Тестируем NVIDIA GRID + VMware Horizon

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

Но объективного сравнения в лоб с локальной производительностью Quadro я не нашёл.

У нас в конфигураторе давно открыты модели серверов с поддержкой технологии GRID, ведь карты GRID (ранее VGX) появились уже давно.

Первые тесты не оправдали ожиданий, я ждал когда допилят драйверы, и постепенно перестал следить за прогрессом в этой области.

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

— Корпус CSE-745TQ
— Материнская плата X9DR3-F
— ЦП 2шт E5-2650
— ОЗУ 128Гб
— 8 SAS-дисков в RAID5

Оборудовали серверы картами GRID K2. В качестве гипервизора выбрали VMware. Установили специализированное ПО на виртуальные машины и провели тестирование.

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

Также захотелось оценить общую стоимость решения для сравнения с реализацией на базе персональной рабочей станции.
К счастью, на складе нашлись карты Quadro K5000 и Quadro K420.

Для начала, провел тесты локально на Windows 7 — получил результаты производительности Quadro K5000 и K420. Так как карта GRID K2 включает в себя 2 чипа, аналогичных чипу K5000, эти данные мне понадобятся для сравнения производительности виртуальных машин в различных режимах деления графических процессоров.

В самом начале появились трудности с охлаждением карты: GRID K2 имеет пассивное охлаждение, а корпус 745 не может обеспечить необходимый продув карты штатными способами. Пришлось установить 90мм-вентилятор на заднюю панель корпуса, заглушив полностью пустые слоты расширения. Чтобы не рисковать — выставил обороты на максимум. Шум от него получился значительный, но охлаждение — превосходное.





В сети есть множество пошаговых руководств по настройке и установке ПО, поэтому коротко пробегусь по основным пунктам.
После установки ESXI ставим необходимые драйверы и модули для GRID. Поднимаем vCenter и Horizon. Создаём виртуалку c Windows (например), обновляем ПО VMware и устанавливаем все обновления Windows. А вот дальнейшие настройки зависят от того, какой режим виртуализации GPU мы выбираем.

Есть 3 варианта:

• vSGA (распределение ресурсов GPU между виртуалками через драйвер VMware) — этот режим не интересный (высокая плотность, но крайне низкая производительность) и рассматриваться не будет.
• vDGA (физический проброс GPU в виртуальную машину с использованием родного драйвера NVIDIA) — этот режим также малоинтересен, так как не обеспечивает высокой плотности. Рассмотрим его только для сравнения с локальной работой Quadro K5000 и профиля vGPU K280Q.
• vGPU (проброс части ресурсов GPU в виртуальную машину с использованием специального драйвера NVIDIA) — это самый интересный и долгожданный вариант реализации, на него и возлагалась основная надежда, так как vGPU позволяет обеспечить беспрецедентную плотность виртуальных машин с использованием аппаратного 3D-ускорения.

vDGA

Для использования этого режима виртуализации, необходимо пробросить в виртуальную среду нашу карту GRID K2. Через vsphere client в настройках хоста выделяем устройства для передачи ресурсов виртуальным машинам.



После перезагрузки хоста в виртуальной машине выбираем новое PCI устройство.



Запускаем машину, ставим драйверы NVIDIA GRID и Horizon Agent. После перезагрузок в системе появляется физическая карта с родным драйвером NVIDIA и еще куча виртуальных устройств (устройства воспроизведения звука, микрофон и прочее).



Далее переходим к настройке Horizon. Через web-интерфейс создаем новый пул из готовых виртуальных машин.



Аппаратный рендеринг не включаем, так как у нас режим passthrough. Настраиваем права доступа к пулу. На данном этапе любое устройство с установленным Horizon-клиентом может использовать эту виртуальную машину.

Я попробовал подключение через iPhone 5.

3D отображалось с несильными задержками, а вот потоковое видео жутко тормозило. Так как при подключении по локалке все летало — я сделал вывод: либо тормоза вызваны беспроводной сетью, либо процессор телефона не справляется с распаковкой PCoIP.
Провел тесты на iPhone 5s — результат был получше. А вот iPhone 6 показал прекрасный результат.

