- 출처:
hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
Apache Hadoop 2.7.1 – HDFS High Availability Using the Quorum Journal Manager
| 본 포스팅은 hadoop 공식 doc에서 ZKFC 부분을 한글로 옮겨서 만들었습니다. 원문을 보고싶으신 분은 첨부된 pdf 파일 확인하시면 됩니다. |
자동 장애 조치는 HDFS 배포에 ZooKeeper 쿼럼과 ZKFailoverController 프로세스 (ZKFC로 약칭)라는 두 가지 새로운 구성 요소를 추가합니다.
Apache ZooKeeper는 소량의 조정 데이터를 유지 관리하고, 해당 데이터의 변경 사항을 클라이언트에 알리고, 클라이언트의 오류를 모니터링하기 위한 고 가용성 서비스입니다. 자동 HDFS 장애 조치의 구현은 다음 사항에 대해 ZooKeeper에 의존합니다.
- 실패 감지 -클러스터의 각 NameNode 머신은 ZooKeeper에서 영구 세션을 유지합니다. 시스템이 충돌하면 ZooKeeper 세션이 만료되어 장애 조치가 트리거 되어야 함을 다른 NameNode에 알립니다.
- Active NameNode 선택 -ZooKeeper는 노드를 활성으로 독점적으로 선택하는 간단한 메커니즘을 제공합니다. 현재 활성 NameNode가 충돌하면 다른 노드가 ZooKeeper에서 다음 활성이 되어야 함을 나타내는 특별한 독점 잠금을 취할 수 있습니다.
ZKFailoverController (ZKFC)는 NameNode의 상태를 모니터링하고 관리하는 ZooKeeper 클라이언트 인 새로운 구성 요소입니다. NameNode를 실행하는 각 머신은 ZKFC도 실행하며 해당 ZKFC는 다음을 담당합니다.
- 상태 모니터링 -ZKFC는 상태 확인 명령을 사용하여 주기적으로 로컬 NameNode를 핑합니다. NameNode가 적시에 정상 상태로 응답하는 한 ZKFC는 노드가 정상이라고 간주합니다. 노드가 충돌, 고정 또는 비정상 상태가 된 경우 상태 모니터는 노드를 비정상으로 표시합니다.
- ZooKeeper 세션 관리 -로컬 NameNode가 정상일 때 ZKFC는 ZooKeeper에서 열린 세션을 유지합니다. 로컬 NameNode가 활성 상태이면 특수 "잠금"znode도 보유합니다. 이 잠금은 "임시"노드에 대한 ZooKeeper의 지원을 사용합니다. 세션이 만료되면 잠금 노드가 자동으로 삭제됩니다.
- ZooKeeper 기반 선택 -로컬 NameNode가 정상이고 ZKFC가 현재 lock znode를 보유하고있는 다른 노드가 없음을 확인하면 자체적으로 lock 획득을 시도합니다. 성공하면 "선거에서 승리"한 것이며 로컬 NameNode를 활성화하기 위해 장애 조치를 실행할 책임이 있습니다. 장애 조치 프로세스는 위에서 설명한 수동 장애 조치와 유사합니다. 먼저 필요한 경우 이전 활성이 차단 된 다음 로컬 NameNode가 활성 상태로 전환됩니다.
자동 장애 복구 설계에 대한 자세한 내용은 Apache HDFS JIRA의 HDFS-2185에 첨부 된 설계 문서를 참조하십시오.
(issues.apache.org/jira/browse/HDFS-2185)
ZKFC Architecture
- zookeeper는 두 개의 namenode를 모니터링하는 ZKFC와 통신하며 active lock을 취득
Active namenode에 문제가 있어 HealthMonitor에 이상이 있으면 ZKFC의 ActiveStandbyElector에 의해 standby namenode를 active로 활성화
프로세스가 사용할 수 없게 되었는지 또는 비정상 상태에 들어 갔는지 확인하기 위해 NameNode를 감시하는 HealthMonitor 필요 - ZooKeeper에서 상태를 관리하고 모니터링하는 ActiveStandbyElector 구현
- HealthMonitor 및 ActiveStandbyElector에서 이벤트를 구독하고 NameNode의 상태를 관리하는 AZKFailoverController 구현
이 ZKFC JVM은 namenode에서 실행되며 ZKFC 프로세스라고 부른다.
HealthMonitor
로컬 namenode를 모니터링하는 스레드로 monitorHealth RPC를 호출한다.
이 RPC에 대한 reponse를 기반으로 namenode 상태를 모니터링한다.
상태 전환은 call back interface를 통해 ZKFC에 메시지를 보낸다.
• INITIALIZING-HealthMonitor가 시작 중이며 아직 NN 3에 연결하지 않았습니다.
• SERVICE NOT RESPONDING-상태 확인 RPC가 시간 초과되었거나 확실한 성공 또는 실패를 반환하지 않습니다.
• SERVICE HEALTHY-상태 확인 RPC가 성공을 반환합니다.
• SERVICE UNHEALTHY-상태 확인 RPC가 최종 실패를 반환합니다 (예 : NameNode가 자체적으로 로컬 디스크 공간 부족과 같은 건강 문제를 감지했습니다.)
• HEALTH MONITOR FAILED-잡히지 않은 예외 등으로 인해 Health Monitor 스레드가 충돌했습니다. 이것은 일반적으로 중단을 유발하는 치명적인 오류입니다.
ActiveStandbyElector 지시
- becomeActive()
로컬 노드에서 transitionToActive ()를 호출합니다. 실패하면 선거를 중단하고 잠시 잠을 자고 선거에 다시 참여하십시오. 재결합 전 휴면은 가능한 경우 다른 노드가 활성화 될 수있는 기회를 제공합니다. 이 경우 선택을 종료 할 때 이동 경로 노드를 삭제하지 않습니다. 이렇게하면 실패 후 부분적으로 활성화 된 상태로 남아있을 수 있으므로 결국 활성 상태가되는 사람이이 노드를 차단하게됩니다. - becomeStandby()
로컬 노드에서 transitionToStandby()를 호출합니다. 실패하면 다른 노드가이 노드를 차단합니다. - enterNeutralMode()
현재 HA 설계에 존재하지 않는 상태로 reponse가 없습니다. - fenceOldActive()
- notifyFatalError(...)
더 이상 예상대로 작동하지 않으므로 ZKFC 프로세스를 중단합니다.
Fencing
ZKFC에서 active namenode가 응답이 없으면 standby로 전환하고 기존 standby NN을 active로 변경하는 작업
|
1. active lock을 획득 한 후 로컬 프로세스가 활성화되도록 지시하기 전에 이동 경로 znode가 있는지 확인하십시오. 2. 선거를 종료 할 때 종료 노드가 차단이 필요한지 여부를 지정하도록 허용합니다. 펜싱이 필요하지 않은 경우 ZooKeeper 세션을 닫기 전에 이동 경로 노드를 삭제하십시오. |
ZKFC 구동시 발생할 수 있는 시나리오
A. Active NN JVM 충돌
JVM이 충돌하면 동일한 노드의 HealthMonitor가 시간 초과 또는 연결 거부 오류로 인해 monitorHealth() 호출에 실패합니다. 그런 다음 HM은 ZKFC에 enterState (SERVICE NOT RESPONDING)를 트리거합니다. ZKFC는 선거를 종료합니다. 다른 노드의 ZKFC는 성공적으로 활성 잠금을 획득하고 펜싱을 시작하고 활성화됩니다.
B. Active NN JVM 동결
ANN의 JVM이 중지되지만 충돌하지 않는 경우 시나리오는 위와 동일합니다. monitorHealth() 호출은 RPC 시간 초과에 도달하고 장애 조치를 트리거합니다.
- 향후 작업 : JVMTI를 사용하여 NN JVM이 현재 긴 가비지 수집 일시 중지를 겪고 있는지 외부에서 확인할 수 있습니다. 그런 다음 GC 일시 중지로 인해 장애 조치에 다른 제한 시간을 사용할 수 있습니다.
C. Active NN machine 충돌
전체 시스템이 충돌하면 ActiveStandbyElector는 구성된 세션 시간 초과 후 ZooKeeper에서 lease를 잃게됩니다. 다른 노드의 ZKFC는 잠금 삭제를 감지하고 위와 동일하게 진행하여 장애 조치를 트리거합니다.
D. Active NN가 비정상적인 상태
상태가 변경되면 HealthMonitor는 HealthCheckFailedException을 보고 위와 동일한 장애 조치를 트리거합니다.
E. Active ZKFC 충돌
ZKFC는 매우 간단하게 설계된 별도의 프로세스에서 실행됩니다. 그러나 여전히 충돌이 발생할 수 있습니다 (예 : JVM 버그, 잘못된 메모리 등). 이 경우 장애 조치가 잘못 트리거됩니다. 공격적인 펜싱을 사용하기 전에 다른 노드의 장애 조치 컨트롤러는 활성 상태를 정상적으로 포기하기 위해 원래 노드로 transitionToStandby를 발행합니다. NameNode 자체가 정상이므로 성공할 것입니다. 따라서 불필요한 장애 조치가 트리거되지만 시스템은 예상대로 진행됩니다.
F. Zookeeper 충돌
ZooKeeper 자체가 충돌하면 두 ZKFC가 동시에 DISCONNECTED 이벤트를 수신합니다. 이 이벤트가 발생하면 로컬 NameNode에서 enterNeutralMode를 호출하지만 둘 다 상태를 변경하지 않습니다. 따라서 시스템은 ZooKeeper가 다운 된 동안 계속 실행되며 장애 조치를 수행 할 수 없습니다.
ZooKeeper가 돌아 오면 클라이언트는 즉시 다시 연결됩니다. ZooKeeper의 동작은 비정상 종료 전에 존재했던 클라이언트 세션이 다시 시작할 때 시작하여 세션 제한 시간 내에 다시 연결되는 한 세션을 다시 획득 할 수 있도록합니다. 따라서 두 노드 모두 세션을 올바르게 다시 확보하고 불필요한 장애 조치가 트리거되지 않습니다.
'Hadoop' 카테고리의 다른 글
| [Hadoop3] Observer Namenode (0) | 2021.03.25 |
|---|---|
| [Hadoop3] Erasure Coding (0) | 2021.03.25 |
| Hadoop 설치시 os kernel parameter 설정 (0) | 2021.03.22 |