HDFS High Availability

1. Purpose(목적)

이 가이드에서는 NameNode에 필요한 공유 스토리지에 NFS를 사용하여 HDFS HA(High Availability) 기능에 대한 개요와 HA HDFS 클러스터를 구성하고 관리하는 방법을 제공합니다. 이 문서에서는 HDFS 클러스터의 일반 구성 요소와 노드 유형에 대해 일반적으로 이해하고 있다고 가정합니다. 

 

2. Background (배경)

Hadoop 2.0.0 이전의 NameNode는 HDFS 클러스터에서 단일 장애 지점(SPOF)이었습니다. 각 클러스터에는 단일 NameNode가 있으며, 해당 시스템 또는 프로세스를 사용할 수 없게 되면 NameNode가 재시작되거나 별도의 시스템에서 실행될 때까지 클러스터를 전체적으로 사용할 수 없게 됩니다.

이는 HDFS 클러스터의 총 가용성에 크게 두 가지 영향을 미쳤습니다. 

 

• 시스템 충돌과 같이 계획되지 않은 이벤트가 발생할 경우 운영자가 NameNode를 재시작할 때까지 클러스터를 사용할 수 없습니다.
  
• NameNode 시스템에서 소프트웨어 또는 하드웨어 업그레이드와 같은 계획된 유지 보수 이벤트로 인해 클러스터 downtime(작동하지않는 시간)이 발생할 수 있습니다.

 

HDFS High Availability 기능은 동일한 클러스터에서 상시대기 상태의 Active/Passive 구성에서 두 개의 중복 NameName를 실행할 수 있는 옵션을 제공하여 위의 문제를 해결합니다. 따라서 시스템이 충돌할 경우 새 NameNode로 신속하게 failover하거나 계획된 유지 보수를 위한 관리자 시작 failover를 수행할 수 있습니다.

 

3. Architecture (구조)

일반적인 HA 클러스터에서는 두 대 이상의 NameNode로 구성됩니다. 언제든지 NameNode 중 정확히 하나는 활성 상태이고 다른 하나는 대기 상태입니다. Active NameNode는 클러스터의 모든 클라이언트 작업을 담당하는 반면, Standby NameNode는 slave 역할을 수행하며 필요한 경우 빠른 failover를 제공할 수 있는 충분한 상태를 유지합니다.

 

Standby node가 Active node와 상태를 동기화하려면 현재 구현에서는 node가 공유 스토리지 디바이스(예: NAS의 NFS 마운트)의 디렉토리에 액세스할 수 있어야 합니다. 이 제한은 이후 버전에서 완화될 수 있습니다.(3.3.0)

 

Active node에 의해 Namespace 수정이 수행되면 공유 디렉토리에 저장된 편집 로그 파일에 영구적으로 수정 레코드를 기록합니다. Standby node는 이 디렉터리에서 편집 내용을 계속 보고 있으며 편집 내용을 볼 때 자체 Namespace에 적용합니다. failover가 발생할 경우, Standby 상태는 해당 기능을 Active 상태로 승격하기 전에 공유 스토리지의 모든 편집 내용을 읽었는지 확인합니다. 이렇게 하면 failover가 발생하기 전에 Namespace 상태가 완전히 동기화됩니다.

 

4. Hardware resources

HA 클러스터를 배포하려면 다음을 준비해야 합니다.

 

• NameNode machines - 활성 및 대기 이름 노드를 실행하는 시스템에는 서로 동등한 하드웨어가 있어야 하며 비 HA 클러스터에서 사용되는 것과 동등한 하드웨어가 있어야 합니다.
• Shared storage - NameNode 시스템이 읽기/쓰기 액세스 권한을 가진 공유 디렉터리를 가져야 합니다. 일반적으로 NFS를 지원하고 각 NameNode 시스템에 마운트된 원격 파일러입니다. 현재 단일 공유 편집 디렉토리만 지원됩니다. 따라서, 시스템의 가용성은 이 공유 편집 디렉토리의 가용성에 의해 제한되므로, 모든 단일 실패 지점을 제거하기 위해서는 공유 편집 디렉토리에 대한 이중화가 필요합니다. 특히 스토리지에 대한 여러 네트워크 경로와 스토리지 자체(디스크, 네트워크 및 전원)의 이중화입니다. 따라서 공유 스토리지 서버는 단순한 리눅스 서버보다는 고품질 전용 NAS 장치일 것을 권장합니다.

