Sa nakalipas na mga taon, ang mga news feed ay dinagsa ng mga mensahe tungkol sa isang bagong uri ng mga distributed computing network na literal na lumilitaw nang wala saan, nilulutas (o sa halip, sinusubukang lutasin) ang iba't ibang uri ng mga problema - ginagawang matalino ang isang lungsod, na nagliligtas sa mundo mula sa copyright. mga lumalabag o vice versa, lihim na paglilipat ng impormasyon o mga mapagkukunan, pagtakas mula sa -sa ilalim ng kontrol ng estado sa isang lugar o iba pa. Anuman ang larangan, lahat sila ay may ilang karaniwang mga tampok dahil sa ang katunayan na ang gasolina para sa kanilang paglago ay ang mga algorithm at diskarte na dumating sa publiko sa panahon ng kamakailang boom sa mga cryptocurrencies at mga kaugnay na teknolohiya. Marahil ang bawat ikatlong artikulo sa mga dalubhasang mapagkukunan sa oras na iyon ay may salitang "blockchain" sa pamagat - talakayan ng mga bagong solusyon sa software at mga modelong pang-ekonomiya ang naging nangingibabaw na trend sa loob ng ilang panahon, laban sa background kung saan ang iba pang mga lugar ng aplikasyon ng mga distributed computing system ay na-relegated sa background.
Kasabay nito, nakita ng mga visionaries at mga propesyonal ang pangunahing kakanyahan ng phenomenon: ang napakalaking distributed computing, na nauugnay sa pagtatayo ng mga network mula sa isang malaking bilang ng mga disparate at heterogenous na mga kalahok, ay umabot sa isang bagong antas ng pag-unlad. Ito ay sapat na upang itapon ang mga paksa ng hype mula sa iyong ulo at tingnan ang paksa mula sa kabilang panig: ang lahat ng mga network na ito, na binuo mula sa malalaking pool, na binubuo ng libu-libong mga nakahiwalay na magkakaibang mga kalahok, ay hindi lumitaw sa kanilang sarili. Ang mga mahilig sa kilusang crypto ay nagawang lutasin ang mga kumplikadong problema ng pag-synchronize ng data at pamamahagi ng mga mapagkukunan at mga gawain sa isang bagong paraan, na naging posible upang pagsama-samahin ang isang katulad na masa ng kagamitan at lumikha ng isang bagong ekosistema na idinisenyo upang malutas ang isang makitid na nakatutok na problema.
Siyempre, hindi ito pumasa sa mga koponan at komunidad na kasangkot sa pagbuo ng libreng distributed computing, at hindi nagtagal ang mga bagong proyekto.
Gayunpaman, sa kabila ng makabuluhang pagtaas sa dami ng magagamit na impormasyon tungkol sa mga pag-unlad sa larangan ng pagbuo ng mga network at pagtatrabaho sa mga kagamitan, ang mga tagalikha ng mga promising system ay kailangang lutasin ang mga seryosong problema.
Ang una sa kanila, gaano man ito kakaiba, ay ang problema sa pagpili ng direksyon.
Maaaring tama ang direksyon, o maaari itong humantong sa isang dead end - walang pagtakas mula dito; ang mga sentralisadong supply ng mga clairvoyant sa komunidad ng IT ay huli pa rin. Ngunit ang pagpili ay dapat gawin upang hindi mahulog sa tradisyunal na bitag ng pangkat na kumukuha ng masyadong malawak na lugar at sinusubukang lumikha ng isa pang hindi espesyalisadong pangkalahatang ipinamahagi na proyekto ng computing mula sa simula. Tila ang saklaw ng trabaho ay hindi nakakatakot, para sa karamihan, kailangan lang nating ilapat ang mga umiiral na pag-unlad: pagsamahin ang mga node sa isang network, iakma ang mga algorithm para sa pagtukoy ng mga topologies, pagpapalitan ng data at pagsubaybay sa kanilang pagkakapare-pareho, ipakilala ang mga pamamaraan para sa pagraranggo ng mga node at paghahanap consensus, at, siyempre, lumikha lang ng sarili mong wika ng query at ang buong wika at kapaligiran sa pag-compute. Ang ideya ng isang unibersal na mekanismo ay napaka-nakatutukso at patuloy na lumalabas sa isang lugar o iba pa, ngunit ang resulta ay isa pa rin sa tatlong bagay: ang nilikha na solusyon ay maaaring maging isang limitadong prototype na may isang grupo ng mga nasuspinde " ToDos" sa backlog, o ito ay magiging isang hindi magamit na halimaw na handang kaladkarin ang sinumang humipo sa mabahong "Turing swamp", o simpleng mamatay nang ligtas mula sa katotohanan na ang swan, crayfish at pike, na hinihila ang proyekto sa isang hindi maintindihang direksyon. , na-overstrain lang ang kanilang mga sarili.
Huwag nating ulitin ang mga hangal na pagkakamali at pumili ng direksyon na may malinaw na hanay ng mga gawain at angkop na angkop sa distributed computing model. Maiintindihan mo ang mga taong sinusubukang gawin ang lahat nang sabay-sabay - siyempre, maraming mapagpipilian. At maraming mga bagay ang mukhang lubhang kawili-wili kapwa mula sa punto ng view ng R&D at pag-unlad, at mula sa punto ng view ng ekonomiya. Gamit ang isang distributed network maaari kang:
- Sanayin ang mga neural network
- Iproseso ang mga stream ng signal
- Kalkulahin ang istraktura ng protina
- Mag-render ng mga XNUMXD na eksena
- Gayahin ang hydrodynamics
- Subukan ang mga diskarte sa pangangalakal para sa mga palitan ng stock
Upang hindi madala sa pag-compile ng isang listahan ng mga kawili-wiling bagay na mahusay na parallelize, pipiliin namin ang distributed rendering bilang aming karagdagang paksa.
Ang distributed rendering mismo ay, siyempre, walang bago. Matagal nang sinusuportahan ng mga kasalukuyang render toolkit ang pamamahagi ng load sa iba't ibang makina; kung wala ito, ang pamumuhay sa ikadalawampu't unang siglo ay magiging malungkot. Gayunpaman, hindi mo dapat isipin na ang paksa ay nasaklaw sa malayo at malawak, at walang magagawa doon - isasaalang-alang namin ang isang hiwalay na problema sa pagpindot: paglikha ng isang tool para sa paglikha ng isang render network.
Ang aming network ng pag-render ay isang kumbinasyon ng mga node na kailangang magsagawa ng mga gawain sa pag-render gamit ang mga node na may mga libreng mapagkukunan sa pag-compute para iproseso ang pag-render. Ikokonekta ng mga may-ari ng mapagkukunan ang kanilang mga istasyon sa network ng pag-render upang tumanggap at magsagawa ng mga trabaho sa pag-render gamit ang isa sa mga sinusuportahang render engine ng network. Sa kasong ito, gagana ang mga tagapagbigay ng gawain sa network bilang isang ulap, independiyenteng namamahagi ng mga mapagkukunan, sinusubaybayan ang kawastuhan ng pagpapatupad, pamamahala sa peligro at iba pang mga problema.
Kaya, isasaalang-alang namin ang paglikha ng isang balangkas na dapat suportahan ang pagsasama sa isang hanay ng mga sikat na render engine at naglalaman ng mga bahagi na nagbibigay ng mga tool para sa pag-aayos ng isang network ng mga heterogenous na node at pamamahala sa daloy ng mga gawain.
Ang pang-ekonomiyang modelo ng pagkakaroon ng naturang network ay hindi pangunahing kahalagahan, kaya't kami ay kukuha bilang paunang pamamaraan ng isang pamamaraan na katulad ng ginamit sa mga kalkulasyon sa mga network ng cryptocurrency - ang mga mamimili ng mapagkukunan ay magpapadala ng mga token sa mga supplier na nagsasagawa ng gawaing pag-render. Mas kawili-wiling maunawaan kung anong mga katangian ang dapat magkaroon ng isang balangkas, kung saan isasaalang-alang namin ang pangunahing senaryo ng pakikipag-ugnayan sa pagitan ng mga kalahok sa network.
Mayroong tatlong panig ng pakikipag-ugnayan sa network: tagapagbigay ng mapagkukunan, tagapagbigay ng gawain at operator ng network (aka control center, network, atbp. sa teksto).
Ang network operator ay nagbibigay sa resource provider ng isang client application o isang operating system image na may naka-deploy na set ng software, na i-install niya sa machine na may mga resources na gusto niyang ibigay, at isang personal na account na naa-access sa pamamagitan ng web interface, na nagpapahintulot sa kanya na itakda ang mga parameter ng pag-access sa mapagkukunan at malayuang pamahalaan ang kanyang landscape ng server: kontrolin ang mga parameter ng hardware, magsagawa ng malayuang pagsasaayos, pag-reboot.
Kapag nakakonekta ang isang bagong node, sinusuri ng sistema ng pamamahala ng network ang kagamitan at tinukoy na mga parameter ng pag-access, niraranggo ito, nagtatalaga ng isang tiyak na rating, at inilalagay ito sa rehistro ng mapagkukunan. Sa hinaharap, upang pamahalaan ang panganib, ang mga parameter ng aktibidad ng node ay susuriin, at ang rating ng node ay isasaayos upang matiyak ang katatagan ng network. Walang matutuwa kung ang kanilang eksena ay ipapadala para i-render sa mga malalakas na card na kadalasang nag-freeze dahil sa sobrang init?
Ang isang user na kailangang mag-render ng isang eksena ay maaaring pumunta sa dalawang paraan: i-upload ang eksena sa isang network repository sa pamamagitan ng web interface, o gumamit ng isang plugin upang ikonekta ang kanilang modeling package o naka-install na renderer sa network. Sa kasong ito, ang isang matalinong kontrata ay pinasimulan sa pagitan ng user at ng network, ang karaniwang kundisyon para sa pagkumpleto nito ay ang pagbuo ng resulta ng pagkalkula ng eksena ng network. Maaaring subaybayan ng user ang proseso ng pagkumpleto ng isang gawain at pamahalaan ang mga parameter nito sa pamamagitan ng web interface ng kanyang personal na account.
Ang gawain ay ipinadala sa server, kung saan ang dami ng eksena at ang bilang ng mga mapagkukunan na hiniling ng tagapagpasimula ng gawain ay sinusuri, pagkatapos nito ang kabuuang dami ay nabulok sa mga bahagi na inangkop para sa pagkalkula sa bilang at uri ng mga mapagkukunang inilalaan ng network . Ang pangkalahatang ideya ay ang visualization ay maaaring hatiin sa maraming maliliit na gawain. Sinasamantala ito ng mga makina sa pamamagitan ng pamamahagi ng mga gawaing ito sa maraming tagapagbigay ng mapagkukunan. Ang pinakasimpleng paraan ay ang pag-render ng maliliit na bahagi ng eksena na tinatawag na mga segment. Kapag handa na ang bawat segment, ang lokal na gawain ay ituturing na nakumpleto, at ang mapagkukunan ay nagpapatuloy sa susunod na natitirang gawain.
Kaya, wala itong pagkakaiba para sa tagapag-render kung ang mga kalkulasyon ay ginagawa sa isang makina o sa isang grid ng maraming indibidwal na mga istasyon ng computing. Ang distributed rendering ay nagdaragdag lamang ng higit pang mga core sa pool ng mga mapagkukunang ginagamit para sa isang gawain. Sa pamamagitan ng network, natatanggap nito ang lahat ng data na kailangan upang mag-render ng isang segment, makalkula ito, ibabalik ang segment na iyon, at lumipat sa susunod na gawain. Bago pumasok sa pangkalahatang network pool, ang bawat segment ay tumatanggap ng isang set ng metainformation na nagpapahintulot sa mga executing node na piliin ang pinaka-angkop na mga gawain sa pag-compute para sa kanila.
Ang mga problema ng segmentation at pamamahagi ng mga kalkulasyon ay dapat malutas hindi lamang mula sa punto ng view ng pag-optimize ng oras ng pagpapatupad, kundi pati na rin mula sa punto ng view ng pinakamainam na paggamit ng mga mapagkukunan at pag-save ng enerhiya, dahil ang kahusayan sa ekonomiya ng network ay nakasalalay dito . Kung ang solusyon ay hindi matagumpay, mas maipapayo na maglagay ng minero sa node o patayin ito upang hindi ito makagawa ng ingay at hindi mag-aksaya ng kuryente.
Gayunpaman, bumalik tayo sa proseso. Kapag natanggap ang isang gawain, ang isang matalinong kontrata ay nabuo din sa pagitan ng pool at ng node, na isasagawa kapag ang resulta ng gawain ay wastong nakalkula. Batay sa mga resulta ng pagtupad sa kontrata, ang node ay maaaring makatanggap ng gantimpala sa isang anyo o iba pa.
Kinokontrol ng control center ang proseso ng pagpapatupad ng gawain, pagkolekta ng mga resulta ng pagkalkula, pagpapadala ng mga hindi tama para sa muling pagproseso at pagraranggo ng pila, pagsubaybay sa karaniwang deadline para sa pagkumpleto ng gawain (upang hindi mangyari na ang huling segment ay hindi kinuha ng anumang node).
Ang mga resulta ng mga kalkulasyon ay dumaan sa yugto ng pag-composite, pagkatapos nito ay natatanggap ng user ang mga resulta ng pag-render, at ang network ay maaaring makatanggap ng gantimpala.
Kaya, ang functional na komposisyon ng isang landscape framework na idinisenyo para sa pagbuo ng mga distributed rendering system ay lumalabas:
- Mga personal na user account na may access sa web
- Software kit para sa pag-install sa mga node
- Sa pamamagitan ng control system:
- Subsystem ng kontrol sa pag-access
- Pag-render ng task decomposition subsystem
- Subsystem ng pamamahagi ng gawain
- Pag-composite ng subsystem
- Landscape ng server at subsystem ng pamamahala ng topology ng network
- Pag-log at audit subsystem
- Pag-aaral ng dalubhasang subsystem
- Rest API o iba pang interface para sa mga external na developer
Ano sa tingin mo? Anong mga tanong ang itinataas ng paksa at anong mga sagot ang interesado ka?
Pinagmulan: www.habr.com