Как провести стресс-тест сервера за сутки

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

Главная ошибка при приемке состоит не в выборе «слабой» утилиты. Инженеры запускают нагрузку, видят 100% CPU и через несколько часов объявляют сервер исправным. Процент загрузки ничего не говорит о машинных ошибках, коррекции ECC, целостности записи, троттлинге или провале одной линии питания. Испытание имеет смысл только тогда, когда у него есть исходный снимок, телеметрия во времени и правило, по которому конкретное отклонение ведет к повторной проверке либо замене компонента.

Как уложить полноценную проверку в 24 часа

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

1. Часы 0-1: сверка комплектации и прошивок, исходные журналы BMC, SMART, EDAC, температуры, обороты вентиляторов и показания блоков питания.
2. Часы 1-5: вычислительная нагрузка с короткими сменами алгоритмов, затем совместная нагрузка CPU и памяти.
3. Часы 5-11: проверка всего доступного объема RAM с контролем ECC и системного журнала.
4. Часы 11-18: тест каждого накопителя, сначала чтение, затем запись с проверочным шаблоном на дисках, которые разрешено перезаписать.
5. Часы 18-22: одновременная нагрузка CPU, RAM и дисков, контроль температур, частот, вентиляторов и мощности.
6. Часы 22-24: управляемая проверка резервирования питания, охлаждение, повтор подозрительного теста и итоговый снимок журналов.

Это расписание не требует, чтобы все серверы выполняли одинаковое число операций. Двухпроцессорная машина с большим объемом RAM и массивом из десятков дисков может не успеть сделать полный проход каждой ячейки и каждого сектора. Тогда приоритет получают целостность, ошибки контроллеров и совместная пиковая нагрузка. Объем фактически проверенных данных обязательно попадает в отчет. Фраза «память проверена» без числа проверенных байтов скрывает дыру в методике.

Перед запуском определите четыре ограничения. Первое, можно ли уничтожать данные на накопителях. Второе, допускает ли площадка отключение одного резервного блока питания. Третье, какая температура воздуха на входе в сервер. Четвертое, какие версии BIOS, BMC, прошивки контроллера и дисков утверждены для поставки. Если хотя бы один ответ неизвестен, отметьте исключение в программе испытаний. Нельзя тихо заменить разрушающий тест диска обычным чтением, а потом выдать оба режима за равноценные.

Сервер проверяют в той конфигурации, в которой он будет работать: те же модули памяти, HBA или RAID-контроллер, накопители, сетевые карты, блоки питания и профиль BIOS. Перестановка DIMM после теста обнуляет вывод о конкретном канале памяти. Обновление прошивки после теста требует хотя бы короткого повторного прогона, потому что меняются управление питанием, вентиляторы, обучение памяти и обработка ошибок.

Не тратьте все окно на установку инструментов. Подготовьте загрузочный образ, пакеты, job-файлы и скрипт сбора метрик заранее на машине той же архитектуры. Проверьте, что образ видит BMC, RAID-контроллер, NVMe и EDAC, а системное время синхронизируется без доступа к рабочей сети. В изолированном контуре репозитория может не быть, и четыре часа приемки исчезнут в поиске зависимостей. Версии утилит тоже входят в отчет: разные выпуски smartctl и stress-ng по-разному распознают новые устройства и датчики.

Нулевая точка отделяет новый дефект от старой записи

До нагрузки сохраните состояние сервера так, чтобы после испытания можно было вычислить приращение каждого счетчика. Абсолютное число ошибок без исходного значения часто обманывает. В журнале SEL может лежать событие, возникшее при сборке без подключенного вентилятора, а счетчик NVMe Error Information иногда содержит записи, не связанные с повреждением носителя. Основанием для решения становится новая запись во время вашего теста, ее тип и связь с нагрузкой.

Зафиксируйте серийные номера и расположение компонентов. Для DIMM нужна привязка к сокету, каналу и слоту, для диска к отсеку и идентификатору контроллера, для блока питания к позиции PSU1 или PSU2. Снимок одной команды lshw не заменяет эту карту: операционная система может показать устройство, но не всегда даст физический адрес, по которому техник найдет неисправную деталь.

Для Linux минимальный исходный набор можно снять такими командами:

ipmitool sensor list
ipmitool sel elist
smartctl -x /dev/sda
smartctl -x /dev/nvme0
journalctl -k -b

