10 év boldog linuxozás után megváltam a három gépre is installált Debiántól és megtértem a szülőhazába, a Unix kebelére.
A megtérésnek komoly oka volt, amely egyrészt keresendő abban, hogy a szünetmentes nélkül működtetett Linuxom gyakran szenvedett áramingadozástól, másrészt abban, hogy az USB vinyó időnként letépődött róla (ebbe ne menjünk bele, életem egyik fájó pontja), végül pedig abban, hogy a 3 vinyóból álló mirrorm (3x ugyanaz a tartalom) háromszor más tartalmat mutatott.
Egy alapos adatmentés után (néhány levelem azért elveszett végül) egy péntek éjszaka álltunk neki Solarist telepíteni. Nem volt egyszerű, az összes Linuxos, Unixos telepítéseim közül a legnehezebb volt. Mielött azonban kitérnék a telepítés nehézségeire, megválaszolnám a címben feltett kérdést.
Miért éppen Solaris?
Mert konzisztens kódbázissál rendelkezik, amitől stabilitást várunk, azaz két bármilyen program békésen meg fog férni egymás mellett.
Ennél fontosabb szempont, hogy ipari minőségű filerendszerrel rendelkezik, ez a ZFS:
Mert init helyett egy sokkal jobb alternatívát kínál a Service Managemet Facility-t.
A Solaris svc (smf) az init teljes lecserélése. Az így elindított service-k mindegyikének (automatikusan) saját logja van. A Solaris gondoskodik arról, hogy ha egy service leáll, akkor újraindítsa. Képes függőség kezelésére is a service-k szintjén. Egy service-ének ráadásul több státusza is lehet, nem csak fut vagy áll. Persze kompatibilis az init scriptekkel is, ha egy szolgáltatáshoz, daemonhoz csak az lenne.
Mivel a gépem (egy Netfinity 5600) több processzorral is rendelkezik, újabb plussz pontot jelentett, hogy sokkal jobban ki tudja használni a két processzoros architektura előnyeit. Bár a gépet nem terhelem le, jó tudni, hogy ha leterhelném, akkor többet tudnék kihozni belőle, mint a korábbi Linuxos verzióból.
Miért kell nekem ZFS?
Mert napi 24 órában megy a gépem és a korábbi filerendszer romboló események nagyobb stabilitásra sarkaltak.
A ZFS ugyanis teljesen más filozófiát követ, mint a korábbi filerendszerek. Nem partícók vannak, hanem poolok, amik szabadon méretezhetőek össze-vissza. Filerendszer szinten tud mirrorozni, tud raid-z-t, ami egy sokkal dinamikusabb raid technológia, mint ami Linuxra van, de persze támogatja a hagyományos raid-eket is.
A ZFS további fontos előnye, hogy „atomikus” műveletekkel van tele, ami azt jelenti, hogy a legvégső változás kis lépésben történik, rövid futásidővel, azonnali hatással. Ha ebbe belefagy, akkor vagy a régi adatod van, vagy az új, de biztos nincs köztes, hibás állapot.
Persze mindent naplóz, de nem egy file-ba (ami ugye elveszik, ha a filerendszer megsérül), hanem külön területen.
Nagyban támogatja az adatmentést is, megmondhatod neki, hogy most egy snapshot-ot akarsz csinálni, akkor csinál egy kvázi tükröt a területről (valójában nem, azaz nincs szükséged ugyanennyi szabad helyre), amit aztán nyugodtan backupolhatsz.
Akiket jobban érdekelnek a filesystem rejtelmei, további finomságokra lelhetnek a ZFS skálázásánál (na ez az a rész, ahol én kényelmesen hátradöltem, és örültem, hogy a gépemre olyan valaki vigyáz, aki érti is azt, amit én most le fogok írni). Ütemezni lehet az IO műveleteket, a párhuzamos könyvtárműveleteket, folyamatosan csinál checksum-ot, endianfüggetlen, tud tömöríteni menet közben (de most ne gondoljon senki a Windows XP tömörített partícióira).
A ZFS meg tudja gyógyítani saját magát. Minden egyes adatblokkhoz erős redundancia jár és többszörös checksum. Ha adatsérülés történik, akkor észreveszi és visszaállítja az eredeti tartalmat.
a zfs-t a napokban nézegettem, de valahogy hiányosnak érzem azon a ponton, hogy zraid kötetet „egyszerűen” bővíteni nem lehet, és nem is tartják egyszerűnek a megoldását: hiába tudok könnyen húdesecure poolt létrehozni, ha utána nem tudom megtenni, hogy veszek egy X méretű vinyót és rebuild azzal a kapacitásnyi bővüléssel.
most éppen azt tartom a legegyszerűbb és legkönnyebben megvalósítható megoldásnak, hogy legyenek párban vinyóim, aztán azokat valamilyen unionfs jellegű megoldással „egynek” láttatom.
mit gondolsz ezekről?
@neo_21670:
Ezt a kovetelmenyt a hagyomanyos RAID megoldasok sem tudjak, a keplet minden esetben N disk X merettel P parity eseten = (N-P)*X. Ha az uj X merete megegyezik, hagyomanyos RAID5-6 tombok viszont kepesek azt hozzaadni meglevo tombhoz. Ezt a ZFS meg nem tudja, sot akkor sem ha a hozzaadasra varo disk merete azonos.
A ZFS viszont masban jo: hogy a temanal maradjunk, tud olyat hogy meglevo eszkozt kicserel majd ujraszinkronizal. Peldaul, ha van 3x80GB RAID-Z vdev, abbol lehetseges a kozepsot 160GB-ra cserelni majd resilver-ezni. Ezt a „minden disk 0-ra XOR-olodik ki” mukodes miatt a hagyomanyos RAID megoldasok mar nem tudjak megcsinalni, akarcsak a dinamikus stripe meretet valamint az atomikus tervezes miatti „write hole” kikuszoboleset sem.
Remelem tudtam erdemben valaszolni a kerdesedre.