УДК 004.75

Подходы к организации платформы как сервиса облачного рендеринга в задачах распределения коллективной работы

Смольянников Илья Викторович – научный сотрудник, главный специалист Центра безопасности информации Центра информационных технологий и систем органов исполнительной власти им. А.В. Старовойтова», г. Москва

Макаревич Артём Денисович – аспирант МИРЭА – Российского технологического университета

Аннотация: В статье рассмотрены основные виды платформ облачного рендеринга, их краткое описание и в каких областях возможно применять. Рассмотрены проблемы, которые возникают при применении таких платформ в процессе выполнения не только рабочих обязанностей, но и при обучении. Предложен типовой вариант архитектуры, который может помочь в распределении нагрузки на серверные мощности организации, но и с уменьшением затрат на организацию полноценной удаленной работы или процесса обучения. Приведен пример реализации предлагаемого подхода для решения задач создания отдельных моделей или сцен целиком с их дальнейшим рендерингом на распределенной инфраструктуре серверов.

Ключевые слова: 3D моделирование, прикладное программное обеспечение, облачный рендеринг, распределение работы.

Введение

В настоящее время широкое распространение получают задачи построения 3D-карт, моделей, целых виртуальных городов на основе реально существующих. С развитием технологий становятся более доступными улучшенные средства компьютерной графики, алгоритмов построения моделей и рендеринга. Все это влечет за собой повышение требований как к самим рабочим местам работников, так и к целым системам, в которые эти данные будут загружаться.

Также в современном мире к рынку информационных технологий возникли дополнительные требования к надежности, безопасности и отказоустойчивости прикладного программного обеспечения, которые используются в информационных системах [6].

Виды платформ

На сегодняшний день системы облачного рендеринга можно условно разделить на следующие категории:

  • рендеринг как SaaS (Software as a Service);
  • рендеринг на собственной инфраструктуре виртуальных машин, размешенных в облаке;
  • «коробочные решения» распределенного рендеринга.

Рассмотрим каждое решение, в частности.

Рендеринг как SaaS представляет из себя предоставляемую услугу, на базе фронтальных веб систем. Данный подход позволяет аутентифицированному на платформе пользователю получать доступ к вычислительным мощностям рендер-рига, посредством передачи через сеть исходного файла трехмерной модели в виде проекта.

Данный подход обладает рядом ограничений, которые в последствие влияют на производительность работников условной компании. В таком формальном устройстве передаваемый исходный проект, требует криптографической защиты сессии передачи, в целях устранения несанкционированного доступа к проектным решениям. На сегодняшний момент сервисов, совмещающих в себе два этих аспекта, не существует.

Так же бизнес-процессы компании обязаны быть перестроены. Мы получаем возможность предоставить услугу клиентам в режиме условного разделения вычислительных ресурсов рендер-фермы, представляя каждый загруженный проектный файл в виде задания на выполнения вычислений, что тривиально с точки зрения представления данных заданий в виде команд ОС и организации потоков.

Основным минусом данного подхода можно назвать необходимость иметь на машине клиента инструментальные средства компьютерной графики, а также проектных файлов. Данный фактор накладывает ограничения на хранимую локально информацию и требует дополнительного внимания, к процессу организации безопасности хранения данных локально у пользователя на компьютере.

Подход к организации на собственной инфраструктуре виртуальных машин, размешенных в облаке, позволяет нивелировать некоторую часть недостатков предыдущего подхода. Подход заключается, в размещении инструментальных средств КГ в виртуальной машине, входящей в состав «облачного сервиса» провайдера.

Стоит отметить, что подход организации системы на базе «коробочного» решения распределенного рендеринга, сочетает в себе плюсы предыдущих двух подходов. Но, основной чертой коробочного решения будет ориентирование всех технических процессов, на компанию провайдер «коробочного» решения и службу поддержки. Зачастую сложности сопровождающие коробочные решения такого уровня сопряжены с требованиями компаний, по открытости исходного кода разработки, возможности самостоятельного сопровождения развернутой технической системы и требованиями интеграции решения в общий контур системы безопасности предприятия, что зачастую невозможно в силу преобладающей проприетарной направленности подобных систем. На данный момент найдена единственная «коробочная» система данного рода с открытым исходным кодом, OpenCue [1].

Назначение

Все вышеперечисленные платформы имеют широкий спектр применения, включая решение научных, математических задач, где требуются значительные вычислительные ресурсы. Данные подходы можно отнести к идее облачных вычислений, которая широко развивается уже с 1990 года.

В настоящее время крупные вычислительные облака состоят из тысяч серверов, размещенных в центрах обработки данных (ЦОД). Они обеспечивают ресурсами десятки тысяч приложений, которые одновременно используют миллионы пользователей [4]. Облачные технологии являются удобным инструментом для предприятий, которым слишком дорого содержать собственные ERP, CRM или другие серверы, требующие приобретения и настройки дополнительного оборудования [5].

Но мы в данном случае рассматриваем более специфичную сферу применения таких систем, а именно организацию работ по оказанию услуг распределенного рендеринга для сотрудников, находящихся за пределами предприятия и не имеющими прямой доступ к своим рабочим местам в организации.

Типовая архитектура

По нашему представлению типовой архитектурой построения систем облачного рендеринга будет являться:

  • шлюз, который будет служить в качестве балансировщика нагрузки и направлять клиентов на разные сервера, в зависимости от выделенной квоты и существующей нагрузки на сервера;
  • сервер-рендер, на котором запущен специализированное ПО, при помощи которого и осуществляется рендер;
  • клиенты, которые подключаются со своих машин к удаленным рабочим столам на серверах или отправляют уже готовые модели, сцены и т.д. на рендер.

Дополнительными компонентами в платформе могут быть службы каталогов и подсистема хранения данных, которые будут отвечать за централизованное управление пользователей и хранение всех их наработок в одном месте.

Предлагаемый подход организации платформы облачного рендеринга

Мы рассмотрели несколько платформ и способов их организации для обеспечения работы удаленных сотрудников с рендер-системами. Но каждый из рассмотренных несет в себе определенные минусы. Поэтому не лишним будет предложить такой подход, который сможет либо эти минусы вовсе убрать, либо сделать их малозаметными по сравнению с пользой, которую может принести предложенный нами подход.

Так как в настоящее время все еще широко распространено программное обеспечение для 3D моделирования различных предметов, зданий, оборудования, интерьеров и т.д., от компании Autodesk, то основной операционной системой, на которой должен работать сервер-рендер должна оставаться Windows. Но в то же время допускается использовать операционную систему Linux и эмулятор для запуска приложений с Windows [3], что конечно может в какой-то степени повлиять на быстродействие сервера в целом.

Если мы используем сервер на базе Windows, то вся система должна быть построена на набор компонентов, относящихся к роли «Удаленный рабочий стол», что позволяет без особых проблем предоставлять доступ к вычислительным мощностям компьютера без дополнительного программного обеспечения. Дополнительно на таких серверах устанавливается ПО для 3D моделирования.

Шлюзом для всех клиентов и в то же время балансировщиком, который будет распределять их по различным серверам, подключенным в кластер будет являться сервер с ролью «Remote Desktop Gateway» [2] или его аналог. В то же время такой сервер может также предоставлять свои вычислительные мощности клиентам, но их процент необходимо ограничить, так как это повлияет на правильное функционирование его основной роли как шлюза.

Для предоставления доступа к таким вычислительным кластерам мы предлагаем использовать доменную организацию, при помощи которой можно гибко настроить права и квоты на сервера.

Принимая во внимание, что данная система может быть по большей части распределенной, то обмен информацией или пользовательскими ключами в домене нельзя напрямую выставлять в сети Интернет без какой-либо защиты каналов связи, все сервера можно объединить, например, через VPN-сеть или любой другой способ организации защищенной сети передачи данных.

В данной реализации требованием к клиентам будет только наличие любой рабочей станции с приемлемыми для комфортной работы характеристиками и стабильный доступ в Интернет.

Пример использования вышеописанного подхода

Перейдем к практическому применению предложенного подхода.

Все сервера в данном случае были основаны на операционной системе Windows. Главное требование к системе было – обеспечить возможность комфортной работы минимум 10 пользователей с возможностью одновременного запуска трех задач на рендеринг сцены. Сама цель создания такой системы была, как и в распределении задач, так и для обеспечения возможности проведения удаленного обучения учеников, у которых может и не быть достаточных мощностей для локального рендеринга больших интерьеров и высокополигональных моделей.

Итоговая архитектура изображена на рисунке 1.

 1

Рисунок 1. Реализованная архитектура.

Всего в качестве серверов-участников кластера, ресурсы которых как раз и задействуются в процессе рендера или моделировании, использовалось два сервера, но как уже раньше и говорилось, шлюз тоже может являться.

Все сервера были объединены в виртуальную сеть на базе OpenVPN, что дало возможность задействовать некоторые мощности, которые не находятся в одной и той же локальной сети с другими серверами.

Так как предполагался как раз-таки распределенный принцип работы и обеспечение балансировки нагрузок на сервера, то для этого понадобилась отдельная подсистема хранения данных, на которой располагаются все профили хоть раз подключавшихся пользователей. Такое решение способствует тому, что любой сервер-участник кластера использует как раз эти профили при подключении к нему клиента, а не со своего локального хранилища.

Active Directory необходим для централизованного управления пользователями, чтобы не приходилось каждый раз вручную создавать необходимых пользователей на каждой сервере-участнике при этом соблюдая принцип, что везде должны быть одинаковые учетные данные.

Принцип работы пользователя состоит в следующем:

  • пользователь подключается к системе по протоколу RDP или WEB-браузер, указывая при этом адрес шлюза;
  • далее срабатывает алгоритм балансировки нагрузки, который автоматически определяет наименее загруженный сервер и переадресовывает пользователя на него.
  • для начала дальнейшей работы пользователь запускает ПО для 3D моделирования. Пример работы изображен на рисунке 2.

2

Рисунок 2. Пример работы пользователя.

Стоит отметить, что привязки к тому, на чем разворачивать такую систему – нет. Так как весь функционал есть и на базе открытого программного обеспечения, за исключением самого 3ds Max. Поэтому почти любой из компонентов системы можно заменить на аналоги.

Платформа, построенная на предложенной архитектуре, легко поддается масштабированию. В любой момент времени кластер вычислительных ресурсов можно расширить путем подключения к виртуальной сети нового сервера или персонального компьютера. Далее этот компьютер необходимо подключить к системе хранения данных, домену и балансировщику нагрузки. После выполнения этих действий и установки специализированного ПО новый компьютер готов к эксплуатации.

Заключение

Таким образом, предложенный подход организации платформы как сервиса облачного рендеринга позволяет обеспечить выполнение своих рабочих обязанностей, например, не имея прямого доступа к своему рабочему месту в офисе. Такой подход применим не только к распределению работ, но и обеспечению учебного процесса, при котором необходимы достаточно высокие мощности персональных компьютеров. Еще одним преимуществом является то, что платформа территориально не привязана к одной сети или ЦОД, так как все сервера объединены через виртуальную сеть, все сервера доступны при условии, что у них есть доступ к этой сети.

Необходимую вычислительную мощность в данном случае можно обеспечить путем использования нескольких персональных компьютеров, но это зависит от задач, так как хоть несколько персональных компьютеров и могут быть и дешевле одного сервера по схожим характеристикам, они будут менее надежны.

Список литературы

  1. OpenCue [Электронный ресурс] URL: https://github.com/AcademySoftwareFoundation/OpenCue (дата обращения: 01.06.2023).
  2. Remote Desktop Gateway [Электронный ресурс] URL: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-access-from-anywhere (дата обращения: 01.06.2023).
  3. WineHQ [Электронный ресурс] URL: https://www.winehq.org/ (дата обращения: 01.06.2023).
  4. Облачные технологии: основные модели, приложения, концепции и тенденции развития [Электронный ресурс] URL: https://cyberleninka.ru/article/n/oblachnye-tehnologii-osnovnye-modeli-prilozheniya-kontseptsii-i-tendentsii-razvitiya-1 (дата обращения: 01.06.2023).
  5. Облачные технологии: основные понятия, задачи и тенденции развития [Электронный ресурс] URL: http://swsys-web.ru/cloud-computing-basic-concepts-problems.html (дата обращения: 01.06.2023).
  6. Тенденции и проблемы развития мирового ИТ-рынка [Электронный ресурс] URL: https://cyberleninka.ru/article/n/tendentsii-i-problemy-razvitiya-mirovogo-it-rynka (дата обращения: 01.06.2023).

Интересная статья? Поделись ей с другими: