souborových systémů pro Cloud

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Testování distribuovaných souborových systémů pro Cloud BAKALÁŘSKÁ PRÁCE Adam Tomek Brno, jaro 2015

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Adam Tomek Vedoucí práce: RNDr. Lukáš Hejtmánek, Ph.D. ii

Poděkování Touto cestou bych rád poděkoval svému vedoucímu bakalářské práce RNDr. Lukáši Hejtmánkovi, Ph.D. za jeho rady a odborné vedení. Dále také děkuji za odborné konzultace ohledně dané oblasti Ing. Filipu Hubíkovi a Mgr. Borisi Parákovi. A na závěr bych poděkoval své rodině za projevenou podporu. iii

Shrnutí Cílem této práce je otestování třech distribuovaných souborových systémů Ceph, GlusterFS a XtreemFS. A na základě výsledků testování shrnout vhodnost jednotlivých systémů pro použití v cloudovém prostředí České národní gridové infrastruktury MetaCentru. Práce přibližuje vlastnosti daných systémů, jejich odlišnosti, postup instalace, výsledky naměřených testů v blokovém rozhraní (má-li souborový systém tuto možnost) a zhodnocení naměřených výsledků vzhledem k danému použití v cloudovém prostředí. iv

Klíčová slova testování, klastr, distribuovaný souborový systém, cloudové prostředí Ceph, GlusterFS, XtreemFS, MetaCentrum v

Obsah 1 Úvod................................. 1 2 Distribuované systémy...................... 2 2.1 Ceph.............................. 2 2.1.1 Struktura........................ 2 2.1.2 Historie vzniku a vývoje............... 2 2.1.3 Typy démonů..................... 2 2.1.4 Vlastnosti....................... 3 2.1.5 Reˇzimy......................... 3 2.2 GlusterFS............................ 4 2.2.1 Struktura........................ 4 2.2.2 Historie vzniku a vývoje............... 5 2.2.3 Typy démonů..................... 5 2.2.4 Vlastnosti....................... 5 2.2.5 Typy rozloˇzení dat.................. 6 2.3 XtreemFS............................ 10 2.3.1 Struktura........................ 10 2.3.2 Historie vzniku a vývoje............... 10 2.3.3 Typy démonů..................... 10 2.3.4 Vlastnosti....................... 11 3 Popis testování........................... 12 3.1 Struktura testovaných klastrů................ 12 3.2 IOzone............................. 13 3.3 Specifikace testovaných strojů................ 15 3.3.1 Nympha klastr.................... 16 3.3.2 Hador klastr...................... 16 3.4 Problémy............................ 16 3.5 Doba trvání........................... 17 4 Instalace............................... 18 4.1 Ceph.............................. 18 4.2 GlusterFS............................ 19 4.3 XtreemFS............................ 20 vi

5 Nastavení.............................. 21 5.1 Ceph.............................. 22 5.1.1 Nastavení monitorů................. 22 5.1.2 Nastavení OSD démona............... 23 5.1.3 Nastavení klientských uzlů............. 24 5.1.4 Nastavení blokových zařízení............ 24 5.2 GlusterFS............................ 25 5.2.1 Nastavení serverových uzlů............. 25 5.2.2 Nastavení klientských uzlů............. 26 5.2.3 Nastavení blokových zařízení............ 27 5.3 XtreemFS............................ 27 5.3.1 Nastavení metadata serveru (MRC)........ 28 5.3.2 Nastavení adresářové služby (DIR)......... 28 5.3.3 Nastavení úložného serveru (OSD)......... 29 5.3.4 Nastavení blokových zařízení............ 30 6 Výsledky testování......................... 32 6.1 Ceph.............................. 32 6.1.1 Nympha klastr.................... 32 6.1.2 Hador klastr...................... 34 6.2 GlusterFS............................ 35 6.2.1 Distribuované replikované rozloˇzení dat...... 36 6.2.2 Distribuované prokládané replikované rozloˇzení dat........................... 38 6.3 XtreemFS............................ 39 6.4 Zhodnocení.......................... 41 7 Závěr................................. 42 vii

1. ÚVOD 1 Úvod V současné době se velmi dostává do popředí poskytování služeb, platforem nebo i celých infrastruktur pomocí cloudového prostředí. Již dříve používané gridové infrastruktury neposkytují dostatek flexibility a postupně se přechází spíše na cloudovou infrastrukturu. Podobně tomu je i u České národní gridové infrastruktury MetaCentra, které teprve před několika lety začalo s vývojem cloudové infrastruktury a nyní je již více jak 200 fyzických strojů po celé České republice zapojených do tohoto projektu. Avšak neustálé rozšiřování celé cloudové infrastruktury si vyžaduje technické řešení pro ukládání obrazů virtuálních strojů, které by mělo být dostatečně flexibilní a poskytovat dostatek prostoru pro veškeré obrazy virtuálních strojů. Technické řešení spočívá ve formě distribuovaného souborového systému. Cílem této bakalářské práce je otestování třech distribuovaných systémů Ceph, GlusterFS a XtreemFS pro cloudové prostředí, přiblížení jejich vlastností a struktury, popis instalace a nastavení pro testování a v závěru shrnutí výsledků s vyhodnocením vhodnosti daných systémů s přihlédnutím na všechny okolnosti. Práce je rozdělená na sedm kapitol, včetně úvodu a závěru. Úvod poskytuje základní přehled o této práci a uvádí čtenáře do dané problematiky. Následuje druhá kapitola, která představuje testované systémy. Třetí kapitola popisuje detailněji testování, použitý software a specifikace testovaných strojů. Následující čtvrtá kapitola umožňí pohled na instalaci samotných systémů. V páté kapitole již nainstalovaným strojům je možné nastavit dané vlastnosti potřebné k testování. Šestá kapitola uvádí grafické i tabulkové představení naměřených dat a zhodnocení vhodnosti testovaných systémů. V závěrečné kapitole následuje krátký souhrn celé práce a případné návrhy možností dalšího testování před možným nasazením do produkční verze cloudového prostředí. 1

2. DISTRIBUOVANÉ SYSTÉMY 2 Distribuované systémy 2.1 Ceph 2.1.1 Struktura Distribuovaný souborový systém Ceph se skládá z klientských a serverových uzlů. Klientské uzly pouze vyuˇzívají jednotlivých sluˇzeb systému Ceph. Serverové uzly poskytují ve výchozím stavu objektový režim, dále také mohou poskytovat blokový režim nebo souborový režim. Přičemž blokový i souborový režim využívají k ukládání svých dat jako spodní vrstvu objektový režim. Data i metadata v rámci všech režimů jsou uskladněna v seskupeních zvaných anglicky pools. Jednotlivá seskupení pak dále udržují dané objekty. 2.1.2 Historie vzniku a vývoje Ceph 1 je volně dostupný distribuovaný souborový systém, který původně vytvořil Sage A. Weil jako svoji disertační práci na Kalifornské univerzitě v Santa Cruz [3]. Po ukončení studia na podzim roku 2007 Weil dále pokračoval ve vývoji Cephu a následně zahrnul do tvorby i další vývojáře. V roce 2012 Weil zakládá společnost Inktank Storage, která se specializuje výhradně na Ceph [2]. Následně třetího července roku 2012 vydává společnost Inktank Storage první plnohodnotnou verzi s názvem Argonaut. Další klíčové verze jsou vydávány zhruba každého půlroku a nesou následující názvy: Bobtail, Cuttlefish, Dumpling, Emperor, Firefly, Giant a Hammer. Za zmínku ještě stojí, že v dubnu roku 2014 společnost Red Hat koupila Inktank Storage [1]. 2.1.3 Typy démonů Ceph využívá tři různé druhy démonů [10]. Démonem se rozumí stále běžící program v pozadí, který vyčkává v nečinnosti na nějakou činnost, kterou posléze obslouží. Jeden serverový uzel může obsahovat maximálně jeden Ceph Monitor a jeden Ceph Metadata Server. Množ- 1 Ceph, <http://ceph.com> 2

