NetApp ONTAP & VMware vVOL

В этой статье я хотел бы рассмотреть внутреннее устройство и архитектуру технологии vVol, реализованную в системах хранения данных NetApp с прошивкой ONTAP.

Почему появилась эта технология и зачем она нужна, почему она будет востребована в современных ЦОД? На эти и другие вопросы я постараюсь ответить в этой статье.

Технология vVol предоставила профили, которые при создании ВМ создают виртуальные диски с заданными характеристиками. В такой среде администратор виртуальной среды уже может с одной стороны у себя в интерфейсе vCenter легко и быстро проверить, какие виртуальные машины живут на каких носителях и узнать их характеристики на СХД: какой там тип носителя, включена ли для него технология кеширования, выполняется ли там репликация для DR, настроена ли там компрессия, дедупликация, шифрование и т.д. С технологией vVol, СХД стала просто набором ресурсов для vCenter, намного более глубже интегрировав их друг с другом, чем это было раньше.

Снепшоты


Проблема консолидации снепшотов и увеличение нагрузки на дисковую подсистему от снепшотов VMware может быть не заметна для небольших виртуальных инфраструктур, но даже они могут встречаться с их негативным влиянием в виде замедления роботы виртуальной машины или невозможности консолидации (удаление снепшота). vVol поддерживает аппаратный QoS для виртуальных дисков ВМ, а также Hardware-Assistant репликацию и снепшоты NetApp, так как они архитектурно устроены и принципиально по-другому работают, не влияя на производительность, в отличие от COW снепшотов VMware. Казалось бы кто пользуется этими снепшотами и почему это важно? Дело в том, что все схемы резервного копирования в среде виртуализации так или иначе архитектурно вынуждены использовать COW снепшоты VMware, если вы хотите получить консистентные данные.

image

vVol


Что вообще такое vVol? vVol — это прослойка для датастора, т.е. это технология виртуализации датастора. Раньше у вас был датастор, расположенный на LUN'е (SAN) или файловой шаре (NAS); как правило, каждый датастор размещал несколько виртуальных машин. vVol сделала датастор более гранулярным создавая отдельный датастор под каждый диск виртуальной машины. vVol также с одной стороны унифицировала работу с протоколами NAS и SAN для среды виртуализации, администратору всё-равно, это луны или файлы, с другой стороны, каждый виртуальный диск ВМ может жить в разных вольюмах, лунах, дисковых пулах (агрегатах), с разными натсройками кеширования и QoS, на разных контроллерах и могут иметь разные политики, которые следуют за этим диском ВМ. В случае с традиционным SAN всё, что СХД «видела» со своей стороны и то, чем она могла управлять — целиком всем датастором, но не отдельно каждым виртуальным диском ВМ. С vVol при создании одной виртуальной машины каждый её отдельный диск может создаваться в соответствии с отдельной политикой. Каждая политика vVol, в свою очередь, позволяет выбирать то свободное пространство из доступного пула ресурсов СХД, которое будет соответствовать заранее прописанным условиям в политиках vVol.

Это позволяет более эффективно и удобно использовать ресурсы и возможности системы хранения. Таким образом, каждый диск виртуальной машины расположен на выделенном своём виртуальном датасторе на подобии LUN RDM. С другой же стороны, в технологии vVol использование одного общего пространства более не является проблемой, ведь аппаратные снепшоты и клоны выполняются не на уровне целого датастора, а на уровне каждого отдельного виртуального диска, при этом не применяются COW снепшоты VMware. В тоже время система хранения теперь сможет «видеть» каждый виртуальный диск отдельно, это позволило делегировать возможности СХД в vSphere (к примеру, снепшоты), предоставляя более глубокую интеграцию и прозрачность дисковых ресурсов для виртуализации.

Компания VMware начала разработку vVol в 2012 году и продемонстрировала эту технологию через два года в своём превью, одновременно компания NetApp объявила о её поддержке в своих системах хранения данных с прошивкой ONTAP со всеми поддерживаемыми средой VMWare протоколами: NAS (NFS), SAN (iSCSI, FCP).



Protocol Endpoints

Давайте теперь отойдём от абстрактного описания и перейдем к конкретике. vVol'ы располагаются на FlexVol, для NAS и SAN это, соответственно, файлы или луны. Каждый VMDK диск живёт на своём выделенном vVol диске. При переезде vVol диска на другую ноду СХД, он прозрачно перемапливается к другому PE на этой новой ноде. Гипервизор может запускать создание снепшота отдельно для каждого диска виртуальной машины. Снепшот одного виртуального диска — это его полная копия, т.е. ещё один vVol. Каждая новая виртуальная машина без снепшотов состоит из нескольких vVol. В зависимости от назначения vVol'ы бывают следующих типов:

image

Теперь, собственно, про 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

iGroup и Export Policy — это механизмы, позволяющие скрывать от хостов доступную на СХД информацию. Т.е. предоставлять каждому хосту только то, что он должен видеть. Как в случае с NAS, так и SAN, мапинг лунов и экспорт файловых шар происходит автоматически из VP. iGroup мапится не на все vVol, а только на PE, так как ESXi использует PE как прокси. В случае NFS протокола, экспорт политика автоматически применяется к файловой шаре. iGroup и экспорт политика создаётся и заполняется автоматически при помощи запроса из vCenter.

SAN & IP SAN

image

В случае протокола iSCSI необходимо иметь минимум один Data LIF на каждой ноде СХД, который подключён в ту же сеть, что и соответствующий VMkernel на ESXi хосте. iSCSI и NFS LIF'ы должны быть разделены, но могут сосуществовать в одной IP сети и одном VLAN. В случае FCP необходимо иметь минимум один Data LIF на каждой ноде СХД для каждой фабрики, другими словами, как правило это два Data LIF'а от каждой ноды СХД, живущие на своём отдельном таргет-порте. Используйте soft-zoning на свиче для FCP.

NAS (NFS)

image

В случае протокола 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.

image

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 API 3.0


Не путайте плагин от вендора СХД (к примеру NetApp VASA Provider 6.0) и API интерфейс VMware VASA (к примеру VASA API 3.0). Самым важным и ожидаемым новшеством в VASA API, в ближайшее время, станет поддержка аппаратной репликации. Именно поддержки аппаратной репликации так не хватает для того, чтобы технология vVol начала широко применяться. В новой версии будет поддерживается аппаратная репликация vVol дисков средствами СХД для обеспечения функции DR. Репликацию можно было выполнить и раньше средствами СХД, но гипервизор раньше не мог работать с отреплицированными данными из-за отсутствия поддержки такого функционала в VASA API 2.X (и более младшей) со стороны vSphere. Также появятся PowerShell командлеты для управления DR на vVol, и что важно, возможность запуска для тестирования отреплицированных машин. Для запланированной миграции с DR сайта может будет запрошена репликация виртуальной машины. Это позволит использовать SRM вместе с vVol.

Oracle RAC будет валидирован для запуска на vVol, что не может не радовать.

Лицензирование


Для работы vVol необходимы следующие компоненты: VP, VSA и хранилище с необходимой прошивкой, поддерживающее vVol. Эти компоненты сами по себе не требуют каких-либо лицензий для работы vVol. Со стороны NetApp ONTAP обязательно необходимо наличие лицензии FlexClone, чтобы vVol работал, — эта лицензия также нужна для того, чтобы поддерживались аппаратные снепшоты или клоны (снятие и восстановление). Для репликации данных (если она нужна) необходима будет лицензия NetApp SnapMirror/SnapVault (на обоих СХД: на основной и резервной площадках). Со стороны vSphere необходимы лицензии Standard или Enterprise Plus.

Выводы


Технология vVol была спроектирована для ещё более тесного взаимодействия гипервизора ESXi с СХД и упрощения управления. Это позволило более рационально использовать возможности и ресурсы СХД, такие как Thing Provisioning, где благодаря UNMAP пространство из тонких лунов может высвобождаться. При этом гипервизору сообщается о реальном состоянии пространства и ресурсов СХД, всё это позволяет применять Thing Provisioning не только для NAS, но и использовать его в «боевых» условиях с SAN, абстрагироваться от протокола доступа и обеспечить прозрачность инфраструктуры. А политики работы с ресурсами СХД, тонкое клонирование и снепшоты не влияющие на производительность позволят ещё более быстро и удобно разворачивать виртуальные машины в виртуализированной инфраструктуре.
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 13
    +1
    Шикарно, спасибо!
      0
      В случае протокола NFS необходимо иметь минимум один Data LIF с установленным IP адресом на каждой ноде СХД, который подключён в ту же подсеть сеть, что и соответствующий VMkernel на ESXi хосте.

      Это ограничение VVOL? Ведь с обычными датасторами LIF ездит между нодами.
        +1
        Может быть дело в производительности? В таком случае трафик будет бегать только в пределах одной ноды, а вторая будет простаивать.
          0
          А толку гнать трафик через вторую ноду, когда агрегатом один? Вопрос в необходимости изменить топологию по сравнению с ESXi 5.5, где не было мультипасинга и использовался один адрес с LAG для фейловера.
            +1
            Если агрегат один, то действительно толку нет. В вашем случае, один дополнительный, IP хлеба не просит. Дело в том, что основная масса заказчиков нетапа это системы с более чем одним агрегатом у которых используется Active/Active конфигурация.
            Таким образом архитектура устроена так, чтобы предусмотреть возможность масштабирования на две и более ноды.
              +1
              В вашем случае, один дополнительный, IP хлеба не просит.

              Спасибо за пояснение, а то мне вспомнилась чудовищная схема подключения из TR-3749, где предлагали создавать по VMKernel на каждый порт контроллера.
                0
                Согласен, та схема была достаточно тяжёлая. Я кстати писал про такую схему когда-то давно. На самом деле та схема, это костыль к Ethernet, потому, что он плохо балансирует по линкам и у него нет встроенного мультипасинга для отказоустойчивости.

                К сожалению VVOL пока что так и не научился работать с pNFS, в котором по-своему решена эта проблема. Надеюсь что VMware работает в этом направлении.
          +1
          Как уже было сказано ранее, PE это прослойка виртуализации, промежуточное звено, через которое происходит обращение от хоста к VVOL. Из чего вытекает, что если пропадёт PE, то пропадёт доступ ко всем VVOL которые он мапил. Но так как вы уже сказали, IP адрес ездит по портам и нодам, то это не проблема.

          Как вы можете знать в случае переезда только лишь IP адреса на другую ноду, доступ к данным будет осуществляться не напрямую, а через не оптимальный путь — пока IP будет на одной ноде, а данные на другой то доступ к ним будет осуществляться через кластерную сеть.

          Такая ситуация может просходить по двум причинам:
          1. Вы прозрачно мигрируете ваши данные с одной ноды на другую: в таком случае, будет момент времени когда ваш IP по которому вы получяете доступ к данным на одной ноде, а ваши данные на другой. Это временная ситуация которая в результате завершается тем, что IP и данные переезжают на одну ноду и доступ к ним снова происходит «напрямую» без кластерной сети по оптимальному пути. А на LIF интерфейсе меняется Home порт — тот который будет на новой ноде.
          2. Когда нода или сетевой порт или сетевой линк умерли. Тогда задействуется механизм временного переезда IP адреса на другой порт. Здесь ключевое слово ВРЕМЕННО. Потому что когда всё восстановиться он поедет обратно на свой родной Home порт.


          Итак не оптимальный путь к данным в случае переезда IP это так или иначе временная мера — защитный механизм.

          А что если вы имеете несколько нод в кластере, каждая из которых имеет ресурсы хранения, вы же хотите чтобы доступ к ним всегда осуществлялся напрямую по оптимальному пути? Всё очень просто для этого нужно создать IP адреса на каждой ноде.
            0
            Ограничения и технические требования описаны в TR документе о vVOL на стр 10.
            +1
            Пара новостей по теме: поддержка vSphere 6.5 появится в VSC 6.2.1P1, которая выйдет 23 февраля.
            А в июне должны выпустить VSC 7.0, где наконец откажутся от винды и она будет поставляться сразу в OVF.
              0
              Спасибо за новость! Кстати ориентировочно к этому времени выйдет ONTAP 9.2.
                0
                Полагаю, оба этих события ONTAP 9.2 & VSC 7.0 будут приурочены VASA API v3.0.
                  0
                  Что-то они прифигели, из VSC 7.0 убрали всё управление снепшотами и совместимость с ESXi 5.5.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое