Distribuovaný síťový filesystém - Coda 6 (3)

Zálohování svazků

Jelikož jsou data uložena na Coda serveru mírně netypicky, nelze pro jejich zálohování použít unixovou klasiku dump.

Zálohání dat v CODA fs vypadá takto:

1. Zjistit volume id, které chceme zazálohovat

sanatana# volutil getvolumelist
V_BindToServer: binding to host sanatana.dharma
P/vicepa Hsanatana.dharma T1c7d40 F94570
Wroot.0 I1000001 H1 P/vicepa m0 M0 U71b6 W1000001 C419b9143 D419b9143 B0 A0
Wrepvol.0 I1000002 H1 P/vicepa m0 M0 U781a W1000002 C419f769b D419f769b B0 A0
GetVolumeList finished successfully 

2. Naklonovat – vytvoření read-only snapshotu

sanatana# volutil clone 1000001 -n root.backup
V_BindToServer: binding to host sanatana.dharma
VolClone: New Volume id = 1000004
VolClone: New Volume name is root.backup 

3. Vydumpovat svazek

sanatana# volutil dump 1000004 | gzip -4c > /tmp/root.backup1.gz
V_BindToServer: binding to host sanatana.dharma
.................................................
VolDump completed, 29270278 bytes dumped 

Pomocí parametru -i lze vytvářet i inkrementální dumpy, podobně jako u programu dump.

4. Oznámit serveru, že záloha proběhla ok

Toto je nutné pouze, pokud budeme chtít používat inkrementální dum­py.

sanatana# volutil ancient 1000001 

5. Likvidace naklonovaného svazku

sanatana# volutil purge 1000004 root
V_BindToServer: binding to host sanatana.dharma
Volume 1000004 (root) successfully purged 

Více informací o zálohování se dozvíte v manuálu.

CODA umožňuje i použití sofistikovanějšího zálohovacího systému, který je popsán v manuálu na výše uvedené adrese. Tento systém je však obtížněji integrovatelný do vašeho stávajícího systému pro centrální zálohování, a proto jej zde nepopisuji.

Coda v praxi

Jak asi víte, CODA filesystém se v praxi moc nepoužívá. Osobně jsem jej doposud neviděl nikde v produkci nainstalovaný. Sami autoři jej pro produkční použití ani nedoporučují.

Coda filesystém má však velice hezký (ve srovnání s AFS) feature list. Z faktu, že všichni používají AFS místo CODA, lze správně usoudit, že použití Cody nebude právě bezproblémové.

Během 14denního testování jsem narazil na značné provozní problémy. Největší potíže způsobovalo použití více než jednoho serveru v clusteru. S jednoserverovým clusterem jsem žádné podrobnější testy neprováděl, neboť tato konfigurace nebyla pro mne zajímavá. Částečný seznam zjištěných problémů následuje.

1. Server

• Update client je velmi citlivý časovou synchronizaci. Synchronizace času prováděná pomocí rdate se ukázala jako nepostačující.
• Pokud nejsou všechny serveru v clusteru neustále online, nastává často pseudo-replikační konflikt na úrovni adresářů, který musí administrátor ručně řešit, a to i v případě, že všechny kopie adresářů jsou shodné.
• Nedostatečná dokumentace
• Nutnost ručního vytváření VLDB – tabulky umístění jednotlivých svazků.
• Problémy s provozem serveru na více IP.
• Administrativní nástroje rozhodně nejsou easy to use.
• Pro komunikaci se používají UDP packety, provoz přes NAT se mně nepodařilo rozchodit.
• Neexistuje způsob, jak jednoduše provádět push/pull server-server replikaci. Lze to dělat s pomocí klienta, ten však vyžaduje platné tokeny.

2. Venus klient

• Mnohem více zabugovaný než serverová součást Cody.
• Chybná detekce online stavu serverů. cfs strong mírně pomůže.
• Nefunguje korektně, pokud se přihlásíte na více než jeden server v clusteru.
• Někdy odmítá nastartovat i po korektním shutdownu – je nutné provést kompletní reinicializaci cache.
• Semtam vytváří client-server replikační konflikty, a to i v případě, že se serverem nepracuje žádný jiný uživatel.
• Utilita pro řešení replikačních konfliktů často segfaultuje, takže není možné konflikt odstranit. Opravdu závažná chyba.
• Je pomalý, i přestože využívá lokální cache. Rychlosti srovnatelné s NFS3 nedosahuje ani náhodou.
• Pracuje vždy s celými soubory, což je velmi nešikovné při velikostech souborů v řádu stovky MB.
• Někdy není schopen provést zpětnou reintegraci změněných dat.
• Kontaktuje vždy všechny dostupné servery v clusteru – nevhodné pro WAN.
• Lazy write je implementováno divně a hlavně dost pomalu.

3. Ostatní

• Některé client-side utility jsou zcela nefunkční (coredump).
• Chybí podpora 64bit platforem – Solaris.
• Integrace s MIT Kerberem není bezproblémová (nerozchodil jsem to), Heimdal pracuje okay.

Celkově bych stupeň zabugovanosti srovnal tak s Win95. Pokud se můžete nasazení Cody vyhnout, rozhodně to udělejte.

Akademický projekt

CODA je vytvářena jako akademický research project. Za necelých dvacet let své existence o ní bylo napsáno pár poměrně zajímavých dokumentů. Podle stupně zabugovanosti mi připadá, že cílem autorů spíše je naprogramovat cosi, o čemž lze pak psát hezké práce, než něco, co lze nasadit do produkce. Vždyť i výše zmíněné dokumenty jsou uloženy v AFS.

Alternativa – OpenAFS

K filesystému CODA existuje v současné době jediná používaná alternativa – AFS server OpenAFS v kombinaci s výborným klientem Arla. Tuto kombinaci lze doporučit, neboť v současné době není moc z čeho vybírat, zvláště když požadujeme platformovou nezávislost.

Alternativa – NFS4

Osobně jsem velice zvědav na to, jak si povede NFS4. Design je ve srovnání s AFS jednodušší, což v praxi znamená lepší kvalitu jednotlivých implementací. Navíc projekty realizující tento protokol startují na zelené louce, takže tu odpadají problémy s 20letou zděděnou codebází. Ačkoliv AFS je v praxi použitelné, rozhodně bych jej velice rád nahradil něčím jednodušším a spolehlivějším, přičemž NFS4 se zdá být velice slibným kandidátem.

Závěr

Tím bychom se rozloučili s Codou 6.0.7 s přáním dočkat se bug free verze alespoň u příležitosti jejích dvacátých narozenin v roce 2007. Je pravda, že tento miniseriál nebyl moc dobře napsaný. Nechal jsem to záměrně tak, jelikož Coda si lepší práci ani nezasloužila.