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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

המסוף

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

REST

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

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

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

סוג העדכון

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

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

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

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

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

תמחור דינמי מקסימלי

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

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

אם לא מגדירים את הערך maxSurge, המערכת משתמשת בערך ברירת המחדל. ב-MIGs אזוריים, ברירת המחדל של 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.

שימו לב: כדי שבדיקת התקינות תחזיר את הערך 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 דרך Google Cloud המסוף ולסמן את התיבה Keep names when replacing VMs (שמירת השמות כשמחליפים מכונות וירטואליות).

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

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

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

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

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

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

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

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

המסוף

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

    כניסה לדף Instance groups

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Instance groups

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

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

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

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

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

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

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

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

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

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

מופע מנוהל ספציפי

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

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

REST

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

לדוגמה, הפקודה הבאה ב-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

מבצעים קריאה ל-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)

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

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

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

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

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

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

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

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

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

אפשר לשנות את התנהגות ברירת המחדל באמצעות Compute Engine API כדי להגדיר את השדות updatePolicy.minimalAction ו-updatePolicy.mostDisruptiveAllowedAction במשאב ה-MIG – לדוגמה, באמצעות קריאה לשיטה 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.

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

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

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

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

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

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

מבצעים קריאה ל-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 אזוריות

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

  • 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 בעדכוני קנרי.

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

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

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

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