iSCSI вместо Fibre Channel: общее хранилище за человеческие деньги

Клиент поставил задачу коротко: два сервера, одно хранилище, чтобы оба могли работать с одними данными. Задача нормальная - пока не выясняется, что бюджет на оборудование ограничен, а классическое решение через Fibre Channel стоит как ещё пара серверов сверху. HBA-карты, оптические коммутаторы, SFP-модули - всё это складывалось в сумму, которую клиент вежливо, но твёрдо отверг.

Так мы и дошли до iSCSI.

Что такое iSCSI и почему он вдруг появился

iSCSI - это SCSI-протокол поверх обычного TCP/IP. Грубо говоря, берём блочное устройство, заворачиваем его в сетевые пакеты и отдаём по Ethernet. Для сервера это выглядит как обычный локальный диск - он не знает, что под капотом сеть. Протокол существует несколько лет, но именно сейчас цены на гигабитный Ethernet упали до уровня, где это начинает иметь практический смысл для среднего бизнеса.

Схема у нас получилась такая: отдельная машина с дисками поднята как iSCSI-таргет (мы использовали Linux с пакетом iscsitarget), два рабочих сервера - инициаторы, подключаются к таргету и получают блочное устройство. Физически всё это висит на выделенном гигабитном свитче - отдельном от офисной сети, чтобы трафик хранилища не конкурировал с пользовательским.

Как поднимали

Сама настройка iSCSI-таргета на Linux оказалась проще, чем мы ожидали. Файл конфига, описываем LUN, прописываем, каким инициаторам разрешён доступ (по IQN - это такой идентификатор iSCSI-клиента), запускаем демон. На серверах-инициаторах ставим open-iscsi, прописываем адрес таргета, делаем discovery - и вот оно, /dev/sdb появилось из ниоткуда.

Дальше - стандартная разметка и форматирование. Том мы отдали под кластерную файловую систему - без неё два сервера одновременно писать в один раздел не могут, это путь к повреждению данных. Здесь начинается тонкое место: iSCSI даёт блочный доступ, но не решает проблему одновременной записи. Это задача кластерной ФС поверх.

Где получилось хорошо

Стоимость. Мы уложились в стоимость дискового массива плюс три гигабитных NIC и бюджетный свитч. По сравнению с FC-решением - разница в разы.

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

Масштабируемость по дискам. Добавить ещё один LUN или расширить существующий - дело нескольких минут на таргете. Серверам об этом можно сообщить без перезагрузки.

Где упёрлись в ограничения

Главный камень преткновения - сеть. iSCSI живёт в TCP/IP, а TCP/IP несёт накладные расходы. При интенсивных операциях ввода-вывода процессор сервера начинает заметно нагружаться - он же обрабатывает стек. Решается TOE-картами (TCP Offload Engine), которые берут эту работу на себя, но это уже отдельные деньги и не всегда оправданные.

Латентность заметно выше, чем у прямого подключения SAS/SCSI. Для файлового сервера или базы данных с умеренной нагрузкой - приемлемо. Для OLTP с тысячами транзакций в секунду - уже вопрос.

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

Одновременный доступ с нескольких серверов - тема отдельная. iSCSI сам по себе не решает конкуренцию за блоки. Если задача - просто разделить хранилище между двумя серверами, которые пишут в разные директории, то кластерная ФС иногда оверкилл, и проще поднять NFS поверх - но тогда это уже не блочный, а файловый доступ, и производительность другая.

Итог на сейчас

Для конкретной задачи клиента - два сервера, общий том, умеренная нагрузка - iSCSI отработал нормально. Систему подняли, оба сервера видят хранилище, данные консистентны. Клиент доволен, что уложился в бюджет.

Но честный вывод такой: iSCSI хорош там, где Fibre Channel избыточен по деньгам, а NAS достаточен по архитектуре, но нужен именно блочный доступ. Если нагрузка вырастет вдвое - придётся разговаривать о выделенных TOE-картах или пересматривать архитектуру.

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