NCC Cross-Cloud Network with NVAs and regional failover

Last reviewed 2026-08-24 UTC

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

המסמך הזה מיועד לאדמינים של רשתות שיוצרים קישוריות לרשת, ולמומחי Cloud Architect שמתכננים איך לפרוס עומסי עבודה. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית של ניתוב, פרוטוקול BGP, קישוריות לאינטרנט ותוכנת NVA שרוצים לפרוס.

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

אם אתם כוללים מכשירי NVA ברשת, הארכיטקטורה הזו מתאימה לדרישות העיצוב הבאות:

  1. תמיכה במעבר לגיבוי (failover) של NVA בין אזורים: זיהוי אוטומטי של כשלים בניווט של NVA באזור מסוים, והפניית התנועה מחדש אל NVAs באזורGoogle Cloud סמוך לפי הצורך.
  2. שמירה על קרבה אזורית: השארת הניתוב בתוך Google Cloud אזורים כדי לצמצם את זמן האחזור ואת עלות העברת הנתונים, אלא אם יש כשל. תעבורת הנתונים מנותבת לאזורים מרוחקים או לחיבורים היברידיים רק אם יש כשל.

העיצוב הזה לא מספק ניתוב סימטרי בין מכשירי NVA, אלא אם מגדירים אותו באמצעות האפשרויות שמתוארות בהמשך בקטע מדרגיות. אם ניתוב סימטרי חשוב יותר לתכנון שלכם מיתירות כשל אזורית ומזיקה לתעבורת נתונים מקומית, כדאי לעיין במאמר בנושא קישור בין רשתות VPC שכנות (peering) של Cross-Cloud Network עם NVAs וזיקה אזורית.

ארכיטקטורה

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

פריסת CCN שבה מוצגות רשתות VPC של ניתוב ומעבר שמחוברות באמצעות מכשירי NVA.

רכיבי ארכיטקטורה

ארכיטקטורת הדוגמה שלמעלה מכילה את הרכיבים הבאים:

רשת חיצונית (במקום או ברשת CSP אחרת)

הרשת החיצונית יכולה להיות מקומית או בספק אחר של שירותי ענן. הוא מארח את הלקוחות של אפליקציות שפועלות ברשתות ה-VPC של עומס העבודה. הרשת החיצונית יכולה גם לארח אפליקציות, אבל מכשירי ה-NVA מעבדים רק תעבורת נתונים שיוצאת מרשת VPC של עומס עבודה או נכנסת אליה.

בתרשים, Cloud Interconnect מחבר את הרשת החיצונית לרשת הניתוב של ה-VPC. בארכיטקטורה הזו יש גם תמיכה בשימוש ב-Cloud VPN במקום ב-Cloud Interconnect. הרשת החיצונית משתמשת בצירופי VLAN של Cloud Interconnect או במנהרות Cloud VPN כדי להתחבר ל-Network Connectivity Center (NCC) hub 1 כרשתות היברידיות מסוג spoke.

ניתוב רשת VPC

רשת ה-VPC של הניתוב מתחברת לרשתות חיצוניות באמצעות Cloud Interconnect או Cloud VPN. הוא מתחבר לרשת ה-VPC של התנועה החוצה דרך מכשירי NVA עם כמה מתאמי NIC.

תעבורת נתונים שעוברת בין רשת ה-VPC לניתוב לבין רשת ה-VPC למעבר חייבת לעבור דרך מכשירי ה-NVA. נתבי Cloud ברשת הניתוב של ה-VPC מחליפים מסלולים עם נתבי הרשת החיצונית ועם כרטיסי ה-NIC של ה-NVA שמחוברים לרשת הניתוב של ה-VPC.

רשת VPC למעבר

רשת ה-VPC של התנועה מתחברת לרשת ה-VPC של הניתוב דרך מכשירי NVA עם multi-NIC. הרשת הזו מעבירה תנועה בין רשת ה-VPC של הניתוב לבין רשתות ה-VPC של עומסי העבודה.

רשת ה-VPC של המעבר מעבירה גם תנועה מרשתות VPC של עומסי עבודה אל מכשירי ה-NVA, ואז בחזרה אל רשתות ה-VPC של עומסי העבודה עבור תנועה בין עומסי עבודה.

נתבי Cloud ברשת מחליפים מסלולים עם כרטיסי ה-NIC של NVA שמחוברים לרשת המעבר.

NVAs

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

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

NCC hub 1

המרכז הזה של NCC מספק קישוריות בין חיבורים היברידיים של רשת חיצונית לבין כרטיסי ה-NIC של NVA שמחוברים לרשת ה-VPC של הניתוב.

המרכז מוגדר בטופולוגיית רשת שכוללת את הסוגים הבאים של רכיבי משנה היברידיים: רכיבי משנה של מכשיר נתב, רכיבי משנה של Cloud VPN ורכיבי משנה של חיבור VLAN של Cloud Interconnect.

כרטיסי NVA NIC שמחוברים לרשת VPC של הניתוב מתווספים ל-Hub כ-spokes של נתב וירטואלי. אפשר להוסיף עד שמונה מכשירי NVA כ-spoke יחיד.

רשתות VPC של עומסי עבודה

רשתות ה-VPC של עומס העבודה מארחות אפליקציות שאפשר לגשת אליהן מלקוחות ברשת החיצונית או מלקוחות ברשתות VPC אחרות של עומס העבודה. רשתות VPC של עומסי עבודה יכולות גם לארח נקודות קצה של Private Service Connect שאפשר לגשת אליהן מרשתות אחרות.

רשתות VPC של עומסי עבודה מוגדרות כרשתות Spoke של VPC ב-NCC hub 2. רשתות ה-VPC של עומסי העבודה מחוברות לכרטיסי ה-NIC של ה-NVA ברשת ה-VPC של התעבורה דרך רכזת NCC מספר 2. תעבורת נתונים שיוצאת מרשת VPC של עומס עבודה מנותבת למכשירי NVA, ללא קשר ליעד הסופי של תעבורת הנתונים.

NCC hub 2

ה-Hub של NCC מספק קישוריות בין רשתות VPC של עומסי עבודה לבין ממשקי NVA של נתב וירטואלי ברשת ה-VPC של התנועה החולפת.

המרכז מוגדר בטופולוגיית כוכב, וההסתעפויות מחוברות באופן הבא:

  • הממשקים של NVA ברשת ה-VPC של התעבורה מוגדרים כ-spokes של מכשיר נתב בקבוצת center spoke.
  • רשתות ה-VPC של עומסי העבודה מוגדרות כרשתות Spoke של VPC בקבוצת Spoke של קצה.

התנועה לרשתות VPC של עומסי עבודה וממנה חייבת לעבור דרך מכשירי ה-NVA.

תנועות תנועה

בקטעים הבאים מוצגים זרימות תנועה רגילות כשכל ה-NVA והחיבורים לרשתות חיצוניות פועלים, וזרימות תנועה של מעבר לגיבוי (failover) כשחיבורים או NVA באזור מסוים נכשלו.

תנועת גולשים רגילה

בתרשים הבא מוצגים זרימות התנועה כשמכשירי ה-NVA והחיבורים לרשתות חיצוניות פועלים:

בזמן שה-NVA פועלים, תנועת הנתונים נשארת באזורים המתאימים.

כשהכול פועל כמו שצריך, התנועה האזורית נשארת באזור שלה:

  1. מדדי BGP שומרים על תעבורה מקומית (מאזור א' לאזור א' או ממיקום א') בתוך האזור, כך שלא צריך לתייג משאבים או מסלולים.
  2. באדריכלות הזו, מכשירי ה-NVA מעבדים את התעבורה בין רשתות ה-VPC של עומסי העבודה, ובין רשתות ה-VPC של עומסי העבודה לבין הרשת החיצונית.

ברשימה הבאה מתוארים זרימות התנועה שמוצגות בתרשים:

רשת חיצונית לרשת VPC של עומס העבודה

תעבורת נתונים עוברת במסלולים דרך חיבורי Cloud Interconnect לרשת VPC הניתוב. המסלולים מוכרזים על ידי Cloud Router ל-NVA דרך רכזת Network Connectivity Center.

ברשת ה-VPC של הניתוב, התנועה מנותבת ל-NIC של ה-NVA הפעיל באמצעות מסלולים דינמיים שנלמדו מה-NVA. התנועה עוברת דרך ה-NVA ל-NIC השני שלו, שמעביר את התנועה לרשת ה-VPC של התנועה. התנועה עוברת במסלולים דרך קישורי NCC לרשת ה-VPC של עומס העבודה ביעד.

רשת VPC של עומס העבודה לרשת חיצונית

התנועה עוברת בנתיבים שנלמדו ממרכז NCC 2 דרך הקישור בין NCC ל-NVA. הוא נכנס ל-NVA הפעיל דרך ה-NIC.

התנועה עוברת דרך ה-NVA ל-NIC השני שלו, שמעביר את התנועה לרשת ה-VPC של הניתוב. תעבורת הנתונים עוברת בנתיבים שמתוכנתים ברשת הניתוב של ה-VPC לצירופי ה-VLAN ולרשת המרוחקת.

מרשת VPC של עומס עבודה לרשת VPC של עומס עבודה

התנועה עוברת בנתיבים שנלמדו ממרכז NCC 2 דרך הקישור בין NCC ל-NVA. היא נכנסת ל-NVA דרך ה-NIC ב-VPC המעבר.

אם יש יותר מ-NVA פעיל אחד, מדדי BGP קובעים איזה NVA הוא הניתור הבא. התעבורה עוברת במסלולים שנלמדו ממרכז NCC מספר 2, יוצאת דרך אותו כרטיס רשת ועוברת דרך הקישור בין רשתות שכנות של NCC אל רשת ה-VPC של עומס העבודה השני.

זרימת תנועה במעבר לגיבוי

בתרשים הבא מוצגים זרימות התנועה כשכל מכשירי ה-NVA באזור נכשלו:

תעבורת הנתונים באזור א' עוברת אוטומטית לאזור ב'.

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

המוצרים שהשתמשו בהם

הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud

  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Network Connectivity Center: מסגרת תזמור שמפשטת את הקישוריות לרשת בין משאבי spoke שמחוברים למשאב ניהול מרכזי שנקרא hub.
  • ‫ Cloud Interconnect: שירות שמרחיב את הרשת החיצונית שלכם לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
  • ‫ Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.
  • ‫ Cloud Router: שירות מבוזר ומנוהל במלואו שמספק יכולות של רמקול ומשיב של פרוטוקול Border Gateway Protocol ‏(BGP). ‫Cloud Router פועל עם Cloud Interconnect,‏ Cloud VPN ומכשירי נתב כדי ליצור מסלולים דינמיים ברשתות VPC על סמך מסלולים שהתקבלו מ-BGP ומסלולים מותאמים אישית שנלמדו.
  • ‫ Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.

חלופות עיצוב

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

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

שיקולים בתכנון

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

אבטחה ותאימות

אלה שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעונה על דרישות האבטחה והתאימות של עומס העבודה:

אמינות

אלה שיקולים והמלצות לעיצוב טופולוגיה ב- Google Cloud שעונה על דרישות המהימנות של עומס העבודה:

  • כדי לשפר את המהימנות, אפשר לפרוס את ה-NVA באזור בכמה Google Cloud אזורים. כך נמנעת תלות באזורים נפרדים, ומשפרים את העמידות מפני הפסקות חשמל באזורים.
  • כדי לקבל זמינות של 99.99% ל-Cloud Interconnect, בדרך כלל צריך להתחבר לשני Google Cloud אזורים שונים, גם אם יש לכם מכונות וירטואליות רק באזור אחד. אם אתם משתמשים ב-Dedicated Interconnect, יש אזורים מסוימים שתומכים בזמינות של 99.99% באזור יחיד.

מדרגיות

בקטע הזה מתוארים שיקולים והמלצות לעיצוב טופולוגיה ב- Google Cloud שעונה על דרישות ההתאמה של עומס העבודה.

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

אם העיצוב שלכם צריך ניתוב סימטרי, תוכלו לשקול את האפשרויות הבאות, בהתאם לתכונות שמציעה תוכנת ה-NVA שלכם:

  • משתמשים במאפייני BGP כדי לשמור על צומת NVA פעיל יחיד לכל אזור, אבל משנים את גודל מכונת ה-VM כדי לטפל בתנועה.
  • משתמשים ביכולות הספק כדי להגדיר NAT של מקור ב-NVA.
  • אם הספק תומך בכך, אפשר להגדיר סנכרון של סשנים בין צמתים.
  • כדאי להשתמש באפשרויות של ניהול תנועה ב-BGP (כמו מדיניות של נתיבי BGP) כדי להגדיר תצורת active-standby לכל זרימה. לדוגמה, אפשר להגדיר רשתות מסוימות כך שהן יעדיפו את NVA-A על פני NVA-B, ולהפוך את ההעדפות עבור רשתות אחרות.

אופטימיזציה של הביצועים

אלה שיקולים והמלצות לעיצוב טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומס העבודה:

  • יכול להיות שאפשר לשפר את ביצועי הרשת על ידי הגדלת יחידת השידור המקסימלית (MTU) של הרשתות והחיבורים. מידע נוסף זמין במאמר בנושא יחידת שידור מקסימלית.
  • כדי לשפר את זמן ההתכנסות, כדאי להשתמש ב-BGP BFD במקומות שבהם זה רלוונטי, כדי להאיץ את הזיהוי והצמצום של שיבושים באירועי BGP. אין תמיכה ב-BFD בסשנים של BGP שהוגדרו למנהרות Cloud VPN או למכשירי NVA שהוגדרו כ-spokes של נתב וירטואלי.

פריסה

כדי לפרוס את ארכיטקטורת ההפניה הזו, פועלים לפי השלבים הבאים:

  1. זיהוי Google Cloud אזורים.
  2. תכנון ובנייה של מבנה הפרויקט.
  3. תכנון הקצאת כתובות IP.
  4. יוצרים את רשת ה-VPC לניתוב.
  5. יצירת חיבורים לרשת החיצונית.
  6. יוצרים את רשתות ה-VPC של התעבורה ועומס העבודה.
  7. יצירת ה-NVA.
  8. יוצרים רכזת NCC 1.
  9. יצירת מרכז NCC 2.
  10. הוספת גישה פרטית ל-Google APIs
  11. הגדרה של תעבורת נתונים נכנסת (ingress) ויוצאת (egress) מהאינטרנט באופן מרוכז.
  12. בדיקת הקישוריות לעומסי עבודה.

זיהוי Google Cloud אזורים

באופן כללי, מומלץ למקם את הקישוריות, רשתות המשנה של ה-VPC ועומסי העבודה שלGoogle Cloud קרוב לרשתות המקומיות או ללקוחות ענן אחרים. מידע נוסף על מיקום עומסי עבודה זמין במאמרים Google Cloud Region Picker ושיטות מומלצות לבחירת אזורים ב-Compute Engine.

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

עיצוב ובנייה של מבנה הפרויקט

יוצרים או מזהים את הפרויקטים שבהם ייצרו את רשתות ה-VPC. תצטרכו את הפרויקטים הבאים:

תכנון הקצאה של כתובות IP

יוצרים תוכנית להקצאת כתובות IP לרשתות הנדרשות. כדי להקל על צבירת כתובות של רשתות VPC של עומסי עבודה, כדאי לבחור את טווחי הכתובות שלהן מתוך טווח גדול יותר. מומלץ להקצות טווח גדול של רשת סופרנט (כמו ‎ /12) לשימוש בהקצאות של רשת ה-VPC של עומס העבודה.

התוכנית צריכה לכלול טווחי כתובות IP עבור הרשתות הבאות:

  • רשתות חיצוניות
  • ניתוב רשת VPC
  • רשת VPC למעבר
  • טווח מצטבר לכל רשתות ה-VPC של עומס העבודה

יצירת רשת VPC לניתוב

רשת ה-VPC לניתוב מארחת את הרכיבים הבאים:

  • חיבורים היברידיים לרשתות חיצוניות.
  • כרטיס רשת אחד מכל NVA. בתרשימים, כרטיס ה-NIC הזה מסומן כ-nic 0.
  • ‫Cloud Router אחד לכל אזור.

כשיוצרים את רשת ה-VPC לניתוב, צריך לבצע את הפעולות הבאות:

  1. בפרויקט שבו רוצים להגדיר רשת VPC לניתוב, יוצרים את רשת הניתוב כרשת VPC גלובלית במצב מותאם אישית עם ניתוב דינמי גלובלי מופעל. כדי להגדיר ניתוב בין אזורים, צריך להגדיר ניתוב דינמי גלובלי.
  2. ברשת הניתוב, יוצרים רשת משנה אחת לכל אזור. בתתי-הרשתות האלה מתארחים ממשקי NVA שמשמשים לניתוב פרטי לרשתות חיצוניות, ואופציונלית, לתקשורת עם האינטרנט.
  3. יוצרים Cloud Router בכל אזור. ‫Cloud Router מטפל ב-BGP בין רשת ה-VPC לבין הרשת החיצונית באותו אזור. מומלץ ליצור NVAs ורשתות VPC של עומסי עבודה באותו אזור שבו נמצא החיבור ההיברידי, כדי לאפשר ניתוב מקומי בין החיבורים ההיברידיים לבין עומסי העבודה דרך ה-NVAs.
    • אם יוצרים מכשירי NVA ורשתות של עומסי עבודה באותו אזור, צריך רק Cloud Router אחד שייפרס באותו אזור.
    • אם יוצרים מכשירי NVA באזור אחד ורשתות VPC של עומסי עבודה באזור אחר, צריך Cloud Router בכל אחד מהאזורים האלה.

יצירת חיבורים לרשת החיצונית

בארכיטקטורה הזו מומלץ להשתמש ב-Cloud Interconnect כדי לחבר את הרשת החיצונית לרשת הניתוב של רשת VPC‏ Google Cloud . עם זאת, אפשר לבחור מוצר אחר לקישוריות. למידע נוסף, קראו את המאמר בחירת מוצרים של Network Connectivity.

הגדרת הקישוריות בין הרשתות החיצוניות (בארגון ובעננים אחרים) לבין רשת הניתוב של רשת ה-VPC. מומלץ להגדיר יעד של 99.99% SLA לעומסי עבודה של ייצור, ולפעול בהתאם לשיטות המומלצות של Google כשמקימים את החיבור.

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

יצירת רשתות VPC למעבר ולעומסי עבודה

תפקיד רשת ה-VPC המעבר הוא לחבר את מכשירי ה-NVA לרשתות ה-VPC של עומסי העבודה.

  1. בפרויקט שבו רוצים ליצור את רשת המעבר, יוצרים את רשת המעבר כרשת VPC גלובלית במצב מותאם אישית עם ניתוב דינמי גלובלי. כדי להגדיר ניתוב בין אזורים, צריך להגדיר ניתוב דינמי גלובלי.
  2. יוצרים רשת משנה אחת לכל אזור כדי לארח ממשקי NVA שמשמשים לניתוב פרטי לרשתות VPC של עומסי עבודה.
  3. מגדירים Cloud Router בכל אזור שבו מתכננים להקצות מכשירי NVA.
  4. יוצרים רשתות VPC של עומסי עבודה לפי הצורך.

יצירת מכשירי ה-NVA

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

  1. כדי לספק עמידות בכמה אזורים, כדאי לפרוס מכשירי NVA בזוגות בשני אזורים לפחות. מכיוון ש-NVA מתווספים כ-spokes של מכשיר נתב וירטואלי ב-Network Connectivity Center, לא צריך להגדיר אותם בקבוצות של מופעים.
  2. מכונות וירטואליות של NVA צריכות לפחות שני כרטיסי NIC, אבל חלק מהספקים דורשים כרטיס NIC ייעודי לניהול. מוסיפים את כרטיסי ה-NIC שנדרשים כדי לעמוד בדרישות הספק.
  3. כדי להבטיח ניתוב סימטרי דרך NVA פעיל יחיד, צריך להגדיר מדדי BGP ב-NVA, כמו MED, כדי לספק העדפות ניתוב בין NVA באזור. מומלץ להשתמש בערכי MED נמוכים, כמו 10 לחיבור הראשי ו-20 לחיבור המשני. כי Google Cloud מוסיף משקל אזורי לרשתות מרוחקות, ולכן לא צריך להגדיר ערכי MED להעדפה בין אזורים. מידע נוסף על שמירה על סימטריה של הניתוב זמין בקטע 'יכולת הרחבה' בהמשך המאמר.
  4. כדי לפרסם את טווחי רשתות המשנה של ה-VPC של עומס העבודה כנתיב סופרנט מצטבר או מסוכם, צריך להגדיר BGP ב-NIC של ה-NVA שמצורף לרשת המעבר. המסלול הזה נדרש כדי לאפשר תקשורת בין עומסי עבודה ב-VPC דרך מכשירי ה-NVA. מגדירים את מכשירי ה-NVA לפרסום של כל רשתות המשנה שגלויות ל-Cloud Router.

יצירת מרכז NCC 1

התפקיד של ה-NCC hub הראשון בעיצוב הזה הוא לאפשר פרסום דינמי של נתיבים בין חיבורים היברידיים לבין מכשירי ה-NVA. כשמגדירים את מרכז ה-NCC, מומלץ לפעול לפי ההנחיות הבאות:

  1. מגדירים את מרכז ה-NCC בטופולוגיית רשת כך שכל הרכיבים יוכלו לתקשר ישירות זה עם זה.
  2. הוספת חיבורים היברידיים (קבצים מצורפים של VLAN או VPN) לרכזת כרשתות היברידיות.
    • מפעילים העברת נתונים מאתר לאתר. מידע על מיקומים נתמכים זמין במאמר מיקומים נתמכים להעברת נתונים.
    • מפעילים את האפשרות Include export IPv4 subnet ranges from spoke to hub (הכללת ייצוא של טווחי תת-רשתות IPv4 מ-spoke ל-hub).
    • מפעילים את האפשרות Include all IPv4 ranges from hub to spoke (הכללת כל טווחי ה-IPv4 ממרכז לזרוע).
  3. מזהים את כרטיסי ה-NIC של NVA שמצורפים לרשת ה-VPC של הניתוב, ואז מוסיפים אותם למרכז NCC 1 כרכיבי נתב וירטואלי.
    • מפעילים העברת נתונים מאתר לאתר.
    • מפעילים את האפשרות Include export IPv4 subnet ranges from spoke to hub (הכללת ייצוא של טווחי תת-רשתות IPv4 מ-spoke ל-hub).
    • מפעילים את האפשרות Include all IPv4 ranges from hub to spoke (הכללת כל טווחי ה-IPv4 ממרכז לזרוע).
  4. כדי להבטיח עמידות, כשמגדירים מכשירי נתב, צריך ליצור סשנים של BGP לשני הממשקים של Cloud Router.

יצירת מרכז NCC 2

המרכז השני של NCC מאפשר פרסום דינמי של מסלולים בין ה-NVA לבין רשתות ה-VPC של עומסי העבודה. כדי לעשות את זה, מוסיפים את כרטיסי ה-NIC של NVA כ-spokes של נתב וירטואלי, ואת רשתות ה-VPC של עומס העבודה כ-spokes של VPC.

  1. מגדירים את ה-hub של NCC בטופולוגיית כוכב, כך שתעבורת הנתונים בין רשתות ה-VPC של עומסי העבודה תעבור דרך רשת ה-VPC המרכזית (ה-hub).
  2. מוסיפים NVAs כ-spokes של נתב וירטואלי לקבוצה המרכזית של ה-Hub.
    1. הפעלת העברות נתונים מאתר לאתר.
    2. מפעילים את האפשרות Include export all IPv4 ranges from spoke to hub (כולל ייצוא של כל טווחי כתובות IPv4 מ-spoke ל-hub).
    3. מפעילים את האפשרות Include import IPv4 ranges from hub to spoke (הכללת טווחי IPv4 לייבוא ממרכז לחיבור).
  3. מוסיפים לקבוצת הקצה רשתות VPC מסוג spokes של עומסי עבודה.
  4. כדי להבטיח חוסן (resilience), כשמגדירים spokes של נתב וירטואלי, צריך ליצור סשנים של BGP לשני הממשקים של Cloud Router.

הוספת גישה פרטית לממשקי API ולשירותים של Google

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

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

ניתוב ישיר לשירותי Private Service Connect (לא דרך מכשירי ה-NVA)

  1. יוצרים נקודת קצה של Private Service Connect עבור ממשקי API של Google בכל רשת VPC.
  2. יוצרים נקודת קצה של Private Service Connect לשירותים שפורסמו על ידי Google בכל רשת VPC של עומס עבודה שזקוקה לגישה לשירות.
  3. כדי לאפשר גישה מהרשת החיצונית, צריך להקצות נקודות קצה של Private Service Connect ברשת ה-VPC של הניתוב. למידע על הפעלת גישה פרטית משרתים מקומיים ל-Google APIs, אפשר לעיין במסמכי Private Service Connect.

ניתוב עקיף דרך NVA

  1. ברשת ה-VPC של הניתוב, יוצרים נקודת קצה של Private Service Connect עבור Google APIs.
  2. ברשת ה-VPC המעבר, יוצרים נקודת קצה של Private Service Connect ‏(PSC) עבור ממשקי API של Google.

  3. מגדירים את ה-DNS באופן הבא:

    1. רשתות VPC של עומסי עבודה: מגדירים את ה-DNS כך שיפתור קריאות ל-API לכתובת ה-IP של נקודת הקצה של Private Service Connect ב-VPC של הניתוב.
    2. רשתות חיצוניות: מגדירים DNS כדי לפתור קריאות API לכתובת ה-IP של נקודת הקצה (endpoint) של Private Service Connect שיצרתם ברשת ה-VPC של המעבר.

    הגישה הזו מאפשרת ל-NVA להעביר תעבורה של Google APIs.

  4. יוצרים נקודת קצה של Private Service Connect לשירותים שפורסמו על ידי Google רק בענן הווירטואלי הפרטי (VPC) של עומס העבודה שמשויך לשירות.

  5. כדי להפעיל גישה בין רשתות VPC לנקודות קצה של Private Service Connect לשירותים שפורסמו על ידי Google, צריך להפעיל הפצה של Private Service Connect ב-NCC hub 2.

הגדרה של תעבורת נתונים נכנסת (ingress) ויוצאת (egress) מרוכזת באינטרנט

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

תעבורת נתונים נכנסת (ingress) מהאינטרנט במקום מרכזי

כדי לאפשר תעבורת נתונים נכנסת מהאינטרנט, מכשירי NVA צריכים לבצע DNAT לתעבורה כשהיא מנותבת למשאב היעד ב-VPC של ה-Spoke. מידע על הגדרת תעבורת נכנסת זמין במאמר איך מגדירים מאזני עומסים של Google עם מכשירים וירטואליים ברשת (NVA) ב-Google Cloud. בהגדרה הזו, אתם מקצים את כתובת היעד המקורית למאזן העומסים של Google שמוצב בחזית של מכשירי ה-NVA. סוג מאזן העומסים שבוחרים משפיע על האופי הגלובלי של שירות ה-ingress.

תעבורת נתונים יוצאת (egress) מרכזית לאינטרנט

אם רוצים לרכז את היציאה לאינטרנט, מכשירי NVA צריכים לבצע SNAT לתנועה כשהיא מנותבת למשאב היעד באינטרנט. כדי להפנות את התנועה ממקור Google Cloud , מכשירי ה-NVA צריכים לפרסם נתיב ברירת מחדל לרשתות ה-VPC של ה-Spoke. הניתוב הזה לא דורש איזון עומסים.

בדיקת הקישוריות לעומסי עבודה

כדי לוודא שיש לכם גישה לנתוני התנועה, כדאי להשתמש ב-traceroute. כדי לבדוק את הקישוריות של התהליכים השונים, אפשר ליצור מכונות וירטואליות לבדיקה ברשתות VPC שונות.

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

שותפים ביצירת התוכן

Author: Haider Witwit | Networking Specialist Architect

תורמי תוכן אחרים: