Windows server cluster service architecture

클러스터 서비스 아키텍처

클러스터 서비스는 운영 체제와 함께 작동하는 별도의 고립된 구성 요소 집합으로서 설계됩니다. 이 설계에 의해 클러스터 서비스와 운영 체제 사이의 복잡한 처리 시스템 일정 의존성을 피할 수 있습니다. 하지만 클러스터 기능을 사용 설정하려면 기본 운영 체제의 일부 변경 사항을 변경해야 합니다. 이 변경 사항은 다음과 같습니다.

• 네트워크 이름과 주소의 동적 생성과 삭제의 지원
• 디스크 드라이브 마운트 해제 중 열린 파일을 닫을 수 있도록 파일 시스템 변경
• 여러 노드 사이에서 디스크와 볼륨 세트를 공유할 수 있도록 I/O 하위 시스템 수정

위의 변경 사항과 기타 사소한 수정과는 별도로 클러스터 기능은 기존 Windows 2000과 Windows NT 운영 체제의 핵심 기반을 이루고 있습니다.

클러스터 서비스 구성 요소

클러스터 서비스는 클러스터 서비스와 그 구성 요소 프로세스를 위해 특별히 설계된 네트워크 드라이버, 장치 드라이버, 리소스 구현 프로세스를 사용하여 Windows 2000 또는 Windows NT 4.0 운영 체제에서 실행됩니다. 이렇게 밀접히 관련된 클러스터 서비스의 상호 협력하는 구성 요소는 다음과 같습니다.

 

• Checkpoint Manager —쿼럼 리소스에 저장된 클러스터 디렉터리에 응용 프로그램 레지스트리 키를 저장합니다.
• Database Manager —클러스터 구성 정보를 관리합니다.
• Event Log Replication Manager —클러스터의 한 노드에서 모든 다른 노드로 이벤트 로그 항목을 복제합니다.
• Failover Manager —리소스 관리를 수행하고 시작, 재시작, 장애 조치 같은 적절한 조치를 시작합니다.
• Global Update Manager —클러스터 구성 요소에서 사용하는 서비스를 전체 업데이트하는 서비스를 제공합니다.
• Log Manager —쿼럼 리소스에 저장된 복구 로그에 변경 사항을 기록합니다.
• Membership Manager —클러스터 구성원을 관리하고 클러스터 내의 다른 노드의 상태를 감시합니다.
• Node Manager —그룹 우선 순위 목록과 노드 사용 가능성에 기초하여 노드에 리소스 그룹 소유권을 지정합니다.
• Resource Monitors —리소스 DLL에 대한 콜백을 사용하여 각 클러스터 리소스의 상태를 모니터링합니다. 리소스 모니터는 별도 프로세스에서 실행되며 원격 프로시저 호출(RPC)를 통해 클러스터 서비스와 통신하여 클러스터 리소스의 부분적 장애로부터 클러스터 서비스를 보호합니다.
• Backup/Restore Manager –Database manager와 Failover Manager의 도움으로 쿼럼 로그와 checkpoint 파일 백업 or 복구

노드 관리자 (Node Manager)

노드 관리자는 각 노드에서 실행되며 클러스터에 속하는 노드의 로컬 목록을 관리합니다. 주기적으로 노드 관리자는 클러스터의 다른 노드에서 실행되는 대상에 메시지(하트비트)를 보내서 노드 장애를 감시합니다. 이 경우 반드시 클러스터의 모든 노드가 정확하게 동일한 클러스터 구성원 보기를 사용해야 합니다.

한 노드가 다른 클러스터 노드와의 통신 장애를 감지하는 경우 전체 클러스터에 메시지를 보내 모든 구성원이 현재 자신의 클러스터 구성원 보기를 검사하도록 합니다. 이 과정은 재그룹 이벤트라고 합니다. 클러스터 서비스는 구성원이 안정화될 때까지 클러스터 내의 모든 노드가 일반적인 디스크 장치에 작업 내용을 기록하지 않도록 합니다. 개별 노드의 노드 관리자가 응답하지 않으면 이 노드는 클러스터에서 제거되고 그 활성 리소스 그룹은 다른 활성 노드로 이동됩니다. 리소스 그룹이 이동할 노드를 선택하기 위해 노드 관리자는 리소스 그룹에서 우선적으로 지정된 노드와 개별 리소스를 소유할 잠재적인 소유자(노드)를 식별합니다. 2노드 클러스터에서 노드 관리자는 단순히 장애가 발생한 노드에서 사용 가능한 노드로 리소스 그룹을 이동합니다. 3노드 또는 4노드 클러스터에서 노드 관리자는 사용 가능한 노드 사이에서 선택적으로 리소스 그룹을 배포합니다.

구성 데이터베이스 관리자(Database Manager)

구성 데이터베이스 관리자는 클러스터 구성 데이터베이스 관리에 필요한 기능을 구현합니다. 구성 데이터베이스는 클러스터의 모든 실제 및 논리적 개체에 대한 정보를 수록합니다. 이 개체는 클러스터 자체, 클러스터 노드 구성원, 리소스 그룹, 리소스 종류 및 디스크와 IP 주소 같은 특정 리소스의 설명을 포함합니다.

구성 데이터베이스에 저장된 정적 및 동적 정보는 클러스터의 원하는 상태 및 요구되는 상태를 추적하는 데 사용됩니다. 클러스터의 각 노드에서 실행되는 각 구성 데이터베이스 관리자는 서로 협력하여 클러스터 사이에서 일관된 구성 정보를 유지합니다. 모든 노드에 있는 구성 데이터베이스 사본의 일관성을 유지하기 위해 단방향 커밋이 사용됩니다. 또한 구성 데이터베이스 관리자는 다른 클러스터 서비스 구성 요소에서 사용하는 인터페이스를 제공합니다. 이 인터페이스는 Win32 응용 프로그램 프로그래밍 인터페이스(API) 세트에서 사용되는 레지스트리 인터페이스와 유사합니다. 핵심적인 차이점은 구성 데이터베이스 관리자가 클러스터 개체의 변경 사항을 기록한 다음 글로벌 업데이트 관리자를 사용하여 다른 노드로 복제한다는 것입니다.

검사점 관리자(Checkpoint Manager)

클러스터 서비스를 리소스 장애에서 복구하기 위해 리소스가 온라인 상태일 때 검사점 관리자가 레지스트리 키를 검사하여 리소스가 오프라인 상태가 되었을 때 검사점 데이터를 쿼럼 리소스에 기록합니다. 클러스터 인식 응용 프로그램은 클러스터 구성 데이터베이스를 사용하여 복구 정보를 저장합니다. 클러스터를 인식하지 않는 응용 프로그램은 로컬 서버 레지스트리에 정보를 저장합니다.

로그 관리자(Log Manager)

검사점 관리자와 함께 로그 관리자는 쿼럼 리소스의 복구 로그에 가장 최신의 구성 데이터와 변경 사항 검사점이 기록되도록 합니다. 만약 한대 혹은 여러 대의 다운되면 구성 변경은 다운 되지 않은 다른 노드에서 만들어집니다. 이런 노드들이 다운되어 있는 동안 Database Manager는 쿼럼 리소스에 구성 변경 로그를 남기기 위해 Log manager를 이용 합니다.

장애 조치 관리자(Failover Manager)

장애 조치 관리자는 리소스의 중지와 시작, 리소의 의존성 관리, 리소스 그룹의 장애 조치 시작을 책임집니다. 이 작업을 수행하기 위해 이 관리자는 리소스 모니터와 노드에서 리소스 및 시스템 상태 정보를 받습니다.

장애 조치 관리자는 또한 클러스터에서 리소스 그룹을 소유할 노드를 결정합니다. 리소스 그룹 설정이 끝나면 개별 리소스 그룹을 소유하는 노드는 리소스 그룹 내의 리소스의 제어를 노드 관리자에게 양도합니다. 리소스 그룹 냉의 리소스에 장애가 이 그룹을 소유한 노드에 의해 처리될 수 없으면 클러스터 내의 각 노드에 있는 장애 조치 관리자는 함께 작동하여 리소스 그룹의 소유권을 재설정합니다.

리소스에 장애가 발생하면 장애 조치 관리자는 리소스를 다시 시작하거나 의존 리소스와 함께 해당 리소스를 오프라인시킵니다. 리소스를 오프라인시킬 경우 리소스의 소유권이 다른 노드로 이동되어 새로운 노드의 소유권 하에서 재시작되어야 한다는 것을 통보합니다. 이 과정을 장애 조치라고 합니다.

장애 조치 (Failover )

장애 조치는 계획되지 않은 하드웨어 또는 응용 프로그램의 장애로 인해 자동적으로 발생하거나 클러스터를 관리하는 관리자가 수동으로 시작할 수 있습니다. 이 두 경우 모두 알고리즘은 동일하지만 수동 장애 조치의 경우 리소스는 정상 종료되는 반면, 장애에 의한 자동 장애 조치의 경우 리소스는 강제 종료되는 차이가 있습니다.

클러스터의 전체 노드에 장애가 발생하면 여기에 속한 리소스 그룹은 클러스터에서 하나 이상의 사용 가능한 서버로 이동합니다. 자동 장애 조치는 리소스 소유권의 계획된 관리적 재지정과 유사합니다. 하지만 장애가 발생한 노드에서는 정상적인 종료 과정이 수행될 수 없기 때문에 과정이 보다 복잡합니다.

자동 장애 조치는 장애가 발생한 노드에서 실행 중이었던 그룹을 식별하고 다양한 리소스 그룹의 소유권을 인수할 노드를 결정해야 합니다. 리소스 그룹을 호스트할 수 있는 클러스터의 모든 노드는 소유권에 대해 서로 협상합니다. 이 협상은 노드 가용성, 현재 로드, 응용 프로그램 피드백 또는 노드 우선 순위 목록에 기초합니다. 리소스 그룹의 협상이 완료되면 클러스터의 모든 노드는 자신의 데이터베이스를 업데이트하고 리소스 그룹을 소유한 노드를 인식하게 됩니다.

장애 복구(Failback)

노드가 온라인으로 돌아오면 장애 조치 관리자는 일부 리소스 그룹을 복구된 노드로 다시 이동할 것인지 결정할 수 있습니다. 이 과정을 장애 복구라고 합니다. 리소스 그룹의 속성에는 반드시 복구된 노드나 재시작한 노드로 장애 복구하기 위해 정의된 우선 순위 지정된 소유자가 포함되어야 합니다. 복구된 노드나 재시작한 노드가 우선하는 소유자인 리소스 그룹은 현재 소유자에서 복구된 노드나 재시작한 노드로 이동합니다. 클러스터 서비스는 처리 로드가 많은 시간이나 올바르게 복구되거나 재시작되지 않은 노드로 리소스의 장애 복구가 일어나지 않도록 합니다. 리소스 그룹의 장애 복구 속성은 장애 복구가 허용되는 주중의 시간과 장애 복구가 시도되는 횟수 제한을 포함합니다.

이벤트 복제 관리자(Eventlog Replication Manager)

클러스터 서비스는 모든 클러스터 노드에 이벤트 로그를 복제 하기 위해 클러스터의 이벤트 서비스와 상호 작용을 합니다.

글로벌 업데이트 관리자(Global Update Manager)

구성 데이터베이스 관리자는 글로벌 업데이트 관리자가 제공하는 업데이트 서비스를 사용하여 모든 노드에 변경 사항을 동일하게 복제합니다. 글로벌 업데이트 관리자는 모든 노드가 구성 업데이트 정보를 받을 수 있도록 합니다. 업데이트를 수행할 수 없거나 업데이트에 실패한 노드는 나머지 다른 노드와 함께 안정된 상태를 유지할 수 없기 때문에 강제로 클러스터에서 배제되며 오프라인으로 상태로 전환됩니다.

리소스 모니터(Resource Monitors)

리소스 모니터는 리소스 DLL과 클러스터 서비스 사이에서 통신 인터페이스를 제공합니다. 클러스터 서비스가 리소스에서 데이터를 가져와야할 때 리소스 모니터는 이 요청을 받아 해당 리소스 DLL로 전달합니다. 결과적으로 리소스 DLL이 그 상태를 보고하거나 이벤트의 클러스터 서비스를 알려야 할 때 리소스 모니터는 이 정보를 리소스에서 클러스터 서비스로 전달합니다.

리소스 관리자는 클러스터 서비스와는 별도의 프로세스에서 실행되어 클러스터 서비스를 리소스 장애로부터 보호하며 클러스터 서비스에 장애가 발생할 경우 적절한 조치를 취합니다. 리소스 관리자는 또한 클러스터 서비스의 장애를 감지하여 모든 리소스와 그룹에서 조치를 취합니다. 기본적으로 클러스터 서비스는 단 하나의 리소스 모니터를 시작하여 다른 노드에서 호스트하는 모든 리소스와 상호 작용합니다. 하지만 각 노드에서는 하나 이상의 리소스 모니터가 실행될 수 있습니다. 이러한 결정은 각 노드의 리소스와 해당 DLL 및 관리자에 의해 수행됩니다. 관리자는 클러스터 관리자나 다른 관리 응용 프로그램을 사용하여 기본 단일 리소스 모니터를 취소할 수 있습니다.

이벤트 처리기

이벤트 처리기는 클러스터의 노드에서 실행되는 응용 프로그램 및 클러스터 서비스 사이에서 이벤트를 주고 받는 전자 회로판과 같은 역할을 합니다. 이벤트 처리기는 클러스터 서비스 구성 요소가 중요한 이벤트에 대한 정보를 다른 구성 요소에 전달하고 클러스터 API 이벤트 메카니즘을 지원할 수 있도록 돕습니다. 이벤트 처리기는 클러스터 인식 응용 프로그램에 신호 이벤트를 전달하고 클러스터 개체를 관리하는 것과 같은 다양한 서비스를 수행합니다