HPC a grid computing

Kdy₧ se dnes °ekne HPC, mßme na mysli High Performance Computing, co₧ se do ΦeÜtiny p°eklßdß jako vysokov²konnΘ poΦφtßnφ.

Na systΘmy slou₧φcφ pro HPC se m∙₧eme dφvat n∞kolika ·hly pohledu. ╚lov∞ku je asi nejbli₧Üφ pohled z fyzickΘ roviny. Kde je co umφst∞nΘ, co je s Φφm spojenΘ atd. NemΘn∞ d∙le₧it² je i pohled logick² û jak je co ud∞lanΘ, aby to fungovalo. Zkusφm proto dneÜnφ HPC systΘmy popsat a klasifikovat nejd°φve z logickΘho pohledu, zastavφm se i u fyzickΘho nßhledu a samostatn∞ se rozepφÜu na tΘma klastr∙ û grid∙.

K dneÜnφmu dni se za₧ilo Φlen∞nφ HPC systΘm∙ na Φty°i kategorie. Toto Φlen∞nφ je zalo₧eno na zp∙sobu zpracovßnφ instrukcφ a datov²ch tok∙.

Jedna instrukΦnφ sada, jedna datovß sada û SISD, Single Instruction Single Data
Jde p°evß₧n∞ o konvenΦnφ systΘmy s jednφm procesorem opat°en²m jednou instrukΦnφ sadou vykonßvanou sΘriov∞ na jednΘ mno₧in∞ dat. NicmΘn∞ n∞kterΘ dneÜnφ mainframy obsahujφ vφce ne₧ jeden procesor, v₧dy ale ka₧d² vykonßvß nezßvisl² instrukΦnφ tok.

Jedna instrukΦnφ sada, vφce datov²ch sad û SIMD, Single Instruction Multiple Data
SystΘmy SIMD se vyznaΦujφ schopnostφ vykonßvat jeden instrukΦnφ tok nad vφcero datov²mi toky. Pro °adu ·loh, hlavn∞ typu paralelnφho datovΘho toku, je tato architektura schopna poskytnout vysok² v²kon. Stroje SIMD mφvajφ jednu instrukΦnφ jednotku ICU (Instruction Processing Unit) obΦas naz²vanou jako kontrolΘr procesor a vφce datov²ch jednotek DPU (Data Processing Units), n∞kdy tΘ₧ naz²vanΘ procesnφmi elementy (PE).

Samostatnou podmno₧inu pak tvo°φ tzv. vektorovΘ poΦφtaΦe. Ty pracujφ spφÜe ne₧ s jednotliv²mi daty s podobn²mi daty uspo°ßdan²mi v polφch. Pou₧φvajφ specißlnφ struktury CPU, kterß jim dovoluje pracovat s daty tΘm∞° paraleln∞. Pokud tyto stroje pracujφ ve vektorovΘm modu, poskytujφ mnohonßsobn∞ vyÜÜφ v²kon, ne₧ kdy₧ pracujφ v konvenΦnφm skalßrnφm m≤du.

Vφce instrukΦnφch sad, jedna datovß sada û MISD, Multiple Instruction Single Data
Teoreticky tyto systΘmy um∞jφ provßd∞t nad jednφm datov²m tokem vφce tok∙ instrukΦnφch sad. Prakticky se ale takovΘ systΘmy nekonstruujφ.

Vφce instrukΦnφch sad, vφce datov²ch sad û MIMD, Multiple Instruction Multiple Data
Tyto systΘmy vykonßvajφ n∞kolik instrukΦnφch tok∙ paraleln∞ nad r∙zn²mi daty. Na rozdφl od vφceprocesorov²ch systΘm∙ SISD jsou instrukce a data zßvisle spojenΘ. Procesor zpracovßvß r∙znΘ Φßsti stejnΘ ·lohy. SystΘmy MIMD mohou pracovat s mnoha pod·lohami paraleln∞, aby zkrßtily Φas pot°ebn² k vy°eÜenφ hlavnφ ·lohy. V∞tÜina vφceprocesorov²ch poΦφtaΦ∙ pat°φ prßv∞ do tΘto kategorie a podle architektury je jeÜt∞ dßle d∞lφme (viz obrßzek).

UMA û Uniform Memory Access

Paralelnφ poΦφtaΦe mφvajφ pam∞¥ bu∩ centrßlnφ nebo distribuovanou. SystΘmy s centrßlnφ pam∞tφ jsou znßmΘ takΘ jako UMA architektury. U t∞chto systΘm∙ platφ, ₧e vÜechny pam∞ti jsou zhruba stejn∞ vzdßlenΘ od vÜech procesor∙ a stejn∞ tak i p°φstupovΘ Φasy ke vÜem jednotkßm pam∞ti jsou zhruba stejnΘ. Hlavnφm znakem pak je, ₧e centrßlnφ pam∞¥ je sdφlenß. Existujφ dva druhy UMA architektury û systΘmy s paralelnφmi vektorov²mi procesory a symetrickΘ multiprocesorovΘ systΘmy.

