A komplexitást a megfogalmazott követelmények teljesítése indokolja. Az ARP-adatrepozitórium a felhasználói igényeken túl magas fokú elérhetőséget, rendelkezésre állást kell hogy biztosítson (más kontextusban ezt a szolgáltatási szint megállapodás [SLA] részének tekintik), és természetesen az adatok biztonsága rendkívül fontos szempont. Az adatbiztonságon ezúttal nem a jogosulatlan hozzáférés megakadályozását értjük, vagy egyéb titkosítási megoldások alkalmazását, hanem az adatok sérülésének vagy elvesztésének megelőzését.

Mivel az ARP-adatrepozitórium nagyszámú felhasználó egyidejű keresési és adat le- és feltöltési kérését kell, hogy kiszolgálja, a megvalósított rendszernek alkalmasnak kell lennie ezek konkurens kiszolgálására (megfelelően méretezett CPU- és memóriakapacitással), és megfelelően nagy méretű hálózati sávszélességre van szüksége, azért hogy az esetlegesen párhuzamosan futó, nagy méretű adatok mozgatása során ne hátráltassák egymást túlzott mértékben.

Ezeken túlmenően, az ARP-adatrepozitórium megvalósítása során felmerülő talán legfontosabb szempont és kihívás, hogy hogyan lehet hatékonyan és biztonságosan, hosszú távon tárolni rendkívül nagy mennyiségű adatot (mind terabyte, mind petabyte nagyságrendben), hogyan lehet kialakítani egy karbantartható infrastruktúrát (esetleges hardvermeghibásodások, szoftverfrissítések esetén is) anélkül, hogy adatot veszítenénk, vagy a rendszer elérhetetlenné válna a javítások idején.

A nyers kutatási adatok archiválásán, megőrzésén, hivatkozhatóságán és letölthetőségén túl fontos követelmény volt az ARP-adatrepozitóriumban való kereshetőség biztosítása is, amely újabb kutatásokhoz szolgáltathat alapadatokat. Szükséges szemantikai információ hiányában és az adatok óriási tömegét figyelembe véve ez szinte lehetetlen feladat lenne. Ezért lett kialakítva a nyers adatokhoz társított metaadatrendszer, amely a nyers adatokról tartalmi, értelmezési és egyéb leíró információkat tárol, amelyek segítségével egyszerű, de akár összetett szempontok szerint már kereshetővé válnak az adatok. A nyers adatokat tehát „metaadatolva” tároljuk az adatrepozitóriumban, a metaadatok a nyers adatokhoz vannak társítva, de a megvalósítás során nem feltétlenül kerülnek ugyanarra az adattárolóra, adattárhelyre, mert a metaadatoknak a hatékony kereshetőséget kell biztosítaniuk tetszőleges szempontrendszer szerint (belső metaadatmező-tartalmakra), míg a nyers adatoknak csak elérhetőséget kell biztosítaniuk (és nem szükséges a belső struktúrához, tartalomhoz hozzáférni).

A fenti szempontok szerinti rendszer kialakítása láthatóan nem egyszerű feladat, különösen, ha egy megfelelő háttér-infrastruktúra még nem áll rendelkezésre. Az ELKH Cloud azonban megfelelő alapként szolgált az adatrepozitórium megvalósításához. Az ELKH-felhő önmagában biztosítja a megfelelő rendelkezésre állás, adatbiztonság (redundancia), rugalmas hardverigények (CPU12, memória), nagy külső és belső sávszélesség biztosítása, felhasználók és projektek kezelése, monitorozás és karbantartás kritériumait. Ezért az ARP-adatrepozitóriumot az ELKH Cloud kiterjesztéseként kívántuk megvalósítani. Az adatrepozitórium adatai számára az ELKH Cloudban már meglevő Ceph-tároló mellett egy új, önálló adattároló rész, ún. ARP Ceph-tároló lesz kialakítva, megfelelően nagyszámú fizikai lemezegység hozzáadásával és a Ceph-rendszer (Weil et al., 2006) telepítésével, konfigurálásával (1. ábra). Az ARP Ceph-tároló fizikailag az ELKH-felhőhöz lesz csatolva, így ez nem válik el helyileg (hálózati szempontból), hanem elérhető, kvázi lokálisan az ELKH számítási felhőből. Ennek a tervezési döntésnek az a nagy előnye, hogy amennyiben az adatfeldolgozó algoritmusokat az ELKH-felhőben futtatjuk, a nyers adatokat már nem kell egy megelőző lépésben ide átmozgatni, hanem a számítások azonnal a helyileg elérhető nyers adatokon elvégezhetőek. Ez a „Moving Compute to Data”, azaz a mozgassuk a számítást az adathoz elvnek megfelelő feldolgozási modell alkalmazását teszi lehetővé. Ez a paradigma rendkívül fontos, amennyiben extrém nagy mennyiségű adat feldolgozása szükséges, mert ekkor előfordulhat, hogy pusztán az adatok mozgatásának költsége (és ideje) nagyságrendekkel haladja meg a tényleges, a valójában értékes adatokat szolgáltató feldolgozási költséget.

Az ELKH-felhő felhasználói felülete (OpenStack [URL1] alapon) lehetővé teszi, hogy az egyes kutatócsoportok elkülönülten (külön projektekben, rugalmas autorizációs feltételekkel) dolgozzanak a saját érdeklődésükre számot tartó adatfeldolgozási projektjeiken, mégis mindegyik önálló projekt hozzáfér az ARP-adatrepozitórium tetszőleges adattartalmához. Fontos megjegyezni, hogy az adatokat feldolgozó személy vagy szervezet nem feltétlenül kell hogy azonos legyen az eredeti adatokat az adatrepozitóriumba feltöltő, publikáló személlyel vagy szervezettel. A számításokhoz szükséges helyi tárolókat és diszkeket (virtuálisgép-lemezek, köztes adatok és eredmények átmeneti tárolására) az ELKH-felhő saját tárolórendszere biztosítja.

 

Az adatrepozitórium az első szintet tekintve az adatbiztonságot háromszoros redundancia (RAID23 3 [Patterson et al., 1987]) biztosításával segíti elő.

Az ELKH Cloudot valójában két felhő federációja alkotja. A felhő egyik része a SZTAKI-ban van (SZTAKI Cloud), a másik része a Wigner Fizikai Kutatóközpontban üzemel (Wigner Cloud), jóllehet a felhasználók egyetlen egységes felületen érik el mindkettőt, számukra transzparens módon (URL2 /webes eléréssel), a nyílt forráskódú OpenStack-keretrendszerbe integrálva.

Az ARP-adatrepozitórium és a nyers adatok elsődleges tárolási helye a SZTAKI-felhőben lesz, de a Wigner-felhőben is telepítésre kerül és üzemel egy, a SZTAKI-felhőbeli adatrepozitóriummal azonos felépítésű és funkciókkal bíró komponens, ún. Slave VM34, amely mögött szintén rendelkezésre áll nagy mennyiségű adattároló kapacitás. A két rendszer, összekapcsolásuk révén, képes lesz egymással kommunikálni, adatokat cserélni, megfelelő szinkronizációs műveleteket egymás között elvégezni, automatizált módon.

Az összes nyers adat automatikus és folyamatos replikálása a SZTAKI-felhőből a Wigner-felhőbe azonban szükségtelenül nagy költséget és hálózati leterheltséget jelentett volna (a helyi redundancia önmagában kellő adatbiztonságot ad). A metaadatok mérete azonban lényegesen kisebb, a metaadatok replikációja, tükrözése a Wigner-felhőben automatikusan megtörténik, ezzel növelve a metaadatok geolokációs redundanciáját. A metaadatok (és egyéb rendszer-konfigurációs adatok) biztonságát növeli az automatikus napi mentés különálló adathordozóra.

