Сервер прошёл POST, загрузил Linux и бодро отвечает по SSH — рабочие сервисы на него пока рано переносить: ошибки памяти, сбои накопителей и проблемы охлаждения могут проявиться только под нагрузкой. Приёмка б/у сервера после ЦОД нужна администратору, чтобы проверить полученную конфигурацию и сохранить исходные данные, с которыми потом можно сравнить состояние машины.
Практический разбор приёмки сервера с анализом аппаратных журналов и нагрузочными тестами рекомендуем прочитать в статье на Хабре https://habr.com/ru/companies/dorfa/articles/1094370/.
Что зафиксировать до начала проверки
Сначала сохраните состояние «как приехало», прежде чем обновлять прошивки, менять настройки BIOS или создавать массив.
В исходную карточку сервера внесите:
- модель и модификацию шасси, серийный номер;
- модели CPU и состав памяти по слотам;
- модели и идентификаторы накопителей, RAID/HBA и сетевых адаптеров;
- версии BIOS, iLO/iDRAC и прошивок контроллеров;
- дистрибутив, версию ядра и драйверов.
Для первичной инвентаризации пригодятся dmidecode, lscpu, lsblk и lspci: их вывод нужно сопоставить с маркировкой и спецификацией поставки. Данные SMBIOS тоже бывают неполными или ошибочными.
Проверьте корпус, разъёмы, вентиляторы, блоки питания, заглушки и воздуховоды. Сфотографируйте повреждения и маркировку спорных компонентов.
Сверьте фактическую сборку с руководством именно этой платформы: правила заполнения DIMM, поддержку контроллера и backplane, доступность PCIe-слотов при установленном числе CPU. Одинаковый разъём ещё не подтверждает совместимость.
В отчёте укажите дату, часовой пояс, исполнителя и назначение сервера. Зафиксируйте расхождение часов ОС и контроллера управления до их синхронизации: это поможет сопоставить события из разных журналов.
Какие журналы и показатели проверить
В Linux с systemd начните с journalctl -k -b: команда показывает сообщения ядра текущей загрузки. journalctl —list-boots перечисляет загрузки, представленные в сохранившемся журнале. Если журнал хранился только в оперативной памяти, истории после перезагрузки может не быть. Пустой журнал — ещё не чистая биография сервера.
Ищите сообщения об аппаратных ошибках, тайм-аутах накопителей, сбросах контроллеров, обрывах сетевого соединения и аварийных завершениях. Сохраняйте полную выгрузку, а не только строки со словом error: соседние сообщения часто объясняют последовательность сбоя.
Через iLO выгрузите IML и доступный AHS, через iDRAC — Lifecycle Log и System Event Log. Сопоставьте события памяти, питания и охлаждения с загрузками ОС. Учитывайте код, затронутый узел, время и повторяемость события; одного уровня Critical для диагноза недостаточно.
Для памяти различайте исправленные ECC-ошибки и неисправимые ошибки. Рост исправленных ошибок во время теста требует разбирательства, но сам по себе ещё не указывает на конкретную неисправную планку: проверяют также слот, канал и конфигурацию. Отсутствие записей Linux имеет смысл оценивать только при работающем механизме регистрации аппаратных ошибок.
По каждому физическому накопителю сохраните полный доступный отчёт smartctl, например с параметром -x*. За RAID-контроллером может потребоваться специальный способ обращения к диску либо утилита производителя контроллера. SMART логического тома не заменяет диагностику всех дисков массива.
Показатели выбирают с учётом типа накопителя:
- SATA HDD: переназначенные, ожидающие переназначения и неисправимые секторы.
- SAS: доступные счётчики дефектов и ошибок.
- SSD: износ и ошибки носителя.
- NVMe: Critical Warning, Available Spare и Percentage Used. Последний показатель отражает оценку использованного ресурса, а не остаток.
Трактовка полей зависит от устройства; PASSED не гарантирует исправность.
Добавьте состояние RAID, защиты кэша контроллера, датчиков температуры, вентиляторов и резервирования питания.
Как проверить сервер под нагрузкой
Проверку б/у сервера проводите до размещения рабочих данных, с доступом к удалённой консоли. Сначала тестируйте подсистемы раздельно, затем сочетайте нагрузки: так проще локализовать сбой и проверить машину при совместном потреблении ресурсов.
- CPU и память. Для нагрузки подходят выбранные стрессоры stress-ng, для проверки доступной памяти — memtester или подходящая загрузочная диагностика. Тест внутри Linux не охватывает память, занятую ядром и другими процессами. Оставляйте ОС рабочий резерв: OOM из-за неудачного размера теста не доказывает дефект DIMM. Сохраняйте параметры запуска, объём проверенной памяти, длительность, число проходов и код завершения.
- Накопители. В fio задайте профиль, соответствующий будущей работе: размер блока, соотношение чтения и записи, глубину очереди и число заданий. Укажите тестируемый объём, режим ввода-вывода, состояние кэша и фоновые операции RAID. Для задержки фиксируйте конкретную метрику, например p99 времени завершения операций clat: среднее скроет редкие длинные паузы. Сохраняйте файл задания и полный результат, желательно JSON. Записывающие тесты выполняйте только на выделенном тестовом файле или заведомо расходном устройстве: запись непосредственно на диск может уничтожить разделы и данные.
- Сеть. iperf3 запускают с заведомо исправным вторым узлом, проверяя нужные порты в обоих направлениях. Вместе со скоростью сохраняют число потоков, MTU, повторные передачи TCP и изменение счётчиков ошибок интерфейсов. Низкий результат может объясняться вторым узлом, кабелем, коммутатором или загрузкой CPU; одной цифры недостаточно, чтобы забраковать NIC.
Во время всех прогонов наблюдайте за температурой, частотами, вентиляторами и новыми аппаратными событиями. Пределы берите из документации конкретных компонентов: единого допустимого значения температуры для всех серверов нет. Необъяснимый перезапуск, ошибка проверки данных или новая неисправимая ошибка памяти — повод остановить приёмку и установить причину.
Продолжительность определяйте программой испытаний и объёмом оборудования. Записывайте фактически выполненные проходы и время: формулировка «ночь простоял включённым» ничего не говорит о нагрузке. После тестов повторите выгрузки журналов и счётчиков, сравните их с исходными.
Как оформить результат приёмки
Отчёт должен позволять повторить проверку. Приложите конфигурацию, команды и версии утилит, исходные выгрузки, результаты тестов и перечень изменений. Таблицу заполняйте измерениями; ниже — шаблон, а не результаты реального сервера.
| Узел | Проверка | Результат | Замечание |
| CPU | Нагрузка, частоты, температура | Длительность, диапазоны, события | Режим питания, ограничения |
| RAM | Тест памяти, события ECC | Объём, проходы, новые ошибки | Непроверенная область, проблемный слот |
| Накопители и RAID | SMART, состояние массива, fio | Изменения счётчиков, ошибки, задержка | Кэш, профиль, фоновые операции |
| Сеть | Передача в обе стороны | Скорость, повторы TCP, ошибки портов | Второй узел, MTU, кабель |
| Питание и охлаждение | Датчики, журналы, резервирование | Температуры, события, состояние БП | Условия и непроверенные режимы |
До ввода в работу закройте вопросы:
- Совпадает ли сборка с заказом и поддерживается ли выбранная ОС?
- Объяснены ли найденные ошибки и выполнен ли повторный тест после исправлений?
- Какие режимы остались непроверенными и допустимо ли это для будущей нагрузки?
- Настроены ли мониторинг, доступ к управлению и восстановление из резервной копии?
Ввод сервера оправдан, когда согласованная программа выполнена, отклонения устранены, а конфигурация соответствует задаче. При нерешённых ошибках или непроверенных критичных режимах приёмку оставляют незавершённой. Успешный прогон подтверждает поведение машины в зафиксированных условиях; гарантию будущей безотказности он не выдаёт.
