Embedded lom 1 port 1 что это
Lights Out Management называется модификация Apple протокола удаленного управления и мониторинга Intelligent Platform Management Interface (IPMI), разработанного Intel.
Внедрение LOM в линейку серверов Xserve позволяет производить мониторинг более сотни разнообразных сенсоров, измеряющих напряжение, температуру, скорость вращения вентиляторов и т.д. При помощи Server Monitor и LOM можно получить полную картинку о состоянии вашего сервера.
Помимо сугубо наблюдательных функций LOM также можно использовать для контроля некоторых параметров Xserve. Таким образом можно удаленно выключить сервер или перезагрузить. При этом вы сможете выполнить эти команды даже в том случае, если Xserve не отвечает.
Процессы LOM контролируются специальным процессором, который работает абсолютно независимо от двух встроенных Intel Xeon.
К процессору LOM можно получить доступ через один или оба встроенных порта Ethernet, каждый из которых имеет два MAC-адреса: один выделен непосредственно процессору LOM, а второй использует операционная система.
Стоит отметить, что IP-адресы, назначаемые на MAC-адресы процессора LOM и системы, должны быть различными. В процессе настройки создается особая учетная запись, пользователь которой будет иметь доступ к системе и данным LOM.
Перепечатка и/или какое-либо иное воспроизведение материалов сайта в сторонних источниках информации без письменного разрешения DeepArtment категорически запрещены.
Управление серверами HP ProLiant через открытые REST API или «iLO на стероидах»
Вступление от HP: эта публикация написана одним из наших заказчиков, который по долгу службы пожелал остаться анонимным. Все совпадения имён и айпишников считать случайными. Попробовать сделать то же самое можно в любое время в нашем демо-центре в Москве — желающих просим писать в комментарии.
Приветствую. Меня зовут Эдуард, и я системный администратор в небольшой компании, которая аутсорсит администрирование ИТ-инфраструктуры. Кхм… Уже похоже на клуб анонимных кого-то с проблемами? Ну да ладно, одна интересная проблема у нас действительно была, а сегодня мы расскажем, как мы с ней столкнулись, и как случайно её решили.
Для начала немного предыстории. Все же помнят, как весело было админить удалённое железо раньше, лет 5-8 назад? Пишем заявку инженерам в ДЦ, ждём, когда они подключат KVM, настраиваем BIOS/CMOS, выставляем загрузку по сети, ставим систему (это хорошо, если кто-то добрый уже написал генератор preseed/kickstart-файлов, и в ДЦ есть DHCP/PXE сервер). А потом у нас на всех серверах появился ipmi (ну со временем). Ох, как мы радовались первое время!
И сервер уже вроде бы ставит ОС. Остаётся только наблюдать за этим в консоли, если скучно. Огорчало только то, что BIOS всё равно приходилось обновлять руками и настраивать (ну там HT/VT-d включить, хотя бы). В итоге все серверы были настроены по-разному, в зависимости от того, в каком квартале их ставили. Ну вы же понимаете, что серверы всегда ставил самый младший админ.
Когда мы находили что-то критичное – мы шли и руками переключали настройки. Бардак, да и только. Но вообще всё это нас устраивало до того, как с нами случилась история, о которой я сегодня и буду рассказывать.
Стоит упомянуть, что часть клиентов мы размещаем прямо на своём железе (точнее на виртуалках на этом железе, которое рулится через ). Ну чтобы вам было легче представить – наша система сильно похожа на OpenStack. И вот, в один прекрасный день, к нам пришел заказчик и попросил «на его железе сделать систему для управления виртуальными машинами в приватном облаке». Мы обрадовались, начали ему показывать своё решение (уже после подписания контракта и ТЗ), ему всё понравилось. Всё понравилось, менеджеры уже открывают шампанское (а надо сказать, что контракт по нашим меркам был очень неплохой). И тут клиент показывает пальцем в пункт ТЗ и спрашивает – «а с этим как?». Сидят админы и недоуменно смотрят в этот пункт – «новые серверы должны автоматически добавляться в облако после инвентаризации, установки в стойку и подключения сети-питания». Мы начали показывать – вот смотрите, мы записываем сервер сюда (1c), добавляем его mac-адрес вот сюда (самописная web-морда для управления dhcp-сервером и pxe), запускаем скрипт, сервер загружается по сети, система ставится (мы с облегчением выдохнули, поняв, что хотя бы система ставится сама), потом мы ловим сервер при перезагрузке, усиленно жмем клавишу Del… В общем, представитель клиента посмотрел на это, почесал затылок, походил по переговорке, собрался с мыслями и произнес: «Да где ж тут автоматически? Вот давайте выкинем всё, кроме 1С, всё равно туда бухгалтеры сервер вносить будут, а не я, и того места, куда вы mac-адрес записывали». Ну и вскоре после этого ушел, добавив, что надеется на то, что задачу мы всё же решим.
Потом мы, как обычно, ТЗ решили прочитать. Нашли там всякие интересные пункты, которые мы (ну те, кто делал задачу, а не те, кто ТЗ подписывал и пересказывал его нам) увидели впервые. Например, мониторинг температуры в обход ОС, мониторинг потребления электричества, автоматическая настройка BIOS… Начали размышлять. Сначала склонялись к мысли, что ipmitool всё это может. Потом представили, как всё это будет выглядеть. Подумали про то, как обновлять настройки, про мониторинг датчиков… В общем, разошлись на выходные с задачей «изучить весь гугл на предмет альтернатив ipmi, которые могут».
Приходим в понедельник, все грустные, злые. А один админ сидит и улыбается. Логичным было пристать к нему с расспросами на тему того, зачем он читает ithappens, когда у нас такая беда. Как оказалось, радовался он по поводу того, что читал не ithappens, а Redfish server management spec v 1.0 (читать здесь). Почитали все вместе вслух, злиться перестали. Redfish оказался именно тем, что нам нужно. Взяли менеджера, заставили его обзванивать всех производителей серверов, чтобы найти железку, в которой Redfish реализован. Приходят через час и смеется, показывает пальцем на коробку у входа и говорит «всё, я нашел». Собственно, коробка оказалась коробкой от HP Proliant Gen9. Сервер мы нашли, вернули в лабораторию (и кто вообще догадался новенький неизученный сервер сразу в ДЦ везти…) и приступили к знакомству с HP REST API (которая и является реализацией Redfish в серверах HP).
Так как мы админы (это потом уже нам дали питониста и он нам всё написал и сделал красивый web-интерфейс), то первым делом мы сели писать sh-ники, которые будут делать то, что нам нужно. Конечно, мы бы не советовали ходить в Rest API консольным curl-ом и генерировать JSON через echo (ну или хотя бы потом не показывайте никому это), но вот поделиться примерами взаимодействия с HP ProLiant REST API будем рады (тем более, что сами представители HP нас об этом и попросили).
Возможностей там полно на самом деле, в документации 2 сотни страниц списка объектов и краткого их описания. Мы первым делом пытались выполнить свои основные задачи, как proof-of-concept. Конечно, часть из них можно делать и через IPMI, но мы решили использовать один инструмент, именно API.
Первым делом (ну хорошо, вторым, после подключения сервера в стойке и после того, как HP iLO получит IP-адрес), прописываем все настройки BIOS:
Научимся управлять питанием. Ребут «по кнопке»:
«Выдёргиваем кабель из розетки»:
Отправляем инженера «нажать кнопку питания»:
Спросим у сервера, кто он такой:
PATCH-запросом в эту же ручку можно изменить информацию о сервере внутри iLo.
Спросим MAC-адреса у сервера (да, в итоге мы пошли дальше и DHCP-сервер сам проводил инвентаризацию новых серверов, если находил незнакомый iLO в отдельном VLAN-е – для iLO мы выдавали динамические адрес, а потом уже заводили записи о статических адресах для сетевых карт сервера и интерфейса iLo):
Из предыдущего JSON-а мы вытаскивали также и количество памяти с моделью CPU, потом разработчики сделали интеграцию с 1С, сервер отправлял данные о себе и туда. Здесь же мы определяли и версию BIOS, чтобы ругаться об устаревших (или просто отличающихся по кластеру) версиях.
Ещё через REST API можно снять показания метрик питания (к сожалению, не во всех «уровнях» лицензии iLO):
Ещё мы нашли какую-то жуткую ручку, которая описывает состояние сервера – обороты вентилятора, температуру, состояние разных железок внутри сервера.
А ещё нашли объект, который говорит о состоянии сервера в целом (ОК/fail) и чем он сейчас занимается (в нашем примере он загружался):
В общем, sh-ник мы в итоге написали и отдали его разработчику. Он над нами посмеялся, мы его за это поругали, пригрозили рута отобрать… Но зато он потом написал модуль в наше облачко, который умеет добавлять и управлять серверами через Redfish (и HP REST API, соответственно). Ну а заказ мы в итоге выполнили.
Наверное, пора закругляться. Расскажем про тех, кто играл главные роли во всей это истории.
Анатомия платформы Huawei FusionServer хостинга RUVDS
Компания Huawei Technologies, известная прежде всего как поставщик сетевого и телекоммуникационного оборудования, более пяти лет назад начала мощный натиск на мировой серверный рынок, нацеливаясь на повышение узнаваемости своего бренда среди корпоративных заказчиков серверов. Кроме того, компания пытается создать себе преимущества благодаря внушительным инвестициям в исследования и разработку.
Предмет сегодняшнего обзора — двухсокетный стоечный сервер 2U Huawei RH2288 V3. Как считает производитель, его основная задача — обработка и хранение данных ответственных приложений в небольшом стоечном пространстве. Серверы Huawei RH2288 V3 подойдут для работы с интернет-приложениями и важными корпоративными системами, для обработки и хранения больших данных, облачных вычислений, предоставления телекоммуникационных услуг. Их применяют поставщики услуг хостинга и VPS, например, RUVDS — официальный партнёр Huawei.
В частности, в рамках совместного проекта вендор оснащает дата-центры RUVDS в России, Великобритании и Швейцарии своим оборудованием. В настоящее время в дата-центрах компании установлено уже более 200 серверов RH2288 V3. Это гарантирует быструю и стабильную работу виртуальных серверов, позволяет предложить клиентам качественные и современные услуги. Кроме того, эти надежные серверные платформы, позволяют оптимизировать стоимость предоставляемых клиентам услуг. Платформа хостинга RH2288 V3 идеально подходит для хостинга и потому стала закономерным выбором для оснащения дата-центров RUVDS. С этими серверами мы и познакомимся в этом обзоре.
Разработчики RH2288 V3 постарались добиться оптимального соотношения производительности и плотности размещения компонентов системы. Сервер предусматривает большую емкость хранения данных, возможности расширения и достаточно высокую вычислительную мощность. Его ближайшие конкуренты — HP DL380p Gen9, IBM x3650 M5, Dell R730xd и Cisco C240 M4.
Для повышения энергоэффективности в нем реализованы интеллектуальные технологии управления питанием: динамическое управление энергопотреблением; предоставление ресурсов источника питания и охлаждение при необходимости; пропорционально-интегрально-дифференциальное регулирование для контроля процесса теплообмена и регулирования скорости вращения вентиляторов. Интеллект сервера этим не ограничивается: система регистрации данных помогает найти неполадки, приведшие к отказу.
С помощью светодиодной панели можно выполнять операции локального управления, а посредством независимого модуля iBMC — осуществлять удаленные задачи, используя последовательную консоль (Serial over LAN, SoL), KVM для удаленного доступа, а также другие функции. Контроллер управления iBMC разработан на собственном чипе Huawei и поставляется в комплекте с сервером бесплатно.
Спецификации RH2288 V3
| Процессор | Один или два процессора серий Intel Xeon E5-2600 V3/V4 |
| ОЗУ | 16 модулей RDIMM/LRDIMM DDR4 |
| ПЗУ | Конфигурации жесткого диска: |
В конкурентных решениях слотов расширения меньше, а RAID-контроллер встроенный. SD-карта в них одна, в то время как сервер Huawei поддерживает два встроенных накопителя SATA DOM или две SD-карты. У RH2288 V3, а это уже третье поколение данной модели сервера, более широкий диапазон рабочих температур, в логах фиксируются не только проблемы, выявляемые средствами диагностики, но и такие события как открытие и закрытие шасси.
Удалённое управление сервером производится при помощи контроллера iBMC, который функционально мало чем отличается от разработок конкурентов, но стоит отметить, что контроллер поддерживает КVM over IP c разрешением Full HD.
Так выглядит логическая схема сервера
Итак, приступим к распаковке. Сервер пришёл к нам вот в такой ничем не примечательной с виду коробке с фирменной эмблемой Huawei. Внутри помимо сервера оказался комплект для его установки в стойку на выдвижных рельсах — Rail Kit.
Его конструкция продумана до мелочей: подпружиненные фиксаторы обеспечивают быстрое и надёжное крепление конструкции.
Также была инструкция по быстрой установке сервера — Quick Start Guide (кликабельно):
А вот и сам сервер с его солидным хранилищем — в данной комплектации это жёсткие диски SAS на 10К емкостью по 900 Гбайт и SATA на 7,2К по 2 Тбайта, плюс SSD SATA по 960 Гбайт. С таким арсеналом можно организовать тиринг — многоуровневое хранение данных.
Отметим, что RH2288 V3 использует жёсткие диски SATA с возможностью горячей замены, жёсткие диски SAS или накопители SSD. Он поддерживает RAID 0, 1, 1E, 10, 5, 50, 6 и 60.
Кстати, SSD от Huawei построены на флэш-памяти MLC. Их наличие позволяет ускорить работу операционной системы.
LED-индикатор на передней панели помогает следить за «состоянием здоровья» сервера. Ниже — индикатор UID и кнопка питания. Кнопка / индикатор UID помогает идентифицировать и находить сервер в стойке. Вы можете включить или выключить индикатор UID, вручную нажав кнопку UID или дистанционно — выполнив команду в iBMC CLI. Эта кнопка также выполняет сброс iBMC.
Извлечь накопитель просто — нужно открыть и потянуть ручку. В RH2288 V3 используются жесткие диски с возможностью горячей замены. Сервер поддерживает следующие конфигурации жесткого диска:
Таким образом, сервер может комплектоваться 25 дисками с передней панели, и все они могут подключаться к контроллеру RAID компании LSI.
В комплекте идут диски HGST корпоративного класса.
Корзины для накопителей HDD/SSD легко извлекаются с передней панели сервера.
А вот нумерованные порты в отсеках шасси сервера, с которыми эти корзины стыкуются.
Разнообразие форм-факторов и типов накопителей.
Индикаторы состояния сетевых портов с 1 по 4
Вентиляторы и блоки питания. В RH2288 V3 — два блока питания с возможностью горячей замены, они работают в режиме резервирования 1 + 1. Можно выбрать следующие типы блоков питания:
Для охлаждения используются парные вентиляторные модули с возможностью горячей замены.
Продуманность до мелочей: так можно легко извлечь блоки питания.
Внизу — порты USB, сетевой порт управления, порт VGA и последовательный порт. 4 и 5 — это стандартные слоты PCIe.
Слева внизу — сетевые порты 1 и 2.
Вот так сервер выглядит целиком — вид сзади.
Ручка снятия крышки корпуса открывает доступ к внутренним компонентам системы.
А ларчик просто открывался… Для этого в комплекте есть специальный мультитул.
Как водится, внутри крышки (кстати, сделана из стали) — подробные схемы и пояснения, что есть что. Здесь можно найти схему передней и задней панели сервера, материнской платы, конфигурации памяти.
[кликабельно] Схема материнской платы с подробно расписанными компонентами.
Подробно расписано всё, что находится на задней панели сервера, поясняются значения индикаторов.
В целом сервер производит довольно хорошее впечатление. Качественно выполненный корпус, хорошая сборка.
Модули вентиляторов направляют поток воздуха на радиаторы процессоров.
[кликабельно] Блок питания и остальная «начинка» сервера. Конструктивные решения вполне стандартные.
Воздуховод обеспечивает правильное охлаждение компонентов сервера, прежде всего — процессоров.
RH2288 V3 поддерживает два процессора Intel Xeon E5-2600 v3 (Haswell-EP) или E5-2600 v4 (Broadwell-EP) и 16 модулей DDR4 DIMM. Процессоры связаны шиной QPI с максимальной скоростью 9,6 ГТ / с. Управление жесткими дисками осуществляется с помощью платы контроллера RAID или PCH.
Радиатор процессора справится с отводом тепла при любой нагрузке
Вот как все выглядит на схеме.
| 1 | Задний модуль жесткого диска | 2 | PCIe-карта на материнке |
| 3 | PCIe-карта на райзере | 4 | Модуль ввода-вывода |
| 5 | Кабельный организатор | 6 | Шасси |
| 7 | Блок питания | 8 | Шина блока питания |
| 9 | Воздуховод | 10 | Лоток суперконденсатора |
| 11 | Суперконденсатор | 12 | Объединительная панель дисков |
| 13 | Скобка вентилятора | 14 | Модуль вентилятора |
| 15 | Жесткий диск | 16 | Радиатор |
| 17 | DIMM | 18 | ЦП |
| 19 | RAID-контроллер | 20 | TPM (опция) |
| 21 | Материнская плата | 22 | SATADOM |
| 23 | LOM | — | — |
Как видно, компоновка довольно плотная. RH2288 V3 предусматривает два PCIe 3.0 x8 слота для стандартных PCIe-карт и поддерживает разные типы райзеров:
1. Райзер 1 с тремя слотами PCIe3.0 x8 для следующих устройств:
— Одна полноразмерная карта PCIe 3.0 x16 полной длины (пропускная способность: PCIe 3.0×8).
— Одна полноразмерная карта PCIe 3.0 x8.
— Одна полноразмерная карта PCIe 3.0 x8.
2. Райзер 2 с двумя слотами PCIe3.0 x16 для следующих устройств:
— Одна полноразмерная плата PCIe 3.0 x16 полной высоты.
— Одна полноразмерная плата PCIe 3.0 x16 полной длины (пропускная способность: PCIe 3.0×8).
Модуль ввода / вывода поддерживает следующие конфигурации:
Процессоры интегрированы с контроллерами памяти и PCIe-контроллерами. Сервер поддерживает следующие процессоры:
Фишка сервера в том, что он содержит штатные райзеры для установки дополнительных плат.
Слева — батарея контроллера. Контроллер имеет кэш ёмкостью 2 Гбайта. Через SAS-экспандер он соединяется с дисками.
Внутри можно сервера установить 16 модулей памяти.
В сервере стоят модули памяти по 32 Гбайта производства SK Hynix.
В центре — тот самый фирменный контроллер iBMC.
Суперконденсатор используется для защиты данных кэша RAID от сбоев питания.
В заключение отметим интересную фишку вендора: две карты SD по 32 Гбайта могут объединяться в RAID 0. При выходе из строя одной карты вторая будет продолжить работать. На этих картах хранится информация, которая записывается контроллером управления iBMC, то есть в случае отказа сервера информация сбрасывается на карту, и можно посмотреть, в чём была причина сбоя. У конкурентов либо нет такого решения, либо оно стоит очень дорого. В целом же серверы Huawei по функционалу как минимум не уступают конкурентам.
Решения Huawei для центров обработки данных помогают хостинг-провайдерам, владельцам дата-центров развивать свой бизнес благодаря оптимальной стоимости, быстрому развертыванию, интеллектуальному управлению и надежности. Так, например, в RUVDS за всё время работы с этим оборудованием ни один из серверов или их компонентов не вышел из строя, создав при этом аварийную ситуацию или, тем более, потерю данных. Отмечены лишь единичные случаи проблем с оперативной памятью и жестким диском, которые решались очень оперативно благодаря гарантии Next Business Day. Жесткие диски в RAID-массиве заменялись в горячем режиме, а замена оперативной памяти была произведена один раз и с минимальным простоем для клиентов для перезагрузки сервера. Блоки питания, процессоры, контроллеры на этих серверах в период эксплуатации из строя не выходили.
Задавайте вопросы в комментариях.
Кстати, нас иногда упрекают, что мы постим только переводы. Писать авторские статьи часто действительно непросто, а хочется, чтобы блог был живым. А этот пост прям авторский-авторский — если он вам понравился, то высокий рейтинг простимулирует нас писать такое почаще 😉 Ну и традиционная скидочка:
