több szerver egyben

Linux-haladó

Kérdésem: meglehet oldani, hogy több gép (jelen esetben 4 alaplap 2x2cpu) 1 gépnek látszodjék (1x16cpu vagy 1x1cpu). Akár úgy, hogy 1 virtuális gépet futtatna az egészen.

  • 2422 megtekintés

( wpeople v | 2010. 07. 07., sze – 15:18 )

Nem hinném - bár van olyan (erősen párhuzamosítható) feladat ahol a műveleteket SMP-hez hasonlóan el tudod osztani.
Azért lássuk be, elég komoly feladat elé állítanád a schedulert, hiszen mekkora az a feladat, amit már érdemes áttolni
a másik gépre az elég szűkös összeköttetésen.

10Gigabites linkek esetén 1.2GB/s a sebesség - ezt már a p3 is meghaladta - mostmár erősen 8-10GB/s környékén járunk általános esetekben
is (v felette). Nem is beszélve a késleltetésről...

ma már megfordult a trend, nem sok kicsi computert raknak egybe, egy erős clusterré mint pár éve,
hanem egyre inkább a sokmagossá dagadt computereket "szeletelik fel" több virtuális gép között.
de van kész megoldás a problémára.
jópár éve nagy divat volt az Openmosix. a fejlesztése abbamaradt, de egy forkja folytatja az fejlesztését, ez az LinuxPMI Project.
érdemes megnézni, de inkább az OpenSSI projectet ajánlom. disztribúció szinten a Debianhoz van jónak mondható támogatás.

( nemka | 2010. 07. 07., sze – 15:24 )

Talán a cluster operációs rendszerek állnak az elképzelésedhez a legközelebb, de még ezek sem elég közel.

( klacus76 | 2010. 07. 07., sze – 15:47 )

Én ezért vettem 6 magos gépet.

Az újabb AMD-k ára megfizethetők, illetve olcsóbb mint a négy darab 2 magos, üzemeltetni is.
ezt vettem pont ma a magok száma miatt:
http://products.amd.com/en-us/DesktopCPUDetail.aspx?id=641&f1=&f2=&f3=&…

valamint mert olcsó hozzá a deszka is.

Nekem több Op rendszert kell virtualizálni vele. majdnem tökéletes.....

Egyébként olvasgass bele ide:
http://en.wikipedia.org/wiki/Xen

( bambano | 2010. 07. 07., sze – 16:13 )

meg, ha azok az alaplapok ibm eseries x3950-ben vannak.

Ahogy skálázódni tud egy 4 magos procin :>
Mondjuk inkább HPC-re való mint LAMP-re de akár még KVM el virtualizálni is lehet vele, ha eljutok odáig ki is próbálom majd, főleg a process migráció érdekelne. Ugye sima processzekkel működik a node-ok között, de azért KVM processz lehet más :>

Ubuntu 10.04, Thinkpad x60s

( csilee | 2010. 07. 07., sze – 16:17 )

Na igen a clustert meg a cloudot már nézegettem

Ne darabszamra nezd oket. Megfelelo feladat eseten a 14 (megfelelo) GPU siman lekorozi az 56 CPUdat.
De ehhez elemezni kell a feladatot, megnezni, mennyire lehet parhuzamosan futtatni, mennyi elagazas van bennuk, illetve hogy hanyszor es mennyi adatot kell a GPU device-ba tolteni.

Specifikald a feladatot (akar maganban is).

szerk: a bladek belso felepiteset nem ismerem, de valoszinuleg kisteljesitmenyu GPU-ik vannak.

igen a programot mi írjuk
vagyis pár éve megírtuk a nagyját és mindig egy kicsi lett hozzá toldva, a probléma ebből is adódik
biztos lehetne sokkal gyorsabb ha elölről kezdenénk

Akkor két eset van:

- a programot úgy írtátok meg, hogy két-három-több független gépen egymás mellett futtatva külön segítség nélkül is jól fut, azt az eredményt produkálja, amit szeretnétek -> ebben az esetben semmi teendő, felrakjátok, oszt kész,

- a programot nem így írtátok meg -> ebben az esetben tessék újraírni, immáron erre is figyelve, és akkor legközelebb nem fogtok így szopni.

Gy.k.: nincs olyan általános megoldás, amely több számítógépen úgy fut, hogy azokon egyetlen, meglevő, mezei, külön tudomány nélküli program számára tudna olyan környezetet biztosítani, hogy az az egyetlen program a több számítógép erőforrásait együttesen tudja kihasználni.

Az ugye nem segítene rajtatok, ha hiába futna a sok gépen együtt a programotok, de így is max. a legerősebb egyetlen gép tudásának a 80-90%-át tudnátok használni?

"Gy.k.: nincs olyan általános megoldás, amely több számítógépen úgy fut, hogy azokon egyetlen, meglevő, mezei, külön tudomány nélküli program számára tudna olyan környezetet biztosítani, hogy az az egyetlen program a több számítógép erőforrásait együttesen tudja kihasználni."

Ezzel maximálisan egyetértek.

Én is programozok, de amikor a rendszerem olyan állapotba kerül, hogy már nem tartható, akkor bizony újra kell tervezni.

A nagyok se véletlenül szervezik relatív önálló modulokba a programjaikat. Ha a progi elég nagy, akkor könnyedén elszabadul a káosz.

Általában elég csak az mysql_query részeket újra írni illetve megnézni, hogy jó helyen vannak-e az indexek.
Megjegyzem ez nem a Vasi hibája, hanem az, hogy menet közben látszik, hogy melyik tábla mennyire töltődik fel és, hogy hová kellene még/vagy tenni indexet.
Sokszor a tábla kapcsolatok és a lekérdezésben szereplő mezők sorrendjét elég felcserélni és máris villámgyors lesz a rendszer.

Meg kell nézni, hogy mi az amit gyakran használnak a userek. A statikus adatokat (lezárt évek) pedig cron-ból kellene menteni statikus táblába, hogy ne terhelje feleslegesen a szervert a realtime lekérdezés.

Ezek csak tippek, hogy mik lehetnek azok amire anno a Vasi nem gondolt.

( csortu v | 2010. 07. 09., p – 08:33 )

A sima (tehát nem az open fork) Mosix miért nem jó? Nálunk az fut a százvalahány node-os clusterünkön. Igaz, ez itt akadémiai környezet, tehát nekünk ingyenes a licensz.
Csaba

én az openmosix korában próbáltam utoljára. akkor még szó sem volt erről. természetesen multithreadesnek kellett lennie a programnak, hogy az egyes processeket tudja dobálni a cluster tagjai között. a mencoder például nem látta sok hasznát, legfeljebb akkor, ha más erőforrásigényes alkalmazások is mentek fele párhuzamosan.
az OpenPMI tudtommal a teljes OpenMosix kódot forkolta és azt a kódbázist fejleszti tovább a mai napig, és nem írták át alapjaiban az egészet. azt már nem használtam, de meglepne ha ilyen változás történt volna.

( ang | 2010. 07. 09., p – 15:10 )

http://kerrighed.org/

Kerrighed is a Single System Image operating system for clusters. Kerrighed offers the view of a unique SMP machine on top of a cluster of standard PCs.

Current Features
Global Process Management

* Cluster wide PIDs
* Process migration with open files, pipes, sockets, shared memory segments, etc.
* Mosix-like global process scheduler.
* Full cluster wide UNIX process management interface (ps, top, kill, etc).
* Customizable distributed scheduler

Global Memory Management

* Support for distributed system V memory segments.
* Memory injection (EXPERIMENTAL)

Checkpoint / restart

* Checkpoint/restart of single processes
* Checkpoint/restart of applications (EXPERIMENTAL)

Architecture

* Support of SMP / multi-cores machines
* Support for x86_64 architecture (support for i386 is currently broken).

Retrieved from "http://kerrighed.org/wiki/index.php/Status"