Отказоустойчивость хранилища достигается двумя ключевыми механизмами: дублированием контроллеров и настройкой Multipath I/O. Контроллеры обеспечивают непрерывность управления дисковым массивом, а Multipath создает избыточные пути передачи данных. При выходе из строя одного диска или целого контроллера система автоматически переключается на резервный компонент без прерывания доступа к данным. Эта архитектура исключает единую точку отказа и критически важна для сервисов, где простой недопустим.
В этом материале разберем, как именно работает связка «дублированный контроллер + Multipath». Вы получите пошаговую инструкцию по настройке multipath-tools в Linux, узнаете, как RAID-массив реагирует на отказ диска или контроллера, и научитесь тестировать отказоустойчивость без риска для данных. Все примеры проверены на практике и адаптированы для системных администраторов и DevOps-инженеров.
Архитектура отказоустойчивого хранилища: как это работает
Центральная идея отказоустойчивого хранилища - избыточность на каждом уровне: от физического диска до пути ввода-вывода. RAID защищает от выхода из строя накопителей. Дублирование контроллеров страхует от отказа управляющей электроники. Multipath I/O добавляет резервирование на уровне соединений между сервером и системой хранения. Каждый уровень работает независимо, вместе они формируют эшелонированную защиту.
Представьте сервер, подключенный к дисковому массиву двумя независимыми каналами через два отдельных контроллера. Один кабель, один HBA-адаптер или один контроллер могут отказать - операционная система даже не заметит сбоя. Именно такую архитектуру мы будем настраивать.
Роль контроллеров и их дублирование
Контроллер хранилища управляет физическими дисками, строит RAID-массив, обрабатывает операции чтения и записи, управляет кэшем. Его отказ без резервирования означает полную потерю доступа ко всем данным на массиве, даже если сами диски исправны.
Дублирование контроллеров решает эту проблему. Два контроллера работают в паре и постоянно синхронизируют состояние. Применяются два основных режима:
- Active/Passive (активный/пассивный). Один контроллер обрабатывает все запросы, второй находится в горячем резерве. При отказе активного пассивный подхватывает управление за секунды. Производительность не суммируется, зато поведение предсказуемо.
- Active/Active (активный/активный). Оба контроллера одновременно обслуживают запросы к разным томам или LUN. При отказе одного второй берет на себя его нагрузку. Общая производительность выше, но требуется тщательное планирование распределения томов.
Автоматическое переключение (failover) происходит прозрачно для операционной системы. Контроллеры обмениваются heartbeat-сигналами, и как только резервный перестает их получать, он активирует свои порты и продолжает обслуживание.
Multipath I/O: избыточность на уровне путей доступа
Multipath I/O - это подсистема ядра Linux, которая объединяет несколько физических путей к одному устройству хранения в одно логическое устройство. Каждый путь может проходить через разные HBA-адаптеры, кабели, коммутаторы и контроллеры. Если один из компонентов на пути выходит из строя, Multipath переключает трафик на оставшиеся пути.
Идентификация устройства происходит по WWID (World Wide Identifier) - уникальному идентификатору, который назначается производителем. Multipath обнаруживает все пути, ведущие к одному WWID, и создает виртуальное блочное устройство в /dev/mapper/. Приложение работает с этим виртуальным устройством и не знает о количестве физических путей.
Демон multipathd постоянно отслеживает состояние путей. При обрыве он помечает путь как failed и исключает из маршрутизации. При восстановлении - возвращает в работу согласно настроенной политике failback. Подробнее о диагностике подобных проблем читайте в руководстве по диагностике неполадок RAID-контроллера.
Поведение RAID-массива при аппаратных сбоях
RAID-массив продолжает функционировать при выходе из строя одного или нескольких дисков - количество допустимых отказов зависит от уровня RAID. Массив не теряет данные, но может снизить производительность. Понимание этих процессов помогает правильно спланировать обслуживание и избежать паники при срабатывании уведомления о сбое.
Отказ диска: деградация и восстановление
При отказе диска контроллер фиксирует ошибки операций ввода-вывода, проверяет SMART-атрибуты и помечает накопитель как failed. Массив переходит в состояние degraded (деградированный). Данные остаются доступными за счет избыточности - четности в RAID 5/6 или зеркалирования в RAID 10.
Если в массиве настроен hot spare (горячий резервный диск), контроллер немедленно начинает rebuild - процесс восстановления избыточности на заменяющем диске. Время восстановления зависит от объема массива и нагрузки. Для массива 10 ТБ на HDD rebuild может занять от 8 до 24 часов. В этот период производительность снижена, а дополнительный отказ диска в RAID 5 приведет к потере данных. Рекомендуем всегда настраивать hot spare - это сокращает окно уязвимости до минут. Практические инструкции по настройке горячей замены и мониторингу состояния массива собраны в статье по администрированию RAID-массивов на HP Smart Array.
Отказ контроллера: переключение на резервный
При отказе активного контроллера резервный фиксирует потерю heartbeat-сигналов и активирует свои порты. Он подхватывает управление дисками, загружает конфигурацию массивов из энергонезависимой памяти и продолжает обработку запросов. Весь процесс занимает от 2 до 15 секунд в зависимости от модели оборудования.
Multipath I/O в это время обнаруживает, что пути через отказавший контроллер стали недоступны, и перенаправляет весь трафик на пути через резервный контроллер. Приложения могут заметить кратковременную паузу, но не потерю доступа. После замены отказавшего контроллера и его синхронизации Multipath возвращает пути в работу.
Выбор уровня RAID напрямую влияет на устойчивость к отказам. Свежее сравнение RAID 10, 5, 6 и ZFS с готовыми командами для настройки вы найдете в полном гиде по RAID-массивам 2026.
Настройка Multipath I/O в Linux: пошаговое руководство
Переходим к практике. Настройка Multipath в Linux состоит из трех этапов: установка пакетов, конфигурация через /etc/multipath.conf и проверка результата. Все команды приведены для RHEL/CentOS/Rocky Linux 8/9 и Debian/Ubuntu 22.04/24.04.
Установка и первичная конфигурация
Установите пакет multipath-tools. В RHEL-совместимых дистрибутивах:
dnf install -y device-mapper-multipathВ Debian/Ubuntu:
apt install -y multipath-toolsПосле установки создайте базовый конфигурационный файл. Если /etc/multipath.conf отсутствует, скопируйте шаблон:
cp /usr/share/doc/device-mapper-multipath/multipath.conf /etc/multipath.confМинимальная рабочая конфигурация включает глобальные настройки в секции defaults:
defaults {
user_friendly_names yes
polling_interval 5
max_polling_interval 20
path_selector "service-time 0"
failback immediate
}Разберем ключевые параметры. user_friendly_names yes назначает устройствам имена вида mpathX вместо длинных WWID. polling_interval 5 задает интервал проверки состояния путей в секундах. path_selector определяет алгоритм выбора пути - service-time оценивает загрузку путей и направляет трафик на наименее загруженный. failback immediate предписывает немедленно возвращать восстановившийся путь в работу.
Запустите службу и добавьте ее в автозагрузку:
systemctl enable --now multipathdКонфигурация устройств и путей
Секция devices описывает параметры для конкретных моделей систем хранения. Multipath определяет устройство по полям vendor и product из вывода scsi_id. Пример для распространенного массива с активным/пассивным режимом:
devices {
device {
vendor "VENDOR"
product "MODEL"
path_grouping_policy group_by_prio
path_checker tur
prio alua
failback immediate
no_path_retry 3
}
}path_checker tur использует команду Test Unit Ready для проверки доступности пути - это стандартный и надежный метод. prio alua задействует протокол Asymmetric Logical Unit Access для определения приоритетов путей. Контроллер, владеющий томом, получает более высокий приоритет. no_path_retry 3 задает количество повторных попыток при отказе всех путей перед возвратом ошибки приложению.
Секция multipaths позволяет задать параметры для конкретного тома по его WWID:
multipaths {
multipath {
wwid 3600508b1001c2d0a0000a0000b000000
alias data_volume
path_grouping_policy multibus
}
}Здесь тому назначается понятный алиас data_volume и задается политика группировки путей multibus для активного/активного режима. После изменения конфигурации перезагрузите демон:
systemctl reload multipathdПроверка и мониторинг конфигурации
Основная команда для проверки - multipath -ll. Она выводит топологию всех multipath-устройств с детализацией по путям:
mpathb (3600508b1001c2d0a0000a0000b000000) dm-3 VENDOR,MODEL
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:1 sdb 8:16 active ready running
| `- 2:0:0:1 sdd 8:48 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:1 sdc 8:32 active ready running
`- 2:0:1:1 sde 8:64 active ready runningВ выводе видны две группы путей. Первая с приоритетом 50 и статусом active - это пути через контроллер, владеющий томом. Вторая с приоритетом 10 и статусом enabled - пути через резервный контроллер. При отказе активных путей трафик переключится на группу enabled.
Для мониторинга в реальном времени используйте multipathd show paths - команда показывает состояние каждого пути, количество ошибок и задержек. Логи демона доступны через journalctl:
journalctl -u multipathd -fПодробнее о маршрутизации данных в SAN и распределенных файловых системах читайте в руководстве по настройке отказоустойчивости SAN.
Выбор режима работы Multipath: failover или multibus
Multipath поддерживает два основных режима группировки путей, и выбор между ними определяет поведение при сбоях и общую производительность.
Failover (активный/пассивный) - это политика group_by_prio. Все пути делятся на группы с разным приоритетом. Трафик идет только через группу с наивысшим приоритетом. Остальные группы находятся в режиме ожидания. При отказе всех путей в активной группе трафик переключается на следующую по приоритету. Режим надежен, предсказуем и подходит для большинства корпоративных СХД.
Multibus (активный/активный) - политика multibus. Все пути объединяются в одну группу, и трафик распределяется между ними по алгоритму, заданному в path_selector. Режим суммирует пропускную способность путей, что дает прирост производительности на операциях с большим количеством параллельных запросов.
Multibus требует осторожности. Если контроллеры хранилища работают в активном/пассивном режиме, а на сервере настроен multibus, трафик пойдет на пассивный контроллер. Тот будет пробрасывать запросы активному через внутреннюю шину, создавая двойную нагрузку и увеличивая задержки. Перед включением multibus убедитесь, что СХД поддерживает симметричный доступ (ALUA или true active/active).
Рекомендация: для баз данных и транзакционных нагрузок используйте failover - стабильность важнее пиковой производительности. Для файловых хранилищ и потокового видео multibus дает ощутимый выигрыш при условии поддержки со стороны СХД.
Тестирование отказоустойчивости: симуляция сбоев
Настроенная система требует проверки. Симуляция отказов подтвердит, что failover работает корректно, а приложения не теряют доступ к данным. Проводите тестирование на нерабочей нагрузке или в окно обслуживания.
Симуляция отказа пути и контроллера
Подготовьте длительную операцию, чтобы наблюдать за поведением системы в реальном времени. Запустите запись большого файла с выводом прогресса:
dd if=/dev/zero of=/mnt/data/testfile bs=1M count=100000 status=progressВ другом терминале отслеживайте состояние путей:
watch -n 1 'multipath -ll'Теперь симулируйте отказ. Самый безопасный способ - перевести порт коммутатора в состояние down, если используется SAN. Для прямого подключения временно отключите один из кабелей между HBA и контроллером. Наблюдайте за выводом multipath -ll: отказавший путь должен перейти в статус failed faulty, а трафик - переключиться на оставшиеся пути. Операция dd продолжит выполняться, возможно, с кратковременным снижением скорости.
Восстановите соединение. Если в конфигурации указан failback immediate, путь вернется в статус active ready running автоматически. При настройке failback manual потребуется команда multipathd reconfigure.
Для симуляции отказа контроллера (если оборудование позволяет) используйте команду управления контроллером - например, storcli /c0 set offline для LSI/Broadcom. Multipath переключит трафик на пути через второй контроллер. После включения контроллера и его синхронизации пути восстановятся.
Типичные проблемы и их решение
При настройке Multipath администраторы сталкиваются с повторяющимися проблемами. Разберем самые частые и способы их решения.
Проблемы совместимости и правила udev
Самая распространенная проблема - конфликт Multipath с правилами udev. По умолчанию udev создает символические ссылки на блочные устройства в /dev/disk/by-id/ и /dev/disk/by-path/. Эти ссылки указывают на отдельные пути, а не на виртуальное multipath-устройство. Если приложение или файл /etc/fstab ссылается на такой путь, после отказа канала устройство станет недоступным.
Решение - всегда использовать ссылки из /dev/mapper/ или /dev/disk/by-id/dm-uuid-*. В /etc/fstab прописывайте:
/dev/mapper/data_volume /mnt/data ext4 defaults,_netdev 0 2Опция _netdev критически важна для SAN и iSCSI - она указывает системе, что устройство сетевое, и откладывает монтирование до поднятия сети и multipathd.
Другая частая проблема - неправильный path_checker. Для разных СХД требуются разные методы проверки. Стандартный tur работает с большинством массивов, но некоторые требуют readsector0 (чтение нулевого сектора) или специфичных для вендора чекеров. Если пути циклически переходят между состояниями active и failed, смените path_checker в соответствии с документацией производителя СХД.
При использовании отечественных систем хранения учитывайте особенности их реализации ALUA. В руководстве по российским СХД 2026 разобраны типичные конфигурации для оборудования «Русский Щит» и Kraftway Storage.
Проверка совместимости выполняется командой multipath -v2 -d - она запускает демон в режиме отладки и выводит обнаруженные устройства без создания multipath-устройств. Внимательно изучите вывод на предмет ошибок определения приоритетов и группировки путей.