Loading
2014. 10. 18. 17:48 - Phil lee

YARN




Overall Flow of YARN

-> YARN Client via API submit job into Resource Manager ( 정확히는 잡을 실행할 Application Master Code를 Resource Manager에게 넘김)

-> Resource M은 Node M을 랜덤하게 골라 그 노드위에서 Application M in Container 을 실행시킴.

-> Application M은 Resource M에게  필요한 Container들의 할당을 요청(즉 모든 Resource요청은 Resource M에게)

나중에 Application M은 이 Container들을 Resource M에게 돌려줘야함

-> Resource M은 Application M을 대신하여 Node Manager들에게  Task 실행 명령함.

각 테스크는 각기 하나의 컨테이너안에서 실행.


YARN


Resource Manager/ Port 8088 <RM은 Scheduler 와 ApplicationsManager ( 주의! ApplicationMaster(AM)가 아님 -_- ) 두 가지 구성요소로 이루어져 있다.>

- 클러스터마다 존재한다. 클러스터의 전반전인 자원관리와 job들의 스케쥴링 담당한다.

여기서 스케쥴링은 자원요청에 맞춰 잡을 실행해도 되는지 허가를 해주는 것뿐이지 잡의 실행여부를

끝까지 책임지지는 않는다. ( 끝까지 책임지는 것은 Application Master 역할)

- Client로 부터 application 실행 요청을 받으면 그 application의 실행을 책임질 application Master 실행

- 각 클러스터내의 서버마다 설정된 Node Manager를 통해 할당된 자원, 자원의 상황알 수 있다.

- Application Master를 통해 필요한 자원이 무엇인지 어떤 자원들이 더 이상 필요 없는지 알아내서 관리

============================================================================

Scheduler 는 다양한 application들에게 (부족한) 리소스들을 배정한다. Scheduler 는 application의 status를 tracking하거나 monitor하지 않고 순수하게 scheduling만 한다. application 오류나 hardware 오류로 실패한 task를 재시작해주지도 않는다. 오직 application이 요구하는 리소스에 관련된 기능만 처리한다. 메모리나 cpu, disk, 네트워크 등을 포함하는 리소스 Container 를 관리한다.

Scheduler 는 클러스터 리소스들을 여러 application들에게 적절히 분배하는 역할을 하는 플러그인이라고 볼 수 있다. 예를 들어  Map-Reduce  application에서는 CapacityScheduler 와 FairScheduler 같은 scheduler들을 사용한다.

 

CapacityScheduler 는 예측 가능한 클러스터 자원의 배분을 위해 hierarchical queues 를 지원한다.

 

ApplicationsManager 는 job을 제출받아서(job-submission), application을 실행시키기 위해 container를 요청하고, 만약 container가 실패하면 재시작시켜준다.

 

NodeManager는 각 machine마다 하나씩 존재한다. container들의 리소스 사용량을 모니터링하고 이를 RM과 scheduler에게 알려 준다.

 

AM은 각 application마다 존재하며, 적절한 리소스 container를 Scheduler에게 받아내고 그들의 상태와 진행 상황을 모니터링한다. 예를들어, Map-Reduce application에서의 AM은 jobtracker이다.

 

MRv2는 이전 stable 릴리즈인 hadoop-0.20.205 과 API 호환성을 유지한다. 따라서 모든 Map-Reduce job은 recompile만하면 MRv2에서도 동작한다.

===============================================================================


Node Manager (TaskTracker)

- 클러스터내의 서버마다 하나씩 실행됨. 노드 내의 자원을 관리하고 이를 Resource Manager에게 전송

- 하나 이상의 Container 관리 -> Container들의 CPU & Memory 모니터링! 트랙킹!

-Container like task in each JVM


Containers

- 각 태스크는 하나의 Container안에서 실행된다. 현재로는 하나의 JVM에 해당되고 요청된 메모리 크기에

의해 (Java Heap)에 의해 Containers 수가 결정된다.

-그럼 누가 어떤 잡을 실행하는데 필요한 자원(Container)을 요청하고 누가 이 요청의 허락여부 결정?

: Application Master->필요한 자원 요청, Resource Manager-> 허락 여부 결정

- 자바를 제외하고 다양한 프로그램들을 돌릴 수 있게 application master는 Container들에게 프로그램들의

실행을 위한 Command Line, Env parameters, backup  data file, jar, token들을 넘겨줘야한다.



Application Master <AM은 RM에게 리소스를 요청하고 NM과 함께 task들을 실행하고 monitor 한다. >

- YARN위에서 실행시키는 Job마다 하나씩 존재.

- 결국 해당 Job에 필요한 리소스를 Resource Manager로부터 받아서 Node Manager로 Task 분담해서

실행(task들 in container에서)하는 역할



MRv2에서는 기존의 JobTracker를 기능 별로 두 가지 daemon으로 나눈다. resource management 와 job scheduling & monitoring 이 그 두 가지 기능이다.

 클러스터 전체를 관리하는 ResourceManager(RM)가 하나 존재하고, 각 노드마다 NodeManager(NM)이 존재하며, 각 application마다 ApplicationMaster(AM)가 존재한다.

=================================================================================================

HAR

Feature of user filesystem
you can store and look at list in HAR

HAR VS HDFS
-> Compress Archive
-> Store as directory on HDFS

because of weakness of HDFS -> Name node should store large meta data in memory.
That's hwy  fild archiving facility that packs files into HDFS block effieicity.

HDFS의 네임노드는 모든 파일 리스트를 저장해야하므로
metadata는 mainmeory 에서 그 많은 양들을 저장할 수 없다.

HAR 등장, 효과적으로 저장가능. as a zip file !
하지만 zip file은 안에 리스트를 볼 수 없지만 HAR는 one directory로 한 파일로 저장되지만
안에 내용물을 볼 수 있다! in a single file ! by packing multiple files ! avoid memory problem.

without decompressing we can look at inside the file !

Limitations
1) it doesn't support compress, just packing
2) immutable; not adding, removing

regardless of usual file system,
you can specify HAR file instead of HDFS !