반응형

오늘은 HDFS 고가용성에 대해서 포스팅 정리~!


해당 내용은 '하둡 완벽 가이드(4)' 대한 정리 내용입니다.


[ HDFS 고가용성 ]

데이터 손실을 방지하기 위해 네임노드 메타데이터를 다수의 파일시스템에 복제하는 방식과 보조 네임노드를 사용하여 체크포인트를 생성하는 방식을 조합해서 활용할 수 있다. 그러나 이러한 방법도 파일시스템의 고가용성을 궁극적으로 보장하지는 않는다. 네임노드는 여전히 단일 고장점(SPOF, Single Point Of Failure)이다. 네임노드에 장애가 발생하면 맵리듀스 잡을 포함하여 모든 클라이언트가 파일을 읽거나 쓰거나 조회할 수 없게 된다. 네임노드는 메타데이터와 파일 블록의 매핑 정보를 보관하는 유일한 저장소이기 때문이다. 


[ HDFS 네임노드가 장애났을 경우 새로운 네임노드로 재구동 과정 - HA 구성 아닌 경우 ]

네임노드의 장애를 복구하기 위해 관리자는 파일시스템 메타데이터 복제본을 가진 새로운 네임노드를 구동하고 모든 데이터노드와 클라이언트에 새로운 네임노드를 사용하도록 알려주면 된다. 

1. 새로운 네임노드는 네임스페이스 이미지를 메모리에 로드한다.

2.에디트 로그를 갱신한다.

3.전체 데이터노드에서 충분한 블록 리포트를 받아 안전 모드를 벗어 날 때까지 어떤 요청도 처리하지 못한다.

이러한 과정을 거치는데 많은 파일 블록과 대형 클러스터에서 새로운 네임노드 재구성 까지는 30분 이상 걸리는 경우도 있다. (즉, 이런 장애 복구에 걸리는 시간을 감안할 수 있다면 이것도 하나의 방법이 될 수 있다.) 사실 네임노드의 갑작스런 장애는 거의 발생하지는 않는다. 


[ HDFS 고가용성(HA, High availability) - 하둡 2.x 릴리즈부터 ]

위와 같이 재구성하는데 오래걸리는 문제를 해결하기 위해 하둡 2.x릴리즈부터 hdfs의 고가용성을 지원한다. 

고가용성은 활성대비(active-standby)상태로 설정된 한 쌍의 네임노드로 구현된다. 활성 네임노드(active namenode)에 장애가 발생하면 대기 네임노드(standby namenode)가 그 역할을 이어받아 큰 중단 없이 클라이언트 요청을 처리한다. 이러한 방식을 지원하기 위해 HDFS의 구조를 일부 변경했다.

  • 네임노드는 에디트 로그를 공유하기 위해 고가용성 공유 스토리지를 반드시 사용해야 한다. 대기 네임노드가 활성화되면 먼저 기존 활성 네임노드의 상태를 동기화하기 위해 공유 에디트 로그를 읽고, 이어서 활성 네임노드에 새로 추가된 항목도 마저 읽는다.
  • 데이터노드는 블록 리포트를 두 개의 네임노드에 보내야 한다. 블록 매핑 정보는 디스크가 아닌 네임노드의 메모리에 보관되기 때문이다.
  • 클라이언트는 네임노드 장애를 사용자에게 투명한 방식으로 처리할 수 있도록 구성해야 한다.
  • 대기 네임노드는 보조 네임노드의 역할을 포함하고 있으며, 활성 네임노드 네임스페이스의 체크포인트 작업을 주기적으로 수행한다.

고가용성 공유 스토리지를 위해 NFS 필러나 QJM(quorum journal manager) 중 하나를 선택할 수 있다. QJM은 HDFS 전용 구현체로, 고가용성 에디트 로그를 지원하기 위한 목적으로 설계되었고 HDFS의 권장 옵션이다. QJM은 저널 노ㅓ드 그룹에서 동작하며, 각 에디트 로그는 전체 저널 노드에 동시에 쓰여 진다.


활성 네임노드에 장애가 발생하면 대기 네임노드는 매우 빠르게(수십초 이내) 기존 네임노드를 대체할 수 있다. 활성과 대기 네임노드는 모두 최신 에디트 로그와 실시간으로 갱신되는 블록 매핑 정보를 메모리에 유지하고 있기 때문이다. 하지만 실제로 장애 복구 시간을 보면 1분 정도 걸리는데, 시스템이 활성 네임노드에 장애가 발생했다고 판단하는 것은 매우 신중해야 하기 때문이다. 

반응형

+ Recent posts