Helyi fájlrendszerek
Egy helyi fájlrendszerben a fájlrendszer az alkalmazást futtató kiszolgálóval közösen van elhelyezve. A fájlrendszer természetéből adódóan a helyi fájlrendszerek korlátozott méretezhetőséggel rendelkeznek, és nem teszik lehetővé az adatmegosztást ügyfelek között a saját hálózaton:
8. ábra: Helyi fájlrendszerek1
A lemezen tárolt adatok általában blokkokként, vagy folytonos, strukturálatlan bájtgyűjteményként vannak megjelenítve. A helyi fájlrendszerek fájlabsztrakciókat nyújtanak, amelyek fájlokat képviselő blokkgyűjtemények.
A helyi fájlrendszereket használó alkalmazásokat nem érinti a fájlok fizikai reprezentációja az adathordozón, a fájlkérelmenként átvitt adatmennyiség (más néven rekordméret), az adathordozók közti adatátvitel egysége (más néven blokkméret) és hasonlók. Az ilyen alacsony szintű részleteket a helyi fájlrendszerek kezelik, illetve hatékonyan elválasztják a felhasználói alkalmazásoktól. Elvben a helyi fájlrendszerek a felhőbeli fájlrendszertípusok alapvető építőelemei. Az elosztott fájlrendszerek például (mint a Hadoop elosztott fájlrendszer, amely a Google fájlrendszerre hasonlít)2 és a párhuzamos fájlrendszerek (például a PVFS) több, egymással együttműködő helyi fájlrendszeren alapul, és ezekben működik. A virtuális és fizikai gépek felhőbeli és egyéb rendszerek szoftveres és hardveres meghibásodásainak tűrése részben attól függ, hogy a helyi fájlrendszerek milyen hatékonyan tudják kezelni ezeket az összeomlásokat. Röviden tehát szinte minden fájlrendszer, legyen az megosztott vagy hálózati, a helyi fájlrendszereken alapul.
9. ábra: A fájlrendszer elrendezése
A UNIX fájlrendszer egy klasszikus helyi fájlrendszer, amelyet az 1970-es években terveztek, és azóta széles körben használják több formában is (FFS, EXT-2 stb.). Bár a fájlokban lévő adatok blokksorozatként vannak elosztva egy táreszközön, a fájlrendszer fenntartja a fájl absztrakcióját annak társított adataival együtt. Ahogy az előző ábrán is látható, egy alapszintű helyi fájlrendszer tartalmaz egy rendszerindító blokkot, egy szuperblokkot, egy I-listát és egy adatrégiót. A rendszerindító blokk tartalmazza az operációs rendszer indításakor annak bináris képét a memóriába beolvasó programot. A blokknak lényegében nincs köze a fájlrendszer kezelési folyamataival és funkcióival. A szuperblokk ismerteti a helyi fájlrendszer elrendezését és jellemzőit, így anak méretét, a blokkméretet, a blokkok számát, az I-lista méretét és helyét és így tovább.
Az I-listában az egyes fájlok állapota UNIX inode-ként (indexcsomópontként, az alábbi ábrán látható módon) jelenik meg. Az inode egy fájl elsődleges adatstruktúrája, és a fájl metaadatait tárolja, beleértve a tár egyes fájlblokkjainak mutatóit, a tulajdonosi és a hozzáférés-vezérlési listákat, a fájl utolsó hozzáférésének időbélyegét és hasonlókat.
10. ábra: Fájlok, inódok és blokkok1
Helyi fájlrendszer például az NTFS, a FAT és az EXT. A helyi fájlrendszerek méretezhetősége, teljesítménye és megosztási korlátai megosztott/hálózati fájlrendszerek használatával bővíthetők.
POSIX I/O-szabványok
A Portable Operating System Interface (POSIX) olyan szabványcsalád, amely az operációs rendszer felületeit definiálja számos UNIX és UNIX-szerű operációs rendszerhez. A POSIX fájlrendszer szabványait gyakran használják UNIX és UNIX-szerű operációs rendszerekben használható fájlrendszerek várt funkcióinak ismertetéséhez.
A POSIX a következő szabványos műveleteket határozza meg a fájlokon: open, read, write és close. A POSIX-szabványok emellett lehetővé teszik, hogy az ilyen fájlrendszerek közvetlenül egy UNIX vagy UNIX-szerű operációs rendszerhez legyenek csatlakoztatva anélkül, hogy a fájlrendszer felügyeletéhez speciális illesztőprogram/ügyfélfolyamatra lenne szükség.
Kernelszintű és felhasználói szintű fájlrendszerek
A kernelszintű fájlrendszerek olyan fájlrendszerek, amelyek kernelszintű API-t tartalmaznak, ami azt is jelenti, hogy a fájlrendszert használó kód a kernelben található. UNIX és UNIX-szerű operációs rendszerek esetén ezek az API-k modulként töltődnek be. Az UNIX-szerű operációs rendszerek kernelszintű fájlrendszeri általában POSIX-kompatibilisek, és gyakran helyi fájlrendszerekre vannak korlátozva.
A felhasználói szintű fájlrendszerek felhasználói térben működnek, és nem kerneltérben. Az ilyen fájlrendszerek felületein a fájlrendszer API-ja hordozható, így sokkal több kliensen telepíthető. Számos elosztott és hálózati fájlrendszer van a felhasználói szinthez kialakítva, amely alól az egyetlen kivétel az AFS, amely kernelszintű illesztőprogramot használt a Linuxban.
Helyi fájlrendszerek kialakítási szempontjai
A helyi fájlrendszerek kialakításának megismeréséhez fontos megérteni a mögöttes adathordozót. Ebben a szakaszban feltételezzük, hogy az adathordozó egy forgólemez.
A helyi fájlrendszerek úgy vannak kialakítva, hogy a fájlok lemezkapacitásának kiosztásakor minimalizálják a keresési és fordulati időt, így javítva a rendszer teljesítményét. A helyi fájlrendszerek emellett maximalizálhatják a keresési és fordulati idő meghatározása után átvitt hasznos adatok mennyiségét. Egy hatékony helyi fájlrendszer kialakításának legfőbb feltétele a teljesítmény. Az adathordozók, például a lemezek és mágneses szalagok az elsődleges tárakkal (például memóriával vagy gyorsítótárakkal) ellentétben nem nyújtanak egységes hozzáférési időket. Ennek következtében a helyi fájlrendszernek a mögöttes adathordozót kell teljes mértékben kihasználnia az elfogadható rendszerteljesítmény eléréséhez, valamint a felesleges területhasználat elkerüléséhez. A felesleges tárhasználat elkerülése létfontosságú, különösen a felhőben, ahol a rendszererőforrások kihasználtságának nagy jelentősége van.
Teljesítmény
A teljesítmény javítása érdekében a helyi fájlrendszerek különböző stratégiákat alkalmazhatnak. A helyi fájlrendszerek blokkcímeket tárolhatnak a fájl inode-jában (egészen pontosan annak lemeztérképén). A helyi fájlrendszerek először is a memóriában gyorsítótárazhatják az inode-okat, így csökkenthetik a blokkhelyek olvasásához/írásához szükséges lemezelérések számát. Másodszor, a hasznos adatátvitel mennyiségének maximalizálása érdekében a helyi fájlrendszerek megnövelhetik a blokkok méretét. Harmadszor, a keresési idő minimalizálása érdekében az elhelyezkedést is kihasználhatják. Ennek fényében a közeljövőben várhatóan hozzáfért blokkok a lemezen egymáshoz közel tárolhatók, így az egyes fájlok blokkjait egymáshoz a lehető legközelebb kell tárolni. Továbbá, mivel a inode-ok az adatblokkjaikkal együtt érhetők el, ezeket is egymáshoz közel kell tárolni. És mivel egy könyvtár inode-jait gyakran egyszerre vizsgáljuk (például ls –la), egy adott könyvtár fájlainak inode-jait egymáshoz közel kell elhelyezni. Negyedszer, a fordulati késés csökkentése érdekében a hengerek fájljainak blokkjait úgy kell elhelyezni, hogy a keresési idő letelése után további fordulati késések nélkül beolvashatók legyenek. Ez az elrendezés javítja a teljesítményt, különösen, ha a blokkokat sorozatosan kérik le. Ha a blokkokat azonban véletlenszerűen kérik le, nehéz kihasználni a henger ezen blokkelrendezését úgy, hogy az csökkentse a fordulati késést. Végül pedig, amikor egy helyi fájlrendszer egy kért blokkot olvas be, ezzel egyidejűleg előre beolvashat olyan blokkokat, amelyekhez várhatóan hozzá szeretnének férni a közeljövőben. Ami azt illeti, számos helyi fájlrendszer (például az Ext2 és a későbbi verziók) stratégiája egyszerre több blokk használatát magában foglaló stratégiát alkalmaz (blokkfürtözést), amelynek keretében egyszerre nyolc folytonos blokkot foglal le. Az operációs rendszer pufferelheti vagy gyorsítótárazhatja is a blokkokat jövőbeli használathoz.
Bár a fájlrendszerek hagyományosan a mágneses merevlemezek teljesítményének optimalizálásához készültek, számos mai fájlrendszer rendelkezik SSD-khez készített működési módokkal, amelyek nem tartalmaznak lemezoptimalizációkat, viszont új funkciókkal javítják az SSD-k teljesítményét és fenntartását.
Megbízhatóság
A hatékony helyi fájlrendszerek tervezésének egy másik fő feltétele a megbízhatóság. A megbízhatóság a felhőbeli tárolásnak is fő szempontja. A helyi fájlrendszereknek megbízhatónak kell lenniük, a tárolt adatoknak tehát mindig elérhetőnek kell lenniük. Az adatoknak így hatékonyan tűrniük kell a szoftveres és hardveres összeomlásokat. Emellett a helyi fájlrendszereknek biztosítaniuk kell a tárolt adatok konzisztenciáját. Egy fájl írásához, létrehozásához, törléséhez és átnevezéséhez több lemezművelet végrehajtására lehet szükség, amelyek az adatokra és metaadatokra is hatással vannak. Ahhoz, hogy meggyőződjön arról, hogy a mögöttes helyi fájlrendszer képes tolerálni az összeomlásokat, arról kell meggyőződnie, hogy mindegyik ilyen művelet konzisztens állapotból konzisztens állapotba helyezi a rendszert. Egy fájl egy másik könyvtárba való áthelyezése – ami létrehozási és törlési műveleteket is tartalmaz – például inkonzisztens fájlrendszerállapotot eredményezhet. Összeomolhat például a rendszer egy fájl áthelyezésekor, így a fájl mindkét könyvtárból eltűnik, az eredetiből és a célkönyvtárból is. Ezen kockázat elkerülése érdekében a helyi fájlrendszernek először létre kell hoznia a fájlt a célhelyen, majd eltávolítania az előző könyvtárból (miután a fájl véglegesítése megtörtént az új könyvtárban).
Több lépésből álló fájlrendszerműveletek
Egyes fájlműveletekhez több olvasási vagy írási lépésre lehet szükség. Ezeket több lépésből álló fájlrendszerműveleteknek nevezzük. Nagy mennyiségű adat egy fájlba való írásakor például több különálló lemezművelet jöhet létre (ami a felhőkörnyezetekben megszokott). Ha az összes szükséges adat írásának befejezése előtt a rendszer összeomlik, a helyi fájlrendszer állapotában csak az írási művelet egy része készült el. A többlépéses műveletek kezelésének egy népszerű módja az elemi tranzakciók használata. Elemi tranzakciók esetén, ha a rendszer egy több lépésből álló művelet bármelyik szakaszánál összeomlik, vagy egyáltalán nem megy végbe a művelet, vagy teljes mértékben lezajlik. A tranzakciók az adatbázisrendszerek szabványos elemei, amelyeket az adatbázisokról szóló szakaszban ismertetünk.
Az egyik alapvető séma a helyi fájlrendszerek elemi tranzakcióinak bevezetéséhez a naplózás. A naplózás során a rendszer először egy speciális naplófájlba írja a tranzakció lépéseit a lemezen. A lépések biztonságos rögzítése, valamint a művelet véglegesítése (azaz teljes teljesítése) után a lépések a fájlrendszerre is alkalmazhatók. Ha a rendszer összeomlik a lépések alkalmazása során, azok könnyen visszaállíthatók a naplófájlból (feltéve, hogy ez védve van a hibáktól). Ezt a technikát műveletreprodukciónak vagy újértéknaplózásnak nevezzük. Ha a rendszer össze is omlik a lépések a naplófájlban való alkalmazása során, a naplófájlban már rögzített lépések elvethetők, maga a fájlrendszer pedig érintetlen marad. A naplózási módszer garantálja, hogy a teljes művelet vagy teljes mértékben megvalósul, vagy egyáltalán nem.
Egyetlen fájlrendszer kiterjesztése több lemezre
A megbízhatóság és/vagy a teljesítmény növelése érdekében a helyi fájlrendszer több lemezmeghajtóval is használható. Ez a videó a fájlrendszer több lemezen történő kibővítéséhez használt különböző technikákat mutatja be:
A lemezmeghajtók kiterjesztésének három fő oka a következő:
- További lemezterület elérése.
- Redundáns adattárolás.
- Blokkok több meghajtón való kiterjesztése, hogy azok párhuzamosan elérhetők legyenek, és javuljon a teljesítmény.
A helyi fájlrendszer számára több lemez is elérhetővé tehető transzparens módon, egyetlen lemezzel, egy úgynevezett logikai mennyiségkezelővel (LVM-mel). Ha két lemezzel rendelkezünk, egy LVM egy nagy címtartományt adhat meg a helyi fájlrendszernek, és a címek felét belsőleg leképezheti az egyik lemezre, a másik felét pedig a másik lemezre. A redundancia biztosításához az LVM mindkét lemezen tárolhatja az összes blokk egy-egy megegyező példányát. Ehhez olvasási és írási műveleteket kell megadni az LVM-nek. Az LVM minden íráshoz frissíti a két lemez két kívánt azonos példányát. Az LVM minden olvasáshoz továbbítja a kérést a kevésbé terhelt lemeznek. Több lemez párhuzamos eléréséhez pedig egy fájlcsíkozás nevű technikát használhatunk. A fájlcsíkozás során a fájlt több egységre osztjuk, amelyeket elosztunk a lemezek között, így lehetővé téve a fájl párhuzamos hozzáférését.
Az adatok a csíkegységtől (attól a szinttől, ahol az adatokat több lemez között elosztjuk) függően különböző módokon csíkozhatók. Blokkszintű csíkozás esetén a csíkegység egy adatblokk. Az adatblokk mérete, amelyet csíkszélességnek is nevezünk, a megvalósítástól függ, azonban mindig legalább akkora, mint a lemez szektormérete. A szekvenciális adatok visszaolvasásakor minden lemez egyszerre olvasható. Többfeladatos operációs rendszerekben nagy az esély arra, hogy a nem szekvenciális lemezelérések is párhuzamosan dolgoztatják az összes lemezt. Bájtszintű csíkozás esetén a csíkegység pontosan egy bájt. Bitszintű csíkozás esetén a csíkegység pontosan egy bit.
RAID
Ahogyan az adatközpontról szóló modulban is említettük, több lemez egyetlen logikai meghajtón egyesíthető a RAID elrendezéssel. A RAID 0 blokkszinten csíkozza az adatokat több lemezre, redundancia nélkül. A RAID 1 egy lemezről egy másikra tükrözi az adatokat, így általában megfelezve a tömbkapacitást. A RAID 2 bitszintű csíkozást nyújt, a Hamming-kódokat pedig paritásmeghajtón tárolja. A RAID 3 bájtszintű csíkozást nyújt, a paritásadatokat pedig dedikált paritásmeghajtókon tárolja. A RAID 4 blokkszintű csíkozást nyújt, dedikált paritásmeghajtókkal. A RAID 5 a RAID 4-gyel és 1-gyel megegyező blokkszintű csíkozást nyújt, a paritásadatokat azonban a készlet minden meghajtója között elosztja. A RAID 6 pedig megegyezik a RAID 5-tel, a paritásblokkokat azonban kétszer írja ki, így egy készleten belül két lemezhibát is képes kezelni. A RAID-konfigurációk kombinálhatók (például RAID 1+0 és RAID 0+1), így különböző teljesítménybeli és megbízhatósági garanciákkal alkalmazhatók.
Tárolóhálózatok
Vállalati informatikai környezetben a tárolók jellemzően konszolidálva vannak, hogy készletekbe rendezhetők és megoszthatók legyenek több kiszolgálón. A tárolóeszközök több kiszolgáló között, egy tárolóhálózattal (SAN-nel) oszthatók meg. Az SAN egy dedikált hálózat, amely hozzáférést biztosít a konszolidált, blokkszintű adattárhoz (lásd az alábbi ábrát). A konszolidált, blokkszintű tároló általában egy lemeztömb. A lemeztömb konfigurálható a RAID valamilyen formájában, a kívánt teljesítmény és megbízhatóság függvényében. A kiszolgálók általában egy iSCSI-, Fibre Channel- vagy hasonló protokollal férnek hozzá a tárolóhálózathoz. A tárolóhálózatot használó kiszolgálók egy logikai blokkeszközt látnak, amely fájlrendszerrel formázható, és a kiszolgálóban csatlakoztatható. Az alkalmazáskiszolgáló ezután a külsőleg tárolt logikai blokkokat ugyanúgy használhatja, mint a helyileg tárolt blokkokat. Az adatok logikai elhelyezése így eltér a fizikai elhelyezéstől.
11. ábra: Tárolóhálózatok
Bár a kiszolgálók megosztják a lemeztömböt, fizikailag nem oszthatnak meg a lemezen található adatokat. Ehelyett a tárolóhálózat (amelyet logikai egységek – LUN-ok – határoznak meg) minden kiszolgálóhoz egy saját részt szolgáltat magából.
Hivatkozások
- Thomas Rivera (2012). The Evolution of File Systems SNIA Tutorial
- Sanjay Ghemawat, Howard Gobioff, és Shun-Tak Leung (2003). The Google File Systems 19th ACM Symposium on Operating Systems Principles