인프런 커뮤니티 질문&답변
작성한 질문수
QJM의 Split Brain 해결법과 Zookeper의 Split Brain 해결법의 차이에 대한 질문
해결된 질문
작성
·
255
·
수정됨
1
안녕하세요. 강사님의 강의를 듣는 도중, 질문의 내용과 같이, Zookeper의 Split Brain 방식과 QJM의 Split Brain 방식의 차이가 헷갈려서, 질문 드리게 되었습니다.
제가 이해한 바는 다음과 같습니다.먼저, Network File System의 문제점은 네트워크 문제 발생시에 동기화 문제가 발생하는 Split Brain Issue가 발생합니다. 이는, 두개의 Active NameNode가 생기기 때문에, 데이터의 corruption이 발생하기 때문에, 저희는 Quorum Journal Manager방식을 채택한 것입니다.
이때, QJM의 경우에도 Split Brain 이슈가 발생이 가능하나, 자체적으로 해결할 수 있다고 했습니다. 해당 방법을 찾아보니, 충분한 수의 Journal Node가 살아있다면, 데이터의 일관성을 유지하기 위해 다수결 원칙을 적용하여 정상적인 Jouranl Node들 간의 동의를 얻게 된다는 점입니다. 저는 해당 방법을 찾아보며, zookeper와 같은 Consoliation Algorithms 방식을 사용하고 있구나... 생각이 들었습니다. 그러니까 Split Brain 이슈 중 하나인 데이터 충돌이 발생했을 때, 맞지 않는 데이터를 지우고, 다수가 가지고 있는 데이터로 통일한다는 것인가..? 라는 생각이 들었습니다.
그러다가, Final Wrap UP 수업에서, zookeper의 경우 NN을 모니터링하며, 장애발생시 (이를 테면, Split Brain과 같은 이슈), StandBy NameNode를 Active NameNode로 전환하며, 여러 개의 Standby NN이 있을 경우 Leader 투표 기능을 통해, Active NameNode를 선출하는 기능이라고 정리하였습니다.
Q1. 시간 순으로 어떻게 되는지가 헷갈립니다. 주키퍼를 통해 상시 모니터링을 하다가, 해당 이슈가 발생할 시, 재빠르게 Active Node로 전환이 되고 나서, 해당 Split Brain 이슈가 발생하며 데이터 충돌이 발생했던 부분을 QJM에서 다수결 원칙을 통해, 올바르지 않은 Journal Node에 있는 데이터는 삭제하며, 데이터의 일관성을 유지한다는 것일까요?
Q2. 만약에 Active Node로 전환이 이루어졌는데도, 해당 문제가 지속적으로 해결이 되지 못해서, QJM에서 다수결 원칙을 통해 해결을 못하는 상황이 발생하면, 심각한 문제상황이라고 볼 수 있는건가요? 잘못 설계해서, 삭제된 데이터는 복구를 할 수 없는건가요?
Q3. Network File System의 경우 hdfs-site.xml에 fencing을 추가함으로써, Split Brain issue를 해결할 수 있다고 공부할 수 있었습니다. 그런데, 상기 방법이 있는데도 불구하고, QJM 방식을 사용하는 이유는, 일정정도 해당 문제가 발생할 시, 데이터의 정합성을 보장해준다는 부분 때문에 차용하는 것일까요?
답변 1
2
안녕하세요 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 데몬도 정상 동작이 안되니 기본 설정은 코드랩 가이드처럼 꼭 해주세요
(모든 오픈소스는 논리적으로 완벽하지 않을 수 있으므로 때론 그들이 설정해놓은 가이드를 따라야할 때도 있습니다)
감사합니다. 특히, Failover상황을 설명해주셔서 ZKFC 역할을 이해할 수 있었습니다. 또한 QJM의 Split Brain Issue는 Jouranlnode안에서 Epoch number를 활용해서, failover가 발생하더라도, editlog의 정합성을 보장하고, Standby NN을 Active NN으로 전환할 수 있다. 라고 정리할 수 있었습니다. 자세한 설명 감사합니다. 도움이 많이 되었습니다.