DISTRIBUOVANÉ DATOVÉ SKLADY A PROTOKOL IBP Lukáš Hejtmánek∗‡ , Petr Holub∗†‡ , and Ludˇek Matyska∗†‡ informatiky a † Ústav výpoˇcetní techniky, Masarykova univerzita v Brnˇe, Botanická 68a, 602 00 Brno, Czech Republic ∗ Fakulta
‡ CESNET
z. s. p. o., Zikova 4, 162 00 Praha 6
e-mail:
[email protected], {hopet,ludek}@ics.muni.cz Vysokorychlostní sítˇe pˇrestávají být mediem, odpovˇedným pouze za pˇrenos dat z jednoho bodu do druhého, ale zahrnují rostoucí poˇcet nových služeb, umožnˇ ujících efektivní vzdálenou spolupráci a sdílení prostˇredk˚u. Mezi nevýznamnˇejší patˇrí internetová telefonie, videokonference, sdílení aplikací, výpoˇcetních a datových zdroj˚u (tzv. gridová prostˇredí cˇ i Gridy [1]). Tento cˇ lánek je vˇenován netradiˇcnímu pˇrístupu k jedná ze zmínˇených oblastí – sdílení datových zdroj˚u v prostˇredí 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˚u DiDaS1 [3].
1 Distribuované ukládání dat Tradiˇcní rˇešení pro velkokapacitní ukládání dat v sít’ovém prostˇredí je zpravidla postaveno na jednom z následujících pˇrístup˚u (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ˇrízení pro ukládání dat, které je pˇripojeno pˇrímo k síti a nikoli k jednomu cˇ i více konkrétním poˇcítaˇcu˚ m. Typicky sestává z diskového pole ovládaného serverem, který je pˇripojen k síti. M˚uže jít bud’ o generické ˇrešení, kdy je na serveru instalován bˇežný operaˇcní systém (se speciálními aplikacemi pro obsluhu NAS vystavené diskové kapacity), pˇrípadnˇe m˚uže jít o specializované proprietární ˇrešení. V poslední dobˇe se jako servery v rostoucí míˇre používají servery na bázi procesor˚u Intel,které v kombinaci s RAID poli poskytují pom eˇ rnˇe levná a souˇcasnˇe robustní ˇrešení pro NAS. Klientské poˇcítaˇce pˇristupují k NAS uloženým dat˚um prostˇrednictvím nˇekterého z bˇežných sít’ových systém˚u soubor˚u, napˇr. NFS, Windows SMB, cˇ i AFS. SAN pˇrístup naproti tomu nabízí rozhraní pro pˇrímou manipulaci s bloky dat. Klientské poˇcítaˇce komunikují s diskovými systémy zpravidla prostˇrednictvím dedikované sítˇe, postavené na protokolu FiberChannel, v poslední dobˇe však roste zájem i o zpˇrístupnˇení prostˇrednictvím IP sítˇe, kde hlavním reprezentantem je protokol iSCSI. Každý klient pracuje se SAN disky jako by se jednalo o jeho lokální diskové zaˇrízení, modifikované bloky dat mohou však být okamžit eˇ viditelné na všech klientech. Aby bylo v takovém pˇrípadˇe dosaženo synchronizace dat (tj. aby si jednotliví klienti data vzájemnˇe nepˇrepisovali), je tˇreba použít odpovídající systémy soubor˚u jako je GFS [4] cˇ i CXFS [5]. Oba uvedené pˇrístupy jsou urˇceny primárnˇe pro konsolidaci ukládání dat v rámci výpoˇcetního centra. Použití sítˇe FiberChannel pro SAN ˇrešení je extrémnˇe drahé, je nutné zajistit samostatné vedení optických kabel˚u a dosah se mˇeˇrí nejvíce na desítky kilometr˚u (vhodné napˇr. pro synchronizaci se záložním úložištˇem). Protokol iSCSI, stejnˇe jako FiberChannel over IP sítˇe teoreticky 1
http://undomiel.ics.muni.cz/presentation/
umožˇnují pˇrenos diskových instrukcí i pˇres sít’ Internet, použití na vˇetší vzdálenosti je však stále ve vývoji (a je zatím nejasné, zda propojení tˇechto pˇrístup˚u spojuje to lepší nebo spíše to horší z obou – tedy cenu FiberChannel s nezaruˇcenou kvalitou pˇrenosu pˇres IP sítˇe). NAS systémy sice používají pˇrímo IP sítˇe a nevyžadují vlastní infrastrukturu, nejˇcastˇeji používané sít’ové systémy soubor˚u jsou však rovnˇež urˇceny primárnˇe pro použití v rámci organizace (za zmínku stojí zejména otázka autentizace a pˇrípadnˇe zabezpeˇcení dat pˇri pˇrenosu). Ani jeden ze systém˚u konsolidace úložných kapacit není primárn eˇ urˇcen do prostˇredí Internetu. Pˇres pokraˇcující experimenty s jejich nasazením V tomto prostˇredí je zˇrejmé, že nedostatky by nejlépe odstranil pˇrístup, který bude brát do úvahy vlastnosti Internetu (nezaru cˇ ená služba s promˇenlivou rychlostí pˇrenosu dat; naopak není tˇreba již nadále uvažovat s menší kapacitou páteˇrních pˇrenosových linek) a který se je pokusí kompenzovat pomocí vhodn eˇ navrženého protokolu. Jedno z možných ˇrešení pˇredstavuje Internet Backplane Protocol, na nˇemž je postaven projekt DiDaS.
2 DiDaS V rámci spolupráce Ústavu výpoˇcetní techniky Masarykovy univerzity v Brnˇe2 a sdružení CESNET3 vznikl projekt DiDaS s cílem experimentálnˇe vyzkoušet nové pˇrístupy k ukládání dat v prostˇredí sítˇe Internet a souˇcasnˇe poskytnout akademické komunitˇe úložný prostor pro výzkumné a výukové úˇcely. Zámˇerem bylo poskytovat velkou kapacitu (více než 10 TB) a vysokou propustnost celého systému, nikoli však nutnˇe jednotlivých prvk˚u. Dalším cílem byl výzkum spolehlivosti v prostˇredí postaveném z principiálnˇe nespolehlivých prvk˚u (jednotlivé úložné uzly plus Internet). To umož nˇ uje budovat velkokapacitní úložný systém z relativnˇe levných komponent. Základem hardwarové infrastruktury je deset uzl˚u. Každý je tvoˇren serverem s architekturou IA-32 doplnˇeným o výkonné ˇradiˇce diskových polí a pˇríslušný poˇcet disk˚u tak, aby kapacita každého uzlu byla cca 1.5 TB. Pro pˇripojení disk˚u 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˚um, má diskové pole ze SCSI disk˚u, které má sice menší kapacitu, ale výraznˇe vyšší propustnost. Každý z uzl˚u je pˇripojen pomocí gigabitového Ethernetu k páteˇrní síti CESNET, která má na páteˇrních spojích kapacitu 2,5 až 10 Gb/s. Na strojích je provozován operaˇcní systém Linux, v souˇcasné dobˇe s jádrem z ˇrady 2.6.
3 IBP Softwarová vrstva Internet Backplane Protocol (IBP), která všechny uzly infrastruktury DiDaSu integruje a umožnˇ uje s nimi pracovat jako s datovými sklady, pochází z University of Tennessee, Knoxwille z laboratoˇre Logistical Computing and Internetworking (LoCI) 4 . Podobnˇe, jako je IP protokol abstrakcí pˇrenosu dat nad potenciálnˇe heterogenní linkovou vrstvou využívající pro transport pˇrenosovou jednotku ve formˇe paketu, je IBP abstrakcí pro ukládání dat nad potenciáln eˇ heterogenními datovými sklady (data depots). IBP jako atomickou jednotku ukládání používá tzv. pole byt˚u (byte array). Analogicky k chování IP protokolu jako nezajišt eˇ né služby typu best-effort (tj. pakety se pˇri pr˚uchodu sítí mohou ztratit, pˇreuspoˇrádat nebo mohou být poškozeny), nad níž je nutné budovat spolehlivé chování pomocí dalších protokol˚u (napˇr. TCP), IBP používá slabý model konzistence a dostupnosti dat, který také neposkytuje 100 % garanci. V rozsáhlých po cˇ ítaˇcových sítích totiž není možné garantovat trvalou dostupnost všech uzl˚u a tím pádem i všech dat na nich uložených. Robustnost, tedy dostupnost dat i v pˇrípadˇe výpadku je pak možno zvyšovat vytváˇrením 2
http://www.ics.muni.cz/ http://www.cesnet.cz/ 4 http://loci.cs.utk.edu 3
kopií a požadované úrovni zabezpeˇcení pak odpovídá poˇcet kopií. Zvyšováním poˇctu kopií se obvykle nezvyšuje pouze robustnost, ale také propustnost systému, zejména pˇri vícenásobném pˇrístupu k dat˚um (více klient˚u cˇ toucích stejná data ve stejný okamžik m˚uže používat r˚uzné kopie – ale i pˇrístup jednoho klienta k rozsáhlejším dat˚um m˚uže využít toho, že r˚uzné cˇ ásti souboru se paralelnˇe cˇ tou z r˚uzných kopií). IBP navíc poˇcítá také s režimem doˇcasného uložení dat, po jehož expiraci m˚uže úložištˇe data smazat. IBP je vlastnˇe rodina protokol˚u uspoˇrádaných do vrstev (analogie sít’ových protokol˚u). Na nejnižší úrovni je transportní protokol IBP sloužící k samotnému ukládání dat do jednotlivých IBP sklad˚u (depot˚u). Další vrstvou je L-Bone, jež umož nˇ uje organizovat jednotlivé IBP sklady do jednotné infrastruktury, ze které je možné servery vybírat na základ eˇ r˚uzných kriterií. Vlastní data jsou pˇri ukládání rozdˇelena na bloky, jejichž organizaci má na starosti vrstva metadat zvaná ExNode, která je paralelní k vrstvˇe 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 cˇ asnˇe s daty (analogie FAT cˇ 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˚u, které mohou mít následující charakteristiky: • permanentní vs. cˇ asovˇe omezené alokace: specifikuje, zda má být alokace trvalá, cˇ i zda m˚uže být serverem smazána po uplynutí cˇ asové lh˚uty, • stabilní vs. volatilní alokace: udává, zda daná alokace musí být serverem držena po celou požadovanou dobu alokace, nebo zda m˚uže být kdykoli smazána, • pole byt˚u, do nˇehož lze pouze pˇridávat (t.j. nelze pˇrepisovat – pˇrepsání vznikne vytvoˇrením nového souboru, který cˇ ást dat sdílí se souborem p˚uvodním a ,,pˇrepsané‘‘ datové bloky jsou novˇe alokovány). Každý IBP depot inzeruje pomocí L-Bone vrstvy volnou kapacitu a jeho správce m˚uže stanovit, jaké alokace jsou na daném depotu povoleny: m˚uže napˇríklad specifikovat, že jsou povoleny pouze stabilní cˇ asovˇe omezené alokace kratší než 10 dní a souˇcasnˇe také permanentní volatilní. Pokud se klient pokusí vyžádat na daném depotu alokaci, která nespl nˇ uje stanovená kritéria (v našem pˇrípadˇe tˇreba stabilní permanentní alokaci), bude jeho požadavek depotem zamítnut. Tento pˇrístup umožˇnuje napˇrí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ž nˇ uje IBP infrastruktuˇre vytváˇret doˇcasné repliky, které slouží ke zvýšení výkonu pˇri cˇ tení dat, pokud jsou již dedikované servery (s permanentními kopiemi) pln eˇ vytíženy. Na druhou stranu takové alokace nijak neomezují uživatele dané koncové stanice, který m˚uže kdykoli požádat IBP sever o uvoln eˇ ní kapacity. IBP protokol poskytuje API nejen pro zápis a cˇ tení dat z depot˚u, ale také nabízí možnost klientem vyžádaného pˇresunu dat pˇrímo mezi dvˇema depoty, aniž by data tekla pˇres klienta. Tento postup umožˇnuje efektivní replikaci dat uvnitˇr IBP infrastruktury a minimalizuje datové toky na koncových stanicích, které jsou z pohledu sít’ové infrastruktury velmi cˇ asto nejslabším cˇ lánkem ˇretˇezce. Parametry a atributy alokací lze postupnˇe mˇenit a upravovat po celou dobu jejich existence. Klient m˚uže napˇríklad prodlužovat cˇ i zkracovat cˇ as expirace, zvyšovat cˇ i snižovat poˇcet redundant-
ních kopií nebo pˇrialokovávat další bloky. Takové požadavky však mohou být zamítnuty, pokud neexistují žádné depoty, které by nabízely alokace s nov eˇ 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˚uvodního souboru. Jde o obdobu I-node z opera cˇ ního systému typu UNIX s tím rozdílem, že bloky nemusí mít jednotnou velikost, mohou se pˇrekrývat nebo m˚uže více blok˚u odpovídat stejnému kusu dat p˚uvodního souboru. Tím je zajišt eˇ na podpora redundance dat na úrovni datových blok˚u. Kromˇe popisu alokací mohou metadata obsahovat informace o kontrolních souˇctech (IBP poˇcítá s nespolehlivostí infrastruktury, nad níž pracuje) cˇ i klíˇce pro šifrování dat (úložná infrastruktura nemusí být d˚uvˇeryhodná a sám uživatel si m˚uže rozhodnout, zda svá data bude do infrastruktury ukládat šifrovanˇe cˇ i nikoli). Data mohou být navíc pˇri ukládání i komprimována pomocí algoritmu implementovaného v knihovn eˇ libz. Metadata jsou pˇri 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ˇcasnˇe nemá pˇrístup k metadat˚um. 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ˇríklad depot nejbližší k vyhledávajícímu klientovi. LBone server v pravidelných intervalech ovˇeˇruje dostupnost jednotlivých IBP depot˚u, je tak schopen nabízet jen dostupné depoty pro ukládání a urˇcit, které alokace jsou dostupné. V pˇrípadˇe, že ExNode obsahuje redundantní alokace, L-Bone vrstva dokáže ohodnotit jednotlivé kopie bloku podle dostupnosti. Samozˇrejmˇe je možné pˇrenášet data z/do více lokací najednou, at’ už redundantn eˇ tatáž data pro zvýšení robustnosti, nebo více r˚uzných datových blok˚u soub eˇ žnˇe pro dosažení vyššího výkonu. Z pohledu souˇcasné implementace se využívá vrstva L-Bone adresáˇrových služeb LDAP, kde se musí každý IBP server registrovat.
3.3 LoRS Vrstva logistických nástroj˚u nazývaná LoRS je vybudována nad vrstvami L-Bone a ExNode. Poskytuje nástroje a API pro cˇ tení, zapisování a pˇrepisování dat v IBP infrastruktuˇre. Tato vrstva poskytuje také nastroje pro práci s XML reprezentací metadat jako s lokálními soubory.
4 Rozvoj IBP pˇrístupu Nasazení IBP jako základního middleware pro distribuované ukládání dat však s sebou pˇrineslo dvˇe základní komplikace: (1) nutnost adaptovat aplikace, pokud potˇrebují pˇrímo pracovat s IBP, a (2) vhodný robustní režim ukládání metadat, který ochrání pˇred chybami uživatel˚u (smazání jediné, u uživatele uložené kopie metadat) a souˇcasnˇe deanonymizuje data (bez pˇrístupu k metadat˚um nelze zjistit, jaká data jsou uložena). Pro usnadnˇení pˇrístupu aplikací k IBP jsme implementovali knihovnu libxio [6], která poskytuje aplikacím API rozhraní POSIXového typu a umož nˇ uje pˇrístup jak k lokálním soubor˚um, tak i dat˚um 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ˇristupovat k lokálním soubor˚um bˇežným zp˚usobem. Knihovna je implementována v jazyce C a je vysoce portabilní. Pro zcela transparentní pˇrístup k IBP dat˚um jsme zvolili jejich vystavení formou virtuálního systému soubor˚u (aplikace v tomto pˇrípadˇe v˚ubec netuší, že pracuje s daty uloženými na IBP depotech). Implementovali jsme lokální systém soubor˚u pro Linux [7] s využitím projektu Linux
Userland File System (LUFS) [8]. Takto pˇripojený systém soubor˚u, který samotná data ukládá na IBP a metadata ukládá do sdíleného systému soubor˚u, v našem pˇrípadˇe OpenAFS [9], poskytuje transparentní pˇrístup k dat˚um na IBP i aplikacím, které nemohou být modifikovány pro použití knihovny libxio. Implementace poskytuje vysoký výkon pˇri sekvenˇcním pˇrístupu, má však vyšší latenci než pˇrístup pomocí knihovny libxio pˇri otevírání souboru a náhodném pˇrístupu. IBP nepodporuje pˇrímé pˇrepisování již alokovaných blok˚u dat, což nám umožnilo elegantním zp˚usobem implementovat verzování soubor˚u a adresáˇru˚ do tohoto systému soubor˚u – uživatel tak m˚uže pˇristupovat nejen k poslední verzi souboru, ale také k verzím pˇredešlým, které by na bˇežném systému soubor˚u již nebyly dostupné (byly pˇrepsány). Tuto zásadní vlastnost již delší dobu využívají zejména vývojáˇri programového vybavení, kteˇrí rutinnˇe používají systémy jako CVS [10], SubVersion [11], cˇ i Microsoft SourceSafe [12], jejímu širšímu nasazení pro b eˇ žné uživatele však zatím brání pˇredevším to, že není bˇežnˇe implementována v souborových systémech a její použití vyžaduje jisté dodateˇcné úsilí. Naše implementace je prototypem systému, jenž by mohl tento stav zmˇenit 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˚u, na nichž plánujeme pracovat v budoucnu. V sou cˇ asné dobˇe data ukládáme bud’ na sdílený systém soubor˚u AFS (v pˇrípadˇe implementace lokálního systému soubor˚u 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˚u NFS. Uživatel zatím m˚uže metadata ukládat také pouze lokáln eˇ na sv˚uj poˇcítaˇc, pokud použije nástroje LoRS cˇ i aplikaci, která s IBP spolupracuje pomocí knihovny libxio.
5 Aplikace Pomocí knihovny libxio jsme implementovali podporu pro IBP do ˇrady r˚uzných, zejména multimediálních aplikací, jako je Mplayer (linuxový pˇrehrávaˇc videa) cˇ i transcode (nástroj pro pˇrekódovávání multimediálních materiál˚u mezi r˚uznými formáty). Nad nástrojem transcode jsme vybudovali distribuované prostˇredí pro kódování videa Distributed Encoding Envirionment (DEE) [13], které je nyní nasazeno v produkˇcním režimu pro zpracování videozáznam˚u pˇrednášek na Fakultˇe informatiky Masarykovy univerzity v Brnˇe. Jednou z nových aplikací projektu DiDaS je práce s archivy velkých obrázk˚u, jako jsou záznamy historických map cˇ i data v lékaˇrských atlasech, kde se bˇežnˇe pracuje s obrazy, které po kompresi mají stále velikost stovek megabyt˚u. 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ž nˇ uje efektivní zoomování a posouvání v obraze, aniž by se musel cˇ íst a dekomprimovat celý soubor. Pro tento formát jsme implementovali v jazyce C konvertor z bˇežných formát˚u jako JPEG, GIF cˇ i PNG, který je možné provozovat pod operaˇcní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 cˇ e implementovaném v platformnˇe nezávislém jazyce Java, který pracuje pod všemi bˇežnˇe dostupnými operaˇcními systémy. Pˇrímá práce s IBP je možná pomocí nástroj˚u LoRS Tools, které jsou dodávány pˇrímo v rámci projektu IBP pro ˇradu r˚uzných platforem. Protože však tyto nástroje vykazují problémy pˇri práci se soubory vˇetšími než 2 GB, vytvoˇrili jsme vlastní portabilní implementaci v jazyce Java nazvanou JavaLors [14], která poskytuje jednoduché a intuitivní rozhraní pro b eˇ žné koncové uživatele bez omezení velikosti soubor˚u. Pro uživatele, kteˇrí z r˚uzných d˚uvod˚u – at’ již psychologických cˇ i technických – nemohou používat aplikace s pˇrímou podporou IBP, JavaLors cˇ i implementaci IBP jako lokálního systému soubor˚u, nabízíme ukládání dat do infrastruktury DiDaSu pomocí webového rozhraní. Pˇres toto rozhraní je možné soubory nahrávat, stahovat, vypisovat jejich seznamy, mazat a pˇrejmenová-
vat. Webové rozhraní je podobnˇe jako samotné IBP plnˇe redundantní, tj. na každém depotu bˇeží web server a uživatel je automaticky v pˇrípadˇe výpadku pˇresmˇerováván na jiný depot. Pomocí protokolu HTTPS je možné bezpeˇcnˇe pˇristupovat k celé infrastruktuˇre bez nárok˚u na jakékoli speciální vybavení.
6 Srovnání pˇrístupu˚ Pˇrístup projektu DiDaS m˚užeme charakterizovat jako rˇešení integrující sklady typu NAS do jednoho velkého datového prostoru s ˇradou nových vlastností, které jednotlivé uzly postrádají: • vysoký výkon infrastruktury zejména pˇri cˇ tení dat (jeden klient s gigabitovým pˇripojením m˚uže bˇežnˇe cˇ íst jeden soubor rychlostí pˇres 400 Mb/s), • jednotlivé uzly úložné infrastruktury mohou být levné a nemusí dosahovat mimoˇrádné propustnosti, pˇresto však infrastruktura jako celek poskytuje vysoký výkon, • od zaˇcátku se poˇcítá s nespolehlivostí jednotlivých uzl˚u, proˇcež systém podporuje zvyšování robustnosti pomocí redundantního ukládání dat, • redundance kromˇe zlepšování robustnosti zvyšuje také rychlost pˇrístupu, • umožˇnuje využít ,,volnˇe‘‘ ležící diskovou kapacitu nededikovaných uzl˚u v síti (typicky koncové stanice, které dnes mají bˇežnˇe diskovou kapacitu v ˇrádu 100 GB), • pˇri implementaci jako lokální systém soubor˚u podporuje také verzování soubor˚u a adresáˇru˚ . Uvedené vlastnosti nejsou bˇežnˇe dostupné ani v komerˇcních ˇrešeních typu SAN, a to ani pˇri práci s daty v rámci jediného výpoˇcetního centra.
7 Závˇer V tomto cˇ lánku jsme pˇredstavili netradiˇcní pˇrístup k vytváˇrení distribuovaných datových sklad˚u, který umožˇnuje velmi levnˇe a efektivnˇe poskytovat velkou úložnou kapacitu. Kromˇe vysokého výkonu pˇrináší také ˇradu zajímavých vlastností, jako je nativní podpora replikace dat cˇ i podpora verzování soubor˚u. Na rozdíl od komerˇcnˇe bˇežnˇe dostupných ˇrešení se jedná o plnˇe otevˇrený vývojový systém, který nemusí být vhodný pro bˇežného uživatele k produkˇcnímu nasazení, ale který pˇredznaˇcuje potenciální smˇery 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, 2005. [2] M. Beck, T. Moore, J. S. Planck. ,,An End-to-End Approach to Globally Scalable Network Storage‘‘, SIGCOMM’02, 2002. http://loci.cs.utk.edu/ibp/files/ pdf/SIGCOMM02p1783-beck.pdf [3] L. Hejtmánek, L. Matyska. ,,Distribuované Datové Sklady‘‘, Širokopásmové sítˇe a jejich aplikace, Olomouc, 2005. s. 168–175.
[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 1997. [5] L. Shepard, E. Eppe. ,,SGI InfiniteStorage Shared Filesystem CXFS: A High-Performance, Multi-OS Filesystem from SGI‘‘, SGI, 2004. http://www.sgi.com/pdfs/2691. pdf [6] L. Hejtmánek, P. Holub. ,,IBP Deployment Tests and Integration with DiDaS Project‘‘, Technická zpráva CESNET 20/2003. 2003. http://www.cesnet.cz/doc/techzpravy/ 2003/ibpdidas/ [7] M. Karásek. Distribuovaný souborový systém pro Linux, diplomová práce FI MU. Brno, 2005. [8] Linux Userland Filesystem. http://lufs.sourceforge.net/ [9] OpenAFS. http://www.openafs.org/ [10] B. Berliner, J. Polk. Concurrent Versions System (CVS). 2001 http://www.cvshome. org [11] B. Collins–Sussman, B. W. Fitzpatrick, C. M. Pilato. Version Control with Subversion, 2004. http://svnbook.red-bean.com/en/1.0/svn-book.html [12] Microsoft ssafe/
SourceSafe.
http://msdn.microsoft.com/vstudio/previous/
[13] P. Holub, L. Hejtmanek. ,,Distributed Encoding Environment Based on Grids and IBP Infrastructure‘‘, Selected papers from TERENA Networking Conference 2004, Rhodes, Greece, 2004. http://www.terena.nl/library/tnc2004-proceedings/ papers/holub.pdf [14] JavaLors, http://undomiel.ics.muni.cz/presentation/download/ JavaLors.jar
