iSCSI и MPIO: добавляем второй путь и тестируем выдёргиванием кабеля

Когда мы запускали первый iSCSI-стенд в мае, намеренно упростили схему: один коммутатор, один сетевой адаптер на клиенте, один путь до хранилища. Цель была - убедиться, что iSCSI вообще работает как замена FC для аналитической нагрузки. Убедились. Но одно дело лабораторный прогон, другое - продакшен, где хранилище трогать нельзя.

Обрыв кабеля проявил проблему наглядно. Во время плановой работы в серверной кто-то задел кабель - iSCSI-сессия упала, SQL Server завис с ошибками I/O, пришлось руками перезапускать сервис. Ничего катастрофического, но неприятно. Клиент спросил: «А что с отказоустойчивостью?» Ответить было нечего.

Что такое MPIO и почему заговорили о нём сейчас

Multipath I/O - механизм, при котором между сервером и хранилищем существует несколько физических путей, и при выходе из строя одного трафик автоматически переходит на другой. В мире Fibre Channel это стандартная практика, там MPIO-драйверы поставляют производители HBA. В мире iSCSI на Windows ситуация была сложнее: либо сторонние решения, либо городить что-то руками.

Windows Server 2003 R2, вышедший в конце 2005, включил Microsoft MPIO как компонент операционной системы. Сам фреймворк - это не готовый драйвер под конкретный тип хранилища, а платформа, к которой подключаются DSM (Device Specific Module). Для iSCSI Microsoft выпустил MSDSM - модуль, который понимает iSCSI-сессии и умеет между ними переключаться. Всё это входит в состав системы, без отдельной покупки.

Именно это сделало задачу практически решаемой на нашем стенде - у клиента как раз Windows Server 2003 R2.

Схема с двумя путями

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

[Win SRV]---[NIC 1]---[Switch A]---[NIC A]---[OpenFiler]
[Win SRV]---[NIC 2]---[Switch B]---[NIC B]---[OpenFiler]

Два коммутатора, два сетевых адаптера на клиенте, два адаптера на хранилище. Каждый путь - изолированная цепочка. Падает Switch A или рвётся кабель на первом пути - трафик идёт через Switch B, сервер продолжает работать.

На OpenFiler добавили второй сетевой адаптер, поднял второй IP в той же подсети хранилища, но на другом физическом интерфейсе. На стороне клиента - то же самое: второй адаптер, второй IP.

Установка и настройка MPIO

Установка компонента через «Add/Remove Windows Components» - там MPIO прячется под «Management and Monitoring Tools». После установки появляется mmc-оснастка «MPIO» и служба MPIO.

Дальше нужно зарегистрировать iSCSI как тип устройства, которым управляет MSDSM. Делается через команду:

mpclaim -r -i -a ""

Перезагрузка. После этого Microsoft iSCSI Initiator при подключении к target на двух адресах видит два пути и передаёт управление ими в MPIO.

Подключение target добавляем дважды - сначала через IP первого адаптера хранилища, потом через IP второго. Initiator создаёт две сессии к одному и тому же IQN target. MPIO подхватывает оба пути и показывает одно логическое устройство в «Disk Management».

В оснастке MPIO можно выбрать политику балансировки: Round Robin (трафик чередуется между путями), Fail Over Only (один путь активный, второй резервный), Least Queue Depth и другие. Для нашей задачи выбрали Round Robin - пусть оба пути работают, заодно суммарная полоса выше.

Тест выдёргиванием кабеля

Проверять отказоустойчивость в теории неинтересно. Подождали, пока по iSCSI идёт реальная нагрузка - копирование большого файла, чтобы был виден трафик, - и выдернули кабель от первого коммутатора к хранилищу.

Копирование продолжилось. Небольшая пауза - где-то 3 секунды по ощущениям, потом трафик пошёл снова. В журнале событий Windows запись о потере одной iSCSI-сессии и переходе на второй путь. SQL Server, который в этот момент держал соединение с базой на iSCSI-диске, не заметил ничего - транзакция не прервалась.

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

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

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

Время обнаружения сбоя. 3 секунды - это не моментально. Для большинства задач некритично, но если приложение чувствительно к I/O-задержкам, эти секунды могут дать себя знать. Таймауты обнаружения настраиваются, но мы не стали трогать дефолты - это отдельная тема для изучения.

Политика Round Robin и iSCSI. В Fibre Channel Round Robin - нормальная практика, там разные пути физически изолированы. В iSCSI оба пути идут через Ethernet, и при интенсивной нагрузке на двух путях одновременно можно поймать out-of-order пакеты. Пока проблем не наблюдали, но в документации Microsoft есть оговорки. Если будет нестабильность - переключим на Fail Over Only.

Два коммутатора - дополнительные деньги. Небольшие, неуправляемый гигабитный коммутатор стоит недорого, но в смету надо закладывать.

Итог

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

MPIO в составе Windows Server 2003 R2 сделал это реализуемым без покупки стороннего ПО. Схема работает, тест прошёл. Посмотрим, как поведёт себя под реальной длительной нагрузкой - пока инсталляция слишком свежая, чтобы говорить о надёжности всерьёз.