ipmitool sel elist полезнее короткого списка SEL, потому что расширенный вывод сопоставляет событие с записью Sensor Data Record и называет датчик. Руководство IPMItool именно так описывает режим elist. Сохраните сырой вывод, время на BMC и системное время. Если часы расходятся, последовательность «сначала перегрев, потом сброс» легко прочитать наоборот.

Для ECC снимите счетчики EDAC до и после испытания либо включите сбор через rasdaemon. Документация ядра Linux разделяет corrected, uncorrected, deferred и fatal errors. Это не четыре названия одного и того же события. Corrected error означает, что ECC исправила данные, а uncorrected сообщает, что исправить ошибку не удалось, даже если система пока продолжила работу. Deferred error может проявиться позже при обращении к отравленной области памяти. Поэтому общий счетчик «hardware errors» в отчете бесполезен, категории надо хранить отдельно.

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

Сделайте один холодный старт, а не только программную перезагрузку. При полном снятии питания BMC, контроллеры и накопители проходят иной путь инициализации, память заново обучается, а резервные блоки договариваются о распределении нагрузки. Именно здесь проявляются зависание POST, пропавший канал, долгий старт диска и ошибка батареи или суперконденсатора кеша. Если процедура запрещает снятие питания, укажите, что cold boot не проверен. Успешный warm reboot не покрывает этот риск.

Запишите температуру воздуха на входе, а не только датчик CPU. Сервер, который тестировали у открытой двери при 18 °C, нельзя честно сравнить с сервером в плотной стойке при 27 °C. Верхние пределы берите из документации конкретной платформы и процессора. Универсальная цифра вроде «до 80 °C нормально» плоха: у разных датчиков различаются место, допустимый предел и логика троттлинга.

Процессор проверяют по ошибкам и удерживаемой частоте

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

Для первого этапа я использую stress-ng. Его руководство прямо говорит, что режим verify проверяет результаты там, где стрессор это поддерживает, а thermalstat собирает показания доступных термозон Linux. Важно прочитать оговорку: verify работает не для каждого стрессора и сам снижает число операций. Поэтому «успешный exit code» не превращает все нагрузки в функциональный тест.

Простой двухчасовой прогон всех логических CPU можно начать так:

stress-ng -c 0 -t 2h

Параллельно раз в 10-30 секунд снимайте частоты по сокетам, package power, температуры, обороты вентиляторов и события ядра. Не ограничивайтесь средним значением. Дефект прижима радиатора или неудачная термопаста часто виден как один горячий сокет, раннее снижение частоты и более высокие обороты его вентиляторной зоны. Средняя температура двух сокетов прячет этот перекос.

Machine Check Architecture нужна именно для разбора таких эпизодов. Документация Intel перечисляет среди регистрируемых аппаратных событий ошибки системной шины, ECC, четности, кеша и TLB. Запись MCE не равна автоматическому приговору процессору: источник может находиться в памяти, шине или питании. Но новая uncorrected или fatal machine check во время приемки всегда переводит сервер в состояние «не принят» до локализации причины. Перезагрузка без объяснения тоже считается отказом, даже если второй запуск прошел.

Частота требует контекста. Сравнивайте ее не с рекламной максимальной частотой одного ядра, а с ожидаемым режимом для числа активных ядер, установленного power limit, профиля BIOS и температуры входящего воздуха. Краткий провал при смене фазы нагрузки нормален. Устойчивая «пила» вместе с достижением thermal trip, событием BMC или резким ростом вентиляторов указывает на охлаждение. Стабильно низкая мощность без перегрева чаще ведет к профилю BIOS, лимиту питания или прошивке.

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

Основания для остановки CPU-этапа просты: MCE категории uncorrected или fatal, вычислительная ошибка утилиты, зависание, самопроизвольная перезагрузка, недопустимая температура по спецификации платформы либо повторяющийся троттлинг, которого нет у эталонной конфигурации в тех же условиях. Одиночная corrected запись требует разбора и повтора, а не автоматического «годен».

Память обязана отдать больше, чем ноль ошибок утилиты

