Sama seperti pertanyaannya.

Misalkan saya ingin memiliki "tombol darurat" yang setara dengan skrip untuk kumpulan FreeNAS saya - sesuatu yang dapat saya klik untuk dijalankan dari GUI atau dijalankan di konsol/SSH, yang dengan sangat cepat menutup semua yang mungkin membaca atau menulis untuk itu, meng-unmount sistem file, dan – idealnya – mendiamkan disk atau partisi yang digunakan.

Saya tidak peduli tentang kesalahan yang timbul pada perangkat lunak lain atau koneksi jarak jauh dengan melakukan ini, atau membatalkan transfer file lama sebelum waktunya, saya hanya ingin offline kumpulan dengan cara tercepat yang konsisten dengan mempertahankan konsistensi dan mungkin memberikannya beberapa detik untuk menyelesaikan penulisan yang tertunda dan kumpulan berada dalam status yang konsisten untuk tujuan data.

Opsi yang disarankan oleh perintah ZFS tidak terlihat menjanjikan:zpool offline hanya berfungsi pada perangkat individual sehingga seseorang mungkin memiliki kondisi balapan jika penulisan terjadi saat disk dikeluarkan satu per satu; zpool export membutuhkan opsi -f jika digunakan dan membawa peringatan bahwa -f bisa kehilangan data juga. Seseorang dapat memeriksa semua file descriptors yang terbuka menggunakan kumpulan atau perangkatnya (ribuan atau ratusan ribu dari mereka?) dan menutup paksa secara manual masing-masing tetapi itu dapat mencapai kondisi balapan karena tidak menghentikan pembuatan fd baru pada saat yang bersamaan. Saya juga tidak boleh berasumsi bahwa semua aktivitas ZFS dimediasi oleh daftar daemon penyajian file jarak jauh untuk dikirimi sinyal keluar, karena beberapa aktivitas file cenderung bersifat lokal (cron/CLI/sesi terpisah).

Jadi melihat cara terbaik untuk offline seluruh kumpulan dengan aman dan cepat, sepertinya umount mungkin taruhan terbaik saya – ini bekerja pada tingkat sistem file dan dapat offline seluruh sistem file dengan cepat dan sebagai unit monolitik, setelah itu zpool export sepertinya itu akan benar-benar dapat menyelesaikan dan menghentikan aktivitas internal apa pun dengan cara yang aman tanpa -f pilihan, menjaga data itu sendiri dalam keadaan konsisten yang dijamin. Jika ada aktivitas disk mentah (resilver atau scrub) maka saya kira itu akan dilanjutkan atau dimulai ulang ketika kumpulan kemudian dibawa kembali online.

Tetapi bahkan umount tampaknya tidak melakukannya sepenuhnya, karena mungkin ada iSCSI zvol target yang digunakan juga. Data di dalamnya tidak dapat disimpan secara konsisten karena server tidak mengetahui strukturnya, sehingga inisiator jarak jauh harus melakukan perbaikan data sebaik mungkin saat mereka terhubung kembali. Saya baik-baik saja dengan itu, tetapi saya tidak yakin apakah semacam perintah untuk menghentikan paksa atau offline target diperlukan atau praktik terbaik. (Catatan:koneksi pemutusan paksa memiliki masalah yang sama dengan menutup fd individu.)

Saya sadar bahwa pasti ada semacam kehilangan data atau masalah jika kumpulan tiba-tiba dikeluarkan dari status RW saat penulisan sedang berlangsung. Tetapi selama itu tidak kehilangan konsistensi (pada kumpulan ZFS dan tingkat sistem file) maka tidak apa-apa - file yang sedang digunakan/target iSCSI yang diperbarui harus mengambil peluang mereka pada file/blok berada di ZFS-konsisten tetapi status data tidak valid karena offline di tengah jalan melalui data yang sedang ditulis. Itu tidak bisa dihindari dan bukan masalah untuk pertanyaan itu.

Jadi, langkah apa yang sebenarnya perlu saya lakukan, untuk menonaktifkan kumpulan yang sedang digunakan secepat mungkin, konsisten dengan keamanan dan konsistensi kumpulan yang terjamin – dan akan secara manual umount membuat sistem file ZFS yang sedang digunakan (sebagai bagian dari solusi) aman atau membawa risiko kerusakan data?

Pembaruan: Menyebutkan di sini kalau-kalau ada orang lain yang menganggap ini berguna. Jawaban yang diterima menyatakan bahwa export -f mungkin memiliki masalah dengan zvols (iSCSI dll). Berdasarkan petunjuk ini, saya menemukan bahwa iSCSI handler yang digunakan oleh FreeNAS dapat secara paksa keluar/mengakhiri sesi, dan memiliki subperintah berguna lainnya yang dapat dikeluarkan sebelumnya – lihat man ctladm . Untuk apa pun zvol Anda digunakan, kemungkinan akan ada beberapa perintah untuk mengakhiri sesi pada zvol tersebut.)

Jawaban yang Diterima:

Penafian:Saat ini saya tidak memiliki banyak tautan dan referensi untuk mencadangkan semua yang ada di bawah, dan saya tidak mengujinya secara ekstensif. Ini hanyalah ringkasan dari hal-hal yang telah saya baca selama lima hingga tujuh tahun terakhir tentang ZFS dan cara kerjanya, dan beberapa pengujian sendiri yang terbatas (tidak terkoordinasi, tetapi kebanyakan reboot secara acak).

Juga, semua di bawah ini dikatakan tanpa mengenai peristiwa bencana (server terbakar sepenuhnya), bug perangkat lunak (bug di ZFS dan sistem operasi utama serta pengontrol perangkat keras), dan kedengkian aktif (admin nakal, kesalahan administrasi). Untuk semua kasus tersebut, Anda masih perlu memiliki cadangan reguler dan dapat dipulihkan!

Data saat istirahat / konsistensi pada disk

Saya tidak peduli tentang kesalahan yang timbul pada perangkat lunak lain atau koneksi jarak jauh dengan melakukan ini, atau membatalkan transfer file lama sebelum waktunya, saya hanya ingin offline kumpulan dengan cara tercepat yang konsisten dengan mempertahankan konsistensi dan mungkin memberikannya beberapa detik untuk menyelesaikan penulisan yang tertunda dan kumpulan berada dalam status yang konsisten untuk tujuan data.

Pertama, kabar baiknya:karena ZFS menggunakan CoW dan transaksi atom, data Anda yang sudah ada akan aman bahkan jika listrik padam secara tiba-tiba. Ini termasuk tata letak kumpulan dan metadata. Karena data lama tidak pernah dipindahkan sebelum data baru benar-benar ditulis (sebenarnya, tidak pernah dipindahkan sama sekali, hanya dialokasikan kembali), data ini tidak akan berada dalam bahaya dengan cara apa pun jika penulisan tiba-tiba terputus.

Terkait:Grep – mengapa tanda kurung dalam pola grep menghapus proses grep dari hasil ps?

Selain itu, checksum (pohon hash Merkle) membantu memastikan bahwa tidak ada hal buruk yang terjadi selama reboot, yang dapat Anda periksa dengan menggosok kolam. Jika Anda memiliki vdev yang berlebihan, ZFS akan secara otomatis memperbaiki kesalahan yang ditemukan dari salinan bagus yang diketahui. Jika beberapa blok telah rusak dengan cara apa pun (misalnya oleh pengontrol disk jahat yang tidak menulis tetapi mengatakannya), checksum mereka tidak akan cocok dengan yang dari vdev lain dan kesalahan akan ditampilkan.

Data dalam mode terbang / tulis dan hilangnya n detik terakhir

Sinkronkan dan tulis asinkron

Biasanya, ZFS mengumpulkan banyak transaksi untuk mempercepat penulisan yang mahal ke drive yang berputar – memposisikan kepala tulis HDD membutuhkan lebih banyak waktu daripada benar-benar menulis, jadi Anda akan ingin mengantri sebanyak mungkin dan kemudian menulisnya secara berurutan (lebih cepat !) pesan (ingat, kami memiliki KK, ini bekerja secara alami di sini).

Kelemahannya adalah semakin lama Anda mengumpulkan, semakin lama aplikasi Anda harus menunggu pesan "tulis berhasil" - yang berarti sistem Anda akan terkunci selama beberapa detik, yang tidak dapat diterima. Lebih buruk lagi – Anda akan kehilangan semua data yang akan ditulis ke disk tetapi belum ditulis jika terjadi kegagalan daya. Jika aplikasi Anda tidak dapat mengatasinya, kerusakan pada lapisan aplikasi dapat terjadi.

Untuk mengatasi hal ini, ZIL (ZFS intent log) telah ditambahkan. Semua transaksi sinkronisasi dikumpulkan dalam log ini (yang disimpan secara default pada disk kumpulan lambat, tetapi dapat disimpan di SSD cermin yang lebih cepat, yang dinamai perangkat SLOG) dan setelah disimpan, "tulis berhasil" dikembalikan ke aplikasi yang dapat melanjutkan tugasnya (tidak terkunci lagi). Selain itu, semua transaksi asinkron dilakukan tanpa ZIL, sehingga bisa lebih cepat – asalkan aplikasi memanggil operasi tulis yang benar untuk datanya (sinkronisasi vs asinkron).

Properti ZFS

Sekarang untuk bagian yang lebih menarik – apa yang terjadi dengan tulisan Anda? Di sana kita harus membedakan mode operasi untuk sistem file (ini adalah properti ZFS dan dapat diatur secara individual untuk setiap sistem file). Tiga mode yang mungkin adalah (dari halaman manual):

sync=standard
  This is the default option. Synchronous file system transactions
  (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
  and then secondly all devices written are flushed to ensure
  the data is stable (not cached by device controllers).

sync=always
  For the ultra-cautious, every file system transaction is
  written and flushed to stable storage by a system call return.
  This obviously has a big performance penalty.

sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.

Anda akan melihat bahwa meskipun disabled dipilih, tata letak kumpulan/konsistensi internal Anda tidak terpengaruh – Anda hanya akan kehilangan data 5 detik terakhir dan ini dapat menempatkan file Anda ke dalam status yang salah (misalnya, karena Anda memiliki VM di atas yang mengharapkan penulisan sinkronisasi tetapi Anda hanya menyediakan async zvol sebagai penyimpanan data pendukung).

Di sisi lain, jika Anda tidak ingin kehilangan apa pun , atur semua sistem file Anda ke always dan beralih ke SSD berperforma tinggi, setidaknya untuk perangkat SLOG (atau mengalami waktu tunggu).

standard adalah kompromi dan paling fleksibel – aplikasi itu sendiri yang memutuskan mode tulis mana yang dibutuhkan. Jika aplikasi Anda buruk, Anda mungkin mengalami kehilangan data. Jika mereka berperilaku, Anda akan memiliki kinerja terbaik dengan dasar keamanan tertentu.

Ekspor/impor kumpulan:

Dari dokumentasi tentang zpool export :

Perintah mencoba untuk meng-unmount semua sistem file yang dipasang di dalam kumpulan sebelum melanjutkan. Jika salah satu sistem file gagal di-unmount, Anda dapat secara paksa melepasnya dengan menggunakan opsi -f.

Jika perangkat tidak tersedia pada saat ekspor, perangkat tidak dapat diidentifikasi sebagai diekspor bersih. Jika salah satu perangkat ini kemudian dipasang ke sistem tanpa perangkat apa pun yang berfungsi, perangkat tersebut akan muncul sebagai "berpotensi aktif".

Jika volume ZFS digunakan di kumpulan, kumpulan tidak dapat diekspor, bahkan dengan opsi -f. Untuk mengekspor kumpulan dengan volume ZFS, pertama-tama pastikan bahwa semua konsumen volume tidak lagi aktif.

Ini berarti kira-kira tiga hal:

• -f memaksa kumpulan untuk diekspor dengan melepas paksa semua sistem file, meskipun sistem tersebut aktif (dengan mengabaikan kunci atau aplikasi yang tertulis di sana)
• Ini tidak bekerja dengan zvol s
• Anda tidak boleh membagi kumpulan dan menggunakannya pada sistem yang berbeda (hati-hati dengan situasi failover)

Terkait:Bagaimana cara membuat daftar file termuda ke-n (tanpa parsing ls!)?

Ringkasan:

• Jika yang Anda pedulikan hanyalah konsistensi pada disk, Anda dapat menggunakan export -f atau mati total
• Jika Anda peduli dengan semua data, gunakan sync=always dan SSD cepat
• Mengenai iSCSI/NFS sebagai penyimpanan data untuk VM, ikhtisar ini juga dapat membantu (kutipan:gunakan NFS atau nonaktifkan cache writeback iSCSI pada Host tamu/VM; diamkan VM sebelum mengambil snapshot ZFS, ZFS akan baik-baik saja, tetapi guest VM hanya akan crash-consistent)

Sebagai balasan untuk pertanyaan lanjutan dari komentar (tinggalkan pertanyaan di mana saya tidak memiliki jawaban yang berguna):

(1) “kabar baik/COW” – bagaimana jika blok tingkat atas akan diperbarui – apakah akan selalu menemukan blok tingkat atas yang dapat digunakan (bahkan jika menunjuk ke versi pohon metadata yang agak lama)? Seberapa buruk itu bisa terjadi?

Kasus terburuk adalah uberblock (yang ada di atas semua yang lain) rusak pada semua perangkat yang berlebihan. Karena tidak ada blok di atasnya, Anda tidak dapat merekonstruksinya dari atas, jadi ada beberapa salinan dari setiap uberblock (IIRC sekitar 3 atau 4), jadi satu bisa hilang dan salinan pengganti masih ada.

(2) Saya terbiasa dengan TXG dan menggunakan ESXi. Menggunakan APC UPS + PSU/hw bagus + P3700 NVMe ZIL jadi power lumayan + ZIL cepat. Tetapi tidak mungkin semua penulisan saat ini akan disinkronkan dan seperti yang Anda katakan, sync=always lambat. Tetapi balasan Anda memang menimbulkan pemikiran, saya mungkin melakukan beberapa pengujian kinerja. Saya menggunakan dedup (hemat 4x, sepadan), jadi tulis =lambat (harus mencari DDT). Alasan sinkronisasi=selalu hanya memengaruhi penulisan yang lambat karena DDT. Tapi pengaturan sync=selalu memaksa ZIL, ZIL sangat cepat dan dan itu membuat TXG panjang aman yang mungkin berarti akses disk lebih efisien. Atau mungkin membunuh latensi. Tidak tahu yang mana! Mungkin harus mencoba!

Saya tidak memiliki pengalaman nyata dengan dedup, jadi saya tidak dapat mengatakan sesuatu yang berguna di sini, kecuali bahwa Anda telah membuat pilihan yang baik dalam perangkat keras (latensi rendah, IOPS tulis 64k acak tinggi, antarmuka NVMe). Ini hanya bisa lebih cepat jika Anda berinvestasi dalam beberapa drive RAM permanen yang sangat mahal (ZeusRAM et al.).

(6) Dengan "konsistensi pada disk" maksud Anda ZFS senang dan pool konsisten? Tidak khawatir jika beberapa file/dir. berakhir dengan konten yang tidak valid atau tidak dipindahkan/dihapus adalah kumpulan tiba-tiba menghilang, atau sistem file seperti NTFWS/VMFS pada zvol rusak secara internal (yaitu sebagai ZFS zvol tidak apa-apa tetapi dari perspektif klien perlu fsck/chkdsk), kumpulan yang disediakan aman/konsisten seperti yang dilihat ZFS

Ya. Intinya "kolam saya tidak kacau, yay!" dalam pengaturan multi-pengguna – bahkan jika satu pengguna memiliki masalah dengan file-nya, yang lain tidak menderita.

(7) Dengan "crash konsisten" maksud Anda apa yang saya maksud (saya pikir Anda lakukan) - bahwa ZFS akan baik-baik saja, kumpulan sejauh yang dilihat ZFS akan baik-baik saja, tetapi data klien jarak jauh mungkin terpotong dari klien itu perspektif yang mirip dengan seolah-olah klien mengalami kegagalan IO disk yang tiba-tiba dan penulisan telah hilang? ==pool akan baik-baik saja, klien mungkin kehilangan/data tidak konsisten dan mungkin memerlukan bantuan untuk memulihkan, seperti kegagalan IO disk lain atau sistem crash?

Ya, pada dasarnya mematikan VM alih-alih mematikan bersih dan KEMUDIAN mengambil snapshot – jika Anda menyalakannya setelah itu, fsck atau serupa tergantung pada sistem file yang akan dijalankan dan mungkin mengeluh tentang shutdown yang tidak bersih. Ini berbeda dengan snapshot ESXi, yang dilanjutkan pada titik waktu yang tepat seolah-olah tidak ada yang terjadi, tetapi mereka membutuhkan interaksi dengan sistem tamu (tambahan tamu terpasang) dan menyertakan memori virtual VM.

Anda dapat menggabungkan keduanya untuk keuntungan Anda:pertama ambil snapshot ESXi, lalu setelah itu snapshot ZFS dari datastore (ESXi menyimpan snapshotnya bersama VM). Kemudian hapus snapshot ESXi Anda, tetapi simpan yang ZFS (membutuhkan lebih sedikit ruang karena salinan tingkat blok). Saat memulihkan, pertama-tama pulihkan snapshot ZFS Anda dan kemudian kembalikan ke snapshot ESXi Anda (tersimpan) dan Anda akan melanjutkan dari tempat Anda tinggalkan. napp-it (sistem manajemen ZFS yang sangat baik dengan antarmuka Web) memiliki konsep bawaan ini (setidaknya untuk penyimpanan data NFS, saya tidak memeriksa iSCSI tetapi menganggapnya serupa).