vSphere освіта - Які недоліки в налаштуванні VM з * занадто * великою кількістю оперативної пам’яті?

Управління пам'яттю VMware, здається, є хитрою рівновагою. З кластерною оперативною пам’яттю, пулами ресурсів, методами управління VMware (TPS, балончиками, заміною хостами), використанням оперативної пам’яті в гостях, заміною, резерваціями, поділами та обмеженнями існує велика кількість змінних.

Я перебуваю в ситуації, коли клієнти використовують виділені ресурси кластерного vSphere. Однак вони налаштовують віртуальні машини так, ніби вони були на фізичному обладнанні. У свою чергу, це означає, що стандартна збірка VM може мати 4 vCPU і 16 Гб або більше оперативної пам’яті. Я приїжджаю зі школи, починаючи з малого (1 vCPU, мінімальна оперативна пам’ять), перевіряючи використання в реальному світі та коригуючи за необхідності. На жаль, багато вимог щодо постачальників та люди, незнайомі з віртуалізацією, вимагають більше ресурсів, ніж необхідно ... Мені цікаво оцінити вплив цього рішення.

Деякі приклади кластера "проблем".

Підсумок пулу ресурсів - Здається, майже 4: 1 перевиконано. Зверніть увагу на велику кількість балонованої оперативної пам’яті.

Розподіл ресурсів - стовпець "Найгірший випадок" показує, що ці ВМ матимуть доступ до менш ніж 50% їх налаштованої оперативної пам'яті за обмежених умов.

Графік використання пам’яті в реальному часі верхнього VM у списку вище. Виділено 4 vCPU та 64 ГБ оперативної пам’яті. Він в середньому становить менше 9 ГБ.

Підсумок того ж ВМ

• Які недоліки перевиконання та переконфігурування ресурсів (зокрема оперативної пам’яті) у середовищах vSphere?

• Якщо припустити, що віртуальні машини можуть працювати в меншій мірі оперативної пам’яті, чи справедливо сказати, що накладні витрати на налаштування віртуальних машин з більшою кількістю оперативної пам’яті, ніж їм насправді потрібно?

• У чому зустрічний аргумент: "якщо VM має 16 ГБ оперативної пам’яті, але використовує лише 4 ГБ, в чому проблема ?? "? Наприклад, чи потрібно клієнтам бути освіченими, що VM - це не те саме, що фізичне обладнання?

• Які конкретні показники слід використовувати для вимірювання використання оперативної пам’яті. Відстеження піків "Активного" порівняно з часом? Дивишся "Споживає"?

Оновлення: я використовував vCenter Operations Manager для профілювання цього середовища та отримання детальної інформації про статистику кластера, перелічену вище. Хоча напевно надмірно передано, віртуальні віртуальні машини насправді настільки переконфігуровані з непотрібною оперативною пам’яттю, що реальний (крихітний) слід пам’яті не показує суперечок пам’яті на рівні кластера / хоста…

Моє вирішення полягає в тому, що віртуальні віртуальні машини повинні бути справжнього розміру з трохи буфера для кешування на рівні ОС. Перевиконання невідомості або "вимог" продавця призводить до ситуації, представленої тут. Повітряна куля пам'яті, здається, погана у кожному випадку, оскільки є вплив на продуктивність, тому правильне розмір може допомогти запобігти цьому.

Оновлення 2: Деякі з цих віртуальних машин починають виходити з ладу:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware описує це як симптом важкого перевиконання пам'яті . Тому я думаю, що це відповідає на питання.

vCops звіт "Негабаритні віртуальні машини" ...

vCops "Відшкодування відходів" ...

Управління пам’яттю vSphere є досить пристойним, хоча терміни, що використовуються, часто викликають велику плутанину.

Взагалі слід уникати перевиконання пам'яті, оскільки це створює саме такий тип проблеми. Однак бувають випадки, коли цього не вдається уникнути, тому попередження попереджується!

Які недоліки перевиконання та перенастроювання ресурсів (зокрема оперативної пам’яті) у середовищах vSphere?

Основним недоліком перевитрати ресурсів є те, що якщо у вас виникнуть суперечки, ваші хости будуть змушені здійснювати повітряні кулі, обмінюватись або розумно розкладати / видаляти копії за лаштунками, щоб надати кожному VM оперативну пам’ять, яка йому потрібна.

Для повітряної кулі vSphere надує "повітряну кулю" оперативної пам’яті в обраному VM, а потім передасть цю повітряну операційну пам’ять гостю, який її потребує. Це насправді не «погано» - віртуальні машини крадуть оперативну пам’ять один одного, тому не відбувається ніякої заміни диска - але це може призвести до помилкового оповіщення та перекосів показників, якщо вони покладаються на аналіз використання оперативної пам’яті VM, оскільки оперативна пам'ять виграла не позначатись як "повітряна куля", лише те, що вона "використовується" ОС.

