Size containers to fit a 2Gi pod and split the queues

목표

ResourceManager 의 REST API 로 이 클러스터가 내줄 수 있는 자원을 확인하고, 그보다 큰 컨테이너를 달라는 잡이 어떻게 끝나는지 본다. Capacity Scheduler 에 etl·adhoc 대기열을 만들어 잡을 보내고, 없는 대기열이 거절되는 것과 끝난 잡의 로그를 모아 읽는 법까지 다룬다.

왜 중요한가

YARN 은 클러스터의 메모리와 코어를 컨테이너 단위로 나눠 주는 자원 관리자다. NodeManager 는 자기가 내줄 수 있는 몫(yarn.nodemanager.resource.memory-mb)을 알리고, ResourceManager 의 스케줄러는 요청을 최소 할당 단위로 올려 잡고 최대 할당보다 크면 거절한다. 맵리듀스든 Spark 든 YARN 위에서 도는 것은 모두 이 규칙을 따른다. 운영에서 "잡이 ACCEPTED 에서 안 움직여요" 와 "잡이 바로 죽어요" 는 대개 이 숫자들의 문제다. 컨테이너 크기가 노드 몫보다 크면 영원히 자리가 나지 않고, 최대 할당보다 크면 곧바로 거절된다. 이 파드는 메모리가 2Gi 라 노드 몫을 1024MB 로 잡아 두었다 — 숫자가 작아서 규칙이 더 잘 보인다. 대기열은 한 클러스터를 여러 팀이 나눠 쓰는 방법이다. Capacity Scheduler 는 대기열마다 보장 몫(capacity)과 빌려 쓸 수 있는 상한(maximum-capacity)을 둔다. 같은 부모 아래 보장 몫의 합은 100 이어야 하고, 설정 파일을 고친 뒤 refreshQueues 로 다시 읽힌다. 끝난 컨테이너의 로그는 NodeManager 가 HDFS 로 모아 두므로(로그 모으기), 파드가 사라진 뒤에도 yarn logs 로 읽을 수 있다.

단계

1. lab-hadoop start yarn 으로 YARN 을 켜고 curl -s http://localhost:8088/ws/v1/cluster/metrics 응답을 /root/hdp/yarn/metrics.json 에 저장하세요.
2. 예제 jar 의 pi 를 -D mapreduce.map.memory.mb=2048 로 돌려 잡이 끝나게 한 뒤, 그 애플리케이션의 yarn application -status <애플리케이션 ID> 출력을 /root/hdp/yarn/toobig.txt 에 저장하세요.
3. /opt/hadoop/etc/hadoop/capacity-scheduler.xml 을 고쳐 root 아래 대기열을 default,etl,adhoc 로, 보장 몫을 20·50·30 으로, adhoc 의 상한을 50 으로 두고 yarn rmadmin -refreshQueues 한 뒤, yarn queue -status etl 출력을 /root/hdp/yarn/etl.txt 에 저장하세요.
4. /data/books/book-1.txt 를 HDFS /user/root/yarn/in/ 에 올리고 wordcount 를 -D mapreduce.job.queuename=etl 로 /user/root/yarn/wc-etl 에 돌리세요.
5. 같은 wordcount 를 없는 대기열 nope 로 제출해 보고(출력 /user/root/yarn/wc-nope) 오류 출력을 /root/hdp/yarn/badqueue.txt 에 저장하세요.
6. curl -s http://localhost:8088/ws/v1/cluster/scheduler 응답을 /root/hdp/yarn/scheduler.json 에 저장하세요.
7. 4단계 잡의 애플리케이션 로그를 yarn logs -applicationId <애플리케이션 ID> 로 모아 /root/hdp/yarn/etl-logs.txt 에 저장하세요.
8. /root/hdp/yarn/report.md 에 ## 컨테이너 크기 ## 대기열 ## 로그 세 절을 쓰세요. 첫 절에 1단계의 totalMB 와 2단계에서 요청한 2048 을 넣으세요.

참고

• 이 파드의 YARN: NodeManager 몫 1024MB·코어 2, 최소 할당 128MB, 최대 할당 1024MB, AM 384MB, 맵·리듀스 256MB(yarn-site.xml·mapred-site.xml).
• 잡 ID job_<A>_<B> 와 애플리케이션 ID application_<A>_<B> 는 같은 숫자를 씁니다. 끝난 잡의 이력은 /tmp/hadoop-yarn/staging/history/done_intermediate/root/ 에 남습니다.
• 이력 서버를 띄우지 않았기 때문에, 실패한 잡은 클라이언트가 최종 상태를 가져오다 연결 오류(10020)로 끝날 수 있습니다. 잡의 진짜 결과는 yarn application -status 나 이력 파일에서 보세요.
• 흔한 실수: 보장 몫의 합을 100 으로 맞추지 않아 refreshQueues 가 거절되는 것, 대기열 이름에 root. 을 붙여 제출하는 것(이름만 씁니다), 애플리케이션이 끝나기 전에 yarn logs 를 부르는 것.
• 공식 문서: Apache Hadoop YARN · Capacity Scheduler · ResourceManager REST APIs · yarn-default.xml