Производительность на Android-смартфонах не сильно отличалась от iPhone 5, и работа была не очень комфортной. Но, в любом случае, гибкость доступа к виртуальной машине очевидна. Можно использовать уже существующий парк рабочих станций / офисных компьютеров. Либо можно пересесть на тонкие клиенты. Horizon-клиент ставится практически на любую популярную ОС.

Также существует уже готовая сборка на linux. В неё уже входит необходимый клиент и стоит она около $40.

Итак, в режиме vDGA мы можем создать 2 виртуальные машины на каждую карту K2, которые будут монопольно использовать каждая свой GPU.
Производительность при тесте SPECviewperf очень высокая для виртуальной среды, но всё равно ниже, чем при локальных тестах на Quadro K5000. Все результаты представлю в конце статьи для объективной оценки.

vGPU

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

В настройках виртуальной машины выбираем Shared PCI Device.



На выбор дается несколько профилей.



K200 — это урезанный K220Q, меньше разрешение и объем видеопамяти.
K220Q-K260Q — основные профили, которые можно выбрать для выполнения конкретных 3D-задач.
K280Q — спорный профиль, по максимальному количеству виртуалок — это тот же vDGA (2 шт. на карту K2), а по производительности ниже. Единственный, на мой взгляд, плюс этого профиля состоит в том, что его можно использовать совместно с другим профилем vGPU. Следует отметить, что на одну карту GRID можно выделять не более 2-х типов профилей. Причем совмещать режимы vGPU и vDGA нельзя по понятным причинам — у них разный способ взаимодействия с виртуальной средой.

Определившись с профилями и создав необходимое количество виртуальных машин или шаблонов, переходим к созданию пула/пулов.
На это раз в настройках рендера выбираем NVIDIA GRID VGPU.



После установки на виртуальную машину оригинальных драйверов NVIDIA и Horizon-агента, виртуальные машины доступны для работы через Horizon-клиент. Видеокарта в режиме vGPU будет определяться как устройство NVIDIA GRID с названием профиля.

Тестирование SPECviewperf V12.0.2

Визуально выглядело всё очень здорово, особенно в режиме K280Q

Для сравнения тот же тест в режиме K220Q.

Уже не так бодренько, но в любом случае достойно для виртуальной среды.

Ниже привожу сводную таблицу по каждому модулю тестирования SPEC для всех режимов виртуализации + результаты локальных тестов Quadro K5000 и K420.

Графики результатов теста

Проанализировав результаты, можно увидеть, что не во всех режимах есть линейный прирост производительности для тех или иных 3D-приложений. Например для Siemens NX нет разницы между профилями K240Q, K260Q и K280Q (скорей всего узким местом стал ЦП). А модуль Medical показал одинаковый результат не только в режимах K240Q, K260Q и K280Q, но и в режиме vDGA и даже при локальных тестах Quadro K5000. Maya, в свою очередь, демонстрирует существенный скачок между режимами K240Q и K260Q (вероятно, это связано с объемом видео памяти), а Solid Works показал одинаковый результат во всех полноценных профилях.

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

Тестирование 3ds Max

Так как тест SPEC для 3ds Max на данный момент поддерживает только версию 2015, и требует её установки, я ограничился ручным тестом пробной версии 2016.

Все режимы vGPU ведут себя достойно — ограничения как и всегда: чем меньше видео памяти выделено — тем меньшее количество полигонов можно обрабатывать.

Работа в самом младшем режиме (K220Q — 16 пользователей на карту) была ничем не хуже работы на младших Quadro. При повышении количества полигонов FPS оставался на комфортном уровне 20-30 кадров в секунду.

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

Тестирование КОМПАС-3D

Ради интереса провёл тест бенчмарком Компас-3D. Производительность графики во всех режимах отличалась не сильно — колебалась от 29 до 33 в их «попугаях». Специалисты АСКОН сказали, что это средний результат подобного решения на Citrix. Тест прошел как-то стремительно, модель вертелась с огромной скоростью (не было такой плавности как в SPEC), видимо это особенность теста. Поэтому я попробовал повертеть её вручную. Крутилась плавно и комфортно, не смотря на то, что модель сложная.

