Solaris OS용 Sun Cluster 개념 안내서

고가용성 프레임워크

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

다음 표에서는 SunPlex 구성 요소 장애(하드웨어 및 소프트웨어 모두)와 고가용성 프레임워크에 구축된 복구 작업을 보여줍니다.

표 3–1 SunPlex 장애 감지 및 복구 수준

장애가 발생한 클러스터 구성 요소 

소프트웨어 복구 

하드웨어 복구 

데이터 서비스 

HA API, HA 프레임워크 

없음 

공용 네트워크 어댑터 

IP Network Multipathing 

다중 공용 네트워크 어댑터 카드 

클러스터 파일 시스템 

기본 및 보조 복제본 

멀티 호스트 장치 

미러된 멀티 호스트 장치 

볼륨 관리(Solaris 볼륨 관리자 및 SPARC 기반 클러스터 전용인 VERITAS Volume Manager) 

하드웨어 RAID-5(예: Sun StorEdgeTM A3x00)

전역 장치 

기본 및 보조 복제본 

장치, 클러스터 전송 연결 장치에 대한 다중 경로 

독립 네트워크 

HA 전송 소프트웨어 

여러 개인용 하드웨어 독립 네트워크 

노드 

CMM, 페일페스트 드라이버 

다중 노드 

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

대부분의 고가용성 프레임워크 자원은 자원을 사용하는 응용 프로그램(데이터 서비스)에 투명하게 복구됩니다. 프레임워크 자원 액세스의 시멘틱은 노드 실패에서 완전하게 보존됩니다. 응용 프로그램은 프레임워크 자원 서버가 다른 노드로 이동되었다는 것을 간단하게 알릴 수 없습니다. 단일 노드의 장애는 다른 노드의 디스크에 대한 대체 하드웨어 경로가 존재한다면, 이 노드에 접속된 파일, 장치 및 디스크 볼륨을 사용하는 나머지 노드에 있는 프로그램에서는 전혀 인식할 수 없습니다. 여러 노드에 대한 포트를 갖고 있는 멀티 호스트 장치를 사용하는 경우를 한 가지 예로 들 수 있습니다.

클러스터 구성원 모니터

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

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

클러스터 멤버쉽에서의 변경을 발견하면 CMM은 클러스터의 동기화된 구성을 수행하며, 이 때 클러스터 자원은 클러스터의 새로운 멤버쉽을 기초로 재분배될 수 있습니다.

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

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

페일패스트 기법

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 기반 시스템으로 구성된 경우에는 OpenBootTM PROM(OBP) 프롬프트가 표시될 수도 있습니다. auto-boot? 매개 변수 설정에 따라 수행할 작업이 결정됩니다. OpenBoot PROM ok 프롬프트에서 eeprom(1M)을 사용하여 auto-boot?를 설정할 수 있습니다.

CCR(Cluster Configuration Repository)

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


주의 – 주의 –

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


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