iSCSI + dm-multipath на Linux: как пережить отказ пути без паузы в работе

В мае вышел open-iscsi 2.0.870, и в этом релизе наконец нормально починили автоматическое переподключение при потере пути. Мы как раз в процессе - подключаем несколько Linux-серверов к iSCSI SAN, так что новая версия пришлась вовремя. Пишем по горячим следам, пока всё ещё свежо.

Зачем вообще multipath

iSCSI - это SCSI поверх TCP/IP. Дисковый массив торчит в сети как обычный хост, сервер подключается к нему как к инициатору, монтирует LUN и видит его как обычный блочный диск. Удобно, дёшево относительно FC, работает на стандартном железе.

Проблема в том, что сетевой путь между сервером и массивом может упасть - отказ свитча, потеря линка, перегрузка порта. Если путь один, всё приложение, работающее с этим диском, встаёт. dm-multipath решает это так: сервер видит один «виртуальный» диск, а под ним - несколько реальных путей к одному LUN через разные сетевые интерфейсы и свитчи. При отказе одного пути ввод-вывод переключается на другой без остановки.

На практике у нас два физических линка с сервера, два разных свитча доступа, два порта на массиве. Если упадёт один свитч или один линк - диск остаётся доступен через второй путь.

Что пришлось настраивать

Сама установка open-iscsi плюс multipath-tools несложная. Реальная работа началась, когда мы начали тестировать переключение - имитировали отказ пути, выдёргивая кабель.

Картина без правильных таймаутов была такая: при выдёргивании кабеля dm-multipath довольно быстро понимал, что путь недоступен. Но сессия iSCSI продолжала висеть - open-iscsi ждал восстановления соединения согласно своим таймаутам. В этот период ввод-вывод через другой путь шёл нормально, но через несколько секунд начинались тайм-ауты на уровне блочного устройства. Файловая система уходила в read-only, приложение падало с ошибкой.

Корень проблемы оказался в несоответствии таймаутов. У open-iscsi есть параметр node.session.timeo.replacement_timeout - сколько секунд ждать восстановления сессии прежде чем сдаться и дать ошибку блочному слою. По умолчанию он стоит 120 секунд. Это значит: два минуты подвешенного ввода-вывода при любом разрыве сессии, даже если dm-multipath давно переключился на живой путь.

На стороне target у нашего массива был свой таймаут - через сколько секунд он считает сессию мёртвой и освобождает ресурсы. Если этот таймаут меньше replacement_timeout initiator'а, возникает коллизия: массив уже закрыл сессию, initiator ещё ждёт её восстановления.

Как выровняли

Логика примерно такая:

• node.session.timeo.replacement_timeout должен быть меньше таймаута target'а - чтобы initiator успел переключиться раньше, чем target убьёт сессию
• node.conn[0].timeo.noop_out_timeout и node.conn[0].timeo.noop_out_interval управляют тем, как быстро initiator детектирует потерю соединения через NOOP-пинги
• В multipath.conf параметры polling_interval, path_checker, failback влияют на скорость детектирования упавшего пути на уровне dm-multipath

Мы установили replacement_timeout в 30 секунд, noop_out_timeout в 5, noop_out_interval в 5. На стороне массива убедились, что его таймаут сессии больше 30 секунд с запасом. После этого при выдёргивании кабеля переключение проходит чисто - ввод-вывод тормозит на несколько секунд пока dm-multipath перестраивается, потом продолжает через живой путь. Файловая система остаётся смонтированной, приложение не падает.

Несколько секунд паузы - это не ноль, но это приемлемо. Главное - нет hard error и нет необходимости перемонтировать диск вручную.

Про новый open-iscsi 2.0.870

В этом релизе починили несколько случаев, когда при переподключении сессия зависала в нечётном состоянии - initiator думал, что сессия восстановлена, хотя target её уже не видел. Мы пока не сталкивались с этим в явном виде на предыдущей версии, но в логах иногда появлялись странные сообщения о неудачных попытках переподключения. Посмотрим, как поведёт себя новая версия под реальной нагрузкой.

Также в 2.0.870 улучшили обработку ошибок при многопутевых конфигурациях - initiator теперь правильнее сообщает dm-multipath о состоянии каждой сессии. Это важно именно для нашего случая.

Что сейчас

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

Для серверов, которые мы ведём в рамках сопровождения, iSCSI multipath становится стандартной схемой там, где нужно подключить блочное хранилище без FC-инфраструктуры. Главный вывод пока один: конфигурация работает, но только если потратить время на таймауты. Дефолтные значения open-iscsi явно рассчитаны на случай, когда multipath нет - с ним надо настраивать руками.