החלה אוטומטית של עדכוני הגדרות של מכונות וירטואליות בקבוצת MIG

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

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

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

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

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

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

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

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

  המסוף

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

  gcloud

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

     gcloud init

• הגדרת אזור ותחום כברירת מחדל

REST

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

התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Cloud de Confiance .

מגבלות

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

התחלת עדכון מתגלגל בסיסי

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

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

כמה דברים שחשוב לזכור כשמבצעים עדכון בהדרגה (rolling):

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

• ‫Instance Group Updater API הוא API הצהרתי. ה-API מצפה שהבקשה תציין את ההגדרה הרצויה של ה-MIG אחרי העדכון, ולא קריאה מפורשת לפונקציה.

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

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_URL
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

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

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

הגדרת אפשרויות לעדכון

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

סוג העדכון

קבוצות של מופעי מכונה מנוהלים תומכות בשני סוגים של עדכונים:

• עדכונים אוטומטיים או פרואקטיביים
• עדכונים סלקטיביים או אופורטוניסטיים

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

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

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

המחיר המקסימלי בתקופת ביקוש גבוה

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

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

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

האפשרות maxSurge פועלת רק אם יש לכם מספיק מכסה או משאבים לתמיכה במשאבים הנוספים.

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

מקסימום לא זמין

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

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

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

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

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

זמן המתנה המינימלי

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

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

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

1. הפונקציה ממתינה עד לתקופת הזמן שצוינה בערך autohealingPolicies.initialDelaySec של ה-MIG עד שבדיקת התקינות תחזיר את הערך HEALTHY.
2. אחר כך, המערכת ממתינה למשך הזמן שצוין על ידי minReadySec.

אם בדיקת תקינות לא מחזירה HEALTHY תוך initialDelaySec, הכלי לעדכון מכריז על המכונה הווירטואלית כלא תקינה ועשוי להפסיק את העדכון. בזמן שהמכונה הווירטואלית ממתינה לאימות במהלך תקופת initialDelaySec ו-minReadySec, הסטטוס של currentAction הוא VERIFYING. עם זאת, הסטטוס של המכונה הווירטואלית הבסיסית נשאר RUNNING.

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

הערך המקסימלי בשדה minReadySec הוא 3,600 שניות (שעה אחת).

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

פעולה מינימלית

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

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

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

הפעולה הכי משבשת שמותרת

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

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

שיטת ההחלפה

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

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

כדי לשמור על שמות המכונות, אם מעדכנים את ה-MIG באמצעות ה-CLI של gcloud או ה-API של Compute Engine, צריך להגדיר את שיטת ההחלפה ל-RECREATE במקום ל-SUBSTITUTE. אפשרות אחרת היא לעדכן את ה-MIG דרך Cloud de Confiance המסוף ולסמן את התיבה Keep names when replacing VMs.

הערכים התקינים של replacementMethod הם:

• ‫SUBSTITUTE (ברירת מחדל). העדכונים מתבצעים מהר יותר כי המכונות הווירטואליות החדשות נוצרות לפני שהמכונות הווירטואליות הישנות מושבתות. עם זאת, שמות המופעים לא נשמרים כי המופעים הישנים עדיין משתמשים בשמות האלה.

• ‫RECREATE. שומר על שמות המכונות במהלך העדכון. מערכת Compute Engine משחררת את שם המכונה כשהמכונה הווירטואלית הישנה מושבתת. לאחר מכן,‏ Compute Engine יוצרת מכונה חדשה עם אותו שם. כדי להשתמש במצב הזה, צריך להגדיר את maxSurge ל-0.

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

דוגמאות נוספות לעדכונים

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

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

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

gcloud beta compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

ביצוע עדכון בהדרגה של כל המכונות הווירטואליות, אבל יצירה של עד 10% מכונות וירטואליות חדשות מעל גודל היעד בכל פעם

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

עדכוני Canary

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

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

התחלת עדכון קנרי

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

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=template=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE"
  }
 ]
}

אפשרויות נוספות מפורטות במאמר הגדרת אפשרויות לעדכון.

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

הפעלת עדכון קנרי

אחרי שמריצים עדכון canary, אפשר להחליט אם רוצים להחיל את העדכון על 100% מה-MIG או לבטל אותו.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

מעקב אחרי עדכונים

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

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

סטטוס בקבוצה