Előfordulhat, hogy egy adott adatfeldolgozást egy felhasználó vagy intézet a Wigner-felhőben kívánja elvégezni, mert vagy kapacitási, vagy egyéb speciális hardverigények miatt itt van lehetőség, itt indokolt ezeket elvégezni, de a nyers adatok helye fizikailag továbbra is a SZTAKI-felhő. Azért, hogy elkerüljük azt, hogy a felhasználónak magának kelljen az adatokat átmozgatni a SZTAKI-felhőből a Wigner-felhőbe (vagy alacsony sávszélességgel tudja csak elérni a távoli adatokat), az adatrepozitórium igény esetén lehetőséget biztosít teljes nyers adatrepozitóriumok átmozgatására. Ezt az adattranszfert a rendszer automatikusan elvégzi, de csak felhasználói (projekt) kérésre. A nyers adatok tükrözése után a feldolgozás már a Wigner-felhőben is rendkívül hatékony módon történhet meg, helyi adathozzáféréssel. Ugyanakkor, mivel az elsődleges adattárolás és adatbevitel helye a SZTAKI-felhő, ezért a Wigner-felhőben futó feldolgozások csak olvasni tudják a Wigner-felhőben tárolt adatrepozitóriumok adatait, ahogy a 2. ábra mutatja. Ha a feldolgozás eredményeképpen előállított új adatokat is be kell írni az ARP-be, akkor ezt csak a SZTAKI-felhőben működő ARP-VM segítségével lehet elvégezni.

A Wigner-felhőben található adatok számára további lehetőség az adatbiztonság fokozására az adatok szalagos egységre történő kiírása. Ezt egy SL3000-es egység segítségével lehet megtenni, szintén felhasználói kérés esetén.

 

A NAS-ról a központi ARP-adatrepozitóriumba való adattranszfer többféle módon történhet. Amennyiben rendelkezésre áll nagy sávszélességű internetkapcsolat a központi repozitórium felé, az adatok feltöltése történhet a szokásos módon, a mindenki számára elérhető webes vagy API45-szolgáltatások valamelyikén, azzal a különbséggel, hogy a forrásadatok helye ezúttal a NAS-on található. Lehetőség van továbbá kötegelt feltöltésre is a NAS és az adatrepozitórium között egy megfelelő szkript lefuttatásával, amely az összes adatot és metaadatot egyetlen parancs kiadásával feltölti. Amennyiben a metaadatok még nem készültek el, de már nagy mennyiségű primer adat áll rendelkezésre, az ELKH-felhőn indítható egy nagy tárolási kapacitású virtuális gép (egy, az erre a célra előkészített lemezkép kiválasztásával), ahova az adatokat átmeneti jelleggel már át lehet transzferálni (ezt ún. kétlépcsős adatfeltöltésnek hívjuk). Amint minden adat és a metaadatok is elkészültek, és feltöltődtek a virtuális gépre, innen már nagy sávszélességű kapcsolaton keresztül, felhasználói jelzésre, automatizáltan kerülhetnek át az adatok a központi ARP-adatrepozitóriumba. Nem utolsósorban, lehetőség van az eszköz fizikai átszállítására is a SZTAKI-ba, ahol azután a repozitóriumba való adatmásolás helyileg történhet, amely bár nagyságrendjében nem, működésében hasonló az Amazon Snowball (URL3) szolgáltatásához.

Ezek a lokális NAS-eszközök 60 TB-os tárterületet biztosítanak (RAID 6 redundanciával), előre telepített, Windows Server operációs rendszerrel, de összekapcsolhatók más, nem Windows-rendszerekkel is. Elsőként a Régészeti Intézetben lévő NAS-adattáron teszteltük a kétlépcsős adatfeltöltést. Az ELKH ARP végső célja, hogy a jelenlegi pilot megoldás általános megoldásként minél több intézet számára legyen bejáratott út a központi adatrepozitórium felé.

 

Ebben a cikkben ennek az infrastruktúrának a koncepcionális és tervezési megfontolásait, döntéseit mutattuk be, a konkrét megvalósítás néhány fontosabb műszaki részletével és megoldásával együtt. A megvalósított infrastruktúrának számos magas szintű követelményt, elvárást kell teljesítenie, mint például a magas rendelkezésre állás, adatbiztonság és redundancia, geolokáció, az adatfeldolgozás minél hatékonyabb támogatása, az adattranszfer és az intézeti, helyi adatkezelés támogatása. Épp ezért volt nagyon fontos stratégiai döntés, hogy az adatrepozitórium műszaki megvalósítását ne nulláról kezdjük, hanem a nagyon sikeres és stabil működésű ELKH Cloud továbbfejlesztéseként oldjuk meg. Ez garancia arra, hogy az adatrepozitórium is eleget fog tenni a magas műszaki elvárásoknak.