Hlavní navigace

Velká řešení otevřeně: souborový systém GlusterFS

Jan Baier

Další z věcí, které je potřeba pro některé aplikace vyřešit, je souborový systém (ideálně POSIX kompatibilní). Z nepřeberného množství možností si pro dnešek vybereme GlusterFS, škálovatelný síťový souborový systém.

Architektura

Základním stavebním kamenem je tzv. cihla („brick“), těch může být na jednom serveru i více. Cihly napříč servery se pak na základě požadované konfigurace spojují do svazků a ty jsou potom přístupné jako klasický souborový systém skrze NFS nebo GlusterFS protokol. Cihly jako takové jsou tvořeny adresářem na nějakém lokálním souborovém systému.

GlusterFS rozeznává několik různých modelů dle stupně redundance a druhu distribuce (velmi podobně jako u RAIDu). Momentálně existují tři základní druhy svazků, které je možné ještě vzájemně kombinovat:

  1. Distribuovaný svazek – výchozí typ, který rozkládá data na úrovni jednotlivých souborů mezi různé cihly. Každý soubor tak bude právě na jedné z cihel, ideologicky to tedy odpovídá RAID0. Chceme-li takový svazek uchránit před ztrátou dat, musíme se spolehnout na spodnější vrstvu (tedy například mít cihlu na spolehlivém úložišti).
  2. Replikovaný svazek – ideologicky odpovídá RAID1 (resp. RAID1+). Při výrobě svazku lze specifikovat míru redundance a každý soubor je pak ukládán na daný počet různých cihel. (Pozn.: Pozor na to, že se jedná o cihly, nikoli servery. Nemusí se tedy vyplatit provozovat na jednom serveru více cihel ze stejného svazku.)
  3. Prokládaný svazek – obdobný typ jako distribuovaný, ale k rozkládáni dat nedochází na úrovni souborů, ale jejich částí (tolika, kolik je cihel ve svazku). Každý soubor je tedy rozložen mezi všechny cihly ve svazku. Při opakovaném čtení stejného souboru tak nedochází k nerovnoměrnému vytížení jedné cihly.

Instalace

Instalace je poměrně přímočará. Pro náš příklad opět použijeme naše dva servery a na každém vyhradíme jeden disk jako základ pro replikovaný svazek. Data tedy budou fyzicky přítomna na obou serverech. Začneme tím, že na discích vyrobíme jeden velký oddíl:

# fdisk /dev/sdc

Vytvoříme souborový systém (momentálně je jako lokální souborový systém doporučován XFS, ale funguje i EXT4 – mkfs.ext4 /dev/sdc1) a nakonec připojíme do systému.

# cat /etc/fstab
/dev/sdc1 /srv/glusterfs ext4 defaults 0 0

Následně je třeba na oba servery nainstalovat balíček glusterfs-server, pro Debian naštěstí existuje repositář s aktuální verzí. Odkaz lze dohledat v dokumentaci na stránkách GlusterFS.

Po instalaci balíčků je nutné oba servery propojit to tzv. důvěryhodné skupiny. Přihlásíme se například na server1 a spustíme příkaz

# gluster peer probe server2

Kdykoliv si můžeme ověřit, které servery jsou připojené:

# gluster peer status

případně

# gluster pool list

Pak již můžeme vytvořit svazek jménem „svazek“, v našem případě půjde o replikovaný svazek s dvěma replikami. Vyrobíme jej pomocí:

# gluster volume create svazek replica 2 transport tcp server1:/srv/glusterfs server2:/srv/glusterfs

Následně nastartujeme:

# gluster volume start svazek

Svazek můžeme nyní připojit skrze libovolný ze serverů jako klasický síťový souborový systém, třeba:

# mount -t glusterfs server1:/svazek /mnt

Cokoli uložíme, se transparentně replikuje i na druhý server. V případě krátkého výpadku (například síťové konektivity) dojde po obnovení spojení k automatické opravě, pokud ovšem nedošlo k zápisu stejného souboru na oba v tu chvíli nespojené servery. V opačném případě dojde k tzv. „split-brain condition“, kterou je potřeba manuálně vyřešit.

Tomuto problému se dá elegantně předcházet použitím vyššího (ideálně lichého) počtu serverů a nastavením nutnosti vidět nadpoloviční většinu svazku. Odpojené (menšinové) cihly pak přejdou automaticky do přístupu pouze pro čtení (případně je možné nastavit i úplné odmítání komunikace s klienty) a nedojde tak k problémům při opětovné synchronizaci.

Geo-replikace

Další zásadní vlastností GlusterFS je geo-replikace. Ve standardním replikačním módu jsou soubory okamžitě a synchronně kopírovány na všechny cihly ve svazku. Pro účely zálohy je ale možné provádět i asynchronní replikaci například na geograficky oddělený server. Tato replikace pak nebude brzdit výkon hlavního svazku. Geo-replikace je navíc možné různě řetězit a z jednoho svazku provádět i několik různých replikací zároveň.

Před výrobou replikačního spojení je dobré zkontrolovat si správné nastavení času (a kupříkladu nastavit NTP), vyrobit SSH přístup ze zdrojového serveru na cílový (tj. na repliku), který nebude vyžadovat heslo, a na replice vyrobit svazek stejným způsobem jako na zdrojových serverech. Svazek ale může být jiného typu a na jiném počtu serverů, celková kapacita svazku by však neměla být menší. Na zdrojovém serveru vyrobíme klíče:

# gluster-georep-sshkey generate

Samotné spojení vyrobíme příkazem:

# gluster volume geo-replication svazek replika::svazek_na_replice create push_pem

Replikaci zahájíme skrze:

# gluster volume geo-replication svazek replika::svazek_na_replice start

Problémy

Na závěr článku ještě zmíním problémy, se kterými jsem se setkal.

  • Nedostupnost jedné cihly v důsledku pádu stroje občas způsobuje na některých z ostatních serverů ve svazku pozastavení všech zápisů, přestože je nadpoloviční většina stále přístupná. Na jiných serverech naopak k zápisu dochází, ale soubory jsou rovnou označovány za konfliktní. Tuto situaci se mi úspěšně daří řešit změnou počtu cihel ve svazku a kompletním vyřazením nedostupné cihly. Nevýhodou ovšem je, že opětovné přidání zahrnuje synchronizaci celého souborového systému.
  • Geo-replikace se občas při síťovém výpadku zastaví a odmítá se znovu spustit. Někdy se dá na základě logů najít problematický soubor a po jeho smazání v replice se vše opět rozjede. Pokud se to nedaří, lze smazat celou repliku a nechat ji znovu zasynchronizovat (což pro velké množství dat může trvat velmi dlouho).
  • Nativní GlusterFS klient (implementovaný pomocí FUSE) na některých serverech při pokusu o čtení některých složek spolehlivě spadne a odpojí celý svazek. Pomůže přejít na protokol NFS, který ale bohužel neumí transparentní fail-over na jiný server.

Momentálně používám v produkčním prostředí stabilní verzi 3.8. K dispozici je ale již i řada 3.10, ve které mohou být některé z problémů vyřešeny.

Našli jste v článku chybu?