Привет, Хабр!
На связи сервисная команда «Инфосистемы Джет». Сегодня хотим рассказать про один из технических кейсов. На его решение должна была уйти пара часов. Вместо этого он съел четыре дня нашей жизни. Спустя почти десяток лет он регулярно вспоминается в обсуждениях за обедом как один из непростых в диагностике. На днях обсуждали его — почему бы теперь не рассказать о нем вам? :) Приступим.
Завязка
Все началось довольно обыденно. Летней ночью с четверга на пятницу около часа ночи прилетает срочная заявка: неисправен сервер Oracle T5-2 после работ в ЦОДе по питанию. Выглядит он вот так:
Коротенькая характеристика: Oracle T5-2 — не самый новый к моменту нашей истории, но довольно популярный сервер в узких кругах. Два процессора SPARC T5, 256 виртуальных потоков и до 1 ТБ памяти — в 2013 году это была настоящая рабочая лошадка для виртуализации и баз данных.
В нашем сервисном центре на поддержке находился довольно большой парк таких серверов. У этой модели частой причиной неисправности была материнская плата, а на старших — процессорные модули.
В нашем случае мы проанализировали собранные данные с системы, в первую очередь под подозрение попала материнская плата.
fault = fault.chassis.voltage.fail@/SYS/MB/CM1
certainty = 100.0 %
FRU = /SYS/MB
ASRU = /SYS/MB
resource = /SYS/MB/CM1Лог ILOM, который говорит о том, что материнская плата неисправна и в первую очередь требует замены.
Дальше события развивались обыденно: запрос — подтверждение — замена. Однако к успеху это не привело — сервер не запустился. На сервис-процессоре мы увидели ошибки на блоках питания и восьми Memory Riser (MR).
Memory Riser — это платы расширения, куда устанавливаются модули памяти. Для наглядности (куда мы без картинок XD):
После материнской платы под подозрение попали компоненты, которые отвечали за питание сервера, — его блоки питания и power distribution board (PDB). Пока мы были на площадке, сразу провели несколько тестов: запуск — поочередная смена блоков питания и зачистка ошибок. Однако результатов это не принесло.
Тем временем со стороны вендора инженер открывает внутренний кейс на разработчиков. К вечеру того же дня в результате анализа под подозрение попали:
один блок питания;
PDB (power distribution board);
комплект внутренних кабелей между матплатой и PDB;
сама плата, которая могла прийти неисправной, — DoA (Dead on Arrival).
A few moments later
Все компоненты уже были в доставке. Мы приехали на площадку проводить поочередную замену. Отчитываемся, что сделали:
заменили PS0 и извлекли старый PS1. Результат — сервер не стартовал;
проинспектировали PDB — визуально проблем не было. Итог: замена к успеху не привела;
-
посмотрели кабели между PDB и матплатой. Кабели тоже выглядели нормально*. Тем не менее их мы тоже поменяли. Результат — ноль;
* Отступление инженера поддержки: С кабелями возникают проблемы из-за высыхания/тугости разъемов. В процессе отключения иногда случаются казусы, но на нашем сервере было все в порядке.
напоследок заменили материнскую плату. Изменений практически никаких не произошло, только в ILOM перестал отображаться PS1 и появились ошибки по всем восьми MR (Memory Riser).
Кульминация: страсти накаляются
«А не в MR’ах ли дело? Скорее нет, так как шансы малы, что неисправны сразу все», — пробежал короткий монолог в голове. «Черт возьми! Ну не могут выйти из строя все комплектующие за инцидент», — продолжалась рефлексия. Собрали все логи после работ и выгрузили вендору.
Шли уже выходные. От вендора — PS1 к замене, о чем утром сообщил наш дежурный инженер. И все.
— ...но мы-то знаем, что проблема не в нем.
Ехать и менять один блок питания было совсем глупо и бесперспективно. Поэтому мы несколько раз созвонились с вендором и постарались донести критичность ситуации: шел второй день, сервер не работал, решения не было. По факту к этому моменту мы поменяли большинство компонентов сервера. Вендор настаивал на проблеме в питании. Тем не менее мы не сдавались. В свою очередь предложили заменить один из MR'ов и посмотреть, не изменится ли ситуация. В ответ услышали только, что такого быть не может, чтобы были неисправны все восемь. Но за неимением других вариантов спустя пару часов увещеваний и разговоров вендор согласился попробовать поменять.
В тот же вечер мы отправились на площадку, заменили блок питания и Memory Riser.
И — о, чудо! — ошибок по райзерам стало на одну меньше.
Развязка: черт возьми и слава Богу – чудо!
Дальше было дело техники — заменить еще семь штук. На локальном складе их не оказалось в нужном количестве, только половина. По всей видимости, в запасе их было не так много, так как довольно редко они выходили из строя.
Нам повезло — удалось найти резервный сервер, откуда можно было позаимствовать на время нужные компоненты, пока решался вопрос логистики. После замены всех райзеров сервер успешно прошел POST, но счастье было не долгим. L Cервер успешно проходил все тесты и грузился до OBP (OpenBoot Prom), все компоненты были зеленые, и ошибок не возникало, но когда дело доходило до загрузки OS Solaris — зависал.
Сразу провели тест с запуском в минимальной конфигурации. Извлекли все PCI‑адаптеры, и операционная система успешно загрузилась. Затем провели ряд тестов с поочередным отключением периферийных устройств и нашли виновников. Неисправными оказались два HBA‑адаптера. После замены функциональность сервера была полностью восстановлена.
К слову сказать, POST при холодном старте занимает 40 минут, поэтому на локализацию ушел весь день.
Что на самом деле сожгло сервер?
Найти железную первопричину нам так и не удалось. Вероятно, произошел скачок напряжения, который задел многие компоненты (8 Memory Riser, блок питания, материнская плата, 2 HBA-адаптера) по линии питания.
Помимо этого, что именно было в ЦОДе во время переключения, нам тоже доподлинно неизвестно.
В итоге сервер ожил, клиент остался доволен, а мы получили еще один интересный опыт для обсуждения за обедом. Главный урок? В сервисной работе нет «слишком невероятных» поломок — есть только те, которые еще не нашли.
Почему нам вспомнился этот кейс? С коллегами обсуждали очередное решение, а эта история — отличное подтверждение того, что редкие и маловероятные сценарии тоже случаются.
P.S. Если у вас были похожие случаи — делитесь в комментариях! Интересно, кто сталкивался с чем-то подобным.
Комментарии (31)
ZlobniyShurik
29.07.2025 07:55На новой работе углядел выключенный HP DL 380 G какой-то-там. Спрашиваю - почему такая красота не в работе? Выяснилось странное - сервер новый, включается, работает. Но, в течение пары-тройки недель забывает всё, что есть на RAID-массиве. Сначала мелкие сбои, потом ОС еле грузится, в конце имеем просто неформатированные диски.
Фирменный сервер, фирменный RAID-контроллер, фирменные диски от HP (хоть и купленные в другой конторе). Диски и контроллер пробовали менять на запасные - не помогло. В логах системы, raid-контрллера и в iLO чисто; SMART идеален; поверхность дисков, проверенная через MHDD на тестовом стенде, в прекрасном состоянии.В глубинах HPшного форума в каком-то неофициальном посте выяснилось чудесное. Если у вас эта модель сервера, да с тем самым RAID-контроллером, то диски такие-то (дальше длинный список партнамберов от HP) ставить нельзя и это не лечится. Но если у вас диски (список партнамберов поменьше), то, залив прошивку конкретной версии XX в контроллер и YY (именно такую, не старше и не младше) в диски, комплектующие таки можно подружить.
Мне повезло - у меня были диски из второго списка, так что 15 минут колдунства и в нашем отделении появился могучий сервак, который потом работал без каких-либо замечаний.
Nurked
29.07.2025 07:55Ой, добро пожаловать, падаван, вас инициировали в мир замечательных пролаентов. Я на них сидел с пятёрок.
Вы прям как из жизни рассказываете, всё как по писаному, когда внезапно начинает ложиться главный RDP cервер, вообще с бодуна и без причин. Лечится всё это установкой левой прошивки, слитой с правильной правой ссылки на восьмом уровне вложенности на сайте поддержки HP.
ZlobniyShurik
29.07.2025 07:55О, да, тогда это был мой первый опыт плотного взаимодействия с HP. Начиная от старичков G2 и выше. Потом Dell'ы, SuperMicro...
Сейчас прикоснулся к машинкам попроще - Asus'ы и Gigabyte'ы (банально, взяли то, что было в наличии и укладывалось в бюджет). Так вот, с ними, как не странно, на мой взгляд головняков меньше (банально взяли первую попавшуюся нормальную память и винты/ssd - работает, не взирая на шильдики), но, впрочем, тут я не эксперт - машин немного, статистика пока никакая.
13werwolf13
29.07.2025 07:55был у нас давно давно сервер hp dl360 gen7, пришёл б.у. из японии как и ещё куча других. все проверки прошёл, работал отлично, накатили систему, развернули софт, пару дней работал без нареканий. и как водится обязательно ночью с субботы на воскресенье прилетает в telegram от zabbix пачка аллертов, сервер выключен. в логах ilo вроде как по питанию, включил удалённо, подежурил часик он работает. так как сервис не самый важный да ещё и зарезервированный другим сервером в соседней стойке ушёл спать. неделю он не давал о себе знать, потом опять ночью с воскресенья на понедельник потух, симптомы те же. в общем мы меняли блоки питания, провода, перевешивали его на другие лучи питания. всё равно раз в ~неделю ± пара дней он вырубался "по питанию". с прода его сняли просто перекинув диски в его точную копию и стали разбираться дальше (больше из спортивного интереса, так как вообще таких пациентов было принято пускать на запчасти канибализируя под задачи собратьев) и за ~3 месяца в нём заменили всё кроме материнки, начиная от прошивок и заканчивая всеми платами, памятью, процами.. малыш не сдавался и раз в какое-то время вырубался. конечно очевидно было что дело в материнке и поставив на него клеймо он был убран в шкаф. спустя пару лет пришёл его собрат с сильно помятым корпусом, вот его кишки и было принято переставить в героя этой истории (как раз живую материнку из мёртвого корпуса в живой корпус с мёртвой материнкой, казалось план идеален) и при перекидывании платы была найдена причина. маленький болтик попавший под материнку который какого-то чёрта раз в неделю закорачивал контакты с обратной стороны платы. без него этот сервер с родной материнкой прослужил ещё порядка трёх лет и возможно до сих пор где-то работает так как ушёл от нас на авито.
perfect_genius
29.07.2025 07:55какого-то чёрта раз в неделю закорачивал контакты
Видимо, в выходные баба Люба протирала корпуса серверов и они чуть-чуть сдвигались.
Donkeyhot_kgd
29.07.2025 07:5540 минут post? Я просто несерьезным админом был, и серваки в организациях где работал были попроще, вот те самые 300-й серии HP в основном, и какиех-то серьезных кейсов не было с ними никогда. Так вот -- 40 минут, правда?!!!
JetHabr Автор
29.07.2025 07:55Добрый день!
Спасибо за ваш вопрос:)
Да, максимальный POST после холодного старта (отключение питания с сервера) занимает порядка 40 минут. И это не придел. Если вспомнить старенькие sun fire 25k или sparc M9000 64 (как выглядит, можно поискать в гугле), на расширенных уровнях диагностики сервер мог запускаться часами. Связано это с расширенной самодиагностикой. В нашем случае не очень помогло, что редкость
DaemonGloom
29.07.2025 07:55Чем больше памяти - тем дольше POST. Условные 16/32 гига, которые в мелких организациях могут встретиться, грузятся быстро, 2-3 минуты. 512 - будет грузиться в 10 раз дольше. А ведь это далеко не лимит по современным меркам крупных компаний...
Сейчас и условный десктоп с 64 гигами DDR5 памяти после холодного старта будет грузиться минут 5 с чёрным экраном во время тренировки памяти.
zatim
29.07.2025 07:55Так а там разве нельзя скипнуть тест памяти настройкой в биосе?
Hardoman
29.07.2025 07:55Скипнуть можно, но задача то была как раз все их пройти)
zatim
29.07.2025 07:55Может мы о разных вещах говорим? Post - power on self test, самотестирование при включении питания. Длительная процедура полного тестирования памяти обычно выключается в биосе пунктом меню что то типа "fast start enable". Проводится только быстрое тестирование. Обычно по умолчанию только оно и включено.
Полное тестирование памяти при поиске неисправности проводится или из биоса (если там есть встроенные утилиты) или же сторонними утилитами как memtest, например.
Hardoman
29.07.2025 07:55Во-первых, в серверах не только память тестируется, но и контроллеры. Во-вторых, цель наоборот не скипать тесты. И вот это "fast boot" как раз нужно отключить, чтобы выполнить полноценное тестирование. Потому что холодный старт обычно - после обслуживания или после аварии, после чего надо полноценно тестировать, а не скипать.
И тестирование выполняется в серверах именно встроенными средствами, а не memtest, который не работает регистровой памятью.
zatim
29.07.2025 07:55но и контроллеры
Причем тут контроллеры? Они быстро тестируются, о них речь не идет.
нужно отключить,
Не нужно. Показать просто неисправную память сможет и быстрый тест. А если память сбоит, встроенный тест этого не покажет, тут нужно тестирование мемтестом, различными паттернами. Кроме того, мемтест покажет в каком именно месте сбой, можно вычислить сбойную плашку.
который не работает регистровой памятью.
С чего бы это вдруг? Кто вам сказал такую чушь? Для любого запущенного ПО вся память выглядит одинаково. Различия в ее аппаратной реализации никак не влияют на возможность работы с ней.
Moon_darker
29.07.2025 07:55Тренировка это тестирование, но тестирование - не тренировка
Во время тренировки материнская плата пробует разные комбинации по частотам и таймингам, чтобы найти самую стабильную конфигурацию
Но обычно это не каждый запуск происходит, и только при включении соответствующих функций в UEFI, ест-но
Moon_darker
29.07.2025 07:55Хотя, возможно, с DDR5 это требование: https://www.crucial.com/support/articles-faq-memory/ddr5-memory-training
zatim
29.07.2025 07:55пробует разные комбинации по частотам и таймингам
Первый раз такое слышу. Обычно инфа по частотам и таймингам любой памяти берется исключительно из ее spd. Все остальное - колхоз и оверклокинг. Вряд ли на такой критически важной технике производитель будет допускать такие вещи.
as-fisherman
29.07.2025 07:55Кластер на HP DL380 Gen9, дисковая полка HPE SV3200. Виртуалки потухли и не включаются. Техподдержка индусы и болгары долго выясняли как их стартануть. Ничего не получается, вендор молчит, поддержка забыла пароли на ESXi, в итоге иксы блокируют вход с каждой неверной попыткой добавляя время блокировки. Долгая несмешная история, в конце которой приехал на локацию инженер HPE и выявил в StoreVirtual все мертвые диски. Была какая-то партия, в которой в стоковой прошивке был счетчик, по истечению которого диски умирали. Поскольку диски были из одной партии, там вроде бы даже серийники подряд были, то этот счетчик на всех одновременно и натикал их смерть. До истечения таймера обновление прошивки решило бы проблему.
Lazhu
29.07.2025 07:55Классика. Вот поэтому всегда ставлю в рейды диски из разных партий и желательно даже разных вендоров
dimka11
29.07.2025 07:55Для чего вообще нужен такой таймер?
ZlobniyShurik
29.07.2025 07:55Там была ошибка в прошивке. Если правильно помню, счетчик часов наработки переполнялся и затирал собой окрестности, в которых тоже лежало что-то важное.
aluminic
29.07.2025 07:55Была какая-то партия, в которой в стоковой прошивке был счетчик, по истечению которого диски умирали.
Фигня какая-то про счетчик. Сигейты с мухой цеце, небось.
Hardoman
29.07.2025 07:55Тоже HP DL 385 не помню какого уж поколения. По прошествии некоторого количества часов начинает подвисать вплоть до фриза.
Сразу проверили диски - исключили их. Затем стали смотреть в сторону памяти и мамы. Память по все тестам здоровая, мама без перегрева и явных ошибок в ILO. Стали грешить на питание. Заменили по очереди блоки питания, казалось, что сначала помогло, но нет. Затем подкинули маму с аналогичного сервера - и тоже нет. Ситуация почти тупиковая, вендор стал готовить доставку полностью нового сервера.
Я тем временем решил на горячую посидеть с мультиметром и post картами и случайно вышел на след. На шине, куда втыкался HBA адаптер было пониженное напряжение. Но маму и блоки же меняли!? Как так?
Нашёл подозрительно горячий другой контроллер на той же шине и извлек его - напряжение выровнялось. Причем, контроллер был как бы живой и корректно определятся в системе. Не верь программной диагностике :)
ED-209
29.07.2025 07:55Был прикольный кейс один, запомнился. Не с железом связанный, но тоже сбило с толку на какое-то время ))
Работал в большой компании, много локальных пользователей, куча контрагентов-удаленщиков, в том числе и home office. И однажды пришло письмо от рандомного юзера, мол, при удаленном подключении "неожиданно во время работы вышибает рабочий стол, документы ничего не сохраняется". Сами же удаленные юзеры ходили на отдельную RDS ферму в DMZ через гейты-vpn'ы.
Так вот. Юзер пожаловался, написал. Посмотрели логи, ничего такого не нашли, хмыкнули, ответили юзеру "у нас все окей, ежели повторится, пишите снова". Прошла неделя-две. И тот же юзер пишет, снова вышибает у него удаленный рабочий стол только, добавляет уже, происходит это примерно в обед. Что про первый раз вспомнил, что совпало во второй. Снова посмотрели логи, все чисто, ничего не падало, не отваливалось, никаких ошибок, тишина. Да и других жалоб не было в принципе, только вот от него. Пока думали размышляли, спустя какое-то время он же написал и в третий раз. И снова, акцентирует, проблема происходит именно в обед. Непонятно. Систематичность вроде как проявилась, логика еще нет. То ли у нас мистика происходит, то ли у самого юзера.
Попросили прислать фото ошибки, как оно вообще выглядит это "неожиданно вылетает удаленный рабочий стол", может быть сообщение какое высвечивается, разрыв соединения или еще что. Запросили скриншот и стали ждать.
Прислал. На фото отчетливо видно Завершение работы в rdp сеансе o_0
Гостевая ВМ фермы изящно уходит в классический shut down. Все ожидали, кроме этого.
А потом осенило. Месяцем ранее настраивали плановую профилактическую перезагрузку каждого из гипервизоров через определенные 90-120 дней. Шедулер раскидали по календарю, условно раз в неделю перезагружается только один сервер. Другой сервер ребутится на следующей неделе. Третья неделя – третий сервер. И так в ротации. Последующая перезагрузка первого сервера происходила заново через 90-120 дней. Десятки гостевых ВМ RDS фермы, как и прочего остального, были размазаны по гипервизорам, по разным серверам.
Настраивали событие, естественно, на ночь. Около 4 утра по Москве, GMT+3. Удаленный сотрудник же, как в итоге выяснилось, работал с нами с Дальнего востока, чуть ли не на Камчатке. И иногда, не часто, балансировка RDS фермы при первом логине забрасывала юзера (GMT+12) на гостевую ВМ RDS того гипервизора, который под утро по Москве должен уйти в ребут. Время у Дальневосточного юзера как раз и было примерно обед.
Как решили? Добавили планировщик заранее выводящий в RDP сессии виндовое уведомление с просьбой сохранить документы, отдохнуть и попить чай 10 минут. Позже вообще разные дополнительные notification для юзеров взяли за правило хорошего тона.
Dr_Faksov
29.07.2025 07:55В сервисной работе нет «слишком невероятных» поломок — есть только те, которые еще не нашли.
Прямо по Стругацким -"Нет событий невозможных, есть маловероятные".
Lazhu
Неужели он питался не от батарей, чтобы так все спалило?
JetHabr Автор
Добрый день! Спасибо за вопрос:)
В ЦОДе есть резервное питание от батарей и ДГУ. Что именно произошло на линии питания нам доподлинно неизвестно. Знаем, что были какие-то работы.
oller
Кз до автомата и пофиг что там за батареи выше
Массовое отключение питания и затем включение всех этих нагрузок (мегаватт моментом?) тоже дело не сильно полезное (история в этом году с крупными дата центрами тому пример, на м9 сам пару блоков питания потерял)
Металл пыль в блок питания (мельчайшие частицы, которые занесли с обувью, одеждой)
Это так краткий перечень возможных,по моему мнению,причин