מידע על מעבר אל Google Cloud עם Hybrid Subnets

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

בנוסף, Hybrid Subnets תומכות בהעברת מכונות וירטואליות מ- Google Cloudלרשת מקומית או בין שתי רשתות VPC.

תרשים בן שלושה שלבים שממחיש העברת עומסי עבודה מ-on-premises אל Google Cloud באמצעות Hybrid Subnets.
איור 1. במהלך ההעברה, רשת משנה היברידית מספקת קישוריות בין עומסי עבודה ברשת מקור לבין רשת VPC (אפשר ללחוץ כדי להגדיל).

מפרטים

אלו המפרטים של Hybrid Subnets.

  • מאפיינים:
    • רשת משנה היברידית היא רשת משנה לוגית יחידה שמשלבת קטע של רשת מקור עם רשת משנה ברשת VPC.
    • הקישוריות הפנימית נשמרת בין כל המכונות הווירטואליות ועומסי העבודה ברשת משנה היברידית.
    • רשת המקור יכולה להיות רשת מקומית או רשת VPC אחרת. הפלח יכול להיות רשת משנה שלמה או חלק מרשת משנה.
    • שני החלקים של רשת משנה היברידית צריכים להיות מחוברים באמצעות מוצר לקישוריות רשת, כמו Cloud VPN או Cloud Interconnect.
    • טווח כתובות ה-IPv4 הראשי של רשת המשנה ב-VPC צריך להיות זהה לטווח של פלח רשת המקור שמשמש את רשת המשנה ההיברידית.
  • הגדרת רשת VPC:
    • כדי להגדיר תת-רשת של VPC כחלק מתת-רשת היברידית, צריך להפעיל ניתוב של תת-רשת היברידית. כשניתוח מסלולים של רשתות משנה היברידי מופעל, יכול להיות שיהיה ניגוד (חפיפה) בין מסלולים מותאמים אישית לבין טווחי כתובות ה-IPv4 הראשיות והמשניות של רשתות משנה.
    • אתם משתמשים במסלולים מותאמים אישית שמוכרזים ב-Cloud Router כדי להכריז באופן סלקטיבי על כתובות ה-IP של מכונות וירטואליות כשאתם מעבירים אותן לרשת המשנה של ה-VPC. כדי לתמוך ב-Proxy ARP ובחיפוש התאמה של הקידומת הארוכה ביותר, המסלולים האלה צריכים להיות ספציפיים יותר (להיות בעלי מסכה של רשת משנה ארוכה יותר) מטווח כתובות ה-IP של תת-הרשת ההיברידית. אפשר להשתמש ב/32 מסלולים למכונות וירטואליות ספציפיות.
  • הגדרת רשת המקור:
    • צריך להגדיר proxy ARP ברשת המקור.
    • צריך להגדיר את רשת המקור כך שתפרסם את טווח כתובות ה-IP של תת-הרשת ההיברידית.
Cloud Router ונתב מקומי מטפלים בניתוב בין שני החלקים של רשת משנה היברידית שמשתמשת בטווח כתובות IP משותף וחופף.
איור 2. בתרשים הזה מוצגת סקירה כללית של השלבים ליצירת תת-רשת היברידית, ואיך Cloud Router ונתב מקומי מעבירים מנות בין שני החלקים של תת-רשת היברידית (אפשר ללחוץ כדי להגדיל).

ניתוב של תת-רשתות היברידיות

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

ניתוב ברשת VPC

במהלך השלב של התאמת מסלולי subnet במודל הניתוב של VPC, אם היעד של חבילת נתונים תואם למסלול subnet מקומי או למסלול subnet של קישור (peering),‏ Google Cloud מנסה להעביר את חבילת הנתונים באמצעות מסלול ה-subnet התואם. ברשת משנה רגילה, אם היעד לא משויך למכונה וירטואלית פעילה או לכלל העברת תעבורה פנימית, המנה מבוטלת וכל המסלולים האחרים מתעלמים ממנה.

