УДК 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. Реализованная архитектура.
Всего в качестве серверов-участников кластера, ресурсы которых как раз и задействуются в процессе рендера или моделировании, использовалось два сервера, но как уже раньше и говорилось, шлюз тоже может являться.
Все сервера были объединены в виртуальную сеть на базе OpenVPN, что дало возможность задействовать некоторые мощности, которые не находятся в одной и той же локальной сети с другими серверами.
Так как предполагался как раз-таки распределенный принцип работы и обеспечение балансировки нагрузок на сервера, то для этого понадобилась отдельная подсистема хранения данных, на которой располагаются все профили хоть раз подключавшихся пользователей. Такое решение способствует тому, что любой сервер-участник кластера использует как раз эти профили при подключении к нему клиента, а не со своего локального хранилища.
Active Directory необходим для централизованного управления пользователями, чтобы не приходилось каждый раз вручную создавать необходимых пользователей на каждой сервере-участнике при этом соблюдая принцип, что везде должны быть одинаковые учетные данные.
Принцип работы пользователя состоит в следующем:
- пользователь подключается к системе по протоколу RDP или WEB-браузер, указывая при этом адрес шлюза;
- далее срабатывает алгоритм балансировки нагрузки, который автоматически определяет наименее загруженный сервер и переадресовывает пользователя на него.
- для начала дальнейшей работы пользователь запускает ПО для 3D моделирования. Пример работы изображен на рисунке 2.
Рисунок 2. Пример работы пользователя.
Стоит отметить, что привязки к тому, на чем разворачивать такую систему – нет. Так как весь функционал есть и на базе открытого программного обеспечения, за исключением самого 3ds Max. Поэтому почти любой из компонентов системы можно заменить на аналоги.
Платформа, построенная на предложенной архитектуре, легко поддается масштабированию. В любой момент времени кластер вычислительных ресурсов можно расширить путем подключения к виртуальной сети нового сервера или персонального компьютера. Далее этот компьютер необходимо подключить к системе хранения данных, домену и балансировщику нагрузки. После выполнения этих действий и установки специализированного ПО новый компьютер готов к эксплуатации.
Заключение
Таким образом, предложенный подход организации платформы как сервиса облачного рендеринга позволяет обеспечить выполнение своих рабочих обязанностей, например, не имея прямого доступа к своему рабочему месту в офисе. Такой подход применим не только к распределению работ, но и обеспечению учебного процесса, при котором необходимы достаточно высокие мощности персональных компьютеров. Еще одним преимуществом является то, что платформа территориально не привязана к одной сети или ЦОД, так как все сервера объединены через виртуальную сеть, все сервера доступны при условии, что у них есть доступ к этой сети.
Необходимую вычислительную мощность в данном случае можно обеспечить путем использования нескольких персональных компьютеров, но это зависит от задач, так как хоть несколько персональных компьютеров и могут быть и дешевле одного сервера по схожим характеристикам, они будут менее надежны.
Список литературы
- OpenCue [Электронный ресурс] URL: https://github.com/AcademySoftwareFoundation/OpenCue (дата обращения: 01.06.2023).
- Remote Desktop Gateway [Электронный ресурс] URL: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-access-from-anywhere (дата обращения: 01.06.2023).
- WineHQ [Электронный ресурс] URL: https://www.winehq.org/ (дата обращения: 01.06.2023).
- Облачные технологии: основные модели, приложения, концепции и тенденции развития [Электронный ресурс] URL: https://cyberleninka.ru/article/n/oblachnye-tehnologii-osnovnye-modeli-prilozheniya-kontseptsii-i-tendentsii-razvitiya-1 (дата обращения: 01.06.2023).
- Облачные технологии: основные понятия, задачи и тенденции развития [Электронный ресурс] URL: http://swsys-web.ru/cloud-computing-basic-concepts-problems.html (дата обращения: 01.06.2023).
- Тенденции и проблемы развития мирового ИТ-рынка [Электронный ресурс] URL: https://cyberleninka.ru/article/n/tendentsii-i-problemy-razvitiya-mirovogo-it-rynka (дата обращения: 01.06.2023).