Hadoop: Capacity Scheduler

Hadoop: Capacity Scheduler

다중 테넌트가 할당된 용량(capacity) 제약 아래 큰 클러스터를 안전하게 공유할 수 있게 하는 플러그형 스케줄러인 CapacityScheduler를 설명하는 문서예요. 계층적 큐, 용량 보장, JSON 기반 큐 매핑, 선점(preemption), 예약(Reservation) 시스템, 동적 큐 자동 생성, 활동(activities) 디버깅까지 다룹니다.

출처: 문서

목적 (Purpose)

이 문서는 여러 테넌트가 할당된 용량의 제약 아래 애플리케이션이 적시에 자원을 할당받을 수 있도록 큰 클러스터를 안전하게 공유하게 하는 Hadoop용 플러그형 스케줄러 CapacityScheduler를 설명합니다.

개요 (Overview)

CapacityScheduler는 운영자 친화적인 방식으로 Hadoop 애플리케이션을 공유 다중 테넌트 클러스터로 실행하면서 클러스터의 처리량과 활용도를 극대화하도록 설계되었습니다.

전통적으로 각 조직은 피크 또는 피크에 가까운 조건에서 조직의 SLA를 충족할 충분한 용량을 가진 자체 전용 컴퓨팅 자원 집합을 가집니다. 이는 일반적으로 평균 활용도가 낮고 조직마다 여러 독립 클러스터를 관리하는 오버헤드가 발생합니다. 조직 간 클러스터 공유는 전용 클러스터를 만들지 않고 규모의 경제 이점을 누릴 수 있으므로 대규모 Hadoop 설치를 운영하는 비용 효율적인 방법입니다. 하지만 조직은 SLA에 중요한 자원을 다른 사람이 사용할까 봐 클러스터 공유를 우려합니다.

CapacityScheduler는 각 조직에 용량 보장을 제공하면서 큰 클러스터를 공유하도록 설계되었습니다. 핵심 아이디어는 Hadoop 클러스터의 가용 자원을 컴퓨팅 요구에 따라 공동으로 클러스터에 자금을 대는 여러 조직이 공유하는 것입니다. 조직은 다른 조직이 사용하지 않는 초과 용량에 접근할 수 있다는 추가 이점이 있습니다. 이는 비용 효율적인 방식으로 조직에 탄력성(elasticity)을 제공합니다.

조직 간 클러스터 공유는 각 조직의 용량이 보장되고 공유 클러스터가 단일 악성 애플리케이션·사용자·그 집합에 취약하지 않도록 하는 안전장치가 필요하므로 강력한 다중 테넌시(multi-tenancy) 지원이 필수적입니다. CapacityScheduler는 단일 애플리케이션·사용자·큐가 클러스터의 자원을 과도하게 소비하지 못하도록 엄격한 제약 집합을 제공합니다. 또한 단일 사용자·큐의 초기화·대기 애플리케이션 수에 제한을 두어 클러스터의 공정성과 안정성을 보장합니다.

CapacityScheduler가 제공하는 기본 추상화는 큐(queue) 개념입니다. 이 큐들은 일반적으로 공유 클러스터의 경제성을 반영하도록 관리자가 설정합니다.

자원 공유에 대한 추가 제어와 예측 가능성을 제공하기 위해 CapacityScheduler는 계층적 큐 를 지원하여, 조직의 하위 큐들이 조직의 애플리케이션 간에 자유 자원 공유에 대한 친화성 을 갖도록, 다른 큐들이 자유 자원을 사용하기 전에 조직의 하위 큐들이 자원을 공유하도록 보장합니다.

CapacityScheduler의 컨테이너 할당은 다음 중 한 방식으로 트리거될 수 있습니다:

  • 노드 하트비트 (Node heartbeat) : NodeManager에서 ResourceManager로의 하트비트 신호가 컨테이너 스케줄링을 트리거합니다. 스케줄러는 해당 노드에 대해 스케줄될 수 있는 애플리케이션을 선택합니다. 이 유형은 무작위적이며, 어떤 노드의 하트비트가 기회를 얻느냐에 달렸습니다. NodeManager 하트비트 간격을 높게 설정하면 컨테이너 스케줄링 성능에 부정적인 영향을 줄 수 있습니다.

  • 비동기 스케줄링 (Asynchronous scheduling) : 백그라운드에서 실행되는 단일 또는 여러 병렬 스레드가 컨테이너 스케줄링을 트리거합니다. 스케줄러는 먼저 스케줄링을 위해 노드 목록에서 무작위 노드를 고르고, 모든 노드가 공정한 기회를 얻도록 노드 목록을 (순환적으로) 반복합니다. 이 접근 방식은 사전 예방적이고 어떤 이벤트도 기다릴 필요가 없으므로 스케줄링 성능을 향상시킵니다.

  • 전역 스케줄링 (Global scheduling) : 비동기 스케줄링과 유사하지만 무작위로 노드를 고르는 대신 자원 크기, 스케줄링 요구사항, 애플리케이션의 자원 분포 같은 요소에 기반해 스케줄링할 노드를 선택합니다. 이 접근 방식은 스케줄러가 최적의 스케줄링 결정을 내릴 수 있게 합니다. 노드 선택 정책은 플러그형이라 애플리케이션의 특정 요구에 맞게 사용자 정의할 수 있습니다.

참고: 비동기 스케줄링은 Capacity Scheduler의 기본 스케줄링 메커니즘입니다.

기능 (Features)

CapacityScheduler는 다음 기능을 지원합니다:

  • 계층적 큐 (Hierarchical Queues) - 다른 큐들이 자유 자원을 사용하기 전에 조직의 하위 큐들이 자원을 공유하도록 보장하는 큐 계층을 지원해 더 많은 제어와 예측 가능성을 제공합니다.

  • 용량 보장 (Capacity Guarantees) - 큐에 특정 용량의 자원이 사용 가능하도록 클러스터 용량의 일부를 큐에 할당합니다. 큐에 제출된 모든 애플리케이션은 큐에 할당된 용량에 접근할 수 있습니다. 관리자는 각 큐에 할당된 용량에 대해 소프트(soft) 한계와 선택적인 하드(hard) 한계를 구성할 수 있습니다.

  • 보안 (Security) - 각 큐에는 어떤 사용자가 개별 큐에 애플리케이션을 제출할 수 있는지 제어하는 엄격한 ACL이 있습니다. 또한 사용자가 다른 사용자의 애플리케이션을 보거나 수정하지 못하게 하는 안전장치가 있습니다. 큐별 및 시스템 관리자 역할도 지원됩니다.

  • 탄력성 (Elasticity) - 자유 자원은 큐 용량을 넘어 어떤 큐에든 할당될 수 있습니다. 미래 시점에 용량 미달로 실행되는 큐에서 이러한 자원에 대한 수요가 있을 때, 이 자원에 스케줄된 작업이 완료되면 용량 미달로 실행되는 큐의 애플리케이션에 할당됩니다(선점도 지원). 이는 큐에 자원이 예측 가능하고 탄력적으로 제공되도록 보장하며, 클러스터의 인위적 자원 격리를 방지해 활용도를 높입니다.

  • 다중 테넌시 (Multi-tenancy) - 단일 애플리케이션, 사용자, 큐가 큐 또는 전체 클러스터의 자원을 독점하지 못하도록 포괄적인 제약 집합을 제공합니다.

  • 운영성 (Operability)

    • 런타임 구성 - 큐 정의와 용량, ACL 같은 속성을 관리자가 런타임에 안전하게 변경해 사용자 혼란을 최소화할 수 있습니다. 또한 사용자·관리자용 콘솔이 제공되어 시스템의 다양한 큐에 대한 현재 자원 할당을 볼 수 있습니다. 관리자는 런타임에 추가 큐 를 추가할 수 있지만, 큐가 STOPPED이고 대기/실행 중인 앱이 없지 않으면 런타임에 삭제 할 수 없습니다.

    • 애플리케이션 배수(Drain) - 관리자는 런타임에 큐를 중지 하여 기존 애플리케이션이 완료될 때까지 실행되는 동안 새 애플리케이션을 제출할 수 없게 합니다. 큐가 STOPPED 상태이면 그 큐 나 그 자식 큐들 에 새 애플리케이션을 제출할 수 없습니다. 기존 애플리케이션은 계속 완료되므로 큐를 우아하게 배수 할 수 있습니다. 관리자는 중지된 큐를 시작 할 수도 있습니다.

  • 자원 기반 스케줄링 (Resource-based Scheduling) - 자원 집약적 애플리케이션 지원으로, 애플리케이션이 기본값보다 높은 자원 요구사항을 선택적으로 지정할 수 있어 서로 다른 자원 요구를 가진 애플리케이션을 수용합니다. 현재 메모리 가 지원되는 자원 요구사항입니다.

  • 기본 또는 사용자 정의 배치 규칙 기반 큐 매핑 인터페이스 (Queue Mapping Interface based on Default or User Defined Placement Rules) - 사용자가 기본 배치 규칙에 따라 작업을 특정 큐에 매핑할 수 있게 합니다. 예를 들어 사용자·그룹, 애플리케이션 이름에 기반합니다. 사용자가 자체 배치 규칙을 정의할 수도 있습니다.

  • 우선순위 스케줄링 (Priority Scheduling) - 애플리케이션을 서로 다른 우선순위로 제출·스케줄할 수 있게 합니다. 정수 값이 높을수록 애플리케이션 우선순위가 높음을 나타냅니다. 현재 애플리케이션 우선순위는 FIFO 정렬 정책에서만 지원됩니다.

  • 백분율 자원 구성 (Percentage Resource Configuration) - 관리자가 큐에 자원의 백분율을 지정할 수 있습니다.

  • 절대 자원 구성 (Absolute Resource Configuration) - 관리자가 백분율 기반 값 대신 큐에 절대 자원을 지정할 수 있습니다. 이는 관리자가 특정 큐에 필요한 자원량을 더 잘 제어하게 해줍니다.

  • 가중치 자원 구성 (Weight Resource Configuration) - 관리자가 백분율 기반 값 대신 큐에 가중치를 지정할 수 있습니다. 이는 동적으로 변화하는 큐 계층에서 큐에 자원을 구성하는 더 나은 제어를 제공합니다.

  • 유니버설 용량 벡터 자원 구성 (Universal Capacity Vector Resource Configuration) - 관리자가 정의된 각 자원 유형에 대해 절대, 가중치, 백분율 모드를 혼합해 큐에 자원을 지정할 수 있습니다. 이는 특정 큐에 필요한 자원량을 구성하는 가장 유연한 방법을 제공합니다.

  • 리프 큐의 동적 자동 생성 및 관리 (Dynamic Auto-Creation and Management of Leaf Queues) - queue-mapping 과 함께 리프 큐 의 자동 생성을 지원합니다. 현재 애플리케이션 배치를 위해 user-group 기반 큐 매핑을 지원합니다. 스케줄러는 부모 큐에 구성된 정책에 기반해 이러한 큐의 용량 관리도 지원합니다.

