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

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

איך החיבורים פועלים

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

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

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

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

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

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

  • הלקוחות יכולים לתקשר עם מאזן העומסים באמצעות הפרוטוקולים HTTP/1.0,‏ HTTP/1.1,‏ HTTP/2 או HTTP/3.
  • כשמשתמשים ב-HTTPS, לקוחות מודרניים משתמשים ב-HTTP/2 כברירת מחדל. ההגדרה הזו נקבעת בצד הלקוח, ולא במאזן העומסים ב-HTTPS.
  • אי אפשר להשבית את HTTP/2 על ידי שינוי ההגדרות במאזן העומסים. עם זאת, אתם יכולים להגדיר לקוחות מסוימים כך שישתמשו ב-HTTP 1.1 במקום ב-HTTP/2. לדוגמה, עם curl, משתמשים בפרמטר --http1.1.
  • מאזני עומסים חיצוניים של אפליקציות תומכים בתגובה HTTP/1.1 100 Continue.

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

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

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

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

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

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

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

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

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

נתיבי ניתוב מיוחדים

‫Google Cloud משתמש בנתיבים מיוחדים שלא מוגדרים ברשת ה-VPC כדי לנתב חבילות לסוגי התנועה הבאים:

Google Cloud משתמש בנתיבי רשתות משנה של רשתות משנה של שרתי proxy בלבד כדי לנתב מנות לסוגי התנועה הבאים:

  • כשמשתמשים בבדיקות תקינות מבוזרות של Envoy.

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

סיום TLS

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

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

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

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

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

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

הזמן הקצוב להגדרת החיבור פג

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

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

זמן קצוב לתפוגה של TLS בצד הלקוח

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

  • במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), שרת ה-proxy של מאזן העומסים הוא תוכנת Envoy.
 ‫10 שניות
זמן קצוב לתפוגה של HTTP keepalive של הלקוח

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

  • במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), שרת ה-proxy של מאזן העומסים הוא תוכנת Envoy.
 ‫610 שניות
זמן קצוב לתפוגה של HTTP keepalive לקצה העורפי

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

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

‫1 אי אפשר להגדיר לקצוות עורפיים של קבוצות נקודות קצה ברשת (NEG) ללא שרת (serverless). אי אפשר להגדיר בקטגוריות קצה עורפי.

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

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

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

מומלץ להגדיר את זמן הקצוב לתפוגה של שירות הקצה העורפי לפרק הזמן הארוך ביותר שצפוי להידרש לקצה העורפי כדי לעבד תגובת HTTP. אם התוכנה שפועלת בקצה העורפי צריכה יותר זמן כדי לעבד בקשת HTTP ולהחזיר את התגובה המלאה, מומלץ להגדיל את זמן הקצוב לתפוגה של השירות לקצה העורפי. לדוגמה, מומלץ להגדיל את זמן הקצוב לתפוגה אם מופיעות תגובות של קוד סטטוס HTTP 408 עם שגיאות jsonPayload.statusDetail client_timed_out.

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

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

המסוף

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

gcloud

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

API

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

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

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

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

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

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

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

זמן קצוב לתפוגה של HTTP keepalive בצד הלקוח

זמן הקצוב לתפוגה של HTTP keepalive של הלקוח מייצג את משך הזמן המקסימלי שבו חיבור TCP יכול להיות לא פעיל בין הלקוח (במורד הזרם) לבין אחד מסוגי שרתי ה-proxy הבאים:

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

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

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

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

המסוף

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

gcloud

במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), משתמשים בפקודה gcloud compute target-http-proxies update או בפקודה gcloud compute target-https-proxies update כדי לשנות את הפרמטר --http-keep-alive-timeout-sec של שרת ה-Proxy ל-HTTP או של שרת ה-Proxy ל-HTTPS.

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

  1. יוצרים שרת proxy חדש לחלוקת העומס עם הגדרות הזמן הקצוב לתפוגה הרצויות.
  2. משכפלים את כל ההגדרות האחרות משרת proxy לחלוקת העומס הנוכחי לשרת proxy לחלוקת העומס החדש. בשרתי proxy של HTTPS ביעד, צריך לקשר את כל אישורי ה-SSL או מפות האישורים לשרת ה-proxy החדש ביעד.
  3. מעדכנים את כללי ההעברה כך שיפנו לשרת ה-Proxy החדש לחלוקת העומס.
  4. מוחקים את שרת ה-proxy הקודם לחלוקת העומס.

API

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

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

  1. יוצרים שרת proxy חדש לחלוקת העומס עם הגדרות הזמן הקצוב לתפוגה הרצויות.
  2. משכפלים את כל ההגדרות האחרות משרת proxy לחלוקת העומס הנוכחי לשרת proxy לחלוקת העומס החדש. בשרתי proxy של HTTPS ביעד, צריך לקשר את כל אישורי ה-SSL או מפות האישורים לשרת ה-proxy החדש ביעד.
  3. מעדכנים את כללי ההעברה כך שיפנו לשרת ה-Proxy החדש לחלוקת העומס.
  4. מוחקים את שרת ה-proxy הקודם לחלוקת העומס.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בקשות HTTP POST לא נשלחות שוב.

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

פרוטוקול WebSocket נתמך ב-GKE Ingress.

טיפול בבקשות ובתגובות לא חוקיות

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

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

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

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

‫1 שרת ה-proxy מחזיר תגובת HTTP 411 לבקשה, אבל אז מנסה לנתח את גוף הבקשה שלא חולק לחלקים כבקשה נוספת. אם הגוף ללא ה-chunking הוא בעצמו בקשת HTTP תקינה, הוא מנותח ונשלח לקצה העורפי.

טיפול בבקשות

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

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

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

טיפול בתגובות

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

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

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

בזמן הטיפול בבקשה ובתגובה, מאזן העומסים עשוי להסיר או להחליף כותרות hop-by-hop ב-HTTP/1.1 לפני העברתן ליעד המיועד.

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

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

  • ‫RATE, למשל קבוצות של מכונות או קבוצות של נקודות קצה ברשת (NEG), הוא המספר המקסימלי של בקשות (שאילתות) לשנייה (RPS, ‏ QPS). אם כל ה-backends נמצאים בקיבולת המקסימלית או מעבר לה, יכול להיות חריגה מהיעד המקסימלי של RPS/QPS.

  • ‫UTILIZATION הוא ניצול ה-VMs בקצה העורפי בקבוצת מכונות.

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

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

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

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

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

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

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

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

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

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

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

חשוב לדעת:

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

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

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

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

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

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

זיקה לסשן (session affinity) שמבוססת על גיבוב (hash)

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

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

ללא

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

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

ערך ברירת המחדל של הזיקה לסשן הוא NONE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כל מאזני העומסים של האפליקציות תומכים בשיוך (affinity) מבוסס-קובצי Cookie של HTTP.

אפשר להגדיר את ערכי ה-TTL של קובצי ה-cookie בשניות, בחלקי שניות (בננו-שניות) או בשניות ובחלקי שניות (בננו-שניות), באמצעות הפרמטרים הבאים של שירות לקצה העורפי והערכים התקינים:

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

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

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

כדי להשתמש ב-HTTP cookie affinity, צריך להגדיר את מצב האיזון הבא ואת ההגדרות של localityLbPolicy:

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

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

זיקה לסשן (session affinity) מבוססת-קובצי Cookie עם שמירת מצב (stateful)

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

מאזני העומסים הבאים תומכים בשיוך (affinity) מבוסס-קובצי Cookie עם שמירת מצב:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אובדן הזיקה לסשן (session affinity)

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

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

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

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

    • הוספת מכונות או נקודות קצה חדשות:

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

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

      • אתם מסירים מכונה כלשהי מקצה עורפי של קבוצת מכונות.
      • התאמה אוטומטית לעומס (autoscaling) או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים כל מכונה מה-backend של קבוצת מופעי מכונה מנוהלים.
      • אתם מסירים נקודת קצה (endpoint) כלשהי מקצה עורפי של NEG.
      • מסירים משירות הקצה העורפי את כל קבוצות המכונות או ה-NEG הקיימות שאינן ריקות.

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

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