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

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

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

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

איזון עומסים היברידי נתמך במאזני העומסים הבאים Google Cloud :

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

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

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

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

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

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

    • שימוש בתשתית הקצה הגלובלית של Google כדי לסיים חיבורים של משתמשים במיקום קרוב יותר למשתמש, וכך לקצר את זמן האחזור.
    • הגנה על השירות באמצעות Google Cloud Armor, מוצר אבטחה מסוג WAF או הגנה מפני DDoS בקצה הרשת, שזמין לכל השירותים שאליהם ניגשים דרך מאזן עומסים חיצוני של אפליקציות.
    • הפעלת השירות כדי לייעל את ההעברה באמצעות Cloud CDN. בעזרת Cloud CDN, אתם יכולים לשמור תוכן במטמון קרוב למשתמשים. ‫Cloud CDN מספק יכולות כמו ביטול תוקף של מטמון וכתובות URL חתומות של Cloud CDN.
    • שימוש באישורי SSL בניהול Google. אפשר להשתמש מחדש באישור ובמפתחות פרטיים שכבר משמשים אתכם במוצרים אחרים של Google Cloud Google. כך לא צריך לנהל אישורים נפרדים.

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

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

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

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

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

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

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

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

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

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

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

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

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

העברה אל Google Cloud.
העברה אל Google Cloud (לחצו כדי להגדיל).

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

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

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

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

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

HTTP(S) חיצוני גלובלי

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

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

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

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

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

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

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

אזורי לעומת גלובלי

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

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

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

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

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

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

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

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

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

    בנוסף, Cloud Router צריך לפרסם את המסלולים הבאים לסביבה המקומית:

    • הטווחים שבהם משתמשים בבדיקות תקינות של Google: ‏ 35.191.0.0/16 ו-130.211.0.0/22. נדרש למאזני עומסים חיצוניים גלובליים של אפליקציות, למאזני עומסים קלאסיים של אפליקציות, למאזני עומסי רשת גלובליים חיצוניים לשרת proxy ולמאזני עומסי רשת קלאסיים לשרת proxy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Google Cloud backends

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

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

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

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

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

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

    • ‫EXTERNAL_MANAGED עבור מאזני עומסים גלובליים חיצוניים של אפליקציות, מאזני עומסים אזוריים חיצוניים של אפליקציות, מאזני עומסים גלובליים חיצוניים של רשתות לשרת proxy ומאזני עומסים אזוריים חיצוניים של רשתות לשרת proxy

    • EXTERNAL למאזני עומסים קלאסיים של אפליקציות (ALB) ולמאזני עומסי רשת קלאסיים בשרת proxy

    • ‫INTERNAL_MANAGED למאזני עומסים פנימיים של אפליקציות ולמאזני עומסי רשת פנימיים בשרת proxy

    ‫INTERNAL_SELF_MANAGED נתמך בפריסות של Cloud Service Mesh בכמה סביבות עם NEG לקישוריות היברידית.

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

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

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

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

בדיקות תקינות מרכזיות

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

עבור נקודות קצה של NON_GCP_PRIVATE_IP_PORT מחוץ Google Cloud, צריך ליצור כללים לחומת האש ברשתות המקומיות וברשתות אחרות בענן. לשם כך, צריך לפנות לאדמין של הרשת. ה-Cloud Router שמשמש לקישוריות היברידית צריך גם לפרסם את הטווחים שבהם משתמשים בבדיקות התקינות של Google. הטווחים שיפורסמו הם 35.191.0.0/16 ו-130.211.0.0/22.

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

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

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

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

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

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

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

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

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

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

  • מישור הנתונים של Envoy מטפל בבדיקות תקינות, ולכן אי אפשר להשתמש במסוףGoogle Cloud , ב-API או ב-CLI של gcloud כדי לבדוק את סטטוס התקינות של נקודות הקצה החיצוניות האלה. ב-NEGs היברידיים עם מאזני עומסים מבוססי Envoy, במסוף מוצג סטטוס בדיקת התקינות כ- Google Cloud 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 ומאזני עומסים פנימיים אזוריים של אפליקציות – צריך להגדיר קישוריות היברידית באותו אזור שבו נמצא מאזן העומסים. אם הם מוגדרים באזורים שונים, יכול להיות שתראו שהעורפים תקינים, אבל בקשות של לקוחות לא יועברו לעורפים.

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

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

רישום ביומן

בקשות שמועברות דרך שרת proxy לנקודת קצה ב-NEG היברידי נרשמות ביומן ב-Cloud Logging באותו אופן שבו נרשמות בקשות לשרתי קצה עורפיים אחרים. אם מפעילים את Cloud CDN עבור מאזן עומסים גלובלי חיצוני של אפליקציות (ALB), גם מציאות במטמון (cache hit) נרשמות ביומן.

למידע נוסף:

מכסה

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

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