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

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

Google Cloud מאזן עומסים פנימי של אפליקציות (ALB) הוא מאזן עומסים מבוסס-פרוקסי בשכבה 7, שמאפשר להפעיל את השירותים ולהתאים אותם לעומס מאחורי כתובת IP פנימית אחת. מאזן העומסים הפנימי של אפליקציות (ALB) מחלק את תעבורת ה-HTTP וה-HTTPS לשרתי קצה עורפיים שמארחים בפלטפורמות שונות, כמו Compute Engine,‏ Google Kubernetes Engine ‏(GKE) ו-Cloud Run. Google Cloud פרטים נוספים מופיעים במאמר בנושא תרחישים לדוגמה.

מצבי פעולה

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

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

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

  בטבלה הבאה מפורטים ההבדלים החשובים בין מצב חוצה-אזורים לבין מצב אזורי:

  מצב מאזן העומסים	תכונה
  	כתובת ה-IP הווירטואלית (VIP) של מאזן העומסים	גישת לקוח	קצה עורפי עם איזון עומסים	זמינות גבוהה ומעבר לגיבוי (failover)
  מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים	מוקצים מתוך רשת משנה באזור ספציפי Google Cloud . כתובות VIP מכמה אזורים יכולות לחלוק את אותו שירות גלובלי של קצה עורפי. אפשר להגדיר איזון עומסים גלובלי מבוסס-DNS באמצעות מדיניות ניתוב DNS כדי לנתב בקשות של לקוחות לכתובת ה-VIP הקרובה ביותר.	תמיד נגיש בכל העולם. לקוחות מכל Google Cloud אזור ב-VPC יכולים לשלוח תעבורה למאזן העומסים.	בק-אנדים גלובליים. מאזן העומסים יכול לשלוח תעבורה לבק-אנדים בכל אזור.	מעבר אוטומטי לגיבוי (failover) למערכות קצה תקינות באותו אזור או באזורים שונים.
  מאזן עומסים פנימי אזורי של אפליקציות (ALB)	מוקצים מתוך רשת משנה באזור ספציפי Google Cloud .	לא נגיש באופן גלובלי כברירת מחדל. אפשר גם להפעיל גישה גלובלית.	שרתי בק-אנד אזוריים. מאזן העומסים יכול להפנות תנועה רק לשרתי בק-אנד שנמצאים באותו אזור כמו שרת ה-proxy של מאזן העומסים.	מעבר אוטומטי לגיבוי (failover) לקצוות עורפיים תקינים באותו אזור.

זיהוי המצב

ארכיטקטורה ומשאבים

בתרשים הבא מוצגים המשאבים שנדרשים למאזני עומסים פנימיים של אפליקציות (ALB): Google Cloud

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

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

‫

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

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

‫

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

רשת משנה של שרת proxy בלבד

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

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

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

בנוסף:

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

כלל העברה וכתובת IP

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

מפרט כתובות IP. כל כלל העברה מפנה לכתובת IP אזורית אחת שאפשר להשתמש בה ברשומות DNS של האפליקציה. אתם יכולים להזמין כתובת IP סטטית שתוכלו להשתמש בה, או לאפשר ל-Cloud Load Balancing להקצות לכם כתובת כזו. מומלץ להזמין כתובת IP סטטית. אחרת, בכל פעם שמוחקים כלל העברה ויוצרים כלל חדש, צריך לעדכן את רשומת ה-DNS עם כתובת ה-IP הזמנית שהוקצתה.

הלקוחות משתמשים בכתובת ה-IP ובפורט כדי להתחבר לשרתי ה-proxy של Envoy של מאזן העומסים – כתובת ה-IP של כלל ההעברה היא כתובת ה-IP של מאזן העומסים (לפעמים נקראת כתובת IP וירטואלית או VIP). לקוחות שמתחברים למאזן עומסים צריכים להשתמש ב-HTTP מגרסה 1.1 ואילך. רשימה מלאה של הפרוטוקולים הנתמכים מופיעה במאמר השוואה בין תכונות של מאזני עומסים.

כתובת ה-IP הפנימית שמשויכת לכלל ההעברה יכולה להגיע מתת-רשת באותה רשת ובאותו אזור כמו שרתי הבק-אנד.

מפרט היציאה. כל כלל העברה למאזן עומסים של אפליקציות יכול להפנות ליציאה אחת מתוך 1-65535. כדי לתמוך בכמה יציאות, צריך להגדיר כמה כללי העברה. אתם יכולים להגדיר כמה כללי העברה שישתמשו באותה כתובת IP פנימית (VIP) ויפנו לאותו proxy של HTTP או HTTPS, כל עוד השילוב הכולל של כתובת ה-IP, היציאה והפרוטוקול הוא ייחודי לכל כלל העברה. כך תוכלו להשתמש במאזן עומסים יחיד עם מפת URL משותפת כפרוקסי לכמה אפליקציות.

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

מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים
	כלל העברה	globalForwardingRules.insert method
	כתובת IP אזורית	addresses.insert method
	סכמת איזון עומסים	INTERNAL_MANAGED
	כתובת IP (אופציונלי)	SHARED_LOADBALANCER_VIP
	ניתוב מהלקוח לקצה הקדמי של מאזן העומסים	גישה גלובלית מופעלת כברירת מחדל כדי לאפשר ללקוחות מכל אזור ב-VPC לגשת למאזן העומסים. שרתי בק-אנד יכולים להיות בכמה אזורים.
