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

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

מאזני עומסים, שרתי proxy של Envoy ולקוחות gRPC בלי שרת Proxy משתמשים בפרטי ההגדרה במשאב של שירות לקצה העורפי כדי לבצע את הפעולות הבאות:

  • תנועה ישירה לעורפי העורף הנכונים, שהם קבוצות של מופעים או קבוצות של נקודות קצה ברשת (NEGs).
  • חלוקת התנועה לפי מצב איזון, שהוא הגדרה לכל שרת קצה.
  • צריך לקבוע איזו בדיקת תקינות עוקבת אחרי התקינות של השרתים העורפיים.
  • מציינים העדפה לסשן.
  • בודקים אם שירותים אחרים מופעלים, כולל השירותים הבאים שזמינים רק למאזני עומסים מסוימים:
    • Cloud CDN
    • כללי מדיניות האבטחה של Google Cloud Armor
    • שרת proxy לאימות זהויות (IAP)
  • הגדרת שירותים לקצה העורפי (גלובליים ואזוריים) כשירות באפליקציות של App Hub.

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

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

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

טבלה: שירותים לקצה העורפי וסוגים נתמכים של קצה עורפי
מוצר מספר שירותי הקצה העורפי המקסימלי היקף השירות לקצה העורפי סוגי קצה עורפי נתמכים סכמת איזון עומסים
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) כמה סוגים עולמי כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר GCE_VM_IP_PORT סוגים של NEGs אזוריים1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • כל ה-NEGs מסוג Serverless: משאב אחד או יותר של App Engine,‏ Cloud Run או פונקציות Cloud Run
  • קבוצת נקודות קצה ברשת גלובלית לאינטרנט עבור קצה עורפי חיצוני
  • ‫NEGs של Private Service Connect:
    • ‫Google APIs: קבוצת נקודות קצה ברשת (NEG) אחת של Private Service Connect
    • שירותים מנוהלים: קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
EXTERNAL_MANAGED
מאזן עומסים קלאסי של אפליקציות (ALB) כמה סוגים בכל העולם3 כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל קצוות העורף של קבוצת המופעים: קצה עורף אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קצוות עורף של קבוצות מופעים מנוהלות ולא מנוהלות
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • כל ה-NEGs מסוג Serverless: משאב אחד או יותר של App Engine,‏ Cloud Run או פונקציות Cloud Run, או
  • קבוצת נקודות קצה ברשת גלובלית לאינטרנט עבור קצה עורפי חיצוני
 EXTERNAL4
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) כמה סוגים אזורי כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • קבוצת נקודות קצה ברשת (NEG) אחת בלי שרת (serverless) (ל-Cloud Run או לפונקציות Cloud Run דור שני בלבד)
  • ‫NEG יחיד של Private Service Connect
  • כל קבוצות ה-NEG האזוריות לאינטרנט עבור קצה עורפי חיצוני
 EXTERNAL_MANAGED
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים כמה סוגים עולמי כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • קבוצת נקודות קצה ברשת (NEG) אחת בלי שרת (serverless) (ל-Cloud Run או לפונקציות Cloud Run דור שני בלבד)
  • ‫NEGs של Private Service Connect:
    • ‫Google APIs: קבוצת נקודות קצה ברשת (NEG) אחת של Private Service Connect
    • שירותים מנוהלים: קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
INTERNAL_MANAGED
מאזן עומסים פנימי אזורי של אפליקציות (ALB) כמה סוגים אזורי כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • קבוצת נקודות קצה ברשת (NEG) אחת בלי שרת (serverless) (ל-Cloud Run או לפונקציות Cloud Run דור שני בלבד)
  • ‫NEG יחיד של Private Service Connect
  • כל קבוצות ה-NEG האזוריות לאינטרנט עבור קצה עורפי חיצוני
 INTERNAL_MANAGED
מאזן עומסי רשת גלובלי חיצוני בשרת proxy 1 בכל העולם3 השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר GCE_VM_IP_PORT סוגים של NEGs אזוריים1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
  • ‫NEGs של Private Service Connect:
    • ‫Google APIs: קבוצת נקודות קצה ברשת (NEG) אחת של Private Service Connect
    • שירותים מנוהלים: קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
EXTERNAL_MANAGED
מאזן עומסי רשת קלאסי בשרת proxy 1 בכל העולם3 השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל קצוות העורף של קבוצת המופעים: קצה עורף אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קצוות עורף של קבוצות מופעים מנוהלות ולא מנוהלות
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT 2
 חיצוני
מאזן עומסי רשת אזורי חיצוני בשרת proxy 1 אזורי השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT
  • כל קבוצות ה-NEG האזוריות לאינטרנט עבור קצה עורפי חיצוני
  • ‫NEG יחיד של Private Service Connect
 EXTERNAL_MANAGED
מאזן עומסי רשת פנימי אזורי בשרת proxy 1 אזורי השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT
  • כל קבוצות ה-NEG האזוריות לאינטרנט עבור קצה עורפי חיצוני
  • ‫NEG יחיד של Private Service Connect
 INTERNAL_MANAGED
מאזן עומסי רשת פנימי בשרת proxy בין אזורים כמה סוגים עולמי השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל ה-backends של קבוצת המופעים: backend אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קבוצת מופעים מנוהלת ולא מנוהלת 1
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP_PORT 1
  • כל ה-NEGs של קישוריות היברידית: אחד או יותר NON_GCP_PRIVATE_IP_PORT NEGs מסוג
  • שילוב של NEGs אזוריים והיברידיים: GCE_VM_IP_PORT ו-NEGs מסוג NON_GCP_PRIVATE_IP_PORT
  • ‫NEGs של Private Service Connect:
    • ‫Google APIs: קבוצת נקודות קצה ברשת (NEG) אחת של Private Service Connect
    • שירותים מנוהלים: קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect
INTERNAL_MANAGED
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי 1 אזורי השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל קצוות העורף של קבוצת המופעים: קצה עורף אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קצוות עורף של קבוצות מופעים מנוהלות ולא מנוהלות
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP
 חיצוני
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי 1 אזורי, אבל אפשר להגדיר אותו כך שיהיה נגיש באופן גלובלי השירות לקצה העורפי תומך באחד מהשילובים הבאים של קצה עורפי:
  • כל קצוות העורף של קבוצת המופעים: קצה עורף אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קצוות עורף של קבוצות מופעים מנוהלות ולא מנוהלות
  • כל ה-NEGs האזוריים: אחד או יותר NEGs אזוריים מסוג GCE_VM_IP
  • קבוצת נקודות קצה (NEG) למיפוי יציאות
 פנימי
Cloud Service Mesh כמה סוגים עולמי כל שירות לקצה העורפי תומך באחד משילובי ה-backend הבאים:
  • כל קצוות העורף של קבוצת המופעים: קצה עורף אחד או יותר של קבוצת מופעים מנוהלת, לא מנוהלת או שילוב של קצוות עורף של קבוצות מופעים מנוהלות ולא מנוהלות
  • כל ה-NEGs האזוריים: אחד או יותר של GCE_VM_IP_PORT או של NON_GCP_PRIVATE_IP_PORT
  • ‫NEG אחד באינטרנט מסוג INTERNET_FQDN_PORT
  • התאמה אחת או יותר של שירותים (תצוגה מקדימה)
 INTERNAL_SELF_MANAGED
‫1 מאזני העומסים האלה תומכים בקבוצות של מכונות עם IPv4 בלבד ובקבוצות של מכונות עם מחסנית כפולה (IPv4 ו-IPv6), וגם בשרתי קצה של NEG אזוריים.
‫2 בפריסות של GKE, מערכות קצה מעורבות של NEG נתמכות רק עם NEGs עצמאיים.
3 השירותים לקצה העורפי שמשמשים מאזני עומסים של אפליקציות (ALB) בגרסה הקלאסית ומאזני עומסי רשת בשרת proxy בגרסה הקלאסית הם תמיד גלובליים, במסלול רגיל או במסלול פרימיום. עם זאת, במסלול הרגיל חלות ההגבלות הבאות:

‫4 אפשר לצרף שירותי בק-אנד של EXTERNAL_MANAGED לכללי העברה של EXTERNAL. עם זאת, אי אפשר לצרף שירותי קצה עורפי של EXTERNAL לכללי העברה של EXTERNAL_MANAGED. כדי ליהנות מתכונות חדשות שזמינות רק במאזן עומסים חיצוני גלובלי של אפליקציות (ALB), מומלץ להעביר את משאבי EXTERNAL הקיימים אל EXTERNAL_MANAGED באמצעות תהליך ההעברה שמתואר במאמר העברת משאבים ממאזן עומסים חיצוני קלאסי של אפליקציות למאזן עומסים חיצוני גלובלי של אפליקציות (ALB).

מתן שמות למאזני עומסים

במאזני עומסים מסוג Proxy Network Load Balancers (מאזני עומסי רשת בשרת proxy) ו-Passthrough Network Load Balancers (מאזני עומסי רשת להעברת סיגנל ללא שינוי), השם של מאזן העומסים תמיד זהה לשם של שירות הקצה העורפי. ההתנהגות של כל ממשק Google Cloud היא כזו:

  • Google Cloud console. אם יוצרים מאזן עומסי רשת בשרת proxy או מאזן עומסי רשת במצב העברה (passthrough) באמצעות מסוף Google Cloud , לשירות הקצה העורפי מוקצה אוטומטית אותו שם שהוזן עבור שם מאזן העומסים.
  • ‫Google Cloud CLI או API. אם יוצרים מאזן עומסי רשת בשרת proxy או מאזן עומסי רשת בשיטת העברה (passthrough) באמצעות ה-CLI של gcloud או ה-API, צריך להזין שם לבחירה בזמן יצירת שירות הקצה העורפי. שם השירות לקצה העורפי הזה משתקף במסוף Google Cloud כשם של מאזן העומסים.

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

בק-אנד

בקצה העורפי יש נקודת קצה אחת או יותר שמקבלות תעבורה מ Google Cloudמאזן עומסים, מ-Envoy proxy שהוגדר ב-Cloud Service Mesh, או מלקוח gRPC בלי שרת Proxy. יש כמה סוגים של שרתים עורפיים:

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

קבוצות של מכונות

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

מכונות וירטואליות של קצה עורפי וכתובות IP חיצוניות

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

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

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

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

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

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

      • עבור בקצה העורפי של קבוצת מופעים, יעד החבילה הוא כתובת ה-IPv4 הפנימית הראשית של nic0 ממשק הרשת או כתובת ה-IPv6 הראשונה מתוך טווח ה-IPv6‏ /96 שהוקצה לממשק nic0, בהתאם למדיניות בחירת כתובת ה-IP של שירות הקצה העורפי וסוג מחסנית ממשק הרשת./128

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

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

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

    • ממשק רשת עם איזון עומסים: ממשק הרשת שאליו שרת ה-proxy של Envoy שולח את תעבורת הבקשות תלוי בסוג קבוצת השרתים העורפיים:

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

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

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

      • עבור בקצה העורפי של קבוצת מופעים, יעד החבילה הוא כתובת ה-IPv4 הפנימית הראשית של nic0 ממשק הרשת או כתובת ה-IPv6 הראשונה מתוך טווח ה-IPv6‏ /96 שהוקצה לממשק nic0, בהתאם למדיניות בחירת כתובת ה-IP של שירות הקצה העורפי וסוג מחסנית ממשק הרשת./128

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

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

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

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

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

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

  • למאזני עומסים פנימיים מסוג העברת תנועה: לקוחות מתקשרים ישירות עם שרתים עורפיים באמצעות מערך וירטואליזציה של רשת Andromeda. החבילות מנותבות ונמסרות לשרתי קצה עורפיים עם כתובות ה-IP המקוריות של המקור והיעד. במקרים של קצה עורפי של קבוצת מכונות וקצה עורפי של GCE_VM_IPNEG, מאזן העומסים מעביר מנות ל-Network Interface ברשת ה-VPC של השירות לקצה העורפי:

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

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

יציאות עם שם

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

הגדרת יציאות עם שמות:

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

  • בשירות הקצה העורפי, מציינים יציאה אחת עם שם באמצעות שם היציאה בלבד (--port-name).

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

לדוגמה, אפשר להגדיר את היציאה עם השם בקבוצת מופעים עם השם my-service-name והיציאה 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

אחר כך מציינים את היציאה עם השם בהגדרות של שירות הקצה העורפי, כשערך המאפיין --port-name בשירות הקצה העורפי מוגדר כ-my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

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

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

