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 plataforma de sistemas informáticos. La API admite tareas que incluyen leer sensores de temperatura o voltaje integrados en un procesador, configurar registros de hardware, acceder a información de inventario del sistema como números de modelo y números de serie, y realizar actividades más complejas, como actualizar el firmware del sistema o diagnosticar fallas del sistema.
HPI está diseñado para su uso con sistemas informáticos de alta disponibilidad modulares y tolerantes a fallas , que generalmente incluyen funciones de detección automática de fallas y redundancia de hardware para que puedan brindar Disponibilidad de servicio continua. Las características adicionales comunes en las plataformas de hardware utilizadas para aplicaciones de alta disponibilidad incluyen la capacidad de servicio en línea y la capacidad de actualización a través de 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.
Historia
Un motivador principal para el desarrollo de la especificación HPI fue la aparición de plataformas de hardware de computadora modular y sistemas comerciales listos para usar (COTS) a fines de la década de 1990 y principios de la de 2000. Esto incluyó 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 bladed.
La necesidad de la especificación HPI fue identificada por primera vez por un grupo de la industria llamado "Foro de alta disponibilidad", 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 documento técnico, “Proporcionar soluciones de alta disponibilidad de arquitectura abierta” a principios de 2001. A partir de ese trabajo, Intel Corporation inició un proyecto para definir una API de administración de plataforma de hardware estándar llamada Interfaz de administración de chasis universal (UCMI). Este trabajo se migró al consorcio SA Forum recién 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 de HPI a través del Protocolo simple de administración de redes (SNMP) y especificaciones que describen el uso de HPI en las plataformas AdvancedTCA y MicroTCA. La Tabla 1 enumera todas las especificaciones publicadas por SA Forum en la familia HPI.
Etiqueta de especificación | Fecha de publicación | Notas |
---|---|---|
SAI-HPI-A.01.01 | 7 de octubre de 2002 | Especificación HPI original |
SAI-HPI-B.01.01 | 3 de mayo de 2004 | Revisión importante de la especificación HPI básica. Se abordaron problemas de implementación y usabilidad en la especificación original. |
SAI-HPI-SNMP-B.01.01 | 3 de mayo de 2004 | SNMP MIB para acceder a implementaciones de HPI |
SAI-HPI-B.02.01 | 18 de enero de 2006 | Revisión menor de la especificación HPI básica. Se agregó capacidad de administración de carga, FUMI y DIMI. |
SAIM-HPI-B.01.01-ATCA | 18 de enero de 2006 | Especificación de mapeo de HPI a AdvancedTCA |
SAI-HPI-B.03.01 | 21 de octubre de 2008 | Revisión menor de la especificación HPI básica. Mejoras a FUMI; algunas funciones API nuevas |
SAI-HPI-B.03.02 | 20 de noviembre de 2009 | Correcciones menores a la especificación HPI base |
SAIM-HPI-B.03.02-xTCA | 19 de febrero de 2010 | Revisión importante de la especificación de mapeo AdvancedTCA. Incluye mapeo para plataformas MicroTCA y AdvancedTCA. |
Las especificaciones de HPI y la Especificación de interfaz de aplicación (AIS) se han desarrollado por separado dentro del Foro de SA. Aunque ambos están pensados para abordar la funcionalidad requerida para los niveles más altos de disponibilidad del servicio, se pueden utilizar de forma independiente entre sí. 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 los proveedores de la plataforma pueden implementar la especificación HPI y utilizarla directamente la aplicación o los programas de gestión sin el uso de otro middleware de gestión de SA Forum.
La intersección principal entre las especificaciones AIS y HPI se encuentra en AIS Platform Management Service (PLM). El servicio PLM se define con la expectativa de que la gestión de la plataforma de hardware se proporcione mediante una implementación de la especificación HPI en la plataforma de hardware de destino.
Arquitectura HPI
La especificación HPI no dicta ni asume qué capacidades de gestión de plataforma deben estar presentes en una plataforma de hardware. Más bien, proporciona una forma genérica y coherente de modelar las capacidades presentes y proporciona una forma para que los programas de aplicación del usuario aprendan los detalles de las capacidades de gestión de la 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 los sensores de temperatura o voltaje, los registros de configuración y los elementos de visualización, o proporcionan interfaces para las 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 puede descubrir la configuración y las capacidades de cada recurso.
Si bien los recursos de HPI son estructuras abstractas, normalmente se utilizan para modelar las capacidades de gestión de los controladores de gestió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 de 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 están organizados en dominios . A menudo, una implementación de HPI implementará solo un dominio para todos los recursos, pero es posible subdividir el sistema en múltiples dominios, si es necesario. Por ejemplo, en algunos sistemas modulares, distintos usuarios pueden poseer y gestionar varios módulos. Para respaldar esto con HPI, todos los Recursos utilizados para administrar los módulos propiedad de un usuario específico pueden ubicarse en un solo Dominio, y ese usuario solo tiene acceso 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. Con esta Sesión establecida, el programa de usuario puede entonces 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 dirigidos por dominio y recurso, los componentes de hardware 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ísico en HPI se denominan Entidades y se identifican con una Ruta de entidad. Una ruta de entidad contiene varios elementos, 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 racks puede tener la ruta de entidad de 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 de HPI maneje la gestión de la plataforma para más de una entidad. También es posible administrar una sola entidad a través de múltiples recursos de HPI. Esta posibilidad de una combinación arbitraria entre los recursos de HPI y las entidades de hardware que se administran puede parecer confusa, pero es una característica importante de la arquitectura de HPI. Esto se debe a que permite modelar infraestructuras de gestión complejas que pueden incluir elementos de gestión en banda y fuera de banda de una única entidad de hardware, y sistemas en los que un controlador de gestión en una pieza de equipo proporciona gestión para otra pieza de equipo.
Instrumentos de gestión
Los recursos de HPI pueden albergar un conjunto de instrumentos de gestión. Cada Instrumento de Gestión modela la capacidad de monitorear 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 información sobre lo que se está monitoreando o controlando.
Hay siete tipos de instrumentos de gestión que se pueden utilizar 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 normalmente se asignan a capacidades de gestión de plataformas 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.
Sensores
Los sensores se utilizan para modelar la capacidad de monitorear algún aspecto de una entidad. Los sensores HPI se basan en el modelo de los sensores IPMI.
Un sensor HPI reporta información de estado sobre el 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 afirmar o anular individualmente, y cuando cambia un estado de evento, se pueden generar eventos asíncronos para informar de esto a un usuario de HPI. La interpretación de cada estado de evento puede variar según una categoría de sensor definida (p. Ej., Umbral, rendimiento, presencia, gravedad) o puede ser única para un sensor específico. Los sensores en la categoría de umbral tienen capacidades adicionales. Los sensores de umbral informan cuando un valor supervisado 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, mayores y críticas de la norma en cualquier dirección.
Además de informar el estado del hardware monitoreado a través de los 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 apropiadas. Las lecturas del sensor pueden ser valores enteros, valores de punto flotante o un bloque de hasta 32 bytes de datos arbitrarios.
Control S
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 encender o apagar, o pulsar o encender o apagar. Los controles analógicos y discretos se pueden establecer en un valor de 32 bits. Los controles de flujo y texto pueden recibir mayores cantidades de datos para controlar el parpadeo de un LED, el sonido de un zumbador 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 usar en formas específicas de implementación.
Repositorios de datos de inventario (IDR)
Los repositorios de datos de inventario se utilizan para informar o establecer información de identificación y configuración para las entidades de hardware. Por lo general, 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 en 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.
Temporizadores de vigilancia
Los temporizadores de vigilancia son dispositivos que a menudo se implementan con hardware especial en sistemas de alta disponibilidad. Estos dispositivos están configurados para interrumpir, restablecer o apagar y encender automáticamente una Entidad después de un cierto período de tiempo si no se restablece primero mediante programación. El propósito de un dispositivo temporizador de vigilancia es proporcionar un mecanismo de detección de fallas. El instrumento de gestión del temporizador HPI Watchdog está diseñado para interactuar con este tipo de mecanismo de hardware. Está modelado muy de cerca en el temporizador de vigilancia de IPMI.
Anunciadores
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 alarma de una manera independiente de la plataforma. El Instrumento de administración del anunciador de HPI proporciona una interfaz abstracta para comunicar información de alarma a la implementación de HPI o la infraestructura de administración subyacente, que luego puede tomar las acciones apropiadas para mostrar esa información en una plataforma en particular.
Instrumentos de gestión de iniciadores de diagnóstico (DIMI)
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 automático y la reparación de condiciones de falla y para respaldar la capacidad de servicio en línea.
Instrumentos de gestión de actualización de firmware (FUMI)
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. Para las Entidades de hardware que incluyen firmware actualizable en campo, FUMI proporciona información sobre las versiones de firmware actualmente instaladas 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 reversión. a versiones anteriores, si es necesario.
Capacidades a nivel de recursos
Además de un conjunto de instrumentos de gestión como se describe anteriormente, un recurso de HPI también puede proporcionar hasta cuatro capacidades de gestión adicionales. Estas capacidades a nivel de recursos son esencialmente instrumentos de gestión especiales, de los cuales puede haber como máximo uno de cada tipo soportado por un recurso. Si un Recurso en particular proporciona o no estas capacidades diversas y a qué Entidad se aplican se describen en un registro de datos accesible por el usuario de HPI para el Recurso. Se define una única ruta de entidad en ese registro, por lo que cualquiera de estas capacidades, si está presente, se aplicará a la misma entidad.
- La capacidad de administración de energía a nivel de recursos actúa como un control especializado para encender o apagar la entidad designada.
- La capacidad de reinicio a nivel de recursos actúa como un control especializado para provocar una operación de reinicio completo o suave en la entidad designada, o si es compatible, para mantener la señal de reinicio en un estado afirmado para evitar que la entidad opere.
- La capacidad de gestión de carga a nivel de recursos actúa como un control especializado que interactúa con el programa de arranque de la entidad designada para identificar qué sistema operativo u otro software debe cargarse cuando se realiza una operación de arranque.
- La capacidad de gestión de la configuración a nivel de recursos proporciona un método para que un usuario de HPI dirija el recurso para guardar o restaurar la información de configuración, como los niveles de umbral del sensor hacia o desde un medio de almacenamiento persistente.
Funciones de dominio
Los programas de usuario acceden a la gestión de la plataforma 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 a nivel de Dominio, o puede acceder a cualquiera de los Recursos que actualmente están listados como miembros del Dominio. Debido a que una sesión solo permitirá el acceso a los recursos que actualmente son miembros del dominio, una implementación de HPI puede imponer el control de acceso de los usuarios limitando qué recursos son miembros de cada dominio y 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 las 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 los eventos se reenvíen desde el dominio en cualquier sesión abierta. Cuando ocurren eventos importantes en las Entidades de hardware monitoreadas por cualquiera de los Recursos que son miembros del Dominio, los mensajes de Evento se generan y se ponen en cola para todas las Sesiones abiertas que hayan 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 sondear continuamente el estado. Los eventos también pueden almacenarse en el Registro de eventos del dominio y recuperarse en un momento posterior para su análisis histórico. Finalmente, la Tabla de Alarmas de Dominio es accesible por el programa de usuario e informa sobre las condiciones de alarma actuales presentes en cualquiera de los Recursos que son miembros del Dominio.
Gestión de intercambio en caliente
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. Hot-swap se refiere a la capacidad de agregar o quitar componentes de hardware en una plataforma en ejecución. HPI denomina una entidad de hardware que se puede intercambiar en caliente como una unidad reemplazable en el campo o FRU. A menudo, especialmente en arquitecturas de sistemas como AdvancedTCA, las FRU incluyen sus propios controladores de gestió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 agregando o eliminando un Recurso en un Dominio. Si la FRU no incluye su propio controlador de gestión, es posible que el Recurso no tenga ninguna capacidad de gestión asignada, pero aún se utiliza para informar la presencia de la FRU en el sistema. Por otro lado, si la FRU incluye un controlador de administración, el recurso que se agrega al dominio puede albergar nuevos instrumentos de administración u otras capacidades y ponerlos 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, Inserción pendiente, Activo, Extracción pendiente . El estado No presente nunca lo informa 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 a las FRU que están físicamente presentes en el sistema, estén o no en pleno funcionamiento. 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 de HPI que modelan FRU intercambiables en caliente se pueden configurar para admitir el intercambio en caliente no administrado o el intercambio en caliente administrado . Un recurso que admita el intercambio en caliente no administrado informará su estado actual de intercambio en caliente, pero el usuario no tiene control sobre las operaciones de intercambio en caliente de la FRU. Cuando un recurso admite el 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 recién agregadas o para desactivar las FRU que se eliminan del sistema.
Compatibilidad con versiones anteriores
Es un objetivo del Foro SA que las nuevas versiones de sus especificaciones se mantengan compatibles con versiones anteriores. En el caso de la especificación HPI, esto significa que los programas de usuario escritos para trabajar con implementaciones HPI de una determinada versión deberían continuar 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 la especificación SAI-HPI-A.01.01.
Para lograr la compatibilidad con versiones anteriores de las especificaciones de HPI, se emplean varias estrategias:
a) Las funciones definidas en versiones anteriores de la especificación de HPI se incluyen en versiones posteriores, sin cambios en el prototipo de función. Las funciones obsoletas se conservan, pero en la especificación se incluye un consejo 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 los programas existentes.
c) Varias enumeraciones que informan datos como tipos de entidades de hardware, tipos de sensores, etc. se declaran en la especificación HPI como abiertas. La lista de códigos de retorno de error que pueden devolver las funciones de HPI 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 no definidos". Al hacerlo, el programa puede seguir funcionando cuando se utiliza con una implementación que se construye a una versión más reciente 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 de HPI al usuario no pueden crecer en longitud en nuevas versiones de la especificación de HPI o cambiar el formato de los datos que se definieron en versiones anteriores. Sin embargo, los bits previamente no definidos en los campos de bits se pueden definir en las nuevas versiones de la especificación HPI, y se puede usar 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 continúen funcionando. correctamente.
e) Las estructuras de datos que el usuario pasa a las funciones de HPI pueden cambiar en nuevas versiones de la especificación de HPI, siempre que el cambio se realice de tal manera que un programa existente que pase la estructura definida anteriormente continúe funcionando correctamente.
Especificación de asignación de HPI a xTCA
Debido a que HPI se usa ampliamente en sistemas AdvancedTCA, el Foro de SA publicó una Especificación de mapeo, etiquetada como SAIM-HPI-B.01.01-ATCA en enero de 2006. El propósito de esta especificación es brindar orientación a los implementadores de interfaces de administración de HPI de una manera recomendada. para 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 forma de representar la capacidad de administración de una plataforma xTCA en HPI en un solo dominio de HPI. Se especifica el nombre de la ruta de entidad de los componentes del sistema xTCA y se definen los instrumentos de gestión que reflejan la información de gestión de la plataforma y las funciones de control disponibles en estas plataformas.
La especificación de mapeo también define Recursos para el chasis xTCA, el administrador de estantes, el administrador de portadoras y otras FRU. En la versión original de la especificación, los recursos se definieron y requerían para todas las "ranuras" en el chasis o en las tarjetas portadoras que potencialmente podrían albergar FRU. En la actualización publicada en 2010, estos recursos de Slot se hicieron opcionales.
La especificación de mapeo de HPI a xTCA sirve a dos públicos. El primero consiste en 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 consiste en 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 deseen proporcionar programas portátiles tanto para xTCA como para otras arquitecturas de plataforma de hardware no necesitan necesariamente 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 las capacidades básicas de administración de la plataforma de una manera que sea detectable y utilizable a través de la interfaz estándar de HPI. Algunas capacidades de gestión de plataformas que son exclusivas de las plataformas xTCA no se pueden utilizar sin hacer referencia a la Especificación de mapeo, pero la mayoría de las aplicaciones de usuario de HPI de propósito general las ignoran razonablemente.
Implementaciones de HPI
Se han producido varias implementaciones ampliamente implementadas de la especificación HPI, sobre todo 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 del programa de aplicación de HPI se proporciona a través de una biblioteca que está vinculada a los 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 de 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 programas de aplicación y un módulo demonio con el que se comunican los módulos de biblioteca. El proceso del demonio OpenHPI está diseñado para integrarse con uno o más módulos enchufables , que manejan la comunicación descendente con varias infraestructuras de gestión de plataforma.
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 membresía para registrar implementaciones. Las implementaciones que se han registrado correctamente pueden denominarse "Registro de foro de disponibilidad de servicios".