HA 클러스터에서 대기 이름 노드는 네임스페이스 상태의 체크포인트도 수행하므로 HA 클러스터에서 보조 이름 노드, CheckpointNode 또는 BackupNode를 실행할 필요가 없습니다. 사실, 그렇게 하는 것은 오류가 될 수 있습니다. 이를 통해 HA를 지원하지 않는 HDFS 클러스터를 HA를 사용하도록 재구성하는 사용자가 이전에 Secondary NameNode 전용이었던 하드웨어를 재사용할 수 있습니다.

 

5. Deployment

5-1. Configuration overview (구성 개요)

Federation 구성과 마찬가지로 HA 구성은 역호환성이므로 기존 단일 NameNode 구성이 변경 없이 작동할 수 있습니다. 새 구성은 노드 유형에 따라 서로 다른 구성 파일을 서로 다른 시스템에 배포할 필요 없이 클러스터의 모든 노드가 동일한 구성을 가질 수 있도록 설계되었습니다.

HDFS Federation과 마찬가지로 HA 클러스터도 이름 서비스 ID를 재사용하여 여러 개의 HA NameNode로 구성될 수 있는 단일 HDFS 인스턴스를 식별합니다. 또한 NameNode ID라는 새로운 추상화가 HA와 함께 추가됩니다. 클러스터의 각 고유 NameNode는 이를 구별하기 위해 다른 NameNode ID를 가집니다. 모든 NameNode에 대해 단일 구성 파일을 지원하기 위해 관련 구성 매개 변수는 NameNode ID와 NameNode ID가 함께 제공됩니다.

 

5-2. Configuration details (구성 상세)

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

이러한 구성을 설정하는 순서는 중요하지 않지만 dfs.name 서비스와 dfs.ha.name 노드에 대해 선택한 값은 중요하지 않습니다.[namesservice ID]가 다음에 오는 사람들의 키를 결정합니다. 따라서 나머지 구성 옵션을 설정하기 전에 이러한 값을 결정해야 합니다.

• dfs.nameservices - the logical name for this new nameservice
• nameservices의 논리 이름(예: "mycluster")을 선택하고 이 구성 옵션의 값에 이 logical name을 사용합니다. 선택한 name은 임의 이름입니다. 구성 및 클러스터 내 절대 HDFS 경로의 권한 구성 요소로 사용됩니다.

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

Note : HDFS Federation도 사용하는 경우 이 구성 설정에는 다른 이름 서비스(HA 또는 기타) 목록도 쉼표로 구분된 목록으로 포함되어야 합니다.

 

• dfs.ha.namenodes.[nameservice ID] - nameservices의 각 NameNode에 대한 고유 식별자입니다.
• 쉼표로 구분된 NameNode ID 목록으로 구성합니다. DataNode는 클러스터의 모든 NameNode를 결정하는 데 사용됩니다. 예를 들어 이전에 이름 서비스 ID로 "mycluster"를 사용하고 NameNode의 개별 ID로 "nn1", "nn2" 및 "nn3"을 사용하려는 경우 다음과 같이 구성할 수 있습니다.

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

Note : HA의 최소 NameNode 수는 2개이지만 추가로 구성할 수 있습니다. 통신 오버헤드로 인해 권장되는 3개의 Name 노드로 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>

 

Note : 원할 경우 "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>

Note : Hadoop의 보안 기능을 사용하도록 설정한 경우 각 NameNode에 대해 https-address도 유사하게 설정해야 합니다.

 

