728x90
반응형

아래의 문서를 참고해서 정리해봤다.
이 문서는 하둡 3.3.5 버전 을 기준으로 작성되어있다.
영어로 작성되어있어 공부할겸 열심히 해석해가며 정리해보았다.

 

Apache Hadoop 3.3.5 – HDFS High Availability

 

Apache Hadoop 3.3.5 – HDFS High Availability

<!--- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or a

hadoop.apache.org

 

 

HA 구성의 배경

Hadoop 2.0 버전 이전에는 Name Node 가 HDFS 클러스터의 SPOF 가 발생했다.

각 클러스터에는 단일 Name Node 가 있으며 해당 시스템이나 프로세스를 사용할 수 없게 되면 Name Node 가 다시 시작되거나 별도의 시스템에서 실행될 때까지 전체 클러스터를 사용할 수 없었다.

 

다음 두 가지 주요 방식으로 HDFS 클러스터의 전체 가용성에 대해 영향을 미쳤다.

  • machine crash 와 같은 계획되어있지 않은 이벤트가 발생할 경우 운영자가 Name Node 를 다시 시작할 때까지 클러스터를 사용할 수 없었다.
  • Name Node 시스템의 소프트웨어 또는 하드웨어 업그레이드와 같은 계획된 유지 관리 이벤트가 생길 경우 클러스터의 가동 중지 시간이 발생한다.

 

따라서, HDFS HA 구성은 위의 문제들을 같은 클러스터 내에서 2개 이상 중복된 Name Node 또는 하둡 3.0 버전 이상에서 hot standby 와 함께 Active/Passive 의 실행 옵션을 제공하여 문제를 해결하고 있다.

 

이를 통해 시스템이 충돌하는 경우 새 Name Node 로 빠른 장애 조치를 수행하거나 계획된 유지 관리를 위해 정상적인 관리자 권한으로 인해 조치를 할 수 있다.

 

 

HA 구성

일반적인 HA 구성의 클러스터에서는 둘 이상의 개별 시스템이 Name Node 로 구성된다.
언제든지 Name Node 중 정확히 하나는 Active 상태이고 나머지는 Standby 상태이다.
Active 상태인 Name Node 는 클러스터의 모든 클라이언트 작업을 담당하는 반면에
Standby 상태의 Name Node 는 단순히 슬레이브로 작동하여 필요한 경우 빠른 장애 조치를 제공할 수 있는 충분한 상태를 유지한다.

 

Standby Name Node 가 Active Name Node 와 동기화된 상태를 유지하기 위해 현재 구현에서는 노드가 공유 저장 장치의 디렉토리에 액세스 할 수 있어야 한다. 이후 이러한 부분이 개선된다고 한다.
다시 말해 공유 저장 장치의 디렉토리를 Active, Standby 상태의 Name Node 모두가 접근이 가능해야 한다.

 

Active 노드는 네임스페이스 수정이 수행되면 공유 디렉터리에 저장된 편집 로그 파일에 수정 기록을 영구적으로 기록한다.
Standby 노드는 이 디렉터리에서 편집 내용을 지속적으로 감시하고 있으며 편집 내용을 확인하면 자체 네임스페이스에 적용한다. 장애 조치가 발생하면 Standby 는 자신을 활성 상태로 승격시키기 전에 공유 스토리지에서 모든 편집 내용을 읽었는지 확인한다. 이렇게 하면 장애 조치가 발생하기 전에 네임스페이스 상태가 완전히 동기화 된다.

 

빠른 장애 조치를 제공하기 위해서는 Standby 노드가 클러스터의 블록 위치에 대한 최신 정보를 가지고 있어야 한다. 이를 달성하기 위해서 Data Node 는 모든 Name Node 의 위치가 구성되어야 하고 모든 Name Node 에게 블록의 위치 정보와 Heartbeat 를 보낸다.
Name Node 중 하나만 한 번에 활성화되는 HA 클러스터의 올바른 작동에 매우 중요하다.
그렇지 않으면 네임스페이스 상태가 둘 사이에서 빠르게 분기되어 데이터 소실 또는 다른 잘못된 결과의 위험이 있다.

 

“split-brain scenario” 를 방지하기 위해서 관리자는 공유 스토리지에 대한 최소한의 하나의 펜싱 방법을 구성해야 한다. 장애 조치 중에 이전 활성 노드가 활성 상태를 포기했는지 확인할 수 없는 경우 펜싱 프로세스는 공유 편집 저장소에 대한 이전 활성의 엑세스를 차단해야 한다. 이렇게 하면 네임스페이스를 더 이상 편집할 수 없으므로 새로운 Active 가 안전하게 장애 조치를 진행할 수 있다.

 

다시 정리해보면 현재 Active 상태의 Name Node 의 상태를 알 수 없는 경우 공유 편집 저장소에 대한 접근을 차단함으로써 현재의 Name Node 가 네임스페이스를 더 이상 편집할 수 없게 되고 그렇게 새로운 Name Node 를 Active 상태로 만들어주면서 안전하게 장애 조치를 진행하게 된다.

 

 

HA 구성을 위한 하드웨어 리소스

HA 클러스터를 배포하려면 다음과 같이 준비가 되어있어야 한다.

Name Node 시스템

Active / Standby Name Node 를 실행하는 시스템에는 서로 동등한 하드웨어 및 non-HA 클러스터에서 사용되는 것과 동일한 하드웨어가 있어야 한다.

 

공유 스토리지

Name Node 가 읽기/쓰기 접근 권한을 가진 공유 디렉토리가 필요하다.
일반적으로 이것은 NFS 를 지원하고 각 Name Node 시스템에 마운트되는 원격 파일러이다.


현재 단일 공유 편집 디렉토리만 지원된다. 따라서 시스템의 가용성은 이 공유 편집 디렉토리의 가용성에 의해 제한되므로 모든 SPOF 를 제거라혀면 공유 편집 디렉토리에 대한 중복성이 필요하다.
특히 스토리지에 대한 다중 네트워크 경로 및 스토리지 자체의 이중화(디스크, 네트워크 및 전원)가 필요하다.
이러한 이유 때문에 공유 스토리지 서버는 단순히 리눅스 서버가 아닌 고품질의 전용 NAS 기기를 권장한다.


HA 클러스터에서 Standby Name Node 는 네임스페이스 상태의 체크포인트도 수행하므로 HA 클러스터에서 Secondary Name Node, CheckpointNode 또는 BackupNode 를 실행할 필요가 없다.
실제로 그렇게 하는 것은 잘못된 방법이다. 또한 HA 가 활성화되지 않은 HDFS 클러스터를 재구성하는 사람이 이전에 보조 Name Node 전용으로 사용했던 하드웨어를 재사용할 수 있도록 허용한다.

728x90
반응형
복사했습니다!