고가용성 프레임워크

Sun Cluster 시스템은 네트워크 인터페이스, 응용 프로그램, 파일 시스템 및 멀티 호스트 장치를 포함하여 사용자와 데이터 사이의 “경로”에 있는 모든 구성 요소의 가용성을 향상시킵니다. 일반적으로, 클러스터 구성 요소는 시스템에서 단일(소프트웨어 또는 하드웨어) 실패를 극복할 경우, 가용성이 높습니다.

다음 표에서는 Sun Cluster 구성 요소의 장애 종류(하드웨어 및 소프트웨어 모두)와 고가용성 프레임워크에 기본 제공되는 복구 종류에 대해 설명합니다.

Sun Cluster 소프트웨어의 고가용성 프레임워크는 노드 장애를 즉각적으로 감지하고 클러스터의 나머지 노드에 프레임워크 자원을 제공하는 새로운 서버를 만듭니다. 모든 프레임워크를 동시에 사용하지 못하는 경우는 없습니다. 손상된 노드의 영향을 받지 않는 프레임워크 자원은 복구가 진행 중인 동안에도 아무 제한없이 사용할 수 있습니다. 또한 실패한 노드의 프레임워크 자원은 복구되는 대로 사용할 수 있게 됩니다. 복구된 프레임워크 자원은 다른 모든 프레임워크 자원이 복구를 완료할 때까지 기다리지 않아도 됩니다.

대부분의 고가용성 프레임워크 자원은 해당 자원을 사용하는 응용 프로그램(데이터 서비스)으로 투명하게 복구됩니다. 프레임워크 자원 액세스의 시멘틱은 노드 실패에서 완전하게 보존됩니다. 응용 프로그램에서는 프레임워크 자원 서버가 다른 노드로 이동했음을 쉽게 감지할 수 없습니다. 한 노드에 장애가 발생하면 이 노드에 연결된 파일, 장치 및 디스크 볼륨을 사용하는 나머지 노드의 프로그램에서 이런 사실을 분명하게 알 수 있습니다. 다른 노드의 디스크에 대체 하드웨어 경로가 있는 경우에는 이 사실이 분명해집니다. 여러 노드에 대한 포트를 갖고 있는 멀티 호스트 장치를 사용하는 경우를 한 가지 예로 들 수 있습니다.

클러스터 구성원 모니터

데이터를 훼손하지 않고 안전하게 보존하려면, 모든 노드가 클러스터 구성원에서 일관되게 일치해야 합니다. 필요한 경우, CMM은 실패에 대한 응답에서 클러스터 서비스(응용 프로그램)의 클러스터 재구성에 통합됩니다.

CMM은 클러스터 전송 계층으로부터 다른 노드에 대한 연결 정보를 수신합니다. CMM은 클러스터 상호 연결을 사용하여 재구성 동안의 상태 정보를 교환합니다.

클러스터 구성원의 변경을 발견한 다음 CMM은 해당 클러스터에 대해 동기화된 구성을 수행합니다. 동기화된 구성에서는 클러스터 자원이 클러스터의 새 구성원을 기준으로 재배포될 수 있습니다.

이전의 Sun Cluster 소프트웨어 릴리스와는 달리, CMM은 전적으로 커널에서 실행됩니다.

클러스터가 여러 개의 별도 클러스터로 분할되지 않도록 보호하는 방법에 대한 자세한 내용은 장애 차단 정보를 참조하십시오.

페일패스트 기법

CMM이 노드에서 치명적인 문제를 확인하면 클러스터 프레임워크를 호출하여 강제로 해당 노드를 종료(패닉)시키고 클러스터 구성원에서 제거합니다. 이러한 작업을 수행하는 기법을 페일패스트라고 합니다. 페일패스트에 의해 노드가 종료되는 경우는 다음 두 가지가 있습니다.

• 노드가 클러스터를 벗어나서 쿼럼을 사용하지 않고 새 클러스터를 시작하려고 시도하면 공유 디스크에 액세스하지 못하도록 “보호”됩니다. 페일패스트의 용도에 대한 자세한 내용은 장애 차단 정보를 참조하십시오.

• 하나 이상의 클러스터 관련 데몬이 중단되면(clexecd, rpc.pmfd, rgmd 또는 rpc.ed) CMM에서 장애를 감지하여 노드가 강제 종료(패닉)됩니다.

클러스터 데몬이 중단되면 노드가 강제 종료(패닉)되고 다음과 유사한 메시지가 해당 노드의 콘솔에 표시됩니다.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

패닉이 발생한 후에 노드가 재부트되어 클러스터로 다시 결합하려고 시도할 수 있습니다. 또한 클러스터가 SPARC 기반 시스템으로 구성된 경우에는 노드가 OpenBoot^TM PROM(OBP) 프롬프트에 남아 있을 수 있습니다. 노드의 다음 작업은 auto-boot? 매개 변수의 설정에 따라 결정됩니다. OpenBoot PROM ok 프롬프트에서 eeprom(1M)을 사용하여 auto-boot?를 설정할 수 있습니다.

CCR(Cluster Configuration Repository)

CCR은 갱신 사항에 대해 2단계 완결 알고리즘을 사용합니다. 모든 클러스터 구성원이 성공적으로 업데이트되어야 하며 그렇지 않은 경우에는 업데이트 사항이 롤백됩니다. CCR은 클러스터 상호 연결을 사용하여 분배된 갱신 사항을 적용합니다.

CCR은 텍스트 파일로 구성되어 있지만 직접 CCR 파일을 편집하면 안됩니다. 각 파일에는 일관성이 유지되도록 체크섬 레코드가 포함됩니다. 수동으로 CCR 파일을 갱신하면 노드나 전체 클러스터의 기능이 정지될 수도 있습니다.

CCR은 쿼럼이 확립될 때만 클러스터가 실행되도록 하기 위해 CMM에 의존합니다. CCR은 클러스터에서 데이터 일관성을 확인해야 하는 책임을 갖고 있으므로 필요에 따라 복구를 수행하고 데이터를 갱신합니다.