ResourceManager Restart

ResourceManager는 YARN에서 실행되는 애플리케이션을 스케줄링하고 리소스를 관리하는 중앙 권위자입니다. 따라서 Apache YARN 클러스터에서 잠재적인 단일 장애 지점입니다. 이 문서는 ResourceManager가 재시작을 거쳐도 계속 기능하고, ResourceManager 다운타임이 최종 사용자에게 보이지 않게 만드는 기능인 ResourceManager Restart의 개요를 제공합니다.

출처: 문서

본문

개요 (Overview)

ResourceManager는 YARN에서 실행되는 애플리케이션을 스케줄링하고 리소스를 관리하는 중앙 권위자입니다. 따라서 잠재적 단일 장애 지점입니다. ResourceManager Restart(재시작)는 RM이 재시작을 거쳐도 계속 기능하고, RM 다운타임이 최종 사용자에게 보이지 않게 만드는 기능입니다.

ResourceManager에는 두 가지 재시작 유형이 있습니다:

비-작업-보존(Non-work-preserving) RM 재시작: 이 재시작은 애플리케이션/시도 상태와 기타 자격 증명 정보를 플러그형 상태 저장소(state-store)에 영구화하도록 RM을 향상시킵니다. RM은 재시작 시 이 정보를 상태 저장소에서 다시 로드하고 이전에 실행 중이던 애플리케이션을 다시 시작합니다. 사용자는 애플리케이션을 다시 제출할 필요가 없습니다.
작업-보존(Work-preserving) RM 재시작: 이는 재시작 시 NodeManager의 컨테이너 상태와 ApplicationMaster의 컨테이너 요청을 결합하여 RM의 실행 상태를 재구성하는 것에 초점을 맞춥니다. Non-work-preserving RM 재시작과의 핵심 차이는, 이전에 실행 중이던 애플리케이션이 RM 재시작 후에도 죽지 않아서 RM 중단으로 인해 애플리케이션이 작업을 잃지 않는다는 것입니다.

기능 (Feature)

비-작업-보존 RM 재시작

비-작업-보존 RM 재시작에서 RM은 클라이언트가 애플리케이션을 제출할 때 애플리케이션 메타데이터(즉 ApplicationSubmissionContext)를 플러그형 상태 저장소에 저장하고, 애플리케이션이 완료될 때 완료 상태(failed, killed, 또는 finished)와 진단 같은 애플리케이션의 최종 상태도 저장합니다. 또한 RM은 보안 환경에서 작업하기 위한 보안 키, 토큰 같은 자격 증명도 저장합니다. RM이 종료될 때, 필요한 정보(즉 애플리케이션 메타데이터와, 보안 환경에서 실행 중이면 함께 있는 자격 증명)가 상태 저장소에 있다면, RM이 재시작될 때 상태 저장소에서 애플리케이션 메타데이터를 가져와 애플리케이션을 다시 제출할 수 있습니다. RM이 다운되기 전에 이미 완료된(failed, killed, finished) 애플리케이션은 다시 제출하지 않습니다.

RM 다운타임 동안 NodeManager와 클라이언트는 RM이 올라올 때까지 RM을 계속 폴링합니다. RM이 올라오면 heartbeat를 통해 통신하고 있던 모든 NodeManager와 ApplicationMaster에 re-sync 명령을 보냅니다. NM은 관리하던 모든 컨테이너를 죽이고 RM에 다시 등록합니다. 이렇게 다시 등록된 NodeManager는 새로 합류하는 NM과 유사합니다. AM(예: MapReduce AM)은 re-sync 명령을 받으면 종료될 것으로 예상됩니다. RM이 재시작되어 모든 애플리케이션 메타데이터, 자격 증명을 상태 저장소에서 로드하고 메모리에 채운 후, 아직 완료되지 않은 각 애플리케이션에 대해 새 attempt(즉 ApplicationMaster)를 생성하고 평소대로 해당 애플리케이션을 다시 시작합니다. 앞서 설명한 대로 이전에 실행 중이던 애플리케이션의 작업은, 본질적으로 re-sync 명령을 통해 RM이 죽이므로 이 방식에서는 손실됩니다.

작업-보존 RM 재시작

작업-보존 RM 재시작에서 RM은 애플리케이션 상태의 영구성을 보장하고 복구 시 그 상태를 다시 로드합니다. 이 재시작은 주로 YARN 클러스터의 전체 실행 상태를 재구성하는 것에 초점을 맞추며, 그 대부분은 모든 컨테이너의 수명주기, 애플리케이션의 헤드룸과 리소스 요청, 큐의 리소스 사용량 등을 추적하는 RM 내부의 중앙 스케줄러 상태입니다. 이렇게 하면 non-work-preserving RM 재시작에서처럼 AM을 죽이고 애플리케이션을 처음부터 다시 실행할 필요가 없습니다. 애플리케이션은 간단히 RM과 다시 동기화하고 멈춘 지점부터 재개할 수 있습니다.

RM은 모든 NM에서 보내진 컨테이너 상태를 활용하여 실행 상태를 복구합니다. NM은 재시작된 RM과 다시 동기화할 때 컨테이너를 죽이지 않습니다. 컨테이너를 계속 관리하고 다시 등록할 때 컨테이너 상태를 RM으로 보냅니다. RM은 이러한 컨테이너 정보를 흡수하여 컨테이너 인스턴스와 관련 애플리케이션의 스케줄링 상태를 재구성합니다. 한편 AM은 미충족 리소스 요청을 RM에 다시 보내야 합니다. RM이 종료될 때 충족되지 않은 요청을 잃을 수 있기 때문입니다. AMRMClient 라이브러리를 사용해 RM과 통신하는 애플리케이션 작성자는 re-sync 시 AM이 RM에 리소스 요청을 다시 보내는 부분에 대해 걱정할 필요가 없습니다. 이는 라이브러리 자체가 자동으로 처리하기 때문입니다.

Configurations

이 절은 RM Restart 기능을 활성화하는 데 관련된 구성을 설명합니다.

RM 재시작 활성화

RM 상태 영구화를 위한 상태 저장소 구성

| Property | Description | | yarn.resourcemanager.store.class | 애플리케이션/시도 상태와 자격 증명을 저장하는 데 사용할 상태 저장소의 클래스 이름. 사용 가능한 상태 저장소 구현은 org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore(ZooKeeper 기반), org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore(HDFS와 local FS 같은 Hadoop FileSystem 기반), org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore(LevelDB 기반)입니다. 기본값은 org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore입니다. |

상태 저장소 구현 선택 방법

ZooKeeper 기반 상태 저장소: 사용자는 RM 재시작 설정에 어떤 저장소든 자유롭게 선택할 수 있지만, RM HA를 지원하려면 ZooKeeper 기반 상태 저장소를 사용해야 합니다. 그 이유는 여러 RM이 동시에 active라고 가정하고 상태 저장소를 편집할 수 있는 스플릿-브레인 상황을 피하기 위한 펜싱(fencing) 메커니즘을 지원하는 것은 ZooKeeper 기반 상태 저장소뿐이기 때문입니다.
FileSystem 기반 상태 저장소: HDFS와 local FS 기반 상태 저장소가 지원됩니다. 펜싱 메커니즘은 지원되지 않습니다.
LevelDB 기반 상태 저장소: LevelDB 기반 상태 저장소는 HDFS와 ZooKeeper 기반 상태 저장소보다 더 가볍다고 간주됩니다. LevelDB는 더 나은 원자적 연산, 상태 업데이트당 더 적은 I/O 연산, 그리고 파일시스템에 훨씬 더 적은 총 파일 수를 지원합니다. 펜싱 메커니즘은 지원되지 않습니다.

Hadoop FileSystem 기반 상태 저장소 구현 구성

HDFS와 local FS 기반 상태 저장소 구현을 모두 지원합니다. 사용할 파일시스템 유형은 URI의 scheme에 의해 결정됩니다. 예: hdfs://localhost:9000/rmstore는 HDFS를 저장소로 사용하고 file:///tmp/yarn/rmstore는 local FS를 저장소로 사용합니다. URI에 scheme(hdfs:// 또는 file://)이 지정되지 않으면, 사용할 저장소 유형은 core-site.xml에 정의된 fs.defaultFS에 의해 결정됩니다.

RM 상태가 Hadoop FileSystem 상태 저장소에 저장될 URI 구성.

