ITband.ru »Продуктивність Hyper-V: тюнінг і моніторинг.

1. Як підвищити продуктивність?
2. Віртуальні процесори
3. пам'ять
4. дискова підсистема
5. Мережеві інтерфейси
6. Хостової і гостьові ОС
7. Моніторинг продуктивності Hyper-V
8. CPU
9. пам'ять
10. диски
11. Мережа
12. Висновок

Як відомо, до певного часу в сфері віртуалізації серверів «правив бал» VMware зі своїм ESX. Тепер же, з випуском Hyper-V Microsoft поступово «наступає на п'яти». Наскільки успішно - питання, звичайно, дуже спірне, враховуючи, що VMware ESX існує на ринку набагато довше. Проте, Hyper-V привертає все більшу і більшу увагу в міру появи нових фіч - таких, як Cluster Shared Volumes і Live Migration в Windows Server 2008 R2, або Dynamic Memory в підготовлюваний до виходу Service Pack 1.

У цій статті ми без жодного marketing bullshit, ми поговоримо про «тонкої настройки», покликаної підвищити продуктивність системи на базі Microsoft Hyper-V. Я спробую розглянути деякі архітектурні особливості Hyper-V, дати кілька порад про те, як можна підвищити продуктивність, не вдаючись до нових фінансових витрат, і як можна побачити, що взагалі відбувається «там, всередині».

Як підвищити продуктивність?

Зрозуміло, якщо щось в системі починає «пригальмовувати» - то найпростішим шляхом буде купити більш потужну систему. Але це не завжди прийнятно, і не тільки через фінансові причини. Наприклад, заміна обладнання часто супроводжується простоєм системи, що не завжди допустимо. У цій частині статті ми подивимося, як можна спробувати підвищити продуктивність системи на базі Hyper-V без втручання в апаратну частину.

Віртуальні процесори

У документації Microsoft досить часто зустрічається поняття «логічний процесор». Під цим терміном розуміють процесорні ядра. Віртуальні процесори - це ті процесори, які бачить гостьова ОС на віртуальній машині. Припустимо, у нас є хост з двома процесорами Intel QuadCore Xeon, на якому запущено 10 віртуальних машин, в настройках кожної з яких встановлено по два віртуальних процесора. В результаті у нас виходить 8 логічних процесорів і 20 віртуальних процесорів.

Скільки ж процесорів призначати віртуальним машинам? Hyper-V дозволяє призначити кожній віртуальній машині максимум 4 процесора. Крім того, різні ОС можуть підтримувати різний максимальну кількість процесорів. У середовищі Hyper-V офіційно підтримується Windows Server 2003, Windows Vista і Windows XP SP3 з двома віртуальними процесорами, Windows Server 2008 R2, Windows 7, RHEL і SLES (з Linux Integration Services 2.1) - до чотирьох віртуальних процесорів.

Використання декількох віртуальних процесорів може призводити до деякого зниження продуктивності, але це більш актуально для Windows Server 2003. При цьому Windows Server 2008 R2 буде нормально працювати навіть з чотирма віртуальними процесорами.

Так скільки ж віртуальних машин можна запустити на одному фізичному сервері? Microsoft офіційно підтримує до 8 віртуальних процесорів на 1 логічний процесор. При цьому для максимальної продуктивності рекомендується робити не більше 4 віртуальних процесорів на 1 логічний.

Як же порахувати таке співвідношення? Зрозуміло, можна «руками» пройтися з налагодження всіх віртуальних машин, і порахувати віртуальні процесори. Але що робити, якщо віртуальних машин багато, або ми маємо справу з кластером, де віртуальні машини періодично мігрують з одного вузла на інший? Тут допоможе скрипт з одного рядка на PowerShell, який я люб'язно запозичу у Бена Армстронга:

write-host (@ (gwmi -ns root \ virtualization MSVM_Processor) .count / (@ (gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum) .Sum) "virtual processor (s) per logical processor" -f yellow

Якщо ви вибираєте залізо - то, крім гігагерца і кількості ядер, потрібно дивитися на обсяг кеша L2 / L3. Чим він більший - тим вище буде продуктивність, особливо для віртуальних машин з великими обсягами пам'яті. Крім того, дуже бажано вибирати процесори з підтримкою технології перетворення адрес SLAT. У чому сенс цієї технології? Справа в тому, що гостьові ОС не працюють з фізичною пам'яттю безпосередньо. Замість цього їм виділяється простір гостьових фізичних адрес. При зверненні до пам'яті гостьової ОС стек віртуалізації перетворює за допомогою спеціальної таблиці цю адресу в фізичну адресу сторінки пам'яті. Це створює додаткове навантаження на пам'ять і на процесор. Технологія SLAT дозволяє здійснювати таке перетворення адрес безпосередньо процесором, в результаті чого накладні витрати сильно скорочуються. У деяких випадках використання SLAT дозволяє отримати приріст продуктивності до 40%. Щоб дізнатися, чи підтримує процесор технологію SLAT - потрібно глянути в специфікацію. У AMD це може називатися Rapid Virtualization Indexing (RVI) або (раніше) Nested Page Tables (NPT), у Intel - Extended Page Tables (EPT).

пам'ять

Пам'ять - це чи не найбільш критичний для продуктивності ресурс. До недавнього часу виділення пам'яті для віртуальних машин викликало деякі труднощі. Справа в тому, що пам'ять віртуальній машині виділяється «жорстко», і змінити це значення можна тільки зупинивши гостьову ОС, що не завжди прийнятно. Розрахувати ж точно, «скільки вішати в грамах» - часто не така і проста задача, так як споживання пам'яті може залежати від безлічі факторів. Тому, як правило, брали вимоги вендорів ПО а-ля «на 100 користувачів - 2 Гб пам'яті» і додавали (а іноді і не додавали) деякий запас. Все б нічого, але тут криються дві проблеми. По-перше, можна помилитися в розрахунках (а вендорськіх вимоги - це «сферичний кінь у вакуумі», вони цілком можуть не мати нічого спільного з реальністю) - що призведе до падіння продуктивності. По-друге, якщо виділити віртуальній машині занадто багато пам'яті - вона буде простоювати, що по суті означає викинуті на вітер гроші. Особливо, якщо віртуальних машин більше однієї. З виходом Service Pack 1 для Windows Server 2008 R2 з'явилася нова технологія - Dynamic Memory, що дозволяє в режимі реального часу виділяти віртуальним машинам стільки пам'яті, скільки їм потрібно для роботи. Dynamic Memory можна порівняти з динамічними VHD, які збільшують обсяг у міру необхідності. Але, на відміну від VHD, обсяг виділеної пам'яті може не тільки збільшуватися, але і зменшуватися, дозволяючи віддати невикористану пам'ять іншим віртуальним машинам. Хоча на момент написання статті Service Pack 1 знаходиться в версії Release Candidate, і тому я не можу рекомендувати використовувати його в продуктивних системах - я буду торкатися Dynamic Memory надалі.

За розподіл пам'яті відповідають п'ять параметрів, з яких перші два можуть бути змінені тільки при зупиненій віртуальній машині, а інші два можуть змінюватися прямо «на льоту»:

· Startup RAM

· Maximum RAM

· Memory Buffer

· Memory Weight

Startup RAM - це обсяг пам'яті, що виділяється віртуальній машині при запуску ОС. Microsoft рекомендує значення Startup RAM 512 Мб для Windows Server 2008, 2008 R2, Windows 7 і Vista. Для Windows Server 2003 і Windows XP рекомендується початкове значення 128 Мб. У деяких випадках, Startup RAM можна підвищити. Зокрема, якщо використовуються «важкі» серверні додатки, що стартують разом з гостьової ОС, і споживають багато пам'яті. Зокрема - Exchange Server.

Maximum RAM - максимальний обсяг пам'яті, який може бути виділений віртуальній машині. Незважаючи на те, що це значення може перевищувати обсяг фізичної пам'яті сервера - не спокушайтеся, це не memory overcommit, і використовувати пам'яті більше, ніж фізично є - не вийде. За замовчуванням це значення дорівнює 64 Гб, і його можна і потрібно зменшити, якщо необхідно обмежити «апетит» віртуальної машини.

Memory Buffer - один з найцікавіших параметрів. Він дозволяє виділяти віртуальній машині не рівно стільки пам'яті, скільки їй потрібно, а трохи більше. Тобто, якщо ОС і запущені програми споживають 600 Мб пам'яті і Memory Buffer дорівнює 20%, то віртуальній машині буде виділено 600 * (1 + 0,2) = 720 Мб. Якщо навантаження носить піковий характер, наприклад - це сервер БД, на якому періодично виконують складні аналітичні звіти - то значення Memory Buffer можна збільшити. Тоді в період чергового «піку» у віртуальної машини буде достатній обсяг вільної пам'яті, і не знадобиться звертатися до файлів підкачки. Крім того, Memory Buffer можна збільшувати, наприклад, для файлових серверів або для веб-серверів - яким потрібна вільна пам'ять для файлового кеша. Проте, зловживати цим параметром не варто - бо якщо одна віртуальна машина забере собі зайву пам'ять - це може означати, що комусь вона не дістанеться, коли буде потрібна.

Memory Weight - пріоритет віртуальної машини при розподілі пам'яті. У бета-версії цей параметр так і називався «Memory Priority». До тих пір, поки на хості є вільна пам'ять - цей параметр ніяк себе не проявляє. Але як тільки пам'ять закінчується, і треба у когось пам'ять відбирати, а кому-то - навпаки, додати - тут-то і починає працювати механізм пріоритетів. У тих віртуальних машин, у яких пріоритет найнижчий - пам'ять буде відбиратися в першу чергу. І, відповідно, на додавання пам'яті першими в черзі встають віртуальні машини з найбільш високими пріоритетами. Для найбільш критичних віртуальних машин можна підвищити пріоритети - і тоді при нестачі пам'яті у них буде найбільший шанс цю пам'ять отримати. А для найменш критичних пріоритет можна, навпаки, знизити - щоб в разі чого у них можна було забрати надлишок невикористаної пам'яті.

Є ще один досить важливий параметр - Memory Reserve. Він дозволяє зарезервувати певний обсяг пам'яті для використання хостовой ОС. Цей резерв не братиме участі в розподілі між віртуальними машинами. Змінити параметр Memory Reserve можна тільки через реєстр (HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Virtualization \ MemoryReserve, тип параметра REG_DWORD). Резервовану обсяг задається в мегабайтах. Максимальне значення - 4096. Якщо вказати більше значення - все одно буде виділено лише 4 Гб. Microsoft вважає, що якщо слідувати Best Practices, і не запускати в хостовой ОС нічого крім, власне, Hyper-V - то вистачить і 32 Мб, але я б все ж порекомендував ставити 1 Гб. На всякий випадок.

дискова підсистема

Дискова підсистема - найбільш типове «вузьке місце», і в системі віртуалізації - особливо. Справа в тому, що багато програм оптимізують роботу з диском так, щоб операції запису-читання були по можливості послідовними. Як приклад можна привести бази MS Exchange Server 2010. Проте, при роботі безлічі віртуальних машин потік вводу-виводу виходить випадковим, і ефективність всіх цих оптимізацій зводиться до нуля. Вирішити цю проблему, крім екстенсивного нарощування потужностей підсистеми зберігання даних (додавання жорстких дисків в RAID-масив, установка більш високопродуктивних контролерів, і т.п.) можна за рахунок використання прямого підключення дисків до віртуальних машин замість VHD-файлів. Наприклад, для ОС можна використовувати VHD, а бази даних зберігати на pass-through-дисках. Незважаючи на те, що Microsoft стверджує, що в Windows Server 2008 R2 продуктивність VHD практично ідентична прямому підключенню дисків - я не готовий стверджувати, що це повністю відповідає дійсності.

Крім цього, є ще одна рекомендація щодо дисків. Не рекомендується використовувати у виробничому середовищі VHD динамічного обсягу, а так само моментальні знімки віртуальних машин (snapshots). Хоча по продуктивності динамічні VHD не надто сильно поступаються VHD фіксованого обсягу - можливе падіння продуктивності при збільшенні обсягу VHD-файлу за рахунок фрагментації. Крім цього, можлива ситуація, коли обсяг VHD не зможе збільшитися через нестачу дискового простору - що теж досить неприємно. Знімки не рекомендується використовувати з тієї ж самої причини: вони призводять до дроблення VHD на кілька файлів, що так само не кращим чином може позначитися на продуктивності. І тут є знову ж неприємний момент: якщо після видалення моментального знімка гостьова ОС перезавантажуватиметься - запуститься операція злиття, до закінчення якої гостьова ОС не запуститься. Цей процес може зайняти досить багато часу. А якщо в процесі злиття закінчиться дисковий простір - пиши «пропало». Віртуальну машину доведеться відновлювати з резервної копії.

Мережеві інтерфейси

Чомусь традиційно при тюнінгу продуктивності в першу чергу звертають увагу на процесор і пам'ять, а про мережеві інтерфейси якось забувають. А проте, мережева підсистема цілком може стати «пляшковим горлечком». Наприклад, якщо на віртуальних машинах запущені сервіси, які генерують великі обсяги мережевого трафіку - бази даних, або файлові сервера. Крім використання більш високопродуктивних мережевих адаптерів (1Gbps - мінімум, а краще - 10Gbps), можна за допомогою віртуальних мереж рознести різні віртуальні машини по окремим мережних інтерфейсів. Особливо, якщо використовується iSCSI - то для iSCSI настійно рекомендується використовувати окремий мережевий адаптер, а краще - кілька. Якщо у вас відмовостійкий кластер і використовується Live Migration - то бажано виділити на кожному вузлі кластера окремий мережевий адаптер для трафіку міграції. Ну і зрозуміло, дешеві адаптери SOHO-класу краще не використовувати, оскільки серверні мережеві адаптери підтримують такі корисні функції, як TCP Chimney Offload і Virtual Machine Queues (VMQ), що дозволяють передати більшу частину функцій по обробці пакетів процесору мережевого адаптера.

Хостової і гостьові ОС

Так само потрібно звернути увагу на налаштування ОС - як хостовой, так і гостьових. Я навмисно не буду говорити про тюнінг окремих додатків - ця тема гідна навіть не окремої статті, а цілої книги. Причому деякі додатки, такі, як SQL Server або Exchange Server - навіть окремих книг.

Що стосується хоста. По-перше - не рекомендується запускати в хостовой ОС будь-які ролі і додатки. Microsoft рекомендує запускати в хостовой ОС тільки агенти систем управління і резервного копіювання. Крім цього, рекомендується встановлювати ОС в режимі Server Core: це знизить споживання пам'яті, а так же обсяг оновлень, і підвищить безпеку.

У гостьових ОС - по-перше, рекомендується використовувати як можна більш нові версії ОС. Зокрема, Windows Server 2008 R2 працює у віртуальному середовищі набагато краще, ніж Windows Server 2003. Так само необхідно стежити, щоб в гостьовій ОС була встановлена ​​остання версія служб інтеграції - це теж може впливати на продуктивність.

Моніторинг продуктивності Hyper-V

Як дізнатися, що продуктивність падає, до того, як користувачі почнуть скаржитися, що у них «все гальмує»? Найкращий спосіб - використання лічильників продуктивності. Не варто використовувати інструменти моніторингу всередині гостьової ОС - через особливості архітектури Hyper-V вони не завжди можуть показувати достовірну інформацію. Використовувати найкраще лічильники в хостовой ОС, причому найкраще - ті, що безпосередньо пов'язані з Hyper-V.

CPU

Лічильник Hyper-V Hypervisor Logical Processor \% Total Run Time покаже завантаження загальне навантаження на процесори хоста. Для того, щоб подивитися навантаження окремих віртуальних машин, можна використовувати лічильник Hyper-V Hypervisor Virtual Processor \% Guest Run Time. Показання цих лічильників можна тлумачити так: значення нижче 75% означають, що все в порядку, вище 75% - пора задуматися, а вище 85% означають, що потрібно щось робити: або встановлювати більш потужні процесори, або якимось чином знижувати навантаження.

пам'ять

На хості потрібно стежити за лічильником Hyper- V Dynamic Memory Balancer \ Available Memory, який показує обсяг пам'яті, доступної для розподілу між віртуальними машинами. Для окремих віртуальних машин є лічильник Hyper- V Dynamic Memory VM \ Physical Memory, що відображає обсяг пам'яті, фактично виділений обраної віртуальній машині (або декільком - в залежності від параметрів лічильника). Крім цього, можна звернути увагу на лічильники так званої навантаження (Memory Pressure). Навантаження - це відношення обсягу пам'яті, який віртуальній машині потрібно до того обсягу, який був їй фактично виділено. Навантаження вимірюється у відсотках, і значення має бути нижче 80%. Значення від 80% до 100% повинно змушувати задуматися, а вище 100% означає, що пам'яті явно недостатньо. «Середню температуру по лікарні» показує лічильник Hyper-V Dynamic Memory Balancer \ Average Pressure, а для окремих віртуальних машин існує лічильник Hyper-V Dynamic Memory VM \ Average Pressure.

Якщо у вас не використовується Dynamic Memory - то перш за все потрібно звернути увагу на лічильник Memory \ Commited Bytes, що показує, яка з віртуальних машин скільки пам'яті фактично використовує з виділених їй. Якщо використовується менше 90% виділеної пам'яті - то все в порядку. Якщо більше 90% - то потрібно подивитися, чи не потрібно додати пам'яті, а може, десь є витік пам'яті, або ж неправильні настройки. А може, варто додати віртуальній машині ще пам'яті. Якщо ж у віртуальної машини залишається менше 100 Мб вільної пам'яті - то це означає, що терміново потрібно щось робити.

диски

Тут нужно звернути Рамус на лічильник \ LogicalDisk (*) \ Average Disk Sec \ Read / Write. Цей лічильник показує середній час, вітраченій на операции запису / читання. Нормальне значення - нижчих 10 мілісекунд (0,010). Значення до 15мс (0,015) и вищє означають, що треба звернути Рамус на дискову підсістему, а значення, что перевіщують 25мс (0,025) говорять про критичність сітуацію. Щоб визначити, яка з віртуальних машин викликає навантаження - є лічильники Hyper-V Virtual IDE Controller / Read / Write Bytes / Sec, що показує кількість зчитуються або записуються байт в секунду для кожного віртуального дискового контролера. Більш того, є лічильник Hyper- V Virtual Storage Device / Read / Write Bytes / Sec, за допомогою якого можна подивитися кількість байт в секунду для окремих віртуальних дисків.

Мережа

Для оцінки загального стану мережевих інтерфейсів є лічильник \ Network Interface (*) \ OutputQueue Length. Його значення не повинно перевищувати 1, а значення вище 2 говорять про критичну ситуацію. Щоб подивитися, хто саме генерує навантаження на мережевий інтерфейс - є групи лічильників для віртуальних комутаторів і для окремих віртуальних мережевих адаптерів. Для віртуальних комутаторів існує група Hyper-V Virtual Switch. З цієї групи два лічильника: Bytes / Sec і Packets / Sec - показують обсяг трафіку, що проходить через віртуальний комутатор, відповідно - в байтах і в пакетах в секунду. Для віртуальних мережевих адаптерів існують групи лічильників Hyper-V Virtual Network Adapter і Hyper-V Legacy Network Adapter. У цих групах параметри Bytes Sent / Sec і Bytes Received / Sec показують обсяг переданого і прийнятого трафіку в байтах в секунду.

Висновок

У цій статті я розповів про те, як можна підвищити продуктивність системи віртуалізації на базі Hyper-V і про те, як за цією продуктивністю спостерігати. Якщо я щось упустив, і у кого-то є будь-які ідеї - із задоволенням їх вислухаю.