NetApp ONTAP UNMAP у SAN оточенні

Команда UNMAP стандартизована в рамках набору команд T10 SCSI і використовується для вивільнення простору з тонких місяців тому назад даних в SAN оточенні. Як я писав раніше, протоколи SAN і NAS потроху запозичують одне в одного все найкраще. Одна з корисних речей, яка з'явилася досить давно, це можливість зворотного зв'язку СГД та хоста, для того щоб «повертати» віддалені блоки в тонкий місяць, чого раніше так не вистачало в SAN. Функцією UNMAP, як і раніше, мало хто користується в SAN оточенні, хоча вона дуже корисна в поєднанні як з віртуалізованими так і не віртуалізованими середовищами.

Без підтримки команди UNMAP будь-який тонкий місяць створений на стороні СГД завжди міглишезбільшуватися у розмірі. Його зростання було питанням часу, який беззастережно завжди закінчувався тим, що такий тонкий місяць зрештою займатиме свій повний обсяг, що йому належить, тобто. врешті-решт він стане товстим.

Ось уявіть у вас на датасторі живуть 3 віртуальні машини, кожна займає 100GB. Ваш датастор знаходиться на тонкому місяці, що займає 300GB. Зайнятий простір з боку СГД та ESXi однаковий: 300GB. Після видалення однієї ВМ, розмір вашого місяця з боку СГД, як і раніше, 300GB, а з боку гіпервізора займаний простір на датасторі 200GB, що живе на цьому місяці.

Пов'язано це про те, що рані був механізму зворотний зв'язок хоста з СХД. А саме коли хост записував блок інформації в місяці, СГД у свою чергу позначала цей блок як використовуваний. Далі хост міг видалити цей блок, але система зберігання про це вже не знала. Команда UNMAP і є цей зворотний зв'язок, який відмаплює вже не потрібний блок із місяця. Нарешті наш тонкий місяць навчився не тількинабирати, але й зменшувати свою вагу, починаючи з версії прошивки (Clustered Data) ONTAP 8.2.

VMware ESXi & UNMAP

У версії 5.0 функція UNMAP вперше була представлена, включена вона була за замовчуванням і автоматично запускалася при досягненні заданого значення віддалених блоків, у наступних версіях механізм вимкнено за замовчуванням і запускається вручну. Починаючи з VMFS-6 (vSphere 6.5), вивільнення простору відбувається автоматично протягом 12 годин, при необхідності ручний механізм запуску вивільнення простору також доступний. Важливо, що вивільнення простору, про який зараз йтиметься відбувається на рівні гіпервізора, тобто. вивільнення віддалених блоків відбуваєтьсялишепісля видалення віртуальної машини або віртуальних дисківцілком, а не всередині гостьової ОС.

Якщо у вас уже є ESXi та СГД з ONTAP з підтримкою UNMAP, але функція не включена

Потрібно її включити з боку СГД та гіпервізора. Почнемо з того, що переведемо місяць в оффлайн і включимо функціюspace-allocationна СГД (якщо там залишилися ВМ у занедбаному стані, вони завершать роботу некоректно і можливо будуть пошкоджені, так що їх варто або тимчасово вимкнути, або тимчасово мігрувати):

Після чого потрібно включитиunmapз боку ESXi, для цього потрібно відмапити та примапити датастор, щоб ESXi виявив підтримку UNMAP (якщо там залишилися ВМ у запущеному стані, вони завершать роботу некоректно і можливо будуть пошкоджені, так що їх варто або тимчасово вимкнути або тимчасово мігрувати):

Після цього, щоб вивільняти простір, потрібно буде періодично запускати команду:

Важливо відзначити, що UNMAP працює тільки для місяців відформатованих зі зміщенням партиції кратне 1 MB. Щоце означає? Це означає, що якщо ви колись конвертували VMFS3 в VMFS5, UNMAP не працюватиме. Перевірити це просто, конвертовані VMFS3 мають таблицю розбивки MBR, а VMFS5, які були створені заново, мають розбивку GPT.

Зверніть увагу на колонку Layout.

Перевірити усунення теж не складно, дивимося на довжину сектора. Нагадаю сектор дорівнює 512 байтам.

Зверніть увагу на колонкиStart SectorіEnd Sector. Отже, останній пристрійnaa.60a98000486e574f6c4a5052537a7375має усунення 1MB (2048 сектора * 512 = 1048576 byte = 1024KB). А ось другий пристрій має зміщення яке не кратно 1MB, воно явно менше, UNMAP на ньому працювати не буде.

Перевірити чи підтримується UNMAP (Delete Status) можна так:

Автоматичне вивільнення простору у vSphere 6.5

Автоматичне вивільнення простору назад у тонкий місяць на СГД підтримується починаючи з vSphere 6.5. Для кожного VMFS-6 датастора можна призначати пріоритет вивільнення простору High/Mid/Slow, яке буде повернено сховищу протягом 12 годин. Запуск вивільнення простору та налаштування пріоритизації для VMFS-6 датастора можна також виконати вручну з графічного інтерфейсу або з командного рядка.

UNMAP із гостьової ОС.