יציאות עם שם רלוונטיות רק לשרתי קצה עורפיים של קבוצות מופעים. ב-NEGs אזוריים עם נקודות קצה (endpoints) מסוג GCE_VM_IP_PORT, ב-NEGs היברידיים עם נקודות קצה מסוג NON_GCP_PRIVATE_IP_PORT וב-NEGs לאינטרנט, היציאות מוגדרות באמצעות מנגנון שונה, כלומר, בנקודות הקצה עצמן. ב-NEGs בלי שרתים יש הפניה לשירותי Google, וב-NEGs של PSC יש הפניה לצירופי שירות באמצעות הפשטות שלא כוללות הגדרה של יציאת יעד.

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

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

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

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

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

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

    • השילובים הלא תואמים של מצבי איזון הם:

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

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

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

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

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

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

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

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

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

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

קבוצות של נקודות קצה ברשת לפי אזור

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

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

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

יש שני סוגים של נקודות קצה ברשת שזמינות ל-NEGs אזוריים:

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

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

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

קבוצות של נקודות קצה ברשת האינטרנט

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

קבוצת נקודות קצה באינטרנט היא שילוב של שם מארח או כתובת IP, בתוספת יציאה אופציונלית. יש שני סוגים של נקודות קצה ברשת שזמינות לקבוצות של נקודות קצה ברשת באינטרנט: INTERNET_FQDN_PORT ו-INTERNET_IP_PORT.

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

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

קבוצות של נקודות קצה ברשת בלי שרת (serverless)

קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה בקצה העורפי של מאזן עומסים. קבוצת נקודות קצה ל-Serverless‏ (NEG) היא קצה עורפי שמפנה אל משאב Cloud Run,‏ App Engine,‏ פונקציות Cloud Run או API Gateway.

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

  • משאב של Cloud Run או קבוצת משאבים.
  • פונקציית Cloud Run או קבוצה של פונקציות (לשעבר פונקציות Cloud Run דור שני).
  • פונקציית Cloud Run (דור ראשון) או קבוצת פונקציות
  • אפליקציה בסביבה רגילה של App Engine או בסביבה גמישה של App Engine, שירות ספציפי באפליקציה, גרסה ספציפית של אפליקציה או קבוצת שירותים.
  • API Gateway שמאפשר גישה לשירותים באמצעות API בארכיטקטורת REST עקבי בכל השירותים, ללא קשר לאופן השימוש בשירות היכולת הזו נמצאת בגרסת טרום-השקה.

כדי להגדיר NEG בלי שרת (serverless) לאפליקציות בלי שרת (serverless) שמשתפות תבנית URL, משתמשים במסכת כתובת URL. מסכת כתובת URL היא תבנית של סכימת כתובות ה-URL (לדוגמה, example.com/<service>). ה-NEG ללא שרתים ישתמש בתבנית הזו כדי לחלץ את השם <service> מכתובת ה-URL של הבקשה הנכנסת, וינתב את הבקשה לשירות התואם של Cloud Run, ‏ פונקציות Cloud Run או App Engine עם אותו שם.

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

מידע נוסף על קבוצות של נקודות קצה ברשת בלי שרת (serverless) זמין במאמר סקירה כללית על קבוצות של נקודות קצה ברשת בלי שרת (serverless).

כבילות שירות

קישור שירות הוא קצה עורפי שיוצר חיבור בין שירות לקצה העורפי ב-Cloud Service Mesh לבין שירות שרשום ב-Service Directory. שירות לקצה העורפי יכול להפנות לכמה כבילות שירות. שירות לקצה העורפי עם כבילת שירות לא יכול להפנות לשום סוג אחר של בק-אנד. מידע נוסף זמין במאמר בנושא שילוב של Cloud Service Mesh עם Service Directory.

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

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

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

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

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

הפרוטוקולים התקפים תלויים בסוג מאזן העומסים או בשאלה אם אתם משתמשים ב-Cloud Service Mesh.

טבלה: פרוטוקול לשרתי הקצה העורפי
מוצר אפשרויות פרוטוקול של שירות לקצה העורפי
מאזן עומסים של אפליקציות (ALB) ‫HTTP, ‏ HTTPS, ‏ HTTP/2
מאזן עומסי רשת בשרת proxy

TCP או SSL

מאזני עומסי רשת אזוריים בשרת proxy תומכים רק ב-TCP.
מאזן עומסי רשת להעברת סיגנל ללא שינוי ‫TCP,‏ UDP או UNSPECIFIED
Cloud Service Mesh HTTP, ‏ HTTPS, ‏ HTTP/2, ‏ gRPC, ‏ TCP

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

מדיניות בחירת כתובת IP

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

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

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

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

מדיניות בחירת כתובת IP תיאור
IPv4 בלבד הפניית תעבורת IPv4 רק לחלק האחורי של שירות לקצה העורפי, בלי קשר לתעבורה מהלקוח ל-GFE. בדיקות התקינות של IPv4 משמשות לבדיקת התקינות של השרתים העורפיים.
העדפת IPv6

לתת עדיפות לחיבור IPv6 של ה-Backend על פני חיבור IPv4 (בתנאי שיש Backend תקין עם כתובות IPv6).

בדיקות תקינות עוקבות מעת לעת אחרי חיבורי IPv6 ו-IPv4 של השרתים העורפיים. ‫GFE מנסה קודם להתחבר ל-IPv6. אם החיבור ל-IPv6 נקטע או איטי, ‏GFE משתמש ב-happy eyeballs כדי לחזור אחורה ולהתחבר ל-IPv4.

גם אם אחד מחיבורי IPv6 או IPv4 לא תקין, ה-backend עדיין נחשב תקין, ו-GFE יכול לנסות את שני החיבורים. בסופו של דבר, התכונה Happy Eyeballs בוחרת באיזה חיבור להשתמש.
IPv6 בלבד

הפניית תנועת IPv6 רק לחלק האחורי של שירות הקצה העורפי, ללא קשר לתנועה מהלקוח ל-proxy. בדיקות תקינות של IPv6 משמשות רק לבדיקת התקינות של השרתים העורפיים.

