I de seneste år er nyhedsstrømme blevet fyldt med meddelelser om nye typer af distribuerede computernetværk, der opstår bogstaveligt talt ud af ingenting, og som forsøger at løse en bred vifte af opgaver - at gøre byen smart, redde verden fra krænkelse af ophavsret, eller omvendt, hemmeligt overføre information eller ressourcer, og undslippe statslig kontrol inden for forskellige områder. Uanset området har de alle et par fælles træk, som skyldes, at deres vækst blev drevet af algoritmer og metoder, der blev populære under det nylige boom i kryptovaluta og relaterede teknologier. Nok havde hver tredje artikel på specialiserede ressourcer ordet 'blockchain' i titlen - diskussionen om nye softwareløsninger og økonomiske modeller blev i et stykke tid den dominerende trend, mens andre anvendelsesområder for distribuerede computationer blev skubbet i baggrunden.
Samtidig så visionærer og fagfolk essensen af fænomenet: massefordelte computere, der handler om opbygning af netværk bestående af et stort antal adskilte og heterogene deltagere, har nået et nyt udviklingsniveau. Det er nok at kaste hypede emner ud af hovedet og se på sagen fra en anden vinkel: alle disse netværk, samlet fra enorme puljer, bestående af tusinder af adskilte, heterogene deltagere, dukkede ikke op af sig selv. Enthusiaster inden for kryptobevegelsen har formået at løse komplekse problemer med datasynkronisering og ressource- og opgavefordeling på en ny måde, hvilket har gjort det muligt at samle en sådan mængde udstyr og skabe et nyt økosystem, der er designet til at løse en snævert defineret opgave.
Selvfølgelig er det ikke gået ubemærket hen for de teams og samfund, der arbejder med udviklingen af frie distribuerede computere, og nye projekter har ikke ladet vente på sig.
Men på trods af den betydelige stigning i mængden af tilgængelige oplysninger om fremskridt inden for opbygning af netværk og arbejde med udstyr, står skaberne af fremadskuende systemer over for alvorlige problemer.
Den første af disse, hvordan det end lyder mærkeligt, er problemet med valget af retning.
Retningen kan være den rigtige, eller den kan føre til en blindgyde - det kan ikke undgås, da de centraliserede leverancer af clairvoyance til IT-samfundet stadig er forsinket. Men der skal træffes et valg for ikke at falde i den traditionelle fælde, som består i, at teamet tager for bredt fat og fra starten forsøger at skabe endnu et ikke-specialiseret projekt inden for distribueret computing af bredt omfang. Det virker som om, at arbejdsfronten ikke er så skræmmende, det handler for det meste bare om at anvende eksisterende udviklinger: forbinde noder i et netværk, tilpasse algoritmer til topologibestemmelse, dataudveksling og kontrol af konsistens, implementere metoder til rangordning af noder og opnå konsensus, og selvfølgelig blot skabe sit eget forespørgselsprog og hele det sproglige og beregningsmæssige miljø. Ideen om en universel mekanisme er yderst fristende og dukker konstant op i forskellige områder, men udgangen ender stadig ofte i en af tre resultater: den skabte løsning viser sig enten at være en begrænset prototype med mange uafklarede 'ToDo'-punkter i backloggen, eller den bliver et ubrugeligt monster, der er klar til at trække enhver, der rører ved den, ind i den stinkende 'Turing-gressen', eller den dør simpelthen, fordi dem, der trak projektet i uforståelige retninger, som en svane, krabbe og gedde, bare er slidte.
Lad os undgå at gentage dumme fejl og vælge en retning med en klar opgavekreds, der passer godt ind i modellen for distribueret computing. Man kan forstå folk, der forsøger at gøre alt og samtidig - der er selvfølgelig meget at vælge imellem. Og meget ser ekstremt interessant ud både fra et R&D- og udviklingsperspektiv og fra et økonomisk synspunkt. Ved hjælp af et distribueret netværk kan man:
- Uddanne neurale netværk
- Behandle signalstrømme
- Beregnere proteinstrukturer
- Udføre rendering af 3D-scener
- Modellere hydrodynamik
- Teste handelsstrategier for aktiemarkeder
For ikke at lade os besætte med at lave en liste over interessante ting, der kan paralleliseres godt, vil vi vælge distribueret rendering som vores næste emne.
Distribueret rendering er i sig selv ikke et nyt fænomen. Eksisterende render-værktøjer har længe understøttet belastningsfordeling på tværs af forskellige maskiner; uden dette ville livet i det 21. århundrede være ret trist. Men man skal ikke tro, at emnet er udtømt, og at der ikke er noget at gøre — vi vil se på et specifikt aktuelt problem: at skabe et værktøj til opbygning af et render-netværk.
Vores render-netværk er en samling af noder, der skal udføre renderingsopgaver, samt noder, der har ledige beregningsressourcer til at håndtere rendering. Ejere af ressourcer vil tilslutte deres stationer til render-netværket for at modtage og udføre renderingsopgaver ved hjælp af en af de render-motorer, som netværket understøtter. Opgaveteleverandører vil bredt arbejde med netværket som en sky, der selvstyrer ressourcer, overvåger korrekt udførelse, håndterer risici og andre problemer.
Dermed vil vi se på oprettelsen af et rammeværk, der skal støtte integrationen med et udvalg af populære render-motorer og indeholde komponenter, der leverer værktøjer til at organisere netværket af heterogene noder og styre opgaveflowet.
Den økonomiske model for eksistensen af et sådant netværk er ikke afgørende, så vi tager udgangspunkt i en model, der ligner den, der anvendes i beregninger i kryptovaluta-netværk — forbrugerne af ressourcen vil sende tokens til leverandørerne, som udfører renderingsarbejdet. Det, der er mere interessant, er at forstå, hvilke egenskaber rammeværket skal have, og derfor vil vi se på det primære scenarie for interaktion mellem netværkets deltagere.
I netværket er der tre parter, der interagerer: ressourceleverandøren, opgaveteleveandøren og netværksoperatøren (også kaldet kontrolcenteret, netværket osv. i teksten).
Netværksoperatøren leverer en klientapplikation eller et operativsystembillede med et udvidet sæt software til resourceudbyderen, som denne installerer på den maskine, hvis ressourcer den ønsker at tilbyde, samt et webgrænseflade til en personlig konto, der gør det muligt for den at angive adgangspunkt til ressourcen og administrere sin serverinfrastruktur eksternt: overvåge hardwareparametre, udføre fjernkonfiguration og genstarte.
Netværksstyringssystemet analyserer udstyret og de angivne adgangsparametre ved tilslutningen af en ny node, rangerer det ved at tildele en bestemt rating og placerer det i ressource-registret. For at styre risiciene vil aktivitetsparametrene for noden blive analyseret, og nodens rangering vil blive justeret for at sikre stabiliteten i netværkets drift. Ingen ønsker jo, at deres scene skal sendes til rendering på kraftfulde, men ofte overophedede grafikkort?
En bruger, der har brug for at få rendereret en scene, kan vælge mellem to metoder: uploade scenen til netværkets repository via webgrænsefladen eller forbinde sin modelleringpakke eller installerede renderer til netværket ved hjælp af et plugin. Herunder initieres der en smart kontrakt mellem brugeren og netværket, hvor standardbetingelsen for afslutning er, at netværket genererer resultatet af scenernes beregning. Brugeren kan overvåge opgavens udførelsesproces og administrere dens parametre via webgrænsefladen i sin personlige konto.
Opgaven overføres til server, hvor scenevolumenet og antallet af de ressources, der er anmodet af opgaveinitiatoren, analyseres, hvorefter den samlede mængde nedbrydes i dele tilpasset til beregning på det dedikerede antal og type ressourcer, der leveres af netværket. Den overordnede idé er, at visualiseringen kan opdeles i mange små opgaver. Engineerne drager fordel af dette ved at fordele opgaverne blandt mange ressourcenaudbydere. Den enkleste metode er at renderere små dele af scenen, kaldet segmenter. Når hvert segment er færdigt, betragtes den lokale opgave som afsluttet, og ressourcen overgår til at udføre den næste udestående.
Der er således ikke nogen egentlig forskel for renderer, om beregninger udføres på én maskine eller på et grid bestående af mange separate beregningsstationer. Distribueret rendering tilføjer blot flere kerner til den pool af ressourcer, der anvendes til opgaven. Gennem netværket modtager den alle de data, der er nødvendige for at rendere segmentet, beregner det, sender dette segment tilbage og går videre til den næste opgave. Inden det kommer ind i den fælles netværkspool, modtager hvert segment et sæt metadata, der gør det muligt for udførelseskud at vælge de mest passende beregningsopgaver.
Opgaver vedrørende segmentering og distribution af beregninger skal ikke kun løses ud fra et optimeringsperspektiv for udførelsestid, men også med henblik på optimal ressourceudnyttelse og energibesparelse, da dette påvirker den økonomiske effektivitet i netværket. I tilfælde af en fejlfunktion vil det være mere hensigtsmæssigt at placere en miner på noden eller slukke den, så den ikke larmer eller bruger strøm.
Men lad os vende tilbage til processen. Ved modtagelse af en opgave mellem poolen og noden oprettes også en smart kontrakt, der udføres ved korrekt beregning af opgavens resultat. Efter afslutningen af kontrakten kan noden modtage belønning i en eller anden form.
Kontrolcentret overvåger processen for udførelsen af opgaven, indsamler beregningsresultater, sender ugyldige tilbage til genbehandling og rangerer køen, mens det også holder øje med den normative udførelsestid for opgaven (så det ikke sker, at det sidste segment ikke tages op til behandling af nogen node).
Beregningernes resultater går gennem en kompositionsfase, hvorefter brugeren modtager rendringsresultaterne, og netværket kan modtage en belønning.
Således aftegnes det funktionelle indhold af det landskabsrammeværk, der er beregnet til at opbygge systemer til distribueret rendering:
- Brugerprofiler med webadgang
- Softwarepakke til installation på noder
- I styringssystemer:
- Adgangsstyringsundersystem
- Undersystem til opgavekomposition af rendering
- Undersystem til distributionsopgaver
- Kompositionsundersystem
- Undersystem til styring af serverlandskab og netværkstopologi
- Logning og revisionsundersystem
- Lærende ekspertundersystem
- Rest API eller en anden grænseflade til eksterne udviklere
Hvad mener du? Hvilke spørgsmål rejser emnet, og hvilke svar er du interesseret i?
Kilde: habr.com
