klaszterféle kellene (nagyobb számítási kapacitás)

Adás - vétel - csere

Sziasztok,

belefutottam egy nagyobb számítási kapacitást igénylő problémába. Előzetes becslések alapján kb. 5-10-15 masszívabb pc-nek megfelelő teljesítmény kellene, de ez még eléggé bizonytalan. Ehhez kellene valami vasat összehozni.

A feladat jellemzői:
- Nagyon jól párhuzamosítható probléma (különböző szélsőértékkereső eljárások) gyakorlatilag ugyanazt a kódot teljesen önállóan lehet futtatni az egyes nodeokon.
- Nincs nagy adatforgalom, ezért sima ethernet elég a nodeok közé.
- Max. 1-2 GB adathalmazon kell dolgozni, ez talán nodeonként lemásolható ha kell.
- A kód nagyrésze elkészíthető 32-bites változókkal, ha ez gyorsít valamit.
- Az előzőek miatt nincs szükség valami kifinomult köztesrétegre, vagy nem tudom mire, amit a klasztereknél szoktak használni, gyakorlatilag egy shellscripttel megoldható a független nodeok együttműködése.

A vassal kapcsoltaban a következők a kérdéseim:
- Úgy általában, hogyan érdemes ilyesminek nekifogni? (pl. komplett konfigok vs. alkatrészek, stb.)
- Az új, sokmagos, 64-bites vasakat mennyire lehet kihasználni a feladat szempontjából?
- Van-e olyan *nix (disztribúció), ami jól kihasználja a feladat szempontjából az újabb vasak képességeit?
- Az utóbbi években egyáltalán nem követtem az kommersz hardverek fejlődését(?), ezért az olyanok, hogy pl. core34dualbrutal meg a társai csak távolról mondanak valamit. Nagyjából milyen irányba kellene elindulni? Régebbi procok között is van, ami ide jó lehet?
- Ha valahogy megoldható, szívesen megspórolnám az egyes nodeok háttértárait, ha megoldható, hogy az említett 1-2 GB adatot viszonylag fájdalommentesen (ne ez legyen a szűk keresztmetszet) elérjék hálózatról. Ennek van realitása?
- Van-e esetleg olyan bevált lap+proc+ram kombináció, aminek jó az ár-érték aránya az ilyen jellegű feladatok szempontjából (tehát érdemes belőle nodeokat építeni)?
- Intel vagy AMD? :)

A feladatra szánt összeg még rugalmas, de jó lenne ha az anyagár megállna néhány100K-nál max. De ha megoldható régebbi cuccokkal is, nem fogok tiltakozni, ha ennél sokkal kevesebbre jön ki. Az ár-érték arány fontos.

Alternatívaként esetleg gépidőbérlés is érdekel, ha van valahol ilyenre lehetőség egyáltalán.

=========================================

További kérdések:

1.:

http://hup.hu/node/48017

Ennek alapján jól értem, hogy, ha megfelelő kernelem van, akkor a többmagos rendszereket úgy tudom kihasználni a párhuzamos végrehajtás szempontjából, hogy több példányban indítom el a számítást az adott nodeon?

Ha ez így van, akkor adott esetben jobb lehet inkább egy sokmagos/sokprocesszoros felépítés gyengébb prockból, mint egy kevesebb, de erősebb processzorokból álló?

2.:

Mindegyik iterációs ciklus azzal jár, hogy végig kell menni egy idősoron. Ezt jelenleg úgy oldottam meg, hogy szekvenciálisan olvasom be egy csv fájlból az adatokat, és mindegyik beolvasást követi egy számítás a beolvasott értékekkel.

Ezt lehetne úgy gyorsítani, hogy először egy nagy tömbbe olvasom be az egész fájlt és utána a tömbön végzek műveleteket? Vagy, ha a fájlt csak egyszer olvasom be, az elején és megoldom valahogy, hogy a későbbi ciklusok is már abból dolgozzanak?

Ezekből milyen következtetéseket lehet levonni a háttértárra, a nodeok közötti kapcsolatra (nagysebességű ethernet?) és a RAM-okra, valamint a processzorok cache-méretére vonatkozóan? Mik lehetnek ezek közül kritikus paraméterek?

  • 1825 megtekintés

( Arbiter | 2010. 02. 16., k – 19:28 )

Olyasmit szeretnél, ami már futott valahol korábban? Akár a modellező szoftver, vagy akár maga a konkrét feladat? Ez segíthetne legalább nagyjából belőni az HW igényeket.

