GlusterFS

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání

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ů.

gluster priority.svg

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

Upozornění 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?
Upozornění 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:

Poznámka 
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šší
Poznámka 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
Upozornění 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
Poznámka Z výpisu lze poznat, že servery byly do TSP začleněny ze stroje s IP adresou 192.168.0.1, přes svůj hostname

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.

glusterfs volume.svg

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
Poznámka 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

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.

glusterfs distributed.svg

Upozornění 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
Poznámka 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í:

  1. Nejprve je třeba zahájit přesun dat (parametr start)
  2. Teprve jsou-li data odsunuta (stav přesunu lze průběžně ověřovat s parametrem status)..
  3. 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
Upozornění 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

glusterfs striped.svg

Upozornění

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.


glusterfs replicated.svg 

root@nod1 ~# gluster volume create Svazek replica 2 transport tcp nod1:/blok1 nod2:/blok1
Poznámka 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ě.

glusterfs distributed replicated.svg

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:

glusterfs distributed replicated wrong.svg

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.


gluster dispersed.svg

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
  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
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í

Snapshotování svazků je novinkou, která se objevila od GlusterFS verze 3.6 Aby ho však bylo možné využívat, musí být 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)

Tzv. Thin Provisioning se u LVM objevil relativně nedávno, kolem r. 2009. Je to technologie, která umožňuje vytvářet a používat logické disky o větší kapacitě, než je dostupná kapacita fyzických blokových zařízení. Tato technologie využívá v principu toho, že jen výjimečně zabírají data na vyhrazeném logickém disku jeho plnou kapacitu. Je zde ale zvýšený počet IO operací, takže thin provisioning snižuje IO výkon LVM až o 30%![1].

U klasických "plnotučných" logických LVM oddílů, má každá z nich vyhrazen pro své extenty pevný rozsah, v jehož rámci si pak již souborový systém ukládá data po libosti. Většina datového prostoru ale zůstává nevyužita. Z hlediska ceny za jednotku datové kapacity je tento způsob hospodaření s datovým prostorem zbytečně rozmařilý, byť má svoje přednosti - označuje se jako tzv. fat či thick provisioning.

Thin Provisioning používá COW mechanismus, co ukládá extenty s daty bezprostředně těsně za sebou, tak jak se postupně plní daty. Ovšem souborový systém, který je nad takovým logickým LVM oddílem, o tom neví. Díky tomu lze dělat logické oddíly s virtuální kapacitou, která je větší než skutečně dostupný fyzický datový prostor, aniž by bylo nutné předem řešit otázku hardwarové kapacity.

Data těchto logických oddílů jsou umístěna v tzv. poolu, což je ve své podstatě klasický logický LVM oddíl s přiděleným rozsahem extentů. Který lze v případě potřeby operativně zvětšit.


Odkazy

  1. ↑ https://www.redhat.com/archives/dm-devel/2012-January/msg00048.html - Dokládají to testy, které počátkem r. 2012 dělal Jagan Reddy. Teoreticky je možné výkon zlepšit tím, že se do Thin VG skupiny přidají rychlá SSD zařízení, na které se umístí extenty vyhrazené pro metadata. Měly by být pokud možno dvě, a každá skupina metadat by měla být na jednom z nich, aby zůstala v případě selhání SSD disku zachována alespoň jedna kopie.
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í
Citováno z „https://wiki.control.fel.cvut.cz/mediawiki/index.php?title=GlusterFS&oldid=28883“