OpenSAF (comúnmente estilo SAF , la disponibilidad marco de servicios [1] ) es un código abierto del servicio - orquestación sistema para la automatización de equipo de aplicación de despliegue, la escala y la gestión. OpenSAF es coherente con los estándares de Service Availability Forum (SAF) y SCOPE Alliance y los amplía . [2]
Autor (es) original (es) | Motorola |
---|---|
Desarrollador (es) | Fundación OpenSAF |
Versión inicial | 31 de junio de 2007 |
Lanzamiento estable | 5.21.03 / 1 de marzo de 2021 |
Repositorio | |
Escrito en | C ++ |
Tipo | Software de gestión de clústeres |
Sitio web | opensaf |
Fue diseñado originalmente por Motorola ECC y es mantenido por OpenSAF Project. [3] OpenSAF es la implementación más completa de las especificaciones SAF AIS , que proporciona una plataforma para automatizar la implementación, el escalado y las operaciones de servicios de aplicaciones en grupos de hosts. [4] Funciona en una variedad de herramientas de virtualización y ejecuta servicios en un clúster, a menudo integrándose con tiempos de ejecución de JVM , Vagrant y / o Docker . OpenSAF originalmente interactuaba con interfaces de programación de aplicaciones (API) C estándar, pero ha agregado enlaces 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 publica poca investigación formal para mejorar las técnicas de alta disponibilidad y tolerancia a fallas para contenedores y nube, [5] los grupos de investigación están explorando activamente estos desafíos con OpenSAF.
Historia
OpenSAF fue fundada por un consorcio industrial, que incluía a Ericsson, HP y Nokia Siemens Networks, y fue anunciado por primera vez por Motorola ECC, adquirido por Emerson Network Power, el 28 de febrero de 2007. [6] La Fundación OpenSAF se lanzó oficialmente el 22 de enero de 2007 . 2008. La membresía evolucionó para incluir 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 adquirido por Oracle. [8] El desarrollo y el diseño de OpenSAF están fuertemente influenciados por los requisitos del sistema de misión crítica , incluidos Carrier Grade Linux , SAF , ATCA e Interfaz de plataforma de hardware . 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 de OpenSAF celebró conferencias entre 2008 y 2010; la primera conferencia organizada por Nokia Siemens Networks en Munich (Alemania), la segunda organizada por Huawei en Shenzhen (China) y la tercera organizada 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 y de la industria han publicado libros de forma independiente que describen soluciones basadas en OpenSAF. [2] [11] Un creciente cuerpo de investigación sobre la disponibilidad de servicios está acelerando el desarrollo de características de OpenSAF que respaldan las implementaciones de nube y microservicios de misión crítica, y la orquestación de servicios. [12] [13]
OpenSAF 1.0 fue lanzado el 22 de enero de 2008. Se componía de la base de código NetPlane Core Service (NCS) aportada 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 el primer lanzamiento desarrollado por la comunidad OpenSAF. Esta versión incluye el servicio de registro y compatibilidad con 64 bits. [14] OpenSAF 3.0 lanzado el 17 de junio de 2009, incluía administración de 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 que incluyen cerrar brechas funcionales, resolver la arquitectura interna, permitir la actualización en servicio, aclarar las API y mejorar la modularidad. [16] Recibiendo un gran interés de la industria y los académicos, OpenSAF celebró dos conferencias comunitarias en 2011, una organizada por la Universidad MIT en Boston MA, y una segunda organizada por Ericsson en Estocolmo.
Versión | Fecha de lanzamiento | Notas |
---|---|---|
1.0 | 22 de enero de 2008 | Base de código original de la base de código NetPlane Core Service (NCS) aportada por Motorola ECC al proyecto OpenSAF. |
2.0 | 12 de agosto de 2008 | |
3,0 | 17 de junio de 2009 | La segunda versión (contando desde la v2.0 en adelante), tomó alrededor de 1,5 años, con contribuciones de Wind River Systems. [17] |
4.0 | 1 de julio de 2010 | El lanzamiento de "Arquitectura". Primer candidato viable para implementación de nivel de operador. [18] |
4.2 | 16 de marzo de 2012 | Capacidad de gestión mejorada, modelado de disponibilidad mejorado. |
5,0 | 5 de mayo de 2016 | Un lanzamiento significativo. Soporte para controladores de sistema de repuesto (2N + repuestos), clúster sin cabeza (resiliencia en la nube), enlaces de Python mejorados, registro de nombres de nodo. [19] |
5,20 | 1 de junio de 2021 | |
Leyenda: Versión antigua Versión anterior, aún mantenida Ultima versión Última versión de vista previa Lanzamiento futuro |
Conceptos
OpenSAF define un conjunto de bloques de construcción, que proporcionan colectivamente un mecanismo para administrar la Disponibilidad del Servicio (SA) de las aplicaciones basadas en modelos de capacidad de recursos. [20] SA y alta disponibilidad (HA) es la probabilidad de que un servicio esté disponible en un momento aleatorio; Los sistemas de misión crítica requieren al menos un 99,999% (cinco nueves) de disponibilidad. 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 débilmente acoplados con interconexiones rápidas entre nodos (es decir, utilizando TIPC / TCP), [22] y extensible para satisfacer diferentes cargas de trabajo; los componentes se comunican entre sí utilizando cualquier protocolo. Esta extensibilidad es proporcionada en gran parte por la API de IMM, utilizada por componentes internos y servicios centrales. La plataforma puede ejercer control sobre los recursos informáticos y de almacenamiento definiéndolos como Objetos, para ser administrados como instancias (servicio de componentes) y / o restricciones de nodo. [2] [20] [23]
El software OpenSAF se distribuye por naturaleza, siguiendo la arquitectura primaria / réplica . En un clúster "OpenSAF", hay dos tipos de nodos que se pueden dividir en los que gestionan un nodo individual y un 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 repuestos listos para asumir el rol de Activo o En espera en caso de falla. Los nodos pueden funcionar sin cabeza, sin plano de control, lo que agrega resistencia a la nube. [16] [24]
Modelo de sistema
El modelo del 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 carga útil / trabajador. El comportamiento de AMF se modifica mediante un objeto de configuración. [24] Los servicios pueden utilizar modelos de redundancia activa 'Sin redundancia', 2N, N + M, N-way y N-way. [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 entregar herramientas de ecosistema, para soportar mejor el modelado y la automatización de casos de uso de nivel 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, administra su carga de trabajo y dirige la comunicación a través del sistema. El plano de control de OpenSAF consta de varios componentes, cada uno con su propio proceso, que pueden ejecutarse tanto en un solo nodo SC como en varios nodos SC, y admiten clústeres de alta disponibilidad y disponibilidad de servicios . [2] [24] Los diversos componentes del plano de control de OpenSAF son los siguientes:
- Information Model Manager ( IMM ) es un almacén de datos persistentes que almacena de manera confiable 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 middleware y configuración de aplicaciones e 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 usar 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 (consulte el teorema de CAP ). [2] [23] [27] El servicio IMM sigue el marco OpenSAF "Service Director" de tres niveles, que comprende IMM Director (IMMD), IMM Node Director (IMMND) y la biblioteca de IMM Agent (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", la instancia del controlador en espera se mantiene actualizada mediante un servicio de puntos de control basado en mensajes. IMMD rastrea la membresía del clúster (usando MDS), proporciona control de acceso al almacén de datos e interfaz administrativa para todos los servicios de OpenSAF. [28] [2]
- El Marco de administración de disponibilidad ( AMF ) ofrece un marco de administración de carga de trabajo y alta disponibilidad con un soporte sólido (junto con otros servicios AIS) para el ciclo de vida completo de administración de fallas (detección, aislamiento, recuperación, reparación y notificación). AMF sigue al "Director de servicio" OpenSAF de tres niveles, que comprende el director (AmfD), el director del nodo (AmfND) y los agentes (AmfA), y un perro guardián interno para la protección de AmfND. El servicio activo de AmfD 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 alcance. [2] Garantiza que los modelos de estado estén de acuerdo actuando como la información principal y el puente API en todos los componentes. AMF monitorea el estado de IMM, aplica cambios de configuración o simplemente restaura cualquier divergencia a la "configuración deseada" usando políticas de escalada de administración de fallas para programar la creación de la implementación deseada. [dieciséis]
- Los directores de AMF ( AmfD ) son programadores que deciden en qué nodos se ejecuta un grupo de servicio no programado (una instancia de servicio redundante). Esta decisión se basa en los modelos de capacidad y disponibilidad actuales frente a los "deseados", los modelos de redundancia del servicio y las limitaciones como la calidad del servicio, la afinidad / antiafinidad, etc. Los directores de AMF hacen coincidir la "oferta" de recursos con la "demanda" de la carga de trabajo. y su comportamiento se puede manipular a través de un objeto del sistema IMM. [2] [16]
Componente
El componente es una entidad lógica del modelo del 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 lógicas (SU), de acuerdo con las interdependencias de fallas, y se asocian con un nodo. El SU es una unidad de carga de trabajo de la que se puede crear una instancia 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 Servicios (SG) que exhiben características particulares de modelado de redundancia. SU dentro de una SG se asigna a instancias de servicio (SI) y se le da un estado de disponibilidad de activo o en espera. Los SI son servicios lógicos redundantes escalables protegidos por AMF. [2] [16]
Nodo
Un nodo es una instancia informática (un blade, hipervisor o VM) donde se implementan las instancias de servicio (carga de trabajo). El conjunto de nodos que pertenecen a la misma subred de comunicación (sin enrutamiento) comprende el Clúster lógico. Cada nodo del clúster debe ejecutar un entorno de ejecución para los servicios, así como los servicios de OpenSAF que se enumeran a continuación:
- Director de nodo (AmfND): AmfND es responsable del estado de ejecución de cada nodo, lo que garantiza que todas las SU activas en ese nodo estén en buen estado. Se encarga de iniciar, detener y mantener CSI y / o SU organizados en SG según lo indique el plano de control. El servicio AmfND aplica la configuración AMF deseada, persistente en IMM, en el nodo. Cuando se detecta una falla en un 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 , contenedores , virtualización y JVM , mediante el modelado de los comandos del ciclo de vida del servicio y del componente (inicio / parada / verificación de estado) en el Modelo AMF. [2]
- Contenido en contenedor: un contenedor de AMF puede residir dentro de una SU. El contenido en contenedor es el nivel más bajo de tiempo de ejecución del que se puede crear una instancia. El componente contenido en contenedor SA-Aware actualmente tiene como objetivo una máquina virtual Java (JVM) por JSR139. [29] [2]
Unidad de servicio
La unidad de programación básica en OpenSAF es una Unidad de servicio (SU). Un SU es una agrupación de componentes. Una SU consta de uno o más componentes que están garantizados para estar ubicados en el mismo nodo. A las SU no se les asignan direcciones IP de forma predeterminada, pero pueden contener algún componente que sí las tenga. Una SU puede gestionarse administrativamente utilizando una dirección de objeto. AmfND monitorea el estado de las SU y, si no se encuentran en el estado deseado, vuelve a implementarlas 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 en la SU. [39] SU se puede administrar administrativamente a través de AMF CLI, o la administración se puede delegar en AMF. Estos volúmenes también son la base del almacenamiento persistente. [2] [16]
Grupo de servicio
El propósito de un grupo de servicios es mantener un conjunto estable de réplicas de SU en ejecución en un momento dado. Se puede utilizar para garantizar la disponibilidad de un número específico de SU idénticas según el 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 el número de instancias declaradas para un SG determinado. La definición de una SG identifica todas las SU asociadas y su estado (activo, en espera, fallido). [2] [16]
Instancia de servicio
Una instancia de servicio OpenSAF (SI) es un conjunto de SU que funcionan en conjunto, como un nivel de una aplicación de varios niveles. El conjunto de SU que protege un servicio lo define la SG. SG de instancias múltiples (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 SU activo en ese SG (incluso si las fallas causan las SU para pasar de una máquina a otra). De forma predeterminada, un servicio se expone dentro de un clúster (p. Ej., SU [TypeA] se agrupa en un SG, con las solicitudes de SU [typeB] balanceadas de carga entre ellas), pero el servicio también se puede exponer fuera de un clúster (p. Ej., Para clientes para llegar a las SU de front-end). [2] [16]
Volúmenes
Los sistemas de archivos disponibles para los SU de OpenSAF son almacenamiento potencialmente efímero, de forma predeterminada. Si el nodo se destruye / recrea, los datos se pierden en ese nodo. Una solución es un almacenamiento compartido Network File System (NFS), accesible para todos los nodos de carga útil. [30] Son posibles otras soluciones técnicas; lo importante es que los volúmenes (archivo compartido, punto 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 un espacio de disco compartido para SU dentro de la 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 utilizando el mismo punto de montaje del sistema de archivos.
Arquitectura
La arquitectura de OpenSAF se distribuye y se ejecuta en un grupo de nodos lógicos. Todos los servicios de OpenSAF tienen una arquitectura de 3 o 2 niveles. En la arquitectura de 3 niveles, los servicios de OpenSAF se dividen en un Director de servicios, un Nodo-Director de servicios y un Agente. El Director es parte de un servicio OpenSAF con inteligencia de servicio central. Normalmente es un proceso en el nodo del controlador. Los directores de nodo coordinan las actividades de servicio del ámbito 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 procesos de aplicación. Los agentes suelen hablar con sus servidores o directores de nodo de servicio. Los servicios de OpenSAF se clasifican modularmente como se indica 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 utilizar TCP o TIPC como transporte subyacente. Los nodos se pueden agregar / eliminar dinámicamente a / desde el 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 idioma para las API de la 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 admitir actualizaciones en servicio listas para usar. Es posible agregar soporte para interfaces de administración adicionales además de la arquitectura modular existente (por ejemplo: - SNMP, NETCONF, REST, HTTP, RPC).
La información detallada de la arquitectura OpenSAF está disponible en http://sourceforge.net/p/opensaf/documentation/ci/default/tree/OpenSAF_Overview_PR.odt
Servicios
Los siguientes servicios AIS de SA Forum son 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á lo suficientemente en buen estado como para formar parte del clúster. Proporciona un mecanismo para rastrear los nodos del clúster interactuando con PLM para rastrear el estado del SO / hardware subyacente.
- Checkpoint Service (CKPT): para guardar los estados de la aplicación y las actualizaciones incrementales que se pueden usar para restaurar el servicio durante la conmutación por error o la conmutación.
- Servicio de eventos (EVT): proporciona un modelo de mensajería de publicación-suscripción que se puede usar para mantener las aplicaciones y las entidades de administración sincronizadas 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): 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 de registro. No para depuración o 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 en todo el clúster con varios remitentes: un solo receptor y mecanismos de grupo de mensajes.
- Servicio de notificación (NTF): proporciona un modelo de productor / suscriptor para las notificaciones de administración del sistema para permitir el manejo de fallas. Se utiliza para notificaciones de alarmas y fallas con soporte para registrar el historial para el análisis de fallas. Admite formatos de notificación de recomendaciones ITU-T X.730, X.731, X.733, X.736.
- Servicio de gestión de plataforma (PLM): proporciona un mecanismo para configurar una vista lógica del hardware subyacente (FRU) y el sistema operativo. Proporciona un mecanismo para rastrear el estado del sistema operativo, el hardware (FRU) y para realizar operaciones administrativas en coordinación con los servicios y aplicaciones de OpenSAF.
- Software Management Framework (SMF): compatibilidad con una actualización automática en servicio de la aplicación, el middleware y el sistema operativo en todo el clúster.
Partidarios
Los proveedores de equipos de red serán los principales usuarios de productos basados en el código base de OpenSAF, integrándolos en sus productos para proveedores de servicios de red, operadores y operadores. Muchos proveedores de equipos de red han demostrado su apoyo a OpenSAF al unirse a la Fundación y / o contribuir al proyecto Open Source. 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. .
Usos
OpenSAF se usa comúnmente como una forma de lograr la disponibilidad del servicio de grado de operador (cinco nueves). Ninguna otra solución de código abierto puede igualar la disponibilidad del servicio OpenSAF. 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.
Ver también
- SAForum
- Alianza SCOPE
- OpenHPI
- Lista de software de gestión de clústeres
- Base de computación nativa en la nube
Referencias
- ^ "OpenSAF / Acerca de" . SourceForge . Archivado desde el original el 11 de mayo de 2015 . Consultado el 28 de diciembre de 2020 .
- ^ a b c d e f g h i j k l m n o p q r s Maria Toeroe; Francis Tam (2012). Disponibilidad del servicio: principios y práctica . John Wiley e hijos. ISBN 978-1-1199-4167-5.
- ^ "Léame de OpenSAF" . SourceForge . Archivado desde el original el 28 de diciembre de 2020 . Consultado el 28 de diciembre de 2020 .
- ^ "OpenSAF" . OpenSAF . Consultado el 28 de diciembre de 2020 .
- ^ "Envases tolerantes a fallas que utilizan NiLiCon" (PDF) . ucla . Archivado (PDF) desde el original el 29 de diciembre de 2020 . Consultado el 28 de diciembre de 2020 .
- ^ a b Carolyn Mathas. "Proyecto OpenSAF" . eetimes . Archivado desde el original el 27 de agosto de 2020 . Consultado el 28 de diciembre de 2020 .
- ^ Personal de ED News (2007). "Líderes de la industria para establecer un consorcio en el proyecto OpenSAF" . Archivado desde el original el 29 de diciembre de 2020.
- ^ Fundación OpenSaf (2010). "GoAhead Software se une a OpenSAF (TM)" . Archivado desde el original el 29 de diciembre de 2020.
- ^ cocinar (2007). "Motorola lanza entorno operativo de alta disponibilidad de código abierto" . Archivado desde el original el 29 de diciembre de 2020.
- ^ Fundación OpenSAF (2010). "OpenSAF en despliegue comercial" . Archivado desde el original el 25 de junio de 2018.
- ^ 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.
- ^ Yanal Alahmad; Tariq Daradkeh; Anjali Agarwal (2018). "Programador de contenedores de disponibilidad para servicios de aplicaciones en la nube" . IEEE : 1–6. doi : 10.1109 / PCCC.2018.8711295 . ISBN 978-1-5386-6808-5. S2CID 155108018 .
- ^ Leila Abdollahi Vayghan; Mohamed Aymen Saied; Maria Toeroe; Ferhat Khendek (2019). "Kubernetes como administrador de disponibilidad para aplicaciones de microservicio" . Revista de aplicaciones informáticas y de red . arXiv : 1901.04946 . Consultado el 28 de diciembre de 2020 .
- ^ a b "Versiones 2.0 de OpenSAF" . LightReading . Archivado desde el original el 15 de agosto de 2020 . Consultado el 29 de diciembre de 2020 .
- ^ "Middleware de Linux de grado portador de código abierto revisado (dispositivos Linux)" . LWN . Archivado desde el original el 17 de septiembre de 2014 . Consultado el 29 de diciembre de 2020 .
- ^ a b c d e f g h yo "Descripción general de la versión 4 de OpenSAF" La versión de la arquitectura " " (PDF) . OpenSAF . Archivado (PDF) desde el original el 29 de diciembre de 2020 . Consultado el 29 de diciembre de 2020 .
- ^ Hans J. Rauscher. "OpenSAF 3.0 lanzado" . WindRiver . Archivado desde el original el 29 de junio de 2020 . Consultado el 30 de diciembre de 2020 .
- ^ "El proyecto OpenSAF lanza una actualización importante para el middleware de alta disponibilidad" . PICMG . Archivado desde el original el 31 de diciembre de 2020 . Consultado el 30 de diciembre de 2020 .
- ^ "Anuncio de la versión 5.0.0 GA y 4.7.1, 4.6.2 versiones de mantenimiento" . sourceforge . Archivado desde el original el 31 de diciembre de 2020 . Consultado el 30 de diciembre de 2020 .
- ^ a b c Foro SA (2010). "SAI-AIS-AMF-B.04.01 Sección 3.6" (PDF) . OpenSAF . Consultado el 20 de diciembre de 2020 .
- ^ Anders Widell; Mathivanan NP (2012). "OpenSAF en la nube. Por qué todavía se necesita un middleware de alta disponibilidad" (PDF) . Eventos de Linuxfoundation . Consultado el 24 de septiembre de 2015 .
- ^ a b Jon Paul Maloy (2004). "TIPC: Proporcionar comunicación para clústeres de Linux" (PDF) . Linux Kernel.org . Simposio de Linux, volumen dos. Archivado (PDF) desde el original el 30 de agosto de 2017 . Consultado el 31 de diciembre de 2020 .
- ^ a b c d OpenSAF TSC (2016). "Opensaf" . OPNFV . Archivado desde el original el 31 de diciembre de 2020 . Consultado el 28 de diciembre de 2020 .
- ^ a b c Proyecto OpenSAF (2020). "Léame de OpenSAF" . Sourceforge . Consultado el 31 de diciembre de 2020 .
- ^ Maxime TURENNE (2015). "UN NUEVO LENGUAJE ESPECÍFICO DE DOMINIO PARA GENERAR Y VALIDAR CONFIGURACIONES DE MIDDLEWARE PARA APLICACIONES ALTAMENTE DISPONIBLES" (PDF) . etsmtl.ca . Consultado el 28 de diciembre de 2020 .
- ^ 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 de servicios" . doi . Estándares e interfaces informáticos de Elsevier Science Publishers BV, vol. 44, No. C. doi : 10.1016 / j.csi.2015.09.009 . Consultado el 28 de diciembre de 2020 .
- ^ Proyecto OPNFV HA (2016). "Análisis de escenarios para alta disponibilidad en NFV, sección 5.4.2" (PDF) . OPNFV . Archivado (PDF) desde el original el 31 de diciembre de 2020 . Consultado el 31 de diciembre de 2020 .
- ^ Proyecto OpenSAF (2020). "OpenSAF IMM README" . Sourceforge . Archivado desde el original el 31 de diciembre de 2020 . Consultado el 31 de diciembre de 2020 .
- ^ Jens Jensen; Grupo de expertos (2010). "JSR 319: Gestión de disponibilidad para Java" . JCP . Archivado desde el original el 10 de julio de 2017 . Consultado el 31 de diciembre de 2020 .
- ^ Ferhat Khendek (2013). "OpenSAF y VMware desde la perspectiva de la alta disponibilidad" (PDF) . DMTF . Archivado (PDF) desde el original el 3 de septiembre de 2015 . Consultado el 31 de diciembre de 2020 .
enlaces externos
- Página web oficial
- OpenSAF en SourceForge.net
- Foro de SA en la Wayback Machine (archivado 2008-10-06)