I de senere år er nyhedsfeeds blevet oversvømmet med beskeder om en ny type distribuerede computernetværk, der bogstaveligt talt dukker op ud af ingenting, løser (eller rettere forsøger at løse) en lang række problemer - at gøre en by smart, redde verden fra ophavsret krænkere eller omvendt, hemmeligt overføre information eller ressourcer, flygte fra -under statskontrol på et eller andet område. Uanset området har de alle en række fælles træk på grund af det faktum, at brændstoffet til deres vækst var de algoritmer og teknikker, der kom til offentligheden under det seneste boom i kryptovalutaer og relaterede teknologier. Sandsynligvis hver tredje artikel om specialiserede ressourcer på det tidspunkt havde ordet "blockchain" i titlen - diskussion af nye softwareløsninger og økonomiske modeller blev den dominerende tendens i nogen tid, på baggrund af hvilken andre anvendelsesområder for distribuerede computersystemer var henvist til baggrunden.
Samtidig så visionære og fagfolk hovedessensen af fænomenet: massiv distribueret computing, forbundet med opbygningen af netværk fra et stort antal forskellige og heterogene deltagere, har nået et nyt udviklingsniveau. Det er nok at smide hype-emnerne ud af dit hoved og se på emnet fra den anden side: alle disse netværk, samlet af enorme puljer, som består af tusindvis af isolerede heterogene deltagere, dukkede ikke op af sig selv. Entusiaster af kryptobevægelsen var i stand til at løse komplekse problemer med datasynkronisering og distribution af ressourcer og opgaver på en ny måde, hvilket gjorde det muligt at sammensætte en lignende masse af udstyr og skabe et nyt økosystem designet til at løse et snævert fokuseret problem.
Dette gik selvfølgelig ikke forbi de teams og fællesskaber, der var involveret i udviklingen af gratis distribueret computing, og nye projekter lod ikke vente på sig.
Men på trods af den betydelige stigning i mængden af tilgængelig information om udviklingen inden for bygning af netværk og arbejde med udstyr, bliver skaberne af lovende systemer nødt til at løse alvorlige problemer.
Den første af dem, uanset hvor mærkelig det kan lyde, er problemet med at vælge en retning.
Retningen kan være korrekt, eller den kan føre til en blindgyde - der er ingen flugt fra dette; centraliserede forsyninger af clairvoyante til it-samfundet er stadig forsinket. Men valget skal træffes for ikke at falde i den traditionelle fælde, at teamet tager for bredt et område og forsøger at skabe endnu et ikke-specialiseret generelt distribueret computerprojekt fra starten. Det ser ud til, at omfanget af arbejdet ikke er så skræmmende, for det meste skal vi bare anvende eksisterende udviklinger: kombinere noder i et netværk, tilpasse algoritmer til at bestemme topologier, udveksle data og overvåge deres konsistens, introducere metoder til at rangere noder og finde konsensus, og selvfølgelig bare opret dit eget forespørgselssprog og hele sproget og computermiljøet. Ideen om en universel mekanisme er meget fristende og dukker konstant op på et eller andet område, men slutresultatet er stadig en af tre ting: den skabte løsning viser sig enten at være en begrænset prototype med en masse suspenderede "ToDos" ” i efterslæbet, eller det bliver et ubrugeligt monster, der er klar til at slæbe enhver væk, der rører ved den ildelugtende “Turing-sump”, eller simpelthen dør trygt af, at svanen, krebsen og gedden, som trak projektet i en uforståelig retning, simpelthen overanstrengte sig selv.
Lad os ikke gentage dumme fejl og vælge en retning, der har en klar række af opgaver og er velegnet til den distribuerede computermodel. Du kan forstå folk, der forsøger at gøre alt på én gang – selvfølgelig er der masser at vælge imellem. Og mange ting ser ekstremt interessante ud både ud fra et R&D- og udviklingssynspunkt og ud fra et økonomisk synspunkt. Ved at bruge et distribueret netværk kan du:
- Træn neurale netværk
- Behandle signalstrømme
- Beregn proteinstruktur
- Gengiv XNUMXD-scener
- Simuler hydrodynamik
- Test handelsstrategier for børser
For ikke at lade os rive med af at udarbejde en liste over interessante ting, der er godt paralleliseret, vil vi vælge distribueret gengivelse som vores videre emne.
Selve distribueret gengivelse er naturligvis ikke noget nyt. Eksisterende render-værktøjssæt har længe understøttet belastningsfordeling på tværs af forskellige maskiner; uden dette ville det være ret trist at leve i det enogtyvende århundrede. Du skal dog ikke tro, at emnet er blevet dækket vidt og bredt, og der er ikke noget at gøre der - vi vil overveje et separat presserende problem: at skabe et værktøj til at skabe et render-netværk.
Vores gengivelsesnetværk er en kombination af noder, der skal udføre gengivelsesopgaver med noder, der har ledige computerressourcer til at behandle gengivelse. Ressourceejere vil forbinde deres stationer til render-netværket for at modtage og udføre render-opgaver ved hjælp af en af netværkets understøttede render-motorer. I dette tilfælde vil opgaveudbydere arbejde med netværket, som om det var en sky, uafhængigt distribuere ressourcer, overvåge rigtigheden af udførelsen, håndtere risici og andre problemer.
Derfor vil vi overveje at skabe en ramme, der skal understøtte integration med et sæt populære gengivelsesmotorer og indeholde komponenter, der giver værktøjer til at organisere et netværk af heterogene noder og styre strømmen af opgaver.
Den økonomiske model for eksistensen af et sådant netværk er ikke af fundamental betydning, så vi vil tage som den indledende ordning en ordning svarende til den, der bruges i beregninger i kryptovaluta-netværk - forbrugere af ressourcen vil sende tokens til leverandører, der udfører renderingsarbejdet. Det er meget mere interessant at forstå, hvilke egenskaber et framework skal have, for hvilket vi vil overveje hovedscenariet for interaktion mellem netværksdeltagere.
Der er tre sider af interaktion i netværket: ressourceudbyder, opgaveudbyder og netværksoperatør (alias kontrolcenter, netværk osv. i teksten).
Netværksoperatøren forsyner ressourceudbyderen med en klientapplikation eller et operativsystembillede med et installeret sæt software, som han vil installere på den maskine, hvis ressourcer han ønsker at stille til rådighed, og en personlig konto, der er tilgængelig via webgrænsefladen, hvilket giver ham mulighed for at indstille adgangsparametre til ressourcen og fjernadministrere sit serverlandskab: kontroller hardwareparametre, udfør fjernkonfiguration, genstart.
Når en ny node er tilsluttet, analyserer netværksstyringssystemet udstyret og specificerede adgangsparametre, rangerer det, tildeler en bestemt rating og placerer det i ressourceregistret. For at styre risikoen vil nodens aktivitetsparametre fremover blive analyseret, og nodens rating vil blive justeret for at sikre netværkets stabilitet. Ingen vil være glade, hvis deres scene bliver sendt til gengivelse på kraftfulde kort, der ofte fryser på grund af overophedning?
En bruger, der skal gengive en scene, kan gå to veje: upload scenen til et netværkslager via webgrænsefladen eller brug et plugin til at forbinde deres modelleringspakke eller installerede renderer til netværket. I dette tilfælde initieres en smart kontrakt mellem brugeren og netværket, hvis standardbetingelse for fuldførelse er genereringen af resultatet af sceneberegningen af netværket. Brugeren kan overvåge processen med at fuldføre en opgave og administrere dens parametre via webgrænsefladen på sin personlige konto.
Opgaven sendes til serveren, hvor volumen af scenen og antallet af ressourcer efterspurgt af opgaveinitiatoren analyseres, hvorefter den samlede volumen dekomponeres i dele tilpasset til beregning af antallet og typen af ressourcer allokeret af netværket . Den generelle idé er, at visualisering kan opdeles i mange små opgaver. Motorer drager fordel af dette ved at fordele disse opgaver blandt flere ressourceudbydere. Den enkleste måde er at gengive små dele af scenen kaldet segmenter. Når hvert segment er klar, betragtes den lokale opgave som afsluttet, og ressourcen går videre til den næste udestående opgave.
Det gør således ikke som sådan nogen forskel for rendereren, om beregningerne udføres på en enkelt maskine eller på et gitter af mange individuelle computerstationer. Distribueret gengivelse tilføjer simpelthen flere kerner til puljen af ressourcer, der bruges til en opgave. Gennem netværket modtager den alle de data, der er nødvendige for at gengive et segment, beregner det, sender det segment tilbage og går videre til den næste opgave. Før de går ind i den generelle netværkspulje, modtager hvert segment et sæt metainformation, der gør det muligt for udførende noder at vælge de bedst egnede computeropgaver til dem.
Problemerne med segmentering og distribution af beregninger skal løses ikke kun ud fra et synspunkt om optimering af udførelsestid, men også ud fra et synspunkt om optimal udnyttelse af ressourcer og energibesparelse, da netværkets økonomiske effektivitet afhænger af dette. . Hvis løsningen ikke lykkes, vil det være mere tilrådeligt at installere en minearbejder på knudepunktet eller slukke for den, så den ikke larmer og ikke spilder elektricitet.
Lad os dog vende tilbage til processen. Når en opgave modtages, dannes der også en smart kontrakt mellem poolen og noden, som udføres, når opgaveresultatet er korrekt beregnet. Baseret på resultaterne af opfyldelsen af kontrakten kan noden modtage en belønning i en eller anden form.
Kontrolcentret styrer processen med opgaveudførelse, indsamling af beregningsresultater, afsendelse af forkerte til genbearbejdning og rangering af køen, overvågning af standard deadline for færdiggørelse af opgaven (så det ikke sker, at det sidste segment ikke optages pr. enhver node).
Resultaterne af beregningerne gennemgår sammensætningsfasen, hvorefter brugeren modtager renderingsresultaterne, og netværket kan modtage en belønning.
Således fremkommer den funktionelle sammensætning af en landskabsramme designet til at bygge distribuerede renderingssystemer:
- Personlige brugerkonti med webadgang
- Software kit til installation på noder
- Ved kontrolsystem:
- Adgangskontrol undersystem
- Rendering opgave nedbrydning delsystem
- Undersystem for opgavefordeling
- Compositing subsystem
- Undersystem til administration af serverlandskab og netværkstopologi
- Logning og revision undersystem
- Læringsekspertundersystem
- Rest API eller anden grænseflade til eksterne udviklere
Hvad synes du? Hvilke spørgsmål rejser emnet, og hvilke svar er du interesseret i?
Kilde: www.habr.com