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