Néhány 100k-ból egy clustert...hát...minden rosszindulat nélkül, komolyan érdekel hogy fogod összehozni...hajrá

EDIT: ha csak egyszer akarod használni, akkor bérelj gépidőt valahol, elég nagy beruházásba akarsz kezdeni, csak akkor vedd meg, ha folyamatosan ki is tudod használni.

- saját kód, szélsőértékkeresés genetikai algoritmussal sokdimenziós paramétertérben, az optimálandó algoritmus pedig idősorokon fut, azok az 1-2 GB adat.

- 5-10 jobb PC, aminek nem kell komplett konfignak lennie, mert csak nodeok. Tehát jó esetben csak lap+proc+ram. Nem gondolom, hogy ez anyagárban sokkal több kellene, hogy legyen.

- Nem csak egyszer kellene, ahogy jelenleg kinéz, kb. 0,5-1,5 évre előre látok feladatokat változó gyakorisággal. A bérlés pedig, ahogy eddig láttam nem feltétlenül triviális, pl. itthon nem tudom, hogy van-e egyáltalán ilyen szolgáltatás. Ha van, az is érdekel, de még túl képlékeny állapotban van ez az egész ahhoz, hogy most döntsem el, hogy melyik megoldás lesz ajobb.

Egy normális desktop quad cpu (szerintem ezzel lesz a legjobb a ft/szumma teljesítmény hányados) 30-40 rugónál indul, egy tolerálható tudású alaplap szerintem egy 20-as, kell bele alsó hangon 4gb ram, ha az adatok kitesznek 1-2gb-ot, ez mondjuk 20-25 rugó, plusz kell minimum egy ház táppal (ezt nem hiszem, hogy 10-15 alatt össze lehetne hozni).
Így szumma kb. egy 100-as nettóban egy gép. Ha kell belőle 5-10, akkor az 500k-1M Ft.
És 10 darab ilyen gép simán megeszik 2-3 kW-ot, ami havonta lakossági áron is van vagy 70-100 ezer Ft villanyszámla (cégesen ennél is több lesz)!

Persze ha az 5-10 PC-t úgy értetted, hogy 5-10 darab 1 procis, 1 core-os PC, akkor az 2-3 db quadcore, és tényleg beleférsz a néhány 100k-ba.

( Nyosigomboc v | 2010. 02. 16., k – 19:38 )

Ha tudsz mutatni valami benchmark kodot, akkor lefuttatom az otthoni gepemen. Ha mast is ra tudsz venni HUP-rol erre, akkor fel tudod merni, hogy a te kodod milyen gepen fut a legjobban.

Fixpontos (egesz), vagy lebegopontos szamitasra van szukseged? Ha az elobbi, az sokat jelent sebessegben. Ha utobbi, akkor meg az is lehet, hogy egy jobb videokartyaval jobban jarsz (CUDA).

Azt is el kell dontened, hogy mennyire vagy hajlando barkacsolni hozza. Tobb alaplap+cpu+mem peldaul meghajthato kozos taprol.

--
If women are so good at multitasking, why can't they have sex and a headache at the same time?

Lebegőpontos, de 32-bites pontosság elég. Barkácsolni hajlandó vagyok, házat is, tápot is, azzal nincs gond.

szerk:

CUDA: ami azt illeti, nagyon ígéretes dolog, de végesek az erőforrásaim, és nem tudom mibe fájna portolni a jelenlegi munkámat CUDA-ra, nem értek hozzá. Ráadásul, valószínűleg azért egy db. abból sem lenne elég, és akkor jön ugye a párhuzamosítás CUDA-ra című dolog, ami még úgy sem hangzik jól, hogy az én esetemben a párhuzamosítás egyszerű. Következő probléma: van-e jó fejlesztőkörnyezet hozzá Linux alá+fordító?
Ezen kívül úgy tudom, hogy a videokártyák általában mátrixműveletek végrehajtásában erősek, ami nálam is van ugyan, de egyáltalán nem domináns. Egy adott ciklusban az a hosszú, amig végigrágja magát az idősoron, emiatt még az is lehet, hogy az idő egy jelentős része az I/O-ra megy el (szekvenciálisan dolgoz fel csv-ket, nem tudom, hogy lehetne-e ezt jobban is), ebben pedig a CUDA sem tudna segíteni.

http://developer.nvidia.com/object/cuda_2_3_downloads.html
Nem hasznaltam meg, de elvileg itt van Linuxos SDK is CUDA-hoz. Kb. 3 hete van ilyen videokartyam, nem futtattam azota atombombaszimulaciot, szoval nem kellett.

