החלפת כונן כושל במערך mdadm באובונטו
פורסם: 15 בפברואר 2025 בשעה 22:03:16 UTC
אם אתה נמצא במצב הנורא של כשל בכונן במערך RAID של mdadm, מאמר זה מסביר כיצד להחליף אותו נכון במערכת אובונטו.
Replacing a Failed Drive in an mdadm Array on Ubuntu
המידע בפוסט זה מבוסס על אובונטו 18.04 והגרסה של mdadm הכלולה במאגרים שלה; בזמן הכתיבה v4.1-rc1. זה עשוי להיות תקף עבור גרסאות אחרות או לא.
לאחרונה היה לי כשל פתאומי בכונן בשרת הקבצים הביתי שלי, המורכב מתשעה כוננים במערך mdadm RAID-6. זה תמיד מפחיד, אבל למרבה המזל הצלחתי להשיג במהירות כונן חלופי שנמסר כבר למחרת כדי שאוכל להתחיל את הבנייה מחדש.
אומנם הייתי קצת זול מדי כשהתקנתי את שרת הקבצים במקור; רק שניים מהכוננים הם כונני NAS אמיתיים (Seagate IronWolf), בעוד שהשאר הם כוננים שולחניים (Seagate Barracuda). באופן לא מפתיע, זה היה אחד מהכוננים השולחניים שוויתרו (אם כי לאחר כמעט שלוש שנות שירות). זה היה מת לגמרי; אחרי שהעברתי אותו למארז USB שולחני כל מה שיצא לי ממנו היה צליל לחיצה מטריד וגם אובונטו 20.04 וגם ווינדוס 10 לא הצליחו לזהות אותו.
נו טוב, על החלק החלופי (וכן, הכונן החדש שקניתי היה IronWolf, למדתי לקח) - מפחיד ככל שזה לאבד כונן במערך פועל, זה אפילו יותר מפחיד אם אתה לא יודע את ההליך הנכון להחלפתו. זו לא הפעם הראשונה שאני צריך להחליף כונן כושל במערך mdadm, אבל למרבה המזל זה כל כך נדיר שבדרך כלל אני צריך לחפש את הפקודות המתאימות. הפעם החלטתי להכין מדריך קטן משלי לעיון עתידי.
אז, קודם כל, כאשר אתה מקבל את הדואר האלקטרוני הנורא של אירוע כשל מ-mdadm, אתה צריך לזהות איזה כונן נכשל. בטח, זה יגיד לך את שם ההתקן (במקרה שלי /dev/sdf), אבל זה כנראה לא ברור איזה כונן פיזי הוא בעצם כפי שהשמות האלה יכולים להשתנות כשהמכונה מאותחלת.
אם אתה אפילו לא בטוח איזה שם מכשיר נכשל, אתה יכול להשתמש בפקודה הבאה כדי לברר (החלף את /dev/md0 בהתקן ה-RAID שלך):
כאמור, במקרה שלי זה היה /dev/sdf, אז בואו נמשיך עם זה.
לאחר מכן, תוכל לנסות למצוא את המספר הסידורי של הכונן הכושל על ידי הנפקת הפקודה הזו:
(אם smartctl לא נמצא, עליך להתקין את חבילת smartmontools באובונטו)
לאחר מכן ניתן להשוות את המספר הסידורי למספרים הסידוריים על התווית הפיזית בכוננים כדי להבין איזה מהם נכשל.
אבל הפעם לא היה לי כל כך מזל. הכונן היה מת לחלוטין ואף סירב לספק SMART או נתונים אחרים, כולל המספר הסידורי.
מכיוון שהייתה לי גישה פיזית לשרת (שאתה באמת צריך אם אתה מתכוון להחליף כונן פיזי בעצמך, אני מניח ;-)) והשרת למעשה פעל כשהדיסק כשל (והמשיך לפעול תקין בזכות יתירות RAID-6), הלכתי עם השיטה הפרימיטיבית באמת, אבל למעשה מאוד יעילה וברורה, פשוט להעתיק קובץ גדול לשרת ולצפות באיזה HDD הבהוב. תוך כמה שניות זיהיתי את האשם.
כעת, לפני ששולפים את הכונן הפיזי, מומלץ ליידע את mdadm באופן רשמי על כוונה זו, על ידי הוצאת פקודה זו (החלף את שמות המכשירים בשמות שלך לפי המתאים):
לאחר הצלחה, mdadm תשיב בהודעה שאומרת שהיא "הסירה" את הכונן, ככל הנראה מכיוון שמכשיר הפשיטה הוירטואלי פועל באותה עת.
אם הוא נכשל עם הודעת שגיאה הדומה ל"התקן או משאב תפוס", ייתכן ש-mdadm למעשה לא רשם את הכונן ככזב מוחלט. כדי לגרום לזה לעשות את זה, הפק את הפקודה הזו (שוב, זכור להחליף את שמות המכשירים בשמות שלך לפי הצורך):
לאחר מכן, אתה אמור להיות מסוגל להסיר את המכשיר מהמערך עם הפקודה הקודמת.
עכשיו הגיע הזמן להחליף את הכונן בפועל. אם אתה ממש ממש - כאילו, באמת - בטוח שהמכשיר והבקר שלך תומכים בהחלפה חמה, תוכל לעשות זאת מבלי לכבות את המכשיר. זו תהיה הדרך להמשיך במערכות ייצור קריטיות הפועלות על חומרת שרת אמיתית ומתאימה שאתה יודע בוודאות שהיא יכולה להתמודד עם זה. עם זאת, שרת הקבצים הביתי שלי מבוסס על לוח אם שולחני ברמה צרכנית עם כמה בקרי SATA ללא שם למחצה בחריצי PCIe כדי לספק יותר יציאות SATA.
למרות שבדרך כלל SATA אמור לתמוך בהחלפה חמה, לא התכוונתי להסתכן בשום דבר בהגדרה הזו, אז בחרתי לכבות את המכשיר בזמן החלפת הכונן.
לפני שתעשה זאת, מומלץ להגיב על מכשיר ה-Raid בקובץ /etc/fstab כך ש-Ubuntu לא תנסה להעלות אותו אוטומטית באתחול הבא, מכיוון שהוא עלול להיתקע ולאלץ אותך להיכנס למצב התאוששות עקב מערך ה-RAID השפל. זה אולי לא בעיה גדולה אם זו מערכת שולחנית, אבל אני מפעיל את השרת הזה בלי ראש בלי צג או מקלדת מחוברים, אז זה יהיה קצת טרחה.
לאחר אתחול המחשב עם הכונן החדש והנוצץ מותקן, השתמש ב-lsblk או באמצעי אחר כדי לזהות אותו. אם לא שינית שום דבר אחר, כנראה (אך לא בהכרח ) הוא יקבל את אותו שם כמו הכונן שהחלפת. במקרה שלי זה קרה, אז החדש נקרא גם /dev/sdf.
מכיוון שהמערך שלי מבוסס על מחיצות ולא על מכשירים פיזיים, הייתי צריך להעתיק את טבלת המחיצות מכונן עובד לכונן החדש כדי לוודא שהן זהות לחלוטין. אם אתה מפעיל את המערך שלך על מכשירים פיזיים במקום זאת, תוכל לדלג על שלב זה.
השתמשתי ב-sgdisk למטרה זו, העתקתי את טבלת המחיצות מ-/dev/sdc ל-/dev/sdf. הקפד להחליף את שמות המכשירים כך שיתאימו לשמות שלך בהתאם למתאים.
שימו לב לסדר כאן: תחילה רשום את הכונן "ל"! זה קצת מנוגד לאינטואיציה בשבילי, אבל רק תוודא שאתה עושה את זה כמו שצריך כדי שלא תקבל עוד כשל בכונן במערך ;-)
לאחר מכן כדי למנוע התנגשויות UUID, צור UUIDs חדשים עבור הכונן החדש:
ועכשיו סוף סוף הגיע הזמן להוסיף את הכונן החדש למערך ולהתחיל את מסיבת הבנייה מחדש! (בסדר, זו לא באמת מסיבה, זה למעשה תהליך די איטי ומעצבן מכיוון שאתה ממש, אבל ממש לא רוצה שכונן נוסף ייכשל בשלב זה. בירה עשויה לעזור, אבל)
בכל מקרה, כדי להוסיף את הכונן החדש למערך, הפק את הפקודה הזו (שוב, הקפד להחליף את שמות המכשירים בשמות שלך לפי המתאים):
אם הכל ילך כשורה, הכונן יתווסף למערך ללא שיהוקים. אני מאמין שהוא בעצם מתווסף כ-"hot spare" כברירת מחדל, אבל מכיוון שחסר למערך הזה דיסק (זה שנכשל), הוא מיד נכנס לשימוש ותהליך הבנייה מחדש יתחיל.
אתה יכול לפקוח עין על זה כך:
זה כנראה ייקח זמן מה; בשרת הנמוך שלי (מבוסס בעיקר על חומרה בדרגת צרכן וכוננים שולחניים, שימו לב) הוא הצליח להגיע לקצת פחות מ-100 מגה-בייט לשנייה. זכור שזה RAID-6, אז יש הרבה חישובי זוגיות מעורבים בבנייה מחדש; RAID-10 היה הרבה יותר מהיר. למכונה הספציפית הזו יש AMD A10 9700E מעבד מרובע ליבות (ה-"E" כלומר דגם חסכוני באנרגיה בתת-שעון, כלומר לא סופר מהיר), רק כדי לתת לכם מושג למה לצפות. עם תשעה כונני 8 TB בהגדרה שלי, הבנייה מחדש המלאה ארכה קצת יותר מ-24 שעות.
במהלך הבנייה מחדש, אתה יכול להעלות את מערכת הקבצים על המערך ולהשתמש בה כרגיל אם תרצה, אבל אני מעדיף להשאיר את זה לבנייה מחדש עד שזה יסתיים. זכור שאם כונן אחד ייכשל, כונן אחר עלול להופיע בקרוב, אז אתה רוצה שהבנייה מחדש תתבצע מהר ככל האפשר מכיוון שאתה באמת לא רוצה שכונן אחר ייכשל במהלך זה. לכן, אל תעמיס עליו עם IO אחרים שאינם נחוצים בהחלט.
לאחר שזה יסתיים, הוסף אותו בחזרה לקובץ /etc/fstab שלך, אתחל מחדש ותיהנה מהקבצים שלך :-)