...
MCCS는 하드웨어의 장애뿐만 아니라 서비스 제공에 필요한 자원들(예를 들면 네트워크 접속, 응용프로그램 구동, 플랫폼 상태, 디스크 접속 등)에 대해서 정상적인 상태인지를 항상 감시하고 관리합니다.
따라서 해당 자원들에 대해 장애 상태가 감지되어 정상적인 서비스 제공이 불가능한 경우에는 유연한 복구 정책에 따라 자동적으로 서비스를 재구동 시키거나 다른 가용 서버로 페일오버 시키게 됩니다.
...
MCCS는 로컬 디스크 복제 환경과 공유 디스크 환경 모두를 지원합니다. 그러므로 사용자에게 디스크 시스템 환경 구성에 보다 나은 유연성을 제공합니다.
페일오버 그룹(Failover Group) 구성 지원
...
- FAULTED(시스템장애) - RUNNING 상태에 있던 노드와의 모든 핫빗이 끊어졌을 때, RUNNING 상태의 노드를 FAULTED로 설정합니다.
노드 상태의 변화 과정
...
다음은 MCCS의 동작 단계에 따른 노드 상태의 변화 과정을 보여줍니다.
...
[그림] MCCS 동작 단계에 따른 노드 상태
핫빗 이중화
...
핫빗은 노드 상호간의 상태를 동기화하고 장애 상태를 결정하는 중요한 역할을 합니다.
따라서 시스템이 운영중인 상황에서는 언제나 통신이 가능한 상태임을 보장하기 위해 반드시 이중화되어야 합니다.
또한 네트워크 고립 여부를 판단하기 위해서 핫빗 네트워크 중에서 하나는 서비스 네트워크 또는 클러스터 노드 외의 노드와 통신이 가능한 네트워크로 반드시 설정해야 합니다.
노드 장애(Node Fault)
모든 핫빗 통신이 일정 시간 단절될 경우는 해당 노드를 장애 상태로 판정합니다. (상세한 내용은 "챕터 9. 노드 속성값"편을 참조해 주십시오.)
핫빗 통신 단절에 대한 최종 판정은 ICMP(Internet Control Message Protocol) 테스트에 의해 이루어집니다.
각각의 핫빗 네트워크가 단절된 시간이 지정 시간을 초과할 경우는 원격 노드의 장애, 분열, 고립으로 판정합니다.
핫빗 단절
...
모든 핫빗 통신이 단절되면 상호간에 상태 정보를 교환할 수 있는 방법을 잃게 됩니다.
이 경우에 MCCS가 상대 노드를 장애로 판단할 것인지 아니면 단지 상호간의 네트워크 통신만 단절된 상태로 판단할 것인지에 따라 서비스 복구 여부가 결정됩니다.
분열(Split)
핫빗 네트워크의 단절이 클러스터 속성에 정의되어 있는 일정 시간 간격 이상의 시간차로 발생할 경우는 노드 장애 보다는 핫빗 네트워크 전체에 대한 불안정을 의심할 수 있습니다.
따라서 핫빗에 의한 노드 상태를 신뢰할 수 없는 상황으로 판단하여 클러스터내의 모든 노드에 대한 MCCS 서비스를 재시작합니다.
핫빗 통신이 다시 정상적으로 이루어지면 RUNNING 상태로 복귀합니다. 그렇지 않으면 INITING 상태에서 핫빗 통신이 정상화될 때까지 대기하게 됩니다.
고립(Isolation)
일정 시간 내에 모든 핫빗이 단절된 경우라도 상대 노드를 장애로 판단하기 전에 먼저 로컬 노드 자신이 모든 네트워크로부터 단절된 상황인지를 확인할 필요가 있습니다.
만일 게이트웨이 혹는 DNS 서버와 같이 공인된 네트워크 지점과의 통신이 가능한 상태라면 로컬 노드 자신은 단절된 상황은 아니며, 상대 노드가 장애 상태인 것으로 판단하여 상대 노드에서 운영중인 서비스의 복구를 시도할 수 있습니다.
그러나 그렇지 않은 경우에는 상대 노드가 로컬 노드의 상황을 고립으로 판단합니다.
상대 노드는 로컬 노드를 장애 상태로 결정하고, 로컬에서 운영중인 서비스에 대한 복구를 시도하기 때문에, 로컬 노드는 가능한 빨리 운영중인 서비스를 종료해야 합니다.
(상세한 내용은 "챕터 9. 노드 속성값" 편을 참조해 주십시오. )
...
원격 노드 장애(Remote Node Fault)
일정 시간 내에 모든 핫빗이 단절된 경우이며 자신이 고립상태가 아니라는 판정이 난 경우에 해당합니다.
로컬 노드가 서비스를 운영중인 경우에는 자신의 상태를 유지하며, 원격 노드에서 구성된 서비스 중에서 운영되지 않는(OFFLINE) 서비스를 기동(ONLINE)시킵니다.
...