Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).
Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.
Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.
Ключевые улучшения
Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
Новая спецификация vVols VASA 6
Кластеризация VMDK для NVMe/TCP
Ограничение максимального количества хостов, выполняющих Unmap
Поддержка NFS 4.1 Port Binding и nConnect
Дополнительная поддержка CNS/CSI для vSAN
vVols
Поддержка растянутого кластера хранилища vVols на SCSI
Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.
Почему это заняло так много времени?
Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.
Сценарии отказа и восстановления
Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.
Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.
Требования
Хранилище SCSI (FC или iSCSI)
Макс. время отклика между хостами vSphere — 11 мс
Макс. время отклика массива хранения — 11 мс
Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
Один vCenter (vCenter HA не поддерживается с vVols)
Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC
Дополнительная поддержка UNMAP
Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.
Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.
Возврат пространства в хранилищах виртуальных томов vSphere описан тут.
Кликните на картинку, чтобы посмотреть анимацию:
Поддержка кластеризации приложений на NVMe-oF vVols
В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.
Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.
Обновление отчетности по аутентификации хостов для VASA Provider
Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.
Гранулярность хостов Storage Provider для vVols
С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.
NVMe-oF
Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP
В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.
Поддержка NVMe Cross Namespace Copy
В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.
Кликните на картинку, чтобы посмотреть анимацию:
VMFS
Сокращение времени на расширение EZT дисков на VMFS
В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.
Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.
Кликните на картинку для просмотра анимации:
Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore
В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.
Кликните на картинку для просмотра анимации:
По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.
Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>
Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:
PSA
Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)
VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.
Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.
Кликните на картинку, чтобы посмотреть анимацию:
NFS
Привязка порта NFS v4.1 к vmk
Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.
Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.
При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:
Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.
Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:
esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>
Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.
В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).
Поддержка файловых томов в топологии HCI Mesh в одном vCenter
Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.
Поддержка CNS на TKGs на растянутом кластере vSAN
Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.
Миграция PV между несвязанными datastore в одном VC
Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.
Поддержка CNS на vSAN Max
Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.
На сайте проекта virten.net появилось отличное руководство о том, как правильно настроить USB-накопитель (обычную флэшку), подключенный к хосту VMware ESXi 8.0 в качестве датастора, откуда можно запускать виртуальные машины. Для производственной среды этого делать, само собой, не рекомендуется, а вот для тестирования различных возможностей хоста vSphere данная инструкция может оказаться очень полезной.
Итак:
Рекомендации по выбору USB-накопителя
Касательно форм-фактора или типа USB-накопителей нет никаких ограничений. Вы можете использовать маленькие флешки USB, большие жесткие диски USB 3.5" с высокой емкостью или внешние твердотельные накопители на базе USB. Из-за проблем с производительностью и надежностью, не рекомендуется использовать дешевые USB-флешки для хранилищ.
Предварительные условия
Некоторые команды требуют доступа по SSH к хосту ESXi, который можно включить из vSphere Client:
После этого вы можете зайти на хост ESXi по SSH с помощью любого клиента, например, PuTTY.
Шаг 1 - отключаем USB Passthrough
Дефолтное поведение хоста ESXi при присоединении USB-накопителя к хосту - дать возможность его проброса в виртуальную машину через механизм USB Passthrough. Поэтому нам нужно отключить этот механизм.
Есть 3 способа это сделать:
На базе устройства с помощью команды esxcli passthrough
На базе модели с использованием расширенных настроек USB quirks
Полностью отключить его для всех устройств, отключив сервис usbarbitrator
1 - Отключаем USB Passthrough на базе устройства
Этот способ основан на параметрах USB Bus и Vendor ID. Эта настройка сохраняется при перезагрузке, но учтите, что она может перестать работать в условиях, когда изменяются идентификаторы Bus ID или Device ID (например, вы воткнете флэшку в другой порт, либо будет присоединено другое устройство на время отсутствия флэшки в порту).
Итак, втыкаем USB-накопитель в хост ESXi и соединяемся с ним по SSH как root. Выводим список USB-устройств командой:
esxcli hardware usb passthrough device list
Для следующей команды вам потребуется записать параметры четырех выделенных колонок в формате Bus#:Dev#:vendorId:productId (например, 1:4:1058:1140).
Отключаем проброс для устройства:
esxcli hardware usb passthrough device disable -d 1:4:1058:1140
После этого перезагружать хост ESXi не требуется.
2 - Отключаем USB Passthrough, используя USB Quirks
Второй вариант отключает USB Passthrough для конкретной модели (сочетание идентификатора производителя и идентификатора продукта) с использованием расширенных настроек USB Quirks.
Вставьте USB-накопитель в ваш ESXi, подключитесь к хосту ESXi с использованием SSH и войдите под root. Далее просмотрите доступные USB-устройства. Первое число - это идентификатор производителя, второе число - идентификатор продукта:
lusb
Для установки USB Quirks нужно указать ID в следующем формате (см. скриншот выше): 0xDeviceID:0xVendorID (например, 0x1058:0x1140).
Отключите USB passthrough, используя следующую команду:
esxcli system settings advanced set -o /USB/quirks -s 0x1058:0x1140:0:0xffff:UQ_MSC_NO_UNCLAIM
Здесь уже нужно перезагрузить хост ESXi для применения изменений.
3 - Отключаем USB Arbitrator
Перед началом процедуры не втыкаем флэшку в сервер.
Заходим в клиент vSphere Client, идем в ESX > Configure > System > Advanced System Settings и нажимаем Edit... Далее найдем параметр USB.arbitratorAutoStartDisabled и установим его в значение 1:
После этого перезагружаем хост ESXi и уже после этого втыкаем флэшку в сервер.
То же самое можно сделать с помощью CLI-команды через SSH (после нее можно уже втыкать флэшку):
/etc/init.d/usbarbitrator stop
Также можно отключить USB Arbitrator следующей командой, которая будет применена после перезагрузки хоста:
# chkconfig usbarbitrator off
Шаг 2 - создаем VMFS Datastore на флэшке
После того, как вы отключили проброс USB, можно создавать датастор через vSphere Client, кликнув правой кнопкой на хосте ESXi и выбрав Actions > Storage > New Datastore... (в ESXi Host Client это делается в разделе Storage > New Datastore).
Если ваше устройство не отображается в мастере New Datastore, нужно сделать ресканирование хранилищ (опция Rescan Storage по правому клику) и убедиться, что устройство присутствует в списке.
Если и это не помогло, то можно попробовать создать датастор с помощью командной строки. Находим путь к устройству (Device Path в формате mpx.vmhba##). Для этого запускаем команду:
esxcli storage core device list |grep '^mpx' -A3
В выводе команды вы сможете идентифицировать устройство по его размеру:
Если у вас несколько устройств одного размера, то после подключения нужного вам устройства загляните в лог /var/log/vmkernel.log и посмотрите там наличие вот такой записи:
vmkernel: Successfully registered device "mpx.vmhba34:C0:T0:L0" from plugin "NMP" of type 0
Это и есть ваша флэшка. Теперь создаем переменную с этим устройством:
DISK="/vmfs/devices/disks/mpx.vmhba34:C0:T0:L0"
После этого создаем метку для данного устройства:
partedUtil mklabel ${DISK} gpt
Теперь с помощью утилиты partedUtil создадим раздел с идентификатором GUID=AA31E02A400F11DB9590000C2911D1B8:
После этого ваш том, созданный на флэшке, появится в списке датасторов хоста.
Для бесплатного резервного копирования виртуальных машин можно использовать скрипт ghettoVCB.
Если вы заметите, что скорость копирования на/с датастора с помощью команд cp, mv или scp очень медленная, то вы можете использовать механизм Storage vMotion или утилиту vmkfstool для копирования данных.
Например, вот так можно склонировать VMDK-диск:
vmkfstools -i <src>.vmdk <dst>.vmdk
Известные проблемы
Когда вы пытаетесь определить диск, дважды проверьте, что вы не перепутали свои накопители. Имя, отображаемое в пользовательском интерфейсе, не меняется, когда меняется идентификатор. Вот пример, где выделенный диск был перенесен на виртуальный адаптер mpx.vmhba33 как новое устройство. Отображаемое имя при этом остается старым - mpx.vmhba32.
Существующие датасторы не монтируются автоматически! То есть, если на вашей флэшке уже есть тома VMFS, то они не будут видны при ее подключении. В этом случае датастор будет offline, а в логе vmkernel.log вы увидите вот такое сообщение:
cpu0:65593)LVM: 11136: Device mpx.vmhba34:C0:T0:L0:1 detected to be a snapshot:
То есть датастор определяется как снапшот. Список снапшотов вы можете вывести командой:
# esxcli storage vmfs snapshot list 583b1a72-ade01532-55f6-f44d30649051 Volume Name: usbflash VMFS UUID: 583b1a72-ade01532-55f6-f44d30649051 Can mount: true Reason for un-mountability: Can resignature: true Reason for non-resignaturability: Unresolved Extent Count: 1
В этом случае вы можете смонтировать датастор следующей командой, используя VMFS UUID:
# esxcli storage vmfs snapshot mount -u 583b1a72-ade01532-55f6-f44d30649051
Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.
Причина такого поведения может заключаться не только в отсутствии свободных нод. Для начала надо проверить, что проблема действительно не в них. Делается это с помощью команды:
stat -f /
Либо можно использовать также команду df -i.
Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.
Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:
1.Поддержка NVMe over TCP
В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.
2. Увеличение числа хостов на один датастор
У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.
3. Affinity 3.0 и поддержка CNS
В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.
4. Пакетные снапшоты томов vVols
В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.
Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.
Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...
Таги: VMware, Clustering, Backup, HA, FT, VMachines, Storage, VMDK, VMFS
Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.
Итак, для начала выводим список доступных USB-интерфейсов на сервере:
esxcli hardware usb passthrough device list
У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):
Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:
esxcli hardware usb passthrough device disable -d 2:7:90c:1000
После этого будет вот такая картина:
Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.
Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:
esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1
Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:
vdq -q
Затем создаем переменную с именем устройства, например:
Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1
После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:
Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.
Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.
Давайте посмотрим, что именно там нового:
1. Увеличение iSCSI Path Limit
Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.
2. Поддержка RDM для RHEL HA
Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.
3. Улучшения снапшотов VMFS SESparse
При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.
4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)
В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.
5. Улучшения производительности для томов VMFS
Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.
6. Улучшения работы с NFS-хранилищами
Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.
7. Поддержка High Performance Plugin FastPath для Fabric Devices
Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.
8. HPP - дефолтный плагин для vSAN
Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).
9. Улучшения VOMA
Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.
10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints
В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.
11. Создание Config vVol больше, чем на 4 ГБ
Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.
12. Улучшения правил SPBM Multiple Snapshot
Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.
13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks
Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.
14. Маппинг CNS PV на vVol
В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.
На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.
Политики SPBM разделяются на 3 основных области:
Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.
В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.
Поддержка правил на базе тэгов определяется при создании политики:
С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:
Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.
Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:
В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.
Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).
После создания тэга его нужно добавить к соответствующим датасторам и создать политику, которая использует соответствующие тэги. Это позволит определить размещение виртуальных машин при их создании, миграции или клонированию.
Весь этот процесс показан на видео ниже:
Еще одно преимущество такой механики заключается в том, что вы можете изменить хранилище, которое располагается под политикой, без изменения самой политики. То есть вы добавляете тэг какому-нибудь хранилищу, и оно автоматически попадает в политику с этим тэгом для размещения ВМ. Политику также можно ассоциировать с кластерами хранилищ (datastore clusters), что добавляет еще гибкости этому механизму.
Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.
Вот как это работает при создании политики:
С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:
Get-VM -Tag Windows
Name PowerState Num CPUs MemoryGB
---- ------- -------- --------
Windows-VMFS-VM PoweredOff 1 4.000
Win10-3 PoweredOn 2 4.000
jm-ws2016 PoweredOn 2 4.000
Win10-2 PoweredOn 2 4.000
И для хранилища:
Get-Datastore -Tag California
Name FreeSpaceGB CapacityGB
---- --------- ----------
N-VVol-Cali 2,048.000 2,048.000
При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.
Напомним, что VMFS-6 впервые появилась в VMware vSphere 6.5 и с тех пор сильно не изменялась, но если посмотреть на отличия шестой версии от пятой, то они весьма существенные:
Как мы видим, основных отличий четыре:
Доступ к хостам ESXi 6.0 и более ранних к VMFS-6 уже невозможен.
Последний пункт как раз и стал причиной того, что произошло изменение в структуре метаданных томов, а значит VMFS-5 нельзя проапгрейдить до VMFS-6. Альтернативой является создание нового датастора VMFS-6, перемещение туда всех виртуальных машин и удаление старого.
Создаем новый VMFS-6:
Перемещаем туда все виртуальные машины тома VMFS-5 через Storage vMotion или Cold migration и удаляем его:
Как стало понятно, для такого "апгрейда" датастора VMFS-5 вам потребуется еще столько же места на другом датасторе или готовом к форматированию под VMFS-6 хранилище, чтобы переместить туда виртуальные машины.
Чтобы посмотреть текущие версии VMFS с помощью PowerCLI, нужно выполнить команду:
Get-Datastore | Select Name, FileSystemVersion | Sort Name
Перед началом процесса апгрейда нужно ознакомиться со статьей KB "Migrating VMFS 5 datastore to VMFS 6 datastore". Для миграции надо использовать командлет Update-VmfsDatastore, который также делает некоторые проверки перед миграцией.
При этом надо учитывать несколько моментов:
На время миграции нужен датастор VMFS-5 такой же или большей свободной емкости.
Машины перемещаются средствами Storage vMotion на временное хранилище.
Командлет убеждается, что на датасторе не осталось ВМ, миграция которых не поддерживается (это машины с поддержкой SRM, VADP, VRM и Clustering).
Командлет временно отключает механизм Storage DRS при своей работе (и включает по окончании). Если сценарий во время исполнения упадет, то вам придется включать Storage DRS вручную.
Нужно внимательно изучить использование параметров Resume и Rollback в случае появления ошибок.
Посмотрим, какие последовательные действия делает сценарий:
Проверяет наличие ВМ с поддержкой VADP, SMPFT, MSCS/RAC на исходном датасторе.
Убеждается, что датастор доступен со всех хостов.
Валидирует, что временный датастор имеет достаточно емкости для размещения виртуальных машин.
Устанавливает функцию Storage DRS Automation в режим manual.
Размонтирует исходный датастор.
Удаляет старый датастор и создает на его месте новый датастор VMFS-6.
Перемещает ВМ и другие данные со временного датастора на новый.
Восстанавливает настройку Storage DRS Automation.
Теперь, собственно, как использовать командлет Update-VmfsDatastore:
Если у вас что-то пошло не так, вы сможете использовать параметр rollback для отката, а также если возникают ошибки, то после их исправления можно использовать параметр resume.
Больше об использовании командлета Update-VmfsDatastore написано вот тут.
Недавно мы рассматривали некоторые аспекты резервного копирования на томах VVols в среде VMware vSphere. Одна из важных составляющих этого процесса - снапшоты (snapshots). Мы упоминали, что ввиду архитектуры VVols в плане снапшотов, снимки на уровне дисковых массивов на томах VVols работают быстрее при откате к снапшоту и консолидации (удалении всех снапшотов диска VMDK).
Сегодня мы попробуем разобраться, как это работает, и почему снапшоты в инфраструктуре VVols - это уже не так плохо, как раньше.
Снапшоты на томах VMFS
Сначала посмотрим на традиционную архитектуру снапшотов виртуальных машин на томах VMFS. Когда для машины делается снапшот, создается VMDK-файл, представляющий собой redo log (назовем его лог наката). В этот момент основной диск ВМ переводится в режим только для чтения (read only), а все новые операции записи (writes) идут в новый VMDK (дельта диск), который становится активным диском в плане новых операций чтения-записи для новых блоков, а старые блоки читаются из старого базового VMDK.
Если же мы хотим удалить один из снапшотов, мы должны склеить (накатить - redo) все сделанные операции записи новых блоков из логов наката к предыдущим точкам во времени. Например, если у вас есть базовая точка PIT1 (основной VMDK-диск), а также снапшоты PIT2 и PIT3, то чтобы удалить, например, снапшот PIT2 вам надо повторить (накатить) все операции его redo log на основном VMKD (PIT1), чтобы получить стабильную итоговую цепочку PIT1-PIT3 (без PIT2). Это довольно трудозатратная операция.
Если вы хотите откатиться к одному из снапшотов (revert), например, к исходному состоянию PIT1, то работает это очень просто - следующие снапшоты в цепочке просто отбрасываются (удаляются их VMDK):
Если же вы хотите удалить все снапшоты (консолидировать диск ВМ - операция consolidate), то процедура будет очень накладной. Об этой процедуре мы детально писали вот тут. Сначала PIT2 склеивается с PIT3, а потом уже получившийся диск склеивается с PIT1.
Таким образом, операция консолидации снапшота, который обязательно создается при резервном копировании, может занять длительное время.
Снапшоты для томов VVols
Давайте теперь посмотрим, как снапшоты работают в среде VVols. Здесь базовый диск находится в режиме чтения-записи всегда и всегда хранит в себе самое актуальное состояние. При создании снапшота диска VMDK происходит создание файла VMDK, который хранит в себе отличия (трекаются изменившиеся блоки), происходившие с какого-то момента времени (можно сказать, что это undo log). При этом основной контекст чтения-записи остается на основном VMDK.
В такой схеме операция revert будет происходит довольно долго по сравнению с таковой на VMFS - надо будет откатить изменения PIT3 в базовом диске, а потом изменения PIT2 (если мы идем к состоянию PIT1), но надо помнить, что откатываться к снапшоту приходиться не так уж и часто.
А вот операция консолидации (удаление всех снапшотов) - очень частая при резервном копировании. И вот тут для такой архитектуры работает это все моментально - мы просто откидываем ненужные объекты undo log, оставляя только базовый диск, который содержит в себе самое актуальное состояние на данный момент:
При необходимости вернуться к какому-то из снапшотов в среде VVols надо будет в базовом диске откатить все те изменения блоков (undo), которые зафиксированы в VMDK-диске снапшота, отслеживаемые с нужного момента времени (например, PIT1):
Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.
Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:
Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.
Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.
Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:
А далее привязываем эту политику к диску VMDK в настройках ВМ:
Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.
Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.
Ну и в заключение несколько аспектов данного рода ограничений:
Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.
Как некоторые знают, в VMware vSphere 6.5 появилась (а точнее вернулась снова) возможность Automatic VMFS UNMAP - возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически. Работает UNMAP только для "тонких" (Thin Provisioned) LUN, на которых размещаются тома VMFS.
Из GUI vSphere Web Client можно управлять только UNMAP'ом для томов VMFS 6, для пятой версии файловой системы это нужно делать вручную с помощью ESXCLI. Кроме того, механизм UNMAP работает в асинхронном режиме, а иногда хочется почистить хранилища от неиспользуемых блоков прямо сейчас.
Поэтому весьма кстати, что на сайте EnterpriseDaddy обнаружился полезный PowerCLI-скрипт, который возвращает дисковое пространство в LUN для заданного хранилища хоста ESXi.
Эта функция принимает на вход имя хоста ESXi и Datastore, а также отключает таймаут на исполнение операций, так как возврат дискового пространства LUN может занять часы.
Function Perform-VMFSUnmap {
[CmdletBinding()]
param(
[Parameter(
Mandatory=$true)]
[String[]]$Datastore,
[String]$ESXiHost
)
Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope Session -Confirm:$false
$ESXHost = Get-VMHost $ESXiHost
$DatastoreName = Get-Datastore $Datastore
Write-Host 'Using ESXCLI and connecting to $VMHost' -ForegroundColor Green
$esxcli = Get-EsxCli -VMHost $ESXHost
Write-Host 'Unmapping $Datastore on $VMHost' -ForegroundColor Green
$esxcli.storage.vmfs.unmap($null,$DatastoreName,$null)
}
Недавно компания VMware выпустила новую версию платформы vSphere 6.5, о новых возможностях которой мы писали вот тут. Между тем, в плане хранилищ было сделано несколько важных улучшений, которые заслуживают отдельного поста. Большинство из этого реализуемо только на базе файловой системы VMFS 6.0, которая также появилась в vSphere 6.5.
1. Возврат дискового пространства хранилищу (Storage UNMAP).
Эта возможность была еще в VMware ESXi 5.0, но пропала по некоторым техническим причинам в следующих версиях. Теперь она полноценно была реализована в двух вариантах:
Automatic UNMAP
Поддержка Linux-based In-Guest UNMAP
Automatic UNMAP - это возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически.
Для работы этой возможности вам понадобятся:
ESXi 6.5+
vCenter 6.5+
VMFS 6
Дисковый массив с поддержкой UNMAP
Если мы в настройках хранилища откроем вкладку Configure:
И далее нажмем Edit в разделе Space Reclamation Priority, то мы увидим вот такую настройку:
Здесь устанавливается приоритет, в соответствии с которым свободные блоки будут автоматически возвращены к LUN. Надо понимать, что UNMAP - это асинхронный процесс, который выполняет специальный crawler, потому и задается его приоритет. Понятное дело, что если задать высокий приоритет, то создастся дополнительная нагрузка на хранилища.
Кстати, для немедленного возврата дискового пространства можно воспользоваться командой esxcli storage vmfs unmap.
Поддержка Linux-based In-Guest UNMAP в vSphere 6.5 появилась впервые. Для ее работы нужна поддержка со стороны гостевой ОС Linux и ее файловой системы. Ну и работает это все только для тонких (thin) дисков.
Работает она не полностью автоматически, а запустить ее можно тремя способами:
Смонтировать файловую систему с опцией discard. Это будет возвращать простраство автоматически, когда будут удаляться файлы.
Выполнение команды sg_unmap. Это запустит механизм UNMAP для выбранных LBA.
Выполнение fstrim. Это вызовет команды trim, которые ESXi конвертирует в операции механизма UNMAP на уровне слоя vSCSI.
2. Функция Thin Hot Extend.
Это очень полезная штука была несколько ранее - она позволяла на горячую увеличить размер тонкого диска.
Вся загвоздка была в том, что диск можно было увеличить только до 2 ТБ, иначе возникала вот такая ошибка:
Теперь же можно задавать виртуальный диск любого размера.
3. Поддержка 4K-дисков в режиме 512e.
Теперь расширенный формат дисковых устройств 4K поддерживается со стороны vSphere 6.5, однако в режиме эмуляции 512e (то есть для 4к-девайсов эмулируются 512-байтные сектора). Такая же поддержка есть и в VMware Virtual SAN 6.5.
Полная поддержка 4k-устройств в нативном режиме ожидается в ближайшем будущем.
4. Поддержка до 512 устройств и 2000 путей.
Ранее платформа vSphere поддерживала 256 устройств и 1024 пути к одному хранилищу. И некоторые умудрялись упираться в лимиты, поэтому для таких клиентов и было сделано увеличение максимумов.
5. Увеличение лимита CBRC (он же View Storage Accelerator).
Про механизм кэширования Content Based Read Cache (CBRC) мы писали вот тут. Он позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК за счет кэширования в оперативной памяти хоста VMware ESXi.
Ранее он был ограничен объемом в 2 ГБ, а теперь увеличился до 32 ГБ:
Теперь в vSphere 6.5 есть механизм для переподписки так называемых unresolved volumes, то есть томов, которые отвязались от основного по каким-то причинам, и теперь их метаданные являются не соответствующими текущей структуре файловой системы. Так, например, бывает в процессе резервного копирования, когда остается какой-нибудь повисший на диске снапшот, который не видно из GUI клиента vSphere.
В этом плане была проделана существенная работа и сделано множество улучшений, о которых можно прочитать тут.
Это основные, но не все улучшения VMware vSphere 6.5 в плане хранилищ, а если хочется узнать обо всех, то почитайте документ "vSphere 6.5 Storage", где очень много всего интересного.
Как-то один из наших читателей спросил, как можно узнать, какие из хостов VMware ESXi в кластере используют данное виртуальное хранилище (датастор)? Ведь использовать они его могут не только для хранения виртуальных машин, исполняемых на нем, но и для хартбитов - то есть сигналов доступности VMware HA, передаваемых через лок-файлы на этих датасторах.
Для этой цели можно использовать утилиту vSphere On-disk Metadata Analyzer (VOMA), которая умеет проверять консистентность метаданных тома VMFS, а также покажет вам информацию о том, какие хосты ESXi его используют.
Для начала нужно узнать имя датастора в формате определения устройства. Посмотрим список имен устройств через esxcli:
esxcli storage vmfs extent list
Мы увидим вот такую картину:
В колонке Device name мы видим имя устройства - eui.5adcee56739fb3ea:1. Теперь с помощью VOMA проведем проверку этого девайса и выведем метаданные этого тома VMFS:
Если том не в порядке, то будет выведено вот такое сообщение:
Error: Missing LVM Magic. Disk doesn’t have a valid LVM Device Error: Failed to Initialize LVM Metadata
Ну а если все окей, то вот что мы получим:
Тут мы видим, что устройство (том VMFS/датастор) используется одним хостом с соответствующим MAC-адресом. Дальше уже дело техники найти этот хост ESXi.
Если вы хотите вывести результаты работы данной команды VOMA в файл, то можно использовать ключ -s:
На днях мы писали о том, что компания VMware выпустила релизную версию своей минимальной операционной системы Photon OS 1.0, которая предназначена для исполнения виртуальных контейнеров Docker. Многие сразу задумались о том, как дело обстоит с работой контейнеров с хранилищами своих данных.
Как раз в этой связи компания VMware выпустила технологическое превью драйвера vSphere Docker Volume Driver, позволяющего напрямую работать с виртуальными хранилищами прямо из контейнеров Docker (версии 1.9 или выше).
Архитектура решения выглядит так:
Как видно из картинки, нам потребуется установить Volume Driver на серверы VMware ESXi, а также плагины vSphere Docker Volume Plugin на виртуальные машины Docker Host, где будут исполняться наши контейнеры. Также мы видим, что в качестве хранилищ поддерживаются практически все, что поддерживает платформа vSphere: тома VMFS (локальные и общие), NFS-хранилища, а также тома Virtual SAN (и соответственно их политики по обеспечению избыточности данных в целях отказоустойчивости).
Рассмотрим развертывание решения vSphere Docker Volume Driver по шагам.
1. На серверы VMware ESXi 6.0 или выше устанавливается компонент vSphere Data Volume Driver в виде обычного VIB-пакета.
4. Устанавливаем VMDK Plugin (Docker Volume Plugin) на хост ESXi.
Проверяем версию Docker:
root@photon-machine [ ~ ]# docker version
Client:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 19:36:04 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 19:36:04 2016
OS/Arch: linux/amd64
root@photon-machine [ ~ ]#
Install the RPM (I’ve used “-U” out of habit, but “-i” can also be used):
Устанавливаем RPM-пакет с плагином в гостевую ОС:
root@photon-machine [ ~ ]# ls
docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm
root@photon-machine [ ~ ]# rpm -Uvh docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:docker-volume-vsphere-0:0.1.0.tp-################################# [100%]
File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'
Created symlink from /etc/systemd/system/multi-user.target.wants/\
docker-volume-vsphere.service to /usr/lib/systemd/system/docker-volume-vsphere.service.
5. Проверяем статус плагина:
root@photon-machine [ ~ ]# systemctl status docker-volume-vsphere
* docker-volume-vsphere.service - "Docker Volume Driver for vSphere"
Loaded: loaded (/usr/lib/systemd/system/docker-volume-vsphere.service;\
enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-05-30 09:04:21 UTC; 28s ago
Main PID: 256 (docker-volume-v)
CGroup: /system.slice/docker-volume-vsphere.service
`-256 /usr/local/bin/docker-volume-vsphere
May 30 09:04:21 photon-machine systemd[1]: Started "Docker Volume Driver\
for....
Hint: Some lines were ellipsized, use -l to show in full.
root@photon-machine [ ~ ]#
Зачастую в тестовом окружении вам нужно создать несколько томов VMFS (например, для тестирования технологии Storage DRS и создания кластера хранилищ), но диск на машине только один. В этом случае можно вручную нарезать этот диск на разделы и отформатировать их в тома VMFS 5, которые будут использоваться в качестве виртуальных хранилищ.
Для этих целей можно использовать 2 утилиты, входящие в состав VMware ESXi 6 - PartedUtil и vmkfstools. Помните, что метод, изложенный ниже, не поддерживается для производственных систем. Используйте его только в тестовом окружении!
Итак, заходим на хост ESXi, напрямую или по SSH. Сначала нужно найти имя устройства. Для этого можно воспользоваться командой:
fdisk –l
Либо для подробной информации можно взять следующую:
esxcli storage core path list
В качастве вывода мы получим что-то вроде этого:
sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
UID: sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
Runtime Name: vmhba34:C0:T0:L0
Device: t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
Device Display Name: Local ATA Disk (t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288)
Adapter: vmhba34
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: sata
Adapter Identifier: sata.vmhba34
Target Identifier: sata.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 33553920
Можно сделать это и из vSphere Client:
Далее получаем таблицу разделов следующей командой (имя диска берем из поля Device):
Диск этот пуст, и мы получим примерно такой вывод:
msdos
29185 255 63 468862128
Например, вы хотите создать на этом диске 5 разделов (LUN) по 10 ГБ каждый. При размере сектора 512 байт, размер каждого такого диска будет 20971519 секторов. При этом первые 2048 секторов диска надо пропустить, чтобы оставить место под GPT-таблицу и выровнять разделы по лучшим практикам (под 512-байтные секторы).
Получаем следующий план разбиения разделов с номерами начальных и конечных секторов:
Аналогичные действия нужно будет проделать и с оставшимися четырьмя датасторами, после чего они станут видны в клиенте vSphere. Более подробно о процедуре изложено в KB 1009829.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.
Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.
Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.
К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.
Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:
Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.
Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.
Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.
Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!
Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:
В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).
Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.
Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:
Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:
Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:
Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.
Как вы знаете, автор этого сайта придерживается правила "лучше переставлять, чем обновлять" (когда речь идет о мажорных версиях продукта - см., например, вот тут и тут).
В VMware vSphere 5.0 компания VMware обновила свою кластерную файловую систему до версии VMFS 5. При этом в vSphere 5.x тома VMFS-3 поддерживаются, а также доступен апгрейд с третьей версии на пятую (напомним, что в пятой версии появилась поддержка дисков в 64 ТБ). Более подробная информация об апгрейде VMFS приведена в документе "VMware vSphere VMFS-5 Upgrade Considerations".
Так вот, апгрейженный том VMFS-5 имеет ограниченную функциональность в отличие от созданного заново тома, а именно:
Апгрейженный том продолжает использовать исходный размер блока (в новой версии VMFS 5.x размер блока унифицирован - 1 МБ). Это иногда может привести к чрезмерному потреблению места на диске (если много мелких файлов), но что самое неприятное - к падению производительности Storage vMotion.
Апгрейженный том не имеет таких возможностей как Sub-Block Size, увеличенное число файлов на хранилище и разметка GPT.
Обновленный том VMFS-5 продолжает иметь раздел, начинающийся с сектора 128, это может вызвать некоторые проблемы с выравниванием блоков. Новый раздел VMFS 5 начинается с сектора 2048.
Таким образом, получается, что лучше создать новый том VMFS-5, чем обновлять существующие тома VMFS-3. Но это все было давно, ну а вдруг у вас остались такие вот обновленные VMFS, из-за которых у вас иногда что-то работает не так?
Проверить, какой у вас том, можно в vSphere Client или vSphere Web Client. Смотрим размер блока:
Если он не 1 МБ - то это точно апгрейженный том, и его неплохо бы пересоздать. А вот если 1 МБ, то вовсе не факт, что это новый том (как раньше, так и сейчас был такой размер блока). В этом случае вам поможет вот этот скрипт, который выводит список всех томов VMFS и показывает, новый это том или апгрейженный.
Запустить этот скрипт можно таким образом:
1. Загружаем его и переименовываем его в check_vmfs.sh, убрав расширение .doc.
2. Копируем скрипт на виртуальный модуль vMA. Можно также запускать скрипт локально на сервере ESXi - для этого его туда надо загрузить через Veeam FastSCP или WinSCP.
3. Включаем демон SSH на хостах ESXi, где вы будете выполнять скрипт. (в vSphere Client нужно зайти в Configuration \ Software \ Security profile \ Services \ SSH).
4. Удаленно выполнить скрипт на серверах через SSH можно с помощью команды:
ssh root@<ESXi IP> 'ash -s' < ./check_vmfs.sh
Далее попросят пароль и будет выведен результат работы скрипта.
Здесь нужно смотреть на значение Sub Blocks, если Sub Blocks = 3968, то это апгрейженный VMFS-5, и его неплохо бы пересоздать. У нормального VMFS-5 значение Sub Blocks равно 32000.
Такое вот работающее правило "лучше переставлять, чем обновлять". Любители PowerShell могут также посмотреть вот эту статью.
Как многие из вас знают, в платформе виртуализации VMware vSphere есть множество удобных средств работы с хранилищами, включая средства позволяющие расширить том VMFS прямо из GUI клиента vSphere Client - достаточно лишь сделать Rescan HBA-адаптеров. Однако если необходимо расширить локальный том (Local VMFS), то тут встроенных средств уже нет, и все нужно аккуратно делать самому, как это описано в KB 2002461. Приведем здесь этот процесс, проиллюстрировав его скриншотами.
Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.
Эта статья приведена здесь на случай, если у вас появится необходимость подключить том VMFS к Windows-системе в режиме Read Only, чтобы скопировать его виртуальные машины, а далее заглянуть в содержимое их файлов виртуальных дисков (VMDK). Это может потребоваться в различных ситуациях (например, вы - злодей) и возможно средствами драйвера Open Source VMFS Driver от fluid Ops.
Если вы попробуете импортировать виртуальную машину (или Virtual Appliance), которая была создана для настольных платформ виртуализации (например, VMware Workstation в формате 2gbsparse), в VMware vSphere 5.1 с помощью утилиты vmkfstools, то у вас это не выйдет. Вы получите подобное сообщение:
Failed to open 'VM-name.vmdk': The system cannot find the file specified (25).
Ошибка может быть и такой:
File [VMFS volume]\VM-name.vmdk was not found.
И такой:
Error Stack:
An error was received from the ESX host while powering on VM VM-name
Cannot open the disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk' or one of the snapshot disks it depends on.
The system cannot find the file specified.
VMware ESX cannot find the virtual disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk'. Verify the path is valid and try again.
Все это из-за одного и того же - в VMware vSphere 5.1 убрали автоматическую загрузку модуля multiextent, который и отвечает как раз за конверсию виртуальных дисков с hosted-платформ VMware в формат VMFS. Чтобы загрузить этот модуль нужно выполнить простую команду:
# vmkload_mod multiextent
Ну а чтобы выгрузить:
# vmkload_mod -u multiextent
Делать это можно смело, так как этот модуль отвечает только за работу с Non-VMFS дисками ВМ.
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
Некоторые из вас, вероятно, видели документ, называющийся "VMFS File Locking and Its Impact in VMware View 5.1", доступный у нас вот тут. Он вкратце рассказывает о нововведении в VMware View 5.1 - теперь для пулов связанных клонов (Linked Clones) можно использовать кластеры до 32-х хостов, а не 8 как раньше. Но работает это только для тех окружений, где реплика базового образа размещена на NFS-хранилище, для VMFS же хранилищ ограничение осталось тем же самым - кластер из максимум 8 хостов. Давайте разбираться, почему это так.
Во-первых, посмотрим как выглядит классическая структура связанных клонов в инсталляции VMware View:
В пуле связанных клонов, который мы можем построить с помощью VMware View Composer, находится создаваемый и настраиваемый базовый образ (может быть со снапшотом), из которого создается реплика этой ВМ (Replica), на базе которой из дельта-дисков строятся уже конечные десктопы пользователей. При этом данные реплики используются одновременно всеми связанными клонами, которые располагаются на хост-серверах ESXi кластера.
Теперь напомним, что мы уже рассматривали типы блокировок (локов) в кластерной файловой системе VMFS. Однако там рассмотрены не все блокировки, которые могут быть применены к файлам виртуальных дисков. Мы рассматривали только эксклюзивную блокировку (Exclusive Lock), когда только один хост может изменять VMDK-файл, а все остальные хосты не могут даже читать его:
Такие блокировки используются в традиционном окружении инфраструктуры виртуализации для серверной нагрузки в виртуальных машинах. Очевидно, что такие блокировки не подходят для доступа к данным файла виртуального диска реплики VMware View.
Поэтому есть и другие типы блокировок. Во-первых, Read-Only Lock (в этом режиме все хосты могут читать один VMDK, но не могут менять его):
Во-вторых, Multi-Writer Lock:
В режиме такой блокировки сразу несколько хостов могут получить доступ к VMDK-файлу на общем хранилище VMFS в режиме Read/Write. При использовании инфраструктуры связанных клонов на хранилище применяются локи типа Read-Only Lock и Multi-Writer Lock, что требует одновременного доступа нескольких хостов ESXi к одному файлу. Естественно, где-то в локе должны храниться данные о том, какие хосты используют его.
А теперь посмотрим на внутренности лока. Они как раз и содержат все UID (User ID) хостов, которые работают с VMDK-файлом, в структуре "lock holders". Надо отметить, что для работы автоматической процедуры обновления лока необходимо, чтобы его размер был равен одному сектору или 512 байтам. А в этот объем помещается только 8 этих самых UID'ов, а девятый уже не влезает:
Напомню, что мы говорим про диск реплики, который необходим сразу всем хостам кластера с виртуальными ПК этого пула. Поэтому, как и раньше, в VMware View 5.1 нельзя использовать для реплики, размещенной на томе VMFS, кластер из более чем восьми хост-серверов VMware ESXi.
Однако можно поместить реплику на том NFS. По умолчанию протокол NFS не поддерживает file locking, однако поддерживает механизм Network Lock Manager
(NLM), который использует схему блокировок "advisory locking":
В этой схеме клиенты файла NFS могут координировать между собой совместный доступ к файлу (в нашем случае - VMDK). При этом никакого лимита на 8 хостов в этом механизме нет. Однако раньше в VMware View не позволялось использовать более 8 хостов в кластере для пула связанных клонов.
Теперь это сделать можно и, во многих случаях, даже нужно, выбрав NFS-хранилище для пула Linked Clone:
Мы уже не раз затрагивали тему 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-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 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-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
Мы уже некоторое время назад писали про различные особенности томов VMFS, где вскользь касалисьпроблемы блокировок в этой кластерной файловой системе. Как известно, в платформе VMware vSphere 5 реализована файловая система VMFS 5, которая от версии к версии приобретает новые возможности.
При этом в VMFS есть несколько видов блокировок, которые мы рассмотрим ниже. Блокировки на томах VMFS можно условно разделить на 2 типа:
Блокировки файлов виртуальных машин
Блокировки тома
Блокировки файлов виртуальных машин
Эти блокировки необходимы для того, чтобы файлами виртуальной машины мог в эксклюзивном режиме пользоваться только один хост VMware ESXi, который их исполняет, а остальные хосты могли запускать их только тогда, когда этот хост вышел из строя. Назвается этот механизм Distributed Lock Handling.
Блокировки важны, во-первых, чтобы одну виртуальную машину нельзя было запустить одновременно с двух хостов, а, во-вторых, для их обработки механизмом VMware HA при отказе хоста. Для этого на томе VMFS существует так называемый Heartbeat-регион, который хранит в себе информацию о полученных хостами блокировок для файлов виртуальных машин.
Обработка лока на файлы ВМ происходит следующим образом:
Хосты VMware ESXi монтируют к себе том VMFS.
Хосты помещают свои ID в специальный heartbeat-регион на томе VMFS.
ESXi-хост А создает VMFS lock в heartbeat-регионе тома для виртуального диска VMDK, о чем делается соответствующая запись для соответствующего ID ESXi.
Временная метка лока (timestamp) обновляется этим хостом каждые 3 секунды.
Если какой-нибудь другой хост ESXi хочет обратиться к VMDK-диску, он проверяет наличие блокировки для него в heartbeat-регионе. Если в течение 15 секунд (~5 проверок) ESXi-хост А не обновил timestamp - хосты считают, что хост А более недоступен и блокировка считается неактуальной. Если же блокировка еще актуальна - другие хосты снимать ее не будут.
Если произошел сбой ESXi-хоста А, механизм VMware HA решает, какой хост будет восстанавливать данную виртуальную машину, и выбирает хост Б.
Далее все остальные хосты ESXi виртуальной инфраструктуры ждут, пока хост Б снимет старую и поставит свою новую блокировку, а также накатит журнал VMFS.
Данный тип блокировок почти не влияет на производительность хранилища, так как происходят они в нормально функционирующей виртуальной среде достаточно редко. Однако сам процесс создания блокировки на файл виртуальной машины вызывает второй тип блокировки - лок тома VMFS.
Блокировки на уровне тома VMFS
Этот тип блокировок необходим для того, чтобы хост-серверы ESXi имели возможность вносить изменения в метаданные тома VMFS, обновление которых наступает в следующих случаях:
Создание, расширение (например, "тонкий" диск) или блокировка файла виртуальной машины
Изменение атрибутов файла на томе VMFS
Включение и выключение виртуальной машины
Создание, расширение или удаление тома VMFS
Создание шаблона виртуальной машины
Развертывание ВМ из шаблона
Миграция виртуальной машины средствами vMotion
Для реализации блокировок на уровне тома есть также 2 механизма:
Механизм SCSI reservations - когда хост блокирует LUN, резервируя его для себя целиком, для создания себе эксклюзивной возможности внесения изменений в метаданные тома.
Механизм "Hardware Assisted Locking", который блокирует только определенные блоки на устройстве (на уровне секторов устройства).
Наглядно механизм блокировок средствами SCSI reservations можно представить так:
Эта картинка может ввести в заблуждение представленной последовательностью операций. На самом деле, все происходит не совсем так. Том, залоченный ESXi-хостом А, оказывается недоступным другим хостам только на период создания SCSI reservation. После того, как этот reservation создан и лок получен, происходит обновление метаданных тома (более длительная операция по сравнению с самим резервированием) - но в это время SCSI reservation уже очищен, так как лок хостом А уже получен. Поэтому в процессе самого обновления метаданных хостом А все остальные хосты продолжают операции ввода-вывода, не связанные с блокировками.
Надо сказать, что компания VMware с выпуском каждой новой версии платформы vSphere вносит улучшения в механизм блокировки, о чем мы уже писали тут. Например, функция Optimistic Locking, появившаяся еще для ESX 3.5, позволяет собирать блокировки в пачки, максимально откладывая их применение, а потом создавать один SCSI reservation для целого набора локов, чтобы внести измененения в метаданные тома VMFS.
С появлением версии файловой системы VMFS 3.46 в vSphere 4.1 появилась поддержка функций VAAI, реализуемых производителями дисковых массивов, так называемый Hardware Assisted Locking. В частности, один из алгоритмов VAAI, отвечающий за блокировки, называется VAAI ATS (Atomic Test & Set). Он заменяет собой традиционный механизм SCSI reservations, позволяя блокировать только те блоки метаданных на уровне секторов устройства, изменение которых в эксклюзивном режиме требуется хостом. Действует он для всех перечисленных выше операций (лок на файлы ВМ, vMotion и т.п.).
Если дисковый массив поддерживает ATS, то традиционная последовательность SCSI-комманд RESERVE, READ, WRITE, RELEASE заменяется на SCSI-запрос read-modify-write для нужных блокировке блоков области метаданных, что не вызывает "замораживания" LUN для остальных хостов. Но одновременно метаданные тома VMFS, естественно, может обновлять только один хост. Все это лучшим образом влияет на производительность операций ввода-вывода и уменьшает количество конфликтов SCSI reservations, возникающих в традиционной модели.
По умолчанию VMFS 5 использует модель блокировок ATS для устройств, которые поддерживают этот механизм VAAI. Но бывает такое, что по какой-либо причине, устройство перестало поддерживать VAAI (например, вы откатили обновление прошивки). В этом случае обработку блокировок средствами ATS для устройства нужно отменить. Делается это с помощью утилиты vmkfstools:
vmkfstools --configATSOnly 0 device
где device - это пусть к устройству VMFS вроде следующего:
Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).
В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).
Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.
Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:
Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.
Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.
После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:
А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.
Как вы знаете, в VMware vSphere 5 версия файловой системы VMFS была продвинута до 5. Это дает множество преимуществ по сравнению с VMFS 3, в частности, возможность создания хранилищ виртуальных машин (Datastore) размером до 64 ТБ без необходимости создания экстентов.
Это стало возможным благодаря использованию GPT-разделов (GUID Partition Table) вместо MBR-разделов (Master Boot Record). При этом, существует ошибочное мнение, что для томов VMFS 3, обновляемых на VMFS 5, ограничения старой версии в 2 ТБ на файловую систему Datastore остаются. Это не так - VMFS 5.0 при обновлении на нее с третьей версии действительно сохраняет формат MBR, однако после расширения тома более 2 ТБ происходит автоматическая конвертация MBR в GPT-диск.
То есть, происходит это так. У нас есть том VMFS 3, мы нажимаем ссылку "Upgrade to VMFS 5":
После прохождения мастера обновления, видим что тип тома - VMFS 5:
Однако здесь также видно, что том VMFS (теперь уже 5-й версии) остался размеров в 2 ТБ, несмотря на то, что LUN может быть более 2 ТБ. Кроме того, том остался MBR-форматированным, а размеры блоков VMFS 3 для него остались неизменными (см. KB 1003565). Надо отметить, что вновь создаваемые тома VMFS 5 всегда создаются с унифицированным размером блока - 1 МБ.
Чтобы расширить том VMFS, вызываем мастер "Increase Datastore Capacity":
Расширяем том, например до 3 ТБ:
Обратите внимание, что VMFS 5 не дает нам увеличения размера файла (vmdk) по сравнению с предыдущей версией - максимум по прежнему 2 ТБ, просто теперь том может быть размером до 64 ТБ без экстентов.
Запустим fdisk, посмотрим свойства расширенного тома и увидим, что он теперь GPT-том:
Далее операции с таким диском производятся с помощью утилиты partedUtil, но это уже другая история.
RSS
