Musim bunga ini kami telah membincangkan beberapa topik pengenalan, mis. и . Dalam kedua ini, kami juga berjanji untuk terus mengkaji prestasi pelbagai topologi berbilang cakera dalam ZFS. Ini adalah sistem fail generasi akan datang yang kini digunakan di mana-mana dari kepada .
Nah, hari ini adalah hari terbaik untuk berkenalan dengan ZFS, pembaca yang ingin tahu. Hanya tahu bahawa dalam penilaian sederhana pemaju OpenZFS Matt Ahrens, "ia benar-benar sukar."
Tetapi sebelum kita sampai ke nombor-dan akan ada, saya berjanji-untuk semua pilihan konfigurasi ZFS lapan cakera, kita perlu bercakap tentang sebagai Secara umum, ZFS menyimpan data pada cakera.
Zpool, vdev dan peranti
Gambar rajah kolam penuh ini termasuk tiga vdev tambahan, satu daripada setiap kelas dan empat untuk RAIDz2
Biasanya tiada sebab untuk mencipta kumpulan jenis dan saiz vdev yang tidak sepadan - tetapi jika anda mahu, tiada apa yang menghalang anda daripada berbuat demikian
Untuk benar-benar memahami sistem fail ZFS, anda perlu melihat dengan teliti struktur sebenarnya. Pertama, ZFS menyatukan volum tradisional dan lapisan pengurusan sistem fail. Kedua, ia menggunakan mekanisme copy-on-write transaksi. Ciri-ciri ini bermakna sistem ini secara strukturnya sangat berbeza daripada sistem fail konvensional dan tatasusunan RAID. Set pertama blok binaan asas yang perlu difahami ialah kolam storan (zpool), peranti maya (vdev) dan peranti sebenar (peranti).
zpool
Kolam simpanan zpool ialah struktur ZFS paling atas. Setiap kolam mengandungi satu atau lebih peranti maya. Sebaliknya, setiap daripadanya mengandungi satu atau lebih peranti sebenar (peranti). Kolam maya ialah unit serba lengkap. Satu komputer fizikal boleh mengandungi dua atau lebih kumpulan berasingan, tetapi setiap satu adalah bebas sepenuhnya daripada yang lain. Pools tidak boleh berkongsi peranti maya.
Lebihan ZFS berada pada tahap peranti maya, bukan pada tahap kumpulan. Sama sekali tidak ada lebihan di peringkat kolam—jika vdev atau vdev khusus hilang, keseluruhan kolam hilang bersama-sama dengannya.
Kolam storan moden boleh bertahan daripada kehilangan cache atau log peranti maya - walaupun mereka mungkin kehilangan sejumlah kecil data kotor jika kehilangan log vdev semasa gangguan kuasa atau sistem ranap.
Terdapat salah tanggapan umum bahawa "jalur data" ZFS ditulis di seluruh kumpulan. Ini tidak benar. Zpool bukan RAID0 yang kelakar, ia lebih kepada RAIDXNUMX yang kelakar dengan mekanisme pengedaran pembolehubah yang kompleks.
Untuk sebahagian besar, rekod diedarkan di antara peranti maya yang tersedia mengikut ruang kosong yang tersedia, jadi secara teori semuanya akan diisi pada masa yang sama. Versi ZFS yang lebih terkini mengambil kira penggunaan (penggunaan) vdev semasa - jika satu peranti maya jauh lebih sibuk daripada yang lain (contohnya, disebabkan beban baca), ia akan dilangkau buat sementara waktu untuk menulis, walaupun mempunyai nisbah ruang kosong tertinggi.
Mekanisme pengesanan kitar semula yang terbina dalam kaedah peruntukan tulis ZFS moden boleh mengurangkan kependaman dan meningkatkan daya pengeluaran semasa tempoh beban yang luar biasa tinggi—tetapi tidak. carte blanche kepada pencampuran tanpa sengaja HDD perlahan dan SSD pantas dalam satu kumpulan. Kumpulan yang tidak sama rata itu masih akan beroperasi pada kelajuan peranti yang paling perlahan, iaitu, seolah-olah ia sepenuhnya terdiri daripada peranti sedemikian.
vdev
Setiap kumpulan storan terdiri daripada satu atau lebih peranti maya (vdev). Seterusnya, setiap vdev termasuk satu atau lebih peranti sebenar. Kebanyakan peranti maya digunakan untuk penyimpanan data ringkas, tetapi terdapat beberapa kelas pembantu vdev, termasuk CACHE, LOG dan KHAS. Setiap jenis vdev ini boleh mempunyai satu daripada lima topologi: peranti tunggal, RAIDz1, RAIDz2, RAIDz3 atau cermin.
RAIDz1, RAIDz2 dan RAIDz3 ialah jenis istimewa dari apa yang orang lama panggil RAID pariti dua (pepenjuru). 1, 2 dan 3 merujuk kepada bilangan blok pariti yang diperuntukkan kepada setiap lorong data. Daripada mempunyai cakera yang berasingan untuk menyediakan pariti, peranti RAIDz maya mengedarkan pariti secara separa merentasi cakera. Tatasusunan RAIDz boleh kehilangan seberapa banyak cakera kerana ia mempunyai blok pariti; jika ia kehilangan satu lagi, ia akan gagal dan mengambil kolam simpanan bersamanya.
Dalam peranti maya cermin (mirror vdev), setiap blok disimpan pada setiap peranti dalam vdev. Walaupun cermin dua lebar adalah yang paling biasa, cermin boleh mempunyai sebarang bilangan peranti yang sewenang-wenangnya—dalam pemasangan yang lebih besar, tiga kali ganda sering digunakan untuk meningkatkan prestasi bacaan dan toleransi kesalahan. Cermin vdev boleh bertahan dalam sebarang kegagalan selagi sekurang-kurangnya satu peranti dalam vdev kekal beroperasi.
Vdev tunggal sememangnya berbahaya. Peranti maya sedemikian tidak akan bertahan dalam satu kegagalan - dan jika digunakan sebagai storan atau vdev khas, maka kegagalannya akan membawa kepada kemusnahan keseluruhan kolam. Berhati-hatilah di sini.
CACHE, LOG dan peranti maya KHAS boleh dibuat dalam mana-mana topologi di atas - tetapi ingat bahawa kehilangan peranti maya KHAS bermakna kehilangan kumpulan, jadi topologi berlebihan amat disyorkan.
peranti
Ini mungkin istilah yang paling mudah untuk difahami dalam ZFS - ia sebenarnya adalah peranti capaian rawak blok. Ingat bahawa peranti maya terdiri daripada peranti individu dan kumpulan dibuat daripada peranti maya.
Cakera, sama ada keadaan magnet atau pepejal, ialah peranti blok yang paling biasa digunakan sebagai blok binaan vdev. Walau bagaimanapun, mana-mana peranti dengan deskriptor dalam /dev akan melakukannya - jadi keseluruhan tatasusunan RAID perkakasan boleh digunakan sebagai peranti individu.
Fail mentah yang ringkas ialah salah satu peranti blok alternatif yang paling penting dari mana vdev boleh dibina. Kumpulan ujian daripada ialah cara yang sangat mudah untuk menyemak arahan kumpulan dan melihat jumlah ruang yang tersedia dalam kumpulan atau peranti maya topologi tertentu.
Anda boleh mencipta kumpulan ujian daripada fail jarang dalam beberapa saat sahaja - tetapi jangan lupa untuk memadamkan keseluruhan kumpulan dan komponennya selepas itu
Katakan anda mahukan pelayan lapan cakera dan merancang untuk menggunakan cakera 10TB (~9300 GiB), tetapi anda tidak pasti topologi mana yang paling sesuai dengan keperluan anda. Dalam contoh di atas, kami membina kumpulan ujian bagi fail yang jarang dalam beberapa saat—dan kini mengetahui bahawa RAIDz2 vdev daripada lapan pemacu 10TB menyediakan 50TiB kapasiti yang boleh digunakan.
Satu lagi kelas peranti khas ialah SPARE. Peranti hot-swap, tidak seperti peranti biasa, tergolong dalam keseluruhan kumpulan dan bukannya satu peranti maya. Jika mana-mana vdev dalam kolam gagal dan peranti ganti disambungkan ke kolam dan tersedia, maka ia akan menyertai vdev yang terjejas secara automatik.
Setelah disambungkan ke vdev yang terjejas, peranti gantian mula menerima salinan atau pembinaan semula data yang sepatutnya ada pada peranti yang hilang. Dalam RAID tradisional ini dipanggil "membina semula", dan dalam ZFS ia adalah "resolving".
Adalah penting untuk ambil perhatian bahawa peranti gantian tidak menggantikan peranti yang gagal secara kekal. Ini hanyalah pengganti sementara untuk mengurangkan masa yang diperlukan untuk vdev merendahkan. Selepas pentadbir menggantikan peranti vdev yang gagal, redundansi dipulihkan kepada peranti kekal itu dan SPARE diputuskan sambungan daripada vdev dan kembali menjadi alat ganti untuk keseluruhan kumpulan.
Set data, blok dan sektor
Set blok binaan seterusnya untuk difahami dalam perjalanan ZFS kami kurang berkaitan dengan perkakasan dan lebih berkaitan dengan cara data itu sendiri disusun dan disimpan. Kami melangkau beberapa lapisan di sini - seperti metaslab - untuk mengelakkan kekacauan butiran sambil mengekalkan pemahaman tentang struktur keseluruhan.
Set data
Apabila kami mula-mula membuat set data, ia menunjukkan semua ruang kumpulan yang tersedia. Kemudian kami tetapkan kuota - dan tukar titik pelekap. Sihir!
Zvol kebanyakannya hanyalah set data yang dilucutkan daripada lapisan sistem failnya, yang kami gantikan di sini dengan sistem fail ext4 yang normal sepenuhnya
Set data ZFS adalah lebih kurang sama dengan sistem fail yang dipasang standard. Seperti sistem fail biasa, pada pandangan pertama ia kelihatan seperti "hanya folder lain." Tetapi sama seperti sistem fail yang dipasang biasa, setiap set data ZFS mempunyai set sifat asasnya sendiri.
Pertama sekali, set data mungkin mempunyai kuota yang ditetapkan. Jika anda memasang zfs set quota=100G poolname/datasetname, maka anda tidak akan dapat menulis ke folder yang dipasang /poolname/datasetname lebih daripada 100 GiB.
Perhatikan kehadiran dan ketiadaan garis miring pada permulaan setiap baris? Setiap set data mempunyai tempat tersendiri dalam kedua-dua hierarki ZFS dan hierarki pemasangan sistem. Tiada garis miring utama dalam hierarki ZFS—anda bermula dengan nama kumpulan dan kemudian laluan dari satu set data ke seterusnya. Sebagai contoh, pool/parent/child untuk set data bernama child di bawah set data induk parent dalam kolam dengan nama kreatif pool.
Secara lalai, titik lekapan set data akan bersamaan dengan namanya dalam hierarki ZFS, dengan garis miring utama - kumpulan bernama pool dipasang sebagai /pool, set data parent dipasang masuk /pool/parent, dan set data kanak-kanak child dipasang masuk /pool/parent/child. Walau bagaimanapun, titik lekap sistem set data boleh ditukar.
Jika kita menunjukkan zfs set mountpoint=/lol pool/parent/child, kemudian set data pool/parent/child dipasang ke dalam sistem sebagai /lol.
Selain set data, kita harus menyebut volum (zvols). Kelantangan adalah lebih kurang sama dengan set data, kecuali ia sebenarnya tidak mempunyai sistem fail—ia hanya peranti blok. Anda boleh contohnya buat zvol Dengan nama mypool/myzvol, kemudian formatkannya dengan sistem fail ext4, dan kemudian lekapkan sistem fail itu - kini anda mempunyai sistem fail ext4, tetapi dengan semua ciri keselamatan ZFS! Ini mungkin kelihatan bodoh pada satu komputer, tetapi lebih masuk akal sebagai bahagian belakang apabila mengeksport peranti iSCSI.
Blok
Fail diwakili oleh satu atau lebih blok. Setiap blok disimpan pada satu peranti maya. Saiz blok biasanya sama dengan parameter saiz rekod, tetapi boleh dikurangkan kepada 2^anjakan, jika ia mengandungi metadata atau fail kecil.
Kami sungguh benar-benar Kami tidak bergurau tentang penalti prestasi yang besar jika anda menetapkan anjakan terlalu rendah
Dalam kumpulan ZFS, semua data, termasuk metadata, disimpan dalam blok. Saiz blok maksimum untuk setiap set data ditakrifkan dalam harta recordsize (saiz rekod). Saiz rekod boleh berubah, tetapi ini tidak akan mengubah saiz atau lokasi mana-mana blok yang telah ditulis pada set data - ia hanya mempengaruhi blok baharu semasa ia ditulis.
Melainkan dinyatakan sebaliknya, saiz kemasukan lalai semasa ialah 128 KiB. Ini semacam pertukaran yang sukar di mana prestasinya tidak akan sempurna, tetapi ia tidak akan menjadi buruk dalam kebanyakan kes. Recordsize boleh ditetapkan kepada sebarang nilai dari 4K hingga 1M (dengan tetapan tambahan recordsize anda boleh memasang lebih banyak lagi, tetapi ini jarang idea yang baik).
Sebarang blok merujuk kepada data hanya satu fail—anda tidak boleh memerah dua fail berbeza ke dalam satu blok. Setiap fail terdiri daripada satu atau lebih blok, bergantung pada saiznya. Jika saiz fail lebih kecil daripada saiz rekod, ia akan disimpan dalam blok yang lebih kecil—contohnya, blok yang mengandungi fail 2KiB hanya akan menduduki satu sektor 4KiB pada cakera.
Jika fail itu cukup besar untuk memerlukan beberapa blok, maka semua entri ke fail itu akan bersaiz recordsize - termasuk entri terakhir, bahagian utamanya mungkin .
volum zvol tidak mempunyai harta recordsize - sebaliknya mereka mempunyai harta yang setara volblocksize.
Sektor
Yang terakhir, blok bangunan paling asas ialah sektor. Ia adalah unit fizikal terkecil yang boleh ditulis atau dibaca daripada peranti hos. Selama beberapa dekad, kebanyakan cakera menggunakan sektor 512-bait. Hari ini, kebanyakan pemacu dikonfigurasikan untuk sektor 4KiB, dan beberapa—terutama SSD—dikonfigurasikan untuk sektor 8KiB atau lebih besar.
ZFS mempunyai ciri yang membolehkan anda menetapkan saiz sektor secara manual. Harta ini ashift. Agak mengelirukan, ashift ialah kuasa dua. Sebagai contoh, ashift=9 bermaksud saiz sektor 2^9, atau 512 bait.
ZFS meminta sistem pengendalian untuk mendapatkan maklumat terperinci tentang setiap peranti blok apabila ia ditambahkan pada vdev baharu, dan secara teorinya secara automatik menetapkan ashift dengan sewajarnya berdasarkan maklumat tersebut. Malangnya, banyak pemacu berbohong tentang saiz sektornya untuk mengekalkan keserasian dengan Windows XP (yang tidak dapat memahami pemacu dengan saiz sektor lain).
Ini bermakna sangat disyorkan bahawa pentadbir ZFS mengetahui saiz sektor sebenar peranti mereka dan ditetapkan secara manual ashift. Jika ashift ditetapkan terlalu kecil, bilangan operasi baca/tulis meningkat secara astronomi. Jadi, menulis "sektor" 512-bait kepada sektor 4KiB sebenar bermakna perlu menulis "sektor" pertama, kemudian baca sektor 4KiB, ubah suai dengan "sektor" 512-bait kedua, tulis semula ke sektor 4KiB baharu , dan seterusnya. untuk setiap entri.
Di dunia nyata, penalti sedemikian menjejaskan SSD Samsung EVO, yang mana ia sepatutnya digunakan ashift=13, tetapi SSD ini berbohong tentang saiz sektornya, dan oleh itu lalai ditetapkan kepada ashift=9. Melainkan pentadbir sistem berpengalaman menukar tetapan ini, SSD ini berfungsi lebih perlahan HDD magnet biasa.
Sebagai perbandingan, kerana terlalu besar ashift hampir tiada penalti. Tiada pencapaian prestasi sebenar dan peningkatan dalam ruang yang tidak digunakan adalah sangat kecil (atau sifar jika mampatan didayakan). Oleh itu, kami amat mengesyorkan agar pemacu yang menggunakan sektor 512 bait pun dipasang ashift=12 atau bahkan ashift=13untuk melihat masa depan dengan yakin.
Harta ashift dipasang untuk setiap vdev peranti maya, dan bukan untuk kolam, kerana ramai orang tersilap fikir, dan tidak berubah selepas pemasangan. Jika anda tidak sengaja memukul ashift Apabila anda menambahkan vdev baharu pada kolam, anda telah mencemarkan kolam itu secara tidak boleh ditarik balik dengan peranti berprestasi rendah dan, sebagai peraturan, tiada pilihan lain selain memusnahkan kolam itu dan mulakan semula. Malah memadamkan vdev tidak akan menyelamatkan anda daripada tetapan yang rosak ashift!
Mekanisme salin-tulis
Jika sistem fail biasa perlu menulis semula data, ia mengubah suai setiap blok di mana ia berada
Sistem fail copy-on-write menulis versi baharu blok dan kemudian membuka kunci versi lama
Secara abstrak, jika kita mengabaikan susunan fizikal sebenar blok, "komet data" kita dipermudahkan kepada "cacing data" yang bergerak dari kiri ke kanan merentasi peta ruang yang tersedia
Kini kita boleh mendapatkan idea yang baik tentang cara syot kilat salin atas tulis berfungsi - setiap blok boleh tergolong dalam berbilang syot kilat, dan akan berterusan sehingga semua syot kilat yang berkaitan dimusnahkan
Mekanisme Copy on Write (CoW) adalah asas asas yang menjadikan ZFS sebagai sistem yang menakjubkan. Konsep asasnya mudah - jika anda meminta sistem fail tradisional untuk menukar fail, ia akan melakukan apa yang anda minta. Jika anda meminta sistem fail copy-on-write untuk melakukan perkara yang sama, ia akan berkata "okay"—tetapi ia akan menipu anda.
Sebaliknya, sistem fail salin atas tulis menulis versi baharu blok yang diubah suai dan kemudian mengemas kini metadata fail untuk menyahpaut blok lama dan mengaitkannya dengan blok baharu yang baru anda tulis.
Menyahikat blok lama dan memautkan yang baharu dilakukan dalam satu operasi, jadi ia tidak boleh diganggu - jika anda menetapkan semula kuasa selepas ini berlaku, anda mempunyai versi baharu fail, dan jika anda menetapkan semula kuasa sebelum ini, maka anda mempunyai versi lama. Walau apa pun, tidak akan ada konflik dalam sistem fail.
Copy-on-write dalam ZFS berlaku bukan sahaja pada peringkat sistem fail, tetapi juga pada peringkat pengurusan cakera. Ini bermakna ZFS tidak terdedah kepada ruang kosong dalam rekod () - fenomena apabila jalur hanya sebahagiannya direkodkan sebelum sistem ranap, dengan kerosakan pada tatasusunan selepas but semula. Di sini jalur ditulis secara atom, vdev sentiasa berurutan, dan .
ZIL: Log niat ZFS
ZFS mengendalikan penulisan segerak dengan cara yang istimewa - ia menyimpannya buat sementara waktu tetapi serta-merta dalam ZIL sebelum kemudian menulisnya secara kekal bersama-sama dengan tulisan tak segerak.
Biasanya, data yang ditulis kepada ZIL tidak pernah dibaca lagi. Tetapi ini mungkin selepas kegagalan sistem
SLOG, atau peranti LOG sekunder, hanyalah vdev yang istimewa - dan sebaik-baiknya sangat pantas - di mana ZIL boleh disimpan secara berasingan daripada storan utama
Selepas ranap sistem, semua data kotor dalam ZIL dimainkan semula - dalam kes ini, ZIL berada di SLOG, jadi di situlah ia dimainkan semula
Terdapat dua kategori utama penulisan—segerak (segerak) dan tak segerak (tak segerak). Bagi kebanyakan beban kerja, sebahagian besar penulisan adalah tak segerak—sistem fail membolehkannya diagregatkan dan dikeluarkan dalam kelompok, mengurangkan pemecahan dan meningkatkan daya pengeluaran dengan ketara.
Rakaman segerak adalah perkara yang sama sekali berbeza. Apabila aplikasi meminta penulisan segerak, ia memberitahu sistem fail: "Anda perlu melakukan ini kepada memori tidak meruap sekarang, dan sehingga itu tiada apa lagi yang boleh saya lakukan.” Oleh itu, penulisan segerak mesti komited pada cakera dengan serta-merta—dan jika itu meningkatkan pemecahan atau mengurangkan daya tampung, begitu juga.
ZFS mengendalikan penulisan segerak secara berbeza daripada sistem fail biasa—bukannya segera membuangnya ke storan biasa, ZFS menyerahkannya ke kawasan storan khas yang dipanggil Log Intent ZFS atau ZIL. Caranya ialah rekod ini juga kekal dalam ingatan, diagregatkan bersama-sama dengan permintaan tulis tak segerak biasa, untuk kemudiannya dimasukkan ke dalam storan sebagai TXG (Kumpulan Transaksi) biasa sepenuhnya.
Semasa operasi biasa, ZIL ditulis dan tidak pernah dibaca lagi. Apabila, selepas beberapa saat, rekod daripada ZIL dikomitkan kepada storan utama dalam TXG biasa daripada RAM, ia dipisahkan daripada ZIL. Satu-satunya masa sesuatu dibaca daripada ZIL ialah apabila mengimport kolam.
Jika ranap sistem ZFS berlaku—sistem pengendalian ranap atau gangguan kuasa—semasa terdapat data dalam ZIL, data tersebut akan dibaca semasa import kumpulan seterusnya (contohnya, apabila sistem ranap sistem dimulakan semula). Apa sahaja yang ada dalam ZIL akan dibaca, dikumpulkan ke dalam TXG, komited ke kedai utama, dan kemudian dipisahkan daripada ZIL semasa proses import.
Salah satu kelas pembantu vdev dipanggil LOG atau SLOG, peranti LOG sekunder. Ia mempunyai satu tujuan - untuk menyediakan kolam dengan peranti vdev yang berasingan dan sebaik-baiknya lebih cepat, sangat tahan tulis untuk menyimpan ZIL, bukannya menyimpan ZIL pada storan vdev utama. ZIL sendiri berkelakuan sama tanpa mengira lokasi storan, tetapi jika vdev dengan LOG mempunyai prestasi tulis yang sangat tinggi, maka penulisan segerak akan menjadi lebih pantas.
Menambah vdev dengan LOG ke kolam tidak berfungsi tidak boleh meningkatkan prestasi tulis tak segerak - walaupun anda memaksa semua menulis ke ZIL dengan zfs set sync=always, ia masih akan dipautkan ke storan utama dalam TXG dengan cara yang sama dan pada kadar yang sama seperti tanpa log. Satu-satunya peningkatan prestasi langsung ialah kependaman tulis segerak (kerana kelajuan log yang lebih tinggi menjadikan operasi lebih pantas sync).
Walau bagaimanapun, dalam persekitaran yang sudah memerlukan banyak penulisan segerak, vdev LOG secara tidak langsung boleh mempercepatkan penulisan tak segerak dan bacaan tidak dicache. Memunggah rekod ZIL ke LOG vdev yang berasingan bermakna kurang perbalahan untuk IOPS pada storan utama, yang meningkatkan prestasi semua bacaan dan tulis sedikit sebanyak.
Syot kilat
Mekanisme salin atas tulis juga merupakan asas yang diperlukan untuk syot kilat atom ZFS dan replikasi tak segerak tambahan. Sistem fail aktif mempunyai pepohon penunjuk yang menandakan semua entri dengan data semasa—apabila anda mengambil gambar, anda hanya membuat salinan pepohon penunjuk itu.
Apabila rekod ditimpa pada sistem fail aktif, ZFS mula-mula menulis versi baharu blok ke ruang yang tidak digunakan. Kemudian menanggalkan versi lama blok daripada sistem fail semasa. Tetapi jika beberapa syot kilat merujuk blok lama, ia masih kekal tidak berubah. Blok lama sebenarnya tidak akan dipulihkan sebagai ruang kosong sehingga semua syot kilat yang merujuk blok itu dimusnahkan!
Replikasi
Pustaka Steam saya pada tahun 2015 ialah 158 GiB dan termasuk 126 fail. Ini agak hampir dengan keadaan optimum untuk rsync - replikasi ZFS melalui rangkaian adalah "hanya" 927% lebih cepat.
Pada rangkaian yang sama, mereplikasi fail imej mesin maya Windows 40 7GB tunggal adalah cerita yang sama sekali berbeza. Replikasi ZFS adalah 289 kali lebih pantas daripada rsync—atau "hanya" 161 kali lebih pantas jika anda cukup arif untuk memanggil rsync dengan suis --inplace.
Apabila imej VM berskala, rsync mengeluarkan skala dengannya. Saiz 1,9 TiB tidak begitu besar untuk imej VM moden - tetapi ia cukup besar sehingga replikasi ZFS adalah 1148 kali lebih pantas daripada rsync, walaupun dengan rsync --inplace argument
Sebaik sahaja anda memahami cara syot kilat berfungsi, ia akan menjadi mudah untuk memahami intipati replikasi. Memandangkan syot kilat hanyalah pokok penunjuk rekod, ia mengikutinya jika kita melakukannya zfs send snapshot, kemudian kami menghantar pokok ini dan semua rekod yang berkaitan dengannya. Apabila kita lulus ini zfs send в zfs receive pada objek sasaran, ia menulis kedua-dua kandungan sebenar blok dan pokok penunjuk yang merujuk blok kepada set data sasaran.
Perkara menjadi lebih menarik pada detik zfs send. Kami kini mempunyai dua sistem, masing-masing mengandungi poolname/datasetname@1, dan anda mengambil gambar baharu poolname/datasetname@2. Oleh itu, dalam kolam sumber yang anda miliki datasetname@1 и datasetname@2, dan dalam kumpulan sasaran hanya terdapat syot kilat pertama datasetname@1.
Kerana antara sumber dan sasaran kita mempunyai gambaran biasa datasetname@1, Kita boleh lakukannya pertambahan zfs send di atasnya. Apabila kita memberitahu sistem zfs send -i poolname/datasetname@1 poolname/datasetname@2, ia membandingkan dua pokok penunjuk. Sebarang petunjuk yang wujud hanya dalam @2, jelas merujuk kepada blok baharu - jadi kami memerlukan kandungan blok tersebut.
Pada sistem jauh, pemprosesan tambahan send sama mudah. Mula-mula kami menulis semua entri baharu yang disertakan dalam strim send, dan kemudian tambahkan penunjuk pada blok ini. Voila, kami ada @2 dalam sistem baru!
Replikasi tambahan tak segerak ZFS ialah peningkatan besar berbanding kaedah berasaskan bukan syot kilat yang lebih awal seperti rsync. Dalam kedua-dua kes, hanya data yang diubah dipindahkan - tetapi rsync mesti terlebih dahulu membaca daripada cakera semua data di kedua-dua belah pihak untuk menyemak jumlah dan membandingkannya. Sebaliknya, replikasi ZFS tidak membaca apa-apa selain pepohon penunjuk—dan sebarang blok yang tidak diwakili dalam petikan keseluruhan.
Mampatan terbina dalam
Mekanisme salin atas tulis juga memudahkan sistem mampatan terbina dalam. Dalam sistem fail tradisional, pemampatan bermasalah—kedua-dua versi lama dan versi baharu data yang diubah berada dalam ruang yang sama.
Jika anda menganggap sekeping data di tengah-tengah fail yang memulakan hayatnya sebagai megabait sifar daripada 0x00000000 dan seterusnya, sangat mudah untuk memampatkannya ke satu sektor pada cakera. Tetapi apakah yang berlaku jika kita menggantikan megabait sifar ini dengan megabait data tidak boleh mampat, seperti JPEG atau hingar pseudo-rawak? Tiba-tiba, megabait data itu tidak memerlukan satu, tetapi 256 sektor 4KiB, dan hanya satu sektor dikhaskan dalam ruang cakera itu.
ZFS tidak mempunyai masalah ini kerana penulisan yang diubah suai sentiasa ditulis pada ruang yang tidak digunakan - blok asal hanya menggunakan satu sektor 4 KiB, tetapi penulisan baharu akan mengambil 256, tetapi itu bukan masalah - bahagian yang diubah suai baru-baru ini daripada " tengah" fail akan ditulis ke ruang yang tidak digunakan tanpa mengira sama ada saiznya telah berubah atau tidak, jadi ini adalah situasi yang benar-benar normal untuk ZFS.
Mampatan ZFS terbina dalam dilumpuhkan secara lalai dan sistem ini menawarkan algoritma boleh pasang—pada masa ini termasuk LZ4, gzip (1-9), LZJB dan ZLE.
- LZ4 ialah algoritma penstriman yang menawarkan faedah mampatan dan penyahmampatan dan prestasi yang sangat pantas untuk kebanyakan kes penggunaan—walaupun pada CPU yang agak perlahan.
- GZIP ialah algoritma yang dihormati yang semua pengguna Unix tahu dan suka. Ia boleh dilaksanakan dengan tahap mampatan 1-9, dengan nisbah mampatan yang semakin meningkat dan penggunaan CPU semasa anda menghampiri tahap 9. Algoritma ini sangat sesuai untuk semua kes penggunaan teks (atau lain yang sangat boleh mampat), tetapi sering menyebabkan isu CPU sebaliknya. gunakannya dengan berhati-hati, terutamanya di peringkat yang lebih tinggi.
- LZJB - algoritma asal dalam ZFS. Ia sudah usang dan tidak boleh digunakan lagi, LZ4 lebih unggul dalam segala hal.
- ZLE — pengekodan tahap sifar, Pengekodan Tahap Sifar. Ia tidak menyentuh data biasa sama sekali, tetapi ia memampatkan jujukan sifar yang besar. Berguna untuk set data tidak boleh mampat sepenuhnya (seperti JPEG, MP4 atau format lain yang sudah dimampatkan) kerana ia mengabaikan data tidak boleh mampat tetapi memampatkan ruang yang tidak digunakan dalam rekod yang terhasil.
Kami mengesyorkan pemampatan LZ4 untuk hampir semua kes penggunaan; penalti prestasi apabila berurusan dengan data tidak boleh mampat adalah sangat kecil, dan pertumbuhan prestasi untuk data biasa adalah penting. Menyalin imej mesin maya untuk pemasangan baharu sistem pengendalian Windows (OS yang baru dipasang, belum ada data di dalamnya) dengan compression=lz4 lulus 27% lebih cepat daripada dengan compression=noneDalam .
ARC - Cache Penggantian Adaptif
ZFS ialah satu-satunya sistem fail moden yang kami tahu yang menggunakan mekanisme caching baca sendiri, dan bukannya bergantung pada cache halaman sistem pengendalian untuk menyimpan salinan blok yang dibaca baru-baru ini dalam RAM.
Walaupun cache asli bukan tanpa masalah - ZFS tidak boleh bertindak balas kepada permintaan peruntukan memori baharu secepat kernel, jadi panggilan baharu malloc() peruntukan memori mungkin gagal jika ia memerlukan RAM yang sedang diduduki oleh ARC. Tetapi ada sebab yang baik untuk menggunakan cache anda sendiri, sekurang-kurangnya buat masa ini.
Semua sistem pengendalian moden yang diketahui, termasuk MacOS, Windows, Linux dan BSD, menggunakan algoritma LRU (Paling Kurang Digunakan) untuk melaksanakan cache halaman. Ini ialah algoritma primitif yang menolak blok cache "ke bahagian atas baris gilir" selepas setiap kali dibaca dan menolak blok "ke bawah baris gilir" seperti yang diperlukan untuk menambah kesilapan cache baharu (blok yang sepatutnya dibaca daripada cakera dan bukannya dari cache) ke atas.
Biasanya algoritma berfungsi dengan baik, tetapi pada sistem dengan set data berfungsi yang besar, LRU dengan mudah membawa kepada meronta-ronta—mengusir blok yang kerap diperlukan untuk memberi ruang kepada blok yang tidak akan dibaca daripada cache lagi.
ialah algoritma yang kurang naif yang boleh dianggap sebagai cache "berwajaran". Setiap kali blok cache dibaca, ia menjadi sedikit "lebih berat" dan menjadi lebih sukar untuk diusir - dan walaupun selepas blok itu diusir dijejaki dalam tempoh masa tertentu. Blok yang telah diusir tetapi kemudian perlu dibaca semula ke dalam cache juga akan menjadi lebih berat.
Hasil akhir semua ini ialah cache dengan nisbah hit yang jauh lebih tinggi—nisbah antara hits cache (dibaca dari cache) dan terlepas (dibaca dari cakera). Ini adalah statistik yang sangat penting - bukan sahaja cache mencecah diri mereka sendiri diservis mengikut urutan magnitud dengan lebih cepat, cache miss juga boleh diservis dengan lebih cepat, memandangkan lebih banyak cache berlaku, semakin sedikit permintaan serentak ke cakera dan semakin rendah kependaman untuk yang tinggal. yang mesti diservis dengan cakera.
Kesimpulan
Memandangkan kami telah membincangkan semantik asas ZFS—cara salin atas tulis berfungsi, serta hubungan antara kumpulan storan, peranti maya, blok, sektor dan fail—kami bersedia untuk membincangkan prestasi dunia sebenar dengan nombor nyata.
Dalam bahagian seterusnya, kita akan melihat prestasi sebenar kumpulan vdev dan RAIDz bercermin, berbanding antara satu sama lain, dan juga dibandingkan dengan topologi RAID kernel Linux tradisional yang telah kami periksa. .
Pada mulanya kami ingin merangkumi hanya asas-topologi ZFS itu sendiri-tetapi selepas itu ini Kami akan bersedia untuk bercakap tentang konfigurasi dan penalaan ZFS yang lebih maju, termasuk penggunaan jenis vdev tambahan seperti L2ARC, SLOG dan Peruntukan Khas.
Sumber: www.habr.com