Привет, Хабр!

На связи сервисная команда «Инфосистемы Джет». Сегодня хотим рассказать про один из технических кейсов. На его решение должна была уйти пара часов. Вместо этого он съел четыре дня нашей жизни. Спустя почти десяток лет он регулярно вспоминается в обсуждениях за обедом как один из непростых в диагностике. На днях обсуждали его — почему бы теперь не рассказать о нем вам? :) Приступим.

Завязка

Все началось довольно обыденно. Летней ночью с четверга на пятницу около часа ночи прилетает срочная заявка: неисправен сервер 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. Если у вас были похожие случаи — делитесь в комментариях! Интересно, кто сталкивался с чем-то подобным.