2. DISTRIBUOVANÉ SYSTÉMY ství Ceph OSD démonů na jeden serverový uzel není nijak dále omezeno. Ceph Monitor sleduje a udrˇzuje informace o všech uzlech v klastru (aktivních i neaktivních). Dále také koordinuje veškeré rozloˇzení dat v klastru a přesuny dat mezi uzly. Ceph OSD Démon shromaˇzd uje data, zpracovává jejich replikace a poskytuje některé monitorovací informace pro Ceph Monitor. Ceph Metadata Server uchovává metadata pro souborový systém Ceph (CephFS). Z toho vyplývá, že pro chod objektového a blokového režimu není potřeba. 2.1.4 Vlastnosti Mezi hlavní vlastnosti patří především: CRUSH algoritmus zajišt uje, ˇze data jsou rovnoměrně distribuována přes celý klastr a všechny uzly klastru mají data rychle dostupná. Moˇznost oddělení správy metadat a dat díky typům uzlů, které Ceph poskytuje, lze jednoduše oddělit správu metadat a dat. Jedná se o výborné řešení, jak předejít větším škodám při selhání hardwaru. Lze toho dosáhnout například nasazením Ceph OSD démonů na jiné serverové uzly než se nachází jakýkoliv Ceph Metadata Server. Více reˇzimů pouˇzití nabízí tři odlišné moˇznosti pouˇzití (objektový, blokový a CephFS reˇzim). Vysoká škálovatelnost možnosti škálování sahají až do řádů tisíců připojených uzlů v rámci jednoho distribuovaného systému. 2.1.5 Reˇzimy Objektový reˇzim poskytuje klientským aplikacím přímý přístup pomocí RADOS 2 (z angl. Reliable Autonomic Distributed Object Sto- 2 RADOS, <http://ceph.com/papers/weil-rados-pdsw07.pdf> 3

2. DISTRIBUOVANÉ SYSTÉMY re). Dále také poskytuje základ pro některé z dalších funkcí, včetně blokového režimu a CephFS [11]. Blokový reˇzim poskytuje moˇznost vytvořit virtuální blokové zařízení, které se nazývá RBD 3 (z angl. RADOS Block Device). RBD poté komunikuje s jednotlivými OSD pomocí modulů jádra nebo librbd knihovny [12]. Obr. 1: Schéma vrstev blokového reˇzimu [14]. CephFS (z angl. Ceph Filesystem) je POSIX kompatibilní souborový systém, který je postaven nad objektovým režimem. Zatím je stále ve vývoji a není určen pro produkční nasazení. Použití CephFS vyžaduje nejméně jeden Ceph Metadata Server [13]. 2.2 GlusterFS 2.2.1 Struktura Distribuovaný souborový systém GlusterFS je složen z serverových a klientských uzlů. Klientské uzly pouze přistupují do datových prostorů přes přípojný bod. Serverové uzly spravují dané datové prostory (anglicky volumes), které se skládají z menších částí (anglicky bricks). Na jednom serverovém uzlu se může nacházet i několik těchto menších částí. GlusterFS poskytuje tři základní možnosti rozložení ukládaných dat do datových prostorů. Jedná se o distribuované, prokládané nebo replikované rozložení dat a případně i různé kombinace těchto tří rozložení. GlusterFS dále umožňuje i jedno typově odlišné rozložení dat s názvem georeplikace. 3 RBD, <http://ceph.com/docs/master/rbd/rbd/> 4

2. DISTRIBUOVANÉ SYSTÉMY 2.2.2 Historie vzniku a vývoje GlusterFS 4 lze zjednodušeně charakterizovat jako volně dostupný distribuovaný souborový systém. Který se začal vyvíjet společností Gluster v červenci roku 2005. První stabilní verze 1.2.3 vyšla v únoru roku 2007 [7]. Od verze 1.3, která byla velice inovativní, vychází stále další nové verze. V srpnu roku 2011 společnost Red Hat koupila firmu Gluster, což ještě více podpořilo vývoj tohoto systému [8]. 2.2.3 Typy démonů GlusterFS rozděluje role pouze mezi tyto dva démony [16, s. 60]: GlusterFS Server (démon glusterfsd) uchovává data v datových prostorech (z angl. volumes), které pak může zpřístupnit prostřednictvím počítačové sítě na základě přístupových práv k jednotlivým datovým prostorům. GlusterFS Client (démon glusterfs) přistupuje k datovým prostorům přes přípojný bod, vyuˇzívá k tomu vlastní protokol postavený nad protokoly pro komunikaci v počítačové síti TCP/IP 5, SDP 6 nebo InfiniBand 7. 2.2.4 Vlastnosti GlusterFS se vyznačuje především těmito vlastnostmi [19]: Typy rozloˇzení dat GlusterFS poskytuje georeplikaci a tři hlavní typy rozloˇzení dat (distribuované, replikované a prokládané rozložení dat) včetně jejich kombinací. Jednoduché nastavení oproti ostatním systémům poskytuje velice jednoduché nastavení celého systému. Názvy příkazů jsou intuitivní a není potřeba dlouhé studování dokumentace. Vysoká škálovatelnost umožňuje lehce přidávat i odebírat serverové uzly. Možnosti škálování jsou až v rámci petabajtů (1 PB = 10 15 B), 4 GlusterFS, <http://www.gluster.org> 5 TCP/IP, <http://www.earchiv.cz/a92/a231c110.php3> 6 SDP, <http://www.cs.vsb.cz/grygarek/tps/projekty/0607z/sdp.pdf> 7 IB, <http://www.mellanox.com/pdf/whitepapers/ib Intro WP 190.pdf> 5

2. DISTRIBUOVANÉ SYSTÉMY teoreticky aˇz v rámci brontobajtů (1 BB = 10 27 B). Počet klientských uzlů může narůstat až do řádů tisíců. 2.2.5 Typy rozloˇzení dat GlusterFS umožňuje vytvářet datové prostory rozprostřené přes různé fyzické stroje. Datové prostory se skládají z menších částí (angl. bricks). Navíc, jeden fyzický stroj může obsahovat i více těchto menších částí. Zde je seznam možných typů rozložení dat [15]: Distribuované rozloˇzení data jsou distribuována na úrovni souborů, bez redundance. Jedná se o obdobu RAID 0 8. Při selhání přicházíme o data. Tato varianta se používá výhradně pro rychlé dosažení velkého úložného prostoru. Obr. 2: Distribuované rozloˇzení dat. [17] 8 RAID 0, <http://www.raid-calculator.com/raid-types-reference.aspx> 6

2. DISTRIBUOVANÉ SYSTÉMY Replikované rozloˇzení data jsou opět distribuována na úrovni souborů, ale již s redundancí. To znamená, že do jisté míry selhání jsou data stále dostupná. Replikované rozložení se nejčastěji používá pro vysokou dostupnost dat. Obr. 3: Replikované rozložení dat. [17] Prokládané rozloˇzení jednotlivé soubory mohou být distribuovány po částech, neuplatňuje se redundance. Tato varianta je vhodná pro velmi velké soubory. Obr. 4: Prokládané rozložení dat. [17] 7

2. DISTRIBUOVANÉ SYSTÉMY Distribuované prokládané rozloˇzení jedná se o kombinaci, která se zaměřuje na škálovatelnost a velmi velké soubory. Obr. 5: Distribuované prokládané rozloˇzení dat. [17] Distribuované replikované rozloˇzení tato kombinace se zaměřuje na škálovatelnost a vysokou dostupnost dat. Jedná se o obdobu RAID 10 9. Obr. 6: Distribuované replikované rozloˇzení dat. [17] 9 RAID 10, <http://www.raid-calculator.com/raid-types-reference.aspx> 8

2. DISTRIBUOVANÉ SYSTÉMY Prokládané replikované rozloˇzení toto rozloˇzení díky kombinaci prokládání a replikování dat umožňuje s vysokou dostupností pracovat s velmi velkými soubory. Obr. 7: Prokládané replikované rozloˇzení dat. [17] Distribuované prokládané replikované rozloˇzení tato kombinace rozložení poskytuje maximální škálovatelnost s vysokou dostupnostní pro velmi velké soubory. Obr. 8: Distribuované prokládané replikované rozložení dat. [17] 9

2. DISTRIBUOVANÉ SYSTÉMY Georeplikace umoˇzňuje asynchronně, inkrementálně a nepřerušovaně replikovat celý úložný systém mezi rozdílnými datovými centry (LAN) nebo geografickými lokacemi (WAN). Využívá se k tomu tzv. model master/slave 10. Georeplikace se používá například pro zálohování veškerých dat. 2.3 XtreemFS 2.3.1 Struktura Distribuovaný souborový systém XtreemFS se skládá z klientských a serverových uzlů. Klientské uzly pouze využívají přístupu do datových prostorů přes přípojný bod. Serverové uzly poskytují správu datových prostorů. Oproti ostatním distribuovaným souborovým systémům může být replikace nastavována pro jednotlivé soubory, nejen pro celé datové prostory. 2.3.2 Historie vzniku a vývoje XtreemFS 11 se začal vyvíjet v roce 2006 [6]. První veřejná verze byla vydána v srpnu roku 2008, avšak verze 1.0 s názvem Jelly Donuts se objevila až v srpnu roku 2009 [5]. Od té doby jsou pravidelně vydávány nové verze. Za zmínku stojí verze 1.4, která prošla rozsáhlým testováním a je považována za velmi stabilní. V roce 2013 původní tým, který se podílel na vývoji XtreemFS, zakládá společnost s názvem Quobyte, která staví především na poznatcích z XtreemFS. A vytváří tak podobný produkt pro produkční použití. Narozdíl od XtreemFS se jedná o placenou variantu [4]. 2.3.3 Typy démonů Rozdělení rolí je výhodné hlavně z hlediska lepší stability systému, proto XtreemFS používá tři různé druhy démonů [9]. Jeden serverový uzel může obsahovat maximálně od každého typu jednoho démona. Metadata server (MRC) uchovává metadata datových prostorů. 10 Master/slave, <http://goo.gl/hdfg5s> 11 XtreemFS, <http://www.gluster.orghttp://www.gluster.org> 10

2. DISTRIBUOVANÉ SYSTÉMY Adresářová sluˇzba (DIR) pomocí adresářové sluˇzby metadata server, úložný server a klient hledají ostatní servery. Dále adresářová služba obsluhuje UUID (univerzální unikátní identifikátor, z angl. universally unique identifier) mapování a shromažd uje informace o datových prostorech. Úloˇzný server (OSD) jedná se o klasický server, kde jsou uloˇzená data a jejich replikace. 2.3.4 Vlastnosti Hlavními vlastnostmi XtreemFS jsou [18]: Asynchronní zálohování MRC umoˇzňuje vytvářet konzistentní zálohu metadat bez přerušení vstupních nebo výstupních operací. Asynchronní zálohování souborového systému jelikož XtreemFS podporuje uchovávání jednotlivých verzí souborů a asynchronní zálohování MRC, dohromady tyto dvě techniky umoˇzňují vytvářet zálohu celého souborového systému. Prokládání dat XtreemFS implementuje prokládání dat přes několik serverových uzlů pro lepší využití šířky pásma kapacity, vstupních a výstupných operací. Zaručuje to rychlejší čtení i zápis dat, protože jsou operace prováděny paralelně na několika serverových uzlech najednou. Replikace jednotlivých souborů v rámci jednoho datového prostoru lze nastavit odlišný počet replikací jednotlivým souborům. Moˇznost částečného replikování repliky jsou doplněny na kompletní až v momentu, kdy je někdo vyžaduje. Vysoká škálovatelnost moˇznost snadného a rychlého přidávání či ubírání nových serverových uzlů. Zabezpečení díky šiforvání pomocí SSL 12 a X.509 13 certifikátů nemusí klienti používat virtuální privátní sítě. 12 SSL, <http://www.ssl-thawte.cz/ssl/co-je-to-ssl/> 13 X.509, <http://ics.muni.cz/bulletin/articles/181.html> 11

3. POPIS TESTOVÁNÍ 3 Popis testování 3.1 Struktura testovaných klastrů Testování bylo určeno pro shrnutí vhodnosti distribuovaných souborových systémů Ceph, GlusterFS a XtreemFS pro použití v cloudovém prostředí České národní gridové infrastruktury MetaCentru. Při testování bylo potřeba zachovat prostředí takové, aby svojí strukturou odpovídalo cloudovému prostředí v MetaCentru. Avšak na druhou stranu, aby také bylo přijatelné pro požadavky na hardware. Návrh struktury byl do velké míry ovlivněn použitým hardwarem. Na dlouhodobé testování byl primárně použit klastr 14 strojů s názvem Nympha. Z nichž 4 stroje sloužili jako serverová část a zbylých 10 strojů sloužilo jako část pro klienty. Díky podobné struktuře všech testovaných systémů mohlo být toto rozložení použito po celou dobu testování. Pouze v opakovaném testování systému Ceph byl použit jiný klastr 20 výkonnějších strojů s názvem Hador. Z nichž opět 4 stroje sloužili jako serverová část a 16 strojů jako část klientská. Hlavním bodem zájmu byla především propustnost celého distribuovaného systému jako celku. Daný systém by měl především poskytovat podporu pro blokové zařízení, se kterým se v cloudovém prostředí nejčastěji pracuje, reprezentuje tak obraz virtuálního stroje. Pokud distribuovaný systém neposkytuje nativní podporu pro blokové zařízení, vytvoří se v datovém prostoru soubory pevné velikosti, které se pak dále naformátují a připojí se k danému stroji jako přípojný bod. Model testování představuje v cloudovém prostředí uložiště obrazů a dat (z angl. Image Storage) u cloudu s architekturou IaaS 14 (z angl. Infrastructure as a Service). V našem případě architektura IaaS poskytuje pomocí middleware OpenNebula 15 virtualizaci hardwaru. Daný distribuovaný souborový systém by v tomto případě měl za úkol distribuci obrazů napříč cloudovým prostředím. Tudíž je především důležité testování rychlosti zápisu dat. Velkou roli pak zde hraje to, jak rychle daný systém dokáže zapiso- 14 IaaS, <http://goo.gl/n1kyvl> 15 OpenNebula, <http://opennebula.org> 12

