응용 프로그램 인터페이스 사양
Application Interface Specification |
AIS(Application Interface Specification, Application Interface Specification)는 고가용성 애플리케이션 컴퓨터 소프트웨어에 대한 API(응용 프로그래밍 인터페이스)를 정의하는 개방형 사양의 모음입니다. 서비스 가용성 포럼(SA Forum)에서 개발, 발행하고, 자유롭게 이용할 수 있도록 한다. 이 규격은 고가용성 애플리케이션의 복잡성을 줄이고 개발 시간을 단축하는 것 외에도, 서로 다른 미들웨어 구현 간 애플리케이션의 이식성을 용이하게 하고 제3자 개발자를 과거에 매우 독점적인 분야로 인정하기 위한 것이었다.
역사
AIS는 SA 포럼의 SAI(Service Availability Interface)의 일부다. 2003년 4월 14일에 발표된 원래의 사양은 가용성 관리 프레임워크(AMF), 클러스터 구성원 서비스(CLM), 기타 4개의 유틸리티 서비스(Checkpoint, Event, Message, Lock)이다.
후속 릴리스에서는 추가 서비스가 추가되었다.
- 릴리스 3(2006년 1월 18일)은 첫 번째 관리 서비스 세트를 추가했다. IMM(로그, 알림 및 정보 모델 관리)
- 릴리즈 4(2007년 2월 27일)는 타이머와 네이밍으로 유틸리티 서비스를 확장했다.
- 릴리스 5(2007년 10월 16일)는 시큐리티로 관리 서비스를 확장하고 소프트웨어 관리 프레임워크를 추가했다.
- 릴리즈 6(2008년 10월 21일)은 플랫폼 관리 서비스를 추가하여 AIS와 HPI(하드웨어 플랫폼 인터페이스)의 격차를 해소했다.
AIS는 12개의 서비스와 2개의 프레임워크로 구성되어 있다. 서비스는 AIS 프레임워크 외에도 AIS 플랫폼 서비스, 기본 AIS 관리 서비스, 일반 AIS 유틸리티 서비스 등 3개 업무 그룹으로 분류된다.
초기에는 API가 C 프로그래밍 언어로만 정의되었으나, 2008년 7월 현재 다양한 서비스 API의 자바 매핑이 증분 출시되고 있다.
서비스 종속성
인터페이스 규격의 서로 다른 서비스와 프레임워크는 모듈형으로 설계되었고, 어느 정도는 서로 독립적으로 설계되었다. 이것은 AIS만 제공하는 시스템을 허용하고 HPI는 존재하지 않으며 그 반대의 경우도 허용한다.
유일하게 필요한 아키텍처 의존성은 클러스터 멤버십 서비스(CLM)에 의존하는 것이다. 플랫폼 관리 서비스(PLM)와 타이머 서비스(TMR)를 제외한 모든 AIS 서비스는 CLM에 의존한다.
모든 AIS 서비스는 AIS 관리 서비스를 사용하여 관리 인터페이스, 구성 및 런타임 관리 정보(그림2)를 노출해야 한다.
플랫폼 서비스
PLM(Platform Management Service)은 시스템의 하드웨어 및 저수준 소프트웨어에 대한 논리적 보기를 제공한다. 이러한 의미에서 낮은 수준의 소프트웨어는 모든 종류의 소프트웨어에 실행 환경을 제공하는 운영 체제와 가상화 계층으로 구성된다.
PLM에 의해 구현된 주요 논리적 실체는 다음과 같다.
- 하드웨어 요소(HE) - 하드웨어 요소는 모든 종류의 하드웨어 엔티티를 나타내는 논리적 엔티티로, 예를 들어 섀시, CPU 블레이드 또는 I/O 장치가 될 수 있다. 일반적으로 모든 FRU(Field Replaceable Unit)는 하드웨어 요소로 모델링된다.
- 실행 환경(EE) - 실행 환경은 일부 소프트웨어 프로그램을 실행할 수 있는 환경을 나타내는 논리적 실체다. 예를 들어 CPU 블레이드 또는 SMP 시스템은 실행 환경으로 모델링된 단일 운영 체제 인스턴스를 실행한다. 다양한 가상화 아키텍처가 지원된다(그림 4).
PLM은 정보 모델에서 이러한 실체의 상태를 유지하고, 이들을 통제하고 상태 변화를 추적할 수 있는 수단을 제공한다. HE에 대한 이러한 작업을 수행하기 위해 PLM Service는 일반적으로 HPI를 사용한다. EE의 경우 PLM은 운영 체제 상태와 사용 가능한 가상화 계층에 대한 모든 필요한 정보를 검색하는 역할을 담당한다.
CLM(Cluster Membership Service)은 클러스터 구성에서 관리적으로 구성된 노드(이 노드를 클러스터 노드 또는 구성된 노드라고도 함)에 대한 멤버십 정보를 애플리케이션에 제공한다. 클러스터는 각각 고유한 노드 이름을 가진 구성된 노드 집합으로 구성된다.
Cluster Membership Service에 의해 구현된 두 개의 논리적 실체는 다음과 같다.
- 클러스터 - 클러스터 자체를 나타내며 클러스터 노드 개체의 상위 개체임.
- 클러스터 노드 - 구성된 클러스터 노드를 나타냄.
CLM은 현재 클러스터 구성원 정보를 검색하고 구성원 자격 변경(예: 노드 탈퇴, 노드 가입)을 추적할 수 있는 API를 제공한다. 클러스터 전체의 모든 AIS 서비스는 CLM 트랙 API를 사용하여 멤버십을 결정해야 한다.
관리 서비스
AIS 서비스(예: 실행 환경, 체크포인트, 구성요소 등)에 의해 구현되는 다양한 실체는 SA 포럼 정보 모델(IM)에서 관리 객체로 표현되며, 이를 구성 관리 데이터베이스로 볼 수 있다. 관리되는 개체는 클래스 속성 및 관리 작업을 정의하는 관련 AIS 서비스 사양에 의해 정의된 객체 클래스의 인스턴스다. 오브젝트 클래스에 대해 지정된 관리 작업은, 예를 들어 서비스 단위를 잠그거나, IM의 내용을 XML 형식으로 내보내는 등 오브젝트로 대표되는 엔티티에서 수행할 수 있는 작업을 나타낸다. IM의 개체는 개체가 최대 하나의 상위 개체와 임의의 수의 하위 개체를 가질 수 있는 트리 계층 구조로 저장된다.
IM의 객체로 대표되는 논리적 실체는 일반적으로 IMM 서비스 자체에 의해 구현되는 것이 아니라, 사용자 애플리케이션과 체크포인트 서비스 또는 가용성 관리 프레임워크와 같은 AIS 서비스들이 이들의 구현을 제공한다. 따라서 이들을 OI(Object Implementer)라고 한다. 관리 목적상, 모든 AIS 서비스는 IMM 서비스를 통해 구현된 실체를 관리 객체로 노출한다.
IM에는 런타임과 구성이라는 두 가지 범주의 개체와 속성이 있다.
런타임 개체와 속성은 그들이 대표하는 엔터티의 현재 상태를 반영한다. 즉, 그들은 서술적 성격을 띤다.
이와는 대조적으로, 구성 개체와 속성은 관리 애플리케이션, 즉 개체 관리자(OM)에 대해 규범적인 것으로, 개체 구현자에게 구현해야 할 엔터티에 대한 입력을 제공하는 수단이다.
구성 개체는 구성 속성과 런타임 속성을 모두 포함할 수 있지만 런타임 개체는 런타임 속성만 포함할 수 있다. 관리 운영은 두 객체 범주에서 정의될 수 있다.
이에 따라 IMM Service는 객체 구현자에게 "남행" 인터페이스인 IMM-OI API를, 관리 애플리케이션(예: SNMP 에이전트)에 "북행" 인터페이스인 IMM-OM API를 노출시키고, 이들 두 당사자 간의 조정을 실시한다. 또한 영구적인 물체와 속성의 저장도 담당한다.
로그
로그 서비스는 시스템 관리자나 자동화된 도구에 적합한 시스템에 대한 클러스터 차원의 기능 기반(구현별이 아닌) 정보를 수집하기 위한 이벤트 로깅을 목적으로 한다.
Log Service는 애플리케이션들이 명명된 파일과 같은 특정 출력 대상으로 연결되는 로그 스트림을 통해 로그 레코드를 표현하고 쓸 수 있도록 한다. 로그 레코드는 일단 출력 대상에 있으면 출력 형식 규칙이 적용되는데, 이 규칙들은 구성 가능하고 공개적이다. 로깅 응용 프로그램은 대상 로그 스트림에 대한 현재 설정을 기준으로 Log Service가 처리하므로 이러한 측면(예: 대상 파일 위치, 파일 회전 또는 포맷 등)을 인식할 필요가 없다. 출력 형식이 공개적이기 때문에 타사 도구는 이러한 로그 파일을 읽을 수 있다.
4가지 유형의 로그 스트림이 지정되는데, 경보(ITU X.733 및 ITU X.736 기반 로그 레코드), 통지(ITU X.730 및 ITU X.731 기반 로그 레코드), 시스템 및 응용이다. 응용 프로그램 유형은 응용 프로그램별 로그 스트림을 정의하기 위해 응용 프로그램에 의해 사용된다. SA Forum 클러스터에는 각 경보, 알림 및 시스템 로그 스트림 유형에 대해 정확히 하나의 미리 정의된 로그 스트림이 있다. 사용자 애플리케이션은 미리 정의된 스트림을 사용하거나 새로운 애플리케이션별 로그 스트림을 생성할 수 있다.
알림
통지 서비스는 ITU-T 결함 관리 모델(X.700 시리즈 문서에 수록된 것)뿐만 아니라 기타 많은 지원 권고안을 기반으로 한다.
통지 서비스는 사건이나 상황의 변화를 설명하는 통지의 개념에 중점을 두고 있다. AIS 이벤트 서비스에서 정의한 '이벤트'와 명확하게 구분하기 위해 '이벤트' 대신 '알림'이라는 용어를 사용한다.
NTF 서비스는 출판-구독 패러다임에 기반을 두고 있다. 경보, 보안 경보, 객체 생성/삭제, 상태 변경, 속성 값 변경, 기타 등 6가지 통지 유형을 정의한다. 알림은 알림 생성자 API를 사용하여 생성/게시된다. 알림 소비자는 알림을 구독하고 알림을 받는 구독자 또는 알림 소비자 API를 사용하여 지속 로그에서 알림을 검색하는 독자가 될 수 있다. 두 유형의 통지 소비자는 수신 또는 읽기에 관심이 있는 통지 특성을 지정하는 필터를 정의할 수 있다.
알림은 애플리케이션뿐만 아니라 AIS 서비스에서도 생성될 수 있다. 알림을 생성하는 AIS 서비스 사양에는 알림을 설명하는 섹션이 있다.
보안
보안 서비스는 클러스터 내에서 AIS 서비스(및 잠재적으로 다른) 클라이언트 프로세스를 인증하고 특정 활동을 수행할 수 있는 권한을 부여하기 위해 AIS 서비스에서 사용할 수 있는 메커니즘을 제공한다. 이러한 메커니즘은 승인되지 않은 액세스로부터 보호함으로써 고가용성 인프라 및 해당 데이터를 포함한 SA Forum 애플리케이션의 무결성을 보존하는 데 사용될 수 있다.
보안의 집행은 AIS 서비스 구현 자체에 위임된다. 보안이 가능한 AIS 서비스는 다른 활동을 시작할 때 고객 프로세스를 대신하여 SEC 구현에 승인을 요청한다. SEC는 이러한 승인 요청에 대해 허가 또는 거부된 표시로 응답하며, 그에 따라 작업을 허용하거나 허용하지 않는 것은 AIS 서비스에 달려 있다. SEC는 IMM을 통해 구성된 일련의 보안 정책을 기반으로 이러한 적응증을 제공하며, 가입자에게 적절한 콜백을 사용하여 정책 변경사항을 알려준다.
프레임워크
가용성 관리 프레임워크
가용성 관리 프레임워크는 SA Forum 호환 시스템에서 서비스 가용성의 원동력이다. 그것은 서비스를 제공할 준비가 되어 있는 상태에 따라 그 통제 하에 있는 여러 기업의 작업부하를 조정한다. 이를 위해 신청서는 AMF에 대해 지정된 정보 모델에 따라 기술할 필요가 있다. 이 모델은 클러스터 내에서 애플리케이션에 속하는 리소스와 애플리케이션이 제공하는 서비스를 설명한다.
이 정보 모델의 기본 논리적 실체는 구성요소로서, 일부 특정 애플리케이션 기능을 캡슐화하는 가용성 관리 프레임워크의 리소스 집합을 나타낸다. AMF에 의해 구성요소에 할당할 수 있는 일부 서비스를 프로비저닝하여 생성된 워크로드는 CSI(구성 요소 서비스 인스턴스)로 표시된다. 구성요소가 서비스를 적극적으로 제공할 때, 서비스를 대표하는 CSI를 대신하여 활성 상태를 할당한다.
내결함성 설계의 기본 원칙은 중복된 기업 집합에 의해 서비스를 제공하는 것이며 따라서 구성요소는 CSI를 대신하여 대기 역할을 할 수 있어야 한다. 대기 구성 요소는 활성 할당 구성 요소가 고장난 경우 서비스 프로비저닝을 인계받을 수 있도록 상태를 유지한다. AMF의 역할은 구성 요소 상태 및 시스템 구성의 함수로 애플리케이션의 구성요소에 활성 또는 대기 워크로드를 할당하는 것이다.
따라서 가용성 관리 프레임워크에서 제공하는 API는 구성요소 등록, 수명 주기 관리 및 워크로드 할당을 가능하게 한다. 그것들은 오류 보고와 건강 모니터링을 위한 기능을 포함한다. 또한 CSI를 보호하는 구성요소 집합 중 구성요소 서비스 인스턴스 할당을 추적할 수 있다.
가용성 관리 프레임워크 구성에는 복구 및 복구 정책이 포함된다. 자원의 우선순위를 정하고 다양한 중복 모델을 제공한다. 이러한 범위는 단순한 2N 모델(1+1 또는 액티브 스탠바이라고도 함)에서 동일한 구성요소 서비스 인스턴스를 대신하여 둘 이상의 대기 할당을 허용하는 N-way 이중화 모델 또는 다중 활성 할당을 허용하는 N-way-active 모델과 같은 보다 정교한 모델에 이르기까지 다양하다.
관리를 간소화하기 위해 AMF는 추가적으로 구성요소를 서비스 단위 및 서비스 그룹으로, 구성요소 서비스 인스턴스를 서비스 인스턴스로 그룹화한다. 이 모든 것들이 지원서를 구성한다. IMM을 통해 이러한 논리적 실체에서 일련의 관리 작업을 이용할 수 있다.
소프트웨어 관리를 위해, 동일한 소프트웨어를 실행하는 기업들은 유형별로 분류되어, 이들 엔터티의 구성에 대해 단일 지점 입력이 허용된다.
소프트웨어 관리 프레임워크
SA Forum 호환 시스템은 시스템에 배포된 소프트웨어와 구성된 모든 소프트웨어 엔터티로 구성된 배치 구성으로 특징지어질 수 있다. 배치 구성은 IMM 서비스에서 관리하는 정보 모델의 필수적인 부분을 구성한다.
소프트웨어 관리 프레임워크(SMF)는 클러스터에 사용할 수 있고 클러스터에 배포되는 소프트웨어를 설명하는 정보 모델의 일부를 유지 관리한다. 그러나 SMF의 주요 목적은 한 배치 구성에서 다른 배치 구성으로 마이그레이션을 조정함으로써 라이브 시스템의 진화를 가능하게 하는 것이다. SMF 용어로 이 마이그레이션 프로세스를 업그레이드 캠페인이라고 한다.
소프트웨어 관리 프레임워크는 업그레이드 캠페인을 지정하는 데 사용할 XML 스키마를 정의한다. SMF 구현은 이러한 XML 파일을 기반으로 시스템을 하나의 배포 구성에서 원하는 새 구성으로 마이그레이션하는데, 이는 근본적으로 새로운 구성을 유도하는 순서된 작업 및 구성 변경의 스크립트다.
이 마이그레이션 중에 SMF
- 캠페인 국가 모델을 유지한다.
- 마이그레이션으로 인해 발생할 수 있는 오류 상황을 모니터링하고
- 필요에 따라 오류 복구 절차를 배포한다.
이러한 모든 작업을 수행하기 위해 SMF 구현은 가용성 유지를 위해 (1) AMF와 상호작용하고, (2) 정보 모델의 변경을 수행하기 위해 IMM과 상호작용하며, (3) NTF와 상호 작용하여 진행 중인 캠페인에 의해 야기되는 오류 상황을 나타낼 수 있는 알림을 받는다.
소프트웨어 관리 프레임워크는 또한 클라이언트 프로세스가 클러스터에서 관련 업그레이드 캠페인이 시작될 때 그리고 중요한 이정표를 통해 진행될 때 콜백 수신에 대한 관심을 등록하기 위한 API를 제공한다. 이를 통해 애플리케이션별 작업을 업그레이드와 함께 조정할 수 있다. 이는 애플리케이션이 일부 중요한 작업을 수행할 때 업그레이드 캠페인 시작을 단순히 차단하는 것에서부터 데이터베이스 스키마 업그레이드 또는 새로운 프로토콜 배포와 같은 애플리케이션 수준 업그레이드 작업을 조정하는 것까지 다양할 수 있다.
SA Forum 클러스터에 배포할 애플리케이션을 전송하는 소프트웨어 벤더의 경우, 소프트웨어 관리 프레임워크는 또한 엔티티 유형 파일에 대한 XML 스키마를 정의하는데, 이 스키마는 애플리케이션에 의해 구현되는 소프트웨어 엔티티 유형을 설명한다. 이 정보는 적절한 배치 구성을 제공하는 데 사용된다.
유틸리티 서비스
체크포인트
체크포인트 서비스는 체크포인트 데이터를 점진적으로 기록할 수 있는 프로세스를 제공하는데, 이는 응용프로그램을 장애로부터 보호하는 데 사용될 수 있다. 프로세스가 장애로부터 복구되는 경우(재시작 또는 장애 조치 절차 포함) 체크포인트 서비스를 사용하여 이전에 체크포인트된 데이터를 검색하고 기록된 상태에서 실행을 재개함으로써 장애의 영향을 최소화할 수 있다.
체크포인트는 클러스터 전체 엔터티다. 체크포인트에 저장된 데이터의 복사본을 체크포인트 복제본이라고 하는데, 일반적으로 성능상의 이유로 디스크보다는 메인 메모리에 저장된다. 체크포인트에는 노드 장애로부터 보호하기 위해 클러스터의 다른 노드에 여러 개의 체크포인트 복제본이 저장되어 있을 수 있다. 체크포인트를 작성하는 프로세스는 동기식 및 비동기식 복제본 업데이트 정책 중 하나를 선택할 수 있다. 비동기 복제의 경우 업데이트 성능을 최적화하기 위해 공동 위치도 선택할 수 있다.
이벤트
이벤트 서비스는 이벤트 채널의 개념을 기반으로 하는 게시/구독 다지점 통신 메커니즘으로, 하나 이상의 게시자가 이벤트 채널을 통해 이벤트를 사용하여 하나 이상의 익명 구독자와 비동기적으로 통신한다. 이벤트 채널은 최상의 이벤트 전달을 제공하는 클러스터 차원의 명명된 엔티티다. 출판사도 같은 이벤트 채널의 구독자가 될 수 있다.
이벤트는 표준 헤더와 0바이트 이상의 게시된 이벤트 데이터로 구성된다. 이벤트 서비스 API는 게시된 이벤트 데이터에 대해 특정 레이아웃을 적용하지 않는다.
프로세스가 이벤트 채널에 가입하여 게시된 이벤트를 수신할 때 게시된 이벤트에 적용할 필터를 지정하십시오. 이벤트는 제공된 필터를 만족하는 경우에만 프로세스에 전달된다.
자물쇠
잠금 서비스는 분산 잠금 서비스로, 서로 다른 노드의 프로세스가 공유 리소스에 액세스하기 위해 서로 경쟁할 수 있는 클러스터에서 사용할 수 있다. 그들에게 잠금 서비스는 잠금 자원이라고 불리는 실체를 제공하며, 애플리케이션 프로세스는 공유 자원에 대한 액세스를 조정하기 위해 사용한다.
잠금 서비스는 단독 접근을 위한 하나의 잠금 모드와 공유 접근을 위한 다른 하나의 잠금 모드를 지원하는 간단한 잠금 모델을 제공한다. 잠금 서비스에서 제공하는 잠금 장치는 복구되지 않는다. 따라서, 하나의 잠금장치를 주장하는 것은 암묵적으로 다른 잠금장치를 주장하는 것이 아니라, 각각의 잠금장치를 개별적으로 청구해야 한다.
메시지
메시지 서비스는 클러스터 전체 프로세스 간 통신 시스템에 대한 API를 지정한다. 통신은 논리적인 이름으로 식별된 메시지 대기열을 기반으로 한다. 임의의 수의 프로세스는 메시지 대기열로 메시지를 보낼 수 있지만, 한 번에 하나의 프로세스는 수신하기 위해 메시지를 열 수 있다. 따라서 단일 메시지 큐는 포인트 투 포인트 또는 멀티 포인트 투 포인트 통신 패턴을 지원한다.
메시지 큐로 메시지를 보내는 프로세스는 수신 프로세스의 정체를 알지 못하므로, 이러한 메시지를 원래 수신하고 있던 프로세스가 장애 조치 또는 전환 중에 다른 프로세스로 대체되었을 수 있다.
메시지 대기열을 함께 그룹화하여 메시지 대기열 그룹을 형성할 수 있다. 메시지 대기열 그룹은 다중점과 다중점 통신을 허용한다. 그것들은 발신자 프로세스가 메시지 대기열의 수와 그것이 통신하고 있는 클러스터 내의 메시지 대기열의 위치를 인식하지 못하도록 논리적인 이름으로 식별된다. 메시지 대기열 그룹은 메시지 대기열 그룹에 관련된 메시지 대기열 사이에 메시지를 배포하는 데 사용될 수 있다. MSG는 세 가지 유니캐스트 분배 정책 - 균등 로드 분배, 로컬 균등 로드 분배 및 로컬 베스트 큐 - 그리고 브로드캐스트(멀티캐스트) 정책을 정의한다.
요청 시 메시지 서비스는 메시지 대기열과 유니캐스트 메시지 대기열 그룹에서 서로 다른 배달 보장(예: 확인, 메시지 지속성 등)을 제공한다.
이름 지정
명명 서비스는 인간 친화적인 이름이 ('bound to') 객체와 연관되는 메커니즘을 제공하므로, 이러한 물체들은 이름이 주어지는 것을 볼 수 있다. 개체는 일반적으로 서비스 액세스 지점, 통신 끝점 및 어떤 종류의 서비스를 제공하는 기타 자원을 나타낸다.
Naming Service는 이름(UTF-8 인코딩 가정) 또는 바인딩된 개체에 대해 특정 레이아웃이나 규약을 부과하지 않는다. 서비스 사용자가 특정 하드웨어 또는 논리적 소프트웨어 구성을 가정하지 않고 자신의 명명 스키마를 선택하여 사용할 수 있도록 한다. Naming Service의 클라이언트는 내부에 저장하고자 하는 객체 바인딩의 구조, 레이아웃, 의미론을 이해하고 서비스로부터 회수할 것으로 기대된다.
타이머스
타이머 서비스는 클라이언트 프로세스가 타이머를 설정하고 타이머가 만료되면 알림을 받을 수 있는 메커니즘을 제공한다. 타이머는 동적으로 생성되는 논리적 개체로, 현재 시간으로부터의 절대 시간 또는 지속 시간으로 만료 시간을 나타낸다.
타이머 서비스는 단일 이벤트 타이머와 정기 타이머의 두 가지 유형의 타이머를 제공한다. 단일 이벤트 타이머는 한 번 만료되며 통지 후 삭제된다. 정기적인 타이머는 지정된 기간에 도달할 때마다 만료되며, 그 과정은 만료에 대해 통지된다. 타이머 삭제 기능을 호출하여 주기적인 타이머를 명시적으로 삭제해야 한다.
프로그래밍 모델
모든 AIS 서비스는 동일한 프로그래밍 모델을 공유한다. 동일한 명명 규칙, 표준 사전 정의된 유형 및 상수, API 의미론, 라이브러리 수명 주기 제어 등이 규격 전반에 걸쳐 사용된다.
SA Forum 애플리케이션 인터페이스는 프로세스와 인터페이스를 구현하는 라이브러리 사이에서 발생한다. 인터페이스는 다중 스레드 애플리케이션 프로세스와 단일 스레드 애플리케이션 프로세스에서 모두 사용하도록 설계되었다. '프로세스'라는 용어는 POSIX 표준에 의해 정의된 프로세스와 동등하다고 볼 수 있지만, AIS는 POSIX 프로세스를 의무화하는 것이 아니라, 시스템이 소프트웨어 실행을 관리하기 위해 제공하는 동등한 실체라고 할 수 있다.
영역 서버는 규격 영역(Availability Management Framework, Cluster Membership Service, Checkpoint Service 등)에 대한 서비스를 제공하는 서버를 나타내는 추상화다. 시행자가 각 영역 서버에 대해 별도의 물리적 모듈을 자유롭게 만들거나 하나 이상의 영역 서버를 하나의 물리적 모듈로 결합할 수 있지만, 각 영역에는 별도의 논리 영역 서버가 있다.
지역실시도서관은 1개 또는 여러 개의 물리적도서관에서 시행할 수 있으나, 각 지역실시도서관에 대해 별도로 운영체제 선정 객체를 초기화, 등록, 취득하는 과정이 필요하다. 그러므로, 프로그래밍의 관점에서, 이것들을 별도의 라이브러리로 보는 것이 유용하다.
사용 모델은 애플리케이션이 설정을 수행한 다음 이벤트가 발생할 때 콜백을 받는 이벤트 중심 아키텍처의 전형적이다(그림 6).
서비스 가용성 라이브러리의 사용은 라이브러리를 초기화하기 위한 호출로 시작되며, 이 호출은 잠재적으로 동적 코드를 로드하고 프로세스에 의해 구현된 비동기 통화를 바인딩한다. 프로세스가 더 이상 영역 함수의 사용을 요구하지 않는 경우, 인터페이스 영역 구현 인스턴스에서 프로세스 연결을 해제하고 관련 리소스를 복구하는 영역 완료 함수를 호출한다.
AIS는 동기식 및 비동기식 프로그래밍 모델을 모두 채택하고 있다. 동기식 API는 일반적으로 라이브러리 및 연결 하우스키핑 인터페이스에 사용된다. 많은 AIS 서비스들은 그들이 구현하는 기업의 변화를 추적할 수 있는 능력을 제공한다. API 트랙은 일반적으로 3가지 기능으로 구성된다. 즉, 클라이언트가 기업에 대한 추적 개시 및 중지, 그리고 서비스 제공 콜백은 추적된 엔터티의 변경에 대해 고객에게 통지한다.
역호환성
AIS 규격을 진화할 때 역호환성을 달성하기 위해 다음과 같은 여러 규칙을 따른다.
- 함수 또는 유형 정의는 특정 SA 포럼 릴리스에 대해 변경되지 않는다.
- 함수 또는 유형 정의의 변경(함수에 새 인수 추가, 데이터 구조에 새 필드 추가)은 새 함수 또는 유형 이름의 정의를 강제한다. 기능/유형이 변경된 버전(예: saAmfComponentRegister_3())을 나타내는 접미사와 함께 이전 버전의 원래 이름에서 새로운 기능 또는 유형 이름이 빌드된다.
- 이전 규칙에 대한 예외로서, 열거형, 플래그 또는 조합 유형의 크기가 변경되지 않는 한, 형식 이름을 변경하지 않고 기존 열거형, 플래그 또는 조합 유형에 새로운 열거형, 플래그 값 또는 조합 필드를 추가할 수 있다.
- AIS 구현자는 애플리케이션이 라이브러리를 초기화할 때 애플리케이션이 제공하는 버전 번호를 존중하고 이전 버전을 사용하는 애플리케이션에 새로운 열거값을 노출하지 않도록 해야 한다.
- 또한 AIS 구현자는 새 오류 코드 또는 수정된 오류 코드와 관련하여 라이브러리가 초기화될 때 애플리케이션에서 제공하는 버전 번호를 존중하고 규격의 최신 버전의 기능에만 적용되는 오류 코드를 규격의 이전 버전에 작성된 애플리케이션에 노출하지 않도록 해야 한다.
예를 들어 f() 함수를 포함하는 특정 서비스의 주요 버전 Vx를 고려하고, 이제 Vy에서 f()를 대체하는 f_y() 변종이 도입되는 새로운 majorVersion Vy(Vy > Vx)에서 f()를 수정해야 한다고 가정한다.
Vx와 Vy 버전을 모두 지원하는 AIS 구현을 고려할 때 프로세스가 Vx 또는 Vy 중 하나를 지정하는 라이브러리를 초기화할 수 있다.
- 이 프로세스가 Vx로 라이브러리 핸들을 초기화하는 경우, 이 핸들은 Vx보다 최신 버전에서 도입된 기능에 대한 액세스를 제공하지 않는다. 특히 이 핸들은 공정이 f_y()를 성공적으로 호출할 수 없게 한다.
- 이 프로세스가 Vy로 라이브러리 핸들을 초기화하는 경우, 이 핸들은 Vy보다 오래된 버전에서 도입된 기능에 대한 액세스를 제공하지 않으며 동일한 기능의 새로운 변형으로 대체된다. 특히 이 핸들은 공정이 f()를 성공적으로 호출할 수 없게 한다.
그러나 프로세스는 얻으려는 기능에 적합한 버전을 사용하여 라이브러리를 매번 여러 번 초기화할 수 있다는 점에 유의하십시오.
Vy용 AIS Service의 사양 문서에는 Vy가 지원하는 기능 또는 유형 정의의 최신 변형만 포함된다.
사양 릴리즈는 다음과 같이 버전화된다: <release code>.<주요판>.<기초본>
릴리스 코드는 대문자다. 역호환성은 동일한 릴리스 코드의 버전에서만 유지된다. 주 버전과 부 버전은 증분 번호들이다. 번호 변경이 큰 릴리스는 위에서 설명한 바와 같이 새로운 기능을 도입하고 역호환 방식으로 API를 변경할 수 있다. 번호가 약간 변경된 릴리스는 API를 변경하지 않는다. 그들은 그들의 전임자에게 버그 수정, 편집 변경, 설명을 제공한다.
구현 레지스트리
SA Forum 구현 레지스트리는 SA Forum 사양의 구현을 등록하고 공개적으로 사용할 수 있도록 하는 프로세스다. 구현 등록에는 멤버십이 필요하지 않다. 성공적으로 등록된 구현을 "서비스 가용성 포럼 등록"이라고 할 수 있다.
