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

במדריך הזה מוסבר איך לפתור בעיות בהגדרות של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.

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

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

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

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

  • בדיקת הכללים של חומת האש.

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

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

  • מוודאים שסוכן האורח של Google פועל במכונה הווירטואלית של ה-Backend. אם אתם מצליחים להתחבר למכונת VM תקינה בעורף, אבל לא למאזן העומסים, יכול להיות שסוכן האורח של Google (לשעבר סביבת האורח של Windows או סביבת האורח של Linux) במכונת ה-VM לא פועל או שלא מצליח לתקשר עם שרת המטא-נתונים (metadata.google.internal, 169.254.169.254).

    כדאי לבדוק את הדברים הבאים:

    • מוודאים שסוכן האורח של Google מותקן ופועל במכונת ה-VM של ה-Backend.
    • מוודאים שכללי חומת האש במערכת ההפעלה המתארחת של המכונה הווירטואלית בעורף (iptables או חומת האש של Windows) לא חוסמים את הגישה לשרת המטא-נתונים.

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

    במכונות וירטואליות שנוצרו מ Google Cloud תמונות, הסוכן של מערכת ההפעלה האורחת מתקין את הנתיב המקומי לכתובת ה-IP של מאזן העומסים. מכונות ב-Google Kubernetes Engine שמבוססות על מערכת הפעלה שמותאמת לקונטיינרים מיישמות את זה באמצעות iptables.

    במכונה וירטואלית של Linux backend, אפשר לוודא שהנתיב המקומי קיים באמצעות הפקודה הבאה. מחליפים את LOAD_BALANCER_IP בכתובת ה-IP של מאזן העומסים:

    sudo ip route list table local | grep LOAD_BALANCER_IP

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

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

    netstat -nl | grep ':PORT'

    התוכנה שפועלת במכונת ה-VM של ה-Back-end צריכה לבצע את הפעולות הבאות:

    • האזנה (bound to) לכתובת ה-IP של מאזן העומסים או לכל כתובת IP (0.0.0.0 או ::)
    • האזנה (שמשויכת) ליציאה שכלולה בכלל ההעברה של מאזן העומסים

    כדי לבדוק את זה, מתחברים למכונת קצה עורפית באמצעות SSH או RDP. לאחר מכן מבצעים את הבדיקות הבאות באמצעות curl,‏ telnet או כלי דומה:

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

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

פתרון בעיות ב-VPC משותף

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

פתרון בעיות במעבר לגיבוי (failover)

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

  • חשוב להבין את המושגים בחירת קצה עורפי ומעקב אחר חיבורים ומעבר לגיבוי (Failover).
  • מוודאים שהגדרתם לפחות שרת קצה עורפי אחד למעבר אוטומטי.
  • כדי לדעת אילו מכונות וירטואליות יכולות לשמש כשרתי קצה עורפיים, אפשר לבדוק אילו שרתי קצה עורפיים תקינים באמצעות מסוף Google Cloud או gcloud compute backend-services get-health.
  • מוודאים שיחס המעבר לגיבוי מוגדר בצורה מתאימה.
  • לא מומלץ להשתמש בקבוצות מופעי מכונה מנוהלים שמופעל בהן התאמה אוטומטית לעומס בשילוב עם יתירות כשל, כי ההתאמה האוטומטית לעומס משנה את מספר השרתים העורפיים הראשיים, השרתים העורפיים של יתירות הכשל או שניהם. הדבר עלול לגרום לשינוי לא צפוי בקבוצת השרתים העורפיים שעומדים בדרישות, כי יחס המעבר לגיבוי קבוע.
  • אם מכונה וירטואלית של לקוח היא גם מכונה וירטואלית לקצה העורפי עם איזון עומסים, חיבורים לכתובת ה-IP של כלל ההעברה של מאזן העומסים נשלחים למכונה הווירטואלית של הקצה העורפי עצמה. מידע נוסף זמין במאמר בנושא בדיקה מלקוח יחיד.

פתרון בעיות שקשורות לרישום ביומן

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

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