HDFS HA 구성 이해하기(2)

이전 포스팅에 이어 계속해서 정리해보았다.

Apache Hadoop 3.3.5 – HDFS High Availability

Apache Hadoop 3.3.5 – HDFS High Availability

 

 

HA 클러스터 배포

페더레이션 구성과 유사하게 HA 구성은 이전 버전과 호환되며 기존 단일 Name Node 구성이 변경 없이 작동하도록 허용한다. 새 구성은 노드 유형에 따라 다른 시스템에 다른 구성 파일을 배포할 필요 없이 클러스터의 모든 노드가 동일한 구성을 가질 수 있도록 설계되어있다.

• 페더레이션(Federation)
  페더레이션(Federation)은 분산 시스템에서 여러 개별적인 시스템이 네트워크를 통해 상호 연결되어 동작하는 것을 의미합니다. 이러한 시스템은 자율적으로 운영되며, 다른 시스템과 상호작용할 수 있습니다.

HDFS 페더레이션과 마찬가지로 HA 클러스터는 여러 HA Name Node 로 구성될 수 있는 단일 HDFS 인스턴스를 식별하기 위해 nameservice ID 를 재사용한다. 또한 HA 와 함께 NameNode ID 라는 새로운 추상화가 추가되었다. 클러스터의 각 고유한 Name Node 에는 구별하기 위해 서로 다른 Name Node ID 가 있다.

모든 Name Node 에 대해 단일 구성 파일을 지원하기 위해 관련 구성 매개변수에 NameService ID 와 NameNode ID 가 접미사로 붙는다.

 

 

HA 클러스터 구성 세부 내용

HA NameNodes 를 구성하려면 hdfs-site.xml 구성 파일에 몇 가지 구성 옵션을 추가해야 한다.

이러한 구성을 설정하는 순서는 중요하지 않지만

dfs.nameservices 및 dfs.ha.namenodes.[nameservice ID] 에 대해 선택한 값에 따라 다음 항목의 키가 결정된다.

따라서 나머지 구성 옵션을 설정하기 전에 이러한 값을 결정해야 한다.

 

 

dfs.nameservices

새로운 nameservices 의 논리적 이름

 

이 nameservices 에 대한 논리적 이름(예: “mycluster”) 을 선택하고 이 구성 옵션의 값에 대해 논리적 이름을 사용한다. 선택한 이름은 임의로 정해준다. 클러스터에서 HDFS의 절대경로의 구성 및 권한 구성 요소로 모두 사용된다.

 

참고로 HDFS 페더레이션도 사용하는 경우 이 구성 설정에는 HA 등의 다른 이름 서비스 목록도 쉼표로 구분된 목록으로 포함 되어야 한다.

<property> 
  <name>dfs.nameservices</name> 
  <value>mycluster</value> 
</property>

dfs.ha.namenodes.[nameservice ID]

nameservice 의 각 Name Node 에 대한 고유 식별자

 

쉼표로 구분된 Name Node ID 목록으로 구성한다. DataNodes 에서 클러스터의 모든 Name Node 를 결정하는 데 사용된다. 예를 들어 이전에 “mycluster” 를 nameservice ID 로 사용했고 “nn1”, “nn2” 그리고 “nn3” 을 NameNode 의 개별 ID 로 사용하려는 경우 다음과 같이 구성한다.

<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2,nn3</value>
</property>

참고로 HA 용 NameNode 의 최소 개수는 2개지만 더 구성할 수 있다. 커뮤니케이션 오버헤드로 권장되는 3개의 NameNode 와 함께 5개를 초과하지 않는 것이 좋다.

 

dfs.namenode.rpc-address.[nameservice ID].[name node ID]

청취할 각 NameNode 의 정규화된 RPC 의 주소

 

