Viimastel aastatel on uudistevood üle ujutatud sõnumitega uut tüüpi hajutatud arvutivõrkudest, mis ilmuvad sõna otseses mõttes eikusagilt ja lahendavad (õigemini üritavad lahendada) väga erinevaid probleeme – linna targaks muutmine, maailma autoriõiguste eest päästmine. rikkujad või vastupidi, teabe või ressursside salaja edastamine, ühes või teises valdkonnas riigi kontrolli alt pääsemine. Olenemata valdkonnast on neil kõigil mitmeid ühiseid jooni, mis tuleneb sellest, et nende kasvu kütuseks olid algoritmid ja tehnikad, mis tulid avalikkuse ette hiljutise krüptovaluutade ja sellega seotud tehnoloogiate buumi ajal. Tõenäoliselt oli tollal iga kolmanda spetsialiseeritud ressursside artikli pealkirjas sõna "plokiahel" - uute tarkvaralahenduste ja majandusmudelite arutelu sai mõneks ajaks domineerivaks trendiks, mille taustal olid hajutatud arvutussüsteemide muud kasutusvaldkonnad. tagaplaanile tõrjutud.
Samal ajal nägid visionäärid ja professionaalid nähtuse peamist olemust: massiline hajutatud andmetöötlus, mis on seotud paljude erinevate ja heterogeensete osalejate võrkude ehitamisega, on jõudnud uuele arengutasemele. Piisab, kui visata oma peast hüpeteemad välja ja vaadata teemat teisest küljest: kõik need tohututest basseinidest kokku pandud võrgustikud, mis koosnevad tuhandetest eraldatud heterogeensetest osalejatest, ei tekkinud iseenesest. Krüptoliikumise entusiastid suutsid lahendada keerulisi andmete sünkroniseerimise ning ressursside ja ülesannete jaotamise probleeme uudsel viisil, mis võimaldas kokku panna sarnase massiga seadmeid ja luua uue ökosüsteemi, mis on mõeldud ühe kitsalt fokusseeritud probleemi lahendamiseks.
Loomulikult ei läinud see mööda tasuta hajutatud andmetöötluse arendamisega seotud meeskondadest ja kogukondadest ning uued projektid ei lasknud end kaua oodata.
Vaatamata võrkude ehitamise ja seadmetega töötamise valdkonna arengute kohta kättesaadava teabe mahu olulisele suurenemisele tuleb paljutõotavate süsteemide loojatel siiski lahendada tõsiseid probleeme.
Esimene neist, ükskõik kui kummaliselt see ka ei kõlaks, on suunavaliku probleem.
Suund võib olla õige või viia ummikusse – sellest pole pääsu, selgeltnägijate tsentraliseeritud tarned IT-kogukonnale jäävad endiselt hiljaks. Kuid valik tuleb teha nii, et mitte langeda traditsioonilisse lõksu, kus meeskond võtab liiga laia ala ja üritab algusest peale luua mõnda muud spetsialiseerimata üldist hajutatud andmetöötlusprojekti. Tundub, et töömaht polegi nii hirmutav, enamjaolt tuleb lihtsalt rakendada olemasolevaid arendusi: ühendada sõlmed võrku, kohandada topoloogiate määramise, andmete vahetamise ja nende järjepidevuse jälgimise algoritme, võtta kasutusele meetodid sõlmede järjestamiseks ja leidmiseks. konsensusele ja loomulikult looge lihtsalt oma päringukeel ning kogu keel ja arvutikeskkond. Universaalse mehhanismi idee on väga ahvatlev ja hüppab pidevalt ühes või teises piirkonnas esile, kuid lõpptulemus on siiski üks kolmest asjast: loodud lahendus osutub kas tegelikult piiratud prototüübiks, millel on hunnik riputatud “ ToDos” mahajäämusse või muutub see kasutuskõlbmatuks koletiseks, kes on valmis minema tassima kõik, kes puudutavad kibedat “Turingi raba”, või lihtsalt sureb turvaliselt sellesse, et projekti arusaamatus suunas vedanud luik, vähid ja haug , pingutasid end lihtsalt üle.
Ärgem kordagem rumalaid vigu ja valigem suund, millel on selge ülesannete ring ja mis sobib hästi hajutatud arvutusmudeliga. Saab aru inimestest, kes püüavad kõike korraga teha – loomulikult on valikut küllaga. Ja nii teadus- ja arendustegevuse kui ka majanduse seisukohalt tunduvad paljud asjad äärmiselt huvitavad. Hajutatud võrku kasutades saate:
- Treeni närvivõrke
- Töötle signaalivooge
- Valgu struktuuri arvutamine
- Renderdage XNUMXD-stseene
- Hüdrodünaamika simuleerimine
- Testige börside kauplemisstrateegiaid
Selleks, et huvitavatest asjadest, mis on hästi paralleelsed, nimekirja koostamisest mitte kihutada, valime edasiseks teemaks hajutatud renderdamise.
Hajutatud renderdamine iseenesest pole muidugi midagi uut. Olemasolevad renderdamistööriistad on pikka aega toetanud koormuse jaotamist erinevate masinate vahel; ilma selleta oleks kahekümne esimesel sajandil elamine üsna kurb. Siiski ei tasu arvata, et teemat on käsitletud kaugelt ja laialt ja seal pole midagi teha – käsitleme eraldi pakilist probleemi: renderdusvõrgu loomise tööriista loomist.
Meie renderdusvõrk on kombinatsioon sõlmedest, mis peavad täitma renderdamisülesandeid sõlmedega, millel on renderdamise töötlemiseks vabad arvutusressursid. Ressursiomanikud ühendavad oma jaamad renderdusvõrguga, et saada ja täita renderdustöid, kasutades ühte võrgu toetatud renderdusmootoritest. Sel juhul töötavad ülesannete pakkujad võrguga nagu pilv, jaotades iseseisvalt ressursse, jälgides täitmise õigsust, haldades riske ja muid probleeme.
Seega kaalume raamistiku loomist, mis peaks toetama integreerimist populaarsete renderdusmootorite komplektiga ja sisaldama komponente, mis pakuvad tööriistu heterogeensete sõlmede võrgu korraldamiseks ja ülesannete voo haldamiseks.
Sellise võrgu olemasolu majanduslik mudel ei oma põhimõttelist tähtsust, mistõttu võtame algskeemina krüptoraha võrkudes arvutustes kasutatavale sarnase skeemi – ressursi tarbijad saadavad renderdamistöid teostavatele tarnijatele tokeneid. Palju huvitavam on mõista, millised omadused peaksid raamistikul olema, mille jaoks käsitleme võrgus osalejate vahelise suhtluse peamist stsenaariumi.
Võrgus on koostoimel kolm külge: ressursi pakkuja, ülesande pakkuja ja võrguoperaator (tekstis ehk juhtimiskeskus, võrk jne).
Võrguoperaator annab ressursipakkujale kliendirakenduse või operatsioonisüsteemi kujutise koos juurutatud tarkvarakomplektiga, mille ta installib masinasse, mille ressursse ta soovib pakkuda, ja isikliku konto, millele pääseb ligi veebiliidese kaudu, mis võimaldab tal määrake ressursile juurdepääsuparameetrid ja hallake serveri maastikku eemalt: juhtige riistvara parameetreid, teostage kaugkonfiguratsiooni, taaskäivitage.
Uue sõlme ühendamisel analüüsib võrguhaldussüsteem seadmeid ja määratud juurdepääsuparameetreid, järjestab need, määrates teatud reitingu ja paigutab selle ressursside registrisse. Edaspidi analüüsitakse riski maandamiseks sõlme aktiivsusparameetreid ning korrigeeritakse sõlme reitingut, et tagada võrgu stabiilsus. Keegi pole rahul, kui tema stseen saadetakse renderdama võimsatele kaartidele, mis sageli ülekuumenemise tõttu külmuvad?
Kasutaja, kes peab stseeni renderdama, saab teha kahte võimalust: laadida stseeni veebiliidese kaudu võrguhoidlasse või kasutada oma modelleerimispaketi või installitud renderdaja võrku ühendamiseks pistikprogrammi. Sel juhul algatatakse kasutaja ja võrgu vahel nutikas leping, mille täitmise tüüptingimuseks on stseeniarvutuse tulemuse genereerimine võrgu poolt. Kasutaja saab oma isikliku konto veebiliidese kaudu jälgida ülesande täitmise protsessi ja hallata selle parameetreid.
Ülesanne saadetakse serverisse, kus analüüsitakse stseeni mahtu ja ülesande algataja küsitud ressursside arvu, misjärel kogumaht jaotatakse osadeks, mis on kohandatud arvutamiseks võrgu poolt eraldatud ressursside arvu ja tüübi järgi. . Üldine idee on see, et visualiseerimist saab jagada paljudeks väikesteks ülesanneteks. Mootorid kasutavad seda ära, jaotades need ülesanded mitme ressursipakkuja vahel. Lihtsaim viis on renderdada stseeni väikesed osad, mida nimetatakse segmentideks. Kui iga segment on valmis, loetakse kohalik ülesanne lõpetatuks ja ressurss liigub järgmise lahendamata ülesande juurde.
Seega ei ole renderdaja jaoks iseenesest vahet, kas arvutused tehakse ühe masinaga või paljude üksikute arvutusjaamade võrgus. Hajutatud renderdamine lisab lihtsalt rohkem tuumasid ülesande jaoks kasutatavate ressursside kogumile. Võrgu kaudu saab ta kõik segmendi renderdamiseks vajalikud andmed, arvutab need välja, saadab selle segmendi tagasi ja liigub edasi järgmise ülesande juurde. Enne üldisesse võrgukogumisse sisenemist saab iga segment metateabe komplekti, mis võimaldab täitvatel sõlmedel valida neile kõige sobivamad andmetöötlusülesanded.
Segmenteerimise ja arvutuste jaotamise probleeme tuleb lahendada mitte ainult täitmisaja optimeerimise, vaid ka ressursside optimaalse kasutamise ja energiasäästu seisukohast, kuna sellest sõltub võrgu majanduslik efektiivsus. . Kui lahendus ebaõnnestub, oleks soovitav paigaldada sõlmele kaevandaja või see välja lülitada, et see ei teeks müra ja ei raiskaks elektrit.
Tuleme siiski tagasi protsessi juurde. Ülesande vastuvõtmisel moodustatakse basseini ja sõlme vahel ka nutikas leping, mis täidetakse siis, kui ülesande tulemus on õigesti arvutatud. Lepingu täitmise tulemuste põhjal võib sõlm saada ühel või teisel kujul tasu.
Juhtimiskeskus kontrollib ülesande täitmise protsessi, arvutustulemuste kogumist, valede saatmist ümbertöötlemiseks ja järjekorra järjestamist, jälgib ülesande täitmise standardtähtaega (et ei juhtuks, et viimane segment jääb hõivamata mis tahes sõlm).
Arvutuste tulemused läbivad koostamisetapi, mille järel saab kasutaja renderdustulemused ja võrk saab tasu.
Seega ilmneb hajutatud renderdussüsteemide ehitamiseks mõeldud maastikuraamistiku funktsionaalne koostis:
- Isiklikud kasutajakontod veebijuurdepääsuga
- Tarkvarakomplekt sõlmedesse paigaldamiseks
- Juhtimissüsteemi järgi:
- Juurdepääsu kontrolli allsüsteem
- Renderdusülesannete lagunemise alamsüsteem
- Ülesannete jaotamise alamsüsteem
- Alamsüsteemi koostamine
- Serveri maastiku ja võrgu topoloogia haldamise alamsüsteem
- Logimise ja auditi alamsüsteem
- Õppimiseksperdi allsüsteem
- Rest API või muu liides välistele arendajatele
Mida sa arvad? Milliseid küsimusi teema tõstatab ja millised vastused sind huvitavad?
Allikas: www.habr.com