В статье много терминов и аббревиатур — если какие-то из них вы подзабыли, то в конце материала я подготовил небольшой глоссарий.
В 2011 году VMware представила публике vSphere 4.1 с поддержкой VAAI, нового API для блочных устройств. Такой интерфейс помог улучшить производительность VMFS благодаря делегированию некоторых операций дисковому массиву. В последующих релизах появилась поддержка NAS-устройств, технологии Thin Provision и набора команд T10 для блочных хранилищ.
С выпуском VVOL (виртуальные тома) компания предложила новый подход к взаимодействию с виртуальными машинами, при котором их диски становятся основным элементом управления для систем хранения данных. Новая идея допускает выполнение операций уровня массива (например, снэпшоты) над отдельными VMDK, что позволяет «выровнять» приложение с его фактическими данными и открывает простор для гибкого применения всевозможных политик хранения.
Остается открытым вопрос: какая роль теперь отводится VAAI API и как он связан с VVOL? При работе с виртуальными томами хост ESXi контролирует не только поток данных, но и управляющий канал до массива. Таким образом, VVOL выглядит как более продвинутое расширение интерфейса VAAI NAS. Что ж, предлагаю пройтись по типичным сценариям взаимодействия виртуальных томов с VAAI.
VAAI vs VVOLs
Блочный VAAI и VVOL
VAAI описывает базовые SCSI-примитивы, с помощью которых гипервизор перекладывает выполнение некоторых операций на хранилище. При этом многое зависит от файловой системы VMFS, которая руководит процессом и непосредственно отправляет VAAI-команды.
Благодаря VVOL, системы хранения теперь знают о наличии виртуальных дисков и могут создавать снимки, клоны и выполнять зануление определенных VMDK.
Однако блочный VAAI и Thin Provisioning по-прежнему сосуществуют с новыми виртуальными томами:
- Операции ATS Все config VVOL в хранилище виртуальных томов отформатированы под VMFS и потому требуют поддержки команд ATS. Поддержка этого набора команд определяется наличием ATS для Protocol Endpoint (PE) LUN, к которому привязаны виртуальные тома.
- XCOPY при работе с виртуальными томами ESXi всегда пытается использовать механизм копирования VVOL силами массива, с помощью примитивов copy Diffs To Virtual Volume или Clone Virtual Volume. Если же они не поддерживаются, то будет задействован обычный программный метод копирования. Поскольку софтовое копирование предполагает перенос данных между PE LUN и VMFS LUN, определенный потенциал использования XCOPY есть и в этом случае. Когда вызван программный метод переноса, vSphere задействует команду XCOPY при перемещении виртуальной машины из VMFS в VVOL-хранилище (либо между разделами VVOL). В первом релизе виртуальных томов XCOPY не используется при переносе VM из раздела VVOL на обычный том.
Поддержка XCOPY определяется гипервизором исходя из наличия VAAI XCOPY на разделе PE LUN, к которому привязан виртуальный том. - Block Zeroing. Основное назначение этого примитива заключается в инициализации «толстых» дисков на томах VMFS. Но для данных на виртуальных томах он не используется, так как VMFS в разделе config VVOL содержит лишь метаданные (дискрипторы, файлы vmx, статистику и логи). При этом тип дисков виртуальных машин выбирается при создании раздела VVOL, а сonfig VVOL «тонкие» по определению.
VAAI NAS и VVOL
В отличие от блочного варианта, все функции VAAI NAS предоставляются через вызовы RPC с помощью плагина от производителя СХД. VVOL расширяет эту модель набором VASA API, что позволяет взвалить на плечи хранилища практически все операции сферы. В шестой версии vSphere уже существующие хранилища VAAI NAS продолжат работать как прежде, но более совершенные виртуальные тома явно будут быстрее и функциональнее. Наконец, использование VVOL не потребует установки плагина от вендора хранилища. Еще один важный момент относительно VAAI NAS: их снэпшоты нельзя мигрировать. При попытке выполнить Storage vMotion для машины на таком томе вся ее история VAAI-снимков будет потеряна. Для виртуальных томов это не проблема, там поддерживается перенос снэпшотов между NFS (без VAAI), VMFS, VSAN и VVOL в любых сочетаниях.
VAAI Thin-Provisioning and VVOLs:
- Soft Threshold Warnings. Предупреждения Soft Threshold для любой активности расположенных на VVOL виртуальных машин будут отображены в vCenter. Контейнер с вызвавшей триггер виртуальной машиной помечается желтым значком, хотя и без детализации, на какой именно VM возникла проблема. Такой нюанс наверняка расстроит администратора, но в будущих обновлениях должны все исправить.
- Hard Threshold Warnings. Поведение этих оповещений похоже на таковое для VMFS-хранилищ. Получившая Hard Threshold виртуальная машина приостанавливается до тех пор, пока администратор не выделит больше пространства или не выключит ее.
- UNMAP. Из-за отсутствия управляемых VMFS-дисков сфера не будет использовать этот примитив, хотя и пропустит, если он придет от гостевой системы. При использовании VVOL команда UNMAP от виртуальной машины передается прямиком хранилищу, которое теперь видит все подобные «рекламации».
Windows Server 2012 сразу поддержит UNMAP, а вот Linux сначала проверит уровень SCSI на виртуальном устройстве. Если он будет SCSI-2 (как сейчас), то никакого UNMAP не последует. Проблема наверняка будет решена в будущих релизах.
Наличие UNMAP определяется по VAAI UNMAP на привязанном к виртуальному тому Protocol Endpoint.
Теперь давайте посмотрим, как работают все эти оптимизации в типичных сценариях.
Типичные сценарии
Storage vMotion работающей машины без снэпшотов
Для работающей без снэпшотов VM копированием управляет драйвер Storage vMotion. Задействуется data mover, который по возможности делегирует перенос секций работающей VM массиву.
Блочные VAAI и VVOL
- Bitmap API применяется для определения подлежащих переносу блоков данных (оптимизация расхода пространства).
- XCOPY для самой миграции (хост координирует работу массива).
NAS VAAI
Без оптимизаций.
NAS VVOL
- Bitmap API для определения переносимых блоков.
Storage vMotion работающей машины со снэпшотами
В первую очередь переносятся снимки, после чего драйвер Storage vMotion займется миграцией актуального состояния виртуальной машины.
Блочный VAAI
- Вызывается Bitmap API для поиска блоков данных на перенос.
- XCOPY применяется для миграции снэпшотов и текущего состояния VM.
Блочные VVOL
- Bitmap API для определения переносимых блоков.
- Clone Virtual Volume и copy Diffs To Virtual Volume VASA API вызываются для миграции всех снэпшотов и полностью передают задачу массиву.
- XCOPY для переноса текущего состояния VM (хост координирует работу массива).
NAS VAAI
- Не поддерживает перенос снимков VM.
- Не предлагает каких-либо оптимизаций.
NAS VVOL
- Задействуется Bitmap API для поиска необходимых блоков.
- Clone Virtual Volume и copy Diffs To Virtual Volume VASA API для миграции снэпшотов силами массива.
Storage vMotion выключенной машины без снэпшотов
При таких условиях вместо драйвера Storage vMotion применяется метод перемещения машины (клонирование с последующим удалением исходника).
Block VAAI
- Bitmap API для поиска нужных блоков.
- XCOPY для миграции виртуальной машины.
Block VVOL
- Для выбора подходящих блоков опять же вызывается Bitmap API.
- Задействуется clone Virtual Volume для миграции актуального состояния VM силами массива.
- Copy Diffs To Virtual Volume отвечает за перенос снэпшотов (тоже полностью передает задачу массиву).
NAS VAAI
- Делегирование процесса клонирования массиву.
NAS VVOL
- Все аналогично Block VVOL.
Storage vMotion выключенной машины со снэпшотами
Идея как в предыдущем варианте, но теперь со снэпшотами.
Block VAAI
- Вызывается Bitmap API для поиска блоков на перенос.
- XCOPY для миграции состояния и снэпшотов VM.
Block VVOL
- Bitmap API
- Clone Virtual Volume для миграции актуального состояния и снимков машины полностью силами СХД.
NAS VAAI
- Не может мигрировать снимки.
- Делегирует клонирование массиву.
NAS VVOl (Same as block VVOL)
- Аналогично Block VVOL.
От переводчика
Статья получилась довольно насыщенной по части аббревиатур и определений, потому предлагаю вашему вниманию небольшой глоссарий по некоторым из них:
- VAAI (vStorage API for Array Integration) — специальный интерфейс от VMware, предназначенный для передачи некоторых операций виртуальных машин по работе с дисками на сторону массива. Типичный пример — инициализация Zeroed-Thick-дисков, при котором «зануление» выполняет СХД, а не сервер ESXi.
- VASA (vStorage APIs for Storage Awareness) — интерфейс общения с системой хранения, позволяющий СХД передавать дополнительную информацию о LUN на сервер ESXi. Например, характеристики скорости и надежности.
- ATS (Atomic Test & Set) — набор команд, предназначенный для управления блокировками файловой системы силами СХД. Блокировки нужны при любом создании или изменении файла на томе VMFS, а передача этой функции массиву позволяет повысить производительность.
- UNMAP (Thin Provisioning Block Space Reclamation) — команда для пометки освободившегося дискового пространства внутри VM как свободного. Без этого удаленный файл на 10 Гб внутри vmdk не будет возвращен в пул доступного дискового пространства. Команда нужна для более эффективного расхода места в хранилищах виртуальных машин.
- T10 — комитет, определяющий стандарты SCSI. В случае с vSphere это означает поддержку расширенного набора команд SCSI вне зависимости от конкретного вендора. Разумеется, СХД также должна быть T10-совместимой.
- Config VVOL (Configuration Volume) — отдельный раздел VVOL для каждой виртуальной машины, содержащий метаданные и файлы описаний (VMX, журналы, дескрипторы и т. п.).
- Protocol Endpoint (PE) — некий аналог «точки монтирования» в Linux. PE предназначен для работы с группой виртуальных томов через одну точку входа. Для блочных устройств PE представляется как LUN, а для файловых — как mount point.
- VSAN (Virtual Storage Area Network) — новый продукт VMware, позволяющий собрать пул хранения для виртуальных машин из локальных дисков серверов ESXi. Аналог традиционных высокодоступных систем хранения.
