FC, iSCSI или SAS: как выбрать интерфейс подключения СХД

Подключать СХД к серверам можно через три принципиально разных интерфейса: Fibre Channel (FC), iSCSI и SAS. У каждого из них своя логика, своя инфраструктура и своя цена входа. При этом характеристики порта — 16 Гбит/с, 25 GbE или 12 Гбит/с — ничего не говорят о реальной производительности под нагрузкой. На неё влияют контроллер СХД, дисковая группа, кэш, настройки путей и конкуренция трафика.

Правильный вопрос не «что быстрее», а «что подходит для моей топологии». Для этого нужно заранее понимать: сколько серверов будет подключено, нужна ли кластерная работа, насколько критична задержка, есть ли выделенная storage-сеть, какое оборудование и компетенции уже есть в команде.

Три архитектуры — одна задача

FC: выделенная сеть хранения

Fibre Channel — это отдельная сеть, исторически созданная именно для хранения данных. Каждый элемент в ней специализирован: FC-адаптеры в серверах, FC-коммутаторы, оптические кабели или DAC, зоны доступа. Storage-трафик физически изолирован от всего остального и не конкурирует с офисной сетью, IP-телефонией, резервным копированием по LAN.

Это главное преимущество FC: предсказуемое поведение при высокой нагрузке. Именно поэтому его выбирают для production-кластеров виртуализации, баз данных, ERP-систем и VDI, где нестабильные задержки недопустимы. Современный стандарт 32GFC широко распространён, доступен 64GFC, а 8-е поколение допускает 128GFC.

Порог входа высокий: нужны FC HBA в каждый сервер, как минимум два FC-коммутатора, SFP-модули, оптика и лицензии на порты. Администратор должен разбираться в зонировании, WWPN-идентификаторах и политиках путей. Но для систем, где простой стоит дороже инфраструктуры, FC оправдан именно зрелостью и управляемостью.

iSCSI: блочное хранилище поверх IP

iSCSI инкапсулирует команды SCSI внутри TCP/IP-пакетов и передаёт их по обычной Ethernet-сети. Главный аргумент в его пользу — доступность: в большинстве инфраструктур уже есть Ethernet-коммутаторы, сетевые карты и кабели. Это снижает стартовые затраты.

Но «работает по Ethernet» не значит «подойдёт любой свободный порт». Для устойчивой работы iSCSI требует выделенной storage-сети: отдельные VLAN или физические коммутаторы, два независимых пути, отдельные сетевые порты и IP-подсети, мониторинг задержек и ошибок. Смешение iSCSI-трафика с пользовательским — самая распространённая ошибка, которая приводит к случайным «зависаниям» виртуальных машин.

При правильном дизайне iSCSI на 10/25 GbE вполне справляется с небольшими и средними кластерами VMware/Hyper-V, backup-инфраструктурой, файловыми сервисами и тестовыми средами.

SAS: прямое подключение без SAN

SAS (Serial Attached SCSI) — это прямое соединение сервера и СХД без промежуточной сети. Нужны только SAS HBA или RAID-контроллер в сервере и внешние mini-SAS HD кабели до портов СХД. Коммутаторы, зоны, отдельные VLAN — ничего из этого не требуется.

SAS удобен, когда сервер и СХД стоят в одной стойке, а число подключаемых хостов невелико. Задержка при прямом подключении низкая, схема простая в диагностике. Современный SAS 4.1 поддерживает скорость 24 Гбит/с на порт.

Ограничения понятны: небольшое расстояние подключения, ограниченное число серверов, меньше гибкости по сравнению с SAN. Технически SAS-коммутаторы существуют, но оборудование редкое и нишевое — в большинстве случаев проще сразу рассматривать iSCSI или FC, если нужен рост.

Сравнительная таблица

Выбор под конкретный сценарий

Один сервер и СХД в одной стойке

Первый кандидат — SAS. Не нужна отдельная сеть хранения, схема простая, задержка низкая. Подходит для файлового сервера, небольшой базы данных, резервного копирования, компактной виртуализации. Важно заранее убедиться, что у СХД есть именно host SAS-порты для подключения сервера, а не только порты расширения для дисковых полок.

2–4 сервера, небольшой кластер

Здесь выбор между iSCSI и FC. iSCSI разумен, если уже есть хорошая 10/25 GbE база, можно выделить отдельную storage-сеть, а команда уверенно администрирует Ethernet. FC оправдан, если задержки критичны, кластер будет расти и есть бюджет на SAN-инфраструктуру.

Кластеры VMware / Hyper-V

Для небольшого кластера из 2–6 хостов iSCSI с изолированной storage-сетью справляется. Для более крупной среды, строгих SLA или высокого числа хостов — FC. SAS возможен только если матрица совместимости СХД, контроллеров и гипервизора это явно подтверждает.

Production-база данных

Для высоконагруженной СУБД обычно выбирают FC — из-за предсказуемости задержки при пиках, а не только из-за скорости. iSCSI также применим, если построена правильная сеть на 25 GbE и выше с изолированными путями. SAS подходит для одиночного сервера с прямым подключением.

Резервное копирование и архив

Для backup важна стабильная пропускная способность в окно резервного копирования, а не минимальная задержка. Подойдут iSCSI на выделенной сети или SAS при близком расположении оборудования. FC актуален, если SAN уже есть.

VDI

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

Типовые ошибки при выборе

iSCSI в общей офисной сети

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

Один путь до СХД

Даже самая надёжная СХД не обеспечит отказоустойчивость, если сервер подключён к ней одним путём. Кабель, порт, HBA, коммутатор — каждый из них одиночная точка отказа. В production планируют минимум два независимых пути.

Покупка СХД без проверки интерфейсов

Одна и та же линейка СХД продаётся с разными контроллерами: FC, iSCSI, SAS или комбо. В коммерческом предложении нужно отдельно проверять тип и количество host-портов, скорость, наличие SFP, совместимость с коммутатором и наличие нужных HBA/NIC в серверах.

Путаница SAS host-портов и портов расширения

SAS-разъёмы на задней панели СХД могут быть предназначены для подключения дисковых полок расширения, а не серверов. Это разные сценарии. Перед покупкой нужно явно уточнить, к каким именно портам можно подключать серверы и сколько хостов поддерживается.

Выбор по скорости порта

32 Гбит FC, 25 GbE iSCSI или 12 Гбит SAS не гарантируют такой скорости на уровне приложения. Ограничением станет дисковая группа, тип RAID, кэш контроллера, очередь запросов, один активный путь или перегруженный коммутатор. Интерфейс важен, но он не исправит слабую архитектуру хранения.

LACP вместо MPIO для iSCSI

Объединение двух портов 10 GbE через LACP не даёт 20 GbE для iSCSI-трафика — только отказоустойчивость. Для масштабирования пропускной способности используется MPIO: каждый путь работает независимо, и суммарная полоса складывается из нескольких активных путей.

Чек-лист перед закупкой

Перед выбором интерфейса и подписанием коммерческого предложения стоит ответить на эти вопросы:

• Сколько серверов подключается сейчас и через 1–2 года?

• Нужна ли кластерная работа (VMware, Hyper-V и др.)?

• Какие интерфейсы поддерживает конкретная модель СХД?

• Есть ли два контроллера у СХД?

• Сколько host-портов на каждом контроллере?

• Есть ли HBA или сетевые карты нужного типа в серверах?

• Нужны ли FC-коммутаторы или отдельные Ethernet-коммутаторы для iSCSI?

• Какие SFP, DAC или кабели нужны?

• Есть ли лицензии на порты и функции СХД?

• Поддерживает ли ОС / гипервизор выбранную схему?

• Настроено ли многопутевое подключение (MPIO)?

• Проверена ли матрица совместимости производителя?

• Есть ли мониторинг задержек, ошибок и состояния путей?

Вывод

Для компактной инфраструктуры с одним-двумя серверами в одной стойке SAS — самый рациональный и простой вариант. Не нужна SAN, не нужны коммутаторы, схема понятна в эксплуатации.

Для небольшого и среднего кластера iSCSI даёт хорошую гибкость при умеренных затратах — но только при условии выделенной storage-сети и нескольких независимых путей. Это не «дешёвый FC», а полноценный подход со своими требованиями.

Для критичных систем, крупных кластеров, production-баз данных и VDI лучше выбирать FC. Он дороже на входе и сложнее в администрировании, но даёт зрелую и предсказуемую модель выделенной сети хранения.