이전에 구성된 NameNode ID 모두에 대해서 NameNode 프로세스의 전체 주소와 IPC 포트를 설정한다. 이로 인해 두 개의 개별 구성 옵션이 생성된다. 예를 들어 다음과 같이 구성할 수 있다.

<property> 
  <name>dfs.namenode.rpc-address.mycluster.nn1</name> 
  <value>machine1.example.com:8020</value> 
</property> 
<property> 
  <name>dfs.namenode.rpc -address.mycluster.nn2</name> 
  <value>machine2.example.com:8020</value> 
</property> 
<property> 
  <name>dfs.namenode.rpc-address.mycluster.nn3</name> 
  < value>machine3.example.com:8020</value> 
</property>

참고로 원하는 경우에 servicerpc-address 와 유사하게 설정을 구성할 수 있다.

 

 

dfs.namenode.http-address.[nameservice ID].[name node ID]

수신할 각 NameNode 의 정규화된 HTTP 주소

 

위의 rpc-address 와 유사하게 두 NameNode 의 HTTP 서버가 수신 대기하도록 주소를 설정한다.
예를 들어 다음과 같이 설정할 수 있다.

<property> 
  <name>dfs.namenode.http-address.mycluster.nn1</name> 
  <value>machine1.example.com:9870</value> 
</property> 
<property> 
  <name>dfs.namenode.http -address.mycluster.nn2</name> 
  <value>machine2.example.com:9870</value> 
</property> 
<property> 
  <name>dfs.namenode.http-address.mycluster.nn3</name> 
  < value>machine3.example.com:9870</value> 
</property>

참고로 Hadoop 의 보안 기능을 활성화한 경우 각 NameNode 에 대해 유사하게 https 주소를 설정해야 한다.

 

dfs.namenode.shared.edits.dir

공유 스토리지 디렉토리의 위치

 

여기에서 Active NameNode 가 수행하는 모든 파일 시스템의 변경 사항을 회신 상태로 유지하기 위해 Standby NameNode 가 사용하는 원격 공유 편집 디렉토리에 대한 경로를 구성한다. 이러한 디렉터리 중 하나만 구성해야 한다. 이 디렉토리는 NameNode 머신에 r/w로 마운트되어야 한다. 이 설정 값은 NameNode 시스템에서 이 디렉토리에 대한 절대 경로로 설정되어야 한다. 예를 들어 다음과 같이 설정할 수 있다.

<property> 
  <name>dfs.namenode.shared.edits.dir</name> 
  <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value> 
</property>

 

dfs.client.failover.proxy.provider.[nameservice ID]

HDFS 클라이언트가 Active NameNode 에 연결하는데 사용하는 Java 클래스

 

어떤 NameNode 가 현재 활성화되어있는지, 즉 어떤 NameNode 가 현재 클라이언트 요청을 처리하고 있는지 확인하기 위해서 DFS 클라이언트에서 사용할 Java 클래스의 이름을 구성한다. 현재 하둡과 함께 제공되고 있는 두가지 구현은 ConfiguredFailoverProxyProvider 그리고 RequestHedgingProxyProvider 이다. (첫 번째 호출의 경우 모든 네임 노드를 동시에 호출하여 활성 노드를 결정하고 후속 요청에서 장애 조치가 발생할때까지 활성 네임노드를 호출한다.) 사용자 지정 프록시 공급자를 사용하지 않는 한 둘 중 하나를 사용하면 된다.

<property> 
  <name>dfs.client.failover.proxy.provider.mycluster</name> 
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> 
</property>

dfs.ha.fencing.methods

장애 조치 중에 Active NameNode 를 차단하는데 사용되는 스크립트 또는 Java 클래스 목록

 

