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

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

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

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

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

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

  המסוף

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

  gcloud

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

     gcloud init

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

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

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

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

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

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

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

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

• התפקיד Logging/Logs Viewer או התפקיד Project/Viewer.

המסוף

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 ממתין לפני הפעלה מחדש או סיום של המכונה, אפשר להגדיר את הזמן הקצוב לתפוגה של שחזור שגיאות במארח. מידע נוסף מופיע במאמר בנושא הגדרת מדיניות זמינות. כשלים בחומרה ובתוכנה יכולים לקרות מדי פעם, אבל הם נדירים. כדי להגן על האפליקציות והשירותים שלכם מפני אירועי מערכת שעלולים לשבש את הפעילות, מומלץ לעיין במקורות המידע הבאים: תכנון מערכות עמידות תבניות לאפליקציות עמידות שניתנות להרחבה יצירה של קבוצות של מופעי מכונה מנוהלים ‫Google מציעה גם שירותים מנוהלים כמו App Engine והסביבה הגמישה של App Engine.
   compute.instances.automaticRestart	אירוע במערכת	האירוע הזה מתרחש אחרי אירוע hostError או אירוע terminateOnHostMaintenance אם מדיניות התחזוקה של המארח automaticRestart של מכונת ה-VM מוגדרת לערך true. ביומנים, רשומה ביומן hostError או terminateOnHostMaintenance קודמת ליומן הזה. אם רוצים לשנות את מדיניות התחזוקה של המארח של מכונה וירטואלית, אפשר לעיין במאמר אפשרויות עדכון של מופע.
   compute.instances.guestTerminate	אירוע במערכת	מערכת ההפעלה של המכונה הווירטואלית התחילה את הכיבוי.
   compute.instances.terminateOnHostMaintenance	אירוע במערכת	אם הגדרתם את מדיניות onHostMaintenance התחזוקה של המארח של ה-VM לערך TERMINATE, מערכת Compute Engine תפסיק את ה-VM כשיש אירוע תחזוקה שבו Google צריכה להעביר את ה-VM למארח אחר. אם רוצים לשנות את המדיניות של מכונה וירטואלית, אפשר לעיין במאמר אפשרויות עדכון של מופע.onHostMaintenance
   compute.instances.preempted	אירוע במערכת	מכונה וירטואלית מסוג VM במודל Spot או מכונה וירטואלית מסוג VM זמני מדור קודם נדחקה על ידי Compute Engine: כש-Compute Engine מבצע preempt למכונת VM מסוג Spot, הוא מפסיק או מוחק את מכונת ה-VM מסוג Spot על סמך פעולת הסיום שלה. למכונות וירטואליות מסוג Spot אין זמן ריצה מקסימלי. כש-Compute Engine מבצעת דחיקה של מכונת VM שניתנת לדחיקה, היא מפסיקה את פעילות המכונה אחרי זמן ריצה מקסימלי של 24 שעות. כדי להימנע מהמגבלות האלה, כדאי להשתמש במכונות וירטואליות מסוג Spot. מכונות וירטואליות מסוג Spot ומכונות וירטואליות שניתנות להפסקת פעולה הן קיבולת עודפת של Compute Engine, ולכן יכול להיות ש-Compute Engine יפסיק את הפעולה שלהן בכל פעם שצריך את הקיבולת הזו במקום אחר. כדי לצמצם את ההשפעות של הקדימות, מומלץ לפעול לפי השיטות המומלצות. לחלופין, אם אתם צריכים מכונות וירטואליות עם סביבות זמן ריצה בשליטת המשתמש, אתם יכולים ליצור מכונות וירטואליות רגילות במקום זאת.
   compute.instances.stop	פעילות של מנהל מערכת	משתמש או חשבון שירות הפסיקו את הפעולה של המכונה הווירטואלית. ממשיכים לשלב הבא כדי לזהות את המשתמש או את חשבון השירות שהפסיק את המכונה הווירטואלית. מידע על הפעלה מחדש של מכונת VM זמין במאמר הפעלה מחדש של מופע שהופסק.
   compute.instances.delete	פעילות של אדמין או אירוע מערכת	משתמש או חשבון שירות מחקו את המכונה הווירטואלית, או שהמכונה הווירטואלית הוגדרה למחיקה אוטומטית. חשוב: בקשות למחיקת המכונה הווירטואלית, שמסומנות בשיטה compute.instances.delete ביומני הביקורת של Cloud, עשויות לבטל באופן לא עקבי בקשות אחרות למכונה הווירטואלית שהוגשו בזמן דומה. גם אם הבקשות האחרות הצליחו, יכול להיות שהשיטה compute.instances.delete תמנע באופן לא עקבי את הופעת השיטות מהבקשות האחרות ביומני הביקורת של Cloud עבור ה-VM. ספציפית, יומן רישום של השיטה compute.instances.delete עשוי להצביע על אחת מהבקשות הבאות למכונת ה-VM: בקשות ממשתמש או מחשבון שירות למחיקה ישירה של המכונה הווירטואלית מסומנות רק באמצעות שיטת compute.instances.delete מהמשתמש או מחשבון השירות. בקשות למחיקה אוטומטית של המכונה הווירטואלית מסומנות בשיטה compute.instances.delete מ[e-mail], אבל יכול להיות שהשיטה שמסבירה את הסיבה למחיקה האוטומטית תופיע ביומני הביקורת של Cloud, ויכול להיות שלא. לדוגמה, אם VM במודל Spot מוגדרת למחיקה אוטומטית במהלך הפסקה זמנית, וההפסקה הזמנית מתרחשת, תראו שיטת compute.instances.delete מ[e-mail], אבל יכול להיות שתראו גם שיטת compute.instances.preempted או לא. יכול להיות שבקשות ל-VM שהתרחשו זמן קצר לפני או אחרי שיטת compute.instances.delete יופיעו ביומני Cloud Audit Logs, ויכול להיות שלא. לדוגמה, אם מכונה וירטואלית מופסקת בגלל תחזוקת המארח זמן קצר לפני שהיא נמחקת, תראו שיטת 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].

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

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

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

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

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

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

יצירת מדד מבוסס-יומנים

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

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

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

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

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

   מעבר אל Log-based Metrics

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

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

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

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

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

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

   • בתפריט בחירת פרויקט או קטגוריה ביומן בוחרים באפשרות: יומני פרויקט
   • בתיבה יצירת מסנן מזינים:

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

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

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

   • שם התווית: 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 .

   מעבר למרכזי השליטה

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

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

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

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

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

1. בתרשים ציר הזמן של מחזור החיים של מכונה וירטואלית מוצגים הנתונים הבאים:

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

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

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

יכול להיות ש-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. אם רלוונטי, מפעילים את החיוב בפרויקט המארח.

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