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

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

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

מצבי פעולה

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

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

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

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

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

זיהוי המצב

המסוף

1. במסוף Google Cloud , עוברים לדף איזון עומסים.

   כניסה לדף Load balancing

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

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בנוסף:

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

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

גרסת טרום-השקה — מאזני עומסים של אפליקציות (ALB) אזוריים פנימיים, אזוריים חיצוניים וחוצי-אזורים תומכים בסיום תנועת IPv6

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

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

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

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

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

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

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

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

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

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

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

שיוך רשת VPC

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

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

שרת proxy לחלוקת העומס

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

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

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

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

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

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

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

אישורי SSL

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

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

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

מפות URL

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

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

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

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

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

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

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

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

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

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

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

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

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

בק-אנדים

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

מצב מאזן עומסים	רכיבי קצה עורפי נתמכים בשירות לקצה העורפי^1						תמיכה בקטגוריות קצה עורפי	תמיכה ב-Cloud Armor	תמיכה ב-Cloud CDN	תמיכה ברכישות מתוך האפליקציה (IAP)	תמיכה בתוספי שירות
	קבוצות של מכונות^2	קבוצות NEG אזוריות^3	thought קבוצות של נקודות קצה ברשת באינטרנט	קבוצות NEG ללא שרת (serverless)	קבוצות NEG היברידיות	קבוצות NEG של Private Service Connect
מאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים				Cloud Run
מאזן עומסים פנימי אזורי של אפליקציות (ALB)				Cloud Run

‫¹ הקצוות העורפיים בשירות לקצה העורפי חייבים להיות מאותו סוג: כולם קבוצות של מכונות או כולם מאותו סוג של NEG. החריג לכלל הזה הוא שאפשר להשתמש גם GCE_VM_IP_PORT בקבוצות NEG אזוריות וגם בקבוצות NEG היברידיות באותו שירות לקצה העורפי, כדי לתמוך ב ארכיטקטורה היברידית.

‫² אפשר לשלב באותו שירות לקצה העורפי קבוצות של מכונות מנוהלות ולא מנוהלות ברמת האזור, וקבוצות של מכונות מנוהלות ברמת המחוז. כשמשתמשים בהתאמה אוטומטית לעומס (automatic scaling) של קבוצת מופעי מכונה מנוהלים שמשמשת כקצה עורפי לשני שירותים לקצה העורפי או יותר, צריך להגדיר את מדיניות ההתאמה האוטומטית לעומס (automatic scaling) של קבוצת המופעים כך שתשתמש ב אותות מרובים.

‫³ קבוצות NEG אזוריות חייבות להשתמש בנקודות קצה (endpoints) של GCE_VM_IP_PORT.

רשתות VPC ורכיבי Back-end

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

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

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

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

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

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

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

  • רשת ה-VPC של הקצה העורפי חייבת להתאים בדיוק לרשת ה-VPC של כלל ההעברה.

  • רשת ה-VPC של הקצה העורפי צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות שכנות (peering) ב-VPC. כדי לאפשר תקשורת בין רשת המשנה שמשמשת רק לשרתי proxy ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שמשמשות את המכונות או נקודות הקצה לקצה העורפי, צריך להגדיר החלפות של נתיבים ברשת המשנה.

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

  גרסת טרום-השקה — מאזני עומסים של אפליקציות (ALB) אזוריים פנימיים, אזוריים חיצוניים וחוצי-אזורים תומכים בסיום תנועת IPv6

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

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

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

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

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

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

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

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

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

גרסת טרום-השקה — מאזני עומסים של אפליקציות (ALB) אזוריים פנימיים, אזוריים חיצוניים וחוצי-אזורים תומכים בסיום תנועת IPv6

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

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

אתם יכולים להשתמש בכללי מדיניות חומת האש של Cloud Next Generation Firewall (Cloud NGFW) כדי לשלוט בגישה של הלקוחות לכללי ההעברה של מאזני עומסים שמבוססים על שרת proxy של Envoy, כמו מאזני עומסים פנימיים אזוריים של אפליקציות ומאזני עומסים פנימיים חוצי-אזורים של אפליקציות. שתי הגרסאות, Cloud NGFW Essentials ו-Cloud NGFW Standard, תומכות בתכונות האלה. במאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים, Cloud NGFW מספק גם מניעת איומים מתקדמת בשכבה 7 (תצוגה מקדימה). מידע נוסף זמין במאמרים שימוש בכללי מדיניות גלובליים של חומת אש ברשת כדי להגן על מאזני עומסים מבוססי-Envoy ושימוש בכללי מדיניות אזוריים של חומת אש ברשת כדי להגן על מאזני עומסים פנימיים של אפליקציות ועל מאזני עומסי רשת פנימיים בשרת proxy.

גישת לקוח

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

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

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

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

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

תמיכה ב-GKE

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

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

• רכיבי Ingress פנימיים שנוצרו באמצעות בקר ה-Ingress של GKE הם תמיד מאזני עומסים של אפליקציות (ALB) פנימיים אזוריים. בקר ה-Ingress של GKE תמיד משתמש בקצוות עורפיים של קבוצות NEG אזוריות מסוג GCE_VM_IP_PORT.

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

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

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

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

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

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

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

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

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

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

רכיבי בקאנד ללא שרת (serverless) בסביבת VPC משותף

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

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

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

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

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

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

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

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

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

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

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

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

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

‫ ‫

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

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

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

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

‫ ‫

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

gcloud

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

API

שינוי הפרמטר timeoutSec של המשאב regionBackendServices

זמן קצוב לתפוגה של HTTP keepalive בצד הלקוח

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

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

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

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

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

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

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

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

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

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

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

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

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

מוצר

אפשרויות של זיקה לסשן (session affinity)

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

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

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

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

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

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

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

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

זיקה לסשן (session affinity) שמבוססת על גיבוב (hash)

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

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

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

ללא

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

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

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

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

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

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

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

זיקה לסשן (session affinity) שמבוססת על כותרת HTTP

כשמשתמשים ב-affinity של שדה כותרת (HEADER_FIELD), הבקשות מנותבות לקצוות העורפיים על סמך הערך של כותרת ה-HTTP בשדה consistentHash.httpHeaderName של השירות לקצה העורפי. כדי להפיץ בקשות בין כל הקצוות העורפיים הזמינים, כל לקוח צריך להשתמש בערך שונה של כותרת HTTP.

ההגדרה "שיוך לשדה כותרת" נתמכת אם מתקיימים התנאים הבאים:

• המדיניות המקומית של איזון העומסים היא RING_HASH או MAGLEV.
• השדה consistentHash של שירות הקצה העורפי מציין את השם של כותרת ה-HTTP‏ (httpHeaderName).

זיקה לסשן (session affinity) שמבוססת על קובצי Cookie

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

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

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

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

• בקבוצות של שרתי עורפי (backend instance), משתמשים במצב האיזון 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 של הזיקה לסשן (session affinity) של HTTP ב-Cookie request header של בקשות HTTP, מאזן העומסים מפנה את הבקשות האלה לאותו שרת עורפי (backend instance) או לאותה נקודת קצה, כל עוד קובץ ה-Cookie של הזיקה לסשן נשאר תקף. כדי לעשות את זה, ממפים את ערך קובץ ה-cookie לאינדקס שמפנה לשרת עורפי (backend instance) ספציפי או לנקודת קצה, ומוודאים שהדרישות של הזיקה לסשן של קובץ ה-cookie שנוצר מתקיימות.

כדי להשתמש ב-HTTP cookie affinity, צריך להגדיר את מצב האיזון הבא ואת ההגדרות של localityLbPolicy:

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

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

זיקה לסשן (session affinity) מבוססת-קובצי Cookie עם שמירת מצב (stateful)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• המופע או נקודת הקצה (endpoint) של הקצה העורפי שנבחרו חייבים להישאר מוגדרים כקצה עורפי. הזיקה לסשן יכולה להישבר כשאחד מהאירועים הבאים מתרחש:
  • המכונה שנבחרה תוסר מקבוצת המכונות שלה.
  • התאמה אוטומטית לעומס או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים את המכונה שנבחרה מקבוצת מופעי המכונה המנוהלים שלה.
  • אתם מסירים את נקודת הקצה שנבחרה מה-NEG שלה.
  • מסירים משירות הקצה העורפי את קבוצת המכונות או את ה-NEG שמכילים את המכונה או את נקודת הקצה שנבחרו.
• נקודת הקצה או השרת העורפי שנבחרו צריכים להישאר תקינים. הזיקה לסשן עלולה להישבר אם המכונה או נקודת הקצה שנבחרו נכשלות בבדיקות התקינות.

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

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

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

  • הוספת מכונות או נקודות קצה חדשות:

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

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

    • אתם מסירים מכונה כלשהי מקצה עורפי של קבוצת מכונות.
    • התאמה אוטומטית לעומס (autoscaling) או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים כל מכונה מה-backend של קבוצת מופעי מכונה מנוהלים.
    • אתם מסירים נקודת קצה (endpoint) כלשהי מקצה עורפי של NEG.
    • מסירים מהשירות לקצה העורפי את כל קבוצות המכונות או ה-NEG הקיימות בקצה העורפי שאינן ריקות.

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

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

יתירות כשל

אם אחד מה-backends לא תקין, התנועה מופנית אוטומטית ל-backends תקינים.

בטבלה הבאה מתוארת ההתנהגות של יתירות הכשל בכל מצב:

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

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

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

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

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

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

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

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

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

   

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

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

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

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

   

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

תמיכה ב-WebSocket

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

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

בחיבורי HTTP/1.1, פרוטוקול WebSocket משתמש במנגנון Upgrade של HTTP/1.1 כדי להעביר חיבור TCP מ-HTTP לחיבור WebSocket. פרוטוקול WebSocket ב-HTTP/1.1 פועל באופן הבא:

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

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

בחיבורי HTTP/2, פרוטוקול WebSocket משתמש בשיטה המורחבת CONNECT יחד עם שדות פסאודו-כותרת (כמו :protocol) כדי ליצור מנהרה בסטרים יחיד של HTTP/2 שיכול להעביר נתונים ל-WebSockets‏ (RFC 8441). פרוטוקול WebSocket ב-HTTP/2 פועל באופן הבא:

1. שרת בק-אנד שולח מסגרת HTTP/2 SETTINGS שמכילה את הפרמטר SETTINGS_ENABLE_CONNECT_PROTOCOL שמוגדר לערך 1. כך מאזן העומסים מקבל הודעה שה-backend תומך בשיטה המורחבת CONNECT.

2. כשמאזן העומסים מקבל את ההגדרה הזו, הוא מזהה אותה ויכול להעביר בקשות שדרוג של WebSocket. היא שולחת את בקשת השדרוג לבק-אנד באמצעות השיטה המורחבת CONNECT. הבקשה מכילה את הכותרות המדומות :method: CONNECT ו-:protocol: websocket, יחד עם כותרות בקשה רלוונטיות אחרות שקשורות ל-WebSocket.

3. ה-backend שולח תגובת הצלחה של WebSocket. שרת בק-אנד שולח תשובה מסוג 200 OK (במקום התשובה מסוג 101 Switching Protocols שמשמשת ב-HTTP/1.1) כדי ליצור את מנהרת ה-WebSocket בסטרים יחיד של חיבור HTTP/2.

4. מאזן העומסים מעביר תנועה דו-כיוונית דרך שרת proxy ב-stream של HTTP/2 שנוצר.

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

הזיקה לסשן ב-WebSockets פועלת באותו אופן כמו בכל בקשה אחרת. מידע נוסף זמין במאמר זיקה לסשן (session affinity).

תמיכה ב-HTTP/2

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

• ‫HTTP/2 over TLS
• ‫HTTP/2 לא מוצפן דרך TCP

‫HTTP/2 over TLS

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

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

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

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

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

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

מגבלות של HTTP/2

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

‫HTTP/2 מעל TCP לא מוצפן

‫HTTP/2 מעל TCP בטקסט לא מוצפן, שמיוצג על ידי המחרוזת "h2c" לפי RFC 7540, מאפשר להשתמש ב-HTTP/2 בלי הצפנת TLS. הוא נתמך בחיבורים הבאים:

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

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

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

תמיכה ב-gRPC

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

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

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

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

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

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

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

תמיכה ב-TLS

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

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

תמיכה ב-Mutual TLS (mTLS)

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

• אי אפשר לציין כתובת IP מילולית שהיא לא RFC 1918 (לדוגמה, 100.64.0.0/10 או טווח ציבורי שמשמש באופן פרטי) ישירות באמצעות הדגל --address כשיוצרים כלל העברה. אם תעשו את זה, תופיע שגיאת אימות של ה-API שבה מצוין שהכתובת היא לא כתובת RFC 1918.

  כדי להשתמש בכתובת IP שאינה RFC 1918, צריך לבצע אחת מהפעולות הבאות כשיוצרים את כלל ההעברה:

  • משמיטים את הדגל --address כדי לאפשר ל- Google Cloud להקצות באופן דינמי כתובת IP תקינה מרשת המשנה.
  • קודם צריך להקצות משאב של כתובת IP עם שם בתוך תת-הרשת של היעד באמצעות --purpose=SHARED_LOADBALANCER_VIP. כשיוצרים את כלל ההעברה, מפנים לשם השמור באמצעות הדגל --address.

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

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

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

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

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

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

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

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

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