למה הגדרת RAID תוכנה (mdadm) בשרתים לא הולכת לפי התוכנית
הגדרת mdadm לעתים קרובות מסתיימת במקום שבו המערך כבר נבנה ומגיב לבקשות. פורמלית, RAID תוכנה בשרת קיים: הכלי מציג סטטוס נקי, המחיצות נקראות, הנתונים במקום. אבל למערך אין דיסק רזרבי חם, התצורה לא מקובעת בקובץ שנקרא בזמן האתחול, והרכב ההתקנים לאחר אתחול מחדש לא אומת על ידי איש.
הכשל הראשון של RAID תוכנה לא מתגלה מיד. הידרדרות המערך מתרחשת בשקט: דיסק אחד נושר מהמראה, הליבה רושמת אירוע, אבל mdadm לא הועבר למצב התראות — פשוט אין למי למסור את ההודעה, ועל אובדן הדיסק נודע כעבור חודשים.
בד בבד מתברר שבדיקת המדיה המתוכננת מעולם לא הופעלה: היומן ריק, ובכונן השני מזמן גדלים סקטורים בלתי קריאים.
המחיר של תרחיש כזה — לא דיסק אחד שכשל, אלא המערך כולו ועשרות שעות של שחזור. בנייה מחדש מתחרה עם בקשות עבודה על פעולות קלט/פלט, זמן התגובה של השירותים גדל פי כמה, וחלון ההשבתה הבלתי מתוכננת חורג בהרבה מהתקנון.
גרוע יותר כשהבדיקה מופעלת לראשונה בדיוק ברגע התקלה: המערך נבנה מחדש לפי החבר הפגום ומשכפל את השגיאה לכל העותקים.
אנו מפרקים כיצד זה נסגר: מבניית מערך עם רזרבה שהוקצתה מראש ושמות התקנים צפויים ועד בדיקות לפי לוח זמנים עם הגבלת עומס והתראות שמגיעות לפני שהכשל הופך סופי.
מה נותן מערך מורכב: זמן השבתה וסוגי כשלים
מערך תוכנה ב-mdadm נבנה כך שבמקרה של כשל של כונן אחד השירות ממשיך לעבוד: הבקשות עוברות דרך הדיסקים הנותרים, והשרת עובר למצב של יתירות מופחתת. עבור הלקוח זה ההבדל בין «שיחת טלפון באמצע הלילה ושחזור מעותק» לבין «החלפת דיסק בבוקר לפי התקנון». השבתת השירות ברגע הכשל נמדדת בשניות של מיתוג, לא בשעות.
ההשפעה השנייה — זמן השחזור של המערך. עם דיסק רזרבי חם מוגדר, הבנייה מחדש מתחילה אוטומטית, בלי להמתין למהנדס ולבלי בחירה ידנית של מחליף; החלון מצטמצם מכמה שעות לעשרות דקות, וכל הזמן הזה השירות ממשיך לענות לבקשות.
סוגים שלמים של כשלים נעלמים כליל: מוות פיזי של הכונן, שגיאות קריאה בסקטורים פגומים (נסגרות על ידי עותק מהמראה) והידרדרות הדרגתית, שנתפסת על ידי בדיקת תקינות תקופתית. היא רצה לפי לוח זמנים, ולכן אי-התאמות עולות לפני שהן הופכות לכשל, ולא ברגע של עומס שיא.
מה שהמערך לא מכסה — כשל של בקר, כבל, ספק כוח ופעולות שגויות של מנהל המערכת. גיבויים נשארים חובה: המערך אחראי להמשכיות, לא לשחזור נתונים. את הגבול הזה אנחנו מבהירים מיד, כדי לא ליצור תחושת ביטחון שווא.
התוצאה המדידה השלישית — תחזוקה מתוכננת ללא השבתה: הדיסק מוחלף בשרת פעיל, בדיקת התקינות לא מפריעה למתן מענה לבקשות, והירידה בביצועים במצב של יתירות מופחתת נראית בניטור מראש. השרת עובר כשל של כונן כאירוע שגרתי, לא כתקלה.
אפשרויות ארגון מערך דיסקים: השוואת גישות
שלוש גישות סוגרות משימה אחת — לעבור כשל של דיסק בלי לעצור את השירות. ההבדל הוא מי מנהל את השיקוף ומה קורה בעת החלפת הכונן: מערך באמצעי המערכת, בקר חומרה או כרך בלוקים חיצוני עם שכפול.
את הסכמה בוחרים לפי רמת היתירות, והיא נקבעת לפי מספר הדיסקים וזמן השחזור המותר. מראה נותנת בנייה מחדש צפויה, זוגיות — יותר קיבולת שימושית באותו מאגר דיסקים. אף אפשרות לא מבטלת את השנייה: המערך מגן מפני כשל של הכונן, אבל לא מפני כשל של המכונה עצמה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מערך באמצעי המערכת (RAID תוכנה) | נדרש סט נייד: הדיסקים נקראים בכל מערכת תואמת, התצורה היא קובץ רגיל ולא זיכרון של בקר | חלק מזמן המעבד מוקדש לחישוב זוגיות; מחיצת האתחול דורשת סכמה נפרדת; בנייה מחדש מתבצעת תחת עומס חי |
| בקר RAID חומרה | החלפת דיסק ומטמון עם הגנת מתח נדרשים ללא עצירה, המערכת צריכה לראות כרך אחד | מטא-נתונים בפורמט סגור: החלפת בקר — רק לדגם תואם; אבחון דרך כלי היצרן |
| כרך בלוקים חיצוני עם שכפול | המערך צריך לעבור כשל של השרת כולו, לא של דיסק בודד | תגובת הרשת נכללת בהשהיית הפעולות; השכפול אסינכרוני — קיים חלון של אובדן הכתיבות האחרונות |
הבחירה המעשית מצטמצמת לשלוש שאלות: האם הניידות של הסט בין שרתים חשובה, האם זמן הבנייה מחדש בעת החלפת דיסק קריטי, והאם המערך צריך לעבור כשל של המכונה עצמה.
איך עובר היישום: ביקורת, סכמה, בנייה, בדיקה
סדר העבודות בנוי כך שלא יהיה צורך לבנות את המערך מחדש אחרי הכשל הראשון. תחילה מתעדים את המצב בפועל של השרת, אחר כך מתכננים סכמת יתירות לפי פרופיל העומס — ורק לאחר מכן בונים את המערך ובודקים שהוא באמת משתחזר, ולא רק «עולה».
- ביקורת תצורת השרת ומלאי הכוננים. בודקים דגמים ומשאב דיסקים, חלוקה, מערכות קבצים, מה כבר נבנה למערכים, אילו מחיצות משתתפות באתחול, מה העומס על קלט/פלט והאם יש תאים פנויים להחלפה ללא עצירה.
- תכנון סכמת המערך. בוחרים רמת יתירות וגודל פס לפי פרופיל קריאה-כתיבה אמיתי, מספר דיסקים פעילים ורזרביים, מסמנים מחיצות שירות ואתחול כך שהמערכת תעלה גם עם כונן שנשר.
- בניית mdadm. יוצרים מערך, מסמנים ומעבירים לפי מזהים, לא לפי שמות התקנים, רושמים תלויות בטוען האתחול ובתמונת האתחול, כדי שסדר הדיסקים שזוהו לא ישבור דבר.
- בדיקת שחזור. מוציאים בכוונה כונן, בודקים איך עוברת הבנייה מחדש וכמה זמן היא אורכת, האם השירות מתנהג באופן צפוי בזמן הזה והאם הרזרבה חוזרת לפעולה אוטומטית.
- ניטור ותחזוקה. מגדירים התראות על הידרדרות המערך, מנהלים יומן אירועים, קובעים בלוח הזמנים בדיקת זוגיות מתוכננת — אז אי-התאמת בלוקים נתפסת לפני הכשל, ולא בזמן השחזור.
- מסירת תקנונים. מוסרים תיעוד של הסכמה, נוהל החלפת כונן שלב אחר שלב, מטריצת «מה לעשות בזמן הידרדרות» וסדר בדיקה לאחר כל שינוי.
תצורות, סכמות מערך ותקנוני תחזוקה
לאחר בניית המערך בתשתית נשארת לא רק תצורה פעילה, אלא גם ערכת תוצרים שלפיהם אפשר לשחזר ולתחזק אותה בלי המחבר. בלעדיהם החלפת דיסק הופכת לפירוק בעיוורון: לא ברור אילו כוננים שייכים למערך, איך הוא ייבנה לאחר אתחול מחדש ומי רשאי לשנות את הגדרותיו.
- קובץ תצורת המערך: הרכב הדיסקים, רמת היתירות, גודל הבלוק והצמדה למזהי הכוננים, לא לשמות ההתקנים. לאחר אתחול מחדש המערך נבנה מעצמו, בלי תלות בסדר זיהוי הדיסקים.
- מפת חיבור הכוננים: בקר, חריץ, מספר סידורי ותפקיד של כל דיסק, בנפרד מסומנים חריצים להחלפה חמה. המהנדס מוציא את הכונן הנדרש בלי לפגוע במערך שכן.
- תקנון החלפת דיסק: מה לבדוק לפני הוצאה, איך להכניס כונן חדש למערך, לאילו מצבים להסתכל בזמן בנייה מחדש ומתי הפעולה נחשבת סגורה.
- מדיניות גישה: למי מותר לבצע פעולות במערך, איך מוגבלות הרשאות, לאן נכתב יומן הפקודות. הוצאה מקרית של דיסק מפסיקה להיות בלתי הפיכה.
- סדר בדיקות מתוכננות: סקר מצב הכוננים והמערך לפי לוח זמנים, השוואת סכומי בקרה, ספים שבהם המהנדס מתערב לפני הכשל.
- הוראות שחזור: תרחישים של הידרדרות ואובדן מלא של המערך, סדר בנייה בשרת חדש, נקודות שבהן הנתונים אובדים ללא תקנה.
- תיעוד השרת: הקשר בין המערך למחיצות, נקודות עיגון ואתחול, מה משתנה בעת הרחבה.
הערכה חיה יחד עם השרת במאגר תצורות: החלפת הדיסק הבאה מתבצעת לפי מסמך, לא לפי זיכרון.
תרגול: בניית מערך ושחזור לאחר הידרדרות
פרויקט מובהק — שירות עם בסיס נתונים ואחסון קבצים, מערך על ארבעה דיסקים עם זוגיות, שנבנה על mdadm. לא היה דיסק רזרבי חם, איש לא סקר את המצב: על הדיסק שנשר נודע בבוקר לפי שגיאות כתיבה, כשהמערך כבר כמה שעות עבד בהידרדרות.
הבנייה מחדש התבצעה תחת עומס חי, תור הדיסקים היה תפוס, זמן התגובה של השירות גדל פי כמה, וחלק מהמשימות היה צריך להפעיל מחדש ביד.
מה שינו
בשלב ראשון הוצאנו את המערך מהידרדרות וקבענו באיזו רמה הוא יציב. לאחר מכן הוספנו דיסק רזרבי חם והפעלנו סקר מצב: הכלי עוקב אחר אירועים ושולח התראה לתורן בכל שינוי בהרכב. בנפרד הגדרנו יומן רישום שינויים — דיסק שחזר נכנס למערך על ידי השלמת בלוקים חסרים, ולא בנייה מחדש מלאה. בדיקת זוגיות הוכנסה ללוח זמנים: היא מגלה שגיאות קריאה «שקטות» לפני שהן צפות בזמן השחזור.
תוצאה במספרים
| מדד | לפני | אחרי |
|---|---|---|
| גילוי הידרדרות | ידני, שעות | התראה, דקות |
| החלפת דיסק | עצירה ובנייה מחדש ידנית | דיסק רזרבי חם, אוטומטית |
| החזרת דיסק למערך | בנייה מחדש מלאה | השלמת שינויים |
| חלון ללא הגנת נתונים | שעות | אין |
חלק מהתקריות שהתורן סוגר בלי יציאה לשטח גדל לרוב: המערך עצמו תופס את הרזרבה, והמהנדס מקבל תמונה מוכנה של הרכב ומצב הדיסקים.
mdadm או בקר חומרה: מה לבחור לשרת
תשובה קצרה: הבחירה נקבעת לא לפי מהירות, אלא לפי המידה שבה אתם מוכנים להיות תלויים בדגם ספציפי של לוח. מערך תוכנה mdadm נבנה על ידי הליבה מעל כוננים רגילים, חומרה — חיה בתוך בקר עם מטמון ולוגיקה משלו. מראה או זוגיות מתקבלות בשני המקרים, אבל בזמן כשל, החלפה והעברה הן מתנהגות אחרת.
החלפת כונן במערך תוכנה מתבצעת בלי לעצור את השירות: הדיסק התקול מוצא, החדש מוכנס למערך, והנתונים משוחזרים תחת עומס חי. מהירות הבנייה מחדש מוגבלת על ידי פרמטרי סנכרון — אחרת היא גוזלת רוחב פס מהאפליקציה ומאריכה את זמן התגובה. בבקר חומרה העבודה הזו עוברת ללוח, אבל ההתקדמות נראית רק דרך הכלי שלו.
ניידות המערך — קו פרשת המים המרכזי. במערך תוכנה הסימון נשמר על הכוננים עצמם: מעבירים את הדיסקים לשרת אחר ומעלים את המערך בפקודת בנייה אחת, בלי לחפש חומרה תואמת. מערך חומרה נקרא על ידי אותו בקר או בקר תואם — אם הלוח התקלקל ואין מחליף מאותו דגם, את הנתונים יהיה צריך לחלץ ברצינות.
למגבלות של מערך תוכנה מתייחסים לירידה בביצועים בזמן בנייה מחדש, היעדר מטמון בלתי תלוי בחשמל וניטור באמצעים עצמאיים: מצב המערך, טמפרטורה ותחזית כשל של כוננים נבדקים על ידי שירותים נפרדים. בתמורה מקבלים שקיפות — רואים איזה בלוק נמצא על איזה דיסק, ואין קופסה שחורה של קושחה.
בפועל את רוב השרתים אנחנו בונים על מתאם מעבר עם מערך תוכנה, ואת המטמון החומרתי משאירים למשימות של כתיבה צפופה.
פירוק ספקות נפוצים: הידרדרות, החלפת דיסק, ניטור
הידרדרות המערך — לא תקלה, אלא מצב שגרתי: הוא ממשיך לספק נתונים, היתירות просто נעלמת עד החלפת הדיסק. המסוכן אינו הכשל של הכונן עצמו, אלא הכשל השני בחלון השחזור — אז הכלל כולו הולך לאיבוד. להלן תשובות לשאלות שעולות לרוב בעת מסירת המערך להפעלה.
מה יקרה אם דיסק יכשל בדיוק בזמן כתיבה?
הליבה מסמנת את הכונן ככשל, המערך עובר למצב מנוון וממשיך לשרת קריאה. שגיאת קלט/פלט תגיע רק לאותה אפליקציה שהבלוקים שלה נכתבו ברגע הכשל ולא שוחזרו על ידי זוגיות. פעולות שלא הושלמו — מערכת קבצים עם יומן תבטל אותן בעת העיגון הבא — שלמות המטא-נתונים נשמרת.
האם אפשר להחליף דיסק בלי התקנה מחדש ובלי לעצור שירותים?
כן, אם הסל תומך בהחלפה חמה: הכונן הכשל מוצא מהמערך, החדש מתווסף כדיסק חלופי, והשחזור מתבצע ברקע. המערך נשאר בעבודה, אבל עד סיום הסנכרון היתירות מופחתת — את הפער הזה אנחנו משתדלים לקצר על ידי הגבלת מהירות הבנייה מחדש, כדי שהיא לא תדחק את עומס העבודה.
איך לוודא שהמערך באמת שלם, ולא «פשוט מגיב»?
בדיקה תקופתית קוראת את כל הבלוקים ומשווה אותם לזוגיות, ומציגה את מספר אי-ההתאמות. אנחנו קובעים אותה לחלון לילה ומנתחים כל אי-התאמה: חד-פעמית בדרך כלל נסגרת בכתיבה מחדש, שיטתית מצביעה על כונן מדרדר או כבל תקול.
האם נדרש ניטור נפרד אם המערך משתחזר מעצמו?
הוא לא משתחזר מעצמו — הוא שורד. בלי התראות, הידרדרות יכולה להישאר בלתי מורגשת שבועות, עד שדיסק שני יכשל. אנחנו מגדירים התראות לאירועי הידרדרות, כשל וסיום בנייה מחדש, ומשלימים אותן בבקרת מצב הכוננים, כדי שהאות יגיע לפני אובדן הנתונים, ולא אחרי.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
הגדרת RAID למשימה מתחילה לא בפקודת יצירת המערך, אלא במלאי: כמה כוננים, איפה תהיה המערכת, איפה הנתונים, האם יש דיסק רזרבי חם ואיך מתבצעת תחזוקת החלפת הדיסק. ככל שהנתונים הראשוניים מדויקים יותר, כך פחות תיקונים בתוכנית העבודה לאחר ההתחלה.
מה נדרש מכם להתחלה:
- רשימת שרתים ותפקידיהם: איפה המערכת, איפה הנתונים, איפה הגיבויים;
- הרכב הכוננים לפי חריצים, כולל כאלה שאינם בשימוש וטעוני החלפה;
- רמת עמידות התקלה הנדרשת: מראה, זוגיות או שילוב של מראות ופיזור;
- דרישות זמינות: חלון תחזוקה וזמן עבודה מותר של המערך במצב הידרדרות;
- הרשאות גישה: חשבון מנהל, קונסולת ניהול השרת, מערכת ניטור;
- מגבלות: הצפנת מחיצות, וירטואליזציה, תוספי אשכול, דרישות רגולטוריות.
בתגובה נחזיר סכמת פריסת מערכים עם חלוקה ורשומות אתחול על שני הכוננים, רשימת עבודות להגדרת RAID למשימה — מחלוקה ועד נוהל החלפת דיסק, בדיקות תקינות וספי התראה, וכן הערכת לוחות זמנים עם חלונות השבתה. את תוכנית העבודה נתאם לפני שינויים בשרתי הייצור, כדי שכל שלב יישאר הפיך.
תארו את המשימה ואת התצורה הנוכחית — נדון בה ונחזור עם הערכה ותוכנית.