En la lastaj jaroj, novaĵfluoj estis inunditaj per mesaĝoj pri nova speco de distribuitaj komputikretoj aperantaj laŭvorte el nenie, solvante (aŭ pli ĝuste, provante solvi) vastan gamon de problemoj - igante urbon inteligenta, savante la mondon de kopirajto. malobeantoj aŭ inverse, sekrete transdonante informojn aŭ rimedojn, eskapi el -sub ŝtata kontrolo en iu aŭ alia areo. Sendepende de la kampo, ili ĉiuj havas kelkajn komunajn trajtojn pro la fakto, ke la brulaĵo por ilia kresko estis la algoritmoj kaj teknikoj, kiuj venis al la publiko dum la lastatempa eksplodo de kriptaj moneroj kaj rilataj teknologioj. Verŝajne ĉiu tria artikolo pri specialaj rimedoj tiutempe havis la vorton "blokĉeno" en la titolo - diskuto pri novaj softvarsolvoj kaj ekonomiaj modeloj fariĝis la domina tendenco dum kelka tempo, sur la fono de kiu aliaj kampoj de apliko de distribuitaj komputikaj sistemoj estis. forigita al la fono.
Samtempe, viziuloj kaj profesiuloj vidis la ĉefan esencon de la fenomeno: amasa distribuita komputado, asociita kun la konstruado de retoj de granda nombro da malsimilaj kaj heterogenaj partoprenantoj, atingis novan evolunivelon. Sufiĉas forĵeti la hype-temojn el via kapo kaj rigardi la temon de la alia flanko: ĉiuj ĉi tiuj retoj, kunvenitaj el grandegaj naĝejoj, kiuj konsistas el miloj da izolitaj heterogenaj partoprenantoj, ne aperis memstare. Entuziasmuloj de la kripta movado povis solvi kompleksajn problemojn pri sinkronigado de datumoj kaj distribuado de rimedoj kaj taskoj en nova maniero, kio ebligis kunmeti similan amason da ekipaĵoj kaj krei novan ekosistemon destinitan por solvi unu mallarĝe fokusitan problemon.
Kompreneble, ĉi tio ne preterpasis la teamoj kaj komunumoj implikitaj en la disvolviĝo de senpaga distribua komputado, kaj novaj projektoj ne longe atendis.
Tamen, malgraŭ la signifa kresko de la volumo de disponeblaj informoj pri evoluoj en la kampo de konstruado de retoj kaj laborado kun ekipaĵoj, la kreintoj de promesplenaj sistemoj devos solvi gravajn problemojn.
La unua el ili, kiom ajn strange ĝi sonus, estas la problemo pri elekto de direkto.
La direkto povas esti ĝusta, aŭ ĝi povas konduki al sakstrato - de tio ne estas eskapo; centralizitaj provizoj de klarvidantoj al la IT-komunumo ankoraŭ malfruas. Sed la elekto devas esti farita por ne fali en la tradician kaptilon de la teamo prenanta tro larĝan areon kaj provante krei alian ne-specialan ĝeneralan distribuitan komputikprojekton de la komenco. Ŝajnas, ke la amplekso de laboro ne estas tiom timiga, plejparte ni nur bezonas apliki ekzistantajn evoluojn: kombini nodojn en reton, adapti algoritmojn por determini topologiojn, interŝanĝi datumojn kaj monitori ilian konsistencon, enkonduki metodojn por rangi nodojn kaj trovi. konsento, kaj, kompreneble, nur kreu vian propran demandlingvon kaj la tutan lingvon kaj komputilan medion. La ideo de universala mekanismo estas tre tenta kaj konstante aperas en iu aŭ alia areo, sed la fina rezulto estas ankoraŭ unu el tri aferoj: la kreita solvo aŭ rezultas esti limigita prototipo kun amaso da suspenditaj "Tadoj". ” en la restaro, aŭ ĝi fariĝas neuzebla monstro preta fortreni iun ajn, kiu tuŝas la fetidan “Turing-marĉon”, aŭ simple mortas sekure pro la fakto, ke la cigno, kankro kaj ezoko, kiuj tiris la projekton en nekomprenebla direkto, simple trostreĉis sin.
Ni ne ripetu stultajn erarojn kaj elektu direkton, kiu havas klaran gamon da taskoj kaj bone taŭgas al la distribuita komputika modelo. Vi povas kompreni homojn, kiuj provas fari ĉion samtempe - kompreneble, estas multe por elekti. Kaj multaj aferoj aspektas ege interesaj kaj el la vidpunkto de R&D kaj evoluo, kaj el la vidpunkto de ekonomio. Uzante distribuitan reton vi povas:
- Trejnu neŭralaj retoj
- Procesi signalfluojn
- Kalkuli proteinan strukturon
- Redonu XNUMXD-scenojn
- Simuli hidrodinamikon
- Provu komercajn strategiojn por borsoj
Por ne lasi sin kun kompilado de listo de interesaj aferoj, kiuj estas bone paraleligitaj, ni elektos distribuitan bildigon kiel nia plua temo.
Distribuita bildigo mem estas, kompreneble, nenio nova. Ekzistantaj bildaj ilaro longe subtenas ŝarĝan distribuon tra malsamaj maŝinoj; sen tio, vivi en la dudekunua jarcento estus sufiĉe malĝoja. Tamen vi ne devus pensi, ke la temo estis kovrita malproksime, kaj tie estas nenio por fari - ni konsideros apartan preman problemon: krei ilon por krei bildigan reton.
Nia bildiga reto estas kombinaĵo de nodoj, kiuj devas plenumi bildigajn taskojn kun nodoj, kiuj havas senpagajn komputigajn rimedojn por prilabori bildigon. Rimedposedantoj konektos siajn staciojn al la bildiga reto por ricevi kaj efektivigi bildlaborojn uzante unu el la subtenataj rendermotoroj de la reto. En ĉi tiu kazo, taskaj provizantoj laboros kun la reto kvazaŭ ĝi estus nubo, sendepende distribuante rimedojn, kontrolante la ĝustecon de ekzekuto, administrante riskojn kaj aliajn problemojn.
Tiel, ni konsideros krei kadron, kiu devus subteni integriĝon kun aro de popularaj bildmotoroj kaj enhavi komponantojn, kiuj provizas ilojn por organizi reton de heterogenaj nodoj kaj administri la fluon de taskoj.
La ekonomia modelo de la ekzisto de tia reto ne havas fundamentan gravecon, do ni prenos kiel la komencan skemon skemon similan al tiu uzata en kalkuloj en kriptaj retoj - konsumantoj de la rimedo sendos ĵetonojn al provizantoj plenumantaj la bildigan laboron. Estas multe pli interese kompreni, kiajn trajtojn devus havi kadro, por kiu ni konsideros la ĉefan scenaron de interago inter retaj partoprenantoj.
Estas tri flankoj de interagado en la reto: rimedoprovizanto, taskoprovizanto kaj retfunkciigisto (alinome kontrolcentro, reto, ktp. en la teksto).
La retfunkciigisto provizas la provizanton de rimedoj per klienta aplikaĵo aŭ bildo de operaciumo kun deplojita aro de programaro, kiun li instalos sur la maŝino, kies rimedojn li volas provizi, kaj personan konton alirebla per la interreta interfaco, permesante al li agordi alirparametrojn al la rimedo kaj malproksime administri lian servilan pejzaĝon: kontroli aparataron parametrojn, plenumi foran agordon, reboot.
Kiam nova nodo estas konektita, la reto-administra sistemo analizas la ekipaĵon kaj specifitajn alirparametrojn, vicigas ĝin, asignante certan takson kaj metas ĝin en la rimeda registro. Estonte, por administri la riskon, la agadparametroj de la nodo estos analizitaj, kaj la taksado de la nodo estos ĝustigita por certigi la stabilecon de la reto. Neniu ĝojos, se ilia sceno estas sendita por bildigi sur potencaj kartoj, kiuj ofte frostiĝas pro trovarmiĝo?
Uzanto, kiu bezonas bildigi scenon, povas iri du vojojn: alŝutu la scenon al reto-deponejo per la retinterfaco, aŭ uzi kromprogramon por konekti sian modelan pakaĵon aŭ instalitan bildilon al la reto. En ĉi tiu kazo, inteligenta kontrakto estas komencita inter la uzanto kaj la reto, kies norma kondiĉo por kompletigo estas la generacio de la rezulto de la scenkalkulo de la reto. La uzanto povas monitori la procezon de kompletigado de tasko kaj administri ĝiajn parametrojn per la retinterfaco de sia persona konto.
La tasko estas sendita al la servilo, kie la volumo de la sceno kaj la nombro da rimedoj petitaj de la tasko iniciatinto estas analizitaj, post kio la totala volumo estas malkomponita en partojn adaptitajn por kalkulo pri la nombro kaj speco de rimedoj asignitaj de la reto. . La ĝenerala ideo estas, ke bildigo povas esti dividita en multajn malgrandajn taskojn. Motoroj utiligas ĉi tion distribuante ĉi tiujn taskojn inter multoblaj rimedoprovizantoj. La plej simpla maniero estas redoni malgrandajn partojn de la sceno nomataj segmentoj. Kiam ĉiu segmento estas preta, la loka tasko estas konsiderata finita, kaj la rimedo pluiras al la sekva elstara tasko.
Tiel, ĝi faras neniun diferencon kiel tia por la bildilo ĉu la kalkuloj estas faritaj sur ununura maŝino aŭ sur krado de multaj individuaj komputikaj stacioj. Distribuita bildigo simple aldonas pli da kernoj al la aro de rimedoj uzataj por tasko. Tra la reto, ĝi ricevas ĉiujn datumojn necesajn por bildigi segmenton, komputas ĝin, resendas tiun segmenton kaj pluiras al la sekva tasko. Antaŭ eniri la ĝeneralan retan naĝejon, ĉiu segmento ricevas aron da metainformoj, kiuj permesas al ekzekutantaj nodoj elekti la plej taŭgajn komputikajn taskojn por ili.
La problemoj de segmentado kaj distribuado de kalkuloj devas esti solvitaj ne nur el la vidpunkto de optimumigo de ekzekuttempo, sed ankaŭ el la vidpunkto de optimuma uzo de rimedoj kaj energiŝparo, ĉar la ekonomia efikeco de la reto dependas de ĉi tio. . Se la solvo estas malsukcesa, estus pli konsilinde instali ministon sur la nodo aŭ malŝalti ĝin por ke ĝi ne bruu kaj ne malŝparu elektron.
Tamen, ni revenu al la procezo. Kiam tasko estas ricevita, inteligenta kontrakto ankaŭ estas formita inter la naĝejo kaj la nodo, kiu estas efektivigita kiam la taskorezulto estas ĝuste kalkulita. Surbaze de la rezultoj de plenumado de la kontrakto, la nodo povas ricevi rekompencon en unu formo aŭ alia.
La kontrolcentro kontrolas la procezon de ekzekuto de taskoj, kolektante kalkulrezultojn, sendante malĝustajn por reprocesado kaj rangado de la atendovico, kontrolas la norman templimon por plenumi la taskon (por ke ne okazu, ke la lasta segmento ne estas prenita de ajna nodo).
La rezultoj de la kalkuloj trairas la komponan etapon, post kiu la uzanto ricevas la bildigajn rezultojn, kaj la reto povas ricevi rekompencon.
Tiel, la funkcia kunmetaĵo de pejzaĝa kadro dizajnita por konstruado de distribuitaj bildsistemoj aperas:
- Personaj uzantkontoj kun ret-aliro
- Programaro por instalo sur nodoj
- Per kontrolsistemo:
- Subsistemo de alirkontrolo
- Iriga tasko-malkompona subsistemo
- Taskdistribua subsistemo
- Komponanta subsistemo
- Servila pejzaĝo kaj reto-topologia administradsubsistemo
- Subsistemo de registrado kaj revizio
- Lernanta sperta subsistemo
- Ripoza API aŭ alia interfaco por eksteraj programistoj
Kion vi pensas? Kiajn demandojn levas la temo kaj kiaj respondoj vi interesas?
fonto: www.habr.com