Тест нулевой конфигурации для серверов до установки ОС

Зачем делать проверку до установки ОС

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

"Нулевая конфигурация" - это короткий тест голого железа до установки ОС и до подключения к продакшен-сети. Вы проверяете, что базовые узлы работают, а встроенное управление (BMC) видит всю картину: датчики, вентиляторы, дисковые корзины, блоки питания и журналы событий. По сути, это приемка сервера в минимальном, но честном режиме.

Чаще всего старт ломают не "сложные" вещи, а базовые: питание (один блок не держит нагрузку или не уходит в резерв), охлаждение (вентилятор работает с ошибкой или неправильно реагирует на температуру), диски и корзины (не видится слот, есть ошибки линии, "флапает" подключение), датчики (ложные показания, из-за которых сервер уходит в защиту).

Ранняя проверка экономит время на внедрении и приемке, потому что вы ловите дефекты до того, как они превратятся в простой. Например, если при поставке стойки с серверами (в том числе класса GSE S200) один модуль питания оказывается нестабильным, это лучше выяснить в тестовом окне на столе, чем ночью после запуска сервисов, когда любой перезапуск - это согласования и потери.

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

Подготовка: что нужно и что не нужно

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

Дальше соберите минимальный набор именно для "нулевого" теста. Чем меньше лишнего, тем проще понять, где проблема: два кабеля питания (если БП два) и доступ к розеткам или PDU, отдельный кабель в сеть управления для BMC и понятный способ получить IP (DHCP или заранее выделенный адрес), локальная консоль (монитор и клавиатура или KVM), а также простой журнал для фиксации результатов и камера для фото.

На этом этапе не нужно настраивать RAID, ставить гипервизор или ОС, подключать агент мониторинга, тянуть VLAN и политики. Любая такая настройка добавляет шум и маскирует аппаратные симптомы. Цель - увидеть чистое состояние железа: датчики, вентиляторы, корзины, питание, журналы.

Фиксируйте результаты так, чтобы их можно было без вопросов передать в эксплуатацию или в поддержку. Запишите серийные номера (шасси, блоки питания, диски), версии прошивок, MAC-адреса, IP BMC, дату и место проверки, а также исходные статусы (OK, Warning, Critical). Если что-то выглядит подозрительно, сделайте фото экрана с ошибкой и фото наклейки серийника. Для серверов вроде GSE S200 это особенно полезно: с такими данными проще ускорить разбор и не спорить о том, что именно было на старте.

Сценарий: проверка BMC и журналов событий

BMC (IPMI/Redfish) удобно проверять еще до установки ОС: это быстрый способ убедиться, что сервер "живой", датчики читаются, а удаленное управление не отвалится в самый неподходящий момент. Обычно этот шаг занимает 10-15 минут.

Подключите BMC к отдельному порту управления, дайте ему адрес (DHCP или статический) и зайдите в веб-интерфейс. Если вход нестабильный или страницы грузятся с ошибками, не списывайте это автоматически на сеть. Часто проблема в прошивке, кабеле, коммутаторе или конфликте IP.

Дальше проверьте несколько вещей:

• Версии прошивок BMC и BIOS/UEFI и дату сборки. Если они заметно отстают от рекомендованных для вашей партии, запланируйте обновление до ввода в эксплуатацию.
• Базовые настройки: часовой пояс и время (для корректных логов), сетевой режим, доступ к удаленной консоли.
• Health/Monitoring: видны ли все датчики и нет ли "Unknown/Not Present" там, где модуль точно установлен.
• SEL/Event Log: есть ли свежие ошибки по питанию, памяти, перегреву, вентиляторам, дисковым корзинам.
• Удаленная консоль (KVM): открывается ли, не рвется ли сессия, работает ли виртуальный носитель (если планируете удаленную установку ОС).

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

