[Из песочницы] NetApp ONTAP & VMware vVOL
Почему появилась эта технология и зачем она нужна, почему она будет востребована в современных ЦОД?
Технология vVol предоставила профили, которые при создании ВМ создают виртуальные диски с заданными характеристиками. В такой среде администратор виртуальной среды уже может с одной стороны у себя в интерфейсе vCenter легко и быстро проверить, какие виртуальные машины живут на каких носителях и узнать их характеристики на СХД: выполняется ли там репликация для DR, настроена ли там компрессия, дедупликация, шифрование и т.д. С технологией vVol, СХД стала просто набором ресурсов для vCenter, намного более глубже интегрировав их друг с другом, чем это было раньше.
Проблема консолидации снепшотов и увеличение нагрузки на дисковую подсистему от снепшотов VMware может быть не заметна для небольших виртуальных инфраструктур, но даже они могут встречаться с их негативным влиянием в виде замедления роботы виртуальной машины или невозможности консолидации (удаление снепшота). vVol поддерживает аппаратный QoS для виртуальных дисков ВМ, а также Hardware-Assistant репликацию и снепшоты NetApp, так как они архитектурно устроены и принципиально по-другому работают, не влияя на производительность, в отличие от COW снепшотов VMware.
vVol
Что вообще такое vVol? vVol — это прослойка для датастора, т.е. это технология виртуализации датастора. Раньше у вас был датастор, расположенный на LUN’е (SAN) или файловой шаре (NAS); как правило, каждый датастор размещал несколько виртуальных машин. vVol с одной стороны унифицировала работу с протоколами NAS и SAN для среды виртуализации, администратору всё-равно, это луны или файлы, с другой стороны, каждый виртуальный диск ВМ может жить в разных вольюмах, лунах, дисковых пулах (агрегатах), разных контроллерах и могут иметь разные политики, которые следуют за этим диском ВМ. В случае с традиционным SAN всё, что СХД «видела» со своей стороны и то, чем она могла управлять — целиком всем датастором, но не отдельно каждым виртуальным диском ВМ. С vVol при создании одной виртуальной машины каждый её отдельный диск может создаваться в соответствии с отдельной политикой. Каждая политика vVol, в свою очередь, позволяет выбирать то свободное пространство из доступного пула ресурсов СХД, которое будет соответствовать заранее прописанным условиям в политиках vVol.
Это позволяет более эффективно и удобно использовать ресурсы и возможности системы хранения. Таким образом, каждый диск виртуальной машины расположен на выделенном своём виртуальном датасторе на подобии LUN RDM. С другой же стороны, в технологии vVol использование одного общего пространства более не является проблемой, ведь аппаратные снепшоты и клоны выполняются не на уровне целого датастора, а на уровне каждого отдельного виртуального диска, при этом не применяются COW снепшоты VMware. В тоже время система хранения теперь сможет «видеть» каждый виртуальный диск отдельно, это позволило делегировать возможности СХД в vSphere (к примеру, снепшоты), предоставляя более глубокую интеграцию и прозрачность дисковых ресурсов для виртуализации.
Компания VMware начала разработку vVol в 2012 году и продемонстрировала эту технологию через два года в своём превью, одновременно компания NetApp объявила о её поддержке в своих системах хранения данных с прошивкой ONTAP со всеми поддерживаемыми средой VMWare протоколами: NAS (NFS), SAN (iSCSI, FCP).
Давайте теперь отойдём от абстрактного описания и перейдем к конкретике. vVol’ы располагаются на FlexVol, для NAS и SAN это, соответственно, файлы или луны. Каждый VMDK диск живёт на своём выделенном vVol диске. Гипервизор может запускать создание снепшота отдельно для каждого диска виртуальной машины. Снепшот одного виртуального диска — это его полная копия, т.е. ещё один vVol. Каждая новая виртуальная машина без снепшотов состоит из нескольких vVol. В зависимости от назначения vVol’ы бывают следующих типов:
Теперь, собственно, про PE. PE — это точка входа к vVol’ам, своего рода прокси. PE и vVol’ы располагаются на СХД. В случае NAS такой точкой входа является каждый Data LIF со своим IP адресом на порте СХД. В случае с SAN это специальный 4МБ лун.
PE создаётся по требованию VASA Provider (VP). PE примапливает все свои vVol по средствам Binging запроса от VP к СХД, примером наиболее частого запроса является старт VM.
ESXi всегда подключается к PE, а не напрямую к vVol. В случае с SAN это позволяет избегать ограничения в 255 лунов на ESXi хост и ограничения в максимальном количестве путей к луну. Каждая виртуальная машина может состоять из vVol только одного протокола: NFS, iSCSI или FCP. Все PE имеют LUN ID 300 и выше.
Несмотря на небольшие отличия, NAS и SAN весьма похожим образом устроены с точки зрения работы vVol в среде виртуализации.
cDOT::*> lun bind show -instance
Vserver: netapp-vVol-test-svm
PE MSID: 2147484885
PE Vdisk ID: 800004d5000000000000000000000063036ed591
vVol MSID: 2147484951
vVol Vdisk ID: 800005170000000000000000000000601849f224
Protocol Endpoint: /vol/ds01/vVolPE-1410312812730
PE UUID: d75eb255-2d20-4026-81e8-39e4ace3cbdb
PE Node: esxi-01
vVol: /vol/vVol31/naa.600a098044314f6c332443726e6e4534.vmdk
vVol Node: esxi-01
vVol UUID: 22a5d22a-a2bd-4239-a447-cb506936ccd0
Secondary LUN: d2378d000000
Optimal binding: true
Reference Count: 2
iGroup и Export Policy — это механизмы, позволяющие скрывать от хостов доступную на СХД информацию. Т.е. предоставлять каждому хосту только то, что он должен видеть. Как в случае с NAS, так и SAN, мапинг лунов и экспорт файловых шар происходит автоматически из VP. iGroup мапится не на все vVol, а только на PE, так как ESXi использует PE как прокси. В случае NFS протокола, экспорт политика автоматически применяется к файловой шаре. iGroup и экспорт политика создаётся и заполняется автоматически при помощи запроса из vCenter.SAN & IP SAN
В случае протокола iSCSI необходимо иметь минимум один Data LIF на каждой ноде СХД, который подключён в ту же сеть, что и соответствующий VMkernel на ESXi хосте. iSCSI и NFS LIF’ы должны быть разделены, но могут сосуществовать в одной IP сети и одном VLAN. В случае FCP необходимо иметь минимум один Data LIF на каждой ноде СХД для каждой фабрики, другими словами, как правило это два Data LIF’а от каждой ноды СХД, живущие на своём отдельном таргет-порте. Используйте soft-zoning на свиче для FCP.
NAS (NFS)
В случае протокола NFS необходимо иметь минимум один Data LIF с установленным IP адресом на каждой ноде СХД, который подключён в ту же подсеть сеть, что и соответствующий VMkernel на ESXi хосте. Нельзя использовать один IP адрес для iSCSI и NFS одновременно, но они оба могут сосуществовать в одном VLAN, в одной подсети и на одном физическом Ethernet порте.
VASA Provider
VP является посредником между vCenter и СХД, он объясняет СХД, что от неё хочет vCenter и наоборот рассказывает vCenter об важных алертах и доступных ресурсах СХД, тех, которые есть физически на самом деле. Т.е. vCenter теперь может знать сколько свободного пространства есть на самом деле, это особенно удобно, когда СХД презентует гипервизору тонкие луны.
VP не является единой точкой отказа в том смысле, что при его выходе из строя виртуальные машины по-прежнему, нормально будут работать, но нельзя будет создавать или редактировать политики и виртуальные машины на vVol, стартовать или останавливать VM на vVol. Т.е. в случае полной перезагрузки всей инфраструктуры, виртуальные машины не смогут стартовать, так как не отработает Binding запрос VP к СХД чтобы примапить PE к своим vVol. Поэтому VP однозначно желательно резервировать. И по той же причине не разрешается располагать виртуальную машину с VP на vVol, которым он управляет. Почему «желательно» резервировать? Потому что, начиная с версии NetApp VP 6.2, последний умеет восстанавливать содержимое vVol просто считывая метаинформацию с самой СХД. Подробнее про настройку и интеграцию в документации по VASA Provider и VSC.
Disaster Recovery
VP поддерживает функционал Disaster Recovery: в случае удаления или повреждения VP, база данных окружения vVol может быть восстановлена: Мета информация об окружении vVol храниться в дублированном виде: в базе данных VP, а также вместе с самими объектами vVol на ONTAP. Для восстановления VP достаточно от-регистрировать старый VP, поднять новый VP, зарегистрировать в нём ONTAP, там же выполнить команду vp dr_recoverdb и подключить к vCenter, в последнем выполнить «Rescan Storage Provider». Подробнее в KB.
Функционал DR для VP позволит ореплицировать vVol средствами аппаратной репликации SnapMirror и восстановить сайт на DR-площадке, когда vVol начнёт поддерживать репликацию СХД (VASA 3.0).
Virtual Storage Console
VSC — это плагин для СХД в графический интерфейс vCenter, в том числе для работы с политиками VP. VSC является обязательным компонентом для работы vVol.
Snapshot & FlexClone
Давайте проведём грань между снепшотами с точки зрения гипервизора и снепшотами с точки зрения СХД. Это очень важно для понимания внутреннего устройства того, как работает vVol на NetApp со снепшотами. Как многие уже знают, снепшоты в ONTAP всегда выполняются на уровне вольюма (и агрегата) и не выполняются на уровне файла/луна. С другой же стороны vVol, это файлы или луны, т.е. с них нельзя для каждого по отдельности VMDK файла снимать снепшоты средствами СХД. Здесь на помощь приходит технология FlexClone, которая как раз умеет делать клоны не только вольюмов целиком, но и файлов/лунов. Т.е. когда гипервизор снимает снепшот виртуальной машины, живущей на vVol, то под капотом происходит следующее: vCenter контактирует с VSC и VP, которые в свою очередь находят, где именно живут нужные VMDK файлы и дают команду ONATP снять с них клон. Да, то что со стороны гипервизора выглядит как снепшот, на СХД это клон. Другими словами, для того, чтобы на vVol работали Hardware-Assistant Snapshot необходима лицензия FlexClone. Именно для такой или подобных целей в ONTAP появился новый функционал FlexClone Autodelete, который позволяет задать политики удаления старых клонов.
Так как снепшоты выполняются на уровне СХД, проблема консолидации снепшотов (ESXi) и негативное влияние снепшотов на производительность дисковой подсистемы, полностью устранены благодаря внутреннему устройству механизма клонирования/снепшотирования в ONTAP.
Консистентность
Так как сам гипервизор снимает снепшоты средствами СХД, то они уже сразу автоматически консистентные. Что очень хорошо вписывается в парадигму резервного копирования NetApp ONTAP. vSphere поддерживает снепшотирование памяти ВМ на выделенный vVol.
Клонирование и VDI
Функция клонирования чаще всего очень востребована в VDI окружении, где есть необходимость быстро разворачивать множество однотипных виртуальных машин. Для того, чтобы использовать Hardware-Assistant клонирование необходима лицензия FlexClone. Важно отметить, что технология FlexClone не только кардинально ускоряет разворачивание копий большого количества виртуальных машин, кардинально уменьшая потребление дискового пространства, но и косвенно ускоряет их работу. Клонирование по сути выполняет функцию подобную дедупликации, т.е. уменьшает объем занимаемого пространства. Дело в том, что NetApp FAS всегда помещает данные в системный кэш, а системный и SSD кэши в свою очередь является Dedup-Aware, т.е. они не затягивает дубликаты блоков от других виртуальных машин, которые уже там есть, логически вмещая намного больше нежели физически системный и SSD кэш могут. Это кардинально улучшает производительность во время эксплуатации СХД и особенно в моменты Boot-Storm благодаря увеличению попадания/чтения данных в/из кэш (а).
UNMAP
Технология vVol начиная с версии VMware 6.0, VM Hardware версии 11 и Windows 2012 с файловой системой NTFS поддерживает высвобождение пространства внутрь тонкого луна на котором расположена данная виртуальная машина автоматически. Это существенно улучшает утилизацию полезного пространства в SAN инфраструктуре, использующей Thing Provisioning и Hardware-assistant снепшоты. А начиная с VMware 6.5 и гостевой ОС Linux с поддержкой SPC-4 также позволит высвобождать пространство изнутри виртуальной машины, назад в СХД, позволяя существенно экономить дорогостоящее пространство на СХД. Подробнее про UNMAP.
Минимальные системные требования
- NetApp VASA Provider 5.0 и выше
- VSC 5.0 и выше.
- Clustered Data ONTAP 8.2.1 и выше
- VMware vSphere 6.0 и выше
- VSC и VP должны иметь одинаковые версии, к примеру, оба 5.х или оба 6.х.
Подробнее уточняйте у авторизированного партнёра NetApp или в матрице совместимости.
SRM и аппаратная репликация
Site Recovery Manager, к сожалению, пока что не поддерживает vVol так как в текущей реализации VASA протокола со стороны VMware не поддерживается репликация и SRM. Системы NetApp FAS имеют интеграцию с SRM и работают без vVol. Технология vVol также поддерживается с vMSC (MetroCluster) для построения для построения, гео-распределённого высоко-доступного хранилища.
Резервное копирование
Технология vVol кардинально изменит подход к резервному копированию, уменьшив время резервного копирования и более эффективно используя пространство хранилища. Одной из причин тому есть принципиально другой подход снепшотирования и резервного копирования, так как vVol использует аппаратное снепшотирование, из-за чего вопрос консолидации и удаления снепшотов VMware отпадает. Из-за устранения проблемы с консолидацией снепшотов VMware, снятие application-aware (аппаратных) снепшотов и резервных копий перестаёт быть головной болью админов. Это позволит более часто снимать резервные копии и снепшоты. Аппаратные снепшоты не влияющие на производительность позволят их хранить много прямо на продуктивной среде, а аппаратная репликация позволит более эффективно реплицировать данные для архивирования или на DR-сайт. Использование снепшотов по сравнению с Full-backup позволит более экономно использовать пространство хранилищ.
VASA 3.0
Не путайте плагин от вендора СХД (к примеру NetApp VASA Provider 6.0) и API интерфейс VMware VASA (к примеру VASA 3.0). Самым важным и ожидаемым новшеством в vVol, в ближайшее время, станет поддержка аппаратной репликации. Именно поддержки аппаратной репликации так не хватает для того, чтобы технология vVol начала широко применяться. В новой версии будет поддерживается аппаратная репликация vVol дисков средствами СХД для обеспечения функции DR. Репликацию можно было выполнить и раньше средствами СХД, но гипервизор раньше не мог работать с отреплицированными данными из-за отсутствия поддержки такого функционала в VASA 2.X (и более младшей) со стороны vSphere. Также появятся PowerShell командлеты для управления DR на vVol, и что важно, возможность запуска для тестирования отреплицированных машин. Для запланированной миграции с DR сайта может будет запрошена репликация виртуальной машины. Это позволит использовать SRM вместе с vVol.
Oracle RAC будет валидирован для запуска на vVol, что не может не радовать.
Лицензирование
Для работы vVol необходимы следующие компоненты: VP, VSA и хранилище с необходимой прошивкой, поддерживающее vVol. Эти компоненты не требуют каких-либо лицензий для работы vVol. Для того чтобы поддерживались аппаратные снепшоты или клоны (снятие и восстановление) необходима лицензия NetApp FlexClone, а для репликации данных необходима будет лицензия NetApp SnapMirror/SnapVault (на обоих СХД: на основной и резервной площадках). Со стороны vSphere необходимы лицензии Standard или Enterprise Plus.
Выводы
Технология vVol была спроектирована для ещё более тесного взаимодействия гипервизора ESXi с СХД и упрощения управления. Это позволило более рационально использовать возможности и ресурсы СХД, такие как Thing Provisioning, где благодаря UNMAP пространство из тонких лунов может высвобождаться. При этом гипервизору сообщается о реальном состоянии пространства и ресурсов СХД, всё это позволяет применять Thing Provisioning не только для NAS, но и использовать его в «боевых» условиях с SAN, абстрагироваться от протокола доступа и обеспечить прозрачность инфраструктуры. А политики работы с ресурсами СХД, тонкое клонирование и снепшоты не влияющие на производительность позволят ещё более быстро и удобно разворачивать виртуальные машины в виртуализированной инфраструктуре.
Комментарии (1)
mikkisse
7 февраля 2017 в 19:07
+1↑
↓
Шикарно, спасибо!