Інша особливість, яку може використовувати vSphere, - це прозорий поділ сторінок (TPS) - це, по суті, дедуплікація ОЗУ. vSphere періодично сканує всю виділену ОЗУ, шукаючи дублюються сторінки. Коли його знайдуть, він буде дублювати та звільняти дублювані сторінки.

Погляньте на посібник з управління пам’яттю vSphere (PDF) - зокрема «Меліорація пам’яті в ESXi» (стор. 8) - якщо вам потрібно більш поглиблене пояснення.

Якщо припустити, що віртуальні машини можуть працювати в меншій мірі оперативної пам’яті, чи справедливо сказати, що накладні витрати на налаштування віртуальних машин з більшою кількістю оперативної пам’яті, ніж потрібно?

Немає видимих ​​накладних витрат - ви можете виділити 100 Гб оперативної пам’яті на хості об'ємом 16 Гб (однак, це не означає, що вам слід із зазначених вище причин).

Загальна пам'ять, якою користуються всі ваші відеомагнітофони, - це "Активна" крива, показана на ваших графіках. Звичайно, ніколи не слід розраховувати лише на цю цифру, коли підраховуєш, яку суму ти хотів би перевиконати, але якщо у тебе є такі історичні показники, як ти є, ти можеш їх аналізувати та опрацьовувати на основі фактичного використання.

Різниця між "активною" та "спожитою" оперативною пам’яттю обговорюється в цій темі спільноти VMWare .

У чому зустрічний аргумент: "якщо в VM виділено 16 Гб оперативної пам’яті, але використовується лише 4 ГБ, в чому проблема?" ? Наприклад, чи потрібно залучати клієнтів?

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

Клієнти повинні бути навчені розміщувати свої VM відповідно до того, що вони використовують , а не того, що вони хочуть . Багато часу люди будуть надмірно задавати свої VM лише тому, що їм може знадобитися 16 Гб оперативної пам’яті, навіть якщо вони історично б’ються по 2 ГБ день у день. Як адміністратор vSphere, ви маєте знання, метрики та потужність, щоб кинути їм виклик і запитати, чи дійсно їм потрібна оперативна пам'ять, яку вони виділили.

Однак, якщо поєднувати управління пам'яттю vSphere з ретельно контрольованими лімітами перевиконання, на практиці рідко виникає проблема, ймовірність закінчення оперативної пам’яті протягом тривалого періоду відносно віддалена.

На додаток до цього, автоматизована програма vMotion (звана VMware розподіленим плануванням ресурсів ) по суті є балансиром навантаження для ваших віртуальних машин - якщо одна ВМ стає перетворювачем ресурсів, DRS повинні мігрувати ВМ навколо, щоб найкраще використовувати ресурси кластеру.

Який конкретний показник слід використовувати для вимірювання використання оперативної пам'яті. Відстеження піків "Активного" порівняно з часом?

Здебільшого висвітлено вище - вашою основною проблемою повинно бути «Активне» використання оперативної пам’яті, хоча ви повинні ретельно визначити свої порогові значення, щоб досягти певного співвідношення ( це гідний приклад , хоча він може бути трохи застарілим). Як правило, я б, звичайно, залишався в межах 120% загальної оперативної пам’яті кластера, але вирішувати, яке співвідношення вам подобається.

Кілька хороших статей / дискусій про перевиконання пам'яті:

• Перевиконання пам'яті у виробництві? ТАК ТАК ТАК
• vSphere - перевиконання пам'яті?
• Переповнення пам'яті в vSphere

На додаток до чудової відповіді Крейга Уотсона, я хотів би додати наступне:

Надмірно заповнювати пам'ять у VMware - це не те, що слід робити спеціально. Зазвичай це показує, що ви або ваш клієнт надмірно передплачуєте обладнання.

Якщо надмірний вчинок є єдиним вибором, я настійно раджу дотримуватися правил пріоритету. Якщо хтось схиляється до надання некритичного VM 16 Гб vRam, коли йому потрібно лише 4 ГБ - принаймні, покладіть цей VM в пул низьких ресурсів або надайте йому низький пріоритет. Ви дійсно не хочете, щоб гіпервізор міняв критичну виробничу базу даних. Не тільки продуктивність знизиться, вона також з'їсть черги вводу / виводу проти вашого резервного сховища.

Якщо ви працюєте на швидкому зберіганні даних (FusionIO, скрипка, локальний SSD тощо), то заміна може не викликати особливих проблем, але з традиційним SAN-накопичувачем ви врешті-решт вплинете на кожен окремий VM та хост, підключений до одного масиву / контролера.