ZFS untuk Pemula

 (ikrima.dev)
2 poin oleh GN⁺ 2023-09-06 | 1 komentar | Bagikan ke WhatsApp
  • Panduan pengantar yang merangkum pemecahan masalah, penyusunan volume baru, hingga strategi backup berdasarkan insiden kerusakan ZFS di FreeNAS, dan membahas struktur serta perintah yang dibutuhkan saat pertama kali mengoperasikan ZFS dalam satu alur
  • ZFS menyediakan filesystem dan logical volume manager sekaligus, dimulai dari Sun Microsystems, lalu pada Linux dan FreeBSD umumnya menggunakan kode OpenZFS
  • Struktur dasarnya terbagi menjadi vdev yang menggabungkan disk fisik, pool yang mengumpulkan vdev, dataset yang berperan sebagai filesystem, dan volume berbentuk block device; RAIDZ-1/2/3 masing-masing dapat menahan kegagalan 1, 2, dan 3 disk
  • Perintah yang paling sering dipakai adalah zpool create/status/list/import/export/destroy/scrub dan zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy, dan untuk menghindari masalah perubahan nama perangkat, penggunaan device UUID lebih disarankan
  • Snapshot melindungi keadaan pada titik waktu tertentu secara ringan dan bisa direplikasi ke pool atau sistem lain dengan zfs send/recv, tetapi snapshot saja sulit menggantikan backup atau DR

Konsep dasar ZFS

  • ZFS adalah filesystem lokal seperti ext4, NTFS, dan exFAT, sekaligus juga berfungsi sebagai logical volume manager seperti LVM di Linux
  • ZFS dibuat oleh Sun Microsystems, dan kode sumber ZFS dipublikasikan dengan lisensi open source sampai sebelum Oracle mengakuisisi Sun
  • Karena kode yang sudah dirilis telah di-port ke berbagai OS, kemudian lahirlah proyek OpenZFS, dan kode ini digunakan di sebagian besar sistem keluarga Unix seperti Linux dan FreeBSD
  • Materi ini dirangkum dari sudut pandang pemula agar orang yang baru mengenal ZFS dapat memahami struktur dan perintah operasionalnya

Komponen ZFS

  • vdev terdiri dari satu atau lebih drive fisik, dan selain hard drive juga dapat mencakup file
    • Bisa dikombinasikan dalam bentuk mirror atau RAIDZ
    • Ada 7 jenis vdev, termasuk jenis penting seperti hot spare, L2ARC, dan ZIL
  • pool terdiri dari satu atau lebih vdev, dan biasanya volume atau dataset dibuat di dalam pool
    • Saat membuat pool dengan perintah zpool, vdev juga didefinisikan bersamaan
    • Berbagai jenis vdev bisa dicampur untuk membentuk tingkat RAIDZ
  • dataset adalah komponen di ZFS yang setara dengan filesystem
    • Dapat mengatur akses pengguna, quota, kompresi, snapshot, dan lain-lain
  • volume mirip dengan dataset, tetapi menyediakan representasi block device
    • Hanya menyediakan sebagian fitur dataset
    • Berguna saat menjalankan filesystem lain di atas ZFS atau mengekspor iSCSI extent

Jenis RAIDZ

  • Dynamic/Simple Stripe, yaitu RAID0, menyebarkan data tanpa parity, dan jika kehilangan satu perangkat maka seluruh data hilang
  • MIRROR, yaitu RAID1, mencerminkan disk dan digunakan bersama 2~4 atau lebih disk
  • RAIDZ-1, yaitu RAID5, menyebarkan parity bersama data, dan dapat menahan kehilangan 1 drive fisik sampai terjadi kegagalan RAID
    • RAIDZ memerlukan minimal 3 disk
  • RAIDZ-2, yaitu RAID6, dapat menahan kehilangan hingga 2 drive fisik
    • RAIDZ-2 memerlukan minimal 4 disk
  • RAIDZ-3 dapat menahan kehilangan hingga 3 drive fisik
    • Memerlukan minimal 4 disk, tetapi sebaiknya tidak digunakan dengan kurang dari 5 disk

Membuat pool dan memeriksa status

  • Pool ZFS dibuat dengan format zpool create [pool] [devices]
    • Contoh pool disk tunggal: zpool create tank /dev/sdb
    • Contoh stripe 3 disk: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • Contoh mirror 2 disk: zpool create tank mirror sdb sdc
    • Contoh pool RAIDZ: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 dapat dibuat dengan format zpool create [pool name] raidz[1,2,3] [devices]
  • Saat membuat pool, mount point default dapat ditentukan dengan flag -m
    • Contoh: zpool create tank -m /mnt/tank mirror sdb sdc
  • Contoh menggunakan nama perangkat berbentuk /dev/sdx, tetapi untuk menghindari masalah boot akibat perubahan nama perangkat, penggunaan device UUID lebih disarankan
  • zpool status adalah perintah dasar untuk memeriksa status pool
    • state menunjukkan apakah pool sedang online
    • status menampilkan informasi tambahan tentang pool
    • action menunjukkan tindakan lanjutan yang diperlukan
    • scan menampilkan progres scrub atau status scrub terakhir
    • errors menunjukkan ada atau tidaknya masalah pada pool
  • zpool list menampilkan detail seperti ukuran pool, alokasi, ruang kosong, fragmentation, capacity, dedup, dan health
  • zpool history menampilkan riwayat perintah yang digunakan untuk perubahan konfigurasi sejak pool dibuat

Mengimpor, mengekspor, menghapus pool, dan scrub

  • Setelah dibuat, pool biasanya otomatis di-import dan di-mount, tetapi saat pemecahan masalah atau setelah sistem di-image ulang, import manual mungkin diperlukan
  • Jika zpool import dijalankan tanpa nama pool, perintah ini akan menampilkan daftar pool yang bisa di-import
    • Jika tidak ada pool yang bisa di-import, akan muncul no pools available to import
    • Jika nama pool ditentukan, pool tersebut akan di-import, dan perintah import juga akan me-mount pool
    • zpool import -a akan mengambil semua pool yang dapat di-import
  • Jika menggunakan -R seperti zpool import -R /mnt/tank2 tank, pool akan di-mount ke lokasi alternate root
    • Ini bukan mount path milik pool itu sendiri, melainkan folder root alternatif
  • zpool export [pool name] adalah kebalikan dari import; ia akan mencoba mengekspor pool setelah me-unmount filesystem yang ter-mount di dalamnya
    • Jika unmount filesystem gagal, -f bisa digunakan untuk force unmount
    • Jika ada ZFS volume yang sedang digunakan, export akan gagal bahkan jika -f dipakai
  • zpool destroy menghapus pool beserta dataset atau volume turunannya
    • Karena semua data dan snapshot juga dihapus, penggunaannya perlu sangat hati-hati
  • ZFS scrub membandingkan semua block dalam pool dengan checksum yang diketahui untuk memverifikasi integritas data
    • Pada vdev yang memiliki parity, data yang rusak dipulihkan menggunakan data dari disk yang sehat
    • Untuk menjaga kesehatan sistem, scrub perlu dijalankan secara terjadwal
    • Mulai: zpool scrub [pool]
    • Cek status: periksa bagian scan pada zpool status
    • Hentikan: zpool scrub -s [pool]

Membuat dataset dan mount

  • zfs create adalah perintah untuk membuat filesystem atau volume baru, dan di sini pembahasan berfokus pada dataset daripada volume
  • zfs create tank/dataset1 membuat dataset1 di bawah tank
    • Dataset tank dibuat otomatis saat zpool create
  • zfs create -p akan membuat juga dataset induk yang belum ada, seperti mkdir -p
    • Jika dataset induk tidak ada, zfs create biasa akan gagal
  • Jika zfs mount dijalankan tanpa argumen, ia menampilkan filesystem ZFS yang sedang ter-mount beserta mount point-nya
    • Output ini tidak mencakup child dataset
  • zfs mount [pool|dataset] me-mount filesystem yang ditentukan
    • zfs mount -a me-mount semua filesystem
  • Child dataset bisa di-mount tanpa parent dataset
    • Dalam kasus ini, path yang dibutuhkan akan dibuat pada filesystem OS
    • Jika nanti mencoba me-mount parent dataset, direktori yang sudah terbuat itu bisa memicu error directory is not empty
  • zfs unmount [dataset] me-unmount dataset yang ditentukan

Melihat dataset dan mengatur properti

  • zfs list [dataset name] menampilkan informasi tentang dataset yang ditentukan
    • Sebagai ganti nama dataset, mount point juga bisa diberikan sebagai argumen
  • Jika zfs list dijalankan tanpa nama dataset, semua dataset di sistem akan ditampilkan secara rekursif
  • Jika flag -r digunakan saat menentukan nama dataset, isi di bawah dataset tersebut dapat ditampilkan secara rekursif
  • Properti ZFS mengendalikan perilaku filesystem, volume, snapshot, dan clone
    • Sekilas dapat terlihat mirip dengan mount option
  • zfs get all [dataset] menampilkan semua properti dataset
  • Nilai properti tertentu dapat diperiksa seperti zfs get compression tank
  • Untuk mengatur properti gunakan zfs set
    • Contoh: zfs set compression=lz4 tank
    • Setelah diatur, Anda bisa memastikan nilai compression berubah menjadi lz4 dengan zfs get compression tank

Cara kerja dan pemanfaatan snapshot

  • snapshot menyimpan keadaan filesystem pada titik waktu tertentu, tetapi tidak menyalin file
  • Snapshot menandai data yang ada sebagai read-only, dan meskipun data baru kemudian ditambahkan ke filesystem, data block lama yang dilindungi snapshot tidak terpengaruh
  • Alur contohnya sebagai berikut
    • Snapshot 1 dibuat pada filesystem yang memiliki Data A
    • Setelah itu Data B ditambahkan dan snapshot 2 dibuat
    • Lalu Data C ditambahkan
    • Snapshot 1 melindungi Data A, dan snapshot 2 melindungi Data A serta Data B
    • Meskipun snapshot 1 dihapus, Data A tetap terlindungi oleh snapshot 2
  • Jumlah data yang digunakan snapshot sangat kecil
    • Karena alih-alih menyalin file, ia hanya mencatat top-level metadata block filesystem yang termasuk dalam snapshot
  • Snapshot berguna untuk pengujian pengembangan software atau membuat failsafe sebelum upgrade
  • Snapshot saja tidak boleh dianggap sebagai solusi backup atau DR

Perintah snapshot

  • Pembuatan snapshot menggunakan format zfs snapshot [pool/dataset@snapshot_name]
    • Contoh: zfs snapshot tank/dataset1@snapshot1
  • Daftar snapshot dapat dilihat dengan zfs list -t snapshot
  • Jika ada beberapa child dataset, snapshot bisa dibuat pada top-level dataset atau menggunakan flag -r untuk snapshot rekursif
    • Contoh snapshot biasa: zfs snapshot tank@snapshot-master
    • Contoh snapshot rekursif: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] membandingkan perbedaan antar snapshot
    • Dari output-nya, file yang ditambahkan dan path yang dimodifikasi dapat diperiksa
  • Pemulihan snapshot dilakukan dengan zfs rollback [pool/dataset@snapshot_name]
    • Saat rollback, file yang dibuat setelah snapshot akan dihapus
    • Snapshot yang lebih baru juga akan dihapus, dan dalam kasus ini Anda mungkin diminta menggunakan opsi -r

ZFS send/recv dan replikasi

  • ZFS send adalah fitur untuk mengirim snapshot sebagai data stream
  • Snapshot dan dataset dapat direplikasi ke file, pool lain, atau sistem lain melalui SSH
  • Contohnya menggunakan dua pool bernama tank dan backup
    • Dataset tank/Movies memiliki data sebesar 1.50G
    • Sebelum transfer, snapshot dibuat dengan zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies mengirim snapshot ke pool backup
  • Setelah transfer, zfs list akan menampilkan backup/Movies dan tank/Movies, dan zfs list -t snapshot juga akan memperlihatkan snapshot di kedua sisi
  • zfs send adalah fitur yang layak dieksplorasi untuk berbagai opsi dan skenario penggunaan, dan bila dipakai bersama RAIDZ dan snapshot dapat membuat filesystem lebih tangguh

Menghapus dataset dan snapshot

  • Penghapusan dataset menggunakan format zfs destroy [pool/dataset]
    • Flag -r juga bisa digunakan
  • Penghapusan snapshot juga menggunakan zfs destroy [pool/dataset@snapshot_name]
    • Flag -r juga bisa digunakan untuk snapshot
  • ZFS menyediakan lebih banyak fitur, tetapi materi ini lebih merupakan titik awal untuk mempelajari konsep dasar dan perintahnya

Referensi

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-06
Opini di Hacker News
  • Saya baru mulai memakai ZFS, dan kurva belajarnya ternyata lebih curam dari yang saya kira. Akan bagus kalau ada wrapper mudah yang membuat kasus penggunaan umum menjadi sangat sederhana
    Misalnya saat membuat pool, cukup pakai default yang masuk akal seperti ashift=12, kompresi lz4, xattr=sa, acltype=posixacl, atime=off, dan untuk enkripsi cukup ada on/off alih-alih banyak opsi
    Akan bagus kalau ia membuatkan kunci enkripsi, mengatur service systemd yang mendekripsi pool saat boot, serta memandu pencadangan kunci. zfs list seharusnya menunjukkan apakah dataset sudah di-mount, apakah terenkripsi, dan apakah kuncinya sudah dimuat
    Saya ingin dataset rekursif dihilangkan, dan alih-alih {pool}/{dataset}, gunakan {pool}:{dataset} agar pool dan dataset dibedakan dengan jelas. Nama pool atau snapshot juga sebaiknya tidak perlu dibuat sendiri; aturan seperti {hostname}-[A-Z], {pool name}_{datetime created} serta nama singkat berbasis angka bisa diberikan otomatis
    Saat membuat pool, jangan minta pengguna memasukkan ID disk sendiri; buat saja dengan /dev/sda, /dev/sdb, lalu simpan metadata di disk supaya tidak membingungkan meski urutan drive berubah
    Progres sebaiknya selalu ditampilkan dengan pv, dan scrub mingguan serta snapshot dan pembersihan per jam/harian/mingguan/bulanan sebaiknya diatur otomatis
    Jika mengirim ke disk yang belum punya pool, setelah konfirmasi, buatkan pool disk tunggal dengan pengaturan yang sama seperti pool pengirim; dan zpool serta zfs sebaiknya digabung menjadi satu perintah
    Saat mengirim dataset terenkripsi, gunakan --raw secara otomatis; default pengiriman sebaiknya --replicate, dan jika memungkinkan gunakan -I. Jangan sembunyikan filesystem snapshot di direktori tersembunyi; perlu juga cara mudah untuk me-mount dan menjelajahi dataset snapshot
    • Ini campuran antara usulan yang masuk akal dan preferensi yang sangat kuat. Default ashift=12 atau sintaks {pool}:{dataset} bisa dimengerti, tetapi tampaknya sulit diubah sekarang, dan sebagian usulan bisa merusak kasus penggunaan yang tidak diketahui
      Cara menamai pool dengan nama host tidak cocok untuk pool SAN yang bisa diimpor dari beberapa host
      Menurut saya scrub mingguan, snapshot berkala, dan pembersihan berkala adalah tugas scheduler sistem operasi. Menggabungkan zpool dan zfs mungkin saja, tetapi pada akhirnya akan menjadi semacam zfs -pool XXXX, zfs -volume XXXX; saya tidak mengerti mengapa itu diperlukan
      Dataset rekursif memang berguna dalam beberapa kasus. Sebaliknya, saya sepenuhnya setuju bahwa zfs list seharusnya menunjukkan apakah dataset di-mount, apakah terenkripsi, dan apakah kuncinya dimuat
      Bagian soal jangan memasukkan ID disk agak ambigu. Disk bisa ditentukan dengan berbagai cara seperti ID, WWN, label, sdX, tetapi bagaimanapun Anda tetap harus memberi tahu disk mana yang akan dipakai
      Fitur untuk menyimpan metadata di disk agar tetap bisa ditemukan meski urutannya berubah sudah ada. Bahkan jika beberapa drive dipindah colokannya lalu pool diimpor, ZFS tetap menemukannya
      Sebagian usulan cukup baik sebagai default, tetapi beberapa tampaknya belum cukup mempertimbangkan pola penggunaan dan kebutuhan di luar dirinya sendiri. ZFS ditujukan untuk jauh lebih banyak pengguna
    • Membuat pool dengan /dev/sda, /dev/sdb lalu mengatakan ZFS bingung, terus terang itu lebih dekat ke masalah pengguna yang tidak memakai cara modern, bukan masalah ZFS
      Di Linux sudah cukup lama ada referensi lengkap seperti /dev/disk/by-id/ata-$manufactuer-$serial-$whatever. Saat membuat pool, seharusnya pakai path seperti ini
    • Banyak usulannya sangat dipengaruhi preferensi pribadi; itu sendiri tidak buruk, tetapi terlihat seperti mengguncang konvensi yang sudah ada tanpa alasan jelas. Misalnya saya tidak mengerti mengapa harus {pool}:{dataset}
      Jika tidak ingin menamai snapshot sendiri, alat kecil yang saya buat, https://github.com/rollcat/zfs-autosnap, mungkin cocok
      Masukkan zfs-autosnap snap ke cron per jam, dan zfs-autosnap gc per hari, maka riwayat snapshot akan digulirkan sesuai kebijakan retensi
      Membuat wrapper perintah ZFS sederhana tidak sulit, jadi silakan ambil kode saya dan buat alat sendiri
    • Saya pernah membaca bahwa salah satu tugas terakhir magang pandai besi adalah membuat sendiri semua alat yang akan dipakai pandai besi sungguhan, seperti landasan, palu, penjepit, dan sebagainya
      Di tempat kerja, saya juga menulis beberapa skrip untuk membuat array ZFS sesuai bentuk deployment yang diasumsikan hari itu. Di dalamnya termasuk pembuatan volume terenkripsi LUKS untuk menaruh zvol, standardisasi aturan penamaan, serta pengaturan default seperti ashift=12 dan kompresi lz4
      Itu jauh sebelum enkripsi bawaan ZFS hadir, dan karena cara sekarang pun tidak bermasalah, saya belum memperbarui skrip agar mendukung enkripsi ZFS
      Sekarang saya tidak lagi mengingat banyak flag, tetapi skrip-skrip itu berfungsi sebagai dokumentasi, dan orang lain di tim cukup menjalankan make-zfs-big-mirror atau make-big-zfs-undundant-raid0
      Suatu saat, jika perlu memprovisioning sistem lebih dari 20 kali setahun, itu pun bisa diotomatisasi lewat provisioning
    • Seperti yang sudah dikatakan orang lain, ini adalah usulan yang sangat berbasis preferensi kuat. Punya pendapat itu boleh saja, tetapi banyak poinnya berada di spektrum dari “bukan cara yang biasa saya pakai di Linux” sampai usulan yang benar-benar bermasalah
      Usulan untuk tidak menamai pool tidak masuk akal. Pool tidak dibuat sesering itu, jadi beri saja nama
      Jika tidak ingin menamai snapshot, Anda bisa memakai httm dan zfs allow. Misalnya httm -S . membuat snapshot seperti rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount
      zfs dan zpool masing-masing adalah perintah Unix yang bagus dengan banyak subperintah. Menurut saya keputusan para perancang ZFS untuk tidak membuat satu perintah manajemen tunggal yang lebih rumit adalah keputusan yang sangat cerdas
      Me-mount dan menjelajahi dataset snapshot secara eksplisit juga mudah dilakukan dengan zfs mount. Namun, saya harap juga dipercaya bahwa antarmuka virtual yang stabil membuat pencarian semua versi file menjadi mudah, dan ini jauh lebih sulit di btrfs dan lainnya. httm juga layak dilihat
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • Ada lebih banyak hal berguna di ZFS. Ada baiknya memahami perbedaan antara zpool-attach(8) dan zpool-replace(8), dan zfs list -t all -o space menunjukkan ruang dipakai untuk apa
    Untuk melindungi sistem operasi sebelum perubahan besar atau upgrade, ZFS Boot Environments adalah fitur terbaik. Sebagai titik awal, https://is.gd/BECTL bisa berguna
    zpool history poolname menampilkan seluruh konfigurasi pool dan riwayat perubahannya. Misalnya perubahan seperti zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m akan tercatat
    Ada juga informasi penting yang tidak dibahas di panduan. Mirror 3-way tetap menyimpan data meski 2 dari 3 disk rusak, mirror 4-way tetap menyimpan data meski 3 dari 4 disk rusak, dan mirror N-way menjaga data tetap tersimpan meski N-1 dari N disk rusak
    Ini berguna saat data adalah yang paling penting tetapi slot atau disk tidak banyak

    • Mirror N-way juga punya sifat bahwa ZFS dapat membagi proses baca ke beberapa disk. Pada disk berputar yang jumlah operasi I/O-nya terbatas, hal ini cukup penting

  • Selama bertahun-tahun menjalankan database PostgreSQL berukuran besar, multi-TB, di ZFS. Berkat ZFS, backup, pembuatan lingkungan pengujian berbasis snapshot lama, dan penghematan disk melalui kompresi bawaan menjadi sangat mudah
    Jika tertarik, pengalaman tersebut bisa dibaca di https://lackofimagination.org/2022/04/our-experience-with-po...

  • Yang paling membantu saat mulai memakai ZFS adalah ZFS Handbook dari FreeBSD dan tulisan Aaron Toponce
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • Saya suka dokumentasi FreeBSD
      Saya memasang FreeBSD di HP Microserver lama dengan ECC RAM 1 GB yang tergeletak, dan karena juga ada lima hard disk lama 500 GB, saya mengonfigurasinya sebagai mirror 5x sambil mengikuti FreeBSD Handbook. Itu pertama kalinya memakai FreeBSD, tetapi berjalan sangat lancar

  • Baru-baru ini, saat banyak membangun ulang infrastruktur yang sebagian besar berupa server LAMP, saya memutuskan semuanya berbasis ZFS di Linux demi replikasi backup dan enkripsi yang efisien
    Sejak lama saya sudah memakai ZFS bersama rsync untuk backup, jadi cukup terbiasa dan hasilnya baik, tetapi ketika mencoba melakukannya dengan benar, waktu yang dibutuhkan jauh lebih besar dari perkiraan. Terutama terkait database dan replikasi, ada banyak saran keliru di web
    Database setidaknya perlu tuning dasar seperti penyelarasan ukuran blok. Untuk mariadb/InnoDB, materi dari Let's Encrypt ini https://github.com/letsencrypt/openzfs-nvme-databases jauh lebih baik daripada yang lain. Nilainya besar karena setiap poin diberi alasan dan mengutip banyak sumber
    Jika mencari lebih jauh di web, akan muncul tanpa akhir saran yang saling bertentangan, anekdot, dan mitos yang tidak lengkap serta disertai teori tanpa dasar. Pada akhirnya kita harus menguji sendiri, memahami hal yang disetel, dan tidak apa-apa juga jika memutuskan untuk tidak menyetelnya
    Untuk replikasi, saya benar-benar menyarankan membaca halaman manual. ZFS menyediakan alat replikasi yang kuat, tetapi terlalu generik sehingga terasa seperti perintah plumbing tingkat rendah di Git. Karena tidak mengasumsikan akan dipakai lewat SSH, kita harus merangkainya sendiri, dan untuk otomatisasi harus memikirkan kondisi batas, sehingga awalnya terasa menakutkan
    Karena itu semua orang beralih ke alat seperti syncoid, tetapi ada hal mengerikan pada skrip replikasi sejenis syncoid. Mereka tidak memakai mode send --replication milik ZFS, melainkan mengimplementasikannya ulang secara tidak lengkap dalam Perl dengan alasan lebih fleksibel
    Saat pengujian awal, begitu memulihkan ulang lalu melihat semua root enkripsi rusak dan semua properti dataset tidak disinkronkan otomatis, rasanya menjengkelkan. Jika memakai opsi replikasi rekursif bawaan saja, ZFS akan menangani ini
    Jika bertekad menulis skrip sendiri, itu tidak sulit. Cukup jaga tetap sederhana dan jangan memasukkan banyak hal tidak perlu ke pipeline seperti syncoid. Dalam pengujian nyata, hal-hal semacam itu juga bisa memperlambat. Lihat progres dengan pv lalu dorong saja, maka akan berjalan cepat
    Mungkin suatu hari saya akan membuka skrip replikasi saya. Rasanya hampir tidak ada skrip referensi yang bagus yang menangani dasar-dasarnya tanpa mengimplementasikan ulang replikasi dengan berantakan

    • Materi itu menyebut tuning io_capacity dan io_capacity_max, tetapi jika membuka dokumentasi MySQL dan melihat peran parameter sebenarnya, sayangnya itu tidak terlalu berguna
      Nilai-nilai ini mengendalikan I/O latar belakang seperti penggabungan change buffer, dan bisa mengambil I/O dari proses utama yang benar-benar membutuhkan pekerjaan
      Berdasarkan pengalaman menjalankan DB MySQL yang cukup sibuk dengan 120K QPS, keduanya tidak perlu disentuh. Jika merasa perlu, sebaiknya pantau dulu waktu hingga redo log penuh dan rasio dirty page di buffer pool. Kemungkinan lebih baik menyetel parameter lain
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Saat melakukan tuning dasar seperti penyelarasan ukuran blok pada database, ada hal yang secara mengejutkan perlu diperiksa. Biasanya orang menyarankan menyesuaikan ukuran record, dan dalam praktiknya ini mengarah pada pengecilan ukuran record filesystem ZFS yang menyimpan data
      Pada level tertentu ini mungkin lebih efisien, tetapi berdasarkan pengalaman, ini sangat menurunkan rasio kompresi
      Efek samping menariknya, tergantung workload, jika bandwidth disk menjadi bottleneck, throughput justru bisa memburuk. Berkat kompresi, kita bisa membaca dan menulis lebih cepat daripada yang mampu ditangani disk fisik, tetapi jika kompresinya dirusak, bandwidth baca/tulis bisa terdampak buruk

  • Beberapa tahun lalu saya mulai memakai ZFS di Linux, dan secara keseluruhan berjalan mulus
    Satu-satunya hal yang mengejutkan adalah nilai default volblocksize ternyata cukup buruk untuk sebagian besar konfigurasi RAIDZ. Kalau tidak ingin kehilangan 50% ruang disk mentah, nilainya harus diperbesar
    Artikel terkait sebagai berikut
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    Pada akhirnya saya bahkan sampai melihat salah satu spreadsheet terkait ZFS
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Secara pribadi, menurut saya efisiensi 50% pada mirror vdev adalah harga yang wajar jika mempertimbangkan kesederhanaan dan peningkatan performa yang besar. Sekarang pool RAIDZ juga bisa diperluas, tetapi tetap jauh lebih kompleks dan performanya tidak sebaik itu

  • Saat masih muda dan lebih ceroboh, saya membaca banyak tulisan dari para penggemar berat tentang betapa hebatnya OS NAS open source, mungkin FreeNAS, dan ZFS. Saya membeli server mikro HP bekas berspesifikasi sangat rendah di eBay, lalu langsung terjun tanpa benar-benar tahu apa yang saya lakukan
    Saya mengajukan beberapa pertanyaan di forum komunitas, tetapi sebagian besar jawabannya adalah “sudah baca dokumentasinya?”, “RAM-nya cukup?”
    Yang disebut dokumentasi itu adalah materi presentasi PowerPoint dengan gaya yang sulit dibaca, nadanya agak seperti evangelis, mengasumsikan banyak pengetahuan sebelumnya, dan juga tidak diperbarui secara rutin. Jumlah RAM yang dibutuhkan juga samar, dan fokusnya hanya memasang sebanyak mungkin
    Pada akhirnya saya mengabaikan semua tanda bahaya terkait teknologinya, hype-nya, dan tingkat pengetahuan saya sendiri, lalu kehilangan banyak data. Banyak pelajaran yang saya dapat

    • Saya penasaran kira-kira sudah berapa lama yang lalu itu. ZFS sudah ada sejak awal 2000-an, dan kalau tidak salah FreeNAS dimulai pada 2005
      Filesystem-nya sudah jauh lebih stabil, dan menurut saya dokumentasinya juga menjadi lebih jelas
      Meski begitu, karena lebih kuat dan lebih canggih daripada filesystem journaling tradisional seperti ext3, cara untuk menembak kaki sendiri juga jadi lebih banyak

  • Untuk catatan di kemudian hari, semua redundansi ZFS berada di lapisan vdev. zpool dibuat dari satu atau lebih vdev, dan dalam kondisi apa pun, jika satu saja vdev di dalam zpool hilang, zpool akan rusak permanen
    Secara historis, RAIDZ, yaitu parity RAID, tidak bisa diperluas dengan menambahkan disk. Satu-satunya cara memperbesar RAIDZ adalah mengganti setiap disk dalam array satu per satu dengan disk yang lebih besar, sambil berharap tidak ada disk yang gagal selama rebuild
    Dengan penilaian yang sangat amatir, saya hanya akan mempertimbangkan RAIDZ untuk kasus dengan jumlah disk banyak seperti RAIDZ2 atau RAIDZ3. Jika n<=6 dan anggaran memungkinkan, saya akan memakai beberapa mirror vdev. Di lingkungan produksi, metrik performa baca/tulis berbagai RAID perlu diteliti lebih lanjut

    • Mirror pool biasanya memang cara yang lebih aman
      Namun saya hanya bisa merekomendasikan RAIDZ1 jika ada backup seluruh site dan Anda cukup percaya pada kemampuan serta monitoring Anda sendiri
      Dalam kasus saya, ada pool drive 3x3, dan snapshot dikirim ke target backup yang berada beberapa U di bawahnya di rack. Target backup itu menyala setiap hari, memiliki pool drive 3x4, dan juga memakai RAIDZ1
      Jika sebuah drive di NAS gagal, rencananya saya segera menyalakan backup untuk menerima snapshot, lalu mengganti drive. Dengan begitu kemungkinan data hilang akibat drive kedua gagal saat resilvering bisa diminimalkan
      Tentu saja data yang benar-benar penting juga saya simpan di luar lokasi

  • Saya sedang mengalami masalah ZFS yang tidak saya pahami. Pada salah satu zpool, zpool status menampilkan daftar error yang terdeteksi, tetapi tidak muncul pada file; selalu hanya muncul pada snapshot, dan pada entri heksadesimal yang sepertinya mungkin snapshot yang sudah dihapus
    Jika snapshot yang ditandai error itu dihapus lalu zpool scrub dijalankan dua kali, error tersebut hilang dan scrub juga tidak menemukan error. zpool status tidak pernah menampilkan error pada perangkat mana pun
    Tidak ada error pada file, tidak ada error pada perangkat, dan tidak ada error terdeteksi saat scrub, tetapi saat berjalan, sekitar 12 “error” baru per hari muncul di zpool status. Saya tidak tahu bagaimana hal seperti ini bisa terjadi

    • Pertanyaan yang sangat bagus. Saya tidak punya waktu untuk mencari issue duplikatnya sekarang, tetapi Anda bisa mencari atau bertanya di mailing list https://zfsonlinux.topicbox.com/groups/zfs-discuss dan issue GitHub https://github.com/openzfs/zfs/issues
      Yang pertama terlihat aneh, tetapi itu adalah web frontend yang normal untuk mailing list tersebut
    • Saya mengalami masalah yang sama. Kadang file tampak rusak bukan hanya di snapshot, tetapi juga di versi file saat ini
      Tidak bisa dipindahkan atau dimodifikasi, hanya bisa dihapus. Saya sama sekali tidak tahu mengapa file-file ini bisa rusak. Untungnya semuanya hanya ISO Linux berukuran besar, jadi tidak terlalu fatal