Názory k článku openMosix - instantní linuxový cluster

se u paralelních systémů občas vyskytne, není to až taková vzácnost. Souvisí hlavně s cachováním, které způsobí výrazně nižší režii systému na multitasking. Ale vysvětlit, proč nastal v daném konkrétním případě, to je dost detektivní práce.

V tomto případě je to myslím spíš záležitost time-sharingu. Jedná se o to, že při zpracování většího množství procesů se stejnou prioritou je každému z nich přidělena poměrná část času a jádro pak musí velmi často přeplánovat úlohy a nejen cache, ale i celý stack je nutné uklidit a obnovit. Při sníženém množství procesů klesá režie jádra. Pokud spolu procesy nekomunikují a jsou vlastně na sobě nezávislé a současně nemusí čekat na I/O, pak režie jádra je hlavním faktorem, který ovlivňuje výkon clusteru. Tedy - výkon roste do určité míry superlineárně, následně pak lineárně a posléze logaritmicky podle toho, kdy se snižující režie jádra nodů vyváží či převáží režií clusteru.

Pokud si pamatuji, tak ve skriptech (Paralelní systémy a algoritmy - prof. Tvrdík, FEL ČVUT) se superlineární zrychlení vysvětluje především správným rozdělením problému (některý z procesorů má řešení "na kraji" stavového prostoru).
Mimochodem bych doporučoval si zmiňovaná skripta přečíst všem, co chtějí o teorii paralelních výpočtů něco vědět (i autorům článku, ať nemusí objevovat ameriku).

Rek bych ze tenhle druh zrychleni se projevi jen u problemu, kdy ve stavovem prostoru hledam jedno urcite reseni, coz popisovana uloha zrejme nedela. Ta proste jen pocita prvocisla a forkuje k tomu nove procesy (alespon jestli jsem ji spravne pochopil ;)).

jo veselaa akce a dobre napsaano -)...

Super akce a super počteníčko. Díky

Krásný článek, dík za něj.

Fiha tak az na konci clanku kdyz jsem cetl jmeno materske firmy tak mi zaclo dochazet kdo to asi muze psat :) takze Jesus (Ondreji) - hezka prace :)

celkom pekny clanok ja som si doma rozchodil mosix ale nie open mosix ale len mosix. koho to napadlo zapnut vsetky PC naraz? :)))

To musela byt dobra sranda, pri zapnuti tech padesati masin naraz :-)). U nas v praci staci, kdyz vypnou proud a zapnou ho driv, nez stacim obvolat usery aby si povypinali pocitace a monitory, a muzu jit rovnou nahazovat pojistky :-)). Rikam jim to pokazdy, aby v pripade vypadku proudu ty masiny vypnuli, a pokazdy pak musim ty pojistky nahazovat :-)).

Jinak souhlasim, dobry clanek, takove pekne odlehcene pocteni :-).

Mate nekdo zkusenosti s provozem Javy na nejakem Linuxovem clusteru? Zajimalo by mne, zda se da nejak vyresit multithreading - vytvaret Javovske procesy mi pripada problematicke.

Musíš použít navíc add-on migshm http://mcaserta.com/maask/, ale není to odzkoušený.
Přeji příjemnou zábavu.

openMosix thready nemigruje a ani sa s tym v buducnosti nerata ....

Jsem jeden z těch, co se setkali s clusterem na akad. půdě a pak už nikdy. A když to není zas tak dávno vidím, že už jsem úplně mimo :-)

A proto bych se chtěl zeptat. V článku je:

"Jeho základní podstatou je modifikace jádra Linuxu tak, že nadstavba Mosix přebírá kontrolu nad procesy ve chvíli volání například fork(), což umožňuje využití této technologie bez nutnosti větší úpravy kódu."

Jak ten fork funguje? Jak se na jiný uzel přesune proces? Je nutný sdílený souborový systém?

My jsme používali PVM (jsou to už 3 roky) a tam sdílený souborový systém potřeba nebyl (i když jsme ho měli). Bez něj by stačilo nějak dostat před výpočtem potřebné binárky na každý uzel. Na každém uzlu nemusela být celá aplikace, ale jen ta část, která se tam spouštěla.

