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

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

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

מצבי פעולה

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

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

• ‫Classic Application Load Balancer. זהו מאזן עומסים חיצוני קלאסי של אפליקציות (ALB), שהוא גלובלי במסלול פרימיום אבל אפשר להגדיר אותו כאזורי במסלול רגיל. מאזן העומסים הזה מיושם בממשקי קצה של Google‏ (GFE). מערכות GFE מופצות ברחבי העולם ופועלות יחד באמצעות הרשת הגלובלית ורמת הבקרה של Google.

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

מצב מאזן העומסים	תרחישים מומלצים לדוגמה	יכולות
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	משתמשים במאזן העומסים הזה לעומסי עבודה חיצוניים של HTTP(S) עם משתמשים שמפוזרים ברחבי העולם או שירותי קצה עורפיים בכמה אזורים.	תואם ל-GKE באמצעות Gateway (תזמור מלא) או NEGs עצמאיים (תזמור ידני) תמיכה בניהול מתקדם של תעבורת נתונים כתובות IP חיצוניות גלובליות מסוג Anycast במסלול פרימיום אפשר לגשת לשרתי בק-אנד בכמה אזורים תמיכה ב-Cloud CDN תמיכה ב-Cloud Armor
מאזן עומסים קלאסי של אפליקציות (ALB)	מאזן העומסים הזה הוא גלובלי במסלול פרימיום. במסלול שירות הרשת מסוג פרימיום, מאזן העומסים הזה מציע איזון עומסים בכמה אזורים, מנסה להפנות את תעבורת הנתונים אל קצה העורף הקרוב ביותר שפועל בצורה תקינה ויש לו קיבולת, ומסיים את תעבורת הנתונים של HTTP(S) הכי קרוב למשתמשים. פרטים על תהליך חלוקת הבקשות מופיעים במאמר בנושא חלוקת תנועה. במסלול השירות הרגיל של רשת, מאזן העומסים הזה יכול להפיץ תעבורה לשרתי בק-אנד באזור אחד בלבד.	תואם ל-GKE באמצעות Gateway (תזמור מלא), Ingress (תזמור מלא) או NEGs עצמאיים (תזמור ידני) תמיכה ב-Google Cloud Armor פחות תכונות לניתוב תנועה רשימה מלאה של היכולות מופיעה בדף תכונות של איזון עומסים.
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	מאזן העומסים הזה כולל הרבה מהתכונות של מאזן העומסים הקלאסי הקיים של אפליקציות (ALB), וגם יכולות מתקדמות לניהול תעבורת נתונים. משתמשים במאזן העומסים הזה אם רוצים להציג תוכן רק ממיקום גיאוגרפי אחד (לדוגמה, כדי לעמוד בדרישות של תקנות). אפשר להגדיר את מאזן העומסים הזה במסלול פרימיום או במסלול רגיל.	תואם ל-GKE באמצעות NEGs עצמאיים (תזמור ידני) תמיכה ביכולות מתקדמות של ניהול תעבורת נתונים כתובות VIP אזוריות באמצעות מסלול רגיל של רשת הפסקת ה-TLS באזור יחיד שאתם מגדירים התוכן מוצג רק מהאזור שהוגדר רשימה מלאה מופיעה במאמר תכונות של איזון עומסים.

זיהוי המצב

המסוף

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

   כניסה לדף Load balancing

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

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

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

ארכיטקטורה

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

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

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

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

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

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

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

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

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

עולמי

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

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

אזורי

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

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

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

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

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

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

אם יצרתם בעבר תת-רשת מסוג proxy-only באמצעות --purpose=INTERNAL_HTTPS_LOAD_BALANCER, אתם צריכים להעביר את הייעוד של תת-הרשת ל-REGIONAL_MANAGED_PROXY לפני שתוכלו ליצור מאזני עומסים אחרים שמבוססים על Envoy באותו אזור של רשת ה-VPC.

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

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

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

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

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

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

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

מצב מאזן העומסים	Network Service Tier	כלל העברה, כתובת IP וסכמת איזון עומסים	ניתוב מהאינטרנט לקצה הקדמי של מאזן העומסים
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	מסלול פרימיום	כלל העברה חיצוני גלובלי כתובת IP חיצונית גלובלית סכמת איזון עומסים: EXTERNAL_MANAGED	הבקשות מנותבות ל-GFE שהכי קרוב ללקוח באינטרנט.
מאזן עומסים קלאסי של אפליקציות (ALB)	מסלול פרימיום	כלל העברה חיצוני גלובלי כתובת IP חיצונית גלובלית סכמת איזון עומסים: EXTERNAL ^1	הבקשות מנותבות ל-GFE שהכי קרוב ללקוח באינטרנט.
	מסלול רגיל	כלל העברה חיצוני אזורי כתובת IP חיצונית אזורית סכמת איזון עומסים: EXTERNAL^1	בקשות שמנותבות ל-GFE באזור של מאזן העומסים.
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	מסלול פרימיום או מסלול רגיל	כלל העברה חיצוני אזורי כתובת IP חיצונית אזורית סכמת איזון עומסים: EXTERNAL_MANAGED	הבקשות מגיעות ל Google Cloud PoP הקרובה ביותר ללקוח. הבקשות מנותבות דרך רשת הליבה (backbone) של Google Cloudעד שהן מגיעות לשרתי proxy של Envoy באותו אזור כמו מאזן העומסים.

