NetApp ONTAP: T10 SCSI Block Command 3 и UNMAP в SAN окружении

Как я писал ранее, протоколы SAN и NAS по немногу заимствуют друг у друга всё лучшее. Одна из полезных вещей которая появилась достаточно давно, это возможность обратной связи СХД и хоста, для того чтобы «возвращать» удалённые блоки в тонкий лун, чего раньше так не хватало в SAN. Функцией UNMAP по-прежнему мало кто пользуется в SAN окружении, хотя она очень полезна в сочетании как с виртуализированными так и не виртуализированными средами.

Без поддержки комманды UNMAP любой тонкий лун созданный на стороне СХД всегда мог только увеличиваться в размере. Его рост был вопросом времени, который безоговорочно всегда заканчивался тем, что такой тонкий лун в конце концов станет занимать свой полный объём, который ему положенн, т.е. в конце концов он станет тольстым.


Вот представьте у вас на датасторе живут 3 виртуальные машины, каждая занимет 100GB. Ваш датастор находится на тонком луне, который занимает 300GB. Занимаемое пространство со стороны СХД и ESXi одинаковое: 300GB. После удаления одной ВМ, размер вашего луна со стороны СХД по-прежнему 300GB, а со стороны гипервизора занимаемое пространство на датасторе живущем на этом луне 200GB.

Связанно это с тем, что ране не было механизма обратной связи хоста с СХД. А именно, когда хост записывал блок информации в луне, СХД в свою очередь помечала этот блок как используемый. Далее хост мог удалить этот блок, но система хранения уже об этом не знала. Команда UNMAP и есть эта обратная связь, которая отмапливает уже не нужный блок с луна. Наконец-то наш тонкий лун научился не только набирать, но и уменьшать свой вес.

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 теперь также смогут возвращать высвобожденное пространство изнутри виртуальной машины назад в хранилище.
Как проверить поддерживает ли ваша линукс машина высвобождение пространства?

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

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

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

grep . /sys/block/sdb/queue/discard_max_bytes 1

sg_unmap --lba=0 --num=2048 /dev/sdb #или blkdiscard --offset 0 --length=2048 /dev/sdb

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.

Disclaimer

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

Выводы

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

Здесь могут содержаться ссылки на Habra-статьи, которые будут опубликованы позже.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
ссылка на оригинал статьи https://habrahabr.ru/post/271959/