구성 (Configuration)

ResourceManager가 CapacityScheduler를 사용하도록 설정

ResourceManager가 CapacityScheduler를 사용하도록 구성하려면 conf/yarn-site.xml 에 다음 속성을 설정하세요.

속성 값
yarn.resourcemanager.scheduler.class org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

스케줄링 전략 설정

capacity scheduler에서 다른 스케줄링 전략을 구성하려면 conf/capacity-scheduler.xml 에 다음 속성을 설정하세요.

속성 설명
yarn.scheduler.capacity.schedule-asynchronously.enable 비동기 스케줄링을 활성화할지 지정. 기본값 true.
yarn.scheduler.capacity.multi-node-placement-enabled 전역 스케줄링을 활성화할지 지정. 기본값 false. 추가로 yarn.scheduler.capacity.multi-node-sorting.policy.names로 노드 정렬 정책을 설정해야 합니다.

큐 설정

etc/hadoop/capacity-scheduler.xml이 CapacityScheduler의 구성 파일입니다.

CapacityScheduler에는 root 라는 미리 정의된 큐가 있습니다. 시스템의 모든 큐는 root 큐의 자식입니다.

추가 큐는 yarn.scheduler.capacity.root.queues에 쉼표로 구분된 자식 큐 목록을 구성해 설정할 수 있습니다.

CapacityScheduler 구성은 큐 계층을 구성하기 위해 queue path 라는 개념을 사용합니다. queue path 는 root 에서 시작해 . (점)을 구분자로 하는 큐 계층의 전체 경로입니다.

주어진 큐의 자식은 구성 노브 yarn.scheduler.capacity.<queue-path>.queues로 정의할 수 있습니다. 달리 명시되지 않으면 자식은 부모에서 속성을 직접 상속하지 않습니다.

세 개의 최상위 자식 큐 a, b, c와 a, b에 대한 일부 하위 큐가 있는 예시입니다.

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>a,b,c</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.queues</name>
  <value>a1,a2</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.b.queues</name>
  <value>b1,b2,b3</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

큐 속성 (Queue Properties)

  • 자원 할당
속성 설명
yarn.scheduler.capacity.legacy-queue-mode.enabled legacy-queue 모드를 비활성화하면 다른 용량 모드를 혼합하고 Universal Capacity Vector 형식을 사용해 큐에 유연하게 자원을 할당할 수 있습니다. 기본값은 true 입니다.
yarn.scheduler.capacity.<queue-path>.capacity 큐 용량 을 백분율(%) float(예: 12.5), postfix w 를 가진 float 가중치(예: 2.0w), 또는 절대 자원 큐 최소 용량으로 지정. 백분율 값을 쓸 때 각 레벨의 모든 큐 용량 합은 100이어야 합니다. 절대 자원을 구성하면 자식 큐의 절대 자원 합이 부모 절대 자원 용량보다 작을 수 있습니다. 자유 자원이 있으면 큐의 애플리케이션은 큐 용량보다 더 많은 자원을 소비할 수 있어 탄력성을 제공합니다. legacy-queue 모드가 비활성화되면 Universal Capacity Vector 형식으로 큐 용량을 구성할 수 있습니다(예: [memory=50%,vcores=2w,gpu=1]).
yarn.scheduler.capacity.<queue-path>.maximum-capacity 최대 큐 용량을 백분율(%) float(capacity 속성이 백분율이나 가중치로 정의된 경우) 또는 절대 자원 큐 최대 용량으로 지정. 이는 큐 애플리케이션의 탄력성 을 제한합니다. 1) 값은 0과 100 사이. 2) 관리자는 각 큐에 대해 절대 최대 용량이 절대 용량보다 크거나 같아야 합니다. 또한 -1로 설정하면 최대 용량을 100%로 설정합니다. legacy-queue 모드가 비활성화되면 Universal Capacity Vector 형식을 사용할 수 있습니다(예: [memory=50%,vcores=2w,gpu=1]).
yarn.scheduler.capacity.minimum-user-limit-percent / yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent 각 큐는 자원에 수요가 있을 때 주어진 시점에 사용자에게 할당되는 자원 백분율에 한계를 적용합니다. 사용자 한계는 최소값과 최대값 사이에서 변할 수 있습니다. 전자(최소값)는 이 속성 값으로, 후자(최대값)는 애플리케이션을 제출한 사용자 수에 따라 달라집니다. 예를 들어 이 속성 값이 25라고 가정합니다. 두 사용자가 큐에 애플리케이션을 제출하면 단일 사용자는 큐 자원의 50%를 넘게 사용할 수 없습니다. 세 번째 사용자가 애플리케이션을 제출하면 단일 사용자는 큐 자원의 33%를 넘게 사용할 수 없습니다. 4명 이상이면 어떤 사용자도 큐 자원의 25%를 넘게 사용할 수 없습니다. 100 값은 사용자 한계가 없음을 의미합니다. 기본값은 100입니다. 값은 정수로 지정합니다. yarn.scheduler.capacity.minimum-user-limit-percent로 모든 큐에 설정하거나 yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent로 큐별로 재정의할 수 있습니다.
yarn.scheduler.capacity.user-limit-factor / yarn.scheduler.capacity.<queue-path>.user-limit-factor 사용자 한계 요소는 단일 사용자가 소비할 수 있는 최대 자원량을 제어하는 방법을 제공합니다. 큐 용량의 배수입니다. 기본적으로 1로 설정되어 클러스터가 얼마나 유휴 상태여도 단일 사용자가 큐의 구성된 용량보다 더 많이 가질 수 없도록 보장합니다. 증가시키면 단일 사용자가 클러스터의 최소 용량보다 더 많이 사용할 수 있고, 줄이면 최대 자원이 낮아집니다. -1로 설정하면 기능이 비활성화됩니다. 값은 float로 지정합니다. 참고: 가중치와 함께 유연한 자동 큐 생성(yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2)을 사용하면 이 속성이 자동으로 -1로 설정됩니다. 동적 큐가 하드코딩된 가중치 1로 생성되고 유휴 클러스터 시나리오에서 계산된 것보다 더 많은 자원을 사용할 수 있어야 하기 때문입니다. yarn.scheduler.capacity.user-limit-factor로 모든 큐에 설정하거나 큐별로 재정의할 수 있습니다.
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb Resource Manager에서 각 컨테이너 요청에 할당할 메모리의 큐별 최대 한계. 이 설정은 클러스터 구성 yarn.scheduler.maximum-allocation-mb를 재정의합니다. 이 값은 클러스터 최대값보다 작거나 같아야 합니다.
yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores Resource Manager에서 각 컨테이너 요청에 할당할 가상 코어의 큐별 최대 한계. 이 설정은 클러스터 구성 yarn.scheduler.maximum-allocation-vcores를 재정의합니다. 이 값은 클러스터 최대값보다 작거나 같아야 합니다.
yarn.scheduler.capacity.<queue-path>.user-settings.<user-name>.weight 큐의 사용자에 대한 사용자 한계 자원 값을 계산할 때 사용되는 부동 소수점 값. 이 값은 각 사용자를 큐의 다른 사용자보다 더 또는 덜 가중합니다. 예를 들어 사용자 A가 큐에서 사용자 B, C보다 50% 더 많은 자원을 받아야 한다면 A에 대해 이 속성을 1.5로 설정합니다. B, C는 기본 1.0입니다.
  • 자원 할당 구성 (legacy-queue-mode)

CapacityScheduler는 세 가지 자원 할당 구성 모드를 지원합니다: 백분율 값(상대 모드), 가중치, 절대 자원.

상대 모드는 큐의 자원을 부모 자원의 일부로 설명하는 방법을 제공합니다. 예를 들어 root.users 큐에 대해 capacity 가 50.0으로 설정되면 users 큐는 root 자원의 50%를 최소 용량으로 가집니다.

가중치 모드에서는 큐의 가중치가 같은 부모 아래 구성된 가중치의 합과 어떻게 관련되는지에 따라 자원이 나뉩니다. 예를 들어 부모 아래 3w, 2w, 5w 가중치를 가진 세 큐가 있으면 합은 10이므로 계산된 최소 용량 은 각각 30%, 20%, 50%입니다. 이 모드를 쓰는 이점은 유연성입니다. 백분율을 쓸 때는 부모 아래 합이 100%여야 하므로 새 큐가 추가될 때마다 백분율 값을 수동으로 다시 계산해야 하지만, 가중치면 자동으로 수행됩니다. 이전 예시에서 이전 세 개와 같은 부모 아래 10w 가중치를 가진 새 큐가 추가되면 새 합은 20이 되어 새 계산 용량 은 15%, 10%, 25%, 50%가 됩니다. 참고: _maximum-capacity_에는 가중치 모드가 없으므로 yarn.scheduler.capacity.<queue-path>.max-capacity는 백분율로 구성해야 합니다.

절대 자원 모드를 쓰려면 yarn.scheduler.capacity.<queue-path>.capacity와 yarn.scheduler.capacity.<queue-path>.max-capacity 둘 다 [memory=10240,vcores=12] 같은 절대 자원 값을 가져야 합니다. 이 구성은 10GB 메모리와 12 VCore를 나타냅니다.

큐 구조에서 가중치와 백분율을 혼합할 수 있지만, 한 부모 아래의 자식 큐는 같은 capacity 모드를 사용해야 합니다.

  • 자원 할당 구성 (non-legacy-queue-mode)

큐의 capacity와 maximum-capacity는 Universal Capacity Vector 형식으로 설정할 수 있습니다(예: [memory=50%,vcores=2w,gpu=1]). 이 예에서 Memory는 백분율 모드, Vcores는 가중치 모드, GPU는 절대 단위로 설정됩니다. 예: 백분율은 50.0, 절대는 [memory=1024,vcores=1], 가중치 모드는 1w처럼 이전 용량 형식도 사용할 수 있습니다. 다른 모드는 큐 계층에서 자유롭게 혼합할 수 있습니다.

자원 간 계층은 큐의 용량 구성과 가용 클러스터 자원에 기반해 계산됩니다. 자원 계층 계산은 정의된 각 자원 유형에 대해 다음 방식으로 수행됩니다: 1. 구성된 절대 용량을 가용 클러스터 자원에서 큐에 할당 2. 남은 클러스터 자원을 백분율 자원 구성이 있는 큐에 할당 3. 나머지 자원을 가중치 자원 구성이 있는 큐에 할당.

Universal Capacity Vector 형식을 사용한 혼합 큐 자원 할당 예시:

# Configuration
yarn.scheduler.capacity.legacy-queue-mode.enabled = false
yarn.scheduler.capacity.root.queues = default, test_1, test_2
yarn.scheduler.capacity.root.test_1.queues = test_1_1, test_1_2, test_1_3
yarn.scheduler.capacity.root.default.capacity =         [memory=1w, vcores=1w]
yarn.scheduler.capacity.root.test_1.capacity =          [memory=16384, vcores=16]
yarn.scheduler.capacity.root.test_1.test_1_1.capacity = [memory=50%, vcores=50%]
yarn.scheduler.capacity.root.test_1.test_1_2.capacity = [memory=1w, vcores=1w]
yarn.scheduler.capacity.root.test_1.test_1_3.capacity = [memory=12288, vcores=12]
yarn.scheduler.capacity.root.test_2.capacity =          [memory=75%, vcores=75%]

# ClusterResources=[32GB 32VCores]  EffectiveMin                     AbsoluteCapacity
root.default              4/32      [memory=4096,    vcores=4]       12.5%
root.test_1              16/32      [memory=16384,   vcores=16]
root.test_1.test_1_1        2/16      [memory=2048,  vcores=2]       6.25%
root.test_1.test_1_2        2/16      [memory=2048,  vcores=2]       6.25%
root.test_1.test_1_3       12/16      [memory=12288, vcores=12]      37.5%
root.test_2              12/32      [memory=12288,   vcores=12]      37.5%

추가 예시는 TestRMWebServicesCapacitySchedulerMixedMode.java에서 찾을 수 있습니다.

root 큐의 용량은 구성할 수 없으며 100%(백분율 모드)로 고정되어 있습니다.

실제 용량, absoluteCapacity 및 maximumApplications 같은 파생 속성은 자원 간 계층에서 계산됩니다. 클러스터 자원이 없으면 maximumApplications는 구성된 값으로 기본 설정됩니다.

  • 실행·대기 애플리케이션 한계

CapacityScheduler는 실행 및 대기 애플리케이션을 제어하는 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications 시스템에서 동시에 활성화(실행 및 대기 모두)될 수 있는 최대 애플리케이션 수. 각 큐의 한계는 큐 절대 용량과 사용자 한계에 직접 비례합니다. 이는 하드 한계이며 이 한계에 도달했을 때 제출된 애플리케이션은 거부됩니다. 기본값 10000. yarn.scheduler.capacity.maximum-applications로 모든 큐에 설정하거나 큐별로 재정의할 수 있습니다. 특정 큐 경로에 이 속성이 설정되지 않으면 최대 애플리케이션 수는 모든 구성된 노드 레이블을 고려해 가능한 가장 높은 값으로 계산됩니다. legacy-queue 모드가 비활성화되고 클러스터 자원이 없으면 구성된 값으로 기본 설정됩니다. 정수 값이 필요합니다.
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent 애플리케이션 마스터를 실행하는 데 사용할 수 있는 클러스터 자원의 최대 백분율 - 동시 활성 애플리케이션 수를 제어합니다. 각 큐의 한계는 큐 용량과 사용자 한계에 직접 비례합니다. float로 지정 - 즉 0.5 = 50%. 기본값 10%. 모든 큐에 설정하거나 큐별로 재정의할 수 있습니다.
yarn.scheduler.capacity.max-parallel-apps / yarn.scheduler.capacity.<queue-path>.max-parallel-apps 동시에 실행될 수 있는 최대 애플리케이션 수. maximum-applications와 달리 애플리케이션 제출은 이 한계에 도달해도 거부되지 않습니다. 대신 실행 자격이 될 때까지 ACCEPTED 상태로 유지됩니다. 모든 큐에 설정하거나 큐별로 재정의할 수 있습니다. 정수 값이 필요합니다. 기본적으로 한계가 없습니다. 최대 병렬 애플리케이션 한계는 큐 계층에서 상속되는 속성으로, 계층의 모든 분기에서 가장 낮은 값이 적용 한계로 선택됩니다.

사용자별 병렬 애플리케이션 수도 제한할 수 있습니다.

속성 설명
yarn.scheduler.capacity.user.max-parallel-apps 모든 사용자에 대해 동시에 실행될 수 있는 최대 애플리케이션 수. 기본값 무제한.
yarn.scheduler.capacity.user.<username>.max-parallel-apps 특정 사용자에 대해 동시에 실행될 수 있는 최대 애플리케이션 수. 전역 설정을 재정의합니다.

이 한계의 평가는 다음 순서로 발생합니다:

  1. maximum-applications 확인 - 한계를 초과하면 제출이 즉시 거부됩니다.

  2. max-parallel-apps 확인 - 제출은 수락되지만 애플리케이션은 RUNNING 상태로 전환되지 않습니다. 큐/사용자 한계가 충족될 때까지 ACCEPTED로 유지됩니다.

  3. maximum-am-resource-percent 확인 - Application Master가 너무 많이 실행 중이면 애플리케이션은 충분한 공간이 생길 때까지 ACCEPTED 상태로 유지됩니다.

  • 큐 관리 및 권한

CapacityScheduler는 큐를 관리하는 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.state 큐의 상태. RUNNING 또는 STOPPED 중 하나. 큐가 STOPPED 상태이면 그 큐 나 그 자식 큐들 에 새 애플리케이션을 제출할 수 없습니다. 따라서 root 큐가 STOPPED면 전체 클러스터에 애플리케이션을 제출할 수 없습니다. 기존 애플리케이션은 계속 완료되므로 큐를 우아하게 배수 할 수 있습니다. 값은 열거형으로 지정합니다.
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications 주어진 큐에 애플리케이션을 제출 할 수 있는 사람을 제어하는 ACL. 주어진 사용자/그룹이 주어진 큐 또는 계층의 부모 큐 중 하나 에 필요한 ACL을 가지면 애플리케이션을 제출할 수 있습니다. 지정되지 않으면 이 속성의 ACL 은 부모 큐에서 상속 됩니다. 이 목록의 사용자 이름 앞에 물결표(~)가 붙으면 실제 사용자의 ACL이 프록시 사용자가 큐에 제출하도록 허용합니다.
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue 주어진 큐에서 애플리케이션을 관리 할 수 있는 사람을 제어하는 ACL. 주어진 사용자/그룹이 주어진 큐 또는 계층의 부모 큐 중 하나 에 필요한 ACL을 가지면 애플리케이션을 관리할 수 있습니다. 지정되지 않으면 상속됩니다. 사용자 이름 앞에 ~이 붙으면 실제 사용자의 ACL이 프록시 사용자가 큐의 앱을 관리하도록 허용합니다.

참고: ACL 은 user1,user2 space group1,group2 형식입니다. 특수 값 *는 누구나 를 의미합니다. 특수 값 space 는 아무도 없음을 의미합니다. 지정되지 않으면 root 큐의 기본값은 *입니다.

  • 애플리케이션 수명

CapacityScheduler는 애플리케이션의 수명을 제어하는 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime 큐에 제출된 애플리케이션의 최대 수명(초). 0 이하 값은 비활성화로 간주됩니다. 기본값 -1. 양수 값이 구성되면 이 큐에 제출된 애플리케이션은 구성된 수명을 초과하면 종료됩니다. 사용자는 제출 컨텍스트에서 애플리케이션별 수명을 지정할 수도 있습니다. 단, 사용자 수명이 큐 최대 수명을 초과하면 무시됩니다. 이는 특정 시점 구성입니다. 참고: 이 기능은 큐 계층의 어느 레벨에서든 설정할 수 있습니다. 자식 큐는 자식 레벨에서 재정의되지 않는 한 부모 값을 상속합니다. 0 값은 최대 수명이 없음을 의미하며 부모의 최대 수명을 재정의합니다. 이 속성이 설정되지 않거나 음수로 설정되면 이 큐의 최대 수명 값은 부모에서 상속됩니다.
yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime 큐에 제출된 애플리케이션의 기본 수명(초). 0 이하 값은 비활성화로 간주됩니다. 사용자가 수명 값을 제출하지 않았으면 이 값이 사용됩니다. 특정 시점 구성입니다. 이 기능은 큐 계층의 어느 레벨에서든 설정할 수 있습니다. 자식은 재정의하지 않는 한 부모 값을 상속합니다. 0 이하로 설정되면 큐의 최대 값도 무제한이어야 합니다. 기본 수명은 최대 수명을 초과할 수 없습니다.
  • 사용자/그룹, 애플리케이션 이름 또는 사용자 정의 배치 규칙 기반 큐 매핑

CapacityScheduler는 사용자·그룹, 사용자 & 그룹, 또는 애플리케이션 이름에 기반한 큐 매핑을 구성하는 다음 파라미터를 지원합니다. 사용자가 자체 배치 규칙을 정의할 수도 있습니다.

속성 설명
yarn.scheduler.capacity.queue-mappings 이 구성은 사용자 또는 그룹을 특정 큐에 매핑합니다. 단일 사용자 또는 사용자 목록을 큐에 매핑할 수 있습니다. 구문: [u or g]:[name]:[queue_name][,next_mapping]*. 여기서 u or g 는 매핑이 사용자용인지 그룹용인지 나타냅니다. 값은 사용자의 경우 u, 그룹의 경우 g 입니다. name 은 사용자 이름 또는 그룹 이름을 나타냅니다. 애플리케이션을 제출한 사용자를 지정하려면 %user를 사용할 수 있습니다. queue_name 은 애플리케이션이 매핑될 큐 이름을 나타냅니다. 사용자 이름과 같은 큐 이름을 지정하려면 %user 를, 사용자가 속한 기본 그룹의 이름과 같은 큐 이름을 지정하려면 %primary_group 을 사용할 수 있습니다. 보조 그룹은 %secondary_group 으로 참조할 수 있습니다.
yarn.scheduler.queue-placement-rules.app-name 이 구성은 application_name을 특정 큐에 매핑합니다. 단일 애플리케이션 또는 애플리케이션 목록을 큐에 매핑할 수 있습니다. 구문: [app_name]:[queue_name][,next_mapping]*. app_name 은 매핑하려는 애플리케이션 이름을 나타냅니다. queue_name 은 애플리케이션이 매핑될 큐 이름을 나타냅니다. 현재 애플리케이션의 이름을 app_name으로 지정하려면 %application을 사용할 수 있습니다.
yarn.scheduler.capacity.queue-mappings-override.enable 이 기능은 사용자가 지정한 큐를 재정의할 수 있는지 지정하는 데 사용됩니다. Boolean 값이며 기본값은 false 입니다.

예시:

아래 예는 단일 매핑을 별도로 다룹니다. 쉼표로 구분된 값으로 여러 매핑을 할 경우 평가는 왼쪽에서 오른쪽으로 진행되며 첫 번째 유효한 매핑이 사용됩니다. 아래 예의 순서는 여러 매핑의 경우 실행 시 실제 실행 순서에 따라 문서화되었습니다.

