Pastaraisiais metais naujienų srautus užplūdo pranešimai apie naujo tipo paskirstytus kompiuterinius tinklus, atsirandančius tiesiog iš niekur, sprendžiančius (tiksliau, bandančius išspręsti) įvairiausias problemas – padaryti miestą išmanų, gelbėti pasaulį nuo autorių teisių. pažeidėjai arba atvirkščiai, slapta perduodantys informaciją ar išteklius, pabėgę iš -valstybės kontrolės vienoje ar kitoje srityje. Nepriklausomai nuo srities, jie visi turi nemažai bendrų bruožų dėl to, kad jų augimo paskata buvo algoritmai ir metodai, kurie visuomenei pasirodė per pastarąjį kriptovaliutų ir susijusių technologijų bumą. Turbūt kas trečio to meto straipsnio apie specializuotus išteklius pavadinime buvo žodis „blockchain“ – diskusijos apie naujus programinės įrangos sprendimus ir ekonominius modelius kurį laiką tapo vyraujančia tendencija, kurios fone vyravo ir kitos paskirstytų skaičiavimo sistemų taikymo sritys. nustumtas į antrą planą.
Tuo pačiu metu vizionieriai ir profesionalai įžvelgė pagrindinę reiškinio esmę: masinis paskirstytasis skaičiavimas, susijęs su tinklų kūrimu iš daugybės skirtingų ir nevienalyčių dalyvių, pasiekė naują išsivystymo lygį. Užtenka išmesti ažiotažas iš galvos ir pažvelgti į temą iš kitos pusės: visi šie tinklai, surinkti iš didžiulių telkinių, susidedančių iš tūkstančių izoliuotų nevienalyčių dalyvių, neatsirado savaime. Kriptografijos judėjimo entuziastai sugebėjo nauju būdu išspręsti sudėtingas duomenų sinchronizavimo ir išteklių bei užduočių paskirstymo problemas, o tai leido sujungti panašią įrangos masę ir sukurti naują ekosistemą, skirtą vienai siaurai fokusuotai problemai išspręsti.
Žinoma, tai neaplenkė komandos ir bendruomenės, dalyvaujančios nemokamo paskirstytojo skaičiavimo kūrime, o nauji projektai netruko laukti.
Tačiau, nepaisant reikšmingo turimos informacijos apie tinklų statybos ir darbo su įranga raidos padidėjimo, perspektyvių sistemų kūrėjai turės išspręsti rimtas problemas.
Pirmasis iš jų, kad ir kaip keistai tai skambėtų, – krypties pasirinkimo problema.
Kryptis gali būti teisinga arba nuvesti į aklavietę – nuo to nepabėgsi, centralizuotas aiškiaregių tiekimas IT bendruomenei vis dar vėluoja. Tačiau pasirinkimas turi būti padarytas taip, kad nepatektume į tradicinius spąstus, kai komanda užima per plačią sritį ir nuo pat pradžių bando sukurti kitą nespecializuotą bendrojo paskirstyto skaičiavimo projektą. Atrodo, kad darbų apimtis nėra tokia bauginanti, dažniausiai tereikia pritaikyti esamus pokyčius: sujungti mazgus į tinklą, pritaikyti topologijų nustatymo, duomenų mainų ir jų nuoseklumo stebėjimo algoritmus, įdiegti mazgų reitingavimo ir paieškos metodus. konsensusą ir, žinoma, tiesiog sukurkite savo užklausos kalbą ir visą kalbą bei skaičiavimo aplinką. Universalaus mechanizmo idėja yra labai viliojanti ir nuolat iškyla vienoje ar kitoje srityje, tačiau galutinis rezultatas vis tiek yra vienas iš trijų dalykų: sukurtas sprendimas arba iš tikrųjų yra ribotas prototipas su krūva pakabinamų. ToDos“ atsilikime, arba jis tampa nebenaudojamu monstru, pasiruošusiu nutempti kiekvieną, prisilietusį prie niūrios „Turingo pelkės“, arba tiesiog saugiai miršta nuo to, kad projektą nesuprantama kryptimi traukė gulbė, vėžiai ir lydekos. , tiesiog pervargė save.
Nekartokime kvailų klaidų ir rinkkimės kryptį, kuri turi aiškų užduočių spektrą ir puikiai tinka paskirstytam skaičiavimo modeliui. Galima suprasti žmones, kurie stengiasi viską daryti iš karto – žinoma, yra iš ko rinktis. Ir daug kas atrodo nepaprastai įdomiai tiek MTEP ir plėtros, tiek ekonomikos požiūriu. Naudodami paskirstytą tinklą galite:
- Neuroninių tinklų mokymas
- Apdorokite signalų srautus
- Apskaičiuokite baltymų struktūrą
- Atvaizduokite XNUMXD scenas
- Imituoti hidrodinamiką
- Išbandyti prekybos strategijas biržose
Kad nenusiviltume sudarydami įdomių dalykų, kurie gerai sugretinami, sąrašą, tolimesne tema pasirinksime paskirstytą atvaizdavimą.
Pats paskirstytas atvaizdavimas, žinoma, nėra jokia naujiena. Esami atvaizdavimo įrankių rinkiniai jau seniai palaiko apkrovos paskirstymą įvairiose mašinose; be to gyventi dvidešimt pirmame amžiuje būtų gana liūdna. Tačiau nereikėtų manyti, kad tema buvo aprėpta toli ir nėra ką ten veikti – panagrinėsime atskirą aktualią problemą: įrankio, skirto renderavimo tinklui kurti, sukūrimą.
Mūsų atvaizdavimo tinklas yra mazgų, kuriems reikia atlikti atvaizdavimo užduotis, derinys su mazgais, turinčiais laisvų skaičiavimo išteklių, kad apdorotų atvaizdavimą. Išteklių savininkai prijungs savo stotis prie atvaizdavimo tinklo, kad gautų ir vykdytų atvaizdavimo užduotis naudodami vieną iš tinklo palaikomų atvaizdavimo variklių. Tokiu atveju užduočių teikėjai dirbs su tinklu kaip debesiu, savarankiškai paskirstydami išteklius, stebėdami vykdymo teisingumą, rizikos valdymą ir kitas problemas.
Taigi apsvarstysime galimybę sukurti sistemą, kuri turėtų palaikyti integraciją su populiarių atvaizdavimo variklių rinkiniu ir apimanti komponentus, teikiančius įrankius heterogeninių mazgų tinklui organizuoti ir užduočių srautui valdyti.
Ekonominis tokio tinklo egzistavimo modelis neturi esminės reikšmės, todėl pradine schema imsime panašią į naudojamą skaičiavimuose kriptovaliutų tinkluose – resurso vartotojai siųs žetonus tiekėjams, atliekantiems atvaizdavimo darbus. Daug įdomiau suprasti, kokias savybes turi turėti karkasas, kuriam mes apsvarstysime pagrindinį tinklo dalyvių sąveikos scenarijų.
Tinkle yra trys sąveikos pusės: išteklių tiekėjas, užduočių teikėjas ir tinklo operatorius (tekste dar žinomas kaip valdymo centras, tinklas ir kt.).
Tinklo operatorius pateikia išteklių tiekėjui kliento programą arba operacinės sistemos atvaizdą su įdiegtu programinės įrangos rinkiniu, kurį jis įdiegs įrenginyje, kurio išteklius jis nori teikti, ir asmeninę paskyrą, pasiekiamą per žiniatinklio sąsają, leidžiančią jam nustatyti prieigos prie resurso parametrus ir nuotoliniu būdu valdyti jo serverio kraštovaizdį: valdyti aparatūros parametrus, atlikti nuotolinę konfigūraciją, perkrauti.
Prijungus naują mazgą, tinklo valdymo sistema išanalizuoja įrangą ir nurodytus prieigos parametrus, suskirsto ją, suteikdama tam tikrą reitingą ir talpina į resursų registrą. Ateityje, siekiant valdyti riziką, bus analizuojami mazgo veiklos parametrai, koreguojamas mazgo reitingas, kad būtų užtikrintas tinklo stabilumas. Niekas nebus patenkintas, jei jų scena bus siunčiama atkurti galingose kortelėse, kurios dažnai užšąla dėl perkaitimo?
Vartotojas, kuriam reikia pateikti sceną, gali pasirinkti du būdus: įkelti sceną į tinklo saugyklą per žiniatinklio sąsają arba naudoti papildinį savo modeliavimo paketui ar įdiegtam atvaizdavimo įrenginiui prijungti prie tinklo. Tokiu atveju tarp vartotojo ir tinklo inicijuojama išmanioji sutartis, kurios standartinė įvykdymo sąlyga yra tinkle sugeneruotas scenos skaičiavimo rezultatas. Vartotojas gali stebėti užduoties atlikimo procesą ir valdyti jos parametrus per savo asmeninės paskyros žiniatinklio sąsają.
Užduotis siunčiama į serverį, kuriame analizuojamas scenos tūris ir užduoties iniciatoriaus prašomų resursų skaičius, po to bendra apimtis išskaidoma į dalis, pritaikytas skaičiuoti pagal tinklo skiriamų išteklių skaičių ir tipą. . Bendra idėja yra ta, kad vizualizaciją galima suskirstyti į daugybę mažų užduočių. Varikliai tuo pasinaudoja paskirstydami šias užduotis keliems išteklių tiekėjams. Paprasčiausias būdas yra pateikti mažas scenos dalis, vadinamas segmentais. Kai kiekvienas segmentas yra paruoštas, vietinė užduotis laikoma baigta, o išteklius pereina prie kitos neatliktos užduoties.
Taigi atvaizduotojui nėra jokio skirtumo, ar skaičiavimai atliekami vienoje mašinoje, ar daugelio atskirų skaičiavimo stočių tinkle. Paskirstytas atvaizdavimas tiesiog prideda daugiau branduolių į užduočiai naudojamų išteklių telkinį. Per tinklą jis gauna visus duomenis, reikalingus segmentui pateikti, jį apskaičiuoja, siunčia tą segmentą atgal ir pereina prie kitos užduoties. Prieš patenkant į bendrą tinklo telkinį, kiekvienas segmentas gauna metainformacijos rinkinį, leidžiantį vykdantiems mazgams pasirinkti jiems tinkamiausias skaičiavimo užduotis.
Skaičiavimų segmentavimo ir paskirstymo problemos turi būti sprendžiamos ne tik vykdymo laiko optimizavimo, bet ir optimalaus išteklių naudojimo bei energijos taupymo požiūriu, nes nuo to priklauso tinklo ekonominis efektyvumas. . Jei sprendimas nepavyksta, verčiau būtų mazge sumontuoti minerį arba jį išjungti, kad nekeltų triukšmo ir nešvaistytų elektros energijos.
Tačiau grįžkime prie proceso. Kai gaunama užduotis, tarp telkinio ir mazgo taip pat sudaroma išmanioji sutartis, kuri vykdoma teisingai apskaičiavus užduoties rezultatą. Remiantis sutarties įvykdymo rezultatais, mazgas gali gauti atlygį viena ar kita forma.
Valdymo centras kontroliuoja užduoties vykdymo procesą, skaičiavimo rezultatų rinkimą, neteisingų siuntimą pakartotiniam apdorojimui ir eilės reitingavimą, standartinio užduoties atlikimo termino stebėjimą (kad neatsitiktų, kad paskutinio segmento neužimtų bet koks mazgas).
Skaičiavimų rezultatai pereina komponavimo etapą, po kurio vartotojas gauna atvaizdavimo rezultatus, o tinklas gali gauti atlygį.
Taigi išryškėja funkcinė kraštovaizdžio karkaso, skirto paskirstytoms atvaizdavimo sistemoms kurti, sudėtis:
- Asmeninės vartotojų paskyros su prieiga prie interneto
- Programinės įrangos rinkinys, skirtas diegti mazguose
- Pagal valdymo sistemą:
- Praėjimo kontrolės posistemis
- Atvaizdavimo užduočių skaidymo posistemis
- Užduočių paskirstymo posistemis
- Kompozicijos posistemis
- Serverio kraštovaizdžio ir tinklo topologijos valdymo posistemis
- Registravimo ir audito posistemis
- Mokymosi ekspertų posistemė
- Rest API arba kita sąsaja išoriniams kūrėjams
Ką tu manai? Kokius klausimus kelia tema ir kokie atsakymai jus domina?
Šaltinis: www.habr.com