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

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

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

אימות סביבת האורח פועלת במכונה הווירטואלית בעורף

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

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

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

כל מכונת 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, וזו התנהגות צפויה.

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

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

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

מריצים את הפקודה הבאה מלקוח באותה רשת VPC כדי לוודא שמכונת ה-VM של ה-Backend מאזינה ליציאת TCP ספציפית:

telnet SERVER_IP_ADDRESS PORT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVER_IP_ADDRESS: כתובת ה-IP של מכונת ה-VM של ה-Backend.
  • ‫PORT: היציאה שהגדרתם לבדיקת תקינות. כברירת מחדל, היציאה של בדיקת התקינות היא 80.

לחלופין, אפשר להשתמש ב-SSH כדי לחבר את מכונת ה-VM של ה-Backend ולהריץ את הפקודה הבאה:

curl localhost:PORT

שוב, מחליפים את PORT ביציאה שהגדרתם לבדיקת תקינות.

דרך נוספת לבצע את הבדיקה הזו היא להריץ את הפקודה הבאה:

netstat -npal | grep LISTEN

בפלט, בודקים את הדברים הבאים:

  • <var>LB_IP_ADDRESS</var>:<var>PORT</var>
  • 0.0.0.0:<var>PORT</var>
  • :::<var>PORT</var>

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

פתרון בעיות בביצועים

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

אימות הפונקציונליות של השרת

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

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

בדיקת החיבור לרשת וזמן האחזור

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

ping SERVER_IP_ADDRESS

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

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

זיהוי שילובים בעייתיים של שרתים ולקוחות

אם בדיקת הרשת ping מצביעה על זמן אחזור נמוך ועל כך שאין אובדן מנות, השלב הבא הוא לזהות איזו קומבינציה ספציפית של לקוח-שרת, אם בכלל, מניבה תוצאות בעייתיות. כדי לעשות את זה, צריך להקטין את מספר השרתים בעורף ב-50% עד שמספר השרתים מגיע ל-1, ובמקביל לשחזר את ההתנהגות הבעייתית (לדוגמה, חביון גבוה או ללא תגובות).

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

אם לא זוהה שילוב בעייתי של לקוח ושרת, אפשר לדלג אל בדיקת הביצועים.

ביצוע לכידה וניתוח של תנועה

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

  1. מתקינים את tcpdump בשרת.
  2. מפעילים את tcpdump בשרת.

  3. מלקוח, שולחים בקשה לדוגמה, כמו הבקשה הבאה:

    curl URL

  4. מנתחים את הפלט של tcpdump כדי לזהות את הבעיה.

ביצוע בדיקות ביצועים

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

  1. לקוח אחד ושרת אחד, ללא איזון עומסים.

  2. לקוח אחד ושרת אחד, עם איזון עומסים.

    תוצאה: שילוב התוצאות מבדיקות [1] ו-[2] מאפשר לזהות אם מאזן העומסים גורם לבעיה.

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

    תוצאה: זיהוי מכסת הביצועים של לקוח אחד.

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

    תוצאה: זיהוי מגבלת הביצועים של שרת אחד.

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

    תוצאה: זיהוי מגבלת הביצועים של הרשת.

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

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

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

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

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

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

פתרון בעיות במאזן עומסים כנקודת קפיצה הבאה

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

בעיות קישוריות

  • אם אי אפשר לבצע פינג לכתובת IP בטווח היעד של מסלול שהקפיצה הבאה שלו היא כלל העברה למאזן עומסי רשת פנימי מסוג העברת סיגנל ללא שינוי, חשוב לדעת שמסלול שמשתמש בסוג הזה של הקפיצה הבאה עשוי שלא לעבד תעבורת ICMP, בהתאם למועד שבו המסלול נוצר. אם המסלול נוצר לפני 15 במאי 2021, הוא מעבד רק תנועת TCP ו-UDP עד 16 באוגוסט 2021. החל מ-16 באוגוסט 2021, כל המסלולים יעבירו אוטומטית את כל התנועה בפרוטוקול (TCP,‏ UDP ו-ICMP) ללא קשר למועד שבו נוצר המסלול. אם אתם לא רוצים לחכות עד אז, אתם יכולים ליצור מסלולים חדשים ולמחוק את הישנים כדי להפעיל את הפונקציונליות של הפינג כבר עכשיו.

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

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

ערך לא תקין לטווח היעד

טווח היעד של מסלול סטטי בהתאמה אישית לא יכול להיות ספציפי יותר מכל מסלול של רשת משנה ברשת ה-VPC. אם קיבלתם את הודעת השגיאה הבאה כשניסיתם ליצור נתיב סטטי מותאם אישית:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

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

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

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

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

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

המאמרים הבאים