3. POPIS TESTOVÁNÍ vat či přepisovat data od několika klientů najednou. A to i v případě, že od jednoho klienta mohou být příjmána data do několika odlišných blokových zařízení najednou. Zvolená velikost testovaných souborů (1 4 GB) reprezentuje velikost obrazu virtuálního stroje, který je distribuován napříč cloudovým prostředím pomocí daného distribuovaného systému, proto byly tyto hodnoty zvoleny i při testování. Každý klientský uzel měl připojených deset blokových zařízení do daného distrubuovaného systému. Při deseti klientských uzlech bylo možné zpracovávat až sto blokových zařízení a při šestnácti klientských uzlech až sto šedesát blokových zařízení najednou. Dále budu nazývat zpracovávání dat jednoho blokového zařízení na jednom uzlu jako jeden proces. Blokové zařízení vždy mělo kapacitu pět gigabajtů, avšak při testování se používali menší velikosti souborů. Následující tabulka vyjadřuje velikosti testovacích souborů v závislosti na počtu procesů na daném stroji: počet procesů velikost testovacího souboru 1 proces 4 096 MB 2 procesy 2 048 MB 3 procesy 1 365 MB 4 procesy a více 1 024 MB Tab. 1: Velikosti testovacích souborů. 3.2 IOzone Testování probíhalo za pomoci programu IOzone 16, který je vhodný především pro měření výkonu pevného disku, ale v distribuovaném reˇzimu lze pouˇzít právě pro měření propustnosti celého distribuovaného souborového systému. Program IOzone v distribuovaném režimu se spouští pouze na jednom klientském stroji. Daný stroj musí mít přístup na všechny ostatní klientské stroje pomocí ssh bez hesla. A samozřejmě na všech ostatních klientských strojích musí být také program IOzone nainstalován, nejlépe ve stejné verzi. IOzone má ve své nabídce celou škálu přepínačů, 16 IOzone, <http://www.iozone.org> 13

3. POPIS TESTOVÁNÍ které umoˇzňují nastavovat moˇznosti testování podle různých případů. V mém případě byla použita tato syntaxe (mění se pouze velikost testovacího souboru, počet procesů a název souboru do kterého se ukládá výstup): $ iozone -Mce -s 4g -r 256k -i 0 -+m nodes01.list -t 1 > test_01n-01p.txt Vysvětlení přepínačů je dostupné v anglickém jazyce pomocí příkazu man iozone, pokud je IOzone v daném systému nainstalován. Přepínače pouˇzíté při testování jsou vysvětleny níˇze: -c zahrne funkci close() do časových výpočtů. -e zahrne funkce typu flush, jedná se o funkce, které umožňují vyprázdnění vyrovnávací paměti (např. fsync, fflush). -i # specifikuje testy, které se mají vykonat. Vˇzdy je nutné zadat test číslo 0. Ostatní testy jsou volitelné. Formát pro zadání více testů najednou můˇze být například: -i 0 -i 2 -i 9. Zde je jejich kompletní seznam: 0 = zápis / přepis 1 = čtení / opětovné čtení 2 = náhodné čtení / náhodný zápis 3 = čtení pozpátku 4 = zápis a přepis pouze vybraného místa v souboru 5 = krokované čtení 6 = zápis funkcí fwrite() / přepis funkcí fwrite() 7 = čtení funkcí fread() / opětovné čtení funkcí fread() 8 = náhodný střídavý zápis a čtení 9 = zápis funkcí pwrite() / přepis funkcí pwrite() 10 = čtení funkcí pread() / opětovné čtení funkcí pread() 11 = zápis funkcí pwritev() / přepis funkcí pwritev() 12 = čtení funkcí preadv() / opětovné čtení funkcí preadv()) -+m # z tohoto souboru se získávají informace o konfiguraci klienta pro klastrové testování. Soubor vˇzdy obsahuje jeden řádek pro jednoho klienta, případně pro jeden proces. Kaˇzdý řádek má tři údaje oddělené mezerou. První údaj je jméno klienta. Druhý 14

3. POPIS TESTOVÁNÍ údaj znázorňuje cestu do pracovního adresáře, kde bude IOzone testovat. A třetí údaj je cesta, kde se nachází na klientovi program IOzone. Zde je ukázka, jak může tento soubor vypadat: nympha4ib /mnt/gbd/01 /usr/bin/iozone nympha5ib /mnt/gbd/02 /usr/bin/iozone nympha6ib /mnt/gbd/03 /usr/bin/iozone -M IOzone bude volat funkci uname() a výstup vloˇzí jako řetězec do výstupního souboru. -r # pouˇzívá se k určení velikosti zapisovaných bloků do testovacího souboru v kilobajtech. Velikost lze také určit jako -r #k (pro velikost v kilobajtech), -r #m (pro velikost v megabajtech) nebo -r #g (pro velikost v gigabajtech). -s # používá se k určení velikosti testovacího souboru v kilobajtech. Velikost lze také specifikovat jako -s #k (pro velikost v kilobajtech), -s #m (pro velikost v megabajtech) nebo -s #g (pro velikost v gigabajtech). -t # určuje kolik procesů najednou při testování poběˇzí, číslo značí počet řádků v souboru u přepínače -+m #. 3.3 Specifikace testovaných strojů Testování probíhalo na již dvou zmíněných klastrech. Všechny stroje byly zapůjčeny od České národní infrastruktury Metacentra, aktivity sdružení CESNET, z. s. p. o. Na klastru Nympha probíhalo testování v rámci několika měsíců, klastr Hador byl zapůjčen pouze na dobu dvou týdnů. Následující tabulky poskytují základní přehled použitého hardwaru a softwaru: 15

3. POPIS TESTOVÁNÍ 3.3.1 Nympha klastr počet strojů 14 umístění Plzeň, Česká republika procesor 2x quad-core Intel Xeon E5472 (3 GHz, 12 MB cache) operační pamět RAM 16 GB pevný disk 1x 300 GB (systém i data) sít 1x InfiniBand (40 Gb/s), 1x Ethernet (1 Gb/s) operační systém Debian 7.6 Wheezy verze jádra operačního systému 3.14.0 pouˇzitá operační pamět RAM 2 GB pouˇzitá sít 1x Infiniband (40 Gb/s) Tab. 2: Specifikace Nympha klastru. 3.3.2 Hador klastr počet strojů 20 umístění Brno, Česká republika procesor 2x octa-core Intel Xeon E5-2630 v3 (2,4 GHz, 20 MB cache) operační pamět RAM 128 GB pevný disk 2x 1 TB (systém), 12x 4 TB (data) sít 1x InfiniBand (40 Gb/s), 2x Ethernet (1 Gb/s) operační systém Debian 7.7 Wheezy verze jádra operačního systému 3.14.0 pouˇzitá operační pamět RAM 2 GB pouˇzitá sít 1x Infiniband (40 Gb/s) Tab. 3: Specifikace Hador klastru. 3.4 Problémy Bohuˇzel i při tomto testování se objevily problémy. Největším problémem bylo chybné měření celého systému GlusterFS. Při prvním pokusu měření systému GlusterFS se nejspíše daný systém špatně nainstaloval. Přesný problém se ovšem nepodařilo odhalit. Avšak výsledky byly zkreslené a nevycházely vůbec dle očekávání. Nekorektnost výsledků byla především odhalena díky vyšším naměřeným hodnotám pro distribuované prokládané replikované rozložení dat než pro pouze distribuované replikované rozložení dat. Proto na všechny stroje byl znova nainstalován neupravený operační systém Debian 7.6 s označením Wheezy. A dle stejného postupu 16