עם זאת, אם הניתוב של רשתות משנה היברידיות מופעל ברשת המשנה, נתיב רשת המשנה הופך לנתיב רשת משנה היברידית, והתנהגות הניתוב שונה:

  • אם החבילה משויכת למכונה וירטואלית שפועלת או לכלל העברת נתונים פנימי בתת-רשת של ה-VPC, Google Cloud החבילה מועברת על סמך הנתיב של תת-הרשת ההיברידית המקומית.
  • אם המנה לא משויכת למכונה וירטואלית פעילה או לכלל העברת נתונים פנימי ברשת המשנה של ה-VPC, Google Cloud מתבצע תהליך ניתוב מיוחד למשאבים לא תואמים. התהליך הזה כולל בדיקה של מסלולים דינמיים וסטטיים מותאמים אישית שחופפים לטווח של רשת המשנה ההיברידית. ברשת משנה היברידית שהוגדרה בצורה נכונה, חבילות הנתונים מנותבות לרשת המקור באמצעות נתיב מקומי דינמי ש-Cloud Router לומד לגבי רשת המשנה של המקור.
בתת-רשת היברידית, מנות A מנותבות באופן מקומי, ומנות B מנותבות ליעד מקומי.
איור 3. מכונות וירטואליות בתת-רשת היברידית יכולות להגיע ליעדים בתת-רשת מקומית ובתת-רשת של רשת VPC, גם אם לשתי תת-הרשתות יש טווח חופף של כתובות IP (אפשר ללחוץ כדי להגדיל).

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

ניתוב רשת המקור

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

אם היעד משויך לעומס עבודה ברשת המקור, הנתב לא מתערב ב-proxy ARP. היעד מקבל את בקשת ה-ARP ומגיב עם כתובת ה-MAC שלו, והמנה מועברת באופן מקומי.

אם היעד נמצא בחלק ה-VPC של רשת המשנה ההיברידית, והנתב למד מסלול דינמי ליעד שהוא ספציפי יותר מהמסלול של רשת המשנה המקומית, הנתב בוחר את המסלול הדינמי באמצעות התאמה של הקידומת הארוכה ביותר. הפעולה הזו מפעילה את הפונקציונליות של פרוטוקול proxy ARP בנתב. הנתב מגיב עם כתובת ה-MAC שלו ומנתב את החבילה ל-Cloud Router ברשת ה-VPC.

נתב מקומי משתמש ב-proxy ARP כדי לנתב חבילת נתונים מעומס עבודה ברשת מקור למכונה וירטואלית שהועברה אל Google Cloud.
איור 4. נתב מקומי משתמש ב-proxy ARP כדי לנתב חבילת נתונים מעומס עבודה ברשת מקור למכונה וירטואלית שהועברה אל Google Cloud(לחיצה להגדלה).

מגבלות

יש כמה מגבלות ל-Hybrid Subnets.

  • מגבלות על משאבים:

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

  • תנועה ומסלולים שלא נתמכים:

    • מנות נמחקות אם הניתוב הבא של מסלול מתנגש נמצא באזור שונה מרשת המשנה ההיברידית.
    • סוגי המסלולים הבאים לא נתמכים כמסלולים סותרים:
      • מסלולי ברירת מחדל שנוצרו על ידי המערכת
      • מסלולים מבוססי-מדיניות
      • מסלולים סטטיים עם תגי רשת
      • מסלולים עם יעדים שמכילים את מסלול רשת המשנה ההיברידית או רחבים ממנו
    • אין תמיכה מלאה ב-NCC ברשתות משנה היברידיות. אפשר להגדיר רשת VPC שמכילה רשת משנה היברידית כרשת מסוג Spoke של מרכז NCC. עם זאת, התנהגות הניתוב של תנועה מ-spokes מחוברים לטווח כתובות ה-IP של רשת המשנה ההיברידית היא בלתי צפויה.
    • אין תמיכה ב-NAT היברידי עם רשתות משנה היברידיות. אפשר להגדיר תת-רשת היברידית לשימוש ב-NAT היברידי, אבל התכונה לא חלה על תנועה שמושפעת מניתוב של תת-רשת היברידית.
    • ניתוב היברידי של תת-רשתות לא חל על תעבורת IPv6.
    • אין תמיכה בתעבורת נתונים של שידור ושידור מרובה בתוך רשת משנה היברידית.
    • אי אפשר להשתמש בחיבורי Partner Interconnect בשכבה 3 שלא תומכים בהכרזה על מסלולי /32 עם Hybrid Subnets.
    • ב-Cloud Router של רשת משנה היברידית, מספר המסלולים המותאמים אישית שניתן לפרסם לא יכול לחרוג מהמספר המקסימלי של מסלולים מותאמים אישית שניתן לפרסם לכל סשן BGP.
    • עומסי עבודה ברשת המקור לא יכולים להגיע לשירותים ולממשקי API של Google באמצעות גישה פרטית ל-Google.
    • עומסי עבודה ברשת המקור לא יכולים להגיע לנקודות קצה של Private Service Connect עבור ממשקי API של Google.

  • תרחישי העברה שלא נתמכים:

  • מגבלות אחרות:

    • התכונה Hybrid Subnets לא מזהה התנגשויות בין כתובות IP ברשת המקור לבין חלקי ה-VPC של תת-רשת היברידית. מוודאים שכל כתובת IP (חוץ משער ברירת המחדל) נמצאת בשימוש רק פעם אחת.
    • אי אפשר לארח עומסי עבודה ב-Hybrid Subnets בכתובות IP שמורות ברשתות משנה של IPv4.
    • עומסי עבודה ברשת המקור לא יכולים להיות נקודות קצה לקבוצות נקודות קצה של רשת קישוריות היברידית שמשתמשות בבדיקות תקינות מרכזיות.
    • העברת תעבורה נכנסת ב-Cloud DNS לא מגיבה לבקשות DNS מעומסי עבודה ברשת המקור.

אפשרויות העברה

‫Google ממליצה להשתמש ב-Migrate to Virtual Machines עם Hybrid Subnets כדי להפוך את תהליך ההעברה של מכונות וירטואליות ממקור VMware או ממקור Google Cloud VMware Engine לאוטומטי.

לחלופין, אפשר להשתמש בכלי העברה של צד שלישי עם Hybrid Subnets, כל עוד מתקיימות הדרישות של Hybrid Subnets שמתוארות במסמך הזה.

מידע על תכנון העברה באמצעות Migrate to Virtual Machines זמין במאמר תהליך ההעברה באמצעות Migrate to VMs.

מידע נוסף על אפשרויות העברה זמין במאמר משאבים להעברה.

כדי לקבל תמיכה בתכנון העברה אל Google Cloud באמצעות Hybrid Subnets, יש לפתוח בקשת תמיכה.

שיקולים לשימוש ב-Hybrid Subnets

בקטעים הבאים מתוארים שיקולים לשימוש ב-Hybrid Subnets.

Proxy ARP ו-Hybrid Subnets

Hybrid Subnets דורש proxy ARP שיוגדר בנתב של רשת המקור או במכשיר הראשון בנתיב (הנקודה שבה מארח שולח לראשונה תעבורת נתונים שיש לה יעד מחוץ לרשת המקומית שלו).

המכשיר הראשון יכול להיות נתב, מכשיר וירטואלי, חומת אש או מכונה וירטואלית שמופעל בה פתרון תוכנה כמו choparp.

כדי להשתמש ב-proxy ARP ברשת המקור, מומלץ לבצע את הפעולות הבאות:

  • כדאי להתייעץ עם ספק רשת המקור לגבי שיטות מומלצות שקשורות להפעלת פרוקסי ARP ולאבטחת סביבת הרשת.
  • אחרי שמסיימים את המיגרציה אלGoogle Cloud, צריך להשבית את פרוקסי ARP.

מגבלת מיקוד לפי אזורים

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

אם במסלול מתחרה יש נקודות קפיצה לאזור אחר:

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

חשוב לוודא שמקורות המידע הבאים נמצאים באותו אזור:

  • תת-רשת ה-VPC שמוגדרת כתת-רשת היברידית
  • ‫Cloud Router שלומד מסלולים לרשת המקור
  • מנהרות HA VPN או צירופים ל-VLAN שמספקים קישוריות היברידית

לדוגמה, נניח שיש תת-רשת היברידית עם טווח כתובות ה-IP 192.0.2.0/24. תת-הרשת של ה-VPC נמצאת באזור us-central1. ה-Cloud Router למד שני מסלולים סותרים:

  • מסלול מותאם אישית עם טווח יעד של 192.0.2.0/25 וניתוב לקפיצה הבאה באזור us-central1
  • מסלול מותאם אישית עם טווח יעד 192.0.2.0/30 וקפיצה הבאה באזור us-west1.

חבילת נתונים נשלחת ליעד 192.0.2.2. כתובת ה-IP הזו לא משויכת למכונה וירטואלית פעילה או לכלל העברה פנימי ברשת המשנה של ה-VPC, ולכן מודל בחירת המסלול בוחר את המסלול המותאם אישית עם היעד הספציפי ביותר, שהוא 192.0.2.0/30. למסלול הזה אין קפיצה הבאה באזור של רשת המשנה ההיברידית, ולכן המנה נפסלת.

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

קישור בין רשתות VPC שכנות (peering)

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

אחרי שרשת ה-VPC המקושרת מתכנתת את המסלולים, היא יכולה להגיע ליעדים בטווח כתובות ה-IP של רשת המשנה ההיברידית, בלי קשר לשאלה אם הם קיימים ב Google Cloud או ברשת המקור.

המסלולים לא יתוכנתו לרשת הפירינג במקרים הבאים:

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

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

ביצועי הרשת

Hybrid Subnets משתמשות בשכבה 3 של מודל OSI כדי לנתב חבילות נתונים בין רשת המקור לבין חלקי ה-VPC של תת-רשת היברידית. הגישה הזו עוזרת ל-Hybrid Subnets להימנע מבעיות של זמן אחזור, רעידות ותפוקה שיכולות לקרות במהלך מיגרציות, כשחלק מעומסי העבודה נמצאים ברשת מקורית וחלק אחר עבר לענן.

בפרט, הימנעות ממנהור בשכבה 2 עוזרת למנוע את הירידה בביצועים שקשורה לאנקפסולציה ולהצפנה של שכבת-על נוספת בשכבה 2. בנוסף, ניתוב בשכבה 3 מאפשר ל-Hybrid Subnets להימנע מבעיה נפוצה במנהור בשכבה 2, שבה התנועה נשלחת לצומת מרכזי לפני שהיא מגיעה ליעדים שיכולים להיות קרובים לנקודת המוצא של התנועה. הבעיה הזו נקראת לפעמים network tromboning.

הגישה של Hybrid Subnets לניתוב פירושה שניתן לצפות לביצועים מרשת משנה היברידית שדומים לביצועים של רשת שלא משתמשת ב-Hybrid Subnets, או זהים להם.

Firewalls and Hybrid Subnets

Hybrid Subnets מאפשרות להימנע מבעיות שקשורות לשימוש בחומות אש עם תנועה שעוברת אנקפסולציה בשכבות-על של שכבה 2. בתעבורה בשכבה 2, חומות אש יכולות לבדוק חבילות רק בנקודות הקצה של שכבת העל או מעבר להן, אלא אם נוקטים אמצעים ספציפיים כמו פענוח שקוף או בדיקות מעמיקות של תעבורת שכבת העל.

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

תמחור

אין חיוב נוסף על שימוש ב-Hybrid Subnets. עם זאת, אתם מחויבים על משאבים ותנועה ברשת בחלק ה-VPC של תת-רשת היברידית.

מידע נוסף מופיע במאמר בנושא תמחור של ענן וירטואלי פרטי.

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