A další dotaz je, jestli zde mám možnost nějak ovlivnit, aby se nějaký konkrétní proces spouštěl na konkrétním uzlu. Třeba na nejvýkonějším (nejslabším) uzlu a podobně. U PVM to šlo, ale tam se v programu proces nevytvářel forkem ale PVM API funkcí.
Je sice pěkné, že není nutné upravovat zdrojový text, ale není to omezující?

A jak je to se signály mezi procesy (asi chodí po síti že?) a sdílenou pamětí a třeba synch. semafory? To si vůbec nedokážu představit. U PVM chodily signály (zprávy) po síti (ale opět se posílaly speciélní PVM funkcí). Sdílená paměť a další tam nebyly. Jenomže v normálním programu být můžou. A taky třeba pipe, nebo lokální soket. Opravdu lze na clusteru spustit jakýkoliv program bez úpravy?
To by bylo tak fantastické a perfektní, až se mi to nechce věřit.

To bych se taky rad dovedel, jestli a jak mezi sebou ti testovaci hledaci prvocisel komunikovali. Vypada to, ze ne. Nebo se mylim?

Nemylis, nekomunikovali. Posilali vysledky na standardni vystup, a Mosix zaridil, ze se vratily na "home node", takze se objevovaly na obrazovce jedineho monitoru, ktery tam byl. Bylo pekne videt, jak jsou prehazene, podle toho, od ktereho procesu dorazil vysledek driv.
Jinak by mely fungovat standardni metody pro predavani dat mezi procesy (pipe), jake se pouzivaji pri programovani na jeden pocitac s jednim procesorem. Priznam se ovsem, ze jsem takove low-level veci nikdy nedelala, takze jsem byla rada, ze jsem v tom fofru vubec napsala aspon nejaky "parallel for" cyklus pomoci "fork()".

Nerad bych kecal, ale obavam se, ze kvuli nekterym temto featuram
je nutne "prestehovat" proces zpatky na matersky node.
V dalsich verzich OpenMosixu se planuje integrace s AFS.


Ivan

Proces se jakoby rozdeli na dve casti jedna je stale na tzv. home node a druha migruje. System je transparentni, takze ani neni videt, ze se proces presunul, takze se tvari jako lokalni a tak se s nim da i pracovat (ale da se lehce zjistit, na kterem nodu bezi, treba pomoci OpenMosixView). Sdileny fs samozrejme neni nutny, i kdyz jej openMosix podporuje (MFS-Mosix File System) primo v /mfs/cislo uzlu a da se klasicky primountovat.
To, kde dany proces chcete spoustet se samozrejme ovlivnit da, at uz rict procesu prikazem migrate kam ma migrovat, nebo migraci zakazat. U kazdeho nodu se vygeneruje cislo odpovidajici jeho vypocetnimu vykonu a to lze zmenit, takze i timto muzete ovlivnovat na kterem nodu chcete uprednostnovat spousteni procesu.
OpenMosix zatim samozrejme nepodporuje SharedMemory (kdyz jsem se tim zabyval na jare 03) ale ma vlastni spravu posilani zprav, ale podrobnosti ted z hlavy nevim.
Nejdulezitejsi vsak je, ze nikdo nemuze od clusteru ocekavat narust vykonu u beznych aplikaci. Proste 1 proces urychlit nelze. Jen muzete vykonove narocne procesy presunout jinam. To je podle mne domena OpenMosixu tzv. Load Balancing. Na paralelni vypocty se tolik nehodi. Hlavni zasada je, ze uzivatel musi mit povedomi o clusteru a musi umet jej vyuzit.
Pokud by mel nekdo zajem, letos jsem promoval a tema me diplomky byly clustery na Linuxu, kde se hodne zabyvam OpenMosixem tak ji muzu nekomu poslat. Mel jsem ji vystavenou na Webu ale stranku mi nedavno zrusili.

Ahoj, hod mi to na tuhle adresu xpolish@seznam.cz . Jestli budes chtit muzu ti to vystavit na webu

:o) to je sice pekny, ale lepsi by bylo, kdybys rekl adresu, kam to umistis... dik

Diplomku jsem umistil na openmosix.wz.cz je to v pdf a ma 4.7 MB, tak pozor.

Pokud je to v nejakem pozivatelnem formatu, tak co treba na docs.linux.cz? vice zakkr@zf.jcu.cz

Mosix samozrejme umi shared memory. zrejme doslo ke zmateni pojmu sdilena pamet jako prostredek IPC a sdileni pameti ze vsech uzlu jako jedna velka RAM.
Shared Memory je prostredek IPC a to mosix samozrejme umi.

