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

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 שבו נמצאים המשאבים של מאזן העומסים.

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

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

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

העברת שירות קיים לענן מאפשרת לכם לפנות קיבולת מקומית ולהפחית את העלות והעומס של תחזוקת תשתית מקומית. אפשר להגדיר פריסה היברידית באופן זמני, שתאפשר לכם להפנות תנועה גם לשירות הנוכחי שלכם בשרת מקומי וגם לנקודת קצה תואמת של שירות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 או מכשיר נתב וירטואלי.

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

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

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

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

משאבים של מאזן עומסים פנימי אזורי של אפליקציות (ALB) לקישוריות היברידית.
משאבים של מאזן עומסים של אפליקציות (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 subnet לא יכולים להיות חופפים. כשכתובות ה-IP חופפות, נתיבי תת-הרשת מקבלים עדיפות על פני קישוריות מרוחקת.

  • קישוריות היברידית. הסביבות שלכם ב- Cloud de Confiance ובסביבות מקומיות או בענן אחר צריכות להיות מחוברות באמצעות קישוריות היברידית, באמצעות צירופים ל-VLAN של Cloud Interconnect, מנהרות 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 או מכשיר נתב וירטואלי VM. אם יש כמה נתיבים לנקודת הקצה של כתובת ה-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מחוץ Cloud de Confiance.

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

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

    מגדירים את הקצה העורפי שאינו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 backends.
    2. מגדירים כמה קצוות עורפיים (או GCE_VM_IP_PORT קבוצות NEG אזוריות או קבוצות של מכונות וירטואליות) באותו אזור שבו הגדרתם קישוריות היברידית.

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

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

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

  • סכמת איזון העומסים של שירות הקצה העורפי היא INTERNAL_MANAGED עבור מאזני עומסים אזוריים פנימיים של אפליקציות ומאזני עומסים אזוריים פנימיים של רשתות לשרת 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 עצמה. כל שירות לקצה העורפי חייב להיות משויך לבדיקת תקינות שבודקת את התקינות של הבק-אנדים. בקשות לבדיקות תקינות (probes) מגיעות משרתי ה-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 מופעל.
  • אם אתם משתמשים בקבוצות מעורבות של נקודות קצה ברשת (NEG), שבהן לשירות לקצה העורפי יחיד יש שילוב של קבוצות NEG אזוריות (נקודות קצה של GCE_VM_IP_PORT בתוךCloud de Confiance) וקבוצות NEG היברידיות (נקודות קצה של 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 – מאזני עומסים חיצוניים אזוריים של אפליקציות, מאזני עומסי רשת חיצוניים אזוריים לשרת proxy, מאזני עומסי רשת פנימיים אזוריים לשרת proxy ומאזני עומסים פנימיים אזוריים של אפליקציות – צריך להגדיר קישוריות היברידית באותו אזור שבו נמצא מאזן העומסים. אם הם מוגדרים באזורים שונים, יכול להיות שתראו שהעורפים תקינים, אבל בקשות של לקוחות לא יועברו לעורפים.

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

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

רישום ביומן

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

למידע נוסף:

מכסה

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

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