Miklix

Ubuntu-ում ձախողված դրայվի փոխարինում mdadm զանգվածում

Հրապարակվել է՝ 15 փետրվարի, 2025 թ., 22:04:12 UTC

Եթե ​​mdadm RAID զանգվածում սկավառակի ձախողման սարսափելի իրավիճակում եք, այս հոդվածը բացատրում է, թե ինչպես ճիշտ փոխարինել այն Ubuntu համակարգում:


Այս էջը ավտոմատ կերպով թարգմանվել է անգլերենից՝ հնարավորինս շատ մարդկանց համար հասանելի դարձնելու համար: Ցավոք, մեքենայական թարգմանությունը դեռ կատարելագործված տեխնոլոգիա չէ, ուստի կարող են սխալներ առաջանալ: Եթե ​​նախընտրում եք, կարող եք դիտել բնօրինակ անգլերեն տարբերակը այստեղ.

Replacing a Failed Drive in an mdadm Array on Ubuntu

Այս գրառման տեղեկատվությունը հիմնված է Ubuntu 18.04-ի և դրա պահեստներում ներառված mdadm-ի տարբերակի վրա. v4.1-rc1 գրելու պահին: Այն կարող է վավեր լինել կամ չգործել այլ տարբերակների համար:

Վերջերս իմ տան ֆայլերի սերվերում սկավառակի հանկարծակի ձախողում ունեցա, որը բաղկացած է mdadm RAID-6 զանգվածի ինը կրիչից: Դա միշտ սարսափելի է, բայց ես, բարեբախտաբար, կարողացա արագ գտնել փոխարինող սկավառակ, որը առաքվել էր արդեն հաջորդ օրը, որպեսզի կարողանամ սկսել վերակառուցումը:

Ես, իհարկե, մի քիչ շատ էժան էի, երբ սկզբնապես կարգավորեցի ֆայլերի սերվերը; կրիչներից միայն երկուսն են իրական NAS կրիչներ (Seagate IronWolf), մինչդեռ մնացածը աշխատասեղանի կրիչներ են (Seagate Barracuda): Զարմանալի չէ, որ դա աշխատասեղանի կրիչներից մեկն էր, որը հրաժարվել էր (չնայած, գրեթե երեք տարվա ծառայությունից հետո): Այն ամբողջովին մեռած էր. Այն աշխատասեղանի USB խցիկ տեղափոխելուց հետո այն ամենը, ինչ ես դուրս եկա դրանից, անհանգստացնող կտտոցների ձայն էր, և ոչ Ubuntu 20.04-ը, ոչ Windows 10-ը չկարողացան հայտնաբերել այն:

Օհ, լավ, փոխարինող մասի մասին (և այո, իմ գնած նոր սկավառակը IronWolf էր, սովորած դասը) - որքան սարսափելի է, որքան այն կորցնում է սկավառակը գործող զանգվածում, նույնիսկ ավելի սարսափելի է, եթե չգիտեք այն փոխարինելու ճիշտ ընթացակարգը: Առաջին անգամը չէ, որ ես ստիպված եմ եղել փոխարինել ձախողված սկավառակը mdadm զանգվածում, բայց, բարեբախտաբար, դա այնքան հազվադեպ է, որ ես սովորաբար պետք է փնտրեմ համապատասխան հրամանները: Այս անգամ ես որոշեցի ստեղծել իմ փոքրիկ ուղեցույցը հետագա հղումների համար:

Այսպիսով, առաջին հերթին, երբ mdadm-ից ստանում եք սարսափելի ձախողման իրադարձության էլ. Իհարկե, այն ձեզ կասի սարքի անունը (իմ դեպքում /dev/sdf), բայց հավանաբար պարզ չէ, թե որ ֆիզիկական սկավառակն է իրականում, քանի որ այդ անունները կարող են փոխվել, երբ մեքենան բեռնվում է:

Եթե ​​նույնիսկ վստահ չեք, թե որ սարքի անունը ձախողվել է, կարող եք օգտագործել հետևյալ հրամանը՝ պարզելու համար (փոխարինեք /dev/md0-ը ձեր RAID սարքով).

mdadm -–query -–detail /dev/md0

Ինչպես նշվեց, իմ դեպքում դա /dev/sdf էր, ուստի եկեք շարունակենք դրանով։

Այնուհետև կարող եք փորձել գտնել ձախողված սկավառակի սերիական համարը՝ տալով այս հրամանը.

smartctl -–all /dev/sdf | grep -i 'Serial'

(եթե smartctl-ը չի գտնվել, դուք պետք է տեղադրել smartmontools փաթեթը Ubuntu-ում)

Այնուհետև սերիական համարը կարելի է համեմատել կրիչների վրա ֆիզիկական պիտակի վրա նշված սերիական համարների հետ՝ պարզելու, թե որն է ձախողվել:

Այս անգամ, սակայն, ես այնքան էլ բախտավոր չէի: Սկավառակը ամբողջովին մեռած էր և նույնիսկ հրաժարվեց տրամադրել SMART կամ այլ տվյալներ, ներառյալ սերիական համարը:

