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

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

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

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

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

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

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

בהתאם להגדרת שירות ה-Backend, הפרוטוקול שבו כל GFE משתמש כדי להתחבר ל-Backends יכול להיות HTTP,‏ HTTPS או HTTP/2. בחיבורי HTTP או HTTPS, הגרסה של HTTP שנעשה בה שימוש היא HTTP 1.1.

ההגדרה HTTP keepalive מופעלת כברירת מחדל, כפי שמצוין במפרט HTTP 1.1. הפרוטוקול HTTP keepalive מנסה להשתמש ביעילות באותו סשן TCP, אבל אין בכך ערובה. ב-GFE משתמשים בערך הזמן הקצוב לתפוגה של שמירת חיבור HTTP פעיל של לקוח של 610 שניות, ובערך ברירת המחדל של הזמן הקצוב לתפוגה של שמירת חיבור פעיל של קצה עורפי של 600 שניות. אפשר לעדכן את פסק הזמן של שמירת החיבור הפעיל ב-HTTP של הלקוח, אבל הערך של פסק הזמן של שמירת החיבור הפעיל בשרת הקצה העורפי הוא קבוע. אפשר להגדיר את הזמן הקצוב לתפוגה של הבקשה והתשובה על ידי הגדרת הזמן הקצוב לתפוגה של שירות לקצה העורפי. למרות שהם קשורים זה לזה, HTTP keepalive ו-TCP idle timeout הם לא אותו דבר. מידע נוסף זמין במאמר בנושא פסק זמן וניסיונות חוזרים.

כדי לוודא שהתנועה מאוזנת באופן שווה, מאזן העומסים עשוי לסגור בצורה נקייה חיבור TCP על ידי שליחת חבילת FIN ACK אחרי השלמת תגובה שכללה כותרת Connection: close, או שהוא עשוי להנפיק פריים GOAWAY של HTTP/2 אחרי השלמת תגובה. ההתנהגות הזו לא מפריעה לבקשות או לתגובות פעילות.

מספר חיבורי ה-HTTP ומספר סשני ה-TCP משתנים בהתאם למספר ה-GFE שמחוברים, למספר הלקוחות שמחוברים ל-GFE, לפרוטוקול של ה-backend ולמיקום הפריסה של ה-backend.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• בודק אבטחה צריך לבדוק את הגדרות כללי ההעברה של מאזן העומסים. כללי ההעברה מגדירים את יציאת היעד שמאזן העומסים מקבל דרכה חבילות ומעביר אותן לשרתי הקצה העורפי. במאזני עומסים שמבוססים על GFE, כל כלל העברה חיצוני יכול להפנות רק ליעד אחד של יציאת TCP. במאזן עומסים שמשתמש ביציאת TCP ‏443, נעשה שימוש ביציאת UDP ‏443 כשהחיבור משודרג ל-QUIC ‏ (HTTP/3).

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

סיום TLS

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

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

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

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

סוג פסק הזמן והתיאור שלו	ערכי ברירת מחדל	תמיכה בערכי זמן קצובים בהתאמה אישית
		עולמי	קלאסי	אזורי
