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

בדף הזה מוסבר איך פועלים מסלולים סטטיים ב- 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 ECMP1
שער הצעד הבא (next-hop-gateway)
מציינים שער ברירת מחדל באינטרנט כדי להגדיר נתיב לכתובות IP חיצוניות.
מכונת הצעד הבא לפי שם ואזור (next-hop-instance)
שליחת מנות למכונה וירטואלית של הצעד הבא שמזוהה לפי שם ואזור, ונמצאת באותו פרויקט כמו המסלול. מידע נוסף זמין במאמר שיקולים לגבי מופעים של קפיצה הבאה.
מכונה של הצעד הבא לפי כתובת (next-hop-address)
שליחת חבילות למכונה וירטואלית של הצעד הבא שמזוהה לפי כתובת IPv4 פנימית ראשית, או כתובת IPv6 פנימית או חיצונית, של ממשק הרשת שלה. מידע נוסף זמין במאמר שיקולים לגבי מופעים של next hop.
הקפיצה הבאה היא מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לפי שם כלל ההעברה (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).

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

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

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

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

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

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

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

    • מאזני עומסים פנימיים להעברת סיגנל ללא שינוי, מאזני עומסים פנימיים של אפליקציות ומאזני עומסים אזוריים פנימיים לשרת proxy עם גישה גלובלית מושבתת
    • מנהרות Cloud VPN, קבצים מצורפים של VLAN ב-Cloud Interconnect ומכונות וירטואליות של מכשירי 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 של הצעד הבא במסלול סטטי (שמצוינת לפי שם ואזור או לפי כתובת פנימית). אם מכונה וירטואלית של הנתב הבא לא פועלת, הניתוב תלוי בשאלה אם קיימים מסלולים אחרים לאותו יעד בדיוק, ובשאלה אם במסלולים האחרים האלה יש נתבים הבאים שפועלים. כדי להמחיש את ההתנהגות הזו, הנה כמה דוגמאות:

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

      • ‫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 .

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

      • ‫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 נפסלות כי המכונות הווירטואליות של הצעד הבא בשני המסלולים 192.168.168.0/24 (route-x ו-route-y) לא פועלות, למרות שקיים מסלול ליעד הרחב יותר 192.168.0.0/16 (route-z) עם מכונה וירטואלית של הצעד הבא שפועלת. זה קורה כי השלב של היעד הספציפי ביותר קודם לשלב של התעלמות ממסלולים סטטיים ודינמיים עם קפיצות לא שמישות בGoogle Cloud סדר הניתוב.

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

  • כללי העברה נתמכים.‏ Google Cloud תומך רק בכללי העברה של מאזן עומסי רשת פנימי מסוג Network Load Balancer עם העברה ישירה של נתונים (passthrough) לניתוב לקפיצה הבאה. 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) בין רשתות VPC שכנות או NCC. ‫NCC תומך במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי של הנתונים כקפיצה הבאה ברשת VPC מסוג Spoke, בכפוף לדרישות של NCC לקישוריות. כלל ההעברה יכול להיות ממוקם בפרויקט שמכיל את הרשת של כלל ההעברה (פרויקט עצמאי או פרויקט מארח של VPC משותף) או בפרויקט שירות של VPC משותף.

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

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

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

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

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

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

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

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

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

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

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