דיווח על מארח עם תקלה

אם נתקלתם בבעיות במכונת H4D וירטואלית שהזמנתם מראש ולא הצלחתם לפתור אותן בדרך אחרת – למשל, שגיאות חוזרות ונשנות במכשיר RDMA – מומלץ לדווח על המארח שלה כעל מארח פגום. כשמדווחים על מארח כפגום, Compute Engine מדווח על המארח כפגום ואז מתקן אוטומטית את המכונה הווירטואלית על ידי הפעלת תחזוקת המארח. במכונות וירטואליות מסוג H4D, כשמתחילה פעולת תחזוקה, Compute Engine מנסה להעביר את המכונה הווירטואלית למארח אחר, כדי לצמצם את זמן ההשבתה של עומס העבודה.

במאמר הזה מוסבר איך לדווח על מארחים פגומים ולתקן אותם במכונות וירטואליות (VM) שמשתייכות לאשכולות מבוססי-VM. לגבי אשכולות Google Kubernetes Engine ‏ (GKE), אפשר לעיין במאמר דיווח על מארחים פגומים דרך GKE.

מגבלות

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

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

  • המכונה הווירטואלית פועלת.

  • המכונה הווירטואלית משתמשת בסוג מכונה H4D.

  • המכונה הוירטואלית משתמשת במודל הקצאת משאבים שמוגבל להזמנה.

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

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

לפני שמתחילים

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

• צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

  המסוף

  כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

  gcloud

  מפעילים את Cloud Shell במסוף Google Cloud .

  הפעלת Cloud Shell

  בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  REST

  כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

  התקינו את ה-CLI של Google Cloud.

  אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

התפקידים הנדרשים

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

• Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) במכונה הווירטואלית או בפרויקט
• כדי לראות את הסטטוס של פעולת דיווח על מארח פגום באמצעות Cloud Logging: מציג היומנים (roles/logging.viewer) בפרויקט

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

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

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

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

• כדי ליצור דוח על מארח פגום: ‫compute.instances.update במכונה הווירטואלית
• כדי לראות רשימה של פעולות באמצעות Logging: logging.operations.list בפרויקט
• כדי לראות את פרטי הפעולה באמצעות Logging: logging.operations.get בפרויקט
• כדי לראות רשימה של פעולות ב-Compute Engine: compute.zoneOperations.list בפרויקט
• כדי לראות את פרטי הפעולה ב-Compute Engine: compute.zoneOperations.describe בפרויקט

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

הסבר על תהליך הדיווח על מארח פגום

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

	מצב מנוהל (HIGHLY_AVAILABLE_CAPACITY)
סוגי המכונות הנתמכים	H4D
הגבלת קצב בקשות שגויה של API לדוחות מארחים	יכול להיות שיהיו הגבלות על קצב הקריאות ל-API.
תהליך דיווח על מארח פגום	כשמדווחים על מארח פגום למכונה וירטואלית מסוג H4D שפועלת במצב מנוהל, מתרחשת הפעולה הבאה: דיווח על המארח הפגום: המכונה הווירטואלית נשארת במצב RUNNING במהלך פעולת הדיווח, שבדרך כלל נמשכת 10-12 דקות. כדי לבדוק את מצב הפעולה, קראו את הקטע בדיקת הפעולות של המארח שדווחו כתקולות במאמר הזה. מתחילים לתקן את המארח: אחרי שהדוח על פעולת המארח הפגומה מסתיים, פעולת התיקון של המארח מתחילה תוך דקה. כשהפעולה של תיקון המארח מתחילה, המכונה הווירטואלית נעצרת והמצב שלה משתנה בהתאם להגדרה של הפעלה מחדש אוטומטית (automaticRestart) שצוינה למכונה הווירטואלית: אם ההפעלה מחדש האוטומטית מופעלת ב-VM, המצב של ה-VM משתנה ל-REPAIRING. המכונה הווירטואלית מופעלת מחדש באופן אוטומטי כשהמארח שלה תקין, אלא אם עוצרים את המכונה הווירטואלית לפני כן. אם ההפעלה מחדש האוטומטית מושבתת במכונה הווירטואלית, מצב המכונה הווירטואלית משתנה ל-TERMINATED. צריך להפעיל מחדש את ה-VM באופן ידני אחרי שהמארח תקין. תיקון המארח הפגום יכול להימשך 3-14 ימים, ולפעמים אפילו יותר. העברה והפעלה מחדש של המכונה הווירטואלית: אחרי שפעולת התיקון של המארח מתחילה (בדרך כלל תוך 10-12 דקות), מערכת Compute Engine מנסה לשריין עוד מארח אחד כדי להחליף את המארח הפגום שדיווחתם עליו בקיבולת השמורה שלכם. אם Compute Engine מוצא מארח תקין – אם הוא מחליף בהצלחה את המארח הפגום או מוצא מארח תקין תואם בקיבולת השמורה שלכם – אז Compute Engine מעביר את המכונה הווירטואלית למארח הזה. לאחר מכן, מפעילים מחדש את המכונה הווירטואלית באחת מהדרכים הבאות: אם מכונת ה-VM במצב REPAIRING ויש משאבים זמינים לפני או בזמן השלמת התיקון, מערכת Compute Engine מפעילה מחדש את מכונת ה-VM באופן אוטומטי במארח תקין. אחרת, אם ה-VM במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי שהתיקון מסתיים, מצב ה-VM נשאר או משתנה ל-TERMINATED. צריך להפעיל מחדש את ה-VM באופן ידני כשרוצים להריץ אותו. עם זאת, יכול להיות שההפעלה מחדש של ה-VM תיכשל אם המשאבים לא יהיו זמינים כשמפעילים מחדש את ה-VM. למשל, זה יכול לקרות אם מכונות וירטואליות אחרות כבר משתמשות במארח שתוקן.

דיווח על מארח בעייתי

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

1. בודקים את המארח שבו פועלת המכונה הווירטואלית.

   הוראות מפורטות מופיעות במאמר בנושא הצגת טופולוגיית אשכול H4D.

2. אופציונלי: גיבוי נתונים ב-SSD מקומי. כשמפסיקים את המכונה הווירטואלית, Compute Engine משליך באופן אוטומטי את הנתונים של כל דיסקי ה-SSD המקומיים שמצורפים למכונה הווירטואלית. אי אפשר לשחזר נתונים של Local SSD אחרי ש-Compute Engine מחק אותם.

   הוראות לשמירת נתונים ב-SSD מקומי מופיעות במאמר גיבוי נתונים ב-SSD מקומי.

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

   gcloud

   כדי לדווח על מארח פגום, משתמשים בפקודה gcloud compute instances report-host-as-faulty הבאה:

   gcloud compute instances report-host-as-faulty VM_NAME \
       --async \
       --disruption-schedule=IMMEDIATE \
       --fault-reasons=behavior=FAULT_REASON,description=DESCRIPTION \
       --zone=ZONE
   

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

   • ‫VM_NAME: שם המכונה הווירטואלית.

   • ‫FAULT_REASON: רשימה של בעיות במארח שהתרחשו במכונה הווירטואלית, מופרדות בפסיקים. לדוגמה, ISSUE_1,ISSUE_2. אפשר לציין את הערכים הבאים:

     • ‫PERFORMANCE: אתם רואים ירידה בביצועים של ה-CPU או של פעולת הרשת Cloud RDMA, כשלים בממשק הרשת IRDMA או שהמכשיר ברשת IRDMA לא קיים.

     • ‫SILENT_DATA_CORRUPTION: הנתונים במכונה הווירטואלית נפגמו, אבל המכונה הווירטואלית ממשיכה לפעול. פגם שקט בנתונים יכול לנבוע מבעיות כמו פגמים ב-vCPU, באגים בתוכנה או בעיות בקרנל.

     • ‫BEHAVIOR_UNSPECIFIED: אתם לא בטוחים איזו בעיה משפיעה על המכונה הווירטואלית או שהבעיה לא נכללת באפשרויות האחרות.

   • ‫DESCRIPTION: תיאור הבעיה שמשפיעה על ה-VM, כמו מידע על XID או חשד לבעיות בביצועים.

   • ‫ZONE: האזור שבו נמצאת המכונה הווירטואלית.

   REST

   כדי לדווח על מארח פגום, צריך לשלוח את בקשת ה-POST הבאה ל-method‏ instances.reportHostAsFaulty.

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

   POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/reportHostAsFaulty
   
   {
     "disruptionSchedule": "IMMEDIATE",
     "faultReasons": [
       {
         "behavior": "FAULT_REASON_1",
         "description": "DESCRIPTION_1"
       },
       {
         "behavior": "FAULT_REASON_2",
         "description": "DESCRIPTION_2"
       }
     ]
   }
   

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

   • ‫PROJECT_ID: מזהה הפרויקט שבו נמצא ה-VM.

   • ‫ZONE: האזור שבו נמצאת המכונה הווירטואלית.

   • ‫VM_NAME: שם ה-VM.

   • ‫FAULT_REASON_1 ו-FAULT_REASON_2: כל בעיה במארח שנתקלה בה מכונת ה-VM. אפשר לציין את הערכים הבאים:

     • ‫PERFORMANCE: אתם רואים ירידה בביצועים של המעבד (CPU) או של פעולת הרשת של RDMA, כשלים במכשיר RDMA או שמכשיר ה-RDMA לא קיים.

     • ‫SILENT_DATA_CORRUPTION: נתוני המכונה הווירטואלית פגומים, אבל המכונה הווירטואלית ממשיכה לפעול. פגם שקט בנתונים יכול לנבוע מבעיות כמו פגמים במעבדים וירטואליים, באגים בתוכנה או בעיות בקרנל.

     • ‫BEHAVIOR_UNSPECIFIED: אתם לא בטוחים מה הבעיה במכונה הווירטואלית.

   • ‫DESCRIPTION_1 ו-DESCRIPTION_2: תיאור של כל בעיה במארח שציינתם, כמו מידע על XID או חשד לבעיות בביצועים.

דוח ביקורות על פעולות מארח לא תקינות

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

1. סימון המארח כפגום. ‫Compute Engine יוצר את הדוח faulty host operation. הפעולה report faulty host יוצרת רצף של פעולות משנה. פעולות המשנה האלה מסמנות את המארח הבסיסי כפגום.

2. הכנת המארח לתיקונים. אחרי שכל פעולות המשנה מסתיימות, מתחילה הפעולה report faulty host. המכונה הווירטואלית מופסקת על ידי Compute Engine, והפעולה לתיקון המארח הפגום מתחילה. בהתאם למצב ההפעלה של ההזמנה שצוין בהזמנה שבה נעשה שימוש במכונה הווירטואלית, ואם יש מארחים תקינים, מערכת Compute Engine משאירה את המכונה הווירטואלית במצב מושבת או מנסה להעביר אותה באופן אוטומטי ולהפעיל אותה מחדש.

3. השלמת הדיווח ותיקון המארח ‫Compute Engine משלים את הפעולה של דיווח על מארח פגום, ומתחילה פעולת התיקון של המארח.

כדי לעקוב אחרי הסטטוס של פעולות הדיווח על מארח פגום (compute.instances.reportHostAsFaulty) בפרויקט, בוחרים באחת מהאפשרויות הבאות. מידע נוסף על פעולות אחרות שאפשר להשתמש בהן כדי לעקוב אחרי תיקונים, העברות והפעלה מחדש אוטומטית זמין במאמרים התנהגויות של תחזוקה והפעלה מחדש ומעקב ותכנון של אירוע תחזוקה של מארח במסמכי התיעוד של Compute Engine.

מסוף (פעולות ב-VM)

1. נכנסים לדף Operations במסוף Google Cloud .

   מעבר אל 'פעולות'

2. בטבלה שמופיעה, מאתרים את המכונה הווירטואלית שדיווחתם עליה.

3. בשורה שמכילה את המכונה הווירטואלית, בעמודה סטטוס, אפשר לראות את הסטטוס של הפעולה 'דיווח על פעולת מארח פגומה'. כשהפעולה מסתיימת, הערך הוא Done.

4. אופציונלי: כדי לוודא שמערכת Compute Engine הפעילה מחדש את המכונה הווירטואלית, מעיינים בפרטים של המכונה הווירטואלית.

מסוף (יומני VM)

1. נכנסים לדף Logs Explorer במסוף Google Cloud .

   כניסה לדף Logs Explorer

2. מוודאים שהמתג הצגת השאילתה מופעל.

3. בעורך השאילתות, מזינים את השאילתה הבאה:

   resource.type="gce_instance" AND protoPayload.methodName=~"compute\.instances\.reportHostAsFaulty"
   

4. לוחצים על Run query. בחלונית Query results מוצגות תוצאות השאילתה.

gcloud

1. כדי לראות את הסטטוס של פעולות המארח הפגומות בדוח בפרויקט, משתמשים בפקודה gcloud compute operations list עם הדגל --filter שמוגדר לערך operationType:compute.instances.reportHostAsFaulty:

   gcloud compute operations list --filter="operationType:compute.instances.reportHostAsFaulty"
   

2. כדי לראות את הפרטים של פעולה ספציפית של מארח עם שגיאה, משתמשים בפקודה gcloud compute operations describe:

   gcloud compute operations describe OPERATION_NAME \
       --zone="ZONE"
   

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

   • ‫OPERATION_NAME: שם הפעולה.

   • ‫ZONE: האזור שבו הפעולה מתבצעת.

REST

כדי לראות את הסטטוס של פעולות הדיווח על מארחים פגומים בפרויקט, שולחים בקשת GET ל-method‏ zoneOperations.list. בכתובת ה-URL של הבקשה, כוללים את פרמטר השאילתה filter שמוגדר לערך items.operationType:compute.instances.reportHostAsFaulty.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/operations&filter=items.operationType:compute.instances.reportHostAsFaulty

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

• ‫PROJECT_ID: שם הפעולה.

• ‫ZONE: האזור שבו נמצאות הפעולות.

מה השלב הבא?

• אם נתקלתם בבעיות בדיווח על מארח פגום, עיינו במאמר פתרון בעיות ב-API של מארח פגום.