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

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

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

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

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

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

בהתאם למיקום הלקוחות שלכם, יכול להיות שכמה שרתי GFE יפעילו חיבורי HTTP(S) לשרתי הקצה העורפיים שלכם. לחבילות שנשלחות מ-GFE יש כתובות IP של מקור מאותו טווח שבו נעשה שימוש בבדיקות תקינות: 35.191.0.0/16 ו-130.211.0.0/22.

הערה: ב-NEGs של אינטרנט, הבקשות ממאזן העומסים מגיעות מטווחים שונים של כתובות IP, בהתאם לסוג ה-NEG (גלובלי או אזורי). מידע נוסף זמין במאמר בנושא אימות בקשות.

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

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

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

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

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

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

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

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

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

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

סיום TLS

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

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

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

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

סוג פסק הזמן והתיאור שלו	ערכי ברירת מחדל	תמיכה בערכי זמן קצוב לתפוגה בהתאמה אישית
		עולמי	קלאסי	אזורי
זמן קצוב לתפוגה של שירות לקצה העורפי^1 הזמן הקצוב לתפוגת הבקשה והתגובה. הערך הזה מייצג את משך הזמן המקסימלי שמותר לעבור בין שליחת הבייט הראשון של בקשה מהמאזן עומסים לקצה העורפי לבין החזרת הבייט האחרון של תגובת ה-HTTP מהקצה העורפי למאזן העומסים. אם ה-backend לא מחזיר את תגובת ה-HTTP המלאה למאזן העומסים בתוך מגבלת הזמן הזו, נתוני התגובה שנותרו מושמטים.	ל-NEGs ללא שרת בשירות קצה עורפי: 60 דקות לכל סוגי הקצה העורפי האחרים בשירות קצה עורפי: 30 שניות לקטגוריות של backend: ‏ 24 שעות (86,400 שניות)
תם הזמן הקצוב להגדרת החיבור הזמן המקסימלי שמוקצב ל-proxy כדי ליצור חיבור לקצה העורפי. הגדרה מוצלחת כוללת השלמה של לחיצת יד תלת-צדדית בפרוטוקול TCP, ואם פרוטוקול ה-Backend הוא HTTPS, השלמה של לחיצת יד בפרוטוקול TLS. במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים של אפליקציות בגרסה הקלאסית, ה-proxy של מאזן העומסים הוא GFE בשכבה השנייה. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫4.5 שניות
פסק זמן של TLS בצד הלקוח משך הזמן המקסימלי שבו ה-proxy של מאזן העומסים ממתין להשלמת לחיצת היד של TLS. במאזני עומסים גלובליים חיצוניים של אפליקציות (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 של מאזן עומסים גלובלי חיצוני של אפליקציות או מאזן עומסים קלאסי של אפליקציות.	למאזני עומסים גלובליים חיצוניים של אפליקציות ולמאזני עומסים קלאסיים של אפליקציות: הזמן הקצוב לתפוגה של סשן QUIC במצב לא פעיל הוא המינימום מבין הזמן הקצוב לתפוגה של הלקוח במצב לא פעיל או הזמן הקצוב לתפוגה של GFE במצב לא פעיל (240 שניות). משך הזמן ללא פעילות ב-GFE קבוע על 240 שניות. אפשר להגדיר את הזמן הקצוב לתפוגה של חוסר פעילות של הלקוח.

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

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

המסוף

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

gcloud

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

API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• זיקה לסשן שמבוססת על גיבוב (NONE, CLIENT_IP)
• זיקה לסשן שמבוססת על כותרת HTTP‏ (HEADER_FIELD)
• זיקה לסשן שמבוססת על קובצי Cookie‏ (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_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 אפקטיבית של המקור, יכול להיות שחלק מהמכונות הווירטואליות של ה-Backend יקבלו יותר חיבורים או בקשות מאחרות.

זיקה לסשן (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. אם לא מציינים את affinityCookieTtlSec, ערך ברירת המחדל של TTL הוא 0.

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

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

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

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

זיקה לקובצי Cookie של HTTP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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