ESOS + Hyper-V: как добиться отказоустойчивости СХД когда «из коробки» её не было / Habr

Часть 1. Знакомство с продуктом

Зачем мы настраивали эту систему?

Нам нужно было развернуть отказоустойчивое хранилище для кластера Hyper-V с двумя нодами Windows Server 2019. Требования:

высокая доступность — виртуальные машины должны работать даже при падении одной ноды СХД;
производительность — Fibre Channel (FC) вместо iSCSI, чтобы избежать задержек;
бюджетность — без дорогих проприетарных решений вроде Dell EMC.

Наш "джентльменский" набор:

СХД AIC HA202-PV (тот самый "ноунейм" 2U с 24 дисками, купленный по цене б/у велосипеда);
Fibre Channel-адаптеры QLogic (найденные в глубинах серверной, покрытые пылью, но еще живые);
2 кастомных сервера с ОС Windows Server 2019 на борту;
безграничный оптимизм и запас крепкого кофе

В защиту нашей СХД стоит сказать, что конфигурация выдалась не такой уж и слабенькой:

Процессор	Intel Xeon Gold 6148 CPU @ 2.40Ghz x2
Оперативная память	DDR4 64GB DIMM 2933 MHz x2
NVMe SSD	Samsung PM1733 7.68 TB

А вот и наш подопытный:

Недостатки у таких габаритов тоже нашлись, для него просто катастрофически необходима стойка 1200 мм. В крайнем случае можно рассмотреть предыдущую модель СХД от этого производителя, вот ссылка: https://www.aicipc.com/en/productdetail/51300IC

Рисунок 2 — СХД AIC HA202-PV подключение плат расширения.

Кстати стоит упомянуть, что бэкплейн от плат расширения стоит дорабатывать, так как сам вырез в СХД под бэкплейн чуть короче самого бэкплейна.

Почему именно ESOS?

Когда мы начали искать решение, вариантов было три:

купить дорогую СХД, что было нецелесообразно для масштаба проекта;
использовать что-то бесплатное и потратить кучу времени;
притвориться, что не слышали задачи.

Мы выбрали второй вариант, потому что:

ESOS позиционируется как готовое решение для SAN;
поддерживает FC (а у нас как раз были эти загадочные адаптеры);
имеет встроенную поддержку кластеризации;
и главное - бесплатный!

Что скрывается под капотом?

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

SCST —«сердце» системы, превращающее ваш сервер в полноценную SAN;
Pacemaker — мозг, отвечающий за отказоустойчивость;
LVM + MDADM — гибкие инструменты работы с дисками;
мощный сетевой стек — от обычного iSCSI до Fibre Channel.

Первые впечатления:

Установка прошла на удивление гладко. "Вау" – подумал я – "это же почти как настоящий NetApp, только бесплатно"! Настроил RAID, создал LUN'ы, подключил к Hyper-V... Казалось, вот оно, счастье!

Но, как это часто бывает в IT, настоящие проблемы начались после слов "ну вот, теперь всё работает".

Первое же тестирование отказоустойчивости (совместно с коллегами) превратилось в комедию ошибок.

Выдергиваем кабель питания из активной ноды ESOS (как взрослые серьезные админы). С гордым видом наблюдаем, как Hyper-V должен переключиться на резервную ноду.

...Проходит минута...

...Две...

Виртуальные машины начинают падать как мухи, а мы – лихорадочно гуглить ошибки.

В тот момент мы поняли, что "готовое решение" оказалось таким же готовым, как полуфабрикаты в ближайшем магазине – теоретически съедобно, но лучше не рисковать.

Что же пошло не так?

LUN'ы отказывались автоматически переподключаться;
MPIO в Windows вел себя как капризный ребенок;
а самое главное – никакой реальной отказоустойчивости "из коробки" не оказалось.

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

Хотите узнать, как мы превратили этот "зоопарк" в стабильную отказоустойчивую систему? Читайте дальше – мы подробно разберем все проблемы и наши нестандартные решения.

Часть 2. Решение проблем

Ожидание: "готовое" решение после настройки по документации.

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

Проблема №1: Хаос в порядке запуска сервисов

Из коробки ESOS управляется кучей скриптов, но при настройке всех сервисов строго по официальной инструкции мы столкнулись с хаотичным порядком инициализации. Система могла:

пытаться собрать RAID до инициализации multipath;
запускать SCST до монтирования основных разделов;
игнорировать зависимости между сервисами.

Результат: При перезагрузке нода превращалась в "кирпич" в 7 случаях из 10.

Наше решение: Отказались от встроенных скриптов и написали свой контроллер инициализации:

#!/bin/bash

# Проверка инициализации multipath с ретраями

check_multipath() {

    for ((i=1; i<=3; i++)); do

        if multipath -v3 &>/dev/null && [ $(multipath -l | wc -l) -gt 0 ]; then

            return 0

        fi

        /etc/rc.d/rc.multipath restart

        sleep 5

    done

    exit 1

}

# Проверка сбора RAID

check_mdraid() {

    for ((i=1; i<=3; i++)); do

        if grep -q "active" /proc/mdstat && [ $(lsblk | grep -c 'raid') -gt 0 ]; then

            return 0

        fi

        /etc/rc.d/rc.mdraid restart

        sleep 5

    done

    exit 1

}

# Жесткая последовательность

/etc/rc.d/rc.multipath start

sleep 3

check_multipath

/etc/rc.d/rc.mdraid start

sleep 3

check_mdraid

exit 0

Ключевые моменты:

строгий порядок: сначала multipath, потом RAID;
проверки с ретраями вместо надежды на "авось";
задержки между операциями (да, sleep — это костыль, но работающий!).

После этого ноды стали подниматься стабильно даже после hard reboot.

Логичный вопрос, который может возникнуть: “А почему не systemd? Зачем эти костыли?”. На это есть сразу несколько причин:

Архитектурная несовместимость

ESOS построена на BusyBox + SysVinit, а systemd требует полной перестройки инициализации системы.
Ядро ESOS скомпилировано без поддержки cgroups (ключевой зависимости systemd).
2. Отсутствие зависимостей
3. Конфликт с существующей инициализацией и компонентами

Чтобы не ломать изначальную структуру, остановились на более простом и стабильном варианте.

Проблема №2: XFS timeline и "сломанные" диски

Следующий сюрприз: при тестах отказоустойчивости (принудительное падение активной ноды) разделы на /dev/md127 отказывались монтироваться на backup-ноде с ошибками:

XFS (md127): metadata I/O error in "log I/O"

XFS (md127): log mount/recovery failed

Диагноз: При резком обрыве работы лог XFS оставался в несогласованном состоянии. Ручное выполнение xfs_repair помогало, но для кластера это неприемлемо.

Решение: Автоматический "лекарь" дисков, интегрированный в Pacemaker:

Рисунок 4 — Восстановление дисков через xfs_repair.

#!/bin/bash

DEVICE="/dev/md127"

if ! mount | grep -q "$DEVICE"; then

    if ! xfs_repair -n "$DEVICE"; then

        xfs_repair -L "$DEVICE" || true

    fi

fi

Интеграция в кластер (crm):

Рисунок 4 — Автоматизация восстановления дисков.

primitive repair_disk anything \

    params binfile="/etc/repair_disk" \

    op start timeout=120s interval=30s \

    meta target-role=Started

colocation repair_with_scst_group inf: repair_disk scst_group

order scst_after_repair inf: repair_disk scst_group

Важно:

скрипт привязан к группе SCST и запускается при переносе ресурсов;
xfs_repair -L принудительно очищает лог;
таймауты подобраны эмпирически под наше железо.

Проблема №3: Консистентность конфигурации

Ручная настройка SCST – неразумный подход. Каждый раз пришлось бы переключиться между нодами. Решение – автоматическая синхронизация:

Рисунок 5 — Автоматическая синхронизация параметров SCST.

#!/bin/bash

current_dc=$(crm_mon -1 2>/dev/null | grep -i 'p_scst' | awk '$print $4$'

if [ "$current_dc" == "mzf-node0.mzf.com" ]; then

    scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \

    root@172.16.16.1:/etc/scst.conf /etc/scst.conf

    scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \

    root@172.16.16.1:/etc/fstab /etc/fstab

    if [ $? -eq 0 ]; then

    sed -i \

    -e 's/50:01:43:80:18:6b:cf:34/21:00:00:24:ff:76:60:d6/g' \

    -e 's/50:01:43:80:18:6b:cf:36/21:00:00:24:ff:76:60:d7/g' \

    -e 's/21:00:00:24:ff:24:84:4e/21:00:00:24:ff:24:84:4f/g' \

    -e 's/21:00:00:24:ff:40:89:6c/21:00:00:24:ff:40:89:6d/g' \

    /etc/scst.conf

    	exit 0

    else

    	echo "Ошибка копирования файла!" >&2

    	exit 1

    fi

else

    exit 0

fi

Особенности:

скрипт запускается только на standby-ноде;
замена WWID необходима из-за разных FC-карт в серверах;
синхронизация fstab для одинаковых обозначений дисков.

"Готовое" решение потребовало трёх нестандартных доработок, но доказало жизнеспособность подхода.

Главный итог: даже минималистичные системы типа ESOS можно превратить в отказоустойчивую платформу, если:

не бояться лезть в системные слои;
автоматизировать восстановление;
жёстко тестировать сценарии "грязного падения".

Часть 3. Испытание на прочность – как мы тестировали отказоустойчивость

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

Что мы хотели узнать:

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

Описание процесса тестирования:

Для тестирования отказоустойчивости нашли два кастомных сервера подключенных к СХД по Fibre Channel с доступом к дискам через MPIO были добавлены в кластер Hyper-V. Создана виртуальная машина на Windows Server, на которой развернута тестовая база 1C в режиме СУБД с использованием MSSQL.

Начинаем тестирование �� самого элементарного – штатное переключение на резервную ноду нашей СХД.

Запускаем нашу тестовую базу 1C, производим ручное переключение на резервную ноду методом перемещения crm resource move scst_group mzf-node1.mzf.com. Видим, что ВМ доступна, не реагирует на какие-либо нажатия мыши, но буквально через 10-15 секунд все стабилизировалось, и снова в строю. Возвращаемся на первую ноду, выполняем аналогично перемещение crm resource move scst_group mzf-node0.mzf.com. При этом не замечаем никаких перебоев с нашей ВМ.
Разобравшись со штатными ситуациями, где результат нас вполне устроил, переходим к тестированию с имитацией аварийных случаев.

2.1 Все так же запускаем 1С на нашей тестовой ВМ, и делаем вид, что работаем, выполняя типовые операции в базе, переключаясь по разным вкладкам, открывая отчеты. В это время, зайдя на Management Interface (megaRAC) нашей СХД, выключаем активную ноду через питание, 10…. 15…. 20…. секунд, и вот ВМ опять отзывается на нажатия мыши, 1С продолжает открывать интересующие нас отчеты.

2.2 Нас также интересует вопрос, а что если в какой-то день наша FC-карта просто перестанет работать, или это может быть даже SFP-модуль, ведь соединение с серверами настроено именно через Fibre Channel.
Вернувшись к штатному состоянию работы нашей СХД, и начав опять делать вид что работаем в 1С, просто задеваем оптический патч-корд, и получается так, что он вылетает из нашей FC-карты, установленной в СХД. ВМ все так же не отвечает на нажатия мыши, как и в предыдущих сценариях тестирования, но уже прошла минута, а ВМ все висит, но спустя примерно еще секунд тридцать ВМ начала откликаться на мышь, а в 1C успешно продолжилась наша работа.

2.3 Остался последний, но не менее важный этап аварийного тестирования, а именно выход из строя одного из дисков в нашем массиве. Т.к. предварительно мы собрали RAID5, было принято решение просто достать один диск из СХД во время все тех же работ в 1С – перемещение по вкладкам и открытие отчетов.
Вынимаем корзину с диском, наша ВМ все так же продолжает стабильно работать, как и база 1С, в которой без промедления открываются отчеты.

3. Напоследок протестируем, как ведет себя СХД при максимальной нагрузке на диски.
Для нагрузочного тестирования использовали программу Diskspd, установленную на одном из Windows серверов, к которому подключено наше хранилище.
Запустили тест на случайную запись (4K, 64 потока, глубина очереди 32)

diskspd -b4K -d60 -o32 -t64 -h -r -w100 -L -Z1G -c10G G:\testfile.dat

После этого – тест на смешанную нагрузку (70% read / 30% write):

diskspd -b8K -d120 -o64 -t32 -h -r -w30 -L -Z1G -c50G G:\testfile.dat

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

Итоговая таблица с этапами и результатами тестирования

Этап тестирования	Сценарий	Действия	Результат
Штатные ситуации	Плановый Перевод сервисов	Перевод на вторую ноду	15 сек на переход
		Обратный переход	ВМ не замечают изменений
Аварийные тесты	Имитация реальных сбоев	Отключение питания на рабочей ноде	Восстановление на резервную ноду за 15-20 сек
		Отключение кабелей FC	Восстановление на резервную ноду за 1-2 минуты
		Работа на одной ноде	Штатная работа
		Отключение диска из массива путем физического извлечения	Штатная работа
Нагрузочное тестирование	Проверка предельных возможностей	Максимальная нагрузка на диски	Стабильная работа

Вывод

Система показала себя хорошо: после аварии она восстанавливалась за 15-20 секунд. Единственное — при резком отключении оптических патч-кордов, время восстановления может занять до 2х минут (при этом ВМ остается в рабочем состоянии), не отвечая на какие-либо действия, пока не произойдет переключение на резервную ноду, что вполне нормально.

После тестов мы получили систему, которая:

автоматически восстанавливается после большинства аварий;
позволяет проводить обслуживание без остановки работы.

Главный урок: даже самая простая система может стать по-настоящему надёжной, если правильно её настроить и тщательно проверить. Тесты заняли больше времени, чем сама настройка, но зато теперь мы уверены в результате.

Остался вопрос на миллион: стоит ли нести это в прод?
➜ Да — если доработать мониторинг и валидацию данных.
➜ Нет — если SLA требует 99.999% uptime без рисков и бюджет позволяет приобрести СХД от именитых вендоров.

Ваше мнение решающее! Пишите в комментариях:

Какие компоненты вызывают больше всего доверия/опасений?
Какие тесты обязательны перед выкаткой?
Какие альтернативы предложили бы вы?