GlusterFS je škálovatelný distribuovaný síťový souborový systém, určený pro velká datová úložiště. Aktuálně patří do portfolia produktů fy. Red Hat (stejně jako Ceph, do kterého se dostal tím že Red Hat v r. 2011 spolkl společnost Gluster (založenou v r. 2005) která s jeho vývojem začala. Lze dynamicky zvětšovat, nebo zmenšovat jeho kapacitu, podobně je tomu u LVM, ovšem s tím rozdílem, že základním prvkem zde není lokální blokové zařízení, ale souborové systémy vzájemně komunikujících strojů.

Použití

GlusterFS je velmi variabilní a jeho výkon, spolehlivost a kapacita závisí nejenom na hardwarové konfiguraci strojů, ale také na jejich počtu a propustnosti sítě a síťových prvků.

Při návrhu GlusterFS úložiště je třeba vzít v úvahu tyto faktory:

Jaké jsou možnosti sítě
Jaký máme k dispozici hardware
Jaké si můžeme dovolit finanční náklady

V současné době jsou parametry běžných pracovních stanic na takové úrovni, že není nezbytně nutné investovat pro sestavení GlusterFS úložiště do hyper extra výkonných a spolehlivých serverů.

K vytvoření velkého úložiště lze docela dobře využít běžných kancelářských desktopů, ovšem při patřičném zohlednění určitých omezení

Propustnost sítě: Dnes se jsou 1Gbitové ethernetové karty zcela běžnou výbavou základních desek. Aby však při komunikaci serverů mohl být využity, musí tomu odpovídat také síťové prvky - kabeláž a switche. Jejich ceny jsou dnes již poměrně přijatelné. Pokud byste chtěli mít síť o propustnosti vyšší, tak už musíte jít minimálně do 10Gbitového ethernetu, kde se ceny pohybují v řádech desetitisíců a u ještě rychlejšího InfiniBandu, v řádech statisíců.

Kapacita a rychlost disků: V současné době nezbývá než řešit dilema - zajistit kapacitu menším množstvím velkých, ale pomalých i když poměrně laciných, rotačních disků? Nebo pořídit větší množstvím menších, za to rychlých SSD disků? Větší množství pevných disků sebou přináší další náklady - je třeba pořídit drahé řadiče a také zajistit dostatečné napájení. Za jistý kompromis z hlediska rychlosti lze považovat hybridní SSHD zařízení. Rozhodně se jim však nevyplatí příliš důvěřovat. Nové technologie sice přinesly větší kapacity, ale vykazují větší poruchovost - a zajistit uspokojivou redundanci dat znamená další náklady na hardware.

Počet serverů: Vyšší počet serverů umožňuje získat velkou úložnou kapacitu. Také se tím zlepšuje výkon GlusterFS z hlediska přístupových rychlostí k souborům. Ovšem každý stroj má svoje energetické nároky. Aby byl GlusterFS kdykoliv dostupný, musí být udržován pokud možno stále v chodu. Každý pevný disk, každá síťová karta, ale i každý síťový prvek si ukousne svůj díl el. energie. Naštěstí většina moderních strojů má v sobě zabudované mechanismy, které zajišťují snížení odběru el. energie, pokud není stroj zatížený. U strojů zavřených v klimatizované serverovně je třeba také připočítat nároky na el. energii spojené s chlazením.

GlusterFS, je ideálním řešením úložiště tam, kde se již v současné době nalézá mnoho klasických desktopových strojů na jedné síti - školní učebny, kanceláře - které lze takto druhotně využít. Nebo tam, kde potřebujeme zajistit vysokou dostupnost a redundanci dat

Instalace

Instalace GlusterFS serveru je u Debianu triviální, neboť je součástí oficiálních repositářů.

apt-get install glusterfs-server

Aktuálně ( tj. k lednu 2015 ) tímto příkazem dojde k nainstalování GlusterFS verze 3.5.2

Verze distribuovaného souborového systému GlusterFS nejsou zpětně kompatibilní a jeho aktualizace nemusí být bezproblémová, proto pokud chcete nainstalovat poslední stabilní verzi GlusterFS (3.6.2), tak musíte použít buď oficiální repozitář Debianu experimental, nebo použít instalační balíčky dostupné v repozitářích webu gluster.org

Anatomie /var/lib/glusterd

/var/lib/glusterd/
   |-  geo-replication/
      \- gsyncd_template.conf
   |- glusterd.info
   |- glustershd/
   |   |- glustershd-server.vol
   |   \- run/
   |- groups/
   |- hooks/
   |- nfs/
   |   |- nfs-server.vol
   |   \- run/
   |- options
   |- peers/
   |- quotad/
   |- snaps/
   |   \- missed_snaps_list
   \- vols\
       |- <jméno svazku>/
       |   |- <jméno svazku>.<ip serveru>.<cesta do adresáře (místo lomítek pomlčky)>.vol
       |   |- ...
       |   |- trusted-<jméno svazku>-fuse.vol
       |   |- <jméno svazku>-fuse.vol
       |   |- quota.conf
       |   |- quota.cksum
       |   |- snapd.info
       |   |- info
       |   |- rbstate
       |   |- node_state.info
       |   \- run/
       \- ...

Vytvoření TSP

Vytvoření TSP (Trusted Storage Pools) se na první pohled podobá vytvoření Volume Group u LVM, pouze s tím rozdílem, že se místo lokálních fyzických blokových zařízení PV do skupiny přidávají celé servery. Jejich zařazením ale, na rozdíl od Volume Group, nevzniká žádný datový prostor, který by se následně přerozdělil na logické disky.

Lokální server, ze kterého se začnou do TSP zařazovat další stroje, je automaticky jeho součástí. Každý další se přidá zcela jednoduše:

root@nod1 :~# gluster peer probe SERVER

Pokud se při této operaci vyskytne nějaký problém, tak je třeba zkontrolovat zda..

Utilita nslookup vrací správně doménové jméno stroje
V souborech /etc/hosts na serverech jsou v pořádku všechny záznamy. Hodně problémů totiž bývá zaviněno právě špatným záznamem v tomto souboru, proto se moc nedoporučuje jeho využití.
Je port 24007 průchozí? Ověřit zda je spojení průchozí můžete dotazem přes telnet
Běží na lokálním i vzdáleném serveru démon pro glusterfs?

TSP nelze sestavit ze serverů na kterých běží různé verze GlusterFS! Viz příklad chybové zprávy:

root@nod1 :~# gluster peer probe 192.168.0.2
peer probe: failed: Peer 192.168.0.2 does not support required op-version

Problém se síťovu komunikací při pokusu o přidání serveru je indikován jako chyba č.107 Viz příklad:

root@nod1 :~# gluster peer probe 192.168.0.2
peer probe: failed: Probe returned with unknown errno 107

Aby mohl GlusterFS pracovat, musí mít povolené následující porty:

TCP 24007: Používá pro svou komunikaci GlusterFS démon
TCP 24008: Využívá Infiniband, pokud není k dispozici, tak tento port nemusí být využitý
TCP 24009 a výše: Používá pro bricky GlusterFS verze 3.3 a menší
TCP 49152 a výše: Používá pro bricky GlusterFS verze 3.4 a vyšší
TCP,UDP 111: Se využívá pro mapování portů
TCP 2049: Se rovněž využívá pro mapování portů ovšem pouze u GlusterFS verze 3.4 a vyšší

Ve výchozím stavu NFS u GlusterFS neposkytuje konektivitu přes UDP, pouze TCP. Pokud chcete využívat pro NFS komunikaci přes UDP, je třeba zapnout parametr nsf.mount-udp

Z principu tedy není možné aby byl jeden server integrován do více než jednoho TSP!

Informace o TSP

root@nod3 :~# gluster pool list
UUID                                    Hostname        State
eaa065d3-f713-4c63-9287-0c50bef9ccc0    nod2            Connected 
e70dfc34-39e2-4f5f-99b1-7d64a6612462    192.168.0.1     Connected 
d1bdbc55-c6c6-461e-b5c9-c0bfa3d39f88    localhost       Connected

Podle výpisu lze poznat, které servery byly do TSP začleněny přes IP adresu (192.168.0.1) a které přes hostname (nod2). V případě doménových jmen, které obsahují jiné než alfanumerické znaky použije GlusterFS rovnou místo doménového jména IP adresu. Pokud chceme aby všechny nody byly identifikované přes IP adresu, můžeme zopakovat proces začlenění nodu.

Nejprve je třeba vyřadit záznam s doménovým jménem...

root@nod3 :~# gluster peer detach nod2
peer detach: success

Důsledkem předchozího kroku je vypnutí démona glusterfsd na stroji nod2, takže před opětným začleněním, je třeba provést jeho nahození:

root@nod2 :~#  /etc/init.d/glusterfs-server restart
[....] Stopping glusterd service: glusterdstart-stop-daemon: warning: failed to kill 5716: No such process
. ok 
[ ok ] Starting glusterd service: glusterd.

Teprve pak lze nod2 přidat přes jeho IP adresu

root@nod3 :~# gluster peer probe 192.168.0.2
peer probe: success.
root@nod3 :~# gluster pool list
UUID                                    Hostname        State
e70dfc34-39e2-4f5f-99b1-7d64a6612462    192.168.0.1     Connected 
eaa065d3-f713-4c63-9287-0c50bef9ccc0    192.168.0.2     Connected 
d1bdbc55-c6c6-461e-b5c9-c0bfa3d39f88    localhost       Connected

Zjištění stavu jednotlivých serverů v rámci TSP

root@nod1 :~# gluster peer status
Number of Peers: 2

Hostname: nod2
Uuid: eaa065d3-f713-4c63-9287-0c50bef9ccc0
State: Peer in Cluster (Connected)

Hostname: nod3
Uuid: d1bdbc55-c6c6-461e-b5c9-c0bfa3d39f88
State: Peer in Cluster (Connected)

Chceme-li zjistit jak vidí situaci v TSP jiný z nodů, je třeba použít parametr --remote-host

root@nod3 :~# gluster --remote-host=nod1 peer status
Number of Peers: 2

Hostname: nod2
Uuid: eaa065d3-f713-4c63-9287-0c50bef9ccc0
State: Peer in Cluster (Connected)

Hostname: nod3
Uuid: d1bdbc55-c6c6-461e-b5c9-c0bfa3d39f88
State: Peer in Cluster (Connected)

Vyřazení serveru z TSP

root@nod1 :~# gluster peer detach nod3

Použití parametru force

root@nod1 :~# gluster peer detach nod3 force

Vytvoření svazku - volume

GlusterFS je distribuovaný souborový systém, neposkytuje tedy žádné blokové zařízení, ale tzv. svazky (volumes), které jsou složené z tzv. bricků. Bricky jsou adresáře na jednotlivých serverech v rámci TSP.

Svazek v minimální konfiguraci může být tvořen pouze jedním brickem.

root@nod1 ~# gluster volume create Svazek transport tcp nod1:/blok1

Pokud by adresář /blok1 byl pouze přípojným bodem pro některé z lokálních blokových zařízení serveru nod1, pak by musel být připojen na konec příkazu ještě parametr force

Aby bylo možné vytvořený svazek připojit, musí být nejprve aktivován parametrem start.

root@nod1 :~# gluster volume list
Svazek
root@nod1 :~# gluster volume start Svazek
volume start: Svazek: success

Pokud existuje v rámci TSP svazků více, lze se o každém z nich dozvědět více informací parametrem info

root@nod1 :~# gluster volume info Svazek

Volume Name: Svazek
Type: Distribute
Volume ID: 42ec4023-3304-4901-901e-73e8d1f6582a
Status: Created
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: nod1:/blok1

Chceme-li naopak svazek zrušit, je třeba zachovat následující postup:

Nejprve svazek zastavíme - gluster volume stop jméno_svazku
Potom ho zrušíme - gluster volume delete jméno_svazku

Při zrušení se sice odstraní soubory v adresáři /var/lib/glusterd/vols, ale uložená data i logy zůstanou - místo se tedy neuvolní. Je tedy třeba provést už na jednotlivých nodech..

Vymazání dat, případně odpojení a následné zrušení LV oddílu
Odstranění logu

Distribuovaný svazek

I když svazek může tvořit pouze jeden brick, z praktického hlediska by to nic pozitivního nepřinášelo. Podstata GlusterFS je v tom, že umožňuje svazky pružně sestavovat z mnoha desítek i stovek bricků a tak vytvořit úložiště s parametry, jaké ani není technicky možné na jednom fyzickém stroji dosáhnout.

Pokud k již vytvořenému svazku přidáme další brick, začne GlusterFS rozhazovat soubory rovnoměrně mezi ně. Tím se sníží počet operací se soubory zpracovávaný na jednom serveru a díky tomu bude přístup ke svazku rychlejší, než kdyby se pracovalo s jedním velkým fyzickým blokovým zařízením.

Použití: Distribuovaný svazek, který funguje ve své podstatě jako síťový raid0, nemá sice žádnou redundanci dat, ale nabízí vysoký výkon a maximum datového prostoru.

Tento vysoký výkon, je ale vykoupen velkou dávkou rizika. Soubory jsou rozloženy rovnoměrně mezi všechny bricky a tak výpadek jednoho z nich povede k tomu, že data která na něm byla uložena, budou nedostupná.

Distribuovaný svazek obvykle zakládáme rovnou přes několik bricků

root@nod1 :~# gluster volume create Svazek nod1:/blok1 nod2:/blok1

Rozšíření svazku o další brick

Když chceme zvýšit jeho kapacitu, můžeme tak učinit velice snadno tím, že jej rozšíříme o další brick

root@nod1 :~# gluster volume info Svazek
 
Volume Name: Svazek
Type: Distribute
Volume ID: 42ec4023-3304-4901-901e-73e8d1f6582a
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: nod1:/blok1
root@nod1 :~# gluster volume add-brick Svazek nod2:/blok1
volume add-brick: success
root@nod1 :~# gluster volume info Svazek
 
Volume Name: Svazek
Type: Distribute
Volume ID: 42ec4023-3304-4901-901e-73e8d1f6582a
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: nod1:/blok1
Brick2: nod2:/blok1

Další brick můžeme přidat kupř. pokud plánujeme odstavit některý ze stávajících serverů, aniž by tím došlo k znefunkčnění stávajícího svazku, aby bylo kam uložená data přesunout.

Informace o stavu svazku

root@nod1 :~# gluster volume status Svazek
Status of volume: Svazek
Gluster process                                     Port    Online  Pid
------------------------------------------------------------------------------
Brick nod1:/blok1                                   49154   Y       2400
Brick nod2:/blok1                                   49154   Y       2614
NFS Server on localhost                             2049    Y       16139
NFS Server on nod2                                  2049    Y       28432
 
Task Status of Volume Svazek
------------------------------------------------------------------------------
There are no active volume tasks

Redukce svazku

Před redukcí svazku musíme být zajištěna dostatečná datová kapacita zbývajících bricků, aby bylo kam přesunout data svazku z bricku ze serveru, který z nějakého důvodu potřebujeme odstavit - kupř. za účelem aktualizace jeho systému, aj.

Odstavení bricku spočívá ze tří fází:

Nejprve je třeba zahájit přesun dat (parametr start)
Teprve jsou-li data odsunuta (stav přesunu lze průběžně ověřovat s parametrem status)..
je možné parametrem commit operaci dokončit

root@nod1 :~# gluster volume remove-brick Svazek nod1:/blok1 start 
volume remove-brick start: success
ID: c6ab64f7-d921-4e07-9350-0524b7d2a613
root@nod1 :~# gluster volume remove-brick Svazek  nod1:/blok1 status
   Node  Rebalanced-files        size      scanned    failures      skipped       status  run time in secs
  ---------  -----------  -----------  -----------  -----------  -----------  ------------   --------------
   localhost            0      0Bytes            0            0            0    completed             0.00
root@nod1 :~# gluster volume remove-brick Svazek nod1:/blok1 commit
Removing brick(s) can result in data loss. Do you want to Continue? (y/n) y
volume remove-brick commit: success

Od verze 3.6, lze brick ze svazku vyhodit bez ohledu na to, jestli na něm ještě nějaká data jsou, či nejsou!

Stripovaný svazek

U stripovaný svazek se od distribuovaného liší tím, že se do bricků neukládají soubory tak jak jsou, ale jsou rozsekány a mezi bricky rozhozeny po menších částech - stripech. To je výhodné především u velmi velkých souborů ( > než 100GB ) - i když je nutno říct, že pro práci s tak velkými soubory obecně není GlusteFS moc vhodný.

Použití: Stripovaný svazek pak nabízí velmi rychlé čtení souborů, ale má extrémně pomalý zápis a navíc žádnou redundanci. Takže při výpadku jednoho bloku je nepoužitelný celý svazek. Proto se používá stripování zpravidla v kombinaci s replikací.

root@nod1 ~# gluster volume create Svazek stripe 2 transport tcp nod1:/blok1 nod2:/blok1

Rozdělování souborů do stripů vede na souborových systémech bricků na serverech ke zbytečné duplikaci dat, protože datový obsah stripů - byť vytvořených z identických souborů - není nikdy stejný. Takže v konečném důsledku může stripovaný svazek zabírat více hluchého místa, nežli svazek čistě distribuovaný.

Replikovaný svazek

Svazek, který je vytvořen jako replikovaný, ukládá pro každý soubor jeho kopii do dalšího bricku. Je-li tento brick na jiném serveru, pak bude svazek schopen ustát i výpadek na straně serveru poskytujícího některý s jeho bricků. Tím odstraňuje zásadní nedostatek čistě distribuovaného svazku. Na druhou stranu, daní za tento komfort je snížení využitelného datového prostoru v rámci svazku.

Použití: Jsou-li k dispozici alespoň dva bricky, z nichž každý je na jiném serveru tak funguje replikovaný svazek jako síťový raid1. Data však mohou být replikována i přes více bricků( a serverů). Tím je zajištěna redundance ukládaných souborů, proto jde o nejčastější řešení u HA clusterů. Replikovaný svazek je poměrně svižný při rychlé čtení, protože soubory lze načítat paralelně z několika serverů současně, tak jako u distribuovaného svazku. Má však horší výkon při zápisu.

root@nod1 ~# gluster volume create Svazek replica 2 transport tcp nod1:/blok1 nod2:/blok1

Počet replikací závisí od počtu dostupných bricků

Distribuovaný svazek s replikací

Distribuovaný svazek s replikací spojuje výhody replikovaného svazku s distribucí souborů přes více serverů. Čím větší je počet bricků na samostatných strojích, tím víc je eliminován problém s rychlostí lokálních IO operací a GlusterFS se jeví z hlediska svého výkonu svižnější. Úzkým hrdlem se pak stává propustnost sítě.

K vytvoření takového svazku dojde automaticky, je-li do svazku zařazen dvojnásobný počet bricků, než-li udává hodnota parametru replica

root@nod1 ~# gluster volume create Svazek replica 2 transport tcp nod1:/blok1 nod1:/blok2 nod2:/blok1 nod2:/blok2

Pozor! Při zakládání distribuovaného svazku s replikací záleží na pořadí bricků! Pokud by byly při zakládání svazku předány bricky v následujícím pořadí..

root@nod1 ~# gluster volume create Svazek replica 2 transport tcp nod1:/blok1 nod2:/blok1 nod1:/blok2 nod2:/blok2

..tak by při výpadku serveru nod2, nebo nod1 došlo k tomu, že by došlo k rozbití svazku, neboť by byla k dispozici neúplná data. Viz ilustrační obrázek:

Disperse

Je nový typ svazku, zavedený od GlusterFS verze 3.6 založený na stripování. Využívá se u něj nový překladač vrstvy, založený na matematických transformacích, který je schopen - v případě selhání bricku - rekonstruovat data chybějícího stripu z dat, které jsou součástí dostupných stripů. To, kolik bricků může ze svazku vypadnout, aniž by došlo ke ztrátě dat závisí na hodnotě disperze. Ta udává kolik bricků je potřeba k dopočítání chybějících dat. Jde v podstatě o síťový raid5.

U dispersního svazku lze volit také úroveň redundance, která je ovšem závislá na počtu dostupných bricků.

Použití: Dispersní svazek zachovává dostupnost dat i při výpadku serveru (podobně jako je tomu u replikace), ale zároveň při dostatečném počtu serverů významně snižuje hluchý prostor vyhrazený pro data nezbytná pro obnovu chybějícího stripu.

Co ovlivňuje výkon a spolehlivost GlusterFS

Srovnávací tabulka GlusterFS svazku o logické kapacitě 8TB, podle typu a kombinace bricků:

Typ svazku	Konfigurace	Počet bricků	Postradatelných^[1]	Kapacita bricku (v TB)	Celková kapacita fyzických zařízení (v TB)	Režie^[2]	Data souboru per brick^[3]	Data souboru^[4]	Traffic souboru per brick^[5]	Traffic souboru^[6]
replikovaný	3*8	3	2	8	24	66.7%	L	3*L	L	3*L
replikovaný	2*8	2	1	8	16	50%	L	2*L	L	2*L
dispersovaný	8+7	15	7	1	15	46.7%	L/8	1.88*L	L/8	1.88*L
dispersovaný	8+6	14	6	1	14	42.9%	L/8	1.75*L	L/8	1.75*L
dispersovaný	8+5	13	5	1	13	38.5%	L/8	1.63*L	L/8	1.63*L
dispersovaný	8+4	12	4	1	12	33.3%	L/8	1.5*L	L/8	1.5*L
dispersovaný	8+3	11	3	1	11	27.3%	L/8	1.38*L	L/8	1.38*L
dispersovaný	8+2	10	2	1	10	20%	L/8	1.25*L	L/8	1.25*L
dispersovaný	8+1	9	1	1	9	11.1%	L/8	1.13*L	L/8	1.13*L
stripovaný	8	8	0	1	8	0%	L/8	L	L/8	L

↑ Maximální počet bricků, který může vypadnout aniž by došlo k selhání svazku
↑ Objem dat vyhrazený pro zajištění redundance
↑ Objem dat jaký zabere jeden soubor na jednom bricku
↑ Celkově zabraná kapacita fyzických zařízení jedním souborem
↑ Počet síťových operací spojených s jedním souborem, připadající na jeden brick
↑ Celkový počet síťových operací, spojených s jedním souborem

počet serverů: Úzkým hrdlem GlusterFS, které lze eliminovat vyšším počtem serverů jsou souborové operace. Čtení či zápis souborů, nebo jejich části do adresářů bricků sebou nese jistou režii, která - pokud stroj zároveň funguje jako brick - zvyšuje lokální I/O zatížení. Čím větší je serverů, tím lepší je rozložení této zátěže a tím i výkon GlusterFS.
SSD versus HDD
samostatné fyzické disky pro bricky
konektivita: Vliv 1G sítě, 10G sítě, Infiniband
typ uložených souborů: Blokový přístup před BD xtranslator

Připojení svazku

Soubory na svazku, ke kterým se přistupuje přes API GlusterFS - typicky virtuální disky - tímto problémem netrpí, protože se do nich data zapisují po blocích.

Klient totiž nepoužívá pro přístup do souborového systému API, ale jaderný modul fuse, který provádí veškeré operace se soubory v userspace. Tím je ovšem jeho výkon degradován. S čím vyšším počtem souborů pracuje, tím vyšší režii (a nižší rychlosti při zápisu a čtení) to sebou nese.

Tento problém lze do jisté míry obejít, pokud se přistupuje k souboru v GlusterFS svazku přes API, které umožňuje blokový přístup.

S využitím fuse klienta

Aby bylo možné připojit GlusterFS svazek, nemusí být stroj na kterém je nainstalován klient součástí TSP. Klient však musí pro jeho připojení využít některý ze serverů, které do příslušného TSP zapojené jsou.

root@stroj :~# mount -t glusterfs nod1:/Svazek /mnt

Nemusí však jít nutně o server, který funguje zároveň jako brick. Navíc je pro mount k dispozici volba backupvolfile-server, kterou lze nastavit záložní server, pro případ že by ten původní byl z nějakého důvodu nedostupný.

root@stroj :~# mount -t glusterfs nod2:/Svazek /mnt -o backupvolfile-server=nod1

Serverů může být pochopitelně nastaveno více a místo volby lze alternativně použít následující syntaxi:

root@stroj :~# mount -t glusterfs nod2,nod1:/Svazek /mnt

Přes NFS

Přes CIFS

Snapshotování

Pokusy se snapshotováním nezkoušejte na žádném produkčním svazku! V každém případě doporučuji zvýšenou pozornost při čtení části věnované rekonstrukci svazku.

Snapshotování svazků lze používat od GlusterFS verze 3.6. Musí být ovšem splněna základní podmínka - a to, že je svazek sestaven z bricků, které jsou nad přírůstkovými logickými LVM oddíly ( Více k vytvoření takového oddílu viz LVM (thin provisioning)

Jakým způsobem snapshotování GlusterFS svazků funguje

Vytvoření snapshotu je jednoduché, ale bohužel tak jak snapshotování GlusterFS svazku funguje, není moc použitelné. A to z následujících důvodů:

Při snapshotu dojde k přemountování přípojného bodu stávajícího bricku z původního LV oddílu na jakýsi dočasný LV oddíl
LVM snapshot, je rovněž namountován, a to na nově vytvořený přípojný body v adresáři /run/gluster/snaps/.... Bohužel jméno tohoto přípojného bodu není stejné, ale pro každý nod vypadá jinak.
Problém představuje restart nodu. Obsah adresáře /run kde se tento přípojný bod nachází, se obvykle nachází v ramdisku. A po restartu nodu přestane existovat.
Další problém může vzniknout, pokud se pro připojení LV oddílu používá jeho jméno (LV name), uuid, nebo jméno souborového systému (LABEL).

Pokud je v souboru /etc/fstab LV oddíl identifikován jménem, nebo hodnotou uuid, nastane po restartu problém v tom, že GlusterFS svazku nebudou sedět atributy u adresáře bricku. Ty "správné" atributy totiž má brick, který je na jiném LV oddíle - tom, který byl založen při snapshotu.
Je-li v souboru /etc/fstab LV oddíl identifikován návěštím souborového systému, je situace komplikovaná v tím, že systém při restartu neví, který LV oddíl má vlastně namountovat. Takže se nepřipojí nic!

Při odstranění snapshotu dojde ke změně atributů bricku na původním svazku, a je-li takový svazek zastaven, už se jej nepodaří znovu nahodit!

Vytvoření snapshotu

root@nod1~# gluster snapshot create build1 buildinglab description Testovaci_snapshot
snapshot create: success: Snap build1_GMT-2015.05.26-14.19.01 created successfully

Změna v namountované struktuře..

...
/dev/mapper/ThinGroup-25fa0c73a6b24327927c0dc9f4f08dba_0      80G   29G   50G  37% /srv/buildinglab
...

Místo původního...

...
/dev/mapper/ThinGroup-buildinglab      80G   29G   50G  37% /srv/buildinglab
...

To však není jediná změna. Pro každý brick je vytvořen LVM snapshot, který je posléze namountován na dočasný mountpoint, který je na každém z nodů pojmenován jinak, ale hodnota trusted.glusterfs.volume-id všech objektů je stejná jako u výchozího snapshotovaného bricku.

Stav snapshotu

Přehled o tom, kam jsou tyto LVM snapshoty na jednotlivých nodech připojeny a zda-li je snapshot aktivní se lze dozvědět takto:

root@nod1~# gluster snapshot status

Snap Name : build1_GMT-2015.05.26-14.19.01
Snap UUID : 3b3b8e45-5c81-45ff-8e82-fea05b1a516a

        Brick Path        :   nod1:/run/gluster/snaps/25fa0c73a6b24327927c0dc9f4f08dba/brick1/data
        Volume Group      :   ThinGroup
        Brick Running     :   No
        Brick PID         :   N/A
        Data Percentage   :   40.80
        LV Size           :   80.00g


        Brick Path        :   nod2:/run/gluster/snaps/25fa0c73a6b24327927c0dc9f4f08dba/brick2/data
        Volume Group      :   ThinGroup
        Brick Running     :   No
        Brick PID         :   N/A
        Data Percentage   :   40.75
        LV Size           :   80.00g


        Brick Path        :   nod3:/run/gluster/snaps/25fa0c73a6b24327927c0dc9f4f08dba/brick3/data
        Volume Group      :   ThinGroup
        Brick Running     :   No
        Brick PID         :   N/A
        Data Percentage   :   40.82
        LV Size           :   80.00g

Aktivace a deaktivace snapshotu

Ve výchozím stavu je snapshot neaktivním stavu. To znamená, že jej nelze jako GlusterFS svazek připojit. Aby to bylo možné, musí být nejprve aktivován

root@nod1~# gluster snapshot activate build1_GMT-2015.05.26-14.19.01
Snapshot activate: build1_GMT-2015.05.26-14.19.01: Snap activated successfully

Deaktivaci snaphotu lze provést obdobným způsobem

root@nod1~# gluster snapshot deactivate build1_GMT-2015.05.26-14.19.01
Deactivating snap will make its data inaccessible. Do you want to continue? (y/n) y
Snapshot deactivate: build1_GMT-2015.05.26-14.19.01: Snap deactivated successfully

Výpis existujících snapshotů

Pro připojení snapshotu je důležité jeho jméno. Součástí jména snapshotu je ve výchozím stavu časové razítko, pokud to ovšem nepotlačíme parametrem při vytvoření snapshotu. Následujícím příkazem si můžeme vylistovat seznam všech existujících snapshotů:

root@nod1~# gluster snapshot list
build1_GMT-2015.05.26-14.19.01

Připojení snapshotu

Jako GlusterFS svazek lze připojit pouze aktivovaný snapshot. Ovšem pozor! Pouze pro čtení! Pokud chcete mít ze snapshotu normální GlusterFS svazek, tak ho z něj musíte nejprve naklonovat.

root@nod1~# mount -t glusterfs localhost:/snaps/build1_GMT-2015.05.26-14.19.01/buildinglab /mnt

Povšimněte si, že cesta pro připojení snapshotu je jiná, než u normálního svazku. Její součástí kromě jména snapshotu také název původního svazku!

Klonování snapshotu

Naklonovat lze pouze aktivní snapshot!

root@nod1~# gluster snapshot clone build-new build1_GMT-2015.05.26-14.19.01
snapshot clone: success: Clone build-new created successfully
root@nod1~# mount
...
/dev/mapper/ThinGroup-build--new_0 on /srv/buildinglab type btrfs (rw,relatime,nodatasum,nodatacow,space_cache,autodefrag)
/dev/mapper/ThinGroup-build--new_0 on /run/gluster/snaps/25fa0c73a6b24327927c0dc9f4f08dba/brick2 type btrfs (rw,relatime,nodatasum,nodatacow,space_cache,autodefrag)
/dev/mapper/ThinGroup-build--new_0 on /run/gluster/snaps/build-new/brick2 type btrfs (rw,relatime,nodatasum,nodatacow,space_cache,autodefrag)
...

Naklonovaný svazek se objeví jako normální GlusterFS svazek, proto jeho jméno nesmí být stejné, jako má některý jiný již existující svazek

A právě v tomto bodě s největší pravděpodobností narazíte na problém spojený s vygenerovanou cestou k bricku. Ten lze vyřešit leda tím, že se upraví konfigurace GlusterFS klonu na všech nodech. Jenže k tomu je nutné svazek nejprve zastavit, připravit nové přípojné body, upravit na všech nodech soubor /etc/fstab, přemountovat LV oddíly; pak provést editaci konfiguračních souborů svazku - opět na všech nodech a poté zkusit svazek znovu nahodit.

Druhá varianta - postupně za běhu bricky odstranit, připravit nové přípojné body, upravit na všech nodech soubor /etc/fstab, přemountovat LV oddíl a přemountovaný brick znovu přidat.

Podrobné informace o snapshotu

root@nod1~# gluster snapshot info
Snapshot                  : build1_GMT-2015.05.26-14.19.01
Snap UUID                 : 3b3b8e45-5c81-45ff-8e82-fea05b1a516a
Description               : Testovaci_snapshot
Created                   : 2015-05-26 14:19:01
Snap Volumes:

        Snap Volume Name          : 25fa0c73a6b24327927c0dc9f4f08dba
        Origin Volume name        : buildinglab
        Snaps taken for buildinglab      : 1
        Snaps available for buildinglab  : 255
        Status                    : Stopped

Odstranění snaphotu

root@nod1~# gluster snapshot delete build1_GMT-2015.05.26-14.19.01
Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
snapshot delete: build1_GMT-2015.05.26-14.19.01: snap removed successfully

Rekonstrukce svazku

Vzniku potenciálních problémů se GlusterFS snaží předcházet tím, že pokud nastane situace, která by hrozila vznikem nekonzistence, dovolí k souborům přistoupit pouze v režimu "jen pro čtení" (read-only).

U virtuálního stroje se to projeví tím, že se v jeho logu začnou objevovat zprávy které vypadají jako by byl poškozený souborový systém.

Ve skutečnosti se nic kritického neděje - změny jsou totiž pouze v paměti. Problém je třeba ihned řešit, protože po určité době stroj zaplácne paměť, zkolabuje a změny zahodí. K poškození dat uložených na GlusterFS ale během té doby nedojde.

Příčiny mohou být různé.

nepřipojený glusterd démon u některého z bricků
split-brain

Nepřipojený glusterd démon u některého z bricků

Z příčiny mně blíže neznámé nastala situace, kdy u svazku replikovaného na tři nody se démon jednoho z bricků dostal do stavu offline.

root@nod1 :~/kompilace# gluster volume status Svazek
Status of volume: Svazek
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick nod1:/srv/Svazek/data                 49178     0          Y       2664 
Brick nod2:/srv/Svazek/data                 49178     0          N/A     12439
Brick nod3:/srv/Svazek/data                 49178     0          Y       2590 
Self-heal Daemon on localhost               N/A       N/A        Y       2642 
Self-heal Daemon on nod3                    N/A       N/A        Y       2551 
Self-heal Daemon on nod2                    N/A       N/A        Y       12433
 
Task Status of Volume Svazek
------------------------------------------------------------------------------

Pro bricky ostatních svazků byli démoni OK. Zkusil jsem na stroji nod2 restartovat GlusterFS, ale situace byla stáje stejná. Protože jsem nevěděl co bylo příčinou, zkusil jsem nejprve zjistit, jak je na tom Svazek se zdravím:

root@nod2 :~# gluster volume heal git info
Brick nod1:/srv/Svazek/data/
<gfid:4aae4907-d363-49d2-ae93-c00eb92f70b5> 
Number of entries: 1

Brick nod2:/srv/Svazek/data/
<gfid:4aae4907-d363-49d2-ae93-c00eb92f70b5> 
Number of entries: 1

Brick nod3:/srv/Svazek/data/
/disk.img 
Number of entries: 1

Z výše uvedeného výpisu bylo zřejmé, že GlusterFS čeká, až se do souboru disk.img na bricku stroje nod3 promítnou změny ze zbylých dvou bricků - nod1 a nod2. Jenže díky tomu, že démon bricku stroje nod2 z nějakého důvodu nekomunikoval, nebylo možné operaci dokončit.

Za normálních okolností probíhá tzv. self-healing (samoozdravný proces) automaticky, ale v tomto případě zřejmě potřeboval nakopnout. Zkusil jsem ho tedy aktivovat manuálně.

Aktivace ozdravného procesu

root@nod2 :~# gluster volume heal Svazek enable
root@nod2 :~# gluster volume heal Svazek info
Brick nod1:/srv/Svazek/data/
<gfid:4aae4907-d363-49d2-ae93-c00eb92f70b5> - Possibly undergoing heal

Number of entries: 1

Brick nod2:/srv/Svazek/data/
<gfid:4aae4907-d363-49d2-ae93-c00eb92f70b5> - Possibly undergoing heal

Number of entries: 1

Brick nod3:/srv/Svazek/data/
/disk.img - Possibly undergoing heal

Number of entries: 1

Takto vypadal výpis zdravotního stavu Svazku v průběhu ozdravného procesu. Po dokončení vypadal následovně a bylo s ním možné zase normálně pracovat:

root@nod2 :~# gluster volume heal Svazek info
Brick nod1:/srv/Svazek/data/
Number of entries: 0

Brick nod2:/srv/Svazek/data/
Number of entries: 0

Brick nod3:/srv/Svazek/data/
Number of entries: 0

split-brain

Může se stát, že za určitých okolností dojde ke stavu, který se anglicky nazývá split-brain.

Je to situace, kdy se dostanou data či metadata bricků do vzájemné nekonzistence. Důsledkem je, že se pak soubor uložený na glusterfs svazku nedá přečíst, ačkoliv je normálně vidět.

Dříve tato situace vyžadovala práci s rozšířenými atributy na jednotlivých nodech. U novějších verzí GlusterFS to není třeba. Následující příklad demonstruje řešení nekonzistence ( split-brainu ) u souboru disk.img, který je uložen v rámci svazku Svazek:

root@nod1 :~# mount -t glusterfs localhost:/Svazek /mnt
root@nod1 :~# ls -al /mnt/
celkem 12582916
drwxr-xr-x 3 root root        4096 kvě  6 12:51 .
drwxr-xr-x 1 root root         140 dub 24 11:56 ..
-rw-r--r-- 1 root root 12884901888 čec  3  2015 disk.img
root@nod1 :~# md5sum /mnt/disk.img 
md5sum: /mnt/disk.img: Chyba vstupu/výstupu
root@nod1 :~# gluster volume heal Svazek info
Brick nod1:/srv/Svazek/data/
<gfid:5d832dd1-4278-4c57-8d10-a18ac459dfc9> - Is in split-brain

Number of entries: 1

Brick nod3:/srv/Svazek/data/
<gfid:5d832dd1-4278-4c57-8d10-a18ac459dfc9> - Is in split-brain

Number of entries: 1

Brick nod2:/srv/Svazek/data/
<gfid:5d832dd1-4278-4c57-8d10-a18ac459dfc9> - Is in split-brain

Number of entries: 1

Dotazem na "zdraví" svazku Svazek jsme zjistili, že ze tří bricků je ve stavu split-brain jeden. Abychom mohli provést opravu, je třeba zjistit, který z nich má neplatné atributy, které brání v automatickém "uzdravení" svazku.

Analýza atributů

Pokud jde v případě souboru disk.img o soubor virtuálního disku, je vhodné nejprve odstavit všechny klienty, které mají tendenci na něj hrabat, abychom měli jistotu, že nám některý proces nebude do problematického souboru hrabat.

Správnou kopii určíme porovnáním afr atributů, které zjistíme pomocí příkazu getfattr:

root@nod1 :~# getfattr -d -e hex -m . /srv/Svazek/data/disk.img
getfattr: Odstraňuji úvodní „/“ z absolutní cesty
# file: srv/Svazek/data/disk.img
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.Svazek-client-0=0x000000000000000000000000
trusted.afr.Svazek-client-1=0x000000000000000000000000
trusted.afr.Svazek-client-2=0x000000090000000000000000
trusted.afr.Svazek-client-3=0x000000000000000000000000
trusted.gfid=0x5d832dd142784c578d10a18ac459dfc9

root@nod2 :~# getfattr -d -e hex -m . /srv/Svazek/data/disk.img
getfattr: Odstraňuji úvodní „/“ z absolutní cesty
# file: srv/Svazek/data/disk.img
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.Svazek-client-0=0x000000000000000000000000
trusted.afr.Svazek-client-2=0x000000090000000000000000
trusted.afr.Svazek-client-3=0x000000000000000000000000
trusted.gfid=0x5d832dd142784c578d10a18ac459dfc9

root@nod3 :~# getfattr -d -e hex -m . /srv/Svazek/data/disk.img
getfattr: Odstraňuji úvodní „/“ z absolutní cesty
# file: srv/Svazek/data/disk.img
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.Svazek-client-0=0x000000010000000000000000
trusted.afr.Svazek-client-1=0x000000000000000000000000
trusted.afr.Svazek-client-2=0x000000000000000000000000
trusted.afr.Svazek-client-3=0x000000290000000000000000
trusted.gfid=0x5d832dd142784c578d10a18ac459dfc9

Každá kopie souboru by měla mít stejný počet afr atributů i jejich jména.
Jména afr atributů typu klient jsou složená ze jména svazku a pořadových čísel bricků tak jak je vrací následující příkaz:

root@nod1 :~# gluster volume info Svazek
 
Volume Name: Svazek
Type: Replicate
Volume ID: c5d9fc30-fcc1-4bd1-b535-5aba172488d2
Status: Stopped
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: nod1:/srv/Svazek/data
Brick2: nod3:/srv/Svazek/data
Brick3: nod2:/srv/Svazek/data
Options Reconfigured:
network.ping-timeout: 5
nfs.disable: on

Z uvedeného výpisu tedy plyne, že...

trusted.afr.Svazek-client-1 == nod1
trusted.afr.Svazek-client-2 == nod3
trusted.afr.Svazek-client-3 == nod2

Abychom mohli určit, na kterém bricku je chyba, musíme vědět, jak číst hodnotu afr atributu. Tu tvoří 3x8 znaků.

Prvních osm deklaruje stav uložených dat
Dalších osm deklaruje stav metadat
A posledních osm něco, zatím nevím co

Je-li hodnota všech osmi znaků 0 (nula), pak to znamená, že je stav příslušných dat OK a brick je připraven přijmout potencionální změny. Cokoliv jiného signalizuje, že někde visí data, která je třeba zapsat.

Porovnáním atributů z uvedených výpisů, můžeme konstatovat následující:

Metadata mají všechny bricky v pořádku (všude jsou samé nuly)
V atributech souboru srv/Svazek/data/disk.img na stroji nod2 chybí záznam pro brick na stroji nod1 (trusted.afr.Svazek-client-1)
Hodnota atributu trusted.afr.Svazek-client-2 na nodech nod1 a nod2 signalizuje, že se do kopie souboru na stroji nod3 mají zapsat nějaká data.
Hodnota atributu trusted.afr.Svazek-client-3 na nodu nod3 signalizuje, že by se měly naopak zapsat nějaká data odsud.

Pokud bychom měli svazek replikovaný pouze mezi dva bricky, tak bychom se museli rozhodnout, u kterého z nich jsou data validní. Ovšem v případě, kdy se data replikují mezi tři nody, rozhoduje většina. Takže ustoupit musí klient stroje nod3.

Ostatně, že jsou kopie souboru na nodech nod1 a nod2 stejné si můžeme ověřit pomocí kontrolního součtu:

root@nod1 :~# md5sum /srv/Svazek/data/disk.img
26b727e6761d341e9d28faa2c5286fbb  /srv/Svazek/data/disk.img

root@nod2 :~# md5sum /srv/Svazek/data/disk.img
26b727e6761d341e9d28faa2c5286fbb  /srv/Svazek/data/disk.img

root@nod3 :~# md5sum /srv/Svazek/data/disk.img
d5e9edbafdf9f181317fa7e9b6b66fd0  /srv/Svazek/data/disk.img

Oprava

U starších verzí GlusterFS bylo nutné před spuštěním samoopravného procesu dát atributy do pořádku jednotlivě na všech nodech postupem, který je popsán popsán níže. U současných verzí to již není nutné. Stačí pouze analýzou atributů zjistit, na kterém bricku se nachází správná kopie souboru.

V předchozím ukázkovém příkladu jsme analýzou atributů zjistili, že správnou verzi souboru obsahuje brick na stroji nod3. Opravu tedy můžeme provést z libovolného nodu následujícím způsobem:

root@nod2 :~# gluster volume heal ganesha split-brain source-brick nod3:/srv/Svazek/data /disk.img

Původní postup opravy atributů

U starších verzí bylo třeba úkonů více:

Doplnit chybějící atribut trusted.afr.Svazek-client-1 u souboru na nodu nod2
Vynulovat atribut trusted.afr.Svazek-client-3 u kopie souboru na stroji nod3

root@nod2 :~# setfattr -n trusted.afr.Svazek-client-1 -v 0x000000000000000000000000 /srv/Svazek/data/disk.img

root@nod3 :~# setfattr -n trusted.afr.Svazek-client-3 -v 0x000000000000000000000000 /srv/Svazek/data/disk.img

Pak nahodíme svazek, namountujeme přes FUSE klienta a čtením souboru vyvoláme "samoopravný" proces.

root@nod1 :~# gluster volume start Svazek
root@nod1 :~# mount -t glusterfs localhost:/Svazek /mnt
root@nod1 :~# md5sum /mnt/disk.img 
 26b727e6761d341e9d28faa2c5286fbb  /mnt/disk.img
root@nod1 :~# gluster volume heal Svazek info split-brain
Brick nod1:/srv/Svazek/data/
Number of entries in split-brain: 0

Brick nod3:/srv/Svazek/data/
Number of entries in split-brain: 0

Brick nod2:/srv/Svazek/data/
Number of entries in split-brain: 0

Z výsledku kontrolního součtu je zřejmé, že byl problém vyřešen a hodnota odpovídá kontrolnímu součtu souboru na nodech nod1 a nod2 před opravou. A dotazem na "zdravotní" stav svazku zjistíme že není žádná položka svazku ve stavu split-brain

Parametry pro volumes

Pro výpis uživatelsky nastavených parametrů GlusterFS svazku se používá příkaz info (viz příklad výše). Vrací však pouze parametry které byly změněné! Aktuální nastavení všech parametrů lze zjistit pomocí klíčového slova all předaného příkazu get:

root@nod1 :~# gluster volume get Svazek all
Option                                  Value                                   
------                                  -----                                   
cluster.lookup-unhashed                 on 
...

Pokud nás zajímá pouze konkrétní hodnota vybraného parametru, předá se místo klíčového slova all parametr:

root@nod1 :~# gluster volume get Svazek nfs.disable
Option                                  Value                                   
------                                  -----                                   
nfs.disable                             on

Uživatelsky pozměnněné parametry lze vrátit na jejich výchozí hodnotu pomocí příkazu reset. Viz následující příklad jak vrátit uživatelsky nastavený parametr nfs.disable na výchozí hodnotu:

root@nod1 :~# gluster volume reset Svazek nfs.disable
volume reset: success: reset volume successful

Pokud by mělo být cílem pouze povolení zapnutí NFS serveru, tak by stačilo příkazem set změnit hodnotu blokování spouštění NFS serveru z on na off

Nastavení jiné než výchozí hodnoty parametru se provádí příkazem set takto:

V následujícím příkladu je vypnut přístup ke svazku Svazek přes NFS

root@nod1 :~# gluster volume set Svazek nfs.disable on
volume set: success
root@nod1 :~# gluster volume info Svazek
 Volume Name: Svazek
Type: Replicate
Volume ID: 7fde9b2c-b50f-4e54-bb4b-388450dddbcc
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: nod1:/srv/blok1
Brick2: nod2:/srv/blok1
Options Reconfigured:
nfs.disable: on

Tabulka parametrů

Parametr	Popis	Výchozí hodnota	Použitelná hodnota
Přístup klientů ke GlusterFS svazku
auth.allow	IP adresy strojů které mohou ke svazku přistupovat	* (přístup povolen všem bez omezení)	IPv4 adresa, u které lze za pomoci znaku '' vymezit širší rozsah např. 192.168.1.
auth.reject	IP adresy strojů kterým má být přístup ke svazku odepřen	NONE (nikomu nemá být přístup odepřen)	IPv4 adresa, u které lze za pomoci znaku '' vymezit širší rozsah např. 192.168.1.
client.grace-timeout	Specifikuje čas, po který se má podržet zámek pro spojení s klientem v případě jeho přerušení. Pokud dojde k obnovení spojení před uplynutím tohoto intervalu, zůstane spojení zachováno.	10	10 - 1800 sekund (30 minut)
network.frame-timeout	Časový interval, během kterého musí dojít ke zpracování dílčí operace. Pokud během něj nedojde odpověď, že byla operace zpracovaná, je spojení s nodem prohlášeno za mrtvé.	1800 (30 minut)	Není žádný limit
network.ping-timeout	Čas, po jehož uplynutí je považováno spojení mezi nody za přerušené. Pokud se tak stane, tak se před navázáním nového spojení nejprve aktualizují zámky a teprve pak se pokračuje v dílčích operacích. Toto je však z hlediska systémových prostředků náročná operace, které je třeba se pokud možno vyhnout. Na druhou stranu se tím prodlužuje čas, než je navázáno spojení s GlusterFS svazkem přes alternativní nod.	42 sekund	Není žádný limit
Nastavení GlusterFS nodu
server.allow-insecure	Tímto parametrem lze povolit připojení GlusterFS klienta na neprivilegovaném portu. Jinak se používají pouze privilegované porty (do portu 1024), ke kterým může přistupovat pouze root.	on	on/off
server.grace-timeout	Specifikuje čas, po který se má podržet zámek pro spojení s nodem v případě jeho přerušení. Pokud dojde k obnovení spojení před uplynutím tohoto intervalu, zůstane spojení zachováno.	10	10 - 1800 sekund (30 minut)
server.statedump-path	Cesta kam se ukládá soubor s výstupem příkazu statedump. Název souboru je sestaven ze skutečné cesty do adresáře bricku (lomítka jsou nahrazena pomlčkami), přípony `.dump` a časového razítka.	Adresář `/run/glusterfs` na stroji kde se nalézá brick. U starších verzí GlusterFS než 3.6 se dump soubor ukládal do adresáře `/tmp` a jeho jméno bylo sestaveno z cesty k bricku, čísla lokálního procesu a přípony `.dump`	Cesta do adresáře kam se zapíše výstup do souboru.
server.ssl	Šifrování komunikace mezi nody přes SSL	off	on/off
Nastavení úložiště bricku
storage.health-check-interval	Interval, v jakém má být prováděna kontrola stavu souborů uložených v rámci bricku	30 sekund	Je-li nastaven počet sekund na 0, bude tato kontrola vypnuta
storage.linux-aio	Používat nativní linuxové AIO (asynchronní IO) na straně úložiště	off	on/off
storage.owner-uid	UID pro soubory bricku na straně úložiště	Není žádná hodnota	Číselná hodnota UID
storage.owner-gid	GID pro soubory bricku na straně úložiště	Není žádná hodnota	Číselná hodnota GID
Diagnostika GlusterFS
diagnostics.brick-log-level	Nastavení úrovně logovaných zpráv týkajících se bricku	INFO	DEBUG/WARNING/ERROR/CRITICAL/NONE/TRACE
diagnostics.client-log-level	Nastavení úrovně logovaných zpráv týkajících se klienta	INFO	DEBUG/WARNING/ERROR/CRITICAL/NONE/TRACE
diagnostics.count-fop-hits	Sledování počtu souborových operací io-stat modulu v rámci datové struktury GlusterFS		on/off
diagnostics.dump-fd-stats	Sledování souborových operací v rámci datové struktury GlusterFS	off	on/off
diagnostics.latency-measurement	Sledování latence zpracovávaných operací v rámci datové struktury GlusterFS	off	on/off
Nastavení GlusterFS clusteru
cluster.background-self-heal-count	Počet bloků, který se může zpracovávat na pozadí, aniž by to vyžadovalo zablokování zpracování datových operací		0 - číslo bez omezení
cluster.choose-local	Parametr dovolí použít při čtení svazku lokální brick, není-li explicitně nastaven parametr cluster.read-subvolume	false	true/false
cluster.data-change-log	Pokud bude tento parametr ve stavu off, nebudou datové operace typu write/truncate při AFR transakcích, které oznamují počet selhání při zápisu, volat operace pre/post, které by se jinak zapisovaly do logu.		on/off
cluster.data-self-heal-algorithm	Při nastavení full se kopíruje celý soubor ze zdroje na kopie. Při nastavení diff se na kopie kopírují pouze ty bloky, jejichž kontrolní součet není shodný se zdrojem. Při nastavení reset se kopírují bloky podle následujícího heuristického modelu. Pokud soubor neexistuje, nebo má nulovou velikost, je zkopírován celý soubor. Je-li velikost souboru stejná, pak se data zdrojového souboru postupně po kouscích čtou a zapisují do kopie, což je rychlejší proces, než pokud by se měly navíc dělat kontrolní součty.	reset	full/diff/reset
cluster.data-self-heal-window-size	Maximální počet bloků na soubor, které může samoopravný mechanismus zpracovávat současně.		1 - 1024
cluster.eager-lock			on/off
cluster.ensure-durability	Tento parametr zajišťuje, že na data i metadata jsou aktivovány mechanismy, které zajišťují konzistenci uložených dat při náhlém výpadku bricku	on	on/off
cluster.entry-change-log			on/off
cluster.heal-timeout		600 sekund	60 - libovolné kladné číslo
cluster.iam-self-heal-daemon			on/off
cluster.metadata-change-log			on/off
cluster.min-free-disk	Parametr určuje kolik procent diskového prostoru v rámci souborového systému na kterém se nachází brick má zůstat volných. Tato volba je použitelná především s situaci, kdy mají disky s bricky různou kapacitu.	10%	Procentuálně určená velikost volného místa
cluster.min-free-inodes			% procenta
cluster.nufa			on/off
cluster.pop-op-delay-secs			číslo
- cluster.quorum-count	Počet svazků, které musí být přítomny aby bylo zachováno fórum. Pokud není nastavená žádná hodnota, má parametr 'cluster.quorum-type automaticky hodnotu fixed	0
- cluster.quorum-type	Parametr nastavuje, jaký typ metody se má použít pro zachování fóra. None znamená, že se žádné fórum používat nemá. Auto znamená, že je na fórum brán zřetel za předpokladu, že je dostupná alespoň polovina bricků svazku. Resp. polovina bricků prvního svazku v seznamu. Fixed znamená, že je pro zachování fóra vyžadován počet bricků uvedených v parametru cluster.quorum-count. Není-li možné zachovat fórum, pak bude končit zápis příznakem EROFS - což by mělo zabránit tomu, aby nastal "split brain", tj. stav kdy na každém bricku je zapsán do stejného místa jiný kus dat.	None	None/Auto/Fixed
cluster.read-hash-mode			0 - 2
cluster.rebalance-stats			on/off
cluster.readdir-failover			on/off
cluster.readdir-optimize			on/off
cluster.read-subvolume	Tímto parametrem lze nastavit u replikovaného svazku, že se budou inody načítat pouze z jednoho bricku. Hodnotou parametru může být pouze jeden z xlator názvů potomka. Např. Svazek-client-0		Jméno svazku `-client-` počet bricků - 1
cluster.read-subvolume-index			-1 - <počet replikací -1>
cluster.self-heal-daemon	Parametr dovoluje vypnout samoopravné mechanismy při replikaci	on	on/off
cluster.self-heal-readdir-size			1024 - 131072
cluster.self-heal-window-size	Parametr určuje maximální počet bloků z jednoho souboru, který se může souběžně kontrolovat během samoopravného procesu.	16	0 - 1025 bloků
cluster.strict-readdir			on/off
cluster.stripe-block-size	Nastavení velikosti stripu - bloku dat dat který GlusterFS pracuje. Tuto velikost lze nastavovat také individuálně podle jména souboru <filename-pattern:blk-size>	128 KB (hodnota platná pro všechny soubory)	Libovolná velikost v bajtech
Parametry ovlivňující výkon GlusterFS
performance.cache-max-file-size
performance.cache-min-file-size
performance.cache-refresh-timeout
performance.cache-size
g performance.enable-least-priority			on/off
performance.flush-behind			on/off
g performance.force-readdirp			on/off
g performance.high-prio-thread			1 - 64
performance.io-thread-count
performance.least-prio-threads			1 - 64
performance.least-rate-limit			číslo
performance.low-prio-threads			1 - 64
performance.normal-prio-threads			1 - 64
performance.strict-o-direct			on/off
performance.strict-write-ordering			on/off
performance.write-behind-window-size
Připojení ke GlusterFS svazku přes NFS v3
nfs.addr-namelookup	Pomalé odpovědi z DNS mohou způsobovat prodlevu během mountu. Tímto parametrem lze ověřování adres v DNS vypnout. Ovšem pozor! Pro připojení pak musíte využívat IPv4 adresy.	on	on/off
nfs.disable	Zablokovat spuštění NFS serveru	off (NFS server je zapnutý)	on/off
nfs.enable-ino32	Je-li povolen tento parametr, budou ke 32-bitovým NFS klientům, které nemají podporu pro 64bitová čísla a velké soubory převáděna čísla inodů na 32bitová. Tento parametr je klíčový, pokud má být GlusterFS svazek exportován přes NFS server, neboť 64bitová čísla inodů mohou vést k tomu, že některé věci nebudou "záhadným způsobem" fungovat!	off	on/off
nfs.export-dir	Tento parametr umožňuje publikovat přes NFS server pouze vybrané podadresáře GlusterFS svazku. Vypublikovaná je vždy absolutní cesta k podadresáři a za ní mezerami oddělený seznam IPv4 adres (nebo doménových jmen) strojů, které mají k němu mít přístup. Místo doménových jmen je lepší použít IPv4 adresy, protože pak nevznikají problémy v případě nedostupnosti DNS serveru.	Ve výchozím stavu se neexportuje nic	Seznam exportovaných položek, vzájemně oddělených čárkou.
nfs.export-volumes	Tímto parametrem lze vypnout globální NFS export celého GlusterFS svazku. Hodí se, pokud chcete povolit pouze připojení adresářů exportovaných přes parametr nfs.export-dir	on	on/off
nfs.port <PORT>	Prostřednictvím tohoto parametru lze změnit výchozí číslo portu pro NFS (2049) pro NFS server GlusterFS svazku na jiné.	NA	38465 - 38467
nfs.ports-insecure	Tímto parametrem lze povolit připojení klienta na neprivilegovaném portu. Jinak se používají jen privilegované porty (do portu 1024), ke kterým má přístup pouze root.	off	on/off
nfs.register-with-portmap	Na strojích, které spouští více NFS serverů je třeba zabránit tomu, aby se nepraly o službu portmap, proto je v takovém případě potřeba registraci služby portmap pro GlusterFS NFS vypnout.	on	on/off
nfs.rpc-auth-allow <IPv4 adresa>	Je-li parametr nastaven, tak GlusterFS NFS bude akceptovat pouze připojení ze strojů které jsou v uvedeném seznamu IPv4 adres. Místo IPv4 adres mohou být použita také doménová jména. Toto nastavení bude akceptováno pro připojení všech adresářů exportovaného svazku.	Není-li uvedena žádná hodnota, nebude možné se připojit z žádného stroje.	Seznam IP adres, nebo doménových jmen. Položky odděleny čárkou.
nfs.rpc-auth-null	Parametrem lze vypnout ověřování typu AUTH_NULL. Měnit výchozí hodnotu tohoto parametru se nedoporučuje.	on	on/off
nfs.rpc-auth-reject <IPv4 adresa>	Je-li parametr nastaven, tak GlusterFS NFS odmítne připojení ze strojů které budou v uvedeném seznamu IPv4 adres. Místo IPv4 adres mohou být použita také doménová jména.	Není-li uvedena žádná hodnota, budou odmítnuty všechy stroje.	Seznam IP adres, nebo doménových jmen. Položky odděleny čárkou.
nfs.rpc-auth-unix	Parametrem lze v případě potřeby vypnout ověřování typu AUTH_UNIX.	on	on/off
nfs.server-aux-gids	Tento parametr povolí nastavení GID a UID souboru na GlusterFS svazku přes NFS klienta. To však nemusí být bezpečné, pokud nejsou uživatelé synchronizováni napříč nody. V takovém případě by se mohlo stát, že by získal k souboru přístup neoprávněný uživatel.	off	on/off
nfs.trusted-write	Parametr, který může za určitých okolností zlepšit výkon při přístupu ke GlusterFS svazku přes NFS. Je-li povolen, tak server odesílá ke klientovi potvrzení, že požadavek už byl zpracovaný aby zbytečně neposílal požadavek na COMMIT	off	on/off
nfs.trusted-sync	Všechny NFS požadavky jsou vyřizovány v asynchronním režimu. To znamená, že uložení na GlusterFS svazek není nijak zaručené. Na druhou stranu je při asynchronním zpracování NFS protokolu výrazně zvýšen výkon NFS. Pozn. je-li aktivován tento parametr, je tím zároveň automaticky nasten parametr nfs.trusted-write na on	off	on/off
nfs.volume-access	Tímto parametrem lze změnit přístup ke GlusterFS svazku tak, aby byl přes NFS dostupný pouze pro čtení	read-write	read-write/read-only
Výkon NFS
performance.nfs.io-cache	Aktivuje kešování IO operací na straně NFS serveru	on	on/off
performance.nfs.io-threads	Aktivuje io-threads na straně NFS serveru	on	on/off
performance.nfs.quick-read	Aktivuje zrychlené načítání z NFS serveru	on	on/off
performance.nfs.read-ahead	Aktivuje predikci načítání souborů z GlusterFS svazku do paměti NFS serveru	on	on/off
performance.nfs.stat-prefetch	Aktivuje stat-prefetch/md-cache na straně NFS serveru	on	on/off
performance.nfs.write-behind	Aktivuje zpožděný zápis dat z paměti na GlusterFS svazek na straně NFS serveru	on	on/off
Doplňkové parametry GlusterFS
features.grace-timeout	Čas, po který je uchováván zámek procesu samoopravného mechanismu.		10 - 1800 seund
features.quota-timeout	Nastavení časové kvóty pro keš na straně klienta. Nastavením časového limitu lze určit po jak dlouhé době se mají data ve vyrovnávací paměti považovat za platné a uložit na svazek. Ve výchozím stavu se ukládají ihned.	0	0 - 3600 sekund
features.lock-heal	Povoluje spuštění samoopravného mechanismus na zámky, v situaci kdy dojde k rozpadu síťového připojení. Velice dobře tento parametr funguje v kombinaci s features.grace-timeout	on	on/off
features.read-only	Umožňuje přepnout celý GlusterFS svazek do režimu jen pro čtení (Týká se i připojení přes NFS)	off	on/off
features.worm	Při aktivaci tohoto parametru na svazek přijde na každou operaci open() odpověď s EROFS (Souborový systém jen pro čtení)		on/off
Geo-replikace GlusterFS
geo-replication.indexing	Je-li tento parametr aktivován, tak se provádí synchronizace změn z nodu Master na Slave automaticky.	off	on/off

Odkazy

http://www.gluster.org/community/documentation/ GlusterFS - dokumentace

https://raobharata.wordpress.com/2013/11/27/glusterfs-block-device-translator/ GlusterFS - BD translator

https://raobharata.wordpress.com/2012/10/29/qemu-glusterfs-native-integration/ GlusterFS a jeho integrace v Qemu

http://blog.gluster.org/2013/11/a-gluster-block-interface-performance-and-configuration/ GlusterFS - výkon a konfigurace

http://funwithlinux.net/2013/02/glusterfs-tips-and-tricks-centos/ GlusterFS na více rozhraních

http://www.ovirt.org/Change_network_interface_for_Gluster GlusterFS - změna síťového rozhraní

http://www.gluster.org/community/documentation/index.php/Gluster_3.2:_Setting_Volume_Options

http://www.gluster.org/community/documentation/index.php/Documenting_the_undocumented#Not_available_through_CLI

[1] Maximální počet bricků, který může vypadnout aniž by došlo k selhání svazku

[2] Objem dat vyhrazený pro zajištění redundance

[3] Objem dat jaký zabere jeden soubor na jednom bricku

[4] Celkově zabraná kapacita fyzických zařízení jedním souborem

[5] Počet síťových operací spojených s jedním souborem, připadající na jeden brick

[6] Celkový počet síťových operací, spojených s jedním souborem

[1]

[2]

[3]

[4]

[5]

[6]

GlusterFS