PVP û Parallel Vector Processors
Architektura typickΘho PVP systΘmu je zobrazena na nßsledujφcφm obrßzku:

P°φkladem takovΘ architektury pak m∙₧e b²t poΦφtaΦ Cray C-90, Cray T-90 nebo NEC SX-4. TakovΘ systΘmy mφvajφ menÜφ poΦet specializovan²ch vektorov²ch procesor∙ (VP). Procesory jsou spojenΘ se sdφlenou pam∞tφ (SM û Shared Memory) switchovanou sφtφ s velkou propustnostφ. Tyto stroje normßln∞ nepou₧φvajφ cache pam∞ti, rad∞ji pou₧φvajφ instrukΦnφ buffer a velk² poΦet vektorov²ch registr∙.

SMP û Symmetric Multiprocessors
Tato architektura poskytuje globßlnφ fyzick² adresnφ prostor se symetrick²m p°φstupem. Ka₧d² procesor (P/C) m∙₧e p°istupovat ke vÜem Φßstem sdφlenΘ pam∞ti (SM). Tento koncept se ujal nejenom u velk²ch drah²ch superpoΦφtaΦ∙, ale i u dneÜnφch pracovnφch stanic. Stßle vφce desktopov²ch systΘm∙ se objevuje s kapacitou Φty° procesor∙ a dneÜnφ servery b∞₧n∞ obsahujφ osm, Üestnßct a vφce procesor∙. Krßsa tohoto modelu je v tom, ₧e vÜechny procesory sdφlejφ stejn² adresnφ prostor a vytvß°ejφ pro u₧ivatele (programßtora) jednotn² systΘm bez jakΘkoli granularity.

U SMP architektury se b∞₧n∞ pou₧φvajφ dv∞ metody pro spojenφ mezi procesorem a pam∞tφ. Prvnφ je zalo₧enß na technologii sb∞rnice (bus) a druhß na technologii switchovanΘho crossbaru (k°φ₧ovΘho p°epinaΦe). Sb∞rnicov² systΘm vypadß podobn∞ jako standardnφ obrßzky poΦφtaΦovΘ architektury s mno₧stvφm komponent spojen²ch jednou sdφlenou datovou cestou.

Crossbarovß architektura odstra≥uje potencionßlnφ ·zkΘ hrdlo jednΘ sb∞rnice tφm, ₧e ji nahrazuje spojenφm typu ka₧d² s ka₧d²m, pop°φpad∞ switchem. To zaruΦφ, ₧e opravdu ka₧d² procesor m∙₧e mφt v reßlnΘm Φase svou datovou cestu k jakΘkoli Φßsti pam∞ti. To vÜak u velk²ch systΘm∙ vede ke znaΦnΘ hardwarovΘ slo₧itosti a k obrovskΘmu nßr∙stu ceny °eÜenφ.

NUMA û Non-Uniform Memory Access

SystΘmy NUMA v∞tÜinou obsahujφ vφce uzl∙ û nod∙. Takov² uzel si m∙₧eme p°edstavit jako jak²si zßkladnφ stavebnφ blok, kter² zpravidla obsahuje jeden nebo vφce procesor∙ a lokßlnφ pam∞¥. Pam∞tem na cizφch uzlech se °φkß vzdßlenΘ û remote memories. V dneÜnφch komerΦnφch a v∞deck²ch °eÜenφch existujφ tyto typy °eÜenφ distribuovanΘ pam∞ti.

ò Cache-Only Memory Architecture (COMA)
ò Cache-Coherent NUMA (CC-NUMA)
ò Non-Cache Coherent NUMA (NCC-NUMA) û jednotlivΘ uzly majφ p°φstup k pam∞ti vzdßlen²ch uzl∙, ale nenφ °eÜena koherence jednotliv²ch pam∞tφ.

KlφΦovou roli v NUMA architekturßch dnes hrajφ systΘmy COMA a CC-NUMA

COMA û Cache-only memory architecture
V tΘto architektu°e je pam∞¥ jednotliv²ch uzl∙ distribuovßna mezi ostatnφ uzly. Nealokuje se vÜak fyzick² adresnφ prostor, ale pam∞¥ ka₧dΘho uzlu je p°evedena do velkΘ cache pam∞ti, kterß v∞tÜinou b²vß pomalejÜφm mediem. P°evod se provßdφ dodateΦn²m hardwarov²m za°φzenφm. To umo₧≥uje velkou a pru₧nou replikaci dat, ale vy₧aduje komplexnφ hardware a protokol pro zajiÜt∞nφ koherentnosti dat. Tφm zpravidla b²vajφ:

ò HaÜovacφ funkce k mapovßnφ mezi fyzick²m adresnφm prostorem pou₧φvan²m procesorem a reßlnou fyzickou adresou DRAM cache, kterß m∙₧e dr₧et dan² zßznam.
ò Pam∞¥ovΘ tagy a porovnßvaΦe, kterΘ urΦφ, kterß °ßdka z danΘho setu cache pam∞ti obsahuje po₧adovanß data.
ò Extra pam∞¥ovΘ stavy k °φzenφ vybran²ch °ßdek z cache pam∞ti.

