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 כדי להתחבר למרכז (hub) מספר 1 של Network Connectivity Center ‏(NCC) כרשתות היברידיות מסוג spoke.

ניתוב רשת VPC

רשת ה-VPC של הניתוב מתחברת לרשתות חיצוניות באמצעות Cloud Interconnect או Cloud VPN. הוא מתחבר לרשת ה-VPC של התנועה החולפת באמצעות מכשירי NVA עם כמה כרטיסי רשת.

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

רשת VPC למעבר

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

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

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

NVAs

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

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

NCC hub 1

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

המרכז מוגדר בטופולוגיית רשת שכוללת את הסוגים הבאים של רשתות היברידיות מסוג Hub and Spoke: רשתות מסוג Router appliance, רשתות מסוג Cloud VPN ורשתות מסוג Cloud Interconnect VLAN attachment.

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

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

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

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

NCC hub 2

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

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

  • הממשקים של NVA ברשת ה-VPC של ה-Transit מוגדרים כ-Spokes של נתב וירטואלי בקבוצת Center Spoke.
  • רשתות ה-VPC של עומסי העבודה מוגדרות כרשתות Spoke של VPC בקבוצת Spoke של קצה.

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

תנועות תנועה

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

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

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

דיאגרמה שמוצגים בה תהליכי עבודה של מעבר לגיבוי (failover) מאזור א' לאזור ב'.

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

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

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

  • רשת חיצונית אל רשת VPC של עומס העבודה
    • תעבורת הנתונים עוברת במסלולים דרך חיבורי Cloud Interconnect לרשת VPC. המסלולים מוכרזים על ידי Cloud Router ל-NVA דרך רכזת Network Connectivity Center.
    • ברשת VPC לניתוב, התנועה מנותבת ל-NIC של ה-NVA הפעיל באמצעות מסלולים דינמיים שנלמדו מה-NVA. התנועה עוברת דרך ה-NVA ל-NIC השני שלו, שמעביר את התנועה לרשת ה-VPC של ה-transit. התעבורה עוברת במסלולים דרך קישורי 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 הוא ה-hop הבא. התנועה עוברת במסלולים שנלמדו ממרכז NCC 2, ויוצאת דרך אותו NIC ועוברת דרך הקישור בין רשתות NCC לרשת ה-VPC של עומס העבודה השני.

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

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

דיאגרמה שמוצגים בה תהליכי מעבר לגיבוי (failover) מאזור א' לאזור ב'.

במצב של כשל מוחלט בכל מכשירי ה-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 | Customer Engineer

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