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

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

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

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

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

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

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

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

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

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

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

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

שנית, Cloud Service Mesh בוחר קבוצת מופעים לניהול (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 או קבוצות ה-NEG באזורים. מומלץ להשתמש באלגוריתם שמוגדר כברירת מחדל, אלא אם יש לכם דרישות מיוחדות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בנוסף, 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 החדש עם שירות לקצה העורפי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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