┌Φelem tohoto hardwarovΘho za°φzenφ je vytvo°enφ duplikßtu fyzickΘho adresnφho prostoru generovanΘho ka₧d²m procesorem na domßcφm uzlu. Tφm se COMA liÜφ od architektury CC-NUMA, kde fyzickß adresa p°φmo definuje, na kterΘm uzlu jsou data umφst∞na.

V²hodou COMA architektury proti CC-NUMA je umo₧n∞nφ v∞tÜφ flexibility (prßv∞ dφky tomuto p°idanΘmu hardwarovΘmu za°φzenφ). Data jsou automaticky kopφrovßna nebo migrovßna do fyzickΘ pam∞ti toho uzlu, kter² je prßv∞ bude pou₧φvat. Toto dynamickΘ vyva₧ovßnφ dat na jednotliv²ch uzlech umo₧≥uje systΘm∙m COMA tvß°it se jako CC-NUMA, vΦetn∞ vlastnostφ obsluhujφcφch migraci a replikaci strßnek pam∞ti pou₧φvan²ch v aplikacφch napsan²ch pro CC-NUMA systΘmy. To znamenß, ₧e na n∞kter²ch COMA systΘmech mohou b∞₧et aplikace, kterΘ ne zrovna dob°e mapujφ architekturu CC-NUMA, nap°φklad aplikace, kterΘ majφ po₧adovan² v∞tÜφ pam∞¥ov² prostor ne₧ jak² fyzicky mß dan² uzel. Nev²hodou COMA architektury je, ₧e vy₧aduje nestandardnφ pam∞¥ovΘ hardwarovΘ systΘmy. COMA systΘmy dnes pat°φ k nejv²konn∞jÜφm, ale da≥ za to je ve v vysokΘ cen∞ a v delÜφch v²vojß°sk²ch Φasech.

CC-NUMA û Cache-Coherent Non-Uniform Memory Access.
Fyzickß pam∞¥ je distribuovßna mezi jednotlivΘ procesory tak, ₧e malß Φßst pam∞ti v₧dy pat°φ k jednomu. Po₧adavek na pam∞¥ tak prochßzφ p°es vnit°nφ spojovacφ sφt. P°φstup k lokßlnφ pam∞ti b²vß rychl², ale latence p°i p°φstupu k vzdßlenΘ pam∞ti b²vß o v²razn∞ v∞tÜφ. Stejn∞ jako u jednoprocesorov²ch systΘm∙ se vyu₧φvß cache pam∞tφ L1 a L2 û viz obrßzek.

V tomto okam₧iku se asi hodφ vysv∞tlit, co rozumφme pod pojmem äcache coherentô pop°φpad∞ äcache coherencyô.
Nßsledujφcφ platφ nejenom pro systΘmy CC-NUMA, ale i pro systΘmy UMA (tedy PVP a SMP). Pokud si vezmu model z p°edchozφho obrßzku kter² obsahuje:

ò procesor;
ò L1 cache, kterß je malß (°ßdov∞ stovky kB), Φasto b²vß souΦßstφ procesoru a proto je p°φstup do nφ velmi rychl²;
ò L2 cache, kterß je ji₧ v∞tÜφ (°ßdov∞ desφtky MB), b²vß velmi blφzko procesoru a p°φstup do nφ je sice pomalejÜφ ne₧ do L1, ale stßle velmi rychl²;
ò lokßlnφ pam∞¥ RAM, kterß b²vß velkß (°ßdov∞ desφtky GB), je fyzicky dßle a i p°φstupovΘ Φasy k nφ jsou dlouhΘ.

V modelu si m∙₧eme p°edstavit procesor, kter² pracuje s elementy (t∞mi jsou data, instrukce a adresy) a nestarß se, co jsou zaΦ û prost∞ je zpracovßvß podle n∞jak²ch pravidel.
Tyto elementy jsou zapisovßny do registr∙. Najdeme je takΘ v L1 cache, kde n∞kolik tvo°φ pam∞¥ovou °ßdku (n∞kdy takΘ pam∞¥ov² blok), nejΦast∞ji o velikosti 32, 64 nebo 128 bajt∙ a u₧ zde (v L1 cache) najdeme instrukΦnφ °ßdky, adresnφ °ßdky a datovΘ °ßdky.

Pokud vφce procesor∙ sdφlφ lokßlnφ RAM pam∞¥, je t°eba vy°eÜit, jak k tΘto pam∞ti p°istupujφ. Pokud procesor pot°ebuje n∞jakß data, hledß je nejprve ve svΘ L1 cache, potom v L2 cache û kdy₧ je nenajde, ₧ßdß o n∞ v popsanΘm °et∞zci o stupe≥ v²Üe. Jde o po₧adavek typu ächci svoji kopii datovΘho bloku". Nßsledn∞ m∙₧e dojφt k n∞kolika scΘnß°∙m:

a) Äßdn² jin² procesor nemß kopii danΘho bloku û nenφ problΘm, procesor si ud∞lß kopii.
b) Jin² procesor mß kopii po₧adovanΘho bloku (asi nad nim pracuje û m∙₧e mφt na blok v²luΦnΘ prßvo nebo ho m∙₧e mφt v re₧imu, kdy ostatnφ procesory majφ prßvo dan² blok Φφst). Musφm tedy zajistit aby ämajitel" bloku zapsal svoje zm∞ny a blok uvolnil. V praxi jeÜt∞ existujφ p°esn∞jÜφ urΦenφ, v jakΘ pam∞ti (L1, L2, RAM) je prßv∞ dan² blok a v jakΘm je stavu.

Mechanismus, kter² zajiÜ¥uje udr₧ovßnφ po₧adovan²ch blok∙ v aktußlnφm stavu se naz²vß cache coherency.

V praxi existuje n∞kolik metod jeho implementace, nejpou₧φvan∞jÜφ jsou:

a) Broadcast (snooping) û vÜechny po₧adavky jsou posφlßny na vÜechna za°φzenφ a ta se poohlΘdnou (snoop), zda prßv∞ nevlastnφ dan² blok ve svΘ cache pam∞ti. Pokud ano, odpovφ.
b) Poin-to-point û po₧adavky jsou posφlßny pouze na ta za°φzenφ, o nich₧ je znßmo, ₧e m∞la n∞co do Φin∞nφ s dan²m blokem. V∞tÜinou to b²vß specißlnφ RAM, kterß si pamatuje ukazatele a jejich historii. ╚asto se ji takΘ °φkß director.

NORMA û Non-Remote Memory Access

U systΘmu s architekturou NORMA mß ka₧d² uzel sv∙j vlastnφ pam∞¥ov² adresnφ prostor û uzel nem∙₧e p°φmo p°istupovat k pam∞ti vzdßlenΘho uzlu. Pokud chce n∞jakß data ze vzdßlenΘ pam∞ti, vy₧ßdß je pomocφ pr∙vodnφ zprßvy (MP û Message Passing). Prvnφ uzel poÜle po₧adavek formou MP na druh² a ten v rutinnφ dßvce zkopφruje data na uzel prvnφ. Cel² mechanismus pr∙vodnφch zprßv je dnes po₧φvßn ve form∞ protokolu MPI nebo protokolu OpenMP.

NORMA model se dßle Φlenφ na MPP (Massively Parallel Processors) a klastry.

MPP û Massively Parallel Processors
B∞₧nß architektura MPP systΘmu je na nßsledujφcφm obrßzku:

VÜechny masivn∞ paralelnφ systΘmy pou₧φvajφ fyzickou distribuovanou pam∞¥ a stßle vφce systΘm∙ takΘ distribuovanß I/O za°φzenφ. Ka₧d² uzel mß jeden nebo vφce procesor∙ s cache (P/C), lokßlnφ pam∞¥ (LM) a v∞tÜinou n∞jak² disk (LD û local disk) a cache director (DIR). Uzel mß lokßlnφ propojenφ (interconnect), spojujφcφ procesor, pam∞¥ a I/O za°φzenφ. D°φve b²val tφmto propojenφm jeden z typ∙ sb∞rnice, u dneÜnφch MPP se spφÜe setkßvßme s crossbarovou architekturou s vysokou propustnostφ. Ka₧d² uzel je p°ipojen do sφt∞ prost°ednictvφm NIC (Network Interface Circuitry ).

MPP je typ systΘmu, v n∞m₧ pod jednφm programem b∞₧φ mnoho samostatn²ch proces∙. Tφmto se velmi podobß SMP s tφm velk²m rozdφlem, ₧e u SMP vÜechny procesory sdφlejφ jednu pam∞¥, zatφmco u MPP mß ka₧d² procesor pam∞¥ vlastnφ. Proto je takΘ psanφ program∙ pro MPP v²razn∞ slo₧it∞jÜφ, jeliko₧ aplikace musφ b²t rozd∞lena na segmenty, kterΘ mohou b²t vykonßvany samostatn∞ a dokß₧φ s ostatnφmi Φßstmi komunikovat. Na druhou stranu zde nenastßvß znßmΘ ·zkΘ hrdlo SMP systΘm∙, kdy₧ vφce procesor∙ zkouÜφ zßrove≥ p°istupovat ke stejnΘ pam∞ti.

MPP dnes zaΦφnajφ hrßt v HPC d∙le₧itou roli, a to dφky nφzk²m cenßm b∞₧n²ch Φip∙ i nφzk²m cenßm jednotliv²ch uzl∙ û velmi dob°e vychßzφ jejich pom∞r ceny k v²konu. Dokß₧φ takΘ nabφdnout obrovskou absolutnφ velikost pam∞ti a jejφ vysokou propustnost. Pro vhodnΘ problΘmy a pro Φßst ·loh s velk²mi po₧adavky na pam∞¥ jsou MPP systΘmy opravdovou jedniΦkou.

D∙le₧itΘ vlastnosti MPP:
ò pou₧φvß v procesnφch uzlech b∞₧nΘ Φipy;
ò pou₧φvß fyzicky distribuovanou pam∞¥ mezi procesorov²mi uzly;
ò podporuje standardnφ programovacφ modely jako PVM (Parallel Virtual Machine) a MPI (Message Passing Interface);
ò pou₧φvß interconnect s vysokou propustnostφ a nφzkou latencφ (velmi Φasto nap°φklad infiniband);
ò je to asynchronnφ MIMD stroj, tzn. ₧e procesy jsou synchronizovßny pomocφ blokov²ch operacφ s pr∙vodnφmi zprßvami;
ò program pro MPP obsahuje vφce proces∙, z nich₧ ka₧d² mß sv∙j vlastnφ adresnφ prostor a kterΘ mezi sebou komunikujφ pomocφ pr∙vodnφch zprßv (MP).

Klastry û Gridy
Klastry Φi gridy jsou systΘmy sestavenΘ z cel²ch poΦφtaΦ∙. Existujφ dva zßkladnφ typy klastr∙, prvnφ je slo₧enφm vφce poΦφtaΦ∙ s cφlem zφskat vyÜÜφ dostupnost (HA û High Availability) celΘho systΘmu, druh² typ je takΘ slo₧en ze samostatn²ch poΦφtaΦ∙, ale s cφlem zφskat vysok² v²poΦetnφ v²kon. DruhΘ skupin∞ se takΘ Φasto °φkß v²poΦetnφ grid.

V tomto Φlßnku hovo°φme o klastrech jako o systΘmech urΦen²ch pro HPC. Ka₧d² uzel klastru je do systΘmu p°ipojen spojenφm typu LAN nebo jinou sφtφ s vysokou propustnostφ. Typicky je ka₧d² uzel reprezentovßn SMP serverem, pracovnφ stanicφ nebo obyΦejn²m PC. D∙le₧itΘ je, ₧e vÜechny uzly musejφ b²t schopnΘ pracovat dohromady jako jeden integrovan² v²poΦetnφ zdroj.

Problematika klastr∙ a grid∙

CharakteristickΘ vlastnosti klastr∙ a grid∙
ò Ka₧d² uzel je tvo°en samostatn²m poΦφtaΦem. To znamenß, ₧e mß procesor s cache (P/C), lokßlnφ pam∞¥ (M), lokßlnφ disk (LD), interconnect (N IC), lokßlnφ I/O za°φzenφ a vlastnφ instanci operaΦnφho systΘmu.
ò JednotlivΘ uzly v klastru jsou navzßjem spojenΘ û b∞₧n∞ pomocφ vyhrazenΘ sφt∞ typu ethernet, FDDI, Fiber channel, infinibiband, mirinet nebo ATM. Velmi Φasto se p°i vzßjemnΘ komunikaci pou₧φvajφ standardnφ protokoly.
ò Klastry p°inßÜejφ takΘ zlepÜenφ dostupnosti urΦitΘ slu₧by (p°i v²padku jednoho uzlu m∙₧e jin² transparentn∞ zastat jeho prßci).
ò Klastry p°inßÜejφ lepÜφ vyu₧itφ stßvajφcφch v²poΦetnφch zdroj∙ (hovo°φ se o 80% vyu₧itφ procesorov² cykl∙).
ò Klastry mohou nabφdnout °eÜenφ ·loh na vy₧ßdßnφ (on demand), neboli poskytnutφ tolika zdroj∙ prßv∞ v tom Φase, kdy jsou pot°ebnΘ.
ò Klastry mohou spojit i vφce platforem, p°edevÜφm unixov²ch, resp. linuxov²ch.
ò Klastry mohou v °ad∞ typ∙ slu₧eb nabφdnout vyÜÜφ v²kon. Pokud ka₧d² z M uzl∙ klastru dokß₧e obslou₧it N klient∙, m∙₧e cel² klastr simultßnn∞ obslou₧it M*N klient∙. Klastr se dß vyu₧φt takΘ ke zkrßcenφ celkovΘ doby b∞hu ·lohy jejφm rozlo₧enφm do n∞kolika paralelnφch ·loh.

Cel² v²poΦet na klastrech mß n∞kolik rovin:
ò Rovinu budovßnφ klastru û spojovßnφ jednotliv²ch uzl∙ do sφtφ-grid∙ a fyzickΘ p°ipojenφ dalÜφch zdroj∙ typu diskov²ch polφ.
ò Rovinu °φzenφ klastru, jeho virtualizace do jednotnΘho systΘmu, kter² se sm∞rem k u₧ivateli m∙₧e tvß°it jako jeden stroj.
ò Rovinu psanφ aplikacφ a b∞hu konkretnφch ·loh.

Budovßnφ klastru û gridu
P°i v²stavb∞ klastru se dnes nejΦast∞ji setkßme se t°emi scΘnß°i:
1. Spojenφ stßvajφcφch v²poΦetnφch systΘm∙ do jednoho klastru. P°φkladem m∙₧e b²t univerzita nebo jinß v∞tÜφ organizace, kterß vlastnφ °adu pracovnφch stanic, st°ednφch server∙ a PC, kterΘ p°es den slou₧φ u₧ivatel∙m a v noci jejich v²poΦetnφ v²kon le₧φ ladem. Takovß organizace v∞tÜinou ji₧ mß i sφ¥ LAN, do nφ₧ jsou tyto stroje p°ipojenΘ. Potom u₧ staΦφ jen na ka₧d² stroj nainstalovat klientsk² software a nastavit pravidla pro chovßnφ celΘho systΘmu. ╚asto b²vß nejv∞tÜφ problΘm organizaΦnφ a bezpeΦnostnφ strßnka projektu. Z technickΘho hlediska m∙₧eme narazit na ·zkß hrdla ve spojenφ jednotliv²ch uzl∙ (LAN).
2. Organizace buduje klastr na zelenΘ louce a nakoupφ v∞tÜφ poΦet levn²ch stroj∙ (dnes nejΦast∞ji server∙ na platform∞ x86 s Linuxem). Tyto stroje propojφ dedikovanou sφtφ (jak u₧ bylo °eΦeno na technologiφch ethernetu, fiber channelu nebo infinibandu) a pro servery poskytne diskovΘ prostory, dnes nejΦast∞ji na bßzi diskov²ch polφch typu NAS (Network Attached Storage) a protokolu NFS.
3. T°etφ scΘnß° se velmi podobß druhΘmu a liÜφ se typem server∙. Nejoblφben∞jÜφmi servery do druhΘho scΘnß°e jsou servery vysokΘ jeden RU (sk°φ≥ov² modul) s jednφm nebo dv∞ma procesory û pou₧φvajφ se servery typu blade. V²hodou tΘto varianty je obrovskß hustota CPU docφlitelnß v malΘm prostoru. VÜichni velcφ v²robci u₧ dnes nabφzejφ blade servery, nicmΘn∞ jejich existence je zatφm p°φliÜ krßtkß a jejφch masovΘ rozÜφ°enφ se teprve oΦekßvß.

╪φzenφ klastr∙ û grid∙
Dnes existuje mnoho softwarov²ch produkt∙, kterΘ nabφzejφ klastrovou funkcionalitu, nap°φklad Sun ONE Grid Engine od firmy Sun Microsystems, Globus Grid od firmy IBM, LSF Φi open-source Boewulf. Jejich porovnßnφ by vystaΦilo na samostatn² Φlßnek, hlavnφ myÜlenka vÜak je spoleΦnß. U₧ivatel poÜle svojφ ·lohu do fronty, ·loze se najdou odpovφdajφcφ zdroje a pak se odeÜle k vykonßnφ. V²sledek se poÜle zpßtky klientovi.

Rozhranφm, kter²m u₧ivatel svoje ·lohy posφlß a prohlφ₧φ si jejich stav a status, b²vß dnes nejen p°φkazovß °ßdka (CL û Command Line) nebo grafickΘ rozhranφ (GUI û Grafical User Interface) ale i webovΘ rozhranφ typu portßl. O °azenφ ·loh do front, vyhledßvßnφ zdroj∙ a monitorovßnφ celΘho klastru se starß hlavnφ °φdφcφ server (master server). Na jednotliv²ch uzlech klastru je nainstalovan² klientsk² software, kter² p°φmß ·lohy od master serveru a postarß se o jejich zpracovßnφ. DneÜnφ klastry takΘ um∞jφ spojovat vφce menÜφch klastr∙ do velk²ch celk∙. ╚asto se tak m∙₧eme setkat s v²razy departmental grid (klastr vybudovan² v rßmci jednoho odd∞lenφ), enterprise grid (klastr slo₧en² z vφce menÜφch klastr∙, ale stßle v rßmci jednΘ organizace) Φi global grid (klastr klastr∙, grid grid∙, spojenφ vφce eneterprise klastr∙ na ·rovni region∙, stßt∙ nebo kontinent∙).

Dobrou zprßvou je takΘ to, ₧e existuje snaha o koexistenci r∙zn²ch typ∙ klastr∙ v globßlnφch gridech. Pracuje se na standardech, kterΘ umo₧nφ kompatibilitu nap°φklad klastr∙ u₧φvajφcφch Sun ONE Grid Engine nebo IBM Globus Grid.

Psanφ aplikacφ pro klastr û grid
Ka₧dΘmu, kdo jen trochu vφ, jak poΦφtaΦe fungujφ, musφ b²t jasnΘ, ₧e aplikace napsanß pro jednoprocesorov² stroj s nejrozÜφ°en∞jÜφ architekturou typu MIMD (nebo i pro vφceprocesorovΘ servery typu SMP) nem∙₧e jen tak b∞₧et na klastru slo₧enΘm ze stovek uzl∙. V drtivΘ v∞tÜin∞ p°φpad∙ je nutn² zßsah programßtora a rozsah tohoto zßsahu se liÜφ p°φpad od p°φpadu. Platφ zde klasickΘ schΘma:

ò °eÜφm reßln² problΘm;
ò problΘm popφÜi fyzikßlnφm modelem;
ò fyzikßlnφ model popφÜi matematick²m modelem;
ò najdu vhodnΘ numerickΘho schΘma odpovφdajφcφ matematickΘmu modelu;
ò napφÜi aplikaci, kterß odpovφdß numerickΘmu schΘmatu;
ò p°i psanφ aplikace pou₧φvßm n∞jak² programovacφ model, p°φpadn∞ z n∞ho odvozen² programovacφ jazyk (C,C++,F77,F90) û programovacφ model je poplatn² hardwarovΘ architektu°e.

Programßtor je tak p°i psanφ aplikace dr₧en äuprost°edô a jeho k≤d musφ odpovφdat jak programovacφmu modelu, tak i navr₧enΘmu numerickΘmu schΘmatu. P°i psanφ aplikace pro klastr pak obecn∞ stojφ p°ed ·kolem problΘm rozlo₧it do menÜφch paralelnφch ·loh.

ProblΘm paralelizace
N∞kterΘ problΘmy z reßlnΘho sv∞ta lze velmi dob°e paralelizovat ji₧ p°i tvorb∞ fyzikßlnφho a matematickΘho modelu. V takovΘm p°φpad∞ b²vß zßsah programßtora relativn∞ mal². VÜechny reßlnΘ problΘmy toto Üt∞stφ nemajφ a pak programßtor musφ °eÜit i modifikaci programovacφho modelu. Setkßvßme se zde s t∞mito pojmy:

Vlßkna û samostatnΘ procesy, majφcφ vφce exekuΦnφch cest.
RMO (Remote Memory Operation) û sada proces∙, z nich₧ ka₧d² m∙₧e p°istupovat k pam∞ti jinΘho procesu bez jeho asistence.
SMD (Shared Memory Directives) û p°φkazy, pomocφ nich₧ u₧ivatel definuje, jak se ·loha paralelizuje. Zp∙sob rozlo₧enφ dat je v tomto p°φpad∞ implicitnφ a vnit°nφ komunikace je takΘ implicitnφ. Samotnß paralelizace nastßvß p°i kompilovßnφ. S tφmto typem paralelizace se nejvφce setkßvßme u SMP stroj∙ a od roku 1997 je v tΘto oblasti standardem OpenMP. Typicky jsou dßny sekce, kterΘ majφ b²t provßd∞ny paraleln∞, a rovn∞₧ jsou dßny smyΦky, kterΘ majφ b∞₧et paraleln∞.
Datov² paralelizmus û u₧ivatel definuje, jak budou data distribuovßna, a vnit°nφ komunikace je implicitnφ. U₧ivatel explicitn∞ definuje rozlo₧enφ na menÜφ komponenty a vlastnφ paralelizace nastßvß p°i kompilovßnφ. Standardem je dnes HPF (High Performance Fortran). TypickΘ jsou distribuovanΘ matice a vektory a pole s podobnou konstrukcφ.
Message Passing (pr∙vodnφ zprßvy) û u₧ivatel definuje jak budou data distribuovßna, kdy a jak bude provedena vnit°nφ komunikace a explicitn∞ definuje i rozd∞lenφ dat a komunikace. Standardem je dnes MPI (Message Passing Interface)

Kter² z model∙ paralelizace je pro dan² problΘm vhodn² zßle₧φ na aplikaci, na hardwarovΘ platform∞, na tom, jakß ·Φinnost je od platformy oΦekßvßna a na tom, kolik Φasu je k dispozici pro realizaci paralelizace.

Typ systΘmu	SMP	Klastry slo₧enΘ z SMP stroj∙ s mo₧nostφ p°φstupu do vzdßlen²ch pam∞tφ RDMA (remote directive memory access)	Klastry slo₧enΘ z SMP stroj∙ bez mo₧nostφ p°φstupu do vzdßlen²ch pam∞tφ RDMA (remote directive memory access)	MPP
bez ochrannΘho programovßnφ	OpenMP	OpenMP nebo HPF	HPF	HPF
s ochrann²m programovßnφm û ruΦnφ prßce	MPI	MPI+OpenMP	MPI+OpenMP MPI je aplikovßno na vÜech procesorech	MPI

Charakteristika typ∙ gridovΘho systΘmu:
snadno programovateln²
t∞₧Üφ na programovßnφ
nßroΦn² na sestavovßnφ k≤du
velmi nßroΦn² na sestavovßnφ k≤du
slo₧it² na sestavovßnφ paralelizovanΘho k≤du

Reference
Dnes se setkßme s implementacφ grid∙ nejΦast∞ji v t∞chto odv∞tvφch:
ò EDA (Electronic Design Automation) p°i nßvrhu a testovßnφ elektronick²ch souΦßstek.
ò Aplikovanß v∞da: genovΘ in₧en²rstvφ, farmacie.
ò Automobilov² pr∙mysl: bariΘrovΘ testy, nap∞¥ovΘ testy, aerodynamika.
ò EDA: simulace, ov∞°ovßnφ, zp∞tnΘ testy.
ò Zßbavnφ pr∙mysl: rendering filmov²ch polφΦek.
ò T∞₧a°sk² pr∙mysl: vizualizace, anal²za dat.
ò V²voj softwaru: sestavovßnφ k≤du.
ò V∞deck² v²zkum: ·lohy s velk²mi v²poΦetnφmi nßroky.

