Отказоустойчивость СХД: как спроектировать резервирование контроллеров, путей ввода-вывода и питания

Что такое отказоустойчивость СХД и почему она начинается с бизнес-требований

Отказоустойчивость это способность IT-системы продолжать работу при отказе отдельных компонентов: в идеале пользователь вообще не замечает проблему. Для системы хранения данных это означает, что выход из строя контроллера, кабеля, блока питания или дисковой полки не прерывает доступ к данным.

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

Короткий ответ на главный вопрос: отказоустойчивость СХД складывается из резервирования четырех групп компонентов - контроллеров, путей ввода-вывода, питания и дисковых полок. Ни один отдельный продукт или уровень RAID не дает нужного результата. Работает система технических и организационных решений.

Доступность, целостность данных и скорость восстановления: три метрики, которые важнее процентов

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

• Доступность. Показывает, как долго сервис работает без перерыва. 99,9% uptime это около 8,8 часа простоя в год, 99,99% - примерно 53 минуты.
• Целостность данных. Заказы, платежи, учетные записи и документы остаются полными и корректными. Массив может быть доступен, но отдавать поврежденные блоки, и это опаснее короткого простоя.
• Скорость восстановления. Время, за которое команда возвращает систему в рабочее состояние после серьезного инцидента. Она зависит от готовых процедур и репетиций не меньше, чем от железа.

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

Как определить допустимое время простоя и потери данных (RTO/RPO) перед выбором оборудования

RTO (Recovery Time Objective) это целевое время восстановления после сбоя. RPO (Recovery Point Objective) это допустимый объем потерянных данных, выраженный во времени: RPO 5 минут означает, что потеря последних пяти минут записей приемлема.

Перевести требования бизнеса в технические параметры помогают четыре вопроса:

1. Сколько минут или часов простоя сервиса допустимо в месяц?
2. Какие данные критичны, а какие допустимо восстановить с потерей?
3. Как часто снимаются резервные копии и проверяется ли восстановление из них?
4. Кто принимает решение об аварийном переключении и по какому регламенту?

Дальше цифры превращаются в конфигурацию. RTO 15 минут требует автоматического failover контроллеров и настроенного multipath. RPO 0 достижим только синхронной репликацией, которая чувствительна к задержкам сети между площадками. Без зафиксированных RTO и RPO невозможно осознанно выбрать между Active-Active и Active-Passive, между одним и двумя контроллерами, между локальным и распределенным хранением. Алгоритм подбора конфигурации под нагрузку разобран в материале о стратегиях резервирования и репликации.

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

Резервирование контроллеров СХД: Active-Active, Active-Passive и проверка failover

Контроллер управляет доступом к массиву, кэшем и дисками. Пока контроллер один, он остается единой точкой отказа (SPOF): его поломка останавливает все тома. Второй контроллер убирает эту точку, но только при подключении к независимым путям питания и сети и при корректной настройке переключения.

Active-Active vs Active-Passive: что выбрать для вашего сценария

Два режима отличаются распределением нагрузки и временем переключения.

ALUA (Asymmetric Logical Unit Access) сообщает хосту, через какой контроллер путь к LUN оптимален, а какой считается резервным. Без ALUA хост может отправлять трафик через неоптимальный путь и терять производительность даже без отказов. Для базы данных с высокими IOPS и требованием RTO в минуты подходит Active-Active. Для архива, хранилища резервных копий или тестового контура достаточно Active-Passive.

Пары контроллеров работают в решениях Dell EMC, NetApp, Huawei, а также в сборках на базе TrueNAS SCALE при настройке iSCSI. Логика везде одна: два независимых узла, согласованная выдача LUN и автоматическое переключение при отказе.

Типичная ошибка: оба контроллера подключены к одному коммутатору или питаются от одной линии. Формально резерв есть, фактически отказ коммутатора или ввода питания останавливает оба узла сразу. Принципы failover на уровне управляющих систем описаны в статье об отказоустойчивости систем управления.

Как проверить, что контроллеры действительно резервируют друг друга

1. Убедитесь, что оба контроллера видны в системе управления СХД и не находятся в состоянии degraded.
2. Проверьте, что каждый LUN доступен через оба контроллера.
3. Эмулируйте отказ: переведите один контроллер в standby или отключите его питание.
4. Зафиксируйте время переключения и убедитесь, что ввод-вывод не прервался.
5. Просмотрите логи и мониторинг на ошибки и повторные переключения.