מאזן עומסים פנימי אזורי של אפליקציות (ALB)
	כלל העברה	forwardingRules.insert method
	כתובת IP אזורית	addresses.insert method
	סכמת איזון עומסים	INTERNAL_MANAGED
	כתובת IP (אופציונלי)	SHARED_LOADBALANCER_VIP
	ניתוב מהלקוח לקצה הקדמי של מאזן העומסים	אתם יכולים להפעיל גישה גלובלית כדי לאפשר ללקוחות מכל אזור ב-VPC לגשת למאזן העומסים. שרתי הבק-אנד צריכים להיות באותו אזור שבו נמצא מאזן העומסים.

כללי העברה ורשתות VPC

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

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

שיוך לרשת VPC

‫Internal Application Load Balancer חוצה אזורים Regional internal Application Load Balancer

בהתאם לכתובת IPv4 או לטווח כתובות IPv6 שבהם אתם משתמשים, תמיד יש רשת VPC מפורשת או מרומזת שמשויכת לכלל ההעברה. כתובות IPv4 פנימיות אזוריות וטווחים של כתובות IPv6 תמיד קיימים בתוך רשתות VPC. כשיוצרים את כלל ההעברה, צריך לציין את תת-הרשת שממנה נלקחת כתובת ה-IP הפנימית. תת-הרשת הזו צריכה להיות באותו אזור ובאותה רשת VPC שבהם נוצרה תת-רשת של שרת proxy בלבד. לכן, יש שיוך רשת משתמע. דרישות לגבי רשתות ותת-רשתות. כדי להשתמש בתנועה מסוג IPv6, הרשתות ורשתות המשנה צריכות לעמוד בדרישות ההגדרה הבאות: רשת VPC: צריך להשתמש ברשת VPC במצב מותאם אישית שהוגדרה עם הדגל --enable-ula-internal-ipv6. תת-רשת של כלל העברה: תת-הרשת הזו צריכה להיות תת-רשת עם תמיכה כפולה (IPv4_IPv6) או IPV6_ONLY, עם הערך ipv6-access-type שמוגדר ל-INTERNAL. אפשרויות להקצאת כתובות IPv6. כלל ההעברה צריך להפנות לטווח של כתובות IPv6‏ /96 מתוך טווח כתובות ה-IPv6 הפנימיות של תת-הרשת /64. כשמגדירים את כלל ההעברה עם הדגל --ip-version=IPV6 Google Cloud,המערכת מקצה באופן אוטומטי קידומת IPv6 אקראית מתוך הטווח של רשת המשנה./96 מגבלות. כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-Google Cloud CLI או ב-API. ב Google Cloud מסוף אין תמיכה בציון כתובות IPv6 זמניות מותאמות אישית לכללי העברה.

שרת proxy יעד

שרת proxy של HTTP או HTTPS ביעד מפסיק חיבורי HTTP(S) מלקוחות. שרת ה-Proxy מסוג HTTP(S) מתייעץ עם מפת URL כדי לקבוע איך לנתב את תעבורת הנתונים לשרתי קצה עורפיים. שרת proxy של HTTPS ליעד משתמש באישור SSL כדי לאמת את עצמו מול לקוחות.

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

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

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

מצב מאזן העומסים	שרת proxy יעד
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים	targetHttpProxies targetHttpsProxies
מאזן עומסים פנימי אזורי של אפליקציות (ALB)	regionTargetHttpProxies regionTargetHttpsProxies

טיפול בכותרת X-Forwarded-For

מאזן העומסים מוסיף שתי כתובות IP לכותרת X-Forwarded-For:

• כתובת ה-IP של הלקוח שמתחבר למאזן העומסים
• כתובת ה-IP של כלל ההעברה של מאזן העומסים

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

אם אתם מפעילים שרת proxy כשרת בק-אנד, בדרך כלל ה-proxy מוסיף עוד מידע לכותרת X-Forwarded-For, ויכול להיות שתצטרכו להתחשב בזה בתוכנה שלכם. הבקשות שמועברות דרך ה-proxy ממאזן העומסים מגיעות מכתובת IP בתת-רשת של שרת proxy בלבד, וה-proxy בשרת העורפי (backend instance) עשוי לתעד את הכתובת הזו וגם את כתובת ה-IP של השרת העורפי עצמו.

מאזן העומסים הפנימי של אפליקציות (ALB) משתמש באמצעי אבטחה ספציפיים לכותרת X-Forwarded-For:

• ניקוי (הסרה) של כותרות. אם יש שרת proxy ביניים בין הלקוח לבין מאזן העומסים, מאזן העומסים מתייחס לכותרות X-Forwarded-For הנכנסות כאל כותרות לא מהימנות ומסיר את הכותרת כדי למנוע זיוף כתובות IP. אין אפשרות להגדיר שינוי בהתנהגות הזו.
• צירוף התנהגות. אפשר להשתמש בכותרות בהתאמה אישית כדי ליצור כותרת חדשה X-Forwarded-For ולהוסיף את כתובת ה-IP של הלקוח וכתובת ה-IP של השרת. עם זאת, במקרה הזה, כתובת ה-IP של הלקוח מנקודת המבט של מאזן העומסים היא כתובת ה-IP של שרת ה-proxy הביניים, ולא כתובת ה-IP המקורית של הלקוח.

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

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

כדי לשמור את כתובת ה-IP של הלקוח באופן מהימן, מומלץ לפעול לפי ההמלצות הבאות:

• שימוש בכותרות מותאמות אישית. מגדירים את השרת הפרוקסי הביניים כך שיחדיר את כתובת ה-IP המאומתת של הלקוח לכותרת בהתאמה אישית. לדוגמה, X-Original-Client-IP או X-Client-IP.
• הגדרת העברה מאזן העומסים הפנימי של אפליקציות (ALB) מעביר כותרות מותאמות אישית לקצה העורפי ללא שינוי.
• עדכון קצה עורפי. מעדכנים את אפליקציית ה-Backend כדי לקרוא את כתובת ה-IP של הלקוח מהכותרת החדשה בהתאמה אישית במקום מ-X-Forwarded-For.

אישורי SSL

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

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

מצב מאזן העומסים	סוג אישור SSL
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים	‫Certificate Manager אישורים בניהול עצמי ואישורים שמנוהלים על ידי Google. ב-Certificate Manager יש תמיכה בסוגים הבאים של אישורים שמנוהלים על ידי Google: אימות DNS באמצעות DNS ציבורי. מידע נוסף זמין במאמר פריסת אישור גלובלי שמנוהל על ידי Google עם הרשאה של DNS. Private Certificate Authority Service. מידע נוסף זמין במאמר בנושא יצירת אישור שמנוהל על ידי Google שהונפק על ידי מופע של CA Service. אין תמיכה באישורים שמנוהלים על ידי Google עם הרשאה של איזון עומסים. אין תמיכה ב אישורי SSL של Compute Engine.
מאזן עומסים פנימי אזורי של אפליקציות (ALB)	אישורי SSL אזוריים ב-Compute Engine ‫Certificate Manager אישורים אזוריים בניהול עצמי ואישורים שמנוהלים על ידי Google. ב-Certificate Manager יש תמיכה בסוגים הבאים של אישורים שמנוהלים על ידי Google: אישורים אזוריים שמנוהלים על ידי Google עם הרשאת DNS לכל פרויקט. מידע נוסף זמין במאמר פריסת אישור אזורי בניהול Google. תעודות אזוריות שמנוהלות על ידי Google עם Certificate Authority Service פרטית. מידע נוסף מופיע במאמר פריסת אישור אזורי שמנוהל על ידי Google באמצעות CA Service. אין תמיכה באישורים שמנוהלים על ידי Google עם הרשאה של איזון עומסים.

מפות של כתובות URL

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

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

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

שירות לקצה העורפי

שירות קצה עורפי מספק מאזן העומסים מידע על ההגדרות, כדי שהוא יוכל להפנות בקשות לקצה העורפי שלו – למשל, קבוצות מופעים של Compute Engine או קבוצות של נקודות קצה ברשת (NEGs). מידע נוסף על שירותי קצה עורפי זמין במאמר סקירה כללית על שירותי קצה עורפי.

היקף השירות לקצה העורפי

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

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

הפרוטוקול לקצה העורפי

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

• ‫HTTP, שמשתמש ב-HTTP/1.1 ולא ב-TLS
• ‫HTTPS, שמשתמש ב-HTTP/1.1 וב-TLS
• ‫HTTP/2, שמשתמש ב-HTTP/2 וב-TLS (אין תמיכה ב-HTTP/2 ללא הצפנה).
• ‫H2C, שמשתמש ב-HTTP/2 דרך TCP. לא נדרש פרוטוקול TLS. פרוטוקול H2C לא נתמך במאזני עומסים קלאסיים של אפליקציות (ALB).

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

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

קצה עורפי

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

מצב מאזן עומסים	קצה עורפי נתמך בשירות לקצה העורפי1						תמיכה בקטגוריות בק-אנד	תמיכה ב-Cloud Armor	תומך ב-Cloud CDN	תמיכה ברכישות מתוך האפליקציה	תמיכה ב-Service Extensions
	קבוצות של מכונות2	Zonal NEGs3	Internet NEGs	קבוצות NEG ללא שרת (serverless)	קבוצות NEG היברידיות	קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים				‫ Cloud Run
מאזן עומסים פנימי אזורי של אפליקציות (ALB)				‫ Cloud Run

שרתי קצה עורפיים ורשתות VPC

ההגבלות על המיקום של השרתים העורפיים תלויות בסוג השרת העורפי.

