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

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

יצירת כלל העברה נכשלת עם השגיאה 'הכתובת היא לא כתובת RFC 1918'

כשיוצרים כלל העברה פנימי עם כתובת IP מילולית ברשת משנה שמשתמשת בטווח שאינו RFC 1918, מוצגת שגיאה שדומה לזו:

ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource:
 - Invalid value for field 'resource.IPAddress': '100.71.1.88'. Address '100.71.1.88' is not an RFC1918 address.

כדי למנוע ניתוב מקרי של כתובות IP שניתנות לניתוב ציבורי, מאמת ה-API בודק בקפדנות ערכים מילוליים בהתאם לתקני RFC 1918. עם זאת, הוא לא בודק באופן דינמי אם כתובת מילולית מנוהלת על ידי VPC, ולכן הוא נכשל כשמספקים כתובת IP שאינה RFC 1918 באופן ישיר.

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

  • משמיטים את הדגל --address מהפקודה gcloud compute forwarding-rules create. Google Cloudהמערכת מקצה באופן אוטומטי כתובת IP בטוחה ותקינה ישירות מתת-הרשת.
  • קודם צריך להזמין משאב של כתובת IP עם שם באמצעות הפקודה gcloud compute addresses create. לאחר מכן צריך להפנות לשם השמור באמצעות הדגל --address:
    1. שומרים את כתובת ה-IP הסטטית כמשאב עם שם: bash gcloud compute addresses create ADDRESS_NAME \ --addresses=IP_ADDRESS \ --region=REGION \ --subnet=SUBNET \ --purpose=SHARED_LOADBALANCER_VIP
    2. מפנים לכתובת ה-IP השמורה לפי שם בפקודה ליצירת כלל ההעברה: --address=ADDRESS_NAME.

מגבלות

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