NVMe-oF (NVMe over Fabrics) к 2026 году перестал быть «экзотикой» и стал вполне прикладным способом собрать remote block storage с задержками и IOPS, близкими к локальному NVMe. Но ключевое условие — подготовленная сеть и понятная модель отказоустойчивости.
Вы выбираете не только транспорт (NVMe/TCP, NVMe/RDMA или iSCSI), но и эксплуатационную дисциплину: изоляцию storage-сети, multipath, таймауты, наблюдаемость и план обновлений. Ниже — сравнение и чеклист, заточенные под реальные задачи VDS/виртуализации/БД на Linux.
Где NVMe-oF полезен в архитектуре
Удалочный блочный диск нужен там, где локальный NVMe «привязан» к конкретному хосту и усложняет миграции, HA и обслуживание:
кластеры виртуализации и контейнерные узлы, где важно быстро переносить нагрузку;
БД и очереди, которым критичны стабильные задержки и предсказуемые IOPS;
сценарии с двумя путями до хранилища (multipath), чтобы падение линка не роняло сервис;
выделенная storage-сеть между вычислительными узлами и узлами хранения.
NVMe-oF старается сохранить «нативную» модель NVMe (очереди, параллелизм команд) и при нормальной сети обычно даёт меньше накладных расходов, чем классический iSCSI.
NVMe/TCP, NVMe/RDMA и iSCSI: что отличается на практике
NVMe/TCP: универсальный компромисс
NVMe/TCP — NVMe-oF поверх TCP/IP. Его обычно выбирают как «дефолт» для Ethernet-инфраструктуры:
работает на типовой сети без специализированных NIC;
проще внедрить и сопровождать, легче автоматизировать;
устойчивее в разнородных средах (разные серверы, разные ядра), где RDMA часто упирается в нюансы железа и свитчей.
Минусы предсказуемые: TCP добавляет CPU overhead и может ухудшать tail latency при перегрузе (очереди, буферблоат, ретрансляции). Это лечится настройкой очередей NIC, IRQ affinity, дисциплиной QoS и изоляцией storage-трафика, но «магии» не будет: по минимальным задержкам NVMe/TCP почти всегда проигрывает RDMA.
NVMe/RDMA: максимум производительности, максимум требований
NVMe/RDMA (RoCEv2 или InfiniBand) выбирают, когда нужно выжать минимальные задержки и высокие IOPS при низком CPU. Но это «другая дисциплина эксплуатации»:
нужны совместимые NIC, корректные драйверы и прошивки, и регулярная верификация после обновлений;
для RoCE важна аккуратно настроенная сеть (включая контроль перегрузки), иначе микропотери превращаются в нестабильность;
в мониторинг добавляются RDMA-метрики (congestion/drops/retrans/состояния очередей).
Если у вас нет выделенной storage network и компетенции по RDMA-сетям, NVMe/RDMA часто даёт «идеальные цифры на стенде» и неприятные сюрпризы в реальном трафике.
iSCSI: зрелость и совместимость, но другой класс ожиданий
iSCSI остаётся живым: он понятен, стабилен, вокруг него огромный опыт, tooling и отлаженные runbook’и. Часто это рациональный выбор, когда важнее предсказуемость эксплуатации на разнородной инфраструктуре.
Но по latency и пику IOPS iSCSI обычно уступает NVMe-oF: выше накладные расходы, меньше «нативного» параллелизма очередей. Тем не менее, iSCSI может быть полностью достаточным, если ваши приложения не упираются в хвостовые задержки.
Если вы планируете строить кластер хранения в выделенной виртуализации и хотите полный контроль над ядром, сетью и политиками обновлений, практичнее сразу закладывать инфраструктуру на VDS.
Latency и IOPS: как сравнивать правильно
Типичная ошибка — сравнивать протоколы по «одной цифре IOPS» из бенчмарка. Для продакшена важнее поведение хвостов и деградаций:
p95/p99 latency, а не только средняя задержка;
что происходит при потерях пакетов, перегрузе CPU, перестройке маршрута;
стабильность на смешанном профиле (randread/randwrite + sync writes + фоновые задачи).
Для БД «красивые IOPS на чтении 4K при QD=32» почти ничего не говорят про реальный TTFB и время коммита: смотрите хвостовые задержки и синхронные записи.
Очень грубая рамка ожиданий:
NVMe/RDMA — лучший кандидат на минимальные задержки и высокий IOPS при низком CPU, но только при правильно настроенной RDMA-сети;
NVMe/TCP — обычно чуть выше latency и выше CPU на тех же IOPS, зато проще и чаще стабильнее в «обычном» Ethernet;
iSCSI — выше задержки и меньше пик, зато зрелость и понятная эксплуатация.
Если вы хотите «приземлить» требования к сети и маршрутизации, иногда полезно вынести storage-трафик в отдельный сегмент и, при необходимости, использовать L4-балансировку TCP/UDP на периферии. В этом контексте может пригодиться материал про балансировку TCP/UDP через Nginx Stream для сервисных сценариев вокруг storage-сети (не как замена multipath, а как элемент инфраструктуры).
Стек реализации: nvmet, SPDK и границы ответственности
Linux kernel target: nvmet
nvmet (NVMe target в ядре Linux) — частый выбор для Linux-to-Linux без «тяжёлых» зависимостей. Плюсы: интеграция с ядром, предсказуемые обновления, понятная диагностика стандартными инструментами. Минус: в «самом потолке» производительности может уступать user-space решениям, особенно на высоких скоростях и большом числе очередей.
SPDK: когда нужен максимум и есть команда под это
SPDK — user-space стек, который часто выигрывает по производительности за счёт polling/hugepages и обхода части ядра. Цена — усложнение эксплуатации: выделенные CPU, pinned IRQ/CPU, более строгая настройка хоста, своя модель наблюдаемости и типовые «подводные камни» при изменениях в железе/драйверах.
Практичный подход: начинать с nvmet и NVMe/TCP, а переход к RDMA/SPDK делать только когда замеры показывают узкое место (tail latency, CPU cost, насыщение очередей) и вы готовы поддерживать это как сервис.
Multipath в 2026: как сделать отказоустойчивость, а не «два провода в один ToR»
Multipath нужен не «для галочки», а чтобы переживать отказ порта/кабеля, перезагрузку узла хранения и деградации одного из путей (потери/задержки).
На Linux универсальный путь — dm-multipath. Но важно помнить: multipath — это не только конфиг на хосте, а топология и таймауты.
Два физических пути должны расходиться максимально: разные NIC, разные свитчи, при необходимости разные VLAN/VRF.
Проверяйте, что failover не превращается в «подвис на десятки секунд» из-за таймаутов и ретраев.
Тестируйте не только «линк упал», но и «линк жив, но с потерями и джиттером».
Отдельно заложите наблюдаемость событий переключения путей: они должны логироваться и алертиться, иначе вы узнаете о проблеме только по жалобам приложений.
Сеть хранения: что важнее протокола
В remote block storage сеть — это часть диска. Самые частые причины «NVMe-oF медленный/нестабильный» почти всегда сетевые:
перегруженные очереди, неудачная настройка interrupt moderation и распределения IRQ по CPU;
нет изоляции: storage-трафик делит каналы с бэкапами, репликацией и «шумными» сервисами;
буферблоат: высокая средняя скорость, но плохой p99;
MTU настроен «не везде», из-за чего появляются фрагментация или blackhole;
для RDMA: ошибки в настройке контроля перегрузки, из-за чего небольшие потери превращаются в нестабильность.
Практический совет: прежде чем выбирать NVMe/RDMA «ради меньшей latency», убедитесь, что ваша сеть уже даёт низкие хвосты на TCP и вы умеете их удерживать под нагрузкой. Иначе RDMA будет лечить не ту проблему.
iSCSI vs NVMe-oF: когда «старое» рациональнее
iSCSI в 2026 всё ещё разумен, если:
важнее совместимость с разными ОС/гипервизорами и отлаженные процессы;
нет готовности к тонкой настройке NVMe-oF и вы выбираете более консервативный стек;
нагрузка не упирается в p99 и экстремальные IOPS.
Если же вы строите хранилище под высоконагруженную OLTP-БД, очереди и сервисы, чувствительные к хвостовым задержкам, NVMe-oF (часто NVMe/TCP как базовый вариант) обычно выглядит более логичным выбором.
Production checklist: минимальный набор проверок перед продом
1) Топология и отказоустойчивость
Два независимых пути до target (желательно разные NIC и разные свитчи).
Тесты: отключение порта, выключение узла хранения, деградация одного пути (потери/задержки).
План обслуживания: как обновлять kernel/SPDK/firmware без простоя (rolling-обновления).
2) Multipath и таймауты
Определите модель путей: active/active или active/passive (зависит от реализации и политики).
Проверьте таймауты на уровне ОС и клиента, чтобы приложение не «замирало» при переключении.
События переключения путей должны быть видны в логах и метриках.
3) Тесты производительности, которые имеют смысл
Меряйте p95/p99 latency на профиле, близком к боевому (разные block size, randread/randwrite, sync).
Отдельно оцените CPU cost на initiator и target.
Проверьте устойчивость к «шуму»: параллельно с I/O дайте сетевую и фоновые нагрузки.
4) Наблюдаемость и диагностика
Метрики дисков: очередь, время обслуживания, ошибки, SMART/NVMe health.
Метрики сети: drops/retrans, p99 RTT, ошибки интерфейса, насыщение линков.
События на уровне NVMe-oF/iSCSI: подключения, реконнекты, изменения путей.
5) Безопасность и изоляция
Изолируйте storage network (VLAN/VRF/отдельные порты), минимизируйте L2-домен.
Контроль доступа: инициаторы должны видеть только свои namespace/LUN.
План реакции на компрометацию: быстрый отзыв доступа, ротация секретов (если используете).
Что выбирать «по умолчанию»
Начинайте с NVMe/TCP, если нужна хорошая смесь latency/IOPS/простоты на обычной Ethernet-сети.
Переходите на NVMe/RDMA, когда есть выделенная storage network, компетенция по RDMA и вы упёрлись в tail latency или CPU на NVMe/TCP.
Оставайтесь на iSCSI, если важнее зрелость, совместимость и предсказуемая эксплуатация, а текущей производительности достаточно.
Ключевой фактор успеха NVMe-oF в 2026 — не выбор «самого быстрого протокола», а дисциплина: изоляция storage-трафика, корректный multipath, тесты хвостовых задержек и нормальная наблюдаемость. Если это сделано, remote block storage действительно начинает ощущаться как «удалённый NVMe», который не страшно нести в прод.
Если вы размещаете такую инфраструктуру под проекты клиентов или свои сервисы, удобнее сразу закладывать ресурсы с запасом по CPU и сети на вычислительных узлах. Под это обычно лучше подходят VDS, где вы контролируете сетевые очереди, ядро и политику обновлений.
