Архитектура 2-node vSAN 6.6. Лицензирование vSAN ROBO.

В статьях 2-node vSAN cluster. Witness Appliance Failure, Режим обслуживания (maintenance) в 2-Node Direct Connect vSAN configuration я затронул вопросы функционирования 2-node VMware vSAN. Сейчас я подробнее остановлюсь на архитектуре 2-node vSAN кластера и лицензировании vSAN for ROBO.

Как я уже писал, vSAN — отличное решение для удаленных офисов и филиалов — Remote Office / Branch Office (ROBO).

На этом рисунке показан центральный ЦОД и три удаленных офиса. Каждый удаленный офис имеет 2-node vSAN cluster и witness host для каждого кластера, функционирующий в центральном ЦОДе. Под witness host понимается не физический хост, а вложенный ESXi, который функционирует в ВМ (virtual appliance), которая в свою очередь развертывается из предварительно сконфигурированного OVA файла. Для vSAN Witness дополнительной лицензии не требуется — она уже встроена.

В инфраструктуре VMware vSphere witness host выглядит как «настоящий».

При этом vSAN witness appliance не предоставляет вычислительные ресурсы или ресурсы хранения для кластера, он не может размещать виртуальные машины.

Он существует ИСКЛЮЧИТЕЛЬНО в конфигурациях Virtual SAN 2 Node/Virtual SAN Stretched Clusters.

А вот как выглядит ВМ, приютившая witness host:

vSAN for ROBO лицензируется по схеме «per-VM» и распространяется пакетами по 25 лицензий. Т.е. модель лицензирования vSAN for ROBO предполагает, что в каждом удаленном офисе может быть не более 25 ВМ. Если ВМ больше, то требуется лицензия  vSAN Standard, Advanced  или  Enterprise. Отличия между редакциями представлена ниже.

Примечание.

• Функции deduplication & compression and RAID-5/6 erasure coding требуют all-flash vSAN.
• С версии vSAN 6.2 все лицензии включают поддержку all-flash (ранее VSAN ROBO edition поддерживала только гибридные конфигурации*).
• Лицензия vSAN for ROBO Advanced была введена только в версии vSAN 6.5 и не доступна для более ранних редакций.
• vSAN для ROBO Enterprise был представлен в выпуске vSAN 6.6.1 и доступен только для этой версии.

*Гибридная конфигурация: от 1 до 7 магнитных диска и обязательно — минимум один SAS/SATA SSD, или PCIe flash диск (NVMe). Магнитные диски используются для хранения данных (capacity layer), а SSD или Flash — в качестве кэша данных (cache layer).

Схема лицензирования допускает первоначальное приобретение лицензии vSAN for ROBO и дальнейшее изменение на ее vSAN Standard, Advanced, or Enterprise без прерывания работы, когда удаленный офис выходит за рамки 25 виртуальных машин.

Лично меня смутило следующее предложение: «It is important to note there is no upgrade/conversion path from vSAN for ROBO per-VM licenses to vSAN Standard, Advanced, and Enterprise per-CPU licenses». Но это относится не к технической части, а к финансовой — лицензии нужно приобретать с нуля, по полной стоимости.

С помощью vSAN for ROBO Standard or Advanced or Enterprise может быть лицензировано любое количество хостов пока запущенные в кластере виртуальные машины не превысят 25. При этом один пакет лицензий может быть распространены между несколькими удаленными офисами. Пример на рисунке.

Здесь мы видим, что для всех трех офисов используется только одна лицензия vSAN for ROBO. Также замечаем, что в третьем офисе не два, а четыре хоста. Это не влияет на лицензирование, но поскольку 4 хоста обеспечивают кворум, то Winess не требуется.

Примечание: четыре хоста обеспечивают хранилище vSAN только для уделенного офиса. В случае, если бы они были частью vSAN Stretched Cluster, то свидетель был бы необходим.

Рассмотрим еще один пример.

Три удаленных сайта имеют в общей сложности 42 виртуальные машины. Поскольку общее количество виртуальных машин на сайтах 1 и 2 меньше, чем 25, может использоваться одна лицензии Virtual SAN for ROBO. Для сайта 3 потребуется собственная лицензия Virtual SAN for ROBO.

Пока мы касались только вопросов лицензирования vSAN. Но необходимо помнить, что для функционирования vSAN нужны еще лицензии на ESXi и vCenter.  Лицензии vSphere и vSphere with Operations Management не включают лицензии vSAN. При этом vSAN работает с любой редакцией vSphere. 

Отдельно стоит остановиться на особенностях использования  редакций  vSphere Essentials Kit и vSphere Essentials Plus Kit. Эти редакции ограничены количеством управляемых vCenter Server Essentials хостов — 3. vSAN witness host— независимо от того, физический он или виртуальный рассматривается как хост в Essentials licensing bundles. Давайте рассмотрим это на примере.

Предположим у нас есть один физический хост в центральном ЦОДе, управляемый vCenter Server который лицензирован как vCenter Server Essentials. Два физических хоста в удаленном офисе, используемые в сценарии 2-node vSAN и управляемые тем же самым vCenter Server. Witness host virtual appliance развернутый в центральном ЦОДе. Всего три физических хоста. Но при попытке добавить witness host к vCenter Server Essentials мы получим предупреждение, поскольку будет считаться что мы добавляем четвертый хост, что не предусмотрено лицензией vSphere Essentials (ОБНОВЛЕНИЕ:   Четвертый хост добавить можно!!! Нужно добавлять witness host ПЕРЕД физическими хостами — Добавление witness appliance к vCenter Foundation и vSphere Essentials).

При проработке вопроса развертывания 2-node VSAN (ROBO) может возникнуть вопрос: а возможно ли при нехватке ресурсов масштабировать его до трехузлового? Технически это можно сделать по инструкции, которую написал Кормак Хоган: Scaling 2-node VSAN (ROBO) to a 3-node or more. Однако если ваш кластер развернут по схеме Direct Connect, то без изменения сетевой архитектуры не обойтись.

Также может возникнуть вопрос: а где еще можно размещать Witness host virtual appliance? И можно ли использовать два удаленных филиала для размещения Witness host друг друга?

На все эти вопросы Кормак Хоган также ответил (2-NODE VSAN TOPOLOGIES REVIEW): witness может запускаться в vCloud Air а также на другом vSAN. Что же касается взаимного хранения свидетелей, то остановимся на этом вопросе подробнее.

Схема выглядит следующим образом:

Эта конфигурация нарушает принцип VMware “We support any vSphere to run the witness that has independent failure properties.” В этом случае существует взаимозависимость между развертываниями 2-node vSAN на каждом удаленном узле, поскольку на каждом сайте есть свидетель другого развертывания 2-node vSAN (W1 является свидетелем 2-node vSAN на удаленном узле 1, а W2 является свидетелем 2-node vSAN на удаленном сайте 2). Таким образом, если один сайт имеет сбой, это влияет на доступность другого сайта. По состоянию на 16 марта 2017 года VMware изменила позицию вокруг этой конфигурации. Теперь VMware будет поддерживать это через RPQ, но существует несколько ограничений, и заказчикам необходимо полностью понять и согласиться с тем, чтобы VMware одобрила RPQ.

Дополнительные материалы:

VMware vSAN ROBO Licensing & vSAN 2 Node

VMWARE VSAN 6.6 Licensing Guide