V posledných rokoch sa spravodajské kanály zaplnili správami o nových typoch distribuovaných výpočtových sietí, ktoré sa objavili doslova z ničoho a snažia sa riešiť najrôznejšie úlohy — urobiť mesto inteligentným, zachrániť svet pred porušovateľmi autorských práv alebo naopak, tajne prenášať informácie či zdroje, uniknúť kontrole štátu v rôznych oblastiach. Bez ohľadu na odvetvie, všetky majú niekoľko spoločných rysov, ktoré sú určené tým, že palivom pre ich rast sa stali algoritmy a metodiky, ktoré sa dostali do širokého povedomia počas nedávneho boomu kryptomien a s nimi spojených technológií. Snáď každá tretia článok na profilových stránkach v tom čase mala v názve slovo „blockchain“ — diskusia o nových softvérových riešeniach a ekonomických modeloch sa na chvíľu stala dominantným trendom, v ktorého pozadí sa iné oblasti použitia systémov distribuovaných výpočtov dostali na vedľajšiu kolej.
Zároveň vizionári a profesionáli rozpoznali hlavnú podstatu fenoménu: masové distribuované výpočty, týkajúce sa budovania sietí z mnohých rozdelených a heterogénnych účastníkov, dosiahli novú úroveň rozvoja. Stačí sa zbaviť hype tém a pozrieť sa na predmet z iného uhla: všetky tieto siete, zložené z obrovských bazénov, ktorými sú tisíce izolovaných heterogénnych účastníkov, nevznikli samé od seba. Nadšenci kryptohybnosti dokázali vyriešiť zložitosti synchronizácie údajov a distribúcie zdrojov a úloh novým spôsobom, čo umožnilo zhromaždiť takúto masu vybavenia a vytvoriť nový ekosystém určený na riešenie jedného úzko zameraného problému.
Samozrejme, to neuniklo tímom a komunitám, ktoré sa zaoberajú rozvojom slobodných distribuovaných výpočtov, a nové projekty nenechali na seba dlho čakať.
Avšak, napriek vážnemu zvýšeniu objemu dostupných informácií o vývoji sietí a práci s vybavením, tvorcovia perspektívnych systémov budú musieť čeliť vážnym problémom.
Prvou z nich, akokoľvek to znie neobvykle, je problém výberu smeru.
Smer môže byť správny, môže viesť do slepej uličky — tomuto sa nedá vyhnúť, centralizované dodávky clairvoyantov do IT komunity zatiaľ zaostávajú. Ale výber je potrebné urobiť, aby sme sa nedostali do tradičnej pasce, ktorá spočíva v tom, že tím si zoberie príliš širokú oblasť a od začiatku sa pokúša vytvoriť ďalší nespecializovaný projekt pre distribuované výpočty širokého profilu. Zdá sa, že fronta prác nie je tak strašná, treba väčšinou len aplikovať existujúce riešenia: spojiť uzly do siete, prispôsobiť algoritmy na určovanie topológií, výmenu dát a kontrolu ich konzistencie, implementovať metodiky hodnotenia uzlov a hľadania konsenzu a samozrejme, len tak vytvoriť svoj vlastný jazyk dotazov a celkové jazykové a výpočtové prostredie. Myšlienka univerzálneho mechanizmu je veľmi lákavá a neustále sa objavuje v rôznych oblastiach, ale na konci to stále vyjde ako jedno z troch: vytvorené riešenie buď ukáže byť v skutočnosti obmedzeným prototypom s množstvom visiacich „ToDo“ v backlogu, alebo sa zmení na nepoužiteľného monštra, pripraveného vtiahnuť každého, kto sa ho dotkne, do zapáchajúceho „Turingovho bažinatého“ miesta, alebo jednoducho spokojne zomrie na to, že projekt ťahali do nejasnej oblasti „labuť, rak a šťuka“ sa banálne pretrhli.
Nepodľahneme hlúpym chybám a vyberieme smer, ktorý má jasný okruh úloh a dobre zapadá do modelu distribuovaných výpočtov. Môžeme pochopiť ľudí, ktorí sa snažia robiť všetko naraz — rozhodne je z čoho vyberať. A veľa vecí vyzerá extrémne zaujímavo, ako z pohľadu R&D, tak z pohľadu ekonomiky. Pomocou distribuovanej siete môžeme:
- Vyučovať neurónové siete.
- Spracovávať prúdy signálov.
- Vypočítavať štruktúru proteínov.
- Vykonávať rendering trojrozmerných scén.
- Modelovať hydrodynamiku.
- Testovať obchodné stratégie pre burzy.
Aby sme sa nezaplietli do zoznamu zaujímavých vecí, ktoré sa dajú dobre paralelizovať, vyberme si ako tému nášho ďalšieho prieskumu distribuovaný rendering.
Distribuovaný rendering sám o sebe nie je vôbec novým javom. Existujúce rendrovacie nástroje už dávno podporujú rozdelenie záťaže medzi rôznymi strojmi, bez toho by bolo v 21. storočí dosť smutné žiť. No netreba si myslieť, že je táto téma vyčerpaná a nie je v nej čo robiť — preskúmame samostatný aktuálny problém: vytvorenie nástroja na budovanie rendrovacej siete.
Naša rendrovacia sieť je zoskupením uzlov, ktoré potrebujú vykonávať rendrovacie úlohy, s uzlami, ktoré majú voľné výpočtové zdroje na spracovanie renderovania. Vlastníci zdrojov sa pripoja k rendrovacej sieti, aby dostávali a vykonávali zadania renderovania pomocou jedného z podporovaných rendrovacích enginov. Poskytovatelia úloh budú pracovať so sieťou ako s cloudom, ktorý sám vykonáva rozdelenie zdrojov, kontrolu správnosti vykonania, riadenie rizík a ďalšie problémy.
Tým pádom sa budeme zaoberať vytvorením frameworku, ktorý musí podporovať integráciu s množstvom populárnych rendrovacích enginov a obsahovať komponenty, ktoré poskytujú nástroje na organizovanie siete z heterogénnych uzlov a riadenie toku úloh.
Ekonomický model existencie takejto siete nemá zásadný význam, preto za východiskový zoberieme schému podobnú tej, čo sa používa vo výpočtoch v kryptomenových sieťach — spotrebitelia zdroja budú zasielať tokeny poskytovateľom, ktorí vykonávajú rendrovaciu prácu. Oveľa zaujímavejšie je pochopiť, akými vlastnosťami by mal framework disponovať, a preto preskúmame základný scenár interakcie účastníkov siete.
V sieti existujú tri strany interakcie: poskytovateľ zdrojov, poskytovateľ úloh a operátor siete (rovnako aj centrum riadenia, sieť atď. podľa textu).
Prevádzkovateľ siete poskytuje dodávateľovi zdrojov klientskú aplikáciu alebo obraz operačného systému s predinštalovaným softvérom, ktorý nainštaluje na stroj, ktorého zdroje chce poskytnúť. Ten je prístupný prostredníctvom webového rozhrania osobného účtu, ktoré mu umožňuje nastaviť prístupové parametre k zdrojom a na diaľku spravovať svoj serverový komplex: monitorovať hardvér, vykonávať diaľkové nastavenia a reštartovať.
Systém správy siete pri pripojení nového uzla vykonáva analýzu hardvéru a zadaných prístupových parametrov, hodnotí ho, priraďuje mu určitý hodnotenie a umiestňuje ho do registra zdrojov. Následne sa s cieľom riadenia rizika parametre aktivity uzla budú analyzovať a hodnotenie uzla bude upravované, aby sa zabezpečila stabilita siete. Nikto predsa nechce, aby jeho scéna bola odoslaná na renderovanie na výkonných, ale často zamŕzajúcich grafikách z prehriatia?
Používateľ, ktorý potrebuje rendrovať nejakú scénu, má dve možnosti: nahrať scénu do repozitára siete cez webové rozhranie alebo pomocou pluginu pripojiť svoj modelovací balík alebo nainštalovaný renderovač k sieti. Pri tomto sa medzi používateľom a sieťou iniciuje smart kontrakt, ktorého štandardnou podmienkou na ukončenie je generovanie výsledku výpočtu scény. Používateľ môže sledovať priebeh vykonávania úlohy a spravovať jej parametre cez webové rozhranie svojho osobného účtu.
Úloha prichádza na server, kde sa analyzuje objem scény a množstvo zdrojov požadovaných iniciátorom úlohy, po čom sa vykonáva dekompozícia celkového objemu na časti, ktoré sú prispôsobené na výpočty na vynesenom množstve a type zdrojov. Celkovou myšlienkou je, že vizualizácia môže byť rozdelená na množstvo malých úloh. Enginy využívajú túto výhodu, pričom tieto úlohy rozdeľujú medzi množstvo dodávateľov zdrojov. Najjednoduchší spôsob je renderovanie malých častí scény, nazývaných segmenty. Keď je každý segment hotový, miestna úloha sa považuje za dokončenú a zdroj prechádza k vykonaniu nasledujúcej z nevyriešených úloh.
Preto pre renderovaciu nie je žiadny podstatný rozdiel, či sa výpočty vykonávajú na jednom počítači alebo na sieti množstva samostatných výpočtových staníc. Distribuované renderovanie jednoducho pridáva viac jadier do zdroja využívaného pre úlohu. Cez sieť získava všetky údaje potrebné na renderovanie segmentu, vypočíta ho, odošle tento segment späť a prechádza k ďalšej úlohe. Predtým, ako sa dostane do spoločného zdroja siete, každý segment získa sadu meta informácií, ktoré umožňujú vykonávacím uzlom vybrať si pre seba najvhodnejšie výpočtové úlohy.
Úlohy segmentácie a distribúcie výpočtov musia byť riešené nielen z pohľadu optimalizácie času realizácie, ale aj z pohľadu optimálneho využitia zdrojov a úspory energie, pretože od toho závisí hospodárska efektivita siete. V prípade neúspešného riešenia by bolo rozumnejšie umiestniť na uzol ťažiar alebo ho vypnúť, aby nerobil šum a neminul elektrinu.
Avšak vráťme sa k procesu. Pri prijímaní úlohy medzi zdrojom a uzlom sa tiež vytvára smart kontrakt, ktorý sa vykonáva pri správnom výpočte výsledku úlohy. Na základe výkonu kontraktu môže uzol získať odmenu rôznymi spôsobmi.
Centrum riadenia kontroluje proces vykonávania úlohy, zhromažďujúc výsledky výpočtov, odosielajúc späť na spracovanie nesprávne a triediaci rad, sledujúc normatívne lehoty vykonania úlohy (aby sa nestalo, že posledný segment nebude spracovaný žiadnym uzlom).
Výsledky výpočtov prechádzajú etapou kompozície, po ktorej používateľ dostáva výsledky renderovania a sieť môže získať odmenu.
Takto sa vykresľuje funkčný rámec pre systém distribučného renderovania:
- Osobné účty užívateľov s webovým prístupom
- Súbor softvéru na inštaláciu na uzly
- Podľa riadiacich systémov:
- Podzákladňa správy prístupu
- Podzákladňa dekompozície renderovacích úloh
- Podzákladňa distribúcie úloh
- Podzákladňa kompozície
- Podzákladňa správy serverového prostredia a topológie siete
- Podzákladňa logovania a auditu
- Učiaca sa expertná podzákladňa
- Rest API alebo iné rozhranie pre vonkajších vývojárov
A čo si myslíte vy? Aké otázky vyvoláva táto téma a aké odpovede vás zaujímajú?
Zdroj: habr.com