Egy gepbe befer akar 3 videokartya is, es egy erosebb fajtan lehet annyi memoria, amibe elvileg befer az adatod. Az, hogy nem texturakat, hanem egyeb adatot tarolsz benne, mas kerdes. Szoval az I/O lehet, hogy nem gond.
A videokartyak tudtommal az olyan lebegopontos muveletek vegrehajtasaban erosek, ahol ki lehet hasznalni a hosszu pipeline-t, mert nincs benne elagazas. Amig nem lehetett normalisan programozni, addig valoban a 4x4-es matrixszorzas volt tipikusan az, amibol erdemes volt epitkezni. A CUDA-val elvileg ez valtozott.

(Szigoruan IMHO, meg tenyleg nem hasznaltam.)

Egyszer azt irod, hogy meg csak erdeklodsz, es nincs jelentosebb mennyisegu kod, maskor meg azt, hogy sok van, es nem tudod portolni.. ehh..

--
If women are so good at multitasking, why can't they have sex and a headache at the same time?

Ehh, ne dühíts fel.

Kódom az van, annyi mint a szemét, sosem írtam, hogy ne volna. A hardver az ami egyelőre kérdéses és "érdeklődök".

Nem dobom ki a CUDA-t mint lehetőséget, de egyelőre semmivel nem látom alátámasztva, hogy nekem az biztos jó lenne. Ráadásul nehezen is tudnám kipróbálni, kis vacak integrált videokártyáim vannak, évek óta nem volt szükségem erősebbre.

"márpedig ha 286-od van és számolni akarsz akkor nem árthat egy math coprocessor, persze lehet várni amíg a 486-ba beépítik de gondolom most akarsz számolni, nem fogja kiváltani a többi rendszert de begyorsít"

ugyanez a cuda-ra is igaz, megvárhatod hogy az intel is beépítse a larabeebe, vagy költhetsz sokszázezret sok pici cpura

nem azt mondom hogy neked A cuda kell mint megoldás, amit eddig írtál egyáltalán nem derül ki hogy mennyire lenne a nálad használható, lehet hogy "realtime" tudnád számolni hónapok helyett, és az is lehet hogy csak nehezen egy pár százaléknyit gyorsítana (amit a belefektetett munkával bőven elveszítesz)

de azt írtad párhuzamosítható, a generikus algoritmusból meg _tippnek_ nem rossz hogy tényleg a cuda (v. opencl) alkalmas lehet rá, ha nem is feltétlen az egészet, kiváltani, akár az algoritmusok jelentős átírásával, a gépek számának csak a felére csökkentésével is megérheti, ehhez csak egy dolog kell, valaki aki otthon van a cuda-ban, neki persze kell egy próbagpu is

ahogy írták nem a mátrixművelet nálad a hátrány, hanem hogy egyszerre csak kicsi adatokkal (1-16KB?) tud dolgozni, de ha ilyen cudabevezetőkkel végeztél akkor a devkit-beli "cuda visual profiler" (cudaprof) meg tudja előre jósolni hogy milyen (algoritmus) paraméterezéssel hogy tud gyorsítani, egész jól el lehet vele állítólag játszani :)

szumma: ha nem is ehhez a projekthez, hanem csak úgy szórakozásból, de lassan megéri barátkozni ha nem is konkrétan a cuda-val hanem a gpgpu(.org)-al :)

"ehhez csak egy dolog kell, valaki aki otthon van a cuda-ban, neki persze kell egy próbagpu is"

Na, ezaz, egyik sincs.

Ráadásul úgy néz ki az eddigi okoskodások alapján, lehet, hogy az I/O adja a szükséges idő egy jelentős részét, ami meg nem tudom, hogy mit jelent GPU vonatkozásban, de úgy sejtem, hogy nem jót.

( Vizibirka | 2010. 02. 16., k – 19:41 )

Szia!

Jelenleg van 10 darab kihasználatlan HP blade-ünk (Intel Xeon [quadCore] [fejből nem tom hány gigahertz], 32GB ram, 2x 2.5" 15K sas disk [ennek sem tudom a méretét fejből]) meg 2 EMC Clariion storage (2x9TB winyókapacitás).

Ha érdekel, akkor keress meg.

Nekem még nem nagyon kellett, de úgy rémlik, hogy az ubuntu szerver változatában van klaszter támogatás.

Ilyet még itt még nem tudok mondani.

Ahhoz, hogy tudjak valamit tudnom kéne, hogy milyen konstrukcióban szeretnéd (vagy mi az a konstrukció ami neked megfelel).
PL: 1 hónapra kell a vas úgy ahogy van. Vagy adjunk 1 hónapnyi gépidőt, de azt te fél év alatt szeretnéd felhasználni (bár ez utóbbit óvatosan mondom).

( Kuvik | 2010. 02. 16., k – 21:02 )

+kérdés:

http://hup.hu/node/48017

Ennek alapján jól értem, hogy, ha megfelelő kernelem van, akkor a többmagos rendszereket úgy tudom kihasználni a párhuzamos végrehajtás szempontjából, hogy több példányban indítom el a számítást az adott nodeon?

Kb. jól érted. Egy sima SMP kernellel simán tudod az n db cpu core-t n példányban futtatott, single-threades alkalmazással fullra járatni. Ha sok az I/O, akkor esetleg többet is lehet futtatni, hogy amikor az egyik vár az I/O-ra, akkor a másik ott álljon, és számolhasson egy kicsit a CPU-n.
Az igazán izgalmas kérdés a cache problémaköre. Ha az alkalmazás értelmesen tudna kb. cache-ből futni (a néhány MB-ban elfér egy ciklus összes adata), akkor lehet, hogy a több példány széttúrja egymás elől a cache-t, és 2 példány együtt nem tud majd annyit se feldolgozni, mintha csak 1 példány futna egyedül.

Cache-el nem tudom mi a helyzet. Úgy néz ki a dolog, hogy egy max 1-2 GB-os idősoron kell szépen végigmenni. Az idősor egy eleme és a rajta végzett műveletek nyilván beférnek a cache-ba, az nem sok, de maga az egész idősor értelemszerűen nem, az esetleg csak a RAM-ba.
Nem tudom, hogy széttúrják-e.

( Jason v | 2010. 02. 16., k – 23:07 )

Szerintem MapReduce-szal megfelelően szét tudnád dobni a dolgot a gépeid között.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( Nyosigomboc v | 2010. 02. 17., sze – 01:56 )

1. Ugy is kihasznalhatod a tobb procit/magot, ha egy peldany fut, de tobb thread-del. Ha mondjuk a csv-d tartalma befer a memoriaba (nyilvan nem stingkent, hanem binarisan), akkor ha az egy globalis valtozon keresztul elerheto, egy peldanyban RAM-ban tartva az osszes thread lathatja egyszerre. (persze ezt a hatast elerheted shared memory-val es tobb process-el is, de nem biztos, hogy azzal jarsz jobban)

2. Ha befer az osszes adatod egyszerre a memoriaba, es emellett a feldolgozasra is marad hely, akkor en ezt valasztanam. Egyszer parse-olod, beolvasod egy tombbe, es onnantol kezdve a lassu hattertartol megszabadultal, minden mehet RAM-bol.

Nekem is lenne kerdesem: mirol szol ez a project? Azon kivul, hogy valami genetikus algoritmust hasznalo optimalizacio?

Valami ceges, uzleti project, vagy sajat kutatas? Ha elobbi, akkor a ceges gepeket estere ossze lehet kotni, akar egy kisvallalkozas irodaja is eleg (kiirni par live cd-t, este bebootolni, reggelre kesz). Meg akkor gondolom mas a keret..
Ha sajat kutatas, akkor a penz resze huzosabb, de konnyebb hozza egyuttmukodot talalni. Egyik evfolyamtarsamnak kellett par eve egy kis gepido letesztelni valami grafelmeleti sejtest (legalabbis asszem azt, nem reszletezte), szoval kapott accot az akkori gepemre..

--
If women are so good at multitasking, why can't they have sex and a headache at the same time?

...
ha ráadásul egyetemi a projekt, akkor egyrészt léteznek akadémiai grid computing erőforrások (pl. a niifi-nél is van), amire lehet pályázni, másrészt ha kb. 5-10 gép 1 évnyi ideje kell, ennyi cpu időt szerintem egy tanszék desktop gépein éjszakai és hétvégi üresjáratokból simán össze lehet szedni, csak meg kell beszélni, hogy ne kapcsolják ki a gépet.

A projekt arról szól, hogy új numerikus módszereket próbálunk fejleszteni bizonyos periodikusságot mutató folyamatok előrejelzésére (pl. bizonyos időjárási paraméterekre, de a módszer viszonylag általános).

Mondjuk, hogy saját kutatás, ami ugyan nem teljsen igaz, de egyelőre nem sok támogatást kaptunk hozzá ezért most mégis inkább ide sorolnám.

miért nem próbálod meg tudományos irányból megközelíteni a dolgot és az egyetemi szféra erőforrásait használni? van az niifnek gridje, meg több helyen is vannak rendesebb cuccok.

itt az a kérdés, hogy a kutatásod/projekted csak gazdasági célt szolgál vagy lehet-e belőle tudományos eredményt kihozni?

"Ugy is kihasznalhatod a tobb procit/magot, ha egy peldany fut, de tobb thread-del. Ha mondjuk a csv-d tartalma befer a memoriaba (nyilvan nem stingkent, hanem binarisan), akkor ha az egy globalis valtozon keresztul elerheto, egy peldanyban RAM-ban tartva az osszes thread lathatja egyszerre."

Ez jól hangzik, de hogyan határozom meg, hogy melyik thread melyik magon fusson? A kernel magától le tudja kezelni?
Praktikusan ez úgy nézne ki, hogy van egy for cikus, ami végigmegy az idősoron, tehát, ha egy processzen belül ezt szeretném többszörözni, akkor egymásután rakom többször ugyanezt. De azt még nem értem, hogy mi biztosítja, hogy magonként fussanak.

"De azt még nem értem, hogy mi biztosítja, hogy magonként fussanak."
Mindegyik threadet dobálja a magok között a rendszer.
Nem tudom, hogy linux-on lehet-e állítani cpu affinitást, windows-on lehet. Ott beállítod, hogy ez a processz ezen a magon fuon, és akkor csak ott fog.
Gyakorlatban szvsz nem nagyon kell evvel foglalkoznod amúgy, ha van egy szabad mag, és egy futásra váró folyamat, akkor ott fuolytatja a futtatást a rendszer.
Elindíthatsz egy processzben több threadet is, de szerintem inkább indíts több processzt, vagy fork()-olj.

( unstar | 2010. 02. 17., sze – 10:20 )

FYI:
http://idea.uab.es/mcreel/ParallelKnoppix/

PelicanHPC is a live CD image that let's you set up a high performance computing cluster in a few minutes. A Pelican cluster allows you to do parallel computing using MPI. You can run Pelican on a single multiple core machine to use all cores to solve a problem, or you can network multiple computers together to make a cluster. The frontend node (either a real computer or a virtual machine) boots from the CD image. The compute nodes boot by PXE, using the frontend node as the server.

( asch v | 2010. 02. 17., sze – 11:52 )

Ha etherneten egyszerre kezd mindenki másolni annak nem lesz annyira jó vége. Én az alapadatok átvitelét sorba időzíteném vagy ha nagyon felkoppansz a teljesítményküszöbre, akkor UDP multicasttal. Persze csak ha ez lesz a szűk keresztmetszet és egéri dolgozni vele.

( verkri | 2010. 02. 17., sze – 12:38 )

Én hasonló témából írtam a diplomámat, nagy gráfokat színeztem saját fejlesztésű evolúciós algoritmussal. Az én megoldásom MATLAB-os volt, de mivel volt kb 70-80 jó nagy gráfom és a számításokat kb 100 különböző paraméterrel külön-külön le kellett futtatni, parallel módon futtattam a kódot egy bash scripttel.

Ami hardverem nekem volt : 25 db 3Ghz Intel Core2Duo, E8400, 4 GB RAM.
Mivel mindegyik CPU dualcore, minden egyes gépen két számítást indítottam, így mindkét mag 100%-on ment.

A magszám/kernel/disztrib bizonytalanságodra az a válaszom, hogy annyi számítást kell indítani, ahány mag van. Ezt lehet külön-külön programhívással, szállal, PVM, MPI, és társai, amely rendszer meg támogatja ( pl MATLAB ) ott is lehet ezzel operálni.

( meditor | 2010. 02. 17., sze – 13:45 )

Mennyi az a sokdimenzió?

> Sol omnibus lucet.

( makonyik V2.0 | 2010. 02. 17., sze – 16:46 )

ha egyetemi a project, akkor nem nehez ... (nem nagyon nehez ...)

egyedul egy scheduler kell hozza ...

- meggyozod a legpotensebb embert a projected fontossagarol
- fogsz valami live distrit
(http://www.knoppix.net/wiki/Cluster_Live_CD)
- ejszakara megszallod az tanszek/barki osszes gepet,
bebutulsz a live-ra, beallitod a mozix-ot, es mar mehet is
a moka ..

nana, hogy nem ilyen egyszeru az egesz, de vsz ez a legeroforras-takarekosabb ...