의존성에 따른 동작

그룹의 시작/종료 순서는 의존성에 따라 온라인은 아래부터 위로, 오프라인은 위부터 아래로 진행됩니다.
그럼 실제 장애가 발생하였을 경우, 리소스 속성을 고려한 진행 순서에 대해 몇 가지 경우를 예로 들어 보겠습니다.
먼저, 리소스 속성과 진행 상태를 다음과 같이 그림으로 미리 정의해 놓았습니다.

[그림] 리소스 상태 정보 표시도

Critical 속성

• critical 리소스보다 하위에서 장애발생
  
  

[그림] 장애 발생 예 1

1. a2 r2 리소스에서 장애가 발생하면 a1 r1 리소스를 종료합니다.
   (a2를 r2를 의존하는 a1으로서는 a2가 r1으로서는 r2가 장애이므로 a1이 r1이 정상적인 온라인이라고 보기 힘듭니다.)
2. a1은 r1은 critical 속성이 있으므로 이 그룹을 페일오버 시키기 위해 a3r3, a4 r4 순서로 종료 시킵니다.
3. 결국 이 노드에서는 a2를 r2를 장애 판정하고 그룹 내의 모든 리소스들을 오프라인 시킵니다.
   
   

• critical이 아닌 리소스

[그림] 장애 발생 예 2

1. a1 r1 리소스가 critical 이 아닌 경우에 온라인 되어 있는 상태입니다.
2. a2 r2 리소스에서 장애가 발생하여 a1 r1 리소스를 종료합니다.
3. a1 r1 리소스는 critical 이 아니므로 그룹 전체를 페일오버 할 필요가 없습니다. 따라서 현재 진행된 상태에서 멈춥니다.
   
   

RestartLimit 속성

'RestartLimit'는 리소스 타입에 있는 속성으로 최종 장애로 판단하기 전에 몇 번까지 복구할 것인지 결정하는 값입니다.

(상세한 내용은 "6. 리소스 타입"  편을 참조해 주십시오.)

[그림] 장애 발생 예 3

1. a2 r2 리소스는 RestartLimit 값이 1인 경우로 1차 장애가 발생했습니다.
2. RestartLimit 값으로 인해 1차 서비스를 복구 시킵니다.
   이 때는 상위인 a1의 r1의 리소스는 하위 리소스 재시작을 위해 오프라인 됩니다.
3. a2가 r2가 재시작 합니다.
4. a1 r1 리소스도 온라인하게 됩니다.
5. a2에서 r2에서 한번 더 장애가 발생하여 최종 장애 상태로 처리 하고 그룹을 페일오버 시키기 위해 현재 그룹을 모두 종료 시킵니다.
   리소스 종료 순서에 의해 a1 r1 리소스부터 종료 시킵니다.
6. a3 r3 리소스를 종료 시킵니다.
7. 현재 노드에서는 a2가 r2가 장애 상태로 처리되었고 모든 리소스들이 오프라인 상태로 남게 됩니다.