Especificación de la interfaz de la aplicación

El servicio de registro está diseñado para el registro de eventos , es decir, para recopilar información sobre el sistema basada en funciones (en contraposición a información específica de la implementación) y que se aplica a administradores de sistemas o herramientas automatizadas.

El Servicio de Registro permite a las aplicaciones expresar y escribir registros a través de flujos de registro que se dirigen a destinos de salida específicos, como un archivo con nombre. Una vez en el destino de salida, el 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 gestiona en función de la configuración actual del flujo de registro de destino. Dado que el formato de salida es público, herramientas de terceros pueden leer estos archivos de registro.

Se especifican cuatro tipos de flujos de registro: alarma (registros basados ​​en ITU X.733 e ITU X.736), notificación (registros basados ​​en ITU X.730 e ITU X.731), sistema y aplicación . El tipo de aplicación se utiliza para definir flujos de registro específicos de la aplicación. Existe un único flujo de registro predefinido para cada tipo (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.

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 complementarias.

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 del 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 miscelánea. Las notificaciones son generadas/publicadas por los productores mediante la API de 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 de consumidor de notificaciones. Ambos tipos de consumidores de notificaciones pueden definir filtros que especifican las características de las notificaciones que les interesa recibir o leer.

Las notificaciones pueden ser generadas tanto por los servicios AIS como por las aplicaciones. Los servicios AIS que generan notificaciones tienen una sección en la especificación que describe dichas notificaciones.

El servicio de seguridad proporciona mecanismos que AIS Services puede utilizar para autenticar los procesos de los clientes de AIS Services (y potencialmente de otros) dentro del clúster y autorizarlos a realizar actividades específicas. Estos mecanismos permiten preservar la integridad de la infraestructura de alta disponibilidad y de las aplicaciones de SA Forum, incluidos sus datos, protegiéndolas contra el acceso no autorizado.

La aplicación de la seguridad se delega a las propias implementaciones del Servicio AIS: los Servicios AIS con seguridad habilitada solicitan autorización a la implementación SEC en nombre de sus procesos cliente al iniciar diferentes actividades. SEC responde a estas solicitudes de autorización con una indicación de concesión o denegación, y es responsabilidad del Servicio AIS permitir o denegar la operación según corresponda. SEC proporciona estas indicaciones basándose en el conjunto de políticas de seguridad configuradas a través de IMM. Asimismo, informa a sus suscriptores sobre los cambios en las políticas mediante las funciones de devolución de llamada correspondientes.

El Marco de Gestión de Disponibilidad (AMF) es el facilitador de la disponibilidad de servicios en sistemas compatibles con SA Forum. Coordina la carga de trabajo de las distintas entidades bajo su control según su nivel de preparación para prestar servicios. Para ello, la aplicación debe describirse según 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 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 (AMF) que encapsulan una funcionalidad específica de la aplicación. La carga de trabajo generada al aprovisionar un servicio que AMF puede asignar a un componente se representa como una instancia de servicio de componente (CSI) . Cuando el componente presta activamente el servicio, se le asigna el estado activo en nombre de la CSI que lo representa.

El principio fundamental del diseño tolerante a fallos consiste en proporcionar los servicios mediante un conjunto de entidades redundantes ; por lo tanto, los componentes deben poder actuar como respaldo en nombre del CSI. Los componentes de respaldo se mantienen en un estado que les permite asumir la prestación del servicio en caso de que falle el componente activo. La función de AMF es asignar cargas de trabajo activas o de respaldo a los componentes de una aplicación en función del estado de los componentes 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 la notificación de errores y la monitorización del estado. También permiten el 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 priorizar los recursos y ofrece diversos modelos de redundancia, desde el sencillo modelo 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 para la misma instancia de servicio de componente, o el modelo N-way-active, 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 estos elementos conforman una aplicación. Mediante IMM, se dispone de un conjunto de operaciones administrativas sobre estas entidades lógicas.

Para la gestión del software, las entidades que ejecutan el mismo software se agrupan por tipos, lo que permite un único punto de entrada para la configuración de estas entidades.

Un sistema compatible con SA Forum se caracteriza por su configuración de despliegue, que comprende el software desplegado en el sistema junto con todas las entidades de software configuradas. La configuración de despliegue constituye una parte esencial del modelo de información gestionado 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 y desplegado en el clúster. Sin embargo, el objetivo principal del SMF es permitir la evolución de un sistema en producción mediante la orquestación de la migración de una configuración de despliegue a otra. En términos del SMF, este proceso de migración se denomina campaña de actualización .

El marco de gestión de software (SMF) define un esquema XML que se utiliza para especificar una campaña de actualización. Una implementación de SMF migra el sistema de una configuración de despliegue a una nueva configuración deseada basándose en 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

• mantiene el modelo de estado de campaña,
• monitores para posibles situaciones de error causadas por la migración y
• Implementa los procedimientos de recuperación de errores según sea necesario.

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 cliente registren su interés en recibir notificaciones cuando se inicie una campaña de actualización relevante en el clúster y a medida que esta avanza por hitos importantes. Esto permite coordinar las acciones específicas de la aplicación con la actualización. Esto puede abarcar 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 aplicación, como actualizar el esquema de la base de datos o implementar nuevos protocolos.

Para los proveedores de software que ofrecen aplicaciones para su implementación en un clúster de SA Forum, el Software Management Framework 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 las configuraciones de implementación adecuadas.

El servicio de puntos de control permite a los procesos registrar datos de puntos de control de forma incremental, lo que puede utilizarse para proteger una aplicación contra fallos. Cuando un proceso se recupera de un fallo (mediante un reinicio o un procedimiento de conmutación por error ), el servicio de puntos de control puede utilizarse para recuperar los datos previamente guardados 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 del punto de control, que normalmente se almacena en la memoria principal en lugar de en el disco por motivos de rendimiento. Un punto de control puede tener varias réplicas almacenadas en diferentes nodos del clúster para protegerlo contra fallos de nodo. El proceso que crea el punto de control puede elegir entre políticas de actualización de réplicas síncronas o asíncronas. En el caso de la replicación asíncrona, 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 de publicación/suscripción basado en el concepto de canales de eventos: uno o más publicadores se comunican de forma asíncrona con uno o más suscriptores anónimos mediante eventos a través de un canal de eventos. Los canales de eventos son entidades con nombre a nivel de clúster que garantizan la entrega de eventos con el mejor esfuerzo posible. Los publicadores también pueden ser suscriptores del mismo canal de eventos.

Los eventos constan de una cabecera estándar y cero o más bytes de datos de evento publicados. La API del Servicio de Eventos no impone un formato específico para los datos de evento publicados.

Cuando un proceso se suscribe a un canal de eventos para recibir eventos publicados, especifica los filtros que se aplicarán a dichos eventos. Los eventos solo se entregan al proceso si cumplen con los filtros especificados.

El servicio de bloqueo es un servicio de bloqueo distribuido , diseñado para su uso en un clúster donde los procesos en diferentes nodos pueden competir entre sí por el acceso a un recurso compartido. Para ello, el servicio de bloqueo proporciona entidades llamadas recursos de bloqueo, que a su vez, los procesos de la aplicación utilizan para coordinar el acceso a dichos recursos compartidos.

El Servicio de Bloqueo proporciona un modelo de bloqueo sencillo que admite un modo de bloqueo para acceso exclusivo y otro para acceso compartido. Los bloqueos que proporciona el Servicio de Bloqueo no son recursivos. Por lo tanto, reclamar un bloqueo no implica reclamar otro; cada bloqueo debe reclamarse individualmente.

El Servicio de Mensajería 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 número de procesos puede enviar mensajes a una cola , pero solo uno a la vez puede abrirla para recibirlos. Por lo tanto, la única cola de mensajes 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, es posible que el proceso que originalmente recibía estos mensajes haya sido reemplazado por otro proceso durante una conmutación por error o un cambio de protocolo.

Las colas de mensajes se pueden agrupar para formar grupos de colas de mensajes. Estos grupos permiten la comunicación multipunto a multipunto. Se identifican mediante nombres lógicos, de modo que el proceso emisor desconoce el número de colas de mensajes y su ubicación dentro del clúster con el que se comunica. Los grupos de colas de mensajes se utilizan para distribuir mensajes entre las colas que pertenecen a cada grupo. MSG define tres políticas de distribución unicast : distribución de carga equitativa, distribución de carga equitativa local y mejor cola local, además de la política de difusión ( multidifusión ).

Previa solicitud, el Servicio de Mensajería proporciona diferentes garantías de entrega (por ejemplo, acuse de recibo, persistencia de mensajes, etc.) en colas de mensajes y en grupos de colas de mensajes unicast.

El Servicio de Nombres proporciona un mecanismo mediante el cual se asocian nombres fáciles de usar a los objetos, de modo que estos objetos puedan buscarse 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 formato ni una convención específicos para los nombres ( se asume la codificación UTF-8 ) ni para 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 formato y la semántica de las vinculaciones de objetos que pretenden almacenar y recuperar del servicio.

El servicio de temporizador proporciona un mecanismo mediante el cual los procesos cliente pueden configurar temporizadores y recibir notificaciones cuando estos expiran. Un temporizador es un objeto lógico que se crea dinámicamente y representa su tiempo de expiración como un valor absoluto o una duración a partir del tiempo actual.

El servicio de temporizadores ofrece dos tipos: temporizadores de evento único y temporizadores periódicos. Los temporizadores de evento único caducan una sola vez y se eliminan tras recibir una notificación. Los temporizadores periódicos caducan cada vez que se alcanza una duración específica, y el proceso recibe una notificación sobre la caducidad. Los temporizadores periódicos deben eliminarse explícitamente mediante una función de eliminación de temporizadores.

Todos los servicios AIS comparten el mismo modelo de programació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., en toda la especificación.

La interfaz de aplicación del Foro SA se establece entre un proceso y una biblioteca que implementa dicha interfaz. Está diseñada para su uso tanto en procesos de aplicación multihilo como monohilo. 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 el sistema proporcione 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 (Marco de Gestión de Disponibilidad, Servicio de Membresía de Clúster, Servicio de Punto de Control, etc.). Cada área tiene un servidor de área lógico independiente, aunque el implementador puede 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 área pueden estar implementadas en una o varias bibliotecas físicas; sin embargo, se requiere un proceso para inicializar, registrar y obtener un objeto de selección del sistema operativo por separado para cada biblioteca de implementación de área. Por lo tanto, desde el punto de vista de la programación, es útil considerarlas como bibliotecas independientes.

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 llamada cuando ocurren 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 asíncronas implementadas por el proceso. Cuando el proceso ya no requiere el uso de las funciones del área, llama a la función de finalización del área, que disocia el proceso de la instancia de implementación del área de interfaz y recupera los recursos asociados.

AIS emplea modelos de programación tanto síncronos como asíncronos. Las API síncronas se utilizan generalmente para las interfaces de administración de bibliotecas y asociaciones. Muchos servicios de AIS permiten realizar un seguimiento de los cambios en las entidades que implementan. El seguimiento de la API suele constar de tres funciones: iniciar y detener el seguimiento de una entidad, invocadas 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.