Vlákno názorů k článku Debian Lenny a stavba výpočetního clusteru od František Ryšánek - Z článku je zřejmé, že o instalaci se pokoušel člověk,...

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.