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

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

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

מצבי פעולה

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

ארכיטקטורה

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

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

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

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

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

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

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

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

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

אזורי

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

‫

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

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

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

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

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

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

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

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

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

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

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

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

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

שיוך רשת VPC

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

רשת ה-VPC של כלל ההעברה היא הרשת שבה נוצרה רשת המשנה של שרתי ה-proxy בלבד. מציינים את הרשת כשיוצרים את כלל ההעברה. בהתאם לשימוש בכתובת IPv4 או בטווח כתובות IPv6, תמיד יש רשת VPC מפורשת או משתמעת שמשויכת לכלל ההעברה. כתובות IPv4 חיצוניות אזוריות תמיד קיימות מחוץ לרשתות VPC. עם זאת, כשיוצרים את כלל ההעברה, צריך לציין את רשת ה-VPC שבה נוצרה רשת המשנה proxy-only. לכן, לכלל ההעברה יש שיוך מפורש לרשת. טווחי כתובות 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 כדי לקבוע איך לנתב את התנועה לקצוות העורפיים.

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

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

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

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

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

כותרת המארח

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

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

איך תוכנת שרת proxy הפוך בקצה העורפי עשויה לשנות את הכותרת X-Forwarded-For

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

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

2. כתובת ה-IP של מערכת הקצה העורפי עצמה.

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

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

תמיכה ב-Cloud Trace

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

מפות URL

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

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

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

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

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

אישורי SSL

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

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

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

מדיניות SSL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בק-אנדים

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

• קבוצות של מכונות
• קבוצות NEG אזוריות
• קבוצות NEG באינטרנט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

• ל-NEG מסוג GCE_VM_IP_PORT: מאפשרים תנועה למספרי היציאות של נקודות הקצה.

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

תמיכה ב-GKE

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

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

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

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

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

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

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

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

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

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

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

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

‫ ‫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫ ‫

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

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

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

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

‫ ‫

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

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

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

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

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

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

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

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

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

שיטות ליתירות כשל

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

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

תמיכה ב-HTTP/2

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

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

‫HTTP/2 over TLS

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

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

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

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

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

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

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

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

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

מגבלות של HTTP/2

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

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

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

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

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

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

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

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

תמיכה ב-WebSocket

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

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

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

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

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

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

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

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

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

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

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

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

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

תמיכה ב-gRPC

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

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

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

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

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

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

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

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

תמיכה ב-TLS

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

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

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

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

‫Mutual 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 כשהם מעבירים בקשות לשרתי המקור.

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

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

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

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

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

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

מצבי TLS early data ‏ (0-RTT)

אפשר להגדיר נתונים מוקדמים של TLS באמצעות אחד מהמצבים הבאים במשאב של שרת ה-proxy ל-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, וכל ניסיון (לא חוקי) לשלוח נתונים מוקדמים נדחה. אם האפליקציות שלכם לא יכולות לטפל בבקשות לנתונים מוקדמים בצורה בטוחה, אתם צריכים להשבית את הנתונים המוקדמים. ‫TLS 1.3 Early Data מושבת כברירת מחדל.

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

הגדרת TLS early data

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

המסוף

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

   כניסה לדף Load balancing

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

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

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

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

6. ברשימה Early data (0-RTT)‎, בוחרים מצב TLS early data.

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

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

gcloud

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

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

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

   • ‫TARGET_HTTPS_PROXY: שרת ה-proxy ל-HTTPS של מאזן העומסים (LB)
   • TLS_EARLY_DATA_MODE: ‏ STRICT,‏ PERMISSIVE,‏ DISABLED או 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 של מאזן העומסים (LB)
• ‫TLS_EARLY_DATA_MODE: ‏ STRICT,‏ PERMISSIVE,‏ DISABLED או UNRESTRICTED
• ‫FINGERPRINT: מחרוזת בקידוד Base64. כדי לתקן את שרת ה-proxy ל-HTTPS, צריך לספק טביעת אצבע עדכנית. אחרת, הבקשה תיכשל ויופיע קוד הסטטוס 412 Precondition Failed של HTTP.

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

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

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

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

• בדף פרטי מאזן העומסים במסוף Google Cloud , מופיע אינדיקטור חזותי לקריאה בלבד שמראה ש-Google Tag Gateway מופעל.
• אי אפשר לערוך או למחוק את ההגדרה של שער Google Tag מהמסוף שלGoogle Cloud .

איך מגדירים שער Google Tag למפרסמים

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

איך פותרים בעיות בהחדרת הקוד של שער Google Tag

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

מגבלות

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

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

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

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

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

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

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

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