Sun Cluster 3.0 U1 개념

고가용성 프레임워크

SunPlex 시스템은 네트워크 인터페이스를 포함하여 사용자들 및 데이터 고가용성, 자체 응용프로그램, 파일 시스템 그리고 멀티호스트 디스크들 사이의 "경로"에 모든 구성 요소를 만듭니다. 일반적으로, 클러스터 구성 요소는 시스템에서 단일(소프트웨어 또는 하드웨어) 실패를 극복할 경우, 가용성이 높습니다.

다음 테이블은 SunPlex 구성 요소 실패의 종류(하드웨어 및 소프트웨어 모두)와 고가용성 프레임워크에 형성된 복구 종류를 보여줍니다.

표 3-1 SunPlex 실패 감지 및 복구 레벨

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

소프트웨어 복구 

하드웨어 복구 

데이터 서비스 

HA API, HA 프레임워크 

없음 

공용 네트워크 어댑터 

네트워크 어댑터 페일오버(NAFO) 

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

클러스터 파일 시스템 

1차 및 2차 복제본 

멀티호스트 디스크 

이중화된 멀티호스트 디스크 

볼륨 관리(Solstice DiskSuite 및 VERITAS Volume Manager) 

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

글로벌 장치 

1차 및 2차 복제본 

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

독립 또는 개인 네트워크 

HA 전송 소프트웨어 

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

노드 

CMM, 페일페스트 드라이버 

다중 노드 

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

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

클러스터 멤버쉽 모니터

CMM(Cluster Membership Monitor)은 클라이언트 시스템당 하나씩 분산된 에이전트 세트입니다. 에이전트들은 클러스터 상호 연결을 거쳐 메시지를 교환하여 다음을 수행합니다.

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

클러스터 멤버쉽

CMM의 주요 기능은 클러스터에 포함된 노드세트 상에서 항상 클러스터 전역의 일치를 구현하는 것입니다. 이러한 제약 조건을 클러스터 멤버쉽이라고 합니다.

클러스터 멤버쉽을 판별하고, 궁극적으로 데이터 무결성을 보장하기 위해 CMM은 다음을 수행합니다.

클러스터가 별도의 여러 클러스터로 스스로를 파티션하지 않도록 보호하는 방법에 대해서는 "정족수 및 정족수 장치"을 참조하십시오.

클러스터 멤버쉽 모니터 재구성

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

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

클러스터 멤버쉽에서의 변경을 발견하면, 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

노드가 종료된 후에 다시 부팅되어 클러스터에 다시 연결될 수도 있고 OpenBoot PROM (OBP) 프롬프트 상태로 있을 수도 있습니다. 어떤 작업을 할 것인지는 OBP의 auto-boot? 매개 변수 설정에 따라 결정됩니다.

CCR(Cluster Configuration Repository)

CCR(Cluster Configuration Repository)은 클러스터의 구성 및 상태에 대한 정보를 저장하기 위한 전체 클러스터 -범위의 개인용 데이터베이스입니다. CCR은 분배 데이터베이스입니다. 각 노드는 데이터베이스의 전체 사본을 관리합니다. CCR을 사용하면 모든 노드에서 일관된 화면으로 클러스터 "전체"를 볼 수 있습니다. 데이터가 손상되지 않도록 하려면 각 노드에서 클러스터 자원의 현재 상태를 알아야 합니다.

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


주의 - 주의 -

CCR이 텍스트 파일로 구성되어도, 수동으로 CCR 파일들을 편집하지 마십시오. 각 파일에는 일관성이 유지되도록 체크섬 레코드가 포함됩니다. 수동으로 CCR 파일을 갱신하면 노드나 전체 클러스터가 기능 수행을 정지시킬 수 있습니다.


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