^‫1 אפשר לצרף שירותי בק-אנד של EXTERNAL_MANAGED לכללי העברה של EXTERNAL. עם זאת, אי אפשר לצרף שירותי קצה עורפי של EXTERNAL לכללי העברה של EXTERNAL_MANAGED. כדי ליהנות מתכונות חדשות שזמינות רק ב-Global External Application Load Balancer, מומלץ להעביר את משאבי EXTERNAL הקיימים אל EXTERNAL_MANAGED באמצעות תהליך ההעברה שמתואר במאמר העברת משאבים ממאזן עומסים קלאסי של אפליקציות אל Global External Application Load Balancer.

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

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

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

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

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

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

אל תסתמכו על ה-proxy כדי לשמור על האותיות הרישיות בשמות של כותרות בקשות או כותרות תגובה. לדוגמה, כותרת התגובה Server: Apache/1.0 עשויה להופיע בלקוח כ-server: Apache/1.0.

הערה: כשמדובר בקבוצות של נקודות קצה ברשת האינטרנט (NEGs), הבקשות ממאזן העומסים מגיעות מטווחים שונים של כתובות IP, בהתאם לסוג ה-NEG (גלובלי או אזורי). מידע נוסף זמין במאמר בנושא אימות בקשות.

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

מצב מאזן העומסים	סוגים של שרתי proxy ליעד	כותרות שנוספו על ידי שרת proxy	כותרות מותאמות אישית נתמכות
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	‫Global HTTP,‏ Global HTTPS	ה-Proxies מגדירים את הכותרות של בקשות ותגובות HTTP באופן הבא: Via: 1.1 google (בקשות ותשובות) ‫X-Forwarded-Proto: [http | https] (בקשות בלבד) ‫X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (ראו כותרת X-Forwarded-For) (בקשות בלבד) שרתי ה-proxy גם מגדירים את הכותרת X-Cloud-Trace-Context אם היא עדיין לא קיימת.	מוגדר בשירות הקצה העורפי או בקטגוריית הקצה העורפי לא אפשרי עם Cloud CDN
מאזן עומסים קלאסי של אפליקציות (ALB)	‫Global HTTP,‏ Global HTTPS	ה-Proxies מגדירים את הכותרות של בקשות ותגובות HTTP באופן הבא: Via: 1.1 google (בקשות ותשובות) ‫X-Forwarded-Proto: [http | https] (בקשות בלבד) ‫X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (ראו כותרת X-Forwarded-For) (בקשות בלבד) הפרוקסי גם מגדיר את הכותרת X-Cloud-Trace-Context אם היא עדיין לא קיימת.	מוגדר בשירות הקצה העורפי או בקטגוריית הקצה העורפי
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	HTTP אזורי, HTTPS אזורי	‫X-Forwarded-Proto: [http | https] (בקשות בלבד) Via: 1.1 google (בקשות ותשובות) ‫X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (ראו כותרת X-Forwarded-For) (בקשות בלבד)	מוגדר במפת URL

הערה: בהתאם ל-RFC 2616 , הכותרות הבאות מסוג hop-by-hop לא מועברות על ידי שרת ה-proxy של היעד:Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding ו-Upgrade.

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

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

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

• ב-Application Load Balancer הקלאסי, כותרות הבקשה והתגובה מומרות לאותיות קטנות, אלא אם משתמשים ב-HTTP/1.1. ב-HTTP/1.1, הכותרות הן באותיות רישיות. האות הראשונה של מפתח הכותרת וכל אות שאחרי מקף (-) מופיעות באותיות רישיות כדי לשמור על תאימות ללקוחות HTTP/1.1. לדוגמה, user-agent משתנה ל-User-Agent ו-content-encoding משתנה ל-Content-Encoding.

• חלק מהכותרות אוחדו. אם יש כמה מופעים של אותו מפתח כותרת (לדוגמה, Via), מאזן העומסים משלב את הערכים שלהם לרשימה אחת של ערכים מופרדים בפסיקים עבור מפתח כותרת יחיד. רק הכותרות שהערכים שלהן יכולים להיות מיוצגים כרשימה מופרדת בפסיקים מאוחדות. כותרות אחרות, כמו Set-Cookie, אף פעם לא מתמזגות.

כותרת המארח

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

כותרת X-Forwarded-For

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

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

אם הבקשה הנכנסת לא כוללת כותרת X-Forwarded-For, הכותרת שמתקבלת היא:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

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

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

שימו לב: מאזן העומסים לא מאמת כתובות IP שמופיעות לפני <client-ip>,<load-balancer-ip> בכותרת הזו. יכול להיות שכתובות ה-IP שלמעלה יכללו תווים אחרים, כולל רווחים.

הסרת ערכים קיימים של כותרות באמצעות request header בהתאמה אישית

אפשר להסיר ערכים קיימים של כותרות באמצעות כותרות בקשה בהתאמה אישית בשירות הקצה העורפי. בדוגמה הבאה השתמשנו בדגל --custom-request-header כדי ליצור מחדש את הכותרת X-Forwarded-For באמצעות המשתנים client_ip_address ו-server_ip_address. ההגדרה הזו מחליפה את הכותרת הנכנסת X-Forwarded-For רק בכתובת ה-IP של הלקוח ושל מאזן העומסים.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