<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:%user:%primary_group.%user</value>
   <description>Maps users to queue with the same name as user but
   parent queue name should be same as primary group of the user</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:%user:%secondary_group.%user</value>
   <description>Maps users to queue with the same name as user but
   parent queue name should be same as any secondary group of the user</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:%user:%user</value>
   <description>Maps users to queues with the same name as user</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user2:%primary_group</value>
   <description>user2 is mapped to queue name same as primary group</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user3:%secondary_group</value>
   <description>user3 is mapped to queue name same as secondary group</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user1:queue1</value>
   <description>user1 is mapped to queue1</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>g:group1:queue2</value>
   <description>group1 is mapped to queue2</description>
</property>
...
<property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user1:queue1,u:user2:queue2</value>
   <description>Here, <user1> is mapped to <queue1>, <user2> is mapped to <queue2> respectively</description>
</property>

<property>
   <name>yarn.scheduler.queue-placement-rules.app-name</name>
   <value>appName1:queue1,%application:%application</value>
   <description>
     Here, <appName1> is mapped to <queue1>, maps applications to queues with
     the same name as application respectively. The mappings will be
     evaluated from left to right, and the first valid mapping will be used.
   </description>
</property>

JSON 기반 큐 매핑 구성

큐 매핑 기능을 더 다양하게 만들기 위해 Capacity Scheduler에 새 형식과 평가 엔진이 추가되었습니다. 새 엔진은 이전 엔진과 완전히 역호환되며 여러 새 기능을 추가합니다. 이전 형식도 구문 분석할 수 있지만 새 기능은 매핑을 JSON으로 지정할 때만 사용할 수 있습니다.

구문 (Syntax)

현재 JSON 스키마에 따라 사용자는 매핑 규칙을 다음과 같이 정의할 수 있습니다.

{
  "rules": [
    {
      "type": "...",
      "matches": "...",
      "policy": "...",
      "parentQueue": "...",
      "customPlacement": "...",
      "fallbackResult":"...",
      "create": true/false,
      "value": "...",
      "customPlacement": "..."
    },
    {
       ... next rule ...
    }
  ]
}

규칙은 위에서 아래로 평가됩니다. 이전 매핑 규칙 평가기와 비교해, 평가가 멈추고 주어진 규칙이 일치하지 않을 때 무엇이 일어날지 더 유연하게 조정할 수 있습니다.

JSON 기반 큐 매핑 활성화 방법

다음 속성이 새 배치 엔진이 규칙을 어떻게 기대하는지 제어합니다.

설정 설명
yarn.scheduler.capacity.mapping-rule-format 허용 값은 legacy 또는 json. 설정되지 않으면 엔진은 이전 형식이 사용 중일 수 있다고 가정하므로 yarn.scheduler.capacity.queue-mappings의 값도 확인합니다. 따라서 이 값은 json으로 설정해야 하며 비워둘 수 없습니다.
yarn.scheduler.capacity.mapping-rule-json 이 속성의 값은 전체 규칙 체인을 인라인으로 포함해야 합니다. 이는 Mutation API(즉 REST 인터페이스로 구성을 실시간 수정)를 사용한다면 Capacity Scheduler를 구성하는 권장 방식입니다.
yarn.scheduler.capacity.mapping-rule-json-file 규칙을 포함한 JSON 파일의 절대 경로를 정의. 예: /opt/hadoop/config/mapping-rules.json.

yarn.scheduler.capacity.mapping-rule-json 속성이 yarn.scheduler.capacity.mapping-rule-json-file보다 우선합니다. 형식이 json으로 설정되었지만 둘 다 정의하지 않으면 경고가 표시되지만 Capacity Scheduler 초기화는 실패하지 않습니다.

legacy와 유연한 큐 자동 생성 모드의 차이

부모 아래에서 유연한 Queue Auto-Creation을 사용하려면 큐 용량이 legacy-queue-mode에서 가중치로 구성되어야 합니다. 유연한 모드는 매핑 규칙에 기반해 새 리프 큐나 전체 큐 계층을 자동 생성하는 훨씬 더 많은 자유를 사용자에게 제공합니다. "Legacy" 모드는 백분율 기반 구성 또는 절대 자원으로 용량이 정의되는 경우를 말합니다. legacy-queue-mode가 비활성화되면 용량은 Universal Capacity Vector 형식, 가중치 1w, 백분율 75, 또는 절대 단위 [memory=1024,vcores=1]로 구성할 수 있습니다.

유연한 Queue Auto-Creation 모드에서 모든 부모 큐는 (yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.enabled 속성이 true로 설정된 경우) 정적 자식 큐가 이미 있어도 동적으로 생성된 부모 또는 리프 큐를 가질 수 있습니다. 이는 또한 스케줄러 구성 방식에 따라 특정 설정이 큐 배치 결과에 영향을 미친다는 뜻입니다.

모드가 관련될 때 문서는 특정 설정이나 플래그가 전체 논리에 어떻게 영향을 미치는지 설명합니다.

규칙 (Rules)

각 매핑 규칙은 다음 설정을 가질 수 있습니다.

설정 설명
type 가능 값: user, group, application. 엔진에게 현재 규칙이 무엇과 일치되어야 하는지 알려줍니다.
matches 일치시킬 문자열, 또는 "전부"를 의미하는 별표 "". 예를 들어 type이 user이고 이 문자열이 "hadoop"이면 제출자가 "hadoop"일 때만 규칙이 평가됩니다. ""는 그룹과는 작동하지 않습니다.
policy 애플리케이션을 배치할 위치를 정의하는 미리 정의된 정책 목록을 선택. 이는 나중에 "Policies" 절에서 설명합니다.
parentQueue user, primaryGroup, primaryGroupUser, secondaryGroup, secondaryGroupUser 정책의 경우 일치하는 큐를 찾을 위치를 엔진에 알려줍니다. 예를 들어 policy가 primaryGroup이고 parent가 root.groups이며 제출자의 그룹이 "admins"이면 결과 큐는 "root.groups.admin"입니다.
fallbackResult 대상 큐가 없거나 생성할 수 없으면 폴백 동작을 정의. 유효 값은 skip, reject, placeDefault.
create "false"로 설정하면 큐가 없어도 생성되지 않습니다. 이 플래그는 유연한 모드와 legacy 모드에서 다르게 작동합니다(아래 참고).
value policy가 setDefaultQueue면 기본 큐가 "root.default"에서 이 설정으로 변경됩니다. 그 외에는 무시됩니다.
customPlacement custom 배치 정책에서만 작동. 이 필드의 값은 엔진이 직접 평가하므로 %application이나 %primary_group 같은 다양한 자리 표시자가 각각의 값으로 대체됩니다.

type은 이전 형식의 첫 번째 열과 동일합니다. "g" 또는 "u"이며 애플리케이션 매핑용 별도 속성이 있습니다. matches는 두 번째 열입니다. 유일한 차이는 %user가 모든 사용자를 일치시키는 것을 의미하지만 충분히 표현력이 없다는 것입니다. 그래서 새 형식에서 *로 바뀌었습니다. fallbackResult 설정은 대상 큐를 생성할 수 없거나 없을 때 무엇을 할지 확인합니다. 세 가지 설정은 다음과 같이 작동합니다:

  • skip: 현재 규칙을 무시하고 다음으로 진행. Fair Scheduler가 배치 규칙을 평가하는 방식입니다.

  • placeDefault: 애플리케이션을 기본 큐 root.default에 배치(다른 곳으로 재정의되지 않은 경우). Capacity Scheduler가 이전 매핑 규칙에서 작동하는 방식입니다.

  • reject: 제출을 거부.

create 플래그는 모드의 영향을 받습니다:

  • Legacy 모드: yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.enabled가 true로 설정된 모든 부모 큐에 적용.

  • Flexible 모드: yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.enabled가 true로 설정된 모든 부모 큐에 적용.

정책 (Policies)

Fair Scheduler의 것과 유사한 여러 미리 정의된 배치 정책이 있습니다. 이 중 상당수는 곧 보겠지만 "custom" 배치 정책으로 표현할 수 있지만, 많은 경우 직접 사용하는 것이 더 안전하고 간단합니다.

정책 설명
specified 제출 중 정의된 큐에 애플리케이션을 배치.
reject 제출을 거부.
defaultQueue 애플리케이션을 기본 큐 root.default 또는 setDefaultQueue가 설정한 재정의 값에 배치.
user 제출자의 사용자 이름과 일치하는 큐에 애플리케이션을 배치.
applicationName 애플리케이션 이름과 일치하는 큐에 배치. 중요: 대소문자를 구분하며 공백은 제거되지 않습니다.
primaryGroup 제출자의 기본 그룹과 일치하는 큐에 배치.
primaryGroupUser root.[parentQueue].<primaryGroup>.<userName> 큐 계층에 배치. parentQueue는 선택 사항입니다.
secondaryGroup 제출자의 보조 그룹과 일치하는 큐에 배치.
secondaryGroupUser root.[parentQueue].<secondaryGroup>.<userName> 큐 계층에 배치. parentQueue는 선택 사항입니다.
setDefaultQueue 기본 큐를 root.default에서 변경. 변경은 다음 규칙에서 복원되지 않는다는 점에서 영구적입니다. 언제든 기본 큐를 원하는 만큼 변경할 수 있습니다.
custom 사용자가 사용자 정의 배치 문자열을 사용할 수 있게 합니다. 아래 설명 참고.

참고:

  1. setDefaultQueue 규칙은 기본 큐만 변경합니다. 기본 큐를 root.default로 복원하려면 규칙 체인에 다시 추가해야 합니다.

  2. 중첩 규칙 primaryGroupUser와 secondaryGroupUser는 legacy와 flexible 모드에서 다르게 작동합니다:

    • Legacy 모드: 부모 큐가 존재할 것으로 기대합니다, 즉 자동 생성할 수 없습니다. 더 구체적으로: primaryGroupUser를 쓰면 root.<primaryGroup>.<userName> 같은 큐 경로가 되며 root.<primaryGroup>은 반드시 존재해야 합니다. userName 리프가 자동 생성되도록 관리 부모일 수 있지만, 부모는 여전히 손으로 만들어야 합니다.

    • Flexible 모드: 부모가 동적 큐 생성을 허용하는 한 제한이 없습니다. 요청된 큐가 생성됩니다.

  3. custom 배치 정책은 적절한 변수 자리 표시자로 다른 정책을 설명할 수 있습니다(아래 참고). 예를 들어 부모 큐 root.groups가 있는 primaryGroupUser는 root.groups.%primary_group.%user로 표현할 수 있습니다. 규칙이 존재하는 주된 이유는 Fair Scheduler 구성 배경이 있는 사용자가 이해하기 쉽고 이런 방식으로 매핑 규칙을 구성하는 것이 더 자연스럽기 때문입니다. 또한 사용자가 실수할 가능성이 적어 더 견고합니다. custom 정책을 사용하려면 "Variables" 절에서 어떤 변수를 사용할 수 있는지 설명합니다.

