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

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

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

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

תיקון אוטומטי של מכונה וירטואלית שנכשלה

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

• סיבות לא צפויות כמו כשל בחומרה.
• פעולות שלא מתבצעות על ידי ה-MIG, כמו הפעולות הבאות:
  • הפסקת פעולה של VM במודל Spot.
  • אירועי תחזוקה בתשתית כשלא מוגדרת מיגרציה פעילה של מכונת ה-VM.
  • פעולות שמבוצעות ישירות במכונה וירטואלית באמצעות הדף VM instances console, פקודות ה-CLI של gcloud‏ instances או משאב API‏ instances. לדוגמה, הפסקת מכונה וירטואלית בקבוצה באמצעות השיטה instances.stop או הפקודה gcloud compute instances stop מפעילה תיקון.

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

תיקון מכונה וירטואלית על סמך בדיקת תקינות של אפליקציה

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

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

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

מדיניות לתיקון אוטומטי

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

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

מעקב אחרי שינויים במצב התקינות של האפליקציה

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

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

תמחור

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

התנהגות במהלך תיקון

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

עדכון לגבי תיקון

במהלך תיקון, קבוצת ה-MIG יוצרת מחדש מכונה וירטואלית באמצעות תבנית המכונה המקורית ששימשה ליצירת המכונה הווירטואלית. לדוגמה, אם מכונה וירטואלית נוצרה באמצעות instance-template-a ואז עדכנתם את ה-MIG לשימוש ב-instance-template-b במצב OPPORTUNISTIC, ה-MIG עדיין ישתמש ב-instance-template-a כדי ליצור מחדש את המכונה הווירטואלית.

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

תיקון מכונה וירטואלית באזור חלופי

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

כשקבוצת MIG מתקנת מכונה וירטואלית באזור ששונה מהאזור המקורי שלה, כתובת ה-URL של המכונה הווירטואלית משתנה כי כתובת ה-URL מכילה את האזור – לדוגמה, projects/example-project/zones/us-central1-b/instances/example-mig-0289gx.

תיקון מכונה וירטואלית באזור חלופי מספק את היתרונות הבאים:

• האפליקציה תהיה עמידה יותר לכשלים אזוריים.

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

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

טיפול בדיסק

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

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

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

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

• יוצרים תמונות מצב של דיסק אחסון מתמיד (persistent disk) רגיל.
• ייצוא נתונים למקור אחר, כמו Cloud Storage.
• מגדירים דיסקים לאחסון מתמיד עם שמירת מצב.

אם למכונות הווירטואליות שלכם יש הגדרות חשובות שאתם רוצים לשמור, Google ממליצה גם להשתמש בתמונה בהתאמה אישית בתבנית של הגדרות מכונה. תמונה בהתאמה אישית מכילה את כל ההגדרות המותאמות אישית שאתם צריכים. כשמציינים אימג' בהתאמה אישית בתבנית של הגדרות מכונה, ה-MIG יוצר מחדש מכונות וירטואליות באמצעות האימג' בהתאמה אישית שמכיל את ההגדרות המותאמות אישית שאתם צריכים.

השבתת התיקונים

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

יכול להיות שתרצו להשבית את התיקונים ב-MIG במקרים כמו הבאים:

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

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

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

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

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

מידע נוסף מופיע במאמר השבתת תיקונים ב-MIG.

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

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