• במקרה של קבוצות של מכונות, NEGs אזוריים ו-NEGs של קישוריות היברידית, כל השרתים העורפיים חייבים להיות ממוקמים באותו פרויקט ואזור כמו שירות השרת העורפי. עם זאת, מאזן עומסים יכול להפנות לעורף חזיתי שמשתמש ברשת VPC אחרת באותו פרויקט כמו שירות העורף החזיתי. אפשר להגדיר קישוריות בין רשת ה-VPC של מאזן העומסים לבין רשת ה-VPC של הבק-אנד באמצעות קישור בין רשתות VPC שכנות (peering), מנהרות Cloud VPN, צירופי VLAN של Cloud Interconnect או מסגרת של Network Connectivity Center.

  הגדרת רשת בקצה העורפי

  • כשיוצרים קבוצות אזוריות של נקודות קצה ברשת (NEGs) וקבוצות היברידיות של נקודות קצה ברשת (NEGs), צריך לציין במפורש את רשת ה-VPC.
  • בקבוצות מופעי מכונה מנוהלים, רשת VPC מוגדרת בתבנית של הגדרות מכונה.
  • בקבוצות של מכונות וירטואליות לא מנוהלות, רשת ה-VPC של קבוצת המכונות הווירטואליות מוגדרת כך שתתאים לרשת ה-VPC של ממשק nic0 עבור המכונה הווירטואלית הראשונה שנוספה לקבוצת המכונות הווירטואליות.

  דרישות לגבי רשתות עורפיות

  הרשת של ה-backend צריכה לעמוד באחת מהדרישות הבאות:

  • רשת ה-VPC של ה-backend חייבת להיות זהה לרשת ה-VPC של כלל ההעברה.

  • רשת ה-VPC של ה-Backend צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות שכנות (VPC Network Peering). צריך להגדיר החלפות של נתיבי רשתות משנה כדי לאפשר תקשורת בין רשת ה-VPC של כלל ההעברה לבין רשתות המשנה שבהן נעשה שימוש במופעי ה-Backend או בנקודות הקצה.

  דרישות לגבי רשת משנה של IPv6 בשרת העורפי

  גרסת ה-IP שמשמשת לחיבור הקצה הקדמי לא תלויה בחיבור הקצה האחורי. מכיוון שרשת המשנה של ה-proxy היא dual-stack ‏ (IPV4_IPV6), היא יכולה לתקשר עם ה-backends באמצעות IPv4 או IPv6.

  אם מופעלות בדוגמאות העורפיות שלכם כתובות IPv6, אפשר להגדיר את רשת המשנה העורפית עם סוג מחסנית של IPV4_ONLY או IPV4_IPV6 (מחסנית כפולה). אם סוג הסטאק של רשת המשנה של ה-Backend כולל IPv6, צריך להגדיר באופן מפורש את ipv6-access-type של רשת המשנה ל-INTERNAL.

• גם רשת ה-VPC של ה-backend וגם רשת ה-VPC של כלל ההעברה צריכות להיות רשתות VPC מסוג Spoke שמצורפות לאותו מרכז NCC. מסנני הייבוא והייצוא צריכים לאפשר תקשורת בין רשת המשנה של ה-proxy בלבד ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שמשמשות את מופעי ה-backend או נקודות הקצה.

• בכל שאר סוגי ה-Backend, כל ה-Backend-ים צריכים להיות ממוקמים באותה רשת VPC ובאותו אזור.

שרתי קצה עורפיים וממשקי רשת

אם משתמשים בעורפי קצה של קבוצות מופעי מכונה, המנות תמיד מועברות אל nic0. אם רוצים לשלוח מנות לממשקי nic0 שאינם ממשקים (vNIC או ממשקי רשת דינמיים), צריך להשתמש במקום זאת ב-NEG backends.

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

חלוקת משנה של הקצה העורפי

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

כברירת מחדל, חלוקת המשנה של ה-Backend מושבתת. מידע על הפעלת התכונה הזו זמין במאמר Backend subsetting for regional internal Application Load Balancers.

בדיקות תקינות

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

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

פרוטוקול בדיקת תקינות

אף על פי שזה לא נדרש ולא תמיד אפשרי, מומלץ להשתמש בבדיקת תקינות שהפרוטוקול שלה תואם לפרוטוקול של שירות ה-Backend. לדוגמה, בדיקת תקינות של HTTP/2 בודקת בצורה הכי מדויקת את הקישוריות של HTTP/2 לשרתי קצה עורפיים. לעומת זאת, מאזני עומסים פנימיים של אפליקציות (ALB) שמשתמשים בשרתי קצה היברידיים של NEG לא תומכים בבדיקות תקינות של gRPC. רשימת הפרוטוקולים הנתמכים לבדיקות תקינות מופיעה בקטע בדיקות תקינות במאמר על התכונות של איזון העומסים.

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

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

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

• סקירה כללית על בדיקות תקינות
• יצירת בדיקות תקינות

כללי חומת אש

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

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

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

• אין צורך לאפשר תעבורה מטווחים של בדיקות תקינות של Google עבור קבוצות NEG היברידיות. עם זאת, אם אתם משתמשים בשילוב של NEGs היברידיים ואזוריים בשירות קצה עורפי יחיד, אתם צריכים לאפשר תנועה מטווחים של בדיקות תקינות של Google עבור ה-NEGs האזוריים.
• ב-NEGs אזוריים באינטרנט, בדיקות התקינות הן אופציונליות. תעבורת נתונים ממאזני עומסים שמשתמשים ב-regional internet NEGs מגיעה מ-proxy-only subnet ואז עוברת תרגום NAT (באמצעות Cloud NAT) לכתובות IP של NAT שהוקצו באופן ידני או אוטומטי. התנועה הזו כוללת גם בדיקות תקינות וגם בקשות של משתמשים ממאזן העומסים לשרתי הקצה. פרטים נוספים זמינים במאמר בנושא NEGs אזוריים: שימוש בשער Cloud NAT.

משתמשים בכללי מדיניות חומת האש של Cloud NGFW כדי לשלוט בגישת הלקוח לכללי ההעברה של מאזני עומסים מבוססי שרת proxy של Envoy, כמו מאזני עומסים פנימיים אזוריים של אפליקציות ומאזני עומסים פנימיים של אפליקציות חוצות-אזורים. התכונות האלה נתמכות ב-Cloud NGFW Essentials וב-Cloud NGFW Standard.

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

גישת לקוח

הלקוחות יכולים להיות באותה רשת או ברשת VPC שמחוברת באמצעות קישור בין רשתות VPC שכנות.

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

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

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

הגישה הגלובלית מושבתת	הגישה הגלובלית מופעלת
הלקוחות צריכים להיות באותו אזור כמו מאזן העומסים. הם גם צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering.	הלקוחות יכולים להיות בכל אזור. הם עדיין צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering (קישור בין רשתות VPC).
לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה צריכים להיות באותו אזור כמו מאזן העומסים.	לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה יכולים להיות בכל אזור.

תמיכה ב-GKE

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

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

• ‫Internal Ingresses שנוצרו באמצעות בקר ה-GKE Ingress הם תמיד מאזני עומסים פנימיים אזוריים של אפליקציות. בקר ה-Ingress של GKE תמיד משתמש בקצה עורפי של GCE_VM_IP_PORT Zonal NEG.

• אתם יכולים להשתמש ב-GCE_VM_IP_PORT zonal NEG שנוצר ומנוהל על ידי GKE Services כקצה עורפי לכל מאזן עומסים של אפליקציות או מאזן עומסי רשת של proxy. מידע נוסף זמין במאמר בנושא איזון עומסים שמקורם בקונטיינר באמצעות קבוצות עצמאיות של נקודות קצה ברשת (NEGs) באזורים.

ארכיטקטורות של VPC משותף

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

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

רשתות משנה וכתובת IP	רכיבים של הקצה הקדמי	רכיבי קצה עורפי
יוצרים את הרשתות ותתי-הרשתות הנדרשות (כולל תת-הרשת של ה-proxy בלבד) בפרויקט המארח של ה-VPC המשותף. אפשר להגדיר את כתובת ה-IP הפנימית של מאזן העומסים בפרויקט המארח או בפרויקט השירות, אבל חובה להשתמש בתת-רשת ברשת ה-VPC המשותפת הרצויה בפרויקט המארח. הכתובת עצמה מגיעה מטווח כתובות ה-IP הראשי של תת-הרשת שאליה מתבצעת ההפניה.	כתובת ה-IP הפנימית האזורית, כלל ההעברה, ה-proxy של HTTP(S) היעד ומפת URL המשויכת צריכים להיות מוגדרים באותו פרויקט. הפרויקט הזה יכול להיות פרויקט מארח או פרויקט שירות.	אפשר לבצע אחת מהפעולות הבאות: יוצרים שירותים לקצה עורפי ובק-אנד (קבוצות של מופעים, NEGs בלי שרת או כל סוג אחר של בק-אנד נתמך) באותו פרויקט שירות כמו רכיבי הקצה הקדמי. יוצרים שירותים לקצה העורפי ובק-אנדים (קבוצות מכונות, NEGs בלי שרת או כל סוג אחר של קצה עורפי נתמך) בכמה פרויקטים של שירותים שנדרש. מפת URL יחידה יכולה להפנות לשירותי קצה עורפיים בפרויקטים שונים. סוג הפריסה הזה נקרא הפניה לשירות בפרויקט אחר. כל שירות לקצה העורפי צריך להיות מוגדר באותו פרויקט שאליו מתבצעת ההפניה של ה-backend. בדיקות תקינות שמשויכות לשירותי קצה עורפיים צריכות להיות מוגדרות באותו פרויקט כמו שירות הקצה העורפי.

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

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

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

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

בקצה העורפי של אפליקציות serverless בסביבת VPC משותף

במאזן עומסים פנימי של אפליקציות (ALB) שמשתמש בקצה עורפי של NEG בלי שרת (serverless), שירות Cloud Run שמשמש כגיבוי צריך להיות באותו פרויקט שירות כמו שירות הקצה העורפי ו-NEG בלי שרת (serverless). אפשר ליצור את רכיבי הקצה הקדמי של מאזן העומסים (כלל העברה, שרת proxy ביעד, מפת URL) בפרויקט המארח, באותו פרויקט שירות שבו נמצאים רכיבי הבק-אנד, או בכל פרויקט שירות אחר באותו סביבת VPC משותף.

הפניה לשירותים בפרויקטים שונים

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

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

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

בעלי השירות יכולים לשמור על אוטונומיה לגבי החשיפה של השירותים שלהם ולשלוט בגישה של המשתמשים לשירותים שלהם באמצעות איזון העומסים. ההרשאה הזו ניתנת באמצעות תפקיד מיוחד ב-IAM שנקרא משתמש בשירותי איזון עומסים ב-Compute (roles/compute.loadBalancerServiceUser).

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

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

הערות לגבי שימוש בהפניה לשירותים בין פרויקטים

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

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

הנה דוגמה לפריסת VPC משותף שבה הקצה הקדמי ומפת URL של מאזן העומסים נוצרות בפרויקט שירות א', ומפת URL מפנה לשירות לקצה העורפי בפרויקט שירות ב'.

במקרה כזה, אדמינים של רשתות או אדמינים של איזון עומסים בפרויקט שירות א צריכים גישה לשירותי קצה עורפי בפרויקט שירות ב. אדמינים בפרויקט שירות ב' מקצים את התפקיד Compute Load Balancer Services User ‏(roles/compute.loadBalancerServiceUser) לאדמינים של איזון עומסים בפרויקט שירות א' שרוצים להפנות לשירות הקצה העורפי בפרויקט שירות ב'.

‫

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

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

במקרה כזה, אדמינים של רשתות או אדמינים של מאזני עומסים בפרויקט המארח צריכים גישה לשירותי קצה עורפי בפרויקט השירות. אדמינים בפרויקט השירות מעניקים את התפקיד Compute Load Balancer Services User ‏(roles/compute.loadBalancerServiceUser) לאדמינים של איזון עומסים בפרויקט המארח א', שרוצים להפנות לשירות הקצה העורפי בפרויקט השירות.

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

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

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

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

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

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

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

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

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

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

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

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

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

זמן קצוב לתפוגה של HTTP keepalive נקרא גם זמן קצוב לתפוגה של TCP idle.

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

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

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

כדי להגדיר ניסיונות חוזרים, אפשר להשתמש במדיניות ניסיונות חוזרים במפת URL. מספר ברירת המחדל של הניסיונות החוזרים (numRetries) הוא 1. הערך המקסימלי שאפשר להגדיר ל-perTryTimeout הוא 24 שעות.

ללא מדיניות ניסיון חוזר, בקשות לא מוצלחות שאין להן גוף HTTP (לדוגמה, בקשות GET) שמובילות לתגובות HTTP 502, 503 או 504, ינסו שוב פעם אחת.

לא מתבצע ניסיון חוזר של בקשות HTTP POST.

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

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

גישה לרשתות מחוברות

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

• קישור בין רשתות VPC שכנות (peering)
• ‫Cloud VPN ו-Cloud Interconnect

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

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

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

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

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

מוצר

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

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

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

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

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

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

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

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

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

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

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

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

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

ללא

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

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

ערך ברירת המחדל של ההעדפה לשימוש באותו שרת (session affinity) הוא NONE.

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

זיקה לסשן (session affinity) של כתובת ה-IP של הלקוח (CLIENT_IP) היא גיבוב של 2-tuple שנוצר מכתובות ה-IP של המקור והיעד של חבילת הנתונים. זיקה לכתובת IP של לקוח מעבירה את כל הבקשות מאותה כתובת IP של לקוח לאותו קצה עורפי, כל עוד יש לאותו קצה עורפי קיבולת והוא תקין.

כשמשתמשים בזיקה לכתובת IP של לקוח, חשוב לזכור את הנקודות הבאות:

• כתובת ה-IP של היעד של החבילה זהה לכתובת ה-IP של כלל ההעברה של מאזן העומסים רק אם החבילה נשלחת ישירות למאזן העומסים.
• יכול להיות שכתובת ה-IP של המקור של חבילת הנתונים לא תהיה זהה לכתובת ה-IP שמשויכת ללקוח המקורי אם חבילת הנתונים עוברת עיבוד על ידי מערכת NAT או proxy ביניים לפני שהיא מועברת למאזן עומסים. Google Cloud במצבים שבהם הרבה לקוחות חולקים את אותה כתובת IP אפקטיבית של המקור, יכול להיות שחלק מהמכונות הווירטואליות של ה-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) שפועלים בכמה אזורים	GCILB
מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)	GCILB

מאפיין הנתיב של קובץ ה-Cookie שנוצר הוא תמיד לוכסן (/), ולכן הוא חל על כל השירותים לקצה העורפי באותה מפת URL, בתנאי שגם השירותים האחרים לקצה העורפי משתמשים בזיקה לקובץ Cookie שנוצר.

אפשר להגדיר את ערך ה-TTL (אורך החיים) של קובץ ה-Cookie בין 0 ל-1,209,600 שניות (כולל) באמצעות הפרמטר affinityCookieTtlSec של שירות ה-Backend. אם לא מציינים את affinityCookieTtlSec, ערך ברירת המחדל של TTL הוא 0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעבר לגיבוי (Failover)

אם שרת קצה עורפי לא תקין, התנועה מופנית אוטומטית לשרתי קצה עורפיים תקינים.

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

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

זמינות גבוהה ומעבר לשני אזורים במקרה של כשל

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

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

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

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

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

   בדוגמה לפריסה של זמינות גבוהה מוצגים הפרטים הבאים:

   • מאזן עומסים פנימי של אפליקציות (ALB) חוצה אזורים עם כתובת IP וירטואלית (VIP) בחלק הקדמי באזורים RegionA ו-RegionB ברשת ה-VPC. הלקוחות שלך נמצאים באזור RegionA.
   • כדי להפוך את מאזן העומסים לנגיש, אפשר להשתמש בכתובות VIP של קצה קדמי משני אזורים, ולהשתמש במדיניות ניתוב DNS כדי להחזיר את כתובת ה-VIP האופטימלית ללקוחות. כדאי להשתמש במדיניות ניתוב לפי מיקום גיאוגרפי אם רוצים שהלקוחות ישתמשו בכתובת ה-VIP שנמצאת הכי קרוב מבחינה גיאוגרפית.
   • מדיניות ניתוב DNS יכולה לזהות אם כתובת VIP לא מגיבה במהלך הפסקת חשמל אזורית, ולהחזיר ללקוחות את כתובת ה-VIP האופטימלית הבאה, כדי להבטיח שהאפליקציה תמשיך לפעול גם במהלך הפסקות חשמל אזוריות.

   

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

   בדוגמה לפריסת מעבר לגיבוי בענן בין אזורים מוצגים הפרטים הבאים:

   • מאזן עומסים פנימי של אפליקציות (ALB) חוצה אזורים עם כתובת VIP של קצה קדמי באזור RegionA של רשת ה-VPC. הלקוחות שלכם נמצאים גם באזור RegionA.
   • שירות לקצה עורפי גלובלי שמפנה לקצה העורפי באזורים RegionA ו-RegionB Google Cloud .
   • כשהשרתים העורפיים באזור RegionA מושבתים, התנועה מועברת לאזור RegionB.

   

תמיכה ב-WebSocket

Google Cloud מאזני עומסים שמבוססים על HTTP(S) תומכים בפרוטוקול WebSocket כשמשתמשים ב-HTTP או ב-HTTPS כפרוטוקול לבק-אנד. לא צריך להגדיר את איזון העומסים כדי להעביר חיבורי WebSocket דרך proxy.

פרוטוקול ה-WebSocket מספק ערוץ תקשורת דו-כיווני בין לקוחות לבין מאזן העומסים. מידע נוסף זמין ב-RFC 6455.

פרוטוקול ה-WebSocket פועל באופן הבא:

1. מאזן העומסים מזהה בקשת websocket‏ Upgrade מלקוח HTTP או HTTPS. הבקשה מכילה את הכותרות Connection: Upgrade ו-Upgrade: websocket, ואחריהן כותרות בקשה רלוונטיות אחרות שקשורות ל-WebSocket.
2. הקצה העורפי שולח תגובת websocket Upgrade. מופע ה-backend שולח תגובה 101 switching protocol עם כותרות Connection: Upgrade ו-Upgrade: websocket וכותרות תגובה אחרות שקשורות ל-WebSocket.
3. מאזן העומסים מעביר תנועה דו-כיוונית באמצעות פרוקסי למשך החיבור הנוכחי.

אם שרת עורפי (backend instance) מחזיר קוד סטטוס 426 או 502, מאזן העומסים (LB) סוגר את החיבור.

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

תמיכה ב-HTTP/2

‫HTTP/2 הוא עדכון משמעותי של פרוטוקול HTTP/1. יש 2 מצבים של תמיכה ב-HTTP/2:

• ‫HTTP/2 over TLS
• Cleartext HTTP/2 over TCP

‫HTTP/2 over TLS

יש תמיכה ב-HTTP/2 over TLS לחיבורים בין לקוחות לבין מאזן עומסים חיצוני של אפליקציות (ALB), ולחיבורים בין מאזן העומסים לבין הקצה העורפי שלו.

מאזן העומסים מנהל משא ומתן אוטומטי עם לקוחות לגבי HTTP/2 כחלק משיטת הלחיצה של TLS, באמצעות תוסף ה-TLS של ALPN. גם אם מאזן העומסים מוגדר לשימוש ב-HTTPS, לקוחות מודרניים משתמשים ב-HTTP/2 כברירת מחדל. השליטה בזה מתבצעת בצד הלקוח, ולא במאזן העומסים.

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

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

מספר מקסימלי של סטרימינג בו-זמני ב-HTTP/2

ההגדרה HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS מתארת את המספר המקסימלי של סטרימינג שנקודת קצה מקבלת, שהופעל על ידי העמית. הערך שמפורסם על ידי לקוח HTTP/2 לGoogle Cloud מאזן עומסים הוא חסר משמעות, כי מאזן העומסים לא יוזם סטרימים ללקוח.

במקרים שבהם מאזן העומסים משתמש ב-HTTP/2 כדי לתקשר עם שרת שפועל במכונה וירטואלית, מאזן העומסים מתחשב בערך SETTINGS_MAX_CONCURRENT_STREAMS שמוגדר בשרת, עד לערך מקסימלי של 100. בכיוון הבקשה (מאזן העומסיםGoogle Cloud ← שרת gRPC), מאזן העומסים משתמש בפריים SETTINGS הראשוני משרת gRPC כדי לקבוע כמה סטרים לכל חיבור יכולים להיות בשימוש בו-זמנית. אם השרת מפרסם ערך גבוה מ-100, מאזן העומסים משתמש ב-100 כמספר המקסימלי של הזרמים בו-זמנית. אם הערך שמתפרסם הוא אפס, מאזן העומסים לא יכול להעביר בקשות לשרת, וזה עלול לגרום לשגיאות.

גודל דינמי של טבלת כותרות HTTP/2

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

מגבלות של HTTP/2

• יכול להיות שחיבור HTTP/2 בין מאזן העומסים לבין המופע ידרוש הרבה יותר חיבורי TCP למופע מאשר חיבור HTTP או HTTPS. אי אפשר להשתמש ב-HTTP/2 כדי לצמצם את מספר החיבורים האלה באמצעות HTTP או HTTPS. כתוצאה מכך, יכול להיות שתראו חביון גבוה בעורף המערכת, כי החיבורים לעורף המערכת מתבצעים בתדירות גבוהה יותר.
• פרוטוקול HTTP/2 בין מאזן העומסים לבין ה-Backend לא תומך בהרצת פרוטוקול WebSocket על פני זרם יחיד של חיבור HTTP/2 ‏ (RFC 8441).
• ‫HTTP/2 בין מאזן העומסים לבין ה-Backend לא תומך ב-Server Push.
• שיעור השגיאות ונפח הבקשות של gRPC לא מוצגים ב-Google Cloud API או במסוף Google Cloud . אם נקודת הקצה של gRPC מחזירה שגיאה, קוד סטטוס של HTTP‏ 200 OK יופיע ביומני מאזן העומסים ובנתוני המעקב.

‫HTTP/2 over cleartext TCP

‫HTTP/2 over cleartext TCP, שמיוצג על ידי המחרוזת h2c לפי RFC 7540, מאפשר לכם להשתמש ב-HTTP/2 ללא הצפנת TLS. היא נתמכת בחיבורים הבאים:

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

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

תמיכה ב-H2C זמינה גם למאזני עומסים שנוצרו באמצעות בקר GKE Gateway ו-Cloud Service Mesh, אבל היא לא נתמכת במאזני עומסים קלאסיים של אפליקציות.

תמיכה ב-gRPC

‫gRPC היא מסגרת קוד פתוח לקריאות לשירותים מרוחקים. היא מבוססת על תקן HTTP/2. תרחישי שימוש ב-gRPC כוללים את הדוגמאות הבאות:

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

כדי להשתמש ב-gRPC עם האפליקציות שלכם, אתם צריכים להעביר בקשות באמצעות proxy מקצה לקצה דרך HTTP/2. Google Cloud כדי לעשות את זה, יוצרים מאזן עומסים של אפליקציות עם אחת מההגדרות הבאות:

• פרוטוקול HTTP/2 over TLS בין הלקוח לבין מאזן העומסים ופרוטוקול H2C בין מאזן העומסים לבין הקצה העורפי: יוצרים מאזן עומסים ב-HTTPS (שמוגדר עם שרת proxy של HTTPS יעד ואישור SSL). בנוסף, אתם יכולים להגדיר את מאזן העומסים להשתמש ב-HTTP/2 לחיבורים לא מוצפנים בין מאזן העומסים לבין הבק-אנד שלו. כדי לעשות זאת, צריך להגדיר את פרוטוקול שירות לקצה העורפי ל-H2C.

• תעבורה מוצפנת מקצה לקצה באמצעות HTTP/2 over TLS: אתם יוצרים מאזן עומסים של HTTPS (שמוגדר עם שרת proxy של HTTPS יעד ואישור SSL). מאזן העומסים מנהל משא ומתן עם לקוחות לגבי HTTP/2 כחלק מלחיצת היד של SSL, באמצעות תוסף ה-TLS של ALPN.

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

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

תמיכה ב-TLS

כברירת מחדל, פרוקסי יעד מסוג HTTPS מקבל רק TLS 1.0,‏ 1.1,‏ 1.2 ו-1.3 כשמסתיימות בקשות SSL של לקוחות.

כשמאזן עומסים של אפליקציות פנימי משתמש ב-HTTPS כפרוטוקול של שירות לקצה העורפי, הוא יכול לנהל משא ומתן על TLS 1.2 או 1.3 עם הקצה העורפי.

תמיכה ב-TLS הדדי

TLS דו-צדדי, או mTLS, הוא פרוטוקול בתקן התעשייה לאימות דו-צדדי בין לקוח לשרת. פרוטוקול mTLS עוזר לוודא שהלקוח והשרת מאמתים זה את זה על ידי בדיקה שלכל אחד מהם יש אישור תקף שהונפק על ידי רשות אישורים (CA) מהימנה. בניגוד ל-TLS רגיל, שבו רק השרת עובר אימות, ב-mTLS גם הלקוח וגם השרת צריכים להציג אישורים כדי לאשר את הזהויות של שני הצדדים לפני יצירת התקשורת.

כל מאזני העומסים של האפליקציות תומכים ב-mTLS. ב-mTLS, מאזן העומסים מבקש מהלקוח לשלוח אישור כדי לאמת את עצמו במהלך לחיצת היד של TLS עם מאזן העומסים. אתם יכולים להגדיר מאגר מהימן בCertificate Manager, שמאזן העומסים ישתמש בו כדי לאמת את שרשרת המהימנות של אישור הלקוח.

מידע נוסף על mTLS זמין במאמר בנושא אימות TLS בו-זמני (mTLS).

מגבלות

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

• מאזני עומסים פנימיים של אפליקציות לא תואמים לתכונות הבאות:

  • Cloud CDN
  • אישורי SSL בניהול Google ב-Compute Engine (יש תמיכה באישורי SSL בניהול Google ב-Certificate Manager)

• כדי להשתמש באישורים של Certificate Manager עם מאזני עומסים פנימיים של אפליקציות, צריך להשתמש ב-API או ב-CLI של gcloud. במסוףGoogle Cloud אין תמיכה באישורים של Certificate Manager.

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

• ‫Google Cloud לא מציג אזהרה אם ברשת המשנה של שרת ה-proxy בלבד נגמרות כתובות ה-IP.

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

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

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

• מאזני עומסים פנימיים של אפליקציות (ALB) לא תומכים ב-Cloud Functions דור ראשון וב-App Engine. מידע נוסף זמין במאמר סקירה כללית של קבוצות NEGs בלי שרת (serverless): מאזני עומסים נתמכים.

• מאזני עומסים פנימיים של אפליקציות לא תומכים ב-Cloud Trace.

המאמרים הבאים

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

• כדי להגדיר איזון עומסים לשירותים שפועלים בתרמילים של GKE, אפשר לעיין במאמרים פריסת שערים של GKE, איזון עומסים מקורי של קונטיינרים עם קבוצות עצמאיות של נקודות קצה ברשת (NEGs) ובקטע צירוף מאזן עומסים פנימי של אפליקציות לקבוצות עצמאיות של נקודות קצה ברשת (NEGs).

• מידע נוסף על ניהול משאבים של תת-רשתות של שרת proxy בלבד זמין במאמר בנושא תת-רשתות של שרת proxy בלבד למאזני עומסים מבוססי Envoy.

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

• כדי להגדיר מאזן עומסים פנימי אזורי של אפליקציות (ALB) באמצעות Private Service Connect, אפשר לעיין במאמר בנושא גישה לממשקי Google APIs אזוריים דרך בק-אנדים.

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