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

Linux Windows

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

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

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

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

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

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

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

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

תשתית קבועה

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

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

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

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

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

   • ב-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) תומכים בגרסת מערכת ההפעלה של היעד.

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

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

‫Debian

אפשר לשדרג את Debian בין גרסאות ראשיות עוקבות. אל תדלגו על גרסאות ראשיות – לדוגמה, שדרגו קודם את Debian 11 ל-12, ואז שדרגו את Debian 12 ל-13.

1. מעדכנים את מאגרי חבילות ה-Debian הקיימים:

   sudo apt update && sudo apt upgrade -y && sudo apt dist-upgrade -y
   

2. מעדכנים את מקורות החבילות ב-/etc/apt/sources.list וב-/etc/apt/sources.list.d/. כדי לעשות זאת, מחליפים את שם הקוד של הגרסה הנוכחית, כמו bullseye, בשם הקוד של גרסת היעד, כמו bookworm. מוודאים שכתובות ה-URL של מאגר החבילות Google Cloud תואמות לגרסה החדשה.

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

   sudo apt update
   sudo apt upgrade --without-new-pkgs -y
   

4. מריצים את השדרוג של ההפצה המלאה:

   sudo apt full-upgrade -y
   

5. מוודאים שהתוסף google-guest-agent פעיל ומופעל:

   sudo systemctl enable --now google-guest-agent
   

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

   sudo systemctl reboot
   

Ubuntu

כדי לנהל שדרוגים מ-LTS ל-LTS ב-Ubuntu, משתמשים בכלי do-release-upgrade.

1. עדכון כל החבילות הנוכחיות:

   sudo apt update && sudo apt dist-upgrade -y
   

2. מתקינים את חבילת הליבה של כלי ניהול העדכונים:

   sudo apt install update-manager-core -y
   

3. מפעילים את הכלי לשדרוג הגרסה:

   sudo do-release-upgrade
   

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

5. מפעילים מחדש את מכונת החישוב כשמתבקשים לעשות זאת.

RHEL

כדי לשדרג בין גרסאות RHEL ראשיות, צריך להשתמש בכלי Red Hat leappהנתמך.

1. בודקים את סטטוס המינוי ל-Red Hat ומוודאים שמופע המחשוב מתחבר ל-Red Hat Update Infrastructure ‏ (RHUI) של Compute Engine.
2. מתקינים את כלי השירות Leapp ואת החבילות שמכילות נתוני העברה.

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

   sudo leapp preupgrade
   

4. בודקים את הדוח ב-/var/log/leapp/leapp-report.txt ופותרים את כל הבעיות שמונעות את השדרוג שזוהו על ידי Leapp.

5. מריצים את השדרוג:

   sudo leapp upgrade
   

6. מפעילים מחדש את המופע כדי לאפשר ל-Leapp לבצע את שדרוג מערכת ההפעלה בסביבה מבודדת:

   sudo reboot
   

SLES

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

1. עדכון המערכת הקיימת:

   sudo zypper patch
   

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

Windows

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

כדי לבצע שדרוג במקום ב-Windows Server, פועלים לפי ההדרכה בנושא ביצוע שדרוג במקום של Windows Server.

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

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

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

• ארגון מופעים באמצעות תוויות: הקצאת תוויות עם מטא-נתונים, כמו env:dev, env:prod ו-tier:frontend, כדי לטרגט קבוצות ספציפיות של מופעי מחשוב לצורך תיקון.
• פריסה מאזור לאזור: אפשר לפרוס את עבודות הטלאים באזורים שונים. לעולם אל תפעילו משימות של תיקון באגים בכל האזורים בו-זמנית בסביבות ייצור.
• שימוש בסקריפטים לפני ואחרי תיקון: מגדירים סקריפטים לפני תיקון כדי לנתק בבטחה חיבורים או להשהות שירותים, ומגדירים סקריפטים אחרי תיקון כדי להריץ בדיקות תקינות לפני החזרת מופעים לשירות.
• מעקב אחרי התאימות לתיקוני אבטחה: אפשר להשתמש בלוח הבקרה של VM Manager במסוףGoogle Cloud כדי לעקוב אחרי התאימות לתיקוני אבטחה ואחרי סטטוס הפגיעויות בכלל מכונות ה-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. אם אי אפשר לאתחל את מערכת ההפעלה או לשחזר אותה, צריך ליצור נפח חדש של דיסק מתמשך מתמונת המצב שצילמתם לפני השדרוג ולצרף אותו כדיסק האתחול של מופע החישוב. שלבים מפורטים לשחזור מופיעים במאמר בנושא שחזור תמונת מצב לדיסק חדש.

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

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