Vmware vvol что это

Обновлено: 06.07.2024

четверг, 26 февраля 2015 г.

VMware Virual Volumes (VVols)

Разбираясь в старых бумагах, нашел свой черновик с записями про VVol - тогда информация про технологию только начала появляться. Не буду скрывать, на тот момент у меня было очень много вопросов к выбранному пути развития (назвать полноценной реализацией это еще было сложно). Почему записи остались только в черновике - уже и не вспомню, перечитал, немного скорректировал и пусть будут теперь здесь.

Наверняка, за прошедшее с момента первого упоминания время, все не по одному разу слышали что VVols это хорошо, удобно и круто. Но почему?

Подход VMware к развитию инфраструктуры виртуализации понятен - "виртуальный" администратор (он, конечно вполне реальный, но занимается только виртуализацией) должен иметь возможность максимально просто, удобно и без привлечения других сотрудников разворачивать необходимые бизнесу сервисы. И основной упор должен быть именно на "без привлечения других" - именно это чаще всего и будет "бутылочным горлышком" в скорости развертывания. А следовательно, участие администраторов, отвечающих за системы хранения и сетевую инфраструктуру, должно быть минимальным - желательно ограничиться только начальной настройкой.

Можно конечно все функции управления "загнать" в vCenter с помощью плагинов, тогда управлять всем оборудованием можно будет из "одного окна". Это вполне удобно, когда у нас небольшая (и сравнительно простая инфраструктура), но как только появляется несколько систем хранения, знаний специалиста по VMware может оказаться недостаточно и, хотя настроить все можно из одной консоли, но занимаются этим снова разные сотрудники.

Помимо того, чтобы упростить развертывание (и обслуживание) виртуальных машин, стоит еще и задача не вносить в гипервизор излишний функционал, который утяжеляет и усложняет работу. Часть функционала дисковых систем можно благодаря VAAI (vStorage APIs for Array Integration). В частности, поддержка Clone Blocks/Full Copy/XCOPY примитива позволяет копировать данные на уровне СХД, не передавая их гипервизору и обратно на массив. Несмотря на все плюсы, VAAI не дает существенных преимуществ как в момент непосредственного развертывания виртуальных машин, так и не слишком помогает в управлении жизненным циклом системы в разрезе конкретных виртуальных машин.

Что сейчас происходит при создании виртуальной машины? Администратор выбирает подходящий datastore - не только исходя из свободного объема, но и в зависимости от того, какая нагрузка будет на виртуальной машине, насколько уже сейчас нагружен тот или иной datastore, а также он должен принимать во внимание поддерживаемый функционал системы хранения. Если датастор еще не создан, то мы обращаемся к администраторам СХД, которые создают LUN, настраивают доступ к хостам. Не исключено, что придется также вносить изменения в сеть хранения (зонирование). После развертывания виртуальной машины, нам нужно следить за производительностью дисковой системы. Можно настраивать QoS на разных уровнях и, скорее всего, также потребуется привлечь администратора СХД.

Можно было бы предположить экстремальное решение - создать достаточно большое число LUNов и распределить по ним виртуальные машины. Ведь чем больше будет число созданных LUN, тем большую гибкость мы получаем! Идеальная ситуация - создать по одному LUN для каждой виртуальной машины, тогда мы можем очень гибко управлять ими. С другой стороны, повышается overprovisioning и управлять системой с большим числом разделов - это настоящий ад для администратора! Да и ESXi имеет ограничение на число подключаемых LUN, что тоже требуется учитывать при планировании системы.

Таким образом, требовалось создать такое решение, которое бы позволило:

снять нагрузку с администраторов СХД (создал раздел из SSD дисков, раздел из SAS дисков и раздел из NL SAS дисков - и дальше пусть специалисты по виртуализации сами с ними разбираются)
обеспечить максимальную гибкость для управления каждой из виртуальных машин
автоматизировать большинство операциq
не перегружать гипервизор (ESXi) и систему управления (vCenter) аппаратно-зависимыми модулями
получить унифицированное решение, которое не "привязано" к конкретным системам хранения

Виртуальные разделы (Virtual Volumes, VVols) и были предложены в качестве такого решения. По сути своей, VVol это еще один уровень абстракции, который отделяет систему хранения данных от гипервизора. Давайте в этом разрезе и посмотрим на основные компоненты решения.

