DISTRIBUOVANÉ DATOVÉ SKLADY A PROTOKOL IBP

Transkript

1 DISTRIBUOVANÉ DATOVÉ SKLADY A PROTOKOL IBP Lukáš Hejtmánek, Petr Holub, and Luděk Matyska Fakulta informatiky a Ústav výpočetní techniky, Masarykova univerzita v Brně, Botanická 68a, Brno, Czech Republic CESNET z. s. p. o., Zikova 4, Praha 6 xhejtman@mail.muni.cz, {hopet,ludek}@ics.muni.cz Vysokorychlostní sítě přestávají být mediem, odpovědným pouze za přenos dat z jednoho bodu do druhého, ale zahrnují rostoucí počet nových služeb, umožňujících efektivní vzdálenou spolupráci a sdílení prostředků. Mezi nevýznamnější patří internetová telefonie, videokonference, sdílení aplikací, výpočetních a datových zdrojů (tzv. gridová prostředí či Gridy [1]). Tento článek je věnován netradičnímu přístupu k jedná ze zmíněných oblastí sdílení datových zdrojů v prostředí Internetu formou sdílených datových úložišt postavených na protokolu IBP (Internet Backplane Protocol) [2]. Popisovaný systém byl vybudován v rámci akademického projektu Distribuovaných datových skladů DiDaS 1 [3]. 1 Distribuované ukládání dat Tradiční řešení pro velkokapacitní ukládání dat v sít ovém prostředí je zpravidla postaveno na jednom z následujících přístupů (nebo na jejich kombinaci): Network Attached Storage (NAS) a pro rozsáhlejší systémy pak Storage Area Networks (SAN). NAS bývá obvykle jedno zařízení pro ukládání dat, které je připojeno přímo k síti a nikoli k jednomu či více konkrétním počítačům. Typicky sestává z diskového pole ovládaného serverem, který je připojen k síti. Může jít bud o generické řešení, kdy je na serveru instalován běžný operační systém (se speciálními aplikacemi pro obsluhu NAS vystavené diskové kapacity), případně může jít o specializované proprietární řešení. V poslední době se jako servery v rostoucí míře používají servery na bázi procesorů Intel,které v kombinaci s RAID poli poskytují poměrně levná a současně robustní řešení pro NAS. Klientské počítače přistupují k NAS uloženým datům prostřednictvím některého z běžných sít ových systémů souborů, např. NFS, Windows SMB, či AFS. SAN přístup naproti tomu nabízí rozhraní pro přímou manipulaci s bloky dat. Klientské počítače komunikují s diskovými systémy zpravidla prostřednictvím dedikované sítě, postavené na protokolu FiberChannel, v poslední době však roste zájem i o zpřístupnění prostřednictvím IP sítě, kde hlavním reprezentantem je protokol iscsi. Každý klient pracuje se SAN disky jako by se jednalo o jeho lokální diskové zařízení, modifikované bloky dat mohou však být okamžitě viditelné na všech klientech. Aby bylo v takovém případě dosaženo synchronizace dat (tj. aby si jednotliví klienti data vzájemně nepřepisovali), je třeba použít odpovídající systémy souborů jako je GFS [4] či CXFS [5]. Oba uvedené přístupy jsou určeny primárně pro konsolidaci ukládání dat v rámci výpočetního centra. Použití sítě FiberChannel pro SAN řešení je extrémně drahé, je nutné zajistit samostatné vedení optických kabelů a dosah se měří nejvíce na desítky kilometrů (vhodné např. pro synchronizaci se záložním úložištěm). Protokol iscsi, stejně jako FiberChannel over IP sítě teoreticky 1

2 umožňují přenos diskových instrukcí i přes sít Internet, použití na větší vzdálenosti je však stále ve vývoji (a je zatím nejasné, zda propojení těchto přístupů spojuje to lepší nebo spíše to horší z obou tedy cenu FiberChannel s nezaručenou kvalitou přenosu přes IP sítě). NAS systémy sice používají přímo IP sítě a nevyžadují vlastní infrastrukturu, nejčastěji používané sít ové systémy souborů jsou však rovněž určeny primárně pro použití v rámci organizace (za zmínku stojí zejména otázka autentizace a případně zabezpečení dat při přenosu). Ani jeden ze systémů konsolidace úložných kapacit není primárně určen do prostředí Internetu. Přes pokračující experimenty s jejich nasazením V tomto prostředí je zřejmé, že nedostatky by nejlépe odstranil přístup, který bude brát do úvahy vlastnosti Internetu (nezaručená služba s proměnlivou rychlostí přenosu dat; naopak není třeba již nadále uvažovat s menší kapacitou páteřních přenosových linek) a který se je pokusí kompenzovat pomocí vhodně navrženého protokolu. Jedno z možných řešení představuje Internet Backplane Protocol, na němž je postaven projekt DiDaS. 2 DiDaS V rámci spolupráce Ústavu výpočetní techniky Masarykovy univerzity v Brně 2 a sdružení CES- NET 3 vznikl projekt DiDaS s cílem experimentálně vyzkoušet nové přístupy k ukládání dat v prostředí sítě Internet a současně poskytnout akademické komunitě úložný prostor pro výzkumné a výukové účely. Záměrem bylo poskytovat velkou kapacitu (více než 10 TB) a vysokou propustnost celého systému, nikoli však nutně jednotlivých prvků. Dalším cílem byl výzkum spolehlivosti v prostředí postaveném z principiálně nespolehlivých prvků (jednotlivé úložné uzly plus Internet). To umožňuje budovat velkokapacitní úložný systém z relativně levných komponent. Základem hardwarové infrastruktury je deset uzlů. Každý je tvořen serverem s architekturou IA-32 doplněným o výkonné řadiče diskových polí a příslušný počet disků tak, aby kapacita každého uzlu byla cca 1.5 TB. Pro připojení disků jsou až na jednu výjimku použita rozhraní Parallel ATA nebo Serial ATA. Jeden server, který poskytuje prostor pro ukládání metadat (viz níže) všem ostatním serverům, má diskové pole ze SCSI disků, které má sice menší kapacitu, ale výrazně vyšší propustnost. Každý z uzlů je připojen pomocí gigabitového Ethernetu k páteřní síti CESNET, která má na páteřních spojích kapacitu 2,5 až 10 Gb/s. Na strojích je provozován operační systém Linux, v současné době s jádrem z řady IBP Softwarová vrstva Internet Backplane Protocol (IBP), která všechny uzly infrastruktury DiDaSu integruje a umožňuje s nimi pracovat jako s datovými sklady, pochází z University of Tennessee, Knoxwille z laboratoře Logistical Computing and Internetworking (LoCI) 4. Podobně, jako je IP protokol abstrakcí přenosu dat nad potenciálně heterogenní linkovou vrstvou využívající pro transport přenosovou jednotku ve formě paketu, je IBP abstrakcí pro ukládání dat nad potenciálně heterogenními datovými sklady (data depots). IBP jako atomickou jednotku ukládání používá tzv. pole bytů (byte array). Analogicky k chování IP protokolu jako nezajištěné služby typu best-effort (tj. pakety se při průchodu sítí mohou ztratit, přeuspořádat nebo mohou být poškozeny), nad níž je nutné budovat spolehlivé chování pomocí dalších protokolů (např. TCP), IBP používá slabý model konzistence a dostupnosti dat, který také neposkytuje 100 % garanci. V rozsáhlých počítačových sítích totiž není možné garantovat trvalou dostupnost všech uzlů a tím pádem i všech dat na nich uložených. Robustnost, tedy dostupnost dat i v případě výpadku je pak možno zvyšovat vytvářením

3 kopií a požadované úrovni zabezpečení pak odpovídá počet kopií. Zvyšováním počtu kopií se obvykle nezvyšuje pouze robustnost, ale také propustnost systému, zejména při vícenásobném přístupu k datům (více klientů čtoucích stejná data ve stejný okamžik může používat různé kopie ale i přístup jednoho klienta k rozsáhlejším datům může využít toho, že různé části souboru se paralelně čtou z různých kopií). IBP navíc počítá také s režimem dočasného uložení dat, po jehož expiraci může úložiště data smazat. IBP je vlastně rodina protokolů uspořádaných do vrstev (analogie sít ových protokolů). Na nejnižší úrovni je transportní protokol IBP sloužící k samotnému ukládání dat do jednotlivých IBP skladů (depotů). Další vrstvou je L-Bone, jež umožňuje organizovat jednotlivé IBP sklady do jednotné infrastruktury, ze které je možné servery vybírat na základě různých kriterií. Vlastní data jsou při ukládání rozdělena na bloky, jejichž organizaci má na starosti vrstva metadat zvaná ExNode, která je paralelní k vrstvě L-Bone. Informace o blocích alokovaných pro daný soubor jsou v rámci vrstvy ExNode reprezentovány jako XML struktura, která se neukládá současně s daty (analogie FAT či I-node struktur používaných na fyzických discích). Nad vrstvami L-Bone a ExNode je vrstva LoRS, poskytující nástroje pro ukládání a stahování dat a jejich management. LoRS vrstva navíc skrývá jednotlivé sklady a poskytuje abstrakci uniformního prostoru pro ukládání dat. 3.1 Transportní a ukládací protokol IBP Základním režimem práce nejnižší vrstvy IBP infrastruktury je alokace polí bytů, které mohou mít následující charakteristiky: permanentní vs. časově omezené alokace: specifikuje, zda má být alokace trvalá, či zda může být serverem smazána po uplynutí časové lhůty, stabilní vs. volatilní alokace: udává, zda daná alokace musí být serverem držena po celou požadovanou dobu alokace, nebo zda může být kdykoli smazána, pole bytů, do něhož lze pouze přidávat (t.j. nelze přepisovat přepsání vznikne vytvořením nového souboru, který část dat sdílí se souborem původním a,,přepsané datové bloky jsou nově alokovány). Každý IBP depot inzeruje pomocí L-Bone vrstvy volnou kapacitu a jeho správce může stanovit, jaké alokace jsou na daném depotu povoleny: může například specifikovat, že jsou povoleny pouze stabilní časově omezené alokace kratší než 10 dní a současně také permanentní volatilní. Pokud se klient pokusí vyžádat na daném depotu alokaci, která nesplňuje stanovená kritéria (v našem případě třeba stabilní permanentní alokaci), bude jeho požadavek depotem zamítnut. Tento přístup umožňuje například dát k dipozici do IBP infrastruktury volnou diskovou kapacitu na koncových stanicích v dané síti s tím, že tato smí být používána pouze pro volatilní alokace to umožňuje IBP infrastruktuře vytvářet dočasné repliky, které slouží ke zvýšení výkonu při čtení dat, pokud jsou již dedikované servery (s permanentními kopiemi) plně vytíženy. Na druhou stranu takové alokace nijak neomezují uživatele dané koncové stanice, který může kdykoli požádat IBP sever o uvolnění kapacity. IBP protokol poskytuje API nejen pro zápis a čtení dat z depotů, ale také nabízí možnost klientem vyžádaného přesunu dat přímo mezi dvěma depoty, aniž by data tekla přes klienta. Tento postup umožňuje efektivní replikaci dat uvnitř IBP infrastruktury a minimalizuje datové toky na koncových stanicích, které jsou z pohledu sít ové infrastruktury velmi často nejslabším článkem řetězce. Parametry a atributy alokací lze postupně měnit a upravovat po celou dobu jejich existence. Klient může například prodlužovat či zkracovat čas expirace, zvyšovat či snižovat počet redundant-

4 ních kopií nebo přialokovávat další bloky. Takové požadavky však mohou být zamítnuty, pokud neexistují žádné depoty, které by nabízely alokace s nově požadovanými parametry. 3.2 ExNode a L-Bone Primárním úkolem vrstvy ExNode je popis jednotlivých alokací, které náleží danému souboru. Pomocí XML je v ExNode metadatech popsáno, který blok na kterém IBP depotu odpovídá kterému kusu dat z původního souboru. Jde o obdobu I-node z operačního systému typu UNIX s tím rozdílem, že bloky nemusí mít jednotnou velikost, mohou se překrývat nebo může více bloků odpovídat stejnému kusu dat původního souboru. Tím je zajištěna podpora redundance dat na úrovni datových bloků. Kromě popisu alokací mohou metadata obsahovat informace o kontrolních součtech (IBP počítá s nespolehlivostí infrastruktury, nad níž pracuje) či klíče pro šifrování dat (úložná infrastruktura nemusí být důvěryhodná a sám uživatel si může rozhodnout, zda svá data bude do infrastruktury ukládat šifrovaně či nikoli). Data mohou být navíc při ukládání i komprimována pomocí algoritmu implementovaného v knihovně libz. Metadata jsou při ukládání souboru do IBP zapisována jako lokální soubor a tedy samotný správce IBP serveru neví, jaká data jsou na jeho depotu uložena, pokud současně nemá přístup k metadatům. L-Bone vrstva má za úkol sdružovat IBP depoty do jednotné infrastruktury, v níž je možné vyhledávat dle specifikovaných vlastností, například depot nejbližší k vyhledávajícímu klientovi. L- Bone server v pravidelných intervalech ověřuje dostupnost jednotlivých IBP depotů, je tak schopen nabízet jen dostupné depoty pro ukládání a určit, které alokace jsou dostupné. V případě, že ExNode obsahuje redundantní alokace, L-Bone vrstva dokáže ohodnotit jednotlivé kopie bloku podle dostupnosti. Samozřejmě je možné přenášet data z/do více lokací najednou, at už redundantně tatáž data pro zvýšení robustnosti, nebo více různých datových bloků souběžně pro dosažení vyššího výkonu. Z pohledu současné implementace se využívá vrstva L-Bone adresářových služeb LDAP, kde se musí každý IBP server registrovat. 3.3 LoRS Vrstva logistických nástrojů nazývaná LoRS je vybudována nad vrstvami L-Bone a ExNode. Poskytuje nástroje a API pro čtení, zapisování a přepisování dat v IBP infrastruktuře. Tato vrstva poskytuje také nastroje pro práci s XML reprezentací metadat jako s lokálními soubory. 4 Rozvoj IBP přístupu Nasazení IBP jako základního middleware pro distribuované ukládání dat však s sebou přineslo dvě základní komplikace: (1) nutnost adaptovat aplikace, pokud potřebují přímo pracovat s IBP, a (2) vhodný robustní režim ukládání metadat, který ochrání před chybami uživatelů (smazání jediné, u uživatele uložené kopie metadat) a současně deanonymizuje data (bez přístupu k metadatům nelze zjistit, jaká data jsou uložena). Pro usnadnění přístupu aplikací k IBP jsme implementovali knihovnu libxio [6], která poskytuje aplikacím API rozhraní POSIXového typu a umožňuje přístup jak k lokálním souborům, tak i datům uloženým na IBP depotech. Díky tomu je možné nahradit v již existující aplikaci standardní POSIXová volání funkcemi z této knihovny beze ztráty schopnosti aplikace přistupovat k lokálním souborům běžným způsobem. Knihovna je implementována v jazyce C a je vysoce portabilní. Pro zcela transparentní přístup k IBP datům jsme zvolili jejich vystavení formou virtuálního systému souborů (aplikace v tomto případě vůbec netuší, že pracuje s daty uloženými na IBP depotech). Implementovali jsme lokální systém souborů pro Linux [7] s využitím projektu Linux

