ClusterGrid infrastruktúra: Hogyan? Stefán Péter,
[email protected] Szalai Ferenc,
[email protected] Vitéz Gábor,
[email protected]
Miről lesz szó? n n
n
ClusterGrid infrastruktúra projekt: Előzmények, jelen Hogyan készítsünk egy laborból szuperszámítástechnikai erőforrást? Hogyan használjuk fel azt? E három téma reményeink szerint lefedi a 3-szor 45 percet, mindenki legnagyobb örömére ☺.
2
A cél n
Választ kapni arra a kérdésre, hogy hogyan lehet egy hétköznapi laborból nagy teljesítményre alkalmas eszközt készíteni és azt országos rendszerbe kapcsolni?
3
ClusterGrid infrastruktúra projekt: Előzmények, jelen
4
Egy kis történelem... n
n
n n n n
2002 tavasz: OM-NIIFI pályázat, mely során az intézmények számítógépes laborokra pályázhattak. A nyertes intézményeknek e laborokat szuperszámítás-technikai célokra is elérhetővé kellett tenni. Kezdeti „nem tudjuk hogyan lesz ebből grid” érzés. NIIF, MTA-SZTAKI, ELTE, BME: Műszaki Bizottság. Kezdeti megoldás: egyetlen hatalmas Condor pool. Amit azóta, technikai értelemben, kinőttünk...
5
A kezdeti probléma, egy gyermek kérdései n
n n
n
n
Van (lesz) rengeteg csomópontunk, melyeket menedzselni kell. Hogyan? Biztonságosan kell őket összekötni. Hogyan? Szuperszámítás-technikai felhasználóknak kell ezeket az erőforrásokat elérni. Hogyan? Ha hiba történik a rendszerben, meg kell találni. Hogyan? ...
6
Egy lehetséges válasz: ClusterGrid n n
n
n
n
Rendszeres „brain-storming” + dokumentáltság. Akinek már van ebben tapasztalata, az „kiélhette alkotói hajlamait”. Többrétű szakértelem, különböző területek szakemberei és a felhasználók is képviseltették magukat. „A működéshez minimálisan szükséges” filozófia (nem bedőlni, nem feltételezni, nem építeni kártyavárat). Eredmény: ClusterGrid infrastruktúra „dizájn”. 7
A ClusterGrid infrastruktúra
8
ClusterGrid infrastruktúra n
n n n n n
Szerepek szerepe: mindenkinek megvan a szerepe ☺. Az „infrastruktúra-jelleg” kiemelt szerepe. Elosztott rendszer, elosztott problémák... ... de legalább homogén környezetben. Cluster és Grid jelentése. Vannak számító csomópontok, helyi kiszolgálók, globális kiszolgálók, felhasználói belépési pontok.
9
A dilemma: Bill, vagy nem Bill? n
n n
n
A gépek kettős célra lettek allokálva: egyrészt oktatási, szolgáltatási célra, másrészt szuperszámítás-technikai célra. A két feladatnak más-más gyökerei vannak. Oktatási, szolgáltatási célra irodai környezet: rendszerint Windows és ami azzal jár.
Szuperszámítás-technikai célra: Unix világ.
10
A kettős cél feloldása n
n n
n
Egy lehetséges, kényelmileg elfogadható, és a biztonságot is egy meghatározott szinten figyelembe vevő megoldás: „dual-boot” gépek, a célnak megfelelően. Egy új popularisa kifejezés: elválasztás (separation). Időbeli skálán „nagyszemcsés” elkülönítés: nappali illetve éjszakai üzemmódok. Talán lehet ezt máshogy is, de ez még a jövő kutatási tárgya.
11
Réteges modell Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
12
A fizikai réteg – gépek szerepe Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
13
Fizikai réteg – gépek szerepe n
Fizikai szinten gépeket látunk, ahol minden gépnek egy jól meghatározott szerepe van: q
q
Számítási csomópont (exec node): Feladata a számítási feladatok elvégzése. CPU-t, memóriát, ideiglenes tárolási területet biztosít (swap and scratch). Helyi kiszolgálók (local master): Dedikált eszköz, melynek feladata cluster-szintű szolgáltatások biztosítása. NFS kiszolgálás, erőforrás menezsment, DNS, hálózati boot szolgáltatások. 14
Fizikai réteg – gépek szerepe q
q
q
Grid-szintű kiszolgáló gépek (service): Általános szolgáltatásokat nyújtanak, mint például OS tükrözés, DNS root. Belépési pontok (entry): A felhasználók számára nyújt az erőforrásokhoz belépési, fordítási, fejlesztési, párhuzamosítási környezetet. (Egyéb szerepek: majd az élet produkálja őket.)
15
Kapcsolati réteg – elválasztás alacsony szinten Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
16
Kapcsolati réteg – elválasztás alacsony szinten n
n
Szeretnénk, ha a grid forgalom és a normál forgalom elválna egymástól: egyszerűség, átláthatóság, hosszabb távon megbízható működés. VLAN-oknak kulcs szerepük van.
17
Hálózati kapcsolati réteg – IP/VPN Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
18
Hálózati kapcsolati réteg – IP/VPN n
n
n n n n
n
A feladat az, hogy biztonságosan összekapcsoljuk az egyes erőforrásokat. Egy lehetséges megoldás: privát hálózati technológia. „Hálózat a hálózatban.” Több lehetőség is van: IPSec, OpenVPN, MPLS. Teljesítmény + biztonság + ésszerűség: MPLS. Hány hálózati kártyánk van? Hogyan tudunk eljutni a legközelebbi MPLS eszközig? Miért nem az Internet? Grid szoftverek gyerekcipőben. 19
Hálózati kapcsolati réteg – IP/VPN
20
Operációs rendszer réteg - mit-hogyan? Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
21
Operációs rendszer réteg – mit-hogyan? n n n n
n
Mi legyen a „grid operációs rendszer”? Hogy mi nem, azt tudjuk... Felhasználói kultúra – Cray, Unix környezet. Előbb RedHat, majd Debian környezet – minimalista filozófia. Operációs rendszer feladatok: q A PC-n: A könnyű menedzselhetőség végett diszk nélküli Linux környezet. q A szerveren: Ezt kiszolgáló környezet, és annak minden velejárója. 22
Operációs rendszer réteg – mit-hogyan? PC: n Root file rendszer hálózatról jön. n Egységes kliens image. n A hatékony IO végett helyi scratch és swap terület. n BIOS trükkök. n Hogyan boot-olnak be a gépek normál, illetve grid üzemmódban? q q
Hálózati boot, Diszk, CDROM boot, Linux BM boot.
23
Operációs rendszer réteg – mit-hogyan? Szerver: n Közös részek láttatása – NFS. n Hálózati boot és az azt támogató elemek: TFTP szolgáltatás, „dupla” DHCP szolgáltatás. n Privát hálózat kiszolgálásának OS elemei: DNS, szoftver update mechanizmus. n Magasabb rétegek kiszolgálása mind a helyi szervert terheli.
24
Erőforrás réteg – ami összefogja a gépeket Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
25
Erőforrás réteg – ami összefogja a gépeket n
n
n
Az erőforrás réteg felel a gépek egyetlen erőforrássá, számítási cluster-ré való alakításában. Masszívan építve az alacsonyabb rétegek technológiáira. Feladatok: q Erőforrás menedzsment, feladatok helyi kezelése, q Párhuzamos kommunikációs lehetőségek biztosítása.
26
Erőforrás réteg – ami összefogja a gépeket n
n
Erőforrás menedzsment elindítja, megállítja, checkpoint-olja, egyszóval felügyeli a felhasználók feladatait, illetve a cluster-ben elérhető számítási erőforrásokat. Feladat menedzsment eszközei: q Condor ütemező (támogatott), q SGE (reméljük mielőbb támogatott), q ...
27
Erőforrás réteg – ami összefogja a gépeket n
n
A párhuzamos program-elemeknek kommunikálniuk kell egymással. Elindulhatunk a kályhától (TCP socket), de nem feltétlenül szükséges: vannak párhuzamos kommunikációra alkalmas kommunikációs könyvtárak, melyek sok terhet levesznek a vállunkról. q q q
PVM (támogatott), MPI (korlátozottan támogatott), OpenMP (ki tudja...).
28
Grid réteg – ami összefogja a cluster-eket Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
29
Grid réteg – ami összefogja a cluster-eket n
n n
n
Egy cluster szép, jó, de nem skálázható a végtelenségig. Kb. 100 csomópont felett már bajok lehetnek. Megoldható az összekötés az erőforrás rétegben, de itt is súlyos bajok vannak (Condor barátságos pool-ok). Alapvető probléma: hogyan vigyük át a felhasználó feladatának környezetét egyik gépről (esetleg egyik cluster-ből) a másikba?
30
Grid réteg – ami összefogja a cluster-eket n
n
n
n
Elosztott erőforrás-kezelési koncepció: grid információs rendszer, grid bróker, globális ütemező, ágens-alapú technológiák... Szolgáltatás alapú vs. Web tranzakció alapú megoldások. Itt már nagyon számít a platform-függetlenség, és a heterogén környezet hatása. Hol élnek a felhasználók és hol a feladataik?
31
Grid réteg – ami összefogja a cluster-eket
32
Alkalmazási, vagy job réteg – végre Alkalmazási, vagy job réteg Grid réteg Erőforrás réteg Operációs rendszer réteg Hálózati kapcsolati réteg Kapcsolati réteg Fizikai réteg
33
Alkalmazási, vagy job réteg – végre n
n n n
Itt a felhasználó programoz, fejleszt, fordít (néha ordít), futtat, és az eredményeket vizsgálja. Hogy hogyan, arról később. Ki mit szeret kérdés: CLI vagy web-es portálfelület? Checkpointing kérdéskör. Hogy állítjuk össze a job-ot?
34
Vége az első résznek. (Ne örüljetek, van még!!!)
35
Egy labor telepítése
36
Installáljunk! Egy cluster telepítése három főbb munkafázisból áll: n Megfelelő hálózati konfiguráció kialakítása. Ezen belül q VLAN-ok elkészítése, q csatlakozás a privát hálózathoz, q MPLS „kijárat” elkészítése. n Kliens PC-k felkészítése. n Szerver telepítése. Egy kis türelem is igényeltetik persze. 37
Szerver telepítése n
n
n n
Mielőtt installálunk... q Kell egy dedikált szerver. q Meg kell győződnünk arról, hogy a szerver hardver felépítése illeszkedik-e az install CD kernel paramétereire. Ha nem
[email protected]. q Kell egy újraírható boot CD. A mindenkori boot CD install image letölthető a projekt web lapjáról. Innen letölthető az „Install Hogyan” dokumentum is. Boot-oljuk be bátran a CD-t!!! 38
Szerver telepítése – első lépés n
Kell egy 16MB-os boot partíció, kb. 512 MB swap, a többi diszk mehet LVM-be.
clgr_makefs iptunnel add grid0 mode gre local 193.6.222.233 remote 195.111.97.2 ttl 255 debootstrap –arch i386 stable /mnt ftp://10.250.255.250/pub/debian n
Kernel bemásolás a /mnt alá. Initrd bemásolás. Chroot a /mnt-be, majd lilo. /etc/apt/sources.list beállítása a saját csomagokhoz. 39
Szerver telepítése – második lépés apt-get update apt-get install xfsprogs lvm10 mount –t proc proc proc vgscan vgchange –a y lilo n
Hálózati beállítások, lásd később.
apt-get remove ... apt-get install vim less screen dpkg-reconfigure --all
40
Szerver telepítés – harmadik fázis n n
ClusterGrid specifikus elemek telepítése Kell a PC-k MAC címe!
apt-get apt-get apt-get apt-get apt-get
install install install install install
clgr-server clgr-client-initrd clgr-client-image clgr-condor-static clgr-service-util
41
Szerver telepítés – negyedik fázis n n n
Bróker rendszer telepítése. Kell Apache-SSL, PHP, PostgreSQL. Külön tanúsítvány a brókernek, külön az Apachenak.
apt-get apt-get apt-get apt-get n
install install install install
idregister libnss-dynmap clgr-broker clgr-broker-exec clgr-broker-condor
És még pár apróság... (lásd melléklet). 42
Az LVM kötetmenedzselő n
Cél: rugalmas diszk menedzsment.
43
Az XFS file rendszer n
n n
SGI által fejlesztett, az EFS kiváltására tervezett file rendszer. Linux alatt is elérhető és használható. Főbb jellemzői: q „Journal” file rendszer. q Nagy/kis file-ok/jegyzékek támogatása. q File rendszer méret változtathatóság. q Nagy átbocsátó-képesség, különösen NFS alkalmazások esetén. 44
Hálózati konfiguráció n
n
n
A legkeményebb, legnagyobb körültekintést igénylő pontja az egész folyamatnak. Rendszerint a legtöbb problémát is hálózati elkonfigurálás okozza. Tisztában kell lenni a PC-labor körüli hálózattal, célszerű rajzolni, és célszerű átgondolni azt, hogy hogyan illeszkedik a grid konfiguráció a jelenlegi hálózati konfigurációba.
45
Hálózati konfiguráció n
n
n
A konfiguráció függ attól is, hogy a szerverben hány hálózati csatoló van, illetve hogy milyen úton jutunk el a HBONE határt jelző eszközig. A hálózati konfiguráció attól is függ, hogy milyen címeket kapnak a labor gépei nem-grid üzemmódban. VLAN-okban kell gondolkodni!
46
Hálózati konfiguráció – a 4 VLAN n n
n
n
PNET: Publikus, kifelé forgalomirányított hálózat. LNET: Nem publikus, kifelé NAT-olt, vagy proxy-zott hálózat (vagy PNET, vagy LNET, vagy mindkettő van). VNET: A privát hálózat felé néző, privát, rendszering pont-pont jellegű kapcsolat (kötelező). GNET: Grid kommunikációra dedikált, külön VLAN (kötelező).
47
Hálózati konfiguráció – példa n
Adott egy 20-gépes labor, az alábbi konfigurációban:
n
Itt a gépek 192.168.0.1-20 címeket kapnak egy DHCP szervertől, melyet kifelé egy Linux tűzfal (VLAN-ok közötti tűzfal) NAT-ol. 48
Hálózati konfiguráció – példa n
n n
n
n
Az LNET 192.168.0.0/24 az 1-es VLAN, a PNET a 193.6.222.233/25 tartomány, 2-es VLAN. Egybefüggő layer-2 kapcsolat. A Linux tűzfal egyetlen fizikai interfészén létrehozott, egyik logikai interfésze az LNET-be a másik a PNET-be lát bele, trunk portokon és interfészeken keresztül. Tegyük fel, hogy a HBONE eszköz felé vezető „uplink” felé layer-3 eszköz van (véget ér a layer-2 kapcsolat). GNET, azaz a GRID VLAN száma: 3. 49
Hálózati konfiguráció – példa # vlan database #(vlan)# vlan 1 name LNET #(vlan)# vlan 2 name PNET #(vlan)# vlan 3 name GNET #(vlan)# exit # conf t #(config)# int range fa0/1 – 24 #(config-if)# switchport mode trunk #(config-if)# switchport trunk encapsulation dot1q #(config-if)# switchport trunk allowed vlan 1,2,3,10021005 #(config-if)# switchport trunk native vlan 1 #(config-if)# exit
50
Hálózati konfiguráció – példa n
n
n
n
n
Az összeköttetés módja a szerver és az MPLSképes eszköz között IP-GRE tunnel lesz a layer-3 eszközök miatt. Ennek szerver felőli oldalát majd a szerver installálás után készítjük el. Az MPLS-felőli router-ben az MPLS konfiguráció, illetve a tunnel létrehozása egy konfigurációval elvégezhető. A VNET tartománya: 10.250.255.160/30, a GNET tartománya pedig 10.250.40.0/24. A gépek hálózati boot-tal indulnak. 51
Hálózati konfiguráció – példa ip cef tag-switching tdp router-id Loopback0 call rsvp-sync
ip vrf GRID rd 1955:4 route-target export 1955:4 route-target import 1955:4
interface Loopback104 ip vrf forwarding GRID ip address 10.250.254.40
52
Hálózati konfiguráció – példa interface Tunnel500 ip vrf forwarding GRID ip address 10.250.255.61 255.255.255.252 tunnel source 195.111.97.2 tunnel destination 193.6.222.233 ip route grid 10.250.40.0 255.255.255.0 10.250.255.62 router bgp 1955 address-family ipv4 vrf GRID redistribute static no auto-summary no synchronization exit-address-family
53
Kliens felkészítés A kliens felkészítése grid üzemmódra az alábbi lépésekből áll: n Opcionálisan a Windows partíció zsugorítása, például BOOTITNG program segítségével (swap és scratch). n Kliens BIOS beállításai: q Powersave opciók kikapcsolása, q PXE, illetve wake-on opciók bekapcsolása. q Boot sorrend – első helyre: a hálózat kerül. n Partícionálás. 54
Vége az második résznek.
55
A grid rendszer felhasználása
56
Autentikáció n
n n
A ClusterGrid egyik legfontosabb újítása, hogy elválasztja a felhasználói azonosítást, az általa létrehozott job azonosításától. Hol él a felhasználó és hol él a job-ja? Melyek a legfontosabb előnyök? q anonimitás, q transzformálhatóság, a job önálló életre keltése, q számlázhatóság, q elosztott menedzselhetőség. 57
Autentikáció
58
Autentikáció
59
Felhasználói hozzáférés n
n
n
A belépési pontokon keresztül, SSH kliens, vagy web-portál segítségével. Itt a program fejlesztéséhez, párhuzamosításához, fordításához, feladat formálásához, feladásához, illetve a kapott eredmény elemzéséhez szükséges eszközöket talál (vagy visz oda). A felhasználási minták nagyon különböznek egymástól: párhuzamos programok vs. tömbfeladatok.
60
Felhasználói körfolyamat
61
Szoftver fejlesztés/beszerzés n n n n
n
n
A felhasználónak van egy problémája. Ehhez gyárt matematikai számítási-modellt. Elosztott számítási modellt (mivel a probléma nagy). A modell-t leprogramozza, vagy már kész szoftvert használ. Általában hasznosak a grafikus fejlesztői felületek: P-GRADE, de hagyományos eszközök is használhatók. A fejlesztés nyelve.
62
Párhuzamosítás n
n
n
n
Bölcs fejlesztőknél szorosan összefonódik a fejlesztési tevékenységgel. (A legbölcsebb felhasználók más programjait használják.) Párhuzamos alkalmazások esetén van értelme. (Tömb feladatoknál felesleges.) Szabványos könyvtárak állnak rendelkezésre: PVM, MPI, OpenMP. Nagyon fontos: az alkalmazott algoritmusnak párhuzamosíthatónak kell lennie! (Amdahl törvény).
63
Portolás, fordítás n n n n n n
Egy kód adott környezetbe ültetése. Látványtalan, nehezen automatizálható, nagy szakértelmet igényel, „rágós falat”. Fordítás, kód optimálás: általános kód vs. adott architektúrára optimált kód. Fordítók, GNU gcc, g77, g++, Intel icc, ifc. Free fordítók GNU g95. Portland csoport termékei. Programok link-elése: önálló tudomány. Fortan-C link-elés. Nagyon nehéz kérdés: futtatási környezet elmentése, illetve az erre való alkalmasság (checkpoint). 64
File-ok átvitele n
n
n
Helyi fejlesztés esetén a programok már helyben vannak. A feladó gépen minden, a feladat futtatásához szükséges elemnek (bináris, input, osztott könyvtárak, licenc állományok, környezeti paraméterek, ...) rendelkezésre kell állni. SCP, FTP.
65
Feladatok készítése n
n
n
n
Egy feladat (job) != egy statikusan linkelt bináris + input file + erőforrás leírás. Egy feladat (job) == több architektúrára elkészített, tetszőlegesen linkelt binárisok (több) + input file-ok + függőségek + környezeti beállítások + forrás + minden, ami a futtatáshoz kell. Feladatok dinamikus megjelenése: UNIX folyamatok, összefüggő feladat-rendszerek, workflow-k. Feladatok statikus megjelenése: file-ok megfelelő struktúrában – Jobdir formátum. 66
„Jobdir” formátum n n n n
Megfelelően struktúrát feladatok. Rend, transzformálhatóság (egyik rendszerből a másikba). „Meta-feladatok”, például fordítási feladat. Minden, ami kell, vándorolhat. JOB/bin JOB/lib JOB/input JOB/output JOB/src JOB/tmp
67
Egy egyszerű job elkészítése, feladása mkdir HOSTNAME cd HOSTNAME mkdir bin input output cp /bin/hostname bin/hostname_i386 cat >submit <<EOL [HOSTNAME] executable = hostname_i386 arguments = -f type = batch EOL clgr_submit .
68
Futás ellenőrzése, hibakeresés n
n
n n n
A feladatokat és az erőforrásokat az erőforrás bróker párosítja össze, automatikusan, a feladat futtatási igényeknek megfelelően. Használhatók a clgr_status, clgr_info parancsok. Feladatok ki is törölhetők: clgr_rm. Egy felhasználó csak a saját feladatait látja. Ha hiba történik valahol, arról a felhasználó értesül.
69
Eredmények ellenőrzése n
n
A felhasználó számára a nap fénypontja: kimeneti állományok ellenőrzése. A körfolyamat kezdődik újra: vagy új futtatás, vagy, rosszabb esetben, új program fejlesztése.
70
Vége az harmadik résznek.
71
A grid jövője n
n
n n n n
Egy biztos: folyamatos, megbízható számítási kapacitásra, az eredményeket eltároló, nagy, elosztott helyre mindig szükség lesz. Rossz hír: rajtunk is múlik, hogy hogyan fejlődik tovább. Fejlődés: szolgáltatás-alapú grid vs. web- alapú grid. Grid rendszerek közötti átjárhatóság protokollja. Hulladékhasznosítás. Megbízható szolgáltatás készítése, kisebb megbízhatóságú elemekből. 72
Kérdések? Észrevételek?
73
