NVMe over TCP или iSCSI: пора ли менять SAN

NVMe over TCP быстрее iSCSI - это правда, и на этом обычно строят аргумент «пора менять SAN». Только вопрос поставлен не с того конца. Быстрее сам по себе протокол ничего не решает: важно, упирается ли ваша сеть хранения в iSCSI вообще. Если узкое горло - в дисках, контроллере или сети, смена протокола ничего не даст, а миграцию вы оплатите.

Поэтому разберём честно: чем эти два протокола отличаются, где NVMe over TCP реально выигрывает, а где переход не окупится, и что нужно, чтобы мигрировать без сюрпризов.

Чем iSCSI и NVMe/TCP отличаются - на пальцах

iSCSI - это команды SCSI, языка дисковых накопителей из 1980-х, упакованные в TCP/IP и пущенные по сети. Протокол зрелый, работает где угодно, понятен любому админу. Но SCSI создавали под механические диски, и в эпоху флеша он стал прослойкой, которая добавляет накладные расходы.

NVMe - это язык, придуманный сразу под флеш-память и параллельный доступ. NVMe over TCP берёт родные NVMe-команды и так же пускает их поверх TCP/IP по обычному Ethernet. Сеть при этом остаётся прежней - меняется протокол поверх неё: вместо «переводим NVMe в SCSI и обратно» диск и хост говорят на одном языке.

И ещё: NVMe/TCP не требует особых сетевых карт. Есть и более быстрые варианты NVMe over Fabrics - через RDMA (RoCE) или InfiniBand, - но они хотят специальное оборудование и настройку. TCP-вариант работает на той же инфраструктуре Ethernet, что и iSCSI, и в этом его практическая ценность. Если нужно освежить, что такое iSCSI и другие протоколы доступа, у нас есть разбор протоколов доступа к данным в СХД.

Почему NVMe/TCP быстрее

Разница не в «более новом протоколе», а в архитектуре очередей. У iSCSI фактически одна очередь команд на соединение - наследие тех времён, когда на другом конце крутился один шпиндель, и глубокая параллельность была не нужна. Флеш-накопитель обрабатывает тысячи запросов одновременно, и одна очередь становится бутылочным горлышком.

NVMe устроен иначе: он поддерживает десятки тысяч параллельных очередей, в каждой - десятки тысяч команд. NVMe/TCP выносит эту параллельность в сеть. Поэтому выигрыш заметнее всего там, где много мелких случайных операций при высокой глубине очереди: нагруженная база, плотная виртуализация, VDI. Заодно на каждую операцию тратится меньше процессорного времени - нет прослойки перевода SCSI ↔ NVMe.

По замерам вендоров NVMe/TCP даёт ниже задержку и выше IOPS на том же массиве и той же сети, чем iSCSI. Разброс большой: где-то это десятки процентов, где-то - кратный прирост на мелких блоках. Порядок величин по задержке: iSCSI на случайном чтении 4К обычно держится около миллисекунды, NVMe/TCP - в районе сотен микросекунд. Цифры зависят от массива, сети и нагрузки, поэтому проверять их нужно на своём стенде, а не по чужому графику.

iSCSI против NVMe/TCP: таблица

Цифры задержки - порядок величин по бенчам вендоров, не гарантия для вашей конфигурации.

Когда переход на NVMe/TCP реально окупается

Есть несколько ситуаций, где смена протокола даёт видимый результат, а не строчку в презентации.

Массив на быстрых NVMe-дисках (all-flash). Здесь iSCSI со своей одной очередью действительно становится ограничением, и NVMe/TCP раскрывает то, на что способен флеш. Про сам сдвиг к флеш-массивам мы писали в статье почему all-NVMe СХД становятся стандартом.

Латентно-чувствительные нагрузки - нагруженные СУБД, плотная виртуализация, VDI на сотни рабочих столов. Там, где важен быстрый отклик на мелких операциях, разница между «около миллисекунды» и «сотней микросекунд» превращается в отзывчивость приложений.

Проектирование с нуля. Если вы собираете новое хранилище и массив с хостом поддерживают NVMe/TCP - закладывать в новый проект iSCSI смысла мало. Здесь переход бесплатный: вы просто не тащите за собой старую прослойку.

Когда iSCSI менять не надо

Обратная сторона, без которой совет неполный. Для среднего и малого бизнеса протокол редко оказывается тем, что тормозит хранилище.

Если массив собран на жёстких дисках или в гибриде (SSD-кэш плюс HDD), упор идёт в сами диски, а не в iSCSI. Разгонять протокол, когда узкое горло - механика, бессмысленно: NVMe/TCP на таком массиве не разгонит то, чего диски не отдают. Сначала измерьте, где реально теряется скорость.

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

Что нужно для перехода

Чтобы NVMe/TCP заработал, три условия должны сойтись.

Массив должен поддерживать NVMe/TCP и стоять на флеше - иначе прироста не будет. Сеть - обычный Ethernet, но чем быстрее, тем лучше: 25 или 100 Гбит и включённые jumbo frames раскрывают протокол полнее, чем 1 Гбит. И, наконец, хост или гипервизор должен уметь NVMe/TCP - вот здесь чаще всего и находится стоп-фактор.

Матрица поддержки на стороне хоста:

Отдельно про многопутёвость: если вы привыкли к MPIO с ALUA на iSCSI, на NVMe/TCP модель другая - нативный multipath с ANA. Это не тумблер «включить NVMe»: путевую схему придётся перенастроить, и это стоит проверить до миграции.

Миграция без простоя

Хорошая новость: менять всё и сразу не нужно. Современные массивы отдают тома одновременно и по iSCSI, и по NVMe/TCP. Поэтому переходить можно постепенно.

Разумный порядок такой. Сначала поднимаете NVMe/TCP на массиве и одном тестовом хосте, гоняете свою реальную нагрузку и смотрите, есть ли выигрыш именно у вас. Потом переводите самые требовательные нагрузки - те, ради которых всё и затевалось. Остальное можно оставить на iSCSI, пока не появится причина трогать. Никакого «выключили старое, включили новое» в выходные - это путь к простою и нервам.

Коротко: чек-лист «пора ли менять SAN»

• Измерьте, где реально узкое горло: протокол, диски, контроллер или сеть. Если не iSCSI - менять протокол незачем.
• Массив на all-flash? Если нет - сначала флеш, потом разговор о NVMe/TCP.
• Есть латентно-чувствительные нагрузки (БД, виртуализация, VDI)? Здесь выигрыш заметен.
• Проверьте поддержку на хосте: VMware 7.0U3+, Linux - да; Windows Server в проде - через сторонний инициатор.
• Сеть 25/100GbE с jumbo frames раскроет протокол; на 1 Гбит разница будет скромной.
• Мигрируйте постепенно, per-workload, с тестом на своей нагрузке. iSCSI и NVMe/TCP уживаются на одном массиве.

Частые вопросы

Что быстрее - NVMe/TCP или iSCSI?

NVMe/TCP: ниже задержка и выше IOPS на мелких операциях за счёт параллельных очередей. Но выигрыш виден на all-flash и латентно-чувствительных нагрузках; на HDD-массиве упор в диски, и разница почти не проявится.

Нужны ли для NVMe/TCP особые сетевые карты?

Нет. NVMe over TCP работает по обычному Ethernet, как iSCSI. Специальное железо нужно только для RDMA-вариантов (RoCE, InfiniBand) - это уже другой уровень бюджета.

Поддерживает ли VMware и Windows NVMe/TCP?

VMware vSphere - да, с 7.0 U3, полностью нативно с 8.0 U1. Linux - давно. Windows Server пока даёт только preview-инициатор, для продакшена используют сторонние решения.

Можно ли использовать iSCSI и NVMe/TCP одновременно?

Да. Массивы отдают тома по обоим протоколам параллельно - на этом и строится постепенная миграция, без разового переключения.

NVMe-накопитель и NVMe over TCP - это одно и то же?

Нет. Накопитель - это интерфейс диска внутри сервера или массива. NVMe/TCP - сетевой протокол доступа к хранилищу. Одно без другого существует спокойно.

По теме

• Что такое SAN и когда его стоит использовать
• LUN в СХД: что это такое и как работает логический диск
• DAS, NAS или SAN: что выбрать