Устройство SAN: Fibre Channel, iSCSI и блочный доступ к данным для виртуализации и кластеров

Что такое SAN и зачем он нужен

SAN (Storage Area Network) - выделенная сеть, которая отдаёт серверам блочные устройства. Хост видит удалённый LUN как локальный диск: /dev/sdb в Linux, диск 2 в «Управлении дисками» Windows, отдельное устройство в списке датасторов гипервизора. SCSI-команды при этом идут по внешнему транспорту, Fibre Channel или iSCSI.

Для кластеров эта модель принципиальна. NAS отдаёт файлы по NFS или SMB, и согласованность доступа обеспечивает сам сервер хранения. SAN отдаёт блоки, а за согласованность отвечает файловая система на хостах: VMFS, CSV, GFS2, OCFS2. Хост получает прямой доступ к блокам, строит несколько независимых путей до одного LUN и видит задержку ввода-вывода без прослойки сетевой файловой системы.

Распространённая ошибка - считать SAN дисковым массивом. SAN - это сеть передачи блочных команд SCSI. Массив с контроллерами, дисками и кэшем - лишь один из её участников, наряду с HBA, коммутаторами и кабельной системой. Массив, подключённый напрямую к серверу одним кабелем, образует DAS, а не SAN. Сравнение подходов по протоколам, латентности и стоимости владения разобрано в материале NAS или SAN: выбор сетевого хранилища для инфраструктуры.

SAN, NAS и DAS: в чём разница

Три подхода отличаются моделью доступа и тем, что именно видит сервер.

SAN и NAS не конкурируют насмерть: в одной инфраструктуре блочный LUN под виртуальные машины и NFS-экспорт под образы ISO дополняют друг друга. Разбор архитектур DAS, NAS, SAN и HCI с матрицей выбора есть в статье DAS, NAS, SAN и HCI: как выбрать систему хранения.

Ключевые компоненты SAN

Минимальный набор оборудования и сущностей, которые придётся настраивать:

• HBA (Host Bus Adapter) - адаптер с собственным WWN в FC-сетях. В iSCSI его роль берёт сетевой интерфейс плюс программный или аппаратный iSCSI-инициатор.
• Коммутаторы - FC-коммутаторы для фабрики; для iSCSI подходят Ethernet-коммутаторы с достаточной пропускной способностью и буферами под всплески.
• Кабели и оптика - оптика с коротковолновыми и длинноволновыми модулями для дистанций от стойки до кампуса, медные DAC и twinax для коротких линков внутри стойки.
• СХД - контроллеры, накопители, кэш, порты подключения, снапшоты, тонкое выделение, репликация.
• LUN - логическое блочное устройство, которое массив показывает хосту.
• Инициатор и таргет - инициатор отправляет SCSI-команды (сервер), таргет их обслуживает (порт массива).

Адресация в FC строится на WWN: 64-битный идентификатор, где WWNN задаёт узел, а WWPN - конкретный порт. В iSCSI аналогичную роль выполняет IQN. Для multipath важны оба адреса: именно по WWPN или IQN настраивают зоны и маскирование.

Пример схемы для кластера: сервер с двумя двухпортовыми HBA, каждый адаптер подключён к своему FC-коммутатору, массив подключён портами к обоим. Хост получает четыре независимых пути к LUN, и multipath переживает отказ коммутатора, HBA или одного контроллера СХД.

Fibre Channel: архитектура фабрики и зонирование

Fibre Channel - семейство стандартов ANSI T11 для передачи SCSI-команд по выделенной сети. Данные идут кадрами фиксированного размера с полезной нагрузкой 2112 байт, поток управляется кредитами буфер-буфер, поэтому потери кадров в норме не возникают даже при полной загрузке. Поколения 8, 16, 32 и 64 Гбит/с на порт, обратная совместимость обычно сохраняется на два поколения назад.

Ориентиры полезной полосы одного порта: 8 Гбит/с - около 800 МБ/с, 16 Гбит/с - около 1600 МБ/с, 32 Гбит/с - около 3200 МБ/с. Это теоретические значения из спецификаций, кодирование 64b/66b и служебные кадры забирают часть полосы; реальную скорость конкретной связки контроллер-коммутатор-сервер измеряют на стенде.

Порты фабрики имеют роли: N_Port на узле, F_Port на коммутаторе, E_Port для межкоммутаторных линков (ISL), G_Port подбирает роль автоматически при подключении.

Топологии Fibre Channel

Исторически сложились три варианта соединения.

• Point-to-point - HBA соединён напрямую с портом массива. Коммутатор не нужен, схема годится для стенда или одиночного сервера, но путей для multipath почти нет и масштабирования тоже.
• Arbitrated loop (FC-AL) - кольцо до 126 устройств. Каждый узел делит полосу кольца, добавление устройства или его отказ влияют на остальных. Топология устарела и в новых проектах не применяется.
• Switched fabric - сеть коммутаторов. Современный вариант для ЦОД: маршрутизация FSPF, линки ISL между коммутаторами, изоляция трафика зонами, масштабирование до сотен портов.

Для отказоустойчивой конфигурации строят две независимые фабрики, fabric A и fabric B, которые соединяются только через хост и массив. ISL между этими фабриками не делают: он превращает две независимые сети в одну с общим доменом отказа. Более простой вариант - одна фабрика из двух коммутаторов с ISL; он дешевле, но отказ коммутатора или линка затрагивает часть путей сразу.

Зонирование и маскирование LUN

Зонирование выполняется на коммутаторе и определяет, какие порты видят друг друга. Soft zoning фильтрует ответы службы имён по WWN: удобно, не требует строгой привязки к порту, но не защищает от подмены адреса. Hard zoning задаётся номерами портов физического коммутатора и проверяется на уровне ASIC, поэтому обойти его подменой WWN нельзя. На практике включают оба механизма.

Правило, которое снижает число сбоев: одна зона - один порт инициатора и один порт таргета (single-initiator, single-target). Тогда изменения в конфигурации одного сервера не задевают остальные, а уведомления RSCN (registered state change notification) не рассылаются всем узлам фабрики при каждом подключении.

Маскирование LUN выполняется на массиве и определяет, какие LUN получит конкретный инициатор по своему WWPN. Механизмы дополняют друг друга: зона открывает хосту доступ к порту СХД, маскирование решает, какие именно LUN он увидит. Пошаговый порядок этих операций для FC и iSCSI с примерами подключения Linux, Windows и гипервизоров описан в руководстве SAN в корпоративной IT-среде: настройка iSCSI и Fibre Channel.

Две частые ошибки при зонировании и маскировании. Первая: новый сервер подключили в готовую широкую зону и не настроили маскирование, и хост увидел все LUN этой зоны, включая диски работающего кластера. Вторая: один и тот же LUN ID отдан разным инициаторам через разные порты массива без учёта маскирования, и ОС получает два разных устройства с одинаковым идентификатором, а multipath принимает их за пути к одному.

iSCSI: принцип работы и отличия от Fibre Channel

iSCSI передаёт SCSI-команды внутри TCP-сегментов, поэтому ему подходит обычная IP-сеть: те же коммутаторы, те же навыки администрирования, та же система мониторинга.

Как iSCSI инкапсулирует SCSI в TCP/IP

Стек выглядит так: SCSI CDB упаковывается в iSCSI PDU, тот попадает в TCP-сегмент, затем в IP-пакет и Ethernet-кадр. На принимающей стороне разбор идёт в обратном порядке, и массив получает обычную SCSI-команду чтения или записи.

Узлы именуются IQN, например iqn.2026-09.ru.example:storage01. Имя уникально для каждого участника: таргет - сторона хранения, инициатор - сторона сервера. Discovery работает по SendTargets: инициатор обращается к порталу (IP и порт, по умолчанию 3260) и получает список доступных таргетов.

Аутентификация выполняется через CHAP, односторонний или взаимный. Без неё любой узел, видящий портал, может попытаться подключиться к таргету. Реализаций инициатора несколько: программный (open-iscsi в Linux, iSCSI Initiator в Windows, программный адаптер в VMware), аппаратный iSCSI HBA с разгрузкой TCP и режим TOE на сетевых картах. Программный вариант дешевле и на современных процессорах держит полосу 10GbE и 25GbE, аппаратный снижает нагрузку на CPU и задержку.

Настройка iSCSI: ключевые параметры

