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

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

כברירת מחדל, רוב המקרים מוגדרים להעברה פעילה במהלך אירועים במארח. בכל סדרות המכונות חוץ מסדרת Z3, אפשר לשנות את ההתנהגות הזו ולהגדיר במפורש את המופעים כך שהם יסתיימו ואופציונלית יופעלו מחדש. חלק מסוגי המכונות לא תומכים במיגרציה פעילה, כמו מכונות H4D, מכונות Bare Metal, מכונות עם יחידות GPU מצורפות או מכונות Z3 עם יותר מ-18 TiB של Titanium SSD מצורף. המופעים האלה מופסקים במהלך אירועים שמתארחים ב-VM. מידע נוסף זמין במאמר בנושא התנהגויות של תחזוקה והפעלה מחדש.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במהלך מיגרציה פעילה, 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 מנסה להפעיל מחדש את המכונה בשרת מארח אחר באותו אזור. למופעי 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 נשמרים בתרחישים הבאים:

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

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

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

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

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

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

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

אם מגדירים את הזמן הקצוב לתפוגה של שחזור 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. כשמקבלים התראה, יש פרק זמן שבו אפשר להתחיל את התחזוקה המתוזמנת בשעה שבוחרים. אם לא תפעילו את התחזוקה המתוזמנת, אירוע התחזוקה יתרחש בסוף תקופת ההודעה, כלומר במועד המתוזמן שמופיע בהודעה.

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

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