OpenSAF

OpenSAF
OpenSAF
Opensaf-logo-full 02.png
원저작자모토로라
개발자OpenSAF 재단
초기 릴리즈2007년 6월 31일; 15년 전(2007-06-31)
안정된 릴리스
5.21.03 / 2021년 3월 1일; 17개월 전(2021-03-01)
저장소
기입처C++
유형클러스터 관리 소프트웨어
웹 사이트opensaf.소스 포지로 이동합니다.이오 Edit this at Wikidata

OpenSAF(일반 SAF, Service Availability[1] Framework)는 컴퓨터 응용 프로그램의 도입, 확장 및 관리를 자동화하기 위한 오픈소스 서비스 오케스트레이션시스템입니다OpenSAF는 Service Availability Forum(SAF; Service Availability Forum) [2]및 SCOPE Alliance 표준에 부합하며 이를 기반으로 확장됩니다.

원래 Motorola ECC에 의해 설계되었으며 OpenSAF 프로젝트에 [3]의해 관리되고 있습니다.OpenSAF는 SAF AIS 사양의 가장 완전한 구현으로 호스트의 클러스터 [4]간에 애플리케이션서비스의 전개, 스케일링 및 운용을 자동화하는 플랫폼을 제공합니다.다양한 가상화 툴에서 작동하며 클러스터에서 서비스를 실행하며 JVM, Vagrant 및/또는 Docker 런타임과 통합되는 경우가 많습니다.OpenSAF는 원래 표준 C Application Programming Interface(API; 응용 프로그램프로그래밍 인터페이스)와 인터페이스했지만 Java [2]및 Python 바인딩이 추가되었습니다.

OpenSAF는 고가용성(HA) 요건을 넘어 서비스 가용성에 초점을 맞추고 있습니다.컨테이너 및 [5]클라우드의 고가용성(HA) 및 내결함성 기술을 개선하기 위한 공식적인 연구는 거의 발표되지 않았지만, 연구 그룹은 OpenSAF를 통해 이러한 과제를 적극적으로 탐색하고 있습니다.

역사

서비스 가용성, 원칙 및 프랙티스, 교재

OpenSAF는 Ericsson, HP 및 Nokia Siemens Networks를 포함한 업계 컨소시엄에 의해 설립되었으며 [6]2007년 2월 28일 Emerson Network Power에 의해 인수된 Motorola ECC에 의해 처음 발표되었습니다.OpenSAF Foundation은 2008년 1월 22일 공식적으로 출범했습니다.멤버십에는 Emerson Network Power, SUN Microsystems, ENEA, Wind River, Huawei, IP Infusion, Tail-f, Aricent, GoAhead Software 및 Rancore [2][7]Technologies가 포함됩니다.GoAhead Software는 Oracle에 [8]인수되기 전인 2010년에 OpenSAF에 가입했습니다.OpenSAF의 개발과 설계는 Carrier Grade Linux, SAF, ATCA 및 하드웨어 플랫폼 인터페이스 등의 미션 크리티컬 시스템 요건에 크게 영향을 받습니다.OpenSAF는 통신 및 임베디드 시스템에서 [9]Linux의 채택을 가속화하는 이정표였습니다.

Foundation의 목표는 상용 제품에 OpenSAF의 채택을 가속화하는 것이었습니다.OpenSAF 커뮤니티는 2008~2010년 독일 뮌헨에서 Nokia Siemens Networks가 주최한 첫 번째 컨퍼런스를 개최했으며, 중국 선전(Shenzhen)에서 두 번째, 미국 팔로알토(Palo Alto)에서 HP가 주최한 세 번째 컨퍼런스를 개최했습니다.2010년 2월에는 통신사업자 네트워크에서의 OpenSAF의 첫 상용 도입이 [10]발표되었습니다.학계 및 업계 그룹은 OpenSAF 기반 [2][11]솔루션을 설명하는 책을 독자적으로 출판했습니다.서비스 가용성에 대한 연구가 증가함에 따라 미션 크리티컬 클라우드 및 마이크로 서비스 구현 및 서비스 [12][13]조정을 지원하는 OpenSAF 기능의 개발이 가속화되고 있습니다.

