מידע על מעבר אל Cloud de Confiance by S3NS עם Hybrid Subnets

בדף הזה מוסבר איך אפשר להשתמש בניתוב היברידי של רשתות משנה כדי להעביר עומסי עבודה אל Cloud de Confiance.

ניתוב היברידי של רשתות משנה מאפשר לרשת VPC לשתף בלוק CIDR עם רשת מקומית מחוברת. אם חבילת נתונים תואמת לנתיב של רשת משנה היברידית, אבל כתובת ה-IP של היעד לא משויכת למשאב ברשת המשנה הזו,Cloud de Confiance יכולה לנתב את החבילה לרשת המקומית באמצעות נתיבים דינמיים או סטטיים.

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

כדי לבצע מיגרציה אל Cloud de Confiance by S3NS עם Hybrid Subnets, צריך שלושה רכיבים נפרדים שפועלים יחד:

  • קישוריות: הרשתות המקומיות ורשתות ה-VPC צריכות להיות מחוברות באמצעות מוצר לקישוריות רשת כמו Cloud VPN או Cloud Interconnect. Hybrid Subnets לא מספקות את הקישוריות הזו בעצמן.
  • ניתוב היברידי של תת-רשתות: צריך להפעיל ניתוב היברידי של תת-רשתות על ידי החלת הדגל allow-cidr-routes-overlap על משאב של תת-רשת.
  • כלי להעברה: צריך כלי להעברה כמו Migrate to Virtual Machines כדי להעביר עומסי עבודה אל Cloud de Confiance.
תרשים עם שלושה שלבים שמראה איך מעבירים עומסי עבודה משרתים מקומיים אל Cloud de Confiance באמצעות רשתות משנה היברידיות.
איור 1. במהלך ההעברה, ניתוב היברידי של רשתות משנה מאפשר לעומסי עבודה ברשת מקומית לתקשר עם עומסי עבודה ברשת VPC מחוברת באמצעות כתובות IP פנימיות, גם אם רשתות המשנה בשתי הרשתות משתמשות באותו בלוק CIDR (אפשר ללחוץ כדי להגדיל).

מפרטים

כדי להגדיר Hybrid Subnets לתמיכה בהעברת עומסי עבודה אלCloud de Confiance מרשת מקומית, הסביבה שלכם צריכה לעמוד בדרישות הבאות.

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

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

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

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

ניתוב ברשת VPC

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

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

  • משאבים תואמים: אם יעד החבילה תואם לממשק הרשת של מכונה וירטואלית פעילה או לכלל העברה פנימי ברשת המשנה, Cloud de Confiance החבילה מועברת לממשק או לכלל ההעברה. ההתנהגות הזו זהה להתנהגות ברשת משנה רגילה.
  • משאבים לא תואמים: אם יעד החבילה לא תואם למשאב ברשת המשנה, Cloud de Confiance מתבצע התהליך של משאבים לא תואמים ברשתות משנה היברידיות. התהליך הזה מכוון מנות לצעדים הבאים של מסלולים סטטיים או דינמיים מקומיים או של peering, כל עוד יש להם צעדים הבאים באותו אזור כמו תת-הרשת ההיברידית. המסלולים הסטטיים או הדינמיים של הרשת המקומית או של רשת הפירינג מספקים נתיב למסירת החבילה לרשת המקומית.
בתת-רשת שבה מופעל ניתוב היברידי של תת-רשתות, מנות A מנותבות באופן מקומי, ומנות B מנותבות ליעד מקומי.
איור 3. בתת-רשת שמשתמשת בניתוב היברידי של תת-רשתות, אם היעד של מנה (packet) תואם למשאב בתת-הרשת, Cloud de Confiance מנתב את התנועה למשאב הזה. אם אין משאבים תואמים, Cloud de Confiance משתמש במשאבים לא תואמים בתהליך של תת-רשתות היברידיות (לחצו להגדלה). Cloud de Confiance

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

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

בקטע הזה מתוארת התנהגות הניתוב ברשת מקומית. בדוגמה הזו, הרשת המקומית מחוברת לרשת VPC באמצעות מנהרות Cloud VPN.

כשמכונה וירטואלית של לקוח ברשת המקומית שולחת מנה למכונה וירטואלית של שרת שנמצאת בבלוק ה-CIDR שמשותף לשתי הרשתות, הנתב של הרשת המקומית או המכשיר הראשון בנתיב מבצעים חיפוש בטבלת הניתוב:

  • אם המכונה הווירטואלית של השרת משויכת לכתובת IP ברשת המקומית, הנתב המקומי לא מתערב ב-proxy ARP. המכונה הווירטואלית של השרת משיבה לחבילות ARP‏ who-has מהמכונה הווירטואלית של הלקוח בתשובות שמכילות את כתובת ה-MAC של השרת. המכונה הווירטואלית של הלקוח שולחת פריים של Ethernet למכונה הווירטואלית של השרת.

  • אם המכונה הווירטואלית של השרת לא משויכת לכתובת IP ברשת המקומית, והנתב המקומי קיבל פרסום של מסלול מותאם אישית ספציפי מהפעלות ה-BGP של Cloud Router במנהרות Cloud VPN ברשת ה-VPC, הנתב המקומי מתערב באמצעות proxy ARP. הנתב המקומי משיב לחבילות ARP‏ who-has ממכונת הלקוח הווירטואלית בתגובות שמכילות את כתובת ה-MAC של הנתב. המכונה הווירטואלית של הלקוח שולחת מסגרת אתרנט לנתב המקומי, והנתב המקומי מחלץ את מנת ה-IP ומעביר אותה לאחת ממנהרות Cloud VPN. החבילה מועברת למכונה הווירטואלית בתת-הרשת שבה מופעל ניתוב היברידי של תת-רשתות.

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

