Обновление vCenter встаёт по таймауту

Обновили несколько vCenter’ов и на очередном обновлятор встаёт колом:

При этом даёт классный совет, типа, за 1 час не успеваю, дай мне побольше времени:
Upgrade phase timed out. The time planned for the upgrade phase
was 60 minutes. The upgrade phase has already been running for 60
minutes. To extend the default timeout, set environment variable
UPGRADE_EXPORT_TIMEOUT
Поиск дал ссылочку на БЗ –  The vCenter Server upgrade from version 7.0 to 8.0 fails at 39% with the error: “Upgrade phase timed out” after getting stuck during the “Exporting the VMware Analytics Service data” step
Запускаем предложенный скрипт и смотрим на наличие 127k файликов в аналитике:

root@vc [ /tmp ]# ls /var/log/vmware/analytics/prod | wc -l
127465
root@vc [ /tmp ]# chmod +x cleaning_vddk_script.sh
root@vc [ /tmp ]# ./cleaning_vddk_script.sh 90
Files before the clean :
127452 ===
Start cleaning VDDK files older than 90 days...
Clean successful! ===
Files after the clean:
0
root@vc [ /tmp ]# ls /var/log/vmware/analytics/prod | wc -l
102

Зачем сломали интерфейс?

Интерфейс в 7-ке были вылизан и привычен. В 8-ке решили, что FULL HD мониторы – это прошлый век, и исправили иконки, всплывающие длинные поля поменяли на полный вывод, а если название хоста не влезет, то не постеснялись в 2 этажа отобразить. Выбор нескольких строк тоже поломали.

Старое оборудование не поддерживается в ESXi 8

После эпопеи VMware ESXi 7.0 и неподдерживаемое оборудование отказ от оборудования в 8-ке продолжился. По процессорам у нас вышли из поддержки Intel Xeon 26xx v2 – хорошо, отправим на списание. Для любителей хлама – неофициально ESXi8 на старых процессорах работает Heads Up – ESXi 8.0 Update 2 requires XSAVE CPU instruction even with allowLegacyCPU=true.
Актуальной остаётся проблема Отвал FC HBA Emulex 8/16-Gb/s после обновления VMware ESXi 7.0 update 3. Драйвер нужно интегрировать старый.

Загрузка ESXi и TPM 2.0

8-ка стала требовать включения TPM 2.0 на серверах (с TPM 1.2 грузится, но ругается):
TPM 1.2 device detected. Support for TPM version 1.2 is discontinued. Installation may proceed, but may cause the system to behave unexpectedly.Make sure the host is upgraded to TPM 2.0.
Как оказалось, на всех старых серверах необходимо на уровне UEFI, а местами и джамперов, переключаться на TPM 2.0.
Как включить TPM 2.0 на серверах Lenovo:

• How to set TPM and enable secure boot on a Lenovo ThinkSystem
• 3550 M5 System-board switches, jumpers, and buttons
• 3650 M5 TPM 2.0

QuickBoot и TPM 2.0, а ещё TXT и IPMI

С 8-ки поддерживается QuickBoot на серверах с TPM 2.0, но встаём на целый набор граблей: современный сервер пишет, что поддержки нет. Запускаем утилиту проверки для определения причин:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
BmcInfo: ipmi returned invalid data length: 1 ccode 255
BmcInfoImpl: Retrieve Version information failed
This system is not QuickBoot compatible: violating one or more strict requirements (Quick Boot is not supported on this machine)
The host does not fulfill the following hard dependencies:
- Intel TXT is enabled

Ищем где выключить TXT на серверах Lenovo  – находим нужный пункт в этой КБ:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
BmcInfo: ipmi returned invalid data length: 1 ccode 255
BmcInfoImpl: Retrieve Version information failed
This system is compatible with Quick Boot.

По второй ошибке – “BMC Firmware Version” missing in System information of VMware DCUI, проверяем, что поля заполнены или нет:

esxcli hardware ipmi bmc get
BMCFirmware Version: 0.00
Hostname Reported:
IPMIVersion: 0.0
IPv4Address:
IPv4Gateway:
IPv4Subnet:
IPv6Addresses:
LANif Admin Status: false
MACAddress:
Manufacturer: Unknown
OSName Reported:

Ошибка спустя несколько минут исправилась после перезагрузки контроллера.
В итоге получаем:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
This system is compatible with Quick Boot.

