Погляд зсередини на OpenBMC стосовно систем OpenPOWER

одній з попередніх статей Максим торкнувся апаратну частину плати 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) та інше.

Зараз віддалене управління повсюдно поширилося. Воно полегшує управління великим парком серверів, підвищує доступність з-за скорочення часу простою, і покращує операційну ефективність датацентрів. Як наслідок, наявність широких можливостей віддаленого менеджменту враховується клієнтами при виборі постачальника апаратної платформи.

Користувачами BMC в основному є сисадміни для віддаленого управління, відновлення після збоїв, збору логів, встановлення ОС і т. д. Даними з сервісного процесора користується техпідтримка. Для неї BMC часто є єдиним джерелом інформації при усуненні збоїв і виявленні несправних компонентів для заміни.

У сучасній інфраструктурі BMC є не просто приємною додатковою опцією віддаленого сервера керування (хоча не ходити в серверну, де холодно, шумно, ніде присісти і погано ловить мобільний — це приємно). У багатьох ситуаціях це критичний компонент інфраструктури. Коли операційна система або програма не відповідає або знаходиться в незрозумілому стані, сервісний процесор є єдиним джерелом інформації і способом швидко відновити роботу.

Для підключення до сервісного процесору використовують виділений мережевий порт (out-of-band), або ж BMC ділить мережевий порт з основною системою (sideband). Тобто один фізичний Ethernet-коннектор, але два незалежних MAC і дві IP-адреси. Для первісної налаштування часто використовують консольне RS-232 підключення.

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 і процесор POWER8 з'єднані шиною LPC (Low Pin Count). Ця шина призначена для зв'язку процесора з периферійними, відносно повільними пристроями. Вона працює на частоті 33 МГц. Через LPC центральний процесор (тобто мікрокод Hostboot/OPAL) спілкується з IPMI стеком BMC BT ( стор 104) інтерфейсу. По цій шині POWER8 отримує завантажувальний мікрокод з PNOR (Processor NOR chip) через LPC → SPI (Serial Peripheral Interface) з'єднання.

Роль BMC на етапі завантаження Power off -> Standby
Перший етап завантаження починається, як тільки блоки живлення включені в мережу і закінчується на стадії, коли BMC повністю включився і готовий розпочати завантаження всього хоста. Забігаючи вперед, відзначу, що звідси і далі описую роботу ПО BMC на OpenPOWER-системах взагалі, але конкретно в нашому сервері ці функції виконує OpenBMC. При подачі живлення BMC починає виконувати код з SPI flash, завантажує u-boot і потім ядро Linux. На даному етапі на BMC працює IPMI, шина LPC підготовлена для доступу хоста до PNOR пам'яті (монтується через mtdblock). Сам чіп POWER8 на даному етапі вимкнений. У цьому стані можна підключитися до мережного інтерфейсу BMC і щось вдіяти.

Standby -> OS boot
Коли система в режимі «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 в компанії Facebook при розробці світча Wedge в рамках співтовариства OCP в 2015 році. Спочатку програмну частину BMC розробляв постачальник заліза. У перші місяці роботи виникло багато нових вимог до BMC, координація яких з розробниками була складною і викликала затримки. Під впливом цього, на одному з хакатонов чотири інженера Facebook реалізували деякі з базових функцій BMC за 24 години. До продуктива було дуже далеко, але стало ясно, що завдання реалізації софтверної частини BMC може бути вирішена окремо від апаратної.

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

Далі Facebook адаптував OpenBMC для NVMe флеш-полиці Lightning, а слідом і для шасі мікросерверів Yosemite. В останньому зміну Facebook відмовився від RMCP/RMCP+ (доступ IPMI over LAN), але з'явився REST API через HTTP(S) і консольний доступ по SSH. Таким чином, у Facebook вийшов єдиний API для керування різними типами обладнання та велика гнучкість реалізації нових фіч. З пропрієтарним підходом до BMC таке було б неможливо.

У концепції Facebook, BMC — звичайний сервер, але працює на ЅоС c обмеженими ресурсами (повільний процесор, мало пам'яті, невеликий флеш). З урахуванням цього, OpenBMC був задуманий як спеціалізований дистрибутив Linux, всі пакети якого збираються з вихідних за допомогою проекту Yocto. Опис всіх пакетів в Yocto об'єднуються в 'приписи' (recipes), які в свою чергу об'єднуються в 'шари' (layers).

OpenBMC має три шари:

  1. загальний рівень, user space додатки (не залежать від заліза).
  2. SoC рівень (ядро Linux, bootloader, C library).
  3. рівень платформи/продукту (пакети специфічні саме для конкретного продукту, налаштування ядра, бібліотеки для сенсорів).
Facebook не перший, хто став використовувати Yocto в BMC. На цій же системі складання побудований пропрієтарний Dell iDRAC.

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

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

Зміни торкнулися всіх шарів проекту, в тому числі перероблено ядро Linux під SoC (встановлювані драйвери, доданий device tree), на рівні користувача з'явився D-Bus для межпроцессорного взаємодії (у facebook D-Bus не було). Саме через D-Bus реалізовані всі функції OpenBMC. Основним способом роботи з OpenBMC є REST інтерфейс для доступу до інтерфейсів шини. Крім того, є Dropbear SSH.


Передбачений web-доступ до REST API (для відладки, наприклад) через фреймворк Python Bottle.
Завдяки легкій портируемости OpenBMC з однієї платформи на іншу, для розробки можуть використовуватися налагоджувальні плати, аж до RaspberryPI. Для спрощення розробки передбачена збірка під емулятор QEMU.

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

Напевно, 90% операцій, що виконуються через BMC, — це включення/вимикання сервера. У OpenBMC це робиться командами
obmcutil poweron
та
obmcutil poweroff
.

Також, наприклад, через
obmcutil
можна подивитися значення сенсорів і детальну інформацію про апаратну частину сервера (ФРУ) якщо підтримується на конкретній платформі:

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, щоб співтовариство могло користуватися.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.