Under de senaste Ă„ren har nyhetsflöden fyllts med meddelanden om nya typer av distribuerade datanĂ€tverk som bokstavligen dyker upp ur ingenstans och försöker lösa en rad olika problem â att göra staden smart, rĂ€dda vĂ€rlden frĂ„n upphovsrĂ€ttsbrott eller tvĂ€rtom, hemligt överföra information eller resurser, fly frĂ„n statens kontroll inom olika omrĂ„den. Oavsett omrĂ„de har de alla gemensamma drag som beror pĂ„ att den vĂ€xtkraft som drivit dem kommer frĂ„n algoritmer och metoder som blivit mainstream under den senaste uppgĂ„ngen av kryptovalutor och relaterad teknologi. Kanske hade var tredje artikel pĂ„ branschresurser under den tiden ordet "blockkedja" i titeln â diskussionen om nya programlösningar och ekonomiska modeller blev en dominerande trend, medan andra tillĂ€mpningar av distribuerade datorsystem hamnade i skuggan.
Samtidigt insÄg visionÀrer och experter den grundlÀggande essensen av fenomenet: massiva distribuerade datorkapaciteter, kopplade till byggandet av nÀtverk av ett stort antal spridda och heterogena deltagare, har nÄtt en ny nivÄ av utveckling. Det rÀcker med att slÄ bort de hype-liknande Àmnena och se pÄ saken frÄn en annan vinkel: alla dessa nÀtverk, som bestÄr av stora pooler med tusentals isolerade och heterogena deltagare, har inte uppstÄtt av en slump. Entusiaster inom kryptorörelsen har lyckats lösa komplexa problem med datasykronisering och resurs- och uppgiftsfördelning pÄ ett nytt sÀtt, vilket har möjliggjort sammanstÀllningen av en sÄdan massa utrustning och skapandet av ett nytt ekosystem avsett för att lösa ett specifikt uppdrag.
Naturligtvis har detta inte gÄtt obemÀrkt förbi de team och gemenskaper som arbetar med att utveckla fria distribuerade datorsystem, och nya projekt lÀt inte vÀnta pÄ sig.
Men trots den betydande ökning av tillgÀnglig information om framstegen inom nÀtverksbyggnad och arbete med utrustning, kommer skaparna av lovande system att behöva hantera allvarliga problem.
Det första av dessa, hur konstigt det Àn kan lÄta, Àr problemet med att vÀlja riktning.
Riktningen kan vara rĂ€tt eller leda till ett dödlĂ€ge â det gĂ„r inte att undkomma det, centrala leveranser av spĂ„mĂ€n till IT-gemenskapen dröjer fortfarande. Men vi mĂ„ste göra ett val för att undvika den traditionella fĂ€llan dĂ€r teamet tar pĂ„ sig ett alltför brett omrĂ„de och försöker skapa Ă€nnu ett ospecialiserat projekt för distribuerad berĂ€kning. Det verkar som att arbetsfronten inte Ă€r sĂ„ skrĂ€mmande; det handlar mest om att tillĂ€mpa befintliga lösningar: koppla samman noder i ett nĂ€tverk, anpassa algoritmer för att bestĂ€mma topologier, datadelning och kontroll av deras konsistens, implementera metoder för rangordning av noder och nĂ„ konsensus, och naturligtvis bara skapa sitt eget frĂ„gesprĂ„k och hela den sprĂ„kliga och berĂ€kningsmĂ€ssiga miljön. IdĂ©n om en universell mekanism Ă€r mycket lockande och dyker stĂ€ndigt upp inom olika omrĂ„den, men resultatet blir fortfarande ett av tre: den skapade lösningen visar sig antingen vara en begrĂ€nsad prototyp med massor av hĂ€ngande
LĂ„t oss inte upprepa dumma misstag och vĂ€lja en riktning som har en tydlig uppsĂ€ttning uppgifter och passar bra i modellen för distribuerad berĂ€kning. Man kan förstĂ„ folk som försöker göra allt pĂ„ en gĂ„ng â det finns faktiskt mycket att vĂ€lja mellan. Och mycket ser extremt intressant ut bĂ„de ur R&D- och utvecklingssynvinkel, samt ur ekonomisk synvinkel. Genom en distribuerad nĂ€tverk kan man:
- TrÀna neurala nÀtverk
- Behandla signalflöden
- BerÀkna proteinstrukturer
- Genomföra rendering av tredimensionella scener
- Modellera hydrodynamik
- Testa handelsstrategier för aktiemarknader
För att inte bli allt för försjunken i att skapa en lista över intressanta saker som passar bra för parallell bearbetning, lÄt oss vÀlja distribuerad rendering som vÄrt nÀsta Àmne.
SjĂ€lva distribuerad rendering Ă€r givetvis inget nytt fenomen. Befintliga renderingsverktyg har lĂ€nge stöd för belastningsfördelning över olika maskiner; utan detta skulle livet i det tjugoförsta Ă„rhundradet vara ganska trist. Men man ska inte tro att Ă€mnet Ă€r helt utforskat och att det inte finns nĂ„got mer att göra â vi kommer att undersöka ett specifikt aktuellt problem: att skapa ett verktyg för att etablera ett renderingsnĂ€tverk.
VÄrt renderingsnÀtverk Àr en sammanslutning av noder som behöver utföra renderingsuppgifter, pÄ noder som har lediga berÀkningsresurser för att hantera rendering. ResursÀgarna kommer att koppla sina stationer till renderingsnÀtverket för att ta emot och utföra renderingsuppgifter med hjÀlp av en av de renderingsmotorer som stöds av nÀtverket. Uppgiftsleverantörerna kommer att arbeta med nÀtverket som en egen cloud-lösning, som sjÀlvstÀndigt hanterar resursfördelning, övervakning av korrekt utförande, riskhantering och andra problem.
DÀrför kommer vi att fokusera pÄ att skapa ett ramverk som ska stödja integrationen med ett antal populÀra renderingsmotorer och innehÄlla komponenter som ger verktyg för att organisera ett nÀtverk av heterogena noder och hantera flödet av uppgifter.
Den ekonomiska modellen för existensen av ett sĂ„dant nĂ€t Ă€r inte avgörande, sĂ„ vi antar en schematisk liknande den som anvĂ€nds i berĂ€kningar i kryptovalutanĂ€tverk â resurskonsumenterna kommer att skicka tokens till leverantörerna som utför renderingsarbetet. Det Ă€r mycket mer intressant att förstĂ„ vilka egenskaper ramverket mĂ„ste ha, vilket vi kommer att göra genom att titta pĂ„ huvudscenariot för interaktion mellan nĂ€tverksdeltagarna.
Det finns tre parter i interaktionen i nÀtverket: resursleverantör, uppgiftsleverantör och nÀtverksoperatör (Àven kallad kontrollcentrum, nÀt och sÄ vidare i texten).
NÀtverksoperatören tillhandahÄller leverantören av resurser en klientapplikation eller en avbildning av operativsystemet med en uppsÀttning program installerad, som denne ska installera pÄ maskinen vars resurser hen vill tillhandahÄlla. Detta hanteras via ett webbgrÀnssnitt för en personlig portal som gör det möjligt att ange Ätkomstparameter till resursen och fjÀrradministrera sin servermiljö: kontrollera hÄrdvaruparametrar, utföra fjÀrrinstÀllningar och starta om.
NÀtverksstyrsystemet genomför en analys av hÄrdvaran och de angivna Ätkomstparametrarna nÀr en ny nod ansluts, rangordnar den och tilldelar ett visst betyg samt registrerar den i resursregistret. I framtiden kommer aktivitetsparametrarna för noden att analyseras för att hantera riskerna, och nodens betyg justeras för att sÀkerstÀlla nÀtverkets stabilitet. Ingen vill att deras scen ska skickas för renderering till kraftfulla men ofta överhettade kort.
En anvÀndare som behöver rendera en scen kan vÀlja mellan tvÄ alternativ: ladda upp scenen till nÀtverksarkivet via webbgrÀnssnittet eller ansluta sitt modelleringspaket eller installerade renderer till nÀtverket via ett plugin. Mellan anvÀndaren och nÀtverket initieras ett smart kontrakt, vars standardvillkor för avslut Àr att nÀtverket genererar resultatet av scenberÀkningen. AnvÀndaren kan övervaka uppgiftens utförande och styra dess parametrar genom webbgrÀnssnittet i sin personliga portal.
Uppgiften tas emot av server, dÀr volymen av scenen och mÀngden resurser som begÀrts av uppdragets initiator analyseras. Detta leder till att den totala volymen delas upp i delar som Àr anpassade för berÀkning pÄ den mÀngd och typ av resurser som nÀtverket tillhandahÄller. Den övergripande idén Àr att visualiseringen kan brytas ner i mÄnga smÄ uppgifter. Renderingsmotorer utnyttjar denna fördel genom att fördela dessa uppgifter bland mÄnga resursleverantörer. Det enklaste sÀttet Àr att rendera smÄ delar av scenen, kallade segment. NÀr varje segment Àr klart anses den lokala uppgiften vara fullgjord, och resursen gÄr vidare till att utföra nÀsta av de kvarstÄende.
För renderaren spelar det ingen roll om berÀkningarna utförs pÄ en enskild maskin eller pÄ ett grid av flera separata berÀkningsstationer. Distribuerad rendering lÀgger helt enkelt till fler kÀrnor i resurspoolen som anvÀnds för uppgiften. Genom nÀtverket fÄr den all information som behövs för att rita segmentet, berÀknar det, skickar tillbaka segmentet och gÄr vidare till nÀsta uppgift. Innan ett segment gÄr in i den gemensamma nÀtpoolen fÄr det en uppsÀttning metadata som gör att exekveringsnoder kan vÀlja de mest lÀmpliga berÀkningsuppgifterna för dem.
Segmenterings- och berÀkningsdistributionsuppgifterna mÄste dÀrför lösas inte bara ur perspektivet av att optimera körtiden, utan ocksÄ ur perspektivet av optimal resursanvÀndning och energibesparing, eftersom detta pÄverkar den ekonomiska effektiviteten i nÀtverket. I hÀndelse av ett misslyckat beslut skulle det vara mer ÀndamÄlsenligt att installera en miner pÄ noden eller stÀnga av den för att undvika buller och elförbrukning.
Men lÄt oss ÄtergÄ till processen. NÀr en uppgift tas emot mellan poolen och noden upprÀttas ocksÄ ett smart kontrakt som verkstÀlls nÀr resultatet av uppgiften berÀknas korrekt. Efter att kontraktet har genomförts kan noden fÄ belöning i nÄgon form.
Kontrollcentralen övervakar processen för att utföra uppgiften, samlar in berÀkningsresultat, skickar tillbaka ogiltiga för nya berÀkningar och rangordnar kön, medan den övervakar den normala tidsramen för att slutföra uppgiften (sÄ att det inte hÀnder att det sista segmentet inte tas upp av nÄgon nod).
BerÀkningsresultaten gÄr igenom en komposition, efter vilket anvÀndaren fÄr renderingens resultat, medan nÀtverket kan fÄ belöning.
SÄledes framtrÀder den funktionella strukturen för det landskapsramverk som Àr avsett för att bygga system för distribuerad rendering:
- AnvÀndarens personliga konton med webbadkomst
- Programvarupaket för installation pÄ noder
- För styrsystem:
- Ă tkomstkontrollsystem
- Deluppgiftssystem för rendering
- Uppgiftsdistributionssystem
- Kompositionssystem
- System för hantering av serverlandskap och nÀtverkstopologi
- Logg- och revisionssystem
- SjÀlvlÀrande expertundersystem
- Rest API eller annat grÀnssnitt för externa utvecklare
Vad tycker ni? Vilka frÄgor vÀcker Àmnet och vilka svar Àr ni intresserade av?
KĂ€lla: habr.com