אין אימות שבודק אם סוג התנועה בשרת העורפי תואם למדיניות לבחירת כתובת IP. לדוגמה, אם יש לכם קצה עורפי (backend) מסוג IPv4 בלבד ואתם בוחרים באפשרות Only IPv6 כמדיניות לבחירת כתובת IP, ההגדרה תוביל לקצה עורפי לא תקין כי התנועה לא תגיע לקצה העורפי הזה ותקבלו את קוד התגובה 503 של HTTP מהלקוחות.

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

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

מצב איזון, קיבולת יעד ושינוי קיבולת

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

  • מצב האיזון מגדיר איך מאזן העומסים מודד את הקיבולת. ל-Google Cloud יש את מצבי האיזון הבאים:
    • ‫CONNECTION: הגדרת הקיבולת על סמך מספר חיבורי ה-TCP החדשים.
    • ‫RATE: מגדיר את הקיבולת על סמך קצב הבקשות החדשות מסוג HTTP.
    • ‫IN-FLIGHT (תצוגה מקדימה): הגדרת הקיבולת על סמך מספר בקשות ה-HTTP הפעילות במקום שיעור בקשות ה-HTTP. אם הבקשות נמשכות יותר משנייה, כדאי להשתמש במצב האיזון הזה במקום במצב RATE.
    • ‫UTILIZATION: הגדרה של הקיבולת על סמך ניצול ה-CPU המשוער של מכונות וירטואליות באזור של קבוצת מכונות.
    • ‫CUSTOM_METRICS: הגדרת הקיבולת על סמך מדדים מותאמים אישית שהוגדרו על ידי המשתמש.
  • במאפיין קיבולת היעד מגדירים את מספר קיבולת היעד.
    • קיבולת היעד לא משמשת כמפסק.
    • כשניצול הקיבולת מגיע לקיבולת היעד, מאזן העומסים מפנה בקשות חדשות או חיבורים חדשים לאזור אחר, אם קצוות העורף מוגדרים בשני אזורים או יותר.
    • מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), מאזני עומסי רשת גלובליים חיצוניים בשרת proxy, מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים ומאזני עומסי רשת פנימיים חוצי-אזורים בשרת proxy משתמשים גם הם בקיבולת כדי להפנות בקשות לאזורים באזורים שונים, אם הגדרתם בק-אנד ביותר מאזור אחד.
    • כשכל האזורים מגיעים לקיבולת היעד, המערכת מחלקת את הבקשות החדשות או את החיבורים החדשים על ידי חריגה מהקיבולת באופן יחסי.
  • כלי לשינוי קיבולת מאפשר לשנות את קיבולת היעד באופן ידני. הערכים של קנה המידה של הקיבולת הם:
    • ‫0: מציין שהקצה העורפי ריק לחלוטין. אי אפשר להשתמש בערך 0 אם לשירות לקצה העורפי יש רק עורף אחד.
    • ‫0.1 (10%) – 1.0 (100%): מציין את אחוז הקיבולת של העורף שנעשה בו שימוש.

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

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

במאזני עומסים של אפליקציות, ב-Cloud Service Mesh ובמאזני עומסי רשת בשרת proxy, סוגי השרתים העורפיים הבאים תומכים בפרמטרים של מצב איזון, קיבולת יעד ושינוי קיבולת:

‫NEGs של אינטרנט, NEGs בלי שרת (serverless) ו-NEGs של Private Service Connect לא תומכים בפרמטרים של מצב איזון, קיבולת יעד ושינוי קיבולת.

מצבי איזון למאזני עומסים של אפליקציות ול-Cloud Service Mesh

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

הגדרת משך הזמן של התנועה

במקרים של עורפי תנועה של Application Load Balancer ו-Cloud Service Mesh, אפשר גם לציין הגדרה של משך התנועה. ההגדרה הזו ייחודית למיפוי בין קצה עורפי נתמך לבין שירות קצה עורפי. להגדרת משך התנועה יש שני ערכים תקינים:

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

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

מצבי איזון למשך תנועה קצר

אם לא מציינים את ההגדרה של משך התנועה או אם היא מוגדרת ל-SHORT(תצוגה מקדימה), מצבי האיזון שזמינים עבור שרתים עורפיים של Application Load Balancer ו-Cloud Service Mesh תלויים בסוג השרת העורפי הנתמך.

טבלה: מצבי איזון לשרתי קצה עורפיים של מאזן עומסים של אפליקציות (ALB) ושל Cloud Service Mesh, באמצעות ההגדרה של משך תעבורה קצר
קצה עורפי נתמך מצב איזון
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
קבוצות של מכונות
‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT
‫NEGs אזוריים של קישוריות היברידית

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

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

טבלה: מצבי איזון עבור עורפי קצה של מאזן עומסים לאפליקציות ו-Cloud Service Mesh באמצעות ההגדרה של משך תנועה ארוך
קצה עורפי נתמך מצב איזון
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
קבוצות של מכונות
‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT
‫NEGs אזוריים של קישוריות היברידית

מצבי איזון למאזני עומסי רשת בשרת proxy

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

טבלה: מצבי איזון עומסים למאזני עומסי רשת לשרתי proxy
קצה עורפי נתמך מצב איזון
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
קבוצות של מכונות
‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT
‫NEGs אזוריים של קישוריות היברידית

מפרטים של קיבולת היעד

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

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

מצב איזון החיבור

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

פרמטרים של קיבולת יעד למצב איזון CONNECTION
פרמטר של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-connections
חיבורי TCP ביעד לכל אזור קצה עורפי
max-connections-per-instance
חיבורי TCP ליעד לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר חיבורי ה-TCP ליעד בכל אזור קצה עורפי.
max-connections-per-endpoint
חיבורי TCP ביעד לכל נקודת קצה של NEG. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר חיבורי ה-TCP ליעד בכל אזור קצה עורפי.

שימוש בפרמטר max-connections

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

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

    • אם מגדירים את max-connections ל-X, קיבולת היעד האזורי היא X.
    • מספר החיבורים הממוצע לכל מופע הוא X / h.

  • קבוצות מנוהלות של מופעים אזוריים לא תומכות בפרמטר max-connections כי הן מורכבות מכמה אזורים. במקום זאת, צריך להשתמש בפרמטר max-connections-per-instance.

  • עבור NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h ≤ N), החישובים הם כדלקמן:

    • אם מגדירים את max-connections ל-X, קיבולת היעד האזורי היא X.
    • מספר החיבורים הממוצע לכל נקודת קצה הוא X / h.

שימוש בפרמטר max-connections-per-instance או max-connections-per-endpoint

כשמציינים את הפרמטר max-connections-per-instance או max-connections-per-endpoint, מאזן העומסים משתמש בערך שמספקים כדי לחשב את הקיבולת לכל אזור:

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

    • אם מגדירים את max-connections-per-instance ל-X, קיבולת היעד האזורי היא N * X. הפעולה הזו שוות ערך להגדרת max-connections לערך N * X.
    • מספר החיבורים הממוצע לכל מופע הוא (N * X) / h.

  • אם מגדירים את max-connections-per-instance ל-X בקבוצת מופעי מכונה מנוהלים אזורית, Google Cloud מחשב את קיבולת היעד לכל אזור בכל אזור של קבוצת המופעים. בכל אזור, אם יש K מכונות בסך הכול ו-h מכונות תקינות (כאשר h≤ K), החישובים הם כדלקמן:

    • קיבולת היעד של האזור היא K * X.
    • מספר החיבורים הממוצע לכל מופע באזור הוא (K * X) / h.

  • עבור NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h ≤ N), החישובים הם כדלקמן:

    • אם מגדירים את max-connections-per-endpoint ל-X, קיבולת היעד האזורי היא N * X. הפעולה הזו שוות ערך להגדרת max-connections לערך N * X.
    • מספר החיבורים הממוצע לכל נקודת קצה הוא (N * X) / h.

מצב איזון שיעורים

קצה עורפי של מאזן עומסים של אפליקציות ושל Cloud Service Mesh עם הגדרה קצרה או לא מוגדרת של משך התנועה (גרסת Preview) יכולים להשתמש במצב איזון RATE עם אחד מפרמטרי קיבולת היעד הנדרשים הבאים:

טבלה: פרמטרים של קיבולת יעד למצב איזון RATE
פרמטר של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-rate
קצב בקשות HTTP ליעד לכל אזור קצה עורפי
‫max-rate-per-instance
יעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. ‫Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות ל-HTTP ליעד לכל אזור בק-אנד.
max-rate-per-endpoint
קצב בקשות HTTP לטירגוט לכל נקודת קצה (endpoint) של NEG. ‫Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד.

שימוש בפרמטר max-rate

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

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

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

  • קבוצות מנוהלות של מופעים אזוריים לא תומכות בפרמטר max-rate כי הן מורכבות מכמה אזורים. במקום זאת, צריך להשתמש בפרמטר max-rate-per-instance.

  • עבור NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h ≤ N), החישובים הם כדלקמן:

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

שימוש בפרמטר max-rate-per-instance או max-rate-per-endpoint

כשמציינים את הפרמטר max-rate-per-instance או max-rate-per-endpoint, מאזן העומסים משתמש בערך שסיפקתם כדי לחשב את הקיבולת לכל אזור:

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

    • אם מגדירים את max-rate-per-instance ל-X, קיבולת היעד האזורית היא N * X בקשות לשנייה. הפעולה הזו שוות ערך להגדרת max-rate לערך N * X.
    • מספר הבקשות הממוצע לשנייה לכל מופע הוא (N * X) / h.

  • אם מדובר בקבוצה אזורית של מופעי מכונה מנוהלים, אם מגדירים את max-rate-per-instance ל-X,‏ Google Cloud מחשב את קיבולת היעד לכל אזור בכל אזור של קבוצת מופעי המכונה המנוהלים. בכל אזור, אם יש K מכונות בסך הכול ו-h מכונות תקינות (כאשר h≤ K), החישובים הם כדלקמן:

    • קיבולת היעד של האזור היא K * X בקשות לשנייה.
    • מספר הבקשות הממוצע לשנייה לכל מופע באזור הוא (K * X) / h.

  • ב-NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h≤ N), החישובים הם כדלקמן:

    • אם מגדירים את max-rate-per-endpoint ל-X, קיבולת היעד האזורית היא N * X בקשות לשנייה. הפעולה הזו שוות ערך להגדרת max-rate לערך N * X.
    • מספר הבקשות הממוצע לשנייה לכל נקודת קצה הוא (N * X) / h.

מצב איזון בטיסה

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

טבלה: פרמטרים של קיבולת יעד עבור מצב האיזון IN_FLIGHT
פרמטר של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-in-flight-requests
מספר היעד של בקשות HTTP בתהליך לכל אזור backend
max-in-flight-requests-per-instance
מספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד.
‫max-in-flight-requests-per-endpoint
מספר היעד של בקשות HTTP בתהליך לכל נקודת קצה של NEG. מאזן העומסים משתמש בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד.

שימוש בפרמטר max-in-flight-requests

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

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

    • אם מגדירים את max-in-flight-requests ל-X, קיבולת היעד האזורית היא X בקשות HTTP בתהליך.
    • מספר בקשות ה-HTTP הממוצע בתהליך לכל מופע הוא X / h.

  • קבוצות אזוריות של מופעים מנוהלים לא תומכות בפרמטר max-in-flight-requests כי הן מורכבות מכמה אזורים. במקום זאת, צריך להשתמש בפרמטר max-in-flight-requests-per-instance.

  • עבור NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h≤ N), החישובים הם כדלקמן:

    • אם מגדירים את max-in-flight-requests ל-X, קיבולת היעד האזורית היא X בקשות HTTP בתהליך.
    • המספר הממוצע של בקשות HTTP בתהליך לכל נקודת קצה הוא X / h.

שימוש בפרמטרים max-in-flight-requests-per-instance או max-in-flight-requests-per-endpoint

כשמציינים את הפרמטר max-in-flight-requests-per-instance או max-in-flight-requests-per-endpoint, מאזן העומסים משתמש בערך שסיפקתם כדי לחשב את הקיבולת לכל אזור:

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

    • אם מגדירים את max-in-flight-requests-per-instance ל-X, קיבולת היעד האזורי היא N * X בקשות HTTP בתהליך. הפעולה הזו שקולה להגדרת max-in-flight-requests לערך N * X.
    • מספר בקשות ה-HTTP הממוצע בתהליך לכל מופע הוא (N * X) / h.

  • אם מגדירים את max-in-flight-requests-per-instance ל-X בקבוצת מופעי מכונה מנוהלים אזורית, Google Cloud מחשב את קיבולת היעד לכל אזור בכל אזור של קבוצת המופעים. בכל אזור, אם יש K מכונות בסך הכול ו-h מכונות תקינות (כאשר h≤ K), החישובים הם כדלקמן:

    • קיבולת היעד של האזור היא K * X בקשות HTTP בתהליך.
    • הערך הממוצע של בקשות HTTP בתהליך לכל מופע באזור הוא (K * X) / h.

  • עבור NEG אזורי עם N נקודות קצה בסך הכול ו-h נקודות קצה תקינות (כאשר h≤ N), החישובים הם כדלקמן:

    • אם מגדירים את max-in-flight-requests-per-endpoint ל-X, קיבולת היעד האזורי היא N * X בקשות HTTP בתהליך. הפעולה הזו שקולה להגדרת max-in-flight-requests לערך N * X.
    • מספר בקשות ה-HTTP הממוצע שנמצאות בתהליך לכל נקודת קצה הוא (N * X) / h.

מצב איזון ניצול

מאזן עומסים של אפליקציות, Cloud Service Mesh וקצה עורפי של קבוצת מופעים של מאזן עומסי רשת בשרת proxy יכולים להשתמש בUTILIZATION מצב איזון. בקצה העורפי של NEG אין תמיכה במצב איזון העומסים הזה.

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

  • אפשר להשתמש במצב איזון UTILIZATION רק אם זיקת הסשן מוגדרת ל-NONE. אם שירות הקצה העורפי משתמש בזיקה לסשן ששונה מ-NONE, צריך להשתמש במצבי האיזון RATE, IN-FLIGHT או CONNECTION במקום זאת.

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

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

פרמטרים של קיבולת יעד לניצול עבור עורפי קצה של Application Load Balancer ו-Cloud Service Mesh עם הגדרה לא מוגדרת או קצרה של משך התנועה

ב-Application Load Balancer וב-Cloud Service Mesh backends עם הגדרה של משך תנועה לא מוגדר או קצר (תצוגה מקדימה) אפשר להשתמש במצב איזון UTILIZATION עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:

טבלה: פרמטרים של קיבולת יעד במצב איזון UTILIZATION ושילובי פרמטרים עבור עורפי תנועה של מאזן עומסים של אפליקציות ו-Cloud Service Mesh עם הגדרה לא מוגדרת או קצרה של משך התנועה
פרמטר או שילוב פרמטרים של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-utilization
יעד הניצול לכל אזור קצה עורפי
max-rate
קצב בקשות HTTP ליעד לכל אזור קצה עורפי
‫max-rate ו-max-utilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • שיעור הניצול של האזור
  • קצב בקשות ה-HTTP של היעד באזור
‫max-rate-per-instance
יעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. ‫Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות ל-HTTP ליעד לכל אזור בק-אנד.
max-rate-per-instance וגם max-utilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • שיעור הניצול של האזור
  • קצב בקשות ה-HTTP הממוקד של האזור (מחושב מקצב בקשות ה-HTTP הממוקד לכל מופע VM של ה-VM באזור)

מידע נוסף על פרמטרים של קיבולת יעד max-rate ו-max-rate-per-instance זמין בקטע מצב איזון קצב במאמר הזה.

פרמטרים של קיבולת יעד לניצול עבור בק-אנד של מאזן עומסים של אפליקציות ו-Cloud Service Mesh עם הגדרה של משך תנועה ארוך

מאזני עומסים של אפליקציות ושרתי קצה של Cloud Service Mesh עם הגדרה ארוכה של משך התנועה (גרסת Preview) יכולים להשתמש במצב איזון עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:UTILIZATION

טבלה: פרמטרים ושילובי פרמטרים של קיבולת יעד במצב איזון UTILIZATION עבור עורפי קצה של Application Load Balancer ו-Cloud Service Mesh עם הגדרה של משך תנועה ארוך (גרסת Preview)
פרמטר או שילוב פרמטרים של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-utilization
יעד הניצול לכל אזור קצה עורפי
max-in-flight-requests
מספר היעד של בקשות HTTP בתהליך לכל אזור backend
‫max-in-flight-requests ו-max-utilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • שיעור הניצול של האזור
  • מספר היעד של בקשות HTTP בתהליך באזור
max-in-flight-requests-per-instance
מספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד.
max-in-flight-requests-per-instance וגם max-utilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • שיעור הניצול של האזור
  • מספר היעד של בקשות HTTP בתהליך באזור (מחושב ממספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית במכונות באזור)

מידע נוסף על פרמטרים של קיבולת יעד max-in-flight-requests ו-max-in-flight-requests-per-instance זמין בקטע מצב איזון בזמן ההעברה במאמר הזה.

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

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

‫
טבלה: פרמטרים של קיבולת יעד במצב איזון UTILIZATION ושילובי פרמטרים עבור קצה עורפי של מאזן עומסי רשת מסוג Proxy Network Load Balancer
פרמטר או שילוב פרמטרים של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
max-utilization
יעד הניצול לכל אזור קצה עורפי
max-connections
חיבורי TCP ביעד לכל אזור קצה עורפי
‫max-connections ו-max-utilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • שיעור הניצול של האזור
  • חיבורי TCP ליעד באזור
max-connections-per-instance
חיבורי TCP ליעד לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר חיבורי ה-TCP ליעד בכל אזור קצה עורפי.
‫max-connections-per-instance and max-utilization
Target is the first to be reached in the backend zone:
  • שיעור הניצול של האזור
  • חיבורי TCP ליעד של האזור (מחושבים מחיבורי ה-TCP ליעד לכל מכונה וירטואלית במכונות הווירטואליות באזור)

מידע נוסף על פרמטרים של קיבולת יעד max-connections ו-max-connections-per-instance זמין בקטע מצב איזון חיבורים במאמר הזה.

מצב איזון של מדדים מותאמים אישית

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

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

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

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

טבלה: פרמטרים של קיבולת יעד במצב איזון CUSTOM_METRICS ושילובי פרמטרים עבור קצה עורפי של מאזן עומסים של אפליקציות עם הגדרה לא מוגדרת או קצרה של משך התנועה
פרמטר או שילוב פרמטרים של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
backends[].customMetrics[].maxUtilization
Target custom metric utilization per backend zone
max-rate
קצב בקשות HTTP ליעד לכל אזור קצה עורפי
max-rate וגם backends[].customMetrics[].maxUtilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • היעד של מדד השימוש המותאם אישית באזור
  • קצב בקשות ה-HTTP של היעד באזור
