Сеть хранения для СХД: iSCSI, FC или NVMe-oF без мифов

Зачем вообще выбирать сеть хранения, а не брать что есть

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

Хранилище почти никогда не живет в вакууме. На результат влияют коммутаторы, очереди и буферы, перегрузка портов, конкуренция с обычным трафиком, а также то, как серверы и гипервизор формируют запросы. Поэтому логика «у нас 10/25/100G, значит все будет быстро» часто не срабатывает. Пропускная способность и задержка - разные вещи, и для storage обычно критичнее второе.

Есть и фактор надежности. В обычной корпоративной сети сбой может выглядеть как «пару секунд не было связи». Для хранения это легко превращается в зависшие виртуальные машины, долгие ребилды, ошибки файловых систем и нервные окна обслуживания. Поэтому споры iSCSI vs Fibre Channel обычно не про «что лучше», а про то, какой уровень предсказуемости и ответственности вы хотите получить от сети.

Перед выбором полезно договориться о приоритетах. Чаще всего важны простота внедрения, стоимость владения (железо, лицензии, поддержка, обучение), SLA по задержкам в пиковые часы, план масштабирования на 2-3 года и доступность специалистов на месте.

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

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

Три варианта в двух словах: iSCSI, Fibre Channel, NVMe-oF

Обычно сравнивают три подхода: iSCSI, Fibre Channel и NVMe-oF. Все они решают одну задачу: надежно возить блочные данные между серверами и массивом. Отличаются тем, по какой среде это работает, какое оборудование нужно и сколько усилий уйдет на поддержку.

iSCSI: блочный доступ по Ethernet

iSCSI - это SCSI-команды, упакованные в TCP/IP и отправленные по Ethernet. Плюс понятный: можно использовать привычные коммутаторы, кабели и навыки сетевых админов. Минус тоже понятный: задержки и стабильность сильнее зависят от того, как настроена сеть (перегрузки, очереди, потери пакетов). Поэтому под iSCSI часто выделяют отдельный VLAN или вообще отдельную физическую сеть.

Типичные сценарии: виртуализация малого и среднего масштаба, файловые сервисы поверх VM, резервное копирование, тестовые контуры. Для баз данных iSCSI тоже подходит, но почти всегда требует изоляции трафика и проверки задержек под нагрузкой.

Fibre Channel: отдельная SAN как дисциплина

Fibre Channel (FC) - специализированная сеть хранения: свои коммутаторы, свои адаптеры (HBA) и своя «сановская» терминология (WWPN, zoning). За счет изоляции FC часто проще удерживать стабильные задержки в продакшене, особенно когда много хостов и есть критичные сервисы.

FC часто выбирают для больших кластеров виртуализации, транзакционных БД, VDI с высокими пиками I/O. Вход обычно дороже из-за FC-коммутаторов и HBA, зато меньше сюрпризов, если все собрано по правилам.

NVMe-oF: NVMe поверх сети

NVMe-oF позволяет вынести NVMe-доступ за пределы одного сервера. Транспорт при этом бывает разным (например, RoCE или TCP), из-за чего часто возникает путаница: NVMe-oF - не «одна сеть», а набор вариантов. Его выбирают, когда важны минимальные задержки и высокая IOPS, и когда есть понятный план роста под быстрые SSD-массивы.

Чтобы не запутаться, удобно разделять три уровня:

• Протокол: iSCSI, FC, NVMe-oF (что «говорят» сервер и СХД).
• Транспорт: Ethernet (TCP/RDMA) или Fibre Channel.
• Архитектура и отказоустойчивость: две независимые сети/фабрики, несколько путей к СХД, MPIO, дублирование коммутаторов, портов, кабелей и питания.

В проектах интеграции часто начинают не с названий, а с вопроса: какой профиль нагрузки и какой запас по росту нужен на 2-3 года. Тогда выбор между iSCSI, FC и NVMe-oF становится практичным, а не «религиозным».

Задержки и производительность: как сравнивать честно

При выборе сети хранения многие смотрят на «максимальные IOPS» и «скорость в Гбит/с». Для СХД важнее, как быстро и предсказуемо система отвечает на маленькие операции чтения и записи в реальной нагрузке.

Задержка зависит не только от сети. На нее влияют размер блока (4K, 8K, 64K), глубина очереди (queue depth) и профиль нагрузки (чтение/запись, случайная/последовательная). Один и тот же массив может показывать красивые IOPS на 4K random read и заметно проседать на смешанной нагрузке 70/30, потому что запись «дороже», очереди растут, а хвосты задержек становятся длиннее.

Смотрите не на среднюю задержку, а на стабильность. Среднее легко сделать «красивым», если иногда случаются редкие, но длинные паузы. Пользователи замечают именно их: подвисания базы, лаги VDI, задержки при открытии файлов. Поэтому ориентируйтесь на p95 и p99 и проверяйте, как они меняются при росте нагрузки.

Сеть обычно вносит проблемы в трех местах: перегрузка, потери пакетов и очереди в буферах. Перегрузка часто появляется из-за oversubscription (когда аплинки «тоньше», чем суммарный трафик вниз). Потери и ретрансляции резко увеличивают хвост задержек, даже если средняя загрузка портов выглядит нормальной. А слишком большие буферы иногда маскируют проблему, создавая очередь ожидания и добавляя миллисекунды там, где вы ждете сотни микросекунд.

Перед выбором попросите интегратора показать замеры на вашем типовом сценарии и на ваших серверах: CPU и драйверы на хостах тоже важны, особенно для iSCSI и NVMe/TCP. Минимальный набор того, что стоит запросить:

• p95/p99 задержки на чтение и запись отдельно при нескольких уровнях нагрузки
• IOPS и пропускная способность с указанием размера блока и глубины очереди
• загрузка портов коммутаторов и наличие дропов/ошибок
• загрузка CPU на хостах и на контроллерах
• схема подписки портов (нет ли узких мест в аплинках)

Пример: база и виртуализация работают на кластере. Если при росте нагрузки p99 уходит с 1-2 мс в 10-20 мс, пользователи увидят «тормоза», даже если средняя задержка осталась низкой. Честное сравнение строится вокруг хвостов задержек и поведения под пиком, а не вокруг одного рекордного числа.

Стоимость: что учитывать кроме цены портов и кабелей

Стоимость сети хранения почти никогда не равна сумме «коммутатор + кабели». Сюрпризы обычно появляются в том, как вы заходите в проект, как живете с ним 3-5 лет и как расширяетесь, когда заканчиваются порты и запас по пропускной способности.

Входной билет: что формирует бюджет

На старте деньги уходят не только в железо, но и в совместимость, поддержку и «мелочи», которые быстро становятся отдельной статьей:

• адаптеры на хостах (NIC/HBA) и их количество для отказоустойчивости
• коммутаторы, количество портов, скорости, резервирование (две фабрики/два коммутатора)
• оптика и трансиверы, патч-корды, кроссы, иногда трассы и монтаж
• лицензии и контракты поддержки (на стороне СХД и коммутаторов)
• пусконаладка: проектирование, multipath, тесты, документация

Если в стойках уже есть развитый Ethernet, входной порог для iSCSI (и части вариантов NVMe-oF поверх Ethernet) часто ниже. FC чаще дороже на старте из-за отдельной инфраструктуры, но может дать более предсказуемую модель эксплуатации там, где это важно.

Что дороже в эксплуатации

В эксплуатации разницу в цене портов часто обгоняют простои и затянутая диагностика. Дорого обходится не «железо само по себе», а время, когда сервис деградирует, а причина неясна.

Обычно расходы упираются в простои, сложность поиска проблем (если команда редко видела конкретную SAN-технологию), отсутствие запаса по портам и пропускной способности, а также в сервис (сроки и стоимость замены модулей и оптики, наличие поддержки на месте).

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

Где экономить безопасно и как учитывать рост

Безопасная экономия обычно про унификацию и планирование, а не про отказ от резервирования. Разумные варианты: использовать существующую кабельную инфраструктуру (если подходит по скорости и качеству), унифицировать Ethernet-оборудование там, где это не снижает надежность, и заранее согласовать путь расширения без остановок.

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

Доступность специалистов и поддержка: реальность на местах

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

Обычно нужны три роли: сетевой инженер (VLAN/VRF, QoS, MTU, диагностика потерь и задержек), инженер по СХД (multipath, политики, алерты) и администратор виртуализации (datastore/volume, совместимость, обновления). В небольшой команде это может быть один человек, но компетенции все равно должны быть.

По рынку обычно проще найти людей с сильным Ethernet-опытом, чем узких специалистов по FC. iSCSI чаще ложится на привычные процессы: те же коммутаторы, те же инструменты мониторинга. FC требует SAN-навыков (zoning, WWN, работа с FC-коммутаторами и HBA). NVMe-oF - история «новее и быстрее», но встречается реже, поэтому и специалистов меньше, и дисциплина проектирования важнее.

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

Поддержку стоит обсуждать так же строго, как железо. Вопросы, которые хорошо отсекают сюрпризы:

• кто принимает заявки 24/7 и как быстро начинается работа по критическому инциденту
• как устроена эскалация и кто подключает вендоров
• что входит в поддержку (обновления, health-check, помощь при расширении, разбор инцидентов)
• где граница ответственности: сеть, СХД, гипервизор, приложения
• какие отчеты вы получите после аварии (причина, действия, профилактика)

Если важно, чтобы поддержка была на месте и круглосуточно, проверяйте не обещания, а реальную дежурную модель и сервисную сеть. Например, у GSE.kz заявлена 24/7 техническая поддержка и сеть сервисных подразделений по Казахстану - для региональных площадок это иногда важнее разницы в «теоретических» микросекундах.

Практичный алгоритм выбора: шаги без лишней теории

Выбор редко начинается с протокола. Он начинается с того, что именно вы хотите получить: стабильную задержку, прогнозируемый рост, понятное обслуживание и рабочую отказоустойчивость.

1. Опишите нагрузки простыми словами. VM обычно важны стабильность и поведение на пиках, базы данных чувствительны к хвостам задержек (p95/p99), файловым сервисам часто важнее пропускная способность и емкость. Сразу отметьте, сколько простоя допустимо и что должно переживать отказ одного пути.

2. Соберите текущие цифры, иначе сравнение будет на уровне мифов. Нужны IOPS и MB/s, но вместе с задержкой под нагрузкой.

Минимальный набор метрик для старта:

• IOPS и пропускная способность в пике и в обычный день
• p95 задержки на чтение и запись
• размер и тип блоков (4K, 8K, 64K)
• рост данных и нагрузок по месяцам
• сколько хостов сейчас и сколько будет через 2-3 года

3. Зафиксируйте требования к отказоустойчивости. В реальности это два независимых пути: два коммутатора или две фабрики, multipath на хостах, понятная схема обновлений без остановки сервисов и обязательные тесты отказов до ввода.

4. Выберите целевую архитектуру и заложите масштабирование. Убедитесь, что сеть расширяется без полной замены: добавление портов, апгрейд скоростей, второй коммутатор, место под адаптеры в серверах.

5. Сделайте пилот и заранее согласуйте критерии приемки. Поднимите 2-3 типовые VM и тестовую БД, прогоните нагрузку в часы пика, проверьте p95/p99, поведение при отказе одного линка и время восстановления.

Если вы приносите интегратору не запрос «хотим быстро», а конкретные метрики и критерии приемки, обсуждение iSCSI vs FC vs NVMe-oF становится заметно продуктивнее. В таких проектах удобно, когда один подрядчик может закрыть и серверную часть, и интеграцию, и поддержку - например, GSE.kz работает как производитель оборудования и системный интегратор.

Когда iSCSI, когда Fibre Channel, когда NVMe-oF

default-выбора нет: решение упирается в то, что вы сможете внедрить, поддерживать и расширять без сюрпризов.

iSCSI обычно выбирают, когда нужно быстро стартовать на привычном Ethernet. Это частый вариант для виртуализации среднего масштаба, файловых сервисов, резервного копирования, тестовых сред и филиалов. Он хорошо работает при аккуратной сегментации трафика и дисциплине в сети.

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

NVMe-oF уместен, когда есть быстрые массивы и нагрузки, которым важны минимальные задержки: высоконагруженные базы, аналитика, плотные VDI-кластеры, отдельные AI и data-intensive задачи. Но он дает смысл только вместе с готовностью инфраструктуры и команды.

Ориентир для быстрого выбора:

• нужен быстрый запуск и единая сеть - чаще iSCSI
• нужна максимальная предсказуемость и изоляция - чаще Fibre Channel
• нужны минимальные задержки для топовых нагрузок - чаще NVMe-oF

Перед закупкой задайте прямые вопросы, чтобы избежать «несовместимо после поставки»:

• какие хосты и ОС поддерживаются в вашем сценарии (драйверы, версии прошивок)
• как будет устроен multipath и кто отвечает за настройку на серверах
• какие ограничения по совместимости коммутаторов, HBA/NIC и СХД и чем они подтверждены
• какими метриками измеряется результат (задержки, IOPS, профиль теста)
• как выглядит план роста на 12-24 месяца (порты, скорости, миграции без простоя)

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

Частые ошибки при внедрении SAN и как их избежать

Ошибки в SAN редко выглядят как «всё сломалось сразу». Чаще это плавающие задержки, неожиданные затыки в пиковые часы и аварии, которые долго диагностировать.

1) Смешали трафик и не контролируют его

Когда storage живет в тех же коммутаторах и VLAN, что офисная сеть, а рядом идут бэкапы, обновления и репликации, начинается конкуренция за буферы и полосу. Спасает дисциплина: отдельный сегмент под storage, понятные QoS-политики (если iSCSI), лимиты и окна для бэкапов, проверка, что в storage-сегмент не попал лишний трафик.

2) Отказоустойчивость «на словах»

Один коммутатор или один путь до массива, либо пути есть, но их никогда не проверяли в реальном отказе. Закладывайте два независимых пути, разнесение по коммутаторам и питанию, корректный multipath на хостах и обязательные тесты отказов до запуска.

3) Выбор по презентациям, а не по своим метрикам

IOPS и микросекунды из слайдов не учитывают ваш профиль: размер блока, долю записи, глубину очередей, влияние виртуализации и соседних задач. Опирайтесь на измеримые цели и делайте короткий пилот или хотя бы нормальный сбор статистики по текущей системе.

4) Не продумали рост

SAN часто упирается не в скорость, а в ограничения по портам, лицензиям, месту в стойке, типу оптики или PCIe-слотам под HBA/NIC. Планируйте подключение новых хостов заранее.

Короткая самопроверка перед запуском:

• есть запас портов и аплинков хотя бы на 30-50% роста
• понятно, как добавлять хосты без остановки сервисов
• зафиксированы требования к кабелям/оптике и совместимость
• согласованы окна и лимиты для бэкапа и репликации
• проведены тесты отказа (порт, свитч, контроллер, линк)

5) Настроили, но не задокументировали

Через полгода меняется админ, и никто не понимает, где какие WWPN/IQN, VLAN, зоны, версии прошивок и почему так настроен multipath. Это увеличивает время любой аварии.

Минимум документации, который реально спасает:

• схема подключений (физика и логика) и список портов
• таблица хостов: IQN/WWPN, IP, VLAN, роли
• правила zoning/masking и принципы именования
• версии прошивок, драйверов, параметры multipath
• результаты тестов: замеры задержек и сценарии отказа

Практичный пример: в больнице ночные бэкапы съедали полосу, и утром VDI начинал тормозить. Проблему решили не заменой массива, а выделением storage-сегмента, лимитами на бэкап и тестом отказа, который выявил неправильный multipath на части хостов.

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

Чтобы интегратор не предлагал «как привыкли», а вы получили решение под реальную нагрузку и рост, фиксируйте требования в вопросах.

Про нагрузку, SLA и архитектуру

• какие приложения и профили I/O закладываются и какими цифрами это подтверждено (замеры, пилот, статистика гипервизора)
• сколько хостов и массивов будет на старте и какой прогноз на 24-36 месяцев (объем, IOPS, пропускная способность, порты)
• какой SLA нужен: допустимый простой, обслуживание без остановки, RPO/RTO, какие отказы должны переживаться (порт, свитч, контроллер, площадка)
• нужна ли физическая изоляция от LAN или достаточно логической сегментации и кто отвечает за границы
• сколько путей закладывается (multipath), какие скорости и типы портов на хостах и на СХД, где возможны узкие места (PCIe, oversubscription, лицензии)

Про эксплуатацию, тесты и поставку

• кто поддерживает решение после внедрения и какие компетенции нужны на стороне заказчика
• что мониторится (порты, очереди, задержка, потери, ошибки), какие пороги считаются аварийными и кто реагирует
• как проверяются аварийные сценарии (линк, свитч, контроллер, обновления) и будет ли план тестов и акт приемки
• есть ли запасные части в стране и какой режим поддержки (24/7, время реакции, время восстановления)
• как выглядит план обновлений и расширений на 2-3 года: совместимость версий, окна работ, поэтапное расширение без простоя

Если подрядчик совмещает роль интегратора и производителя (как GSE.kz), отдельно уточните, кто отвечает за запчасти, выезды и поддержку всей цепочки от сервера до СХД, а не «по отдельным коробкам».

Пример выбора: рост инфраструктуры и план миграции без боли

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

Ограничения обычно приземленные: бюджет утвержден заранее, сроки жесткие, а специалистов по конкретной технологии (особенно FC или NVMe-oF) может не быть в штате. При этом нужна поддержка 24/7 и понятный план роста на 2-3 года, чтобы сеть хранения не пришлось переделывать через полгода.

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

Дальше варианты сравниваются по рискам миграции. Если сейчас iSCSI и все в целом работает, часто разумно сначала «довести его до ума» (сегментация, резервирование, QoS, проверенные коммутаторы), а NVMe-oF рассматривать как следующий этап, когда появится зрелая потребность в минимальных задержках и готовность команды. FC имеет смысл, если у вас уже есть опыт и процессы, а предсказуемость и изоляция важнее гибкости.

Чтобы миграция прошла без боли, планируйте два шага: сначала перенос некритичных нагрузок для обкатки, затем поэтапный перенос критичных систем с окном отката. И заранее договоритесь о границах ответственности: СХД, сеть, гипервизор, multipath, мониторинг.

Действия, которые обычно экономят недели: подготовить ТЗ с измеримыми критериями, согласовать целевую архитектуру и собрать тестовый стенд, максимально похожий на боевой. На этом этапе удобно подключать и производителя, и интегратора: подобрать серверы и СХД под профиль нагрузок, спроектировать сеть и обеспечить дальнейшую поддержку. В Казахстане такой формат часто делают с участием GSE.kz как системного интегратора и производителя серверов, чтобы поставка и сервис оставались в одном контуре ответственности.