3. POPIS TESTOVÁNÍ jako při první instalaci, byl nainstalován a nastaven systém GlusterFS. Po opětovném otestování, výsledky již vycházely dle očekávání. Druhým problémem při testování bylo selhání hardwaru na dvou klientských uzlech. Při neustálém zatížení většího počtu strojů, bohužel dochází i k selhání hardwaru. Přesněji na jednom klientském uzlu byl detekován vadný pevný disk a na druhém klientském uzlu po plánovaném restartu byla detekována vadná operační pamět. Oba klientské uzly byly opraveny a nasazeny zpět k testování. 3.5 Doba trvání Jelikoˇz se při testování jednalo o velké přenosy dat, samotné testování zabralo spoustu času. V následující tabulce naleznete přibližné časové údaje doby trvání samotného testování, které zahrnovalo i opakované přeměření některých hodnot. Avšak v tabulce není zahrnuto prvotní měření GlusterFS s nekorektními výsledky. zápis přepis Ceph (Nympha klastr) 24 h 22 h Ceph (Hador klastr) 8 h 7 h GlusterFS (dist. repl. rozloˇzení dat) 9 h 8 h GlusterFS (dist. pro. repl. rozloˇzení dat) 12 h 10 h XtreemFS 72 h 76 h celkem 125 h 123 h Tab. 4: Přibližná doba trvání testování. 17

4. INSTALACE 4 Instalace Tato kapitola poskytuje instalační postup jednotlivých systémů na serverové nebo klientské uzly, přičemž všechny příkazy jsou napsány tak, aby je vykonával pouze uživatel root. Pokud se budou tyto příkazy vykonávat pod jiným uživatelem, je potřeba se při instalaci za uživatele root vydávat, například pomocí příkazu sudo 17. 4.1 Ceph Oproti ostatním systémům, tento postup se provede pouze na počátečním serverovém uzlu. Instalace na ostatní serverové či klientské uzly probíhá pomocí příkazu ceph-deploy z počátečního serverového uzlu a prolíná se tak s postupným nastavováním systému. Z tohoto důvodu jsem instalaci na ostatní serverové či klientské uzly zařadil až do kapitoly nastavení. Následující instalační postup pro počáteční serverový uzel je rozdělen do třech po sobě jdoucích kroků [20]: 1) V tomto postupu je popisována instalace systému Ceph verze 0.80 Firefly na operační systém Debian 7 s označením Wheezy, přičemˇz postup při instalaci jiných verzí na jiné operační systémy je velmi podobný. Nejprve je potřeba přidat Ceph zdroj do našeho systému následujícím příkazem: $ echo deb http://ceph.com/debian-firefly/ wheezy main tee /etc/apt/sources.list.d/ceph.list 2) Pro větší bezpečnost je zdroj zabezpečen klíčem, bez něhož není možné tento zdroj používat. Nahrání klíče do systému provedeme příkazem: $ wget -q -O- https://ceph.com/git/?p=ceph.git;a=blob_plain; f=keys/release.asc apt-key add - 3) Nyní je nutné načíst nové balíky ze zdrojů do našeho systému. $ apt-get update 4) Závěrem nainstalujeme potřebný balík ceph-deploy. $ apt-get install ceph-deploy 17 sudo, <http://www.linuxsoft.cz/article.php?id article=493> 18

4. INSTALACE 4.2 GlusterFS Instalace GlusterFS je rozdělena do třech po sobě jdoucích kroků: 1) V následujícím postupu je vybraný jako operační systém Debian 7 s označením Wheezy. Avšak postup pro ostatní podporované systémy je velice podobný. Jelikož ve zdrojích pro Debian je dostupná verze GlusterFS nejvýše ve verzi 3.2, je lepším způsobem stáhnout si přímo aktuální deb balíky. Současnou nejnovější verzí ze dne 28. 4. 2015 je verze číslo 3.6.3-1. Následující tři příkazy provedou stažení deb balíků této verze: $ wget http://download.gluster.org/pub/gluster/glusterfs/ LATEST/Debian/wheezy/apt/pool/main/g/glusterfs/glusterfscommon_3.6.3-1_amd64.deb $ wget http://download.gluster.org/pub/gluster/glusterfs/ LATEST/Debian/wheezy/apt/pool/main/g/glusterfs/glusterfsclient_3.6.3-1_amd64.deb $ wget http://download.gluster.org/pub/gluster/glusterfs/ LATEST/Debian/wheezy/apt/pool/main/g/glusterfs/glusterfsserver_3.6.3-1_amd64.deb 2) Další tři příkazy nám nainstalují potřebné balíky. Pokud instalujeme balíky na klientský uzel, vynecháme poslední řádek. dpkg -i glusterfs-common_3.6.3-1_amd64.deb dpkg -i glusterfs-client_3.6.3-1_amd64.deb dpkg -i glusterfs-server_3.6.3-1_amd64.deb 3) V posledním kroku je uˇz jen potřeba odstranit přebytečné deb balíky, které jsme v prvním kroku stahovali. rm glusterfs-common_3.6.3-1_amd64.deb rm glusterfs-client_3.6.3-1_amd64.deb rm glusterfs-server_3.6.3-1_amd64.deb 19

4. INSTALACE 4.3 XtreemFS Instalace XtreemFS je rozdělena do pěti po sobě jdoucích kroků [21]: 1) V následujícím postupu se bude jednat opět o operační systém Debian 7 s označním Wheezy. Avšak podobný postup je i pro ostatní podporované systémy. V první řadě je potřeba přidat XtreemFS zdroj do našeho systému. Přidání zdroje do systému provedeme tímto příkazem: $ echo "deb http://download.opensuse.org/repositories/home:/ xtreemfs/debian_7.0/./"\ > /etc/apt/sources.list.d/xtfs.list 2) Pro větší bezpečnost je zdroj zabezpečen klíčem, bez něhož není možné tento zdroj používat. Dalším příkazem klíč stáhneme a nahrajeme do systému. $ wget -q http://download.opensuse.org/repositories/home:/ xtreemfs/debian_7.0/release.key -O - apt-key add - 3) Nyní je potřeba načíst nové balíky ze zdrojů do našeho systému. $ apt-get update 4) V poslední fázi nainstalujeme potřebné balíky. Pokud požadujeme instalaci balíků na klientský uzel, krok číslo čtyři můžeme přeskočit. Pro instalaci balíků na serverový uzel zůstáváme u bodu číslo čtyři, který je pro nás bodem posledním. $ apt-get install xtreemfs-server 5) Tímto příkazem nainstalujeme potřebné balíky na klientský uzel včetně nástrojů pro správu. $ apt-get install xtreemfs-client xtreemfs-tools 20

