Новую файловую систему NetApp Novus нельзя добавить в обычную заявку на СХД как «модель поновее». Производитель рассчитывает её на ИИ-фабрики с десятками тысяч GPU. Для кластера из 50 000 ускорителей NetApp называет требуемую совокупную пропускную способность 100 Тбит/с.

Если ты выбираешь хранилище для 1С, виртуальных машин, общих файлов или резервных копий, Novus из проекта можно вычеркнуть. В этой инфраструктуре полезнее проверить ONTAP 9.18.1, а при подтверждённой нехватке IOPS или пропускной способности — сравнить массивы EF50 и EF80 на своей нагрузке.

Novus имеет смысл только в ИИ-фабрике

NetApp строила Novus не как замену офисному NAS или универсальному SAN. Это архитектура для непрерывной подачи данных на тысячи GPU, простой которых обходится дороже отдельного слоя хранения.

По описанию NetApp Novus, система разделяет данные и метаданные, использует AFF A90 для слоя данных и работает со штатными клиентами NFSv4.2/pNFS Flex Files с nconnect. NVIDIA GPUDirect Storage позволяет ускорителям получать данные, минуя лишнее копирование через память процессора.

Производитель заявляет более 100 ТБ/с в едином пространстве имён и поддержку сотен тысяч GPU. Это другой масштаб закупки: не одна стойка с базами и виртуальными машинами, а площадка гигаваттного класса.

ITPro приводит оценку, по которой из-за медленной подачи данных загрузка GPU в традиционной архитектуре может падать ниже 30%. Это не результат универсального испытания: показатель зависит от модели обучения, размера файлов, сети и организации набора данных. Но критерий для проекта из него получается ясный: Novus обсуждают, когда замеры показывают простой дорогостоящего GPU-кластера из-за хранилища.

Разделение программного и аппаратного слоёв само по себе не делает систему подходящей для ИИ. Принципы программно определяемых хранилищ помогают понять архитектуру, но не заменяют расчёт потока данных к ускорителям.

Для 1С на 50 пользователей, файлового архива на 200 ТБ или кластера из 20 гипервизоров у Novus нет задачи. Её масштаб не даёт этим нагрузкам измеримой выгоды.

EF50 подходит для базы, которая уже упирается в обычный SAN

EF50 и EF80 ближе к реальному проекту закупки. Обе модели занимают 2U, вмещают 24 NVMe SSD, работают с двумя активными контроллерами и поддерживают FC, NVMe/RoCE, iSCSI и InfiniBand.

Разница начинается с предельной производительности. По характеристикам, опубликованным ServerNews, EF50 выдаёт до 41 Гбайт/с при чтении, до 30 Гбайт/с при записи и до 1,7 млн IOPS. У EF80 заявлены 110 Гбайт/с, 57 Гбайт/с и 5 млн IOPS соответственно.

Эти цифры не доказывают, что транзакционная база станет работать быстрее. В опубликованных данных нет методики теста, профиля операций, размера блока и задержки на конкретной СУБД. Поэтому EF50 стоит включать в короткий список для базы или умеренной HPC-нагрузки, но выбирать — после пилота с её снимком или генератором того же профиля ввода-вывода.

EF80 нужен не «на вырост», а под измеренный дефицит. Если мониторинг показывает 2,5 млн IOPS или последовательное чтение выше 45 Гбайт/с, EF50 уже не проходит по паспортному пределу. Тогда EF80 становится кандидатом. Если текущая нагрузка держится на 300 000 IOPS и 8 Гбайт/с, разница между моделями останется в коммерческом предложении, а не в работе приложения.

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

EF80 требует новой сети, а не только места в стойке

У EF80 до 12 портов 200Gb NVMe/IB или NVMe/RoCE и до 24 портов 64Gb FC. Паспортные 110 Гбайт/с не получить через пару старых 32Gb FC-подключений.

Даже восемь линий 100Gb дают суммарно 800 Гбит/с, то есть 100 Гбайт/с до вычета служебного трафика и потерь протокола. Для заявленных 110 Гбайт/с потребуется больше восьми таких линий либо фабрика на 200Gb. Вместе с массивом в смету попадут коммутаторы, оптические модули, кабели и серверные адаптеры.

Питание тоже различается. Типовое потребление EF50 составляет 1041 Вт, EF80 — 1235 Вт. При круглосуточной работе расчёт выглядит так:

EF50: 1,041 кВт × 8760 часов = 9119 кВт·ч в год;
EF80: 1,235 кВт × 8760 часов = 10 819 кВт·ч в год;
разница: 1700 кВт·ч в год без охлаждения.

Чтобы получить расходы в рублях, умножь результат на тариф своей площадки. При 10 ₽ за кВт·ч разница составит 17 000 ₽ в год только по питанию массива. Это расчётный пример, а не универсальная цена эксплуатации.

Компромисс EF50 — предел в 1,7 млн IOPS и 41 Гбайт/с. Компромисс EF80 — сеть классом выше, дополнительные адаптеры и ещё 1700 кВт·ч в год до учёта охлаждения.

ONTAP 9.18.1 меняет работу действующей инфраструктуры

Владельцу массива на ONTAP обновление 9.18.1 принесёт больше пользы, чем анонс Novus. Здесь речь идёт о функциях, которые можно применить к резервному копированию, S3 и защите томов.

В примечаниях к выпуску ONTAP 9.18.1 NetApp указывает три изменения:

SnapMirror cloud поддерживает резервное копирование и восстановление FlexGroup в конфигурациях MetroCluster;
из S3-снимка можно восстановить отдельный объект, набор объектов или весь бакет;
ARP/AI автоматически включается для новых томов на AFF A, AFF C, ASA и ASA r2 после 12-часового льготного периода.

Номер версии сам по себе не основание для обновления. Сначала проверь ограничения нужной функции. Постквантовые алгоритмы SSL работают при отключённом SSL FIPS. Доступ по S3 к данным FlexCache требует ONTAP 9.18.1 или новее на всех узлах кластера.

Если эти условия конфликтуют с принятой политикой безопасности или версиями соседних узлов, обновление придётся разбить на этапы. Начинать лучше с тестового кластера и сценария отката, а не с включения функций в рабочем MetroCluster.

Спецификация под задачу

Считаем для проекта, где замеры уже показали упор в хранилище. Первый сценарий — транзакционная база требует до 1 млн IOPS и 25 Гбайт/с чтения. Второй — HPC-нагрузка доходит до 3 млн IOPS или 60 Гбайт/с.

Параметр	Транзакционная база	HPC с подтверждённым дефицитом полосы
Массив	NetApp EF50	NetApp EF80
Корпус	2U	2U
Контроллеры	два активных	два активных
Накопители	24 NVMe SSD	24 NVMe SSD
Заявленный предел	1,7 млн IOPS, чтение 41 Гбайт/с	5 млн IOPS, чтение 110 Гбайт/с
Подключение	FC, NVMe/RoCE, iSCSI или InfiniBand под действующую фабрику	200Gb NVMe/IB либо NVMe/RoCE; 64Gb FC — после расчёта числа линий
Типовое потребление	1041 Вт	1235 Вт
Проверка перед заказом	пилот с профилем операций базы и замером задержки	пилот с целевой полосой, числом потоков и рабочим размером блока

Ёмкость SSD здесь не указана намеренно: исходных данных о рабочем объёме, коэффициенте заполнения и запасе на рост нет. Её считают отдельно. Например, для 200 ТБ полезных данных, 30% запаса и коэффициента полезной ёмкости массива 0,8 потребуется 200 × 1,3 ÷ 0,8 = 325 ТБ сырой ёмкости. Если полезный объём вырастет вдвое, сырой объём также удвоится.

EF50 оставляй в спецификации, пока расчётная нагрузка укладывается в его пределы с запасом и пилот подтверждает задержку. EF80 добавляй, когда EF50 не проходит по IOPS или полосе. Покупка EF80 без расчёта сети оставляет большую часть её производительности недоступной.

Для обычной 1С, виртуализации, файлов и резервных копий развилка короче: Novus исключить, действующий ONTAP проверить на совместимость с 9.18.1, а EF50 и EF80 рассматривать только после замеров. В заявке на EF80 должны стоять требуемая полоса, число и скорость портов, серверные адаптеры и годовое потребление около 10 819 кВт·ч. Одной строки «до 5 млн IOPS» для закупки недостаточно.