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