5. NASTAVENÍ 5 Nastavení Kapitola nastavení zahrnuje část příprav, kdy je daný systém již nainstalovaný na všechny uzly (toto neplatí pro systém Ceph, který je nainstalovaný pouze na počáteční serverový uzel). Dále je potřeba daný systém správně nakonfigurovat, aby byl připraven na testování. Před začátkem nastavování musí být splněny tyto podmínky: 1) V první řadě je důleˇzité správně nastavit nasměrování domén na IP adresy pomocí souboru /etc/hosts. Pokud pouˇzíváme propojení přes InfiniBand, doporučuji k jeho adresám přiřadit jiné názvy domén než u propojení přes Ethernet. Upravit soubor je potřeba na všech serverových uzlech a prvním klientském uzlu. Měl by obsahovat údaje o všech uzlech, které spolupracují s daným distribuovaným systémem. Zde je příklad, jak by mohl soubor /etc/hosts vypadat: 127.0.0.1 localhost 147.240.12.1 server1 147.240.12.2 server2 10.50.100.1 server1ib 10.50.100.2 server2ib 149.240.15.1 klient1 10.60.100.1 klient1ib 2) Z prvního serverového uzlu musí být dostupné všechny uzly přes ssh spojení bez hesla. V mém případě se jedná o čtyři uzly serverové a deset (šestnáct) uzlů klientských. Jelikož některé systémy používají ssh spojení v instalačních skriptech i na ten samý uzel na kterém se zrovna nachází, je nutné aby toto ssh spojení fungovalo také. Pro vygenerování nového klíče a jeho distribuci na ostatní serverové uzly doporučuji použití následujících příkazů: $ ssh-keygen $ ssh-copy-id uživatel@uzel 21

5. NASTAVENÍ 3) Z prvního klientského uzlu musí být dostupné všechny klientské uzly přes ssh spojení bez hesla. V mém případě se jedná o deset (šestnáct) uzlů. Takovéto nastavení je nutné kvůli možnosti spuštění programu IOzone v distribuovaném režimu. Opět doporučuji použití příkazů ssh-keygen a ssh-copy-id z bodu číslo dva. 5.1 Ceph U systému Ceph se jedná o částečné doinstalování systému s nastavením. Narozdíl od počátečního serverového uzlu se ostatní uzly instalují jiným způsobem. Z tohoto důvodu jsem instalaci ostatních serverových uzlů zařadil až do této kapitoly. Postup nastavení systému Ceph částečně vychází z Ceph dokumentace [22]. 5.1.1 Nastavení monitorů 1) Nejdříve vytvoříme adresář na prvním serverovém uzlu. Je důleˇzité vykonávat všechny další příkazy z tohoto adresáře, protoˇze na toto místo se budou ukládat všechny logovací údaje při vytváření systému Ceph, případně i dočasné soubory. Adresáři můžeme dát jakékoliv jméno, já jsem v tomto případě zvolil název cluster. $ mkdir /cluster $ cd /cluster 2) Nyní deklarujeme iniciální monitory. $ ceph-deploy new nympha2ib nympha3ib nympha4ib nympha5ib 3) Ve složce kde se právě nacházíme se nám automaticky vytvořilo několik souborů, nás zajímá především soubor ceph.conf, do kterého nyní doplníme naši konfiguraci. Porušeným klastrem je v následujícím kódu označen klastr, kde byl zaznamenán výpadek některého z uzlů a replikace může být dočasně snížena až na hodnotu min size. Pod řádek [global] doplníme následující informace: # iniciální počet replikací osd_pool_default_size = 2 22

5. NASTAVENÍ # iniciální minimální počet replikací v porušeném klastru osd_pool_default_min_size = 1 # iniciální počet umíst ujících skupin osd_pool_default_pg_num = 256 # iniciální počet umíst ujících skupin pro umístění dat osd_pool_default_pgp_num = 256 4) Dalším krokem je instalace systému Ceph na ostatní serverové uzly. $ ceph-deploy install create nympha2ib nympha3ib nympha4ib nympha5ib 5) Krokem číslo pět zakončíme nastavení monitorů. Následujícím příkazem vytvoříme monitory, které jsme v bodě číslo dva deklarovali. Součástí toho je i shromáždění klíčů na jednotlivých monitorech, tyto klíče budou používány všemi uzly pro autentizaci všech služeb systému Ceph. $ ceph-deploy mon create-initial 5.1.2 Nastavení OSD démona 1) K vytvoření OSD potřebujeme nejdříve na daných serverových uzlech vytvořit přísloušnou složku, ve které bude OSD démon uchovávat data. Nejlepším způsobem je připojení celého pevného disku jako přípojný bod. V mém případě jsem pro klastr Nympha použil pouze část disku (jeden oddíl), který byl připojený na umístění /data. A pro klastr Hador jsem použil osm disků na každý uzel, které byly připojeny na úmístění /data0 až /data7. 2) V dalším kroku připravíme vytvoření čtyř OSD démonů následujícím způsobem: $ ceph-deploy osd prepare nympha2ib:/data nympha3ib:/data nympha4ib:/data nympha5ib:/data 3) Nyní nám již nic nebrání k aktivaci čtyř předpřipravených OSD démonů tímto příkazem: $ ceph-deploy osd activate nympha2ib:/data nympha3ib:/data nympha4ib:/data nympha5ib:/data 23

5. NASTAVENÍ 5.1.3 Nastavení klientských uzlů 1) Poˇzadavky na verzi jádra operačního systému u klietských uzlů jsou poměrně vysoké. Aktuální poˇzadavky naleznete v dokumentaci systému Ceph 18. V mém případě bylo pouˇzito na všech uzlech jádro operačního systému verze 3.14.0. 2) Dalším krokem je jiˇz samotná instalace systému Ceph na klientské uzly z počátečního serverového uzlu. V klastru Hador jsem instaloval systém na šestnáct uzlů, v klastru Nympha na deset uzlů. Zde vidíte ukázku instalace z klastru Nympha: $ ceph-deploy install nympha6ib nympha7ib nympha8ib nympha9ib nympha10ib nympha11ib nympha12ib nympha13ib nympha14ib nympha15ib 3) Na závěr už jen rozšíříme na nově nainstalované klientské uzly klíč s názvem ceph.client.admin.keyring a konfigurační soubor ceph.conf. Provádíme tak opět z počátečního serverového uzlu. $ ceph-deploy admin nympha6ib nympha7ib nympha8ib nympha9ib nympha10ib nympha11ib nympha12ib nympha13ib nympha14ib nympha15ib 5.1.4 Nastavení blokových zařízení Následující čtyři kroky provádíme již na klientských uzlech. 1) Bloková zařízení ve výchozím nastavení ukládají data do seskupení s názvem rbd. Avšak nic nám nebrání si vytvořit pro testování vlastní seskupení. Toto seskupení stačí vytvořit pouze na jednom klientském uzlu, seskupení je pak viditelné pro celý klastr. V mém případě jsem vytvořil seskupení s názvem testing následujícím způsobem: $ ceph osd pool create testing 256 256 První hodnota za názvem seskupení určuje počet umíst ujících skupin (pg num) a druhá hodnota určuje počet umíst ujících skupin pro umístění dat (pgp num). 18 Poˇzadavky na jádro operačního systému, <http://goo.gl/ftvgdg> 24

5. NASTAVENÍ 2) Dalším krokem je vytvoření blokového zařízení pomocí příkazu rbd. Parametry určují název blokového zařízení, velikost v megabajtech a seskupení, ve kterém se budou data blokového zařízení nacházet. V případě klastru Nympha i Hador jsem vytvářel na každém klientském uzlu deset blokových zařízení, v seskupení testing a s velikostí 5120 megabajtů. $ rbd create nympha6_0 --size 5120 --pool testing 3) Po úspěšném vytvoření blokových zařízení je potřeba na všech zařízení vytvořit souborový systém. V tomto příkazu se jedná o souborový systém ext4 19 s přepínačem, který nastavuje nula procent rezervovaných bloků pro super-uživatele. $ mkfs.ext4 -m0 /dev/rbd/testing/nympha6_0 4) V závěru již stačí vytvořit složky pro připojení blokových zařízení. A následně zařízení připojit. $ mkdir /mnt/rbd_0 $ mount /dev/rbd/testing/nympha6_0 /mnt/rbd_0 Po připojení by měla být všechna bloková zařízení na daném uzlu viditelná pomocí příkazu df nebo mount. 5.2 GlusterFS 5.2.1 Nastavení serverových uzlů Nastavení serverových uzlů se skládá z pěti kroků, které se kromě třetího kroku vykonávají pouze na počátečním serverovém uzlu. Postup nastavení systému GlusterFS částečně vychází z dokumentace GlusterFS [23]. 1) Z počátečního serverového uzlu přidáme ostatní serverové uzly, počáteční uzel není nutné přidávat. Níˇze je ukázka z klastru Nympha: 19 ext4, <https://www.usenix.org/legacy/event/lsf07/tech/cao m.pdf?q=ext4> 25

5. NASTAVENÍ $ gluster peer probe nympha3ib 2) Po přidání všech ostatních serverových uzlů pouze zkontrolujeme stav tímto příkazem: $ gluster peer status 3) V tomto kroku připravíme adresáře pro ukládání dat na serverové uzly definované v prvním kroku. Nejlepším způsobem je připojení celého pevného disku nebo oddílu jako přípojný bod. V mém případě jsem použil pouze jeden oddíl, který byl připojen na adresář /data. Tento krok je potřeba vykonat na všech serverových uzlech, včetně počátečního. 4) Pokračujeme vytvořením datového prostoru s daným typem rozložení dat. V mém případě jsem použil dva typy rozložení dat. Jedná se o distribuované replikované a distribuované prokládané replikované rozložení dat. První příkaz z následujících je použití s distribuovaným replikovaným typem rozložení dat. Druhý příkaz je použití s distribuovaným prokládaným replikovaným typem rozložení dat. $ gluster volume create test-volume replica 2 transport tcp nympha2ib:/data nympha3ib:/data nympha4ib:/data nympha5ib:/data $ gluster volume create test-volume stripe 2 replica 2 transport tcp nympha2ib:/data nympha3ib:/data nympha4ib:/data nympha5ib:/data 5) V závěru po úspěšném vytvoření datového prostoru, můˇzeme datový prostor spustit. $ gluster volume test-volume 5.2.2 Nastavení klientských uzlů Následující postup je potřeba provést na všech klientských uzlech. 1) Nejdříve vytvoříme sloˇzku pro připojení datového prostoru. 26

5. NASTAVENÍ $ mkdir /mnt/glusterfs 1) Po úspěšné vytvoření sloˇzky, připojíme datový prostor. Zde je uveden příklad z klastru Nympha: $ mount.gluster nympha2ib:/test-volume /mnt/glusterfs 5.2.3 Nastavení blokových zařízení Systém GlusterFS ve výchozím stavu bloková zařízení nepodporuje. Proto je nutné vytvořit v datovém prostoru soubory o pevné velikosti, které budou zastupovat bloková zařízení. A dále je přes smyčku loop připojit ke klientskému uzlu. Následující kroky provedeme na všech klientských uzlech. 1) Nejdříve vytvoříme ve složce /mnt/glusterfs deset souborů o velikosti 5120 megabajtů. Použijeme vhodný příkaz, například tento: $ dd if=/dev/zero of=/mnt/glusterfs/nympha6_0 bs=1 count=0 seek=5120m 2) Dále ve stejných souborech jako z předchozího kroku vytvoříme souborový systém ext4 bez rezervovaných bloků pro superuˇzivatele. $ mkfs.ext4 -m0 -F /mnt/glusterfs/nympha6_0 3) V závěru jiˇz stačí vytvořit sloˇzky pro připojení blokových zařízení. A následně zařízení připojit do systému. $ mkdir /mnt/gbd_0 $ mount /mnt/glusterfs/nympha6_0 /mnt/gbd_0 5.3 XtreemFS V rámci nastavení systému XtreemFS bylo částečně vycházeno z dokumentace XtreemFS [9]. 27

5. NASTAVENÍ 5.3.1 Nastavení metadata serveru (MRC) Nastavení metadata serveru obsahuje pouze spuštění daného démona na počátečním serverovém uzlu. 1) Spuštění metadata serveru provedeme tímto příkazem: $ /etc/init.d/xtreemfs-mrc start 5.3.2 Nastavení adresářové sluˇzby (DIR) Kaˇzdý bod tohoto postupu je potřeba provést na všech čtyřech serverových uzlech. 1) Adresářovou sluˇzbu nastavíme tak, aby byla replikovaná na všech čtyřech serverových uzlech. Proto musíme v tomto bodě upravit následující soubory: /etc/xos/xtreemfs/mrcconfig.properties /etc/xos/xtreemfs/osdconfig.properties V obou souborech vyplníme názvy jednotlivých serverových uzlů s adresářovou sluˇzbou a příslušným portem. Takto vypadá výchozí nastavení: # Directory Service endpoint dir_service.host = localhost dir_service.port = 32638 # If you run a replicated DIR, you also have to set the addresses of the additional DIR replicas here: #dir_service1.host = second-dir-replica #dir_service1.port = 32638 #dir_service2.host = third-dir-replica #dir_service2.port = 32638 A níže je příklad mého nastavení na klastru Nympha: # Directory Service endpoint dir_service.host = nympha2ib dir_service.port = 32638 dir_service1.host = nympha3ib 28

5. NASTAVENÍ dir_service1.port = 32638 dir_service2.host = nympha4ib dir_service2.port = 32638 dir_service3.host = nympha5ib dir_service3.port = 32638 2) Nyní v souboru dirconfig.properties, který je umístěn v adresáři /etc/xos/xtreemfs/, odstraníme první znak (#) u následujícího řádku: #babudb.plugin.0 = /etc/xos/xtreemfs/server-repl-plugin/dir. properties 3) V tomto bodě nastavíme názvy jednotlivých serverových uzlů s adresářovou službou a příslušným portem obdobně jako v bodě číslo jedna. Nastavení provedeme v souboru dir.properties, který je uložen v adresáři /etc/xos/xtreemfs/server-repl-plugin/. Jedná se o nastavení pro modul, který zpracovává replikaci adresářové služby. Zde je uvedené nastavení z klastru Nympha: # participants of the replication including this replica babudb.repl.participant.0 = nympha2ib babudb.repl.participant.0.port = 35678 babudb.repl.participant.1 = nympha3ib babudb.repl.participant.1.port = 35678 babudb.repl.participant.2 = nympha4ib babudb.repl.participant.2.port = 35678 babudb.repl.participant.3 = nympha5ib babudb.repl.participant.3.port = 35678 4) V poslední bodě již můžeme zapnout adresářovou službu. $ /etc/init.d/xtreemfs-dir start 5.3.3 Nastavení úloˇzného serveru (OSD) Celý tento postup je potřeba provést na všech čtyřech serverových uzlech, tím získáme nejvíce možného dostupného místa. 29

5. NASTAVENÍ 1) K vytvoření úloˇzného serveru nejdříve potřebujeme vytvořit sloˇzku, která uskladní data úložného serveru. Nejlepší možný způsob je připojení celého pevného disku jako přípojný bod. V klastru Nympha jsem použil pouze část disku (jeden oddíl), který byl připojen na umístění /data. 2) V dalším kroku je potřeba změnit adresáři /data vlastníka a skupinu. Provedeme to příkazem chown následujícím způsobem: $ chown xtreemfs:xtreemfs /data 3) Dále v postupu je na řadě změna místa uloˇziště v konfiguračním souboru osdconfig.properties, který je opět umístěn ve sloˇzce /etc/xos/xtreemfs/. Níˇze je ukázka z klastru Nympha: object_dir = /data 4) V závěru nastavení úloˇzného serveru jiˇz jen sluˇzbu zapneme. $ /etc/init.d/xtreemfs-osd start 5.3.4 Nastavení blokových zařízení Systém XtreemFS ve výchozím stavu bloková zařízení nepodporuje. Proto je nutné vytvořit v datovém prostoru soubory o pevné velikosti, které budou zastupovat bloková zařízení a přes smyčku loop je připojit ke klietskému uzlu. Kroky číslo jedna a tři provádíme pouze na jednom klientském uzlu, ostatní kroky na všech klientských uzlech. 1) Nejdříve je potřeba vytvořit v systému GlusterFS datový prostor. Tento příkaz pouˇzijeme pouze na jednom z klietských uzlů. V příkazu se odkazujeme na příslušný metadata server (MRC), který se nachází na počátečním serverovém uzlu. $ mkfs.xtreemfs nympha2ib/test 2) Dále připojíme datový prostor ke klientskému uzlu. Před samotným připojením je potřeba vytvořit adresář, do kterého datový prostor připojíme. V příkazu mount.xtreemfs se odkazujeme na replikovanou adresářovou službu (DIR). 30

