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 файле.

Первое, что нам нужно - научиться создавать и управлять виртуальными томами. Управлять созданием и размещением VVols должен не каждый отдельный хост ESXi, а сервер управления vCenter Server, поэтому слой управления (control plane) логично отделить от канала передачи данных (data plane). Кроме того, система управления виртуальными томами может быть реализована каждым производителем систем хранения по-своему, т.е. она должна быть "вне" vCenter Server. Этот программный компонент, обеспечивающий управление виртуальными томами, носит название VASA Provider. В его задачи входит в том числе предоставление информации о топологии и текущем состоянии СХД, а также о поддерживаемых возможностях системы хранения. Посредством vSphere APIs for Storage Awareness (VASA) данные передаются в vCenter Server и хосты ESXi. VASA Provider может быть реализован как “внутри" системы хранения (HP 3Par), так и в виде отдельной виртуальной машины (NetApp FAS). 

Следующей задачей является обеспечение доступа гипервизора (ESXi) к данным, которые находятся внутри VVol. С одной стороны, есть изначально реализованный механизм DataStore, с которым все привыкли работать. С другой стороны, у нас есть множество VVols, которые можно сгруппировать по используемым возможностям системы хранения. Например, одни тома могут быть созданы на дисках SAS и для них настроена аппаратная репликация, другие тома созданы на дисках SSD и для них репликация не используется. Логично объединить такие VVol в группы (Storage Containers) -  это еще один важный термин в новой системе. По своим параметрам Storage Container очень напоминает уже привычный LUN или раздел NFS - там хранятся данные наших виртуальных машин.  Однако, Storage Container отличается тем, что он не является жестко ограниченным ресурсом (как LUN), а представляет собой пулл “грязного” (raw) дискового пространства, на котором можно создать нужные VVols. VASA Provider сообщает всю необходимую информацию серверу vCenter и хостам ESXi. Хост ESXi не может получить доступ к Storage Container через SCSI команды или NFS RPC - вся информация передается только через VASA провайдер. Когда мы хотим создать VVol для виртуальной машины, мы должны сначала подключить новый DataStore, для которого vCenter "предложит" нам (если мы конечно все правильно настроили) предварительно созданный Storage Container. За создание Storage Container отвечает администратор системы хранения, скорее всего, он их создаст несколько (зачем - чуть позже). Всю остальную работу по распределению ресурсов уже берет на себя vCenter и аднимистратор виртуальной инфраструктуры.

Как же хост может получить доступ к данным в 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:

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

Все это, безусловно, начинает играть роль, когда у нас появляется достаточно сложная инфраструктура. Начинать "играть" в 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) - управление ресурсами хранения на основе политик

Понравился пост? Подпишись через RSS, Email или twitter!