하둡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 로부터 파일 시스템 쓰기(업데이트, 삭제, 이동 등) 요청을 받으면
(클라이언트로써) 저널 노드에 접근하여 해당 트랜잭션(edit log)을 Journal Node 로 전송하고 저장을 요청합니다.
저널 노드(데몬)는 Name Node 로부터 받은 트랜잭션(edit log 내용)를 저널 노드 자신의 로컬 디스크에 저장합니다.
해당 edit log 내용은 전체 저널 노드들에 동시에 쓰여집니다(=Active 가 모든 저널 노드에 일일이 직접 edit log 를 전송)
저널 노드는 Active/Standby name nodes 가 서로 edit log 를 공유할 수 있도록 해줍니다.
오로지 Active Name Node 만이 Journal 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/2+1개 이상의 노드가 살아있다면, 정상적으로 작동합니다.)
저널 노드가 여러대인 이유는, 저널 노드 역시 SPOF 대상이 될 수 있기 때문입니다.
저널 노드가 1대 뿐인 상황에서 저널 노드가 죽으면, Stand by Name Node 가 정보를 읽을 수 없게 됩니다.
저널 노드가 홀수개여야 하는 이유는, 안정적이고 명확한 과반수를 측정하기 위해서입니다.
예를 들어, 4대로 이루어진 저널 노드 클러스터가 있다고 합시다.
4대 중 2대가 죽었을 때, 죽은 노드와 산 노드가 2:2 기 때문에 과반수 판정을 할 수 없습니다
"과반수 이상의 투표가 필요할 때 명확한 과반숫자를 기준으로 판정하기 위해 홀수인 것이 좋다" 라고 알아둡시닷
journal node 중 하나가 손상되어도 제대로 동작하는데, 이 기능은 zookeeper 없이 구현되었습니다.
위와 같이 3개 이상의 Journal node 들을 운영하여 과반수가 동의해야 메타데이터 변경이 적용되는 방식을
QJM(Quorum Journal Manager) 이라고 하며, QJM 은 (아래서 설명할)주키퍼가 없이 동작합니다.
QJM 은 split brain 현상을 방지합니다. 예를 들어 각자 자기가 active 라고 생각하는 name nodes 에서
과반수 이상의 journal node 에 edit log 를 넘겨주지 못한 name node 는 자연스레 active 가 될 수 없게 되기 때문입니다.
(QJM 은 한 번에 하나의 네임노드만 edit log 를 쓸 수 있도록 보장함)
참고로 Qourum 은 정족수를 뜻하며, 정족수는 "의사 결정 등에 필요한 최소한의 수"를 말합니다.
여기서는 "Qourum = 과반수" 라고 이해해도 무방합니다.
(split brain 등에 의해 만들어진) 잘못된 active 가 시스템을 손상시킬 수 있기 때문에
이를 방지하기 위한 fencing 이라는 메소드가 제공됩니다.
journal node 의 이름이 journal 인 이유는, 파일 시스템의 journaling 정보(edit log 내용)를 담고 있기 때문입니다.
journal 이라는 단어는 "일련의 변경 사항을 기록하는 로그 시스템"을 의미합니다.
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 들과 세션을 유지하고 있습니다.
각 NameNode 마다 1개의 zkfc(zookeeper failover controller)가 동작하고,
zkfc 는 자신이 관리하는 name node 에게 주기적으로 RPC 를 보내어 상태를 확인합니다.
(응답이 잘 오면 namenode 가 정상 상태구나 판단 가능)
이 중 active name node 를 관리하는 zkfc 는 zookeeper의 ephemeral znode 를 생성하여 active 의 정보를 저장합니다.
그리고 이 zkfc 는 주기적으로 zookeeper 에게 heartbeat 를 보냅니다.
zookeeper 는 zkfc로부터 heartbeat 받음으로써 active 가 잘 살아있는지 확인합니다
만약 Active 가 반응이 없으면 (세션/네트워크가 끊기거나 active 가 죽어서, zookeeper 가 heartbeat 를 일정 시간 못 받게되면)
active namenode 를 관리하는 zkfc 가 Active namenode 에게 보낸 RPC 요청에 응답을 받지 못하고
이 zkfc 가 zookeeper 에게 heartbeat 를 보내지 못합니다.
이렇게 연결이 끊어지면 ephemeral znode 이 자동으로 삭제되고,
standby namenode 의 zkfc 가 이를 감지하고 failover 를 수행합니다.
standby 는 Active 로 승격되고, 승격된 namenode 는 Active NameNode 의 역할을 맡습니다.
여러 Standby Name Node 가 있는 경우, 어떤 것을 Active Name Node 로 승격되는지 판단은
Zookeeper 가 제공하는 리더 선출 기능에 의해 진행됩니다.
위 과정에서 Zookeeper 는 감시(watches), 세션 타임아웃(session timeout), 리더 선출 기능을 사용합니다.
주키퍼는 분산된 서버 간 정보를 공유하는 역할을 맡으며,
시스템 관리, 분산락, 네이밍 서비스, 서버 모니터링(장애 노드 삭제 등) 같은 서비스를 제공합니다.
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 이 발생할 수 있지만,
자체적으로 해결하는 메커니즘이 있어 문제가 되지 않습니다.
Fencing 이란, split brain 현상 발생시 잘못된 active 가 HDFS 를 업데이트 (editlog 를 발행) 할 가능성을 차단하는 매커니즘입니다.
즉, standby 가 active 로 승격되면 기존 active 가 HDFS 를 변경하지 못하도록 방지하는 과정입니다.
- soft fencing : SSH 를 통해 기존 active node 에 접속하여 kill 명령어로 프로세스 종료
근데 네트워크가 차단된 상태라면 SSH 접근이 불가하여 kill 할 수 없게 됩니다.
kill 못하면 기존 active 가 HDFS 업데이트 할 수 있는 가능성이 생깁니다...
- hard fencing : 기존 Active 를 강제로 차단하는 방법
HDFS 를 읽기 전용 모드로 바꿔서, 기존 Active 가 저장소(HDFS) 업데이트 하는 것을 차단합니다.
혹은 STONITH(Shoot The Other Node In The Head) 을 하는데, 하드웨어 제어 기능을 사용하여
기존 active 가 동작중인 머신의 전원을 차단하도록 하는 것입니다.
fencing 이 완료되어야 standby namenode 가 active 로 승격되도록 합니다.
즉, fencing 이 일어나는 시점은 "기존 active 가 응답하지 않고 standby 가 active 로 승격되기 전" 입니다.
갑자기 존댓말로 포스팅 하니까 느낌 이상하네.
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 |