변수 (Variables)

내부적으로 도구는 적절한 값으로 특정 변수를 채웁니다. custom 매핑 정책이 선택되면 이 변수들을 사용할 수 있습니다. 엔진은 변수를 대체할 때 최소한의 검증만 수행한다는 점을 참고하세요 - 따라서 올바른 문자열을 제공하는 것은 사용자 책임입니다.

변수 의미
%application 제출된 애플리케이션의 이름.
%user 애플리케이션을 제출한 사용자.
%primary_group 제출자의 기본 그룹.
%secondary_group 제출자의 보조(추가) 그룹.
%default 스케줄러의 기본 큐.
%specified 제출자가 정의한 큐를 포함.

예: root.users.mrjobs 큐에 MapReduce 애플리케이션을 제출한다고 합시다. 이 경우 %specified의 값은 root.users.mrjobs로 설정됩니다.

"Policies" 절에서 설명했듯이 꽤 많은 정책을 custom으로 달성할 수 있습니다. specified 정책을 쓰는 대신 custom을 쓰고 customPlacement 필드를 %specified로 설정할 수 있습니다. 하지만 이 변수에 추가 문자열을 붙이거나 앞에 추가할 수 있으므로 훨씬 더 큰 제어권을 가집니다. 따라서 %specified.%user.largejobs 같은 설정이 가능합니다. 올바른 배치를 위해 문자열이 유효한 큐 경로로 해석되어야 한다는 점을 명심하세요.

이전 매핑 규칙 형식을 새 형식으로 변환

이 표에서 콜론으로 구분된 이전 규칙을 새 형식으로 다시 쓰는 방법을 볼 수 있습니다.

이전 매핑 규칙 JSON 기반 매핑 규칙
u:username:root.user.queue { "type": "user", "matches": "username", "policy": "custom", "customPlacement": "root.user.queue", "fallbackResult":"placeDefault" }
u:%user:%user { "type": "user", "matches": "*", "policy": "user", "fallbackResult":"placeDefault" }
u:%user:root.parent.%user { "type": "user", "matches": "*", "policy": "user", "parentQueue": "root.parent", "fallbackResult":"placeDefault" }
u:%user:%primary_group { "type": "user", "matches": "*", "policy": "primaryGroup", "fallbackResult":"placeDefault" }
u:%user:%primary_group.%user { "type": "user", "matches": "*", "policy": "primaryGroupUser", "fallbackResult":"placeDefault" }
u:%user:root.groups.%primary_group.%user { "type": "user", "matches": "*", "policy": "primaryGroupUser", "parentQueue": "root.groups", "fallbackResult":"placeDefault" }
u:%user:%secondary_group { "type": "user", "matches": "*", "policy": "secondaryGroup", "fallbackResult":"placeDefault" }
u:%user:%secondary_group.%user { "type": "user", "matches": "*", "policy": "secondaryGroupUser", "fallbackResult":"placeDefault" }
u:%user:root.groups.%secondary_group.%user { "type": "user", "matches": "*", "policy": "secondaryGroupUser", "parentQueue": "root.groups", "fallbackResult":"placeDefault" }
g:hadoop:root.groups.hadoop { "type": "group", "matches": "hadoop", "policy": "custom", "customPlacement": "root.groups.hadoop", "fallbackResult":"placeDefault" }
%application:%application (애플리케이션 매핑) { "type": "user", "matches": "*", "policy": "applicationName", "fallbackResult":"placeDefault" }
hive_query:root.query.hive (애플리케이션 매핑) { "type": "application", "matches": "hive_query", "policy": "custom", "customPlacement": "root.query.hive", "fallbackResult":"placeDefault" }

%application:%application이 user 유형 매처를 요구한다는 점에 주목할 가치가 있습니다. 내부적으로 ""는 사용자에 대해서만 해석되기 때문입니다. type을 application으로 설정하면 ""는 "*"라는 이름의 애플리케이션과 일치시키는 것을 의미합니다.

예시 (Example)

개발자, QA 엔지니어, 테스트 개발자가 공유하는 클러스터가 있다고 합시다.

다음 배치 논리를 달성하려고 합니다:

  1. 사용자가 devs 기본 그룹에 속하면 root.users.devs에 배치. 이 큐는 개발자용으로 예약됩니다.

  2. 사용자가 qa 기본 그룹에 속하면 애플리케이션은 root.users.lowpriogroups.<primaryGroup>으로 감. 이 큐는 용량이 낮고 테스터용입니다.

  3. 사용자가 qa-dev 기본 그룹에 속하면 애플리케이션은 root.users.highpriogroups.<primaryGroup>으로 감. 이 큐는 용량이 높고 테스트 개발자용입니다.

  4. 사용자 이름과 일치하는 큐에 애플리케이션 배치.

  5. 그러한 큐가 없으면 애플리케이션 제출 맥락에서 큐를 가져오지만, 큐가 없고 부모가 관리형이면 생성하지 않아야 합니다.

  6. 위 중 어떤 것도 일치하지 않으면 애플리케이션을 root.default에 배치.

  7. 기본 배치가 어떠한 이유로 실패하면 기본 큐를 root.users.default로 변경.

  8. 기본 큐에 다시 배치 시도.

  9. 그것도 실패하면 제출을 완전히 거부.

이것은 9개의 규칙 체인을 의미합니다:

{
 "rules":[
   {
     "type": "group",
     "matches": "devs",
     "policy": "custom",
     "customPlacement": "root.users.devs",
     "fallbackResult":"skip"
   },
   {
     "type": "group",
     "matches": "qa",
     "policy": "primaryGroup",
     "parentQueue": "root.users.lowpriogroups",
     "fallbackResult":"skip"
   },
   {
     "type": "group",
     "matches": "qa-dev",
     "policy": "primaryGroup",
     "parentQueue": "root.users.highpriogroups",
     "fallbackResult":"skip"
   },
   {
     "type": "user",
     "matches": "*",
     "policy": "user",
     "fallbackResult":"skip"
   },
   {
     "type": "user",
     "matches": "*",
     "policy": "specified",
     "create": false,
     "fallbackResult":"skip"
   },
   {
     "type": "user",
     "matches": "*",
     "policy": "defaultQueue",
     "fallbackResult":"skip"
   },
   {
     "type": "user",
     "matches": "*",
     "policy": "setDefaultQueue",
     "value": "root.users.default",
     "fallbackResult": "skip"
   },
   {
     "type": "user",
     "matches": "*",
     "policy": "defaultQueue",
     "fallbackResult":"skip"
   },
   {
     "type":"user",
     "matches":"*",
     "policy":"reject"
   }
 ]
}

참고: 실제로 8번째 규칙에서 fallbackResult를 reject로 설정할 수 있으므로 마지막 reject가 필요 없습니다. 하지만 reject를 단독으로 쓰는 것도 장점이 있습니다: type과 matches 필드가 필수이므로 특정 그룹, 애플리케이션, 사용자의 제출을 거부할 수 있습니다.

애플리케이션 우선순위 설정 (Setup for application priority)

애플리케이션 우선순위는 FIFO 정렬 정책과 함께만 작동합니다. 기본 정렬 정책은 FIFO입니다.

애플리케이션의 기본 우선순위는 클러스터 레벨과 큐 레벨로 지정할 수 있습니다.

  • 클러스터 레벨 우선순위 : 클러스터 최대 우선순위보다 큰 우선순위로 제출된 애플리케이션은 우선순위가 클러스터 최대 우선순위로 재설정됩니다. $HADOOP_HOME/etc/hadoop/yarn-site.xml이 클러스터 최대 우선순위의 구성 파일입니다.
속성 설명
yarn.cluster.max-application-priority 클러스터의 최대 애플리케이션 우선순위 정의.
  • 리프 큐 레벨 우선순위 : 각 리프 큐는 관리자가 기본 우선순위를 제공합니다. 큐의 기본 우선순위는 우선순위를 지정하지 않고 제출된 애플리케이션에 사용됩니다. $HADOOP_HOME/etc/hadoop/capacity-scheduler.xml이 큐 레벨 우선순위의 구성 파일입니다.
속성 설명
yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority 리프 큐의 기본 애플리케이션 우선순위 정의.

참고: 애플리케이션이 다른 큐로 이동될 때 애플리케이션의 우선순위는 변경되지 않습니다.

Capacity Scheduler 컨테이너 선점 (Capacity Scheduler container preemption)

CapacityScheduler는 보장된 용량보다 많은 자원을 사용하는 큐에서 컨테이너를 선점하는 것을 지원합니다. 애플리케이션 컨테이너 선점을 지원하려면 yarn-site.xml에서 다음 구성 파라미터를 활성화해야 합니다.

속성 설명
yarn.resourcemanager.scheduler.monitor.enable 스케줄러에 영향을 미치는 주기 모니터 집합(yarn.resourcemanager.scheduler.monitor.policies에 지정)을 활성화. 기본값 false.
yarn.resourcemanager.scheduler.monitor.policies 스케줄러와 상호작용하는 SchedulingEditPolicy 클래스 목록. 구성된 정책은 스케줄러와 호환되어야 합니다. 기본값은 CapacityScheduler와 호환되는 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy.

yarn.resourcemanager.scheduler.monitor.policies에 ProportionalCapacityPreemptionPolicy 클래스가 구성되면 다음 구성 파라미터를 yarn-site.xml에서 구성해 컨테이너 선점을 제어할 수 있습니다.

속성 설명
yarn.resourcemanager.monitor.capacity.preemption.observe_only true면 정책을 실행하지만 선점 및 종료 이벤트로 클러스터에 영향을 주지 않습니다. 기본값 false
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval 이 ProportionalCapacityPreemptionPolicy 정책 호출 사이의 시간(밀리초). 기본값 3000
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill 애플리케이션에 선점을 요청한 후 컨테이너를 종료하기까지의 시간(밀리초). 기본값 15000
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round 한 라운드에서 선점되는 자원의 최대 백분율. 이 값을 제어해 클러스터에서 컨테이너를 회수하는 속도를 조절할 수 있습니다. 총 목표 선점을 계산한 뒤 정책은 이 한계 내로 축소합니다. 기본값 0.1
yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity 선점에 대해 무시되는 목표 용량 초과 자원의 최대량. 이는 계산된 목표 균형 주변의 데드존을 정의해 스래싱과 진동을 방지합니다. 높은 값은 용량 도달 시간을 늦추고(자연 완료가 없으면) 보장 용량으로의 수렴을 막을 수 있습니다. 기본값 0.1
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor 계산된 선점 목표가 주어지면 자연적으로 만료되는 컨테이너를 고려해 이 백분율의 델타만 선점합니다. 이는 데드존(MAX_IGNORED_OVER_CAPACITY)으로의 기하 수렴 속도를 결정합니다. 예를 들어 종료 요소 0.5는 자연 종료가 없어도 5 * #WAIT_TIME_BEFORE_KILL 내에 자원의 거의 95%를 회수합니다. 기본값 0.2

