Ubuntu ရှိ mdadm Array တွင် မအောင်မြင်သော Drive ကို အစားထိုးခြင်း။

ဤပို့စ်ရှိ အချက်အလက်များသည် Ubuntu 18.04 နှင့် ၎င်း၏ repositories များတွင် ပါဝင်သော mdadm ဗားရှင်းကို အခြေခံထားသည်။ v4.1-rc1 ရေးသားချိန်တွင်ဖြစ်သည်။ အခြားဗားရှင်းများအတွက် မှန်ကန်မှုရှိနိုင်သည် သို့မဟုတ် မရှိနိုင်ပါ။

မကြာသေးခင်က ကျွန်တော့်ရဲ့ home file server မှာ mdadm RAID-6 array ထဲက drive ကိုးခုပါဝင်တဲ့ drive ချို့ယွင်းမှုတစ်ခု ရုတ်တရက်ကြုံခဲ့ရပါတယ်။ အဲဒါက အမြဲတမ်းကြောက်စရာကောင်းပေမယ့် ကံကောင်းထောက်မစွာပဲ နောက်တစ်နေ့မှာ ပို့ပေးပြီးသား အစားထိုး drive တစ်ခုကို မြန်မြန်ရှာတွေ့နိုင်ခဲ့ပြီး ပြန်လည်တည်ဆောက်မှုကို စတင်နိုင်ခဲ့ပါတယ်။

file server ကို စစချင်း setup လုပ်တုန်းက ကျွန်တော် ဈေးပေါလွန်းတယ်လို့ ဝန်ခံပါတယ်။ drive နှစ်ခုပဲ NAS drive တွေ (Seagate IronWolf) ဖြစ်ပြီး ကျန်တာတွေက desktop drive တွေ (Seagate Barracuda) ဖြစ်ပါတယ်။ အံ့သြစရာတော့ မဟုတ်ပါဘူး၊ desktop drive တွေထဲက တစ်ခုပါ (ဒါပေမယ့် သုံးနှစ်နီးပါး အသုံးပြုပြီးနောက်မှာ)။ လုံးဝ အလုပ်မလုပ်တော့ပါဘူး။ desktop USB enclosure ကို ရွှေ့လိုက်တဲ့အခါ စိတ်အနှောင့်အယှက်ဖြစ်စရာ clicking အသံတွေပဲ ကြားရပြီး Ubuntu 20.04 နဲ့ Windows 10 နှစ်ခုလုံးက မသိရှိနိုင်ခဲ့ပါဘူး။

ကဲ၊ အစားထိုးပစ္စည်းအကြောင်း ဆက်ကြရအောင် (ဟုတ်တယ်၊ ကျွန်တော်ဝယ်လိုက်တဲ့ drive အသစ်က IronWolf ပါ၊ သင်ခန်းစာယူစရာပါ) - လည်ပတ်နေတဲ့ array ထဲမှာ drive ပျောက်သွားတာ ကြောက်စရာကောင်းသလောက်၊ အစားထိုးဖို့ မှန်ကန်တဲ့ လုပ်ထုံးလုပ်နည်းကို မသိရင် ပိုကြောက်စရာကောင်းပါတယ်။ mdadm array မှာ ပျက်နေတဲ့ drive ကို အစားထိုးရတာ ပထမဆုံးအကြိမ် မဟုတ်ပေမယ့်၊ ကံကောင်းထောက်မစွာပဲ၊ အဲဒါက အရမ်းရှားပါးတာကြောင့် သင့်တော်တဲ့ command တွေကို ရှာဖွေရပါတယ်။ ဒီတစ်ခါတော့ နောင်မှာ ကိုးကားဖို့အတွက် ကျွန်တော့်ရဲ့ ကိုယ်ပိုင်လမ်းညွှန်လေးကို ပြုစုဖို့ ဆုံးဖြတ်လိုက်ပါတယ်။

ဒါကြောင့် ပထမဆုံး mdadm ဆီက ကြောက်စရာကောင်းတဲ့ fail event အီးမေးလ်ကို ရတဲ့အခါ ဘယ် drive ချို့ယွင်းသွားလဲဆိုတာ သိဖို့လိုပါတယ်။ ဟုတ်ပါတယ်၊ device name ကို ပြောပြပါလိမ့်မယ် (ကျွန်တော့်ကိစ္စမှာ /dev/sdf)၊ ဒါပေမယ့် စက်ကို boot လုပ်တဲ့အခါ အဲဒီနာမည်တွေ ပြောင်းလဲသွားနိုင်တဲ့အတွက် အဲဒီ physical drive က ဘယ် drive လဲဆိုတာ ရှင်းရှင်းလင်းလင်း မသိနိုင်ပါဘူး။

