OpenSAF

OpenSAF (comúnmente llamado SAF , Service Availability Framework ^[1] ) es un sistema de orquestación de servicios de código abierto para automatizar la implementación, el escalamiento y la gestión de aplicaciones informáticas. OpenSAF es coherente con los estándares de Service Availability Forum (SAF) y SCOPE Alliance y los amplía . ^[2]

Fue diseñado originalmente por Motorola ECC y es mantenido por el Proyecto OpenSAF. ^[3] OpenSAF es la implementación más completa de las especificaciones SAF AIS , proporcionando una plataforma para automatizar la implementación, escalamiento y operaciones de servicios de aplicaciones a través de clústeres de hosts. ^[4] Funciona a través de una gama de herramientas de virtualización y ejecuta servicios en un clúster, a menudo integrándose con JVM , Vagrant y/o entornos de ejecución de Docker . OpenSAF originalmente interactuaba con interfaces de programación de aplicaciones (API) estándar de C, pero ha agregado enlaces de Java y Python. ^[2]

OpenSAF se centra en la disponibilidad de servicios más allá de los requisitos de alta disponibilidad (HA). Si bien se han publicado pocas investigaciones formales para mejorar las técnicas de alta disponibilidad y tolerancia a fallas para contenedores y la nube, ^[5] los grupos de investigación están explorando activamente estos desafíos con OpenSAF.

OpenSAF fue fundada por un consorcio industrial, que incluía a Ericsson, HP y Nokia Siemens Networks, y anunciada por primera vez por Motorola ECC, adquirida por Emerson Network Power , el 28 de febrero de 2007. ^[6] La Fundación OpenSAF se lanzó oficialmente el 22 de enero de 2008. La membresía evolucionó para incluir a Emerson Network Power, SUN Microsystems, ENEA, Wind River, Huawei, IP Infusion, Tail-f, Aricent, GoAhead Software y Rancore Technologies. ^{[2] [7]} GoAhead Software se unió a OpenSAF en 2010 antes de ser adquirida por Oracle. ^[8] El desarrollo y diseño de OpenSAF están fuertemente influenciados por los requisitos de sistemas críticos para la misión , incluidos Carrier Grade Linux, SAF , ATCA y Hardware Platform Interface . OpenSAF fue un hito en la aceleración de la adopción de Linux en telecomunicaciones y sistemas integrados. ^[9]

El objetivo de la Fundación era acelerar la adopción de OpenSAF en productos comerciales. La comunidad OpenSAF celebró conferencias entre 2008 y 2010; la primera conferencia fue organizada por Nokia Siemens Networks en Múnich (Alemania), la segunda por Huawei en Shenzhen (China) y la tercera por HP en Palo Alto (EE. UU.). En febrero de 2010, se anunció la primera implementación comercial de OpenSAF en redes de operadores. ^[10] Grupos académicos e industriales han publicado libros de forma independiente que describen soluciones basadas en OpenSAF. ^{[2] [11]} Un creciente cuerpo de investigación en disponibilidad de servicios está acelerando el desarrollo de características de OpenSAF que respaldan implementaciones de microservicios y nube de misión crítica, y la orquestación de servicios. ^{[12] [13]}

OpenSAF 1.0 se lanzó el 22 de enero de 2008. Comprendía el código base de NetPlane Core Service (NCS) aportado por Motorola ECC. ^[14] Junto con el lanzamiento de OpenSAF 1.0, se inició la base de OpenSAF. ^[6] OpenSAF 2.0, lanzado el 12 de agosto de 2008, fue la primera versión desarrollada por la comunidad OpenSAF. Esta versión incluía el servicio de registro y soporte de 64 bits. ^[14] OpenSAF 3.0, lanzado el 17 de junio de 2009, incluía administración de la plataforma, mejoras de usabilidad y soporte de API de Java. ^[15]

OpenSAF 4.0 fue un lanzamiento histórico en julio de 2010. ^[2] Apodado el "lanzamiento de la arquitectura", introdujo cambios significativos, incluyendo el cierre de brechas funcionales, el establecimiento de la arquitectura interna, la habilitación de actualizaciones en servicio, la aclaración de las API y la mejora de la modularidad. ^[16] OpenSAF recibió un interés significativo de la industria y los académicos, y celebró dos conferencias comunitarias en 2011, una organizada por la Universidad MIT en Boston, MA, y una segunda organizada por Ericsson en Estocolmo.

