Burn-in тест сервера перед продакшеном: утилиты и критерии

Что проверяет burn-in и почему он нужен перед продакшеном

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

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

Чаще всего burn-in помогает выявить проблемы, которые потом выглядят как «редкие и непонятные»:

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

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

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

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

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

Зафиксируйте минимум:

• модель и серийный номер шасси, а также серийные номера ключевых узлов (если доступны);
• конфигурацию CPU, объем и схему установки RAM (по слотам);
• состав накопителей и контроллера, RAID-уровень (если уже настроен);
• сетевые карты и их порты (скорости, типы подключений);
• версии BIOS/UEFI, BMC, прошивок контроллера и NIC.

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

Обратите внимание на:

• температуру в серверной и свободный приток воздуха (нет ли перекрытых решеток);
• подключение к ИБП и режим питания (один/два блока, разные вводы);
• схему сети: куда подключен сервер, какие коммутаторы, какие VLAN;
• базовые настройки: профиль питания в BIOS, режим вентиляторов, включен ли ECC.

Длительность и набор нагрузок выбирайте под задачу. Для типового ввода часто хватает 4-12 часов, но если сервер будет считать данные или крутить виртуализацию, добавьте упор на CPU/RAM и сеть.

Если это, например, новый rack-сервер уровня GSE S200 Series для кластера, заранее решите, что важнее в приемке: стабильная температура под полной нагрузкой или предсказуемая пропускная способность сети. Тогда и сценарий теста, и критерии «годен/не годен» будут прозрачнее.

Что мониторить во время теста: показатели и источники логов

Во время burn-in важно не только «нагрузить железо», но и постоянно смотреть, как оно себя ведет. Большая часть проблем проявляется не как явный «FAIL» в утилите, а как перегрев, троттлинг, редкие аппаратные ошибки или внезапные перезагрузки.

Тепло, питание и охлаждение

Начните с термокартины: температуры CPU, VRM (если доступно), чипсета, дисков, плюс обороты вентиляторов. На Linux часто хватает lm-sensors, а для чтения данных с BMC удобен ipmitool (температуры, fan RPM, события).

Тревожные признаки:

• частота процессора заметно падает под стабильной нагрузкой;
• в логах есть сообщения о thermal throttling;
• вентиляторы постоянно «пилят» обороты, а температура скачет;
• появляются события по питанию (если BMC их фиксирует).

Аппаратные ошибки и системные события

Даже если тесты продолжают выполняться, аппаратные ошибки могут копиться в фоне. На Linux проверяйте kernel log и dmesg на MCE (Machine Check Exception), ошибки PCIe, таймауты устройств, сбои драйверов. На Windows смотрите Event Viewer: WHEA-Logger, BugCheck, Disk, Ntfs.

Короткий минимум, который стоит фиксировать по времени (с таймстампами):

• температура и частоты CPU, факт троттлинга;
• события IPMI/BMC (SEL): перегрев, питание, вентиляторы;
• dmesg/journalctl или Event Viewer по аппаратным ошибкам;
• SMART по дискам (smartctl) и рост reallocated/pending/CRC;
• перезагрузки, зависания, «отвал» сети, ошибки драйверов.

Если, например, через 40 минут нагрузки появляются MCE и затем перезагрузка, это уже не «случайность», даже если часть тестов успела завершиться. Связка «метрики + системные логи + события BMC» помогает быстро сузить поиск и дает нормальную доказательную базу.

Набор утилит для CPU: чем грузить и что считать проблемой

Цель CPU-теста проста: надолго загрузить все ядра на 100% и убедиться, что система не уходит в ошибки под теплом и питанием. Важно проверять не только «держит ли нагрузку», но и нет ли скрытых аппаратных сбоев, которые проявляются через час, а не через 5 минут.

Для нагрузки чаще всего используют несколько классов утилит:

• stress-ng (быстро запускается и хорошо масштабируется);
• Prime95/mprime (тяжелая нагрузка на вычисления и кэш);
• Linpack-подобные пакеты (очень «жаркие», полезны для проверки охлаждения и лимитов питания).

Чтобы нагрузка была честной, параллелизм задают по числу логических CPU (threads). Часто имеет смысл оставить 1-2 потока системе, особенно если вы параллельно мониторите логи и сенсоры. Для двухсокетных систем полезно прогонять тесты с привязкой к NUMA, чтобы ловить проблемы конкретного процессора или конкретного набора каналов памяти.

Пример команд (адаптируйте N под ваш сервер):

N=$(nproc)
stress-ng --cpu $N --cpu-method matrixprod --timeout 2h --metrics-brief

Проблемой считаются не «высокие температуры сами по себе», а признаки нестабильности:

• троттлинг, который держится постоянно и заметно режет частоты под стабильной нагрузкой;
• ошибки MCE/WHEA в системных логах, даже если тест формально не упал;
• падения процессов теста, зависания, перезагрузки, kernel panic;
• ошибки вычислений (если утилита их показывает).

Для гарантийных кейсов сохраняйте вывод утилиты, версии BIOS/микрокода и выжимку из системных логов в один архив с датой и серийным номером сервера. Это банально, но именно этого чаще всего не хватает, когда «вроде падало, но теперь не воспроизводится».

Тест RAM и ECC: как выявлять нестабильность памяти

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

Надежнее всего начинать с проверки вне ОС: Memtest86 (или аналогичный загрузочный тест) хорошо ловит явные проблемы модулей и таймингов.

Уже в системе полезно добавить длительную нагрузку на память. Чаще всего используют stress-ng в режиме vm (выделяет и активно перезаписывает большие объемы RAM), а по ситуации - y-cruncher, который нередко выявляет нестабильность на грани, особенно при высокой температуре.

С ECC важно различать «исправленные» и «неисправленные» ошибки. Единичная корректируемая ошибка за много часов может быть случайностью, но повторяемые события, рост счетчиков под нагрузкой или ошибки на одном и том же DIMM почти всегда означают железную проблему. Для проверки смотрите системные журналы: в Linux это dmesg и сообщения EDAC/MCE (часто видны как записи про corrected/uncorrected ECC). В Windows похожие события попадают в системный журнал.

Что обычно считается FAIL по памяти:

• любая uncorrected ECC ошибка, kernel panic, BSOD или самопроизвольная перезагрузка;
• повторяющиеся corrected ECC ошибки, особенно на одном слоте/канале;
• ошибки Memtest86, даже единичные, если они воспроизводятся;
• падения y-cruncher или ошибки вычислений (mismatch) при одинаковых настройках;
• крэши приложений и «битые» архивы/хэши во время длительной записи в RAM.

Если тестируете новый сервер перед вводом (например, стойку для виртуализации), запускайте нагрузку на 4-12 часов и следите, чтобы счетчики ECC не росли. Если растут, фиксируйте время, температуру и конкретный модуль - так проще обосновать замену по гарантии.

Тест сети: пропускная способность, потери и стабильность

Сеть часто выглядит «нормально», пока не начинается реальная нагрузка: резервное копирование, миграции ВМ, репликация баз. Burn-in по сети нужен, чтобы поймать плавающие ошибки порта, кабеля, SFP и настроек до продакшена.

Сначала сделайте базовую проверку линка. Важно не только «поднялся ли интерфейс», но и нет ли скрытых ошибок, которые потом превращаются в ретрансляции TCP и падение скорости.

Проверьте:

• скорость и дуплекс (например, 10G/Full), корректную автосогласовку;
• счетчики ошибок интерфейса: CRC, drops, overruns, frame errors;
• драйвер и прошивку NIC (без предупреждений в системных логах);
• наличие/отсутствие flow control pause frames (если они неожиданно растут).

Дальше нагружайте канал iperf3. Прогоняйте в обе стороны и с разным числом потоков: одна «толстая» сессия и несколько параллельных часто дают разную картину. Для стабильности полезны длинные прогоны (10-30 минут), а не 30 секунд.

# На принимающей стороне
iperf3 -s

# На тестируемом сервере: 4 потока, 15 минут
iperf3 -c <IP_партнера> -P 4 -t 900

# Обратное направление (сервер передает в ответ)
iperf3 -c <IP_партнера> -P 4 -t 900 -R

Для сервисов, чувствительных к задержкам (голос, VDI, некоторые кластеры), добавьте проверку потерь и джиттера. Простая практика: длительный ping и сравнение «до» и «под нагрузкой iperf3».

Что фиксировать для отчета и возможного гарантийного кейса: снимок конфигурации (скорость/MTU), полный вывод iperf3, счетчики ошибок интерфейса до и после теста, а также метрики TCP (ретрансляции, просадки скорости по времени). Если на новом сервере линк 10G показывает стабильные CRC и рост ретрансляций на одном порту, это сильный аргумент для замены кабеля, SFP или NIC.

Диски и хранилище (по задаче): быстрый стресс I/O и проверки

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

Для быстрого стресс-теста I/O обычно хватает fio. Идея простая: дать длительную смешанную нагрузку (чтение/запись), похожую на реальную. Для БД полезны небольшие блоки и случайный доступ, для файловых архивов - крупные блоки и последовательная запись. Запускайте тест на том уровне, где реально будет работать хранилище: отдельный диск, RAID-массив, LVM, SAN LUN.

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

Сигналы «не годен», при которых тест стоит останавливать и разбираться:

• ошибки чтения/записи в fio, I/O error в dmesg или syslog;
• резкий рост задержек (latency) и провалы скорости без изменения профиля нагрузки;
• таймауты дисков или контроллера, сообщения о reset/abort команд;
• рост SMART-ошибок (reallocated, pending, uncorrectable), даже если тест «формально прошел»;
• перегрев дисков или контроллера выше нормы для вашей модели.

Если сервер собирается под критичные нагрузки (например, кластер VM в стойке), полезно сравнить результаты с эталоном той же конфигурации. Такой эталон можно хранить как базовый профиль для приемки.

Пошаговый сценарий burn-in на 4-12 часов (пример)

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

Если сервер новый или после ремонта, burn-in лучше делать в предсказуемых условиях: нормальная вентиляция, штатные вентиляторы, закрытая крышка, питание без «сюрпризов».

Пример последовательности (4-12 часов)

1. Соберите «паспорт» сервера и включите сбор логов: модель, серийный номер, конфигурация CPU/RAM/дисков/сетевых карт, версии BIOS/firmware, дата и место теста. Сразу настройте сохранение системных логов (dmesg/journal/syslog), событий BMC/IPMI и показаний датчиков.

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

3. Нагрузка по очереди: сначала CPU стресс с мониторингом, затем RAM стресс, затем комбинированная нагрузка CPU+RAM. Важно не просто «грузить», а отслеживать признаки деградации: троттлинг, резкие скачки температуры, Machine Check ошибок, падения тестов, зависания.

4. Сетевой прогон iperf3: в обе стороны, в несколько потоков, минимум 10-15 минут на каждую конфигурацию (один линк, LACP, разные VLAN - по вашей схеме). Если сервер будет работать с хранилищем или базами, добавьте короткий I/O стресс (fio) на нужных дисках или томах.

5. Финальный статус PASS/FAIL и упаковка артефактов: сохраните логи, результаты утилит, скриншоты датчиков и таблицу с метриками. Это сильно помогает, если потребуется разбор инцидента или гарантийный кейс.

Критерии «годен/не годен»: как принять решение без гадания

Главное правило: сравнивайте результаты burn-in не с «как у других», а со спецификациями производителя для вашей модели CPU, памяти, платы и системы охлаждения. Температурные лимиты, допустимые частоты, правила работы турбо и пороги троттлинга отличаются даже у похожих конфигураций.

Оценивать «годен/не годен» удобнее по четырем осям: стабильность, ошибки в логах, тепловое поведение, предсказуемость производительности. Если хотя бы одна ось проваливается повторяемо, это почти всегда повод остановиться и разобраться до продакшена.

Практичный критерийный чек:

• FAIL: повторяемые аппаратные ошибки в логах (ECC/MC, PCIe AER, MCE), даже если сервер не падает. Единичный редкий WARNING еще не приговор, но повторяемость на той же нагрузке - красный флаг.
• FAIL: зависания, самопроизвольные перезагрузки, уход в kernel panic, пропадания сетевых интерфейсов или контроллера.
• FAIL: устойчивый троттлинг при номинальной нагрузке, когда вентиляция и условия нормальные (чистые фильтры, адекватная температура в стойке, корректный профиль вентиляторов).
• PASS: тесты идут часами без критических ошибок и падений, а показатели стабильны.
• PASS: производительность предсказуема, без резких провалов и «пилы» частот без внешней причины.

Пример: вы прогоняете новый rack-сервер (например, из класса S200) 8 часов. Если каждые 20-30 минут фиксируется MCE или растет счетчик исправленных ECC, сервер лучше считать «не годен» для продакшена, даже если приложения пока не замечают проблем. А если температура и частоты держатся в пределах спецификации и логи чистые, решение «годен» можно принимать уверенно.

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

Самая частая ошибка - проводить burn-in тест сервера как «черный ящик»: запустили стресс, ушли, вернулись к зависшему экрану и без ответа на вопрос «почему». Без мониторинга температур, частот, ошибок ECC и логов ОС вы теряете время и не получаете доказательств для разборов и гарантийных обращений.

Вторая ловушка - менять сразу все. Обновили BIOS, драйвер RAID, прошивку сетевой карты и одновременно запустили новую нагрузку. Если сервер упал, вы не поймете, что именно стало причиной. Делайте изменения по одному и фиксируйте версии прошивок и пакетов до и после.

Что чаще всего ломает тест

• Стресс без наблюдения: нет графиков, нет логов, нет меток времени.
• «Коктейль» нагрузок без плана: CPU, RAM, сеть и диски одновременно, а потом непонятно, что виновато.
• Игнор условий: закрытая стойка, забитые фильтры, высокий нагрев в серверной.
• Слабое питание или проблемный PDU: краткие просадки, которые выглядят как «случайные» ребуты.
• Слишком короткий прогон: 10-20 минут не ловят редкие ошибки памяти и перегрев под постоянной нагрузкой.

Простой пример: сервер проходит 15 минут, но через 2 часа начинает троттлить из-за температуры или ловит единичные ECC-ошибки. Если вы не записываете события в syslog/journal и показания датчиков, спор «воспроизводится/не воспроизводится» может тянуться бесконечно.

Как не попасться

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

Как фиксировать результаты для гарантийных кейсов

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

Удобнее всего вести единый шаблон отчета на каждый сервер. В первой части укажите дату и время, место установки, серийный номер и точную конфигурацию (CPU, объем RAM, модели дисков, сетевые карты). Отдельной строкой запишите версии BIOS и ключевых firmware, а также параметры, которые меняли перед тестом (профили питания, XMP, настройки RAID, MTU).

Дальше соберите «сырые» данные, чтобы их было сложно трактовать двояко:

• логи ОС: dmesg и журнал системы за окно теста (с отметками времени);
• журнал BMC: выгрузка SEL (например, через ipmitool) и показания датчиков (температуры, питание, вентиляторы);
• диски: SMART-выгрузки до и после теста, плюс результаты I/O утилит, если гоняли;
• результаты стресс-утилит: итоговые отчеты, коды завершения, показатели ошибок (ECC, segfault, падения).

Фотодоказательства тоже полезны: экран консоли с идущим тестом и временем, шильдик с серийником, общий вид стойки и подключений (питание, сеть). Это помогает подтвердить, что тест шел на конкретном железе.

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

Короткий чек-лист перед вводом в продакшен

Перед тем как отдавать сервер под реальные нагрузки, полезно пройти короткую проверку, чтобы потом не спорить «что было в момент запуска». Этот список хорошо дополняет burn-in тест сервера и закрывает типовые риски.

5 проверок за 15 минут

• Зафиксируйте идентификаторы и конфигурацию: серийный номер, модель, CPU, объем RAM, состав дисков/RAID, сетевые карты. Запишите версии BIOS/BMC/прошивок контроллеров.
• Проверьте термопрофиль под нагрузкой: температуры CPU, чипсета, дисков, обороты вентиляторов. Если видите явный троттлинг или резкие «пилы» оборотов, остановитесь и разберитесь до продакшена.
• Просмотрите системные логи на критические аппаратные ошибки: Machine Check, ECC, PCIe, ошибки контроллеров, перегрев. За время тестов не должно быть повторяющихся ошибок.
• Оцените состояние дисков: SMART без тревожных атрибутов, нет роста переназначенных/ожидающих секторов, нет ошибок чтения/записи.
• Проверьте сеть на целевой режим: скорость и стабильность (например, через iperf3), без потерь и «провалов» при длительном прогоне.

Отдельно сохраните «пакет доказательств» для гарантии: папку с датой и именем сервера, выводы команд, логи (zip), скриншоты страниц BIOS/BMC со версиями, а также краткий итог «годен/не годен» с подписью ответственного.

Пример из практики: ввод нового сервера без сюрпризов

Новый rack-сервер ставили под виртуализацию. Диски планировались в отдельной СХД, поэтому главный риск был в памяти и сети. Чтобы не мешать пользователям, сервер подключили в тестовый VLAN и прогнали burn-in ночью, с теми же сетевыми настройками, что будут в продакшене (скорость портов, MTU, bonding).

Сценарий был простой: 30-60 минут базовой нагрузки на CPU, чтобы увидеть перегрев, странные частоты и ошибки питания, а дальше упор на RAM и сеть. Для памяти запустили stress-ng (режимы vm и malloc) и параллельно смотрели логи ECC в dmesg и журнале системы. Важно не просто загрузить RAM, а убедиться, что нет повторяющейся коррекции на одном и том же DIMM.

Для сети сделали несколько прогонов iperf3 в обе стороны с разной длительностью (короткий для пиков и длинный на стабильность) и проверили, что нет потерь, ретрансмитов и скачков скорости при длительной нагрузке.

Итог оформили так, чтобы его можно было сразу приложить к гарантийному обращению:

• один PDF или Doc: конфигурация, версии BIOS/firmware, окна теста, краткие выводы, критерии PASS/FAIL;
• архив логов: выводы команд, журналы системы, скриншоты метрик (температуры, частоты, ошибки);
• фото шильдика с серийным номером и наклейками на узлах (если доступно);
• контрольная сумма архива, чтобы файл не повредился при пересылке.

Если тест дал FAIL, не спешили менять все подряд. Сначала повторили прогон с теми же параметрами (исключить случайный сбой), затем изолировали компонент: перестановка модулей памяти по слотам, замена кабеля/порта, обновление firmware. Если ошибка повторялась и была воспроизводимой, эскалировали в сервис с полным пакетом доказательств.

Следующие шаги: как встроить burn-in в вашу ИТ-практику

Чтобы burn-in не превращался в разовую инициативу, закрепите его как обязательный шаг в приемке новых серверов и после любых рискованных изменений: замены CPU/RAM, прошивок, настройки RAID, переноса в другую стойку или зал.

Рабочее правило простое: без отчета о тесте сервер не получает статус «готов к продакшену». Это снижает споры между ИТ, закупками и подрядчиками, потому что решение опирается на измеримые факты.

Процесс, который легко поддерживать

Определите владельца процедуры (например, инженер эксплуатации) и заведите короткий регламент: что тестируем, сколько часов, какие утилиты и какие метрики считаются критичными. Сразу договоритесь о формате артефактов: логи, скриншоты ключевых экранов мониторинга, версии BIOS/BMC, серийные номера, итоговый PASS/FAIL.

Чтобы не делать это вручную каждый раз, автоматизируйте сбор результатов: один скрипт, который стартует тесты, собирает журналы (dmesg, BMC/SEL, SMART, отчеты утилит), фиксирует температуру и частоты, а затем собирает единый архив и краткий отчет. Такой пакет удобен и для внутреннего контроля, и для гарантийного кейса, если проблема всплывет позже.

Закрепите критерии заранее, особенно при закупках

До подписания поставки согласуйте с поставщиком критерии PASS/FAIL и что считается «дефектом»: ошибки ECC, Machine Check, деградация сети, перегрев, троттлинг, нестабильность под нагрузкой. Это экономит время и делает ожидания понятными.

Если вы планируете закупку и внедрение под ключ, имеет смысл заранее обсудить с GSE.kz (gse.kz) поставку серверов и системную интеграцию, а также то, как будет выглядеть приемка: burn-in, пакет отчетности и дальнейшая поддержка.