OpenSAF
![]() | |
Originalautor (en) | Motorola |
---|---|
Entwickler (en) | OpenSAF Foundation |
Erstveröffentlichung | 31. Juni 2007 |
Stabile Version | 5.21.03 / 1. März 2021 |
Repository | |
Geschrieben in | C ++ |
Typ | Cluster -Management -Software |
Webseite | OpenSAF |
OpenSAF (Allgemein gestaltet Safer, der Service Verfügbarkeitsrahmen[1]) ist ein Open Source Service-Orchestrierung System zur Automatisierung von Computer Anwendung Bereitstellung, Skalierung und Management. OpenSAF steht im Einklang mit und erweitert. Service Verfügbarkeitsforum (SAF) und Scope Alliance Standards.[2]
Es wurde ursprünglich von entworfen von Motorola ECCund wird durch das OpenSAF -Projekt gepflegt.[3] OpenSAF ist die umfassendste Implementierung der SAF AIS Spezifikationen, Bereitstellung einer Plattform für die Automatisierung von Bereitstellungen, Skalierung und Betrieb von Anwendungsdiensten in Clustern von Hosts.[4] Es funktioniert in einer Reihe von Virtualisierungstools und führt Dienste in einem Cluster aus, in dem sie häufig in integriert werden in JVM, Landstreicherund/oder Docker Laufzeiten. OpenSAF hat ursprünglich mit Standard -C -Application Programing Interfaces (APIs) verbunden, hat jedoch Java- und Python -Bindungen hinzugefügt.[2]
OpenSAF konzentriert sich auf die Verfügbarkeit von Serviceverfügbarkeit über die Anforderungen an die hohe Verfügbarkeit (HA). Während nur wenig formelle Forschung veröffentlicht wird, um die Techniken der hohen Verfügbarkeits- und Fehlertoleranztechniken für Container und Cloud zu verbessern.[5] Forschungsgruppen untersuchen diese Herausforderungen mit OpenSAF aktiv.
Geschichte

