Дизайн и разворот vSAN 7.0U1 – Aleksandr Mykhalchenko`s Blog

Продукт vSAN представляет собой программное решение для хранения данных (SDS), поддерживающее системы гиперконвергентной инфраструктуры (HCI). Функционально он интегрирован в vSphere в качестве распределенного уровня ПО в гипервизоре ESXi. По факту, vSAN создает единый пул для всех хостов в составе его кластера, объединяя локальные дата-стораджи или напрямую подключенные устройства хранения данных:

Благодаря vSAN виртуальная инфраструктура более не нуждается в специальном внешнем хранилище. Он удобно настраивает систему хранения данных, применяя политики SPBM – набор индивидуально задаваемых требований к хранению, условиям и возможностям хранения.

Ниже мы поговорим о том, как грамотно разработать дизайн vSAN 7.0U1, с учетом особенностей инфраструктуры, и опираясь на предоставляемые последней версией этого продукта новые возможности. Расскажем, как развернуть его с нуля в рабочей среде, настроить взаимодействие между компонентами и хранилищем данных. Словом, насладимся в полной мере поразительными качествами этого решения. Этого, если можно так выразиться, «хранилища Шредингера» – виртуальной системы данных, которой можно пользоваться, но нельзя пощупать вживую…

Разработка дизайна vSAN 7.0U1

VMware рекомендует идти по одной из генеральных линий построения кластера vSAN, отличающихся не только исходными данными, но и самим принципом разворота. Это:

Разворот под ключ с Dell EMC VxRail или с Hitachi UCP-HC;
Сертифицированный vSAN Ready Nodes от любого из ведущих производителей серверного оборудования;
Пользовательский билд с компонентами из VCG.

В двух словах познакомимся с ними, чтобы выбор был обоснованным.

Dell EMC VxRAIL

Объединение вычислительных, сетевых ресурсов и ресурсов хранения VMware в гиперконвергентную инфраструктуру с целью достаточно простого в развертывании и прозрачного в применении комплексного решения. ПО VxRAIL загружается на партнерское физическое оборудование и включает vSAN.

vSAN Ready Node

Готовая серверная конфигурация для разворачивания vSAN, сертифицированная и проверенная на разрешенном «железе». Она рекомендована OEM-производителями и VMware. Идеальное решение для обустройства гиперконвергентных блоков, участвующих в строительстве крупных сред дата-центров, и нуждающихся в настройке программных и аппаратных конфигураций с целью автоматизации процессов. Члены партнерской сети vSAN Ready Node предлагают предустановленный vSAN на готовых узлах.

Один из этих вариантов – однозначный выбор для масштабных инфраструктур и дата-центров, которым важны комплексные подходы к виртуализации. Что же касается пользовательских конфигураций vSAN, с ними вполне по силам построить отлично защищенное и удобное в использовании хранилище данных для производственных сред малых и средних размеров. И именно на них мы сегодня и сфокусируемся, как на наиболее вариативных, интересных и сложных.

Совместимость и требования

Перед тем, как приступать непосредственно к построению дизайна vSAN, стоит оценить исходные данные. На самом деле, все будет зависеть от того, разворачивается ли он уже в существующей работающей инфраструктуре, или же архитектура виртуальной среды строится на пустом месте, но обязательно с самого начала уже с этим интегрированным продуктом. Со вторым вариантом, конечно, проще: гораздо меньше факторов надо учитывать и часть ограничивающих свободу виртуализатора рамок попросту отсутствует. Поэтому мы, естественно, будем рассматривать сложный случай – с разворотом на базе среды.

Итак, обрисуем ситуацию вкратце. Предположим, у нас есть виртуальная среда – скажем, любая vSphere, в идеале – последняя на данный момент версия 7.0U1 (или хотя бы 6.7), – и запланирован ее естественный апгрейд с разворотом программно-определенной системы хранения vSAN. Это означает, что у нас есть какое-то соответствующее виртуальное «железо», управляющие устройствами микропрограммы, используемое в работе всего этого ПО, определенная модель хоста и тому подобные важные вещи. В первую очередь, придется убедиться в том, что все это совместимо с продуктом vSAN 7.0U1, используя, по традиции, VMware Compatibility Guide (VCG). Там выбираются различные сочетания перечисленных составляющих и выясняется, готовы ли они к совместному «проживанию» с инфраструктурой хранения данных. До этого, естественно, предварительно следует выяснить, какие на данный момент задействованы в ESXi драйвера и управляющие оборудованием микропрограммы, компоненты сети. Вот небольшой список команд для получения информации о:

контролере:

esxcli vsan debug controller list

VID/DID/SVID/SSID сетевого адаптера или сторадж-контроллера:

vmkchdev -l | egrep ‘vmnic|vmhba’

драйвере NIC:

esxcli network nic list

драйвере контроллера хранилища:

esxcli storage core adapter list

версии любого драйвера:

vmkload_mod -s <имя драйвера > | grep -i version

устройствах NVME:

esxcli nvme device get -A vmhbaX | egrep “Serial Number|Model Number|Firmware Revision”

где «Х» – название искомого устройства.

Много полезной информации по совместимости и требованиях ко всему перечисленному можно найти в разделе «Требования и совместимость» статьи «Инсталляция обновления VMware vSAN 7.0U1». А вот дополняющая изложенную там информацию небольшая «шпаргалка» по совместимости и требованиям в схемах.

Параметры аппаратной части и ее состав:

Типы контроллеров хранилища:

Кстати, в будущем, когда vSAN уже будет развернут, его Health Service каждый раз станет обращаться к сверке совместимости, и если обнаружит несоответствия, выдаст по ним сводку в таком виде:

А теперь изложим краеугольные камни выбора конфигурации.

Дисковые группы

Термин «дисковые группы» применяется к управляющим конструкциям vSAN из одного устройства кэширования и одного или нескольких емкостных устройств (от 1 до 7):

где HDD (как магнитные, так и механические) характеризуются скоростью вращения шпинделя для предоставления доступа к информации (7 200/10 000/15 000 RPM), а SSD (как правило, это флэши с SAS, SATA или NVMe интерфейсом) – жизненным циклом записей:

При этом первые используются на уровне емкости для гибридных конфигураций, а SSD – в гибридных только для кэша (чтение/запись), в all-flash же они предназначены не только для кэша (запись), но и для емкости.

Забегая вперед, заметим, что в одном хосте в составе кластера vSAN может быть не более пяти дисковых групп, но и не менее одной. Флэш-дисков кэширования при этом предусмотрено количество от 1 до 5 на каждый хост, а емкостных дисков – от одного до 35, независимо от их разновидности.

All-Flash или гибридная дисковая группа?

Существует принципиальная разница между all-flash и гибридной дисковой группой, участвующими в построении кластера vSAN:

Функции компрессии и дедупликации доступны только в all-flash-конфигурациях;
All-Flash не поддерживается сетевыми картами 1 Гбит/с (только Ethernet 10 Гбит/с);
Экономящая место функция Erasure Coding (RAID 5/RAID 6) работает только с all-flash;
В процессе чтения резервирование кэша в all-flash не используется – читается непосредственно с накопителей;
Флэш-устройства могут быть как емкостными, так и устройствами кэширования.

Важно! VMware настойчиво рекомендует остановиться на All-Flash-конфигурациях, ибо классы выносливости и производительности теперь важны как для емкостного уровня, так и для уровня кэширования. Они поддерживают 100 000 и более I/O операций/с на каждый хост.

Гибридные дисковые группы под кэширование требуют выделение минимум 10% емкости, при этом 70% этого объема распределяется на часто читаемые блоки дисков, а 30% – для буферизации записей.

Сеть vSAN

В трафике vSAN могут применяться стандартные свитчи, либо же Distributed Switch. Первые означают, что каждый хост обладает своим собственным стандартного типа свитчом, что же касается Distributed Switch, в нем каждая группа портов VMkernel подсоединяется к хосту, включенному в vSAN. Так как в лицензию vSAN входит DSwitch, рекомендуется его и использовать во всех случаях.

О требованиях к сети vSAN было сказано достаточно в статье «Инсталляция обновления VMware vSAN 7.0U1». И там же подробно описано, как организовать VMkernel Port и тиминг, какие порты назначать компонентам и т.п.

Файловые системы стораджей

ESXi-хосты используют в пространстве хранилища все многообразие видов физических систем хранения, включая внутренние и внешние устройства, а также доступный по сети сторадж. Конкретно, это три формата файловых систем, которые базируются на:

Файлах (сетевая файловая система NFS). До недавнего времени – превалирующая. Преимущества: данные складируются в файлах с лимитированными метаданными, файлы сгруппированы в иерархическую структуру директорий. Однако с ростом емкости хранилищ стала ограниченной за счет недостаточной вычислительной мощности и неэффективности файловых таблиц из-за их гигантского роста размера:

Блоках VMware vSphere (VMFS). Преимущества: файлы располагаются в линейках записей хранилища, данные разбиты равномерно внутри каждого тома, а параметры метаданных стали более однозначными для файлов в контейнерах. VMFS может обслуживать как непосредственно сторадж ВМ, так и почтовую или же любую другую базу данных:

Объектах VMware vSphere (Virtual Volumes и vSAN):

Важно! В выборе между NFS и VMFS отдавать предпочтение стоит последней. Если это не противоречит рекомендациям вендора СХД.

Об объектно-ориентированном хранилище – нашем vSAN – поговорим подробнее. В хранилище этого типа предусмотрено создание виртуальных машин самого широкого функционала и свойств. Это могут быть:

Единственный объект домашнего пространства имен (файлы конфигурации .log/.hlog/.nvram/.vmsd/.vmx);
1+ объекты VMDK (виртуального диска машины);
Thin-provision объект подкачки (создается, когда ВМ включается);
1+ дельта-объектов снэпшотов (создается, когда снимаются снэпшоты);
1+ объектов памяти ВМ (состояние виртуальной памяти машины, когда она обозначается как «suspended» или, когда сохраняется состояние ее виртуальной памяти при снятии снэпшота);
Объекты данных производительности vSAN;
iSCSI LUN-объекты.

Чтобы лучше понимать, что собой представляют эти объекты, вот их примерные аналоги в традиционной файловой системе:

Каждый формат должен быть выбран или создан специально с целью ассоциации с определенной ВМ.

Политики хранилищ

Политика объектно-ориентированного хранилища позволяет администратору среды легко подбирать правильное хранилище данных, на котором будет разворачиваться виртуальная машина.

Вообще же подбирать ту или иную конкретную политику необходимо из возможностей хранения. Она определяется для ВМ, ее диска, объектов памяти и других либо в момент разворота, либо позднее, так как ее можно поменять в любой момент.

Важно! Объекты снэпшотов виртуального диска исходят из политики своего родительского дискового объекта.

Применять к виртуальной машине можно, как только одну политику, так и несколько сразу. Это имеет смысл, к примеру, когда необходимо резервировать хранилище для различных VMDK, или же следует увеличить избыточность критически важных данных вне ОС.

А сейчас углубимся в суть и свойства параметров политик хранения в vSAN, чтобы в дальнейшем процедура конфигурирования или перенастройки была осознанной (о технической ее стороне рассказано в статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1»).

Site disaster tolerance и Failures to tolerate

Атрибут «Site disaster tolerance» применим исключительно к растянутым кластерам (ниже их обсудим самым подробнейшим образом). Он определяет метод избыточности данных, используемый кластером в случае сбоя сайта. При этом для растянутых кластеров разработаны три пути борьбы с проблемой:

дуальный мониторинг сайтов,
отключение функции, но с требованием хранить данные на первичном сайте,
отключение функции, но с требованием хранить данные на вторичном сайте.

Если же кластер к растянутому типу не относится, просто выбирается значение «None», соответствующее стандартному кластеру.

С Failures to tolerate все гораздо интереснее и VMware крайне рекомендует уделить этому атрибуту максимум внимания, так как без его грамотной настройки о защите хостов и устройств от сбоев говорить не приходится вовсе. Он задает количество сбоев, которые способна перенести виртуальная машина, и, в целом, выбор его в настройках политик хранения, где он и определяется, ограничивается такими вариантами:

«No data redundancy» (отказ от избыточности данных),
кол-во падений, определяемое конкретным типом RAID-политики:

Это решение дополняет политику хранения, и на практике, к примеру, может работать так. Если для большого по классификации объекта назначена отказоустойчивость на уровне 1 и применено зеркалирование, вместо двух компонентов у него будет четыре. Причем каждый из них будет размером в половину начального.

RAID-1 способен справиться с количеством сбоев от одного до трех и оптимизирован под производительность, используя зеркалирование, RAID-5 справляется с одним сбоем, а RAID-6 – с двумя, и эта последняя пара концентрируется на емкости. Познакомимся с ними ближе.

RAID-типы политик хранения vSAN

RAID 0 (чередующийся) – самая высокая производительность без избыточности. Но, если один диск будет потерян, данные также утратятся по причине не восстанавливаемости из-за недостатка избыточности;
RAID 1 (зеркальный) – хорошая производительность с полной избыточностью с удвоенным использованием емкости. Данные с одного диска отзеркаливаются на другой, полная их копия доступна, в случае чего, но производительность не максимальна;
RAID 10 (чередующийся + зеркальный) – идеальная производительность с удвоенным использованием емкости. По сути – комбинация первых двух типов. Он быстрее RAID 5/6, но с избыточностью RAID 1. Единственный минус – половина емкости не участвует, и это очень дорогое решение;
RAID 5 (чередующийся + паритетный) – хорошая производительность с избыточностью, при которой снижается скорость записи на диск по причине обработки паритетности. Данные пишутся по всем дискам сразу, и их количество пропорционально производительности. Выпадение одного диска не критично, но объем хранилища уменьшен на емкость диска с паритетными данными;
RAID 6 (чередующийся + двойной паритетный) – хорошая производительность с избыточностью, при которой снижается скорость записи на диск из-за обработки паритетности RAID 5. Это то же самое, что и RAID 5, за исключением добавления дополнительного блока паритетности. Дисковая группа может выдержать до двух конкурентных падений, так как сразу два блока паритетности пишутся по всей плоскости данных. Эти добавочные записи дают сниженную производительность, а используемая емкость хранилища уменьшена сразу на два диска.

Дисковые полосы

Параметр «Number of disk stripes per object» (от 1 до 12) определяет количество емкостных устройств, между которыми распределяется полосами каждая копия объекта vSAN. И назначая его следует учитывать такие моменты:

Увеличение количества полос редко влечет за собой рост производительности, так как новые полосы могут использовать другую дисковую группу, а могут располагаться и в той же самой, обращаясь к одному и тому же устройству кэширования;
Чем чаще «промахивается» кэш, тем большим должно быть значение атрибута.

Дефолтное значение «1», в большинстве случаев, удовлетворяет самому широкому спектру рабочих нагрузок виртуальных машин.

Важно! Для больших объектов vSAN (свыше 255 ГБ) политика хранения не ограничивает максимальную конфигурацию разбивки 12-ю полосами. Однако следует учесть, что, если объект нуждается в большем количестве полос, чем существует накопителей емкости, согласно политики запись будет вестись, в том числе, и несколькими полосами на один диск. При этом, если политикой определено чередование, система будет пытаться превысить количество дисков емкости, что приведет к невыполнению политики. Избежать этого можно включив force provisioning.

Контрольная сумма и лимиты IOPS

Лимиты IOPS – это ограничение на количество операций ввода-вывода в секунду в vSAN. С его помощью достаточно элементарно ограничиваются используемые VMDK ресурсы. Этот параметр напрямую связан с производительностью инфраструктуры.

Обоснование необходимости лимитрованности IOPS достаточно прозрачно: далеко не всегда самая загруженная машина в кластере является самой важной, однако, если ее «аппетиты» велики, «обокрасть» соседок, производительность которых, как раз, весьма критична, она всегда готова. В то же время, естественное стремление просто декларировать жесткие ограничения может сыграть злую шутку с системой. Дело в том, что размеры одной операции ввода-вывода могут быть разными – от 4 КБ до 1 МБ, и последний случай запросит гораздо больше ресурсов для обработки.

Эта проблема породила разработку взвешенного подхода к отражению размера I/O, что нашло свой отклик в настройках параметров политик хранения vSAN. Если там применить ограничение на операции ввода-вывода к объекту стораджа, начнет работать т. н. «правило приведения к 32 КБ»:

I/O < 32 КБ – засчитывается как единожды проведенная операция ввода/вывода;
32 КБ < I/O < 64 КБ – как две I/O и т.д., с равным шагом нормализации.

В результате за одно осуществление тяжелой операции не потратится в разы больше ресурсов, чем это будет происходить с маленькой I/O. Для наглядной демонстрации разницы между использованием нормализации лимитов IOPS и обычным, скажем, vSCSI IOPS, в рамках одного и того же VMDK, приведем соответствующий график производительности:

vSAN предоставляет инструментарий настройки политик хранения для воплощения этих ограничений, регулируя скорость запроса ресурсов дисками, благодаря задержке операций ввода/вывода в случае превышения пороговых значений. О том, как задавать параметры политик хранения или же редактировать значения уже назначенных для изменения лимитов IOPS, рассказано в статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Что же касается контрольной суммы, она по умолчанию включена и является сквозной с целью обеспечения целостности данных, предотвращая их повреждение, вызванное аппаратными или программными компонентами в процессе операций чтения или записи. В деталях, она делает следующее:

Автоматически обнаруживает и решает silent-ошибки дисков, скрытые ошибки секторов из-за физических неисправностей дисков;
Восстанавливает поврежденные данные с других зеркал или полос данных/паритетности либо же сообщает об этом пользователю, советуя предпринять те или иные меры;
Выполняет очистку диска раз в год в фоновом режиме (параметр периода очистки «ObjectScrubsPerYear» меняется в расширенных настройках ESXi-хоста).

Некоторые сценарии приложений и ряд операционных систем уже имеют встроенный механизм контрольной суммы, и тогда в vSAN ее необходимо отключить, чтобы излишне не нагружать систему. Это делается аналогично в «Advanced Policy Rules» настроек политик и процесс подробно описан в упомянутой выше статье.

Резервирование для Flash-кэша на чтение

По умолчанию, кэш-память дисковой группы разделяет кэш чтения поровну, опираясь на потребности его составляющих. Резервирование Flash Read Cache закрепляет эту часть кэширующего устройства под конкретный объект vSAN:

В политиках хранения он указывается в процентах (от 0 до 100) от логического размера объекта с четырьмя знаками после запятой. Для него справедливы следующие утверждения:

Зарезервированная емкость не может использоваться другими объектами;
Незарезервированная емкость равномерно распределяется между всеми объектами;
Когда увеличивается емкость SSD, при реконфигурации следует вписывать такое же соотношение Flash Read Cache к общему объему.

Значение по умолчанию установлено 0%, так как любое его увеличение влечет колоссальное резервирование места, которое, по большому счету, может никогда и не востребоваться. Особенно, когда речь идет о крупных инфраструктурах с большими емкостями накопителей. Например, даже если зарезервировать всего 1% под флэш-кэш на чтение на диске в 1 ТБ, в цифрах это будет целых 10 ГБ. Для одной виртуальной машины, как правило, это уже катастрофа.

Этот атрибут, преимущественно, полезен для гибридных конфигураций, так как на архитектуру all-flash он влияния не оказывает.

Резервирование места под объект

Когда разворачивается объект vSAN, под него резервируется определенное пространство VMDK. В политиках этот атрибут задается как процент от логического размера виртуального диска.

Глобально, существует три типа организации: Thin Provision, Thick Provision и конкретно определенное соотношение с VMDK. По умолчанию, значение в политиках всегда стоит Thin Provision, и это не удивительно, ведь таким образом выделение места на диске производится, по сути, on-demand – под объект будет выделяться ровно столько, сколько он занимает в данный конкретный момент времени с учетом всего сопутствующего функционала в отношении политик отказоустойчивости и т.п.

Чтобы в будущем было легче сделать выбор в пользу конкретного типа, приведем их сравнительную таблицу, в которой очень полно и доходчиво все расписано:

	Thick Provisioned Lazy-Zeroed	Thin Provisioned
Время создания	быстрое	самое быстрое
Распределение блоков	полностью предопределено	распределяется и обнуляется по требованию в момент первой записи в блок
Шаблон виртуального диска	повышенная вероятность непрерывности файловых блоков	шаблон вариативен в соответствии с динамическим состоянием тома в момент распределения блока
Обнуление выделенных файловых блоков	файловые блоки обнуляются, когда в каждый из них делается первая запись	файловые блоки обнуляются, когда распределяются

В случае vSAN, Thick Provision (lazy zero) – это жесткое резервирование. Как правило, «съедает» места гораздо больше, чем того требуется, однако полезна, если критично иметь точные расчеты общей емкости. Что же касается других вариантов (25/50/75%) – это просто выделение процента пространства, без учета чего бы то ни было, причем (и это важно!) совершенно несовместимое с функциями компрессии и дедупликации.

Force Provisioning

Этот атрибут включен в политики vSAN как силовой метод выделения ресурсов для создания виртуальной машины, игнорирующий жалобы системы, что у нее недостаточно хостов или дисков. В списке созданный объект получит статус соответствующего, только когда дополнительные ресурсы будут добавлены. Это своеобразное отложенное конфигурирование, позволяющее временно пользоваться ресурсами, адекватное, к примеру, если ожидается скорая поставка аппаратного оборудования для полноценной поддержки решения, но сроки разворота пользовательских машин уже поджимают.

По умолчанию, естественно отключено.

Важно! Созданные Force Provisioning ВМ имеют FTT = 0 и только одну полосу. Выход из положения, повторимся, временный и несерьезный с точки зрения защиты, производительности и выносливости инфраструктуры.

Принципы построения дизайна vSAN

vSAN – это, по сути, кластер хостов с заданными политиками хранения информации и выбранной комбинацией файловых систем, подключенный к соответствующим образом сконфигурированной сети и с организованными дисковыми группами. Об аппаратных и программных требованиях к нему написано выше в разделе «Совместимость и требования». Теперь же поговорим о его составе, возможностях и свойствах.

Как неотъемлемая часть гиперконвергентной инфраструктуры он пользуется ее родной системой шифрования данных, ускоряет и упрощает управление хранилищем и его использование, поддерживает масштабируемость и увеличивает вычислительную мощность, как таковую. Важно отметить, что он полностью интегрируем как с VMware vCloud, так и с NSX.

О кластере vSAN

Во-первых, в кластере vSAN может быть не менее трех хостов, но и не более 64 (для версии 7.0U1 продукта). О том, как их создавать и настраивать будет рассказано ниже в разделе «Подготовка к развороту vSAN 7.0U1». (Растянутый кластер – это отдельная тема для обсуждения, и на ней мы обязательно еще остановимся.) Виртуальных машин при этом он может включать до 8 000, если мы говорим о тех, которые можно защитить НА.

Определяясь с конфигурацией, важно правильно рассчитать CPU и память хостов. И учитывать при этом нужно следующее:

желаемое количество сокетов на один хост,
желаемое число ядер на сокет,
общее кол-во виртуальных машин и сколько каждая из них потребует vCPU,
желаемое соотношение числа vCPU и ядер,
желаемый объем памяти в каждой ВМ,
кол-во поддерживаемых дисков и дисковых групп.

Важно! Предусмотреть 10% запас ресурсов CPU или даже более, если планируется включать компрессию и дедупликацию.

С полезными формулами для расчета и другими нюансами можно ознакомиться в разделе «Требования к кластеру» статьи «Инсталляция обновления VMware vSAN 7.0U1».

Последний апдейт этого продукта предложил пропускать через инструмент vSAN Sizing все вопросы по параметрам инфраструктуры хранения. В его составе – замечательный функционал «Quick sizer», помогающий в выполнении калькуляции «от и до». Это мобильное приложение для Android и iOS-платформ:

Настоятельно советуем научиться им пользоваться вот здесь и постоянно применять на практике.

По понятным причинам, в дизайне гиперконвергентной структуры самое сложное – это не просто просчитать удовлетворяющую текущим задачам конфигурацию, но предусмотреть (в разумных границах) потенциальное расширение мощностей, а также реализовать все возможное для того, чтобы она давала максимальную производительность и при этом отличалась рентабельностью.

К слову, визард-установщик кластера vSAN «Quickstart», который обсудим ниже, позволяет быстро масштабировать инфраструктуру путем добавления хостов в уже существующий:

И все старые конфигурации, в том числе и сетевые, автоматически будут применены к новым хостам. При этом текущие операции не прерываются.

Подробно о масштабировании vSAN постараемся обязательно рассказать в еще одной посвященной этому продукту статье: «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Балансировка конфигурации

Best practice – сконфигурировать сбалансированный кластер. То есть такой, в котором все ноды имеют идентичную настройку. Тогда компоненты хранилища будут распределены равномерно, емкость станет использоваться оптимальнее, а потеря узла не повлияет на производительность.

Важно! Иногда балансировка кластера невозможна, в принципе. Например, когда уже существующую инфраструктуру vSAN пытаются расширить: аналогичное старому оборудование бывает очень трудно достать, а менять все на новое – неоправданно накладно. В этом случае осознанно идут на асимметричность, добавляя более емкие и быстрые устройства, однако, обязательно равное их количество на каждый хост. И тогда рекомендовано не забывать про включение EVC.

Host Rebuild Reservation (HBR)

Функция Host Rebuild Reservation (HBR) позволяет зарезервировать место, куда можно восстановить хост после падения в асимметричных структурах. Это не множественная практика – предназначена она для единичного случая, и ничего общего с тотальной организацией fault domain не имеет. Причем работает не только конкретно с падением, но и с выпадением хоста в окно техобслуживания. В некотором роде полезная с точки зрения подстраховки вещь, однако перманентно «съедающая» объем хранилища, равный самому большому хосту.

С растянутым кластером, кластером с доменами отказа, ROBO-лицензией и кластерами, в которых менее четырех хостов, функция не работает.

Важно! Если емкость кластера выше определенного предела, HBR вообще не включится. Более того, нужно учитывать, что даже сам факт ее включения резервирует 5% дополнительной емкости под свои внутренние операции.

Отслеживает опасное приближение к этим границам vSAN сам, посылая предупреждения в хелс-чек. Кстати, именно из-за включения этой функции, если вовремя не освободить требуемое место, среда начнет блокировать процедуры создания новых ВМ, снятие снэпшотов, создание виртуальных дисков и прочие операции.

Best practice: вместо HBR рассмотреть альтернативные решения, подходящие для асимметричных структур. Например, применять односокетовые сервера для нагруженных рабочих процессов хранилища. Или же развернуть хосты с пустыми отсеками, чтобы потом в них можно было спокойно добавлять диски без необходимости наращивать количество нод.

Множественность дисковых групп

Настоятельно рекомендуется применять разделение группы дисков для каждого хоста. Сравнение с одиночной организацией наглядно продемонстрировано на схеме:

Множественность групп дисков имеет следующие преимущества:

Если отказывает единственная дисковая группа в хосте – может отказать весь хост;
Множественная организация позволяет гибко настраивать масштабируемость структуры;
Выше производительность, так как рост количества устройств кэширования позволяет увеличить количество I/O.

Растянутый кластер

Растянутые кластеры используются в средах, где крайне важно предотвратить факты простоев и аварий. Они защищают данные не только в стойках хранилищ, но и во всем дата-центре.

По своей структуре, это – кластер vSAN с двумя активно-активными сайтами и третьим хостом-свидетелем:

Важно! У каждой пары защищаемых сайтов может быть только один witness-хост.

При этом два защищаемых сайта делят между собой равное количество хостов (до 15 штук на каждом), обязательно организованных в fault domain, и между ними настроен канал связи с низкой задержкой и высокой пропускной способностью (оба сайта, к тому же, должны иметь выход в сеть vMotion для стандартных миграций). Сайт-свидетель подключен к ним обоим и, как только что-то случается с любым из защищаемых сайтов (неважно, это окно техобслуживания или реальный сбой), он принимает на себя нагрузку. При этом связь между witness-сайтом и каждым активно-активным сайтом может иметь высокие задержки и низкую пропускную способность – на результат бесперебойного использования это не влияет. О требованиях к сетевым характеристикам и прочих рекомендациях подробно говорилось в разделе «Требования к сети» статьи «Инсталляция обновления VMware vSAN 7.0U1».

Один из защищаемых сайтов обязательно назначается как «preferred», а другой – вторичным. По умолчанию, предпочитаемый сайт используется, когда между двумя сайтами с данными случился раздел сети. При этом сайт-свидетель все так же может общаться с ними обоими. Как только пропадает сеть между сайтами, хост-свидетель и preferred-сайт продолжают обслуживать операции хранилища и предоставляют пользователям доступ к данным. Когда же связь восстанавливается, активные сайты ресинхронизируются.

Часто хост-свидетель – это ESXi хост, либо соответствующий ESXi Virtual Appliance. Для его организации и налаживания связи внутри растянутого vSAN-кластера существуют встроенные механизмы в самом хранилище. Ниже, когда будем рассматривать создание нового кластера vSAN при помощи Cluster Quickstart, процесс будет подробно описан. А чтобы к нему перейти, на этапе конфигурирования в пункте «Advanced options» там, где «Deployment type» выбираем из выпадающего меню «Stretched cluster»:

Важно! Хост-свидетель не является членом кластера. Он не может стартовать ВМ, которые запускались до того на хосте. И вообще на нем нельзя создавать виртуальные машины, как таковые.

Готовый результат создания кластера vSAN с witness-хостом будет выглядеть примерно так (свидетель, очевидно, стоит особняком):

В выборе размера хоста-свидетеля, стоит опираться на такую табличку:

О системе PFTT и fault domain рассказывалось в статье «Инсталляция обновления VMware vSAN 7.0U1». Этот момент аналогично стоит предусмотреть в разработке дизайна vSAN 7.0U1, если хотим сделать свою инфраструктуру отказоустойчивой, безопасной и высокопроизводительной.

Растянутый кластер может с успехом использовать технологии vSphere Replication и Site Recovery Manager. То есть доступна настройка динамической миграции машин и автоматический перезапуск НА. При этом vCenter Server должен быть проинсталлирован и на защищаемом сайте, и на сайте восстановления (автономный кластер с одним vCenter Server не поддерживается). Схема в данном случае получается посложнее, но и защита, бесспорно, вырастает на порядок:

Политики хранения в растянутых кластерах применяются к объектам vSAN и, глобально опираются на:

отказоустойчивость связи между сайтами («Site disaster tolerance»),
отказоустойчивость каждого сайта в составе («Failures to tolerate»).

Суммарно это дает полную отказоустойчивость, и выбираются соответствующие назначения при создании политик хранения ВМ:

О том, как их задавать, мы поговорим в другом нашем материале – «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Двух-нодовые кластера

Создание двух-новодового кластера позволяет обойти минимальное требование vSAN по количеству узлов в нем. Управляемость, производительность и доступность при этом будет выше, однако хост-свидетель внутри него избавляет от необходимости обязательно организовывать третий физический хост:

По факту, он состоит из двух физических хостов и одного свидетельского Virtual Appliance. Внутри них, естественно, создается fault domain.

Это идеальная схема для небольших сред ROBO-лицензии, так как удаленные офисы могут управляться централизовано с одного инстанса vCenter Server. К тому же и данные, благодаря наличию witness-хоста, защищены эффективно:

Рекомендуется подключать удаленный сайт к главному по 10 Гбит/с сети с задержкой, примерно, в 150 мс, и оба они должны быть непосредственно соединены кабелем. При этом двух-нодовый кластер разворачивается целиком на удаленном сайте, а вот хост-свидетель, как раз, в главном офисе, дабы обеспечить лучшую защиту информации и повысить управляемость. Witness-узел использует дополнительный NIC – ни в коем случае не прямое кабельное подключение.

Конфигурирование vmknic должно обеспечивать трафик свидетеля, и сделать это можно командой:

esxcli vsan network ipv4 add -i vmkX -T=witness

Интересно, что и двух-нодовый кластер можно организовать как растянутый: его отличие от классики в том, что две базовые ноды разнесены географически. Правда, это – уже случай Enterprise-лицензии. Создается он точно так же, как и обычный, аналогично организуются предпочитаемый и вторичный сайты, но в каждом домене будет всего один хост.

Дедупликация и компрессия

Задача дедупликации и компрессии – минимизировать потребление емкости хранилища, повышая его производительность и доступность:

Эти функции работают только на уровне кластера. В их отношении следует учесть, что не ко всем файлам они применимы одинаково эффективно: некоторые типы дедуплицируются и сжимаются лучше других. Включение происходит в момент удаления данных с уровня кэша и помещения на уровень емкости.

Дедупликация – это удаление избыточных блоков данных. Компрессия – удаление дополнительных избыточных данных в каждом блоке. Применение этих методов эффективно исключительно в тандеме.

Чтобы включить эти функции, на этапе создания нового vSAN-кластера в Cluster Quickstart при конфигурировании в строке «Deduplication and compression» пункта «Advanced options» переводим ползунок в активное состояние:

Шифрование

Шифрование в vSAN работает с данными на уровне дисков в составе хранилища. Его главные свойства и преимущества таковы:

data-at-rest шифрование для всех объектов стораджа на уровне хранилища,
индивидуальная конфигурация для каждого кластера,
поддержка гибридных, all-flash, растянутых и двух-нодовых кластеров,
не нужны самошифрующиеся диски,
совместимость со всеми функциями vSAN,
работа с Key Management Interoperability Protocol (KMIP) совместимыми системами управления ключами (KMIP 1.1).

Его можно включать прямо в процессе создания нового кластера vSAN (об этом расскажем ниже), либо на уже существующих кластерах хранилища данных (об этом будет в статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1»):

Важно! Операция включения/выключения шифрования требует последовательного изменения формата дисков (формат дисков с шифрованием отличается от формата без) и может занять значительное время.

Использование шифрования в vSAN требует наличия соответствующего уровня лицензии. Это – Enterprise, причем покупается такая лицензия на каждый CPU/виртуальный десктоп, либо же это на каждый ROBO (25-pack) лицензирование.

Разрешенное в vSAN шифрование использует XTS AES 256 кодировку и на уровне кэша, и на уровне емкости. Оно не зависит от оборудования и совместимо с любыми аккредитованными текущей версией vSAN устройствами. Все функции vSphere, в т. ч. vMotion, Distributed Resource Scheduler, НА и Replication поддерживаются родным шифрованием.

Организация шифрования требует создания отдельного сервера Key Management Server (KMS) (или кластера KMS – по одному на каждый инстанс vCenter Server), к которому напрямую будут обращаться хосты. Несколько замечаний по организации кластера KMS:

Группа серверов этого кластера должна быть построена на KMIP и реплицировать ключи друг другу;
Кластер выбирать только моновендорный;
При создании указывать единственную точку отказа.

Важно! Сервер KMS или кластер должны располагаться вне хранилища данных vSAN.

Логика кластеризации серверов шифрования проста: если первый в списке KMS недоступен, vCenter Server попытается обратиться к следующему и т. д. Это отличная подстраховка процедуры шифрования, ведь помимо этого ключ запрашивается в процессе репликации ключей у любого из серверов, и так – по цепочке. Даже если один из них выйдет из строя, на безопасность это не повлияет.

К слову, и кластер такой может быть не один, но обязательно следует назначить какой-то из них по дефолту, чтобы к нему шли запросы от vCenter на получение новых ключей.

Клиентские сертификаты зависят от выбора вендора: у кого-то разрешены самосозданные, кто-то принимает только сгенерированные KMS доверенные и т.д. Конкретизировать этот момент следует всегда только с поставщиком решений.

Для глубокого понимания системы шифрования в vSAN, опишем процесс его работы в деталях:

vCenter Server запрашивает AES-256 KEK (key encryption key) от KMS и хранит у себя только ID KEK;
Затем он рассылает KEK ID всем хостам;
Хосты используют KEK ID для запроса KEK от KMS;
Они создают уникальные DEK (disk encryption key) для каждого диска – теперь в хранилище vSAN каждый диск зашифрован своим индивидуальным DEK;
KMS генерирует единственный ключ хоста HEK (host encryption key), рассылает его всем хостам в кластере для использования в шифровании дампов ядра:

Сore dump – это состояние памяти, зафиксированное в момент прекращения выдачи ответов на запросы к системе. По умолчанию они хранятся в партиции «/var/core» ESXi-хоста. КЕК и HEK хранятся в памяти и включаются в зашифрованный дамп ядра. Кстати, именно core dump помогает службе поддержки VMware провести диагностику причин фиолетовых «экранов смерти» и других ошибок. Если интересно, больше на эту тему почитать можно здесь.

В завершение разговора о шифровании данных в vSAN стоит упомянуть два его типа:

data-at-rest,
data-in-transit.

Первый защищает данные на устройствах хранения глобально, даже в случае удаления их из кластера, а второй – в процессе их движения по кластеру.

Data-in-transit использует AES-256-битное шифрование, благодаря которому шифруется не только движение внутри кластера, но и передача данных между активно-активными хостами и свидетелем, а также трафик файловой службы между клиентскими серверами и прокси-сервером VDFS. Речь о динамическом генерировании симметричных ключей при установке соединения и обеспечении связи лишь с доверенными хостами, каждый из которых проходит этап аутентификации при включении в кластер.

Data-at-rest – это шифрование данных в состоянии покоя, по окончанию всех операций обработки. Даже если устройство удалить из кластера, информация на нем будет надежно защищена. И вот как раз этот тип шифрования обязательно требует наличия внешнего KMS. Кстати, выше описана схема работы именно data-at-rest.

Включаться и выключаться обе эти разновидности шифрования могут автономно друг от друга. Подробно об их применении поговорим в статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Подготовка к развороту vSAN 7.0U1

Перед тем, как приступать непосредственно к формированию кластера vSAN, следует и выполнить такие условия:

Подготовить серверы, соответствующие VCL в разрезе аппаратной части, в количестве n+1;
Развернуть на всех серверах ESXi 6.7 (8169922) или новее;
Для управления этими хостами поднять vCenter Server 6.7 (8217866) или новее;

Важно! Версия vCenter Server должна совпадать с ESXi или быть свежее. О том, как обновиться до последней версии компонентов vSphere мы писали в статьях: «Переход с ESXi 6.7 на ESXi 7.0 Free» и «Инсталляция и разворот VMware vSphere 7.0».

Настроить интернет-подключение к vCenter так, чтобы база данных VCL в разрезе аппаратной части могла автоматически обновляться;
Настроить DHCP, DNS и NTP в виртуальной среде;
Все хосты ESXi, кроме одного, поместить в один новый кластерный контейнер в vCenter, выключив для него функции DRS, HA и vSAN (если ранее были включены) и далее следить, чтобы они в процессе не включались;
Подключить каждый хост к vmkernel и сконфигурировать vmkernel сети vMotion (подраздел «Назначение VMkernel для vSAN» в сетевых требованиях раздела «Требования и совместимость» статьи «Инсталляция обновления VMware vSAN0U1»);
(Опционально) Для тестов операций Storage vMotion организовать дополнительный тип хранилища данных (NFS или VMFS) под каждый хост;
Организовать пул IP-адресов, на каждый ESXi-хост по одному. Адреса должны быть из одной и той же VLAN и даже одинакового сегмента сети.

Если изначально дизайн будущего хранилища предусматривал использование шифрования, процедура подготовки к развороту увеличится еще на несколько пунктов проверки:

наличия свободного места на дисках для выполнения их эвакуации в процессе изменения их формата;

Важно! Смену формата дисков надо планировать в производственные окна.

отсутствия любых ресинхронизационных процессов;
работоспособности кластера (хелс-чек зеленый);
дискового формата: должен быть версии 5 и выше (если старше – последовательно обновиться до приемлемого);
отсутствия перегрузок.

И непосредственных мероприятий:

Установить сервер KMS, совместимый с KMIP 1.1 и настроенный с KMIP прокси-сервером, имеющий доступ по IP;
Добавить этот сервер (настроить как доверенный) в vCenter Server;
Наладить связь между ним и vCenter Server по безопасному каналу (если инстансов vCenter больше одного, все они должны подключаться к одному KMS-серверу):

Разрешить в правах учетной записи администратора, под которой и будет формироваться новый кластер vSAN, атрибуты: «Inventory.EditCluster», «Cryptographer.ManageEncryptionPolicy», «Cryptographer.ManageKMS», «Cryptographer.ManageKeys».

Организацию сервера KMS и дальнейшие с ним действия, а также включение шифрования в vSAN в деталях обсудим в статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Когда все будет готово, разворот vSAN 7.0U1 может пойти несколькими путями:

Предустановленным – опцией «Quickstart» в разделе «Configuration» вкладки новосозданного кластера (включение кластерных служб vSphere DRS, НА и vSAN; добавление хостов; конфигурирование, включая DVS, настройку трафика, назначение дисков и доменов отказа):

Кастомизированным – если в верхней части этой вкладки нажать на кнопку «Skip Quickstart». Этот же вариант используется, когда на существующем кластере включается vSAN.

Первый способ доступен прямо из веб-клиента vSphere. Его крайне рекомендует сам вендор как наиболее быстрый и безошибочный способ достижения цели назначения и конфигурирования кластера vSAN. Особенно актуально для средних и более крупных классов сред.

Позволить себе пропустить этот мастер-установщик упомянутой кнопкой могут только продвинутые виртуализаторы – в этом случае конфигурировать кластер нужно полностью вручную.

Важно! Если нажать «Skip Quickstart», обратно к помощнику и автоматизации процесса кластеризации вернуться будет нельзя.

Создание кластера vSAN с помощью Cluster Quickstart

Сразу после изъявления желания создать новый кластер в веб-клиенте vSphere (правой кнопкой на дата-центре и в выпавшем меню выбрать «New Cluster»), интерфейс выдаст окно вида:

в котором нужно прописать имя будущего кластера и включить vSAN (на DRS и НА ползунки обязательно выключаем). Появится окно мастера-установщика, в котором, как мы видим, первый шаг уже отработан:

Далее делаем так:

Для включения хостов в этот новообразованный кластер жмем кнопочку «Add»;
В окне «Add hosts» в первом одноименном пункте визарда нам предложит определить добавляемый хост по его IP или FDQN, а также ввести для него логин и пароль администратора:

Можно добавить сразу много хостов, вписывая их идентификаторы под первым. Повторять пароли, если они одинаковы для всех хостов, необязательно: вверху можно поставить галочку на «Use the same credentials for all hosts»;

По кнопке «Next» попадаем в следующее окно предупреждения по безопасности, требующее вручную проверить сертификаты всех нижеперечисленных отпечатков SHA1 наших хостов:

В пункте «Host summary» появится список добавленных хостов с указанием их версии ESXi. Если все устраивает, жмем «Next»;
«Ready to complete». Просуммировано количество добавленных хостов и представлен их список по адресам ниже. Есть предупреждение о том, что выбранные хосты сейчас отправятся на техобслуживание и может понадобиться их выключение или же миграция включенных и приостановленных ВМ. Если все правильно, заканчиваем добавление хостов в новый кластер кнопкой «Finish».

Теперь окно Cluster Quickstart будет выглядеть так:

Все критические замечания будут показаны здесь:

С черными и красными предупреждениями надо выяснить отношения сразу – они критичны для успешности разворота vSAN. Желтые, если хочется, можно пока оставить в покое – это просто замечания о не идеальности, так сказать.

Время перейти к последнему – третьему – шагу создания кластера: к его настройке. Жмем кнопку «Configure» внизу и пройдемся по пунктам выскочившего диалогового окна конфигурации:

«Distributed switches». Если пока не уверены в сетевых настройках, можно поставить галочку в «Configure networking settings later», чтобы настроить ее позднее. Однако, раздел «Подготовка к развороту vSAN 7.0U1» выше нами пройден в деталях, поэтому такой проблемы, вероятно, не будет. Оставляем количество Dswitch равное «1» и вписываем его имя:

Скроллим вниз экран: будут еще поля о назначении группы портов и физических адаптеров (если последнее необходимо). По кнопке «Next» отправляемся далее:

«Storage traffic». Конфигурируем параметры трафика. Ставим галочку на «Use VLAN», выбираем сетевой протокол и тип IP, после чего продвигаемся дальше «Next»:

«Advanced options». Здесь назначается, при необходимости, продвинутый функционал vSAN: тип разворота (в т. ч. растянутый кластер или обычный), нужно ли включать локдаун-режим, дедупликацию и компрессию, шифрование, а также EVC:

«Claim disks». Для дисков кластера система сразу назначит роли – кэша или емкостного. Эту информацию нужно перепроверить и подтвердить:

«Create fault domains». В появившемся окне можно настроить домен отказа для включенных нами в кластер хостов. Для этого придумываем ему имя и проставляем галочки в списке напротив тех хостов, которые в него хочется включить:

В случае растянутого кластера окно конфигурирования fault domain будет выглядеть так:

«Select witness host». Выбираем хост-свидетель для растянутого кластера:

Внизу показывается состояние проверки на совместимость, и, если строка зеленая, – жмем «Next».

«Claim disks for witness host». Выбираем диски для кэша и емкостные под хост-свидетель:

«Ready to complete». Проверяем, все ли настройки были сделаны верно, после чего завершаем конфигурирование кластера кнопкой «Finish».

Какое-то время будет висеть бар прогресса, после чего можно считать, что кластер vSAN у нас готов.

Создание кластера vSAN вручную

Если по каким-то причинам мастер-помощник «Cluster Quickstart» не подходит, или же уже есть в наличии кластер, но пока без vSAN, поступаем следующим образом:

Заходим в меню веб-клиента vSphere и выбираем там «Hosts and Clusters»;
Кликаем на кластер, на котором хотим развернуть vSAN, и заходим на вкладку «Configure»;
Выбираем «Services» и нажимаем кнопку «CONFIGURE», после чего откроется мастер-установщик:

Здесь можно выбрать «Single site cluster» (каждый хост подразумевает, что он принадлежит своему собственному fault domain), «Two host vSAN cluster» или «Stretched cluster» (про оба и соображения насчет их выбора писалось выше в подразделе «О кластере vSAN» раздела «Разработка дизайна vSAN 7.0U1»). Переходим далее по «Next»;

«Services». В сервисах включается дедупликация и компрессия, а также шифрование при необходимости (обо всем писалось в том же подразделе «О кластере vSAN»). «Next»;
«Claim disks». В этой секции будет показан список доступных дисков, в котором при помощи выпадающего меню в каждой строке выбираем для чего они предназначены – для кэширования или емкости (best practice: одинакового типа «Flash» и для того, и для другого). Кроме того, здесь нужно проверить, правильно ли определился их тип:

«Next»;

«Create fault domains». По желанию, назначаем домены отказа по аналогии с тем, как это делается в Quickstart-помощнике. Жмем «Next»;
«Ready to complete». Проверяем всю назначенную конфигурацию и завершаем включение этого кластера в vSAN кнопкой «Finish».

После того, как кластер vSAN развернулся одним из вышеописанных методов, можно задавать настройки новых политик хранения и редактировать старые, разворачивать виртуальные машины в нем и применять к ним определенную политику, использовать функционал доменов сбоя, дедупликации, компрессии и шифрования, а также встроенные опции режима техобслуживания. Наконец, получить в помощники широкие возможности мониторинга и масштабирования при администрировании виртуальных хранилищ своей гиперконвергентной инфраструктуры. Но, обо всем этом мы поговорим в нашей следующей посвященной продукту vSAN статье «Настройка, мониторинг и администрирование VMware vSAN 7.0U1».

Если же хочется узнать больше о сложных случаях разворота и конфигурации, приобрести практические навыки организации растянутых кластеров со всеми их особенностями, научиться более тонко настраивать политики защиты и связь между компонентами vSAN-кластера, обязательно постарайтесь попасть на авторизованные курсы VMware по этой тематике.