סקירה כללית של קבוצות נקודות קצה ברשת לקישוריות היברידית

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

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

הגדרה של איזון עומסים היברידי מאפשרת לכם ליהנות מהיתרונות של יכולות הרשת של Cloud Load Balancing בשירותים שפועלים בתשתית הקיימת שלכם מחוץ ל- Cloud de Confiance.

יש תמיכה באיזון עומסים היברידי במאזני העומסים הבאים Cloud de Confiance by S3NS :

שירותים מקומיים ושירותי ענן אחרים נחשבים כמו כל שרת קצה עורפי אחר של Cloud Load Balancing. ההבדל העיקרי הוא שמשתמשים בNEG עם קישוריות היברידית כדי להגדיר את נקודות הקצה של השרתים העורפיים האלה. נקודות הקצה צריכות להיות שילובים תקפים של IP:port שמאזן העומסים יכול להגיע אליהם באמצעות מוצרי קישוריות היברידית כמו Cloud VPN,‏ Cloud Interconnect או מכונות וירטואליות של מכשיר נתב.

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

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

לקוחות ציבוריים

אתם יכולים להשתמש במאזן עומסים של אפליקציות (ALB) חיצוני עם קצה עורפי של NEG היברידי כדי לנתב תעבורת נתונים מלקוחות חיצוניים לקצה עורפי מקומי או ברשת ענן אחרת. אתם יכולים גם להפעיל את היכולות הבאות של רשתות בעלות ערך מוסף עבור השירותים שלכם ברשתות מקומיות או ברשתות ענן אחרות:

  • באמצעות מאזן עומסים חיצוני אזורי של אפליקציות (ALB), אתם יכולים לנתב תעבורה חיצונית לנקודות קצה שנמצאות באותו אזור Cloud de Confiance שבו נמצאים המשאבים של מאזן העומסים. משתמשים במאזן העומסים הזה אם רוצים להציג תוכן ממיקום גיאוגרפי אחד בלבד (לדוגמה, כדי לעמוד בדרישות של תקנות תאימות) או אם רוצים להשתמש ברמת השירות הרגילה של רשת.

האופן שבו הבקשה מנותבת (אם היא מנותבת ל Cloud de Confiance קצה עורפי או לנקודת קצה מקומית או בענן) תלוי בהגדרות של מפת URL. בהתאם למיפוי כתובות ה-URL, מאזן העומסים בוחר שירות לקצה העורפי עבור הבקשה. אם שירות ה-Backend שנבחר הוגדר עם NEG של קישוריות היברידית (שמשמש רק לנקודות קצה שאינןCloud de Confiance ), מאזן העומסים מעביר את התנועה דרך Cloud VPN,‏ Cloud Interconnect או מכונות וירטואליות של Router appliance ליעד החיצוני המיועד.

לקוחות פנימיים (בתוך Cloud de Confiance או בפריסה מקומית)

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

מאזן עומסים פנימי אזורי של אפליקציות (ALB) הוא מאזן עומסים אזורי, כלומר הוא יכול להפנות תעבורה רק לנקודות קצה באותו אזור Cloud de Confiance שבו נמצאים המשאבים של מאזן העומסים.

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

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

תרחיש לדוגמה: מעבר לענן

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

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

ארכיטקטורה היברידית

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

שירותים מקומיים ושירותי ענן אחרים הם כמו כל שרת קצה עורפי אחר של Cloud Load Balancing. ההבדל העיקרי הוא שמשתמשים בNEG עם קישוריות היברידית כדי להגדיר את נקודות הקצה של השרתים העורפיים האלה. נקודות הקצה צריכות להיות שילובים תקפים של IP:port שהלקוחות יכולים להגיע אליהם באמצעות קישוריות היברידית, כמו Cloud VPN,‏ Cloud Interconnect או מכשיר Router VM.

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

HTTP(S) חיצוני אזורי

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

HTTP(S) פנימי אזורי

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

שרת proxy פנימי אזורי

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

ניתוב ב-Cloud Load Balancing

הניתוב ב-Cloud Load Balancing תלוי בהיקף של מאזן העומסים שהוגדר:

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

לדוגמה, אם שער Cloud VPN או קובץ ה-VLAN המצורף של Cloud Interconnect מוגדרים באזור REGION_A, המשאבים שנדרשים למאזן העומסים (כמו שירות קצה עורפי, NEG היברידי או כלל העברה) חייבים להיווצר באזור REGION_A. כברירת מחדל, לקוחות שניגשים למאזן העומסים חייבים להיות גם באזור REGION_A.