OpenSAF 1.0은 2008년1월 22일에 출시되었습니다.Motorola [14]ECC가 제공하는 NetPlane Core Service(NCS) 코드 베이스로 구성되어 있습니다.OpenSAF 1.0 릴리즈와 함께 OpenSAF 기반은 [6]제외되었습니다.2008년 8월 12일에 출시된 OpenSAF 2.0은 OpenSAF 커뮤니티에 의해 개발된 첫 번째 릴리스입니다.이 릴리스에는 로그 서비스와 64비트 [14]지원이 포함되어 있습니다.2009년 6월 17일에 출시된 OpenSAF 3.0에는 플랫폼 관리, 가용성 향상 및 Java API [15]지원이 포함되어 있습니다.

OpenSAF 4.0은 2010년 [2]7월의 획기적인 릴리스입니다."아키텍처 릴리스"라는 별명을 가진 이 릴리스는 기능 격차 해소, 내부 아키텍처 정착, 인서비스 업그레이드 활성화, API 명확화 및 모듈화 [16]개선 등 중요한 변화를 도입했습니다.OpenSAF는 업계와 학계의 큰 관심을 받아 2011년에 보스턴 MA의 MIT University가 주최한 커뮤니티 컨퍼런스와 스톡홀름의 Ericsson이 주최한 커뮤니티 컨퍼런스를 2회 개최했습니다.

릴리스 이력
버전 발매일 메모들
이전 버전, 더 이상 유지 보수되지 않음 2008년 1월 22일 Motorola ECC가 OpenSAF 프로젝트에 제공한 NetPlane Core Service(NCS) 코드베이스의 원래 코드베이스.
이전 버전, 유지 보수 불필요: 2.0 2008년 8월 12일
이전 버전, 유지 보수 불필요: 3.0 2009년 6월 17일 두 번째 릴리스(v2.0 이후 계산)는 윈드 리버 [17]시스템의 기여로 약 1.5년이 걸렸다.
이전 버전, 유지 보수 불필요: 4.0 2010년 7월 1일 「아키텍처」릴리즈실행 가능한 최초의 캐리어 그레이드 [18]도입 후보.
이전 버전이지만 유지 보수: 4.2 2012년 3월 16일 관리 용이성 향상, 가용성 모델링 강화.
이전 버전이지만 유지 보수: 5.0 2016년 5월 5일 중요한 릴리스입니다.스페어 시스템 컨트롤러(2N + 스페어), 헤드리스 클러스터(클라우드 복원성), 확장 Python 바인딩, 노드 이름 [19]로깅 지원.
현재 안정적인 버전: 5.20 2021년 6월 1일
범례:
구버전
이전 버전, 아직 유지 관리됨
최신 버전
최신 프리뷰 버전
향후 출시

개념

OpenSAF v4 아키텍처

OpenSAF는 일련의 구성 요소를 정의하며 리소스 기능 [20]모델을 기반으로 애플리케이션의 Service Availability(SA; 서비스 가용성)를 관리하는 메커니즘을 집합적으로 제공합니다.SA 및 고가용성(HA)은 임의의 시점에서 서비스를 이용할 수 있는 확률입니다.미션 크리티컬 시스템에서는 99.999% 이상의 가용성이 필요합니다.HA와 SA는 기본적으로 동일하지만 SA는 한 단계 더 나아갑니다(즉, 하드웨어와 소프트웨어의 [21]인서비스 업그레이드).OpenSAF는 노드 간(예: TIPC/TCP [22]사용) 상호 연결이 빠른 느슨한 결합 시스템을 위해 설계되었으며 서로 다른 워크로드를 충족하도록 확장 가능합니다. 구성 요소는 모든 프로토콜을 사용하여 서로 통신합니다.이 확장성은 내부 컴포넌트와 핵심 서비스에서 사용되는 IMM API에 의해 대부분 제공됩니다.플랫폼은 오브젝트로 정의하고 (컴포넌트 서비스)인스턴스 및 [2][20][23]노드 제약으로 관리함으로써 컴퓨팅 리소스와 스토리지 리소스를 제어할 수 있습니다.

