vasa vmware что это

Технологии хранения данных VMware vSphere 6. Часть 1 – Old School

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

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

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

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

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

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

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

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

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

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

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 позволяют оптимизировать и переложить на массив следующие процессы:

Пояснение

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

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

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

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

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

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

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

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:

Источник

VMware ESXi 5.Х и NetApp ONTAP 8: тюнинг

Настройки VMWare ESXi можно разделить на следующие части:

Hypervisor

Этот раздел вынесу в отдельный пост.

Гостевые ОС

Disk alignment

Первый случай это когда есть misalignment VMFS датастора относительно хранилища. Для устранения первого типа проблемы необходимо создать лун с правильной геометрией и переместить туда виртуальные машины.

Пример для файловой системы VMFS3. В новосозданной VMFS5 (не апгрейд с VMFS3) блок имеет размер 1MB с суб-блоками 8KB.

takeover/giveback

Для отработки при takeover/giveback в HA паре, необходимо настроить правильные таймауты гостевых ОС :

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

Устанавливаются эти значения вручную или при помощи скриптов доступных в составе VSC.
Windows: Установить значение задержки доступа к диску 60 сек при помощи реестра (задаётся в секундах, в шеснадцатиричной форме).

Solaris: Устанавить значение 60 сек задержки (задаётся в секундах, в шеснадцатиричной форме) для диска можно в файле /etc/system:
Дополнительные настройки могут быть внесены в файл /kernel/drv/sd.conf:
Solaris 10.0 GA — Solaris 10u6:

Solaris 10u7 и новее и Solaris 11:

Обратите внимение: на два пробела между vendor ID NETAPP и ID LUN, также как и между словами «VMware» и «Virtual» в конфиге выше.

Настройки FC/FCoE Switch Zoning

Round Robin будет более производительнее если путей больше чем один к контроллеру. В случае использования Microsoft Cluster + RDM дисков к применению рекомендован механизм балансировки Most Recently Used.

Ниже таблица рекомендуемых настроек балансировки нагрузки. Подробнее о логике работы NetApp FAS, ALUA и балансировке нагрузки для блочных протоколов.

Удостоверьтесь в том, что SATP политика применившаяся к вашему луну имеет включённую опцию reset_on_attempted_reserve:

Настройки ESXi хоста

Для оптимальной работй ESXi хоста необходимо установить рекомендуемые для него параменты.

Есть несколько способов это сделать:

Утилита esxcfg-advcfg испольуемая в этих примерах располагается в /usr/sbin папке для ESXi хоста.

Утилита esxcfg-advcfg испольуемая в этих примерах располагается в /usr/sbin папке для ESXi хоста.

Источник

NetApp ONTAP & VMware vVOL

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

Почему появилась эта технология и зачем она нужна, почему она будет востребована в современных ЦОД? На эти и другие вопросы я постараюсь ответить в этой статье.

Технология vVol предоставила профили, которые при создании ВМ создают виртуальные диски с заданными характеристиками. В такой среде администратор виртуальной среды уже может с одной стороны у себя в интерфейсе vCenter легко и быстро проверить, какие виртуальные машины живут на каких носителях и узнать их характеристики на СХД: какой там тип носителя, включена ли для него технология кеширования, выполняется ли там репликация для DR, настроена ли там компрессия, дедупликация, шифрование и т.д. С технологией vVol, СХД стала просто набором ресурсов для vCenter, намного более глубже интегрировав их друг с другом, чем это было раньше.

Снепшоты

Проблема консолидации снепшотов и увеличение нагрузки на дисковую подсистему от снепшотов VMware может быть не заметна для небольших виртуальных инфраструктур, но даже они могут встречаться с их негативным влиянием в виде замедления роботы виртуальной машины или невозможности консолидации (удаление снепшота). vVol поддерживает аппаратный QoS для виртуальных дисков ВМ, а также Hardware-Assistant репликацию и снепшоты NetApp, так как они архитектурно устроены и принципиально по-другому работают, не влияя на производительность, в отличие от COW снепшотов VMware. Казалось бы кто пользуется этими снепшотами и почему это важно? Дело в том, что все схемы резервного копирования в среде виртуализации так или иначе архитектурно вынуждены использовать COW снепшоты VMware, если вы хотите получить консистентные данные.

Что вообще такое vVol? vVol — это прослойка для датастора, т.е. это технология виртуализации датастора. Раньше у вас был датастор, расположенный на LUN’е (SAN) или файловой шаре (NAS); как правило, каждый датастор размещал несколько виртуальных машин. vVol сделала датастор более гранулярным создавая отдельный датастор под каждый диск виртуальной машины. vVol также с одной стороны унифицировала работу с протоколами NAS и SAN для среды виртуализации, администратору всё-равно, это луны или файлы, с другой стороны, каждый виртуальный диск ВМ может жить в разных вольюмах, лунах, дисковых пулах (агрегатах), с разными натсройками кеширования и QoS, на разных контроллерах и могут иметь разные политики, которые следуют за этим диском ВМ. В случае с традиционным SAN всё, что СХД «видела» со своей стороны и то, чем она могла управлять — целиком всем датастором, но не отдельно каждым виртуальным диском ВМ. С vVol при создании одной виртуальной машины каждый её отдельный диск может создаваться в соответствии с отдельной политикой. Каждая политика vVol, в свою очередь, позволяет выбирать то свободное пространство из доступного пула ресурсов СХД, которое будет соответствовать заранее прописанным условиям в политиках vVol.

Это позволяет более эффективно и удобно использовать ресурсы и возможности системы хранения. Таким образом, каждый диск виртуальной машины расположен на выделенном своём виртуальном датасторе на подобии LUN RDM. С другой же стороны, в технологии vVol использование одного общего пространства более не является проблемой, ведь аппаратные снепшоты и клоны выполняются не на уровне целого датастора, а на уровне каждого отдельного виртуального диска, при этом не применяются COW снепшоты VMware. В тоже время система хранения теперь сможет «видеть» каждый виртуальный диск отдельно, это позволило делегировать возможности СХД в vSphere (к примеру, снепшоты), предоставляя более глубокую интеграцию и прозрачность дисковых ресурсов для виртуализации.

Компания VMware начала разработку vVol в 2012 году и продемонстрировала эту технологию через два года в своём превью, одновременно компания NetApp объявила о её поддержке в своих системах хранения данных с прошивкой ONTAP со всеми поддерживаемыми средой VMWare протоколами: NAS (NFS), SAN (iSCSI, FCP).

Protocol Endpoints

Давайте теперь отойдём от абстрактного описания и перейдем к конкретике. vVol’ы располагаются на FlexVol, для NAS и SAN это, соответственно, файлы или луны. Каждый VMDK диск живёт на своём выделенном vVol диске. При переезде vVol диска на другую ноду СХД, он прозрачно перемапливается к другому PE на этой новой ноде. Гипервизор может запускать создание снепшота отдельно для каждого диска виртуальной машины. Снепшот одного виртуального диска — это его полная копия, т.е. ещё один vVol. Каждая новая виртуальная машина без снепшотов состоит из нескольких vVol. В зависимости от назначения vVol’ы бывают следующих типов:

Теперь, собственно, про PE. PE — это точка входа к vVol’ам, своего рода прокси. PE и vVol’ы располагаются на СХД. В случае NAS такой точкой входа является каждый Data LIF со своим IP адресом на порте СХД. В случае с SAN это специальный 4МБ лун.

PE создаётся по требованию VASA Provider (VP). PE примапливает все свои vVol по средствам Binging запроса от VP к СХД, примером наиболее частого запроса является старт VM.

ESXi всегда подключается к PE, а не напрямую к vVol. В случае с SAN это позволяет избегать ограничения в 255 лунов на ESXi хост и ограничения в максимальном количестве путей к луну. Каждая виртуальная машина может состоять из vVol только одного протокола: NFS, iSCSI или FCP. Все PE имеют LUN ID 300 и выше.

Несмотря на небольшие отличия, NAS и SAN весьма похожим образом устроены с точки зрения работы vVol в среде виртуализации.

iGroup & Export Policy

iGroup и Export Policy — это механизмы, позволяющие скрывать от хостов доступную на СХД информацию. Т.е. предоставлять каждому хосту только то, что он должен видеть. Как в случае с NAS, так и SAN, мапинг лунов и экспорт файловых шар происходит автоматически из VP. iGroup мапится не на все vVol, а только на PE, так как ESXi использует PE как прокси. В случае NFS протокола, экспорт политика автоматически применяется к файловой шаре. iGroup и экспорт политика создаётся и заполняется автоматически при помощи запроса из vCenter.

SAN & IP SAN

В случае протокола iSCSI необходимо иметь минимум один Data LIF на каждой ноде СХД, который подключён в ту же сеть, что и соответствующий VMkernel на ESXi хосте. iSCSI и NFS LIF’ы должны быть разделены, но могут сосуществовать в одной IP сети и одном VLAN. В случае FCP необходимо иметь минимум один Data LIF на каждой ноде СХД для каждой фабрики, другими словами, как правило это два Data LIF’а от каждой ноды СХД, живущие на своём отдельном таргет-порте. Используйте soft-zoning на свиче для FCP.

NAS (NFS)

В случае протокола NFS необходимо иметь минимум один Data LIF с установленным IP адресом на каждой ноде СХД, который подключён в ту же подсеть сеть, что и соответствующий VMkernel на ESXi хосте. Нельзя использовать один IP адрес для iSCSI и NFS одновременно, но они оба могут сосуществовать в одном VLAN, в одной подсети и на одном физическом Ethernet порте.

VASA Provider

VP является посредником между vCenter и СХД, он объясняет СХД, что от неё хочет vCenter и наоборот рассказывает vCenter об важных алертах и доступных ресурсах СХД, тех, которые есть физически на самом деле. Т.е. vCenter теперь может знать сколько свободного пространства есть на самом деле, это особенно удобно, когда СХД презентует гипервизору тонкие луны.

VP не является единой точкой отказа в том смысле, что при его выходе из строя виртуальные машины по-прежнему, нормально будут работать, но нельзя будет создавать или редактировать политики и виртуальные машины на vVol, стартовать или останавливать VM на vVol. Т.е. в случае полной перезагрузки всей инфраструктуры, виртуальные машины не смогут стартовать, так как не отработает Binding запрос VP к СХД чтобы примапить PE к своим vVol. Поэтому VP однозначно желательно резервировать. И по той же причине не разрешается располагать виртуальную машину с VP на vVol, которым он управляет. Почему «желательно» резервировать? Потому что, начиная с версии NetApp VP 6.2, последний умеет восстанавливать содержимое vVol просто считывая метаинформацию с самой СХД. Подробнее про настройку и интеграцию в документации по VASA Provider и VSC.

Disaster Recovery

VP поддерживает функционал Disaster Recovery: в случае удаления или повреждения VP, база данных окружения vVol может быть восстановлена: Мета информация об окружении vVol храниться в дублированном виде: в базе данных VP, а также вместе с самими объектами vVol на ONTAP. Для восстановления VP достаточно от-регистрировать старый VP, поднять новый VP, зарегистрировать в нём ONTAP, там же выполнить команду vp dr_recoverdb и подключить к vCenter, в последнем выполнить «Rescan Storage Provider». Подробнее в KB.

Функционал DR для VP позволит ореплицировать vVol средствами аппаратной репликации SnapMirror и восстановить сайт на DR-площадке, когда vVol начнёт поддерживать репликацию СХД (VASA 3.0).

Virtual Storage Console

VSC — это плагин для СХД в графический интерфейс vCenter, в том числе для работы с политиками VP. VSC является обязательным компонентом для работы vVol.

Snapshot & FlexClone

Давайте проведём грань между снепшотами с точки зрения гипервизора и снепшотами с точки зрения СХД. Это очень важно для понимания внутреннего устройства того, как работает vVol на NetApp со снепшотами. Как многие уже знают, снепшоты в ONTAP всегда выполняются на уровне вольюма (и агрегата) и не выполняются на уровне файла/луна. С другой же стороны vVol, это файлы или луны, т.е. с них нельзя для каждого по отдельности VMDK файла снимать снепшоты средствами СХД. Здесь на помощь приходит технология FlexClone, которая как раз умеет делать клоны не только вольюмов целиком, но и файлов/лунов. Т.е. когда гипервизор снимает снепшот виртуальной машины, живущей на vVol, то под капотом происходит следующее: vCenter контактирует с VSC и VP, которые в свою очередь находят, где именно живут нужные VMDK файлы и дают команду ONATP снять с них клон. Да, то что со стороны гипервизора выглядит как снепшот, на СХД это клон. Другими словами, для того, чтобы на vVol работали Hardware-Assistant Snapshot необходима лицензия FlexClone. Именно для такой или подобных целей в ONTAP появился новый функционал FlexClone Autodelete, который позволяет задать политики удаления старых клонов.

Так как снепшоты выполняются на уровне СХД, проблема консолидации снепшотов (ESXi) и негативное влияние снепшотов на производительность дисковой подсистемы, полностью устранены благодаря внутреннему устройству механизма клонирования/снепшотирования в ONTAP.

Консистентность

Так как сам гипервизор снимает снепшоты средствами СХД, то они уже сразу автоматически консистентные. Что очень хорошо вписывается в парадигму резервного копирования NetApp ONTAP. vSphere поддерживает снепшотирование памяти ВМ на выделенный vVol.

Клонирование и VDI

Функция клонирования чаще всего очень востребована в VDI окружении, где есть необходимость быстро разворачивать множество однотипных виртуальных машин. Для того, чтобы использовать Hardware-Assistant клонирование необходима лицензия FlexClone. Важно отметить, что технология FlexClone не только кардинально ускоряет разворачивание копий большого количества виртуальных машин, кардинально уменьшая потребление дискового пространства, но и косвенно ускоряет их работу. Клонирование по сути выполняет функцию подобную дедупликации, т.е. уменьшает объем занимаемого пространства. Дело в том, что NetApp FAS всегда помещает данные в системный кэш, а системный и SSD кэши в свою очередь является Dedup-Aware, т.е. они не затягивает дубликаты блоков от других виртуальных машин, которые уже там есть, логически вмещая намного больше нежели физически системный и SSD кэш могут. Это кардинально улучшает производительность во время эксплуатации СХД и особенно в моменты Boot-Storm благодаря увеличению попадания/чтения данных в/из кэш(а).

UNMAP

Технология vVol начиная с версии VMware 6.0, VM Hardware версии 11 и Windows 2012 с файловой системой NTFS поддерживает высвобождение пространства внутрь тонкого луна на котором расположена данная виртуальная машина автоматически. Это существенно улучшает утилизацию полезного пространства в SAN инфраструктуре, использующей Thing Provisioning и Hardware-assistant снепшоты. А начиная с VMware 6.5 и гостевой ОС Linux с поддержкой SPC-4 также позволит высвобождать пространство изнутри виртуальной машины, назад в СХД, позволяя существенно экономить дорогостоящее пространство на СХД. Подробнее про UNMAP.

Минимальные системные требования

SRM и аппаратная репликация

Site Recovery Manager, к сожалению, пока что не поддерживает vVol так как в текущей реализации VASA протокола со стороны VMware не поддерживается репликация и SRM. Системы NetApp FAS имеют интеграцию с SRM и работают без vVol. Технология vVol также поддерживается с vMSC (MetroCluster) для построения для построения, гео-распределённого высоко-доступного хранилища.

Резервное копирование

Технология vVol кардинально изменит подход к резервному копированию, уменьшив время резервного копирования и более эффективно используя пространство хранилища. Одной из причин тому есть принципиально другой подход снепшотирования и резервного копирования, так как vVol использует аппаратное снепшотирование, из-за чего вопрос консолидации и удаления снепшотов VMware отпадает. Из-за устранения проблемы с консолидацией снепшотов VMware, снятие application-aware (аппаратных) снепшотов и резервных копий перестаёт быть головной болью админов. Это позволит более часто снимать резервные копии и снепшоты. Аппаратные снепшоты не влияющие на производительность позволят их хранить много прямо на продуктивной среде, а аппаратная репликация позволит более эффективно реплицировать данные для архивирования или на DR-сайт. Использование снепшотов по сравнению с Full-backup позволит более экономно использовать пространство хранилищ.

VASA API 3.0

Не путайте плагин от вендора СХД (к примеру NetApp VASA Provider 6.0) и API интерфейс VMware VASA (к примеру VASA API 3.0). Самым важным и ожидаемым новшеством в VASA API, в ближайшее время, станет поддержка аппаратной репликации. Именно поддержки аппаратной репликации так не хватает для того, чтобы технология vVol начала широко применяться. В новой версии будет поддерживается аппаратная репликация vVol дисков средствами СХД для обеспечения функции DR. Репликацию можно было выполнить и раньше средствами СХД, но гипервизор раньше не мог работать с отреплицированными данными из-за отсутствия поддержки такого функционала в VASA API 2.X (и более младшей) со стороны vSphere. Также появятся PowerShell командлеты для управления DR на vVol, и что важно, возможность запуска для тестирования отреплицированных машин. Для запланированной миграции с DR сайта может будет запрошена репликация виртуальной машины. Это позволит использовать SRM вместе с vVol.

Oracle RAC будет валидирован для запуска на vVol, что не может не радовать.

Лицензирование

Для работы vVol необходимы следующие компоненты: VP, VSA и хранилище с необходимой прошивкой, поддерживающее vVol. Эти компоненты сами по себе не требуют каких-либо лицензий для работы vVol. Со стороны NetApp ONTAP обязательно необходимо наличие лицензии FlexClone, чтобы vVol работал, — эта лицензия также нужна для того, чтобы поддерживались аппаратные снепшоты или клоны (снятие и восстановление). Для репликации данных (если она нужна) необходима будет лицензия NetApp SnapMirror/SnapVault (на обоих СХД: на основной и резервной площадках). Со стороны vSphere необходимы лицензии Standard или Enterprise Plus.

Источник