}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Testování pNFS ˇ B AKALÁ RSKÁ PRÁCE
Jiˇrí Kortus
Brno, jaro 2010
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: RNDr. Lukáš Hejtmánek, Ph.D. ii
Podˇekování Chtˇel bych touto cestou podˇekovat panu RNDr. Lukáši Hejtmánkovi, Ph.D., za hodnotné rady pˇri tvorbˇe bakaláˇrské práce, odbornou pomoc pˇri rˇ ešení vzniklých problému˚ a cˇ as, který mi vˇenoval v souvislosti s tvorbou této práce. Rovnˇež bych chtˇel podˇekovat rodiˇcum ˚ zejména za obˇetavost a podporu, díky níž mohu studovat.
iii
Shrnutí Práce se vˇenuje popisu souborového systému NFS a jeho paralelní verze pNFS. Uvádí jednotlivé pˇrístupy pˇri použití pNFS, zamˇerˇ uje se na instalaci a konfiguraci. Rovnˇež zminuje ˇ problémy, které pˇri používání pNFS nastaly a jejich rˇ ešení. Její souˇcástí je také popis podpory protokolu IPv6 v pNFS.
iv
Klíˇcová slova NFS, pNFS, linux, iSCSI, OSD, parallel NFS
v
Obsah 1
2
3 4 5 6
Popis NFS, pNFS . . . . . . . . . . . . . 1.1 NFS . . . . . . . . . . . . . . . . . . 1.1.1 NFS verze 2 . . . . . . . . . 1.1.2 NFS verze 3 . . . . . . . . . 1.1.3 NFS verze 4 . . . . . . . . . 1.1.4 NFS verze 4.1 . . . . . . . . Instalace jednotlivých serveru˚ . . . . . 2.1 Popis prostˇredí . . . . . . . . . . . 2.2 Jádro, pnfs-nfs-utils . . . . . . . . . 2.3 Souborový pˇrístup – spNFS . . . . 2.3.1 Úvod . . . . . . . . . . . . . 2.3.2 Datové servery . . . . . . . 2.3.3 Metadata server . . . . . . . 2.3.4 Klient . . . . . . . . . . . . . 2.4 Objektový pˇrístup – pNFS+EXOFS 2.4.1 Úvod . . . . . . . . . . . . . 2.4.2 OSD . . . . . . . . . . . . . 2.4.3 Metadata server . . . . . . . 2.4.4 Klient . . . . . . . . . . . . . 2.5 Blokový pˇrístup . . . . . . . . . . . 2.5.1 Úvod . . . . . . . . . . . . . 2.5.2 iSCSI target . . . . . . . . . 2.5.3 MDS . . . . . . . . . . . . . 2.5.4 Klient . . . . . . . . . . . . . 2.6 PVFS . . . . . . . . . . . . . . . . . Problémy spojené s pNFS . . . . . . . . Testování výkonu pNFS . . . . . . . . . Podpora IPv6, Kerberos . . . . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 3 . 3 . 4 . 4 . 5 . 6 . 10 . 10 . 10 . 13 . 13 . 13 . 13 . 15 . 15 . 15 . 16 . 16 . 17 . 18 . 18 . 18 . 20 . 20 . . 21 . 22 . 24 . 25 . 26
1
Úvod Technologický pokrok druhé poloviny dvacátého století, a zejména poˇcátku století dvacátého prvního, s sebou mimo jiné pˇrinesl i bouˇrlivý rozvoj informaˇcních technologií. Ty umožnují, ˇ kromˇe obecnˇe rozšíˇreného využití jako komunikace a sdílení informací, využití ke stále složitˇejším výpoˇctum ˚ nebo jiným nároˇcným aplikacím. To s sebou pˇrináší nároky na výpoˇcetní výkon i na kapacitu a rychlost odezvy datových úložišt’ a výmˇeny dat mezi nimi. V prostˇredí nároˇcných výpoˇctu˚ jsou rozšíˇrené výpoˇcetní systémy ve formˇe clusteru, ˚ kde výkon celku je dán nejen poˇctem a výkonem jednotlivých uzlu, ˚ ale i rychlostí pˇri cˇ tení a ukládání dat. Potˇreba vysokého výkonu ve všech zmínˇených ohledech se projevuje napˇríklad v oblastech zpracování a streamování videa, simulacích a modelování nebo jiných nároˇcných výpoˇctech. Data jsou cˇ asto ukládána na serverech, které pˇredstavují úzké hrdlo celého systému a je složité, respektive nákladné zvýšit jejich propustnost. Tento problém lze rˇ ešit distribucí dat na více uzlu, ˚ což umožní paralelní pˇrístup k datum, ˚ a tudíž i lepší škálovatelnost takového systému. Mimo jiných souborových systému˚ se problematiku paralelního pˇrístupu pokouší rˇ ešit protokol pNFS, podˇcást protokolu NFS verze 4.1. Jeho cílem je nabídnout vysokou datovou propustnost, zárovenˇ rˇ eší otázky bezpeˇcnosti pˇrístupu k datum ˚ povinnou implementací bezpeˇcnostních mechanismu˚ (Kerberos, pˇrípadnˇe jiné). Je koncipován nejen jako alternativa k jiným paralelním souborovým systémum, ˚ ale umožnuje ˇ i nasazení spoleˇcnˇe s nimi; podporuje ruzné ˚ zpusoby ˚ vlastního ukládání dat. Parallel NFS nabízí možnost paralelizace stávajících úložných systému, ˚ které jsou zejména v prostˇredí operaˇcních systému˚ typu UNIX postaveny na protokolu NFS. Díky novým vlastnostem NFSv4 a NFSv4.1 a mj. díky univerzálnímu, na systému nezávislém návrhu, také umožní nasazení na jiných platformách. První kapitola popisuje vlastnosti jednotlivých verzí protokolu NFS a odlišnosti mezi nimi, v závˇeru se zabývá popisem protokolu pNFS. Druhá kapitola se zamˇerˇ uje na konfiguraci a instalaci linuxového jádra a nástroju˚ potˇrebných pro fungování pNFS, popisuje instalaci souborového (NFS), objektového (EXOFS), blokového a PVFS pˇrístupu. Kapitola tˇretí se zamˇerˇ uje na problémy, které nastaly bˇehem instalace nebo konfigurace popsaných ˇ pˇrístupu. ˚ Ctvrtá kapitola pojednává o testování výkonu pNFS, poslední kapitola je vˇenována popisu aktuálního stavu podpory IPv6 v pNFS a funkˇcnosti Kerberos autentizace. 2
1 Popis NFS, pNFS 1.1
NFS
NFS (Network File System) je sít’ový souborový systém puvodnˇ ˚ e navržený firmou Sun v roce 1984 [16], založený na principu klient – server. Jeho specifikace jsou otevˇrené a jsou veˇrejnˇe publikovány v dokumentech RFC. Návrh NFS byl pˇrizpusoben ˚ použití v heterogenním výpoˇcetním prostˇredí, proto byl pro výmˇenu dat zvolen jazyk XDR (eXternal Data Representation), který umožnuje ˇ korektní výmˇenu dat mezi ruznými ˚ systémy, nezávisle na platformˇe a architektuˇre. Vlastní komunikace mezi systémy (mezi klientem a serverem) byla založena na RPC (Remote Procedure Call), kdy každá operace je realizována RPC voláním na vzdáleném stroji. Každá entita souborového systému NFS je (v rámci jednoho serveru, resp. jmenného prostoru) jednoznaˇcnˇe urˇcena identifikátorem, tzv. filehandle. Ten v sobˇe zahrnuje (z pohledu serveru) identifikátor konkrétního souborového systému (oddílu), identifikaci souboru (adresáˇre) – cˇ íslo i-uzlu, a cˇ íslo instance (generace) tohoto souboru. Užití filehandle místo pˇrístupových cest bylo zvoleno z duvodu ˚ rozdílných zpusob ˚ u˚ popisu cesty k souboru jednotlivými operaˇcními systémy. Zpoˇcátku bylo k sít’ové komunikaci využito protokolu UDP z duvodu ˚ lepšího využití sítˇe a snížení latencí pˇri komunikaci. Vzhledem k tomu, že se ale jedná o protokol nespolehlivý (nezajišt’ující doruˇcení dat), bylo nutné spolehlivost zajistit uvnitˇr NFS. Pozdˇeji byla pˇridána i možnost komunikace nad spolehlivým protokolem TCP, což pˇrineslo zlepšení propustnosti NFS, protože nativní algoritmus pro retransmisi ztracených datagramu˚ v TCP byl efektivnˇejší než algoritmus v NFS použitý pro retransmisi UDP datagramu. ˚ Ve verzích 1, 2 a 3 je protokol NFS bezstavový – pˇri každém RPC volání server pouze zpracuje požadavek od klienta a vrátí mu pˇrípadnˇe výsledek volání; sám o sobˇe ale neˇreší stav zdroju, ˚ ke kterým je pˇristupováno. Protokol NFS sám o sobˇe neimplementuje zamykání souboru, ˚ tato funkcionalita vyžadující stav je zajišt’ována protokolem NLM (Network Locking Manager) [1]; informace o stavu je potˇrebná i ve vztahu k prvotnímu pˇripojení exportovaného souborového systému klientem (zjištˇení prvotního filehandle) pomocí protokolu MOUNT [2, Appendix A.]1 , který je využíván pˇri procesu prvotního pˇripojení exportovaného adresáˇre klientem.
1. Jednalo se o udržování pˇrehledu o tom, kteˇrí klienti pˇristupují k exportovaným položkám z duvod ˚ u˚ správy, napˇr. aby bylo možné uvˇedomit je pˇri vypínání serveru.
3
1. P OPIS NFS, P NFS Absence stavu pˇrímo v protokolu NFS na stranˇe serveru umožnuje ˇ jednodušší implementaci serveru a zjednodušuje zotavení pˇrístupu na server po jeho havárii. Klienti pouze znovu opakují své požadavky a vyˇckávají na jejich provedení; v pˇrípadˇe potˇreby mohou do urˇcité doby od opˇetovného spuštˇení serveru (tzv. grace period) znovu uplatnit pˇres NLM zamknutí souboru, ˚ ke kterým pˇred pádem pˇristupovali). 1.1.1 NFS verze 2 První verze protokolu NFS sloužila pouze pro interní potˇreby firmy Sun [16], po doplnˇení a pˇrepracování byla specifikace ve druhé verzi uvolnˇena jako dokument RFC 1094 [2]. Jako první zveˇrejnˇená specifikace nesla výše uvedené rysy – zejména absenci stavu na stranˇe serveru a komunikaci nad protokolem UDP2 . NFSv2 umožnuje ˇ pouze základní rˇ ízení pˇrístupu (AUTH_UNIX) na bázi uživatelských (UID), resp. skupinových (GID) identifikátoru˚ charakteristické pro OS UNIX. To zajišt’uje pouze velmi omezenou bezpeˇcnost a navíc je nutný pˇredpoklad sjednocení identifikátoru˚ UID/GID všech klientu˚ a serveru, ˚ pˇrípadnˇe jejich vhodné pˇremapování. 1.1.2 NFS verze 3 Tˇretí verze protokolu specifikovaná v RFC 1813 [3] pˇrinesla další druhy autentizace. Druh AUTH_DES poskytuje autentizaci pomocí jména platného v rámci celé sítˇe (network-wide name), pˇriˇcemž autentizaˇcní parametry jsou šifrovány algoritmem DES a klíˇce sezení jsou vymˇenˇeny pomocí asymetrické kryptografie. Dalším druhem autentizace je AUTH_KERB – autentizaˇcní parametry jsou taktéž založené na jménu s platností v rámci sítˇe a šifrovány pomocí DES. Klíˇce sezení jsou vymˇenˇeny za pomoci tajných klíˇcu˚ v rámci protokolu Kerberos. Kromˇe nových možností autentizace NFSv3 pˇrináší zvˇetšení velikosti filehandle na maximálnˇe 64 B a zárovenˇ povoluje jeho velikost i zmenšit dle potˇreby, což cˇ ásteˇcnˇe šetˇrí místo, které zabírá filehandle, a snižuje zatížení sítˇe. Rovnˇež je pˇrekonána hranice maximální velikosti souboru 2 GB zvˇetšním offsetu souboru na 64 b, je odstranˇena 8kB hranice pro cˇ tení a zápis. Kromˇe komunikace nad protokolem UDP je explicitnˇe pˇridána i podpora TCP. Je zefektivnˇena práce s atributy, které jsou vraceny po každém 2. Po uvolnˇení specifikace NFSv3 byla implementace NFSv2 firmy Sun rozšíˇrena o podporu protokolu TCP; konkurenˇcní implementace již pˇredtím tento protokol pro NFS podporovaly [16, NFSv3].
4
1. P OPIS NFS, P NFS volání procedury – to eliminuje nezanedbatelné množství volání procedury pro zjištˇení atributu˚ (GETATTR). Vylepšená efektivita se týká i zjišt’ování obsahu adresáˇru, ˚ pro které je novˇe definována procedura READDIRPLUS vracející kromˇe filehandle i jejich atributy (tím se eliminuje potˇreba získávat jednotlivˇe filehandle a atributy souboru˚ v adresáˇri). Výkon NFS serveru muže ˚ být zvýšen povolením bezpeˇcného asynchronního zápisu. To znamená, že klient nemusí poslat na server data s požadavkem, aby byla ihned zapsána na disk; místo toho posílá data, která server uloží do vyrovnávací pamˇeti a klient data ze své pamˇeti ještˇe neodstraní (ˇcímž zabrání jejich ztrátˇe, pokud by v tomto okamžiku došlo k výpadku serveru). V okamžiku, kdy pošle urˇcité množství dat nebo posílání dokonˇcí, zavolá na serveru proceduru COMMIT a server z vyrovnávací pamˇeti data zapíše do pamˇeti trvalé (na disk), následnˇe klient muže ˚ data ze své pamˇeti bezpeˇcnˇe odstranit. 1.1.3 NFS verze 4 NFSv4 dle specifikace z roku 2000, RFC 3010, v roce 2003 nahrazená specifikací RFC 3530 [4], pˇrinesla mimo jiné duležitou ˚ zmˇenu – stavovost protokolu oproti verzím pˇredchozím. Celý protokol je nyní postaven cˇ istˇe na RPC vˇcetnˇe funkcionality, která byla puvodnˇ ˚ e rˇ ešena externˇe: zámky již nejsou rˇešeny pomocí NLM, pro pˇripojování exportu˚ není použit protokol MOUNT. Od NFSv4 je možné definovat cˇ ásteˇcné zmˇeny v protokolu v rámci minor versions (minor verzí, podverzí). Oproti verzím 2 a 3 dochází ke zmˇenám v pojetí hierarchie souborového systému. V NFSv4 nejsou exporty oddˇeleny (netvoˇrí více stromu), ˚ ale jsou souˇcástí hierarchie jednoho stromu. Jsou definovány základní identifikátory filehandle – root filehandle a public filehandle. Root filehandle identifikuje koˇren celého stromu, public filehandle libovolný objekt pˇredstavující souborový systém (tzn. podstrom celého stromu). Zámky jsou klientum ˚ na požádání doˇcasnˇe pˇridˇeleny serverem na bázi zápujˇ ˚ cek (leases) – klient musí požadavky na zámek prubˇ ˚ ežnˇe obnovovat (bud’ explicitním požadavkem, nebo provádˇením operací, pˇri kterých je doba platnosti automaticky prodloužena, napˇr. READ). Zámky nemusí být aplikovány jen na celé objekty souborového systému, ale i na jejich podˇcásti v urˇceném rozsahu (byte-range). Novou vlastností je i delegace pravomocí na klienta. Server muže ˚ klientovi pˇridˇelit urˇcitou pravomoc, která je spravována na stranˇe klienta (napˇr. zápis do souboru), cˇ ímž je zvýšena rychlost operací (možnost využití vyrovnávací pamˇeti u klienta) a sníženo zatížení sítˇe. Delegací je využito v pˇrípadˇe, 5
1. P OPIS NFS, P NFS kdy nedochází ke konfliktu požadavku˚ klientu; ˚ pokud je udˇelena delegace a bránila by novému požadavku klienta, muže ˚ být serverem odvolána. Pojetí procedur je odlišné od pˇredchozích verzí – NFSv4 definuje dvˇe procedury: NULL a COMPOUND, pˇriˇcemž všechny operace jsou souˇcástí procedury COMPOUND. Ta umožnuje ˇ vložení více operací, které jsou poté po rˇ adˇe vykonávány, navíc si mohou postupnˇe pˇrímo pˇredávat filehandle. Pˇrínos COMPOUND spoˇcívá zejména v odstranˇení kumulace latencí, které by vznikaly pˇri postupném volání dílˇcích procedur. NFSv4 podstatnˇe rozšiˇruje množinu atributu, ˚ které se dˇelí na tˇri druhy (mandatory, recommended a named). Atributy skupiny mandatory pˇredstavují základní množinu atributu˚ a musí být povinnˇe podporovány klientem i serverem. Skupina recommended obsahuje další rozšíˇrení, která by mˇela být dle možností v co nejvˇetší míˇre podporována; mezi nˇe patˇrí mj. pokroˇcilé rˇízení pˇrístupových práv pomocí ACL (Access Control List). Poslední skupina pˇredstavuje rozšíˇrení pro potˇreby aplikací, které není omezováno, nicménˇe atributy z této skupiny by mˇely být zaregistrovány u organizace IANA, aby nedocházelo ke kolizím. Atributy jsou novˇe založeny na rˇ etˇezcích kódovaných pomocí UTF-8. Za pomoci speciálních atributu˚ lze u NFSv4 provádˇet migraci souborového systému za chodu na jiný server (pˇri pokusu o pˇrístup k filehandle pˇresunutého souboru dojde k chybˇe vzniklé pˇresunem, klient se poté muže ˚ serveru zeptat na nové umístˇení souboru). Kromˇe migrace je možná také replikace souborového systému na více serveru˚ (pˇredpokládané využití se týká souborových systému˚ exportovaných jen pro cˇ tení). Dále je vylepšena bezpeˇcnost díky povinnému použití frameworku RPCSEC_GSS dle RFC 2203, který nabízí ruzné ˚ pˇrístupy k zajištˇení autentizace, integrity dat a soukromí; definuje, jak se klient a server dohodnou na použití konkrétního zpusobu ˚ zabezpeˇcení (Kerberos V5, LIPKEY a SPKM-3). Specifikace NFSv4 požaduje použití protokolu s rˇízením zahlcení uznaný organizací IETF (TCP, SCTP); pˇredepsaná je podpora TCP. V pˇrípadˇe komunikace protokolem TCP by mˇela být udržována persistentní spojení, aby nebylo nutné neustále navazovat nová spojení, což by se projevilo vyššími latencemi zejména v prostˇredí WAN sítí. 1.1.4 NFS verze 4.1 Protokol NFSv4.1 popsaný v RFC 5661 [5] pˇredstavuje první minor verzi NFSv4. Je rozšíˇrena množina zámku˚ o serverem odvolatelné zámky pro delegaci adresáˇru˚ (directory delegation) umožnující ˇ efektivnˇejší použití vyrovnávací pamˇeti na klientovi. Dalším (odvolatelným) zámkem je layout, který 6
1. P OPIS NFS, P NFS klientovi umožnuje ˇ pˇrímý pˇrístup k datum ˚ a zajišt’uje jejich konzistenci po dobu držení zámku. Vylepšení delegací se týká také informování klientu˚ o zmˇenách souboru˚ a adresáˇru˚ (jen pro cˇ tení). Server navíc muže ˚ pˇri odvolávání delegací z duvod ˚ u˚ správy prostˇredku˚ upozornit klienta, který se muže ˚ rozhodnout, jaké delegace vrátí. Protokol zlepšuje kompatibilitu s Microsoft Windows v oblasti rˇ ízení pˇrístupu pomocí ACL. V oblasti bezpeˇcnostních mechanismu˚ není v NFSv4 povinné implementovat LIPKEY a SPKM3, povinná je však implementace mechanismu Kerberos V5 GSS-API. Komunikace mezi klientem a serverem je novˇe založena na relacích (sessions). Relace jsou objekty na serveru dynamicky vytvoˇrené klientem a slouží k reprezentaci stavu mezi jednotlivými spojeními a instancemi klientu. ˚ To pˇredstavuje mechanismus pro EOS sémantiku (Exactly Once Semantics), tedy sémantiku zaruˇcující, že každá operace bude vykonána právˇe jednou. Tato vlastnost je duležitá ˚ zejména pro neidempotentní operace vykonávané v potenciálnˇe nespolehlivém sít’ovém prostˇredí. Jedna relace pˇritom náleží pouze jednomu klientovi, zatímco jeden klient muže ˚ mít více relací, jedna relace však nesmí náležet více klientum. ˚ Stav urˇcený relací pˇritom nezávisí na existenci spojení mezi klientem a serverem. Pokud po urˇcitou dobu není relaci pˇriˇrazeno žádné spojení, dochází k vypršení platnosti zámku˚ asociovaných s klientem, kterému relace náleží. V souvislosti s relacemi existují dva komunikaˇcní kanály – dopˇredný (fore channel) a zpˇetný (backchannel). Zpˇetný kanál je iniciován klientem (to umožnuje ˇ ustavení kanálu pˇri pruchodu ˚ firewallem, pˇrípadnˇe NAT) na základˇe jeho rozhodnutí. Slouží jako komunikaˇcní cesta k pˇrenosu požadavku˚ zpˇetného volání od serveru. Pro zvýšení výkonu je (mimo dalších vlastností) v NFSv4.1 možné používat trunking, tzn. více spojení mezi klientem a serverem ruznými ˚ cestami, resp. vícenásobný pˇrístup, pokud jsou data zpˇrístupnˇena/replikována na více serverech. Velmi duležitou ˚ zmˇenou v NFSv4.1 je nepovinná možnost implementovat paralelní pˇrístup mezi klienty a servery – pNFS, Parallel NFS. Oproti pˇredchozím verzím NFS jsou zmˇenˇeny vztahy mezi komponentami systému, kde mimo množiny klientu˚ a serveru˚ pˇribyla funkce Metadata serveru(MDS). Koncepce pNFS je založena na oddˇelení samotných dat a informací o datech (metadat). Data jsou uložena na datových serverech/úložištích (DS), pˇrístup k tˇemto datum ˚ má mimo klientu˚ i metadata server (MDS). Informace popisující umístˇení dat a informace o nich jsou pˇredávány v tzv. layoutech. Každý layout nese informaci o tom, na kterých úložištích (a kde v rámci 7
1. P OPIS NFS, P NFS nich) se data nachází a navíc specifikuje, podle jakého vzoru budou data do jednotlivých úložišt’ ukládána (napˇr. jak budou data rozkládána do stripes). MDS vystupuje vuˇ ˚ ci datovým úložištím v roli klienta a data z úložišt’ zpˇrístupnuje ˇ pomocí NFSv4.1 exportu. ˚ Klient pˇristupující k exportu v pˇrípadˇe schopnosti komunikovat pˇres NFSv4.1 pˇri požadavku na pˇrístup k objektu v exportu od serveru získá layout týkající se patˇriˇcného objektu. Z nˇej zjistí, kde se objekt nachází, a muže ˚ k nˇemu pˇristupovat pˇrímou cestou, mimo MDS. Komunikace s MDS probíhá pˇres protokol pNFS, který plní roli rˇ ídicího protokolu, vlastní datová komunikace mezi klientem a datovým úložištˇem je uskuteˇcnˇena pomocí protokolu pro pˇrístup k úložišti.
KLIENTI protokol pNFS
Protokol pro přístup k úložišti
MDS Řídicí protokol
DATOVÉ SERVERY Obrázek 1.1: Komponenty architektury pNFS. Layout sám o sobˇe nemá pro klienta vypovídací hodnotu, jak k datum ˚ pˇristupovat. O interpretaci informací v layoutu a jejich použití se stará layout driver, který koordinuje rˇ ídicí informace v návaznosti na MDS a vlastní pˇrímou datovou komunikaci mezi klienty a úložišti. Tato koncepce umožnuje ˇ eliminovat úzké hrdlo, které by normálnˇe pˇredstavovaly omezené prostˇredky NFS serveru, respektive komunikaˇcní cesta mezi klientem a serverem. Díky paralelizaci muže ˚ pˇri pˇridávání dalších úložišt’ celý systém škálovat; oddˇelením datové a rˇ ídicí komunikace lze plnˇe využít dostupné pˇrenosové kapacity. 8
1. P OPIS NFS, P NFS Klient muže ˚ na DS pˇristupovat i prostˇrednictvím exportu na MDS, který v takovém pˇrípadˇe plní roli DS, pokud nejsou data rozkládána (stripována) mezi více DS. MDS sice pˇredstavuje v takové situaci úzké hrdlo systému jako v pˇrípadˇe bˇežného NFS, nicménˇe použití této možnosti muže ˚ být výhodné, protože klient muže ˚ k datum ˚ pˇristupovat i v pˇrípadˇe, že nepodporuje komunikaci pomocí pNFS, pˇrípadnˇe není tˇreba, aby všichni klienti pˇristupovali pomocí pNFS. PNFS je možné využít ve spojení s ruznými ˚ pˇrístupy k ukládání dat [6], tzn. s ruznými ˚ koncepcemi datových úložišt’. Specifikace NFSv4.1 popisuje tˇri typy pˇrístupu˚ – souborový pˇrístup (file layout), objektový pˇrístup (object layout) a blokový pˇrístup (block/volume layout), objektový a blokový pˇrístup jsou popsány ve zvláštních dokumentech RFC 5664 [7] a RFC 5663 [8]. Data jsou na backendu (úložišti) ukládána ruznými ˚ zpusoby, ˚ z pohledu aplikací na klientovi se ovšem jedná o zápis do souboru˚ na pˇripojeném pNFS svazku. Souborový pˇrístup ukládá na DS data do souboru, ˚ tedy zejména prostˇrednictvím NFS. Mohou být použity ale i jiné podporované souborové systémy, jako napˇr. PVFS nebo GFS. V další kapitole je popsáno použití souborového pˇrístupu založeného na spNFS (simple pNFS). Objektový pˇrístup ukládá data na objektové úložištˇe (OSD, Object storage device) data do kontejneru˚ – objektu, ˚ pˇriˇcemž objekt obsahuje jednak data a jednak atributy; soubor muže ˚ být uložen do více objektu. ˚ Pˇrenos dat mezi klientem a OSD probíhá pomocí protokolu OSD, podmnožiny protokolu SCSI. Dále je uvedena konfigurace pNFS objektového pˇrístupu s úložištˇem osc-osd a souborovým systémem EXOFS. Blokový pˇrístup je založen na ukládání dat na bloková zaˇrízení. K nim pˇristupuje jako k bˇežným blokovým zaˇrízením (napˇr. diskum) ˚ a cˇ tení/zápis probíhá ve formˇe bloku˚ dat. Jedná se zejména o použití protokolu˚ z rodiny SCSI (Small Computer System Interface), napˇr. Parallel SCSI, Serial Attached SCSI, Internet SCSI – iSCSI aj. Vzhledem k charakteristice blokového pˇrístupu je nutné vzít zde v úvahu otázku bezpeˇcnosti, protože v tomto ohledu je její správa delegována na klienty (na úložišti by bylo problematické ji rˇ ešit). Blokový pˇrístup je možné použít jen v bezpeˇcném prostˇredí, s kontrolou nad klienty. Popisovaná konfigurace pNFS blokového pˇrístupu využívá block spNFS serveru.
9
2 Instalace jednotlivých serveru˚ 2.1
Popis prostˇredí
K testování všech pNFS serveru/pˇ ˚ rístupu˚ byl pro poˇcáteˇcní seznámení s pNFS jako operaˇcní systém použit Debian linux 5.0.4 stable (Lenny). Tento systém byl zvolen s ohledem na použitý balíˇckovací systém a zkušenosti s prostˇredím. Vzhledem k nedostupnosti nˇekterých knihoven z repozitáˇru˚ stable byl pˇridán i repozitáˇr unstable. Vlastní testování probíhalo na virtuálních (paravirtualizovaných) strojích Ústavu výpoˇcetní techniky Masarykovy univerzity, na kterých byl nainstalován Debian linux 4 stable (Etch). Knihovny a další software potˇrebný ke zprovoznˇení a testování jednotlivých serveru˚ nedostupné v repozitáˇrích byly staženy v podobˇe zdrojových kódu˚ a zkompilovány, jak je dále uvedeno v jednotlivých postupech. Není-li uvedeno jinak, týkají se dané postupy všech stroju˚ (DS, MDS i klientu). ˚ Instalace v jiných linuxových distribucích se muže ˚ od uvádˇených postupu˚ cˇ ásteˇcnˇe lišit (napˇríklad použitým balíˇckovacím systémem a správci balíˇcku, ˚ jejich dostupností a konvencí v pojmenování, umístˇením souboru, ˚ názvy služeb apod.).
2.2
Jádro, pnfs-nfs-utils
Testy byly provádˇeny s linuxovým jádrem 2.6.33-rc6 1 rozšíˇreným pNFS patchem. Pro funkˇcnost NFSv4 a pNFS je zapotˇrebí v konfiguraci jádra pˇred zkompilováním nastavit konfiguraˇcní direktivy2 následujícím zpusobem: ˚ CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_PNFS=y CONFIG_NFSD=m CONFIG_PNFSD=y CONFIG_SPNFS=y 1. V další fázi bylo použito jádro 2.6.33, protože s jádrem 2.6.33-rc6 se nepodaˇrilo zprovoznit pNFS objektový pˇrístup. Nejnovˇejší jádro s podporou pNFS je možné získat z git://linux-nfs.org/~bhalevy/linux-pnfs.git 2. Názvy direktiv souvisejících s pNFS se pravdˇepodobnˇe v následujících verzích jádra budou lišit [9].
10
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ Pro podporu objektového pˇrístupu a souborového systému EXOFS je nutné nastavit direktivy CONFIG_PNFS_OBJLAYOUT=m CONFIG_SCSI_ULD=m CONFIG_EXOFS_FS=m V pˇrípadˇe konfigurace jádra pro podporu blokového pˇrístupu nesmí být zapnuta podpora lokálních pNFS exportu˚ [10] (její zapnutí zapˇríˇciní nefunkˇcnost blokového pˇrístupu): CONFIG_PNFSD_LOCAL_EXPORT=n Stažení jádra, aplikace pNFS patche, zkonfigurování a kompilace byla provedena postupem cd /usr/src wget http://www.kernel.org/pub/linux/kernel/v2.6/\ testing/v2.6.33/linux-2.6.33-rc6.tar.bz2 tar xjvf linux-2.6.33-rc6.tar.bz2 rm linux-2.6.33-rc6.tar.bz2 cd linux-2.6.33-rc6 wget "http://git.linux-nfs.org/?p=bhalevy/linux-pnfs\ git;a=commitdiff_plain;h=pnfs-all-2.6.33-rc6-\ 2010-02-24;hp=v2.6.33-rc6" -O pnfs-patch patch -p1
11
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ libtirpc-dev libwrap0-dev libkrb5-dev libgssglue-dev \ libcap-dev libblkid-dev librpcsecgss-dev rpcbind3 Dále byly staženy, zkompilovány a nainstalovány knihovny libevent a libnfsidmap: wget http://www.monkey.org/~provos/libevent-1.4.13-\ stable.tar.gz wget http://www.citi.umich.edu/projects/nfsv4/linux/\ libnfsidmap/libnfsidmap-0.23.tar.gz tar xzvf libevent-1.4.13-stable.tar.gz tar xzvf libnfsidmap-0.23.tar.gz cd libevent-1.4.13-stable ./configure && make && make install && cd .. cd libnfsidmap-0.23 ./configure && make && make install && cd .. Poté již bylo možné nainstalovat aktuální verzi nástroju˚ pro práci s pNFS, pnfs-nfs-utils, a spustit (v pˇrípadˇe DS a MDS) NFS server: git clone git://git.linux-nfs.org/projects/bhalevy/\ pnfs-nfs-utils.git cd pnfs-nfs-utils ./autogen.sh ./configure && make && make install service nfs-kernel-server restart Startovací skripty NFS serveru nedetekovaly pˇrítomnost podpory NFS v jádˇre, pravdˇepodobnˇe v dusledku ˚ zmˇen v nových verzích jádra. To bylo provizornˇe vyˇrešeno zakomentováním podmínky, která slouží ke zjištˇení podpory NFS, ve skriptu /etc/init.d/nfs-kernel-server: #if [ -f /proc/kallsyms ] && ! grep -qE ’init_nf(sd| )’ /proc/kallsyms; then # log_warning_msg "Not starting $DESC: no support in current kernel." # exit 0 #fi 3. rpcbind musel být nainstalován namísto puvodní ˚ služby portmap, protože pokus o spuštˇení služby nfs.mountd konˇcil chybovou hláškou unable to register (mountd, 1, udp), pravdˇepodobnˇe proto, že se démon pokoušel pˇripojit na místní IPv6 ˇ loopback adresu ::1, avšak démon portmap IPv6 nepodporuje. Rešením problému je nahrazení démona portmap démonem rpcbind nebo zakázání IPv6 loopback rozhraní.
12
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚
2.3
Souborový pˇrístup – spNFS
2.3.1 Úvod Na datových serverech je nutné vyexportovat adresáˇr sloužící pro ukládání dat pˇres pNFS, jedná se o bˇežný NFS export (ne nutnˇe NFSv4). Metadata server exportuje jeden NFSv4.1 adresáˇr s parametrem pnfs, což v kombinaci s rˇ ídicím démonem spnfsd zajistí, že daný stroj bude vystupovat jako MDS. Démonovi spnfsd je v konfiguraˇcním souboru nastaveno, jaký je poˇcet datových serveru, ˚ jejich IP adresy a exporty na nich, které budou sloužit pro ukládání dat pNFS klientu, ˚ a dále adresáˇr na MDS, který obsahuje pˇrípojná místa s pˇripojenými exporty jednotlivých DS. Klient nevyžaduje žádnou zvláštní konfiguraci, jen je tˇreba zavést modul nfslayoutdriver, aby mohl správnˇe interpretovat layouty od MDS a pˇrímo komunikovat s datovými servery. Celý pNFS systém je zpˇrístupnˇen pˇripojením pNFS exportu z MDS do pˇrípojného místa na klientovi za použití volby minorversion=1. Tato volba urˇcuje použití protokolu NFSv4.1, jehož je pNFS souˇcástí. 2.3.2 Datové servery Na jednotlivých DS byly vytvoˇreny koˇrenové adresáˇre (zde /pnfs) urˇcené pro pˇrístup pˇres pNFS a bylo nastaveno jejich exportování pˇres NFSv4 zkonfigurováním souboru /etc/exports následujícím zpusobem ˚ [17] (není zapotˇrebí volba pnfs, jedná se o bˇežný NFS export): / *(rw,fsid=0,no_root_squash,sync,no_subtree_check) Následovalo naˇctení nové konfigurace: exportfs -r 2.3.3 Metadata server Na MDS byl vytvoˇren adresáˇr /pnfs sdružující adresáˇre urˇcené pro pˇripojení exportu˚ z jednotlivých DS, pojmenované podle IP adresy datových serveru. ˚ Byl založen i adresáˇr /export sloužící k pˇrístupu k exportovaným adresáˇrum ˚ z datových serveru˚ prostˇrednictvím MDS. Do konfiguraˇcního souboru /spnfsd.conf [18] byly zapsány informace o obecné konfiguraci spNFS – velikost stripe (stripe size), cesta k adresáˇri v souborovém systému MDS, který obsahuje pˇrípojné body datových serveru˚ DS-Mount-Directory a jejich poˇcet NumDS. 13
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ Pro každý z datových serveru˚ 4 byla specifikována jeho IP adresa DSn_IP, cˇ íslo portu DSn_PORT, identifikátor DSn_ID a cesta k adresáˇri pro ukládání dat v souborovém systému exportovaném z DS DSn_ROOT, a to v pojetí NFSv4 (tedy v tomto pˇrípadˇe adresáˇr /pnfs na datovém serveru pˇredstavuje koˇrenový adresáˇr / z pohledu NFSv4 klienta). [General] Verbosity = 1 Stripe-size = 8192 Dense-striping = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs DS-Mount-Directory = /spnfs [DataServers] NumDS = 2 DS1_IP = DS1_PORT DS1_ROOT DS1_ID =
192.168.1.200 = 2049 = / 1
DS1_IP = DS1_PORT DS1_ROOT DS1_ID =
192.168.1.201 = 2049 = / 1
Po nakonfigurování spNFS serveru byla do souboru /etc/exports vložena položka pro nasdílení adresáˇre /export jako koˇrenu (root) pˇres pNFS. Parametr pnfs je zde zásadní, protože umožnuje ˇ klientum ˚ komunikaci jak s MDS (pro pˇredávání informací o layoutech), tak i pˇrímo s datovými servery. /export *(rw,fsid=0,insecure,no_root_squash,sync, no_subtree_check,pnfs) Posledním krokem na MDS bylo pˇripojení exportovaných adresáˇru˚ z datových serveru˚ do pˇripravených pˇrípojných bodu, ˚ naˇctení nové konfigurace a spuštˇení démona spnfsd: 4. Konfigurace byla zprovoznˇena s jedním DS, pro názornost je dále uvedena konfigurace se dvˇema DS.
14
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ mount -t nfs4 192.168.1.200:/ /spnfs/192.168.1.200 mount -t nfs4 192.168.1.201:/ /spnfs/192.168.1.201 exportfs -r spnfsd
2.3.4 Klient Na klientských systémech byla vytvoˇrena pˇrípojná místa /mnt/pnfs, do kterých byl po zavedení modulu pro podporu pNFS pˇres NFS pˇrístup pˇripojen exportovaný adresáˇr z MDS (192.168.1.202) pod NFSv4. mkdir /mnt/pnfs modprobe nfslayoutdriver mount -t nfs4 -o minorversion=1 192.168.1.202:/ \ /mnt/pnfs Poté bylo možné do pˇrípojného místa /mnt/pnfs bˇežnˇe pˇristupovat a provádˇet operace se soubory a adresáˇri.
2.4
Objektový pˇrístup – pNFS+EXOFS
2.4.1 Úvod Pˇri objektovém pˇrístupu jsou, stejnˇe jako v pˇredchozích pˇrípadech, použity tˇri komponenty – datové úložištˇe, MDS a klient. Úložištˇe je založeno na iSCSI targetu rozšíˇreném o podporu ukládání objektu; ˚ vlastní data objektu˚ jsou na úložišti ukládána do souboru, ˚ z pohledu iSCSI klienta (iniciátoru) ale jednotlivé targety a jejich logické jednotky vystupují jako zaˇrízení využívající objektový souborový systém EXOFS. Metadata server musí mít pˇrehled o OSD zaˇrízeních, která mají sloužit pro ukládání objektu, ˚ a tedy vuˇ ˚ ci nim vystupuje jako klient. Exportuje jeden adresáˇr s volbou pnfs, který si jednotliví klienti pˇripojí. Klienti musí podporovat komunikaci s OSD a musí se na nˇe pˇrihlásit. Za podpory ovladaˇce pro objektový pˇrístup objlayoutdriver mohou pˇristoupit k exportu na MDS a s jeho pomocí následnˇe pˇrímo komunikovat se všemi úložišti. Vyzkoušena byla konfigurace se tˇremi stroji – metadata serverem, OSD a klientem, konfigurace s více stroji nebyla vyzkoušena z duvodu ˚ neúspˇešné kompilace potˇrebných nástroju˚ na virtuálních strojích. Kompilace neprobˇehla pravdˇepodobnˇe kvuli ˚ ne zcela aktuálním knihovnám a dalším 15
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ potˇrebným balíˇckum ˚ na tˇechto strojích a jejich povýšení na novˇejší verze nebylo možné provést, proto je dále popsána konfigurace MDS+OSD+klient. Pˇri práci se skripty dodanými k nástrojum ˚ pro práci s OSD docházelo ke špatné interpretaci skriptu, ˚ proto je cˇ ásteˇcnˇe jejich cˇ innost rozepsána jako posloupnost jednotlivých pˇríkazu. ˚ Bˇežnˇe by mˇely tyto pomocné skripty fungovat a mˇelo by být možné je k práci s OSD a pNFS bez problému˚ použít, pˇrestože pˇri praktickém nasazení bude patrnˇe k celé konfiguraci pˇristupováno zcela odlišnˇe. 2.4.2 OSD K nastavení objektových úložišt’ (OSD) byl na každém stroji sloužícím jako zaˇrízení OSD zkompilován démon pro OSD target OSC OSD [11][12], navíc byly nainstalovány nástroje pro práci s iSCSI z balíˇcku open-iscsi. apt-get install open-iscsi libsqlite3-dev git clone git://git.open-osd.org/osc-osd git submodule init git submodule update cd osc-osd make Ke spuštˇení serveru a zpˇrístupnˇení objektového datového úložištˇe prostˇrednictvím iSCSI OSD targetu byl po úpravách (aby odpovídal daným podmínkám) použit skript up dodávaný se zdrojovými kódy OSC OSD: BACKSTORE0=/exofs-backstore Tím došlo k nastavení adresáˇre, do kterého budou ukládána data reprezentovaná úložištˇem 0. Další úložištˇe nebyla nastavována, proto byly další rˇ ádky pro nastavování cest jednotlivých promˇenných BACKSTOREn zakomentovány. Skript po spuštˇení vytvoˇrí iSCSI target, zpˇrístupní jej pro všechny iniciátory a vytvoˇrí v nˇem logickou jednotku 0, která pˇredstavuje OSD úložištˇe v /exofs-backstore. 2.4.3 Metadata server Na MDS byl zkompilován iSCSI OpenOSD iniciátor, nainstalovány potˇrebné balíˇcky a upraveny dodané skripty do-osd a do-exofs5 . 5. Skript do-exofs sloužící k práci se souborovým systémem exofs z OSD iniciátoru neplnil svou hlavní funkci – pˇripojení souborového systému z OSD targetu. Proto jsou kroky, které by mˇel suplovat, dále jednotlivˇe rozepsány.
16
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ apt-get install open-iscsi uuidgen git clone git://git.open-osd.org/open-osd.git cd open-osd make Úprava skriptu do-osd spoˇcívala v nastavení IP adresy OSD targetu úpravou promˇenné IP_OSD, po ní mohl být skript spuštˇen, cˇ ímž došlo k pˇrihlášení iniciátoru na target. Dalším krokem bylo vytvoˇrení souborového systému exofs na zaˇrízení /dev/osd0, které vzniklo v dusledku ˚ pˇrihlášení na target. K tomu je využito nástroje mkfs.exofs dodávaného se zdrojovými kódy open-osd. Vytváˇrenému oddílu bylo tˇreba nastavit identifikátor oddílu (PID, partition ID) a jméno, resp. jedineˇcný identifikátor, který je možné vygenerovat napˇr. nástrojem uuidgen. 6 Po vytvoˇrení souborového systému již bylo možné zaˇrízení /dev/osd0 pˇripojit (s povinným uvedením identifikátoru PID ): ./do-osd uuidgen ./usr/mkfs.exofs --osdname=vygenerovane_uuid \ --dev=/dev/osd0 --pid=0x10000 mount -t exofs -o pid=0x10000 /dev/osd0 \ /mnt/exofs V souboru /etc/hosts byl nastaven export pˇrípojného bodu OSD: /mnt/exofs *(rw,fsid=0,insecure,no_root_squash,sync, no_subtree_check,pnfs) a byl obnoven seznam exportovaných adresáˇru: ˚ exportfs -v
2.4.4 Klient Bylo nutné nainstalovat iSCSI OpenOSD inicátor stejným postupem jako na MDS. Následovalo pˇrihlášení na OSD target (po upravení skriptu do-osd), zavedení ovladaˇce objlayoutdriver pro objektový pˇrístup pˇres pNFS a na závˇer pˇripojení exportu z pNFS serveru: apt-get install open-iscsi uuidgen git clone git://git.open-osd.org/open-osd.git cd open-osd make 6. Je možné i nastavit velikost vytváˇreného oddílu v MB pomocí volby –size=velikost, tato volba se ale jevila nefunkˇcní, bylo možné zapsat i vˇetší množství dat než byla velikost oddílu.
17
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ ./do-osd modprobe objlayoutdriver mount -t nfs4 -o minorversion=1 192.168.1.201:/ \ /mnt/pnfs
2.5
Blokový pˇrístup
2.5.1 Úvod Konfigurace pro pNFS blokový pˇrístup je podobná konfiguraci pro objektový pˇrístup – obˇe využívají pˇrístup k logické jednotce zpˇrístupnˇené iSCSI targetem. Je nutné zajistit blokové zaˇrízení, které bude targetem zpˇrístupnˇeno jako logická jednotka (LUN) pro ukládání dat, dále toto zaˇrízení inicializovat a vytvoˇrit na nˇem oddíly s patˇriˇcným souborovým systémem. Poté muže ˚ být nakonfigurován iSCSI target pro vytvoˇrení nové logické jednotky reprezentující požadované blokové zaˇrízení. MDS vystupuje jednak v roli pNFS serveru a jednak v roli iSCSI klienta, proto je zapotˇrebí se pˇrihlásit na target a vyhledat dané blokové zaˇrízení a to následnˇe pˇripojit jako bˇežné blokové zaˇrízení. Zárovenˇ musí být pˇrípojný bod tohoto zaˇrízení vyexportován pˇres pNFS a musí být spuštˇen démon koordinující metadata pro blokový pˇrístup. Na klientovi je tˇreba, stejnˇe jako na MDS, provést pˇrihlášení na iSCSI target (aby mˇel klient informaci o existenci tohoto úložištˇe a LUN na nˇem) a pˇripojit pNFS export z MDS. Blokový pˇrístup se nepodaˇrilo v kombinaci s pNFS zprovoznit. Následující postup byl konzultován s vývojáˇri a pravdˇepodobnˇe je korektní. Samotná komunikace pˇres iSCSI fungovala, pˇri pˇripojení pNFS exportu klientem ale pNFS server hlásil špatnou identifikaci layoutu, a proto komunikace probíhala pomocí bˇežného NFS pˇres metadata server. Pˇríˇcinu problému se nepodaˇrilo ani s pomocí vývojáˇru˚ zjistit. 2.5.2 iSCSI target Pro kompilaci iSCSI targetu byl požadován balíˇcek libssl-dev; pro práci s targetem balíˇcek tgt. Po stažení a rozbalení bylo pˇristoupeno ke zkompilování nejnovˇejší verze targetu: apt-get install libssl-dev tgt wget http://sourceforge.net/projects/iscsitarget/files\ /iscsitarget/1.4.20/iscsitarget-1.4.20.tar.gz/download
18
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ tar xzvf iscsitarget-1.4.20.tar.gz cd iscsitarget-1.4.20 make && make install Bylo nutné vyˇrešit problém s vytvoˇreným modulem iscsi_trgt.ko, který nebyl pˇri pokusu o zavedení nástrojem depmod nalezen, protože neˇ byl nakopírován do adresáˇre modulu˚ aktuálního jádra. Rešením bylo zavedení modulu pˇríkazem insmod (pˇrípadnˇe úprava systémového skriptu /etc/init.d/iscsitarget pro jeho správné automatické zavedení), nebo zkopírování k ostatním modulum ˚ jádra, vytvoˇrení mapy závislostí a spuštˇení služby iscsitarget: cp /lib/modules/extra/iscsi/iscsi_trgt.ko \ /lib/modules/2.6.33-pnfs/kernel/drivers/scsi/ depmod -ae service iscsitarget start iSCSI target slouží ke zpˇrístupnˇení blokového zaˇrízení pomocí iSCSI. Jako blokové zaˇrízení bˇežnˇe slouží pevný disk, v tomto testovacím pˇrípadˇe byl použit 5GB soubor vytvoˇrený nástrojem dd (díky tomu, že je k souboru pod linuxem možné pˇristupovat jako k blokovému zaˇrízení). Zaˇrízení je tˇreba inicializovat vytvoˇrením GPT signatury. Ta je zapotˇrebí proto, že na disku vytvoˇrí jedineˇcný identifikátor sloužící pro urˇcení konkrétního blokového zaˇrízení v iSCSI; vytvoˇrení signatury lze provést napˇríklad nástrojem parted. Lze jím i vytvoˇrit oddíl (v tomto pˇrípadˇe s názvem data typu ext2 7 zaujímající 100 % místa): mkdir /pnfs-block && cd /pnfs-block dd if=/dev/zero of=disk.img bs=1G seek=5 count=0 parted disk.img mklabel gpt parted disk.img mkpart data ext2 0% 100% V dalším kroku byl vytvoˇren nový target s ID 1 a jménem ds a v rámci nˇej logická jednotka 1 reprezentující blokové zaˇrízení (soubor obrazu disku). K tomuto targetu byl povolen pˇrístup ze všech iniciátoru: ˚ tgtadm --tid 1 tgtadm --tid 1
--lld iscsi --op new --mode target \ --targetname ds --lld iscsi --mode logicalunit --op new \ --lun 1 --backing-store /pnfs-block/disk.img
7. Souborový systém ext2 je vytvoˇren jen proto, že nástroj parted novˇejší souborové systémy typu ext nepodporuje, což ale nebrání vytvoˇrení souborového systému ext3 v další fázi.
19
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚ tgtadm --lld iscsi --mode target --op bind \ --tid 1 --initiator-address ALL tgtadm --lld iscsi --mode target --op show 2.5.3 MDS Na MDS je potˇreba mít nainstalovaný iSCSI iniciátor, pomocí kterého se provede pˇrihlášení na target. iscsiadm -m discovery -t sendtargets -p 192.168.1.200 \ --login Dále bylo zapotˇrebí vytvoˇrit na vzniklém zaˇrízení /dev/sda1 souborový systém ext3. mkfs.ext3 -b 4096 /dev/sda1 Stejnˇe jako v pˇredchozích pˇrípadech musela být upravena konfigurace NFS serveru a exportován adresáˇr sloužící pro pNFS pˇrístup. /export *(rw,fsid=0,insecure,no_root_squash,sync, no_subtree_check,pnfs) Posledním krokem na MDS serveru bylo stažení rˇ ídicího blokového démona ctl a jeho kompilace a spuštˇení. git clone git://git.linux-nfs.org/projects/rmcneal/\ ctl.git cd ctl make ./ctl 2.5.4 Klient Na klientovi je tˇreba stejnˇe jako na MDS pˇrihlásit se na iSCSI target a poté pˇripojit pNFS export z MDS. iscsiadm -m discovery -t sendtargets -p 192.168.1.200 \ --login mount -t nfs4 -o minorversion=1 192.168.1.202:/ \ /mnt/pnfs
20
2. I NSTALACE JEDNOTLIVÝCH SERVER U˚
2.6
PVFS
Instalace a konfigurace PVFS+pNFS mˇela být provedena podle [13]. Hned na poˇcátku se vyskytly podstatné problémy pˇri kompilaci. Po konzultaci s vývojáˇri na mailing listu PVFS se ukázalo, že dostupné zdrojové kódy PVFS obsahují zastaralou cˇ ást pro podporu pNFS, která se už podstatnou dobu nevyvíjí. Ze soukromé korespondence s jedním z vývojáˇru˚ (Benjaminem Allanem) vyplývá, že aktualizace pNFS podpory v PVFS tak, aby byla možná kompilace s aktuálními jádry, by byla velmi nároˇcná. Pravdˇepodobnˇe by v takovém pˇrípadˇe bylo schudnˇ ˚ ejší celou podporu pNFS napsat od základu znova. Navíc puvodní ˚ autor pNFS/PVFS (Dean Hildebrand) toto rˇ ešení nepovažuje za perspektivní a nehodlá je dále podporovat. Z výše uvedených duvod ˚ u˚ nebyl PVFS pˇrístup otestován – samotné zprovoznˇení nebylo schudné ˚ a PVFS pˇrístup v pNFS se jeví jako neperspektivní.
21
3 Problémy spojené s pNFS PNFS je novým protokolem (dokument RFC 5661 [5] byl schválen v lednu 2010), jehož implementace se neustále vyvíjí. Proto jsou v urˇcitých pˇrípadech (zejména u iSCSI targetu a iniciátoru) potˇrebné nové verze knihoven, které mohou být experimentální nebo nedostateˇcnˇe vyzkoušené. To komplikuje nebo i vyluˇcuje instalaci pNFS komponent ve stabilním prostˇredí. Protože vývoj pNFS nástroju˚ stále probíhá, obsahují ruzné ˚ nedostatky. ∙
Pˇri konfiguraci metadata serveru a datového serveru na jednom stroji se po pˇripojení exportu klientem vše zdálo být funkˇcní, nicménˇe pˇri pokusu o zápis do exportovaného svazku pˇrestala zapisující aplikace reagovat. V nˇekterých pˇrípadech nebylo poté možné stroj korektnˇe vypnout nebo restartovat a musel být vypnut externˇe (tato situace se týkala zejména testování na virtuálních strojích s Debian linuxem 4).
∙
Stejný problém se objevil na klientovi v pˇrípadˇe, kdy datový a metadata server byly vypnuty, aniž by klient pˇredtím odpojil sdílený svazek exportovaný metadata serverem. Vyskytoval se rovnˇež i pˇri použití objektového pˇrístupu, pokud pˇred vypnutím/restartem klienta nebylo provedeno odhlášení z targetu.
∙
Další nedostatek nesouvisel pˇrímo s pNFS, ale s OSD úložištˇem. Pˇri vytváˇrení souborového systému na logické jednotce zpˇrístupnˇené targetem byla stanovena jeho kapacita, nicménˇe bylo možné zapsat i vˇetší množství dat, než byla stanovená mez (jak bylo zmínˇeno v 2.4.3).
∙
Pro automatické spouštˇení NFS serveru v novˇe zkompilované verzi systémovým skriptem /etc/init.d/nfs-kernel-server musel být skript upraven (uvedeno v 2.2, protože nedetekoval pˇrítomnost podpory NFS v jádˇre.
∙
Pˇri pokusu o zprovoznˇení pNFS s blokovým pˇrístupem oznamoval server klientovi podporu pNFS layoutu typu 0, tedy žádnou pNFS podporu, pˇrestože bylo prostˇredí nastaveno pro blokový pNFS pˇrístup dle kapitoly 2.5.1. Pˇríˇcina problému nebyla zjištˇena ani po konzultaci s vývojáˇri.
∙
Problém pˇrímo nesouvisející s pNFS se vyskytl pˇri instalaci, respektive spuštˇení démona rpc.mountd z novˇe zkompilovaných nástroju˚ nfs-utils. Démon se nespustil automaticky a pˇri ruˇcním spuštˇení
22
3. P ROBLÉMY SPOJENÉ S P NFS hlásil chybu unable to register (mountd, 1, udp) související se službou portmapper implementovanou démonem portmap, konkrétnˇe s absencí podpory IPv6 u tohoto démona. Jeho nahrazení démonem rpcbind problém vyˇrešilo.
23
4 Testování výkonu pNFS PNFS se podaˇrilo zprovoznit jen na testovací sestavˇe, která sloužila pouze k seznámení s prostˇredím pNFS a jeho nastavením. Jednalo se o tˇri poˇcítaˇce s následujícími konfiguracemi: ∙
DS: Intel Celeron 1,7 GHz, 512 MB RAM DDR-266, 80GB disk Maxtor ATA 133, sít’ová karta 3Com 940
∙
Klient: Intel Pentium 4 2,4 GHz, 512 MB RAM DDR-400, 20GB disk Maxtor ATA 100, sít’ová karta Intel EtherExpress/1000
∙
MDS: Intel Pentium M 1,6 GHz, 1024 MB RAM DDR-400, 160GB disk WD ATA 100, sít’ová karta Realtek 8139C
Všechny stroje byly propojeny Fast ethernetem, takže jejich výkon byl dostateˇcný na plnou saturaci pˇrenosové kapacity sítˇe. Rychlosti pˇrenosu se blížily teoretickému maximu 100 Mb/s, pˇribližnˇe v rozmezí 11,5-11,9 MB/s. V dané konfiguraci navíc nebylo možné vyzkoušet vliv pNFS, a to nejen z duvodu ˚ kapacity sítˇe, ale i z duvodu ˚ nefunkˇcnosti MDS a DS na jednom stroji. Z tˇechto duvod ˚ u˚ nelze posoudit míru škálovatelnosti a nárust ˚ výkonu pNFS oproti NFS.
24
5 Podpora IPv6, Kerberos V souˇcasné dobˇe je protokol IPv6 podporován protokolem NFSv4. V pNFS není tento protokol zatím použitelný, protože klienti neumožnují ˇ uložení IPv6 adresy do vyrovnávací pamˇeti pro DS [14]. Jeho podpora je do budoucna plánována, avšak zatím má oproti jiným vlastnostem nižší prioritu. U objektového pˇrístupu není možné protokol IPv6 použít, protože není aktuálnˇe implementován na stranˇe úložištˇe OSC OSD, konkrétnˇe v démonovi tgtd [15]. Funkˇcnost Kerberos autentizace mˇela být testována na pˇridˇelených virtuálních strojích za využití stávající Kerberos infrastruktury. Protože se však nepodaˇrilo na tˇechto strojích pNFS zprovoznit, nemohla být autentizace otestována.
25
6 Závˇer Pˇri instalaci a konfiguraci uvedených pˇrístupu˚ pNFS se ukázalo, že mohou nastat ruzné ˚ problémy, jejichž vyˇrešení je cˇ asovˇe nároˇcné a nˇekdy i po konzultaci s vývojáˇri neschudné. ˚ Jedná se o sadu nástroju, ˚ které jsou v neustálém vývoji, a proto jsou cˇ asto vyžadovány nové komponenty systému (zejména knihovny). To ovšem muže ˚ být nesluˇcitelné s použitím v prostˇredí, kde je vyžadována pouze ovˇerˇ ená a stabilní programová výbava. Mimo to se linuxová implementace pNFS vyznaˇcuje za urˇcitých situací nestabilitou nebo nemožností zaruˇcit funkˇcnost implementovaných vlastností. Také blokový pNFS pˇrístup, jehož implementace je oproti ostatním pˇrístupum ˚ nejpokroˇcilejší, trpí uvedenými neduhy. Další nevýhodou je absence podpory protokolu IPv6, který bude pravdˇepodobnˇe v budoucnu nutnou prerekvizitou prakticky pro všechny programy komunikující v prostˇredí internetu. Vzhledem k experimentální podobˇe implementace pNFS je patrné i chybˇející zaˇclenˇení do operaˇcního systému, napˇríklad skripty pro ovládání všech služeb souvisejících s pNFS a jejich snadná konfigurace nebo dostupnost balíˇcku˚ pro jednoduchou instalaci. V této fázi vývoje toto však nelze brát jako závažný nedostatek. Z dˇríve uvedených duvod ˚ u˚ nemohly být provedeny požadované testy výkonu a škálovatelnosti pNFS. Protože se jedná o implementaci, která má nedostatky a nelze ji považovat za stabilní, rozhodnˇe lze uvažovat o její aplikaci pouze v experimetnálních oblastech. S pokraˇcujícím vývojem se bude pravdˇepodobnˇe situace zlepšovat a poté bude možné jednoznaˇcnˇe konstatovat, zda je pNFS oproti bˇežnému NFS významnˇe výkonnˇejší, pˇrípadnˇe v jakých oblastech je výhodné tuto technologii použít a v jakých nikoliv.
26
Literatura [1] STERN, Hal; EISLER, Mike; LABIAGA, Ricardo. Managing NFS and NIS. Second Edition. USA : O’Reilly Media, 2001. Chapter 11: File Locking. Dostupné z WWW:
. ISBN 1-56592-510-6. [2] NOWICKY, Bill. RFC 1094. NFS: Network File System protocol specification. USA: Sun Microsystems, Inc., 1989-04. 27 s. Dostupné z WWW: . [3] CALLAGHAN, Brent; PAWLOWSKI, Brian; STAUBACH, Peter. RFC 1813. NFS Version 3 Protocol Specification. USA: Sun Microsystems, Inc.; Network Appliance Corp., 1995-06. 126 s. Dostupné z WWW: . [4] SHEPLER, Spencer et al. RFC 3530. Network File System (NFS) version 4 Protocol. USA: Sun Microsystems, Inc.; Hummingbird Ltd.; Network Appliance, 2003-04. 275 s. Dostupné z WWW: . [5] SHEPLER, Spencer et al. RFC 5661. Network File System (NFS) Version 4 Minor Version 1 Protocol. USA: Storspeed, Inc.; NetApp, 2010-01. 617 s. Dostupné z WWW: . [6] HILDEBRAND, Dean. CITI: pNFS. USA: University of Michigan. CITI. c2009 [cit. 2010-05-02]. Dostupné z WWW: . [7] HALEVY, Benny et al. RFC 5664. Object-Based Parallel NFS (pNFS) Operations. USA: Panasas, Inc., 2010-01. 35 s. Dostupné z WWW: . [8] BLACK, David L. et al. RFC 5663. Parallel NFS (pNFS) Block/Volume Layout. USA: EMC Corporation; Nasuni Inc; Google, 2010-01. 28 s. Dostupné z WWW: . [9] ADAMSON, William A. Naming convention for pNFS client code. In PNFS mailing list. c2010 [cit. 2010-04-12]. Dostupné z WWW: . 27
ˇ 6. Z ÁV ER
[10] HALEVY, Benny. Block layout not working (server sends bad layout id?). In PNFS mailing list. c2010 [cit. 2010-04-22]. Dostupné z WWW: . [11] HARROSH, Boaz. OSC software OSD implementation, c2008 [cit. 2010-04-15]. Dostupné z WWW: . [12] HARROSH, Boaz. [osd-dev] Using exofs with pNFS?. In osddev mailing list. c2009 [cit. 2010-04-15]. Dostupné z WWW: . [13] HILDEBRAND, Dean. pNFS/PVFS2 Documentation. Linux pNFS/PVFS2 Installation Instructions. USA: University of Michigan. CITI. c2009 [cit. 2010-04-14]. Dostupné z WWW: . [14] ADAMSON, Andy. IPv6 support in pNFS. In Linux NFS. c2010 [cit. 201005-15]. Dostupné z WWW: . [15] HARROSH, Boaz. pNFS-related questions. In Linux NFS. c2010 [cit. 2010-05-15]. Dostupné z WWW: . [16] Wikipedia, The Free Encyclopedia: Network File System (Protocol) [online], c2010 [cit. 2010-04-13]. Dostupné z WWW: . [17] Network Appliance Inc. Soubor spnfs.txt, c2007 [cit. 2010-04-12]. Souˇcást pNFS patche linuxového jádra, po aplikování dostupné v Documentation/filesystems/spnfs.txt. [18] Network Appliance Inc. Konfiguraˇcní soubor spnfsd.conf, c2007 [cit. 2010-04-12]. Souˇcást zdrojových kódu˚ nástroju˚ pnfs-nfs-utils.
28
