La Interfaz de Plataforma de Hardware ( HPI ) es una especificación abierta que define una interfaz de programación de aplicaciones (API) para la gestión de plataformas de sistemas informáticos. La API admite tareas que incluyen la lectura de sensores de temperatura o voltaje integrados en un procesador, la configuración de registros de hardware, el acceso a información de inventario del sistema como números de modelo y números de serie, y la realización de actividades más complejas, como la actualización del firmware del sistema o el diagnóstico de fallas del sistema.
HPI está diseñado para su uso con sistemas informáticos de alta disponibilidad modulares y tolerantes a fallos , que suelen incluir funciones de detección automática de fallos y redundancia de hardware para poder proporcionar disponibilidad de servicio continua. Otras funciones comunes en las plataformas de hardware utilizadas para aplicaciones de alta disponibilidad incluyen capacidad de mantenimiento en línea y capacidad de actualización mediante módulos intercambiables en caliente.
La especificación HPI es desarrollada y publicada por el Foro de Disponibilidad de Servicios (Foro SA) y está disponible gratuitamente para el público.
Un factor motivador principal para el desarrollo de la especificación HPI fue la aparición de plataformas de hardware informático modulares y sistemas comerciales listos para usar (COTS) a finales de la década de 1990 y principios de la década de 2000. Esto incluía las plataformas CompactPCI y, más tarde, las plataformas AdvancedTCA y MicroTCA (xTCA) estandarizadas por el PCI Industrial Computer Manufacturers Group (PICMG). Estas plataformas incluyen infraestructuras de gestión de hardware basadas en la Interfaz de gestión de plataforma inteligente (IPMI). Al mismo tiempo, los principales proveedores empresariales como HP e IBM también desarrollaron sistemas modulares y blade.
La necesidad de la especificación HPI fue identificada por primera vez por un grupo de la industria llamado “High Availability Forum”, que se reunió durante varios meses en 2000 para discutir cuestiones relacionadas con la construcción de sistemas informáticos de alta disponibilidad utilizando tecnología de arquitectura abierta . Este grupo publicó un informe técnico, “Providing Open Architecture High Availability Solutions” (Proporcionar soluciones de alta disponibilidad de arquitectura abierta) a principios de 2001. A partir de ese trabajo, Intel Corporation comenzó un proyecto para definir una API de gestión de plataforma de hardware estándar denominada Universal Chassis Management Interface (UCMI). Este trabajo se trasladó al consorcio SA Forum, recientemente formado, y se publicó como Hardware Platform Interface en octubre de 2002. La especificación HPI original, SAI-HPI-A.01.01, fue la primera especificación publicada por SA Forum.
Desde 2002 en adelante, se han publicado varias actualizaciones de la especificación HPI. Además, se han elaborado especificaciones para acceder a una implementación HPI a través del Protocolo simple de administración de redes (SNMP) y especificaciones que describen el uso de HPI en plataformas AdvancedTCA y MicroTCA. La Tabla 1 enumera todas las especificaciones publicadas por el SA Forum en la familia HPI.
Las especificaciones HPI y la especificación de interfaz de aplicación (AIS) se han desarrollado por separado en el Foro SA. Aunque ambas tienen como objetivo abordar la funcionalidad necesaria para los niveles más altos de disponibilidad del servicio, se pueden utilizar de forma independiente. Las especificaciones AIS se pueden implementar y utilizar para middleware de agrupación en clúster de alta disponibilidad que no implementa la gestión de la plataforma de hardware, y la especificación HPI puede ser implementada por proveedores de plataformas y utilizada directamente por programas de aplicación o gestión sin el uso de otro middleware de gestión del Foro SA.
La intersección principal entre las especificaciones AIS y HPI se encuentra en el Servicio de gestión de plataformas (PLM) de AIS. El servicio PLM se define con la expectativa de que la gestión de la plataforma de hardware se proporcionará a través de una implementación de la especificación HPI en la plataforma de hardware de destino.
La especificación HPI no dicta ni presupone qué capacidades de gestión de plataforma deben estar presentes en una plataforma de hardware. En cambio, proporciona una forma genérica y consistente de modelar las capacidades que estén presentes y ofrece una forma para que los programas de aplicación de usuario conozcan los detalles de las capacidades de gestión de plataforma que están disponibles.
HPI organiza las capacidades de gestión de la plataforma de hardware en un conjunto de recursos . Cada recurso alberga un conjunto de instrumentos de gestión que pueden supervisar y controlar partes de la plataforma de hardware. Los instrumentos de gestión abstraen los componentes de gestión integrados en la plataforma, como sensores de temperatura o tensión, registros de configuración y elementos de visualización, o proporcionan interfaces para funciones de gestión, como la actualización del firmware y la ejecución de diagnósticos. Estos instrumentos de gestión se describen en registros de datos de recursos (RDR) a los que puede acceder la aplicación del usuario, de modo que la aplicación pueda descubrir la configuración y las capacidades de cada recurso.
Si bien los recursos HPI son estructuras abstractas, por lo general se utilizan para modelar las capacidades de administración de los controladores de administración individuales en la plataforma de hardware. Por ejemplo, en las plataformas AdvancedTCA (ATCA), cada blade de computación generalmente incluye un controlador de administración IPMI (IPMC) responsable de las tareas de administración de hardware relacionadas con ese blade. Una interfaz HPI para una plataforma ATCA normalmente incluirá un recurso para cada IPMC.
Los recursos en HPI se organizan en dominios . A menudo, una implementación de HPI implementará solo un dominio para todos los recursos, pero es posible subdividir el sistema en varios dominios, si es necesario. Por ejemplo, en algunos sistemas modulares, varios módulos pueden ser propiedad de diferentes usuarios y estar administrados por ellos. Para respaldar esto con HPI, todos los recursos utilizados para administrar los módulos que pertenecen a un usuario específico pueden ubicarse en un solo dominio, y ese usuario tiene acceso solo a ese dominio.
Los programas de usuario de HPI acceden a la infraestructura de gestión de la plataforma abriendo una sesión con un dominio de HPI específico. Una vez establecida esta sesión, el programa de usuario puede realizar varias llamadas a funciones de HPI para consultar o actualizar información sobre ese dominio o sobre cualquiera de los recursos que actualmente son miembros de ese dominio.
Si bien los instrumentos de administración de HPI están organizados y direccionados por dominio y recurso, los componentes de hardware que son administrados por esos instrumentos de administración se identifican individualmente en los RDR asociados con cada instrumento de administración. Los componentes de hardware físicos en HPI se denominan entidades y se identifican con una ruta de entidad. Una ruta de entidad contiene múltiples elementos, donde el primer elemento describe dónde se encuentra la entidad de hardware en una entidad contenedora, el segundo elemento describe dónde se encuentra esa entidad en un contenedor más grande, y así sucesivamente. Por ejemplo, una fuente de alimentación redundante para un chasis en un sistema que abarca varios bastidores podría tener la ruta de entidad POWER_SUPPLY.2,SUBRACK.3,RACK.1.
Debido a que cada instrumento de gestión está asociado con una ruta de entidad específica, es posible que un recurso HPI se encargue de la gestión de la plataforma para más de una entidad. También es posible que una sola entidad se gestione a través de varios recursos HPI. Esta posibilidad de una combinación arbitraria entre los recursos HPI y las entidades de hardware que se gestionan puede parecer confusa, pero es una característica importante de la arquitectura HPI. Esto se debe a que permite el modelado de infraestructuras de gestión complejas que pueden incluir elementos de gestión tanto en banda como fuera de banda de una sola entidad de hardware, y sistemas en los que un controlador de gestión en un equipo proporciona gestión para otro equipo.
Los recursos de HPI pueden alojar un conjunto de instrumentos de gestión. Cada instrumento de gestión modela la capacidad de supervisar o controlar algún aspecto de una entidad de hardware. Un conjunto de RDR en cada recurso describe los instrumentos de gestión alojados por ese recurso, incluida la información sobre lo que se está supervisando o controlando.
Existen siete tipos de instrumentos de gestión que pueden utilizarse para modelar diversas capacidades de la infraestructura de gestión de la plataforma. Los primeros cuatro: sensores, controles, repositorios de datos de inventario y temporizadores de vigilancia, son instrumentos de gestión básicos que suelen corresponderse con capacidades de gestión de la plataforma discretas. Los otros tres: anunciadores, DIMI y FUMI, son más complejos y encapsulan funciones lógicas que la infraestructura de gestión de la plataforma puede proporcionar.
Los sensores se utilizan para modelar la capacidad de monitorear algún aspecto de una entidad. Los sensores HPI se basan en los sensores IPMI.
Un sensor HPI informa sobre el estado del hardware que se está monitoreando a través de un conjunto de hasta 15 bits individuales, llamados estados de eventos. Cada estado de evento se puede activar o desactivar individualmente y, cuando un estado de evento cambia, se pueden generar eventos asincrónicos para informar esto a un usuario de HPI. La interpretación de cada estado de evento puede variar según una categoría de sensor definida (por ejemplo, umbral, rendimiento, presencia, gravedad) o puede ser exclusiva de un sensor específico. Los sensores en la categoría de umbral tienen capacidades adicionales. Los sensores de umbral informan cuando un valor que se está monitoreando está por encima o por debajo de los valores de umbral configurables. Se pueden definir hasta tres umbrales superiores y tres umbrales inferiores para desviaciones menores, importantes y críticas de la norma en cualquier dirección.
Además de informar el estado del hardware monitoreado a través de estados de eventos, un sensor HPI también puede informar un valor, llamado lectura del sensor. La lectura del sensor refleja el valor actual de lo que se está monitoreando, escalado en las unidades adecuadas. Las lecturas del sensor pueden ser valores enteros, valores de punto flotante o un bloque de hasta 32 bytes de datos arbitrarios.
Los controles se utilizan para modelar la capacidad de actualizar algún aspecto de una entidad. Hay varios tipos de controles definidos en HPI, que varían según el tipo de datos que se pueden utilizar cuando se actualizan. Los controles digitales se pueden activar o desactivar, o activar o desactivar mediante pulsos. Los controles analógicos y discretos se pueden configurar en un valor de 32 bits. A los controles de flujo y de texto se les pueden proporcionar mayores cantidades de datos para controlar el parpadeo de un LED, el sonido de un avisador acústico o la visualización de datos en un panel de control. A los controles OEM (específicos del proveedor) se les puede enviar un bloque de datos, que la entidad administrada puede utilizar de formas específicas de la implementación.
Los repositorios de datos de inventario se utilizan para informar o establecer información de identificación y configuración para entidades de hardware. Normalmente, elementos como el número de modelo, el número de serie y los datos de configuración básica se almacenan en la memoria ROM o flash de una entidad de hardware. Esta información se puede leer y, en algunos casos, actualizar, a través de un repositorio de datos de inventario de HPI.
Los temporizadores de vigilancia son dispositivos que suelen implementarse con hardware especial en sistemas de alta disponibilidad. Estos dispositivos están configurados para interrumpir, reiniciar o apagar y encender automáticamente una entidad después de un período de tiempo determinado si no se reinicia mediante programación primero. El propósito de un dispositivo de temporizador de vigilancia es proporcionar un mecanismo de detección de fallas. El instrumento de administración de temporizadores de vigilancia HPI está diseñado para interactuar con este tipo de mecanismo de hardware. Está modelado muy de cerca en el temporizador de vigilancia IPMI.
Los anunciadores son instrumentos de gestión lógicos que se utilizan para interactuar con una función de visualización de alarmas en una plataforma de hardware. Debido a que se utiliza una amplia variedad de hardware de visualización de alarmas, como LED , alertas audibles, paneles de visualización de texto, etc. en diferentes plataformas de hardware, es difícil escribir un programa de aplicación para mostrar información de alarmas de una manera independiente de la plataforma. El instrumento de gestión de anunciadores de HPI proporciona una interfaz abstracta para comunicar información de alarmas a la implementación de HPI o la infraestructura de gestión subyacente, que luego puede tomar las medidas adecuadas para mostrar esa información en una plataforma en particular.
Los DIMI son instrumentos de gestión lógica que se utilizan para coordinar la ejecución de firmware o software de diagnóstico en línea o fuera de línea en varias entidades de hardware. Un DIMI proporciona información al programa de usuario de HPI que indica cuál será el impacto en el servicio de la ejecución de diagnósticos y proporciona una interfaz común para iniciar, detener y monitorear la ejecución de los programas de diagnóstico. Esta función está integrada con HPI para ayudar a estandarizar el diagnóstico y la reparación automáticos de condiciones de falla y para respaldar la capacidad de servicio en línea.
Los FUMI son instrumentos de gestión lógica que se utilizan para respaldar la instalación de actualizaciones de firmware en entidades de hardware programables. En el caso de las entidades de hardware que incluyen firmware actualizable en campo, el FUMI proporciona información sobre las versiones de firmware instaladas actualmente y proporciona una interfaz estándar para identificar una nueva versión para cargar y para coordinar el proceso de actualización, incluida la posible copia de seguridad y la reversión a versiones anteriores, si es necesario.
Además de un conjunto de instrumentos de gestión como los descritos anteriormente, un recurso HPI también puede proporcionar hasta cuatro capacidades de gestión adicionales. Estas capacidades a nivel de recurso son esencialmente instrumentos de gestión especiales, de los cuales puede haber como máximo uno de cada tipo admitido por un recurso. Si un recurso en particular proporciona o no estas capacidades diversas y a qué entidad se aplican se describe en un registro de datos al que puede acceder el usuario HPI para el recurso. En ese registro se define una única ruta de entidad, por lo que cualquiera de estas capacidades, si está presente, se aplicará a la misma entidad.
Los programas de usuario acceden a la gestión de plataformas basada en HPI abriendo una sesión con un dominio. El programa de usuario puede abrir una sesión con un dominio específico especificando un identificador de dominio o, más comúnmente, puede abrir una sesión con un dominio predeterminado. Con una sesión establecida, el programa de usuario puede acceder a varias funciones de nivel de dominio o puede acceder a cualquiera de los recursos que se enumeran actualmente como miembros del dominio. Debido a que una sesión solo permitirá el acceso a los recursos que actualmente son miembros del dominio, el control de acceso de usuarios se puede aplicar mediante una implementación de HPI limitando qué recursos son miembros de cada dominio y limitando qué usuarios pueden establecer sesiones con esos dominios.
Una de las funciones más importantes del Dominio es proporcionar información, a través de la Tabla de Presencia de Recursos (RPT), sobre todos los Recursos que son miembros del Dominio. Una segunda tabla, la Tabla de Referencia de Dominio (DRT), proporciona información sobre otros Dominios HPI a los que se puede acceder abriendo Sesiones adicionales.
La interfaz HPI proporciona tres servicios a nivel de dominio que un programa de usuario puede utilizar para mantenerse informado de condiciones excepcionales en la plataforma de hardware. El más importante de ellos es el Servicio de gestión de eventos . Un usuario puede solicitar que se reenvíen eventos desde el dominio en cualquier sesión abierta. Cuando ocurren eventos significativos en las entidades de hardware monitoreadas por cualquiera de los recursos que son miembros del dominio, se generan mensajes de eventos y se ponen en cola en todas las sesiones abiertas que han realizado dicha solicitud. A través de este mecanismo, los programas de usuario pueden mantenerse informados de los cambios en la plataforma administrada sin necesidad de consultar continuamente el estado. Los eventos también se pueden almacenar en el registro de eventos del dominio y recuperarlos en un momento posterior para realizar un análisis histórico. Finalmente, el programa de usuario puede acceder a la tabla de alarmas del dominio , que informa sobre las condiciones de alarma actuales presentes en cualquiera de los recursos que son miembros del dominio.
Una característica clave de la especificación HPI es la forma en que maneja la reconfiguración dinámica o las acciones de intercambio en caliente en la plataforma administrada. El intercambio en caliente se refiere a la capacidad de agregar o quitar componentes de hardware en una plataforma en ejecución. HPI denomina a una entidad de hardware que se puede intercambiar en caliente como una unidad reemplazable en campo o FRU. A menudo, especialmente en arquitecturas de sistemas como AdvancedTCA, las FRU incluyen sus propios controladores de administración de plataforma. Por lo tanto, el intercambio en caliente de una FRU puede modificar simultáneamente tanto el conjunto de entidades de hardware que se administrarán como la infraestructura disponible para esa administración.
El enfoque de HPI para la gestión de intercambio en caliente refleja esto al modelar la adición o eliminación de una entidad de hardware mediante la adición o eliminación de un recurso en un dominio. Si la FRU no incluye su propio controlador de administración, es posible que el recurso no tenga ninguna capacidad de administración asignada, pero aún así se utiliza para informar la presencia de la FRU en el sistema. Por otro lado, si la FRU incluye un controlador de administración, entonces el recurso que se agrega al dominio puede alojar nuevos instrumentos de administración u otras capacidades y ponerlas a disposición del usuario de HPI.
El recurso asociado con una FRU siempre estará en uno de los cinco estados de intercambio en caliente, que son legibles por el usuario de HPI: No presente, Inactivo, Pendiente de inserción, Activo, Pendiente de extracción . El estado No presente nunca es informado por un recurso, porque cuando la FRU no está presente en el sistema, el recurso no debería existir como miembro de ningún dominio. Los otros cuatro estados son aplicables para las FRU que están físicamente presentes en el sistema, ya sea que estén o no completamente operativas. Cuando un recurso cambia a un nuevo estado de intercambio en caliente, se envía un evento de HPI a los programas de usuario que han solicitado notificaciones de eventos.
Los recursos HPI que modelan FRU intercambiables en caliente se pueden configurar para admitir intercambio en caliente no administrado o intercambio en caliente administrado . Un recurso que admita intercambio en caliente no administrado informará su estado de intercambio en caliente actual, pero el usuario no tiene control sobre las operaciones de intercambio en caliente de la FRU. Cuando un recurso admite intercambio en caliente administrado, un programa de usuario puede interactuar con la implementación de HPI y la infraestructura de administración de la plataforma subyacente para coordinar las acciones necesarias para integrar las FRU recientemente agregadas o desactivar las FRU que se eliminan del sistema.
El Foro SA tiene como objetivo que las nuevas versiones de sus especificaciones sean compatibles con versiones anteriores. En el caso de la especificación HPI, esto significa que los programas de usuario escritos para funcionar con implementaciones HPI de una determinada versión deben seguir funcionando sin cambios con implementaciones HPI que admitan una versión posterior de la especificación. Este objetivo se ha cumplido con las especificaciones HPI publicadas desde la especificación SAI-HPI-B.01.01. La serie “B” de especificaciones HPI no es compatible con versiones anteriores de la especificación SAI-HPI-A.01.01.
Para lograr la compatibilidad con versiones anteriores de las especificaciones HPI, se emplean varias estrategias:
a) Las funciones definidas en versiones anteriores de la especificación HPI se incluyen en versiones posteriores, sin cambios en el prototipo de la función. Las funciones obsoletas se conservan, pero se incluye un aviso en la especificación de que no deben ser utilizadas por nuevos programas de usuario.
b) Se pueden agregar nuevas funciones en nuevas versiones de la especificación HPI, siempre que su uso no sea requerido por programas existentes.
c) Varias enumeraciones que informan datos como tipos de entidad de hardware, tipos de sensor, etc. se declaran en la especificación HPI como abiertas. La lista de códigos de retorno de error que las funciones HPI pueden devolver también se declara como abierta. Las nuevas versiones de la especificación HPI no eliminan ni cambian ningún valor enumerado existente, pero pueden agregar nuevos valores a una enumeración abierta. Los programas de usuario deben aceptar valores que no estén definidos actualmente y tratarlos como "válidos pero indefinidos". Al hacerlo, el programa puede continuar funcionando cuando se usa con una implementación que está construida para una versión más nueva de la especificación HPI, que puede haber definido nuevos valores para la enumeración.
d) Las estructuras de datos que se pasan de las funciones HPI al usuario no pueden aumentar de longitud en las nuevas versiones de la especificación HPI ni cambiar el formato de los datos que se definieron en versiones anteriores. Sin embargo, los bits no definidos previamente en los campos de bits se pueden definir en las nuevas versiones de la especificación HPI y se puede utilizar el espacio no utilizado en las uniones, siempre que los programas que no reconozcan los nuevos bits o el nuevo uso del espacio no utilizado sigan funcionando correctamente.
e) Las estructuras de datos que se pasan a las funciones HPI desde el usuario pueden cambiar en las nuevas versiones de la especificación HPI, siempre que el cambio se realice de manera tal que un programa existente que pase la estructura definida anteriormente siga funcionando correctamente.
Debido a que HPI se utiliza ampliamente en sistemas AdvancedTCA, el SA Forum publicó una especificación de mapeo, denominada SAIM-HPI-B.01.01-ATCA en enero de 2006. El propósito de esta especificación es proporcionar orientación a los implementadores de interfaces de administración de HPI sobre una forma recomendada de modelar esta compleja arquitectura de sistema con HPI. En febrero de 2010 se publicó una nueva especificación de mapeo, SAIM-HPI-B.03.02-xTCA, que revisa este mapeo y lo extiende a los sistemas MicroTCA.
La especificación de mapeo de HPI a xTCA define una manera de representar la capacidad de administración de una plataforma xTCA en HPI en un solo dominio HPI. Se especifica la denominación de la ruta de entidad de los componentes del sistema xTCA y se definen los instrumentos de administración que reflejan la información de administración de la plataforma y las funciones de control disponibles en estas plataformas.
La especificación de mapeo también define los recursos para el chasis xTCA, el administrador de estantes, el administrador de portadores y otras FRU. En la versión original de la especificación, se definían y exigían recursos para todas las “ranuras” del chasis o de las tarjetas portadoras que podrían alojar FRU. En la actualización publicada en 2010, estos recursos de ranura se hicieron opcionales.
La especificación de mapeo de HPI a xTCA está dirigida a dos públicos. El primero está formado por desarrolladores de plataformas que desean incorporar una interfaz HPI en una plataforma AdvancedTCA o MicroTCA. La especificación proporciona una plantilla para modelar los sistemas.
La segunda audiencia está formada por usuarios de HPI que desean crear aplicaciones portátiles o programas de middleware en múltiples plataformas AdvancedTCA o MicroTCA. Sin embargo, los usuarios de HPI que desean proporcionar programas portátiles tanto para xTCA como para otras arquitecturas de plataformas de hardware no necesariamente necesitan hacer referencia a la Especificación de mapeo de HPI a xTCA. Esto se debe a que las implementaciones de HPI que siguen la Especificación de mapeo de HPI a xTCA presentarán capacidades básicas de administración de plataformas de una manera que se pueda descubrir y usar a través de la interfaz estándar de HPI. Algunas capacidades de administración de plataformas que son exclusivas de las plataformas xTCA no se pueden usar sin hacer referencia a la Especificación de mapeo, pero la mayoría de las aplicaciones de usuario de HPI de propósito general pueden ignorarlas razonablemente.
Se han producido varias implementaciones ampliamente difundidas de la especificación HPI, más notablemente por parte de proveedores de plataformas que construyen sistemas informáticos AdvancedTCA u otras plataformas informáticas de alta disponibilidad. En la mayoría de las implementaciones, la propia interfaz de programación de aplicaciones HPI se proporciona a través de una biblioteca vinculada a programas de aplicación. Este módulo de biblioteca normalmente se comunica con un servidor HPI que se ejecuta como un proceso demonio , que realiza las funciones de los dominios y recursos HPI, comunicándose con una infraestructura de gestión subyacente según sea necesario.
Varias implementaciones de HPI se basan en una implementación de código abierto de la especificación HPI, denominada OpenHPI. OpenHPI también sigue el diseño general que se muestra en la Figura 6, ya que incluye un módulo de biblioteca que se vincula con los programas de aplicación y un módulo demonio con el que se comunican los módulos de biblioteca. El proceso demonio OpenHPI está diseñado para integrarse con uno o más módulos de complemento , que manejan la comunicación descendente con varias infraestructuras de gestión de plataformas.
El Registro de Implementación del Foro SA [ enlace muerto permanente ] es un proceso que permite que las implementaciones de las especificaciones del Foro SA se registren y se pongan a disposición del público. No se requiere ser miembro para registrar implementaciones. Las implementaciones que se hayan registrado correctamente pueden denominarse "Registradas en el Foro de Disponibilidad de Servicios".