Tingkatkan keandalan dengan mempartisi disk dengan ukuran berbeda?


8

Saya mengerti ZFS akan lebih suka semua disk dengan ukuran yang sama. Namun, dalam hal saya memiliki dua disk dengan ukuran yang berbeda (1TB dan 1.5TB), saya ingin memiliki redundansi tertentu, tetapi tidak mirroring. Jadi saya memotong dua disk menjadi 5 partisi, dengan masing-masing partisi sekitar 500GB dan membuat kumpulan "raidz" ... zfs dengan senang hati berkewajiban. Apakah pengaturan benar-benar meningkatkan keandalan? Pikirannya adalah jika disk tidak rusak total, dan hanya sebagian yang gagal, saya masih dapat mengakses data?


5
Ini tidak menambah keandalan dan menurunkan kinerja.
Michael Hampton

1
Sebagian besar jawaban / komentar yang saya terima, tidak masuk cukup dalam untuk alasan mengapa. Sederhana "melawan praktik terbaik" atau "disk yang sama masuk akal" sebenarnya tidak banyak berarti bagi saya. Jelas, mengingat disk aneh yang saya miliki ini, saya tidak akan mencari yang terbaik dari yang terbaik dalam hal keandalan dan kinerja. Saya bertanya apa yang bisa dilakukan mengingat apa yang saya miliki. Juga, banyak hal berubah: dalam buku "Master FreeBSD ZFS" ... penulis dengan jelas mengatakan di masa lalu / solaris, penyediaan disk secara keseluruhan dianggap penting, sekarang tidak. Provisi berbasis partisi sama baiknya atau bahkan dianjurkan.
python152

Khusus untuk redundansi berbasis paritas, tidak ada persyaratan mutlak pada ukuran yang sama (samar-samar saya ingat buku zfs juga mengatakan drive kapasitas yang sama dari vendor yang berbeda berakhir dengan ukuran yang berbeda). Terserah bagaimana algoritma penempatan data ZFS memilih untuk mengatasinya untuk menyeimbangkan penyebaran bit paritas dan menyeimbangkan kinerja.
python152

@ python152 Selalu tergantung pada apakah Anda dapat hidup dengan kerugian (ZFS benar-benar sangat fleksibel, praktik terbaik adalah rekomendasi, bukan aturan). Misalnya, jika Anda dapat menerima waktu henti dan percaya diri dalam manajemen partisi, mengganti disk yang rusak sebagian tidak sepenting itu. Saya masih akan waspada terhadap lubang penulisan RAID5, yang ada terlepas dari apakah perangkat keras pendukung Anda adalah disk, partisi atau bahkan file.
user121391

1
@ user121391 ZFS raidz tidak menderita dari lubang penulisan RAID5. Lihat blogs.oracle.com/bonwick/entry/raid_z dan pthree.org/2012/12/05/zfs-administration-part-ii-raidz
nickcrabtree

Jawaban:


3

Pikirannya adalah jika disk tidak rusak total, dan hanya sebagian yang gagal, saya masih dapat mengakses data?

Secara teori, pemikiran ini benar. Selama Anda menemukan kesalahan pada satu perangkat RAIDZ1 vdev Anda, ZFS dapat dan akan memberi tahu Anda dan memperbaiki kesalahan tersebut, dengan asumsi perangkat lain bebas kesalahan.

Apa yang mungkin berbeda dalam kenyataan adalah beberapa hal:

  • Kesalahan dapat menjangkau partisi dan karena itu dua atau lebih perangkat akan terpengaruh, yang dapat mengakibatkan kesalahan yang tidak dapat dipulihkan atau bahkan hilangnya seluruh kumpulan (tergantung pada lokasi dan jumlah kesalahan). Anda bisa menggunakan RAIDZ2 atau Z3 untuk mengurangi ini, tetapi masalahnya selalu ada.
  • Sementara resilver partisi, disk perlu membaca (2 kali) dan menulis (1 kali) ke disk yang sama secara bersamaan dan acak. Kecuali Anda menggunakan Solaris 11.3 dengan resilver berurutan, ini akan sangat sangat lambat. Sampai Anda selesai dengan proses resilver, Anda rentan terhadap kesalahan di partisi lain. Jika waktu resilver Anda lebih lama, peluang Anda untuk menghadapi URE tambahan bertambah. Itu juga menempatkan beban tambahan pada drive, meningkatkan kemungkinan kegagalan drive total.
  • Bayangkan partisi ke-3 Anda (yang terakhir pada disk 1,5TB) menunjukkan cukup banyak kesalahan untuk menurunkan kumpulan dan meminta penggantian. Jika Anda tidak dapat menambahkan disk lain, Anda tidak dapat melakukan penggantian tanpa shutdown / ekspor, dan bahkan itu lebih rumit dari biasanya.

Berdasarkan poin-poin itu, saya akan menyarankan untuk tidak melakukan ini jika keandalan adalah tujuan utama Anda. Dengan asumsi situasi perangkat keras tetap, saya akan melakukan salah satu dari yang berikut:

  1. Gunakan mirror dan kehilangan 500GB, tetapi dapatkan setup yang sederhana dengan ekspansi yang mudah di masa depan
  2. Gunakan dua kumpulan terpisah dan copies = 2jika Anda ingin ketahanan terhadap kesalahan yang lebih kecil (kegagalan seluruh disk hanya akan membunuh 2/5 atau 3/5 dari data Anda dibandingkan dengan pengaturan Anda)
  3. Gunakan sistem file lain selain ZFS jika Anda ingin memiliki kue dan memakannya juga

5

Apa yang Anda gambarkan agak norak.

ZFS menginginkan disk penuh dengan ukuran dan kemampuan yang sama. Ini penting karena berbagai alasan, tetapi juga masuk akal.

Yang akan Anda lakukan dalam situasi yang telah Anda uraikan adalah menambah kompleksitas ke lingkungan dan meningkatkan risiko Anda.


1
Belum lagi mengurangi kinerja.
Michael Hampton

@MichaelHampton Bagaimana?
kucing

2
@ kucing Karena ZFS mengira Anda memiliki lima spindel, padahal sebenarnya Anda punya dua spindel.
Michael Hampton

4

Mari kita begini:

  • Jika Anda memiliki 1 TB data pada disk satu, Anda dapat mereplikasi ke disk dua, dan Anda dapat kehilangan salah satu disk.

  • Jika Anda memiliki 1,5 TB data pada disk dua, Anda hanya dapat mereplikasi 1 TB data pertama ke disk satu. Dalam skenario ini, jika disk dua gagal Anda AKAN kehilangan data.

ZFS sangat mampu tetapi sebagai aturan umum, sesuai dengan dua poin di atas, pengaturan disk campuran konyol dan tidak berguna. Jika Anda peduli dengan keandalan dan redundansi, pura-pura disk kedua juga hanya 1TB.


4
Saya memberikan sedikit komentar ini karena saya merasa tidak cocok dengan "jawaban" seperti itu, tetapi jika Anda benar-benar ingin menggunakan semua ruang pada disk Anda, saya akan membuat mirror 1TB, dan kemudian gunakan 500GB terakhir sebagai volume reguler, yang tidak direplikasi untuk ruang awal dan file temp yang tidak saya pedulikan (seperti folder unduhan browser saya - bagus untuk menyimpan barang lama di sana, tapi tidak ada yang saya benar-benar rindu jika saya kehilangan itu).
Benny Mackney
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.