Bmc расшифровка и плата управления сервером — зачем она и что внутри

background memory controller
контроллер вспомогательного запоминающего устройства

English-Russian dictionary of computer abbreviations and terms.
.

Смотреть что такое «BMC» в других словарях

1. background memory controller — контроллер вспомогательного ЗУ;

2. binary magnetic core — двоичное запоминающее устройство на магнитных сердечниках;

4. bone marrow cell — клетка костного мозга;

5. bubble memory controller — контроллер запоминающего устройства на цилиндрических магнитных доменах

Англо-русский словарь технических аббревиатур.
.

Время на прочтение

В одной из предыдущих статей Максим затронул аппаратную часть платы BMC (Baseboard Management Controller). Я хочу продолжить повествование и рассказать о нашем подходе к BMC и участии в проекте OpenBMC.

Для полноты истории придётся начать немного издалека и рассказать о назначении сервисных процессоров и роли BMC в работе сервера, затронуть протокол IPMI и программную часть. После этого кратко опишу, как BMC участвует в загрузке систем на POWER8. Закончу обзором проекта OpenBMC и нашим отношением к вопросу. Опытные в теме сервисных процессоров читатели могут сразу отмотать на нижние разделы.

Сервисные процессоры — что, зачем и как

Сервисный процессор — это отдельный специализированный контроллер, встраиваемый в сервер. Его чип может быть напаян на материнскую плату, расположен на отдельной карте или, к примеру, размещён в блейд-шасси для управления ресурсами всей системы в целом (и тогда это может называться уже SMC — System Management Controller). BMC — частный случай сервисного процессора для управления отдельным хостом, и дальше по тексту будем говорить только о них и использовать термин «сервисный процессор» только в значении «BMC». При этом, говоря «BMC», в целом имеем в виду как собственно чип, так и управляющую прошивку. В некоторых случаях отдельно будем указывать, что речь идёт о аппаратной либо программной части.

BMC запитан отдельно от основной системы, включается автоматически при подаче дежурного (standby) питания на сервер и работает, пока питание не отключится. Почти все сервисные процессоры умеют управлять питанием хоста, предоставлять доступ к консоли главной операционной системы через Serial Over LAN (SoL), считывать показания системных датчиков (скорость вентиляторов, напряжение на блоках питания и VRM, температура компонентов), следить за исправностью компонентов, хранить аппаратный лог ошибок (SEL). Многие предоставляют возможности удаленного KVM, виртуальных медиа (DVD, ISO), поддерживают различные протоколы out-of-band подключения (IPMI/RMCP, SSH, RedFish, RESTful, SMASH) и прочее.

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

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

В современной инфраструктуре BMC является не просто приятной дополнительной опцией удалённого управления сервера (хотя не ходить в серверную, где холодно, шумно, негде присесть и плохо ловит мобильный — это приятно). Во многих ситуациях это критический компонент инфраструктуры. Когда операционная система или приложение не отвечает или находится в непонятном состоянии, сервисный процессор является единственным источником информации и способом быстро восстановить работу.

IPMI

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

Обычно сервисный процессор основан на специализированных системах на кристалле (System-on-Chip, SoC), и стандартом де-факто описания требований к архитектуре аппаратной части является спецификация IPMI (Intelligent Platform Management Interface). Это достаточно старый стандарт, ещё в 1998 году группа компаний разработала первую спецификацию IPMI для стандартизации управления сервером.

IPMI предусматривает общий интерфейс сообщений для доступа ко всем управляемым компонентам в системе и описывает большой набор интерфейсов для разных типов операций — например, мониторинга температуры, напряжения, скорости вентиляторов, или получения доступа к консоли ОС. Также предусмотрены методы для управления питанием всего комплекса, получения аппаратных логов SEL (System Event Log), считывания данных сенсоров (SDR), реализации аппаратных watchdog’ов. IPMI предоставляет замену или абстракцию для отдельных методов доступа к сенсорам, таких как System Management Bus (SMBus) или Inter Integrated Circuit (I2C). В большинстве BMC используют проприетарный IPMI стек от небольшого числа вендоров.

Претензии к IPMI

К протоколу накопилось много претензий, в том числе в части безопасности при доступе по сети (IPMI over LAN). Периодически сеть сотрясают истории, подобные этой. Дело вот в чем — получив доступ к сервисному процессору, мы получаем полный контроль над сервером. Ничто не мешает перезагрузиться в recovery mode и поменять пароль для ‘root’-учётки. Единственным надёжным средством от подобной уязвимости является правило, что IPMI траффик (UDP порт 623) не должен выходить за пределы специально выделенной сети или VLAN. За активностью в управляющей сети должен быть строгий контроль.

Кроме проблем c безопасностью, аппаратный ландшафт датацентров сильно изменился за минувшие годы. Распространились виртуализация, дезагрегация компонентов, облака. В протокол IPMI сложно добавлять что-то новое. Чем больше серверов надо администрировать, тем выше значение автоматизации процедур. Появляются спецификации API, призванные заменить IPMI over LAN. Многие возлагают надежды на RedFish.

Этот API использует современные JSON и HTTPS протоколы и RESTful интерфейс для доступа к данным ‘out-of-band’. Цель разработки нового API — предложить отрасли единый стандарт, который подходил бы для гетерогенных датацентров. Причем и для одиночных сложных enterprise серверов и для облачных датацентров из множества commodity серверов. И этот API должен отвечать актуальным требованиям безопасности.

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

Роль BMC в жизни сервера. На этой картинке SMS означает «System Management Software». Картинка взята отсюда.

Роль BMC в загрузке системы OpenPOWER

В сердце аппаратной части протокола IPMI находится чип BMC. Он задействован в работе сервера, начиная с момента подачи питания и участвует в процессе начальной загрузки сервера на OpenPOWER. То есть BMC необходим для включения системы. В то же время перезагрузка/падение BMC не влияет на уже работающую операционную систему.

Роль BMC в этапе загрузке Power off -> Standby

Когда система в режиме ‘standby’, и нажата кнопка включения питания, BMC инициирует продолжение загрузки и запускает на мастер-процессоре «маленький» контроллер SBE (Self Boot Engine) внутри POWER8 чипа на загрузку Hostboot микрокода из PNOR-флэша в L3 кэш мастер-процессора.

Микрокод Hostboot отвечает за инициализацию шин процессора, SDRAM памяти, остальных процессоров POWER8, OPAL (Open Power Abstraction Layer) и еще одного микроконтроллера встроенного в POWER8, называемого OCC (On Chip Controller).

Об этом контроллере расскажем чуть подробнее, так как для BMC он имеет особое значение. Когда Hostboot заканчивает свою работу, из PNOR флэша запускается следующий компонент микрокода Skiboot. Этот уровень синхронизирует процессоры, инициализирует шины PCIe, а также взаимодействует с BMC через IPMI (например, обновляет значение сенсора «FW Boot progress»). Skiboot также отвечает за запуск следующего уровня загрузки Petitboot, который выбирает, откуда будет загружена основная операционная система, и запускает ее через вызов kexec.

Но сделаем шаг назад, и вернёмся к OCC. Чип OCC представляет собой ядро PPC 405, встроенное в процессор IBM POWER8 вместе с основными ядрами POWER8 (один ОСС на чип). У него есть собственные 512 КБ SRAM, доступ к основной памяти. Это система реального времени, ответственная за температурный контроль (мониторинг температур памяти и процессорного ядра), управление производительностью памяти, отслеживание напряжения и частоты процессора. OCC предоставляет доступ ко всей этой информации для BMC по шине I2C.

Что именно делает OCC?

• Отслеживает состояние электропитания компонентов сервера.
• Отслеживает и контролирует температуру компонентов; в случае перегрева снижает производительность памяти (memory throttling).
• Если необходимо, OCC снижает частоту/энергопотребление процессора за счет снижения максимального P-state (performance state, см. ACPI). При этом OCC не задаёт P-state напрямую. Он задает лимиты, в рамках которых операционная система может менять P-state.
• Предоставляет BMC информацию о питании и температуре для эффективного управления вентиляторами.

Таким образом, OCC является поставщиком информации для BMC, к которому подключен по шине I2C. Исходный код большей части микрокода для POWER8 (и в частности для OCC) был открыт IBM.

