Mengganti Drive yang Gagal dalam Array mdadm di Ubuntu

Informasi dalam posting ini berdasarkan Ubuntu 18.04 dan versi mdadm yang disertakan dalam repositorinya; pada saat artikel ini ditulis v4.1-rc1. Mungkin berlaku atau tidak untuk versi lain.

Baru-baru ini saya mengalami kegagalan drive secara tiba-tiba di server file rumah saya, yang terdiri dari sembilan drive dalam array RAID-6 mdadm. Itu selalu menakutkan, tetapi untungnya saya dapat dengan cepat mendapatkan drive pengganti yang sudah dikirim keesokan harinya sehingga saya dapat memulai pembangunan kembali.

Saya akui saya agak terlalu pelit saat pertama kali menyiapkan server file; hanya dua dari drive tersebut yang merupakan drive NAS (Seagate IronWolf), sedangkan sisanya adalah drive desktop (Seagate Barracuda). Tidak mengherankan, itu adalah salah satu drive desktop yang sudah tidak berfungsi (meskipun setelah hampir tiga tahun digunakan). Drive itu benar-benar mati; setelah memindahkannya ke wadah USB desktop, yang saya dapatkan hanyalah bunyi klik yang mengganggu dan baik Ubuntu 20.04 maupun Windows 10 tidak dapat mendeteksinya.

Baiklah, lanjut ke bagian pengganti (dan ya, drive baru yang saya beli adalah IronWolf, pelajaran yang dipetik) - meskipun kehilangan drive dalam array yang sedang berjalan itu menakutkan, akan lebih menakutkan lagi jika Anda tidak mengetahui prosedur yang benar untuk menggantinya. Ini bukan pertama kalinya saya harus mengganti drive yang rusak dalam array mdadm, tetapi untungnya hal itu sangat jarang terjadi sehingga saya biasanya harus mencari perintah yang tepat. Kali ini saya memutuskan untuk membuat panduan kecil saya sendiri untuk referensi di masa mendatang.

Jadi, pertama-tama, saat Anda menerima email kejadian gagal yang ditakutkan dari mdadm, Anda perlu mengidentifikasi drive mana yang gagal. Tentu, email tersebut akan memberi tahu Anda nama perangkat (dalam kasus saya /dev/sdf), tetapi mungkin tidak jelas drive fisik mana yang sebenarnya karena nama-nama tersebut dapat berubah saat komputer di-boot.

Jika Anda tidak yakin nama perangkat mana yang gagal, Anda dapat menggunakan perintah berikut untuk mengetahuinya (ganti /dev/md0 dengan perangkat RAID Anda):

Seperti disebutkan, dalam kasus saya adalah /dev/sdf, jadi mari kita lanjutkan dengan itu.

Kemudian, Anda dapat mencoba mencari nomor seri drive yang gagal dengan mengeluarkan perintah ini:

(jika smartctl tidak ditemukan, Anda perlu menginstal paket smartmontools di Ubuntu)

Nomor seri kemudian dapat dibandingkan dengan nomor seri pada label fisik di drive untuk mengetahui drive mana yang gagal.

Namun kali ini, saya tidak seberuntung itu. Drive tersebut benar-benar mati dan bahkan menolak untuk memberikan SMART atau data lainnya, termasuk nomor seri.

Karena saya memiliki akses fisik ke server (yang sangat Anda perlukan jika Anda akan mengganti drive fisik sendiri, saya kira ;-)) dan server benar-benar berjalan saat disk gagal (dan terus berjalan dengan baik berkat redundansi RAID-6), saya menggunakan metode yang sangat primitif, tetapi sebenarnya sangat efektif dan jelas, yaitu dengan menyalin file besar ke server dan melihat lampu HDD mana yang tidak berkedip. Dalam beberapa detik saya telah mengidentifikasi penyebabnya.

Sekarang, sebelum mencabut drive fisik, ada baiknya Anda memberi tahu mdadm secara formal tentang maksud ini, dengan mengeluarkan perintah ini (ganti nama perangkat dengan nama Anda sendiri jika perlu):

Jika berhasil, mdadm akan membalas dengan pesan yang menyatakan bahwa drive tersebut telah "dihapus saat dalam keadaan panas", tampaknya karena perangkat raid virtual sebenarnya sedang berjalan pada saat itu.

Jika gagal dengan pesan kesalahan yang mirip dengan "perangkat atau sumber daya sibuk", mungkin mdadm sebenarnya tidak mendaftarkan drive tersebut untuk mengalami kegagalan total. Untuk melakukannya, jalankan perintah ini (sekali lagi, ingatlah untuk mengganti nama perangkat dengan nama Anda sendiri sebagaimana mestinya):

Setelah itu, Anda seharusnya dapat menghapus perangkat dari array dengan perintah sebelumnya.