Аппаратная акселерация PCoIP

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

Я осознавал, что помимо основных задач, центральный процессор занимается кодированием PCoIP потока для отправки его клиенту. Учитывая то, что PCoIP нельзя назвать «лёгким» протоколом, нагрузка на процессор должна быть существенной. Для разгрузки ЦП я попробовал использовать Teradici PCoIP Hardware Accelerator APEX 2800.



Установив драйвер на ESXI и виртуальные машины я повторил несколько тестов. Результаты были впечатляющие:

Графики результатов теста

В некоторых тестах производительность увеличилась до 2-х раз, при использовании APEX 2800. Эта карта способна разгружать до 64 активных дисплеев.

Оценка стоимости решения

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

Сделал несколько расчетов в разных вариантах: виртуальное рабочее место получается дороже физической графстанции от 1,5 до 4 раз, в зависимости от количества виртуальных машин. Самая бюджетная виртуальная машина получилась в конфигурации: 32 виртуалки, 1-Core, 7GB RAM, K220Q 0,5GB (эквивалент Quadro K420).

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

Естественно, чуда не произошло и вряд ли когда-либо произойдёт — повышение плотности влечёт за собой увеличение стоимости решения. Но отметим очевидные плюсы данной технологии:

— Безопасность (первый плюс клиент-серверной архитектуры — все данные хранятся централизовано и изолировано)
— Высокая плотность (до 64 пользователей графических приложений на 4U стоечного пространства)
— Максимальная утилизация вычислительных мощностей (минимизированы простои системы в сравнении с персональной рабочей станцией)
— Удобство администрирования (всё на одном железе и в одном месте)
— Надежность (отказоустойчивость на уровне комплектующих + возможность построения отказоустойчивого кластера)
— Гибкость распределения ресурсов (в считанные секунды пользователь получает ресурсы необходимые для выполнения ресурсоемких задач, без изменения аппаратной части)
— Удалённый доступ (доступ из любой точки планеты через интернет)
— Кроссплатформенность клиентской части (подключение с любых устройств с любыми ОС, поддерживающих VMware Horizon Client)
— Энергоэффективность (при увеличении количества рабочих мест, энергопотребление сервера и тонких клиентов становится в несколько раз ниже чем у всех локальных рабочих станций)

Выводы

В результате тестирования, я для себя отметил несколько потенциально узких мест системы:

Частота процессора. Низкая частота классических процессоров Intel Xeon, как показали тесты, зачастую становилась узким местом системы. Поэтому необходимо использовать высокочастотные версии процессоров.
PC over IP. При выполнении задач связанных с отображением потокового видео или 3D-анимации, запаковка PCoIP отнимает значительную часть ресурсов центрального процессора виртуальной машины. Поэтому, использование аппаратного PCoIP-акселератора существенно повысит производительность вычислительной подсистемы.
Дисковая подсистема. Не секрет, что шпиндельный диск и в персональной системе, в большинстве случаев, является бутылочным горлышком. В сервере эта проблема стоит ещё острее, т.к. единовременный старт десятка виртуалок заставляет задуматься любой массив, и увеличение количества дисков в определенный момент уже не может повлиять на ситуацию. Поэтому необходимо строить гибридные дисковые подсистемы с использованием SSD. При более высоком количестве виртуальных машин необходимо и вовсе рассмотреть вариант с СХД.

Ну вот и всё. Безусловно это были лишь предварительные тесты для того, чтобы оценить потенциал и понять позиционирование этого решения. Следующими шагами будут: полный цикл тестирования оригинальной конфигурации с постоянной и переменной нагрузкой на все виртуальные машины, построение кластера для повышения отказоустойчивости и, возможно, еще что-нибудь — что Вы посоветуете…

Заключение

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

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

Спасибо за внимание, ниже ссылки на нашу активность:
Официальный сайт
Канал Youtube
В контакте и Facebook
Twitter и Instagram