Кроме взаимодействия с OCC и центральным процессором по шине LPC, у BMC есть и другие интерфейсы. Например, для управления блоками питания и LED используется GPIO на чипе BMC, для чтения сенсоров может использоваться I2C.

Взаимосвязь всего вышеупомянутого не так уж сложна

На данный момент большая часть микрокода OpenPOWER является открытой. При этом программная часть сервисного процессора и стек IPMI до недавнего времени оставались проприетарными. Первым open source проектом для сервисного процессора стал OpenBMC. Сообщество встретило его с воодушевлением и стало активно развивать. Про OpenBMC и поговорим дальше.

OpenBMC, его история и особенности

Наконец, мы подходим к истории появления OpenBMC и том, как мы его используем.

Рождение OpenBMC в Facebook

Через несколько месяцев OpenBMC официально был выпущен вместе с коммутатором Wedge, а еще через некоторое время исходный код OpenBMC был открыт в рамках партнерства OCP.

OpenBMC имеет три слоя:

• SoC уровень (ядро Linux, bootloader, C library).
• уровень платформы/продукта (пакеты специфичные именно для конкретного продукта, настройки ядра, библиотеки для сенсоров).

OpenBMC легко портируется с одной платформы на другую с помощью пересборки несколькими командами bitbake. Это позволяет использовать один и тот же BMC и как следствие один API на разных аппаратных платформах. Этим можно сломать сложившуюся традицию зависимости программного стека от аппаратной части.

Fork проекта в IBM

Сообщество OCP быстро прониклось идеей OpenBMC, и в разработку активно включился другой участник OCP – IBM. Их стараниями возник форк проекта под OpenPOWER, и к августу 2015 была выпущена первая версия OpenBMC для сервера Rackspace Barreleye под SoC AST2400. Инженеры IBM решительно взялись за дело и не просто адаптировали OpenBMC под новую платформу, а значительно его переработали. При этом из-за сжатых сроков и для простоты разработки активно использовали Python.

Предусмотрен web-доступ к REST API (для отладки, к примеру) через фреймворк Python Bottle.
Благодаря легкой портируемости OpenBMC с одной платформы на другую, для разработки могут использоваться отладочные платы, вплоть до RaspberryPI. Для упрощения разработки предусмотрена сборка под эмулятор QEMU.

Сейчас OpenBMC имеет достаточно аскетичный консольный интерфейс через SSH. IPMI поддерживается со стороны хоста в минимальном объеме. REST-интерфейс может использоваться приложениями для удаленного управления и мониторинга. Часть наиболее популярных функций реализована через команду obmcutil.

Наверное, 90% операций, выполняемых через BMC, — это включение/выключение сервера. В OpenBMC это делается командами obmcutil poweron и obmcutil poweroff.

Также, к примеру, через obmcutil можно посмотреть значение сенсоров и подробную информацию про аппаратную часть сервера (FRU), если это поддерживается на конкретной платформе:

obmcutil getinventory
obmcutil getsensors

Сейчас, в проекте OpenBMC активно участвует не только IBM, но и много других вендоров, заинтересованных в уходе от закрытого стека BMC. Сам IBM сосредоточен в основном на адаптации под платформу P9.

Большая часть разработки OpenBMC ведется под лицензией Apache-2.0, но в состав OpenBMC входит множество компонентов с разными лицензиями (например, ядро Linux и u-boot под GPLv2). В результате получается микс из разных open source лицензий. Кроме того, разработчики могут добавлять в конечную сборку собственные проприетарные компоненты, которые работают параллельно с Open Source.

Наш взгляд на OpenBMC

Как понятно из текста выше, программную часть своего сервисного процессора мы проектируем на основе OpenBMC. Продукт еще сырой, но самый минимум функций для администрирования сервера в нем уже реализован, частично реализован IPMI (для самых базовых потребностей). Сервисные процессоры в серверах с таким набором возможностей были на рынке несколько лет назад.

OpenBMC постоянно изменяется и совершенствуется, почти каждый день на gerrit сервере можно увидеть новые коммиты. Поэтому сильно концентрироваться на функциональности в данный момент — дело не очень благодарное. Непрерывно выполняется рефакторинг, код на Python заменяется на C/C++, больше функций переносятся в systemd.

Отношение к сервисному процессору, как к обычному серверу нетипично для BMC из-за его важной роли в жизни сервера. Использование systemd и D-Bus не было распространено в этой области раньше. Новое время — новые веяния.

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

Чтобы удаленно управлять состоянием серверной платформы, системные администраторы и инженеры пользуются технологией IPMI, которая значительно упрощает им жизнь. Теперь не надо каждый раз бежать к серверу, чтобы нажать на кнопку перезагрузки ― своевременно реагировать на критические неполадки можно сидя дома в уютном кресле. В этой статье рассмотрим основные компоненты IPMI и детали работы технологии.

Что такое IPMI

Аббревиатура IPMI расшифровывается как Intelligent Platform Management Interface (интеллектуальный интерфейс управления платформой). Через IPMI можно удаленно подключиться к серверу и управлять его работой:

• Проводить мониторинг физического состояния оборудования, например, проверять температуру отдельных составляющих системы, уровни напряжения, скорость вращения вентиляторов
• Восстанавливать работоспособность сервера в автоматическом или ручном режиме (удаленная перезагрузка системы, включение/выключение питания, загрузка ISO-образов и обновление программного обеспечения)
• Управлять периферийными устройствами
• Вести журнал событий
• Хранить информацию об используемом оборудовании

Допустим, инженер перенастраивает сеть на сервере, допускает ошибку в конфигурации и теряет доступ по SSH. Как теперь «достучаться» до сервера? Можно подключиться по IPMI и поменять настройки.

IPMI хорош тем, что перечисленные выше функции доступны вне зависимости от работы процессора, BIOS или операционной системы (ОС) управляемой платформы. Например, можно удаленно перезагрузить сервер, если зависла ОС, или поискать причину выхода из строя CPU в журнале системных событий. Управлять можно даже выключенным сервером ― достаточно того, что сервер подключен к электрической сети.

После того как сервер смонтировали и подключили к сети, инженеры Selectel настраивают BIOS и IPMI. Дальше можно выйти из шумной серверной и продолжить настраивать оборудование удаленно. Как только первоначальная настройка закончена, клиенты Selectel могут управлять работой выделенных серверов и серверов произвольной конфигурации через IPMI.

Историческая справка
Первую версию спецификации IPMI v1.0 разработали совместно компании Intel, Dell, NEC и Hewlett-Packard в 1998 году. На практике обнаружились уязвимости и недостатки, которые исправили в последующих версиях IPMI v1.5 и v2.0.

Спецификация IPMI стандартизирует интерфейс общения, а не конкретную реализацию в «железе», поэтому IPMI не требует использования специальных запатентованных устройств и определенных микроконтроллеров. Производители, придерживаясь спецификаций, разрабатывают собственное оборудование IPMI, встроенное в серверные платформы:

Компании устанавливают свои цены на предоставляемую технологию. Если стоимость реализации IPMI увеличивается, цена аренды сервера растет, так как напрямую зависит от стоимости расходников.

Решения производителей отличаются между собой:

• Наглядностью информации о состоянии оборудования
• Уникальным набором приложений для восстановления работоспособности сервера, если отказали какие-либо комплектующие
• Возможностью собирать статистику по всем комплектующим сервера, в том числе подключенным через карты расширения PCI, NVM и т.д.
• Использование технологии не только в серверном оборудовании, но и с обычными компьютерами через платы расширения PCI-Express

На деле для комфортной работы с удаленной консолью и своевременного оповещения о проблемах достаточно базового функционала IPMI.

Хотя производители предоставляют измененный и доработанный IPMI, реализация его архитектуры остается схожей. Разберемся, из чего состоит технология, опираясь на официальную спецификацию компании Intel.

Базовые компоненты любого IPMI

В центре архитектуры — «мозг» IPMI, микроконтроллер BMC (Baseboard Management Controller). Через него как раз и происходит удаленное управление сервером. По сути, BMC ― это отдельный компьютер со своим программным обеспечением и сетевым интерфейсом, который распаивают на материнской плате или подключают как плату расширения по шине PCI management bus.

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

К BMC можно подключить дополнительные контроллеры управления (Management Controllers, MCs), чтобы расширить возможности базового управления. Например, в то время как основная система управляется функциями BMC, MCs подключаются для мониторинга различных подсистем: резервных источников питания, RAID-накопителей, периферийных устройств.

MCs поставляются самостоятельными платами, отдельными от центрального BMC, поэтому их также называют Satellite Controllers. Дополнительных контроллеров может быть несколько, а вот центральный BMC — один.

К BMC контроллеры подключаются через интерфейс IPMB (Intelligent Platform Management Bus ― шина интеллектуального управления платформой). IPMB ― это шина на основе I2C (Inter-Integrated Circuit), по которой BMC перенаправляет команды управления к различным частям архитектуры:

• Общается с дополнительными контроллерами (MCs)
• Считывает данные сенсоров (Sensors)
• Обращается к энергонезависимому хранилищу (Non-Volatile Storage)

Архитектура IPMI реализована так, что удаленный администратор не имеет прямого доступа к компонентам системы. Например, чтобы получить данные с сенсоров, удаленный администратор посылает команду на BMC, а BMC в свою очередь обращается к сенсорам.

Кроме передачи команд на BMC можно настроить автоматическое выполнение действий контроллером с помощью следующих механизмов:

Энергонезависимое хранилище

Энергонезависимое хранилище остается доступным даже при сбое CPU сервера, например, через локальную сеть; состоит из трех областей:

• System Event Log (SEL) ― журнал системных событий
• Sensor Data Record (SDR) Repository ― репозиторий, хранящий данные о сенсорах
• Field Replaceable Units (FRUs) Info ― инвентарная информация о модулях системы

Модули системы генерируют (Event Generator) или получают (Event receiver) события. MCs выступают в качестве генераторов событий, а BMC в архитектуре может выполнять обе роли. BMC получает сообщения о событиях по системному интерфейсу и IPMB, затем регистрирует их в System Event Log (SEL).

К реализации SEL есть обязательные требования:

• SEL хранит в памяти не меньше 16 событий
• К информации, хранящейся в SEL, можно получить доступ вне зависимости от доступа к BMC и состояния управляемой платформы

Команды IPMI допускают чтение и удаление SEL. Поскольку память SEL ограничена, периодически журнал надо проверять и очищать, чтобы записывались новые события. В настройках BMC можно сконфигурировать автоочистку SEL. Автоочистка на различных платформах происходит по-разному — стирая старые записи, чтобы заполнить новые, или очищая всю историю.

Сообщение о событии несет в себе информацию из областей SDR Repository и FRU Info.

Записи SDR — это данные о типах и количестве сенсоров, их возможности генерировать события, типы показаний. SDR также содержат записи о количестве и типах устройств, подключенных к IPMB. Записи SDR хранятся в области памяти, которая называется SDR Repository (Sensor Data Records Repository).

Записи FRU содержат информацию о серийных номерах и моделях деталей различных модулей системы — процессора, платы памяти, платы ввода-вывода, контроллерах управления.

Информация FRU может предоставляться через MC (командами IPMI) либо через доступ к чипам энергонезависимой памяти SEEPROM (Serial Electrically Erasable Programmable Read Only Memory), подключенным по шине Private Management Bus. По этой шине контроллеры общаются через низкоуровневые I2C-команды с устройствами, которые не поддерживают IPMI-команды.

Практическое применениеДопустим, клиент жалуется на зависания сервера, но в логах операционной системы всё в порядке. Смотрим SEL ― видим ошибки по одной из планок оперативной памяти с указанием информации о слоте, в котором она находится. Меняем ― сервер начинает работать как часы.

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

Структура IPMI-команд

IPMI передает сообщения в формате запрос-ответ. Запросы — это команды. Команды инициируют действия и устанавливают значения. Формат запрос-ответ делает возможным одновременное общение нескольких контроллеров по одной шине.

Сообщения IPMI содержат базовый набор полей, единый для всех команд:

• Network Function (NetFn) присваивает команде значение кластера, к которому команда относится (команды шасси, событий, хранилища и т. д.)
• Поле Request/Response Identifier нужно, чтобы различать запросы и ответы
• Requester’s ID — информация об источнике сообщения. Например, для IPMB эта информация содержит LUN (Logical Unit Number) устройства
• Responder’s ID адресует запрос к желаемому ответчику
• Command — уникальные в рамках Network Function команды
• Data — дополнительные параметры (например, данные, возвращаемые в ответе)

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

Каналы, по которым передаются сообщения, можно разделить на три категории с соответствующими интерфейсами:

• BMC ― MCs, Sensors, Storage (IPMB)
• BMC ― управляемая платформа (System Interface)
• BMC ― удаленный администратор (LAN, Serial Interface)

В этой модели BMC можно воспринимать как коммутатор, который связывает между собой интерфейсы системы (в терминологии спецификации ― Bridging):

• Serial ↔ IPMB
• Serial ↔ System Interface
• LAN ↔ IPMB
• LAN ↔ System Interface
• Serial ↔ PCI Management Bus
• LAN ↔ PCI Management Bus
• Другие комбинации, в том числе Serial ↔ LAN

При доставке через разные интерфейсы архитектуры базовый набор полей дополняется номерами каналов и фреймами. Например, протокол IPMB добавляет адресные поля и поля для проверки целостности передаваемых данных, а LAN инкапсулирует команды IPMI в UDP/IP пакеты.

Интерфейсы удаленного доступа

В начальной версии IPMI удаленная консоль подключалась к модулю BMC через последовательный интерфейс (Serial Interface). Спецификация IPMI v2.0 базируется на использовании сетевого интерфейса (LAN Interface).

• Сообщения IPMI формируются в пакеты IPMI Session (позже в статье мы подробнее рассмотрим формирование IPMI Session)
• Пакеты IPMI Session инкапсулируются по протоколу RMCP (Remote Management Control Protocol)
• RMCP-пакеты формируются в UDP datagrams
• Добавляются фреймы Ethernet

Последовательный интерфейс для подключения удаленной консоли к BMC уже не используется, однако он нужен для реализации двух функций:

• Serial Port Sharing
• Serial-over-LAN (SoL)

Serial Port Sharing ― это возможность использовать общий последовательный коннектор между последовательными контроллерами BMC и управляемой системы. Обычно Serial Port Sharing используется для реализации BIOS Console Redirection, то есть перенаправления BIOS-консоли на модуль BMC.

Serial-over-LAN нужен для взаимодействия с компонентами системы, которые понимают только последовательный интерфейс общения. Еще можно из консоли сервера посылать команды напрямую к устройствам сервера (чипам, картам, дискам и так далее). SoL реализован так, чтобы работать совместно с функцией Serial Port Sharing.

Сеанс и аутентификация

Для LAN и последовательного интерфейса началу передачи IPMI-сообщений предшествует установление сеанса, в ходе которого формируются пакеты данных IPMI Session.

Установление сеанса ― это аутентификация конкретного пользователя. Сеанс должен быть активирован перед началом передачи IPMI-сообщений по следующему алгоритму:

• Удаленная консоль запрашивает данные по аутентификации у BMC
• BMC посылает ответ о поддерживаемых типах аутентификации (none, password, алгоритмы MD2 и MD5 и т.д.)
• Если пользователь имеет привилегии доступа к каналу, BMC посылает ответ, содержащий ID сеанса. Благодаря назначению ID, несколько сеансов могут работать одновременно на одном канале (согласно требованиям спецификации ― не менее четырех одновременных сессий)
• Удаленная консоль посылает запрос активации сеанса. Запрос содержит ID сеанса и аутентификационную информацию (имя пользователя, пароль, ключи ― зависит от выбранного типа аутентификации)
• BMC верифицирует информацию о пользователе, утверждает ID сеанса и посылает ответ об активации

Сеансы автоматически прерываются, если в течение заданного интервала не выполняется никаких действий или если соединение разорвано.

Доступ к BMC можно заблокировать, отправив одновременно множество запросов об активации сеанса, тогда все ресурсы будут использоваться для отслеживания сессий, требующих активации. Чтобы предотвратить возможную атаку, в реализации BMC рекомендуется применять алгоритм LRU (Last Recently Used). Алгоритм утверждает ID сеанса для наиболее раннего запроса активации сеанса. Например, удаленная консоль запускается через браузер в noVNC-сессии. Если открыть несколько вкладок с запущенными сессиями, текстовый ввод будет доступен в наиболее ранней открытой вкладке.

Когда IPMI становится недоступен

