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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התזה לאזור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הפחתת נפח אחסון אוטומטית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בידוד תנועה

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

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

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

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

ללא בידוד

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

הכי קרוב

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

מחמיר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הסרת מדיניות

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

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

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

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

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

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

פתרון בעיות

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

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

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

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

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

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

הפחתת נפח אחסון אוטומטית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בידוד תנועה

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

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

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

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

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

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

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

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

מגבלות

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