סקירה כללית של מאזן עומסי רשת חיצוני בשרת proxy

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

מאזן עומסי רשת חיצוני לשרת proxy הוא מאזן עומסים של שרת proxy הפוך שמפיץ תעבורת TCP שמגיעה מהאינטרנט למכונות וירטואליות (VM) ברשתGoogle Cloud הענן הווירטואלי הפרטי (VPC). כשמשתמשים במאזן עומסי רשת בשרת proxy חיצוני, תעבורת TCP או SSLנכנסת מסתיימת במאזן העומסים. חיבור חדש מעביר את התנועה לשרת העורפי הזמין הקרוב ביותר באמצעות TCP או SSL (מומלץ). תרחישי שימוש נוספים מפורטים במאמר סקירה כללית של מאזן עומסי רשת לשרת proxy.

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

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

‫Cloud Load Balancing עם סיום SSL.
Cloud Load Balancing עם סיום SSL (לחצו כדי להגדיל).

מצבי פעולה

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

  • מאזן עומסי רשת קלאסי בשרת proxy מיושם בממשקי קצה של Google‏ (GFE) שמפוזרים באופן גלובלי. אפשר להגדיר את מאזן העומסים הזה לטיפול בתעבורת TCP או SSL באמצעות שרת proxy של TCP או שרת proxy של SSL, בהתאמה. במסלול פרימיום, אפשר להגדיר את מאזן העומסים הזה כשירות גלובלי לאיזון עומסים. במסלול הרגיל, מאזן העומסים הזה מוגדר כשירות אזורי לאיזון עומסים. אפשר להשתמש במאזני עומסים קלאסיים של רשת גם לפרוטוקולים אחרים שמשתמשים ב-SSL, כמו WebSockets ו-IMAP over SSL.
  • מאזן עומסי רשת גלובלי חיצוני בשרת proxy מיושם בממשקי GFE שמפוזרים באופן גלובלי, ותומך ביכולות מתקדמות של ניהול תעבורה. אפשר להגדיר את מאזן העומסים הזה לטיפול בתנועת TCP או SSL באמצעות שרת TCP Proxy או שרת SSL Proxy, בהתאמה. מאזן העומסים הזה מוגדר כשירות גלובלי לאיזון עומסים במסלול פרימיום. אפשר להשתמש במאזני עומסים גלובליים חיצוניים של רשתות proxy גם לפרוטוקולים אחרים שמשתמשים ב-SSL, כמו WebSockets ו-IMAP over SSL.
  • מאזן עומסי רשת אזורי חיצוני בשרת proxy מיושם במערך התוכנה של Envoy proxy בקוד פתוח. הוא יכול לטפל רק בתנועת TCP. מאזן העומסים הזה מוגדר כשירות אזורי לאיזון עומסים, שאפשר להשתמש בו במסלול הפרימיום או במסלול הרגיל.

זיהוי המצב

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

המסוף

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. בכרטיסייה Load Balancers (מאזני עומסים) מוצגים סוג מאזן העומסים, הפרוטוקול והאזור. אם השדה region ריק, מאזן העומסים הוא גלובלי.

    בטבלה הבאה מוסבר איך לזהות את מצב איזון העומסים.

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

gcloud

  1. משתמשים בפקודה gcloud compute forwarding-rules describe:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

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

    מצב מאזן העומסים סכמת איזון עומסים כלל העברה רמת הרשת
    מאזן עומסי רשת קלאסי בשרת proxy חיצוני עולמי ‫Standard או Premium
    מאזן עומסי רשת גלובלי חיצוני בשרת proxy EXTERNAL_MANAGED עולמי פרימיום
    מאזן עומסי רשת אזורי חיצוני בשרת proxy EXTERNAL_MANAGED אזורי ‫Standard או Premium

ארכיטקטורה

בתרשימים הבאים מוצגים הרכיבים של מאזני עומסי רשת חיצוניים בשרת proxy.

עולמי

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

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

אזורי

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

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

הרכיבים הבאים הם חלק ממאזני עומסים חיצוניים של רשת בשרת proxy.

רשת משנה ל-Proxy בלבד

רשת המשנה של ה-proxy בלבד מספקת קבוצה של כתובות IP ש-Google משתמשת בהן כדי להפעיל פרוקסי של Envoy בשמכם. צריך ליצור רשת משנה מסוג proxy-only בכל אזור של רשת VPC שבה משתמשים במאזני עומסים. הדגל --purpose של רשת המשנה הזו, שמשמשת רק כפרוקסי, מוגדר כ-REGIONAL_MANAGED_PROXY. כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור ובאותה רשת VPC חולקים מאגר של שרתי proxy של Envoy מאותה תת-רשת של שרתי proxy בלבד.

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

נקודות שכדאי לזכור:

  • תת-רשתות של פרוקסי בלבד משמשות רק לפרוקסי Envoy, ולא לשרתי הקצה העורפיים.
  • כתובת ה-IP של מאזן העומסים לא נמצאת בתת-הרשת של ה-proxy בלבד. כתובת ה-IP של מאזן העומסים מוגדרת על ידי כלל ההעברה החיצוני המנוהל שלו.
  • צריך להגדיר את תת-הרשתות של שרת ה-proxy עם סוג מחסנית של IPV4_IPV6 כדי להפסיק את תעבורת הנתונים הנכנסת של IPv6, ועם סוג מחסנית של IPV4_ONLY או IPV4_IPV6 כדי להפסיק את תעבורת הנתונים הנכנסת של IPv4.

כללי העברה וכתובות IP

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

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

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

כדי לתמוך בכמה יציאות עוקבות, צריך להגדיר כמה כללי העברה. אפשר להגדיר כמה כללי העברה עם אותה כתובת IP וירטואלית ויציאות שונות. לכן, אפשר להשתמש ב-proxy לכמה אפליקציות עם יציאות מותאמות אישית נפרדות לאותה כתובת IP וירטואלית של TCP proxy.

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

מצב מאזן העומסים Network Service Tier כלל העברה, כתובת IP וסכמת איזון עומסים ניתוב מהאינטרנט לקצה הקדמי של מאזן העומסים
מאזן עומסי רשת קלאסי בשרת proxy מסלול פרימיום

כלל העברה חיצוני גלובלי

כתובת IP חיצונית גלובלית

סכמת איזון עומסים: EXTERNAL

 הבקשות מנותבות ל-GFE שהכי קרובים ללקוח באינטרנט.
מסלול רגיל

כלל העברה חיצוני אזורי

כתובת IP חיצונית אזורית

סכמת איזון עומסים: EXTERNAL

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

כלל העברה חיצוני גלובלי

כתובת IP חיצונית גלובלית

סכמת איזון עומסים: EXTERNAL_MANAGED

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

כלל העברה חיצוני אזורי

כתובת IP חיצונית אזורית

סכמת איזון עומסים: EXTERNAL_MANAGED

 בקשות מנותבות לשרתי ה-proxy של Envoy באותו אזור שבו נמצא מאזן העומסים.

כללי העברה ורשתות VPC

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

מצב מאזן העומסים שיוך לרשת VPC
מאזן עומסי רשת גלובלי חיצוני בשרת proxy

מאזן עומסי רשת קלאסי בשרת proxy

אין רשת VPC משויכת.

כלל ההעברה תמיד משתמש בכתובת IP שנמצאת מחוץ לרשת ה-VPC. לכן, לכלל ההעברה אין רשת VPC משויכת.
מאזן עומסי רשת אזורי חיצוני בשרת proxy

רשת ה-VPC של כלל ההעברה היא הרשת שבה נוצרה רשת המשנה של ה-proxy בלבד. כשיוצרים את כלל ההעברה, מציינים את הרשת.

בהתאם לכתובת IPv4 או לטווח כתובות IPv6 שבהם אתם משתמשים, תמיד יש רשת VPC מפורשת או מרומזת שמשויכת לכלל ההעברה.

  • כתובות IPv4 חיצוניות אזוריות תמיד נמצאות מחוץ לרשתות VPC. עם זאת, כשיוצרים את כלל ההעברה, צריך לציין את רשת ה-VPC שבה נוצרה תת-הרשת של ה-proxy בלבד. לכן, לכלל ההעברה יש שיוך מפורש לרשת.

  • טווחים של כתובות IPv6 חיצוניות אזוריות תמיד קיימים בתוך רשת VPC. כשיוצרים את כלל ההעברה, צריך לציין את רשת המשנה שממנה נלקח טווח כתובות ה-IP. תת-הרשת הזו צריכה להיות באותו אזור ובאותה רשת VPC שבה נוצרה תת-רשת של שרת proxy בלבד. לכן, יש שיוך רשת משתמע.

    דרישות לגבי רשתות ותת-רשתות. כדי להשתמש בתנועה מסוג IPv6, הרשתות ורשתות המשנה צריכות לעמוד בדרישות ההגדרה הבאות:

    • רשת VPC: צריך להשתמש ברשת VPC במצב מותאם אישית שהוגדרה עם הדגל --enable-ula-internal-ipv6.
    • תת-רשת של כלל העברה: תת-הרשת הזו צריכה להיות תת-רשת עם תמיכה כפולה (IPv4_IPv6) או IPV6_ONLY, עם הערך ipv6-access-type שמוגדר ל-EXTERNAL.
    אפשרויות להקצאת כתובות IPv6. כלל ההעברה חייב להפנות לטווח של כתובות IPv6 מתוך טווח כתובות ה-IPv6 החיצוניות של תת-הרשת./96/64 אפשר להקצות את טווח כתובות ה-IPv6 הזה באחת מהשיטות הבאות:
      /96
    • מציינים כתובת IPv6 חיצונית שמורה.
    • הגדרת כתובת IPv6 זמנית מותאמת אישית.
    • מאפשרים הקצאה אוטומטית של כתובת IPv6 זמנית. Google Cloud
    מגבלות. כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-Google Cloud CLI או ב-API. ב Google Cloud מסוף אין תמיכה בציון כתובות IPv6 זמניות מותאמות אישית לכללי העברה.

שרתי proxy יעד

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

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

  • שרת proxy של TCP ביעד: מגדירים את מאזן העומסים עם שרת proxy של TCP ביעד אם צפוי טראפיק TCP.
  • שרת proxy של SSL ביעד: מגדירים את מאזן העומסים עם שרת proxy של SSL ביעד אם צפוי נפח תנועה של לקוחות מוצפן. סוג מאזן העומסים הזה מיועד רק לתנועה שאינה HTTP(S). לתנועת HTTP(S), מומלץ להשתמש במאזן עומסים חיצוני של אפליקציות (ALB).

כברירת מחדל, פרוקסי היעד לא שומר את כתובת ה-IP המקורית של הלקוח ואת פרטי היציאה. כדי לשמור את המידע הזה, צריך להפעיל את פרוטוקול ה-PROXY ב-proxy של היעד.

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

מצב מאזן העומסים Network Service Tier שרת proxy יעד חומרי עזר
מאזן עומסי רשת קלאסי בשרת proxy מסלול פרימיום targetTcpProxies או targetSslProxies שרת proxy יעד מפנה לשירות קצה עורפי יחיד.
מסלול רגיל targetTcpProxies או targetSslProxies
מאזן עומסי רשת גלובלי חיצוני בשרת proxy מסלול פרימיום targetTcpProxies או targetSslProxies שרת proxy יעד מפנה לשירות קצה עורפי יחיד.
מאזן עומסי רשת אזורי חיצוני בשרת proxy מסלול פרימיום ומסלול רגיל regionTargetTcpProxies פרוקסי היעד מפנה לשירות יחיד לקצה העורפי או לנתיב TLS אחד או יותר.

אישורי SSL

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

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

  • ‫Google Cloud יש שתי שיטות הגדרה להקצאת מפתחות פרטיים ואישורי SSL ל-proxy יעד ל-SSL: אישורי SSL של Compute Engine ו-Certificate Manager. תיאור של כל הגדרה זמין במאמר שיטות להגדרת אישורים בסקירה הכללית על אישורי SSL.

  • ‫Google Cloud יש שני סוגים של אישורים: בניהול עצמי ובניהול Google. תיאור של כל סוג מופיע במאמר סוגי אישורים בסקירה הכללית על אישורי SSL.

מסלולי TLS

משאב TLS route מאפשר להגדיר איך התנועה מופנית לשירותי קצה עורפיים על סמך שמות מארחים של SNI.

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

מסלולי TLS זמינים רק למאזני עומסי רשת אזוריים חיצוניים בשרת proxy. הם לא נתמכים במאזני עומסי רשת קלאסיים בשרת proxy ובמאזני עומסי רשת גלובליים חיצוניים בשרת proxy.

אפשר לצרף הגדרת נתיב TLS לשרת proxy ליעד של מאזן עומסים באמצעות הפקודות gcloud network-services tls-routes.

בטבלה הבאה מפורטים ממשקי ה-API של מסלולי TLS שנדרשים למאזני עומסים חיצוניים של רשתות proxy:

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

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

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

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

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

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

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

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

מצב מאזן העומסים קצה עורפי נתמך בשירות לקצה העורפי
קבוצות של מכונות קבוצות אזוריות של נקודות קצה של רשתות Internet NEGs קבוצות NEG ללא שרת (serverless) קבוצות היברידיות של נקודות קצה ברשת (Hybrid NEGs) קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect GKE
מאזן עומסי רשת קלאסי בשרת proxy שימוש ב-NEGs אזוריים עצמאיים
מאזן עומסי רשת גלובלי חיצוני בשרת proxy * GCE_VM_IP_PORT type endpoints *
מאזן עומסי רשת אזורי חיצוני בשרת proxy נקודות קצה מסוג GCE_VM_IP_PORT קבוצות NEGs אזוריות בלבד הוספת Private Service Connect NEG

* מאזני עומסי רשת גלובליים חיצוניים בשרת proxy תומכים בקבוצות של מופעים עם IPv4 ו-IPv6 (מערך כפול) ובמערכות בק-אנד של NEG אזורי עם נקודות קצה של GCE_VM_IP_PORT.

שרתי קצה עורפיים ורשתות VPC

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

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

  • במקרה של קבוצות של מכונות, NEGs אזוריים ו-NEGs של קישוריות היברידית, כל השרתים העורפיים חייבים להיות ממוקמים באותו פרויקט ואזור כמו שירות השרת העורפי. עם זאת, מאזן עומסים יכול להפנות לעורף קצה שמשתמש ברשת VPC אחרת באותו פרויקט כמו שירות עורף הקצה. אפשר להגדיר קישוריות בין רשת ה-VPC של מאזן העומסים לבין רשת ה-VPC של הבק-אנד באמצעות קישור בין רשתות VPC שכנות (peering), מנהרות Cloud VPN, צירופי VLAN של Cloud Interconnect או מסגרת של Network Connectivity Center.

    הגדרת רשת בקצה העורפי

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

    דרישות לגבי רשתות עורפיות

    הרשת של ה-backend צריכה לעמוד באחת מהדרישות הבאות:

    • רשת ה-VPC של ה-backend חייבת להיות זהה לרשת ה-VPC של כלל ההעברה.

    • רשת ה-VPC של ה-Backend צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות שכנות (VPC Network Peering). צריך להגדיר את החלפת נתיבי רשתות המשנה כדי לאפשר תקשורת בין רשת ה-VPC של רשת המשנה עם שרת ה-proxy בלבד בכלל ההעברה לבין רשתות המשנה שבהן נעשה שימוש במופעי ה-backend או בנקודות הקצה.

    דרישות לגבי רשת משנה של IPv6 בעורף המערכת

    גרסת ה-IP שמשמשת לחיבור הקצה הקדמי לא תלויה בחיבור הקצה האחורי. מכיוון שרשת המשנה של הפרוקסי היא dual-stack ‏ (IPV4_IPV6), היא יכולה לתקשר עם השרתים העורפיים באמצעות IPv4 או IPv6.

    אם מופעלות בדוגמאות העורפיות שלכם כתובות IPv6, אפשר להגדיר את רשת המשנה העורפית עם סוג מחסנית של IPV4_ONLY או IPV4_IPV6 (מחסנית כפולה). אם סוג הערימה של רשת המשנה של ה-backend כולל IPv6, צריך להגדיר באופן מפורש את ipv6-access-type של רשת המשנה ל-EXTERNAL.

  • גם רשת ה-VPC של ה-backend וגם רשת ה-VPC של כלל ההעברה צריכות להיות רשתות VPC מסוג Spoke שמצורפות לאותו מרכז NCC. מסנני הייבוא והייצוא צריכים לאפשר תקשורת בין רשת המשנה של ה-proxy בלבד ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שמשמשות את מופעי ה-backend או נקודות הקצה.

  • בכל שאר סוגי ה-Backend, כל ה-Backend-ים צריכים להיות ממוקמים באותה רשת VPC ובאותו אזור.

שרתי קצה וממשקי רשת

אם משתמשים בעורפי קצה של קבוצות מופעי מכונה, המנות תמיד מועברות אל nic0. אם רוצים לשלוח מנות לממשקי nic0 שאינם ממשקים (vNIC או ממשקי רשת דינמיים), צריך להשתמש במקום זאת ב-NEG backends.

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

פרוטוקול לתקשורת עם השרתים העורפיים

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

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

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

כללי חומת אש

חובה להגדיר את כללי חומת האש הבאים:

  • במאזני עומסי רשת קלאסיים בשרת proxy, כלל חומת אש של תעבורת נתונים נכנסת (ingress) allow שמאפשר לתעבורה מ-GFE להגיע לשרתים העורפיים (backend).

  • במאזני עומסים גלובליים חיצוניים בשרת proxy, כלל חומת אש של תעבורת נתונים נכנסת (ingress) allow כדי לאפשר לתעבורת נתונים מ-GFE להגיע לשרתים העורפיים.

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

  • כלל חומת אש של תעבורת נתונים נכנסת (ingress) allow כדי לאפשר לתעבורה מטווחים של בדיקות תקינות להגיע לשרתים העורפיים. מידע נוסף על בדיקות תקינות ולמה צריך לאפשר תנועה מהן זמין במאמר Probe IP ranges and firewall rules.

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

היציאות של כללי חומת האש האלה צריכות להיות מוגדרות באופן הבא:

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

בטבלה הבאה מפורטים טווחי כתובות ה-IP של המקור שנדרשים לכללים של חומת האש.

מצב מאזן העומסים טווחים של כתובות IP של בדיקות תקינות בקשת טווחי מקור
מאזן עומסי רשת גלובלי חיצוני בשרת proxy
  • 35.191.0.0/16
  • 130.211.0.0/22

לתנועת IPv6 לשרתי הקצה:

  • 2600:2d00:1:b029::/64
 המקור של תנועת הנתונים של GFE תלוי בסוג ה-Backend:
  • קבוצות של מופעים ו-NEGs אזוריים (GCE_VM_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16

    לגבי תנועת IPv6 אל ה-backends:

    • 2600:2d00:1:1::/64
מאזן עומסי רשת קלאסי בשרת proxy
  • 35.191.0.0/16
  • 130.211.0.0/22
 הטווחים האלה חלים על בקשות לבדיקות תקינות (probes) ובקשות מ-GFE.
מאזן עומסי רשת אזורי חיצוני בשרת proxy‏ *, †
  • 35.191.0.0/16
  • 130.211.0.0/22

לתנועת IPv6 לשרתי הקצה:

  • 2600:2d00:1:b029::/64
 הטווחים האלה חלים על בקשות לבדיקות תקינות (probes).

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

† ב-NEGs אזוריים לאינטרנט, בדיקות תקינות הן אופציונליות. תעבורת נתונים ממאזני עומסים שמשתמשים ב-regional internet NEGs מגיעה מ-proxy-only subnet ואז עוברת תרגום NAT (באמצעות Cloud NAT) לכתובות IP של NAT שהוקצו באופן ידני או אוטומטי. התנועה הזו כוללת גם בדיקות תקינות וגם בקשות של משתמשים ממאזן העומסים לשרתי הקצה. פרטים נוספים זמינים במאמר בנושא NEGs אזוריים: שימוש בשער Cloud NAT.

כתובות IP של המקור

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

למאזני עומסים קלאסיים של רשת בשרת proxy ולמאזני עומסים גלובליים חיצוניים של רשת בשרת proxy:

  • חיבור 1, מהלקוח המקורי למאזן העומסים (GFE):

    • כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
    • כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.

  • חיבור 2, ממאזן העומסים (GFE) אל מכונת ה-VM או נקודת הקצה של ה-Backend:

    • כתובת ה-IP של המקור: כתובת IP באחד מהטווחים שצוינו בכללי חומת האש.

    • כתובת ה-IP של היעד: כתובת ה-IP הפנימית של המכונה הווירטואלית או של הקונטיינר בבק-אנד ברשת ה-VPC.

למאזני עומסים אזוריים חיצוניים של שרת proxy:

  • חיבור 1, מהלקוח המקורי למאזן העומסים (רשת משנה ל-proxy בלבד):

    • כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
    • כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.

  • חיבור 2, ממאזן העומסים (רשת משנה של פרוקסי בלבד) אל מכונת ה-VM או נקודת הקצה של הקצה העורפי:

    • כתובת ה-IP של המקור: כתובת IP בתת-הרשת של שרת ה-proxy בלבד שמשותפת לכל מאזני העומסים שמבוססים על Envoy שנפרסו באותו אזור ובאותה רשת כמו מאזן העומסים.

    • כתובת ה-IP של היעד: כתובת ה-IP הפנימית של המכונה הווירטואלית או של הקונטיינר בבק-אנד ברשת ה-VPC.

יציאות פתוחות

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

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

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

  • בסריקת יציאות (לדוגמה, באמצעות nmap) בדרך כלל לא צפויה חבילת תגובה או חבילת TCP RST כשמבצעים בדיקת TCP SYN. מערכות GFE שולחות מנות SYN-ACK בתגובה לבדיקות SYN רק ליציאות שהגדרתם עבורן כלל העברה. מערכות GFE שולחות חבילות רק לשרתי הקצה העורפיים בתגובה לחבילות שנשלחות לכתובת ה-IP של מאזן העומסים וליציאת היעד שהוגדרה בכלל ההעברה שלו. חבילות שנשלחות לכתובת IP או ליציאה אחרת לא נשלחות לשרתי ה-Backend.

    ‏GFE מטמיע תכונות אבטחה כמו Google Cloud Armor. עם Cloud Armor Standard, שרתי GFE מספקים הגנה שפועלת ללא הפסקה מפני מתקפות DDoS נפחיות ומבוססות פרוטוקול, ומפני הצפות SYN. ההגנה הזו זמינה גם אם לא הגדרתם את Cloud Armor באופן מפורש. תחויבו רק אם תגדירו כללי מדיניות אבטחה או אם תירשמו ל-Google Cloud Armor Enterprise.

  • על מנות שנשלחות לכתובת ה-IP של איזון העומסים יכול לענות כל GFE בצי של Google. עם זאת, סריקה של כתובת IP של איזון עומסים ושילוב של יציאת יעד בודקת רק GFE אחד לכל חיבור TCP. כתובת ה-IP של איזון העומסים לא מוקצית למכשיר או למערכת יחידים. לכן, סריקה של כתובת ה-IP של מאזן עומסים שמבוסס על GFE לא סורקת את כל ה-GFE בצי של Google.

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

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

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

ארכיטקטורה של VPC משותף

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

כתובת IP כלל העברה שרת proxy יעד רכיבי קצה עורפי
צריך להגדיר כתובת IP חיצונית באותו הפרויקט שבו נמצא מאזן העומסים. כלל ההעברה החיצוני חייב להיות מוגדר באותו פרויקט כמו מופעי ה-Backend (פרויקט השירות). פרוקסי היעד TCP או SSL צריך להיות מוגדר באותו פרויקט שבו מוגדרים מופעי הקצה העורפי.

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

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

ביזור תעבורת נתונים

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

במאזני עומסים חיצוניים של רשת בשרת proxy, מצב האיזון יכול להיות CONNECTION או UTILIZATION:

  • אם מצב איזון העומסים הוא CONNECTION, העומס מתפזר על סמך המספר הכולל של החיבורים שהקצה העורפי יכול לטפל בהם.
  • אם מצב איזון העומסים הוא UTILIZATION, העומס מתחלק בהתאם לניצול של המכונות בקבוצת המכונות. מצב האיזון הזה חל רק על קצוות עורפיים של קבוצת מכונות VM.

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

מאזן עומסי רשת קלאסי בשרת proxy

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

איך הקשרים מחולקים

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

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

במסלול פרימיום

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

  • ‫Google מפרסמת את כתובת ה-IP של מאזן העומסים מכל נקודות הנוכחות ברחבי העולם. כל כתובת IP של מאזן עומסים היא מסוג anycast גלובלי.

  • אם מגדירים שירות קצה עורפי עם קצה עורפי בכמה אזורים, מערכות Google Front Ends‏ (GFE) מנסות להפנות בקשות לקבוצות תקינות של מופעי קצה עורפי או לקבוצות NEG באזור הקרוב ביותר למשתמש.

במסלול רגיל

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

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

מאזן עומסי רשת גלובלי חיצוני בשרת proxy

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

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

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

למידע נוסף, קראו את המאמרים הבאים:

איך הקשרים מחולקים

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

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

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

  • ‫Google מפרסמת את כתובת ה-IP של מאזן העומסים מכל נקודות הנוכחות ברחבי העולם. כל כתובת IP של מאזן עומסים היא מסוג anycast גלובלי.

  • אם מגדירים שירות קצה עורפי עם קצה עורפי בכמה אזורים, מערכות Google Front Ends‏ (GFE) מנסות להפנות בקשות לקבוצות תקינות של מופעי קצה עורפי או לקבוצות NEG באזור הקרוב ביותר למשתמש.

מאזן עומסי רשת אזורי חיצוני בשרת proxy

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

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

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

למידע נוסף, קראו את המאמרים הבאים:

ניתוב מבוסס-SNI עם נתיבי TLS

ניתוב מבוסס-SNI מאפשר למאזני עומסים של TCP proxy לנתב תנועה לשירותי קצה עורפיים ספציפיים על סמך שם המארח של Server Name Indication ‏ (SNI) שסופק במהלך לחיצת היד של TLS. ‫SNI הוא תוסף TLS שמאפשר ללקוח לציין את שם הדומיין שאליו הוא רוצה להגיע לפני יצירת המנהרה המוצפנת. שם המארח של SNI מועבר בפורמט לא מוצפן בהודעה ClientHello כדי שמאזן העומסים יוכל לבדוק את הערך הזה ולנתב את תעבורת הנתונים לשירות לקצה העורפי המתאים.

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

התכונה הזו מאפשרת כמה תרחישי שימוש מרכזיים, כמו:

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

איך התעבורה מתחלקת כשמשתמשים בנתיבי TLS

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

  1. מאזן העומסים מאזין לכתובת ה-IP ולפורט שמוגדרים בכלל ההעברה.
  2. כשלקוח יוזם חיבור TLS, מאזן העומסים מיירט את ההודעה ClientHello ומחלץ את שם המארח של SNI.

  3. ה-SNI שחולץ מושווה לשמות המארחים שמוגדרים במסלולי ה-TLS שהוגדרו. מאזן העומסים משתמש בלוגיקה הבאה כדי לקבוע לאיזה שירות לקצה העורפי צריך להעביר את התנועה:

    1. אם הלקוח לא משתמש בפרוטוקול TLS, מאזן העומסים סוגר את החיבור.
    2. אם הלקוח לא שולח שם של שם מארח SNI בהודעה ClientHello, מאזן העומסים סוגר את החיבור.
    3. אם הלקוח שולח שם מארח של SNI שהוא לא שם DNS תקין, מאזן העומסים סוגר את החיבור.
    4. אם הלקוח שולח שם מארח של SNI שלא תואם לאף שם מארח של SNI שמשויך לנתיב TLS, מאזן העומסים סוגר את החיבור.

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

      ההתאמה מתבצעת לפי הסיומת הארוכה ביותר (הארוכה ביותר מבחינת מספר תתי-הדומיינים). כדי להמחיש את שיטת ההתאמה, נניח שיש מסלול TLS עם SNI ‏*.foo.com, מסלול TLS נוסף עם SNI ‏*.bar.foo.com ומסלול TLS שלישי עם SNI ‏baz.bar.foo.com.

      • אם שם המארח של SNI של הלקוח הוא baz.bar.foo.com, מאזן העומסים בוחר שירות קצה עורפי שאליו מפנה נתיב ה-TLS ששם ה-SNI שלו הוא baz.bar.foo.com.
      • אם שם המארח של SNI של הלקוח הוא qux.bar.foo.com, מאזן העומסים בוחר שירות קצה עורפי שאליו מפנה נתיב ה-TLS ששם ה-SNI שלו הוא qux.bar.foo.com.*.bar.foo.com
      • אם שם המארח של SNI של הלקוח הוא qux.qux.foo.com, מאזן העומסים בוחר שירות קצה עורפי שאליו מפנה נתיב ה-TLS ששם ה-SNI שלו הוא qux.qux.foo.com.*.foo.com

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

מגבלות

המגבלות הבאות חלות כשמשתמשים בנתיבי TLS כדי להגדיר ניתוב מבוסס-SNI:

  • פרוקסי TCP ליעד יכול להפנות לשירות קצה עורפי יחיד או לנתיב TLS אחד או יותר. אי אפשר להגדיר את שניהם.

  • מאזני עומסים של רשתות proxy לא יכולים לזהות איחוד של חיבורי HTTP, מה שעלול להוביל לניתוב שגוי של בקשות HTTP.

    כברירת מחדל, הדפדפנים כבר מאחדים חיבורי HTTP. לדוגמה, כשדפדפן פותח חיבור ל-www.example.com והשרת מציג אישור ל-*.example.com במהלך לחיצת היד של TLS, הדפדפן משתמש מחדש בחיבור הזה לכל הבקשות ל-www.example.com, כל עוד שם המארח מפנה לאותה כתובת IP.*.example.com ההתנהגות הזו תואמת ל-RFC 7540.

    בתכנון מסלולים שמבוסס על SNI, אחרי שנוצר חיבור, הוא נקשר באופן קבוע לעורף הקצה של היעד. כדאי לשקול פריסה שבה *.example.com מוצג על ידי קצה עורפי אחד של HTTPS עם אישור TLS של *.example.com, ו-my.example.com מוצג על ידי קצה עורפי אחר של HTTPS. אם נוצר קודם חיבור ל-*.example.com, בקשות HTTP עוקבות ל-my.example.com יאוחדו לאותו חיבור באמצעות קצה העורף של *.example.com HTTPS.

זיקה לסשן (session affinity)

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

מאזני עומס רשת חיצוניים לשרת proxy מציעים את סוגי ההצמדה הבאים של סשנים:

  • ללא

    הגדרה של זיקה לסשן עם ערך של NONE לא אומרת שאין זיקה לסשן. כלומר, לא מוגדרת במפורש אפשרות של זיקה לסשן (session affinity).

    הגיבוב תמיד מתבצע כדי לבחור קצה עורפי. הגדרה של זיקה לסשן של NONE פירושה שמאזן העומסים משתמש בגיבוב של 5 טאפלים כדי לבחור בק-אנד. הגיבוב (hash) של 5 הערכים מורכב מכתובת ה-IP של המקור, היציאה של המקור, הפרוטוקול, כתובת ה-IP של היעד והיציאה של היעד.

    ערך ברירת המחדל של ההעדפה לשימוש באותו שרת (session affinity) הוא NONE.

  • זיקה לכתובת IP של לקוח

    זיקה לסשן (session affinity) של כתובת ה-IP של הלקוח (CLIENT_IP) היא גיבוב של 2-tuple שנוצר מכתובות ה-IP של המקור והיעד של חבילת הנתונים. זיקה לכתובת IP של לקוח מעבירה את כל הבקשות מאותה כתובת IP של לקוח לאותו קצה עורפי, כל עוד יש לאותו קצה עורפי קיבולת והוא תקין.

    כשמשתמשים בזיקה לכתובת IP של לקוח, חשוב לזכור את הנקודות הבאות:

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

כשמגדירים זיקה לסשן (session affinity), חשוב לזכור את הנקודות הבאות:

  • אל תסתמכו על זיקה לסשן (session affinity) למטרות אימות או אבטחה. הזיקה לסשן עלולה להיפסק בכל פעם שמספר השרתים העורפיים הפעילים והתקינים משתנה. לפרטים נוספים, ראה איבוד זיקה לסשן.

  • ערכי ברירת המחדל של הדגלים --session-affinity ו---subsetting-policy הם NONE, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.

איבוד הזיקה לסשן

כל האפשרויות של זיקה לסשן דורשות את הדברים הבאים:

  • צריך להגדיר את שרת עורפי (backend instance) או נקודת הקצה שנבחרו כ-backend. הזיקה לסשן עלולה להיפסק באחד מהמקרים הבאים:
    • הסרתם את המכונה שנבחרה מקבוצת המכונות שלה.
    • התכונות 'התאמה אוטומטית לעומס' או 'תיקון תוכנה אוטומטי' של קבוצת מופעי מכונה מנוהלים מסירות את המכונה שנבחרה מקבוצת המופעים המנוהלים.
    • מסירים את נקודת הקצה שנבחרה מה-NEG שלה.
    • מסירים את קבוצת המכונות או את ה-NEG שמכילים את המופע או נקודת הקצה שנבחרו משירות לקצה העורפי.
  • מוודאים שנקודת הקצה או מופע ה-Backend שנבחרו תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות תקינות.
  • במאזני עומסים גלובליים חיצוניים של רשתות פרוקסי ובמאזני עומסים קלאסיים של רשתות פרוקסי, זיקה להפעלת אינטרנט יכולה להיפסק אם נעשה שימוש ב-Google Front End (GFE) שונה בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט אל Google משתנה בין בקשות או חיבורים.
לכל האפשרויות של זיקה לסשן (session affinity) יש את הדרישות הנוספות הבאות:

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

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

    • הוספת מופעים או נקודות קצה חדשים:

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

    • הסרה של כל מופע או נקודת קצה, לא רק המופע או נקודת הקצה שנבחרו:

      • מסירים מופע כלשהו מקצה עורפי של קבוצת מופעים.
      • התאמה אוטומטית לעומס או תיקון תוכנה אוטומטי של קבוצת מופעי מכונה מנוהלים מסירים כל מופע מקצה העורף של קבוצת מופעי מכונה מנוהלים.
      • אתם מסירים נקודת קצה כלשהי מעורף קצה של NEG.
      • מסירים כל קבוצת מופעים או NEG קיימת ולא ריקה מהקצה העורפי של שירות ה-Backend.

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

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

מעבר לגיבוי (Failover)

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

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

איזון עומסים באפליקציות GKE

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

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

מגבלות

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

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

  • המגבלות הבאות חלות רק על מאזני עומסי רשת בשרת proxy בגרסה הקלאסית ועל מאזני עומסי רשת בשרת proxy חיצוני גלובלי שנפרסים עם שרת proxy של SSL:

    • מאזני עומסים קלאסיים של רשת בשרת proxy ומאזני עומסים גלובליים של רשת בשרת proxy לא תומכים באימות שמבוסס על אישורי לקוח, שנקרא גם אימות TLS הדדי.

    • מאזני עומסי רשת קלאסיים של שרתי proxy ומאזני עומסי רשת גלובליים חיצוניים של שרתי proxy תומכים רק בתווים קטנים בדומיינים במאפיין של שם נפוץ (CN) או במאפיין של שם חלופי של בעלים (subject) (SAN) באישור. אישורים עם אותיות רישיות בדומיינים מוחזרים רק אם הם מוגדרים כאישור הראשי בשרת ה-proxy של היעד.

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