NetApp FAS і VMware ESXi: Swap

В продовження теми про оптимізації хоста з VMware ESXi, розглянемо як чинити зі Swap'ом в інфраструктурі живе на СГД NetApp FAS. Хоча ця стаття повинна бути корисна і не тільки власникам систем NetApp FAS.

Одна з найважливіших можливостей віртуалізації полягає в можливості більш ефективно утилізувати серверне обладнання, що має на увазі Overcommit ресурсів. Якщо ми говоримо про ОЗП, це означає, що ми можемо налаштувати кожній віртуальній машині більше пам'яті, ніж є на сервері насправді. А далі ми покладаємося на ESXi, щоб той розрулив боротьбу за ресурси — забрав (такий процес часто називають reclamation) не потрібну пам'ять однієї віртуальної машини і віддав тієї, що її дійсно потребує. В той момент коли не вистачає пам'яті, починається процес свапинга пам'яті.

Почнемо з того, що є два типу свапинга які можуть відбуватися на ESXi хості. Їх дуже часто плутають, тому давайте умовно будемо називати їх Тип 1 і Тип 2.


Розташування даних VMware ESXi за замовчуванням


Тип 1. VMX swapping (vSwap)


Це найпростіший тип свапинга для опису. Пам'ять виділяється не тільки для віртуальних машин, а також і для різних компонент хоста, наприклад для монітора віртуальних машин (VMM) і віртуальних пристроїв. Така пам'ять може бути свапирована для того, щоб виділити більш нужденним віртуальним машинам більше фізичної пам'яті. За словами VMware ця можливість може вивільнити від 50MB до 10MB пам'яті, для кожної віртуальної машини без істотного погіршення продуктивності.

Цей тип свапианга включений за замовчуванням, VMX Swap зберігатимуться в папці з віртуальною машиною у вигляді файлу з розширенням vswp (розташування може бути змінено через параметр sched.swap.vmxSwapDir). VMX swapping може бути виключений за допомогою установки параметра віртуальної машини sched.swap.vmxSwapEnabled = FALSE.

Тип 2. Guest OS Swapping


Віртуальна машина «бачить» стільки нібито «фізичної» пам'яті, скільки ОЗП задано в її настройках. З точки зору гоствеой ОС, вся така виділена пам'ять для неї фізична. Насправді гіпервізор приховує за шаром віртуалізації для гостьової ОС, яка ж пам'ять використовується на самому справі: фізична або vSwap. Коли пам'ять «всередині» гостьовий ОС закінчується, вона сама починає свапить. І ось тут потрібно не заплутатися — цей процес не має нічого спільного зі свапингом на рівні хоста (VMX). Наприклад, для віртуальної машини з налаштованими 4GB пам'яті, гіпервізор може выдилить цю пам'ять на хості, як у фізичній пам'яті, так і в свапе хоста (VMX) — для віртуальної машини це не важливо, все 4GB будуть використані як фізична пам'ять просто тому, що гостьова ОС не має поняття, що її пам'ять виртуализирована.

Коли гостьова ОС хоче використовувати більше ніж 4GB пам'яті, вона буде використовувати власний свапинг, Windows використовує pagefile.sys в Linux це виділений Swap. Таким чином свапо зберігається всередині віртуального диска — всередині одного з VMDK файлів віртуальної машини. Тобто Pagefile.sys/Swap це частина віртуального диска віртуальної машини.

І ось що відбувається, коли використовується драйвер балунинга: коли він «роздувається», він забиває всю вільну (з точки зору гостьовий ОС) пам'ять, при цьому драйвер балунинга засвідчується що він отримує насправді фізичну, не свапированную пам'ять хоста, а коли у такої віртуальної машини немає вільної пам'яті, це затсавляет гостьову ОС почати свапить дані. І це добре, так як гостьова ОС краще знає що свапить на диск, а що ні.

ESXi Host swapping


Коли ми розуміємо, що ESXi хост дуже багато свапит, це говорить про те, що у нас дуже велике перерасходывание ресурсів, все reclamation і техніки по економії пам'яті (ballooning, page sharing і стиснення memory) не рятують — хосту просто не вистачає ОЗП. Вважається, що хост перебуває в стані «Hard state» (1%-2% пам'яті вільно) або «Low state» (1% і менше). Такий стан справ істотно погіршує продуктивність, його потрібно уникати. Інша проблема, коли Swapping на рівні хоста не має контролю над тим, що туди потрапляє — в отличае від свапинга гостьовий ОС (Тип 2), гіпервізор не знає, які дані більш важливі для гостьової ОС, по-цьому важливо встановлювати VMware Tools, щоб працював драйвер балунинга.

vSwap (Тип 1) за замовчуванням зберігається .vswp файл у папці з віртуальною машиною. NetApp рекомендує зберігати vSwap (Тип 1) на виділений датастор.

/vmfs/volumes/4b953b81-76b37f94-efef-0010185f132e/vp # ls-lah |grep swp
--rw------ 1 root root 2.0 G Jan 11 18:02 vp-c6783a5c.vswp


Такий файл існує тільки для запущених віртуальних машин — при запуску гіпервізор створює цей файл і видаляє при виключенні віртуальної машини. Зверніть увагу на розмір цього файлу — він дорівнює різниці між сконфігурованої пам'яттю для віртуальної машини і резервом фізичної пам'яті за цією машиною. Таким чином забезпечується наявність заданого простору пам'яті, коли віртуальна машина стартує (не залежно від того, яка пам'ять використовується — справжня фізична або vSwap). Резерв піклується про те, щоб віртуальна машина отримала потрібне середовище завжди у фізичній пам'яті хоста. а різниця між резервом та налаштованої пам'яттю віртуальної машини зберігається в vswp файл.