Проверка RAM состоит из записи и чтения шаблонов по максимально доступному объему плюс наблюдения за ECC на уровне контроллера памяти. Ноль ошибок в пользовательской программе не доказывает, что память чиста: ECC могла исправить бит до того, как процесс прочитал данные. Обратная ошибка тоже встречается, когда тест завершает OOM killer или гипервизор отбирает память, а техник записывает это как дефект DIMM.

На установленной ОС нельзя занять все физические байты. Ядро, драйверы и сама программа сохраняют часть RAM. Для первичной приемки удобно сочетать долгий проход stress-ng по виртуальной памяти с загрузочным тестом памяти, если программа испытаний позволяет перезагрузку. Загрузочный тест видит больше адресного пространства, а Linux лучше показывает EDAC, машинные ошибки и поведение реальной прошивки под совместной нагрузкой. Они дополняют друг друга.

Перед этапом запишите объем installed и usable memory, схему каналов, частоту, число ranks и наличие ECC. Проверьте журнал обучения памяти после холодного старта. Сервер может загрузиться с пониженной частотой или отключенным каналом и все равно показать «много памяти». Сравнение с паспортной конфигурацией ловит неправильную установку раньше стресс-теста.

Во время прогона следите за тремя независимыми признаками:

• программа сообщает mismatch или verify error с адресом;
• EDAC либо BMC увеличивает счетчик corrected, uncorrected, deferred или fatal;
• ядро фиксирует MCE, offlining страницы, сбой канала либо DIMM.

Документация Linux RAS аккуратно формулирует смысл corrected errors: система продолжает работать, потому что данные еще не повреждены, но профилактическая замена модуля с такими событиями может снизить риск будущего uncorrected error. Из этого не следует, что любой исторический CE требует выбросить DIMM. Для нового сервера практичный критерий строже: нулевое приращение CE во время приемочного окна. Новый повторяемый CE, привязанный к одному DIMM или каналу, служит основанием заменить модуль или проверить сокет и плату, даже если приложение не упало.

Uncorrected, deferred и fatal error означают остановку приемки. Сначала сохраните журналы, адрес, syndrome, label DIMM и фазу нагрузки. Затем повторите холодный старт и тест в контролируемой конфигурации. Если событие следует за DIMM после разрешенной перестановки, меняйте модуль. Если остается на канале или сокете, подозревайте разъем, процессор с контроллером памяти или системную плату. Такая локализация экономит повторные выезды: замена «первой попавшейся памяти» не лечит погнутый контакт сокета.

Скорость памяти используйте как диагностический фон, а не как универсальный порог годности. NUMA-размещение, число каналов, ranks, режим энергосбережения и алгоритм теста меняют пропускную способность. Полезнее сравнить симметричные узлы внутри сервера и одинаковые серверы одной спецификации. Отклонение одного сокета на заметную и воспроизводимую величину требует проверки схемы DIMM и NUMA, но процент допуска должен быть записан владельцем платформы до теста.

Диск принимают после проверки данных, а не графика скорости

Накопитель может показать ожидаемые IOPS и при этом возвращать поврежденные блоки. Поэтому приемочный тест диска должен разделять производительность, целостность данных и здоровье носителя. График задержки отвечает на вопрос «как устройство обслуживает запросы», verify отвечает «вернулись ли записанные байты», а SMART и журналы контроллера объясняют аппаратные события. Ни один из этих источников не заменяет остальные.

Сначала снимите smartctl -x для каждого физического диска. Для RAID понадобятся синтаксис и утилита конкретного контроллера, потому что /dev/sda может оказаться виртуальным томом. Сохраните media and data integrity errors, available spare, critical warning и unsafe shutdowns у NVMe; для SAS и SATA сохраните error log, self-test log, reallocated, pending и uncorrectable sectors, если устройство публикует эти поля. Названия и смысл атрибутов отличаются, поэтому нельзя применять одну таблицу порогов ко всем протоколам.

Руководство smartctl уточняет важную деталь: расширенный SMART-тест может идти от десятков минут до нескольких часов, а результат надо читать в self-test log. Команда запуска сама по себе не является результатом:

smartctl -t long /dev/sda
smartctl -l selftest /dev/sda

Для чистого диска или выделенного тестового раздела fio позволяет записать шаблон и проверить его при чтении. Документация fio выделяет verification как отдельный режим и предупреждает: read workload с verify ожидает ранее записанный файл. Я использую явный job-файл, чтобы в отчете остались параметры:

[global]
ioengine=libaio
direct=1
filename=/dev/nvme0n1
verify=crc32c
verify_fatal=1
group_reporting=1

[write_verify]
rw=write
bs=1M
size=100%
do_verify=1

Этот пример уничтожит содержимое указанного устройства. Перед запуском второй инженер должен сопоставить filename с серийным номером и отсеками, а не только с нестабильным именем /dev/nvme0n1. На сервере с данными замените устройство на заранее созданный тестовый файл или ограниченный свободный раздел, но честно запишите долю проверенной поверхности. Тест файла не проверяет блоки вне него.

После последовательного прохода добавьте смешанную случайную нагрузку с глубиной очереди, близкой к предполагаемой работе, и соберите не только средние IOPS. Нужны bandwidth, ошибки, средняя и хвостовая задержка, глубина очереди, температура диска и события контроллера. Конкретный предел p99 задает проект: массив для базы данных и архивный HDD имеют разные требования. На приемке важны также выбросы одного диска среди одинаковых. Повторяющиеся таймауты, reset controller, выпадение линка или резкий рост задержки одного устройства нельзя списывать на «особенность SSD».

Кеш контроллера меняет картину. Короткая запись может полностью поместиться в защищенный кеш и показать скорость, которой массив не удержит. Записывайте объем, превышающий кеш, и дождитесь установившегося режима. Проверьте, что политика write back действительно защищена батареей или суперконденсатором, если это предусмотрено конфигурацией, а событие о неисправной защите не спрятано в журнале контроллера. Не переключайте write through на write back только ради результата: приемка должна измерять утвержденную безопасную настройку.

Безусловный отказ дают verify mismatch, новые media or data integrity errors, uncorrectable sectors, выпадение диска из массива или неуспешный extended self-test. Рост reallocated или pending sectors у нового SATA-диска тоже ведет к замене. Один NVMe error log entry без декодирования недостаточен: некоторые записи сообщают о неподдержанной команде. Смотрите status field, счетчик до теста и после, журнал ядра и совпадение по времени.

Питание проверяют под общей нагрузкой

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

Через BMC собирайте input power, output power, токи или статус каждого PSU, напряжения, температуры входа и выхода, fan RPM, redundancy state и SEL. Набор датчиков зависит от платформы. Отсутствующее показание нельзя превращать в ноль; в отчете ставят «датчик не предоставлен». Ноль ватт у работающего блока может означать ошибку чтения, прошивку BMC или реально неразделенную нагрузку.

Смотрите на форму перехода. При включении дисковой записи мощность растет, вентиляторы реагируют с задержкой, температура выходит на плато. Если частота CPU падает одновременно с Power Unit redundancy lost или voltage threshold event, сначала разбирайте питание, а не охлаждение. Если растет температура входа для всей стойки, причина может лежать в рециркуляции горячего воздуха, а не в сервере.

Проверка резервирования означает физическое отключение одного ввода только для сервера с независимыми БП, независимыми линиями и подтвержденным запасом мощности каждого блока. Ее выполняет специалист площадки по согласованной процедуре. Не выдергивайте кабель из единственного источника, не работайте внутри блока и не имитируйте отказ на нагруженной производственной стойке. Суточная приемка не оправдывает риск для людей и соседнего оборудования.

При разрешенном тесте сначала убедитесь, что нагрузка распределена между PSU и каждый ввод способен нести текущий максимум. Отключите одну линию, проверьте отсутствие перезагрузки и ошибок, дождитесь корректного события потери резервирования, восстановите питание и повторите для второй линии. Сервер должен вернуть состояние redundancy restored. Неверное событие SEL тоже дефект приемки: без точного сигнала эксплуатация не узнает о работе на одном блоке.

Колебание мощности само по себе не основание для замены. Основаниями служат выход напряжения за порог платформы, отказ блока, потеря нагрузки при переключении, перезагрузка, запах или шум электрического дефекта, повторяемое событие power fault и невозможность восстановить резервирование. При запахе, дыме, искрении или аномальном нагреве немедленно снимите нагрузку по аварийной процедуре площадки. Не запускайте повтор ради красивого лога.

Решение о замене должно быть записано до запуска

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

