Több processzoros rendszer építése lépésről lépésre.
Hozzászólások
[quote:0902114887="tille"]Egy nem pont ebbe a témába vágó kérdésem lenne (de lehet hogy belefér :D): A nagy hálózati terhelésű gépekbe mindenki Intel / 3com karit ajánl.
- Mi a véleményetek az SMC karikról? Ezek nem jók?
- Vagy ha jók, akkor miért nem írja senki az Intel / 3com után?
inkább csak a 3Com vagy Cisco kártyát ajánlom... Az ok pedig egyszerű:
- nézd meg milyen erőforrást használ egy egy SMC / Realtek kártya és milyet a komoly kártyák, meg fogsz lepődni! Ugye egy clusternél pegig nem igazán örülnek, ha processzor nem az elsődleges feladatát végzi az ideje igen nagy részében.
- ezek mellett stabilitás, stabilitás, stabilitás... Ég és föld a két kategória.
Nem olcsók ezek cuccok, de van mire elkérni a több pénzt.
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
Igen, ez a helyzet. Ha Beowulf-ot, vagy egyéb MPI clustert használsz, akkor azt hiszem a futtatott szoftverből kell kihasználni (asszem az MPI szabvány körül kell nézelődni), míg az OpenMosix esetén arra kell figyelni, hogy sokat forkolj és ezt ne pthread-del tedd. Csak külön processz tud másik node-ra költözni, szal ha egy processzel hajtod a halálba a procit, akkor sajna át kell írnod, hogy részszámításokra bontsa a feladatot. Ha viszont az alkalmazásod pthread-eket használ, a segítségedre lehet ez , ami alapján annyi a megoldás, hogy hozzá kell linkelned az FSU-Pthread libet az alkalmazáshoz.
[quote:4c6789bce3="meditor"]Terveim szerint a vezérgép hardvere egy 3.2 GHz P4, 4 GB rammal,
megfelelő tárolókapacitással, és vizuális képességekkel, a másik gép
szintén 3.2 GHz + 4 GB ram. Slackware 10.2 -őt fogok használni, ha
jól tudom van is hozzá 16 gépre optimalizált kernel.
Nem flame-nek szánom, de nem járnál jobban esetleg Athlon64/Opteron-alapú gépekkel? Kevesebb áramot fogyaszt, kevésbé melegszik és a neten sokfelé látható tesztek szerint a médiafeldolgozást kivéve mindenben gyorsabb, mint a P4-ek. Persze ha az algoritmusaid P4-esre vannak kihegyezve, akkor egy szót se szóltam. :)
[quote:78673fa4c6="rigidus"][quote:78673fa4c6="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
Nézd meg a mini-itx-es gép leírását is... a top 106-ik supercomputer rendszergazdája építette, és van néhány nagyon hasznos tanácsa... főleg a rendszer telepítésével kapcsolatban. Van néhány nagyon jó MPI leírás is odalinkelve a végére amiben van egy csomó vektoros / mátrixos példa is egész jó optimalizálásokkal C++, C, Fortran és Lisp példákkal hegyekben...
Ha kell véltelenszámot sokszor generálni a számításokhoz akkor is érdemes megfontolni a mini-itx-et mert a CL266 chipsetben van neki ilyen. Néhány alkalmazásban például oda is ver az akármilyen Pentiumoknak mert kénytelenek a procival generáltatni a viszonylag jó véletlenszámot ami jelentős erőforrást eszik meg... Ha nem kell véletlenszám generálás sok akkor pedig attól függően kéne renszert választani hogy mennyi lebegőpontos vagy egész számon végzett műveletet hajtasz végre. Az egyikben az AMD a másikban az Intel a nyerő. Esetleg meggondolnám még masszív vektorozós dologhoz a PS/2 játékkonzolt clusterben!!!
Ne felejtsd el hogy a a 3 gep vagy 4 sose adja 3 gep egyuttes teljesitemnyet. nagyban elnyeli a node-ok kozti kommunikacio a szamitaskapacitast. erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
[quote:199d235fe7="gipszjakab"]
inkább csak a 3Com vagy Cisco kártyát ajánlom... Az ok pedig egyszerű:
Mostanság IBM HS20 Bladeben láttam Broadcom Ethernet chipet integrálva.
X4200 Sunban pedig két portos Intelből volt kettő darab.
Nagyon fontos szempont, hogy a márkás kártyák egyre több részét a TCP/IP kommunikációnak hardverből valósítják meg, tehermentesítve így a CPU-t.
A fent említett adapterek természetesen mind gigabitesek voltak, így jól jön az a segítség.
Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
[quote:df8391761a="lloyddzilla"]erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Ezt az AMD-s dolgot légyszi' fejtsd ki kicsit bővebben, mert érdekelne, hogy mi a gond vele! Eddig szinte minden tesztben azt láttam (pl. Anandék csináltak emlékeim szerint egy nagyobb linuxos tesztet, MySQL-lel), hogy az Opteronok beépített memóriavezérlője feltörli a padlót a Xeonokkal.
Tényleg nem flame-elni akarok, azért kérdem, mert kíváncsi vagyok. Hátha tudsz valami olyanról, amiről én még nem. :)
[quote:7a76f11e3c="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
[quote:7edad4b9ce="meditor"]
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Szerintem sokkal elegansabb, ha PXE-vel halozaton bootolod be a node-okat. Egyreszt csak egyszer kell a vezergepet beallitani, hogy ezt is megoldja, masreszt utana megsporolod a cd lemez/drive-okat. Tobb node-nal mar ez plane izgalmas. Egyetlen feltetel, hogy olyan halokari kell a node-okba, ami tudja, de pl a sima intel 100-asok tudjak, vagy 3com-ok, gagyibbal meg nem erdemes szorakozni szvsz.
[quote:bcb9fc3124="Skuzzy"][quote:bcb9fc3124="meditor"]
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Szerintem sokkal elegansabb, ha PXE-vel halozaton bootolod be a node-okat. Egyreszt csak egyszer kell a vezergepet beallitani, hogy ezt is megoldja, masreszt utana megsporolod a cd lemez/drive-okat. Tobb node-nal mar ez plane izgalmas. Egyetlen feltetel, hogy olyan halokari kell a node-okba, ami tudja, de pl a sima intel 100-asok tudjak, vagy 3com-ok, gagyibbal meg nem erdemes szorakozni szvsz.
Ezt a kérdést jól körbejártam anno, bootp-t használtam több okból
PXE helyett. A bootp nagyon kellemes volt, csak kissé riasztónak
találtam az epromégetést. (Nem mintha nagy feladat lenne, de mégis.)
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
A flashbőlboot drága. Egy CD olvasó 2 ezer forint és nagyon egyszerű
a boot folyamat megváltoztatása - csak egy CD-t kell megégetni,
ehhez semmi extraberendezés nem kell, ma már rutinfeladat.
Mondjuk a pxe és a boot-p nagy előnye, hogy a rendszeradminisztráció
a vezérgépen megy. De ha a CD-boot csak annyit csinál, hogy IP címet
kér, fölmountol és chroot_saját_könyvtár, akkor ugyanott vagy.
[quote:ac47f71d08="lloyddzilla"]Ne felejtsd el hogy a a 3 gep vagy 4 sose adja 3 gep egyuttes teljesitemnyet. nagyban elnyeli a node-ok kozti kommunikacio a szamitaskapacitast. erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Csak nem a jó öreg OldMan rovatában olvastad?
Megdobhatnál bennünket egy linkkel.
[quote:72442e2f0d="Dwokfur"][quote:72442e2f0d="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
[quote:4ad35d3c0b="Adi"][quote:4ad35d3c0b="lloyddzilla"]erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Ezt az AMD-s dolgot légyszi' fejtsd ki kicsit bővebben, mert érdekelne, hogy mi a gond vele! Eddig szinte minden tesztben azt láttam (pl. Anandék csináltak emlékeim szerint egy nagyobb linuxos tesztet, MySQL-lel), hogy az Opteronok beépített memóriavezérlője feltörli a padlót a Xeonokkal.
Ugyanezt szűrtem le az Anandról. Remélem nem értettük mindketten félre.
Vagy lehet, hogy a Rambus a nyerő? :wink:
Ja, es megfozi a gepet, tobbet fogyaszt mint az intel, inkompatible, eldurrantja a kondenzatort :?
Erdekes modon itt tobb 4,8,12G memoval felpakolt opteron kozul egyik sem fagy. Egyebkent mi az, hogy "Opteronos clusterek gyarilag fagynak"?
[quote:6566138472="meditor"]
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
Nézd meg ezt: http://rom-o-matic.net/
PXE floppy boot-ról (esetleg USB drive, bár azzal nem próbáltam).
[quote:5f744bc80a="lloyddzilla"]es nem amd-t mert annak a memoria kezelese nem megfelelo.
GIGAROTFL! :lol: Ami ittjart nalunk tesztre a cegnel 1.8-as Sun Opteron, az felkezzel verte tonkre a 3 Ghz feletti Xeonjaink, kb. mindenben amit probaltunk. Mikozben nem akarta magat ategetni a padlon. (Ellentetben az Intel szemetekkel.) Mondhatni meggyozott, pedig nem vagyok x86 fan, "mint az kozismert".
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
[quote:01330e45b5="Mac"][quote:01330e45b5="meditor"]
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
Nézd meg ezt: http://rom-o-matic.net/
PXE floppy boot-ról (esetleg USB drive, bár azzal nem próbáltam).
Üdv!
Mac
Ha már floppy, akkor minek pxe/bootp? (Pont az lenne a lényeg, hogy
nem kell forgó alkatrész a rendszer felállásához!) Nos az én
kompromisszumom: bootoljunk CD-ről, ez megbízhatóbb, mint a
floppy, ára elhanyagolható. Ezután etherboot, az adminja egyszerű,
csak a cliens hálókari macadresse kell hozzá a konfigba. Ráadásul
az összes scriptem megvan már hozzá, ami a kliensek felállásához köll.
(Ez is egy szempont)
Az nfs-ről: valóban tud lassú lenni, ha rosszul van beállítva.
[quote:d466b65236="lloyddzilla"]wolphie
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
.
Ertem akkor gyarilag = Sun :)
En meg egyet sem lattam fagyni, igaz egy sem Sun belole.
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
Hozzatennem, hogy a Sun dual opteron cucccal csak SCSI diszkek eseteben garantalja a linux kompatibilitast :-)
Újabb kérdés, kicsit vissza a földre, mert itt olyan magasságok vannak,
hogy beleszédülök.
Szóval:
1. Összeadódik-e a vezérgép és a kliensek memóriája?
2. Milyen arányban legyen a vezérgép és a kliensek
memóriája?
Amint az sejthető a vékonyklienseim nem is lennének olyan vékonyak a
maguk 2-4 Gb ramjával, igaz, egyelőre a vezérgépbe sem lenne több 4
Gb-nél. A vitából annyit leszűrtem, hogy nem tanácsos túllépni
a 32 bites címhatárt (próbához ez is elég).
Yaya probahoz eleg siman. A memorad nem adodik ossze sot, ugye feladatkezelo is korlatokat kap- kezel mert nincs meg az alaplapok kozti minimum 4 gigz/sec. Fizikai korlatokat nem tudod tullepni.
[quote:3ee88a0ee0="lloyddzilla"]Yaya probahoz eleg siman. A memorad nem adodik ossze sot, ugye feladatkezelo is korlatokat kap- kezel mert nincs meg az alaplapok kozti minimum 4 gigz/sec. Fizikai korlatokat nem tudod tullepni.
Tehát akkor: az egyes szálak kiosztótdnak ez egyes kliensekre, és úgy
kell megméretezni a szálat, hogy az a kliensen adott fizikai lehetőségek
mellett az végrehajtódhasson?
A feladatütemező memóriaigénye hogyan kalkulálható?
[quote:4e130b2c58="meditor"][quote:4e130b2c58="rigidus"][quote:4e130b2c58="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
btw: c-be irtad, vagy esetleg lisp/prolog?
Az alkalmazás nagy memóriaigényű lesz 20-30 db százmilliós hosszúságú
vektort és 6-8 ugyanilyen elemszámú mátrixot kell kezelni. A program
színtiszta C.
Ha maximalista vagy, talan trivi es talan mar megoldottak a kovetkezo dolgokat, de az is lehet, hogy talalsz benne hasznalhatot:
a) Alternativ fordito. Tobb fele C forditot icc, sun studio, gcc azon belul eltero verziot erdemes kiprobalni. Eleg nagy elteresek szoktak lenni. Nem feltetlenul a frissebb verzio eredmenyezi a gyorsabb kodot!
b) Fordito optimalizalasa. Forditasi direktivaknal nem szabad kockaztatni a megbizhato uzemen a gyorsabb futasido erdekeben, ez altalaban hamar kibukik ilyen kornyezetben, valamint FONTOS eltavolitani a kizarolag fejlesztes kozben hasznalt direktivakat is, pl debughoz. (Ezt sokan elfelejtik es napokkal-hetekkel esetenkent honapokkal visszavetheti a futasidot) Celszeru tobb hosszabb (min 20-30 perces) benchmarkot csinalni _a celalkalmazas algoritmusait felhasznalva_ tobbfele fordito direktivaval gcc eseten a kovetkezo dokumentacio tanulmanyozasa mellett: http://gcc.gnu.org/onlinedocs
(keresd meg az atalad valasztott verziohoz tartozo cflag doksit)
c) OS. En megprobalnek mas oprendszerek kornyeken is benchmarkolni, lehet, hogy az aktualis celfeladatnal mas OS-ek jobban teljesitenek. btw: ha lehetoseg van ra az OS-t javasolt forrasbol telepiteni es itt is figyelni kell az adott rendszer felepitesere, fordito direktivakra, kernel beallitasara+forditasara. Ha van ra lehetoseg, a kernel utemezojenek a frekvenciajat minel alacsonyabbra kell allitani. Linux eseten erdmes megprobalni 2.4 vs 2.6 verziokat egyarant. Nem biztos, h a 2.6 minden esetben jobban teljesit.
Intel CPU eseten fontos lehet a microcode feltoltese. Sokan szem elol tevesztik, hogy nehany bios ezt nem vegzi el. Ebben az esetben ahhoz, hogy a processzor optimalisan mukodjon mindenkeppen el kell vegezni. Altalaban ez a CPU cache-k mukodese erdekeben fontos tenyezo.
d) A valasztott architektura sajatossagait figyelembe kell venni ugyanugy fejlesztesnel mint az OS beallitasanal. Fejlesztesnel szinte az egyik legfontosabb dolog, hogy az egyes valtozotipusok a kulonbozo architekturakon eltero memoriaigennyel rendelkezhetnek. Sokan meglepodnek, hogy a cel alkalmazas nem ugy fut alternativ architekturan, mint az elvart lenne.
Aztan akadnak egyes valtozotipusok amelyek gond nelkul mukodnek "A" architekturan, viszont egyaltalan nem tamogatottak "B"-n. (Peldanak okaert PPC vs. long long.) Bar ilyenekre a compilerek legtobbszor forditaskor sikitanak. :D
e) Kodoptimalizalas. Ez egy eleg osszetett dolog, igy csak a lenyesgesebbeket emlitem. Kerulni kell a user outputra a gyakori allapotjelzesek kuldeset. Ilyen hosszu futasideju algoritmusnal felesleges masodpercenkent 100x frissiteni, elegendo orankent. Erdemes figyelni, hogy olyan helyzetekre ahol a nyelvnek vannak specifikus operatorai ott azokat kell hasznalni. (Pl a C eseteben: ++i; nem ugyanaz mint i = i + 1; futasidoben, csak a kiertekelesnel ). Ha valtozonak memoriat foglalsz, erdemes meg figyelni a sorendisegre v. a szorvanyosan hasznalt valtozoknal, hogy az adott esetben melyik a koltsegesebb a memoriaban tartani, vagy masodpercenket 2000x ujrafoglaltatni.
[quote:4e130b2c58="meditor"]Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
1-2-3 jol hangzik, 4-esre nem biztos, hogy minden esetben a legjobb valasztas. Klaszterezesnel gyakori I/O muveletekre kell szamitani amelyek lehetnek egeszen valtozatos meretuek. Sok apro I/O muveletnel az nfs szerver rend szerint hamar kidol. Ilyen celteruletekre vannak celspecifikus fajlrendszerek.
Megegy megjegyzes: Valaki irta fentebb, hogy a heterogen kornyezet megengedett. Ez csak bizonyos feltetelek mellett igaz. SSI klasztereknel kifejezetten homogen nativ kod hasznalhato.
Köszi rigidus, nagyon fontos dolgokat írtál! Lassan kezd összállni bennem
valami összkép. Az nfs-s megjegyzésed nagyon fontos, ez az igazi érv
az nfs ellen, bár korábban is terítékre került a kérdés.
Az biztos, hogy ismert plattformon (P4) és ismert disztribúcióval (Slack
10.2, 2.4.31) fogok indulni, még, ha nem is optimális, de nem akarok az
elején azon filózni, hogy az adott jelenség a rendszerismeret hiányából,
vagy az alapfeladatból vezethető le.
[quote:74061f3fc9="meditor"]1. Összeadódik-e a vezérgép és a kliensek memóriája?
1. Logikailag igen, fizikailag viszont nem. Nem egyetlen egysegkent viselkedik, tekintettel arra, hogy az egyes memoria tartomanyok mas-mas node-okon vannak, mas-mas CPU-k fennhatosaga alatt ill. van kozottuk egy halozat is ahol a savszelesseg altalaban kisebb mint a gazdagepen lokalis eleres eseten.
[quote:74061f3fc9="meditor"]2. Milyen arányban legyen a vezérgép és a kliensek
memóriája?
Erre nem lehet konkret aranyszammal felelni, szvsz ennek neked kell utanaszamolnod. Fugg a celfeladattol, fugg attol, hogy milyen tipusu klaszterezest hasznalsz SSI/Beowulf, architektura is lehet befolyasolo tenyezo. Meg meg kismillo dolog.
Azért én mindenképp kitartanék a PXE ( vagy egy kozponti hattértárról történó bootolás) melett, egyrészt a image-ek jobban karbantarthatók, nem kell új CD-ket égetni minden apró módosítás miatt. Nincs mechanikus alkatrész a kliensekbe, ebből következően, kevesebbet fogyaszt, ritkábban kell karbantartani és további dolgok maradhatnak ki a kernelből. A halózati eszközökön ilyen esetben úgysem érdemes spórolni, meg kell venni a sok egyforma 3Com-ot, vagy mást amivel nem kell bajlódni utólag.
Szvsz a sw rész a legkritikusabb, azon múlik minden, hogy sikerül-e úgy megfelelően atalakítani a kódot.
Ezenkívül biztos talalsz a linux-hoz kernelpatch-eket, amik a cluster működtetéséhez hasznosak.
Én még nem csináltam ilyet, de izgalmas érdekes feladatnak gondolom. Sok sikert. :)
[quote:2cd311536b="Bodri"]Azért én mindenképp kitartanék a PXE ( vagy egy kozponti hattértárról történó bootolás) melett, egyrészt a image-ek jobban karbantarthatók, nem kell új CD-ket égetni minden apró módosítás miatt. Nincs mechanikus alkatrész a kliensekbe, ebből következően, kevesebbet fogyaszt, ritkábban kell karbantartani és további dolgok maradhatnak ki a kernelből. A halózati eszközökön ilyen esetben úgysem érdemes spórolni, meg kell venni a sok egyforma 3Com-ot, vagy mást amivel nem kell bajlódni utólag.
Szvsz a sw rész a legkritikusabb, azon múlik minden, hogy sikerül-e úgy megfelelően atalakítani a kódot.
Ezenkívül biztos talalsz a linux-hoz kernelpatch-eket, amik a cluster működtetéséhez hasznosak.
Én még nem csináltam ilyet, de izgalmas érdekes feladatnak gondolom. Sok sikert. :)
Köszi a biztatást. CD lesz, és bootp, eldöntöttem. Az ok: az elején
minél kevesebb ismeretlent akarok vinni a rendszerbe. Az elvi működést
akarom demonstrálni, csak ezután jöhet szóba a tuning.
[quote:02e247879f="meditor"]Jól látom-e hogy a Beowulf egy elég kiforrot dolog?
Kicsi fogalomzavarba kerultunk. :)
A Beowulf nem egy szoftver, hanem egy klasztertipus, valojaban egy technologia, ugyanugy mint az SSI. Mindketto kiforrott technologia, az alkalmazott szoftver minosege az mar mas kerdes.
(Elegge sietek, de megprobalom roviden leirni mindkettot)
Az SSI (Single System Image) rovid lenyege, hogy a klasztert egyetlen nagy tobbproceszoros gepkent latod es igy is kezeli transzparensen. Itt a migralasat a klaszterezeshez valasztott szoftver (pl Mosix, Openmosix, OpenSSI, stb) vegzi el ugyanugy, mint a koltseg-megterules szamitast is mindezt megelozoen. Tehat megirsz egy alkalmazast amely tobbprocesszoros kornyezetet tamogat, annelkul, hogy figyelembe kellene venned az egymastol halozat altal szeparalt eroforrasokat (processzorokat/memoriat/stb). Ez forditva is igaz, ha fogsz egy alkalmazast amely tamogat SMP-t, minden gond nelkul mukodesre lehet birni a klaszteren anelkul, hogy modositani kellene a program mukodeset. (Pl: egy Apache, PostgreSQL vigan szalad rajta) Alt. nagy forgalmu szervereknel, uzleti alkalmazasoknal hasznalatos.
A Beowulf klaszterezes lenyege gyokeresen mas. Valojaban tudomanyos celokra ezt hasznaljak. Itt neked kell gondoskodni a socket kezelesrol, neked kell definialnod a migralas szabalyait, neked kell felosztani az egyes node-ok feladatkoret, neked kell meghatarozni azt is, hogy a feldolgozas mely szakaszait mely node-ok vegezzek, termeszetesen mindezt a meglevo programkod elegge alapos atirasaval. Csak nagy vonalakban: Gondoskodni kell arrol, hogy mindig minden node elfoglalt legyen, ne legyen felesleges halozati forgalom, torekedni kell az eltero architekturak sajatossagaira. Elonye, hogy a legjobb teljesitmenyt csak ezzel lehet erni, mivel az egyes node-okat akar egyenkent is programozhatod. Alt. internetes keresomotoroknal (pl: google), tudomanyos szamitasokra (pl: Earth Simulator), filmgyartas (pl: ILM), hadiiparnal alkalmazzak.
[quote:20a32c85de="rigidus"][quote:20a32c85de="meditor"]Jól látom-e hogy a Beowulf egy elég kiforrot dolog?
Kicsi fogalomzavarba kerultunk. :)
A Beowulf nem egy szoftver, hanem egy klasztertipus, valojaban egy technologia, ugyanugy mint az SSI. Mindketto kiforrott technologia, az alkalmazott szoftver minosege az mar mas kerdes.
(Elegge sietek, de megprobalom roviden leirni mindkettot)
Az SSI (Single System Image) rovid lenyege, hogy a klasztert egyetlen nagy tobbproceszoros gepkent latod es igy is kezeli transzparensen. Itt a migralasat a klaszterezeshez valasztott szoftver (pl Mosix, Openmosix, OpenSSI, stb) vegzi el ugyanugy, mint a koltseg-megterules szamitast is mindezt megelozoen. Tehat megirsz egy alkalmazast amely tobbprocesszoros kornyezetet tamogat, annelkul, hogy figyelembe kellene venned az egymastol halozat altal szeparalt eroforrasokat (processzorokat/memoriat/stb). Ez forditva is igaz, ha fogsz egy alkalmazast amely tamogat SMP-t, minden gond nelkul mukodesre lehet birni a klaszteren anelkul, hogy modositani kellene a program mukodeset. (Pl: egy Apache, PostgreSQL vigan szalad rajta) Alt. nagy forgalmu szervereknel, uzleti alkalmazasoknal hasznalatos.
A Beowulf klaszterezes lenyege gyokeresen mas. Valojaban tudomanyos celokra ezt hasznaljak. Itt neked kell gondoskodni a socket kezelesrol, neked kell definialnod a migralas szabalyait, neked kell felosztani az egyes node-ok feladatkoret, neked kell meghatarozni azt is, hogy a feldolgozas mely szakaszait mely node-ok vegezzek, termeszetesen mindezt a meglevo programkod elegge alapos atirasaval. Csak nagy vonalakban: Gondoskodni kell arrol, hogy mindig minden node elfoglalt legyen, ne legyen felesleges halozati forgalom, torekedni kell az eltero architekturak sajatossagaira. Elonye, hogy a legjobb teljesitmenyt csak ezzel lehet erni, mivel az egyes node-okat akar egyenkent is programozhatod. Alt. internetes keresomotoroknal (pl: google), tudomanyos szamitasokra (pl: Earth Simulator), filmgyartas (pl: ILM), hadiiparnal alkalmazzak.
Nagyon jó! Akkor nekem beowulf - max 2-3 alkalmazást fogok futtatni,
ezek minden programsora kézben van. A feladat súlypontja tehát a
SAJÁT programok teljes átírására tevődik át - ez kell nekem!
Mégegyszer köszönöm mindenkinek az észrevételeket és a tanácsokat,
remélem hamarosan konkrét lépéseket is tehetek! Addig is: irodalmazás
és eszmecsere (-::
Nagyon jó! Akkor nekem beowulf - max 2-3 alkalmazást fogok futtatni,
ezek minden programsora kézben van. A feladat súlypontja tehát a
SAJÁT programok teljes átírására tevődik át - ez kell nekem!
Orulok a kezdeti sikerelmenynek, de arra keszulj, hogy az elejen nagy szivas lesz. :D
Mégegyszer köszönöm mindenkinek az észrevételeket és a tanácsokat,
remélem hamarosan konkrét lépéseket is tehetek! Addig is: irodalmazás
és eszmecsere (-::
Sok sikert kivanok hozza es feltetlenul szamolj be nekunk a fejlemenyekrol. Tudod, mas focimeccsen szeret szurkolni, en meg klaszter tuningolason. :D :D
HPC clustert csak es kizarolag (na jo:az esetek 99.99%-aban), MPI konyvtarral hasznaljak. Az OpenMosix egy ennel fapadosabb (bar ketsegtelelnul egyszeru) megoldas, raadasul a processzek koltoztetese olyan koltseg, ami egy nagyteljesitmenyu szamitas eseten nehezen felvallalhato, illetve zero segitseget nyujt az alkalmazas fejlesztesehez es a debugolashoz. Kerulendo.
A Grid nem alkalmas nagyteljesitmenyu szamitasokra, mivel termeszetebol fakadoan lazan kapcsolt elemeket tartalmaz (es meg nem is mindig megbizhato). A Grid az eroforras megosztas eszkoze, nem pedig az eroforrasok (pl. CPU) kooperativ jellegu osszekapcsolasara.
Tehat ha valami utos problemad van, akkor az alabbiak a jarhatoak:
1. Ird meg tobbszalura, vegyel ala egy tobutas vasat (pl. dual opteronokat mar nagyon barati aron kapsz).
2. Ha ennel is tobb kell akkor vegyel mondjuk 4 dual Opteront, tedd fel a kedvenc linux v. BSD disztribedet (most nem nyitok hitvitat a melyik a legjobb kerdesbol, indulaskent barmelyik jo), es telepits (fordits) ra LAM/MPI-t (www.lam-mpi.org). Ezutan johet a jofele C v. Fortran programozas. A ket ut kozul ez a nehezebb, de ez a megoldas olcsobban es jobban skalazodik. Persze ha nagyon sok a penz, akkor irany az IBM eCluster, a Sun Fire v12xx ad absurdum SGI Altix v. SGI Origin. Ezek a gepek a megfelelo konyvtarakkal mar eleve telepitve erkeznek.
Andrei
====================================================
[quote:7d05f45a06="Dwokfur"][quote:7d05f45a06="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Nincsenek, sajnos nem tudom sem cáfolni, sem megerősíteni a föntieket.
[quote:488188422a="meditor"]Lehet, hogy meg kell barátkoznom a fortrannal?
IMHO a fortran nem egy rossz valasztas, de C-hez konnyebben lehet segitseget talalni ha elakadsz. En a helyedben elso lepesben maradnek a C-nel, aztan kesobb meglatod, lehet, hogy mas nyelvekben egyszerubben tudod megfogalmazni az algoritmust es/vagy jobb minosegu nativ kodot keszit a fordito.
Köszönöm a hozzászólásokat! Számomra ez új terület, ahogy mondani
szokták iszom a szavaitokat (-::
Az is jó, hogy van egy kis vita - ebből is sokat tanulok. Két dolgot szűrtem
le:
1. töbszálassá kell tennem a jelenleg monolitikus programokat.
2. korántsincs lefutva a hardver meccs. Bár ez utóbbinak nincs akkora
jelentősége, mert egyelőre a fürtözés elvi lehetőségeit szeretném
felderíteni. nyilván másként közelítek majd a dologhoz, ha úgy döntök,
ezen a vonalon megyek tovább, mondjuk 2 tucat géppel.
[quote:7faeeb724c="meditor"]Lehet, hogy meg kell barátkoznom a fortrannal?
Nem biztos... van C-hez is mpi:
#include "mpi.h"
de a forditást is mpi-hez kell csinálni, valamint a clusternek támogatni kell az MPI futtatást a megfeleően előkészített könyvtárakban. A futtatást az mpirun-nal indíthatod ahl specifikálni lehet, hogy hány processt kapjon.
Ha MPI-t szeretnél használni akkor a kommunikáció módjának a kiválasztása (pl broadcast / read-write) igen fontos, valamint a megfelelő MPI adattípusok választása ami != a C típusaival...
Bővebben egy mátrixos / vektoros példa kapcsán C-ben:
ftp://math.usfca.edu/pub/MPI/mpi.guide.ps
Nah bocs hogy nem irtam. Egesz egyszeruen az Amd memoria controllere nem mukodik tokeletesen, sot. 4 gb. memora mar neccesen megy bele, es ha betolsz melle egy nagy tranzakcio igenyu kartyat le is csokken rendesen (akar 2gb/s) Nem olvastam amd-rol rossz cikket, de tapasztalatbol tudom hogy nem megy, a gyarto se tudott vele mit kezdeni, nem szeretnem a nevet leirni, de 3 betus es nem SGI. Semmi bajom az amd-vel csak nincs se alaplap gyartasa, se mobil cpu-ja, se external mem controllere. Legutobbi szukseges komoly rendszer epitesehez, kulonoson ha rendes NUMA (esetleg felxibile HB crossbar) gepet akar az ember. Opeteronos clusterekkel meg sok a baj, intel se nagy durranas az 1 millas Xeonok alatt. Itanium2 meg agyonb4sz.
elsősorban tényleg a szoftver oldalról kell alaposan körüljárni a dolgot.
típusproblémákra /mátrixműveletek avagy nagyméretű nemlineáris illesztések/ készítettek sokféle, kimondottan elosztott elven működő algoritmus könyvtárat. Ezeket profik hegyezték ki, amennyire csak lehetett arra, hogy jól skálázódjanak.
Meg kellene nézni, hogy a ti feladatotok mennyire típusprobléma. Ha igen, jó eséllyel a fő számolást igénylő dolgokat polcról levehető elosztott szoftverrel meg tudjátok oldani /talán ingyenes szoftverekkel, amint az a tudományos világban megszokott/.
Épp most készülök beszerezni egy tyan Thunder K8W (S2885)-at.
Szerinted ez nem tud 4GB-nál több memóriát kezelni, vagy csak valami asztali "szerverre" gondoltál, mikor ezt a az AMD memóriakezelési hibát említetted?
bár asztaliban meg ritkaság a 4g-nél több memóriát tudó.....
[quote:06afdb0d8a="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nem érzed úgy, hogy neked egy adott gyártó rossz szériáját sikerült kifognod? :)
Csak mert érdekes módon én ilyet nem tapasztalok. Pedig van pár opteronos gépünk.
[quote:86821944fe="Dwokfur"][quote:86821944fe="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
[quote:d07b3d54ed="kohinoor"][quote:d07b3d54ed="Dwokfur"][quote:d07b3d54ed="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
Csak úgy kíváncsiságból: megírnád, hogy milyen eszközök ezek pontosan?
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
Tervezem egy több processzoros rendszer kiépítését, de nagyon járatlan
vagyok ebben a kérdéskörben. Itt szeretnék majd segítséget kérni azoktól,
akiknek van némi tapasztalata. Elsőként egyből néhány amatőr kérdés:
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Terveim szerint először egy két gépes rendszert raknék össze. Ez állna
egy vezérgépből, amely a vizualizációt is végzi, illetve egy
vékonykliensből, amely a vezérgépről bootolna föl.
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Minden segítséget előre is köszönök, a rendszer építésének folyamatáról
ebben a topikban folyamatosan be fogok számolni.
[quote:f8f52cd259="meditor"]
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Ha jol eterm, inkabb clustert ertesz a tobbprocesszoros rendszeren, ebben az esetben:
1: igen
2: nem
3: ez nyilvan attol fugg, hogy mit es milyen terhelessel szeretnel futtatni rajta, "jatszashoz" meg par gep eseten valszeg gond nelul
[quote:17d910c770="bra"][quote:17d910c770="Dwokfur"][quote:17d910c770="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
Nalunk egy SUN Fire x4200 (2*Opteron 275 = 4 core), 8 GB RAM volt tesztelesen. Build celra teszteltem, 2 hetig mindenfele forditasi idot mertem, nem tapasztaltam stabilitasi problemat.
Meg tavaly kaptunk egy v40z-t (ha jol emlekszem 16 GB RAM-mal), azzal sem volt semmilyen problemank.
[quote:6f36a9ff11="shogy"][quote:6f36a9ff11="bra"][quote:6f36a9ff11="Dwokfur"][quote:6f36a9ff11="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
Nalunk egy SUN Fire x4200 (2*Opteron 275 = 4 core), 8 GB RAM volt tesztelesen. Build celra teszteltem, 2 hetig mindenfele forditasi idot mertem, nem tapasztaltam stabilitasi problemat.
Meg tavaly kaptunk egy v40z-t (ha jol emlekszem 16 GB RAM-mal), azzal sem volt semmilyen problemank.
shogy
A V20z és a V40z, meg az x széria azért némileg más.
Bővebben :-) :
Három gépből készítettem egyszer, vezérgép volt egy IBM xSeries 200 (PIII 866 MHz, 512 MB RAM) a két node pedig Duron 1.1 GHz, 128 MB RAM PC. 10 Mb-es HUB-al voltak összekötve (az volt kéznél).
ClusterKnoppix-ot használtam, a node-ok a vezérgép CD ROM-járól bootoltak. Ez kicsit lassú volt, de utánna ment szépen.
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Igen. A kovetkezo linken bovebben olvashatsz rola: http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/SMP-HOWTO.pdf
[quote:cc8553063d="meditor"]Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
Ha jol ertem, neked nem "sok egymastol kulonbozo" alkalmazast kell futtatnod, hanem egyetlen celalkalmazasra szeretned hasznalni.
Ez esetben ket lehetseges megoldas javasolt:
1. SSI klaszter.
Elonyei, hogy elvileg barmely SMP alkalmazast kepes futtatni es viszonylag konnyu leprogramozni a hozza megirt alkalmazast. (Itt a csak parhuzamos processek megletere kell ugyelni.)
Hatranya, hogy a rendszer kevesbe skalazhato es viszonylag nagy a futasidobeni veszteseg mas megoldasokkal szemben. Ez annyit tesz, hogy a node-ok novelesevel nem mindig az elvart aranyban novekszik a ossz szamitasi teljesitmeny.
Erre vki javasolta az openmosix-ot fentebb. Szep es jo dolog, de en nem nagyon voltam tole elajulva, meg nagyon kiforratlan. Oszinten megvallva igazan jo SSI-t meg nem lattam.
2. Beowulf klaszter.
A celalkalmazast jol skalazhatoan el lehet kesziteni, ez termeszetesen jo hatassal van a teljesitmenyre is, viszont az utemezot azt a celalkalmazasnal magunknak kell leprogramozni. IMHO igazan jo Beowulf utemezot irni eleg keserves munka, csak akkor erdemes belevagni, ha a befektetett munka kesobb megterul.
AMD vs. Intel flame: Minden CPU mas es mas tulajdonsagokkal rendelkezik es _altalaban_ tudomanyos celokra mas jellegu architekturak a keresettebbek. IMHO egyetlen celalkalmazashoz valo hardver megvalasztasanal az elsodleges szempont, hogy milyen algoritmusokat futtat. Pl.: nagy memoriaigenye van es rengeteg egesszamaos muvelet, de keves lebegopontos, vagy rengeteg lebegopontos muvelet ugyanakkor keves i/o muvelet es memoriahasznalt ill. ezeknek a kombinacioja. Ez mind-mind meghatarozoszerepet jatszik abban, hogy milyen hardvert valasszal.
A halozatot szinten nem art gondosan elkesziteni. Eleg nagy szivas, ha egy 100 napos szimulacio kiertekelese elott 2 nappal behal egy router, halokari, vagy "letaposodik" a kabel ami az utemezohoz megy.
[quote:16b87fe0c8="kohinoor"]Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
Oké, akkor meghívlak az egyetemre egy látogatásra, ott van Sun-os dual opteron 8 GB rammal. Nem fagyott, és nem indult újra. Mondhatnám soha :P
Köszönöm az eddigieket! A fejlesztés nem lesz pillanatreakció, úgyhogy
időként ez a szál el fog süllyedni. Nem azt mondom hogy ennyi az éves
tervem, de úgy számolok, hogy ez az év rá megy kisebb-nagyobb
kihagyások miatt.
Terveim szerint a vezérgép hardvere egy 3.2 GHz P4, 4 GB rammal,
megfelelő tárolókapacitással, és vizuális képességekkel, a másik gép
szintén 3.2 GHz + 4 GB ram. Slackware 10.2 -őt fogok használni, ha
jól tudom van is hozzá 16 gépre optimalizált kernel.
Az egész annyiból valóban játszadozás, hogy egy technológiát akarok
kipróbálni, és ha jól kezelhető, akkor fölbővítem, ahogy erőm és
lehetőségeim engedik.
(A feladat egy hatalmas mátrix kezelése, különféle szempontú
transzformációja lesz, összefüggésben azokkal a kutatási témakkal,
amelyekről az elmúlt egy évben itt a HUP-on is beszámoltam.)
Mégegyszer köszi, a leírtak alapján lehet keresgélni a hardvert.
[quote:d581088e56="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
[quote:5f348e6eff="meditor"]Tervezem egy több processzoros rendszer kiépítését, de nagyon járatlan
vagyok ebben a kérdéskörben. Itt szeretnék majd segítséget kérni azoktól,
akiknek van némi tapasztalata. Elsőként egyből néhány amatőr kérdés:
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Terveim szerint először egy két gépes rendszert raknék össze. Ez állna
egy vezérgépből, amely a vizualizációt is végzi, illetve egy
vékonykliensből, amely a vezérgépről bootolna föl.
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Minden segítséget előre is köszönök, a rendszer építésének folyamatáról
ebben a topikban folyamatosan be fogok számolni.
Üdv: meditor
Hali,
Mi OpenMosix clustert teszteltünk egy duál Xeon szerver és 70 db via c3 800 vékony kliens fürtözésével. Mivel amúgy is vékony kliens környezetben "hajtjuk a usereket", nem okozott gondot az OpenMosix specifikus dolgok bemásolása a /-ként használt nfs share-be. Ez gyönyörűen működött is, de az OpenMosix-nak gondja van a pthread-ekkel, azokat a processzeket, amik ezt használják nem képes másik gépre migrálni. Ugyanez a helyzet a nem green thread Java-val is. Emiatt ez nálunk gyakorlatilag kilőtte a gyorsítás lehetőségét, mivel a tipikusan használt programok jó része (pl. mozilla, ooo) nem migrálódik. Viszont a többi cluster megoldással szemben az a nagy előnye, hogy az alatta futó szoftvereknek azt sem kell tudniuk, hogy fürtön futnak, a userspace felé majdnem teljesen transzparens.
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
[quote:5049f3b7f6="rigidus"][quote:5049f3b7f6="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
btw: c-be irtad, vagy esetleg lisp/prolog?
Az alkalmazás nagy memóriaigényű lesz 20-30 db százmilliós hosszúságú
vektort és 6-8 ugyanilyen elemszámú mátrixot kell kezelni. A program
színtiszta C.
Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
[quote:1b4d0abf0e="lloyddzilla"]Nah bocs hogy nem irtam. Egesz egyszeruen az Amd memoria controllere nem mukodik tokeletesen, sot. 4 gb. memora mar neccesen megy bele, es ha betolsz melle egy nagy tranzakcio igenyu kartyat le is csokken rendesen (akar 2gb/s) Nem olvastam amd-rol rossz cikket, de tapasztalatbol tudom hogy nem megy, a gyarto se tudott vele mit kezdeni, nem szeretnem a nevet leirni, de 3 betus es nem SGI. Semmi bajom az amd-vel csak nincs se alaplap gyartasa, se mobil cpu-ja, se external mem controllere. Legutobbi szukseges komoly rendszer epitesehez, kulonoson ha rendes NUMA (esetleg felxibile HB crossbar) gepet akar az ember. Opeteronos clusterekkel meg sok a baj, intel se nagy durranas az 1 millas Xeonok alatt. Itanium2 meg agyonb4sz.
Mi ez a 4 GB memória már neccesen megy bele téma? Itt hever pár low end gép dual Opteronnal, 4 GB memóriával, de van középkategóriás is, 8-16 GB-tal. A necc maximum ott jött be a képbe, hogy neccszatyorban is hozhatod a modulokat.
[quote:c5e87853e9="meditor"]egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
ez esetben javaslom az algoritmus vizsgalatat is. sot konzultaciot az adott algoritmus kornyeket ismero matematikusok es informatikus oktatok kozott.
ha kicsit sikerul huznod az algoritmusok heteket sporolhatsz:)
Hozzászólások
[quote:0902114887="tille"]Egy nem pont ebbe a témába vágó kérdésem lenne (de lehet hogy belefér :D): A nagy hálózati terhelésű gépekbe mindenki Intel / 3com karit ajánl.
- Mi a véleményetek az SMC karikról? Ezek nem jók?
- Vagy ha jók, akkor miért nem írja senki az Intel / 3com után?
inkább csak a 3Com vagy Cisco kártyát ajánlom... Az ok pedig egyszerű:
- nézd meg milyen erőforrást használ egy egy SMC / Realtek kártya és milyet a komoly kártyák, meg fogsz lepődni! Ugye egy clusternél pegig nem igazán örülnek, ha processzor nem az elsődleges feladatát végzi az ideje igen nagy részében.
- ezek mellett stabilitás, stabilitás, stabilitás... Ég és föld a két kategória.
Nem olcsók ezek cuccok, de van mire elkérni a több pénzt.
[quote:7242bdf455="meditor"]Kedves Blint!
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
Igen, ez a helyzet. Ha Beowulf-ot, vagy egyéb MPI clustert használsz, akkor azt hiszem a futtatott szoftverből kell kihasználni (asszem az MPI szabvány körül kell nézelődni), míg az OpenMosix esetén arra kell figyelni, hogy sokat forkolj és ezt ne pthread-del tedd. Csak külön processz tud másik node-ra költözni, szal ha egy processzel hajtod a halálba a procit, akkor sajna át kell írnod, hogy részszámításokra bontsa a feladatot. Ha viszont az alkalmazásod pthread-eket használ, a segítségedre lehet ez , ami alapján annyi a megoldás, hogy hozzá kell linkelned az FSU-Pthread libet az alkalmazáshoz.
Azt hiszem érdemes elolvasnod ezt...
[quote:4c6789bce3="meditor"]Terveim szerint a vezérgép hardvere egy 3.2 GHz P4, 4 GB rammal,
megfelelő tárolókapacitással, és vizuális képességekkel, a másik gép
szintén 3.2 GHz + 4 GB ram. Slackware 10.2 -őt fogok használni, ha
jól tudom van is hozzá 16 gépre optimalizált kernel.
Nem flame-nek szánom, de nem járnál jobban esetleg Athlon64/Opteron-alapú gépekkel? Kevesebb áramot fogyaszt, kevésbé melegszik és a neten sokfelé látható tesztek szerint a médiafeldolgozást kivéve mindenben gyorsabb, mint a P4-ek. Persze ha az algoritmusaid P4-esre vannak kihegyezve, akkor egy szót se szóltam. :)
Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
Nézd meg a mini-itx-es gép leírását is... a top 106-ik supercomputer rendszergazdája építette, és van néhány nagyon hasznos tanácsa... főleg a rendszer telepítésével kapcsolatban. Van néhány nagyon jó MPI leírás is odalinkelve a végére amiben van egy csomó vektoros / mátrixos példa is egész jó optimalizálásokkal C++, C, Fortran és Lisp példákkal hegyekben...
Ha kell véltelenszámot sokszor generálni a számításokhoz akkor is érdemes megfontolni a mini-itx-et mert a CL266 chipsetben van neki ilyen. Néhány alkalmazásban például oda is ver az akármilyen Pentiumoknak mert kénytelenek a procival generáltatni a viszonylag jó véletlenszámot ami jelentős erőforrást eszik meg... Ha nem kell véletlenszám generálás sok akkor pedig attól függően kéne renszert választani hogy mennyi lebegőpontos vagy egész számon végzett műveletet hajtasz végre. Az egyikben az AMD a másikban az Intel a nyerő. Esetleg meggondolnám még masszív vektorozós dologhoz a PS/2 játékkonzolt clusterben!!!
Köszi! Nem rég töltöttem le (andrej javaslatára) az MPI-t az általad
megadott link is kitér erre. Kezdenek összállni a dolgok (-::
Állítólag a jövő héten már pénz is lesz (lehet kezdeni a hardverbeszerzést),
csak még rá kell bólintatnom a fejlesztési irányra a partnerekkel.
Ne felejtsd el hogy a a 3 gep vagy 4 sose adja 3 gep egyuttes teljesitemnyet. nagyban elnyeli a node-ok kozti kommunikacio a szamitaskapacitast. erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
[quote:199d235fe7="gipszjakab"]
inkább csak a 3Com vagy Cisco kártyát ajánlom... Az ok pedig egyszerű:
Mostanság IBM HS20 Bladeben láttam Broadcom Ethernet chipet integrálva.
X4200 Sunban pedig két portos Intelből volt kettő darab.
Nagyon fontos szempont, hogy a márkás kártyák egyre több részét a TCP/IP kommunikációnak hardverből valósítják meg, tehermentesítve így a CPU-t.
A fent említett adapterek természetesen mind gigabitesek voltak, így jól jön az a segítség.
Mindegy en SGI ala mar nem adom tobbet. lehet hogy opteronos SUN-okkal csak velunk toltak ki, de mar nem erdekel, nem koltseghatekony amugy sem.
Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
[quote:df8391761a="lloyddzilla"]erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Ezt az AMD-s dolgot légyszi' fejtsd ki kicsit bővebben, mert érdekelne, hogy mi a gond vele! Eddig szinte minden tesztben azt láttam (pl. Anandék csináltak emlékeim szerint egy nagyobb linuxos tesztet, MySQL-lel), hogy az Opteronok beépített memóriavezérlője feltörli a padlót a Xeonokkal.
Tényleg nem flame-elni akarok, azért kérdem, mert kíváncsi vagyok. Hátha tudsz valami olyanról, amiről én még nem. :)
[quote:7a76f11e3c="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
En 2 cegnel tapasztaltam ket kulon gyartottol. Lehetnek mas tapasztalatok is. Az egyik ceg 8+ node-os rendszert akart osszepakolni.
[quote:7edad4b9ce="meditor"]
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Szerintem sokkal elegansabb, ha PXE-vel halozaton bootolod be a node-okat. Egyreszt csak egyszer kell a vezergepet beallitani, hogy ezt is megoldja, masreszt utana megsporolod a cd lemez/drive-okat. Tobb node-nal mar ez plane izgalmas. Egyetlen feltetel, hogy olyan halokari kell a node-okba, ami tudja, de pl a sima intel 100-asok tudjak, vagy 3com-ok, gagyibbal meg nem erdemes szorakozni szvsz.
[quote:8d59bf86df="lloyddzilla"]. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Honnan veszed ezt az AMD-s dolgot? Télleg jólenne tudni, mert szerintem nagyon leragadtál a K6-os vagy sima Athlon korszakban.
szerintemez az nfs dolog meg f0sp4csk0las.
[quote:bcb9fc3124="Skuzzy"][quote:bcb9fc3124="meditor"]
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Szerintem sokkal elegansabb, ha PXE-vel halozaton bootolod be a node-okat. Egyreszt csak egyszer kell a vezergepet beallitani, hogy ezt is megoldja, masreszt utana megsporolod a cd lemez/drive-okat. Tobb node-nal mar ez plane izgalmas. Egyetlen feltetel, hogy olyan halokari kell a node-okba, ami tudja, de pl a sima intel 100-asok tudjak, vagy 3com-ok, gagyibbal meg nem erdemes szorakozni szvsz.
Ezt a kérdést jól körbejártam anno, bootp-t használtam több okból
PXE helyett. A bootp nagyon kellemes volt, csak kissé riasztónak
találtam az epromégetést. (Nem mintha nagy feladat lenne, de mégis.)
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
A flashbőlboot drága. Egy CD olvasó 2 ezer forint és nagyon egyszerű
a boot folyamat megváltoztatása - csak egy CD-t kell megégetni,
ehhez semmi extraberendezés nem kell, ma már rutinfeladat.
Mondjuk a pxe és a boot-p nagy előnye, hogy a rendszeradminisztráció
a vezérgépen megy. De ha a CD-boot csak annyit csinál, hogy IP címet
kér, fölmountol és chroot_saját_könyvtár, akkor ugyanott vagy.
[quote:df5c3bdf85="lloyddzilla"]szerintemez az nfs dolog meg f0sp4csk0las.
Miért is?
pl .: lassu
[quote:4750dabd38="lloyddzilla"]pl .: lassu
mihez képest?
csak mert én is haználom, és nincs vele semmi bajom, csúcsra járatja a 100 Mb-es kártyát...
[quote:ac47f71d08="lloyddzilla"]Ne felejtsd el hogy a a 3 gep vagy 4 sose adja 3 gep egyuttes teljesitemnyet. nagyban elnyeli a node-ok kozti kommunikacio a szamitaskapacitast. erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Csak nem a jó öreg OldMan rovatában olvastad?
Megdobhatnál bennünket egy linkkel.
Üdv,
Dw.
[quote:72442e2f0d="Dwokfur"][quote:72442e2f0d="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
[quote:4ad35d3c0b="Adi"][quote:4ad35d3c0b="lloyddzilla"]erdemes egy alaplapra minel tobb CPU-t tolni. es jo alaplapra es nem amd-t mert annak a memoria kezelese nem megfelelo.
Ezt az AMD-s dolgot légyszi' fejtsd ki kicsit bővebben, mert érdekelne, hogy mi a gond vele! Eddig szinte minden tesztben azt láttam (pl. Anandék csináltak emlékeim szerint egy nagyobb linuxos tesztet, MySQL-lel), hogy az Opteronok beépített memóriavezérlője feltörli a padlót a Xeonokkal.
Ugyanezt szűrtem le az Anandról. Remélem nem értettük mindketten félre.
Vagy lehet, hogy a Rambus a nyerő? :wink:
Üdv,
Dw.
[quote:4de6e033a3="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele.
Ja, es megfozi a gepet, tobbet fogyaszt mint az intel, inkompatible, eldurrantja a kondenzatort :?
Erdekes modon itt tobb 4,8,12G memoval felpakolt opteron kozul egyik sem fagy. Egyebkent mi az, hogy "Opteronos clusterek gyarilag fagynak"?
Jaj, már megint felbukkant a semmiből egy "vegyél Intelt, mert az AMD melegszik" :)
[quote:6566138472="meditor"]
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
Nézd meg ezt: http://rom-o-matic.net/
PXE floppy boot-ról (esetleg USB drive, bár azzal nem próbáltam).
Üdv!
Mac
[quote:5f744bc80a="lloyddzilla"]es nem amd-t mert annak a memoria kezelese nem megfelelo.
GIGAROTFL! :lol: Ami ittjart nalunk tesztre a cegnel 1.8-as Sun Opteron, az felkezzel verte tonkre a 3 Ghz feletti Xeonjaink, kb. mindenben amit probaltunk. Mikozben nem akarta magat ategetni a padlon. (Ellentetben az Intel szemetekkel.) Mondhatni meggyozott, pedig nem vagyok x86 fan, "mint az kozismert".
wolphie
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
[quote:01330e45b5="Mac"][quote:01330e45b5="meditor"]
A PXE-vel kapcsolatban ott akadtam el, hogy volt egy heterogén
hálózat, amelyben az egyik BIOS tudta, a másik nem, töltsük le,
flash-seljük meg ... még körülményesebb, mint az eprom égetés.
Nézd meg ezt: http://rom-o-matic.net/
PXE floppy boot-ról (esetleg USB drive, bár azzal nem próbáltam).
Üdv!
Mac
Ha már floppy, akkor minek pxe/bootp? (Pont az lenne a lényeg, hogy
nem kell forgó alkatrész a rendszer felállásához!) Nos az én
kompromisszumom: bootoljunk CD-ről, ez megbízhatóbb, mint a
floppy, ára elhanyagolható. Ezután etherboot, az adminja egyszerű,
csak a cliens hálókari macadresse kell hozzá a konfigba. Ráadásul
az összes scriptem megvan már hozzá, ami a kliensek felállásához köll.
(Ez is egy szempont)
Az nfs-ről: valóban tud lassú lenni, ha rosszul van beállítva.
[quote:d466b65236="lloyddzilla"]wolphie
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
.
Ertem akkor gyarilag = Sun :)
En meg egyet sem lattam fagyni, igaz egy sem Sun belole.
[quote:adc84949c9="lloyddzilla"]wolphie
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
Hozzatennem, hogy a Sun dual opteron cucccal csak SCSI diszkek eseteben garantalja a linux kompatibilitast :-)
Mondjuk Sun-os gepek eleve nem skalazhatoak. cask a node-ok szmat novelheted ami csak koltsegnovelo tenyezo. De azert leirta magat elottem ez a ceg.
Újabb kérdés, kicsit vissza a földre, mert itt olyan magasságok vannak,
hogy beleszédülök.
Szóval:
1. Összeadódik-e a vezérgép és a kliensek memóriája?
2. Milyen arányban legyen a vezérgép és a kliensek
memóriája?
Amint az sejthető a vékonyklienseim nem is lennének olyan vékonyak a
maguk 2-4 Gb ramjával, igaz, egyelőre a vezérgépbe sem lenne több 4
Gb-nél. A vitából annyit leszűrtem, hogy nem tanácsos túllépni
a 32 bites címhatárt (próbához ez is elég).
Yaya probahoz eleg siman. A memorad nem adodik ossze sot, ugye feladatkezelo is korlatokat kap- kezel mert nincs meg az alaplapok kozti minimum 4 gigz/sec. Fizikai korlatokat nem tudod tullepni.
[quote:3ee88a0ee0="lloyddzilla"]Yaya probahoz eleg siman. A memorad nem adodik ossze sot, ugye feladatkezelo is korlatokat kap- kezel mert nincs meg az alaplapok kozti minimum 4 gigz/sec. Fizikai korlatokat nem tudod tullepni.
Tehát akkor: az egyes szálak kiosztótdnak ez egyes kliensekre, és úgy
kell megméretezni a szálat, hogy az a kliensen adott fizikai lehetőségek
mellett az végrehajtódhasson?
A feladatütemező memóriaigénye hogyan kalkulálható?
[quote:4e130b2c58="meditor"][quote:4e130b2c58="rigidus"][quote:4e130b2c58="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
btw: c-be irtad, vagy esetleg lisp/prolog?
Az alkalmazás nagy memóriaigényű lesz 20-30 db százmilliós hosszúságú
vektort és 6-8 ugyanilyen elemszámú mátrixot kell kezelni. A program
színtiszta C.
Ha maximalista vagy, talan trivi es talan mar megoldottak a kovetkezo dolgokat, de az is lehet, hogy talalsz benne hasznalhatot:
a) Alternativ fordito. Tobb fele C forditot icc, sun studio, gcc azon belul eltero verziot erdemes kiprobalni. Eleg nagy elteresek szoktak lenni. Nem feltetlenul a frissebb verzio eredmenyezi a gyorsabb kodot!
b) Fordito optimalizalasa. Forditasi direktivaknal nem szabad kockaztatni a megbizhato uzemen a gyorsabb futasido erdekeben, ez altalaban hamar kibukik ilyen kornyezetben, valamint FONTOS eltavolitani a kizarolag fejlesztes kozben hasznalt direktivakat is, pl debughoz. (Ezt sokan elfelejtik es napokkal-hetekkel esetenkent honapokkal visszavetheti a futasidot) Celszeru tobb hosszabb (min 20-30 perces) benchmarkot csinalni _a celalkalmazas algoritmusait felhasznalva_ tobbfele fordito direktivaval gcc eseten a kovetkezo dokumentacio tanulmanyozasa mellett: http://gcc.gnu.org/onlinedocs
(keresd meg az atalad valasztott verziohoz tartozo cflag doksit)
c) OS. En megprobalnek mas oprendszerek kornyeken is benchmarkolni, lehet, hogy az aktualis celfeladatnal mas OS-ek jobban teljesitenek. btw: ha lehetoseg van ra az OS-t javasolt forrasbol telepiteni es itt is figyelni kell az adott rendszer felepitesere, fordito direktivakra, kernel beallitasara+forditasara. Ha van ra lehetoseg, a kernel utemezojenek a frekvenciajat minel alacsonyabbra kell allitani. Linux eseten erdmes megprobalni 2.4 vs 2.6 verziokat egyarant. Nem biztos, h a 2.6 minden esetben jobban teljesit.
Intel CPU eseten fontos lehet a microcode feltoltese. Sokan szem elol tevesztik, hogy nehany bios ezt nem vegzi el. Ebben az esetben ahhoz, hogy a processzor optimalisan mukodjon mindenkeppen el kell vegezni. Altalaban ez a CPU cache-k mukodese erdekeben fontos tenyezo.
d) A valasztott architektura sajatossagait figyelembe kell venni ugyanugy fejlesztesnel mint az OS beallitasanal. Fejlesztesnel szinte az egyik legfontosabb dolog, hogy az egyes valtozotipusok a kulonbozo architekturakon eltero memoriaigennyel rendelkezhetnek. Sokan meglepodnek, hogy a cel alkalmazas nem ugy fut alternativ architekturan, mint az elvart lenne.
Aztan akadnak egyes valtozotipusok amelyek gond nelkul mukodnek "A" architekturan, viszont egyaltalan nem tamogatottak "B"-n. (Peldanak okaert PPC vs. long long.) Bar ilyenekre a compilerek legtobbszor forditaskor sikitanak. :D
e) Kodoptimalizalas. Ez egy eleg osszetett dolog, igy csak a lenyesgesebbeket emlitem. Kerulni kell a user outputra a gyakori allapotjelzesek kuldeset. Ilyen hosszu futasideju algoritmusnal felesleges masodpercenkent 100x frissiteni, elegendo orankent. Erdemes figyelni, hogy olyan helyzetekre ahol a nyelvnek vannak specifikus operatorai ott azokat kell hasznalni. (Pl a C eseteben: ++i; nem ugyanaz mint i = i + 1; futasidoben, csak a kiertekelesnel ). Ha valtozonak memoriat foglalsz, erdemes meg figyelni a sorendisegre v. a szorvanyosan hasznalt valtozoknal, hogy az adott esetben melyik a koltsegesebb a memoriaban tartani, vagy masodpercenket 2000x ujrafoglaltatni.
[quote:4e130b2c58="meditor"]Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
1-2-3 jol hangzik, 4-esre nem biztos, hogy minden esetben a legjobb valasztas. Klaszterezesnel gyakori I/O muveletekre kell szamitani amelyek lehetnek egeszen valtozatos meretuek. Sok apro I/O muveletnel az nfs szerver rend szerint hamar kidol. Ilyen celteruletekre vannak celspecifikus fajlrendszerek.
Megegy megjegyzes: Valaki irta fentebb, hogy a heterogen kornyezet megengedett. Ez csak bizonyos feltetelek mellett igaz. SSI klasztereknel kifejezetten homogen nativ kod hasznalhato.
Nativ kod mindenhol elonyos szerintem. A taskok meretezese pedig aranyban kell alljon a latency-vel.
Köszi rigidus, nagyon fontos dolgokat írtál! Lassan kezd összállni bennem
valami összkép. Az nfs-s megjegyzésed nagyon fontos, ez az igazi érv
az nfs ellen, bár korábban is terítékre került a kérdés.
Az biztos, hogy ismert plattformon (P4) és ismert disztribúcióval (Slack
10.2, 2.4.31) fogok indulni, még, ha nem is optimális, de nem akarok az
elején azon filózni, hogy az adott jelenség a rendszerismeret hiányából,
vagy az alapfeladatból vezethető le.
[quote:74061f3fc9="meditor"]1. Összeadódik-e a vezérgép és a kliensek memóriája?
1. Logikailag igen, fizikailag viszont nem. Nem egyetlen egysegkent viselkedik, tekintettel arra, hogy az egyes memoria tartomanyok mas-mas node-okon vannak, mas-mas CPU-k fennhatosaga alatt ill. van kozottuk egy halozat is ahol a savszelesseg altalaban kisebb mint a gazdagepen lokalis eleres eseten.
[quote:74061f3fc9="meditor"]2. Milyen arányban legyen a vezérgép és a kliensek
memóriája?
Erre nem lehet konkret aranyszammal felelni, szvsz ennek neked kell utanaszamolnod. Fugg a celfeladattol, fugg attol, hogy milyen tipusu klaszterezest hasznalsz SSI/Beowulf, architektura is lehet befolyasolo tenyezo. Meg meg kismillo dolog.
Jól látom-e hogy a Beowulf egy elég kiforrot dolog?
Azért én mindenképp kitartanék a PXE ( vagy egy kozponti hattértárról történó bootolás) melett, egyrészt a image-ek jobban karbantarthatók, nem kell új CD-ket égetni minden apró módosítás miatt. Nincs mechanikus alkatrész a kliensekbe, ebből következően, kevesebbet fogyaszt, ritkábban kell karbantartani és további dolgok maradhatnak ki a kernelből. A halózati eszközökön ilyen esetben úgysem érdemes spórolni, meg kell venni a sok egyforma 3Com-ot, vagy mást amivel nem kell bajlódni utólag.
Szvsz a sw rész a legkritikusabb, azon múlik minden, hogy sikerül-e úgy megfelelően atalakítani a kódot.
Ezenkívül biztos talalsz a linux-hoz kernelpatch-eket, amik a cluster működtetéséhez hasznosak.
Én még nem csináltam ilyet, de izgalmas érdekes feladatnak gondolom. Sok sikert. :)
[quote:2cd311536b="Bodri"]Azért én mindenképp kitartanék a PXE ( vagy egy kozponti hattértárról történó bootolás) melett, egyrészt a image-ek jobban karbantarthatók, nem kell új CD-ket égetni minden apró módosítás miatt. Nincs mechanikus alkatrész a kliensekbe, ebből következően, kevesebbet fogyaszt, ritkábban kell karbantartani és további dolgok maradhatnak ki a kernelből. A halózati eszközökön ilyen esetben úgysem érdemes spórolni, meg kell venni a sok egyforma 3Com-ot, vagy mást amivel nem kell bajlódni utólag.
Szvsz a sw rész a legkritikusabb, azon múlik minden, hogy sikerül-e úgy megfelelően atalakítani a kódot.
Ezenkívül biztos talalsz a linux-hoz kernelpatch-eket, amik a cluster működtetéséhez hasznosak.
Én még nem csináltam ilyet, de izgalmas érdekes feladatnak gondolom. Sok sikert. :)
Köszi a biztatást. CD lesz, és bootp, eldöntöttem. Az ok: az elején
minél kevesebb ismeretlent akarok vinni a rendszerbe. Az elvi működést
akarom demonstrálni, csak ezután jöhet szóba a tuning.
[quote:02e247879f="meditor"]Jól látom-e hogy a Beowulf egy elég kiforrot dolog?
Kicsi fogalomzavarba kerultunk. :)
A Beowulf nem egy szoftver, hanem egy klasztertipus, valojaban egy technologia, ugyanugy mint az SSI. Mindketto kiforrott technologia, az alkalmazott szoftver minosege az mar mas kerdes.
(Elegge sietek, de megprobalom roviden leirni mindkettot)
Az SSI (Single System Image) rovid lenyege, hogy a klasztert egyetlen nagy tobbproceszoros gepkent latod es igy is kezeli transzparensen. Itt a migralasat a klaszterezeshez valasztott szoftver (pl Mosix, Openmosix, OpenSSI, stb) vegzi el ugyanugy, mint a koltseg-megterules szamitast is mindezt megelozoen. Tehat megirsz egy alkalmazast amely tobbprocesszoros kornyezetet tamogat, annelkul, hogy figyelembe kellene venned az egymastol halozat altal szeparalt eroforrasokat (processzorokat/memoriat/stb). Ez forditva is igaz, ha fogsz egy alkalmazast amely tamogat SMP-t, minden gond nelkul mukodesre lehet birni a klaszteren anelkul, hogy modositani kellene a program mukodeset. (Pl: egy Apache, PostgreSQL vigan szalad rajta) Alt. nagy forgalmu szervereknel, uzleti alkalmazasoknal hasznalatos.
A Beowulf klaszterezes lenyege gyokeresen mas. Valojaban tudomanyos celokra ezt hasznaljak. Itt neked kell gondoskodni a socket kezelesrol, neked kell definialnod a migralas szabalyait, neked kell felosztani az egyes node-ok feladatkoret, neked kell meghatarozni azt is, hogy a feldolgozas mely szakaszait mely node-ok vegezzek, termeszetesen mindezt a meglevo programkod elegge alapos atirasaval. Csak nagy vonalakban: Gondoskodni kell arrol, hogy mindig minden node elfoglalt legyen, ne legyen felesleges halozati forgalom, torekedni kell az eltero architekturak sajatossagaira. Elonye, hogy a legjobb teljesitmenyt csak ezzel lehet erni, mivel az egyes node-okat akar egyenkent is programozhatod. Alt. internetes keresomotoroknal (pl: google), tudomanyos szamitasokra (pl: Earth Simulator), filmgyartas (pl: ILM), hadiiparnal alkalmazzak.
[quote:20a32c85de="rigidus"][quote:20a32c85de="meditor"]Jól látom-e hogy a Beowulf egy elég kiforrot dolog?
Kicsi fogalomzavarba kerultunk. :)
A Beowulf nem egy szoftver, hanem egy klasztertipus, valojaban egy technologia, ugyanugy mint az SSI. Mindketto kiforrott technologia, az alkalmazott szoftver minosege az mar mas kerdes.
(Elegge sietek, de megprobalom roviden leirni mindkettot)
Az SSI (Single System Image) rovid lenyege, hogy a klasztert egyetlen nagy tobbproceszoros gepkent latod es igy is kezeli transzparensen. Itt a migralasat a klaszterezeshez valasztott szoftver (pl Mosix, Openmosix, OpenSSI, stb) vegzi el ugyanugy, mint a koltseg-megterules szamitast is mindezt megelozoen. Tehat megirsz egy alkalmazast amely tobbprocesszoros kornyezetet tamogat, annelkul, hogy figyelembe kellene venned az egymastol halozat altal szeparalt eroforrasokat (processzorokat/memoriat/stb). Ez forditva is igaz, ha fogsz egy alkalmazast amely tamogat SMP-t, minden gond nelkul mukodesre lehet birni a klaszteren anelkul, hogy modositani kellene a program mukodeset. (Pl: egy Apache, PostgreSQL vigan szalad rajta) Alt. nagy forgalmu szervereknel, uzleti alkalmazasoknal hasznalatos.
A Beowulf klaszterezes lenyege gyokeresen mas. Valojaban tudomanyos celokra ezt hasznaljak. Itt neked kell gondoskodni a socket kezelesrol, neked kell definialnod a migralas szabalyait, neked kell felosztani az egyes node-ok feladatkoret, neked kell meghatarozni azt is, hogy a feldolgozas mely szakaszait mely node-ok vegezzek, termeszetesen mindezt a meglevo programkod elegge alapos atirasaval. Csak nagy vonalakban: Gondoskodni kell arrol, hogy mindig minden node elfoglalt legyen, ne legyen felesleges halozati forgalom, torekedni kell az eltero architekturak sajatossagaira. Elonye, hogy a legjobb teljesitmenyt csak ezzel lehet erni, mivel az egyes node-okat akar egyenkent is programozhatod. Alt. internetes keresomotoroknal (pl: google), tudomanyos szamitasokra (pl: Earth Simulator), filmgyartas (pl: ILM), hadiiparnal alkalmazzak.
Nagyon jó! Akkor nekem beowulf - max 2-3 alkalmazást fogok futtatni,
ezek minden programsora kézben van. A feladat súlypontja tehát a
SAJÁT programok teljes átírására tevődik át - ez kell nekem!
Mégegyszer köszönöm mindenkinek az észrevételeket és a tanácsokat,
remélem hamarosan konkrét lépéseket is tehetek! Addig is: irodalmazás
és eszmecsere (-::
Orulok a kezdeti sikerelmenynek, de arra keszulj, hogy az elejen nagy szivas lesz. :D
Sok sikert kivanok hozza es feltetlenul szamolj be nekunk a fejlemenyekrol. Tudod, mas focimeccsen szeret szurkolni, en meg klaszter tuningolason. :D :D
Egy szomszéd topik innen a hupról. Csak azért, hogy együtt legyenek a
dolgok:
http://hup.hu/modules.php?name=Forums&file=viewtopic&t=2524&start=0&postdays=0&postorder=asc&highlight=
A fentiből kiemelném Andrei hozzászólását:
====================================================
Idevago forum:
http://forum.hwsw.hu/index.php?showtopic=23052
HPC clustert csak es kizarolag (na jo:az esetek 99.99%-aban), MPI konyvtarral hasznaljak. Az OpenMosix egy ennel fapadosabb (bar ketsegtelelnul egyszeru) megoldas, raadasul a processzek koltoztetese olyan koltseg, ami egy nagyteljesitmenyu szamitas eseten nehezen felvallalhato, illetve zero segitseget nyujt az alkalmazas fejlesztesehez es a debugolashoz. Kerulendo.
A Grid nem alkalmas nagyteljesitmenyu szamitasokra, mivel termeszetebol fakadoan lazan kapcsolt elemeket tartalmaz (es meg nem is mindig megbizhato). A Grid az eroforras megosztas eszkoze, nem pedig az eroforrasok (pl. CPU) kooperativ jellegu osszekapcsolasara.
Tehat ha valami utos problemad van, akkor az alabbiak a jarhatoak:
1. Ird meg tobbszalura, vegyel ala egy tobutas vasat (pl. dual opteronokat mar nagyon barati aron kapsz).
2. Ha ennel is tobb kell akkor vegyel mondjuk 4 dual Opteront, tedd fel a kedvenc linux v. BSD disztribedet (most nem nyitok hitvitat a melyik a legjobb kerdesbol, indulaskent barmelyik jo), es telepits (fordits) ra LAM/MPI-t (www.lam-mpi.org). Ezutan johet a jofele C v. Fortran programozas. A ket ut kozul ez a nehezebb, de ez a megoldas olcsobban es jobban skalazodik. Persze ha nagyon sok a penz, akkor irany az IBM eCluster, a Sun Fire v12xx ad absurdum SGI Altix v. SGI Origin. Ezek a gepek a megfelelo konyvtarakkal mar eleve telepitve erkeznek.
Andrei
====================================================
[quote:7d05f45a06="Dwokfur"][quote:7d05f45a06="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Nincsenek, sajnos nem tudom sem cáfolni, sem megerősíteni a föntieket.
Nehany link, talan segit.
http://www.cacr.caltech.edu/beowulf/tutorial/building.html
http://www.pingvintelep.hu/content.php?article
Lehet, hogy meg kell barátkoznom a fortrannal?
[quote:beedaa3b22="Dwokfur"]Vagy lehet, hogy a Rambus a nyerő? :wink:
Technológiailag jobb is és előrébb is mutat, mint a DDR-SDRAM megoldások, csak sajnos drága a gyártása, így kiesett az olcsó-pc piacról.
[quote:488188422a="meditor"]Lehet, hogy meg kell barátkoznom a fortrannal?
IMHO a fortran nem egy rossz valasztas, de C-hez konnyebben lehet segitseget talalni ha elakadsz. En a helyedben elso lepesben maradnek a C-nel, aztan kesobb meglatod, lehet, hogy mas nyelvekben egyszerubben tudod megfogalmazni az algoritmust es/vagy jobb minosegu nativ kodot keszit a fordito.
Köszönöm a hozzászólásokat! Számomra ez új terület, ahogy mondani
szokták iszom a szavaitokat (-::
Az is jó, hogy van egy kis vita - ebből is sokat tanulok. Két dolgot szűrtem
le:
1. töbszálassá kell tennem a jelenleg monolitikus programokat.
2. korántsincs lefutva a hardver meccs. Bár ez utóbbinak nincs akkora
jelentősége, mert egyelőre a fürtözés elvi lehetőségeit szeretném
felderíteni. nyilván másként közelítek majd a dologhoz, ha úgy döntök,
ezen a vonalon megyek tovább, mondjuk 2 tucat géppel.
[quote:7faeeb724c="meditor"]Lehet, hogy meg kell barátkoznom a fortrannal?
Nem biztos... van C-hez is mpi:
#include "mpi.h"
de a forditást is mpi-hez kell csinálni, valamint a clusternek támogatni kell az MPI futtatást a megfeleően előkészített könyvtárakban. A futtatást az mpirun-nal indíthatod ahl specifikálni lehet, hogy hány processt kapjon.
Ha MPI-t szeretnél használni akkor a kommunikáció módjának a kiválasztása (pl broadcast / read-write) igen fontos, valamint a megfelelő MPI adattípusok választása ami != a C típusaival...
Bővebben egy mátrixos / vektoros példa kapcsán C-ben:
ftp://math.usfca.edu/pub/MPI/mpi.guide.ps
Egy nem pont ebbe a témába vágó kérdésem lenne (de lehet hogy belefér :D): A nagy hálózati terhelésű gépekbe mindenki Intel / 3com karit ajánl.
- Mi a véleményetek az SMC karikról? Ezek nem jók?
- Vagy ha jók, akkor miért nem írja senki az Intel / 3com után?
Meditor, talaltam neked vmit, talan segit abban, h elindulj:
http://esca.atomki.hu/dlug/gemini/intro.html
Hajrá!!!! Engem is érdekel, hogy mire jutsz... Itt van 1 kis kedvcsináló:
http://www.mini-itx.com/projects/cluster/
szerintem szuper...
Nah bocs hogy nem irtam. Egesz egyszeruen az Amd memoria controllere nem mukodik tokeletesen, sot. 4 gb. memora mar neccesen megy bele, es ha betolsz melle egy nagy tranzakcio igenyu kartyat le is csokken rendesen (akar 2gb/s) Nem olvastam amd-rol rossz cikket, de tapasztalatbol tudom hogy nem megy, a gyarto se tudott vele mit kezdeni, nem szeretnem a nevet leirni, de 3 betus es nem SGI. Semmi bajom az amd-vel csak nincs se alaplap gyartasa, se mobil cpu-ja, se external mem controllere. Legutobbi szukseges komoly rendszer epitesehez, kulonoson ha rendes NUMA (esetleg felxibile HB crossbar) gepet akar az ember. Opeteronos clusterekkel meg sok a baj, intel se nagy durranas az 1 millas Xeonok alatt. Itanium2 meg agyonb4sz.
elsősorban tényleg a szoftver oldalról kell alaposan körüljárni a dolgot.
típusproblémákra /mátrixműveletek avagy nagyméretű nemlineáris illesztések/ készítettek sokféle, kimondottan elosztott elven működő algoritmus könyvtárat. Ezeket profik hegyezték ki, amennyire csak lehetett arra, hogy jól skálázódjanak.
Meg kellene nézni, hogy a ti feladatotok mennyire típusprobléma. Ha igen, jó eséllyel a fő számolást igénylő dolgokat polcról levehető elosztott szoftverrel meg tudjátok oldani /talán ingyenes szoftverekkel, amint az a tudományos világban megszokott/.
Épp most készülök beszerezni egy tyan Thunder K8W (S2885)-at.
Szerinted ez nem tud 4GB-nál több memóriát kezelni, vagy csak valami asztali "szerverre" gondoltál, mikor ezt a az AMD memóriakezelési hibát említetted?
bár asztaliban meg ritkaság a 4g-nél több memóriát tudó.....
BB
[quote:06afdb0d8a="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nem érzed úgy, hogy neked egy adott gyártó rossz szériáját sikerült kifognod? :)
Csak mert érdekes módon én ilyet nem tapasztalok. Pedig van pár opteronos gépünk.
[quote:86821944fe="Dwokfur"][quote:86821944fe="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
[quote:d07b3d54ed="kohinoor"][quote:d07b3d54ed="Dwokfur"][quote:d07b3d54ed="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
Csak úgy kíváncsiságból: megírnád, hogy milyen eszközök ezek pontosan?
[quote:b485032911="lloyddzilla"]wolphie
gyarilag fagy az azt jelenti kiszallitjak es nem jo. se winnel se linuxxal semmivel. szoval.
Utana a Sun-os mernok aztmondja "Ez van" Hozzatennem hogy beszeltem mar szemelyesen olyan Sun-os mernokkel aki sajnalta hogy nam itnaium2-vel dolgozik.
Azonkivul Itanium2 az firstclass cpu, meg az NEC vektor cpu-jai is. cluster sux rendes HPC-t szerintem csak NumaFlex-re erdemes epiteni. vagy sx6bol .
Hadd tippeljek: ultra lowend V20z?
Tervezem egy több processzoros rendszer kiépítését, de nagyon járatlan
vagyok ebben a kérdéskörben. Itt szeretnék majd segítséget kérni azoktól,
akiknek van némi tapasztalata. Elsőként egyből néhány amatőr kérdés:
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Terveim szerint először egy két gépes rendszert raknék össze. Ez állna
egy vezérgépből, amely a vizualizációt is végzi, illetve egy
vékonykliensből, amely a vezérgépről bootolna föl.
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Minden segítséget előre is köszönök, a rendszer építésének folyamatáról
ebben a topikban folyamatosan be fogok számolni.
Üdv: meditor
[quote:f8f52cd259="meditor"]
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Ha jol eterm, inkabb clustert ertesz a tobbprocesszoros rendszeren, ebben az esetben:
1: igen
2: nem
3: ez nyilvan attol fugg, hogy mit es milyen terhelessel szeretnel futtatni rajta, "jatszashoz" meg par gep eseten valszeg gond nelul
4: nem hasznaltam meg ilyet, de miert ne lehetne?
[quote:75f65c1183="lloyddzilla"]se mobil cpu-ja
Akkor a turion az mi? Gondolom a SUN ezért épít 2-4 procis V szériás cuccokat, mert nemgyó.
Ez annyira nem lehet rossz: http://www.sun.com/servers/entry/v40z/specs.jsp
[quote:17d910c770="bra"][quote:17d910c770="Dwokfur"][quote:17d910c770="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
Nalunk egy SUN Fire x4200 (2*Opteron 275 = 4 core), 8 GB RAM volt tesztelesen. Build celra teszteltem, 2 hetig mindenfele forditasi idot mertem, nem tapasztaltam stabilitasi problemat.
Meg tavaly kaptunk egy v40z-t (ha jol emlekszem 16 GB RAM-mal), azzal sem volt semmilyen problemank.
shogy
[quote:6f36a9ff11="shogy"][quote:6f36a9ff11="bra"][quote:6f36a9ff11="Dwokfur"][quote:6f36a9ff11="lloyddzilla"]Opteronos clusterek gyarilag fagynak. 4gigz ramtol felfele. akkor is ha a legjobb ramot veszed. A SUN meg nem erdekel, mert az Intel helyeben en se kotnek uzletet egy olyan gyartoval aki release-kent kiad felkesz termeket es meg csak nem is fizet tobbet a cpu-ert....
Nekem nincsenek 4Gb+ Opteron tapasztalataim, kisfiú vagyok. De úgy vettem ki, mintha bra-nak más tapasztalatai lennének.
Kommentálnád ezt, bra?
Adi: neked vannak 4Gb+ Opteron tapasztalataid?
Üdv,
Dw.
2-8 magos gépekről (mind HP) tudok nyilatkozni, ilyenek vannak nekünk.
A legkisebb DL145-ös (vagy blade-ben BL35-ös), a legnagyobb DL585-ös (blade-ben BL45-ös, ez éppen 4 db. dual core Opteronnal volt).
Memória 1 GB-tól 32 GB-ig. OS: FreeBSD/amd64, Solaris (9 és 10), Linux (Red Hat).
Gyönyörűen mennek, szerintem nagyon korrekt gépek.
Nalunk egy SUN Fire x4200 (2*Opteron 275 = 4 core), 8 GB RAM volt tesztelesen. Build celra teszteltem, 2 hetig mindenfele forditasi idot mertem, nem tapasztaltam stabilitasi problemat.
Meg tavaly kaptunk egy v40z-t (ha jol emlekszem 16 GB RAM-mal), azzal sem volt semmilyen problemank.
shogy
A V20z és a V40z, meg az x széria azért némileg más.
1., Lehet.
2., Nem.
3., Egy darabig
Bővebben :-) :
Három gépből készítettem egyszer, vezérgép volt egy IBM xSeries 200 (PIII 866 MHz, 512 MB RAM) a két node pedig Duron 1.1 GHz, 128 MB RAM PC. 10 Mb-es HUB-al voltak összekötve (az volt kéznél).
ClusterKnoppix-ot használtam, a node-ok a vezérgép CD ROM-járól bootoltak. Ez kicsit lassú volt, de utánna ment szépen.
Sok sikert, érdeklődve várom, hogy mire jutsz!
Üdv!
Mac
[quote:cc8553063d="meditor"]Kedves Blint!
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Igen. A kovetkezo linken bovebben olvashatsz rola: http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/SMP-HOWTO.pdf
[quote:cc8553063d="meditor"]Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
Ha jol ertem, neked nem "sok egymastol kulonbozo" alkalmazast kell futtatnod, hanem egyetlen celalkalmazasra szeretned hasznalni.
Ez esetben ket lehetseges megoldas javasolt:
1. SSI klaszter.
Elonyei, hogy elvileg barmely SMP alkalmazast kepes futtatni es viszonylag konnyu leprogramozni a hozza megirt alkalmazast. (Itt a csak parhuzamos processek megletere kell ugyelni.)
Hatranya, hogy a rendszer kevesbe skalazhato es viszonylag nagy a futasidobeni veszteseg mas megoldasokkal szemben. Ez annyit tesz, hogy a node-ok novelesevel nem mindig az elvart aranyban novekszik a ossz szamitasi teljesitmeny.
Erre vki javasolta az openmosix-ot fentebb. Szep es jo dolog, de en nem nagyon voltam tole elajulva, meg nagyon kiforratlan. Oszinten megvallva igazan jo SSI-t meg nem lattam.
2. Beowulf klaszter.
A celalkalmazast jol skalazhatoan el lehet kesziteni, ez termeszetesen jo hatassal van a teljesitmenyre is, viszont az utemezot azt a celalkalmazasnal magunknak kell leprogramozni. IMHO igazan jo Beowulf utemezot irni eleg keserves munka, csak akkor erdemes belevagni, ha a befektetett munka kesobb megterul.
AMD vs. Intel flame: Minden CPU mas es mas tulajdonsagokkal rendelkezik es _altalaban_ tudomanyos celokra mas jellegu architekturak a keresettebbek. IMHO egyetlen celalkalmazashoz valo hardver megvalasztasanal az elsodleges szempont, hogy milyen algoritmusokat futtat. Pl.: nagy memoriaigenye van es rengeteg egesszamaos muvelet, de keves lebegopontos, vagy rengeteg lebegopontos muvelet ugyanakkor keves i/o muvelet es memoriahasznalt ill. ezeknek a kombinacioja. Ez mind-mind meghatarozoszerepet jatszik abban, hogy milyen hardvert valasszal.
A halozatot szinten nem art gondosan elkesziteni. Eleg nagy szivas, ha egy 100 napos szimulacio kiertekelese elott 2 nappal behal egy router, halokari, vagy "letaposodik" a kabel ami az utemezohoz megy.
[quote:16b87fe0c8="kohinoor"]Nalunk fagynak a dual opteronok 4gb+ rammal. Kulfoldi irodaban sun van, az is fagy. Minden nap :-) Ennek ellenere vesszuk. Tobbet vannak szervizben, mint amennyit mennek. Biztosan jok ezek a cuccok, de en soha eletemben nem talalkoztam normalisan mukodo amd-s geppel, meg a kornyezetemben sem. Ha hozza nem ertesbol adodna a dolog, am legyen, de ha a szerviz es a gyarto sem tud mit tenni, akkor azt tudom mondani, hogy meg mindig nem megbizhato.
Oké, akkor meghívlak az egyetemre egy látogatásra, ott van Sun-os dual opteron 8 GB rammal. Nem fagyott, és nem indult újra. Mondhatnám soha :P
Köszönöm az eddigieket! A fejlesztés nem lesz pillanatreakció, úgyhogy
időként ez a szál el fog süllyedni. Nem azt mondom hogy ennyi az éves
tervem, de úgy számolok, hogy ez az év rá megy kisebb-nagyobb
kihagyások miatt.
Terveim szerint a vezérgép hardvere egy 3.2 GHz P4, 4 GB rammal,
megfelelő tárolókapacitással, és vizuális képességekkel, a másik gép
szintén 3.2 GHz + 4 GB ram. Slackware 10.2 -őt fogok használni, ha
jól tudom van is hozzá 16 gépre optimalizált kernel.
Az egész annyiból valóban játszadozás, hogy egy technológiát akarok
kipróbálni, és ha jól kezelhető, akkor fölbővítem, ahogy erőm és
lehetőségeim engedik.
(A feladat egy hatalmas mátrix kezelése, különféle szempontú
transzformációja lesz, összefüggésben azokkal a kutatási témakkal,
amelyekről az elmúlt egy évben itt a HUP-on is beszámoltam.)
Mégegyszer köszi, a leírtak alapján lehet keresgélni a hardvert.
[quote:d581088e56="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
btw: c-be irtad, vagy esetleg lisp/prolog?
[quote:5f348e6eff="meditor"]Tervezem egy több processzoros rendszer kiépítését, de nagyon járatlan
vagyok ebben a kérdéskörben. Itt szeretnék majd segítséget kérni azoktól,
akiknek van némi tapasztalata. Elsőként egyből néhány amatőr kérdés:
1. Lehet-e ehhez heterogén hardverkörnyezetet használni?
2. Szükséges-e, hogy a fürtbe bevont gépek száma a 2 hatványa
legyen?
3. Elegendő-e egy sima 100 Mb-es hálózat ehhez?
Terveim szerint először egy két gépes rendszert raknék össze. Ez állna
egy vezérgépből, amely a vizualizációt is végzi, illetve egy
vékonykliensből, amely a vezérgépről bootolna föl.
Egy mellékszál: Lehet-e X alól 1920x1200 - as felbontású monitort hajtani.
Minden segítséget előre is köszönök, a rendszer építésének folyamatáról
ebben a topikban folyamatosan be fogok számolni.
Üdv: meditor
Hali,
Mi OpenMosix clustert teszteltünk egy duál Xeon szerver és 70 db via c3 800 vékony kliens fürtözésével. Mivel amúgy is vékony kliens környezetben "hajtjuk a usereket", nem okozott gondot az OpenMosix specifikus dolgok bemásolása a /-ként használt nfs share-be. Ez gyönyörűen működött is, de az OpenMosix-nak gondja van a pthread-ekkel, azokat a processzeket, amik ezt használják nem képes másik gépre migrálni. Ugyanez a helyzet a nem green thread Java-val is. Emiatt ez nálunk gyakorlatilag kilőtte a gyorsítás lehetőségét, mivel a tipikusan használt programok jó része (pl. mozilla, ooo) nem migrálódik. Viszont a többi cluster megoldással szemben az a nagy előnye, hogy az alatta futó szoftvereknek azt sem kell tudniuk, hogy fürtön futnak, a userspace felé majdnem teljesen transzparens.
1. igen
2. nem
3. igen
Kedves Blint!
Ez azt jelenti, hogy annak a programnak a fejlesztése során, amit ebben
a rendszerben futtatni akarsz, figyelemmel kell lenni-e a többprocesszoros
környetetre?
Tulképp egyetlen egy programot akarok futtatni a szokásos
rendszerprogramokon kívül, ennek van nagyon nagy számítási igénye.
Előfordul például, hogy egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
[quote:5049f3b7f6="rigidus"][quote:5049f3b7f6="meditor"]töbszálassá kell tennem a jelenleg monolitikus programokat.
Nem kotelezo multithread-de tenni, ez alt. a celfeladattol fugg, a thread ugysem tudja elhagyni a parent process-t legfokeppen a CPU-t a sajat parent process-e nelkul, igy termeszetesen enelkul nem is migralhato. Viszont mindenkeppen parhuzamosan kell leprogramozni a celalkalmazast es az egyes egysegeket kulon processekbe kell foglalni.
btw: c-be irtad, vagy esetleg lisp/prolog?
Az alkalmazás nagy memóriaigényű lesz 20-30 db százmilliós hosszúságú
vektort és 6-8 ugyanilyen elemszámú mátrixot kell kezelni. A program
színtiszta C.
Azt hiszem a rendszer indítása kezd összeállni a fejembe:
1. Vezérgép indul.
2. kliensek saját CD-ről bootolnak
3. DHCP-vel ip kiosztás
4. nfs-sel mount
Azt is látom, hogy P4-essel kezdem a kísérleteket, nagyon hasznos volt
ebből a szempontból az itt folyó AMD-s diszkurzus.
Köszönöm a linkeket is, át fogom őket tanulmányozni.
[quote:c960c4e0c3="meditor"]Slackware 10.2 -őt fogok használni, ha
jól tudom van is hozzá 16 gépre optimalizált kernel.
Pedig mar ajanlottam volna az Ultra Monkey-t meg az OSCAR-t :(
[quote:1b4d0abf0e="lloyddzilla"]Nah bocs hogy nem irtam. Egesz egyszeruen az Amd memoria controllere nem mukodik tokeletesen, sot. 4 gb. memora mar neccesen megy bele, es ha betolsz melle egy nagy tranzakcio igenyu kartyat le is csokken rendesen (akar 2gb/s) Nem olvastam amd-rol rossz cikket, de tapasztalatbol tudom hogy nem megy, a gyarto se tudott vele mit kezdeni, nem szeretnem a nevet leirni, de 3 betus es nem SGI. Semmi bajom az amd-vel csak nincs se alaplap gyartasa, se mobil cpu-ja, se external mem controllere. Legutobbi szukseges komoly rendszer epitesehez, kulonoson ha rendes NUMA (esetleg felxibile HB crossbar) gepet akar az ember. Opeteronos clusterekkel meg sok a baj, intel se nagy durranas az 1 millas Xeonok alatt. Itanium2 meg agyonb4sz.
Mi ez a 4 GB memória már neccesen megy bele téma? Itt hever pár low end gép dual Opteronnal, 4 GB memóriával, de van középkategóriás is, 8-16 GB-tal. A necc maximum ott jött be a képbe, hogy neccszatyorban is hozhatod a modulokat.
[quote:c5e87853e9="meditor"]egy 3 GHz-s gépen 29 napig fut egy számítás.
Ezt az időt akarjuk a nyers erő alkalmazásával csökkenteni, mert
az egyéb tartalékok elfogytak, illetve várható a számítási igény
2 nagyságrendbeli növekedése.
ez esetben javaslom az algoritmus vizsgalatat is. sot konzultaciot az adott algoritmus kornyeket ismero matematikusok es informatikus oktatok kozott.
ha kicsit sikerul huznod az algoritmusok heteket sporolhatsz:)