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

Այս գրառման մեջ տեղեկատվությունը հիմնված է 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 սարքով):

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

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

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

Սերիական համարը կարող է համեմատվել սկավառակների վրա ֆիզիկական պիտակի վրա նշված սերիական համարների հետ՝ պարզելու համար, թե որն է խափանվել։

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

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

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

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

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

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

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

Չնայած SATA-ն ընդհանուր առմամբ պետք է աջակցի «hot swaping» (տաք փոխարինում), ես չէի պատրաստվում որևէ բան ռիսկի դիմել այս կարգավորման մեջ, ուստի որոշեցի անջատել համակարգիչը սկավառակը փոխարինելիս։

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

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

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

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

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

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

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

Ամեն դեպքում, նոր սկավառակը զանգվածին ավելացնելու համար գործարկեք այս հրամանը (կրկին, համոզվեք, որ սարքերի անունները փոխարինել եք ձեր սեփականով, ըստ անհրաժեշտության):

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

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

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

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

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