hledat:

9   MetaCentrum

9.1   Všeobecné informace

Základním cílem projektu MetaCentrum je poskytnout akademickým uživatelům výpočetní prostředí, které plně využije možností vysokorychlostní počítačové sítě a současně uniformním způsobem zpřístupní výpočetní a diskové kapacity největších akademických výpočetních center České republiky. Hlavní důraz je kladen na podporu provozní infrastruktury, její potřeby a požadavky pak určují i zaměření nezbytných výzkumných a vývojových činností. Projekt MetaCentrum se současně snaží o úzkou spolupráci s mezinárodními projekty ve stejné oblasti tak, aby v ČR existovalo nezbytné odborné i technické zázemí.

Výsledkem projektu je národní grid, tj. virtuální distribuovaný počítač, který umožňuje jak synchronní využití výpočetních zdrojů, tak i možnost používat jednotlivé uzly bez přesné znalosti umístění a do jisté míry i architektury konkrétních počítačů. V rámci aktivit přímo podporovaných sdružením CESNET jsou rozšiřovány výpočetní kapacity clusterového typu (založené na architektuře IA-32), celkově však projekt integruje i další výpočetní kapacity (Alpha, SGI), diskové kapacity jednotlivých center (v řádu mnoha TB) a rovněž páskovou knihovnu, zakoupenou před lety sdružením a trvale využívanou pro zálohování a archivaci dat.

Hlavní cíl projektu je rozvoj a udržení provozu gridu. V oblasti vývoje došlo v roce 2003 k rostoucímu propojení s aktivitami, realizovanými pod mezinárodními projekty 5. rámcového programu EU DataGrid (kterému je v této zprávě věnována samostatná kapitola) a GridLab (projekt, na němž za ČR participuje Masarykova univerzita a jehož řešitelé se částečně překrývají s řešiteli projektu MetaCentrum).

Na řešení projektu se v roce 2003 podílely následující organizace:

• Ústav výpočetní techniky, Masarykova univerzita v Brně
• Ústav výpočetní techniky, Univerzita Karlova 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.

MetaCentrum rovněž přímo spravuje nebo poskytuje odbornou podporu při správě clusterů, pořízených konkrétními pracovišti vysokých škol. Jedná se především o NCBR (Národní centrum výzkumu biomolekul) na MU v Brně a dále o NTC (Národní technologické centrum) na ZČU v Plzni. Celkem se jedná o 165 takto spravovaných procesorů.

9.2   Provozní záležitosti

Základní struktura MetaCentra je již několik let stabilní. Tvoří ji čtyři lokality ve třech městech, a to v Brně (ÚVT MU), Praze a Plzni (CIV ZČU). V Praze jsou výpočetní zdroje rozmístěny na ÚVT UK a na CESNETu. Všechna centra mají vlastní připojení na vysokorychlostní páteř CESNET2. Toto připojení má kapacitu 1 Gb/s a může být podle potřeby i rozšířeno.

Základní výpočetní strukturu tvoří clustery s procesory s architekturou IA-32. Konkrétní rozmístění a základní charakteristika uzlů jsou následující:

• Brno: 32×Pentium III 1 GHz, 64×Pentium 4 Xeon 2,4 GHz
• Praha: 64×Pentium III 700 MHz
• Plzeň: 32×Pentium III 1 GHz

Celkem je k dispozici 192 procesorů vždy v dvouprocesorovém uspořádání (poskytujeme tedy celkem 96 uzlů) s 1 GB paměti na uzel. Disková kapacita se zvyšuje od 9 GB/uzel u nejstarších (a nejméně výkonných) uzlů přes 18 GB/uzel až na 36 GB/uzel u nejnovějších uzlů.

Všechny uzly clusterů jsou vybaveny sítí Fast Ethernet (100 Mb/s). Uzly clusterů v Plzni a v Brně jsou propojeny vysokorychlostními sítěmi. V Plzni se jedná síť Myrinet (1,2 Gb/s plný duplex), v Brně má každý uzel dvě aktivní rozhraní gigabitového Ethernetu (zapojena do kaskády přepínačů ProCurve firmy HP) a 16 uzlů je vybaveno rozhraním sítě Myrinet (přenosová rychlost až 2 Gb/s plný duplex). Toto uspořádání umožňuje jednak řešit úlohy i s enormními požadavky na meziuzlovou přenosovou rychlost, jednak testovat vliv různých rozhraní na škálovatelnost programů.

Výpočetní kapacity MetaCentra však nejsou omezeny pouze na clustery. Z prostředků sdružení byl koncem roku 2002 zakoupen server se dvěma procesory Itanium II (1 GHz, architektura IA-64) od firmy HP. Tento server (s kapacitou vnitřní paměti 6 GB a 100 GB lokální diskové paměti) sloužil především jako testovací prostředí pro tento typ architektury. Zjistili jsme, že reálně dosahovaný výkon byl kolem 140 % výkonu procesorů Pentium 4 Xeon s frekvencí 2,4 GHz. U výpočtů s programem sander (LES - equilibrace) se podařilo dosáhnout rychlosti téměř shodné s výkonem dvouprocesorové konfigurace MPI/shmem překládané PGI překladačem. Na druhé straně operace s velkými bloky paměti (rutiny mem* v knihovně libc) nejsou příliš optimální - reálná rychlost byla často pouze poloviční ve srovnání s procesorem Pentium 4 Xeon. Překladače pro architekturu IA-64 mají rovněž v implicitním režimu značně agresivní optimalizace (výrazné reorganizace operací v pohyblivé řádové čárce), což může způsobit chyby ve výpočtu.

Jednotlivá centra, zapojená do projektu, poskytují i vlastní výpočetní kapacity, tvořené především počítači SGI s procesory MIPS (ÚVT UK a ÚVT MU) a dále počítači Compaq s procesory Alpha (ZČU). Kromě výpočetních kapacit jsou rovněž k dispozici disková pole s celkovou kapacitou přes 5 TB.

Na všech uzlech clusterů běží operační systém Debian Linux, v průběhu roku 2003 došlo k povýšení na verzi 3.0. Všechny výpočetní kapacity MetaCentra jsou zpřístupněny prostřednictvím dávkového systému PBSpro, jehož údržba je finančně zajišťována Masarykovou univerzitou v Brně. Systém PBSpro spolupracuje i s nativními dávkovými systémy velkých počítačů (NQE). Instalovali jsme dále systém globus ve verzi 2.2.4 a zprovoznili bránu mezi tímto systémem a PBS. Ve druhé polovině roku probíhá i testování verze 3.0 systému globus.

Zálohování dat zajišťuje velkoobjemová pásková knihovna na ÚVT MU, s využitím systému NetWorker firmy Legato. Zálohují se všechny stroje a diskové kapacity, 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 již plně využita (při ukládání záloh na dobu alespoň tří měsíců).

Uživatelé MetaCentra mají k dispozici i rozsáhlé programové vybavení, jehož přehled je aktuálně k dispozici na stránkách portálu meta.cesnet.cz. Z prostředků projektu jsou hrazeny aktualizace vývojového prostředí na clusterech, a to jak překladače (Portland Group i Intel), tak i sledovací nástroje pro paralelní programy TotalView, Vampir a VampirTrace. Z aplikačně orientovaného prostředí je třeba zmínit zejména údržbu systému Matlab. Přístup k datům zajišťuje mimo jiné distribuovaný systém souborů AFS, na clusterech ve volně šiřitelné verzi OpenAFS.

9.2.1   Rozšíření v roce 2003

Protože zakázka z roku 2002 byla realizována až v únoru 2003, byly finanční prostředky tohoto roku využity nikoliv na další zvyšování růstu procesorů, ale na povýšení kapacity vybraných uzlů. Konkrétně bylo do nejnovějšího clusteru (s procesory Xeon) zakoupeno dalších 32 disků s kapacitou 36 GB a dále u poloviny uzlů zvýšena kapacita hlavní paměti na 2 GB. Toto rozšíření paměťové i diskové kapacity umožní využít ve větší míře pokročilých způsobů plánování, zejména pak odsunutí běžících úloh s nižší prioritou při příchodu úlohy s prioritou výrazně vyšší - tzv. preemptivní plánování. Tento způsob práce však vyžaduje, aby se stará (nízkoprioritní) i nová (vysokoprioritní) úloha současně vešly na disk i do paměti. Preemptivní plánování umožní rychlejší vyřízení krátkých uživatelských úloh s vysokou prioritou. Kromě rozšíření vlastních výpočetních uzlů jsme dále povýšili diskovou kapacitu front-endů jednotlivých clusterů a přikoupili další front-end (dual CPU Intel Pentium 4 Xeon 3 GHz).

S ohledem na stále rostoucí zájem o procesory s 64bitovou architekturou jsme zakoupili jednak počítač p615 firmy IBM se dvěma procesory Power4+ (1,2 GHz, 6 GB RAM), jednak server se dvěma procesory AMD-64 (pro tento počítač byl současně zakoupen operační systém SuSe Linux ve verzi podporující tyto procesory). Počítač IBM bude instalován v Brně, počítač AMD v Plzni. Zkušenost s těmito počítači bude mimo jiné využita i při rozhodování o případných nákupech v roce 2004.

Dále jsme v roce 2003 pořídili dalších 16 karet Myrinet a odpovídající rozšíření přepínače v Brně tak, aby bylo možno všech 32 uzlů (64 procesorů) Pentium 4 Xeon propojit touto vysokorychlostní sítí.

Akvizice nového software se kromě nákupu výše zmíněného operačního systému omezila na nákup superpočítačové licence programu Gaussian'03. Výpočty programem Gaussian tvoří téměř 50 % spotřebované výpočetní kapacity celého MetaCentra, přitom zakoupená verze obsahuje celou řadu rozšíření a zdokonalení, požadovaných uživateli.

9.2.2   Statistické údaje o provozu

Podrobnější statistické údaje o využití všech kapacit MetaCentra jsou za minulý rok k dipozici v Ročence MetaCentra, zde uvedeme pouze vybrané údaje o využití clusterů.

Zatímco průměrné celoroční využití clusterů je pouze 41 %, je v posledním půl roce patrný výrazný růst zájmu o tyto výpočetní kapacity:

• Využití za poledních 6 měsíců je 51 %
• Využití za poslední dva měsíce je 65 %
• Využití za poslední měsíc (listopad) je 80 %

Hlavní růst zájmu je o výkonné systémy s procesory Pentium 4 Xeon.

Celkově bylo (od 1. ledna do 12. prosince 2003) spočteno 24 524 úloh, což představuje téměř 39,5 tisíce dnů výpočtů. Jedna úloha v průměru využila 1,79 procesoru, je tedy zřejmé, že převažují jedno a dvouprocesorové úlohy. Na druhé straně několik uživatelů své úlohy spouštělo v průměru na 11 až 12 procesorech současně, což ukazuje i na zájem o využití pro středně paralelní úlohy (viz rovněž dále).

MetaCentrum má cca 200 uživatelů, z nichž cca 70 je výrazně aktivních. 7 nejaktivnějších uživatelů propočítalo na 45 % veškerého výpočetního času (statistiky se týkají clusterů, nikoliv velkých počítačů). Účty jsou přidělovány na rok, podmínkou prodloužení účtu je zpráva o využití kapacit, požadovaná vždy koncem kalendářního roku.

9.3   Informační služby

Základní informační branou MetaCentra je portál na adrese meta.cesnet.cz. Ten poskytuje jednak obecné informace pro neautentizované zájemce, jednak specifické informace pro uživatele - po autentizaci.

V oblasti informačních služeb je nosnou ideou využití adresářových služeb jako "výkladní skříně" pro důležitá data. Mezi základní cíle patří maximálně zjednodušit vyhledávání a získávání informací, které někde ve výpočetním prostředí existují (v různých částech infrastruktury, např. Perun či dávkový systém). Hlavním letošním úkolem se tak stala aktualizace adresářové služby MetaCentra, a to jak technologicky, tak jako výkladní skříně systému Perun.

Základní změny v rámci aktualizace informačních služeb:

Změna schématu

Úprava a rozšíření LDAP schématu pro prezentaci údajů o uživatelích. Používané schéma je rozšířením standardního schématu o specifické atributy. Cílem provedené úpravy je využít co nejvíce standardních schémat a tím zvýšit kompatibilitu. Využito bylo zejména schéma a doporučení eduPerson z projektu Internet2 (v oblasti informací o lidech) a rfc2307 (v oblasti informací o uživatelských kontech). Informace o novém schématu jsou součástí připravované technické zprávy o systému Perun [Kře04].

Propagace češtiny

Situace s využíváním české diakritiky u klientů adresářových služeb není stále úplně zvládnuta, použité řešení je kompromisní a umožňuje zachovat kompatibilitu a současně zpřístupnit klientům odpovídající skutečně české (resp. česky s veškerou diakritikou psané) informace.

Mechanismus distribuce dat z MetaDatabáze

Tato úprava, nezávisle na struktuře dat, umožní zabezpečit propagaci změn databáze do LDAPu v reálném čase. Pro některé klienty a aplikace může tato schopnost znamenat značné zlepšení služeb informační infrastruktury.

Infrastruktura adresářových serverů

Nový mechanismus distribuce dat z MetaDatabáze umožní nasazení zcela standardních mechanismů pro replikaci LDAP serverů. OpenLDAP umožňuje při replikaci používat autentizaci Kerberem.

9.3.1   Perun

Zásadním vývojem systému pro správu uživatelských účtů Perun je zavedení konceptu homogenních clusterů, tj. takových, kde jsou uživatelské účty na všech uzlech identické. Původní systém byl navržen v době, kdy tyto clustery ještě nebyly rozšířeny; přestože je byl schopen spravovat, nárůst počtu uzlů nad 50 začal působit nezanedbatelné výkonnostní problémy. Současné řešení, které odbouralo opakované časově náročné generování identických datových souborů, je připraveno na možné rozšíření clusterů až do tisíců uzlů.

Se správou velkých clusterů také souvisí nově vyvinutá část administrativního portálu dovolující přehledně sledovat stav propagace dat na jednotlivé uzly. Dalším vývojem v administrativním portálu je návrh a realizace systematického rozhraní zaměřeného na prohlížení a aktualizaci dat o uživatelích, spravovaných prostředcích, účtech apod.

Aplikační datové schéma bylo s ohledem na spolupráci v mezinárodních projektech rozšířeno o podporu PKI infrastruktury; systém dovoluje sledovat vazbu uživatelů na jejich X.509 certifikáty a následně generovat jejich mapování na konkrétní účty.

Publikování dat ze systému Perun do informační služby MetaCentra (LDAP) jsme aktualizovali tak, že je nyní kompatibilní se standardními schématy inetOrgPerson, eduPerson, a rfc2307. Dosavadní vývoj v použitém software (OpenLDAP) také dovolil zavést inkrementální propagaci změn do stromu LDAPu za plného provozu serveru, takže změny mohou být promítnuty bezprostředně poté, co nastanou (nikoli až při pravidelném nočním odstavení LDAP serveru).

Prozkoumali jsme i variantu použití SQL backendu LDAP serveru (tj. překlad LDAP dotazů na on-line dotazy do databáze), ale celkově ji hodnotíme jako nevyhovující (výsledky jsou shrnuty v bakalářské práci Miloše Malíka na FI MU).

Ve druhé polovině roku jsme přenesli centrální server systému Perun ze stanice SGI, která již nevyhovovala výkonnostně a začínala vykazovat hardwarové chyby, na nový server IA-32 s operačním systémem Linux. Současně také došlo k přechodu od databázového serveru Oracle 8.0 na aktuální verzi 9.2. To dovolilo i zavedení plnohodnotné kerberovské autentizace.

Současná architektura celého systému Perun je popsána v připravovanérozsáhlé technické zprávě. Zároveň jsme revidovali a kompletně zdokumentovali všechny databázové objekty.

