Under de senaste åren har nyhetsflöden översvämmats med meddelanden om en ny typ av distribuerade datornätverk som bokstavligen dyker upp från ingenstans och löser (eller snarare försöker lösa) en mängd olika problem - att göra en stad smart, rädda världen från upphovsrätt. överträdare eller vice versa, i hemlighet överföra information eller resurser, fly från -under statlig kontroll i ett eller annat område. Oavsett fält har de alla ett antal gemensamma drag på grund av det faktum att bränslet för deras tillväxt var de algoritmer och tekniker som kom till allmänheten under den senaste boomen av kryptovalutor och relaterade teknologier. Förmodligen var tredje artikel om specialiserade resurser vid den tiden hade ordet "blockchain" i titeln - diskussion om nya mjukvarulösningar och ekonomiska modeller blev den dominerande trenden under en tid, mot bakgrund av vilken andra tillämpningsområden för distribuerade datorsystem var förflyttas till bakgrunden.
Samtidigt såg visionärer och proffs huvudessensen av fenomenet: massiv distribuerad datoranvändning, associerad med konstruktion av nätverk från ett stort antal olika och heterogena deltagare, har nått en ny utvecklingsnivå. Det räcker med att kasta ut hypeämnena från ditt huvud och titta på ämnet från andra sidan: alla dessa nätverk, sammansatta av enorma pooler, som består av tusentals isolerade heterogena deltagare, dök inte upp av sig själva. Entusiaster av kryptorörelsen kunde lösa komplexa problem med datasynkronisering och distribution av resurser och uppgifter på ett nytt sätt, vilket gjorde det möjligt att sätta ihop en liknande massa av utrustning och skapa ett nytt ekosystem utformat för att lösa ett snävt fokuserat problem.
Naturligtvis gick detta inte förbi de team och samhällen som var involverade i utvecklingen av gratis distribuerad datoranvändning, och nya projekt lät inte vänta på sig.
Men trots den betydande ökningen av volymen tillgänglig information om utvecklingen inom området för att bygga nätverk och arbeta med utrustning, måste skaparna av lovande system lösa allvarliga problem.
Den första av dem, hur konstigt det än kan låta, är problemet med att välja riktning.
Riktningen kan vara korrekt, eller så kan den leda till en återvändsgränd - det finns ingen flykt från detta, centraliserade leveranser av klärvoajanta till IT-gemenskapen är fortfarande försenade. Men valet måste göras för att inte hamna i den traditionella fällan att teamet tar ett för brett område och försöker skapa ytterligare ett icke-specialiserat allmänt distribuerat datorprojekt från början. Det verkar som att omfattningen av arbetet inte är så skrämmande, för det mesta behöver vi bara tillämpa befintlig utveckling: kombinera noder till ett nätverk, anpassa algoritmer för att bestämma topologier, utbyta data och övervaka deras konsistens, införa metoder för att rangordna noder och hitta konsensus, och, naturligtvis, skapa bara ditt eget frågespråk och hela språket och datormiljön. Idén om en universell mekanism är mycket frestande och dyker ständigt upp i ett eller annat område, men slutresultatet är fortfarande en av tre saker: den skapade lösningen visar sig antingen vara en begränsad prototyp med ett gäng suspenderade "ToDos" ” i eftersläpningen, eller så blir det ett oanvändbart monster redo att dra iväg alla som rör vid det stinkande ”Turing-träsket”, eller helt enkelt dör säkert av att svanen, kräftorna och gäddan, som drog projektet i en obegriplig riktning, helt enkelt överansträngde sig själva.
Låt oss inte upprepa dumma misstag och välja en riktning som har ett tydligt utbud av uppgifter och som är väl lämpat för den distribuerade beräkningsmodellen. Du kan förstå människor som försöker göra allt på en gång – det finns förstås mycket att välja på. Och många saker ser extremt intressanta ut både ur FoU- och utvecklingssynpunkt och ur ekonomisk synvinkel. Med hjälp av ett distribuerat nätverk kan du:
- Träna neurala nätverk
- Processsignalströmmar
- Beräkna proteinstruktur
- Återge XNUMXD-scener
- Simulera hydrodynamik
- Testa handelsstrategier för börser
För att inte bli medveten om att sammanställa en lista över intressanta saker som är väl parallelliserade kommer vi att välja distribuerad rendering som vårt ytterligare ämne.
Distribuerad rendering i sig är naturligtvis inget nytt. Befintliga renderingsverktyg har länge stöttat lastfördelning över olika maskiner; utan detta skulle det vara ganska tråkigt att leva på det tjugoförsta århundradet. Du bör dock inte tro att ämnet har täckts långt och brett, och det finns inget att göra där - vi kommer att överväga ett separat pressande problem: att skapa ett verktyg för att skapa ett renderingsnätverk.
Vårt renderingsnätverk är en kombination av noder som behöver utföra renderingsuppgifter med noder som har lediga datorresurser för att bearbeta rendering. Resursägare kommer att ansluta sina stationer till renderingsnätverket för att ta emot och utföra renderingsjobb med en av nätverkets renderingsmotorer som stöds. I det här fallet kommer uppgiftsleverantörer att arbeta med nätverket som ett moln, oberoende distribuera resurser, övervaka korrektheten i utförandet, riskhantering och andra problem.
Därför kommer vi att överväga att skapa ett ramverk som bör stödja integration med en uppsättning populära renderingsmotorer och innehålla komponenter som tillhandahåller 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ätverk är inte av grundläggande betydelse, så vi kommer att ta som det initiala schemat ett schema som liknar det som används i beräkningar i kryptovalutanätverk - konsumenter av resursen kommer att skicka tokens till leverantörer som utför renderingsarbetet. Det är mycket mer intressant att förstå vilka egenskaper ett ramverk bör ha, för vilket vi kommer att överväga huvudscenariot för interaktion mellan nätverksdeltagare.
Det finns tre sidor av interaktion i nätverket: resursleverantör, uppgiftsleverantör och nätoperatör (alias kontrollcenter, nätverk, etc. i texten).
Nätoperatören förser resursleverantören med en klientapplikation eller en operativsystemavbildning med en installerad uppsättning programvara, som han kommer att installera på den maskin vars resurser han vill tillhandahålla, och ett personligt konto som är tillgängligt via webbgränssnittet, vilket gör att han kan ställa in åtkomstparametrar till resursen och fjärrhantera sitt serverlandskap: kontrollera hårdvaruparametrar, utför fjärrkonfiguration, starta om.
När en ny nod ansluts analyserar nätverkshanteringssystemet utrustningen och specificerade åtkomstparametrar, rangordnar den, tilldelar en viss klassificering och placerar den i resursregistret. I framtiden, för att hantera risken, kommer nodens aktivitetsparametrar att analyseras och nodens betyg kommer att justeras för att säkerställa nätverkets stabilitet. Ingen kommer att bli nöjd om deras scen skickas att renderas på kraftfulla kort som ofta fryser på grund av överhettning?
En användare som behöver rendera en scen kan gå på två sätt: ladda upp scenen till ett nätverksförråd via webbgränssnittet, eller använd en plugin för att ansluta sitt modelleringspaket eller installerade renderare till nätverket. I detta fall initieras ett smart kontrakt mellan användaren och nätverket, vars standardvillkor för slutförandet är genereringen av resultatet av scenberäkningen av nätverket. Användaren kan övervaka processen för att slutföra en uppgift och hantera dess parametrar via webbgränssnittet för sitt personliga konto.
Uppgiften skickas till servern, där volymen på scenen och antalet resurser som begärs av uppgiftsinitiatorn analyseras, varefter den totala volymen delas upp i delar anpassade för beräkning av antalet och typen av resurser som tilldelas av nätverket . Den allmänna tanken är att visualisering kan delas upp i många små uppgifter. Motorer drar fördel av detta genom att fördela dessa uppgifter mellan flera resursleverantörer. Det enklaste sättet är att återge små delar av scenen som kallas segment. När varje segment är klart anses den lokala uppgiften vara avslutad och resursen går vidare till nästa utestående uppgift.
Det gör alltså ingen skillnad som sådan för renderaren om beräkningarna utförs på en enda maskin eller på ett rutnät med många individuella beräkningsstationer. Distribuerad rendering lägger helt enkelt till fler kärnor till poolen av resurser som används för en uppgift. Genom nätverket tar den emot all data som behövs för att rendera ett segment, beräknar det, skickar tillbaka segmentet och går vidare till nästa uppgift. Innan de går in i den allmänna nätverkspoolen får varje segment en uppsättning metainformation som gör det möjligt för exekverande noder att välja de mest lämpliga beräkningsuppgifterna för dem.
Problemen med segmentering och distribution av beräkningar måste lösas inte bara ur synvinkeln optimering av exekveringstid, utan också ur perspektivet optimal användning av resurser och energibesparing, eftersom nätverkets ekonomiska effektivitet beror på detta. . Om lösningen misslyckas skulle det vara mer tillrådligt att installera en gruvarbetare på noden eller stänga av den så att den inte bullrar och inte slösar med el.
Men låt oss gå tillbaka till processen. När en uppgift tas emot bildas även ett smart kontrakt mellan poolen och noden, vilket exekveras när uppgiftsresultatet är korrekt beräknat. Baserat på resultatet av att uppfylla kontraktet kan noden få en belöning i en eller annan form.
Kontrollcentralen kontrollerar processen för att utföra uppgiften, samla in beräkningsresultat, skicka felaktiga för ombearbetning och rangordning av kön, övervaka standarddeadline för att slutföra uppgiften (så att det inte händer att det sista segmentet inte tas upp av vilken nod som helst).
Resultaten av beräkningarna går igenom sammansättningsstadiet, varefter användaren får renderingsresultaten och nätverket kan få en belöning.
Sålunda framträder den funktionella sammansättningen av ett landskapsramverk utformat för att bygga distribuerade renderingssystem:
- Personliga användarkonton med webbåtkomst
- Programvara för installation på noder
- Genom kontrollsystem:
- Delsystem för åtkomstkontroll
- Delsystem för renderingsuppgiftsupplösning
- Delsystem för uppgiftsfördelning
- Kompositdelsystem
- Undersystem för hantering av serverlandskap och nätverkstopologi
- Loggning och revisionsdelsystem
- Undersystem för lärande experter
- Rest API eller annat gränssnitt för externa utvecklare
Vad tror du? Vilka frågor väcker ämnet och vilka svar är du intresserad av?
Källa: will.com