Spring ieu kami geus dibahas sababaraha jejer bubuka, misalna. и . Dina kadua ieu, urang malah jangji baris nuluykeun diajar kinerja rupa-rupa topologies multi-disk di ZFS. Ieu sistem file generasi saterusna nu ayeuna keur deployed madhab ti ka .
Nya, dinten ieu mangrupikeun dinten anu pangsaéna pikeun kenal sareng ZFS, pamiarsa panasaran. Ngan terang yén dina pamekar OpenZFS penilaian hina Matt Ahrens, "éta hésé pisan."
Tapi sateuacan urang dugi ka nomer - sareng bakal aya, kuring janji - pikeun sadaya varian konfigurasi ZFS dalapan disk, urang kedah ngobrol ngeunaan kumaha Sacara umum, ZFS nyimpen data dina disk.
Zpool, vdev jeung alat
diagram kolam renang pinuh ieu ngawengku tilu vdevs bantu, salah sahiji unggal kelas, sarta opat pikeun RAIDz2
Biasana henteu aya alesan pikeun nyiptakeun kumpulan jinis sareng ukuran vdev anu teu cocog - tapi upami anjeun hoyong, teu aya anu ngahalangan anjeun pikeun ngalakukeunana.
Pikeun leres-leres ngartos sistem file ZFS, anjeun kedah ningal struktur anu saleresna. Kahiji, ZFS ngahijikeun volume tradisional sareng lapisan manajemén sistem file. Kadua, éta ngagunakeun mékanisme copy-on-write transactional. Fitur ieu hartosna yén sistem sacara stuktur béda pisan sareng sistem file konvensional sareng arrays RAID. The set mimiti blok wangunan dasar ngartos anu kolam renang gudang (zpool), alat virtual (vdev) jeung alat nyata (alat).
zpool
Kolam renang panyimpen zpool mangrupikeun struktur ZFS anu paling luhur. Unggal kolam renang ngandung hiji atawa leuwih alat virtual. Sabalikna, masing-masing ngandung hiji atanapi langkung alat nyata (alat). Kolam renang maya mangrupikeun unit mandiri. Hiji komputer fisik bisa ngandung dua atawa leuwih pools misah, tapi unggal sagemblengna bebas tina batur. Pools teu tiasa ngabagi alat virtual.
ZFS redundansi aya dina tingkat alat virtual, teu di tingkat kolam renang. Aya pancén teu redundancy di tingkat kolam renang-lamun hiji vdev atanapi dedicated vdev leungit, sakabéh kolam renang leungit sapanjang kalawan eta.
pools gudang modern bisa salamet leungitna cache atawa log hiji alat maya urang - sanajan maranéhna bisa leungit jumlah leutik data kotor lamun maranéhna leungit vdev log salila pareum listrik atawa sistem kacilakaan.
Aya misconception umum yén ZFS "belang data" ditulis dina sakabéh kolam renang. Ieu teu bener. Zpool sanes a RAID0 lucu, éta leuwih ti hiji lucu kalawan mékanisme distribusi variabel kompléks.
Kanggo sabagéan ageung, rékaman disebarkeun diantara alat maya anu sayogi dumasar kana rohangan bébas anu sayogi, ku kituna dina téori aranjeunna sadayana bakal dieusi dina waktos anu sami. Vérsi ZFS nu leuwih anyar tumut kana akun pamakéan vdev ayeuna (pembuangan) - lamun hiji alat maya nyata sibuk ti nu sejen (contona, alatan maca beban), eta bakal samentara skipped pikeun nulis, sanajan ngabogaan rasio spasi bébas pangluhurna. .
Mékanisme deteksi daur ulang anu diwangun kana metode alokasi nyerat ZFS modéren tiasa ngirangan latency sareng ningkatkeun throughput salami periode beban anu luar biasa tinggi - tapi henteu. carte blanche mun campur involuntary of HDDs slow sarta SSDs gancang dina hiji kolam renang. Kolam renang anu henteu sami sapertos kitu bakal tetep beroperasi dina laju alat anu paling laun, nyaéta, saolah-olah éta diwangun ku alat sapertos kitu.
vdev
Unggal kolam renang gudang diwangun ku hiji atawa leuwih alat virtual (vdev). Sabalikna, unggal vdev kalebet hiji atanapi langkung alat nyata. Kaseueuran alat virtual dianggo pikeun neundeun data anu sederhana, tapi aya sababaraha kelas pembantu vdev, kalebet CACHE, LOG, sareng SPECIAL. Unggal jenis vdev ieu bisa boga salah sahiji lima topologies: single-alat, RAIDz1, RAIDz2, RAIDz3 atawa eunteung.
RAIDz1, RAIDz2 na RAIDz3 mangrupakeun variétas husus naon folks heubeul bakal nelepon ganda (diagonal) parity RAID. 1, 2 sareng 3 nujul kana sabaraha blok parity anu dialokasikeun ka unggal jalur data. Gantina gaduh disk misah pikeun nyadiakeun parity, alat RAIDz virtual ngadistribusikaeun parity semi-rata sakuliah disk. A Asép Sunandar Sunarya RAIDz bisa leungit saloba disk sakumaha mibanda blok parity; lamun leungit hiji sejen, eta bakal gagal sarta nyandak kolam renang gudang kalayan eta.
Dina alat virtual eunteung (eunteung vdev), unggal blok disimpen dina unggal alat dina vdev. Sanajan kaca spion dua-lega anu paling umum, eunteung bisa ngandung sagala jumlah sawenang alat-dina pamasangan badag, triples mindeng dipaké pikeun ngaronjatkeun kinerja maca jeung kasabaran sesar. Eunteung vdev tiasa salamet kagagalan naon waé salami sahenteuna hiji alat dina vdev tetep operasional.
vdevs tunggal inherently bahaya. Alat maya sapertos kitu moal salamet kagagalan tunggal - sareng upami dianggo salaku panyimpen atanapi vdev khusus, maka kagagalanna bakal nyababkeun karusakan sadayana kolam renang. Kudu ati-ati pisan di dieu.
CACHE, LOG, sareng alat maya SPECIAL tiasa didamel dina topologi di luhur - tapi émut yén kaleungitan alat virtual SPECIAL hartosna kaleungitan kolam renang, janten topologi anu kaleuleuwihan disarankeun pisan.
pakakas
Ieu meureun istilah panggampangna pikeun ngarti dina ZFS - eta sacara harfiah mangrupakeun blok alat aksés acak. Inget yen alat virtual diwangun ku alat individu, sarta kolam renang dijieun tina alat virtual.
Disk, boh kaayaan magnét atanapi padet, mangrupikeun alat blok anu paling umum dianggo salaku blok wangunan vdev. Nanging, alat naon waé anu gaduh deskriptor dina / dev bakal ngalakukeun - ku kituna sakabéh hardware RAID arrays tiasa dianggo salaku alat anu misah.
File atah basajan mangrupikeun salah sahiji alat blok alternatif anu paling penting dimana vdev tiasa diwangun. Test pools ti mangrupakeun cara pohara merenah pikeun pariksa paréntah kolam renang tur tingal sabaraha spasi sadia dina kolam renang atawa alat virtual tina topologi dibikeun.
Anjeun tiasa nyiptakeun kolam renang tés tina file anu jarang dina sababaraha detik - tapi tong hilap mupus sadayana kolam renang sareng komponénna saatosna
Anggap anjeun hoyong server dalapan disk sareng ngarencanakeun ngagunakeun disk 10 TB (~ 9300 GiB) - tapi anjeun henteu yakin topologi mana anu paling cocog sareng kabutuhan anjeun. Dina conto di luhur, urang ngawangun kolam renang test tina file sparse dina hitungan detik - tur ayeuna urang terang yen RAIDz2 vdev dalapan 10 TB disk nyadiakeun 50 TiB kapasitas usable.
Alat kelas khusus anu sanés nyaéta SPARE. Alat hot-swap, teu saperti alat biasa, milik sakabéh kolam renang tinimbang hiji alat virtual tunggal. Mun sagala vdev di kolam renang nu gagal sarta alat cadang disambungkeun ka kolam renang na sadia, mangka otomatis bakal gabung vdev kapangaruhan.
Sakali disambungkeun ka vdev kapangaruhan, alat ngagantian dimimitian pikeun nampa salinan atawa reconstructions tina data nu kudu dina alat leungit. Dina RAID tradisional ieu disebut "rebuilding", sarta dina ZFS éta "resolvering".
Kadé dicatet yén alat ngagantian teu permanén ngaganti alat gagal. Ieu ngan hiji ngagantian samentara pikeun ngurangan waktu nu diperlukeun pikeun vdev ngadegradasi. Saatos pangurus ngagantikeun alat vdev gagal, redundancy dibalikeun kana éta alat permanén, sarta SPARE dipegatkeun tina vdev sarta balik deui ka cadang pikeun sakabéh kolam renang.
Set data, blok sareng séktor
Susunan blok wangunan salajengna pikeun ngartos dina perjalanan ZFS urang kirang aya hubunganana sareng hardware sareng seueur deui hubunganana sareng kumaha datana diatur sareng disimpen. Kami ngaluncurkeun sababaraha lapisan di dieu - sapertos metaslab - pikeun ngahindarkeun detailna bari ngajaga pamahaman ngeunaan struktur umum.
Dataset
Nalika urang mimiti nyiptakeun set data, éta nunjukkeun sadaya rohangan kolam renang anu sayogi. Teras we nyetel kuota - sarta ngarobah titik Gunung. Sihir!
Zvol lolobana ngan hiji dataset dilucuti tina lapisan filesystem na, nu urang ngaganti dieu kalawan ext4 filesystem lengkep normal.
Set data ZFS kira-kira sami sareng sistem file anu dipasang standar. Kawas sistem file biasa, dina glance kahiji sigana "ngan polder sejen." Tapi sapertos sistem file anu dipasang biasa, unggal set data ZFS gaduh set sipat dasar sorangan.
Anu mimiti, susunan data tiasa gaduh kuota anu ditugaskeun. Upami anjeun masang zfs set quota=100G poolname/datasetname, teras anjeun moal tiasa nyerat kana polder anu dipasang /poolname/datasetname leuwih ti 100 GiB.
Perhatikeun ayana-sareng henteuna-slash di awal unggal baris? Unggal set data ngagaduhan tempatna sorangan dina hirarki ZFS sareng hierarki gunung sistem. Henteu aya slash ngarah dina hirarki ZFS - anjeun mimitian ku nami kolam renang teras jalur tina hiji set data ka hareup. Salaku conto, pool/parent/child pikeun set data ngaranna child handapeun dataset indungna parent dina kolam renang kalayan ngaran kreatif pool.
Sacara standar, titik gunung tina susunan data bakal sarua jeung ngaranna dina hirarki ZFS, kalawan slash ngarah - pool ngaranna pool dipasang salaku /pool, susunan data parent dipasang di /pool/parent, sareng set data anak child dipasang di /pool/parent/child. Tapi, titik mount sistem set data tiasa dirobih.
Lamun urang nunjukkeun zfs set mountpoint=/lol pool/parent/child, teras set data pool/parent/child dipasang kana sistem salaku /lol.
Salian datasets, urang kudu nyebut jilid (zvols). Volume kira-kira sarua jeung kumpulan data, iwal ti sabenerna teu boga sistem file-éta ngan hiji alat block. Anjeun tiasa contona nyieun zvol Kalawan ngaran mypool/myzvol, teras pormat ku sistem file ext4, teras pasang sistem file éta - ayeuna anjeun gaduh sistem file ext4, tapi kalayan sagala fitur kaamanan ZFS! Ieu mungkin sigana konyol dina hiji komputer, tapi ngajadikeun leuwih akalna salaku backend a nalika exporting hiji alat iSCSI.
Blok-blok
Hiji file digambarkeun ku hiji atawa leuwih blok. Unggal blok disimpen dina hiji alat virtual. Ukuran blok biasana sami sareng parameter ukuran rékaman, tapi bisa diréduksi jadi 2 ^ ngalih, lamun ngandung metadata atawa file leutik.
Urang bener bener Kami henteu bercanda ngeunaan pinalti kinerja anu ageung upami anjeun nyetél ashift rendah teuing
Dina kolam renang ZFS, sadaya data, kalebet metadata, disimpen dina blok. Ukuran blok maksimum pikeun tiap set data diartikeun dina harta recordsize (ukuran catetan). Ukuran catetan tiasa robih, tapi ieu moal ngarobih ukuran atanapi lokasi blok naon waé anu parantos diserat kana set data - éta ngan ukur mangaruhan blok énggal nalika ditulis.
Kacuali disebutkeun, ukuran éntri standar ayeuna nyaéta 128 KiB. Ieu jenis trade-off tangguh dimana kinerja moal sampurna, tapi moal dahsyat di hal nu ilahar. Recordsize tiasa disetel ka nilai naon waé ti 4K dugi ka 1M (kalayan setélan tambahan recordsize Anjeun tiasa install malah leuwih, Tapi ieu téh jarang mangrupakeun ide nu sae).
Blok naon waé ngarujuk kana data ngan ukur hiji file-anjeun teu tiasa nyepetkeun dua file anu béda kana hiji blok. Unggal file diwangun ku hiji atawa leuwih blok, gumantung kana ukuranana. Upami ukuran file langkung alit tibatan ukuran catetan, éta bakal disimpen dina blok anu langkung alit - contona, blok kalayan file 2 KiB ngan ukur ngeusian hiji séktor 4 KiB dina disk.
Upami filena cukup ageung ngabutuhkeun sababaraha blok, maka sadaya éntri kana file éta bakal ukuranana recordsize - kaasup entri panungtungan, bagian utama nu bisa jadi .
jilid zvol teu boga harta recordsize - gantina maranéhna boga sipat sarimbag volblocksize.
séktor
Panungtungan, blok wangunan paling dasar nyaéta séktor. Ieu mangrupikeun unit fisik pangleutikna anu tiasa ditulis atanapi dibaca tina alat host. Pikeun sababaraha dasawarsa, kalolobaan disk nganggo séktor 512-bait. Dinten ayeuna, kalolobaan drive dikonpigurasi pikeun 4 séktor KiB, sareng sababaraha - khususna SSD - dikonpigurasi pikeun séktor 8 KiB atanapi langkung ageung.
ZFS gaduh fitur anu ngamungkinkeun anjeun nyetél ukuran séktor sacara manual. sipat ieu ashift. Anu rada ngabingungkeun, ashift mangrupikeun kakuatan dua. Salaku conto, ashift=9 hartina ukuran séktor 2^9, atawa 512 bait.
ZFS miwarang sistem operasi pikeun inpo wincik tentang unggal alat block lamun eta ditambahkeun kana vdev anyar, sarta sacara téoritis otomatis nyetél ashift luyu dumasar kana informasi éta. Hanjakalna, seueur drive ngabohong ngeunaan ukuran séktorna pikeun ngajaga kasaluyuan sareng Windows XP (anu teu tiasa ngartos drive sareng ukuran séktor sanés).
Ieu ngandung harti yén éta kacida dianjurkeun yén administrator ZFS nyaho ukuran sector sabenerna alat maranéhanana sarta diatur sacara manual ashift. Upami ashift diatur leutik teuing, jumlah operasi baca/tulis naék sacara astronomis. Janten, nyerat "sektor" 512-bait ka sektor 4 KiB nyata hartosna kedah nyerat "sektor" kahiji, teras baca sektor 4 KiB, modifikasi sareng "sektor" 512-bait kadua, nyerat deui ka anu énggal. sektor 4 KiB, jeung saterusna pikeun tiap entri.
Di dunya nyata, hukuman sapertos mangaruhan Samsung EVO SSDs, nu eta kudu dilarapkeun ashift=13, Tapi SSDs ieu bohong ngeunaan ukuran séktor maranéhanana, sarta ku kituna standar disetel ka ashift=9. Iwal hiji administrator sistem ngalaman ngarobah setelan ieu, SSD ieu jalan Lalaunan HDD magnét biasa.
Pikeun babandingan, keur badag teuing ashift ampir euweuh pinalti. Henteu aya prestasi anu nyata, sareng kanaékan rohangan anu henteu kapake henteu terbatas (atanapi enol upami komprési diaktipkeun). Ku alatan éta, kami nyarankeun pisan yén sanajan éta drive anu nganggo séktor 512-bait dipasang ashift=12 atawa malah ashift=13pikeun nempo confidently kana mangsa nu bakal datang.
Pasipatan ashift dipasang pikeun tiap vdev alat virtual, jeung teu keur kolam renang, saloba jalma salah pikir - sarta teu robah sanggeus instalasi. Lamun ngahaja pencét ashift Lamun anjeun tambahkeun vdev anyar ka kolam renang a, anjeun geus irrevocably ngotoran kolam renang nu ku alat-kinerja low sarta, sakumaha aturan, euweuh pilihan séjén ti ngancurkeun kolam renang tur mimitian deui. Malah ngahapus vdev moal nyalametkeun anjeun tina setélan rusak ashift!
Mékanisme copy-on-write
Upami sistem file biasa kedah nyerat data, éta ngarobih unggal blok dimana ayana
Sistem file copy-on-write nyerat vérsi énggal blok teras muka konci versi lami
Dina abstrak, lamun urang malire susunan fisik sabenerna blok, "data komet" urang simplifies kana "cacing data" nu ngalir ti kénca ka katuhu sakuliah peta spasi sadia.
Ayeuna urang tiasa nampi ide anu sae kumaha jalanna jepretan copy-on-write - unggal blok tiasa milik sababaraha jepretan, sareng bakal tetep dugi ka sadaya jepretan anu aya hubunganana musnah.
Mékanisme Copy on Write (CoW) mangrupikeun dasar dasar anu ngajantenkeun ZFS janten sistem anu luar biasa. Konsep dasarna basajan - upami anjeun naroskeun sistem file tradisional pikeun ngarobih file, éta bakal ngalakukeun naon anu anjeun naroskeun. Upami anjeun naroskeun sistem file copy-on-write pikeun ngalakukeun hal anu sami, éta bakal nyarios "oke" - tapi éta bakal ngabohong ka anjeun.
Gantina, sistem file copy-on-write nulis versi anyar tina blok dirobah, lajeng ngamutahirkeun metadata file pikeun unlink blok heubeul tur pakait jeung blok anyar Anjeun nulis.
Unlinking blok heubeul jeung linking nu anyar geus rengse dina hiji operasi, jadi teu bisa interrupted - lamun ngareset kakuatan sanggeus ieu kajadian, Anjeun gaduh versi anyar tina file, sarta lamun ngareset kakuatan saméméhna, teras anjeun gaduh versi heubeul. Dina sagala hal, moal aya bentrok dina sistem file.
Copy-on-write di ZFS lumangsung henteu ngan dina tingkat sistem file, tapi ogé dina tingkat manajemén disk. Ieu ngandung harti yén ZFS henteu rentan ka spasi bodas dina catetan () - fenomena nalika strip geus ngan sawaréh geus dirékam saméméh sistem nabrak, kalawan ruksakna Asép Sunandar Sunarya sanggeus reboot a. Di dieu belang ditulis atom, vdev salawasna sequential, jeung .
ZIL: Log Hajat ZFS
ZFS nanganan tulisan sinkron dina cara anu khusus - éta nyimpen éta samentawis tapi langsung di ZIL sateuacan engké nyerat sacara permanén sareng tulisan asinkron.
Biasana, data anu ditulis ka ZIL henteu kantos dibaca deui. Tapi ieu mungkin saatos gagal sistem
A SLOG, atawa alat LOG sekundér, ngan saukur husus - sarta preferably pisan gancang - vdev dimana ZIL bisa disimpen misah ti gudang utama.
Saatos kacilakaan, sadaya data kotor dina ZIL diulinkeun deui - dina hal ieu, ZIL dina SLOG, janten dimana éta diulang deui
Aya dua kategori utama tulisan: sinkron (singkronisasi) sareng asinkron (async). Kanggo sabagéan ageung beban kerja, seuseueurna tulisan henteu sinkron - sistem file ngamungkinkeun aranjeunna dihijikeun sareng dikaluarkeun dina bets, ngirangan fragméntasi sareng ningkatkeun throughput sacara signifikan.
Rékam sinkron mangrupikeun masalah anu béda. Nalika aplikasi nyuhunkeun nyerat sinkron, éta nyarios ka sistem file: "Anjeun kedah ngalakukeun ieu kana mémori anu henteu volatile. ayeuna, sarta nepi ka harita teu aya deui anu bisa Kami laksanakeun.” Ku alatan éta, nulis sinkron kudu komitmen langsung ka disk - sarta lamun ieu ngaronjatkeun fragméntasi atawa ngurangan throughput, jadi eta.
ZFS nanganan tulisan sinkron béda ti sistem file biasa-tinimbang langsung flushing aranjeunna ka gudang biasa, ZFS commits aranjeunna ka wewengkon gudang husus disebut ZFS Intent Log, atawa ZIL. Trik nya éta rékaman ieu oge tetep dina mémori, keur aggregated sapanjang kalawan requests nulis Asynchronous normal, mun engké jadi flushed kana gudang sakumaha TXGs lengkep normal (Grup Transaksi).
Salila operasi normal, ZIL ditulis tur pernah maca deui. Nalika, saatos sababaraha waktos, rékaman tina ZIL komitmen kana panyimpenan utama dina TXGs biasa tina RAM, aranjeunna dipisahkeun tina ZIL. Hiji-hijina waktos anu dibaca tina ZIL nyaéta nalika ngimpor kolam renang.
Upami kagagalan ZFS lumangsung-kacilakaan sistem operasi atanapi pareum listrik-bari aya data dina ZIL, data éta bakal dibaca nalika impor kolam renang salajengna (contona, nalika sistem failover di-restart). Naon waé anu aya dina ZIL bakal dibaca, dikelompokkeun kana TXG, komitmen ka toko utama, teras dipisahkeun tina ZIL nalika prosés impor.
Salah sahiji kelas helper vdev disebut LOG atanapi SLOG, alat LOG sekundér. Cai mibanda hiji tugas - nyadiakeun kolam renang misah tur, preferably, leuwih gancang, kalawan lalawanan nulis pisan tinggi, alat vdev pikeun nyimpen ZIL, tinimbang nyimpen ZIL dina gudang vdev utama. ZIL sorangan behaves sami paduli lokasi gudang, tapi lamun vdev kalawan LOG boga kinerja nulis kacida luhurna, lajeng sinkron nulis bakal leuwih gancang.
Nambahkeun vdev kalawan LOG ka kolam renang teu jalan teu tiasa ningkatkeun kinerja nulis Asynchronous - malah lamun maksakeun sagala nulis ka ZIL kalawan zfs set sync=always, aranjeunna masih bakal numbu ka gudang utama di TXG dina cara nu sarua jeung di Pace sarua tanpa log. Hiji-hijina perbaikan kinerja langsung nyaéta latensi nyerat sinkron (sabab laju log anu langkung luhur ngajantenkeun operasi langkung gancang sync).
Nanging, dina lingkungan anu parantos peryogi seueur nyerat sinkron, vdev LOG sacara teu langsung tiasa nyepetkeun nyerat asinkron sareng bacaan anu teu dicache. Offloading ZIL rékaman ka vdev LOG misah hartina kirang contention pikeun IOPS on gudang primér, nu ngaronjatkeun kinerja sadaya maca jeung nulis ka extent sababaraha.
Jepret
Mékanisme copy-on-write ogé mangrupa pondasi anu diperlukeun pikeun jepretan atom ZFS jeung réplikasi asinkron tambahan. Sistem file aktip gaduh tangkal pointer anu nandaan sadaya éntri sareng data ayeuna - nalika anjeun nyandak snapshot, anjeun ngan saukur ngadamel salinan tina tangkal pointer ieu.
Nalika rékaman ditimpa dina sistem file anu aktip, ZFS mimiti nyerat versi anyar blok kana rohangan anu henteu dianggo. Lajeng detaches versi heubeul tina blok ti sistem file ayeuna. Tapi upami sababaraha snapshot ngarujuk kana blok anu lami, éta tetep teu robih. Blok heubeul moal sabenerna disimpen salaku spasi bébas dugi sadayana snapshots ngarujuk blok nu ancur!
réplikasi
Perpustakaan uap kuring di 2015 nyaéta 158 GiB sareng kalebet 126 file. Ieu cukup deukeut jeung kaayaan optimal pikeun rsync - réplikasi ZFS ngaliwatan jaringan éta "ngan" 927% leuwih gancang.
Dina jaringan anu sami, réplikasi file gambar mesin virtual 40GB Windows 7 mangrupikeun carita anu béda. Réplikasi ZFS 289 kali langkung gancang tibatan rsync-atanapi "ngan" 161 kali langkung gancang upami anjeun cekap pikeun nelepon rsync sareng saklar --inplace.
Nalika skala gambar VM, rsync ngaluarkeun skala sareng éta. Ukuran 1,9 TiB henteu ageung pikeun gambar VM modéren-tapi cukup ageung yén réplikasi ZFS 1148 kali langkung gancang tibatan rsync, sanaos ku rsync --inplace argumen.
Sakali anjeun ngartos kumaha snapshots jalan, éta bakal gampang nangkep hakekat réplikasi. Kusabab snapshot ngan saukur tangkal catetan pointers, éta kieu lamun urang ngalakukeun zfs send snapshot, lajeng urang ngirim tangkal ieu sareng sadaya rékaman pakait sareng eta. Nalika urang lulus ieu zfs send в zfs receive dina obyék target, eta nyerat duanana eusi sabenerna blok jeung tangkal pointers ngarujuk blok kana set data target.
Hal meunang malah leuwih metot dina kadua zfs send. Urang ayeuna gaduh dua sistem, masing-masing ngandung poolname/datasetname@1, jeung anjeun nyandak snapshot anyar poolname/datasetname@2. Ku alatan éta, dina kolam renang sumber anjeun gaduh datasetname@1 и datasetname@2, Sarta dina kolam renang target aya ngan snapshot munggaran datasetname@1.
Kusabab antara sumber jeung udagan urang boga snapshot umum datasetname@1, urang tiasa ngalakukeun eta nambahan zfs send di luhur eta. Lamun urang ngabejaan sistem zfs send -i poolname/datasetname@1 poolname/datasetname@2, eta compares dua tangkal pointer. Sagala pointers nu aya ngan dina @2, écés ngarujuk kana blok anyar - janten urang peryogi eusi blok éta.
Dina sistem jauh, ngolah incremental send sagampil basajan. Mimiti urang nyerat sadaya éntri énggal anu kalebet dina aliran send, teras tambahkeun pointer kana blok ieu. Voila, urang boga @2 dina sistem anyar!
Réplikasi incremental Asynchronous ZFS mangrupikeun paningkatan anu ageung tina metode dumasar-non-snapshot sateuacana sapertos rsync. Dina duanana kasus, ngan data robah ditransferkeun - tapi rsync kedah munggaran maca ti disk sagala data dina dua sisi pikeun pariksa jumlah tur dibandingkeun. Sabalikna, réplikasi ZFS henteu maca nanaon lian ti tangkal pointer-sareng blok naon waé anu henteu diwakilan dina snapshot sadayana.
Diwangun-di komprési
Mékanisme copy-on-write ogé nyederhanakeun sistem komprési anu diwangun. Dina sistem file tradisional, komprési aya masalah - duanana versi heubeul jeung versi anyar tina data robah aya dina spasi sarua.
Upami anjeun nganggap sapotong data di tengah file anu ngamimitian hirupna salaku megabyte nol tina 0x00000000 sareng saterasna - gampang pisan pikeun niiskeun kana séktor tunggal dina disk. Tapi naon anu lumangsung lamun urang ngaganti megabyte ieu nol ku megabyte data incompressible, kayaning JPEG atanapi pseudo-acak noise? Ujug-ujug, éta megabyte data bakal merlukeun teu hiji, tapi 256 4 séktor KiB, sarta ngan hiji sektor ieu ditangtayungan dina spasi disk.
ZFS teu boga masalah ieu, saprak rékaman dirobah sok ditulis kana spasi henteu kapake - blok aslina ngan nyokot hiji 4 sektor KiB, sarta nulis anyar bakal nyandak up 256, tapi ieu teu jadi masalah - fragmen anyar dirobah tina "tengah" file bakal ditulis kana spasi henteu kapake paduli naha ukuranana geus robah atawa henteu, jadi ieu kaayaan sagemblengna normal pikeun ZFS.
Diwangun-di komprési ZFS ditumpurkeun sacara standar, sarta sistem nawarkeun algoritma pluggable - ayeuna kaasup LZ4, gzip (1-9), LZJB na ZLE.
- LZ4 nyaéta algoritma streaming anu nawiskeun komprési sareng decompression sareng kauntungan kinerja anu gancang pisan pikeun kalolobaan kasus pamakean - bahkan dina CPU anu lumayan lambat.
- GZIP mangrupakeun algoritma venerable yén sadaya pamaké Unix nyaho tur cinta. Éta tiasa dilaksanakeun kalayan tingkat komprési 1-9, kalayan ningkatkeun rasio komprési sareng pamakean CPU nalika anjeun ngadeukeutan tingkat 9. Algoritma ieu cocog pikeun sadaya kasus panggunaan téks (atanapi anu tiasa dikomprésikeun pisan), tapi sering nyababkeun masalah CPU upami henteu - nganggo éta. kalawan caution, utamana dina tingkat luhur.
- LZJB - algoritma aslina dina ZFS. Éta luntur sareng henteu kedah dianggo deui, LZ4 punjul dina sagala hal.
- GORENG - encoding tingkat enol, Encoding tingkat enol. Teu noél data normal pisan, tapi compresses runtuyan badag tina nol. Mangpaat pikeun set data pinuh incompressible (sapertos JPEG, MP4 atawa format sejenna geus dikomprés) sabab teu malire data incompressible tapi compresses spasi teu dipaké dina rékaman hasilna.
Kami ngarékoméndasikeun komprési LZ4 pikeun ampir sakabéh kasus pamakéan; pinalti kinerja nalika kaayaan data incompressible pisan leutik, jeung tumuwuhna kinerja pikeun data has signifikan. Nyalin gambar mesin virtual pikeun pamasangan sistem operasi Windows anyar (OS anu nembe dipasang, teu acan aya data di jero) nganggo compression=lz4 diliwatan 27% gancang ti kalawan compression=nonedi .
ARC - cache ngagantian adaptif
ZFS mangrupikeun hiji-hijina sistem file modern anu urang terang yén ngagunakeun mékanisme maca cache sorangan, tinimbang ngandelkeun halaman cache sistem operasi pikeun nyimpen salinan blok anu nembe dibaca dina RAM.
Sanaos cache asli henteu aya masalahna - ZFS henteu tiasa ngabales pamundut alokasi mémori énggal sagancangna kernel, janten telepon énggal malloc() alokasi memori bisa gagal lamun merlukeun RAM ayeuna dikawasaan ku ARC. Tapi aya alesan anu hadé pikeun ngagunakeun cache anjeun nyalira, sahenteuna pikeun ayeuna.
Kabéh sistem operasi modern dipikawanoh, kaasup MacOS, Windows, Linux Ubuntu jeung BSD, ngagunakeun algoritma LRU (Paling Least Anyar Dipaké) pikeun nerapkeun cache kaca. Ieu mangrupikeun algoritma primitif anu ngadorong blok cache "ka luhur antrian" saatos unggal dibaca sareng nyorong blok "ka handap antrian" upami diperyogikeun pikeun nambihan cache anu énggal (blok anu kedah dibaca tina disk tinimbang ti cache) ka luhur.
Biasana algoritmana tiasa dianggo saé, tapi dina sistem anu gaduh set data anu ageung, LRU gampang nyababkeun thrashing - ngusir blok anu sering diperyogikeun pikeun masihan rohangan pikeun blok anu moal pernah dibaca deui tina cache.
mangrupakeun algoritma teuing kirang naif nu bisa dianggap "weighted" cache. Unggal waktos blok cache dibaca, éta janten langkung beurat sareng langkung hese diusir - komo saatos blok digusur. dilacak dina jangka waktu nu tangtu. Blok anu parantos digusur tapi teras kedah dibaca deui kana cache ogé bakal langkung beurat.
Hasil ahir sadaya ieu mangrupikeun cache kalayan rasio hit anu langkung luhur - rasio antara hits cache (dibaca tina cache) sareng kantun (dibaca tina disk). Ieu mangrupikeun statistik anu penting pisan - sanés ngan ukur cache anu nabrak sorangan dilayanan pesenan gedéna langkung gancang, cache misses ogé tiasa dilayanan langkung gancang, kumargi langkung seueur cache anu pencét, pangsaeutikna pamundut paralel ka disk sareng langkung handap latency pikeun anu sono sésana. nu kudu dilayanan ku disk.
kacindekan
Ayeuna urang parantos nutupan semantik dasar ZFS-kumaha cara copy-on-write, kitu ogé hubungan antara pools gudang, alat virtual, blok, séktor, sareng file-urang siap ngabahas kinerja dunya nyata sareng wilangan nyata.
Dina bagian salajengna, urang bakal nempo kinerja sabenerna mirrored vdev na RAIDz pools, dibandingkeun saling, sarta dibandingkeun jeung Linux Ubuntu kernel tradisional topologies RAID kami geus nalungtik. .
Mimitina urang ngan ukur hoyong nutupan dasarna - topologi ZFS sorangan - tapi saatosna ieu Kami bakal siap ngobrol ngeunaan konfigurasi anu langkung maju sareng tuning ZFS, kalebet panggunaan jinis vdev bantu sapertos L2ARC, SLOG sareng Alokasi Khusus.
sumber: www.habr.com