장애복구 컨트롤러에 대해
on Hadoop
스탠바이 네임노드를 활성화시키는 네임노드 전환 작업은 장애복구 컨트롤러라는 새로운 객체가 관리한다.
다양한 방법으로 장애복구 컨트롤러를 구현할 수 있지만, 기본적으로는 아파치 프로젝트에서 널리 알려진 주키퍼를 이용하여 클러스터에 하나의 네임노드만 활성 상태에 있는 것을 보장한다.
장애복구 컨트롤러 프로세스는 하트비트 방식을 사용하여 네임노드의 장애 발생을 감시하다가, 네임노드에 장애가 발생하면 복구를 시도한다.
정기적인 유지관리를 위해, 관리자가 수동으로 네임노드를 전환할 수도 있다.
이를 우아한(graceful) 장애복구라고 하는데, 두개의 네임노드가 서로 역할을 바꾸게 하는 방법으로 순서를 제어할 수 있다.
그러나 우아하지 못한 장애복구에서는, 장애가 발생한 네임노드가 현재 실제로도 실행되지 않고 있다는 걸 확신하기 어렵다.
예를 들어, 네트워크가 느려지는 등의 이유로 주키퍼로 하트비트를 받지 못한다고 하자.
주키퍼는 네임노드 전환을 시작할텐데, 실제로는 기존의 활성 네임노드가 여전히 실행되고 있으며, 자신이 활성화된 네임노드라고 생각하고 있을 것이다.
고가용성을 구현하기 위해서는 기존의 활성 네임노드가 이러한 시스템을 망가뜨리지 않도록 노력을 기울여야 하는데, 이를 위해 펜싱이라는 메소드를 제공한다.
이런 스플릿 브레인 상황에서는 기존의 활성 네임노드가 클라이언트의 읽기 요청에 대해 잘못된 정보를 줄 가능성이 있으므로, ssh 펜싱 명령어로 네임노드의 프로세스를 확실히 종료시키는 것이다.
그러나 공유 에딧로그를 저장하기 위해 NFS를 이용하는 경우에는 한번에 하나의 네임노드만 허용하는 것이 불가능하므로 좀 더 강력한 펜싱 메쏘드를 사용해야 한다.
하둡에서 NFS보다 QJM을 권장하는 이유이기도 하다.
네임노드가 공유 스토리지에 접근하는 것을 막는 것 부터, 원격 명령어로 네트워크 포트까지 막는 등 다양한 펜싱 메쏘드들이 있다.
최후의 수단으로는 기존의 활성 네임노드를 STONITH(shoot the other node in the head)하는데, 이는 호스트 머신의 전원을 강제로 내려버리는 PDU를 이용하는 기술이다.
클라이언트 장애복구는 클라이언트 라이브러리로 명확하게 처리된다.
가장 단순한 방법은 장애복구 제어를 위한 클라이언트측 설정을 이용하는 것인데, HDFS URI는 한쌍의 네임노드 주소를 매핑한 논리적 호스트명을 사용하고, 클라이언트 라이브러리는 성공할때까지 각 네임노드의 주소로 연결을 시도한다.