Hispanopedia Wiki
Articulo de referencia

OpenSAF

OpenSAF (conocido comúnmente como SAF , Service Availability Framework [ 1 ] ) es un sistema de orquestación de servicios de código abierto para automatizar el despliegue, el es...

Hispanopedia WikiContenido en espanolLectura gratuita

OpenSAF (conocido comúnmente como SAF , Service Availability Framework [ 1 ] ) es un sistema de orquestación de servicios de código abierto para automatizar el despliegue, el escalado y la gestión de aplicaciones informáticas. OpenSAF es compatible con los estándares del Service Availability Forum (SAF) y de la SCOPE Alliance , y los amplía . [ 2 ] Es software libre y de código abierto , con licencia GNU Lesser General Public License (LGPL), versión 2.1.

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 el despliegue, el escalado y las operaciones de servicios de aplicaciones en clústeres de hosts. [ 4 ] Funciona con una variedad de herramientas de virtualización y ejecuta servicios en un clúster, integrándose a menudo con la máquina virtual Java (JVM), Vagrant y/o los sistemas de tiempo de ejecución de Docker . OpenSAF originalmente interactuaba con las interfaces de programación de aplicaciones ( API ) estándar de C , pero ha añadido enlaces para los lenguajes Java y Python . [ 2 ]

OpenSAF se centra en la disponibilidad del servicio 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 fallos para contenedores y la nube, [ 5 ] grupos de investigación están explorando activamente estos desafíos con OpenSAF.

Historia

Disponibilidad del servicio, principios y práctica, libro de texto

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 de misión crítica , 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 embebidos. [ 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 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ó el primer despliegue comercial de OpenSAF en redes de operadores. [ 10 ] Grupos académicos e industriales han publicado de forma independiente libros 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 soportan despliegues de nube y microservicios de misión crítica, y orquestación de servicios. [ 12 ] [ 13 ]

OpenSAF 1.0 se publicó el 22 de enero de 2008. Incluía el código fuente de NetPlane Core Service (NCS) aportado por Motorola ECC. [ 14 ] Junto con el lanzamiento de OpenSAF 1.0, se creó la fundación OpenSAF. [ 6 ] OpenSAF 2.0, publicado 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 compatibilidad con 64 bits. [ 14 ] OpenSAF 3.0, publicado el 17 de junio de 2009, incluía gestión de plataforma, mejoras de usabilidad y compatibilidad con la API de Java. [ 15 ]

OpenSAF 4.0 fue un lanzamiento clave en julio de 2010. [ 2 ] Conocido como el "lanzamiento de arquitectura", introdujo cambios significativos, incluyendo la solución de problemas funcionales, la consolidación de la arquitectura interna, la habilitación de actualizaciones en servicio, la clarificación de las API y la mejora de la modularidad. [ 16 ] Al recibir un gran interés por parte de la industria y el ámbito académico, OpenSAF celebró dos conferencias comunitarias en 2011, una organizada por la Universidad MIT en Boston, MA, y otra organizada por Ericsson en Estocolmo.

Conceptos

Arquitectura OpenSAF v4

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 basándose en modelos de capacidad de recursos. [ 20 ] La SA y la alta disponibilidad (HA) representan la probabilidad de que un servicio esté disponible en un momento aleatorio; los sistemas de misión crítica requieren una disponibilidad de al menos el 99,999 % (cinco nueves). La HA y la SA son esencialmente lo mismo, pero la SA va más allá (es decir, actualizaciones de hardware y software en servicio). [ 21 ] OpenSAF está diseñado para sistemas débilmente acoplados con interconexiones rápidas entre nodos (es decir, mediante TIPC/TCP), [ 22 ] y es extensible para adaptarse a diferentes cargas de trabajo; los componentes se comunican entre sí mediante cualquier protocolo. Esta extensibilidad la proporciona en gran medida la API IMM, utilizada por los componentes internos y los servicios centrales. La plataforma puede ejercer control sobre los recursos de computación y almacenamiento definiéndolos como objetos, que se gestionan como instancias (de servicio de componentes) y/o restricciones de nodos. [ 2 ] [ 20 ] [ 23 ]

El software OpenSAF es de naturaleza distribuida, siguiendo la arquitectura primario/réplica . En un clúster `OpenSAF`, existen dos tipos de nodos que se pueden dividir en aquellos que administran un nodo individual y el plano de control. Un controlador del sistema se ejecuta en modo "activo", otro en modo "en espera", y los controladores del sistema restantes (si los hay) son de reserva, listos para asumir el rol de activo o en espera en caso de una falla. Los nodos pueden ejecutarse sin interfaz gráfica, sin plano de control, lo que añade resiliencia a la nube. [ 16 ] [ 24 ]

Modelo del sistema

Los diseñadores de sistemas necesitan mejores herramientas de modelado.

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 proporcionar herramientas de ecosistema, para respaldar mejor el modelado y la automatización de casos de uso de grado de operador y Cloud Native Computing Foundation .

Plano de control

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 de OpenSAF consta de varios componentes, cada uno un proceso independiente, que pueden ejecutarse en un nodo SC o en varios nodos SC, lo que permite la alta disponibilidad de los clústeres y la disponibilidad del servicio . [ 2 ] [ 24 ] Los distintos componentes del plano de control de OpenSAF son los siguientes:

  • El Administrador del Modelo de Información (IMM) es un almacén de datos persistente que almacena de forma fiable los datos de configuración del clúster, representando el estado general del clúster en cualquier momento dado. Proporciona un medio para definir y gestionar la configuración del middleware y la aplicación, así como la información de estado 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 consistencia 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 trabajo de tres niveles "Director de Servicio" de OpenSAF, que comprende el Director de IMM (IMMD), el Director de Nodo de IMM (IMMND) y la biblioteca del Agente de IMM (IMMA). IMMD se implementa como un demonio en los controladores que utilizan un modelo de redundancia 2N; la instancia del controlador activo es la "réplica principal" y 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 pertenencia al clúster (mediante MDS), proporciona control de acceso al almacén de datos e interfaz administrativa para todos los servicios de OpenSAF. [ 28 ] [ 2 ]
  • El Availability Management Framework (AMF) proporciona un marco de gestión de alta disponibilidad y carga de trabajo con soporte robusto (en conjunto con otros servicios AIS) para el ciclo de vida completo de la gestión de fallos (detección, aislamiento, recuperación, reparación y notificación). AMF sigue el modelo de tres niveles "Service Director" de OpenSAF, que comprende el director (AmfD), el director de nodo (AmfND) y los agentes (AmfA), y un mecanismo de vigilancia interno para la protección de AmfND. El servicio activo AmfD es responsable de implementar la configuración del servicio, persistida 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 ] Asegura que los modelos de estado coincidan actuando 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" mediante políticas de escalamiento de gestión de fallos para programar la creación del despliegue deseado. [ 16 ]
  • Los directores AMF (AmfD) son planificadores que deciden en qué nodos se ejecuta un grupo de servicios no planificado (una instancia de servicio redundante). Esta decisión se basa en los modelos de disponibilidad y capacidad actuales frente a los deseados , los modelos de redundancia de servicio y restricciones como la calidad del servicio, la afinidad/antiafinidad, etc. Los directores AMF ajustan el suministro de recursos a la "demanda" de carga de trabajo, y su comportamiento puede manipularse mediante un objeto del sistema IMM. [ 2 ] [ 16 ]

Componente

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 fallos, y se asocian a un Nodo. ​​La SU es una unidad de carga de trabajo instanciable controlada por un modelo de redundancia AMF, ya sea activa, en espera o en estado de fallo. Las SU del mismo tipo se agrupan en Grupos de Servicio (SG), que presentan características particulares de modelado de redundancia. A las SU dentro de un SG se les asigna una Instancia de Servicio (SI) y se les da un estado de Disponibilidad de activo o en espera. Las SI son servicios lógicos redundantes escalables protegidos por AMF. [ 2 ] [ 16 ]

Nodo

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

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

Unidad de servicio

Conceptos de OpenSAF

