Worker arhitektura

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.

Spura je 4. sep 2017 ob 13:25 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.).

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.

Mavrik je 4. sep 2017 ob 17:16 izjavil:

pegasus je 4. sep 2017 ob 17:14 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