Отже, раніше ми розглянули видалення віртуальних машин із датастора. Логічно було б зробити те саме при видаленні блоків даних зсередини гостьової ОС, а не повністю віртуальної машини або її дисків. UNMAP підтримується за СХД з ONTAP і у тому, щоб працював механізм UNMAP при видаленні даних із VMDK, тобто. зсередини гостьової ОС, з боку сховища додатково нічого реалізовувати не потрібно, достатньощоб UNMAP був увімкнений. Необхідно, щоб гіпервізор міг транслювати цю інформацію від віртуальної машини до сховища, що виконується повністю на рівні SCSI. Отже,починаючи з ESXi 6.0 тепер є можливість передавати інформацію про віддалені блоки всередині гостьової ОС.

Для роботи UNMAP зсередини віртуальної машини необхідно дотриматися таких умов і мати:

Virtual Hardware Version 11
VMFS6
vSphere 6.0*/6.5
Місяць СГД має бути тонким
віртуальні диски віртуалки мають бути тонкими
файлова система гостьової ОС має підтримувати UNMAP
для vSphere 6.0 CBT має бути вимкнений
увімкнути UNMAP на гіпервізорі, якщо необхідно:esxcli storage vmfs unmap -l myDatastore
включити UNMAP на СГД

Never Thin on Thin

Багато років усі вендори СГД говорили не створюйте тонкі віртуальні диски на тонких місяцях. Але тепер це змінилося і для того, щоб вивільняти блоки зсередини віртуальної машини необхідно мати тонкі віртуальні диски та тонкий місяць на СГД. У версії vSphere 6.0 був реалізований функціон повернення віддалених блоків зсередини гостьової ОС, але мав ряд обмежень при використанні UNMAP, наприклад, не підтримувалися Linux машини. У vSphere 6.0 і старіших версій з VMFS, функція UNMAP автоматично не запускається, потрібно запускати команду вручну.

Windows Guest OS support

Для того, щоб працювало вивільнення простору зсередини гостьової ОС Windows, файлова система NTFS має бути відформатована з розміром allocation unit рівним 64КБ.

Linux Guest OS SPC-4 support

Для цього запустіть команду

ПараметрUnmap command supported (LBPU)встановлений у значення 1означає, що використовується тонкий диск, що нам потрібно. А значення 0 означає, що тип віртуального диска thick (eager або sparse), з товстими дисками функція UNMAP працювати не буде.

Версія version=0x02 [SCSI-2] говорить про те, що UNMAP не працюватиме, нам необхідна версія SPC-4:

Для цього запустимо команду

значення 1 говорить про те, що гостьова ОС повідомляє SCSI рівень про віддалені блоки з файлової системи.

Перевіримо чи вивільняється простір за допомогою UNMAP:

Якщо ви отримуєте помилку«blkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation no supported»означає UNMAP не працює. Якщо помилки немає, то залишається примонтувати файлову систему з ключемdiscard:

Важливо пам'ятати, що гіпервізор VMware запускає UNMAPасинхронно, тобто із затримкою. Це означає, що на практиці ви швидше за все, ніколи не матимете зайнятий простір 1:1, усередині гостьової ОС/на датасторі гіпервізора та на місяці СГД.

Це суттєво покращує утилізацію корисного простору у SAN інфраструктурі, що використовує Thing Provisioning та Hardware-assistant снепшоти.

Windows (Bare Metal)

Підтримка команд UNMAP для цього сімейства операційної системи почалася з Windows Server 2012 з файловою системою NTFS. Для увімкнення автоматичного UNMAP використовуйте Windows Host Utility 6.0.2 або вище або ONTAP DSM 4.0 або вище. Для перевірки включення UNMAP виконайте fsutil behavior query disabledeletenotify . СтанDisableDeleteNotify = 0означає, що UNMAP повертає блоки на ходу (in-band). Якщо у хоста підключено кілька місяців з небагатьох СГД, частина яких не підтримує UNMAP, рекомендується вимкнути його.

Linux (Bare Metal)

Linux дистрибутиви підтримують UNMAP. NetApp офіційнопідтримує RHEL версії 6.2 і вище за допомогою ключа–o discardкомандиmountта утилітиfstrim. Докладніше в RHEL6 Storage Admin Guide.

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

Якщо ж ви потрапили в таку ситуацію, проконсультуйтеся з техпідтримкою, можливо, варто збільшити значенняwafl_zombie_ack_limitіwafl_zombie_msg_cnt. Якщо вам необхідно видалити всі дані на місяці, то краще видаліть на СГД весь місяць. All Flash системи, з іншого боку, набагато менш сприйнятливі до подібних запитів, і зазвичай досить швидко і без зусиль справляються з такими завданнями.

Видалення файлів у ONTAP 9 та пріоритизація

Нагадаю, що ONTAP 9 була випущена в травні 2016. У цій версії софту Zombie повідомлення більше не генаруються для вивільнення простору, натомість файл просто позначається для видалення. У зв'язку з чим логіка роботи вивільнення простору суттєво змінилася:

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

Реалізована підтримка UNMAP як на стороні гостьової ОС, хоста, так і на стороні сховищ NetApp,дозволяє більш раціонально утилізувати простір у SAN оточенні використовує Thin Provisioning і як наслідок дозволить раціональніше використовувати простір СХД з апаратними снепшотами. Підтримка UNMAP на рівні гіпервізора, і тим більше усередині гостьової ОС, суттєво полегшить використання цих двох потрібних технологій.

Хардкорна конфа за С++. Ми запрошуємо лише профі.