주어진 시간에 하나의 NameNode 만 활성 상태에 있는 것이 시스템의 정확성에 중요하다. 따라서 장애 조치 중에 다른 NameNode 를 활성 상태로 전환하기 전에 먼저 활성 NameNode 가 대기 상태에 있는지 또는 프로세스가 종료되었는지 확인해야 한다. 이렇게 하려면 최소한 하나의 펜싱 방법을 구성해야 한다. 이는 펜싱이 성공했음을 나타낼 때까지 순서대로 시도되는 캐리지 리턴으로 구분된 목록으로 구성된다. 하둡과 함게 제공되는 shell 및 sshfence 라는 두 가지 방법이 있다.

 

사용자 정의를 통해 펜싱 방법을 구현하는 내용은 org.apache.hadoop.ha.NodeFencer 클래스를 참조하면 된다.

 

sshfence

Active NameNode 에 대한 SSH 및 프로세스 종료

 

sshfence 옵션은 대상 노드에 SSH 를 연결하고 fuser 를 사용하여 서비스의 TCP 포트에서 수신 대기 중인 프로세스를 종료한다. 이 펜싱 옵션이 작동하려면 암호를 제공하지 않고 대상 노드에 SSH 로 연결할 수 있어야 한다. 따라서 쉼표로 구분된 SSH 개인 키 파일 목록인 dfs.ha.fencing.ssh.private-key-files 옵션도 구성해야 한다. 예를 들어 다음과 같이 설정할 수 있다.

<property> 
      <name>dfs.ha.fencing.methods</name> 
      <value>sshfence</value> 
    </property> 

    <property> 
      <name>dfs.ha.fencing.ssh.private-key-files</name> 
      <value>/home/exampleuser/.ssh/id_rsa</value> 
    </property>

 

선택적으로 SSH 를 수행하기 위해 비표준 사용자 이름 또는 포트를 구성할 수 있다. 또한 SSH 엗 ㅐ한 시간 제한을 구성할 수 있으며 그 후에는 이 펜싱 방법이 실패한 것으로 간주된다.

<property> 
  <name>dfs.ha.fencing.methods</name> 
  <value>sshfence([[username][:port]])</value> 
</property> 
<property> 
  <name>dfs.ha. fencing.ssh.connect-timeout</name> 
  <value>30000</value> 
</property>

 

 

shell

Active NameNode 를 차단하기 위해 임의의 쉘 명령을 실행한다.

 

쉘 펜싱 방법은 임의의 쉘 명령을 실행한다. 따라서 다음과 같이 구현할 수 있다.

<property> 
  <name>dfs.ha.fencing.methods</name> 
  <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value> 
</property>

‘(’ 와 ‘)’ 사이의 문자열은 bash 쉘에 직접 전달되며 닫는 괄호를 포함하지 않을 수 있다.

 

쉘 명령은 현재 하둡 구성 변수를 모두 포함하도록 설정된 환경에서 실행되며 구성 키에서 ‘.’ 문자는 ‘_’ 으로 대체된다. 사용된 구성에는 이미 일반 형식으로 승격된 네임노드별 구성이 있다.

 

예를 들어, dfs_namenode_rpc-address 는 구성에서 해당 변수를 dfs.namenode.rpc.address.ns1.nn1 로 지정할 수 있지만 대상 노드의 RPC 주소를 포함한다.

 

추가적으로 다음과 같이 차단할 대상 노드를 참조하는 변수도 사용할 수 있다.

$target_host	hostname of the node to be fenced
$target_port	IPC port of the node to be fenced
$target_address	the above two, combined as host:port
$target_nameserviceid	the nameservice ID of the NN to be fenced
$target_namenodeid	the namenode ID of the NN to be fenced

 

이 환경 변수들은 또한 쉘 명령 자체에서 대체해서 사용될 수 있다. 예를 들어 다음과 같이 사용한다.

<property>
  <name>dfs.ha.fencing.methods</name>
  <value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
</property>

쉘 명령이 종료 코드 0을 반환하면 펜싱이 성공한 것으로 결정된다. 다른 종료 코드를 반환하면 펜싱이 성공하지 못한 것이며 목록의 다음 펜싱 방법이 시도 된다.

 

참고로 이 펜싱 방법은 제한 시간을 구현하지 않는다. 시간 초과가 필요한 경우 쉘 스크립트 자체에서 구현해야 한다.

 

fs.defaultFS

아무것도 지정되지 않은 경우 Hadoop FS 클라이언트에서 사용하는 기본 경로 접두사

 

선택적으로 Hadoop 클라이언트가 새로운 HA-enabled logical URI 를 사용하도록 기본 경로를 구성할 수 있다. 이전에 “mycluster” 를 nameservice ID 로 사용한 경우 이는 모든 HDFS 경로의 권한 부분의 값이 된다. 이는 core-site.xml 파일에서 다음과 같이 구성될 수 있다.

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

dfs.ha.nn.not-become-active-in-safemode

활성화 되어있는 namenodes 가 safe mode 가 되는 것을 방지

 

safe mode 일 때 활성화 되어있는 네임노드를 허용할지의 여부를 설정한다.

 

true 로 설정되어있을 경우 safe mode 에서 네임노드는 auto failover 가 켜져 있는 경우 ZKFS 에게 SERVICE_UNHEALTHY 를 보고하거나, auto failover 가 꺼져 있는 경우 활성으로의 전환에 실패하도록 예외를 발생시킨다. 다음과 같이 설정할 수 있다.

<property>
  <name>dfs.ha.nn.not-become-active-in-safemode</name>
  <value>true</value>
</property>

HA 클러스터 배포 세부 내용

필요한 구성 옵션을 모두 설정한 후 초기에 두 개의 HA NameNode 의 on-disk metadata 를 동기화 해야한다.

• 만약 새 HDFS 클러스터를 설정할 경우 하나의 NameNode 에서 포맷 명령어를 실행해야 한다.
  (hdfs namenode -format)
• NameNode 를 이미 포맷했거나 non-HA-enabled 클러스터에서 HA-enabled 클러스터로 변환할 경우 포맷되지 않은 NameNode 에서 hdfs namenode -bootstrapStandby 명령어를 실행해서 NameNode 의 메타데이터 디렉토리들의 내용을 다른 디렉토리로 복사해야한다.
  이 명령을 실행하게 되면 공유 편집 디렉토리(dfs.namenode.shared.edits.dir에 의해 구성됨) 에 두 NameNode 를 시작할 수 있는 충분한 평집 트랜잭션이 포함되어 있는지 확인할 수 있다.
• non-HA NameNode 를 HA 로 변환하는 경우 hdfs -initializeSharedEdits 명령을 실행해야 한다.
  그러면 로컬 NameNode 편집 디렉토리의 편집 데이터와 함께 공유 편집 디렉토리가 초기화된다.

 

이 시점에서 일반적으로 NameNode 를 시작하는 것처럼 모든 HA NameNode 를 시작할 수 있다.

 

구성된 HTTP 주소를 탐색하여 각 NameNode 의 웹 페이지를 개별적으로 방문할 수 있다. 구성된 주소 옆에는 NameNode 의 HA 상태(standby 또는 active) 가 있다. HA NameNode 가 시작될때마다 처음에는 standby 상태에 있는다.

 

 

HA 클러스터 관리 명령어

HDFS HAAdmin command

HA NameNode 가 구성되고 시작되었으므로 HA HDFS 클러스터를 관리하기 위한 몇가지 추가 명령어에 접근할 수 있다. 특히 hdfs haadmin 명령어에 익숙해져야 한다. 추가 인자 없이 명령어를 실행하면 다음과 같이 확인할 수 있다.

Usage: DFSHAAdmin [-ns <nameserviceId>]
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-getAllServiceState]
    [-checkHealth <serviceId>]
    [-help <command>]

옵션에 대한 상세 내용은 다음과 같다.

• transitionToActive / transitionToStandby
  지정된 NameNode 의 상태를 Active 또는 Standby 상태로 전환한다.
  펜싱을 수행하려고 시도하지 않으므로 거의 사용하지 않아야 한다.
  이 명령어 대신 hdfs haadmin -faliover 를 사용하는 것이 좋다.
• failover
  failover 를 진행한다.
  이 명령어를 통해 첫 번째 NameNode 에서 두 번재 NameNode 로 failover 하게 된다.
  첫 번째 NameNode 가 Standby 상태인 경우 이 명령은 오류 없이 두 번째 NameNode 로 전환된다.
  첫 번째 NameNode 가 Active 상태인 경우 Standby 상태로 전환하려는 시도가 이루어진다.
  전환에 실패하게 되면 펜싱 방법이 성공할 때까지 순서대로 시도된다.
  이 프로세스 후에만 두 번째 NameNode 가 Active 상태로 전환된다.
  펜싱 방법이 성공하지 않으면 두 번째 NameNode 가 Active 되지 않고 오류가 반환된다.
• getServiceState
  지정된 NameNode 가 Active 인지 Standby 인지 확인한다.
  NameNode 에 연결해서 현재 상태를 확인하고 Standby 또는 Active 상태를 출력해준다.
  NameNode 가 현재 Active 인지 Standby 인지에 따라 다르게 동작해야 하는 cron 작업 또는 모니터링 스크립트에서 사용할 수 있다.
• getAllServiceState
  모든 NameNode 의 상태를 반환한다.
  구성된 모든 NameNode 에 연결해서 현재 상태를 확인하고 Standby 또는 Active 상태를 출력해준다.
• checkHealth
  지정된 NameNode 의 상태를 확인한다.
  NameNode 는 내부 서비스가 예상대로 실행되고 있는지 확인하는 것을 포함하여 일부 진단을 자체적으로 수행할 수 있다. 이 명령은 NameNode 가 정상이면 0 을 반환하고 그렇지 않으면 다른 값을 반환한다. 모니터링 목적으로 이 명령을 사용할 수 있다.
  참고로 지정된 NameNode 가 완전히 다운되지 않는 한 항상 성공을 반환한다.

 

Audomatic Failover

위에서는 수동으로 Failover 를 구성하는 방법에 대해서 설명한다. 해당 모드에서 시스템은 활성 노드가 실패하더라도 활성 노드에서 Standby NameNode 로의 Failover 를 자동으로 트리거하지 않는다. 이번에는 자동으로 Failover 를 구성하는 방법에 대해서 설명한다.

 

Failover 구성

자동 Failover 는 HDFS 배포에 아래의 두 가지 새로운 구성 요소를 추가한다.

• ZooKeeper quorum
• ZKFailoverController 프로세스 (ZKFC)

 

Apache Zookeeper 는 소량의 조정 데이터를 유지하고 해당 데이터의 변경 사항을 클라이언트에 알리고 클라이언트의 장애를 모니터링하기 위한 고갸용성 서비스이다. 자동 HDFS Failover 구현은 다음을 위해 Zookeeper 에 의존한다.

• Failure detection
  클러스터의 각 NameNode 머신은 Zookeeper 에서 영구 세션을 유지한다. 시스템이 충돌하면 Zookeeper 세션이 만료되고 다른 NameNode 에 Failover 가 트리거 되어야 함을 알린다.
• Active NameNode election
  Zookeeper 는 노드를 활성으로 독점적으로 선택하는 간단한 메커니즘을 제공한다. 현재 Active NameNode 가 충돌하면 다른 노드가 Zookeeper 에서 다음 활성 노드가 되어야 함을 나타내는 특수 배타적 잠금을 취할 수 있다.

 

ZKFC(ZKFailoverController) 는 NameNdoe 의 상태를 모니터링하고 관리하는 Zookeeper 클라이언트인 새로운 구성요소 이다. NameNode 를 실행하는 각 머신은 ZKFC 도 실행하며 다음 내용을 담당한다.

• Health monitoring
  ZKFC 는 상태 확인 명령을 사용하여 주기적으로 로컬 NameNode 를 ping 한다. NameNode 가 적시에 정상 상태로 응답하는 한 ZKFC 는 노드를 정상으로 간주한다. 노드가 충돌, 정지 또는 비정상 상태에 들어간 경우 상태 모니터는 해당 노드를 비정상으로 표시한다.
• ZooKeeper session management
  로컬 NameNode 가 정상일 때 ZKFC 는 Zookeeper 에서 열린 세션을 유지한다. 로컬 NameNode 가 활성화되면 특별한 “lock” znode 를 가진다. 이 lock 은 ephemeral nodes 에 대한 ZooKeeper 의 지원을 사용한다. 세션이 만료되면 lock node 는 자동으로 사라진다.
• ZooKeeper-baased election
  로컬 NameNode 가 정상이고 ZKFC 가 현재 lock znode 를 보유하고 있는 다른 노드가 없음을 확인하면 자체적으로 lock 을 얻으려고 시도한다. 성공하면 won the election 한 것으로 로컬 NameNode 를 활성화하기 위한 Failover 실행을 담당한다. Failover 프로세스는 위에서 설명한 수동 장애 조치와 유사하다. 먼저 필요한 경우 이전 활성이 차단된 다음 로컬 NameNode 가 활성 상태로 전환된다.

 

 

Zookeeper 배포

일반적인 배포에서 ZooKeeper 데몬은 3개 또는 5개의 노드에서 실행되도록 구성된다. ZooKeeper 자체에는 리소스 요구 사항이 적기 때문에 HDFS NameNode 및 대기 노드와 동일한 하드웨어에 ZooKeeper 노드를 배치하는 것이 허용된다. 많은 운영자가 YARN ResourceManger 와 동일한 노드에 세 번째 ZooKeeper 프로세스를 배포하도록 선택한다. 최상의 성능과 격리를 위해서 HDFS 메타데이터와 별도의 디스크 드라이브에 데이터를 저장하도록 ZooKeeper 노드를 구성하는 것이 좋다.

 

ZooKeeper 설정은 별도의 문서를 통해 확인할 수 있고 3개 이상의 노드에서 실행되는 ZooKeeper 클러스터를 설정하고 ZK CLI 를 사용하여 연결하고 올바른 작동을 확인했다고 가정한다.

 

autometic failover 구성

자동 Failover 를 구성하려면 두 개의 새로운 매개변수를 추가해야 한다.

 

hdfs-site.xml 파일에 구성을 추가한다.

<property> 
   <name>dfs.ha.automatic-failover.enabled</name> 
   <value>true</value> 
 </property>

 

또한 클러스터를 설정해야 함을 지정한다. 이 내용은 core-site.xml 파일에 추가한다.

<property> 
   <name>ha.zookeeper.quorum</name> 
   <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value> 
 </property>

이 설정에는 ZooKeeper 서비스를 실행하는 host:port 의 쌍이 나열된다.

 

자동 Failover 의 동작을 제어하도록 설정할 수 있는 몇 가지 다른 구성 매개변수도 있지만 대부분의 설치에는 필요하지 않는다. 자세한 내용은 별도로 살펴보면 좋을 것 같다.

 

 

ZooKeeper 에 HA 상태 초기화

구성 키를 추가한 다음 ZooKeeper 에서 필요한 상태를 초기화 하는 것이다. NameNode 호스트 중 하나에서 다음 명령을 실행하여 초기화 할 수 있다.

[hdfs]$ $HADOOP_HOME/bin/zkfc -formatZK

이렇게 하면 자동 Failover 시스템이 데이터를 저장하는 ZooKeeper 에 znode 가 생성된다.

 

클러스터 시작 (start-dfs.sh)

자동 Failover 가 활성화 되었으므로 start-dfs.sh 스크립트는 이제 NameNode 를 실행하는 모든 시스템에서 ZKFC 데몬을 자동으로 시작한다. ZKFC 가 시작되면 활성화할 NameNode 중 하나를 자동으로 선택한다.

 

수동으로 클러스터 시작

zkfc 클러스터에서는 서비스를 수동으로 관리하는 경우 NameNode 를 실행하는 각 시스템에서 데몬을 수동으로 시작해야 한다. 다음과 같이 시작할 수 있다.

[hdfs]$ $HADOOP_HOME/bin/hdfs --데몬 시작 zkfc

ZooKeeper 에 대한 액세스 보안

보안 클러스터를 실행중인 경우 ZooKeeper 에 저장된 정보도 보호되는지 확인하고 싶을 수 있다. 다음과 같은 방법을 통해 악의적인 클라이언트가 ZooKeeper 의 메타데이터를 수정하거나 잠재적으로 잘못된 Failover 를 트리거하는 것을 방지할 수 있다.

 

ZooKeeper 의 정보를 보호하려면 먼저 core-site.xml 파일에 추가하면 된다.

<property>
   <name>ha.zookeeper.auth</name>
   <value>@/path/to/zk-auth.txt</value>
 </property>
 <property>
   <name>ha.zookeeper.acl</name>
   <value>@/path/to/zk-acl.txt</value>
 </property>

여기서 ‘@’ 문자에 유의해야 한다. 구성이 인라인이 아니라 디스크의 파일을 가리키도록 지정한다. 인증 정보는 CredentialProvider 를 통해서 읽을 수도 있다. (hadoop-common 프로젝트의 CredentialProviderAPI 가이드 참조)

 

첫 번째 구성 파일은 ZK CLI 에서 사용하느 것과 동일한 형식으로 ZooKeeper 인증 목록을 지정한다.

digest:hdfs-zkfcs:mypassword

여기서 hdfs-zkfcs 는 ZooKeeper 의 고유한 사용자의 이름이고 mypassword 는 암호로 사용되는 고유한 문자열이다.

 

다음으로 이 인증에 해당하는 ZooKeeper ACL 을 생성한다.

[hdfs]$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=

output 에서 → 문자열 뒤의 내용을 복사해 zk-acls.txt 파일에 복사하여 붙여넣는다.

다음과 같이 붙여넣을 때 앞에 “digest:” 를 붙인다.

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

이러한 ACL 을 적용하려면 zkfc -formatZK 명령어를 다시 실행한다.

 

그리고 ZK CLI 를 통해 ACL 을 확인할 수 있다.

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

 

자동 Failover 확인

자동 Failover 가 설정되면 작동을 테스트 해야 한다. 이렇게 하려면 먼저 활성화되어있는 NameNode 를 찾는다. NameNode 웹 인터페이스에 방문하여 어떤 노드가 활성 상태인지 알 수 있다. 각 노드는 페이지 상단에 HA 상태를 보고한다.

 

활성 NameNode 를 찾으면 해당 노드에서 오류가 발생할 수 있다. 예를 들어, kill -9 명령어를 통해 JVM 충돌을 시뮬레이션할 수 있다. 또는 시스템 전원을 껏다 켜거나 네트워크 인터페이스를 분리하여 다은 종류의 중단을 시뮬레이션 할 수 있다. 테스트하려는 중단을 트리거한 후 다른 NameNode 가 몇 초 내에 자동으로 활성화 되어야 한다. 장애를 감지하고 Failover 를 트리거하는데 필요한 시간은 ha.zookeeper.session-timeout.ms 의 구성에 따라 다르지만 기본 값은 5초 이다.

 

테스트에 실패하면 구성이 잘못되었을 수도 있어 zkfc 문제를 추가로 진단하려면 데몬과 NameNode 데몬의 로그를 확인하면 된다.