iSCSI-SAN без Fibre Channel: OpenFiler, гигабит и 400 МБ/с на практике

Разговор начался предсказуемо. Клиент пришёл с задачей: база данных растёт, локальные диски уже не вариант, нужно что-то централизованное. Мы прикинули FC-SAN - примерно так, как это делали для другого клиента в феврале. Прикинули и услышали в ответ характерную паузу. Бюджет на Brocade и HBA-карты не закладывался. Разговор мог бы закончиться на этом, но мы решили посмотреть на iSCSI.

Почему iSCSI стал реальным вариантом

До недавнего времени iSCSI на Windows-клиенте был мероприятием на любителя - инициаторы были либо дорогими аппаратными картами, либо нестабильным软件. Microsoft iSCSI Initiator 2.0, вышедший в 2005 году, изменил расклад: бесплатный, работает поверх обычного сетевого адаптера, ставится на Windows Server 2003 без плясок. Это убрало основной барьер на клиентской стороне.

На стороне хранилища тоже появился нормальный инструмент - OpenFiler. Дистрибутив Linux, заточенный под NAS/SAN: веб-интерфейс для управления, поддержка iSCSI через Linux-SCSI target (tgt), LVM под томами. Не NetApp, конечно, но для задачи клиента - рабочий вариант.

Принципиальное отличие от FC: всё ходит по обычному Ethernet. Никаких HBA, никаких коммутаторов Brocade, никакого специального кабеля. Зато и разделять с рабочим трафиком нельзя - нужна выделенная сеть.

Архитектура стенда

Схема получилась простая. Отдельный сервер под OpenFiler - два SATA-диска в RAID 1 под ОС, четыре диска в RAID 5 под данные. Отдельный гигабитный коммутатор, в который воткнуты только сервер хранилища и серверы-клиенты - никакого другого трафика. Клиенты - два Windows Server 2003, Microsoft iSCSI Initiator 2.0, каждый с выделенным сетевым адаптером для iSCSI-трафика.

[Win SRV 1]---+
              |---[GbE switch (только iSCSI)]---[OpenFiler]
[Win SRV 2]---+

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

Настройка и подводные камни

OpenFiler устанавливается как обычный Linux с графическим инсталлятором, после чего управление идёт через веб-интерфейс на 446 порту. Создать физический том, поверх него - volume group, из неё нарезать LUN под каждый клиент - всё через браузер. Концептуально понятно, если знаком с LVM.

Первый сюрприз пришёл с настройкой доступа. В OpenFiler авторизация iSCSI-инициаторов работает по IQN (iSCSI Qualified Name) - строка вида iqn.1991-05.com.microsoft:hostname. Нужно явно добавить каждый инициатор в список разрешённых для конкретного LUN. Мы поначалу упустили этот шаг и минут двадцать смотрели на то, почему клиент «видит» target, но не может подключиться. Читаем документацию - и сразу находим.

Второй момент - jumbo frames. Теоретически MTU 9000 должен дать прирост на больших блоках. Включили на коммутаторе и на всех интерфейсах - и поймали нестабильность: периодические обрывы сессии. Откатились к стандартному MTU 1500, стабильность вернулась. Возможно, дело в конкретном коммутаторе или в версии драйверов, разбираться пока не стали - задача была запустить, а не оптимизировать до предела.

Третье - тонкая настройка таймаутов на инициаторе. Дефолтные значения Microsoft iSCSI Initiator при кратковременной потере связи с target ведут себя не очень приятно: сессия может «зависнуть» прежде чем переподключиться. Подкрутили LoginTimeout и MaxRequestHoldTime через реестр - стало лучше.

Что получилось в цифрах

Тестировали последовательное чтение большими блоками - это основная нагрузка для базы данных клиента. Результат в районе 115 МБ/с - то есть практически полная полоса гигабитного линка. Для сравнения: тот же тест на локальных SATA-дисках давал около 80-90 МБ/с. Выигрыш не в скорости iSCSI сам по себе, а в том, что RAID 5 из четырёх шпинделей читает параллельно и не является узким местом.

Случайный I/O - другая история. Здесь latency сети ощущается, и результаты скромнее, чем у FC. Для OLAP-нагрузки и последовательного сканирования таблиц - нормально. Для базы с интенсивными случайными операциями мы бы смотрели на FC или на SSD-кеш, но у клиента именно аналитическая нагрузка, так что попали в точку.

Итог

iSCSI на OpenFiler - рабочий вариант для задач, где FC избыточен по цене, а производительности гигабита хватает. Основные условия: выделенная сеть без постороннего трафика, понимание ограничений по случайному I/O, и аккуратная настройка доступа через IQN.

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