Что такое nvidia grid

Почему не RemoteFX, а также подробнее о технологиии NVIDIA GRID VGPU

Довольно давно я знаком с гипервизором от компании Microsoft под названием Hyper-V. Надо отметить, что данный гипервизор с каждым следующим поколением серверной платформы Windows Server становится всё более функциональным и интуитивно понятным для администрирования. В PowerShell добавляются новые командлеты, позволяющие легко управлять гипервизором. Появляется отличная возможность реализовывать с помощью скриптов даже такие необходимые задачи, как резервное копирование виртуальных машин и создание снапшотов по расписанию в планировщике без использования сторонних и довольно дорогостоящих программ. Администрировать Hyper-V легко, производительность гипервизора не вызывает нареканий, постоянно растет список операционных систем, имеющих либо установленные службы интеграции с гипервизором, либо имеющих возможность установить такие службы, либо поддерживающих Hyper-V благодаря модулям ядра. Еще совсем недавно состоялся релиз FreeBSD 10.0, первой из BSD систем, которая легко и непринужденно устанавливалась в качестве гостевой на гипервизор от Microsoft, и которая избавилась от детских болячек, вроде ограниченного размера виртуального жесткого диска и возможности использования только устаревшего сетевого адаптера (legacy или эмулированного), чья скорость не может превышать 100мбит/сек, в то время как физический сетевой адаптер является гигабитным. В общем, как может показаться, тенденция к улучшению имеет ну очень положительную динамику. Именно поэтому изначально мы занялись поиском ответа на вопрос, о том, существует ли возможность использования физической видеокарты в гостевой операционной системе Hyper-V. Ответ, как нам казалось тогда, не заставил себя долго ждать и уже через 5 минут, судя по статьям в интернете, мы были уверены, что такая возможность существует и, более того, она качественно реализована разработчиками Hyper-V. Как оказалось, мы жестоко ошибались, но обо всем по порядку.

Microsoft предложила в качестве решения технологию RemoteFX, которую изначально разрабатывала компания Calista Technologies, которая в последствии была приобретена Microsoft. Сама технология имеет очень весомые аппаратные требования как к серверу виртуализации, так и к видеокарте, которая в дальнейшем будет использоваться гостевой операционной системой посредством этой технологии. Требования заключаются в том, что сам сервер должен иметь CPU с поддержкой SLAT (EPT on Intel, NPT/RVI on AMD), а вот с GPU все еще веселее. Вот собственно требования и рекомендации, озвученные самими Microsoft:

На просторах всемирной сети есть немало руководств по развертыванию RemoteFX на Windows Server. Однако о качественном применении почти ни в одной из этих статей речи не идёт, а в основном статья имеет такой законченный смысл «Поднял, поковырялся, вроде работает, вроде даже шевелится побыстрее, вроде даже нагрузку на центральный процессор снизили. Для чего делал? Черт его знает».

Так вот, я хочу рассказать вам о нашем опыте поиска решения задачи по расширению возможностей виртуальных машин в обработке 3D-графики. Перед нами стояла довольно чётко обрисованная задача. Нам нужно было сделать так, чтобы пользователи удаленных рабочих столов терминального сервера, развернутого на платформе Windows Server 2012 R2, смогли как минимум качественно просматривать различные 3D чертежи и сборки в специализированных viewer-ах, а как максимум и сами могли нет-нет, да и запустить различные CAD программы.

