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

Ступні 2099 Мб памяті, а у запущених на ньому ВМ в сумі 4096 Мб

До речі кажучи, і це важливо, «споживана память» у такій ситуації може бути як менше (хороший випадок), так і більше, ніж память «доступна» (поганий

Рис 625 Прикладна ілюстрація Memory Overcommitment

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

випадок) Для ілюстрації – зверніть увагу на стовпець Host Memory Usage на попередньому малюнку Як бачимо, при 4096 Мб показаної памяті віртуальні машини реально використовують 553 Мб, що цілком поміщається в наявних у сервера 2099 Мб Це якраз приклад «хорошого» випадку memory overcommitment

Memory Overcommitment досягається на ESX (i) за рахунок декількох техноло-

гий Перелічимо їх:

Q виділення за запитом

Q дедуплікація оперативної памяті, transparent memory page sharing

Q механізм балон, він же balloon driver або vmmemctl

Q стиск памяті, memory compression (новинка 41)

Q файл підкачки гіпервізора, VMkernel swap

Що це Яке місце цих технологій Наскільки вони застосовні Наскільки вони марні Давайте поміркуємо

Вступна до роздумів

Ми будемо міркувати про споживання памяті віртуальними машинами, а точніше – гостьовими ОС і додатками

Основна ідея ось у чому – «показана» сервера (тут не важливо, фізичній або віртуальному) оперативна память ніколи не завантажена на 100% Чому У вас завантажена саме так Значить, ви погано спланували цей сервер, згодні

Кілька тверджень, на яких базуються подальші міркування

1&nbsp&nbsp&nbsp Нам слід прагнути до того, що віртуальні машини не повинні весь час споживати 100% від «показаної» ім памяті Таким чином, інші міркування я буду засновувати на тому, що у вас саме так Те, що деякі завдання займають чимось (наприклад, кешем) всю вільну память, тут не враховуємо, так як розмова йде в загальному

2&nbsp&nbsp&nbsp У різний час доби / дні тижня наші програми споживають память по-різному Більшість завдань споживають максимум ресурсів в робочі години в будні, з піками вранці або в середині дня, або <підставте дані своєї статистики> Однак бувають додатки з нетиповим для нашої інфраструктури профілем споживання памяті

3&nbsp&nbsp&nbsp У вашій інфраструктурі зроблений запас по оперативної памяті серверів, тобто «доступною» памяті Цей запас робиться з таких міркувань:

• архітектор побоюється промахнутися з необхідним обсягом «Промахнутися» в сенсі «продати менше памяті, ніж потрібно для обумовлених віртуальних машин»

• як запас на випадок відмови сервера (або декількох)

• як запас на випадок зростання кількості віртуальних машин або навантаження на існуючі віртуальні машини

Далі

Ризикну припустити, що в наших інфраструктурах можна виділити кілька груп віртуальних машин, по-різному споживають память Спробую запропонувати класифікацію Вона зразкова, тому що тут я її пропоную лише для ілюстрації своїх роздумів

Q  ВМ додатків – Скільки памяті ви виділяєте («показуєте» в моїх визначеннях тут) своїх серверів додатків При опитуваннях на курсах я чую цифри 4-8, рідко більше Вірніше, для малого числа ВМ більше Більшість таких додатків споживає ресурси в робочі години, проте бувають і винятки (наприклад, сервери резервного копіювання, що працюють ночами)

Q  Інфраструктурні ВМ – Всякі DNS, DC і т п Зазвичай гігабайт або два Споживають ресурсів мало, піки, якщо взагалі є, – в робочі години

Q  Тестові ВМ – Думаю, гігабайт або два в середньому по лікарні, і більше на вимогу, дивлячись що тестувати будемо Піки в робочі години, десь буває купа тестових віртуальних машин, що простоюють подавляюще велику частину часу (як крайній випадок – хтось створив і закинув, а видалити ВМ страшно – раптом кому потрібна)

Давайте тепер розглянемо ці групи віртуальних машин в контексті механізмів роботи з памяттю

Далеко не всі ВМ споживають всю виділену память весь час роботи І часто виникають ситуації, коли для ВМ виділені 10 (наприклад) Гб, а вона активно використовує лише 7 Або один

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

Віртуальній машині виділили («показали») 2 Гб Віртуальну машину включили Що відбувається далі

Етап 1 – включення Припустимо, у момент включення гість споживає всю або більшу частину доступної памяті Хтось забиває її нулями, хтось просто багато хоче в момент включення Це найгірший випадок – Адже тоді гостю потрібна вся «показана» йому память Ок, гіпервізор йому всю видає Отже, на етапі 1

«Споживана» память дорівнює «показаної», в найгіршому випадку

Етап 2 – гість стартував всі служби, служби почали працювати, створювати навантаження Але не 100% памяті споживається, см твердження 1 Наприклад, 1200 Мб з виділених 2000 Тобто гість 800 Мб позначив у себе в таблиці памяті як

«Вільна» По-хорошому гіпервізорами треба б її забрати Він і забирає (забігаючи вперед – для цього використовується механізм balloon) Отже, балон роздувся, потім відразу здувся Що вийшло: гостю 1200 Мб потрібно, тому вони балоном або не оніміли, або відразу повернулися назад Але більше памяті гостю зазвичай не потрібно – і він більше не запитує у гіпервізора А раз не запрошувати, гіпервізор цієї віртуальній машині більше сторінок фізичної памяті і не виділяє

Отже, якщо гість споживає не всю показану память, гіпервізор йому не виділить в реальному оперативці більше, ніж він хоча б раз зажадає Те, що одного разу було затребувано і виділено, але потім звільнено і не використовується, періоди-

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

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

Працює цей механізм завжди, коли віртуальна машина споживає не 100% «показаної» памяті Тобто завжди, крім перших хвилин після включення і рідкісних піків, цей механізм працює і помітно економить нам память

Якщо віртуальна машина не споживає всю память часто – механізм дуже корисний

Для деяких тестових – 100% часу

Для інфраструктурних – іноді большую частину часу

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

Ефект на продуктивність якщо і є негативний, то несуттєвий

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

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

Гипервизор вважає контрольні суми сторінок оперативної памяті Знаходить спільні (для однієї або декількох віртуальних машин) сторінки І однакові сторінки з різних «віртуальних таблиць памяті »адресує в одну-єдину сторінку в памяті реальної (рис 626)

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

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

Наскільки часто це застосовується до різних груп віртуальних машин

Складне питання Складність – у все більш широко використовуваному механізмі Large Pages Якщо у вас Windows 7/2008 + Nehalem і використовуються сторінки памяті по 2 Мб, теорія говорить, що ефект від page sharing буде маленьким Хоча в реальності там досить складний алгоритм:

ESX (i) розбиває 2 Мб сторінку на 4 Кб, вважає їх контрольні суми, але

не використовує механізм page sharing, поки памяті сервера достатньо А от якщо памяті сервера перестає вистачати на всі віртуальні машини, то, перед тим як

Рис 626 Ілюстрація роботи механізму Page Sharing Джерело: VMware

включати якийсь із механізмів підкачки, гіпервізор починає робити sharing цих маленьких 4 Кб шматків

А якщо великі сторінки не використовуються вашої інфраструктурою – ефект часто досить значний

Продуктивність не відчуває негативного ефекту від застосування даного механізму Тим більше що ESX (i) знає, що таке архітектура NUMA, і якщо сервер у нас цієї архітектури, то дедуплікація сторінок памяті йде всередині кожного одного NUMA вузла незалежно, щоб віртуальній машині не доводилося за окремими, дедупліцірованнимі сторінками звертатися в память іншого процесора

Джерело: Міхєєв М О Адміністрування 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>

*

*