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

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

פתרון בעיות נפוצות ב-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.

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

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

פתרון בעיות כלליות בקישוריות

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

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

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

לתגובות שגיאה של HTTP עם statusDetails שלא תואם למחרוזת היומן response_sent_by_backend:

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

  • מאזן העומסים הקלאסי של אפליקציות (ALB) תמיד משתמש בקוד השגיאה 502 של תגובת HTTP.

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

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

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

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

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

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

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

    2. בודקים את הערך של השדה statusDetails:

      • אם statusDetails מחזיר הודעת הצלחה, כמו response_sent_by_backend, אז ה-backend הוא זה שמציג תגובות HTTP 502. בודקים את היומנים בקצה העורפי וממשיכים לפתור את הבעיה בהתאם לשירות שפועל בקצה העורפי.
      • אם הפקודה statusDetails מחזירה הודעת שגיאה, אפשר להיעזר ברשימת הפתרונות הבאה לכמה שגיאות נפוצות שקשורות לתגובות 5xx:
      הודעת השגיאה statusDetail סיבות אפשריות ופתרונות
      failed_to_connect_to_backend

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

      המלצות:

      • מגדירים את היציאה של בדיקת התקינות לשימוש ב יציאה למילוי הבקשה. המשמעות היא שהקצה העורפי יימצא במצב לא תקין לפני שהוא יהיה כשיר להצגת תנועה אמיתית.
      • משתמשים בפקודה הבאה כדי לוודא שיש שירות שפועל ביציאה עם השם של שירות ה-backend: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

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

      backend_connection_closed_before_data_sent_to_client הקצה העורפי סגר באופן לא צפוי את החיבור שלו למאזן העומסים לפני שהתגובה הועברה באמצעות פרוקסי ללקוח. זה יכול לקרות אם מאזן העומסים שולח תנועה לישות אחרת. יכול להיות שהגורם השני הוא מאזן עומסים של צד שלישי עם פסק זמן של TCP שהוא קצר יותר מפסק הזמן של מאזן העומסים. פרטים נוספים זמינים במאמר Timeouts and retries.
      backend_timeout לשרת העורפי לקח יותר מדי זמן להגיב. יכול להיות שהזמן הקצוב לתפוגה של שירות הקצה העורפי קצר מדי בשביל שהשירות יגיב. כדאי להגדיל את הזמן הקצוב לתפוגה של שירות לקצה העורפי או לבדוק למה לוקח לשירות כל כך הרבה זמן להגיב.

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

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

פתרון שגיאות HTTP 408

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

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

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

  • חיבור 1, מהלקוח המקורי למאזן העומסים (GFE או רשת משנה של שרת proxy בלבד)
  • חיבור 2, ממאזן העומסים (GFE או רשת משנה של proxy בלבד) למכונה וירטואלית או לנקודת קצה של קצה העורף

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

מקבלים שגיאת הרשאה כשמנסים להציג אובייקט בקטגוריה של Cloud Storage

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

כתובת ה-URL לא מציגה את האובייקט הרצוי ב-Cloud Storage

האובייקט של Cloud Storage שיוצג נקבע על סמך מפת ה-URL וכתובת ה-URL שביקשתם. אם נתיב הבקשה ממופה לקטגוריית קצה עורפי במפת URL, האובייקט ב-Cloud Storage נקבע על ידי הוספת נתיב הבקשה המלא לקטגוריה של Cloud Storage שצוינה במפת URL.

לדוגמה, אם ממפים את /static/* ל-gs://[EXAMPLE_BUCKET], הבקשה ל-https://<GCLB IP or Host>/static/path/to/content.jpg תנסה להציג את gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. אם האובייקט לא קיים, במקום האובייקט תופיע הודעת השגיאה הבאה:


NoSuchKey
The specified key does not exist.

הדחיסה לא פועלת

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

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

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

כדי להגדיר בק-אנד של Apache שיגיש תשובות דחוסות שמועברות דרך מאזן עומסים של אפליקציות (ALB) חיצוני:

פתרון בעיות בקצוות עורפיים לא תקינים

פתרון בעיות ב-HTTP/2 לשרתי קצה עורפיים

מוודאים שמופע ה-Backend תקין ותומך בפרוטוקול HTTP/2. כדי לוודא זאת, אפשר לבדוק את הקישוריות לשרת העורפי (backend instance) באמצעות HTTP/2. מוודאים שהמכונה הווירטואלית משתמשת בחבילות הצפנה שתואמות למפרט HTTP/2. לדוגמה, פרוטוקול HTTP/2 לא מאפשר שימוש בסטים מסוימים של אלגוריתמים להצפנה (cipher suite) מסוג TLS 1.2. אפשר לעיין ברשימה השחורה של חבילות הצפנה TLS 1.2.

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

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

פתרון בעיות שקשורות לקצה עורפי חיצוני ול-NEG באינטרנט

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

התנועה לא מגיעה לנקודות הקצה

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

  • נקודת הקצה מצורפת ל-NEG עם גישה לאינטרנט.
  • אפשר ליצור רזולוציית DNS של ה-FQDN המשויך (אם משתמשים בסוג נקודת הקצה FQDN).
  • יש גישה לנקודת הקצה דרך האינטרנט.

אם התנועה לא מגיעה לנקודת הקצה, ומוחזר קוד שגיאה 502, צריך לשלוח שאילתה לרשומת ה-TXT של DNS של _cloud-eoips.googleusercontent.com באמצעות כלי כמו dig או nslookup. שימו לב ל-CIDR (אחרי ip4:) וודאו שהטווחים האלה מורשים על ידי חומת האש או רשימת בקרת הגישה (ACL) בענן.

אחרי הגדרת backend חיצוני, בקשות ל-backend חיצוני נכשלו עם שגיאת 5xx

  • מסמנים את האפשרות רישום ביומן.
  • מוודאים שקבוצת נקודות הקצה ברשת מוגדרת עם כתובת ה-IP:היציאה או ה-FQDN:היציאה הנכונים עבור קצה העורף החיצוני.
  • אם אתם משתמשים ב-FQDN, ודאו שאפשר לתרגם אותו באמצעות Google Public DNS. כדי לוודא שאפשר לתרגם את ה-FQDN באמצעות Google Public DNS, אפשר לפעול לפי השלבים האלה או להשתמש בממשק האינטרנט ישירות.
  • אם אתם ניגשים למאזן העומסים רק דרך כתובת ה-IP החיצונית שלו, ושרת האינטרנט של המקור מצפה לשם מארח, צריך לוודא שאתם שולחים כותרת HTTP Host תקינה לבק-אנד על ידי הגדרת כותרת בקשה בהתאמה אישית.
  • אם אתם מתקשרים עם קצה עורפי באמצעות HTTPS או HTTP2 (כפי שמוגדר בשדה protocol של שירות הקצה העורפי) שהוגדר כנקודת קצה חיצונית של קצה עורפי INTERNET_FQDN_PORT, ודאו שהמקור שלכם מציג אישור TLS (SSL) תקין וששם הדומיין המלא (FQDN) המוגדר תואם ל-SAN (שם חלופי של בעלים (subject)) ברשימת ה-SAN של האישורים. אישור תקף מוגדר כאישור שנחתם על ידי רשות אישורים ציבורית ושלא פג תוקפו.
  • כשמשתמשים בנקודות קצה חיצוניות של קצה עורפי INTERNET_FQDN_PORT, מאזן העומסים לא מקבל אישורים בחתימה עצמית, והם נדחים.
  • כשמשתמשים ב-HTTPS או ב-HTTP/2 עם נקודות קצה מסוג INTERNET_IP_PORT, לא מתבצעת אימות של אישור SSL או בדיקה של SAN. המשמעות היא שאפשר להשתמש באישורים בחתימה עצמית. כשמשתמשים ב-SSL, מומלץ להשתמש בנקודות הקצה INTERNET_FQDN_PORT כדי לוודא שאפשר לאמת את אישורי השרת ואת שמות ה-SAN.

תגובות מהקצה העורפי החיצוני שלי לא נשמרות במטמון על ידי Cloud CDN

חשוב לוודא ש:

  • הפעלתם את Cloud CDN בשירות הקצה העורפי שמכיל את ה-NEG שמפנה לקצה העורפי החיצוני, על ידי הגדרת enableCDN לערך true.
  • התשובות שמוגשות על ידי הבק-אנד החיצוני עומדות בדרישות השמירה במטמון של Cloud CDN. לדוגמה, אתם שולחים Cache-Control: public, max-age=3600 כותרות תגובה מהמקור.

פתרון בעיות ב-NEG ללא שרת

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

הבקשות נכשלות ומתקבלת שגיאת 404

מוודאים שהמשאב הבסיסי של בלי שרת (serverless) (כמו App Engine, פונקציות Cloud Run או שירות של Cloud Run) עדיין פועל. אם משאב בלי שרת נמחק אבל ה-NEG ללא שרת עדיין קיים, מאזן עומסים של אפליקציות חיצוני ימשיך לנסות לנתב בקשות לשירות שלא קיים. התוצאה היא תגובת 404.

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

טיפול בחוסר התאמה של מסכות כתובות URL

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

‫Cloud Run: במקרה של אי התאמה במסכת כתובת ה-URL, מאזן העומסים מחזיר שגיאת HTTP 404 (לא נמצא).

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

‫App Engine: במקרה של אי התאמה במסכת כתובת ה-URL,‏ App Engine משתמש ב-dispatch.yaml ובלוגיקת הניתוב שמוגדרת כברירת מחדל ב-App Engine כדי לקבוע לאיזה שירות לשלוח את הבקשה.