זמן קצוב לתפוגה של שירות לקצה העורפי1 זמן קצוב לתפוגה של בקשה ותגובה. הזמן המקסימלי המותר בין שליחת הבייט הראשון של בקשה מהמאזן עומסים לקצה העורפי לבין החזרת הבייט האחרון של תגובת ה-HTTP מהקצה העורפי למאזן העומסים. אם ה-backend לא מחזיר את תגובת ה-HTTP המלאה למאזן העומסים בתוך מגבלת הזמן הזו, נתוני התגובה שנותרו מושמטים.	ל-NEGs בלי שרת (serverless) בשירות קצה עורפי: 60 דקות לכל סוגי הקצה העורפי האחרים בשירות קצה עורפי: 30 שניות לקטגוריות של backend: ‏ 24 שעות (86,400 שניות)
תם הזמן הקצוב להגדרת החיבור הזמן המקסימלי שמוקצב ל-proxy כדי ליצור חיבור לקצה העורפי. הגדרה מוצלחת כוללת השלמה של לחיצת יד תלת-צדדית בפרוטוקול TCP, ואם פרוטוקול ה-Backend הוא HTTPS, השלמה של לחיצת יד בפרוטוקול TLS. במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים של אפליקציות בגרסה הקלאסית, ה-proxy של מאזן העומסים הוא GFE בשכבה השנייה. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫4.5 שניות
פסק זמן של TLS בצד הלקוח משך הזמן המקסימלי שבו ה-proxy של מאזן העומסים ממתין להשלמת לחיצת היד של TLS. במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים קלאסיים של אפליקציות (ALB), ה-proxy של מאזן העומסים הוא GFE בשכבה הראשונה. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫10 שניות
Client HTTP keepalive timeout הזמן המקסימלי שחיבור ה-TCP בין לקוח לבין שרת ה-proxy של מאזן העומסים יכול להיות במצב לא פעיל. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP). במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים של אפליקציות (ALB) בגרסה הקלאסית, ה-proxy של מאזן העומסים הוא GFE בשכבה הראשונה. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫610 שניות
Backend HTTP keepalive timeout הזמן המקסימלי שחיבור ה-TCP בין שרת ה-proxy של מאזן העומסים לבין בק-אנד יכול להיות בלי פעילות. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP). במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים של אפליקציות בגרסה הקלאסית, ה-proxy של מאזן העומסים הוא GFE בשכבה השנייה. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	לשירותי קצה עורפי: 10 דקות (600 שניות) למאגרי מידע בעורף המערכת: 6 דקות (360 שניות)
‫QUIC session idle timeout הזמן המקסימלי שבו סשן QUIC יכול להיות לא פעיל בין הלקוח (בכיוון downstream) לבין GFE של מאזן עומסים גלובלי חיצוני של אפליקציות או מאזן עומסים קלאסי של אפליקציות.	למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ולמאזני עומסים קלאסיים של אפליקציות (ALB): הזמן הקצוב לתפוגה של סשן QUIC במצב לא פעיל הוא המינימום מבין הזמן הקצוב לתפוגה של הלקוח במצב לא פעיל או הזמן הקצוב לתפוגה של GFE במצב לא פעיל (240 שניות). משך הזמן ללא פעילות ב-GFE קבוע על 240 שניות. אפשר להגדיר את הזמן הקצוב לתפוגה של חוסר פעילות מצד הלקוח.

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

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

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

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

מצב מאזן העומסים	ערכי ברירת מחדל	תיאור של זמן קצוב לתפוגה עבור websockets
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	זמן קצוב לתפוגה של שירות לקצה העורפי: 30 שניות	חיבורי WebSocket פעילים לא משתמשים בזמן הקצוב לתפוגה של השירות לקצה העורפי שמוגדר במאזן העומסים. החיבורים נסגרים אוטומטית אחרי 24 שעות (86,400 שניות). המגבלה הזו של 24 שעות היא קבועה, והיא מבטלת את זמן קצוב לתפוגה של שירות לקצה העורפי אם הוא גדול מ-24 שעות. חיבורי WebSocket לא פעילים נסגרים אחרי שחלף הזמן הקצוב לתפוגה של שירות ה-Backend. אנחנו לא ממליצים להגדיר ערכי זמן קצוב לתפוגה של שירותי backend שגדולים מ-24 שעות (86,400 שניות), כי מערכות GFE מופעלות מחדש באופן תקופתי לצורך עדכוני תוכנה ותחזוקה שוטפת אחרת. Google Cloud ערך הזמן הקצוב לתפוגה של שירות לקצה העורפי לא מעכב את פעולות התחזוקה. ככל שהזמן הקצוב לתפוגה של השירות לקצה העורפי ארוך יותר, כך גדל הסיכוי ש- Google Cloudיסיים חיבורי TCP לצורך תחזוקה.
מאזן עומסים קלאסי של אפליקציות (ALB)	זמן קצוב לתפוגה של שירות לקצה העורפי: 30 שניות	חיבורי Websocket, בין אם הם לא פעילים או פעילים, נסגרים אוטומטית אחרי שחלף הזמן הקצוב לתפוגה של שירות ה-Backend. אנחנו לא ממליצים להגדיר ערכי זמן קצוב לתפוגה של שירותי backend שגדולים מ-24 שעות (86,400 שניות), כי מערכות GFE מופעלות מחדש באופן תקופתי לצורך עדכוני תוכנה ותחזוקה שוטפת אחרת. Google Cloud ערך הזמן הקצוב לתפוגה של שירות לקצה העורפי לא מעכב את פעולות התחזוקה. ככל שהזמן הקצוב לתפוגה של השירות לקצה העורפי ארוך יותר, כך גדל הסיכוי ש- Google Cloudיסיים חיבורי TCP לצורך תחזוקה.
מאזן עומסים חיצוני אזורי של אפליקציות (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) או במאזן עומסים קלאסי של אפליקציות: ממשק קצה של Google‏ (GFE) בשכבה הראשונה

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

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

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

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

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

זמן קצוב לתפוגה של סשן לא פעיל ב-QUIC

הזמן הקצוב לתפוגה של סשן QUIC במצב לא פעיל מייצג את משך הזמן המקסימלי שסשן QUIC יכול להיות במצב לא פעיל בין הלקוח לבין GFE של מאזן עומסים גלובלי חיצוני של אפליקציות או מאזן עומסים קלאסי של אפליקציות.

ערך הזמן הקצוב לתפוגה של חוסר פעילות בסשן QUIC מוגדר כערך המינימלי מבין הזמן הקצוב לתפוגה של חוסר פעילות בלקוח או הזמן הקצוב לתפוגה של חוסר פעילות ב-GFE (240 שניות). משך הזמן ללא פעילות ב-GFE קבוע על 240 שניות. אפשר להגדיר את הזמן הקצוב לתפוגה של חוסר פעילות של הלקוח.

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

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

מצב מאזן העומסים	לוגיקה לניסיון נוסף
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	אפשר להגדיר את ההתנהגות הזו באמצעות מדיניות ניסיון חוזר במפת URL. המספר המקסימלי של ניסיונות חוזרים (numRetries) שאפשר להגדיר באמצעות מדיניות הניסיונות החוזרים הוא 25. הערך המקסימלי שאפשר להגדיר ל-perTryTimeout הוא 24 שעות. כדי להשבית את הניסיונות החוזרים, צריך להגדיר במפורש את numRetries ל-1. הסיבה לכך היא שהפרמטר numRetries מציין את המספר המקסימלי הכולל של ניסיונות איזון העומסים לשליחת הבקשה אל ה-backend. הסכום הכולל הזה כולל את הבקשה הראשונית וגם את כל ניסיונות השליחה החוזרים. אם מגדירים את numRetries ל-1 כדי להשבית את הניסיונות החוזרים, המשמעות היא שרק הבקשה הראשונית נשלחת ולא מתבצעים ניסיונות חוזרים נוספים. ללא מדיניות ניסיון חוזר, בקשות לא מוצלחות שאין להן תוכן HTTP (לדוגמה, בקשות GET) שמובילות לתגובות HTTP 502, 503 או 504 (retryConditions=["gateway-error"]) ינסו שוב פעם אחת. לא מתבצע ניסיון חוזר של בקשות HTTP‏ POST. בקשות שבוצעו מחדש יוצרות רק רשומה אחת ביומן עבור התגובה הסופית. בטבלה הבאה מפורט אילו מערכות בק-אנד תומכות במדיניות ברירת מחדל ובמדיניות מותאמת אישית לניסיון חוזר במאזן עומסים גלובלי חיצוני של אפליקציות (ALB). סוג הקצה העורפי מדיניות ברירת המחדל לניסיון חוזר מדיניות מותאמת אישית לניסיון חוזר קבוצות של מכונות קבוצות אזוריות של נקודות קצה ברשת (NEGs) קבוצות NEG היברידיות קבוצות NEGs של Private Service Connect קבוצות NEG באינטרנט קבוצות NEG ללא שרת (serverless)
מאזן עומסים קלאסי של אפליקציות (ALB)	אי אפשר לשנות את מדיניות הניסיון החוזר לחיבורים. לא מתבצע ניסיון חוזר של בקשות HTTP‏ POST. בקשות HTTP GET תמיד מנסות שוב פעם אחת, כל עוד 80% או יותר מהשרתים העורפיים תקינים. אם יש מופע יחיד של שרת עורפי בקבוצה והחיבור למופע הזה נכשל, אחוז המופעים של שרת עורפי במצב לא תקין הוא 100%, ולכן GFE לא מנסה לשלוח שוב את הבקשה. מאזן העומסים מנסה שוב בקשת GET שנכשלה אם הבקשה הראשונה נכשלה לפני קבלת כותרות התגובה ממופע ה-Backend. בקשות שבוצעו מחדש יוצרות רק רשומה אחת ביומן עבור התגובה הסופית. מידע נוסף זמין במאמר בנושא רישום ביומן ומעקב אחרי מאזן עומסים של אפליקציות (ALB) חיצוני. בקשות שלא מצליחות גורמות למאזן העומסים ליצור תגובת HTTP 502. בטבלה הבאה מפורטים סוגי השרתים העורפיים שתומכים במדיניות ניסיון חוזר במאזן עומסים של אפליקציות (ALB) קלאסי. סוג הקצה העורפי מדיניות ברירת המחדל לניסיון חוזר מדיניות מותאמת אישית לניסיון חוזר קבוצות של מכונות קבוצות אזוריות של נקודות קצה ברשת (NEGs) קבוצות NEG היברידיות קבוצות NEG באינטרנט קבוצות NEG ללא שרת (serverless)
מאזן עומסים חיצוני אזורי של אפליקציות (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
אי אפשר לנתח את חלקי הגוף. זה המקרה היחיד שבו חלק מהנתונים מגיעים לקצה העורפי. מאזן העומסים סוגר את החיבורים ללקוח ולשרת הקצה העורפי כשהוא מקבל נתח שלא ניתן לניתוח.

טיפול בבקשות

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

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

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

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

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

שני הגורמים האלה – הערכת הקיבולת וההקצאה הפרואקטיבית – משפיעים על החלוקה בין המקרים. לכן, התנהגות של Cloud Load Balancing שונה מזו של מאזן עומסים פשוט מסוג Round-robin שמפיץ בקשות בדיוק ביחס של 50:50 בין שני מופעים. במקום זאת, Google Cloud איזון העומסים מנסה לבצע אופטימיזציה של בחירת מופע ה-Backend לכל בקשה.

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

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

איך הבקשות מחולקות

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

1. מהלקוח ל-GFE בשכבה הראשונה. נתבי קצה מפרסמים את כתובת ה-IP החיצונית של כלל ההעברה בגבולות הרשת של Google. כל פרסום מפרט את הניתוב הבא למערכת איזון עומסים בשכבה 3 ובשכבה 4 (Maglev). מערכות Maglev מנתבות את התעבורה לממשק קצה של Google‏ (GFE) בשכבה הראשונה.
   • כשמשתמשים במסלול פרימיום, Google מפרסמת את כתובת ה-IP של איזון העומסים מכל נקודות הנוכחות בעולם. כל כתובת IP של מאזן עומסים היא מסוג anycast גלובלי.
   • כשמשתמשים במסלול הרגיל, Google מפרסמת את כתובת ה-IP של מאזן העומסים מנקודות נוכחות שמשויכות לאזור של כלל ההעברה. מאזן העומסים משתמש בכתובת IP חיצונית אזורית. שימוש בכלל העברה במסלול הרגיל מגביל אתכם לקבוצת מופעים ולבק-אנד של NEG אזורי באותו אזור שבו נמצא כלל ההעברה של מאזן העומסים.
2. מ-GFE בשכבה הראשונה ל-GFE בשכבה השנייה. ממשק הקצה של Google‏ (GFE) בשכבה הראשונה מסיים את ה-TLS אם נדרש, ואז מנתב את תעבורת הנתונים לממשקי קצה של Google בשכבה השנייה לפי התהליך הבא:
   • מערכות GFE בשכבה הראשונה מנתחות את מפת ה-URL ובוחרות שירות לקצה העורפי או קטגוריית קצה עורפי.
   • בשירותי קצה עורפיים עם NEGs באינטרנט, ממשקי הקצה של Google‏ (GFE) בשכבה הראשונה בוחרים בשער העברת נתונים חיצוני בשכבה השנייה, שמוצב יחד עם ממשק הקצה של Google‏ (GFE) בשכבה הראשונה. שער ההעברה שולח בקשות לנקודת הקצה של ה-NEG באינטרנט. כאן מסתיים תהליך חלוקת הבקשות ל-NEGs באינטרנט.
   • בשירותי קצה עורפי עם NEGs בלי שרת (serverless) וNEGs של Private Service Connect‏ (PSC), ובקטגוריות קצה עורפי אזוריות, רכיבי GFE בשכבה הראשונה בוחרים רכיב GFE בשכבה השנייה באזור שתואם לאזור של ה-NEG או הקטגוריה. בקטגוריות של Cloud Storage במספר אזורים, רכיבי GFE בשכבה הראשונה בוחרים רכיבי GFE בשכבה השנייה באזור של הקטגוריה, או באזור הכי קרוב שאפשר לקטגוריה במספר אזורים (מוגדר לפי זמן הלוך ושוב ברשת).
   • בשירותי קצה עורפיים עם קבוצות של מופעים, NEGs אזוריים עם נקודות קצה GCE_VM_IP_PORT ו-NEGs היברידיים, מערכת ניהול הקיבולת של Google מעדכנת את GFEs בשכבה הראשונה לגבי הקיבולת שנעשה בה שימוש והקיבולת שהוגדרה לכל קצה עורפי. הקיבולת המוגדרת עבור שרת קצה עורפי מוגדרת על ידי מצב איזון העומסים, קיבולת היעד של מצב איזון העומסים והתאמת הקיבולת.
     • מסלול רגיל:‏ GFEs בשכבה הראשונה בוחרים GFE בשכבה השנייה באזור שמכיל את השרתים העורפיים.
     • מסלול פרימיום: שרתי GFE בשכבה הראשונה בוחרים שרתי GFE בשכבה השנייה מתוך קבוצה של אזורים רלוונטיים. האזורים הרלוונטיים הם כל האזורים שבהם הוגדרו שרתי קצה עורפיים, למעט אזורים שבהם הוגדרו שרתי קצה עורפיים עם קיבולת אפס. מערכות GFE בשכבה הראשונה בוחרות את מערכת ה-GFE הכי קרובה בשכבה השנייה באזור הרלוונטי (מוגדר לפי זמן הלוך ושוב ברשת). אם שרתי קצה עורפיים מוגדרים בשני אזורים או יותר, שרתי GFE בשכבה הראשונה יכולים להעביר בקשות לאזורים רלוונטיים אחרים אם אזור הבחירה הראשון מלא. יכול להיות שיהיה מעבר לאזורים אחרים אם כל השרתים בעורף באזור שנבחר ראשון יגיעו לקיבולת המקסימלית.
3. שכבת GFE שנייה בוחרת בקצה העורפי. מערכות GFE בשכבה השנייה ממוקמות באזורים. הם משתמשים בתהליך הבא כדי לבחור שרת קצה עורפי:
   • בשירותי בק-אנד עם NEGs ללא שרתים, NEGs של Private Service Connect ודלי בק-אנד, ממשקי קצה של Google בשכבה השנייה מעבירים בקשות למערכות הייצור של Google. כאן מסתיים תהליך חלוקת הבקשות עבור שרתי הקצה העורפיים האלה.

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

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

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

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

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

   • ‫SPRAY_TO_REGION: GFE בשכבה השנייה לא מעדיף לבחור מופעי קצה או נקודות קצה בעורף באותו אזור כמו GFE בשכבה השנייה. מערכות GFE בשכבה השנייה מנסות לחלק את התעבורה לכל המופעים או נקודות הקצה בעורף בכל האזורים. הפעולה הזו יכולה להוביל לחלוקת עומס מאוזנת יותר, אבל על חשבון הגדלת התנועה בין האזורים.
   • ‫WATERFALL_BY_ZONE: רכיבי GFE בשכבה השנייה מעדיפים מאוד לבחור מופעי קצה או נקודות קצה של שרתים עורפיים באותו אזור כמו רכיבי ה-GFE בשכבה השנייה. ממשקי GFE בשכבה השנייה מפנים בקשות לשרתי קצה עורפיים באזורים שונים רק אחרי שכל השרתים העורפיים באזור הנוכחי הגיעו לקיבולת המוגדרת שלהם.
5. השכבה השנייה של GFE בוחרת מופעים או נקודות קצה בתוך האזור. כברירת מחדל, ממשק קצה של Google‏ (GFE) בשכבה השנייה מחלק את הבקשות בין הקצוות העורפיים בשיטת round-robin. רק במאזני עומסים חיצוניים גלובליים של אפליקציות, אפשר לשנות את ההגדרה הזו באמצעות מדיניות מקומית של איזון עומסים (localityLbPolicy). המדיניות המקומית של איזון העומסים חלה רק על בק-אנדים באזור שנבחר, כפי שמוסבר בשלב הקודם.

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

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

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

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

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

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

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

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

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

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

מוצר	אפשרויות של זיקה לסשן
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) וגם מאזן עומסים חיצוני אזורי של אפליקציות (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. ב-Global External Application Load Balancer, אל תגדירו זיקה לסשן (session affinity) אם אתם משתמשים בחלוקת תנועה משוקללת. אם כן, הגדרת חלוקת התנועה המשוקללת תקבל עדיפות.
מאזן עומסים קלאסי של אפליקציות (ALB)	ללא (NONE) כתובת ה-IP של הלקוח (CLIENT_IP) קובץ Cookie שנוצר (GENERATED_COOKIE)

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

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

• ללא
• זיקה לכתובת 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 יכולה להיות מהסוגים הבאים:

• זיקה לקובץ Cookie שנוצר
• תחום עניין משותף של קובצי Cookie מסוג HTTP
• זיקה לסשן מבוססת על קובצי Cookie עם שמירת מצב

זיקה לקובץ 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

כשמשתמשים בזיקה שמבוססת על קובצי 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.

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

אפשר להגדיר את ערכי ה-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.

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

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