La Especificación de Interfaz de Aplicación ( AIS ) es una colección de especificaciones abiertas que definen las interfaces de programación de aplicaciones (API) para software informático de aplicaciones de alta disponibilidad. Es desarrollada y publicada por el Foro de Disponibilidad de Servicios (SA Forum) y se encuentra disponible de forma gratuita. Además de reducir la complejidad de las aplicaciones de alta disponibilidad y acortar el tiempo de desarrollo, las especificaciones tenían como objetivo facilitar la portabilidad de las aplicaciones entre diferentes implementaciones de middleware y admitir a desarrolladores externos en un campo que en el pasado era altamente propietario.
El AIS es parte de las Interfaces de Disponibilidad de Servicios (SAI) del Foro SA. Las especificaciones originales, publicadas el 14 de abril de 2003, fueron el Marco de Gestión de la Disponibilidad (AMF), el Servicio de Membresía de Clúster (CLM) y otros cuatro servicios de utilidad (Punto de Control, Evento, Mensaje, Bloqueo).
Se agregaron servicios adicionales en versiones posteriores.
AIS consta de 12 servicios y dos marcos de trabajo. Los servicios se clasifican en tres grupos funcionales: servicios de plataforma AIS, servicios básicos de gestión AIS y servicios generales de utilidad AIS, además de los marcos de trabajo AIS.
Inicialmente, las API se definieron sólo en el lenguaje de programación C , pero a partir de julio de 2008, el mapeo Java de las diferentes API de servicio se está publicando de forma incremental.
Los diferentes servicios y marcos de las especificaciones de interfaz se han diseñado para que sean modulares y, hasta cierto punto, independientes entre sí. Esto permite que exista un sistema que solo proporcione AIS y no HPI y viceversa.
La única dependencia arquitectónica requerida es la dependencia del Servicio de membresía del clúster (CLM). Todos los servicios AIS, con excepción del Servicio de administración de la plataforma (PLM) y el Servicio de temporizador (TMR), dependen del CLM.
Se espera que todos los servicios AIS utilicen los servicios de administración AIS para exponer sus interfaces administrativas, configuración e información de administración del tiempo de ejecución (fig. 2).
El servicio de gestión de plataformas (PLM) proporciona una vista lógica del hardware y del software de bajo nivel del sistema. El software de bajo nivel en este sentido comprende el sistema operativo y las capas de virtualización que proporcionan entornos de ejecución para todo tipo de software.
Las principales entidades lógicas implementadas por PLM son:
PLM mantiene el estado de estas entidades en el modelo de información y proporciona medios para controlarlas y realizar un seguimiento de cualquier cambio de estado. Para cumplir con estas tareas en el caso de los sistemas operativos, el servicio PLM suele utilizar HPI. En el caso de los sistemas operativos, PLM se encarga de recuperar toda la información necesaria sobre el estado del sistema operativo y cualquier capa de virtualización disponible.
El servicio de pertenencia al clúster (CLM) proporciona a las aplicaciones información sobre la pertenencia a los nodos que se han configurado administrativamente en la configuración del clúster (estos nodos también se denominan nodos del clúster o nodos configurados) y es fundamental para cualquier sistema en clúster. Un clúster consta de este conjunto de nodos configurados, cada uno con un nombre de nodo único.
Las dos entidades lógicas implementadas por el Servicio de Membresía del Clúster son:
El CLM proporciona API para recuperar la información actual sobre la pertenencia al clúster y realizar un seguimiento de los cambios de pertenencia (por ejemplo, abandono o incorporación de un nodo). Todos los servicios AIS de todo el clúster deben utilizar la API de seguimiento del CLM para determinar la pertenencia.
Las distintas entidades implementadas por los servicios AIS (por ejemplo, entornos de ejecución, puntos de control, componentes, etc.) se representan como objetos gestionados en el Modelo de información (IM) de SA Forum, que puede considerarse como una base de datos de gestión de configuración . Los objetos gestionados son instancias de clases de objetos definidas por la especificación de servicio AIS pertinente, que define los atributos de clase y las operaciones administrativas. Las operaciones administrativas especificadas para las clases de objetos representan operaciones que se pueden realizar en las entidades representadas por los objetos, por ejemplo, bloquear una unidad de servicio o exportar el contenido del IM en formato XML. Los objetos del IM se almacenan en una jerarquía de árbol donde un objeto puede tener, como máximo, un objeto padre y cualquier número de objetos hijos.
Las entidades lógicas representadas por los objetos en el IM no suelen ser implementadas por el propio Servicio IMM; en su lugar, las aplicaciones de usuario y los Servicios AIS, como el Servicio de Punto de Control o el Marco de Gestión de Disponibilidad, proporcionan su implementación. Por lo tanto, se denominan implementadores de objetos (OI). Para fines de gestión, todos los servicios AIS exponen sus entidades implementadas como objetos gestionados a través del servicio IMM.
Hay dos categorías de objetos y atributos en el IM: tiempo de ejecución y configuración.
Los objetos y atributos de tiempo de ejecución reflejan el estado actual de las entidades que representan: son denaturaleza descriptiva .
Por el contrario, los objetos y atributos de configuración son prescriptivos , mientras que para las aplicaciones de gestión (o administradores de objetos , OM) son los medios para proporcionar información a los implementadores de objetos sobre qué entidades necesitan implementar.
Los objetos de configuración pueden incluir atributos de configuración y de tiempo de ejecución, mientras que los objetos de tiempo de ejecución pueden incluir solo atributos de tiempo de ejecución. Las operaciones administrativas se pueden definir en ambas categorías de objetos.
En consecuencia, el Servicio IMM expone una interfaz “ hacia el sur ” –la API IMM-OI– a los implementadores de objetos y una interfaz “ hacia el norte ” –la API IMM-OM– a las aplicaciones de gestión (fig. 5), por ejemplo, los agentes SNMP, y media entre estas dos partes. También es responsable de almacenar los objetos y atributos persistentes.
El servicio de registro está destinado al registro de eventos , es decir, para recopilar información de todo el clúster basada en funciones (a diferencia de información específica de la implementación) sobre el sistema, lo que es adecuado para administradores de sistemas o herramientas automatizadas.
El servicio de registro permite que las aplicaciones expresen y escriban registros de registro a través de secuencias de registro que conducen a destinos de salida específicos, como un archivo con nombre. Una vez en el destino de salida, un registro de registro está sujeto a reglas de formato de salida, que son configurables y públicas. La aplicación de registro no necesita conocer ninguno de estos aspectos (por ejemplo, la ubicación del archivo de destino, la rotación o el formato del archivo, etc.) ya que el servicio de registro los maneja en función de la configuración actual para la secuencia de registro de destino. Dado que el formato de salida es público, las herramientas de terceros pueden leer estos archivos de registro.
Se especifican cuatro tipos de flujos de registro: alarma (registros de registro basados en ITU X.733 e ITU X.736), notificación (registros de registro basados en ITU X.730 e ITU X.731), sistema y aplicación . Las aplicaciones utilizan el tipo de aplicación para definir flujos de registro específicos de la aplicación. Hay exactamente un flujo de registro predefinido para cada uno de los tipos de flujo de registro de alarma, notificación y sistema en un clúster de SA Forum. Las aplicaciones de usuario pueden utilizar cualquiera de los flujos predefinidos o crear nuevos flujos de registro específicos de la aplicación.
El servicio de notificación se basa, en gran medida, en el modelo de gestión de fallos de la UIT-T (que se encuentra en la serie de documentos X.700), así como en muchas otras recomendaciones de apoyo.
El servicio de notificaciones se centra en el concepto de notificación , que explica un incidente o un cambio de estado. Se utiliza el término "notificación" en lugar de "evento" para distinguirlo claramente de "evento" tal como lo define el Servicio de eventos AIS.
El servicio NTF se basa en el paradigma de publicación-suscripción . Define seis tipos de notificaciones: alarma, alarma de seguridad, creación/eliminación de objetos, cambio de estado, cambio de valor de atributo y varios. Los productores generan/publican las notificaciones mediante la API del productor de notificaciones. Los consumidores de notificaciones pueden ser suscriptores , que se suscriben a las notificaciones y las reciben a medida que se producen, o lectores , que recuperan las notificaciones de los registros persistentes mediante la API del consumidor de notificaciones. Ambos tipos de consumidores de notificaciones pueden definir filtros que especifiquen las características de las notificaciones que les interesa recibir o leer.
Las notificaciones pueden ser generadas por los servicios AIS y por las aplicaciones. Los servicios AIS que generan notificaciones tienen una sección en la especificación que describe sus notificaciones.
El servicio de seguridad proporciona mecanismos que pueden ser utilizados por los Servicios AIS para autenticar los procesos de cliente de los Servicios AIS (y potencialmente otros) dentro del clúster y para autorizarlos a realizar actividades específicas. Estos mecanismos pueden utilizarse para preservar la integridad de la infraestructura de alta disponibilidad y de las aplicaciones de SA Forum, incluidos sus datos, al protegerlas contra el acceso no autorizado.
La aplicación de la seguridad se delega en las propias implementaciones del Servicio AIS: los Servicios AIS con seguridad habilitada solicitan autorización a la implementación de SEC en nombre de sus procesos cliente a medida que inician diferentes actividades. SEC responde a estas solicitudes de autorización con una indicación de concesión o denegación, y el Servicio AIS es quien debe permitir o rechazar la operación en consecuencia. SEC proporciona estas indicaciones en función del conjunto de políticas de seguridad configuradas a través de IMM. También informa a sus suscriptores sobre los cambios de políticas mediante devoluciones de llamadas adecuadas.
El marco de gestión de la disponibilidad es el que permite la disponibilidad de los servicios en los sistemas compatibles con SA Forum. Coordina la carga de trabajo de las diferentes entidades bajo su control en función de su estado de preparación para proporcionar servicios. Para ello, es necesario describir la aplicación de acuerdo con el modelo de información especificado para AMF. Este modelo describe qué recursos pertenecen a la aplicación, dentro del clúster, y qué servicios proporciona la aplicación.
La entidad lógica básica de este modelo de información es el componente , que representa un conjunto de recursos para el marco de gestión de disponibilidad que encapsulan alguna funcionalidad específica de la aplicación. La carga de trabajo generada por el aprovisionamiento de algún servicio que puede ser asignado a un componente por AMF se representa como una instancia de servicio de componente (CSI) . Cuando el componente está proporcionando activamente el servicio, se le asigna el estado activo en nombre de la CSI que representa el servicio.
El principio fundamental del diseño tolerante a fallos es proporcionar los servicios mediante un conjunto de entidades redundantes y, por lo tanto, los componentes deben poder actuar como un recurso de reserva en nombre del CSI. Los componentes de reserva se mantienen en un estado tal que son capaces de hacerse cargo de la prestación del servicio, en caso de que el componente con la asignación activa falle. La función de AMF es asignar cargas de trabajo activas o de reserva a los componentes de una aplicación en función del estado del componente y la configuración del sistema.
En consecuencia, las API proporcionadas por el marco de gestión de disponibilidad permiten el registro de componentes, la gestión del ciclo de vida y la asignación de cargas de trabajo. Incluyen funciones para informar errores y supervisar el estado. También permiten realizar un seguimiento de la asignación de instancias de servicio de componentes entre el conjunto de componentes que protegen el CSI.
La configuración del marco de gestión de disponibilidad incluye políticas de recuperación y reparación. Permite la priorización de recursos y contempla una variedad de modelos de redundancia. Estos van desde el modelo simple 2N (también conocido como 1+1 o activo-en espera) hasta otros más sofisticados como el modelo de redundancia N-way, que permite más de una asignación en espera en nombre de la misma instancia de servicio de componente o el modelo N-way-activo que permite múltiples asignaciones activas.
Para simplificar la administración, AMF agrupa los componentes en unidades de servicio y grupos de servicio, y las instancias de servicio de los componentes en instancias de servicio. Todos ellos forman una aplicación. A través de IMM, se encuentran disponibles un conjunto de operaciones administrativas en estas entidades lógicas.
Para fines de gestión de software, las entidades que ejecutan el mismo software se agrupan en tipos, lo que permite un único punto de entrada para la configuración de estas entidades.
Un sistema compatible con SA Forum se puede caracterizar por su configuración de implementación, que consiste en el software implementado en el sistema junto con todas las entidades de software configuradas. La configuración de implementación constituye una parte esencial del modelo de información administrado por el Servicio IMM.
El marco de gestión de software (SMF) mantiene la parte del modelo de información que describe el software disponible e implementado en el clúster. Pero el objetivo principal de SMF es permitir la evolución de un sistema en vivo organizando la migración de una configuración de implementación a otra. En términos de SMF, este proceso de migración se denomina campaña de actualización .
El marco de gestión de software define un esquema XML que se utilizará para especificar una campaña de actualización. Una implementación de SMF migra el sistema de una configuración de implementación a una nueva deseada en función de dicho archivo XML, que es esencialmente un script de acciones ordenadas y cambios de configuración que conducen a la nueva configuración.
Durante esta migración, SMF
Para llevar a cabo todas estas tareas, la implementación de SMF interactúa al menos (1) con AMF para mantener la disponibilidad, (2) con IMM para realizar cambios en el modelo de información y (3) con NTF para recibir notificaciones que puedan indicar situaciones de error causadas por la campaña en curso.
El marco de gestión de software también proporciona una API para que los procesos de los clientes registren su interés en recibir devoluciones de llamadas cuando se inicia una campaña de actualización relevante en el clúster y a medida que avanza a través de hitos importantes. Esto permite la coordinación de acciones específicas de la aplicación con la actualización. Esto puede variar desde simplemente bloquear el inicio de una campaña de actualización cuando la aplicación realiza alguna tarea crítica hasta coordinar acciones de actualización a nivel de la aplicación, como actualizar el esquema de la base de datos o implementar nuevos protocolos.
Para los proveedores de software que entregan aplicaciones que se implementarán en un clúster de SA Forum, el marco de gestión de software también define un esquema XML para el archivo de tipos de entidad , que describe los tipos de entidad de software implementados por la aplicación. Esta información se utiliza para generar configuraciones de implementación adecuadas.
El servicio de puntos de control proporciona una función para que los procesos registren datos de puntos de control de forma incremental, lo que se puede utilizar para proteger una aplicación contra fallos. Cuando un proceso se recupera de un fallo (con un reinicio o un procedimiento de conmutación por error ), el servicio de puntos de control se puede utilizar para recuperar los datos de puntos de control anteriores y reanudar la ejecución desde el estado registrado, minimizando así el impacto del fallo.
Los puntos de control son entidades que abarcan todo el clúster. Una copia de los datos almacenados en un punto de control se denomina réplica de punto de control, que normalmente se almacena en la memoria principal en lugar de en el disco por razones de rendimiento. Un punto de control puede tener varias réplicas de puntos de control almacenadas en diferentes nodos del clúster para protegerlo contra fallas de nodos. El proceso que crea el punto de control puede elegir entre políticas de actualización de réplicas sincrónicas y asincrónicas. En el caso de la replicación asincrónica, también se puede seleccionar la ubicación conjunta para optimizar el rendimiento de la actualización.
El servicio de eventos es un mecanismo de comunicación multipunto a multipunto de publicación/suscripción que se basa en el concepto de canales de eventos: uno o más publicadores se comunican de forma asincrónica con uno o más suscriptores anónimos mediante el uso de eventos a través de un canal de eventos. Los canales de eventos son entidades con nombre de todo el clúster que proporcionan la entrega de eventos con el máximo esfuerzo. Los publicadores también pueden ser suscriptores en el mismo canal de eventos.
Los eventos constan de un encabezado estándar y cero o más bytes de datos de eventos publicados. La API del servicio de eventos no impone un diseño específico para los datos de eventos publicados.
Cuando un proceso se suscribe a un canal de eventos para recibir eventos publicados, especifica los filtros que se aplicarán a los eventos publicados. Los eventos solo se envían al proceso si cumplen con los filtros proporcionados.
El servicio de bloqueo es un servicio de bloqueo distribuido , que está pensado para usarse en un clúster donde los procesos en diferentes nodos pueden competir entre sí por el acceso a un recurso compartido. Para ellos, el servicio de bloqueo proporciona entidades llamadas recursos de bloqueo, que a su vez, los procesos de la aplicación usan para coordinar el acceso a esos recursos compartidos.
El Servicio de bloqueo proporciona un modelo de bloqueo simple que admite un modo de bloqueo para acceso exclusivo y otro para acceso compartido. Los bloqueos proporcionados por el Servicio de bloqueo no son recursivos. Por lo tanto, reclamar un bloqueo no implica reclamar implícitamente otro bloqueo, sino que cada bloqueo debe reclamarse individualmente.
El servicio de mensajes especifica las API para un sistema de comunicación entre procesos en todo el clúster . La comunicación se basa en colas de mensajes identificadas por un nombre lógico. Cualquier cantidad de procesos puede enviar mensajes a una cola de mensajes, pero un proceso a la vez como máximo puede abrirla para recibir. Por lo tanto, la cola de mensajes única admite patrones de comunicación punto a punto o multipunto a punto.
Los procesos que envían mensajes a una cola de mensajes desconocen la identidad del proceso receptor; por lo tanto, el proceso que originalmente recibía estos mensajes puede haber sido reemplazado por otro proceso durante una conmutación por error o un cambio.
Las colas de mensajes se pueden agrupar para formar grupos de colas de mensajes. Los grupos de colas de mensajes permiten la comunicación multipunto a multipunto. Se identifican por nombres lógicos de modo que un proceso emisor desconoce la cantidad de colas de mensajes y la ubicación de las colas de mensajes dentro del clúster con el que se está comunicando. Los grupos de colas de mensajes se pueden utilizar para distribuir mensajes entre las colas de mensajes pertenecientes al grupo de colas de mensajes. MSG define tres políticas de distribución de unidifusión (distribución de carga igualitaria, distribución de carga igualitaria local y mejor cola local) y la política de difusión ( multidifusión ).
A pedido, el Servicio de mensajes proporciona diferentes garantías de entrega (por ejemplo, reconocimiento, persistencia del mensaje, etc.) en colas de mensajes y en grupos de colas de mensajes de unidifusión.
El servicio de nombres proporciona un mecanismo mediante el cual se asocian nombres sencillos para los usuarios con objetos ('vinculados a'), de modo que se puedan buscar estos objetos a partir de sus nombres. Los objetos suelen representar puntos de acceso a servicios, puntos finales de comunicación y otros recursos que proporcionan algún tipo de servicio.
El Servicio de nombres no impone un diseño específico ni una convención sobre los nombres ( se asume la codificación UTF-8 ) ni sobre los objetos a los que están vinculados. Permite a los usuarios del servicio seleccionar y utilizar su propio esquema de nombres sin asumir ninguna configuración de hardware o software lógica específica. Se espera que los clientes del Servicio de nombres comprendan la estructura, el diseño y la semántica de los vínculos de objetos que pretenden almacenar dentro del servicio y recuperar del mismo.
El servicio de temporizador proporciona un mecanismo mediante el cual los procesos de cliente pueden configurar temporizadores y recibir notificaciones cuando un temporizador vence. Un temporizador es un objeto lógico que se crea de forma dinámica y representa su hora de vencimiento como una hora absoluta o una duración a partir de la hora actual.
El servicio de temporizador proporciona dos tipos de temporizadores: temporizadores de evento único y temporizadores periódicos. Los temporizadores de evento único expirarán una vez y se eliminarán después de la notificación. Los temporizadores periódicos expirarán cada vez que se alcance una duración especificada y se notificará al proceso sobre las expiraciones. Los temporizadores periódicos deben eliminarse explícitamente invocando una función de eliminación de temporizadores.
Todos los servicios AIS comparten el mismo modelo de programación. En toda la especificación se utilizan las mismas convenciones de nomenclatura, tipos y constantes predefinidos estándar, semántica de API, control del ciclo de vida de la biblioteca, etc.
La interfaz de aplicación de SA Forum se produce entre un proceso y una biblioteca que implementa la interfaz. La interfaz está diseñada para que la utilicen tanto procesos de aplicación de un solo subproceso como de múltiples subprocesos. El término "proceso" puede considerarse equivalente a un proceso definido por el estándar POSIX; sin embargo, AIS no exige un proceso POSIX , sino cualquier entidad equivalente que proporcione un sistema para gestionar el software en ejecución.
El servidor de área es una abstracción que representa el servidor que proporciona servicios para un área de especificación (Availability Management Framework, Cluster Membership Service, Checkpoint Service, etc.). Cada área tiene un servidor de área lógico independiente, aunque el implementador tiene la libertad de crear un módulo físico independiente para cada servidor de área o combinar uno o más servidores de área en un único módulo físico.
Las bibliotecas de implementación de áreas pueden implementarse en una o varias bibliotecas físicas; sin embargo, se requiere un proceso para inicializar, registrar y obtener un objeto de selección de sistema operativo por separado para la biblioteca de implementación de cada área. Por lo tanto, desde un punto de vista de programación, es útil considerarlas como bibliotecas separadas.
El modelo de uso es típico de una arquitectura basada en eventos, en la que la aplicación realiza una configuración y luego recibe devoluciones de llamadas a medida que ocurren los eventos (fig. 6).
El uso de una biblioteca de disponibilidad de servicios comienza con una llamada para inicializar la biblioteca, que potencialmente carga cualquier código dinámico y vincula las llamadas asincrónicas implementadas por el proceso. Cuando el proceso ya no requiere el uso de las funciones de área, llama a la función de finalización de área, que disocia el proceso de la instancia de implementación del área de interfaz y recupera los recursos asociados.
AIS emplea tanto el modelo de programación sincrónico como el asincrónico. Las API sincrónicas se utilizan generalmente para interfaces de mantenimiento de bibliotecas y asociaciones. Muchos servicios de AIS proporcionan la capacidad de realizar un seguimiento de los cambios en las entidades que implementan. El seguimiento de la API normalmente consta de tres funciones: el inicio y la detención del seguimiento de una entidad invocados por el cliente; y la devolución de llamada invocada por el servicio para notificar al cliente sobre los cambios (pendientes) de una entidad rastreada.
Para lograr compatibilidad con versiones anteriores al evolucionar la especificación AIS, se siguen una serie de reglas:
A modo de ejemplo, considere una versión principal Vx de un servicio dado que incluye una función f() y suponga que f() tuvo que modificarse en una versión principal Vy más nueva (Vy > Vx), lo que llevó a la introducción de la variante f_y() que ahora reemplaza a f() en Vy.
Considerando una implementación de AIS que soporta ambas versiones Vx y Vy, un proceso puede inicializar la biblioteca especificando Vx o Vy:
Tenga en cuenta, sin embargo, que un proceso puede inicializar la biblioteca varias veces, cada vez con la versión adecuada a la funcionalidad que pretende obtener.
El documento de especificación de un servicio AIS para Vy solo incluye la última variante de una definición de función o tipo compatible con Vy.
Las versiones de las especificaciones se versionan como: <código de versión>.<versión principal>.<versión secundaria>
El código de la versión se escribe con mayúscula. La compatibilidad con versiones anteriores se mantiene solo entre versiones del mismo código de versión. La versión principal y la versión secundaria son números incrementales. Las versiones con un cambio de número principal pueden introducir nuevas funciones y cambiar la API de forma compatible con versiones anteriores, como se describió anteriormente. Las versiones con un cambio de número menor no cambian la API. Proporcionan correcciones de errores, cambios editoriales y aclaraciones a su predecesora.
El Registro de Implementación del Foro SA es un proceso que permite registrar y poner a disposición del público las implementaciones de las especificaciones del Foro SA. No es necesario ser miembro para registrar las implementaciones. Las implementaciones que se hayan registrado correctamente pueden denominarse "Registradas en el Foro de Disponibilidad de Servicios".