הערה: בגישה הזו, כל הערכים הקיימים של X-Forwarded-For מבוטלים מהבקשה. ‫Because Google Cloud לא מתעד ערכי כותרות, אי אפשר לשחזר את הערכים האלה. אם רוצים לשמור את התוכן המקורי של הכותרת, אפשר לאחסן אותו בכותרת מותאמת אישית נפרדת.

איך תוכנת reverse proxy של ה-backend עשויה לשנות את הכותרת X-Forwarded-For

אם בשרתי הקצה העורפיים של מאזן העומסים פועלת תוכנת פרוקסי הפוך של HTTP, יכול להיות שהתוכנה תצרף את אחת מכתובות ה-IP הבאות או את שתיהן לסוף הכותרת X-Forwarded-For:

1. כתובת ה-IP של GFE שהתחבר לבק-אנד. טווח ה-proxy של GFE מפורט במסמך כללי חומת האש.

2. כתובת ה-IP של מערכת ה-Backend עצמה.

כתוצאה מכך, מערכת במעלה הזרם עשויה לראות כותרת X-Forwarded-For במבנה הבא:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

תמיכה ב-Cloud Trace

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

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

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

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

מיפוי כתובות URL תומך בכמה תכונות מתקדמות לניהול תנועה, כמו ניהוג תנועה מבוסס-כותרות, פיצול תנועה מבוסס-משקל ושכפול בקשות. למידע נוסף, קראו את המאמרים הבאים:

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

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

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

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

אישורי SSL

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

• ‫Google Cloud מספק שתי שיטות הגדרה להקצאת מפתחות פרטיים ואישורי SSL ל-proxy יעד של HTTPS: אישורי SSL של Compute Engine ו-Certificate Manager. תיאור של כל הגדרה זמין במאמר שיטות להגדרת אישורים בסקירה הכללית על אישורי SSL.

• ‫Google Cloud מספק שני סוגים של אישורים: בניהול עצמי ובניהול Google. תיאור של כל סוג מופיע במאמר סוגי אישורים בסקירה הכללית על אישורי SSL.

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

מדיניות SSL

מדיניות SSL מציינת את קבוצת התכונות של SSL שמאזני העומסים של Google Cloud משתמשים בהן כשמנהלים משא ומתן על SSL עם לקוחות.

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

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

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

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

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

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

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

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

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

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

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

קטגוריות קצה עורפי

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

בק-אנד

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

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

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

‫² IAP ו-Cloud CDN לא תואמים זה לזה. אי אפשר להפעיל את שניהם באותו שירות לקצה העורפי.

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

‫⁴ קבוצות אזוריות של נקודות קצה ברשת (NEGs) חייבות להשתמש בנקודות קצה מסוג GCE_VM_IP_PORT.

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

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

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

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

• קטגוריות של Cloud Storage לא משויכות לרשת VPC. הם יכולים להיות ממוקמים בכל פרויקט באותו ארגון.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

• ‫GCE_VM_IP_PORT NEG backends: צריך לאפשר תנועה למספרי היציאות של נקודות הקצה.

בטבלה הבאה מפורטים טווחי כתובות ה-IP של המקור שנדרשים לכללי חומת האש:

מצב מאזן העומסים	טווחים של כתובות IP של בדיקות תקינות	בקשת טווחי מקור
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי הקצה: 2600:2d00:1:b029::/64	המקור של תנועת הנתונים של GFE תלוי בסוג ה-Backend: קבוצות מופעים וקבוצות אזוריות של נקודות קצה ברשת (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 לתנועת IPv6 לשרתי הקצה העורפיים: 2600:2d00:1:1::/64 קבוצות NEG של קישוריות היברידית (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 קבוצות נקודות קצה ברשת האינטרנט (INTERNET_FQDN_PORT ו-INTERNET_IP_PORT): טווחי כתובות ה-IP שמופיעים ברשומת ה-TXT של ה-DNS‏ _cloud-eoips.googleusercontent.com. אפשר לחלץ את כתובות ה-IP של המקור עבור קצה עורפי של קבוצת נקודות קצה ברשת האינטרנט (NEG) באמצעות פקודת הדוגמה הבאה במערכת Linux: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2 ‫NEGs בלי שרת (serverless) ו-backend buckets: רשת הייצור של Google מטפלת בניתוב חבילות
מאזן עומסים קלאסי של אפליקציות (ALB)	לגבי בדיקות תקינות של IPv4 לשרתי קצה עורפיים: 35.191.0.0/16	המקור של תנועת הנתונים של GFE תלוי בסוג ה-Backend: קבוצות מופעים, קבוצות נקודות קצה ברשת (NEG) אזוריות (GCE_VM_IP_PORT) וקבוצות נקודות קצה ברשת (NEG) לקישוריות היברידית (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 קבוצות נקודות קצה ברשת האינטרנט (INTERNET_FQDN_PORT ו-INTERNET_IP_PORT): טווחי כתובות ה-IP שמופיעים ברשומת ה-TXT של ה-DNS‏ _cloud-eoips.googleusercontent.com. אפשר לחלץ את כתובות ה-IP של המקור עבור קצה עורפי של קבוצת נקודות קצה ברשת האינטרנט (NEG) באמצעות פקודת הדוגמה הבאה במערכת Linux: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2 קבוצות של נקודות קצה ברשת בלי שרת (serverless) ודלי אחסון של קצה עורפי: ניתוב החבילות מתבצע ברשת הייצור של Google.
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	לגבי בדיקות תקינות של IPv4 לשרתי קצה עורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי הקצה העורפיים: 2600:2d00:1:b029::/64 אין צורך לאפשר תעבורה מטווחים של בדיקות תקינות של Google עבור קבוצות NEG היברידיות. עם זאת, אם אתם משתמשים בשילוב של NEGs היברידיים ואזוריים בשירות קצה עורפי יחיד, אתם צריכים לאפשר תנועה מטווחים של בדיקות תקינות של Google עבור ה-NEGs האזוריים.	תת-הרשת של שרת ה-proxy בלבד שהגדרתם. אם אתם משתמשים בתת-רשת של שרת proxy בלבד עם תמיכה כפולה (dual-stack) כדי להעביר תעבורת נתונים של IPv6 דרך proxy, כלל חומת האש צריך להגדיר באופן מפורש את טווח המקור של IPv6 כדי להבטיח שתעבורת הנתונים תגיע לשרתים העורפיים. לדוגמה, באמצעות --source-ranges ::/0 או טווח IPv6 ספציפי של רשת המשנה של ה-proxy בלבד (תצוגה מקדימה).

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

ממשק קצה גלובלי

הערה: ממשק קצה גלובלי שונה מממשק קצה של Google‏ (GFE). ממשק הקצה של Google‏ (GFE) הוא שרת proxy הפוך שמסיים חיבורי TCP, ואילו ממשק קצה גלובלי הוא פתרון שעוזר לספק, להרחיב ולאבטח את האפליקציות שפונות לאינטרנט. ‫ממשק קצה גלובלי (GFE) Enterprise מרכז את התמחור של מוצרי רשת שונים Google Cloud לרמת תמחור אחת.

התכונה Global Front End, שזמינה בגרסת Preview, משלבת בין מאזני עומסים גלובליים חיצוניים של אפליקציות, Google Cloud Armor,‏ Cloud CDN ו-Service Extensions לפתרון אחד שיעזור לכם לספק, להרחיב ולאבטח את האפליקציות שפונות לאינטרנט. אפשר להפעיל את רמת החיוב ממשק קצה גלובלי (GFE) Enterprise בפרויקט Google Cloud. ב-ממשק קצה גלובלי (GFE) Enterprise, התמחור של המוצרים שצוינו למעלה מאוחד בתוכנית תמחור אחת. מידע נוסף על הפעלת רמת החיוב ממשק קצה גלובלי (GFE) Enterprise בפרויקט זמין במאמר הפעלה וניהול של ממשק קצה גלובלי (GFE) Enterprise בפרויקטGoogle Cloud .

כשמפעילים את ממשק קצה גלובלי (GFE) Enterprise בפרויקט, כל מאזני העומסים של אפליקציות חיצוניות גלובליות בפרויקט מקבלים גישה לתכונות ספציפיות של Cloud Armor Enterprise.

בארכיטקטורה של ממשק קצה גלובלי, מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) מחלק את תעבורת ה-HTTP וה-HTTPS בין מופעי הבק-אנד של אפליקציה בכמה אזורים. ‫Cloud CDN מאיץ אפליקציות שפונות לאינטרנט באמצעות נקודות נוכחות (PoP) של Google בקצה הרשת, ופועל עם מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) כדי להעביר תוכן למשתמשים. כללי מדיניות האבטחה של Google Cloud Armor מגנים על המכונות העורפיות. המדיניות הזו מספקת סינון ברמה 7 על ידי בדיקת בקשות נכנסות למתקפות נפוצות באינטרנט או למאפיינים אחרים ברמה 7, וחסימת התנועה לפני שהיא מגיעה לשירותי הקצה העורפי עם איזון העומסים. Service Extensions מאפשרים לכם להתאים אישית את עיבוד הנתונים של מאזן העומסים כך שיתאים לדרישות הספציפיות של האפליקציה או העסק שלכם.

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

תמיכה ב-GKE

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

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

  כשמפעילים את Cloud CDN עבור שרתי קצה עורפיים שמנוהלים על ידי GKE Gateway, הגדרת השמירה במטמון מתבצעת באמצעות מסנני GKE GCPHTTPFilter שמצורפים למשאבי HTTPRoute. מידע על הגדרת שמירה במטמון זמין במאמר הגדרת Cloud CDN ל-Gateway.

• ‫Ingress חיצוני שנוצר באמצעות בקר GKE Ingress הוא תמיד מאזן עומסים קלאסי של אפליקציות. בקר GKE Ingress מעדיף להשתמש בקצה עורפי של NEG אזורי GCE_VM_IP_PORT, אבל הוא תומך גם בקצה עורפי של קבוצת מופעים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • במאזני עומסים גלובליים חיצוניים של אפליקציות, אי אפשר להפנות לשירות לקצה העורפי חוצה פרויקטים אם לשירות לקצה העורפי יש שרתי backend של NEG בלי שרת עם App Engine.

  • במאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) אי אפשר להפנות לשירות קצה עורפי חוצה-פרויקטים אם לשירות הקצה העורפי יש קצוות עורפיים של NEG אזוריים באינטרנט.
• הפניה לשירותים בפרויקטים שונים לא נתמכת ב-Application Load Balancer הקלאסי.
• ‫Google Cloud לא מבדיל בין משאבים (לדוגמה, שירותי קצה עורפי) שמשתמשים באותו שם בכמה פרויקטים. לכן, כשמשתמשים בהפניה לשירותים בין פרויקטים, מומלץ להשתמש בשמות ייחודיים של שירותי קצה עורפיים בפרויקטים שונים בארגון.
• אם מופיעה שגיאה כמו "Cross-project references for this resource are not allowed", צריך לוודא שיש לכם הרשאה להשתמש במשאב. אדמין בפרויקט שבבעלותו המשאב צריך להעניק לכם את התפקיד 'משתמש בשירותי איזון עומסים של Compute' (roles/compute.loadBalancerServiceUser). אפשר להעניק את התפקיד הזה ברמת הפרויקט או ברמת המשאב. לדוגמה, אפשר לעיין במאמר הענקת הרשאות לאדמין של מאזן עומסים של Compute לשימוש בשירות לקצה העורפי או בקטגוריית קצה עורפי.

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

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

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

‫

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

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

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

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

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

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

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

‫ ‫

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

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

זמינות גבוהה ומעבר לגיבוי (failover)

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

בטבלה הבאה מתואר אופן הפעולה של המעבר לגיבוי.

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

תמיכה ב-HTTP/2

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

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

‫HTTP/2 over TLS

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

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

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

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

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

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

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

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

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

מגבלות של HTTP/2

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

תמיכה ב-HTTP/3

‫HTTP/3 הוא פרוטוקול אינטרנט מהדור הבא. הוא מבוסס על IETF QUIC, פרוטוקול שפותח מהפרוטוקול המקורי Google QUIC. יש תמיכה ב-HTTP/3 בין מאזן העומסים החיצוני של האפליקציות, Cloud CDN והלקוחות.

התמיכה ב-Google QUIC (שנקרא גם gQUIC) הוסרה באפריל 2023 לטובת HTTP/3 over IETF QUIC, שהוא גם תקן IETF וגם הוכח כי הוא עדיף על gQUIC.

פרטים נוספים:

• ‫IETF QUIC הוא פרוטוקול של שכבת התעבורה שמספק בקרת עומס ואמינות דומים ל-TCP, משתמש ב-TLS 1.3 לאבטחה ומשפר את הביצועים.
• ‫HTTP/3 היא שכבת אפליקציה שמבוססת על IETF QUIC, והיא מסתמכת על QUIC לטיפול ב-multiplexing, בבקרת עומס, בזיהוי אובדן ובשידור חוזר.
• פרוטוקול HTTP/3 מאפשר הפעלה מהירה יותר של חיבור לקוח, מבטל חסימה של ראש התור בזרמים מרובי-ערוצים ותומך בהעברת חיבור כשכתובת ה-IP של הלקוח משתנה.
• יש תמיכה ב-HTTP/3 בחיבורים בין לקוחות לבין מאזן העומסים, אבל לא בחיבורים בין מאזן העומסים לבין הקצה העורפי שלו.
• חיבורי HTTP/3 משתמשים באלגוריתם BBR לבקרת עומס.

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

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

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

איך מתנהל משא ומתן לגבי HTTP/3

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

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

התמיכה מפורסמת בכותרת התגובה של ה-HTTP‏ Alt-Svc. כשפרוטוקול HTTP/3 מופעל, התשובות ממאזן העומסים כוללות את ערך הכותרת alt-svc הבא:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

הערה: הכותרת Alt-Svc מפרסמת כמה גרסאות של HTTP/3 כדי לתמוך בטיוטות קודמות שמשמשות חלק מהלקוחות – לדוגמה, h3-29.

אם HTTP/3 הוגדר במפורש כ-DISABLE, התגובות לא כוללות כותרת תגובה של alt-svc.

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

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

אם החיבור חוזר ל-HTTPS או ל-HTTP/2, אנחנו לא מחשיבים את זה ככשל במאזן העומסים.

לפני שמפעילים HTTP/3, חשוב לוודא שההתנהגויות שתוארו קודם מקובלות בעומסי העבודה שלכם.

הגדרת HTTP/3

האפשרויות NONE (ברירת המחדל) ו-ENABLE מפעילות תמיכה ב-HTTP/3 עבור איזון העומסים.

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

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

ערך לשינוי מהיר	התנהגות
NONE	התמיכה ב-HTTP/3 מוצגת ללקוחות.
ENABLE	התמיכה ב-HTTP/3 מוצגת ללקוחות.
DISABLE	היא משביתה באופן מפורש את הפרסום ב-HTTP/3 וב-Google QUIC ללקוחות.

כדי להפעיל (או להשבית) באופן מפורש את HTTP/3, פועלים לפי השלבים הבאים.

מסוף: HTTPS

הערה: בשלב הזה אי אפשר להגדיר את המשא ומתן של HTTP/3 בדף של שרתי proxy ליעד, וצריך לערוך את ההגדרה של מאזן העומסים כדי להגדיר אותו.

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

   כניסה לדף Load balancing

2. בוחרים את מאזן העומסים שרוצים לערוך.

3. לוחצים על Frontend configuration.

