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

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

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

מצבי פעולה

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

ארכיטקטורה

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

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

רשת המשנה של ה-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

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

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

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

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

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

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

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

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

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

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

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

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

• חלק מהכותרות אוחדו. אם יש כמה מופעים של אותו מפתח כותרת (לדוגמה, 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>

הסרת ערכים קיימים של כותרות באמצעות 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}

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

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

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

אישורי SSL

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

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

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

מדיניות SSL

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

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

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

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

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

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

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

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

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

• ‫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).

בק-אנד

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

• קבוצות של מכונות
• קבוצות אזוריות של נקודות קצה ברשת (NEGs)
• קבוצות NEG באינטרנט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמיכה ב-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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫Cloud de Confiance לא מבדיל בין משאבים (לדוגמה, שירותי קצה עורפי) שמשתמשים באותו שם בכמה פרויקטים. לכן, כשמשתמשים בהפניה לשירותים בין פרויקטים, מומלץ להשתמש בשמות ייחודיים של שירותי קצה עורפיים בפרויקטים שונים בארגון.
• אם מופיעה שגיאה כמו "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) לאדמינים של איזון עומסים בפרויקט שירות א' שרוצים להפנות לשירות הקצה העורפי בפרויקט שירות ב'.

‫

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

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

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

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

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

‫ ‫

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

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

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

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

תמיכה ב-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 לCloud de Confiance מאזן עומסים הוא חסר משמעות, כי מאזן העומסים לא יוזם סטרימים ללקוח.

במקרים שבהם מאזן העומסים משתמש ב-HTTP/2 כדי לתקשר עם שרת שפועל במכונה וירטואלית, מאזן העומסים מתחשב בערך SETTINGS_MAX_CONCURRENT_STREAMS שמוגדר בשרת, עד לערך מקסימלי של 100. בכיוון הבקשה (מאזן העומסיםCloud de Confiance ← שרת 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 לא מוצגים ב-Cloud de Confiance API או במסוף Cloud de Confiance . אם נקודת הקצה של gRPC מחזירה שגיאה, קוד סטטוס של HTTP‏ 200 OK יופיע ביומני מאזן העומסים ובנתוני המעקב.

‫HTTP/2 over cleartext TCP

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

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

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

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

תמיכה ב-WebSocket

Cloud de Confiance מאזני עומסים מבוססי 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 וקוד הסטטוס מועבר ללקוח.

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

תמיכה ב-gRPC

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

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

כדי להשתמש ב-gRPC עם האפליקציות Cloud de Confiance שלכם, אתם צריכים להעביר בקשות באמצעות 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.

תמיכה ב-TLS

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

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

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

אחרי שמגדירים את 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 מתבצעים מחוץ למסוף Cloud de Confiance . צריך להגדיר את התכונה הזו באמצעות הממשק של Google Tag Manager.

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

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

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

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

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

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

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