Проблема с плагином Veeam BR

Также отвалился плагин для Veeam BR – порешалось переустановкой? Нет…

Цели тестирования:

• определить производительность системы хранения данных (СХД) в кластере HyperMetro и её изменение при различных вариантах отказа оборудования;
• оценить влияние на производительность и доступность программно-аппаратного комплекса (ПАК) фирменного MPIO-драйвера (драйвер балансировки подключения по нескольким путям ввод-вывода) Huawei Ultrapath;
• протестировать функциональность SmartVirtualization СХД Huawei Dorado 5000V6 – способность выдавать через себя дисковые разделы других СХД.

Дополнительно была проведена проверка работоспособности одного из серверов системы управления базами данных (СУБД) Oracle DB при отказе узла кластера HyperMetro. Для этого сервер был временно перенесён в кластер HyperMetro без прерывания его работы, а по окончании тестирования возвращён обратно.

Оборудование было предоставлено системным интегратором,  который также составил и выполнил программу и методику испытаний. Тестирование осуществлялось при помощи программы VDBench, имитировалась нагрузка, аналогичная создаваемой основным сервером СУБД Oracle DB в ежедневной эксплуатации. Профиль  нагрузки  приведён  в Приложении 1.

Для проведения тестирования был собран стенд, имитирующий размещение оборудования в двух пространственно-разнесённых центрах обработки данных, установлено и настроено программное обеспечение (ПО) и развёрнуты тестовые виртуальные машины. Схема стенда и описание используемого ПО приводятся в Приложении 2.

Первичное конфигурирование системы проводилось с использованием штатных MPIO-драйверов среды виртуализации VMware ESXi. Драйвер оказывает решающее влияние на производительность системы и её отказоустойчивость, поэтому было проведено две серии тестов – со штатными драйверами VMware, и с фирменными драйверами Huawei Ultrapath от изготовителя СХД. Перед началом тестирования выживаемости кластера при различных вариантах отказов оборудования и влияние отказов на производительность был выполнен эталонный замер производительности системы в штатном режиме работы. Методика замера и результаты приведены в Приложении 3.

После определения исходного уровня производительности системы, была выполнена оценка изменения производительности при отказе удалённой системы хранения (Приложение 4), локальной системы хранения (Приложение 5) и дирижёра кластера (Quorum Server). С целью проверки выживаемости, в тестовую среду был мигрирован сервер СУБД Oracle DB (DEV03). Оценивалось влияние на работоспособность и доступность сервера  отказ одной из реплик хранилища. Результаты приведены в Приложении 6.

Следующим этапом стала оценка влияния на производительность и доступность системы использование MPIO-драйвера Huawei Ultrapath. В процессе подготовки стенда выяснилось, что драйвер существует только для версии VMware ESXi 6.7U3, а на стенде развёрнута VMware ESXi 7. Для проведения работ был подготовлен и подключен новый сервер с требуемой версией ESXi, описание стенда приведено в Приложении 7.

Поскольку среда поменялась, были проведены замеры производительности системы в штатном режиме (Приложение 8). Затем выполнены замеры производительности при отказе удалённого хранилища (Приложение 9) и локального (Приложение 10).

После проведения серии опытов по определению производительности работы и отказоустойчивости кластера, была выполнена оценка функционала виртуализации СХД (SmartVirualization) и сделаны замеры производительности работы системы при прямом подключении к серверу раздела СХД  EMC VNX5700 и подключении его через функцию виртуализации СХД Huawei Dorado 5000 V6. Схема стенда и результаты тестирования приведены в Приложении 11.

Дополнительно была выполнена оценка влияния процесса создания и удаления моментальных снимков (снапшотов, snapshots) виртуальных машин (ВМ) на производительность работы ВМ при использовании традиционных томов VMFS (Приложение 12), при использовании виртуальных томов VVOL (Приложение 13), а также влияние на производительность процедуры установки обновлений управляющего ПО СХД (Приложение 14).

Краткое резюме по этапам тестирования производительности приведено в таблице:

Результаты тестирования функции виртуализации внешних систем хранения (Smart Virtualization) CХД Huawei Dorado V6 приведены в таблице:

Результаты тестирования процесса создания и удаления моментальных снимков ВМ (снапшотов) на CХД Huawei Dorado V6 с томами VMFS:

Результаты тестирования процесса создания и удаления моментальных снимков ВМ на CХД Huawei Dorado V6 с томом VVOL:

Выводы по итогам тестирования

1. Технология HyperMetro-кластера (двух удалённых на большое расстояние систем хранения данных, на одной из которых размещается основная копия данных, на второй – её реплика) может быть использована в продуктивной среде для обеспечения непрерывности работы прикладных задач в случае аварийного выключения основного ЦОДа или основной системы хранения.
2. Потери производительности при отказе одной из систем незначительны, а в случае отказа удалённой системы производительность возрастает. Потери производительности на синхронизацию данных после восстановления доступности систем не превышают 20%. Пауза длительностью 13-14 секунд в момент пропадания одной из реплик не привела к отказу в обслуживании СУБД Oracle DB, что является подтверждением возможности использования технологии для обеспечения непрерывности работы информационной системы.
3. Со штатными MPIO-драйверами VMware показывает лучшую производительность в операциях чтения-записи на том. Использование MPIO-драйвера Huawei UltraPath возможно только в случае если все системы хранения данных предприятия будут производства Huawei. С оборудованием других производителей драйвер не работает.
4. Функция виртуализации других систем хранения не даёт никаких преимуществ в производительности перед прямым подключением этих систем и, в основном, может быть использована для миграции данных из сторонних СХД на Dorado 5000 V6.
5. Процесс создания, а особенно наличия моментального снимка ВМ (снапшота) оказывает существенное влияние на производительность работы системы, которая падает почти в два раза. Поэтому снапшоты рекомендуется создавать в периоды наименьшей загрузки системы и не оставлять дольше, чем это необходимо.
6. По сравнению с классической технологией VMFS, технология VVOLs (Virtual Volumes) для VMware показала лучшие результаты в операциях чтения-записи на том, уменьшение времени создания и удаления снапшотов ВМ без оперативной памяти. Однако создание снапшотов ВМ с оперативной памятью занимает весьма продолжительное время, также зафиксирована нестабильная работа управляющей службы тома (VASA-провайдера). Текущая реализация VVOLs в продукте Huawei для VMware не может быть рекомендована к использованию для продуктивных систем.
7. Интерфейс управления СХД Dorado 5000 V6 дружелюбен и интуитивно понятен.
8. Конструктивно СХД Dorado 5000 V6 имеет большую длину, из-за чего может быть установлена только в определённых слотах стандартной серверной стойки. Также она имеет высокую теплопроизводительность и нуждается в хорошем охлаждении. Это следует учитывать при выборе и оснащении места размещения СХД.
9. В целом, технология метрокластера и система хранения Huawei Dorado 5000 V6 заслуживает положительной оценки и может рекомендована к внедрению в продуктивную среду.

Приложения

Приложение 1. Профиль нагрузки Oracle СУБД DB

 Исходя из полученных перед началом тестирования отчетов AWR с существующих СУБД Oracle DB заказчика установлен следующий профиль нагрузки для VDbench:

• 93% операций ввода-вывода на диск совершается с размером блока 8KB при соотношении чтения/записи 73% к 27%;
• 7% операций ввода-вывода на диск совершается с размером блока 512b при соотношении чтения/записи 16% к 84%.

Приложение 2. Описание тестового стенда c штатным MPIO-драйвером ESXi

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

• одна СХД Huawei Dorado5000 v6;
• один сервер Lenovo SR650 (2xCPU, 768GB RAM, 4x10GbE, 2x32Gb FC) с ОС VMware ESXi, 7.0.0, 16324942;
• один коммутатор SAN с двенадцатью 16 или 32Gb MM SFP+, c одним одномодовым SFP+;
• семь ВМ VDbench (8vCPU, 24GB RAM, 16GB disk, 4x600GB тестовые диски с контроллерами VMware Paravirtual SCSI).

Дополнительно на существующем оборудовании заказчика разворачивается две ВМ:

• одна для управления VDbench;
• одна для сервера Quorum кластера Huawei HyperMetro.

Серверное оборудование обновляется последними версиями прошивок и на ESXi устанавливаются версии драйверов в соответствии с таблицами совместимости Huawei.

На коммутаторах SAN настраивается зонирование, обеспечивающее связь.

Описание настроек кластера Huawei HyperMetro для VMware:

• Все NVMe-диски собираются в один StoragePool RAID5 с политикой резервирования дисков High;
• Создается HyperMetro-домен из двух СХД Huawei с Quorum сервером доступным через порты управления обоих контроллеров. Для данного домена создается отдельный пользователь на СХД. Обе СХД осуществляют репликацию через 4 выделенных порта для репликации;
• Создаются две пары LUN на СХД:
  • На первой СХД – LUN1_pri и LUN2_sec по 21TB;
  • На второй СХД – LUN1_sec и LUN2_pri по 21TB;
  • Из которых собирается две пары HyperMetro, в которых LUN1 назначается роль Preffered на первой СХД, а LUN2 роль Preffered на второй СХД. Скорость репликации Highest. Политика восстановления Automatic.
• Созданные LUN презентуются хостам с одинаковым LUN ID (10 для LUN1, 11 для LUN2), которые настраиваются таким образом, чтобы пути к СХД, расположенной на одной площадке с сервером были выбраны как активные, а пути к уделенной СХД как резервные. Для презентации LUN хостам используются 4 выделенных порта для данных:
  • На первой СХД:
    • Сервер SR650-2
      • HyperMetro Working Mode: Local preferred mode
      • OS Setting: VMware ESXi
      • Host Access Mode: Asymmetric
      • Preferred Path for HyperMetro: Yes
    • Сервер SR650-1
      • HyperMetro Working Mode: Local preferred mode
      • OS Setting: VMware ESXi
      • Host Access Mode: Asymmetric
      • Preferred Path for HyperMetro: No
    • На второй СХД:
      • Сервер SR650-2
        • HyperMetro Working Mode: Local preferred mode
        • OS Setting: VMware ESXi
        • Host Access Mode: Asymmetric
        • Preferred Path for HyperMetro: No
      • Сервер SR650-1
        • HyperMetro Working Mode: Local preferred mode
        • OS Setting: VMware ESXi
        • Host Access Mode: Asymmetric
        • Preferred Path for HyperMetro: Yes
      • На ESXi выполняются следующие настройки политик работы с путями к Huawei:
        • esxcli storage nmp psp roundrobin deviceconfig set –device=naa.6ac8d34100ec7478024b9dc900000000 –iops=1 –type iops
        • esxcli storage nmp psp roundrobin deviceconfig set –device=naa.6ac8d34100ec7478024bb11000000001 –iops=1 –type iops
        • esxcli storage nmp satp rule add -V HUAWEI -M XSG1 -s VMW_SATP_ALUA -P VMW_PSP_RR -c tpgs_on
• Гипервизоры ESXi собираются в кластер со следующими параметрами:
  • HA: Enabled
  • Proactive HA: Disabled
  • Host Failure: Restart VMs. Using VM restart priority ordering.
  • Host Isolation: VMs on isolated hosts will remain powered on.
  • Datastore with Permanent Device Loss: Power off and restart VMs. Datastore protection enabled. Always attempt to restart VMs.
  • Datastore with All Paths Down: Power off and restart VMs (Agressive restart policy). Datastore protection enabled. Always attempt to restart VMs.
  • Guest not heartbeating: Disabled VM and application monitoring disabled.
  • Тестовые диски ВМ размещаются на Preffered LUN локальной СХД. Нумерация ВМ с 1 по 7 на SR650-1 и с 8 по 14 на SR650-2.

Схема демо-стенда:

Приложение 3. Первоначальное тестирование

В ходе первоначального тестирования проводилось наполнение дисков тестовых ВМ vdbench случайными данными и определялся служебный параметр – число потоков vdbench (в конфигурации профиля нагрузки заказчика), при котором достигается нагрузка с максимально оптимальным сочетанием IOPS/Latency. В ходе первоначального тестирования данный параметр устанавливается равным 2.

Таблица тестирования с различным числом потоков.

Графики IOPS, Bandwidth, latency для числа потоков = 2:

Приложение 4.  Производительность при использовании Native MPIO. Имитация отказа СХД №1 (удалённой)

Для текущего теста стенд описан в Приложении 2. Выбор служебных параметров VDbench описан в Приложении 3.

Протокол теста:

1. В 12:55 запущен VDbench со следующими параметрами производительности 96k IOPS 700MB/s в конфигурации профиля нагрузки заказчика (Oracle DB) на 14-ти ВМ.
2. В 12:56 сервер Quorum отключен, в интерфейсе СХД зафиксировано появление ошибки о недоступности Quorum:
   1. Деградации производительности не обнаружено.
3. В 12:57 сервер Quorum включен, в интерфейсе СХД зафиксировано отсутствие ошибки о недоступности Quorum:
   1. Деградации производительности не обнаружено.
4. В 12:59 путем полного отключения электропитания сымитирован отказ СХД №1, зафиксировано:
   • Пути на гипервизорах ESXi до СХД №1 перешли в состояние Dead, пути до СХД№2 ранее находившиеся в статусе Active перешли в статус Active (I/O);
   • Полная приостановка ввода-вывода к дискам ВМ на 13 секунд;
   • После возобновления ввода-вывода, зафиксирован рост производительности (IOPS) на 8% с 96000 до 104000, при этом значительных колебаний времени отклика от диска не обнаружено.

5. В 13:05 было подано электропитание на СХД№1, через 10 минут система автоматически запустилась. В 13:17:37 автоматически запустилась синхронизация LUN’ов кластера HyperMetro (Режим работы Automatic, скорость репликации Highest), в результате чего было зафиксировано:
   • Снижение производительности (IOPS) на 8% с 104000 до 96000, при этом значительных колебаний времени отклика от диска не обнаружено;
   • Незначительные колебания загруженности процессора на контроллерах СХД с 25-30% до 40-45%;
   • Загруженность линка SAN между площадками составляет не более 4Gb/s.

6. В 14:35 был завершен процесс синхронизации LUN’ов кластера HyperMetro, в результате чего было зафиксировано возвращение путей на ESXi в исходное состояние:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Active на сервере площадки 1 и Active (I/O) на сервере площадки 2, пути до СХД №1 перешли в состояние Active на сервере площадки 2 и Active (I/O) на сервере площадки 1;
   • Загруженность линка SAN между площадками сократилась до 1Gb/s.

Суммарные графики IOPS, Bandwidth, latency во время отключения/включения СХД:
Графики IOPS, Bandwidth, latency во время отключения/включения СХД для ВМ:

Типовой график загрузки контроллеров СХД (*Далее аналогичен при аналогичных тестах):

Типовой график загрузки SAN-линка между ЦОДами (*Далее аналогичен при аналогичных тестах):

Приложение 5. Производительность при использовании Native MPIO-драйвера. Имитация отказа СХД №2 (локальной)

Для текущего теста стенд описан в Приложении 2. Выбор служебных параметров VDbench описан в Приложении 3.

Протокол теста:

1. В 15:13 запущен VDbench со следующими параметрами производительности 96k IOPS 700MB/s в конфигурации профиля нагрузки заказчика (Oracle DB) на 14-ти ВМ.
2. В 15:16 путем полного отключения электропитания сымитирован отказ СХД №2, зафиксировано:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Dead, пути до СХД№1 ранее находившиеся в статусе Active перешли в статус Active (I/O);
   • Полная приостановка ввода-вывода к дискам ВМ на 13 секунд c последующей деградацией производительности (IOPS) на 50% на 17 секунд, после чего зафиксирован рост производительности (IOPS) на 8%, с 96000 до 106000. При этом значительных колебаний времени отклика от диска не обнаружено.

3. В 15:25 было подано электропитание на СХД №2, через 10 минут система автоматически запустилась. В 15:38:13 автоматически запустилась синхронизация LUN’ов кластера HyperMetro (Режим работы Automatic, скорость репликации Highest). В результате было зафиксировано:
   • Снижение производительности (IOPS) на 8% с 108000 до 96000, при этом значительных колебаний времени отклика от диска не обнаружено;
   • Незначительные колебания загруженности процессора на контроллерах СХД с 25-30% до 40-45%;
   • Загруженность SAN-линка между площадками составляет не более 4Gb/s.

4. В 16:50 был завершен процесс синхронизации LUN’ов кластера HyperMetro, в результате чего было зафиксировано возвращение путей на ESXi в исходное состояние:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Active на сервере площадки 1 и Active (I/O) на сервере площадки 2, пути до СХД №1 перешли в состояние Active на сервере площадки 2 и Active (I/O) на сервере площадки 1;
   • Загруженность SAN – линка между площадками сократилась до 1Gb/s.

Суммарные графики IOPS, Bandwidth, latency во время отключения/включения СХД:

Графики IOPS, Bandwidth, latency во время отключения/включения СХД для ВМ:

Приложение 6. Протокол теста «Native MPIO. Влияние отказа СХД на существующую ВМ c СУБД Oracle DB (dev03)»

Для текущего теста стенд описан в Приложении 2. Выбор служебных параметров VDbench описан в Приложении 3.

Протокол теста:

1. В тестовый стенд на сервер SR650-01 и LUN LUN2_HyperMetro_D5kv6_2_pri мигрирована ВМ dev03 с СУБД Oracle DB. Preffered СХД для данного кластерного LUN является СХД №2.
2. В 14:21 запущена тестовая нагрузка на ВМ dev03, дополнительно запущен VDbench для фиксации времени приостановки дискового ввода-вывода в конфигурации профиля нагрузки заказчика (Oracle DB) на 14-ти ВМ.
3. В 14:34 путем полного отключения электропитания сымитирован отказ СХД №2, зафиксировано:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Dead, пути до СХД №1 ранее находившиеся в статусе Active перешли в статус Active (I/O);
   • Полная приостановка ввода-вывода к дискам ВМ на 14 секунд;
   • После приостановки ввода-вывода на ВМ dev03 СУБД Oracle DBосталась доступна и работоспособна, повреждения данных не обнаружено; тестовая нагрузка продолжила свою работу, ошибок с экстренным завершением процесса не обнаружено.

4. В 14:43 было подано электропитание на СХД №2, через 10 мин. система автоматически запустилась. В 15:53:41 автоматически запустилась синхронизация LUN’ов кластера HyperMetro (Режим работы Automatic, скорость репликации Highest). В ходе синхронизации влияния на работу БД и тестовой нагрузки на ВМ dev03 не обнаружено.

5. В 16:15 был завершен процесс синхронизации LUN’ов кластера HyperMetro, в результате чего было зафиксировано возвращение путей на ESXi в исходное состояние:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Active на сервере площадки 1 и Active (I/O) на сервере площадки 2, пути до СХД №1 перешли в состояние Active на сервере площадки 2 и Active (I/O) на сервере площадки 1.

Приложение 7. Описание тестового стенда c MPIO-драйвером Huawei UltraPath

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

• одна СХД Huawei Dorado5000 v6;
• один коммутатор SAN с двенадцатью 16 или 32Gb MM SFP+, c одним одномодовым SFP+;
• сервер установлен только в ДЦ №2 в следующей конфигурации:
• один сервер Huawei 2288H V5 (2288H V5 10GE SFP+) (1xCPU, 768GB RAM, 1x10GbE, 2x32Gb FC) с ОС VMware ESXi, 6.7.0, 15160138).
• на ESXi установлен драйвер OceanStor_UltraPath_21.6.3 для VMware_ESXi;
• семь ВМ VDbench (8vCPU, 24GB RAM, 16GB disk, 4x600GB тестовые диски с контроллером VMware Paravirtual SCSI).

Дополнительно на существующем оборудовании заказчика развернуты две ВМ:

• Одна для управления VDbench;
• Одна для сервера Quorum кластера Huawei HyperMetro.

Серверное оборудование обновлено последними версиями прошивок. На ESXi устанавлены версии драйверов в соответствии с таблицами совместимости Huawei.

На коммутаторах SAN настроено зонирование, обеспечивающее связь.

Описание настроек кластера Huawei HyperMetro для VMware:

• Все NVMe-диски собираны в один StoragePool в RAID5 с политикой резервирования дисков High;
• Создан HyperMetro домен из двух СХД Huawei с Quorum сервером, доступным через порты управления обоих контроллеров. Для данного домена создан отдельный пользователь на СХД. Обе СХД осуществляют репликацию через 4 выделенных порта для репликации;
• Созданы две пары LUN на СХД:
  • На первой СХД – LUN1_pri и LUN2_sec по 21TB;
  • На второй СХД – LUN1_sec и LUN2_pri по 21TB;
  • Из этих LUN собраны две пары HyperMetro, в которых LUN1 назначена роль Preffered на первой СХД, а LUN2 – роль Preffered на второй СХД. Скорость репликации – Highest. Политика восстановления – Automatic.
• Созданные LUN презентованы хостам с одинаковым LUN ID (10 для LUN1, 11 для LUN2), которые настроены таким образом, чтобы пути к СХД, расположенной на одной площадке с сервером были выбраны как активные, а пути к уделенной СХД как резервные. Для презентации LUN хостам используются 4 выделенных порта для данных:
  • На первой СХД:
    • Сервер Hua2288h-01
      • HyperMetro Working Mode: Local preferred mode
      • OS Setting: VMware ESXi
      • Host Access Mode: Asymmetric
      • Preferred Path for HyperMetro: Yes
    • На второй СХД:
      • Сервер Hua2288h-01
        • HyperMetro Working Mode: Local preferred mode
        • OS Setting: VMware ESXi
        • Host Access Mode: Asymmetric
        • Preferred Path for HyperMetro: No
      • На ESXi выставлен автоматический режим работы MPIO Huawei UltraPath:

esxcli upadm set hypermetro workingmode -m auto

Тестовые диски ВМ размещаются на Preffered LUN локальной СХД. Нумерация ВМ с 8 по 14 на Hua2288h-01.

Схема демо-стенда представлена на рисунке ниже.

Приложение 8. Первоначальное тестирование

В ходе первоначального тестирования проводится наполнение дисков тестовых ВМ vdbench случайными данными и определяется служебный параметр – число потоков vdbench (в конфигурации профиля нагрузки заказчика) при котором достигается нагрузка с максимально оптимальным сочетанием IOPS/Latency. Данный параметр устанавливается равным 2.

Таблица тестирования с различным числом потоков.

Графики IOPS, Bandwidth, latency для числа потоков = 2:

Приложение 9. Протокол теста «Huawei MPIO. Имитация отказа СХД №1»

Для текущего теста стенд описан в Приложении 6. Выбор служебных параметров VDbench описан в Приложении 6.1.

Протокол теста:

1. В 10:56 запущен VDbench со следующими параметрами производительности 57k IOPS 420MB/s в конфигурации профиля нагрузки заказчика (Oracle DB) на 7-ми ВМ.
2. В 10:57 сервер Quorum отключен, в интерфейсе СХД зафиксировано появление ошибки о недоступности Quorum:
   • Деградации производительности не обнаружено.
3. В 10:58 сервер Quorum включен, в интерфейсе СХД зафиксировано отсутствие ошибки о недоступности Quorum:
   • Деградации производительности не обнаружено.
4. В 11:03 путем полного отключения электропитания сымитирован отказ СХД №1, зафиксировано:
   • Пути на гипервизорах ESXi до СХД №1 перешли в состояние Dead;
   • Полная приостановка ввода-вывода к дискам ВМ на 13 секунд;
   • После возобновления ввода-вывода, зафиксирован рост производительности (IOPS) на 2% с 57000 до 59000, при этом значительных колебаний времени отклика от диска не обнаружено.

5. В 11:10 было подано электропитание на СХД №1, через 10 минут система автоматически запустилась. В 11:22:14 автоматически запустилась синхронизация LUN’ов кластера HyperMetro (Режим работы Automatic, скорость репликации Highest), в результате чего было зафиксировано:
   • Снижение производительности (IOPS) на 16% с 59000 до 49000, при этом значительных колебаний времени отклика от диска не обнаружено;
   • Незначительные колебания загруженности процессора на контроллерах СХД с 25-30% до 40-45%;
   • Загруженность линка SAN между площадками составляет не более 4Gb/s.

6. В 12:16 был завершен процесс синхронизации LUN’ов кластера HyperMetro, в результате чего было зафиксировано возвращение путей на ESXi в исходное состояние:
   • Пути на гипервизорах ESXi до СХД №1 перешли в состояние Active;
   • Загруженность линка SAN между площадками сократилась до 1Gb/s.

Суммарные графики IOPS, Bandwidth, latency во время отключения/включения СХД:

Графики IOPS, Bandwidth, latency во время отключения/включения СХД для ВМ:

Приложение 10. Протокол теста «Huawei MPIO. Имитация отказа СХД №2»

Для текущего теста стенд описан в Приложении 7. Выбор служебных параметров VDbench описан в Приложении 9.

Протокол теста:

1. В 13:11 запущен VDbench со следующими параметрами производительности 57k IOPS 420MB/s в конфигурации профиля нагрузки заказчика (Oracle DB) на7-ти ВМ.
2. В 13:14 путем полного отключения электропитания сымитирован отказ СХД №2, зафиксировано:
   • Пути на гипервизорах ESXi до СХД №2 перешли в состояние Dead;
   • Полная приостановка ввода-вывода к дискам ВМ на 13 секунд, после чего, зафиксирован рост производительности (IOPS) на 16% с 55000 до 66000, при этом значительных колебаний времени отклика от диска не обнаружено.