• dfs.namenode.shared.edits.dir - 공유 저장소 디렉터리의 위치입니다.
• Standby NameNodes가 Active 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 클래스입니다.
• DFS 클라이언트에서 사용할 Java 클래스의 이름을 구성하여 현재 활성 인 NameNode를 확인하고 현재 클라이언트 요청을 처리하는 NameNode를 결정합니다. 현재 Hadoop과 함께 제공되는 두 가지 구현은 ConfiguredFailoverProxyProvider(첫 번째 호출의 경우, 모든 namenodes를 동시에 호출하여 활성 노드를 결정하고 후속 요청에서 장애 조치가 발생할 때까지 활성 이름 노드를 호출) 및 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 - failover 중에 Active NameNode를 고정하는데 사용 할 스크립트 또는 Java 클래스 목록입니다.
• 주어진 시간에 하나의 NameNode만 Active 상태에 있는 것이 시스템의 정확성을 위해 중요합니다. 따라서 장애 조치 중에 다른 NameNode를 Active 상태로 전환하기 전에 먼저 Active NameNode가 Standby 상태에 있거나 프로세스가 종료되었는지 확인합니다. 이렇게하려면 적어도 하나의 fencing method(차단 방법)을 구성해야합니다. 이들은 carriage-return-separated 목록으로 구성되며, fencing이 성공했음을 나타낼 때까지 순서대로 시도됩니다. Hadoop과 함께 제공되는 두 가지 방법은 shell과 sshfence입니다. 

sshfence - SSH를 Active NameNode에 연결하고 프로세스를 제거합니다.

sshfence 옵션은 대상 노드에 SSH를 전송하고 fuser를 사용하여 서비스의 TCP 포트에서 프로세스 수신을 제거합니다. 이 fencing 옵션이 작동하려면 암호를 제공하지 않고 대상 노드에 SSH 할 수 있어야 합니다. 따라서 SSH 개인 키 파일(id_rsa)의 쉼표로 구분된 목록인 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에 대한 시간 초과(밀리초)를 구성할 수도 있습니다. 이 시간이 지나면 이 fencing method는 실패한 것으로 간주됩니다.

<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를 fence로 설정합니다.

셸 펜싱 메서드는 임의 셸 명령을 실행합니다. 다음과 같이 구성할 수 있습니다.

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

'('and ')' 사이의 문자열은 bash shell에 직접 전달되며, 닫히는 괄호를 포함하지 않을 수 있습니다.

shell 명령은 현재 Hadoop 구성 변수를 모두 포함하도록 설정된 환경에서 실행되며, 구성 키의 '.' 문자를 '_' 문자로 바꿉니다. 사용된 구성에서 대상 노드의 RPC 주소가 dfs.namenode.rpc-address.ns1.nn1로 지정되더라도 dfs_namenode_rpc-address는 이미 일반 형식으로 승격된 이름 노드별 구성을 가지고 있습니다.

 

또한 fenced 대상 노드를 참조하는 다음과 같은 변수도 사용할 수 있습니다.

$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

이러한 환경 변수는 shell 명령 자체에서 대체 변수로 사용될 수도 있습니다.

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

shell 명령이 종료 코드 0을 반환하는 경우 fencing이 성공적으로 결정됩니다. 다른 종료 코드를 반환할 경우 fencing은 성공하지 못했으며 목록의 다음 fencing 방법을 시도합니다.

Note :  이 펜싱 방법은 시간 초과를 구현하지 않습니다. 시간 초과가 필요한 경우 셸 스크립트 자체에서 구현해야 합니다(예: 몇 초 안에 하위 셸을 강제 제거하여 상위 셸을 죽임).

 

• fs.defaultFS - Hadoop FS 클라이언트가 none을 지정하면 default path 접두사가 사용됩니다.

필요한 경우 이제 Hadoop client가 새 HA 지원 논리 URI를 사용하도록 기본 경로를 구성할 수 있습니다. 이전에 nameservice ID로 "mycluster"를 사용한 경우 이 값은 모든 HDFS 경로의 권한 부분의 값이 됩니다. core-site.xml 파일에서 다음과 같이 구성할 수 있습니다.

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

 

• dfs.ha.nn.not-become-active-in-safemode - NameNode 안전 모드가 Active되지 않도록 하는 경우

Namenode가 안전 모드 일 때 Active 되도록 허용할지 여부로, true로 설정되면 안전 모드의 Namenode는 auto failover가 on인 경우, SERVICE_UNHEALTHY를 ZKFC에보고하거나, auto failover가 off인 경우 활성화로 전환하지 못하도록 예외를 던집니다.

<property>
  <name>dfs.ha.nn.not-become-active-in-safemode</name>
  <value>true</value> //기본값은 false
</property>

 

5-4. Deploymentdetails (배포 세부 정보)

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

• 새로운 HDFS 클러스터를 설정하는 경우 먼저 NameNode 중 하나에서 format 명령 (hdfs namenode -format)을 실행해야합니다.
• NameNode를 이미 포맷했거나 HA가 지원되지 않는 클러스터를 HA가 사용하도록 변환하는 경우, NameNode 메타데이터 디렉토리의 내용을 포맷되지 않은 NameNode에서 "hdfs namenode -bootstrap Standby" 명령을 실행하여 다른 포맷되지 않은 NameNode로 복사해야 합니다. 이 명령을 실행하면 shared edits directory(dfs.namenode.shared.edits.dir에 구성된 대로)에 두 NameNode를 모두 시작할 수 있는 충분한 편집 트랜잭션이 포함되어 있는지도 확인합니다.
• HA가 아닌 NameNode를 HA로 변환하는 경우 "hdfs -initializeSharedEdits"명령을 실행하여 로컬 NameNode 편집 디렉토리의 편집 데이터로 공유 편집 디렉토리를 초기화해야합니다.

이 때 NameNode를 시작할 때와 마찬가지로 모든 HA NameNode를 시작할 수 있습니다.

구성된 HTTP 주소를 찾아 각 NameNode의 웹 페이지를 개별적으로 방문할 수 있습니다. 구성된 주소 옆에는 HA(“standby” or “active”)  NameNode가 시작될 때마다 NameNode의 HA 상태가 유지되며 처음에는 대기 상태에 있습니다.

 

5-5. Administrative commands

이제 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>]

이 가이드에서는 이러한 각 하위 명령의 높은 사용 방법에 대해 설명합니다. 각 하위 명령의 특정 사용 정보를 보려면 "hdfs haadmin -help <command>"를 실행해야 합니다.

• transitionToActive and transitionToStandby - transition the state of the given NameNode to Active or Standby
• These subcommands cause a given NameNode to transition to the Active or Standby state, respectively. These commands do not attempt to perform any fencing, and thus should rarely be used. Instead, one should almost always prefer to use the “hdfs haadmin -failover” subcommand.
• failover - initiate a failover between two NameNodes
• This subcommand causes a failover from the first provided NameNode to the second. If the first NameNode is in the Standby state, this command simply transitions the second to the Active state without error. If the first NameNode is in the Active state, an attempt will be made to gracefully transition it to the Standby state. If this fails, the fencing methods (as configured by dfs.ha.fencing.methods) will be attempted in order until one succeeds. Only after this process will the second NameNode be transitioned to the Active state. If no fencing method succeeds, the second NameNode will not be transitioned to the Active state, and an error will be returned.
• getServiceState - determine whether the given NameNode is Active or Standby
• Connect to the provided NameNode to determine its current state, printing either “standby” or “active” to STDOUT appropriately. This subcommand might be used by cron jobs or monitoring scripts which need to behave differently based on whether the NameNode is currently Active or Standby.
• getAllServiceState - returns the state of all the NameNodes
• Connect to the configured NameNodes to determine the current state, print either “standby” or “active” to STDOUT appropriately.
• checkHealth - check the health of the given NameNode
• Connect to the provided NameNode to check its health. The NameNode is capable of performing some diagnostics on itself, including checking if internal services are running as expected. This command will return 0 if the NameNode is healthy, non-zero otherwise. One might use this command for monitoring purposes.

Note : 이 기능은 아직 구현되지 않았으며, 지정된 NameNode가 완전히 다운되지 않는 한 현재에는 항상 성공을 반환할 것입니다.

 