דרישות לקישוריות לרשת

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

  • Cloud de Confiance רשת VPC. רשת VPC שהוגדרה בתוך Cloud de Confiance. זו רשת ה-VPC שמשמשת להגדרת Cloud Interconnect/Cloud VPN ו-Cloud Router. זו גם אותה רשת שבה תיצרו את משאבי איזון העומסים (כלל העברה, שרת proxy ליעד, שירות קצה עורפי וכו'). כתובות IP וטווחים של כתובות IP ברשת מקומית, בענן אחר וברשת משנה לא יכולים להיות חופפים. Cloud de Confiance כשכתובות ה-IP חופפות, נתיבי רשתות המשנה מקבלים עדיפות על פני קישוריות מרוחקת.

  • קישוריות היברידית. הסביבות שלכם ב- Cloud de Confiance ובסביבות מקומיות או בסביבות ענן אחרות צריכות להיות מחוברות באמצעות קישוריות היברידית, באמצעות קבצים מצורפים של Cloud Interconnect VLAN, מנהרות Cloud VPN עם Cloud Router או מכונות וירטואליות של מכשירי נתב. מומלץ להשתמש בחיבור עם זמינות גבוהה. נתב Cloud Router שמופעל בו ניתוב דינמי גלובלי לומד על נקודת הקצה הספציפית באמצעות BGP ומתכנת אותה ברשתCloud de Confiance VPC. ניתוב דינמי אזורי לא אפשרי. אין תמיכה גם בנתיבים סטטיים.

    ה-Cloud Router צריך גם לפרסם את המסלולים הבאים לסביבה המקומית:

    • הטווחים שבהם משתמשים הגשושים של בדיקת תקינות ב-Google הם 35.191.0.0/16 ו-130.211.0.0/22.

    • הטווח של רשת המשנה של ה-proxy בלבד באזור: למאזני עומסים מבוססי Envoy – מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), מאזני עומסים פנימיים אזוריים של אפליקציות (ALB), מאזני עומסי רשת חיצוניים אזוריים לשרת proxy, ומאזני עומסי רשת פנימיים אזוריים לשרת proxy.

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

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

    • אם אתם משתמשים ברשתות VPC שונות, שתי הרשתות צריכות להיות מחוברות באמצעות VPC Network Peering או להיות רשתות מסוג spoke ב-VPC באותו מרכז NCC.

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

  • נקודות קצה ברשת (IP:Port) מקומיות או בעננים אחרים. נקודת קצה אחת או יותר ברשת IP:Port שמוגדרות בסביבות מקומיות או בסביבות ענן אחרות, שאפשר לנתב באמצעות Cloud Interconnect, ‏ Cloud VPN או מכשיר נתב וירטואלי. אם יש כמה נתיבים לנקודת הקצה של כתובת ה-IP, הניתוב יתבצע בהתאם להתנהגות שמתוארת בסקירה הכללית על נתיבי VPC ובסקירה הכללית על Cloud Router.

  • כללים של חומת האש ברשת המקומית או בענן אחר. צריך ליצור את כללי חומת האש הבאים בסביבה המקומית או בסביבת ענן אחרת:

    • כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) כדי לאפשר לתעבורה מהבדיקות של Google לבדיקת תקינות להגיע לנקודות הקצה שלכם. הטווחים שיוגדרו כמאושרים הם: 35.191.0.0/16 ו-130.211.0.0/22. חשוב לזכור שצריך לפרסם את טווחי הכתובות האלה גם על ידי Cloud Router ברשת המקומית. פרטים נוספים זמינים במאמר בנושא טווחים של כתובות IP של בדיקות וכללים של חומת אש.
    • כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) כדי לאפשר לתעבורת נתונים שמתבצעת בה איזון עומסים להגיע לנקודות הקצה.
    • במאזני עומסים מבוססי Envoy – מאזני עומסים חיצוניים אזוריים של אפליקציות, מאזני עומסים פנימיים אזוריים של אפליקציות, מאזני עומסי רשת חיצוניים אזוריים של proxy, ומאזני עומסי רשת פנימיים אזוריים של proxy – צריך גם ליצור כלל חומת אש כדי לאפשר לתעבורת נתונים מרשת המשנה לשרת proxy בלבד באזור להגיע לנקודות הקצה שנמצאות בפריסה מקומית או בסביבות ענן אחרות.

רכיבים של מאזן עומסים

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

הגדרות הקצה הקדמי

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

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

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

שירות לקצה העורפי

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

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

  • שרתי קצה עורפיים שאינםCloud de Confiance (במקום או בענן אחר)

    כל יעד שאפשר להגיע אליו באמצעות מוצרי הקישוריות ההיברידית של Google (Cloud VPN,‏ Cloud Interconnect או מכונות וירטואליות של מכשירי נתב), ואפשר להגיע אליו באמצעות שילוב IP:Port תקין, יכול להיות מוגדר כנקודת קצה למאזן העומסים.

    מגדירים את הקצה העורפי שאינוCloud de Confiance באופן הבא:

    1. מוסיפים כל שילוב שלCloud de Confiance נקודת קצה שאינה ברשתIP:Port אל קבוצה של נקודות קצה ברשת (NEG) לקישוריות היברידית. מוודאים שאפשר להגיע לכתובת ה-IP ולפורט האלה מ- Cloud de Confiance באמצעות קישוריות היברידית (דרך Cloud VPN,‏ Cloud Interconnect או מכונות VM של מכשיר נתב). ב-NEGs של קישוריות היברידית, מגדירים את סוג נקודת הקצה ברשת לערך NON_GCP_PRIVATE_IP_PORT.
    2. במהלך יצירת ה-NEG, מציינים Cloud de Confiance אזור שממזער את המרחק הגיאוגרפי בין Cloud de Confiance לבין הסביבה המקומית או סביבת ענן אחרת. לדוגמה, אם אתם מארחים שירות בסביבה מקומית בפרנקפורט, גרמניה, אתם יכולים לציין את אזור europe-west3-a Cloud de Confiance כשאתם יוצרים את ה-NEG.

    3. מוסיפים את ה-NEG של הקישוריות ההיברידית כקצה עורפי לשירות הקצה העורפי.

      ‫NEG עם קישוריות היברידית יכול לכלול רק נקודות קצה שאינןCloud de Confiance. יכול להיות שתעבורת הנתונים תיחסם אם קבוצת נקודות קצה היברידית (NEG) כוללת נקודות קצה למשאבים ב Cloud de Confiance רשת VPC, כמו כתובות IP של כללי העברה למאזני עומסים פנימיים מסוג Network Load Balancer. מגדירים את נקודות הקצה לפי ההוראות שמפורטות בקטע הבא. Cloud de Confiance

  • Cloud de Confiance backends

    מגדירים את נקודות הקצה Cloud de Confiance באופן הבא:

    1. יוצרים שירות קצה עורפי נפרד עבור הקצה העורפי של Cloud de Confiance .
    2. מגדירים כמה קצוות עורפיים (או GCE_VM_IP_PORT NEGs אזוריים או קבוצות של מכונות וירטואליות) באותו אזור שבו הגדרתם קישוריות היברידית.

נקודות נוספות שכדאי לקחת בחשבון:

  • כל NEG קישוריות היברידית יכול להכיל רק נקודות קצה (endpoint) ברשת מאותו סוג (NON_GCP_PRIVATE_IP_PORT).

  • אפשר להשתמש בשירות קצה עורפי יחיד כדי להפנות גם לקצוות עורפיים מבוססי-Cloud de Confiance(באמצעות NEGs אזוריים עם נקודות קצה של GCE_VM_IP_PORT) וגם לקצוות עורפיים מקומיים או בענן אחר (באמצעות NEGs של קישוריות היברידית עם נקודות קצה של NON_GCP_PRIVATE_IP_PORT). אסור להשתמש בשילובים אחרים של סוגי קצה עורפי מעורבים.

  • סכמת איזון העומסים של שירות הקצה העורפי היא INTERNAL_MANAGED עבור מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של רשתות לשרת proxy.

  • פרוטוקול השירות לקצה העורפי חייב להיות אחד מהפרוטוקולים HTTP,‏ HTTPS או HTTP2 במאזני עומסים של אפליקציות, ואחד מהפרוטוקולים TCP או SSL במאזני עומסים של רשת בשרת proxy. במאמר פרוטוקולים ממאזן העומסים לקצה העורפי מפורטת רשימת הפרוטוקולים של שירותים לקצה העורפי שנתמכים על ידי כל מאזן עומסים.

  • מצב האיזון של הקצה העורפי של ה-NEG ההיברידי צריך להיות RATE למאזני עומסים של אפליקציות ו-CONNECTION למאזני עומסי רשת של שרת proxy. פרטים על מצבי איזון זמינים במאמר סקירה כללית על שירותי קצה עורפי.

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

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

בדיקות תקינות מבוזרות של Envoy

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

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

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

בדיקות תקינות מבוזרות של Envoy נוצרות באמצעות אותם תהליכים של מסוףCloud de Confiance , ה-CLI של gcloud ו-API כמו בדיקות תקינות מרכזיות. לא נדרשת הגדרה נוספת.

נקודות חשובות:

  • אין תמיכה בבדיקות תקינות של gRPC.
  • אין תמיכה בבדיקות תקינות עם פרוטוקול PROXY גרסה 1 מופעל.
  • אם אתם משתמשים ב-NEGs מעורבים שבהם לשירות קצה עורפי יחיד יש שילוב של NEGs אזוריים (נקודות קצה של GCE_VM_IP_PORT בתוךCloud de Confiance) ו-NEGs היברידיים (נקודות קצה של NON_GCP_PRIVATE_IP_PORT מחוץ ל- Cloud de Confiance), אתם צריכים להגדיר כללי חומת אש כדי לאפשר תנועה מטווח כתובות ה-IP של בדיקות תקינות של Google (130.211.0.0/22 ו-35.191.0.0/16) לנקודות הקצה של ה-NEG האזורי ב-Cloud de Confiance. הסיבה לכך היא שקבוצות NEGs אזוריות משתמשות במערכת המרכזית של Google לבדיקת תקינות.

  • מישור הנתונים של Envoy מטפל בבדיקות תקינות, ולכן אי אפשר להשתמש בCloud de Confiance מסוף, ב-API או ב-CLI של gcloud כדי לבדוק את סטטוס התקינות של נקודות הקצה החיצוניות האלה. ב-NEGs היברידיים עם מאזני עומסים מבוססי Envoy, במסוף מוצג סטטוס בדיקת התקינות כ- Cloud de Confiance N/A. זה תקין.

  • כל שרת Envoy proxy שמוקצה לרשת המשנה proxy-only באזור ברשת ה-VPC מתחיל בדיקות תקינות באופן עצמאי. לכן, יכול להיות שתראו עלייה בתעבורת הנתונים ברשת בגלל בדיקות תקינות. העלייה תלויה במספר שרתי ה-proxy של Envoy שהוקצו לרשת ה-VPC באזור, בכמות התנועה שמתקבלת בשרתי ה-proxy האלה ובמספר נקודות הקצה שכל שרת proxy של Envoy צריך לבצע בדיקת תקינות לגביהן. בתרחיש הגרוע ביותר, תנועת הרשת בגלל בדיקות תקינות גדלה בקצב ריבועי (O(n^2)).

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

מסמכים קשורים:

מגבלות

  • צריך להפעיל ב-Cloud Router שמשמש לקישוריות היברידית את האפשרות global dynamic routing. אין תמיכה בניתוב דינמי אזורי ובניתוב סטטי.
  • במאזני עומסים אזוריים שמבוססים על Envoy – מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), מאזני עומסים חיצוניים אזוריים של רשת לשרת proxy, מאזני עומסים פנימיים אזוריים של רשת לשרת proxy ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB) – צריך להגדיר קישוריות היברידית באותו אזור שבו נמצא מאזן העומסים. אם הם מוגדרים באזורים שונים, יכול להיות שתראו שהשרתים העורפיים תקינים, אבל בקשות הלקוח לא יועברו לשרתים העורפיים.

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

    חשוב גם לבדוק את הגדרות האבטחה בהגדרות הקישוריות ההיברידית. חיבורי HA VPN מוצפנים כברירת מחדל (IPsec). חיבורי Cloud Interconnect לא מוצפנים כברירת מחדל. פרטים נוספים זמינים במסמך המידע בנושא הצפנה במעבר.

רישום ביומן

בקשות שמועברות דרך שרת proxy לנקודת קצה ב-NEG היברידי נרשמות ב-Cloud Logging באותו אופן שבו נרשמות בקשות לשרתי קצה עורפיים אחרים.

למידע נוסף:

מכסה

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

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