NVMe-oF поверх RoCE v2: тестируем замену Fibre Channel в кластере хранения

Fibre Channel - это дорого. Не «немного дороже», а «выделенный коммутационный fabric, специализированные HBA, отдельная экспертиза и SFP-модули по цене приличного сервера». Для крупного банка это привычные операционные расходы; для промышленного предприятия с КИИ-объектом, которое только начинает строить нормальное хранилище, это боль. Когда один из клиентов в рамках managed-сопровождения поставил вопрос о новом кластере хранения и попросил обосновать альтернативы FC, мы решили не ограничиваться вендорскими презентациями и потрогать NVMe-oF руками.

Что тестировали и почему RoCE v2

NVMe over Fabrics - это протокол, который позволяет использовать NVMe-интерфейс не только для локальных дисков, но и по сети. Транспортов несколько: InfiniBand, FC-NVMe и RDMA over Converged Ethernet (RoCE). InfiniBand - отдельная инфраструктура, ещё дороже FC. FC-NVMe требует того же железа, что и обычный FC. RoCE v2 работает поверх обычного 25GbE или 100GbE Ethernet, которые у большинства клиентов уже есть или закладываются в бюджет под любую задачу.

Именно RoCE v2 нас и интересовал: идея использовать существующий Ethernet-фабрик для хранилища с latency, сопоставимой с FC, выглядит привлекательно. Особенно на фоне того, что отечественные СХД - Yadro, АЭОН, Depo - всё активнее заявляют поддержку NVMe-oF в своих roadmap-ах и актуальных прошивках.

Стенд

Собрали минимальный стенд из того, что было под рукой: два сервера-инициатора на Astra Linux SE 1.8 с 25GbE-картами с поддержкой RDMA, один сервер-таргет с NVMe SSD, 25GbE-коммутатор с поддержкой PFC (Priority Flow Control) - это обязательное условие для RoCE, без PFC RDMA деградирует под нагрузкой хуже iSCSI.

Для сравнения подняли iSCSI на том же железе и том же коммутаторе. Таргет - Open-iSCSI + LIO. NVMe-oF таргет - nvmetcli с rdma-транспортом.

Latency: NVMe-oF против iSCSI

Первое, что проверяли - latency на случайных 4K чтениях с глубиной очереди 1. Это самый показательный тест для хранилища: при глубине очереди 1 скрыть latency нечем, виден чистый round-trip.

iSCSI вёл себя предсказуемо: latency в районе 200-300 мкс, что для GigE/10GE - нормально, для 25GbE - чуть лучше, но не радикально. Протокол работает через TCP, добавляет overhead на копирование данных через CPU и stack.

NVMe-oF / RoCE v2 показал принципиально другую картину: latency в районе 50-100 мкс в стабильном состоянии. RDMA обходит CPU при передаче данных, пакеты не проходят через весь сетевой стек хоста. Это не маркетинговые цифры из вайтпейпера - разница действительно ощутима, и не в процентах, а в разах.

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

Стабильность под нагрузкой

Здесь всё оказалось интереснее, чем ожидали.

PFC - обязательно, а не желательно. RoCE требует lossless Ethernet. Без правильно настроенного PFC и ECN (Explicit Congestion Notification) на коммутаторе NVMe-oF под нагрузкой начинает сбрасывать RDMA-пакеты, что приводит к росту latency до уровня хуже iSCSI и периодическим таймаутам инициатора. Мы это воспроизвели намеренно - отключили PFC на тестовом VLAN и запустили трафик с соседних портов. Результат неприятный: не просто деградация, а паузы по несколько секунд. Для хранилища это катастрофа.

С правильным PFC и ECN - стабильно. Три часа fio со смешанной нагрузкой (70% чтение / 30% запись, 4K и 128K блоки), без единого таймаута инициатора.

CPU-overhead. Здесь NVMe-oF выигрывает у iSCSI заметно: RDMA разгружает CPU инициатора от работы с сетевым стеком. На инициаторах с iSCSI под нагрузкой мы видели 8-15% CPU на softirq; с NVMe-oF - меньше 3%. Для виртуализационных хостов, где каждый процент CPU на счету, это ощутимо.

Multipath. NVMe-oF поддерживает native multipath - несколько путей до одного namespace через разные интерфейсы. Настроили два пути от каждого инициатора, проверили отказ одного из интерфейсов. Failover прошёл за секунды без потери сессии - это лучше, чем мы видели с iSCSI multipath в аналогичной ситуации.

Что с отечественными СХД

Здесь честный ответ такой: поддержка NVMe-oF в отечественных СХД декларируется активнее, чем реализована в текущих прошивках. Несколько вендоров, которых мы опрашивали, говорят о поддержке как о feature в актуальной версии - но при попытке уточнить детали выясняется, что речь о FC-NVMe или о бета-статусе RoCE.

Yadro - наиболее продвинутые в этом направлении, у них RoCE в актуальных версиях задокументирован и есть референс-инсталляции. У остальных - смотрите на дату прошивки и спрашивайте конкретные версии, а не маркетинговые материалы.

Для стенда мы использовали Linux-таргет, что позволило проверить протокол независимо от вендорской реализации. В production это не вариант - там нужна поддержка со стороны СХД и гарантии вендора.

Итоговая картина

NVMe-oF поверх RoCE v2 - рабочая альтернатива Fibre Channel по характеристикам latency и производительности, при этом использует обычный Ethernet-фабрик. Ключевые условия, без которых это не работает нормально:

• Коммутаторы с поддержкой PFC и ECN - не любой управляемый свич, а именно data center класса с lossless Ethernet.
• RDMA-capable NIC - mlx5, Chelsio или аналог. Обычная карта без RDMA не даст эффекта.
• Правильная конфигурация QoS - это не «поставил и работает», нужна отдельная работа с сетевой командой.

Для клиента итог такой: FC исключили из рассмотрения как избыточно дорогой для их масштаба. NVMe-oF поверх нового 25GbE-фабрика вошёл в проектирование следующего этапа. iSCSI остаётся для менее критичных workload-ов - он проще в эксплуатации и не требует специального железа.

Полноценное тестирование с выбранной СХД запланировано на осень, когда будет готов новый фабрик. Там посмотрим, как вендорская реализация соотносится с тем, что мы видели на Linux-таргете.