8   MetaCentrum

Aktivita MetaCentrum odpovídá za provoz a další rozvoj distribuovaného výpočetního a úložného prostředí v rámci České republiky a jeho propojení s podobnými zahraničními systémy. Grid, jak se takový systém zpravidla nazývá, představuje jednu ze základních infrastruktur globálně chápaného výzkumu a vývoje, umožňující intenzivní spolupráci i geograficky velmi rozptýlených výzkumných týmů.

Jedním ze základních problémů, které musí budování rozsáhlé sdílené výpočetní a úložné infrastruktury vyřešit, je řešení rozporu mezi specifickými, často protichůdnými požadavky uživatelů na vlastnosti takové infrastruktury a minimalizací provozních nákladů, spočívající zpravidla v unifikaci poskytovaného prostředí. Aktivita MetaCentrum přijala v roce 2006 strategii, která umožňuje skloubit tyto protichůdné požadavky pomocí důsledně aplikované virtualizace poskytovaného prostředí. Hlavní činností MetaCentra v roce 2007 byly proto první kroky tvorby virtualizované gridové infrastruktury. Realizované činnosti lze rozdělit do následujících oblastí:

Paralelně s těmito specifickými úkoly aktivita zajišťovala provoz stávající infrastruktury, včetně pokračující uživatelské podpory, rozvoje portálu a s ním souvisejících služeb. Rovněž pokračovaly činnosti v oblasti rozvoje bezpečnosti MetaCentra a monitorování stavu infrastruktury a poskytovaných služeb. Pokračovala rovněž spolupráce s dalšími aktivitami sdružení CESNET, zejména pak v oblasti bezpečnosti, podpory složitých prostředí pro spolupráci a optických sítí. Přechod na IPv6 pak znamenal výrazné posílení spolupráce s provozem sítě CESNET2.

Aktivita MetaCentrum rovněž odpovídá za zapojení do mezinárodních projektů EU (v roce 2007 to byly projekty EGEE II a nově zahájený EGI_DS) a přípravu nových projektů - v rámci EU to byly projekty EGEE III a EUAsiaGrid, které oba koncem roku 2007 postoupily do fáze "dohadování" (negotiations). Kromě toho je MetaCentrum společně s aktivitou Virtuální prostředí pro spolupráci součástí návrhu projektu pro NSF (USA) v oblasti kolaborativních prostředí pro výuku. Pokračovala i interakce s výzkumným záměrem Masarykovy univerzity, zejména v oblasti plánování v gridovém prostředí.

8.1   Virtualizace MetaCentra

Virtualizační vrstvu považujeme v mnoha ohledech za analogii IP vrstvy prostředí počítačových sítí. Uspokojení specifických a protichůdných požadavků uživatelů zpravidla vyžaduje použití zcela odlišného prostředí na úrovni celých operačních systémů, ne pouze nějaké mezivrstvy - middleware - a jejího rozhraní. Alternativním přístupem může být využití SOA, tj. Service Oriented Architecture, její důsledné zavedení je však (zatím?) spojeno s neúnosně vysokou režií a neefektivitou. Virtualizace prostředí, tj. odstínění fyzického hardware virtualizační vrstvou a v konečném důsledku nabídka celých virtuálních počítačů - tedy ne pouze konkrétního operačního prostředí, tvořeného operačním systémem, knihovnami, middleware a aplikacemi, ale celého byť virtuálního počítače - nabízí abstrakci, která umožňuje uspokojit prakticky jakékoliv uživatelské požadavky se zachování sdíleného charakteru spravované infrastruktury.

8.1.1   Základní infrastruktura

Správci infrastruktury jsou v tomto pojetí plně odpovědni za zajištění provozu fyzických počítačů a na nich instalovaného virtualizačního prostředí do úrovně hypervizorů (Virtual Machine Monitor). Správa infrastruktury může dále poskytovat předdefinované virtuální počítače s konkrétním operačním systémem, knihovnami atd., případně vyladěné pro určité aplikace (např. formou nastavení systémových parametrů, instalací specifických knihoven a nástrojů apod.). Je relativně snadné takto nabízet i vzájemně nekompatibilní prostředí, která by jinak byla dostupná pouze reinstalací celých fyzických počítačů (operace, která může vyžadovat manuální zásah a je tedy pro provoz rozsáhlé infrastruktury neúnosně nákladná). Virtualizace však nabízí mnohem více. Virtuální počítače je možné snadno zastavit odebráním procesoru, v tomto stavu checkpointovat a přenést na jiný fyzický počítač - virtualizované prostředí odstíní případně rozdíly ve fyzickém vybavení počítačů. Je dokonce možné přesunovat virtuální počítače přímo za běhu, což umožňuje dynamicky optimalizovat využití infrastruktury bez přímého vlivu na uživatelské výpočty. Checkpointované - hibernované - virtuální počítače je možné dlouhodobě držet, kopírovat a kopie spouštět podle potřeby. Bez zbytečné režie je takto možné zajistit plnou reprodukovatelnost prostředí - výpočet není ovlivněn předchozími operacemi a aplikacemi, začíná vždy ve stejném a dobře definovaném stavu operačního systému.

Enkapsulace poskytnutá virtuálními počítači však může jít i dále. Je možné nabídnout uživatelům přímo rozhraní holého virtuálního počítače, na kterém si uživatelé spustí vlastní instalaci operačního systému a aplikací. Případné bezpečnostní problémy lze odstínit použitím virtuální sítě, která není směrována do Internetu - v takto izolovaném prostředí je možné uvolnit většinu bezpečnostních požadavků. Výhodným vedlejším efektem je možnost udržovat neměnné výpočetní prostředí - bezpečnostní "záplaty", které je jinak nezbytné instalovat, mohou nečekanými způsobem ovlivnit chování aplikací a tak znehodnotit např. prováděnou rozsáhlou sérii výpočtů. Virtuální počítače odstíněné virtuální sítí mohou zůstat v nezměněné podobě, aniž by tím byla ohrožena bezpečnost celé infrastruktury.

Z virtuálních počítačů je možné budovat celé virtuální gridy, tedy skupiny virtuálních počítačů, spuštěných na fyzických strojích v různých uzlech infrastruktury. Propojení může být opět realizováno na úrovni virtuální sítě, která může, ale nemusí být směrována do Internetu. Uvnitř uzavřených virtuálních gridů je možné spouštět virtuální počítače s triviálními autentizačními mechanismy (třeba s prázdnými hesly), což usnadňuje práci uživatelů bez kompromisu celkové bezpečnosti poskytované infrastruktury.

K virtualizaci MetaCentra používáme primárně systém Xen. Jeho hlavní předností je paravirtualizace, tj. pouze částečná abstrakce fyzických prostředků. Například procesor není virtualizován, virtuální počítače v Xenu díky tomu mají prakticky stejný výpočetní výkon jako nativní počítač bez virtualizace (rozdíl se pro výpočetně náročné aplikace pohybuje zpravidla do 3 %). Na druhé straně Xen poskytuje úplný virtuální počítač, na němž lze spustit téměř jakoukoliv variantu Linuxu s novějšími verzemi jádra. Na konci roku 2007 bylo v prostředí Xen k dispozici na 272 jader téměř stovky výpočetních uzlů MetaCentra.

Při pokusu virtualizovat i víceprocesorové systémy (konkrétně osmiprocesorové počítače SunFire X4600 s NUMA architekturou) jsme začátkem roku narazili na problém výrazné neefektivity Xenu na této architektuře. Xen v používaných verzích nezajišťoval afinitu procesoru a paměťových míst, přitom v NUMA architektuře je nezbytné, aby i po přerušení výpočet pokračoval na tom procesoru, který má stejnou "vzdálenost" od paměti jako procesor, na němž došlo k přerušení výpočtu. Nedodržení této zásady vede ke ztrátě výkonu v řádu mnoha desítek procent. Proto jsme u těchto strojů využili jiné virtualizační prostředí, konkrétně VServer. V něm jednotlivé virtuální stroje sdílí stejné jádro, virtualizace (abstrakce) je poskytována až na úrovni "kopií" operačního systému. Výhodou tohoto přístupu je menší režie ve srovnání s prostředím Xen, na výše uvedených osmiprocesorových (16 jader) počítačích je možné spouštět až stovky virtuálních počítačů (výhodné např. při simulaci rozsáhlého výpočetního či peer to peer prostředí). Na konci roku 2007 byly takto rutinně provozovány dva počítače SunFire X4600, tj. celkem 32 jader (AMD). Přes určité výhody VServeru plánujeme postupný přechod těchto počítačů na Xen, jakmile bude dostupná kvalitní podpora NUMA architektury.

Od druhé poloviny roku již byl na všechny nově pořízené počítače automaticky instalován Xen (počítače se dvěma procesory) nebo VServer (počítače s NUMA architekturou). Celkově je virtualizováno cca 40 % jader, která ale představují přes 60 % celkového instalovaného výkonu.

8.1.2   Plánování

Virtualizace infrastruktury nebyla samoúčelné cvičení, její hlavní přínos spočívá ve vytvoření podmínek pro poskytování pokročilých služeb, zejména prioritizace úloh. Kromě virtualizace je nezbytnou podmínkou i podpora virtuálního prostředí v plánovači, jehož prostřednictvím uživatelé spouští své úlohy. Navrhli jsme a v roce 2007 intenzivně rozvíjeli systém Magrathea pro podporu plánování ve virtualizované infrastruktuře. V první fázi jsme se soustředili na exkluzivní sdílení fyzických strojů, kdy pracujeme s následujícím modelem:

Jedná se tedy o typický příklad sdílení infrastruktury různými operačními prostředími v čase s prakticky nulovou režií přechodu mezi nimi.

Systém Magrathea představuje rozšíření plánovače, v němž je soustředěna "znalost" o virtuálním prostředí. Magrathea je nezávislá na konkrétním plánovači (v prostředí MetaCentra spolupracuje s PBSPro) a skrývá před ním virtualizované prostředí. Jakmile plánovač naplánuje úlohu v jednom z virtuálních počítačů, Magrathea zajistí, že na ostatní virtuální počítače stejného uzlu nebudou po dobu běhu aplikace posílány jiné úlohy.

Tento jednoduchý scénář sdílení infrastruktury umožňuje prioritizaci úloh. V případě, že na uzlu již běží výpočet a přijde požadavek s vyšší prioritou, Magrathea může virtuálnímu počítači odebrat většinu zdrojů (CPU, paměť) a uvolnit tak výpočetní kapacitu uzlu pro prioritní úlohu, která bude spuštěna v jiném virtuálním stroji. Odebrání CPU je přitom na úrovni VMM v podstatě triviální operací. Dochází tak k preempci původní úlohy, která přitom není úplně pozastavena, což výrazně snižuje riziko zhroucení úlohy (což je bohužel relativně častý případ, pokud se snažíme pouze pozastavit aplikaci pomocí signálu suspend) a přitom garantuje, že neexistuje nějaký "zapomenutý" proces, který by nové prioritní úloze odebíral část zdrojů. Podrobnosti o systému Magrathea je možné najít v publikacích MetaCentra.

Od situace s jedním plně aktivním a druhým preemptnutým virtuálním počítačem je již relativně krátká cesta k uzlům, na nichž běží více virtuálních počítačů s aktivními aplikacemi současně. V takovém případě Magrathea musí zajistit, že celkový počet spuštěných aplikací není vyšší než počet jader (resp. není vyšší než by spustil plánovač na původním fyzickém uzlu). Ve virtuálním prostředí lze přitom nabízet jedno, dvou i vícejaderné virtuální počítače, Magrathea musí proto korektně ošetřit i takové případy.

Magrathea experimentálně podporuje i situaci, kdy uživatel využívá gridové prostředí pro nabídku služeb. V takovém případě aplikace většinu času pouze čeká na požadavky, po jejich příchodu však musí být schopna na ně rychle reagovat (není tedy možné teprve s příchodem požadavku plánovat a spouštět úlohu). Magrathea podporuje i tzv. frozen stav, kdy virtuální počítač s aplikací "spí" (má odstraněn procesor, ale je trvale přítomen) a umí jej velmi rychle "probudit" pro příchodu konkrétního požadavku.

V některých případech však nestačí jen odebrání většiny zdrojů a je třeba původní aplikaci (resp. přesněji virtuální počítač, v němž běží) z uzlu odstranit. Mluvíme v takovém případě o migraci virtuálních strojů. Migraci můžeme provést systémem "store and forward", tj. běžící virtuální počítač hibernujeme, obraz pak překopírujeme na jiný fyzický uzel a tam jej spustíme. Pokročilou alternativou je pak migrace "za živa", kdy se na druhém fyzickém stroji vytvoří kopie za běhu a v příhodném momentě se pouze předá řízení. Podpora migrace vyžaduje v obou případech spolupráci plánovače, pouze migrace bez přerušení výpočtu umožňuje takto přenášet i distribuované výpočty. Podpora migrací jak systémem Magrathea, tak vlastní infrastrukturou bude předmětem výzkumu v roce 2008.

8.1.3   Interaktivní Grid

Jedním z významných nedostatků současných gridových infrastruktur je nabídka pouze dávkového charakteru práce, kdy uživatelé nemají bezprostřední interaktivní styk s výpočetními uzly. Přestože MetaCentrum neomezuje přímý přístup na jednotlivé výpočetní uzly (uživatelé se mohou kdykoliv pomocí ssh přihlásit) a je také možné přes dávkový režim pořádat o naplánování uzlů, na nichž bude následně uživatel pracovat interaktivně, neexistuje podpora "okamžité" interaktivity, tj. možnost uspokojit požadavek na interaktivní uzly v reálném čase. Zavedením preempce a základními kroky k podpoře migrace jsme však v roce 2007 postavili stavební kameny prostředí, v němž bude možné uspokojit uživatelský požadavek na interaktivní práci v reálném čase - preempcí, případně migrací běžících aplikací (včetně možností agregace preemptovatelných úloh).

Podpora bezprostřední interaktivní práce s virtuálními počítači (a následně celými virtuálními gridy) vyžaduje i možnost lépe řídit stav virtuálních počítačů, zejména pak možnost znovuspuštění (reboot, opětné spuštění klonu původního virtuálního počítače apod.). V roce 2007 jsme vyvinuli nástroje pro ovládání virtuálních počítačů "zvenku", přes VMM. Tyto nástroje jsou v podobě příkazového řádku (CLI, Command Line Interface) odstupné administrátorům MetaCentra. Základní funkce byly rovněž integrovány do MetaPortálu a budou v roce 2008 zpřístupněny koncovým uživatelům (zejména možnost uživatelem iniciovaného rebootu přiděleného virtuálního stroje bez interakce s administrátory).

8.1.4   Infiniband

Koncem roku 2006 jsme pořídili karty a přepínače Infiniband pro podporu vysokorychlostní nízkolatenční komunikace uvnitř clusteru. Protože Infiniband chceme používat ve virtualizovaném prostředí, soustředili jsme se v roce 2007 na řešení problémů, spojených s využitím takovýchto vysokorychlostních rozhraní ve virtuálních počítačích Xen (v prostředí VServer není tento problém kritický, protože tam jediný běžící operační systém přímo ovládá i fyzické rozhraní). Xen standardně síťová rozhraní virtualizuje, což ovšem přináší viditelnou ztrátu výkonu a zvýšení zpoždění, nežádoucí vlastnosti zejména v případě vysokorychlostních spojení. Alternativní nabízenou možností je pak export fyzického zařízení přímo do virtuálního počítače (toto zařízení pak není sdíleno, ale konkrétní virtuální počítač může využít rozhraní přímo, bez dodatečné režie virtualizace).

Karty Infiniband jsou v Xenu podporovány několika vývojovými projekty, z nichž však žádný zatím nedosáhl potřebné kvality a stability. Rozhodli jsme se proto využít možnosti exportu karty, i v tomto případě ale bylo nutné z implementace odstranit chyby, související především s nekorektním ošetřením inicializace karty a rovněž jejího opětného uvolnění. Provedli jsme řadu měření výkonu, a to jak benchmarkem b_eff, tak i jednoduchým měřením s MPI (openmpi-1.1.1.-1) přímo nad Infinibandem (bez IP vrstvy). Nejvyšší dosažená přenosová rychlost s MPI ve virtuálním počítači byla 960 MB/s (téměř 7,7 Gb/s) pro 2MB pakety. Naopak nejnižší zpoždění (pro prázdné pakety) bylo 3,31 μs, 4MB pakety pak mají zpoždění 4,56 ms. Měření byla prováděna v režimu point to point na kartách DDR, tedy s teoretickou přenosovou rychlostí až 20 Gb/s. Jen pro srovnání, na 1GE kartách se podařilo dosáhnout nejmenšího zpoždění kolem 60 μs. Další výsledky budou k dispozici v připravované technické zprávě.

Stroje s Infinibandem jsou tak k dispozici uživatelům i ve virtualizovaném prostředí. Jejich plnohodnotné využití však rovněž vyžaduje speciální podporu systémem Magrathea, neboť není možné Infiniband sdílet více virtuálními stroji současně. Export karty je funkční, ale v současné implementaci je karta přidělena virtuálnímu stroji trvale, k jejímu uvolnění dojde až s ukončením virtuálního stroje (shutdown). Všestranná plnohodnotná podpora Infiniband karet ve virtualizovaném prostředí bude proto předmětem dalšího studia i v roce 2008.

8.2   PBSPro

Plánování úloh v MetaCentru zajišťuje systém PBSPro. Jeho stabilita významným způsobem ovlivňuje stabilitu celého nabízeného výpočetního prostředí. V roce 2007 jsme se proto věnovali jak opravě chyb, tak zajištění nových vlastností PBSPro, aby nepůsobil jako nejslabší článek celé infrastruktury. Konkrétně jsme v průběhu roku přidali následující nové vlastnosti:

Nasazení systému Magrathea přímo v provozu MetaCentra přispělo koncem roku i k podstatnému zvýšení stability celého plánovacího prostředí. Konkrétně se podařilo nalézt chyby v detekci krátkodobého rozpadu sítě, kdy PBSPro nedokázalo korektně ošetřit stav po znovunavázání spojení (docházelo k předčasnému zhrouceni lokálního démona pbs_mom s důsledkem úplné ztráty informace o běžící úloze - PBSPro pak takový uzel vyhodnotila jako neobsazený a pokusila se na něm spustit další úlohu). V opravené verzi je krátkodobě "ztracený" uzel korektně rozpoznán a PBSPro neztratí informaci o běžících úlohách.

8.3   Síťová infrastruktura

Přechod na virtualizované výpočetní prostředí si vyžádal také významné změny v síťové infrastruktuře. Jednou z výhod virtuálních strojů je možnost jejich individualizace dle požadavků uživatelů. Jedním z těchto požadavků je také možnost používat permanentní síťové adresy, neboť to výrazně zjednodušuje např. konfiguraci paralelních výpočtů. Virtuální počítače uživatelů, kteří budou spouštět vlastní operační systémy, musí být z bezpečnostních důvodů odděleny od Internetu. Podpora mobility se podstatně usnadní, pokud oba fyzické stroje, mezi nimiž se virtuální přesouvá, jsou ve stejném síťovém segmentu.

Tyto argumenty, společně s faktem, že virtuálních počítačů bude perspektivně mnohem více než fyzických uzlů, vedly k návrhu nové síťové infrastruktury MetaCentra, postavené na protokolu IPv6. Jeho nasazením jsme získali prakticky neomezený adresový prostor, přitom IPv6 vrací zpět do sítě plnohodnotný end to end přístup (žádné NAT, které zejména v gridovém prostředí působí jen velmi těžce překonatelné problémy). Dalším rysem navržené infrastruktury je "plochá" struktura - všechny výpočetní a servisní uzly MetaCentra jsou na jedné L2 síti, která v současnosti propojuje uzly v Plzni, Praze i Brně. Správa provozu sítě na naši žádost současně vybavila toto prostředí technologiemi, které nám v další etapě umožní experimentovat s uživatelem řízenými virtuálními podsítěmi (VLAN), principem označovaným jako QinQ. Těchto virtuálních LAN chceme využít pro konstrukci virtuálních gridů, jejichž ustavení a eventuální směrování do Internetu bude plně pod kontrolou MetaCentra, bez nutnosti bezprostřední interakce se správou páteřní sítě. To nám umožní budovat virtuální gridy na žádost, v okamžiku plánování úloh.

8.3.1   Jmenný prostor

MetaCentru byl přidělen prefix 2001:718:ff01::/48, pro alokaci konkrétních adres jsme vytvořili adresní plán, v jehož rámci jsme vyčlenili prefix /56 pro fyzické stroje. Z čistě administrativních důvodů je tento prefix dále členěn na prefixy /64, předělené jednotlivým uzlům. Jména všem strojům v IPv6 síti přidělujeme z jmenného prostoru meta6.cesnet.cz. Oddělený jmenný prostor pro IPv6 jsme zvolili jednak z důvodů unifikace a snazší správy, jednak pro optimalizaci přístupu. Přidělování jmen je nyní plně v rukou správců MetaCentra (v jmenném prostoru IPv4 je nezbytná koordinace s lokálními správci), je jasná příslušnost strojů k MetaCentru a současně je zajištěno, že uživatelé či služby se nebudou přes IPv6 obracet na počítače, které ještě IPv6 adresu nemají.

8.3.2   Služby

Vlastní IPv6 infrastruktura postrádá smysl bez aplikací, které ji umí přímo využívat. Přechod od IPv4 na IPv6 však znamená nejen větší rozsah adres, ale i zavedení celé řady dodatečných informací. Narůstá počet adres na každém rozhraní, což znamená nutnost výběru té správné, IPv6 adresy je třeba rozeznat v konfiguračních souborech atd. Teoreticky by vše (nebo alespoň podstatná část) mělo být skryto korektním používáním knihoven, praxe je však zejména u starších (tradičních) aplikací, především těch psaných v jazyce C, odlišná - programátoři často s adresami manipulují přímo, s implicitním předpokladem, že mají právě 32 bitů.

Zaměřili jsme se proto také na analýzu připravenosti základního programového vybavení MetaCentra na IPv6. Přestože řada velkých Internetových serverů již delší dobu používá IPv6, v MetaCentru používaný middleware zatím v prostředí IPv6 zpravidla ještě nebyl nasazen (dotazem na připravenost na IPv6 jsme např. zcela zaskočili autory plánovacího systému PBSPro, kteří přiznali, že jsme celosvětově první, kteří se o něco takového zajímají). V některých případech jsme rovněž zjistili, že konkrétní program je sice schopen komunikovat přes IPv6, avšak není zcela dotaženo rozpoznávání IPv6 adres (a jejich variant) při analýze konfiguračních souborů či příkazové řádky (např. není korektně zpracována adresa v hranatých závorkách či využívající procentní syntaxi). V takových případech zpravidla stačí důsledně používat DNS jména, tato skutečnost však nebývá nikde popsána.

Mezi hodnocené služby a aplikace, které jsou připraveny na použití v IPv6, patří:

Naopak mezi podstatné komponenty infrastruktury MetaCentra, které IPv6 nepodporují, patří:

Testovali jsme také DHCP pro IPv6 (DHCPv6). Zjistili jsme, že žádné open source řešení poskytuje plně uspokojivé služby. V současné době proto jako server používáme wide-dhcpv6 s vlastními modifikacemi a opravami. Jako klienty doporučujeme Dibbler (který jako jediný podporuje "MAC address only" DUID).

V roce 2007 se nám tak podařilo vytvořit vlastní IPv6 infrastrukturu MetaCentra včetně všech nezbytných administrativních a organizačních kroků. Máme vytvořen adresní plán a rozběhli jsme první sadu služeb nad IPv6. Současně jsme identifikovali problematická místa, na jejichž odstranění se soustředíme v dalším roce. Jsme zatím největší gridové prostředí (a jediná národní infrastruktura mimo Čínu), které přechází na IPv6. Máme proto výbornou šanci získat cenné zkušenosti, o které bude celosvětově široký zájem.

8.3.3   10 Gb/s infrastruktura

