Как мы тестируем NAS: NFS, SMB, метаданные и отказ контроллера

В даташите NAS одна цифра: последовательное чтение в GB/s, снятое на больших файлах с нескольких клиентов. На ресурсе с домашними каталогами или на сборочной ферме сотни клиентов создают, опрашивают через stat, открывают и закрывают мелкие файлы, листают каталоги на 100 000 записей и пишут по несколько kB за раз. Здесь контроллер упирается в операции с метаданными, пока в линке еще есть запас. Мы меряем операции в секунду и задержку по каждому типу операции, а throughput показываем только для профиля больших файлов.

Стенд

Хосты стенда работают клиентами NFSv3, NFSv4.1 и SMB 3, с подписью или шифрованием, если они включены на ваших ресурсах. Профиль берем из статистики ваших ресурсов: распределение размеров файлов, доля вызовов метаданных против чтения и записи, размеры каталогов, число клиентов и опции монтирования. NAS стоит в лаборатории, работает на хостах стенда или остается в вашей лаборатории за выделенным каналом. Порты 1G, 10G и 100G, 25G как breakout из 100G. Прогон идет по шагам нагрузочного теста.

Между ними стоит ваша пара ToR с выгрузкой конфигурации, а порты генератора держат смесь приложений на тех же аплинках. Снимаем статистику вызовов с каждого клиента, счетчики NAS и коммутатора по портам.

Что проверяем

• Метаданные: create, stat, open и close, rename и delete в секунду, с p50 и p99 по каждому типу вызова
• Листинг каталогов на 10 000 – 1 000 000 записей: сколько он длится и что делает с другими клиентами там же
• Мелкие файлы от 4 kB до 256 kB: запись и чтение пачками, счет в штуках в секунду
• Последовательный ввод-вывод от 1 GB на файл: скорость на клиента и суммарная; GB/s в отчете стоят только здесь
• Масштаб по клиентам: число растет шагами до вашего дизайна, пока поток операций не перестанет расти, а p99 не пойдет вверх
• NFS nconnect и SMB multichannel: одно TCP-соединение на клиента против нескольких, и расходится ли нагрузка по NIC и линкам
• Отказ контроллера под нагрузкой: hard-монтирование NFS и SMB continuous availability, зависание клиента от последнего завершенного вызова до первого вернувшегося и каждая ошибка приложения
• Снапшоты создаем и удаляем по вашему расписанию во время прогона и пишем задержку по типам вызовов на каждом из них

На странице хранилищ все 5 классов устройств. Блочному хранению по NVMe/TCP и RoCEv2, с incast и PFC на ToR, посвящен отдельный пост: как мы тестируем сети хранения.

Что обычно ломается

Потолок метаданных. В типовом проекте ресурс отдавал 40 000 вызовов в секунду на 32 клиентах и те же 40 000 на 128. Задержка p99 у stat выросла с 2 до 45 мс, а аплинки были загружены меньше чем на 20 %. Пользователи жалуются на медленную сеть, и первыми проверяют коммутаторы. Таблица задержек по вызовам указывает на контроллер за час.

Дополнительные соединения не открываются. В шаблоне монтирования прописан nconnect, но половина клиентов монтирует ресурс через старую карту automount без него. SMB multichannel открывает один канал, потому что на NIC клиента выключен RSS. Такой клиент сидит на одном TCP-соединении: в типовом проекте около 1 GB/s на порту 25G.

Отказ контроллера. NAS переносит ресурс на второй контроллер за секунды, клиентам нужно больше времени. NFSv4 выжидает grace period. Клиенты SMB без continuous availability теряют открытые дескрипторы, и приложение показывает ошибку вместо паузы. В типовой таблице приемки это две строки. NFS: самое долгое зависание клиента 38 с при критерии 60 с, ошибок приложений нет. SMB на ресурсе без CA: 3 клиента из 20 потеряли открытые файлы.

Что в отчете

Операции в секунду и latency p50 и p99 по типу вызова, числу клиентов и профилю файлов, с точкой, где поток операций перестает расти. Throughput на клиента и суммарный для больших файлов, с nconnect или multichannel и без них. Зависание клиентов на каждом отказе по протоколу и опциям монтирования, с подсчетом ошибок приложений, и задержка на каждом снапшоте. Статистика вызовов с клиентов, счетчики NAS и коммутатора, захваты трафика и конфигурация каждого прогона: опции монтирования, настройки ресурсов, ToR. Вендор NAS, сетевая команда и владельцы ресурсов читают одну и ту же таблицу.

С чего начать

Пришлите нам модель NAS, число клиентов и статистику ваших файловых ресурсов. Мы ответим черновиком тест-плана: пункты проверки, схема стенда и сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.