Musim semi ini kita telah membahas beberapa topik pengantar, misalnya. и . Pada bagian kedua, kami bahkan berjanji untuk terus mempelajari kinerja berbagai topologi multi-disk di ZFS. Ini adalah sistem file generasi berikutnya yang sekarang digunakan di mana saja untuk .
Nah, hari ini adalah hari terbaik untuk mengenal ZFS, para pembaca yang penasaran. Ketahuilah bahwa dalam penilaian sederhana pengembang OpenZFS Matt Ahrens, "ini sangat sulit."
Namun sebelum kita membahas angkanya - dan saya berjanji akan ada - untuk semua varian konfigurasi ZFS delapan disk, kita perlu membicarakan tentang sebagai Secara umum, ZFS menyimpan data pada disk.
Zpool, vdev dan perangkat
Diagram kumpulan lengkap ini mencakup tiga vdev tambahan, satu untuk setiap kelas, dan empat untuk RAIDz2
Biasanya tidak ada alasan untuk membuat kumpulan jenis dan ukuran vdev yang tidak cocok - tetapi jika Anda mau, tidak ada yang menghentikan Anda untuk melakukannya
Untuk benar-benar memahami sistem file ZFS, Anda perlu melihat lebih dekat struktur sebenarnya. Pertama, ZFS menyatukan lapisan manajemen volume dan sistem file tradisional. Kedua, menggunakan mekanisme copy-on-write transaksional. Fitur-fitur ini berarti bahwa sistem ini secara struktural sangat berbeda dari sistem file konvensional dan susunan RAID. Kumpulan blok penyusun dasar pertama yang harus dipahami adalah kumpulan penyimpanan (zpool), perangkat virtual (vdev), dan perangkat nyata (perangkat).
zpool
Kumpulan penyimpanan zpool adalah struktur ZFS paling atas. Setiap kumpulan berisi satu atau lebih perangkat virtual. Pada gilirannya, masing-masing berisi satu atau lebih perangkat (perangkat) nyata. Kumpulan virtual adalah unit mandiri. Satu komputer fisik dapat berisi dua atau lebih kumpulan terpisah, namun masing-masing kumpulan sepenuhnya independen satu sama lain. Kumpulan tidak dapat berbagi perangkat virtual.
Redundansi ZFS berada pada tingkat perangkat virtual, bukan pada tingkat kumpulan. Sama sekali tidak ada redundansi di tingkat kumpulan—jika vdev atau vdev khusus hilang, seluruh kumpulan juga ikut hilang.
Kumpulan penyimpanan modern dapat bertahan dari hilangnya cache atau log perangkat virtual - meskipun mereka mungkin kehilangan sejumlah kecil data kotor jika kehilangan log vdev saat listrik padam atau sistem mogok.
Ada kesalahpahaman umum bahwa "garis data" ZFS ditulis di seluruh kumpulan. Ini tidak benar. Zpool bukanlah RAID0 yang lucu, ini lebih lucu dengan mekanisme distribusi variabel yang kompleks.
Sebagian besar, catatan didistribusikan di antara perangkat virtual yang tersedia sesuai dengan ruang kosong yang tersedia, jadi secara teori semuanya akan diisi pada waktu yang sama. Versi ZFS yang lebih baru memperhitungkan penggunaan (pembuangan) vdev saat ini - jika satu perangkat virtual jauh lebih sibuk dibandingkan perangkat lainnya (misalnya, karena beban baca), perangkat tersebut akan dilewati sementara untuk penulisan, meskipun memiliki rasio ruang kosong tertinggi .
Mekanisme deteksi daur ulang yang dibangun dalam metode alokasi tulis ZFS modern dapat mengurangi latensi dan meningkatkan throughput selama periode beban tinggi yang tidak biasa - namun hal ini tidak terjadi. kekuasaan penuh hingga pencampuran paksa HDD lambat dan SSD cepat dalam satu kumpulan. Kumpulan yang tidak setara tersebut akan tetap beroperasi pada kecepatan perangkat paling lambat, seolah-olah seluruhnya terdiri dari perangkat tersebut.
vdev
Setiap kumpulan penyimpanan terdiri dari satu atau lebih perangkat virtual (vdev). Pada gilirannya, setiap vdev menyertakan satu atau lebih perangkat nyata. Sebagian besar perangkat virtual digunakan untuk penyimpanan data sederhana, namun ada beberapa kelas pembantu vdev, termasuk CACHE, LOG, dan SPECIAL. Masing-masing jenis vdev ini dapat memiliki salah satu dari lima topologi: perangkat tunggal, RAIDz1, RAIDz2, RAIDz3, atau mirror.
RAIDz1, RAIDz2 dan RAIDz3 adalah varietas khusus dari apa yang orang-orang tua sebut sebagai RAID paritas ganda (diagonal). 1, 2 dan 3 mengacu pada berapa banyak blok paritas yang dialokasikan untuk setiap jalur data. Daripada memiliki disk terpisah untuk memberikan paritas, perangkat RAIDz virtual mendistribusikan paritas secara semi-merata ke seluruh disk. Array RAIDz dapat kehilangan disk sebanyak yang memiliki blok paritas; jika kehilangan yang lain, ia akan gagal dan mengambil kumpulan penyimpanan bersamanya.
Di perangkat virtual cermin (mirror vdev), setiap blok disimpan di setiap perangkat di vdev. Meskipun cermin dua lebar adalah yang paling umum, cermin dapat memuat perangkat dalam jumlah berapa pun—dalam instalasi besar, cermin tiga kali lipat sering digunakan untuk meningkatkan kinerja baca dan toleransi kesalahan. Cermin vdev dapat bertahan dari kegagalan apa pun selama setidaknya satu perangkat di vdev tetap beroperasi.
Vdev tunggal pada dasarnya berbahaya. Perangkat virtual seperti itu tidak akan bertahan dari satu kegagalan pun - dan jika digunakan sebagai penyimpanan atau vdev khusus, maka kegagalannya akan menyebabkan kehancuran seluruh kumpulan. Berhati-hatilah di sini.
CACHE, LOG, dan perangkat virtual SPECIAL dapat dibuat di salah satu topologi di atas - namun ingat bahwa kehilangan perangkat virtual KHUSUS berarti kehilangan kumpulan, jadi topologi redundan sangat disarankan.
alat
Ini mungkin istilah yang paling mudah untuk dipahami di ZFS - ini secara harfiah adalah perangkat akses acak blok. Ingatlah bahwa perangkat virtual terdiri dari perangkat individual, dan kumpulan terdiri dari perangkat virtual.
Disk, baik yang bersifat magnetis maupun solid state, adalah perangkat blok yang paling umum digunakan sebagai blok penyusun vdev. Namun, perangkat apa pun dengan deskriptor di /dev dapat digunakan - sehingga seluruh rangkaian RAID perangkat keras dapat digunakan sebagai perangkat terpisah.
File mentah sederhana adalah salah satu perangkat blok alternatif terpenting yang dapat digunakan untuk membuat vdev. Kumpulan tes dari adalah cara yang sangat mudah untuk memeriksa perintah kumpulan dan melihat berapa banyak ruang yang tersedia di kumpulan atau perangkat virtual dengan topologi tertentu.
Anda dapat membuat kumpulan pengujian dari file yang jarang hanya dalam beberapa detik - tetapi jangan lupa untuk menghapus seluruh kumpulan dan komponennya setelahnya
Katakanlah Anda menginginkan server delapan disk dan berencana menggunakan disk 10 TB (~9300 GiB) - namun Anda tidak yakin topologi mana yang paling sesuai dengan kebutuhan Anda. Pada contoh di atas, kami membangun kumpulan pengujian dari file yang jarang dalam hitungan detik - dan sekarang kami mengetahui bahwa RAIDz2 vdev yang terdiri dari delapan disk berukuran 10 TB menyediakan kapasitas yang dapat digunakan sebesar 50 TiB.
Perangkat kelas khusus lainnya adalah SPARE. Perangkat hot-swap, tidak seperti perangkat biasa, merupakan milik keseluruhan kumpulan, bukan milik satu perangkat virtual. Jika ada vdev di kumpulan yang gagal dan perangkat cadangan terhubung ke kumpulan dan tersedia, maka perangkat tersebut akan secara otomatis bergabung dengan vdev yang terpengaruh.
Setelah terhubung ke vdev yang terpengaruh, perangkat pengganti mulai menerima salinan atau rekonstruksi data yang seharusnya ada di perangkat yang hilang. Dalam RAID tradisional, hal ini disebut "pembangunan kembali", dan di ZFS disebut "perbaikan kembali".
Penting untuk dicatat bahwa perangkat pengganti tidak menggantikan perangkat yang rusak secara permanen. Ini hanya pengganti sementara untuk mengurangi waktu yang dibutuhkan vdev untuk terdegradasi. Setelah administrator mengganti perangkat vdev yang gagal, redundansi dikembalikan ke perangkat permanen tersebut, dan SPARE terputus dari vdev dan kembali menjadi cadangan untuk seluruh kumpulan.
Kumpulan data, blok, dan sektor
Rangkaian elemen dasar berikutnya yang perlu dipahami dalam perjalanan ZFS kami tidak terlalu berkaitan dengan perangkat keras, melainkan lebih berkaitan dengan cara data itu sendiri diatur dan disimpan. Kami melewatkan beberapa lapisan di sini - seperti metaslab - untuk menghindari detail yang berantakan sambil mempertahankan pemahaman tentang keseluruhan struktur.
Himpunan data
Saat pertama kali kita membuat kumpulan data, ini menunjukkan semua ruang kumpulan yang tersedia. Kemudian kami menetapkan kuota - dan mengubah titik pemasangan. Sihir!
Zvol sebagian besar hanyalah kumpulan data yang dilucuti dari lapisan sistem filenya, yang kami ganti di sini dengan sistem file ext4 yang sepenuhnya normal
Kumpulan data ZFS kira-kira sama dengan sistem file terpasang standar. Seperti sistem file biasa, sekilas tampak seperti “folder lain”. Namun sama seperti sistem file yang dipasang pada umumnya, setiap kumpulan data ZFS memiliki kumpulan properti dasarnya sendiri.
Pertama-tama, kumpulan data mungkin memiliki kuota yang ditetapkan. Jika Anda menginstal zfs set quota=100G poolname/datasetname, maka Anda tidak akan dapat menulis ke folder yang di-mount /poolname/datasetname lebih dari 100 GiB.
Perhatikan ada—dan tidak adanya—garis miring di awal setiap baris? Setiap kumpulan data memiliki tempatnya sendiri dalam hierarki ZFS dan hierarki pemasangan sistem. Tidak ada garis miring di hierarki ZFS - Anda memulai dengan nama kumpulan dan kemudian jalur dari satu kumpulan data ke kumpulan data berikutnya. Misalnya, pool/parent/child untuk kumpulan data bernama child di bawah kumpulan data induk parent di kolam dengan nama kreatif pool.
Secara default, titik pemasangan himpunan data akan setara dengan namanya di hierarki ZFS, dengan garis miring di depan - kumpulan diberi nama pool dipasang sebagai /pool, Himpunan data parent dipasang di /pool/parent, dan kumpulan data anak child dipasang di /pool/parent/child. Namun, titik pemasangan sistem kumpulan data dapat diubah.
Jika kami menunjukkan zfs set mountpoint=/lol pool/parent/child, lalu kumpulan data pool/parent/child dipasang ke dalam sistem sebagai /lol.
Selain kumpulan data, kami harus menyebutkan volume (zvols). Volume kira-kira sama dengan kumpulan data, hanya saja volume sebenarnya tidak memiliki sistem file—itu hanya perangkat blok. Misalnya, Anda dapat membuat zvol Dengan nama mypool/myzvol, lalu format dengan sistem file ext4, lalu pasang sistem file tersebut - sekarang Anda memiliki sistem file ext4, tetapi dengan semua fitur keamanan ZFS! Ini mungkin tampak konyol pada satu komputer, tetapi lebih masuk akal sebagai backend ketika mengekspor perangkat iSCSI.
Blok
Sebuah file diwakili oleh satu atau lebih blok. Setiap blok disimpan di satu perangkat virtual. Ukuran blok biasanya sama dengan parameter ukuran rekaman, tetapi dapat dikurangi menjadi 2^pergeseran, jika berisi metadata atau file kecil.
Kami sungguh benar-benar Kami tidak main-main dengan penalti performa yang besar jika Anda menetapkan perpindahan gigi terlalu rendah
Di kumpulan ZFS, semua data, termasuk metadata, disimpan dalam blok. Ukuran blok maksimum untuk setiap kumpulan data ditentukan di properti recordsize (ukuran catatan). Ukuran rekaman dapat berubah, namun hal ini tidak akan mengubah ukuran atau lokasi blok apa pun yang telah ditulis ke kumpulan data - ini hanya memengaruhi blok baru saat ditulis.
Kecuali ditentukan lain, ukuran entri default saat ini adalah 128 KiB. Ini semacam trade-off yang sulit di mana kinerjanya tidak akan sempurna, tetapi dalam banyak kasus tidak akan terlalu buruk. Recordsize dapat diatur ke nilai apa pun dari 4K hingga 1M (dengan pengaturan tambahan recordsize Anda dapat menginstal lebih banyak lagi, tetapi ini jarang merupakan ide yang bagus).
Blok apa pun mengacu pada data dari satu file saja—Anda tidak dapat memasukkan dua file berbeda ke dalam satu blok. Setiap file terdiri dari satu atau lebih blok, bergantung pada ukurannya. Jika ukuran file lebih kecil dari ukuran record, maka akan disimpan dalam blok yang lebih kecil - misalnya, blok dengan file 2 KiB hanya akan menempati satu sektor 4 KiB pada disk.
Jika file cukup besar sehingga memerlukan beberapa blok, maka semua entri ke file tersebut akan berukuran besar recordsize - termasuk entri terakhir, yang mungkin bagian utamanya .
volume zvol tidak memiliki properti recordsize - sebaliknya mereka memiliki properti yang setara volblocksize.
Sektor
Komponen terakhir yang paling mendasar adalah sektor ini. Ini adalah unit fisik terkecil yang dapat ditulis atau dibaca dari perangkat host. Selama beberapa dekade, sebagian besar disk menggunakan sektor 512-byte. Saat ini, sebagian besar drive dikonfigurasikan untuk 4 sektor KiB, dan beberapa - terutama SSD - dikonfigurasi untuk 8 sektor KiB atau bahkan lebih besar.
ZFS memiliki fitur yang memungkinkan Anda mengatur ukuran sektor secara manual. Properti ini ashift. Agak membingungkan, ashift adalah kekuatan dua. Misalnya, ashift=9 berarti ukuran sektor 2^9, atau 512 byte.
ZFS meminta sistem operasi untuk informasi rinci tentang setiap perangkat blok ketika ditambahkan ke vdev baru, dan secara teoritis secara otomatis menetapkan pergeseran yang tepat berdasarkan informasi tersebut. Sayangnya, banyak drive yang berbohong tentang ukuran sektornya demi menjaga kompatibilitas dengan Windows XP (yang tidak dapat memahami drive dengan ukuran sektor lain).
Artinya sangat disarankan agar administrator ZFS mengetahui ukuran sektor sebenarnya dari perangkat mereka dan mengaturnya secara manual ashift. Jika ashift diatur terlalu kecil, jumlah operasi baca/tulis akan meningkat secara drastis. Jadi, menulis "sektor" 512 byte ke sektor 4 KiB nyata berarti harus menulis "sektor" pertama, lalu membaca sektor 4 KiB, memodifikasinya dengan "sektor" 512 byte kedua, menulisnya kembali ke yang baru 4 sektor KiB, dan seterusnya untuk setiap entri.
Di dunia nyata, hukuman seperti itu berdampak pada SSD Samsung EVO, yang harus diterapkan ashift=13, namun SSD ini berbohong tentang ukuran sektornya, dan karena itu defaultnya disetel ke ashift=9. Kecuali jika administrator sistem berpengalaman mengubah pengaturan ini, SSD ini akan berfungsi lebih lambat HDD magnetik biasa.
Sebagai perbandingan, karena terlalu besar ashift hampir tidak ada penalti. Tidak ada peningkatan kinerja yang nyata, dan peningkatan ruang yang tidak terpakai sangat kecil (atau nol jika kompresi diaktifkan). Oleh karena itu, kami sangat menyarankan agar drive yang menggunakan sektor 512 byte pun diinstal ashift=12 atau bahkan ashift=13untuk menatap masa depan dengan percaya diri.
Properti ashift diinstal untuk setiap perangkat virtual vdev, dan bukan untuk kolam renang, seperti yang dipikirkan banyak orang secara keliru - dan tidak berubah setelah instalasi. Jika Anda tidak sengaja memukul ashift Saat Anda menambahkan vdev baru ke kumpulan, Anda telah mencemari kumpulan tersebut dengan perangkat berkinerja rendah dan, sebagai aturan, tidak ada pilihan lain selain menghancurkan kumpulan tersebut dan memulai kembali. Bahkan menghapus vdev tidak akan menyelamatkan Anda dari pengaturan yang rusak ashift!
Mekanisme copy-on-write
Jika sistem file biasa perlu menulis ulang data, ia akan memodifikasi setiap blok di mana data tersebut berada
Sistem file copy-on-write menulis blok versi baru dan kemudian membuka kunci versi lama
Secara abstrak, jika kita mengabaikan susunan fisik blok yang sebenarnya, “komet data” kita disederhanakan menjadi “worm data” yang bergerak dari kiri ke kanan melintasi peta ruang yang tersedia.
Sekarang kita bisa mendapatkan gambaran bagus tentang cara kerja snapshot copy-on-write - setiap blok dapat dimiliki oleh beberapa snapshot, dan akan bertahan hingga semua snapshot terkait dimusnahkan
Mekanisme Copy on Write (CoW) adalah dasar fundamental yang membuat ZFS menjadi sistem yang luar biasa. Konsep dasarnya sederhana - jika Anda meminta sistem file tradisional untuk mengubah file, sistem tersebut akan melakukan persis seperti yang Anda minta. Jika Anda meminta sistem file copy-on-write untuk melakukan hal yang sama, ia akan mengatakan “oke”—tetapi ia berbohong kepada Anda.
Sebaliknya, sistem file copy-on-write menulis versi baru dari blok yang dimodifikasi, dan kemudian memperbarui metadata file untuk memutuskan tautan blok lama dan mengaitkannya dengan blok baru yang baru saja Anda tulis.
Memutuskan tautan blok lama dan menautkan blok baru dilakukan dalam satu operasi, sehingga tidak dapat diganggu - jika Anda menyetel ulang daya setelah ini terjadi, Anda memiliki versi file baru, dan jika Anda menyetel ulang daya sebelumnya, maka Anda punya versi lama. Bagaimanapun, tidak akan ada konflik dalam sistem file.
Copy-on-write di ZFS terjadi tidak hanya di tingkat sistem file, tetapi juga di tingkat manajemen disk. Ini berarti ZFS tidak rentan terhadap spasi dalam catatan () - sebuah fenomena ketika strip hanya direkam sebagian sebelum sistem mogok, dengan kerusakan pada array setelah reboot. Di sini stripe ditulis secara atom, vdev selalu berurutan, dan .
ZIL: Log maksud ZFS
ZFS menangani penulisan sinkron dengan cara khusus - ia menyimpannya sementara tetapi segera di ZIL sebelum kemudian menulisnya secara permanen bersama dengan penulisan asinkron.
Biasanya, data yang ditulis ke ZIL tidak pernah dibaca lagi. Tapi ini mungkin terjadi setelah kegagalan sistem
SLOG, atau perangkat LOG sekunder, hanyalah vdev khusus - dan sebaiknya sangat cepat - di mana ZIL dapat disimpan secara terpisah dari penyimpanan utama
Setelah crash, semua data kotor di ZIL diputar ulang - dalam hal ini, ZIL ada di SLOG, jadi di situlah data tersebut diputar ulang
Ada dua kategori utama penulisan: sinkron (sinkronisasi) dan asinkron (async). Untuk sebagian besar beban kerja, sebagian besar penulisan dilakukan secara asinkron - sistem file memungkinkan penulisan dilakukan secara agregasi dan diterbitkan dalam batch, sehingga mengurangi fragmentasi dan meningkatkan throughput secara signifikan.
Rekaman sinkron adalah masalah yang sama sekali berbeda. Saat aplikasi meminta penulisan sinkron, aplikasi memberitahu sistem file: "Anda perlu melakukan ini ke memori non-volatile sekarang juga, dan sampai saat itu tidak ada lagi yang dapat saya lakukan.” Oleh karena itu, penulisan sinkron harus segera dilakukan ke disk - dan jika hal ini meningkatkan fragmentasi atau mengurangi throughput, biarlah.
ZFS menangani penulisan sinkron secara berbeda dari sistem file biasa—alih-alih langsung memindahkannya ke penyimpanan biasa, ZFS memasukkannya ke area penyimpanan khusus yang disebut ZFS Intent Log, atau ZIL. Triknya adalah catatan-catatan ini juga tetap berada di memori, dikumpulkan bersama dengan permintaan tulis asinkron normal, untuk kemudian dimasukkan ke dalam penyimpanan sebagai TXG (Grup Transaksi) yang sepenuhnya normal.
Selama pengoperasian normal, ZIL ditulis dan tidak pernah dibaca lagi. Ketika, setelah beberapa saat, catatan dari ZIL dimasukkan ke penyimpanan utama di TXG biasa dari RAM, catatan tersebut akan terlepas dari ZIL. Satu-satunya saat sesuatu dibaca dari ZIL adalah saat mengimpor kumpulan.
Jika terjadi kegagalan ZFS—sistem operasi mogok atau pemadaman listrik—saat ada data di ZIL, data tersebut akan dibaca selama impor kumpulan berikutnya (misalnya, saat sistem failover dimulai ulang). Apa pun yang ada di ZIL akan dibaca, dikelompokkan ke dalam TXG, dimasukkan ke penyimpanan utama, dan kemudian dilepaskan dari ZIL selama proses impor.
Salah satu kelas pembantu vdev disebut LOG atau SLOG, perangkat LOG sekunder. Ia memiliki satu tugas - untuk menyediakan kumpulan perangkat vdev yang terpisah dan, lebih disukai, jauh lebih cepat, dengan resistensi tulis yang sangat tinggi untuk menyimpan ZIL, daripada menyimpan ZIL di penyimpanan vdev utama. ZIL sendiri berperilaku sama terlepas dari lokasi penyimpanannya, tetapi jika vdev dengan LOG memiliki kinerja penulisan yang sangat tinggi, maka penulisan sinkron akan lebih cepat.
Menambahkan vdev dengan LOG ke kumpulan tidak berfungsi tidak bisa meningkatkan kinerja penulisan asinkron - bahkan jika Anda memaksa semua penulisan ke ZIL dengan zfs set sync=always, mereka akan tetap ditautkan ke penyimpanan utama di TXG dengan cara dan kecepatan yang sama seperti tanpa log. Satu-satunya peningkatan kinerja langsung adalah latensi penulisan sinkron (karena kecepatan log yang lebih tinggi membuat pengoperasian lebih cepat sync).
Namun, dalam lingkungan yang sudah memerlukan banyak penulisan sinkron, vdev LOG secara tidak langsung dapat mempercepat penulisan asinkron dan pembacaan yang tidak di-cache. Membongkar catatan ZIL ke vdev LOG terpisah berarti lebih sedikit perselisihan untuk IOPS pada penyimpanan utama, sehingga meningkatkan kinerja semua pembacaan dan penulisan sampai batas tertentu.
Jepretan
Mekanisme copy-on-write juga merupakan landasan yang diperlukan untuk snapshot atom ZFS dan replikasi asinkron tambahan. Sistem file aktif memiliki pohon penunjuk yang menandai semua entri dengan data saat ini - saat Anda mengambil snapshot, Anda cukup membuat salinan pohon penunjuk ini.
Ketika catatan ditimpa pada sistem file aktif, ZFS pertama-tama menulis versi baru dari blok tersebut ke ruang yang tidak terpakai. Kemudian lepaskan blok versi lama dari sistem file saat ini. Namun jika beberapa snapshot mereferensikan blok lama, maka snapshot tersebut tetap tidak berubah. Blok lama tidak akan benar-benar dipulihkan sebagai ruang kosong sampai semua snapshot yang merujuk pada blok tersebut dimusnahkan!
replikasi
Perpustakaan Steam saya pada tahun 2015 adalah 158 GiB dan mencakup 126 file. Ini mendekati situasi optimal untuk rsync - replikasi ZFS melalui jaringan "hanya" 927% lebih cepat.
Di jaringan yang sama, mereplikasi satu file image mesin virtual Windows 40 berukuran 7 GB adalah cerita yang sangat berbeda. Replikasi ZFS 289 kali lebih cepat daripada rsync—atau "hanya" 161 kali lebih cepat jika Anda cukup paham untuk memanggil rsync dengan tombol --inplace.
Saat gambar VM diskalakan, masalah rsync akan diskalakan. Ukuran 1,9 TiB tidak terlalu besar untuk image VM modern—tetapi cukup besar sehingga replikasi ZFS 1148 kali lebih cepat dibandingkan rsync, bahkan dengan argumen rsync --inplace
Setelah Anda memahami cara kerja snapshot, akan mudah untuk memahami esensi replikasi. Karena snapshot hanyalah sebuah pohon penunjuk rekaman, maka hal tersebut akan terjadi jika kita melakukannya zfs send snapshot, lalu kami mengirimkan pohon ini dan semua catatan yang terkait dengannya. Ketika kita melewati ini zfs send в zfs receive pada objek target, ia menulis konten sebenarnya dari blok dan pohon penunjuk yang mereferensikan blok ke kumpulan data target.
Segalanya menjadi lebih menarik pada detik kedua zfs send. Kami sekarang memiliki dua sistem, masing-masing berisi poolname/datasetname@1, dan Anda mengambil snapshot baru poolname/datasetname@2. Oleh karena itu, di kumpulan sumber yang Anda miliki datasetname@1 и datasetname@2, dan di kumpulan target hanya ada snapshot pertama datasetname@1.
Karena antara sumber dan target kita mempunyai gambaran yang sama datasetname@1, kita bisa melakukannya tambahan zfs send di atasnya. Saat kami memberi tahu sistem zfs send -i poolname/datasetname@1 poolname/datasetname@2, ini membandingkan dua pohon penunjuk. Petunjuk apa pun yang hanya ada di @2, jelas mengacu pada blok baru - jadi kita memerlukan konten blok tersebut.
Pada sistem jarak jauh, pemrosesan bersifat inkremental send sesederhana itu. Pertama kita menulis semua entri baru yang termasuk dalam aliran send, lalu tambahkan pointer ke blok ini. Voila, sudah @2 dalam sistem baru!
Replikasi tambahan asinkron ZFS merupakan peningkatan besar dibandingkan metode berbasis non-snapshot sebelumnya seperti rsync. Dalam kedua kasus tersebut, hanya data yang diubah yang ditransfer - tetapi rsync harus terlebih dahulu Baca dari disk semua data di kedua sisi untuk memeriksa jumlah dan membandingkannya. Sebaliknya, replikasi ZFS tidak membaca apa pun selain pohon penunjuk—dan blok apa pun yang tidak terwakili dalam keseluruhan snapshot.
Kompresi bawaan
Mekanisme copy-on-write juga menyederhanakan sistem kompresi bawaan. Dalam sistem file tradisional, kompresi menjadi masalah - versi lama dan versi baru dari data yang diubah berada dalam ruang yang sama.
Jika Anda menganggap sepotong data di tengah file yang memulai hidupnya sebagai megabyte nol dari 0x00000000 dan seterusnya - sangat mudah untuk mengompresnya menjadi satu sektor pada disk. Namun apa yang terjadi jika kita mengganti megabyte angka nol ini dengan satu megabyte data yang tidak dapat dikompresi, seperti JPEG atau noise pseudo-random? Tiba-tiba, megabyte data tersebut memerlukan bukan hanya satu, melainkan 256 4 sektor KiB, dan hanya satu sektor yang dicadangkan dalam ruang disk tersebut.
ZFS tidak memiliki masalah ini, karena catatan yang dimodifikasi selalu ditulis ke ruang yang tidak terpakai - blok asli hanya membutuhkan satu sektor 4 KiB, dan penulisan baru akan memakan 256, tetapi ini bukan masalah - sebuah fragmen yang baru saja dimodifikasi dari bagian "tengah" file akan ditulis ke ruang yang tidak terpakai terlepas dari apakah ukurannya berubah atau tidak, jadi ini adalah situasi yang sepenuhnya normal untuk ZFS.
Kompresi ZFS bawaan dinonaktifkan secara default, dan sistem menawarkan algoritme yang dapat dicolokkan - saat ini termasuk LZ4, gzip (1-9), LZJB, dan ZLE.
- LZ4 adalah algoritma streaming yang menawarkan kompresi dan dekompresi yang sangat cepat serta manfaat kinerja untuk sebagian besar kasus penggunaan - bahkan pada CPU yang cukup lambat.
- GZIP adalah algoritme terhormat yang diketahui dan disukai semua pengguna Unix. Algoritme ini dapat diimplementasikan dengan tingkat kompresi 1-9, dengan peningkatan rasio kompresi dan penggunaan CPU saat Anda mendekati level 9. Algoritme ini cocok untuk semua kasus penggunaan teks (atau kasus penggunaan lainnya yang sangat dapat dikompres), tetapi sering kali menyebabkan masalah CPU - gunakanlah dengan hati-hati, terutama pada level yang lebih tinggi.
- LZJB - algoritma asli di ZFS. Sudah usang dan tidak boleh digunakan lagi, LZ4 lebih unggul dalam segala hal.
- ZLE — pengkodean tingkat nol, pengkodean tingkat nol. Itu tidak menyentuh data normal sama sekali, tetapi memampatkan sejumlah besar angka nol. Berguna untuk kumpulan data yang sepenuhnya tidak dapat dimampatkan (seperti JPEG, MP4, atau format lain yang sudah dikompresi) karena mengabaikan data yang tidak dapat dimampatkan tetapi memampatkan ruang yang tidak terpakai dalam rekaman yang dihasilkan.
Kami merekomendasikan kompresi LZ4 untuk hampir semua kasus penggunaan; penalti kinerja ketika menangani data yang tidak dapat dimampatkan sangat kecil, dan pertumbuhan kinerja untuk data tipikal adalah signifikan. Menyalin gambar mesin virtual untuk instalasi baru sistem operasi Windows (OS yang baru diinstal, belum ada data di dalamnya) dengan compression=lz4 melewati 27% lebih cepat dibandingkan dengan compression=noneDi .
ARC - cache pengganti adaptif
ZFS adalah satu-satunya sistem file modern yang kami ketahui yang menggunakan mekanisme cache bacanya sendiri, daripada mengandalkan cache halaman sistem operasi untuk menyimpan salinan blok yang baru dibaca di RAM.
Meskipun cache asli bukannya tanpa masalah - ZFS tidak dapat merespons permintaan alokasi memori baru secepat kernel, jadi panggilan baru malloc() alokasi memori mungkin gagal jika memerlukan RAM yang saat ini ditempati oleh ARC. Namun ada alasan bagus untuk menggunakan cache Anda sendiri, setidaknya untuk saat ini.
Semua sistem operasi modern yang dikenal, termasuk MacOS, Windows, Linux dan BSD, menggunakan algoritma LRU (Least Almost Used) untuk mengimplementasikan cache halaman. Ini adalah algoritma primitif yang mendorong blok cache "ke bagian atas antrian" setelah setiap pembacaan dan mendorong blok "ke bagian bawah antrian" sesuai kebutuhan untuk menambahkan cache baru yang hilang (blok yang seharusnya dibaca dari disk, bukan dari disk). dari cache) ke atas.
Biasanya algoritme bekerja dengan baik, namun pada sistem dengan kumpulan data kerja yang besar, LRU dengan mudah menyebabkan thrashing—mengusir blok-blok yang sering dibutuhkan untuk memberikan ruang bagi blok-blok yang tidak akan pernah dibaca lagi dari cache.
adalah algoritme yang tidak terlalu naif yang dapat dianggap sebagai cache “tertimbang”. Setiap kali blok cache dibaca, blok tersebut menjadi sedikit lebih berat dan sulit untuk dikeluarkan - dan bahkan setelah blok tersebut dikeluarkan dilacak dalam jangka waktu tertentu. Sebuah blok yang telah dikeluarkan tetapi kemudian perlu dibaca kembali ke dalam cache juga akan menjadi lebih berat.
Hasil akhir dari semua ini adalah cache dengan rasio hit yang jauh lebih tinggi—rasio antara cache hits (dibaca dari cache) dan miss (dibaca dari disk). Ini adalah statistik yang sangat penting - tidak hanya cache yang berhasil dilayani dengan urutan besarnya lebih cepat, cache yang hilang juga dapat dilayani lebih cepat, karena semakin banyak cache yang ditemukan, semakin sedikit permintaan paralel ke disk dan semakin rendah latensi untuk kesalahan yang tersisa. yang harus dilayani dengan disk.
Kesimpulan
Sekarang kita telah membahas semantik dasar ZFS—cara kerja copy-on-write, serta hubungan antara kumpulan penyimpanan, perangkat virtual, blok, sektor, dan file—kita siap mendiskusikan kinerja dunia nyata dengan bilangan real.
Pada bagian selanjutnya, kita akan melihat kinerja sebenarnya dari kumpulan vdev dan RAIDz yang dicerminkan, dibandingkan satu sama lain, dan juga dibandingkan dengan topologi RAID kernel Linux tradisional yang telah kita periksa. .
Pada awalnya kami hanya ingin membahas dasar-dasarnya - topologi ZFS itu sendiri - tetapi setelahnya seperti itu Kami akan siap berbicara tentang konfigurasi dan penyetelan ZFS yang lebih canggih, termasuk penggunaan tipe vdev tambahan seperti L2ARC, SLOG, dan Alokasi Khusus.
Sumber: www.habr.com