Kromě IPv6 jsme se v roce 2007 věnovali dalšímu rozvoji 10 Gb/s sítě. Dokončili jsme proces zahájený v předchozím roce dobudováním uzlů 10 Gb/s sítě v Plzni, Praze a Brně. Konkrétně jsme pořídili dva 10GE přepínače Force10, každý s kapacitou až 24 10GE portů (přepínače byly aktuálně pořízeny s více jak polovinou portů osazených). Na jeden z těchto 1U přepínačů jsou připojeny prvky 10 Gb/s infrastruktury v Praze - agregující přepínač s jedním 10 GE portem a 16 porty 1GE, napojení na CzechLight, provozní 10GE port sítě CESNET2, privátní 10 Gb/s DWDM linka do Brna a Plzně a další. Druhý je instalován s podobným účelem v Brně - zde jsou na něj napojeny 10GE přepínače (např. 8portový nebo hlavní přepínač uzlu MetaCentra v Brně, zajišťující agregaci 1GE portů do 10GE infrastruktury), experimentální Cisco 6506 a rovněž připojení 10 Gb/s sítě CESNET2 (provozní síť i privátní spoje DWDM) a CzechLight.

8.4   Bezpečnost

V roce 2007 jsme pokračovali v podpoře federativních mechanismů pro autentizaci a řízení přístupu. Zřídili jsme poskytovatele identit (Identity Provider) pro uživatele MetaCentra a také řadu federalizovaných poskytovatelů služeb (Service Providers), které slouží primárně jako demonstrace funkčnosti federací. Všechny tyto aplikace jsou součástí vznikající české akademické federace (CzTestFed). Podpora federačního modelu byla rovněž integrována do portálu MetaCentra, kde je používána především na správu uživatelských účtů, včetně možnosti nezávislé obnovy hesla. Věnujeme se i samostatnému výzkumu v oblasti federací. Ve spolupráci s aktivitou Multimediální přenosy a kolaborativní prostředí jsme navrhli bezpečnostní infrastrukturu prostředí pro spolupráci, která je založena na využití federačního modelu. Společně s MU budeme spolupracovat na projektu FR CESNET "Common Access Toolkit for Federations", jehož výsledky budou přejaty do prostředí MetaCentra.

Věnovali jsme se možnostem, jak rozšířit portfolio autentizačních mechanismů v distribuovaném prostředí, zejména s ohledem na jejich vzájemnou kombinovatelnost. V rámci diplomových prací se studenti FI MU věnovali použití jednorázových hesel a přístupu do gridového prostředí. Během řešení první práce jsme dokončili přehled a ověřovací instalace tzv. soft-tokenů, tj. Java aplikací pro mobilní zařízení (telefon, PDA), pro správu jednorázových hesel. Tato zařízení byla použita pro autentizaci k experimentálnímu MyProxy serveru, který udržuje proxy certifikáty pro přístup do gridového prostředí. Výsledkem druhé práce je prostředí pro správu proxy certifikátů v prostředí MS Windows, které poskytuje přehledné GUI a integruje podporu proxy certifikátů do aplikací putty a winscp.

Od roku 2006 jsme plně zapojeni v projektu eduroam, do kterého poskytujeme Radius server pro uživatele MetaCentra. V roce 2007 jsme provedli instalaci záložního Radius serveru, který běží ve virtuálním stroji na HighAvailability serveru MetaCentra. Během roku 2007 jsme se zúčastnili testování evropské eduroam infrastruktury, které bylo zaměřeno na možnosti použití TLS mechanismů (tj. certifikátů) pro autentizaci uživatelů. V rámci testování jsme poskytovali certifikační autoritu a distribuci testovacích certifikátů administrátorům.

Věnovali jsme se také oblasti bezpečnostního monitoringu, kdy jsme se zaměřili na detekci průniků a kontrolu integrity souborů. V pilotním provozu jsou systémy checkrootkit a AIDE (kontrola integrity souborů). Společně s kolegy z EGEE se podílíme na vývoji software Pakiti pro monitorování instalovaného software a jeho aktualizací. Pozornost jsme věnovali i vzdálenému logování pomocí syslog-ng, který však neprokázal dostatečnou robustnost pro nasazení v produkčním distribuovaném prostředí. Uvažujeme proto o nahrazení transportní vrstvy syslog-ng nějakým spolehlivějším protokolem, např. z oblasti monitoringu úloh, které se věnujeme v projektu EGEE. Připravili jsme také dokument klasifikující bezpečnostní incidenty, který má mimo jiné sloužit administrátorům jako vodítko při jejich řešení.

V oblasti virtualizovaného prostředí jsme se zaměřili na problematiku důvěryhodného využití virtuálních strojů, které mohou migrovat po infrastruktuře. Pro tyto účely jsme navrhli možné řešení založené na technikách Trusted Computing a využití TPM čipů.

Během roku pokračovala naše činnost Registrační autority CESNET CA, proběhla také akreditace druhého člena MetaCentra jako registračního úředníka. V oblasti PKI jsme se zabývali mechanismy pro spolehlivou distribuci revokačních dat, která vyústila v návrh a implementaci distribuční služby nad monitorovací infrastrukturou gLite L&B, za jejíž vývoj odpovídáme v rámci projektu EGEE II.

8.5   Úložné prostředí

Úložné kapacity a nabízené související služby hrají v gridových infrastrukturách stále větší roli. Současně se jasně ukazuje, a to nejen v rámci MetaCentra, že uživatelé mají zájem o co nejjednodušší řešení, nejlépe formou globálně dostupného systému souborů. Explicitní hierarchické úložné systémy, které rozlišují lokální a vzdálené systémy souborů, storage elementy, úložné kapacity na páskách, archivaci atd. jsou zpravidla využívány velmi neefektivně - uživatelé si zvyknou používat jeden nebo nejvýše dva z těchto systémů a zbytek, přes přednosti pro konkrétní aplikace, ignorují.

V roce 2007 jsme se proto zaměřili na analýzu aktuálního stavu v oblasti úložných prostředí s cílem do konce roku rozhodnout o strategii MetaCentra na další období. Po sérii experimentů, z nichž některé jsou zmíněny níže, jsme se rozhodli pro následující řešení:

Z pohledu uživatelů dojde ke sjednocení úložných prostorů, které mají v současné době rozptýleny mezi lokální domácí adresáře, NFS připojované adresáře lokálních clusterů a AFS. Případný přechod na paralelizovaný scratch prostor by měli uživatelé zaznamenat pouze v podobě zvýšení rychlosti přístupu. Ostatní služby (AFS, zálohování, archivace) budou zachovány, případně rozšířeny.

8.5.1   PVFS2

V souvislosti s podporou přednášky "Introduction to High Performance Computing", která byla v jarním semestru 2007 realizována pomocí nekomprimovaných HD videopřenosů mezi LSU (Louisiana, USA) a FI MU v Brně jsme testovali kvalitu a spolehlivost systému PVFS2, se kterým počítáme pro paralelní scratch prostory. Testy probíhaly na clusteru 8 uzlů, každý se dvěma SAS lokálními disky. Uzly byly propojeny 1GE sítí. Podařilo se nám dosáhnout agregované propustnosti až 400 MB/s pro čtení i zápis. Ještě vyšších výkonů jsme dosáhli při použití MPI-IO přímo na gigabitovým Ethernetem (obchází se standardní UNIX I/O rozhraní). Dosažení takto vysoké propustnosti je však podmíněno použitím velkých bloků při čtení i zápisu souborů, což přirozeně často znamená modifikaci aplikace, která by tento systém používala. Pro ukládání a práci s malými soubory je výkon PVFS2 výrazně nižší.

Dalším problémem PVFS2 je nulová redundance, kdy při výpadku i jediného disku jsou ztracena data v celém systému souborů. Vzhledem k relativně nízké poruchovosti disků považujeme toto riziko za akceptovatelné pro soubory ve scratchi, kde není trvalá dostupnost dat garantována.

Pro srovnání výkonu jsme použili diskové pole se SATA disky, kde se nám v konfiguraci RAID 0 podařilo dosáhnout srovnatelného výkonu, ovšem se stejným rizikem při výpadku disku. V redundantní konfiguraci RAID 5 jsme srovnatelného výkonu dosáhli pouze pro čtení, zápis byl v tomto případě vždy výrazně pomalejší.

8.5.2   Investiční aktivity

Na základě poměrně rozsáhlé analýzy potřeb uživatelů a dostupných technických možností jejich uspokojení jsme také rozhodli o pořízení nových úložných kapacit. Konkrétně jsme zakoupili dvě jednoduchá disková pole s neformátovanou kapacitou 16 TB každé. Tato pole jsou nasazena v RAID5 konfiguraci jako lokální NFSv3 server a rovněž Storage Element pro podporu projektu EGEE II. Jedno z polí je umístěno v sídle sdružení, druhé pak v bezprostřední blízkosti farmy Goliáš na Fyzikálním ústavu AV ČR v Praze.

Po rozhodnutí o architektuře úložných kapacit MetaCentra jsme se rozhodli pořídit velkokapacitní pole střední úrovně. Z dvoukolového výběrového řízení vyšla jako vítězná firma SGI s nabídkou pole IS4500F a rozsáhlým doprovodným programovým vybavením. Zakoupené pole je osazeno SATA disky s aktuální kapacitou 61,5 TB, s možností rozšíření na více jak dvojnásobek kapacity. Předpokládaná propustnost pole je cca 1 GB/s. Pole je rovněž možné osadit FC (Fibre Channel) disky s menší kapacitou, ale výrazně vyšším výkonem. Obslužné programové vybavení pole je schopno obsloužit i kombinaci SATA a FC disků - toho plánujeme využít pro transparentní hierarchický systém (s kapacitou nabízenou SATA disky a výkonem blížícím se použití FC disků). Pole je umístěno na ÚVT MU v Brně a bude sloužit primárně jako NFSv4 server pro celé MetaCentrum. Pole je zakoupeno s plnou podporou, jejíž součástí je i zprovoznění pole do 24 hodin po výpadku. Po vyhodnocení provozu plánujeme v roce 2008 rozšíření kapacit a rovněž funkcí dokoupením dalšího programového vybavení - již v zakoupené konfiguraci však pole podporuje např. hardwarové snapshoty pro snadné zálohování konzistentního stavu pole bez degradace výkonu.