5. NASTAVENÍ $ mkdir /mnt/xtreemfs $ mount.xtreemfs nympha2ib,nympha3ib,nympha4ib,nympha5ib/test /mnt/xtreemfs 3) V tomto kroku nastavíme výchozí nastavení replikací pro celý datový prostor. $ xtfsutil --set-drp --replication-policy WqRq --replication-factor 2 /mnt/xtreemfs 4) Po připojení datového prostoru vytvoříme na všech klientských uzlech deset souborů ve složce /mnt/xtreemfs o velikosti 5120 megabajtů. Soubory musí mít rozdílné názvy v rámci celého klastru. Použijeme na to vhodný příkaz: $ dd if=/dev/zero of=/mnt/xtreemfs/nympha6_0 bs=1 count=0 seek=5120m 5) Nyní ve stejných souborech jako z předchozího kroku vytvoříme souborový systém ext4 bez rezervovaných bloků pro superuživatele. $ mkfs.ext4 -m0 -F /mnt/xtreemfs/nympha6_0 6) V závěru jiˇz stačí vytvořit sloˇzky pro připojení blokových zařízení. A následně zařízení připojit. $ mkdir /mnt/xbd_0 $ mount /mnt/xtreemfs/nympha6_0 /mnt/xbd_0 Po připojení by měla být všechna zařízení na daném uzlu viditelná pomocí příkazu df nebo mount. 31

6. VÝSLEDKY TESTOVÁNÍ 6 Výsledky testování 6.1 Ceph Systém Ceph nesplnil očekávání. Na klastru Nympha nejevil známky jakéhokoliv škálování. Zapisoval i přepisoval data rychlostmi pouze do 50 MB/s při jakémkoliv počtu strojů a procesů. Z tohoto důvodu jsem se rozhodl pro opakované otestování na výkonnějším klastru Hador s větším množstvím Ceph OSD démonů. Zatímco na klastru Nympha byl zaveden pouze jeden Ceph OSD démon na jednom oddíle pro jeden serverový uzel. V klastru Hador byl tento počet rozšířen na osm Ceph OSD démonů pro jeden serverový uzel, každý zvlášt na samostatném pevném disku. Pro klastr Hador byly naměřeny výrazně lepší hodnoty, jak v rychlosti, tak ve šklálovatelnosti. Nejlepší ukázkou škálovatelnosti je zápis dat pro jeden proces. Avšak pro klientské uzly s malým počtem procesů byly naměřeny velice rozdílné hodnoty. Nejlepším příkladem je obrovský rozdíl naměřených hodnot u jednoho uzlu s jedním a dvěma procesy. Naměřená hodnota pro dva procesy na jednom uzlu měla být dle předpokladů daleko nižší (okolo 100 150 MB/s). Tento test byl proveden několikrát a vždy byly naměřeny téměř totožné hodnoty. 6.1.1 Nympha klastr Obr. 9: Graf zápisu dat - Ceph (klastr Nympha). 32

6. VÝSLEDKY TESTOVÁNÍ v kb/s 1 proces 2 procesy 4 procesy 6 procesů 8 procesů 10 procesů 1 uzel 42 036,83 36 377,68 43 619,80 36 441,79 42 389,47 32 630,98 2 uzly 36 096,99 39 121,35 45 403,05 44 194,49 39 159,71 35 012,58 4 uzly 33 157,81 38 789,76 42 813,73 42 298,28 36 273,55 36 930,54 6 uzlů 38 872,33 41 087,03 37 273,72 34 389,50 32 385,66 36 564,68 8 uzlů 41 397,04 35 362,79 34 469,69 34 409,34 32 312,77 32 891,02 10 uzlů 40 600,11 34 676,23 33 509,60 36 452,31 33 965,88 33 727,15 Tab. 5: Hodnoty zápisu dat - Ceph (klastr Nympha). Obr. 10: Graf přepisu dat - Ceph (klastr Nympha). v kb/s 1 proces 2 procesy 4 procesy 6 procesů 8 procesů 10 procesů 1 uzel 37 827,05 36 084,60 45 777,52 40 388,53 44 250,76 37 100,56 2 uzly 35 865,73 41 371,55 41 923,38 41 830,27 43 526,42 40 378,60 4 uzly 37 562,33 45 340,54 44 695,82 43 950,40 39 860,49 38 451,60 6 uzlů 40 546,72 44 522,96 36 951,50 36 723,48 34 381,11 35 472,03 8 uzlů 36 617,50 36 860,89 36 149,51 34 647,46 40 419,71 38 041,27 10 uzlů 43 849,13 37 220,01 36 426,80 34 574,51 38 396,15 33 425,75 Tab. 6: Hodnoty přepisu dat - Ceph (klastr Nympha). 33

6. VÝSLEDKY TESTOVÁNÍ 6.1.2 Hador klastr Obr. 11: Graf zápisu dat - Ceph (klastr Hador). v kb/s 1 proces 2 procesy 4 procesy 6 procesů 8 procesů 10 procesů 1 uzel 48 637,11 316 392,95 410 109,34 476 855,44 464 229,70 472 644,64 2 uzly 78 127,44 421 159,62 511 516,11 485 374,30 477 550,94 493 068,32 4 uzly 182 416,38 407 305,76 521 021,94 434 867,97 400 746,58 399 094,19 6 uzlů 223 017,12 403 401,12 453 938,32 442 602,43 438 361,19 394 224,73 8 uzlů 260 482,53 415 670,75 478 465,31 468 160,93 440 493,81 423 798,31 10 uzlů 289 262,29 462 422,12 476 293,33 447 556,19 442 378,73 427 212,31 12 uzlů 324 340,85 476 310,67 471 138,28 440 437,14 426 991,42 408 629,38 14 uzlů 342 310,86 488 640,68 504 190,55 416 418,44 447 928,56 424 301,90 16 uzlů 361 994,71 508 373,67 468 004,73 439 462,43 423 877,98 409 096,18 Tab. 7: Hodnoty zápisu dat - Ceph (klastr Hador). 34