의존성에 따른 동작

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

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

의존성 속성에 따른 동작

• OnlineDependency

Image Added

[그림] 리소스(r1) 단일 온라인 예(D1의 OnlineDependency : STRONG, D2의 OnlineDependency : WEAK) 

1. r1에 연결된 의존성의 OnlineDependency속성을 확인합니다.
2. D1의 속성값이 STRONG이므로, r4 -> r2 -> r1순으로 온라인 합니다.
   (D2의 속성값은 WEAK이므로, r3는 온라인 하지 않습니다.)

• OfflineDependency
  

Image Added

[그림] 리소스(r4) 단일 오프라인 예(D1의 OfflineDependency : STRONG, D2의 OfflineDependency : WEAK) 

1. r4에 연결된 의존성의 OfflineDependency속성을 확인합니다.
2. D1의 속성값이 STRONG이므로, r1 -> r2 -> r4순으로 오프라인 합니다.
   (D2의 속성값은 WEAK이므로, r3는 오프라인 하지 않습니다.)

리소스 Critical 속성

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

 Image Added

[그림] 장애 발생 예 1

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

• critical이 아닌 리소스

[그림] 장애 발생 예 2

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

RestartLimit 속성

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

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

[그림] 장애 발생 예 3

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

※ 장애로 인한 리소스 재시작 시에는 의존성의 OfflineDependency 속성값에 따라 상위 리소스를 오프라인 하고 재시작합니다.
    재시작 후에는 오프라인 한 리소스들에 대해서 다시 온라인 합니다.