» »

Worker arhitektura

Worker arhitektura

ragezor ::

Rabim pomoc pri arhitekturi sistema.

Trenutno stanje:
job scheduler z multiprocessing modulom ustvari workerje in jim posilja jobe za izvrsevanje (preko redisa). jobi se potem z rezultati vrnejo nazaj v job schedulerja, kjer se sprocesirajo in zapisejo v bazo.

Zeleno stanje:
job scheduler razposlje jobe workerjem, ki so neodvisni in so lahko tudi na drugem racunalniku. rezultati se potem posljejo spet drugim procesom, kjer se jih sprocesira in zapise v bazo.

Zdaj pa rabim nasvete kako zgraditi tako arhitekturo. Je dobra ideja, da se workerji locijo v svoje projekte ala microservices? Deljena koda med workerji, job schedulerjem, itd. pa se da v knjiznice? Tukaj se bojim, da bo stevilo projektov prevec naraslo in bo zadeva tezko obvladljiva.

Ce imamo N workerjev istega tipa ima vsak worker svoj queue ali en queue in workerji tekmujejo za jobe?
Prednosti vecih queuejov: lazji loadbalancing, lazja implementacija pobiranje statistik workerjev (obremenjenost, katere jobe drzi in kako dolgo jih drzi, ...)
Prednosti enega queuea: ni ti treba registrirati workerjev z job schedulerjem

Sam se nagibam, da imas za N workerjev tudi N queue-jev, bi pa bil vesel opisa vasih izkusenj in kje se skrivajo pasti.

Spura ::

job scheduler razposlje jobe workerjem, ki so neodvisni in so lahko tudi na drugem racunalniku. rezultati se potem posljejo spet drugim procesom, kjer se jih sprocesira in zapise v bazo.


Temu se rece Message Queue. Uzames neki kot je RabbitMQ in si razporedis queues in consumerje.

napsy ::

workerje lahko tudi implementiras s sistemskim select() klicem.
"If you die, you die. But when you live you live. There is no time to waste."

ragezor ::

Spura je izjavil:

job scheduler razposlje jobe workerjem, ki so neodvisni in so lahko tudi na drugem racunalniku. rezultati se potem posljejo spet drugim procesom, kjer se jih sprocesira in zapise v bazo.


Temu se rece Message Queue. Uzames neki kot je RabbitMQ in si razporedis queues in consumerje.


Kaj pridobis ce vzames RabbitMQ? Ker queue imamo trenutno implementiran preko Redisa. JobScheduler si tudi zapomni jobe, ki jih je poslal workerju in worker mu obcasno poslje nazaj seznam jobov, ki jih izvrsuje. Tako detektiramo izgubljene jobe (ce pade worker ali redis npr.).

pegasus ::

Medklic: HPC svet ima to rešeno že 50+ let. Kaj točno vas žene v to, da z reimplementacijami odkrivate toplo vodo?

Mavrik ::

pegasus je izjavil:

Medklic: HPC svet ima to rešeno že 50+ let. Kaj točno vas žene v to, da z reimplementacijami odkrivate toplo vodo?


To da očitno HPC svet tega ne zna dokumentirat in razložit ostalemu svetu. Kaj točno pomeni da ima "rešeno"? Kaj je ta "rešitev"?
The truth is rarely pure and never simple.

Spura ::

ragezor je izjavil:


Kaj pridobis ce vzames RabbitMQ? Ker queue imamo trenutno implementiran preko Redisa.
Pac imas ze implementiran MQ, ne pa da emuliras MQ preko Redisa kot koordinatorske/persist tocke.

ragezor je izjavil:


JobScheduler si tudi zapomni jobe, ki jih je poslal workerju in worker mu obcasno poslje nazaj seznam jobov, ki jih izvrsuje.
Tako detektiramo izgubljene jobe (ce pade worker ali redis npr.).
V MQ sistemu je vse to built in. Trackat jobe je brezveze, ker vsak worker obdeluje natancno en message. Seznam izvrsenih jobov je kar queue sam. Izgubljenih jobov nimas, ker ce crkne MQ potem workerji ne morejo commitat obdelave messagea. Ce crkne worker mu timeouta transakcija in gre to v failed queue. Etc... pac teh raznih resitev je kolikor hoces. Ti pa pac reinventas MQ skozi Redis.

Seveda stvari so drugacne ce tvoji kao jobi ful majhni pa da jih je ful velik.

ragezor ::

Vidis, pri nas workerji vzamejo vec jobov naenkrat in potem asinhrono izvrsujejo tele jobe. Scheduler drzi seznam aktivnih jobov zato, da lahko javi opozorilo, da se job se vedno izvaja in potem ne zgenerira novega joba, ce je en ze v izvajanju. Rabimo pa detektirat izgubljene jobe, da jih odstranimo iz seznama aktivnih in se potem zacnejo generirati spet novi.

Isotropic ::

a ni nekaj podobnega hadoop map reduce?
na hpc mislim da obstaja en program "ganglia", ki je nekaj podobnega, ne spomnim se pa več specifik.

Zgodovina sprememb…

AndrejO ::

Mavrik je izjavil:

pegasus je izjavil:

Medklic: HPC svet ima to rešeno že 50+ let. Kaj točno vas žene v to, da z reimplementacijami odkrivate toplo vodo?


To da očitno HPC svet tega ne zna dokumentirat in razložit ostalemu svetu. Kaj točno pomeni da ima "rešeno"? Kaj je ta "rešitev"?

To, da je "vse rešeno", je morda res prehuda, ampak "queueing theory" (kako se temu reče v slovenščini, nisem prepričan ... "čakalne vrste" se mi zdi preozek termin) je v preteklih letih dala že kar nekaj odgovor na vprašanja, ki se tičejo iskanja optimalnih rešitev za takšne probleme.

Sicer pa odgovor na vprašanje: ena vrsta za N izvajalcev ali pa N vrst za N izvajalcev (če privzamemo, da so prehodi med vrstami možni) bosta skupno razpoložljivo kapaciteto izvajalcev zasedli enako (enak izkoristek sistema). Iz tega izhaja, da bo čas procesiranja v sistemu enak.

Tako teorija. Zato ljudje najpogosteje predlagajo oz. uporabijo eno vrsto za N odjemalcev.

V praksi pa OP ni povedal vseh bistvenih podatkov in mimogrede lahko dobi napačen nasvet, ki bo žrtev ene izmed zmot naivnega distribuiranega procesiranja.

Zato se lahko pri implementaciji izkaže, da ima eno opravilo ("job") toliko podatkov, da prenos od vrste pa do izvajalca traja netrivialno dolgo (pojavi se latenca, ki po velikost postane primerljiva, če ne celo večja od samega izvajanja opravila), z večanjem števila odjemalcev pa marsikdo prepozno (t.j. šele ko pride do prevoja eksponentne krivulje) ugotovi, da pasovna širina na sistemu, kjer se nahaja vrsta, ni neomejena zaradi česar začne čas prenosa naraščati eksponentno glede na količino dela. In takšne "skrite" vrste se lahko pojavijo na vsaki točki v sistemu. Dostop do jedra CPE, dostop do delovnega pomnilnika, dostop trajnega pomnilnika (HDD/SDD), prenos podatkov preko omrežja, ...

Tipičen primer sistema, kjer "ena vrsta" ni primerna, ker je omejena s pasovno širino omrežja, je sistem za obdelav slik, kjer je vsaka slika velika po nekaj 10 MiB ali več.

Potem pa se je potrebno vsesti nazaj in v model vključiti ne samo delavce, ki "procesirajo" podatke, temveč tudi delavce, ki "prepošiljajo" podatke od vrste ali vrst do "procesorjev" in hopa, pa je potrebno na novo razmisliti kaj je bolj celovit opis problema.

HPC je področje, kjer so ti "problemi" vsakodneven pojav že odkar se je nekdo spomnil to kratico. Zato je to tudi področje, ker imajo na to temo največ znanja in največ izkušenj s praktičnimi implementacijami. Težava je samo to, da večina ljudi ne hodi na njihove konference, ne dela na praksi pri njih in si po možnosti še celo misli, da razvoj malo večjega sistema nima ničesar za opraviti z matematiko, ker domet njihovih dosedanjih naročnikov ne preseže kapacitete ene škatle, ki jo lahko sosedov mulec v soboto popoldne sestavi doma v svoji sobi.

/rant

pegasus ::

Andrej, hvala za rant :)
Drži, computing svet se ukvarja s to teorijo že od kar je en "worker" bil computing room, v katerem se je raztezal en računalnik, "jobi" pa userji pred vrati, vsak s svojim stackom luknjanih kartic.
Današnji queueing sistemi na gručah (pbs, slurm, openlava, condor, ...) in schedulerji (maui, moab, ...) implementirajo desetletja dobrih praks. Potencialna razlika od tega, kar išče op, je zgolj to, da so mišljeni za interaktivno uporabo in zato delajo s časovnimi resolucijami, merjenih v desetinah sekund ali celo minutah, op pa verjento išče nekaj pod nivojem sekunde. Kar se da urediti z malce dela. Predvsem pa je teorija popolnoma ista.
RabbitMQ in sorodne rešitve uporabljajo ta pristop, a jih vidim v vlogi reševanja drugačnega problema: admin definira, koliko taskov bo vzporedno izvajal vsak posamezen node in s tem prepreči, da bi nenaden naval povpraševanja preobremenil en node. Poleg tega tak dizajn omogoča elastično širjenje in krčenje kapacitet na določeni funkcionalnosti.

Če se hoče kdo igrat z nečim kar vzpostavi most med tema svetovoma, en naš user razvija python jug.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Supercomputer (cluster)

Oddelek: Pomoč in nasveti
284319 (2994) johnnyyy
»

php/javascript pomoč

Oddelek: Izdelava spletišč
9941 (722) Anrex
»

Nov algoritem za učinkovito izrabo jeder

Oddelek: Novice / Procesorji
2310083 (7220) jype
»

Vprasanje glede koncepta programa [c#]

Oddelek: Programiranje
111894 (1636) _Dormage_
»

[QT/C++] Spreminjanje objektov na glavnem oknu iz QThread-a

Oddelek: Programiranje
7747 (618) c0dehunter

Več podobnih tem