שיטות מומלצות לשימוש ברשת

בדף הזה מפורטות שיטות מומלצות לשימוש ברשת ב-Google Cloud VMware Engine.

איך מונעים בעיות בקביעת מסלול

התקשורת בתוך VMware Engine ועם שאר האינטרנט מנותבת בשכבה 3, למעט רשתות שמועברות מהתשתית המקומית או מעננים פרטיים אחרים של VMware Engine.

כדי למנוע בעיות בהגדרה, ובביצועים או במגבלות כשמגדירים ניתוב אל סביבת VMware Engine וממנה, מומלץ לפעול לפי השיטות המומלצות הבאות:

  • מגדירים את Cloud Router שמשויך לחיבור Cloud VPN או Cloud Interconnect בענן היברידי מקומי עם פרסומים מותאמים אישית של טווחי VMware Engine וטווחי שירותי מחשוב אחרים של Google, כמו Google Kubernetes Engine ו-Compute Engine.
  • משתמשים במרחב כתובות IP רציף עבור רשתות משנה של פלח NSX.

  • כדי לצמצם את מספר המסלולים שמוכרזים לשאר חלקי Google, מסכמים את מסלולי פלח NSX ברמה 0 באופן הבא:

    • אם נדרש NAT, צריך לסכם את כתובות ה-IP של NAT מחוץ לרמה 0 ולא מתוך /32.
    • סיכום של כתובות ה-IP של נקודות הקצה של IPsec ‏ (/32) ברמה 0.
    • סיכום של כתובות ה-IP בפרופיל ה-DNS (כתובות /32) ברמה 0.

  • מפעילים את NSX-T DHCP Relay בהתאם למיקום של שירותי ה-DHCP – ב-VMware Engine או במקום אחר.

  • כשמפיצים מחדש מסלולים סטטיים ברמה 0 ל-BGP, צריך להחיל מפת מסלולים כדי למנוע הפצה מחדש של 0/0.

בחירת אפשרות מתאימה לגישה לאינטרנט

ב-VMware Engine יש את האפשרויות הבאות להגדרת גישה לאינטרנט וכתובות IP ציבוריות. כדי לבחור את האפשרות המתאימה ביותר, כדאי לעיין בטבלה הבאה ולשקול את היתרונות והחסרונות של כל אחת מהאפשרויות:

אפשרות גישה לאינטרנט היתרונות חסרונות
שירות האינטרנט וכתובות ה-IP הציבוריות של VMware Engine
  • לא כרוך בחיובים נוספים. כלול בעלות של שירות VMware Engine.
  • קל להגדיר אותו.
  • האם יש גיבוי של הסכם רמת השירות.
  • יש לו הגדרה קבועה.
  • אין תמיכה ב-BYOIP.
  • יש לה מכסת נתונים ורוחב פס מוגבלים, ולכן היא מתאימה יותר ל-PoC או לפריסות קטנות.
  • לא מספק נראות של מדדי תעבורה נכנסת/יוצאת.
  • האפשרות הזו בלעדית לשתי האפשרויות האחרות.
  • נדרשים מכשירים של צד שלישי כדי להשתמש בניהול תנועה מתקדם (כמו בדיקת חומת אש ברמה 7 או איזון עומסים מורכב).
  • לא תומך ב-Application Level Gateway‏ (ALG).
העברת נתונים דרך קצה האינטרנט של ה-VPC של הלקוח
  • יש לו הגדרה שניתנת להרחבה.
  • תמיכה ב-BYOIP.
  • מספק ניראות מלאה ומעקב.
  • אפשר לשלב אותו עם בדיקה ברמה 7, איזון עומסים מתקדם ומוצרים של צד שלישי.
  • אפשר לשלב אותו עם מאזני עומסים מקוריים של Google ועם Cloud Service Mesh.
  • אפשר לשלב אותו עם Google Cloud Armor כדי לקבל הגנה מפני מתקפות DDoS.
  • נדרשת הגדרה מורכבת יותר.
  • אין הסכם רמת שירות (SLA) לשירות המשולב.
העברת נתונים דרך חיבורים מקומיים
  • השימוש בהגדרות קיימות.
  • ריכוז האבטחה ואיזון העומסים בפריסה מקומית.
  • מאפשר את מספר השינויים הקטן ביותר.
  • מציע תמיכה גלובלית מוגבלת.
  • יכול להיות שחלק מעומסי העבודה יתחלקו בין שירותי אינטרנט שונים.

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

הטמעה של שרשור שירותים באמצעות מכשירי רשת וירטואלית של צד שלישי

‫VMware Engine תומך בשרשור של שירותי רשת באמצעות טופולוגיות של ניתוב בשכבה 3. במצב הזה, אתם יכולים לפרוס ולחבר מכשיר וירטואלי של צד שלישי ב-VMware Engine כדי לספק שירותי רשת מוטמעים למכונות וירטואליות של VMware, כמו איזון עומסים, חומת אש מהדור הבא (NGFW) וזיהוי ומניעה של פריצות. אפשר לפרוס את המכשירים האלה בכמה דרכים, בהתאם לדרישות הפילוח והקישוריות של האפליקציות.

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

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

מאחורי שער ברמה 1

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

הדיאגרמה הבאה מציגה איך שער ברמה 1 פועל ב-VMware Engine:

מכשיר צד שלישי משמש כשער ברירת המחדל לכמה רשתות בסביבה.

כדי להטמיע את הטופולוגיה הזו:

  1. מגדירים נתיבים סטטיים ברמה 1 שיפנו למכונה הווירטואלית של ה-Appliance ויאפשרו גישה לרשתות שמאחוריה.
  2. ברמה 0, מבצעים הפצה מחדש של מסלולים סטטיים ברמה 1 ל-BGP.
  3. בנוגע לתמיכה בניתוב בין רשתות VLAN של אורחים, עומסי עבודה (workloads) של אורחים ב-VMware מוגבלים ל-10 כרטיסי רשת וירטואליים. במקרים מסוימים, צריך להתחבר ליותר מ-10 רשתות VLAN כדי ליצור את פילוח חומת האש הנדרש. במקרה כזה, אפשר להשתמש בתיוג של VLAN כדי להעביר את הנתונים לספק התוכנה העצמאי. צריך להתאים את הגודל של המכונות הווירטואליות של ספקי תוכנה עצמאיים (ISV) כדי לתמוך בתנועה ולהפיץ אותה בין כמה קבוצות של מכשירי ISV לפי הצורך.

מאחורי שער ברמה 0

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

הדיאגרמה הבאה מציגה כיצד שער ברמה 0 פועל ב-VMware Engine:

למכשיר של צד שלישי יש שער אחד או יותר ברמה 1 מאחוריו.

כדי להטמיע את הטופולוגיה הזו:

  1. מגדירים נתיב סטטי שמוגדר כברירת מחדל בכל שער Tier-1 שמפנה אל ה-NGFW.
  2. מגדירים מסלולים סטטיים כדי להגיע לפלחי עומס עבודה ברמה 0 עם NGFW בתור הצעד הבא.
  3. להפיץ מחדש את המסלולים הסטטיים האלה ל-BGP באמצעות מפת מסלולים כדי למנוע הפצה מחדש של 0/0.

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