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

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

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

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

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

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

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

    במכונות וירטואליות שנוצרו מ Google Cloud תמונות, הסוכן של מערכת ההפעלה מתקין את המסלול המקומי לכתובת ה-IP של מאזן העומסים. מכונות ב-Google Kubernetes Engine שמבוססות על Container-Optimized OS מיישמות את זה באמצעות 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 או ::)
    • האזנה ביציאה (bound to) שכלולה בכלל ההעברה של מאזן העומסים

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

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

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

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

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

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

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

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

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

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

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