Приемочные тесты дисков на серверах: fio/DiskSpd и пороги

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

Паспортным цифрам доверять недостаточно. Их обычно снимают в лабораторных режимах (часто в красивом сценарии вроде последовательного чтения). В реальной жизни нагрузка смешанная: мелкие блоки, параллельные потоки, очередь запросов, фоновая очистка SSD, кэши контроллера, RAID, файловая система. Поэтому диск может быть «быстрым по паспорту», но давать задержки, от которых страдают СУБД, виртуализация и файловые сервисы.

Приемка ловит типовые проблемы поставки и совместимости: пересорт (не та модель или объем), неподходящая прошивка, разные ревизии в одной партии, деградация после хранения, перегрев в корзине, а иногда и банальный брак. В серверных конфигурациях это критично: один «плохой» диск в массиве легко портит картину целиком.

Чаще всего вскрывается не нехватка максимальной скорости, а нестабильность. Например, из 8 новых SSD один может периодически давать всплески задержки до сотен миллисекунд при записи. На файловом сервисе это выглядит как «подвисания», а в кластере виртуализации - как фризы ВМ и рост времени отклика приложений. Такой диск нередко проходит поверхностную проверку SMART, но проваливает нагрузку.

Чтобы приемка не превращалась в гадание, заранее договоритесь, какие показатели фиксируете:

• производительность (IOPS и MB/s) в нужных режимах
• задержки (средняя и p95/p99/p99.9)
• стабильность по времени (нет ли просадок и «пилы»)
• ошибки ввода-вывода, timeouts, resets
• разброс между дисками в одной партии

Дальше все упирается в два вопроса: какие профили нагрузки ближе к вашим сервисам и какие пороги считать браком, а не «особенностью настроек».

Перед тестами: что влияет на результаты и как не перепутать уровни

Результаты легко испортить еще до запуска fio или DiskSpd. Начинайте не с команд, а с фиксации условий: какой накопитель, какой контроллер, на каком уровне меряем и какие кэши включены.

Ожидания сильно зависят от типа диска. NVMe обычно дает низкую задержку и высокий IOPS. SATA SSD упирается в интерфейс и контроллер. SAS часто ведет себя стабильнее под длительной нагрузкой. HDD хороши в последовательных задачах и резко проседают на случайных. Если сравнивать все как одно и то же, вы либо «забракуете» нормальный HDD, либо пропустите проблемный SSD.

Отдельная тема - RAID/HBA и кэш. Write-back легко рисует красивые цифры, пока запись идет в кэш контроллера, а не на носитель. Write-through честнее, но медленнее. Важна защита кэша (BBU или суперконденсатор): без нее кэш записи часто отключают, и поведение системы меняется. Перед тестом явно зафиксируйте режим кэша и политику записи.

Файловая система тоже влияет. Тест «в файл» зависит от FS, размера блока, параметров монтирования и фоновых задач. Тест по блочному устройству ближе к «железу». Для приемки полезно понимать, что именно вы проверяете: сам диск, стек хранения или схему «как будет в проде».

Параллелизм задает картину нагрузки. Очередь (QD) и число потоков (numjobs) могут как раскрыть накопитель, так и спрятать дефект. Слишком маленькая очередь занижает IOPS, слишком большая раздувает очереди до десятков миллисекунд и иногда маскирует редкие провалы.

Перед запуском зафиксируйте:

• тип диска и интерфейс (SATA/SAS/NVMe), объем, прошивку
• режим контроллера (RAID/HBA), write-back/write-through, наличие BBU/суперкапа
• уровень теста: файл на FS или блочное устройство, что и как форматировали
• параметры нагрузки: block size, QD, numjobs, длительность прогрева
• фон: ребилд RAID, scrub, обновления, телеметрия

И не путайте уровни измерения. Один и тот же диск может выглядеть по-разному:

• на физическом диске (минимум «магии»)
• на томе RAID/массива (влияние кэша и политики)
• на LUN/томе ОС (драйверы и планировщик)
• внутри гостевой ВМ (виртуальные очереди и лимиты гипервизора)

Если вы принимаете серверы и СХД как интегратор, практичный подход - прогнать тест на двух уровнях: «железо» (чтобы искать брак) и «как будет работать» (чтобы подтвердить ожидаемую производительность в эксплуатации).

Подготовка стенда и правила безопасности тестирования

Сначала решите, что именно проверяете: отдельный диск, RAID-группу или весь путь хранения (диск - контроллер - драйвер - ОС - файловая система). Если смешать уровни, результаты будут «гулять», и дефект легко пропустить.

Инструменты и наблюдение за системой

Минимальный набор простой: fio для Linux, DiskSpd для Windows и мониторинг. Во время прогона смотрите не только скорость, но и признаки проблем: рост задержек, ошибки контроллера, перегрев, перераспределенные блоки.

Для мониторинга обычно хватает штатных средств ОС и утилит контроллера/дисков: SMART/NVMe log, журнал событий, загрузка CPU, очередь диска, температура, I/O errors. Полезно заранее включить сбор логов, чтобы потом привязать провал теста к конкретной минуте.

Чтобы не путаться в железе, договоритесь об именовании до первого запуска. Удобный формат: сервер - слот/бэй - серийный номер - роль диска (OS, DATA, LOG, CACHE). Например: SRV-DB01 BAY03 S/N XXXXX DATA.

Также заранее зафиксируйте среду, иначе сравнивать будет нечего: версия ОС и план питания, драйверы и прошивки (контроллер, диск), режим RAID и stripe size, политика кэша, файловая система и размер блока (если тестируете на уровне тома).

Прогрев и стабилизация (precondition)

Новые SSD часто показывают «витринные» цифры, пока свободны и холодные. Для приемки нужен прогрев: заполнение и нагрузка до выхода на стабильные задержки. Для большинства SSD разумный минимум - 30-60 минут тяжелой записи (или заполнение 1-2 раза), затем пауза 5-10 минут и только потом замеры.

Главное правило безопасности: тестируйте только на пустом диске или тестовом томе. Один неверный параметр (не тот диск, не тот путь) - и данные потеряны.

Перед стартом введите стоп-правила:

• не запускать тест на прод-томах и на LUN с важными данными
• перед запуском перепроверять, что именно будет перезаписано (путь/буква/диск)
• отключать фоновые задачи, которые искажают картину (бэкапы, антивирус-скан)
• контролировать температуру и обдув (особенно NVMe в плотных корзинах)
• если пошли I/O errors, остановить прогон и сохранить логи

Так стенд станет предсказуемым, а результаты - сравнимыми между партиями дисков и серверами.

Пошаговая схема приемочных тестов fio и DiskSpd

Лучше держаться одной и той же схемы, чтобы сопоставлять результаты между партиями, моделями и стендами.

1) Выберите сценарий и цель

Определите уровень: отдельный диск, RAID-группа, том в SAN или datastore гипервизора. Затем выберите профиль, близкий к реальным сервисам: СУБД (мелкие блоки и низкая задержка), файловый сервис (смешанные блоки и последовательность), виртуализация (сильная смесь чтения/записи и высокий параллелизм).

2) Прогрев и базовая проверка стабильности

Перед измерениями сделайте прогрев: запись по всему объему тестового файла/тома и короткий прогон, чтобы скорость вышла на плато. Если график скачет, а задержка идет «пилой», это уже сигнал.

Дальше держитесь простых правил:

• прогоняйте несколько размеров блока (4K, 8K, 64K, 1M) и несколько глубин очереди (например, QD 1, 4, 16, 32), чтобы увидеть и «однопоток», и пик
• фиксируйте не только IOPS/MB/s, но и хвост задержек (p95, p99, p99.9)
• отслеживайте редкие «паузы» в сотни миллисекунд: они убивают СУБД и VDI даже при хороших средних значениях
• сохраняйте артефакты: логи fio/DiskSpd, конфигурацию стенда, SMART и системные журналы

Повторяемость обязательна: сделайте 2-3 одинаковых прогона и принимайте решение по медиане, а не по лучшему результату.

Пример минимальных команд (подставьте свой путь и размер):

