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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמחור

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

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

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

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

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

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

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

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

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

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

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

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

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