In de afgelopen jaren zijn nieuwsupdates overspoeld met berichten over nieuwe soorten gedistribueerde rekensystemen die letterlijk uit het niets opduiken, en proberen om verschillende taken op te lossen — een slimme stad creëren, de wereld beschermen tegen auteursrechtenschendingen, of omgekeerd, in het geheim informatie of middelen overdragen en ontkomen aan controle door de staat in het een of andere domein. Ongeacht het gebied hebben ze allemaal een aantal gemeenschappelijke kenmerken, die voortkomen uit het feit dat de brandstof voor hun groei algoritmen en methoden zijn die in de recente cryptocurrency-hype en bijbehorende technologieën wijdverbreid zijn geworden. Waarschijnlijk had elke derde artikel op gespecialiseerde platforms in die tijd het woord "blockchain" in de titel — discussies over nieuwe software-oplossingen en economische modellen werden enige tijd de dominante trend, waardoor andere toepassingsgebieden van gedistribueerde rekensystemen op de achtergrond raakten.
Tegelijkertijd zagen visionairs en professionals de essentie van het fenomeen: massale gedistribueerde berekeningen, die verband houden met het opbouwen van netwerken van een groot aantal losse en heterogene deelnemers, zijn op een nieuw ontwikkelingsniveau gekomen. Het is voldoende om de opwindende thema's uit je hoofd te zetten en anders naar de zaak te kijken: al deze netwerken, verzameld uit enorme pools waarin duizenden afzonderlijke heterogene deelnemers zijn ondergebracht, zijn niet vanzelf ontstaan. Enthousiastelingen van de crypto-beweging hebben complexe problemen van gegevenssynchronisatie en de distributie van middelen en taken op een nieuwe manier weten op te lossen, wat het mogelijk maakte om zo'n massa apparatuur samen te brengen en een nieuw ecosysteem te creëren dat is ontworpen om een specifieke taak te vervullen.
Natuurlijk is dit niet voorbij gegaan aan teams en gemeenschappen die betrokken zijn bij de ontwikkeling van vrije gedistribueerde berekeningen, en nieuwe projecten lieten niet op zich wachten.
Echter, ondanks de aanzienlijke toename van de beschikbare informatie over ontwikkelingen op het gebied van netwerkconstructie en apparatuur, zullen de ontwikkelaars van veelbelovende systemen ernstige problemen moeten oplossen.
De eerste hiervan, hoe vreemd het ook klinkt, is het probleem van de keuze van de richting.
De richting kan juist zijn, maar kan ook in een impasse leiden — dat is onontkoombaar, centrale leveringen van helderzienden aan de IT-gemeenschap blijven vooralsnog achter. Maar er moet een keuze worden gemaakt om niet in de traditionele val te trappen, waarbij het team een te breed gebied kiest en vanaf het begin probeert om weer een niet-gespecialiseerd project voor gedistribueerde berekeningen te creëren. Het lijkt erop dat de frontlinie van het werk niet zo eng is, je moet voornamelijk gewoon de bestaande ontwikkelingen toepassen: knooppunten in een netwerk combineren, algoritmes voor topologieën, gegevensuitwisseling en het bewaken van hun consistentie aanpassen, technieken voor het rangschikken van knooppunten en het vinden van consensus implementeren, en natuurlijk gewoon je eigen querytaal creëren en alle taal- en rekenomgevingen opzetten. Het idee van een universeel mechanisme is heel verleidelijk en komt voortdurend op in een of andere sector, maar uiteindelijk komt er nog steeds een van de drie uit: de gemaakte oplossing blijkt ofwel een beperkt prototype te zijn met een heleboel onafgemaakte “ToDo” in de backlog, of wordt een onbruikbaar monster dat iedereen die het aanraakt naar het stinkende “Turing moeras” kan trekken, of sterft gewoon een gelukkige dood omdat de projectdeelnemers die de richting niet begrepen een lepel, een kanker en een snoek zijn die simpelweg zijn doorgebroken.
Laten we geen domme fouten herhalen en een richting kiezen die een duidelijke taakkring heeft en goed past bij het model van gedistribueerde berekeningen. Je kunt mensen begrijpen die proberen alles tegelijk te doen — er is tenslotte voldoende te kiezen. En veel lijkt uiterst interessant vanuit zowel het R&D-perspectief als het economische perspectief. Met behulp van een gedistribueerd netwerk kun je:
- Neurale netwerken trainen
- Signaalsstromen verwerken
- De structuur van eiwitten berekenen
- 3D-scènes renderen
- Hydrodynamica modelleren
- Handelsstrategieën voor aandelenbeurzen testen
Om niet af te dwalen in het opstellen van een lijst met interessante dingen die goed parallel gaan, kiezen we als ons volgende onderwerp gedistribueerde rendering.
Distributed rendering itself is not a new phenomenon. Existing render toolkits have long supported load distribution across different machines; without this, life in the twenty-first century would be rather bleak. However, it is important not to think that the topic is exhausted and that there is nothing left to address. We will examine a specific, relevant issue: the creation of a tool for forming a render network.
Our rendering network is a combination of nodes that need to perform rendering tasks and nodes that have available computing resources to handle rendering. Resource owners will connect their stations to the rendering network to receive and execute rendering tasks using one of the supported render engines. Task providers will work with the network as if it were a cloud, autonomously handling resource distribution, correctness control, risk management, and other challenges.
Thus, we will consider the creation of a framework that should support integration with a range of popular render engines and contain components that provide tools for organizing a network of heterogeneous nodes and managing the flow of tasks.
The economic model for the existence of such a network is not fundamentally important, so we will use a scheme similar to that applied in computations within cryptocurrency networks — resource consumers will send tokens to the providers executing rendering work. It is much more interesting to understand the properties that the framework should possess, for which we will examine the main interaction scenario of network participants.
There are three parties in the network interaction: resource provider, task provider, and network operator (also referred to as the control center, network, etc., throughout the text).
De netwerkaanbieder biedt de leverancier van bronnen een client-applicatie of een besturingssysteemimage met een complete set software die deze op de machine zal installeren waarvan hij de middelen wil beschikbaar stellen. Dit is toegankelijk via een webinterface van een persoonlijk dashboard waarmee hij toegang tot de bron kan instellen en zijn serverlandschap op afstand kan beheren: hardware-instellingen controleren, op afstand configureren en herstarten.
Het netwerkbeheersysteem voert bij het aansluiten van een nieuwe knooppunt een analyse uit van de hardware en de ingestelde toegang parameters, rangschikt het en kent een bepaalde score toe, waarna het in het register van bronnen wordt geplaatst. In de toekomst zullen, voor risicobeheer, de activiteitparameters van het knooppunt worden geanalyseerd en de score van het knooppunt worden aangepast om de stabiliteit van het netwerk te waarborgen. Niemand vindt het prettig als hun scène moet worden gerenderd op krachtige, maar vaak vastlopende oververhitte kaarten?
Een gebruiker die een scène moet renderen, kan twee wegen inslaan: de scène uploaden naar de repository van het netwerk via de webinterface of met een plugin zijn modelleringpakket of geïnstalleerde renderer aansluiten op het netwerk. Tussen de gebruiker en het netwerk wordt een smart contract geïnitialiseerd, waarvan de standaardvoorwaarde voor voltooiing is dat het netwerk het resultaat van de berekening van de scène genereert. De gebruiker kan het proces van de uitvoering van de taak volgen en de parameters ervan beheren via de webinterface van zijn persoonlijke dashboard.
De taak wordt verzonden naar server, waar het volume van de scène en het aantal middelen dat door de opsteller van de taak is aangevraagd wordt geanalyseerd. Daarna wordt het totale volume opgedeeld in delen die zijn aangepast voor berekeningen op de door het netwerk toegewezen hoeveelheid en type middelen. Het algemene idee is dat visualisatie kan worden opgedeeld in vele kleine taken. Engines maken gebruik van dit voordeel door deze taken te verdelen onder verschillende leveranciers van middelen. De eenvoudigste manier is het renderen van kleine delen van de scène, die segmenten worden genoemd. Zodra elk segment klaar is, wordt de lokale taak als voltooid beschouwd en gaat de bron verder met de uitvoering van de volgende onopgeloste taak.
Dus voor de renderer maakt het niet uit of de berekeningen op één machine worden uitgevoerd of op een grid van meerdere afzonderlijke rekenstations. Gedistribueerde rendering voegt simpelweg meer kernen toe aan de pool van middelen die voor de taak worden gebruikt. Via het netwerk ontvangt het alle gegevens die nodig zijn voor het renderen van een segment, rekent deze uit, stuurt het segment terug en gaat verder met de volgende taak. Voor het in de gemeenschappelijke pool van het netwerk komen, ontvangt elk segment een set metadata waarmee de uitvoerende knooppunten de meest geschikte rekenkundige taken kunnen kiezen.
De taken van segmentatie en verdeling van berekeningen moeten worden opgelost, niet alleen met het oog op optimalisatie van de uitvoeringstijd, maar ook vanuit het perspectief van optimaal gebruik van bronnen en energiebesparing, aangezien dit de economische efficiëntie van het netwerk beïnvloedt. In het geval van een ongunstige oplossing zou het verstandiger zijn om een miner op de knoop te plaatsen of deze uit te schakelen om geluidsoverlast en elektriciteitsverbruik te voorkomen.
Maar laten we terugkeren naar het proces. Bij het ontvangen van een taak wordt tussen de pool en de knoop ook een slimme contractvorm opgesteld, die wordt uitgevoerd bij de correcte berekening van het resultaat van de taak. Na het uitvoeren van het contract kan de knoop op de een of andere manier worden beloond.
Het controlecentrum beheert het proces van taakuitvoering, verzamelt de berekeningsresultaten, stuurt onjuiste resultaten voor herverwerking en rangschikt de wachtrij, waarbij de normtijd voor de uitvoering van de taak wordt gevolgd (zodat het niet gebeurt dat het laatste segment door geen enkele knoop wordt opgepakt).
De berekeningsresultaten ondergaan een compositiefase, waarna de gebruiker de renderingresultaten ontvangt en het netwerk kan worden beloond.
Zo ontstaat de functionele samenstelling van het landschapsframework, bedoeld voor het bouwen van gedistribueerde rendering systemen:
- Persoonlijke gebruikersaccounts met webtoegang
- Softwarepakket voor installatie op knooppunten
- Over de beheersystemen:
- Toegangsbeheersubsysteem
- Sub-systeem voor het decomponeren van renderingtaken
- Taakdistributiesubsysteem
- Compositiesubsysteem
- Systeem voor serverlandschapbeheer en netwerktopologie
- Logging- en auditsubsysteem
- Zelf lerend expertsubsysteem
- Rest API of een andere interface voor externe ontwikkelaars
Wat denken jullie? Welke vragen roept dit onderwerp op en welke antwoorden zijn voor jullie interessant?
Bron: habr.com