Красные флаги обычно такие: повторяющиеся события PSU/AC Lost при стабильном питании, ошибки ECC/Memory Training, перегрев или скачки температур "на ровном месте", Fan Failed или частые уходы вентиляторов в максимум, обрывы связи BMC (watchdog, reset, network link flaps).

Если вы интегрируете серверы для критичных площадок (например, ЦОД или госорганизации), заранее договоритесь, кто фиксирует результаты проверки и как быстро оформляется замена по гарантии. Когда есть скриншоты логов и точное время событий, разбор обычно идет быстрее.

Сценарий: датчики температуры, напряжений и состояния

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

Откройте в BMC сводку Health и список сенсоров. Смотрите не только на красные статусы, но и на странные значения, которые формально "почти нормальные", но выбиваются из логики.

Что смотреть в первую очередь

Обычно хватает базового набора:

• Температуры: CPU, входной воздух (Inlet), VRM, чипсет, зона памяти, корзины дисков.
• Напряжения и токи: линии 12V, 5V, 3.3V, ток по PSU (если доступно), состояние батарейки/RTC.
• Состояния: крышка шасси, наличие модулей памяти, состояние PCIe, датчики корпуса и backplane.

Пороговые значения берите из политики производителя, но оценивайте по ситуации. После перевозки и распаковки бывают "ложные" предупреждения: сервер еще холодный, Inlet показывает слишком низко, крышка закрыта не до конца. Дайте системе 5-10 минут поработать и проверьте, исчезает ли предупреждение.

Сравните показания с реальностью вокруг. Если в стойке 22-24C, а Inlet показывает 40C без нагрузки, проверьте воздушный поток, заглушки, ориентацию в стойке и наличие препятствий перед фронтом.

Если датчик "завис" или показывает нереальное

Перед тем как идти дальше по сценарию, сделайте несколько простых шагов: обновите показания (Refresh) и посмотрите, меняются ли значения, перезагрузите BMC и повторите проверку, обесточьте сервер на 1-2 минуты и включите снова. Затем проверьте "физику": плотно ли сидят модули, кабели вентиляторов, backplane, крышка.

Если после этого датчик стабильно "врет", лучше остановиться и решить вопрос до установки ОС. Иначе вы перенесете риск прямо в продакшен. Обязательно зафиксируйте скрин/лог и отметьте серийный номер узла.

Сценарий: вентиляторы и охлаждение

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

Зайдите в BMC и посмотрите, все ли вентиляторы определяются, есть ли у них обороты и одинаково ли они ведут себя в одном ряду. Если один вентилятор показывает заметно меньше RPM при том же режиме, лучше остановиться и разобраться.

Быстрый тест вентиляторов

Дайте системе 5-10 минут поработать в простое, затем переключите профиль охлаждения (если доступно) с "тихого" на "производительный" и обратно. Важна не точная цифра, а реакция: обороты должны меняться быстро и предсказуемо, без "провалов" и зависаний.

Для фиксации результата обычно достаточно: сравнить RPM вентиляторов в одном режиме, убедиться, что нет предупреждений Fan/Temp, проверить реакцию на смену профиля и послушать, нет ли дребезга, скрежета или прерывистого гула.

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

Воздушный поток и мелочи, которые ломают охлаждение

Проверьте, что заглушки на местах, корзины и панели закрыты, а воздушный канал не "дырявый". Открытая заглушка или неверно установленный модуль может привести к тому, что в простое все выглядит нормально, а под нагрузкой появится локальный перегрев (часто в зоне памяти, RAID/HBA или у задних слотов).

Сигналы будущих проблем: температура растет медленно, но постоянно; один датчик стабильно выше других на 8-15 градусов; вентиляторы уходят в высокий режим без видимой причины; после перезагрузки на несколько минут все "нормализуется". Если это заметили на приемке, лучше заменить подозрительный вентилятор или поправить воздушный тракт сразу, пока сервер еще не введен в эксплуатацию.

Сценарий: дисковые корзины и подключение накопителей

Цель этого шага - убедиться, что корзины, бэкплейн и контроллер видят каждый слот стабильно, без настройки RAID и без установки ОС. Если пропадает хотя бы один слот, потом это превращается в "случайные" ошибки уже на боевой нагрузке.

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

Затем аккуратно проверьте механику и hot-swap на одном-двух слотах (на пустом сервере это безопаснее). Извлеките накопитель, подождите 10-20 секунд и вставьте обратно до четкого щелчка.

Во время теста смотрите на простые признаки: появляется ли событие об извлечении/установке в журнале BMC, не загораются ли индикаторы "ошибка" на корзине или диске, возвращается ли диск в тот же слот, нет ли сообщений про link down, reset, timeout, CRC, и не начинает ли "сыпаться" соседний слот при ваших действиях.

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

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

Сценарий: питание, блоки питания и резервирование

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

Сначала в BMC проверьте, видит ли система оба БП, какой у них статус (OK/Warning/Failed), есть ли предупреждения по входному напряжению и события о переключениях. Даже если сервер загружается, в журнале могут быть записи о просадках или кратковременной потере входного питания.

Дальше проверьте N+1 по очереди: отключайте каждый БП отдельно (вытаскивайте силовой кабель или выключайте конкретную розетку PDU), оставляя второй подключенным. Сервер не должен перезагружаться, а BMC должна зафиксировать потерю одного БП и затем восстановление.

Быстро оцените разводку питания: оба БП должны сидеть на разных линиях или разных PDU (а не в одном удлинителе), кабели должны быть без люфта, у PDU не должно быть перегруза по группе розеток, а входное напряжение в BMC - в пределах нормы и без частых скачков.

Есть отдельный класс проблем: БП "живой", но ненадежный под нагрузкой. На это намекают повторяющиеся предупреждения по input power даже при низкой нагрузке, краткие "потери" БП на секунды, резкие скачки оборотов вентиляторов без роста температуры, заметный нагрев корпуса или разъемов питания, свист или нетипичный шум второго БП при отключении первого.

Если такое проявилось, лучше заменить кабель, розетку PDU или сам БП до установки ОС и развертывания сервисов.

Пошаговый план теста на 30-60 минут

"Нулевой" тест удобнее делать по одному сценарию с таймингом. Так вы не забудете мелочи, а итог будет сравнимым между разными поставками и площадками.

1. 0-5 минут: фиксируем исходные данные. Сфотографируйте шильдик, запишите серийный номер, модель, состав (CPU, RAM, количество БП, корзины). Отметьте версии BIOS/BMC и ключевые настройки (дата, режим питания, профиль вентиляторов).

2. 5-15 минут: BMC и события. Зайдите в BMC, проверьте доступность, время, сетевые настройки и состояние аппаратных компонентов. Сохраните текущие логи, затем очистите журнал событий, чтобы в тест попало только новое.

3. 15-30 минут: датчики и охлаждение. Проверьте сенсоры температуры, напряжений и статусы. Убедитесь, что все вентиляторы видны и их обороты меняются при смене профиля или при краткой нагрузке (если доступна встроенная диагностика). Любой сенсор со статусом Warning или N/A запишите и уточните причину.

4. 30-45 минут: корзины и накопители. Проверьте, что все слоты дисковой корзины определяются, нет ошибок по backplane, защелки и индикаторы работают ожидаемо. Если есть RAID-контроллер, убедитесь, что он видит каждый диск и нет ошибок по линиям.

5. 45-60 минут: питание и финальный сбор логов. По очереди отключите один блок питания (если есть резервирование), убедитесь, что сервер не выключается, а в BMC появляется корректное событие. Верните питание, повторно снимите логи и сделайте короткий отчет: что проверили, что нашли, какие параметры были вне нормы и какие шаги дальше.

Типовые ошибки и ловушки при проверке

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

Прошивки и настройки: меняют, но не фиксируют

Частая ошибка - пропустить обновление прошивки BMC/BIOS/контроллеров, а потом неделями искать странные сбои с датчиками или вентиляторами. Другая крайность - поменять параметры (профиль вентиляторов, режим питания, порядок загрузки) и не записать, что именно изменили. Тогда непонятно, это дефект железа или последствия новой настройки.

Хорошая привычка: перед тестом сохранить версии прошивок и ключевые настройки, а после - зафиксировать все изменения.

Проверяют "все сразу" и теряют причину

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

Если нужен простой порядок, держитесь его: BMC и журналы событий, затем датчики температуры/напряжений, потом вентиляторы и реакция на нагрузку, дисковые корзины и обнаружение накопителей, и в конце питание и резервирование.

"Пока работает" - значит, можно игнорировать предупреждения

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

Не проверяют резервирование: питание и hot-swap

Самая обидная ловушка - проверить, что сервер включается, и на этом остановиться. Потом в стойке выясняется, что второй блок питания не подхватывает нагрузку, или дисковая корзина не дает корректную hot-swap (или вы просто не увидели событие в BMC).

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

Короткий чек-лист перед установкой ОС

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

• BMC открывается, учетные данные и права проверены, удаленная консоль запускается, а после ваших тестов в журнале нет свежих критических событий.
• По датчикам температуры, напряжений и состояния нет "вечных" алармов, показания похожи на реальность (не 0°C и не 120°C без нагрузки).
• Вентиляторы видны системой, не показывают ошибок, обороты держатся ровно; при краткой нагрузке температура не уходит в красную зону.
• Каждая позиция дисковой корзины определяет накопитель; если поддерживается hot-swap, вы аккуратно проверили извлечение и возврат одного диска, и система отреагировала корректно.
• Каждый блок питания по очереди тянет сервер один: вы отключали один БП (второй оставался включен), и не появлялись предупреждения о питании или просадки.

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

Пример из практики: как тест спасает от простоя

Новый сервер уже стоит в стойке, до запуска сервиса осталось 2 дня. Команда планировала поставить ОС, развернуть приложение, перенести данные. Вместо этого начали с "нулевого" теста: только питание, сеть управления и доступ в BMC.

Через 10 минут всплыло странное: один из слотов дисковой корзины то появлялся, то пропадал. В BMC периодически фиксировались предупреждения по линии backplane. Снаружи все выглядело нормально, индикаторы горели как обычно, и без проверки эту проблему легко было бы списать на будущую настройку RAID или "капризы ОС".

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

План работ поменяли на месте: остановили установку ОС и миграции, зафиксировали логи BMC и отметили слот, заменили корзину или модуль (в зависимости от модели и комплектации), повторили проверку до чистых журналов.

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

Следующие шаги: закрепляем процесс и отвечаем за результат

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

Оформляйте результаты так, чтобы их можно было быстро поднять через месяц, когда появится спорная ошибка или потребуется гарантийное обращение. В акт приемки и во внутренний тикет обычно достаточно приложить дату, серийный номер и конфигурацию (CPU, RAM, корзины, БП), версии прошивок (BIOS, BMC, RAID/HBA), снимки экранов со статусами датчиков и вентиляторов, сводку по питанию, выгрузку журнала событий BMC (до и после теста) и итог "годен/не годен" с пометками, что исправлено на месте, а что уходит в замену.

Повторяйте проверку не только при первой поставке. Риск "тихих" аппаратных проблем заметно растет, если сервер перевозили, меняли блок питания, вентилятор, контроллер, корзину или кабели, обновляли прошивки BIOS/BMC или меняли настройки питания, либо были инциденты с электросетью, ИБП или перегревом.

Дальше все решает дисциплина: внесите сценарий в стандарт внедрения, а на складе закрепите правило "без акта теста в продакшен не едет". Назначьте ответственного, заведите шаблон тикета и простое правило хранения артефактов (логи, скриншоты) в одном месте.

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