Vmware vaai что это

Обновлено: 06.07.2024

Недавно вышел в свет один из важнейших документов, содержащий в себе концентрацию лучших практик для обеспечения производительной работы VMware vSphere с поправками на последнюю, седьмую, версию.

Данная серия постов, скорее, вырезка интересующих меня моментов из гайда, которыми можно поделиться с коллегами, с моими комментариями и дополнениями, но не в коем случае не попытка перевести полностью и дословно данный документ.

Мой перевод и понимание документа могут содержать неточности и, возможно, ошибки, поэтому в первую очередь настоятельно рекомендую самостоятельно ознакомиться с документом в его оригинальном виде.

В целом, документ состоит из большого количества секций. Я просто пойду сверху вниз по всем пунктам, которые интересуют меня, и могут быть полезны в первую очередь новичкам.

Первая часть «Hardware for Use with VMware vSphere» посвящается моментам, на которые необходимо обратить внимание при выборе серверного оборудования и начальной конфигурации.

Validate Your Hardware

Всегда необходимо проверять серверное оборудование, планируемое для использования под задачи виртуализации на совместимость с устанавливаемой версией vSphere. Проверять по Support Matrix необходимо все:

HBA, NIC, CPU;
Версии Firmware, драйвера;
СХД, протокол подключения;
Версии гостевых ОС.

Конечно, это не значит, что если в матрице совместимости отсутствует нужная прошивка, либо драйвер, модель CPU и т.п., то система не запустится, но вот в случае возникновения проблем, в технической поддержке могут и отказать до обновления на поддерживаемые версии компонентов.

При новых инсталляциях, рекомендуется тестировать ОЗУ в течение 72 часов, для выявления возможных ошибок.

CPU Hardware Considerations

Hardware-Assisted Virtualization

Большинство современных процессоров Intel и AMD включают в себя функции «помощи в виртуализации» и улучшают производительность виртуальной среды. Данные функции ниже:

Программная реализация вышеуказанных функций не поддерживается VMware начиная с версии 6.7, теперь данную задачу должен полностью брать на себя процессор.

Memory Hardware Considerations

Persistent Memory (PMem)

Планки энергонезависимой памяти, которые включаются в стандартные слоты DIMM. Дешевле, данные сохраняются при перезагрузке, большие объемы памяти, по сравнению с классической ОЗУ, обладают более низкой скоростью доступа. Пример – Intel Optane (DCPMM – DC Persistent Memory Modules), NVDIMM-N.

Intel Optane работает в двух режимах:

Memory mode – DCPMM выступает для операционной системы как основная оперативная память. В этом случае «классическая ОЗУ» DRAM выступает в качестве кэша для DCPMM. Данный режим позволяет «сэкономить» на более дорогой DRAM, не без уменьшения скорости доступа. Производительность зависит от размера DRAM под кэш, как часто необходимо обращаться к ОЗУ и т.п. Подробнее.;
App Direct Mode – В данном случае приложение, либо ОС понимает, что работает как с классической DRAM, так и с Persistent Memory, в связи с чем само выбирает, какую память использовать в конкретный момент. DCPMM может представляться в виртуальной машине виде классического диска (vPMEMDisk) также, как и устройство, выступающее в качестве виртуальной NVDIMM (vPMEM). В этом случае, гостевая операционная система должна понимать, что работает с NVDIMM памятью (PMem aware). Подробнее.

VMware рекомендует использовать режим App Direct как устройство vPMEM. Для получения максимальной производительности приложение должно быть PMem-aware, например, MS SQL Server 2019.

NVDIMM – тип Persistent Memory, работающий на тех же скоростях, что и DRAM, но сохраняет данные при перезагрузках. Всегда подключается в виртуальную машину как PMem и не может работать в режиме Memory Mode, как DCPMM.

В App Mode работает аналогично DCPMM как vPMEMDisk, либо как vPMEM. Подробнее.

Storage Hardware Considerations

В большинстве случаев, на итоговую работу дисковой подсистемы влияет не сколько конфигурация ESXi, сколько конфигурация СХД и сети передачи данных.

Производительность дисковой подсистемы зачастую зависит от множества факторов, включая уровень используемого RAID, типы дисков, размер кэш и т.п.

Перед непосредственным внедрением, крайне рекомендуется ознакомиться с документацией вендора СХД, а также с документацией VMware относительно работы системы виртуализации с СХД выбранного вендора.

VMware vStorage APIs for Array Integration (VAAI)

Выбираем СХД, которая поддерживает VAAI, чтобы перенести выполнение некоторых дисковых операций с гипервизора ESXi на СХД.

В некоторых случаях использование VAAI снижает нагрузку на CPU гипервизора, поскольку теперь часть своей работы он перекладывает на СХД, снижается latency, уменьшается трафик в сети передачи данных.

Основные возможности VAAI для SAN:

Scalable Lock (hardware-assisted locking, atomic test & set он же ATS). Используется при обновлении метаданных VMFS. Ранее, при изменении метаданных ненадолго, но блокировались обращения ко всему VMFS-тому. С использованием Scalable Lock эта проблема решается, блокируется только доступ к изменяемому элементу, но не ко всему Datastore. Выражается в ускорении многих операций, типа изменения конфигураций машин, снапшотов, расширения диско, увеличивается производительность «тонких» VMDK и т.п.;
Extended Copy (XCOPY, copy offload) перекладывает операции по копированию (в рамках одной СХД) на систему хранения данных. Например, при клонировании машин, Storage vMotion. Снижает нагрузку на ESXi. Не будет работать при копировании\клонировании между двумя разными СХД;
Block zeroing (Write Same) – «зануление» дисков thick provision eager-zeroed тоже перекладывается на СХД, уменьшая работу гипервизора;
Dead space reclamation (UNMAP) – крайне полезная вещь, при использовании тонких LUN на СХД. Возвращает освобожденное на Datastore пространство обратно в СХД. Удалил виртуальную машину – стал меньше размером тонкий LUN на СХД (конечно, не моментально).

Основные возможности VAAI для NAS:

Исходя из вышеуказанных возможностей VAAI для SAN и NAS, очевидно, что использование массивов с поддержкой данной технологии настоятельно рекомендуется.

iSCSI and NFS Storage

Убеждаемся, что у нас на сети нет узких мест, желательно, роутинга (точнее крайне настоятельно рекомендуется).

Держим в голове, что использование software-initiated iSCSI адаптера, а также NFS могут потребовать дополнительных ресурсов CPU на хосте, поскольку заниматься обработкой дискового трафика придется ему.

NVMe Storage

NVMe быстрее, но так же требует больше процессорных ресурсов. Рекомендуются к использованию многоядерные процессоры, хотя бы от 8 ядер. Больше процессоров – лучше, но хотя бы 2. С частотой так же – выше – лучше.

NVMe over Fabrics (NVMe-oF) Storage

Начиная с версии 7, ESXi поддерживает технологию NVMe-oF с помощью FC, либо RDMA в качестве транспорта.

NVMe-oF позволяет получить больше значения IOPS при меньших задержках.

Network Hardware Considerations

Убеждаемся, что мы используем «server-class» сетевые адаптеры для получения максимальной производительности. Убеждаемся, что на сети нет узких мест, все кабеля, коммутаторы работают на максимально доступных скоростях.

Так же рекомендуется использовать карты, поддерживающие функции Checksum offload, TSO, LRO, RSS, Jumbo и т.д. (если они, конечно, планируют использоваться).

По аналогии с HBA адаптерами, сетевые карты должны быть установлены в соответствующие PCI слоты, для получения максимально-доступной скорости приема/передачи.

Однопортовые 10Gb/s адаптеры рекомендуется устанавливать в слоты PCIe x8 (или выше), в то время как двухпортовые уже в PCIe x16.

При этом 40 гигабитные адаптеры следует устанавливать в PCI Gen3 x8/16 (либо выше).

По возможности, и крайне рекомендуется, чтобы виртуальный свитч vSwitch содержал адаптеры с одинаковой пропускной способностью.

Использование LACP может увеличить пропускную способность и доступность.

Hardware BIOS Settings

Всегда следует использовать последнюю версию BIOS, доступную для системы (но матрицу совместимости глянуть все равно стоит).

После обновления версии, следует проверить настройки BIOS, вдруг, ранее выставленные значения были изменены.

Добавлю от себя, что, если не знаешь, зачем нужен параметр, лучше его не изменять, чтобы не получить в дальнейшем проблем.

Следует убедиться, что в BIOS задействованы все процессорные сокеты и все ядра на установленных процессорах, включен Hyper-Threading и Turbo Boost;
Не стоит переводить Node Interleaving в параметр enabled (это отключит использование NUMA). Для использования NUMA – выставляем этот параметр в disabled, для использования UMA – enabled. В большинстве случаев, при правильном сайзинге виртуальных машин, с NUMA мы получим большую производительность;
Необходимо убедиться, что все функции hardware-assisted virtualization включены (VT-x, AMD-V, EPT, RVI);
Неплохим решением будет отключить в BIOS устройства, которые не используются. Например, USB, либо сетевые порты.

Power Management BIOS Settings

Не про употребление электропитанием сервера, а про управление питанием CPU.

Рекомендуется переложить управление питанием с плеч BIOS на плечи ESXi, и выставить в BIOS значение “OS Controlled Mode”, либо аналогичное.

C-States помогают экономить электроэнергию, переводя простаивающие процессоры в режим пониженного энергопотребления за счет приостановки работы его отдельных компонентов.

Всего таких уровней 6. Чем выше уровень – тем больше элементов процессора в режиме минимального энергопотребления.

Все выглядит прекрасно до тех пор, пока нагрузка не начинает расти и процессору необходимо перейти из состояния с отключёнными компонентами в полностью рабочее состояние (из режима C6 в C0). Этот переход занимает какое-то время, и это может сказаться на работе некоторых приложений. Подробнее.

Использование C1E (аппаратно-управляемое состояние) зачастую уменьшает потребление электроэнергии с минимальным, либо вообще без влияния на производительность. Однако, некоторые приложения, крайне чувствительные к I/O latency, например, финансовые платформы, могут быть к этому чувствительны. В таком случае рекомендуется отключение C1E в BIOS;
C-States глубже чем C1 и C1E управляются программно. Чтобы получить максимальную производительность на ватт электроэенергии, рекомендуется оставить включенными все C-States, которые в дальнейшем будут управляться с помощью vSphere;
При использовании технологии Turbo Boost или Turbo Core, использование C-States в некоторых ситуациях могут даже увеличить производительность некоторых немногопоточных приложений (в случае, если некоторые ядра процессора простаивают).

На этом раздел по «железной» части подходи к концу. В следующей части посмотрим на все, что касается раздела ESXi and Virtual Machines этого замечательного гайда.

В статье много терминов и аббревиатур — если какие-то из них вы подзабыли, то в конце материала я подготовил небольшой глоссарий.

В 2011 году VMware представила публике vSphere 4.1 с поддержкой VAAI, нового API для блочных устройств. Такой интерфейс помог улучшить производительность VMFS благодаря делегированию некоторых операций дисковому массиву. В последующих релизах появилась поддержка NAS-устройств, технологии Thin Provision и набора команд T10 для блочных хранилищ.

С выпуском VVOL (виртуальные тома) компания предложила новый подход к взаимодействию с виртуальными машинами, при котором их диски становятся основным элементом управления для систем хранения данных. Новая идея допускает выполнение операций уровня массива (например, снэпшоты) над отдельными VMDK, что позволяет «выровнять» приложение с его фактическими данными и открывает простор для гибкого применения всевозможных политик хранения.

Остается открытым вопрос: какая роль теперь отводится VAAI API и как он связан с VVOL? При работе с виртуальными томами хост ESXi контролирует не только поток данных, но и управляющий канал до массива. Таким образом, VVOL выглядит как более продвинутое расширение интерфейса VAAI NAS. Что ж, предлагаю пройтись по типичным сценариям взаимодействия виртуальных томов с VAAI.

Блочный 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:

Теперь давайте посмотрим, как работают все эти оптимизации в типичных сценариях.

Типичные сценарии

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

Storage vMotion выключенной машины со снэпшотами

Идея как в предыдущем варианте, но теперь со снэпшотами.

Block VAAI

Вызывается Bitmap API для поиска блоков на перенос.
XCOPY для миграции состояния и снэпшотов VM.

Block VVOL

Bitmap API
Clone Virtual Volume для миграции актуального состояния и снимков машины полностью силами СХД.

NAS VAAI

Не может мигрировать снимки.
Делегирует клонирование массиву.

NAS VVOl (Same as block VVOL)

От переводчика

Статья получилась довольно насыщенной по части аббревиатур и определений, потому предлагаю вашему вниманию небольшой глоссарий по некоторым из них:

Сетевые накопители QNAP сертифицированы с VMware vSphere версии 5, что позволяет расширить возможности при создании и масштабировании облачных сред. Поддержка технологии VAAI и плагина для vSphere Сlient улучшает взаимодействие сетевого накопителя QNAP и серверов виртуализации, что в свою очередь повышает производительность и эффективность работы.

VAAI (vStorage APIs for Array Integration)

Сетевые накопители QNAP поддерживают технологию VAAI, расширяющую степень их применения в средах виртуализации. Комплекс таких функций VMware, как Full Copy, Block Zeroing и Hardware-assisted Locking позволяет возложить некоторые операции с дисками на сетевой накопитель QNAP, что существенно увеличивает производительность и эффективность виртуальной инфраструктуры.

Fullcopy, увеличение производительности до 70%
Позволяет передать сетевому накопителю QNAP операции копирования объектов виртуальной инфраструктуры, что снижает время клонирования и разворачивания виртуальных машин.
Block zeroing, увеличение производительности до 75%
Возможность обнуления больших блочных массивов силами накопителя QNAP для уменьшения нагрузки на хост-сервер.
Hardware-assisted locking
Благодаря данной функции сетевой накопитель QNAP блокирует не весь LUN при выполнении операций одного ESXi-сервера, а только необходимые блоки, сохраняя оставшуюся часть свободными, что повышает эффективность работы.

С использованием VAAI обработка данных возлагается на сетевой накопитель QNAP, благодаря чему стандартные операции управления и развертывания виртуальной машины могут быть выполнены быстрее, задействовав при этом меньше ресурсов процессора, памяти и пропускной способности ESXi-сервера.

Плагин к vSphere Client

Благодаря поддержке плагина для vSphere Client можно управлять хранилищами данных VMware на сетевом накопителе QNAP прямо из консоли клиента vSphere. В распределенных системах виртуализации администраторы могут легко контролировать состояние сетевого накопителя и хранилищ данных VMware, ИА также создавать дополнительные дисковые хранилища для нескольких ESXi-хостов всего в несколько щелчков мыши.

В век бурного развития технологий виртуализации балом правит интеграция всего и вся. Администраторам и провайдерам уже недостаточно парой движений создавать виртуальные машины и разворачивать из шаблонов целые инфраструктуры — в моде совместная работа всех звеньев инфраструктуры. В этой статье поговорим об удобствах и возможностях, которые дает нам глубокая интеграция гипервизора и систем хранения NetApp.

Небольшой концептуальный экскурс

Несколько лет назад в VMware оценили тенденции развития дата-центров и заранее подготовились к растущей роли хранилищ в виртуализации. Так появилась концепция vStorage, объединяющая в себе множество технологий работы с хранилищами в виртуальной среде, среди которых есть VAAI и VASA:

VASA (vStorage API for Storage Awareness) — основной API-интерфейс для отслеживания конфигурации хранилищ и настройки некоторых их свойств.
VAAI (vStorage API for Array Integration) — API для передачи определенных дисковых операций с виртуальными машинами на сторону массива.

Благодаря новым API стало возможно повысить производительность дисковых томов благодаря делегированию некоторых операций массиву. Например, клонирование VM в таком варианте будет выполняться практически полностью силами массива, как и «зануление» дисков VMDK в формате Zeroed-thick.

Изначально возможности VAAI были доступны только для блочных СХД, но с пятой версии vSphere в игру вступили и NFS-системы NetApp.

Информация об устройствах, томах и топологии

Чаще всего администраторам не хватает под рукой информации о характеристиках подключенных СХД, особенно если поддержкой таких систем занимаются другие люди. Даже чтобы создать «золотой» или «серебряный» профиль хранилища, нужно понимать уровень производительности и надежности доступных ESXi-хранилищ.

Чтобы vSphere мог собрать для вас все эти данные, необходимо установить и настроить VASA-провайдер. Фактически это промежуточное приложение, которое будет собирать информацию о ваших хранилищах и предоставлять ее vSphere. Загрузить провайдер можно на официальном сайте NetApp. После установки потребуется настроить в провайдере подключение к хранилищу NetApp, а в консоли vSphere — доступ к самому провайдеру (подробная неофициальная инструкция).

Еще больше возможностей интеграции

Помимо сбора базового пакета информации об устройствах и топологии, связка vSphere-NetApp умеет несколько больше. Например, можно серьезно повысить производительность подсистемы хранения с помощью возможностей VAAI.

NFS-хранилища требуют предварительной установки и настройки специального плагина vSphere — именно с его помощью добавляется поддержка VAAI для NetApp.

Изначально потребуется выполнить не так уж много условий:

Включение опций VMware vStorage for NFS и NFSv3 на хранилище NetApp с Data ONTAP0.1 или новее.
Проверка работы VAAI на хосте vSphere 0 или новее.

Можно использовать команду esxcli storage nfs list.

и установка специального плагина (NetAppNasPlugin.vib) на хосте ESXi, к которому подключено хранилище NetApp.

Если при установке плагина возникнут какие-либо затруднения, предлагаем официальную и неофициальную инструкции. Как только плагин установлен и все настройки сделаны, vSphere будет самостоятельно управлять всеми «аппаратными ускорениями» массива.

Теперь ознакомимся со всеми возможностями, которые открывает включение vStorage APIs для СХД.

Удобное управление профилями хранения

Благодаря VASA можно значительно упростить себе жизнь в части работы с СХД NetApp в виртуальной среде. Собирая информацию о хранилищах из Virtual Storage Console и пересылая ее в vCenter, провайдер VASA позволяет:

Более грамотно размещать новые VM на датасторах. Можно создать профили хранения с разным уровнем надежности и производительности, а VASA позволит подобрать под них правильные устройства.
Своевременно получать оповещения о несоответствии хранилища уровню надежности или производительности, заявленному в профиле vSphere. То есть если уровень RAID был каким-то образом изменен с 10 на 1, вы узнаете об этом до размещения там пары новых СУБД.

По умолчанию провайдер VASA содержит три стандартных профиля хранилищ:

Gold — позиционируется как вариант для размещения бизнес-критичных приложений. Характеризуется высочайшей производительностью, которая не зависит от загрузки соседних дисковых томов, и изоляцией в случае аварии.
Silver — мейнстрим для корпоративных приложений. Это достаточно производительные хранилища с чуть меньшей надежностью при масштабных авариях.
Bronze — самый емкий, но при этом ограниченный по скорости профиль. Обычно для таких систем не предусмотрен вариант защиты от масштабных аварий.

При развертывании новых виртуальных машин можно использовать один из этих профилей для правильного размещения их VMDK.

«Разгрузка» процесса копирования VM

Хранилище NetApp может полностью выполнять клонирование VM или миграцию VMDK между датасторами внутри массива. Благодаря этому исключаются лишние I/O-операции с хоста, что экономит ресурсы CPU и полосу пропускания сети.

При создании клона VM в пределах одного тома NetApp использует Full Copy API для клонирования VM с «эталонного» образа. Такие копии впоследствии могут быть использованы для создания VM на любом датасторе ЦОД.

Также Full Copy API используется для миграции дисков машины между разными томами (Storage vMotion). Благодаря выполнению миграции силами массива машины могут переезжать между хранилищами для балансировки нагрузки или при операциях обслуживания. При этом ресурсы хоста практически не задействуются в этом процессе и могут быть использованы для полезной работы VM.

Аппаратное «зануление» при создании виртуальных дисков

Если вы используете VMDK-диски форматов zeroed-thick или eagerzeroed-thick, то наверняка оцените аппаратное ускорение этого процесса — форматирование дисков и их размещение на датасторе целиком выполняется СХД.

При создании дисков двух указанных выше форматов хост ESXi в общем случае занимается выделением довольно большого дискового объема с последующим заполнением его нулями:

При zeroed-thick фактическое «зануление» выполняется в процессе работы с диском. Так создание диска выполняется быстрее, но теряется производительность на дополнительных операциях с диском при дальнейшей работе.
Eagerzeroed-thick предполагает изначальное заполнение нового диска нулями, что гарантирует его высокую производительность, но требует дополнительного времени при создании

Благодаря передаче такой инициализации на массив скорость работы с «зануленными» дисками для хоста ESXi перестает отличаться от обычных VMDK — все дополнительные операции берет на себя СХД. Особенно полезно аппаратное ускорение для машин с включенной опцией VMware Fault Tolerance, так как при ее работе требуется «зануление» довольно большого числа блоков виртуальных дисков.

Аппаратные блокировки

Для внесения изменений в объекты VMFS гипервизор от VMware использует принцип блокировки дискового тома (LUN). То есть если нужно создать новую VM, изменить размер виртуального диска (что происходит очень часто с «тонкими» дисками) или просто добавить к имеющейся VM новое устройство, — на время выполнения этой операции ESXi блокирует ВЕСЬ LUN с использованием SCSI reservation.

При действующей блокировке с томом не могут работать остальные хосты, что порой здорово мешает в крупной виртуальной среде. Чем выше дисковая нагрузка в среде виртуализации, тем болезненнее (в плане производительности) будут происходить любые изменения в датасторах VMFS и тем более явными будут «тормоза» требовательных к дисковому I/O приложений.

Для решения этой проблемы в VAAI используется Hardware Assisted Locking API, позволяющий более детально подходить к вопросу блокировок. Вместо целого тома резервируются конкретные области раздела СХД, которые необходимо изменить.

Мы рассмотрели основные возможности интеграции NetApp и VMware — вендоров, которые наиболее востребованы сегодня для построения корпоративных облаков в модели IaaS.

Читайте также: