Názory k článku
Debian Lenny a stavba výpočetního clusteru

clanok nebudem hodnotit, len si dovolim pridat zaujimavy odkaz. myslim, ze CR a SR su na tom dost podobne. http://blackhole.sk/…e-sa-slovaci

Kdyby si autor udělal pořádnou řešerši webu, možná by ušetřil sto litrů a spoustu práce.

http://meta.cesnet.cz/

O tomhle clusteru vím, je dokonce ve stejné budově jako ten náš. Také jsme uvažovali o jeho použití a měl jsem to tedy i uvést. Bohužel tento cluster se vyznačuje neustálým vývojem a častěji neběží než běží a myjsme potřebovali něco, co nainstalujem a poběží to. Navíc si myslím, že poplatky za využívání clusteru PřF by byly možná ještě vyšší než nákup počítačů.

No, projekt Metacentrum je pokud vím vědecký projekt, financovaný hlavně z grantů, takže stačí zažádat o přístup a zdůvodnit na jakém vědeckém projektu pracujete. Co vím, pomůžou vám s instalací programů, možná i operačního systému a zařazení vašich počítačů do jejich sítě (bez nutnosti je poskytovat všechny jiným uživatelům). Dokonce vám pomůžou i s instalací vašich programů v rámci jejich clusteru nebo i gridu, ale s přísným ohledem na licenci.

BTW, pokud jde o instalaci nodů, zajímavý je projekt Fully Automated Installer (fai) přítomný v debianu.

Např. popis na stránkách ZČU je již doufejme docela zastaralý http://zsc.zcu.cz/hardware.html . Pokud ne, pak trochu nechápu smysl provozu takových strojů. Pravda, ty alfy jsou již dle webu metacentra vyřazené z gridu.

Pokud mate cluster ze 4 pocitacu, mohli jste finance investovat lepe a udelat si registraci v Metacentru. Je to zdarma, vypocetniho vykonu nabizeji dost a dokazi splnit i specialni pozadavky.

Metacentrum vyuzivam a rozhodne nemohu rici, ze by nefungovalo a vse bylo ve vyvoji. S vypadky musite pocitat i u Vaseho maleho clusteru. Vyuzivani Metacentra je zdarma, proto nevim, komu byste mel platit za pouzivani.

metacentrum je nechutny tunel na penize, ale to vetsinu „je to zdarma“ nezajima

To by mě zajímalo. Můžeš to rozvést?

taky jsem pred 5 lety skladal cluster kolegum co delaji molekularni simulace.
a bylo to jednoduche, stacilo spojit nekolik pocitacu do gigoveho ethernetu,
dns se nepouzilo, z uzlu na uzel se dostalo pomoci rsh nebo ssh, domovsky adresar a nejake programy se sdilely v NFS, uzivatele a hesla se resily kopirovanim souboru na uzly a veskere schopnosti pro paralelni programy zajistovala knihovna MPI. zadny extra soft se nemusel pouzit.

Presne tak, na par takovych clusteru jsem pocital, maximalne myslim kolem 25 uzlu, zadny specialni soft tam nesel, vse pres MPI. Aspon to nedelalo bordel a nerozdazovalo to load balancing. Pocital jsem na par masinach se specialnim softwarem, ale pro mne jako uzivatele nic noveho neprinasel (jen to, ze jsem se musel hlasit do fronty a nedaly se killnout zatuhle procesy jinak nez telefonem adminovi nebo ze jsem mel teoretickou moznost migrovani procesu, ktera nefungovala).

Pro administrovani se nejaky clustrovy system hodi, zjednodusuje to zpravu a dava konzistenci (neni nad to mit na kazdem nodu jinou vezi sdilenych knihoven pro X a hledat, proc paralelni program nahodne segfaultuje).

Clanek mi prijde trochu o nicem – ala „koupil jsem si 4 PC a nainstaloval na nich soft, kterej nema dokumentaci a nechodi“

ja jsem tenkrat zadny balancovaci system nedaval, protoze cluster s MPI
pouzivalo par kolegu a tem nebylo zatezko kouknout na uzly jak jsou vytizene a podle toho spustit vhodne paralelni vypocetni soft co si sami psali s MPI.

dnes bych uz radeji skladal vykonny stroj s nabusenyma grafarnama a narocne vypocty delal pomoci CUDA. napriklad knihovny BLAS a FFT uz jsou pro CUDA.

Strasne ten hype okolo GPGPU. GPGPU se zdaleka nehodi pro vsechny vypocty. Odvazuju se rict, ze se hodi dokonce jen pro male procento vypoctu.

1) Ten ohromujici vykon je jen v single precision.
2) GPU maji malo pameti (ano 2GB je malo) a transfer z RAM stoji hodne casu.
3) Vetsina vedeckych vypoctu se provadi ve specialnich aplikacich, casto komercnich a uzavrenych. Takze i kdyby mela implementace GPGPU pro dany ucel smysl, jen tak se ji nedockame.

ad CUDA a BLAS: cuBLAS je jen single precision, navic nejslozitejsi operace, kterou BLAS umi je nasobeni matic, a to vedcum opravdu nestaci:) Az bude pro CUDA prepsany i LAPACK, zacne to byt aspon trochu zajimave.

A taky až bude CUDA umět pracovat s řídkými maticemi… Jinak ad 1), 2) i 3) naprostý souhlas, dnes je to pro řešení většiny reálných (neakademických) problémů k ničemu, snad časem.

Pravidla dotaci ve statni sfere stale pouzivaji pojem zakladni prostredek? Ceske ucetni standardy hovori o dlouhodobem investicnim majetku.

Nemůžu za to jak tomu říkají naše účetní. Prostě nesmíme nakupovat nad 40 000 Kč. Je menší problém koupit tři počítač za 39 000 než jeden za 41 000.

a preto sa to robi tak ze sa kupi od jednej firmy pocitac , tlaciaren, servisne prace rozpisane na 3 faktury po 39000 a firma doda jeden poriadny pocitac – vyriesene za 1 den

riesenie vedeckym pristupom – 2 tyzdne hladania softu,nadavania pri instalacii a vysledok neviemaky

Z článku je zřejmé, že o instalaci se pokoušel člověk, který je především koncovým uživatelem aplikací. Problémy, které při tom zažíval, jsou do značné míry identické s problémy, které zažívá obyčejný uživatel, pokud se snaží nainstalovat Linux a trochu se v něm zabydlet podle svého.

Pro hraní s clusterem je podle mého optimální, když správce, který cluster instaluje a provozuje, Linuxu trochu více rozumí „pod kapotou“. V ideálním případě by měl umět trochu Cčko a neměl by mít zábrany zkompilovat si cokoli ze zdrojáků. Pokud spuštění kompilátoru a dohledání pár závislostí a priori problém, tak je chyba někde mezi židlí a klávesnicí :-) Přece jenom se na správce budou obracet uživatelé, kteří si taky třeba píšou nějaký software a o kompilaci, knihovnách apod. může být dost často řeč.

Software clusteru se podle mého skládá z několika oblastí, které jsou do značné míry nezávislé:

1) bootující základ operačního systému pro „compute nodes“. Mým oblíbeným postupem je bootovat po síti (diskless). Tím máte zaručeno na všech diskless nodech identické prostředí a nemusíte řešit problémy toho typu, že Vám někde instalační skript doběhl a jinde zhavaroval, že se jednotlivé nody začínají lišit (lhostejno, čí vinou). Pro diskless boot lze použít jakékoli řešení, klidně třeba LTSP, ze kterého můžete vynechat XWindows. Nebo něco, co si stlučete doma na koleně.
Poskládat bootující Linux není koncepčně o mnoho složitější, než poskládat bootovačku MS-DOSu. Výchozím bodem je pořídit si nějaké železo na hraní a nebát se toho (nejde o produkční systém, nevadí když ho rozbijete). Jestli pak ten diskless node bude bootovat ostříhaný Debian nebo Fedoru, to je dost jedno. Resp. je výhodné pořídit si obdobu prostředí, na kterém na svých pracovních stanicích pracují koncoví uživatelé (kvůli přímé kompatibilitě kompilovaných aplikací).

2) standardní unixoví démoni na masteru, konfigurace sítě, zajištění konektivity do internetu. Třeba dávat jednotlivým nodům veřejné adresy a připojovat je do inetu přímo jenom přes router, to bych v dnešní době považoval za zpátečnictví (pravda s jistou dávkou sympatické nostalgie). Spíš bych to viděl na privátně číslovaný subnet jenom pro cluster, ven do internetu skrz NAT, příchozí relace (SSH apod) přes mapované porty a možná s bouncem přes nějaký intermediate server ve vnitřní síti (třeba přes master, pokud se nebojíte vystavit ho jedním fousem do inetu). Pokud má být cluster uvnitř instituce vidět přímo po vnitřní LANce, tak bych to přesto oddělil aspoň routerem a dal bych clusteru vyhrazený switch – kvůli oddělení různých potenciálních provozních „vedlejších efektů“ mezi clusterem a kancelářskou sítí.

