Миграция графических САПР в «облако»

Сергей Точилкин
Начальник отдела инфраструктурного ПО, компания «Открытые Технологии»

Зачем переносить графические САПР в «облако»

Для переноса графических приложений в «облако» есть несколько весьма серьезных  оснований:

• экономия вычислительных ресурсов;
• аутсорсинг вычислительных мощностей для графических приложений;
• защита интеллектуальной собственности;
• создание территориально распределенных проектных команд.

Степень применения пользователями любых вычислительных ресурсов, в том числе графической подсистемы, различна в зависимости от выполняемых задач. Кроме того, нагрузка, создаваемая разными пользователями,  неравномерна по времени. Эти факторы учитываются для экономии вычислительных мощностей с помощью терминальных решений и виртуализации рабочих станций (VDI).  Поэтому гораздо более эффективно вместо покупки каждому пользователю САПР выделенной рабочей станции  приобрести мощный графический сервер и обеспечить его совместное использование, как это делается для обычных офисных приложений. При этом крайне желательно было бы обеспечить квотирование графических ресурсов для разных групп пользователей, поскольку существующие средства виртуализации решают эту задачу для центрального процессора, оперативной памяти,  дисковой подсистемы и сетевых карт. 

Сервер с несколькими мощными GPU обладает еще одним значительным преимуществом по сравнению с разрозненными рабочими станциями.  Оно связано с приобретающими в последнее время популярность вычислениями общего назначения с применением графических процессоров. Возможность применения одного и того же программно­аппаратного комплекса для решения задач математического моделирования и инженерных расчетов, а также  визуализации выглядит весьма заманчиво. Актуальность подобных решений уже оценили производители, например технология NVIDIA Maximus позволяет объединять вычислительные мощности графических процессоров NVIDIA Quadro и вычислительных процессоров NVIDIA Tesla.

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

Перенос графических приложений в «облако» упрощает контроль утечек информации, являющейся интеллектуальной собственностью, так как обработка такой информации теперь может  осуществляться в рамках защищенного контура. Результаты работы  проектировщиков остаются в ЦОДе (например, в хранилище PLM­системы) и не попадают на компьютеры пользователей. 

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

Для ряда наших клиентов, использующих САПР и PLM­системы, сегодня стали актуальны задачи организации удаленной работы для членов проектных контрактных команд и обеспечения защиты интеллектуальной собственности. Наиболее эффективным решением представляется обработка информации, являющейся интеллектуальной собственностью, в рамках защищенного контура, который проще всего организовать, консолидировав обработку в центре обработки данных (ЦОДе). Попутно это позволяет получить и другие преимущества: экономию вычислительных ресурсов, улучшенное управление рабочими местами, высокий уровень доступности и производительности приложений.

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

В настоящей статье рассмотрены две технологии, которые, по нашему мнению, лучше других подходят для графических  САПР, — Citrix XenDesktop и NICE Cloud Desktop Virtualization.

Citrix XenDesktop

На рис. 1 представлена архитектура «облачного» решения для 3D­приложений с использованием Citrix XenDesktop.

Рис. 1. Архитектура «облака» Citrix XenDesktop

Для создания виртуальных  рабочих станций CitrixXenDesktop использует гипервизор CitrixXenServer 6, позволяющий добавлять в виртуальную машину физический графический адаптер с применением технологии PCI Passthrough. При этом гипервизор добавляет дополнительный слой абстракции в управление ресурсами виртуальных машин, объединяя идентичные GPU в группу и беря на себя управление выделением конкретного физического GPU конкретной виртуальной машине в момент ее старта.

Для поддержки технологии PCI Passthrough физический сервер должен поддерживать аппаратные технологии Intel VT­d или AMD IOMMU в зависимости от его аппаратной платформы.

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

Операционная система виртуальной рабочей станции распознает оригинальный физический GPU и использует драйверы производителя. Поддержка графических и вычислительных API: Microsoft DirectХ, DirectCompute, OpenGL, OpenCL, NVIDIA CUDA, ATI Stream — определяется поддержкой соответствующих API в драйверах производителя GPU.

На каждую виртуальную машину,  предназначенную для применения с 3D­приложениями, устанавливается ПО Citrix HDX 3D Pro. Этот компонент расширяет возможности протокола Citrix ICA, обеспечивая удаленную передачу трехмерного рабочего стола. При установке ПО Citrix HDX 3D Pro на виртуальную машину добавляется виртуальный дисплей, с помощью которого формируется передаваемое удаленному клиенту изображение трехмерного рабочего стола. При этом создаваемое изображение может сжиматься для сокращения используемой полосы пропускания сети, что особенно важно в случае удаленного доступа. Пользователь может вручную управлять качеством получаемой его клиентским компьютером картинки. Если виртуальной машине выделен GPU производства NVIDIA, поддерживающий API CUDA, то для сжатия HDX 3D Pro задействует вычислительные мощности графического ускорителя. HDX 3D Pro устанавливается не только на виртуальные машины, но и на физические рабочие станции. Таким образом, эта технология может применятся также для монтируемых в стойку рабочих станций. HDX 3D Pro совместима с операционными системами Windows XP и Windows 7, а кроме того поддерживает конфигурации с несколькими мониторами.

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

NICE Desktop Cloud Virtualization

Архитектура NICE Desktop Cloud Virtualization (далее — NICE DCV) значительно отличается от архитектуры решений Citrix. Прежде всего отметим ее особенности:

• поддержка только приложений, разработанных с использованием API OpenGL;
• NICE DCV совместимы только  с  графическими ускорителями NVIDIA;
• поддержка операционных систем Windows и Linux;
• интеграция с ПО RealVNC, расширяющая возможности протокола RFB (Remote Framebuffer);
• два режима работы;
• возможность применять для рендеринга локальные графические процессоры сервера или графические процессоры, установленные на другом сервере.

Два режима функционирования и поддержка удаленного рендеринга позволяют реализовать различные сценарии использования NICE DCV. На рис. 2 представлен режим Native Display. В нем удаленный доступ осуществляется к консольной сессии компьютера,  на котором исполняется 3D­приложение. Вследствие этого в таком режиме компьютер, играющий роль графического сервера, может обслужить только одного пользователя. Рассмотрим, как NICE DCV работает в данном режиме. Для функционирования NICE DCV на графическом сервере (компьютер, на котором запускается 3D­приложение) устанавливаются серверы RealVNC и NICE DCV, на клиентском компьютере — клиент RealVNC и клиентский компонент NICE DCV, который называется DCV End station. Последний встраивается в клиент RealVNC для получения и отображения формируемого на сервере изображения окна приложения.

Рис. 2. Режим работы NICE DCV — Native Display

Серверная часть NICE DCV встраивает в систему свою библиотеку OpenGL. В результате когда приложение, использующее API OpenGL, вызывает функции этого API, то библиотека NICE DCV перехватывает эти вызовы и передает их на обработку графической карте, а затем сжимает сформированное изображение окна приложения и отсылает его компоненту DCV End station на клиентском компьютере для отображения. Для сжатия изображений NICE DCV применяет ресурсы центрального процессора сервера приложений. Таким образом, NICE DCV отвечают только за формирование окна, использующего OpenGL, за передачу остальных элементов рабочего стола, перемещений мыши и нажатий клавиатуры отвечает RealVNC. Как видите, такой режим работы не обеспечивает разделения ресурсов GPU, однако он может применяться для других сценариев. Например, для удаленной работы с физическими рабочими станциями, установленными в центре обработки данных, или обеспечения удаленного доступа к вычислительному кластеру, построенному на базе GPU и выполняющему визуализацию  результатов вычислений.

Режим работы Native Display может использоваться под управлением операционных систем Windows и Linux. Под управлением операционной системы Windows пользовательским приложениям доступны вычислительные API NVIDIA CUDA, OpenCL и DirectCompute, под управлением операционной системы Linux — NVIDIA CUDA и OpenCL.

Рис. 3. Режим работы NICE DCV — Display Isolation

Второй режим работы NICE DCV называется Display Isolation. Он возможен только под управлением операционной системы Linux. На рис. 3 представлена схема его работы. Главное его отличие от режима Native Display заключается в том, что используются виртуальные дисплеи, получаемые средствами сервера  RealVNC. Такие дисплеи могут создаваться для каждого пользователя сервера приложений, и каждый из них будет функционировать в рамках отдельной пользовательской сессии. Когда  пользователь запускает приложения, серверные компоненты NICE DCV, как и в предыдущем случае, перехватывают вызовы функций OpenGL и передают их на обработку графической карте, а затем сжимают сформированное изображение окна приложения и отсылают его компоненту DCV End station на клиентском компьютере для отображения.

