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:
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:
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]
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:
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]
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 .