iSCSI multipath на CentOS 7: blacklist для локальных дисков и охота на ghost-пути

Когда-то мы разбирали выбор между FC и iSCSI применительно к VMware. На этот раз история другая - Linux-серверы на CentOS 7, общее блочное хранилище по iSCSI, и задача поднять нормальный multipath без того, чтобы система сошла с ума от собственных локальных дисков.

Спойлер: multipath.conf на первый взгляд выглядит как «добавь пару строк и работает». На практике - не совсем.

Контекст

Клиент использует несколько серверов CentOS 7 как вычислительные узлы. Хранилище - внешний iSCSI-target, два пути до него через два разных коммутатора. Задача стандартная: LUN виден с двух интерфейсов, нужно чтобы система объединила пути в одно устройство, переживала потерю одного пути без паузы в работе, и не мешала нормальной работе.

Установка стандартная для RHEL/CentOS 7:

yum install device-mapper-multipath iscsi-initiator-utils
systemctl enable multipathd
systemctl enable iscsid

iscsiadm для подключения к target и обнаружения LUN-ов - отдельная история, там всё привычно. Проблемы начались после того, как LUN подключился и мы запустили multipathd.

Первая проблема: multipath видит всё подряд

Запускаем multipath -ll - и видим не только iSCSI-диски, но и локальные SATA-диски сервера. Это неприятно: во-первых, системный диск в multipath-списке выглядит как потенциальная катастрофа, во-вторых, сам multipathd начинает опрашивать локальные диски и пишет в лог что-то вроде того, что пути нестабильны.

Решение известное - blacklist в /etc/multipath.conf. На RHEL/CentOS 7 файл по умолчанию либо отсутствует, либо минимальный. Вот что мы прописываем:

blacklist {
    devnode "^sda"
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
}

blacklist_exceptions {
    property "ID_WWN"
}

Логика: исключить системный диск (sda) и все нежелательные псевдоустройства явно, а в blacklist_exceptions разрешить обратно всё, что имеет WWN - то есть реальные блочные устройства с хранилища. iSCSI LUN-ы WWN имеют, локальные SATA-диски в типовой конфигурации - тоже, так что это не серебряная пуля.

Более надёжный способ - исключать по WWID конкретного системного диска:

/sbin/scsi_id -g -u -d /dev/sda

Выдаёт что-то вроде 3600508b1001c5e4f5a5a4a4a4a4a4a4a. Этот идентификатор прописываем в blacklist явно:

blacklist {
    wwid "3600508b1001c5e4f5a5a4a4a4a4a4a4a"
}

После перезапуска multipathd - multipath -ll показывает только iSCSI-устройство с двумя путями. Локальные диски исчезли из вывода.

Вторая проблема: ghost-пути

После нескольких часов работы мы заметили интересное: multipath -ll показывает не два, а три пути. Один из них помечен как ghost или faulty. При этом хранилище доступно, сессии iSCSI живые, IO идёт.

Это классический ghost-путь. Появляется когда iscsiadm обнаружил и зарегистрировал путь в момент запуска, потом путь по каким-то причинам стал недостоверным (переподключение, перебой), а kernel device mapper запомнил его как отдельное блочное устройство. Multipathd видит «устаревший» device, который физически уже не соответствует активной сессии.

Что помогло:

Первое - проверить реальные iSCSI-сессии:

iscsiadm -m session -P 3

Вывод показывает активные сессии, состояние (LOGGED IN), и какие именно устройства к ним привязаны. Если в вывode два пути, а multipath видит три - где-то есть «мёртвый» device без живой сессии.

Второе - принудительно убрать ghost-пути:

multipath -f <device>
multipathd reconfigure

Или, если хочется грубее:

multipathd -k"remove path <имя_пути>"

Третье - разобраться с причиной появления. В нашем случае виновником оказалась настройка discovery в iscsiadm: при старте системы iscsiadm --mode discovery выполнялся дважды - один раз через iscsid.service и один раз через скрипт в /etc/rc.local, оставшийся от предыдущей версии конфигурации. Дублированный discovery создавал дополнительную запись в /var/lib/iscsi/nodes/, которая при загрузке поднималась как отдельная сессия, а потом оказывалась лишней.

Убрали дублирующий вызов, почистили /var/lib/iscsi/nodes/ от лишних записей, перезагрузили - ghost-пути больше не появлялись.

Параметры multipath для iSCSI

Помимо blacklist, стоит явно выставить тип checker-а и политику:

defaults {
    user_friendly_names yes
    path_grouping_policy failover
    path_checker tur
    failback immediate
    no_path_retry 5
}

path_checker tur - Test Unit Ready, стандартный SCSI-запрос, работает надёжно с большинством iSCSI-target-ов. failback immediate - при восстановлении упавшего пути сразу возвращаем на него IO, не ждём. no_path_retry 5 - пять попыток перед тем как объявить устройство недоступным, а не бесконечный цикл.

Для active-active multipath (если target его поддерживает) меняем path_grouping_policy на multibus и добавляем rr_min_io 100. Но это уже зависит от конкретного хранилища - не все iSCSI-target-ы корректно работают в active-active без дополнительной настройки на стороне СХД.

Итог

Конфигурация работает. Два пути активны, переключение при отключении одного коммутатора происходит без видимых ошибок на приложении. Ghost-пути не появляются. Мониторинг multipath -ll добавили в нашу инфраструктуру наблюдения - если число путей отклоняется от двух, летит алерт.

Главный вывод: multipath на Linux настраивается, но требует аккуратности именно в blacklist и в том, как iscsiadm стартует при загрузке. Половина проблем, которые мы видим на практике - это либо лишние устройства в multipath, либо двойные discovery-сессии. Оба лечатся конфигом, не магией.