[HDFS] 네임노드 개념과 HA(High Availability, 고가용성) 구성

 

네임노드 장애가 나도 서비스에 문제가 발생하지 않도록 하는 네임노드 HA 구성에 대해 알아보겠습니다. 그 전에 네임노드의 역할, 네임노드 디렉토리 구조, 체크포인팅 개념을 먼저 정리하겠습니다.

 

1. 네임노드의 역할

 

(1) 메타데이터 관리

기본적으로 메타데이터는 메모리에 로딩해놓는다.

 

fsimage 파일

• 어떤 시점에서 HDFS 메타데이터에 대한 스냅샷 파일이다.
• 가장 최근에 체크포인팅(fsimage + edits => fsimage)을 한 시점까지의 메타데이터를 갖고 있다.
• 파일 퍼미션, 엑세스 시간, HDFS 파일 위치, HDFS 블록 메타정보가 기록되어 있다.
• dfs.namenode.name.dir 경로에 저장이 된다. (디스크에도 저장)
• 네임노드 시작할 때 fsimage를 메모리에 로딩한다.

 

edits 로그

• 마지막 체크포인팅이후, 변경사항을 기록하는 로그파일이다.
• 네임노드 시작할 때 edits log를 fsimage에 적용한다. (체크포인팅)
• 네임노드가 HA 구성이 되어있는 경우, 액티브 네임노드가 저널노드에 edits 로그를 쓴다. 스탠바이 네임노드는 저널노드에서 edits 로그를 읽고, 주기적으로 체크포인팅을 수행한다.
• dfs.journalnode.edits.dir 경로에 저장이 된다. (디스크에도 저장)

 

블록 매핑 정보

• 네임노드가 시작할 때, 데이터노드로부터 블록위치 정보를 받는다.
• 네임노드가 시작한 이후 데이터노드가 주기적으로 블록리포트(블록위치 정보)를 준다.
• 네임노드가 갖고 있는 블록 메타정보와, 데이터노드가 보내준 블록위치 정보를 매핑하여 각 블럭의 위치를 매핑한다. 매핑된 내용은 따로 디스크에 저장하지 않고, 메모리에만 저장해놓는다.

 

(2) 데이터노드, 블록 관리

네임노드는 데이터노드와 주기적으로 통신하면서 데이터노드와 블록들을 관리한다.

 

• 네임노드는 데이터노드에게 주기적으로 하트비트와 블록리포트(블록위치 정보)를 받는다. 네임노드가 HA 구성이 되어있는 경우, 데이터노드는 액티브 네임노드, 스탠바이 네임노드 모두에게 하트비트와 블록리포트(블록위치 정보)를 보낸다.
• 하트비트를 오랫 동안(10초) 받지 못하면, 네임노드는 이 데이터노드가 죽은 것으로 표시한다. 그리고 이 데이터노드에 있던 블록을 다른 데이터노드에 복제하도록 명령을 내린다.
• 블록 복제가 필요 이상으로 된 경우 (기본 3개), 필요없는 블록은 삭제하도록 명령을 내린다.

 

(3) 클라이언트 요청 받기

클라이언트 요청을 제일 먼저 받는 녀석이 네임노드다!

 

• 클라이언트(하이브, 자바프로그램 등등)가 HDFS 데이터를 읽거나 쓸 때, 제일 먼저 네임노드와 연결한다.
• 클라이언트가 쓰기 작업을 요청한 경우, 네임노드는 블록을 저장할 수 있는 데이터노드(3개) 주소를 제공한다.
• 클라이언트가 읽기 작업을 요청한 경우, 네임노드는 블록이 저장되어 있는 데이터노드들의 주소를 제공한다.
• 이후에는 클라이언트는 네임노드와 통신하지 않고, 데이터노드와 다이렉트로 통신한다.

 

(4) edits log 쓰기

HDFS 변경사항을 edits log에 기록한다.

 

• 네임노드 HA 구성인 경우, 액티브 네임노드는 저널노드에 edits log를 쓴다. dfs.journalnode.edits.dir 경로에 저장이 된다. dfs.namenode.name.dir에도 저장된다.
• 네임노드 HA 구성이 아닌 경우, dfs.namenode.name.dir 경로에 저장된다.

 

 

2. 네임노드 관련 디렉토리 구조

1) dfs.namenode.name.dir

• /data1/hadoop/cache/hdfs/name/
  • current
    • edits
    • edits_inprogress
    • fsimage
    • fsimage.md
    • seen_txid
      • journal노드의 edits_inprogress txid와 동일함
      • 네임노드가 재시작할때, 이 트랜잭션 id부터 로드함
  • in_use.lock
    • 네임노드가 시작할 때 in_use.lock 파일을 먼저 생성하여 파일시스템을 잠금한다.
    • used to prevent multiple NameNode processes from starting up and concurrently modifying the directory.

 

dfs.journalnode.edits.dir

• /data1/hdfs/journal/users/
  • edits
  • edits_inprogress
  • last-promised-epoch
    • epoch number가 기록된 파일이다. (저널노드는 active가 되는 네임노드에 epoch number를 할당한다. )
  • last-writer-epoch
    • epoch number가 기록된 파일이다. (저널노드는 active가 되는 네임노드에 epoch number를 할당한다. )

 

 

3. 체크포인팅이란

fsimage와 edits로그를 합쳐 새로운 fsimage를 만드는 과정

 

• 체크포인팅을 통해 edit log에 있는 변경 내용을 다시 반영할 필요 없이 fsimage 파일에서 바로 최종 상태를 메모리에 로드할 수 있다.
• 약간의 부하가 발생하는 작업이다. 네임노드가 체크포인팅까지 하기엔 부담이다.
• 그래서 세컨더리 네임노드나 스탠바이 네임노드 같은 녀석들이 체크포인팅을 대신 해준다.
• 체크포인팅을 주기적으로 안 해주면, edits 로그가 계속 커진다. 네임노드를 재시작할 때 fsiamage를 메모리에 로딩하고 edits 로그를 반영하는데 edits 로그가 크다보니 반영하는 시간이 길어진다. 그럼 그 시간동안에 하둡 클러스터를 사용할 수 없게 된다. (쓰기 작업이 불가함) 그래서 정기적으로 체크포인팅을 해서 네임노드를 빠르게 재시작할 수 있도록 한다.
• dfs.naemnode.checkpoint.check.period 주기로 체크포인팅을 한다.
• 네임노드가 HA 구성이 되어있는 경우, 스탠바이 네임노드가 체크포인팅을 한다. 저널노드에서 edits log를 읽어와 fsimage에 반영하고 체크포인팅이 완료된 fsimage를 액티브 네임노드에게 전달한다.

 

체크포인팅 로그 (in standby namenode)

• Triggering checkpoint because it has been 3603 seconds since the last checkpoint, which exceeds the configured interval 3600
• Save namespace
• Saving image file /data1/hadoop/cache/hdfs/name/current/fsimage.ckpt_000000000115653601 using no compression
• Image file /data1/hadoop/cache/hdfs/name/current/fsimage.ckpt_000000000115653601 of size xxxxxxxxxx bytes saved in 1 seconds
• Going to retain 2 images with txid >= 115573815
• Purging old image FSImageFile(file=/data1/hadoop/cache/name/current/fsimage_0000000115573812, cpktTxId=0000000115573812)
• Uploaded image with txid 115653601 to namenode at http://name1.com:50070

 

EditLogTailer

• Triggering log roll on remote NameNode name1.com:8020
• Reading EditLogInputStream expecting start txid #xxxxxxxx
• Start loading edits file http://journal1.com:8480, http://journal2.com:8480, http://journal3.com:8480
• Fast-forwarding stream http://journal1.com:8480, http://journal2.com:8480, http://journal3.com:8480
• Edits file http://journal1.com:8480, http://journal2.com:8480, http://journal3.com:8480 edits #20 loaded
• Loaded 20 edits starting from txid xxxxxxxxx

 

 

(참고) 세컨더리 네임노드 VS 스탠바이 네임노드

세컨더리 네임노드

• 네임노드 역할을 할 수 없다. 단지 체크포인팅만 대신 해줄 뿐이다.
• 또한, 체크포인팅을 한 fsimage를 네임노드에게 보내진 않는다. 이 fsimage가 필요하면 네임노드에서 따로 다운로드를 받아야 한다.
• 데이터노드는 세컨더리 네임노드에게 하트비트를 보내지 않는다. 네임노드한테만 보낸다.

 

스탠바이 네임노드

• 액티브 네임노드가 될 수 있다. (HA 가능) 최신의 메타데이터를 메모리에 저장해놓고 있기 때문이다.
• 물론, 체크포인팅도 한다. fsimage를 액티브 네임노드에게 전달도 한다.
• 데이터노드는 스탠바이 네임노드에게도 하트비트를 보낸다.

 

---

 

네임노드 이해에 필요한 개념을 알아보았으니 이제 네임노드 HA 아키텍처를 정리해보겠습니다.

 

네임노드 HA 아키텍처

혹시나 네임노드가 고장나도 HDFS를 문제없이 사용할 수 있는 아키텍처다!
액티브 네임노드가 고장나면, 스탠바이 네임노드가 액티브 네임노드로 동작한다!
네임노드 HA 아키텍처는 크게 4가지로 구성된다.

 

(1) 액티브 네임노드 / 스탠바이 네임노드

	Active Namenode	Standby Namenode
클라이언트 요청 받기	O	X
체크포인팅 수행	X	O
저널노드에 edits log 쓰기	O	X (읽기만 함)
데이터노드에게 heartbeat 받기	O	O
데이터노드에게 blockreport 받기	O

 

(2) 저널노드

• 액티브 네임노드가 edits 로그를 기록하는 서버이다. 스탠바이 네임노드는 저널노드에서 edits 로그를 읽는다. 즉, 네임노드들의 공유 스토리지라고 보면 된다.
• 홀수대로 구성한다. 왜 홀수대일까?

 

(3) Zookeeper

• 네임노드의 상태정보를 저장하고 있다. (active, standby)
• 주키퍼 서버는 홀수대로 구성한다. 액티브 네임노드를 선정할 때 다수결로 투표하기 위해서이다.

 

(4) ZKFC (Zookeeper Failover Controller)

• 각각의 네임노드 서버에서 동작한다.
• 액티브 네임노드, 스탠바이 네임노드의 상태를 모니터링하여 주키퍼에게 알려준다.
  • 네임노드와 주키퍼 모두와 세션을 맺고 있다.
• 액티브 네임노드에 장애가 발생하면 zkfc와 주키퍼 간의 세션을 종료한다.
• 그리고 스탠바이 네임노드를 액티브 네임노드로 전환한다.

 

---

 

참고링크

• 저널노드 디렉토리

JournalNodes