ဘယ် device name က fail ဖြစ်နေလဲဆိုတာတောင် သေချာမသိရင် အောက်ပါ command ကိုသုံးပြီး ရှာဖွေနိုင်ပါတယ် (/dev/md0 ကို သင့်ရဲ့ RAID device နဲ့ အစားထိုးပါ)။

ဖော်ပြခဲ့သည့်အတိုင်း၊ ကျွန်တော့်ကိစ္စမှာ /dev/sdf ဖြစ်တဲ့အတွက် အဲဒါနဲ့ ဆက်သွားရအောင်။

ထို့နောက် အောက်ပါ command ကို ရိုက်ထည့်ခြင်းဖြင့် ချို့ယွင်းနေသော drive ၏ serial number ကို ရှာဖွေရန် ကြိုးစားနိုင်ပါသည်။

(smartctl ကို မတွေ့ပါက Ubuntu တွင် smartmontools package ကို ထည့်သွင်းရန် လိုအပ်ပါသည်)

ဘယ်ဟာ ချို့ယွင်းနေလဲဆိုတာ သိရဖို့ serial number ကို drive တွေပေါ်က physical label ပေါ်က serial number တွေနဲ့ နှိုင်းယှဉ်ကြည့်နိုင်ပါတယ်။

ဒီတစ်ခါတော့ ကျွန်တော်ကံမကောင်းခဲ့ပါဘူး။ drive က လုံးဝအလုပ်မလုပ်တော့ဘဲ SMART ဒါမှမဟုတ် serial number အပါအဝင် တခြားဒေတာတွေကိုတောင် မပေးခဲ့ပါဘူး။

ကျွန်တော်မှာ server ကို physical access ရထားပြီး (physical drive ကို ကိုယ်တိုင်အစားထိုးမယ်ဆိုရင် တကယ်လိုအပ်မယ်ထင်တယ် ;-)) disk ပျက်သွားတဲ့အချိန်မှာ server က တကယ်အလုပ်လုပ်နေတာကြောင့် (RAID-6 redundancy ကြောင့် ကောင်းကောင်းအလုပ်လုပ်နေတာ)၊ ကျွန်တော်ကတော့ အရမ်းရိုးရှင်းပေမယ့် အရမ်းထိရောက်ပြီး ထင်ရှားတဲ့ နည်းလမ်းဖြစ်တဲ့ ဖိုင်ကြီးတစ်ခုကို server ပေါ်ကူးယူပြီး ဘယ် HDD မီးမှိတ်တုတ်မှိတ်တုတ်မလင်းတာကို စောင့်ကြည့်တဲ့ နည်းလမ်းကို ရွေးချယ်ခဲ့ပါတယ်။ စက္ကန့်အနည်းငယ်အတွင်းမှာပဲ အကြောင်းရင်းကို ကျွန်တော် ဖော်ထုတ်နိုင်ခဲ့ပါတယ်။

ယခု၊ ရုပ်ပိုင်းဆိုင်ရာ drive ကို မဖယ်ရှားမီ၊ ဤ command ကို ထုတ်ပြန်ခြင်းဖြင့် mdadm အား ဤရည်ရွယ်ချက်ကို တရားဝင်အသိပေးသင့်သည် (သင့်လျော်သလို device အမည်များကို သင့်ကိုယ်ပိုင်အမည်ဖြင့် အစားထိုးပါ)။

အောင်မြင်ပါက mdadm သည် drive ကို "hot removed" လုပ်လိုက်ပြီဖြစ်ကြောင်း မက်ဆေ့ချ်ဖြင့် ပြန်ကြားပါမည်၊ အဘယ်ကြောင့်ဆိုသော် virtual raid device သည် ထိုအချိန်တွင် အမှန်တကယ် လည်ပတ်နေသောကြောင့်ဖြစ်သည်။

device or resource busy" ကဲ့သို့သော error message ဖြင့် fail ဖြစ်ပါက mdadm သည် drive ကို လုံးဝ fail ဖြစ်အောင် register မလုပ်ထားခြင်း ဖြစ်နိုင်သည်။ ထိုသို့ပြုလုပ်ရန် အောက်ပါ command ကို ရိုက်ထည့်ပါ (ထပ်ပြောပါရစေ၊ သင့်လျော်သလို သင့်ကိုယ်ပိုင် device name များဖြင့် အစားထိုးရန် မမေ့ပါနှင့်):

ထို့နောက်၊ ယခင် command ဖြင့် array မှ device ကို ဖယ်ရှားနိုင်ရပါမည်။