OpenSAF wurde von einem Branchenkonsortium, darunter Ericsson, HP und Nokia Siemens Networks, gegründet und wurde am 28. Februar 2007 erstmals von Motorola ECC angekündigt, die von Emerson Network Power übernommen wurde.[6] Die OpenSAF-Stiftung wurde am 22. Januar 2008 offiziell eingeführt. Die Mitgliedschaft wurde zu Emerson Network Power, Sun Microsystems, ENEA, Wind River, Huawei, IP-Infusion, Tail-F, Aricent, GoaHead-Software und Rancore-Technologien entwickelt.[2][7] Goahead Software trat 2010 OpenSAF an, bevor er von Oracle erworben wurde.[8] OpenSAFs Entwicklung und Design werden stark von beeinflusst von Missionkritisch Systemanforderungen, einschließlich Carrier Grade Linux, Safer, ATCA und Hardware Platform Interface. OpenSAF war ein Meilenstein bei der Beschleunigung der Einführung von Linux in Telekommunikation und eingebetteten Systemen.[9]
Ziel der Stiftung war es, die Einführung von OpenSAF in kommerziellen Produkten zu beschleunigen. Die OpenSAF-Community veranstaltete zwischen 2008 und 2010 Konferenzen; Die erste Konferenz, die von Nokia Siemens Networks in München (Deutschland) veranstaltet wurde, die von Huawei in Shenzhen (China) veranstaltete und von HP in Palo Alto (USA) veranstaltet wurde. Im Februar 2010 wurde der erste kommerzielle Einsatz von OpenSAF in Carrier Networks angekündigt.[10] Akademische und Branchengruppen haben unabhängig voneinander Bücher veröffentlicht, in denen OpenSAF-basierte Lösungen beschrieben werden.[2][11] Eine wachsende Anzahl von Forschungsergebnissen in der Verfügbarkeit von Dienstleistungen beschleunigt die Entwicklung von OpenSAF-Funktionen, die Missionskritische Cloud- und Microservices-Bereitstellungen sowie die Service-Orchestrierung unterstützen.[12][13]
OpenSAF 1.0 wurde am 22. Januar 2008 veröffentlicht. Es umfasste die von Motorola ECC beigestellte Codebasis (NCS).[14] Zusammen mit der OpenSAF 1.0 -Release wurde die OpenSAF -Stiftung inceptiert.[6] OpenSAF 2.0, das am 12. August 2008 veröffentlicht wurde, war die erste Veröffentlichung, die von der OpenSAF -Community entwickelt wurde. Diese Version beinhaltete Protokollservice und 64-Bit-Support.[14] OpenSAF 3.0, das am 17. Juni 2009 veröffentlicht wurde, umfasste Plattformmanagement, Usability -Verbesserungen und Java -API -Unterstützung.[15]
OpenSAF 4.0 war im Juli 2010 eine Meilensteinveröffentlichung.[2] Mit dem Spitznamen "Architekturveröffentlichung" wurden signifikante Änderungen eingeführt, einschließlich der Schließung funktionaler Lücken, der Abwicklung der internen Architektur, der Ermöglichung von In-Service-Upgrade, Klärung von APIs und Verbesserung der Modularität.[16] OpenSAF erhielt erhebliche Interesse von Industrie und Akademikern und veranstaltete 2011 zwei Community -Konferenzen, eine von der MIT University in Boston MA, und ein zweites von Ericsson in Stockholm.
Ausführung | Veröffentlichungsdatum | Anmerkungen |
---|---|---|
1.0 | 22. Januar 2008 | Original Codebase von NCS -Codebasis (NETPLANE CORE Service) von Motorola ECC zum OpenSAF -Projekt. |
2.0 | 12. August 2008 | |
3.0 | 17. Juni 2009 | Die zweite Veröffentlichung (ab V2.0 ab V2.0) dauerte etwa 1,5 Jahre mit Beiträgen von Wind River Systems.[17] |
4.0 | 1. Juli 2010 | Die Veröffentlichung "Architektur". Erster tragfähiger Bereitstellungskandidat für Carrier-Grade.[18] |
4.2 | 16. März 2012 | Verbesserte Verwaltbarkeit, verbesserte Verfügbarkeitsmodellierung. |
5.0 | 5. Mai 2016 | Eine signifikante Veröffentlichung. Unterstützung für Ersatzsystem -Controller (2N + Ersatzteile), kopfloser Cluster (Cloud Resilience), verstärkte Pythonbindungen, Knotenname -Protokollierung.[19] |
5.20 | 1. Juni 2021 | |
Legende: Alte Version Ältere Version, noch gepflegt Letzte Version Neueste Vorschau -Version Zukünftige Veröffentlichung |
Konzepte

OpenSAF definiert eine Reihe von Bausteinen und bietet gemeinsam einen Mechanismus zur Verwaltung von Anwendungsverfügbarkeit (SA) der Serviceverfügbarkeit (SA) von Anwendungen, die auf Modellen der Ressourcenkapazität basieren.[20] SA und hohe Verfügbarkeit (HA) ist die Wahrscheinlichkeit, dass ein Dienst zu einem zufälligen Zeitpunkt verfügbar ist. Missionskritische Systeme benötigen mindestens 99,999% (fünf Neune) Verfügbarkeit. HA und SA sind im Wesentlichen gleich, aber SA geht weiter (d. H. In-Service-Upgrades von Hardware und Software).[21] OpenSAF ist für locker verbunden Systeme mit schnellen Verbindungen zwischen Knoten (d. H. Mit TIPC/TCP),[22] und erweiterbar, um verschiedene Arbeitsbelastungen zu erfüllen; Komponenten kommunizieren mit einem Protokoll zwischen sich. Diese Erweiterbarkeit wird größtenteils von der ImmpI, die von internen Komponenten und Kerndiensten verwendet wird, bereitgestellt. Die Plattform kann die Kontrolle über Rechen- und Speicherressourcen ausüben, indem sie als Objekte definiert werden, um als (Komponentendienst) und/oder Knotenbeschränkungen verwaltet zu werden.[2][20][23]
OpenSAF -Software ist in der Natur verteilt, folgt dem Primär-/Replika -Architektur. In einem "OpenSAF" -Cluster gibt es zwei Arten von Knoten, die in diejenigen unterteilt werden können, die eine Person verwalten Knoten und Kontrollebene. Ein Systemcontroller wird im "aktiven" Modus ausgeführt, ein anderer im "Standby" -Modus, und verbleibende Systemcontroller (falls vorhanden) sind Ersatzteile bereit, im Falle eines Fehlers als aktive oder Standby -Rolle zu übernehmen. Knoten können ohne Kontrollebene kopflos laufen und die Widerstandsfähigkeit der Wolken hinzufügen.[16][24]
Systemmodell

