21. Fejezet - A Vinum kötetkezelő

Nem számít, milyen lemezeink is vannak, ugyanis mindig adódnak velük kapcsolatban gondjaink:

Ezekre a problémákra javasoltak és meg is valósítottak számos megoldást. A felhasználók egy része általában úgy védekezik ellenük, hogy több, gyakran redundánsan tároló lemezt használ. A különféle kártyák és hardveres RAID-vezérlõk támogatása mellett a FreeBSD alaprendszerében megtalálható egy blokkos eszközmeghajtóként a Vinum kötetkezelõ is, amellyel virtuális lemezmeghajtókat lehet létrehozni. Tehát a Vinum egy olyan ún. kötetkezelõ, vagyis virtuális lemezkezelõ, ami az említett három problémára próbál megoldást adni. A Vinum a hagyományos lemezes tárolásnál jóval nagyobb rugalmasságot, teljesítményt és megbízhatóságot biztosít, valamint ismeri a RAID-0, RAID-1 és RAID-5 modelleket külön-külön és kombinálva is.

Ebben a fejezetben összefoglaljuk a hagyományos lemezes tárolás jellegzetes problémáit és bemutatjuk a Vinum kötetkezelõt.

A lemezek kapacitása ugyan növekszik, de velük együtt a tárigények is. Ezért gyakran érezzük úgy, hogy a rendelkezésünkre álló lemezek tárkapacitását meghaladó állományrendszerre lenne szükségünk. Kétségtelen, hogy ez a probléma messze nem akkora jelentõségû, mint például tíz évvel ezelõtt, de még mindig fennáll. Egyes rendszerek ezt úgy hidalták át, hogy létrehoztak egy olyan absztrakt eszközt, amely az adatokat több lemezen tárolja el.

Napjaink rendszerei szinte állandóan egyszerre több adathoz is hozzá akarnak férni. Például egy nagy forgalmú FTP vagy HTTP szerver több 100 Mbit/s sebességû kapcsolattal is csatlakozhat a világhálóhoz, amelyeken keresztül párhuzamosan többezernyi tranzakciót is folytathat, ami jelentõsen meghaladja a legtöbb lemez átlagos átviteli sebességét.

A jelenleg kapható lemezek soros adatátviteli sebessége egészen 70 MB/s-ig is terjedhet, de ennek az értéknek kevés a jelentõsége olyan környezetekben, ahol több, egymástól függetlenül futó program próbál egyszerre hozzáférni, hiszen ilyen esetekben csak a töredékét képesek elérni. Ilyenkor sokkal érdekesebb a lemezt kezelõ alrendszer szempontjából nézni a problémát: így az egyes adatátviteli kérések terhelése lesz a meghatározó paraméter, vagyis az az idõ, amit a kérés teljesítésében érintett meghajtók eltöltenek a feldolgozással.

Bármelyik kérést is vesszük, a kiszolgáláshoz a meghajtónak elõször a megfelelõ helyre kell mozgatnia az író/olvasó fejeket, meg kell várni a fej alatt elhaladó elsõ szektort, majd végrehajtani a megfelelõ mûveletet. Ezek a mûveletek szétválaszthatatlanok: semmi értelme nincs megszakítani ezeket.

Tekintsünk egy átlagosnak mondható, nagyjából 10 kB méretû adatátvitelt: a legújabb nagyteljesítményû lemezek átlagosan 3,5 ms alatt képesek pozicionálni a fejeket. A leggyorsabb lemezek 15 000 fordulatot tesznek meg percenként (RPM), így az átlagos forgási késleltetés (egy fél fordulat ideje) 2 ms. 70 MB/s-os sebesség mellett az átvitel maga megközelítõleg 150 μs, ami szinte elhanyagolható a pozicionálás idejéhez képest. Ilyen esetekben a tényleges adatátviteli sebesség 1 MB/s-nél alig valamivel többre esik vissza, és tisztán látszik, hogy erõsen függ az átvitt adat mennyiségétõl.

A hagyományos és kézenfekvõ megoldása ennek a problémának "még több cséve" használata: egyetlen nagy lemez helyett alkalmazzunk több kisebb, de azonos tárkapacitású lemezt. Mindegyik lemez képes egymástól függetlenül mozgatni a fejeiket és az adatokat, aminek köszönhetõen a tényleges adatátvitel mértéke nagyjából a lemezek számával arányosan növekszik.

Az adatátvitelben bekövetkezõ javulás pontos aránya természetesen kisebb, mint a lemezek száma: habár az egyes meghajtók képesek párhuzamosan mozgatni az adatokat, semmilyen módon garantálhatjuk, hogy a kérések egyenletesen oszlanak el köztük. Emiatt szinte elkerülhetetlen, hogy az egyik meghajtót nagyobb terhelés érje, mint a másikat.

A lemezekre esõ terhelés egyenletessége erõsen függ attól, hogyan osztjuk el az adatokat a meghajtók között. Az itt használt példában a lemezen tárolt adatokat egy könyv oldalaiként érdemes elképzelni, vagyis rengeteg szám szerint címezhetõ adatszektorként. A virtuális lemezt ennek megfelelõen a legegyszerûbben úgy tudjuk felosztani az egymás után következõ független fizikai lemezek mérete szerint és így használni, mintha egy nagy könyvet kisebb részekre téptünk volna. Ezt a módszert nevezik összefûzésnek, és elõnye, hogy a résztvevõ lemezeknek nem kell azonos méretûeknek lenniük. Ez a megoldás remekül mûködik abban az esetben, amikor a virtuális lemez hozzáférései egyenletesen oszlanak el annak teljes területén. Amikor viszont az elérés csak egy kisebb területre korlátozódik, kevesebb javulás tapasztalható. A Az összefûzött szervezési mód mutatja be lemezek egy ilyen összefûzött konfigurációját.

Feloszthatjuk a virtuális lemezünket kisebb azonos méretû darabokra is, melyeket különbözõ eszközökön sorosan tárolunk el. Például az elsõ 256 szektort eltároljuk az elsõ lemezen, majd a következõ 256 szektort a következõ lemezen és így tovább. Az utolsó lemez kitöltése után az egész folyamat ismétlõdik, egészen az összes lemez megtöltéséig. Ezt a leképezést csíkozásnak ("striping") vagy RAID-0-nak nevezzük . A csíkozás használata során valamivel bonyolultabbá válik az adatok megtalálása és többletmunkát is jelenthet olyan esetekben, amikor az adatátvitel több lemezt is érint, de ezzel egyidõben sokkal jobban szétosztja a terhelést a lemezek között. A A csíkozott szervezési mód mutatja be a lemezek csíkozott szervezését.

A modern lemezhajtók utolsó fontos problémája, hogy nem eléggé megbízhatóak. Annak ellenére, hogy a lemezek ezen a téren meglehetõsen sokat fejlõdtek az utóbbi pár évben, egy szervernek még mindig ezek azok a központi részei, amelyek a leginkább hajlamosak a meghibásodásra. Amikor ez bekövetkezik, a hatása akár egy katasztrófával is felérhet: a sérült lemezmeghajtók cseréje és az adatok visszaállítása napokat is igénybe vehet.

Ennek a problémának a hagyományos megközelítése lenne a tükrözés ("mirroring"), vagyis amikor ugyanarról az adatról tartunk két példányt két eltérõ fizikai hardveren. A RAID-szintek beköszöntével ezt a technikát RAID level 1-nak vagy RAID-1-nek is nevezik. Amikor írunk a kötetre, mindenhova írunk, az olvasás pedig bármelyik eszközrõl elvégezhetõ. Így ha az egyik meghajtó tönkremenne, egy másikon még mindig megtalálható az összes adat.

A tükrözés két problémát vet fel:

Az adatintegritás megõrzésére egy másik megoldás a paritás használata, melyet a 2, 3, 4 és 5 RAID-szintek valósítanak meg. Ezek közül talán a RAID-5 a legérdekesebb. A Vinumban egy olyan csíkozott szervezési módként valósították meg, ahol minden csíkból egy blokk az összes többi paritási információját tartalmazza. A RAID-5 által megvalósított szervezés hasonlít a csíkozáshoz, azonban a RAID-5-ben mindegyik csík tartalmaz egy paritási információt is. Tehát a Vinumban, ahogy azt RAID-5 a megköveteli, a paritást tároló blokkok helye az egyik csíkról a másikra változik. Az adatblokkokban található számok relatív blokkszámokat jelölnek.

A RAID-5-nek a tükrözéshez képest megvan az az elõnye, hogy jelentõsen kevesebb tárhelyet igényel. Az olvasás hasonló a csíkozott szervezésekéhez, azonban az írás jóval lassabb, közel 25%-a az olvasás sebességének. Az egyik meghajtó meghibásodása esetén a tömb csökkentett módban még képes folytatni a mûködést: a fennmaradó meghajtókról továbbra is a megszokott módon lehet olvasni, viszont a sérült meghajtóról olvasott adatokat folyamatosan javítani kell a többirõl származó segédinformációk szerint.

A tárgyalt problémák orvoslására a Vinumban egy négyszintû objektumhierarchiát alakítottak ki:

A most következõ szakaszokban ismertetjük, hogy ezek az objektumok milyen módon szolgáltatják a Vinum részérõl elvárt funkciókat.

A Vinum a rendszerben ismert objektumokkal kapcsolatos információkat egy konfigurációs adatbázisban tartja fenn. Kezdetben a felhasználó egy vagy több konfigurációs állomány segítségével hozza létre ezt az adatbázist a gvinum(8) segédprogrammal. A Vinum ezt a konfigurációs adatbázist bemásolja mindegyik irányítása alatt álló slice-ba (melyek a Vinum eszköznek hív). Az adatbázis minden egyes állapotváltás folyamán frissül, így egy újraindítás után minden egyes Vinum-objektum állapota pontosan helyreállítódik.

Korábban már megismerhettük, hogy a Vinum alapértelmezett neveket társít az erekhez és az allemezekhez, habár ezek a nevek felülbírálhatóak. Ez viszont egyáltalán nem ajánlott, mivel már a VERITAS kötetkezelõ, ahol tetszõleges neveket rendelhetünk az objektumokhoz, használata során kiderült, hogy akkora mértékû rugalmasságot nem kínál fel, mint amennyi zavart képes okozni.

A nevek tartalmazhatnak bármilyen nem üres karaktert, azonban érdemes inkább csak betûket, számjegyeket és az aláhúzást használni. A kötetek, erek és allemezek nevei akár 64 karakteresek is lehetnek, a meghajtók nevei pedig 32 karakteresek.

A Vinum objektumai a /dev/gvinum könyvtáron belüli hierarchiában helyezkednek el eszközleírókként. Az imént említett példakonfiguráció hatására a következõ eszközleírók jönnek létre:

A /dev/vinum/control és /dev/vinum/controld nevû vezérlõeszközök, melyeket a gvinum(8) és a Vinum démon használ. * Mindegyik kötethez egy eszközleíró tartozik. Ezek a Vinum számára a központi eszközök, ezért az elõbbi konfiguráció révén megjelennek a /dev/gvinum/myvol, /dev/gvinum/mirror, /dev/gvinum/striped, /dev/gvinum/raid5 és /dev/gvinum/raid10 eszközök.

Az egyes meghajtókhoz tartozó leírók a /dev/vinum/drive könyvtárban találhatóak. Ezek valójában szimbolikus linkek a megfelelõ lemezes eszközökre. * Minden kötethez közvetlen leírók tartoznak /dev/gvinum könyvtárban. * Az egyes erek és allemezek eszközleírói a /dev/gvinum/plex és /dev/gvinum/sd könyvtárakban jelennek meg.

Például tekintsük most az alábbi konfigurációs állományt:

Az állomány feldolgozása után az eszközleírókat a gvinum(8) az alábbi módon szervezi a /dev/gvinum könyvtárban:

Jóllehet, az ereket és allemezeket nem ajánlott külön-külön elnevezni, a Vinum meghajtóknak nevet kell adni. Ezzel megoldhatóvá válik, hogy az egyes meghajtók automatikusan felismerhetõek legyenek abban az esetben is, amikor fizikailag áthelyezzük ezeket. A meghajtók nevei legfeljebb 32 karakteresek lehetnek.

A GENERIC rendszermag nem tartalmazza a Vinumot. Habár készíteni lehet olyan rendszermagot, amelyik támogatja a Vinumot, mégsem ajánlott. A Vinumot a szabványos módon modulként (kld) indíthatjuk el. Még a kldload(8) használatára sincs szükség, mivel a gvinum(8) indulása során ellenõrzi a modul jelenlétét és betölti, ha még nem lenne jelen.

Olyan számítógépeknél, ahol a teljesen tükrözött Vinum-alapú állományrendszereket használunk, kívánatos lehet magát a rendszerindításhoz használt állományrendszert is tükrözni. Egy ilyen konfiguráció összeállítása már messze nem annyira egyszerû, mint egy tetszõleges állományrendszer esetén, mivel:

A soronkövetkezõ szakaszokban "rendszerindító kötetként" (root volume) fogunk általánosságban véve hivatkozni a rendszerindításhoz használt állományrendszert tartalmazó Vinum-kötetre. Ennek megfelelõen valószínûleg jó ötlet a "root" névvel azonosítani ezt a kötetet, habár technikai szempontból ezt semmi nem követeli meg. Az itt felsorakozó példákban azonban ezt a nevet fogjuk használni.