מגבלות

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

  • ניהול כתובות IP ותעבורה נתמכת:

    • ‫IPv6: ‏Hybrid Subnets לא תומך בתנועת IPv6.

    • שידור ו-multicast: Hybrid Subnets לא תומכות בתעבורת נתונים של שידור ו-multicast.

    • קונפליקטים של כתובות IP: Hybrid Subnets לא מזהות קונפליקטים של כתובות IP בין משאבים ברשת המקומית לבין רשת ה-VPC שמכילה את תת-הרשת שבה מופעל ניתוב של תת-רשת היברידית. מוודאים שכל כתובת IP, למעט שער ברירת המחדל, נמצאת בשימוש רק פעם אחת.

    • כתובות שלא ניתן להשתמש בהן: אי אפשר להשתמש בשתי כתובות ה-IPv4 הראשונות ובשתי כתובות ה-IPv4 האחרונות בטווח כתובות ה-IPv4 הראשי של רשת משנה (subnet) לכל משאב Cloud de Confiance . הכלל הזה נשאר בתוקף גם אם מפעילים ניתוב היברידי של רשתות משנה. למידע נוסף, ראו כתובות שלא ניתן להשתמש בהן בטווחים של רשתות משנה ב-IPv4.

  • אזורים לא תואמים: מנות נתונים מושמטות אם הצעד הבא במסלול סטטי או דינמי תואם בטווח היעד של מסלול תת-רשת היברידי תואם נמצא באזור ששונה מהאזור של תת-הרשת. מידע נוסף זמין במאמר בנושא מגבלות אזוריות.

  • מסלולים סטטיים עם תגי רשת: מוודאים שכל מסלול סטטי תואם בטווח היעד של מסלול תת-הרשת ההיברידי התואם לא משתמש בתגי רשת. התאמה של מסלולים סטטיים שמשתמשים בתגי רשת גורמת לאובדן חבילות כשיש שיעורי חבילות גבוהים.

  • אינטראקציות עם מוצרים שלא נתמכות: אל תשתמשו ב-Hybrid Subnets עם הפריטים הבאים.

    • ‫Network Connectivity Center (NCC): ‏ NCC לא תומך ברשתות משנה היברידיות. Cloud de Confiance‏ לא נמנע מכם לייצא רשתות משנה שמופעל בהן ניתוב של רשתות משנה היברידיות למרכז NCC, אבל פעולה כזו עלולה לגרום להתנהגות ניתוב בלתי צפויה.

    • קבוצות NEG עם קישוריות היברידית: מערכות בדיקת תקינות של Google לבדיקות תקינות מרכזיות לא יכולות לתקשר עם נקודות קצה בקבוצת NEG עם קישוריות היברידית אם נקודות הקצה מתאימות למסלול של רשת משנה היברידית.

    • ‫Hybrid NAT: לא ניתן להשתמש ב-Hybrid NAT עם Hybrid Subnets. ‫NAT היברידי לא מבצע NAT של מקור (SNAT) על מנות שנשלחות ממכונות וירטואליות ליעדים במסלול סטטי או דינמי, אם קודם נמצא התאמה למסלול של רשת משנה היברידית.

חשוב לזכור גם את המגבלות המעשיות הבאות.

  • הרשת המקומית צריכה לתמוך ב-proxy ARP: תת-רשתות היברידיות לא תומכות בהעברת עומסי עבודה מרשתות מרוחקות אצל ספקי שירותי ענן אחרים, כמו Azure או AWS, כי הרשתות המרוחקות האלה לא תומכות ב-proxy ARP.

  • הרשת המקומית צריכה לקבל /32פרסומים של נתיבים: אם אתם משתמשים ב-Partner Interconnect בשכבה 3, צריך לבדוק עם השותף אם הוא תומך בקבלת /32קידומות.

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

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

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

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

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

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

בקטעים הבאים מתוארים שיקולים לשימוש בתכונה 'רשתות משנה היברידיות' להעברת עומסי עבודה אל Cloud de Confiance.

Proxy ARP ו-Hybrid Subnets

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

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

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

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

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

ההגבלה הזו חלה כשתעבורת הנתונים תואמת לנתיב של רשת משנה היברידית, אבל כתובת ה-IP של היעד לא משויכת למכונה וירטואלית פעילה או לכלל העברה פנימי. במהלך השלב unmatched resources in hybrid subnets במודל לבחירת מסלולים של Cloud de Confiance, המסלולים מוערכים כאילו המקור של החבילה נמצא באותה רשת VPC כמו המסלול של תת-הרשת ההיברידית.

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

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

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

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

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

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

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

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

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

אפשר לקשר בין רשת VPC שמכילה רשת משנה שמשתמשת בניתוב היברידי של רשתות משנה לבין רשת VPC שכנה באמצעות קישור בין רשתות VPC שכנות (peering).

תעבורת נתונים מלקוחות ברשת מקושרת יכולה להגיע ליעדים בתוך בלוק ה-CIDR המשותף, בלי קשר לשאלה אם היעדים הם משאביCloud de Confiance או ברשת המקומית. אם לחבילה מלקוח ברשת המקושרת יש יעד שתואם למסלול היברידי של רשת משנה מקושרת, והיעד לא תואם למכונה וירטואלית פעילה או לכלל העברת נתונים פנימי, אפשר לנתב את החבילה באמצעות מסלול סטטי או דינמי ברשת ה-VPC המקושרת.

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

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

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

ביצועי הרשת

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

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

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

Firewalls and Hybrid Subnets

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

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

תמחור

למידע על התמחור של Hybrid Subnets, ראו תמחור של ענן וירטואלי פרטי (VPC).

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