ClusterGrid infrastruktúra: Hogyan? Stefán Péter, Szalai Ferenc, Vitéz Gábor,

Átírás

1 ClusterGrid infrastruktúra: Hogyan? Stefán Péter, Szalai Ferenc, Vitéz Gábor,

2 Miről lesz szó? 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

3 A cél 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

4 ClusterGrid infrastruktúra projekt: Előzmények, jelen 4

5 Egy kis történelem 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

6 A kezdeti probléma, egy gyermek kérdései 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

7 Egy lehetséges válasz: ClusterGrid 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

8 A ClusterGridinfrastruktúra 8

9 ClusterGrid infrastruktúra 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

10 A dilemma: Bill, vagy nem Bill? 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

11 A kettős cél feloldása 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

12 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

13 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

14 Fizikai réteg gépek szerepe Fizikai szinten gépeket látunk, ahol minden gépnek egy jól meghatározott szerepe van: 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). q 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

15 Fizikai réteg gépek szerepe 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. q 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. q (Egyéb szerepek: majd az élet produkálja őket.) 15

16 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

17 Kapcsolati réteg elválasztás alacsony szinten 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

18 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

19 Hálózati kapcsolati réteg IP/VPN 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

20 Hálózati kapcsolati réteg IP/VPN 20

21 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

22 Operációs rendszer réteg mit-hogyan? 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

23 Operációs rendszer réteg mit-hogyan? PC: Root file rendszer hálózatról jön. Egységes kliens image. A hatékony IO végett helyi scratch és swap terület. BIOS trükkök. 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

24 Operációs rendszer réteg mit-hogyan? Szerver: Közös részek láttatása NFS. Hálózati boot és az azt támogató elemek: TFTP szolgáltatás, dupla DHCP szolgáltatás. Privát hálózat kiszolgálásának OS elemei: DNS, szoftver update mechanizmus. Magasabb rétegek kiszolgálása mind a helyi szervert terheli. 24

25 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

26 Erőforrás réteg ami összefogja a gépeket 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

27 Erőforrás réteg ami összefogja a gépeket 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

28 Erőforrás réteg ami összefogja a gépeket 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

29 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

30 Grid réteg ami összefogja a cluster-eket 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

31 Grid réteg ami összefogja a cluster-eket 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

32 Grid réteg ami összefogja a cluster-eket 32

33 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

34 Alkalmazási, vagy job réteg végre 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

35 Vége az első résznek. (Ne örüljetek, van még!!!) 35

36 Egy labor telepítése 36

37 Installáljunk! Egy cluster telepítése három főbb munkafázisból áll: 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. Kliens PC-k felkészítése. Szerver telepítése. Egy kis türelem is igényeltetik persze. 37

38 Szerver telepítése 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 grid-tech@niif.hu. 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

39 Szerver telepítése első lépés 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 remote ttl 255 debootstrap arch i386 stable /mnt ftp:// /pub/debian 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

40 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 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

41 Szerver telepítés harmadik fázis ClusterGrid specifikus elemek telepítése Kell a PC-k MAC címe! apt-get install clgr-server apt-get install clgr-client-initrd apt-get install clgr-client-image apt-get install clgr-condor-static apt-get install clgr-service-util 41

42 Szerver telepítés negyedik fázis 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 install idregister libnss-dynmap apt-get install clgr-broker apt-get install clgr-broker-exec apt-get install clgr-broker-condor És még pár apróság... (lásd melléklet). 42

43 Az LVM kötetmenedzselő Cél: rugalmas diszk menedzsment. 43

44 Az XFS file rendszer 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

45 Hálózati konfiguráció 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

46 Hálózati konfiguráció 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

47 Hálózati konfiguráció a 4 VLAN 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

48 Hálózati konfiguráció példa Adott egy 20-gépes labor, az alábbi konfigurációban: Itt a gépek címeket kapnak egy DHCP szervertől, melyet kifelé egy Linux tűzfal (VLAN-ok közötti tűzfal) NAT-ol. 48

49 Hálózati konfiguráció példa Az LNET /24 az 1-es VLAN, a PNET a /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

50 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, #(config-if)# switchport trunk native vlan 1 #(config-if)# exit 50

51 Hálózati konfiguráció példa 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: /30, a GNET tartománya pedig /24. A gépek hálózati boot-tal indulnak. 51

52 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

53 Hálózati konfiguráció példa interface Tunnel500 ip vrf forwarding GRID ip address tunnel source tunnel destination ip route grid router bgp 1955 address-family ipv4 vrf GRID redistribute static no auto-summary no synchronization exit-address-family 53

54 Kliens felkészítés A kliens felkészítése grid üzemmódra az alábbi lépésekből áll: Opcionálisan a Windows partíció zsugorítása, például BOOTITNG program segítségével (swap és scratch). 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. Partícionálás. 54

55 Vége az második résznek. 55

56 A grid rendszer felhasználása 56

57 Autentikáció 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

58 Autentikáció 58

59 Autentikáció 59

60 Felhasználói hozzáférés 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

61 Felhasználói körfolyamat 61

62 Szoftver fejlesztés/beszerzés 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

63 Párhuzamosítás 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

64 Portolás, fordítás 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

65 File-ok átvitele 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

66 Feladatok készítése 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

67 Jobdir formátum 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

68 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

69 Futás ellenőrzése, hibakeresés 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

70 Eredmények ellenőrzése 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

71 Vége az harmadik résznek. 71

72 A grid jövője 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

73 Kérdések? Észrevételek? 73