Megarac sp что это
Перейти к содержимому

Megarac sp что это

  • автор:

MegaRAC

MegaRAC от американского Megatrends является продукт линией обслуживания процессоров обеспечивая полную вне зоны или отбой дистанционного управления компьютерными систем независимо от операционной системы состояния или местоположений для устранения неполадок компьютеров и гарантировать непрерывность обслуживания. Сервисные процессоры MegaRAC бывают разных форматов — карты PCI, встроенные модули и только программное обеспечение.

Контроллер удаленного управления MegaRAC был представлен в 1998 году компанией Dell, которая позже разработала DRAC . Карта второго поколения, MegaRACG2 (2002), обеспечивала консоль, графическое перенаправление KVM, межсетевой экран и резервное питание от батареи.

Прошивка MegaRAC SP

Прошивка MegaRAC SP состоит из четырех основных функциональных групп:

  • Полная реализация IPMI 2.0, обеспечивающая мониторинг датчиков и состояния, оповещение, регистрацию событий, последовательный порт по локальной сети и т. Д. Эта прошивка использует Linux 2.6.
  • Виртуальный KVM для перенаправления сигналов видео, клавиатуры и мыши. При этом используется собственная технология сжатия AMI.
  • Виртуальный носитель для перенаправления CD / DVD. Это используется для использования локального CD / DVD для установки операционной системы или программного обеспечения на удаленном хосте.
  • Инфраструктура управления, совместимая с DMTF, реализующая CIM, SMASH и WS-MAN.

Прошивка MegaRAC SP продается производителям оригинального оборудования (OEM), а не конечным пользователям.

Рекомендации

  • «American Megatrends предлагает на рынок сбыта карту удаленной помощи MegaRAC» . encyclopedia.com . Cengage Learning . Проверено 21 июня 2010 .
  • «MegaRAC G2» . scmagazineus.com . Хеймаркет. Архивировано из оригинала на 2013-02-01 . Проверено 18 июня 2010 .
  • «AMI MegaRAC: почти идеальный продукт» . theinquirer.net . Зарегистрироваться . Проверено 21 июня 2010 .
  • «AMI представляет стек микропрограмм служебного процессора MegaRAC SP для AST2000» . edageek.com 2007 . Online Destiny LTD . Проверено 21 июня 2010 .
  • «AMI объявляет о поддержке программного обеспечения MegaRAC SP для контроллера управления сервером ServerEngines Pilot» . serverengines.com . Серверные движки . Проверено 21 июня 2010 .
  • «AMI представляет MegaRAC SP для Winbond WPCM450» . Nuvoton 2008 . Проверено 21 июня 2010 .
  • «American Megatrends представляет MegaRAC PM для контроллера управления основной платой Renesas H8S / 2462» . AMI 2009 . Проверено 21 июня 2010 .
  • «American Megatrends отмечает двенадцать лет успеха с MegaRAC» . ami.com . AMI 2009 . Проверено 21 июня 2010 .

Redfish в GAGAR>IN BMC

На сегодняшний день большинство крупных производителей серверного оборудования, таких как (DELL, IBM, HP) включают поддержку RedFish в прошивки для своих BMC контроллеров (Baseboard management controller) Разумеется, разрабатывая серверы GAGAR>IN, мы также добавили поддержку Redfish в наш BMC, который построен на базе открытого проекта OpenBMC. В этой статье расскажем, для чего мы используем RedFish и какие преимущества он нам даёт.

Redfish — это, как всем известно, спецификация и открытый индустриальный стандарт, который пришёл на смену устаревшему IPMI. Он используется для управления серверным оборудованием посредством RESTful интерфейса. Redfish разрабатывается некоммерческой ассоциацией производителей DMTF (Distributed Management Task Force) с 2014 года и к настоящему моменту достаточно заматерел. Актуальная спецификация Redfish версии 1.12.0 была опубликована 21 января 2021 года.

Если по простому, то весь функционал Redfish можно разделить на две больше группы: мониторинг и управление. Большая часть схемы Redfish содержит информацию об инвентаризации системы и текущем состоянии отдельных компонент. Но есть также множество идентификаторов OData (Open Data Protocol), которые отвечают за управление, изменение настроек BMC/UEFI и выполнение определённых команд. В этой статье мы коснёмся лишь мониторинга.

Мониторинг

