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

זיהוי המצב

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

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

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

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

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

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

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

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

‫

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

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

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

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

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

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

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

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

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

בנוסף:

• תת-רשתות של פרוקסי בלבד משמשות רק לפרוקסי Envoy, ולא לשרתי הקצה העורפיים.
• מכונות וירטואליות בבק-אנד או נקודות קצה של כל מאזני העומסים הפנימיים של אפליקציות באזור וברשת VPC מקבלות חיבורים מרשת המשנה של שרת ה-proxy בלבד.
• כתובת ה-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) ויפנו לאותו יעד HTTP או HTTPS proxy, כל עוד השילוב הכולל של כתובת ה-IP, היציאה והפרוטוקול יהיה ייחודי לכל כלל העברה. כך תוכלו להשתמש במאזן עומסים יחיד עם מפת URL משותפת כשרת proxy לכמה אפליקציות.

סוג כלל ההעברה, כתובת ה-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
‫Cross-region internal Application Load Balancer Regional internal Application Load Balancer	כתובות IPv4 פנימיות אזוריות תמיד קיימות בתוך רשתות VPC. כשיוצרים את כלל ההעברה, צריך לציין את תת-הרשת שממנה נלקחת כתובת ה-IP הפנימית. תת-הרשת הזו צריכה להיות באותו אזור ובאותה רשת VPC שבה נוצרה תת-רשת של שרת proxy בלבד. לכן, יש שיוך רשת משתמע.

שרת proxy יעד

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

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

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

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

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

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

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

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

אישורי SSL

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

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

מצב מאזן עומסים	סוג אישור SSL
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים	‫Certificate Manager אישורים בניהול עצמי ואישורים שמנוהלים על ידי Google. ב-Certificate Manager יש תמיכה בסוגים הבאים של אישורים שמנוהלים על ידי Google: אימות DNS באמצעות DNS ציבורי. מידע נוסף זמין במאמר פריסת אישור גלובלי שמנוהל על ידי Google עם הרשאת DNS. Private Certificate Authority Service. מידע נוסף זמין במאמר בנושא יצירת אישור שמנוהל על ידי Google שהונפק על ידי מופע של שירות רשות האישורים. אין תמיכה באישורים שמנוהלים על ידי 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 או כותרות). על סמך החלטת הניתוב, השרת הפרוקסי מעביר בקשות של לקוחות לשירותי קצה עורפיים ספציפיים. במפת ה-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	קבוצות אזוריות של נקודות קצה של רשתות^3	Internet NEGs	קבוצות NEG ללא שרת (serverless)	קבוצות היברידיות של נקודות קצה ברשת (NEGs)	קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים				‫ Cloud Run
מאזן עומסים פנימי אזורי של אפליקציות (ALB)				‫ Cloud Run

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

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

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

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

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

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

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

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

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

  דרישות לגבי רשת ה-Backend

  הרשת של ה-Backend חייבת לעמוד באחת מהדרישות הבאות:

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

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

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

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

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

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

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

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

גרסת טרום-השקה

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

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

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

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

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

גישת לקוח

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

gcloud

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

API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מוצר

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

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

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

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

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

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

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

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

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

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

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

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

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

ללא

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

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

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

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

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

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

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

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

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

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

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

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

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

• זיקה לקובץ Cookie שנוצר
• תחום עניין משותף של קובצי Cookie מסוג HTTP
• זיקה לסשן מבוססת-קובצי Cookie עם שמירת מצב

זיקה לקובץ Cookie שנוצר

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

השם של קובץ ה-Cookie שנוצר משתנה בהתאם לסוג איזון העומסים.

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

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

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

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

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

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

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

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

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

כל מאזני העומסים של האפליקציות תומכים בהעדפה שמבוססת על קובצי Cookie של HTTP.

אפשר להגדיר את ערכי ה-TTL של קובץ ה-Cookie באמצעות שניות, חלקי שניות (בננו-שניות) או שניות בתוספת חלקי שניות (בננו-שניות) באמצעות הפרמטרים הבאים של שירות לקצה העורפי והערכים התקינים:

• אפשר להגדיר את consistentHash.httpCookie.ttl.seconds לערך בין 0 ל-315576000000 (כולל).
• אפשר להגדיר את consistentHash.httpCookie.ttl.nanos לערך בין 0 ל-999999999 (כולל). יחידות הזמן הן ננו-שניות, ולכן 999999999 שווה ל-.999999999 שניות.

אם לא מציינים את consistentHash.httpCookie.ttl.seconds ואת consistentHash.httpCookie.ttl.nanos, המערכת משתמשת בערך של פרמטר שירות לקצה העורפי affinityCookieTtlSec. אם לא מציינים את affinityCookieTtlSec, ערך ברירת המחדל של TTL הוא 0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

   

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

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

תמיכה ב-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 load balancer ← gRPC server), מאזן העומסים משתמש בפריים 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. היא נתמכת בחיבורים הבאים:

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

  חשוב: אין תמיכה ב-gRPC over H2C בחיבור הזה.

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

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

תמיכה ב-gRPC

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

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

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

• פרוטוקול HTTP/2 over TLS בין הלקוח למאזן העומסים ופרוטוקול H2C בין מאזן העומסים לבין ה-backend: יוצרים מאזן עומסים ב-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 האלה כדי להעביר אותן באמצעות פרוקסי דרך 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 לא מציג אזהרה אם ברשת המשנה של השרת פרוקסי בלבד נגמרות כתובות ה-IP.

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

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

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

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

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

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

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

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

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

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

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

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