פתרון בעיות בכיבוי ובאתחול מחדש של מכונות וירטואליות

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

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

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

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

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

  המסוף

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

  gcloud

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

     gcloud init

     אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

     הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
• הגדרת אזור ותחום כברירת מחדל

אבחון של כיבויים והפעלה מחדש של מכונות

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

שאילתות ביומני ביקורת של Cloud

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

ההרשאות שנדרשות למשימה הזו

כדי לבצע את המשימה הזו נדרשות ההרשאות הבאות:

• התפקיד Logging/מציג היומנים או התפקיד Project/צפייה.

המסוף

1. נכנסים לדף Logs Explorer במסוף Google Cloud .

   כניסה לדף Logs Explorer

   הערה: יכול להיות שתצטרכו ללחוץ על שדרוג כדי להשתמש ב-Logs Explorer במקום בכלי הישן לצפייה ביומנים.

2. בשדה Query, מזינים את השאילתה הבאה:

   resource.type="gce_instance"
   "VM_NAME"
   logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")
   

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

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

   

4. לוחצים על Run query. התוצאות מוצגות בקטע Query results.

   כדאי לדעת: כדי להגדיל את גודל הקטע Query results, לוחצים על Enter fullscreen Query results.

5. לוחצים על החץ להרחבה לצד כל תוצאה כדי להציג מידע מפורט.

6. במאמר בדיקת יומני הביקורת של Cloud מוסבר בהרחבה על השדות method ו-principalEmail שמשויכים לכיבויים ולהפעלות מחדש, ומה אפשר לעשות כדי למנוע אותם.

gcloud

1. כדי להציג את יומני הביקורת של Cloud, משתמשים בפקודה gcloud logging read:

   gcloud logging read --freshness=TIME 'resource.type="gce_instance" "VM_NAME" logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")'
   

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

   • ‫TIME: משך הזמן שרוצים לשלוח לגביו שאילתה. לדוגמה, 1h שולח שאילתות לרשומות ביומן בשעה האחרונה. מידע על פורמטים של תאריך ושעה זמין במאמר gcloud topic datetimes.
   • ‫VM_NAME: שם המכונה הווירטואלית שכובתה או הופעלה מחדש.

   התוצאות מוצגות.

2. במאמר בדיקת יומני ביקורת של Cloud מוסבר על השדות method ו-principalEmail שקשורים לכיבוי ולהפעלה מחדש, ועל הפעולות שאפשר לעשות כדי למנוע אותם.

בדיקת יומני ביקורת של Cloud

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

