Механізми перерозподілу ресурсів в ESX (i) – ЧАСТИНА 3

Однак у теорії накладні витрати мають місце бути: якщо якась ВМ хоче змінити розділяється з іншими сторінку памяті, за допомогою технології Copy-on-write робиться копія сторінки, яка і віддається приватно даної ВМ Це повільніше, ніж просто дати записати в неподілюваний сторінку Наскільки помітний ефект у реальному житті, сказати дуже складно

Офіційні дані щодо впливу Page Sharing на продуктивність наступні (рис 627)

На цьому малюнку кожна трійка стовпців – різна задача

Перший в кожній трійці стовпець – продуктивність завдання у віртуальній машині, коли page sharing для неї не використовується

Другий стовпець – продуктивність при використанні page sharing, з настройками за замовчуванням

Третій стовпець в кожній трійці – використовується page sharing, із зменшеною частотою сканування памяті

За одиницю обрані дані тестів з відключеним page sharing Як видно, середній стовпець – з увімкненим page sharing і параметрами за замовчуванням – не гірше, а іноді краще по продуктивності Поліпшення повязують з тим, що memory footprint у віртуальної машини стає менше і краще поміщається в кеш У кожному разі, різницю по продуктивності можна назвати несущест-

Механізми перерозподілу ресурсів в ESX (i)

Рис 627 Порівняння продуктивності трьох завдань щодо застосування до них Page Sharing

кої Результати першої і третьої бенчмарки – число транзакцій в секунду, для компілювання ядра – витрачений час

Ефект від роботи даного механізму легко виявити на вкладці Summary

для пулу ресурсів (рис 628)

Рис 628 Виділення памяті для пяти ВМ

У пулі ресурсів з малюнка пять ВМ Кожній виділено по 1 Гб памяті З 5 Гб виділеної на ці пять ВМ памяті на 3,5 Гб поширюється механізм page sharing

На закладці Resource Allocation для віртуальної машини можна побачити цю інформацію стосовно неї однієї (рис 629)

Рис 629 Виділення памяті для однієї ВМ

Як видно, з належних їй чотирьох гігабайт ця віртуальна машина розділяє з іншими ВМ півтора гігабайти

Цей же показник Shared можна побачити на закладціPerformance, Вибравши відповідний лічильник для памяті (рис 630)

Відмінність shared common і shared в наступному: коли у трьох ВМ одна спільна сторінка, то shared common – обсяг цієї однієї сторінки, а shared total – трьох

Для налаштування процесу сканування памяті пройдіть Home Configuration

Advanced Settings сервера Тут є можливість вказати наступні параметри:

Q MemShareScanTime – як багато часу можна витрачати на сканування

Q MemShareScanGHz – скільки ресурсів можна витрачати (якщо 0, то ця функція не буде працювати на цьому сервері)

Для відключення цього механізму для окремої ВМ додайте в її файл налаштувань (* Vmx) параметр

schedmempshareenable = false

Пробувати відключити цей механізм має сенс лише у випадках аномально високого завантаження процесорів віртуальної машини або сервера, або для експериментів зі збільшення продуктивності ВМ

Механізми перерозподілу ресурсів в ESX (i)

Рис 630 Shared і Shared Common лічильники

Коли оперативної памяті багато і всі працюючі віртуальні машини в ній поміщаються, все добре Однак не виключені ситуації, коли памяті вистачати перестає Самий явний приклад – сталася відмова сервера, серверів ESX (i) залишилося менше, а ВМ працює на них стільки ж

У таких ситуація нас виручать налаштування limit, reservation і shares – з їх допомогою ми заздалегідь вказали, яким ВМ дати більше памяті Але виходить, у менш пріоритетних ВМ память буде потрібно відняти, щоб віддати її більш пріоритетним Само собою, просто так відібрати память у ВМ не можна – можна частину її даних витіснити в файл підкачки Ось механізми vmmemctl (balloon driver), memory compression і vmkernel swap цим і займаються

Один з компонентів VMware tools – це драйвер пристрою vmmemctl За командою ESX (i) він починає запитувати у гостьовій ОС память, так само як це роблять додатки гостьовий ОС Тобто цей драйвер роздуває той самий «балон» всередині, запитуючи (тобто віднімаючи) память у гостя

Навіщо це треба Для вирішення двох завдань

Перша вже описана вище: якщо гостю були виділені сторінки памяті, які він уже перестав використовувати, то гіпервізор не може такі вільні сторінки відрізнити і забрати А що роздув всередині «балону» гість сам їх віддасть в першу чергу і потім не запросить у гіпервізора їх назад Сторінки реальної памяті, зайняті «балоном», гіпервізор відрізнить від інших сторінок памяті, виділених даної ВМ, і перестане їх адресувати для неї

Подивіться на рис 631 – сторінки памяті, гостем для себе помічені як

«Вільні», позначені зірочками зліва А праворуч, в наступному стані описуваного механізму, вони вже не займають залізну память сервера

Рис 631 Ілюстрація відбирання раніше запитаної, але невикористовуваної памяті механізмом Balloon

Друге завдання – коли гостю виділено, наприклад, 2 Гб, а 1 Гб з них треба відняти Характерний приклад – коли памяті сервера перестало вистачати різко збільшити число віртуальних машин А число їх різко збільшилася через збій одного з серверів і рестарту його ВМ на іншому

Так от, у віртуальної машини треба відняти память Гипервизор роздуває балон, гість починає використовувати свій власний файл / розділ підкачки Реальну память, тепер зайняту балоном (з точки зору гостя), гіпервізор віддає другий ВМ

Тобто balloon driver – це спосіб гіпервізорами задіяти механізм підкачки гостя

До речі, в моєму прикладі гіпервізор віддасть команду відняти гігабайт А чи весь гігабайт балон відніме Може бути, і не весь – гість цілком може відмовити йому в памяті, якщо визнає, що іншим додаткам память потрібніше Якщо балон не впорався, то гіпервізор доотнімет залишився за допомогою memory compression і vmkernel swap

Коли механізм балона може не впоратися:

Q коли в ВМ не встановлені VMware tools vmmemctl – це частина VMware tools

Q коли vmmemctl не завантажено Наприклад, при старті ВМ, до того як загру-

зілась гостьова ОС

Q коли vmmemctl не здатний відняти память досить швидко

Q за замовчуванням балон забирає не більше 65% памяті ВМ Крім того, можна цю настройку поміняти індивідуально для ВМ, прописуванням в її файлі налаштувань

Механізми перерозподілу ресурсів в ESX (i)

schedmemmaxmemctl = <дозволене до відбирання кількість мегабайт>

Перевірити, що для ВМ недоступний механізм balloon, можна таким чином: запустите esxtop, перейдіть на екран Memory натисканням «m», натисніть

«F» і відзначте стовпець «MCTL» Натисніть Enter Значення «N» у цьому стовпці для якоїсь ВМ означає, що драйвер vmmemctl в ній не працює

У ваших інтересах, щоб цей механізм був доступний для всіх ВМ Зокрема, тому що він використовується не тільки для відбирання та перерозподілу памяті у випадку нестачі ресурсу (як у прикладі вище) Ще він використовується, щоб витіснити ВМ з частини фізичної оперативної памяті, коли та їй вже не використовується Це набагато більш часта операція, і з використанням balloon вона проходить безболісно і невідчутно для продуктивності ВМ

Суть цього механізму – в тому, що гіпервізор резервує якийсь обсяг памяті під створення такого собі кеша Тепер, коли постає завдання два з опису балона – впихнути ВМ в менший, ніж їм хочеться, обсяг памяті, – частина памяті віртуальної машини буде стиснута і поміщена в раніше зарезервовану область (рис 632)

Рис 632 Ілюстрація роботи Memory Compression