‫max-rate-per-instance
יעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. ‫Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות ל-HTTP ליעד לכל אזור בק-אנד.
max-rate-per-instance וגם backends[].customMetrics[].maxUtilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • היעד של מדד השימוש המותאם אישית באזור
  • קצב בקשות ה-HTTP הממוקד של האזור (מחושב מקצב בקשות ה-HTTP הממוקד לכל מופע VM של ה-VM באזור)
max-rate-per-endpoint
קצב בקשות HTTP לטירגוט לכל נקודת קצה (endpoint) של NEG. ‫Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד.
‫max-rate-per-endpoint and backends[].customMetrics[].maxUtilization
Target is the first to be reached in the backend zone:
  • היעד של מדד השימוש המותאם אישית באזור
  • שיעור היעד של בקשות HTTP באזור (מחושב משיעור היעד של בקשות HTTP לכל נקודת קצה של NEG בנקודות הקצה באזור)

מידע נוסף על פרמטרים של קיבולת יעד max-rate, max-rate-per-instance ו-max-rate-per-endpoint זמין בקטע מצב איזון קצב במסמך הזה.

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

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

טבלה: פרמטרים של קיבולת יעד במצב איזון CUSTOM_METRICS ושילובי פרמטרים עבור קצה עורפי של Application Load Balancer עם הגדרה של משך תנועה ארוך (גרסת Preview)
פרמטר או שילוב פרמטרים של קיבולת היעד קצה עורפי נתמך
קבוצות של מופעי מכונה אזוריים (מנוהלים או לא מנוהלים) קבוצות אזוריות של מופעי מכונה מנוהלים ‫Zonal NEGs עם נקודות קצה של GCE_VM_IP_PORT ‫NEGs אזוריים של קישוריות היברידית
backends[].customMetrics[].maxUtilization
Target custom metric utilization per backend zone
max-in-flight-requests
מספר היעד של בקשות HTTP בתהליך לכל אזור backend
max-in-flight-requests וגם backends[].customMetrics[].maxUtilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • היעד של מדד השימוש המותאם אישית באזור
  • מספר היעד של בקשות HTTP בתהליך באזור
max-in-flight-requests-per-instance
מספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד.
max-in-flight-requests-per-instance וגם backends[].customMetrics[].maxUtilization
היעד הוא הראשון שאליו מגיעים באזור העורפי:
  • היעד של מדד השימוש המותאם אישית באזור
  • מספר היעד של בקשות HTTP בתהליך באזור (מחושב ממספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית במכונות באזור)
‫max-in-flight-requests-per-endpoint
מספר היעד של בקשות HTTP בתהליך לכל נקודת קצה של NEG. מאזן העומסים משתמש בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד.
‫max-in-flight-requests-per-endpoint and backends[].customMetrics[].maxUtilization
Target is the first to be reached in the backend zone:
  • היעד של מדד השימוש המותאם אישית באזור
  • מספר היעד של בקשות HTTP בתהליך באזור (מחושב ממספר היעד של בקשות HTTP בתהליך לכל נקודת קצה של NEG בנקודות הקצה באזור)

מידע נוסף על פרמטרים של קיבולת יעד max-in-flight-requests, max-in-flight-requests-per-instance ו-max-flight-requests-per-endpoint זמין במאמר בנושא מצב איזון בזמן ההפעלה.

מדיניות איזון עומסים של שירות

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

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

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

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

מדיניות מקומית לאיזון עומסים

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

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

  • ‫ROUND_ROBIN (ברירת מחדל): זו הגדרת ברירת המחדל של מדיניות המיקום של איזון העומסים, שבה מאזן העומסים בוחר עורף תקין בסדר סיבובי.

  • ‫LEAST_REQUEST: אלגוריתם O(1) שבו מאזן העומסים בוחר באופן אקראי שני מארחים תקינים, ובוחר את המארח עם מספר הבקשות הפעילות הנמוך יותר.

  • ‫RING_HASH: האלגוריתם הזה מיישם גיבוב עקבי לשרתי קצה עורפיים. האלגוריתם בנוי כך שהוספה או הסרה של מארח מקבוצה של N מארחים משפיעה רק על 1/N מהבקשות.

  • ‫RANDOM: מאזן העומסים בוחר מארח תקין באופן אקראי.

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

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

  • ‫WEIGHTED_MAGLEV: הטמעה של איזון עומסים משוקלל לכל מופע במאזני עומסים חיצוניים של רשת להעברת סיגנל ללא שינוי באמצעות משקלים שמדווחים על ידי בדיקות תקינות. אם משתמשים במדיניות הזו, שירות לקצה העורפי צריך להגדיר בדיקת תקינות מבוססת-HTTP שאינה מדור קודם, ותשובות בדיקת התקינות צפויות להכיל את שדה כותרת התגובה של HTTP שאינו סטנדרטי, X-Load-Balancing-Endpoint-Weight, כדי לציין את המשקלים לכל מופע. ההחלטות לגבי איזון העומסים מתקבלות על סמך המשקלים לכל מופע שמדווחים בתשובות האחרונות לבדיקת התקינות שעובדו, כל עוד כל מופע מדווח על משקל תקין או על UNAVAILABLE_WEIGHT. אחרת, איזון העומסים יישאר שווה.

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

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

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

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

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

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

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

האפשרויות הנתמכות:

  • ROUND_ROBIN

  • LEAST_REQUEST

  • RING_HASH

  • RANDOM

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

  • MAGLEV

  • WEIGHTED_ROUND_ROBIN

מאזן עומסי רשת גלובלי חיצוני בשרת proxy

מאזן עומסי רשת אזורי חיצוני בשרת proxy

מאזן עומסי רשת פנימי בשרת proxy בין אזורים

מאזן עומסי רשת פנימי אזורי בשרת proxy

האפשרויות הנתמכות:

  • ROUND_ROBIN

  • LEAST_REQUEST

  • RING_HASH

  • RANDOM

  • MAGLEV

  • ‫ORIGINAL_DESTINATION (לא נתמך במאזני עומסי רשת גלובליים חיצוניים לשרת proxy)
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי

האפשרויות הנתמכות:

  • MAGLEV

  • WEIGHTED_MAGLEV

מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי

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

מאזן עומסי רשת קלאסי בשרת proxy

 לא נתמך

הערה: ערך ברירת המחדל האפקטיבי של מדיניות המיקום של איזון העומסים (localityLbPolicy) משתנה בהתאם להגדרות של זיקה לסשן (session affinity). אם לא מגדירים את הזיקה לסשן (session affinity) – כלומר, אם הזיקה לסשן (session affinity) נשארת בערך ברירת המחדל NONE – ערך ברירת המחדל של localityLbPolicy הוא ROUND_ROBIN. אם זיקה לסשן מוגדרת לערך שאינו NONE, ערך ברירת המחדל של localityLbPolicy הוא MAGLEV.

כדי להגדיר מדיניות מקומית לאיזון עומסים, אפשר להשתמש במסוףGoogle Cloud , ב-gcloud ‏(--locality-lb-policy) או ב-API ‏(localityLbPolicy).

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

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

יש תמיכה בחלוקה למערכות משנה בעורף עבור:

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

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

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

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

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

התרשים הבא מציג מאזן עומסים עם שני שרתי proxy. בלי חלוקה לקבוצות משנה של קצה עורפי, התנועה משני ה-proxy מופצת לכל הקצוות העורפיים בשירות הקצה העורפי 1. כשהאפשרות 'חלוקת משנה של ה-Backend' מופעלת, התנועה מכל שרת proxy מופצת לחלק מהשרתים של ה-Backend. התנועה משרת proxy 1 מופצת לעורפי 1 ו-2, והתנועה משרת proxy 2 מופצת לעורפי 3 ו-4.

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

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

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

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

  • למרות שהחלוקה לקבוצות משנה בעורף נועדה לוודא שכל המופעים בעורף ינוצלו היטב, היא עלולה להוביל להטיה מסוימת בכמות התנועה שכל עורף מקבל. מומלץ להגדיר את localityLbPolicy כ-LEAST_REQUEST בשירותים לקצה העורפי שרגישים לאיזון העומס בקצה העורפי.
  • הפעלה או השבתה של יצירת קבוצת משנה משבשות קישורים קיימים.
  • כדי לבצע חלוקה למערכי משנה בעורף המערכת, צריך להגדיר את הזיקה לסשן (session affinity) לערך NONE (גיבוב של 5 טאפלים). אפשר להשתמש באפשרויות אחרות של זיקה לסשן רק אם השבתתם את חלוקת ה-backend לקבוצות משנה. ערכי ברירת המחדל של הדגלים --subsetting-policy ו---session-affinity הם NONE, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.

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

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

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

כברירת מחדל, האפשרות 'חלוקה לקבוצות משנה' מושבתת, מה שמגביל את שירות לקצה העורפי להפצה של עד 250 מופעים או נקודות קצה של Backend. אם שירות ה-backend שלכם צריך לתמוך ביותר מ-250 שירותי backend, אתם יכולים להפעיל חלוקה לקבוצות משנה. כשהאפשרות 'חלוקה לקבוצות משנה' מופעלת, נבחרת קבוצת משנה של מופעי קצה עורפיים לכל חיבור לקוח.

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

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

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

הוראות להגדרה מופיעות במאמר Subsetting.

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

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

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

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

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

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

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

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

כברירת מחדל, כל מאזני העומסים של Google Cloud בוחרים בקצה העורפי באמצעות גיבוב של חמישה ערכים (--session-affinity=NONE), באופן הבא:

  • כתובת ה-IP של המקור של חבילת הנתונים
  • יציאת המקור של המנה (אם היא מופיעה בכותרת של המנה)
  • כתובת ה-IP של היעד של חבילת הנתונים
  • יציאת היעד של המנה (אם היא מופיעה בכותרת של המנה)
  • הפרוטוקול של חבילת הנתונים

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

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

מידע נוסף על זיקה לסשן (session affinity) למאזני עומסים של רשתות proxy זמין במאמרי עזרה הבאים:

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

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

  • במאזני עומסים חיצוניים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות שמשתמשים בפרוטוקול HTTP,‏ HTTPS או HTTP/2, פסק הזמן של שירות הקצה העורפי הוא פסק זמן של בקשה ותגובה לתנועת HTTP(S).

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

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

    • ערך ברירת המחדל: 30 שניות
    • טווח שניתן להגדרה: 1 עד 2,147,483,647 שניות

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

  • ב-Cloud Service Mesh, שדה הזמן הקצוב לתפוגה של שירות הקצה העורפי (שמצוין באמצעות timeoutSec) לא נתמך בשירותי gRPC ללא proxy. בשירותים כאלה, מגדירים את פסק הזמן של שירות הקצה העורפי באמצעות השדה maxStreamDuration. הסיבה לכך היא ש-gRPC לא תומך בסמנטיקה של timeoutSec, שמציינת את משך הזמן להמתנה עד שהבק-אנד יחזיר תגובה מלאה אחרי שליחת הבקשה. זמן קצוב לתפוגה של gRPC מציין את משך הזמן להמתנה מתחילת הסטרימינג עד שהתגובה תעבור עיבוד מלא, כולל כל הניסיונות החוזרים.

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

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

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

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

מידע נוסף זמין במאמרים הבאים:

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

חלק משירותי ה-Backend תומכים בתכונות האופציונליות הבאות.

Cloud CDN

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

פרטים נוספים זמינים במאמרי העזרה בנושא Cloud CDN.

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

Cloud Armor

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

אם אתם משתמשים במסוף Google Cloud , אתם יכולים לבצע אחת מהפעולות הבאות:

  • בוחרים מדיניות אבטחה קיימת של Cloud Armor.
  • מאשרים את ההגדרה של מדיניות אבטחה של Cloud Armor להגבלת קצב של יצירת בקשות עם שם, מספר בקשות, מרווח, מפתח ופרמטרים של הגבלת קצב של יצירת בקשות שאפשר להתאים אישית. אם אתם משתמשים ב-Cloud Armor עם שירות proxy במעלה הזרם, כמו ספק CDN, צריך להגדיר את Enforce_on_key ככתובת IP של XFF.
  • כדי לבטל את ההצטרפות להגנה של Cloud Armor, בוחרים באפשרות None (ללא).

IAP

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

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

תכונות מתקדמות לניהול תעבורת נתונים

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

‫API וgcloud הפניה

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

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

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

לסרטונים קשורים: