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

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

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

  • מכונות H4D
  • מכונות Z3 עם יותר מ-18 TiB של כונני Titanium SSD מצורפים
  • מכונות Z4D עם יותר מ-42 TiB של Titanium SSD מצורף
  • 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 משקיע בשחזור הנתונים בדיסקים של SSD מקומי אחרי זיהוי שגיאת מארח. הנתונים ב-SSD המקומי יאבדו אם הזמן שצוין יחלוף בלי שהשחזור יצליח.

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

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

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

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

  • מופעים שמבוססים על סוגי המכונות הבאים מסיימים את הפעולה ומופעלים מחדש במקום:
    • ‫Z3 עם יותר מ-18 TiB של Titanium SSD
    • ‫Z4D עם יותר מ-42 TiB של Titanium SSD
    • ‫X5,
    • X4
    • H4D
  • מכונות Bare metal מסיימות את הפעולה ומופעלות מחדש, כלומר הן עשויות להיות מופעלות מחדש במארח אחר. פרטים נוספים זמינים במסמכי התיעוד בנושא "חוויית תחזוקה" של סדרת המכונות. לדוגמה, במאמר חוויית התחזוקה של מכונות C3 מוסבר על סוגי מכונות Bare Metal מסוג C3.
  • מכונות וירטואליות חסויות, למעט סוגי מכונות N2D עם פלטפורמות מעבד AMD EPYC Milan שמריצות AMD SEV.
  • Instances with GPUs
  • Instances with TPUs

העברה בזמן אמת

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

במהלך מיגרציה פעילה, מערכת 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 מנסה לשחזר מכונות עם דיסקים מקומיים של SSD שמצורפים אליהן למשך שעה. אם מגיעים למגבלת הזמן, מערכת Compute Engine מנסה להפעיל מחדש את המכונה בשרת מארח אחר באותו אזור. למופעי Z4D,‏ Z3,‏ X4 ו-H4D יש זמני המתנה שונים כברירת מחדל. סוגי המכונות האלה מופעלים מחדש באותו שרת מארח אחרי סיום המכונה.

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

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

compute.instances.automaticRestart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תזמון תחזוקה

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

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

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