hledat:

7   MetaCentrum

Projekt MetaCentrum rozšiřuje infrastrukturu akademické vysokorychlostní sítě o podporu aplikací, vyžadujících rozsáhlé výpočetní kapacity. Vlastním cílem projektu MetaCentrum je propojení stávající a další rozšiřování výpočetní kapacity největších akademických center ČR.

Systémy projektem spravované vytváří virtuální distribuovaný počítač, v poslední době označovaný jako Grid (výpočetní mřížka). Smyslem aktivit je jednak odstínit uživatele od nepodstatných rozdílů mezi jednotlivými konkrétními systémy, tvořícími Grid, jednak umožnit jejich synchronní využití a poskytnout tak výpočetní kapacitu přesahující možnosti jednotlivých center.

Projekt má vlastní provozní část, odpovídající za zajištění funkčnosti vlastní infrastruktury, a rovněž část vývojovou, v jejímž rámci jsou rozvíjeny a testovány nové metody a techniky vytváření a podpory Gridů. Nedílnou součástí projektu je podpora mezinárodních aktivit sdružení CESNET i dalších akademických subjektů, zejména pak souvisejících se zapojením do projektů 5. rámcového programu Evropské unie. Informace o MetaCentru, včetně přístupu ke všem administrativním funkcím, jsou zprostředkovány portálem MetaCentra, dostupným na adrese meta.cesnet.cz.

Do řešení projektu MetaCentrum byla v roce 2001 zapojena následující centra:

• Ústav výpočetní techniky, Masarykova univerzita v Brně
• Ústav výpočetní techniky, Karlova univerzita v Praze
• Centrum informatizace a výpočetní techniky, Západočeská univerzita v Plzni
• Centrum výpočetní techniky, Vysoká škola báňská - Technická univerzita Ostrava

S výjimkou posledního jmenovaného pracoviště všechna přispívají výpočetními kapacitami, především pak velkými výpočetními systémy firem SGI a Compaq.

7.1   Provoz

Distribuovanému charakteru MetaCentra odpovídá rozmístění jeho výpočetních kapacit do čtyř lokalit ve třech městech: Brně (ÚVT MU), Praze (CESNET a ÚVT UK) a Plzni (CIV ZČU). Systémy na ÚVT MU, CESNETu a CIV ZČU jsou přímo připojeny na vysokorychlostní páteř CESNET2 vyhrazenou linkou s kapacitou 1 Gb/s. Systémy na ÚVT UK jsou přímo připojeny na metropolitní síť PASNET a jejím prostřednictvím na páteř CESNET2.

Vlastní výpočetní kapacity MetaCentra tvoří clustery s procesory Intel Pentium (architektura IA-32), zakoupené v letech 2000 a 2001 (v roce 1999 byla zakoupena vysokokapacitní pásková knihovna, poskytující celkem 12 TB online nekomprimované kapacity pro zálohování dat všech uzlů MetaCentra). Clustery jsou tvořeny vždy dvouprocesorovými jednotkami v rackovém provedení, s kapacitou 1 GB hlavní paměti na jednotku. Každý cluster má celkem 64 procesorů Intel Pentium III, s frekvencí 750 MHz a 1 GHz. Disková kapacita je 18 × 9 GB a 18 × 18 GB.

Na přelomu roku 2002/2003 bude dodán nový cluster, opět se 64 procesory v dual CPU rackovém provedení (výška 1U), tentokrát s procesory Intel Pentium 4 Xeon s frekvencí 2,4 GHz a diskovou kapacitou 18 × 36 GB (celková cena každého clusteru se postupně snižuje, přestože výrazně roste výkon i disková kapacita a v posledním roce i kapacita síťového připojení, viz dále). Výrobcem je stejně jako u clusteru zakoupeného v předchozím roce firma HP, letos však bohužel měla problémy se včasným dodáním.

V roce 2001 bylo celkem 128 procesorů clusterů rozděleno mezi ZČU, CESNET a MU v poměru 32:32:64. Na konci roku bylo 32 procesorů, pořízených v roce 2000 přestěhováno do Prahy a nové procesory budou umístěny v Brně, v roce 2003 bude proto rozdělení vlastního výkonu MetaCentra 32:64:96.

Přestože se fyzicky jedná o oddělené systémy, logicky jsou všechny clustery vybaveny stejnou verzí operačního systému Linux (distribuce Debian) a jednotně spravovány systémem PBS. Začátkem roku 2002 byla z prostředků MU zakoupena licence rozšířené verze PBSpro, kterou je postupně PBS nahrazována (kompletní náhrada proběhne až v roce 2003). Všechny uzly clusterů jsou samostatně adresovatelné a přímo přístupné z Internetu. Rozsáhlejší (dlouhodobější) využití uzlů je však možné pouze prostřednictvím systému PBS, aby bylo možno zdroje optimálně plánovat.

Všechny uzly clusterů byly vybaveny rozhraním Fast Ethernet (100 Mb/s). Pro vysokorychlostní přenosy byly v Brně a Plzni k dispozici i vysokorychlostní sítě Myrinet (vždy 16 uzlů v Plzni a Brně) a gigabitový Ethernet (16 uzlů v Brně). Výběr uzlů s konkrétním vysokorychlostním propojením umožňuje rovněž dávkový systém PBS, uživatelé tak mohou snadno zvolit požadované vlastnosti bez toho, že by znali přesné označení konkrétních uzlů.

V clusteru zakoupeném v roce 2002 (bude instalován v roce 2003) má každá jednotka 2 integrovaná rozhraní gigabitového Ethernetu. Rozhodli jsme se proto nerozšiřovat prozatím síť Myrinet a zakoupili jsme přepínače HP ProCurve 4108gl s celkem 90 GE rozhraními. Spolu se stávajícím GE přepínačem nám to umožní propojit všech 48 jednotek (96 procesorů) v Brně do GE sítě (z toho 32 jednotek bude propojeno duálním GE spojením). Vytvoříme tak největší cluster s takto rychlým propojením v ČR.

Kromě PC clusteru jsme v roce 2002 zakoupili první server se 64bitovou architekturou (IA-64) firmy Intel, vybavený 2 procesory Itanium II, 6 GB hlavní paměti a celkem 100 GB přímo připojené diskové kapacity. Server vyrobila firma HP a dodala jej v plně funkční podobě až koncem roku. Server v roce 2003 rovněž plně zapojíme do infrastruktury MetaCentra a zpřístupníme jej akademické komunitě v ČR tak, aby si potenciální zájemci tuto architekturu ji mohli vyzkoušet před vlastním nákupem.

Tento přístup se osvědčil již s dosavadními clustery, kdy pracoviště na Přírodovědecké fakultě MU v Brně zakoupilo - na základě zkušeností s využitím clusterů MetaCentra - vlastní cluster s více jako 80 procesory (rovněž Intel Pentium 4 Xeon). I tento cluster, obdobně jako podobný cluster v Plzni, bude integrován do MetaCentra a spravován analogicky jako ostatní výpočetní zdroje.

I v roce 2002 pokračovalo využití zálohovacích kapacit velkoobjemové páskové knihovny v Brně. Pravidelné zálohování zajišťuje systém NetWorker firmy Legato. Zálohují se všechny systémy MetaCentra, přenosová kapacita sítě CESNET2 je stále postačující přes rostoucí objemy zálohovaných dat. kapacita páskové knihovny je v současnosti využita na více jak 75 %.

Součástí infrastruktury poskytované MetaCentrem je i základní programové vybavení. Plný a aktuální přehled je možno vždy získat na webových stránkách MetaCentra. V rámci řešení jsme již dříve zakoupili a stále udržujeme v aktuálním stavu zejména překladače firmy Portland Group (důležité jsou zejména překladače pro jazyk Fortran, v němž je napsána podstatná část používaného aplikačního programového vybavení), ladicí a sledovací nástroje pro paralelní programy na clusterech TotalView, Vampir a Vampir Trace firmy Etnus a zejména rozsáhlý balík pro inženýrské výpočty Matlab. Samozřejmostí je MPI, a to jak ve formě volně šiřitelných verzí (LAM a MPICH), tak i komerční verze MPIpro, s ovladači na prostředí Myrinet.

MetaCentrum stále používá distribuovaný systém souborů AFS, v současné době však již téměř výhradně v Open Source verzi (OpenAFS).

7.1.1   Bezpečnost

Autentizaci uživatelů v rámci MetaCentra zajišťuje systém Kerberos 5. I v roce 2002 pokračovaly práce jednak na plné integraci používaných prostředků a systému Kerberos, jednak na transparentním propojení systémů Kerberos a PKI (založeném na certifikátech). MetaCentrum používá certifikační autoritu CESNETu a umožňuje přímý přístup uživatelům, kteří mají její platný certifikát.

Jednotlivé uzly MetaCentra přešly v průběhu roku 2002 na nové verze systému Heimdal (non-US implementace Kerbera 5, na které se podílí i pracovníci MetaCentra) a systému OpenSSH (3.4).

7.1.2   Informační služby

MetaCentrum spravuje na adrese meta.cesnet.cz web -MetaPortál, který poskytuje jak obecné informace uživatelům i dalším zájemcům ve veřejné části, tak i specifické informace pro uživatele a správce v autentizované části. V souladu s celkovou politikou MetaCentra je autentizace možná prostřednictvím systému Kerberos. K dispozici máme i plug-iny do prohlížeče Mozilla, které umí pro autentizaci použít aktivní uživatelův tgt tiket.

Web MetaCentra používá pro primární uložení informací systém správy verzí CVS, webové stránky jsou z těchto dat generovány (na žádost nebo automaticky). To umožňuje vysoce efektivně zpřístupňovat i semidynamická data, kde stránky nejsou generovány při každém přístupu, ale pouze po změně v primární "databázi".

Vlastní informační infrastruktura je postavena na kerberizovaném openLDAPu, je plně funkční a v provozu od druhé poloviny roku 2002. Tímto systémem jsou zpřístupněny všechny dynamické informace a rovněž informace o uživatelích. Řešili jsme i problémy spojené s replikací dat a zálohováním. Výsledky popsané v technické zprávě budou nasazeny v průběhu roku 2003.

Prostřednictvím MetaPortálu jsou uživatelům k dispozici i všechna osobní data, která nám svěřili. Uživatelé tak mají možnost okamžité kontroly všech svěřených dat a současně mohou data prostřednictvím MetaPortálu aktualizovat a opravovat. Uživatelé si tímto způsobem vybírají i systémy, ke kterým chtějí v rámci MetaCentra získat přístup.

Platnost účtů je omezena na jeden rok, prodloužení je rovněž zajištěno prostřednictvím MetaPortálu (uživatel musí napsat krátkou zprávu a potvrdit své osobní údaje, bez tohoto kroku mu nebude účet prodloužen).

Vlastní správu osobních dat a informací o účtech zajišťuje systém Perun, plně vyvinutý v rámci MetaCentra. V roce 2002 pokračoval rozvoj zejména jeho administrativní části, používané správci jednotlivých uzlů, a rovněž plnohodnotná integrace s openLDAP infrastrukturou. Systém v současné podobě umožňuje distribuované potvrzení žádostí o nový účet, změny oprávnění, kontrolu, prodlužování účtů a další aktivity, včetně upozornění na nevyřízené požadavky.

7.2   Globus, MDS a mezinárodní aktivity

Na hlavních systémech MetaCentra jsme instalovali systém Globus ve verzi 2 a zprovoznili jeho informační službu MDS ve verzi 2.2. Systém Globus vytváří základní infrastrukturu pro vzdálené spouštění úloh, což umožňuje propojit naše výpočetní kapacity do rozsáhlých mezinárodních Gridů. Bezpečnost systému Globus stojí na PKI, jehož propojení se systémem Kerberos jsme již dříve vyřešili. MetaCentrum přitom poskytuje mnohem rozsáhlejší služby než Globus, který proto není interně používán.

MetaCentrum v roce 2002 podporovalo několik mezinárodních aktivit jak v rámci sdružení CESNET, tak i jeho členů. Mezi nejvýznamnější patří samozřejmě zapojení do projektu DataGrid, kterému je věnován samostatný příspěvek, dále podpora projektu GridLab (řešen na ÚVT MU, viz www.gridlab.org) a zapojení do experimentů v rámci mezinárodní konference SC2002. Ta se v roce 2002 konala v Baltimore (USA, stát Maryland) a její součástí bylo jako každoročně několik soutěží. MetaCentrum, resp. jeho uzly se zapojily do dvou skupin: jednak do tzv. High Performance Computing Challenge a High Performance Bandwidth Challenge (viz http://scb.ics.muni.cz/static/SC2002).

High Performance Computing Challenge měla tři části:

• Most Innovative Data-Intensive Application
• Most Geographicall Distributed Application
• Most Heterogeneous Set of Platforms

Soutěže jsme se zúčastnili v rámci týmu vedeném profesorem Edem Seidelem z Ústavu gravitační fyziky Alberta Einsteina v Postupimi (SRN) a měli jsme na starosti vlastní zajištění Gridu. Podařilo se nám vytvořit Grid z 69 uzlů ve 14 zemích s celkem 7345 procesory, z nichž pro účely vlastního experimentu bylo k dispozici téměř 3500 procesorů. Jedním z uzlů byla i PlayStation 2 s instalovaným operačním systémem Linux (v Manchesteru). Geografické rozložení uzlů tohoto Gridu je vidět na obrázku 7.1. Aplikací byl distribuovaný výpočet vlastností černých děr. S tímto Gridem se podařilo zvítězit ve dvou ze tří uvedených kategorií, a to nejvíce distribuovaná aplikace a nejheterogennější Grid.

Cílem High Performance Bandwidth Challenge byla demonstrace aplikace, vyžadující největší datové toky na místo konání konference. K dispozici bylo celkem 3 × 10 Gb/s. Tento tým byl veden J. Shalfem z Lawrence Berkley Laboratory (LBL) a používal stejnou základní aplikaci jako v předchozím případě, v tomto případě však byla aplikace použita jako generátor primárních dat pro vizualizaci - zasílala se nezpracovaná data, která byla upravována (renderována) přímo na místě clusterem s 32 procesory (každý procesor měl 1 Gb/s připojení, teoretická kapacita byla tedy 32 Gb/s).

Data primárně generovaly velké počítače LBL a NCSA v USA plus dva systémy v Evropě: v Amsterodamu (Holandsko) a v Brně. Zatímco cluster v Amsterodamu používal vyhrazenou transatlantickou linku (s kapacitou 10 Gb/s), pro přenos dat z Brna jsme použili sítě CESNET2, Géant a Abilene. Namísto vyhrazené IP služby jsme se rozhodli experimentálně použít LBE (Less then Best Effort) službu, která umožňuje posílat do sítě data s maximální rychlostí (bez ochrany proti zahlcení) a síť sama tato data prioritně zahazuje, pokud skutečně po cestě k zahlcení dojde. Použitá aplikace využívala protokol UDP a vlastní real-time vizualizace není příliš náchylná na občasný výpadek dat (krátkodobé výpadky lidské oko ani nepostřehne, dlouhodobější lze aproximovat díky datům z jiných zdrojů).

Do uzlu sítě CESNET2 v Brně jsme za přispění provozní skupiny instalovali tříportovou GE kartu a propojili ji s clusterem, který tak získal teoretickou externí konektivitu 4 Gb/s. Současně byla dočasně povýšena mezinárodní linka Praha-Frankfurt na 2 Gb/s. V rámci vlastního experimentu se podařilo generovat trvalý tok 2 Gb/s mezi Brnem a Baltimorem po dobu dvou hodin (zatížení linek sítě CESNET2 je patrné z přiloženého obrázku 7.2). To představovalo téměř 12 % datového toku 16,811 Gb/s, se kterým tento tým zvítězil.

7.3   Uživatelé a výpočty

Kompletní přehled o uživatelích, rozložení využití MetaCentra a dalších parametrech bude možno nalézt v ročence MetaCentra za rok 2002, která vyjde v první polovině roku 2003. V současné době je k dispozici pouze MetaRočenka 2001, nicméně celkové trendy zůstaly zachovány i v roce 2002.

MetaCentrum má v současné době cca 200 aktivních uživatelů, spravovaných třemi administrativními uzly na ZČU, UK a MU zhruba v poměru 1:2:3. Největší uživatelé jsou z AV ČR a MU Brno (obé cca 1/3 celkové kapacity MetaCentra, třetím největším je pak UK s cca 1/6 celkové kapacity). Prozatím velmi slabé je využití zdrojů MetaCentra studenty a zaměstnanci technických vysokých škol (především ČVUT a VUT). Na zlepšení této situace jsme se zaměřili v roce 2002 úzkou spoluprací se Západočeskou univerzitou v Plzni. Konkrétně jsme se rozhodli ověřit použitelnost prostředí MetaCentra (zejména clusterů) pro řešení rozsáhlých úloh technického charakteru s cílem využít výsledky při propagaci mezi komunitou uživatelů z technických vysokých škol.

V listopadu a prosinci 2002 jsme provedli řadu testů výkonosti PC clusterů MetaCentra z hlediska použití softwarového CFD balíku FLUENT 6.0 od firmy Fluent International. Tento produkt je zaměřen na simulace v oblasti výpočtové mechaniky tekutin a již v minulosti bylo některé jeho části možné použít na superpočítačích či síti UNIXových stanic v paralelním běhu. Nyní je produkt plně paralelizován i pro platformu PC-Linux. Po provedených testech je jeho instalace na PC clusterech předána k rutinnímu užívání ostatním uživatelům, v první fázi především ze ZČU v Plzni.

Před prováděním testů jsme již od podzimu 2002 zkoumali možnosti FLUENTu z hlediska paralelního a distribuovaného běhu na PC clusterech MetaCentra. Na základě daných poznatků jsme připravili vhodné úlohy ve spolupráci se Škoda Auto a. s. Mladá Boleslav a NTC ZČU v Plzni. Zajistili jsme také ve spolupráci s dodavatelskou firmou FLUENTu TechSoft Engineering, s. r. o, pro omezené období (prosinec 2002) neomezený počet licencí pro FLUENT. Tento krok byl jedním z hlavních předpokladů prováděných testů, protože při paralelním běhu alokuje každý procesor, který se účastní výpočtu, jednu plovoucí licenci. O prováděné testy a jejich výsledky je ve firmě TechSoft Engineering zájem a předpokládáme, že nezůstane jen u ohlasu republikové úrovně.

Úlohy, které jsme připravili, představují jisté portfolio typických úloh různé náročnosti. Nejobjemnější je úloha představující simulaci externí aerodynamiky vozu Škoda Fabia Combi, jejíž výpočetní síť má 13 miliónů 3D buněk. Tato výpočetní síť byla vytvořena na superpočítači Compaq GS140 na ZČU v Plzni. Při řešení takové úlohy je třeba mít k dispozici přibližně 13 GB paměti, což přesahuje možnosti uvedeného superpočítače. Svou velikostí se řadí mezi náročné úlohy i ze světového hlediska. Další úlohy jsou již méně náročné, ale stejně se svými parametry řadí mezi typ úloh, ke kterým se uživatel běžně nedostane.

Používali jsme FLUENT 6.0.20, jehož instalaci jsme umístili na AFS buňku ZČU v Plzni. Při provádění testů jsme sledovali dobu výpočtu jedné iterace (z časových důvodů jich bylo prováděno pouze několik desítek, nebyla řešena vždy celá úloha), dobu načítání úlohy na metapočítač zvolené konfigurace a pro některé případy také dobu startu FLUENTu na metapočítači. FLUENTu lze při distribuovaném běhu nastavit různé komunikační protokoly, proto jsme měnili při provádění testů i tyto parametry. Pro cluster nympha (v Plzni) jsme museli provést downgrade ovladačů pro speciální komunikační karty Myrinet na verzi 1.5, protože FLUENT s novějšími, které byly původně nainstalovány (1.5.1), odmítal spolupracovat.

Původně jsme měli v plánu pro správu běhu testovacích úloh na PC clusterech použít dávkový systém PBS, povedlo se to ale pouze pro část testů. Hlavní příčina spočívala ve využití verze openPBS, která nemá vyřešeno spouštění úloh s podporou Kerbera (to v rámci MetaCentra řeší až dávkový systém PBSpro), museli jsme použít ssh namísto (pokerberizovaného) rsh. V takovém případě pak ale FLUENTu nefungovaly komunikátory Network MPI a Myrinet MPI, proto jsme část testů prováděli mimo PBS, kdy část PC clusterů byla ve zvláštním režimu.

V případě některých testů, které jsme chtěli zadávat ke zpracování přes systém PBS s tím, že využijeme větší část PC clusterů, jsme také neuspěli: PBS sice správně alokovala příslušný počet uzlů, ale nedošlo ke startu úlohy a vlastní test tak neproběhl. I v tomto případě jsme prováděli testy mimo PBS. Tento problém se týkal situace, kdy jsme na PBS chtěli z každé části clusteru (současně v Plzni, Praze i Brně) po osmi a více uzlech. Tyto výsledky testů jsme využili při ladění systému PBSpro tak, aby se již v nové verzi použitého dávkového systému nevyskytovaly.

Ve verzi 6.0 se objevily některé novinky, které jsme chtěli vyzkoušet i v rozsáhlém distribuovaném prostředí PC clusterů MetaCentra. Jednalo se například o možnost využití tzv. "dynamic load balancing", což je postup, který umožní rozumně využít dostupné zdroje v případě nehomogenního výpočetního prostředí (z hlediska výkonu).

Úlohy jsou načítány FLUENTem na jednotlivé výpočetní uzly, každému je přidělena stejně objemná část úlohy. Problém nastává v situaci (která je pro clustery MetaCentra typická), kdy jsou alokované výpočetní uzly různě výkonné. Pak celý výpočet čeká po každé iteraci v konvergenčním procesu výpočtu na nejslabší uzel a výpočet se tak zbytečně zdržuje.

FLUENT pomocí metody dynamic load balancing zjistí poměrnou výkonnost jednotlivých uzlů a pak reorganizuje rozdělení úlohy tak, aby doba výpočtu na jednotlivých uzlech byla stejná. Bohužel jsme zjistili, že tato metoda není ve verzi Fluent 6.0 funkční, nehledě na to, že vyžaduje použití grafického uživatelského rozhraní, což je pro praktické výpočty rozsáhlých úloh, spravovaných dávkovým systémem nepoužitelné.

Problémy nastaly také pro testovací úlohu s asi 5 milióny buněk, kterou jsme připravili s tzv. nekonformními síťovými rozhraními. Pro paralelní automatické načítání na jednotlivé uzly by tato rozhraní neměla působit žádné problémy v případě, že se neprovádí adaptace sítě. Zjistili jsme, že takovéto automatické rozdělení úlohy proběhlo pouze pro jednu konfiguraci metapočítače, pro další pak selhalo. Proto bylo od testů s touto úlohou upuštěno. Neznamená to ale, že se daný typ úlohy nedá na PC clusterech spočítat, pouze je třeba dopředu rozdělit úlohu pro konkrétní počet výpočetních uzlů. To vyhovuje výpočtáři, ale ne našim testům škálovatelnosti výkonu aplikace.

FLUENT vykazuje v rámci jedné části clusteru (do 32 procesorů) poměrně dobrou škálovatelnost (lineární zrychlení), a to i pro velké úlohy. Po překročení této hranice se výpočetní časy ještě lehce zkracují (pro 40, 48, 56 procesorů), pro vyšší počet se ale opět prodlužují a například pro všechny použité procesory (158) je již čas výpočtu horší než pro 32 procesorů na jedné části clusteru. Zde se může negativně projevovat také nehomogenita clusteru, pro konfigurace metapočítače jsme použili stroje s procesory Intel Pentium III 700 MHz i stroje s AMD Athlon 1,9 GHz (minos, PC cluster na ZČU).

Výrazné je použití vysokorychlostní sítě (Myrinet, gigabitový Ethernet), zejména pro start FLUENTu a načítání úlohy. Když jsme použili standardního síťového komunikátoru (sokety), je pro větší počet zapojených výpočetních uzlů v metapočítači (nad 40 procesorů) alarmující doba startu FLUENTu. Ta činila v takových případech i několik hodin, při použití 158 procesorů to pak bylo asi 7 hodin. Když jsme použili Network MPI, FLUENT nastartuje i v takové konfiguraci metapočítače během několika málo minut. Daní za to je pak ale zhoršení času jedné iterace, která místo 44 sekund (sokety) trvá asi 49 s.

Ve dvojici tabulek jsou uvedeny částečné výsledky pro velikou úlohu se 13 milióny buněk - obtékání auta.

Poznámky k tabulce 7.1

Pro počty procesorů 8-32 jsou měření prováděna na clusteru nympha (Plzeň), pro počty procesorů 8-15 po jednom CPU na stroji, dále pak s využitím obou procesorů strojů.
Poznámka 1: Pro počty procesorů 32-158 jsou brány 4 části clusteru nympha, minos, skurut, skirit, vždy rovnoměrně rozdělený počet alokovaných výpočetních uzlů.
Poznámka 2: Tato konfigurace je 16 strojů po dvou procesorech na každém z clusterů nympha, minos a skurut.

Poznámka k tabulce 7.2

Pro počty procesorů 32-158 jsou brány 4 části clusteru nympha, minos, skurut, skirit, vždy rovnoměrně rozdělený počet alokovaných výpočetních uzlů.

Vidíme, že pro cluster nympha je použití Myrinetu pro malý počet CPU zanedbatelné, význam poroste u vyššího počtu CPU (rozdíl je vidět již u 20 CPU), kdy patrně roste komunikace během výpočtu. Vliv Myrinetu jsme poznali při sledování doby načítání úlohy na metapočítač, která je pak až dvakrát kratší. Z hlediska celkového reálného výpočtu je to ale marginální.

Network MPI (tedy použití MPI přes celý distribuovaný systém - byla použita implementace LAM) je horší při načítání úlohy i při vlastním výpočtu. Pozitivní je pouze doba startu FLUENTu, kde se jedná o zlepšení o několik řádů oproti komunikaci přes sokety. I to je ale pro "rozumný" počet CPU (cca do 40) a reálně náročnou úlohu (tj. úlohu, která počítá několik dní) pouze zanedbatelná výhoda.

Malý počet měření zatím neumožňuje formulovat jednoznačnější závěry a zejména doporučení - to bude úkolem práce v první polovině roku 2003.

Závěrem lze říci, že i část PC clusteru, tedy například 16 dvouprocesorových uzlů s 16 GB paměti lze použít jako výkonný nástroj pro zvládnutí vysoce náročných CFD úloh. Pozitivní je i možnost použití některého ze superpočítačů pro přípravu definice rozsáhlých úloh, v některých případech nelze totiž úlohy připravovat přímo v paralelním běhu FLUENTu (tato část není paralelizována).

předchozí

obsah

následující