4. בוחרים את כתובת ה-IP והיציאה של קצה קדמי שרוצים לערוך. כדי לערוך הגדרת HTTP/3, הפרוטוקול חייב להיות HTTPS.

הפעלת HTTP/3

1. בוחרים בתפריט QUIC negotiation.
2. כדי להפעיל במפורש HTTP/3 עבור קצה קדמי זה, בוחרים באפשרות Enabled (מופעל).
3. אם יש לכם כמה כללי frontend שמייצגים IPv4 ו-IPv6, הקפידו להפעיל HTTP/3 בכל כלל.

השבתת HTTP/3

1. בוחרים בתפריט QUIC negotiation.
2. כדי להשבית במפורש את HTTP/3 בחזית הזו, בוחרים באפשרות מושבת.
3. אם יש לכם כמה כללי frontend שמייצגים IPv4 ו-IPv6, הקפידו להשבית את HTTP/3 לכל כלל.

‫gcloud: HTTPS

לפני שמריצים את הפקודה הזו, צריך ליצור משאב של אישור SSL לכל אישור.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

מחליפים את QUIC_SETTING באחד מהערכים הבאים:

• ‫NONE (ברירת מחדל): מאפשר ל-Google לקבוע מתי לפרסם את HTTP/3.

  כשבוחרים באפשרות NONE, פרוטוקול HTTP/3 מפורסם ללקוחות, אבל פרוטוקול Google QUIC לא מפורסם. במסוף Google Cloud , האפשרות הזו נקראת אוטומטי (ברירת מחדל).

• ‫ENABLE: מפרסם ללקוחות את פרוטוקול HTTP/3.

• ‫DISABLE: לא מפרסם ללקוחות את HTTP/3.

‫API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

מחליפים את QUIC_SETTING באחד מהערכים הבאים:

• ‫NONE (ברירת מחדל): מאפשר ל-Google לקבוע מתי מתבצעת פרסום של HTTP/3.

  כשבוחרים באפשרות NONE, פרוטוקול HTTP/3 מפורסם ללקוחות, אבל פרוטוקול Google QUIC לא מפורסם. במסוף Google Cloud , האפשרות הזו נקראת אוטומטי (ברירת מחדל).

• ‫ENABLE: מפרסם ללקוחות את HTTP/3 ו-Google QUIC.

• ‫DISABLE: לא מפרסם ללקוחות את HTTP/3 או את Google QUIC.

תמיכה ב-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. הקצה העורפי שולח תגובת WebSocket‏ Upgrade. התשובה הזו כוללת תשובה 101 Switching Protocols עם כותרות Connection: Upgrade ו-Upgrade: websocket, ועוד כותרות תשובה שקשורות ל-WebSocket.
3. מאזן העומסים מעביר תנועה דו-כיוונית למשך החיבור הנוכחי.

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

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

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

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

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

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

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

תמיכה ב-gRPC

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

אם אתם רוצים להגדיר מאזן עומסים של אפליקציות באמצעות HTTP/2 עם Google Kubernetes Engine Ingress או באמצעות gRPC ו-HTTP/2 עם Ingress, תוכלו לעיין במאמר HTTP/2 לאיזון עומסים עם Ingress.

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

מידע על פתרון בעיות ב-HTTP/2 זמין במאמר פתרון בעיות ב-HTTP/2 בשרתי הקצה העורפי.

מידע על מגבלות HTTP/2 זמין במאמר מגבלות HTTP/2.

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

תמיכה ב-TLS

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

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

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

תמיכה ב-TLS בו-זמני (mTLS)

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

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

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

תמיכה ב-TLS 1.3 early data

הערה: נתונים מוקדמים של TLS 1.3 או 0-RTT נתמכים רק לחידוש של סשנים קודמים בין הלקוחות לבין Cloud CDN או מאזן העומסים. ‫Cloud CDN או מאזן עומסים לא יכולים להשתמש ב-TLS early data כשמעבירים בקשות לשרתי המקור.

נתונים מוקדמים של TLS 1.3 נתמכים בשרת ה-proxy של HTTPS היעד של מאזני העומסים החיצוניים הבאים של אפליקציות, גם עבור HTTPS על TCP ‏ (HTTP/1.1,‏ HTTP/2) וגם עבור HTTP/3 על QUIC:

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

גרסה TLS 1.3 הוגדרה ב-RFC 8446 ומציגה את המושג early data (נתונים מוקדמים), שנקרא גם נתונים עם זמן הלוך ושוב אפס (0-RTT). הנתונים האלה יכולים לשפר את ביצועי האפליקציה בחיבורים שהופעלו מחדש ב-30 עד 50%.

עם TLS 1.2, נדרשים שני תהליכי הלוך ושוב לפני שאפשר לשדר נתונים בצורה מאובטחת. ב-TLS 1.3, הזמן הזה מצטמצם לסיבוב אחד (1-RTT) לחיבורים חדשים, וכך הלקוחות יכולים לשלוח נתוני אפליקציה מיד אחרי התגובה הראשונה של השרת. בנוסף, ב-TLS 1.3 מוצג המושג של נתונים מוקדמים להפעלת סשנים מחדש, שמאפשר ללקוחות לשלוח נתוני אפליקציה עם ClientHelloההתחלה, וכך לקצר את זמן הלוך ושוב האפקטיבי לאפס (0-RTT). נתונים מוקדמים של TLS 1.3 מאפשרים לשרת הקצה העורפי להתחיל לעבד את נתוני הלקוח לפני שתהליך הלחיצת יד עם הלקוח מסתיים, וכך מצמצמים את זמן האחזור. עם זאת, צריך לנקוט אמצעי זהירות כדי לצמצם את הסיכון להפעלת התקפה חוזרת.

מכיוון שנתונים מוקדמים נשלחים לפני השלמת הלחיצת יד, תוקף יכול לנסות לתפוס בקשות ולהפעיל אותן מחדש. כדי לצמצם את הסיכון הזה, שרת הקצה העורפי חייב לשלוט בקפידה בשימוש בחבילת הגלישה המוקדמת, ולהגביל את השימוש בה לבקשות אידמפוטנטיות. שיטות HTTP שמיועדות להיות אידמפוטנטיות אבל עשויות להפעיל שינויים לא אידמפוטנטיים – כמו בקשת GET שמשנה מסד נתונים – לא יכולות לקבל נתונים מוקדמים. במקרים כאלה, שרת הקצה העורפי צריך לדחות בקשות עם הכותרת Early-Data: 1 של HTTP על ידי החזרת קוד הסטטוס 425 Too Early של HTTP.

בבקשות עם נתונים מוקדמים, הכותרת HTTP Early-Data מוגדרת לערך 1, שמציין לשרת העורפי שהבקשה הועברה בנתונים מוקדמים של TLS. הוא גם מציין שהלקוח מבין את קוד הסטטוס של HTTP 425 Too Early.

מצבי נתונים מוקדמים של TLS ‏ (0-RTT)

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

• ‫STRICT. הפעולה הזו מפעילה TLS 1.3 early data לבקשות עם שיטות HTTP בטוחות (GET,‏ HEAD,‏ OPTIONS,‏ TRACE) ולבקשות HTTP שאין להן פרמטרים של שאילתות. בקשות ששולחות נתונים מוקדמים שמכילים שיטות HTTP לא אידמפוטנטיות (כמו POST או PUT) או פרמטרים של שאילתות נדחות עם קוד סטטוס HTTP 425.

• ‫PERMISSIVE. הפעולה הזו מפעילה TLS 1.3 early data לבקשות עם שיטות HTTP בטוחות (GET, ‏ HEAD, ‏ OPTIONS, ‏ TRACE). במצב הזה, בקשות שכוללות פרמטרים של שאילתה לא נדחות. בעל האפליקציה צריך לוודא שהשימוש בנתונים מוקדמים בטוח לכל נתיב בקשה, במיוחד לנקודות קצה שבהן הפעלה חוזרת של בקשה עלולה לגרום לתופעות לוואי לא רצויות, כמו רישום ביומן או עדכונים במסד הנתונים שמופעלים על ידי בקשות GET.

• ‫DISABLED. לא מתבצע פרסום של TLS 1.3 early data, וכל ניסיון (לא תקין) לשלוח early data נדחה. אם האפליקציות שלכם לא מצוידות ביכולת לטפל בבקשות לנתונים מוקדמים בצורה בטוחה, אתם צריכים להשבית את הנתונים המוקדמים. כברירת מחדל, התכונה TLS 1.3 early data מושבתת.

• ‫UNRESTRICTED (לא מומלץ לרוב עומסי העבודה). ההגדרה הזו מאפשרת שימוש ב-TLS 1.3 Early Data לבקשות עם כל שיטת HTTP, כולל שיטות לא אידמפוטנטיות, כמו POST. במצב הזה לא נאכפות הגבלות אחרות. המצב הזה יכול להיות שימושי בתרחישי שימוש ב-gRPC. עם זאת, אנחנו לא ממליצים על השיטה הזו אלא אם בדקתם את מצב האבטחה שלכם וצמצמתם את הסיכון למתקפות שידור חוזר באמצעות מנגנונים אחרים.

הגדרת נתונים מוקדמים של TLS

כדי להפעיל או להשבית באופן מפורש את TLS early data:

המסוף

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

   כניסה לדף Load balancing

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

3. לוחצים על עריכה.

4. לוחצים על Frontend configuration.

5. בוחרים את כתובת ה-IP והיציאה של קצה קדמי שרוצים לערוך. כדי להפעיל את הנתונים המוקדמים של TLS, הפרוטוקול חייב להיות HTTPS.

6. ברשימה Early data (0-RTT) (נתונים מוקדמים (0-RTT)), בוחרים מצב נתונים מוקדמים של TLS.

7. לוחצים על סיום.

8. כדי לעדכן את מאזן העומסים, לוחצים על עדכון.

gcloud

1. הגדרת מצב TLS early data בשרת ה-proxy של HTTPS ביעד של מאזן עומסים של אפליקציות.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫TARGET_HTTPS_PROXY: שרת ה-proxy ל-HTTPS של מאזן העומסים
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED, or UNRESTRICTED

API

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

מחליפים את מה שכתוב בשדות הבאים:

• ‫TARGET_HTTPS_PROXY: שרת ה-proxy ל-HTTPS של מאזן העומסים
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED, or UNRESTRICTED
• ‫FINGERPRINT: מחרוזת בקידוד Base64. כדי לתקן את פרוקסי ה-HTTPS של היעד, צריך לספק טביעת אצבע עדכנית. אחרת, הבקשה תיכשל ויוחזר קוד הסטטוס 412 Precondition Failed של HTTP.