OpenSAF 소프트웨어는 프라이머리/레플리카 아키텍처에 따라 기본적으로 배포됩니다.'OpenSAF' 클러스터에는 개별 노드와 컨트롤 플레인을 관리하는 노드로 나눌 수 있는2종류의 노드가 있습니다.1개의 시스템 컨트롤러는 "액티브" 모드로 동작하고, 다른 1개의 시스템컨트롤러는 "스탠바이" 모드로 동작합니다.또한 장애가 발생했을 경우 액티브 또는 스탠바이 역할을 인계할 수 있는 예비 컨트롤러가 있습니다.노드는 제어부 없이 헤드리스로 실행되므로 클라우드 복원력을 [16][24]높일 수 있습니다.

시스템 모델

시스템 설계자에게는 더 나은 모델링 도구가 필요합니다.

OpenSAF 시스템 모델은 OpenSAF가 요청을 처리 및 검증하고 AMF 모델의 객체 상태를 업데이트하여 작업자/페이로드 노드 간에 워크로드 및 서비스 그룹을 스케줄링할 수 있도록 하는 핵심 Enabler API입니다.AMF 동작은 설정 개체를 통해 변경됩니다.[24]서비스는 'No Redundancy', 2N, N+M, N-way 및 N-way Active 용장성 [20]모델을 사용할 수 있습니다.OpenSAF에는 AMF 구성 모델의 설계 및 생성을 단순화하는 명확한 모델링 툴체인이 없습니다.이러한 [25][26]격차를 해소하기 위한 지속적인 연구가 필요하며, 에코시스템 툴을 제공하여 통신사급 및 Cloud Native Computing Foundation 사용 사례의 모델링 및 자동화를 보다 효과적으로 지원해야 합니다.

컨트롤 플레인

OpenSAF 시스템 컨트롤러(SC)는 클러스터의 주요 제어 유닛으로 워크로드를 관리하고 시스템 간의 통신을 유도합니다.OpenSAF 컨트롤 플레인은 다양한 컴포넌트(각 프로세스)로 구성되어 있습니다.각 컴포넌트는 단일 SC 노드 또는 여러 SC 노드에서 모두 실행 가능하며 고가용성 클러스터와 서비스 [2][24]가용성을 지원합니다.OpenSAF 컨트롤 플레인의 다양한 컴포넌트는 다음과 같습니다.

  • IMM(Information Model Manager)은 클러스터의 구성 데이터를 안정적으로 저장하는 영구 데이터 저장소이며, 언제든지 클러스터의 전체 상태를 나타냅니다.미들웨어 및 응용 프로그램 구성 및 상태 정보를 관리 대상 개체 및 해당 [23]속성의 형태로 정의 및 관리하는 수단을 제공합니다.IMM은 모든 노드에서 데이터를 복제하는 인메모리 데이터베이스로 구현됩니다.IMM은 SQLite를 영구 백엔드로 사용할 수 있습니다.Apache ZooKeeper와 마찬가지로 IMM은 가용성/성능보다 구성 데이터의 트랜잭션 수준의 일관성을 보장합니다(CAP [2][23][27]정리 참조).IMM 서비스는 IMM Director(IMMD), IMM Node Director(IMMND) 및 IMM Agent Library(IMMA)로 구성된 3계층 OpenSAF "Service Director" 프레임워크를 따릅니다.IMMD는 2N 용장성 모델을 사용하여 컨트롤러에 데몬으로 구현됩니다.액티브컨트롤러 인스턴스는 "프라이머리 레플리카", 스탠바이 컨트롤러 인스턴스는 메시지 기반 체크포인트 서비스에 의해 최신 상태로 유지됩니다.IMMD는 (MDS를 사용하여) 클러스터 멤버십을 추적하고 모든 OpenSAF [28][2]서비스에 대해 데이터스토어 액세스컨트롤 및 관리 인터페이스를 제공합니다.
  • Availability Management Framework(AMF; 가용성 관리 프레임워크)는 완전한 장애 관리 라이프 사이클(검출, 분리, 복구, 복구 및 알림)에 대한 강력한 지원(다른 AIS 서비스와 연계)을 통해 고가용성 및 워크로드 관리 프레임워크를 제공합니다.AMF는 디렉터(AmfD), 노드 디렉터(AmfND) 및 에이전트(AmfA) 및 AmfND 보호를 위한 내부 워치독으로 구성된 3계층 OpenSAF "Service Director"에 따릅니다.액티브 AmfD 서비스는 시스템/클러스터 범위 전체에서 IMM에서 유지되는 서비스 구성을 실현하는 역할을 합니다.노드 디렉터는 [2]범위 내의 모든 컴포넌트에 대해 동일한 기능을 수행합니다.모든 컴포넌트에 걸쳐 주요 정보 및 API 브리지 역할을 함으로써 상태 모델이 일치하도록 합니다.AMF는 IMM 상태를 감시하고 구성 변경을 적용하거나 장애 관리 에스컬레이션 정책을 사용하여 원하는 [16]구성 생성을 스케줄링하여 원하는 구성으로 되돌리기만 하면 됩니다.
  • AMF Director(AMFD)는 일정되지 않은 서비스 그룹(용장 서비스 인스턴스)이 실행되는 노드를 결정하는 스케줄러입니다.이 결정은 현재 v.s.에 기초하고 있습니다.가용성 및 기능 모델, 서비스 용장성 모델 및 QoS, 어피니티/반선호도 등의 제약 조건을 "확장"할 수 있습니다.AMF 디렉터는 자원 "supply"를 워크로드 "demand"에 매칭하여 IMM 시스템 [2][16]객체를 통해 그 동작을 조작할 수 있습니다.

