Pomocí glusteru je možné vytvářet různé „disky“ rozprostřené přes různé stroje, podobně jako např. pomocí mdadm, který pracuje na úrovni disků nebo partitions. Základním stavebním kamenem ve světě glusterFS je „brick“, jedná se o nejmenší jednotku (podobně jako je partition), jeden host může exportovat více bricků, volume (disk) se vždy rozprostírají přes jeden nebo více bricků.
Gluster podporuje následující rozložení, která je možné zprovoznit i na jednom stroji.
-
Distributed volume – volume je rozloženo přes skupinu bricků. Pro každý soubor platí, že jeho data existují právě na jednom bricku. Toto rozložení použijeme v okamžiku, kdy chceme výhradně škálovat.
-
Replicated volume – volume je replikováno na více bricků, každý soubor se nachází na všech briccích. Toto rozložení použijeme, je-li prioritou High-Availability.
-
Stripped volume – volume je rozloženo přes skupinu bricků s tím, že narozdíl od Distributed volume může být jeden soubor uložen napříč bricky. Toto rozložení použijeme, je-li třeba ukládat soubory větší, než jsou velikosti disků na strojích.
-
Distributed Striped volume – kombinace s důrazem na výkon a obrovské soubory.
-
Distributed Replicated volume – kombinace, jedná se v podstatě o RAID 10.
-
Geo-replication – asynchronní jednosměrná replikace. Cílový stroj nemusí být připojen do clusteru.
Mám dva servery...
Potřeboval jsem vyřešit „jednoduchý“ problém. Mám dva servery a potřebuji asynchronní mirror několika adresářů na serveru 1, tj. v okamžiku, kdy zapíšu soubor na server 1, měl by se (nejlépe ihned) objevit také na serveru 2 s tím, že zapisovací proces na serveru 1 nesmí čekat na server 2. Je-li server 2 offline, nesmí se to nijak projevit na rychlosti zápisu na serveru 1; jakmile bude server 1 opět dostupný, data se neprodleně zreplikují.
GlusterFS nabízí mnoho způsobů, jak vytvořit volume (disk) distribuovaný přes několik strojů, různě mirrorovaný apod. Použil jsem formu geo-replication proto, že tento režim je ideálním řešením mého problému, nevyžaduje žádné další otevřené porty na obou strojích, vystačí si s SSH. Víceméně jsem postupoval dle tohoto návodu. Nejprve je třeba na obou strojích nainstalovat balík glusterfs-server, rsync a také splnit tyto požadavky. Mějme stroje master a slave.
Příprava stroje master
service glusterfs-server start
Master je hlavní. Na masteru jsou data, které chci kopírovat na slave. Bude třeba vytvořit gluster volume a následně jej připojit. Gluster volume se zatím nedá vytvořit nad blokovým zařízením (přijde ve verzi 3.4), je to možné pouze nad adresářem. V adresáři /mnt/data mám připojen souborový systém, který chci replikovat.
gluster volume create data master:/mnt/data
Vytvořil jsem volume data nad brickem /mnt/data:
gluster volume start data
Volume jsem nastartoval
mount -t glusterfs localhost:/data /data
Připojil jsem glusterfs volume do /data. Potom na disku nastane stav, kdy v /mnt/data máte totéž, co je v /data. S tím rozdílem, že /data je hlídáno službou glusterd, která má všechny soubory zaindexované a zná jejich hashe. /mnt/data by neměl nikdo modifikovat, jinak gluster nebude o těchto změnách vědět.
Jelikož replikace dat na slave bude probíhat přes SSH, bude třeba vygenerovat nějaký ten klíč, bez paraphrase.
ssh-key-gen -f /etc/glusterd/geo-replication/secret.pem
Příprava stroje slave
U slave není nutné, aby služba glusterfs-server běžela, balík glusteru musí být ovšem nainstalován. Je třeba naimportovat public-key z master serveru mezi rootovy authorized_keys. Ano, bohužel je to tak, v dalších verzích by mělo být možné geo-replikovat na libovolného uživatele, ve verzi 3.2.7, kterou jsem použil, tomu tak ještě není. Na slave stroji vytvoříme cílový adresář /data-backup, do kterého budou přistávat data z masteru.
Propojení
Zapneme geo-replikaci volume jménem data a zvolíme jako cíl stroj slave.
gluster volume geo-replication data root@slave:/data-backup start
Zanedlouho bychom měli pozorovat data na slave stroji. Pokud se tak neděje (tak se to stalo i mně), je třeba zkontrolovat status nebo kouknout do logů. V mém případě status vypadal v pořádku:
gluster volume geo-replication status
MASTER SLAVE STATUS
--------------------------------------------------------------------------------
data ssh://root@slave:file:///data-backup OK
Ale v logu glusterd na stroji master jsem našel toto:
[2013-03-26 01:57:50.386405] E [syncdutils:133:log_raise_exception] <top>: FAIL:
Traceback (most recent call last):
File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/syncdutils.py", line 154, in twrap
tf(*aa)
File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/repce.py", line 117, in listen
rid, exc, res = recv(self.inf)
File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/repce.py", line 41, in recv
return pickle.load(inf)
EOFError
Příčin této chyby může být mnoho, od nefukčního SSH spojení po neexistující adresář na stroji slave nebo chybějící glusterfs-server nebo rsync. V mém případě (oba stroje Debian Wheezy) bylo třeba přenastavit cestu ke remote-gsyncd. Na slave bylo třeba najít binárku gsyncd:
find /usr/ -name 'gsyncd'
/usr/lib/glusterfs/glusterfs/gsyncd
Na stroji master následně přenastavit geo-replikaci:
gluster volume geo-replication data root@slave:/data-backup config remote-gsyncd /usr/lib/glusterfs/glusterfs/gsyncd
Nyní už měl gluster na masteru správnou cestu k binárce na slave. Na slave se začaly objevovat soubory a zanedlouho bylo vše 1:1. Teď, když zapíšu na master do /data, do dvou sekund se totéž objeví na stroji slave.