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

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

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

• высокая доступность — виртуальные машины должны работать даже при падении одной ноды СХД;

• производительность — Fibre Channel (FC) вместо iSCSI, чтобы избежать задержек;

• бюджетность — без дорогих проприетарных решений вроде Dell EMC.

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

• СХД AIC HA202-PV (тот самый "ноунейм" 2U с 24 дисками, купленный по цене б/у велосипеда);

• Fibre Channel-адаптеры QLogic (найденные в глубинах серверной, покрытые пылью, но еще живые);

• 2 кастомных сервера с ОС Windows Server 2019 на борту;

• безграничный оптимизм и запас крепкого кофе

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

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

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

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

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

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

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

2. использовать что-то бесплатное и потратить кучу времени;

3. притвориться, что не слышали задачи.

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

• 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? Зачем эти костыли?”. На это есть сразу несколько причин:

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

• 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:

#!/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):

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 – неразумный подход. Каждый раз пришлось бы переключиться между нодами. Решение – автоматическая синхронизация:

#!/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. Испытание на прочность – как мы тестировали отказоустойчивость

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

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

• Что будет, если мы просто переведем сервисы на другую ноду в штатном режиме?

• Как система поведет себя при настоящей аварии?

• Выдержит ли она максимальную нагрузку?

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

1. Для тестирования отказоустойчивости нашли два кастомных сервера подключенных к СХД по 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. Разобравшись со штатными ситуациями, где результат нас вполне устроил, переходим к тестированию с имитацией аварийных случаев.

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-20 секунд. Единственное — при резком отключении оптических патч-кордов, время восстановления может занять до 2х минут (при этом ВМ остается в рабочем состоянии), не отвечая на какие-либо действия, пока не произойдет переключение на резервную ноду, что вполне нормально.

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

• автоматически восстанавливается после большинства аварий;

• позволяет проводить обслуживание без остановки работы.

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

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

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

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

• Какие тесты обязательны перед выкаткой?

• Какие альтернативы предложили бы вы?