אחרי שמגדירים את TLS early data, אפשר לשלוח בקשות מלקוח HTTP שתומך ב-TLS early data. אפשר לראות שהחביון נמוך יותר בבקשות שהופעלו מחדש.

אם לקוח שלא תואם ל-RFC שולח בקשה עם שיטה לא אידמפוטנטית או עם פרמטרים של שאילתה, הבקשה נדחית. מופיע קוד סטטוס HTTP 425 Early ביומני מאזן העומסים ותגובת ה-HTTP הבאה:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

שער Google Tag למפרסמים

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

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

ההגדרה והניהול של שער Google Tag מתבצעים מחוץ למסוף Google Cloud . צריך להגדיר את התכונה הזו באמצעות הממשק של Google Tag Manager.

• בדף Load balancer details במסוף Google Cloud מוצג אינדיקטור ויזואלי לקריאה בלבד שמראה שהופעל שער Google Tag.
• אי אפשר לערוך או למחוק את ההגדרה של שער Google Tag מהמסוףGoogle Cloud .

הוראות מלאות להגדרת שער Google Tag למפרסמים זמינות במאמר איך מגדירים שער Google Tag למפרסמים.

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

מידע על פתרון בעיות בשערי Google Tag זמין במאמר בנושא פתרון בעיות בהחדרת הקוד של שער Google Tag.

אם נתקלתם בבעיות במהלך ההגדרה שלא מוסברות במסמכי התיעוד, תוכלו לפנות לתמיכה של Google Ads.

מגבלות

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

• מאזני עומסים של HTTPS תומכים רק בתווים קטנים בדומיינים במאפיין של שם נפוץ (CN) או במאפיין של שם חלופי של בעלים (subject) (SAN) באישור. אישורים עם אותיות רישיות בדומיינים מוחזרים רק אם הם מוגדרים כאישור הראשי בשרת ה-proxy של היעד.

• מאזני עומסים מסוג HTTPS לא משתמשים בתוסף Server Name Indication ‏ (SNI) כשהם מתחברים לבק-אנד, למעט מאזני עומסים עם בק-אנד מסוג Internet NEG. מידע נוסף זמין במאמר בנושא הצפנה ממאזן העומסים אל קצה העורף.

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

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

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

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

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

• באמצעות Cloud CDN אפשר לבקש ביטול של שמירה במטמון כדי לאלץ את המערכת להתעלם מאובייקט או מקבוצת אובייקטים במטמון. כשמשתמשים במאזן עומסים חיצוני גלובלי של אפליקציות עם הפניה לשירות בין פרויקטים ב-VPC משותף, כברירת מחדל, לאדמינים של פרויקטים של שירותים אין את ההרשאות הנדרשות כדי לבקש ביטול של מטמון. הסיבה לכך היא שביטול התוקף של מטמון מוגדר בפרויקט הקצה הקדמי (כלומר, הפרויקט שכולל את כלל ההעברה, שרת proxy לחלוקת העומס ומפת URL של מאזן העומסים). לכן, רק ישויות מורשות שיש להן תפקידי IAM להגדרת משאבים שקשורים למאזן העומסים בפרויקטים של קצה קדמי (לדוגמה, התפקיד 'אדמין של רשת Compute') יכולים להנפיק ביטולים של מטמון. אדמינים של שירותים, ששולטים בהקצאת שירותי הקצה העורפי בפרויקט נפרד, צריכים לעבוד עם האדמין של מאזן העומסים בפרויקט הקצה הקדמי כדי להוציא פסילה של מטמון לשירותים שלהם בפרויקט.

• כשמשתמשים במאזן עומסים קלאסי של אפליקציות (ALB), מאזן העומסים מוסיף באופן אוטומטי כותרת HTTP ‏Content-Length: 0 לבקשות DELETE דרך HTTP/1.1 ו-HTTP/2, גם אם הבקשה המקורית לא ציינה אורך תוכן. ההתנהגות הזו עלולה לגרום למדיניות האבטחה של Cloud Armor לחסום את הבקשות האלה אם המדיניות מוגדרת לסנן או לדחות בקשות שמכילות כותרת של אורך תוכן. הבעיה הזו ספציפית למאזן עומסים של אפליקציות (ALB) קלאסי, ולא מתרחשת בבקשות של GET או HEAD.

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

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

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

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

• אם אתם משתמשים קיימים ב-Classic Application Load Balancer, הקפידו לעיין בסקירה כללית של המעבר כשאתם מתכננים פריסה חדשה באמצעות Global External Application Load Balancer.

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

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

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

• מידע על הצגת אתרים מופיע במאמר הצגת אתרים.

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

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

• כדי ללמוד איך להשתמש ב-Certificate Manager כדי להקצות ולנהל אישורי SSL, אפשר לעיין בסקירה הכללית על Certificate Manager.

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

• רק במאזני עומסים חיצוניים אזוריים של אפליקציות, אפשר לנסות להשתמש בApigee Shadow API Discovery כדי למצוא ממשקי API של צללים (שנקראים גם ממשקי API לא מתועדים) בתשתית הקיימת שלכם ב-Google Cloud . לפני שמפעילים את Shadow API Discovery, חשוב לקרוא את המגבלות שקשורות אליו.