Hlavní navigace

Vlákno názorů k článku openMosix - instantní linuxový cluster od Radim - Jsem jeden z těch, co se setkali s...

Článek je starý, nové názory již nelze přidávat.

  • 23. 10. 2003 10:12

    Radim (neregistrovaný)

    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.

  • 23. 10. 2003 10:33

    Jirka (neregistrovaný)

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

  • 23. 10. 2003 14:11

    Lucie (neregistrovaný)

    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()".

  • 23. 10. 2003 11:22

    Ivan (neregistrovaný)

    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

  • 23. 10. 2003 11:33

    Ing. Froid :) (neregistrovaný)

    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.

  • 23. 10. 2003 11:43

    Polish (neregistrovaný)

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

  • 23. 10. 2003 16:06

    Honza (neregistrovaný)

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

  • 24. 10. 2003 9:03

    Froid (neregistrovaný)

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

  • 24. 10. 2003 8:10

    Karel Zak (neregistrovaný)

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

  • 27. 10. 2003 13:02

    moje (neregistrovaný)

    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.

  • 23. 10. 2003 12:50

    Izak (neregistrovaný)

    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 ...)

  • 23. 10. 2003 14:45

    Lucie (neregistrovaný)

    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 :-)

  • 23. 10. 2003 16:28

    Dodo (neregistrovaný)

    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 ...