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

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

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

מגבלות

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

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

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

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

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

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

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

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

  המסוף

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

  gcloud

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

  gcloud init

  REST

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

  התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. אופציונלי: גיבוי נתונים ב-SSD מקומי. כשמפסיקים את המכונה הווירטואלית, Compute Engine משליך באופן אוטומטי את הנתונים של כל דיסקי ה-SSD המקומיים שמצורפים למכונה הווירטואלית. אי אפשר לשחזר נתונים של 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: שם ה-VM.

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

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

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

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

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

     • ‫PERFORMANCE: אתם רואים ירידה בביצועים של המעבד או של פעולת רשת 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.

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

מה השלב הבא?

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