Vesm∞s jde o ·lohy kterΘ majφ dßvkov² charakter a vyznaΦujφ se dlouhou dobou b∞hu.

KonkrΘtnφ reference m∙₧ete najφt nap°φklad na nßsledujφcφch adresßch:

http://wwws.sun.com/software/grid/success.html
http://www-1.ibm.com/grid/grid_customer.shtml

Jednoduch² nßvod na vybudovßnφ gridu
1. Identifikujte svΘ pot°eby. Pro ka₧d² typ ·lohy, kterou chcete zpracovat v gridu, byste m∞li znßt typ ·lohy (b∞₧φ v jednom vlßknu, ve vφce vlßknech nebo ve vφce procesech), pam∞¥ovΘ nßroky na procesech a dobu b∞hu procesu. Pokud jde o ·lohu b∞₧φcφ ve vφce procesech, analyzujte ·rove≥ meziprocesnφ komunikace a podle toho se rozhodn∞te, zda pot°ebujete stroj SMP nebo rychl² interconnect.
2. Odhadn∞te, jak se vaÜe nßroky budou m∞nit v blφzkΘ budoucnosti.
3. Zjist∞te, zda n∞kterß aplikace nem∙₧e b∞₧et pouze na danΘ platform∞. To ovliv≥uje mo₧nost mφt v klastru vφce platforem.
4. UrΦete, existujφ-li mezi stßvajφcφmi stroji takovΘ, kterΘ by mohly slou₧it jako v²poΦetnφ uzly budoucφho klastru.
5. Za°i∩te, aby byl klastr spravovateln² jako jeden v²poΦetnφ zdroj:
ò vytvo°te nebo pou₧ijte stßvajφcφ nßstroj pro äsoft updateô (nßstroj na automatickΘ instalace OS a jejich snadnΘ konfigurace);
ò vytvo°te nebo pou₧ijte stßvajφcφ nßstroje na automatickou instalaci patch∙;
ò pokud bude v klastru licenΦnφ server, ujist∞te se, ₧e mß vysokou dostupnost;
ò vytvo°te nebo pou₧ijte hotov² nßstroj, kter² umφ zajistit b∞h ·lohy na libovolnΘm uzlu klastru;
ò vytvo°te nebo pou₧ijte hotov² nßstroj, kter² vßm umo₧nφ °φdit cel² klastr z jednoho bodu.
6. Rozhodn∞te se, jak² budete pou₧φvat frontov² systΘm (NQS, PBS, Sun ONE Grid Engine, LSF). Nainstalujte jej na nod, kter² bude ve funkci front master. Pokud budete v klastru pot°ebovat sdφlenφ soubor∙, budete asi pot°ebovat diskovΘ pole typu NAS, kterΘ poskytuje diskovΘ prostory nap°φklad p°es NFS. Pokud budete na n∞kter²ch uzlech pot°ebovat knihovny MPI, nainstalujte je.
7. NauΦte u₧ivatele posφlat ·lohy do front mφsto toho, aby je spouÜt∞li interaktivn∞.
8. Rozhodn∞te se, kterΘ dalÜφ v²poΦetnφ zdroje zapojφte do gridu. Vytvo°te pravidla k tomu, aby stroje s jednφm procesorem byly vyu₧φvßny pro jednoprocesorovΘ ·lohy a stroje s dv∞ma Φi vφce procesory pro ·lohy vφceprocesorovΘ.
9. Pokud jsou n∞kterΘ aplikace paralelizovanΘ, ale jejich vnit°nφ komunikace nenφ p°φliÜ intenzivnφ, m∙₧ete zvß₧it spojenφ n∞kolika uzl∙ rychl²m interkonektem typu mirinet nebo p°idßnφ SMP stroje do klastru.
10. Pokud jsou n∞kterΘ aplikace paralelizovanΘ a jejich vnit°nφ komunikace je velmi intenzivnφ, je p°idßnφ v∞tÜφho SMP stroje nebo spojenφ stßvajφcφch uzl∙ rychl²m interkonektem tΘm∞° nutnostφ.

TomßÜ Okrouhlφk

Infotipy:
http://www.sun.com/grid
http://www-1.ibm.com/grid
http://www.hp.com/techservers/grid
http://help.aei-potsdam.mpg.de/sc/lsf
http://www.beowulf.org
http://www.openmp.org
http://www-unix.mcs.anl.gov/mpi
http://www.sun.com/blueprints
http://www.hlrs.de

Pou₧itß literatura:
Sun blueprint û Sun Based Beowulf Cluster
IBM redbook û Introduction to Grid Computing with Globus
Wolfgang Gentzsch û Grid Computing: A New Technology for the Advanced Web
Jaroslav Nadrchal, FZU AV╚R û Architectures of Parallel Computers
Rolf Rabenseifner, Michael M. Resch, University of Stuttgart û Hardware Architectures and Parallel Programming Models