סקירה כללית של נתב וירטואלי

נתב וירטואלי הוא תכונה של Network Connectivity Center ‏ (NCC) שמאפשרת לכם להשתמש במכשיר וירטואלי של צד שלישי ברשת ב- Google Cloud. כשמשתמשים בגישה הזו, המכשיר יכול להחליף מסלולים עם Cloud Router באמצעות פרוטוקול Border Gateway Protocol ‏ (BGP).

באמצעות מכשיר נתב ו-NCC, אפשר:

  • חיבור של כמה רשתות VPC זו לזו. רשתות ה-VPC יכולות להיות ממוקמות בפרויקטים שונים באותו ארגון Google Cloud או בארגונים שונים.
  • חיבור של כמה רשתות VPC לרשתות בארגון או לרשתות של ספק שירותי ענן אחר. אפשר להגיע לרשתות החיצוניות האלה דרך כל סוג של רשת היברידית מסוג Hub and Spoke. הגישה הזו נקראת קישוריות מאתר לענן.
  • אפשר להשתמש במכונות וירטואליות של Router appliance כדי לנהל את הקישוריות בין רשתות ה-VPC.
  • אפשר להשתמש ברשת Google Cloud VPC כרשת תקשורת מרחבית (WAN) ארגונית כדי לחבר רשתות שנמצאות מחוץ ל- Google Cloud. אתם יכולים ליצור קישוריות בין האתרים החיצוניים שלכם באמצעות כל סוג של רכזת היברידית. הגישה הזו נקראת קישוריות מאתר לאתר.

איך זה עובד

אפשר להגדיר מכשיר נתב וירטואלי על ידי התקנת קובץ אימג' במכונה וירטואלית ב-Compute Engine. אתם יכולים להשתמש בתמונה שסופקה על ידי שותף נתמך של NCC. אפשר גם להשתמש בתמונה מותאמת אישית, למשל תמונה שיצרתם.

אחרי שמתקינים את מכשיר הנתב, מגדירים ממשקים ב-Cloud Router כדי ליצור קישור בין רשתות שכנות (peering) באמצעות Border Gateway Protocol‏ (BGP) עם מכשיר הנתב. פרוטוקול BGP מאפשר שינוי מסלול דינמי בין Cloud Router לבין מופע של מכשיר נתב. החלפת נתיבים מאפשרת קישוריות מהאתר לרשת ה-VPC דרך מופע של מכשיר נתב. כלומר, אפשר להשתמש בנתיבים שמופצים על ידי מכשיר הנתב במכונות וירטואליות ובמשאבים אחרים שיש להם כתובות IP באותה רשת VPC.

‫Cloud Router משתמש בממשקים שהוגדרו עם כתובות IP פנימיות של RFC 1918 כדי ליצור קישור בין רשתות שכנות (peering) של BGP עם מופעים של מכשירי נתב.

אין ממשקי API Google Cloud , משאבים או הרשאות נפרדים לנתב וירטואלי. כדי לעבוד עם נתב וירטואלי, משתמשים במשאבים ובהרשאות של Compute Engine ו-Cloud Router.

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

בטופולוגיה הבאה מוצגת רשת VPC ושני אתרים מקומיים. כל אתר מקומי מתחבר אל Google Cloud באמצעות spoke של נתב וירטואלי. שני האתרים המקומיים יכולים להשתמש ברשת של Google כדי להעביר נתונים ביניהם.

טופולוגיה של נתב וירטואלי
טופולוגיה של מכשיר נתב (לחצו כדי להגדיל)

  1. כל אחד מהמכשירים המקומיים Customer network A ו-Customer network B מחובר דרך ציוד של הלקוח (CPE) למופע של מכשיר נתב. בדרך כלל, ציוד CPE משתמש במנגנון קישוריות, כמו מנהרת שכבת-על של SD-WAN או מנהרת VPN של IPsec, כדי ליצור קישוריות עם מופע של מכשיר נתב.

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

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

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

  3. בכל אזור, מופע של מכשיר נתב יוצר קישור בין רשתות שכנות (peering) באמצעות Border Gateway Protocol‏ (BGP) עם Cloud Router המתאים. כל Cloud Router מקבל ומפרסם קידומות של מסלולים מהמיקום המתאים באתר המקומי.

  4. נתבי Cloud מחליפים באופן דינמי את כל המסלולים שהתקבלו ביניהם. ההגדרה הזו מספקת חילופי מסלולים דינמיים מקצה לקצה וקישוריות של מישור הנתונים בין Customer network A לבין Customer network B.

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

דרישות

כשפורסים מופעים של מכשירי נתב, צריך לפעול לפי הדרישות הבאות.

הגדרת BGP

  • תמונת מכשיר הנתב שמתקינים צריכה לתמוך בפרוטוקול הניתוב BGP.
  • כדי להפעיל קישור בין רשתות שכנות באמצעות BGP בין מכונת נתב לבין Cloud Router, צריך לצרף כל מכונת נתב כרשת משנית לרכזת NCC.
  • יוצרים Cloud Router באותו אזור שבו נמצאת תת-הרשת שמכילה את ממשק ה-Peering של מכונת הנתב.
  • יוצרים ממשקי BGP באופן ידני במופע של מכשיר הנתב. הממשקים האלה צריכים להיות באותה רשת משנה כמו מופע מכשיר הנתב.
  • יצירה ידנית של סשנים של BGP עם Cloud Router ממופע של מכשיר נתב.
  • במכונות וירטואליות עם כמה ממשקי רשת שהוגדרו כחלק ממכונת הנתב, אפשר ליצור סשנים של BGP עם נתבי Cloud שנמצאים באותה רשת משנה כמו ממשק המכונה הווירטואלית. מידע נוסף על ממשקי VM זמין במאמר סקירה כללית ודוגמאות של ממשקי רשת מרובים.

המלצות לגבי זמינות

‫ * הסכם רמת השירות (SLA) הרגיל למכונות וירטואליות של Compute Engine חל גם על הזמינות של מופעים של מכשירי נתב. הסכם רמת שירות (SLA) זה מבטיח זמינות של 99.5% למכונה וירטואלית אחת ו-99.99% למכונות וירטואליות בכמה תחומים (zones). מידע נוסף מופיע במאמר בנושא הסכם רמת השירות (SLA) של Compute Engine. * לזוג מופעים של מכשיר נתב, כל אחד למיקום מקומי אחר, מריצים לפחות שתי מכונות וירטואליות באזורים שונים. כל מכונה וירטואלית צריכה להיות מחוברת לשני ממשקים מיותרים של Cloud Router. מידע נוסף על אזורים זמין במאמר אזורים ומתחמים.

לתשומת ליבכם

לפני שמשתמשים בנתב וירטואלי, כדאי לעיין בסעיפים הבאים.

שיקולים כלליים

  • נדרש NCC כדי להפעיל את הנתב הווירטואלי. כלומר, אי אפשר להגדיר מופעים של מכשירי נתב עצמאיים שיוצרים קשר עם Cloud Router או עם נתבים אחרים שיוצרים קשר. צריך להגדיר מכונות וירטואליות של נתבים כחלק מ-NCC spoke.

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

    נתב וירטואלי לא תומך ב-VPC משותף כשמכונת ה-VM של נתב וירטואלי נפרסת בפרויקט השירות.

שיקולים לגבי ניתוב

  • אם כמה מופעים של מכשיר נתב מכריזים על אותם קידומות ניתוב עם אותו MED, Google Cloud המערכת משתמשת בניתוח נתיבים מרובים בעלות שווה (ECMP) בכל המופעים של מכשיר הנתב.
  • מומלץ לא לפרסם את אותם קידומות באמצעות שילוב של סוגי spoke שונים (מכשירי נתב, שערים של Cloud VPN וחיבורי VLAN). אם אפשר להגיע לאותם קידומות באמצעות שילוב של סוגי רכזות, שימוש ב-ECMP בשילוב של סוגי רכזות עלול להוביל לתנועה לא מאוזנת בכל קישור.
  • אם נלמד קידומת אחת עם כמה צעדים הבאים ב-Cloud Router יחיד, Cloud Router בוחר קודם את הצעדים הבאים עם אורך הנתיב הקצר ביותר של AS, ואז משתמש ב-MED כדי להכריע בין נתיבים שווים. מידע נוסף מופיע במאמר אורך הנתיב של מערכת אוטונומית במאמרי העזרה של Cloud Router.

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