ઉબુન્ટુ પર mdadm એરેમાં નિષ્ફળ ડ્રાઇવને બદલવી

આ પોસ્ટમાં આપેલી માહિતી ઉબુન્ટુ 18.04 અને તેના ભંડારોમાં સમાવિષ્ટ mdadm ના સંસ્કરણ પર આધારિત છે; v4.1-rc1 લખતી વખતે. તે અન્ય સંસ્કરણો માટે માન્ય હોઈ શકે છે અથવા ન પણ હોઈ શકે.

તાજેતરમાં મારા હોમ ફાઇલ સર્વરમાં અચાનક ડ્રાઇવ ફેઇલર આવી ગયું, જેમાં mdadm RAID-6 એરેમાં નવ ડ્રાઇવ હોય છે. તે હંમેશા ડરામણી હોય છે, પરંતુ સદભાગ્યે હું ઝડપથી રિપ્લેસમેન્ટ ડ્રાઇવ મેળવી શક્યો જે બીજા દિવસે જ ડિલિવર થઈ ગઈ હતી જેથી હું ફરીથી બાંધકામ શરૂ કરી શકું.

જ્યારે મેં મૂળ ફાઇલ સર્વર સેટઅપ કર્યું ત્યારે હું ખૂબ જ સસ્તો હતો તે સ્વીકાર્ય છે; ફક્ત બે ડ્રાઇવ વાસ્તવિક NAS ડ્રાઇવ્સ (સીગેટ આયર્નવોલ્ફ) છે, જ્યારે બાકીના ડેસ્કટોપ ડ્રાઇવ્સ (સીગેટ બારાકુડા) છે. આશ્ચર્યજનક નથી કે, તે ડેસ્કટોપ ડ્રાઇવ્સમાંથી એક હતી જે છોડી દીધી હતી (લગભગ ત્રણ વર્ષની સેવા પછી, જોકે). તે સંપૂર્ણપણે મૃત હતી; તેને ડેસ્કટોપ USB એન્ક્લોઝરમાં ખસેડ્યા પછી મને તેમાંથી ફક્ત એક અસ્વસ્થ ક્લિકિંગ અવાજ મળ્યો અને ઉબુન્ટુ 20.04 કે વિન્ડોઝ 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 જનરેટ કરો:

અને હવે આખરે એરેમાં નવી ડ્રાઇવ ઉમેરવાનો અને રિબિલ્ડ પાર્ટી શરૂ કરવાનો સમય આવી ગયો છે! (ઠીક છે, તે ખરેખર પાર્ટી નથી, તે ખરેખર ખૂબ જ ધીમી અને ચિંતાજનક પ્રક્રિયા છે કારણ કે તમે ખરેખર, ખરેખર આ સમયે બીજી ડ્રાઇવ નિષ્ફળ જાય તેવું ઇચ્છતા નથી. જોકે, બીયર મદદ કરી શકે છે)

ગમે તે હોય, એરેમાં નવી ડ્રાઇવ ઉમેરવા માટે, આ આદેશ જારી કરો (ફરીથી, યોગ્ય હોય તો ઉપકરણના નામોને તમારા પોતાના નામથી બદલવાની ખાતરી કરો):

જો બધું બરાબર રહેશે, તો ડ્રાઇવને કોઈ અડચણ વિના એરેમાં ઉમેરવામાં આવશે. મારું માનવું છે કે તે વાસ્તવમાં ડિફોલ્ટ રૂપે "હોટ સ્પેર" તરીકે ઉમેરવામાં આવ્યું છે, પરંતુ આ એરેમાં ડિસ્ક ખૂટે છે (જે નિષ્ફળ ગઈ), તેથી તે તરત જ ઉપયોગમાં લેવામાં આવશે અને પુનઃનિર્માણ પ્રક્રિયા શરૂ થશે.

તમે તેના પર આ રીતે નજર રાખી શકો છો:

આમાં કદાચ થોડો સમય લાગશે; મારા સામાન્ય સર્વર પર (મોટાભાગે ગ્રાહક ગ્રેડ હાર્ડવેર અને ડેસ્કટોપ ડ્રાઇવ્સ પર આધારિત, યાદ રાખો) તે 100 MB/sec થી ઓછી ઝડપે પહોંચી શક્યું. ધ્યાનમાં રાખો કે આ RAID-6 છે, તેથી પુનઃનિર્માણ સાથે ઘણી બધી પેરિટી ગણતરીઓ સામેલ છે; RAID-10 ખૂબ ઝડપી હોત. આ ચોક્કસ મશીનમાં AMD A10 9700E ક્વોડ કોર CPU ("E" એટલે કે તે એક ઓછી ઘડિયાળવાળું ઊર્જા કાર્યક્ષમ મોડેલ છે, એટલે કે સુપર ફાસ્ટ નહીં), ફક્ત તમને શું અપેક્ષા રાખવી તેનો ખ્યાલ આપવા માટે. મારા સેટઅપમાં નવ 8 TB ડ્રાઇવ્સ સાથે, સંપૂર્ણ પુનઃનિર્માણમાં 24 કલાકથી વધુ સમય લાગ્યો.

પુનઃનિર્માણ દરમિયાન, તમે ફાઇલસિસ્ટમને એરે પર માઉન્ટ કરી શકો છો અને જો તમે ઈચ્છો તો તેનો સામાન્ય રીતે ઉપયોગ કરી શકો છો, પરંતુ હું તેને પુનઃનિર્માણ પર છોડી દેવાનું પસંદ કરું છું જ્યાં સુધી તે પૂર્ણ ન થાય. ધ્યાનમાં રાખો કે જો એક ડ્રાઇવ નિષ્ફળ જાય, તો બીજી ટૂંક સમયમાં આવી શકે છે, તેથી તમે ઇચ્છો છો કે પુનઃનિર્માણ શક્ય તેટલું ઝડપથી પૂર્ણ થાય કારણ કે તમે ખરેખર ઇચ્છતા નથી કે તે દરમિયાન બીજી ડ્રાઇવ નિષ્ફળ જાય. તેથી, તેના પર અન્ય IO નો બોજ ન નાખો જે સખત જરૂરી નથી.

એકવાર તે થઈ જાય, પછી તેને તમારી /etc/fstab ફાઇલમાં પાછું ઉમેરો, રીબૂટ કરો અને તમારી ફાઇલોનો આનંદ માણો :-)