שיטות מומלצות לשדרוג מערכת ההפעלה

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

כשגרסה של מערכת הפעלה מתקרבת לסוף תקופת התמיכה (EOS) או לסוף חיי המוצר (EOL), צריך לשדרג לגרסה נתמכת של מערכת ההפעלה כדי להמשיך לקבל עדכוני אבטחה, תאימות תוכנה ושילוב עם פלטפורמת Cloud de Confiance by S3NS . מידע נוסף על שלבי התמיכה מפורט במאמר בנושא מחזור החיים של מערכות הפעלה.

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

אם מבצעים שדרוג משמעותי במקום של מערכת ההפעלה – למשל, שדרוג של Debian 12 ל-13, של RHEL 9 ל-10 או של Ubuntu 24.04 ל-26.04 במופע פעיל של מחשוב – נוצרים סיכונים תפעוליים משמעותיים בסביבות ענן. בניגוד לשרתים פיזיים מקומיים, מופעי החישוב שלכם תלויים בחבילות מיוחדות של סביבת האורח כדי לתקשר עם ההיפר-ויז'ור ועם שרת המטא-נתונים של Compute Engine.

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

• אובדן קישוריות SSH ו-RDP: פורמטים של הגדרות לשירותי רשת, כללי חומת אש ברמת האורח, כמו ufw או firewalld, או הגדרות של דימון SSH יכולים להשתנות בין גרסאות של מערכת הפעלה, ולנתק את הגישה הניהולית מרחוק.
• שיבוש בסביבת האורח: חבילות google-guest-agent ו-google-oslogin מנהלות מפתחות SSH, חשבונות משתמשים, ממשקי רשת וסנכרון עם מטא-נתונים. אם מאגרי חבילות או תלויות נשברים במהלך שדרוג הפצה, יכול להיות שהסוכן של האורח יפסיק לפעול, וכך יימנעו כניסות נוספות או הגדרות רשת.
• בעיות תאימות עם אחסון ועם מנהלי התקנים של ליבת מערכת ההפעלה: שינויים בליבה, ב-initramfs או במנהלי התקנים של בקרי דיסק (כמו virtio-scsi או NVMe) עלולים לגרום לכשלים בהפעלה או למנוע ממופע המחשוב לזהות נפחי דיסק קשיח מצורפים.
• הגדרות לא עקביות למאגרי מידע: ספקי מערכות הפעלה מוציאים לעיתים קרובות משימוש מאגרי חבילות מדור קודם ומפתחות חתימה, או מחליפים אותם. מצב כזה עלול לגרום לכך שמנהלי חבילות ייכשלו באמצע השדרוג, ומערכת ההפעלה תישאר במצב לא ניתן לשחזור, עם התקנה חלקית.

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

בחירה באסטרטגיית השדרוג המתאימה

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

תשתית בלתי ניתנת לשינוי

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

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

יצירת תמונה מעודכנת

1. בוחרים את תמונת מערכת ההפעלה הציבורית העדכנית מהרשימה של פרטי מערכת ההפעלה הנתמכות, או יוצרים תמונת בסיס מותאמת אישית באמצעות Image Builder או כלים אוטומטיים כמו Packer או Ansible.
2. מוודאים שהאפליקציה והתלות שלה מותקנות ופועלות בהצלחה בגרסת מערכת ההפעלה החדשה בסביבת בדיקה שאינה סביבת ייצור.
3. ליצור תמונת מערכת הפעלה בהתאמה אישית או להפנות למשפחת התמונות הציבוריות החדשה. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש במשפחות של תמונות.

יצירת תבנית של הגדרות מכונה מעודכנת

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

gcloud compute instance-templates create NEW_TEMPLATE_NAME \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --region=REGION

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

• ‫NEW_TEMPLATE_NAME: השם של תבנית הגדרות המכונה החדשה.
• ‫IMAGE_FAMILY: משפחת האימג' של מערכת ההפעלה של היעד, למשל debian-12 או ubuntu-2404-lts.
• ‫IMAGE_PROJECT: הפרויקט שמארח את התמונה, כמו debian-cloud או ubuntu-os-cloud.
• ‫MACHINE_TYPE: סוג המכונה של המופעים.
• ‫REGION: האזור ב-Compute Engine שבו יוצרים את התבנית.

ביצוע החלפה מתגלגלת ב-MIG

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

gcloud compute instance-groups managed rolling-action replace MIG_NAME \
    --max-surge=20% \
    --max-unavailable=0 \
    --region=REGION

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

• ‫MIG_NAME: השם של קבוצת המופעים המנוהלת.
• ‫REGION: האזור שבו נמצאת קבוצת ה-MIG. ב-MIG אזורי, מחליפים את --region=REGION ב---zone=ZONE.

יצירה מחדש של מכונות וירטואליות עם דיסק אחסון מתמיד (persistent disk)

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

גיבוי כל הדיסקים

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

gcloud compute disks snapshot BOOT_DISK_NAME \
    --snapshot-names=SNAPSHOT_NAME \
    --zone=ZONE

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

• ‫BOOT_DISK_NAME: השם של דיסק האתחול שרוצים לגבות.
• ‫SNAPSHOT_NAME: השם של קובץ ה-snapshot החדש של ה-Persistent Disk.
• ‫ZONE: האזור שבו נמצא הדיסק.

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

הפרדה בין נתוני האפליקציה לבין דיסק האתחול

חשוב לוודא שנתוני האפליקציה, קבצי מסד הנתונים ויומני העסקאות נמצאים בכרכים משניים של Persistent Disk או בשירותים חיצוניים, כמו Cloud Storage או Cloud SQL, ולא בדיסק האתחול.

יצירת מכונת מחשוב חלופית

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

   gcloud compute instances stop LEGACY_INSTANCE_NAME --zone=ZONE
   

2. מנתקים את דיסקי הנתונים המשניים ממופע Compute מדור קודם:

   gcloud compute instances detach-disk LEGACY_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

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

   gcloud compute instances create NEW_INSTANCE_NAME \
       --image-family=IMAGE_FAMILY \
       --image-project=IMAGE_PROJECT \
       --zone=ZONE \
       --machine-type=MACHINE_TYPE
   

4. מצרפים את דיסקי הנתונים המשניים הקיימים למכונת החישוב החדשה:

   gcloud compute instances attach-disk NEW_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

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

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

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

• ‫LEGACY_INSTANCE_NAME: השם של מכונת ה-Compute הקיימת שאתם משדרגים.
• ‫DATA_DISK_NAME: השם של נפח האחסון המשני של Persistent Disk לניתוק ולחיבור מחדש.
• ‫NEW_INSTANCE_NAME: השם של מכונת החישוב החדשה שתחליף את הקיימת.
• ‫IMAGE_FAMILY: משפחת התמונות של גרסת מערכת ההפעלה של היעד, למשל debian-13 או ubuntu-2604-lts.
• ‫IMAGE_PROJECT: הפרויקט שמספק את התמונה, למשל debian-cloud או ubuntu-os-cloud.
• ‫MACHINE_TYPE: סוג המכונה של מופע ה-Compute החדש.
• ‫ZONE: האזור שבו נמצאים מופעי החישוב.

שדרוגי מערכת הפעלה במקום

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

רשימת דרישות מוקדמות לשדרוג

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

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

2. עדכון כל החבילות הנוכחיות וסביבת האורח עבור Cloud de Confiance לגרסאות האחרונות שזמינות לגרסת מערכת ההפעלה הנוכחית:

   • ב-Debian וב-Ubuntu: sudo apt update && sudo apt dist-upgrade -y
   • ב-RHEL,‏ CentOS ו-Rocky Linux: ‏ sudo dnf upgrade -y
   • ב-SLES: ‏ sudo zypper update

   מוודאים שהחבילות google-guest-agent ו-google-oslogin פעילות:

   sudo systemctl status google-guest-agent
   

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

   gcloud compute instances add-metadata INSTANCE_NAME \
       --metadata=serial-port-enable=TRUE \
       --zone=ZONE
   

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

   • ‫INSTANCE_NAME: השם של מכונת ה-Compute.
   • ‫ZONE: האזור שבו נמצאת מכונת ה-Compute.

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

4. אם אתם משתמשים ב-OS Login או במפתחות SSH שמנוהלים על ידי סוכן האורח, אז הגדירו סיסמה לחשבון משתמש מקומי עם הרשאות אדמין, למשל באמצעות sudo passwd USERNAME, כדי שתוכלו להיכנס דרך הקונסולה הטורית אם OS Login לא יהיה זמין באופן זמני במהלך השדרוג. מחליפים את USERNAME בשם של חשבון המשתמש המקומי.

5. צריך לוודא שלמחיצת הבסיס / ולמחיצת האתחול /boot יש מספיק שטח פנוי, מומלץ לפחות 5 GB, כדי להוריד ולפתוח חבילות חדשות:

   df -h / /boot
   

6. מוודאים שסוכני צד שלישי לאבטחה, לגיבוי או לניטור (כולל Google Cloud Ops Agent) תומכים בגרסת היעד של מערכת ההפעלה.

תהליכי שדרוג במקום

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

אוטומציה של ניהול תיקונים לעדכונים משניים

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

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

• ארגון מופעים באמצעות תוויות: הקצאת תוויות עם מטא-נתונים, כמו env:dev, env:prod ו-tier:frontend, כדי לטרגט קבוצות ספציפיות של מופעי Compute לצורך תיקון.
• פריסה מאזור לאזור: אפשר לפרוס את עבודות הטלאים באזורים שונים. לעולם אל תפעילו עבודות תיקון על כל האזורים בו-זמנית בסביבות ייצור.
• שימוש בסקריפטים לפני ואחרי תיקון: מגדירים סקריפטים לפני תיקון כדי לנתק בבטחה חיבורים או להשהות שירותים, ומגדירים סקריפטים אחרי תיקון כדי להריץ בדיקות תקינות לפני החזרת מופעים לשירות.
• מעקב אחרי התאימות לתיקוני אבטחה: אפשר להשתמש בלוח הבקרה של VM Manager במסוףCloud de Confiance כדי לעקוב אחרי התאימות לתיקוני אבטחה ואחרי סטטוס הפגיעויות בכלל מכונות ה-VM.

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

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

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

1. מוודאים שחיבור ה-SSH או ה-RDP תקין.

2. מוודאים שהסוכן לאורחים והשירות של OS Login פעילים ומדווחים על סטטוס תקין:

   sudo systemctl status google-guest-agent
   sudo systemctl status google-oslogin-cache
   

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

   curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/id
   

4. מוודאים ששירותי האפליקציה הופעלו ושבדיקות התקינות ממאזני העומסים מדווחות על מקרים תקינים.

פתרון בעיות של ניתוק

אם איבדתם את הגישה ל-SSH או ל-RDP למופע של Compute אחרי שדרוג במקום, צריך לבצע את השלבים הבאים לפתרון בעיות:

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

   gcloud compute instances tail-serial-port-output INSTANCE_NAME \
       --zone=ZONE
   

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

   gcloud compute connect-to-serial-port INSTANCE_NAME \
       --zone=ZONE
   

   נכנסים באמצעות פרטי הכניסה של המשתמש המקומי, בודקים את יומני המערכת באמצעות journalctl -xe ומפעילים מחדש את הרשת או את השירות google-guest-agent.

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

   • ‫INSTANCE_NAME: השם של מכונת ה-Compute שאתם מנסים לפתור בה בעיות.
   • ‫ZONE: האזור שבו נמצאת מכונת ה-Compute.

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

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

• מידע על שלבי מחזור החיים של מערכות הפעלה ומדיניות הוצאה משימוש
• שיטות מומלצות לניהול תמונות
• הסבר על הרכיבים והדמונים של סביבת האורח
• הגדרה של עדכוני אבטחה אוטומטיים באמצעות VM Manager
• ביצוע שדרוג במקום של Windows Server