• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Grid és adattárolás
 

Grid és adattárolás

on

  • 525 views

2006

2006

Statistics

Views

Total Views
525
Views on SlideShare
525
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Grid és adattárolás Grid és adattárolás Presentation Transcript

    • Grid és adattárolás Szalai Ferenc, Nagy Zsombor, Wágner Ferenc NIIF Intézet
    • TartalomI. Általános bevezetésII.A ClusterGrid infrastruktúraIII.Számítási erőforrás: Könnyen telepíthető HPC klaszter kialakítása GNU/Debian Linux alapokonIV.Adattárolási erőforrás: Költséghatékony adattárolás Coraid (AOE) alapokonV.Grid köztesréteg keretrendszer: Grid UndergroundVI.Elosztott adattárolási grid szolgáltatásVII.Hova tovább
    • I. Általános bevezető
    • Mi az a grid?● Szolgáltatás orientált megközelítés● Erőforrás és felhasználói absztrakció jelenléte fontos● Erőforrásokat szolgáltatások reprezentálják● Lehetséges erőforrások: számítási (PC, klaszter, szuperszámítógép), adattárolási (diszk, NAS, HPC Storage alrendszer), virtuális labor, tartalomszolgáltatások, hálózat stb.● A grid divat, de fel lehet tölteni tartalommal is!
    • Mi az a ClusterGrid?● Magyarország egyetlen valódi (nem teszt, nem projekt) grid rendszere.● 2002 június óta működik egy OM-NIIF PC labor pályázatnak köszönhetően● éjjel-nappal váltakozó üzemmód● speciális hálózati és számítási erőforrás infrastruktúra● központi management
    • II. ClusterGrid infrastruktúra
    • ClusterGrid architektúra
    • ClusterGrid architektúra● Védet hálózatba kötött erőforrások (MPLS, .1q VLAN)● Szeparáció: operációs rendszer szint, hálózati összeköttetés szint● Egyszerű könnyen managelhető komponensek● klaszter az elemei erőforrás● Szuperszámítógépek is be vannak kötve● kb. 1000 csomópont, 1 - 1.5 Tflops, 40 Tb adattárolási kapacitás● Saját grid köztesréteg (middleware)
    • ClusterGrid felhasználói környezet● Belépési pontok eléréséhez X509-es tanúsítvány szükséges. (pl.: NIIF CA)● Moduláris kliens alkalmazás (grid parancs, jelenleg parancssori)● Funkciók: – feladat indítás (grid clgr submit) – feladat státus (grid clgr status) – feladat törlése (grid clgr rm) – feladat eredményének begyűjtése (grid clgr getout) – erőforrás rendelkezésre állása (grid clgr info)
    • III. Számítási erőforrás: Könnyen telepíthető HPC klaszter kialakításaGNU/Debian Linux alapokon Wágner Ferenc
    • Célkitűzések● könnyen, lehetőleg távolról is telepíthető rendszer;● minél kevesebb szolgáltatás a konfiguráció egyszerűsége és rugalmasan tartása végett;● tisztán hálózati kliensek, opcionális lemezhasználat. – A jelenlegi egyetlen ütemezőnk, a Condor swapet követel, ami egyelőre lokális (létezik hálózati swapes tesztrendszer); – PXE-vel bootolunk, ami jöhet hajlékony lemezről is, ha az intézményi üzemmódváltási policy ezt követeli.
    • Megoldás● Linux disztribúció: GNU/Debian Sarge● intelligens, hardverfüggetlen telepítő;● a telepítő testre szabható● dokumentált;● telepítés után is könnyen karban tartható.
    • Debian telepítő testre szabása● kiindulási pont a Netinst CD: kis image, könnyen terjeszthető és gyorsan felírható● default kernel a 2.6-os (Intel arch. fordul csak elő), parancssor: – debian-installer/framebuffer=false (kompatibilitási okokból) – languagechooser/language-name=English – countrychooser/shortlist=US – console-keymaps-at/keymap=us – preseed/file=/cdrom/clgr/seed.cfg (a többi válasz már írható ebbe)
    • Debian telepítő: Problémák● kernel parancssor hossza korlátozott, lényegében betelt● további opciók (nodma) hozzáadása nehézkes● esetleges USB billentyűzet nyelvét továbbra is választani kell
    • Debian Telepítő● A telepítő által feltett kérdések: – hálózati konfiguráció, particionálás, root jelszó● A ClusterGrid egy központi gépét használjuk: – DNS szervernek, APT proxy-nak, időszervernek, – mail átjárónak: a rendszerleveleket központilag gyűjtjük
    • Debian telepítő: hálózat● a telepítő netcfg összetevője nem moduláris, át kellett írni; – C program, komoly módosításokra szorult a VLAN- ok, a GRE tunnel és a több interface támogatásának hiánya miatt; – SVN-ből letölthető a Debian Installer Sarge ágát használtuk a szükséges állományok felülírásával
    • Debian telepítő: hálózat● a szerverek egy privát Layer 3 MPLS hálózatba vannak kötve – vagy egy közeli NIIF regionális routeren keresztül, vagy egy Internetben futó GRE IP tunnelen keresztül.● a klaszter általában natívan és tagelt VLAN-on keresztül is kapcsolódik a szerverhez; – ha az induló DHCP-t és TFTP-t nem a GRID szerver nyújtja, akkor natív kapcsolatra nincs szükség.● a telepítő beállítja ezeket a hálózati kapcsolatokat, gyenge hálózati eszközök esetén MTU csökkentésre lehet utólag szükség.
    • Debian telepítő: particionálás● a partman összetevő scriptek moduláris rendszere● új, ClusterGrid specifikus menüponttal bővítettük● a kijelölt diszkeken automatikusan szoftver RAID fölötti LVM köteteket képez, alkalmas fájlrendszerekkel (Ext3, XFS) és csatolási pontokkal, csak le kell okézni.
    • ClusterGrid csomagok● a csomagok nem feltételezik a saját telepítő használatát, úgy kevesebbet kérdeznek, mert a hálózati adatokat átveszik tőle;● clgr-server: – lényegében függőségi csomag: a szükséges összetevőket (szerver programokat) húzza magával konfigurálja is őket, vagyis sérti a Debian Policy-t; – legalább csinál backupot; – biztosít pár adminisztrációs eszközt.
    • ClusterGrid csomagok● clgr-client-image: nem tartalmazza az NFS root image-et, csak az azt elkészítő programot● clgr-condor: bináris csomag, az ütemező zárt forráskódú (kiváltása folyamatban);● clgr-initramfs: csak az új (>2.6.12) kernelek initramfs függőségét elégíti ki, kamu initramfs-t gyárt, a kliensek initrd-t használnak; – a szerveren ezek a kernelek nem futtathatók.
    • Kliens indulása● a Windowsokat a nap végén kézzel vagy időzített feladattal lekapcsolják vagy újraindítják;● az alapértelmezett üzemmód a megadott időben átvált;● a szerver néhány másodperces eltolással hálózaton ébreszti őket;● PXE stack elindul a hálókártya ROM-ban vagy lemezről;
    • Kliensek indulása● DHCP szerver lehet intézményi vagy futhat a GRID szerveren ✔ a helyi labor kikapcsolt GRID szerver mellett is működőképes; ✔ a helyi rendszergazdák saját területen tudnak beavatkozni az első lépésbe; ✔ a GRID szerver nem igényel kézi konfigurációt; ✗ külön eszközt vesz igénybe
    • Kliens indulása● TFTP-n letöltődik a PXELINUX boot menü: – desktop mód: lokális boot a helyi merevlemezről; – grid mód: TFTP-n jön a linux kernel és az initrd; – további módok vehetők fel a helyi igényeknek megfelelően; – az alapértelmezett üzemmód cronból változik; – lehet a TFTP szerver is intézményi, de az nehézkessé teszi a rendszer frissítését, mert másolgatni kell a kernelt és az initrd-t.
    • Kliens Indulása● Az induló Linux már csak a tagelt VLAN-t használja, adminisztratívan elválasztva ezzel a GRID forgalmat a többitől.● Igénybe vett szolgáltatások: DHCP, NFS, syslog, NTP, SMTP, Condor● Nem kell DNS!● A kliensek a partíció típusától függően inicializálják a számukra kijelölt partíciót, felcsatolják, és swap fájlt hoznak létre rajta.
    • Kliensek indulása● / - csak olvasható közös NFS root; – a /etc/adjtime, a /etc/hosts és a /etc/mailname szimbolikus linkek a /var/local alá, mert kliensenként különbözőek; rendszerindításkor kerülnek kitöltésre.● /dev - TMPFS másolat a gyökérből, többen írni akarják.● /var - TMPFS másolat a gyökérből, alapértelmezés szerint üres állományokkal, helytakarékossági okokból; a logolás a GRID szerverre történik, a /var partíciót nem dagasztja.
    • Kliensek Indulása● /usr/local - csak olvasható közös NFS programterület, például a Condor ütemezőt ide telepítjük, mert az fut a szerveren és a klienseken is.● /home - írható közös NFS terület, nem lockolt, így nem írhatja több kliens ugyanazt a fájlt (a Condor figyel erre).
    • Kliensek Indulása● SSH démon fut a klienseken, konzol login alapesetben nem engedélyezett, csak root kulcs van a szerveren.● A grid periódus végén az alapértelmezett boot mód visszaáll lokálisra, a kliensek pedig a helyi beállítás szerint leállnak, újraindulnak vagy futnak tovább, míg az eléjük ülő felhasználó egy újraindítással vissza nem váltja őket desktop üzemmódba.
    • Monitorozás● Szervereink különböző mutatóit a ClusterGrid központból a Munin szoftver segítségével folyamatosan mérjük; – ez komoly segítség a hibakeresésben, – és képet kapunk a rendszer összesített teljesítményéről is;● Mindkettőhöz szükségessé vált saját plugin-ek fejlesztése is.
    • Monitorozás
    • Hova tovább?● Problémák: – Condor – az időszinkron miatt a szerver terhelése nagyon egyenetlen.● Terveink: – felügyelet (Nagios) – távoli ssh konzolos telepítési opció – hálózati swap opció – NFS root helyett TMPFS root opció
    • IV. Adattárolási erőforrás:Költséghatékony adattárolás Coraid (AOE) alapokon
    • Célkitűzés● 100 Tb-os adattárolás● Földrajzilag elosztott architektúra● Standard hálózati technológia (IP, vagy ethernet)● Hagyományos merevlemezeket használjon● Legyen olcsó● Nagy rendelkezésre állás könnyű biztosíthatósága
    • Megoldás● AOE protokoll (Layer 2)● Coraid PATA és SATA eszközök● PATA: 10 db lemez, passzív doboz, aktív lemezre szerelhető egységgel, 100 Mb/s lemezenkénti uplink● SATA: aktív managelhető doboz, 2x1GE uplink, RAID (0, 1, 5, 10), 15 db lemez
    • ATA over Ethernet● Üzenetek: – ATA üzenetek Ethernet üzenetbe csomagolva – konfigurációs● AoE egységek azonosítása: shelf, slot● Speciális ethernet csomag típus -> 802.1q nem engedélyezett● Jumbo frame támogatás
    • AoE + Host OS● Operációs rendszer támogatás: – Linux: 2.6.11 óta vanilla kernel része – Windows – Freebsd – Solaris, Mac OS X: hamarosan● Aoetools: felhasználói programokls ­l /dev/etherd/c­w­­w­­­­  1 root disk 152,   3 2006­04­10 08:23 discoverbrw­rw­­­­  1 root disk 152, 160 2006­04­10 08:23 e10.0brw­rw­­­­  1 root disk 152, 161 2006­04­10 08:23 e10.1cr­­r­­­­­  1 root disk 152,   2 2006­04­10 08:23 errc­w­­w­­­­  1 root disk 152,   4 2006­04­10 08:23 interfacesc­w­­w­­­­  1 root disk 152,   5 2006­04­10 08:23 revalidate
    • 20Tb HA PATA Storage Node● 8db PATA doboz (7 használt 1 tartalék)● 1db Cisco 3550 48 port sw● 1db Cisco 3550 24 port sw● 70 db Hitachi 400 Gb PATA disk● 2db IBM AMD 64 bit frontend● rengeteg kábel, optikai GE uplink (publikus, grid VLAN)● LVM2 + XFS, RAID 6● HA: Hearthbeat● Grid storage sw● 60GB/s írás, olvasás
    • SATA Storage Node● 3 db SATA doboz● C6509, GE switch modul● Több különféle frontend: – XEN virtuális gép virtuális merevlemezei – EGEE storage – Grid storage● Teljesítmény tesztek folynak
    • V. Grid köztesrétegkeretrendszer: Grid Underground
    • Célkitűzés● Web szolgáltatás orientált szabvány (W3C, OGSA) implementációkat tartalmazó általános keretrendszer● Konkrét grid szolgáltatások megvalósítása● Kicsi egyszerűen telepíthető, kezelhető rendszer● több platform, OS támogatása● desktopon és szupergépeken is használható legyen● kicsi memória és CPU használat az erőforrásokon
    • Megoldás● Komponensek: – Python programozási nyelv – Twisted web alkalmazás keretrendszer – soappy – SOAP parzer – pyopenssl – X509 tanúsítványok és TLS kezelése● Core rendszer: – minden szolgáltatás egy dinamikusan betölthető interfész osztály + backendek – kommunikációs réteget elrejti a szolgáltatások elöl – szolgáltatás életciklus kezelés
    • GUG Core● gugctl daemon● Két speciális szolgáltatás: Manager, Grid Információs rendszer (GIS)● Szálkezelés● Manager: – szolgáltatások életciklus kezelése: leállítás, indítás, status, hirdetések begyűjtése stb. – maga is web szolgáltatás -> távoli szolgáltatás management● GIS: – p2p rendszer a szolgáltatás hirdetések terjesztésére és keresésére; – adat és meta adat szétválasztása – adat bármi lehet
    • GUG szolgáltatások● Egyszerű követelmények: – bármilyen Python osztály lehet – a konstruktor megkapja: service id, local_gis_url, konfigurációs állomány neve – legyen egy get_description függvénye – _ kezdődő függvények nem hívhatóak SOAP-on keresztül – opcionálisan lehet _clean függvénye takarításra – publikus függvény első argumentuma az authorizációs információt tartalmazza● A get_description a szolgáltatás leírását adja vissza amit a GIS terjeszt. Bármilyen formátum lehet. Jelenleg XML használatos
    • Példa szolgáltatásclass Test: def __init__(self, id, local_gis_url, config): pass def _get_description(self, site_id): return ”””<?xml version=1.0?> <ServiceDescription> <Site>%s</Site> </ServiceDescription> ””” % site_id def echo(self, x509, x): return x
    • GUG szolgáltatások: feladat végrehajtás● SuperScheduler: grid (opcionálisan klaszter) szintű ütemezés – OGSA BES interfész, OGSA JSDL feladat leíró – moduláris erőforrás és döntéshozási interfész● Job Controller: egységes interfész a különféle helyi erőforrás kezelő rendszerekhez (Condor, LSF, PBS, stb.) – OGSA BES interfész, OGSA JSDL feladat leíró – nem ütemez● Exec: SMP gépen programvégerhajtás – architektúra függő modulok
    • Use case -ClusterGrid
    • Use case - klaszter
    • Use case – destop grid
    • GUG szolgáltatások● Fordítás: a gridben elérhető összes architektúrára lefordítja az alkalmazást és előkészíti a feladat végrehajtásra● Virtuális szervezetek (VO): minden feladat, felhasználó, szolgáltatás egy vagy több VO-nak tagja. A VO határozza meg az hozzáférési jogosultságokat. A tagságot tagsági igazolvánnyal igazolja● Elosztott katalógus● Elosztott adattárolás: storage manager (StM), storage controller (StC)● Állomány megosztás
    • VI. Elosztott adattárolási grid szolgáltatás Nagy Zsombor
    • A teljes storage rendszer architektúrája
    • Egyedi azonosítók a rendszerben● GUID: katalógus bejegyzés azonosítója – a katalógusban használjuk● SURL: állomány példányának azonosítója – a Storage Controllernél használjuk● LFN: állományok és könyvtárok elérési útja – a felhasználó csak erről tud
    • Felhasználói felület● egységes névtér (/grid)● LFN (Logical Filename)● /grid/niif/tmp/file
    • Utasítások● állománykezelés: put, get, cp, mv, rm● könyvtárak: ls, mkdir, rmdir● a cp valójában egy put vagy get, ha helyi útvonal van benne● az mv helyi útvonalra valójában egy put vagy get és egy törlés
    • Példa● ls, mkdir$ grid storage ls /grid/tmp$ grid storage mkdir /grid/tmp/proba$ grid storage ls /grid/tmpd   2006­04­12 14:04 proba● put$ cat szoveg  Szöveg.$ grid storage put szoveg /grid/tmp/probaput szoveg to /grid/proba/szoveg... done.$ grid storage put szoveg /grid/tmp/probaput szoveg to /grid/tmp/proba/szoveg.1... done.$ grid storage put szoveg /grid/tmp/masnevput szoveg to /grid/tmp/proba/masnev... done.
    • Példa: ls -R$ grid storage ls /grid/tmp ­R/grid/tmp:d   2006­04­12 14:04 proba/grid/tmp/proba:­ 8 2006­04­12 14:05 szoveg­ 8 2006­04­12 14:06 szoveg.1­ 8 2006­04­12 14:06 masnev
    • Példa: get$ grid storage get /grid/tmp/proba/szovegget /grid/tmp/proba/szoveg to ./szoveg.1... done.$ grid storage get /grid/tmp/proba/szovegget /grid/tmp/proba/szoveg to ./szoveg.2... done.$ grid storage get /grid/tmp/proba/szoveg.1get /grid/tmp/proba/szoveg to ./szoveg.3... done.
    • Példa: mv$ grid storage mv /grid/tmp/proba/szoveg   /grid/tmp$ grid storage ls /grid/tmp ­R/grid/tmp:d   2006­04­12 14:04 proba­ 8 2006­04­12 14:05 szoveg/grid/tmp/proba:­ 8 2006­04­12 14:06 szoveg.1­ 8 2006­04­12 14:06 maslegyenaneve
    • Példa: mv$ grid storage mv /grid/tmp/proba/masnev   /grid/tmp/szovegmv: /grid/tmp/szoveg: LFN already exists$ grid storage mkdir /grid/tmp/test$ grid storage mv /grid/tmp/proba/masnev   /grid/tmp/test$ grid storage ls /grid/niif/tmp/test­ 8 2006­04­12 14:06 masnev
    • Példa: ls kiment (lokális)zsombor@gridsite:~$ ls ­lR probaproba:total 8drwxr­xr­x 2 zsombor zsombor 4096 Dec 15 15:40 bin­rw­r—r­­ 1 zsombor zsombor   58 Feb 24 13:11 submitproba/bin:total 80­rwxr­xr­x  1 zsombor zsombor 75948 Dec 15 15:40 ls
    • Példa: cp (put)$ grid storage cp proba /grid/tmpcp: proba is a directory.$ grid storage cp ­R proba /grid/tmpentering directory probaput proba/submit to /grid/tmp/proba/submit... done.entering directory proba/binput proba/bin/ls to /grid/tmp/proba/bin/ls... done.put proba/bin to /grid/tmp/proba/bin finished.put proba to /grid/tmp/proba finished.
    • Példa: ls kimenet (storage)$ grid storage ls ­R /grid/tmp/proba/grid/tmp/proba:­ 58 2006­04­12 17:09 submitd     2006­04­12 17:09 bin/grid/tmp/proba/bin:x 75948 2006­04­12 17:09 ls
    • Katalógus felület● kulcs-érték párok tárolása● kulcs alapú visszakeresés● kulcs-érték párok törlése● karakterfüzérek● felhasználás: ID - XML dokumentum összerendelés
    • Katalógus implementáció● Distributed Hash Table● Distributed Hash Catalog (DHC) – jelenleg centralizált – Kademlia protokoll implementálása folyamatban● csomópont: DHC Node● interfész: DHC Manager (DM)
    • Katalógus: Kademlia● csomópontok: 160-bites azonosító● kulcs hash-elése 160 bitre● az a k db csomópont tárolja az adatot, amelyik a legközelebb van a kulcs hash-éhez● közelség: XOR metrika● kulcs felkutatása: logaritmikus lépésszám
    • Katalógusban tárolt adatok● kulcs: egyedi azonosító (Global Unique IDentifier, GUID)● érték: XML dokumentum, kétféle: file/directory● GUID: olyan, mint az inode, minden könyvtárnak és állománynak van● a /grid könyvtárnak fix GUID-ja van: 0● az LFN feloldása mindig a /grid-től indul
    • Katalógus: könyvtár (/grid)<Directory> <Created>1138791142</Created> <Entry>   <GUID>a5b50c6c­13c2­46e7­b34c­735c5a2d93c0</GUID>   <Name>jobs</Name> </Entry> <Entry>   <GUID>227e2b4a­bdca­40ef­b43f­cf55547e2a1e</GUID>   <Name>tmp</Name> </Entry></Directory>
    • Katalógus: könyvtár (/grid/tmp)<Directory>  <Created>1144854280</Created>  <Entry>     <GUID>c7696f8b­49a8­4dbd­862e­8928c4f6ae09</GUID>     <Name>proba</Name>  </Entry>  <Entry>     <GUID>2ddb17fc­15be­4c20­9909­79fcffd4a678</GUID>     <Name>szoveg</Name>  </Entry></Directory>
    • Katalógus: állomány ("szoveg") <File>    <Created>1144920120</Created>    <Size>8</Size>    <SURL>2fa00259­15b5­42b7­92df           ­863e5522758f/ipipida875</SURL>    <IsExecutable>0</IsExecutable> </File>
    • Storage Element (SE) felület● a Storage Element egy absztrakt erőforrás● egy file példányának egyedi azonosítója: SURL, Storage URL● műveletek: – file tárolása, SURL generálás – SURL által azonosított file visszaadása – SURL által azonosított file törlése
    • SE megvalósítása: Storage Controller● műveletek: – prepareToGet, – statusOfGetRequest – prepareToPut, – statusOfPutRequest, – releaseFiles● SURL formátuma: – <StC ID>/<file ID>● StC megtalálható az ID-je alapján
    • Storage Controller adattranszferFüggetlen adattranszfer:● TURL, Transfer URL● a felhasználó jelzi feltöltési/letöltési szándékát● kap TURL-eket● kiválaszt egyet, és feltölti/letölti a file
    • Storage Controller feltöltés● prepareToPut, több file is feltölthető meg kell adni az állományok méretét minden állományhoz kapunk SURL-t és TURL-ek és kapunk egy tokent – TURL-ekre feltölthetőek az állományok● statusOfPutRequest: token segítségével statust kaphatunk
    • Storage Controller letöltés● prepareToGet: több file is letölthető meg kell adni az SURL-eket minden állományhoz kapunk TURL-eket és kapunk egy tokent – TURL-ekre letölthetőek az állományok● statusOfGetRequest: token segítségével statust kaphatunk
    • Példa: letöltés az StC-rőlSURL: 2fa00259­15b5­42b7­92df­863e5522758f/ipipida875a / előtti rész azonosítja az StC­tprepareToGet([2fa00259­15b5­42b7­92df­ 863e5522758f/ipipida875])válaszként kapunk egy vagy több TURL­t, pl.:http://storage.niif.grid:21113/3cec12a2­ca12­4776­8bf4­ 56fdb5c1457d.0$ wget http://storage.niif.grid:21113/d6269631­3746­ 4174­ba45­bb0d7b3f45e5.0 http://storage.niif.grid:21113/d6269631­3746­4174­ba45­ bb0d7b3f45e5.0    => `d6269631­3746­4174­ba45­bb0d7b3f45e5.0$ cat d6269631­3746­4174­ba45­bb0d7b3f45e5.0   Szöveg.
    • Storage Manager (StM) felület● get, put, cp, rm, stat, mv, ls, mkdir,  rmdir● rekurzivitás: cp, rm, mv, ls● felülírási módok: – felülír – megszámoz – figyelmen kívül hagy – hibát jelez és leáll● mindegyik LFN-eket használ (nem GUID-ot, nem SURL-t)
    • Példa: file feltöltése
    • Feltöltés: put1. a felhasználó megadja a kívánt LFN-t, és a file méretét6. válaszként kap egy TURL-t, amelyre feltöltheti a állományt
    • Feltöltés: prepareToPut2. a Storage Manager előkészíti a feltöltést a Storage Controllernél: átadja a file méretét (az LFN-t nem)3. válaszként kap egy SURL-t és egy (vagy több) TURL-t (a TURL-t majd a felhasználónak adja vissza)
    • Feltöltés: katalógus4. a Storage Manager generálegy GUID-ot az újállományhoz, elkészíti az XMLdokumentumot, és tárolja akatalógusban5. az LFN-hez tartozószülőkönyvtárba be kelljegyezni az új állományt,módosítani kell akatalógusbejegyzést6. végül vissza lehet adni aTURL-t a felhasználónak
    • VII. Hova tovább?
    • Összefoglalás● ClusterGrid: működik, használható, folyamatosan új szolgáltatásokkal bővül – intézményi szinten is használható, könnyen telepíthető klaszter számítási erőforrás komponens● Adattárolás: hatékony, gazdaságos, ismert technológiákra épített adattárolási erőforrás Coraid (AoE) alapokon. Intézményi szinten általánosan is használható● GUG: könnyen telepíthető egyszerű web szolgáltatás keretrendszer, gazdag szolgáltatás kínálattal
    • Jövő● ClusterGrid: desktop erőforrások bevonása● Új GUG szolgáltatások: – teljes körű AAI integráció – grafikus/web kliensek – intelligens ütemezési algoritmus – elosztott állomány rendszer(?) – tartalom management● Új probléma: elosztott szolgáltatás management
    • Referenciák● ClusterGrid: http://www.clustergrid.hu● Coraid: http://www.coraid.com● GUG: http://gug.grid.niif.hu, http://www.sf.net/projects/gug● Avaxio Informatikai Kft.: – Coraid eszközök magyarországi forgalmazója és támogatója – GUG alapú ipari grid rendszerek támogatója