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

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

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

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

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

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

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

‫Migrate to 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 או מכשיר Router VM.

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

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

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

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

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

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

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

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

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

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

  • כל 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 למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), למאזני עומסים אזוריים חיצוניים של אפליקציות (ALB), למאזני עומסים גלובליים חיצוניים של רשתות לשרתי proxy ולמאזני עומסים אזוריים חיצוניים של רשתות לשרתי proxy

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

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

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

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

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

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

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

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

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

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

רישום ביומן

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

למידע נוסף:

מכסה

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

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