תובנות לגבי מאזן עומסים

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

צפייה בתובנות ב-Recommender API

כדי לראות את התובנות האלה ב-CLI של gcloud או ב-Recommender API, משתמשים בסוג התובנה הבא:

  • google.networkanalyzer.networkservices.loadBalancerInsight

נדרשות ההרשאות הבאות:

  • recommender.networkAnalyzerLoadBalancerInsights.list
  • recommender.networkAnalyzerLoadBalancerInsights.get

מידע נוסף על השימוש ב-Recommender API לתובנות של Network Analyzer זמין במאמר שימוש ב-Recommender CLI וב-API.

חומת האש של בדיקת התקינות לא מוגדרת

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

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

המלצות

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

טווח כתובות ה-IP של בדיקת תקינות חסום

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

המלצות

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

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

ההגדרה של חומת האש לא עקבית

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

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

המלצות

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

טווח כתובות ה-IP של בדיקת תקינות חסום חלקית

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

  • ‫Load balancer: שם מאזן העומסים
  • כלל העברה: השם של כלל ההעברה הספציפי
  • רשת: שם הרשת שבה מאזן העומסים מוגדר
  • חומות אש חוסמות: שם חומות האש שחוסמות טווחי בדיקות תקינות
  • חומות אש שמאפשרות תעבורה באופן חלקי: השם של חומות האש שמאפשרות תעבורה של בדיקות תקינות במכונות וירטואליות של קצה עורפי שהוגדרו כראוי
  • קצוות עורפיים שההגדרה שלהם שגויה: קצוות עורפיים שבהם הגדרת חומת האש לטווח של בדיקת תקינות לא פועלת בצורה תקינה
  • טווחי כתובות IP חסומים של בדיקות תקינות: טווחי כתובות IP שבהם התנועה של בדיקות התקינות חסומה

המלצות

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

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

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

התובנה הזו כוללת את המידע הבא:

  • שירות לקצה העורפי: השירות לקצה העורפי שהושפע.
  • כללי העברה: כללי ההעברה שמפנים את התנועה לשירות הקצה העורפי הזה.
  • זיקה לסשן: הזיקה לסשן שבה נעשה שימוש בשירות לקצה העורפי.
  • שרתי קצה עורפיים מושפעים: שרתי הקצה העורפיים שמשתמשים במצב איזון UTILIZATION.

המלצות

כדי להשתמש בזיקה לסשן שאינה NONE, צריך להשתמש במצב איזון עומסים RATE או CONNECTION. אפשר לבצע את הפעולה הזו רק באמצעות Google Cloud CLI או Compute Engine API, ולא במסוף Google Cloud .

בשירותי בק-אנד של מאזן עומסים מסוג proxy שמשתמשים בפרוטוקולים HTTP,‏ HTTPS או HTTP/2, אפשר להחליף את מצב האיזון ל-RATE באמצעות הפקודה gcloud compute backend-services update-backend ולבחור באפשרות rate balancing mode.

בדוגמת הקוד הבאה אפשר לראות איך משתמשים בפקודה הזו כדי להעביר את המצב ל-RATE:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    BACKEND_SERVICE_SCOPE \
    --instance-group=INSTANCE_GROUP_NAME \
    INSTANCE_GROUP_SCOPE \
    --balancing-mode=RATE \
    TARGET_CAPACITY

בשירותי בק-אנד של שרת proxy לאיזון עומסים שמשתמשים בפרוטוקולים שאינם HTTP (כמו TCP או SSL), צריך להחליף את מצב האיזון ל-CONNECTION באמצעות הפקודה gcloud compute backend-services update-backend ולבחור באפשרות connection balancing mode (מצב איזון חיבורים).

בדוגמת הקוד הבאה אפשר לראות איך משתמשים בפקודה הזו כדי להעביר את המצב ל-CONNECTION:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    BACKEND_SERVICE_SCOPE \
    --instance-group=INSTANCE_GROUP_NAME \
    INSTANCE_GROUP_SCOPE \
    --balancing-mode=CONNECTION \
    TARGET_CAPACITY

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

  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
  • ‫BACKEND_SERVICE_SCOPE: ההיקף של שירות הקצה העורפי. לשירותים לקצה עורפי גלובלי, משתמשים ב---global. בשירותים לקצה עורפי אזורי, משתמשים ב---region=REGION ומחליפים את REGION באזור.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת השרתים העורפיים.
  • ‫INSTANCE_GROUP_SCOPE: המיקום של קבוצת המכונות. לקבוצות מנוהלות של מופעי מכונה אזוריים, משתמשים ב---region=REGION, ומחליפים את REGION באזור. לקבוצות של מופעים אזוריים, משתמשים ב---zone=ZONE ומחליפים את ZONE באזור.
  • ‫TARGET_CAPACITY: שיעור יעד או מפרט של חיבור יעד. כדי להשתמש במצב איזון קצב, משתמשים בדגלים --max-rate= או --max-rate-per-instance=. מידע נוסף זמין במאמר בנושא מצב איזון קצב בסקירה הכללית של שירותי קצה עורפיים. במצב איזון חיבורים מסוג drop, משתמשים בדגלים --max-connections= או --max-connections-per-instance=. מידע נוסף זמין במאמר מצב איזון חיבורים בסקירה הכללית של שירותי ה-Backend.

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

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

התובנה הזו כוללת את המידע הבא:

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

פרטים נוספים זמינים במאמר בנושא קטגוריה ומפרט יציאות.

המלצות

מגדירים את בדיקת תקינות באמצעות use serving port specification כדי שבדיקת התקינות תשתמש באותו פורט שבו משתמש שירות לקצה העורפי. בדוגמת הקוד הבאה מוצגות פקודות של Google Cloud CLI לעדכון בדיקת תקינות כדי להשתמש ביציאת ההגשה:

gcloud compute health-checks update PROTOCOL HEALTH_CHECK_NAME \
      HEALTH_CHECK_SCOPE \
      --use-serving-port

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

  • ‫PROTOCOL: הפרוטוקול שמשמש בבדיקת תקינות.
  • ‫HEALTH_CHECK_NAME: השם של בדיקת התקינות.
  • ‫HEALTH_CHECK_SCOPE: היקף בדיקת התקינות. לביצוע בדיקות תקינות גלובליות, צריך להשתמש ב---global. למעקב אחר תקינות אזורי, משתמשים ב---region=REGION, ומחליפים את REGION באזור.

אישורי SSL לא משויכים למאזני עומסים

המשמעות היא שלפרויקט יש אישורי SSL בניהול Google שלא משויכים למאזן עומסים שמטפל בתנועת SSL או HTTPS. אי אפשר להשתמש באישורי SSL בניהול Google עד שמצרפים אותם למאזן עומסים. אפשר לראות את רשימת האישורים הלא מצורפים בפרטי התובנות.

המלצות

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

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

אישורי SSL שמשויכים למאזן עומסים שלא חושף את יציאה 443

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

המלצות

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