ZFS RAID dan enkripsi LUKS di Linux


24

Saya berencana untuk menyiapkan drive 3x 2TB 7200rpm sebagai kumpulan Z-RAID terenkripsi LUKS di Linux (untuk solusi NAS).

Pemahaman saya tentang masalah yang dihadapi adalah bahwa satu-satunya cara untuk mencapai ini adalah untuk luksFormatsetiap perangkat fisik dan kemudian mengumpulkan zpool dari wadah LUKS yang tidak terkunci.

Saya memiliki keprihatinan berikut dengan ini:

  • Bukankah itu akan secara signifikan menghambat kinerja penulisan? Dalam pengaturan ini, data yang berlebihan dienkripsi beberapa kali karena LUKS tidak "menyadari" Z-RAID. Dalam solusi LUKS-on-mdadm data dienkripsi sekali dan hanya ditulis ke disk beberapa kali. CPU saya mendukung Intel AES-NI.

  • Apakah ZFS akan menyadari kegagalan disk ketika beroperasi pada wadah LUKS alat-mapper sebagai lawan perangkat fisik? Bagaimana dengan deduplikasi dan fitur ZFS lainnya?


4
Saya tidak akan melakukannya. Kedengarannya rawan kegagalan.
ewwhite

3
@ MadHatter Karena itu ZFS. Kamu tidak bisa melakukan itu
Michael Hampton

1
Baik (saya akan mengambil kata-kata Anda untuk itu). Buat ZFS besar tunggal yang berisi satu file besar, mountback-mount dan enkripsi itu .
MadHatter mendukung Monica

1
@ewewhite Saya hanya mencari tahu opsi untuk menggunakan enkripsi dengan ZFS di Linux sampai modul kernel ZFS mengimplementasikan enkripsi itu sendiri. Tapi saya harus setuju - LUKS dan ZFS tampaknya tidak rukun.
MasterM

4
Jangan pernah, buat file besar dan loopback dengan ZFS. Anda mengacaukan kumpulan Anda ke kecepatan yang tidak dapat digunakan ketika KK kehabisan ruang untuk operasi itu.
Vinícius Ferrão

Jawaban:


27

Salah satu server yang saya kelola menjalankan tipe konfigurasi yang Anda gambarkan. Ini memiliki enam hard drive 1TB dengan kolam RAIDZ terenkripsi LUKS di atasnya. Saya juga memiliki dua hard drive 3TB di cermin ZFS terenkripsi LUKS yang diganti setiap minggu untuk dikeluarkan di luar lokasi. Server telah menggunakan konfigurasi ini selama sekitar tiga tahun, dan saya tidak pernah punya masalah dengannya.

Jika Anda memiliki kebutuhan untuk ZFS dengan enkripsi di Linux maka saya merekomendasikan pengaturan ini. Saya menggunakan ZFS-Fuse, bukan ZFS di Linux. Namun, saya percaya bahwa tidak ada hubungannya dengan hasil selain ZFS di Linux mungkin akan memiliki kinerja yang lebih baik daripada pengaturan yang saya gunakan.

Dalam pengaturan ini, data yang berlebihan dienkripsi beberapa kali karena LUKS tidak "menyadari" Z-RAID. Dalam solusi LUKS-on-mdadm data dienkripsi sekali dan hanya ditulis ke disk beberapa kali.

Perlu diingat bahwa LUKS tidak mengetahui adanya RAID. Itu hanya tahu bahwa itu duduk di atas perangkat blok. Jika Anda menggunakan mdadm untuk membuat perangkat RAID dan kemudian luksformat, mdadm yang mereplikasi data terenkripsi ke perangkat penyimpanan yang mendasarinya, bukan LUKS.

Pertanyaan 2.8 dari LUKS FAQ membahas apakah enkripsi harus di atas RAID atau sebaliknya . Ini menyediakan diagram berikut.

Filesystem     <- top
|
Encryption
|
RAID
|
Raw partitions
|
Raw disks      <- bottom

Karena ZFS menggabungkan fungsi RAID dan sistem file, solusi Anda perlu terlihat seperti berikut.

RAID-Z and ZFS Filesystem  <-top
|
Encryption
|
Raw partitions (optional)
|
Raw disks                  <- bottom

Saya telah mencantumkan partisi mentah sebagai opsional karena ZFS mengharapkan bahwa itu akan menggunakan penyimpanan blok mentah daripada partisi. Meskipun Anda bisa membuat zpool menggunakan partisi, itu tidak disarankan karena akan menambah tingkat manajemen yang tidak berguna, dan itu perlu diperhitungkan saat menghitung berapa offset Anda untuk penyelarasan blok partisi.

Bukankah itu akan secara signifikan menghambat kinerja penulisan? [...] CPU saya mendukung Intel AES-NI.

Seharusnya tidak ada masalah kinerja selama Anda memilih metode enkripsi yang didukung oleh driver AES-NI Anda. Jika Anda memiliki cryptsetup 1.6.0 atau yang lebih baru, Anda dapat menjalankan cryptsetup benchmarkdan melihat algoritma mana yang akan memberikan kinerja terbaik.

Pertanyaan tentang opsi yang direkomendasikan untuk LUKS ini mungkin juga bermanfaat.

Karena Anda memiliki dukungan enkripsi perangkat keras, Anda cenderung menghadapi masalah kinerja karena ketidaksejajaran partisi.

ZFS di Linux telah menambahkan ashiftproperti ke zfsperintah untuk memungkinkan Anda menentukan ukuran sektor untuk hard drive Anda. Menurut FAQ yang ditautkan, ashift=12akan mengatakan bahwa Anda menggunakan drive dengan ukuran blok 4K.

LUKS FAQ menyatakan bahwa partisi LUKS memiliki keselarasan 1 MB. Pertanyaan 6.12 dan 6.13 membahas hal ini secara terperinci dan juga memberikan saran tentang cara membuat header partisi LUKS lebih besar. Namun, saya tidak yakin mungkin membuatnya cukup besar untuk memastikan bahwa sistem file ZFS Anda akan dibuat pada batas 4K. Saya akan tertarik mendengar bagaimana ini bekerja untuk Anda jika ini adalah masalah yang perlu Anda selesaikan. Karena Anda menggunakan drive 2TB, Anda mungkin tidak menghadapi masalah ini.

Apakah ZFS akan menyadari kegagalan disk ketika beroperasi pada wadah LUKS alat-mapper sebagai lawan perangkat fisik?

ZFS akan menyadari kegagalan disk sejauh dapat membaca dan menulis kepada mereka tanpa masalah. ZFS membutuhkan penyimpanan blok dan tidak peduli atau tahu tentang spesifik penyimpanan itu dan dari mana asalnya. Hanya melacak kesalahan baca, tulis, atau checksum yang ditemui. Terserah Anda untuk memantau kesehatan perangkat penyimpanan yang mendasarinya.

Dokumentasi ZFS memiliki bagian tentang pemecahan masalah yang layak dibaca. Bagian tentang mengganti atau memperbaiki perangkat yang rusak menjelaskan apa yang mungkin Anda temui selama skenario kegagalan dan bagaimana Anda bisa menyelesaikannya. Anda akan melakukan hal yang sama di sini untuk perangkat yang tidak memiliki ZFS. Periksa syslog untuk pesan dari driver SCSI Anda, HBA atau pengontrol HD, dan / atau perangkat lunak pemantauan SMART dan kemudian bertindak sesuai.

Bagaimana dengan deduplikasi dan fitur ZFS lainnya?

Semua fitur ZFS akan bekerja sama terlepas dari apakah penyimpanan blok yang mendasarinya dienkripsi atau tidak.

Ringkasan

  1. ZFS pada perangkat yang dienkripsi LUKS berfungsi dengan baik.
  2. Jika Anda memiliki enkripsi perangkat keras, Anda tidak akan melihat performa yang baik selama Anda menggunakan metode enkripsi yang didukung oleh perangkat keras Anda. Gunakan cryptsetup benchmarkuntuk melihat apa yang paling cocok untuk perangkat keras Anda.
  3. Pikirkan ZFS sebagai RAID dan sistem file yang digabungkan menjadi satu kesatuan. Lihat diagram ASCII di atas untuk tempat yang sesuai dengan tumpukan penyimpanan.
  4. Anda harus membuka kunci setiap perangkat blok terenkripsi LUKS yang digunakan sistem file ZFS.
  5. Pantau kesehatan perangkat keras penyimpanan dengan cara yang sama seperti yang Anda lakukan sekarang.
  6. Berhati-hatilah dengan perataan blok sistem file jika Anda menggunakan drive dengan blok 4K. Anda mungkin perlu bereksperimen dengan opsi luksformat atau pengaturan lain untuk mendapatkan perataan yang Anda butuhkan untuk kecepatan yang dapat diterima.

3
+1 Untuk menemukan cara agar ini berfungsi dengan contoh.
ewwhite

1
1 MiB sudah habis dibagi oleh 4KiB, jadi Anda harus benar menyelaraskan sampai ashift = 20 (yang saya pikir tidak perlu dalam karir saya) asalkan Anda menggunakan disk mentah.
Michael Hampton

1
Hanya satu hal lagi: Saya memilih jawaban Anda karena itu yang diharapkan OP, dan ditulis dengan baik, jadi itu lebih baik daripada jawaban saya.
Vinícius Ferrão

3
@ ViníciusFerrão: Perhatikan juga bahwa FreeBSD dan FreeNAS menggunakan pendekatan yang identik untuk enkripsi ZFS. gelidigunakan untuk membuat perangkat terenkripsi dan data plaintext tersedia melalui perangkat kedua yang digunakan ZFS. Lihat poin kedua di doc.freenas.org/index.php/Volumes#Encryption .
Starfish

2
@ CMCDragonkai Karena kedua perangkat L2ARC dan SLOG berisi potongan-potongan data dari kolam Anda, jika Anda mengenkripsi penyimpanan untuk memberikan kerahasiaan (yang sering menjadi titik menggunakan penyimpanan terenkripsi di tempat pertama), Anda hampir pasti ingin jalankan perangkat L2ARC dan SLOG yang dienkripsi dengan cara yang sama.
CVn

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.