IPMI, iLO, DRAC: перезагрузить сервер в другом городе, не вставая из кресла

Было примерно два часа ночи. Сервер в филиале в другом городе завис намертво - ни ping, ни SSH, ни RDP. Никто не отвечает. Дежурный у клиента смотрит на него и говорит: «Он просто стоит, лампочки горят». Раньше следующий шаг был один: либо кто-то едет, либо утром ждём открытия офиса и просим нажать кнопку reset. Сервисный выезд в другой город - это пять-шесть часов потерянного времени и отдельный счёт клиенту.

На этот раз сервер был с HP iLO - Integrated Lights-Out. Мы заранее подключили его к отдельному сетевому порту с отдельным IP, выдали доступ. Открыли браузер, зашли на интерфейс iLO, увидели сервер живым на уровне управляющего чипа - он висел в ОС, но сам контроллер работал. Нажали кнопку принудительной перезагрузки. Через минуту сервер поднялся, сервисы запустились. Дежурный звонит: «Заработало». Всё.

Это был момент, после которого мы пересмотрели наш чеклист при заказе серверов.

Что такое iLO, DRAC и IPMI

Это три разных названия одной идеи, реализованной разными производителями.

IPMI - Intelligent Platform Management Interface - стандарт, который описывает интерфейс управления железом независимо от операционной системы. Работает через отдельный сетевой порт или через разделяемый, через него можно смотреть температуры, статус питания, получать события. Это базовый уровень, который поддерживает почти любой серверный чипсет.

HP iLO - реализация HP, заметно богаче голого IPMI. Здесь есть веб-интерфейс, удалённая консоль через Java-апплет, управление питанием, просмотр системного журнала, виртуальный KVM. То есть можно зайти и увидеть то, что видит физический монитор, подключённый к серверу.

Dell DRAC - Dell Remote Access Controller, то же самое со стороны Dell. Логика аналогичная, немного другой интерфейс, немного другие возможности в зависимости от версии.

Суть одна: есть маленький отдельный компьютер внутри сервера, который живёт на собственном питании, имеет собственный сетевой адрес и работает вне зависимости от того, что творится с основной ОС. Завис Linux, завис Windows, ядро паникует, процессор намертво ушёл в петлю - контроллеру управления всё равно, он жив, он отвечает, он даёт вам доступ к железу.

Что умеет iLO на практике

Мы работали преимущественно с HP iLO, поэтому по нему конкретнее.

Удалённая консоль. Видишь экран сервера как будто сидишь перед ним. BIOS, загрузчик, консоль ОС - всё. Если сервер завис на POST, увидишь сообщение об ошибке памяти или диска. Раньше для этого нужен был физический монитор или KVM-переключатель.

Управление питанием. Выключить, включить, принудительный reset, graceful shutdown - всё через интерфейс. Именно это мы и использовали той ночью.

Виртуальный привод. Можно подключить ISO-образ с локальной машины как виртуальный CD-ROM сервера. Загрузился с образа, починил, перезагрузился. Без физических дисков, без поездки.

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

Мониторинг параметров. Температуры, скорости вентиляторов, статус блоков питания - в режиме реального времени. Это дополняет мониторинг через Nagios, потому что Nagios смотрит со стороны ОС, а iLO видит уровень железа независимо.

Что изменилось в работе

Раньше ночной инцидент с зависшим сервером в удалённой точке имел предсказуемый сценарий: ждём утра или едем. Оба варианта - это либо простой до открытия офиса, либо дополнительные расходы и усталый инженер.

Теперь сценарий другой. Дежурный звонит - сервер не отвечает. Открываем iLO, смотрим на консоль, читаем IML, принимаем решение. Зависла ОС - перезагружаем удалённо. Ошибка дискового контроллера - видим сообщение, оцениваем критичность, утром организуем замену. Сервер не подаёт признаков жизни вообще - смотрим статус питания, пробуем включить, смотрим POST. Во многих случаях инцидент закрывается без выезда.

Это напрямую влияет на то, что мы обещаем клиентам в рамках сопровождения инфраструктуры. Время реакции - одно, время восстановления - совсем другое. Если раньше ночной инцидент с удалённым сервером физически не мог закрыться быстро, теперь это возможно. Разница принципиальная.

Мы пересмотрели SLA-параметры для клиентов с удалёнными точками - именно потому, что теперь есть инструмент, который позволяет держать эти параметры.

Что теперь в чеклисте при заказе сервера

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

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

• Наличие выделенного порта iLO/DRAC/IPMI. Не через разделяемый интерфейс, а отдельный порт на отдельном IP. Иначе если сеть ОС упала - упал и доступ к управлению.
• Лицензия iLO Advanced или аналог. Базовая лицензия на HP урезает функционал, в частности удалённую консоль. Доплата небольшая, возможности принципиально другие.
• Отдельный VLAN для управления. Трафик управления не должен идти через тот же сегмент, что и продакшн. Это и безопасность, и отказоустойчивость.
• Проверка доступа до ввода в эксплуатацию. Убедиться, что iLO работает, консоль открывается, управление питанием работает - прямо на этапе приёмки, а не когда придёт нужда.

Можно сколько угодно говорить про VPN между офисами и хорошие каналы связи - всё это помогает, пока ОС живая. Когда ОС мертва, нужен другой уровень доступа. Теперь он у нас есть по умолчанию.