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

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

משתמשים בפקודה report-host-as-faulty כדי לדווח על מארח פגום, ומשתמשים בפרמטר --fault-behavior כדי לספק מידע נוסף על הבעיה.

gcloud compute instances report-host-as-faulty TPU_NAME \
    --fault-reasons=behavior=FAULT_BEHAVIOR,description=DESCRIPTION \
    --disruption-schedule=DISRUPTION_SCHEDULE

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

  • ‫TPU_NAME: השם של מכונת ה-TPU.

  • ‫FAULT_BEHAVIOR: אפשר להעביר אחד מהערכים הבאים:

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

  • DESCRIPTION: תיאור הבעיה שמשפיעה על המכונה הווירטואלית.

  • ‫DISRUPTION_SCHEDULE: מציין את התזמון להפעלת תהליך הדיווח על תקלות. ערך ברירת המחדל הוא IMMEDIATE, שמתחיל את התהליך באופן מיידי. הערך של DISRUPTION_SCHEDULE חייב להיות אחד מהערכים הבאים: IMMEDIATE,‏ FUTURE.

הדיווח על פעולת מארח פגומה נמשך בדרך כלל 10-12 דקות. אחרי שפעולת הדוח מסתיימת, תיקון המארח מתחיל תוך דקה אם לשיבוש מוגדר לוח זמנים של IMMEDIATE. אם התזמון של השיבוש מוגדר ל-FUTURE, לא מתבצע תיקון באופן מיידי. במקום זאת, Compute Engine מתזמן תיקון אם בעתיד מזוהה תקלה כלשהי. אחרי שהתיקון מתחיל, המכונה הווירטואלית מושבתת. יכול להיות שהמכונה הווירטואלית תישאר במצב PENDING עד שהמארח יתוקן. תיקון המארח הפגום יכול להימשך 3-14 ימים או יותר. במצב 'כל הקיבולת' של TPU, מכונות וירטואליות של TPU לא מועברות למארח אחר במהלך התיקון. במקום זאת, הם יופעלו מחדש באותו מארח אם יש בו מספיק קיבולת.