Posljednjih godina, vijesti su preplavljene porukama o novom tipu distribuiranih računarskih mreža koje se pojavljuju bukvalno niotkuda, rješavajući (ili bolje rečeno, pokušavajući riješiti) širok spektar problema - čineći grad pametnim, spašavajući svijet od autorskih prava prekršioci ili obrnuto, tajno prenošenje informacija ili resursa, bježanje iz-pod državne kontrole u jednom ili drugom području. Bez obzira na oblast, svi oni imaju niz zajedničkih karakteristika zbog činjenice da su pogon za njihov rast bili algoritmi i tehnike koje su izašle u javnost tokom nedavnog procvata kriptovaluta i srodnih tehnologija. Vjerovatno svaki treći članak o specijaliziranim resursima u to vrijeme imao je u naslovu riječ „blockchain“ – diskusija o novim softverskim rješenjima i ekonomskim modelima je neko vrijeme postala dominantan trend, na čijoj pozadini su ostale oblasti primjene distribuiranih računarskih sistema. potisnut u drugi plan.
Istovremeno, vizionari i profesionalci su uvideli glavnu suštinu fenomena: masovno distribuirano računarstvo, povezano sa izgradnjom mreža od velikog broja različitih i heterogenih učesnika, dostiglo je novi nivo razvoja. Dovoljno je izbaciti hype teme iz glave i pogledati temu s druge strane: sve ove mreže, sastavljene iz ogromnih pulova, koje čine hiljade izolovanih heterogenih učesnika, nisu se pojavile same od sebe. Entuzijasti kripto pokreta uspjeli su riješiti složene probleme sinhronizacije podataka i distribucije resursa i zadataka na nov način, što je omogućilo sastavljanje slične mase opreme i stvaranje novog ekosustava dizajniranog za rješavanje jednog usko fokusiranog problema.
Naravno, to nije zaobišlo timove i zajednice uključene u razvoj besplatnog distribuiranog računarstva, a novi projekti nisu dugo čekali.
Međutim, uprkos značajnom povećanju obima dostupnih informacija o razvoju u oblasti izgradnje mreža i rada sa opremom, kreatori perspektivnih sistema moraće da reše ozbiljne probleme.
Prvi od njih, koliko god to čudno zvučalo, je problem odabira smjera.
Smjer može biti ispravan, ili može dovesti do ćorsokaka - od toga nema izlaza; centralizirane isporuke vidovnjaka IT zajednici još uvijek kasne. Ali izbor se mora napraviti kako ne bi upali u tradicionalnu zamku tima koji zauzima preširoko područje i pokušava od samog početka stvoriti još jedan nespecijalizirani opći distribuirani računarski projekt. Čini se da obim posla i nije toliko zastrašujući, uglavnom samo trebamo primijeniti postojeće razvoje: kombinirati čvorove u mrežu, prilagoditi algoritme za određivanje topologija, razmjenu podataka i praćenje njihove konzistentnosti, uvesti metode za rangiranje čvorova i pronalaženje konsenzus, i, naravno, samo kreirajte svoj jezik upita i čitav jezik i računarsko okruženje. Ideja o univerzalnom mehanizmu je vrlo primamljiva i stalno se pojavljuje u jednom ili drugom području, ali krajnji rezultat je i dalje jedna od tri stvari: stvoreno rješenje ili se ispostavlja kao ograničeni prototip s gomilom suspendiranih "ToDos-a". ” u zaostatku, ili postaje neupotrebljivo čudovište spremno da odvuče svakoga ko dirne u smrdljivu “Turingovu močvaru”, ili jednostavno umire sigurno od činjenice da su labud, rak i štuka, koji su projekt vukli u neshvatljivom smjeru, jednostavno su se prenaprezali.
Nemojmo ponavljati glupe greške i izaberimo pravac koji ima jasan raspon zadataka i koji je dobro prilagođen modelu distribuiranog računarstva. Možete razumjeti ljude koji pokušavaju sve učiniti odjednom - naravno, ima mnogo toga za izabrati. I mnogo toga izgleda izuzetno interesantno kako sa stanovišta istraživanja i razvoja, tako i sa stanovišta ekonomije. Koristeći distribuiranu mrežu možete:
- Obučite neuronske mreže
- Obradi tokove signala
- Izračunajte strukturu proteina
- Renderirajte XNUMXD scene
- Simulirajte hidrodinamiku
- Testirajte strategije trgovanja za berze
Kako se ne bismo zanosili sastavljanjem liste zanimljivih stvari koje su dobro paralelne, za dalju temu ćemo odabrati distribuirano renderiranje.
Sam distributivni render, naravno, nije ništa novo. Postojeći kompleti alata za renderovanje dugo su podržavali distribuciju opterećenja na različitim mašinama; bez toga bi život u dvadeset prvom veku bio prilično tužan. Međutim, ne biste trebali misliti da je tema nadaleko pokrivena i da tu nema šta da se radi - razmotrit ćemo poseban hitan problem: stvaranje alata za kreiranje mreže za renderiranje.
Naša mreža za renderiranje je kombinacija čvorova koji trebaju izvršiti zadatke renderiranja s čvorovima koji imaju slobodne računske resurse za obradu renderiranja. Vlasnici resursa će povezati svoje stanice s mrežom za renderiranje kako bi primili i izvršili poslove renderiranja koristeći jedan od podržanih mehanizama za renderiranje na mreži. U ovom slučaju, provajderi zadataka će raditi sa mrežom kao da je oblak, samostalno distribuirajući resurse, nadgledajući ispravnost izvršenja, upravljajući rizicima i drugim problemima.
Stoga ćemo razmotriti stvaranje okvira koji bi trebao podržati integraciju sa skupom popularnih render engine-a i sadržavati komponente koje pružaju alate za organiziranje mreže heterogenih čvorova i upravljanje protokom zadataka.
Ekonomski model postojanja takve mreže nije od fundamentalne važnosti, pa ćemo kao početnu shemu uzeti shemu sličnu onoj koja se koristi u kalkulacijama u mrežama kriptovaluta - potrošači resursa će slati tokene dobavljačima koji obavljaju poslove renderiranja. Mnogo je interesantnije shvatiti koja svojstva okvir treba da ima, za šta ćemo razmotriti glavni scenario interakcije između učesnika mreže.
Postoje tri strane interakcije u mreži: dobavljač resursa, provajder zadataka i mrežni operater (u tekstu se naziva kontrolni centar, mreža itd.).
Mrežni operater pruža provajderu resursa klijentsku aplikaciju ili sliku operativnog sistema sa postavljenim setom softvera, koji će instalirati na mašinu čije resurse želi da obezbedi, i lični nalog dostupan preko veb interfejsa, što mu omogućava da postavite parametre pristupa resursu i daljinski upravljajte njegovim serverskim pejzažom: kontrolirajte hardverske parametre, izvršite udaljenu konfiguraciju, ponovno pokrenite sistem.
Kada se poveže novi čvor, sistem za upravljanje mrežom analizira opremu i određene pristupne parametre, rangira je, dodeljuje određeni rejting i smešta u registar resursa. U budućnosti, radi upravljanja rizikom, analizirat će se parametri aktivnosti čvora, a rejting čvora će biti prilagođen kako bi se osigurala stabilnost mreže. Niko neće biti zadovoljan ako se njihova scena pošalje na renderiranje na moćne kartice koje se često smrzavaju zbog pregrijavanja?
Korisnik koji treba da renderuje scenu može ići na dva načina: prenijeti scenu u mrežno spremište preko web sučelja ili koristiti dodatak da poveže svoj paket za modeliranje ili instalirani renderer na mrežu. U tom slučaju se pokreće pametni ugovor između korisnika i mreže, čiji je standardni uslov za završetak generisanje rezultata proračuna scene od strane mreže. Korisnik može pratiti proces izvršavanja zadatka i upravljati njegovim parametrima preko web interfejsa svog ličnog naloga.
Zadatak se šalje na server, gdje se analizira obim scene i broj resursa koje zahtijeva inicijator zadatka, nakon čega se ukupan volumen razlaže na dijelove prilagođene za izračunavanje broja i vrste resursa koje mreža dodjeljuje. . Opća ideja je da se vizualizacija može podijeliti na mnogo malih zadataka. Motori iskorištavaju ovo tako što distribuiraju ove zadatke među više dobavljača resursa. Najjednostavniji način je renderiranje malih dijelova scene koji se nazivaju segmenti. Kada je svaki segment spreman, lokalni zadatak se smatra završenim, a resurs prelazi na sljedeći neriješeni zadatak.
Dakle, za renderera nema nikakve razlike da li se proračuni izvode na jednoj mašini ili na mreži mnogih pojedinačnih računarskih stanica. Distribuirano renderiranje jednostavno dodaje više jezgri u skup resursa koji se koriste za zadatak. Preko mreže prima sve podatke potrebne za renderiranje segmenta, izračunava ih, šalje taj segment nazad i prelazi na sljedeći zadatak. Prije ulaska u opći mrežni skup, svaki segment prima skup metainformacija koje omogućavaju izvršnim čvorovima da izaberu najprikladnije računske zadatke za njih.
Problemi segmentacije i distribucije proračuna moraju se rješavati ne samo sa stanovišta optimizacije vremena izvršenja, već i sa stanovišta optimalnog korištenja resursa i uštede energije, jer od toga ovisi ekonomska efikasnost mreže. . Ako je rješenje neuspješno, uputnije bi bilo instalirati rudar na čvor ili ga isključiti kako ne bi stvarao buku i ne trošio struju.
Međutim, vratimo se na proces. Kada se primi zadatak, između spremišta i čvora se formira i pametni ugovor, koji se izvršava kada je rezultat zadatka ispravno izračunat. Na osnovu rezultata ispunjenja ugovora, čvor može dobiti nagradu u ovom ili onom obliku.
Kontrolni centar kontroliše proces izvršavanja zadatka, prikupljanje rezultata proračuna, slanje pogrešnih na ponovnu obradu i rangiranje reda, praćenje standardnog roka za izvršenje zadatka (da se ne desi da zadnji segment ne zauzme bilo koji čvor).
Rezultati proračuna prolaze kroz fazu sastavljanja, nakon čega korisnik dobiva rezultate renderiranja, a mreža može dobiti nagradu.
Tako se pojavljuje funkcionalna kompozicija okvira pejzaža dizajniranog za izgradnju distribuiranih sistema za renderiranje:
- Lični korisnički nalozi sa pristupom webu
- Softverski komplet za instalaciju na čvorove
- Po upravljačkom sistemu:
- Podsistem kontrole pristupa
- Podsistem dekompozicije zadataka renderiranja
- Podsistem distribucije zadataka
- Kompozitni podsistem
- Podsistem za upravljanje pejzažom servera i topologijom mreže
- Podsistem evidentiranja i revizije
- Stručni podsistem učenja
- Rest API ili drugi interfejs za vanjske programere
Šta ti misliš? Koja pitanja postavlja tema i koji odgovori vas zanimaju?
izvor: www.habr.com