Локальные NVMe выполняют профиль нагрузки в нужном SLA, но после переноса данных в сетевое хранилище может вырасти p99 задержки и снизиться IOPS. Чтобы понять, ограничивает ли систему транспорт, сравнивают один профиль I/O через iSCSI и NVMe-oF: одинаковые размер блока, queue depth, долю чтения и записи, сеть и функции target.
NVMe over Fabrics, или NVMe-oF, переносит командную модель NVMe через сеть. Он может уменьшить программный overhead и лучше масштабировать параллельный I/O, но результат зависит от транспорта и реализации. Ниже показано, какие звенья проверить до пилота.
Где возникает overhead при доступе к NVMe по сети
SCSI и iSCSI умеют держать несколько команд в работе, поэтому сводить их к одной очереди нельзя. Разница возникает из-за командной модели, организации очередей, числа переходов по программному стеку и сетевого транспорта. Величина overhead зависит от initiator, target, размера блока, queue depth и сети.
NVMe рассчитан на высокопараллельный доступ к твердотельной памяти и поддерживает до 65 535 очередей ввода-вывода с большим числом команд в каждой. Многоочередная модель позволяет подавать I/O с разных CPU-ядер. В тесте фиксируют IOPS, throughput и p95/p99 latency при заданных размере блока и глубине очереди.
iSCSI переносит команды SCSI через TCP/IP, а NVMe-oF передает NVMe capsules через RDMA, TCP или Fibre Channel. Путь приложения проходит через block layer, initiator, сеть, target и namespace. Каждый слой добавляет обработку, но реальный разрыв между iSCSI и NVMe-oF определяют только на одинаковом оборудовании и профиле I/O.
Возникает разрыв между возможностями носителя и возможностями канала до него. Чем быстрее становятся накопители, тем заметнее этот разрыв.
Что такое NVMe over Fabrics простыми словами
Технология переносит протокол NVMe на сетевой транспорт. Команды не транслируются в другой набор, а доставляются по сети в исходном виде — вместе с моделью множественных очередей.
ОС получает удаленные NVMe namespaces как блочные устройства через NVMe-oF initiator. Командная модель NVMe сохраняется, но путь остается сетевым: задержка, доступность и восстановление зависят от fabric, target, multipathing и таймаутов. Сходство с локальным диском относится к модели доступа, а не к архитектуре.
NVMe-oF также разделяет вычислительные узлы и хранилище и позволяет перераспределять namespaces без перестановки накопителей. При этом общий доступ, отказоустойчивость и миграция зависят от функций target и всей fabric.
Три транспорта: RDMA, TCP и Fibre Channel
NVMe-oF передает командные и ответные capsules через транспортные привязки RDMA, TCP или Fibre Channel. Каждая требует своей fabric-инфраструктуры.
Транспорт | Требования к сети | Типичное применение |
|---|---|---|
NVMe/RDMA | RDMA NIC и совместимая fabric, требования зависят от транспорта | Низкая latency при подтвержденном storage bottleneck |
NVMe/TCP | IP/Ethernet, поддержка NVMe/TCP у host и target | Пилот на существующей IP/Ethernet-сети |
NVMe/FC | Существующая фабрика Fibre Channel | Организации с построенной инфраструктурой FC |
Для NVMe/RDMA сначала выбирают конкретный транспорт. RoCE требует сквозной настройки Ethernet-fabric под модель управления перегрузкой и потоком. iWARP использует TCP и не предъявляет того же требования к PFC. InfiniBand требует совместимой InfiniBand-fabric. Во всех случаях проверяют RDMA у адаптеров, target, ОС, драйверов и коммутаторов.
NVMe/TCP работает поверх стандартной IP-сети и не требует RDMA-адаптеров. Он сохраняет модель очередей NVMe, но выигрыш относительно iSCSI не гарантирован сменой протокола. NVMe/TCP пилотируют на существующей Ethernet-сети, если host, target и ОС совместимы, а результат измеряют при одинаковом профиле.
NVMe поверх Fibre Channel логичен там, где фабрика FC уже построена и обслуживается: инфраструктура остается, транспортируемый протокол меняется.
Что нужно из оборудования
Работоспособность NVMe-oF зависит от согласованности всей цепочки. До закупки составляют единый чек-лист: host initiator и драйвер, NIC или HBA, коммутаторы и fabric, target и контроллер, multipathing, гипервизор или ОС. Для эксплуатации также задают discovery, аутентификацию, мониторинг ошибок и дропов, резервные пути и порядок failover.
На стороне сервера проверяют initiator, драйвер, ОС и серверные сетевые карты для выбранного транспорта. Отсутствие offload не всегда запрещает работу, но меняет нагрузку на CPU и производительность.
На стороне сети проверяют транспорт, версии коммутаторов, пропускную способность, сегментацию и резервирование. Для RoCE настраивают выбранную модель congestion control и flow control. Для NVMe/TCP обычную IP-сеть нельзя считать автоматически готовой: нужны контролируемая загрузка, маршрутизация, безопасность и мониторинг.
На стороне хранилища проверяют NVMe-oF target, discovery, аутентификацию и TLS там, где они поддерживаются, multipathing, zoning или VLAN, таймауты и сценарий восстановления после обрыва пути.
Несовместимость host, target или транспорта может сделать схему неработоспособной. Матрицы совместимости и фактический режим соединения проверяют до закупки, а затем подтверждают failover-тестом.
На каких задачах разница видна, а на каких нет
Технология адресует конкретную проблему — задержку транспорта. Если узкое место в другом месте, эффекта не будет.
Где выигрыш заметен:
NVMe-oF рассматривают для баз и виртуализации, когда замеры показывают высокий p99 storage latency при мелкоблочном параллельном I/O. Для GPU и аналитики нужен подтвержденный storage stall или недогрузка ускорителей из-за подачи данных. При последовательном чтении сначала сравнивают требуемую полосу с сетью и СХД.
Где разницы не будет:
Для архивов и backup NVMe-oF обычно не выбирают ради latency. Сначала проверяют, ограничен ли процесс сетью, источником, дедупликацией, сжатием или target. При широком канале транспорт все же может влиять на throughput, поэтому абсолютного запрета нет.
Снимите p95/p99 latency, IOPS, throughput, queue depth, CPU host и target и загрузку сети в проблемный период. Затем оцените долю времени операции в storage I/O и влияние ее сокращения на SLA приложения.
Для одного узла сервер с NVMe в массиве может дать меньшую задержку и более простую схему. Но он не создает автоматически общий доступ, независимость данных от вычислительного узла, миграцию ВМ и отказоустойчивый target. Сравнивают не только IOPS, но и восстановление после отказа узла и масштабирование.
Стоит ли переходить: критерии решения
Переход оправдан, когда совпадают три условия: узкое место действительно в задержке хранилища, нагрузка относится к мелкоблочному случайному доступу, и объем задачи достаточен, чтобы затраты на перестройку окупились.
Для пилота NVMe/TCP выделяют тестовый namespace и одинаковый профиль fio или прикладного теста. Его сравнивают с iSCSI на той же сети и фиксируют p95/p99 latency, IOPS, CPU и восстановление после обрыва пути.
RDMA рассматривают, если NVMe/TCP не выполняет заданный SLA p99 latency или создает неприемлемую нагрузку на CPU, а проект способен поддерживать совместимые адаптеры и fabric-настройки.
Отдельное предупреждение про цифры. Показатели из презентаций получены на конкретных конфигурациях при конкретных профилях нагрузки. Ваш результат зависит от накопителей, сети, настроек и характера обращений приложения. Единственный корректный способ — измерить на своей нагрузке до и после, на тестовом стенде.
Что делать перед решением
Технология решает транспортную задержку и только ее. Она не ускорит приложение, которое упирается в процессор, не компенсирует нехватку памяти и не сделает медленные накопители быстрыми.
Порядок действий состоит из четырех шагов: снять профиль I/O, подтвердить transport bottleneck, выбрать два транспорта-кандидата, провести A/B-пилот и failover-тест. Если ограничение находится в CPU, памяти, СХД или приложении, смена транспорта не решит проблему.
Если транспорт ограничивает приложение, для подбора системы хранения под задачу подготовьте профиль I/O, целевой p99 latency, требуемые IOPS и throughput и текущую схему сети. По этим данным выбирают СХД, адаптеры, транспорт и критерии пилотного теста до промышленного запуска.