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

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

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

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

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

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

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

מגבלות

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

התחלת עדכון בסיסי בהדרגה (rolling)

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

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

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

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

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

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

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. בוחרים את קבוצת ה-MIG שרוצים לעדכן.

  3. לוחצים על Edit.

  4. לוחצים על Instance template & overrides כדי להרחיב את הקטע ומוסיפים תבנית לבדיקה באופן הבא:

    1. לוחצים על הוספת תבנית לבדיקה.

    2. ברשימה Instance template for testing, בוחרים תבנית חדשה.

      אם התבנית שרוצים לבדוק לא זמינה, משתמשים באפשרות Create a new instance template ופועלים לפי ההנחיות כדי ליצור תבנית של הגדרות מכונה.

    3. בשדה Target running, מזינים את המספר או האחוז של המכונות שרוצים להחיל עליהן את התבנית החדשה.

    4. בשדה Instances or percentage, בוחרים באפשרות instances או percent כדי לציין את המספר שהזנתם בשדה Target running.

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

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

  6. לוחצים על שמירה כדי להתחיל את העדכון.

gcloud

משתמשים בפקודה rolling-action start-update.

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

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

  • ‫INSTANCE_GROUP_NAME: השם של ה-MIG
  • ‫INSTANCE_TEMPLATE_URL: כתובת ה-URL של תבנית של הגדרות מכונה שבה רוצים להשתמש כדי ליצור מכונות ב-MIG. כתובת ה-URL יכולה להכיל את המזהה או את השם של תבנית של הגדרות מכונה. מציינים אחד מהערכים הבאים:
    • לתבנית של הגדרות מכונה אזורית: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • לתבנית גלובלית של הגדרות מכונה: INSTANCE_TEMPLATE_ID
  • ‫ZONE: לקבוצות MIG אזוריות, מציינים את האזור
  • ‫REGION: לקבוצות MIG אזוריות, מציינים את האזור

REST

מפעילים את ה-method‏ patch במשאב MIG אזורי או תחום.

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

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 יוצרת רק מכונה אחת נוספת לכל אזור במהלך העדכון.

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

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

סוג העדכון

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

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

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

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

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

מתח מקסימלי

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

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

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

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

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

הערך המקסימלי לא זמין

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

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

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

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

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

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

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

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

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

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

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

שיטת ההחלפה

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

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

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

שיטות להחלפת מכונות מנוהלות.

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

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

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

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

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

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

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

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

ביצוע עדכון בהדרגה (rolling) עם 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]

עדכון בהדרגה (rolling) של כל המכונות הווירטואליות, אבל יצירה של עד 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 יכול להיות תבנית של הגדרות מכונה אזורית מאותו אזור של קבוצת המכונות המנוהלת, או תבנית של הגדרות מכונה גלובלית.

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

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

  3. לוחצים על Edit.

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

    1. לוחצים על הוספת תבנית לבדיקה.

    2. ברשימה Instance template for testing, בוחרים תבנית חדשה.

      אם התבנית שרוצים לבדוק לא זמינה, משתמשים באפשרות Create a new instance template ופועלים לפי ההנחיות כדי ליצור תבנית של הגדרות מכונה.

    3. בשדה Target running, מזינים את המספר או האחוז של המכונות שרוצים להחיל עליהן את התבנית החדשה.

    4. בשדה Instances or percentage, בוחרים באפשרות instances או percent כדי לציין את המספר שהזנתם בשדה Target running.

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

  6. לוחצים על שמירה כדי להתחיל את העדכון.

gcloud

משתמשים בפקודה rolling-action start-update. צריך לציין גם את התבנית הנוכחית וגם את התבנית החדשה כדי להגדיר במפורש כמה מופעים צריכים להשתמש בכל תבנית:

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]

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

  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות.
  • ‫CURRENT_INSTANCE_TEMPLATE: התבנית הנוכחית של הגדרות המכונה שמשמשת את הקבוצה.
  • ‫NEW_TEMPLATE: התבנית החדשה שרוצים לבדוק.
  • ‫SIZE: מספר או אחוז המכונות שרוצים להחיל עליהן את העדכון. צריך להחיל את המאפיין target-size על התבנית --canary-version. אפשר להגדיר אחוז רק אם הקבוצה מכילה 10 מכונות או יותר.
  • ‫ZONE: לקבוצות MIG אזוריות, מציינים את האזור.
  • ‫REGION: לקבוצות MIG אזוריות, מציינים את האזור.

לדוגמה, הפקודה הבאה מבצעת עדכון קנרית שפורס את example-template-B ל-10% מהמכונות בקבוצה:

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%

REST

מפעילים את ה-method‏ patch במשאב MIG אזורי או תחום. בגוף הבקשה, כוללים גם את תבנית של הגדרות מכונה הנוכחית וגם את תבנית של הגדרות מכונה החדשה שרוצים לבדוק בגרסה ראשונית (canary). לדוגמה:

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"
  }
 ]
}

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

  • ‫NEW_TEMPLATE: השם של התבנית החדשה שרוצים לבדוק.
  • ‫NUMBER|PERCENTAGE: המספר הקבוע או האחוז של המכונות שבהן יתבצע עדכון ה-canary. אפשר להגדיר אחוז רק אם הקבוצה מכילה 10 מכשירים או יותר. אחרת, צריך לציין מספר קבוע.
  • ‫CURRENT_INSTANCE_TEMPLATE: התבנית הנוכחית של הגדרות המכונה שמשמשת את הקבוצה.

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

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

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

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

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

  3. לוחצים על Edit.

  4. בתבנית של הגדרות המכונה שבחרתם לבדיקה, מעדכנים את הערך של Target running בתבנית הבדיקה ל-100% כדי להעביר את תבנית הבדיקה לכל המכונות.

    לחלופין, אפשר להחליף את התבנית המקורית בתבנית הבדיקה ולמחוק את תבנית של הגדרות מכונה לבדיקה.

  5. לוחצים על שמירה כדי להתחיל את העדכון.

gcloud

אם אתם רוצים להמשיך עם העדכון החלקי, אתם יכולים להריץ שוב את הפקודה rolling-action start-update, אבל הפעם להגדיר רק את הדגל version ולהשמיט את הדגל --canary-version.

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

REST

מפעילים את ה-method‏ patch במשאב MIG אזורי או תחום. בגוף הבקשה, מציינים את התבנית החדשה של הגדרות המכונה בתור version ומשמיטים את התבנית הקודמת של הגדרות המכונה מגוף הבקשה. אם לא מציינים את גודל היעד, העדכון יושק ל-100% מהמופעים. לדוגמה:

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
   }
 ]
}

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

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

סטטוס הקבוצה

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

המסוף

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

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

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

  3. כדי לראות את הפרטים, לוחצים על הכרטיסייה Details.

  4. בקטע Instance template אפשר לראות את המספר הנוכחי של המכונות ואת מספר היעד של המכונות לכל תבנית של הגדרות מכונה.

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

gcloud

משתמשים בפקודה describe.

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

אפשר גם להשתמש בפקודה gcloud compute instance-groups managed wait-until עם הדגל --version-target-reached כדי להמתין עד שהערך של status.versionTarget.isReached יוגדר כ-true בקבוצה:

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

REST

מפעילים את ה-method‏ get במשאב MIG אזורי או תחום.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gcloud

כל המופעים המנוהלים

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

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:

העמודה HEALTH_STATE תופיע ריקה, אלא אם הגדרתם בדיקת תקינות.

בטרמינלים אינטראקטיביים שתומכים בפלט צבעוני של ANSI, כברירת מחדל ה-CLI של gcloud מקודד בצבע את הערכים בעמודות STATUS,‏ HEALTH_STATE ו-ACTION. במאמר הסבר על צבעי הסטטוס ב-CLI של gcloud מוסבר על ערכת הצבעים ואיך להשבית את הצבעים.

מכונה מנוהלת ספציפית

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

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

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

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

REST

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

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

הקריאה מחזירה רשימה של מכונות ל-MIG, כולל instanceStatus ו-currentAction של כל מכונה.

{
  "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"
    }
  ]
}

אם מגדירים בדיקת תקינות, התשובה כוללת גם את השדה instanceHealth.

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

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

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

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

REST

מפעילים את ה-method‏ patch במשאב MIG אזורי או תחום.

בגוף הבקשה, מציינים את תבנית של הגדרות מכונה הקודמת בתור version:

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
    }
  ]
}

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

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

הפסקת עדכון

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

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

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

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

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

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

ערך תיאור אילו מאפייני מכונה אפשר לעדכן?
REFRESH אל תעצרו את המכונה. דיסקים נוספים, ממשקי רשת דינמיים (NIC), מטא-נתונים של מכונות, תוויות, תגים
RESTART עוצרים את המכונה ומפעילים אותה מחדש. דיסקים נוספים, כרטיסי רשת דינמיים, מטא-נתונים של מכונות, תוויות, תגים, סוג מכונה
REPLACE (ברירת המחדל) החלפת המכונה בהתאם לאפשרות replacement method. כל מאפייני המכונה שמאוחסנים בתבנית של הגדרות המכונה או בהגדרות של כל מכונה בנפרד

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

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

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

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

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

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

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

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

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

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

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

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

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

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

  5. כדי להתחיל את הפעולה, לוחצים על Restart VMs או על Replace VMs.

gcloud

משתמשים בפקודה restart או בפקודה replace.

הפקודות הבאות מבצעות הפעלה מחדש או החלפה הדרגתית של מכונות ב-MIG אזורי. בקבוצת MIG אזורית, מחליפים את הדגל --zone=ZONE בדגל --region=REGION.

  • כדי להפעיל מחדש את כל המכונות ב-MIG אזורי, אחת אחרי השנייה:

    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --zone=ZONE

  • כדי להחליף את כל המופעים ב-MIG אזורי, אחד בכל פעם:

    gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME \
    --zone=ZONE

אתם יכולים להתאים אישית את הפקודות האלה בעזרת אותן אפשרויות שזמינות לעדכונים, למשל --max-surge ו---max-unavailable.

REST

שולחים בקשת PATCH באחת מהשיטות הבאות:

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

  • מגדירים את השדה updatePolicy.minimalAction לערך RESTART או REPLACE.

  • מגדירים את השדה versions.name. לדוגמה, אפשר לציין מספר גרסה עם חותמת זמן – v2-ddmmyyhhmm.

  • מגדירים את השדה versions.instanceTemplate לכתובת ה-URL הנוכחית של התבנית.

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

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"
  }
 ]
}

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

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

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

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

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

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

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

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. אם יוצרים מחדש מכונות במקום להחליף אותן, העדכון נמשך זמן רב יותר, אבל המכונות המעודכנות שומרות על השמות שלהן.

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

gcloud

כשמפעילים את הפקודה rolling-action, צריך לכלול את הדגל --replacement-method=recreate.

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]

REST

מפעילים את ה-method‏ patch במשאב MIG אזורי או תחום. בגוף הבקשה, כוללים את השדה updatePolicy.replacementMethod:

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 אזורית, עם כמה חריגים שמתוארים בהמשך. כשמפעילים עדכון של קבוצת MIG אזורית, שירות העדכון תמיד מעדכן את המכונות באופן פרופורציונלי ואחיד בכל אזור. אי אפשר לבחור אילו מכונות באילו אזורים יעודכנו קודם, ואי אפשר לבחור לעדכן מכונות באזור אחד בלבד.

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

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

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

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

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

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

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

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

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

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

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