HPC2009 - előzmények

A tavaji év folyamán az ELTE-IIG beszerzett egy HPC-t. Irdatlan sok munka volt a beszerzéssel, jól akartuk csinálni. A szállítás átcsúszott idénre, januárban (tervezik) szállítani. Hogy is néz ez ki:

Közönséges PC-k ethernet feletti clustere.
Najó, 2 procis rackelhető szerverek duál gigabites clustere. Intel Nehalem XEON E5520 cpu-val szerelve. 90 darab cpu-val, értsd 360 mag.
Az egyik gép kijelölt, ez a fejgép (fejgép = HN) A fejgép hardveresen másmilyen is, mint a többi. A maradék 44 gép egyforma (számoló szerver = CN). Ez a cluster nem túl nagy, emiatt úgy döntöttünk, hogy az adatterítést (a $HOME terítése valami hálózati filerendszerrel) nem dedikált gép végzi, hanem a HN másodállásban.

Majd ha megjön a gép, lesz kép is.

Röviditések:

HPC
High Performance Computing. A nevével ellentétben gépet értünk alatta, azt, amit elsősorban számolásra tervezünk. És nem mondjuk adatbáziskezelésre, játékra, tartalomszolgáltatásra, szövegszerkesztésre. Szokásos újságírói megfogalmazásban 'szuperkompjúter'
ELTE-IIG
Eötvös Loránd Tudományegyetem Informatikai Igazgatóság, http://iig.elte.hu
HN
Head Node. Az interaktív belépésre szolgáló gép, ami a cluster vezénylését (és managelését) látja el.
CN
Computing Node. A feladatok futtatására kijelölt gép. Általában interaktív belépés nem engedett. Saját háttértára nincs, vagy elhanyagolható.

( _ventura_ v | 2010. 01. 02., szo – 17:17 )

azt lehet tudni, hogy mik fognak rajta majd futni?

CoreDuo L2400, 4G, Ubuntu 9.10, 2.6.31

debian/lenny
CN: wakeonlan, pxeboot, nfsroot (single system image)
HN: local disk boot, tftp+dhcp+NFS szerver, NFS vagy jobb szerver a $HOME-nak
PVM/MPI cluster, valami job schedulerrel (queue manager) pl sun grid engine

ha nem kuszik fel a debian/lenny, akkor probalkozunk ebben a sorrendben:
ubuntu lts
ubuntu legfrissebb
redhat enterprise
suse
lfs vagy gentoo
ha egyik sem kuszik fel, akkor beadom a lemondasomat ;)

Ha eljon ez az ido, akkor minderrol reszletsen.

Userek szeretnenek windows HPC clustert (specifikus binaris alkalmazasoknak), emiatt tervben van egy (low-prio :-) project, hogy KVM alapu virtualis windows clustert epitsunk, amit a job schedulerrel normal HPC jobkent lehet elinditani, es kuzdjon meg vele a user (a virtualis windows HPC-n admint kap)

a szerverekhez redhat van megajanlva gyartoilag. (opcionalis, nincs berendelve)
teljes installt (faltol-falig megoldast: oprendszer, sge, mpi) install-teszt-konfigot szandekosan nem kertunk. Mondjuk 44 darab CN helyett 30 darab CN-re futotta volna.
Masreszt meg ugy veljuk, hogy nincs a hp-ibm-sgi-fujitsu-* magyarorszagi kereskedoi kozossegnek olyan szakembergardaja, akik kiugroan jobbak lennenek, mint mi ;)

egyebkent ez a teljes konfig egy elegge uj dolog. Mindig van eselye annak, hogy valahol elcsattanunk. Csodalkoznek, ha nem menne fel a debian/lenny a kivant funkcionalitassal. Azon is csodalkoznek, ha nem kellene egyedileg forditani egyet az openmpi csomagon. :-) A lenny kernele vagy jo, vagy nem, mondjuk 20% eselyt adok neki, hogy ujabb/patchelt kernel kell, es mondjuk 2% eselyt, hogy az a patch-et nekunk kell megirni. Ez belefer. Attol, hogy egy egyedi szerver minden hardvereleme mukodik linux alatt, meg nem biztos, hogy a cluster osszeall.

uzemeltetunk cca 35 debian/stable rendszert, emiatt ez az elso.
Az ubuntu/lts es a debian/stable kozott egeszen marginalis kulonbseget latok rendszergazdakent, es azt is inkabb az ubuntu/lts javara (*), emiatt az a masodik. Mivel ez egy kutatoi cluster, amiben szinte mindent alarendeltunk a szamolasi teljesitmenynek (egy kicsit a megbizhatosagot is peldaul) emiatt belefer egy linux from scratch is, ha nagyon muszaj.
Termeszetesen a RHEL ugy ertendo, hogy centos. Ha elakadunk benne, akkor lesz belole RHEL. Igazabol ezt a scenariot nem tudom elkepzelni. Marmint azt, hogy valamit ne tudjunk eletre lehelni debian/stable alatt, amire van gyartoi tamogatas RHEL-hez.

(*) valaszolj az alabbi ket kerdesre:
- mikor jon ki a kovetkezo debian/stable?
- mikor jon ki a kovetkezo ubuntu/lts?

Ubuntu LTS nem annyira sokara.
- April 29th, 2010 – Final release of Ubuntu 10.04 LTS.

Debian.. soka.. nagyon soka. :)

A teljesitmeny az elsodleges. Teljesitmenyben CentOS viszi a palmat. S ha viszi a gep (mivel ezzel ajanlottak, gondolom viszi) akkor miert ne? [url=http://www.phoronix.com/scan.php?page=article&item=centos_54_comparison…

"CentOS 5.4 ended up winning 11 of these tests"

Nem érdekes az oprendszer teljesítménye szinte semmilyen szempontból. Marginális még a libc hatása is. A userek backendként az intel math kernel libraryt akarják használni, a számolások memóriára és cpu-magra osztottak, sem a VM-nek sem a schedulernek nincs jelentősége. A MPI/PVM libek várhatóan számítanak, azokat várhatóan újrafordítjuk, hozzáhangoljuk a hardverhez.

Phoronix (vagy prohardver) teszteket leginkább azért szoktam olvasni, hogy lássak néhány alkalmazást, amivel soha az életben nem találkozom :-)

ibm-nek van tesztlaborja és ott ezeket a dolgokat ki lehet próbálni.
nem tudom, milyen gépeket vettetek végül, de nehogy belefussatok a debian opensource náci hülyeségeibe :) (konkrétan hogy egy-két hálókártya firmware-jét kihajították a kernelből, buheráld bele külön csomagból, ez főleg tftp bootnál kicsit izgalmas lehet).

Ekkora megrendelésnél én biztos addig kavartam volna, amíg valamilyen márkás gépet tudok venni számomra megfelelő áron. Az se baj, ha ibm:)

nem az IBM adta a legjobb konfigot.

markas gep lett, csak markas gep volt a versenyben. Ez a rendszer meg nincs az ibm (hp, sgi, bull, fujitsu, *) tesztlaborban, legfeljebb 1 darab az elemi alkotoreszekbol. Ha meg "addig kavarok, amig be nem mutatjak nekem a rendszert pre-sales allapotban" akkor nem 44 CN van, hanem max 15. Komoly.

( handler | 2010. 01. 02., szo – 18:03 )

Data Parallel Excel fog futni rajta :) Egyebkent lehet tudni, mifele masinak kerultek a clusterbe?

Hátbazmeg, ide először azt akartam írni, hogy hülye egy vicc, de (nem tudok rá értelmes magyarázatot adni, hogy miért) rákerestem, és tessék:

http://www.microsoft.com/hpc/en/us/excel.aspx

kész... ilyenkor rosszul érzem magam. Eszembe jut a PzKpfw V, a Me-262, a DEC Alpha, az SGI Tezro, meg más csodás dolgok, és ilyenkor rossz azzal szembesülni, hogy az evolúció nem vezet globális optimumra.