Skenario Kehilangan Data ZFS


27

Saya sedang mencari cara membangun Pool ZFS yang besar (150TB +), dan saya ingin mendengar pengalaman orang-orang tentang skenario kehilangan data karena perangkat keras yang gagal, khususnya, membedakan antara contoh-contoh di mana hanya beberapa data yang hilang vs. seluruh sistem file ( jika ada perbedaan di ZFS).

Sebagai contoh: katakanlah vdev hilang karena kegagalan seperti drive drive eksternal kehilangan daya, atau kartu controller gagal. Dari apa yang saya baca kolam harus masuk ke mode rusak, tetapi jika vdev dikembalikan kolam harus pulih? atau tidak? atau jika vdev rusak sebagian, apakah ada yang kehilangan seluruh kumpulan, beberapa file, dll?

Apa yang terjadi jika perangkat ZIL gagal? Atau hanya satu dari beberapa ZIL?

Benar-benar semua dan semua anekdot atau skenario hipotetis yang didukung oleh pengetahuan teknis yang dalam dihargai!

Terima kasih!

Memperbarui:

Kami melakukan ini dengan harga murah karena kami adalah bisnis kecil (sekitar 9 orang) tetapi kami menghasilkan data pencitraan yang cukup banyak.

Data sebagian besar file bertubuh kecil, dengan hitungan saya sekitar 500k file per TB.

Data itu penting tetapi tidak terlalu kritis. Kami berencana untuk menggunakan kumpulan ZFS untuk mencerminkan array data "langsung" 48TB (digunakan selama 3 tahun atau lebih), dan menggunakan sisa penyimpanan untuk data yang 'diarsipkan'.

Kolam akan dibagikan menggunakan NFS.

Rak seharusnya berada pada jalur generator cadangan gedung, dan kami memiliki dua UPS APC yang mampu memberi daya pada rak dengan beban penuh selama 5 menit atau lebih.


2
Jika Anda belum tahu apa yang Anda lakukan, dapatkan konsultan dan / atau dapatkan kursus. Saya ragu semua spesifik yang Anda butuhkan dapat dicakup dalam satu jawaban sederhana.
Lucas Kauffman

3
Jadi, Anda masih berencana menggunakan konsumen yang lebih murah, 7.2 SATA? desah
Chopper3

@ Chopper3 Sebenarnya, saya sengaja tidak mengatakan itu ... Saya memberikan pertimbangan serius untuk membeli drive SAS 2TB, bukannya drive SATA 3TB. Meskipun saya telah melihat banyak orang mengatakan mereka telah menggunakan drive SATA baik-baik saja ....
Siklon

1
Disk SATA untuk ZFS sebenarnya bukan campuran yang bagus. Anda tidak akan menemukan banyak orang merekomendasikan pengaturan itu saat ini. Pada skala yang Anda bicarakan (150TB), ini adalah kesalahan yang mahal dan tidak perlu. Lihatlah ini, meskipun .
ewwhite

Jawaban:


22

Rancang cara yang benar dan Anda akan meminimalkan kemungkinan hilangnya data ZFS. Anda belum menjelaskan apa yang Anda simpan di kolam renang. Dalam aplikasi saya, sebagian besar melayani VMWare VMDK dan mengekspor zvol melalui iSCSI. 150TB bukan jumlah yang sepele, jadi saya akan mengandalkan seorang profesional untuk penskalaan saran.

Saya tidak pernah kehilangan data dengan ZFS.

Saya telah mengalami segalanya:

Tetapi melalui semua itu, tidak pernah ada kehilangan data yang berarti. Hanya downtime. Untuk VMWare, VMDK berada di atas penyimpanan ini, fsck atau reboot sering diperlukan setelah suatu peristiwa, tetapi tidak lebih buruk dari server crash lainnya.

Adapun kehilangan perangkat ZIL, itu tergantung pada desain, apa yang Anda simpan dan pola I / O dan tulis Anda. Perangkat ZIL yang saya gunakan relatif kecil (4GB-8GB) dan berfungsi seperti cache tulis. Beberapa orang mencerminkan perangkat ZIL mereka. Menggunakan perangkat STEC SSD kelas atas membuat mirroring menjadi penghalang biaya. Saya menggunakan kartu PCIe DDRDrive tunggal sebagai gantinya. Rencanakan perlindungan baterai / UPS dan gunakan kartu SSD atau PCIe dengan cadangan super-kapasitor (mirip dengan pengontrol RAID, implementasi BBWC dan FBWC ).

Sebagian besar pengalaman saya ada di sisi Solaris / OpenSolaris dan NexentaStor . Saya tahu orang-orang menggunakan ZFS di FreeBSD, tapi saya tidak yakin seberapa jauh di belakang versi zpool dan fitur lainnya. Untuk penyebaran penyimpanan murni, saya akan merekomendasikan pergi rute Nexentastor (dan berbicara dengan mitra yang berpengalaman ), karena ini adalah OS yang dibangun khusus dan ada lebih banyak penyebaran kritis yang berjalan pada turunan Solaris daripada FreeBSD.


Saya memperbarui pertanyaan saya dengan beberapa info lebih lanjut, tetapi saya sangat tertarik mengetahui lebih banyak perincian mengenai: 'tidak pernah ada kehilangan data yang berarti', dan apa artinya itu / melibatkan. Juga tertarik untuk mengetahui lebih lanjut tentang memulihkan zpool yang rusak, menangani NIC yang buruk, dan bahkan masalah dengan drive SATA dan beralih ke SAS (meskipun Anda akan senang mengetahui, saya mungkin akan menggunakan SAS 2TB lebih dari 3TB SATA , atas rekomendasi Anda).
Topan

Non-lumayan-rugi == beberapa detik data transaksional, atau keadaan konsisten-crash . Dan NIC yang buruk diisolasi ke satu host VMWare dan menghasilkan masalah di tingkat VM. Bukan penyimpanan ZFS yang mendasarinya.
ewwhite

The design the right waylink rusak sekarang.
Saurabh Nanda

11

Saya tidak sengaja menimpa kedua ZIL pada versi terakhir OpenSolaris, yang menyebabkan seluruh kumpulan hilang secara permanen. (Kesalahan yang sangat buruk di pihak saya! Saya tidak mengerti bahwa kehilangan ZIL berarti kehilangan kolam. Untungnya pulih dari cadangan dengan downtime.)

Karena versi 151a (tidak tahu apa artinya versi ZPool), masalah ini telah diperbaiki. Dan, saya bisa bersaksi bahwa itu berhasil.

Selain itu, saya kehilangan data NOL pada server 20tb - termasuk karena beberapa kasus kesalahan pengguna lebih lanjut, banyak kegagalan daya, manajemen kesalahan disk, kesalahan konfigurasi, banyak disk gagal, dll. Meskipun manajemen dan antarmuka konfigurasi pada Solaris sering berubah dan menjengkelkan dari versi ke versi dan menyajikan target keterampilan yang selalu berubah, itu masih merupakan pilihan terbaik untuk ZFS.

Tidak hanya saya tidak kehilangan data pada ZFS (setelah kesalahan mengerikan saya), tetapi itu selalu melindungi saya. Saya tidak lagi mengalami kerusakan data - yang telah mengganggu saya selama 20 tahun terakhir di sejumlah server dan workstation, dengan apa yang saya lakukan. Diam (atau hanya "cukup tenang") korupsi data telah membunuh saya beberapa kali, ketika data bergulir dari rotasi cadangan, tetapi sebenarnya telah menjadi rusak pada disk. Atau skenario lain di mana cadangan mendukung versi yang korup. Ini telah menjadi masalah yang jauh lebih besar daripada hanya kehilangan data dengan cara besar sekaligus, yang hampir selalu didukung. Untuk alasan ini, saya suka ZFS dan tidak bisa memahami mengapa checksumming dan penyembuhan otomatis belum menjadi fitur standar dalam sistem file selama satu dekade. (Memang, sistem yang benar-benar hidup atau mati biasanya memiliki cara lain untuk memastikan integritas,

Kata bijak, jika Anda tidak ingin turun ke ACL-neraka, jangan gunakan server CIFS bawaan untuk ZFS. Gunakan Samba. (Kamu bilang kamu menggunakan NFS.)

Saya tidak setuju dengan argumen SAS vs SATA, setidaknya saran bahwa SAS selalu lebih disukai daripada SATA, untuk ZFS. Saya tidak tahu apakah komentar itu merujuk pada kecepatan putaran platter, dugaan keandalan, kecepatan antarmuka, atau atribut lainnya. (Atau mungkin hanya "harganya lebih mahal dan umumnya tidak digunakan oleh konsumen, oleh karena itu mereka lebih unggul". Sebuah survei industri yang baru-baru ini dirilis (masih dalam berita saya yakin), mengungkapkan bahwa SATA sebenarnya hidup lebih lama dari SAS rata-rata, setidaknya dengan ukuran sampel yang signifikan dari survei. (Terkejut saya itu pasti.) Saya tidak dapat mengingat apakah itu adalah versi "perusahaan" dari SATA, atau konsumen, atau kecepatan apa - tetapi dalam pengalaman saya yang besar, model perusahaan dan konsumen gagal pada saat yang sama tingkat signifikan secara statistik. (Ada masalah drive konsumen membutuhkan waktu terlalu lama untuk gagal, yang jelas penting di perusahaan - tetapi itu belum menggigit saya, dan saya pikir itu lebih relevan untuk pengontrol perangkat keras yang dapat mengambil keseluruhan volume off-line dalam kasus seperti itu. Tapi itu bukan masalah SAS vs SATA, dan ZFS tidak pernah mengecewakan saya. Sebagai hasil dari pengalaman itu, saya sekarang menggunakan campuran 1/3 perusahaan dan 2/3 drive SATA konsumen .) Terlebih lagi saya telah melihat tidak ada kinerja yang signifikan dengan campuran SATA ini, ketika dikonfigurasi dengan benar (misalnya strip tiga arah mirror), tapi sekali lagi saya memiliki permintaan IOPS yang rendah, jadi tergantung pada seberapa besar toko Anda dan kasus penggunaan yang khas, YMMV. Saya benar-benar memperhatikan bahwa ukuran cache bawaan per-disk lebih penting untuk masalah latensi daripada kecepatan rotasi platter, dalam kasus penggunaan saya.

Dengan kata lain, ini adalah amplop dengan beberapa parameter: biaya, throughput, IOPS, jenis data, jumlah pengguna, bandwidth administratif, dan kasus penggunaan umum. Mengatakan bahwa SAS selalu merupakan solusi yang tepat adalah dengan mengabaikan permutasi yang besar dari faktor-faktor tersebut.

Tapi bagaimanapun juga, ZFS benar-benar mengguncang.


3
Terima kasih telah meluangkan waktu untuk merespons. Pengalaman Anda dengan ZFS konsisten dengan pengalaman saya. Komentar saya tentang pemilihan drive secara khusus tentang nearline SAS versus disk SATA. Perbedaan utama adalah antarmuka. Mereka setara secara mekanis. Praktik terbaik di ZFS-land sekarang adalah untuk menghindari SATA karena kebutuhan untuk antarmuka dual-porting, koreksi kesalahan yang lebih baik dan batas waktu yang dapat diatur yang ditawarkan oleh SAS.
ewwhite

Saya akhirnya menggunakan disk SAS 3TB tapi .... sebelum melakukannya, saya membuat 30 atau lebih disk campuran (5 400GB SATA, 12 750GB SATS, 14 1TB SAS) yang saya masukkan ke dalam selubung SAS yang diperluas yang sama. Benar-benar skenario kasus terburuk menurut. Drive ini juga sudah ~ 2-3 tahun runtime. Saya kemudian menulis sebuah program yang menjalankan 8 utas secara acak membaca tulisan dan menghapus file ke kolam. Saya menjalankannya selama lebih dari seminggu. Baca dan tulis> 100 TB ke kolam ... tidak ada masalah. AVG R / W 100-400MB / detik. Saya menduga peringatan SATA over SAS mungkin berita lama sekarang.
Topan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.