למה in-place upgrade של Linux נכשל באמצע
in-place upgrade של Linux נכשל לעיתים רחוקות כבר בהתחלה — המכונה מחזיקה מעמד עד לרגע שבו מנהל החבילות מתחיל לפתור תלויות של המהדורה החדשה מעל החבילות המותקנות.
מטא-נתוני המאגרים כבר הוחלפו, חלק מהספריות עודכנו, והטרנזקציה אינה מצליחה להיסגר: נוצר קונפליקט תלויות, שבו מחצית הסביבה נמשכת לענף הישן ומחצית לחדש. לאחר מכן מנהל החבילות מסרב לעבוד עם שתי הקבוצות.
השכבה הבאה — חבילות יתומות. המהדורה מוציאה חלק מהרכיבים, והם נותרים ללא בעלים במטא-נתונים החדשים: אינם נמחקים, אינם מתעדכנים, מחזיקים ספריות משותפות ישנות וחוסמים את פתרון התלויות אצל השכנים. ברשימת המותקן ידנית הם אינם מופיעים, ולכן בעת הניתוח הם אינם נראים.
קבצי תצורה מיושנים שוברים כבר את עליית השירותים. מנהל החבילות אינו דורס הגדרות ששונו בשקט — לצידן נוצר קובץ חדש, והדמון קורא את זה שנטען ראשון. פורמט הפרמטרים במהדורה החדשה שונה: השירות נופל בעלייה או עולה עם ערכים ריקים.
המקרה הגרוע ממתין לאחר האתחול: הקרנל חדש, אך תמונת האתחול והמודולים נותרו מהמהדורה הקודמת. מערכת הקבצים השורשית אינה נטענת — זו המערכת שאינה עולה, שמשחזרים ידנית ממדיה חירום, תוך אובדן שעות של זמינות השירות.
כל נקודות הכשל הללו צפויות מראש וניתנות לבדיקה לפני האתחול. נפרט כיצד סוגרים אותן — ממיפוי חבילות ועד הרצת בקרה על עותק.
מה משתנה לאחר עדכון מערכת מבוקר
המעבר בין גרסאות major מפסיק להיות ספונטני: השירותים מופעלים מחדש בסדר מוגדר, וחלון ההשבתה נשמר בטווח המוצהר, במקום להימתח לסדרה של תיקוני חירום בלילה. הבדיקות מורצות על עותק של סביבת הייצור, ולכן התלויות בין השירותים ורצף ההפעלה מחדש עובדו מראש.
עדכון Linux במקום (in-place upgrade) מתבצע ללא התקנה מחדש: החבילות, התצורות והנתונים נשארים באותה מערכת, והתפקידים אינם נפרסים מחדש. זה מסיר את הסיכון העיקרי — פער בין מה שהוגדר ידנית לבין מה שמתואר בתצורה.
נעלם סוג שלם של כשלים הקשור בספריות מיושנות: ההפצה מפסיקה לקבל תיקוני אבטחה ומפסיקה להיבנות כנגד תלויות עדכניות. לאחר המעבר לענף נתמך של Debian, הבניות שוב משוחזרות בכלים רגילים, בלי טלאים ממאגרים חיצוניים.
תוכנית החזרה לאחור נקבעת לפני תחילת העבודה: תמונת מצב, נקודת חזרה וקריטריונים שבלפיהם עוצרים את המעבר. אם השירות אינו עובר את הבדיקות, החזרה לתמונה הקודמת אורכת דקות ולא שעות של שחזור מגיבוי.
בתוצאה — תמיכה בספריות עדכניות, הליך חוזר למעבר הבא וזמן התאוששות צפוי מראש, שאותו ניתן להקצות בהסכם רמת השירות.
דרכים למעבר בין גרסאות major של Linux
הבחירה בין עדכון במקום (in-place upgrade), העברה למערכת נקייה וסטנד מקביל נקבעת לא לפי הנוחות של המהנדס, אלא לפי מידת ההשבתה שהשירות מתיר ולפי מידת השליטה בתצורה לאחר המעבר.
עדכון במקום שומר על הנתונים, ההגדרות המקומיות והכתובות, אך גורר איתו שכבות מצטברות של גרסאות minor קודמות — מקונפיגים מיושנים ועד חבילות שאיש אינו מעז למחוק. העברה למערכת נקייה מספקת מצב צפוי, אך דורשת מיפוי מלא של השירותים והעברת נתונים עם בדיקת שלמות.
| אפשרות | מתי מתאימה | מגבלות השיטה |
|---|---|---|
| עדכון במקום | צומת בודד, חלון השבתה מותר, תצורה על ענף מנוהל | קבצים שיוריים ומודולים מיושנים מועברים אוטומטית; חזרה לאחור לאחר ההרצה הראשונה אינה פשוטה |
| העברה למערכת נקייה | נדרשים מבנים משוחזרים וויתור על עריכות ידניות | השבתה בזמן ההעתקה; נדרשת סקירה של כל השירותים, הרשאות הגישה ונקודות ה-mount |
| סטנד מקביל | העומס מפוזר, קיימים מאזן עומסים ורפליקות | תחזוקה כפולה בתקופת המעבר; קשה יותר לאתר פערים בין הסביבות |
בפועל מתחילים בעדכון במקום על צומת אחד שאינו קריטי: כך נבדקים התרחישים, הסקריפטים והתנהגות השירותים לפני שמחילים אותם על מכונות הייצור. שימור הנתונים בכל אפשרות נשען על תמונת מצב לפני העבודה ועל השוואה לאחריה — אחרת לא יהיה במה להשוות את "לפני" ו"אחרי".
איך מתבצע העדכון: שלבי העבודה ההנדסית
עדכון בין גרסאות major אינו פקודה אחת בטרמינל, אלא רצף שבו כל שלב מותיר דרך חזרה. העבודה מתבצעת על מארח אחד בכל פעם: המצב מתועד לפני ואחרי, ולכן כשל בכל שלב אינו הופך לאובדן שירות. הסדר זהה להפצות ממשפחת Debian ולתואמות לה — שונים רק סט הפקודות של מנהל החבילות.
- מיפוי שירותים. אוספים את תפקידי המארח: יחידות פעילות, טיימרים ומשימות מתוזמנות, פורטים מאזינים, קשרים עם מכונות שכנות, מבנים שנעשו בעקיפין למנהל החבילות. בלי הרשימה הזו אין אפשרות לקבוע שלא אבד דבר לאחר העדכון.
- תמונת מצב. מתעדים את רשימת החבילות עם הגרסאות, את תוכן ספריית ההגדרות, את טבלת ה-mount, את פרמטרי הרשת ואת מודולי הקרנל המותקנים. בנוסף תמונת דיסק מלאה או snapshot של הכרך — היא נדרשת גם להשוואה וגם לחזרה לאחור.
- תוכנית חזרה לאחור וחלון עבודה. מגדירים את נקודת האל-חזור: עד לאיזה שלב החזרה אורכת דקות, ואחרי איזה — שעות. מתאמים את החלון, את ההרשאות ואת האחראי מטעם הלקוח.
- הרצה על עותק. פורסים סטנד מתמונת המצב ועוברים את כל השרשרת: עדכון המאגרים, החלפת המהדורה, מיזוג הקונפיגים, אתחול. כך נראים מראש חבילות שנעלמו מהמאגרים החדשים ופורמטים שהשתנו בקבצי ההגדרות.
- עדכון במקום. מעבירים את השירותים לתחזוקה, מעלים את החבילות למהדורה החדשה, וקונפליקטים בהגדרות פותרים ידנית ולא בהחלפה אוטומטית. האתחול מתבצע דרך קונסולת ניהול, כדי שהגישה לא תהיה תלויה ברשת פעילה.
- בדיקה לאחר האתחול. בודקים יחידות במצב כשל, יומני אתחול, נקודות mount, תוקפי תעודות ובדיקות יישומיות: האם השירות מגיב, האם מתבצעת כתיבה למסד הנתונים, האם צמתים שכנים רואים אותו.
- קבלת התוצאה. מוסרים רשימת בדיקות, תיעוד מעודכן, רשימת השינויים וחלון תצפית שבו נשארים בקשר. המארח חוזר לעבודה לפי תוצאה מאושרת, ולא לפי עצם האתחול.
תוצרי העדכון: תצורות ותקנונים
עדכון בין גרסאות major באמצעות in-place upgrade מסתיים לא באתחול, אלא במסירת ערכת קבצים ומסמכים. לפיה ניתן לתחזק את המערכת, לשחזר אותה על סטנד אחר ולחזור לאחור בלי מי שביצע את העדכון. להלן הרשימה שאנו סוגרים לפני המסירה: אם סעיף חסר, העבודה אינה נחשבת מושלמת.
- תרשים התשתית — הצמתים, תפקידיהם, מקטעי הרשת והקשרים בין השירותים, מעודכנים למועד המסירה ולא היסטוריים.
- תצורות השירותים — ההגדרות, יחידות systemd ופרמטרי הקרנל השונים מהברירת מחדל, עם הסבר מדוע נבחר דווקא הערך הזה.
- מדיניות גישה — הרכב הקבוצות, כללי העלאת ההרשאות, המפתחות והתעודות, תוקפם ונוהל הביטול עם עזיבת עובד.
- תקנון תחזוקה — תדירות העדכונים, חלונות העבודה, הבדיקות לפני ההחלה והקריטריונים שלפיהם צומת נחשב תקין.
- נוהל חזרה לאחור — נקודות החזרה שנותרו, מה בדיוק עולה מהגיבוי, כמה זמן זה אורך ומי מקבל את ההחלטה.
- יומן שינויים — כרונולוגיה: מה שינו ולשם מה, אילו בדיקות עברו, אילו חריגות נמצאו וכיצד נסגרו.
התרשים, התצורות והיומן נמצאים זה לצד זה, במערכת בקרת גרסאות, ולכן העריכות מתבצעות יחד עם השינויים ולא במסמך נפרד. כל סעיף מאומת על ידי קובץ או פקודה — הערכה מתקבלת פורמלית, ולא על סמך מילים.
מקרה בוחן: עדכון פארק שרתים ללא השבתה ממושכת
פארק של 60+ שרתים פעל על גרסת major של הפצה שהספק הפסיק להנפיק עבורה עדכוני אבטחה.
העדכון נדחה שנה אחר שנה: התרחיש הרגיל הניח התקנה מחדש מאפס, העברת נתונים והגדרה ידנית של כל מכונה — לפי הערכת הצוות עצמו הדבר היה מביא ללא פחות משני ימי השבתה לקבוצה ועשרות פעולות ידניות שקל לטעות בהן.
כיצד העבירו את העומס
הפארק חולק לקבוצות של 8–10 מכונות והועבר בהדרגה. הצומת הוצא מאיזון העומס, המתינו לסיום הסשנים הפעילים, צולמה תמונת מצב והופעל in-place upgrade דרך תרחישים מנוהלים ב-Ansible. לאחר האתחול המכונה עברה בדיקות אוטומטיות: תגובת השירות, זמינות הפורטים, שלמות ספריות הנתונים.
רק במעבר מלא חזר הצומת לרוטציה, אחרת הוא הוחזר מהתמונה בתוך דקות, והעומס המשיך להתאזן על שאר מכונות הקבוצה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| עבודה עם שרת אחד | 4–6 שעות של פעולות ידניות | 25–40 דקות, מהן 5 דקות של מעורבות מהנדס |
| השבתת השירות | חלון של 8 שעות בסוף השבוע | אפסית, הצמתים יוצאים אחד אחד |
| שיעור השלבים הידניים | כ-70% | פחות מ-10% |
| חזרה לאחור בעת כשל | התקנה מחדש מאפס | החזרת תמונה תוך 3–5 דקות |
| מכונות על הענף העדכני | 0% | 100% |
את כל הפארק העבירו בתוך חודש וחצי, בלי לעצור את השירות כולו אף פעם. הפעולות הידניות הצטמצמו להרצת התרחיש ולבדיקת הדוח, והעדכון לגרסת ה-major הבאה מתבצע כעת במסלול מעובד, ולא מאפס.
במה שונה עדכון במקום מהתקנה מחדש?
עדכון במקום והתקנה מחדש פותרים משימה אחת — להעלות את המערכת לענף major חדש, אך מגיעים אליה מכיוונים שונים. במקרה הראשון מנהל החבילות מחליף חבילות מעל הסביבה הפעילה ומריץ סקריפטי הגירה: הוא גם משווה קבצי תצורה, מסמן את אלה שנערכו ידנית ומציע להשאירם.
במקרה השני מקבלים שורש נקי ומעבירים אליו נתונים, הגדרות ושירותים ביד — כלומר מרכיבים את המכונה מחדש ממה שהצליחו להיזכר ולמצוא.
מכאן ההבדל המעשי העיקרי — שימור ההגדרות. עדכון במקום גורר איתו משתמשים ומפתחותיהם, כללי mount, תעודות, תיאורי שירותים, משימות מתזמן, מגבלות משאבים ופרמטרי רשת. כל אלה נשארים על הדיסק בלי פגע, ומנהל החבילות רק שואל מה לעשות עם הקבצים שנערכו ידנית.
התקנה מחדש אינה נותנת זאת: כל הגדרה שלא תועדה במאגר התצורות או שלא הוצאה לגיבוי נעלמת יחד עם השורש הישן, ובדרך כלל נזכרים בה רק לאחר העלייה.
לוחות הזמנים נבדלים בסדר גודל. עדכון במקום נכנס לחלון אחד: יצירת snapshot של מערכת הקבצים או גיבוי, בדיקת מקום פנוי, הרצת העדכון, אתחול, בדיקת השירותים והיומנים.
התקנה מחדש — זהו מיפוי של מה שבאמת פועל על המארח, בניית תמונה או מחיצות, העברת נתונים ותצורות, הגדרת גישה, ואחר כך איתור תקלות עד למצב "הכל כמו שהיה", ולכך נדרשים ימים ולא שעות.
גם סיכון אובדן הנתונים שונה במהותו. בעדכון במקום הוא מרוכז בחלון אחד: הגירה כושלת, חוסר מקום במחיצה או תצורת שירות בלתי תואמת — והחזרה לאחור נעשית מהתמונה, ולכן התמונה חייבת להתקיים לפני ההתחלה, ובדיקה על עותק סטנד היא הכרחית.
בהתקנה מחדש הנתונים אובדים בשקט: שכחו מסד נתונים, לא הוציאו תור, פספסו תעודה או כלל חומת אש — ומגלים זאת כעבור שבועות.
הכלל המעשי פשוט: כל עוד המערכת הוגדרה ידנית והצטברו בה חריגים, עדכון במקום זול יותר בזמן ובטוח יותר למצב. התקנה מחדש מוצדקת כאשר השורש כבר אינו משוחזר וכדאי להרכיב אותו מחדש מתוך תצורה מתועדת. אנו בוחנים זאת לפני תחילת העבודה ובוחרים את האפשרות לפי מיפוי המארח, ולא לפי הרגל.
ספקות טכניים לפני העדכון
לפני כל in-place upgrade של Linux עולים אותם שאלות: כמה תימשך ההשבתה, האם מערכת שלא עודכנה זמן רב תסתדר, ומה לעשות אם המכונה לא תעלה. להלן תשובות קצרות לאלה הנשאלות בתדירות הגבוהה ביותר.
כמה תימשך השבתת השירותים?
העדכון נכנס להפסקה טכנולוגית אחת: החלפת החבילות, יצירת תמונת האתחול, אתחול. השירותים חוזרים לעבודה לאחר בדיקת תקינות היישומים, ולא מיד לאחר האתחול. באשכול הצמתים מתעדכנים בזה אחר זה, ולכן השירות החיצוני נשאר זמין.
המערכת לא עודכנה כמה שנים — האם תתעדכן ישירות?
לא תמיד: בין ענפים משתנים התלויות, מערכת ה-init ומיקום התצורות. המסלול נבנה שלב אחר שלב, דרך מהדורות ביניים עד לענף היעד, ולפני הצעד הראשון נוצרת תמונת דיסק מלאה — החזרה לאחור נשארת אפשרית בכל שלב.
כיצד נבדקת התאימות של התוכנה היישומית?
לפני העבודה משווים את הרכב השירותים ואת גרסאות הספריות לדרישות ענף היעד. מה שאינו נתמך ישירות מותקן ממאגר נפרד או מוחלף בתחליף תואם — זה נכנס לתוכנית מראש, ולא מתברר בליל העדכון.
מה לעשות אם המערכת לא תעלה?
שחזור האתחול מתבצע ממדיה נפרדת: מחליפים את הקרנל או את רשומת ה-boot loader, והשינויים מוחזרים מהתמונה שנוצרה. סדר הפעולות עצמו נבדק על עותק של התשתית לפני העבודה, ולכן בסביבת הייצור הוא מבוצע לפי תרחיש מוכן.
נדון במשימת העדכון שלכם
הערכת עדכון בין גרסאות major נשענת על פרטי הסביבה: סטנדים שנראים זהים נבדלים בהרכב החבילות ובמאגרים חיצוניים, ובדיוק זה קובע את היקף העבודה.
כדי לנקוב בלוחות זמנים ובסדר פעולות, ולא בטווח "מכאן ומכאן", נדרש מאיתנו חתך של הסביבה — את כל זה ניתן לשלוח בכל צורה נוחה, בין אם ייצוא ממערכת ניהול התצורות ובין אם רשימה טקסטואלית.
- רשימת השרתים והמכונות הווירטואליות עם תפקידן בסביבה: מאזן עומסים, יישום, מסד נתונים, תור, אחסון קבצים;
- הגרסאות הנוכחיות של ההפצות וענף היעד שאליו מתכננים לעלות;
- מקורות חבילות לא שגרתיים, מודולי קרנל ובניות מהמקור — אלה לרוב שוברים את המעבר;
- קובצי התצורה של השירותים ויחידות systemd שדורסים את התנהגות ברירת המחדל;
- התלויות בין הצמתים: כרכים משותפים, רפליקציה, אינטגרציות חיצוניות, הצמדות קשיחות ברשת;
- זמן אי-הזמינות המותר והחלון שבו ניתן להתחיל את העדכון;
- מה כבר קיים לצורך חזרה לאחור: תמונות, גיבויים, צמתים חלופיים.
לאחר הניתוח אנו מחזירים מיפוי של הסביבה עם נקודות הסיכון המסומנות, הערכה ותוכנית עבודה לפי שלבים עם סדר עדכון הצמתים, וכן קריטריוני קבלה — רשימת הבדיקות שהשירות חייב לעבור לפני החזרה לעבודה.
את סדר המסירה קובעים מראש: מה אתם מקבלים בתוצאה, אילו תצורות ותקנוני חזרה לאחור נשארים אצל הצוות שלכם וכיצד המערכת נמסרת להפעלה לאחר הסיום.
תארו את המשימה — נחזור עם הערכה ותוכנית.