HDFS Architecture(4) - Name Node HA

Name Node HA가 필요한 이유

• namenode는 SPOF(단일장애지점)인데, 이는 Hadoop의 기본 아키텍처가 namenode를 master로, datanode들을 slave로 하는 master-slave 구조를 따르기 때문임.

• 이 중 namenode는 하나의 인스턴스, datanode는 수평 확장이 가능했으므로 namenode는 bottleneck이 되기 쉬운 구조였음

• 초기 버전에서는 namenode의 데이터 유실을 방지하는 secondary namenode가 있었지만, 이는 완전한 해결책이 되지 못함

• 이러한 구조에서는 예상치 못한 장애뿐 아니라, 계획된 업그레이드나 업데이트에서도 downtime이 발생할 수밖에 없음

HDFS HA Architecture

여기선 Journal Nodes를 활용한 HA 구성을 살펴본다. Shared Storage를 이용한 HA 구성도 있다.

• HA Architecture 구성요소

  • 그림에서와 같이 두 개의 Namenode를 active/standby 상태로 두어서 SPOF를 해결한다. active/standby namenode 모두 running 중으로 운영된다.

  • active namenode가 다운되면 standby namenode가 active namenode 역할을 가져간다.

  • standby namenode는 Hadoop cluster failover 기능을 통합하는 backup namenode 역할을 수행해, namenode의 예상치 못한 장애에 자동화된 failover를 수행한다.

  • HA 구성에서의 중요 이슈

    • Active Standby NameNode는 항상 서로 sync가 되어야 한다.

    • 한 순간에 단 하나의 active namenode만 존재해야 한다. 만약 잠깐이라도 두 개의 active namenode인 상태가 된다면, 서로 다른 active 데이터 상태를 가져서 데이터 충돌이 일어날 수 있다.(split-brain). 이를 막기 위해 Fencing과정을 가짐.

• Quorum Journal Nodes를 이용한 HA 구현

• Sync mechanism

  • Active, Standby namenode는 Journal Nodes라는 별도의 노드 그룹(혹은 데몬 프로세스)를 통해 sync를 유지

  • Journal Nodes는 ring topology 구성으로 연결되어 있음

  • Journal Nodes에 들어온 request는 ring구조를 따라 다른 노드로 copy됨(특정 Journal Node에 failure가 발생해도 Fault Tolerance를 보장)

  • Active namenode는 Journal Node에 있는 EditLogs를 업데이트

  • Standby namenode는 Journal Node로 부터 EditLogs의 변경사항을 읽고 그것을 자신의 namespace에 적용

  • Failover 시에 Standby namenode는 Active namenode가 되기 전에 자신의 metadata의 내용이 Journal Node에 있는 것과 같은지 확인. 확인되었다면 그때 Active Namenode로 전환

  • 모든 datanode는 Active/Standby Node의 IP를 모두 알고 있으며, 자신의 heart beat와 block report를 두 namenode에게 모두 보냄(Standby가 Active 전환을 빠르게 수행하기 위함)

• Fencing

  • Journal Node는 한 순간에 하나의 namenode만 writer가 되도록 함

  • Standby Namenode가 Journal Nodes에 대한 writing 권한을 받으면, 다른 Namenode가 Active 상태가 되지 못하도록 막음

  • 이 과정이 모든 끝난 후에 Active Namenode 역할을 수행함

• Auto-Failover

  

  • Hadoop HA Cluster에서는 Automatic Failover를 위해 Apache Zookeeper를 사용
  • zookeeper는 적은 양의 coordination data를 유지하고, client들에게 데이터의 변경사항을 알리고 failure 감지를 위해 client를 모니터링함
  • zookeeper는 namenode에 session을 유지하며, 만약 failure가 발생하면 sesseion 종료를 감지하여 다른 namenode에게 failover process가 시작됨을 알림
  • Standby Namenode는 Active Namenode가 되기 위해 zookeeper에 유지되고 있던 state에 lock을 건다.
  • ZKFC(ZookeeperFailoverController)는 Namenode의 상태를 모니터링 하는 zookeeper client 프로세스
  • Namenode는 ZKFC를 자신의 노드에 띄우고, ZKFC는 Namenode를 주기적으로 health check함

• Oberver Name Node(ONN)으로 부하 분산하기

ONN은 3.x 버전부터 사용 가능하다

• ONN의 필요성

  • 위 구조에서 Active Namenode는 모든 client의 요청을 받고 Standby Namenode는 단순히 Active Namenode와 같은 상태를 같도록 sync하는 역할을 담당한다.
  • 단일장애지점의 해결(HA)은 달성했지만, 여전히 Active Namenode에 병목현상이 발생하는 문제가 남아 있음
  • 만일 부하로 인해 failover가 되었다면, Active 상태를 넘겨받은 Standby Name노드에서도 똑같은 형상이 연쇄적으로 발생할 것임
  • ONN은 Standby Namenode와 마찬가지로 Active와 같은 상태를 유지하며, 여기에 더해 Active Namenode처럼 consistent read를 지원한다. HDFS의 use case는 대부분 wirte-once-read-many-access이기 때문에 read의 부하를 분산하는 것만으로도 Active Namenode의 부하를 많이 낮출 수 있을 것이라는 디자인의 결과물임

• State of Namenode

  • 즉, Namenode는 세 가지 state를 가질 수 있음. Active, Standby, Observer.

  • 주의해야할 점은 Active-Oberver 사이에서 직접적인 역할 전환은 불가능하다. Auto-Failover 과정을 보면 이해할 수 있음

• client가 read 요청을 하면, proxy provider가 먼저 클러스터에서 사용할 수 있는 ONN으로 read를 시도하며, 모든 ONN으로부터의 읽기가 실패하면 그 때 Active Namenode에게 요청을 보냄

• 다중 유저의 요청에 대해 consistency를 보장하기 위한 msync() 메소드가 추가됨. 기본값은 사용하지 않도록 되어있음