Viimastel aastatel on uudistevoogudes ilmunud teateid uut tüüpi hajusate arvutusvõrkude kohta, mis näivad tulevat kõrvalt, lahendades (või pigem püüdes lahendada) kõige mitmekesisemaid ülesandeid — muuta linn nutikaks, päästa maailm autoriõiguste rikkujatest või vastupidi, salaja edastada teavet või ressursse, põgeneda riigi kontrolli alt mistahes valdkonnas. Ükskõik, millises valdkonnas need tegutsevad, omavad nad kõiki mitmeid ühiseid jooni, mis tulenevad sellest, et nende kasvu kütuseks on olnud algoritmid ja meetodid, mis said laialdaselt kasutusele viimase krüptovaluutade ja seotud tehnoloogiate buumi ajal. Tõenäoliselt oli iga kolmas artikkel oma pealkirjas sõna "blokkchain", arutelu uusi tarkvaralahendusi ja majandusmudeleid sai mõneks ajaks dominiivseks trendiks, mille taustal liigitatud hajutatud arvutuse süsteemide teised rakendused jäid tagaplaanile.
Samas nägid visionäärid ja professionaalid nähtuse põhiolemust: massilised hajutatud arvutused, mis on seotud suurte arvukate ja erinevate osalejate võrkude loomisega, on jõudnud uuele arengutasemele. Piisab, et heita kõrvale hype-teemad ja vaadata asjadele teise nurga alt: kõik need võrgud, mis koosnevad tohututest basseinidest, kus asub tuhandeid eraldiseisvaid ja erinevaid osalejaid, ei ole ilmnenud iseenesest. Krüptoliikumise entusiastid on suutnud uuel viisil lahendada keerulisi andmete sünkroniseerimise ja ressursside jaotamise probleeme, mis võimaldas kokku koguda sellise hulga seadmeid ja luua uue ökosüsteemi, mis on mõeldud ühe kitsalt suunatud ülesande täitmiseks.
Muidugi ei jäänud see tähelepanuta meeskondade ja kogukondade poolt, kes tegelevad vabade hajutatud arvutuste arendamisega, ning uued projektid ei lasknud end kaua oodata.
Kuid hoolimata kergest vähenemisest kergesti kättesaadavatel andmetel võrgu ja seadmete arendamise kohta, peavad tulevaste süsteemide loojad lahendama tõsiseid probleeme.
Esimene neist, kuigi see kõlab kummaliselt, on suuna valimise probleem.
Suund võib olla õige, kuid võib viia ka ummikusse — sellest ei pääse, keskne ennustajate pakkumine IT-kommuunis jääb endiselt hiljaks. Kuid valik tuleks teha, et mitte sattuda traditsioonilisse lõksu, kus meeskond võtab liiga laia valdkonna ja üritab algusest peale luua veel ühte ebaspetsialiseeritud jaotatud arvutamise projekti. Tundub, et tööde rind ei ole nii hirmutav, tuleb enamikul juhtudel lihtsalt rakendada olemasolevaid saavutusi: ühendada sõlmed võrguks, kohandada topoloogia määramise, andmevahetuse ja nende järjepidevuse kontrollimise algoritme, rakendada sõlmede reitingumeetodeid ja konsensuse leidmise algoritme, no ja muidugi, luua oma päringukeel ja kogu keele- ja arvutuslik keskkond. Üks universaalse mehhanismi idee on väga ahvatlev ja kerkib pidevalt esile ühes või teises valdkonnas, kuid lõpus saadakse ikkagi üks kolmest: loodud lahendus osutub tegelikult piiratud prototüübiks, millel on hunnik kiiresti vananevaid “ToDo” teateid, või muutub kasutatamatuks monstumiks, mis on valmis endale meelitama igaühe, kes sellele läheneb, haisvasse “türiingude mudasse”, või sureb lihtsalt õnneks ära, sest projekti tõukavad tundmatus suunas luike, vähid ja haugid on lihtsalt väsinud.
Ärge kordage rumalaid vigu ja valige suund, millel on arusaadav ülesande ring ja mis sobib hästi jaotatud arvutamise mudelisse. Võib mõista inimesi, kes üritavad teha kõike ja otsekohe — valid paremaid võimalusi on palju. Ja palju paistab üsnagi huvitav nii R&D kui ka arenduse seisukohalt, samuti majanduslikult. Jaotatud võrgu abil on võimalik:
- Koolitada närvivõrke
- Töötleda signaalivooge
- Arvutada valkude struktuuri
- Teha kolmemõõtmeliste stseenide renderdamist
- Modelleerida hüdrodünaamikat
- Testida kauplemisstrateegiaid börsidel
Et mitte liialdada huvitavate asjade loetlemisega, valime meie edasise teema jaotatud renderdamine.
Jaotatud renderdamine iseenesest ei ole muidugi midagi uut. Olemasolevad renderdamise tööriistad on juba ammu toetanud koormuse jaotamist erinevate masinate vahel; ilma selleta oleks elu XXI sajandil üsna kurb. Siiski ei maksa arvata, et teema on ammendunud ja seal pole midagi uurida - käsitleme ühte olulist probleemi: tööriista loomine renderdamise võrgu loomiseks.
Meie renderdamise võrk on sõlmede kogum, mis peab täitma renderdamise ülesandeid, ja sõlmedest, kus on vabade arvutusressursside, et neid renderdamise ülesandeid töödelda. Ressursside omanikud ühendavad oma jaamad renderdamise võrguga, et saada ja täita renderdamise ülesandeid kasutades ühte võrgus toetatud renderdamise mootoreid. Ülesannete pakkujatel on seejuures võrk nagu pilv, mis iseseisvalt jagab ressursse, kontrollib ülesannete täitmise õigsust, haldab riske ja muid küsimusi.
Nii et vaatleme raamistiku loomist, mis peab toetama integreerimist populaarsete renderdamise mootoreid ja sisaldama komponente, mis pakuvad tööriistu, et korraldada heterogeensete sõlmede võrku ja hallata ülesannete voogu.
Sarnase võrgu olemasolu majanduslik mudel ei oma põhimõttelist tähtsust, seega võime alguseks võtta skeemi, mis sarnaneb krüptovaluuta võrgu arvutustes kasutatavale - ressursi tarbijad saadavad tokenid töö tegemiseks ressurside pakkujatele. Huvi pakub aga see, milliseid omadusi peaks raamistiku omama, millega kaasneb osaliste interaktsiooni põhistsenaariumi käsitlemine.
Võrgus on kolm osalist: ressursside pakkuja, ülesannete pakkuja ja võrgu operaator (ka keskuse juht, võrk jne tekstis).
Võrguoperaator pakub ressursitootjale kliendi rakendust või operatsioonisüsteemi pilti koos eelnevalt installitud tarkvarakomplektiga, mille ta paigaldab masinale, mille ressursse ta soovib pakkuda. Samuti on saadaval veebiliides, mis võimaldab tal määrata juurdepääsu parameetreid ja hallata oma serverite maastikku kaugjuhtimise teel: kontrollida riistvaraparaetreid, teostada kaugseadistust, taaskäivitada.
Võrgu juhtimisseade analüüsib varustust ja määratud juurdepääsu parameetreid, kui liidetakse uus sõlm, reastab selle määratud hinnanguga ja lisab ressurside registrisse. Edasi, riski juhtimise eesmärgil analüüsitakse sõlme aktiivsuse parameetreid ning sõlme reitingut kohandatakse, et tagada võrgu stabiilne töö. Kelligi pole meeldiv, kui nende stsenaarium saadetakse renderdama võimsatele, kuid tihti ülekuumenemise tõttu kergesti kokku kukkuvatele kaartidele.
Kasutaja, kes peab renderdama mõnda stsenaariumit, võib valida kahe tee vahel: kas laadib stsenaariumi võrgu registrisse veebiliidese kaudu või ühendab oma modelleerimise paketi või paigaldatud renderdaja võrku plugina abil. Sellisel juhul algatatakse kasutaja ja võrgu vahel nutileping, mille tavapäraseks lõpetamise tingimuseks on, et võrk genereerib stsenaariumi arvutustulemuse. Kasutaja saab jälgida ülesande täitmise käiku ja hallata selle parameetreid oma kasutajaliidese veebilehe kaudu.
Ülesanne saadetakse server, kus analüüsitakse stsenaariumi mahtu ja ülesande algataja nõutud ressursside hulka ning seejärel dekompleksitakse kogumaht osadeks, mis on kohandatud arvutamiseks võrgust eraldatud hulga ja tüüpi ressurssidel. Üldine idee on see, et visualiseerimine võib jaguneda mitmeks väikseks ülesandeks. Mootorid kasutavad seda eelist ja jagavad need ülesanded paljude ressursitootjate vahel. Lihtsaim viis on renderdada väikseid stsenaariumi osi, mida nimetatakse segmentideks. Kui iga segment on valmis, loetakse kohalik ülesanne täidetuks ja ressurss liigub järgmise lahendamata ülesande täitmisele.
Seega renderdaja jaoks ei ole vahet, kas arvutused toimuvad ühel masinal või mitmete eraldi arvutijaamade rühmas. Jaotatud renderdamine lisab lihtsalt rohkem tuumasid ressursside kogumisse, mida ülesande jaoks kasutatakse. Võrgus saab ta kõik andmed, mis on vajalikud segmentide renderdamiseks, arvutab selle, saadab segmendi tagasi ja liigub järgmise ülesande juurde. Enne võrgu üldkogusse sisenemist saab iga segment komplekti metaandmeid, mis võimaldab täitmisosa nikod valida nende jaoks sobivamaid arvutusülesandeid.
Seosegmentimise ja arvutuste jaotamise ülesanded peavad olema lahendatud mitte ainult ajakulu optimeerimise, vaid ka ressursside ja energia säästlikkuse optimaalsete kasutusvõimaluste seisukohalt, kuna sellest sõltub võrgu majanduslik efektiivsus. Ebaõnnestumise korral oleks mõistlikum paigutada node miner või välja lülitada see, et see ei müra ega tarbiks elektrit.
Kuid naasse protsessi juurde. Ülesande saamisel luuakse ka nutileping, mis täidetakse, kui ülesande tulemus arvutatakse õigesti. Lepingutäiendite põhjal saab node preemia mingil kujul.
Juhtimiskeskus jälgib ülesande täitmise protsessi, kogudes arvutustulemusi, saates vale tulemused uuesti töötlemiseks ja järjestades järjekorda, jälgides ülesande regulaarset täitmise aega (et vältida olukorda, kus viimast segmenti ei võeta tööle ühegi nodi poolt).
Arvutustulemused läbivad koostamisetapi, pärast mida kasutaja saab renderdamise tulemused, ja võrk võib saada preemia.
Seega joonistub välja funktsionaalne maastiku raamistik, mis on mõeldud jaotatud renderdamise süsteemide ehitamiseks:
- Kasutajate isiklikud kabinetid veebipääsuga
- Tarkvara komplekt sõlvede installeerimiseks
- Halduse süsteemide osas:
- Ligipääsu juhtimise alamsüsteem
- Renderdamise ülesannete dekompositsioonisüsteem
- Ülesannete jaotamise alamsüsteem
- Koostamissüsteem
- Serveri maastiku ja võrgu topoloogia halduse alamsüsteem
- Logimise ja auditi alamsüsteem
- Õppiv eksperdi alamsüsteem
- REST API või muu liides välistest arendajatest
Kuidas on teie arvamus? Milliseid küsimusi teema tekitab ja millised vastused teid huvitavad?
Allikas: habr.com