ברמת הקבוצה, Compute Engine מאכלס שדה לקריאה בלבד בשם status שמכיל את הדגל versionTarget.isReached ואת הדגל isStable. אפשר להשתמש ב-CLI של gcloud או ב-REST כדי לגשת לדגלים האלה. אפשר גם להשתמש במסוף Cloud de Confiance כדי לראות את המספר הנוכחי של המופעים שמתעדכנים ואת המספר המתוכנן של המופעים שיתעדכנו.

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

איך בודקים אם השקת העדכון הסתיימה

כדי לוודא שההשקה של העדכון הסתיימה, בודקים את הערך של השדה status.versionTarget.isReached ב-MIG:

• ‫status.versionTarget.isReached set to true מציין שכל המכונות הווירטואליות נוצרו או נוצרות באמצעות גרסת היעד.

• ‫status.versionTarget.isReached set to false indicates that at least one VM is not yet using the target version. לחלופין, במקרה של עדכון קנרי, false מציין שמספר המכונות הווירטואליות שמשתמשות בגרסת היעד לא תואם לגודל היעד שלה.

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

הערך status.isStable שמוגדר ל-false מציין שהשינויים פעילים, בהמתנה או שה-MIG עצמו עובר שינוי.

הערך status.isStable שמוגדר ל-true מציין את הדברים הבאים:

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

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

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

ברגע שכל הפעולות יסתיימו, הערך של status.isStable יוגדר שוב ל-true עבור ה-MIG הזה.

פעולות נוכחיות על מופעים

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

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

NAME: vm-instances-9pk4
ZONE: us-central1-f
STATUS:
HEALTH_STATE:
ACTION: CREATING
INSTANCE_TEMPLATE: my-new-template
VERSION_NAME:
LAST_ERROR:

NAME: vm-instances-h2r1
ZONE: us-central1-f
STATUS: STOPPING
HEALTH_STATE:
ACTION: DELETING
INSTANCE_TEMPLATE: my-old-template
VERSION_NAME:
LAST_ERROR:

gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
    --instance INSTANCE_NAME \
    [--zone=ZONE | --region=REGION]

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "5317605642920955957",
      "version": {
        instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-prvp"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "2800161036826218547",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-w2t5"
    }
  ]
}

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

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

הערכים האפשריים של currentAction הם:

• ‫ABANDONING. המופע מוסר מקבוצת ה-MIG.
• ‫CREATING. המכונה בתהליך יצירה.
• ‫CREATING_WITHOUT_RETRIES. המופע נוצר ללא ניסיונות חוזרים. אם המופע לא נוצר בניסיון הראשון, ה-MIG לא מנסה להחליף את המופע שוב.
• ‫DELETING. המכונה נמצאת בתהליך מחיקה.
• RECREATING. המופע מוחלף.
• ‫REFRESHING. המופע מוסר ממאגרי היעדים הנוכחיים שלו ומתווסף מחדש לרשימת מאגרי היעדים הנוכחיים (הרשימה הזו יכולה להיות זהה למאגרי היעדים הקיימים או שונה מהם).
• ‫RESTARTING. המכונה נמצאת בתהליך של הפעלה מחדש באמצעות השיטות stop ו-start.
• ‫RESUMING. המופע נמצא בתהליך של הפעלה מחדש אחרי שהושעה.
• ‫STARTING. המופע בתהליך של הפעלה אחרי שהוא הופסק.
• ‫STOPPING. המכונה מופסקת.
• SUSPENDING. המכונה מושעית.
• ‫VERIFYING. המופע נוצר ועובר תהליך אימות.
• ‫NONE. לא מתבצעות פעולות במופע.

החזרה לגרסה קודמת של עדכון

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE" # Old instance template
    }
  ]
}

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

הפסקת עדכון

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

כדי לשנות עדכון מ'פרואקטיבי' ל'אופורטוניסטי' באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

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

1. שולחים בקשה כדי לקבוע כמה מופעים עודכנו:

   gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
      [--zone=ZONE | --region=REGION]

   ה-CLI של gcloud מחזיר תגובה שכוללת רשימה של מופעים בקבוצה והסטטוסים הנוכחיים שלהם:

   NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
   vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
   vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
   vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template
   

   בדוגמה הזו, שני מופעים כבר עודכנו.

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

   gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
      --version template=OLD_INSTANCE_TEMPLATE \
      --canary-version template=NEW_INSTANCE_TEMPLATE,target-size=2 \
      [--zone=ZONE | --region=REGION]

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

שליטה במהירות של עדכון בהדרגה (rolling)

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

