Компания VMware завершила длительную и кропотливую работу над новой концепцией СХД выпуском в свет vSphere 6.0 с поддержкой программных хранилищ и структуры Virtual Volumes (VVols), о которых и будет мой сегодняшний пост. Начну с официального определения от производителя: «Virtual Volumes — это новая структура интеграции и управления, обеспечивающая виртуализацию массивов SAN и NAS благодаря созданию эффективной эксплуатационной модели, которая оптимизирована для виртуализированных сред и ориентирована на особенности приложения, а не инфраструктуры».
Представляется, что в будущем Virtual Volumes заменят VMFS, поскольку VMware никогда не распыляется на поддержку двух различных вариантов для ключевых компонентов инфраструктуры, то есть на двойную работу. Сперва они упразднили ESX спустя несколько лет после выхода ESXi, затем – VSA, выпустив на замену VSAN, а теперь пытаются перевести пользователей с vSphere Client на Web Client; допускаю, что в какой-то момент они могут решить перейти от vCenter Server на Windows к VCSA. Поэтому можно предположить, что аналогичная судьба ждет VMFS, от которой откажутся в пользу VVols – разумеется, после того, как они достигнут определенной стадии «зрелости» и будут приняты к использованию большинством пользовательской аудитории. Подтверждением этой мысли является и тот факт, что поддержка VVols включена во все редакции vSphere.
Выясним, однако, для начала, почему эксперты советуют не торопиться с внедрением Virtual Volumes.
Это достаточно серьезный резон, особенно для крупных организаций, у которых репликация массивов СХД является основополагающей в их стратегии защиты и восстановления данных. Поддержка репликации хранилища на сегодня не заявлена в спецификации VASA 2.0, так что SRM и vMSC не работают с VVols – для кого-то этого будет достаточно, чтобы не читать дальше. Замечу, однако, что хотя VMware и не поддерживает репликацию массивов СХД, некоторые производители планируют или уже обеспечивают такую поддержку, так что некий workaround существует (но его все же нельзя использовать с SRM или vMSC до тех пор, пока VMware не включит его в спецификацию VASA).
Да-да, невзирая на годы, затраченные на разработку, это лишь версия 1.0, и, как первая версия любого продукта, она подвержена «болезни роста», что может заставить пользователей пока подождать. К тому же наблюдается определенный недостаток поддержки функциональной совместимости (а именно — репликации); что же касается поддержки со стороны собственно массива СХД (что тоже потребовало значительных трудозатрат со стороны производителей) – она также выходит в начальной версии. Среди производителей, участвовавших в разработке архитектуры – всеми уважаемые HP, NetApp и Dell, которые занимались этим несколько лет, поэтому именно их решения, скорее всего, будут наиболее зрелыми в плане готовности к использованию.
На текущий момент есть четверка производителей, у которых в VMware Hardware Compatibility Guide заявлена поддержка Day 1 для VVols. Этот список, разумеется, будет расширяться по мере того, как другие компании-производители будут завершать разработку и проходить сертификацию VMware для VVols; сейчас производители заняты также и расширением спектра поддерживаемых возможностей для VVols.
Помните, как это было, когда вы впервые рассказали сетевому администратору про vSwitch и озвучили требования к сети для vSphere? Без сомнения, человек почувствовал, как власть ускользает из его рук. Возможно, вам даже не удалось разойтись миром:). Аналогичный сценарий вполне вероятен и сегодня, когда вы заведете речь о VVols в разговоре с администратором СХД. Впрочем, как показала история, «сопротивление бесполезно!» — и как тогда администраторы vSphere выиграли борьбу с сетевыми админами, так и теперь они, скорее всего, победят и администраторов СХД. Чтобы обойтись без драки, советуем привлечь их к сотрудничеству, разъясняя, что же такое VVols, как это работает и как это упростит их жизнь от того, что взаимоотношения виртуальной инфраструктуры и СХД значительно улучшатся.
Пока еще нет достаточных статистических данных по производительности, чтобы посмотреть, насколько хорошо VVols масштабируемы в сравнении с VMFS, т.е. будут ли они в этом отношении лучше, хуже или такими же. Предполагаю, что это решение примерно аналогично VMFS в смысле масштабируемости, или даже чуть лучше нее. Строго говоря, VVols разрабатывались не как средство увеличения производительности относительно VMFS, а как совершенно новая архитектура программного хранилища, новый подход, ориентированный на виртуальную машину как на единицу хранения в массиве СХД. Это же можно сказать и относительно сравнения RDM и VMFS – речь шла не о повышении производительности, и VMware доказала, что производительность у них одинаково высока, поэтому я вполне допускаю, что подобное произойдет и с VVols. Есть сведения, что в настоящий момент VMware выполняет тесты на сравнение производительности, и результаты, надеюсь, скоро будут доступны.
VMware достаточно долго пыталась мимикрировать под данную функциональность внутри vSphere, предлагая «тонкие диски», снапшоты виртуальных машин, Storage vMotion, Storage I/O Control, и т.д., и т.п. Жизнь многих из этих фич в будущем прекратится, поскольку внедрение VVols опять же приведет к использованию массива СХД. То есть процесс снятия снапшота виртуальной машины автоматически превратится в создание снапшота массива СХД; аналогично, если для динамического выделения ресурса хранения сейчас применяются «тонкие диски», то в будущем этим будут заниматься массивы СХД. Это даже к лучшему, ибо они позволяют выполнять эти операции быстрее и эффективнее. Тем не менее, чтобы использовать данные функции, для массива СХД потребуются соответствующие лицензии. Одни производители, возможно, включат эту функциональность в основной набор поддерживаемых операций, а другие – нет, поэтому следует уточнить стоимость поддержки указанных функциональных возможностей в вашем конкретном случае.
Внедрение VVols коснется архитектуры процесса резервного копирования “Direct to SAN”, поскольку теперь он имеет дело с Protocol Endpoint и VASA storage provider. На данный момент еще нет сведений о массовой поддержке данного подхода со стороны поставщиков решений резервного копирования, но в скором будущем они, конечно, появятся. Узнайте у вашего поставщика, как скоро ваше решение для резервного копирования будет поддерживать VVol. Например, Veeam поддержал vVol в выпущенном недавно обновлении Veeam Availability Suite 8.0 Update 2 (подробнее можно прочитать здесь).
Теперь о позитивном.
Хотя список причин, по которым можно не торопиться с внедрением VVols, выглядит достаточно серьезно, во всех остальных отношениях VVols являются оптимальным архитектурным решением для СХД в среде vSphere и предоставляют множество преимуществ. Так, аналогично тому как VSAN позволяет внедрить Storage Policy Based Management (SPBM) на уровне виртуальных машин, VVols дают ту же возможность для shared storage – и преимущества, конечно, не ограничиваются лишь этим.
Поэтому теперь предлагаю рассмотреть список аргументов «За скорейшее внедрение Virtual Volumes»:
Совершенно необязательно «окончательно и бесповоротно» переходить на VVols — виртуальные тома можно использовать и наряду с VMFS или NFS. VVols — это просто еще одна опция для вашей архитектуры. Можно легко перемещать виртуальные машины с VMFS/NFS на VVols и обратно, используя Storage vMotion, так что вы можете настроить Storage Container на виртуальный том и создавать или мигрировать машины, как вам удобно.
Перешли с ESX на ESXi позже других и запоздало изучали отличия и нюансы работы? Долго не могли привыкнуть к vSphere Web Client? Давайте оставим в прошлом эти «грабли» и не будем ждать, что VVols придется осваивать в «добровольно-принудительном» режиме. Чем раньше вы приступите к ознакомлению с новинкой, тем уверенней вы будете себя чувствовать, когда другие еще только начнут свои первые робкие шажки в этом направлении. А выступать в роли эксперта – почетно и приятно, ведь здорово, когда людям пригодились знания, которые ты им передал.
Помните, в vSphere 5.0, когда VMware внедрила автоматический возврат неиспользуемого места на диске командой UNMAP, это приводило к ошибкам, и в результате пришлось отказаться от автоматизации этой операции и делать это вручную до сей поры, но теперь автоматизация снова с нами – благодаря VVols. Массив СХД, имея полное представление о удалении или перемещении виртуальной машины, сразу после этого может выполнить возврат более неиспользуемого места. Больше не требуется вручную запускать esxcli — с VVols все происходит автоматически. Если нужен возврат места с еще более высоким уровнем гранулярности, то можно еще выполнить на гостевой ОС команду UNMAP. Такой подход позволит повысить эффективность использования массива СХД.
Если ваш массив СХД поддерживает VVols, нет нужды переходить на другую редакцию vSphere – с VVols работают все редакции. Настроить VVols несложно, так что это не должно стать сдерживающим фактором, как раз наоборот.
Не отставайте от пользователей VSAN, которые уже вовсю применяют Storage Policy Based Management. Этот подход к управлению инфраструктурой позволяет вам настраивать политики управления СХД в соответствии с функциональными возможностями массива СХД – таким образом, использование ресурсов и возможностей вашей СХД становится ориентированным непосредственно на виртуальные машины. Управление на основе политик позволяет назначать ресурсы в точном соответствии с потребностями виртуальной машины, а также следить за соблюдением этих назначений. Компания VMware потратила много сил и средств на создание этого механизма управления – и все для того, чтобы обеспечить максимальную эффективность и гибкость при выделении ресурсов массива СХД для виртуальных машин.
Массив СХД – это, по сути, механизм для выполнения операций чтения\записи, а также софт, предназначенный для работы именно с этим механизмом. Вместе они представляют собой мощный инструмент для работы с данными. Использование VMFS и СХД vSphere предполагает, что имеется еще некий «посредник», который указывает собственно массиву СХД, что и когда делать. Разумеется, такая цепочка – не самый эффективный метод работы. Избавившись же от такого «посредника» и дав в распоряжение массиву СХД возможности самоконтроля, мы получили систему с наибольшей эффективностью и оптимальным результатом. Заметим также, что возможности массива СХД куда шире, чем сопоставимой СХД vSphere, плюс к тому, у массива всё куда прозрачнее относительно ресурсов СХД, нежели у vSphere. Естественно, что такие вещи, как как динамическое выделение ресурса (thin provisioning), снапшоты и собственно QoS в реализации с использованием массивов СХД гораздо более эффективны.
Для того, чтобы работать с VVols, нет необходимости переквалифицироваться в администратора СХД. С задачами администрирования VVols вполне справится среднестатистический ИТ-админ, а если вы – администратор VMware, то вам даже не понадобится лишний раз открывать консоль управления СХД, поскольку интеграция SPBM и VVols с vCenter предоставляет вам единый инструмент управления (можно контролировать политики и виртуальные тома из интерфейса VMware).
Файлы или блоки? NFS, iSCSI или Fiber Channel? Теперь это совершенно без разницы, ибо VVols воплощают единую архитектуру программного хранилища для всех протоколов хранения и внедряют, так сказать, единый «уровень общения с vSphere». Если вы используете VVols, вам уже неважно, что там было — VMFS и блоки или NFS и файлы, у вас теперь просто VVols и ряд универсальных компонентов, используемых с любым протоколом хранения. Конечно, у каждого протокола есть свои особенности, но VVols позволяет «причесать всех под одну гребенку», поскольку использует не уникальные, а идентичные свойства всех протоколов.
И на десерт самая, пожалуй, «вкусная» причина: теперь массивы СХД умеют работать с каждой отдельно взятой виртуальной машиной. С использованием VMFS «прозрачность» распространялась до уровня LUN, и ни уровнем ниже – из-за этого мы не имели представления о том, какие машины находятся на том или ином томе VMFS. С внедрением VVols парадигма меняется: единицей хранения теперь стала виртуальная машина. К примеру, если мы хотим сделать снапшот массива для одной машины, это вполне осуществимо (тогда как с VMFS нам приходилось делать снапшот для всего LUN). Если вам нужно назначить политики QoS на конкретные виртуальные машины Tier-1, это также можно сделать, поскольку эта функциональная возможность теперь работает на уровне виртуальных машин. Таким образом, мы отходим от концепции VMFS, которая была недостаточно эффективной с точки зрения использования массивов СХД. Теперь мы можем выделять ресурсы на СХД по мере необходимости, без того, чтобы резервировать огромные пространства для VMFS. Это и была основная идея, которую VMware воплотила в Virtual Volumes.
Разумеется, каждый будет решать вопрос об использовании Virtual Volumes, основываясь на своем собственном понимании ситуации. (Все же помните, что наступит момент, и станут говорить уже не «если вы перейдете на VVols», а «когда вы переходите на VVols».) Без сомнения, у нового подхода есть значительные преимущества – в частности, это наиболее эффективное выделение ресурсов для виртуальных машин – но до принятия решения следует тщательно проанализировать, как внедрение VVols согласуется с текущей работой вашей инфраструктуры и перспективами ее развития. Поскольку же переход на новую архитектуру можно совершать постепенно, как уже было сказано, используя Virtual Volumes наряду с NFS или VMFS (то бишь «есть слона по частям»), я могу его только приветствовать.
Представляется, что в будущем Virtual Volumes заменят VMFS, поскольку VMware никогда не распыляется на поддержку двух различных вариантов для ключевых компонентов инфраструктуры, то есть на двойную работу. Сперва они упразднили ESX спустя несколько лет после выхода ESXi, затем – VSA, выпустив на замену VSAN, а теперь пытаются перевести пользователей с vSphere Client на Web Client; допускаю, что в какой-то момент они могут решить перейти от vCenter Server на Windows к VCSA. Поэтому можно предположить, что аналогичная судьба ждет VMFS, от которой откажутся в пользу VVols – разумеется, после того, как они достигнут определенной стадии «зрелости» и будут приняты к использованию большинством пользовательской аудитории. Подтверждением этой мысли является и тот факт, что поддержка VVols включена во все редакции vSphere.
Выясним, однако, для начала, почему эксперты советуют не торопиться с внедрением Virtual Volumes.
Причина №1. Не поддерживается репликация массивов СХД
Это достаточно серьезный резон, особенно для крупных организаций, у которых репликация массивов СХД является основополагающей в их стратегии защиты и восстановления данных. Поддержка репликации хранилища на сегодня не заявлена в спецификации VASA 2.0, так что SRM и vMSC не работают с VVols – для кого-то этого будет достаточно, чтобы не читать дальше. Замечу, однако, что хотя VMware и не поддерживает репликацию массивов СХД, некоторые производители планируют или уже обеспечивают такую поддержку, так что некий workaround существует (но его все же нельзя использовать с SRM или vMSC до тех пор, пока VMware не включит его в спецификацию VASA).
Причина №2. Это первая версия новой архитектуры программного хранилища
Да-да, невзирая на годы, затраченные на разработку, это лишь версия 1.0, и, как первая версия любого продукта, она подвержена «болезни роста», что может заставить пользователей пока подождать. К тому же наблюдается определенный недостаток поддержки функциональной совместимости (а именно — репликации); что же касается поддержки со стороны собственно массива СХД (что тоже потребовало значительных трудозатрат со стороны производителей) – она также выходит в начальной версии. Среди производителей, участвовавших в разработке архитектуры – всеми уважаемые HP, NetApp и Dell, которые занимались этим несколько лет, поэтому именно их решения, скорее всего, будут наиболее зрелыми в плане готовности к использованию.
Причина №3. Не все производители СХД реализуют полную поддержку VVols
На текущий момент есть четверка производителей, у которых в VMware Hardware Compatibility Guide заявлена поддержка Day 1 для VVols. Этот список, разумеется, будет расширяться по мере того, как другие компании-производители будут завершать разработку и проходить сертификацию VMware для VVols; сейчас производители заняты также и расширением спектра поддерживаемых возможностей для VVols.
Причина №4. Кто выйдет победителем в борьбе за сферы влияния на ЦОД?
Помните, как это было, когда вы впервые рассказали сетевому администратору про vSwitch и озвучили требования к сети для vSphere? Без сомнения, человек почувствовал, как власть ускользает из его рук. Возможно, вам даже не удалось разойтись миром:). Аналогичный сценарий вполне вероятен и сегодня, когда вы заведете речь о VVols в разговоре с администратором СХД. Впрочем, как показала история, «сопротивление бесполезно!» — и как тогда администраторы vSphere выиграли борьбу с сетевыми админами, так и теперь они, скорее всего, победят и администраторов СХД. Чтобы обойтись без драки, советуем привлечь их к сотрудничеству, разъясняя, что же такое VVols, как это работает и как это упростит их жизнь от того, что взаимоотношения виртуальной инфраструктуры и СХД значительно улучшатся.
Причина №5. Насколько масштабируема эта архитектура?
Пока еще нет достаточных статистических данных по производительности, чтобы посмотреть, насколько хорошо VVols масштабируемы в сравнении с VMFS, т.е. будут ли они в этом отношении лучше, хуже или такими же. Предполагаю, что это решение примерно аналогично VMFS в смысле масштабируемости, или даже чуть лучше нее. Строго говоря, VVols разрабатывались не как средство увеличения производительности относительно VMFS, а как совершенно новая архитектура программного хранилища, новый подход, ориентированный на виртуальную машину как на единицу хранения в массиве СХД. Это же можно сказать и относительно сравнения RDM и VMFS – речь шла не о повышении производительности, и VMware доказала, что производительность у них одинаково высока, поэтому я вполне допускаю, что подобное произойдет и с VVols. Есть сведения, что в настоящий момент VMware выполняет тесты на сравнение производительности, и результаты, надеюсь, скоро будут доступны.
Причина № 6. Функциональные возможности работы с массивами СХД требуют отдельных лицензий
VMware достаточно долго пыталась мимикрировать под данную функциональность внутри vSphere, предлагая «тонкие диски», снапшоты виртуальных машин, Storage vMotion, Storage I/O Control, и т.д., и т.п. Жизнь многих из этих фич в будущем прекратится, поскольку внедрение VVols опять же приведет к использованию массива СХД. То есть процесс снятия снапшота виртуальной машины автоматически превратится в создание снапшота массива СХД; аналогично, если для динамического выделения ресурса хранения сейчас применяются «тонкие диски», то в будущем этим будут заниматься массивы СХД. Это даже к лучшему, ибо они позволяют выполнять эти операции быстрее и эффективнее. Тем не менее, чтобы использовать данные функции, для массива СХД потребуются соответствующие лицензии. Одни производители, возможно, включат эту функциональность в основной набор поддерживаемых операций, а другие – нет, поэтому следует уточнить стоимость поддержки указанных функциональных возможностей в вашем конкретном случае.
Причина № 7. Когда подтянутся поставщики решений резервного копирования?
Внедрение VVols коснется архитектуры процесса резервного копирования “Direct to SAN”, поскольку теперь он имеет дело с Protocol Endpoint и VASA storage provider. На данный момент еще нет сведений о массовой поддержке данного подхода со стороны поставщиков решений резервного копирования, но в скором будущем они, конечно, появятся. Узнайте у вашего поставщика, как скоро ваше решение для резервного копирования будет поддерживать VVol. Например, Veeam поддержал vVol в выпущенном недавно обновлении Veeam Availability Suite 8.0 Update 2 (подробнее можно прочитать здесь).
Теперь о позитивном.
Хотя список причин, по которым можно не торопиться с внедрением VVols, выглядит достаточно серьезно, во всех остальных отношениях VVols являются оптимальным архитектурным решением для СХД в среде vSphere и предоставляют множество преимуществ. Так, аналогично тому как VSAN позволяет внедрить Storage Policy Based Management (SPBM) на уровне виртуальных машин, VVols дают ту же возможность для shared storage – и преимущества, конечно, не ограничиваются лишь этим.
Поэтому теперь предлагаю рассмотреть список аргументов «За скорейшее внедрение Virtual Volumes»:
Причина №1. Всегда есть возможность выбора и гибкие опции
Совершенно необязательно «окончательно и бесповоротно» переходить на VVols — виртуальные тома можно использовать и наряду с VMFS или NFS. VVols — это просто еще одна опция для вашей архитектуры. Можно легко перемещать виртуальные машины с VMFS/NFS на VVols и обратно, используя Storage vMotion, так что вы можете настроить Storage Container на виртуальный том и создавать или мигрировать машины, как вам удобно.
Причина №2. Присоединиться к энтузиастам в освоении новых технологий
Перешли с ESX на ESXi позже других и запоздало изучали отличия и нюансы работы? Долго не могли привыкнуть к vSphere Web Client? Давайте оставим в прошлом эти «грабли» и не будем ждать, что VVols придется осваивать в «добровольно-принудительном» режиме. Чем раньше вы приступите к ознакомлению с новинкой, тем уверенней вы будете себя чувствовать, когда другие еще только начнут свои первые робкие шажки в этом направлении. А выступать в роли эксперта – почетно и приятно, ведь здорово, когда людям пригодились знания, которые ты им передал.
Причина №3. Место на диске снова свободно!
Помните, в vSphere 5.0, когда VMware внедрила автоматический возврат неиспользуемого места на диске командой UNMAP, это приводило к ошибкам, и в результате пришлось отказаться от автоматизации этой операции и делать это вручную до сей поры, но теперь автоматизация снова с нами – благодаря VVols. Массив СХД, имея полное представление о удалении или перемещении виртуальной машины, сразу после этого может выполнить возврат более неиспользуемого места. Больше не требуется вручную запускать esxcli — с VVols все происходит автоматически. Если нужен возврат места с еще более высоким уровнем гранулярности, то можно еще выполнить на гостевой ОС команду UNMAP. Такой подход позволит повысить эффективность использования массива СХД.
Причина №4. Доступность во всех редакциях vSphere
Если ваш массив СХД поддерживает VVols, нет нужды переходить на другую редакцию vSphere – с VVols работают все редакции. Настроить VVols несложно, так что это не должно стать сдерживающим фактором, как раз наоборот.
Причина №5. Облегчает переход к Storage Policy Based Management
Не отставайте от пользователей VSAN, которые уже вовсю применяют Storage Policy Based Management. Этот подход к управлению инфраструктурой позволяет вам настраивать политики управления СХД в соответствии с функциональными возможностями массива СХД – таким образом, использование ресурсов и возможностей вашей СХД становится ориентированным непосредственно на виртуальные машины. Управление на основе политик позволяет назначать ресурсы в точном соответствии с потребностями виртуальной машины, а также следить за соблюдением этих назначений. Компания VMware потратила много сил и средств на создание этого механизма управления – и все для того, чтобы обеспечить максимальную эффективность и гибкость при выделении ресурсов массива СХД для виртуальных машин.
Причина №6. Оптимальное использование возможностей массива СХД
Массив СХД – это, по сути, механизм для выполнения операций чтения\записи, а также софт, предназначенный для работы именно с этим механизмом. Вместе они представляют собой мощный инструмент для работы с данными. Использование VMFS и СХД vSphere предполагает, что имеется еще некий «посредник», который указывает собственно массиву СХД, что и когда делать. Разумеется, такая цепочка – не самый эффективный метод работы. Избавившись же от такого «посредника» и дав в распоряжение массиву СХД возможности самоконтроля, мы получили систему с наибольшей эффективностью и оптимальным результатом. Заметим также, что возможности массива СХД куда шире, чем сопоставимой СХД vSphere, плюс к тому, у массива всё куда прозрачнее относительно ресурсов СХД, нежели у vSphere. Естественно, что такие вещи, как как динамическое выделение ресурса (thin provisioning), снапшоты и собственно QoS в реализации с использованием массивов СХД гораздо более эффективны.
Причина №7. Управление VVols не требует специальных навыков
Для того, чтобы работать с VVols, нет необходимости переквалифицироваться в администратора СХД. С задачами администрирования VVols вполне справится среднестатистический ИТ-админ, а если вы – администратор VMware, то вам даже не понадобится лишний раз открывать консоль управления СХД, поскольку интеграция SPBM и VVols с vCenter предоставляет вам единый инструмент управления (можно контролировать политики и виртуальные тома из интерфейса VMware).
Причина №8. Единая архитектура для всех
Файлы или блоки? NFS, iSCSI или Fiber Channel? Теперь это совершенно без разницы, ибо VVols воплощают единую архитектуру программного хранилища для всех протоколов хранения и внедряют, так сказать, единый «уровень общения с vSphere». Если вы используете VVols, вам уже неважно, что там было — VMFS и блоки или NFS и файлы, у вас теперь просто VVols и ряд универсальных компонентов, используемых с любым протоколом хранения. Конечно, у каждого протокола есть свои особенности, но VVols позволяет «причесать всех под одну гребенку», поскольку использует не уникальные, а идентичные свойства всех протоколов.
Причина №9. Единица хранения – виртуальная машина
И на десерт самая, пожалуй, «вкусная» причина: теперь массивы СХД умеют работать с каждой отдельно взятой виртуальной машиной. С использованием VMFS «прозрачность» распространялась до уровня LUN, и ни уровнем ниже – из-за этого мы не имели представления о том, какие машины находятся на том или ином томе VMFS. С внедрением VVols парадигма меняется: единицей хранения теперь стала виртуальная машина. К примеру, если мы хотим сделать снапшот массива для одной машины, это вполне осуществимо (тогда как с VMFS нам приходилось делать снапшот для всего LUN). Если вам нужно назначить политики QoS на конкретные виртуальные машины Tier-1, это также можно сделать, поскольку эта функциональная возможность теперь работает на уровне виртуальных машин. Таким образом, мы отходим от концепции VMFS, которая была недостаточно эффективной с точки зрения использования массивов СХД. Теперь мы можем выделять ресурсы на СХД по мере необходимости, без того, чтобы резервировать огромные пространства для VMFS. Это и была основная идея, которую VMware воплотила в Virtual Volumes.
Разумеется, каждый будет решать вопрос об использовании Virtual Volumes, основываясь на своем собственном понимании ситуации. (Все же помните, что наступит момент, и станут говорить уже не «если вы перейдете на VVols», а «когда вы переходите на VVols».) Без сомнения, у нового подхода есть значительные преимущества – в частности, это наиболее эффективное выделение ресурсов для виртуальных машин – но до принятия решения следует тщательно проанализировать, как внедрение VVols согласуется с текущей работой вашей инфраструктуры и перспективами ее развития. Поскольку же переход на новую архитектуру можно совершать постепенно, как уже было сказано, используя Virtual Volumes наряду с NFS или VMFS (то бишь «есть слона по частям»), я могу его только приветствовать.
Дополнительная информация:
- Обзор Virtual Volumes от VMware (на русском языке): http://www.vmware.com/ru/products/vsphere/features/virtual-volumes.html
- Обзор Storage Policy-Based Management от VMware (на русском языке): http://www.vmware.com/ru/products/vsphere/features/storage-policy-based-management.html
- Release Notes для Veeam Backup & Replication 8.0 Update 2 (на англ.языке): http://www.veeam.com/kb2024
