През последните години новинарските емисии са залети с информация за нов тип разпределни изчислителни мрежи, които се появяват буквално от нищото и опитват да решават най-различни задачи — да направят градовете умни, да спасят света от нарушители на авторските права или обратно, тайно да предават информация или ресурси, да избягат от контрола на държавата в определени области. Независимо от сферата, всички те имат редица общи черти, произтичащи от факта, че горивото за техния растеж са алгоритми и методики, които излязоха на широката публика по време на последния бум на криптовалутите и свързаните с тях технологии. Вероятно всяка трета статия в специализираните източници по онова време съдържаше думата “блокчейн” в заглавието — обсъждането на нови софтуерни решения и икономически модели за известно време стана доминираща тенденция, на фона на която други области на приложение на разпределените изчисления бяха поставени на втори план.
В същото време визионерите и професионалистите осъзнаха основната същност на явлението: масовите разпределени изчисления, свързани с изграждането на мрежи от голям брой разпокъсани и хетерогенни участници, достигнаха ново ниво на развитие. Достатъчно е да изхвърлите хиповите теми от главата си и да погледнете на въпроса от друга страна: всички тези мрежи, съставени от огромни пулове, в които влизат хиляди отделни и разнородни участници, не се появиха сами по себе си. Ентусиастите на крипто-движението успяха да разрешат сложни проблеми със синхронизацията на данни и разпределението на ресурси и задачи по нов начин, което и позволи събирането на подобна маса от устройства и създаването на нова екосистема, предназначена за решаване на една узко насочена задача.
Разбира се, това не мина незабелязано от екипите и общностите, занимаващи се с развитието на свободни разпределени изчисления, и новите проекти не закъсняха.
Въпреки това, независимо от сериозното увеличаване на обема на наличната информация за разработките в областта на изграждането на мрежи и работата с оборудване, създателите на перспективни системи ще трябва да решават сериозни проблеми.
Проблемът, който е на първо място, колкото и странно да звучи, е проблемът с избора на направление.
Направлението може да е правилно, може да води в задънена улица — от това не можем да се избавим, централизирани доставки на ясновидци в IT общността все още изостават. Но изборът трябва да бъде направен, за да не попаднем в традиционната капан, състояща се в това, че екипът избира прекалено широка област и от самото начало се опитва да създаде още един неспециализиран проект за разпределени изчисления с широк профил. Изглежда, че фронтът на работа не е толкова страшен, основно трябва просто да приложим съществуващите разработки: да обединим възлите в мрежа, да адаптираме алгоритмите за определяне на топологиите, обмен на данни и контрол на тяхната консистентност, да внедрим методики за класифициране на възли и намиране на консенсус, а, разбира се, просто да създадем свой собствен език за заявки и всичкото езиково и изчислително обкръжение. Идеята за универсален механизъм е много примамлива и постоянно се появява в една или друга сфера, но в края на краищата получаваме едно от трите: създаденото решение или се оказва наистина ограничен прототип с куп висящи „ToDo“ в беклога, или става неизползваем монстър, готов да погълне всеки, който се докосне до него в зловещата „тюрингова трясина“, или просто успешно умира, защото проектираният в непонятна посока проект „лебед, рак и щука“ безславно се прекъсва.
Нямаме да повтаряме глупави грешки и ще изберем направление с ясна задача и добре подходящо за модела на разпределени изчисления. Можем да разберем хората, които опитват да направят всичко и веднага — изборът наистина е голям. И много неща изглеждат изключително интересни както от гледна точка на R&D и разработка, така и от икономическа гледна точка. С помощта на разпределена мрежа можем:
- Да обучаваме невронни мрежи
- Да обработваме потоци от сигнали
- Да изчисляваме структурата на белтъците
- Да провеждаме рендеринг на триизмерни сцени
- Да моделираме хидродинамика
- Да тестваме търговски стратегии за фондовите борси
За да не се увлечем в съставяне на списък с интересни неща, които добре се паралелизират, ще изберем като основна тема разпределен рендеринг.
Разпределеното рендериране само по себе не е ново явление. Съществуващите рендер-тулкове отдавна поддържат разпределение на натоварването между различни машини; без това, животът в двадесет и първи век щеше да е доста тъжен. Обаче, не бива да се мисли, че темата е изчерпана, и няма какво повече да се обсъжда — ще разгледаме конкретен актуален проблем: създаването на инструмент за изграждане на рендер мрежа.
Нашата рендер мрежа е съюз от възли, които трябва да изпълняват рендеринг задачи, със възли, които разполагат със свободни изчислителни ресурси за обработка на рендеринг. Собствениците на ресурси ще свързват своите станции към рендер мрежата, за да получават и изпълняват рендеринг задачи с помощта на един от поддържаните рендер двигатели. Доставчиците на задачи от своя страна ще работят с мрежата като с облак, който самостоятелно разпределя ресурсите, следи за коректността на изпълнението, управлява рисковете и решава други въпроси.
Следователно, ще разгледаме изграждането на фреймуърк, който трябва да поддържа интеграция с набор от популярни рендер двигатели и да съдържа компоненти, предоставящи инструменти за организиране на мрежа от различни възли и управление на потока от задачи.
Икономическата модел на съществуването на такава мрежа не е от основно значение, затова ще приемем схема, подобна на използваната при изчисленията в криптовалутни мрежи — потребителите на ресурс ще изпращат токени на доставчиците, извършващи рендеринг работа. Където е по-интересно да разберем, какви характеристики трябва да притежава фреймуъркът, ще разгледаме основния сценарий на взаимодействие между участниците в мрежата.
В мрежата съществуват три страни на взаимодействие: доставчик на ресурси, доставчик на задачи и оператор на мрежата (също и централен управител, мрежа и т.н. в текста).
Оператор на мрежата предоставя на доставчика на ресурси клиентско приложение или образ на операционната система с инсталиран набор от софтуер, който той ще инсталира на машината, чийто ресурси желае да предостави, и достъпен чрез уеб-интерфейс на личния кабинет, позволяващ му да задава параметри за достъп до ресурса и да управлява отдалечено своето сървърно пространство: да контролира хардуерните параметри, да извършва дистанционни настройки, да рестартира.
Системата за управление на мрежата при свързването на нов възел провежда анализ на оборудването и зададените параметри за достъп, класифицира го, присвоявайки му определен рейтинг, и го помещава в регистъра на ресурсите. В бъдеще, с цел управление на риска, параметрите на активността на възела ще бъдат анализирани и рейтингът на възела ще бъде коригиран, за да се осигури стабилността на работата на мрежата. Никому не би било приятно, ако сцената им бъде изпратена за рендериране на мощни, но често прегряващи графични карти?
Потребителят, който трябва да рендерира дадена сцена, може да избере два пътя: да зареди сцената в репозиториума на мрежата чрез уеб-интерфейса или с помощта на плъгин да свърже своя модел на пакет или инсталиран рендерер към мрежата. При това между потребителя и мрежата се инициира смарт-контракт, чийто стандартен условие за приключване е генерирането на резултат от изчисленията на сцената от мрежата. Потребителят може да следи хода на изпълнението на задачата и да управлява нейните параметри през уеб-интерфейса на своя личен кабинет.
Заданието постъпва на сървър, където се анализира обемът на сцената и количеството заявени от инициатора задачи ресурси, след което се извършва декомпозиция на общия обем на части, адаптирани за изчисления на определеното от мрежата количество и тип ресурси. Общата идея е, че визуализацията може да бъде разделена на множество малки задачи. Рендер механизмите се възползват от това предимство, разпределяйки тези задачи сред множество доставчици на ресурси. Най-простият начин е рендерирането на малки части от сцената, наречени сегменти. Когато всеки сегмент е готов, локалната задача се счита за завършена, ресурсът преминава към изпълнението на следващата от нерешените.
Следователно, за рендерера няма съществена разлика дали изчисленията се извършват на една машина или на мрежа от множество отделни изчислителни станции. Разпределеното рендериране просто добавя повече ядра към басейна на ресурсите, използвани за задачата. Чрез мрежата той получава всички данни, необходими за рендериране на сегмента, изчислява го, изпраща този сегмент обратно и преминава към следната задача. Преди да постъпи в общия басейн на мрежата, всеки сегмент получава набор от метаинформация, позволяваща на изпълнителните 节点 да избират най-подходящите за тях изчислителни задачи.
Задачите по сегментация и разпределение на изчисленията трябва да се решават не само от гледна точка на оптимизация на времето за изпълнение, но и от гледна точка на оптималното използване на ресурсите и пестенето на енергия, тъй като от това зависи икономическата ефективност на мрежата. В случай на неуспешно решение, по-добре е да се постави майнер на 节点 или да се изключи, за да не пречи и да не харчи електричество.
Но да се върнем към процеса. При получаване на задача между басейна и 节点 също се формира смарт-контракт, който се изпълнява при коректно изчисление на резултата от задачата. В края на изпълнението на договора 节点 може да получава възнаграждение по един или друг начин.
Центърът за управление контролира процеса на изпълнение на задачата, събирайки резултатите от изчисленията, изпращайки обратно за повторна обработка неправилните и ранжирайки опашката, следейки нормативния срок за изпълнение на задачата (за да не се случи така, че последният сегмент да не бъде обработен от нито един 节点).
Резултатите от изчисленията преминават през етапа на композиране, след което потребителят получава резултатите от рендеринга, а мрежата може да получи възнаграждение.
Така се очертава функционалният състав на ландшафтния фреймворк, предназначен за построяване на системи за разпределено рендериране:
- Лични профили на потребители с уеб достъп
- Комплект софтуер за инсталиране на 节点
- По отношение на системите за управление:
- Подсистема за управление на достъпа
- Подсистема за декомпозиция на задачите за рендериране
- Подсистема за разпределение на задачите
- Подсистема за композиране
- Подсистема за управление на сървърния ландшафт и топологията на мрежата
- Подсистема за логиране и одит
- Обучаема експертна подсистема
- Rest API или друг интерфейс за външни разработчици
Какво мислите вие? Какви въпроси предизвиква темата и какви отговори ви интересуват?
Източник: habr.com
