Pendahuluan:

Saya kode-monyet yang semakin mengambil tugas SysAdmin untuk perusahaan kecil saya. Kode saya adalah produk kami, dan semakin kami menyediakan aplikasi yang sama dengan SaaS.

Sekitar 18 bulan yang lalu saya memindahkan server kami dari vendor sentris hosting premium ke rak barebone di pusat data tingkat IV. (Secara harfiah di seberang jalan.) Ini melakukan lebih banyak hal pada diri kita sendiri - hal-hal seperti jaringan, penyimpanan dan pemantauan.

Sebagai bagian dari langkah besar, untuk menggantikan penyimpanan terpasang langsung yang disewa dari perusahaan hosting, saya membangun NAS 9-simpul 9TB yang didasarkan pada SuperMicro chassises, kartu RAID 3ware, Ubuntu 10,04, dua lusin disk SATA, DRBD dan. Semuanya didokumentasikan dengan penuh cinta dalam tiga posting blog: Membangun & menguji baru 9TB SATA RAID10 NFSv4 NAS: Bagian I , Bagian II dan Bagian III .

Kami juga menyiapkan sistem pemantauan Cacit. Baru-baru ini kami telah menambahkan semakin banyak titik data, seperti nilai SMART.

Saya tidak bisa melakukan semua ini tanpa peti mati yang mengagumkan di ServerFault . Sudah pengalaman yang menyenangkan dan mendidik. Bos saya senang (kami menghemat banyak ember $$$) , pelanggan kami senang (biaya penyimpanan turun) , saya senang (bersenang-senang, bersenang-senang, bersenang-senang) .

Sampai kemarin.

Pemadaman & Pemulihan:

Beberapa waktu setelah makan siang, kami mulai mendapatkan laporan kinerja yang lamban dari aplikasi kami, sebuah CMS media streaming berdasarkan permintaan. Pada saat yang sama sistem pemantauan Cacti kami mengirim badai email. Salah satu peringatan yang lebih jitu adalah grafik iostat menunggu.

Performa menjadi sangat menurun sehingga Pingdom mulai mengirimkan notifikasi "server down". Keseluruhan bebannya moderat, tidak ada lonjakan lalu lintas.

Setelah masuk ke server aplikasi, klien NFS dari NAS, saya mengkonfirmasi bahwa hampir semuanya mengalami waktu tunggu IO yang sangat terputus-putus dan gila-gilaan. Dan begitu saya melompat ke node NAS primer itu sendiri, penundaan yang sama terbukti ketika mencoba menavigasi sistem file array masalah.

Waktu untuk gagal, itu berjalan dengan baik. Dalam 20 menit, semuanya dipastikan akan kembali dan berjalan dengan sempurna.

Post-Mortem:

Setelah semua dan semua kegagalan sistem saya melakukan post-mortem untuk menentukan penyebab kegagalan. Hal pertama yang saya lakukan adalah ssh kembali ke kotak dan mulai meninjau log. Itu offline, sepenuhnya. Waktu untuk perjalanan ke pusat data. Reset perangkat keras, membuat cadangan, dan menjalankan.

Dalam /var/syslogaku menemukan entri yang tampak menakutkan ini:

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

Jadi saya pergi untuk memeriksa grafik Cacti untuk disk dalam array. Di sini kita melihat bahwa, ya, disk 7 hilang begitu saja seperti yang dikatakan syslog. Tetapi kita juga melihat bahwa SMART 8 Baca Erros disk berfluktuasi.

Tidak ada pesan tentang disk 8 di syslog. Lebih menarik adalah bahwa nilai-nilai berfluktuasi untuk disk 8 langsung berkorelasi dengan waktu tunggu IO tinggi! Interpretasi saya adalah:

• Disk 8 mengalami kesalahan perangkat keras aneh yang menghasilkan waktu operasi lama intermiten.
• Entah bagaimana kondisi kesalahan ini pada disk mengunci seluruh array

Mungkin ada deskripsi yang lebih akurat atau benar, tetapi hasil akhirnya adalah bahwa satu disk memengaruhi kinerja seluruh array.

Pertanyaan-pertanyaan)

• Bagaimana satu disk dalam perangkat keras SATA RAID-10 array dapat membuat seluruh array berhenti melengking?
• Apakah saya naif untuk berpikir bahwa kartu RAID harus ditangani?
• Bagaimana saya bisa mencegah disk yang salah tingkah berdampak pada seluruh array?
• Apakah saya melewatkan sesuatu?

Saya benci mengatakan "jangan gunakan SATA" di lingkungan produksi kritis, tapi saya sudah sering melihat situasi ini. Drive SATA umumnya tidak dimaksudkan untuk siklus tugas yang Anda gambarkan, meskipun Anda melakukan drive spec yang diperingkat khusus untuk operasi 24x7 di pengaturan Anda. Pengalaman saya adalah bahwa drive SATA dapat gagal dengan cara yang tidak terduga, sering kali mempengaruhi seluruh array penyimpanan, bahkan ketika menggunakan RAID 1 + 0, seperti yang telah Anda lakukan. Kadang-kadang drive gagal dengan cara yang dapat menghentikan seluruh bus. Satu hal yang perlu diperhatikan adalah apakah Anda menggunakan ekspander SAS dalam pengaturan Anda. Itu dapat membuat perbedaan dalam bagaimana disk yang tersisa dipengaruhi oleh kegagalan drive.

Tetapi mungkin lebih masuk akal untuk menggunakan SAS drive midline / nearline (7200 RPM) versus SATA. Ada harga yang lebih murah dibandingkan SATA, tetapi drive akan beroperasi / gagal lebih dapat diprediksi. Koreksi-kesalahan dan pelaporan dalam antarmuka / protokol SAS lebih kuat dari pada SATA. Jadi, bahkan dengan drive yang mekanismenya sama , perbedaan protokol SAS mungkin telah mencegah rasa sakit yang Anda alami selama kegagalan drive Anda.

Bagaimana satu disk dapat menurunkan array? Jawabannya adalah tidak seharusnya, tetapi tergantung pada apa yang menyebabkan pemadaman. Jika disk itu mati dengan cara yang berperilaku, itu seharusnya tidak menghapusnya. Tapi itu mungkin gagal dalam "kasus tepi" cara yang tidak bisa ditangani oleh pengontrol.

Apakah Anda naif berpikir ini seharusnya tidak terjadi? Tidak, kurasa tidak. Kartu RAID perangkat keras seperti itu seharusnya menangani sebagian besar masalah.

Bagaimana cara mencegahnya? Anda tidak dapat mengantisipasi kasus tepi aneh seperti ini. Ini adalah bagian dari menjadi sysadmin ... tetapi Anda dapat mengerjakan prosedur pemulihan agar tidak memengaruhi bisnis Anda. Satu-satunya cara untuk mencoba memperbaikinya sekarang adalah dengan mencoba kartu perangkat keras lain (tidak mungkin apa yang ingin Anda lakukan) atau mengubah drive Anda menjadi drive SAS daripada SATA untuk melihat apakah SAS lebih kuat. Anda juga dapat menghubungi vendor kartu RAID Anda dan memberi tahu mereka apa yang telah terjadi dan melihat apa yang mereka katakan; mereka, bagaimanapun, adalah perusahaan yang seharusnya berspesialisasi dalam mengetahui seluk beluk elektronik drive yang miring. Mereka mungkin memiliki lebih banyak saran teknis tentang cara kerja drive dan juga keandalan ... jika Anda dapat menghubungi orang yang tepat untuk diajak bicara.

Apakah kamu melewatkan sesuatu? Jika Anda ingin memverifikasi bahwa drive mengalami kegagalan kasus tepi, tarik dari array. Array akan terdegradasi tetapi Anda seharusnya tidak memiliki lebih banyak perlambatan dan kesalahan aneh (selain dari status array terdegradasi). Anda mengatakan bahwa saat ini tampaknya berfungsi dengan baik, tetapi jika mengalami kesalahan pembacaan disk, Anda harus mengganti drive selagi bisa. Drive dengan kapasitas tinggi kadang-kadang dapat memiliki kesalahan URE (alasan terbaik untuk tidak menjalankan RAID 5, catatan samping) yang tidak muncul sampai drive lain gagal. Dan jika Anda mengalami perilaku tepi-kasus dari satu drive itu, Anda tidak ingin data yang rusak dimigrasi ke drive lain dalam array.

Saya bukan ahli, tapi saya akan mengambil gambar liar dalam kegelapan berdasarkan pengalaman saya dengan pengontrol RAID dan array penyimpanan.

Disk gagal dengan berbagai cara. Sayangnya, disk bisa gagal, atau salah, dengan cara di mana kinerjanya sangat terpengaruh tetapi pengontrol RAID tidak melihat sebagai kegagalan.

Jika disk gagal dengan cara yang jelas, setiap perangkat lunak pengontrol RAID harus cukup baik dalam mendeteksi kurangnya respons dari disk, menghapusnya dari kumpulan dan menembakkan pemberitahuan. Namun, dugaan saya tentang apa yang terjadi di sini adalah bahwa disk mengalami kegagalan yang tidak biasa yang, untuk beberapa alasan tidak memicu kegagalan pada sisi pengontrol. Oleh karena itu ketika controller sedang melakukan write flush atau read dari disk yang terpengaruh, butuh waktu lama untuk kembali dan pada gilirannya menggantung seluruh IO yang beroperasi dan oleh karena itu array. Untuk alasan apa pun, ini tidak cukup untuk pengontrol RAID untuk pergi "ah, gagal disk", mungkin karena data akhirnya kembali pada akhirnya.

Saran saya adalah segera mengganti disk yang gagal. Setelah itu, saya akan melihat konfigurasi untuk kartu RAID Anda (Ini 3ware, saya pikir mereka cukup bagus) dan mencari tahu apa yang dianggap sebagai disk gagal menjadi.

PS ide bagus mengimpor SMART ke dalam kaktus.

Anda memerlukan fitur perangkat penyimpanan kelas perusahaan. Secara khusus, drive perusahaan WD RE 4 memiliki dua fitur yang diperlukan untuk mencegah perilaku ini dalam RAID Array. Teknologi pertama yang tercantum di bawah ini mencegah getaran harmonik rotasi tidak menyebabkan keausan yang tidak perlu pada komponen mekanis hard drive. Teknologi kedua yang menyebabkan masalah Anda, protokol SATA tidak memiliki fitur ini. Untuk mendapatkan fitur-fitur ini, Anda memerlukan SAS, dan jika Anda bersikeras pada drive SATA Anda dapat membeli kartu SAS to SATA Interposer seperti LSISS9252.

Teknologi RAFF yang disempurnakan Elektronik canggih memantau drive dan memperbaiki getaran linear dan rotasi secara real time. Hasilnya adalah peningkatan kinerja yang signifikan di lingkungan getaran tinggi dibandingkan generasi drive sebelumnya.

Pemulihan kesalahan (TLER) khusus RAID, khusus waktu, mencegah kejatuhan drive yang disebabkan oleh proses pemulihan kesalahan hard drive yang umum terjadi pada drive desktop.

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

Lihat juga tautan di bawah ini:

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

Lihat juga: Western Digital TLER Document yang menjelaskan proses pemulihan kesalahan secara mendalam. Pencegahan Kesalahan Pemulihan Fallout di WD Caviar RAID Edition Serial ATA Hard Drive:

http://www.3dfxzone.it/public/files/2579-001098.pdf

Tebakan: hardisk dikonfigurasikan untuk mencoba kembali kesalahan baca daripada melaporkan kesalahan. Walaupun ini adalah perilaku yang diinginkan dalam pengaturan desktop, ini kontraproduktif dalam RAID (di mana controller harus menulis ulang setiap sektor yang gagal membaca dari disk lain, sehingga drive dapat memetakannya kembali).

tembakan saya dalam gelap:

• drive 7 gagal. ini memiliki beberapa jendela gagal yang tidak tersedia.

• drive 8 memiliki beberapa kesalahan 'lebih ringan' juga; dikoreksi dengan mencoba ulang.

• RAID10 biasanya "sebuah RAID0 dari beberapa pasangan RAID1", apakah drive 7 dan 8 anggota dari pasangan yang sama?

jika demikian, maka sepertinya Anda menekan kasus "tidak boleh terjadi" kegagalan dua disk pada pasangan yang sama. hampir satu-satunya hal yang dapat membunuh RAID10. Sayangnya, itu bisa terjadi jika semua drive Anda berasal dari tempat pengiriman yang sama, jadi mereka sedikit lebih mungkin mati secara bersamaan.

Saya kira bahwa selama kegagalan drive 7, pengontrol mengarahkan ulang semua bacaan ke drive 8, jadi setiap kesalahan-coba ulang menyebabkan penundaan besar yang menyebabkan longsoran tugas-tugas yang membeku, membunuh kinerja untuk sementara waktu.

Anda beruntung bahwa drive 8 tampaknya belum mati, jadi Anda harus dapat memperbaikinya tanpa dataloss.

Saya akan mulai dengan mengubah kedua drive, dan jangan lupa untuk memeriksa kabel. koneksi yang longgar dapat menyebabkan ini, dan jika tidak dirutekan dengan kuat, itu lebih mungkin terjadi pada drive yang berdekatan. juga, beberapa kartu multiport memiliki beberapa konektor dua port, jika drive 7 dan drive 8 berada pada yang sama, itu mungkin menjadi sumber masalah Anda.

Kartu SATA Interposer adalah solusi lain.

Saya baru-baru ini mengalami nasib yang sama persis dan menemukan utas ini. Keseluruhan tenor adalah bahwa protokol SAS lebih cocok untuk RAID daripada SATA, karena SATA kekurangan fitur. Inilah sebabnya mengapa drive fisik yang sama dilengkapi dengan pengontrol SAS, kemudian dijual sebagai Nearline SAS.

Mencari lebih jauh, saya menemukan:

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

Saya sedang menyelidiki untuk meningkatkan salah satu penyimpanan saya dengan sejumlah ini. Saat ini, perbedaan harga antara 3 TB SATA vs SAS adalah 400% (harga vanilla, merek yang sama, spesifikasi dan toko, Jerman). Saya jelas tidak tahu apakah strategi ini berhasil dengan baik, tetapi patut dicoba.

Komentar sangat menyambut :-)

Saya telah melihat disk SATA dengan elektronik yang rusak mengunci firmware init dari Areca 12 sesuatu yang solid, tidak ada cara untuk mengakses BIOS apalagi boot mesin dari media apa pun sampai hard drive yang menyinggung ditemukan dengan menarik disk keluar dalam biner mencari mode.