В останні роки новинні стрічки наповнили повідомлення про розподілені обчислювальні мережі нового типу, що з'являються буквально з нізвідки, вирішують (точніше, намагаються вирішити) найрізноманітніші завдання — зробити місто розумним, врятувати світ від порушників авторських прав або навпаки, таємно передати інформацію або ресурси, втекти з -Під контролю держави в тій чи іншій сфері. Незалежно від сфери, всі вони мають низку загальних рис, обумовлених тим, що паливом для їх зростання з'явилися алгоритми та методики, що вийшли в широкі маси під час недавнього буму криптовалют та пов'язаних з ними технологій. Напевно, кожна третя стаття на профільних ресурсах на той час у назві мала слово "блокчейн" - обговорення нових програмних рішень та економічних моделей деякий час стало домінуючим трендом, на тлі якого інші сфери застосування систем розподілених обчислень були відсунуті на другий план.
У той же час візіонери та професіонали побачили основну суть явища: масові розподілені обчислення, пов'язані з побудовою мереж з великої кількості розрізнених та різнорідних учасників, вийшли на новий рівень розвитку. Достатньо викинути з голови хайпові теми і поглянути на предмет з іншого боку: всі ці мережі, зібрані з величезних пулів, у яких складаються тисячі відокремлених різнорідних учасників, з'явилися не власними силами. Ентузіасти крипто-руху змогли вирішити в новому ключі складні проблеми синхронізації даних та розподілу ресурсів та завдань, що й дозволило зібрати воєдино подібну масу обладнання та створити нову екосистему, призначену для вирішення одного вузькоспрямованого завдання.
Зрозуміло, це не пройшло повз команди та спільноти, що займаються розвитком вільних розподілених обчислень, і нові проекти не змусили на себе чекати.
Однак, незважаючи на серйозне збільшення обсягу доступних відомостей про напрацювання в галузі побудови мереж та роботи з обладнанням, творцям перспективних систем доведеться вирішувати серйозні проблеми.
Першою з них, хоч як дивно це звучало, є проблема вибору напряму
Напрямок може бути вірним, може вести в глухий кут — від цього не втекти, централізовані поставки ясновидців в IT-спільноту поки що запізнюються. Але вибір слід зробити, щоб не потрапити в традиційну пастку, яка полягає в тому, що команда бере надто широку область і зі старту намагається створити ще один неспеціалізований проект розподілених обчислень широкого профілю. Здається, що фронт робіт не такий страшний, треба здебільшого просто застосувати існуючі напрацювання: об'єднати вузли в мережу, адаптувати алгоритми визначення топологій, обміну даними та контролю їх консистентності, впровадити методики ранжирування вузлів та знаходження консенсусу, ну і, звичайно, лише створити свою мову запитів та все мовне та обчислювальне оточення. Ідея універсального механізму дуже приваблива і постійно спливає в тій чи іншій сфері, але на виході, як і раніше, виходить одне з трьох: створене рішення або виявляється насправді обмеженим прототипом з купою "ToDo", що підвисли в белогу, або стає неюзабельним монстром, готовим поцупити будь-кого, хто доторкнувся до смердючої "тьюрингової трясовини", або ж просто вмирає від того, що лебідь, рак і щука, що тягнули в незрозумілий бік, банально надірвалися.
Не будемо повторювати дурних помилок і виберемо напрямок, що має зрозуміле коло завдання і добре підходить під модель розподілених обчислень. Можна зрозуміти людей, які намагаються зробити все й одразу – вибрати, звичайно, є з чого. І багато що виглядає вкрай цікаво як з точки зору R&D та розробки, так і з погляду економіки. За допомогою розподіленої мережі можна:
- Навчати нейронні мережі
- Обробляти потоки сигналів
- Обчислювати структуру білків
- Проводити рендеринг тривимірних сцен
- Моделювати гідродинаміку
- Тестувати торгові стратегії для фондових бірж
Щоб не захоплюватися складанням списку цікавих речей, які добре паралеляться, виберемо як нашу подальшу тему розподілений рендеринг.
Сам собою розподілений рендеринг — явище, зрозуміло, жодного разу не нове. існуючі рендер-тулкіти давно підтримують розподіл навантаження різними машинами, без цього в двадцять першому столітті жити було б досить сумно. Проте не варто думати, що тема виїжджена вздовж і впоперек, і робити там нема чого — ми розглянемо окрему актуальну проблему: створення інструменту для формування рендер-мережі.
Мережа рендерингу у нас — це об'єднання вузлів, яким необхідно виконувати завдання рендерингу, з вузлами, які мають вільні обчислювальні ресурси для обробки рендерингу. Власники ресурсів підключатимуть свої станції до мережі рендерингу, щоб отримувати та виконувати завдання рендерингу з використанням одного з підтримуваних мережею рендер-движків. Постачальники завдань при цьому працюватимуть з мережею як із хмарою, яка самостійно виконує розподіл ресурсів, контроль коректності виконання, управління ризиками та інші проблеми.
Таким чином ми будемо розглядати створення фреймворку, який повинен підтримувати інтеграцію з набором популярних рендер-движків і містити компоненти, що надають інструментарій для організації мережі з різнорідних вузлів та управління потоком завдань.
Економічна модель існування подібної мережі не має принципового значення, тому за вихідну приймемо схему, схожу з застосовуваною у обчисленнях у криптовалютних мережах — споживачі ресурсу надсилатимуть токени постачальникам, які виконують роботу рендерингу. Куди цікавіше зрозуміти, які властивості має мати фреймворк, для чого розглянемо основний сценарій взаємодії учасників мережі.
У мережі існують три сторони взаємодії: постачальник ресурсів, постачальник завдань та оператор мережі (він центр управління, мережа тощо за текстом).
Оператор мережі надає постачальнику ресурсу додаток-клієнт або образ операційної системи з розгорнутим набором софту, які той встановить на машину, ресурси якої він хоче надати, та доступний через веб-інтерфейс особистий кабінет, що дозволяє йому задавати параметри доступу до ресурсу та віддалено керувати своїм серверним ландшафтом: контролювати параметри заліза, виконувати віддалену настройку, перезавантажувати.
Система управління мережею при підключенні нового вузла проводить аналіз обладнання та заданих параметрів доступу, ранжує його, привласнюючи певний рейтинг, та поміщає до реєстру ресурсів. Надалі з метою управління ризиком параметри активності вузла будуть аналізуватись, і рейтинг вузла коригуватиметься для забезпечення стабільності роботи мережі. Нікому ж не буде приємно, якщо їхню сцену відправлять рендеритися на потужні карти, що часто зависають від перегріву?
Користувач, якому необхідно відрендерити будь-яку сцену, може піти двома шляхами: завантажити сцену в репозиторій мережі через веб-інтерфейс або за допомогою плагіна підключити свій пакет моделювання або встановлений рендерер до мережі. При цьому між користувачем та мережею ініціюється смарт-контракт, штатною умовою завершення якого є генерація мережею результату обчислення сцени. Слідкувати за процесом виконання завдання та керувати його параметрами користувач може через веб-інтерфейс свого особистого кабінету.
Завдання надходить на сервер, де аналізується обсяг сцени та кількість запитаних ініціатором завдання ресурсів, після чого виконується декомпозиція загального обсягу на частини, адаптовані для обчислення на виділеній мережею кількості та тип ресурсів. Загальна ідея полягає в тому, що візуалізація може бути розбита на безліч невеликих завдань. Двигуни користуються цією перевагою, розподіляючи ці завдання серед багатьох постачальників ресурсів. Найпростіший спосіб - рендеринг невеликих частин сцени, які називаються сегментами. Коли кожен сегмент готовий, локальне завдання вважається виконаним, ресурс переходить до виконання наступного з невирішених.
Таким чином, для рендерера немає різниці, чи виконуються обчислення на одній машині або ж на гриді з безлічі окремих обчислювальних станцій. Розподілений рендеринг просто додає більше ядер у пул ресурсів, що використовуються для завдання. Через мережу він отримує всі дані, необхідні для рендерингу сегмента, обчислює його, відправляє цей сегмент назад і переходить до наступного завдання. Перед надходженням до загального пулу мережі кожен сегмент отримує набір метаінформації, що дозволяє вузлам-виконавцям вибирати найбільш підходящі для них обчислювальні завдання.
Завдання сегментації та розподілу обчислень при цьому повинні вирішуватись не тільки з точки зору оптимізації часу виконання, а й з точки зору оптимального використання ресурсів та енергозбереження, оскільки від цього залежить економічна ефективність мережі. У разі невдалого рішення на вузол доцільніше поставити майнер або вимкнути його, щоб не шумів і не витрачав електрику.
Однак повернемося до процесу. При отриманні задачі між пулом та вузлом також формується смарт-контракт, який виконується при коректному обчисленні результату задачі. За підсумками виконання договору вузол може отримувати винагороду у тому чи іншому вигляді.
Центр управління контролює процес виконання завдання, збираючи результати обчислень, відправляючи на повторну обробку некоректні та ранжуючи чергу, відстежуючи нормативний термін виконання завдання (щоб не сталося, що останній сегмент не береться в роботу жодним вузлом).
Результати обчислень проходять етап композингу, після чого користувач отримує результати рендерингу, а мережа може отримати винагороду.
Таким чином вимальовується функціональний склад ландшафтного фреймворку, призначеного для побудови систем розподіленого рендерингу:
- Особисті кабінети користувачів з веб-доступом
- Комплект ПЗ для встановлення на вузли
- За системою управління:
- Підсистема керування доступом
- Підсистема декомпозиції завдань рендерингу
- Підсистема розподілу завдань
- Підсистема композингу
- Підсистема управління серверним ландшафтом та топологією мережі
- Підсистема логування та аудиту
- Експертна підсистема, що навчається
- Rest API або інший інтерфейс для зовнішніх розробників
А що ви думаєте? Які питання породжує тема та які відповіді вам цікаві?
Джерело: habr.com