Idén tavasszal már megbeszéltünk néhány bevezető témát, pl. и . A másodikban még azt is megígértük, hogy folytatjuk a különböző többlemezes topológiák teljesítményének tanulmányozását a ZFS-ben. Ez a következő generációs fájlrendszer, amelyet most már mindenhol implementálnak: from a .
Nos, ma a legjobb nap a ZFS-szel, a kíváncsi olvasókkal való ismerkedésre. Csak tudd, hogy Matt Ahrens OpenZFS fejlesztő szerény véleménye szerint "ez nagyon nehéz".
Mielőtt azonban rátérnénk a számokra – és megígérem –, a nyolclemezes ZFS-konfiguráció összes lehetőségéről beszélnünk kell mint A ZFS általában a lemezen tárolja az adatokat.
Zpool, vdev és eszköz
Ez a teljes készletdiagram három kiegészítő vdevet tartalmaz, mindegyik osztályból egyet, és négyet a RAIDz2-hez
Általában nincs ok arra, hogy össze nem illő vdev típusú és méretű készletet hozzon létre – de semmi sem akadályozza meg ebben, ha akarja.
A ZFS fájlrendszer valódi megértéséhez alaposan meg kell vizsgálnia a tényleges szerkezetét. Először is, a ZFS egyesíti a kötet- és fájlrendszer-kezelés hagyományos szintjeit. Másodszor, tranzakciós másolás-írási mechanizmust használ. Ezek a tulajdonságok azt jelentik, hogy a rendszer szerkezetileg nagyon különbözik a hagyományos fájlrendszerektől és RAID-tömböktől. Az alapvető építőelemek első csoportja, amelyet meg kell érteni, a tárolókészlet (zpool), a virtuális eszköz (vdev) és a valós eszköz (eszköz).
zpool
A zpool tárolókészlet a legfelső ZFS-struktúra. Minden készlet egy vagy több virtuális eszközt tartalmaz. Viszont mindegyik tartalmaz egy vagy több valós eszközt (eszközt). A virtuális medencék önálló blokkok. Egy fizikai számítógép két vagy több különálló készletet tartalmazhat, de mindegyik teljesen független a többitől. A poolok nem oszthatnak meg virtuális eszközöket.
A ZFS redundanciája a virtuális eszköz szintjén van, nem a készlet szintjén. Egyáltalán nincs redundancia a készlet szintjén – ha bármelyik vdev vagy speciális vdev meghajtó elveszik, akkor az egész készlet elveszik vele együtt.
A modern tárolókészletek túlélhetik a gyorsítótár vagy a virtuális eszköznapló elvesztését – bár kis mennyiségű piszkos adatot veszíthetnek, ha áramkimaradás vagy rendszerösszeomlás során elveszítik a vdev-naplót.
Elterjedt tévhit, hogy a ZFS „adatsávok” a teljes készletre vannak írva. Ez nem igaz. A Zpool egyáltalán nem vicces RAID0, inkább vicces összetett változó eloszlási mechanizmussal.
A rekordok nagyrészt a rendelkezésre álló szabad hely szerint vannak szétosztva a rendelkezésre álló virtuális eszközök között, így elméletileg mind egyszerre töltődik be. A ZFS későbbi verzióiban az aktuális vdev-használatot (kihasználtságot) veszik figyelembe – ha az egyik virtuális eszköz jelentősen elfoglaltabb, mint a másik (például olvasási terhelés miatt), akkor a rendszer átmenetileg kihagyja az íráshoz, annak ellenére, hogy a legmagasabb szabad kapacitással rendelkezik. térarány.
A modern ZFS írási allokációs módszerekbe beépített kihasználtság-észlelő mechanizmus csökkentheti a késleltetést és növelheti az átviteli sebességet szokatlanul nagy terhelésű időszakokban – de nem korlátozás nélküli felhatalmazás a lassú HDD-k és a gyors SSD-k akaratlan keveredésén egy készletben. Egy ilyen egyenlőtlen pool továbbra is a leglassabb eszköz sebességével fog működni, vagyis mintha teljes egészében ilyen eszközökből állna.
vdev
Minden tárolókészlet egy vagy több virtuális eszközből áll (virtuális eszköz, vdev). Minden vdev egy vagy több valódi eszközt tartalmaz. A legtöbb virtuális eszközt egyszerű adattárolásra használják, de számos vdev helper osztály létezik, köztük a CACHE, a LOG és a SPECIAL. Ezen vdev típusok mindegyikének öt topológiája lehet: egyetlen eszköz (egy eszköz), RAIDz1, RAIDz2, RAIDz3 vagy tükör (tükör).
A RAIDz1, RAIDz2 és RAIDz3 különleges változatai annak, amit a régi idősek dupla (átlós) paritású RAID-nek neveztek. Az 1, 2 és 3 arra utal, hogy hány paritásblokk van lefoglalva az egyes adatsávokhoz. A paritáshoz külön lemezek helyett a RAIDz virtuális eszközök ezt a paritást félig egyenletesen osztják el a lemezek között. Egy RAIDz tömb annyi lemezt veszíthet, ahány paritásblokkja van; ha elveszít egy másikat, akkor összeomlik és magával viszi a tárolókészletet.
A tükrözött virtuális eszközökben (tükör vdev) minden blokk minden egyes eszközön tárolva van a vdev-ben. Bár a legelterjedtebbek a kétszéles tükrök, tetszőleges számú eszköz lehet egy tükörben – a nagy telepítéseknél gyakran hármasokat használnak a jobb olvasási teljesítmény és hibatűrés érdekében. A vdev tükör minden hibát túlél, amíg legalább egy eszköz a vdevben továbbra is működik.
Az egyetlen vdev-k eredendően veszélyesek. Egy ilyen virtuális eszköz egyetlen meghibásodást sem fog túlélni - és ha tárolóként vagy speciális vdev-ként használják, akkor meghibásodása az egész készlet megsemmisüléséhez vezet. Legyen itt nagyon-nagyon óvatos.
A CACHE, LOG és SPECIAL VA-k a fenti topológiák bármelyikével létrehozhatók – de ne feledje, hogy a SPECIÁLIS VA elvesztése a készlet elvesztését jelenti, ezért erősen ajánlott a redundáns topológia.
eszköz
Valószínűleg ez a legkönnyebben érthető kifejezés a ZFS-ben – ez szó szerint egy blokk véletlen hozzáférésű eszköz. Ne feledje, hogy a virtuális eszközök egyedi eszközökből állnak, míg a készlet virtuális eszközökből áll.
A lemezek – akár mágneses, akár félvezetős – a leggyakoribb blokkeszközök, amelyeket a vdev építőelemeiként használnak. Azonban minden olyan eszköz megteszi, amelynek a /dev leírója van, így a teljes hardveres RAID-tömbök különálló eszközként használhatók.
Az egyszerű nyers fájl az egyik legfontosabb alternatív blokkeszköz, amelyből vdev készíthető. Tesztmedencék innen nagyon praktikus módja annak, hogy ellenőrizze a pool parancsokat, és megtudja, mennyi hely áll rendelkezésre egy adott topológiájú készletben vagy virtuális eszközben.
Néhány másodperc alatt létrehozhat tesztkészletet ritka fájlokból – de utána ne felejtse el törölni a teljes készletet és annak összetevőit
Tegyük fel, hogy egy szervert nyolc lemezre szeretne helyezni, és 10 TB-os (~9300 GiB) lemezt szeretne használni – de nem biztos abban, hogy melyik topológia felel meg leginkább az igényeinek. A fenti példában egy tesztkészletet készítünk ritka fájlokból másodpercek alatt – és most már tudjuk, hogy egy nyolc 2 TB-os lemezből álló RAIDz10 vdev 50 TiB használható kapacitást biztosít.
Az eszközök másik speciális osztálya a SPARE (tartalék). Az üzem közben cserélhető eszközök a hagyományos eszközökkel ellentétben a teljes készlethez tartoznak, nem pedig egyetlen virtuális eszközhöz. Ha a készletben lévő vdev meghibásodik, és egy tartalék eszköz csatlakozik a készlethez és elérhető, akkor az automatikusan csatlakozik az érintett vdev-hez.
Az érintett vdev-hez való csatlakozás után a tartalék eszköz elkezdi fogadni a hiányzó eszközön található adatok másolatait vagy rekonstrukcióit. A hagyományos RAID-ben ezt újraépítésnek, míg a ZFS-ben resilveringnek hívják.
Fontos megjegyezni, hogy a tartalék eszközök nem helyettesítik tartósan a meghibásodott eszközöket. Ez csak egy ideiglenes csere a vdev leromlási idejének csökkentése érdekében. Miután az adminisztrátor lecseréli a meghibásodott vdev-et, a redundancia visszaáll az állandó eszközre, a SPARE pedig leválik a vdev-ről, és visszaáll tartalékként a teljes készletre.
Adatkészletek, blokkok és szektorok
A ZFS-utazásunk során megértendő építőelemek következő csoportja kevésbé a hardverről szól, hanem arról, hogyan szerveződnek és tárolódnak maguk az adatok. Itt kihagyunk néhány szintet – például a metaslab-et –, hogy ne zsúfoljuk el a részleteket, miközben megőrizzük a teljes szerkezet megértését.
Adatkészlet (adatkészlet)
Amikor először hozunk létre egy adatkészletet, az az összes rendelkezésre álló készletterületet mutatja. Ezután beállítjuk a kvótát – és módosítjuk a csatlakozási pontot. Varázslat!
A Zvol nagyrészt csak egy adatkészlet, amely megfosztotta a fájlrendszer rétegétől, amit itt egy teljesen normális ext4 fájlrendszerre cserélünk.
A ZFS-adatkészlet nagyjából megegyezik egy szabványos csatolt fájlrendszerrel. Mint egy hagyományos fájlrendszer, első pillantásra úgy tűnik, hogy "csak egy másik mappa". De csakúgy, mint a szokásos csatlakoztatható fájlrendszerek, minden ZFS-adatkészletnek megvannak a saját alapvető tulajdonságai.
Először is, egy adatkészlethez lehet hozzárendelt kvóta. Ha be van állítva zfs set quota=100G poolname/datasetname, akkor nem fog tudni írni a csatolt mappába /poolname/datasetname több mint 100 GiB.
Észreveszi a perjelek jelenlétét – és hiányát – az egyes sorok elején? Minden adatkészletnek megvan a maga helye mind a ZFS-hierarchiában, mind a rendszercsatlakozási hierarchiában. A ZFS-hierarchiában nincs bevezető perjel – a készlet nevével kezdődik, majd az egyik adatkészlettől a másikig vezető útvonal. Például, pool/parent/child nevű adatkészlethez child a szülő adatkészlet alatt parent kreatív nevű medencében pool.
Alapértelmezés szerint az adatkészlet csatolási pontja megegyezik a nevével a ZFS-hierarchiában, egy perjellel - a készlet neve pool mint /pool, adathalmaz parent beszerelve /pool/parentés a gyermek adatkészletet child beszerelve /pool/parent/child. Az adatkészlet rendszer-csatlakozási pontja azonban módosítható.
Ha megadjuk zfs set mountpoint=/lol pool/parent/child, majd az adatkészletet pool/parent/child mint a rendszerre szerelve /lol.
Az adathalmazok mellett meg kell említeni a köteteket (zvols). A kötet nagyjából ugyanaz, mint egy adatkészlet, azzal a különbséggel, hogy valójában nincs fájlrendszere – ez csak egy blokkeszköz. Például létrehozhat zvol Névvel mypool/myzvol, majd formázza meg egy ext4 fájlrendszerrel, majd csatolja be azt a fájlrendszert – most már van egy ext4 fájlrendszere, de a ZFS összes biztonsági funkciójával! Ez egyetlen gépen hülyének tűnhet, de sokkal értelmesebb háttérrendszerként iSCSI-eszköz exportálásakor.
Blocks
A fájlt egy vagy több blokk képviseli. Minden blokk egy virtuális eszközön van tárolva. A blokk mérete általában megegyezik a paraméterrel rekordméret, de redukálható 2^ műszakha metaadatokat vagy kis fájlt tartalmaz.
Mi tényleg tényleg nem viccel a hatalmas teljesítménybüntetéssel, ha túl kicsi váltást állít be
A ZFS-készletben minden adat, beleértve a metaadatokat is, blokkban tárolódik. Az egyes adatkészletek maximális blokkmérete a tulajdonságban van meghatározva recordsize (rekord méret). A rekord mérete módosítható, de ez nem változtatja meg az adatkészletbe már beírt blokkok méretét vagy helyét - ez csak az új blokkokat érinti, ahogyan írják.
Eltérő rendelkezés hiányában az aktuális alapértelmezett rekordméret 128 KiB. Ez egyfajta trükkös kompromisszum, ahol a teljesítmény nem tökéletes, de a legtöbb esetben nem is szörnyű. Recordsize tetszőleges értékre állítható 4K és 1M között (speciális beállításokkal recordsize telepíthet még többet is, de ez ritkán jó ötlet).
Bármely blokk csak egy fájl adataira vonatkozik – nem zsúfolhat két különböző fájlt egy blokkba. Minden fájl egy vagy több blokkból áll, mérettől függően. Ha a fájl mérete kisebb, mint a rekordméret, akkor a rendszer kisebb blokkméretben tárolja – például egy 2 KiB-os fájlt tartalmazó blokk csak egy 4 KiB-os szektort foglal el a lemezen.
Ha a fájl elég nagy, és több blokkot igényel, akkor az ezzel a fájllal rendelkező rekordok mérete megfelelő lesz recordsize - beleértve az utolsó bejegyzést is, melynek fő része lehet .
zvols nem rendelkezik ingatlannal recordsize — ehelyett egyenértékű tulajdonságuk van volblocksize.
Szektorok
Az utolsó, legalapvetőbb építőelem a szektor. Ez a legkisebb fizikai egység, amely az alapul szolgáló eszközre írható vagy olvasható. Több évtizeden át a legtöbb lemez 512 bájtos szektorokat használt. Mostanában a legtöbb lemez 4 KiB szektorra van beállítva, és egyesek – különösen az SSD-k – 8 KiB szektorral vagy még ennél is többel rendelkeznek.
A ZFS rendszer rendelkezik egy tulajdonsággal, amely lehetővé teszi a szektor méretének manuális beállítását. Ez az ingatlan ashift. Kissé zavaró, hogy az ashift a kettő hatványa. Például, ashift=9 a szektor mérete 2^9, vagyis 512 bájt.
A ZFS részletes információkat kér az operációs rendszertől minden egyes blokkeszközről, amikor új vdev-hez adják, és elméletileg automatikusan megfelelően telepíti az Ashift-et ezen információk alapján. Sajnos sok meghajtó hazudik a szektorméretéről, hogy fenntartsa a kompatibilitást a Windows XP-vel (amely nem tudta megérteni a más szektorméretű meghajtókat).
Ez azt jelenti, hogy a ZFS-adminisztrátoroknak erősen ajánlott ismerni eszközeik tényleges szektorméretét, és manuálisan beállítani ashift. Ha az eltolás túl alacsonyra van állítva, akkor az olvasási/írási műveletek száma csillagászatilag megnő. Tehát az 512 bájtos "szektorok" írása egy valódi 4 KiB-os szektorba azt jelenti, hogy meg kell írni az első "szektort", majd be kell olvasni a 4 KiB-os szektort, módosítani kell egy második 512 bájtos "szektorral", vissza kell írni az újba. 4 KiB szektor, és így tovább.
A való világban ilyen büntetés éri a Samsung EVO SSD-ket, amiért ashift=13, de ezek az SSD-k hazudnak a szektorméretükről, ezért az alapértelmezett értékre van állítva ashift=9. Ha egy tapasztalt rendszergazda nem módosítja ezt a beállítást, akkor ez az SSD működik lassabban hagyományos mágneses HDD.
Összehasonlításképpen túl nagy mérethez ashift gyakorlatilag nincs büntetés. Nincs valódi teljesítménybüntetés, és a kihasználatlan terület növekedése végtelenül kicsi (vagy nulla, ha a tömörítés engedélyezett). Ezért azt javasoljuk, hogy még azokat a meghajtókat is telepítse, amelyek 512 bájtos szektorokat használnak ashift=12 vagy ashift=13hogy magabiztosan nézzen szembe a jövővel.
Ingatlan ashift be van állítva minden egyes vdev virtuális eszközhöz, és nem a medencéhez, ahogy sokan tévesen gondolják – és a telepítés után sem változik. Ha véletlenül megütötte ashift Amikor új vdev-t adsz a készlethez, akkor helyrehozhatatlanul beszennyezted azt a készletet egy alacsony teljesítményű eszközzel, és általában nincs más választásod, mint megsemmisíteni a készletet és újrakezdeni. Még a vdev eltávolítása sem ment meg a hibás konfigurációtól ashift!
Másolás írásra mechanizmus
Ha egy normál fájlrendszernek felül kell írnia az adatokat, akkor minden blokkot megváltoztat, ahol vannak
A másolás írásra fájlrendszer új blokkverziót ír, majd feloldja a régi verzió zárolását
Absztrakt módon, ha figyelmen kívül hagyjuk a blokkok tényleges fizikai elhelyezkedését, akkor az "adatüstökösünk" leegyszerűsödik egy "adatféreggé", amely balról jobbra mozog a rendelkezésre álló tér térképén.
Most már jó ötletet kaphatunk a másolás az írásra pillanatképek működéséről - minden blokk több pillanatkép birtokában is lehet, és mindaddig megmarad, amíg az összes kapcsolódó pillanatkép meg nem semmisül.
A Copy on Write (CoW) mechanizmus az alapvető alapja annak, ami a ZFS-t ilyen csodálatos rendszerré teszi. Az alapkoncepció egyszerű – ha egy hagyományos fájlrendszert kér meg egy fájl megváltoztatására, az pontosan azt fogja tenni, amit kért. Ha megkér egy másolás-írásra fájlrendszert, hogy tegye meg ugyanezt, azt fogja mondani, hogy "ok", de hazudik neked.
Ehelyett a másolás írásra fájlrendszer megírja a módosított blokk új verzióját, majd frissíti a fájl metaadatait a régi blokk összekapcsolásának megszüntetése és az éppen írt új blokk társítása érdekében.
A régi blokk leválasztása és az új összekapcsolása egy műveletben történik, így nem szakítható meg - ha ez megtörténik, akkor a fájl új verziója van, ha pedig korán, akkor a régi verzió. . Mindenesetre nem lesznek ütközések a fájlrendszerben.
A ZFS-ben a másolás írásra nem csak a fájlrendszer szintjén történik, hanem a lemezkezelés szintjén is. Ez azt jelenti, hogy a ZFS-t nem befolyásolja a szóköz () - olyan jelenség, amikor a szalagnak csak részben volt ideje rögzíteni a rendszer összeomlása előtt, újraindítás után tömbsérüléssel. Itt a csík atomszerűen van írva, a vdev mindig szekvenciális, és .
ZIL: ZFS szándéknapló
A ZFS rendszer a szinkron írásokat különleges módon kezeli – ideiglenesen, de azonnal eltárolja a ZIL-ben, mielőtt később az aszinkron írásokkal együtt véglegesen megírná.
A ZIL-be írt adatok általában soha többé nem kerülnek beolvasásra. De lehetséges a rendszer összeomlása után
A SLOG vagy másodlagos LOG eszköz csak egy speciális - és lehetőleg nagyon gyors - vdev, ahol a ZIL a fő tárolótól elkülönítve tárolható
Összeomlás után a ZIL-ben lévő összes piszkos adat újrajátszásra kerül - ebben az esetben a ZIL a SLOG-on van, tehát onnan játssza vissza
Az írási műveleteknek két fő kategóriája van: szinkron (szinkron) és aszinkron (aszinkron). A legtöbb munkaterhelésnél az írások túlnyomó többsége aszinkron – a fájlrendszer lehetővé teszi azok összesítését és kötegelt kiadását, csökkentve a töredezettséget és nagymértékben növelve az átviteli sebességet.
A szinkronizált felvételek egészen más tészta. Amikor egy alkalmazás szinkron írást kér, azt mondja a fájlrendszernek: "Ezt a nem felejtő memóriába kell véglegesítenie. mostaddig nem tehetek mást." Ezért a szinkron írásokat azonnal lemezre kell helyezni – és ha ez növeli a töredezettséget vagy csökkenti az átviteli sebességet, akkor legyen.
A ZFS másképp kezeli a szinkron írásokat, mint a hagyományos fájlrendszerek – ahelyett, hogy azonnal lefoglalná őket a normál tárhelyen, a ZFS egy speciális tárolóterületen, a ZFS Intent Log (ZIL) néven véglegesíti azokat. A trükk az, hogy ezek a rekordok is a memóriában marad, a normál aszinkron írási kérelmekkel együtt összesítve, hogy később teljesen normál TXG-ként (tranzakciócsoportként) a tárhelyre kerüljön.
Normál működés közben a ZIL-be íródik, és soha többé nem olvasható. Amikor néhány pillanat múlva a ZIL rekordjai a RAM-ból a normál TXG-k fő tárolójába kerülnek, leválasztják őket a ZIL-ről. A ZIL-ből csak a készlet importálásakor lehet olvasni valamit.
Ha a ZFS meghibásodik – az operációs rendszer összeomlása vagy áramkimaradás – miközben vannak adatok a ZIL-ben, akkor az adatok a következő készletimportálás során kerülnek beolvasásra (például a vészhelyzeti rendszer újraindításakor). Bármi, ami a ZIL-ben található, beolvasásra kerül, TXG-kbe csoportosítva, a fő tárolóhoz kötődik, majd az importálási folyamat során leválik a ZIL-ről.
Az egyik vdev segítő osztály a LOG vagy SLOG, a LOG másodlagos eszköze. Egyetlen célja van – hogy a készletet külön, lehetőleg sokkal gyorsabb, nagyon írásálló vdev-vel láthassa el a ZIL tárolására, ahelyett, hogy a ZIL-t a fő vdev tárolóban tárolná. Maga a ZIL ugyanúgy viselkedik, függetlenül attól, hogy hol van tárolva, de ha a LOG vdev nagyon nagy írási teljesítménnyel rendelkezik, a szinkron írás gyorsabb lesz.
LOG-val rendelkező vdev hozzáadása a készlethez nem működik nem tud javítja az aszinkron írási teljesítményt – még akkor is, ha minden írást a ZIL-re kényszerít zfs set sync=always, továbbra is ugyanúgy és ugyanolyan ütemben kapcsolódnak a TXG fő tárolójához, mint a napló nélkül. Az egyetlen közvetlen teljesítményjavulás a szinkron írások késleltetése (mivel a gyorsabb naplózás felgyorsítja a műveleteket). sync).
Egy olyan környezetben azonban, amely már sok szinkron írást igényel, a vdev LOG közvetve felgyorsíthatja az aszinkron írást és a nem gyorsítótárazott olvasást. A ZIL-bejegyzések külön vdev LOG-ba való áthelyezése kevesebb versengést jelent az IOPS-ért az elsődleges tárolón, ami bizonyos mértékig javítja az összes olvasási és írási teljesítményt.
Pillanatképek
A másolás írásra mechanizmus szintén szükséges alapja a ZFS atomi pillanatképeinek és a növekményes aszinkron replikációnak. Az aktív fájlrendszer rendelkezik egy mutatófával, amely az összes rekordot megjelöli az aktuális adatokkal – amikor pillanatfelvételt készít, egyszerűen másolatot készít erről a mutatófáról.
Amikor egy rekordot felülírnak az aktív fájlrendszeren, a ZFS először a blokk új verzióját írja a fel nem használt területre. Ezután leválasztja a blokk régi verzióját az aktuális fájlrendszerről. De ha néhány pillanatkép a régi blokkra hivatkozik, az továbbra is változatlan marad. A régi blokk valójában nem kerül visszaállításra szabad területként, amíg az erre a blokkra hivatkozó összes pillanatfelvétel meg nem semmisül!
Replikáció
A Steam könyvtáram 2015-ben 158 GiB volt, és 126 927 fájlt tartalmazott. Ez elég közel áll az rsync optimális helyzetéhez – a hálózaton keresztüli ZFS replikáció "csak" 750%-kal volt gyorsabb.
Ugyanazon a hálózaton egy 40 GB-os Windows 7 virtuálisgép-képfájl replikálása teljesen más történet. A ZFS-replikáció 289-szer gyorsabb, mint az rsync – vagy „csak” 161-szer gyorsabb, ha elég okos ahhoz, hogy az rsync-et --inplace segítségével hívja meg.
Amikor egy virtuálisgép-lemezkép méretezve van, az rsync-problémák átméretezik vele. Az 1,9-es TiB nem olyan nagy egy modern virtuális gépképhez, de elég nagy ahhoz, hogy a ZFS-replikáció 1148-szor gyorsabb, mint az rsync, még az rsync --inplace argumentumával is
Miután megértette a pillanatképek működését, könnyen megértheti a replikáció lényegét. Mivel a pillanatkép csak a rekordokra mutató mutatók fája, ebből az következik, hogy ha így teszünk zfs send pillanatképet, akkor elküldjük ezt a fát és a hozzá tartozó összes rekordot is. Amikor ezt elküldjük zfs send в zfs receive a célon a blokk tényleges tartalmát és a blokkra hivatkozó mutatók fáját is a céladatkészlethez írja.
A dolgok a másodiknál még érdekesebbek lesznek zfs send. Jelenleg két rendszerünk van, mindegyik tartalmaz poolname/datasetname@1, és új pillanatképet készít poolname/datasetname@2. Ezért az eredeti medencében van datasetname@1 и datasetname@2, és a célkészletben eddig csak az első pillanatfelvétel datasetname@1.
Mivel közös pillanatképünk van a forrás és a cél között datasetname@1, meg tudjuk csinálni járulékos zfs send felette. Amikor azt mondjuk a rendszernek zfs send -i poolname/datasetname@1 poolname/datasetname@2, két mutatófát hasonlít össze. Bármilyen mutató, amely csak a következőben létezik @2, nyilvánvalóan új blokkokra utalnak - tehát szükségünk van ezeknek a blokkoknak a tartalmára.
Távoli rendszeren egy növekmény feldolgozása send ugyanolyan egyszerű. Először minden új bejegyzést írunk a streambe send, majd adjon hozzá mutatókat ezekhez a blokkokhoz. Voila, megvan @2 az új rendszerben!
A ZFS aszinkron növekményes replikációja hatalmas előrelépés a korábbi, nem pillanatfelvétel alapú módszerekhez, például az rsynchez képest. Mindkét esetben csak a megváltozott adatok kerülnek átvitelre – de először az rsync-nek kell lennie olvas a lemezről az összes adatot mindkét oldalon, hogy ellenőrizze az összeget és hasonlítsa össze. Ezzel szemben a ZFS-replikáció nem olvas mást, csak mutatófákat – és minden olyan blokkot, amely nem szerepel a megosztott pillanatképen.
Beépített tömörítés
A másolás írásra mechanizmus a beépített tömörítési rendszert is leegyszerűsíti. Egy hagyományos fájlrendszerben a tömörítés problémás – a módosított adatok régi verziója és új verziója is ugyanazon a helyen található.
Ha figyelembe vesszük egy fájl közepén lévő adatot, amely 0x00000000 és így tovább nullák megabájtjaként indul, akkor nagyon könnyű egy szektorba tömöríteni a lemezen. De mi történik, ha ezt a megabájt nullát lecseréljük egy megabájt tömöríthetetlen adatra, például JPEG-re vagy pszeudovéletlen zajra? Ez a megabájt adat váratlanul nem egy, hanem 256 4 KiB szektort igényel, és ezen a helyen a lemezen csak egy szektor van lefoglalva.
A ZFS-nél nincs ilyen probléma, mivel a módosított rekordok mindig fel nem használt területre íródnak - az eredeti blokk csak egy 4 KiB-os szektort foglal el, az új rekord pedig 256-ot, de ez nem probléma - egy nemrég módosított töredék a " középső része a fel nem használt területre íródik, függetlenül attól, hogy a mérete változott-e vagy sem, így a ZFS esetében ez meglehetősen szokásos helyzet.
A natív ZFS-tömörítés alapértelmezés szerint le van tiltva, és a rendszer csatlakoztatható algoritmusokat kínál – jelenleg LZ4, gzip (1-9), LZJB és ZLE.
- LZ4 egy streaming algoritmus, amely rendkívül gyors tömörítést és kitömörítést, valamint teljesítményelőnyöket kínál a legtöbb felhasználási esetben – még meglehetősen lassú CPU-kon is.
- GZIP egy tiszteletreméltó algoritmus, amelyet minden Unix-felhasználó ismer és szeret. Megvalósítható 1-9 tömörítési fokozatokkal, a tömörítési arány és a CPU-használat a 9-es szinthez közeledve növekszik. Az algoritmus minden szöveges (vagy más erősen tömöríthető) felhasználási esetre alkalmas, de egyébként gyakran okoz CPU-problémákat – használd óvatosan, különösen magasabb szinteken.
- LZJB ez az eredeti algoritmus a ZFS-ben. Elavult, már nem szabad használni, az LZ4 minden tekintetben felülmúlja.
- ROSSZUL - nulla szintű kódolás, nulla szintű kódolás. Egyáltalán nem érinti a normál adatokat, hanem nagy számú nulla-sorozatot tömörít. Hasznos a teljesen tömöríthetetlen adatkészletek (például JPEG, MP4 vagy más, már tömörített formátumok) esetén, mivel figyelmen kívül hagyja a tömöríthetetlen adatokat, de tömöríti a fel nem használt helyet az eredményül kapott rekordokban.
Az LZ4 tömörítést szinte minden felhasználási esetre ajánljuk; a teljesítménybüntetés, ha nem tömöríthető adatokkal találkozik, nagyon kicsi, és növekedés a tipikus adatok teljesítménye jelentős. Virtuális gép képének másolása a Windows operációs rendszer új telepítéséhez (frissen telepített operációs rendszer, még nincsenek benne adatok) compression=lz4 27%-kal gyorsabban sikerült, mint compression=none-Ban .
ARC – adaptív cseregyorsítótár
A ZFS az egyetlen olyan modern fájlrendszer, amelyről tudunk, és amely saját olvasási gyorsítótárazási mechanizmusát használja, ahelyett, hogy az operációs rendszer oldalgyorsítótárára hagyatkozna, hogy a nemrég olvasott blokkok másolatait a RAM-ban tárolja.
Bár a natív gyorsítótár nem problémamentes, a ZFS nem tud olyan gyorsan válaszolni az új memóriafoglalási kérésekre, mint a kernel, így az új kihívás malloc() a memóriafoglalás meghiúsulhat, ha szüksége van az ARC által jelenleg elfoglalt RAM-ra. De jó okai vannak a saját gyorsítótár használatának, legalábbis egyelőre.
Az összes ismert modern operációs rendszer, köztük a MacOS, a Windows, a Linux és a BSD, az LRU (Least Recently Used) algoritmust használja az oldal gyorsítótárának megvalósításához. Ez egy primitív algoritmus, amely minden olvasás után a gyorsítótárazott blokkot "feljebb a sorban" tolja, és a blokkokat szükség szerint "le a sorban" új gyorsítótár-kihagyások hozzáadásához (olyan blokkok, amelyeket a lemezről kellett volna beolvasni, nem a gyorsítótárból). fel.
Az algoritmus általában jól működik, de a nagy működő adatkészletekkel rendelkező rendszereken az LRU könnyen összetöréshez vezet – a gyakran szükséges blokkokat kilöki, hogy helyet adjon a gyorsítótárból soha többé nem olvasható blokkoknak.
egy sokkal kevésbé naiv algoritmus, amely egy "súlyozott" gyorsítótárnak tekinthető. Minden alkalommal, amikor egy gyorsítótárazott blokkot beolvasnak, az egy kicsit "nehezebb" lesz, és nehezebb lesz kilakoltatni – és még egy blokk kilakoltatása után is lánctalpas egy bizonyos időn belül. A kiürített, de a gyorsítótárba visszaolvasandó blokk is "nehezebb" lesz.
Mindennek végeredménye egy jóval magasabb találati aránnyal rendelkező gyorsítótár, a cache-találatok (a cache-ből végrehajtott olvasások) és a cache miss-ek (lemezről olvasások) aránya. Ez egy rendkívül fontos statisztika – nemcsak maguk a gyorsítótár-találatok szolgálnak ki nagyságrendekkel gyorsabban, hanem a gyorsítótár-kihagyások is gyorsabban teljesíthetők, mivel minél több gyorsítótár-lekérést kap, annál kevesebb az egyidejű lemezkérés, és annál kisebb a késleltetés azon fennmaradó hiányosságok számára lemezzel szolgálják fel.
Következtetés
Miután megtanultuk a ZFS alapvető szemantikáját - a másolás-írás működését, valamint a tárolókészletek, virtuális eszközök, blokkok, szektorok és fájlok közötti kapcsolatokat - készen állunk arra, hogy megvitassuk a valós teljesítményt valós számokkal.
A következő részben áttekintjük a tükrözött vdeveket és RAIDz-t használó készletek tényleges teljesítményét egymáshoz képest, valamint a hagyományos Linux kernel RAID topológiákkal, amelyeket megvizsgáltunk. .
Eleinte csak az alapokat szerettük volna kitérni – magukra a ZFS topológiákra –, de utána ilyen a Készüljünk fel arra, hogy beszéljünk a ZFS fejlettebb beállításáról és hangolásáról, beleértve az olyan kiegészítő vdev típusok használatát, mint az L2ARC, SLOG és a Special Allocation.
Forrás: will.com