Нижче приклад запуску віртуальної машини з 4GB пам'яті і резервом 2GB. Пам'ятайте, що vSwap видаляється після виключення? А якщо в цей момент датастор зберігає цю віртуальну машину заповниться і залишиться вільного 1.8 GB простору, що станеться?


Що можна з цим зробити? Звичайно ж можна вивільнити простір на датасторе або розташувати vSwap (Тип 1) на іншому датасторе. За замовчуванням він зберігатися в папці з віртуальної пашиною. Якщо це «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Розташування vSwap файлів також можна змінити на рівні налаштувань кожної віртуальної машини. Відкрийте налаштування віртуальної машини і виберіть вкладку Options:


Якщо цей хост частина кластера, загляньте в налаштування кластера Store the swapfile in the datastore specified by the host


Далі оберіть датастор де буде зберігатися vSwap (Тип 1).

Навіщо розташовувати свапо на окремий датастор?




Рекомендована схема розташування Swap'а для NetApp FAS

По-перше варто зазначити, що загальне правило VMware говорить по можливості розташовувати vSwap (Тип 1) у папці з віртуальною машиною, так як винесення на окремий датастор може уповільнити vMotion. Але в окремому випадку VMware + NetApp FAS вступає інша рекомендація. NetApp рекомендує зберігати vSwap (Тип 1) на окремому виділеному, який один для всіх віртуальних машин датасторе, так як в цьому випадку різниця при міграції vMotion практично нивилирована. VMware рекомендує, щоб пространсто під vSwap (Тип 1) було більше або дорівнює різниці сконфігурованої і зарезервованої для віртуальної машини пам'яті. Інакше віртуальні машини можуть не стартувати. Приклад: у нас є 5-ть віртуальних машин з розміром пам'яті 4GB і резервацією для кожної 3GB.

Мінімальний розмір датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB

Якщо на хості немає вільних фізичних 5VM * 3 = 15 GB пам'яті, машини не можуть стартувати, виводячи помилку:
The host does not have sufficient memory resources to satisfy the reservation


І в той же час буде створений Event log


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

В-третіх це снепшоты і дедубликация на рівні сховища. Так як у нетапа снепшоты не впливають на продуктивність, вони є нормою життя, постійно виконуються і є частиною парадигми резервного копіювання NetApp для систем FAS. Свапо це абсолютно даремна інформація при резервне копіювання та відновлення. Якщо він інтенсивно використовується, а снепшоты часто знімаються, в снепшотах буде «захоплена» і зберігатися весь час життя снепшота, ця даремна інформація. А так як свапо постійно змінюється, а спепшот захоплює тільки нові змінені дані, в кожному такому снепшоте буде зберігатися ці нові змінені дані з свапа, нещадно поїдаючи корисний простір під непотрібні дані на сховище. Дедублицировать свапо немає ніякого резону, адже дані в свапе не потрібні при відновленні і ніколи не будуть прочитані. У цьому сенсі зручно виносити свапи на окремий датастор. NetApp рекомендує розташовувати свапо на окремий датастор з вимкненими снепшотами і дедубликацией, так ми можемо ще сильніше зменшити оверхед в снепшотах і на реплікації.

NetApp не рекомендує використовувати локальні диски (стор 76-78, DEC11) на хості, для зберігання vSwap (Тип 1) тому, що така конфігурація має негативний вплив на швидкість виконання операції vMotion.

Варто виносити Тип 2 Swap?


Розміщення тимчасових даних, таких як Swap та Pagefile.sys на виділений датастор (створивши виділений віртуальний диск для цієї мети) дозволяє не дедублицировать і не бекапировать ці дані також як і vSwap (Тип 1). Дуже важливо не забути вказати цей диск Independent, щоб агент VSC не змушував FAS знімати снепшоты з розділу зберігає Swap файли (Тип 2).


У NetApp немає рекомендацій щодо Swap Тип 2, винесення цих даних є опціональним дизайном, у якого є свої плюси і мінуси:

На додаток до винесеного vSwap Тип 1, винесення Swap Тип 2 ще сильніше зменшить оверхед на снепшотах, і як наслідок збільшить пропускну здатність для реплікації. ACB DR рішень наявність Swap'а (обидва типи) не нисет ніякого смислового навантаження, адже він не використовується при старті системи. Якщо ми перестанемо зберігати Swap (Тип 2) в снепшотах і резервних копіях, при локальному відновленні це не повинно викликати будь-яких проблем, так як відновлюваний .vmx config файл буде містити посилання на VMDK файл зберігає розділ Swap'ом, адже той перебуватиме на тому ж місці. Але це додасть додаткові кроки при відновленні на віддаленій майданчику, в таких конфігураціях SRM, SnapProtect та інших DR рішень.


Так при відновленні віртуальної машини VMDK файлу зберігає свапо гостьовий ОС, потрібно доповнити кроками створення віртуального диска, файлової системи на ньому і його підключення до віртуальної машини (або підключення існуючого VMDK створеної з файловою системою). Детальніше TR-3671.

Повідомлення щодо помилок у тексті прошу направляти в ЛС.
Зауваження і доповнення навпроти прошу в коментарі

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.