iSCSI multipath в Linux: настройка, ALUA, split-path и диагностика

Зачем нужен multipath iSCSI и почему «split-path» — частая боль

iSCSI в Linux обычно заводится быстро: подняли open-iscsi, залогинились на target, увидели новый диск — поехали. Проблемы начинаются, когда появляется «взрослая» SAN: два контроллера, два IP на порталах, две сетевые карты на хосте, несколько путей до одного LUN. Без multipath вы видите несколько блочных устройств, которые на самом деле указывают на один и тот же LUN. Это прямой путь к порче ФС и странным инцидентам.

Под «split-path» обычно имеют в виду ситуацию, когда пути до одного LUN «разъехались»: часть I/O идёт через одно устройство, часть — через другое, или система начинает воспринимать один LUN как два разных диска. Типовые симптомы:

• вместо одного диска появляется два (или больше) /dev/sdX от разных iSCSI-сессий;
• после рестарта меняются буквы sdX, и /etc/fstab «попадает» не на тот путь;
• multipath то собирает mpathX, то оставляет «осиротевшие» пути;
• при обрыве одного пути начинается серия ошибок, после чего ФС требует fsck;
• в худшем случае получаете «split brain»: один LUN используется двумя узлами без кластерной блокировки.

Ниже — практичный чеклист настройки device-mapper-multipath и multipathd, чтобы многопутевость была предсказуемой, персистентной и хорошо диагностировалась.

Базовая архитектура: где заканчивается iSCSI и начинается multipath

Полезно разделять уровни ответственности:

• open-iscsi создаёт сессии к portal’ам и поднимает SCSI-устройства на хосте (те самые /dev/sdX).
• device-mapper-multipath (dm-multipath) агрегирует несколько SCSI-путей в одно устройство: /dev/mapper/mpath* (или алиас).
• udev и правила именования обеспечивают стабильные симлинки и свойства устройств.

Главный принцип безопасности: ФС/RAID/LVM создаём и монтируем только поверх multipath-устройства, а не поверх отдельных /dev/sdX. Любое использование «сырого» пути (особенно в /etc/fstab) — частая причина split-path и дальнейших проблем.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если вы поднимаете хосты под хранилище в облаке, удобнее тестировать iSCSI/multipath на отдельной машине: для этого подойдёт VDS с двумя сетевыми интерфейсами и управляемой маршрутизацией.

Предварительные требования: сеть, инициатор и дисциплина имен

Сеть и маршрутизация

Для двух путей обычно делают две независимые сети (или VLAN) и избегают асимметрии. До настройки multipath проверьте:

• оба iSCSI портала реально доступны по TCP/3260;
• каждый путь «привязан» к своему интерфейсу (policy routing или хотя бы корректные маршруты);
• MTU одинаковый по всей цепочке (если используете jumbo — то везде);
• нет «случайного» NAT/conntrack на пути, который может рвать долгие TCP-сессии.

Идентичность LUN: WWID важнее букв sdX

/dev/sdX — не идентификатор. Для multipath якорь — WWID LUN. Он позволяет «склеивать» пути в один mpath независимо от порядка обнаружения устройств.

Установка и включение: open-iscsi и multipathd

Набор пакетов зависит от дистрибутива, но логика одинаковая: нужны open-iscsi и multipath-tools (названия могут отличаться). Включаем службы:

systemctl enable --now iscsid
systemctl enable --now multipathd

Дальше подключаемся к target через discovery и login (подставьте свои IP/iqn):

iscsiadm -m discovery -t sendtargets -p 10.0.10.10:3260
iscsiadm -m discovery -t sendtargets -p 10.0.20.10:3260
iscsiadm -m node --login

Если у вас два портала, после логина вы обычно увидите два SCSI-диска на один LUN (например, /dev/sdb и /dev/sdc). В этот момент не размечайте и не монтируйте их напрямую: работаем только через multipath.

multipath.conf: сборка путей, ALUA и «устойчивое имя»

Конфигурация multipath.conf определяет, как multipathd распознаёт LUN, какие устройства включать/исключать, и как выбирать активный путь.

Минимальная, но безопасная база

Одна из типовых ошибок — включить multipath «на всё подряд». В результате в multipath попадают локальные диски, виртуальные устройства, loop и т.д. Безопаснее явно ограничить область и использовать blacklist. Пример базовой конфигурации (адаптируйте под себя и под дистрибутив):

defaults {
  user_friendly_names yes
  find_multipaths yes
  reassign_maps yes
  polling_interval 5
}

blacklist {
  devnode "^sd[a]$"
  devnode "^nvme"
  devnode "^loop"
}

Коротко по параметрам:

• find_multipaths снижает риск создания mpath там, где нет реальной многопутевости.
• reassign_maps помогает сохранять карты при изменениях путей (поведение зависит от версии multipath-tools).
• user_friendly_names удобно для быстрой диагностики, но для продакшена лучше фиксировать имена через alias по WWID (ниже).

Стабильные имена: alias вместо «mpathb»

Для практичной «персистентности» имён заведите секцию multipaths и привяжите WWID к читаемому имени. Тогда даже если порядок путей и буквы sdX меняются, устройство будет стабильно доступно как /dev/mapper/имя.

multipaths {
  multipath {
    wwid  "36001405abcde1234567890fedcba9876"
    alias "db_lun01"
  }
}

WWID берите из вывода multipath -ll после первичного обнаружения.

ALUA и политика путей

Если SAN поддерживает ALUA (Asymmetric Logical Unit Access), часть путей будет optimized, часть non-optimized. Это нормально: multipath должен предпочитать оптимизированные пути и корректно переключаться при отказе контроллера или порта.

Признаки, что ALUA работает неправильно:

• все пути выглядят одинаково активными, хотя SAN асимметричная;
• при failover «зависает» I/O на десятки секунд;
• растут задержки и очередь, хотя нагрузка небольшая.

Иногда нужно явно задать политику группировки/приоритета под конкретный vendor/product массива. Ориентир: для ALUA обычно используют prio alua и группировку по приоритету, но финальные параметры лучше сверять с рекомендациями производителя SAN.

Как выглядит «здоровый» multipath и что проверять первым

После правок конфигурации перезапустите демон и пересоберите карты:

systemctl restart multipathd
multipath -r
multipath -ll

В «здоровом» состоянии вы видите один mpath-девайс и несколько путей внутри. Важно, чтобы все пути относились к одному WWID, а статусы путей были в рабочем состоянии (например, active/ready/running — точные слова зависят от версии).

Ещё два источника правды:

multipathd show maps
multipathd show paths

Если видите несколько разных mpath для одного LUN — это уже симптом split-path: где-то «не сходится» WWID/атрибуты udev, либо SAN отдаёт разные идентификаторы по разным путям (тогда нужно чинить на стороне target/массива).

Split-path на практике: типовые причины и как чинить

Причина 1: разметка/ФС сделаны на /dev/sdX

Классика: разметили /dev/sdb, а через неделю он стал /dev/sdc, и система либо не загрузилась, либо смонтировала «не то». Лечение: переносим точку опоры на multipath — используем /dev/mapper/mpath* или alias, а в /etc/fstab предпочитаем UUID файловой системы или явный путь /dev/mapper/alias.

Причина 2: multipath подхватывает не те диски (или не подхватывает нужные)

Доведите до ума blacklist и убедитесь, какие устройства реально видит multipath. Если локальный диск случайно попал в multipath, это может проявляться очень «творчески» — вплоть до проблем при загрузке.

Причина 3: разные WWID по разным путям

Иногда target/SAN отдаёт идентификаторы несимметрично (или есть баг в конфигурации). Для Linux это выглядит как разные диски, и multipath их не «склеит». Нужно добиться, чтобы по всем путям LUN имел один WWID. Быстрая диагностика — сравнить udev-свойства каждого /dev/sdX:

udevadm info --query=all --name=/dev/sdb
udevadm info --query=all --name=/dev/sdc

Сравнивайте ID/serial/wwid атрибуты и сверяйте, что массив действительно отдаёт один и тот же идентификатор.

Причина 4: «двойной доступ» к LUN и риск split brain

Split brain в контексте SAN и Linux storage — это одновременная запись в один LUN с двух хостов без кластерной координации. Такое иногда случается случайно: LUN «примапили» двум серверам, или в аварии подняли второй хост и подключили тот же том «на всякий случай».

Если LUN не предназначен для кластерного доступа, правило простое: один LUN — один активный писатель. Для общего диска используйте кластерную ФС и механизм блокировок, иначе почти гарантированно поймаете порчу данных.

Практический контроль: на стороне SAN фиксируйте маппинг LUN к конкретным initiator’ам, а на стороне Linux — держите порядок в /etc/iscsi/initiatorname.iscsi и не клонируйте машины с одинаковым IQN без замены.

Failover пути: почему иногда нужен fsck и как снизить вероятность

При обрыве пути возможны два сценария:

• Короткая деградация: multipath быстро переключился, приложения почти не заметили.
• Долгая пауза/таймаут: запросы «встали», ФС получила ошибки записи или чтения, а затем при следующем монтировании требуется fsck.

Что чаще всего растягивает failover: TCP-таймауты iSCSI, агрессивная/неудачная проверка путей в multipath, поведение массива при ALUA failover. Цель тюнинга — сделать так, чтобы отказ одного пути выглядел как быстрый перенос на живой путь, а не как минутное ожидание с волной ошибок.

Если вы строите отказоустойчивые схемы не только для хранилища, но и для сервисов управления, пригодится шаблонный подход к failover: например, для DNS-зон полезна статья про взвешенный роутинг и failover в GeoDNS — по смыслу это та же дисциплина тестирования и наблюдаемости, только на другом уровне.

Тестирование: fio для IOPS/latency и проверка failover

Чтобы не гадать по ощущениям, используйте fio и два типа тестов: измерение задержек и имитация отказа пути.

Базовый тест на задержки

Пример случайного чтения с замером задержек на multipath-устройстве. Указывайте правильный девайс и не запускайте на продовых данных без понимания последствий:

fio --name=randread --filename=/dev/mapper/db_lun01 --direct=1 --ioengine=libaio --bs=4k --iodepth=32 --rw=randread --numjobs=1 --time_based=1 --runtime=60 --group_reporting

Смотрите p95/p99 задержек и сравнивайте до/после изменений.

Failover-тест

Запускаете fio и во время теста «роняете» один путь (например, выключив интерфейс или убрав маршрут). В идеале будет небольшой всплеск задержек, но без обвала и без I/O errors. Если начинаются ошибки — для вашей связки SAN+iSCSI+multipath failover настроен небезопасно (или у массива медленный ALUA-переход, который нужно учитывать параметрами/таймаутами).

udev и «порядок в /dev»: когда нужно вмешиваться

Чаще всего достаточно корректного multipath.conf и alias по WWID. Но иногда приходится разбираться с udev, если:

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

Начинайте с диагностики: udevadm info, просмотр событий, сравнение атрибутов. Делать кастомные правила стоит только когда ясно, какую проблему вы решаете — иначе легко закрепить «случайное совпадение» и получить новый split-path после обновления ядра или пакетов.

Чеклист: как не словить split-path и split brain

1. Всегда работайте с LUN через /dev/mapper/mpath* или alias, а не через /dev/sdX.
2. Добейтесь стабильного имени: WWID → alias в multipaths.
3. Проверьте, что все пути имеют одинаковый WWID и корректно группируются.
4. Если SAN с ALUA — убедитесь, что пути различаются по состоянию optimized/non-optimized и multipath выбирает правильные.
5. Регулярно тестируйте failover под нагрузкой и смотрите на ошибки ввода-вывода и p95/p99 задержек.
6. Не допускайте одновременной записи в один LUN с двух хостов без кластерной ФС и блокировок.

Диагностика инцидентов: команды, которые реально помогают

Когда «что-то пошло не так», соберите короткий набор фактов:

lsblk
iscsiadm -m session
multipath -ll
multipathd show maps
multipathd show paths
dmesg -T | tail -n 200

Если видите внезапные I/O ошибки, «flapping» путей и рост задержек — фиксируйте время и коррелируйте с сетевыми событиями, логами SAN и состоянием интерфейсов. В storage-инцидентах критична причинно-следственная цепочка: что первым деградировало — сеть, портал, контроллер, ALUA-состояние или таймауты на хосте.

Итог

Multipath iSCSI в Linux — это не только «поставить пакеты и включить multipathd». Устойчивость достигается дисциплиной: используем dm-multipath как единственную точку доступа к LUN, обеспечиваем стабильные имена через alias по WWID, учитываем ALUA, тестируем failover под нагрузкой и не допускаем сценариев split brain. Тогда даже при падении одного пути поведение будет предсказуемым, без внезапного fsck и без потери данных.