[하둡, 하이브로 시작하기] 2. 하둡(hadoop) (~2.4 YARN)

2.4 YARN

YARN: 클러스터 리소스 관리 / 애플리케이션 라이프 사이클 관리 아키텍처 

= 자원 관리(리소스 매니저  & 노드매니저) + 애플리케이션 라이프 사이클 관리 기능(애플리케이션 마스터 & 컨테이너)

 

- 자원 관리

    - 노드매니저: 클러스터의 각 노드마다 실행 ➡️ 현재 노드의 사원 상태 관리 ➡️ 리소스매니저에 보고

    - 리소스 매니저: 노트매니저의 정보 ➡️ 클러스터 전체 자원 관리 (자원 사용 상태 모니터링, 애플리케이션 마스터 자원 요청 ➡️ 빈 자원 사용)

 

- 라이프사이클 관리

1. 클라이언트: 애플리케이션 ➡️ 리소스 매니저

2. 리소스 매니저: 비어있는 노드에서 애플리케이션 마스터 실행

3. 애플리케이션 마스터: 작업 실행 자원 요청 ➡️ 리소스 매니저

4. 자원 할당

5. 각 노드에 컨테이너(실제 작업 실행 단위) 실행, 실제 작업 진행 

6. 컨테이너 작업 종료

7. 컨테이너: 작업 결과 ➡️ 애플리케이션 마스터 

8. 모든 작업 종료

9. 애플리케이션 마스터: 모든 작업 결과 ➡️ 리소스매니저, 자원 해체 

 

2.4.1 YARN-Scheduler

스케줄러: 자원 할당을 위한 정책 

- FIFO 스케줄러

- Fair 스케줄러: 자원을 조절하여 작업에 균등하게 자원 할당

- Capacity 스케줄러: 트리 형태로 큐 선언 ➡️ 간 큐 별로 이용할 수 있는 자원의 용량 정함 

 

2.4.1.1 커패시티 스케줄러

트리 형태로 계층화된 큐 선언 ➡️ 큐별로 사용 가능한 용량 할당 ➡️ 자원 관리

 

yarn.scheduler.capacity.maximum-applications	PRE, RUNNIG 상태로 설정 될 수 있는 최대 애플리케이션의 개수
yarn.scheduler.capacity.maximum-am-resource-percent	애플리케이션 마스터(AM)에 할당 가능한 최대 비율. AM은 실제 작업이 돌지 않고 작업을 관리하는 역활을 하기 때문에 작업에 많은 컨테이너를 할당하기 위해 이 값을 적당히 조절해야 함
yarn.scheduler.capacity.root.queues	root 큐에 등록하는 큐의 이름. root큐는 하위에 동록할 큐를 위해 논리적으로만 존재
yarn.scheduler.capacity.root.[큐이름].maximum-am-resource-percent	큐에서 AM이 사용할 수 있는 자원의 비율
yarn.scheduler.capacity.root.[큐이름].capacity	큐의 용량 비율
yarn.scheduler.capacity.root.[큐이름].user-limit-factor	큐에 설정된 용량 * limit-factor 만큼 다른 큐의 용량을 사용할 수 있음. 클러스터의 자원을 효율적으로 사용할 수 있음. maxmimum-capacity 이상으로는 이용할 수 없음.
yarn.scheduler.capacity.root.[큐이름].maximum-capacity	큐가 최대로 사용할 수 있는 용량

 

사용자 & 큐 자동 매핑

• u:유저명:큐
  • 유저 & 큐를 매핑
• g:그룹명:큐
  • 그룹 & 큐를 매핑
• u:%user:%user
  • 유저 ➡️ 유저명 큐에 매핑
• u:%user:%primary_group
  • 유저 ➡️ 유저의 프라이머리 그룹명 큐에 매핑

 

2.4.1.2 페어 스케줄러

 제출된 작업이 동등하게 리소스를 점유 할 수 있도록 지원

 

1. 작업 큐에 작업 제출

2. 클러스터: 자원을 조절 ➡️ 모든 작업에 균등하게 자원 할당

 

페어 스케줄러는 트리 형태로 계층화된 큐를 선언하고, 큐별로 사용가능한 용량을 할당하여 자원을 관리

 

 

yarn.scheduler.fair.allocation.file	fair-scheduler.xml	설정파일의 이름
yarn.scheduler.fair.user-as-default-queue	true	큐이름을 지정하지 않았을 때 기본큐의 사용 여부
yarn.scheduler.fair.preemption	false	우선순위 선점의 사용 여부

 

2.4.2 YARN 메모리 설정 

리소스 매니저 설정

• yarn.nodemanager.resource.memory-mb
  • 클러스터의 각 노드에서 컨테이너 운영에 설정할 수 있는 메모리의 총량
  • 노드의 OS를 운영할 메모리를 제외하고 설정
  • 기본값은 장비에 설정된 메모리의 80% 정도를 설정
    • 노드의 메모리가 32G인경우 운영체제를 위한 4G를 제외하고 28G를 설정