Для работы с графическими картами серверные компоненты DCV применяют X­серверы. Если на сервере приложений установлено несколько GPU, то для каждого из них создается отдельный дисплей X­сервера. В процессе работы серверные компоненты NICE DCV динамически связывают экземпляры приложений с дисплеями X­сервера. При этом принадлежность приложений к пользовательским сессиям не учитывается. Благодаря этому обеспечивается не только разделение вычислительных ресурсов одного GPU между несколькими пользователями, но и утилизация нескольких GPU одним пользователем. Последнее также может достигаться за счет объединения графических карт с помощью технологии NVIDIA SLI. В данном режиме пользовательским приложениям доступны вычислительные API NVIDIA CUDA и OpenCL.

К сожалению, не для всех приложений разрабатываются версии для операционной системы. Разделение ресурсов GPU между пользователями Windows­приложений может быть реализовано посредством удаленного рендеринга. Принципы работы удаленного рендеринга продемонстрированы на рис. 4.

Рис. 4. Режим удаленного рендеринга NICE DCV

В сценарии удаленного рендеринга задействованы три участника: сервер приложений, клиентский компьютер и сервер рендеринга. На сервер приложений и клиентский компьютер устанавливаются компоненты, аналогичные двум предыдущим сценариям. Сервер приложений не имеет собственного физического GPU. Графические ускорители устанавливаются в сервер рендеринга, на котором запускается агент рендеринга DCV. Серверу приложений указывается сервер рендеринга, который он должен использовать для перенаправления вызовов функций API OpenGL. Когда приложение, применяющее API OpenGL, вызывает функции данного API,  библиотека NICE DCV перехватывает эти вызовы и передает их на обработку серверу рендеринга через агент рендеринга DCV. Последний отправляет полученные вызовы на обработку локальным библиотекам OpenGL, которые используют для формирования изображения ресурсы графических ускорителей. Агент рендеринга сжимает сформированное графическим ускорителем изображение окна приложения и передает его напрямую компоненту DCV End station на клиентском компьютере, минуя сервер приложения. Для сжатия агент рендеринга применяет ресурсы центрального процессора сервера рендеринга.

Для работы с графическими картами агенты рендеринга используют X­серверы. Если на сервере рендеринга установлено несколько GPU, то для каждого из них создается отдельный дисплей X­сервера. Агенты рендеринга динамически связывают экземпляры приложений с дисплеями X­сервера. При этом принадлежность экземпляров приложений к серверам приложений не учитывается. За счет этого два разных приложения, запущенных на одном сервере приложений, будут использовать ресурсы разных GPU сервера рендеринга. Графические карты на сервере рендеринга также могут объединяться с помощью технологии NVIDIA SLI.

 Для связи между сервером приложения и сервером рендеринга применяется протокол TCP. К среде передачи между сервером приложений и сервером рендеринга предъявляются требования низкой латентности и большой полосы пропускания. В соответствии с этим для организации такой среды (по информации от производителя) подходят следующие технологии:

• виртуальная host­only сеть, организуемая средствами гипервизора (ESXi, KVM, Xen);
• сеть InfiniBand;
• сети 10GBASE­XX.

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

Наиболее интересные сценарии использования технологии внешнего рендеринга  представлены на рис. 5 и 6. В обоих случаях применяется гипервизор VMware ESXi, но вместо него могут использоваться и XenServer, и Linux KVM.

Рис. 5. Архитектура «облака» NICE DCV для САПР (сценарий с виртуальной сетью)

В сценарии, представленном на рис. 5, GPU устанавливаются в тот же сервер, на котором работает гипервизор. Средствами гипервизора создаются виртуальные машины, исполняющие роль сервера приложений (как правило, под управлением Windows 7), и виртуальная машина, исполняющая роль сервера рендеринга. Сервер рендеринга и серверы приложений получают по два сетевых интерфейса: один принадлежит к виртуальной host­only сети, организуемой средствами гипервизора, и служит для передачи вызовов OpenGL, а второй задействуется для связи с клиентскими компьютерами, через него сервер рендеринга и серверы приложений взаимодействуют с клиентским компьютером пользователя.

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

Рис. 6. Архитектура «облака» NICE DCV для САПР (сценарий с InfiniBand)