Прежде всего, сам виртуальный раздел Virtual Volume (VVol) - это своего рода контейнер, в котором хранится информация, необходимая виртуальной машине - это может быть конфигурация, swap или непосредственно данные, которые мы привыкли обычно видеть в vmdk файле. Любой элемент виртуальной машины, который ранее требовал создания файла в vmfs (или nfs), теперь является отдельным виртуальным томом. Каждая виртуальная машина включает несколько VVols, количество которых меняется, в зависимости от состояния машины (наличия снимков и т.п.):

1 VVol для конфигурации виртуальной машины (метаданные - .vmx файл, дескрипторы виртуальных дисков, логи и т.п.)
1 VVol для каждого виртуального диска (.vmdk)
1 VVol для swap (если используется)
1 VVol для снапшота каждого диска + 1 VVol для снимка памяти

VVol это только некий виртуальный контейнер - это не LUN (по крайней мере, он им не обязан быть) и не точка монтирования NFS - реализация VVol на уровне системы хранения остается в руках производителя СХД. Для гипервизора же это просто абстрактный объект с данными, с которыми можно работать по SCSI протоколу, как и с любыми другими данными, находящимися в vmdk файле.

Как же хост может получить доступ к данным в VVol? Чтобы реализация в гипервизоре не зависела от реализации VVol в системе хранения, нужен универсальный механизм реализации канала передачи данных. Protocol Endpoint (PE) является своего рода proxy для перенаправления операций ввода-вывода от гипервизора на конкретный VVol. PE это либо специальный LUN (если VVol находится на СХД, подключенной через блочный протокол), либо точка монтирование NFS (если VVol находится на NFS системе хранения). Один PE может служить прокси для множества виртуальных томов.

Обратите внимание, что уже это существенно упрощает администрирование - нам достаточно подключить только один LUN на сервер ESXi, чтобы получить возможность управлять множеством VVols. Protocol Endpoint поддерживает multipath для блочных протоколов, но для NFS поддержки multipath пока нет (как нет и поддержки NFS v4.1). Для NFS отказоустойчивость можно реализовать за счет увеличения числа PE для данного Storage Container. Хотя PE может отвечать только за одну систему хранения, но на одной СХД мы можем создать столько PE, сколько нам необходимо, при этом подразумевается, что каждый PE обеспечивает доступ ко всем Storage Container на данной системе хранения, хотя это и не является обязательным требованием.

Так как количество используемых Protocol Endpoint существенно меньше, чем количество подключаемых LUN (до перехода к использованию VVol), технически мы можем подключить к нашей инфраструктуре заметно больше дисковых ресурсов, что может быть актуально в свете повышения максимального количества хостов в кластере vSphere 6.

Все перечисленные компоненты (VVol, Storage Container, VASA Provider, Protocol Endpoint) обеспечивают управление виртуальными томами и доступ к данным на них. С их помощью мы можем упростить задачу распределения пространства на СХД для виртуальной инфраструктуры.

Какие еще плюсы мы можем получить от нового уровня абстракции? Благодаря VASA Provider, мы знаем о поддерживаемых возможностях системы хранения данных для VVols, размещенных на тех или иных Storage Containers, а значит мы можем использовать эту информацию при размещении новых VVols. Создавая Storage Container, администратор системы хранения фактически определяет Storage Capability - те возможности СХД , о которых VASA Provider сообщает серверу vCenter. Они могут включать в себя такие параметры как: уровень RAID, поддержку thin provisioning, тип используемых дисков, поддержку zero detect, аппаратную поддержку снапшотов и т.д. Все эти атрибуты затем могут быть использованы администратором виртуальной инфраструктуры для определения политик - Storage Policies. При создании виртуальных машин, администратор выбирает, какую политику применить для размещения дисковых ресурсов. В ходе жизненного цикла виртуальной машины также учитываются назначенные политики. Все это и составляет систему управления виртуальными машинами на базе политик (Storage Policy Based Management, SPBM).

Итак, как выглядит процесс "запуска" системы для использования VVols:

настраиваем VASA Provider (либо интегрирован в СХД, либо отдельная виртуальная машина)
администратор СХД выделяет ресурсы (Storage Containers) на системе хранения
ищем существующие Protocol EndPoint (создаются вместе с Storage Container или VASA Provider делает это автоматически для нас)
создаем новые DataStore для созданных Storage Containers
настраиваем политики (Storage Policies)
создаем новую вирутальную машину

Конечно, VVol на начальном этапе развития не лишены определенных недостатков. Пока еще:

нет поддержки NFS v4.1
нет поддержки Storage DRS
нет поддержки Site Recovery Manager (SRM)

Единая терминология, независимо от способа подключения СХД
Возможность делегировать СХД выполнение многих операций над дисками виртуальной машины
Возможность предоставлять сервисы СХД на уровне отдельной виртуальной машины
Управление ресурсами на основе политик
Легкость администрирования

Все это, безусловно, начинает играть роль, когда у нас появляется достаточно сложная инфраструктура. Начинать "играть" в VVols, имея одну систему хранения с одним типом дисков и 3-4 сервера, на мой взгляд, можно только для самообразования. Практической пользы вы, уверен, на такой конфигурации не увидите.

Virtual Volume (VVol) - виртуальный раздел/том
VASA Provider - реализация слоя управления для VVol
vSphere APIs for Storage Awareness (VASA) - программный интерфейс для унификации взаимодействия с СХД
Storage Container - контейнер, в котором создаются VVols
Protocol Endpoint (PE) - прокси для доступа к самим данным
Storage Capability - поддерживаемые возможности СХД, которые можно использовать в создаваемых политиках
Storage Policies - политики, назначаемые виртуальным машинам, на основе которых происходит выбор подходящих дисковых ресурсов
Storage Policy Based Management (SPBM) - управление ресурсами хранения на основе политик

Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.

Описание технологии 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).

vVols виртуализирует массивы SAN/NAS, обеспечивая более эффективную операционную модель, которая оптимизирована для виртуализированных сред и ориентирована на приложения, а не на инфраструктуру.

Обзор решения Virtual Volumes (vVols)

vVols — это платформа интеграции и управления, которая виртуализирует массивы SAN/NAS, обеспечивая более эффективную операционную модель. Она оптимизирована для виртуализированных сред и ориентирована на приложения, а не на инфраструктуру.

Уникальная особенность vVols заключается в использовании общей операционной модели хранилища с vSAN, лидирующим на рынке решением для гиперконвергентной инфраструктуры. Оба решения используют управление хранилищем на основе политик (SPBM), чтобы исключить выделение ресурсов хранения, а также описательные политики на уровне виртуальной машины или VMDK-диска, которые можно применить или изменить за считаные минуты. SPBM ускоряет операции в хранилище и снижает потребность в специализированных навыках для инфраструктуры хранения данных.

Преимущества решения vVols

Эффективный контроль

С помощью vVols намного удобнее предоставлять и обеспечивать нужные уровни обслуживания хранилища в соответствии с конкретными потребностями отдельных виртуальных машин. Благодаря эффективному контролю над ресурсами хранилища и службами обработки данных вплоть до уровня ВМ администраторы виртуальной инфраструктуры могут создавать оптимальные сочетания ресурсов и обеспечивать необходимые уровни обслуживания хранилища. Избыточное выделение ресурсов полностью устраняется, так как каждая ВМ потребляет именно необходимый ей объем ресурсов.

Оптимизированные процессы хранения

Решение vVols значительно упрощает управление с помощью существующей эксплуатационной модели для администраторов хранилища и виртуальной инфраструктуры. vVols помогает отделить представление ресурсов хранения от их потребления виртуальными машинами. В модели программно-определяемого хранилища VMware с использованием vVols администраторы хранилища могут настроить хранилище данных vVols, которое определяет объем ресурсов и службы обработки данных. Администраторы виртуальной инфраструктуры затем используют возможности, доступные в хранилище данных, для создания политик. Для соответствия изменяющимся уровням обслуживания достаточно лишь изменить политики. Администраторы хранилища отвечают за первоначальную настройку, а затем администраторы виртуальной инфраструктуры могут обслуживать среду самостоятельно.

Гибкость выбора

vVols — это отраслевая инициатива, в рамках которой ИТ-отделы могут использовать уникальные возможности имеющихся хранилищ и без прерывания работы перейти к более удобной и эффективной эксплуатационной модели. ИТ-отделы также могут управлять разнородными хранилищами, используя единую плоскость управления.

Экосистема партнеров по vVols

Экосистема партнеров по решениям для хранения

Решение vVols создано специалистами VMware в сотрудничестве с участниками экосистемы партнеров по решениям для хранения при разработке новой эксплуатационной модели хранения, ориентированной на использование виртуальных машин. В работе над vVols участвовали крупнейшие поставщики. Эта экосистема продолжает расти и укрепляться, предлагая решения с поддержкой vVols.

