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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיום TLS

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

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

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

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

סוג פסק הזמן והתיאור שלו	ערכי ברירת מחדל	תמיכה בערכי זמן קצוב בהתאמה אישית
		זמן קצוב לתפוגה של שירות לקצה העורפי1 זמן קצוב לתפוגת בקשה ותגובה. הערך הזה מייצג את משך הזמן המקסימלי שמותר שיעבור בין הרגע שבו מאזן העומסים שולח את הבייט הראשון של בקשה לקצה העורפי, לבין הרגע שבו הקצה העורפי מחזיר את הבייט האחרון של תגובת ה-HTTP למאזן העומסים. אם ה-backend לא מחזיר את כל תגובת ה-HTTP למאזן העומסים בתוך מגבלת הזמן הזו, נתוני התגובה שנותרו מושמטים.	לכל סוגי ה-backend האחרים בשירות לקצה העורפי: 30 שניות
תם הזמן הקצוב להגדרת החיבור משך הזמן המקסימלי שמוקצב ל-proxy כדי ליצור חיבור לקצה העורפי. הגדרה מוצלחת כוללת השלמה של לחיצת יד תלת-צדדית בפרוטוקול TCP, ואם פרוטוקול ה-Backend הוא HTTPS, השלמה של לחיצת יד בפרוטוקול TLS. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫4.5 שניות
פסק זמן של TLS בצד הלקוח משך הזמן המקסימלי שבו ה-proxy של מאזן העומסים ממתין להשלמת לחיצת היד של TLS. במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫10 שניות
Client HTTP keepalive timeout הזמן המקסימלי שחיבור ה-TCP בין לקוח לבין ה-proxy של מאזן העומסים יכול להיות בלי פעילות. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP). במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	‫610 שניות
Backend HTTP keepalive timeout הזמן המקסימלי שחיבור ה-TCP בין ה-proxy של מאזן העומסים לבין קצה עורפי יכול להיות לא פעיל. (יכול להיות שאותו חיבור TCP ישמש לכמה בקשות HTTP). במאזני עומסים חיצוניים אזוריים של אפליקציות, ה-proxy של מאזן העומסים הוא תוכנת Envoy.	לשירותי קצה עורפי: 10 דקות (600 שניות)

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

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

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

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

מצב מאזן עומסים	ערכי ברירת מחדל	תיאור של פסק זמן עבור websockets
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	זמן קצוב לתפוגה של שירות לקצה העורפי: 30 שניות	חיבורי WebSocket פעילים לא משתמשים בזמן הקצוב לתפוגה של השירות לקצה העורפי של מאזן העומסים. חיבורי WebSocket לא פעילים נסגרים אחרי שחלף הזמן הקצוב לתפוגה של שירות לקצה העורפי. Cloud de Confiance מפעיל מחדש מעת לעת או משנה את מספר המשימות של תוכנת Envoy. ככל שערך הזמן הקצוב לתפוגה של שירות לקצה העורפי ארוך יותר, כך גדל הסיכוי שמשימות של Envoy יופעלו מחדש או שחיבורי TCP יסתיימו.

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

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

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

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

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

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

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

הערך של הזמן הקצוב לתפוגה של 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 ראשון בין הלקוח (בכיוון 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;

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

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

מצב מאזן עומסים

לוגיקה לניסיון נוסף

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

טיפול בבקשות

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

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

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

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

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

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

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

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

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

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

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

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

מוצר

אפשרויות של זיקה לסשן

‫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.

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

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

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

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

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