החלפת כונן כושל במערך mdadm באובונטו

המידע בפוסט זה מבוסס על Ubuntu 18.04 ועל גרסת mdadm הכלולה במאגרים שלה; נכון לכתיבת שורות אלה, גרסה 4.1-rc1. ייתכן שהיא תקפה עבור גרסאות אחרות, וייתכן שלא.

לאחרונה הייתה לי כשל פתאומי בכונן בשרת הקבצים הביתי שלי, המורכב מתשעה כוננים במערך RAID-6 של mdadm. זה תמיד מפחיד, אבל למרבה המזל הצלחתי למצוא במהירות כונן חלופי שסופק כבר למחרת כדי שאוכל להתחיל בבנייה מחדש.

אני מודה שהייתי קצת קמצן מדי כשהגדרתי במקור את שרת הקבצים; רק שניים מהכוננים הם כונני NAS אמיתיים (Seagate IronWolf), בעוד שהשאר הם כוננים שולחניים (Seagate Barracuda). באופן לא מפתיע, דווקא אחד מכונני השולחן הפסיק לעבוד (אחרי כמעט שלוש שנות שירות, אגב). הוא היה מת לחלוטין; אחרי שהעברתי אותו למארז USB שולחני, כל מה שקיבלתי ממנו היה צליל נקישה מטריד, וגם Ubuntu 20.04 וגם Windows 10 לא הצליחו לזהות אותו.

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

אז, קודם כל, כשאתם מקבלים את דוא"ל אירוע הכשל המפחיד מ-mdadm, אתם צריכים לזהות איזה כונן כשל. נכון, הוא יגיד לכם את שם ההתקן (במקרה שלי /dev/sdf), אבל כנראה שלא ברור איזה כונן פיזי זה באמת מכיוון שהשמות האלה יכולים להשתנות כאשר המכונה מאתחלת.

אם אינך בטוח איזה שם התקן נכשל, תוכל להשתמש בפקודה הבאה כדי לברר זאת (החלף את /dev/md0 בהתקן ה-RAID שלך):

כפי שצוין, במקרה שלי זה היה /dev/sdf, אז בואו נמשיך עם זה.

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

(אם smartctl לא נמצא, עליך להתקין את חבילת smartmontools באובונטו)

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

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

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

כעת, לפני שתשלפו את הכונן הפיזי, מומלץ להודיע רשמית ל-mdadm על כוונה זו, על ידי הנחת פקודה זו (החליפו את שמות ההתקנים בשמות שלכם לפי הצורך):

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

אם הפעולה נכשלת עם הודעת שגיאה בדומה ל-"device or resource busy", ייתכן ש-mdadm לא רשם את הכונן ככשל מוחלט. כדי לגרום לו לעשות זאת, הפעילו את הפקודה הזו (שוב, זכרו להחליף את שמות ההתקנים בשמות שלכם בהתאם):

לאחר מכן, תוכל להסיר את ההתקן מהמערך באמצעות הפקודה הקודמת.

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

למרות ש-SATA בדרך כלל אמור לתמוך בהחלפה חמה, לא התכוונתי להסתכן בשום דבר בהגדרה זו, אז בחרתי לכבות את המכונה תוך כדי החלפת הכונן.

לפני שתעשו זאת, מומלץ להסיר את התקן ה-RAID בקובץ /etc/fstab כדי שאובונטו לא תנסה לטעון אותו אוטומטית באתחול הבא, מכיוון שהיא עלולה להיתקע ולאלץ אתכם למצב שחזור עקב מערך RAID פגום. ייתכן שזו לא בעיה גדולה אם מדובר במערכת שולחנית, אבל אני מריץ את השרת הזה ללא חיבור למסך או מקלדת, כך שזה יהיה קצת טרחה.

לאחר אתחול המכונה עם הכונן החדש והמבריק מותקן, השתמש ב-lsblk או באמצעי אחר כדי לזהות אותו. אם לא שינית שום דבר אחר, סביר להניח (אך לא בהכרח) שהוא יקבל את אותו שם כמו הכונן שהחלפת. במקרה שלי הוא קיבל את אותו שם, ולכן הכונן החדש נקרא גם /dev/sdf.

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

השתמשתי ב-sgdisk למטרה זו, והעתקתי את טבלת המחיצות מ-/dev/sdc ל-/dev/sdf. ודאו שאתם מחליפים את שמות ההתקנים כך שיתאימו לשלך, כנדרש.

שימו לב לסדר כאן: אתם מפרטים קודם את כונן ה-"to"! זה קצת לא אינטואיטיבי מבחינתי, אבל רק תוודאו שאתם עושים את זה נכון כדי שלא תקבלו עוד כשל בכונן במערך ;-)

לאחר מכן, כדי להימנע מהתנגשויות UUID, צור UUIDs חדשים עבור הכונן החדש:

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

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

אם הכל ילך כשורה, הכונן יתווסף למערך ללא תקלות. אני מאמין שהוא למעשה נוסף כ"כונן רזרבי חם" כברירת מחדל, אבל מכיוון שלמערך הזה חסר דיסק (זה שנכשל), הוא מוכנס לשימוש מיד ותהליך הבנייה מחדש יתחיל.

אתה יכול לעקוב אחרי זה כך:

זה כנראה ייקח קצת זמן; בשרת הצנוע שלי (המבוסס בעיקר על חומרה ברמת צרכן וכוננים שולחניים, שימו לב) הוא הצליח להגיע לקצת פחות מ-100 מגה-בייט/שנייה. קחו בחשבון שזה RAID-6, כך שיש הרבה חישובי זוגיות הכרוכים בבנייה מחדש; RAID-10 היה הרבה יותר מהיר. למחשב הספציפי הזה יש מעבד AMD A10 9700E מרובע ליבות (ה-"E" פירושו שזהו דגם חסכוני באנרגיה עם תזמון נמוך מדי, כלומר לא סופר מהיר), רק כדי לתת לכם מושג למה לצפות. עם תשעת הכוננים של 8 טרה-בייט במערכת שלי, השיפוץ המלא ארכה קצת יותר מ-24 שעות.

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

לאחר שתסיים, הוסף אותו בחזרה לקובץ /etc/fstab שלך, הפעל מחדש ותיהנה מהקבצים שלך :-)