13 декабря 2016

NetApp ONTAP: UNMAP в SAN окружении

Виртуализация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 на СХД (если там остались ВМ в запущенном состоянии, они завершат работу некорректно и возможно будут повреждены, так что их стоит или временно выключить, или временно мигрировать):

lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state offline
lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -space-allocation enabled
lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state online

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

esxcli storage filesystem unmount -l myDatastore
esxcli storage filesystem mount -l myDatastore
esxcli storage vmfs unmap -l myDatastore

После этого, чтобы высвобождать пространство, нужно будет периодически запускать команду:

esxcli storage vmfs unmap -l myDatastore

Важно отметить, что UNMAP работает только для лунов отформатированных со смещением партиции кратное 1 MB. Что это значит? Это значит, что, если вы когда-то конвертировали VMFS3 в VMFS5, UNMAP работать не будет. Проверить это просто, конвертированные VMFS3 имеют таблицу разбивки MBR, а VMFS5 которые были созданы заново имеют разбивку GPT.

# esxcli storage core device partition showguid
Example output:

Device                                Partition  Layout  GUID
-------------------------------------------------------------
naa.60a98000486e574f6c4a5778594e7456          0  MBR     N/A
naa.60a98000486e574f6c4a5778594e7456          1  MBR     N/A
naa.60a98000486e574f6c4a5052537a7375          0  GPT     00000000000000000000000000000000
naa.60a98000486e574f6c4a5052537a7375          1  GPT     aa31e02a400f11db9590000c2911d1b8

Обратите внимение на колонку Layout.

Проверить смещение тоже не сложно, смотрим на длинну сектора. Напомню сектор равен 512 байтам.
# esxcli storage core device partition list
Example output:

Device                                Partition  Start Sector  End Sector  Type  Size
-------------------------------------------------------------------------------------
naa.60a98000486e574f6c4a5778594e7456          0             0  3221237760     0  1649273733120
naa.60a98000486e574f6c4a5778594e7456          1           128  3221225280    fb  1649267277824
naa.60a98000486e574f6c4a5052537a7375          0             0  3221237760     0  1649273733120
naa.60a98000486e574f6c4a5052537a7375          1          2048  3221237727    fb  1649272667648

Обратите внимание на колонки «Start Sector» и «End Sector». Итак, последнее устройство naa.60a98000486e574f6c4a5052537a7375 имеет смещение 1MB (2048 сектора*512 =1048576 byte = 1024KB). А вот второе устройство naa.60a98000486e574f6c4a5778594e7456 имеет смещение которое не кратно 1MB, оно явно меньше, UNMAP на нем работать не будет.

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

# esxcli storage core device vaai status get -d naa
Example output:

naa.60a98000486e574f6c4a5052537a7375
VAAI Plugin Name: VMW_VAAIP_NETAPP
ATS Status: supported
Clone Status: supported
Zero Status: supported
Delete Status: supported

Автоматическое высвобождение пространства в vSphere 6.5


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

esxcli storage vmfs reclaim config get -l DataStoreOnNetAppLUN
   Reclaim Granularity: 248670 Bytes
   Reclaim Priority: low

esxcli storage vmfs reclaim config set -l DataStoreOnNetAppLUN -p high



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

Виртуальные машины с Linux поддерживающие SPC-4 и работающие на vSphere 6.5 теперь также смогут возвращать высвобожденное пространство изнутри виртуальной машины назад в хранилище.
Как проверить поддерживает ли ваша линукс машина высвобождение пространства?

Проверка поддержки SPC-4 в виртуальной машине Linux
Для этого запустите команду
sg_vpd -p lbpv
Logical block provisioning VPD page (SBC):
  Unmap command supported (LBPU): 1
  Write same (16) with unmap bit supported (LBWS): 0
  Write same (10) with unmap bit supported (LBWS10): 0

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

sg_inq /dev/sdc -d
standard INQUIRY:
 PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
 [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
 EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
 [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
 length=36 (0x24) Peripheral device type: disk
 Vendor identification: VMware
 Product identification: Virtual disk
 Product revision level: 1.0

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

sg_inq -d /dev/sdb
standard INQUIRY:
 PQual=0 Device_type=0 RMB=0 version=0x06 [SPC-4]
 [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
 EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
 [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
 length=36 (0x24) Peripheral device type: disk
 Vendor identification: VMware
 Product identification: Virtual disk
 Product revision level: 2.0


Давайте проверим что UNMAP включён и работает:
Для этого запустим команду
grep . /sys/block/sdb/queue/discard_max_bytes
1

значение 1 говорит о том, что гостевая ОС уведомляет SCSI уровень об удалённых блоках с файловой системы.

Проверим высвобождается ли пространство при помощи UNMAP:
sg_unmap --lba=0 --num=2048 /dev/sdb
#или
blkdiscard --offset 0 --length=2048 /dev/sdb

Если вы получаете ошибку «blkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported» значит UNMAP не работает. Если же ошибки нет, то остаётся примонтировать файловую систему с ключём discard:
mount /dev/sdb /mnt/netapp_unmap -o discard


Важно помнить, что гипервизор VMware запускает UNMAP асинхронно, то есть с задержкой. Это означает, что на практике вы скорее всего, никогда не будете иметь занятое пространство 1:1, внутри гостевой ОС/на датасторе гипервизора и на луне СХД.

VVOL

Технология VVOL начиная с версии vSphere 6.0, VM Hardware версии 11 и Windows 2012 GOS с файловой системой NTFS поддерживает автоматическое высвобождение пространства внутрь тонкого луна на внешнем хранилище, на котором расположена данная виртуальная машина.

Linux GOS поддерживающие SPC-4 установленные на VM Hardware версии 11 на vSphere 6.5 также смогут возвращать пространство изнутри виртуальной машины на тонкий лун СХД.

Это существенно улучшает утилизацию полезного пространства в SAN инфраструктуре, использующей Thing Provisioning и Hardware-assistant снепшоты.

Подробнее о тюнинге ESXi 6.x для ONTAP.

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, рекомендуется выключить его.

Подробнее о тюнинге Windows Server для ONTAP.

Linux (Bare Metal)


Linux дистрибутивы поддерживают UNMAP. NetApp официально поддерживает RHEL версии 6.2 и выше при помощи ключа –o discard команды mount и утилиты fstrim. Подробнее в RHEL6 Storage Admin Guide.

Подробнее о тюнинге Linux Server для ONTAP.

Zombie


До версии ONTAP 9 операции удаления файлов генерировалии так называемые Zombie сообщения.
ONTAP 8 & Zombie сообщения
Высвобождение удалённых блоков позволяет с одной стороны существенно экономить дисковое пространство, но с другой стороны если хост запросит у СХД высвободить больше количество блоков, к примеру, терабайты данных, ваша СХД будет выполнять это и не успокоится пока не закончит, а это дополнительная активность на СХД. Высвобождение терабайта данных особенно будет заметно на дисковых или гибридных (не All Flash) системах. Поэтому стоит осторожно относиться к удалению большего количества данных одним махом на таких системах (терабайт).

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


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

Напомню что ONTAP 9 была выпущена в мае 2016. В этой версии софта Zombie сообщения больше не генарируются для высвобождения пространства, вместо этого файл просто помечается для удаления. В связи с чем логика работы высвобождения пространства существенно изменилась:
  • во-первых данные удаляются в фоне
  • во-вторых появилась возможность приоритизации высвобождения пространство из тех вольюмов, которым больше это нужно т.е те у которых заканчивается пространство.


Выводы


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

Сообщения по ошибкам в тексте прошу направлять в ЛС. Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Теги:SCSI3UNMAPSANFCPFCfibre channelfibre channel (fc)fibrechanneliscsivmwareSCSIT10netappnetapp FASFASData OntapcDOTClustered ONTAPClustered Data OntapCluster-Modethin provisioningthinprovisioningVMWare vSphereVMWare ESXiESXivSphere 5vsphere 5.5esxi 5ESXi 6vSphere 6vSpherevmware vsphere 5.5vmware vsphere 6SBC3SCSI-2Unmap command supportedLBPUSPC-4mountfsutilfstrimAll Flashspace reclaimationspace reclaimvmfs3vmfs6vmfs
Хабы: Виртуализация SAN
+12
5,8k 20
Комментарии 8
Лучшие публикации за сутки

Минуточку внимания

Разместить