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

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

כדי להגדיר את התצורה הרצויה למכונות הווירטואליות ב-MIG, משתמשים ברכיבי התצורה הבאים של המכונות הווירטואליות:

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

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

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

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

אפשר גם להגדיר את ה-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 באמצעות הרכיבים הבאים:

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

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

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

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

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

אוטומטי (יזום)

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

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

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

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

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

סלקטיבי (אופורטוניסטי)

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

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

• אפשר לבחור את המכונות הווירטואליות שרוצים לעדכן.
• אתם יכולים לשלוט בתזמון ובסדר של העדכונים.
• אפשר להשתמש ב-CLI של gcloud או ב-REST כדי לעדכן את כל המופעים באופן מיידי.

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

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

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

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

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

יצירה מחדש של מכונות וירטואליות

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

הגדרה של עדכון יזום או עדכון אופורטוניסטי

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

אפשר להשתמש במסוף Cloud de Confiance , ב-Google Cloud CLI או ב-REST.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --type=TYPE

gcloud beta compute instance-groups managed update INSTANCE_GROUP_NAME \
    --update-policy-type=TYPE

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

{
  "updatePolicy": {
    "type": "TYPE" # Choose an opportunistic or proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
    }]
}

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

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

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

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

gcloud beta compute instance-groups managed describe INSTANCE_GROUP_NAME \
    --format="(updatePolicy)"

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

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

עדכונים למכונות וירטואליות מושעות ומופסקות

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

1. מכונות וירטואליות שפועלות, מושעות ומופסקות
2. מכונות וירטואליות עם הסטטוס SUSPENDING או STOPPING

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

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

1. מחיקה של מכונות וירטואליות מושעות ומופסקות.
2. המערכת יוצרת מכונות וירטואליות חדשות באמצעות תבנית של הגדרות מכונה חדשה.
3. מבצע את תהליך האתחול.
4. השהיה או הפסקה של המכונות הווירטואליות.

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

1. ממשיכים או מתחילים את ה-VM.
2. העדכון מתבצע במכונות הווירטואליות כשהן פועלות.
3. מבצע את תהליך האתחול.
4. השהיה או הפסקה של המכונות הווירטואליות.

עדכוני Canary

אם רוצים להפעיל עדכוני קנרי בקבוצת מופעי מכונה מנוהלים (MIG) שבה מכונות וירטואליות מושעות או מושבתות, צריך לשים לב לנקודות הבאות:

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

הקשר בין השדות versions ו-instanceTemplate

אם אתם משתמשים ב-REST, מומלץ להשתמש בשדות instanceGroupManagers.versions ו-regionInstanceGroupManagers.versions כדי להגדיר תבניות של מכונות ל-MIG אזוריות ול-MIG של אזור מוגדר.

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

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

אם מציינים גם את השדה instanceTemplate וגם את השדה versions כשקוראים למתודה update() או למתודה patch(), יש שלוש תוצאות אפשריות:

• הגדרתם את אותו ערך בשני השדות.

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

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

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

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

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

  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_TEMPLATE",
   "versions": [
    {
     "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    }
   ],
   "updatePolicy": {
     "type": "PROACTIVE"
   }
  }
  

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

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

  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "versions": [
    {
     "instanceTemplate": "global/instanceTemplates/A_DIFFERENT_NEW_TEMPLATE"
    }
   ],
   "updatePolicy": {
     "type": "PROACTIVE"
   }
  }
  

השדה versions, השדה instanceTemplate והשיטה get()

אם מציינים רק תבנית אחת של מכונה, באמצעות השדה instanceTemplate ברמה העליונה, השדה versions או שניהם, השיטה get() מחזירה את שני השדות בתשובה שלה. כך השדה החדש versions תואם לאחור. כל עוד מציינים תבנית של מופע יחיד באחד מהשדות האלה, לא חל שינוי בערך שמוחזר על ידי השיטה get() בשדה instanceTemplate.

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

השדה versions והשיטה setInstanceTemplate()

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

ה-method‏ setInstanceTemplate() מגדיר גם את updatePolicy ל-OPPORTUNISTIC. כך נמנעת מ-MIG פריסה אקטיבית של תבנית של הגדרות מכונה שלא צוינה במפורש בשדה versions.

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

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