На стороне сервера команда multipath -ll показывает пути и их состояние. Для iSCSI проверяются сессии: iscsiadm -m session. В TrueNAS состояние пула показывает zpool status. Тест failover проводите в окно обслуживания и при наличии свежей резервной копии: во время переключения возможны краткие ошибки ввода-вывода, и приложения без настроенных таймаутов реагируют на них сбоями.

Резервирование путей ввода-вывода: настройка multipath I/O

Multipath I/O позволяет серверу видеть несколько путей к одному LUN и переключаться между ними при отказе. Путь это цепочка из HBA или сетевого адаптера, кабеля, коммутатора и порта контроллера. Пока путь один, любой разрыв в этой цепочке означает потерю доступа к данным.

iSCSI и Fibre Channel: особенности резервирования путей

Для iSCSI две независимые подсети на разных коммутаторах дают тот же эффект, что две фабрики в FC. Jumbo Frames снижают накладные расходы, но требуют одинакового MTU на всем пути, иначе производительность падает. CHAP защищает сессии, но при ошибке в конфигурации часть путей может не подняться.

Пошаговая настройка multipath I/O на Linux

1. Установите пакеты multipath-tools (Debian, Ubuntu) или device-mapper-multipath (RHEL-совместимые дистрибутивы).
2. Создайте или отредактируйте файл /etc/multipath.conf.
3. Запустите службу multipathd и включите ее в автозапуск.
4. Проверьте, что устройства собраны в multipath.
5. Протестируйте отказ пути: отключите один кабель или порт и убедитесь, что доступ сохранился.

Пример конфигурации для iSCSI-массива:

defaults {
    user_friendly_names yes
    path_grouping_policy group_by_prio
    path_selector "round-robin 0"
    failback immediate
    no_path_retry 10
}
devices {
    device {
        vendor "TrueNAS"
        product "iSCSI Disk"
        path_grouping_policy group_by_prio
        prio alua
        failback immediate
    }
}

Политика group_by_prio собирает пути в группы по приоритету и корректно работает с ALUA: трафик идет через активный контроллер, а резервные пути остаются в горячем резерве. Политика multibus распределяет нагрузку по всем путям, но без ALUA может отправлять запросы на неоптимальный контроллер. Значение failback immediate возвращает трафик на основной путь сразу после восстановления, failback manual требует ручного вмешательства.

Команды для проверки и обслуживания:

multipath -ll
iscsiadm -m session
dmsetup ls
systemctl status multipathd

Команда multipath -ll показывает группы путей, их состояние и приоритеты. Отсутствие ALUA в настройках, один коммутатор для обоих путей и слишком широкий blacklist в multipath.conf это самые частые причины, по которым резервирование не срабатывает при реальном отказе. Пошаговые команды и разбор поведения массивов при сбоях собраны в руководстве по дублированию контроллеров и настройке Multipath I/O.

Дублирование блоков питания и дисковых полок: физический уровень отказоустойчивости

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

Схемы подключения питания: A/B-питание и ИБП

Схема A/B предполагает, что каждый блок питания устройства подключен к отдельной линии: разные вводы, разные фазы или разные ИБП. При отключении одной линии нагрузка переходит на второй блок без остановки. Проверить это можно отключением одной линии в окно обслуживания и наблюдением за датчиками питания в системе управления СХД.

ИБП рассчитывают под суммарную нагрузку стойки и требуемое время автономной работы: запас на 10 минут покрывает переход на генератор, для часа автономии нужен другой класс оборудования. Типичная ошибка: оба блока питания подключены к одному ИБП, даже если у него несколько розеток. Отказ или разряд одного ИБП останавливает устройство целиком.

Дублирование дисковых полок и SAS-цепочек

Дисковая полка тоже может отказать: контроллер полки, блок питания, кабель. Если данные лежат только в одной полке и без избыточности, отказ приводит к их потере. Избыточность обеспечивают RAIDZ, зеркала или erasure coding, а доступность повышают двойным подключением.

В схеме с двумя контроллерами и двумя полками каждый контроллер подключается к обеим полкам по отдельным SAS-цепочкам. При отказе одной полки данные остаются доступны через вторую, а массив переходит в режим пониженной производительности. На практике применяют JBOD-полки, подключенные к разным HBA, и multipath для полок: тогда потеря одного кабеля или порта не прерывает доступ.

