Кстати, если вы первый раз читаете про виртуальные тома, то рекомендую начать с вводного материала, где основная идея обрисована крупными мазками.
С релизом 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.
