שיטות מומלצות לשימוש ב-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 עם קיבולת מספקת לצירופי ה-VLAN שלכם במהלך תחזוקה מתוכננת של החיבור או במהלך כשל בלתי צפוי בשילוב של תחום זמינות קצה (EAD) ומתקן לאחסון ואירוח שרתים (colocation facility).

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

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

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

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

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

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

סוג הקיבולת הדרכה
קיבולת החיבור של Cloud Interconnect מוודאים שלכל דומיין זמינות של Edge יש מספיק קיבולת חיבור כדי להעביר את כל תעבורת הייצור.
קיבולת של צירוף ל-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 מהרשת המקומית.

בטבלה הבאה מתוארת כמות הקיבולת המינימלית של ה-attachment שנדרשת בכל תחום זמינות של קצה הרשת לכל רשת 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 פועלים בצורה תקינה במהלך פעולה רגילה. כשמשתמשים בהגדרה פעילה-פעילה, חשוב לעקוב אחרי דפוסי השימוש כדי לוודא שיש לכם מספיק קיבולת אם מתרחש כשל.

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

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

תעבורת רשת שיוצאת מאזור מסוים מעדיפה להשתמש בנתיב עם המדד הכי נמוך, כמו שמתואר בקטע ההשפעות של מצב ניתוב דינמי בסקירה הכללית של 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 פועל בהצלחה.
קיבולת במהלך מעבר לגיבוי (failover)

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

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

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

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

בתרחיש הזה, אתם מקצים שני חיבורי 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

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

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

קיבולת מספקת

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

קיבולת לא מספקת אם אחד מחיבורי 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 10Gbps.

דומיין הזמינות של 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 פועל בהצלחה.
קיבולת במהלך מעבר לגיבוי (failover)

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

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

עם זאת, אם החיבור שלכם ל-Cloud Interconnect ב-EDGE_DOMAIN_1 יפסיק לפעול, קיבולת הצירוף של החיבור שנותר תהיה רק 10Gbps, ותיתקלו בעומס ובאובדן מנות.
המלצה מוודאים שיש לכם קיבולת שווה בשני תחומים של זמינות קצה באזור מטרופוליטני. זה רלוונטי גם לחיבורי Cloud Interconnect וגם לחיבורי VLAN. בתרחיש הזה, צריך לפחות 2x10 Gbps של קיבולת חיבור בכל תחום זמינות של קצה הרשת כדי להבטיח קיבולת מספקת אם אחד מחיבורי 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 מבטל את החבילה ושולח הודעה על הצורך בפיצול (ICMP over IPv4) או על חבילה גדולה מדי (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 מכתיב את ה-MTU של רשת ה-VPC שבה משתמש ממשק הרשת של המכונה המקבלת, כאילו המכונה המקבלת קיבלה חבילה שמופנית בתוך רשת ה-VPC.
    • מנות שנשלחות ל-Google APIs ולשירותים של Google משרתים מקומיים דרך צירוף ל-VLAN מעובדות באותו אופן כמו מנות שנשלחות ממופעי מכונות וירטואליות ל-Google APIs ולשירותים של Google. מידע נוסף זמין במאמר תקשורת עם ממשקי API ושירותים של Google.
חבילות שנשלחות דרך HA VPN באמצעות Cloud Interconnect ב-HA VPN over Cloud Interconnect,‏ MTU של שער הוא 1,440 בייט, ו-MTU של מטען ייעודי קטן יותר, בהתאם להצפנות שבהן נעשה שימוש. מידע נוסף זמין במאמר שיקולים לגבי MTU במאמרי העזרה בנושא Cloud VPN.

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