အခု drive ကို တကယ်အစားထိုးရမယ့်အချိန်ရောက်ပါပြီ။ သင့်စက်နဲ့ controller က hot swapping ကို support လုပ်တယ်ဆိုတာ တကယ်သေချာရင် စက်ကို မပိတ်ဘဲ လုပ်နိုင်ပါတယ်။ အဲဒါက အစစ်အမှန် server hardware ပေါ်မှာ run နေတဲ့ အရေးကြီးတဲ့ production system တွေကို ကိုင်တွယ်ဖြေရှင်းနိုင်တဲ့ နည်းလမ်းပါပဲ။ ကျွန်တော့်အိမ်က file server က consumer grade desktop motherboard ကို အခြေခံထားပြီး PCIe slot တွေမှာ semi-noname SATA controller နှစ်ခုနဲ့ SATA port တွေ ပိုထည့်ပေးပါတယ်။

SATA က ယေဘုယျအားဖြင့် hot swapping ကို ပံ့ပိုးပေးသင့်ပေမယ့် ဒီ setup မှာ ဘာအန္တရာယ်မှ မဖြစ်စေချင်ဘူး၊ ဒါကြောင့် drive ကို အစားထိုးနေချိန်မှာ စက်ကို ပိတ်ဖို့ ရွေးချယ်ခဲ့တယ်။

အဲဒီလိုမလုပ်ခင်မှာ /etc/fstab ဖိုင်ထဲမှာ raid device ကို comment out လုပ်ထားဖို့ကောင်းပါတယ်။ ဒါမှ Ubuntu က နောက်တစ်ကြိမ် boot လုပ်တဲ့အခါ auto mount မလုပ်နိုင်မှာမို့လို့ပါ။ ဘာလို့လဲဆိုတော့ RAID array ပျက်စီးသွားလို့ recovery mode ထဲ ရောက်သွားမှာမို့လို့ပါ။ desktop system ဆိုရင်တော့ အဲဒါက ပြဿနာကြီးကြီးမားမား မဟုတ်ပေမယ့် ကျွန်တော်ကတော့ ဒီ server ကို headless နဲ့ monitor ဒါမှမဟုတ် keyboard မတပ်ဘဲ run ပါတယ်။ ဒါကြောင့် နည်းနည်းတော့ ခက်ပါလိမ့်မယ်။

အသစ်စက်စက် drive ကို install လုပ်ပြီးနောက် စက်ကို boot လုပ်ပြီးနောက် lsblk သို့မဟုတ် အခြားနည်းလမ်းများကို အသုံးပြု၍ ၎င်းကို ခွဲခြားသိရှိနိုင်ပါသည်။ အခြားမည်သည့်အရာကိုမျှ မပြောင်းလဲပါက သင်အစားထိုးလိုက်သော drive နှင့် အမည်တူနေဖွယ်ရှိသည် (သို့သော် မဖြစ်မနေပြောင်းလဲရန် မလိုအပ်ပါ)။ ကျွန်တော့်ကိစ္စမှာတော့ ပြောင်းလဲသွားတာကြောင့် အသစ်စက်စက်ကို /dev/sdf လို့လည်း ခေါ်ပါတယ်။

ကျွန်တော့်ရဲ့ array က physical devices တွေထက် partitions တွေကို အခြေခံထားတဲ့အတွက် partition table ကို အလုပ်လုပ်နေတဲ့ drive ကနေ drive အသစ်ကို ကူးယူဖို့ လိုအပ်ပါတယ်။ ဒါမှသာ အားလုံး တစ်ထပ်တည်းကျမှာ သေချာပါတယ်။ array ကို physical devices တွေမှာ run မယ်ဆိုရင် ဒီအဆင့်ကို ကျော်သွားလို့ရပါတယ်။

ဒီအတွက် sgdisk ကိုသုံးခဲ့ပြီး partition table ကို /dev/sdc ကနေ /dev/sdf ကို ကူးယူခဲ့ပါတယ်။ သင့်တော်သလို သင့်ရဲ့ device name တွေနဲ့ ကိုက်ညီအောင် အစားထိုးဖို့ သေချာလုပ်ပါ။

ဒီမှာ အစီအစဉ်အတိုင်း ကြည့်ပါ- "to" drive ကို အရင်စာရင်းပြုစုပါ။ ကျွန်တော့်အတွက်တော့ နည်းနည်းတော့ ဆန့်ကျင်ဘက်ပါပဲ။ ဒါပေမယ့် array မှာ drive failure နောက်တစ်ခါ မဖြစ်အောင် မှန်ကန်စွာ လုပ်ဆောင်ဖို့ သေချာအောင်လုပ်ပါ။ ;-)

ထို့နောက် UUID ပဋိပက္ခများကို ရှောင်ရှားရန်အတွက် drive အသစ်အတွက် UUID အသစ်များကို generate လုပ်ပါ-

