Distribuovaný sítový filesystém - Coda 6

CODA

Jak již bylo v titulku uvedeno: Coda je pokročilý distribuovaný sítový filesystém. Filesystémů s takovými možnostmi moc k dispozici není: AFS, DCE, NFS4. Tento filesystém je vyvíjen již od roku 1987 a vychází z AFS v2. Z AFS vychází nejen ideově, ale i recyklací částí kódu uvolněného IBM. Filesystém CODA je šířen pod GPL, knihovny pod LGPL a kernel drivery pod BSD licencí. Podívejme se na nejzajímavější věci, které CODA nabízí. Sami autoři považují Codu za velice slibnou technologii.

Lokální cache

Podobně jako AFS i Coda implementuje na klientech lokální persistentní cache, kterou používá pro zvýšení výkonu zejména při provozu ve WAN sítích. To je velký rozdíl oproti síťovým systémům určeným pro lokální sítě, např. NFS3, SMB, které umějí běhat pouze přes drát. Spolehlivost WAN sítí je řádově nižší než u LAN, a tak se lokální cache často využívá i v době, kdy je server nedostupný. Lokální cache taktéž vyrovnává rychlostní rozdíl mezi LAN/WAN, alespoň u většiny čtecích operací. Lokální cache je pro distribuovaný filesystém zkrátka nutnost.

Replikace dat

Další z vymožeností, se kterou se setkáme u těchto filesystémů, je replikace dat mezi servery. Je to velmi příjemná věc nejen pro rozdělování zátěže za účelem lepší škálovatelnosti a zálohování, ale především pro provoz na WAN. Klient se tak může připojit k nejrychlejšímu serveru, přičemž v případě jeho selhání se může automaticky přepnout na jiný.

Replikaci je možné provádět několika způsoby: single/multi master a sync/async. Coda používá asynchroní multi master replikaci, což je velmi vhodné pro WAN sítě, protože změny stačí nahrát na jakýkoliv právě dostupný server. Coda klienti se snaží zapsat změny na všechny jim dostupné servery a při zjišťování konzistence cache se taktéž snaží kontaktovat co největší množství serverů. Tímto způsobem se snižuje možnost server-server replikačních konfliktů.

Weakly connected režim

Coda na rozdíl od AFS podporuje i weakly connected režim. V tomtu režimu se pracuje pouze se soubory v cache a provedené změny se zaznamenávají do soboru v tar formátu. Při opětovné dostupnosti serveru jsou tyto změny promítnuty i do souborů na serveru. Replikační konflikty je nutné nejprve ručně nalézt (zobrazí se jako broken symlink) a pak i vyřešit. Tento režim je zvlášť vhodný pro uživatele laptopů. Obzvlášť hezká je optimalizace seznamu změn prováděných klientem před odesláním na server, aby se šetřilo přenosové pásmo.

Hoarded files

Protože je velikost diskové cache omezená, je pro disconnected režim výhodné, aby cache obsahovala všechny soubory, se kterými chceme bez připojení na server pracovat. Coda podporuje sticky cache soubory, které nejsou z cache automaticky odmazávány, pokud je potřeba udělat místo pro nové. V distribuci najdete program spy, který zaznamenává jména souborů, ke kterým právě přistupujete. Takto lze vytvořit seznam nejpotřebnějších souborů.

Design Coda serveru

Coda server je velmi netypická aplikace. Jeho miss-design věrně odráží konec 80. let v softwarovém průmyslu. O kompletním přepsání se sice diskutovalo, ale nikdo se k tomuto kroku nakonec neodhodlal. Je to škoda, protože mnohem lepší je aplikaci kompletně přepsat než udržovat zprasený kód a doufat, že se to v budoucnu nějak samo vyřeší.

Soubory na Coda serveru

Coda server neukládá soubory tak, jak jsme všichni zvyklí z ostatních normálních síťových filesystému. Tak jako profesionální zloději, kteří ukládají zlato zvlášť a kamínky zvlášť, coda server ukládá data a metadata každé zvlášť. Výsledek tohoto postupu je ten, že pokud chceme na serveru přistupovat k uloženým datům, je nutné použít coda klienta.

RVM

Server používá pro ukládání metadat a obsahu adresářů knihovnu RVM, která implementuje tzv. recoverable virtual memory. Můžeme si to představit jako malloc s podporou persistence a transakcí. Obraz této paměti je ukládán do souboru, ačkoliv autoři doporučují pro snížení výkonu raw partition, s fixní velikostí. Pokud velikost neodhadnete, je nutné provést import/export metadat. Metadata mají snahu bobtnat v případě nedostupnosti některého ze serverů v clusteru – obsahují totiž i replikační vektory. Správa volného místa v RVM byla dlouho velmi špatná, ve verzi rvm 1.10 byl algoritmus konečně doladěn.

Nejlepší nakonec – obraz virtuální paměti je anonymně mmapován + načítán celý do adresového prostoru serveru. Nejenže budete potřebovat i stejné množství virtuální paměti, ale start serveru není zrovna rychlá záležitost. Navíc většina 32bitových OS nepodporuje mmap o větší velikosti než 2 GB, což omezuje celkový maximální počet souborů uložených na jednom serveru. S virtuální pamětí se nevyplatí šetřit, jelikož kernel zlikviduje coda server při jejím nedostatku.

Pokud jste neposlechli doporučení autorů a nezodpovědně jste si zvolili nebezpečnou možnost ukládat data do souboru, lze použít mmap s flagem private. Tímto se eliminují trable s pomalým startem coda serveru a se značnou nenažraností, co se velikosti virtuální paměti týče. Limit maximální velikosti rvm to však nevyřeší.

RVM obsahuje kromě vlastních dat ještě protokolační soubor, který je použit pro transakční redo log. Implemetace redo logu je opět velmi špatná. Log není cyklický, jak by se dalo očekávat. Při jeho zaplnění a bohužel také v pravidelných intervalech je prováděna jeho reorganizace, kdy se z něj vymažou zakomitované transakce a zbytek se sklepne na začátek. Tato, ehm ne příliš optimální, garbage collection generuje značné množství io operací. Implementace logu hezky odráží historické dědictví Cody – v dávných dobách bylo místo na disku velmi drahé. Dnes už si klidne cyklický gigabajtový log udělat můžeme…

Systémová databáze

Stejně jako ostatní distribuované filesystémy, i Coda má systémovou databázi replikovanou mezi jednotlivými servery. Systémová databáze je typu single-master – její úpravy se kopírují jen jedním směrem. Coda na rozdíl od AFS nepoužívá žádnou sofistikovanou metodu pro distribuci a synchronizaci této databáze mezi jednotlivými uzly. Databáze se prostě čas od času překopíruje a její změny jsou občas ohlašovány master uzlem. Coda taktéž nikterak nebrání editaci této databáze na běžných uzlech.

Tato databáze se nachází v adresáři /vice (nelze změnit; přesněji řečeno lze, ale pak ji některé utility nenajdou). Obsahuje tabulku uživatelských hesel, tabulku serverů, jméno root volumu, jméno master serveru, tabulku replikovaných volumů a seznam všech známých volumů a jejich replik. Dále jsou v databázi uvedeny autorizační tokeny, které používají administrativní utility pro vzdálenou správu serveru. Jelikož se tyto tokeny replikují, může každý administrátor administrovat každý dostupný server.

Do adresáře /vice jsou i docela nešťastně ukládány logy serveru, které zabírají oproti vlastní databázi značné množství místa.

Datové úložiště – Partition

Datové úložiště serveru se nazývá v coda terminologii partition a nachází se v adresáři /vicep[a-z]. Optimální je vyhradit pro tento adresář vlastní svazek, server bude potom správně reportovat volné místo na disku. Coda server ukládá data (naštěstí) do klasických souborů. Tyto soubory jsou ukládány do adresářové struktury připomínající Squid cache. Kromě adresářů a souborů se v partition nachází i index FTREEDB, který slouží k vyhledání jednotlivých souborů. Pokud se poškodí a nemáte na jiném serveru repliky svazků, tak smůla… Maximální počet souborů, který může být v partition uložen, je statický a volí se při instalaci v rozsahu 256K-16M souborů.

V dokumentaci se píše, že coda server přistupuje přímo k inodům a nepotřebuje existenci souborů v partition, a tak si máme upravit fsck, aby mu nevadily nereferencované inody, jelikož autoři svou modifikaci veřejně nenabízejí…

Administrativní jednotka – Volume

Základní a vlastně jedinou viditelnou administrativní jednotkou pro správu souborů je volume. Rozmístění volumů do partitions zajímá jen administrátory serverů, nikoliv uživatele.

Volume je strom souborů větší než adresář, ale menší než partition, který se přimountovává jako jeden celek. Není to tedy jako v NFS, kde si můžete namountovat libovolný exportovaný adresář ze serveru. Jako příklad volumu autoři uvádějí homedir jednoho uživatele. To je velmi hezký příklad, jelikož volumy podporují diskquoty. Volumy lze replikovat a vytvářet jejich záložní kopie. Velikost volumu by měla být proto zvolena tak, aby se jeden volume vešel na příslušné zálohovací zařízení.

Coda podporuje i nereplikovatelné volumy – k nim však není možno přistupovat pomocí weak access modu. Posledním typem jsou záložní volumy. Ty se nereplikují a není možné do nich zapisovat.