QJM의 Split Brain 해결법과 Zookeper의 Split Brain 해결법의 차이에 대한 질문

안녕하세요 minsubrother님!

디테일하게 질문을 주셔서 명료하게 기술하려했는데 도움이 되었으면 좋겠네요.
(제가 근래 외부 일정이 많아 답변이 늦어질 수 있는 점 양해 부탁드립니다)

HDFS HA 구성을 위해 Namenode 2대와 JournalNode, Zookeeper, ZKFC가 필요합니다.

일단 먼저 각자의 역할을 헷갈리시는 것 같아 먼저 정리해보겠습니다.

• journalnode

  • Active, Standby NN의 중간 역할로 메타데이터의 변경 사항, 즉 editlog를 저장 및 보관합니다. 즉, 이가 없으면 Active NN은 메타데이터를 자신의 서버에 저장하나 결국 SPOF 발생하니 저희의 목표인 고가용성을 보장해주기 어렵죠. 이렇게 Active NN로부터 전달받아 전달된 editlog는 Standby NN가 주기적으로 반영하므로, 장애 발생시 빠른 Failover가 가능합니다.

  • journalnode에 오직 Active NN만 editlog를 쓰기 또는 저장할 수 있고, standby NN는 읽기 권한만 있습니다. standBy NN은 주기적으로 저장된 정보를 받아와 업데이트시켜줍니다.

  • 저널노드도 고가용성을 위해) 3대 이상의 홀수 개수로 구성하는 이유는 한개의 노드가 문제가 생기더라도 계속 원하는 역할을 정상 동작시킬 수 있기 때문입니다 (실패 허용개수 (n-1)/2)

• zookeeper는 hdfs 만 아니라 일반적으로 사용되는 서비스로서, 다수의 서버로 구성되어 데이터를 동기화하고 신뢰성 정보를 제공해줍니다. 여기서 신뢰성이란? Active NN 입니다. 즉 2대의 NN 상태 정보 및 2대의 NN 중에서 어떤 서버를 Active로 해줘야할지 선정해주는 핵심 역할을 해줍니다. 선정된 정보는 주키퍼 앙상블에 저장합니다.

• ZKFC는 NN 및 zookeeper의 중간자 역할로, heartbeat를 통해 2대의 NN 을 지속적으로 모니터링해주고, 자동으로 장애를 인지하며 문제가 감지되면 zookeeper에게 알려줍니다.

Failover 시나리오 (zookeeper를 이용해 자동 장애 인지)

• active NN 장애가 발생해서 다운되면, ZKFC1는 그 상태를 알아차리고 Zookeeper와 연결된 세션을 끊습니다. (더 자세히 들어가면 znode 와 lock 개념이 나오나 여기서 표면적으로만 설명하겠습니다)

• ZKFC2는 Zookeeper를 통해 세션이 끊긴 것을 알고, standBy NN을 active 상태로 전환하기 전에, 기존 Active NN의 정보를 조회하여 Kill 해줍니다. (Fencing)

• 그리고 standBy NN은 journalnode로부터 최신 editlog까지 확인하여 최신 반영해줍니다.

• Fencing과 Editlogs 반영이 문제 없으면 ZFKC는 zookeeper의 선출기능 (leader election)을 사용하여 1대의 standby NN을 active NN으로 전환해줍니다. (강의자료에 설명했다시피 Hadoop 3.X 버전에서는 기존 버전과 다르게 Standby NN를 여러대로 구성할 있고, 이때 여러 StandBy NN 중 어떤 노드를 Active NN을 선언할지 자체 leader election 정책을 통해 선정된다고 이해하면 됩니다)

Fencing

• Fencing Method는 뒤 Hadoop Setting Guidance에서도 설명하나, 역할은 Active NN 장애 발생시 문제가 감지된 Active NN을 정상적으로 Kill 해주는 역할입니다. (즉 문자그대로 울타리를 잘 치는 역할이라고 보면 됩니다)

NFS (Shared Storage) + Zookeeper

• Active NN과 Standby NN 사이에 메타데이터를 간편하게 공유하는 방법은 NAS와 같은 Shared Storage 이용하면 됩니다. 저장 문제는 간단하게 해결 될 수 있으나 2대의 서버가 Active 되어 S Storage에 써버리면 중요 정보는 Crash가 발생합니다 (Split Brain)

• 수동으로 장애 인지가 아닌, 자동으로 장애를 인지하는 방법으로 Zookeeper를 많이 씁니다. 이때 StandBy NN이 Actve가 될때 기존 Active NN을 KILL 해야하는데 이를 위해때 별도 fencing method를 설정해줍니다.

• 장애] (NFS 사용시 별도의 fencing 메소드 선언) 기존 Active NN에 문제가 발생하여 Fencing 처리해줄 경우 대략 다음과 같은 3가지 상황인데

  • 네트워크 장애

  • 물리적 서버 장애

  • 부하 상황

  2,3 번은 정상적으로 fencing 할 수 있으나, 네트워크 문제로 (Zookeeper로만 통신하지 않고, 비정상적으로 Shared Storage와도 통신이 되면서) standBy NN에서 fencing 처리를 (네트워크 단절로) 정상적으로 수행하지 못할수 있습니다 그럼 기존 Active NN은 정상 종료되지 않으므로 Split Brain 발생할 수 있습니다.

• 하둡에서는 이 한계를 해결하기 위해 Quorum Journal Manager를 권고하고 있습니다.

QJM + Zookeeper

• 위 역할에서 설명한 JournalNode를 이용하여 edits 정보를 저장 및 공유하는 기능을 수행합니다.

• JournalNode도 여러대로 구성되어있으므로 Split Brain 이슈가 발생할 수 있는데 이는 epoch number를 이용하여 아래와 같은 로직으로 자체적으로 대처해줍니다. 국문으로 말씀드리는 것 보다 아래 원문 그대로 참조하시면 도움될 것 같습니다.

JournalNode fencing

- When a NameNode becomes active, it is assigned an integer epoch number.
- Each epoch number is unique. No two NameNode have the same epoch number.
- When a NameNode sends any message to a JournalNode, it includes its epoch number as part of the request.
- Whenever the JournalNode receives such a message, it compares the epoch number against a locally stored value called the promised epoch number.
- If the requester’s epoch number is higher than the locally stored promised epoch number, then it is said to be “newer” and accept the edit request and also update it’s previous promised epoch number with the new epoch number.
- If the requester’s epoch number is lower, then it will reject the request.
- For any NameNode to successfully write edits, it has to successfully write to a majority of nodes. That means that a majority of nodes have to accept its epoch number as the newest.
- When a new NameNode becomes active, it is guarantee has an epoch number higher than any previous NameNode.

이러한 탄탄한 로직으로 (별도의 Fencing 메소드가 없더라도) 갑자기 장애가 발생해도 StandBy NN가 Active로 전환될때 edits 정보의 정합성은 유지가 되고,standby NN가 자연스럽게 active NN으로 전환될 수 있습니다.

별도의 fencing method 필요 없더라도 hdfs-site.xml 에 "dfs.ha.fencing.methods” conf에 기본 설정을 해주지 않으면 fatal 에러가 발생하고 ZKFC 데몬도 정상 동작이 안되니 기본 설정은 코드랩 가이드처럼 꼭 해주세요

(모든 오픈소스는 논리적으로 완벽하지 않을 수 있으므로 때론 그들이 설정해놓은 가이드를 따라야할 때도 있습니다)