Коли ви починаєте серйозно гратися з сучасною віртуалізацією, рано чи пізно ви зіткнетеся з повторюваною проблемою: Віртуальні машини рідко пропонують таку ж графічну продуктивність, як операційна система, встановлена безпосередньо на обладнанні.Хоча робочий стіл хоста може працювати плавно навіть у роздільній здатності 4K, робочий стіл віртуальної машини може бути переривчастим, із затримкою миші, розривами екрана або нестачею плавного відтворення відео.
Цей сценарій повторюється як у побуті, так і в Корпоративні платформи, що використовують KVM, Proxmox, VMware, Hyper-V або публічну хмару.І відчуття те саме: «Хост працює чудово, але віртуальна машина повільна... що я роблю не так? Чи потрібен мені виділений графічний процесор, SR-IOV, для зміни гіпервізорів, чи просто більше потужності процесора?»
Графічна продуктивність у віртуальних машинах: чого насправді можна очікувати
Перший крок – це коригування очікувань: Віртуалізація робочих столів з "майже рідним" 3D-прискоренням залишається проблемоюОсобливо, якщо ви хочете спільно використовувати один графічний процесор між хостом та кількома віртуальними машинами, не вдаючись до дуже дорогих або складних рішень.
У типовому випадку з Debian 12 як хост через KVM, ноутбук Ryzen 7 PRO з вбудованою графічною процесором Radeon та 4K-дисплеємФізичний робочий стіл працює ідеально: переміщення вікон відбувається миттєво, веб-сайти завантажуються швидко, а 4K YouTube відтворюється плавно. Однак на віртуальних машинах Linux з графікою Virtio або SPICE продуктивність падає: Важкі веб-сторінки та онлайн-відео відчувають більше затримок, а плавність роботи не така висока, як у хоста..
Під час тестування різних конфігурацій (драйвер VirtIO-GPU, SPICE, virgl, різні віддалені програми перегляду, такі як virt-viewer, клієнти Windows тощо) спостерігається, що Вказівник та загальна швидкість реагування дещо покращилися, але розриви зображення, пропущені кадри та чітке відчуття менш «жвавого» робочого столу все ще присутні.Через це багато людей одразу ж розглядають можливість використання GPU passthrough. Або навіть перехід на іншу платформу.
Важливо розуміти, що навіть у потужних інфраструктурах, Віртуалізація створює невелике навантаження на процесор, оперативну пам'ять і, особливо, на дисковий ввід/вивід і графіку.У традиційних навантаженнях на сервер (веб, бази даних, мікросервіси) таке покарання є прийнятним; але коли ви починаєте запитувати Вишукана графічна інтерактивність, низька затримка та плавне відеокожна мілісекунда на рахунку.
Віртуальні машини проти фізичних серверів: реальний вплив на продуктивність
Хоча ми тут зосереджуємося на графіці, варто розглянути віртуалізацію в контексті. Фізичні (голі) сервери залишаються еталоном, коли вам потрібна висока продуктивність та мінімальна затримка.Особливо у високопродуктивних базах даних, 3D-рендерингу, штучному інтелекті або потоковій передачі даних у реальному часі.
Типові тести бенчмарків показують, що добре налаштована віртуальна машина на KVM або VMware працює дуже близько до "голого металу" за витратами процесора та оперативної пам'яті: приблизні втрати 5-8% у процесорі та 7-13% у пам'ятіНайбільша прогалина полягає в сховищі. Швидкість 4K IOPS може знизитися на 17-25%, що є критично важливим, якщо ваше робоче навантаження дуже інтенсивне використання дискового простору.
Цей штраф також існує в графічному дизайні, з тим нюансом, що Графічний процесор зазвичай використовує ресурси спільно з кількома віртуальними машинами, а шлях представлення (SPICE, VNC, RDP, власний протокол гіпервізора тощо) додає затримку та стиснення.Результат: система «не непридатна для використання», але порівняно з хостом вона працює менш плавно.
Ось чому є сценарії, коли варто залишитися з голим металом: великі транзакційні бази даних (Oracle, SQL Server Enterprise, SAP HANA), механізми штучного інтелекту/машинного навчання з потужними графічними процесорами або ігрові/стрімінгові сервери з дуже суворими вимогами до затримки. У цих ситуаціях навантаження на процесор, пам'ять, ввод-вивод та графічний процесор рівня віртуалізації стає набагато помітнішим.
Замість цього веб-додатки, мікросервіси, середовища розробки та віртуальні офісні робочі столи — навіть легкий робочий стіл в Ubuntu— Вони дуже добре вписуються у віртуальні машини. Вони мають переваги створення знімків, високої доступності та швидкого масштабування, а незначна втрата продуктивності цілком прийнятна.
Процесор, оперативна пам'ять, диск і мережа: які показники слід перевіряти в повільній віртуальній машині
Перш ніж звинувачувати графічний процесор, нам потрібно підтвердити, що Ви не обмежені процесором, пам'яттю, диском чи мережеюБагато проблем із «повільною роботою робочого столу» насправді є перенасиченням іншого ресурсу: процесор чекає своєї черги, інтенсивний обмін або диск на межі своїх можливостей.
Наприклад, у VMware vSphere процесор кожного віртуального процесора проходить чотири стани: RUN (робота), WAIT (очікування/введення/виведення або простою), READY (у черзі без фізичного процесора) та COSTOP (співзупинка в багатоядерних віртуальних машинах)Високі значення READY або COSTOP є чіткими показниками конфлікту та того, що хостинг перевантажений.
Для процесорів ключовими показниками є відсоток постійного використання, використання МГц на віртуальний процесор та лічильники Ready/COSTOPЯкщо віртуальна машина постійно завантажена на 90-100% або готова до роботи більше 10% часу, це означає, що ця машина має проблеми. Додавання більшої кількості віртуальних процесорів волею-неволею майже ніколи не допомагає, якщо хост вже перевантажений.
У пам'яті ми повинні пильнувати за Глобальне використання включає підкачку/свап, а на платформах, таких як Azure або Hyper-V, файли підкачки або свапування на вторинних дисках.Коли ці томи показують багато операцій читання/запису, це явна ознака того, що віртуальній машині закінчилася оперативна пам'ять.
На диску та в мережі спостерігається наступне: середня затримка читання/запису, кількість вводів/виводів за секунду та пропускна здатність мережіТривалі затримки на диску понад 15-20 мс або падіння доступності та тайм-аути у віддаленому сховищі (Azure Storage, SAN тощо) є прямими ворогами сприйнятої продуктивності на віддаленому робочому столі.
Інструменти моніторингу та діагностики: від ESXTOP до Azure Monitor
Великі виробники пропонують добре розроблені інструменти для аналізу продуктивності віртуальної машини. Ось деякі приклади:
- VMware: vCenter та ESXTOP.
- Azure: Монітор Azure та PerfInsights.
- Hyper-V: Монітор продуктивності та PowerShell.
- KVM/Proxmox: комбінації, такі як top, htop, iostat, virt-top та сам веб-інтерфейс.
ESXTOP — це класичний інструмент для аналізу в режимі реального часу. Він дозволяє переглядати кожні кілька секунд показники для кожного віртуального процесора, такі як %ВИКОРИСТОВУВАТИ, %ЗАПУСКУ, %СИС, %ОЧІКУВАННЯ, %ПРОСТІЙНИЙ ЧАС, %ЗАПУСК, %CSTP, %МЛМТД та багато іншого. Основне правило: якщо %RDY або %CSTP різко зростає, у вас забагато віртуальних процесорів або забагато віртуальних машин для хоста.
В Azure, увімкнення діагностики на рівні віртуальної машини та облікового запису сховища надає вам діаграми Процесор, пам'ять, диск та мережаразом із показниками доступності, затримки, дроселювання та помилок тайм-ауту сховища. Ця інформація допомагає розрізнити проблему платформи та вузьке місце на вашому боці через надмірну кількість операцій вводу-виводу або пропускну здатність.
У Hyper-V робота розділена між Диспетчер Hyper-V, монітор продуктивності, монітор ресурсів і командлети PowerShellВи можете перевірити фізичні та логічні ядра, NUMA, диски VHDX, віртуальні адаптери, черги дисків та багато іншого, щоб точно налаштувати, яка частина не відповідає вимогам.
Окрім виробника, багато посібників рекомендують використовувати специфічні стрес-тести: sysbench для процесора, stress-ng та memtester для оперативної пам'яті, fio для дискового вводу/виводу, iperf3 або netperf для мережі. Це дозволяє легко порівняти базову машину з віртуальною машиною та побачити обмеження кожного гіпервізора.
Віртуалізація GPU: SR-IOV, passthrough та пропрієтарні рішення
Коли вузьким місцем є чітка графічність (розриви екрана, низька частота кадрів, повільна анімація, переривчасте відео), саме час звернути увагу на Віртуалізація GPUТут є три основні сімейства рішень:
- Пропускна здатність GPU (пропускна здатність PCI)Повноцінна відеокарта призначається одній віртуальній машині. Це пропонує майже нативну продуктивність, але з очевидними обмеженнями: ця відеокарта стає недоступною для хоста та інших віртуальних машин, і зазвичай вам потрібен окремий відеовихід для цієї віртуальної машини, що не ідеально, якщо ви хочете відображати все на одному екрані.
- Віртуалізація GPU за допомогою SR-IOV (віртуалізація вводу/виводу з одним коренем)Це дозволяє надавати доступ до функцій віртуальних графічних процесорів (ВФ) різним віртуальним машинам. Ідея дуже приваблива: спільне використання графічного обладнання з мінімальними накладними витратами. Intel просуває цей підхід у своїх вбудованих графічних процесорах Xe2 для ноутбуків (наприклад, Lunar Lake) та в графічних процесорах центрів обробки даних (Flex), тоді як AMD та NVIDIA переважно резервують цю функцію для... дуже дорогі візитні картки де, крім того, часто існують моделі ліцензування та передплати, які не дуже зручні для домашніх користувачів або малого бізнесу.
- SR‑IOVЦе рішення Він не повністю прозорий для віртуальних машин, вимагає специфічних драйверів, підтримки BIOS/прошивки та гіпервізора, а також може створювати власні проблеми сумісності.Не завжди варто оновлювати все обладнання (наприклад, купувати ноутбук Intel Lunar Lake лише заради цього), якщо решта вашого робочого процесу залишатиметься обмеженою іншими факторами. Аналіз апаратного забезпечення ПК допомагає визначитися.
- Власні рішення для віртуалізації GPUТакі як NVIDIA RTX vWS, NVIDIA VGX або їхні наступники. Вони поєднують специфічне обладнання (наприклад, карти типу VGX K1/K2 з кількома графічними процесорами Kepler, великим обсягом пам'яті GDDR5 та тисячами ядер CUDA) з гіпервізором графічного процесора, який дозволяє мультиплексувати обчислювальну потужність графіки на десятки віртуальних робочих столів.
Часткові технології GPU в середовищах робочого столу: virtio-gpu, virgl та SPICE
Для тих, хто використовує KVM, QEMU, Proxmox або подібні програми, звичайний шлях включає Паравіртуалізовані графічні контролери, такі як virtio-gpu, у поєднанні з протоколами віддаленого робочого столу, такими як SPICEНа стороні гостьової системи встановлено драйвер, який «розуміє» цей віртуальний пристрій і дозволяє певний рівень базового 2D/3D прискорення.
VirGL – це додатковий шар, який перетворює виклики OpenGL від гостьової системи до графічного процесора хостаТаким чином, програма у віртуальній машині опосередковано використовує реальне 3D-прискорення. Теоретично це має покращити графічну продуктивність робочого столу та програм. Однак на практиці іноді трапляється навпаки. Якщо вбудований графічний процесор хоста недостатньо потужний або реалізація не відшліфована, помітно значне падіння продуктивності.
Фактично, багато користувачів з вбудованими графічними процесорами AMD (наприклад, Renoir) повідомляють, що після активації VirGL... Робочий стіл віртуальної машини стає набагато повільнішим і важчимдо такої міри, що це гірше, ніж використання Virtio-GPU «без графічного процесора». Це не означає, що VirGL марний, але він дуже залежить від комбінації. апаратне забезпечення + драйвери + завантаження графіки віртуальної машини.
У Proxmox тріо virtio-gpu + SPICE + програма для перегляду віртуальних процесорів Зазвичай це мінімальна розумна конфігурація для графічного робочого столу Linux. Вона забезпечує пристойний покажчик миші, зміну розміру вікна та краще стиснення зображень, ніж простий VNC, але все ж... Не очікуйте такого ж досвіду, як із віддаленою консоллю VMware ESXi або VMRC., які значно вдосконалені після років оптимізації.
Ось чому багато адміністраторів, які переходять з ESXi, дивуються, коли пробують Proxmox. Незважаючи на дуже потужний гіпервізор, Відчуття "швидкості" віддаленого робочого столу нижче якщо ви не налаштовуєте багато тонких налаштувань або не використовуєте спеціальну відеокарту.
Коли варто використовувати GPU passthrough, а коли ні?
Передача даних через графічний процесор залишається найпродуктивнішим варіантом для конкретної віртуальної машини. Однак у сценаріях щоденного використання на робочому столі є кілька недоліків. Наприклад. потреба в іншому моніторі, втрата графічного процесора для хоста, додаткові ускладнення (IOMMU, групи, BIOS, драйвери, помилки з призупиненням тощо).
Якщо ваша мета полягає в тому, одна віртуальна машина має повне 3D-прискоренняЗусилля зазвичай того варті. Такі проекти, як Looking Glass, дозволяють вам «повторно впровадити» образ віртуальної машини на робочий стіл хоста, щоб уникнути додаткових моніторів. Але, якщо ви хочете… кілька офісних або тестових віртуальних машин з хорошим базовим рівнем володінняПеренесення графічного процесора до кожного з них неможливе.
Для потужних настільних комп'ютерів можна розглянути гібридну комбінацію: Основний графічний процесор для хоста та пропускна здатність від другого, скромнішого графічного процесора для конкретної віртуальної машиниТаким чином, ви підтримуєте дуже зручний робочий стіл хоста та надаєте цій віртуальній машині графічне середовище, дуже близьке до рідного; аналіз ноутбука Це може запропонувати уявлення про альтернативи настільним комп'ютерам у порівнянні з ноутбуками.
З ноутбуками все стає складніше. Зазвичай вони мають один вбудований графічний процесор (або вбудований графічний процесор + внутрішній графічний процесор, високо інтегровані з прошивкою)З обмеженими ресурсами та відсутністю реальної можливості встановлення іншої відеокарти, наскрізне керування рідко буває доцільним. Більш доцільно використовувати паравіртуалізовані опції (virtio-gpu, SPICE, RDP), щоб зменшити графічні очікування віртуальних машин.
Словом, Passthrough – це правильний інструмент для кількох дуже вимогливих віртуальних машин.Для лабораторій з багатьма машинами або легкими робочими столами вас більше цікавить налаштування гіпервізора, керування навантаженням процесора/оперативної пам'яті/вводу/виводу та вибір правильного протоколу віддаленого робочого столу.
Гіпервізори, NUMA, динамічна пам'ять та інші фактори продуктивності
Окрім графічного процесора, спосіб управління гіпервізором Процесор, пам'ять, сховище та мережа Це безпосередньо впливає на сприйняття плавності робочого столу віртуальної машини. Hyper-V, KVM, VMware та інші мають дещо різні філософії, але всі вони мають спільні концепції.
Наприклад, архітектура Hyper-V базується на гіпервізор, який контролює доступ до обладнання, кореневий розділ із системою управління та вторинні розділи для віртуальних машинЦе підтримується такими технологіями, як віртуальна NUMA, динамічна пам'ять, віртуальні комутатори, мережевий SR-IOV та оптимізація сховища, така як ODX.
NUMA (неоднорідний доступ до пам'яті) особливо важливий на серверах з багатьма ядрами. Якщо велика віртуальна машина погано розділена між фізичними вузлами NUMA, її затримка пам'яті збільшується. І продуктивність страждає, навіть якщо на папері здається, що ресурсів достатньо. В ідеалі топологія vNUMA віртуальної машини повинна відповідати топології pNUMA хоста.
Динамічна пам'ять (у Hyper-V, розгортання в інших гіпервізорах) може заощаджувати глобальну оперативну пам'ять, але Він не підходить для робочих навантажень, чутливих до затримки, таких як бази даних або робочі станції з багатьма відкритими програмами.У таких випадках доцільно виділити фіксовану пам'ять, щоб уникнути пауз, коли гіпервізор вирішить повернути всю оперативну пам'ять одразу.
Зберігання є найпоширенішою проблемою. Рекомендується Використовуйте VHDX-диски фіксованого розміру, розділяйте системні диски та диски з даними, обирайте SSD-накопичувачі корпоративного класу або NVMe-диски та уникайте RAID-конфігурацій з поганою поведінкою запису (RAID 5/6) для інтенсивних робочих навантажень.Де це можливо, Storage Spaces Direct або масиви NVMe допомагають підтримувати затримки в прийнятних межах.
У мережі доцільно налаштувати Зовнішні віртуальні комутатори на швидких мережевих адаптерах (10 GbE, якщо можливо), використання об'єднання мережевих адаптерів, увімкнення SR-IOV для дуже великих мережевих навантажень, а також налаштування MTU та розвантаження. Тільки якщо весь мережевий ланцюг це підтримує. Погана конфігурація мережі може зробити віддалений робочий стіл, навіть з хорошим графічним процесором, гіршим, ніж очікувалося.
Стрес-тестування та варіанти використання: коли обрати віртуальну чи фізичну машину
Щоб вирішити, чи переносити графічне навантаження на віртуальну машину, чи залишати його на фізичному носії, важливо Тестування за допомогою бенчмарків та інструментів для вимірювання стресу Вони повинні вимірювати використання процесора, оперативної пам'яті, дискового простору та мережі. А також, коли це можливо, використання графічного процесора. В ідеалі, «реальний» додаток слід порівнювати з таким самим додатком, що працює у віртуальній машині.
Реалістична схема може бути такою: Запустіть sysbench або Geekbench для перевірки процесора, stress-ng або memtester для перевірки оперативної пам'яті, fio для перевірки 4K IOPS та затримки диска, iperf3 для перевірки пропускної здатності мережі., а також деякі базові графічні бенчмарки (наприклад, glxgears або тест WebGL у браузері) як на хості, так і на віртуальній машині.
Якщо втрата продуктивності знаходиться в допустимих межах (наприклад, Менше 10% навантаження на процесор/оперативну пам'ять та 15-20% навантаження на дискЯкщо віддалений робочий стіл здається достатньо зручним для цільового використання (автоматизація офісу, адміністрування, легка розробка), віртуалізація є цілком прийнятним варіантом.
Якщо ж, з іншого боку, застосунок значною мірою залежить від Графічний процесор, низька затримка та висока стабільна пропускна здатність вводу/виводу (рендеринг у Blender, важкі CAD, двигуни штучного інтелекту, що навчають великі моделі, ігри тощо), досвід зазвичай набагато кращий на фізичному сервері з виділеним графічним процесором або на професійній віртуальній машині з наскрізним підключенням графічного процесора/віртуалізацією.
Ключовим є виявлення того, який компонент (готовий процесор, недостатня кількість оперативної пам'яті, обмежений ввод-вивод, відсутність справжнього графічного процесора, повільна мережа або погано оптимізований протокол робочого столу) уповільнює роботу кожної віртуальної машини. застосувати найпростіше та найекономічніше рішення, яке можна реалізувати в цьому випадкуі зарезервувати значні інвестиції (виділені графічні процесори, SR-IOV, професійне обладнання) для робочих навантажень, де вони дійсно мають значення.