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

במדריך הזה מוסבר איך לפתור בעיות בהגדרות של Cloud de Confiance by S3NS מאזן עומסים פנימי לאפליקציות. לפני שממשיכים במדריך הזה, כדאי להכיר את המושגים הבאים:

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

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

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

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

למידע נוסף, קראו את המאמרים הבאים:

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

זה תקין. מאזן עומסים פנימי של אפליקציות (ALB) פועל כ-HTTP(S) reverse proxy (שער). כשתוכנת לקוח פותחת חיבור לכתובת ה-IP של כלל העברה INTERNAL_MANAGED, החיבור מסתיים בשרת proxy. הפרוקסי מעבד את הבקשות שמגיעות דרך החיבור הזה. לכל בקשה, שרת ה-proxy בוחר קצה עורפי לקבלת הבקשה על סמך מפת URL וגורמים אחרים. ה-proxy שולח את הבקשה לשרת העורפי שנבחר. כתוצאה מכך, מנקודת המבט של ה-Backend, המקור של חבילת נתונים נכנסת הוא כתובת IP מרשת המשנה (subnet) של אזור proxy בלבד.

מאזן העומסים לא מתחבר לסביבות קצה עורפיות

צריך להגדיר את חומות האש שמגנות על השרתים העורפיים כך שיאפשרו תעבורת נתונים נכנסת (ingress) מה-proxies בטווח של תת-רשת של שרת proxy בלבד שהקציתם לאזור של מאזן העומסים הפנימי מסוג HTTP(S).

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

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

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

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

הפרוקסיים מאזינים לחיבורים לכתובת ה-IP ולפורט של מאזן העומסים שהוגדרו בכלל ההעברה (לדוגמה, 10.1.2.3:80), ולפרוטוקול שצוין בכלל ההעברה (HTTP או HTTPS). אם הלקוחות לא מצליחים להתחבר, צריך לוודא שהם משתמשים בכתובת, ביציאה ובפרוטוקול הנכונים.

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

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

מגבלות של מדיניות הארגון לגבי VPC משותף

אם אתם משתמשים ב-VPC משותף ואתם לא מצליחים ליצור מאזן עומסים של אפליקציות (ALB) פנימי חדש ברשת משנה מסוימת, יכול להיות שהסיבה לכך היא מדיניות הארגון. במדיניות הארגון, מוסיפים את רשת המשנה לרשימת רשתות המשנה המותרות או פונים לאדמין של הארגון. מידע נוסף זמין במאמר constraints/compute.restrictSharedVpcSubnetworks.

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

יכול להיות שתבחינו בחוסר איזון בתעבורת הנתונים במאזן העומסים הפנימי של אפליקציות (ALB) באזורים שונים. זה יכול לקרות במיוחד כשניצול הקיבולת של ה-Backend נמוך (< 10%).

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

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

  • מומלץ להשתמש בRATE מצב איזון עם יעד קיבולת נמוך של max-rate-per-instance.
  • משתמשים במדיניות התנועה של קצה עורפי מסוג LocalityLbPolicy עם אלגוריתם לאיזון עומסים מסוג LEAST_REQUEST.

5xx שגיאות לא מוסברות

במקרים של שגיאות שנגרמות בגלל בעיות בתקשורת בין שרת ה-proxy של מאזן העומסים לבין השרתים העורפיים שלו, מאזן העומסים יוצר קוד סטטוס של HTTP‏ (5xx) ומחזיר את קוד הסטטוס הזה ללקוח. לא כל השגיאות מסוג HTTP 5xx נוצרות על ידי מאזן העומסים. לדוגמה, אם קצה עורפי שולח תגובה מסוג HTTP 5xx למאזן העומסים, מאזן העומסים מעביר את התגובה הזו ללקוח שלו. כדי לדעת אם תגובת HTTP 5xx הועברה מקצה עורפי או נוצרה על ידי שרת ה-proxy של מאזן העומסים, צריך לעיין בשדה proxyStatus של יומני מאזן העומסים.

שינויים בהגדרות של מאזן עומסים של אפליקציות (ALB) פנימי, כמו הוספה או הסרה של שירות לקצה העורפי, עלולים לגרום לתקופה קצרה שבה המשתמשים יראו את קוד הסטטוס של HTTP 503. למרות שהשינויים בהגדרות האלה מועברים ל-Envoys באופן גלובלי, אתם רואים רשומות ביומן שבהן השדה proxyStatus תואם למחרוזת היומן connection_refused.

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

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

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

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

  3. מוודאים שפרמטר ההגדרה keepalive של תוכנת שרת ה-HTTP שפועלת במופע העורפי לא קטן מפרק הזמן הקצוב לתפוגה של keepalive במאזן העומסים, שהערך שלו קבוע על 10 דקות (600 שניות) ולא ניתן להגדרה.

    מאזן העומסים יוצר קוד סטטוס HTTP 5xx כשהחיבור לקצה העורפי נסגר באופן לא צפוי במהלך שליחת בקשת ה-HTTP או לפני קבלת תגובת ה-HTTP המלאה. זה יכול לקרות כי פרמטר ההגדרה keepalive של תוכנת שרת האינטרנט שפועלת במופע העורפי קטן יותר מהזמן הקצוב הקבוע לתפוגה של keepalive במאזן העומסים. מוודאים שהזמן הקצוב לתפוגה של keepalive בהגדרות של תוכנת שרת ה-HTTP בכל שרת קצה עורפי מוגדר לערך שגדול מעט מ-10 דקות (הערך המומלץ הוא 620 שניות).

מגבלות

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