ZFS – Modern kor a tárolásban

A SUN forradalmi módon akarta az adattárolást, volumekezelést, filesystem gondokat megoldani, amikor megalkotta a ZFS (Zettabyte File System)-t. Azóta eléggé meghatározóvá vált maga a ZFS és mindaz a szemlélet amit magával hozott. Erről szeretnék egy összefoglalót nyújtani.

Kezdjük az elején azon dolgok összegyűjtésével ami megnehezíti a tárhelykezelést:

– Nevek, partíciók, volume-k, rendelekezésre állás, növelés, csökkentés, konfigurációs file-k tömege
– Limitek kezelése filesystemek, volume-k, file méretek, file számosságok, snapshotok esetén
– Külön 3rd party toolok a blokk és file alapú megosztások kezeléséhez
– Portolási problémák különböző platformok esetén (x86, SPARC, PowerPC, ARM, …)
– Lineáris létrehozási idő, fix blokk méretek, hosszadalmas RAID újraépítési idő, növekvő backup idők

Ezen dolgokon akar változtatni a SUN a zfs-el. Kezdjük az átlag felhasználó számára talán leglényegtelenebb dologgal, ami a Zettabyte névből fakad ami a tíz a huszonegyediket jelent. Ez a nagy szám már sok mindenre utal, többek között az új nagyságrendi korlátokkal is. A zfs ugyanis az átlag 64 bites rendszerekkel ellentétben 128 bites. Nézzük ez milyen új hatalmas korlátokat jelenthet a tárolásban:

• 2^64 — Number of snapshots of any file system
• 2^48 — Number of entries in any individual directory
• 6 EiB (2^64 bytes) — Maximum size of a file system
• 16 EiB — Maximum size of a single file
• 6 EiB — Maximum size of any attribute
• 256 ZiB (2^78 bytes) — Maximum size of any zpool
• 2^56 — Number of attributes of a file (actually constrained to 248 for the number of files in a ZFS file system)
• 2^64 — Number of devices in any zpool
• 2^64 — Number of zpools in a system
• 2^64 — Number of file systems in a zpool

ZFS Pool-ok

A ZFS szakítva a tradicionális volume managerekkel, amikre utána külön szeparált filesystem-et kellett rakni, egybeépítette a filesystem-et és a volumemanager-t. Viszont ezt nem úgy kell elképzelni, hogy egy termék, aminek van volume manager része, és filesystem része mint például a Veritas Storage Foundation-nek. A ZFS egy filesystem, ami egyben volume kezelésre is használható.

Hogy ezt jobban meg lehessen érteni bele kell magunkat ásni a szerkezetébe. A ZFS úgynevezett pool filozófiát követ. Egy közös zsákot, amibe egyik részről dobálunk erőforrásokat (diskeket), ezzel egy nagy közös név alatt létező adattömeget kapva, majd ebből az adat tömegből (pool-ból) oszthatunk ki tárolásra szánt filerendszereket.

Ez a pool dolog megfelel az SVM alatt egy metadevice-nak. A pool-t tehát maguk a fizikai diskek tesztesítik meg. A pool-nak lennie kell egy nevének, ami egy metadevice neveként funkcionálhat, amire hivatkozhatunk. A poolban pedig még azt kell tudnunk definiálni, hogy a fizikai diskek között milyen fajta RAID szintnek megfelelő kapcsolatot, tömbösítést kívánunk alkalmazni. Redundancia nélkül (hasonló mint a RAID 0), tükrözve (RAID 1) két vagy több eszközt, vagy RAID-Z csoportba három vagy több eszközt (egy elem kiesését tolerálja), vagy RAID-Z2 csoportba négy vagy több eszközt (két elem kiesését tolerálja). 2009 Júliusa óta a három paritásos RAID-Z3 technológia is elérhető az OpenSolaris-ban. Ezen túl poolokhoz opcionálisan adhatunk külön táró eszközöket hot spareként, illetve gyorsítótárként. Mint majd a lentebbi példákon látszik majd, nagyon könnyen megtehetjük ezt, egyszerű parancsok segítségével, a poolok bővítése, rendezése pedig szintén dinamikus és könnyű.

Ahogy SVM esetében, úgy ZFS esetében is vannak meta adatbázisok. Mi több a ZFS esetében ez sokkal fontosabb szereppel bír, mert az egész ZFS egy adminisztráció alapú meta adatbázis gyakorlatilag. Az úgynevezett Copy-on-Write alapú paradigmára épül, amit leegyszerűsítve úgy lehetne lehetne definiálni, mely fordítása talán „írás esetén másolás” lehetne – egy széles körben alkalmazott módszer a I/O műveleteinek optimalizálására. A copy-on-write jó példája az ún. lusta kiértékelés/végrehajtás (lazy evaluation) elvnek, ami azt mondja, hogy a rendszerben a költséges, vagyis sok erőforrást igénylő műveleteket el kell halasztani mindaddig, amíg azok végrehajtása már ténylegesen kikerülhetetlen nem lesz. Tehát a magát a műveletet lekönyveli a meta adabázisába, majd amikor jut idő, energia akkor ténylegesen kiírja lemezre is.

Ez az adminisztráció gyakorlatilag teljes optimalizálást tesz lehetővé a poolunk előlünk elrejtve megfelelőképp írja ki az adatokat a lemezekre, végez menetközbe optimalizálást, átszervezést, anélkül, hogy mi tudnánk, illetve, hogy foglalkozunk kellene vele.

Ebből a teljes adminisztrációból következik, hogy elég egyszerűen lehet klónozni, illetva snapshotot készíteni, hisz csak a megfelelő meta adatokat kell megduplikálni, és az utána következő módosításokat kezelni, amit a copy-on-write megoldás nagyben segít.

Limitációk és attribútomok

Az SVM-es hasonlatnál maradva, amikor létrejön egy metadevice az ugyan úgy használható, mint egy zpool. Persze a zpool a /ZPOOL_NEVE alatt egyből elérhető lesz, míg a metadevice esetében külön filesystem-et kell tennünk rá, és mountolni ahová szeretnénk. Szintén hasonló kép mint a softpartíciók esetében, a zpool esetében is lehetőségünk van filesystem-eket létrehozni a zpoolból. Amikor egy filesystemet csinálunk, az a /ZPOOL/FILESYSTEM_NEVE alatt egyből elérhető is lesz.

Alapvetően ez csak egy újabb meta adminisztrációs elem lesz. A létrejövő filesystem teljes semmilyen beállítással, vagy limitációval nem rendelkezik, így a pool összes erőforrását uralni tudja. Tehát az új filesystem-et testre kell szabnunk minden féle attributum, beállítás, limitáció megadásával. Talán a legfontosabb néhány:

– mountpoint path (mivel alapvetően a leírt struktúrában érhető el az új filesystem a mountpoint beállítás segítségével adhatjuk meg, amennyiben máshová szeretnénk mountolni)
– reservation (az adatmennyiség amit le akarunk foglalni ennek a filesystemnek, függetlenül hogy ki van e használva hogy nem)
– quota (ez csak egy felső limit amit nem léphet túl a filesystem, cserébe amennyiben más filesystemek felélik a zpool szabad kapacitását, hiába a filesystemünk nem érte el a quota határát előfordulhat, hogy nem tudunk majd már bele írni)
– compression (lehetőségünk van adattömörítés használatára, azaz x adatot ténylegesen csak y tárhelyre írunk ki, értelemszerűen x nagyobb y . Több féle tömörítő algoritmus is létezik)
– sharenfs/sharesmb (a meglővő filesystem-et egy kapcsoló segítségével meg is oszthatjuk hálózatunkon)

Deduplikáció

Megemlíteném ezt a nagyon friss újdonságot, ami jelenleg még csak a legújabb OpenSolarisokban érhető el. Ez a deduplikáció, és ahogy a nevéből is fakad az egyező adatok többszörös tárolását kivédendő szolgáltatás lenne. Kicsit talán hasonlíthatnám a tömörítéshez, de természetesen ez teljesen más.

Mikor hol használhatom a ZFS-t?

A Solaris 10 update 6 óta szerves része a ZFS a Solaris-nak, sőt még root filerendszernek is használható. Portolták már FreeBSD-re is. Sajnos a licenselése miatt a Linux kernel része nem lehet, csak userspace-ben futtatható FUSE rendszerekkel. A ZFS ennek ellenére, nyílt és szabadon fejleszthető bárki számára.

Egy hosszú példa a ZFS használatára