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

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

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

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

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

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

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

בהתאם להגדרת שירות לקצה העורפי, הפרוטוקול שבו משתמשים שרתי proxy של Envoy כדי להתחבר לבק-אנד יכול להיות HTTP,‏ HTTPS או HTTP/2. אם הפרוטוקול הוא HTTP או HTTPS, הגרסה של HTTP היא HTTP 1.1. הפרוטוקול HTTP keepalive מופעל כברירת מחדל, כפי שמצוין במפרט HTTP 1.1. פרוקסי Envoy מגדיר את הזמן הקצוב לתפוגה של חיבור HTTP פעיל של הלקוח ואת הזמן הקצוב לתפוגה של חיבור פעיל של ה-backend לערך ברירת מחדל של 600 שניות כל אחד. אפשר לעדכן את משך הזמן הקצוב לתפוגה של HTTP keepalive בצד הלקוח, אבל משך הזמן הקצוב לתפוגה של 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 של המקור של המנות, כפי שהיא נראית בבק-אנד, לא זהה לGoogle Cloud כתובת ה-IP החיצונית של מאזן העומסים. במילים אחרות, יש שני חיבורי TCP.

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

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

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

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

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

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

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

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

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

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

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

סיום TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

gcloud

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

API

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

gcloud

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

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

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

API

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

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

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

ערך הזמן הקצוב לתפוגה של 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:

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

יכול להיות שחיבורי ה-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;

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

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

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

טיפול בבקשות

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

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

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

טיפול בתשובות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה לסשן (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) GCLB
מאזני עומסים קלאסיים של אפליקציות (ALB) GCLB
מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) GCILB

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

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

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

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

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

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

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

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

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

כשהלקוח כולל את קובץ ה-cookie של שיוך סשן HTTP בCookie כותרת הבקשה של בקשות HTTP, מאזן העומסים מפנה את הבקשות האלה לאותו מופע או נקודת קצה של קצה עורפי, כל עוד קובץ ה-cookie של שיוך הסשן תקף. כדי לעשות זאת, צריך למפות את ערך קובץ ה-Cookie לאינדקס שמפנה למופע ספציפי של שרת עורפי (backend instance) או לנקודת קצה, ולוודא שהדרישות של קובץ ה-Cookie שנוצר לגבי זיקה לסשן (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 של זיקה לסשן (session affinity) בCookie request header של בקשות HTTP הבאות, מאזן העומסים מפנה את הבקשות האלה לשרת עורפי (backend instance) או לנקודת קצה נבחרים.

בניגוד לשיטות אחרות של שיוך סשנים:

  • לזיקה מבוססת-קובצי 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 שנבחרו תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות תקינות.
  • ב-Global external Application Load Balancers וב-Classic Application Load Balancers, יכול להיות שזיקה לסשן תפסיק לפעול אם נעשה שימוש ב-Google Front End (GFE) שונה בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט אל Google ישתנה בין בקשות או בין חיבורים.
חוץ מהאפשרות של זיקה לסשן מבוססת-קובצי Cookie עם שמירת מצב, לכל האפשרויות של זיקה לסשן יש את הדרישות הנוספות הבאות:

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

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

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

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

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

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

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

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