Në vitet e fundit, kanalet e lajmeve janë mbushur me mesazhe për rrjetet e reja të kompjuterave të shpërndarë që shfaqen thuajse nga asgjëja, të cilat përpiqen (në mënyrë më të saktë) të zgjidhin një gamë të gjerë problemesh - të bëjnë qytetin inteligjent, të shpëtojnë botën nga shkelësit e të drejtave të autorit ose përkundrazi, të transferojnë fshehtas informacion ose burime, të ikin nga kontrolli i shtetit në një fushë të caktuar. Pavarësisht nga fusha, të gjithë kanë disa karakteristika të përbashkëta, të cilat janë rezultat i mënyrave dhe algoritmeve që morën famë gjatë bumit të fundit të kriptovalutave dhe teknologjive të lidhura me to. Ndoshta çdo artikull i tretë në burimet përkatëse gjatë asaj kohe kishte fjalën "blockchain" në titull - diskutimi i zgjidhjeve të reja softuerike dhe modeleve ekonomike u bë një tendencë dominuese, përballë së cilës fushat e tjera të përdorimit të sistemeve të shfrytëzimit të shpërndarë u shtynë në plan të dytë.
Megjithatë, vizionarët dhe profesionistët e panë thelbin e këtij fenomeni: kompjuterat masivë të shpërndarë, të lidhur me ndërtimin e rrjeteve nga një numër i madh pjesëmarrësish të ndarë dhe të heterogjenë, kanë arritur një nivel të ri zhvillimi. Mjafton të heqësh nga mendja temat e hype-it dhe të shikosh objektin nga një këndvështrim tjetër: të gjitha këto rrjete, të mbledhura nga pool të mëdha, ku përfshihen mijëra pjesëmarrës të veçuar dhe të ndryshëm, nuk shfaqen vetë. Enthusiastët e lëvizjes kripto arritën të zgjidhin në një mënyrë të re probleme të komplikuara të sinkronizimit të të dhënave dhe shpërndarjes së burimeve dhe detyrave, gjë e cila lehtësoi mbledhjen e një mase të tillë pajisjesh dhe krijimin e një ekosistemi të ri, të dizajnuar për të zgjidhur një detyrë të caktuar.
Sigurisht, kjo nuk kaloi pa u vënë re nga ekipet dhe komunitetet që janë të angazhuara në zhvillimin e kompjuterive të lira dhe të shpërndara, dhe projektet e reja nuk vonuan të shfaqen.
Megjithatë, pavarësisht rritjes serioze të sasisë së informacionit të disponueshëm mbi zhvillimet në fushën e ndërtimit të rrjeteve dhe punës me pajisjet, krijuesit e sistemeve të perspektivës do të duhet të zgjidhin probleme serioze.
E para prej tyre, sa e çuditshme që mund të tingëllojë, është problemi i zgjedhjes së drejtimit
Direktimi mund tĂ« jetĂ« i saktĂ«, mund tĂ« çojĂ« nĂ« njĂ« fund tĂ« ngushtĂ« â nuk ka shans tĂ« shpĂ«tojmĂ«, furnizimet qendrore tĂ« parashikuesve nĂ« komunitetin IT janĂ« ende tĂ« ngadalta. Por duhet tĂ« bĂ«het njĂ« zgjedhje, pĂ«r tĂ« mos rĂ«nĂ« nĂ« grackĂ«n tradicionale, qĂ« Ă«shtĂ« se ekipi merr njĂ« fushĂ« shumĂ« tĂ« gjerĂ« dhe nga fillimi pĂ«rpiqet tĂ« krijojĂ« njĂ« projekt tĂ« pa specializuar pĂ«r llogaritjet e shpĂ«rndara. Duket se pĂ«rparĂ«sitĂ« e punĂ«s nuk janĂ« aq tĂ« frikshme, Ă«shtĂ« mĂ« sĂ« shumti vetĂ«m pĂ«r tĂ« aplikuar zhvillimet ekzistuese: pĂ«r tĂ« bashkuar nyjat nĂ« rrjet, pĂ«r tĂ« adaptuar algoritmet e pĂ«rcaktimit tĂ« topologjive, shkĂ«mbimin e tĂ« dhĂ«nave dhe kontrollin e konsistencĂ«s sĂ« tyre, pĂ«r tĂ« zbatuar metodologjitĂ« e renditjes sĂ« nyjave dhe tĂ« gjetjes sĂ« konsensusit, dhe sigurisht, thjesht tĂ« krijosh gjuhĂ«n tĂ«nde tĂ« pyetjeve dhe tĂ« gjithĂ« mjedisin gjuhĂ«sor dhe llogaritur. Ideja pĂ«r njĂ« mekanizĂ«m tĂ« universalisht Ă«shtĂ« shumĂ« joshĂ«se dhe paraqitet vazhdimisht nĂ« sfera tĂ« ndryshme, por nĂ« dalje, vazhdon tĂ« prodhojĂ« njĂ« ndĂ«r tri gjĂ«ra: zgjidhja e krijuar ose rezulton tĂ« jetĂ« nĂ« tĂ« vĂ«rtetĂ« njĂ« prototip i kufizuar me njĂ« mori âToDoâ tĂ« pezulluara nĂ« bllokun e punĂ«s, ose bĂ«het njĂ« monstruozitet i pa pĂ«rdorshĂ«m, i gatshĂ«m pĂ«r tĂ« tĂ« tĂ«rhequr nĂ« njĂ« âmoçalin Turingâ, ose thjesht vdes nĂ« paqe nga faktori qĂ« çekonte projektin nĂ« njĂ« drejtim tĂ« panjohur, duke krijuar zakonisht njĂ« grua, njĂ« karkalec dhe njĂ« peshk i cili thjesht Ă«shtĂ« lodhur.
Mos tĂ« pĂ«rsĂ«risim gabime tĂ« stupid dhe tĂ« zgjedhim njĂ« drejtim qĂ« ka njĂ« rreth tĂ« qartĂ« detyrash dhe qĂ« i pĂ«rshtatet mirĂ« modelit tĂ« llogaritjeve tĂ« shpĂ«rndara. Mund tĂ« kuptojmĂ« njerĂ«zit qĂ« pĂ«rpiqen tĂ« bĂ«jnĂ« gjithçka nĂ« njĂ« kohĂ« â sigurisht, ka shumĂ« pĂ«r tĂ« zgjedhur. Dhe shumĂ« duket tepĂ«r interesante, si nga kĂ«ndvĂ«shtrimi i R&D dhe zhvillimit, ashtu edhe nga kĂ«ndvĂ«shtrimi ekonomik. Me ndihmĂ«n e njĂ« rrjeti tĂ« shpĂ«rndarĂ« mund tĂ«:
- Trajnoni rrjetet neuronale
- PĂ«rpunoni flukset e sinjaleve
- Llogariten strukturat e proteinave
- Kryeni renderimin e skenave tre dimensionale
- Modeloni dinamikën hidrike
- Testoni strategji tregtare për bursat
Për të mos u përfshirë në përgatitjen e një liste gjërash interesante që përshtaten mirë për paralelizimin, do të zgjedhim si temën tonë të ardhshme renderimin e shpërndarë.
E pĂ«rbashkĂ«t, renderimi i shpĂ«rndarĂ« Ă«shtĂ« njĂ« fenomen qĂ«, natyrisht, nuk Ă«shtĂ« aspak i ri. Toolkit-et e ekzistuese tĂ« renderimit kanĂ« mbĂ«shtetur prej njĂ« kohĂ«sh shpĂ«rndarjen e ngarkesĂ«s nĂ« makina tĂ« ndryshme; pa kĂ«tĂ«, do tĂ« ishte mjaft e trishtuar tĂ« jetonim nĂ« shekullin e njĂ«zetĂ« dhe njĂ«. MegjithatĂ«, nuk duhet tĂ« mendojmĂ« se kjo temĂ« Ă«shtĂ« e thellĂ« dhe nuk ka çfarĂ« tĂ« diskutojmĂ« â ne do tĂ« shqyrtojmĂ« njĂ« problem tĂ« veçantĂ« aktual: krijimin e njĂ« mjeti pĂ«r formimin e njĂ« rrjeti renderimi.
Rrjeti ynë i renderimit është një bashkim i nyjeve, të cilat duhet të kryejnë detyra renderimi, me nyje që kanë resurse të lira për përpunimin e renderimit. Pronarët e resurseve do të lidhin stacionet e tyre me rrjetin e renderimit për të marrë dhe për të kryer detyrat e renderimit duke përdorur një nga motorët e renderimit të mbështetur nga rrjeti. Furnizuesit e detyrave do të punojnë me rrjetin si me një cloud, duke kryer vetë shpërndarjen e burimeve, mbikëqyrjen e saktësisë së realizimit, menaxhimin e riskut dhe probleme të tjera.
Kështu, ne do të shqyrtojmë krijimin e një kornize që duhet të mbështesë integrimin me një grup motorësh të njohur renderimi dhe të përmbajë komponente që ofrojnë mjete për organizimin e një rrjeti nga nyje të ndryshme dhe menaxhimin e rrjedhës së detyrave.
Modeli ekonomik i ekzistencĂ«s sĂ« njĂ« rrjeti tĂ« tillĂ« nuk ka rĂ«ndĂ«si thelbĂ«sore, prandaj do ta marrim si bazĂ« njĂ« skemĂ« tĂ« ngjashme me atĂ« qĂ« aplikohet nĂ« llogaritjet nĂ« rrjetet kriptomonedhave â konsumatorĂ«t e burimeve do tĂ« dĂ«rgojnĂ« token te furnizuesit qĂ« kryejnĂ« punĂ«n e renderimit. MĂ« interesante Ă«shtĂ« tĂ« kuptojmĂ« se cilat cilĂ«si duhet tĂ« ketĂ« korniza, pĂ«r tĂ« cilĂ«n do tĂ« shqyrtojmĂ« skenarin kryesor tĂ« ndĂ«rveprimit tĂ« pjesĂ«marrĂ«sve nĂ« rrjet.
Në rrjet ka tre palë ndërveprimi: furnizuesi i burimeve, furnizuesi i detyrave dhe operatori i rrjetit (ai që është qendra e menaxhimit, rrjeti dhe etj. në tekst).
Operatori i rrjetit i siguron ofruesit të burimeve një aplikacion-klient ose një imazh të sistemit operativ me një grup të plotë softuerësh, që ai do të instalojë në makinën e cila do të ofrojë, dhe një panel personal të aksesueshëm përmes një ndërfaqeje web, që i lejon atij të përcaktojë parametrat e aksesit në burim dhe të menaxhojë në mënyrë të largët peizazhin e tij serverik: të kontrollojë parametrat e harduerit, të kryejë konfigurimin e largët, të ri-aktivizojë.
Sistemi i menaxhimit të rrjetit gjatë lidhjes së një nyje të re kryen një analizë të pajisjeve dhe parametrave të dhënë të aksesit, e rendit atë, duke i dhënë një rang të caktuar, dhe e regjistron atë në regjistrat e burimeve. Më pas, me qëllim menaxhimin e rrezikut, parametrat e aktivitetit të nyjës do të analizohet dhe rangu i nyjës do të rregullohet për të siguruar stabilitetin e funksionit të rrjetit. Askush nuk do të ishte i kënaqur nëse skena e tij do të dërgohej për të u renderuar në karta të fuqishme, por që shpesh ngecin nga mbinxehja.
Përdoruesi, i cili ka nevojë të renderojë ndonjë skenë, mund të ndjekë dy rrugë: të ngarkojë skenën në depozitat e rrjetit përmes ndërfaqes web ose duke përdorur një plugin të lidhë paketën e tij të modelimit ose të vendosurën e renderimit në rrjet. Në këtë rast, ndërmjet përdoruesit dhe rrjetit inicion një kontratë të mençur, kushti standard i përfundimit të së cilës është gjenerimi i rezultatit të llogaritjes së skenës nga rrjeti. Përdoruesi mund ta ndjekë procesin e ekzekutimit dhe të menaxhojë parametrat e tij përmes ndërfaqes web të panelit të tij personal.
Detyra arrin në server, ku analizohet volumi i skenës dhe numri i burimeve të kërkuara nga iniciatori i detyrës, pas së cilës kryhet dekompozimi i volumit të përgjithshëm në pjesë, të adaptohara për llogaritjen në numrin dhe llojin e burimeve të dedikuara nga rrjeti. Ideja e përgjithshme është se vizualizimi mund të ndahet në shumë detyra të vogla. Motorët përfitojnë nga ky avantazh, duke shpërndarë këto detyra midis shumë ofruesve të burimeve. Mënyra më e thjeshtë është renderimi i pjesëve të vogla të skenës, të quajtura segmente. Kur çdo segment është gati, detyra lokale konsiderohet e përfunduar, burimi kalon në ekzekutimin e detyrës tjetër të pa zgjidhur.
Prandaj, për renderer-in nuk ka ndonjë dallim thelbësor nëse llogaritjet kryhen në një makinë të vetme ose në një gridi të shumë stacioneve të llogaritjes së veçantë. Renderimi i shpërndarë thjesht shton më shumë bërthama në grupin e burimeve të përdorura për detyrën. Nëpërmjet rrjetit, ai merr të dhënat e nevojshme për renderimin e segmentit, e llogarit atë, e dërgon këtë segment prapa dhe kalon në detyrën tjetër. Para se të hyjë në grupin e përbashkët të rrjetit, çdo segment merr një set metainformacionesh që i lejon nodet ekzekutues të zgjedhin detyrat më të përshtatshme për ta.
Detyrat e segmentimit dhe shpërndarjes së llogaritjeve duhet të zgjidhen jo vetëm nga perspektiva e optimizimit të kohës së ekzekutimit, por gjithashtu nga këndvështrimi i përdorimit optimal të burimeve dhe kursimit të energjisë, pasi kjo ndikon në efikasitetin ekonomik të rrjetit. Në rast të një vendimi të dështuar, do të ishte më e arsyeshme të vendoset një miner në nod ose ta fikim atë, për të mos bërë zhurmë dhe për të mos shpenzuar energji elektrike.
Megjithatë, le të kthehemi te procesi. Kur merr një detyrë, gjithashtu formohet një kontratë inteligjente midis grupit dhe nodit, e cila ekzekutohet kur rezultati i llogaritjes është i saktë. Pas përfundimit të kontratës, nodi mund të marrë shpërblime në ndonjë format.
Qendra e menaxhimit kontrollon procesin e ekzekutimit të detyrës, duke mbledhur rezultatet e llogaritjeve, duke dërguar për përpunim të përsëritur ato që janë të pasakta dhe duke renditur radhën, duke ndjekur afatin e rregullt të ekzekutimit të detyrave (që të mos ndodhë që segmenti i fundit të mos merret në punë nga asnjë nod).
Rezultatet e llogaritjeve kalojnë në fazën e kompozimit, pas së cilës përdoruesi merr rezultatet e renderimit, dhe rrjeti mund të marrë shpërblimin.
Kështu, përbërja funksionale e kornizës për peizazhin shfaqet, e cila është e destinuar për ndërtimin e sistemeve të renderimit të shpërndarë:
- Kategoritë personale të përdoruesve me qasje në web
- Pako software për instalim në nodet
- Nga sistemet e menaxhimit:
- Nën-sistemi i menaxhimit të aksesit
- Nën-sistemi i dekompozimit të detyrave të renderimit
- Nën-sistemi i shpërndarjes së detyrave
- NĂ«n-sistemi i kompozimit
- Nën-sistemi i menaxhimit të peizazhit të serverit dhe topologjisë së rrjetit
- NĂ«n-sistemi i regjistrimit dhe auditit
- Nën-sistemi ekspert i mësimit
- Rest API ose një ndërfaqe tjetër për zhvilluesit e jashtëm
ĂfarĂ« mendoni ju? Cilat pyetje ngre kjo temĂ« dhe cilat pĂ«rgjigje ju interesojnĂ«?
Burimi: habr.com
