În ultimii ani, fluxurile de știri au fost inundate de mesaje despre rețelele de calcul distribuit, care apar literalmente din niciunde, încercând să rezolve cele mai diverse probleme — să transforme orașele în unele inteligente, să salveze lumea de încălcările drepturilor de autor sau, din contră, să ofere în secret informații sau resurse, să scape de controlul statului în diverse domenii. Indiferent de sferă, toate acestea au o serie de trăsături comune, dictată de faptul că carburantul pentru dezvoltarea lor au fost algoritmii și metodele care au ajuns în mase în timpul recentei bule de criptomonede și a tehnologiilor înrudite. Probabil că fiecare a treia articol de pe resursele de specialitate în acea perioadă avea cuvântul "blockchain" în titlu — discutarea noilor soluții software și modele economice a devenit pentru o vreme tendința dominantă, într-un fundal în care alte sfere de aplicare ale sistemelor de calcul distribuit au fost puse în plan secund.
În același timp, viziunile și profesioniștii au vazut esența fenomenului: calculul distribuit de masă, asociat cu construirea de rețele dintr-un număr mare de participanți dispersați și eterogeni, a ajuns la un nou nivel de dezvoltare. Este suficient să scapi din minte temele hype și să privești subiectul dintr-o altă perspectivă: toate aceste rețele, formate din oceane uriașe de participanți separați și diferiți, nu au apărut din senin. Entuziaștii mișcării crypto au reușit să rezolve în mod inedit probleme complexe de sincronizare a datelor și distribuție a resurselor și sarcinilor, ceea ce a permis împreunarea unei astfel de mase de echipamente pentru a crea un nou ecosistem destinat rezolvării unei sarcini foarte specifice.
Desigur, acest lucru nu a trecut neobservat de echipele și comunitățile care se ocupă cu dezvoltarea calculului distribuit liber, iar noile proiecte nu au întârziat să apară.
Cu toate acestea, în ciuda creșterii semnificative a volumului de informații disponibile despre progresele în domeniul construirii rețelelor și lucrului cu echipamente, creatorii sistemelor promițătoare se vor confrunta cu probleme serioase.
Prima dintre acestea, oricât de ciudat ar suna, este problema alegerii direcției.
Direcția poate fi corectă sau poate conduce într-o fundătură - acest lucru nu se poate evita, livrările centralizate de prevăzători în comunitatea IT sunt încă întârziate. Dar este necesar să facem o alegere pentru a nu cădea în capcana tradițională, constând în faptul că echipa își asumă un domeniu prea larg și încearcă de la început să creeze încă un proiect nespecializat de calcul distribuit de amploare generală. Se pare că frontul de lucru nu este atât de înfricoșător, trebuie în principal să aplici realizările existente: să unifici nodurile într-o rețea, să adaptezi algoritmii de determinare a topologiilor, schimbului de date și controlului coerenței lor, să implementezi metodologia de clasificare a nodurilor și găsirea consensului și, bineînțeles, doar să creezi propriul tău limbaj de interogare și întregul mediu lingvistic și computațional. Ideea unui mecanism universal este foarte atrăgătoare și revine constant în diferite domenii, dar la ieșire se obține în continuare unul din trei rezultate: soluția creată fie se dovedește a fi de fapt un prototip limitat cu o mulțime de „ToDo”-uri în backlog, fie devine un monstru inutilizabil, pregătit să tragă pe oricine atinge în „mlaștina turingiană” malodorantă, fie pur și simplu moare din cauza că cei care trăgeau proiectul într-o direcție neclară - rățoi, rac și știucă - s-au epuizat.
Să nu repetăm greșelile stupide și să alegem o direcție care are un cerc de sarcini clar și se potrivește bine modelului de calcul distribuit. Poate fi înțeles cei care încearcă să facă totul simultan - există, desigur, de unde alege. Și multe aspecte par extrem de interesante atât din punct de vedere R&D și dezvoltare, cât și din punct de vedere economic. Folosind o rețea distribuită, se poate:
- Antrena rețele neuronale
- Prelucra fluxuri de semnale
- Calcula structura proteinelor
- Realiza randări ale scenelor tridimensionale
- Modela hidrodinamica
- Testa strategii de tranzacționare pentru burse
Pentru a nu ne lăsa atrași de compunerea unei liste de lucruri interesante care se paralelizează bine, să alegem ca subiectul nostru viitor randarea distribuită.
Renderizarea distribuită, pe sine, nu este un fenomen nou. Kiturile de instrumente de randare existente au susținut de mult distribuția sarcinilor pe diferite mașini; fără aceasta, viața în secolul XXI ar fi fost destul de nesatisfăcătoare. Cu toate acestea, nu trebuie să credem că subiectul a fost epuizat și că nu mai există nimic de făcut; vom analiza o problemă importantă: crearea unui instrument pentru formarea unei rețele de randare.
În rețeaua noastră de randare, avem o combinație de noduri care trebuie să execute sarcinile de randare, cu noduri care dispun de resurse de calcul disponibile pentru procesarea randării. Proprietarii de resurse vor conecta stațiile lor la rețeaua de randare pentru a primi și a executa sarcini de randare folosind unul dintre motorul de randare acceptate de rețea. Furnizorii de sarcini vor interacționa cu rețeaua ca și cum ar fi un cloud, care gestionează de la sine distribuția resurselor, verificarea corectitudinii execuției, gestionarea riscurilor și alte probleme.
Astfel, vom analiza crearea unui cadru care ar trebui să susțină integrarea cu o gamă de motoare de randare populare și să conțină componente care oferă instrumente pentru organizarea unei rețele din noduri variate și gestionarea fluxului de sarcini.
Modelul economic al existenței unei astfel de rețele nu are o importanță esențială, așa că vom lua drept bază o schemă similară cu cea folosită în calculul rețelelor de criptomonedă – consumatorii de resurse vor trimite token-uri furnizorilor care execută munca de randare. Este mult mai interesant să înțelegem ce calități ar trebui să aibă cadrul, pentru a analiza scenariul principal de interacțiune a participanților în rețea.
În rețea există trei părți care interacționează: furnizorul de resurse, furnizorul de sarcini și operatorul rețelei (care este, de asemenea, centrul de control, rețeaua etc., în text).
Operatorul rețelei oferă furnizorului de resurse o aplicație client sau o imagine a sistemului de operare cu un set complet de software dezvoltat, pe care acesta îl va instala pe mașina ale cărei resurse dorește să le ofere. Accesul se face prin intermediul unei interfețe web a unui cont personal, care îi permite să seteze parametrii de acces la resursă și să gestioneze de la distanță peisajul său server: să controleze parametrii hardware, să efectueze configurări la distanță, să repornească.
Sistemul de management al rețelei, atunci când se conectează un nou nod, analizează echipamentul și parametrii de acces setați, îl clasifică, atribuindu-i un anumit rating, și îl înregistrează în registrul resurselor. Ulterior, în scopuri de gestionare a riscurilor, parametrii de activitate ai nodului vor fi analizați, iar ratingul acestuia va fi corectat pentru a asigura stabilitatea funcționării rețelei. Nimănui nu i-ar plăcea ca scena lor să fie trimisă pentru a fi redată pe plăci grafice puternice, dar adesea blocate din cauza supraîncălzirii?
Utilizatorul care trebuie să redimensioneze o scenă poate merge pe două căi: să încarce scena în repertoriul rețelei prin intermediul interfeței web sau să conecteze pachetul său de modelare sau renderer-ul instalat la rețea printr-un plugin. În acest proces, între utilizator și rețea se inițiază un smart contract, condiția standard de finalizare a acestuia fiind generarea de către rețea a rezultatului calculului scenei. Utilizatorul poate urmări procesul de execuție a sarcinii și gestiona parametrii acesteia prin intermediul interfeței web a contului său personal.
Sarcina ajunge la serverul, unde se analizează volumul scenei și numărul de resurse solicitate de inițiatorul sarcinii, după care se efectuează decompunerea volumului total în părți adaptate pentru calcul pe cantitatea și tipul de resurse dedicate de rețea. Ideea generală este că vizualizarea poate fi împărțită în numeroase sarcini mici. Motoarele profita de acest avantaj, distribuind aceste sarcini între numeroși furnizori de resurse. Cel mai simplu mod este redarea unor părți mici ale scenei, numite segmente. Când fiecare segment este gata, sarcina locală este considerată finalizată, resursa trece la executarea următoarei sarcini nerezolvate.
Astfel, pentru renderer nu există o diferență reală dacă calculele sunt efectuate pe o singură mașină sau pe un grid de multe stații de calcul separate. Renderingul distribuit adaugă pur și simplu mai multe nuclee în pool-ul de resurse utilizate pentru sarcină. Prin rețea, acesta primește toate datele necesare pentru a reda segmentul, îl calculează, trimite acest segment înapoi și trece la următoarea sarcină. Înainte de a intra în pool-ul comun al rețelei, fiecare segment primește un set de metainformații, permițând nodurilor executante să aleagă cele mai potrivite sarcini de calcul.
Sarcinile de segmentare și distribuire a calculului trebuie rezolvate nu doar din perspectiva optimizării timpului de execuție, ci și din punctul de vedere al utilizării optime a resurselor și economisirii de energie, deoarece acest lucru afectează eficiența economică a rețelei. În cazul unei soluții nereușite, ar fi mai convenabil să se instaleze un miner pe nod sau să fie oprit, pentru a nu face zgomot și a nu consuma electricitate.
Cu toate acestea, să ne întoarcem la proces. La primirea sarcinii, între pool și nod se formează, de asemenea, un smart contract, care se execută atunci când rezultatul sarcinii este calculat corect. La finalizarea contractului, nodul poate primi o recompensă sub diverse forme.
Centrul de control monitorizează procesul de executare a sarcinii, colectând rezultatele calculului, trimite pentru reprocesare rezultatele incorecte și clasifică coada, urmărind termenul standard de execuție a sarcinii (pentru a nu se întâmpla ca ultimul segment să nu fie preluat de niciun nod).
Rezultatele calculului trec printr-o etapă de compunere, după care utilizatorul primește rezultatele redării, iar rețeaua poate obține o recompensă.
Astfel, se conturează compunerea funcțională a framework-ului de peisaj destinat construirii sistemelor de rendering distribuit:
- Cabinete personale ale utilizatorilor cu acces web
- Pachet software pentru instalare pe noduri
- După sistemele de gestionare:
- Subsystema de gestionare a accesului
- Subsystema de decompoziție a sarcinilor de redare
- Subsystema de distribuție a sarcinilor
- Subsystema de compunere
- Subsystema de gestionare a peisajului serverului și a topologiei rețelei
- Subsystema de logare și audit
- Subsystema expertă învățată
- API REST sau o altă interfață pentru dezvoltatorii externi
Ce părere aveți? Ce întrebări ridică acest subiect și ce răspunsuri vă interesează?
Sursa: habr.com