8.6   Rozšíření výpočetní kapacity

Na základě zájmu patrného z prezentací na mezinárodních konferencích a workshopech jsme se v roce 2007 věnovali analýze nasazení nových architektur a zejména specializovaných koprocesorů v prostředí MetaCentra. S ohledem na cenu, dostupnost, šíři současného i očekávaného nasazení a složitost programování jsme se rozhodli soustředit se pouze na možnosti využití GPU (grafické procesory) pro tento účel. FPGA akcelerátory zatím nenabízí podporu operací v pohyblivé čárce s 64 a více bity (což je dnes standard vědeckých výpočtů). Stejným nedostatkem prozatím trpí i IBM Cell architektura (tam je ohlášena dostupnost 64bitové architektury ve druhé polovině roku 2008). GPU naopak mají standardní podporu výpočtů v pohyblivé čárce - byť se nejedná o korektní IEEE 754 aritmetiku - jsou široce rozšířené (což pozitivně ovlivňuje jejich cenu) a zejména firma nVidia začala překovávat doposud největší nedostatek GPU jako koprocesorů, spočívající v malé propustnosti při komunikaci z karty zpět do hlavní paměti počítače.

Nová generace karet rodiny 8xxx, které jsme pořizovali společně s aktivitou Multimediální přenosy a kolaborativní prostředí pro zpracování HD videa, již nabízí velmi zajímavé výpočetní výkony, použitelné i v prostředí MetaCentra. Na rok 2008 pak firma nVidia ohlásila karty s architekturou TESLA (Cuda), které by již měly být plnohodnotnými koprocesory pro nejnáročnější výpočty. Možnosti programování GPU rodiny 8xxx jsme ověřili ve spolupráci s aktivitou Multimediální přenosy a kolaborativní prostředí na implementaci kompresních algoritmů (viz příslušná část zprávy). GPU zatím nenabízíme jako standardní koprocesory, vytvořili jsme ale ze zakoupených strojů experimentální prostředí, na němž chceme v roce 2008 pokračovat již s případnou implementací výpočetně náročných jader (kernels) aplikací, běžně využívaných v MetaCentru.

8.6.1   Investiční aktivity

Zvyšující se poruchovost nás vedla k rozhodnutí o náhradě nejstaršího clusteru (s procesory Pentium III na 700 MHz) systémem postaveným na quad-core procesorech. 64 původních jednoprocesorových uzlů (2 plné racky) jsme nahradili 10 dvouprocesorovými uzly s quad-core Intel procesory na 3 GHz. Z výběrového řízení vyšla vítězně nabídka firmy SGI, která těchto 80 jader dokázala umístit do prostoru pouhých 5U s energetickou náročností pouze 5 kW. Uzly jsou primárně poskytnuty jako výpočetní kapacity EGEE, díky virtualizaci však budou přímo využitelné i pro uživatele MetaCentra. Současně chceme na těchto uzlech experimentálně ověřit možnosti využití dual quad-core CPU serverů ve virtualizovaném prostředí, kde jedno až dvě jádra budou vyhrazena pro režii operačního systému a virtualizace (zejména virtualizovaných síťových rozhraní). 8jaderné servery zpravidla degradují výkon při použití všech osmi jader pro aplikace, vyhrazení jednoho až dvou jader pouze pro režijní účely může proto vést zdánlivě paradoxně k celkovému vyššímu poskytovanému výkonu.

Zakoupili jsme rovněž další server Sun x4600 s osmi AMD dual-core procesory, neboť tyto servery si v průběhu roku získaly vysokou oblibu uživatelů (16 výkonných jader se 64 GB sdílené paměti je téměř ideálním prostředním pro běh paralelních úloh). I na tomto počítači běží virtualizované prostředí.

8.6.2   Integrace externích clusterů

Pokračovali jsme v zapojení clusterů výzkumných skupin do infrastruktury MetaCentra. Zástupce MetaCentra se zúčastnil výběrových řízení v Loschmidtových laboratořích na MU, vybrané IBM Blade řešení je plně integrováno do infrastruktury MetaCentra. Obdobně jsme se podíleli na výběrovém řízení nákupů clusterů pro Národní centrum výzkumu biomolekul (MU) a Biofyzikálního ústavu AV ČR; pořízené systémy jsou rovněž plně integrovány. Ve všech případech integrace znamená nasazení virtualizační technologie Xen.

Spolupracujeme rovněž s pracovištěm JČU a AV ČR v Nových Hradech na výběru clusteru, který bude po pořízení také integrován do infrastruktury MetaCentra.

předchozí
obsah 		následující
fond rozvojemetacentrumliberouterpřenosyvideoservereduroamdalší servery