Sekarang saatnya mengganti drive. Jika Anda benar- benar yakin mesin dan kontroler Anda mendukung hot swapping, Anda dapat melakukannya tanpa mematikan mesin. Itulah cara yang tepat untuk sistem produksi penting yang berjalan pada perangkat keras server yang sebenarnya dan tepat yang Anda tahu pasti dapat menanganinya. Namun, server file rumah saya berbasis pada motherboard desktop kelas konsumen dengan beberapa kontroler SATA semi-noname di slot PCIe untuk menyediakan lebih banyak port SATA.

Meskipun SATA secara umum mendukung hot swapping, saya tidak mau mengambil risiko apa pun dalam pengaturan ini, jadi saya memilih untuk mematikan mesin saat mengganti drive.

Sebelum melakukannya, ada baiknya untuk mengomentari perangkat raid di berkas /etc/fstab sehingga Ubuntu tidak akan mencoba memasangnya secara otomatis pada boot berikutnya, karena perangkat mungkin akan hang dan memaksa Anda masuk ke mode pemulihan karena susunan RAID yang rusak. Itu mungkin bukan masalah besar jika menggunakan sistem desktop, tetapi saya menjalankan server ini tanpa monitor atau keyboard yang terpasang, jadi ini akan sedikit merepotkan.

Setelah mem-boot komputer dengan drive baru yang terpasang, gunakan lsblk atau cara lain untuk mengidentifikasinya. Jika Anda belum mengubah apa pun, drive tersebut mungkin (tetapi tidak harus ) akan mendapatkan nama yang sama dengan drive yang Anda ganti. Dalam kasus saya, drive tersebut mendapatkan nama yang sama, jadi drive yang baru juga disebut /dev/sdf.

Karena array saya berbasis partisi, bukan perangkat fisik, saya perlu menyalin tabel partisi dari drive yang berfungsi ke drive baru untuk memastikan keduanya sama persis. Jika Anda menjalankan array pada perangkat fisik, Anda dapat melewati langkah ini.

Saya menggunakan sgdisk untuk tujuan ini, menyalin tabel partisi dari /dev/sdc ke /dev/sdf. Pastikan untuk mengganti nama perangkat agar sesuai dengan nama Anda sendiri.

Perhatikan urutannya di sini: Anda mencantumkan drive "to" terlebih dahulu! Ini agak berlawanan dengan intuisi saya, tetapi pastikan Anda melakukannya dengan benar agar tidak terjadi kegagalan drive lain dalam array ;-)

Kemudian untuk menghindari konflik UUID, buat UUID baru untuk drive baru:

Dan sekarang akhirnya tiba saatnya untuk menambahkan drive baru ke array dan memulai pesta pembangunan kembali! (Oke, ini bukan benar-benar pesta, ini sebenarnya proses yang cukup lambat dan menegangkan karena Anda benar-benar tidak ingin drive lain gagal saat ini. Namun, bir mungkin bisa membantu)

Bagaimanapun, untuk menambahkan drive baru ke array, jalankan perintah ini (sekali lagi, pastikan untuk mengganti nama perangkat dengan nama Anda sendiri sebagaimana mestinya):

Jika semuanya berjalan lancar, drive akan ditambahkan ke array tanpa hambatan. Saya yakin drive tersebut sebenarnya ditambahkan sebagai "hot spare" secara default, tetapi karena array ini tidak memiliki disk (yang rusak), drive tersebut akan segera digunakan dan proses pembangunan ulang akan dimulai.

Anda dapat mengawasinya seperti ini:

Ini mungkin akan memakan waktu cukup lama; pada server saya yang sederhana (yang sebagian besar berbasis pada perangkat keras kelas konsumen dan drive desktop, perlu diingat) kecepatannya dapat mencapai kurang dari 100 MB/detik. Perlu diingat bahwa ini adalah RAID-6, jadi ada banyak kalkulasi paritas yang terlibat dalam pembangunan ulang; RAID-10 akan jauh lebih cepat. Mesin khusus ini memiliki CPU quad core AMD A10 9700E (huruf "E" berarti model hemat energi dengan clock rendah, yaitu tidak terlalu cepat), hanya untuk memberi Anda gambaran tentang apa yang diharapkan. Dengan sembilan drive 8 TB dalam pengaturan saya, pembangunan ulang penuh memakan waktu lebih dari 24 jam.

Selama proses membangun ulang, Anda dapat memasang sistem berkas pada array dan menggunakannya seperti biasa jika Anda mau, tetapi saya lebih suka membiarkannya hingga proses membangun ulang selesai. Ingatlah bahwa jika satu drive gagal, drive lain mungkin akan segera menyusul, jadi Anda ingin proses membangun ulang dilakukan secepat mungkin karena Anda benar-benar tidak ingin drive lain gagal selama proses tersebut. Oleh karena itu, jangan membebaninya dengan IO lain yang tidak terlalu diperlukan.

Setelah selesai, tambahkan kembali ke file /etc/fstab Anda, reboot dan nikmati file Anda :-)