5 Userland File System (LUFS) [8]. Takto připojený systém souborů, který samotná data ukládá na IBP a metadata ukládá do sdíleného systému souborů, v našem případě OpenAFS [9], poskytuje transparentní přístup k datům na IBP i aplikacím, které nemohou být modifikovány pro použití knihovny libxio. Implementace poskytuje vysoký výkon při sekvenčním přístupu, má však vyšší latenci než přístup pomocí knihovny libxio při otevírání souboru a náhodném přístupu. IBP nepodporuje přímé přepisování již alokovaných bloků dat, což nám umožnilo elegantním způsobem implementovat verzování souborů a adresářů do tohoto systému souborů uživatel tak může přistupovat nejen k poslední verzi souboru, ale také k verzím předešlým, které by na běžném systému souborů již nebyly dostupné (byly přepsány). Tuto zásadní vlastnost již delší dobu využívají zejména vývojáři programového vybavení, kteří rutinně používají systémy jako CVS [10], SubVersion [11], či Microsoft SourceSafe [12], jejímu širšímu nasazení pro běžné uživatele však zatím brání především to, že není běžně implementována v souborových systémech a její použití vyžaduje jisté dodatečné úsilí. Naše implementace je prototypem systému, jenž by mohl tento stav změnit k lepšímu. Problém robustní, perzistentní a výkonné implementace ukládání ExNode metadat je jedním ze základních výzkumných problémů, na nichž plánujeme pracovat v budoucnu. V současné době data ukládáme bud na sdílený systém souborů AFS (v případě implementace lokálního systému souborů pomocí LUFS), nebo nabízíme uživateli možnost ukládat metadata pomocí webového rozhraní na diskový prostor, který je v rámci DiDaSové infrastruktury sdílen z jednoho depotu pomocí sít ového systému souborů NFS. Uživatel zatím může metadata ukládat také pouze lokálně na svůj počítač, pokud použije nástroje LoRS či aplikaci, která s IBP spolupracuje pomocí knihovny libxio. 5 Aplikace Pomocí knihovny libxio jsme implementovali podporu pro IBP do řady různých, zejména multimediálních aplikací, jako je Mplayer (linuxový přehrávač videa) či transcode (nástroj pro překódovávání multimediálních materiálů mezi různými formáty). Nad nástrojem transcode jsme vybudovali distribuované prostředí pro kódování videa Distributed Encoding Envirionment (DEE) [13], které je nyní nasazeno v produkčním režimu pro zpracování videozáznamů přednášek na Fakultě informatiky Masarykovy univerzity v Brně. Jednou z nových aplikací projektu DiDaS je práce s archivy velkých obrázků, jako jsou záznamy historických map či data v lékařských atlasech, kde se běžně pracuje s obrazy, které po kompresi mají stále velikost stovek megabytů. Pro efektivní práci s tímto typem dat jsme vyvinuli vlastní formát komprese Tiled Map File (TMF) podobný formátu JPEG, který umožňuje efektivní zoomování a posouvání v obraze, aniž by se musel číst a dekomprimovat celý soubor. Pro tento formát jsme implementovali v jazyce C konvertor z běžných formátů jako JPEG, GIF či PNG, který je možné provozovat pod operačními systémy UN*X/Linux a Microsoft Windows. Data uložená na IBP v TMF formátu je možno prohlížet pomocí prohlížeče implementovaném v platformně nezávislém jazyce Java, který pracuje pod všemi běžně dostupnými operačními systémy. Přímá práce s IBP je možná pomocí nástrojů LoRS Tools, které jsou dodávány přímo v rámci projektu IBP pro řadu různých platforem. Protože však tyto nástroje vykazují problémy při práci se soubory většími než 2 GB, vytvořili jsme vlastní portabilní implementaci v jazyce Java nazvanou JavaLors [14], která poskytuje jednoduché a intuitivní rozhraní pro běžné koncové uživatele bez omezení velikosti souborů. Pro uživatele, kteří z různých důvodů at již psychologických či technických nemohou používat aplikace s přímou podporou IBP, JavaLors či implementaci IBP jako lokálního systému souborů, nabízíme ukládání dat do infrastruktury DiDaSu pomocí webového rozhraní. Přes toto rozhraní je možné soubory nahrávat, stahovat, vypisovat jejich seznamy, mazat a přejmenová-

6 vat. Webové rozhraní je podobně jako samotné IBP plně redundantní, tj. na každém depotu běží web server a uživatel je automaticky v případě výpadku přesměrováván na jiný depot. Pomocí protokolu HTTPS je možné bezpečně přistupovat k celé infrastruktuře bez nároků na jakékoli speciální vybavení. 6 Srovnání přístupů Přístup projektu DiDaS můžeme charakterizovat jako řešení integrující sklady typu NAS do jednoho velkého datového prostoru s řadou nových vlastností, které jednotlivé uzly postrádají: vysoký výkon infrastruktury zejména při čtení dat (jeden klient s gigabitovým připojením může běžně číst jeden soubor rychlostí přes 400 Mb/s), jednotlivé uzly úložné infrastruktury mohou být levné a nemusí dosahovat mimořádné propustnosti, přesto však infrastruktura jako celek poskytuje vysoký výkon, od začátku se počítá s nespolehlivostí jednotlivých uzlů, pročež systém podporuje zvyšování robustnosti pomocí redundantního ukládání dat, redundance kromě zlepšování robustnosti zvyšuje také rychlost přístupu, umožňuje využít,,volně ležící diskovou kapacitu nededikovaných uzlů v síti (typicky koncové stanice, které dnes mají běžně diskovou kapacitu v řádu 100 GB), při implementaci jako lokální systém souborů podporuje také verzování souborů a adresářů. Uvedené vlastnosti nejsou běžně dostupné ani v komerčních řešeních typu SAN, a to ani při práci s daty v rámci jediného výpočetního centra. 7 Závěr V tomto článku jsme představili netradiční přístup k vytváření distribuovaných datových skladů, který umožňuje velmi levně a efektivně poskytovat velkou úložnou kapacitu. Kromě vysokého výkonu přináší také řadu zajímavých vlastností, jako je nativní podpora replikace dat či podpora verzování souborů. Na rozdíl od komerčně běžně dostupných řešení se jedná o plně otevřený vývojový systém, který nemusí být vhodný pro běžného uživatele k produkčnímu nasazení, ale který předznačuje potenciální směry vývoje distribuovaného ukládání dat do budoucna. Reference [1] I. Foster, C. Kesselman (Eds). The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, [2] M. Beck, T. Moore, J. S. Planck.,,An End-to-End Approach to Globally Scalable Network Storage, SIGCOMM 02, pdf/sigcomm02p1783-beck.pdf [3] L. Hejtmánek, L. Matyska.,,Distribuované Datové Sklady, Širokopásmové sítě a jejich aplikace, Olomouc, s

7 [4] S. Soltis, G. Erickson, K. Preslan, M. O Keefe, T. Ruwart.,,The Global File System: A File System for Shared Disk Storage, IEEE Transactions on Parallel and Distributed Systems, October [5] L. Shepard, E. Eppe.,,SGI InfiniteStorage Shared Filesystem CXFS: A High-Performance, Multi-OS Filesystem from SGI, SGI, pdf [6] L. Hejtmánek, P. Holub.,,IBP Deployment Tests and Integration with DiDaS Project, Technická zpráva CESNET 20/ /ibpdidas/ [7] M. Karásek. Distribuovaný souborový systém pro Linux, diplomová práce FI MU. Brno, [8] Linux Userland Filesystem. [9] OpenAFS. [10] B. Berliner, J. Polk. Concurrent Versions System (CVS) org [11] B. Collins Sussman, B. W. Fitzpatrick, C. M. Pilato. Version Control with Subversion, [12] Microsoft SourceSafe. ssafe/ [13] P. Holub, L. Hejtmanek.,,Distributed Encoding Environment Based on Grids and IBP Infrastructure, Selected papers from TERENA Networking Conference 2004, Rhodes, Greece, papers/holub.pdf [14] JavaLors, JavaLors.jar