*6. Automatic Failover (자동 장애 조치)

6-1. Introduction (소개)

위의 섹션에서는 수동 failover를 구성하는 방법에 대해 설명합니다. 이 모드에서는 Active 노드가 실패하더라도 시스템에서 Active 노드에서 Standby NameNode로 failover를 자동으로 트리거하지 않습니다. 이 섹션에서는 자동 failover를 구성하고 배포하는 방법에 대해 설명합니다.

 

6-2. components (구성요소)

자동 failover 조치는 HDFS 배포에 ZooKeeper quorum과 ZKFailoverController 프로세스 (ZKFC로 약칭)라는 두 가지 새로운 구성 요소를 추가합니다.

Apache ZooKeeper는 적은 양의 조정 데이터를 유지하고, 해당 데이터의 변경 사항을 클라이언트에 통지하고, 클라이언트의 장애를 모니터링하는 데 매우 유용한 서비스입니다. 자동 HDFS failover의 구현은 다음과 같은 작업을 위해 ZooKeeper를 사용합니다.

• Failure detection (실패감지) - 클러스터의 각 NameNode 시스템은 ZooKeeper에서 영구 세션을 유지합니다. 시스템이 충돌하면 ZooKeeper 세션이 만료되어 다른 NameNode에 장애 조치가 트리거되어야 함을 알립니다.
• Active NameNode election(활성 NameNode 선거) - ZooKeeper는 노드를 활성노드로만 선택하는 간단한 메커니즘을 제공합니다. 현재 활성 NameNode가 충돌하면 다른 노드가 ZooKeeper에서 특별한 독점 잠금을 사용하여 다음 활성 상태가되어야 함을 나타낼 수 있습니다.

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

 

• Health monitoring - ZKFC는 상태 확인 명령을 사용하여 주기적으로 로컬 NameNode를 통신 상태를 검사합니다. NameNode가 적절한 시기에 healthy status 로 응답하는 한, ZKFC는 노드를 정상으로 간주합니다. 노드가 충돌, 고정 또는 비정상 상태에 들어간 경우 상태 모니터는 노드를 비정상으로 표시합니다.
• ZooKeeper session management - 로컬 NameNode가 정상일 때 ZKFC는 ZooKeeper에서 세션을 열어 둡니다. 로컬 NameNode가 Active 상태인 경우 특별한 "lock" zNode도 보유합니다. 이 lock은 "ephemeral(임시)"노드에 대한 ZooKeeper의 지원을 사용합니다. 세션이 만료되면 잠금 노드가 자동으로 삭제됩니다.
• ZooKeeper-based election - 로컬 NameNode가 정상이고 ZKFC가 현재 잠금 znode를 보유하고있는 다른 노드가 없음을 확인하면 자체적으로 lock 획득을 시도합니다. 성공하면 "won the election (선거에서 승리)"한 것이며 로컬 NameNode를 Active하기 위해 failover를 실행해야합니다. failover 프로세스는 위에서 설명한 수동 failover와 유사합니다. 먼저 필요한 경우 이전 Active가 차단 된 다음 로컬 NameNode가 Active 상태로 전환됩니다.

6-3. Deploying ZooKeeper (ZooKeeper 배포)

일반적인 배포에서 ZooKeeper 데몬은 3개 또는 5개의 노드에서 실행되도록 구성됩니다. ZooKeeper 자체에는 가벼운 리소스 요구 사항이 있으므로, HDFS NameNode 및 Standby Node와 동일한 하드웨어에 ZooKeeper 노드를 배치 할 수 있습니다. 많은 관리자는 세 번째 ZooKeeper 프로세스를 YARN ResourceManager와 동일한 노드에 배포하기로 선택합니다. 최상의 성능과 분리를 위해 ZooKeeper 노드를 구성하여 HDFS 메타데이터와 별도의 디스크 드라이브에 데이터를 저장하는 것이 좋습니다.

 

6-4. Before you begin

