Представляю вашему вниманию первую часть серии публикаций о технологиях хранения VMware vSphere. В данной статье будут рассмотрены старые проверенные фичи, доступные еще в 4 и 5 версиях продукта.

VASA – vSphere API for Storage Awareness / Набор API для отслеживания хранилищ

VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.

Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:

• получала информацию о статусе, характеристиках и возможностях СХД;
• могла работать с такими сущностями как Virtual SAN and Virtual Volumes;
• могла взаимодействовать с фильтры ввода-вывода (VAIO).

Наличие соответствующего VASA-провайдера предоставляет указанные выше возможности и позволяет использовать их в политиках (SPBM). Если нет нужного провайдера хранения vSphere не видит характеристик СХД, фильтров VAIO, не может работать с vVOL, отсутствует возможность создать соответствующие правила в политиках.

VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.

Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.

vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.

Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:

• Возможности и сервисы хранилища. Это как раз то, на основе чего формируются правила Common rules и Rules Based on Storage-Specific Data Services в SPBM – возможности и сервисы, предоставляемые Virtual SAN, vVol и фильтрами ввода-вывода.
• Состояние хранилища. Информация о состоянии и событиях на стороне хранилищ, в т.ч. тревожные события, изменения конфигурации.
• Информация Storage DRS. Данная информация позволяет учитывать внутренние процессы управления хранилищами в работе механизма Storage DRS.

Разработка VASA-провайдера для интеграции продукта (3-й стороны), в частности СХД, с vSphere ложится на плечи вендора. Такие storage provider-ы могут быть установлены практически на любом узле инфраструктуры за исключением сервера vCenter. Как правило, сторонние VASA-провайдеры устанавливаются на контроллер СХД или выделенный сервер.

К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).

VAAI — vSphere API for Array Integration / Набор API для интеграции массива

API данного типа можно разделить на 2 категории:

• Hardware Acceleration APIs. Предназначены для прозрачного переноса нагрузок по выполнению отдельных операций связанных с хранением с гипервизоров на СХД.
• Array Thin Provisioning APIs. Предназначены для мониторинга пространства на «тонких» разделах массивов для предотвращения ситуаций с нехваткой места и выполнения отзыва (неиспользуемого) пространства.

Storage Hardware Acceleration (VAAI для Hardware Acceleration)

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

Storage Hardware Acceleration поддерживается для блочных (FC, iSCSI) и файловых (NAS) СХД. Для работы технологии необходимо, чтобы блочное устройство поддерживало стандарт T10 SCSI либо имело VAAI-плагин. Если блочный массив поддерживает стандарт T10 SCSI, то VAAI-плагин для поддержки Hardware Acceleration не нужен, все заработает напрямую. Файловые хранилища требуют наличия отдельного VAAI-плагина. Разработка VAAI-плагинов ложится на плечи производителя СХД.

В целом VAAI для Hardware Acceleration позволяют оптимизировать и переложить на массив следующие процессы:

• Миграция ВМ посредством Storage vMotion.
• Развертывание ВМ из шаблона.
• Клонирование ВМ или шаблонов ВМ.
• Блокировки VMFS и операции с метаданными для ВМ.
• Работа с «толстыми» дисками (блочный и файловый доступ, eager-zero диски).

Для блочных устройств Hardware Acceleration оптимизирует операции:

• Full copy (clone blocks или copy offload). Позволяет массиву делать полную копию данных, избегая операций чтения-записи хостом. Данная операция сокращает время и сетевую нагрузку при клонировании, развертывании из шаблона или миграции (перемещении диска) ВМ.
• Block zeroing (write same). Позволяет массиву обнулять большое количество блоков, что значительно оптимизирует создание дисков типа «eager zero thick» для ВМ.
• Hardware assisted locking (atomic test and set — ATS). Позволяет избежать блокировки LUN-а с VMFS целиком (нет необходимости использовать команду SCSI reservation) благодаря поддержке выборочной блокировки отдельных блоков. Исключается потеря (снижается вероятность потери) производительности хранилища при внесении гипервизором изменений в метаданные на LUN с VMFS.

Пояснение

VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.

Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.

Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).

Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:

• VMFS разделы источника и назначения имеют разные размеры блока
• Файл источник имеет формат RDM, файл назначения не-RDM
• Исходный файл «eager-zeroed-thick», файл назначения «тонкий»
• ВМ имеет снапшоты
• VMFS растянута на несколько массивов

Для файловых СХД Hardware Acceleration оптимизирует операции:

• Full File Clone. Позволяет клонировать файлы ВМ на уровне устройства NAS.
• Reserve Space. Позволяет резервировать пространство для ВМ с «толстыми» дисками (по умолчанию NFS не резервирует пространство и не позволяет делать «толстые» диски).
• Native Snapshot Support. Поддержка создания снапшотов ВМ на уровне массива.
• Extended Statistics. Даёт возможность увидеть использование пространства на массиве.

Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга

Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.

PSA выполняет следующие задачи:

• Загружает и выгружает плагины мультипафинга
• Скрывает от ВМ специфику работы плагинов мультипафинга
• Направляет запросы ввода-вывода MPP
• Обрабатывает очереди ввода-вывода
• Распределяет полосу пропускания между ВМ
• Выполняет обнаружение и удаление физических путей
• Собирает статистику ввода-вывода

По умолчанию ESXi использует встроенный плагин мультипафинга VMware — Native Multipathing Plug-In (NMP). В целом, NMP поддерживает все типы и модели СХД совместимые с vSphere и выбирает алгоритм мультипафинга по умолчанию в зависимости от конкретной модели.

NMP в свою очередь также является расширяемым модулем, управляющим двумя наборами плагинов: Storage Array Type Plug-Ins (SATPs), and Path Selection Plug-Ins (PSPs). SATPs и PSPs могут быть встроенными плагинами VMware или разработками сторонних производителей. При необходимости разработчик СХД может создать собственный MPP для использования в дополнение или вместо NMP.

SATP отвечает за восстановление пути посте сбоя (failover): мониторинг состояния физических путей, информирование об изменении их состояния, переключение со сбойного пути на рабочий. NMP предоставляет SATPs для всех возможных моделей массивов, поддерживаемых vSphere, и осуществляет выбор подходящего SATP.

PSP отвечает за выбор физического пути передачи данных. NMP предлагает 3 встроенных варианта PSP: Most Recently Used, Fixed, Round Robin. Основываясь на выбранном для массива SATP, модуль NMP делает выбор варианта PSP по умолчанию. При этом vSphere Web Client дает возможность выбрать вариант PSP вручную.

Принцип работы вариантов PSP:

• Most Recently Used (MRU) – хост выбирает путь который использовался последним (недавно). Если этот путь становится недоступен, то хост переходит на альтернативный путь. Возврат к первоначальному пути после его восстановления не происходит. Возможность задания предпочитаемого пути отсутствует. MRU – вариант по умолчанию для большинства active-passive массивов.
  
  
• Fixed – хост использует предпочитаемый путь, который может быть задан вручную, либо выбирает первый рабочий путь, обнаруженный при загрузке системы. Вручную заданный предпочитаемый путь сохраняет свой статус даже будучи недоступным, поэтому после его восстановления хост переключится на него обратно. Если предпочитаемый путь явно не задан вручную и был выбран автоматически, то в случае его недоступности предпочитаемым назначается дублирующий путь и возврата к первоначальному пути после его восстановления не будет. Fixed – вариант по умолчанию для большинства active-active массивов.
  
  
• Round Robin (RR) – хост использует автоматический алгоритм выбора пути выполняя ротацию активных путей для active-passive массивов, либо ротацию всех путей для active-active массивов. Как видно, RR может использоваться для обоих типов массивов и позволяет выполнять балансировку нагрузки по путям для разных LUNов.

Спасибо за внимание, продолжение следует.