Das OpenSAF -Systemmodell ist der wichtigste Enabler API, so OpenSAF, Anforderungen zu verarbeiten und zu validieren und den Status von Objekten im AMF -Modell zu aktualisieren, sodass Direktoren Workloads und Servicegruppen über Mitarbeiter-/Nutzlastknoten hinweg planen können. Das AMF -Verhalten wird über ein Konfigurationsobjekt geändert.[24] Services können "No-Redundanz", 2N, N+M, N-Way und N-Way Active Redundanzmodelle verwenden.[20] OpenSAF fehlt offensichtliche Modellierungs -Toolchains, um das Design und die Erzeugung von AMF -Konfigurationsmodellen zu vereinfachen. Laufende Forschung, um diese Lücke zu schließen,[25][26] Muss Ökosystemwerkzeuge liefern, um die Modellierung und Automatisierung von Trägernahrungsmitteln und bessere Unterstützung zu unterstützen und besser zu unterstützen. Cloud Native Computing Foundation Anwendungsfälle.
Kontrollebene
Der OpenSAF System Controller (SC) ist die Hauptsteuerung des Clusters, die seine Arbeitsbelastung verwaltet und die Kommunikation über das System leitet. Die OpenSAF -Steuerebene besteht aus verschiedenen Komponenten, die jeweils ihren eigenen Prozess haben, die sowohl auf einem einzelnen SC -Knoten als auch auf mehreren SC -Knoten ausgeführt werden können, die unterstützend sind Hochverfügbarkeitscluster und Serviceverfügbarkeit.[2][24] Die verschiedenen Komponenten der OpenSAF -Steuerebene sind wie folgt:
- Informationsmodellmanager (Imm) ist ein anhaltender Datenspeicher, der die Konfigurationsdaten des Clusters zuverlässig speichert, was den Gesamtzustand des Clusters zu einem bestimmten Zeitpunkt darstellt. Bietet ein Mittel zur Definition und Verwaltung von Middleware- und Anwendungskonfiguration und Statusinformationen in Form von verwalteten Objekten und deren entsprechenden Attributen.[23] IMM wird als In-Memory-Datenbank implementiert, die seine Daten auf allen Knoten repliziert. Imm kann SQLite als anhaltendes Backend verwenden. Wie Apache ZooKeeper, IMM garantiert die Konsistenz von Konfigurationsdaten auf Transaktionsebene gegenüber Verfügbarkeit/Leistung (siehe Cap -Theorem).[2][23][27] Der IMM-Service folgt dem dreistufigen OpenSAF "Service Director" Framework, der Imm Director (IMMD), Immnode Director (IMMD) und IMM Agent Library (IMMA) umfasst. IMMD wird als Dämon für Controller mit einem 2N-Redundanzmodell implementiert. Die aktive Controller-Instanz ist "Primärreplik", die Standby-Controller-Instanz, die von einem meldungsbasierten Checkpoining-Dienst auf dem Laufenden gehalten wird. Immd Tracks Cluster -Mitgliedschaft (mit MDS) bietet Datenspeicherzugriffskontrolle und administrative Schnittstelle für alle OpenSAF -Dienste.[28][2]
- Verfügbarkeitsmanagement Rahmen (AMF) Serviert hohe Verfügbarkeits- und Workload -Management -Framework mit robuster Unterstützung (in Verbindung mit anderen AIS -Diensten) für den Lebenszyklus des vollständigen Fehlermanagements (Erkennung, Isolation, Wiederherstellung, Reparatur und Benachrichtigung). AMF folgt dem dreistufigen OpenSAF "Service Director", umfassenden Direktor (AMFD), Node Director (AMFND) und Agenten (AMFA) und einem internen Wachhund für AMFND-Schutz. Der aktive AMFD -Dienst ist für die Realisierung der Servicekonfiguration verantwortlich, die im IMM über System-/Clusterbereich hinweg anhält. Knotendirektoren erfüllen die gleiche Funktion für jede Komponente innerhalb ihres Geltungsbereichs.[2] Es stellt sicher, dass die staatlichen Modelle übereinstimmen, indem sie als Hauptinformationen und API -Brücke über alle Komponenten fungieren. AMF überwacht den IMM -Status, wendet Konfigurationsänderungen an oder stellte einfach alle Abweichungen in "gesuchte Konfiguration" mithilfe von Fehlerverwaltungsrichtlinien zurück, um die Erstellung der gewünschten Bereitstellung zu planen.[16]
- AMF -Direktoren (AMFD) sind Scheduler, die entscheiden, welche Knoten eine außerplanmäßige Servicegruppe (eine redundante Serviceinstanz) ausgeführt wird. Diese Entscheidung basiert auf dem aktuellen V.S. "gewünschte" Verfügbarkeits- und Fähigkeitsmodelle, Service-Redundanzmodelle und Einschränkungen wie Qualitätsqualität, Affinität/Anti-Affinität usw. Die AMF-Direktoren übereinstimmen mit dem Ressourcenangebot "Angebot" für die Arbeitsbelastung "Nachfrage" und sein Verhalten kann durch Manipulation durch durch ein Immsystemobjekt.[2][16]
Komponente
Die Komponente ist eine logische Entität des AMF -Systemmodells und stellt eine normalisierte Ansicht einer Computerressource wie Prozesse, Treiber oder Speicher dar. Die Komponenten werden gemäß den Abhängigkeiten von Fehler in logische Serviceeinheiten (SU) zusammengefasst und einem Knoten zugeordnet. Die SU ist eine sofortige Einheit der Arbeitsbelastung, die von einem AMF -Redundanzmodell kontrolliert wird, entweder aktiv, Standby- oder Fehlgeschlagen. SU des gleichen Typs wird in Service Groups (SG) eingeteilt, die bestimmte Redundanzmodellierungseigenschaften aufweisen. SU innerhalb eines SG wird zugewiesen Service Instances (SI) und gegeben einen Verfügbarkeitszustand von aktivem oder Standby. SIs sind skalierbare redundante logische Dienste, die von AMF geschützt sind.[2][16]
Knoten
A Knoten ist eine Computerinstanz (eine Klinge, Hypervisor oder VM), in der Serviceinstanzen (Workload) bereitgestellt werden. Der Satz von Knoten, die zu demselben Kommunikations -Subnetz gehören (kein Routing), umfasst den logischen Cluster. Jeder Knoten im Cluster muss eine Ausführungsumgebung für Dienste sowie OpenSAF -Dienste ausführen, die unten aufgeführt sind:
- Node Director (AMFND): Der AMFND ist für den laufenden Zustand jedes Knotens verantwortlich, um sicherzustellen, dass alle aktiven SU auf diesem Knoten gesund sind. Es kümmert sich um das Starten, Stoppen und Aufrechterhalten von CSI und/oder SUS, das sich in SG organisiert, wie von der Kontrollebene angewiesen. Der AMFND -Dienst erzwingt die gewünschte AMF -Konfiguration, die auf dem Knoten in IMM bestand. Wenn ein Knotenfehler erkannt wird, beobachtet der Director (AMFD) diese staatliche Änderung und startet eine Serviceinheit für einen anderen berechtigten gesunden Knoten.[2][16]
- Nicht-SA-bewusstes Komponenten: OpenSAF kann HA (jedoch nicht SA) für sofortige Komponenten bereitstellen, die stammen Cloud Computing, Containerisierung, Virtualisierung, und JVM Domänen durch Modellierung der Befehle für Komponenten- und Service -Lebenszyklus (Start/Stop/Health -Check) im AMF -Modell.[2]
- Container geschlossen: Ein AMF-Container kann sich in einem SU befinden. Der Container ist die niedrigste Laufzeitstufe, die instanziiert werden kann. Die SA-bewusstes Container-Komponente zielt derzeit auf eine Java Virtual Machine (JVM) pro JSR139 ab.[29][2]
Serviceeinheit

