מסלולים סטטיים

בדף הזה מוסבר איך פועלים מסלולים סטטיים ב- Google Cloud.

לסקירה כללית על מסלולים ב- Google Cloud, אפשר לעיין בסקירה הכללית על מסלולים.

שיקולים ליצירת מסלולים סטטיים

יש שתי דרכים ליצור מסלולים סטטיים:

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

פרמטרים של מסלול

מסלולים סטטיים תומכים במאפיינים הבאים:

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

  • רשת. כל מסלול צריך להיות משויך לרשת VPC אחת בלבד.

  • הצעד הבא. הניתוב הבא קובע את משאב הרשת שאליו נשלחות חבילות הנתונים. כל סוגי הקפיצות הבאות תומכים ביעדי IPv4, וחלק מסוגי הקפיצות הבאות תומכים ביעדי IPv6. מידע נוסף זמין במאמר Next hops and features.

  • טווח היעד. טווח היעד הוא סימון CIDR יחיד של IPv4 או IPv6.

    יעדים של מסלולים סטטיים צריכים לעמוד בכללים שמתוארים במאמרים אינטראקציות בין מסלולים של רשתות משנה לבין מסלולים סטטיים ואינטראקציות בין רשתות משנה לבין מסלולים סטטיים בנושא קישור בין רשתות VPC שכנות (peering). היעד הרחב ביותר האפשרי עבור נתיב סטטי של IPv4 הוא 0.0.0.0/0. היעד הרחב ביותר האפשרי לניתוב סטטי של IPv6 הוא ::/0.

  • עדיפות. מספרים נמוכים יותר מציינים עדיפות גבוהה יותר. העדיפות הגבוהה ביותר האפשרית היא 0, והעדיפות הנמוכה ביותר האפשרית היא 65,535.

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

הצעדים הבאים והתכונות

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

סוג הצעד הבא IPv4 IPv6 ECMP‏1
שער לניתוב הבא (next-hop-gateway)
מציינים שער ברירת מחדל לאינטרנט כדי להגדיר נתיב לכתובות IP חיצוניות.
מופע של הצעד הבא לפי שם ואזור (next-hop-instance)
שליחת מנות למכונה וירטואלית של הצעד הבא שמזוהה לפי שם ואזור, ונמצאת באותו פרויקט כמו המסלול. מידע נוסף זמין במאמר שיקולים לגבי מופעים של הנתב הבא.
מכונת היעד הבאה לפי כתובת (next-hop-address)
שליחת חבילות למכונה וירטואלית של היעד הבא שמזוהה לפי כתובת ה-IPv4 הפנימית הראשית, או לפי כתובת IPv6 פנימית או חיצונית, של ממשק הרשת שלה. מידע נוסף זמין במאמר שיקולים לגבי מופעים של הניתור הבא.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הניתוב הבא לפי שם כלל ההעברה (next-hop-ilb) והאזור (next-hop-ilb-region)
שליחת מנות לקצה העורפי של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי שמזוהה לפי שם כלל ההעברה, האזור והפרויקט (אופציונלי). מידע נוסף זמין במאמר שיקולים לגבי קפיצות הבאות של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הניתוב הבא לפי כתובת (next-hop-ilb)
שליחת חבילות לקצה העורפי של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי שמזוהה על ידי כתובת ה-IP של כלל ההעברה של מאזן העומסים. מידע נוסף זמין במאמר בנושא שיקולים לגבי קפיצות הבאות של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. 		2
מנהרת VPN קלאסי של הניתוב לקפיצה הבאה (next-hop-vpn-tunnel)
שליחת מנות למנהרת VPN קלאסי של הניתוב לקפיצה הבאה באמצעות ניתוב מבוסס-מדיניות או VPN מבוסס-נתיב. מידע נוסף זמין במאמר שיקולים לגבי קפיצות (hops) הבאות במנהרת VPN קלאסית.
‫1ECMP (ריבוי נתיבים בעלות שווה) פירושו ששני נתיבים סטטיים או יותר יכולים לחלוק את אותו טווח יעד ואת אותה עדיפות. אפשר ליצור שתי דרכים סטטיות או יותר ברשת VPC עם אותו יעד, אותה עדיפות וקפיצה הבאה של שער אינטרנט שמוגדר כברירת מחדל, אבל התוצאה תהיה זהה לתוצאה של דרך סטטית אחת שמשתמשת בקפיצה הבאה של שער אינטרנט שמוגדר כברירת מחדל עבור היעד והעדיפות האלה.
2התמיכה ב-IPv6 תלויה בפרויקט וברשת של הניתוב הבא.

