При створенні віртуальних машин на різних Гіпервізор (VMWare, KVM, Hyper-V і т.д.) ви можете звернути увагу, що іноді віртуальна машина може не бачити все виділені їй віртуальні ядра (vCPU). У нашому випадку віртуальній машині на KVM були виділені 8 vCPU, на неї встановлена Windows 10. Однак Windows визначала ці ядра як окремі процесори, з яких можна використовувати тільки 2 vCPU.
зміст:
- Віртуальна машина Windows 10 не бачить все ядра
- Кількість підтримуваних процесорів в Windows 10
- Управління віртуальними ядрами і vCPU в KVM
- Налаштування віртуальних процесорів і кількості ядер в VMWare
- Архітектура NUMA і віртуальні vCPU
Віртуальна машина Windows 10 не бачить все ядра
Якщо відкрити диспетчер пристроїв Windows, можна переконається, що всі виділені ядра видно як 8 окремих віртуальних процесорів типу QEMU Virtual CPU version 2,5.
При цьому у властивостях Windows 10 (Computer -> Properties) і в Task Manage видно, що на комп'ютері доступні тільки 2 процесора QEMU Virtual CPU.
Тобто скільки б ви не додали віртуальних ядер, Windows 10 все одно зможе використовувати тільки два. При цьому сусідній віртуальний сервер з Window Server 2016 на цьому ж гіпервізора бачить все 16 виділених йому vCPU.
Кількість підтримуваних процесорів в Windows 10
Проблема полягає в тому, що в десктопних редакціях Windows (Windows 10 / 8.1 / 7) є обмеження на максимальну кількість фізичних процесорів (сокетов), яке комп'ютер може використовувати:
- Windows 10 Home - 1 CPU
- Windows 10 Professional - 2 CPU
- Windows 10 Workstation - до 4 CPU
- Windows Server 2016 - до 64 CPU
Однак це обмеження не поширюється на ядра. Тобто для підвищення продуктивності ви можете використовувати процесор з великою кількістю ядер. Більшість гіпервізора вміють надавати vCPU у вигляді процесорів, процесорних ядер або навіть потоків. Тобто замість 8 віртуальних CPU ви можете надати vCPU у вигляді 2 сокетов по 4 ядра в кожному. Розглянемо, як в різних системах віртуалізації виділити віртуальні процесори у вигляді ядер і як це пов'язати з архітектурою NUMA, що використовується в сучасних процесорах.
Управління віртуальними ядрами і vCPU в KVM
У моїй віртуальній машині KVM c Windows 10, всі призначені віртуальні ядра вважаються окремими процесорами.
Щоб використовувати всі ресурси CPU, виділені віртуальній машині потрібно, щоб віртуальна машина бачила не 8 процесорів, а один 8-ядерний процесор, 2 процесора по 4 ядра або 1 процесор з 4 ядрами по 2 потоки. Спробуємо змінити спосіб призначення віртуальних ядер для ВМ на KVM.
Вимкніть віртуальну машину:
# Virsh shutdown server.vpn.ru - де server.vpn.ru це ім'я віртуальної машини.
Виведіть поточну XML конфігурацію віртуальної машини KVM:
# Virsh dumpxml server.vpn.ru
Нам цікавий блок з описом процесорів:
8 1000 / machine hvm
Як бачимо, у нас вказано просто 8 vCPU. Змінимо конфігурацію:
# Virsh edit server.vpn.ru
І після додамо:
де:
host-passthrough- режим емуляції при якому на віртуальній машині буде показаний фізичний процесор вузла кластера (ноди).sockets = '1'- вказуємо що процесор 1cores = '4'- вказуємо, що процесор має 4 ядраthreads = '2'- вказуємо, що ядра у нас по 2 потоки
Збережіть конфігураційний файл і запустіть ВМ. Авторизуйтесь в гостьовій ВМ з Windows 10 і в Task Manager або Resource Monitor перевірте, що ОС бачить все виділені віртуальні ядра.
Також в якості системи тепер став відображатися фізичний процесор хоста Intel (R) Xeon (R) Silver 4114 CPU, а не віртуальний.
Так нам вдалося вирішити проблему з навантаженням на ВМ, так як двох ядер не вистачало для повноцінної роботи додатків.
Налаштування віртуальних процесорів і кількості ядер в VMWare
Ви можете змінити спосіб презентації vCPU для віртуальної машини VMWare з інтерфейсу vSphere Client.
- Вимкніть ВМ і відкрийте її налаштування;
- розгорніть секцію CPU;
- Змінимо конфігурацію ВМ так, щоб гостьова ОС бачила 2 процесора по 4 ядра. змініть значення Cores per Socket на 4. Це означає, що гостьова ОС буде бачити два чотирьох -ядерних процесора (2 сокета по 4 ядра);
- Збережіть зміни і запустіть ВМ.
Архітектура NUMA і віртуальні vCPU
Є ще кілька аспектів призначення vCPU і ядер віртуальним машинам, які потрібно розуміти.
При призначенні ядер на сокеті враховуйте наявність NUMA архітектури (Використовується в більшості сучасних CPU). Не рекомендується призначати вашої ВМ кількість ядер на сокет (і загальна кількість vCPU) більше, ніж доступно ядер на вашому фізичному сокеті / процесорі (ноді NUMA). При розміщенні на одній фізичній ноді NUMA, віртуальна машина зможе використовувати швидку локальну RAM, доступну на конкретній ноді NUMA. Інакше для виконання операції процесам доведеться чекати відповіді від іншої Ноди NUMA (що дещо довго).
Якщо ви призначаєте для ВМ два окремих віртуальних сокета, то гипервизор може їх запускати на різних нодах NUMA. Що не кращим чином позначиться на продуктивності ВМ.
Якщо кількість необхідних vCPU перевищує кількість ядер на 1 фізичному сокеті (ноді NUMA), потрібно створити кілька віртуальних сокетов (процесорів) з необхідним кількість ядер. Також не бажано використовувати непарна кількість процесорів (краще додати 1 vCPU)
Це дозволить зберегти продуктивність віртуальної машини.
Наприклад, для 2 процесорного хоста з 10 ядрами (сумарно доступно 40 vCPU з урахуванням Hyper-Threading), При налаштуванні vCPU для ВМ оптимально використовувати такі конфігурації:
| Необхідна кількість vCPU | Кількість віртуальних сокетов в налаштуваннях ВМ | Кількість ядер на віртуальному процесорі в налаштуваннях ВМ |
| 1 | 1 | 1 |
| ... | ||
| 10 | 1 | 10 |
| 11 | Чи не оптимально | |
| 12 | 2 | 6 |
| ... | ||
| 20 | 2 | 10 |
Наприклад, ВМ з Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфігурації 8 сокетів за 2 ядра буде працювати гірше, ніж в конфігурації 2 сокета по 8 ядер.
Також не забувайте, що деякі програми ліцензуються за фізичними сокетів (так було в старих версіях SQL Server). Іноді вам просто вигідніше ліцензувати один багатоядерний процесор, ніж кілька процесорів з меншою кількістю ядер.
Сучасні версії Windows Server ліцензуються в середовищі віртуалізації по-особливому. Також є свої особливості ліцензування процесорів в VMWare vSphere.