Стан «а» – треба вивантажити дві сторінки памяті з реального оперативки Стан «b» – вирішення питання «по старинці», механізмами підкачки Стан «с» – модернова рішення питання Сторінки стиснуті і поміщені

в раніше зарезервовану область памяті сервера

Ідея в тому, що стиснути і записати дані в память, або прочитати і розтиснути, швидше, ніж без стиснення читати або писати з диска, з файлу підкачки

Зверніть увагу на те, що память під цей кеш НЕ резервується на сервері заздалегідь – це частина памяті самої ВМ Тобто коли для ВМ перестає вистачати памяті, гіпервізор віднімає у неї ще трохи – і в цьому «трохи» він розміщує стислі сторінки її памяті, яким не вистачає місця просто так

Якісь налаштування для даного механізму доступні тільки через Advanced Options для ESX (i)

Трохи вище я описав vmmemctl (balloon) – механізм для витіснення частини оперативної памяті гостя в файл / розділ підкачки

Потім розповів про memory compression, проміжний механізм між використанням механізмів підкачки і просто роботою в оперативній памяті

А тепер поговоримо про останній механізм для тієї ж самої мети – відбирання реальної памяті у віртуальної машини

При включенні кожної віртуальної машини гіпервізор створює файл Vswp – файл підкачки vmkernel для цієї ВМ

Тепер коли гіпервізорами треба забрати частину памяті у віртуальної машини, він може просто з частини сторінок скопіювати вміст в даний файл і перенаправляти звернення ВМ до памяті у файл Гість нічого про це знати не буде

Щоб проілюструвати відмінність між механізмами balloon і vmkernel swap, давайте поглянемо на рис 633

Рис 633 Рівні роботи з оперативною памяттю

Ви бачите три рівня оперативної памяті

Верхній, Application memory, – це память, яку бачать додатки всередині ВМ Адресуватися ця память може в оперативну память (яку гостьова ОС вважає апаратної) плюс файл підкачки гостьовий ОС

Механізми перерозподілу ресурсів в ESX (i)

Другий рівень, Guest memory, – це та память, яку показує гіпервізор для гостьової ОС Адресуватися він може в фізичну память сервера і файл підкачки гіпервізора Це той самий файл, який створюється при включенні ВМ і розмір якого дорівнює hardware memory мінус reservation

Як ви бачите, файлів підкачки ми можемо задіяти два, на різних рівнях цієї схеми А який краще Краще той, який є файлом підкачки гостьовий ОС Бо якщо використовується він, то гостьова ОС може сама вибрати сторінки памяті, які підуть першими в файл підкачки, і вибере вона найменш важливі У той час як гіпервізор в свій файл підкачки поміщає якісь сторінки памяті ВМ, у гіпервізора немає можливості визначити, що в них і наскільки вони критичні

Так от, balloon – це спосіб витіснити гостя з реальної оперативної памяті в його внутрішній файл підкачки, а vmkernel swap – витіснити гостя з реальної оперативної памяті в зовнішній файл підкачки, який гіпервізор створив для цієї віртуальної машини

VMkernel swap можна задіяти завжди – гіпервізорами потрібно лише в таблиці памяті поміняти посилання з памяті фізичної на файл підкачки – це основний плюс даного механізму

У механізму balloon завдань, можна сказати, дві Перше завдання – відібрання незайнятої памяті Це завдання стабільно актуальна для віртуальних машин будь-якої групи

Друге завдання, спільна для всіх трьох механізмів, – перерозподіл викорис зуемое памяті між віртуальними машинами Дане завдання мені бачиться мало актуальною – при адекватному плануванні інфраструктури Давайте розберемо її злегка докладніше

Отже, з чого може взятися ситуація, коли у однієї ВМ память треба відняти, щоб віддати іншій Я бачу кілька варіантів

Коли у нас memory overcommitment і відразу у багатьох ВМ наступили піки навантаження, що призвело до завантаження сервера на 100% по памяті Це, до речі кажучи, причина користуватися memory overcommitment акуратно Втім, зовсім відмовлятися від memory overcommitment, як закликає нас робити Майкрософт, на мою думку, теж не варто

Коли у нас ламається один із серверів кластера HA Наприклад, у нас 10 серверів, все завантажені по памяті (вдень, в будні) відсотків на 70 Однак після відмови одного з серверів є ймовірність, що один або кілька залишилися виявляться завантаженими на 100% – HA хоч і вибирає для включення кожної з упалих віртуальних машин найменш завантажений сервер, але гарантій достатності ресурсів не дає

Далі ситуація розгалужується Якщо у вас є DRS, то він швиденько рознесе ВМ по різних серверах, і перерозподіляти память не доведеться

А от якщо DRS немає, або він НЕ в автоматичному режимі – ось тут ми приходимо до браку на всі ВМ фізичної памяті (на одному або декількох серве-

рах) І гіпервізор відніме память у частині машин за допомогою балона або решти двох механізмів

Таким чином, якщо у вашій інфраструктурі виконуються наступні умови:

Q ресурсів серверів достатньо для всіх віртуальних машин, з урахуванням їх

піків і з урахуванням планових і непланових простоїв частини серверів Це найголовніша умова

Q у вас є кластер DRS, і він налаштований на автоматичний режим Баланс-

ровки навантаження

Так от, якщо ці умови виконуються, ймовірність того, що перерозподіляти память не буде потрібно, прагне до 100%

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

Хочеться явно зазначити, що навіть наявність балона і інших механізмів не дає стовідсоткової гарантії, що запустяться всі віртуальні машини, але всі будуть відчувати брак памяті Правда, якісь віртуальні машини можуть

«Залишитися на коні» за рахунок опускання інших ВМ у ще більше «свопування» (у налаштуванні пріоритету віртуальних машин нам допоможуть настройки reservation і shares)

І за великим рахунком, це і є ефект від роботи і сам сенс існування описуваних функцій перерозподілу памяті

Звідси висновок: наявність Balloon driver, memory compression і vmkernel swap – це безсумнівний плюс для інфраструктури, але не панацея від браку памяті Краще планувати інфраструктуру, навантаження на неї і збільшення доступних ресурсів так, щоб ці механізми не прігождается взагалі, – інакше частина віртуальних машин буде відчувати брак ресурсів

У ESX (i) є лічильник – відсоток вільної памяті Його порогові значення Судячи з документації, це: Q> 6% = high Нормальний стан сервера

Q> 4% = soft Памяті залишилося менше, ніж вважається нормальним, але гострої нестачі ні

Q> 2% = hard Ситуація з памяттю стає критичною

Q> 1% = low Все, приїхали

Однак, за деякими даними, ці константи злегка інші:

Q High = вільно понад 64% памяті

Q Soft = вільно від 64% до 32% Q Hard = вільно від 32% до 16% Q Low = вільно менше 16%

Як ESX (i) реагує на зміну стану цього лічильника:

Q  Стан High Задіюється тільки page sharing

Механізми перерозподілу ресурсів в ESX (i)

Q  Стан Soft Вільної памяті менше, ніж хотілося б Починаємо використовувати balloon

Q  Стан Hard Вільної памяті мало Використовуємо ще й compression і vmk swap

Q  Стан Low Гипервизор використовує всі доступні механізми і плюс до того може зупинити виконання віртуальних машин, що вимагають память понад виділеної в даний момент

Зверніть увагу Якщо для якоїсь віртуальної машини слід відключити роботу механізмів Balloon driver і VMkernel swap, то простий спосіб це зробити – вказати значення reservation для памяті рівним значенню Hardware memory цієї віртуальної машини

Balloon, memory compression і vmkernel swap і роблять одну і ту ж роботу Але balloon робить її більш оптимально – дозволяє гостю самому вибрати, що поміщати в своп Дані тестів наведені на наступних малюнках, перший з яких – рис 634

