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

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

פתרון בעיות נפוצות ב-Network Analyzer

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

הכלי Network Analyzer זמין במסוף Google Cloud כחלק מ-Network Intelligence Center.

מעבר אל Network Analyzer

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

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

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) פועל כשרת proxy הפוך (שער) מסוג HTTP(S). כשתוכנת לקוח פותחת חיבור לכתובת ה-IP של כלל הפנייה לכתובת פנימית שמנוהל על ידי Google, החיבור מסתיים בשרת proxy. הפרוקסי מעבד את הבקשות שמגיעות דרך החיבור הזה. לכל בקשה, שרת ה-proxy בוחר קצה עורפי לקבלת הבקשה על סמך מפת URL וגורמים אחרים. ה-proxy שולח את הבקשה לשרת העורפי שנבחר. כתוצאה מכך, מנקודת המבט של ה-Backend, המקור של חבילת נתונים נכנסת הוא כתובת IP מרשת המשנה של ה-Proxy בלבד באזור.

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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