ပြီးတော့ အခု array ထဲကို drive အသစ်ထည့်ပြီး rebuild party စဖို့ အချိန်ရောက်ပါပြီ။ (အိုကေ၊ ပါတီပွဲတစ်ခုတော့ မဟုတ်ပါဘူး၊ တကယ်တော့ အတော်လေး နှေးကွေးပြီး စိတ်အနှောင့်အယှက်ဖြစ်စေတဲ့ လုပ်ငန်းစဉ်တစ်ခုပါ၊ ဘာလို့လဲဆိုတော့ ဒီအချိန်မှာ နောက်ထပ် drive တစ်ခု ချို့ယွင်းသွားမှာကို သင်တကယ် မလိုလားလို့ပါ။ ဘီယာက အထောက်အကူ ဖြစ်နိုင်ပေမယ့်)

ဘာပဲဖြစ်ဖြစ်၊ array ထဲကို drive အသစ်ထည့်ဖို့အတွက် ဒီ command ကို ထုတ်ပေးပါ (ထပ်ပြောပါရစေ၊ device name တွေကို သင့်တော်သလို ကိုယ်ပိုင်နာမည်နဲ့ အစားထိုးဖို့ သေချာအောင်လုပ်ပါ)။

အားလုံးအဆင်ပြေသွားရင် drive ကို array ထဲ အနှောင့်အယှက်မရှိဘဲ ထည့်သွားပါလိမ့်မယ်။ တကယ်တော့ default အနေနဲ့ "hot spare" အနေနဲ့ ထည့်ထားတယ်လို့ ကျွန်တော်ထင်ပါတယ်၊ ဒါပေမယ့် ဒီ array မှာ disk (ပျက်ကွက်သွားတဲ့ disk) မပါတဲ့အတွက် ချက်ချင်းအသုံးပြုပြီး rebuild လုပ်ငန်းစဉ်စတင်ပါလိမ့်မယ်။

သင်ဤကဲ့သို့ စောင့်ကြည့်နိုင်သည်-

ဒါက အချိန်အနည်းငယ်ကြာနိုင်ပါတယ်။ ကျွန်တော့်ရဲ့ နိမ့်ကျတဲ့ server မှာ (အဓိကအားဖြင့် စားသုံးသူအဆင့် hardware နဲ့ desktop drive တွေကို အခြေခံထားတာပါ) 100 MB/sec အောက်မှာပဲ ရောက်ခဲ့ပါတယ်။ ဒါက RAID-6 ဖြစ်တဲ့အတွက် rebuild လုပ်တဲ့အခါ parity calculation တွေ အများကြီးပါဝင်တယ်ဆိုတာ သတိရပါ။ RAID-10 က ပိုမြန်မှာပါ။ ဒီစက်မှာ AMD A10 9700E quad core CPU ("E" က စွမ်းအင်ချွေတာတဲ့ မော်ဒယ်လို့ ဆိုလိုပါတယ်၊ ဆိုလိုတာက အရမ်းမြန်တာမဟုတ်ပါဘူး) ပါရှိပါတယ်။ ဘာတွေမျှော်လင့်ရမလဲဆိုတာ အကြံဥာဏ်ပေးဖို့ပါ။ ကျွန်တော့်ရဲ့ setup မှာ 8 TB drive ကိုးခုနဲ့ အပြည့်အဝ rebuild လုပ်တာက ၂၄ နာရီကျော်ပဲ ကြာပါတယ်။

ပြန်လည်တည်ဆောက်နေစဉ်အတွင်း၊ filesystem ကို array ပေါ်တွင် mount လုပ်ပြီး သင်အလိုရှိပါက ပုံမှန်အတိုင်း အသုံးပြုနိုင်ပါသည်၊ သို့သော် ပြန်လည်တည်ဆောက်မှုပြီးသည်အထိ ၎င်းကိုထားခဲ့လိုပါသည်။ drive တစ်ခုချို့ယွင်းပါက နောက်တစ်ခုမကြာမီ လိုက်ပါလာနိုင်သည်ကို သတိပြုပါ၊ ထို့ကြောင့် ပြန်လည်တည်ဆောက်မှုကို အမြန်ဆုံးပြီးမြောက်စေလိုပါသည်၊ အဘယ်ကြောင့်ဆိုသော် ထိုအတောအတွင်း အခြား drive တစ်ခု ချို့ယွင်းသွားမည်ကို သင်အမှန်တကယ်မလိုလားသောကြောင့်ဖြစ်သည်။ ထို့ကြောင့် မလိုအပ်သော အခြား IO များဖြင့် ၎င်းကို ဝန်ထုပ်ဝန်ပိုးမဖြစ်စေပါနှင့်။

ပြီးသွားရင် /etc/fstab ဖိုင်ထဲ ပြန်ထည့်ပြီး reboot လုပ်ပြီး ဖိုင်တွေကို သုံးကြည့်ပါ :-)