1. בודקים את השדות method של יומני הביקורת של Cloud ומשווים אותם ל-methods שמפורטות בטבלה הבאה.

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

   ‏Method	סוג הכיבוי	תיאור
   compute.instances.repair.recreateInstance	אירוע במערכת	אם המכונה הווירטואלית שייכת לקבוצת מופעי מכונה מנוהלים (MIG), קבוצת מופעי מכונה מנוהלים יוצרת מחדש את המכונה הווירטואלית אם המצב של המכונה הווירטואלית משתנה מ-RUNNING וקבוצת מופעי מכונה מנוהלים לא יזמה את השינוי במצב. שינויים במצב של מופע שלא מתחילים על ידי ה-MIG כוללים: כשלים בחומרה. הפסקת פעולה של VM במודל Spot. אירועים של תחזוקת תשתית כשלא מוגדרת מיגרציה פעילה של המכונה הווירטואלית. מחיקת מופע MIG באמצעות אחת מהשיטות הבאות: ה-Method ב-API של instances.delete הפקודה gcloud compute instances delete הערה: כדי לוודא שהשינויים בהגדרות לא יבוטלו על ידי ה-MIG, חשוב להשתמש בשיטות של הקבוצה. לדוגמה, כדי למחוק מופע מנוהל, משתמשים באחת מהשיטות הבאות: לקבוצת MIG אזורית: instanceGroupManagers.deleteInstances לקבוצת MIG אזורית: regionInstanceGroupManagers.deleteInstances ב-gcloud: gcloud compute instance-groups managed delete-instances
   compute.instances.hostError	אירוע של המערכת	שגיאה במארח (compute.instances.hostError) מציינת שהייתה בעיה בחומרה או בתוכנה במכונה הפיזית או בתשתית של מרכז הנתונים שמארח את מופע המחשוב שלכם, שגרמה לקריסת המופע. שגיאה במארח שקשורה לכשל מוחלט בחומרה או לבעיות אחרות בחומרה עשויה למנוע מיגרציה פעילה של המופע. אם המכונה שלכם מוגדרת להפעלה מחדש אוטומטית, שזו הגדרת ברירת המחדל, Compute Engine מפעיל מחדש את המכונה, בדרך כלל תוך שלוש דקות מהרגע שבו זוהתה השגיאה. בהתאם לבעיה, ההפעלה מחדש עשויה להימשך עד 5.5 דקות. אחרי שמתרחשת שגיאת מארח במכונה של Compute Engine, או אחרי שאתם מדווחים על המארח שלה כפגום, המארח של המכונה דורש תחזוקת חירום לא מתוכננת. כברירת מחדל, כשמתוזמן סוג כזה של תחזוקה, Compute Engine מספק הודעה מראש כמה שעות לפני כן. לפעמים, יכול להיות שמופע של מחשוב לא יגיב לפני שמוצגת שגיאת מארח. אפשר לקצר את משך הזמן ש-Compute Engine ממתין לפני הפעלה מחדש או סיום של המכונה על ידי הגדרת פסק הזמן להתאוששות משגיאה במארח. מידע נוסף זמין במאמר בנושא הגדרת המדיניות למופע קיים. תקלות פיזיות בחומרה ובתוכנה יכולות לקרות מדי פעם, אבל הן נדירות. כדי להגן על האפליקציות והשירותים שלכם מפני אירועי מערכת שעלולים לשבש את הפעילות, מומלץ לעיין במקורות המידע הבאים: תכנון מערכות עמידות תבניות לאפליקציות עמידות שניתנות להרחבה יצירת קבוצות מופעי מכונה מנוהלים ‫Google מציעה גם שירותים מנוהלים כמו App Engine וסביבה גמישה ב-App Engine.
   compute.instances.automaticRestart	אירוע במערכת	האירוע הזה מתרחש אחרי אירוע hostError או אירוע terminateOnHostMaintenance, אם מדיניות התחזוקה של המארח automaticRestart של ה-VM מוגדרת ל-true. ביומנים, לפני הרשומה הזו מופיעה רשומה עם hostError או terminateOnHostMaintenance. אם רוצים לשנות את מדיניות התחזוקה של המארח של מכונת ה-VM, אפשר לעיין במאמר אפשרויות עדכון של מופע.
   compute.instances.guestTerminate	אירוע במערכת	מערכת ההפעלה של המכונה הווירטואלית התחילה את תהליך הכיבוי.
   compute.instances.terminateOnHostMaintenance	אירוע של המערכת	אם הגדרתם את מדיניות התחזוקה של המארחonHostMaintenance של ה-VM לערך TERMINATE, מערכת Compute Engine תפסיק את ה-VM כשיש אירוע תחזוקה שבו Google צריכה להעביר את ה-VM למארח אחר. אם רוצים לשנות את onHostMaintenanceהמדיניות של מכונה וירטואלית, אפשר לעיין במאמר אפשרויות עדכון של מופע.
   compute.instances.preempted	אירוע במערכת	Compute Engine הפסיק לפני הזמן (preempt) את ה-VM במודל Spot או את ה-VM הזמני מדור קודם: כש-Compute Engine מבצעת דחיקה של VM במודל Spot, היא מפסיקה או מוחקת את VM במודל Spot בהתאם ל פעולת הסיום שלה. למכונות וירטואליות מסוג Spot אין זמן ריצה מקסימלי. כש-Compute Engine מבצעת דחיקה של מכונה וירטואלית שניתנת לדחיקה, היא מפסיקה את המכונה אחרי זמן ריצה מקסימלי של 24 שעות. כדי להימנע מהמגבלות האלה, כדאי להשתמש במכונות וירטואליות מסוג Spot. VM במודל Spot ו-VM זמני הם קיבולת עודפת של Compute Engine, ולכן יכול להיות ש-Compute Engine יפסיק את הפעולה שלהם בכל פעם שנדרשת קיבולת במקום אחר. כדי לצמצם את ההשפעות של הקדימות, מומלץ לפעול לפי השיטות המומלצות. לחלופין, אם אתם צריכים מכונות וירטואליות עם סביבות זמן ריצה בשליטת המשתמש, אתם יכולים ליצור מכונות וירטואליות רגילות במקום זאת.
   compute.instances.stop	פעילות של מנהל מערכת	משתמש או חשבון שירות הפסיקו את המכונה הווירטואלית. כדי לזהות את המשתמש או את חשבון השירות שהפסיקו את המכונה הווירטואלית, ממשיכים לשלב הבא. מידע על הפעלה מחדש של מכונה וירטואלית זמין במאמר הפעלה מחדש של מופע שהופסק.
   compute.instances.delete	פעילות אדמין או אירוע מערכת	משתמש או חשבון שירות מחקו את המכונה הווירטואלית, או שהמכונה הווירטואלית הוגדרה למחיקה אוטומטית. חשוב: בקשות למחיקת מכונה וירטואלית, שמסומנות בשיטה compute.instances.delete ביומני הביקורת של Cloud, עשויות לבטל באופן לא עקבי בקשות אחרות למכונה הווירטואלית שנשלחו בערך באותו הזמן. גם אם הבקשות האחרות האלה הצליחו, יכול להיות שהשיטה compute.instances.delete תמנע באופן לא עקבי מהשיטות של הבקשות האחרות האלה להופיע ביומני הביקורת של Cloud עבור ה-VM שלכם. ספציפית, יומן לשיטה compute.instances.delete עשוי להצביע על אחת מהבקשות הבאות ל-VM: בקשות ממשתמש או מחשבון שירות למחיקה ישירה של המכונה הווירטואלית מסומנות רק באמצעות שיטת compute.instances.delete מהמשתמש או מחשבון השירות. בקשות למחיקה אוטומטית של ה-VM מצוינות באמצעות השיטה compute.instances.delete מ[e-mail], אבל השיטה שמסבירה את הסיבה למחיקה האוטומטית עשויה להופיע או לא להופיע ביומני הביקורת של Cloud. לדוגמה, אם VM במודל Spot מוגדרת למחיקה אוטומטית במהלך הפסקה זמנית והיא נדחקת, תראו שיטה compute.instances.delete מ[e-mail], אבל יכול להיות שתראו גם שיטה compute.instances.preempted או לא. יכול להיות שב-Cloud Audit Logs יופיעו בקשות למכונה הווירטואלית שהתרחשו זמן קצר לפני או אחרי שיטה של compute.instances.delete, ויכול להיות שלא. לדוגמה, אם מכונה וירטואלית מופסקת בגלל תחזוקת המארח זמן קצר לפני שהיא נמחקת, תראו שיטת compute.instances.delete, אבל יכול להיות שתראו גם שיטת compute.instances.terminateOnHostMaintenance או שלא תראו אותה. כדי לזהות את המשתמש או את חשבון השירות שמחק את מכונת ה-VM, ממשיכים לשלב הבא. מידע על יצירת מכונה וירטואלית חדשה זמין במאמר יצירה והפעלה של מכונה וירטואלית.
   compute.instances.insert	פעילות של מנהל מערכת	משתמש או חשבון שירות יצרו את המכונה הווירטואלית. עוברים לשלב הבא כדי לזהות את המשתמש או את חשבון השירות שיצרו את המכונה הווירטואלית. מידע נוסף על יצירת מכונה וירטואלית חדשה זמין במאמר יצירה והפעלה של מכונה וירטואלית.
   compute.instances.reset	פעילות של מנהל מערכת	משתמש או חשבון שירות מאפסים את המכונה הווירטואלית. עוברים לשלב הבא כדי לזהות את המשתמש או את חשבון השירות שהפסיקו את המכונה הווירטואלית.