Первоначальной идеей стало развертывание RemoteFX на Windows Server 2012R2. Сказано – сделано. В наличии имелась серверная платформа DELL PowerEdge R720, оснащенный двумя процессорами Intel Xeon CPU E5-2670 v2 @ 2.50GHz поддерживающими SLAT, а также вычислительный графический модуль NVIDIA GRID K2. На сервер была установлена операционная система Windows Server 2012R2 standard с графической оболочкой, была развернута служба Hyper-V и настроен RemoteFX. На самом деле, тогда мы думали, что это окончательное решение и технология RemoteFX нас полностью устроит. Однако, в дальнейшем мы узнали, что Microsoft накладывает на технологию и существенные программные требования, что в качестве гостевой операционной системы, способной использовать трехмерный графический адаптер RemoteFX, могут выступать только операционные системы Windows 7 и 8 и только в редакциях Ultimate и Enterprise. Не совсем справедливо конечно, учитывая то, что сам гипервизор по заявлениям своих разработчиков поддерживает уйму других операционных систем.

Стало понятно, что наша цель использовать графический адаптер в виртуальном терминальном сервере, который развернут на Windows Server 2012R2, останется неосуществимой. Ладно, работаем с тем, что есть. Так что-же у нас есть? Совсем немного. Всего-то возможность установки в качестве гостевой операционной системы Windows 7-8 Ultimate-Enterprise с возможностью подключения к ним только одного пользователя. И даже распрекрасная библиотека RDP Wrapper не в состоянии решить этой проблемы. К тому-же, как нам стало известно по результатам производительности, трехмерный графический адаптер RemoteFX практически не умеет работать с таким API, как OpenGL, который используют большинство CAD программ, а вместо этого поддерживает полностью только проприетарную разработку Microsoft только для Windows – Direct3D. Об этом совсем скромно-скромно заявляют лишь две строчки в описании технологии RemoteFX на сайте Microsoft:

«Support in Windows Server 2012 R2 is provided for DX 11.0, DirectCompute, and C++ AMP. Most of the latest graphics cards will support OpenGL 4.0 and OpenCL 1.1 or later, but these APIs are currently unsupported by RemoteFX in Windows Server 2012 R2.»

Что это, проприетарная разработка для поддержания возможности развертывания терминального сервера на основе виртуальных машин, предложенной в последнем поколении Windows Server? Сложно ответить на этот вопрос. Однако, ясно только одно, технология RemoteFX неприменима для решения поставленной перед нами задачи, особенно ввиду чрезмерно завышенных аппаратных и программных требований к платформе, серверу и гостевым операционным системам. Все эти требования мы, конечно, готовы удовлетворить, но получить в результате готовое решение с крайне сомнительным функционалом – это расточительство.

Именно поэтому поиск не прекратился и, к своему стыду, мы первый раз обратили внимание на то, что пишет сама NVIDIA, о разработанном им графическом вычислительном модуле и его применении. Подробнее можно прочесть здесь, а если коротко, то NVIDIA создала технологию NVIDIA GRID vGPU, благодаря которой графические команды каждой виртуальной машины передаются напрямую в GPU, без трансляции гипервизором. Один физический графический модуль, благодаря драйверу, имеет несколько профилей виртуального GPU c различным количеством ядер и дискретной графической памяти. Вот таблица доступных виртуальных профилей для графических плат NVIDIA GRID:

Всё предельно просто и прекрасно. Драйвер имеет возможность выделять из аппаратной платформы платы виртуальные профили, отличающиеся друг от друга количеством графических ядер и памяти, которые могут стать аналогом физической видеокарты в виртуальной машине. В то время, как технология RemoteFX – всего лишь программная прослойка между виртуальной машиной и реальной графической платой, которая выборочно передает на обработку ту или иную графику. Зачем тогда Microsoft рекомендует к использованию графическую плату, чей функционал в полной мере не поддерживается возможностями их гипервизора? Зачем рекомендовать эту плату к использованию, если гипервизор, написанный ими, не идет по пути развития концепции, предложенной производителями графической платы? Не понятно. Однако, надо отметить, что в описании самой технологии NVIDIA GRID VGPU на сайте NVIDIA, не говорится ни слова (и слава богу) о гипервизоре Microsoft, а вместо этого упоминаются такие разработчики, как VMware c vSphere и Citrix со своим XenServer.

Было решено попробовать в качестве гипервизора XenServer 6.5 от Citrix, чей функционал в редакции Enterprise как раз поддерживает распределение виртуальных графических профилей между виртуальными машинами. Хоть это и не имеет никакого отношения к статье, всё же отмечу, что установка и настройка сервера простая и интуитивно понятная до безобразия. Сервер был установлен и активирован триальной лицензией на 90 дней, которую можно получить, с учетом количества сокетов хоста, за 5 минут, зарегистрировавшись на сайте разработчиков. После активации функция распределения графических профилей становится доступной в XenCenter. К сожалению, для загрузки пока доступны драйвера исключительно для операционных систем Windows, однако радует уже то, что графический профиль имеет возможность устанавливаться не только на версии Windows 7-8 Ultimate-Enterprise, но и на другие операционные системы Microsoft такие как Windows 7-8 других редакций и Windows Server 2008-2012, из коробки поддерживает OpenGL 4.4 и DirectX 11 и OpenCL, а также не имеет ограничений на количество одновременных подключений средствами удаленного рабочего стола к виртуальной машине.

Чтобы оценить качество работы виртуальных графических профилей, в качестве гостевой была установлена операционная система Windows 8.1_x64_Enterprise, в настройках виртуальной машины поочередно добавлялись первые три профиля (K280Q, K260Q, K240Q), которые считаются максимально производительными в порядке убывания, и с каждым графическим профилем было запущено по 4 бенчмарка, тестирующих производительность 3D графики с использованием API OpenGL и Direct3D. Чтобы сравнение не казалось чрезмерно-абстрактным, было принято решение сравнить результаты бенчмарков, запущенных на ВМ, с результатами этих же бенчмарков запущенных на физической машине, имеющей схожие характеристики. Коротко о технических характеристиках виртуальной и физической машины можно узнать из таблицы представленной ниже.

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

Итак, первым бенчмарком будет SPECviewperf 12.0.2, который многими специалистами почитается как эталонный бенчмарк для тестирования графики различных CAD программ. Кому интересно, подробнее тут. Результаты в таблице ниже. Разрешение окна везде 1900×1060 (по умолчанию в бенчмарке).

Все результаты выкладываю как есть. Немного смутило меня, что профиль K260Q по идее должен быть «слабее», чем K280Q, однако показал более выдающиеся результаты. Перепроверил, запустив тест еще раз на обоих профилях и пришел к выводу, что показания стабильные (не рандомные) и хоть и отличаются от первоначальных, но в разумных пределах 0.2-0.4.

Следующим бенчмарком, а вернее набором различных бенчмарков для тестирования графики OpenGL стал GpuTest с сайта geeks3d.com, подробнее можно узнать здесь. Результаты в таблице ниже в формате (points/FPS). Все тесты произведены в полноэкранном режиме 1920×1080.

Следующим бенчмарком стал RedSDK turbine benchmark от компании REDWAY3D. Подробнее тут. Результаты в таблице ниже. Все тесты произведены в полноэкранном режиме 1920×1080.

Последним бенчмарком стала бесплатная версия Heaven Benchmark 4.0 от разработчиков Unigine. Подробнее тут. Выбор на него пал в том числе потому, что он может протестировать графику Direct3D. Все тесты произведены в окне разрешением 1280×720 по причине того, что бенчмарк не захотел запускаться в полноэкранном режиме на виртуальных машинах по неизвестным мне причинам, выдавая ошибку. Результаты в таблицах ниже.

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

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

Надеюсь, опыт нашего отдела ИТ кому-нибудь пригодится. Благодарю за внимание.

Источник

Тестируем 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 мы выбираем.

Для использования этого режима виртуализации, необходимо пробросить в виртуальную среду нашу карту 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-клиент ставится практически на любую популярную ОС.

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

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

В настройках виртуальной машины выбираем 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 — Вы уже и так все видели, да и вообще, синтетический тест — не лучший способ ручной проверки.

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

Источник