Віртуалізація - Налаштування Dynamic Memory в Windows Server 2008 R2 SP1 з роллю Hyper-V.

Ви вже знаєте, що не так давно вийшли остаточні версії платформи Microsoft Windows Server 2008 R2 SP1 і безоплатна його версії Hyper-V Server 2008 R2 SP1 , Орієнтованої тільки на завдання віртуалізації. Одне з основних нововведень - функції Dynamic Memory для віртуальних машин, що дозволяють динамічно виділяти і розподіляти оперативну пам'ять між ними.

Давайте подивимося як це працює. Стаття заснована на замітці " Dynamic Memory Coming to Hyper-V Part 6 ", Яка є частиною серії заміток про Dynamic Memory, посилання на які розміщені в кінці статті.

В першу чергу, Dynamic Memory дозволяє виділяти віртуальній машині на хості Hyper-V пам'ять динамічно, відповідно до запитів ВМ. Тобто, це дозволяє не виділяти всю можливу для використання ВМ пам'ять, а виділити стільки, скільки потрібно для базової завантаження і найпростішої роботи. По-друге, за допомогою Dynamic Memory Balancing відбувається перерозподіл пам'яті між працюючими віртуальними машинами, що призводить до зростання коефіцієнта консолідації віртуальних машин на хост-сервері Hyper-V R2 до 40% (особливо для VDI-навантажень).

Давайте подивимося на екран налаштувань пам'яті для віртуальної машини в Hyper-V Manager:

Як ми бачимо, тут є 2 види установок виділення пам'яті віртуальної машини:

• Static - в цьому випадку пам'ять віртуальній машині виділяється відразу в зазначеному обсязі, і вона зберігається за нею поки віртуальна машина запущена або знаходиться в стані "paused". Як тільки машина вимикається - пам'ять вивільняється.
• Dynamic - в цьому випадку є параметри Startup RAM і Maximum RAM, які впливають на виділення пам'яті ВМ в процесі її роботи.

• Startup RAM - це обсяг пам'яті, який буде фізично виділений і закріплений за віртуальною машиною при її запуску. В даному випадку - це 1 ГБ.
• Maximum RAM - це максимальне значення пам'яті, яке може використовувати гостьова ОС віртуальної машини (пам'ятаєте, що вона повинна підтримувати цей обсяг)

Також під цими параметрами розташовується настройка Memory Buffer.

Ця установка визначає кількість пам'яті, який буде потрібно Гіпервізор на обслуговування віртуальної машини в службових цілях, наприклад, для можливостей SuperFetch . Вона може бути задана у відсотках від 5 до 95%. Тобто, якщо у вас у віртуальної машини коштує 1 ГБ пам'яті для гостьової ОС і 20% memory buffer - то у вас буде 250 МБ за його службові цілі. За замовчуванням коштує 20% - і це оптимально в більшості випадків. Для високопродуктивних і вимогливих до швидкодії і пам'яті навантажень, можливо, має сенс збільшити це значення. До речі, ця настройка змінюється навіть у запущеній віртуальної машини, без необхідності її зупинки.

Далі переходимо до останньої налаштування - Memory priority.

Ця установка в Hyper-V еквівалентна, по-суті, опції Shares в VMware vSphere. Коли віртуальних машин на хості багато, і вони починають боротися за ресурси, то потрібно якось пріоритезувати виділення пам'яті нужденним віртуальним машинам. Memory priority і визначає як вони будуть її розподіляти між собою в умовах боротьби - тобто машина з більш високим пріоритетом отримує пам'ять першої і в обсязі пропорційному пріоритету (тобто виглядає ставлення її пріоритету до суми загальних пріоритетів на хості Hyper-V).

Тепер, як це працює на практиці. У нас є три віртуальних машини з початковою пам'яттю 1 ГБ (Startup RAM) і максимальної 4 ГБ (Maximum RAM) для кожної. При цьому всього на сервері є 8 ГБ на всі машини. Ми їх запускаємо - пам'ять відразу виділяється в обсязі суми цієї Startup RAM (3 ГБ).

За 15 хвилин. Finance VM починає вважати звіти, а Engineering VM - запускає задачу аналізу даних. Пам'ять машини Finance VM зростає до 3 ГБ, машини Engineering VM - до 2 ГБ, при цьому навантаження на Sales VM не змінюється - і їй залишається виділено 1 ГБ. Всього на сервері використовується 6 ГБ або 75% від усієї доступної пам'яті (8 ГБ):

Через 30 хвилин. Finance VM продовжує вважати звіти і, врешті-решт, закінчує цю справу, вивільнивши пам'ять до 2 ГБ. При це Engineering VM - продовжує аналіз даних, доводячи використовувану пам'ять до 3,5 ГБ, майже досягши максимальної межі. І тут ми ще запускаємо Service VM з початковою пам'яттю в 1 ГБ. Все використовується: 2 + 3,5 + 1 + 1 = 7.5 ГБ або десь 94% від 8 ГБ сервера.

Це і є оптимальне використання ресурсів сервера.

Тут виникає питання - а що якщо віртуальним машинам буде потрібно ще пам'ять? Чи буде це означати, що сторінки підуть в своп, організований Hyper-V для віртуальної машини?

По-перше, Dynamic Memory має можливість вилучити невикористовувані сторінки пам'яті у віртуальної машини і передати їх найбільш потребує ВМ на хості. Робиться це шляхом запуску високопріоритетного процесу в простоює ВМ, який починає "виїдати" пам'ять в ОС цієї машини і передавати ці сторінки іншим ВМ. Але пам'ять віртуальної машини нижче Startup RAM ніколи не опуститься - це її гарантований мінімум. Решта розподіляється відповідно до Memory priority при нестачі ресурсів.

По-друге, коли на хості Hyper-V зовсім не залишиться вільного місця, включет механізм свопіювання в гостьовій системі , А не на рівні віртуальної машини (тобто, всередині образу ВМ, а не на сховище з VHD-диском). Робиться це тому, що гостьова ОС сама краще знає, які сторінки їй краще складати в своп - і, відповідно, відбуваються менші втрати продуктивності. Природно, такий ситуації треба уникати - будь-який диск працює в сотні тисяч разів повільніше пам'яті.

Ну а тепер корисні посилання по тому, як працює Dynamic Memory в Hyper-V: