Инсталляция обновления VMware vSAN 7.0U1

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

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

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

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

Требования к дисковому формату

vSAN 7.0U1 функционирует лишь с дисковыми форматами версии 13.0. Версия 1.0 вообще более им не распознается. Этот устаревший дисковый формат не работает со снэпшотами, дедупликацией, компрессией, шифрованием и контрольными суммами (то есть со всем, что предлагает расширенный функционал современного vSAN), а его производительность совершенно не выдерживает критики.

Важно! Не получится проапгрейдить дисковый формат 1.0 средствами vSphere Update Manager или esxcli для vSAN 7.0U1. Единственный выход: перенести информацию, уничтожить диски этой версии и установить новые, минимум 3.0-формата.

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

Одним из подводных камней процесса обновления дискового формата может стать недостаточная емкость кластеров или использование двух-трех-нодных кластеров. Из-за этого эвакуация дисковой группы версии 1.0/2.0 может не пойти вообще. Чтобы решить проблему следует в клиенте vSphere выбрать «Allow Reduced Redundancy»:

или же использовать команду:

vsan.ondisk_upgrade –allow-reduced-redundancy

Учтите, что после этого разрешения виртуальные машины остаются незащищенными, так как подобный метод не переносит данные на другие кластеры хоста. Он удаляет дисковую группу, апгрейдит ее формат, а затем добавляет ее снова в кластер. Избыточность при этом снизится и все объекты снова станут доступны.

Требования к физическому оборудованию

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

Устройства хранилища для хостов vSAN

Компонент хранилища	Требования
Кэш	Один SAS или SATA SSD, либо PCIe флэш-устройство.
	Обеспечить не менее 10% памяти предполагаемого хранилища для кэширования + реплики (зеркала и др.) для каждой группы дисков в случае гибридного кластера. Подробности можно изучить здесь.
	vSphere Flash Read Cache не должен использовать ни одно флэш-устройство, зарезервированное под кэш vSAN.
	Флэш-устройства кэширования не должны форматироваться VMFS или другой файловой системой.
Виртуальная машина хранилища данных	В случае гибридной конфигурации группы убедиться, что минимум один SAS или NL-SAS магнитный диск доступен.
Виртуальная машина хранилища данных	Если используется дисковая конфигурация, построенная исключительно на флэш-устройствах, минимум один SSD SAS или SATA, либо же флэш-устройство PCIe доступны.
Контроллеры хранилища	Один SAS или SATA HBA, либо же RAID-контроллер работает в passthrough-режиме или режиме RAID 0. Проверить поддержку контроллером функций можно здесь.

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

Важно! Когда используются диски не из vSAN-групп для VMFS, для создания дампов ядра, журналов и резервных копий следует применять только хранилище данных VMFS.

Важно! Не запускайте виртуальные машины с диска или группы RAID, чей контроллер используется совместно с дисками или RAID-группами vSAN.

Важно! Нельзя передавать диски не из vSAN-групп на гостевые ВМ в качестве Raw Device Mapping (RDM).

Если интересует тема комбинирования в одном контроллере хранилища дисков vSAN и прочих, обязательно почитайте, что о них написано здесь.

Память

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

Для версий vSAN 6.2 / ESXi 6.0U3 и всех более поздних, калькуляция памяти производится с использованием очень простой полезной формулы:

vSANFootprint = HOST_FOOTPRINT + NumDiskGroups * DiskGroupFootprint,

где:

HOST_FOOTPRINT – фиксированное количество памяти, потребляемое vSAN на каждом ESXi-хосте, независимо от дисковых групп (это константа – 7100 МБ);
NumDiskGroups – количество дисковых групп в хосте (от 1 до 5);
DiskGroupFootprint – количество памяти, выделенное каждой отдельной группе дисков на хосте.

DiskGroupFootprint, в свою очередь, рассчитывается по формуле:

DiskGroupFootprint = DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT,

где:

DISKGROUP_FIXED_FOOTPRINT – фиксированное количество памяти, выделенное для каждой отдельной дисковой группы на хосте (константа – 1360 МБ для all-flash и 1610 для гибридных);
DISKGROUP_SCALABLE_FOOTPRINT – память, выделенная для каждой отдельной дисковой группы, исходя из количества физической памяти ESXi-хоста (0,5% системной памяти);
CacheSize – размер кэша диска (в ГБ, для SSD – от 0 до 600, для гибридного – от 0 до 2 ТБ);
CACHE_DISK_FOOTPRINT – количество памяти выделенное каждому гигабайту кэша диска (константа – 20 МБ для all-flash и 10 МБ для гибридных);
NumCapacityDisks – количество емкостных дисков в каждой дисковой группе;
CAPACITY_DISK_FOOTPRINT – количество памяти, выделенной на каждый емкостный диск, независимо от его размера (константа – 180 МБ для гибридных и 160 МБ для all-flash).

Важно! Для дисковых групп с включенной функцией «compression-only» на каждый емкостный диск следует накинуть 39,5 МБ.

Важно! Для дисковых групп с включенной дедупликацией на каждую дисковую группу надо дополнительно предусмотреть 120 МБ памяти.

Важно! Для гибридных конфигураций, параметр DISKGROUP_SCALABLE_FOOTPRINT может равняться не 0,5% системной памяти, а 0,2% размера кэша диска, смотря, какое из значений меньше.

Диски кэша для всех flash-устройств ограничены 600 ГБ, поэтому использование SSD большего объема не потребляет дополнительной памяти.

Также стоит учесть, что vSAN сокращает использование памяти, если у хостов менее 32 ГБ памяти, и что он потребляет дополнительную память, если количество нод в кластере превышает 32.

Загрузочные флэш-устройства

В процессе инсталляции ESXi создается coredump-партиция на загрузочном устройстве. Размер ее, по умолчанию, удовлетворяет требованиям установки.

При этом различают два случая:

Размер памяти ESXi-хоста меньше 512 ГБ. В качестве загрузочного устройства можно использовать любое USB, SD или SATADOM устройство. Первые два должны быть не менее 4 ГБ.
Размер памяти ESXi-хоста больше 512 ГБ. Можно загружать с SATADOM (single-level cell (SLC)) или дискового устройства, объемом не менее 16 ГБ. Для версии vSAN 6.5 и выше нужно изменить размер coredump-партиции на ESXi-хосте для загрузки с USB/SD-устройств. Больше о соответствующих партициях можно почитать здесь.

При загрузке ESXi хоста 6.0 или новее версии с USB или SD-карты, логи трассировки vSAN пишутся на RAMDisk. Они автоматически выгружаются на постоянный носитель при завершении работы или системного краша. При сбое питания логи трассировки vSAN не сохраняются.

При загрузке ESXi хоста 6.0 или новее версии с SATADOM-устройства, логи трассировки vSAN пишутся непосредственно на SATADOM. Очень важно, чтобы это устройство отвечало требованиям вышеупомянутым требованиям.

Требования к кластеру

Стандартный кластер vSAN состоит минимум из трех хостов, каждый из которых вносит свой вклад в общую емкость. Для двух-нодового кластера обязательно организуется внешний хост-свидетель:

Соответствующие минимумы и максимумы:

*Доступна двух-нодовая конфигурация.

Проектирование и размер отказоустойчивых структур vSAN

Чтобы справиться с падениями хоста обязательно настраивается атрибут PFTT (Primary level of failures to tolerate) в политиках хранения виртуальных машин. В любом случае количество хостов в отказоустойчивой структуре рассчитывается по формуле:

2 * PFTT + 1

Большее расчетное количество сбоев – большей емкости хосты требуются.

При подключении хостов кластера к rack-серверам, можно организовать их в fault domain для повышения отказоустойчивости, в частности, для противостояния сбоям свитча в верхней части стойки и потерям питания. Для этого домены сбоя распределяют компоненты резервации по серверам в отдельных вычислительных стойках. Каждый из них включает минимум один хост и должен отвечать требованиям к аппаратной части (см. выше).

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

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

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

Обеспечить достаточное количество доменов сбоя, удовлетворяющее расчётному PFTT (минимум – 3, в идеале – 4 и более);
Назначить одинаковое количество хостов каждому fault domain;
Использовать хосты с одинаковыми конфигурациями;
Выделить один домен сбоя свободной емкости для восстановления данных после сбоя.

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

В случае с тремя хостами, только один сбой отработается. При этом каждая из двух необходимых реплик данных виртуальной машины будет расположена на разных хостах:

Важно! Для трех-хостовой структуры, если один из хостов уйдет на техобслуживание, vSAN не сможет эвакуировать данные с него. Любой дополнительный сбой катастрофичен в этом режиме. В этой ситуации рекомендуется обязательно использовать опцию «Ensure accessibility» при эвакуации:

Она гарантирует, что объекты останутся доступными и на протяжении миграции данных.

Двух-трех-хостовые конфигурации не соответствуют политике отказоустойчивости.

Требования к сети

Общие требования по каждому сетевому компоненту для vSAN:

Пропускная способность хоста. Напрямую выделяется 1 Гбит/с для гибридных конфигураций, и напрямую выделенные или общего доступа 10 Гбит/с для конфигураций all-flash;
Связь между хостами. Каждый хост в кластере, неважно, дает ли он емкость, должен обладать сетевым адаптером VMkernel для трафика vSAN;
Сеть хоста. Все хосты vSAN-кластера должны быть подключены ко 2-го или 3-го уровня сети vSAN;
Поддержка IPv4 and IPv6:

Сетевые задержки. Между всеми хостами в кластере задержки должны быть, максимум, 1 мс (для стандартных, нерастянутых), 5мс (между двумя главными сайтами растянутого кластера), 200 мс (между главным сайтом и хостом-свидетелем).

Транспортные протоколы и порты

Важно! На хостах vSAN версии 6.6 и более поздних мультиадресные порты 12345 и 23451 не требуются.

Пропускная способность хоста

Трафик vSAN может использовать 10-GbE физические сетевые адаптеры совместно с другими типами системного трафика (vSphere vMotion, vSphere HA и трафиком виртуальной машины). Гарантировать пропускную способность в этом случае будет vSphere Network I/O Control в vSphere Distributed Switch:

А назначить Distributed Switch можно так:

В vSphere Network I/O Control настраивается резервирование и совместное использование для исходящего трафика vSAN:

Например, на управляющем трафиком vSAN, vSphere vMotion и трафиком виртуальных машин 10-GbE физическом адаптере задаются следующие параметры:

Если адаптер перегружен, Network I/O Control выделяет 5 Гбит/с для vSAN на физическом адаптере.

Назначение VMkernel для vSAN

Порядок действий при предоставлении сетевого адаптера VMkernel трафику vSAN на каждом ESXi-хосте:

Заходим на хост во вкладку «Configure»;
В «Networking» выбираем «VMkernel adapters» и кликаем на иконку «Add Networking», после чего откроется мастер-установщик:

«Select connection type» – выбираем «VMkernel Network Adapter», затем жмем «Next»:

«Select target device» – задаем конфигурацию целевого свитча:

«Port properties» – выбираем «vSAN»:

«Ready to complete» – проверяем конфигурацию и заканчиваем по «Finish».

Отказоустойчивость сети и балансировка нагрузки

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

В настройке группы сетевых адаптеров используются следующие конфигурации аварийного переключения:

Маршрутизация на основе исходного виртуального порта (активно-пассивная).
Маршрутизация на основе IP-хэша (активно-активная со статическим EtherChannel для стандартного свитча и канала LACP-порта распределенного коммутатора).
Маршрутизация на основе загрузки физического сетевого адаптера (активно-активная).

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

Важно! В одной подсети не поддерживается несколько адаптеров VMkernel. Разные VMkernel-адаптеры могут использоваться в разных подсетях. Это обусловлено нерентабельным ростом расходов на настройку и организацию сетевой инфраструктуры. Доступность сети повышается за счет тиминга физических сетевых адаптеров.

Важно! В vSAN 6.6 и новее многоадресная пересылка на физических коммутаторах кластера не требуется. Можно создать простую одноадресную сеть для vSAN:

Следует учесть, что развернутый на кластере vSAN 6.6 использующий IP-адресацию из DHCP без резервации vCenter Server не поддерживается. Если же настроить резервирование, все будет в порядке.

Маркировка трафика vSAN

Рекомендовано маркировать трафик vSAN как приоритетный. Механизм позволяет назначать класс приоритетности (Class of Service (CoS)) от 0 до 7 (от низкого к самому высокому). Делается это в vSphere Distributed Switch.

Сегментирование трафика vSAN в VLAN

Для повышения безопасности и производительности рекомендовано изолировать трафик vSAN в сети VLAN. Это особенно актуально при разделении емкости резервного физического адаптера между несколькими типами трафика.

Создание статической маршрутизации для сети vSAN

Традиционные конфигурации vSphere, по умолчанию, используют единственный шлюз. Именно через него весь маршрутизируемый трафик и путешествует. Но, начиная с версии vSAN 7.0 можно переназначить дефолтный шлюз для адаптера VMkernel на каждом хосте и настроить его адрес в сети vSAN.

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

Для настройки статической маршрутизации используется команда esxcli:

esxcli network ip route ipv4 add -g <gateway-to-use> –n <remote-network>

где <remote-network> – это удаленная сеть, к которой должен иметь доступ хост, а <gateway-to-use> – интерфейс, которым будем пользоваться при отправке трафика в удаленную сеть.

Jumbo Frames

Если планируется использовать jumbo frames с vSAN для улучшения производительности CPU, предварительно стоит убедиться, что они включены на всех хостах и сетевых устройствах кластера.

Важно! В ESXi по умолчанию встроены функции TSO и LRO для TCP. Поэтому перед решением применять или нет jumbo frames для увеличения производительности стоит дважды подумать. Затраты на их включение на всех нодах сети будут колоссальными.

Пошаговая процедура подготовки к апдейту и обновления vSAN 7.0U1

В плане подготовки к апгрейду vSAN стоит проделать следующее, по пунктам:

Сделать бэкап всех виртуальных машин;
Выполнить все условия раздела «Требования и совместимость» выше при уточнении дизайна инфраструктуры vSAN. Это относится к вопросам версионности и обеспечения по факту необходимым аппаратным оборудованием, драйверами, ПО, управляющими микропрограммами, I/O-контроллерами хранилища. Нужно проверить, хватает ли места на дисках, сделано ли все в отношении сетевой организации. Обязательно учесть рекомендации подраздела «Отказоустойчивость сети и балансировка нагрузки»;
Погрузить все vSAN-хосты в режим maintenance, выбрав опцию «Ensure data accessibility» или «Full data migration»:

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

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

В целом же лицензирование для vSAN предусмотрено трех типов: стандартное, расширенное и корпоративное. Во втором случае функционал прирастает возможностью кодирования с уничтожением RAID 5/6, компрессией и дедупликацией. Enterprise-лицензирование подразумевает, что вам необходимо шифрование и растянутые кластеры. Функционал каждой лицензии наглядно представлен здесь:

Учтите, что лицензия покупается, исходя из общего количества CPU в кластере.

Обновление хостов до версии 7.0U1

На каждом хосте vSAN нужно обновить компоненты vSphere (ESXi и vCenter Server) до версии 7.0U1 (об этом подробно писалось в статье «Инсталляция и разворот VMware vSphere 7.0», а также в релизе «VMware ESXi 7.0 Update 1 Release Notes»).

Пойти можно двумя путями:

используя vSphere Lifecycle Manager,
командами Esxcli.

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

Апгрейд хоста-свидетеля в двух-хостовом растянутом кластере

Как мы знаем, хост-свидетель в растянутом кластере на два хоста располагается вне кластера, однако управляются все они одним и тем же vCenter Server:

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

Важно! Нельзя апгрейдить хост-свидетель до момента, пока этот процесс не закончат все хосты с данными и не будут погружены в режим техобслуживания. Параллельное применение vSphere Lifecycle Manager приведет к тому, что они станут обновляться одновременно, а это чревато проблемами. Чтобы этого избежать в настройках vSphere Lifecycle Manager отключается апдейт хоста-свидетеля при инициации его для хостов данных.

Обновление дискового формата (опционально)

Текущее состояние дискового формата проверяется на кластере vSAN: в его окне на вкладке «Configure» выбирается «General»:

Если, в разделе «Disk Format Version» видим предупреждающий значок и сообщение о количестве несоответствующих последнему релизу версий, жмем напротив кнопочку «Upgrade On-disk Format». Для начала, рекомендуется запустить пре-чек там же, чтобы получить самую свежую информацию.

Важно! В кластерах со включенным шифрованием, дедупликацией или компрессией дисковый формат обновляется автоматически до самой свежей версии. Без телодвижений со стороны администратора.

Использование RVC при обновлении дискового формата

Ruby vSphere Console (RVC) – замечательная вещь, почитаемая любителями консольного управления компонентами виртуальных сред. Чтобы проапгрейдить с ее помощью дисковый формат при обновлении vSAN до последней версии, идем по пунктам:

Проверяем статус состояния на странице «Disk Management», либо же запустив на выполнение команду:

vsan.disks_stats /<IP-адрес vCenter IP или имя хоста>/<имя дата-центра>/computers/<имя кластера>

Убеждаемся, что нам хватит свободного места командой:

vsan.whatif_host_failures

А также в том, что наши хосты не в maintenance-режиме (иначе доступное количество ресурсов на кластере уменьшится и апгрейд провалится), и что ни одна из задач не подвисла невыполненной (последнее удобно делать командой «vsan.resync_dashboard»).

Набираем команду:

vsan.ondisk_upgrade <путь к vSan кластеру>

и следим за прогрессом апгрейда в RVC (каждый диск будет обрабатываться последовательно). Окончание ознаменуется таким сообщением:

Done with disk format upgrade phase

There are n v1 objects that require upgrade Object upgrade progress: n upgraded, 0 left

Object upgrade completed: n upgraded

Done VSAN upgrade

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

vsan.obj_status_report

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