Тестуємо 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,5 GB (еквівалент Quadro K420).

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

Природно, дива не сталося і навряд чи коли-небудь станеться — підвищення щільності тягне за собою збільшення вартості рішення. Але зазначимо очевидні плюси даної технології:

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

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

Частота процесора. Низька частота класичних процесорів Intel Xeon, як показали тести, часто ставала вузьким місцем системи. Тому необхідно використовувати високочастотні версії процесорів.
PC over IP. При виконанні завдань, пов'язаних з відображенням потокового відео або 3D-анімації, запаковка PCoIP забирає значну частину ресурсів центрального процесора віртуальної машини. Тому, використання апаратного PCoIP-акселератора істотно підвищить продуктивність обчислювальної підсистеми.
Дискова підсистема. Не секрет, що шпиндельний диск і в персональній системі, в більшості випадків, є пляшковим горлечком. У сервері ця проблема стоїть ще гостріше, оскільки одноразовий старт десятка виртуалок змушує задуматися будь-масив, і збільшення кількості дисків в певний момент вже не може вплинути на ситуацію. Тому необхідно будувати гібридні дискові підсистеми з використанням SSD. При більш високій кількості віртуальних машин необхідно і зовсім розглянути варіант з СГД.

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

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

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

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

Готова технологія GRID до масового застосування?

/>
/>


<input type=«radio» id=«vv69309»
class=«radio js-field-data»
name=«variant[]»
value=«69309» />
Так, готова. Співвідношення ціна/продуктивність досягла необхідного рівня для масового впровадження.
<input type=«radio» id=«vv69311»
class=«radio js-field-data»
name=«variant[]»
value=«69311» />
Готова тільки для застосування у спеціалізованій сфері з підвищеними вимогами до безпеки доступу.
<input type=«radio» id=«vv69313»
class=«radio js-field-data»
name=«variant[]»
value=«69313» />
Не готова. Занадто висока вартість робочого місця.
<input type=«radio» id=«vv69315»
class=«radio js-field-data»
name=«variant[]»
value=«69315» />
Не готова. Занадто низька продуктивність графічної підсистеми.

Проголосувало 18 осіб. Утрималося 11 осіб.


Хотілося б Вам взяти участь у тестуванні технології GRID?

/>
/>

<input type=«radio» id=«vv69317»
class=«radio js-field-data»
name=«variant[]»
value=«69317» />
Так, заради інтересу.
<input type=«radio» id=«vv69319»
class=«radio js-field-data»
name=«variant[]»
value=«69319» />
Так, я працюю у важких графічних додатках і хочу порівняти продуктивність. В коментарях напишу назву і, якщо буде можливість, дам посилання для скачування пробної версії.
<input type=«radio» id=«vv69321»
class=«radio js-field-data»
name=«variant[]»
value=«69321» />
Немає, і так все зрозуміло.
<input type=«radio» id=«vv69323»
class=«radio js-field-data»
name=«variant[]»
value=«69323» />
Ні, мені це не цікаво

Проголосував 21 людина. Утрималося 7 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.