הגדרת נתב חיצוני כדי להימנע ממיקומים לא נתמכים

התכונה 'העברת נתונים מאתר לאתר' מאפשרת לכם לחבר את האתרים החיצוניים שלכם באמצעות רשת Google. בהקשר הזה, אתר חיצוני הוא כל רשת שאתם מנהלים מחוץ ל- Google Cloud. לדוגמה, אתר חיצוני יכול להיות הרשת המקומית או הרשת שלכם אצל ספק שירותי ענן אחר.

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

העברת נתונים מאתר לאתר היא חלק מ-Network Connectivity Center, שמאפשר לכם לנהל את הרשת באמצעות ארכיטקטורת רכזת וחישורים. כדי להשתמש בהעברת נתונים מאתר לאתר, צריך ליצור קישוריות לכל רשת חיצונית באמצעות משאב קישוריות נתמך. לאחר מכן, משייכים כל משאב קישוריות לנקודת חיבור (spoke) של Network Connectivity Center ‏(NCC), שמצורפת למרכז (hub) של NCC. לאחר מכן, NCC יוצר קישוריות מלאה בין כל האתרים החיצוניים שמשויכים ל-spokes.

טופולוגיה לדוגמה

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

  • רשת א', בהודו

  • רשת ב', באוסטרליה

הרשתות האלה מתחברות אל Google Cloud באמצעות קובצי מצורף של VLAN ל-Dedicated Interconnect ומנהרות Cloud VPN‏ (HA VPN). המשאבים האלה ממוקמים בשני אזורים שנתמכים להעברת נתונים מאתר לאתר: asia-south1 ו-australia-southeast1. שני קבצים מצורפים של VLAN משויכים ל-NCC spokes שבהם מופעלת התכונה של העברת נתונים מאתר לאתר.

בטופולוגיה הזו, מכונות וירטואליות (VM) של Compute Engine ממוקמות ב-australia-southeast1. המכונות הווירטואליות האלה מריצות שירותים שמערכות מקומיות שנמצאות ברשת א' ניגשות אליהם באופן קבוע.

עם זאת, הטופולוגיה הזו תוכננה כך שלמשאבי Dedicated Interconnect תהיה זמינות של 99.99%. כדי להשיג זמינות של 99.99%, צריך להשתמש בשני זוגות של חיבורי Dedicated Interconnect בשני אזורים. לכל חיבור צריך להיות צירוף ל-VLAN משלו.

כדי לעמוד בדרישה הזו, בדוגמה של הטופולוגיה ממוקם זוג מיותר של צירופים ל-VLAN באזור היפותטי שאין בו תמיכה (region-unsupported1). רשת א' נמצאת במרחק שווה בין asia-south1 לבין region-unsupported1. עם זאת, האזור שלא נתמך קרוב יותר ל-australia-southeast1 מאשר ל-asia-south1.

ההגדרה הזו עלולה לגרום לבעיה בהעברת נתונים מאתר לאתר. מכיוון ש-region-unsupported1 קרוב יותר ל-australia-southeast1, ה-Cloud Router ב-australia-southeast1 רואה את המשאב ב-region-unsupported1 כנתיב האופטימלי לרשת א'. אבל מכיוון שהנתיב הזה לא משויך ל-NCC, נתב Cloud לא מפרסם מחדש את הקידומות של רשת A לרשת B.

דוגמה לטופולוגיה שבה נעשה שימוש במיקום שלא נתמך להעברת נתונים מאתר לאתר.
איור 1. טופולוגיה לדוגמה שמשתמשת במיקום שלא נתמך להעברת נתונים מאתר לאתר (לחיצה להגדלה).

אפשרויות להגדרות אישיות

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

בשתי האפשרויות האלה נעשה שימוש ב-MED. כדי להבין איך Cloud Router משתמש ב-MED, אפשר לעיין בהנחיות לגבי עדיפויות בסיסיות.

אפשרות 1: אופטימיזציה להעברת נתונים מאתר לאתר

אם העברת נתונים מאתר לאתר היא קריטית, צריך להגדיר שכל התנועה תעדיף משאבים שמשויכים ל-spokes של NCC. כדי להשיג את ההתנהגות הזו, צריך להשתמש בערכי MED שונים עבור asia-south1 ועבור region-unsupported1.

לדוגמה, כדי להגדיר את הנתב ברשת A המקומית לפרסום של 10.1/16, משתמשים בפקודה הבאה:

  • ‫MED של 100 עד asia-south1
  • ‫MED של 20000 עד region-unsupported1

במקרה כזה, Cloud Router ב-australia-southeast1 רואה את הפרסום שמגיע מ-asia-south1 כנתיב הטוב ביותר. הוא גם מציג מחדש מודעות של 10.1/16 ברשת B המקומית.

היתרון בגישה הזו הוא שהיא מאפשרת לכם להשתמש בהעברת נתונים מאתר לאתר באופן עקבי. החיסרון הוא שהיא מגדילה את זמן האחזור של מערכות A ברשת שצריכות לגשת למכונות הווירטואליות ב-australia-southeast1.

אפשרות 2: אופטימיזציה של התנועה מאתר לענן

אם העברת נתונים מאתר לאתר היא לא קריטית, אפשר להגדיר שכל התנועה תעדיף את region-unsupported1. כדי להשיג את ההתנהגות הזו, צריך להשתמש באותם ערכי MED עבור asia-south1 ו-region-unsupported1.

לדוגמה, כדי להגדיר את הנתב ברשת A המקומית לפרסום של 10.1/16, משתמשים בפקודה הבאה:

  • ‫MED של 100 עד asia-south1
  • ‫MED של 100 עד region-unsupported1

במקרה כזה, Cloud Router ב-australia-southeast1 רואה את ההודעה שמגיעה מ-region-unsupported1 כנתיב הטוב ביותר כי הוא קרוב יותר מבחינה גיאוגרפית מ-asia-south1.

מכיוון שהנתיב הזה לא משויך ל-NCC,‏ Cloud Router לא מפרסם מחדש את 10.1/16 לרשת B המקומית.

היתרון בגישה הזו הוא שבמערכות ברשת א' שצריכות לגשת למכונות וירטואליות ב-australia-southeast1, ניתנת עדיפות לנתיב עם השהיה נמוכה יותר. החיסרון בגישה הזו הוא שהיא גורמת להעברת נתונים מאתר לאתר להיכשל.

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