3) samotný clustering, paralelizace výpočtů. Tohle je podle mého dáno především koncovou aplikací, od které (resp. od jejíchž implementátorů) by měl vzejít požadavek na framework/knihovnu, pomocí které rozkládání práce poběží. Tuto knihovnu potom nainstalovat na master a do „šablony diskless worker nodu“. Odhaduji, že se ve finále bude jednat o pár souborů a možná nějaký modul do kernelu. Tohle je pro mě osobně ta nejvyšší věda z celého clusteru.

Držím palce lidem, kteří si takovéhle věci staví. Obohacují tím jednak uživatelský vědní obor (a lidi z tohoto oboru), jednak taky sami sebe a své schopnosti. Výkon jednotlivého počítače rozhodně neškáluje donekonečna (spíš naopak, C2Q v desktopové desce má možná optimální poměr výkon/cena) a cluster je pro mnoho potřeb velmi užitečný přístup. A hlavně: co si otestujete a nacvičíte na malém clusteru složeném z pár počítačů, to může při dobrém návrhu velmi dobře škálovat na supervýkonné clustery o mnoha stovkách nodů. Takže si nácvikem na levném malém clusteru můžete ušetřit docela dost peněz za čas velikého nájemného stroje.

Konkrétně u jednoproceso­rových strojů s procesory „Xeon“ chci upozornit, že v předchozí generaci (Core2Duo/Quad) byly Xeony 3000 series identické s Core 2 Quad, a použitím Core 2 Quad namísto Xeonu 3000 se daly ušetřit nějaké peníze. Serverové Xeony 5000/7000 series měly trochu víc keše, ale zase se musely potýkat s relativně pomalejší sdílenou FSB a společným paměťovým řadičem, nemluvě o ceně…
V případě Core i7 (mimochodem výborný procesor pro věděcké výpočty) je to všechno zase trochu jinak, přinejmenším v první generaci byl k dispozici v podstatě jediný čipset a jediná rodina procesorů…

Ohledně „čerstvosti“ dokumentace a clusterových distribucí: je třeba pochválit kohokoli, kdo zveřejní svoji práci a aspoň trochu ji učeše, aby byla k užitku ostatním. Zejména je třeba toto vyzdvihnout u projektů, které mají relativně omezený počet dalších uživatelů (tedy kde se zveřejnění tolik „nevyplatí“, jako u projektů pro běžného spotřebitele). U specializovaných projektů není k dispozici zdaleka tolik peněz na nějakou trvalou údržbu a aktualizace. Jakákoli dokumentace, i starší, je důležitá spíše tím, že ukazuje směr. Že to jde, a zhruba co je k tomu potřeba. Nemůžete srovnávat jednotlivce nebo malý tým, kteří si uplácali vlastní cluster a zveřejnili postup jak na to, s týmy které vyvíjejí Firefox nebo Apache.

Třeba dávat jednotlivým nodům veřejné adresy a připojovat je do inetu přímo jenom přes router, to bych v dnešní době považoval za zpátečnictví (pravda s jistou dávkou sympatické nostalgie). Spíš bych to viděl na privátně číslovaný subnet jenom pro cluster, ven do internetu skrz NAT, příchozí relace (SSH apod) přes mapované porty a možná s bouncem přes nějaký intermediate server ve vnitřní síti (třeba přes master, pokud se nebojíte vystavit ho jedním fousem do inetu).

Hmm, veřejné IP je zpátečnické, proto tomu dáte privátní a mapujete porty. :-(

Pokud to bude na IPv6 tak klidně :-) Na IPv4 mi tohle přijde jako klasický případ technologické vnitřní sítě, u které by bylo veřejné číslování vysloveně plýtváním. Plýtváním, které voní dávnými zlatými časy.

Jinak jsem měl pocit, že výpočetní cluster je v podstatě takový back-end, na který není potřeba lézt přímo zvenčí. Čekal bych, že práce se zadává masteru. Potažmo běžný uživatel bude mít potřebu bavit se přímo hlavně (možná výhradně) s masterem. Když jednotlivé diskless pracanty schováte za firewall s NATem, houby zle. Bezpečnostní konfigurace pro přístup zvenčí se bude řešit na masteru.

100% souhlas!
e.

Node, ne nod.

Existuje take zajimava vec jmenem InfernoOS, coz je distribuovany Unix-like operacni system, ktery se da dokonce spoustet nejen nativne, ale take jako aplikace pro windows/Linux. Nejsem si jisty, jestli je moznost uzpusobit mu aplikace tak, aby vyuzily jeho potencial co nejlepe, ale jinak na nem existuje urcita moznost sdileni systemovych prostredku. Na slovensku dokonce kdysi existoval projekt Melua Grid, ktery rozjizdel takovy superpocitac jako komunitni sit.

http://code.google.com/p/inferno-os/

Neda mi to, a prispeji tez ukazkou sve hromadky zeleza. Je to klastr postaveny na zaklade specifickych pozadavku na nasem ustavu. Konkretne jde o potrebu spoustet mnoho jednovlaknovych uloh a mit moznost dynamicky alokovat CPUtime podle nice. Vyhodou meho reseni je prakticky nekonecny uptime (neboli odolnost proti vypadkum proudu), nevyhodou je m.j. to, ze ridici SW je psany na kolene a jeho udrzba zavisi na case a dusevnim zdravi jednoho cloveka. Presto, pokud by nekdo touzil nasi selmu okopirovat, necht se ozve (na strankach je e-mail).

Bacha na disk usage /home ;)

Na taketo veci je velmi dobry Condor http://www.cs.wisc.edu/condor/

A tenhle znate?

http://helmer.sfe.se

Super je taky Helmer2 a Helmer3 to je onoco… :-).

http://helmer2.sfe.se
http://helmer3.sfe.se

Moje dlouholetá zkušenost je, že přímý přístup na nody z Internetu je nevýhodou. Proč? Kvůli bezpečnosti. Musíte instalovat updaty a rebootovat podle aktuální dostupnosti záplat, protože jinak se vystavujete riziku napadení. Navíc po ukončení podpory pro vaši distribuci ve verzi x.y musíte provést upgrade. Když ale celý cluster dáte za nějaký access server, který dělá NAT, tak aktuální musíte udržovat jen ten access server. Nody a master server updatujete jen když se vám to hodí. Například když tam běží jeden nebo dva týdny trvající výpočty, tak určitě nechcete dělat update jádra s následným rebootem před jejich dokončením. Osobně se domnívám, že si mnou popisované problémy plně uvědomíte až po delší době používání.

Když tak koukám na IPčko u Vašeho příspěvku, které bonznul server root.cz, tak bych Vám chtěl poděkovat za názor, protože názor člověka, který je zvyklý pracovat s veřejně číslovanou IPv4 sítí o rozměru „třídy B“, má určitou váhu :-)

A co nakoupit několik PS3 konzolí? To by byl mazec.

http://en.wikipedia.org/…on_3_cluster

autor clanku necht mi promine, ale podezrivam ho z notne davky ignorance okerenene nezdravou spetkou masochismu ..

{,open}solaris + cluster express je relativne spolehlive a sofistikovane reseni. pokud nekdo baziruje na Linuxu budiz, pokud nekdo potrebuje *skutecny *cluster, tak po Linuxu asi nesahne ..

afaik je cluster express natolik podobny velice dobre dokumentovanemu sun clusteru, ze ona dan za to, ze je zadarmo – a sice, zadna podpora – neni az zas tak bolestiva ..

Každý pod pojmem cluster rozumí něco jiného. Ale nikdo si nevzpomněl na opravdové clustery, kdy skupina počítačů se tváří jako jeden, kdy tato skupina sdílí společný virtuální paměťový prostor. Výpadek jednoho uzlu jen sníží společný výkon. Kdy není třeba vytvářet speciální aplikace pro cluster. Tichou vzpomínku držme např. na True Cluster v systému True64.

Šedý Linuxovsko/Win­dowsovský mor nám nějak zastínil tato krásná řešení. Třeba se znovu objeví v budoucnu. Nové Windows prý oprášily starý dobrý MACH si mikrojádrem
:-). Tak proč bychom se v budoucnu nedočkali třeba opravdových clusterů na Linuxu – ne jenom sranda clusterů.

I to MPI je jen hračka. Kdyby si METACENTUM za ty prachy koupilo jeden pořádný server (např. z10), tak by nejen ušetřili ale hlavně spočetli toho řádově více (a i ten jejich Linux je tam také možné virtualizovat). Jenže holt by přišli o tu svou krkolomnou hračku.

Toto je, s odpostenim pekny blabol. Kdyz je MPI jen hracka, tak proc se vyuziva na drtive vetsine kompu z top500?

Zkratka v HPC je vice pristupu a vice reseni a kazde z nich je vhodne na neco jineho.

Dalo by se teoreticky tohle vyuzit i k hrani her? Spojit par starsich pocitacu.