fio --name=rand4k --filename=/mnt/testfile --size=50G --direct=1 --rw=randrw --rwmixread=70 \
 --bs=4k --iodepth=16 --numjobs=4 --time_based --runtime=180 --group_reporting \
 --output=fio_rand4k_mix.json --output-format=json

DiskSpd.exe -b4K -d180 -W30 -o16 -t4 -r -w30 -Sh -L C:\test\testfile.dat

Какие метрики считать приемочными: что важно и почему

В приемке важны не рекорды, а предсказуемость. Диск может показать высокий средний результат и при этом периодически «проваливаться» на секунды. Именно это потом превращается в зависания СУБД, тормоза виртуальных машин и очереди на файловом сервере.

Производительность: IOPS, latency и MB/s

IOPS полезны для мелких блоков (4K-16K) и случайного доступа, но смотрите не только «среднее за прогон». Проверяйте стабильность по времени: резкие падения на одинаковой нагрузке часто указывают на троттлинг, кэширование, прошивку или дефект.

Задержка почти всегда важнее IOPS. Среднее значение легко прячет редкие, но болезненные задержки, поэтому в отчете фиксируйте p95/p99/p99.9. Для виртуализации и БД именно p99 и p99.9 чаще объясняют жалобы пользователей.

Пропускная способность (MB/s) важна для последовательных потоков и крупных блоков (128K-1M): бэкапы, выгрузки, сканирование больших файлов. Если throughput «пилит» при постоянной нагрузке, это похоже на SLC-кэш, перегрев или проблемы контроллера.

Надежность: ошибки и температура

Любые ошибки важнее «чуть ниже IOPS». Отмечайте read/write errors, timeout, reset, media errors, а для SSD - изменения счетчиков ошибок в SMART. Даже единичные timeouts под нагрузкой потом превращаются в проблемы RAID, файловой системы или гипервизора.

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

Что полезно приложить к отчету:

• логи fio/DiskSpd (желательно с перцентилями и разбиением по времени)
• SMART до и после
• события ОС о reset/timeout (если были)
• температуру NVMe в ходе прогона
• версию драйвера и прошивки контроллера, режим питания

Типовые профили тестов под базы данных

У баз данных обычно две разные нагрузки: мелкие случайные операции (OLTP) и большие последовательные чтения (аналитика). Плюс журналы транзакций, где важны ровная задержка и отсутствие редких длинных пауз. Поэтому лучше сделать несколько коротких, но точных профилей, чем один «универсальный».

Быстрый набор для среза и сравнения партий:

• 4K random read: QD 1 и QD 32, 1-4 потока (смотрите IOPS и p99)
• 4K random write: QD 1 и QD 32, 1-4 потока (смотрите p99 и «ступеньки»)
• 70/30 random (read/write): блок 8K, QD 8-32, 4-8 потоков (типичный OLTP)
• mixed 16K: 50/50 или 70/30, QD 8-16 (когда часть запросов тяжелее 8K)

Для аналитики проверьте последовательное чтение 64K-1M с QD 4-16 и убедитесь, что throughput держится ровно. Для журналов транзакций выделите отдельный тест: 4K-16K sync write, небольшая очередь (QD 1-4), 1 поток. Здесь важнее предсказуемость, чем пик.

Типовые профили тестов под файловые сервисы

Файловые сервисы (SMB/NFS) нагружают диск иначе, чем БД: больше последовательного чтения больших файлов, «офисная» смесь и всплески по мелким файлам. Эти режимы лучше проверять отдельно.

Базовые профили

1. Последовательное чтение больших файлов (бэкапы, медиа, образы):

fio --name=seqread --filename=/mnt/testfile --size=200G --direct=1 \
  --rw=read --bs=1M --iodepth=32 --numjobs=4 --runtime=180 --time_based \
  --group_reporting

2. «Офисная» смесь: случайный доступ 64K с преобладанием чтения (ловит проблемы, когда скорость нормальная, а задержки скачут):

fio --name=mix64k --filename=/mnt/testfile --size=100G --direct=1 \
  --rw=randrw --rwmixread=80 --bs=64K --iodepth=16 --numjobs=4 \
  --runtime=300 --time_based --group_reporting

3. Много мелких файлов: здесь важны IOPS и «хвост» задержек, поэтому поднимайте параллелизм (numjobs/iodepth) и обязательно фиксируйте p95/p99.

На Windows тот же смысл можно повторить DiskSpd, например для 64K 80/20:

DiskSpd.exe -c100G -d300 -Sh -L -o16 -t4 -b64K -r -w20 C:\testfile.dat

Полезная проверка конкуренции: запустите одновременно последовательное чтение (1M) и случайную запись (4K-16K). Так видно, «проваливается» ли чтение, когда рядом идут записи.

Оговорка про SMB/NFS

Сначала тестируйте диск/том на сервере (fio/DiskSpd), и только потом сам SMB/NFS с клиента. Иначе будет непонятно, где узкое место: диск, CPU, сеть, настройки протокола, антивирус или шифрование.

Типовые профили тестов под виртуализацию и VDI

Виртуализация почти никогда не бывает «чистым» чтением или записью. Обычно это смесь мелких случайных операций, где важнее стабильная задержка, чем максимальный IOPS.

Профиль 1: смешанная нагрузка «обычная виртуализация»

70/30 или 60/40 read/write, блок 8K (допустимо 4K-16K), высокий параллелизм:

fio --name=virt-mix --filename=/dev/nvme0n1 --direct=1 --ioengine=libaio \
 --rw=randrw --rwmixread=70 --bs=8k --numjobs=8 --iodepth=32 \
 --time_based=1 --runtime=300 --group_reporting=1 --lat_percentiles=1

Затем сделайте короткую «лесенку по очереди»: iodepth 1, 4, 8, 16, 32. Если p99 latency прыгает ступенями, это часто выдает проблемы с прошивкой, контроллером или перегрев.

Профиль 2: VDI (важен строгий p99)

80/20 read/write, 4K, много потоков, но без запредельного iodepth:

fio --name=vdi-boot --filename=/dev/nvme0n1 --direct=1 --ioengine=libaio \
 --rw=randrw --rwmixread=80 --bs=4k --numjobs=16 --iodepth=16 \
 --time_based=1 --runtime=300 --group_reporting=1 --lat_percentiles=1

Если p99 «уплывает», пользователи увидят это как подвисания при логине или открытии профиля, даже когда средняя задержка выглядит нормально.

Профиль 3: плотная консолидация (много ВМ одновременно)

Увеличивайте numjobs (например, 24-48), но следите, чтобы не упереться в CPU тестовой машины. Параллельно смотрите загрузку процессора и очереди.

Если есть RAID/HBA с кэшем, прогоните один и тот же профиль дважды: с write-back и с write-through. Сильная разница по задержкам и особенно по p95/p99 - признак того, что в бою поведение будет зависеть от настроек кэша и наличия BBU/суперконденсатора.

Пороги приемки: как задать значения, чтобы ловить брак

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

Какие значения имеет смысл контролировать

Не ограничивайтесь средними. Для большинства ролей важнее хвосты задержек и стабильность:

• IOPS и MB/s по каждому профилю (и повторяемость между прогонами)
• p99, а для критичных ролей еще и p99.9 (отдельно read и write)
• просадки по времени относительно медианы (например, по минутам)
• нулевая терпимость к I/O errors, timeouts, resets, media errors
• температура и признаки троттлинга

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

Как выставлять пороги: от эталона и от роли

Надежнее задавать пороги в два слоя: от эталонного экземпляра (или проверенной партии) и от требований роли.

• Эталон: 1-2 проверенных диска той же модели, те же профили, затем допустимое отклонение (например, не хуже 10-15% по медиане и не хуже 20-30% по p99).
• Партия: сравнение дисков между собой. Экземпляр, который стабильно хуже группы по p99 или по стабильности, подозрителен даже при «формальном прохождении».
• Роль: для СУБД пороги по p99/p99.9 жестче, для файловых сервисов обычно важнее ровный throughput на последовательных тестах.
• Стабильность: регулярные провалы (например, каждые 3-5 минут падение IOPS на 30%+) - повод для разбирательства до ввода в работу.

По температуре смотрите связку: рост температуры плюс падение IOPS или рост p99. Если это повторяется в одинаковых условиях, фиксируйте как троттлинг и учитывайте в порогах (или меняйте обдув, если в реальной стойке он будет другим).

Частые ошибки и ловушки при приемке

Даже хорошие тесты легко испортить условиями запуска. Тогда «плохой» диск выглядит нормальным, или наоборот вы бракуете исправный.

Самые частые причины ложных результатов:

• тестовый файл слишком маленький и попадает в кэш (ОС, контроллер, кэш SSD)
• тест идет слишком мало времени и не показывает garbage collection, прогрев, SLC-кэш и троттлинг
• том занят фоновыми задачами (антивирус, индексация, бэкапы, репликация)
• путаница в единицах (MB/s vs MiB/s) и метриках (IOPS без размера блока ничего не означает)
• сравнение «несравнимого»: разные драйверы/прошивки, другой режим RAID, другой кэш, разные QD и потоки

Отдельная ловушка - делать вывод о конкретном диске, измеряя массив. Деградация может быть в контроллере, кабеле, слоте, backplane или настройках питания.

Практический пример: два одинаковых сервера показывают разные результаты на чтении 4K. Разбор часто упирается в то, что на одном включен write-back с BBU и стоит другой драйвер RAID, а на втором кэш записи отключен после обновления прошивки.

Еще один «бытовой» момент, который спасает время: фиксируйте серийные номера дисков, версии прошивок, модель контроллера и его прошивку. Без этого вы не сможете повторить тест и быстро локализовать проблемный экземпляр, особенно когда диски переставляют между серверами или площадками.

Чеклист, мини-шаблон отчета и короткий пример

Чтобы результаты были сравнимыми и пригодными для споров с поставщиком, держите короткий чеклист и простой шаблон отчета.

Чеклист перед стартом

• Зафиксировать конфигурацию: RAID/HBA, версии BIOS/прошивок, режимы контроллера (write-back/write-through), политики кэша.
• Убедиться, что тестируете нужный уровень: диск, массив или LUN, и что нет ребилда/скраба.
• Выбрать одинаковый объем тестового файла (часто берут 1.5-2x ОЗУ, чтобы не упереться в кэш).
• Сделать прогрев выбранным профилем перед замером.
• Проверить охлаждение и питание: температура дисков и контроллера должна быть нормальной до и во время теста.

Мини-шаблон отчета

Отчет должен позволять повторить тест и быстро найти «плохой» экземпляр:

• Идентификация: модель, емкость, тип (HDD/SATA SSD/NVMe), серийный номер, слот/порт, дата, партия.
• Среда: сервер, ОС, драйвер, версия fio/DiskSpd, параметры теста (блок, глубина очереди, потоки, время, размер файла).
• Настройки хранения: RAID-уровень, stripe size, кэш контроллера, файловая система, mount-опции.
• Результаты: IOPS, MB/s, средняя задержка и p95/p99/p99.9, стабильность по времени, температуры.
• Вывод: «годен/условно/брак», что перепроверяли.

Доказательства лучше прикладывать сразу: сырые логи fio/DiskSpd (текст/JSON), отметки метрик по времени (хотя бы из мониторинга), а также системные журналы по ошибкам диска/контроллера.

Пример из практики: в стойковом сервере из партии 12 одинаковых SSD один диск показывает нормальные IOPS, но p99 задержка в 3-5 раз выше и видны «зубцы» каждые 30-60 секунд. Первый шаг - повторить прогон на том же слоте. Затем переставить диск в другой слот (чтобы исключить порт/кабель/backplane). Если проблема «едет» вместе с диском, фиксируйте как брак и оформляйте замену.

Если вы принимаете серверы и СХД в рамках внедрений, удобно заранее согласовать единый шаблон отчета, пороги и порядок перепроверки. В проектах, где поставку и интеграцию берет на себя GSE.kz (gse.kz), такая стандартизация особенно помогает: меньше спорных случаев, быстрее диагностика и понятнее эксплуатация после запуска.