'Development/Hadoop'에 해당되는 글 17건

Scheduler

• 계층형 큐
• 부모 큐: 조직과 하위 조직의 자원을 관리
• 리프 큐: 부모 아래에서 동작하는 큐로 더 이상 자식 큐가 없는 마지막 큐
• 부모 큐는 직접 애플리케이션을 제출할 수 없으며, 오직 리프 큐만 애플리케이션을 제출함
• ROOT는 어떤 조직에도 속하지 않으며, 클러스터 자체를 의미함

Capacity Scheduler

• 스케줄러 특징
• 특별한 설정을 하지 않을 경우 기본으로 Capacity Scheduler를 사용함
• 각 리프 큐의 내부 스케줄링은 FIFO 방식으로 자원을 할당함
• 다른 조직에서 애플리케이션을 제출한 후 제어권을 돌려주는 식으로 자원 공유 가능
• 잘 사용하지 않는(가장 작은 비율의) 큐에 더 높은 우선순위를 줌
• 탄력성을 보장하기 위해 설정은 되어 있지만 수요가 부족해 사용률이 저조한 커패시티는 자원을 필요로 하는 큐에 자동으로 할당됨
• 큐 특징
• 큐는 런타임에 삭제될 수 없으며, 전체 계층에 걸쳐 동일한 이름은 허용되지 않음
• 새로 추가하는 큐는 해당 레벨의 큐 커패시티에서 100%를 초과할 수 없음
• 부모 큐의 사용 커패시티는 모든 하위 큐가 사용한 커패시티의 합으로 정의됨
• 기존 리프 큐는 새로운 큐 추가에 의해 부모 큐가 될 수 없음 (한번 자식은 영원한 자식)
• 특정 부모 큐의 모든 하위 큐에 대해 문자열 형식의 ACL을 설정할 수 있음
• User1,User2,User3(space)Group1,Group2

(Example 1)

• yarn.scheduler.capacity.root.A.capacity -> 20% (20GB, total 100GB)
• yarn.scheduler.capacity.root.B.capacity -> 80% (80GB)
• A: 20GB -> 1a(20GB), 1b(20GB), 2c(20GB), 3d(20GB), 3e(20GB)
• B: 80GB -> 4f(60GB, Pending))
• <IF> yarn.scheduler.capacity.root.A.maximum-capacity -> 40% (40GB)
• A: 20GB -> 1a(20GB), 1b(20GB), 2c(20GB, Pending), 3d(20GB, Pending), 3e(20GB, Pending)
• B: 80GB -> 4f(60GB)

(Example 2)

• yarn.scheduler.capacity.root.A.minimum-user-limit-percent -> 20%
• Sequence 1 -> a(100%)
• Sequence 2 -> a(50%), b(50%)
• Sequence 3 -> a(33.3%), b(33.3%), c(33.3%)
• Sequence 4 -> a(20%), b(20%), c(20%), d(20%), e(20%)
• Sequence 5 -> a(20%), b(20%), c(20%), d(20%), e(20%), f(Pending)

(Example 3)

• yarn.scheduler.capacity.root.A.user-limit-factor -> 1
• a(100%)
• yarn.scheduler.capacity.root.A.user-limit-factor -> 2
• a(200% with B)
• yarn.scheduler.capacity.root.A.user-limit-factor -> 0.5
• a(50%)

• 이 외에도…
• yarn.scheduler.capacity.maximum-applications -> 기본값 10000
• yarn.scheduler.capacity.<queue-path>.maximum-applications
• absolute-capacity * maximumapplications
• 시스템 스레싱을 피하기 위해 동시에 실행되는 애플리케이션 총 개수를 제한함
• yarn.scheduler.capacity.maximum-am-resource-percent -> 기본값 0.1
• yarn.scheduler.capacity.<queue-path>.maximum-am-resourcepercent
• AM이 사용할 수 있는 클러스터 자원의 최대 비율
• 대부분의 유휴 자원을 점유하는 AM이 할당된 후 맵리듀스 컨테이너를 할당하기 위해 다른 애플리케이션이 반납할 때까지 기다리는 데드락을 방지함
• 예) AM이 단일 노드 100GB 중 30GB를 할당받은 후 80GB 컨테이너를 요청하면?...

시스템 스레싱: 프로세스들이 제한된 메모리보다 큰 메모리를 사용하여, 페이지 교체가 일어나며 프로세스의 대기 시간이 길어지는 것

Fair Scheduler

• 큐 내의 모든 잡이 공평하게 리소스를 점유하는 방식
• YARN 스케줄러 중 가장 인기 있게 사용됨

• Fair 스케줄러 종류
• FairSharePolicy (default)
• Weight 값에 따라 공평하게 -> 메모리만 고려함(CPU는 동일 비율)
• FIFOPolicy
• 먼저 들어온 애플리케이션부터
• DominantResourceFairnessPolicy
• CPU와 메모리 사용량에 따라 CPU를 많이 쓰는 애플리케이션은 vCores를 많이 할당해주고, 메모리를 많이 쓰는 애플리케이션은 메모리를 많이 할당해주는 방식
• FairSharePolicy vs FIFOPolicy
• A(60GB) 큐에서 a1(60GB), b2(40GB), c3(20GB) 순으로 애플리케이션이 요청될 때
• FIFOPolicy
• a1이 다 끝나야 b2, c3가 시작될 수 있음
• FairSharePolicy
• 3개의 애플리케이션이 유휴 자원의 1/3씩 할당 받아 동시에 실행될 수 있음
• 다수의 Job 실행에 따른 잦은 Pending을 해소할 수 있음