CapacityScheduler는 큐에 제출된 애플리케이션 컨테이너의 선점을 제어하기 위해 capacity-scheduler.xml에서 다음 구성을 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.disable_preemption 주어진 큐에 제출된 애플리케이션 컨테이너의 선점을 선택적으로 비활성화하기 위해 true로 설정할 수 있습니다. 이 속성은 yarn.resourcemanager.scheduler.monitor.enable을 true 로, yarn.resourcemanager.scheduler.monitor.policies를 ProportionalCapacityPreemptionPolicy 로 구성해 시스템 전체 선점이 활성화된 경우에만 적용됩니다. 큐에 이 속성이 설정되지 않으면 부모에서 상속됩니다. 기본값 false.
yarn.scheduler.capacity.<queue-path>.intra-queue-preemption.disable_preemption 주어진 큐에 제출된 애플리케이션 컨테이너의 큐 내(intra-queue) 선점을 선택적으로 비활성화하기 위해 true 로 설정할 수 있습니다. 이 속성은 시스템 전체 선점이 활성화되고 yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.enabled가 true 인 경우에만 적용됩니다. 큐에 설정되지 않으면 부모에서 상속됩니다. 기본값 false.

예약 속성 (Reservation Properties)

  • 예약 관리 및 권한

CapacityScheduler는 예약의 생성, 삭제, 갱신, 나열을 제어하는 다음 파라미터를 지원합니다. 모든 사용자는 자신의 예약을 갱신, 삭제, 나열할 수 있습니다. 예약 ACL이 활성화되었지만 정의되지 않으면 모든 사람이 접근할 수 있습니다. 아래 예에서 는 큐 이름입니다. 예를 들어 기본 큐에서 예약을 관리하는 예약 ACL을 설정하려면 yarn.scheduler.capacity.root.default.acl_administer_reservations 속성을 사용합니다.

속성 설명
yarn.scheduler.capacity.root.<queue>.acl_administer_reservations 주어진 큐에 예약을 관리 할 수 있는 사람을 제어하는 ACL. 주어진 사용자/그룹이 주어진 큐에 필요한 ACL이 있으면 모든 예약을 제출, 삭제, 갱신, 나열할 수 있습니다. 지정되지 않으면 이 속성의 ACL은 부모 큐에서 상속되지 않습니다.
yarn.scheduler.capacity.root.<queue>.acl_list_reservations 주어진 큐에 예약을 나열 할 수 있는 사람을 제어하는 ACL. 주어진 사용자/그룹이 주어진 큐에 필요한 ACL이 있으면 모든 애플리케이션을 나열할 수 있습니다. 지정되지 않으면 상속되지 않습니다.
yarn.scheduler.capacity.root.<queue>.acl_submit_reservations 주어진 큐에 예약을 제출 할 수 있는 사람을 제어하는 ACL. 주어진 사용자/그룹이 주어진 큐에 필요한 ACL이 있으면 예약을 제출할 수 있습니다. 지정되지 않으면 상속되지 않습니다.

CapacityScheduler로 ReservationSystem 구성

CapacityScheduler는 사용자가 미리 자원을 예약할 수 있는 ReservationSystem을 지원합니다. 애플리케이션은 제출 시 reservationId를 지정해 런타임에 예약된 자원을 요청할 수 있습니다. ReservationSystem을 위해 yarn-site.xml에서 다음 구성 파라미터를 구성할 수 있습니다.

속성 설명
yarn.resourcemanager.reservation-system.enable 필수 파라미터: ResourceManager에서 ReservationSystem을 활성화. Boolean 값 필요. 기본값 false, 즉 ReservationSystem은 기본적으로 활성화되지 않습니다.
yarn.resourcemanager.reservation-system.class 선택 파라미터: ReservationSystem의 클래스 이름. 기본값은 구성된 Scheduler에 따라 선택, 즉 CapacityScheduler가 구성되면 CapacityReservationSystem입니다.
yarn.resourcemanager.reservation-system.plan.follower 선택 파라미터: 타이머로 실행되어 CapacityScheduler를 Plan과 동기화하고 그 반대도 하는 PlanFollower의 클래스 이름. 기본값은 구성된 Scheduler에 따라 선택, 즉 CapacityScheduler가 구성되면 CapacitySchedulerPlanFollower입니다.
yarn.resourcemanager.reservation-system.planfollower.time-step 선택 파라미터: PlanFollower 타이머의 주기(밀리초). Long 값 필요. 기본값 1000.

ReservationSystem은 CapacityScheduler 큐 계층과 통합되며 현재 모든 LeafQueue에 대해 구성할 수 있습니다. CapacityScheduler는 ReservationSystem을 조정하기 위한 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.reservable 필수 파라미터: 큐의 자원을 사용자가 예약할 수 있음을 ReservationSystem에 나타냄. Boolean 값 필요. 기본값 false, 즉 LeafQueues 에서 예약은 기본적으로 활성화되지 않습니다.
yarn.scheduler.capacity.<queue-path>.reservation-agent 선택 파라미터: 사용자의 예약 요청을 Plan에 배치하려고 시도할 ReservationAgent의 구현을 결정하는 데 사용되는 클래스 이름. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.
yarn.scheduler.capacity.<queue-path>.reservation-move-on-expiry 선택 파라미터: 연결된 예약이 만료될 때 애플리케이션을 부모 reservable 큐로 이동할지 종료할지 ReservationSystem에 지정. Boolean 값 필요. 기본값 true 로 애플리케이션이 reservable 큐로 이동됨을 나타냄.
yarn.scheduler.capacity.<queue-path>.show-reservations-as-queues 선택 파라미터: Scheduler UI에서 예약 큐를 표시하거나 숨김. Boolean 값 필요. 기본값 false, 즉 예약 큐는 숨겨집니다.
yarn.scheduler.capacity.<queue-path>.reservation-policy 선택 파라미터: 새 예약이 어떤 안전 조건도 위반하지 않는지 검증하는 SharingPolicy의 구현을 결정하는 데 사용되는 클래스 이름. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.
yarn.scheduler.capacity.<queue-path>.reservation-window 선택 파라미터: SharingPolicy가 Plan의 제약이 충족되는지 검증하는 시간(밀리초). Long 값 필요. 기본값 하루.
yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity 선택 파라미터: SharingPolicy가 단일 사용자가 예약하도록 허용하는 어느 시점의 최대 용량(백분율(%) float). 기본값 1, 즉 100%.
yarn.scheduler.capacity.<queue-path>.average-capacity 선택 파라미터: SharingPolicy가 단일 사용자가 예약하도록 허용하는 ReservationWindow 에 걸쳐 집계될 평균 허용 용량(백분율(%) float). 기본값 1, 즉 100%.
yarn.scheduler.capacity.<queue-path>.reservation-planner 선택 파라미터: (예정된 유지보수나 노드 실패로) Plan 용량이 사용자 예약 자원보다 낮아지면 호출될 Planner 의 구현을 결정하는 데 사용되는 클래스 이름. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner 로 예약된 자원이 Plan 용량 내에 들어올 때까지 Plan을 스캔하고 수락 역순(LIFO)으로 예약을 탐욕적으로 제거합니다.
yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window 선택 파라미터: Planner가 Plan의 제약이 충족되는지 검증하는 시간(밀리초). Long 값 필요. 기본값 한 시간.

리프 큐의 동적 자동 생성 및 관리

CapacityScheduler는 두 가지 유형의 큐 자동 생성 모드를 지원합니다: legacy와 flexible. Legacy 모드는 이 기능을 사용하도록 구성된 부모 큐 아래 리프 큐 생성을 허용합니다. Flexible 모드는 부모 큐 와 리프 큐 생성 모두를 허용합니다. 참고: 생성된 큐는 capacity 로 가중치로만 구성될 수 있으며 구성됩니다.

  • 큐 매핑을 통한 동적 자동 생성 리프 큐 설정

yarn.scheduler.capacity.queue-mappings에 나열된 user-group 큐 매핑 은 자동 생성 리프 큐가 어느 부모 큐 아래 생성되어야 하는지 식별하기 위해 추가 부모 큐 파라미터를 지정해야 합니다. 자세한 내용은 위의 Queue Mapping based on User or Group 절을 참고하세요. 이러한 부모 큐도 아래 Parent queue configuration for dynamic leaf queue creation and management 절에서 설명한 대로 자식 큐 자동 생성을 활성화해야 합니다.

예:

<property>
  <name>yarn.scheduler.capacity.queue-mappings</name>
  <value>u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1.%user</value>
  <description>
    Here, u:%user:parent1.%user mapping allows any <user> other than user1,
    user2 to be mapped to its own user specific leaf queue which
    will be auto-created under <parent1>.
  </description>
</property>
  • legacy 동적 리프 큐 자동 생성 및 관리를 위한 부모 큐 구성

Dynamic Queue Auto-Creation and Management 기능은 CapacityScheduler 큐 계층과 통합되며 현재 ParentQueue 에 대해 리프 큐를 자동 생성하도록 구성할 수 있습니다. 이러한 부모 큐는 자동 생성된 큐와 함께 미리 구성된 다른 큐가 공존하는 것을 지원하지 않습니다. CapacityScheduler는 큐 자동 생성을 활성화하기 위한 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.enabled 필수 파라미터: 지정된 부모 큐에 대해 리프 큐 자동 생성을 활성화해야 함을 CapacityScheduler에 나타냄. Boolean 값 필요. 기본값 false, 즉 ParentQueue 에서 리프 큐 자동 생성은 기본적으로 활성화되지 않습니다.
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.management-policy 선택 파라미터: 이 부모 큐 아래에서 리프 큐와 그 용량을 동적으로 관리할 AutoCreatedQueueManagementPolicy의 구현을 결정하는 데 사용되는 클래스 이름. 기본값 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.queuemanagement.GuaranteedOrZeroCapacityOverTimePolicy. 사용자·그룹은 제한된 시간 동안 자동 생성 리프 큐에 애플리케이션을 제출하고 사용을 중단할 수 있습니다. 따라서 부모 큐 아래에 보장 용량보다 더 많은 리프 큐가 자동 생성될 수 있습니다. 현재 정책 구현은 부모 큐의 용량 가용성과 리프 큐 간 애플리케이션 제출 순서에 기반해 구성된 용량이나 0 용량을 최선 노력 으로 할당합니다.
  • CapacityScheduler로 legacy Auto-Created Leaf Queues 구성

리프 큐 자동 생성이 활성화된 부모 큐는 자동 생성 리프 큐의 자동 구성을 위한 템플릿 파라미터 구성을 지원합니다. 자동 생성 큐는 Absolute Resource 구성을 제외한 모든 리프 큐 구성 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.capacity 필수 파라미터: 자동 생성 리프 큐의 최소 보장 용량 지정.
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.maximum-capacity 선택 파라미터: 자동 생성 리프 큐의 최대 용량 지정. 이 값은 클러스터 최대값보다 작거나 같아야 합니다.
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.<leaf-queue-property> 선택 파라미터: maximum-capacity, user-limit-factor, maximum-am-resource-percent …처럼 자동 생성 리프 큐에 구성할 수 있는 다른 큐 파라미터 - Queue Properties 절 참고

예 1:

<property>
  <name>yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled</name>
  <value>true</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity</name>
   <value>5</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity</name>
   <value>100</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor</name>
   <value>3.0</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy</name>
   <value>fair</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.GPU.capacity</name>
   <value>50</value>
</property>
<property>
    <name>yarn.scheduler.capacity.root.parent1.accessible-node-labels</name>
    <value>GPU,SSD</value>
  </property>
<property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels</name>
    <value>GPU</value>
 </property>
<property>
   <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels.GPU.capacity</name>
   <value>5</value>
</property>

예 2:

<property>
  <name>yarn.scheduler.capacity.root.parent2.auto-create-child-queue.enabled</name>
  <value>true</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent2.leaf-queue-template.capacity</name>
   <value>[memory=1024,vcores=1]</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent2.leaf-queue-template.maximum-capacity</name>
   <value>[memory=10240,vcores=10]</value>
</property>
  • 자동 생성 큐 관리를 위한 Scheduling Edit Policy 구성

관리자는 yarn.resourcemanager.scheduler.monitor.policies 구성에서 현재 스케줄링 편집 정책 목록에 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.QueueManagementDynamicEditPolicy 스케줄링 편집 정책을 쉼표 구분 문자열로 추가해야 합니다. 자세한 내용은 위 Capacity Scheduler container preemption 절을 참고하세요.

속성 설명
yarn.resourcemanager.monitor.capacity.queue-management.monitoring-interval 이 QueueManagementDynamicEditPolicy 정책 호출 사이의 시간(밀리초). 기본값 1500
  • flexible 동적 리프 큐 자동 생성 및 관리를 위한 부모 큐 구성

Flexible Dynamic Queue Auto-Creation and Management 기능은 ParentQueue 가 부모 큐와 리프 큐를 모두 자동 생성할 수 있게 합니다. 이러한 부모 큐는 미리 구성된 다른 큐가 자동 생성된 큐와 공존할 수 있습니다. 자동 생성 큐는 capacity 로 가중치를 가지므로 부모 아래의 미리 구성된 큐도 같은 방식으로 구성되어야 합니다. CapacityScheduler는 큐 자동 생성 활성화를 위한 다음 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.enabled 필수 파라미터: 지정된 부모 큐에 대해 유연한 자동 큐 생성을 활성화해야 함을 나타냄. Boolean 값 필요. 기본값 false.
yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.max-queues 선택 파라미터: 부모 큐 아래 생성되는 동적 큐 수를 제한. Integer 값 필요. 기본값 1000.
  • CapacityScheduler로 flexible Auto-Created Leaf Queues 구성

유연한 자동 큐 생성을 활성화한 부모 큐는 템플릿 파라미터를 통해 동적으로 생성된 리프·부모 큐의 구성을 지원합니다. 자동 생성 큐는 Absolute Resource 구성을 제외한 모든 리프 큐 구성 파라미터를 지원합니다.

속성 설명
yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.template.<queue-property> 선택 파라미터: 자동 생성된 부모 와 리프 큐가 상속하는 큐 속성(capacity, maximum-capacity, user-limit-factor, maximum-am-resource-percent … - Queue Properties 절 참고)을 지정. 여기에 설정된 Dynamic Queue ACL은 동적 부모 큐에 대해 parent-template으로, 동적 리프 큐에 대해 leaf-template으로 재정의될 수 있습니다.
yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.leaf-template.<queue-property> 선택 파라미터: 자동 생성된 리프 큐가 상속하는 큐 속성을 지정.
yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.parent-template.<queue-property> 선택 파라미터: 자동 생성된 부모 큐가 상속하는 큐 속성을 지정.

다음 구성 스니펫 예시는 CapacityScheduler에 다음을 지시합니다: * root.parent에 대한 유연한 자동 큐 생성 활성화 * 와일드카드 큐 경로(root.parent.*) 때문에 모든 동적 큐를 root.parent 두 레벨 아래(예: root.parent.parent-auto.leaf-auto)에 최대 용량 80%로 생성 * 동적 부모 큐를 root.parent 직접 아래 가중치 2로 생성 * root.parent 직접 아래 생성되는 모든 리프 큐에 GPU 라벨 추가 * root.parent 직접 아래 모든 큐의 GPU 라벨 관련 가중치 설정

<property>
  <name>yarn.scheduler.capacity.root.parent.auto-queue-creation-v2.enabled</name>
  <value>true</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent.*.auto-queue-creation-v2.template.maximum-capacity</name>
   <value>80</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent.auto-queue-creation-v2.parent-template.capacity</name>
   <value>2w</value>
</property>
<property>
   <name>yarn.scheduler.capacity.root.parent.auto-queue-creation-v2.leaf-template.accessible-node-labels</name>
   <value>GPU</value>
</property>
 <property>
   <name>yarn.scheduler.capacity.root.parent.auto-queue-creation-v2.leaf-template.accessible-node-labels.GPU.capacity</name>
   <value>5w</value>
</property>

기타 속성 (Other Properties)

  • 자원 계산기 (Resource Calculator)
속성 설명
yarn.scheduler.capacity.resource-calculator 스케줄러에서 자원을 비교하는 데 사용할 ResourceCalculator 구현. 기본인 org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator는 Memory만 사용하며, DominantResourceCalculator는 지배 자원(Dominant-resource)을 사용해 Memory, CPU 등 다차원 자원을 비교합니다. Java ResourceCalculator 클래스 이름이 필요합니다.
  • 데이터 지역성 (Data Locality)

Capacity Scheduler는 작업 지역성 제약을 존중하기 위해 Delay Scheduling을 활용합니다. 지역성 제약에는 node-local, rack-local, off-switch의 3가지 레벨이 있습니다. 스케줄러는 지역성을 만족할 수 없을 때 놓친 기회 수를 세고, 이 횟수가 임계값에 도달할 때까지 기다렸다가 지역성 제약을 다음 레벨로 완화합니다. 임계값은 다음 속성으로 구성할 수 있습니다.

속성 설명
yarn.scheduler.capacity.node-locality-delay 이 횟수만큼 스케줄링 기회를 놓치면 CapacityScheduler가 rack-local 컨테이너를 스케줄링하려 시도. 일반적으로 클러스터의 노드 수로 설정해야 합니다. 기본은 대략 한 랙의 노드 수인 40. 양의 정수 값 필요.
yarn.scheduler.capacity.rack-locality-additional-delay node-locality-delay 횟수에 더해 추가로 이 횟수만큼 스케줄링 기회를 놓치면 CapacityScheduler가 off-switch 컨테이너를 스케줄링하려 시도. 기본값 -1로, 이 경우 off-switch 컨테이너 할당을 위한 놓친 기회 수는 L * C / N 공식으로 계산됩니다. 여기서 L은 자원 요청에 지정된 위치(노드 또는 랙) 수, C는 요청된 컨테이너 수, N은 클러스터 크기입니다.

참고, YARN이 파일시스템과 별도로 배포되면 지역성이 무의미하므로 이 기능을 비활성화해야 합니다. yarn.scheduler.capacity.node-locality-delay를 -1로 설정하면 되며, 이 경우 요청의 지역성 제약은 무시됩니다.

  • NodeManager 하트비트당 컨테이너 할당

CapacityScheduler는 각 NodeManager 하트비트에서 할당할 수 있는 컨테이너 수를 제어하는 다음 파라미터를 지원합니다. 이 파라미터는 yarn rmadmin -refreshQueues 로 새로고침할 수 있습니다.

속성 설명
yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled 하나의 NodeManager 하트비트에서 여러 컨테이너 할당을 허용할지. 기본 true.
yarn.scheduler.capacity.per-node-heartbeat.maximum-container-assignments multiple-assignments-enabled가 true면 하나의 NodeManager 하트비트에서 할당할 수 있는 최대 컨테이너 수. 기본값 100으로 하트비트당 최대 컨테이너 할당 수를 100으로 제한. 이 값을 -1로 설정하면 이 한계를 비활성화.
yarn.scheduler.capacity.per-node-heartbeat.maximum-offswitch-assignments multiple-assignments-enabled가 true면 하나의 NodeManager 하트비트에서 할당할 수 있는 최대 off-switch 컨테이너 수. 기본 1로 하나의 하트비트에서 off-switch 할당 하나만 허용.

CapacityScheduler 구성 검토

설치와 구성이 완료되면 YARN 클러스터를 시작한 후 웹 UI에서 이를 검토할 수 있습니다.

  • YARN 클러스터를 정상적인 방식으로 시작.

  • ResourceManager 웹 UI를 엽니다.

  • /scheduler 웹페이지에 개별 큐의 자원 사용량이 표시되어야 합니다.

큐 구성 변경 (Changing Queue Configuration)

큐/스케줄러 속성 변경 및 큐 추가/제거는 파일 또는 API의 두 가지 방식으로 할 수 있습니다. 이 동작은 yarn-site.xml의 yarn.scheduler.configuration.store.class로 변경할 수 있습니다. 가능한 값은 file(파일로 속성 수정 허용), memory(API로 속성 수정 허용하지만 재시작 시 변화를 유지하지 않음), leveldb(API로 속성 수정하고 leveldb 백킹 스토어에 저장), zk(API로 속성 수정하고 zookeeper 백킹 스토어에 저장)입니다. 기본값은 file 입니다.

파일로 큐 구성 변경

파일로 편집하려면 conf/capacity-scheduler.xml을 편집하고 yarn rmadmin -refreshQueues 를 실행해야 합니다.

$ vi $HADOOP_CONF_DIR/capacity-scheduler.xml
$ $HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues

파일로 큐 삭제

1단계: 큐 중지

리프 큐를 삭제하기 전에 리프 큐에 실행·대기 중인 앱이 없어야 하며 yarn.scheduler.capacity.<queue-path>.state를 변경해 STOPPED 상태여야 합니다. Queue Administration & Permissions 절 참고. 부모 큐를 삭제하기 전에 모든 자식 큐에 실행·대기 앱이 없고 STOPPED 상태여야 합니다. 부모 큐도 STOPPED여야 합니다.

2단계: 큐 삭제

파일에서 큐 구성을 제거하고 위에서 설명한 대로 refresh를 실행합니다.

주기적 구성 새로고침 활성화

큐 구성 주기적 새로고침을 활성화하면 conf/capacity-scheduler.xml 을 편집해 yarn rmadmin -refreshQueues 호출 없이 구성을 다시 로드·적용할 수 있습니다.

속성 설명
yarn.resourcemanager.scheduler.monitor.enable 주기적 새로고침에 모니터링 활성화가 필요. 기본값 false.
yarn.resourcemanager.scheduler.monitor.policies 클래스 목록을 담는 구성 속성. 클래스를 더 추가하면 더 많은 모니터 작업이 실행됩니다. 주기적 새로고침을 활성화하려면 정책 목록에 org.apache.hadoop.yarn.server.resourcemanager.capacity.QueueConfigurationAutoRefreshPolicy를 추가하세요. 이 속성의 기본값은 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy로, 선점 기능이 기본적으로 활성화되어 있음을 의미합니다. 이 클래스를 목록에서 제거하면 선점 기능이 비활성화됩니다.
yarn.resourcemanager.queue.auto.refresh.monitoring-interval 자동 새로고침 모니터링 간격 조정 가능. 값은 밀리초. 기본값 5000(5초).

API로 큐 구성 변경

API로 편집하면 스케줄러 구성의 백킹 스토어를 사용합니다. 이를 활성화하려면 yarn-site.xml에서 다음 파라미터를 구성할 수 있습니다.

참고: 이 기능은 알파 단계이며 변경될 수 있습니다.

속성 설명
yarn.scheduler.configuration.store.class 사용할 백킹 스토어 유형. 위에서 설명.
yarn.scheduler.configuration.mutation.acl-policy.class 어떤 사용자가 어떤 큐를 수정할 수 있는지 제한하는 ACL 정책을 구성할 수 있습니다. 기본값은 org.apache.hadoop.yarn.server.resourcemanager.scheduler.DefaultConfigurationMutationACLPolicy 로 YARN 관리자만 구성을 수정할 수 있게 합니다. 다른 값은 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.conf.QueueAdminConfigurationMutationACLPolicy 로 호출자가 큐의 관리자인 경우에만 큐 수정을 허용합니다.
yarn.scheduler.configuration.store.max-logs leveldb나 zookeeper를 쓰면 구성 변경이 백킹 스토어에 감사 기록됩니다. 이 구성은 저장할 최대 감사 로그 수를 제어하며, 초과하면 가장 오래된 로그를 버립니다. 기본값 1000.
yarn.scheduler.configuration.leveldb-store.path leveldb 사용 시 구성 스토어의 저장 경로. 기본값 ${hadoop.tmp.dir}/yarn/system/confstore.
yarn.scheduler.configuration.leveldb-store.compaction-interval-secs leveldb 사용 시 구성 스토어를 압축하는 간격(초). 기본값 86400, 즉 하루.
yarn.scheduler.configuration.zk-store.parent-path zookeeper 사용 시 구성 스토어 관련 정보의 zookeeper 루트 노드 경로. 기본값 /confstore.

참고: yarn.scheduler.configuration.store.class로 스케줄러 구성 변형(mutations)을 활성화하면 yarn rmadmin -refreshQueues 가 비활성화됩니다, 즉 파일로 구성을 업데이트할 수 없게 됩니다.

REST로 스케줄러 구성을 변경하는 예시는 YARN Resource Manager REST API를, 명령줄로 변경하는 예시는 YARN Commands Reference를 참고하세요.

컨테이너 업데이트 (Updating a Container, Experimental - API may change in the future)

Application Master가 Resource Manager로부터 Container를 받으면 RM에 컨테이너의 특정 속성을 업데이트하도록 요청할 수 있습니다.

현재 두 가지 유형의 컨테이너 업데이트만 지원됩니다:

  • 자원 업데이트 (Resource Update) : AM이 RM에 컨테이너의 자원 크기를 업데이트하도록 요청할 수 있음. 예: 컨테이너를 2GB, 2 vcore에서 4GB, 2 vcore로 변경.

  • 실행 유형 업데이트 (ExecutionType Update) : AM이 RM에 컨테이너의 ExecutionType을 업데이트하도록 요청할 수 있음. 예: 실행 유형을 GUARANTEED 에서 OPPORTUNISTIC 으로 또는 그 반대로 변경.

이것은 AM이 AllocateRequestProto에서 UpdateContainerRequestProto 유형 목록인 updated_containers 필드를 채워 가능합니다. AM은 같은 allocate 호출에서 여러 컨테이너 업데이트 요청을 할 수 있습니다.

UpdateContainerRequestProto의 스키마는 다음과 같습니다.

message UpdateContainerRequestProto {
  required int32 container_version = 1;
  required ContainerIdProto container_id = 2;
  required ContainerUpdateTypeProto update_type = 3;
  optional ResourceProto capability = 4;
  optional ExecutionTypeProto execution_type = 5;
}

ContainerUpdateTypeProto는 enum입니다:

enum ContainerUpdateTypeProto {
  INCREASE_RESOURCE = 0;
  DECREASE_RESOURCE = 1;
  PROMOTE_EXECUTION_TYPE = 2;
  DEMOTE_EXECUTION_TYPE = 3;
}

위 enum에 제약되어 스케줄러는 현재 한 업데이트 요청에서 컨테이너의 자원 업데이트 OR 실행 유형 중 하나만 변경을 지원합니다.

AM은 또한 RM에서 받은 최신 ContainerProto를 제공해야 합니다. 이것은 RM이 업데이트하려는 컨테이너입니다.

RM이 요청된 컨테이너를 업데이트할 수 있으면 업데이트된 컨테이너는 같은 allocate 호출의 반환 값인 AllocateResponseProto의 UpdatedContainerProto 유형 updated_containers 목록 필드나 후속 호출 중 하나에서 반환됩니다.

UpdatedContainerProto의 스키마는 다음과 같습니다.

message UpdatedContainerProto {
  required ContainerUpdateTypeProto update_type = 1;
  required ContainerProto container = 2;
}

컨테이너에 수행된 컨테이너 업데이트 유형과 업데이트된 토큰을 담은 업데이트된 Container 객체를 지정합니다.

컨테이너 토큰은 AM이 해당 NM에 컨테이너가 아직 시작되지 않았다면 시작하거나, 업데이트된 토큰으로 컨테이너를 업데이트하도록 요청하는 데 사용할 수 있습니다.

DECREASE_RESOURCE와 DEMOTE_EXECUTION_TYPE 컨테이너 업데이트는 자동입니다 - AM이 NM에 컨테이너 자원 감소를 명시적으로 요청할 필요가 없습니다. 다른 업데이트 유형은 AM이 NM에 컨테이너 업데이트를 명시적으로 요청해야 합니다.

yarn.resourcemanager.auto-update.containers 구성 파라미터가 true로 설정되면(기본 false) RM은 모든 컨테이너 업데이트가 자동이도록 보장합니다.

활동 (Activities)

스케줄링 활동은 일부 중요한 스케줄링 경로의 디버깅에 사용되는 활동 메시지로, 스케줄러 성능에 약간의 영향으로 기록되고 RESTful API로 노출될 수 있습니다. 현재 두 가지 유형의 활동이 지원됩니다: 스케줄러 활동 과 애플리케이션 활동.

스케줄러 활동 (Scheduler Activities)

스케줄러 활동은 스케줄링 주기의 유용한 스케줄링 정보를 포함하며, 스케줄러가 컨테이너를 어떻게 할당하는지 보여줍니다. 스케줄러 활동 REST API(http://rm-http-address:port/ws/v1/cluster/scheduler/activities)는 스케줄러 활동 기록을 활성화하고 캐시에서 가져오는 방법을 제공합니다. 성능 영향을 없애기 위해 스케줄러는 스케줄링 주기 끝에 활동 기록을 자동 비활성화하므로, RESTful API를 다시 조회해 최신 스케줄러 활동을 얻을 수 있습니다.

스케줄러 활동에 대한 쿼리 파라미터, 출력 구조, 예시는 YARN Resource Manager REST API를 참고하세요.

애플리케이션 활동 (Application Activities)

애플리케이션 활동은 지정된 애플리케이션의 유용한 스케줄링 정보를 포함하며, 요구사항이 어떻게 충족되거나 건너뛰어졌는지 보여줍니다. 애플리케이션 활동 REST API(http://rm-http-address:port/ws/v1/cluster/scheduler/app-activities/{appid})는 지정된 애플리케이션의 애플리케이션 활동 기록을 몇 초 안에 활성화하거나 캐시에서 과거 애플리케이션 활동을 가져오는 방법을 제공하며, "refresh"와 "get"을 포함한 사용 가능한 동작을 "actions" 파라미터로 지정할 수 있습니다.

  • "actions=refresh" 파라미터로 조회하면 지정된 애플리케이션의 애플리케이션 활동 기록을 일정 시간(기본 3초) 동안 활성화하고 {"appActivities":{"applicationId":"application_1562308866454_0001","diagnostic":"Successfully received action: refresh","timestamp":1562308869253,"dateTime":"Fri Jul 05 14:41:09 CST 2019"}} 같은 간단한 응답을 얻습니다.

  • "actions=get" 파라미터로 조회하면 기록을 활성화하지 않고 캐시에서 과거 애플리케이션 활동을 직접 가져옵니다.

  • actions 파라미터가 지정되지 않으면 기본 동작은 "refresh,get"으로, "refresh"와 "get"이 모두 수행됩니다.

애플리케이션 활동에 대한 쿼리 파라미터, 출력 구조, 예시는 YARN Resource Manager REST API를 참고하세요.

구성 (Configuration)

CapacityScheduler는 스케줄러/애플리케이션 활동의 캐시 크기와 만료를 제어하는 다음 파라미터를 지원합니다.

속성 설명
yarn.resourcemanager.activities-manager.cleanup-interval-ms 활동의 정리 간격(밀리초). 기본 5000.
yarn.resourcemanager.activities-manager.scheduler-activities.ttl-ms 스케줄러 활동의 수명(밀리초). 기본 600000.
yarn.resourcemanager.activities-manager.app-activities.ttl-ms 애플리케이션 활동의 수명(밀리초). 기본 600000.
yarn.resourcemanager.activities-manager.app-activities.max-queue-length 앱 활동의 최대 큐 길이. 기본 100.

웹 UI (Web UI)

활동 정보는 RM Web UI의 애플리케이션 시도 페이지에서 볼 수 있으며, 보류 중인 요청이 집계·표시됩니다. 새로고침 버튼을 클릭하면 최신 활동 정보를 얻을 수 있습니다.

더 알아보기 (Learn more)