| Property | Description | | yarn.resourcemanager.fs.state-store.uri | RM 상태가 저장될 FileSystem 경로의 위치를 가리키는 URI(예: hdfs://localhost:9000/rmstore). 기본값은 ${hadoop.tmp.dir}/yarn/system/rmstore입니다. FileSystem 이름이 제공되지 않으면 *conf/core-site.xml에 지정된 fs.default.name이 사용됩니다. |

상태 저장소 클라이언트가 Hadoop FileSystem에 연결하는 데 사용하는 재시도 정책 구성.

| Property | Description | | yarn.resourcemanager.fs.state-store.retry-policy-spec | Hadoop FileSystem 클라이언트 재시도 정책 스펙. Hadoop FileSystem 클라이언트 재시도는 항상 활성화됩니다. sleep-time과 number-of-retries의 쌍, 즉 (t0, n0), (t1, n1), ... 으로 지정되며, 처음 n0번의 재시도는 평균 t0 밀리초를 sleep하고, 다음 n1번의 재시도는 평균 t1 밀리초를 sleep하는 식입니다. 기본값은 (2000, 500)입니다. |

ZooKeeper 기반 상태 저장소 구현 구성

RM 상태가 저장되는 ZooKeeper 서버 주소와 루트 경로 구성.

| Property | Description | | yarn.resourcemanager.zk-address | 콤마로 구분된 Host:Port 쌍 목록. 각각은 RM이 RM 상태를 저장하는 데 사용하는 ZooKeeper 서버에 해당합니다(예: "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002"). | yarn.resourcemanager.zk-state-store.parent-path | RM 상태가 저장될 루트 znode의 전체 경로. 기본값은 /rmstore입니다. |

상태 저장소 클라이언트가 ZooKeeper 서버에 연결하는 데 사용하는 재시도 정책 구성.

| Property | Description | | hadoop.zk.num-retries | 연결이 끊어졌을 때 RM이 ZooKeeper 서버에 연결을 시도하는 횟수. 기본값은 500입니다. | hadoop.zk.retry-interval-ms | ZooKeeper 서버에 연결할 때 재시도 사이의 간격(밀리초). 기본값은 2초입니다. | hadoop.zk.timeout-ms | ZooKeeper 세션 타임아웃(밀리초). 이 구성은 ZooKeeper 서버가 세션이 언제 만료되는지 결정하는 데 사용됩니다. 서버가 이 구성이 지정하는 세션 타임아웃 기간 내에 클라이언트로부터 소식을 듣지 못하면(즉 heartbeat 없음) 세션 만료가 발생합니다. 기본값은 10초입니다. |

ZooKeeper znodes에 권한을 설정하는 데 사용할 ACL 구성.

LevelDB 기반 상태 저장소 구현 구성

| Property | Description | | yarn.resourcemanager.leveldb-state-store.path | RM 상태가 저장될 로컬 경로. 기본값은 ${hadoop.tmp.dir}/yarn/system/rmstore입니다. |

작업-보존 RM 복구 구성

| Property | Description | | yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms | RM 작업-보존 복구 시 새 컨테이너를 할당하기 전에 RM이 기다리는 시간을 설정합니다. 이 대기 기간은 복구 시 새 컨테이너를 애플리케이션에 할당하기 전에 RM이 클러스터의 NM과 재동기화를 안정화할 기회를 줍니다. |

참고 (Notes)

RM이 작업-보존 복구를 활성화한 상태로 재시작하면 ContainerId 문자열 형식이 변경됩니다. 예전 형식은 Container_{clusterTimestamp}_{appId}_{attemptId}_{containerId}였습니다. 예: Container_1410901177871_0001_01_000005.

이제 Container_e{epoch}_{clusterTimestamp}_{appId}_{attemptId}_{containerId}로 변경됩니다. 예: Container_e17_1410901177871_0001_01_000005.

여기서 추가된 epoch 숫자는 0에서 시작해 RM이 재시작될 때마다 1씩 증가하는 단조 증가 정수입니다. epoch 숫자가 0이면 생략되고 containerId 문자열 형식은 이전과 동일하게 유지됩니다.

샘플 구성 (Sample Configurations)

아래는 ZooKeeper 기반 상태 저장소를 사용해 RM 작업-보존 재시작을 활성화하기 위한 최소 구성 집합입니다.

 <property>
   <description>Enable RM to recover state after starting. If true, then
   yarn.resourcemanager.store.class must be specified</description>
   <name>yarn.resourcemanager.recovery.enabled</name>
   <value>true</value>
 </property>

 <property>
   <description>The class to use as the persistent store.</description>
   <name>yarn.resourcemanager.store.class</name>
   <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
 </property>

 <property>
   <description>Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server
   (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state.
   This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
   as the value for yarn.resourcemanager.store.class</description>
   <name>yarn.resourcemanager.zk-address</name>
   <value>127.0.0.1:2181</value>
 </property>

더 알아보기 (Learn more)

원문: 문서