Рис 634 Час виконання компіляції

при відлученні памяті за допомогою balloon або vmkernel swap

Стовпцями відображається обсяг відібраної у віртуальної машини памяті Червона лінія з ромбами – швидкість компіляції, зелена з квадратами – тільки vmkernel swap Як видно, коли з 512 Мб памяті у гостя залишалося тільки 128, при використанні для відбирання памяті balloon швидкість виконання бенчмарки практично не знижувалася

Специфіка даного тесту, компіляції, – у тому, що самому процесу память особливо не потрібна – основний обєм зайнятий під кеш даних Так от, у разі balloon гість розумів, що в своп краще покласти спочатку дані, ніж ядро ​​ОС або ядро ​​програми А в разі vmkernel swap такий вибір зробити не можна, і в своп йде «щось»

А ось дані за схожих умов для бази даних Oracle, навантаженої відповідною утилітою (рис 635)

Рис 635 Кількість транзакцій в секунду для БД Oracle при відлученні памяті за допомогою balloon або vmkernel swap

Зверніть увагу: поки balloon віднімав менше ніж 1792 Мб з 3840, продуктивність практично не падала Це знову ж специфіка програми, але додатки характерного

А от для якихось додатків різниці не буде (рис 636)

Рис 636 Кількість транзакцій в секунду для SPECjbb при відлученні памяті за допомогою balloon або vmkernel swap

Механізми перерозподілу ресурсів в ESX (i)

І в початковому діапазоні vmkernel swap навіть менше негативу робить на продуктивність ВМ Втім, відсоток додатків, ось так використовують память, малий, в загальному випадку Тут використовувалася бенчмарка SPECjbb – утиліта для тестування навантаження, що імітує навантаження на серверну частину Javaпріложеній

А от для Exchange різниця кардинальна (рис 637)

Рис 637 Затримки при обробці пошти сервером Exchange при відлученні памяті за допомогою balloon або vmkernel swap

Якщо відняти 9 з 12 Гб памяті балоном, то це дасть подвоєння latency, в той час як відібрання 2 Гб з 12 за допомогою vmkernel swap – утрідцатіеніе () Знову ж Exchange використовує всю доступну память для кешування даних з метою мінімізації обігу до дисків

Таким чином, якщо використання підкачки неминуче, balloon – це менше зло Проте ще разок зауважу – на мою думку, вам рідко доведеться опинитися в ситуації, коли balloon працюватиме через нестачі памяті І навіть якщо така ситуація станеться, balloon дасть зниження продуктивності, просто майже завжди менше зниження, ніж використання vmkernel swap

А тепер порівняємо це ще й з compression

Як бачимо, при використанні механізму balloon досить безболісно можна відібрати 8 з 32 Гб памяті, а з memory compression – ще 2 Гб

Як видно, compression – не панацея, але якщо вже памяті жорстко не вистачає, то з compression краще, ніж без нього (краще, ніж тільки з vmkernel swap відразу після balloon, якщо бути точним) Навантаження на процесори збільшується на 1-2%, що невідчутно

Першоджерело даних тестування – документ «Understanding Memory Resource Management in VMware ESX 41» (http://wwwvmwarecom/resources/ techresources/10129)

Рис 638 Відлучення памяті у сервера SharePoint механізмами memory compression і vmkernel swap

Одним з механізмів управління ресурсами дискової підсистеми у ESX (i) можна розглядати настоянки Multipathing Детально про них розповідалося в розділі 3

У версії 41 зявився механізм Storage IO Control – про нього розповідається в розділі 614

З механізмів управління ресурсами мережевої підсистеми у ESX (i) є тільки підтримка угруповання контролерів (NIC Teaming) і обмеження пропускної здатності каналу (traffic shaping) Детально про них розповідалося в розділі 2

Крім того, у версії 41 зявився механізм Network IO Control, про нього розказано в розділі 615

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*