자동 failover 구성을 시작하기 전에 클러스터를 종료해야합니다. 현재 클러스터가 실행되는 동안에는 수동 failover 설정에서 자동 failover 설정으로 전환 할 수 없습니다.

 

6-5. Configuring automatic failover (자동 failover 설정)

자동 failover를 구성하려면 구성에 두 개의 새 매개 변수를 추가해야 합니다. hdfs-site.xml 파일에서 다음을 추가합니다.

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

 

자동 failover를 위해 클러스터를 설정해야 합니다. core-site.xml 파일에 있습니다.

ZooKeeper 서비스를 실행하는 host-port 쌍을 나열합니다.

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

문서의 앞부분에서 설명한 매개 변수와 마찬가지로 이러한 설정은 구성 키에 nameservice ID를 추가하여 nameservice별로 구성 할 수 있습니다. 예를 들어, faderation을 사용하도록 설정된 클러스터에서 dfs.ha.automatic-failover.enabled.my-namesservice-id를 설정하여 이름 서비스 중 하나에 대해서만 자동 failover를 사용하도록 명시적으로 설정할 수 있습니다.

 

자동 failover 조치의 동작을 제어하기 위해 설정할 수있는 몇 가지 다른 구성 매개 변수도 있습니다. 그러나 대부분의 설치에는 필요하지 않습니다. 자세한 내용은 구성 키 관련 문서를 참조하세요.

 

6-6. Initializing HA state in ZooKeeper (ZooKeeper에서 HA 상태 초기화)

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

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

그러면 자동 장애 조치 시스템이 데이터를 저장하는 ZooKeeper에 znode가 생성됩니다.

 

6-7. Starting the cluster with start-dfs.sh (start-dfs.sh로 cluster 시작)

구성에서 자동 페일오버가 사용되도록 설정되었으므로 이제 start-dfs.sh 스크립트가 NameNode를 실행하는 모든 시스템에서 ZKFC 데몬을 자동으로 시작합니다. ZKFC가 시작되면 자동으로 NameNode 중 하나를 선택하여 Active(활성화)됩니다.

 

6-8. Starting the cluster manually (수동으로 cluster 시작)

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

[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start zkfc

 

 

6-9. Securing access to ZooKeeper (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를 통해 읽을 수도 있습니다 (pls는 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=

'->' 문자열 뒤에 있는 이 출력의 섹션을 복사하여 zk-accls 파일에 붙여넣습니다.txt, 접두사 앞에 "filename:" 문자열이 붙습니다. 예를 들어 다음과 같습니다.

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

이러한 ACL을 적용하려면 위에서 설명한 대로 zkfc-formatZK 명령을 다시 실행해야 합니다.
이 작업을 수행한 후 다음과 같이 ZK CLI에서 ACL을 확인할 수 있습니다.

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

 

6-10. Verifying automatic failover (자동 failover 확인)

자동 failover를 설정한 후에는 작동을 테스트해야 합니다. 이렇게 하려면 먼저 Active NameNode를 찾으십시오. NameNode 웹 인터페이스(http://localhost:9870)를 방문하면 어떤 노드가 활성 상태인지 알 수 있습니다. 각 노드는 페이지 상단에 HA 상태를 보고합니다.

 

Active NameNode를 찾았으면 해당 노드에서 오류가 발생시킬 수 있습니다. 예를 들어 kill -9 <pid of NN>(강제종료)을 사용하여 JVM 충돌을 시뮬레이션할 수 있습니다. 또는 기계의 전원을 껐다가 켜거나 네트워크 인터페이스를 분리하여 다른 유형의 중단을 시뮬레이션할 수도 있습니다. 테스트할 중단을 트리거한 후 다른 NameNode가 몇 초 내에 자동으로 활성화됩니다. 장애를 감지하고 failover를 트리거하는 데 필요한 시간은 ha.zookeeper의 구성에 따라 달라집니다. session-timeout.ms이지만 기본값은 5초입니다.

 

테스트가 실패하면 구성이 잘못되어 있을 수 있습니다. 문제를 추가로 진단하려면 zkfc 데몬 및 NameNode 데몬에 대한 로그를 확인하세요.