Во последниве години, вестите беа преплавени со пораки за нов тип на дистрибуирани компјутерски мрежи кои се појавуваат буквално од никаде, решавајќи (или подобро, обидувајќи се да решат) широк спектар на проблеми - правење град паметен, спасување на светот од авторски права прекршители или обратно, тајно пренесување информации или ресурси, бегање од -под државна контрола во една или друга област. Без разлика на полето, сите тие имаат голем број заеднички карактеристики поради фактот што гориво за нивниот раст беа алгоритмите и техниките кои дојдоа во јавноста за време на неодамнешниот бум на криптовалутите и сродните технологии. Веројатно секој трет напис за специјализирани ресурси во тоа време го имаше зборот „блокчејн“ во насловот - дискусијата за нови софтверски решенија и економски модели стана доминантен тренд некое време, на позадината на која беа други области на примена на дистрибуирани компјутерски системи. исфрлен во втор план.
Во исто време, визионерите и професионалците ја видоа главната суштина на феноменот: масовното дистрибуирано пресметување, поврзано со изградбата на мрежи од голем број различни и хетерогени учесници, достигна ново ниво на развој. Доволно е да ги исфрлите темите за возбуда од вашата глава и да ја погледнете темата од другата страна: сите овие мрежи, собрани од огромни базени, кои се состојат од илјадници изолирани хетерогени учесници, не се појавија сами по себе. Ентузијастите на крипто движењето можеа да решат сложени проблеми со синхронизација на податоци и дистрибуција на ресурси и задачи на нов начин, што овозможи да се состави слична маса на опрема и да се создаде нов екосистем дизајниран да реши еден тесно фокусиран проблем.
Се разбира, тоа не помина од тимовите и заедниците вклучени во развојот на бесплатно дистрибуирани компјутери, а новите проекти не чекаа долго да доаѓаат.
Сепак, и покрај значителното зголемување на обемот на достапни информации за случувањата во областа на градење мрежи и работа со опрема, креаторите на перспективни системи ќе мора да решат сериозни проблеми.
Првиот од нив, колку и да звучи чудно, е проблемот со изборот на насока.
Насоката може да биде точна, или може да доведе до ќорсокак - нема спас од ова; централизираните набавки на видовити за ИТ заедницата сè уште доцнат. Но, изборот мора да се направи за да не падне во традиционалната замка тимот да зазема премногу широка област и да се обиде да создаде уште еден неспецијализиран општо дистрибуиран компјутерски проект од самиот почеток. Се чини дека обемот на работа не е толку страшен, во најголем дел само треба да ги примениме постоечките случувања: комбинирање на јазли во мрежа, прилагодување на алгоритми за одредување топологии, размена на податоци и следење на нивната конзистентност, воведување методи за рангирање јазли и наоѓање консензус и, се разбира, само креирајте ваш сопствен јазик за пребарување и целата јазична и компјутерска околина. Идејата за универзален механизам е многу примамлива и постојано се појавува во една или друга област, но крајниот резултат е сепак една од трите работи: создаденото решение или излегува дека е ограничен прототип со куп суспендирани „ToDos“. „ во заостанатиот дел, или станува неупотребливо чудовиште подготвено да го одвлече секој што ќе го допре фетилното „Турингово мочуриште“ или едноставно да умира безбедно од фактот дека лебедот, ракот и штуката, кои го влечеа проектот во неразбирлива насока, едноставно се пренапрегаа.
Да не ги повторуваме глупавите грешки и да избереме насока која има јасен опсег на задачи и е добро прилагодена на моделот на дистрибуирани компјутери. Можете да ги разберете луѓето кои се обидуваат да направат сè одеднаш - се разбира, има многу да изберете. И многу работи изгледаат исклучително интересно и од гледна точка на истражување и развој и развој, и од гледна точка на економијата. Користејќи дистрибуирана мрежа, можете:
- Воз невронски мрежи
- Процес на сигнални текови
- Пресметајте ја структурата на протеините
- Рендерирајте XNUMXD сцени
- Симулирајте хидродинамика
- Тестирајте ги стратегиите за тргување за берзите
За да не се занесеме со составување листа на интересни работи кои се добро паралелизирани, ќе го избереме дистрибуираното рендерирање како наша понатамошна тема.
Самиот дистрибуиран рендер, се разбира, не е ништо ново. Постоечките алатки за рендерирање долго време поддржуваат дистрибуција на оптоварување низ различни машини; без ова, живеењето во дваесет и првиот век би било доста тажно. Сепак, не треба да мислите дека темата е опфатена надалеку и нема што да се прави таму - ќе разгледаме посебен проблем: создавање алатка за создавање мрежа за рендерирање.
Нашата мрежа за рендерирање е комбинација од јазли кои треба да извршуваат задачи за рендерирање со јазли кои имаат бесплатни компјутерски ресурси за обработка на рендерирање. Сопствениците на ресурси ќе ги поврзат своите станици со мрежата за рендерирање за да примаат и извршуваат задачи за рендерирање користејќи еден од поддржаните мотори за рендерирање на мрежата. Во овој случај, давателите на задачи ќе работат со мрежата како да е облак, независно дистрибуирајќи ресурси, следејќи ја исправноста на извршувањето, управувајќи со ризици и други проблеми.
Така, ќе размислиме за создавање рамка која треба да поддржува интеграција со збир на популарни рендер мотори и да содржи компоненти кои обезбедуваат алатки за организирање мрежа на хетерогени јазли и управување со текот на задачите.
Економскиот модел на постоење на таква мрежа не е од фундаментално значење, затоа како почетна шема ќе земеме шема слична на онаа што се користи при пресметките во мрежите на криптовалути - потрошувачите на ресурсот ќе испраќаат токени до добавувачите кои ја вршат работата за рендерирање. Многу поинтересно е да се разберат какви својства треба да има рамка, за што ќе го разгледаме главното сценарио на интеракција помеѓу учесниците во мрежата.
Постојат три страни на интеракција во мрежата: давател на ресурси, давател на задачи и мрежен оператор (наречен центар за контрола, мрежа, итн. во текстот).
Мрежниот оператор му обезбедува на давателот на ресурси клиентска апликација или слика од оперативниот систем со распореден сет софтвер, кој тој ќе го инсталира на машината чии ресурси сака да ги обезбеди и лична сметка достапна преку веб-интерфејсот, што ќе му овозможи да поставете ги параметрите за пристап до ресурсот и далечински управувајте со пејзажот на неговиот сервер: контролирајте ги хардверските параметри, извршете далечинска конфигурација, рестартирајте.
Кога е поврзан нов јазол, системот за управување со мрежата ја анализира опремата и наведените параметри за пристап, ја рангира, доделувајќи одредена оцена и ја става во регистарот на ресурси. Во иднина, за да се управува со ризикот, ќе се анализираат параметрите на активноста на јазолот и ќе се прилагоди рејтингот на јазолот за да се обезбеди стабилност на мрежата. Никој нема да биде задоволен ако нивната сцена биде испратена за рендерирање на моќни картички кои често се замрзнуваат поради прегревање?
Корисникот кој треба да рендерира сцена може да оди на два начина: да ја постави сцената во мрежно складиште преку веб-интерфејсот или да користи додаток за да го поврзе својот пакет за моделирање или инсталираниот рендерер на мрежата. Во овој случај, се иницира паметен договор помеѓу корисникот и мрежата, чиј стандарден услов за завршување е генерирање на резултатот од пресметката на сцената од страна на мрежата. Корисникот може да го следи процесот на завршување на задачата и да управува со неговите параметри преку веб-интерфејсот на неговата лична сметка.
Задачата се испраќа до серверот, каде што се анализира обемот на сцената и бројот на ресурси кои ги бара иницијаторот на задачата, по што вкупниот волумен се разложува на делови приспособени за пресметка на бројот и видот на ресурсите доделени од мрежата. . Општата идеја е дека визуелизацијата може да се подели на многу мали задачи. Моторите го користат ова со дистрибуција на овие задачи меѓу повеќе даватели на ресурси. Наједноставниот начин е да се рендерираат мали делови од сцената наречени сегменти. Кога секој сегмент е подготвен, локалната задача се смета за завршена, а ресурсот преминува на следната извонредна задача.
Така, не прави разлика како таков за рендерот дали пресметките се вршат на една машина или на мрежа од многу поединечни компјутерски станици. Дистрибуираното прикажување едноставно додава повеќе јадра во базенот на ресурси што се користат за задача. Преку мрежата, ги прима сите податоци потребни за прикажување на сегмент, го пресметува, го испраќа тој сегмент назад и продолжува на следната задача. Пред да влезе во општиот мрежен базен, секој сегмент добива збир на метаинформации кои им овозможуваат на јазлите за извршување да ги изберат најсоодветните компјутерски задачи за нив.
Проблемите на сегментација и дистрибуција на пресметките мора да се решат не само од гледна точка на оптимизација на времето на извршување, туку и од гледна точка на оптимално користење на ресурсите и заштеда на енергија, бидејќи економската ефикасност на мрежата зависи од ова . Ако решението е неуспешно, попрепорачливо е да се инсталира рудар на јазолот или да се исклучи за да не прави бучава и да не троши електрична енергија.
Сепак, да се вратиме на процесот. Кога ќе се прими задача, се формира и паметен договор помеѓу базенот и јазолот, кој се извршува кога резултатот од задачата е правилно пресметан. Врз основа на резултатите од исполнувањето на договорот, јазолот може да добие награда во една или друга форма.
Контролниот центар го контролира процесот на извршување на задачата, собирање резултати од пресметката, испраќање неточни за повторна обработка и рангирање на редот, следење на стандардниот рок за завршување на задачата (за да не се случи последниот сегмент да не биде преземен од кој било јазол).
Резултатите од пресметките минуваат низ фазата на составување, по што корисникот ги добива резултатите од рендерирањето, а мрежата може да добие награда.
Така, се појавува функционалниот состав на рамка за пејзаж дизајниран за изградба на системи за дистрибуирани рендерирање:
- Лични кориснички сметки со веб-пристап
- Софтверски комплет за инсталација на јазли
- Со контролен систем:
- Подсистем за контрола на пристап
- Подсистем за распаѓање на задачи за рендерирање
- Подсистем за дистрибуција на задачи
- Подсистем за составување
- Подсистем за управување со пејзаж на сервер и мрежна топологија
- Подсистем за евиденција и ревизија
- Експертски потсистем за учење
- Rest API или друг интерфејс за надворешни програмери
Што мислиш? Кои прашања ги поставува темата и кои одговори ве интересираат?
Извор: www.habr.com