Samozřejmostí byla celoroční běžná údržba systému, opravy chyb, udržování konzistence dat a podpora uživatelů.

9.4   Aplikace

I v roce 2003 jsme se snažili podpořit vývoj a použití skutečně rozsáhlých paralelních aplikací, synchronně využívajících větší počet uzlů jednotlivých clusterů.

9.4.1   Prohledávání stavového prostoru

V roce 2003 byl dokončen vývoj aplikace modelování konformačního chování molekul s použitím zařízení silové zpětné vazby (instalováno v laboratoři HCI na FI MU). Nosnou částí aplikace je výpočet stavového prostoru pro toto zařízení, který je pro velkou výpočetní náročnost implementován distribuovaně nad komunikačním modelem MPI. Výpočet využívá tzv. "Transposition Table Driven Scheduling" rozdělení výpočtu na jednotlivé uzly, představuje tedy distribuovanou aplikaci s velkým množstvím malých asynchronních zpráv vhodnou pro prostředí clusterů.

Kromě vyladění výpočtů ve smyslu aplikační oblasti [Kře03] jsme provedli sérii experimentů zaměřených na chování paralelního výpočtu. Výsledky lze shrnout následovně:

• Na jednom homogenním PC clusteru aplikace škáluje ve shodě s teoretickým limitem (daným mírnou nerovnoměrností distribuce výpočtu) až do dostupných 64 CPU.
• Výsledky jednoho výpočtu provedeného distribuovaně na clusterech v Brně a Plzni se neliší od výpočtu na jednom z těchto clusterů. To dokazuje původní hypotézu, že tento typ aplikace není závislý na latenci síťového propojení.
• Pokusné výpočty na více než 100 CPU ukazují, že pro netriviální zadání lze zřejmě dosáhnout lineárního škálování i při těchto počtech. Pro exaktní ověření tohoto tvrzení ale bude třeba ještě dořešit lepší rozdělení výpočtu zohledňující různý výkon nehomogenních CPU.

Dále jsme při uvedených experimentech identifikovali anomálie chování MPI:

• Při plném využití dvouprocesorových uzlů clusteru (tj. přiřazení dvou procesů výpočtu na tento uzel) je nezanedbatelná část jejich výkonu spotřebována režií MPI - to má za následek výraznou degradaci celkového výkonu.
• Po jisté době (poslání několika set až tisíc zpráv) dochází k zahlcení MPI, které se projeví dlouhotrvajícím voláním funkcí MPI, které jsou svojí definovanou sémantikou neblokující. Následkem je neúplné využití CPU, tj. také celková degradace výkonu. K tomuto efektu přitom dochází pouze s komunikátorem ch_p4 (tj. TCP spojení), při použití přímé komunikace přes Myrinet nebyl pozorován.

Všechny zmíněné výsledky byly prezentovány na konferenci EuroPVM/MPI a jsou uvedeny v článku [KPM03].

9.4.2   Fluidní dynamika

Také v roce 2003 jsme prováděli měření škálovatelnosti FLUENTu na PC clusterech MetaCentra. Tato měření měla za úkol doplnit chybějící údaje z konce roku 2002 a v druhé polovině roku 2003 poskytnout informace o chování tohoto paralelního výpočetního software z oblasti numerické simulace proudění na novém hardware, případně v nové verzi.

Při provádění testů jsme z důvodů porovnatelnosti použili stejnou sadu úloh, jako koncem roku 2002. Jedná se o jisté portfolio typických úloh různé výpočetní náročnosti, jsou použity různé výpočetní modely i postupy. Pro účely testů na PC clusterech je prováděno pouze několik iterací výpočtu. Doba trvání jedné iterace je základním ukazatelem průběhu výpočtu, sledovali jsme zároveň ale i další parametry, jako například dobu startu FLUENTu na vybrané části clusteru. Pro testování byly použity clustery v Brně (skirit) a Plzni (nympha a minos).

Benchmarky jsou prováděny na různém počtu procesorů clusteru při použití různých síťových komunikátorů a různých síťových zařízení. Pro počet procesorů 4 až 15 je použit jeden procesor výpočetních uzlů, pro 16 a více oba procesory výpočetního uzlu.

Při počtu procesorů 32 a více jsou brány čtyři části dostupných clusterů (nympha, minos, skirit a skurut v Praze) a je rovnoměrně rozdělen počet alokovaných výpočetních uzlů.

Výsledky pro FLUENT 6.0.12

Na obrázku a obrázku vidíme výpočetní časy v závislosti na počtu procesorů a komunikátoru pro jednu z náročnějších úloh. Lineární urychlení je téměř dosaženo pro síťové rozhraní Myrinet, ostatní (používající 100 Mb/s) jsou také solidní. Oproti očekávání použití Network MPI (NetMPI), které je určeno právě pro clustery, nepřináší zvýšení výkonu. Tomu nepomůže ani gigabitový Ethernet na clusteru minos.

Na obrázku je vidět, že pro sockety dochází do počtu procesorů 56 ještě k malému urychlení výpočtu, pak již nastává zhoršení. Pro Network MPI je situace ještě horší.

Výsledky pro FLUENT 6.1.22

Ve druhé polovině roku jsme na plzeňské AFS nainstalovali novější verzi FLUENTu. Je připojitelná pro běžné uživatele pomocí příslušného modulu. Na novějších strojích, které jsou součástí clusteru skirit, jsme provedli v rámci limitu dostupných licencí doplňkové testy středního rozsahu. Cílem bylo zejména porovnat chování FLUENTu na Myrinetu (2 Gb/s) a gigabitovém Ethernetu. Úlohy byly na clusteru spouštěny prostřednictvím dávkového systému PBSPro běžnou cestou bez zvláštních privilegií.

Zjistili jsme, že nová verze FLUENTu neklade tak přísné požadavky na nainstalované ovladače pro Myrinet. Také příprava konfiguračních souborů pro běh FLUENTu na Myrinetu se zjednodušila. Naproti tomu jsme byli nuceni provést některé úpravy v instalaci FLUENTu, abychom vyšli vstříc specifickému prostředí PC clusterů MetaCentra, se kterým vývojáři nepočítali.

Na obrázku vidíme časy iterace pro jednu ze středně náročných úloh pro různé komunikátory. Bohužel při použití Myrinetu nejsou v této verzi FLUENTu k dispozici obvyklé detailní zprávy o průběhu paralelního výpočtu, uváděné hodnoty jsou zjištěny nepřímo a tedy nepřesně.

Pro uživatele je potěšující, že funguje dobře Network MPI, z hlediska iteračního procesu jsou (pro všechny úlohy) komunikátory rovnocenné, i když Network MPI a Myrinet mají lehce lepší výkon. Na obrázku je uvedeno urychlení výpočtu vzhledem k nejmenšímu počtu použitých procesorů pro daný benchmark (úlohu). Vidíme, že pokud úloha běží na strojích, kde je druhý procesor volný (do 14 CPU), škálovatelnost je solidní, na úrovni SMP superpočítačů.

Na obrázku je vidět dobu nabíhání všech procesů na všechny výpočetní uzly, které se účastní výpočtu. Zde je oproti předchozí verzi vylepšen komunikátor Network MPI. Na obrázku je doba načítání středně náročné úlohy a její distribuce na jednotlivé výpočetní uzly. Opět pro vyšší počet procesorů není vhodné používat sockety. Pro představu je na obrázku uveden objem dat, který je pro jednotlivé úlohy přenášen během výpočtu mezi výpočetními uzly při každé iteraci.

FLUENT s novou verzí 6.1.22 dospěl do fáze širší použitelnosti a vyšší stability i na rozsáhlejších PC clusterech typu MetaCentra.

Umíme odpovědět uživateli, který se zajímá, jestli se mu vyplatí pro potřeby výpočtů ve FLUENTu investovat do vysokorychlostního zařízení typu Myrinet. Gigabitový Ethernet spolu s komunikátorem Network MPI zajistí prakticky stejný výkon, při použití menšího počtu procesorů (do 10) je možno s úspěchem použít i sockety.

předchozí

obsah

následující