하둡2부터는 High Availability (이하 HA)라는 용어를 사용합니다.
High Availability란 하나의 네임노드와 보조네임노드를 설정하는것이 아닌,
두 개의 네임노드를 설정하는 방법입니다.
NameNode 에 장애가 발생하면
모든 클라이언트가 HDFS 를 사용할 수 없기 때문에 (이를 SPOF (single point of failure) 라고 합니다.)
HA 를 위해 standby name node 를 둡니다.
두 개의 네임노드는 Active 네임노드, Stanby 네임 노드라고 합니다.
Active네임노드에 장애가 생기면,
두번째 네임노드인 Stanby 네임 노드가 Active한 상태로 바뀌면서
네임 노드의 역할을 맡는 방식입니다.
액티브 네임노드와 스탠바이 네임노드는
데이터 노드로부터 블록 리포트와 하트비트를 모두 받아서
동일한 메타데이터를 유지하고, (아래서 설명할) journal node 를 이용하여 에디트파일을 공유합니다.
액티브 네임노드는 네임노드의 역할을 수행하고,
스탠바이 네임노드는 액티브 네임노드와 동일한 메타데이터 정보를 유지하다가,
액티브 네임노드에 문제가 발생하면 스탠바이 네임노드가 액티브 네임노드로 동작하게 됩니다.
액티브 네임노드에 문제가 발생하는 것을 자동으로 확인하는 것이 어렵기 때문에
보통 주키퍼를 이용하여 장애 발생시 자동으로 변경될 수 있도록 합니다.
Active Name Node 는 Client 로부터 파일 시스템 쓰기(업데이트, 삭제, 이동 등) 요청을 받으면
클라이언트로써 저널 노드에 접근하여 해당 트랜잭션을 Journal Node 로 전송하고 저장을 요청합니다.
저널 노드(데몬)는 Name Node 로부터 받은 트랜잭션(edit log 내용)를 저널 노드 자신의 로컬 디스크에 저장합니다.
해당 edit log 내용은 전체 저널 노드들에 동시에 쓰여집니다.
오로지 Active Name Node 만이 쓰기 권한을 갖고, Standby name node는 읽기 권한만을 갖습니다.
Standby name node 는 1분 간격으로 Journal Node 로부터 새로운 edit log 내용을 받아
메모리에 상주하는 메타데이터에 반영합니다.
만약 Active Name Node 가 장애가 나면, Standby Name node 가 Journal Node 로부터 모든 정보를 받아
메모리 메타데이터 구성에 반영한 후 Active Name Node 가 됩니다.
리소스를 적게 사용하기 때문에 NameNode 나 Resource Manager 같은 데몬이 돌아가는 서버에서 함께 실행 가능합니다.
저널 노드는 3대 이상의 홀수 개수 만큼 있는 것이 좋습니다. (3, 5, 7,....)
절반 이상의 Journal Node 가 동작 중이어야 edit log 를 fsimage 에 반영할 수 있기 때문입니다.
(저널 노드는 최대 (n-1)/2 개 이상의 노드가 살아있다면, 정상적으로 작동합니다.)
저널 노드가 여러대인 이유는, 저널 노드 역시 SPOF 대상이 될 수 있기 때문입니다.
저널 노드가 1대 뿐인 상황에서 저널 노드가 죽으면, Stand by Name Node 가 정보를 읽을 수 없게 됩니다.
journal node 중 하나가 손상되어도 제대로 동작하는데, 이 기능은 zookeeper 없이 구현되었습니다.
journal node 의 이름이 journal 인 이유는, 파일 시스템의 journaling 정보(edit log 내용)를 담고 있기 때문입니다.
(부정확한 정보 :
이와 같이 Journal node 를 이용하여 HA 를 구성하는 것을 QJM(Quorum Journal Manager) 라고 하는 것 같은데...(?)
이는 (아래서 설명할)주키퍼가 없어도 동작하지만, active name node 선출을 위해 주키퍼를 사용합니다.)
Resource Manager 에도 장애가 발생하면, job 이나 task container 가 실행될 수 없어서
Single Point of Failure 문제점을 갖고 있습니다.
따라서 Resource Manager 역시 이중화를 하여 HA 를 유지해야 합니다.
두 개의 리소스 매니저를 (name node 가 그러했던 것처럼) Active, Standby 두 가지로 나눠 실행합니다.
실행 중인 Resource Manager 에 대한 정보(어플리케이션 진행 상태, Token 위임, 버전 정보 등)는
HDFS(FileSystemRMStateStore), 주키퍼(ZKRMStateStore) 등에 보관되기 때문에
실패한 Active RM 의 핵심 상태를 Standby RM 이 그대로 복구 가능합니다.
Active RM 에 장애가 발생하면, RM 내부적으로 주키퍼의 Active Standby Elector 방식을 임베딩 한 후 사용하여
여러 Standby RM 중 하나를 Active RM 으로 결정합니다.
NameNode 는 (아래서 설명할) zkfc 가 있지만, RM 은 없습니다.
왜냐하면 RM에 장애 감지기가 내장되어있기 때문에 HDFS의 경우와 같이 별도의 ZKFC 데몬을 실행할 필요가 없습니다.
Application Manager와 Node Manager는 Active 가 죽은 이후부터 새롭게 Active 가 된 Standby RM 을 찾기 위해
Round Robin 방식으로 모든 StandBy RM 들을 돌아다닙니다.
그러다가 새롭게 Active 가 된 RM 을 찾으면 그 RM 과 다시 기존의 작업을 재개합니다.
주키퍼는 Active Name Node 와 Standby Name Node 를 이용한 HA 를 가능하게 해주는 분산 코디네이터 입니다.
주키퍼는 어떤 네임 노드가 Active 인지, Standby 인지를 저장함으로 네임 노드들을 관리합니다.
주키퍼는 단 하나의 네임 노드만 active 상태에 있는 것을 보장합니다.
주키퍼는 평소에 zkfc 를 통해 name node 들과 세션을 유지하고 있습니다.
만약 Active 가 반응이 없으면 (세션이 끊기면) 주키퍼는 바로 Standby 에게 'active 가 장애가 났음'을 알립니다.
standby 는 Active 로 바뀌고 NameNode 의 역할을 맡습니다.
여러 Standby Name Node 가 있다면 어떤 것을 Active Name Node 로 선출할 지는
Zookeeper 가 제공하는 리더 선출 기능에 의해 정해집니다.
주키퍼는 분산된 서버 간 정보를 공유하는 역할을 맡으며,
시스템 관리, 분산락, 네이밍 서비스, 서버 모니터링(장애 노드 삭제 등) 같은 서비스를 제공합니다.
3대 이상의 홀수 개수 만큼 있는 것이 좋습니다. (3, 5, 7,....)
주키퍼는 하나의 리더와 다수의 팔로워로 구성되어 있는데 리더가 주키퍼로 들어오는 데이터의 분산을 도맡아 합니다.
리더가 죽으면 나머지 팔로워들 중 하나가 리더가 되어 리더의 역할을 계속 수행합니다.
모든 리더와 팔로워들은 똑같은 데이터를 동기화하고 있기 때문에 어느 주키퍼 서버에서 데이터를 읽어도
같은 데이터를 읽을 수 있습니다.
주키퍼 장애 복구 컨트롤러 ZKFC ( ZookeeperFailoverController ) 는 Zookeepr Client 로써 동작합니다.
자신이 실행되고 있는 서버 위에서 실행되는 Name Node 의 상태를 heartbeat 를 통해 모니터링 합니다.
(네임 노드가 동작하는 서버에 zkfc 도 같이 동작하면서 네임 노드 상태를 모니터링함)
또한 평소(Name Node 가 정상 동작할 때)에 Zookeeper 와 zkfc 간 세션을 유지합니다.
Active Name Node 의 상태가 비정상이 되면, 이를 감지하여 zkfc 와 Zookeeper 간 세션을 종료합니다.
(위에서도 설명한 것처럼) zkfc는 active name node 에 장애가 발생하면,
Standby name node 를 Active Name node 로 승격시키고 기존의 Active Name Node 를 제거합니다.
이 과정에서 zkfc 는 zookeeper 의 대표자 선출 기능(leader election)을 사용하여 여러 standby name node 중
active name node 가 될 노드를 결정합니다.
주키퍼 장애 복구 컨트롤러 ZKFC 를 사용하여, 단 하나의 네임 노드만 활성 상태에 있는 것을 보장합니다.
name node 장애가 아닌데, 네트워크 문제(네트워크 단절 등)가 발생하거나 CPU 과부하 상황에서
active name node 가 죽었다고 판단하여 새로운 name node 가 active 로 승격될 수 있습니다.
이 때 기존의 active name node 는 아직도 자기가 active 라고 생각하는데,
이 상황을 split brain 이라고 부릅니다. (즉, 두 노드 모두 자신이 primary(leader, 혹은 master, active) 라고 생각하는 상황)
이것이 원인이 되어 데이터 동기화, 서비스 중복 시작 등의 문제가 발생할 수 있는데,
기존의 active name node 를 확실하게 죽이는 것을 fencing 펜싱 이라고 합니다.
journal node 자체에서도 split brain 이 발생할 수 있지만,
자체적으로 해결하는 메커니즘이 있어 문제가 되지 않습니다.
갑자기 존댓말로 포스팅 하니까 느낌 이상하네.
https://jyoondev.tistory.com/61
https://excelsior-cjh.tistory.com/73
https://excelsior-cjh.tistory.com/26
https://cyberx.tistory.com/148
https://blog.naver.com/juner84/220490940841
http://blog.naver.com/jevida/221727337500
m.blog.naver.com/juner84/100201906628
https://likebnb.tistory.com/162
https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.3.2/bk_hadoop-ha/content/ch_HA-NameNode.html
https://data-flair.training/blogs/hadoop-namenode-automatic-failover/
'Hadoop' 카테고리의 다른 글
| [HDFS] 세이프 모드(safe mode)란? (0) | 2020.07.20 |
|---|---|
| [Hadoop] ssh 22번 기본 port number 바꾸기 (0) | 2020.07.20 |
| [Hadoop3] Web Interface Port 번호 (0) | 2020.07.17 |
| [Hadoop] 기술 질문 대비 적어두는 것들 (0) | 2020.07.15 |
| [Hadoop3] 버전 2 vs 버전 3 새로운 기능 설명 및 링크 (0) | 2020.07.15 |