클러스터가 내줄 수 있는 것

lab-hadoop start yarn 으로 YARN 을 켜고, curl -s http://localhost:8088/ws/v1/cluster/metrics 응답 JSON 을 /root/hdp/yarn/metrics.json 에 저장하세요.

clusterMetrics 의 totalMB·totalVirtualCores·activeNodes 가 NodeManager 가 알린 몫입니다. 파드는 2Gi 인데 totalMB 가 그보다 훨씬 작은 이유를 생각해 보세요 — HDFS·YARN 데몬 넷과 클라이언트 JVM 이 먼저 자리를 차지합니다.

최대 할당보다 큰 컨테이너

yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar pi -D mapreduce.map.memory.mb=2048 1 10 을 돌려 잡이 끝나게 한 뒤, 그 애플리케이션의 yarn application -status application_<…> 출력을 /root/hdp/yarn/toobig.txt 에 저장하세요.

맵 하나가 2048MB 를 달라는데 최대 할당은 1024MB 입니다. AM 은 맵 컨테이너를 요청하기도 전에 잡을 KILLED 로 끝냅니다. 애플리케이션 ID 는 잡 ID 의 숫자 그대로이고, 이력 폴더에서 이름이 QuasiMonteCarlo 인 KILLED 잡을 찾으면 됩니다. 진단(Diagnostics) 줄이 이유를 말해 줍니다.

대기열 셋 만들기

/opt/hadoop/etc/hadoop/capacity-scheduler.xml 에서 yarn.scheduler.capacity.root.queues 를 default,etl,adhoc 로, root.default.capacity·root.etl.capacity·root.adhoc.capacity 를 20·50·30 으로, root.adhoc.maximum-capacity 를 50 으로 두세요. yarn rmadmin -refreshQueues 로 다시 읽힌 뒤 yarn queue -status etl 출력을 /root/hdp/yarn/etl.txt 에 저장하세요.

같은 부모 아래 보장 몫(capacity)의 합은 100 이어야 refreshQueues 가 받아들입니다. 상한(maximum-capacity)은 남는 자원을 빌려 쓸 수 있는 한계입니다. 설정 파일을 고치는 것만으로는 아무 일도 일어나지 않습니다 — 다시 읽혀야 합니다.

etl 대기열로 잡 보내기

/data/books/book-1.txt 를 HDFS /user/root/yarn/in/ 에 올리고, yarn jar <예제 jar> wordcount -D mapreduce.job.queuename=etl /user/root/yarn/in /user/root/yarn/wc-etl 로 돌리세요.

대기열은 이름만 씁니다(root. 없이). 잡 이력 파일 이름의 대기열 칸에 root.etl 이 찍히는지 보세요. 채점기는 그 칸과 출력의 _SUCCESS 를 봅니다.

없는 대기열은 제출에서 거절된다

같은 wordcount 를 -D mapreduce.job.queuename=nope 로 /user/root/yarn/wc-nope 에 제출해 보고, 오류 출력(표준 오류 포함)을 /root/hdp/yarn/badqueue.txt 에 저장하세요.

없는 대기열은 스케줄러가 애플리케이션을 받는 순간 거절합니다. 잡은 시작도 하지 않으므로 이력에도 남지 않습니다 — 그래서 이 오류는 제출한 쪽의 출력에만 있습니다.

스케줄러가 보는 대기열

curl -s http://localhost:8088/ws/v1/cluster/scheduler 응답 JSON 을 /root/hdp/yarn/scheduler.json 에 저장하세요.

응답의 scheduler.schedulerInfo.queues.queue 에 대기열마다 capacity·maxCapacity·usedCapacity 가 있습니다. 채점기는 그 값이 여러분이 고친 설정 파일과 같은지 봅니다 — refreshQueues 가 정말 먹었는지 확인하는 셈입니다.

끝난 잡의 로그 모아 읽기

4단계 잡의 애플리케이션 ID(application_<…>)로 yarn logs -applicationId <ID> 를 실행해 출력을 /root/hdp/yarn/etl-logs.txt 에 저장하세요.

NodeManager 는 컨테이너가 끝나면 그 로그를 HDFS 의 /tmp/logs/<사용자>/ 아래로 모읍니다(로그 모으기). 그래서 노드가 사라져도 로그가 남습니다. 모으기는 앱이 끝난 뒤 몇 초 걸리니, 곧바로 부르면 빈 출력이 나올 수 있습니다. 출력에 컨테이너마다 Container: 머리와 LogType:syslog·stdout·stderr 가 차례로 나옵니다.

자원의 숫자를 남기기

/root/hdp/yarn/report.md 에 ## 컨테이너 크기 ## 대기열 ## 로그 세 절을 쓰세요. 첫 절에 1단계의 totalMB 와 2단계에서 요청한 2048 을 숫자로 넣으세요.

노드 몫·최소 할당·최대 할당·AM 크기가 어떻게 맞물리는지, 대기열의 보장 몫과 상한이 무엇을 뜻하는지, 로그가 어디에 모였는지를 적으세요.