שירות לקצה העורפי מגדיר איך Cloud Load Balancing מבזר את תעבורת הנתונים. ההגדרות של שירות הקצה העורפי מכילות קבוצה של ערכים, כמו הפרוטוקול שמשמש לחיבור לקצה העורפי, הגדרות שונות של הפצה וסשן, בדיקות תקינות וזמני קצוב. ההגדרות האלה מאפשרות לכם לשלוט באופן מדויק בהתנהגות של מאזן העומסים. כדי לעזור לכם להתחיל, לרוב ההגדרות יש ערכי ברירת מחדל שמאפשרים הגדרה מהירה. ההיקף של שירות לקצה העורפי הוא גלובלי אואזורי.
מאזני עומסים, שרתי proxy של Envoy ולקוחות gRPC בלי שרת Proxy משתמשים בפרטי ההגדרה במשאב שירות לקצה העורפי כדי לבצע את הפעולות הבאות:
- הפניית תנועה ישירות אל הבק-אנדים הנכונים, שהם קבוצות של מופעים או קבוצות של נקודות קצה ברשת (NEGs).
- חלוקת התנועה לפי מצב איזון, שהוא הגדרה לכל שרת קצה.
- קובעים איזו בדיקת תקינות עוקבת אחרי התקינות של השרתים העורפיים.
- מציינים session affinity.
- בודקים אם שירותים אחרים מופעלים, כולל השירותים הבאים שזמינים רק עבור מאזני עומסים מסוימים:
- Cloud CDN
- כללי מדיניות האבטחה של Google Cloud Armor
- שרת proxy לאימות זהויות (IAP)
- הגדרת שירותים לקצה העורפי (גלובליים ואזוריים) כשירות באפליקציות של App Hub.
מגדירים את הערכים האלה כשיוצרים שירות לקצה העורפי או כשמוסיפים בק-אנד לשירות לקצה העורפי.
הערה: אם אתם משתמשים במאזן עומסים חיצוני גלובלי של אפליקציות או במאזן עומסים קלאסי של אפליקציות, והבק-אנד שלכם מציג תוכן סטטי, כדאי לשקול שימוש בקטגוריות בק-אנד במקום בשירותי בק-אנד. אפשר לעיין במאמרים בנושא קטגוריות בק-אנד למאזן עומסים גלובלי חיצוני של אפליקציות או קטגוריות בק-אנד למאזן עומסים קלאסי של אפליקציות.בטבלה הבאה מפורטים מאזני העומסים שמשתמשים בשירותים לקצה העורפי. המוצר שבו אתם משתמשים קובע גם את המספר המקסימלי של שירותים לקצה העורפי, את ההיקף של שירות לקצה העורפי, את סוגי הקצה העורפי הנתמכים ואת סכימת איזון העומסים של השירות לקצה העורפי. סכמת איזון העומסים היא מזהה שמשמש את Google לסיווג של כללי העברה ושירותי קצה עורפי. כל מוצר לאיזון עומסים משתמש בסכמת איזון עומסים אחת לכללי ההעברה ולשירותים לקצה העורפי. יש סכימות שמשותפות בין מוצרים.
| מוצר | המספר המקסימלי של שירותים לקצה עורפי | היקף השירות לקצה העורפי | סוגי קצה עורפי נתמכים | סכמת איזון עומסים |
|---|---|---|---|---|
| מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) | כמה סוגים | עולמי | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
EXTERNAL_MANAGED |
| מאזן עומסים קלאסי של אפליקציות (ALB) | כמה סוגים | בכל העולם3 | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
חיצוני4 |
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | כמה סוגים | אזורי | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
EXTERNAL_MANAGED |
| מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים | כמה סוגים | עולמי | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
INTERNAL_MANAGED |
| מאזן עומסים פנימי אזורי של אפליקציות (ALB) | כמה סוגים | אזורי | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
INTERNAL_MANAGED |
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy | 1 | בכל העולם3 | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
EXTERNAL_MANAGED |
| מאזן עומסי רשת קלאסי בשרת proxy | 1 | בכל העולם3 | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
חיצוני |
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | בלי נתיבי TLS: 1 עם נתיבי TLS: כמה |
אזורי | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
EXTERNAL_MANAGED |
| מאזן עומסי רשת אזורי פנימי בשרת proxy | בלי נתיבי TLS: 1 עם נתיבי TLS: כמה |
אזורי | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
INTERNAL_MANAGED |
| מאזן עומסי רשת פנימי בשרת proxy שפועל בכמה אזורים | בלי נתיבי TLS: 1 עם נתיבי TLS: כמה |
עולמי | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
INTERNAL_MANAGED |
| מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי | 1 | אזורי | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
חיצוני |
| מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי | 1 | אזורי, אבל אפשר להגדיר אותו כך שיהיה נגיש בכל העולם | שירות הקצה העורפי תומך באחד משילובי הקצה העורפי הבאים:
|
INTERNAL |
| Cloud Service Mesh | כמה סוגים | עולמי | כל שירות backend תומך באחד מהשילובים הבאים של backend:
|
INTERNAL_SELF_MANAGED |
- כלל ההעברה וכתובת ה-IP החיצונית שלו הם אזוריים.
- כל שרתי הבק-אנד שמחוברים לשירות לקצה העורפי צריכים להיות באותו אזור כמו כלל ההעברה.
EXTERNAL_MANAGED לכללי העברה של EXTERNAL. עם זאת, אי אפשר לצרף שירותי קצה עורפי של EXTERNAL לכללי העברה של EXTERNAL_MANAGED.
כדי ליהנות מתכונות חדשות שזמינות רק ב-Global External Application Load Balancer, מומלץ להעביר את משאבי EXTERNAL הקיימים אל EXTERNAL_MANAGED באמצעות תהליך ההעברה שמתואר במאמר העברת משאבים ממאזן עומסים קלאסי של אפליקציות אל Global External Application Load Balancer.
מתן שמות למאזני עומסים
במאזני עומסים מסוג Proxy Network Load Balancer ומאזני עומסים מסוג Passthrough Network Load Balancer, השם של מאזן העומסים תמיד זהה לשם של שירות לקצה העורפי. ההתנהגות של כל ממשק Google Cloud היא כדלקמן:
- Google Cloud console. אם יוצרים מאזן עומסי רשת בשרת proxy או מאזן עומסי רשת במצב העברה (passthrough) באמצעות המסוף Google Cloud , שירות לקצה העורפי מקבל אוטומטית את אותו שם שהוזן עבור שם מאזן העומסים.
- Google Cloud CLI או API. אם יוצרים מאזן עומסי רשת בשרת proxy או מאזן עומסי רשת מסוג העברה (passthrough) באמצעות ה-CLI של gcloud או API, צריך להזין שם לבחירה בזמן יצירת שירות הקצה העורפי. שם שירות הקצה העורפי הזה משתקף במסוף Google Cloud כשם של מאזן העומסים.
מידע נוסף על מתן שמות למאזני עומסים של אפליקציות זמין במאמר סקירה כללית של מיפוי כתובות URL: מתן שמות למאזני עומסים.
בק-אנד
בקצה העורפי יש נקודת קצה אחת או יותר שמקבלות תעבורת נתונים מ Google Cloudמאזן עומסים, משרת proxy של Envoy שהוגדר ב-Cloud Service Mesh, או מלקוח gRPC בלי שרת Proxy. יש כמה סוגים של שרתים עורפיים:
- קבוצת מכונות שמכילה מכונות וירטואליות (VM). קבוצת מופעים יכולה להיות קבוצת מופעים מנוהלת (MIG), עם או בלי שינוי גודל אוטומטי, או שהיא יכולה להיות קבוצת מופעים לא מנוהלת. יותר משירות קצה עורפי אחד יכול להפנות לקבוצת מכונות, אבל כל שירותי הקצה העורפי שמפנים לקבוצת המכונות חייבים להשתמש במצבי איזון תואמים. מידע נוסף מופיע בקטע הגבלות והנחיות לגבי קבוצות של מכונות וירטואליות.
- Zonal NEG
- Serverless NEG
- Private Service Connect NEG
- NEG באינטרנט
- קבוצת נקודות קצה (NEG) לקישוריות היברידית
- מיפוי יציאות של NEG
- Service Directory service bindings (תצוגה מקדימה)
- עורפי שירות שפורסמו (גרסת Preview)
אי אפשר למחוק קבוצת מופעים או NEG בעורף העורף שמשויכים לשירות עורף עורף. לפני שמוחקים קבוצת מופעים או NEG, צריך קודם להסיר אותה כקצה עורפי מכל שירותי הקצה העורפי שמפנים אליה.
קבוצות של מכונות
בקטע הזה מוסבר איך קבוצות של מכונות וירטואליות עובדות עם שירות לקצה העורפי.
מכונות וירטואליות בעורף וכתובות IP חיצוניות
מכונות וירטואליות בבק-אנד בשירותי בק-אנד לא צריכות כתובות IP חיצוניות:
במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסי רשת חיצוניים לשרת proxy: לקוחות מתקשרים עם Google Front End (GFE) בשכבה הראשונה, שמארח את כתובת ה-IP החיצונית של מאזן העומסים. ממשק הקצה של Google בשכבה הראשונה מתקשר עם ממשק הקצה של Google בשכבה השנייה, שנמצא באותו אזור כמו מכונת הבק-אנד הווירטואלית או נקודת הקצה. כל GFE בשכבה השנייה מתקשר עם מכונות וירטואליות או נקודות קצה בעורף, בהתאם לכללים הבאים:
ממשק רשת עם איזון עומסים: ממשק הרשת שאליו GFE בשכבה השנייה שולח את תעבורת הבקשות תלוי בסוג קבוצת השרתים העורפיים:
במקרה של קצוות עורפיים של קבוצת מכונות, מאזן העומסים תמיד מעביר חבילות לממשק
nic0של כל מכונת VM בקצה העורפי. הכלל הזה נכון גם אם למכונה הווירטואלית יש כמה ממשקי רשת באותה רשת 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 ממוקם ברשת משנה של שרת proxy בלבד. כל שרת proxy של Envoy מתקשר עם מכונות וירטואליות או נקודות קצה של backend בהתאם לכללים הבאים:
ממשק רשת עם איזון עומסים: ממשק הרשת שאליו שרת ה-proxy של Envoy שולח את תעבורת הבקשות תלוי בסוג קבוצת השרתים העורפיים:
במקרה של קצוות עורפיים של קבוצת מכונות, מאזן העומסים תמיד מעביר חבילות לממשק
nic0של כל מכונת VM בקצה העורפי. הכלל הזה נכון גם אם למכונה הווירטואלית יש כמה ממשקי רשת באותה רשת 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.
למאזנים אזוריים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי: לקוחות מתקשרים ישירות עם שרתים עורפיים באמצעות התשתית של Google Maglev. החבילות מנותבות ונמסרות לשרתי קצה עורפיים עם כתובות ה-IP המקוריות של המקור והיעד. מאזן העומסים מעביר חבילות לאחד מממשקי הרשת הבאים:
במאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על מאגרי יעד, מאזן העומסים תמיד מעביר חבילות ל
nic0ממשק.במאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי עם קצה עורפי של קבוצת מכונות, מאזן העומסים תמיד מעביר חבילות ל-interface
nic0. מידע נוסף זמין במאמר בנושא עורפי קצה של קבוצות מופעים וממשקי רשת.במאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי עם קצוות עורפיים של
GCE_VM_IPNEG, מאזן העומסים מעביר מנות לכרטיס הרשת שתואם לכרטיס הרשת של ה-NEG. מידע נוסף זמין במאמר בנושא קצוות עורפיים של NEG אזוריים וממשקי רשת.אם למכונת קצה עורפי יש ממשק
nic0וממשק אחד או יותר שאינםnic0באותה רשת VPC, מאזן העומסים מעביר חבילות רק לממשק הרשתnic0מתוך קבוצת ממשקי הרשת באותה רשת VPC.
מאזני עומסים פנימיים מסוג העברת תעבורה: לקוחות מתקשרים ישירות עם שרתי קצה עורפיים באמצעות מערך וירטואליזציה של רשת Andromeda. החבילות מנותבות ונמסרות לשרתי קצה עורפיים עם כתובות ה-IP המקוריות של המקור והיעד. בבק-אנד של קבוצת מכונות ובבק-אנד של
GCE_VM_IPNEG, מאזן העומסים מעביר מנות לממשק רשת ברשת ה-VPC של השירות לקצה העורפי:אפשר לציין במפורש את רשת ה-VPC של שירות ה-Backend, או שהיא יכולה להיות מושפעת מקבוצת המופעים הראשונה של השרת העורפי (backend instance) או מ-NEG שנוספו לשירות ה-Backend, או מכלל ההעברה הראשון שמפנה לשירות ה-Backend. מידע נוסף זמין במאמר מפרט של רשת שירותי קצה עורפי.
אם למכונת קצה עורפי יש ממשק
nic0וממשק אחד או יותר שאינםnic0באותה רשת VPC, מאזן העומסים מעביר חבילות רק לממשק הרשתnic0מתוך קבוצת ממשקי הרשת באותה רשת VPC.
יציאות עם שם
המאפיין named port של שירות הקצה העורפי רלוונטי רק למאזני עומסים מבוססי-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כבק-אנד לפחות לשירות בק-אנד אחד, אי אפשר להשתמש באותה קבוצת מופעים כבק-אנד למאזן עומסי רשת מסוג 'העברה בלבד' כי מאזני עומסי רשת מסוג 'העברה בלבד' דורשים את מצב האיזוןCONNECTION.
אין פקודה אחת שיכולה לשנות את מצב האיזון של אותה קבוצת מופעים בכמה שירותי בק-אנד. כדי לשנות את מצב האיזון של קבוצת מכונות שהיא קצה עורפי של שני שירותי קצה עורפי או יותר, אפשר להשתמש בטכניקה הזו:
- מסירים את קבוצת המכונות בתור קצה עורפי מכל השירותים לקצה העורפי, למעט שירות אחד לקצה העורפי.
- משנים את מצב האיזון של קבוצת המכונות לשירות הבק-אנד שנותר.
- מוסיפים מחדש את קבוצת המכונות כקצה עורפי לשירותים האחרים לקצה העורפי.
כדאי ליישם את השיטות המומלצות הבאות, שמציעות אפשרויות גמישות יותר:
מומלץ לא להשתמש באותה קבוצת מופעים כקצה עורפי לשני שירותי קצה עורפי או יותר. במקום זאת, כדאי להשתמש בכמה קבוצות NEG.
בניגוד לקבוצות של מכונות וירטואליות, למכונה וירטואלית יכולה להיות נקודת קצה בשתי קבוצות או יותר של NEGs עם איזון עומסים.
לדוגמה, אם מכונה וירטואלית צריכה להיות קצה עורפי של מאזן עומסי רשת להעברת סיגנל ללא שינוי וגם של מאזן עומסי רשת לשרת proxy או של מאזן עומסים של אפליקציות, צריך להשתמש בכמה קבוצות NEG עם איזון עומסים. ממקמים נקודת קצה של מכונה וירטואלית בקבוצת NEG ייחודית שתואמת לכל סוג של מאזן עומסים. לאחר מכן משייכים כל NEG לשירות הקצה העורפי המתאים של מאזן העומסים.
כשמשתמשים במדד הניצול של איזון עומסים של HTTP לצורך התאמה אוטומטית לעומס, לא מוסיפים קבוצת מופעי מכונה מנוהלים עם התאמה אוטומטית לעומס ליותר משירות לקצה העורפי אחד. שני שירותי קצה עורפי או יותר שמפנים לאותה קבוצת מופעי מכונה מנוהלים עם התאמה אוטומטית לעומס יכולים לסתור זה את זה, אלא אם מדד ההתאמה האוטומטית לעומס לא קשור לפעילות של איזון העומסים.
קבוצות של נקודות קצה ברשת לפי אזור
נקודות קצה ברשת מייצגות שירותים לפי כתובת ה-IP שלהם או לפי כתובת IP ושילוב של יציאה, במקום להתייחס למכונה וירטואלית בקבוצת מופעים. קבוצה של נקודות קצה ברשת (NEG) היא קיבוץ לוגי של נקודות קצה ברשת.
קבוצות אזוריות של נקודות קצה ברשת (NEGs) הן משאבים אזוריים שמייצגים אוספים של כתובות IP או שילובים של כתובות IP ויציאות עבורGoogle Cloud משאבים בתוך תת-רשת אחת.
שירות לקצה העורפי שמשתמש ב-NEGs אזוריים כבק-אנדים שלו מחלק את תעבורת הנתונים בין אפליקציות או קונטיינרים שפועלים בתוך מכונות וירטואליות.
יש שני סוגים של נקודות קצה ברשת שזמינות ל-NEGs אזוריים:
GCE_VM_IPנקודות קצה (נתמכות רק במאזנים פנימיים של עומסי רשת להעברת סיגנל ללא שינוי ובמאזנים אזוריים של עומסי רשת להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי).GCE_VM_IP_PORTנקודות קצה.
כדי לראות אילו מוצרים תומכים בעורפי קצה של NEG אזורי, אפשר לעיין בטבלה: שירותי עורף קצה וסוגי עורף קצה נתמכים.
פרטים נוספים מופיעים במאמר סקירה כללית של קבוצות NEGs אזוריות.
קבוצות של נקודות קצה ברשת באינטרנט
קבוצות NEGs באינטרנט הן משאבים שמגדירים בקצה העורפי חיצוני. שרת קצה עורפי חיצוני הוא שרת קצה עורפי שמארח בתוך תשתית מקומית או בתשתית שמסופקת על ידי צדדים שלישיים.
קבוצת נקודות קצה באינטרנט היא שילוב של שם מארח או כתובת IP, בתוספת יציאה אופציונלית. יש שני סוגים של נקודות קצה ברשת שזמינות לקבוצות של נקודות קצה ברשת באינטרנט: INTERNET_FQDN_PORT ו-INTERNET_IP_PORT.
פרטים נוספים מופיעים במאמר סקירה כללית על קבוצה של נקודות קצה ברשת באינטרנט.
קבוצות של נקודות קצה ברשת בלי שרת (serverless)
קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה בקצה העורפי של מאזן עומסים. קבוצת נקודות קצה (NEG) בלי שרת (serverless) היא בק-אנד שמפנה למשאב Cloud Run, App Engine, פונקציות Cloud Run או API Gateway.
קבוצת נקודות קצה בלי שרת (serverless) יכולה לייצג את אחד מהדברים הבאים:
- משאב 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 Functions או App Engine עם אותו שם.
כדי לראות אילו מאזני עומסים תומכים בקצה עורפי של NEG ללא שרתים, אפשר לעיין בטבלה: שירותים לקצה העורפי וסוגי קצה עורפי נתמכים.
מידע נוסף על NEGs בלי שרת (serverless) זמין במאמר סקירה כללית של קבוצות של נקודות קצה ברשת בלי שרת (serverless).
כבילות שירות ב-Service Directory
קישור שירות של Service Directory הוא משאב בקצה העורפי שיוצר חיבור בין שירות בקצה העורפי ב-Cloud Service Mesh לבין שירות שרשום ב-Service Directory. שירות לקצה העורפי יכול להפנות לכמה קשרי שירות של Service Directory. עם זאת, שירות קצה עורפי עם שירות Service Directory לא יכול להפנות לשום סוג אחר של משאב קצה עורפי. מידע נוסף זמין במאמר בנושא שילוב של Cloud Service Mesh עם Service Directory.
קצה עורפי של שירות שפורסם
אם רשתות ה-VPC של הספק והצרכן שייכות לאותו ארגון, אפשר לגשת לשירות שפורסם באמצעות קצה עורפי של שירות שפורסם. בק-אנדים של שירותים שפורסמו מאפשרים לכם להגדיר מאזני עומסים נתמכים או Cloud Service Mesh כדי לנתב תנועה לשירותים שפורסמו דרך נקודות קצה של Private Service Connect. כדי להפנות תנועה לשירות שפורסם, משייכים שירות לקצה עורפי אזורי לחיבור שירות. ההגדרה הזו נקראת קצה עורפי של שירות שפורסם.
הבק-אנדים האלה מספקים קישוריות מאוחדת בכך שהם מאפשרים למאזני עומסים נתמכים ול-Cloud Service Mesh לשתף נקודות קצה של Private Service Connect. כדי ליצור את החיבור הזה, צריך לספק הפניה לקובץ המצורף של השירות של הבעלים של השירות המנוהל. בנוסף, קצה עורפי של שירותים שפורסמו מאפשר ניהול מתקדם של תעבורת נתונים וניטור, כמו אכיפה של מדיניות אבטחה מרכזית ואיסוף של מדדים מרכזיים.
מידע נוסף על הגדרת עורפי קצה של שירותים שפורסמו עבור מאזני עומסים זמין במאמר גישה לשירותים שפורסמו דרך עורפי קצה ונקודות קצה של שירותים שפורסמו.
קצוות עורפיים מעורבים
כשמוסיפים סוגים שונים של שרתי קצה עורפיים לשירות קצה עורפי יחיד, צריך להביא בחשבון את שיקולי השימוש הבאים:
- שירות לקצה העורפי יחיד לא יכול להשתמש בו-זמנית גם בקבוצות של מופעים וגם ב-NEGs אזוריים.
- אפשר להשתמש בשילוב של סוגים שונים של קבוצות מופעים באותו שירות קצה עורפי. לדוגמה, שירות קצה עורפי יחיד יכול להפנות לשילוב של קבוצות מנוהלות ולא מנוהלות של מכונות. למידע מלא על שירותי קצה עורפי שמתאימים לקצה העורפי, אפשר לעיין בטבלה שבקטע הקודם.
- עם מאזני עומסים מסוימים של פרוקסי, אפשר להשתמש בשילוב של NEGs אזוריים (עם נקודות קצה של
GCE_VM_IP_PORT) ו-NEGs של קישוריות היברידית (עם נקודות קצה שלNON_GCP_PRIVATE_IP_PORT) כדי להגדיר איזון עומסים היברידי. כדי לראות אילו מאזני עומסים כוללים את היכולת הזו, אפשר לעיין בטבלה: שירותי בק-אנד וסוגי בק-אנד נתמכים.
הפרוטוקול לקצה העורפי
כשיוצרים שירות קצה עורפי, צריך לציין את הפרוטוקול שמשמש לתקשורת עם הקצוות העורפיים. אפשר לציין רק פרוטוקול אחד לכל שירות backend – אי אפשר לציין פרוטוקול משני לשימוש כגיבוי.
הפרוטוקולים התקפים תלויים בסוג מאזן העומסים או בשאלה אם אתם משתמשים ב-Cloud Service Mesh.
| מוצר | אפשרויות פרוטוקול של שירות לקצה העורפי |
|---|---|
| Application Load Balancer | 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 בלבד
ואתם בוחרים באפשרות |
הצפנה בין מאזן העומסים לבין הקצוות העורפיים
מידע על הצפנה בין מאזן העומסים לבין השרתים העורפיים זמין במאמר בנושא הצפנה לשרתים העורפיים.
מצב איזון, קיבולת יעד ושינוי קיבולת
במאזני עומסים של אפליקציות, ב-Cloud Service Mesh ובמאזני עומסי רשת בשרת proxy, מצב האיזון, קיבולת היעד והתאמת הקיבולת הם פרמטרים שאתם מספקים כשאתם מוסיפים קצה עורפי נתמך לשירות לקצה העורפי. מאזני העומסים משתמשים בפרמטרים האלה כדי לנהל את ההפצה של בקשות חדשות או חיבורים חדשים לאזורים שמכילים קצוות עורפיים נתמכים:
- מצב האיזון מגדיר איך מאזן העומסים מודד את הקיבולת.
ב-Google Cloud יש את מצבי האיזון הבאים:
-
CONNECTION: מגדיר את הקיבולת על סמך מספר חיבורי ה-TCP החדשים. -
RATE: הגדרת הקיבולת על סמך קצב בקשות ה-HTTP החדשות. -
IN-FLIGHT: מגדיר את הקיבולת על סמך מספר בקשות ה-HTTP הפעילות במקום על סמך קצב בקשות ה-HTTP. כדאי להשתמש במצב האיזון הזה במקום במצבRATEאם השלמת הבקשות נמשכת יותר משנייה אחת. -
UTILIZATION: הגדרה של הקיבולת על סמך ניצול ה-CPU המשוער של מכונות וירטואליות באזור של קבוצת מכונות. -
CUSTOM_METRICS: מגדיר את הקיבולת על סמך מדדים מותאמים אישית שהוגדרו על ידי המשתמש.
-
- המאפיין target capacity מגדיר את מספר קיבולת היעד.
- קיבולת היעד לא משמשת כמפסק.
- כשניצול הקיבולת מגיע לקיבולת היעד, מאזן העומסים מפנה בקשות חדשות או חיבורים חדשים לאזור אחר, אם קצוות העורף מוגדרים בשני אזורים או יותר.
- מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), מאזני עומסים גלובליים חיצוניים של רשתות proxy, מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים ומאזני עומסים פנימיים של רשתות proxy חוצי-אזורים משתמשים גם הם בקיבולת כדי להפנות בקשות לאזורים באזורים שונים, אם הגדרתם בק-אנד ביותר מאזור אחד.
- כשכל האזורים מגיעים לקיבולת היעד, המערכת מחלקת את הבקשות החדשות או החיבורים החדשים על ידי מילוי יתר באופן יחסי.
- כלי להגדלת הקיבולת מאפשר להגדיל את קיבולת היעד באופן ידני.
הערכים של קנה המידה של הקיבולת הם:
-
0: מציין שהקצה העורפי ריק לחלוטין. אי אפשר להשתמש בערך0אם לשירות העורפי יש רק עורף אחד. -
0.1(10%) –1.0(100%): מציין את אחוז הקיבולת של העורף שנעשה בו שימוש.
-
מאזני עומסי רשת להעברת סיגנל ללא שינוי משתמשים באופן סמלי במצב איזון CONNECTION, אבל לא תומכים בקיבולת יעד או בשינוי קיבולת. מידע נוסף על האופן שבו מאזני עומסי רשת להעברת סיגנל ללא שינוי מחלקים חיבורים חדשים זמין במאמרים הבאים:
- חלוקת התנועה במאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי
- חלוקת התנועה במאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי
שרתי קצה עורפיים נתמכים
במאזני עומסים של אפליקציות, ב-Cloud Service Mesh ובמאזני עומסי רשת בשרת proxy, סוגי הקצה העורפי הבאים תומכים בפרמטרים של מצב איזון, קיבולת יעד ושינוי קיבולת:
- בקצה העורפי של קבוצות של מכונות
- קבוצות אזוריות של נקודות קצה ברשת (NEGs) עם
GCE_VM_IP_PORTנקודות קצה - Zonal hybrid connectivity NEGs
NEGs של אינטרנט, NEGs של serverless ו-NEGs של Private Service Connect לא תומכים בפרמטרים של מצב איזון, קיבולת יעד ושינוי קיבולת.
מצבי איזון למאזני עומסים של אפליקציות (ALB) ול-Cloud Service Mesh
מצבי האיזון שזמינים לקצה העורפי של מאזן עומסים של אפליקציות ושל Cloud Service Mesh תלויים בסוג הקצה העורפי הנתמך ובהגדרה של משך התנועה.
הגדרת משך הזמן של התנועה
בשרתי קצה עורפיים של Application Load Balancer ו-Cloud Service Mesh, אפשר גם לציין הגדרה של משך התנועה. ההגדרה הזו ייחודית למיפוי בין קצה עורפי נתמך לבין שירות קצה עורפי. להגדרת משך התנועה יש שני ערכים תקינים:
-
SHORT: מומלץ לבקשות HTTP שהתשובות עליהן מגיעות מהשרתים העורפיים תוך פחות משנייה. אם לא מציינים במפורש את משך התנועה, מאזן העומסים פועל כאילו צויןSHORT. -
LONG: מומלץ לבקשות HTTP שבהן לשרת העורפי נדרשת יותר משנייה אחת כדי ליצור תגובות.
כדי להגדיר באופן מפורש את משך התנועה כשמוסיפים קצה עורפי לשירות קצה עורפי, מבצעים אחת מהפעולות הבאות:
- מריצים את הפקודה
gcloud compute backend-services add-backendעם הדגל--traffic-duration. - יוצרים שירות לקצה העורפי או מעדכנים שירות לקצה העורפי באמצעות
trafficDuration.
מצבי איזון למשך תנועה קצר
אם לא מציינים את הגדרת משך התעבורה או אם היא מוגדרת ל-SHORT, מצבי האיזון שזמינים עבור מאזני עומסים של אפליקציות וקצוות עורפיים של Cloud Service Mesh תלויים בסוג הקצה העורפי הנתמך.
| קצה עורפי נתמך | מצב איזון | ||||
|---|---|---|---|---|---|
CONNECTION |
RATE |
IN_FLIGHT |
UTILIZATION |
CUSTOM_METRICS |
|
| קבוצות של מכונות | |||||
NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
|||||
| NEGs אזוריים של קישוריות היברידית | |||||
מצבי איזון למשכי תנועה ארוכים
כשההגדרה של משך התעבורה היא LONG, מצבי האיזון שזמינים לקצה העורפי של מאזן העומסים של האפליקציה ושל Cloud Service Mesh תלויים בסוג הקצה העורפי הנתמך.
| קצה עורפי נתמך | מצב איזון | ||||
|---|---|---|---|---|---|
CONNECTION |
RATE |
IN_FLIGHT |
UTILIZATION |
CUSTOM_METRICS |
|
| קבוצות של מכונות | |||||
NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
|||||
| NEGs אזוריים של קישוריות היברידית | |||||
מצבי איזון למאזני עומסים של רשת בשרת proxy
מצבי האיזון שזמינים לבק-אנד של מאזן עומסי רשת לשרת proxy תלויים בסוג הבק-אנד הנתמך.
| קצה עורפי נתמך | מצב איזון | ||||
|---|---|---|---|---|---|
CONNECTION |
RATE |
IN_FLIGHT |
UTILIZATION |
CUSTOM_METRICS |
|
| קבוצות של מכונות | |||||
NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
|||||
| NEGs אזוריים של קישוריות היברידית | |||||
מפרטים של קיבולת היעד
הגדרות קיבולת היעד רלוונטיות למאזן עומסים של אפליקציות, ל-Cloud Service Mesh ולשרתי proxy לקצה העורפי של מאזן עומסי רשת שתומכים בהגדרות של מצב איזון, קיבולת יעד והתאמת קיבולת.
מפרטי קיבולת היעד לא רלוונטיים למאזני עומסי רשת להעברת סיגנל ללא שינוי.
מצב איזון החיבור
שרתי קצה עורפיים של מאזן עומסי רשת מסוג Proxy Network Load Balancer יכולים להשתמש במצב האיזון CONNECTION עם אחד מהפרמטרים הנדרשים הבאים של קיבולת היעד:
| פרמטר של קיבולת היעד | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | 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 מחשב את קיבולת היעד לכל תחום (zone) בכל תחום (zone) של קבוצת מופעי המכונה. בכל אזור, אם יש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.
- אם מגדירים את
מצב איזון שיעורים
בקצה העורפי של Application Load Balancer ו-Cloud Service Mesh עם הגדרה של משך תנועה לא מוגדר או קצר, אפשר להשתמש במצב איזון RATE עם אחד מהפרמטרים הנדרשים הבאים של קיבולת היעד:
| פרמטר של קיבולת היעד | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
max-rateקצב בקשות HTTP ליעד לכל אזור קצה עורפי |
||||
max-rate-per-instanceיעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד. |
||||
max-rate-per-endpointקצב בקשות HTTP ליעד לכל נקודת קצה של 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 מחשב את קיבולת היעד לכל תחום (zone) בכל תחום (zone) של קבוצת מופעי המכונה. בכל אזור, אם יש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 עם אחד מהפרמטרים הבאים של קיבולת היעד הנדרשת:
| פרמטר של קיבולת היעד | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
max-in-flight-requestsמספר היעד של בקשות HTTP בתהליך לכל אזור עורפי |
||||
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 מחשב את קיבולת היעד לכל תחום (zone) בכל תחום (zone) של קבוצת המופעים. בכל אזור, אם יש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אם שיעור הניצול הממוצע של כל המכונות הווירטואליות שמשויכות לשירות קצה עורפי נמוך מ-10%, מאזן העומסים הופך לרגיש מאוד לשינויים קלים בתנועת הגולשים. לכן, צפוי חוסר איזון מסוים בתנועת הגולשים, ושינויים קלים בעומס יכולים לגרום לשינוי בחלוקת תנועת הגולשים בין השרתים השונים.
UTILIZATION למצב איזון אין הגדרת קיבולת יעד חובה, אבל אפשר להגדיר קיבולת יעד באמצעות אחד מפרמטרים של קיבולת היעד או שילובים של פרמטרים של קיבולת היעד שמתוארים בקטעים הבאים.
פרמטרים של קיבולת יעד לניצול עבור עורפי קצה של Application Load Balancer ו-Cloud Service Mesh עם הגדרה לא מוגדרת או קצרה של משך התנועה
בקצה העורפי של מאזן העומסים של האפליקציה ושל Cloud Service Mesh עם הגדרה של משך תנועה לא מוגדר או קצר, אפשר להשתמש במצב איזון UTILIZATION עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:
| פרמטר או שילוב פרמטרים של קיבולת יעד | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
max-utilizationשיעור הניצול של כל אזור קצה עורפי |
||||
max-rateקצב בקשות HTTP ליעד לכל אזור קצה עורפי |
||||
max-rate ו-max-utilizationהיעד הוא הראשון שאליו מגיעים באזור העורפי:
|
||||
max-rate-per-instanceיעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד. |
||||
max-rate-per-instance וגם
max-utilizationהיעד הוא הראשון שהושג באזור העורפי:
|
||||
מידע נוסף על פרמטרים של קיבולת יעד max-rate ו-max-rate-per-instance זמין בקטע מצב איזון קצב במאמר הזה.
פרמטרים של קיבולת יעד לניצול עבור מאזן עומסים של אפליקציות וקצה עורפי של Cloud Service Mesh עם הגדרה של משך תנועה ארוך
בק-אנד של Application Load Balancer ו-Cloud Service Mesh עם הגדרה ארוכה של משך התנועה יכולים להשתמש במצב איזון UTILIZATION עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:
| פרמטר או שילוב פרמטרים של קיבולת טירגוט | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
max-utilizationשיעור הניצול של כל אזור קצה עורפי |
||||
max-in-flight-requestsמספר היעד של בקשות HTTP בתהליך לכל אזור עורפי |
||||
max-in-flight-requests ו-max-utilizationהיעד הוא הראשון שאליו מגיעים באזור העורפי:
|
||||
max-in-flight-requests-per-instanceמספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד. |
||||
max-in-flight-requests-per-instance וגם
max-utilizationהיעד הוא הראשון שהושג באזור העורפי:
|
||||
max-in-flight-requests ו-max-in-flight-requests-per-instance של קיבולת היעד מופיע בקטע מצב איזון בזמן ההעברה במסמך הזה.
פרמטרים של קיבולת יעד לניצול למאזני עומסי רשת בשרת proxy
בקצה העורפי של מאזני עומסים מסוג proxy לרשת, אפשר להשתמש בפרמטר UTILIZATION balancing mode עם אחד מפרמטרים או שילובים של פרמטרים של קיבולת היעד הבאים.
| פרמטר או שילוב פרמטרים של קיבולת יעד | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
max-utilizationשיעור הניצול של כל אזור קצה עורפי |
||||
max-connectionsחיבורי TCP ליעד לכל אזור קצה עורפי |
||||
max-connections ו-max-utilizationהיעד הוא הראשון שאליו מגיעים באזור העורפי:
|
||||
max-connections-per-instanceחיבורי TCP ליעד לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר חיבורי ה-TCP ליעד בכל אזור קצה עורפי. |
||||
max-connections-per-instance and
max-utilizationTarget is the first to be reached in the backend zone:
|
||||
מידע נוסף על פרמטרים של קיבולת יעד max-connections ו-max-connections-per-instance זמין בקטע מצב איזון חיבורים במאמר הזה.
מצב איזון של מדדים מותאמים אישית
בקצה העורפי של מאזן עומסים של אפליקציות ומאזן עומסי רשת בשרת proxy אפשר להשתמש במצב איזון CUSTOM_METRICS. מדדים בהתאמה אישית מאפשרים לכם להגדיר קיבולת יעד על סמך נתוני אפליקציה או תשתית שהכי חשובים לכם. מידע נוסף זמין במאמר בנושא מדדים מותאמים אישית עבור מאזני עומסים של אפליקציות.
לCUSTOM_METRICS מצב איזון אין הגדרת קיבולת יעד חובה, אבל אפשר להגדיר קיבולת יעד באמצעות אחד מפרמטרים של קיבולת יעד או שילובים של פרמטרים של קיבולת יעד שמתוארים בקטעים הבאים.
מדדים מותאמים אישית לפרמטרים של קיבולת יעד לשרתי קצה עורפיים של מאזן עומסים של אפליקציות (ALB) עם הגדרה לא מוגדרת או קצרה של משך התנועה
בקצה העורפי של מאזן העומסים של האפליקציה עם הגדרה של משך תנועה לא מוגדר או קצר, אפשר להשתמש במצב איזון CUSTOM_METRICS עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:
| פרמטר או שילוב פרמטרים של קיבולת טירגוט | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
backends[].customMetrics[].maxUtilizationTarget custom metric utilization per backend zone |
||||
max-rateקצב בקשות HTTP ליעד לכל אזור קצה עורפי |
||||
max-rate וגם
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שהושג באזור העורפי:
|
||||
max-rate-per-instanceיעד קצב בקשות ה-HTTP לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד. |
||||
max-rate-per-instance וגם
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שהושג באזור העורפי:
|
||||
max-rate-per-endpointקצב בקשות HTTP ליעד לכל נקודת קצה של NEG. Cloud Load Balancing משתמש בפרמטר הזה כדי לחשב את קצב הבקשות של HTTP ליעד לכל אזור בק-אנד. |
||||
max-rate-per-endpoint ו-
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שאליו מגיעים באזור העורפי:
|
||||
מידע נוסף על פרמטרים של קיבולת יעד max-rate, max-rate-per-instance ו-max-rate-per-endpoint זמין בקטע מצב איזון קצב במסמך הזה.
פרמטרים של קיבולת יעד של מדדים מותאמים אישית לעורפי תנועה של מאזן עומסים של אפליקציות עם הגדרה של משך תנועה ארוך
בקצה העורפי של מאזן עומסים של אפליקציות עם הגדרה ארוכה של משך התנועה אפשר להשתמש במצב האיזון CUSTOM_METRICS עם אחד מהפרמטרים הבאים של קיבולת היעד או עם שילוב של פרמטרים:
| פרמטר או שילוב פרמטרים של קיבולת טירגוט | קצה עורפי נתמך | |||
|---|---|---|---|---|
| קבוצות מופעי מכונה אזוריות (מנוהלות או לא מנוהלות) | קבוצות אזוריות של מופעי מכונה מנוהלים | NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה |
NEGs אזוריים של קישוריות היברידית | |
backends[].customMetrics[].maxUtilizationTarget custom metric utilization per backend zone |
||||
max-in-flight-requestsמספר היעד של בקשות HTTP בתהליך לכל אזור עורפי |
||||
max-in-flight-requests וגם
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שמושג באזור העורפי:
|
||||
max-in-flight-requests-per-instanceמספר היעד של בקשות HTTP בתהליך לכל מכונה וירטואלית. מערכת Cloud Load Balancing משתמשת בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד. |
||||
max-in-flight-requests-per-instance וגם
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שהושג באזור העורפי:
|
||||
max-in-flight-requests-per-endpointמספר היעד של בקשות HTTP בתהליך לכל נקודת קצה של NEG. מאזן העומסים משתמש בפרמטר הזה כדי לחשב את מספר היעד של בקשות HTTP בתהליך לכל אזור בק-אנד. |
||||
max-in-flight-requests-per-endpoint ו-
backends[].customMetrics[].maxUtilizationהיעד הוא הראשון שאליו מגיעים באזור העורפי:
|
||||
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. Maglev לא יציב כמוRING_HASHאבל הוא מאפשר לבנות טבלאות מהר יותר ולבחור מארחים מהר יותר. מידע נוסף על Maglev זמין במאמר הטכני בנושא Maglev.
WEIGHTED_MAGLEV: הטמעה של איזון עומסים אזורי חיצוני להעברת סיגנל ללא שינוי ברשת לפי משקל לכל מכונה, באמצעות משקלים שמדווחים על ידי בדיקות תקינות. אם משתמשים במדיניות הזו, שירות לקצה העורפי צריך להגדיר בדיקת תקינות מבוססת-HTTP שאינה מדור קודם, ותשובות בדיקת התקינות צפויות להכיל את שדה כותרת התגובה של HTTP שאינו סטנדרטי,X-Load-Balancing-Endpoint-Weight, כדי לציין את המשקלים לכל מופע. ההחלטות לגבי איזון העומסים מתקבלות על סמך המשקלים לכל מופע שמדווחים בתשובות האחרונות לבדיקת התקינות שעובדו, כל עוד כל מופע מדווח על משקל תקין או עלUNAVAILABLE_WEIGHT. אחרת, איזון העומסים יישאר שווה.לדוגמה, אפשר לעיין במאמר הגדרת איזון עומסים לפי משקל למאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי.
WEIGHTED_ROUND_ROBIN: מאזן העומסים משתמש במדדים מותאמים אישית שהוגדרו על ידי המשתמש כדי לבחור את המופע או נקודת הקצה האופטימליים בעורף שיטפלו בבקשה.
| מאזן עומסים | אפשרויות של מדיניות מקומית לאיזון עומסים |
|---|---|
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים מאזן עומסים פנימי אזורי של אפליקציות (ALB) |
אפשרויות נתמכות:
|
מאזן עומסי רשת גלובלי חיצוני בשרת proxy מאזן עומסי רשת אזורי חיצוני בשרת proxy מאזן עומסי רשת פנימי בשרת proxy שפועל בכמה אזורים מאזן עומסי רשת אזורי פנימי בשרת proxy |
אפשרויות נתמכות:
|
| מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי | אפשרויות נתמכות:
|
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מאזן עומסים קלאסי של אפליקציות (ALB) מאזן עומסי רשת קלאסי בשרת proxy |
לא נתמך |
הערה: ערך ברירת המחדל האפקטיבי של מדיניות המיקום של איזון העומסים (localityLbPolicy) משתנה בהתאם להגדרות של זיקה לסשן (session affinity). אם לא מגדירים את הזיקה לסשן – כלומר, אם הזיקה לסשן נשארת בערך ברירת המחדל NONE – ערך ברירת המחדל של localityLbPolicy הוא ROUND_ROBIN. אם זיקת הסשן מוגדרת לערך שאינו NONE, ערך ברירת המחדל של localityLbPolicy הוא MAGLEV.
כדי להגדיר מדיניות מקומית לאיזון עומסים, אפשר להשתמש במסוףGoogle Cloud , ב-gcloud (--locality-lb-policy) או ב-API (localityLbPolicy).
חלוקת משנה של הקצה העורפי
חלוקה לקבוצות משנה בעורף המערכת היא תכונה אופציונלית שמשפרת את הביצועים ואת יכולת ההתאמה לגדילה על ידי הקצאת קבוצת משנה של שרתים עורפיים לכל אחד ממופעי ה-proxy.
אפשר להשתמש בחלוקה לקבוצות משנה בקצה העורפי במקרים הבאים:
- מאזן עומסים פנימי אזורי של אפליקציות (ALB)
- מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי
חלוקה לקבוצות משנה של קצה עורפי למאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
מאזן העומסים הפנימי של אפליקציות (ALB) בין אזורים לא תומך בחלוקת קצה העורף לקבוצות משנה.במאזני עומסים פנימיים אזוריים של אפליקציות, חלוקת המשנה של הקצה העורפי מקצה באופן אוטומטי רק קבוצת משנה של הקצה העורפי בשירות הקצה העורפי האזורי לכל מופע של שרת proxy. כברירת מחדל, כל מופע של שרת proxy פותח חיבורים לכל השרתים העורפיים בשירות לקצה העורפי. אם מספר מופעי ה-proxy ומספר ה-backends גדולים, פתיחת חיבורים לכל ה-backends עלולה לגרום לבעיות בביצועים.
אם מפעילים את התכונה subsetting, כל שרת proxy פותח חיבורים רק לחלק ממסדי הנתונים, וכך מצטמצם מספר החיבורים שנשארים פתוחים לכל מסד נתונים. צמצום מספר החיבורים הפתוחים בו-זמנית לכל שרת קצה עורפי יכול לשפר את הביצועים של שרתי הקצה העורפי ושל שרתי ה-proxy.
התרשים הבא מציג מאזן עומסים עם שני שרתי proxy. בלי חלוקת משנה של קצה עורפי, התנועה משני ה-proxy מופצת לכל הקצוות העורפיים בשירות הקצה העורפי 1. כשהאפשרות 'חלוקת משנה של שרתים עורפיים' מופעלת, התנועה מכל שרת proxy מופצת לקבוצת משנה של השרתים העורפיים. התנועה משרת ה-proxy מספר 1 מופצת לעורפי הקצה מספר 1 ו-2, והתנועה משרת ה-proxy מספר 2 מופצת לעורפי הקצה מספר 3 ו-4.
בנוסף, אפשר לחדד את התנועה של איזון העומסים לשרתי הקצה על ידי הגדרת המדיניות localityLbPolicy.
מידע נוסף זמין במאמר בנושא מדיניות בנושא תנועה.
במאמר הגדרת חלוקת משנה של קצה עורפי מוסבר איך להגדיר חלוקת משנה של קצה עורפי למאזני עומסים פנימיים של אפליקציות.
הערות לגבי חלוקת קצה עורפי לקבוצות משנה במאזן עומסים של אפליקציות (ALB) פנימי
- למרות שהחלוקה לקבוצות משנה בעורף נועדה לוודא שכל המופעים בעורף ימשיכו להיות בשימוש יעיל, היא עלולה להוביל להטיה מסוימת בכמות התנועה שכל עורף מקבל. מומלץ להגדיר את
localityLbPolicyל-LEAST_REQUESTבשירותים לקצה העורפי שרגישים לאיזון של עומס הקצה העורפי. - הפעלה או השבתה של יצירת קבוצת משנה משבשות קישורים קיימים.
- כדי לבצע חלוקה לקבוצות משנה בקצה העורפי, צריך להגדיר את הזיקה לסשן (session affinity) ל-
NONE(גיבוב של 5 טאפלים). אפשר להשתמש באפשרויות אחרות של זיקה לסשן (session affinity) רק אם השבתתם את חלוקת ה-backend לקבוצות משנה. ערכי ברירת המחדל של הדגלים--subsetting-policyו---session-affinityהםNONE, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.
חלוקה לקבוצות משנה של קצה עורפי במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי
חלוקת קצה עורפי למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי מאפשרת להגדיל את מאזן העומסים הפנימי להעברת סיגנל ללא שינוי כדי לתמוך במספר גדול יותר של מכונות וירטואליות בקצה העורפי לכל שירות קצה עורפי פנימי.
מידע על ההשפעה של יצירת קבוצת משנה על המגבלה הזו מופיע בעמודה מכסות ומגבלות בטבלה שירותי קצה עורפי.
כברירת מחדל, האפשרות 'חלוקה לקבוצות משנה' מושבתת, מה שמגביל את שירות הקצה העורפי לחלוקה לעד 250 מופעים או נקודות קצה של קצה עורפי. אם שירות ה-Backend שלכם צריך לתמוך ביותר מ-250 שירותי Backend, אתם יכולים להפעיל חלוקה לקבוצות משנה. כשהאפשרות 'חלוקה לקבוצות משנה' מופעלת, נבחרת קבוצת משנה של מופעי קצה עורפיים לכל חיבור לקוח.
בתרשים הבא מוצג מודל מוקטן של ההבדל בין שני מצבי הפעולה האלה.
בלי חלוקה לקבוצות משנה, נעשה שימוש טוב יותר בכל השרתים העורפיים התקינים, וחיבורים חדשים של לקוחות מחולקים בין כל השרתים העורפיים התקינים בהתאם לחלוקת התנועה. הגדרת קבוצת משנה מטילה הגבלות על איזון העומסים, אבל מאפשרת למאזן העומסים לתמוך ביותר מ-250 שרתים עורפיים.
הוראות להגדרה מופיעות במאמר Subsetting.
הערות לגבי חלוקת משנה של קצה עורפי במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי
- כשהתכונה 'חלוקה לקבוצות משנה' מופעלת, לא כל השרתים העורפיים יקבלו תנועה משולח מסוים, גם אם מספר השרתים העורפיים קטן.
- למספר המקסימלי של מופעי קצה עורפיים כשמופעלת חלוקה לקבוצות משנה, אפשר לעיין בדף המכסות .
- יש תמיכה רק ב-5-tuple session affinity עם חלוקה לקבוצות משנה.
- אין תמיכה בשיקוף מנות עם יצירת קבוצת משנה.
- הפעלה או השבתה של יצירת קבוצת משנה משבשות קישורים קיימים.
- אם לקוחות מקומיים צריכים לגשת למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שימוש בתת-קבוצה יכול לצמצם באופן משמעותי את מספר השרתים העורפיים שמקבלים חיבורים מהלקוחות המקומיים. הסיבה לכך היא שהאזור של מנהרת Cloud VPN או של חיבור ה-VLAN של Cloud Interconnect קובע את קבוצת המשנה של השרתים העורפיים של מאזן העומסים. כל נקודות הקצה של Cloud VPN ו-Cloud Interconnect באזור מסוים משתמשות באותה קבוצת משנה. באזורים שונים משתמשים בקבוצות משנה שונות.
תמחור של חלוקה לקבוצות משנה בקצה העורפי
אין חיוב על שימוש בחלוקה לקבוצות משנה בקצה העורפי. מידע נוסף זמין במאמר בנושא כל המחירים של שירותי הרשת.
זיקה לסשן (session affinity)
זיקה לסשן מאפשרת לכם לשלוט באופן שבו מאזן העומסים בוחר בקצה העורפי לחיבורים חדשים בצורה צפויה, כל עוד מספר הקצוות העורפיים התקינים נשאר קבוע. זה שימושי לאפליקציות שצריכות להפנות בקשות מרובות ממשתמש נתון לאותו בק-אנד או לאותה נקודת קצה. אפליקציות כאלה כוללות בדרך כלל שרתים עם מצב (stateful) שמשמשים להצגת מודעות, למשחקים או לשירותים עם שמירת נתונים במטמון פנימי.
Google Cloud מאזני עומסים מספקים זיקה לסשן על בסיס האפשרות הטובה ביותר. גורמים כמו שינוי במצבי בדיקת תקינות של בק-אנד, הוספה או הסרה של בק-אנד, שינויים במשקלים של בק-אנד (כולל הפעלה או השבתה של איזון משוקלל) או שינויים בקיבולת של בק-אנד, כפי שנמדדת על ידי מצב האיזון, עלולים לשבור את זיקה לסשן (session affinity).
איזון עומסים עם זיקה לסשן פועל בצורה טובה כשיש פיזור גדול יחסית של חיבורים ייחודיים. גדול מספיק פירושו לפחות פי כמה ממספר השרתים העורפיים. בדיקת מאזן עומסים עם מספר קטן של חיבורים לא תניב ייצוג מדויק של חלוקת חיבורי הלקוח בין שרתי קצה עורפיים.
כברירת מחדל, כל מאזני העומסים בוחרים את השרתים העורפיים באמצעות גיבוב של חמישה ערכים (--session-affinity=NONE), באופן הבא: Google Cloud
- כתובת ה-IP של המקור של חבילת הנתונים
- יציאת המקור של המנה (אם היא מופיעה בכותרת של המנה)
- כתובת ה-IP של היעד של חבילת הנתונים
- יציאת היעד של המנה (אם היא מופיעה בכותרת של המנה)
- הפרוטוקול של חבילת הנתונים
מידע נוסף על זיקה לסשן (session affinity) במאזני עומסים מסוג Network Load Balancer להעברת סיגנל ללא שינוי זמין במאמרי עזרה הבאים:
- חלוקת התנועה במאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי
- חלוקת התנועה למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי
מידע נוסף על זיקה לסשן (session affinity) למאזני עומסים של אפליקציות זמין במאמרים הבאים:
- זיקה לסשן (session affinity) למאזני עומסים חיצוניים של אפליקציות (ALB)
- זיקה לסשן (session affinity) למאזני עומסים פנימיים של אפליקציות (ALB)
מידע נוסף על זיקה לסשן (session affinity) למאזני עומסים של רשתות proxy זמין במאמרים הבאים:
- זיקה לסשן (session affinity) למאזנים חיצוניים של עומסי רשת בשרת proxy
- זיקה לסשן (session affinity) למאזני עומסי רשת פנימיים של שרת proxy
זמן קצוב לתפוגה של שירות לקצה העורפי
לרוב Google Cloud מאזני העומסים יש זמן קצוב לתפוגה של שירות לקצה העורפי. ערך ברירת המחדל הוא 30 שניות. טווח הערכים המלא של הזמן הקצוב לתפוגה הוא 1 עד 2,147,483,647 שניות.
במאזני עומסים חיצוניים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות שמשתמשים בפרוטוקול HTTP, HTTPS או HTTP/2, פסק הזמן של שירות הקצה העורפי הוא פסק זמן של בקשה ותגובה לתנועת HTTP(S).
פרטים נוספים על הזמן הקצוב לתפוגה של שירות הקצה העורפי בכל מאזן עומסים מפורטים במאמרים הבאים:
- במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), אפשר לעיין במאמר בנושא פסק זמן וניסיונות חוזרים.
- במאזני עומסים פנימיים של אפליקציות, אפשר לעיין במאמר בנושא פסק זמן וניסיונות חוזרים.
במאזנים חיצוניים של עומסי רשת בשרת proxy ובמאזנים פנימיים של עומסי רשת בשרת proxy, הזמן הקצוב לתפוגה של שירות הקצה העורפי שהוגדר הוא משך הזמן שבו מאזן העומסים שומר על חיבור ה-TCP פתוח, אם לא מועברים נתונים מהלקוח או מהקצה העורפי. אם לא מועברים נתונים במשך הזמן הזה, ה-proxy סוגר את החיבור.
- ערך ברירת המחדל: 30 שניות
- טווח שניתן להגדרה: 1 עד 2,147,483,647 שניות
במאזני עומסים פנימיים של רשת להעברת סיגנל ללא שינוי ובמאזני עומסים אזוריים של רשת להעברת סיגנל ללא שינוי, אפשר להגדיר את ערך הזמן הקצוב לתפוגה של שירות הקצה העורפי באמצעות
gcloudאו ה-API, אבל המערכת מתעלמת מהערך. לפסק זמן של שירות קצה עורפי אין משמעות במאזני עומסים מסוג pass-through.
- ב-Cloud Service Mesh, שדה הזמן הקצוב לתפוגה של שירות הקצה העורפי (שמצוין באמצעות
timeoutSec) לא נתמך בשירותי gRPC ללא proxy. בשירותים כאלה, מגדירים את פסק הזמן של השירות לקצה העורפי באמצעות השדהmaxStreamDuration. הסיבה לכך היא ש-gRPC לא תומך בסמנטיקה שלtimeoutSecשמציינת את משך הזמן להמתנה עד שהבק-אנד יחזיר תגובה מלאה אחרי שליחת הבקשה. זמן קצוב לתפוגה של gRPC מציין את משך הזמן להמתנה מתחילת הזרם עד שהתגובה תעבור עיבוד מלא, כולל כל הניסיונות החוזרים.
בדיקות תקינות
לכל שירות קצה עורפי שהקצוות העורפיים שלו הם קבוצות של מכונות וירטואליות או NEGs אזוריים, צריך להיות משויך בדיקת תקינות. שירותי קצה עורפי שמשתמשים ב-NEG בלי שרת או ב-NEG גלובלי לאינטרנט כקצה עורפי לא יכולים להפנות לבדיקת תקינות.
כשיוצרים מאזן עומסים באמצעות מסוף Google Cloud , אפשר ליצור את בדיקת התקינות, אם היא נדרשת, כשיוצרים את מאזן העומסים, או שאפשר להפנות לבדיקת תקינות קיימת.
כשיוצרים שירות backend באמצעות קבוצת מופעים או בקצה העורפי של NEG אזורי באמצעות Google Cloud CLI או API, צריך להפנות לבדיקת תקינות קיימת. פרטים על הסוג וההיקף של בדיקת התקינות הנדרשת מופיעים במדריך בנושא מאזן עומסים בסקירה הכללית על בדיקות תקינות.
מידע נוסף זמין במאמרים הבאים:
- סקירה כללית על בדיקות תקינות
- יצירת בדיקות תקינות
gcloudדף בדיקת התקינות- דף בדיקת תקינות של API בארכיטקטורת REST
תכונות נוספות שמופעלות במשאב של שירות לקצה העורפי
חלק משירותי ה-Backend תומכים בתכונות האופציונליות הבאות.
Cloud CDN
רשת Cloud CDN משתמשת ברשת הקצה הגלובלית של Google כדי להציג תוכן באמצעות שרתים שנמצאים במיקום קרוב יותר אל המשתמשים, לצורך האצת אתרים ואפליקציות. Cloud CDN מופעל בשירותי קצה עורפי שמשמשים מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB). מאזן העומסים מספק את כתובות ה-IP והיציאות של הקצה הקדמי שמקבלות בקשות, ואת הבק-אנד שמגיב לבקשות.
פרטים נוספים זמינים במאמרי העזרה בנושא Cloud CDN.
אי אפשר להשתמש ב-Cloud CDN עם IAP. אי אפשר להפעיל אותם באותו שירות לקצה העורפי.
Cloud Armor
אם אתם משתמשים באחד ממאזני העומסים הבאים, אתם יכולים להוסיף הגנה נוספת לאפליקציות שלכם על ידי הפעלת Cloud Armor בשירות הקצה העורפי במהלך יצירת מאזן העומסים:
- מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
- מאזן עומסים קלאסי של אפליקציות (ALB)
- מאזן עומסי רשת גלובלי חיצוני לשרת proxy
- מאזן עומסי רשת קלאסי בשרת proxy
אם אתם משתמשים במסוף 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 שמשויכים למאזני עומסים, אפשר לעיין במאמרים הבאים:
- סקירה כללית על ניהול תנועה במאזני עומסים פנימיים של אפליקציות
- סקירה כללית על ניהול תנועה במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
- סקירה כללית על ניהול תעבורה במאזני עומסים אזוריים חיצוניים של אפליקציות
ממשקי API וgcloud הפניות
למידע נוסף על המאפיינים של משאב שירות לקצה העורפי, אפשר לעיין במקורות המידע הבאים:
- Global backend service API resource
Regional backend service API resource
gcloud compute backend-servicespage, for both global and regional backend services
המאמרים הבאים
לעיון במסמכי תיעוד קשורים ומידע על השימוש בשירותי קצה עורפיים באיזון עומסים:
- יצירת כותרות בהתאמה אישית
- יצירת מאזן עומסים חיצוני של אפליקציות (ALB)
- סקירה כללית של מאזן עומסים חיצוני של אפליקציות (ALB)
- הפעלת ניתוק הדרגתי של חיבורים
- הצפנה במעבר ב- Google Cloud
לסרטונים קשורים: