přejít na obsah přejít na navigaci

Linux E X P R E S, GlusterFS – Geo-replication v praxi

GlusterFS – Geo-replication v praxi

Znáte GlusterFS? Doslechl jsem se o něm až v okamžiku, kdy Red Hat koupil firmu Gluster, která stála za jeho vývojem. GlusterFS je distribuovaný open-source souborový systém a je dostupný snad v každé distribuci. Dají se s ním dělat kouzla, o kterých se vám ani nesnilo.


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.

Nahoru

Odkazy

Příspěvky

GlusterFS – Geo-replication v praxi
Miroslav Koucký 29. 05. 2013, 07:34:27
Odpovědět  Odkaz 
Děkuji za podnětný článek.
Již delší dobu se chystám ze zvědavosti vyzkoušet replikaci dat přes více strojů a Váš článek mě konečně motivoval k praktické realizaci.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz

Libor Zoubek


  • Distribuce: Arch
  • Grafické prostředí: E17



Public Relations

OpenRadioss: Simulace dynamických dějů nyní jako open-source

OpenRadiossNa podzim loňského roku Altair překvapil odbornou veřejnost z řad výpočtářů a vývojových inženýrů představením řešiče OpenRadioss. Jak už název napovídá, Open­Radi­oss je open-source verzí explicitní­ho solveru Altair Radioss, CAE nástroje pro simulace rychlých dějů, jakými jsou tolik populární virtuální testy nárazů vozidel, včetně vyhodnocení pasivní bezpečnosti, zkoušky odolnosti leteckých konstrukcí, pádové zkoušky elektronických zařízení a podobně.

Pokračování ...



Public Relations

Zabezpečte firemní komunikaci a chraňte citlivé informace vaší společnosti pomocí MailStore

Stále více malých a středních podniků (MSP) přechází na Microsoft 365 v cloudu. Očekávají přitom, že jejich data jsou zde automaticky v bezpečí. Jenže tak tomu není. Přestože cloudové služby nabízejí vysokou úroveň zabezpečení, nejsou data v Microsoft 365 archivována a zálohována automaticky.

Pokračování ...


Redakční blog

Pavel Fric

Pavel Fric, 10. April

Zapojte se do tvorby distribuce Mageia

Podílejte se na vytváření balíčků pro Mageiu, dělejte, co je potřeba, staňte se baličem


Pavel Fric

Pavel Fric, 13. March

Lollypop

Lollypop je hudební přehrávač navržený, jak ukazuje jeho podoba, aby výborně zapadl do pracovního...


Pavel Fric

Pavel Fric, 26. February

QElectroTech

Kreslení elektrotechnických i jiných výkresů


Všechny blogy »