• yarn.nodemanager.resource.cpu-vcores
  • 클러스터의 각 노드에서 컨테이너 운영에 설정할 수 있는 CPU의 개수
  • 기본값은 장비에 설치된 CPU의 80% 정도를 설정
    • 노드에 설치된 CPU가 40개일 경우 32를 설정
• yarn.scheduler.maximum-allocation-mb
  • 하나의 컨테이너에 할당할 수 있는 메모리의 최대값
  • 8G가 기본 값
• yarn.scheduler.minimum-allocation-mb
  • 하나의 컨테이너에 할당할 수 있는 메모리의 최소값
  • 1G가 기본값
• yarn.nodemanager.vmem-pmem-ratio
  • 실제 메모리 대비 가상 메모리 사용 비율
  • mapreduce.map.memory.mb * 설정값의 비율로 사용 가능
  • 메모리를 1G로 설정하고, 이 값을 10으로 설정하면 가상메모리를 10G 사용
• yarn.nodemanager.vmem-check-enabled
  • 가상 메모리에 대한 제한이 있는지 확인하여, true 일 경우 메모리 사용량을 넘어서면 컨테이너를 종료
  • false 로 설정하여 가상메모리는
• yarn.nodemanager.pmem-check-enabled
  • 물리 메모리에 대한 제한이 있는지 확인하여, true 일 경우 메모리 사용량을 넘어서면 컨테이너를 종료

2.4.3 YARN 명령어

사용자 커맨드 목록

 

application	애플리케이션 정보 확인, 작업 종료
applicationattempt	애플리케이션 Attempt 정보
classpath	필요한 클래스 정보
container	컨테이너 정보
jar	jar 파일 실행
logs	애플리케이션 로그 확인
node	노드 정보
queue	큐 정보
version	버전 정보
envvars	환경 변수 정보

 

운영자 커맨드 목록

daemonlog	로그 레벨 설정
nodemanager	노드매니저 실행
proxyserver	프록시 서버 실행
resourcemanager	리소스매니저 실행
rmadmin	리소스매니저 어드민 클라이언트 명령
schedulerconf	스케쥴러 설정 업데이트
scmadmin	공유 캐쉬 매니저 어드민 클라이언트 명령
sharedcachemanager	공유 캐쉬 매니저 실행
timelineserver	타임라인 서버 실행

 

2.4.4 YARN REST API

리소스 매니저는 REST API를 제공. 이를 통해 클러스터의 상태정보, 운영정보를 확인할 수 있습니다. 응답형태는 JSON, XML 형태로 제공됩니다. 리소스 매니저 매뉴얼에서 전체 목록을 확인할 수 있습니다.

클러스터 메트릭 정보 확인

클러스터 메트릭 정보를 확인하는 URI는 다음과 같습니다. 해당 URI를 GET 방식으로 호출하면 됩니다. 헤더에 { 'Content-Type': 'application/json' }로 정보를 설정하면 json 형식으로 값을 반환

http://<rm http address:port>/ws/v1/cluster/metrics

 

2.4.5 YARN Node Labels

특징

• 하나의 노드는 하나의 파티션을 가질 수 있음(One node can have only one node partition)
  • 기본값은 DEFAULT 파티션(partition="")
  • 클러스터는 여러 파티션(여러 노드)으로 구성할 수 있음
  • 스케줄러에서 사용자가 각 파티션이 사용할 수 있는 리소스의 양을 설정해야 함
  • 노드 레이블로 지정되지 않은 큐는 기본 파티션을 이용하게 됨
• 접근제어(ACL)
  • 큐에서 설정된 노드만 작업에 이용할 수 있고, 이를 통해 각 노드에 대한 접근제어가 가능함
• 클러스터 사용량 제어
  • 각 노드마다 사용할 수 있는 자원의 비율을 지정하여 사용량을 제어할 수 있음

파티션의 종류

• Exclusive 파티션
  • 클러스터의 자원에 여유가 있어도 지정한 파티션만 이용하여 작업을 처리
• Non-Exclusive 파티션
  • 클러스터에 여유가 있다면 DEFAULT 파티션으로 요청한 작업에 대해서 처리 가능

설정

노드 레이블 설정

리소스 매니저에서 노드 레이블을 지원하도록 하기 위해서 yarn-site.xml에 다음과 같이 설정합니다.

Copy  <property>
    <name>yarn.node-labels.enabled</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.node-labels.fs-store.root-dir</name>
    <value>hdfs://namenode:port/path/to/store/node-labels/</value>
  </property>

 

스케줄러 설정

 

yarn.scheduler.capacity.<queue-path>.capacity	DEFAULT 파티션에 속하는 노드에 액세스 할 수있는 큐의 백분율 설정. 각 부모의 직계 자녀에 대한 기본 용량의 합은 100
yarn.scheduler.capacity.<queue-path>.accessible-node-labels	"hbase, storm"과 같이 관리자가 각 큐에서 레이블에 액세스 할 수 있고 쉼표로 구분하여 레이블을 지정. 큐가 레이블 hbase 및 storm에 액세스 할 수 있음을 의미함. 모든 큐는 레이블이없는 노드에 액세스 할 수 있으므로 사용자는 이를 지정하지 않아도 됨. 사용자가 이 필드를 지정하지 않으면 상위 필드에서 상속.
yarn.scheduler.capacity.<queue-path>.accessible-node-labels.<label>.capacity	<label> partition에 속하는 노드에 액세스 할 수있는 큐의 백분율을 설정. 각 부모 아래의 직계 자녀에 대한 <label> 용량의 합계는 100. 기본적으로 0.
yarn.scheduler.capacity.<queue-path>.accessible-node-labels.<label>.maximum-capacity	yarn.scheduler.capacity.<queue-path>.maximum-capacity와 유사하게 각 대기열의 레이블에 대한 최대 용량. 기본적으로 100.
yarn.scheduler.capacity.<queue-path>.default-node-label-expression	"hbase"와 같은 값. 즉, 응용 프로그램이 자원 요청에 노드 레이블을 지정하지 않고 큐에 제출 한 경우 "hbase"를 default-node-label-expression으로 사용.

 

YARN 고가용성

리소스 매니저 HA

리소스 매니저 고가용성은 주키퍼와 액티브, 스탠바이 리소스 매니저를 이용하여 제공합니다. 각 리소스 매니저는 클러스터와 작업 상태 보관을 위한 메타 데이터를 저장하기 위한 저정소를 공유합니다. 주키퍼를 이용한 ZKRMStateStore와 파일 시스템을 이용한 FileSystemRMStateStore가 있습니다. 기본적으로 ZKRMStateStore를 추천합니다.

장애 극복

리소스 매니저에 장애가 발생하면 사용자가 수동으로 CLI 커맨드를 이용하여 액티브 리소스 매니저로 변경할 수 있습니다. 주키퍼를 이용하면 자동으로 리소스 매니저의 상태가 변경됩니다.

Copy # 리소스 매니저 상태 확인 
 $ yarn rmadmin -getServiceState rm1
 active

 $ yarn rmadmin -getServiceState rm2
 standby

# 상태 변경 
 $ yarn rmadmin -transitionToStandby rm1

 

2.4.7. 타임라인 서비스

특징

YARN 타임 라인 서비스 v.2는 v.1 및 v.1.5에 이은 타임 라인 서버의 다음 주요 버전입니다. V.2는 v.1의 두 가지 주요 과제를 해결하기 위해 만들어졌습니다.

확장성

V.1은 writer / reader 및 스토리지의 단일 인스턴스로 제한되며 소규모 클러스터 이상으로 확장되지 않습니다. V.2는 더 확장 가능한 분산 작성기 아키텍처와 확장 가능한 백엔드 저장소를 사용합니다.

YARN Timeline Service v.2는 데이터 수집 (쓰기)과 데이터 제공 (읽기)을 분리합니다. 기본적으로 각 YARN 애플리케이션에 대해 하나의 수집기인 분산 수집기를 사용합니다. 리더는 REST API를 통해 쿼리를 제공하는 전용 인스턴스입니다.

YARN Timeline Service v.2는 Apache HBase가 읽기 및 쓰기에 대한 응답 시간을 유지하면서 큰 크기로 잘 확장되기 때문에 Apache HBase를 기본 백업 스토리지로 선택합니다.

유용성 향상

많은 경우 사용자는 작업의 진행 흐름(flow) 또는 YARN 응용 프로그램의 논리적 그룹 수준의 정보에 관심이 있습니다. 논리적 애플리케이션을 완료하기 위해 일련의 YARN 애플리케이션을 시작하는 것이 훨씬 더 일반적입니다. 타임 라인 서비스 v.2는 흐름 개념을 명시 적으로 지원합니다. 또한 흐름 수준에서 메트릭 집계를 지원합니다.

또한 구성 및 메트릭과 같은 정보는 가장 중요한 정보로 취급됩니다. 다음 다이어그램은 서로 다른 YARN 항목 모델링 흐름 간의 관계를 보여줍니다.

구조

YARN Timeline Service v.2는 수집기 (writer) 세트를 사용하여 백엔드 스토리지에 데이터를 씁니다. 수집기는 전용 응용 프로그램 마스터와 함께 배포되고 함께 배치됩니다. 리소스 관리자 타임 라인 수집기를 제외하고 해당 애플리케이션에 속하는 모든 데이터는 애플리케이션 수준 타임 라인 수집기로 전송됩니다.

특정 애플리케이션에 대해 애플리케이션 마스터는 함께 배치 된 타임 라인 수집기 (이 릴리스의 NM 보조 서비스)에 애플리케이션 데이터를 쓸 수 있습니다. 또한 애플리케이션의 컨테이너를 실행중인 다른 노드의 노드 관리자도 애플리케이션 마스터를 실행중인 노드의 타임 라인 수집기에 데이터를 씁니다.

 

리소스 관리자는 자체 타임 라인 수집기도 유지합니다. 쓰기 볼륨을 합리적으로 유지하기 위해 YARN 일반 수명주기 이벤트 만 내 보냅니다.

타임 라인 리더는 타임 라인 수집기와는 별도의 데몬이며 REST API를 통해 쿼리를 제공하는 데 전념합니다.