prosim prosim, seeeem!
info@howtolinux.info

Procesy migruje automaticky, a pres utilitu mu muzes rict (mosrun ??) jestli je to uloha na I/O , CPU nebo mixovana, na jakem nodu se spusti atd.

Migraci provadi automaticky podle vytizeni nodu. Ta automatika je tak promakana, ze napr. kdyz jsem spoustel utilitu na testovani SMP masin (vice procesorovych) tak to nejdrive bezelo na 1. nodu (mel jsem ruzne vykonne CPU 2x AMD 1,6, 1xPIII 1G a 1x PIII-500) treba zrovna na tom 1G a pak kdyz to vytizilo CPU na plno, tak to dalo na dalsi nejvice vykonny node ... pak PIII bezela na 100% a AMD na 75% ... pak pridal dalsi AMD a zase 2x AMD kazdy na 70% a PIII na 100 ... no a mosix spocital (mozna to tam i na chvili odmigrovalo) ze na ten dalsi to uz migrovat nebude protoze pak by bezel 500MHz na 100% a ostatni relativne k ni. Ne ze by to byla chyba mosixu ze to nebezelo vsude na 100%, ale byla to vlastnost danne aplikace, protoze u SMP musi byt vsechny CPU stejne tak ta aplikace vzdy poslala na vykonnejsi node min instrukci (doufam ze je to srozumitelne).

Jinak samozrejme bezi vsechny nody na 100% a pokud nejaky neni vytizen nemigruje, nebot by to bylo akorat pomalejsi.

MosixFileSytem pouzivat nemusite, ten se hodi akorat pokut danna aplikace neco zapisuje, protoze mokud tam MFS mit nebudete bude zapis provadet vzdy HOME node (proste mosix na Nodu rekne, ze home nod ma zapsat ... vse je samozrejme trnsparentni takze aplikace nema o nicem ani tuseni).
K tem aplikacim, aplikace vsude byt nemusi, protoze on ji taha jen z HOME node na dalsich ji ani NEUMI vyuzit, pokud vam ovsem HOME node spadne, spadne vam i aplikace :-(

Jinak OpenMosix musete pouzit i jako Terminal server, protoze hezky migruje i OpenOffice(U openGL grafu i 1 instance (OO vytvari def. 8procesu)) a pokud si na tomto X-clientovi(šterminal serverš) pusti vice lidi OO + svoje aplikace bude to hezky migrovat a tento servr se bude tvarit jako velice vykonny ... jen nesmi spadnout HOME node.

K tomu HOME node, HOME nod je nod ze ktereho se spusti danna aplikace, takze pokud budete mit 30 nodu a jeden si spusti program na N1 a druhy na N2 a dejme tomu ze aplikace budou migrovat mezi temito nody, tak kdyz spadne N1 vsechny apliace ktere byli spusteny z N1 spadnou, ale aplikace ktera bezi na N2 a zaroven migruje na N1 mez problemu pobezi dal, jen ta cast vypoctu ktera prave bezela na N1 ze provede znovu (treba na N2 nebo N3 ...)

Zacnu od konce.

Ano, na clusteru lze spustit jakykoliv program bez upravy. Ale normalni slusny program bezi cely jako jeden proces, takze maximalne odmigruje na jiny nod vcelku (coz ma vyznam pro nekoho, kdo potrebuje spoustet hodne narocnych navzajem nezavislych programu.) Aby se program rozdelil, musi byt jeho beh rozdelen do dvou ci vice procesu, coz se zaridi napriklad tim fork(). [Rozdeleni do threadu nestaci, protoze thready vyuzivaji sdilenou pamet.] To je ponekud neprakticke, pokud se vase myslenky pohybuji na urovni slozitych algebraickych struktur a nikoliv na urovni ovladani nejakeho operacniho systemu. Proto existuji vselijake nadstavby, ktere maji cely proces usnadnit, ale jeste jsem se k nim nedostala.

Vsechny komunikace mezi procesy by mely probihat stejne hladce, jako v pripade jednoho procesoru.

Sdileny souborovy system potreba neni, my jsme ke vsem pocitacum krome jednoho pristupovali jako k bezdiskovym (ony na nich disky byly, ale na tech diskach byly Windows :-) ). Ale je-li potreba, pouzit se muze.