Die grundlegende Planungseinheit in OpenSAF ist eine Service Unit (SU). Ein SU ist eine Gruppierung von Komponenten. Eine SU besteht aus einer oder mehreren Komponenten, die garantiert auf demselben Knoten co-loced werden. SUS wird standardmäßig keine IP -Adressen zugewiesen, kann jedoch eine Komponente enthalten, die dies tut. Eine SU kann mithilfe einer Objektadresse administrativ verwaltet werden. AMFND überwacht den Zustand von SUS und falls nicht im gewünschten Zustand, falls nach Möglichkeit den gleichen Knoten anwenden. AMFD kann den SU auf einem anderen Knoten starten, wenn dies vom Redundanzmodell erforderlich ist.[2] Ein SU kann ein Volumen wie ein lokales Festplattenverzeichnis oder eine Netzwerkscheibe definieren und den Komponenten in der Su. [39] SU kann über die AMF -CLI administrativ verwaltet werden, oder das Management kann an AMF delegiert werden. Solche Bände sind auch die Grundlage für die anhaltende Lagerung.[2][16]
Servicegruppe
Der Zweck einer Servicegruppe besteht darin, zu einem bestimmten Zeitpunkt eine stabile Reihe von Replik -SU -Läufen aufrechtzuerhalten. Es kann verwendet werden, um die Verfügbarkeit einer bestimmten Anzahl identischer SU zu garantieren, die auf ausgewähltem konfiguriertem Redundanzmodell basiert: N-Way, N-Way-Active, 2N, N+M oder 'No-Redundancy'. Der SG ist ein Gruppierungsmechanismus, mit dem OpenSAF die Anzahl der für ein gegebenen SG deklarierten Fälle beibehalten. Die Definition eines SG identifiziert alle zugeordneten SU und ihren Zustand (aktiv, Standby, fehlgeschlagen).[2][16]
Serviceinstanz
Ein OpenSAF Serviceinstanz (SI) ist eine Reihe von SU, die zusammenarbeiten, wie z. B. eine Stufe einer mehrstufigen Anwendung. Der Satz von SU, der einen Dienst schützt, wird durch die SG definiert. Multi-Instance SG (N-Way-Active, N-Way, N+M) erfordert eine stabile IP-Adresse, einen DNS-Namen und einen Lastballer Die SU wird von Maschine zu Maschine bewegen). Standardmäßig wird ein Dienst in einem Cluster freigelegt (z. B. SU [typea] in einem SG mit Anfragen aus dem SU [TypB] -Last ausgeglichen), aber der Service kann auch außerhalb eines Clusters freigelegt werden (z. B. für Kunden, um Front-End Sus) zu erreichen.[2][16]
Bände
Dateisysteme, die OpenSAF SUs verfügbar sind, sind standardmäßig kurzlebiger Speicher. Wenn der Knoten zerstört/nachgebaut wird, gehen die Daten an diesem Knoten verloren. Eine Lösung ist ein freigegebenes Netzwerkdateisystem (NFS), der für alle Nutzlastknoten zugänglich ist.[30] Weitere technische Lösungen sind möglich - wichtig ist, dass Volumes (Dateifreigabe, Mountspunkt) in AMF modelliert werden können. Hoch verfügbare Bände bieten eine anhaltende Speicherung, die für die Lebensdauer des SU selbst vorhanden ist. Dieser Speicher kann auch als gemeinsamer Speicherplatz für SU innerhalb des SG verwendet werden. Volumina, die an bestimmten Mountspunkten auf dem Knoten montiert sind, sind im Besitz eines bestimmten SG, sodass die Instanz nicht mit demselben Dateisystemmontagepunkt mit einem anderen SG geteilt werden kann.
Die Architektur
Die OpenSAF -Architektur wird verteilt und wird in einer Gruppe logischer Knoten ausgeführt. Alle OpenSAF-Dienste verfügen entweder über eine 3-stufige oder zweistufige Architektur. In der dreistufigen Architektur werden OpenSAF-Dienste in einen Dienstdirektor, einen Service-Knoten-Regisseur und einen Agenten unterteilt. Der Direktor ist Teil eines OpenSAF -Dienstes mit Central Service Intelligence. In der Regel handelt es sich um einen Prozess auf dem Controller -Knoten. Die Node Directors koordinieren den Node Scoped Service-Aktivitäten wie Messaging mit seinem zentralen Direktor und seinen lokalen Agenten. Der Agent bietet Kunden als (gemeinsam genutzte) verknüpfbare Bibliothek, die genau definierte Service-APIs für Bewerbungsprozesse ausgesetzt sind, Servicefunktionen zur Verfügung. Agenten sprechen normalerweise mit ihren Serviceknotendirektoren oder Servern. Die OpenSAF -Dienste werden modular wie unten klassifiziert[22]
- Kerndienste - AMF, CLM, Imm, Log, NTF
- Optionale Dienste - EVT, CKPT, LCK, MSG, PLM, SMF
Die optionalen Dienste können während der Erstellung/Verpackung von OpenSAF aktiviert oder deaktiviert werden. OpenSAF kann so konfiguriert werden, dass TCP oder TIPC als zugrunde liegender Transport verwendet werden. Knoten können zum Laufzeit dynamisch hinzugefügt/gelöscht werden. OpenSAF -Cluster skaliert mehrere hundert Knoten. OpenSAF unterstützt die folgenden Sprachbindungen für die AIS -Schnittstellen -APIs:
- C/C ++
- Java -Bindungen (für AMF- und CLM -Dienste)
- Python -Bindungen
- OpenSAF bietet Befehlszeilen-Tools und -versorger für die Verwaltung des OpenSAF-Clusters und der Anwendungen.
Die modulare Architektur ermöglicht das Hinzufügen neuer Dienste sowie die Anpassung der vorhandenen Dienste. Alle OpenSAF-Dienste sind so konzipiert, dass sie Upgrades für den Service unterstützen.
Dienstleistungen
Die AIS -Dienste des folgenden SA -Forums werden von OpenSAF 5.0 implementiert.[23]
- Verfügbarkeitsmanagement Framework (AMF) - oben beschrieben.
- Cluster -Mitgliedsdienst (CLM) - bestimmt, ob ein Knoten gesund genug ist, um Teil des Clusters zu sein. Bietet einen Mechanismus, um die Clusterknoten zu verfolgen, indem Sie mit PLM interagieren, um den Status der zugrunde liegenden OS/Hardware zu verfolgen.
- Checkpoint Service (CKPT) - zum Speichern von Anwendungszuständen und inkrementellen Updates, mit denen der Service während des Failovers oder der Umstellung wiederhergestellt werden kann.
- Event Service (EVT)-Bietet ein Messaging-Modell für Publish-Subscribe, mit dem Anwendungen und Verwaltungseinheiten synchronisiert werden können, um Ereignisse im Cluster aufzunehmen.
- Informationsmodellverwaltungsdienst (IMM) - oben beschrieben.
- Lock Service (LCK) - Unterstützt ein verteiltes Lock -Service -Modell mit Unterstützung für gemeinsam genutzte Sperren und exklusiven Schlösser.
- Log Service (Log) - Mittel zum Aufzeichnen (in Protokolldateien) Die funktionalen Änderungen im Cluster mit Unterstützung für die Protokollierung in verschiedenen Protokolldatensatzformaten. Nicht zum Debuggen oder Fehlerverfolgung. Unterstützt die Protokollierung von Alarmen und Benachrichtigungen, die im Cluster auftreten.
- Messaging Service (MSG)-Unterstützt Cluster-Wide Messaging-Mechanismus bei mehreren Absendern-Einzelempfänger sowie Messing-Gruppen-Mechanismen.
- Benachrichtigungsdienst (NTF) - Bietet ein Hersteller-/Teilnehmermodell für Systemverwaltungsbenachrichtigungen, um die Fehlerbehandlung zu ermöglichen. Wird für Alarm- und Fehlerbenachrichtigungen mit Unterstützung für die Aufzeichnungsverlauf für die Fehleranalyse verwendet. Unterstützt die Benachrichtigungsformate von ITU-T X.730, X.731, X.733, X.736 Empfehlungen.
- Plattform Management Service (PLM) - Bietet einen Mechanismus zur Konfiguration einer logischen Ansicht der zugrunde liegenden Hardware (FRU) und des Betriebssystems. Bietet einen Mechanismus, um den Status des Betriebssystems, die Hardware (FRU), die Verwaltungsvorgänge in Abstimmung mit den OpenSAF -Diensten und -anwendungen durchzuführen.
- Software Management Framework (SMF)-Unterstützung für ein automatisiertes In-Service-Upgrade von Anwendung, Middleware und Betriebssystem im gesamten Cluster.
Unterstützer
Anbieter von Netzwerkgeräten werden die Hauptnutzer von Produkten sein, die auf der OpenSAF -Code -Basis basieren und sie in ihre Produkte für Netzwerkdienstleister, Spediteure und Betreiber integrieren. Viele Anbieter von Netzwerkgeräten haben ihre Unterstützung für OpenSAF gezeigt, indem sie sich der Stiftung anschließen und/oder zum Open -Source -Projekt beigetragen haben. Die aktuellen Foundation -Mitglieder umfassen: Ericsson, HP, und Orakel. Mehrere Anbieter von Computer- und Kommunikationstechnologie haben auch die Unterstützung für die OpenSAF-Initiative angezeigt, darunter Openclovis Safplus, Emerson-Netzwerkleistung eingebettetes Computer, kontinuierliches Computer, Wind River, IP-Infusion, Tail-F, Aricent, Rancore-Technologien, Goahead-Software und Montavista-Software .
Verwendet
OpenSAF wird üblicherweise verwendet, um die Verfügbarkeit von Dienstleistungsverfügbarkeit (Fünf-neuner-Dienstleistungen) zu erreichen. OpenSAF ist funktionell vollständig abgeschlossen, fehlt jedoch das Ökosystem von Modellierungswerkzeugen, die anderen Open-Source-Lösungen wie möglich zur Verfügung stehen Kubernetes und Docker Schwarm.
Siehe auch
- Saforum
- Scope Alliance
- OpenHPI
- Liste der Cluster -Verwaltungssoftware
- Cloud Native Computing Foundation
Verweise
- ^ "Openensaf/über". SourceForge. Archiviert vom Original am 2015-05-11. Abgerufen 2020-12-28.
- ^ a b c d e f g h i j k l m n o p q r s Maria Toeroe; Francis Tam (2012). Verfügbarkeit von Service: Grundsätze und Praxis. John Wiley & Sons. ISBN 978-1-1199-4167-5.
- ^ "Openensaf Readme". SourceForge. Archiviert vom Original am 2020-12-28. Abgerufen 2020-12-28.
- ^ "Openensaf". OpenSAF. Abgerufen 2020-12-28.
- ^ "Fehlertolerante Behälter mit Nilicon" (PDF). UCLA. Archiviert (PDF) vom Original am 2020-12-29. Abgerufen 2020-12-28.
- ^ a b Carolyn Mathas. "OpenSAF -Projekt". Eetimes. Archiviert vom Original am 2020-08-27. Abgerufen 2020-12-28.
- ^ Ed News Staff (2007). "Branchenführer, um Konsortium für OpenSAF -Projekt zu gründen". Archiviert vom Original am 2020-12-29.
- ^ OpenSAF Foundation (2010). "Goahead -Software beiträgt OpenSAF (TM) bei". Archiviert vom Original am 2020-12-29.
- ^ Cook (2007). "Motorola startet Open-Source-Betriebsumgebung mit hoher Verfügbarkeit". Archiviert vom Original am 2020-12-29.
- ^ OpenSAF Foundation (2010). "OpenSAF im kommerziellen Einsatz". Archiviert vom Original am 2018-06-25.
- ^ Madhusanka Liyanage; Andrei Gurtov; Mika Ylianttila (2015). Software Defined Mobile Networks (SDMN): Jenseits der LTE -Netzwerkarchitektur. John Wiley & Sons, Ltd. doi:10.1002/9781118900253. ISBN 9781118900253.
- ^ Yanal Alahmad; Tariq Daradkeh; Anjali Agarwal (2018). "Verfügbarkeitsbewusste Containerplaner für Anwendungsdienste in Cloud". 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 als Verfügbarkeitsmanager für Microservice -Anwendungen". Journal of Network- und Computeranwendungen. Arxiv:1901.04946. Abgerufen 2020-12-28.
- ^ a b "OpenSAF veröffentlicht 2.0". Leuchtgrundstück. Archiviert vom Original am 15. August 2020. Abgerufen 29. Dezember 2020.
- ^ "Open Source Carrier Grade Linux Middleware Rev'd (LinuxDevices)". Lwn. Archiviert vom Original am 2014-09-17. Abgerufen 29. Dezember 2020.
- ^ a b c d e f g h i "OpenSAF Release 4 -Übersicht" Die Architekturveröffentlichung "" (PDF). OpenSAF. Archiviert (PDF) vom Original am 29. Dezember 2020. Abgerufen 29. Dezember 2020.
- ^ Hans J. Rauscher. "OpenSAF 3.0 veröffentlicht". Windriver. Archiviert vom Original am 2020-06-29. Abgerufen 30. Dezember 2020.
- ^ "OpenSAF -Projekt veröffentlicht ein großes Update für Middleware mit hoher Verfügbarkeit". Picmg. Archiviert vom Original am 2020-12-31. Abgerufen 30. Dezember 2020.
- ^ "Ankündigung von 5.0.0 Ga -Veröffentlichung und 4.7.1, 4,6.2 Wartung veröffentlicht". SourceForge. Archiviert vom Original am 2020-12-31. Abgerufen 30. Dezember 2020.
- ^ a b c SA Forum (2010). "SAI-AIS-AMF-B.04.01 Abschnitt 3.6" (PDF). OpenSAF. Abgerufen 20. Dezember 2020.
{{}}
: CS1 Wartung: URL-Status (Link) - ^ Anders Widell; Mathivanan NP (2012). "OpenSAF in der Cloud. Warum eine HA -Middleware noch benötigt wird" (PDF). LinuxFoundation -Ereignisse. Abgerufen 24. September 2015.
{{}}
: CS1 Wartung: URL-Status (Link) - ^ a b Jon Paul Maloy (2004). "TIPC: Bereitstellung von Kommunikation für Linux -Cluster" (PDF). Linux kernel.org. Linux Symposium, Volumen zwei. Archiviert (PDF) vom Original am 2017-08-30. Abgerufen 31. Dezember 2020.
- ^ a b c d OpenSAF TSC (2016). "Openensaf". OPNFV. Archiviert vom Original am 2020-12-31. Abgerufen 2020-12-28.
- ^ a b c OpenSAF -Projekt (2020). "Openensaf Readme". SourceForge. Abgerufen 2020-12-31.
{{}}
: CS1 Wartung: URL-Status (Link) - ^ Maxime Turenne (2015). "Eine neue, domänenspezifische Sprache zum Generieren und Validieren von Middleware -Konfigurationen für hoch verfügbare Anwendungen" (PDF). ETSMTL.CA. Abgerufen 2020-12-28.
{{}}
: CS1 Wartung: URL-Status (Link) - ^ Pejman Salehi;Abdelwahab Hamou-Lhadj;Maria Toeroe;Ferhat Khendek (2016). "Eine UML-basierte domänenspezifische Modellierungssprache für das Management der Serviceverfügbarkeit" ". doi.Elsevier Science Publishers B. V. Computer Standards & Interfaces, Vol.44, Nr. C. C. doi:10.1016/j.csi.2015.09.009. Abgerufen 2020-12-28.
{{}}
: CS1 Wartung: URL-Status (Link) - ^ OPNFV HA -Projekt (2016). "Szenarioanalyse für hohe Verfügbarkeit in NFV, Abschnitt 5.4.2" (PDF). OPNFV. Archiviert (PDF) vom Original am 2020-12-31. Abgerufen 2020-12-31.
- ^ OpenSAF -Projekt (2020). "OpenSAF Imm Readme". SourceForge. Archiviert vom Original am 2020-12-31. Abgerufen 2020-12-31.
- ^ Jens Jensen; Expertengruppe (2010). "JSR 319: Verfügbarkeitsmanagement für Java". JCP. Archiviert vom Original am 2017-07-10. Abgerufen 2020-12-31.
- ^ Ferhat Khendek (2013). "OpenSAF und VMware aus der Perspektive der hohen Verfügbarkeit" (PDF). DMTF. Archiviert (PDF) vom Original am 2015-09-03. Abgerufen 2020-12-31.
Externe Links
- Offizielle Website
- OpenSAF an SourceForge
- SA Forum Bei der Wayback -Maschine (Archiviert 2008-10-06)