2. בודקים את השדות principalEmail ביומני הביקורת של Cloud כדי לזהות את המשתמש או השירות שהפעילו את הכיבוי או ההפעלה מחדש. בטבלה הבאה מפורטים שירותים מנוהלים נפוצים של Google שמתחילים כיבוי או הפעלה מחדש.

   אימייל	תיאור
   [e-mail]	אירוע מערכת גרם לכיבוי או להפעלה מחדש.
   [e-mail]	נציג שירות יזם את הכיבוי. כדי לדעת מאיזה פרויקט השירות התחיל את ההשבתה, בודקים את project-number של סוכן השירות. כדי לברר איזה שירות של Google שלח את הבקשה, בודקים את השדה protoPayload.requestMetadata.callerSuppliedUserAgent.

   אם משתמש הפעיל את הכיבוי או ההפעלה מחדש, כתובת האימייל שלו מופיעה בשדה principalEmail. לדוגמה, [e-mail].

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

מעקב אחרי אירועים במחזור החיים של מכונת VM

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

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

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

הערה: היומנים שנוצרים ומשמשים בלוח הבקרה הזה הם מדדים שחלים עליהם חיובים.

יצירת מדד מבוסס-יומן

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

כדי לקבל את ההרשאות שנדרשות ליצירת המדד, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד כתיבת יומנים (roles/logging.logWriter) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

כדי ליצור מדד מבוסס-יומן שמוגדר על ידי המשתמש:

1. במסוף Google Cloud , נכנסים לדף מדדים מבוססי-יומנים.

   כניסה אל Log-based Metrics

2. לוחצים על יצירת מדד.

בקטע סוג המדד, מבצעים את הפעולות הבאות:

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

בקטע פרטים, מזינים את הפרטים הבאים:

• שם המדד מבוסס-היומן: vm-lifecycle-events. כדי שלוח הבקרה יפעל כמו שצריך, צריך להשתמש בשם המדויק הזה.
• תיאור: אופציונלי – מזינים תיאור למדד הזה.
• יחידות: 1

1. בקטע Filter selection (בחירת מסנן), מציינים את הפרטים הבאים:

   • בתפריט Select project or log bucket בוחרים באפשרות: Project logs
   • בקטע מסנן Build מזינים:

     resource.type = "gce_instance" AND
     log_id("cloudaudit.googleapis.com/activity") OR
     log_id("cloudaudit.googleapis.com/system_event")
     operation.first="true"

2. בקטע תוויות, לוחצים על הוספת תווית.

3. מציינים את הפרטים הבאים:

   • Label name: method
   • סוג התווית: STRING
   • שם השדה: protoPayload.methodName
   • ביטוי רגולרי:

     (recreateInstance|hostError|automaticRestart|guestTerminate|terminateOnHostMaintenance|preempted|insert|stop|delete|reset|start)

4. לוחצים על סיום

5. לוחצים על יצירת מדד.

שימוש במרכז הבקרה

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

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

כדי לקבל את ההרשאות שנדרשות לשימוש בלוח הבקרה, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Monitoring Dashboard Viewer (roles/monitoring.dashboardViewer) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

1. פותחים את Dashboards במסוף Google Cloud .

   מעבר אל Dashboards

2. בכרטיסייה רשימת מרכזי הבקרה, פותחים את מרכז הבקרה GCE VM Lifecycle Events Monitoring.

3. בוחרים את המכונה הווירטואלית מהתפריט הנפתח Name.

4. מצמצמים את סדרת הזמנים למסגרת זמן רלוונטית.

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

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

1. בתרשים VM Lifecycle Timeline מוצגים הנתונים הבאים:

   • מדד compute.googleapis.com/instance/uptime שמציין אם מכונת ה-VM פעלה בנקודת זמן מסוימת. הערך 1 מציין שהמכונה פעלה והערך 0 מציין שהיא לא פעלה. שימו לב שהמדד הזה משקף את הזמינות כתוצאה מפעילות משתמשים ומאירועים במערכת, והוא לא מצביע על הסכם רמת השירות (SLA) של Compute Engine.
   • המדד מבוסס-היומנים vm-lifecycle-events לספירת מספר הפעולות במחזור החיים, כמו stop או start, שבוצעו במכונה בנקודת זמן נתונה

2. בתרשים 'אירועים' מוצג אותו מדד מבוסס-יומן vm-lifecycle-events אבל בתצוגה מוגדלת כדי שיהיה קל יותר לקרוא אותו. שימו לב: למרות שהצירים האופקיים מיושרים, הצבעים לא מסונכרנים בין שני התרשימים.

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

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

כדי לבדוק אם המכונות הווירטואליות שלכם כובו על ידי בקשת כיבוי המוני, חפשו פעולות עצירה שהופעלו על ידי [e-mail].

הפעלת מופע מושפע מחזירה שגיאה שדומה לזו:

Starting instance(s) INSTANCE_NAME...failed.
ERROR: (gcloud.compute.instances.start) The default network interface [nic0] is frozen.

כדי לפתור את הבעיה:

1. מזהים את ה-VPC המשותף שבו משתמשים המכונות הווירטואליות, באמצעות הפקודה gcloud compute instances describe:

   gcloud compute instances describe VM_NAME \
      --format="flattened(networkInterfaces[].network)"
   

   הפלט אמור להיראות כך:

   networkInterfaces[0].network: https://www.googleapis.com/compute/v1/projects/SHARED_VPC_PROJECT/global/networks/FROZEN_NETWORK
   

2. בודקים בפרויקט המארח של ה-VPC המשותף אם החיוב הושבת.

   resource.type="project"
   protoPayload.request.@type="type.googleapis.com/google.internal.cloudbilling.billingaccount.v1.DisableResourceBillingRequest"
   protoPayload.response.resourceBillingInfo.billingAccountAssignmentType="DISABLED"
   

3. אם רלוונטי, מפעילים את החיוב בפרויקט המארח.

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