IPMI помогает восстановить работоспособность сервера при его сбое. Однако может случиться так, что становится недоступна система удаленного управления. Сбои в работе IPMI можно разделить на четыре категории:

• На уровне сети. «Битые» порты, нерабочее оборудование, дефект кабеля, плохо обжатая витая пара
• На уровне ПО. Баг системы, зависание модуля BMC, необходимость обновить прошивку модуля
• На уровне «железа». Перегрев, выход из строя критичных комплектующих (память, процессор), дефекты архитектуры системы
• На уровне питания. Отключение питания BMC или проблемы с блоком питания сервера

Перечисленные факторы влияют как на работу IPMI, так и на сам сервер. Модуль BMC ― это независимый от сервера чип, и отказ данного микроконтроллера говорит об отказе сервера в 90% случаев.

IPMI на практике

Управлять сервером по IPMI можно через веб-браузер, утилиты, предоставляемые производителями, и утилиты с открытым исходным кодом.

Веб-интерфейс у каждой реализации IPMI свой, но принцип доступа остается одинаковым:

В Selectel мы работаем с IPMI-модулями компаний Intel, Asus и Supermicro. В качестве примера посмотрим на веб-интерфейс Supermicro:

Возможности веб-интерфейса также реализованы в графической утилите Supermicro IPMIView:

Чтобы управлять оборудованием через Linux-консоль, устанавливается соответствующая утилита (например, Ipmitool для локального и удаленного управления или IPMICFG для локального). Далее при помощи консольных команд добавляется IPMI-устройство и конфигурируется BMC.

Клиентам Selectel доступен IPMI для выделенных серверов и серверов произвольной конфигурации. IPMI реализован в виде KVM-консоли, которая запускается в noVNC-сессии через панель управления. Для этого в карточке с информацией о сервере надо нажать на значок консоли в правом верхнем углу:

Консоль открывается в браузере и подстраивается под размер экрана. При желании консоль можно использовать даже через телефон или планшет.

Сессия прерывается, если выйти из панели.

Заключение

IPMI ― это полностью автономный компонент серверной платформы, который не зависит ни от операционной системы, ни от BIOS, ни от CPU сервера.

Благодаря IPMI, затраты на обслуживание серверных систем сокращаются, а жизнь системных администраторов становится проще. Нет необходимости постоянного присутствия рядом с оборудованием ― его работа контролируется удаленно по сети.

В этой статье мы рассмотрели основные компоненты IPMI. Однако детали технологии обширны. Талантливые разработчики, опираясь на спецификацию, могут создавать свое IPMI-оборудование и open-source инструменты, попутно устраняя недостатки текущей спецификации и открывая новые возможности удаленного управления.

Материалы, использованные в статье:

Спецификация IPMI v2.0
Официальная документация Supermicro

Плата управления сервером — зачем она и что внутри

Всем привет! С вами снова Максим. Сегодня немного расскажу про плату управления для нашего сервера. В общем-то, она не отличается особенной сложностью, но и пропускать этот компонент тоже никак нельзя — мы с коллегами решили, что все существенные подсистемы и компоненты сервера должны быть освещены.

Можно ли обойтись без этой платы?

Тут, может быть, сразу последует вопрос — а зачем вообще выносить функции управления с материнской платы на отдельную карточку? Зачем умножать число компонентов, не проще ли всё засунуть на материнку, как это обычно делают производители серверов?

Согласен, в обычных условиях и мы поступили бы именно так — но в этом проекте и в таком вопросе пришлось поступить нестандартно. Из-за плотности компоновки материнской платы просто не было лишнего места для размещения чипов BMC, USB-хоста, PCIe-коммутатора и разводки всех связанных с ними цепей. А кроме того, просто не было места на задней панели шасси для установки коннекторов Ethernet/USB напрямую на материнской плате. В общем, мы решили не усложнять и без того сложную системную плату, и вынесли все эти компоненты на отдельную плату управления. Этот способ, кроме всего прочего, даёт больше гибкости в плане будущих доработок и изменений.

Что внутри?

Собственно, структурная схема платы весьма проста:

Структурная схема платы управления сервером.

Главный компонент — чип BMC ASPEED AST2400, очень популярный и наверняка многим хорошо знакомый. У него есть своя выделенная память DDR3 объёмом 512 МБ.

Под спойлером краткая ориентировка про BMC, вряд ли интересная опытным в этих сферах людям.

BMC — это Baseboard Management Controller, контроллер управления системной платой. Он включается при подаче дежурного напряжения на системную плату (т.е. когда кабель подключается к блоку питания), загружает Linux из собственной ROM-памяти. В рабочем режиме мониторит работу системы — собирает информацию с датчиков (обороты вентиляторов, температуры, напряжения и токи на компонентах, датчик проникновения в корпус), считывает коды ошибок памяти, позволяет управлять компонентами системы как автоматически, так и вручную через сеть. Ведёт журналы мониторинга системы, может включать/выключать/перезагружать систему, обновлять прошивку ROM хоста, и т.д. В общем, недремлющая рабочая лошадка.

К BMC подключен хост USB3.0, для которого мы используем чип TI7340. От него два порта USB3.0 выводятся наружу. Также к BMC прицеплен двухканальный контроллер Gigabit Ethernet (BCM5720), порты которого выведены наружу. Это очень распространённый контроллер, который отлично поддерживается архитектурой POWER.

Всю эту компанию объединяет PCIe-коммутатор (по цене оптимально было поставить PEX8714), напрямую присоединённый к разъёму для подключения к системной плате. Он разводит PCIe x4 на x2 и 2 по x1.

Разъём для подключения к системной плате имеет небольшую особенность. Сам-то коннектор полностью стандартный. Но чтобы полностью исключить установку платы управления в обычный PCIe-слот (на материнке у нас есть специальный выделенный слот для платы управления), мы развернули коннектор на 180 градусов и сдвинули его относительно стандартного для PCIe размещения.

На схеме можно также заметить видеовыход VGA и два последовательных порта — их наружу не выводили, оставили в виде header-ов. Они нужны в основном для отладочных целей — да и на внешней панели низкопрофильной PCIe-карты просто не осталось места после размещения двух USB и двух Ethernet портов.

Как выглядит плата

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

В левой стороне изображения задняя панель платы — из неё выведены 2 порта USB3.0, а под ними — сдвоенные порты GbE.

Покажу и нашу любимую техноживопись дорожками по плате:

Сигналы и питание разведены по 8 слоям.

Считаю, отлично годится, чтобы распечатать в цвете и повесить на стенку — нарядно, воодушевляюще, и очень жизненно! 🙂

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

• зафиксировать требования к прошивке и расставить приоритеты по их реализации;
• поднять исходный вариант на нашем сервере (адаптировав базовый функционал к нашему железу);
• добавить нужный для нас функционал.

Получившуюся в результате версию, естественно, в OpenBMC будем коммитить.

Расшифровка аббревиатуры

Транскрипция сокращения

Big Mike’s Choppers

Чопперы большого Майка

Bulk Mail Center

Массовая Рассылка Центра

Bankrupt Motor Carrier

Business Membership Center

BMC Software, Inc.

British Motor Corporation

Британская Автомобильная Корпорация

Bulk Molding Compound

Навальная Смесь Прессформы

Контроллер Управления Основной Платой

Bicycle Manufacturing Company

Велосипед Производственная Компания

Bring Much Cash

Принесите Много Наличных Денег

Brethren Mennonite Council

Братьев Меннонитов Совета

Basic Minimum Capital

Базовый Минимальный Капитал

Build My Church

Построю Мою Церковь

Black Marine Corps

Черный Морской Пехоты

Business Management Company

Управление Бизнесом Компании

British Mountaineering Council

Британского Альпинистского Совета

Chief Boatswain’s Mate

Помощник главного боцмана

Bone Mineral Content

Содержание Минералов В Костной Ткани

Bible Missionary Church

Библейская Миссионерская Церковь

Контроллер Памяти Пузыря

Burlington Medical Center

Медицинский Центр Burlington

Binghamton Manufacturing Corporation

Бингемтон Производственная Корпорация

Big Mikes Choppers

Большая Микрофоны Измельчители

Battle Management Cell

Управление Боевой Ячейки

British Museum Collection

Коллекции Британского Музея

Случайное сокращение

What does BMC mean? We have 627 definitions. Read most used BMC meanings below.

Notice

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the cookie policy.