De afgelopen jaren zijn nieuwsfeeds overspoeld met berichten over een nieuw type gedistribueerde computernetwerken die letterlijk uit het niets opduiken en een breed scala aan problemen oplossen (of beter gezegd proberen op te lossen): een stad slim maken, de wereld redden van auteursrechten overtreders of andersom, die in het geheim informatie of middelen overdragen, ontsnappen aan de controle van de staat in een of ander gebied. Ongeacht het vakgebied hebben ze allemaal een aantal gemeenschappelijke kenmerken vanwege het feit dat de brandstof voor hun groei de algoritmen en technieken waren die tijdens de recente hausse aan cryptocurrencies en aanverwante technologieën naar het publiek kwamen. Waarschijnlijk had elk derde artikel over gespecialiseerde bronnen in die tijd het woord ‘blockchain’ in de titel - discussie over nieuwe softwareoplossingen en economische modellen werd enige tijd de dominante trend, tegen de achtergrond waarvan andere toepassingsgebieden van gedistribueerde computersystemen ontstonden. naar de achtergrond verbannen.
Tegelijkertijd zagen visionairs en professionals de belangrijkste essentie van het fenomeen: massaal gedistribueerd computergebruik, geassocieerd met de constructie van netwerken van een groot aantal ongelijksoortige en heterogene deelnemers, heeft een nieuw ontwikkelingsniveau bereikt. Het is voldoende om de hype-onderwerpen uit je hoofd te gooien en het onderwerp van de andere kant te bekijken: al deze netwerken, samengesteld uit enorme pools, die bestaan uit duizenden geïsoleerde heterogene deelnemers, zijn niet op zichzelf ontstaan. Enthousiastelingen van de cryptobeweging waren in staat om complexe problemen van datasynchronisatie en distributie van bronnen en taken op een nieuwe manier op te lossen, waardoor het mogelijk werd een vergelijkbare hoeveelheid apparatuur samen te stellen en een nieuw ecosysteem te creëren dat was ontworpen om één specifiek probleem op te lossen.
Uiteraard ging dit niet voorbij aan de teams en gemeenschappen die betrokken waren bij de ontwikkeling van gratis gedistribueerd computergebruik, en nieuwe projecten lieten niet lang op zich wachten.
Ondanks de aanzienlijke toename van de hoeveelheid beschikbare informatie over ontwikkelingen op het gebied van het bouwen van netwerken en het werken met apparatuur, zullen de makers van veelbelovende systemen echter serieuze problemen moeten oplossen.
De eerste daarvan is, hoe vreemd het ook mag klinken, het probleem van het kiezen van een richting.
De richting kan de juiste zijn, of het kan op een dood spoor uitlopen; daar is geen ontkomen aan; de gecentraliseerde levering van helderzienden aan de IT-gemeenschap komt nog te laat. Maar de keuze moet zo worden gemaakt dat we niet in de traditionele val trappen waarbij het team een te breed terrein bestrijkt en vanaf het begin probeert een ander niet-gespecialiseerd algemeen gedistribueerd computerproject op te zetten. Het lijkt erop dat de reikwijdte van het werk niet zo eng is, voor het grootste deel hoeven we alleen maar bestaande ontwikkelingen toe te passen: knooppunten combineren tot een netwerk, algoritmen aanpassen voor het bepalen van topologieën, gegevens uitwisselen en hun consistentie bewaken, methoden introduceren voor het rangschikken van knooppunten en het vinden consensus, en natuurlijk creëer je gewoon je eigen zoektaal en de hele taal- en computeromgeving. Het idee van een universeel mechanisme is erg verleidelijk en duikt voortdurend op op een of ander gebied, maar het eindresultaat is nog steeds een van drie dingen: de gecreëerde oplossing blijkt óf een beperkt prototype te zijn met een heleboel hangende ‘ ToDos” in de achterstand, of het wordt een onbruikbaar monster dat klaar staat om iedereen weg te slepen die het stinkende “Turing-moeras” aanraakt, of gewoon veilig sterft door het feit dat de zwaan, rivierkreeft en snoek, die het project in een onbegrijpelijke richting trokken , hebben zichzelf eenvoudigweg overbelast.
Laten we geen domme fouten herhalen en een richting kiezen die een duidelijk takenpakket heeft en goed past bij het gedistribueerde computermodel. Je kunt mensen begrijpen die alles in één keer proberen te doen - er is natuurlijk genoeg om uit te kiezen. En veel dingen zien er buitengewoon interessant uit, zowel vanuit het oogpunt van R&D en ontwikkeling, als vanuit het oogpunt van de economie. Met behulp van een gedistribueerd netwerk kunt u:
- Train neurale netwerken
- Verwerk signaalstromen
- Bereken de eiwitstructuur
- Geef XNUMXD-scènes weer
- Simuleer de hydrodynamica
- Test handelsstrategieën voor aandelenbeurzen
Om ons niet te laten meeslepen door het samenstellen van een lijst met interessante dingen die goed geparalleliseerd zijn, zullen we gedistribueerde weergave als ons verdere onderwerp kiezen.
Gedistribueerde weergave op zichzelf is natuurlijk niets nieuws. Bestaande rendertoolkits ondersteunen al lang de verdeling van de belasting over verschillende machines; zonder dit zou het leven in de XNUMXe eeuw behoorlijk triest zijn. Je moet echter niet denken dat het onderwerp wijd en zijd is behandeld, en dat er niets aan te doen is - we zullen een apart urgent probleem overwegen: het creëren van een tool voor het creëren van een rendernetwerk.
Ons renderingnetwerk is een combinatie van knooppunten die renderingtaken moeten uitvoeren met knooppunten die over vrije computerbronnen beschikken om het renderen te verwerken. Eigenaars van bronnen zullen hun stations verbinden met het rendernetwerk om rendertaken te ontvangen en uit te voeren met behulp van een van de ondersteunde render-engines van het netwerk. In dit geval zullen taakaanbieders met het netwerk als een cloud werken, onafhankelijk bronnen distribueren, toezicht houden op de juistheid van de uitvoering, risicobeheer en andere problemen.
We zullen dus overwegen een raamwerk te creëren dat de integratie met een reeks populaire render-engines moet ondersteunen en componenten moet bevatten die tools bieden voor het organiseren van een netwerk van heterogene knooppunten en het beheren van de stroom van taken.
Het economische model van het bestaan van een dergelijk netwerk is niet van fundamenteel belang, dus zullen we als aanvankelijk schema een schema nemen dat vergelijkbaar is met het schema dat wordt gebruikt bij berekeningen in cryptocurrency-netwerken: consumenten van de bron zullen tokens sturen naar leveranciers die het weergavewerk uitvoeren. Het is veel interessanter om te begrijpen welke eigenschappen een raamwerk zou moeten hebben, waarvoor we het hoofdscenario van interactie tussen netwerkdeelnemers zullen beschouwen.
Er zijn drie kanten van interactie in het netwerk: resource provider, taakprovider en netwerkoperator (ook wel controlecentrum, netwerk, etc. genoemd in de tekst).
De netwerkoperator voorziet de resourceprovider van een clienttoepassing of een besturingssysteemimage met een geïmplementeerde set software, die hij zal installeren op de machine waarvan hij de bronnen wil verstrekken, en een persoonlijk account dat toegankelijk is via de webinterface, waardoor hij stel toegangsparameters in voor de bron en beheer zijn serverlandschap op afstand: controleer hardwareparameters, voer configuratie op afstand uit, start opnieuw op.
Wanneer een nieuw knooppunt wordt aangesloten, analyseert het netwerkbeheersysteem de apparatuur en specificeert de toegangsparameters, rangschikt deze, kent een bepaalde beoordeling toe en plaatst deze in het bronnenregister. Om het risico te beheersen zullen in de toekomst de activiteitsparameters van het knooppunt worden geanalyseerd en zal de rating van het knooppunt worden aangepast om de stabiliteit van het netwerk te garanderen. Niemand zal blij zijn als hun scène wordt weergegeven op krachtige kaarten die vaak vastlopen als gevolg van oververhitting?
Een gebruiker die een scène moet renderen kan op twee manieren: upload de scène naar een netwerkrepository via de webinterface, of gebruik een plug-in om zijn modelleringspakket of geïnstalleerde renderer met het netwerk te verbinden. In dit geval wordt een slim contract geïnitieerd tussen de gebruiker en het netwerk, waarvan de standaardvoorwaarde voor voltooiing het genereren van het resultaat van de scèneberekening door het netwerk is. De gebruiker kan het proces van het voltooien van een taak volgen en de parameters ervan beheren via de webinterface van zijn persoonlijke account.
De taak wordt naar de server gestuurd, waar het volume van de scène en het aantal door de taakinitiator aangevraagde bronnen worden geanalyseerd, waarna het totale volume wordt opgesplitst in delen die zijn aangepast voor berekening op basis van het aantal en het type bronnen dat door het netwerk is toegewezen. . Het algemene idee is dat visualisatie kan worden opgesplitst in veel kleine taken. Engines profiteren hiervan door deze taken over meerdere resourceproviders te verdelen. De eenvoudigste manier is om kleine delen van de scène, segmenten genoemd, weer te geven. Wanneer elk segment klaar is, wordt de lokale taak als voltooid beschouwd en gaat de resource door naar de volgende openstaande taak.
Voor de renderer maakt het dus op zichzelf geen verschil of de berekeningen op één enkele machine worden uitgevoerd of op een raster van veel individuele rekenstations. Gedistribueerde weergave voegt eenvoudigweg meer kernen toe aan de pool van bronnen die voor een taak worden gebruikt. Via het netwerk ontvangt het alle gegevens die nodig zijn om een segment weer te geven, berekent het, stuurt dat segment terug en gaat verder met de volgende taak. Voordat elk segment de algemene netwerkpool binnengaat, ontvangt het een set meta-informatie waarmee uitvoerende knooppunten de meest geschikte computertaken voor hen kunnen selecteren.
De problemen van segmentatie en distributie van berekeningen moeten niet alleen worden opgelost vanuit het oogpunt van optimalisatie van de uitvoeringstijd, maar ook vanuit het oogpunt van optimaal gebruik van hulpbronnen en energiebesparing, aangezien de economische efficiëntie van het netwerk hiervan afhangt . Als de oplossing niet succesvol is, is het beter om een miner op het knooppunt te installeren of uit te schakelen, zodat deze geen geluid maakt en geen elektriciteit verspilt.
Laten we echter teruggaan naar het proces. Wanneer een taak wordt ontvangen, wordt er ook een slim contract gevormd tussen de pool en het knooppunt, dat wordt uitgevoerd wanneer het taakresultaat correct is berekend. Op basis van de resultaten van het vervullen van het contract kan het knooppunt een of andere vorm van beloning ontvangen.
Het controlecentrum controleert het proces van taakuitvoering, verzamelt berekeningsresultaten, verzendt onjuiste resultaten voor herverwerking en rangschikt de wachtrij, bewaakt de standaarddeadline voor het voltooien van de taak (zodat het niet gebeurt dat het laatste segment niet wordt ingenomen door elk knooppunt).
De resultaten van de berekeningen doorlopen de compositing-fase, waarna de gebruiker de renderingresultaten ontvangt en het netwerk een beloning kan ontvangen.
Zo ontstaat de functionele samenstelling van een landschapsraamwerk ontworpen voor het bouwen van gedistribueerde weergavesystemen:
- Persoonlijke gebruikersaccounts met webtoegang
- Softwarekit voor installatie op knooppunten
- Via besturingssysteem:
- Subsysteem voor toegangscontrole
- Subsysteem voor het ontleden van taken
- Subsysteem voor taakverdeling
- Composiet subsysteem
- Subsysteem voor serverlandschap en netwerktopologiebeheer
- Subsysteem voor logboekregistratie en audit
- Subsysteem van leerexpert
- Rest API of andere interface voor externe ontwikkelaars
Wat denk je? Welke vragen roept het onderwerp op en in welke antwoorden bent u geïnteresseerd?
Bron: www.habr.com