1. להתחיל עדכון קנרי במקום עדכון מלא.
2. מגדירים ערך גבוה של minReadySec. הגדרת הערך הזה גורמת לכלי לעדכון להמתין את מספר השניות הזה לפני שהוא מחשיב את המופע כמעודכן בהצלחה ועובר למופע הבא.
3. הפעלת בדיקת תקינותגורמת לשירות העדכונים להמתין עד שהאפליקציה תופעל ולדווח על אות תקין לפני שהוא מחשיב את המכונה כמעודכנת בהצלחה וממשיך למכונה הבאה.
4. מגדירים ערכים נמוכים ל-maxUnavailable ול-maxSurge. כך מובטח שרק מספר מינימלי של מופעים יעודכן בכל פעם.
5. עדכון סלקטיבי של מופעים ב-MIG במקום להשתמש בעדכון אוטומטי.

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

שליטה ברמת השיבוש במהלך עדכון בהדרגה (rolling)

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

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

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

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

שתי האפשרויות האלה מקבלות את הערכים הבאים:

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

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

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

אפשר לשנות את התנהגות ברירת המחדל באמצעות Compute Engine API כדי להגדיר את השדות updatePolicy.minimalAction ו-updatePolicy.mostDisruptiveAllowedAction במשאב ה-MIG – לדוגמה, באמצעות קריאה לשיטה regionInstanceGroupManagers.patch. לחלופין, אפשר לבחור את הפעולות הספציפיות שמותר לעדכן מכונות וירטואליות כשמעדכנים את ה-MIG מהמסוף Cloud de Confiance . כדי לראות את ההגדרות הנוכחיות, אפשר לעיין במאמר בנושא קבלת מאפיינים של קבוצת מופעים מנוהלת (MIG).

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

ביצוע הפעלה מחדש מתגלגלת או החלפה

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

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

כשמבצעים הפעלה מחדש מדורגת או החלפה של המופעים באמצעות מסוףCloud de Confiance או Google Cloud CLI, הפעולות הבסיסיות הבאות מתבצעות ב-MIG. עם זאת, אם משתמשים ב-REST, צריך להגדיר את השדות האלה בבקשה כדי להפעיל מחדש או להחליף את הפעולה.

• אם הערך של updatePolicy.type הוא OPPORTUNISTIC, הכלי MIG משנה את הסוג ל-AUTOMATIC.
• ה-MIG מעדכן את versions.name של כל מופע.

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE",
   "name": "v2-1705499403"
  }
 ]
}

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

דוגמאות נוספות להחלפה או להפעלה מחדש

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

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

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

ביצוע הפעלה מחדש מתגלגלת של כל מכונות ה-VM במהירות האפשרית

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

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

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

שמירה של שמות המכונות

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

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

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

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

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

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

ההבדלים בין עדכון קבוצות MIG אזוריות לבין עדכון קבוצות MIG אזוריות

ל-MIGs אזוריים יש את ערכי ברירת המחדל הבאים לעדכון:

• maxUnavailable=NUMBER_OF_ZONES
• maxSurge=NUMBER_OF_ZONES

‫NUMBER_OF_ZONES הוא מספר התחומים שמשויכים לקבוצת ה-MIG האזורית. כברירת מחדל, מספר האזורים של קבוצת MIG אזורית הוא 3. אבל יכול להיות שתבחרו מספר אחר.

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

שימוש במספר קבוע או באחוז בבקשות לעדכון

אם מציינים מספר קבוע בבקשות העדכון, המספר שמציינים מחולק במספר האזורים ב-MIG האזורי ומפוזר באופן שווה. לדוגמה, אם מציינים maxSurge=10, הכלי לעדכון מחלק את 10 בין מספר האזורים באזור ויוצר מכונות על סמך המספר הזה. אם מספר המופעים לא מתחלק באופן שווה בין האזורים, הכלי לעדכון מוסיף את המופעים שנותרו לאזור אקראי. לכן, אם יש 10 מופעים בשלושה אזורים, שניים מהאזורים יקבלו 3 מופעים ואזור אחד יקבל 4 מופעים. אותה לוגיקה חלה על הפרמטרים maxUnavailable ו-targetSize בעדכוני קנרי.

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

• אם מציינים אחוז של מכונות וירטואליות לעדכון קנרי, הכלי לעדכון מנסה לפרוס את המכונות באופן שווה בין האזורים. ההפרש שנותר מעוגל כלפי מעלה או מטה בכל אזור, אבל ההפרש הכולל לא עולה על מכונה וירטואלית אחת לכל קבוצה. לדוגמה, אם יש לכם קבוצת MIG עם 10 מכונות וירטואליות ואתם רוצים לעדכן 25% מהן, העדכון יופעל על 2 עד 3 מכונות וירטואליות.

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

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

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