• MTU 9000 (jumbo frames) на всём маршруте: NIC сервера, порты коммутатора, интерфейсы массива, VLAN-интерфейсы. Несовпадение - самая частая причина падения скорости: сервер отправляет кадры 9000, коммутатор их фрагментирует или дропает, и полоса падает в разы.
• Отдельный VLAN и отдельные физические порты под iSCSI. Трафик резервного копирования, репликации и виртуальных машин рядом с iSCSI даёт всплески задержки.
• CHAP на инициаторе и таргете, с разными паролями для разных узлов.
• MPIO вместо LACP. LACP распределяет по линкам отдельные TCP-потоки, но одна сессия iSCSI обычно идёт по одному линку. Multipath с несколькими порталами и подсетями даёт и отказоустойчивость, и суммирование полосы между сессиями.
• Настройки NIC: отключить энергосбережение и EEE, проверить flow control и размеры ring buffer и очередей.
• Проверка после настройки: список сессий (iscsiadm -m session в Linux), состояние путей (multipath -ll), замер задержки и IOPS на профиле приложения в течение хотя бы 30 минут.

Отличия от FC сводятся к транспорту. iSCSI не требует HBA и отдельной коммутаторной инфраструктуры, а его полоса на 25GbE даёт порядка 2800 МБ/с, то есть больше, чем полезная пропускная способность одного порта FC 16 Гбит/с. Плата за это - зависимость от IP-сети: перегрузка, потери и ретрансмиссии TCP растят задержку, а jumbo frames, QoS и изоляцию VLAN настраивают вручную. Подробное сравнение блочных и файловых протоколов с параметрами target и initiator собрано в статье Протоколы доступа к СХД: iSCSI, NFS, SMB и Fibre Channel.

Блочный и файловый доступ: когда что использовать

Блочный доступ отдаёт LUN: хост видит блочное устройство, сам создаёт на нём файловую систему или передаёт его приложению напрямую. Файловый доступ отдаёт пространство имён: клиент монтирует NFS или SMB, работает с файлами, а размещением блоков и блокировками занимается сервер хранения.

Когда блочный доступ критичен

• Кластеры виртуализации. VMFS в VMware, CSV в Hyper-V, общее хранилище в Proxmox и KVM требуют блочного устройства с поддержкой SCSI-3 persistent reservations: без резервирований невозможны кворум, fencing и корректный live migration.
• Базы данных с прямым доступом к диску. Oracle, SQL Server и PostgreSQL на кластере получают предсказуемую задержку, собственный кэш и настройки записи, которых файловый протокол не даёт.
• Кластерные файловые системы: GFS2, OCFS2, ASM в Oracle работают поверх блочных устройств и сами решают, какой узел владеет областью диска.
• Загрузка с SAN. Сервер без локальных дисков грузится с LUN, что упрощает замену железа и обслуживание.
• Приложения, требующие raw-устройства или собственного управления диском.

Файловый доступ выигрывает там, где нужны общие папки с правами POSIX или NTFS, хранилище шаблонов, бэкапы и тома Kubernetes через NFS CSI. Рабочее сочетание в одной инфраструктуре: LUN по FC под датастор виртуальных машин и NFS-экспорт того же массива под ISO и резервные копии. Подробнее о том, как разные модели хранения уживаются в одном контуре, читайте в обзоре Архитектуры хранилищ данных: DAS, NAS, SAN и HCI.

FC или iSCSI: критерии выбора для виртуализации и кластеров

Оба протокола несут одни и те же SCSI-команды, и для гипервизора или кластерной файловой системы они взаимозаменяемы. Разница в транспорте, стоимости, предсказуемости задержки и требованиях к персоналу.

Сравнение производительности и стоимости

Критерии, по которым решение принимают на практике:

• Требуется задержка в сотни микросекунд на транзакционной СУБД - смотреть в сторону FC или NVMe-oF, но сначала измерить, нужна ли эта задержка самой задаче.
• Парк из нескольких десятков виртуальных машин с нагрузкой до десятков тысяч IOPS - iSCSI на 10 или 25GbE с MPIO закрывает задачу.
• FC-фабрика уже построена и обслуживается - продлевать её обычно дешевле, чем строить параллельную сеть.
• Много узлов и требуется дешёвое масштабирование по числу портов - iSCSI выигрывает по стоимости подключения.
• Нет времени на новую инфраструктуру - iSCSI запускается быстрее, но выделенный VLAN, jumbo frames и multipath обязательны с первого дня.

Пример: кластер Proxmox из трёх узлов с общим LUN по iSCSI 25GbE и multipath закрывает потребности в live migration и HA при типовой нагрузке виртуальных машин. Тот же кластер на FC 16 Гбит/с даст меньшую задержку, но потребует двух коммутаторов, HBA, оптики и отдельного обучения команды. Решение стоит принимать по результатам нагрузочного теста на собственном профиле ввода-вывода, а не по табличным максимумам.

Типичные ошибки при построении SAN

1. Один путь до LUN. Multipath не настроен, и отказ HBA, порта или коммутатора останавливает ввод-вывод. Проверка: multipath -ll показывает не менее двух активных путей, а тест с отключением линка не приводит к ошибкам ввода-вывода.
2. Зона «на всё». Одна широкая зона со всеми хостами и портами массива даёт лишние RSCN при каждом изменении и риск, что новый сервер увидит чужие LUN.
3. Нет маскирования LUN. Хост получает доступ к дискам другого кластера и может перезаписать данные.
4. Несовпадение MTU. Jumbo frames на сервере и 1500 на коммутаторе приводят к фрагментации или дропам и падению полосы.
5. Отсутствие CHAP или общий пароль на все узлы.
6. Перегруженный iSCSI VLAN: бэкапы, репликация и трафик виртуальных машин идут по той же сети, что и хранилище.
7. Несогласованные очереди. Глубина очереди на HBA или NIC не совпадает с возможностями массива, при переполнении растёт задержка, и гипервизор помечает датастор как недоступный.
8. Рассинхрон адресов: WWPN в зонах и маскировании не совпадают с реальными портами после замены HBA или сетевой карты.
9. Нет мониторинга. Без контроля задержки, ошибок CRC и ретрансмиссий деградация обнаруживается по жалобам пользователей, а не по метрикам.

Чек-лист перед переводом в продуктив: зоны ограничены парой инициатор-таргет; маскирование привязано к конкретным WWPN или IQN; на хосте видны все ожидаемые пути в состоянии active/ready; MTU согласован на всём маршруте; CHAP включён; задержка и IOPS сняты под нагрузкой профиля приложения; зоны, маскирование и IP-схема задокументированы; проверен отказ коммутатора, одного пути и одного контроллера массива.

Практические рекомендации по построению SAN

Для Fibre Channel:

• Строить две независимые фабрики вместо одной с ISL, если требуется отказоустойчивость уровня ЦОД.
• Использовать зоны single-initiator, single-target и включать hard zoning там, где коммутаторы это поддерживают.
• Заводить в маскирование конкретные WWPN, а не группы, и вести таблицу соответствия LUN, WWPN и серверов.
• Ставить двухпортовые HBA и разводить порты по разным коммутаторам, чтобы отказ адаптера не отключал хост от хранилища.
• Оставлять свободные порты и запас по кредитам буфер-буфер под рост числа узлов.

Для iSCSI:

• Выделять отдельный VLAN и, если возможно, отдельные физические интерфейсы под трафик хранилища.
• Включать jumbo frames сквозным образом и проверять MTU утилитой ping с запретом фрагментации на всём маршруте, включая порталы массива.
• Настраивать MPIO с несколькими порталами и подсетями, а не LACP, если нужны одновременно отказоустойчивость и суммирование полосы.
• Включать CHAP и не переиспользовать пароли между узлами.
• Следить за задержкой, числом ретрансмиссий и ошибок интерфейсов; порог для тревоги выбирать по результатам стенда, а не по общим рекомендациям.

Для обоих протоколов: тестировать отказоустойчивость до продуктивной нагрузки (вынуть линк, выключить порт коммутатора, перевести контроллер массива в режим обслуживания), фиксировать зоны, маскирование и топологию в документации и повторять нагрузочный тест после каждого изменения прошивки коммутатора, HBA или массива.

Начните с профиля нагрузки: снимите на существующем хранилище средний и пиковый IOPS, размер блока, соотношение чтения и записи и требования приложения к задержке. Эти четыре цифры определят, хватит ли iSCSI на 25GbE с multipath или нужен FC, и уберегут от покупки полосы, которую нагрузка никогда не выберет.