Descripción general de la tecnología IPMI


Para administrar de forma remota el estado de la plataforma del servidor, los administradores e ingenieros del sistema utilizan la tecnología IPMI, que simplifica enormemente su vida. Ahora no tiene que correr al servidor cada vez que presiona el botón de reinicio; puede responder a problemas críticos de manera oportuna mientras está sentado en su casa en una silla cómoda. Este artículo cubrirá los componentes básicos de IPMI y los detalles de cómo funciona la tecnología.

¬ŅQu√© es el IPMI?


El acrónimo IPMI significa Interfaz inteligente de administración de plataforma. A través de IPMI, puede conectarse de forma remota al servidor y administrar su funcionamiento:

  • Monitoree el estado f√≠sico del equipo, por ejemplo, verifique la temperatura de los componentes individuales del sistema, los niveles de voltaje y la velocidad del ventilador.
  • Restaure el servidor en modo autom√°tico o manual (reinicio remoto del sistema, encendido / apagado, carga de im√°genes ISO y actualizaci√≥n de software)
  • Administrar perif√©ricos
  • Mantenga un registro de eventos
  • Almacenar informaci√≥n sobre el equipo utilizado

Supongamos que un ingeniero reconfigura la red en el servidor, comete un error de configuraci√≥n y pierde el acceso a trav√©s de SSH. ¬ŅC√≥mo "llegar" al servidor ahora? Puede conectarse a trav√©s de IPMI y cambiar la configuraci√≥n.

IPMI es bueno porque las funciones anteriores están disponibles independientemente del procesador, BIOS o sistema operativo (SO) de la plataforma administrada. Por ejemplo, puede reiniciar el servidor de forma remota si el sistema operativo se congela, o buscar el motivo de la falla de la CPU en el registro de eventos del sistema. Incluso puede administrar un servidor apagado: es suficiente que el servidor esté conectado a la red eléctrica.

Una vez que el servidor está montado y conectado a la red, los ingenieros de Selectel configuran el BIOS y el IPMI. Luego puede salir de la ruidosa sala de servidores y continuar configurando el equipo de forma remota. Una vez que se completa la configuración inicial, los clientes de Selectel pueden administrar servidores de configuración dedicados y arbitrarios a través de IPMI.

Antecedentes historicos


La primera versión de la especificación IPMI v1.0 fue desarrollada conjuntamente por Intel, Dell, NEC y Hewlett-Packard en 1998. En la práctica, se descubrieron vulnerabilidades y debilidades que se corrigieron en versiones posteriores de IPMI v1.5 y v2.0.

La especificación IPMI estandariza la interfaz de comunicación, y no una implementación específica en el hardware, por lo que IPMI no requiere el uso de dispositivos especiales patentados y ciertos microcontroladores. Los fabricantes, siguiendo las especificaciones, desarrollan sus propios equipos IPMI integrados en plataformas de servidores:
FabricanteTecnología basada en IPMI
CiscoCisco IMC (controlador de gestión integrado)
DelliDRAC (tarjeta de acceso remoto integrada de Dell)
HPiLO (luces apagadas integradas)
IbmIMM (Módulo de gestión integrado)
LenovoIMM (Módulo de gestión integrado)
SupermicroSIM (Supermicro Intelligent Management)
Las empresas establecen sus precios por la tecnología provista. Si el costo de la implementación de IPMI aumenta, el precio de alquiler del servidor aumenta, ya que depende directamente del costo de los consumibles.

Las soluciones de los fabricantes difieren entre sí:

  • Visibilidad de la informaci√≥n del estado del equipo.
  • Un conjunto √ļnico de aplicaciones para restaurar el estado del servidor si falla alg√ļn componente
  • La capacidad de recopilar estad√≠sticas sobre todos los componentes del servidor, incluidos los conectados a trav√©s de tarjetas de expansi√≥n PCI, NVM, etc.
  • Usar tecnolog√≠a no solo en el hardware del servidor, sino tambi√©n con computadoras comunes a trav√©s de tarjetas de expansi√≥n PCI-Express

De hecho, para un trabajo cómodo con la consola remota y la notificación oportuna de problemas, la funcionalidad básica de IPMI es suficiente.

Aunque los fabricantes proporcionan un IPMI modificado y revisado, la implementaci√≥n de su arquitectura sigue siendo similar. Veamos en qu√© consiste la tecnolog√≠a, seg√ļn las especificaciones oficiales de Intel.

Los componentes b√°sicos de cualquier IPMI


Controladores


En el centro de la arquitectura está el "cerebro" de IPMI, el microcontrolador BMC (Baseboard Management Controller). A través de él, se lleva a cabo el control remoto del servidor. De hecho, BMC es una computadora separada con su software e interfaz de red, que se suelda a la placa base o se conecta como una tarjeta de expansión a través del bus de administración PCI.


BMC se alimenta desde el voltaje de espera de la placa base, es decir, siempre funciona, independientemente del estado del servidor.

Puede conectar Controladores de administración (MC) adicionales al BMC para ampliar las capacidades de administración básica. Por ejemplo, mientras el sistema principal está controlado por las funciones BMC, los MC están conectados para monitorear varios subsistemas: fuentes de alimentación redundantes, unidades RAID, periféricos.

Los MC vienen con placas independientes separadas del BMC central, por lo que también se denominan controladores de satélite. Puede haber varios controladores adicionales, pero el BMC central es uno.

Los controladores están conectados al BMC a través de la interfaz IPMB (Intelligent Platform Management Bus - Intelligent Platform Management Bus). IPMB es un bus basado en I2C (Circuito Inter-Integrado), a través del cual el BMC redirige los comandos de control a varias partes de la arquitectura:

  • Se comunica con controladores adicionales (MC)
  • Lee datos del sensor (sensores)
  • Accede al almacenamiento no vol√°til

La arquitectura IPMI se implementa para que el administrador remoto no tenga acceso directo a los componentes del sistema. Por ejemplo, para recibir datos de los sensores, el administrador remoto envía un comando al BMC, y el BMC, a su vez, se refiere a los sensores.

Además de enviar comandos al BMC, puede configurar la ejecución automática de acciones por parte del controlador utilizando los siguientes mecanismos:
PEF (filtrado de eventos de plataforma)El BMC almacena una tabla de eventos con información sobre qué eventos responder y qué acciones tomar. Cuando el BMC recibe un mensaje de evento, compara los datos con la tabla y elige cómo responder al evento.
La reacción incluye acciones como apagar, reiniciar el sistema, generar una alerta
Temporizador de vigilanciaEl temporizador está configurado para realizar una acción después de un período de tiempo especificado. Las acciones incluyen apagar, reiniciar el servidor, interrumpir los procesos. Si establece el valor de tiempo de espera en 0, la acción se realizará de inmediato.
Dependiendo de la implementación, Watchdog puede interrogar al sistema sobre el estado una vez en un intervalo de tiempo determinado. Si el sistema no responde (por ejemplo, cuando se cuelga), se activa una acción
Cortafuegos de firmwareAlgunas acciones de BMC implementadas en un servidor autónomo pueden interrumpir el funcionamiento de plataformas modulares (por ejemplo, un servidor Blade). Para evitar posibles problemas, el firewall permite que BMC bloquee la configuración, los comandos de IPMI y las operaciones de escritura a través de la interfaz del sistema.
El firewall también contiene un conjunto de comandos a través del cual puede averiguar qué comandos y funciones de administración están disponibles para una plataforma en particular

Almacenamiento no vol√°til


El almacenamiento no volátil permanece disponible incluso si la CPU del servidor falla, por ejemplo, a través de una red local; consta de tres áreas:

  • Registro de eventos del sistema (SEL): registro de eventos del sistema
  • Repositorio de registro de datos del sensor (SDR): un repositorio que almacena datos del sensor
  • Informaci√≥n de unidades reemplazables en campo (FRU): informaci√≥n de inventario sobre m√≥dulos del sistema

Los m√≥dulos del sistema generan (generador de eventos) o reciben eventos (receptor de eventos). Los MC act√ļan como generadores de eventos, y los BMC en una arquitectura pueden desempe√Īar ambos roles. El BMC recibe mensajes de eventos a trav√©s de la interfaz del sistema y el IPMB, luego los registra en el Registro de eventos del sistema (SEL).

Hay requisitos obligatorios para implementar SEL:

  • SEL almacena al menos 16 eventos en la memoria
  • Se puede acceder a la informaci√≥n almacenada en SEL independientemente del acceso a BMC y el estado de la plataforma administrada

Los comandos de IPMI leen y eliminan SEL. Dado que la memoria SEL es limitada, periódicamente se debe verificar y limpiar el registro para que se registren nuevos eventos. En la configuración de BMC, puede configurar la limpieza automática de SEL. La limpieza automática en diferentes plataformas se realiza de diferentes maneras: borra los registros antiguos para completar los nuevos o borra toda la historia.

El mensaje del evento lleva información del repositorio SDR y las áreas de información de FRU.

Los registros SDR son datos sobre los tipos y la cantidad de sensores, su capacidad para generar eventos y los tipos de lecturas. Los SDR también contienen registros de la cantidad y los tipos de dispositivos conectados a IPMB. Los registros SDR se almacenan en un área de memoria llamada Repositorio SDR (Repositorio de registros de datos del sensor).

Los registros de FRU contienen informaci√≥n sobre n√ļmeros de serie y modelos de piezas de varios m√≥dulos del sistema: procesador, tarjeta de memoria, tarjeta de E / S, controladores.

La información de FRU se puede proporcionar a través de MC (comandos de IPMI) o mediante el acceso a chips de memoria no volátil SEEPROM (memoria de solo lectura programable borrable eléctricamente en serie) conectada a través del bus de administración privada. Los controladores se comunican a través de este bus a través de comandos I2C de bajo nivel con dispositivos que no admiten comandos IPMI.

Aplicación práctica


Supongamos que un cliente se queja de congelaciones del servidor, pero todo está en orden en los registros del sistema operativo. Observamos a SEL: vemos errores en una de las ranuras de RAM que indican la información sobre la ranura en la que se encuentra. Cambiar: el servidor comienza a funcionar como un reloj.


Arriba, examinamos los módulos básicos de la arquitectura IPMI. Ahora veamos la estructura de los comandos transmitidos y veamos qué interfaces se utilizan para la conexión remota.

Estructura de comando de IPMI


IPMI envía mensajes de solicitud-respuesta. Las solicitudes son comandos. Los comandos inician acciones y establecen valores. El formato de solicitud-respuesta hace posible la comunicación simultánea de varios controladores en el mismo bus.

Los mensajes de IPMI contienen un conjunto b√°sico de campos comunes a todos los comandos:

  • La funci√≥n de red (NetFn) asigna al comando el valor del cl√ļster al que pertenece el comando (comandos del chasis, eventos, almacenamiento, etc.)
  • El campo Identificador de solicitud / respuesta es necesario para distinguir entre solicitudes y respuestas
  • ID del solicitante : informaci√≥n sobre el origen del mensaje. Por ejemplo, para IPMB, esta informaci√≥n contiene el LUN (n√ļmero de unidad l√≥gica) del dispositivo
  • El ID del respondedor dirige la solicitud al respondedor deseado
  • Comando : exclusivo dentro del equipo de funciones de red
  • Datos : par√°metros adicionales (por ejemplo, datos devueltos en la respuesta)

Además, la respuesta siempre pasa el Código de finalización, que informa el resultado del comando. Si se produce un error durante la ejecución de la solicitud, se enviará un código distinto de cero correspondiente al evento.

Los canales a través de los cuales se transmiten los mensajes se pueden dividir en tres categorías con las interfaces correspondientes:

  • BMC - MC, sensores, almacenamiento (IPMB)
  • BMC - Plataforma administrada (interfaz del sistema)
  • BMC - Administrador remoto (LAN, interfaz en serie)

En este modelo, BMC puede considerarse como un conmutador que interconecta las interfaces del sistema (en la terminología de la especificación: Bridging):

  • Serie ‚ÜĒ IPMB
  • Interfaz de sistema serie ‚ÜĒ
  • LAN ‚ÜĒ IPMB
  • LAN Interface Interfaz del sistema
  • Serie Bus Bus de gesti√≥n PCI
  • LAN ‚ÜĒ Bus de administraci√≥n PCI
  • Otras combinaciones, incluida Serial ‚ÜĒ LAN

Cuando se entrega a trav√©s de varias interfaces de arquitectura, el conjunto b√°sico de campos se complementa con n√ļmeros de canal y tramas. Por ejemplo, el protocolo IPMB agrega campos de direcci√≥n y campos para verificar la integridad de los datos transmitidos, y la LAN encapsula los comandos IPMI en paquetes UDP / IP.

Interfaces de acceso remoto


En la versión inicial de IPMI, la consola remota estaba conectada al módulo BMC a través de una interfaz en serie (interfaz en serie). La especificación IPMI v2.0 se basa en el uso de una interfaz de red (interfaz LAN).

La interfaz LAN se proporciona a través de un puerto de red BMC dedicado con su dirección IP. Al transmitir mensajes de IPMI a través de LAN, hay varias etapas de encapsulación:

  • Los mensajes de IPMI se generan en paquetes de sesi√≥n de IPMI (m√°s adelante en el art√≠culo examinaremos con m√°s detalle la formaci√≥n de la sesi√≥n de IPMI)
  • Los paquetes de sesi√≥n de IPMI se encapsulan utilizando RMCP (Protocolo de control de gesti√≥n remota)
  • Los paquetes RMCP se forman en datagramas UDP
  • Se agregan tramas de Ethernet


La interfaz en serie para conectar una consola remota a BMC ya no se usa, pero es necesaria para implementar dos funciones:

  • Puerto serie compartido
  • Serial-over-LAN (SoL)

Serial Port Sharing es la capacidad de usar un conector serial com√ļn entre BMC seriales y un sistema administrado. Por lo general, el uso compartido del puerto serie se usa para implementar la redirecci√≥n de la consola del BIOS, es decir, redirigir la consola del BIOS al m√≥dulo BMC.

Serial-over-LAN es necesario para interactuar con los componentes del sistema que entienden solo una interfaz de comunicación en serie. También puede enviar comandos desde la consola del servidor directamente a los dispositivos del servidor (chips, tarjetas, discos, etc.). SoL está implementado para funcionar en conjunto con la función Serial Port Sharing.

Sesión y Autenticación


Para LAN y la interfaz en serie, el comienzo de la transmisión de mensajes IPMI está precedido por el establecimiento de una sesión durante la cual se generan los paquetes de datos de sesión IPMI.

El establecimiento de sesión es la autenticación de un usuario específico. La sesión debe activarse antes de enviar mensajes IPMI de acuerdo con el siguiente algoritmo:


  1. La consola remota solicita datos de autenticación de BMC
  2. BMC env√≠a una respuesta sobre los tipos de autenticaci√≥n admitidos (ninguno, contrase√Īa, algoritmos MD2 y MD5, etc.)
  3. La consola remota envía un comando sobre el tipo de autenticación seleccionado y envía el inicio de sesión del usuario
  4. Si el usuario tiene privilegios de acceso al canal, el BMC envía una respuesta que contiene la ID de la sesión. Gracias a la asignación de ID, varias sesiones pueden funcionar simultáneamente en un canal (de acuerdo con los requisitos de la especificación, al menos cuatro sesiones simultáneas)
  5. La consola remota env√≠a una solicitud de activaci√≥n de sesi√≥n. La solicitud contiene un ID de sesi√≥n e informaci√≥n de autenticaci√≥n (nombre de usuario, contrase√Īa, claves; depende del tipo de autenticaci√≥n seleccionado)
  6. BMC verifica la información del usuario, aprueba la ID de la sesión y envía una respuesta de activación

Las sesiones se finalizan automáticamente si no se toman medidas durante el intervalo especificado o si la conexión se desconecta.

El acceso al BMC se puede bloquear enviando m√ļltiples solicitudes de activaci√≥n de sesi√≥n al mismo tiempo, luego todos los recursos se utilizar√°n para rastrear las sesiones que requieren activaci√≥n. Para evitar un posible ataque, se recomienda utilizar el algoritmo LRU (√öltimo uso reciente) en la implementaci√≥n de BMC. El algoritmo establece una ID de sesi√≥n para la solicitud de activaci√≥n de sesi√≥n m√°s temprana. Por ejemplo, una consola remota se inicia a trav√©s de un navegador en una sesi√≥n noVNC. Si abre varias pesta√Īas con sesiones en ejecuci√≥n, la entrada de texto estar√° disponible en la primera pesta√Īa abierta.

Cuando IPMI deja de estar disponible


IPMI ayuda a restaurar el estado del servidor si falla. Sin embargo, puede suceder que el sistema de control remoto no esté disponible. El mal funcionamiento del IPMI se puede dividir en cuatro categorías:

  • A nivel de red. Puertos rotos, equipo que no funciona, defecto del cable, par trenzado mal engarzado
  • A nivel de software. Error del sistema, bloqueo del m√≥dulo BMC, necesidad de actualizar el firmware del m√≥dulo
  • A nivel de hardware. Sobrecalentamiento, falla de componentes cr√≠ticos (memoria, procesador), defectos en la arquitectura del sistema
  • A nivel nutricional. Interrupci√≥n del suministro el√©ctrico de BMC o problemas de suministro de energ√≠a del servidor

Estos factores afectan tanto el funcionamiento de IPMI como el servidor en sí. El módulo BMC es un chip independiente del servidor, y una falla de este microcontrolador indica una falla del servidor en el 90% de los casos.

IPMI en la pr√°ctica


Puede administrar el servidor a través de IPMI a través de un navegador web, las utilidades proporcionadas por los fabricantes y las utilidades de código abierto.

Cada implementación de IPMI tiene una interfaz web, pero el principio de acceso sigue siendo el mismo:

  1. Ingrese la dirección IP del puerto BMC en la barra de direcciones
  2. Ingrese nombre de usuario y contrase√Īa. Algunas veces esta informaci√≥n se indica directamente en el equipo.

En Selectel, trabajamos con módulos IPMI de Intel, Asus y Supermicro. Como ejemplo, mira la interfaz web de Supermicro:


Las características de la interfaz web también se implementan en la utilidad gráfica Supermicro IPMIView:


Para administrar el equipo a través de la consola de Linux, se instala la utilidad correspondiente (por ejemplo, Ipmitool para administración local y remota o IPMICFG para local). Luego, usando los comandos de la consola, se agrega un dispositivo IPMI y se configura el BMC.


Los clientes de Selectel tienen IPMI disponible para configuraciones de servidor dedicadas y personalizadas . IPMI se implementa como una consola KVM, que se ejecuta en una sesión noVNC a través del panel de control . Para hacer esto, en la tarjeta con información sobre el servidor, haga clic en el icono de la consola en la esquina superior derecha:


La consola se abre en el navegador y se ajusta al tama√Īo de la pantalla. Si lo desea, la consola se puede usar incluso a trav√©s de un tel√©fono o tableta.

La sesión se interrumpe si sale del panel.


Conclusión


IPMI es un componente totalmente autónomo de la plataforma del servidor, que no depende del sistema operativo, BIOS o CPU del servidor.

Gracias a IPMI, el costo de mantenimiento de los sistemas del servidor se reduce y la vida de los administradores del sistema se simplifica. No hay necesidad de una presencia permanente cerca del equipo: su trabajo se controla de forma remota a través de la red.

En este artículo, cubrimos los componentes básicos de IPMI. Sin embargo, los detalles de la tecnología son vastos. Los desarrolladores talentosos, confiando en la especificación, pueden crear su equipo IPMI y herramientas de código abierto, eliminando simultáneamente las deficiencias de la especificación actual y abriendo nuevas posibilidades para el control remoto.

Materiales utilizados en el artículo:

Especificación IPMI v2.0
Libros blancos supermicro

Source: https://habr.com/ru/post/439834/


All Articles