В рамках развития системы мониторинга Zabbix, о которой мы писали в предыдущей статье об OCP Experience Lab, стояла задача получения основных параметров работы наших серверов, таких как температура процессоров, потребляемая мощность, токи нагрузки, частоты вращения вентиляторов и т.д. в периоды простоя и максимальной нагрузки.

Среди опрашиваемых машин были как наши собственные серверы GAGAR>IN, так и модели других OCP производителей Wiwynn и MiTAC, произведенные по такой же спецификации Tioga Pass. При этом на серверах GAGAR>IN были установлены BMC контроллеры с прошивкой на основе OpenBMC, а на Wiwynn и MiTAC использовался MegaRAC SP-X от AMI (American Megatrends Inc.).

И GAGAR>IN BMC и AMI MegaRAC SP-X поддерживают RedFish в качестве RESTful веб API для получения данных о сенсорах. Причем обе реализации схемы Redfish минимально отличаются друг от друга, что позволило нам разработать универсальный шаблон для Zabbix. Но начнем с простого.

Модель работы Redfish

Любой запрос Redfish формируется агентом используя HTTPS протокол передачи данных. Как правило используется метод GET для получения данных, но может и быть POST, PATCH и DELETE для специфических операций, которые мы обсудим позже. В ответ на запрос сервер формирует ответ в JSON формате, который содержит запрашиваемую информацию или сообщение об ошибке. Типовой URI запроса выглядит следующим образом

Структура дерева ресурсов Redfish

Запрос к корневому элементу дерева ресурсов Redfish возвращает набор элементов «Collections», которые в свою очередь могут содержать подразделы и отдельные конечные элементы. Для реализации Redfish в OCP серверах определены следующие элементы:

https://www.opencompute.org/files/OCP-Summit-2018-OCP-Profile-for-Server-v5.pdf

Для примера, вышеуказанный запрос на получение основной информации о системе возвращает нам JSON примерно вот такого вида (для краткости приведён небольшой фрагмент):

 "Manufacturer": "GAGAR>IN", "Memory": < "@odata.id": "/redfish/v1/Systems/system/Memory" >, "MemorySummary": < "Status": < "Health": "OK", "HealthRollup": "OK", "State": "Enabled" >, "TotalSystemMemoryGiB": 48 >, "Model": "Tioga Pass Single Side", "Name": "system", "PartNumber": "HEPB.466216.007", "PowerRestorePolicy": "AlwaysOff", "PowerState": "On", "ProcessorSummary": < "Count": 2, "Model": "Intel Xeon processor", "Status": < "Health": "OK", "HealthRollup": "OK", "State": "Enabled" >>,

Но для задач мониторинга нас больше интересуют градусы Цельсия, амперы и вольты, поэтому следующий запрос мы шлём на URI:

В ответ получаем длиннющую «простыню», содержащую информацию о состоянии каждого датчика, установленного в системе, а их у нас в сервере несколько сотен. Привожу пример по одному датчику:

 "Temperatures": [ < "@odata.id": "/redfish/v1/Chassis/TiogaPass_Baseboard/Thermal#/Temperatures/53", "@odata.type": "#Thermal.v1_3_0.Temperature", "MaxReadingRangeTemp": 127.0, "MemberId": "Core_7_CPU1", "MinReadingRangeTemp": -128.0, "Name": "Core 7 CPU1", "ReadingCelsius": 22.0, "Status": < "Health": "OK", "State": "Enabled" >, "UpperThresholdCritical": 91.0, "UpperThresholdNonCritical": 81.0 >, ] 

Очевидно, что ReadingCelsius — это текущее значение температуры сенсора для Core 7 CPU1, UpperThresholdNonCritical — это порог высокой температуры, а UpperThresholdCritical — это значение критического состояния. Вот было бы здорово нарисовать эти значения на графике, да еще и генерировать оповещения при превышении UpperThresholdNonCritical. И так для каждого датчика.

Воодушевленные возможностью получения такого огромного массива оперативной информации мы задумались об инструменте для её автоматической обработки. И тут на сцену выходит LLD (low level discovery) от Zabbix.

Низкоуровневое обнаружение в Zabbix

Низкоуровневое обнаружение (Low Level Discovery) даёт возможность автоматического создания элементов данных, триггеров и графиков в Zabbix для различных объектов мониторинга. В нашем случае мы будем создавать элементы данных для каждого датчика, показания которого мы получили в нашем Redfish ответе.

Затем мы будем строить для этого элемента данных графики на основании накопленных данных. Будем также создать прототипы триггеров, которые будут срабатывать при превышении оперативных значении определенных пороговых значений, и отправлять нам сообщения в Телеграмм.

Но вот незадача, мы же не ставим агента Zabbix на BMC. Вместо этого мы хотим парсить ответ на Redfish запрос. Причем Zabbix ждет от нас данные в формате JSON. Но структура этих данных имеет вполне определенный формат который, конечно же отличается от того, что мы получили в Redfish ответе. Что ж, для решения этих задач придется написать пару скриптов!

Скрипты LLD для GAGAR>IN BMC

Но неужели никто до нас не сталкивался с подобной задачей? Быстрый поиск на Zabbix Share показал, что не только сталкивались, но и успешно решали её. В частности удалось найти замечательный фреймворк для DELL iDRAC. Пришлось внести некоторые изменения в скрипты, потому что DELL-овская реализация Redfish отличается от используемой в OpenBMC. В частности идентификаторы OData выглядят следующим образом для разных BMC:

Dell iDRAC: /redfish/v1/Systems/System.Embedded.1/Processors

AMI MegaRAC: /redfish/v1/Systems/Self/Processors

GAGAR>IN: /redfish/v1/Systems/system/Processors

Мы добавили в свои скрипты дополнительный параметр $TYPE, который позволял указывать тип BMC. В зависимости от этого подставлялись правильные идентификаторы OData.

Кроме этого пришлось повозиться с jq — замечательным обработчиком JSON, работающим в командной строке. Например, для получения заветного значения температурного датчика из приведенного выше JSON, пришлось использовать вот такую конструкцию:

cat $ | jq —arg TYPE «$TYPE» —arg NAME «$NAME» ‘.[$TYPE] | .[] | select(.Name==$NAME)’ | jq «.$» | tr -d «‘» | tr -d ‘»‘

где BATCH — это имя файла, TYPE = ‘Temperatures’, NAME = ‘Core 7 CPU1’, а ITEM = ReadingCelsius. Если кто-то предложит более оптимальный вариант разбора, мы будем очень признательны.

Первый скрипт на Ruby, делая запросы по верхнему уровню схемы Redfish, обнаруживает все доступные группы элементов данных из всех вышеуказанных «Collections»: Processors, Memory, Thermal, Power, Sensors. Настраиваем Zabbix на запуск этого скрипта раз в час — мы же не меняем набивку сервера каждые пять минут.

Второй скрипт на Ruby использует выявленные первым скриптом идентификаторы OData (Open Data Protocol) и выполняет по ним отдельные Redfish запросы, после чего сохраняет эти данные локально для дальнейшей обработки. Есть смысл настроить запуск этого скрипта в Zabbix раз в пять минут или даже чаще, если есть желание получить более дискретные графики.

Но стоит учитывать тот факт, что объем хранимых данных в Zabbix вырастет пропорционально, да и poller может не успеть опросить все серверы, особенно если их десятки или даже сотни в дата-центре.

Последний скрипт на простом bash выполняет простую функцию парсера полученного вторым скриптом файла. Он формирует вывод в JSON формате, который может понимать непосредственно Zabbix. Всю остальную красоту рисует для нас Zabbix.

Красивые графики

Создав в Zabbix шаблон для вызова вышеописанных скриптов, мы настроили создание отдельных прототипов данных для каждого обнаруженного датчика, а также прототипов триггеров для тех датчиков, которые имеют пороговые значения. Ну и конечно же не забыли добавить прототипы для графиков, которые вы можете посмотреть ниже.

Вольтаж батарейки UEFI. При снижении значения ниже 2.73 вольт, сработает триггер оповещения.TDP первого процессора в Ваттах. При нагрузке на процессор мощность существенно растёт.Температура 15 ядра первого процессора. При превышении 81С сработает триггер.

Что дальше?

В результате мы получили 745 элементов данных, 118 графиков и 355 триггеров для одного GAGAR>IN BMC. Разумеется, мониторинг это не самоцель, поэтому активные триггеры мы оставили для ключевых элементов данных, таких как перегрев процессоров, общий health-статус компонентов и превышение пороговых значений токов.

Набор скриптов и шаблон Zabbix оформлен в отдельный репозиторий на github, а также выложен на Zabbix Share Стрижка, как говорится, только начата, поэтому мы приглашаем всех пользователей оборудования OCP брать наши наработки за основу и дорабатывать их. Некоторые секции данных, такие как, например, Storage и ManagedBy, в наших скриптах не обрабатываются, и будет здорово, если их поддержка будет кем-то добавлена.

В следующей статье напишем, как мы используем Redfish для управления сервером.

Уязвимость в контроллерах AMI MegaRAC угрожает серверам AMD, ARM, HPE, Dell

Рекомендуем почитать:

Xakep #297. Язык самолетов

  • Содержание выпуска
  • Подписка на «Хакер» -60%

Эксперты обнаружили сразу три уязвимости в программном обеспечении MegaRAC BMC (Baseboard Management Controller) компании American Megatrends. Проблемы затрагивают серверное оборудование, используемое многими дата-центрами и поставщиками облачных сервисов.

Уязвимости были найдены специалистами компании Eclypsium в августе 2022 года, когда проприетарный код American Megatrends, в частности прошивки MegaRAC BMC, «утек» в сеть. Изучив прошивку, эксперты обнаружили баги, который при определенных условиях могут использоваться для выполнения произвольного кода, обхода аутентификации и составления списков пользователей.

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

MegaRAC BMC применяются как минимум 15 крупными производителями серверов, включая AMD, Ampere Computing, ASRock, Asus, ARM, Dell EMC, Gigabyte, Hewlett-Packard Enterprise, Huawei, Inspur, Lenovo, Nvidia, Qualcomm, Quanta и Tyan.

Исследователи выявили следующие проблемы, о которых уже уведомили American Megatrends и затронутых поставщиков:

  • CVE-2022-40259: критическая уязвимость, допускающая выполнение произвольного кода через API Redfish из-за некорректного раскрытия команд пользователю (9,9 балла из 10 возможных по шкале CVSS 3.1);
  • CVE-2022-40242: учетные данные по умолчанию для пользователя sysadmin, позволяющие злоумышленнику установить административный шелл (8,3 балла по шкале CVSS 3.1);
  • CVE-2022-2827: ошибка манипулирования запросами, позволяющая перечислить имена пользователей и определять, существует ли в системе конкретная учетная запись (7,5 балла по шкале CVSS 3.1).

Эксперты подчеркивают, что наиболее серьезная из трех уязвимостей, CVE-2022-40259, требует предварительного доступа хотя бы к учетной записи с низким уровнем привилегий для выполнения обратного вызова API. Однако для эксплуатации CVE-2022-40242 единственным условием является наличие удаленного доступа к устройству. Таким образом, первые две проблемы крайне серьезны, так как предоставляют злоумышленникам доступ к административной оболочке без необходимости дальнейшего повышения привилегий.

Третий недостаток не оказывает существенного влияния на безопасность, но дает представление о существовании тех или иных учтенных записей, а значит, может открыть прямой путь к перебору паролей или атакам типа credential stuffing (с подстановкой уже известных хакерам учетных данных).

«Эти уязвимости могут создать серьезные риски, если злоумышленник имеет доступ к BMC уязвимого сервера. В соответствии с передовыми практиками безопасности, BMC не должны быть открыты для прямого доступа из интернета, и сканирование, проведенное нами после первоначального раскрытия уязвимостей, показывает относительно низкую общедоступность (по сравнению с недавними громкими уязвимостями, найденными в других инфраструктурных продуктах).

Но довольно часто можно найти BMC, которые подвергаются риску либо из-за неправильной конфигурации, либо из-за плохой ИБ-гигиены. Кроме того, этими уязвимостями сможет воспользоваться злоумышленник, получивший первоначальный доступ к центру обработки данных или административной сети», — гласит отчет компании.

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

«Поскольку дата-центры имеют тенденцию стандартизировать определенные аппаратные платформы, любая уязвимость уровня BMC, скорее всего, коснется большого количества устройств и потенциально может затронуть весь центр обработки данных и услуги, которые тот предоставляет. Стандартизация серверных компонентов хостинговыми и облачными провайдерами означает, что эти уязвимости могут затрагивать сотни тысяч или даже миллионы систем», — предупреждают в Eclypsium.

Megarac sp что это

Функциональная совместимость Microchip и AMI упрощает разработку решений для удаленного управления внешними хранилищами, что снижает эксплуатационные расходы центров обработки данных.

Администраторы центров обработки данных и ИТ-менеджеры хотят иметь возможность безопасного удаленного управления платформами и устройствами и устранения неполадок, что требует сопряжения дополнительного программного обеспечения, аппаратного и программного обеспечения с адаптерами хранения и другими компонентами сервера. Компания Microchip Technology Inc. (Nasdaq: MCHP) сегодня объявила, что добавила эту возможность к своим адаптерам Adaptec Smart Storage, которые теперь беспрепятственно взаимодействуют с программным обеспечением для удаленного мониторинга и диагностики MegaRAC® SP-X от American Megatrends (AMI) и поддерживаются в его MegaRAC. рамки разработки решения.

«Наши адаптеры Adaptec Smart Storage теперь легко сочетаются с широко распространенными решениями от MegaRAC SP-X для удаленного хранения AMI, которые обеспечивают мониторинг серверных компонентов, автоматическое обнаружение проблем системы и другие виды диагностики из любой точки мира», — сказал Пит Хазен, вице-президент. президент подразделения Microchip Data Center Solutions. «Поддержка наших адаптеров в среде разработки MegaRAC ускоряет выход на рынок решений, обеспечивающих базовые функции удаленного управления, и позволяет легко настраивать их для поддержки дополнительных функций».

Функциональная совместимость между адаптерами Adaptec Smart Storage и микропрограммой управляемости MegaRAC SP-X, обеспечивающей питание встроенных контроллеров управления базами данных (BMC), снижает эксплуатационные расходы центра обработки данных, обеспечивая возможности удаленного управления, включая мониторинг состояния платформы и уведомления о проблемах, диагностику и восстановление. Внеполосное управление позволяет напрямую подключаться к адаптерам через сетевое соединение, если сервер выключен или не отвечает, и повышает безопасность, устраняя необходимость в проприетарном программном обеспечении или инструментах хоста на сервере или в системе хранения. AMI использует комбинацию широко распространенного протокола транспортного компонента управления (MCTP) и прикладного программного интерфейса (API) Microchip StorageCore, чтобы добавить базовую поддержку для адаптеров Adaptec Smart Storage в инструмент управления хранилищем среды разработки MegaRAC.

«Сочетание адаптеров Microtec ChipTime Adaptec Smart Storage с микропрограммой управления BMC MegaRAC SP-X значительно упрощает разработку решений для удаленного безопасного хранения, — сказал Стивен Биньо, директор по развитию бизнеса AMI. «Мы гордимся тем, что тесно сотрудничали с Microchip, чтобы добавить поддержку своих адаптеров в нашу инфраструктуру разработки MegaRAC и предоставим необходимые пакеты кода, инструменты и опыт разработки нашим взаимным клиентам, что позволит им ускорить TTM и расширить возможности управления платформой.»

Доступность

Доступны адаптеры Adaptec Smart Storage с поддержкой MegaRAC.

О Microchip:

Microchip Technology Inc. — ведущий поставщик интеллектуальных, подключенных и безопасных встроенных решений для управления. Его простые в использовании инструменты разработки и обширный портфель продуктов позволяют клиентам создавать оптимальные проекты, которые снижают риски и снижают общую стоимость системы и время выхода на рынок. Решения компании обслуживают более 120 000 клиентов на промышленном, автомобильном, потребительском, аэрокосмическом и оборонном, коммуникационном и вычислительном рынках. Microchip со штаб-квартирой в Чандлере, штат Аризона, предлагает отличную техническую поддержку, а также надежную доставку и качество.

Основанная в 1985 году и известная во всем мире AMIBIOS®, American Megatrends (AMI) поставляет новейшее оборудование, программное обеспечение и утилиты для ведущих производителей настольных, серверных, мобильных и встраиваемых систем. Ведущие в отрасли прошивки Aptio® V UEFI BIOS от AMI, а также решения MegaRAC® BMC и удаленного управления серверами продолжают завоевывать признание и награды во всем мире. В соответствии с разнообразием своих технологий и линейки продуктов AMI является членом многочисленных отраслевых ассоциаций и групп стандартов, таких как Объединенный форум EFI (UEFI) и Trusted Computing Group (TCG). Компания AMI со штаб-квартирой в Норкроссе, штат Джорджия, имеет отделения в США, Китае, Германии, Индии, Японии, Корее и Тайване, чтобы лучше обслуживать своих клиентов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *