Если СХД подключается к одному-двум серверам в той же стойке, чаще всего стоит начать с SAS: это простая и понятная схема без отдельной SAN-инфраструктуры. Для небольшого или среднего кластера обычно рациональнее iSCSI, но только при выделенной storage-сети и многопутевом подключении. Для критичных баз данных, крупной виртуализации, VDI и сред, где важны предсказуемые задержки и отказоустойчивость, лучше рассматривать FC.
Выбирать интерфейс подключения СХД только по скорости порта — ошибка. На практике важнее другое:
- сколько серверов будет подключено сейчас и через год;
- нужна ли кластерная работа;
- насколько критичны задержки;
- есть ли отдельная сеть хранения;
- какие порты уже есть у СХД;
- есть ли HBA, сетевые карты, SFP, кабели и коммутаторы;
- кто будет администрировать эту схему после внедрения.
Поэтому FC, iSCSI и SAS стоит сравнивать не как «быстрее или медленнее», а как три разные архитектуры подключения.
Что именно мы сравниваем
FC, iSCSI и SAS могут решать похожую задачу — дать серверу блочный доступ к хранилищу. Но технически это разные подходы.
FC: выделенная сеть хранения
FC, или Fibre Channel, — это отдельная сеть, как правило используемая для хранения данных. Обычно в такой схеме используются:
- FC-адаптеры в серверах;
- FC-коммутаторы;
- SFP-модули;
- оптические кабели или DAC;
- настройка зон доступа;
- многопутевое подключение.
FC часто выбирают для критичных систем, где важны стабильные задержки и предсказуемое поведение под нагрузкой. Такой интерфейс хорошо подходит для крупных кластеров виртуализации, баз данных, ERP-систем, VDI и другой инфраструктуры, где простой стоит дорого.
Но у FC выше порог входа. Нужно покупать не только СХД, но и адаптеры, коммутаторы, модули, кабели, лицензии портов. Кроме того, администратор должен понимать, как работает SAN: зоны, WWPN-идентификаторы, две независимые фабрики, политика путей на сервере.
iSCSI: блочное хранилище по IP-сети
iSCSI передает команды SCSI поверх TCP/IP. Это описано в стандарте IETF RFC 7143. Проще говоря, сервер обращается к блочному хранилищу через Ethernet-сеть.
Главное преимущество iSCSI — доступность. Часто в инфраструктуре уже есть Ethernet-коммутаторы, сетевые карты, SFP или DAC-кабели, при этом возможна и маршрутизация трафика. Поэтому iSCSI может быть дешевле на старте, чем FC.
Но из этого не следует, что iSCSI можно подключить «в любой свободный порт офисного коммутатора». Конечно, iSCSI будет работать и на обычной гигабитной сети, но стабильной и производительной эта работа не будет. Для стабильности нужна отдельная storage-сеть:
- отдельные VLAN, а лучше отдельные физические коммутаторы;
- минимум два независимых пути;
- отдельные порты на сервере;
- отдельные IP-подсети;
- контроль потерь, ошибок портов и задержек;
- согласованный MTU на всем пути, если включаются jumbo frames.
iSCSI хорошо подходит для небольших и средних кластеров VMware/Hyper-V, backup, файловых сервисов, тестовых сред и универсальной инфраструктуры. Но его качество напрямую зависит от сетевого дизайна.
SAS: прямое подключение без SAN
SAS, или Serial Attached SCSI, чаще используется для прямого подключения сервера к СХД или дисковой полке. IBM в своем обзоре описывает SAS как последовательный интерфейс и набор протоколов для обмена данными между устройствами хранения.
В типичной схеме нужны:
- SAS HBA или RAID-контроллер в сервере;
- внешние mini-SAS или mini-SAS HD кабели;
- СХД с host SAS-портами;
- корректная схема подключения к одному или двум контроллерам.
SAS удобен, когда СХД стоит рядом с сервером, а подключить нужно один сервер или небольшую пару серверов. В такой схеме не нужны FC-коммутаторы и отдельная Ethernet-сеть хранения. Минусы тоже понятны: меньше гибкости, ограничение по расстоянию, ограничение по числу подключаемых серверов. Стоит отметить, что на SAS можно строить и сеть хранения, есть специальные SAS-коммутаторы, но оборудование это редкое и специфическое, и идти в эту историю в большинстве случаев не стоит.
Как выбрать интерфейс под свою среду
Начинать лучше не с вопроса «какой интерфейс быстрее», а с топологии.
Один сервер и СХД в той же стойке
В первую очередь стоит рассмотреть SAS.
Он подходит для:
- файлового сервера;
- небольшой базы данных;
- сервера резервного копирования;
- компактной виртуализации;
- прямого подключения дисковой полки;
- небольшой инфраструктуры без отдельной SAN.
Перед покупкой важно проверить, что у СХД есть именно host SAS-порты для подключения сервера. SAS-разъемы на задней панели могут быть предназначены для подключения полок расширения, а не серверов. Это разные сценарии.
2–4 сервера в небольшом кластере
Здесь чаще всего выбор идет между iSCSI и FC.
iSCSI подойдет, если:
- уже есть 10/25 GbE-инфраструктура;
- можно выделить отдельную storage-сеть;
- нагрузка умеренная;
- команда умеет администрировать Ethernet;
- бюджет ограничен.
FC стоит рассматривать, если:
- задержки критичны;
- простой инфраструктуры дорогой;
- кластер будет расти;
- есть бюджет на SAN;
- в компании уже есть опыт работы с FC.
SAS тоже возможен, но только если конкретная СХД и серверы поддерживают такую схему подключения. Для будущего роста он менее удобен.
VMware, Hyper-V и другие кластеры виртуализации
Для виртуализации важны не только скорость, но и стабильность доступа к LUN, поддержка многопутевого подключения (MPIO), совместимость с гипервизором и поведение при отказе пути.
В документации VMware by Broadcom по FC SAN отдельно рассматриваются практики работы ESXi с Fibre Channel и рекомендации по подключению к SAN.
Для небольшого кластера на 2–6 хостов часто достаточно iSCSI, если storage-трафик изолирован. Для более критичной виртуализации, большого числа хостов и строгих SLA чаще выбирают FC.
SAS в кластере возможен не всегда. Его нужно проверять по матрице совместимости СХД, контроллеров, серверов и гипервизора.
База данных с критичной задержкой
Для production-базы с высокой нагрузкой чаще выбирают FC. Причина не только в скорости, а в предсказуемости поведения при пиковых нагрузках.
Но это не означает, что iSCSI нельзя использовать для баз данных. Если сеть построена правильно, используется 25 GbE или выше, настроены отдельные пути и нет конкуренции с пользовательским трафиком, iSCSI может быть рабочим вариантом.
SAS хорош для базы на одном сервере, если СХД подключается напрямую и не требуется масштабирование на много хостов.
Backup, архив и файловые сервисы
Для резервного копирования часто важнее не минимальная задержка, а стабильная пропускная способность и окно бэкапа.
Обычно достаточно:
- iSCSI — если есть выделенная сеть и нужно гибкое подключение;
- SAS — если backup-сервер и СХД стоят рядом;
- FC — если SAN уже есть или backup должен работать через существующую FC-инфраструктуру.
Здесь важно не переоценивать роль интерфейса. Медленный пул дисков, дедупликация, слабый контроллер или перегруженная сеть могут ограничить скорость сильнее, чем сам тип подключения.
VDI и рабочие места
В VDI опасны пиковые нагрузки: массовый вход пользователей утром, одновременная загрузка рабочих столов, обновления, антивирусные проверки.
Для небольшой VDI-среды можно использовать iSCSI на выделенной сети. Для крупной VDI-инфраструктуры или строгих требований к задержкам лучше рассматривать FC. SAS может подойти для компактной инсталляции, но быстро упирается в ограничения по росту.
Изображение HPE MSA 2060/2050.
Источник изображения: hpe.com
Сравнение FC, iSCSI и SAS
| Критерий | FC | iSCSI | SAS |
|---|---|---|---|
| Тип подключения | Выделенная сеть хранения | IP-сеть Ethernet | Прямое подключение |
| Типичные задачи | Критичные БД, VMware/Hyper-V, VDI, крупные кластеры | Небольшие и средние кластеры, backup, файловые сервисы | Один сервер, пара серверов, DAS, компактная инфраструктура |
| Задержка | Обычно самая предсказуемая | Зависит от сети и нагрузки | Низкая при прямом подключении |
| Стоимость входа | Высокая | Средняя или низкая, если Ethernet уже есть | Низкая или средняя при малом числе серверов |
| Дальность подключения | Хорошая, особенно с оптикой | Хорошая, зависит от IP-сети | Обычно в пределах стойки или ряда |
| Масштабирование | Хорошее для множества хостов | Хорошее при грамотной сети | Ограничено, требует специфического оборудования |
| Отказоустойчивость | Через две SAN-фабрики, HBA и многопутевое подключение | Через две сети, два коммутатора, NIC и многопутевое подключение | Через два контроллера и два пути, если поддерживается |
| Оборудование | FC HBA, FC-коммутаторы, SFP, оптика | Ethernet NIC, коммутаторы, SFP/DAC/RJ-45 | SAS HBA или RAID-контроллер, mini-SAS кабели |
| Скорость | Самый современный досупный стандарт 8 поколения 128GFC (128 GbE), ожидается 256GFC. Чаще всего встречатся 16 и 32 GbE | ограничена Ethernet-сетями, 40, 100 и больше GbE в самых современных сетях). чаще всего встречается 10 и 25 GbE | современный стандарт SAS 4.1 поддерживает 24GbE+ |
| Сложность администрирования | Выше | Средняя | Ниже, но важна совместимость |
| Главный риск | Недооценить стоимость и сложность | Пустить storage-трафик в общую сеть | Ожидать масштабируемость как у SAN |
Скорость порта не равна скорости приложения. На реальную производительность влияют контроллеры СХД, дисковая группа, кэш, тип RAID, глубина очереди, настройки ОС, политика путей и конкуренция с другим трафиком.
Например, iSCSI на 25 GbE может работать лучше плохо спроектированной FC-сети. А SAS может быть рациональнее FC, если речь идет об одном сервере и СХД в той же стойке.
Практические схемы подключения
Один путь до СХД
Схема выглядит просто:
Сервер → один кабель или один коммутатор → один порт СХД
Для тестовой среды такая схема допустима. Для production — почти всегда нет.
Проблема в том, что любой элемент становится единой точкой отказа:
- кабель;
- порт сервера;
- HBA или сетевая карта;
- коммутатор;
- порт СХД;
- контроллер СХД.
Даже дорогая СХД не даст отказоустойчивость, если сервер подключен к ней одним путем.
FC с двумя независимыми фабриками
Более правильная схема для FC:
Сервер, HBA 1 → FC-коммутатор A → контроллер СХД A
Сервер, HBA 2 → FC-коммутатор B → контроллер СХД B
В такой архитектуре важно:
- не объединять две фабрики так, чтобы отказ одного элемента затронул обе;
- настроить зоны доступа;
- проверить видимость LUN с каждого пути;
- включить многопутевое подключение на сервере;
- проверить политику выбора пути в ОС или гипервизоре;
- задокументировать, какой порт куда подключен.
Такой подход сложнее, чем один кабель, но именно он дает смысл FC в критичной инфраструктуре.
iSCSI на отдельной storage-сети
Правильная схема для iSCSI обычно выглядит так:
Сервер, NIC 1 → iSCSI-коммутатор A или VLAN A → порт СХД A
Сервер, NIC 2 → iSCSI-коммутатор B или VLAN B → порт СХД B
Для iSCSI особенно важно не смешивать трафик хранения с обычной офисной сетью. Microsoft в материалах по диагностике iSCSI отдельно рассматривает сетевые причины проблем подключения и нестабильности: iSCSI Storage Connectivity Troubleshooting Guidance.
На практике для iSCSI стоит заранее выделить:
- отдельные VLAN или физические коммутаторы;
- отдельные IP-подсети;
- отдельные сетевые порты на сервере;
- два независимых пути;
- мониторинг ошибок портов, потерь и задержек;
- понятные правила изменения MTU.
Jumbo frames можно включать только тогда, когда они одинаково настроены на всем пути: сервер, коммутатор, порт СХД. Частичная настройка часто дает больше проблем, чем пользы.
SAS direct-attached
Схема SAS обычно проще:
Сервер, SAS HBA → mini-SAS HD кабель → контроллер СХД A
Сервер, второй порт SAS HBA → mini-SAS HD кабель → контроллер СХД B
Такое подключение удобно, когда сервер и СХД находятся рядом. Не нужны коммутаторы, не нужно проектировать отдельную сеть хранения. Но важно заранее понять, сколько серверов можно подключить к конкретной СХД и поддерживается ли отказоустойчивый вариант с двумя контроллерами.
В каталоге СХД можно встретить разные варианты одной линейки с разными интерфейсами. Например, для сравнения логики выбора полезно смотреть отдельно модели с FC/iSCSI и SAS: СХД HPE MSA 2050 FC/iSCSI 24SFF и СХД HPE MSA 2050 HD-SAS 24SFF.
Когда выбирать FC
FC HBA / Fibre Channel адаптер.
Источник изображения: официальная документация Oracle
FC стоит выбирать, когда инфраструктура критична и важно снизить число случайных факторов в сети хранения.
Подходящие сценарии:
- production-кластер VMware или Hyper-V;
- базы данных с высокой нагрузкой;
- ERP, учетные и финансовые системы;
- VDI;
- высоконагруженные файловые сервисы;
- инфраструктура с большим числом серверов;
- среда, где FC уже используется и поддерживается командой.
FC хорош тем, что storage-трафик уже физически отделен от обычной Ethernet-сети. Он не конкурирует с пользовательским трафиком, офисными сервисами, резервным копированием по LAN или другими приложениями.
Но вместе с этим появляются расходы:
- FC HBA в каждый сервер;
- как минимум два FC-коммутатора;
- SFP-модули;
- оптические кабели;
- лицензии портов;
- запасные модули и кабели;
- время на настройку зон и путей.
FC оправдан не потому, что он «дороже», а потому что он дает зрелую и предсказуемую модель SAN для систем, где простой и нестабильные задержки стоят дороже оборудования.
Когда выбирать iSCSI
iSCSI стоит выбирать, когда нужна гибкая и сравнительно доступная схема подключения СХД, а в инфраструктуре уже есть хорошая Ethernet-база.
Он подходит для:
- небольших и средних кластеров виртуализации;
- backup-инфраструктуры;
- файловых сервисов;
- тестовых и dev-сред;
- небольших баз данных;
- универсальных серверных задач;
- компаний без отдельной FC-компетенции.
Перед внедрением нужно проверить, что iSCSI будет жить не в общей офисной сети, а в отдельной storage-среде.
Минимальный набор условий:
- 10 GbE как минимально-разумный базовый уровень для современных задач;
- 25 GbE или выше для более плотных нагрузок;
- два независимых пути;
- отдельные VLAN или отдельные коммутаторы;
- отдельные NIC-порты;
- включенное многопутевое подключение;
- мониторинг задержек и ошибок;
- понятная схема IP-адресации.
Главный риск iSCSI — не сам протокол, а плохая сеть. Если storage-трафик идет через общий коммутатор вместе с пользователями, камерами, телефонией, Wi-Fi и файловыми копированиями, задержки будут случайными. На уровне виртуальных машин это может выглядеть как «подвисания», хотя диски и СХД исправны.
Когда выбирать SAS
SAS стоит выбирать для компактных схем, где СХД подключается напрямую к серверу или небольшой паре серверов.
Хорошие сценарии:
- один физический сервер;
- небольшая виртуализация;
- файловый сервер;
- backup-сервер;
- прямое подключение дисковой полки;
- инфраструктура в одной стойке;
- ограниченный бюджет без задачи строить SAN.
Плюсы SAS понятны:
- меньше компонентов;
- нет отдельной SAN;
- низкая задержка;
- проще схема подключения;
- проще диагностика физического пути.
Но до покупки нужно проверить несколько вещей:
- есть ли у СХД host SAS-порты;
- сколько серверов можно подключить;
- поддерживается ли подключение к двум контроллерам;
- какие именно кабели нужны;
- какой тип разъемов используется;
- какая допустимая длина кабеля;
- нужен ли HBA или RAID-контроллер;
- поддерживает ли ОС или гипервизор выбранную схему;
- можно ли расширить конфигурацию позже.
SAS — удачный выбор для прямого подключения, но он не заменяет SAN, если через год нужно подключить десять серверов, разнести их по разным стойкам и гибко распределять тома между хостами.
Выбор по типу нагрузки
| Сценарий | Что выбрать в первую очередь | Альтернатива | На что обратить внимание |
|---|---|---|---|
| Один сервер и СХД рядом | SAS | iSCSI | Проверить host SAS-порты и кабели |
| 2–4 сервера, небольшой кластер | iSCSI 10/25 GbE | SAS или FC | Выделенная storage-сеть и многопутевое подключение |
| Production VMware/Hyper-V | FC или iSCSI | SAS в ограниченных схемах | Совместимость, политика путей, два контроллера |
| База данных с критичной задержкой | FC | SAS для одного сервера, iSCSI 25 GbE | Очереди, кэш, RAID, стабильность задержек |
| Backup и архив | iSCSI или SAS | FC, если SAN уже есть | Окно резервного копирования и скорость пула |
| VDI | FC или iSCSI 25 GbE | SAS для компактной среды | Пики входа пользователей и массовая загрузка рабочих столов |
| Файловый сервер | iSCSI или SAS | FC для крупной среды | Дисковая группа, кэш, сеть, рост нагрузки |
| Рост до многих серверов | FC или iSCSI | — | SAS быстро упрется в топологию |
Если инфраструктура закупается с нуля, стоит сравнивать не только цену самой СХД, но и полный комплект подключения. В каталоге систем хранения данных полезно смотреть не только форм-фактор и емкость, но и интерфейсы контроллеров, комплектацию, наличие кабелей, тип портов и возможность расширения.
Скрытая стоимость подключения
У интерфейса есть не только техническая, но и финансовая сторона. Иногда решение кажется дешевым только до момента закупки кабелей, модулей и лицензий.
Что считать для FC
В бюджет нужно заложить:
- FC HBA на каждый сервер;
- два FC-коммутатора;
- SFP-модули;
- оптические кабели;
- лицензии портов;
- запасные SFP;
- запасные кабели;
- работы по настройке зон;
- проверку совместимости;
- настройку многопутевого подключения.
FC редко оказывается самым дешевым на старте, но может быть выгоднее в критичной среде, где цена простоя выше стоимости инфраструктуры.
Что считать для iSCSI
Для iSCSI нужно учитывать:
- сетевые карты 10/25 GbE;
- коммутаторы с достаточной пропускной способностью;
- SFP+, SFP28 или DAC;
- отдельные VLAN или физические коммутаторы;
- резервирование путей;
- время на настройку MPIO;
- мониторинг storage-сети;
- возможное обновление сетевой инфраструктуры.
Если iSCSI строится на слабых офисных коммутаторах, экономия быстро превращается в нестабильность.
Что считать для SAS
Для SAS важно не забыть:
- SAS HBA или RAID-контроллер;
- внешние mini-SAS кабели нужного типа;
- достаточное число портов на СХД;
- возможность подключения к двум контроллерам;
- ограничение по длине кабелей;
- будущий рост;
- совместимость с сервером и ОС.
SAS может быть самым рациональным вариантом для компактной среды, но его нужно считать с учетом будущего расширения.
Типовые ошибки при выборе
iSCSI в общей офисной сети
Это одна из самых частых ошибок. Storage-трафик нельзя смешивать с пользовательским трафиком, Wi-Fi, IP-телефонией, камерами, принтерами и обычным файловым обменом.
Последствия:
- случайные задержки;
- потери пакетов;
- подвисания виртуальных машин;
- сложная диагностика;
- ложное впечатление, что проблема в СХД.
Правильный подход — отдельная storage-сеть, два пути, мониторинг и понятная схема IP-адресации.
Один путь до СХД
Один кабель до массива — это единая точка отказа. Один коммутатор — тоже. Один HBA или NIC — тоже.
Для production-среды нужно планировать минимум два независимых пути. Иначе отказ одного физического элемента может остановить доступ к хранилищу.
Покупка СХД без нужных портов
Одна и та же линейка СХД может продаваться с разными контроллерами: FC, iSCSI, SAS или комбинированными вариантами. Поэтому перед покупкой нужно проверять не только название модели, но и конкретную комплектацию.
В коммерческом предложении стоит отдельно проверить:
- тип host-портов;
- скорость портов;
- количество портов на контроллер;
- наличие SFP;
- совместимость SFP с коммутатором;
- наличие HBA или NIC в серверах;
- тип кабелей;
- лицензии на порты и функции.
Путаница между SAS host-портами и портами расширения
На задней панели СХД могут быть SAS-разъемы, но это не всегда означает, что к ним можно подключить сервер. Иногда это порты для подключения дисковых полок расширения.
Перед покупкой нужно явно уточнить:
- можно ли подключать серверы к этим SAS-портам;
- сколько серверов поддерживается;
- поддерживается ли отказоустойчивое подключение;
- какие кабели и адаптеры нужны.
Выбор по максимальной скорости порта
16/32 Gb FC, 10/25 GbE iSCSI или 12 Gb SAS не гарантируют такую скорость на уровне приложения.
Ограничением может стать:
- дисковая группа;
- тип RAID;
- кэш СХД;
- контроллер;
- очередь запросов;
- один активный путь;
- перегруженный коммутатор;
- настройки ОС или гипервизора.
Интерфейс важен, но он не исправит слабую архитектуру хранения.
Использование LACP для увеличения пропускной способности iSCSI
Довольно частая история, когда берут два порта 10GbE объединяют их в LACP, думая что получится скорость в 20GbE. Но объединение портов в данном случае даёт только отказоустойчивость, но не масштабирование, для увеличения скорости необходимо использовать MPIO.
Чек-лист перед покупкой СХД и серверов
Перед закупкой стоит пройтись по списку:
- Сколько серверов будет подключено сейчас?
- Сколько серверов нужно подключить через 1–2 года?
- Нужен ли кластер VMware, Hyper-V или другой гипервизор?
- Какие интерфейсы есть у СХД: FC, iSCSI, SAS?
- Какая скорость портов?
- Сколько портов на каждом контроллере?
- Есть ли два контроллера?
- Есть ли HBA или сетевые карты в серверах?
- Нужны ли FC-коммутаторы?
- Нужны ли отдельные Ethernet-коммутаторы для iSCSI?
- Нужны ли SFP, DAC, оптические или SAS-кабели?
- Есть ли лицензии на порты и функции?
- Поддерживает ли ОС или гипервизор выбранную схему?
- Настроено ли многопутевое подключение?
- Есть ли мониторинг задержек, ошибок и отказов путей?
- Проверена ли матрица совместимости производителя?
Если хотя бы на несколько вопросов нет ответа, выбор интерфейса еще рано считать завершенным.
Как принять решение
Для небольшой инфраструктуры, где СХД стоит рядом с одним сервером или парой серверов, SAS часто будет самым простым и экономичным вариантом. Он не требует отдельной SAN-сети, понятен в подключении и хорошо подходит для компактных решений.
Для небольшого или среднего кластера чаще всего стоит смотреть на iSCSI. Но только при условии, что storage-трафик будет изолирован от обычной сети, а подключение будет построено минимум в два пути. iSCSI — не «дешевый FC», а отдельный подход, который хорошо работает при правильной сетевой архитектуре.
Для критичных систем, больших кластеров, баз данных, VDI и инфраструктуры с высокими требованиями к задержкам лучше выбирать FC. Его сложнее и дороже внедрять, зато он дает зрелую модель выделенной сети хранения и предсказуемое поведение в production.
Правильный интерфейс подключения СХД — это не самый дорогой и не самый быстрый на бумаге вариант. Это интерфейс, который соответствует топологии, нагрузке, бюджету, квалификации команды и планам роста. Ошибки чаще возникают не из-за самого FC, iSCSI или SAS, а из-за непроверенных портов, одного пути до СХД, общей сети для iSCSI, забытых кабелей, лицензий и неверных ожиданий от масштабирования.
