שיטות מומלצות לשימוש ב-Cloud Interconnect

כדאי להשתמש בשיטות המומלצות הבאות כשמתכננים ומגדירים את Cloud Interconnect.

עבודה עם Google Cloud פרויקטים

אם ארכיטקטורת הרשת שלכם תומכת בכך, כדאי להגדיר את פרויקטי Cloud Interconnect כמומלץ בקטע הזה.

הקצאת חיבורים פיזיים של Cloud Interconnect בפרויקט נפרד

הקצאת חיבורים פיזיים (יציאות) ל-Cloud Interconnect בפרויקט אחד, אבל הקצאת קבצים מצורפים של VLAN בפרויקטים אחרים. הפרויקטים האחרים צריכים להיות באותו ארגון Google Cloud כמו הפרויקט שמכיל את החיבורים הפיזיים.

חיבורי VLAN שמקשרים חיבור פיזי לאזור באמצעות Cloud Router לא חייבים להיות באותו פרויקט כמו החיבור הפיזי. מידע נוסף זמין במאמר בנושא שימוש בחיבורים בפרויקטים אחרים.

השיטה הזו מקלה על ביצוע שלבי ההגדרה הבאים:

  • אפשר לשייך לחשבון לחיוב פנימי נפרד את הפרויקט שמכיל את החיבורים הפיזיים.
  • אפשר להגדיר תפקידים והרשאות בניהול זהויות והרשאות גישה (IAM) בפרויקט שמכיל את החיבורים הפיזיים.
  • אם רוצים למחוק או לעדכן משאב שהוא לא חיבור פיזי, אפשר לעשות זאת בלי להשפיע על החיבורים הפיזיים.

הגדרת קבצים מצורפים של VLAN בפרויקט המארח של ה-VPC המשותף

ברשת VPC משותפת, צריך להגדיר את כל חיבורי ה-VLAN, ולא חיבורים פיזיים של Cloud Interconnect (יציאות), בפרויקט המארח. מידע נוסף על חיבור קבצים מצורפים לרשתות VPC משותפות זמין במאמר אפשרויות לחיבור לכמה רשתות VPC.

יצירת חיבורים מיותרים של Cloud Interconnect עם קיבולת מספקת

בקטע הזה מתוארות שיטות מומלצות ליצירת חיבורים מיותרים של Cloud Interconnect עם קיבולת מספקת במקרה של מעבר לגיבוי (failover). השיטות המומלצות האלה מבטיחות שאירועים כמו תחזוקה מתוכננת או כשלים בחומרה לא יגרמו להשבתה.

חיבורי Cloud Interconnect מספקים הגנה של עד 50% מתעבורת הרשת בקיבולת כוללת, כשהקיבולת מחולקת באופן שווה בין אזורי הזמינות של קצה הרשת. כך מובטחת קיבולת מספקת במקרה של כשל או תחזוקה מתוכננת. שימוש ביותר מ-50% מהקיבולת של Cloud Interconnect עלול לגרום להגבלת מהירות החיבור בתקופות של עומס ברשת. לדוגמה, אם אתם מתכוונים לשלוח 100 Gbps של תנועה מוגנת בין הרשת המקומית שלכם לבין Google Cloud, אתם צריכים להקצות חיבורי Cloud Interconnect מיותרים עם קיבולת של לפחות 200 Gbps.

אתם יכולים ליצור חיבורי Cloud Interconnect לפי אחת מהטופולוגיות המומלצות הבאות:

כשיוצרים חיבורי Cloud Interconnect בהתאם לטופולוגיות האלה, יוצרים זוגות של חיבורים באזור מטרופוליטני אחד או יותר. באזור מטרופוליטני יחיד, אתם יכולים למקם חיבורי Cloud Interconnect בדומיינים שונים של זמינות קצה.

מומלץ ליצור חיבורים מיותרים באמצעות קבוצות חיבורים. מידע נוסף מופיע במאמר אפשרויות של עמידות והסכם רמת שירות.

לוודא שיש מספיק קיבולת בכל תחום זמינות של שרת קצה

אם יש השבתה או תחזוקה באחד מהדומיינים של זמינות קצה באזור מטרופוליני, התעבורה עוברת אוטומטית לדומיין השני של זמינות קצה.

כדי למנוע אובדן מנות אם דומיין זמינות קצה יחיד נכשל, פועלים לפי ההנחיות הבאות:

סוג הקיבולת הדרכה
קיבולת החיבור של Cloud Interconnect חשוב לוודא שלכל תחום זמינות של שרת קצה יש מספיק קיבולת חיבור כדי להעביר את כל תעבורת הייצור.
קיבולת של צירוף ל-VLAN

מוודאים שלכל תחום זמינות של קצה הרשת יש מספיק קיבולת של צירוף ל-VLAN כדי להעביר את כל תעבורת הייצור של רשת ה-VPC היעד.

תעבורת הנתונים ב-VPC בחיבורי Cloud Interconnect מועברת דרך קבצים מצורפים של VLAN, שמקשרים את החיבור לרשתות VPC. גם אם לכל תחום זמינות של קצה יש קיבולת חיבור מספקת, צריך לוודא שיש לו גם קיבולת מספקת של צירוף ל-VLAN.

קיבולת של צירוף ל-VLAN וכמה רשתות VPC

אם אתם משתמשים בחיבורי Cloud Interconnect כדי לגשת ליותר מרשת אחת של ענן וירטואלי פרטי (VPC), אתם צריכים ליצור קובצי מצורף של VLAN מכל רשת VPC לכל חיבור Cloud Interconnect. לכל רשת VPC, צריך לוודא שיש מספיק קיבולת של צירוף ל-VLAN כדי להעביר את כל תעבורת הייצור של רשת ה-VPC הזו אם מתרחש יתירות כשל.

נניח שיש לכם את רשתות ה-VPC ועומסי העבודה הבאים:

  • ‫vpc-1 מקבל 2Gbps של תנועה כוללת מהרשת המקומית שלכם.
  • בנוסף, vpc-2 מקבלת תנועה כוללת של 2Gbps מהרשת המקומית שלכם.

בטבלה הבאה מתוארת קיבולת הצירוף המינימלית שצריך בכל תחום זמינות של קצה לכל רשת VPC:

דומיין הזמינות של Edge קיבולת החיבור קיבולת הקבצים המצורפים
EDGE_DOMAIN_1 ‫1 x 10 Gbps ‫2 x 1 Gbps עד vpc-1
‫2 x 1 Gbps עד vpc-2
EDGE_DOMAIN_2 ‫1 x 10 Gbps ‫2 x 1 Gbps עד vpc-1
‫2 x 1 Gbps עד vpc-2

כשמוסיפים חיבורי VLAN דרך חיבור Cloud Interconnect, יכול להיות שהקיבולת שהוגדרה לחיבור תהיה גדולה מהקיבולת הכוללת של החיבור. ההגדרה הזו תקינה, אבל התנועה בפועל לא יכולה לחרוג מהקיבולת הכוללת של החיבור. מוודאים שעומס העבודה לא יוצר יותר תנועה מהקיבולת של החיבור.

שימוש בצירופים ל-VLAN במצב פעיל-פעיל

יש שתי דרכים להגדיר צירופים מיותרים ל-VLAN:

  • הגדרה פעילה-פעילה שמפצלת את התנועה בין קבצים מצורפים של VLAN.
  • הגדרה פעילה/סבילה שמשתמשת רק בצירוף ל-VLAN אחד בכל פעם.

מומלץ להשתמש בהגדרה פעילה-פעילה כי היא מאפשרת לקבוע בקלות אם כל חיבורי ה-VLAN פועלים בצורה תקינה במהלך פעולה רגילה. כשמשתמשים בהגדרה פעילה-פעילה, צריך לעקוב אחרי דפוסי השימוש כדי לוודא שיש לכם מספיק קיבולת אם מתרחש כשל.

בהגדרה פעילה/סבילה, יכול להיות שחיבורי VLAN יוגדרו בצורה שגויה בלי שתשימו לב. אם אתם משתמשים בהגדרה הזו, הקפידו לבדוק את יתירות הכשל לפני שמוסיפים תנועה בסביבת הייצור.

הסבר על יתירות כשל בין אזורים

תעבורת רשת שיוצאת מאזור מסוים מעדיפה להשתמש בנתיב עם המדד הנמוך ביותר, כפי שמתואר במאמר ההשפעות של מצב ניתוב דינמי בסקירה הכללית של Cloud Router. בשימוש רגיל, המשמעות היא שתעבורת נתונים יוצאת (egress) עוברת דרך האזור הקרוב ביותר Google Cloud שיש בו צירופי VLAN פעילים, והאזור המקומי הוא הקרוב ביותר.

לדוגמה, נניח שאתם בונים טופולוגיה לאפליקציות ברמת הייצור, ויש לכם רשת VPC עם המאפיינים הבאים:

  • צירופים ל-VLAN בשני אזורים
  • הניתוב הדינמי הגלובלי הופעל

התנועה מעדיפה לצאת מצירופים ל-VLAN באזור המקומי, גם אם הצירופים באזור הזה עמוסים מדי. התנועה תזרום לאזור השני רק אם כל חיבורי ה-VLAN באזור המקומי יושבתו. המשמעות היא שלכל אחד מארבעת חיבורי Cloud Interconnect בטופולוגיה צריכה להיות קיבולת מספיקה של צירוף ל-VLAN כדי להעביר את כל תעבורת הייצור.

תרחישים

בקטע הזה מתוארים תרחישים שבהם מגדירים משאבי Cloud Interconnect. בנוסף, מוסבר איך כל הגדרה מטפלת בעומס העבודה במהלך פעולה רגילה ומעבר לגיבוי. כל תרחיש כולל המלצה שקשורה לשיטות המומלצות ליתירות ולקיבולת.

תרחיש 1: קיבולת מספקת

בתרחיש הזה, אתם מקצים שני חיבורי Dedicated Interconnect בשני תחומים שונים של זמינות קצה, כמו שמוצג בטבלה הבאה:

דומיין הזמינות של Edge קיבולת החיבור קיבולת הקבצים המצורפים אזור הקבצים המצורפים
EDGE_DOMAIN_1 ‫1 x 10 Gbps ‫1 x 10 Gbps ATTACHMENT_REGION_1
EDGE_DOMAIN_2 ‫1 x 10 Gbps ‫1 x 10 Gbps ATTACHMENT_REGION_1

בטבלה הבאה מוסבר איך ההגדרה הזו מטפלת בעומס העבודה במהלך פעולה רגילה ובמהלך יתירות כשל:

משאב תיאור
גודל עומס העבודה תעבורה כוללת של 10Gbps בין ATTACHMENT_REGION_1 לבין הרשת המקומית.
קיבולת במהלך פעולה רגילה

קיבולת מספקת

קיבולת של ‎20 Gbps מ-ATTACHMENT_REGION_1 לרשת המקומית שלכם. עומס העבודה שלכם בנפח 10Gbps פועל בהצלחה.
קיבולת במהלך מעבר לגיבוי

קיבולת מספקת אם אחד מחיבורי Cloud Interconnect מושבת.

לדוגמה, אם החיבור ב-EDGE_DOMAIN_1 נכשל, הקיבולת הזמינה שלכם היא החיבור ב-EDGE_DOMAIN_2. לחיבור Cloud Interconnect היחיד הזה יש קיבולת של ‎10 Gbps. קיבולת הצירוף של 10‎ Gbps שיצרתם מספיקה להעברת עומס העבודה של הייצור.

אם נפח העבודה שלכם יגדל ליותר מ-10Gbps של תנועה, הוא יחרוג מהקיבולת של הקובץ המצורף, ויכול להיות שתחוו אובדן מנות.
המלצה צריך להקצות קיבולת לחיבור Cloud Interconnect ולחיבור ה-VLAN, כך שלכל תחום זמינות של קצה הרשת תהיה קיבולת מספקת לכל עומס העבודה של הייצור.

תרחיש 2: קיבולת לא מספקת במהלך מעבר לגיבוי (failover)

בתרחיש הזה, אתם מקצים שני חיבורי Dedicated Interconnect בשני תחומים שונים של זמינות קצה, כמו שמוצג בטבלה הבאה:

דומיין הזמינות של Edge קיבולת החיבור קיבולת הקבצים המצורפים אזור הקבצים המצורפים
EDGE_DOMAIN_1 ‫1 x 100 Gbps ‫100 Gbps‏ (2‎ x 50 Gbps) ATTACHMENT_REGION_1
EDGE_DOMAIN_2 ‫1 x 100 Gbps ‫100 Gbps‏ (2‎ x 50 Gbps) ATTACHMENT_REGION_1

בטבלה הבאה מוסבר איך ההגדרה הזו מטפלת בעומס העבודה במהלך פעולה רגילה ובמהלך יתירות כשל:

משאב תיאור
גודל עומס העבודה נפח התנועה הכולל בין ATTACHMENT_REGION_1 לבין הרשת המקומית שלכם הוא ‎150 Gbps.
קיבולת במהלך פעולה רגילה

קיבולת מספקת

‫‎200 Gbps של קיבולת מ-ATTACHMENT_REGION_1 לרשת המקומית שלכם. עומס העבודה שלכם בנפח 150Gbps פועל בהצלחה.
קיבולת במהלך מעבר לגיבוי

קיבולת לא מספקת אם אחד מהחיבורים של Cloud Interconnect מושבת.

אם אחד מחיבורי Cloud Interconnect מושבת לצורך תחזוקה, כל עומס העבודה של 150Gbps מנסה לבצע מעבר לגיבוי (failover) לחיבור יחיד של 100Gbps. הכמות הזו גדולה יותר מהקיבולת של החיבור, ולכן יש עומס ואובדן מנות.
המלצה כדי להבטיח זמינות מלאה במהלך אירוע כשל, צריך לוודא שתנועת הגולשים המשולבת בכל חיבור לא חורגת מהקיבולת הכוללת של דומיין זמינות יחיד של קצה הרשת. בתרחיש הזה, תצטרכו קיבולת חיבור של לפחות ‎200 Gbps וקיבולת צירוף של ‎3 x 50 Gbps בכל תחום זמינות של קצה הרשת כדי שתהיה לכם קיבולת מספקת במהלך מעבר לגיבוי.

תרחיש 3: צירופים לא מאוזנים ל-VLAN

בתרחיש הזה, אתם מקצים שני חיבורי Dedicated Interconnect בשני תחומים שונים של זמינות קצה, כמו שמוצג בטבלה הבאה. אתם מקצים בהתחלה קיבולת של 1‎ x 10 Gbps של קובץ מצורף ב-EDGE_DOMAIN_1. בהמשך, אתם מבינים שנפח העבודה גדל ל-20Gbps, ולכן אתם מעדכנים רק את קיבולת הצירוף ב-EDGE_DOMAIN_1 ל-2 x 10 Gbps.

דומיין הזמינות של Edge קיבולת החיבור קיבולת הקבצים המצורפים אזור הקבצים המצורפים
EDGE_DOMAIN_1 ‫1 x 100 Gbps ‫1 x 10 Gbps (הקצאה ראשונית)
2 x 10 Gbps (עדכון מאוחר יותר)		 ATTACHMENT_REGION_1
EDGE_DOMAIN_2 ‫1 x 100 Gbps ‫1 x 10 Gbps ATTACHMENT_REGION_1

בטבלה הבאה מוסבר איך ההגדרה הזו מטפלת בעומס העבודה במהלך פעולה רגילה ובמהלך יתירות כשל:

משאב תיאור
גודל עומס העבודה נפח תנועה כולל של 20Gbps בין ATTACHMENT_REGION_1 לבין הרשת המקומית.
קיבולת במהלך פעולה רגילה

קיבולת מספקת

‫30 Gbps של קיבולת מ-ATTACHMENT_REGION_1 לרשת המקומית שלכם. עומס העבודה שלכם בנפח 20Gbps פועל בהצלחה.
קיבולת במהלך מעבר לגיבוי

קיבולת מספקת אם החיבור של Cloud Interconnect ב-EDGE_DOMAIN_2 מושבת.
קיבולת לא מספקת אם החיבור של Cloud Interconnect ב-EDGE_DOMAIN_1 מושבת.

אם חיבור Cloud Interconnect ב-EDGE_DOMAIN_2 מושבת, עדיין יש קיבולת של 20Gbps לחיבור שנותר, ועומס העבודה פועל בהצלחה.

עם זאת, אם החיבור שלכם ל-Cloud Interconnect ב-EDGE_DOMAIN_1 יפסיק לפעול, קיבולת הצירוף מהחיבור שנותר תהיה רק 10Gbps, ותיתקלו בעומס ובאובדן מנות.
המלצה חשוב לוודא שיש לכם קיבולת שווה בשני תחומים של זמינות קצה באזור מטרופוליני. זה רלוונטי גם לחיבורי Cloud Interconnect וגם לחיבורי VLAN. בתרחיש הזה, צריך לפחות 2 חיבורים של 10Gbps בכל תחום זמינות של קצה הרשת כדי להבטיח קיבולת מספקת אם אחד מחיבורי Cloud Interconnect יפסיק לפעול.

שימוש באותו MTU לכל צירופי ה-VLAN

מומלץ להשתמש באותו MTU לכל קבצים מצורפים של VLAN שמחוברים לאותה רשת VPC, ולהגדיר את ה-MTU של רשת ה-VPC לאותו ערך. זוהי השיטה המומלצת, אבל אתם לא חייבים להגדיר את ערכי ה-MTU של צירופים ל-VLAN ואת ערכי ה-MTU של רשתות ה-VPC כך שיהיו זהים. עם זאת, יכול להיות שיהיו מקרים של אובדן מנות, במיוחד בפרוטוקולים שאינם TCP, אם תבצעו את הפעולות הבאות:

  • להשתמש בערכי MTU שונים של צירוף ל-VLAN עבור צירופים ל-VLAN שמחוברים לאותה רשת VPC.
  • הגדרת MTU של צירוף ל-VLAN שהוא קטן יותר מה-MTU של רשת ה-VPC שמכילה את הצירופים ל-VLAN.

למידע כללי על האופן שבו פרוטוקולים מטפלים בערכי MTU לא תואמים, אפשר לעיין במאמר Mismatched MTUs, MSS clamping, path MTU discovery (ערכי MTU לא תואמים, הידוק MSS, איתור MTU של נתיב) במסמכי התיעוד בנושא MTU של VPC.

מנות שנשלחות דרך צירוף ל-VLAN מעובדות באופן הבא:

מצב התנהגות
מנות TCP SYN ו-SYN-ACK Google Cloud מבצעת הידוק של MSS, ומשנה את ה-MSS כך שחבילות יתאימו ל-MTU של צירוף ה-VLAN. לדוגמה, אם ה-MTU של קובץ ה-VLAN המצורף הוא 1,500 בייט, הגבלת ה-MSS משתמשת בגודל מקטע מקסימלי של 1,460 בייט.
מנות IP עד (כולל) ה-MTU של הצירוף ל-VLAN ‫Google Cloud לא מבצע שינויים במנות, למעט מנות SYN ומנות SYN-ACK, כפי שמתואר בשורה הראשונה.
בדיקות MTU למנות IP
  • ה-MTU של מנות שנשלחות על ידי משאבי Google Cloud דרך צירוף ל-VLAN מוגבל על ידי ה-MTU של הצירוף ל-VLAN. לדוגמה, כשמופע של מכונה וירטואלית שולח מנות ליעד שאפשר להגיע אליו באמצעות ניתוב דינמי, והניתוב הבא הוא צירוף ל-VLAN, המנות שגדולות מה-MTU של הצירוף ל-VLAN מושמטות:
    • ‫Google Cloud משליך את החבילה ושולח הודעה מסוג Fragmentation Needed (ICMP over IPv4) או Packet Too Big (ICMPv6) גם כשהביט Don't Fragment ‏ (DF) מופעל וגם כשהוא מושבת.
    • צריך להגדיר כללי חומת אש של VPC כניסה או כללים במדיניות חומת האש כדי לאפשר כניסה של ICMP (עבור IPv4) או ICMPv6 (עבור IPv6) ממקורות שתואמים ליעדים המקוריים של החבילה.
    • כללי העברה למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ולהעברת פרוטוקול פנימית חייבים להשתמש בפרוטוקול L3_DEFAULT כדי לעבד גם ICMP לגילוי MTU של נתיב (PMTUD) וגם את הפרוטוקול שבו נעשה שימוש בחבילה המקורית.
  • ‫Cloud Interconnect לא אוכף את ה-MTU של צירוף ה-VLAN לגבי חבילות נתונים שמתקבלות מרשת מקומית. במקום זאת, Google Cloud אוכף את ה-MTU על המשאב Google Cloud שמקבל את החבילה:
    • אם המשאב שמקבל את החבילה הוא מכונה וירטואלית, Google Cloud מערכת Cloud Load Balancing אוכפת את ה-MTU של רשת ה-VPC שבה משתמש ממשק הרשת של המכונה המקבלת, כאילו המכונה המקבלת קיבלה חבילה שמועברת בתוך רשת ה-VPC.
    • מנות שנשלחות ל-Google APIs ולשירותים של Google משרתים מקומיים דרך צירוף ל-VLAN, מעובדות באותו אופן כמו מנות שנשלחות ממופעי VM לממשקי API ולשירותים של Google. מידע נוסף זמין במאמר תקשורת עם Google APIs ושירותים של Google.
חבילות שנשלחות דרך HA VPN באמצעות Cloud Interconnect ב-HA VPN over Cloud Interconnect,‏ MTU של שער הוא 1,440 בייט, ו-MTU של מטען ייעודי קטן יותר, בהתאם להצפנות שבהן נעשה שימוש. מידע נוסף זמין במאמר שיקולים לגבי MTU במאמרי העזרה בנושא Cloud VPN.

המאמרים הבאים