De siste årene har nyhetsfeeds blitt oversvømmet med meldinger om en ny type distribuerte datanettverk som bokstavelig talt dukker opp fra ingensteds, og løser (eller rettere sagt, prøver å løse) en lang rekke problemer – å gjøre en by smart, redde verden fra opphavsrett. krenkere eller omvendt, hemmelig overføring av informasjon eller ressurser, rømming fra -under statlig kontroll i ett eller annet område. Uavhengig av felt har de alle en rekke fellestrekk på grunn av det faktum at drivstoffet for veksten deres var algoritmene og teknikkene som kom til publikum under den nylige boomen i kryptovalutaer og relaterte teknologier. Sannsynligvis hver tredje artikkel om spesialiserte ressurser på den tiden hadde ordet "blockchain" i tittelen - diskusjon om nye programvareløsninger og økonomiske modeller ble den dominerende trenden i noen tid, på bakgrunn av hvilke andre anvendelsesområder for distribuerte datasystemer var henvist til bakgrunnen.
Samtidig så visjonære og fagfolk hovedessensen av fenomenet: massiv distribuert databehandling, assosiert med bygging av nettverk fra et stort antall forskjellige og heterogene deltakere, har nådd et nytt utviklingsnivå. Det er nok å kaste ut hype-emnene fra hodet og se på emnet fra den andre siden: alle disse nettverkene, satt sammen fra enorme bassenger, som består av tusenvis av isolerte heterogene deltakere, dukket ikke opp av seg selv. Entusiaster av kryptobevegelsen var i stand til å løse komplekse problemer med datasynkronisering og distribusjon av ressurser og oppgaver på en ny måte, noe som gjorde det mulig å sette sammen en lignende masse utstyr og lage et nytt økosystem designet for å løse ett smalt fokusert problem.
Dette gikk selvfølgelig ikke forbi teamene og lokalsamfunnene som var involvert i utviklingen av gratis distribuert databehandling, og nye prosjekter lot ikke vente på seg.
Til tross for den betydelige økningen i volumet av tilgjengelig informasjon om utviklingen innen bygging av nettverk og arbeid med utstyr, vil skaperne av lovende systemer måtte løse alvorlige problemer.
Den første av dem, uansett hvor merkelig det kan høres ut, er problemet med å velge retning.
Retningen kan være riktig, eller den kan føre til en blindvei - det er ingen unnslippe fra dette; sentraliserte forsyninger av klarsynte til IT-samfunnet er fortsatt sent ute. Men valget må tas for ikke å falle i den tradisjonelle fellen med at teamet tar et for bredt område og prøver å lage et annet ikke-spesialisert generelt distribuert dataprosjekt fra starten av. Det ser ut til at omfanget av arbeidet ikke er så skummelt, for det meste trenger vi bare å bruke eksisterende utviklinger: kombinere noder til et nettverk, tilpasse algoritmer for å bestemme topologier, utveksle data og overvåke deres konsistens, introdusere metoder for å rangere noder og finne konsensus, og selvfølgelig bare lag ditt eget spørringsspråk og hele språket og datamiljøet. Ideen om en universell mekanisme er veldig fristende og dukker stadig opp i et eller annet område, men sluttresultatet er fortsatt en av tre ting: den opprettede løsningen viser seg enten å være en begrenset prototype med en haug med suspenderte "ToDos" ” i etterslepet, eller det blir et ubrukelig monster klar til å dra vekk alle som berører den illeluktende «Turing-sumpen», eller rett og slett dør trygt av at svanen, krepsen og gjeddene, som trakk prosjektet i en uforståelig retning, rett og slett overanstrengt seg.
La oss ikke gjenta dumme feil og velge en retning som har et klart spekter av oppgaver og som passer godt til den distribuerte datamodellen. Du kan forstå folk som prøver å gjøre alt på en gang – selvfølgelig er det mye å velge mellom. Og mye ser ekstremt interessant ut både fra et FoU- og utviklingssynspunkt, og fra et økonomisk synspunkt. Ved å bruke et distribuert nettverk kan du:
- Tren nevrale nettverk
- Behandle signalstrømmer
- Beregn proteinstruktur
- Gjengi XNUMXD-scener
- Simuler hydrodynamikk
- Test handelsstrategier for børser
For ikke å la oss rive med av å lage en liste over interessante ting som er godt parallellisert, vil vi velge distribuert gjengivelse som vårt videre tema.
Distribuert gjengivelse i seg selv er selvfølgelig ikke noe nytt. Eksisterende gjengivelsesverktøysett har lenge støttet lastfordeling på tvers av forskjellige maskiner; uten dette ville det vært ganske trist å leve i det tjueførste århundre. Du bør imidlertid ikke tro at emnet har blitt dekket vidt og bredt, og det er ingenting å gjøre der - vi vil vurdere et eget presserende problem: å lage et verktøy for å lage et gjengivelsesnettverk.
Vårt gjengivelsesnettverk er en kombinasjon av noder som trenger å utføre gjengivelsesoppgaver med noder som har ledige dataressurser for å behandle gjengivelse. Ressurseiere vil koble stasjonene sine til gjengivelsesnettverket for å motta og utføre gjengivelsesjobber ved å bruke en av nettverkets støttede gjengivelsesmotorer. I dette tilfellet vil oppgaveleverandører jobbe med nettverket som om det var en sky, uavhengig distribuere ressurser, overvåke riktigheten av utførelse, håndtere risikoer og andre problemer.
Derfor vil vi vurdere å lage et rammeverk som skal støtte integrasjon med et sett med populære gjengivelsesmotorer og inneholde komponenter som gir verktøy for å organisere et nettverk av heterogene noder og administrere flyten av oppgaver.
Den økonomiske modellen for eksistensen av et slikt nettverk er ikke av grunnleggende betydning, så vi vil ta som den første ordningen en ordning som ligner den som brukes i beregninger i kryptovalutanettverk - forbrukere av ressursen vil sende tokens til leverandører som utfører gjengivelsesarbeidet. Det er mye mer interessant å forstå hvilke egenskaper et rammeverk skal ha, som vi vil vurdere hovedscenarioet for interaksjon mellom nettverksdeltakere for.
Det er tre sider av samhandling i nettverket: ressursleverandør, oppgaveleverandør og nettverksoperatør (alias kontrollsenter, nettverk osv. i teksten).
Nettverksoperatøren gir ressursleverandøren en klientapplikasjon eller et operativsystembilde med et installert sett med programvare, som han vil installere på maskinen hvis ressurser han ønsker å tilby, og en personlig konto som er tilgjengelig via nettgrensesnittet, slik at han kan angi tilgangsparametere til ressursen og fjernadministrer serverlandskapet hans: kontroller maskinvareparametere, utfør ekstern konfigurasjon, start på nytt.
Når en ny node er tilkoblet, analyserer nettverksstyringssystemet utstyret og spesifiserte tilgangsparametere, rangerer det, tildeler en bestemt vurdering og plasserer det i ressursregisteret. I fremtiden, for å håndtere risikoen, vil nodens aktivitetsparametere bli analysert, og nodens rating vil bli justert for å sikre stabiliteten til nettverket. Ingen vil være fornøyd hvis scenen deres sendes til gjengivelse på kraftige kort som ofte fryser på grunn av overoppheting?
En bruker som trenger å gjengi en scene kan gå to veier: laste opp scenen til et nettverksdepot via nettgrensesnittet, eller bruke en plugin for å koble sin modelleringspakke eller installerte gjengiver til nettverket. I dette tilfellet initieres en smart kontrakt mellom brukeren og nettverket, standardbetingelsen for fullføringen er generering av resultatet av sceneberegningen av nettverket. Brukeren kan overvåke prosessen med å fullføre en oppgave og administrere dens parametere gjennom nettgrensesnittet til sin personlige konto.
Oppgaven sendes til serveren, hvor volumet på scenen og antall ressurser etterspørres av oppgaveinitiatoren analyseres, hvoretter det totale volumet dekomponeres i deler tilpasset beregning på antall og type ressurser som er allokert av nettverket . Den generelle ideen er at visualisering kan brytes ned i mange små oppgaver. Motorer drar nytte av dette ved å fordele disse oppgavene mellom flere ressursleverandører. Den enkleste måten er å gjengi små deler av scenen kalt segmenter. Når hvert segment er klart, anses den lokale oppgaven som fullført, og ressursen går videre til neste utestående oppgave.
Dermed spiller det ingen rolle som sådan for gjengiveren om beregningene utføres på en enkelt maskin eller på et rutenett med mange individuelle datastasjoner. Distribuert gjengivelse legger ganske enkelt til flere kjerner til ressursbasen som brukes til en oppgave. Gjennom nettverket mottar den alle dataene som trengs for å gjengi et segment, beregner det, sender det segmentet tilbake og går videre til neste oppgave. Før de går inn i den generelle nettverkspoolen, mottar hvert segment et sett med metainformasjon som lar utførende noder velge de best egnede dataoppgavene for dem.
Problemene med segmentering og distribusjon av beregninger må løses ikke bare fra synspunktet om optimalisering av utførelsestid, men også fra synspunktet om optimal ressursbruk og energisparing, siden den økonomiske effektiviteten til nettverket avhenger av dette. . Hvis løsningen ikke lykkes, vil det være mer tilrådelig å installere en gruvearbeider på noden eller slå den av slik at den ikke lager støy og ikke sløser med strøm.
La oss imidlertid gå tilbake til prosessen. Når en oppgave mottas, dannes det også en smart kontrakt mellom bassenget og noden, som utføres når oppgaveresultatet er korrekt beregnet. Basert på resultatene av å oppfylle kontrakten, kan noden motta en belønning i en eller annen form.
Kontrollsenteret kontrollerer prosessen med oppgaveutførelse, samler inn beregningsresultater, sender ukorrekte for reprosessering og rangering av køen, overvåker standard frist for å fullføre oppgaven (slik at det ikke skjer at siste segment ikke tas opp innen kl. hvilken som helst node).
Resultatene av beregningene går gjennom komposisjonsfasen, hvoretter brukeren mottar gjengivelsesresultatene, og nettverket kan motta en belønning.
Dermed fremkommer den funksjonelle sammensetningen av et landskapsrammeverk designet for å bygge distribuerte gjengivelsessystemer:
- Personlige brukerkontoer med nettilgang
- Programvaresett for installasjon på noder
- Etter kontrollsystem:
- Delsystem for tilgangskontroll
- Gjengivelsesoppgavedekomponeringsdelsystem
- Undersystem for oppgavefordeling
- Komposittundersystem
- Undersystem for administrasjon av serverlandskap og nettverkstopologi
- Logging og revisjonsdelsystem
- Undersystem for læringsekspert
- Rest API eller annet grensesnitt for eksterne utviklere
Hva tror du? Hvilke spørsmål reiser temaet og hvilke svar er du interessert i?
Kilde: www.habr.com