Upravovat zdrojovy text se nemusi, ale muze. Pro rozumne pouziti asi musi....

Na ostatni dotazy myslim odpovedeli jini :-)

1. Nie je nutny zdielany FS. uzly medzi sebou komunikuju, je to priamo v jadre. Funguje to tak, ze proces ktory ma byt migrovany sa presunie (nie prekopiruje) na novy uzol a kompletne bezi tam. Na starom z neho ostane len info v /proc. Je to super, no ma to jedno nebezpecenstvo. Raz som startol 40 procesov, tie na uzloch naalokovali pamate, spolu cez 6GB a potom som zatavil cluster. Startovaci uzol mal aj so swapom 4GB :(((
2. Ano, je mozne posielat procesy na konkretne uzly a kade tade. prikazy ako mosrun, runon a podobne, samozrejme dalsie ladenia cez mosctl.
3. signaly po sieti. Ziadna pamat sa nezdiela.
4. Existuje aj vlastny mosixovsky FS, no pozro na nho. V jadre 2.4.20 ani 2.4.21 nie je prilis stabilny.
5. Jadro 2.4.22 ma vazny bug ktory sa ale prejavuje len na viacprocesorovych masinach, takze nepouzivat v takom pripade ...

Slo by to pouzit i na louskani RC5 a nebo jsem uplne mimo ?

ono by to slo pouzit na spoustu veci, ale nekdy bys musel upravit ten program, ale to nemusi jit vzdycky:)
moznost paralelniho zpracovani ulohy se meri velicinou zvanou granualita ulohy, a existuji i ulohy, ktere nelze prizpusobit pro paralelni zpracovani, jine vice ci mene lze:)

Zdravim

Samozrejme ze slo, ale spis bych na toto pouzil jinou metodu.

RC5 se desifruje brutalni metodou, takze vezmes 000001, zahashujes ho, porovnas s hashem co chces dekryptovat, púak pokracujes pres 000002 az k ffffff.

chapes princip? proste typicky for .. do.

takze vhodne reseni je rozdelit 000001 .. ffffff na vice dilu a katdy node nechat pocitat jen tu mensi cast. proste paralelni vypocet.

vice teorie v poslednim Prielomu: john@home

zdenek

1. Linuxove clustery mimo akademickou pudu: Jenom IBM mela nedavno rocni obrat v prodeji techto clusteru kolem 1 miliardy USD a predpoklada narust. Linuxovych clusteru v komercni sfere jsou spousty, ale firmy se tim nechlubi.

2. Me znama vypocetni centra pouzivaji clustery na bazi Beowulfu, nikoliv Mosixu. Nejvetsi CPU zatez je od uloh, ktere byly jiz davno paralelizovany prostrednictvim MPI (predpoved pocasi, kvantova chemie, ...) a Mosix by pouze zvysoval rezii OS.

3. Cerstve informace bude zanedlouho mozne ziskat napr. na http://www.nsc.liu.se/lcsc/. Workshop prave probiha, po skonceni bude vetsina prezentaci pristupna na webu.

Taky adminuju kolegum cluster obsahujici prozatim
11 procesoru. Uvazoval jsem i o Mosixu, ale
kolegove maji paralelni vypocty psane ze 100% pomoci
MPI, takze Mosix neni potreba.

A kdy bude zase dalsi nejaky podobny pokus, ci podobna action? :-) Fakt zajimave, .....
D. :)

Je to opravdu zajimave a na pocteni, a zvlaste stroje vhodne predevsim pro hry a jine uzivatelske aplikace s tak slabym vykonem a presto pouzite k takovemu ukolu. Skoda jen ze jste nemeli neco rychlejsiho a hlavne jinou architekturu. Vysledky by jiste byly zajimavejsi. Co ale neni muze byt....

pokusal som sa to rozbehat na clusterknopixu, ale stroje sa navzajom nevideli...
Upravil som /etc/openmosix.map tabulku, ale v tom pripade boli okolite stroje vyznaceny v openmosixview cervene. Ale shel isiel vytvorit.
Je niekto, kto napise nejaky ten strucny howto (step by step)
nieco ako:
1. nakonfigurovat sietovku pomocou .....
2. spustit to a potom zas ono
Naozaj by ste ma niekto velmi potesil...

Dobry den,

jde na takovyto cluster (napr. z peti pocitacu) nainstalovat Apache kdyz uz jeden server nestaci? Diky.