Viimastel aastatel on uudistevoogudes ilmunud lugematul hulgal teateid uue tüübi jaotatud arvutivõrkudest, mis kerkivad sõna otseses mõttes kusagilt ning püüavad lahendada erinevaid probleeme — alates nutikate linnade loomisest kuni autoriõiguste rikkumiste tõrjumiseni, või vastupidi, teabe ja ressursside salajase edastamiseni, et pääseda riigi kontrolli alt välja. Ükskõik millises valdkonnas, jagavad need kõik teatud ühiseid jooni, kuna nende kasvu kütuseks on olnud algoritmid ja meetodid, mis on laiemasse kasutusse jõudnud hiljutise krüptovaluutade ja sellega seotud tehnoloogiate buumi käigus. Tõenäoliselt oli iga kolmas artikkel spetsialiseeritud allikates sellel ajal pealkirjas sõna „plokiahel“ — arutelud uute tarkvaralahenduste ja majandusmudelite üle said mõneks ajaks domineerivaks trendiks, mille taustal jäid teised jaotatud arvutisüsteemide kasutusvaldkonnad tähelepanuta.
Samas nägid visionäärid ja spetsialistid nähtuse põhiolemust: massilised jaotatud arvutused, mis on seotud suurte ja heterogeensete osaliste võrkude ehitamisega, on jõudnud uuele arengutasemele. Piisab, kui jätta kõrvale hüpeteemad ja vaadata asjale teise nurga alt: kõik need võrgud, mis koosnevad tohututest basseinidest, milles on tuhandeid iseseisvaid ja heterogeenseid osalisi, ei tekkinud iseenesest. Krüptoliikumise entusiastid suudavad uuendatud võtmes lahendada keerulisi andmete sünkroonimise ja ressursside ning ülesannete jagamise probleeme, mis on võimaldanud sellise seadmete massi liitmise ning uue ökosüsteemi loomise, mille eesmärk on lahendada üks kitsas suunatud ülesanne.
Muidugi ei jäänud see märkamata vabade jaotatud arvutuste arendamise meeskondadele ja kogukondadele, ning uued projektid ei lasknud end kaua oodata.
Kuid vaatamata olulisele teabe kasvu mahule, mis käsitleb võrkude ehitamist ja seadmete kasutamist, peavad perspektiivsete süsteemide loojad lahendama tõsiseid probleeme.
Esimene, kuigi see võib kõlada kummaliselt, on suunavaliku probleem
Suund võib olla õige, kuid võib viia ummikusse — sellest ei pääse, tsentraliseeritud selgeltnägijate pakkumised IT-kogukonnas jäävad veel maha. Kuid valik tuleb teha, et mitte sattuda traditsioonilisse lõksu, mis seisneb selles, et meeskond haarab endale liiga laia ala ja püüab algusest peale luua veel ühe mittespetsialiseeritud hajutatud arvutuste projekt. Tundub, et tööde hulk pole nii hirmutav, tuleb peamiselt lihtsalt rakendada olemasolevaid lahendusi: ühendada sõlmed võrku, kohandada topoloogia määramise, andmevahetuse ja nende järjepidevuse kontrollimise algoritme, rakendada sõlmede järjestamise ja konsensuse leidmise meetodeid, ning loomulikult luua oma päringute keel ja kõik keele- ja arvutuslikud keskkonnad. Universaalse mehhanismi idee on äärmiselt ahvatlev ja kerkib pidevalt esile ühes või teises valdkonnas, kuid väljundiks on ikka üks kolmest: loodud lahendus osutub tegelikult piiratud prototüübiks, millel on hunnik poolikuid „ToDo“ ülesandeid tagumise järele; või muutub see kasutamiskõlbmatuks monstrumiks, mis haarab igasuguseid puudutajaid oma lõhnavasse „Tüüringi sohu“; või sureb lihtsalt õnnelikult, kuna projekti vedajad, olles suunatud teadmata suunas, saavad lihtsalt ära tüütatud.
Vältime rumalaid vigu ja valime suuna, mille ülesannete ring on selge ja sobib hästi hajutatud arvutamise mudelisse. On arusaadav, et on inimesi, kes püüavad teha kõike ja kohe — valikuid on tõesti palju. Ja palju näeb välja äärmiselt huvitav nii R&D kui ka majanduse seisukohalt. Hajutatud võrgu abil on võimalik:
- Koolitada närvivõrke
- Töödelda signaalivooge
- Arvutada valkude struktuuri
- Teha kolme mõõtme stseneeringute renderdamist
- Modelleerida hüdrodünaamikat
- Testida kauplemisstrateegiaid aktsiaturgudel
Et mitte laskuda pikale nimekirjale huvitavatest asjadest, mis sobivad hästi paralleelimiseks, valime edasise teema hajutatud renderdamine.
Jaotatud renderdamine iseenesest ei ole kindlasti uus nähtus. Olemasolevad renderdus tööriistad toetavad juba ammu koormuse jaotust erinevate masinate vahel, ilma milleta oleks 21. sajandis elu üsna masendav. Kuid ei tasu arvata, et teema on ammendatud ja seal ei ole rohkem tegemist — vaatleme ühte eriti olulist probleemi: renderdamise võrgu loomise tööriista väljatöötamine.
Meie renderdamisvõrk on sõlmede kogum, mis vajab renderdamise ülesannete täitmist, koos sõlmedega, millel on renderdamiseks vabad arvutusressursid. Ressursside omanikud ühendavad oma tööstused renderdamisvõrku, et saada ja täita renderdamise ülesandeid, kasutades mõnd toetatud renderdamismootorit. Ülesannete pakkujad töötavad võrgu kaudu nagu pilveteenusega, mis iseseisvalt teostab ressursside jaotust, tagab täitmise õigsuse, haldab riske ja lahendab muid probleeme.
Käsitleme seega raamistikku, mis peab toetama integreerimist populaarsete renderdamismootoritega ning sisaldama komponente, mis pakuvad tööriistu erinevate sõlmede võrgustiku korraldamiseks ja ülesannete voogude juhtimiseks.
Sellise võrgu majandusmudel ei ole põhimõtteliselt oluline, seega võtame aluseks skeemi, mis on sarnane krüptovaluutanetworkide arvutustes kasutatavale — ressursikasutajad saadavad tootmisteenuste osutajatele, kes teevad renderdamistööd, tokenid. Olulisem on mõista, milliseid omadusi peab raamistik endas sisaldama, seetõttu vaatleme võrgu osaliste peamist suhtlusstsenaariumi.
Võrgus on kolm osalise osalust: ressurside pakkuja, ülesannete pakkuja ja võrgu operaator (keskuse juhtimine, võrgu keskpunkt jne).
Võrguoperaator annab ressursi pakkujale kliendirakenduse või opsüsteemi pildi koos kõigi vajalike tarkvaradega, mille ta installeerib masinale, mille ressursse ta soovib pakkuda. Lisaks on tal juurdepääs veebiliidese kaudu isiklikule kontole, mis võimaldab tal seadistada juurdepääsuparameetreid ja kaugjuhtida oma serverite maastikku: jälgida riistvara parameetreid, teostada kaugseadistamist ja taaskäivitada.
Võrgu juhtimissüsteem analüüsib uut sõlme ühendamisel riistvara ja määratud juurdepääsuparameetreid, hindab seda ja määrab teatud reitingu, seejärel lisab selle ressursside registrisse. Edasi liikudes, et hallata riski, analüüsitakse sõlme tegevusparameetreid ning sõlme reitingut korrigeeritakse, et tagada võrgu stabiilne töö. Keegi ei taha, et nende stseen saadetaks renderdama võimsatele, kuid sageli ülemäärasest kuumenemisest kokku kukkuvatele kaartidele?
Kasutaja, kes peab renderdama mingit stseeni, võib minna kahte teed: laadida stseen võrku läbi veebiliidese või kasutada pluginit, et ühendada oma modelleerimispakett või installitud renderdaja võrku. Sellega initsieeritakse kasutaja ja võrgu vahel nutileping, mille tavapärane lõpetamise tingimus on tulemuse genereerimine võrgu poolt stseeni arvutamisel. Kasutaja saab jälgida ülesande täitmise protsessi ja hallata selle parameetreid oma isikliku konto veebiliidese kaudu.
Ülesanne saadetakse server, kus analüüsitakse stseeni mahtu ning ülesande algataja poolt nõutavate ressursside hulka, mille järel jagatakse kogu maht osadeks, mis on kohandatud arvutamiseks eraldatud võrgus olevate ressursside koguse ja tüübi jaoks. Üldine idee on see, et visualiseerimine saab jagada paljude väikeste ülesannete vahel. Mootorid kasutavad seda eelist, jaotades need ülesanded paljude ressursihankijate vahel. Lihtsaim viis on renderdada stseeni väikseid osi, mida kutsutakse segmentideks. Kui iga segment on valmis, loetakse kohalik ülesanne lõpetatuks ning ressurss suunatakse järgmise lahendamata ülesande täitmisele.
Seega, renderdaja jaoks ei ole vahet, kas arvutused teostatakse ühel masinal või paljude eraldi arvutitega moodustavas gridis. Jaotatud renderdamine lisab lihtsalt rohkem tuumasid ressursside kasutamiseks. Võrgu kaudu saab ta kõik andmed, mis on vajalikud lõigu renderdamiseks, arvutab selle, saadab lõigu tagasi ja liigub järgmise ülesande juurde. Enne võrku minemist saab iga lõik kokkulepitud metaandmed, mis võimaldavad täitev sõlmedel valida endale sobivaimad arvutusülesanded.
Lõikude ja arvutuste jaotamise ülesandeid tuleb lahendada mitte ainult käitamise aja optimeerimise, vaid ka ressursside ja energiatõhususe optimaalsete kasutusviiside kaudu, kuna see mõjutab võrgu majanduslikku efektiivsust. Ebaõnnestumise korral on mõistlikum sellele sõlmele paigaldada kaevandaja või välja lülitada, et see ei tekitaks müra ega raiskaks elektrit.
Kuid pöördume tagasi protsessi juurde. Ülesande saamisel luuakse põhja ja sõlme vahel ka nutileping, mis täidetakse, kui ülesande tulemuse arvutamine on korrektne. Lepingu täitmise tulemuste põhjal saab sõlm kas mingit tüüpi tasu.
Juhtimiskeskus jälgib ülesande täitmise protsessi, kogudes arvutustulemusi, saatides vale tulemused uuesti töötlemiseks ning järjestades järjekorda, jälgides täitmise normatiivperioodi (et vältida olukorda, kus viimane segment ei saa ühegi sõlme poolt tööle hakatud).
Arvutustulemused läbivad kompositsiooni etapi, pärast mida saab kasutaja renderduste tulemused, ning võrk võib saada tasu.
Seega joonistub välja funktsionaalne koostis maastiku raamistikust, mis on ette nähtud jaotatud renderdamise süsteemide loomiseks:
- Kasutajate isiklikud kontod veebipääsuga
- Tarkvarapakett sõlmedele paigaldamiseks
- Juhtimissüsteemide kohta:
- Ligipääsuhaldussubsystem
- Renderdamise ülesannete dekompositsiooni alamsüsteem
- Ülesannete jagamise alamsüsteem
- Kompositsiooni alamsüsteem
- Serveri haldamise ja võrgu topoloogia alamsüsteem
- Logimise ja auditi alamsüsteem
- Õppiv ekspertalamsüsteem
- Rest API või muu liides väliste arendajate jaoks
Kuidas teie arvate? Milliseid küsimusi teema tekitab ja milliseid vastuseid te otsite?
Allikas: habr.com