La unidad de planificació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 estén ubicados en el mismo nodo. Las SU no tienen direcciones IP asignadas por defecto, pero pueden contener algún componente que sí las tenga. Una SU se puede administrar administrativamente mediante una dirección de objeto. AmfND supervisa el estado de las SU y, si no se encuentra en el estado deseado, las vuelve a implementar en el mismo nodo si es posible. AmfD puede iniciar la SU en otro nodo si 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 de la SU.[39] Las SU se pueden administrar administrativamente a través de la CLI de AMF, o la administración se puede delegar a AMF. Dichos volúmenes también son la base del almacenamiento persistente. [ 2 ] [ 16 ]

Grupo de servicios

El propósito de un Grupo de Servicio (GS) es mantener un conjunto estable de réplicas de SU en funcionamiento en todo momento. Se puede utilizar para garantizar la disponibilidad de un número específico de SU idénticas según el modelo de redundancia configurado: N-Way, N-way-Active, 2N, N+M o Sin redundancia . El GS es un mecanismo de agrupación que permite a OpenSAF mantener el número de instancias declaradas para un GS determinado. La definición de un GS identifica todas las SU asociadas y su estado (activa, en espera, fallida). [ 2 ] [ 16 ]

Instancia de servicio

Una instancia de servicio (SI) de OpenSAF es un conjunto de SU que trabajan juntas, como una capa de una aplicación de múltiples capas. 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). Por defecto, un servicio se expone dentro de un clúster (por ejemplo, SU[TypeA] se agrupa en un SG, con las solicitudes de SU[typeB] balanceadas entre ellas), pero el servicio también puede exponerse fuera de un clúster (por ejemplo, para que los clientes lleguen a las SU de front-end). [ 2 ] [ 16 ]

Volúmenes

Los sistemas de archivos disponibles para las SU de OpenSAF son, por defecto, 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 de Sistema de Archivos de Red (NFS), accesible para todos los nodos de carga útil. [ 30 ] Son posibles otras soluciones técnicas; lo importante es que los volúmenes (recursos compartidos de archivos, puntos de montaje) se pueden modelar en AMF. Los volúmenes de alta disponibilidad proporcionan almacenamiento persistente que existe durante la vida útil de la propia SU. Este almacenamiento también se puede utilizar como espacio de disco compartido para SU dentro del SG. Los volúmenes montados en puntos de montaje específicos en el nodo pertenecen a un SG específico, por lo que esa instancia no se puede compartir con otros SG que utilicen el mismo punto de montaje del sistema de archivos.

Arquitectura

La arquitectura OpenSAF es 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 forma parte de un servicio OpenSAF con inteligencia de servicio centralizada. Normalmente es un proceso en el nodo controlador. Los Directores de nodo coordinan las actividades de servicio con ámbito de 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 la aplicación. Los Agentes normalmente se comunican con sus Directores de nodo de servicio o Servidores. Los servicios OpenSAF se clasifican modularmente como se muestra a continuación [ 22 ].

  • Servicios principales: 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/empaquetado de OpenSAF. OpenSAF se puede configurar para usar TCP o TIPC como protocolo de transporte subyacente. Los nodos se pueden agregar/eliminar dinámicamente del clúster de OpenSAF en tiempo de ejecución. El clúster de OpenSAF escala bien hasta varios cientos de nodos. OpenSAF admite los siguientes enlaces de lenguaje para las API de la interfaz AIS:

  • C , C++
  • Enlaces 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 añadir nuevos servicios, así como adaptar los servicios existentes. Todos los servicios de OpenSAF están diseñados para admitir actualizaciones durante su funcionamiento.

Servicios

Los siguientes servicios AIS del Foro SA se implementan mediante OpenSAF 5.0. [ 23 ]

  • Marco de gestión de disponibilidad (AMF), descrito anteriormente.
  • Servicio de pertenencia a clúster (CLM): determina si un nodo está en buen estado para formar parte del clúster. Proporciona un mecanismo para realizar un seguimiento de los nodos del clúster interactuando con PLM para monitorizar el estado del sistema operativo y el hardware subyacentes.
  • Servicio de punto de control (CKPT): para guardar estados de la aplicación y actualizaciones incrementales que se pueden usar para restaurar el servicio durante una conmutación por error o un cambio de sistema.
  • Servicio de eventos (EVT): proporciona un modelo de mensajería de publicación-suscripción que se puede utilizar para mantener sincronizadas las aplicaciones y las entidades de gestión sobre los eventos que ocurren 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): Permite registrar (en archivos de registro) los cambios funcionales que ocurren en el clúster, con soporte para diversos formatos de registro. No se utiliza para depuración ni seguimiento de errores. Admite el registro de alarmas y notificaciones que se producen en el clúster.
  • Servicio de mensajería (MSG): admite un mecanismo de mensajería a nivel de clúster con múltiples remitentes y un receptor, así como mecanismos de grupos de mensajes.
  • Servicio de Notificaciones (NTF): Proporciona un modelo productor/suscriptor para las notificaciones de gestión del sistema, lo que permite la gestión de fallos. Se utiliza para notificaciones de alarmas y fallos, con soporte para el registro del historial para el análisis de fallos. Admite los formatos de notificación de las recomendaciones ITU-T X.730, X.731, X.733 y X.736.
  • Servicio de administración de plataforma (PLM): proporciona un mecanismo para configurar una vista lógica del hardware subyacente (FRU) y del sistema operativo. Permite realizar un seguimiento del estado del sistema operativo y del hardware (FRU), así como llevar a cabo operaciones administrativas en coordinación con los servicios y aplicaciones de OpenSAF.
  • Marco de gestión de software (SMF): admite la actualización automatizada en servicio de aplicaciones, middleware y sistemas operativos en todo el clúster.

Seguidores

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

Usos

OpenSAF se usa comúnmente para 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 .

Véase también

