Начать нужно издалека. Когда разрабатывались средства для создания и управления ИТ-инфраструктурой предприятий, они, конечно же, не были рассчитаны на то, что когда-нибудь мир изменится и виртуализация станет основой ИТ в большинстве крупных компаний. Начав с использования технологий полной и частичной программной эмуляции в продуктах VMware Workstation и ESX Server первых версий, компания VMware (и не только она) заставила производителей процессоров поверить, что их изначально необходимо делать с поддержкой виртуализации, то есть передать часть функций программной платформы на сторону CPU в целях улучшения производительности и простоты управления гостевыми ОС со стороны гипервизора. Так появились технологии аппаратной виртуализации Intel VT и AMD-V, для которых уже не требовалось больших трудозатрат в человеко-кодочасах на написание и модернизацию гипервизора.
Для виртуализации оказались также неудобны физические коммутаторы, поэтому VMware сделала софтверные коммутаторы vSwitch, работающие на уровне ядра VMKernel, которые позволяли гибко управлять политиками VLAN (и другими политиками) на уровне групп портов этих программных сущностей. Потом появился распределенный коммутатор VMware Distributed Switch, который объединял софтовые vSwitch в целях обеспечения централизованного управления сетевой инфраструктурой и снижения трудозатрат на администрирование. В это время производители смекнули, что коммутатор можно запихнуть в сетевую карту и сделали технологию SR-IOV, которая также представляет собой изменения видения вендоров "железа" под воздействием популярности виртуализации (технология поддерживается и в vSphere 5.1). Когда стало понятно, что традиционной концепции VLAN не хватает, поскольку появился новый тип бизнеса IaaS - придумали технологию VXLAN, которая также требует поддержки со стороны аппаратного обеспечения.
С точки зрения хранилищ, компания VMware тоже внесла инновации в традиционный подход - она предложила передать часть функций по управлению объектами виртуальной инфраструктуры на сторону дисковых массивов. Так появился механизм VAAI, который, будучи поддерживаемым со стороны вендоров СХД, позволяет в разы увеличить производительность некоторых операций в виртуальными машинами на хранилищах, а значит, это создает вендорам массивов дополнительное преимущество. Поэтому и на этот раз им пришлось следовать за трендом и реализовать поддержку VAAI в своих хранилищах.
Теперь VMware увидела новую проблему, мешающую движению виртуализации вперед: логическая единица хранилищ - LUN.
Когда создавались дисковые массивы для традиционных физических серверов, производители справедливо полагали, что LUN будет использоваться либо одной ОС как диск, либо небольшим кластером как общий диск. Потом пришла VMware и адаптировала концепцию LUN к своему продукту, сделав кластерную файловую систему VMFS, которая будучи развернута в рамках одного или нескольких LUN позволяет предоставить одновременный доступ к их содержимому со стороны нескольких хостов ESX / ESXi. Эта файловая система зарекомендовала себя очень хорошо, и больших неудобств пользователи не испытывали до того, как их инфраструктура становилась очень крупной.
В большой виртуальной инфраструктуре присутствуют сотни хранилищ VMFS, созданных поверх LUN, где лежат виртуальные машины с различным уровнем требуемого сервиса и политик. Проблемы начинаются с того, что система хранения не знает о том, что на ее LUN находятся виртуальные машины. Например, синхронная репликация на уровне массива может делаться только на уровне LUN, хотя с данного тома VMFS требуется реплицировать не все ВМ, которые могут быть с различным уровнем критичности. То же самое касается снапшотов и снапклонов уровня массива, а также технологий резервного копирования. Конечно же, все это можно обойти, сделав репликацию и резервное копирование с помощью Veeam Backup and Replication или vSphere Replication и vSphere Data Protection, однако это задействует ресурсы хоста и не настолько производительно. Можно сделать дизайн инфраструктуры из расчета 1 машина на LUN, однако это создает сложности управления томами VMFS (управление путями, политики и т.п.), да и зачем вообще тогда нужна VMFS?
Поэтому VMware решила пойти в традиционном направлении: "заставить" производителей массивов считаться с виртуальными машинами. Так появилась концепция vVOL (она же VM Volumes), которая увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore".
На этой картинке мы видим, что в традиционной модели, которая есть сейчас, N хост-серверов создают с M томами дискового массива N x M связей, которые создают большую нагрузку на дисковые ресурсы. Например, в концепции VDI, где десктопы используют тонкие диски, растущие по мере наполнения их данными, операции с одним десктопом (выделение блоков) влияют на производительность всего тома и все виртуальных машин на нем, поскольку требуются операции с метаданными тома VMFS. VMware решила устранить эту проблему на корню, взявшись за то, чтобы массив позволял оперировать с отдельной виртуальной машиной на хранилище, не затрагивая остальные ВМ на нем.
Таким образом, vVOL является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN). То есть, vVOL - это низкоуровневое хранилище одной виртуальной машины, с которым будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины нужно хранить как отдельную сущность уровня хранилищ в виде vVOL, тогда с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.
Выглядит все это так:
Но как же быть, например, с тем, что один хост ESXi поддерживает до 256 LUN, с которыми он может взаимодействовать? Очень просто - в массиве должно быть устройство, называемое "IO Demultiplexer" или "IO Demux", которое представляет собой логический канал ввода-вывода, предоставляющий доступ ко всем дисковым устройствам, где будут размещены тома vVOL виртуальных машин. Такое устройство должно реализовывать политики доступа по нескольким путям уже в самом себе, а за ним могут находиться тысячи виртуальных машин. Очевидно, что это устройство нуждается в резервировании. Самое интересное тут то, что в рамках данной концепции нивелируются различия между NAS и блочными FC или iSCSI-хранилищами в плане работы с дисками ВМ.
Здесь также появляется еще одна проблема - как быть, если администратор VMware vSphere может создавать бесконтрольно виртуальные машины, оперируя уровнем хранилищ, а администратор систем хранения так об этом и не узнает? Для этого есть концепция емкостных пулов (Capacity Pools), которые создает администратор СХД, определяя уровень доступной емкости в пуле и политики, ограничивающие спектр низкоуровневых операций в этом пуле.
Для того, чтобы удовлетворять показателям уровня обслуживания (QoS), была придумана концепция профилей хранилищ (Profiles), на уровне которых администратор может задавать требуемые параметры производительности и политики данных, которые могут быть применены как на уровне vVOL, так и на уровне Capacity Pool.
Текущие техники оптимизации хранилищ, такие как Storage DRS, SIOC, VASA и VAAI - это шаги в правильном направлении, однако их недостаточно, чтобы обеспечить максимальный уровень гибкости на уровне отдельных виртуальных машин в большой инфраструктуре. Поэтому концепция vVOL может помочь это сделать в будущем. Все это органично вписывается в концепцию программно-определяемых хранилищ (Software Defined Storage), по аналогии с Software Defined Networking, обе которых являются частями глобальной концепции Software Defined Datacenter.
Ну и на закуску - демка с VMworld 2012 функциональности vVOL, где происходят следующие вещи:
Механизм vSphere Data Protection хочет сделать резервную копию ВМ.
В качестве хранилища используется EMC VNXe, в котором есть поддержка прототипа VM Granular Storage.
ВМ находится в "Capacity Pool" на томе "Virtual Volume", для которого определены политики, в том числе "VM-accelerated snapshots".
В экспериментальной сборке vSphere используется VM Granular Storage API, с помощью которого делается высокопроизводительный Virtual-Volume level snapshot в целях дальнейшего резервного копирования машины
Все это выглядит круто, осталось только производителям дисковых массивов вздохнуть и взяться за новую трендовую концепцию.
RSS