vVols также интегрируется с API-интерфейсами vSphere для фильтрации ввода-вывода, что обеспечивает поддержку программных служб обработки данных. Первоначальные предложения партнеров включают в себя решения для кэширования и репликации.

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

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

С релизом vSphere 6 VMware вывела на рынок одну из наиболее обсуждаемых технологий хранения — Virtual Volumes (VVOL). Идея в том, чтобы управлять политиками хранения на уровне виртуальных машин, а не datastore. Это заметный прогресс в управлении внешними хранилищами и VM по сравнению с vSphere 5.5. Наверняка это побудит многих вендоров анонсировать поддержку виртуальных томов в своих устройствах и постараться прийти первыми к водопою.

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

Но дьявол кроется в деталях. В этой статье мы углубимся в технологию VVOL, разберемся, зачем нужны виртуальные тома, и сформулируем пять важных вопросов перед внедрением.

Эволюция datastore

Вне зависимости от типа системы хранения (блочная или файловая), виртуальные машины vSphere всегда хранятся в логическом объекте-хранилище, именуемом datastore.

Хранилища NFS используют собственную файловую систему, в то время как блочные устройства полагаются на vSphere VMFS. Проприетарная файловая система VMware становится все лучше с каждым релизом vSphere и сейчас уже достигла высокой предельной емкости (с VMDK размером 62 Тб) и производительности благодаря различным оптимизациям вроде VAAI.

Когда в качестве хранилища используются разделяемые внешние устройства, datastore практически всегда строится из одного большого LUN. При этом такой большой раздел является самым маленьким логическим элементом в СХД. На невиртуализованных системах детализация на уровне LUN была вполне приемлемой, так как на каждый том приходился всего один сервер. Можно было легко оперировать политиками сервиса с использованием LUN.

С приходом виртуализации соотношение между LUN и виртуальными машинами изменилось: теперь на один LUN/datastore приходится множество гостей, каждый из которых вынужденно получает одинаковый уровень сервиса.

Подобная архитектура продемонстрировала целый ряд проблем. QoS и другие политики обслуживания могли быть применены только на уровне дискового тома, даже с учетом блочного тиринга (block-level tiering). Таким образом, любое перемещение «горячих» данных происходило бы для всех VM на этом хранилище. До недавнего времени пользователи VMware вынуждены были использовать опции вроде DRS, чтобы как-то распределять нагрузку на системы хранения.

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

Даже штатно поддерживающие QoS-системы не в состоянии были воспользоваться преимуществами VM-приоритезации, потому что для этого требовалось размещать виртуальную машину на собственном дисковом томе. Стратегия «одна VM — один LUN» себя не оправдывала, потому что ESXi ограничен 256 LUN на хост. Не удивительно, что сценарии с индивидуальными LUN не вызвали у общественности особого энтузиазма.

Заря VVOL

Для решения проблемы VMware изменила подход к работе с дисками VM, в результате чего появилась технология виртуальных томов.

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

VVOL предлагает несколько новых концептов, которые помогут понять суть новинки:

Storage provider (SP). Выступает в роли интерфейса между гипервизором и внешним хранилищем. Работает отдельно от data path и использует уже существующий протокол VASA; передает всю информацию о хранилище и VVOL. Для работы виртуальных томов требуется VASA 2.0.
Storage container (SC). Это просто пул хранения на внешнем массиве, который каждый вендор реализует по-своему. В перспективе из нескольких таких пулов можно будет собрать логический том для размещения VVOL. Вообще, надежность и устойчивость хранилищ VVOL в немалой степени зависят от реализации Storage container.
Protocol endpoint (PE). Отвечает за предоставление виртуального тома гипервизору. Реализован как обычный LUN, хотя и не хранящий никаких данных. Можно сказать, что это некий пропускной шлюз для доступа к подключенному VVOL. Если вы знакомы с семейством EMC VMAX, то PE аналогичен гейткиперу от EMC.

Большая часть работы по поддержке VVOL ложится на вендора хранилища. VMware разработала спецификацию, а ее реализация отдана на откуп производителям железа. Учитывая это, предлагаю вашему вниманию пять вопросов, на которые необходимо ответить перед приобретением хранилища под VVOL:

Сколько виртуальных томов поддерживается системой? Как мы уже знаем, одна VM использует несколько VVOL. Это значит, что реальная вместимость виртуальных машин значительно ниже заявленного числа томов. Это вполне может стать проблемой на массивах all-flash, где плотность I/O предполагает размещение очень большого числа виртуальных машин.
Какие возможности поддерживаются на уровнеVM? Сейчас не много информации касаемо поддерживаемых для VM сервисов, но почти наверняка будут QoS, снэпшоты и репликация. Здесь все в значительной степени зависит от вендора СХД: добавит ли он все разработанные VMware возможности.
Можно ли использовать хранилище в смешанном режиме? VVOL не могут быть вариацией на тему «пан или пропал». Производитель должен продемонстрировать, что использование виртуальных томов никак не ограничивает работу «обычных» LUN на том же хранилище.
Каким образом поддерживаетсяVASA? Для работы VVOL потребуется VASA версии 2.0, выступающий в роли своеобразного мостика между подсистемой хранения гипервизора и железкой. Через этот канал происходит настройка виртуальных томов и сбор различной системной информации. Некоторые вендоры встраивают поддержку VASA API в само устройство, но порой предлагается поставить дополнительное ПО. Второй вариант с дополнительным софтом выглядит менее предпочтительно из-за лишней сложности архитектуры и потенциально более низкой стабильности.
Нужно ли платить за VVOL отдельно? Кажется очевидным, но многие вендоры наверняка захотят продать новую «фишку» вместо просто выпуска обновления микрокода с новыми возможностями. Например, VMware планирует отдельно лицензировать VVOL для собственного решения по хранению данных VSAN. Так что не удивляйтесь, если ваш вендор решит немного отбить вложенные в поддержку VVOL средства.

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

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

вторник, 10 февраля 2015 г.

Техническое описание VVol

Первое что хотелось бы отметить - технология называется VVol, не vVol, Vvol и прочее (от переводчика).

Гипервизор позволяет реализовать автоматизацию СХД от приложения, так как:

Знает все требования приложений в реальном времени;
Является элементом пути в операции ввода-вывода;
Видит все нижележащие СХД;
Может динамически настраивать СХД;
Независим от аппаратного обеспечения.

Традиционная модель - длительные циклы предоставления ресурсов, управление LUN, сложные и частые миграции данных.

Автоматизация от приложения - динамическое предоставление ресурсов СХД по мере необходимости. Контроль уровня предоставления сервиса на уровне отдельной ВМ. Общее управление разными устройствами.

vSphere Virtual Volumes

Виртуализирует SAN и NAS устройства;
Виртуальные диски нативно предоставляются массиву;
Позволяют выполнять операции на уровне отдельной ВМ используя функции СХД;
Управление хранилище на основе политик (SPBM, Storage policy-based management) позволяет автоматизировать потребление ресурсов при масштабировании;
Широкая поддержка основнымит производителями СХД;
Поставляется с vSphere.

Пять типов объектов VVols: Config, Data, MEM, SWAP, Other;
Отсутствие необходимости использования СХД (VMFS отходит в историю);
Объекты виртуальной машины хранятся нативно на СХД;

Логическая конструкция массива для группирования виртуальных томов;
Обычно определяется администратором СХД на самом массиве для определения ёмкости массива и его ограничений;
Ёмкость определяется физической ёмкостью массива.

Размер контейнера основан на ёмкости массива;
Максимальное количество контейнеров зависит от массива;
Размер контейнера может быть расширен;
LUN требует файловой системы, стандартизация размера LUN требует большего их количества.

Точка доступа реализовывающая коммуникацию между ESXi и СХД;
На данный момент поддерживаются: iSCSI, NFS v3, FC, FCoE;
Для каждой конечной точки единовременно поддерживается какой-то один обозначенный протокол;
Конечная точка получает SCSI либо NFS команды;
Контейнера массива - для большого количества метаданных и данных ВМ.

Возможности массива и политики хранения ВМ (Storage Capabilities и VM Storage Policies)

Являются функциями массива и требованиями ВМ к этим функциям, соответственно. Требования могут быть удовлетворены возможностями, предоставляемыми массивом;
Возможности массива определяют что может предоставить массив в ответ на требования ВМ;
Политики хранения ВМ являются компонентом хранилища на основе политик
Представленные возможности - функции и сервисы массива, предоставленные гипервизору через VASA API;
Управляются на уровне виртуального диска ВМ
Используют концепцию соответствия для контроля предоставляемого уровня сервиса.

Разгрузка операций: разворачивание, удаление, клонирование (полное и связанных), снепшоты;
Снепшоты: управляемые ESXi или массивом.

В данной версии SRM не поддерживает VVol, но будет в следующей.

В будущих версиях VVol позволит пулу массива распространяться между физическими массивами.

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