Тестирование производительности и надёжности хранилища: методика, инструменты и шаблон отчёта

Зачем тестировать хранилище и какие задачи это решает

Производитель заявляет для массива NVMe 500 000 IOPS, а приложение получает 40 000 и стоит в очереди на запись. Между этими цифрами лежит разница между блочным доступом к пустому устройству и реальной работой через ZFS, сеть и RAID-контроллер. Короткий ответ на главный вопрос: хранилище проверяют двумя независимыми блоками работ - измерением метрик на сценариях, приближенных к рабочей нагрузке, и имитацией отказов диска и узла с замером реакции системы. Только вместе эти данные показывают, выдержит ли массив реальную эксплуатацию.

Практических поводов провести тесты несколько:

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

Без метрик доказать готовность хранилища к работе невозможно. Фраза «должно выдержать» в отчёте не защищает от инцидента. Числа с указанием сценария, размера блока, глубины очереди и перцентилей латентности превращают предположение в проверяемое утверждение.

Экономический смысл прямой. Замеры до и после апгрейда показывают, дал ли новый SLOG или переход на NVMe ожидаемый эффект. Иногда узким местом оказывается сеть или политика sync=always, и деньги на диски потрачены зря. Тест занимает несколько часов, ошибочная закупка стоит на порядок дороже.

Надёжность проверяют отдельно от производительности. Массив может показывать отличные IOPS и при этом терять доступность на часы при отказе одного диска. Поэтому методика включает имитацию отказа диска и узла, а нагрузочными прогонами не ограничивается.

Методика тестирования: от постановки целей до интерпретации результатов

Рабочая методика состоит из шести шагов, и каждый фиксируется письменно. Такой подход делает результаты воспроизводимыми: через полгода коллега повторит прогон и получит сравнимые цифры.

1. Определить цели и критерии приёмки.
2. Выбрать сценарии нагрузки, отражающие реальные задачи.
3. Подготовить окружение: прогрев, отключение фоновых процессов, фиксация версий ПО.
4. Провести измерения, от трёх прогонов на сценарий.
5. Проверить надёжность: имитация отказов, мониторинг деградации и восстановления.
6. Проанализировать данные и оформить отчёт.

Порядок шагов нарушать не стоит. Тест надёжности на непрогретой или уже деградировавшей системе даёт результат, который сложно объяснить.

Определение целей и критериев приёмки

Бизнес-требование «база должна работать быстро» в критерий не превращается. Его переформулируют в измеримые показатели: 5000 IOPS при случайном чтении блоками 8 КБ, латентность 95-го перцентиля не выше 5 мс, пропускная способность последовательной записи не ниже 800 МБ/с.

Профиль нагрузки определяется приложением. Транзакционная СУБД генерирует много мелких случайных операций. Аналитическая система читает крупными блоками. Сервер резервного копирования пишет длинные последовательные потоки. Виртуализация смешивает всё сразу, и соотношение чтения к записи меняется в течение суток.

Такую таблицу согласуют с владельцем сервиса до начала работ. После согласования любое изменение критериев фиксируется отдельно, иначе результат всегда можно объявить неудачным.

Выбор сценариев нагрузки под реальные задачи

Каждому классу приложений соответствует свой набор параметров: rw (randread, randwrite, randrw, seqread, seqwrite), размер блока bs, глубина очереди iodepth, число параллельных задач numjobs.

• OLTP-база: randrw с долей чтения 70%, bs=8k, iodepth=32, numjobs=4, direct=1.
• Аналитика и бэкапы: seqwrite, bs=1m, iodepth=8, длительность от 30 минут.
• Файловый сервер: смесь seqread и randread, bs=128k.
• Виртуализация: randrw 50/50, bs=4k, высокий iodepth и много задач.
• Проверка надёжности: фоновая нагрузка плюс имитация отказа диска или узла.

Сценарии прогоняют в двух состояниях: на холодном кэше и после прогрева. Первый показывает поведение после перезагрузки или сброса кэша контроллера, второй отвечает на вопрос о стабильной работе. Разница между ними часто объясняет жалобы «утром всё медленно». Общий разбор типов тестов, включая benchmark, stress, soak и fault-injection, приведён в материале о методах нагрузочного тестирования вычислительных систем перед запуском.

Инструменты для нагрузочного тестирования: fio, vdbench, ioping

Три инструмента закрывают большинство задач. fio даёт гибкость и точные метрики, vdbench работает со сложными многопоточными и файловыми нагрузками, ioping выполняет быструю проверку латентности за считанные секунды. Как выбрать инструмент под конкретный класс задач, разобрано в статье об инструментах тестирования производительности серверов и инфраструктуры.

fio: гибкая настройка под любые профили нагрузки

Базовый запуск для случайного чтения: fio --name=randread --filename=/dev/nvme0n1 --rw=randread --bs=8k --iodepth=32 --numjobs=4 --direct=1 --runtime=300 --time_based --group_reporting.

Ключевые параметры:

• direct=1 обходит кэш страниц операционной системы и заставляет диск выполнять реальные операции, без него вы измеряете скорость памяти;
• iodepth задаёт число одновременных запросов в очереди, для NVMe значения 32 и выше раскрывают потенциал устройства, для одиночного HDD рост выше 1-2 почти ничего не даёт;
• numjobs создаёт параллельные процессы и имитирует несколько приложений;
• ramp_time исключает из статистики период прогрева, обычно достаточно 30-60 секунд;
• time_based вместе с runtime задают длительность прогона в секундах.

В отчёте смотрят не только средние значения. Строка iops показывает операции в секунду, bw пропускную способность в КБ/с, lat среднюю и максимальную задержку, clat percentiles распределение задержек по перцентилям. Медиана 1 мс при p99 в 80 мс означает редкие, но болезненные всплески, которые приложение заметит.

Пример смешанной нагрузки: fio --name=mix --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --direct=1 --runtime=600 --time_based.

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

vdbench: многопоточные и файловые нагрузки

vdbench применяют, когда нужно эмулировать десятки и сотни потоков или работать через файловую систему, а не через блочное устройство. Он полезен для тестирования NAS и распределённых хранилищ, где важна не только скорость дисков, но и поведение протокола NFS или SMB под множеством клиентов.

Минимальный сценарий описывается текстовым файлом с блоками sd (storage definition) и wd (workload definition). Для смешанной нагрузки на файловой системе задают anchor в каталоге /mnt/pool/test, число потоков threads=16, операции operations=read,write, размер sizes=4k, долю чтения read pct 70, seek pct 100 и время elapsed 600. Отчёт содержит IOPS, полосу и задержки по каждому потоку.

Плата за мощь - сложность. Синтаксис требует внимательного чтения, ошибка в разделе приводит к неверной интерпретации, а сам vdbench заметно нагружает CPU хоста, что на слабом сервере искажает измерения.

ioping: быстрая оценка латентности

ioping измеряет задержку отдельного запроса так же, как ping измеряет задержку пакета. Запуск: ioping -c 10 /dev/sdb для блочного устройства, ioping -c 10 /mnt/pool для файловой системы, ioping -R /dev/sdb для проверки последовательного доступа.

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

Ориентиры для исправного оборудования: SATA SSD 0,1-0,5 мс, NVMe 0,05-0,2 мс, HDD 5-15 мс. Значения в разы выше говорят о проблемах с диском, кабелем, контроллером или о фоновой нагрузке.

Проверка надёжности системы хранения: имитация отказов и мониторинг

Производительность под нагрузкой и устойчивость к отказам проверяют вместе. Рабочая практика: запустить fio в фоне и в этот момент вывести диск из строя. Система должна сохранить доступность данных, а метрики покажут реальную цену деградации.

Перед любыми экспериментами с отказами делают резервную копию и проверяют её восстановление. Если хранилище содержит единственную копию данных, имитация отказа превращается в потерю информации, а не в тест.

smartctl: проверка состояния диска

Команда smartctl -a /dev/sdX выводит все атрибуты S.M.A.R.T. и историю самотестов. Смотреть нужно на несколько полей:

• Reallocated_Sector_Ct (ID 5) - число переназначенных секторов; рост от нуля до десятков и сотен говорит о деградации поверхности;
• Current_Pending_Sector (ID 197) - секторы, чтение которых не удалось; любое ненулевое значение требует внимания;
• Offline_Uncorrectable (ID 198) - ошибки, найденные при фоновом сканировании;
• Temperature_Celsius (ID 194) - температура; для HDD выше 50 °C надёжность падает, для NVMe критичны значения выше 70 °C и троттлинг;
• Media_Wearout_Indicator или Percentage_Used у SSD - остаточный ресурс.

Пороги задают заранее: Current_Pending_Sector больше нуля, Media_Wearout_Indicator ниже 10%, устойчивый рост Reallocated_Sector_Ct за месяц. Для регулярного контроля настраивают опрос через smartd или сбор метрик в систему мониторинга. Проверка состояния диска идёт по расписанию, а не только во время тестов.

Имитация отказа диска в ZFS

ZFS позволяет сымитировать отказ без физического извлечения накопителя. Последовательность действий:

1. Зафиксировать базовые метрики: zpool status, zpool iostat -v 2, текущие IOPS и латентность.
2. Вывести диск из пула: zpool offline pool sdb.
3. Проверить состояние: zpool status покажет DEGRADED, а рядом с диском появится пометка OFFLINE.
4. Измерить производительность деградированного пула тем же профилем нагрузки.
5. Вернуть диск командой zpool online pool sdb или заменить его: zpool replace pool sdb sdc.
6. Наблюдать перестроение через zpool status и zpool iostat, фиксируя скорость resilver.

Во время resilver пул читает данные со всех живых дисков и пишет копию на новый. Скорость зависит от заполненности пула, типа дисков, нагрузки и параметров ZFS. На зеркалах из HDD перестроение десятков терабайт занимает сутки и больше, и всё это время производительность снижена на 30-70%.

Команда zpool iostat -v 5 показывает поток по каждому устройству и помогает увидеть, упирается ли восстановление в диск или в контроллер. Счётчики ошибок в zpool status (read, write, cksum) должны оставаться нулевыми.

Имитация отказа узла и оценка отказоустойчивости

Отказ узла проверяют тремя способами: отключением питания, разрывом сетевого соединения, остановкой сервиса хранилища. Каждый сценарий проверяет свой слой.

Ключевые метрики: время до восстановления доступа (failover time), объём потерянных или не подтверждённых операций, ошибки целостности после возврата узла, время полной синхронизации реплик. У распределённых хранилищ на Ceph или GlusterFS методика отличается: там оценивают состояние кластера (ceph -s), число PG в состоянии degraded или undersized и время обратного заполнения.

После восстановления узла проверяют целостность контрольных сумм, отсутствие разошедшихся реплик, корректность кворума, возврат всех дисков в строй и то, что фоновое восстановление не вывело систему из SLA по латентности.

Как интерпретировать результаты и оформить отчёт

Сырые числа превращаются в выводы тремя операциями. Первая: сравнение с критериями приёмки из согласованной таблицы. Вторая: анализ разброса между прогонами, если результаты отличаются больше чем на 10-15%, условия теста недостаточно стабильны. Третья: сопоставление метрик между собой, высокая средняя латентность при низких IOPS указывает на узкую очередь или медленный носитель, а рост IOPS без изменения латентности говорит о запасе производительности.

Перцентили важнее среднего. p99 в 50 мс при средней 1,5 мс означает, что один запрос из ста ждёт в тридцать раз дольше. Пользователь замечает именно такие всплески. Отчёт только со средними значениями не отвечает на вопрос о реальном опыте работы с системой.

Отдельно фиксируют условия: версии ОС и прошивок, модели дисков, тип RAID или топологию vdev, размер блока, direct, iodepth, длительность и число прогонов. Без этого данные не воспроизводимы. Алгоритм корректной интерпретации замеров разобран в статье о тесте производительности системы и корректной интерпретации результатов.

Шаблон отчёта о тестировании хранилища

Структура, которую можно копировать и заполнять. Разделы идут в таком порядке:

1. Титульный лист: название стенда, дата, версия отчёта, исполнитель, заказчик.
2. Цели и критерии приёмки: таблица метрик с целевыми значениями и допустимыми отклонениями.
3. Конфигурация: сервер, CPU, память, диски, контроллер, сеть, версии ОС и ПО, схема пулов.
4. Методика и инструменты: список утилит, параметры запуска, длительность, число прогонов, условия прогрева.
5. Результаты по сценариям: таблицы и графики с IOPS, латентностью (avg, p95, p99, max) и пропускной способностью.
6. Проверка надёжности: сценарии отказов, время реакции, скорость восстановления, ошибки целостности.
7. Выводы и рекомендации: соответствие критериям, узкие места, что изменить до продуктивной эксплуатации.
8. Приложения: сырые логи, вывод zpool status, снимки smartctl.

Раздел с результатами удобно оформлять таблицей: сценарий, IOPS, средняя латентность, p95, p99, пропускная способность, вердикт. Вердикт пишут словами: соответствует, соответствует с оговоркой, не соответствует.

Типичные ошибки при тестировании хранилищ и как их избежать

• Тест без прогрева. Решение: ramp_time 30-60 секунд или отдельный прогон перед замером, иначе первые секунды дадут завышенные цифры.
• Игнорирование кэшей. Кэш ОС, кэш RAID-контроллера с батареей и SLOG в ZFS искажают картину. Решение: direct=1 для блочных тестов и понимание того, куда физически пишутся данные.
• Неверный размер блока. Замер блоками 1 МБ для транзакционной базы даёт красивые цифры, которых в работе не будет. Решение: брать размер блока из профиля приложения.
• Короткий прогон. Тест на 30 секунд измеряет кэши. Решение: от 5 минут для мелких блоков и от 30 минут для последовательных операций.
• Отсутствие мониторинга. Без наблюдения за CPU, памятью и сетью непонятно, где узкое место. Решение: параллельно с fio снимать vmstat, iostat, sar и метрики сети.
• Фоновая активность. Обновление индексов, репликация или задача резервного копирования испортят замер. Решение: остановить лишние процессы или проводить тест в отдельном окне.
• Тест надёжности без резервной копии. Недопустимо. Решение: снимок или полная копия перед экспериментами с отказами.
• Единичный прогон. Решение: минимум три повтора и оценка разброса значений.

Большинство искажений связано с окружением, а не с инструментами. Материал о тестировании производительности компьютерных систем без искажения результатов помогает выстроить контроль условий, включая температуру, энергопотребление и стабильность стенда.

Адаптация методики под разные типы хранилищ

Блочные, файловые и сетевые хранилища тестируют по-разному.

Локальные диски и DAS дают самую чистую картину: нет сети, нет протокола, задержка определяется носителем и контроллером. Здесь достаточно fio и ioping, а основное внимание уделяют проверке заявленных IOPS при разной глубине очереди.

NAS добавляет сетевой слой и протокол. Монтирование по NFS или SMB меняет профиль: появляются задержки протокола, влияние MTU и скорости линка. Тестировать нужно с клиента, а не с сервера, иначе вы измеряете локальный диск. Полезно сравнить NFSv4.2 и SMB с разными размерами rsize и wsize, а затем посмотреть, как ведёт себя хранилище при 10-20 одновременных клиентах. Для TrueNAS и ZFS дополнительно применяют zpool iostat и zfs get all, чтобы проверить параметры sync, recordsize и compression.

SAN подразумевает блочный доступ по Fibre Channel или iSCSI и многопутевую конфигурацию. Отдельный сценарий - поведение при отказе одного пути (multipath failover): нагрузку запускают, затем отключают один путь и смотрят, выросла ли латентность и появились ли ошибки ввода-вывода. Проверяют также очередь на HBA и согласованность размеров блока между инициатором и массивом.

Распределённые хранилища (Ceph, GlusterFS, MinIO) тестируют и на уровне клиента, и на уровне кластера. Важны метрики восстановления, распределение данных по узлам и деградация при выключении одного сервера. Нагрузка от многих клиентов одновременно показывает реальную картину, а одиночный fio даёт завышенные результаты.

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

Практический старт выглядит так: возьмите критерии приёмки, прогоните три сценария fio, снимите smartctl со всех дисков, затем сымитируйте отказ диска и узла. Такой цикл закрывает основные риски и укладывается в один рабочий день.