הפרויקט והרשת של הצעד הבא

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

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

  • פרויקט: מלבד המקרים שמפורטים בטבלה הבאה, הניתוב הבא חייב להיות ממוקם בפרויקט שמכיל את רשת ה-VPC של הניתוב הבא (פרויקט עצמאי או פרויקט מארח של VPC משותף). חלק מהנקודות הבאות בנתיב יכולות להיות ממוקמות בפרויקטים של שירות VPC משותף.

סוג הצעד הבא יכול להיות ברשת VPC שמקושרת לרשתות שכנות יכול להיות ב-VPC spoke אחר של רכזת NCC יכול להיות בפרויקט שירות של VPC משותף
שער הנתבים הבא (next-hop-gateway)
המופע הבא לפי שם (next-hop-instance)
המופע הבא בנתיב לפי כתובת (next-hop-address)
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הניתוב הבא לפי שם כלל ההעברה והאזור (next-hop-ilb)
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הניתוב הבא באמצעות קישור למשאב של כלל העברה (next-hop-ilb)
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הניתוב לקפיצה הבאה לפי כתובת (next-hop-ilb) ‫
IPv4 בלבד
מנהרת VPN קלאסית של Next hop ‏ (next-hop-vpn-tunnel)

שיקולים משותפים לצעדים הבאים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ולצעדים הבאים של מאזן עומסים ברמת המופע

ניתוב מבוסס-אינסטנס מתייחס לניתוב סטטי עם קפיצה הבאה שהיא מכונה וירטואלית (next-hop-instance או next-hop-address).

מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי כצעד הבא מתייחס למסלול סטטי עם הצעד הבא שהוא מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (next-hop-ilb).

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

  • צריך להגדיר את מכונות ה-VM של הקצה העורפי או את מופע הניתוב הבא כדי להעביר מנות מכל כתובת IP של מקור. כדי להגדיר העברה, מפעילים העברת IP (can-ip-forward) לכל מכונה וירטואלית בנפרד כשיוצרים את המכונה הווירטואלית. במכונות וירטואליות שנוצרות באופן אוטומטי כחלק מקבוצת מופעי מכונה מנוהלים, צריך להפעיל העברת IP בתבנית של הגדרות מכונה שבה נעשה שימוש בקבוצת המופעים. צריך לבצע את שינוי ההגדרה הזה בנוסף לכל הגדרה של מערכת ההפעלה שנדרשת לניתוב מנות.

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

  • למכונות הווירטואליות של ה-Backend או למופע הבא בשרשרת ההפניה האוטומטית צריכים להיות כללי חומת אש מתאימים. צריך להגדיר כללים לחומת האש שחלים על המנות שמנותבות. חשוב לזכור:

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

    מידע נוסף על כללים משתמעים של חומת האש

  • אזור המקור של מנה שנשלחת על ידי מכונת VM בבק-אנד או מופע של הצעד הבא הוא האזור שבו נמצאת מכונת ה-VM בבק-אנד או המופע של הצעד הבא. לדוגמה, חבילות שעברו עיבוד במכונות וירטואליות של קצה עורפי או במופעים של הניתוב הבא ב-us-west1 יכולות להישלח ליעדים שאפשר לגשת אליהם רק ב-us-west1, גם אם המכונה הווירטואלית של הקצה העורפי או המופע של הניתוב הבא קיבלו במקור את החבילה ממשאב באזור ששונה מ-us-west1. דוגמאות למשאבים שאפשר לגשת אליהם רק באותו אזור שבו נמצאת מכונה וירטואלית ששולחת מנה:

    • מאזני עומסים פנימיים להעברת סיגנל ללא שינוי, מאזני עומסים פנימיים של אפליקציות ומאזני עומסי רשת פנימיים לשרת proxy ברמה אזורית, כשהגישה הגלובלית מושבתת
    • מנהרות Cloud VPN, קובצי מצורף של Cloud Interconnect VLAN ומכונות וירטואליות של מכשירי Network Connectivity Router אם רשת ה-VPC משתמשת בניתוב דינמי אזורי

שיקולים לגבי מכונות של הצעד הבא

  • הצעד הבא לפי שם המכונה והתחום (next-hop-instance): כשיוצרים נתיב סטטי עם מכונה לצעד הבא שמוגדרת לפי שם המכונה והתחום, Google Cloud נדרש שקיימת מכונה עם השם הזה בתחום שצוין, ושמתקיימים התנאים הבאים:

    • המופע נמצא באותו פרויקט כמו המסלול.
    • למופע יש ממשק רשת (NIC) ברשת ה-VPC של המסלול (לא ברשת VPC שכנה).

    כל עוד המסלול הסטטי קיים, התנאים הבאים חלים:

    • Google Cloud מעדכן באופן אוטומטי את התוכנה לקפיצה הבאה באחד מהמקרים הבאים:

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

    • ‫Google Cloud לא מעדכן את התוכנות לקפיצה הבאה במקרים הבאים:

      • כשמוחקים את המכונה.
      • טווח כתובות ה-IPv6 שהוקצה לכרטיס הרשת של המכונה משתנה.
      • כשכתובת ה-IPv4 או ה-IPv6 של המכונה לא מוקצית.

  • כתובת ה-IP של מופע הניתוב הבא (next-hop-address): כתובות ה-IP התקפות של מכונות VM לניתוב הבא הן:

    • כתובת ה-IPv4 הפנימית הראשית של ממשק רשת של מכונה וירטואלית.
    • כל כתובת IPv6 פנימית או חיצונית בטווח כתובות IPv6‏ /96 שהוקצה לממשק רשת של מכונה וירטואלית.

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

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

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

  • מכונות וירטואליות של next hop בפרויקטים של שירות VPC משותף: כשמציינים מכונה וירטואלית של next hop לפי כתובת IP, המכונה הווירטואלית יכולה להיות ממוקמת בפרויקט שבו נמצא המסלול (פרויקט עצמאי או פרויקט מארח של VPC משותף) או בפרויקט של שירות VPC משותף. כשמציינים מכונה וירטואלית של קפיצה הבאה לפי שם המכונה והאזור, המכונה הווירטואלית של הקפיצה הבאה צריכה להיות ממוקמת באותו פרויקט כמו המסלול ורשת ה-VPC (פרויקט עצמאי או פרויקט מארח של VPC משותף).

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

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

  • אין גיבוב סימטרי כשמחברים בין שתי רשתות VPC: ‫Google Cloud לא מוצע גיבוב סימטרי כשמשתמשים בשתי מכונות וירטואליות או יותר של next hop שיש להן כמה ממשקי רשת בתצורה שעומדת בכל הקריטריונים הבאים:

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

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

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

    • יש לכם את המסלולים ואת מצבי מכונות ה-VM הבאים:

      • ‫route-a, יעד 192.168.168.0/24, עדיפות 10, המכונה הווירטואלית (VM) של הנתב הבא vm-a נעצרת
      • ‫route-b, יעד 192.168.168.0/24, עדיפות 20, מכונת ה-VM של הנתב הבא vm-b פועלת
      • ‫route-c, יעד 192.168.168.0/24, עדיפות 30, מכונת ה-VM של הנתב הבא vm-c פועלת

      בדוגמה הזו, מנות שהיעדים שלהן מתאימים ל-192.168.168.0/24 נשלחות ל-vm-b הדילוג הבא כי vm-a הדילוג הבא של העדיפות הגבוהה ביותר route-a לא פועל. זה קורה כי השלב של התעלמות מנתיבים סטטיים ודינמיים עם קפיצות לא שמישות קודם לשלב של התעלמות מנתיבים בעדיפות נמוכה בסדר הניתובGoogle Cloud .

    • יש לכם את המסלולים ואת מצבי מכונות ה-VM הבאים:

      • ‫route-x, יעד 192.168.168.0/24, עדיפות 10, המכונה הווירטואלית (VM) של הנתב הבא vm-x נעצרת
      • ‫route-y, יעד 192.168.168.0/24, עדיפות 20, המכונה הווירטואלית (VM) של הנתב הבא vm-y נעצרת
      • ‫route-z, יעד 192.168.0.0/16, עדיפות 0, הניתוב הבא המכונה הווירטואלית vm-z פועלת

      בדוגמה הזו, מנות שהיעדים שלהן מתאימים ל-192.168.168.0/24 נפסלות כי מכונות ה-VM של הניתוב לקפיצה הבאה בשני המסלולים 192.168.168.0/24 (route-x ו-route-y) לא פועלות, למרות שקיים מסלול ליעד הרחב יותר 192.168.0.0/16 (route-z) עם מכונת VM פעילה לקפיצה הבאה. זה קורה כי השלב של היעד הספציפי ביותר קודם לשלב של התעלמות ממסלולים סטטיים ודינמיים עם קפיצות לא שמישות בסדר הניתובGoogle Cloud .

שיקולים לגבי קפיצות (hops) הבאות במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי

  • כללי העברה נתמכים. Google Cloud תומך רק בכללי העברה של מאזן עומסי רשת פנימי מסוג Network Load Balancer עם העברה פנימית של נתונים לניתוב הבא. Google Cloud לא תומך בכללי העברה של ניתוב הבא שמשמשים מאזני עומסים אחרים, העברת פרוטוקולים או נקודות קצה של Private Service Connect.

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

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

    • לפי שם כלל ההעברה (--next-hop-ilb) והאזור (--next-hop-ilb-region): כשמציינים כלל העברה של קפיצה הבאה לפי שם ואזור, הרשת של כלל ההעברה צריכה להיות זהה לרשת ה-VPC של המסלול. כלל ההעברה צריך להיות באותו פרויקט שבו נמצאת הרשת של כלל ההעברה (פרויקט עצמאי או פרויקט מארח של VPC משותף).

    • לפי קישור למשאב של כלל העברה: קישור למשאב של כלל העברה משתמש בפורמט /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, כאשר PROJECT_ID הוא מזהה הפרויקט של הפרויקט שמכיל את כלל ההעברה, REGION הוא האזור של כלל ההעברה ו-FORWARDING_RULE_NAME הוא השם של כלל ההעברה. כשמציינים כלל להעברת נתונים לניתוב הבא באמצעות קישור המשאב שלו, רשת הניתוב של כלל העברת הנתונים צריכה להיות זהה לרשת ה-VPC של המסלול. כלל ההעברה יכול להיות ממוקם בפרויקט שמכיל את הרשת של כלל ההעברה (פרויקט עצמאי או פרויקט מארח של VPC משותף) או בפרויקט שירות של VPC משותף.

    • לפי כתובת IP של כלל העברה: כשמציינים כלל העברה של הצעד הבא לפי כתובת IPv4 או IPv6, רשת ה-VPC של כלל העברה יכולה להיות או רשת ה-VPC של המסלול או רשת VPC שמחוברת לרשת ה-VPC של המסלול באמצעות קישור בין רשתות שכנות (peering) או NCC. ‫NCC תומך במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (passthrough) ב-VPC spoke, בכפוף לדרישות הקישוריות של NCC. כלל ההעברה יכול להיות ממוקם בפרויקט שמכיל את הרשת של כלל ההעברה (פרויקט עצמאי או פרויקט מארח של VPC משותף) או בפרויקט שירות של VPC משותף.

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

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

  • אין תמיכה בכללי העברה שמשתמשים בכתובת IP פנימית משותפת (--purpose=SHARED_LOADBALANCER_VIP). מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי של קפיצה הבאה וכללי העברה של מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי שמשתמשים בכתובת IP משותפת כדי להפנות לשירותים שונים בעורף (מאזני עומסי רשת פנימיים שונים להעברת סיגנל ללא שינוי) הם תכונות שאי אפשר להשתמש בהן בו-זמנית. מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הצעד הבא חייב להשתמש בכתובת IP ייחודית לכלל ההעברה של מאזן העומסים, כדי שרק שירות לקצה העורפי אחד (מאזן עומסים אחד) יקבל הפניה חד-משמעית. תעבורת נתונים שנשלחת למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מהסוג הבא (next-hop) שהוגדר עם כתובת IP משותפת, מבוטלת ללא הודעה.

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

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

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

שיקולים לגבי קפיצות (next hop) במנהרת VPN קלאסי

  • עלויות וחביון (latency) של אזור לאזור: Google Cloud לא מתייחס למרחק האזורי של נתיבים שמשתמשים במנהרת VPN קלאסי של קפיצה הבאה. שליחת תנועה למנהרת VPN קלאסית של הניתוב הבא באזור אחר מוסיפה עלויות של העברת נתונים יוצאת וגורמת להשהיית רשת. השיטה המומלצת היא להשתמש במנהרת HA VPN עם ניתוב דינמי במקום זאת, כי ההגדרה הזו מתחשבת במרחק האזורי.

  • התנהגות כשמנהרות VPN קלאסיות לא פועלות: מסלולים סטטיים מותאמים אישית שהקפיצות הבאות שלהם הן מנהרות VPN קלאסיות לא מוסרים באופן אוטומטי כשמנהרות VPN קלאסיות לא פועלות. פרטים על מה שקורה כשמנהרות לא פועלות זמינים במאמר When tunnels are down במסמכי התיעוד של VPN קלאסי.

שיקולים לגבי NCC

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

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