סקירה כללית של איזון עומסים מתקדם

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

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

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

  • Waterfall לפי אזור (אלגוריתם ברירת המחדל).
  • ריסוס לאזור.
  • לרסס לעולם.
  • מפל לפי אזור.

אלה האפשרויות הנוספות שזמינות:

  • הגדרת שרתים מועדפים לעורף. ‫Cloud Service Mesh שולח תעבורה לקבוצות ה-MIG או ל-NEG האלה לפני שהוא שולח תעבורה לשרתי קצה עורפיים אחרים.
  • הגדרת ניהול אוטומטי של הקיבולת.
  • התאמה אישית של התנהגות המעבר לגיבוי.

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

איך Cloud Service Mesh מנתב ומאזן עומסים של תעבורה

בתרשים הבא מוצג אופן הניתוב של תעבורת נתונים ב-Cloud Service Mesh.

איך Cloud Service Mesh מקבל החלטות לגבי איזון עומסים
איך Cloud Service Mesh מקבל החלטות לגבי איזון עומסים (לחצו כדי להגדיל)

קודם כל, Cloud Service Mesh בוחר שירותי קצה עורפיים על סמך מאפייני הבקשה ועל סמך כללי הניתוב במשאב Route או במפת URL, בהתאם ל-API שבו נעשה שימוש בפריסה.

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

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

קצה עורפי נתמך וקצה עורפי לא נתמך

סוגי הבק-אנד הבאים נתמכים באיזון עומסים מתקדם:

  • קבוצות של מכונות לא מנוהלות
  • קבוצות של מופעי מכונה מנוהלים (MIG)
  • קבוצות של נקודות קצה ברשת אזורית (GCE_VM_IP_PORT NEGs)
  • קבוצות של נקודות קצה ברשת לקישוריות היברידית (NON_GCP_PRIVATE_IP_PORT NEG)

סוגי ה-backend הבאים לא נתמכים באיזון עומסים מתקדם:

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

תרחישים לדוגמה

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

איזון התנועה בין שרתי הבק-אנד באזור

אלגוריתם ברירת המחדל לאיזון עומסים, waterfall by region, מפזר את התנועה באופן שווה בין כל קבוצות ה-MIG או NEGs באזורים. מומלץ להשתמש באלגוריתם שמוגדר כברירת מחדל, אלא אם יש לכם דרישות מיוחדות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התנהגות תרשים מפל מים לפי אזור התזה לאזור Spray to world Waterfall by zone
שימוש אחיד בקיבולת באזור במצב יציב כן כן כן לא
שימוש אחיד בקיבולת במספר אזורים במצב יציב לא לא כן לא
חלוקת תנועה אחידה באזור במצב יציב לא כן כן לא
תנועה בין אזורים כן. האלגוריתם הזה יפיץ את התנועה באופן שווה בין האזורים באזור, תוך אופטימיזציה של זמן האחזור ברשת. יכול להיות שהתנועה תועבר בין אזורים אם יהיה צורך בכך. כן כן כן, התעבורה תמלא את התחום הקרוב ביותר עד לקיבולת שלו. אחר כך הוא יעבור לאזור הבא.
רגישות לעליות פתאומיות בתנועה באזור המקומי ממוצע; בהתאם לכמות התנועה שכבר הועברה כדי ליצור איזון בין האזורים. נמוך יותר, כי העליות החדות באזור יחיד יתפזרו על פני כל האזורים באזור. נמוך יותר, כי העליות החדות באזור יתפזרו על פני כל האזורים. גבוה יותר, כי סביר יותר ששיאים בתחום יחיד יטופלו באופן מלא על ידי תחום יחיד עד ש-Cloud Service Mesh יוכל להגיב.

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

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

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

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

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

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

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

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

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

כשהמערכות העורפיות שמתרוקנות באופן אוטומטי חוזרות למצב תקין, הן לא מתרוקנות אם לפחות 35% מנקודות הקצה או מהמופעים תקינים למשך 60 שניות. ‫Cloud Service Mesh לא מרוקן יותר מ-50% מנקודות הקצה בשירות לקצה העורפי, ללא קשר למצב התקינות של הקצה העורפי.

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

התאמה אישית של התנהגות המעבר לגיבוי

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

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

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

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

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

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

סף התקינות למעבר אוטומטי הוא ערך באחוזים. הערך שאתם מגדירים קובע מתי Cloud Service Mesh מפנה תנועה לשרתי קצה לגיבוי. אפשר להגדיר את הערך כמספר שלם בין 1 ל-99. ערך ברירת המחדל של Cloud Service Mesh הוא 70 עם Envoy ו-50 עבור gRPC ללא proxy. ערך גדול יותר יתחיל את המעבר לגיבוי (failover) של התנועה מוקדם יותר מערך קטן יותר.

פתרון בעיות

דפוסי חלוקת התנועה יכולים להשתנות בהתאם לאופן ההגדרה של serviceLbPolicy החדש עם שירות ה-Backend.

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

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

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

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

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

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

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

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

התנועה לא מועברת לחלק מקבוצות ה-MIG או ה-NEG כשהעדפה ניתנת לחלק מקבוצות ה-MIG או ה-NEG

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

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

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

התנועה נשלחת ליותר מדי קבוצות של מכונות מנוהלות (MIG) או קבוצות של נקודות קצה ברשת (NEG) ממקור יחיד

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

תנועת הגולשים מועברת לאשכול מרוחק כשהסטטוס של ה-backend משתנה

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

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

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

מגבלות ושיקולים

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

Waterfall-by-zone

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

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

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

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

התזה לאזור

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

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

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

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

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

  • אלגוריתמים גלובליים לאיזון עומסים (waterfall by region, spray-to-region, waterfall-by-zone) לא חלים על קבוצות MIG או על NEGs שהוגדרו כשרתי קצה עדיפים.

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

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

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

  • אם הערך serviceLbPolicies מוגדר, אחוז ה-MIG או ה-NEG המינימליים שלעולם לא יתרוקנו הוא 50%. בשני סוגי ההגדרות, קבוצת MIG או NEG מסומנת כלא תקינה אם פחות מ-25% מהמופעים או מנקודות הקצה בקבוצת ה-MIG או ה-NEG תקינים.

  • כדי ש-MIG או NEG יחזרו לפעולה אחרי ניתוק, לפחות 35% מהמופעים או מנקודות הקצה צריכים להיות תקינים. הפעולה הזו נדרשת כדי לוודא שקבוצת מופעים מנוהלת (MIG) או קבוצת נקודות קצה ברשת (NEG) לא משנה את המצב שלה בין מצב של ניקוז למצב של אי-ניקוז.

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

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