В этой матрице намеренно нет правила «любая температура выше X означает брак». Число X принадлежит спецификации конкретного датчика и платформы. Нет и общего допуска IOPS. Для однородной партии полезны медиана и диапазон эталонных серверов, но эталон тоже должен пройти функциональные критерии. Быстрый сервер с повреждением данных остается неисправным.

Различайте замену компонента и непринятие сервера. Ошибка, которая четко следует за одним диском или DIMM, обычно ведет к замене детали и повтору затронутых этапов. Событие на канале памяти, повторяющийся reset нескольких дисков за одним контроллером или синхронный провал двух PSU указывает на общий узел. Тогда замена отдельных конечных устройств только замаскирует причину.

Статус «условно годен» допустим для документированного ограничения методики, например когда политика запретила разрушающую запись на уже подготовленный массив. Он не подходит для необъясненной аппаратной ошибки. Пишите «проверено чтением 100% LBA, запись с verify не выполнялась», а не «диски прошли стресс-тест». Заказчик сможет решить, принять ли остаточный риск.

GSE при поставке серверов S200 Series контролирует жизненный цикл оборудования от производства до поддержки, поэтому такую матрицу удобно согласовать вместе с конфигурацией и протоколом приемки. Она полезна и для любой другой платформы: критерии должны ссылаться на спецификацию именно поставленного узла, а не на привычку инженера.

Отчет должен воспроизводить каждый вывод

Хороший отчет позволяет другому инженеру повторить не весь день, а ровно тот эпизод, на котором возникло отклонение. Для этого недостаточно скриншота зеленого окна. Нужны идентификаторы оборудования, условия, точные параметры нагрузки, временные ряды и необработанные журналы.

В шапке укажите модель и серийный номер сервера, состав по слотам, версии BIOS, BMC и прошивок, настройки профиля производительности, ОС и ядро, дату, место в стойке и температуру входящего воздуха. Отдельно запишите, какие функции не проверялись: второй сетевой порт, GPU, конкретный HBA, горячая замена вентилятора. Пробел в охвате лучше скрытого предположения.

Для каждого этапа запишите начало и конец, команду или job-файл, объем обработанных данных, статус завершения и ссылки внутри комплекта отчета на сырой лог. Снимайте метрики с единым временем. Формат CSV или JSON удобнее картинки: по нему можно найти максимум, построить ряд и сравнить два прогона. Скриншот BMC оставьте как дополнение, если он подтверждает физическое расположение датчика.

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

Итоговая строка для этапа должна содержать измерение и критерий. «Температуры нормальные» ничего не доказывает. Запись «CPU1 max 76 °C при inlet max 25 °C, порог платформы 85 °C, thermal events 0» проверяема. Числа здесь показывают форму записи, а не универсальные пределы для вашего сервера. Подставьте фактические показания и официальный лимит модели.

Приложите исходный и итоговый вывод SEL, SMART и EDAC, даже когда разница равна нулю. Для счетчиков укажите формулу delta = after - before. Если BMC очищали, приложите журнал до очистки и время команды. Для дисков свяжите имя устройства, WWN или serial и физический slot. Для памяти свяжите EDAC label с маркировкой слота из сервисного руководства.

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

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

Суточный тест ловит ранний брак, но не заменяет эксплуатацию

Даже чистые 24 часа не предсказывают износ вентилятора, деградацию флеш-памяти через годы или ошибку прошивки при редкой рабочей комбинации. Приемка снижает риск раннего отказа и неверной сборки. Дальше нужны постоянный сбор SEL, SMART, ECC, температур и событий питания, плановые self-tests накопителей и проверка резервирования по регламенту площадки.

Суточное окно можно расширить там, где цена отказа высока или полный проход физически не помещается. Большой объем RAM заслуживает нескольких проходов, HDD большого размера требует времени на extended self-test и полную запись, GPU и сетевые ускорители добавляют свои нагрузки. Не ускоряйте проверку повышением температуры или отключением защиты. Так вы меняете условия из приемочных в разрушительные и можете потерять гарантийно значимую картину.

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

После чистого прогона сохраните комплект как эталон для конкретного серийного номера. Через месяц эксплуатации новые corrected ECC, рост media errors или изменение температурного разрыва можно сравнить с этой точкой, а не с памятью дежурного инженера. Если же тест дал повторяемое аппаратное событие, не торгуйтесь с логом ради срока запуска. Сутки уже окупились: дефект проявился там, где замена еще плановая, а не аварийная.