В сценарии, представленном на рис. 6, GPU устанавливаются в выделенные физические серверы рендеринга. Для обеспечения высокой доступности  и балансировки нагрузки серверы рендеринга объединяются  в ферму. Ферма рендеринга соединяется с серверами виртуализации через сеть рендеринга, которая строится на базе оборудования  InfiniBand или 10 Гбит Ethernet. Для связи с клиентами ферма рендеринга использует сеть центра обработки данных.  На серверах виртуализации средствами гипервизора создаются виртуальные машины, исполняющие роль сервера приложений. Серверы приложений получают по два сетевых интерфейса: один принадлежит к виртуальной сети, соединенной с сетью рендеринга,  и служит для передачи вызовов OpenGL, а второй относится к виртуальной сети, соединенной с сетью центра обработки данных, и служит для связи с клиентскими компьютерами — через него сервер приложений взаимодействует с клиентским компьютером пользователя.

Такой сценарий имеет несколько важных достоинств:

• высокая доступность;
• возможность гибкого использования ресурсов GPU;
• возможность подключения к существующей инфраструктуре виртуальных рабочих столов.

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

Гибкое использование ресурсов GPU обеспечивает как более свободную балансировку нагрузки, создаваемой разными пользователями, так и возможность применять ферму рендеринга, в которой серверы объединены высокоскоростными и низколатентными интерфейсами, в качестве вычислительного кластера. Правда, здесь необходимо учитывать, что в ферме рендеринга можно использовать только GPU серии Quadro или Tesla 2070Q, которые оптимизированы для обработки чисел с плавающей запятой одинарной точности. Это ограничение связано с тем, что GPU серии Tesla, оптимизированные для обработки чисел с плавающей запятой двойной точности, не поддерживают графические API OpenGL и DirectX.

Возможность подключения к существующей инфраструктуре виртуальных рабочих столов означает, что ферма рендеринга может быть подключена к ней без смены платформы виртуализации и платформы управления. Виртуальная машина, применяемая для запуска графического приложения, будет отличаться от обычных виртуальных машин наличием сетевого интерфейса, подключенного к сети InfiniBand, установленными серверными компонентами NICE DCV и RealVNC, а также протоколом доступа RFB. 

Основной недостаток данного сценария — более высокая цена, что обусловлено необходимостью построения сети InfiniBand или 10 Гбит Ethetnet.

Выводы

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

Достоинствами Citrix XenDesktop являются использование аппаратного ускорения для сжатия потока, передаваемого на клиентский терминал, и возможность гибкой настройки применяемой полосы пропускания, что особенно важно для сценариев удаленного доступа. Технология может использовать GPU, объединенные средствами NVIDIA SLI или ATI CrossFireX. К достоинствам решения Citrix следует также отнести наличие развитой системы управления виртуальными рабочими столами. Основной недостаток Citrix XenDesktop — невозможность разделения ресурсов одного GPU между несколькими виртуальными машинами. Однако в ближайшее время  этот недостаток может быть устранен благодаря интеграции c NVIDIA VGX (см. врезку «NVIDIA VGX»).

Среди достоинств NICE DCV следует отметить, во­первых, разделение ресурсов GPU между пользователями, а во­вторых, возможность двойного применения серверов рендеринга — как для рендеринга в графических приложениях, так и в качестве высокопроизводительного вычислительного кластера. Правда, нужно учитывать, что одновременно обе задачи сервер рендеринга решать не может. В­третьих, возможность встраивать NICE DCV в инфраструктуры виртуализации VMware и Citrix, добавляя таким образом необходимую функциональность с минимальными издержками.

Основной недостаток NICE DCV — это отсутствие поддержки API Microsoft DirectX. Однако в ближайшее время он, видимо, будет устранен, так как производитель планирует интегрировать в NICE DCV возможности технологии NVIDIA VGX. Еще один недостаток — необходимость построения сети InfiniBand и тонкой настройки производительности в сценариях с удаленным рендерингом. Последний недостаток — поддержка графических ускорителей  исключительно производства NVIDIA.

Выбор одной из представленных в статье технологий зависит от используемых приложений (OpenGL и/или DirectX), решаемых задач (только графика или графика плюс вычисления), имеющихся технических средств (AMD или NVIDIA) и бюджета проекта. 

САПР и графика 12`2012