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

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

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

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

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

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

סיום TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ערך הזמן הקצוב לתפוגה של HTTP keepalive של הלקוח במאזן העומסים צריך להיות גדול יותר מערך הזמן הקצוב לתפוגה של HTTP keepalive (TCP idle) שמשמש לקוחות או שרתי proxy ב-downstream. אם ללקוח במורד הזרם יש פסק זמן ארוך יותר של HTTP keepalive (מצב המתנה של TCP) מאשר פסק הזמן של HTTP keepalive של הלקוח במאזן העומסים, יכול להיות שיתרחש מצב של תחרות. מנקודת המבט של לקוח במורד הזרם, חיבור TCP שנוצר יכול להיות במצב סרק למשך זמן ארוך יותר מהזמן שמותר במאזן העומסים. המשמעות היא שהלקוח במורד הזרם יכול לשלוח חבילות אחרי שמאזן העומסים מחשיב את חיבור ה-TCP כסגור. במקרה כזה, מאזן העומסים מגיב עם מנת TCP reset ‏ (RST).

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

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

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

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

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

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

הערך של הזמן הקצוב לתפוגה של שמירת החיבור פעיל בבק-אנד של מאזן העומסים צריך להיות קטן מהערך של הזמן הקצוב לתפוגה של שמירת החיבור פעיל שמשמש את התוכנה שפועלת בבק-אנד. כך נמנע מצב של מרוץ תהליכים שבו מערכת ההפעלה של השרתים העורפיים עשויה לסגור חיבורי TCP עם איפוס TCP ‏ (RST). אי אפשר להגדיר את ערך הזמן הקצוב לתפוגה של הבק-אנד של מאזן העומסים, ולכן צריך להגדיר את תוכנת הבק-אנד כך שערך הזמן הקצוב לתפוגה של ה-HTTP keepalive (TCP idle) יהיה גדול מ-600 שניות.

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

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

תוכנות לשרתי אינטרנט	פרמטר	הגדרת ברירת המחדל	הגדרה מומלצת
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

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

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

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

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

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

אפשר להגדיר את המדיניות באמצעות מדיניות ניסיון חוזר במפת URL. מספר ברירת המחדל של ניסיונות חוזרים (numRetries) הוא 1. המספר המקסימלי של ניסיונות חוזרים שאפשר להגדיר באמצעות מדיניות הניסיון החוזר הוא 25. הערך המקסימלי של perTryTimeout שאפשר להגדיר הוא 24 שעות. ללא מדיניות ניסיון חוזר, בקשות לא מוצלחות שאין להן תוכן HTTP (לדוגמה, בקשות GET) שמובילות לתגובות HTTP 502, 503 או 504, ינסו שוב פעם אחת. לא מתבצע ניסיון חוזר של בקשות HTTP POST. בקשות שבוצעו מחדש יוצרות רק רשומה אחת ביומן לתגובה הסופית.

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

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

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

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

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

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

טיפול בבקשות

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

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

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

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

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

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

מוצר

אפשרויות של שיוך סשן

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

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

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

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

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

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

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