Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.
Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.
При таком подходе гранулярность операций сопровождения хранилища ВМ силами массива находится на уровне datastore (LUN или NFS-шара целиком), а не на уровне отдельных ВМ. Имеются в виду такие операции, как снапшоты, репликация, дедупликация, шифрование, QoS. Они выполняются на уровне СХД, а не средствами гипервизора, что позволяет осуществлять их быстрее, при этом разгружая вычислительные ресурсы хостов и сеть передачи данных. В первую очередь это касается блочного доступа с VMFS, некоторые модели файловых массивов (например, NetApp) дают гранулярность на уровне отдельных ВМ – например, СХД позволяет сделать снапшот отдельной ВМ, а не datastore целиком.
Описанная выше традиционная технология хранения ВМ в vSphere 6 по прежнему поддерживается, но в дополнение к ней была разработана концепция Virtual Volumes (VVOL), предполагающая объектное хранение ВМ на массивах, поддерживающих данную технологию, независимо от их типа (блочные или файловые).
VVOL – это объект, содержащий файлы ВМ, виртуальные диски и их производные. СХД с поддержкой VVOL получает возможность непосредственной работы с данными объектами за счет собственных аппаратных ресурсов. Как правило, каждый VVOL имеет уникальный GUID для идентификации. Нет необходимости заранее выделять пространство под VVOL, они создаются автоматом при выполнении операций с ВМ: создание, клонирование, снапшотинг.
vSphere (хосты ESXi и vCenter) ассоциирует с ВМ один или несколько VVOL:
• VVOL данных, соответствующий файлу виртуального диска (.vmdk);
• VVOL конфигурации — небольшая домашняя директория, содержащая метаданные ВМ (включая файл .vmx, файлы дескрипторы виртуальных дисков, log-файлы и т.п.). Данный тип VVOL форматируется в VMFS или NFS, в зависимости от типа СХД (блочная или файловая).
• Дополнительные VVOL могут создаваться для остальных компонент ВМ (например, VVOL для swap-файла или файла ОЗУ ВМ для снапшота) или производных виртуальных дисков (клоны, реплики, снапшоты).
Благодаря VVOL мы получаем гранулярность управления хранилищем на уровне отдельных ВМ и можем напрямую задействовать для этого ресурсы СХД. VVOL позволяют использовать гибкие возможности управления хранилищем на основе политик SPBM. Деление данных ВМ на VVOL нескольких типов позволяет размещать их на хранилища с разным уровнем сервиса: VVOL данных на производительный tier с высоким уровнем сервиса, VVOL с конфигурацией или второстепенным диском ВМ на более простые tier.
Для хранения VVOL не нужны классические LUNы или NFS-шары. VVOL хранятся на условно «сыром» пространстве СХД в объектах, называемых storage container. Storage container-ы это логические единицы пространства массива, их количество и ёмкость определяются конкретной СХД и инфраструктурой. Как минимум 1 storage container должен быть создан на СХД, нельзя растягивать 1 storage container на несколько физических массивов.
Storage container-ы логически группируют VVOL из соображений администрирования или управления: можно создавать отдельные storage container-ы для разных заказчиков, департаментов или групп ВМ. Один storage container может включать несколько профилей сервиса, таким образом, на одном и том же storage container могут размещаться ВМ с разными требованиями к обслуживанию и политиками хранения.
Для интеграции СХД с vSphere, для того, чтобы vCenter и гипервизоры могли работать с VVOL и подключиться к storage container необходимо развертывание и регистрация на vCenter специального storage provider-а на базе VASA (VMware APIs for Storage Awareness) для VVOL, который должен разрабатываться и предоставляться производителем СХД.
Для доступа хостов ESXi к VVOL используются логические прокси ввода-вывода, называемы protocol endpoints. ESXi использует protocol endpoints для установления data-path по требованию между ВМ и её VVOL. Каждый VVOL подключен к определенному protocol endpoints. Как правило, СХД требует небольшое количество protocol endpoints, поскольку 1 protocol endpoints может обслуживать множество ВМ (сотни и тысячи).
VVOL поддерживают основные протоколы СХД: Fibre Channel, FCoE, iSCSI, и NFS, аналогично традиционном хранилищам vSphere.
Для поддержки VVOL необходимо использование HBA-адаптеров и версий драйверов для них, адаптированных к работе с (поддерживающих) VVOL.
На стороне СХД происходит конфигурирование protocol endpoints – по одному или несколько на storage container. Protocol endpoints являются частью СХД и предоставляются хостам вместе с ассоциированными storage container-ами через storage provider. vSphere Web Client отображает protocol endpoints, подключенные к инфраструктуре, через T10-based LUN WWN для блочных массивов и IP/DNS для файловых. Protocol endpoints поддерживают мультипафинг только для SCSI-вариантов подключений (для NFS не поддерживается).
Storage container-ы подключаются к инфраструктуре в виде virtual datastore, эти сущности являются их прямым отображением в vSphere Web Client. Virtual datastore аналогичны обычным datastore vSphere, могут отображать VVOL по именам ВМ, их можно монтировать и размонтировать. Однако их конфигурирование, в т.ч. изменение размера осуществляется на уровне СХД за пределами vSphere. Virtual datastore могут использоваться совместно с обычными VMFS и NFS datastore, а также с Virtual SAN.
Размещение ВМ на virtual datastore (с использованием VVOL) требует наличия политик хранения (SPBM). Политика хранения ВМ (VM storage policy) содержит наборы правил по размещению и качеству сервиса для ВМ и гарантирует их выполнение. При отсутствии конкретных политик система будет использовать политику по умолчанию без ограничений, в этом случае массив самостоятельно выберет оптимальное размещение ВМ на свое усмотрение.
Важными преимуществами технологии являются поддержка создания снапшотов и клонов отдельных ВМ на уровне и за счет ресурсов СХД, а также обеспечение таких сервисов как репликация, шифрование, дедупликация и сжатие отдельных виртуальных дисков. Отдельно следует отметить поддержку SPBM, которая открывает большой потенциал управления хранением ВМ на основе политик.
Продукты VMware поддерживающие VVOL:
• VMware vSphere 6.0.x
• VMware vRealize Automation 6.2.x
• VMware Horizon 6.1.x
• VMware vSphere Replication 6.0.x
Продукты VMware НЕ поддерживающие VVOL:
• VMware vRealize Operations Manager 6.0.x to 6.1.0
• VMware Site Recovery Manager 5.x to 6.1.0
• VMware vSphere Data Protection 5.x to 6.1.0
• VMware vCloud Director 5
Технологии VMware поддерживающие VVOL:
• High Availability (HA)
• Linked Clones
• Native Snapshots
• NFS version 3.x
• Storage Policy Based Management (SPBM)
• Storage vMotion
• Thin Provisioning
• View Storage Accelerator/Content Based Read Cache (CBRC)
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• vSphere Flash Read Cache
• vSphere Software Development Kit (SDK)
• vSphere API for I/O Filtering (VAIO)
• vMotion
• xvMotion
• VADP
Технологии VMware НЕ поддерживающие VVOL:
• Fault Tolerance (FT)
• IPv6
• Microsoft Failover Clustering
• NFS version 4.1
• Raw Device Mapping (RDM)
• SMP-FT
• Storage Distributed Resource Scheduler (SDRS)
• Storage I/O Control
Есть предположение, что VMware делает ставку на VVOL, их развитие, и в скором будущем технология станет совместима со всеми решениями вендора. Возможно, в перспективе VVOL станут основной технологией хранения VMware, которая приведет к постепенному уходу от устаревших традиционных хранилищ и прекращению их поддержки.
На момент публикации статьи из 200 (примерно) производителей систем хранения, продукты которых совместимых с vSphere (согласно VMware Compatibility Guide), лишь 18 поддерживают VVOL. Реальных отзывов о практическом использовании VVOL мне найти не удалось: ни в Интернетах, ни на форуме VMware VMUG (даже на буржуйском). Отсутствие совместимости VVOL c перечисленными выше технологиями на данном этапе заставит многих заказчиков отказаться от VVOL, поскольку несовместимая с VVOL технология или их набор зачастую могут оказаться важнее для многих инфраструктур.
Из этого можно сделать вывод, что теоретически технология VVOL очень интересная и полезная. Однако, на данном этапе её практичность и необходимость внедрения вызывают сомнения. Нужен положительный опыт применения в продакшене и нужна совместимость с другими важными фичами vSphere, пока этого нет.
Спасибо за внимание, на этом цикл статей по технологиям хранения vSphere 6 закончен. В следующей статье будут рассмотрены решения VMware для репликации и аварийного восстановления (DR): vSphere Replication и Site Recovery Manager (SRM).
Описание технологии VVOL
Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.
При таком подходе гранулярность операций сопровождения хранилища ВМ силами массива находится на уровне datastore (LUN или NFS-шара целиком), а не на уровне отдельных ВМ. Имеются в виду такие операции, как снапшоты, репликация, дедупликация, шифрование, QoS. Они выполняются на уровне СХД, а не средствами гипервизора, что позволяет осуществлять их быстрее, при этом разгружая вычислительные ресурсы хостов и сеть передачи данных. В первую очередь это касается блочного доступа с VMFS, некоторые модели файловых массивов (например, NetApp) дают гранулярность на уровне отдельных ВМ – например, СХД позволяет сделать снапшот отдельной ВМ, а не datastore целиком.
Описанная выше традиционная технология хранения ВМ в vSphere 6 по прежнему поддерживается, но в дополнение к ней была разработана концепция Virtual Volumes (VVOL), предполагающая объектное хранение ВМ на массивах, поддерживающих данную технологию, независимо от их типа (блочные или файловые).
VVOL – это объект, содержащий файлы ВМ, виртуальные диски и их производные. СХД с поддержкой VVOL получает возможность непосредственной работы с данными объектами за счет собственных аппаратных ресурсов. Как правило, каждый VVOL имеет уникальный GUID для идентификации. Нет необходимости заранее выделять пространство под VVOL, они создаются автоматом при выполнении операций с ВМ: создание, клонирование, снапшотинг.
vSphere (хосты ESXi и vCenter) ассоциирует с ВМ один или несколько VVOL:
• VVOL данных, соответствующий файлу виртуального диска (.vmdk);
• VVOL конфигурации — небольшая домашняя директория, содержащая метаданные ВМ (включая файл .vmx, файлы дескрипторы виртуальных дисков, log-файлы и т.п.). Данный тип VVOL форматируется в VMFS или NFS, в зависимости от типа СХД (блочная или файловая).
• Дополнительные VVOL могут создаваться для остальных компонент ВМ (например, VVOL для swap-файла или файла ОЗУ ВМ для снапшота) или производных виртуальных дисков (клоны, реплики, снапшоты).
Благодаря VVOL мы получаем гранулярность управления хранилищем на уровне отдельных ВМ и можем напрямую задействовать для этого ресурсы СХД. VVOL позволяют использовать гибкие возможности управления хранилищем на основе политик SPBM. Деление данных ВМ на VVOL нескольких типов позволяет размещать их на хранилища с разным уровнем сервиса: VVOL данных на производительный tier с высоким уровнем сервиса, VVOL с конфигурацией или второстепенным диском ВМ на более простые tier.
Для хранения VVOL не нужны классические LUNы или NFS-шары. VVOL хранятся на условно «сыром» пространстве СХД в объектах, называемых storage container. Storage container-ы это логические единицы пространства массива, их количество и ёмкость определяются конкретной СХД и инфраструктурой. Как минимум 1 storage container должен быть создан на СХД, нельзя растягивать 1 storage container на несколько физических массивов.
Storage container-ы логически группируют VVOL из соображений администрирования или управления: можно создавать отдельные storage container-ы для разных заказчиков, департаментов или групп ВМ. Один storage container может включать несколько профилей сервиса, таким образом, на одном и том же storage container могут размещаться ВМ с разными требованиями к обслуживанию и политиками хранения.
Для интеграции СХД с vSphere, для того, чтобы vCenter и гипервизоры могли работать с VVOL и подключиться к storage container необходимо развертывание и регистрация на vCenter специального storage provider-а на базе VASA (VMware APIs for Storage Awareness) для VVOL, который должен разрабатываться и предоставляться производителем СХД.
Для доступа хостов ESXi к VVOL используются логические прокси ввода-вывода, называемы protocol endpoints. ESXi использует protocol endpoints для установления data-path по требованию между ВМ и её VVOL. Каждый VVOL подключен к определенному protocol endpoints. Как правило, СХД требует небольшое количество protocol endpoints, поскольку 1 protocol endpoints может обслуживать множество ВМ (сотни и тысячи).
VVOL поддерживают основные протоколы СХД: Fibre Channel, FCoE, iSCSI, и NFS, аналогично традиционном хранилищам vSphere.
Для поддержки VVOL необходимо использование HBA-адаптеров и версий драйверов для них, адаптированных к работе с (поддерживающих) VVOL.
На стороне СХД происходит конфигурирование protocol endpoints – по одному или несколько на storage container. Protocol endpoints являются частью СХД и предоставляются хостам вместе с ассоциированными storage container-ами через storage provider. vSphere Web Client отображает protocol endpoints, подключенные к инфраструктуре, через T10-based LUN WWN для блочных массивов и IP/DNS для файловых. Protocol endpoints поддерживают мультипафинг только для SCSI-вариантов подключений (для NFS не поддерживается).
Storage container-ы подключаются к инфраструктуре в виде virtual datastore, эти сущности являются их прямым отображением в vSphere Web Client. Virtual datastore аналогичны обычным datastore vSphere, могут отображать VVOL по именам ВМ, их можно монтировать и размонтировать. Однако их конфигурирование, в т.ч. изменение размера осуществляется на уровне СХД за пределами vSphere. Virtual datastore могут использоваться совместно с обычными VMFS и NFS datastore, а также с Virtual SAN.
Размещение ВМ на virtual datastore (с использованием VVOL) требует наличия политик хранения (SPBM). Политика хранения ВМ (VM storage policy) содержит наборы правил по размещению и качеству сервиса для ВМ и гарантирует их выполнение. При отсутствии конкретных политик система будет использовать политику по умолчанию без ограничений, в этом случае массив самостоятельно выберет оптимальное размещение ВМ на свое усмотрение.
Преимущества и недостатки VVOL
Важными преимуществами технологии являются поддержка создания снапшотов и клонов отдельных ВМ на уровне и за счет ресурсов СХД, а также обеспечение таких сервисов как репликация, шифрование, дедупликация и сжатие отдельных виртуальных дисков. Отдельно следует отметить поддержку SPBM, которая открывает большой потенциал управления хранением ВМ на основе политик.
Продукты VMware поддерживающие VVOL:
• VMware vSphere 6.0.x
• VMware vRealize Automation 6.2.x
• VMware Horizon 6.1.x
• VMware vSphere Replication 6.0.x
Продукты VMware НЕ поддерживающие VVOL:
• VMware vRealize Operations Manager 6.0.x to 6.1.0
• VMware Site Recovery Manager 5.x to 6.1.0
• VMware vSphere Data Protection 5.x to 6.1.0
• VMware vCloud Director 5
Технологии VMware поддерживающие VVOL:
• High Availability (HA)
• Linked Clones
• Native Snapshots
• NFS version 3.x
• Storage Policy Based Management (SPBM)
• Storage vMotion
• Thin Provisioning
• View Storage Accelerator/Content Based Read Cache (CBRC)
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• vSphere Flash Read Cache
• vSphere Software Development Kit (SDK)
• vSphere API for I/O Filtering (VAIO)
• vMotion
• xvMotion
• VADP
Технологии VMware НЕ поддерживающие VVOL:
• Fault Tolerance (FT)
• IPv6
• Microsoft Failover Clustering
• NFS version 4.1
• Raw Device Mapping (RDM)
• SMP-FT
• Storage Distributed Resource Scheduler (SDRS)
• Storage I/O Control
Есть предположение, что VMware делает ставку на VVOL, их развитие, и в скором будущем технология станет совместима со всеми решениями вендора. Возможно, в перспективе VVOL станут основной технологией хранения VMware, которая приведет к постепенному уходу от устаревших традиционных хранилищ и прекращению их поддержки.
На момент публикации статьи из 200 (примерно) производителей систем хранения, продукты которых совместимых с vSphere (согласно VMware Compatibility Guide), лишь 18 поддерживают VVOL. Реальных отзывов о практическом использовании VVOL мне найти не удалось: ни в Интернетах, ни на форуме VMware VMUG (даже на буржуйском). Отсутствие совместимости VVOL c перечисленными выше технологиями на данном этапе заставит многих заказчиков отказаться от VVOL, поскольку несовместимая с VVOL технология или их набор зачастую могут оказаться важнее для многих инфраструктур.
Из этого можно сделать вывод, что теоретически технология VVOL очень интересная и полезная. Однако, на данном этапе её практичность и необходимость внедрения вызывают сомнения. Нужен положительный опыт применения в продакшене и нужна совместимость с другими важными фичами vSphere, пока этого нет.
Спасибо за внимание, на этом цикл статей по технологиям хранения vSphere 6 закончен. В следующей статье будут рассмотрены решения VMware для репликации и аварийного восстановления (DR): vSphere Replication и Site Recovery Manager (SRM).