OpenSAF define un conjunto de bloques de construcción que, en conjunto, proporcionan un mecanismo para gestionar la disponibilidad del servicio (SA) de las aplicaciones en función de modelos de capacidad de recursos. ^[20] SA y alta disponibilidad (HA) son la probabilidad de que un servicio esté disponible en un punto aleatorio en el tiempo; los sistemas de misión crítica requieren al menos una disponibilidad del 99,999 % (cinco nueves). HA y SA son esencialmente lo mismo, pero SA va más allá (es decir, actualizaciones en servicio de hardware y software). ^[21] OpenSAF está diseñado para sistemas acoplados de forma flexible con interconexiones rápidas entre nodos (es decir, utilizando TIPC/TCP), ^[22] y extensibles para satisfacer diferentes cargas de trabajo; los componentes se comunican entre sí utilizando cualquier protocolo. Esta extensibilidad se proporciona en gran parte mediante la API IMM, utilizada por los componentes internos y los servicios centrales. La plataforma puede ejercer control sobre los recursos de cómputo y almacenamiento definiéndolos como objetos, para ser administrados como instancias (servicio de componentes) y/o restricciones de nodo. ^{[2] [20] [23]}

El software OpenSAF es de naturaleza distribuida, siguiendo la arquitectura principal/réplica . En un clúster "OpenSAF", hay dos tipos de nodos que se pueden dividir en aquellos que administran un nodo individual y un plano de control. Un controlador de sistema se ejecuta en modo "activo", otro en modo "en espera" y los controladores de sistema restantes (si los hay) son repuestos listos para asumir el rol de Activo o En espera en caso de una falla. Los nodos pueden ejecutarse sin cabeza, sin plano de control, lo que agrega resiliencia a la nube. ^{[16] [24]}

El modelo de sistema OpenSAF es la API habilitadora clave , que permite a OpenSAF procesar y validar solicitudes, y actualizar el estado de los objetos en el modelo AMF, lo que permite a los directores programar cargas de trabajo y grupos de servicios en los nodos de trabajo/carga útil. El comportamiento de AMF se cambia a través de un objeto de configuración. ^[24] Los servicios pueden usar modelos de redundancia "sin redundancia", 2N, N+M, N-way y N-way Active. ^[20] OpenSAF carece de cadenas de herramientas de modelado obvias para simplificar el diseño y la generación de modelos de configuración AMF. La investigación en curso para abordar esta brecha, ^{[25] [26] necesita brindar herramientas de ecosistema para respaldar mejor el modelado y la automatización de los casos de uso} de Cloud Native Computing Foundation y de nivel de operador .

El controlador del sistema OpenSAF (SC) es la unidad de control principal del clúster, que gestiona su carga de trabajo y dirige la comunicación en todo el sistema. El plano de control OpenSAF consta de varios componentes, cada uno de ellos con su propio proceso, que pueden ejecutarse tanto en un solo nodo SC como en varios nodos SC, lo que permite la alta disponibilidad de clústeres y la disponibilidad del servicio . ^{[2] [24]} Los distintos componentes del plano de control OpenSAF son los siguientes:

• Information Model Manager ( IMM ) es un almacén de datos persistente que almacena de forma fiable los datos de configuración del clúster, lo que representa el estado general del clúster en un momento dado. Proporciona un medio para definir y gestionar la configuración y el estado de la aplicación y el middleware en forma de objetos gestionados y sus atributos correspondientes. ^[23] IMM se implementa como una base de datos en memoria que replica sus datos en todos los nodos. IMM puede utilizar SQLite como backend persistente. Al igual que Apache ZooKeeper , IMM garantiza la coherencia a nivel de transacción de los datos de configuración sobre la disponibilidad/rendimiento (véase el teorema CAP ). ^{[2] [23] [27]} El servicio IMM sigue el marco de tres niveles "Director de servicios" de OpenSAF, que comprende IMM Director (IMMD), IMM Node Director (IMMND) y la biblioteca de agentes IMM (IMMA). IMMD se implementa como un demonio en los controladores utilizando un modelo de redundancia 2N, la instancia del controlador activo es la "réplica principal", la instancia del controlador en espera se mantiene actualizada mediante un servicio de puntos de control basado en mensajes. IMMD realiza un seguimiento de la membresía del clúster (usando MDS), proporciona control de acceso al almacén de datos y una interfaz administrativa para todos los servicios de OpenSAF. ^{[28] [2]}
• Availability Management Framework ( AMF ) ofrece un marco de gestión de carga de trabajo y alta disponibilidad con un soporte sólido (en conjunto con otros servicios AIS) para todo el ciclo de vida de la gestión de fallos (detección, aislamiento, recuperación, reparación y notificación). AMF sigue el "Director de servicios" de OpenSAF de tres niveles, que comprende el director (AmfD), el director de nodo (AmfND) y los agentes (AmfA), y un organismo de control interno para la protección de AmfND. El servicio AmfD activo es responsable de realizar la configuración del servicio, persistente en IMM, en todo el ámbito del sistema/clúster. Los directores de nodo realizan la misma función para cualquier componente dentro de su ámbito. ^[2] Garantiza que los modelos de estado estén de acuerdo al actuar como el principal puente de información y API entre todos los componentes. AMF supervisa el estado de IMM, aplicando cambios de configuración o simplemente restaurando cualquier divergencia a la "configuración deseada" utilizando políticas de escalada de gestión de fallos para programar la creación de la implementación deseada. ^[16]
• Los directores de AMF ( AmfD ) son programadores que deciden en qué nodos se ejecuta un grupo de servicios no programado (una instancia de servicio redundante). Esta decisión se basa en modelos de disponibilidad y capacidad actuales y "deseados", modelos de redundancia de servicio y restricciones como calidad de servicio, afinidad/antiafinidad, etc. Los directores de AMF hacen coincidir la "oferta" de recursos con la "demanda" de carga de trabajo, y su comportamiento se puede manipular a través de un objeto de sistema IMM. ^{[2] [16]}

El componente es una entidad lógica del modelo de sistema AMF y representa una vista normalizada de un recurso informático, como procesos, controladores o almacenamiento. Los componentes se agrupan en unidades de servicio (SU) lógicas, según las interdependencias de fallas, y se asocian con un nodo. La SU es una unidad instanciable de carga de trabajo controlada por un modelo de redundancia AMF, ya sea en estado activo, en espera o fallido. Las SU del mismo tipo se agrupan en grupos de servicio (SG) que exhiben características particulares de modelado de redundancia. Las SU dentro de un SG se asignan a instancias de servicio (SI) y se les asigna un estado de disponibilidad activo o en espera. Las SI son servicios lógicos redundantes escalables protegidos por AMF. ^{[2] [16]}

Un nodo es una instancia de cómputo (un blade, un hipervisor o una máquina virtual) donde se implementan instancias de servicio (carga de trabajo). El conjunto de nodos que pertenecen a la misma subred de comunicación (sin enrutamiento) compone el clúster lógico. Cada nodo del clúster debe ejecutar un entorno de ejecución para los servicios, así como los servicios OpenSAF que se enumeran a continuación:

• Director de nodo (AmfND): El AmfND es responsable del estado de ejecución de cada nodo, garantizando que todas las SU activas en ese nodo estén en buen estado. Se encarga de iniciar, detener y mantener la CSI y/o las SU organizadas en SG según lo indicado por el plano de control. El servicio AmfND aplica la configuración AMF deseada, que se conserva en IMM, en el nodo. Cuando se detecta una falla en el nodo, el director (AmfD) observa este cambio de estado y lanza una unidad de servicio en otro nodo en buen estado elegible. ^{[2] [16]}
• Componente no compatible con SA: OpenSAF puede proporcionar HA (pero no SA) para componentes instanciables que se originan en dominios de computación en la nube , contenerización , virtualización y JVM , al modelar los comandos del ciclo de vida del componente y del servicio (inicio/detención/verificación de estado) en el modelo AMF. ^[2]
• Contenedor incluido: un contenedor de AMF puede residir dentro de una SU. El contenedor incluido es el nivel más bajo de entorno de ejecución que se puede instanciar. El componente contenedor incluido SA-Aware actualmente apunta a una máquina virtual Java (JVM) según JSR139. ^{[29] [2]}

La unidad de programación básica en OpenSAF es una unidad de servicio (SU). Una SU es una agrupación de componentes. Una SU consta de uno o más componentes que se garantiza que estarán ubicados en el mismo nodo. Las SU no tienen direcciones IP asignadas de forma predeterminada, pero pueden contener algún componente que sí las tenga. Una SU se puede gestionar administrativamente mediante una dirección de objeto. AmfND supervisa el estado de las SU y, si no se encuentran en el estado deseado, las vuelve a implementar en el mismo nodo si es posible. AmfD puede iniciar la SU en otro nodo si así lo requiere el modelo de redundancia. ^[2] Una SU puede definir un volumen, como un directorio de disco local o un disco de red, y exponerlo a los componentes en la SU. [39] La SU se puede gestionar administrativamente a través de la CLI de AMF, o se puede delegar la gestión a AMF. Dichos volúmenes también son la base del almacenamiento persistente. ^{[2] [16]}

El propósito de un grupo de servicios es mantener un conjunto estable de SU de réplica en ejecución en un momento dado. Se puede utilizar para garantizar la disponibilidad de una cantidad específica de SU idénticas en función del modelo de redundancia configurado seleccionado: N-Way, N-way-Active, 2N, N+M o "Sin redundancia". El SG es un mecanismo de agrupación que permite a OpenSAF mantener la cantidad de instancias declaradas para un SG determinado. La definición de un SG identifica todas las SU asociadas y su estado (activo, en espera, fallido). ^{[2] [16]}

Una instancia de servicio (SI) de OpenSAF es un conjunto de SU que trabajan juntas, como un nivel de una aplicación de múltiples niveles. El conjunto de SU que protege un servicio está definido por el SG. Un SG de múltiples instancias (N-way-active, N-way, N+M) requiere una dirección IP estable, un nombre DNS y un balanceador de carga para distribuir el tráfico de esa dirección IP entre las SU activas en ese SG (incluso si las fallas hacen que las SU se muevan de una máquina a otra). De manera predeterminada, un servicio se expone dentro de un clúster (por ejemplo, SU[TypeA] se agrupa en un SG, con solicitudes de SU[typeB] balanceadas entre ellas), pero el servicio también se puede exponer fuera de un clúster (por ejemplo, para que los clientes lleguen a las SU de front-end). ^{[2] [16]}

Los sistemas de archivos disponibles para las SU de OpenSAF son, de manera predeterminada, un almacenamiento potencialmente efímero. Si el nodo se destruye o se vuelve a crear, los datos se pierden en ese nodo. Una solución es un almacenamiento compartido del Sistema de archivos de red (NFS), accesible para todos los nodos de carga útil. ^{[30] También} son posibles otras soluciones técnicas: lo importante es que los volúmenes (recurso compartido de archivos, punto de montaje) se pueden modelar en AMF. Los volúmenes de alta disponibilidad proporcionan un almacenamiento persistente que existe durante la vida útil de la propia SU. Este almacenamiento también se puede utilizar como un espacio de disco compartido para la SU dentro del SG. Los volúmenes montados en puntos de montaje específicos en el nodo son propiedad de un SG específico, por lo que esa instancia no se puede compartir con otro SG que utilice el mismo punto de montaje del sistema de archivos.

La arquitectura OpenSAF está distribuida y se ejecuta en un clúster de nodos lógicos. Todos los servicios OpenSAF tienen una arquitectura de 3 o 2 niveles. En la arquitectura de 3 niveles, los servicios OpenSAF se dividen en un Director de servicio, un Director de nodo de servicio y un Agente. El Director es parte de un servicio OpenSAF con inteligencia de servicio central. Normalmente es un proceso en el nodo controlador. Los Directores de nodo coordinan las actividades de servicio del nodo, como la mensajería, con su Director central y sus Agentes locales. El Agente proporciona capacidades de servicio disponibles para los clientes a través de una biblioteca enlazable (compartida) que expone API de servicio bien definidas a los procesos de aplicación. Los Agentes normalmente se comunican con sus Directores de nodo de servicio o Servidores. Los servicios OpenSAF se clasifican modularmente de la siguiente manera ^[22]

• Servicios básicos: AMF, CLM, IMM, LOG, NTF
• Servicios opcionales: EVT, CKPT, LCK, MSG, PLM, SMF

Los servicios opcionales se pueden habilitar o deshabilitar durante la compilación o el empaquetado de OpenSAF. OpenSAF se puede configurar para utilizar TCP o TIPC como transporte subyacente. Se pueden agregar o eliminar nodos dinámicamente del clúster OpenSAF en tiempo de ejecución. El clúster OpenSAF se escala hasta varios cientos de nodos. OpenSAF admite los siguientes enlaces de lenguaje para las API de interfaz AIS:

• C/C++
• Enlaces de Java (para servicios AMF y CLM)
• Enlaces de Python
• OpenSAF proporciona herramientas y utilidades de línea de comandos para la gestión del clúster y las aplicaciones de OpenSAF.

La arquitectura modular permite la incorporación de nuevos servicios, así como la adaptación de los servicios existentes. Todos los servicios de OpenSAF están diseñados para soportar actualizaciones durante el servicio.

Los siguientes servicios AIS de SA Forum están implementados por OpenSAF 5.0. ^[23]

• Marco de gestión de disponibilidad (AMF): descrito anteriormente.
• Servicio de pertenencia al clúster (CLM): determina si un nodo está en condiciones adecuadas para formar parte del clúster. Proporciona un mecanismo para realizar un seguimiento de los nodos del clúster mediante la interacción con PLM para realizar un seguimiento del estado del sistema operativo y el hardware subyacentes.
• Servicio de punto de control (CKPT): para guardar estados de aplicaciones y actualizaciones incrementales que se pueden usar para restaurar el servicio durante una conmutación por error o un cambio.
• Servicio de eventos (EVT): proporciona un modelo de mensajería de publicación-suscripción que se puede utilizar para mantener las aplicaciones y las entidades de administración sincronizadas sobre los eventos que suceden en el clúster.
• Servicio de Gestión de Modelos de Información (IMM): descrito anteriormente.
• Servicio de bloqueo (LCK): admite un modelo de servicio de bloqueo distribuido con soporte para bloqueos compartidos y bloqueos exclusivos.
• Servicio de registro (LOG): medio para registrar (en archivos de registro) los cambios funcionales que ocurren en el clúster, con soporte para el registro en diversos formatos de registro. No se utiliza para depuración ni seguimiento de errores. Admite el registro de alarmas y notificaciones que ocurren en el clúster.
• Servicio de mensajería (MSG): admite un mecanismo de mensajería a nivel de clúster con múltiples remitentes, un único receptor y mecanismos de grupo de mensajes.
• Servicio de notificación (NTF): proporciona un modelo de productor/suscriptor para las notificaciones de gestión del sistema que permiten la gestión de fallos. Se utiliza para notificaciones de alarmas y fallos y admite el registro del historial para el análisis de fallos. Admite formatos de notificación de las recomendaciones ITU-T X.730, X.731, X.733 y X.736.
• Servicio de gestión de la plataforma (PLM): proporciona un mecanismo para configurar una vista lógica del hardware subyacente (FRU) y del sistema operativo. Proporciona un mecanismo para realizar un seguimiento del estado del sistema operativo, el hardware (FRU) y para realizar operaciones administrativas en coordinación con los servicios y aplicaciones de OpenSAF.
• Marco de gestión de software (SMF): soporte para una actualización automatizada en servicio de aplicaciones, middleware y sistema operativo en todo el clúster.

Los proveedores de equipos de red serán los principales usuarios de los productos basados ​​en la base de código OpenSAF, integrándolos en sus productos para proveedores de servicios de red, operadores y proveedores de servicios. Muchos proveedores de equipos de red han demostrado su apoyo a OpenSAF uniéndose a la Fundación y/o contribuyendo al proyecto de código abierto. Los miembros actuales de la Fundación incluyen: Ericsson , HP y Oracle . Varios proveedores de tecnología informática y de comunicaciones también han indicado su apoyo a la iniciativa OpenSAF, incluidos OpenClovis SAFplus, Emerson Network Power Embedded Computing, Continuous Computing, Wind River, IP Infusion, Tail-f, Aricent, Rancore Technologies, GoAhead Software y MontaVista Software.

OpenSAF se utiliza comúnmente como una forma de lograr una disponibilidad de servicio de nivel de operador (cinco nueves). OpenSAF es funcionalmente completo, pero carece del ecosistema de herramientas de modelado disponibles para otras soluciones de código abierto como Kubernetes y Docker Swarm .

• Foro SA
• Alianza SCOPE
• OpenHPI
• Lista de software de gestión de clústeres
• Fundación para la computación nativa en la nube

• Sitio web oficial
• OpenSAF en SourceForge
• Foro SA en Wayback Machine (archivado el 6 de octubre de 2008)