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

נתב וירטואלי הוא תכונה של 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 המתאים. כל Cloud Router מקבל ומפרסם קידומות של מסלולים מהמיקום המתאים באתר המקומי.

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

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

דרישות

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

הגדרת BGP

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

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

  • הסכם רמת השירות (SLA) הרגיל למכונות וירטואליות של Compute Engine חל גם על הזמינות של מופעי מכשירי נתב. רמת הזמינות בהסכם רמת השירות היא 99.5% למכונה וירטואלית אחת ו-99.99% למכונות וירטואליות בכמה אזורים. מידע נוסף מופיע במאמר בנושא הסכם רמת השירות (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.

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