Ми вже не раз зачіпали тему vswp-файлів віртуальних машин (файли підкачки), які використовуються для організації swap-простору гіпервізором VMware ESXi. Ці файли виконують роль останнього ешелону серед технік оптимізації пам'яті в умовах нестачі ресурсів на хості. Нагадаємо, що в гіпервізора VMware ESXi є такі техніки як Transparent Page Sharing , Memory Ballooning , A також Memory Compression , Які дозволяють розбиратися з ситуаціями нестачі пам'яті, необхідної віртуальним машинам.

Нагадаємо також, що першим ешелоном оптимізації пам'яті є техніка Memory Ballooning. Вона працює за рахунок використання драйвера vmmemctl.sys (для Windows), що поставляється разом з VMware Tools. Він дозволяє "надути" куля всередині гостьової ОС (balloon), який захоплює фізичну пам'ять, виділену цієї ОС (якщо її багато), і віддає її іншим гостьовим операційним системам, які її потребують. Цей balloon не дозволяє гостьовий ОС виробляти роботу додатків з даною галуззю пам'яті, тому якщо їм буде потрібна додаткова пам'ять - вона буде йти в гостьовій своп. Це більш правильний підхід, ніж свопувати гостьову ОС в файл підкачки vswp на томі VMFS, оскільки операційна система сама краще розбирається, що і коли їй класти і діставати з свопу (відповідно, швидкодію вище).

Однак, коли пам'яті у всіх віртуальних машин зовсім мало або окремої ВМ її потрібно більше, ніж налаштоване, а також відбувається постійне звернення до пам'яті (особливо, якщо в гостьових ОС немає VMware Tools), гипервизор починає використовувати vswp-файл підкачки, який за замовчуванням знаходиться в папці з віртуальною машиною. Ми вже писали про те, що з метою підвищення швидкодії можна покласти vswp-файли віртуальних машин на локальні SSD-сховища серверів ESXi, а також про те, як видаляти сміттєві файли vswp .

Нижче ми наведемо 8 фактів про swap-файлах віртуальних машин, які засновані на ось цієї замітці Френка Деннемана:

1. Зберігання vswp-файлів на локальних дисках сервера ESXi (в тому числі Swap to Host Cache) збільшує час vMotion. Це очевидно, тому що доводиться копіювати vswp-файл в директорію ВМ (або іншу налаштовану директорію), щоб його бачив цільової хост.

2. З точки зору безпеки: vswp-файл не чиститься перед створенням. Тобто там лежать не нулі, а попередні дані блоків. Нагадуємо, що розмір файлу підкачки дорівнює розміру сконфигурированной пам'яті ВМ (якщо не налаштований Reservation). Якщо ж у машини є Reservation, то розмір vswp-файлу визначається за формулою:

Configured memory - memory reservation = size swap file

Тобто, якщо в настройках пам'яті машини їй виділено 4 ГБ, а Reservation налаштований в 1 ГБ, то vswp-файл буде складати 3 ГБ.

3. Як відбувається копіювання vswp-файлу при vMotion? Спочатку створюється новий vswp-файл на цільовому хості, а потім копіюються тільки swapped out сторінки з вихідного в цільової vswp-файл.

4. Що відбувається при різниці в конфігурації розміщення vswp-файлів в кластері і для окремих хостів? Нагадаємо, що в налаштуваннях кластера VMware vSphere є 2 опції зберігання vswp-файлів: в папці з ВМ (за замовчуванням) і в директорії, яка вказана в налаштуваннях хоста:

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

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

6. vswp-файл краще не поміщати на реплицируемой сховище. Це пов'язано з тим, що використовувані сторінки пам'яті, що знаходяться в двох синхронізуються файлах, будуть постійно реплицироваться, що може викликати зниження продуктивності реплікації, особливо якщо вона синхронна і особливо при vMotion в недефолтной конфігурації (коли відбувається активне копіювання сторінок і їх реплікація):

7. Якщо ви використовуєте снапшоти на рівні сховищ (Datastore або LUN), то краще зберігати vswp-файли окремо від цих сховищ - так як в ці снапшоти потрапляє багато непотрібного, що міститься в своп-файлах.

8. Чи потрібно класти vswp-файли на сховища, які розгорнуті на базі thin provisioned datastore (на рівні LUN)? Відповідь на це питання залежить від того, як ви моніторите вільне місце на тонких місяцях і пристроях свого дискового масиву. При створенні vswp-файлу VMkernel визначає його розмір і можливість його створення на рівні хоста ESXi, а не на рівні пристрою дискового масиву. Тому якщо vswp-файл активно почне використовуватися, а ви цього не помітите при неправильній конфігурації і відсутності моніторингу тонких томів - то можуть виникнути проблеми з їх переповненням, що призведе до збоїв в роботі ВМ.