4. 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!
5. 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
8. 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)
10. III. Számítási erőforrás:
Könnyen telepíthető HPC
klaszter kialakítása
GNU/Debian Linux alapokon
Wágner Ferenc
11. 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.
12. 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ó.
13. 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)
14. 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
15. 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
16. 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
17. 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.
18. 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.
19. 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.
20. 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.
21. 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;
22. 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
23. 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.
24. 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.
25. 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.
26. 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).
27. 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.
28. 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.
32. 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
33. 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
34. 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
35. 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 programok
ls l /dev/etherd/
cww 1 root disk 152, 3 20060410 08:23 discover
brwrw 1 root disk 152, 160 20060410 08:23 e10.0
brwrw 1 root disk 152, 161 20060410 08:23 e10.1
crr 1 root disk 152, 2 20060410 08:23 err
cww 1 root disk 152, 4 20060410 08:23 interfaces
cww 1 root disk 152, 5 20060410 08:23 revalidate
36. 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
37. 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
39. 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
40. 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
41. 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
42. 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
43. Példa szolgáltatás
class 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
44. 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
48. 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
51. 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
53. 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
54. Példa
●
ls, mkdir
$ grid storage ls /grid/tmp
$ grid storage mkdir /grid/tmp/proba
$ grid storage ls /grid/tmp
d 20060412 14:04 proba
●
put
$ cat szoveg
Szöveg.
$ grid storage put szoveg /grid/tmp/proba
put szoveg to /grid/proba/szoveg... done.
$ grid storage put szoveg /grid/tmp/proba
put szoveg to /grid/tmp/proba/szoveg.1... done.
$ grid storage put szoveg /grid/tmp/masnev
put szoveg to /grid/tmp/proba/masnev... done.
59. Példa: ls kiment (lokális)
zsombor@gridsite:~$ ls lR proba
proba:
total 8
drwxrxrx 2 zsombor zsombor 4096 Dec 15 15:40 bin
rwr—r 1 zsombor zsombor 58 Feb 24 13:11 submit
proba/bin:
total 80
rwxrxrx 1 zsombor zsombor 75948 Dec 15 15:40 ls
61. Példa: ls kimenet (storage)
$ grid storage ls R /grid/tmp/proba
/grid/tmp/proba:
58 20060412 17:09 submit
d 20060412 17:09 bin
/grid/tmp/proba/bin:
x 75948 20060412 17:09 ls
62. 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
64. 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
65. 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
69. 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
70. 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
71. Storage Controller
adattranszfer
Fü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
72. 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
73. 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
74. Példa: letöltés az StC-ről
SURL: 2fa0025915b542b792df863e5522758f/ipipida875
a '/' előtti rész azonosítja az StCt
prepareToGet(['2fa0025915b542b792df
863e5522758f/ipipida875'])
válaszként kapunk egy vagy több TURLt, pl.:
http://storage.niif.grid:21113/3cec12a2ca1247768bf4
56fdb5c1457d.0
$ wget http://storage.niif.grid:21113/d62696313746
4174ba45bb0d7b3f45e5.0
http://storage.niif.grid:21113/d626963137464174ba45
bb0d7b3f45e5.0
=> `d626963137464174ba45bb0d7b3f45e5.0'
$ cat d626963137464174ba45bb0d7b3f45e5.0
Szöveg.
75. 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)
77. Feltöltés: put
1. a felhasználó megadja a kívánt LFN-t, és a file méretét
6. válaszként kap egy TURL-t, amelyre feltöltheti a
állományt
78. Feltöltés: prepareToPut
2. 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)
79. Feltöltés: katalógus
4. a Storage Manager generál
egy GUID-ot az új
állományhoz, elkészíti az XML
dokumentumot, és tárolja a
katalógusban
5. az LFN-hez tartozó
szülőkönyvtárba be kell
jegyezni az új állományt,
módosítani kell a
katalógusbejegyzést
6. végül vissza lehet adni a
TURL-t a felhasználónak
81. Ö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
82. 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
83. 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
