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

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

איך פועלים הקישורים

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

בהתאם להגדרת שירות לקצה העורפי, הפרוטוקול שבו כל 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 פעיל של הלקוח ואת הזמן הקצוב לתפוגה של חיבור פעיל של ה-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.
• מאזני עומסים חיצוניים של אפליקציות (ALB) תומכים בתגובה HTTP/1.1 100 Continue.

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

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

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

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

• חיבור 1, מהלקוח המקורי למאזן העומסים (GFE):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיום TLS

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) משתמשים בפרמטר routeAction.timeout של מיפויי כתובות ה-URL שהוגדר ומתעלמים מהזמן הקצוב לתפוגה של שירות הקצה העורפי. אם לא מגדירים את הערך של 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 keepalive של הלקוח עם ערך בין 5 ל-1,200 שניות.

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

המסוף

משנים את השדה 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.

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

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

API

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

במאזן עומסים אזורי חיצוני של אפליקציות (ALB), אי אפשר לעדכן ישירות את הפרמטר של הזמן הקצוב לתפוגה של חיבור פעיל של שרת proxy אזורי מסוג HTTP(S). כדי לעדכן את פרמטר הזמן הקצוב לתפוגה של שמירת החיבור (keepalive) של שרת 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 ‏ (RST).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טיפול בבקשות

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

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

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

המשמעות של קיבולת תלויה בחלקה במצב האיזון. בRATEמצב, זה פשוט יחסית: 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 בשכבה הראשונה לגבי הקיבולת שנעשה בה שימוש והקיבולת שהוגדרה לכל שירות קצה עורפי. הקיבולת המוגדרת של שרת קצה עורפי מוגדרת על ידי מצב איזון העומסים, קיבולת היעד של מצב איזון העומסים והכלי להרחבת הקיבולת.
     • מסלול רגיל: שרתי GFE בשכבה הראשונה בוחרים שרת GFE בשכבה השנייה באזור שמכיל את השרתים העורפיים.
     • מסלול פרימיום: שרתי GFE בשכבה הראשונה בוחרים שרתי GFE בשכבה השנייה מתוך קבוצה של אזורים רלוונטיים. האזורים הרלוונטיים הם כל האזורים שבהם הוגדרו שרתי קצה עורפיים, לא כולל אזורים שבהם הוגדרו שרתי קצה עורפיים עם קיבולת אפס. מערכות GFE בשכבה הראשונה בוחרות את מערכת ה-GFE הכי קרובה בשכבה השנייה באזור רלוונטי (מוגדר לפי זמן הלוך ושוב ברשת). אם העורפים מוגדרים בשני אזורים או יותר, שרתי GFE בשכבה הראשונה יכולים להעביר בקשות לאזורים רלוונטיים אחרים אם אזור הבחירה הראשון מלא. אם כל השרתים העורפיים באזור המועדף הגיעו לקיבולת המקסימלית שלהם, יכול להיות שהבקשות יועברו לאזורים אחרים.
3. שכבת ה-GFE השנייה בוחרת בקצה העורפי. מערכות GFE בשכבה השנייה ממוקמות באזורים. הם משתמשים בתהליך הבא כדי לבחור שרת קצה עורפי:
   • בשירותי קצה עורפיים עם קבוצות NEG ללא שרתים, קבוצות NEG של 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 בשכבה השנייה. שערים של Google בחלק השני של הרשת מפנים בקשות לשרתי קצה עורפיים באזורים שונים רק אחרי שכל שרתי הקצה העורפיים באזור הנוכחי הגיעו לקיבולת המוגדרת שלהם.
5. השכבה השנייה של GFE בוחרת מופעים או נקודות קצה בתוך האזור. כברירת מחדל, ממשק קצה של Google‏ (GFE) בשכבה השנייה מחלק את הבקשות בין הקצוות העורפיים בשיטת round-robin. במאזני עומסים חיצוניים גלובליים בלבד, אפשר לשנות את ההגדרה הזו באמצעות מדיניות מקומית של איזון עומסים (localityLbPolicy). המדיניות המקומית של איזון העומסים חלה רק על שרתי בק-אנד באזור שנבחר, כפי שמוסבר בשלב הקודם.

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

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

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

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

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

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

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

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

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

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

מוצר	אפשרויות של זיקה לסשן
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) וגם ‫Regional external Application Load Balancer	ללא (NONE) כתובת ה-IP של הלקוח (CLIENT_IP) קובץ Cookie שנוצר (GENERATED_COOKIE) שדה כותרת (HEADER_FIELD) קובץ Cookie של HTTP‏ (HTTP_COOKIE) זיקה מבוססת-קובצי Cookie עם שמירת מצב (STRONG_COOKIE_AFFINITY) חשוב לזכור: ערך ברירת המחדל האפקטיבי של מדיניות המיקום של איזון העומסים (localityLbPolicy) משתנה בהתאם להגדרות של זיקה לסשן (session affinity). אם זיקה לסשן אינה מוגדרת—כלומר, אם זיקה לסשן נשארת בערך ברירת המחדל NONE—אז ערך ברירת המחדל של localityLbPolicy הוא ROUND_ROBIN. אם זיקה לסשן מוגדרת לערך שונה מ-NONE, ערך ברירת המחדל של localityLbPolicy הוא MAGLEV. במאזן עומסים גלובלי חיצוני של אפליקציות (ALB), אל תגדירו זיקה לסשן (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) לאחת מהקטגוריות הבאות:

• זיקה לסשן מבוססת Hash‏ (NONE, ‏ CLIENT_IP)
• זיקה לסשן שמבוססת על כותרת HTTP‏ (HEADER_FIELD)
• זיקה לסשן מבוססת קובצי Cookie‏ (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

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

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

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

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

ללא

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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