Քանի որ ես ֆիզիկական մուտք ունեի դեպի սերվեր (որը ձեզ իսկապես անհրաժեշտ է, եթե դուք պատրաստվում եք փոխարինել ֆիզիկական դրայվը, ենթադրում եմ, ;-)) և սերվերն իրականում աշխատում էր, երբ սկավառակը ձախողվեց (և շարունակեց լավ աշխատել RAID-6 ավելորդության շնորհիվ), ես գնացի շատ պարզունակ, բայց իրականում շատ արդյունավետ և ակնհայտ մեթոդի՝ պարզապես մեծ ֆայլը պատճենելու HDD լույսը սերվերին և դիտելով: Մի քանի վայրկյանում ես բացահայտեցի մեղավորին։

Այժմ, նախքան ֆիզիկական դրայվը հեռացնելը, լավ գաղափար է պաշտոնապես տեղեկացնել mdadm-ին այս մտադրության մասին՝ տալով այս հրամանը (համապատասխանաբար փոխարինեք սարքի անունները ձեր անուններով).

mdadm -–manage /dev/md0 -–remove /dev/sdf1

Հաջողության դեպքում mdadm-ը կպատասխանի հաղորդագրությունով, որում ասվում է, որ այն «տաք հեռացրեց» սկավառակը, ըստ երևույթին այն պատճառով, որ վիրտուալ ռեյդի սարքն այդ պահին իրականում աշխատում է:

Եթե ​​այն ձախողվում է «սարքը կամ ռեսուրսը զբաղված է» նման սխալի հաղորդագրությամբ, կարող է լինել, որ mdadm-ը իրականում չի գրանցել սկավառակի ամբողջական ձախողումը: Դա անելու համար թողարկեք այս հրամանը (կրկին, հիշեք, որ հարմարության դեպքում սարքի անունները փոխարինեք ձեր անուններով).

mdadm --manage /dev/md0 --fail /dev/sdf

Դրանից հետո դուք պետք է կարողանաք սարքը հեռացնել զանգվածից նախորդ հրամանով:

Այժմ ժամանակն է իրականում փոխարինել սկավառակը: Եթե ​​իսկապես վստահ եք , որ ձեր մեքենան և կարգավորիչը աջակցում են տաք փոխանակմանը, կարող եք դա անել առանց սարքն անջատելու: Դա կլինի այն ճանապարհը, որով կարելի է գնալ կրիտիկական արտադրական համակարգերի վրա, որոնք աշխատում են իրական, պատշաճ սերվերի ապարատով, որը դուք գիտեք, որ իրականում կարող է կարգավորել այն: Իմ տնային ֆայլերի սերվերը հիմնված է սպառողական կարգի աշխատասեղանի մայր տախտակի վրա, որը ունի մի քանի կիսաանվան SATA կարգավորիչներ PCIe սլոտներում, սակայն ավելի շատ SATA պորտեր տրամադրելու համար:

Չնայած SATA-ն, ընդհանուր առմամբ, պետք է աջակցի տաք փոխանակմանը, ես չէի պատրաստվում որևէ բան վտանգի ենթարկել այս կարգավորումը, ուստի որոշեցի անջատել մեքենան սկավառակը փոխարինելիս:

Նախքան դա անելը, լավ գաղափար է մեկնաբանել Raid սարքը /etc/fstab ֆայլում, որպեսզի Ubuntu-ն չփորձի այն ավտոմատ կերպով տեղադրել հաջորդ բեռնման վրա, քանի որ այն կարող է կախել և ստիպել ձեզ անցնել վերականգնման ռեժիմ՝ նսեմացված RAID զանգվածի պատճառով: Դա կարող է մեծ խնդիր չլինել, եթե դա աշխատասեղանի համակարգ է, բայց ես աշխատում եմ այս սերվերը առանց գլխի առանց մոնիտորների կամ ստեղնաշարի կցված, այնպես որ դա մի փոքր դժվարություն կլինի:

Տեղադրված փայլուն նոր սկավառակով սարքը բեռնելուց հետո օգտագործեք lsblk կամ այլ միջոցներ՝ այն նույնացնելու համար: Եթե ​​որևէ այլ բան չեք փոխել, այն հավանաբար (բայց ոչ պարտադիր ) կստանա նույն անունը, ինչ ձեր փոխարինած սկավառակը: Իմ դեպքում դա արեց, ուստի նորը կոչվում է նաև /dev/sdf:

Քանի որ իմ զանգվածը հիմնված է ոչ թե ֆիզիկական սարքերի, այլ միջնորմների վրա, ես պետք է պատճենեի բաժանման աղյուսակը աշխատանքային սկավառակից նոր սկավառակ՝ համոզվելու համար, որ դրանք նույնն են: Եթե ​​փոխարենը գործարկեք ձեր զանգվածը ֆիզիկական սարքերի վրա, կարող եք բաց թողնել այս քայլը:

Ես այս նպատակով օգտագործեցի sgdisk-ը` պատճենելով բաժանման աղյուսակը /dev/sdc-ից /dev/sdf: Համոզվեք, որ փոխարինեք սարքի անունները, որպեսզի համապատասխանեն ձեր անուններին:

Ուշադրություն դարձրեք կարգին այստեղ. նախ նշեք «to» քշելը: Սա մի քիչ հակաինտուիտիվ է ինձ համար, բայց պարզապես համոզվեք, որ ճիշտ եք հասկանում, որպեսզի զանգվածում սկավառակի ևս մեկ ձախողում չստանաք ;-)

sgdisk -R /dev/sdf /dev/sdc

Այնուհետև UUID-ի կոնֆլիկտներից խուսափելու համար ստեղծեք նոր UUID-ներ նոր սկավառակի համար.

sgdisk -G /dev/sdf

Եվ հիմա վերջապես եկել է նոր դրայվը զանգվածին ավելացնելու և վերակառուցման երեկույթը սկսելու ժամանակը: (Լավ, դա իրականում խնջույք չէ, դա իրականում բավականին դանդաղ և անհանգստացնող գործընթաց է, քանի որ դուք իսկապես, իսկապես չեք ցանկանում, որ այս պահին մեկ այլ շարժիչ ձախողվի: Այնուամենայնիվ, գարեջուրը կարող է օգնել):

Ինչևէ, նոր սկավառակը զանգվածին ավելացնելու համար թողարկեք այս հրամանը (կրկին համոզվեք, որ համապատասխանաբար փոխարինեք սարքի անունները ձեր անուններով).

mdadm -–manage /dev/md0 -–add /dev/sdf1

Եթե ​​ամեն ինչ լավ ընթանա, սկավառակը կավելացվի զանգվածին առանց զկռտումների: Կարծում եմ, որ այն իրականում ավելացվել է որպես «տաք պահեստային» լռելյայն, բայց քանի որ այս զանգվածին բացակայում է սկավառակը (այն, որը ձախողվել է), այն անմիջապես գործարկվում է, և վերակառուցման գործընթացը կսկսվի:

Դուք կարող եք հետևել դրան այսպես.

watch cat /proc/mdstat

Սա հավանաբար որոշ ժամանակ կպահանջի. իմ ցածրակարգ սերվերի վրա (հիմնականում սպառողական կարգի ապարատային և աշխատասեղանի կրիչներ, նկատի ունեցեք) այն կարողացավ հասնել 100 ՄԲ/վ-ից մի փոքր պակաս: Հիշեք, որ սա RAID-6-ն է, ուստի վերակառուցման հետ կապված շատ հավասարաչափ հաշվարկներ կան. RAID-10-ը շատ ավելի արագ կլիներ: Այս կոնկրետ մեքենան ունի AMD A10 9700E քառամիջուկ պրոցեսոր («E»-ը նշանակում է, որ այն ցածր ժամացույցի էներգաարդյունավետ մոդել է, այսինքն՝ ոչ գերարագ), պարզապես ձեզ պատկերացում տալու համար, թե ինչ է սպասվում: Ինը 8 TB կրիչներով իմ կարգավորումներում, ամբողջական վերակառուցումը տևեց 24 ժամից մի փոքր ավելի:

Վերակառուցման ժամանակ դուք կարող եք ֆայլային համակարգը տեղադրել զանգվածի վրա և օգտագործել այն սովորականի պես, եթե ցանկանում եք, բայց ես նախընտրում եմ այն ​​թողնել վերակառուցմանը մինչև այն ավարտվի: Հիշեք, որ եթե մի դրայվը ձախողվի, շուտով կարող է հաջորդել մյուսը, այնպես որ դուք ցանկանում եք, որ վերակառուցումն իրականացվի հնարավորինս արագ, քանի որ դուք իսկապես չեք ցանկանում, որ մեկ այլ սկավառակ խափանվի դրա ընթացքում: Հետևաբար, մի ծանրաբեռնեք այն այլ IO-ներով, որոնք խիստ անհրաժեշտ չեն:

Ավարտելուց հետո այն նորից ավելացրեք ձեր /etc/fstab ֆայլին, վերագործարկեք և վայելեք ձեր ֆայլերը :-)

Կիսվեք Bluesky-ումԿիսվել Facebook-ումԿիսվեք LinkedIn-ումԿիսվեք Tumblr-ումԿիսվեք X-ումԿիսվեք LinkedIn-ումԿպցնել Պինթրեսթում

Միկել Բանգ Քրիստենսեն

Հեղինակի մասին

Միկել Բանգ Քրիստենսեն
Mikkel-ը miklix.com-ի ստեղծողն ու սեփականատերն է: Նա ունի ավելի քան 20 տարվա աշխատանքային փորձ՝ որպես պրոֆեսիոնալ համակարգչային ծրագրավորող/ծրագրային ապահովման մշակող և ներկայումս լրիվ դրույքով աշխատում է եվրոպական խոշոր ՏՏ կորպորացիայի մեջ: Երբ նա բլոգ չի գրում, նա իր ազատ ժամանակն անցկացնում է հետաքրքրությունների, հոբբիների և գործունեության լայն շրջանակի վրա, որոնք որոշ չափով կարող են արտացոլվել այս կայքում ընդգրկված թեմաների բազմազանության մեջ: