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

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

Cloud de Confiance by S3NS מאזן עומסים פנימי של אפליקציות (ALB) הוא מאזן עומסים מבוסס-פרוקסי בשכבה 7, שמאפשר לכם להפעיל את השירותים שלכם ולהתאים אותם לעומס מאחורי כתובת IP פנימית אחת. מאזן העומסים הפנימי של האפליקציות מחלק את תעבורת הנתונים ב-HTTP וב-HTTPS בין שרתים עורפיים שמארחים מגוון של פלטפורמות, כמו Compute Engine,‏ Google Kubernetes Engine‏ (GKE) ו-Cloud Run. Cloud de Confiance פרטים נוספים מופיעים במאמר בנושא תרחישים לדוגמה.

מצבי פעולה

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

ארכיטקטורה ומשאבים

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

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

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

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

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

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

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

בנוסף:

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

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

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

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

הלקוחות משתמשים בכתובת ה-IP ובפורט כדי להתחבר לשרתי ה-proxy של Envoy של מאזן העומסים – כתובת ה-IP של כלל ההעברה היא כתובת ה-IP של מאזן העומסים (לפעמים נקראת כתובת IP וירטואלית או VIP). לקוחות שמתחברים למאזן עומסים צריכים להשתמש ב-HTTP מגרסה 1.1 ואילך. רשימה מלאה של הפרוטוקולים הנתמכים מופיעה במאמר השוואה בין תכונות של מאזני עומסים.

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

מפרט היציאה. כל כלל העברה למאזן עומסים של אפליקציות יכול להפנות ליציאה אחת מתוך 1-65535. כדי לתמוך בכמה יציאות, צריך להגדיר כמה כללי העברה. אתם יכולים להגדיר כמה כללי העברה שישתמשו באותה כתובת IP פנימית (VIP) ויפנו לאותו proxy של HTTP או HTTPS, כל עוד השילוב הכולל של כתובת ה-IP, היציאה והפרוטוקול הוא ייחודי לכל כלל העברה. כך תוכלו להשתמש במאזן עומסים יחיד עם מפת URL משותפת כפרוקסי לכמה אפליקציות.

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

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

forwardingRules.insert method
כתובת IP אזורית

addresses.insert method
סכמת איזון עומסים

INTERNAL_MANAGED
כתובת IP (אופציונלי)

SHARED_LOADBALANCER_VIP
ניתוב מהלקוח לקצה הקדמי של מאזן העומסים

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

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

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

מצב מאזן העומסים שיוך לרשת VPC
‫ Regional internal Application Load Balancer

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

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

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

  • רשת VPC: צריך להשתמש ברשת VPC במצב מותאם אישית שהוגדרה עם הדגל --enable-ula-internal-ipv6.
  • תת-רשת של כלל העברה: תת-הרשת הזו צריכה להיות תת-רשת עם תמיכה כפולה (IPv4_IPv6) או IPV6_ONLY, עם הערך ipv6-access-type שמוגדר ל-INTERNAL.

אפשרויות להקצאת כתובות IPv6. כלל ההעברה צריך להפנות לטווח של כתובות IPv6‏ /96 מתוך טווח כתובות ה-IPv6 הפנימיות של תת-הרשת /64. כשמגדירים את כלל ההעברה עם הדגל --ip-version=IPV6, Cloud de Confianceהמערכת מקצה באופן אוטומטי קידומת /96 IPv6 אקראית מתוך הטווח של רשת המשנה.

מגבלות. כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-Google Cloud CLI או ב-API. ב Cloud de Confiance מסוף אין תמיכה בציון כתובות IPv6 זמניות מותאמות אישית לכללי העברה.

שרת proxy יעד

שרת proxy של HTTP או HTTPS ביעד מפסיק חיבורי HTTP(S) מלקוחות. שרת ה-Proxy מסוג HTTP(S) מתייעץ עם מפת URL כדי לקבוע איך לנתב את תעבורת הנתונים לשרתי קצה עורפיים. שרת proxy של HTTPS ליעד משתמש באישור SSL כדי לאמת את עצמו מול לקוחות.

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

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

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

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

טיפול בכותרת X-Forwarded-For

מאזן העומסים מוסיף שתי כתובות IP לכותרת X-Forwarded-For:

  • כתובת ה-IP של הלקוח שמתחבר למאזן העומסים
  • כתובת ה-IP של כלל ההעברה של מאזן העומסים

אם אין כותרת X-Forwarded-For בבקשה הנכנסת, שתי כתובות ה-IP האלה הן הערך המלא של הכותרת. אם בבקשה יש כותרת X-Forwarded-For, פרטים אחרים, כמו כתובות ה-IP שנרשמו על ידי שרתי proxy בדרך למאזן העומסים, נשמרים לפני שתי כתובות ה-IP.

אם אתם מפעילים שרת proxy כשרת בק-אנד, בדרך כלל ה-proxy מוסיף עוד מידע לכותרת X-Forwarded-For, ויכול להיות שתצטרכו להתחשב בזה בתוכנה שלכם. הבקשות שעוברות דרך ה-Proxy ממאזן העומסים מגיעות מכתובת IP בתת-רשת של שרת proxy בלבד, וה-Proxy בשרת העורפי (backend instance) עשוי לתעד את הכתובת הזו וגם את כתובת ה-IP של השרת העורפי עצמו.

מאזן העומסים הפנימי של אפליקציות משתמש באמצעי אבטחה ספציפיים לכותרת X-Forwarded-For:

  • ניקוי (הסרה) של כותרות. אם יש שרת proxy ביניים בין הלקוח לבין מאזן העומסים, מאזן העומסים מתייחס לכותרות X-Forwarded-For הנכנסות כאל כותרות לא מהימנות ומסיר את הכותרת כדי למנוע זיוף של כתובות IP. אין אפשרות להגדיר שינוי בהתנהגות הזו.
  • Append Behavior (הוספת התנהגות). אפשר להשתמש בכותרות בהתאמה אישית כדי ליצור כותרת חדשה X-Forwarded-For ולהוסיף את כתובת ה-IP של הלקוח וכתובת ה-IP של השרת. עם זאת, במקרה הזה, כתובת ה-IP של הלקוח מנקודת המבט של מאזן העומסים היא כתובת ה-IP של שרת ה-proxy הביניים ולא כתובת ה-IP המקורית של הלקוח.

שמירה על כתובות ה-IP של הלקוחות באמצעות שרתי proxy ביניים

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

כדי לשמור את כתובת ה-IP של הלקוח באופן מהימן, מומלץ לפעול לפי ההמלצות הבאות:

  • שימוש בכותרות מותאמות אישית. מגדירים את השרת הפרוקסי הביניים כך שיחדיר את כתובת ה-IP המאומתת של הלקוח לכותרת בהתאמה אישית. לדוגמה, X-Original-Client-IP או X-Client-IP.
  • הגדרת העברה מאזן העומסים הפנימי של אפליקציות (ALB) מעביר כותרות מותאמות אישית לקצה העורפי ללא שינוי.
  • עדכון קצה עורפי. מעדכנים את אפליקציית ה-Backend כדי לקרוא את כתובת ה-IP של הלקוח מהכותרת החדשה בהתאמה אישית במקום מ-X-Forwarded-For.

אישורי SSL

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

מאזני עומסים פנימיים אזוריים של אפליקציות תומכים באישורי SSL ב-Compute Engine בניהול עצמי.

מפות של כתובות URL

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

בטבלה הבאה מפורט סוג מפת ה-URL שנדרש על ידי מאזני עומסים פנימיים של אפליקציות בכל מצב:

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

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

שירות קצה עורפי מספק מאזן העומסים מידע על ההגדרות, כדי שהוא יוכל להפנות בקשות לקצה העורפי שלו – למשל, קבוצות מופעים של Compute Engine או קבוצות של נקודות קצה ברשת (NEGs). מידע נוסף על שירותי קצה עורפי זמין במאמר סקירה כללית על שירותי קצה עורפי.

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

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

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

הפרוטוקול לקצה העורפי

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

  • ‫HTTP, שמשתמש ב-HTTP/1.1 ולא ב-TLS
  • ‫HTTPS, שמשתמש ב-HTTP/1.1 וב-TLS
  • ‫HTTP/2, שמשתמש ב-HTTP/2 וב-TLS (אין תמיכה ב-HTTP/2 ללא הצפנה).
  • ‫H2C, שמשתמש ב-HTTP/2 דרך TCP. לא נדרש פרוטוקול TLS. אין תמיכה ב-H2C במאזני עומסים קלאסיים של אפליקציות (ALB).

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

פרוטוקול שירות הבק-אנד לא צריך להיות זהה לפרוטוקול שבו הלקוחות משתמשים כדי לתקשר עם מאזן העומסים. לדוגמה, לקוחות יכולים לשלוח בקשות למאזן העומסים באמצעות HTTP/2, אבל מאזן העומסים יכול לתקשר עם בק-אנד באמצעות HTTP/1.1 (HTTP או HTTPS).

קצה עורפי

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

  • קבוצות של מכונות
  • קבוצות אזוריות של נקודות קצה ברשת (Zonal NEGs)
  • ‫NEGs באינטרנט
  • קבוצות NEG היברידיות

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

ההגבלות על המיקום של השרתים העורפיים תלויות בסוג השרת העורפי.

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

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

    • כשיוצרים קבוצות אזוריות של נקודות קצה ברשת (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 של רשת המשנה ל-INTERNAL.

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

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

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

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

חלוקת משנה של הקצה העורפי

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

כברירת מחדל, חלוקת המשנה של ה-Backend מושבתת. מידע על הפעלת התכונה הזו זמין במאמר Backend subsetting for regional internal Application Load Balancers.

בדיקות תקינות

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

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

פרוטוקול בדיקת תקינות

אמנם אין חובה להשתמש בבדיקת תקינות, ולא תמיד אפשר לעשות זאת, אבל מומלץ להשתמש בבדיקת תקינות שהפרוטוקול שלה תואם לפרוטוקול של שירות ה-Backend. לדוגמה, בדיקת תקינות של HTTP/2 בודקת בצורה הכי מדויקת את הקישוריות של HTTP/2 לשרתי קצה עורפיים. לעומת זאת, מאזני עומסים פנימיים של אפליקציות (ALB) שמשתמשים בשרתי קצה היברידיים של NEG לא תומכים בבדיקות תקינות של gRPC. רשימת הפרוטוקולים הנתמכים לבדיקות תקינות מופיעה בקטע בדיקות תקינות במאמר על התכונות של איזון העומסים.

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

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

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

כללי חומת אש

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

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

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

גישת לקוח

הלקוחות יכולים להיות באותה רשת או ברשת VPC שמחוברת באמצעות קישור בין רשתות VPC שכנות.

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

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

הגישה הגלובלית מושבתת הגישה הגלובלית מופעלת
הלקוחות צריכים להיות באותו אזור כמו מאזן העומסים. הם גם צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering. הלקוחות יכולים להיות בכל אזור. הם עדיין צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering (קישור בין רשתות VPC).
לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה צריכים להיות באותו אזור כמו מאזן העומסים. לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה יכולים להיות בכל אזור.

תמיכה ב-GKE

ב-GKE נעשה שימוש במאזני עומסים פנימיים של אפליקציות (ALB) בדרכים הבאות:

  • שערי כניסה פנימיים שנוצרו באמצעות בקר GKE Gateway יכולים להשתמש בכל מצב של מאזן עומסים פנימי של אפליקציות (ALB). אתם שולטים במצב של מאזן העומסים על ידי בחירה של GatewayClass. בקר GKE Gateway תמיד משתמש בGCE_VM_IP_PORT קצה עורפי של NEG אזורי.

  • ‫Internal Ingresses שנוצרו באמצעות GKE Ingress controller הם תמיד מאזני עומסים פנימיים אזוריים של אפליקציות. בקר ה-Ingress של GKE תמיד משתמש בקצה עורפי של GCE_VM_IP_PORT Zonal NEG.

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

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

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

רשתות משנה וכתובת IP רכיבי קצה קדמי רכיבי קצה עורפי

יוצרים את הרשתות ורשתות המשנה הנדרשות (כולל רשת המשנה של ה-proxy בלבד) בפרויקט המארח של ה-VPC המשותף.

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

 כתובת ה-IP הפנימית האזורית, כלל ההעברה, ה-proxy של HTTP(S) היעד ומפת URL המשויכת צריכים להיות מוגדרים באותו פרויקט. הפרויקט הזה יכול להיות פרויקט מארח או פרויקט שירות. אפשר לבצע אחת מהפעולות הבאות:
  • יצירת שירותי קצה עורפיים וקצה עורפי (קבוצות מופעים, NEGs ללא שרת או כל סוג אחר של קצה עורפי נתמך) באותו פרויקט שירות כמו רכיבי הקצה הקדמי.
  • יוצרים שירותים לקצה העורפי וקצוות עורפיים (קבוצות מכונות, NEGs ללא שרת או כל סוג אחר של קצה עורפי נתמך) בכמה פרויקטים של שירותים שנדרשים. מפת URL יחידה יכולה להפנות לשירותי קצה עורפיים בפרויקטים שונים. סוג הפריסה הזה נקרא הפניה לשירות בפרויקט אחר.

כל שירות לקצה העורפי צריך להיות מוגדר באותו פרויקט שאליו מתבצעת ההפניה של ה-backend. בדיקות תקינות שמשויכות לשירותי קצה עורפיים צריכות להיות מוגדרות באותו פרויקט כמו שירות הקצה העורפי.

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

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

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

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

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

בקצה העורפי של אפליקציות serverless בסביבת VPC משותפת

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

הפניה לשירותים בפרויקטים שונים

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

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

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

בעלי השירות יכולים לשמור על אוטונומיה לגבי החשיפה של השירותים שלהם ולשלוט בגישה של המשתמשים לשירותים שלהם באמצעות איזון העומסים. ההרשאה הזו ניתנת באמצעות תפקיד מיוחד ב-IAM שנקרא משתמש בשירותי איזון עומסים ב-Compute (roles/compute.loadBalancerServiceUser).

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

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

הערות לגבי שימוש בהפניה לשירותים בין פרויקטים

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

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

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

במקרה כזה, אדמינים של רשתות או אדמינים של מאזני עומסים בפרויקט שירות א צריכים גישה לשירותי קצה עורפי בפרויקט שירות ב. אדמינים בפרויקט שירות ב' מקצים את התפקיד Compute Load Balancer Services User ‏(roles/compute.loadBalancerServiceUser) לאדמינים של איזון עומסים בפרויקט שירות א' שרוצים להפנות לשירות הקצה העורפי בפרויקט שירות ב'.

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

דוגמה 2: חזית של מאזן עומסים בפרויקט המארח ועורפים בפרויקטים של שירותים

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

במקרה כזה, אדמינים של רשתות או אדמינים של מאזני עומסים בפרויקט המארח צריכים גישה לשירותי קצה עורפי בפרויקט השירות. אדמינים בפרויקט השירות מעניקים את התפקיד 'משתמש בשירותי מאזן עומסים של Compute' (roles/compute.loadBalancerServiceUser) לאדמינים של מאזן עומסים בפרויקט המארח א' שרוצים להפנות לשירות הקצה העורפי בפרויקט השירות.

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

פסק זמן וניסיונות חוזרים

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

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

הזמן הקצוב לתפוגת הבקשה והתגובה. הערך הזה מייצג את משך הזמן המקסימלי שמותר לעבור בין שליחת הבייט הראשון של בקשה מהמאזן עומסים לקצה העורפי לבין החזרת הבייט האחרון של תגובת ה-HTTP מהקצה העורפי למאזן העומסים. אם ה-backend לא מחזיר את תגובת ה-HTTP המלאה למאזן העומסים בתוך מגבלת הזמן הזו, נתוני התגובה שנותרו מושמטים.
  • ל-NEGs ללא שרת בשירות קצה עורפי: 60 דקות
  • לכל סוגי הקצה העורפי האחרים בשירות קצה עורפי: 30 שניות
Client HTTP keepalive timeout

משך הזמן המקסימלי שחיבור ה-TCP בין לקוח לבין פרוקסי Envoy מנוהל של מאזן העומסים יכול להיות במצב המתנה. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP).

 ‫610 שניות
Backend HTTP keepalive timeout

משך הזמן המקסימלי שחיבור ה-TCP בין שרת ה-proxy של Envoy המנוהל של מאזן העומסים לבין קצה עורפי יכול להיות לא פעיל. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP).

 ‫10 דקות (600 שניות)

זמן קצוב לתפוגה של שירות לקצה העורפי

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

לדוגמה, אם רוצים להוריד קובץ בגודל 500MB, והערך של הזמן הקצוב לתפוגה של שירות ה-backend הוא 90 שניות, מאזן העומסים מצפה ש-backend יספק את כל הקובץ בגודל 500MB תוך 90 שניות. יכול להיות שתגדירו את הזמן הקצוב לתפוגה של שירות הקצה העורפי כך שלא יספי לקצה העורפי לשלוח את תגובת ה-HTTP המלאה שלו. במצב הזה, אם מאזן העומסים קיבל לפחות כותרות תגובת HTTP מהקצה העורפי, מאזן העומסים מחזיר את כותרות התגובה המלאות ואת גוף התגובה, עד כמה שאפשר, במסגרת הזמן הקצוב לתפוגה של שירות הקצה העורפי.

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

ערכי הזמן הקצוב לתפוגה של שירות הקצה העורפי יכולים להיות בין 1 ל-2,147,483,647 שניות, אבל ערכים גבוהים יותר לא מעשיים. בנוסף,Cloud de Confiance לא מבטיח שחיבור TCP בסיסי יישאר פתוח למשך כל הזמן הקצוב לתפוגה של שירות הקצה העורפי. מערכות לקוח צריכות להטמיע לוגיקה של ניסיון חוזר במקום להסתמך על חיבור TCP פתוח למשך תקופות ארוכות.

בחיבורי websocket שמשמשים עם מאזני עומסים פנימיים של אפליקציות, חיבורי websocket פעילים לא פועלים לפי הזמן הקצוב לתפוגה של שירות הקצה העורפי. חיבורי WebSocket במצב המתנה נסגרים אחרי שחלף הזמן הקצוב לתפוגה של שירות ה-Backend.

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

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

המסוף

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

gcloud

משתמשים בפקודה gcloud compute backend-services update כדי לשנות את הפרמטר --timeout של משאב שירות לקצה העורפי.

API

שינוי הפרמטר timeoutSec של המשאב regionBackendServices

פסק זמן של keepalive ב-HTTP בצד הלקוח

הזמן הקצוב לתפוגה של הודעת keep-alive ב-HTTP של הלקוח מייצג את משך הזמן המקסימלי שחיבור TCP יכול להיות לא פעיל בין הלקוח (במורד הזרם) לבין שרת proxy של Envoy. ערך ברירת המחדל של הזמן הקצוב לתפוגה של שמירת חיבור הלקוח ב-HTTP הוא 610 שניות. אפשר להגדיר את הזמן הקצוב לתפוגה עם ערך בין 5 ל-1,200 שניות.

זמן קצוב לתפוגה של HTTP keepalive נקרא גם זמן קצוב לתפוגה של TCP idle.

ערך הזמן הקצוב לתפוגה של HTTP keepalive של הלקוח במאזן העומסים צריך להיות גדול יותר מערך הזמן הקצוב לתפוגה של HTTP keepalive (TCP idle) שמשמש לקוחות או שרתי proxy ב-downstream. אם ללקוח במורד הזרם יש פסק זמן ארוך יותר של HTTP keepalive (מצב המתנה של TCP) מאשר פסק הזמן של HTTP keepalive של הלקוח במאזן העומסים, יכול להיות שיתרחש מצב של תחרות. מנקודת המבט של לקוח במורד הזרם, חיבור TCP שנוצר יכול להיות במצב סרק למשך זמן ארוך יותר מהזמן שמותר במאזן העומסים. המשמעות היא שהלקוח במורד הזרם יכול לשלוח חבילות אחרי שמאזן העומסים מחשיב את חיבור ה-TCP כסגור. במקרה כזה, מאזן העומסים מגיב עם מנת TCP reset ‏ (RST).

כשפג הזמן הקצוב לתפוגה של HTTP keepalive של הלקוח, שרת ה-GFE או שרת ה-Envoy proxy שולח TCP FIN ללקוח כדי לסגור את החיבור בצורה תקינה.

פסק זמן ל-keepalive של HTTP בקצה העורפי

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

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

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

הערך של הזמן הקצוב לתפוגה של שמירת החיבור פעיל בבק-אנד של מאזן העומסים צריך להיות קטן מהערך של הזמן הקצוב לתפוגה של שמירת החיבור פעיל שמשמש את התוכנה שפועלת בבק-אנד. כך נמנע מצב של מרוץ תהליכים שבו מערכת ההפעלה של השרתים העורפיים עשויה לסגור חיבורי TCP עם איפוס TCP ‏ (RST). אי אפשר להגדיר את ערך הזמן הקצוב לתפוגה של הבק-אנד של מאזן העומסים, ולכן צריך להגדיר את תוכנת הבק-אנד כך שערך הזמן הקצוב לתפוגה של ה-HTTP keepalive (TCP idle) יהיה גדול מ-600 שניות.

כשזמן ההמתנה של שרת הבק-אנד מסוג HTTP keepalive מסתיים, שרת ה-GFE או שרת ה-Envoy proxy שולח TCP FIN למכונת ה-VM של הבק-אנד כדי לסגור את החיבור בצורה תקינה.

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

תוכנות לשרתי אינטרנט פרמטר הגדרת ברירת המחדל הגדרה מומלצת
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

ניסיונות חוזרים

כדי להגדיר ניסיונות חוזרים, אפשר להשתמש במדיניות ניסיונות חוזרים במפת כתובות ה-URL. מספר ברירת המחדל של הניסיונות החוזרים (numRetries) הוא 1. הערך המקסימלי שאפשר להגדיר ל-perTryTimeout הוא 24 שעות.

ללא מדיניות ניסיון חוזר, בקשות לא מוצלחות שאין להן גוף HTTP (לדוגמה, בקשות GET) שמובילות לתגובות HTTP 502, 503 או 504, ינסו שוב פעם אחת.

לא מתבצע ניסיון חוזר של בקשות HTTP POST.

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

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

גישה לרשתות מחוברות

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

  • קישור בין רשתות VPC שכנות (peering)
  • ‫Cloud VPN ו-Cloud Interconnect

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

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

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

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

טבלה: הגדרות נתמכות של שיוך סשנים
מוצר אפשרויות של שיוך סשן
  • ללא (NONE)
  • כתובת ה-IP של הלקוח (CLIENT_IP)
  • קובץ Cookie שנוצר (GENERATED_COOKIE)
  • שדה כותרת (HEADER_FIELD)
  • קובץ Cookie של HTTP‏ (HTTP_COOKIE)
  • זיקה מבוססת-קובצי Cookie עם שמירת מצב (STRONG_COOKIE_AFFINITY)

חשוב גם לזכור:

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

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

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

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

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

אפשר לסווג את הזיקה לסשן (session affinity) במאזני עומסים פנימיים של אפליקציות לאחת מהקטגוריות הבאות:
  • זיקה לסשן שמבוססת על גיבוב (NONE, CLIENT_IP)
  • זיקה לסשן שמבוססת על כותרת HTTP‏ (HEADER_FIELD)
  • זיקה לסשן שמבוססת על קובצי Cookie‏ (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

זיקה לסשן מבוססת גיבוב

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

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

ללא

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

זיקה לסשן (session affinity) שמבוססת על כותרת HTTP

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

יש תמיכה בהעדפה של שדה כותרת אם מתקיימים התנאים הבאים:

  • מדיניות המיקום של איזון העומסים היא RING_HASH או MAGLEV.
  • השדה consistentHash בשירות העורפי מציין את השם של כותרת ה-HTTP (httpHeaderName).

הזיקה לסשן שמבוססת על קובצי Cookie יכולה להיות מהסוגים הבאים:

כשמשתמשים בזיקה לקובץ Cookie שנוצר (GENERATED_COOKIE), מאזן העומסים כולל קובץ Cookie של HTTP בכותרת Set-Cookie בתגובה לבקשת ה-HTTP הראשונית.

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

מוצר שם קובץ ה-Cookie
מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים GCILB
מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) GCILB

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

אפשר להגדיר את ערך ה-TTL (אורך החיים) של קובץ ה-Cookie בין 0 ל-1,209,600 שניות (כולל) באמצעות הפרמטר affinityCookieTtlSec של שירות ה-Backend. אם לא מציינים את affinityCookieTtlSec, ערך ברירת המחדל של TTL הוא 0.

כשהלקוח כולל את קובץ ה-Cookie של הזיקה לסשן שנוצר בכותרת הבקשה של בקשות HTTP‏ (Cookie), מאזן העומסים מפנה את הבקשות האלה לאותו מופע או נקודת קצה של קצה עורפי, כל עוד קובץ ה-Cookie של הזיקה לסשן תקף. כדי לעשות זאת, ממפים את ערך קובץ ה-Cookie לאינדקס שמפנה למופע ספציפי של שרת עורפי (backend instance) או לנקודת קצה, ומוודאים שהדרישות של זיקה לסשן (session affinity) שנוצרות מתקיימות.

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

  • לקבוצות של שרתי עורף, משתמשים בRATEמצב איזון.
  • כדי להגדיר את localityLbPolicy של שירות הקצה העורפי, משתמשים ב-RING_HASH או ב-MAGLEV. אם לא מגדירים במפורש את localityLbPolicy, מאזן העומסים משתמש ב-MAGLEV כברירת מחדל משתמעת.

מידע נוסף זמין במאמר בנושא איבוד שיוך לסשן.

כשמשתמשים בזיקה שמבוססת על קובצי Cookie של HTTP ‏ (HTTP_COOKIE), מאזן העומסים כולל קובץ Cookie של HTTP בכותרת Set-Cookie בתגובה לבקשת ה-HTTP הראשונית. אתם מציינים את השם, הנתיב ואורך החיים (TTL) של קובץ ה-Cookie.

כל מאזני העומסים של האפליקציות תומכים בהעדפה שמבוססת על קובצי HTTP Cookie.

אפשר להגדיר את ערכי ה-TTL של קובץ ה-Cookie באמצעות שניות, חלקי שניות (בננו-שניות) או שניות בתוספת חלקי שניות (בננו-שניות). לשם כך, משתמשים בפרמטרים הבאים של שירות ה-Backend ובערכים התקינים:

  • אפשר להגדיר את consistentHash.httpCookie.ttl.seconds לערך בין 0 לבין 315576000000 (כולל).
  • אפשר להגדיר את consistentHash.httpCookie.ttl.nanos לערך בין 0 לבין 999999999 (כולל). יחידות הזמן הן ננו-שניות, ולכן 999999999 שווה ל-.999999999 שניות.

אם לא מציינים את consistentHash.httpCookie.ttl.seconds וגם לא את consistentHash.httpCookie.ttl.nanos, המערכת משתמשת בערך של פרמטר שירות ה-backend‏ affinityCookieTtlSec. אם לא מציינים את affinityCookieTtlSec, ערך ברירת המחדל של TTL הוא 0.

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

כדי להשתמש בהצמדה של קובצי Cookie ב-HTTP, צריך להגדיר את מצב איזון העומסים ואת ההגדרות הבאות:localityLbPolicy

  • לקבוצות של שרתי עורף, משתמשים בRATEמצב איזון.
  • כדי להגדיר את localityLbPolicy של שירות הקצה העורפי, משתמשים ב-RING_HASH או ב-MAGLEV. אם לא מגדירים במפורש את localityLbPolicy, מאזן העומסים משתמש ב-MAGLEV כברירת מחדל משתמעת.

מידע נוסף זמין במאמר בנושא איבוד שיוך לסשן.

זיקה לסשן מבוססת-קובצי Cookie עם שמירת מצב

כשמשתמשים בזיקה מבוססת-Cookie עם שמירת מצב (STRONG_COOKIE_AFFINITY), מאזן העומסים כולל קובץ Cookie של HTTP בכותרת Set-Cookie בתגובה לבקשת ה-HTTP הראשונית. מציינים את השם, הנתיב ואורך החיים (TTL) של קובץ ה-Cookie.

מאזני העומסים הבאים תומכים בהעדפה מבוססת-קובצי Cookie עם שמירת מצב:

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

אפשר להגדיר את ערכי ה-TTL של קובץ ה-Cookie בשניות, בשבריר שנייה (כננו-שניות) או בשניות ובשבריר שנייה (כננו-שניות). המשך שמיוצג על ידי strongSessionAffinityCookie.ttl לא יכול להיות ארוך משבועיים (1,209,600 שניות).

הערך של קובץ ה-Cookie מזהה מופע או נקודת קצה נבחרים בעורף האתר על ידי קידוד המופע או נקודת הקצה שנבחרו בערך עצמו. כל עוד קובץ ה-Cookie תקף, אם הלקוח כולל את קובץ ה-Cookie של שיוך הסשן בCookie כותרת הבקשה של בקשות HTTP הבאות, מאזן העומסים מפנה את הבקשות האלה למופע או לנקודת קצה של בק-אנד שנבחרו.

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

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

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

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

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

מידע נוסף זמין במאמר בנושא איבוד שיוך לסשן.

המשמעות של TTL אפס עבור קירבה על בסיס קובצי Cookie

לכל הזיקות להפעלות שמבוססות על קובצי Cookie, כמו זיקה לקובץ Cookie שנוצר, זיקה לקובץ Cookie‏ HTTP וזיקה מבוססת-מצב לקובץ Cookie, יש מאפיין TTL.

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

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

  • לקוחות אחרים מתייחסים לסשן כאל בקשת HTTP אחת, ומוחקים את קובץ ה-Cookie מיד לאחר מכן.

איבוד השיוך לסשן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעבר אוטומטי לגיבוי (failover) לקצוות עורפיים תקינים באותו אזור.

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

 הפונקציה מחזירה HTTP 503

זמינות גבוהה ומעבר לשני אזורים במקרה של כשל

למאזני עומסים פנימיים אזוריים של אפליקציות

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

תמיכה ב-WebSocket

Cloud de Confiance מאזני עומסים שמבוססים על HTTP(S) תומכים בפרוטוקול WebSocket כשמשתמשים ב-HTTP או ב-HTTPS כפרוטוקול לבק-אנד. לא צריך להגדיר את איזון העומסים כדי להעביר חיבורי WebSocket דרך proxy.

פרוטוקול ה-WebSocket מספק ערוץ תקשורת דו-כיווני בין לקוחות לבין מאזן העומסים. מידע נוסף זמין ב-RFC 6455.

פרוטוקול ה-WebSocket פועל באופן הבא:

  1. מאזן העומסים מזהה בקשת websocket‏ Upgrade מלקוח HTTP או HTTPS. הבקשה מכילה את הכותרות Connection: Upgrade ו-Upgrade: websocket, ואחריהן כותרות בקשה רלוונטיות אחרות שקשורות ל-WebSocket.
  2. הקצה העורפי שולח תגובה של websocket Upgrade. מופע ה-backend שולח תגובה 101 switching protocol עם כותרות Connection: Upgrade ו-Upgrade: websocket וכותרות תגובה אחרות שקשורות ל-WebSocket.
  3. מאזן העומסים משמש כשרת proxy לתנועה דו-כיוונית למשך החיבור הנוכחי.

אם שרת עורפי (backend instance) מחזיר קוד סטטוס 426 או 502, מאזן העומסים (LB) סוגר את החיבור.

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

תמיכה ב-HTTP/2

‫HTTP/2 הוא עדכון משמעותי של פרוטוקול HTTP/1. יש 2 מצבים של תמיכה ב-HTTP/2:

  • ‫HTTP/2 over TLS
  • Cleartext HTTP/2 over TCP

‫HTTP/2 over TLS

יש תמיכה ב-HTTP/2 over TLS לחיבורים בין לקוחות לבין מאזן עומסים חיצוני של אפליקציות (ALB), ולחיבורים בין מאזן העומסים לבין הקצה העורפי שלו.

מאזן העומסים מנהל משא ומתן אוטומטי עם לקוחות לגבי HTTP/2 כחלק משיטת הלחיצה של TLS, באמצעות תוסף ה-TLS של ALPN. גם אם מאזן העומסים מוגדר לשימוש ב-HTTPS, לקוחות מודרניים משתמשים ב-HTTP/2 כברירת מחדל. השליטה בזה מתבצעת בצד הלקוח, ולא במאזן העומסים.

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

כדי להשתמש ב-HTTP/2 דרך TLS, צריך להפעיל TLS בקצה העורפי ולהגדיר את פרוטוקול שירות הקצה העורפי לערך HTTP2. מידע נוסף זמין במאמר הצפנה ממאזן העומסים אל השרתים העורפיים.

מספר מקסימלי של סטרימינג בו-זמני ב-HTTP/2

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

במקרים שבהם מאזן העומסים משתמש ב-HTTP/2 כדי לתקשר עם שרת שפועל במכונה וירטואלית, מאזן העומסים מתחשב בערך SETTINGS_MAX_CONCURRENT_STREAMS שמוגדר בשרת, עד לערך מקסימלי של 100. בכיוון הבקשה (מאזן העומסיםCloud de Confiance ← שרת gRPC), מאזן העומסים משתמש בפריים SETTINGS הראשוני משרת gRPC כדי לקבוע כמה סטרימים לכל חיבור יכולים להיות בשימוש בו-זמנית. אם השרת מפרסם ערך גבוה מ-100, מאזן העומסים משתמש ב-100 כמספר המקסימלי של הזרמים בו-זמנית. אם מפרסמים ערך של אפס, מאזן העומסים לא יכול להעביר בקשות לשרת, וזה עלול לגרום לשגיאות.

גודל דינמי של טבלת כותרות HTTP/2

פרוטוקול HTTP/2 משפר משמעותית את פרוטוקול HTTP/1.1 באמצעות תכונות כמו ריבוב (multiplexing) ודחיסת כותרות HPACK. פרוטוקול HPACK משתמש בטבלה דינמית שמשפרת את הדחיסה של הכותרות, וכך הופכת את הכול למהיר יותר. כדי להבין את ההשפעה של שינויים דינמיים בגודל טבלת הכותרות ב-HTTP/2, איך התכונה הזו יכולה לשפר את הביצועים ואיך באג ספציפי בספריות לקוח שונות של HTTP יכול לגרום לבעיות בדחיסת כותרות HPACK, אפשר לעיין במאמר בקהילה.

מגבלות של HTTP/2

  • יכול להיות שחיבור HTTP/2 בין מאזן העומסים לבין המופע ידרוש הרבה יותר חיבורי TCP למופע מאשר חיבור HTTP או HTTPS. אי אפשר להשתמש ב-HTTP/2 כדי לצמצם את מספר החיבורים האלה באמצעות HTTP או HTTPS. כתוצאה מכך, יכול להיות שתראו חביון גבוה בעורף המערכת, כי החיבורים לעורף המערכת מתבצעים בתדירות גבוהה יותר.
  • פרוטוקול HTTP/2 בין מאזן העומסים לבין ה-Backend לא תומך בהרצת פרוטוקול WebSocket על פני זרם יחיד של חיבור HTTP/2 ‏ (RFC 8441).
  • ‫HTTP/2 בין מאזן העומסים לבין ה-Backend לא תומך ב-Server Push.
  • שיעור השגיאות ונפח הבקשות של gRPC לא מוצגים ב-Cloud de Confiance API או במסוף Cloud de Confiance . אם נקודת הקצה של gRPC מחזירה שגיאה, קוד סטטוס של HTTP‏ 200 OK יופיע ביומני מאזן העומסים ובנתוני המעקב.

‫HTTP/2 over cleartext TCP

‫HTTP/2 over cleartext TCP, שמיוצג על ידי המחרוזת h2c לפי RFC 7540, מאפשר לכם להשתמש ב-HTTP/2 ללא הצפנת TLS. היא נתמכת בחיבורים הבאים:

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

  • מאזן עומסים לקצה העורפי שלו: נתמך על ידי הגדרת הפרוטוקול של שירות הקצה העורפי ל-H2C.

תמיכה ב-H2C זמינה גם למאזני עומסים שנוצרו באמצעות בקר GKE Gateway ו-Cloud Service Mesh, אבל היא לא זמינה למאזני עומסים קלאסיים של אפליקציות.

תמיכה ב-gRPC

‫gRPC היא מסגרת קוד פתוח לקריאות לשירות מרוחק (RPC). היא מבוססת על תקן HTTP/2. תרחישי שימוש ב-gRPC כוללים את הדוגמאות הבאות:

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

כדי להשתמש ב-gRPC עם האפליקציות שלכם, אתם צריכים להעביר בקשות באמצעות proxy מקצה לקצה דרך HTTP/2. Cloud de Confiance כדי לעשות את זה, יוצרים מאזן עומסים של אפליקציות עם אחת מההגדרות הבאות:

  • פרוטוקול HTTP/2 over TLS בין הלקוח לבין מאזן העומסים ופרוטוקול H2C בין מאזן העומסים לבין הקצה העורפי: יוצרים מאזן עומסים ב-HTTPS (שמוגדר עם שרת proxy של HTTPS יעד ואישור SSL). בנוסף, אתם יכולים להגדיר את מאזן העומסים להשתמש ב-HTTP/2 לחיבורים לא מוצפנים בין מאזן העומסים לבין הבק-אנד שלו. כדי לעשות זאת, צריך להגדיר את פרוטוקול שירות לקצה העורפי ל-H2C.

  • תעבורה מוצפנת מקצה לקצה באמצעות HTTP/2 over TLS: אתם יוצרים מאזן עומסים של HTTPS (שמוגדר עם שרת proxy של HTTPS יעד ואישור SSL). מאזן העומסים מנהל משא ומתן עם לקוחות לגבי HTTP/2 כחלק מלחיצת היד של SSL, באמצעות תוסף ה-TLS של ALPN.

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

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

תמיכה ב-TLS

כברירת מחדל, פרוקסי יעד של HTTPS מקבל רק TLS 1.0,‏ 1.1,‏ 1.2 ו-1.3 כשמסתיימות בקשות SSL של לקוחות.

כשמאזן עומסים של אפליקציות פנימי משתמש ב-HTTPS כפרוטוקול של שירות לקצה העורפי, הוא יכול לנהל משא ומתן על TLS 1.2 או 1.3 עם הקצה העורפי.

תמיכה ב-TLS הדדי

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

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

מידע נוסף על mTLS זמין במאמר בנושא אימות TLS בו-זמני (mTLS).

מגבלות

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

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

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

  • לקוחות שמתחברים למאזן עומסים פנימי של אפליקציות (ALB) צריכים להשתמש בגרסה 1.1 של HTTP ואילך. אין תמיכה ב-HTTP 1.0.

  • ‫Cloud de Confiance לא מציג אזהרה אם ברשת המשנה של שרת ה-proxy בלבד נגמרות כתובות ה-IP.

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

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

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

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