Subject
타겟 노드를 일시 못찾았을 때 장애 발생
APPLIES TO:
MCCS 3.1
SYMPTOMS
타겟에서 장애가 생긴경우 액티브에서 페일이 발생해도 페일오버가 진행되지 못한다.
타겟의 상태가 돌아오고 난 후 진행되지 못한 페일 오버를 계속적으로 수행 시킬 수 있도록 기능 구현
CAUSE
console에서 입력된 명령을 처리하는 PolicyManager thread와 이를 해석하거나 자체에서 생긴 이벤트에 대한 command를 처리하는 GroupManager thread의 간략한 흐름도이다. PolicyManger에서는 db에서 기록된 console action을 polling으로 가져와서 처리하는 곳이고 GroupManager에서는 엔진내부에서 동작을 결정짓는 command를 큐에서 polling으로 꺼내쓰는 쓰레드이다.
지연된 command(혹은 event)를 처리하기 위해 Deferred Queue를 생성하였고 이를 위한 DeferredMonitor 스레드를 생성하였다.
이 큐에 담기는 것은 GroupManager의 CommandPkt Queue 에서 처리되지 못한 CommandPkt를 담는 곳이며
DeferredMonitor 스레드는 이 큐에서 element가 발생함과 동시에 running 이 이루어 진다. (Blocking Queue 참조)
DeferredMonitor 스레드를 GroupManager 내의 inner 클래스로 생성한 이유는 GroupManager내의 변수들을 편하게 쓰기 위함이다.
DeferredMonitor.run() 내의 queue.take() 에서 내용물이 add 될 때 까지 wait 하는 동작을 취하게 된다. (Blocking Queue 참조)
element가 담겨 스레드가 running 되면 processCommand 내에서 failover 할 수 있는 타겟을 찾아본 뒤
없을 경우엔 다시 deferred queue 에 담고 sleep(3000)으로 대기한다. 왜냐하면 deferred queue에 담는 순간 이 스레드는 계속 running가 될 수 있는 조건이 되기 때문이다.
그래서 take() 대신 (head의 element 가져온 후 지우는) peek() 같은 참조만 하는 메소드를 써 보았지만 그런 메소드에서는 wait() 가 내부적으로 이루어지지 않기때문에
큐에 담기든 안담겨 있든 DeferredMonitor 스레드가 계속적으로 running 가 된다.
SOLUTION
Blocking queue로 생성한 지연된 페일오버를 받을 수 있는 event 큐 스레드를 별도로 두어 지연된 처리가 발생시 담아두었다가
원격노드의 상태가 정상으로 돌아오면 정상적인 command q 로 보내어 지연된 페일오버가 처리 가능하도록 하였다.
Fixed MCCS 3.2