שכבת-על של NSX וניתוב קצה (edge routing)

פתרון VMware ב- Google Cloud משתמש ב-VMware NSX כדי לספק שירותי Networking מוגדרי-תוכנה (SDN) ואבטחה למכונות הווירטואליות (VMs) של עומסי העבודה ב-VMware Cloud Foundation ‏(VCF). במסמך הזה מוסבר איך רשת שכבת-העל של NSX פועלת עם שכבת הבסיס שלGoogle Cloud הענן הווירטואלי הפרטי (VPC), ומשווה בין ארכיטקטורות הניתוב של צומתי NSX Edge לבין רשת ה-VPC.

סקירה כללית של NSX ב- Google Cloud

בפתרון VMware, רשת ה-VPC Google Cloud מספקת את התשתית הפיזית והווירטואלית למארחי ה-ESXi ללא מערכת הפעלה (מכונות Compute Engine z3-highmem-192-highlssd-metal) ולמכשירי הניהול. ‫VMware NSX נמצא מעל שכבת הבסיס הזו כדי לספק הטופולוגיה של הרשת מופשטת למכונות הווירטואליות של עומסי העבודה ב-VCF:

  • Geneve overlay encapsulation: מארחי ESXi וצומתי NSX Edge יוצרים ממשקי Transport Endpoint ‏ (TEP) (vmk10 או vmk3) ברשת המשנה הייעודית של NSX-TEP VPC. תעבורת הנתונים של המכונות הווירטואליות של עומסי העבודה נארזת בחבילות Geneve (יציאת UDP‏ 6081) ומנותבת בין נקודות הקצה של מנהרות המארחים דרך רשת ה-VPC הבסיסית של Google Cloud, באמצעות יחידת שידור מקסימלית (MTU) של 8896 בייטים.
  • כתובות IP מנותקות: מכונות וירטואליות של עומסי עבודה שמחוברות למקטעי שכבת-על של NSX יכולות להשתמש בטווחים שרירותיים של כתובות IP, בלי לצרוך כתובות IP מתת-הרשתות של ה-VPC ב- Google Cloud או לחרוג ממכסות ה-IP של תת-הרשתות של ה-VPC.
  • ארכיטקטורת ניתוב בכמה רמות:
    • שערי Tier-1 (T1)‎: מספקים ניתוב מזרח-מערב בין מקטעי שכבת-על, שירותי DHCP מקומיים וכללי חומת אש של שערים.
    • שערים ברמה 0 (T0): מספקים ניתוב צפון-דרום בין סביבת שכבת-העל של NSX לבין רשת ה-VPC הבסיסית של Google Cloud .
  • אבטחה מבוזרת: חומת האש המבוזרת (DFW) של NSX אוכפת כללי מדיניות של מיקרו-סגמנטציה עם שמירת מצב (stateful) ישירות בכרטיס הרשת הווירטואלי (vNIC) של כל מכונה וירטואלית של עומס עבודה, בלי קשר למקטע שכבת-העל או למארח ESXi שבהם נמצאת המכונה הווירטואלית.

טופולוגיית שכבת בסיס לעומת טופולוגיית שכבת-על

ארכיטקטורת הרשת מחולקת לשתי שכבות נפרדות – שכבת הבסיס של ה- Google Cloud VPC ושכבת העל של VMware NSX – כפי שמוצג בתרשים הבא (לחצו להגדלה):

 ‫Google Cloud VPC underlay hosting Z3 instances and VCF appliances below the VMware NSX overlay.  ‫Google Cloud VPC underlay hosting Z3 instances and VCF appliances below the VMware NSX overlay.

בטבלה הבאה מפורטים הרכיבים ותחומי האחריות של כל שכבת רשת:

שכבת רשת הרכיבים העיקריים תחומי האחריות
Google Cloud VPC underlay
  • מארחי ESXi פיזיים (ממשקי NIC ראשיים וממשקי NIC דינמיים)
  • ניהול VCF מכונות וירטואליות (vCenter Server, ‏ SDDC Manager, ‏ NSX Manager cluster, VMware HCX)
  • רשתות משנה של VPC‏ (Management, vSAN, vMotion, NSX-TEP, NSX-Uplink)
  • מאזני עומסים פנימיים אזוריים ומכשירי נתב של Network Connectivity Center
  • מספקת נגישות IP בין יציאות VMkernel של מארח ESXi
  • מארח מכשירים של מישור הבקרה של VCF ישירות ברשתות משנה של VPC
  • מעביר חבילות Geneve מוכמסות בין TEP של מארח ESXi לבין TEP של NSX Edge
  • חיבור בין הרשתות המקומיות, רשתות ה-VPC המקושרות ושירותיGoogle Cloud
שכבת-על של NSX SDN
  • אשכולות NSX Edge (נתבים לוגיים ברמה 0 וברמה 1)
  • מקטעי שכבת-על של NSX
  • מכונות וירטואליות של עומסי עבודה
  • NSX Distributed Firewall (DFW) and Gateway Firewall
  • מספקת דומיינים מבודדים של שכבה 2 וניתוב מזרח-מערב למכונות וירטואליות של עומסי עבודה
  • מפרסם את בלוקי ה-CIDR של עומסי העבודה לשכבת הבסיס של ה-VPC דרך שערי Tier-0
  • מספק איזון עומסים, NAT ואבטחה בקצה הצפוני-דרומי

תרחישי שימוש מתקדמים בארכיטקטורה

אתם יכולים לבנות את הטופולוגיות של NSX ו-VPC כך שיתמכו בדרישות שונות של בידוד ושל ריבוי דיירים:

  • דומיינים מאוחדים של עומסי עבודה ב-VPC יחיד: פריסה של דומיין הניהול של VCF ודומיין אחד או יותר של עומסי עבודה של VI בתוךGoogle Cloud רשת VPC אחת. כל דומיין של עומס עבודה משתמש בתת-רשתות ייעודיות של vSAN,‏ vMotion ו-NSX-TEP באותו VPC, תוך שיתוף או בידוד של אשכולות NSX Edge לניתוב צפון-דרום.
  • מיפויים של כמה רשתות VPC: חיבור של שערים נפרדים של NSX Tier-0 או אשכולות נפרדים של NSX Edge לרשתות VPC מבודדות של Google Cloud (לדוגמה, רשתות VPC נפרדות לעומסי עבודה בסביבת ייצור, רשתות היקפיות ושירותים משותפים). הטופולוגיה הזו שומרת על גבולות מחמירים של חומת אש וניתוב ברמת ה-VPC ב- Google Cloud , תוך שמירה על ניהול מרכזי של מחזור החיים של VCF.

ניתוב NSX Edge

כדי לנתב תנועה בין מקטעי שכבת-העל של NSX לבין רשת ה-VPC של Google Cloud , מכונות וירטואליות של NSX Edge צריכות להחליף מסלולים או להעביר חבילות דרך רשת המשנה של NSX-Uplink VPC. כדי להגדיר ניתוב צפון-דרום בין שערי NSX Tier-0 לבין רשת ה-VPC, אתם יכולים להשתמש באחת מהאפשרויות הבאות:

אפשרות 1: ניתוב סטטי של VPC (פעיל-המתנה)

בטופולוגיית ניתוב סטטית, זוג צומתי NSX Edge במצב פעיל-המתנה משתמש בכתובת IP וירטואלית (VIP) צפה ברשת המשנה של NSX-Uplink ב-VPC, שמאחורי מאזן עומסי רשת אזורי פנימי עם העברה (pass-through), כמו שמוצג בתרשים הבא (לחצו להגדלה):

נתיבים סטטיים של VPC שמפנים את תנועת הנתונים של שכבת העל של NSX דרך מאזן עומסים פנימי לצומתי NSX Edge פעילים במצב המתנה. נתיבים סטטיים של VPC שמפנים את תנועת הנתונים של שכבת-העל של NSX דרך מאזן עומסים פנימי לצומתי NSX Edge במצב פעיל-המתנה.

  • מנגנון ניתוב: אתם יוצרים מסלולים סטטיים בהתאמה אישית בטבלת המסלולים שלGoogle Cloud VPC, שמציינים את בלוקי ה-CIDR של עומסי העבודה בשכבת-העל של NSX כיעד, ואת ה-VIP הצף של NSX Edge (או כלל העברה של מאזן עומסים פנימי) בתור הצעד הבא.
  • זמינות גבוהה: כשמשתמשים בשירות קצה עורפי פנימי אזורי עם מדיניות הזמינות הגבוהה של GARP_RA (או העברה של טווח כתובות IP חלופיות), תעבורת הנתונים מופנית אוטומטית לצומת NSX Edge במצב המתנה אם צומת Edge הפעיל נכשל.
  • תרחיש לדוגמה: מתאים במיוחד לפריסות קטנות יותר או לטופולוגיות שכבת-על סטטיות שבהן בלוקי ה-CIDR של עומס העבודה לא משתנים לעיתים קרובות, ורוחב הפס של קצה יחיד עומד בדרישות שלכם לגבי תפוקה.

אפשרות 2: ניתוב BGP דינמי באמצעות מכשיר נתב של Network Connectivity Center (פעיל-פעיל)

כדי להגדיר החלפת מסלולים דינמית ושינוי אופקי של רוחב הפס, משתמשים בקישור בין רשתות שכנות (peering) של Border Gateway Protocol ‏(BGP) בין שער NSX Tier-0 לבין Cloud Router באמצעות מכשיר הנתב של Network Connectivity Center, כמו שמוצג בתרשים הבא (לחצו כדי להגדיל):

קישור בין רשתות שכנות (peering) של Cloud Router דרך BGP עם נתבים וירטואליים של NSX Edge שמוצמדים למארחי Z3 באמצעות כללי זיקה של DRS. קישור בין רשתות שכנות (peering) של Cloud Router דרך BGP עם נתבים וירטואליים של NSX Edge שמוצמדים למארחי Z3 באמצעות כללי זיקה של DRS.

  • החלפת מסלולים דינמית: שער NSX Tier-0 מפרסם באופן אוטומטי בלוקים של CIDR של מקטעי שכבת-על של NSX שנוצרו לאחרונה ב-Cloud Router דרך BGP, ולומד מסלולי VPC ומסלולים מקומיים (0.0.0.0/0 או קידומות ספציפיות) באמצעות פרסומי מסלולים בהתאמה אישית. בארכיטקטורה הזו אין צורך לעדכן ידנית את הנתיבים הסטטיים של ה-VPC.
  • Active-active ECMP scaling: תמיכה בניתוב Equal-Cost Multi-Path (ECMP)‎ בעד שמונה צומתי NSX Edge פעילים לכל שער Tier-0, הרחבת הקיבולת מצפון לדרום ותמיכה ביתירות כשל באמצעות Bidirectional Forwarding Detection (BFD).
  • דרישת הצמדה של Edge למארח: מכיוון שמכונה וירטואלית של NSX Edge פועלת בתוך מארח ESXi, ממשק ה-uplink הווירטואלי שלה ממפה ל-NIC דינמי ספציפי במכונה הבסיסית של Compute Engine ללא מערכת הפעלה. כדי לוודא ש-Cloud Router מעביר את תעבורת הנתונים של BGP ומישור הנתונים למארח ה-bare-metal המדויק שבו נמצא כל VM של NSX Edge, צריך להגדיר כללי זיקה של VMware Distributed Resource Scheduler (DRS) (כללי זיקה של VM-Host) כדי להצמיד כל VM של NSX Edge למארח ה-ESXi הייעודי שלו.
  • סשנים מיותרים של BGP: מגדירים סשנים כפולים של BGP בין כל ממשקי ה-uplink של צומת NSX Edge ברשת המשנה NSX-Uplink לבין ממשקים מיותרים של Cloud Router, כדי לשמור על זמינות רציפה של מישור הבקרה במהלך אירועי תחזוקה של המארח.

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