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

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

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

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

איך זה עובד

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

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

‫Cloud Router משתמש בממשקים שהוגדרו עם כתובות IP פנימיות של RFC 1918 כדי ליצור שיוך 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 אחת. עם זאת, המקרים של מכשירי הנתב נמצאים באזורים שונים. לכן, מצב הניתוב הדינמי של רשת ה-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 חל גם על הזמינות של מופעים של מכשירי נתב. רמת הזמינות בהסכם רמת השירות היא 99.5% למכונה וירטואלית אחת ו-99.99% למכונות וירטואליות בכמה אזורים. מידע נוסף מופיע במאמר הסכם רמת השירות של Compute Engine.
  • כדי להגדיר זוג מופעים של מכשיר נתב, כל אחד במיקום מקומי אחר, מריצים לפחות שתי מכונות וירטואליות באזורים שונים. כל מכונה וירטואלית צריכה להיות מחוברת לשני ממשקים מיותרים של Cloud Router. מידע נוסף על אזורים זמין במאמר אזורים ומתחמים.

לתשומת ליבכם

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

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

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

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

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

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

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

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