[Hadoop] HDFS NameNode의 Metadata 관리와 Failover 상세 과정

NameNode

 HDFS에서 모든 데이터의 metadata를 관리하는 노드.

 

Failover

 장애 극복 기능으로써 어떤 시스템의 문제가 발생했을 시, 예비 시스템으로 자동 전환되는 기능.

 

관련 글

[Hadoop] HDFS - The Hadoop Distributed File System

---

 이번 글에서는 HDFS의 NameNode가 HA(High Availability) 구성된 상태에서 Failover가 일어나는 과정에 대해서 소개하도록 하겠습니다. 공부하면 아시겠지만, HDFS에서는 가장 중요하다고 할 수 있는 metadata를 NameNode가 관리합니다. 그래서 NameNode 서버가 죽게 된다면 이는 곧 HDFS를 사용할 수 없음을 뜻합니다. 그래서 이를 방지하고자 Secondary NameNode를 구성하는 방법 등을 거쳐 현재는 Active - Standby NameNode 구조를 사용하고 있습니다. Standby NameNode는 Secondary와 다르게 Active 상태의 NameNode를 완벽하게 대체할 수 있다는 점에서 차이점이 있습니다. 이때 Standby가 문제가 생긴 Active를 대체하여 서로 상태가 변하는 과정을 Failover라고 합니다.

 

 

NameNode의 metadata 관리 방법

 

 Failover에 과정을 알기 전에 가장 먼저 NameNode가 metadata를 어떻게 관리하는지 알아야 합니다. 여기서 FsImage와 EditLog의 용어가 등장합니다. FsImage는 파일에 매핑된 블럭 등을 포함한 전체 namespace 정보를 저장하고 있습니다. 기존에 존재하던 FsImage 정보에서 metadata의 정보가 변경되었다면 새로운 FsImage를 만드는 것이 아니라, 특정 파일에 transaction 로그를 기록하게 되는데 이 특정 파일이 EditLog입니다.

 

 참고로 NameNode 디렉토리에 가보면 아래와 같이 파일들이 존재합니다. "edits_A-B" 형태로 EditLog가 존재하는데 이는 A번 Transaction부터 B번 Transaction까지의 로그입니다. 그리고 "edits_inprogress_C" 형태의 파일은 현재 기록중인 EditLog입니다. FsImage도 "fsimage_D" 형태로 파일들이 다수 존재하는데 마찬가지로 숫자는 반영된 마지막 Transaction을 뜻합니다.

 

 그렇다면 EditLog는 점점 쌓이다가 언제 FsImage에 반영이 될까요? 일반적으로 생각했을 때, 로그를 계속 쌓다 보면 파일의 크기가 점점 늘어날 것을 예상할 수 있습니다. 그래서 EditLog의 크기가 무한정 커지는 것을 막기 위해 주기적으로 EditLog를 FsImage에 반영시켜 새로운 FsImage를 만드는데 이것을 우리는 Checkpoint라고 합니다. Checkpoint의 주기는 특정 기간 또는 transaction 수에 따라 정할 수 있는데, 이는 HDFS 설정을 통해 가능합니다.( dfs.namenode.checkpoint.period, dfs.namenode.checkpoint.txns )

 

 이와 같이 NameNode는 FsImage와 EditLog를 관리하고, 이 정보들과 DataNode로부터 받는 Block report를 함께  In-Memory에 올려서 사용합니다. 참고로 FsImage에는 block들이 어떤 DataNode에 위치하는지는 저장하지 않습니다. Block들의 위치 정보는 Block report들에 담겨 있으며 메모리에 올려 관리합니다.

 

 

 

Namenode HA의 Architecture

 

 현재 HA가 구성되어 있는 HDFS의 아키텍쳐는 아래와 같습니다. NameNode 2대와 다수의 DataNode가 존재하고 추가적으로 다수의 JournalNode, Zookeeper, ZKFC가 있습니다. JournalNode와 Zookeeper 모두 NameNode의 HA를 위해 존재하는데 각자의 역할이 조금씩 다릅니다. 그리고 Active NameNode에 문제가 발생할 때, 빠른 Failover를 위해서 DataNode는 Active, Standby NameNode 모두에게 Block report를 전송합니다.

 

 

 JournalNode는 Active와 Standby NameNode의 중간 역할을 함으로써 metadata의 변경 사항, 즉 EditLog를 보관합니다. JournalNode가 없던 때는 Active NameNode가 자신의 서버에 저장을 했지만, 이는 마찬가지로 SPOF(Single Point of Failure)로써 서버에 문제가 발생했을 때 온전하게 대처할 수 없습니다. 그래서 Active와 Standby 중간에 JournalNode를 위치시켜 EditLog를 지속적으로 저장하고, JournalNode가 관리하는 데이터의 신뢰성을 위해 3대 이상의 홀수로 구성합니다. 이렇게 Active NameNode로부터 전달받아 저장된 EditLog는 Standby NameNode가 접근 후, 주기적으로 반영을 시켜 언제든지 빠른 Failover가 가능하도록 합니다.

 

 Zookeeper는 HDFS뿐만 아니라 일반적으로 사용되는 프로그램으로써, 다수의 서버로 구성되어 데이터를 동기화하고 신뢰 있는 정보를 제공합니다. HDFS에서 신뢰 있는 정보를 받아야 하는 순간이 언제일까요? 지금까지 계속 이야기해왔던 Active NameNode입니다. 우리는 2대의 NameNode를 사용하게 되는데, 이 중에서 어떤 서버가 Active가 되어야 할지 선정하는 것이 바로 Zookeeper의 핵심 역할입니다. 그리고 이렇게 선정된 정보는 다수의 Zookeeper 서버 내부에 데이터로 저장되며 사용자에게 신뢰 있는 정보를 제공하는 것입니다. 그와 더불어 두 개의 NameNode를 위한 세션을 유지하며, 이 세션이 끊겼을 경우 NameNode에 문제가 발생한 것으로 판단합니다.

 

 ZKFC(ZooKeeper Failover Controller)는 NameNode와 Zookeeper의 중간 역할로써, 두 NameNode의 상태를 지속적으로 모니터링하고 Zookeeper를 기반으로 NameNode에게 명령을 내립니다. Zookeeper는 위에서 말했듯이 HDFS만을 위한 시스템이 아닙니다. 그래서 결국 HDFS와 Zookeeper가 서로 호환이 되도록 해주는 것이 필요한데, 그것이 바로 ZKFC입니다. ZKFC는 NameNode가 설치된 서버에 같이 설치가 되며 NameNode를 지속적으로 모니터링합니다. 이때 문제가 감지되면, Zookeeper가 알 수 있도록 세션을 끊어주고 Zookeeper의 Active 선정을 기반으로 두 NameNode에게 명령을 내려줍니다.

 

 

NameNode의 Failover 과정

 

 그렇다면 앞서 말한 내용을 기반으로 NameNode의 Failover 과정에 대해 말씀드리겠습니다. 상황은 Active NameNode에서 문제가 발생해 서비스가 다운된 것을 시작으로 하겠습니다.

 

 1) Active NameNode 서비스 다운.

 

 2) 모니터링하고 있던 ZKFC1이 Active NameNode의 상태를 알아차리고 ZooKeeper와 연결된 session을 끊음.

 

 3) ZKFC1과 session이 끊기면서 Zookeeper에 ephemeral znode로써 저장되어있던 lock은 삭제된다.

 

 4) 반대쪽 ZKFC2가 Zookeeper에서 lock이 사라진 것을 알고 새로운 lock을 생성한다.

 

 5) ZKFC2는 Standby NN을 Active 상태로 전환하기 전에 기존 Active NN을 fencing 해야 한다. 이때 Active NN가 누군지 모르기 때문에 Zookeeper의 Breadcrumb znode의 데이터를 보고 fencing 대상으로 지정한다. 

 

 6) Lock을 얻고 기존 Active NN를 fencing도 시켰으므로, Standby NN는 JournalNode로부터 EditLogs를 확인하며 자신의 namespace에 반영시킨다. ( Standby NN는 평상시에도 주기적으로 EditLogs를 반영시켜 checkpoint를 한다.)

 

 

      

 7) Fencing과 EditLogs 반영이 문제없이 끝났다면 새로운 Breadcrumb를 노드의 정보와 함께 생성하고 Standby NN는 Active 상태로 전환된다.

 

 지금까지 NameNode의 Failover 과정에 대해 상세하게 소개했습니다. 사실 해당 글에서 소개한 과정보다 더 자세한 내용이 존재하긴 합니다. 예를 들어 ZKFC의 경우 HealthMonitor와 ActiveStandbyElector라는 모듈이 존재하기도 합니다. 하지만 이를 전부 다 소개하기에는 너무 양이 많아지고 헷갈릴 것 같아 통합적으로 ZKFC가 하는 것으로 설명한 점 참고 부탁드리겠습니다. 더 자세한 내용은 Hadoop 공식 문서와 ZKFC-design pdf 문서를 참고하시면 확인할 수 있습니다.

 

    - Hadoop 공식 문서
https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

   

    - ZKFC-design pdf 문서

zkfc-design.pdf

0.24MB

 

 

References

 

https://hadooptechblog.wordpress.com/2015/12/29/understanding-namenode/

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

https://dydwnsekd.tistory.com/86

https://sencia.tistory.com/38

http://johnjianfang.blogspot.com/2015/03/hadoop-two-ha-activestandbyelector.html