Мониторинг питания и полок настраивается по SNMP: датчики напряжения, температуры, состояния вентиляторов и дисков. RAID без горячей замены и без контроля состояния дисков создает ложное чувство защищенности. Как связать RAID, репликацию, снапшоты и восстановление в единую схему с измеримыми RTO и RPO, разобрано в статье про RAID, репликацию и снапшоты.

Чек-лист проверки отказоустойчивости СХД перед вводом в эксплуатацию

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

• Оба контроллера активны, режим (Active-Active или Active-Passive) соответствует требованиям RTO.
• ALUA настроен, multipath -ll показывает несколько путей с корректными приоритетами.
• Тест отказа одного пути не прерывает ввод-вывод.
• Каждый блок питания подключен к отдельной линии, тест отключения одной линии пройден.
• Данные доступны при отказе одной дисковой полки или одного SAS-кабеля.
• Настроены алерты на отказ компонентов и на событие failover.
• Есть схема подключения, регламент действий при аварии и список ответственных.

Сценарии тестирования: эмуляция отказа контроллера, пути, БП и полки

1. Отказ контроллера. Перевести узел в standby или отключить питание, замерить время переключения, проверить доступность данных и логи.
2. Отказ пути. Отключить один кабель или порт, убедиться, что multipath переключился на резервный путь без ошибок ввода-вывода.
3. Отказ питания. Отключить одну линию, проверить, что система работает, а датчики показывают переход на второй блок.
4. Отказ полки. Отключить одну полку, проверить доступность данных через вторую и состояние массива.

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

Мониторинг и документация: что должно быть настроено до ввода в эксплуатацию

Без наблюдения отказоустойчивость остается теоретической: система переключится на резерв, а команда узнает об этом через месяц по логам. Минимальный набор: опрос состояния контроллеров, путей, блоков питания и полок по SNMP, метрики задержек ввода-вывода и алерты на события переключения. Инструменты: Zabbix, Prometheus с экспортерами, встроенные средства оповещения СХД.

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

Особенности отказоустойчивости в SDS и HCI

Программно-определяемое хранилище (SDS) переносит функции хранения данных с уровня специализированного оборудования на программный уровень. Такое построение позволяет использовать стандартные серверы и диски, а логику RAID, репликации и снапшотов берет на себя софт.

Гиперконвергентная инфраструктура (HCI) объединяет вычислительные ресурсы и программно-определяемое хранилище на стандартных серверных узлах. Вычисления и хранение живут на одних и тех же машинах, а данные распределяются между узлами кластера.

Репликация и erasure coding как основа отказоустойчивости в SDS

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

Выбор между вариантами влияет на RTO, RPO и стоимость одновременно. В Ceph применяют и репликацию 3x, и пулы с erasure coding: первый вариант для баз данных, второй для архивов и объектного хранения.

Резервирование контроллеров и путей ввода-вывода в SDS сохраняется, но к нему добавляется резервирование сети между узлами. Сеть хранения выносят в отдельный VLAN или физически отделяют от сети управления, ставят два коммутатора и агрегацию каналов. Кластер из трех узлов с репликацией 3x переживает отказ одного узла без потери данных, но при потере связности между узлами часть из них может перейти в режим только для чтения.

Типичные ошибки при построении отказоустойчивой СХД

1. Оба блока питания в одну розетку или один ИБП. Отказ линии останавливает устройство целиком. Подключайте блоки к разным вводам питания.
2. Оба пути ввода-вывода через один коммутатор. Резервные пути сходятся в одной точке отказа. Используйте два независимых коммутатора и две подсети или две фабрики.
3. Отсутствие тестов failover. Конфигурация, не проверенная отключением компонента, может не переключиться. Проводите тесты в окно обслуживания.
4. RAID без контроля состояния дисков и горячей замены. Деградировавший массив без внимания теряет второй диск и приводит к потере данных.
5. Ненастроенный мониторинг. Без алертов резервный компонент остается незамеченным до следующей аварии.
6. Игнорирование обновлений прошивок. Производители закрывают в прошивках ошибки, влияющие на переключение и целостность данных. Обновляйте согласованно на всех контроллерах.
7. Единая точка отказа в сети. Один коммутатор для всех узлов кластера сводит на нет избыточность хранения.

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

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