요소

컴포넌트는 AMF 시스템 모델의 논리 엔티티로 프로세스, 드라이버, 스토리지 등의 컴퓨팅 자원의 정규화된 뷰를 나타냅니다.컴포넌트는 장애 상호의존성에 따라 논리 서비스 유닛(SU)으로 그룹화되어 노드에 관련지어집니다.SU는 AMF 용장성 모델(액티브, 스탠바이 또는 장애 상태)에 의해 제어되는 순간적인 워크로드 단위입니다.같은 유형의 SU는 특정 용장성 모델링 특성을 나타내는 Service Group(SG; 서비스 그룹)으로 그룹화됩니다.SG 내의 SU는 Service Instance(SI; 서비스인스턴스)에 할당되어 active 또는 standby의 가용성 상태가 됩니다.SI는 AMF에 [2][16]의해 보호되는 확장 가능한 다중 논리 서비스입니다.

노드

노드는 서비스 인스턴스(워크로드)가 구현되는 컴퓨팅 인스턴스(블레이드, 하이퍼바이저 또는 VM)입니다.같은 통신 서브넷(루팅 없음)에 속하는 노드 세트가 논리 클러스터를 구성합니다.클러스터 내의 모든 노드는 서비스 및 다음에 나열된 OpenSAF 서비스에 대한 실행 환경을 실행해야 합니다.

  • 노드 디렉터(AmfND):AmfND는 각 노드의 실행 상태를 책임지고 해당 노드의 모든 활성 SU가 정상임을 확인합니다.컨트롤 플레인의 지시에 따라 CSI 또는 SU를 SG로 편성하여 기동, 정지 및 유지보수를 수행합니다.AmfND 서비스는 IMM에서 유지되는 원하는 AMF 설정을 노드에 적용합니다.노드 장애가 검출되면 디렉터(AmfD)는 이 상태 변화를 감시하고 다른 적격 정상 [2][16]노드에서 서비스 유닛을 실행합니다.
  • 비SA-Aware 컴포넌트: OpenSAF는 AMF [2]모델에서 컴포넌트 및 서비스 라이프 사이클 명령(시작/정지/상태 체크)을 모델링함으로써 클라우드 컴퓨팅, 컨테이너화, 가상화 및 JVM 도메인에서 발생하는 인스턴스화 가능한 컴포넌트에 HA(SA는 아님)를 제공할 수 있습니다.
  • 컨테이너 포함:AMF 컨테이너 포함은 SU 내에 존재할 수 있습니다.컨테이너 포함은 인스턴스화할 수 있는 최저 수준의 런타임입니다.SA-Aware 컨테이너 포함 구성 요소는 현재 JSR139마다 [29][2]Java Virtual Machine(JVM; Java 가상 머신)을 대상으로 합니다.

서비스 유닛

OpenSAF 개념

OpenSAF의 기본 스케줄링 유닛은 Service Unit(SU; 서비스 유닛)입니다.SU는 컴포넌트의 그룹입니다.SU는 같은 노드에 공존할 수 있는1개 이상의 컴포넌트로 구성됩니다.SU에는 디폴트로 IP 주소가 할당되어 있지 않지만 할당되어 있는 컴포넌트가 포함되어 있는 경우가 있습니다.SU는 오브젝트 주소를 사용하여 관리 가능합니다.AmfND는 SU의 상태를 감시합니다.필요한 상태가 아닐 경우 가능하면 같은 노드에 다시 전개합니다.AmfD는 용장성 [2]모델에서 필요한 경우 다른 노드에서 SU를 시작할 수 있습니다.SU는 로컬 디스크 디렉토리나 네트워크 디스크 등의 볼륨을 정의하여 SU의 컴포넌트에 표시할 수 있습니다.[39] SU는 AMF CLI를 통해 관리 관리하거나 AMF에 관리를 위임할 수 있습니다.또한 이러한 볼륨은 영속적인 [2][16]스토리지의 기반이 됩니다.

서비스 그룹

서비스 그룹의 목적은 항상 실행되고 있는 복제 SU의 안정적인 세트를 유지하는 것입니다.N-Way, N-way-Active, 2N, N+M, 또는 「No-Redundancy」의 선택된 설정 용장 모델에 근거해, 같은 SU 의 지정수의 가용성을 보증하기 위해서 사용할 수 있습니다.SG는 OpenSAF가 특정 SG에 대해 선언된 인스턴스 수를 유지할 수 있는 그룹화 메커니즘입니다.SG의 정의는 관련된 모든 SU와 그 상태(active, standby, failed)[2][16]를 식별합니다.

서비스 인스턴스

OpenSAF Service Instance(SI; 서비스인스턴스)는 여러 계층의 응용 프로그램의 1개 계층과 같이 함께 작동하는 SU 세트입니다.서비스를 보호하는 SU 집합은 SG에 의해 정의됩니다. 다중 인스턴스 SG(N-way-Active, N-way, N+M)를 사용하려면 해당 SG의 활성 SU 간에 해당 IP 주소의 트래픽을 분산하려면 안정적인 IP 주소, DNS 이름 및 로드 밸런서가 필요합니다(장애로 인해 SU가 시스템에서 시스템으로 이동하는 경우에도).디폴트로는 서비스는 클러스터 내에서 공개됩니다(예를 들어 SU[TypeA]는 1개의 SG로 그룹화되어 SU[TypeB]로부터의 요구가 그 사이에서 로드밸런싱됩니다).그러나 서비스는 클러스터 외부에서도 공개될 수 있습니다(예를 들어 클라이언트가 프런트 엔드 SU에 [2][16]도달하는 경우).

볼륨

OpenSAF SU에서 사용할 수 있는 파일 시스템은 기본적으로 사용 후 삭제 저장소가 될 수 있습니다.노드가 파괴/재작성되면 해당 노드에서 데이터가 손실됩니다.하나의 솔루션은 모든 페이로드 노드에서 [30]액세스할 수 있는 NFS(Network File System) 공유 스토리지입니다.다른 기술적인 솔루션도 가능합니다.중요한 것은 볼륨(파일 공유, 마운트 포인트)을 AMF로 모델링할 수 있다는 것입니다.고가용성이 뛰어난 볼륨은 SU 자체의 수명 동안 지속되는 스토리지를 제공합니다.이 스토리지는 SG 내의 SU의 공유 디스크 공간으로 사용할 수도 있습니다.노드의 특정 마운트 지점에 마운트된 볼륨은 특정 SG가 소유하므로 동일한 파일 시스템 마운트 지점을 사용하여 인스턴스를 다른 SG와 공유할 수 없습니다.

아키텍처

OpenSAF 아키텍처는 논리 노드의 클러스터 내에서 분산되어 실행됩니다.모든 OpenSAF 서비스는 3-Tier 또는 2-Tier 아키텍처를 사용합니다.3계층 아키텍처에서는 OpenSAF 서비스는 서비스 디렉터, 서비스 노드 디렉터 및 에이전트로 분할됩니다.디렉터는 중앙 서비스 인텔리전스를 갖춘 OpenSAF 서비스의 일부입니다.일반적으로 컨트롤러 노드상의 프로세스입니다.노드 디렉터는 중앙 디렉터 및 로컬에이전트와의 메시징 등의 서비스 액티비티를 조정합니다.에이전트는 (공유) 링크 가능 라이브러리를 통해 클라이언트가 이용할 수 있는 서비스 기능을 제공합니다.이 라이브러리는 적절하게 정의된 서비스 API를 응용 프로그램프로세스에 제공합니다.에이전트는 일반적으로 서비스 노드 디렉터 또는 서버와 대화합니다.OpenSAF 서비스는 모듈식으로 다음과[22] 같이 분류됩니다.

  • 핵심 서비스 – AMF, CLM, IMM, LOG, NTF
  • 옵션 서비스 – EVT, CKPT, LCK, MSG, PLM, SMF

옵션 서비스는 OpenSAF 빌드/패키징 중에 활성화 또는 비활성화할 수 있습니다.OpenSAF는 TCP 또는 TIPC를 기본 전송으로 사용하도록 설정할 수 있습니다.실행 시 OpenSAF 클러스터 간에 노드를 동적으로 추가/삭제할 수 있습니다.OpenSAF 클러스터는 수백 개의 노드를 확장합니다.OpenSAF는 AIS 인터페이스 API에 대해 다음 언어 바인딩을 지원합니다.

  • C/C++
  • Java 바인딩(AMF 및 CLM 서비스용)
  • 파이썬 바인딩
  • OpenSAF는 OpenSAF 클러스터 및 응용 프로그램 관리를 위한 명령줄 도구 및 유틸리티를 제공합니다.

모듈러형 아키텍처는 기존 서비스의 적응뿐만 아니라 새로운 서비스의 추가를 가능하게 합니다.모든 OpenSAF 서비스는 인서비스 업그레이드를 지원하도록 설계되어 있습니다.

서비스

다음 SA Forum의 AIS 서비스는 OpenSAF 5.0에 [23]의해 구현됩니다.

  • 가용성 관리 프레임워크(AMF) - 위에서 설명했습니다.
  • Cluster Membership Service(CLM; 클러스터 멤버십서비스)– 노드가 클러스터의 일부가 될 수 있을 정도로 정상인지 여부를 판별합니다.기본 OS/하드웨어 상태를 추적하기 위해 PLM과 상호 작용하여 클러스터 노드를 추적하는 메커니즘을 제공합니다.
  • Checkpoint Service(CKPT) – 페일오버 또는 스위치 오버 시 서비스 복원에 사용할 수 있는 애플리케이션 상태 및 증분 업데이트를 저장합니다.
  • 이벤트 서비스(EVT) – 클러스터에서 발생하는 이벤트에 대해 애플리케이션 및 관리 엔티티를 동기화하는 데 사용할 수 있는 퍼블리시/서브스크라이브 메시징 모델을 제공합니다.
  • 정보 모델 관리 서비스(IMM) - 위에서 설명했습니다.
  • 잠금 서비스(LCK)– 공유 잠금 및 전용 잠금을 지원하는 분산 잠금 서비스 모델을 지원합니다.
  • 로그 서비스(LOG) – 클러스터에서 발생한 기능 변경을 로그 파일에 기록하는 수단으로 다양한 로그 레코드 형식으로 로깅을 지원합니다.디버깅 또는 오류 추적용이 아닙니다.클러스터에서 발생하는 경보 및 알림 로깅을 지원합니다.
  • 메시징 서비스(MSG) – 여러 송신자를 가진 클러스터 전체의 메시징 메커니즘(단일 수신자 및 메시지 그룹 메커니즘)을 지원합니다.
  • Notification Service(NTF; 알림 서비스): 장애 처리를 활성화하기 위한 시스템 관리 알림의 생산자/가입자 모델을 제공합니다.장애 분석을 위한 기록 기록을 지원하는 알람 및 장애 알림에 사용됩니다.ITU-T X.730, X.731, X.733, X.736 권장사항 알림 형식을 지원합니다.
  • 플랫폼 관리 서비스(PLM)– 기반이 되는 하드웨어(FRU)와 OS의 논리 뷰를 구성하는 메커니즘을 제공합니다.OS, 하드웨어(FRU)의 상태를 추적하고 OpenSAF 서비스 및 애플리케이션과 연계하여 관리 작업을 수행하는 메커니즘을 제공합니다.
  • 소프트웨어 관리 프레임워크(SMF)– 클러스터 전체에서 애플리케이션, 미들웨어 및 OS의 자동 인서비스 업그레이드를 지원합니다.

서포터

Network Equipment Provider는 OpenSAF 코드베이스에 기반한 제품의 프라이머리 사용자가 되며 네트워크 서비스 프로바이더, 캐리어 및 오퍼레이터용 제품에 통합됩니다.많은 네트워크 기기 프로바이더가 재단에 가입하거나 오픈 소스 프로젝트에 기여함으로써 OpenSAF에 대한 지원을 증명하고 있습니다.현재 Foundation 멤버는 다음과 같습니다.Ericsson, HP 및 Oracle.OpenClovis SAFplus, Emerson Network Power Embedded Computing, Continuous Computing, Wind River, IP Infusion, Tail-f, Aricent, Rancore Technologies, GoAhead Software 및 MontaVista 소프트웨어 등의 컴퓨팅 및 통신 테크놀로지 프로바이더도 OpenSAF 이니셔티브를 지원하고 있습니다.

사용하다

OpenSAF는 일반적으로 캐리어 그레이드(5.9%)의 서비스 가용성을 실현하는 방법으로 사용됩니다.OpenSAF는 기능적으로는 완전하지만 Kubernetes 및 Docker Swarm과 같은 다른 오픈 소스 솔루션에서 사용할 수 있는 모델링 툴 생태계가 부족합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "OpenSAF/About". SourceForge. Archived from the original on 2015-05-11. Retrieved 2020-12-28.
  2. ^ a b c d e f g h i j k l m n o p q r s Maria Toeroe; Francis Tam (2012). Service Availability: Principles and Practice. John Wiley & Sons. ISBN 978-1-1199-4167-5.
  3. ^ "OpenSAF Readme". SourceForge. Archived from the original on 2020-12-28. Retrieved 2020-12-28.
  4. ^ "OpenSAF". OpenSAF. Retrieved 2020-12-28.
  5. ^ "Fault-Tolerant Containers Using NiLiCon" (PDF). ucla. Archived (PDF) from the original on 2020-12-29. Retrieved 2020-12-28.
  6. ^ a b Carolyn Mathas. "OpenSAF project". eetimes. Archived from the original on 2020-08-27. Retrieved 2020-12-28.
  7. ^ ED News Staff (2007). "Industry Leaders To Establish Consortium On OpenSAF Project". Archived from the original on 2020-12-29.
  8. ^ OpenSaf Foundation (2010). "GoAhead Software Joins OpenSAF(TM)". Archived from the original on 2020-12-29.
  9. ^ cook (2007). "Motorola launches open-source High Availability Operating Environment". Archived from the original on 2020-12-29.
  10. ^ OpenSAF Foundation (2010). "OpenSAF in Commercial Deployment". Archived from the original on 2018-06-25.
  11. ^ Madhusanka Liyanage; Andrei Gurtov; Mika Ylianttila (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. John Wiley & Sons, Ltd. doi:10.1002/9781118900253. ISBN 9781118900253.
  12. ^ Yanal Alahmad; Tariq Daradkeh; Anjali Agarwal (2018). "Availability-Aware Container Scheduler for Application Services in Cloud". IEEE: 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 as an Availability Manager for Microservice Applications". Journal of Network and Computer Applications. arXiv:1901.04946. Retrieved 2020-12-28.
  14. ^ a b "OpenSAF Releases 2.0". LightReading. Archived from the original on 15 August 2020. Retrieved 29 December 2020.
  15. ^ "Open source Carrier Grade Linux middleware rev'd (LinuxDevices)". LWN. Archived from the original on 2014-09-17. Retrieved 29 December 2020.
  16. ^ a b c d e f g h i "OpenSAF Release 4 Overview "The Architecture Release"" (PDF). OpenSAF. Archived (PDF) from the original on 29 December 2020. Retrieved 29 December 2020.
  17. ^ Hans J. Rauscher. "OpenSAF 3.0 released". WindRiver. Archived from the original on 2020-06-29. Retrieved 30 December 2020.
  18. ^ "OpenSAF Project Releases Major Update to High Availability Middleware". PICMG. Archived from the original on 2020-12-31. Retrieved 30 December 2020.
  19. ^ "Announcement of 5.0.0 GA release and 4.7.1, 4.6.2 maintenance releases". sourceforge. Archived from the original on 2020-12-31. Retrieved 30 December 2020.
  20. ^ a b c SA Forum (2010). "SAI-AIS-AMF-B.04.01 Section 3.6" (PDF). OpenSAF. Retrieved 20 December 2020.{{cite web}}: CS1 maint :url-status (링크)
  21. ^ Anders Widell; Mathivanan NP (2012). "OpenSAF in the Cloud. Why an HA Middleware is still needed" (PDF). Linuxfoundation Events. Retrieved 24 September 2015.{{cite web}}: CS1 maint :url-status (링크)
  22. ^ a b Jon Paul Maloy (2004). "TIPC: Providing Communication for Linux Clusters" (PDF). Linux Kernel.org. Linux Symposium, Volume Two. Archived (PDF) from the original on 2017-08-30. Retrieved 31 December 2020.
  23. ^ a b c d OpenSAF TSC (2016). "Opensaf". OPNFV. Archived from the original on 2020-12-31. Retrieved 2020-12-28.
  24. ^ a b c OpenSAF Project (2020). "OpenSAF README". Sourceforge. Retrieved 2020-12-31.{{cite web}}: CS1 maint :url-status (링크)
  25. ^ Maxime TURENNE (2015). "A NEW DOMAIN SPECIFIC LANGUAGE FOR GENERATING AND VALIDATING MIDDLEWARE CONFIGURATIONS FOR HIGHLY AVAILABLE APPLICATIONS" (PDF). etsmtl.ca. Retrieved 2020-12-28.{{cite web}}: CS1 maint :url-status (링크)
  26. ^ Pejman Salehi; Abdelwahab Hamou-Lhadj; Maria Toeroe; Ferhat Khendek (2016). "A UML-based domain specific modeling language for service availability management". doi. Elsevier Science Publishers B. V. Computer Standards & Interfaces, Vol. 44, No. C. doi:10.1016/j.csi.2015.09.009. Retrieved 2020-12-28.{{cite journal}}: CS1 maint :url-status (링크)
  27. ^ OPNFV HA Project (2016). "Scenario Analysis for High Availability in NFV, Section 5.4.2" (PDF). OPNFV. Archived (PDF) from the original on 2020-12-31. Retrieved 2020-12-31.
  28. ^ OpenSAF Project (2020). "OpenSAF IMM README". Sourceforge. Archived from the original on 2020-12-31. Retrieved 2020-12-31.
  29. ^ Jens Jensen; Expert Group (2010). "JSR 319: Availability Management for Java". JCP. Archived from the original on 2017-07-10. Retrieved 2020-12-31.
  30. ^ Ferhat Khendek (2013). "OpenSAF and VMware from the Perspective of High Availability" (PDF). DMTF. Archived (PDF) from the original on 2015-09-03. Retrieved 2020-12-31.

외부 링크