उबंटूवरील mdadm अ‍ॅरेमध्ये अयशस्वी ड्राइव्ह बदलणे
प्रकाशित: १५ फेब्रुवारी, २०२५ रोजी १०:०३:१९ PM UTC
जर तुम्ही mdadm RAID अ‍ॅरेमध्ये ड्राइव्ह बिघाडाच्या भयानक परिस्थितीत असाल, तर हा लेख उबंटू सिस्टमवर ते योग्यरित्या कसे बदलायचे ते स्पष्ट करतो.
Replacing a Failed Drive in an mdadm Array on Ubuntu
या पोस्टमधील माहिती उबंटू १८.०४ आणि त्याच्या रिपॉझिटरीजमध्ये समाविष्ट असलेल्या mdadm च्या आवृत्तीवर आधारित आहे; v4.1-rc1 लिहिण्याच्या वेळी. ती इतर आवृत्त्यांसाठी वैध असू शकते किंवा नसू शकते.
माझ्या होम फाइल सर्व्हरमध्ये अलीकडेच अचानक ड्राइव्ह बिघाड झाला, ज्यामध्ये mdadm RAID-6 अ‍ॅरेमध्ये नऊ ड्राइव्ह असतात. ते नेहमीच भयानक असते, परंतु सुदैवाने मी दुसऱ्या दिवशी आधीच डिलिव्हर झालेला रिप्लेसमेंट ड्राइव्ह पटकन मिळवू शकलो जेणेकरून मी पुनर्बांधणी सुरू करू शकलो.
मी सुरुवातीला फाइल सर्व्हर सेटअप केला तेव्हा मी थोडा जास्तच स्वस्त होतो हे मान्य आहे; फक्त दोन ड्राइव्ह प्रत्यक्ष NAS ड्राइव्ह आहेत (Seagate IronWolf), तर उर्वरित डेस्कटॉप ड्राइव्ह आहेत (Seagate Barracuda). आश्चर्याची गोष्ट नाही की, तो डेस्कटॉप ड्राइव्हपैकी एक होता जो सोडून गेला होता (जवळजवळ तीन वर्षांच्या सेवेनंतर), परंतु तो पूर्णपणे मृत झाला होता; डेस्कटॉप USB एन्क्लोजरमध्ये हलवल्यानंतर मला त्यातून फक्त एक त्रासदायक क्लिकिंग आवाज मिळाला आणि Ubuntu 20.04 किंवा Windows 10 हे दोन्हीही ते शोधू शकले नाहीत.
बरं, रिप्लेसमेंट पार्टबद्दल (आणि हो, मी घेतलेला नवीन ड्राइव्ह आयर्नवोल्फ होता, धडा शिकलो) - रनिंग अ‍ॅरेमध्ये ड्राइव्ह गमावणे जितके भयानक आहे तितकेच ते बदलण्याची योग्य प्रक्रिया माहित नसल्यास ते आणखी भयानक आहे. mdadm अ‍ॅरेमध्ये अयशस्वी ड्राइव्ह बदलण्याची ही पहिलीच वेळ नाही, परंतु सुदैवाने ते इतके दुर्मिळ आहे की मला सहसा योग्य कमांड शोधाव्या लागतात. यावेळी मी भविष्यातील संदर्भासाठी माझा स्वतःचा छोटासा मार्गदर्शक तयार करण्याचा निर्णय घेतला.
म्हणून, सर्वप्रथम, जेव्हा तुम्हाला mdadm कडून भयानक अपयशी घटनेचा ई-मेल येतो, तेव्हा तुम्हाला कोणता ड्राइव्ह अयशस्वी झाला आहे हे ओळखावे लागेल. अर्थात, ते तुम्हाला डिव्हाइसचे नाव सांगेल (माझ्या बाबतीत /dev/sdf), परंतु ते प्रत्यक्षात कोणते भौतिक ड्राइव्ह आहे हे कदाचित स्पष्ट नसेल कारण मशीन बूट झाल्यावर ती नावे बदलू शकतात.
जर तुम्हाला खात्री नसेल की कोणते डिव्हाइस नाव अयशस्वी झाले आहे, तर तुम्ही खालील कमांड वापरून शोधू शकता (/dev/md0 ला तुमच्या RAID डिव्हाइसने बदला):
नमूद केल्याप्रमाणे, माझ्या बाबतीत ते /dev/sdf होते, तर चला ते पुढे चालू ठेवूया.
मग, तुम्ही ही आज्ञा देऊन अयशस्वी ड्राइव्हचा सिरीयल नंबर शोधण्याचा प्रयत्न करू शकता:
(जर smartctl सापडले नाही, तर तुम्हाला उबंटूवर smartmontools पॅकेज स्थापित करावे लागेल)
त्यानंतर कोणता ड्राइव्ह अयशस्वी झाला आहे हे शोधण्यासाठी सिरीयल नंबरची तुलना ड्राइव्हवरील भौतिक लेबलवरील सिरीयल नंबरशी केली जाऊ शकते.
यावेळी, मी इतका भाग्यवान नव्हतो. ड्राइव्ह पूर्णपणे बंद होता आणि त्याने SMART किंवा सिरीयल नंबरसह इतर डेटा देण्यासही नकार दिला.
माझ्याकडे सर्व्हरवर प्रत्यक्ष प्रवेश असल्याने (जर तुम्ही स्वतः भौतिक ड्राइव्ह बदलणार असाल तर तुम्हाला खरोखरच याची आवश्यकता असेल, मला वाटते ;-)) आणि डिस्क बिघडली तेव्हा सर्व्हर प्रत्यक्षात चालू होता (आणि RAID-6 रिडंडन्सीमुळे ते व्यवस्थित चालू राहिले), मी खरोखरच आदिम, परंतु प्रत्यक्षात अत्यंत प्रभावी आणि स्पष्ट पद्धत वापरली, फक्त सर्व्हरवर मोठी फाइल कॉपी करणे आणि कोणता HDD लाईट चमकत नाही हे पाहणे. काही सेकंदातच मी गुन्हेगार ओळखला.
आता, फिजिकल ड्राइव्ह काढून टाकण्यापूर्वी, हा आदेश देऊन (योग्य असल्यास डिव्हाइसची नावे तुमच्या स्वतःच्या नावाने बदला) mdadm ला औपचारिकपणे या हेतूची माहिती देणे चांगले आहे:
यशस्वी झाल्यास, mdadm एक संदेश देईल की त्याने ड्राइव्ह "हॉट रिमूव्ह" केला आहे, कारण त्यावेळी व्हर्च्युअल रेड डिव्हाइस प्रत्यक्षात चालू आहे.
जर ते "डिव्हाइस किंवा रिसोर्स बिझी" सारख्या एरर मेसेजसह अयशस्वी झाले, तर कदाचित mdadm ने ड्राइव्ह पूर्णपणे अयशस्वी झाल्यामुळे नोंदणीकृत केले नसेल. ते करण्यासाठी, ही आज्ञा द्या (पुन्हा एकदा, योग्य असल्यास डिव्हाइसची नावे तुमच्या स्वतःच्या नावांनी बदलण्याचे लक्षात ठेवा):
त्यानंतर, तुम्ही मागील कमांड वापरून अॅरेमधून डिव्हाइस काढू शकाल.
आता ड्राइव्ह बदलण्याची वेळ आली आहे. जर तुम्हाला खरोखर, खरोखर - खरोखर - खात्री असेल की तुमचे मशीन आणि कंट्रोलर हॉट स्वॅपिंगला सपोर्ट करतात, तर तुम्ही मशीन बंद न करता हे करू शकता. वास्तविक, योग्य सर्व्हर हार्डवेअरवर चालणाऱ्या क्रिटिकल प्रोडक्शन सिस्टमवर जाण्याचा हा मार्ग असेल जो तुम्हाला माहिती आहे की तो हाताळू शकतो. माझा होम फाइल सर्व्हर कंझ्युमर ग्रेड डेस्कटॉप मदरबोर्डवर आधारित आहे ज्यामध्ये PCIe स्लॉटमध्ये काही सेमी-नॉन-नेम SATA कंट्रोलर्स आहेत जेणेकरून अधिक SATA पोर्ट मिळतील.
जरी SATA सामान्यतः हॉट स्वॅपिंगला समर्थन देत असले तरी, मी या सेटअपमध्ये काहीही धोका पत्करणार नव्हतो, म्हणून मी ड्राइव्ह बदलताना मशीन बंद करण्याचा पर्याय निवडला.
ते करण्यापूर्वी, /etc/fstab फाइलमध्ये raid डिव्हाइसची टिप्पणी करणे चांगले आहे जेणेकरून उबंटू पुढील बूटवर ते स्वयंचलितपणे माउंट करण्याचा प्रयत्न करणार नाही, कारण ते हँग होऊ शकते आणि खराब झालेल्या RAID अ‍ॅरेमुळे तुम्हाला रिकव्हरी मोडमध्ये आणू शकते. जर ते डेस्कटॉप सिस्टम असेल तर ती मोठी समस्या असू शकत नाही, परंतु मी मॉनिटर किंवा कीबोर्ड जोडलेले नसलेले हेडलेस सर्व्हर चालवतो, त्यामुळे हे थोडे त्रासदायक असेल.
नवीन चमकदार ड्राइव्ह बसवून मशीन बूट केल्यानंतर, ते ओळखण्यासाठी lsblk किंवा इतर कोणत्याही माध्यमांचा वापर करा. जर तुम्ही इतर काहीही बदलले नसेल, तर कदाचित ते (पण आवश्यक नाही) तुम्ही बदललेल्या ड्राइव्हसारखेच नाव घेईल. माझ्या बाबतीत ते बदलले, म्हणून नवीन ड्राइव्हला /dev/sdf असेही म्हणतात.
माझा अ‍ॅरे भौतिक उपकरणांऐवजी विभाजनांवर आधारित असल्याने, ते अगदी सारखेच आहेत याची खात्री करण्यासाठी मला विभाजन सारणी कार्यरत ड्राइव्हवरून नवीन ड्राइव्हवर कॉपी करावी लागली. जर तुम्ही तुमचा अ‍ॅरे भौतिक उपकरणांवर चालवला तर तुम्ही ही पायरी वगळू शकता.
मी यासाठी sgdisk वापरले, विभाजन सारणी /dev/sdc वरून /dev/sdf मध्ये कॉपी केली. योग्यरित्या तुमच्या स्वतःच्या नावांशी जुळण्यासाठी डिव्हाइसची नावे बदलण्याची खात्री करा.
येथे क्रम लक्षात घ्या : तुम्ही "to" ड्राइव्ह प्रथम सूचीबद्ध करा! हे माझ्यासाठी थोडेसे उलट आहे, परंतु तुम्ही ते योग्यरित्या केले आहे याची खात्री करा जेणेकरून तुम्हाला अ‍ॅरेमध्ये पुन्हा ड्राइव्ह अपयश येणार नाही ;-)
नंतर UUID संघर्ष टाळण्यासाठी, नवीन ड्राइव्हसाठी नवीन UUID जनरेट करा:
आणि आता शेवटी अ‍ॅरेमध्ये नवीन ड्राइव्ह जोडण्याची आणि रीबिल्ड पार्टी सुरू करण्याची वेळ आली आहे! (ठीक आहे, ही खरोखर पार्टी नाही, ती प्रत्यक्षात खूपच मंद आणि अस्वस्थ करणारी प्रक्रिया आहे कारण तुम्हाला खरोखरच यावेळी दुसरा ड्राइव्ह बिघडायला नको आहे. तथापि, बिअर मदत करू शकते)
असो, अ‍ॅरेमध्ये नवीन ड्राइव्ह जोडण्यासाठी, ही कमांड द्या (पुन्हा एकदा, योग्य असल्यास डिव्हाइसची नावे तुमच्या स्वतःच्या नावाने बदलण्याची खात्री करा):
जर सर्व काही व्यवस्थित झाले, तर ड्राइव्ह कोणत्याही अडचणीशिवाय अ‍ॅरेमध्ये जोडला जाईल. मला वाटते की तो प्रत्यक्षात डीफॉल्टनुसार "हॉट स्पेअर" म्हणून जोडला गेला आहे, परंतु या अ‍ॅरेमध्ये डिस्क गहाळ असल्याने (जी अयशस्वी झाली), ती ताबडतोब वापरात आणली जाते आणि पुनर्बांधणी प्रक्रिया सुरू होईल.
तुम्ही त्यावर असे लक्ष ठेवू शकता:
यास कदाचित थोडा वेळ लागेल; माझ्या कमी दर्जाच्या सर्व्हरवर (मुख्यतः ग्राहक श्रेणीतील हार्डवेअर आणि डेस्कटॉप ड्राइव्हवर आधारित, लक्षात ठेवा) ते १०० एमबी/सेकंदांपेक्षा कमी गतीने पोहोचू शकले. लक्षात ठेवा की हे RAID-6 आहे, म्हणून पुनर्बांधणीमध्ये बरेच पॅरिटी कॅल्क्युलेशन समाविष्ट आहेत; RAID-10 खूप वेगवान झाला असता. या विशिष्ट मशीनमध्ये AMD A10 9700E क्वाड कोर CPU आहे ("E" म्हणजे ते कमी-घड्याळ असलेले ऊर्जा कार्यक्षम मॉडेल आहे, म्हणजेच सुपर फास्ट नाही), फक्त तुम्हाला काय अपेक्षा करावी याची कल्पना देण्यासाठी. माझ्या सेटअपमध्ये नऊ ८ TB ड्राइव्हसह, संपूर्ण पुनर्बांधणीला फक्त २४ तासांपेक्षा जास्त वेळ लागला.
पुनर्बांधणी दरम्यान, तुम्ही अॅरेवर फाइलसिस्टम माउंट करू शकता आणि तुम्हाला हवे असल्यास ते सामान्यपणे वापरू शकता, परंतु ते पूर्ण होईपर्यंत मी ते पुनर्बांधणीवर सोडण्यास प्राधान्य देतो. लक्षात ठेवा की जर एक ड्राइव्ह अयशस्वी झाला तर दुसरा लवकरच येऊ शकतो, म्हणून तुम्हाला पुनर्बांधणी शक्य तितक्या लवकर पूर्ण करायची आहे कारण त्या दरम्यान दुसरा ड्राइव्ह अयशस्वी होऊ नये असे तुम्हाला वाटते. म्हणून, त्यावर इतर IO भार टाकू नका जे पूर्णपणे आवश्यक नाही.
एकदा ते पूर्ण झाले की, ते तुमच्या /etc/fstab फाइलमध्ये परत जोडा, रीबूट करा आणि तुमच्या फाइल्सचा आनंद घ्या :-)