מידע על אירועים של מארחים

במהלך מחזור החיים של מכונה וירטואלית (VM) או מכונת Bare Metal, יכולים להתרחש במכונת המארח שבה המכונה פועלת כמה אירועים שקשורים למארח. אירוע מארח יכול לכלול תחזוקה שוטפת של תשתית Compute Engine, או במקרים נדירים, שגיאת מארח. אתם יכולים להגדיר את מדיניות תחזוקת המארח כדי לבחור איך מופעלות התגובות של מופעי המחשוב במהלך אירוע במארח או אחריו.

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

  • מכונות H4D
  • מכונות Z3 עם יותר מ-18,000 GiB של Titanium SSD מצורף
  • מכונות Z4D ו-Z4M עם יותר מ-42,000GiB של Titanium SSD מצורף
  • מכונות עם ממשק רשת של Cloud RDMA
  • מכונות Bare Metal
  • מכונות עם מעבדי GPU מצורפים

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

סוגי אירועים של מארחים

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

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

אירועי תחזוקה

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

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

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

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

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

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

תחזוקה דחופה

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

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

אם יש אירוע תחזוקה מתוכנן בהמתנה כש-Compute Engine שולח התראה על תחזוקה דחופה, אירוע התחזוקה הדחופה מחליף את אירוע התחזוקה המתוכנן.

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

שגיאות שקשורות למארח

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

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

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

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

‫Google מציעה גם שירותים מנוהלים כמו App Engine וסביבה גמישה ב-App Engine.

סקירה כללית של מדיניות התחזוקה של המארח

מדיניות התחזוקה של המארח של מופע קובעת את אופן הפעולה שלו במהלך אירועי המארח הבאים:

  • אירוע תחזוקה
  • אירוע תחזוקה דחוף
  • אירוע שגיאה במארח או מופע לא מגיב

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

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

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

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

התנהגויות תחזוקה והפעלה מחדש

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

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

  • מופעים שמבוססים על סוגי המכונות הבאים מסיימים את הפעולה ומופעלים מחדש במקום:
    • ‫Z3 עם יותר מ-‎18,000 GiB של Titanium SSD
    • ‫Z4D או Z4M עם יותר מ-42,000 GiB של Titanium SSD
    • ‫Z4M שיש להם ממשק רשת Cloud RDMA
    • X5,
    • X4
    • H4D
  • מכונות Bare Metal מסתיימות ומופעלות מחדש, כלומר הן עשויות להיות מופעלות מחדש במארח אחר. לפרטים נוספים, קראו את המאמר "חוויית התחזוקה" של סדרת המכונות. לדוגמה, במאמר חוויית התחזוקה של מכונות C3 מוסבר על סוגי מכונות Bare Metal מסוג C3.
  • Confidential VMs, חוץ מסוגי מכונות N2D עם פלטפורמות מעבד AMD EPYC Milan שמריצות AMD SEV.
  • מכונות עם מעבדים גרפיים (GPU)
  • מכונות עם יחידות TPU

מיגרציה פעילה

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

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

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

compute.instances.migrateOnHostMaintenance

סיום והפעלה מחדש

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

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

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

compute.instances.terminateOnHostMaintenance

הפעלה מחדש אוטומטית

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

כברירת מחדל, Compute Engine מנסה לשחזר מכונות עם דיסקים מסוג Local SSD במשך שעה. אם מגיעים למגבלת הזמן, מערכת Compute Engine מנסה להפעיל מחדש את המכונה בשרת מארח אחר באותו אזור. למופעי Z4D,‏ Z4M,‏ Z3,‏ X4 ו-H4D יש זמני המתנה שונים כברירת מחדל. סוגי המכונות האלה מופעלים מחדש באותו שרת מארח אחרי סיום המכונה.

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

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

compute.instances.automaticRestart

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

מכיוון ש- Persistent Disk ו-Hyperdisk הם אחסון ברשת (NAS), כשמפעילים מחדש את המכונה, Compute Engine מחבר מחדש את דיסק האתחול ואת כל הדיסקים המשניים למכונה. הנתונים בדיסקים האלה נשמרים במהלך מיגרציה פעילה והפעלות מחדש של המכונות.

ב-Compute Engine, הנתונים בדיסקי SSD מקומיים נשמרים אחרי אירוע במארח, אם אפשר. עם זאת, ב-Compute Engine אין הבטחה לשמירת נתונים ב-SSD מקומי.

  • דיסקים מסוג SSD מקומי נשמרים בתרחישים הבאים:

    • אתם מפעילים מחדש את מערכת ההפעלה (OS) של האורח.
    • אתם מגדירים את המכונה למיגרציה פעילה, והמכונה עוברת אירוע תחזוקה של המארח.
    • מתרחשת שגיאה במארח, ו-Compute Engine מחבר מחדש את המכונה לדיסקים של Local SSD במסגרת מגבלת הזמן הקצוב לתפוגה.
    • בחרתם לשמור את הנתונים ב-SSD המקומי כשאתם עוצרים או משעים את המכונה (גרסת טרום-השקה (Preview)).
    • מכונת Compute עם דיסקים מסוג SSD מקומיים שמחוברים אליה, שתומכת רק בסיום ובהפעלה מחדש אוטומטית, עוברת אירוע תחזוקה. המופע מופעל מחדש במקום, והנתונים ב-SSD המקומי נשמרים, במקום להעביר אותם למארח חדש.

  • דיסקים מסוג SSD מקומי לא נשמרים בתרחישים הבאים:

    • אתם מכבים את מערכת ההפעלה של האורח ומאלצים את המכונה להפסיק.
    • אתם יוצרים VM במודל Spot או VM זמני, וה-VM עובר את תהליך ההפקעה.
    • אתם מגדירים את המכונה כך שהיא תפסיק לפעול באירועי תחזוקה של המארח במקום להשתמש במיגרציה פעילה, והמכונה עוברת אירוע תחזוקה של המארח.
    • הגדרתם באופן שגוי דיסק SSD מקומי, ואי אפשר לגשת אליו.
    • השבתתם את החיוב בפרויקט, ולכן המופע הופסק.
    • אם automaticRestart לא מוגדר במופע שלכם.
    • מתרחשת שגיאת מארח ו-Compute Engine לא מצליח לחבר מחדש את הדיסקים למופע לפני שפג הזמן הקצוב לתפוגה. במקרה כזה, המכונה מופעלת מחדש בלי לשחזר את כונני ה-SSD המקומיים. כשהמכונה מופעלת מחדש, Compute Engine מצרף דיסקים ריקים של SSD מקומי למכונה שהופעלה מחדש. כדי שהמופע יוכל להשתמש בדיסקים האלה, צריך לפרמט אותם ולהוסיף אותם. אי אפשר לשחזר את הנתונים בדיסקים המקוריים של ה-SSD המקומי.

Google Cloud משתמש בגישה של "המאמץ המרבי" כדי לשמור על הנתונים ב-SSD המקומי. עם זאת, יש מקרים שבהם אי אפשר לשחזר נתונים, כמו במקרה של זמן קצוב לתפוגה. מידע נוסף על המקרים שבהם נשמרים דיסקים מסוג Local SSD זמין במאמר שמירת נתונים ב-Local SSD.

זמן קצוב לתפוגה של שחזור SSD מקומי

כשמופע עם דיסקים מקומיים של SSD מצורפים עובר למצב REPAIRING, ‏ Compute Engine מנסה לשחזר או לשמור את הנתונים של ה-SSD המקומי. המופע ודיסקי ה-SSD המקומיים לא זמינים במהלך הזמן הזה.

מכונה נכנסת למצב REPAIRING ומתחילה את הספירה לאחור של זמן הקצוב לשחזור של Local SSD בתרחישים הבאים:

  • אירעה שגיאה במארח.
  • תחזוקה מתוזמנת מתבצעת במכונה שתומכת בשימור נתונים בכונן SSD מקומי אחרי סיום הפעולה, והמכונה מוגדרת גם לעצירה במהלך תחזוקת המארח (onHostMaintenance מוגדר ל-TERMINATE) וגם להפעלה מחדש אוטומטית (automaticRestart מוגדר ל-true). במהלך התחזוקה, Compute Engine משמר את הנתונים על ידי הפעלה מחדש של המכונה במקום באותו מארח, או על ידי העברת המכונה והנתונים בכונן ה-SSD המקומי שלה למארח אחר בזמן שהיא מושבתת.

אתם יכולים לקבוע כמה זמן Compute Engine ינסה לשחזר או לשמור את הנתונים באמצעות ההגדרה localSsdRecoveryTimeout של מדיניות המארח. כברירת מחדל, מערכת Compute Engine מקדישה שעה לשחזור הנתונים, אבל הערכים התקינים להגדרה הזו הם בין 0 ל-168, במרווחים של שעה. לסוגי המכונות הבאים יש ערכי ברירת מחדל שונים:

  • סוגי מכונות VM‏ Z4D,‏ Z4M ו-Z3: ערך ברירת המחדל הוא 6, כלומר המכונות האלה מנסות לשחזר את נתוני ה-SSD המקומי במשך 6 שעות במצב REPAIRING לפני שהן מגיעות למגבלת הזמן הקצוב לתפוגה.
  • Z4M bare metal ו-Z3 bare metal: ערך ברירת המחדל הוא 168 שעות (7 ימים).

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

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

אם מגדירים את זמן הקצוב לתפוגה של שחזור ה-SSD המקומי לערך המקסימלי של 168, המכונה נשארת במצב REPAIRING למשך עד 7 ימים בזמן ש-Compute Engine מנסה לשחזר את דיסקי ה-SSD המקומיים.

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

הפסקת השחזור של דיסק SSD מקומי

אתם יכולים להפסיק את תהליך השחזור של דיסק ה-SSD המקומי לפני ש-Compute Engine מגיע למגבלת הזמן הקצוב לשחזור. כדי לעשות זאת, משתמשים בפקודה gcloud compute instances stop עם הדגל --discard-local-ssd=True.

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

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

תזמון תחזוקה

ב-Google Cloud יש תכונות שמאפשרות שליטה הדוקה יותר על התחזוקה. בסוגים מסוימים של מכונות, אתם יכולים להגדיר העדפות תחזוקה ולקבל התראות על אירועי תחזוקה קרובים דרך Cloud Logging, שרת המטא-נתונים של המכונה, הפקודה compute instances describe ב-CLI של gcloud או ה-method‏ instances.describe ב-REST. אחרי קבלת ההתראה, יש לכם פרק זמן מסוים שבו אתם יכולים להתחיל את התחזוקה המתוזמנת בזמן שאתם בוחרים. אם לא תפעילו את התחזוקה המתוזמנת, אירוע התחזוקה יתרחש בסוף תקופת הזמן של ההתראה, כלומר בזמן המתוזמן שמופיע בהתראה.

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

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