אופטימיזציות מתקדמות של איזון עומסים

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

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

‫Cloud Load Balancing מציע את התכונות המתקדמות הבאות:

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

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

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

בתרשים הבא אפשר לראות איך Cloud Load Balancing מעריך את הניתוב, איזון העומסים ופיזור התנועה.

איך Cloud Load Balancing מקבל החלטות לגבי ניתוב ופילוח תנועה.
איך Cloud Load Balancing מקבל החלטות לגבי ניתוב ופילוח התנועה.

לפני שמתחילים

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

מאזני עומסים וקצה עורפי נתמכים

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

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

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

בק-אנד נתמך?
קבוצות של מכונות
יש תמיכה בקבוצות מופעי מכונה מנוהלות אזוריות ולא מנוהלות אזוריות, אבל אין תמיכה בקבוצות מופעי מכונה מנוהלות אזוריות.
קבוצות אזוריות של נקודות קצה ברשת (GCE_VM_IP_PORT נקודות קצה)
קבוצות אזוריות של נקודות קצה ברשת (GCE_VM_IP נקודות קצה)
מאזני עומסים של אפליקציות ומאזני עומסים של רשתות לשרתי proxy לא תומכים בסוגים האלה של קבוצות נקודות קצה ברשת (NEGs).
קבוצות NEG היברידיות (נקודות קצה NON_GCP_PRIVATE_IP_PORT)
קבוצות NEG ללא שרת (serverless)
קבוצות NEG באינטרנט
קבוצות NEGs של Private Service Connect

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

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

תרשים מפל לפי אזור

‫WATERFALL_BY_REGION הוא אלגוריתם ברירת המחדל לאיזון עומסים. באמצעות האלגוריתם הזה, כל ה-proxies של מאזן העומסים (Google Front Ends (GFEs)‎ בשכבה השנייה או Envoys) באזור הקרוב ביותר למשתמש מנסים למלא את ה-backends באופן יחסי לקיבולות היעד שהוגדרו (שעברו שינוי על ידי כלי ההרחבה של הקיבולת).

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

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

התזה לאזור

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

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

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

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

מפל לפי אזור

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

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

האלגוריתם WATERFALL_BY_ZONE ממזער את זמן האחזור על סמך השיקולים הבאים:

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

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

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

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

הפחתה אוטומטית של הקיבולת והחזרה שלה

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

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

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

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

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

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

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

אלה הקצוות העורפיים עם קיבולת אפס:

  • קבוצות של שרתים עורפיים ללא מכונות חברות, שבהן הקיבולת של קבוצת המכונות מוגדרת על בסיס כל מכונה
  • קבוצות NEG של שרתים עורפיים ללא נקודות קצה חברות, שבהן הקיבולת של קבוצת ה-NEG מוגדרת על בסיס כל נקודת קצה
  • קבוצות של שרתים עורפיים (backend instance) או NEGs שהגדרתם את ערכי הקיבולת שלהם לאפס

היכולת לנקז באופן אוטומטי את הקיבולת של ה-backend שקולה להגדרה ידנית של backendService.backends[].capacityScaler של ה-backend ל-0, אבל בלי להגדיר את הערך של קנה המידה של הקיבולת.

הסרת ניקוז אוטומטית של קיבולת

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

סף מעבר לגיבוי

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

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

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

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

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

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

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

בידוד תנועה

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

יש שני מצבי בידוד:

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

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

ללא בידוד

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

איך Cloud Load Balancing מתנהג כשבידוד התנועה לא מופעל.
איך Cloud Load Balancing מתנהג כשבידוד התנועה לא מופעל.

הכי קרוב

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

איך Cloud Load Balancing מתנהג כשבידוד התנועה מופעל במצב NEAREST.
איך Cloud Load Balancing מתנהג כשבידוד התנועה מופעל במצב NEAREST.

מחמיר

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

איך Cloud Load Balancing מתנהג כשבידוד התנועה מופעל במצב STRICT.
איך Cloud Load Balancing מתנהג כשבידוד התנועה מופעל במצב STRICT.

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

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

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

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

קצה עורפי מועדף

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

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

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

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

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

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

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

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

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

הוספה של כלל מדיניות

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

המסוף

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

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

    כניסה לדף Load balancing

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

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

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

  5. בקטע Failover Health Threshold (סף בריאות למעבר לגיבוי), מזינים מספר בין 1 ל-99.

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

  7. בקטע Traffic isolation (בידוד תנועה), בוחרים באפשרות Isolate at region level (בידוד ברמת האזור).

  8. בוחרים את מצב בידוד התנועה המועדף.

  9. לוחצים על יצירה.

gcloud

  1. יוצרים משאב של מדיניות לאיזון עומסים בשירות. אפשר לעשות את זה באמצעות קובץ YAML או ישירות באמצעות פרמטרים של gcloud.

    באמצעות קובץ YAML

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

    גלובלי 

    name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
autoCapacityDrain:
    enable: True
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
isolationConfig:
  isolationGranularity: ISOLATION_GRANULARITY
  isolationMode: ISOLATION_MODE

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

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫FAILOVER_THRESHOLD_VALUE: ערך הסף למעבר לגיבוי. הערך צריך להיות מספר בין 1 ל-99.
    • ‫LOAD_BALANCING_ALGORITHM: אלגוריתם איזון העומסים שבו יש להשתמש. הפרטים יכולים להיות SPRAY_TO_REGION, WATERFALL_BY_REGION או WATERFALL_BY_ZONE.
    • ‫ISOLATION_GRANULARITY: רמת הפירוט של הגבלת הבידוד. כדי למנוע הצפה של תעבורת נתונים בין אזורים, צריך להגדיר את הערך הזה ל-REGION. אם לא מציינים ערך, לא נאכף בידוד.
    • ‫ISOLATION_MODE: התנהגות הבידוד. הערכים האפשריים הם NEAREST או STRICT.

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

    gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
    --source=PATH_TO_POLICY_FILE \
    --location=global

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

    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫PATH_TO_POLICY_FILE: הנתיב לקובץ ה-YAML שמכיל את מדיניות איזון העומסים של השירות.

    אזורי 

    name: projects/PROJECT_ID/locations/REGION/serviceLbPolicies/SERVICE_LB_POLICY_NAME
autoCapacityDrain:
    enable: True
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM

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

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫REGION: האזור שבו נוצרה המדיניות. האזור הזה צריך להיות זהה לאזור של שירות לקצה העורפי שאליו רוצים להחיל את המדיניות.
    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫FAILOVER_THRESHOLD_VALUE: ערך הסף למעבר לגיבוי. הערך צריך להיות מספר בין 1 ל-99.
    • ‫LOAD_BALANCING_ALGORITHM: אלגוריתם איזון העומסים שבו יש להשתמש. הפרטים יכולים להיות SPRAY_TO_REGION, WATERFALL_BY_REGION או WATERFALL_BY_ZONE.

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

    gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
    --source=PATH_TO_POLICY_FILE \
    --location=REGION

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

    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫PATH_TO_POLICY_FILE: הנתיב לקובץ ה-YAML שמכיל את מדיניות איזון העומסים של השירות.
    • ‫REGION: האזור שבו נמצאת המדיניות. האזור הזה צריך להיות זהה לאזור של שירות לקצה העורפי שרוצים להחיל עליו את המדיניות.

    ללא קובץ YAML

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

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

    gcloud network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
    --auto-capacity-drain \
    --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
    --location=LOCATION

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

    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫LOAD_BALANCING_ALGORITHM: אלגוריתם איזון העומסים שבו יש להשתמש. הפרטים יכולים להיות SPRAY_TO_REGION, WATERFALL_BY_REGION או WATERFALL_BY_ZONE.
    • ‫FAILOVER_THRESHOLD_VALUE: ערך הסף של המעבר לגיבוי. הערך צריך להיות מספר בין 1 ל-99.
    • ‫LOCATION: המיקום שבו נוצרת המדיניות. הערך יכול להיות global או אזור Google Cloud . במקרה של מדיניות אזורית, המיקום הזה צריך להיות זהה לאזור של שירות ה-Backend שאליו רוצים להחיל את המדיניות.

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

    gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=ISOLATION_GRANULARITY \
    --isolation-config-mode=ISOLATION_MODE \
    --location=global

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

    • ‫ISOLATION_GRANULARITY: רמת הפירוט של הגבלת הבידוד. כדי למנוע הצפה של תעבורת נתונים בין אזורים, צריך להגדיר את הערך הזה ל-REGION. אם לא מציינים ערך, לא נאכף בידוד.
    • ‫ISOLATION_MODE: התנהגות הבידוד. הערכים האפשריים הם NEAREST או STRICT.

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

    gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    {--global | --region=REGION}

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

    • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

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

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --protocol=PROTOCOL \
    --port-name=NAMED_PORT_NAME \
    --health-checks=HEALTH_CHECK_NAME \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    {--global | --region=REGION}

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

    • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
    • ‫PROTOCOL: הפרוטוקול שמשמש לתקשורת עם ה-backends, כמו HTTP,‏ HTTPS או TCP.
    • ‫NAMED_PORT_NAME: השם של היציאה ששירות הקצה העורפי מאזין לה.
    • ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות.
    • ‫LOAD_BALANCING_SCHEME: סכמת איזון העומסים, למשל EXTERNAL_MANAGED או INTERNAL_MANAGED.
    • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
    • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

השבתת התכונות שהוגדרו במדיניות

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

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

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

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=LOCATION

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

  • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
  • LOCATION: המיקום שבו נוצרה המדיניות. הערך יכול להיות global או אזור Google Cloud .

איפוס סף המעבר לגיבוי

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

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=LOCATION

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

  • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
  • LOCATION: המיקום שבו נוצרה המדיניות. הערך יכול להיות global או אזור Google Cloud .

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

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

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=LOCATION

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

  • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.
  • LOCATION: המיקום שבו נוצרה המדיניות. הערך יכול להיות global או אזור Google Cloud .

השבתת בידוד התנועה

כדי להשבית את הפרדת התנועה (גרסת Preview), מגדירים את שני פרמטרי ההגדרה של ההפרדה לערך UNSPECIFIED, כמו שמוצג בפקודה הבאה:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=global

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

  • ‫SERVICE_LB_POLICY_NAME: השם של מדיניות איזון העומסים של השירות.

הסרת מדיניות

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

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    {--global | --region=REGION}

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

  • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
  • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

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

אפשר להגדיר את השרתים העורפיים המועדפים באמצעות Google Cloud CLI או ה-API.

המסוף

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

כשמוסיפים את הקצה העורפי לשירות הקצה העורפי, מגדירים את השדה Backend preference level לערך Preferred.

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

gcloud

הוספת שרת קצה עורפי מועדף

כדי להגדיר קצה עורפי מועדף, משתמשים בפקודה gcloud compute backend-services add-backend כדי להגדיר את הדגל --preference כשמוסיפים את הקצה העורפי לשירות הקצה העורפי.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    {--global | --region=REGION}

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

  • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
  • ‫PREFERENCE: רמת ההעדפה שרוצים להקצות לשרת העורפי, PREFERRED או DEFAULT.
  • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

החלק הנותר של הפקודה תלוי בסוג העורף שבו אתם משתמשים (קבוצת מופעים או NEG). במאמר בנושא הפקודה gcloud compute backend-services add-backend מפורטים כל הפרמטרים הנדרשים.

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

כדי לעדכן את הפרמטר --preference של קצה עורפי, משתמשים בפקודה gcloud compute backend-services update-backend.

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    {--global | --region=REGION}

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

  • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
  • ‫PREFERENCE: רמת ההעדפה שרוצים להקצות לשרת העורפי, PREFERRED או DEFAULT.
  • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

החלק הנותר של הפקודה תלוי בסוג העורף שבו אתם משתמשים (קבוצת מופעים או NEG). הפקודה הבאה מעדכנת את ההעדפה של קבוצת מופעים של שרת עורפי ומגדירה אותה ל-PREFERRED:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    {--global | --region=REGION}

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

  • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות.
  • ‫INSTANCE_GROUP_ZONE: האזור שבו נמצאת קבוצת המכונות.
  • ‫REGION: האזור של שירות הקצה העורפי (אם מגדירים שירות קצה עורפי אזורי).

API

כדי להגדיר קצה עורפי מועדף, מגדירים את הדגל preference בכל קצה עורפי באמצעות משאב backendServices גלובלי.

בדוגמה הבאה אפשר לראות איך מגדירים את ההעדפה של ה-Backend:

  name: projects/PROJECT_ID/locations/LOCATION/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

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

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
  • ‫BACKEND_1_NAME: השם של ה-Backend המועדף
  • ‫BACKEND_2_NAME: השם של קצה העורפי שמוגדר כברירת מחדל
  • ‫LOCATION: המיקום שבו נוצר שירות ה-Backend. הערך יכול להיות global או אזור Google Cloud .

פתרון בעיות

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

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

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

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

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

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

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

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

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

סף מעבר לגיבוי

תנועת גולשים נשלחת לעורף מרוחק במהלך שינויים זמניים במצב התקינות

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

נקודות קצה תקינות עמוסות מדי כשנקודות קצה אחרות לא תקינות

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

קצה עורפי מועדף

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

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

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

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

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

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

בידוד תנועה

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

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

תעבורת הנתונים מנותבת מאזור מרוחק לאזור קרוב יותר

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

התנועה לא מנותבת מחדש אחרי שמפעילים את בידוד התנועה

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

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

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

מגבלות

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