Referencias

  1. ↑ "OpenSAF/Acerca de" . SourceForge . Archivado del original el 11 de mayo de 2015. Consultado el 28 de diciembre de 2020 .
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Maria Toeroe; Francis Tam (2012). Disponibilidad del servicio: Principios y práctica . John Wiley & Sons. ISBN 978-1-1199-4167-5.
  3. ↑ "OpenSAF Readme" . SourceForge . Archivado del original el 28/12/2020 . Consultado el 28/12/2020 .
  4. ↑ "OpenSAF" . OpenSAF . 19 de marzo de 2014. Consultado el 28 de diciembre de 2020 .
  5. ↑ "Contenedores tolerantes a fallos con NiLiCon" (PDF) . ucla . Archivado (PDF) del original el 29/12/2020 . Consultado el 28/12/2020 .
  6. 1 2 Carolyn Mathas (28 de febrero de 2007). "Proyecto OpenSAF" . eetimes . Archivado del original el 27 de agosto de 2020. Recuperado el 28 de diciembre de 2020 .
  7. ↑ Equipo de redacción de ED News (2007). "Líderes de la industria crearán un consorcio para el proyecto OpenSAF" . Archivado del original el 29 de diciembre de 2020.
  8. ↑ Fundación OpenSaf (2010). "GoAhead Software se une a OpenSAF™" (Comunicado de prensa). Archivado del original el 29 de diciembre de 2020.
  9. ↑ cook (2007). "Motorola lanza un entorno operativo de alta disponibilidad de código abierto" . Archivado del original el 21 de diciembre de 2014.
  10. ↑ Fundación OpenSAF (2010). "OpenSAF en el despliegue comercial" (Comunicado de prensa). Archivado del original el 25 de junio de 2018.
  11. ↑ Madhusanka Liyanage; Andrei Gurtov; Mika Ylianttila (2015). Redes móviles definidas por software (SDMN): Más allá de la arquitectura de red LTE . John Wiley & Sons, Ltd. doi : 10.1002/9781118900253 . ISBN 9781118900253.
  12. ↑ Yanal Alahmad; Tariq Daradkeh; Anjali Agarwal (2018). "Planificador de contenedores con conciencia de disponibilidad para servicios de aplicaciones en la nube". 2018 IEEE 37th International Performance Computing and Communications Conference (IPCCC) . pp. 1–6 . doi : 10.1109/PCCC.2018.8711295 . ISBN  978-1-5386-6808-5. S2CID 155108018 . 
  13. ↑ Leila Abdollahi Vayghan; Mohamed Aymen Saied; Maria Toeroe; Ferhat Khendek (2019). "Kubernetes como gestor de disponibilidad para aplicaciones de microservicios". Journal of Network and Computer Applications . arXiv : 1901.04946 .
  14. 1 2 "OpenSAF Releases 2.0" . LightReading . Archivado del original el 15 de agosto de 2020. Recuperado el 29 de diciembre de 2020 .
  15. ↑ "Middleware Linux de código abierto de grado operador revisado (LinuxDevices)" . LWN . Archivado del original el 17 de septiembre de 2015. Consultado el 29 de diciembre de 2020 .
  16. 1 2 3 4 5 6 7 8 9 "Descripción general de OpenSAF Release 4 "La versión de arquitectura"" (PDF) . OpenSAF . Archivado (PDF) del original el 31 de diciembre de 2020 . Recuperado el 29 de diciembre de 2020 .
  17. ↑ Hans J. Rauscher (22 de junio de 2009). "OpenSAF 3.0 lanzado" . WindRiver . Archivado del original el 29 de junio de 2009. Recuperado el 30 de diciembre de 2020 .
  18. ↑ "El proyecto OpenSAF lanza una importante actualización de su middleware de alta disponibilidad" . PICMG . Archivado del original el 31 de diciembre de 2020. Consultado el 30 de diciembre de 2020 .
  19. ↑ "Anuncio de la versión 5.0.0 GA y las versiones de mantenimiento 4.7.1 y 4.6.2" . sourceforge . Archivado del original el 31 de diciembre de 2020. Consultado el 30 de diciembre de 2020 .
  20. ^ Foro SA (2010 ) . "SAI-AIS-AMF-B.04.01 Sección 3.6" (PDF) . OpenSAF . Consultado el 20 de diciembre de 2020 .
  21. ↑ Anders Widell; Mathivanan NP (2012). "OpenSAF en la nube. Por qué sigue siendo necesario un middleware de alta disponibilidad" (PDF) . Eventos de Linuxfoundation . Consultado el 24 de septiembre de 2015 .
  22. 1 2 Jon Paul Maloy (2004). "TIPC: Proporcionando comunicación para clústeres Linux" (PDF) . Linux Kernel.org . Simposio Linux, Volumen Dos. Archivado (PDF) del original el 30 de agosto de 2017. Recuperado el 31 de diciembre de 2020 .
  23. 1 2 3 4 OpenSAF TSC (2016). "Opensaf" . OPNFV . Archivado del original el 31-12-2020 . Recuperado el 28-12-2020 .
  24. 1 2 3 Proyecto OpenSAF (2020). "OpenSAF README" . Sourceforge . Recuperado el 31-12-2020 .
  25. ↑ Maxime TURENNE (2015). "UN NUEVO LENGUAJE ESPECÍFICO DE DOMINIO PARA GENERAR Y VALIDAR CONFIGURACIONES DE MIDDLEWARE PARA APLICACIONES DE ALTA DISPONIBILIDAD" (PDF) . etsmtl.ca . Consultado el 28 de diciembre de 2020 .
  26. ↑ Pejman Salehi; Abdelwahab Hamou-Lhadj; Maria Toeroe; Ferhat Khendek (2016). "Un lenguaje de modelado específico de dominio basado en UML para la gestión de la disponibilidad del servicio" . Computer Standards & Interfaces . Computer Standards & Interfaces, Vol. 44, No. C. Elsevier Science Publishers BV: 63–83 . doi : 10.1016/j.csi.2015.09.009 . Recuperado el 28 de diciembre de 2020 .
  27. ↑ Proyecto OPNFV HA (2016). "Análisis de escenarios para alta disponibilidad en NFV, Sección 5.4.2" (PDF) . OPNFV . Archivado (PDF) del original el 31/12/2020 . Recuperado el 31/12/2020 .
  28. ↑ Proyecto OpenSAF (2020). "OpenSAF IMM README" . Sourceforge . Archivado del original el 31/12/2020 . Recuperado el 31/12/2020 .
  29. ↑ Jens Jensen; Grupo de Expertos (2010). "JSR 319: Gestión de disponibilidad para Java" . JCP . Archivado del original el 10 de julio de 2017. Consultado el 31 de diciembre de 2020 .
  30. ↑ Ferhat Khendek (2013). "OpenSAF y VMware desde la perspectiva de la alta disponibilidad" (PDF) . DMTF . Archivado (PDF) del original el 23 de septiembre de 2015. Recuperado el 31 de diciembre de 2020 .