Hadoop: Fair Scheduler

Hadoop: Fair Scheduler

대규모 클러스터에서 YARN 애플리케이션이 자원을 공정하게 공유할 수 있게 하는 플러그형 스케줄러인 FairScheduler를 설명하는 문서예요. 계층적 큐, 자동 큐 배치, 설치, 구성(allocation 파일 형식 포함), 관리, 예약 시스템을 다룹니다.

출처: 문서

본문

목적 (Purpose)

이 문서는 Hadoop용 플러그형 스케줄러인 FairScheduler를 설명합니다. 이 스케줄러는 대규모 클러스터에서 YARN 애플리케이션이 자원을 공정하게 공유할 수 있게 해 줍니다.

소개 (Introduction)

공정 스케줄링은 모든 앱이 시간이 지나면서 평균적으로 자원을 동등하게 공유하도록 애플리케이션에 자원을 할당하는 방법입니다. Hadoop NextGen은 여러 자원 유형을 스케줄링할 수 있습니다. 기본적으로 Fair Scheduler는 스케줄링 공정성 결정을 메모리에만 기반으로 합니다. Ghodsi 등이 개발한 Dominant Resource Fairness 개념을 사용해 메모리와 CPU 모두로 스케줄링하도록 구성할 수 있습니다. 단일 앱이 실행 중일 때 그 앱이 전체 클러스터를 사용합니다. 다른 앱이 제출되면 해제된 자원이 새 앱에 할당되어, 각 앱이 결국 거의 같은 양의 자원을 받습니다. 앱의 큐를 형성하는 기본 Hadoop 스케줄러와 달리, 이 방식은 장기 실행 앱을 굶기지 않으면서 단기 앱이 합리적인 시간 안에 끝날 수 있게 합니다. 여러 사용자 간에 클러스터를 공유하는 합리적인 방법이기도 합니다. 마지막으로 공정 공유는 앱 우선순위와도 함께 작동합니다. 우선순위는 각 앱이 받아야 할 총 자원의 비율을 결정하는 가중치로 사용됩니다.

스케줄러는 앱을 더 나아가 "큐"로 구성하고 이런 큐 사이에서 자원을 공정하게 공유합니다. 기본적으로 모든 사용자는 "default"라는 단일 큐를 공유합니다. 앱이 컨테이너 자원 요청에서 특정 큐를 나열하면 요청이 그 큐로 제출됩니다. 또한 구성을 통해 요청에 포함된 사용자 이름에 기반해 큐를 할당할 수도 있습니다. 각 큐 안에서 스케줄링 정책이 실행 중인 앱들 사이에 자원을 공유하는 데 사용됩니다. 기본은 메모리 기반 공정 공유이지만, FIFO와 Dominant Resource Fairness를 사용한 다중 자원도 구성할 수 있어요. 큐는 자원을 나누기 위해 계층으로 배열될 수 있고, 특정 비율로 클러스터를 공유하도록 가중치로 구성될 수 있습니다.

공정 공유를 제공하는 것 외에도 Fair Scheduler는 큐에 보장된 최소 공유를 할당할 수 있게 합니다. 이는 특정 사용자, 그룹, 프로덕션 애플리케이션이 항상 충분한 자원을 받도록 보장하는 데 유용해요. 큐에 앱이 있으면 최소 공유를 받지만, 큐가 보장된 공유를 다 사용할 필요가 없으면 초과분은 다른 실행 앱들 사이에 나뉩니다. 이는 스케줄러가 큐에 용량을 보장하면서도 그 큐에 앱이 없을 때 자원을 효율적으로 활용하게 합니다.

Fair Scheduler는 기본적으로 모든 앱을 실행하게 하지만, 구성 파일로 사용자별·큐별 실행 앱 수를 제한할 수도 있습니다. 이는 사용자가 한 번에 수백 개의 앱을 제출해야 할 때, 또는 너무 많은 앱을 동시에 실행하면 너무 많은 중간 데이터가 생기거나 너무 많은 컨텍스트 스위칭이 발생할 때 성능을 개선하는 데 유용합니다. 앱 제한은 이후 제출된 앱을 실패시키지 않고, 스케줄러 큐에서 사용자의 이전 앱 중 일부가 끝날 때까지 기다리게만 합니다.

계층적 큐와 플러그형 정책 (Hierarchical queues with pluggable policies)

공정 스케줄러는 계층적 큐를 지원합니다. 모든 큐는 "root"라는 큐에서 내려옵니다. 사용 가능한 자원은 일반적인 공정 스케줄링 방식으로 루트 큐의 자식들 사이에 분산됩니다. 그런 다음 자식들은 자기에게 할당된 자원을 같은 방식으로 자식들에게 분산합니다. 애플리케이션은 잎(leaf) 큐에서만 스케줄링될 수 있습니다. 큐는 공정 스케줄러 allocation 파일에서 부모의 하위 요소로 배치해 다른 큐의 자식으로 지정할 수 있어요.

큐의 이름은 부모의 이름으로 시작하며 구분자는 마침표입니다. 루트 큐 아래의 "queue1"이라는 큐는 "root.queue1"로, "parent1" 아래의 "queue2"는 "root.parent1.queue2"로 참조됩니다. 큐를 참조할 때 이름의 root 부분은 선택 사항이므로, queue1은 그냥 "queue1"로, queue2는 "parent1.queue2"로 참조할 수 있습니다.

추가로 공정 스케줄러는 각 큐에 다른 사용자 정의 정책을 설정해 사용자가 원하는 어떤 방식으로든 큐의 자원을 공유하게 합니다. 사용자 정의 정책은 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy를 확장해 만들 수 있습니다. FifoPolicy, FairSharePolicy(기본), DominantResourceFairnessPolicy가 내장되어 있고 바로 사용할 수 있습니다.

원래(MR1) Fair Scheduler에 있던 추가 기능 중 일부는 아직 지원되지 않습니다. 그중에는 특정 앱에 대한 우선순위 "부스트(boosting)"를 제어하는 사용자 정의 정책 사용이 있습니다.

애플리케이션을 큐에 자동 배치 (Automatically placing applications in queues)

Fair Scheduler는 관리자가 제출된 애플리케이션을 적절한 큐에 자동으로 배치하는 정책을 구성할 수 있게 합니다. 배치는 제출자의 사용자·그룹과 애플리케이션이 전달한 요청 큐에 의존할 수 있습니다. 정책은 들어오는 애플리케이션을 분류하기 위해 순차 적용되는 규칙 집합으로 구성됩니다. 각 규칙은 앱을 큐에 배치하거나, 거부하거나, 다음 규칙으로 계속합니다. 이 정책 구성 방법은 아래 allocation 파일 형식을 참고하세요.

설치 (Installation)

Fair Scheduler를 사용하려면 먼저 yarn-site.xml에서 적절한 스케줄러 클래스를 지정합니다.

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

구성 (Configuration)

Fair Scheduler 사용자 정의는 보통 두 파일을 수정하는 것을 포함합니다. 첫째, 스케줄러 전체 옵션을 기존 구성 디렉터리의 yarn-site.xml 파일에 구성 속성을 추가해 설정할 수 있습니다. 둘째, 대부분의 경우 사용자는 어떤 큐가 존재하고 그들의 각 가중치와 용량을 나열하는 allocation 파일을 만들고 싶어할 것입니다. allocation 파일은 10초마다 다시 로드되어 즉석에서 변경할 수 있습니다.

yarn-site.xml에 배치할 수 있는 속성

속성 설명
yarn.scheduler.fair.allocation.file allocation 파일 경로. allocation 파일은 큐와 그 속성, 특정 정책 기본값을 설명하는 XML 매니페스트. 파일은 다음 절에서 설명하는 XML 형식이어야 함. 상대 경로를 주면 클래스패스(보통 Hadoop conf 디렉터리 포함)에서 파일을 찾음. 기본 fair-scheduler.xml.
yarn.scheduler.fair.user-as-default-queue 큐 이름이 지정되지 않았을 때 할당과 연관된 사용자 이름을 기본 큐 이름으로 사용할지 여부. "false" 또는 미설정이면 모든 작업이 "default"라는 공유 기본 큐를 가짐. 기본 true. allocations 파일에 큐 배치 정책이 주어지면 이 속성은 무시됨. 참고: false로 설정하면 allocations 파일에 "default" 큐를 선언해야 함.
yarn.scheduler.fair.preemption 선점(preemption) 사용 여부. 기본 false.
yarn.scheduler.fair.preemption.cluster-utilization-threshold 선점이 발동하는 활용 임계값. 활용도는 모든 자원 중 사용/용량 비율의 최대값으로 계산. 기본 0.8f.
yarn.scheduler.fair.sizebasedweight 크기와 관계없이 모든 앱에 동등한 공유를 제공하는 대신 크기에 기반해 개별 앱에 공유를 할당할지 여부. true로 설정하면 앱은 앱의 총 요청 메모리에 1을 더한 값의 자연로그를 자연로그 2로 나눈 값으로 가중치가 주어짐. 기본 false.
yarn.scheduler.fair.assignmultiple 한 하트비트에서 여러 컨테이너 할당을 허용할지 여부. 기본 false.
yarn.scheduler.fair.dynamic.max.assign assignmultiple이 true일 때 한 하트비트에서 할당할 수 있는 자원 양을 동적으로 결정할지 여부. 켜면 한 하트비트에서 노드의 미할당 자원의 약 절반이 컨테이너에 할당됨. 기본 true.
yarn.scheduler.fair.max.assign assignmultiple이 true이고 dynamic.max.assign이 false일 때, 한 하트비트에서 할당할 수 있는 최대 컨테이너 수. 기본 -1(제한 없음).
yarn.scheduler.fair.locality.threshold.node 특정 노드에 컨테이너를 요청하는 애플리케이션에 대해, 마지막 컨테이너 할당 이후 다른 노드에 배치를 받아들이기 전에 기다리는 스케줄링 기회 수. 0과 1 사이의 float로 표현되며, 클러스터 크기의 일부로서 놓치는 스케줄링 기회 수. 기본 -1.0은 어떤 스케줄링 기회도 놓치지 않는다는 뜻.
yarn.scheduler.fair.locality.threshold.rack 특정 랙에 컨테이너를 요청하는 애플리케이션에 대해, 마지막 컨테이너 할당 이후 다른 랙에 배치를 받아들이기 전에 기다리는 스케줄링 기회 수. 0과 1 사이의 float로 표현. 기본 -1.0은 기회를 놓치지 않음.
yarn.scheduler.fair.allow-undeclared-pools true이면 애플리케이션 제출 시 새 큐를 만들 수 있음. 제출자가 애플리케이션의 큐로 지정했거나 user-as-default-queue 속성으로 배치됐기 때문. false이면 allocation 파일에 지정되지 않은 큐에 앱이 배치될 때마다 대신 "default" 큐에 배치됨. 기본 true. 참고: false로 설정하면 allocations 파일에 "default" 큐도 선언해야 함. allocations 파일에 큐 배치 정책이 주어지면 이 속성은 무시됨.
yarn.scheduler.fair.update-interval-ms 스케줄러를 잠그고 공정 공유를 재계산하고 수요를 재계산하며 선점 대상이 있는지 확인하는 간격. 기본 500 ms.
yarn.resource-types.memory-mb.increment-allocation fairscheduler는 이 값의 증분으로 메모리를 부여. memory-mb.increment-allocation의 배수가 아닌 리소스 요청으로 작업을 제출하면 가장 가까운 증분으로 올림됨. 기본 1024 MB.
yarn.resource-types.vcores.increment-allocation fairscheduler는 이 값의 증분으로 vcores를 부여. vcores.increment-allocation의 배수가 아닌 리소스 요청으로 작업을 제출하면 가장 가까운 증분으로 올림됨. 기본 1.
yarn.resource-types.<resource>.increment-allocation fairscheduler는 이 값의 증분으로 <resource>를 부여. <resource>.increment-allocation의 배수가 아닌 리소스 요청으로 작업을 제출하면 가장 가까운 증분으로 올림됨. 리소스에 대해 이 속성을 지정하지 않으면 증분 올림이 적용되지 않음. 단위를 지정하지 않으면 그 리소스의 기본 단위로 가정.
yarn.scheduler.increment-allocation-mb 메모리 할당 증분. 더 이상 선호되지 않음. yarn.resource-types.memory-mb.increment-allocation 사용. 기본 1024 MB.
yarn.scheduler.increment-allocation-vcores CPU vcores 할당 증분. 더 이상 선호되지 않음. yarn.resource-types.vcores.increment-allocation 사용. 기본 1.

allocation 파일 형식

allocation 파일은 XML 형식이어야 합니다. 형식은 다섯 가지 유형의 요소를 담습니다.

  • Queue 요소: 큐를 나타냄. Queue 요소는 선택적 'type' 속성을 가질 수 있으며, 'parent'로 설정하면 부모 큐가 됩니다. 이는 잎 큐를 구성하지 않고 부모 큐를 만들 때 유용합니다. 각 큐 요소는 다음 속성을 포함할 수 있습니다.
    • minResources: 큐가 가질 자격이 있는 최소 자원. 단일 자원 공정성 정책에서는 메모리만 사용되고 다른 자원은 무시됩니다. 큐의 최소 공유가 충족되지 않으면 같은 부모 아래 다른 큐보다 먼저 사용 가능한 자원을 받게 됩니다. 단일 자원 공정성 정책에서 메모리 사용이 최소 메모리 공유보다 낮으면 큐는 불충족으로 간주됩니다. Dominant resource fairness에서 지배적 자원의 클러스터 용량 대비 사용이 그 자원의 최소 공유보다 낮으면 큐는 불충족으로 간주됩니다. 이 상황에서 여러 큐가 불충족이면 관련 자원 사용과 최소값의 비율이 가장 작은 큐로 자원이 갑니다. 최소값 아래인 큐가 최소값까지 즉시 오르지 않을 수 있다는 점에 유의하세요. 이미 실행 중인 작업이 그 자원을 사용 중일 수 있기 때문입니다.
    • maxResources: 큐가 할당받을 수 있는 최대 자원. 큐의 집계 사용을 이 한도 위로 올리는 컨테이너는 할당되지 않습니다. 이 한도는 재귀적으로 적용되며, 그 할당이 큐나 부모(들)를 최대 자원 위로 올리면 큐에 컨테이너가 할당되지 않습니다.
    • maxContainerAllocation: 큐가 단일 컨테이너에 할당할 수 있는 최대 자원. 설정하지 않으면 값이 부모 큐에서 상속됩니다. 기본값은 yarn.scheduler.maximum-allocation-mb와 yarn.scheduler.maximum-allocation-vcores. maxResources보다 높을 수 없습니다. 이 속성은 root 큐에 유효하지 않습니다.
    • maxChildResources: 임시(ad hoc) 자식 큐가 할당받을 수 있는 최대 자원. 자식 큐 한도는 재귀적으로 적용되며, 그 할당이 자식 큐나 부모(들)를 최대 자원 위로 올리면 컨테이너가 할당되지 않습니다.
      • minResources, maxResources, maxContainerAllocation, maxChildResources 속성에 대해 다음 형식 중 하나로 파라미터를 줄 수 있습니다.
        • Old format: "X mb, Y vcores", "X% cpu, Y% memory", "X%". 단일 백분율이 주어지지 않으면 메모리와 cpu 모두 구성이 필수이고, 다른 자원 유형은 무시되고 0으로 설정됩니다.
        • New format (권장): "vcores=X, memory-mb=Y" 또는 "vcores=X%, memory-mb=Y%". 이 형식에서 백분율이나 단위 없는 정수 자원 값을 줄 수 있습니다. 후자의 경우 단위는 그 자원에 구성된 기본 단위에서 추론됩니다. 이 형식은 메모리와 CPU 외 자원이 지정될 때 필요합니다. 지정되지 않은 자원은 minResources의 경우 0으로, maxResources, maxContainerAllocation, maxChildResources의 경우 그 자원의 최대치로 설정됩니다.
    • maxRunningApps: 큐에서 한 번에 실행할 앱 수를 제한합니다.
    • maxAMShare: application master 실행에 사용할 수 있는 큐의 공정 공유 비율을 제한합니다. 이 속성은 잎 큐에서만 사용할 수 있습니다. 예를 들어 1.0f로 설정하면 잎 큐의 AM이 메모리·CPU 공정 공유의 최대 100%를 차지할 수 있습니다. -1.0f 값은 이 기능을 비활성화하고 amShare를 검사하지 않습니다. 기본값 0.5f.
    • weight: 다른 큐와 비균등하게 클러스터를 공유합니다. 가중치는 기본 1이며, 가중치 2의 큐는 기본 가중치 큐보다 약 2배 많은 자원을 받아야 합니다. 가중치 0의 큐는 모든 비영 가중치 큐가 자원을 받은 뒤에 자원을 받아야 합니다.
    • schedulingPolicy: 어떤 큐의 스케줄링 정책을 설정합니다. 허용 값은 "fifo"/"fair"/"drf" 또는 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy를 확장하는 어떤 클래스든. 기본 "fair". "fifo"이면 제출 시간이 더 이른 앱이 컨테이너를 우선 받지만, 이후 제출된 앱도 이전 앱의 요청을 충족한 뒤 클러스터에 여유 공간이 있으면 동시에 실행될 수 있습니다.
    • aclSubmitApps: 큐에 앱을 제출할 수 있는 사용자·그룹 목록. 이 목록의 형식과 큐 ACL 작동 방식은 아래 ACL 절을 참고하세요.
    • aclAdministerApps: 큐를 관리할 수 있는 사용자·그룹 목록. 현재 유일한 관리 동작은 애플리케이션 종료입니다. 이 목록의 형식과 큐 ACL 작동 방식은 아래 ACL 절을 참고하세요.
    • minSharePreemptionTimeout: 큐가 다른 큐에서 자원을 가져오기 위해 컨테이너를 선점하려 시도하기 전에 최소 공유 아래에 머무는 초 수. 설정하지 않으면 큐는 부모 큐에서 값을 상속. 기본값 Long.MAX_VALUE로, 의미 있는 값을 설정할 때까지 컨테이너를 선점하지 않습니다.
    • fairSharePreemptionTimeout: 큐가 다른 큐에서 자원을 가져오기 위해 컨테이너를 선점하려 시도하기 전에 공정 공유 임계값 아래에 머무는 초 수. 설정하지 않으면 부모 큐에서 값 상속. 기본 Long.MAX_VALUE.
    • fairSharePreemptionThreshold: 큐의 공정 공유 선점 임계값. 큐가 fairSharePreemptionThreshold*fairShare 자원을 받지 않고 fairSharePreemptionTimeout을 기다리면, 다른 큐에서 자원을 가져오기 위해 컨테이너를 선점할 수 있습니다. 설정하지 않으면 부모 큐에서 값 상속. 기본 0.5f.
    • allowPreemptionFrom: 스케줄러가 큐에서 자원을 선점하는 것이 허용되는지 결정. 기본 true. 큐의 이 속성이 false이면 모든 자식 큐에 재귀적으로 적용됩니다.
    • reservation: ReservationSystem에 큐의 자원이 사용자가 예약할 수 있음을 나타냅니다. 잎 큐에만 적용됩니다. 이 속성이 구성되지 않으면 잎 큐는 예약 가능하지 않습니다.
  • User 요소: 개별 사용자의 동작을 제어하는 설정을 나타냄. maxRunningApps(특정 사용자의 실행 앱 수 제한) 단일 속성을 담을 수 있습니다.
  • userMaxAppsDefault 요소: 제한이 달리 지정되지 않은 사용자들의 기본 실행 앱 한도를 설정.
  • defaultFairSharePreemptionTimeout 요소: root 큐의 공정 공유 선점 타임아웃 설정; root 큐의 fairSharePreemptionTimeout 요소가 덮어씀. 기본 Long.MAX_VALUE.
  • defaultMinSharePreemptionTimeout 요소: root 큐의 최소 공유 선점 타임아웃 설정; root 큐의 minSharePreemptionTimeout이 덮어씀. 기본 Long.MAX_VALUE.
  • defaultFairSharePreemptionThreshold 요소: root 큐의 공정 공유 선점 임계값 설정; root 큐의 fairSharePreemptionThreshold가 덮어씀. 기본 0.5f.
  • queueMaxAppsDefault 요소: 큐의 기본 실행 앱 한도 설정; 각 큐의 maxRunningApps 요소가 덮어씀.
  • queueMaxResourcesDefault 요소: 큐의 기본 최대 자원 한도 설정; 각 큐의 maxResources 요소가 덮어씀.
  • queueMaxAMShareDefault 요소: 큐의 기본 AM 자원 한도 설정; 각 큐의 maxAMShare가 덮어씀.
  • defaultQueueSchedulingPolicy 요소: 큐의 기본 스케줄링 정책 설정; 지정되면 각 큐의 schedulingPolicy 요소가 덮어씀. 기본 "fair".
  • reservation-agent 요소: 사용자의 예약 요청을 Plan에 배치하려 시도하는 ReservationAgent 구현의 클래스 이름 설정. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.
  • reservation-policy 요소: 새 예약이 어떤 불변 조건도 위반하지 않는지 검증하는 SharingPolicy 구현의 클래스 이름 설정. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.
  • reservation-planner 요소: Plan 용량이(예약된 유지보수나 노드 실패로 인해) 사용자가 예약한 자원 아래로 떨어지면 호출되는 Planner 구현의 클래스 이름 설정. 기본값 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner로, Plan을 스캔해 예약 자원이 Plan 용량 안에 올 때까지 수락 역순(LIFO)으로 예약을 탐욕적으로 제거합니다.
  • queuePlacementPolicy 요소: 들어오는 앱을 큐에 배치하는 방법을 스케줄러에 알려주는 규칙 요소 목록을 담음. 규칙은 나열된 순서로 적용됩니다. 규칙은 인자를 받을 수 있습니다. 모든 규칙은 "create" 인자를 받으며, 규칙이 새 큐를 만들 수 있는지 나타냅니다. "Create" 기본값은 true이고, false로 설정되고 규칙이 allocations 파일에 구성되지 않은 큐에 앱을 배치한다면 다음 규칙으로 계속합니다. 마지막 규칙은 절대 continue를 내보낼 수 없는 규칙이어야 합니다. 유효한 규칙은:
    • specified: 앱이 요청한 큐에 배치. 앱이 큐를 요청하지 않았으면(즉 "default" 지정) 계속. 앱이 마침표로 시작·끝나는 큐 이름(예: ".q1" 또는 "q1.")을 요청하면 거부됨.
    • user: 앱이 제출한 사용자의 이름의 큐에 배치. 사용자 이름의 마침표는 "dot"로 교체됩니다. 즉 사용자 "first.last"의 큐 이름은 "first_dot_last".
    • primaryGroup: 앱이 제출한 사용자의 기본 그룹 이름의 큐에 배치. 그룹 이름의 마침표는 "dot"로 교체. 즉 그룹 "one.two"의 큐 이름은 "one_dot_two".
    • secondaryGroupExistingQueue: 앱이 제출한 사용자의 보조 그룹 이름과 일치하는 큐에 배치. 구성된 큐와 일치하는 첫 번째 보조 그룹이 선택. 그룹 이름의 마침표는 "dot"로 교체. 즉 보조 그룹 중 하나로 "one.two"를 가진 사용자는 그런 큐가 존재하면 "one_dot_two" 큐에 배치.
    • nestedUserQueue: 중첩 규칙이 제안한 큐 아래의 사용자 이름 큐에 앱을 배치. 'user' 규칙과 비슷하지만, 'nestedUserQueue' 규칙에서는 사용자 큐가 어떤 부모 큐 아래에서도 만들어질 수 있는 반면 'user' 규칙은 root 큐 아래에서만 사용자 큐를 만든다는 차이가 있습니다. nestedUserQueue 규칙은 중첩 규칙이 부모 큐를 반환할 때만 적용됩니다. 큐의 'type' 속성을 'parent'로 설정하거나 그 큐 아래에 잎을 하나 이상 구성해 부모가 되게 함으로써 부모 큐를 구성할 수 있습니다.
    • default: 'queue' 속성이 지정된 기본 규칙의 큐에 앱을 배치. 'queue' 속성이 지정되지 않으면 'root.default' 큐에 배치.
    • reject: 앱이 거부됨.

예시 allocation 파일:

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
    <queue name="sample_reservable_queue">
      <reservation></reservation>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>
  <queueMaxResourcesDefault>40000 mb,0vcores</queueMaxResourcesDefault>

  <!-- Queue 'secondary_group_queue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  <maxChildResources>4096 mb,4vcores</maxChildResources>
  </queue>

  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>

  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

원래 FairScheduler와의 하위 호환을 위해 "queue" 요소 대신 "pool" 요소로 이름 지을 수 있습니다.

큐 접근 제어 목록 (Queue Access Control Lists)

큐 ACL(접근 제어 목록)은 관리자가 특정 큐에서 누가 행동을 취할 수 있는지 제어하게 합니다. 큐별로 설정할 수 있는 aclSubmitApps와 aclAdministerApps 속성으로 구성됩니다. 현재 지원되는 유일한 관리 동작은 애플리케이션 종료입니다. 관리자는 그것에 애플리케이션을 제출할 수도 있습니다. 이 속성들은 "user1,user2 group1,group2" 또는 " group1,group2" 형식의 값을 취합니다. 사용자/그룹이 큐 ACL의 멤버이거나 그 큐의 어떤 조상의 큐 ACL의 멤버이면 큐에 대한 행동이 허용됩니다. 그래서 queue2가 queue1 안에 있고 user1이 queue1의 ACL, user2가 queue2의 ACL에 있으면 두 사용자 모두 queue2에 제출할 수 있습니다.

참고: 구분자는 공백 문자입니다. ACL 그룹만 지정하려면 값의 시작을 공백 문자로 하세요.

root 큐의 ACL은 기본적으로 ""인데, ACL이 전달되므로 모든 사람이 모든 큐에 제출·종료할 수 있다는 뜻입니다. 접근을 제한하려면 root 큐의 ACL을 "" 이외의 것으로 바꾸세요.

예약 접근 제어 목록 (Reservation Access Control Lists)

예약 ACL(접근 제어 목록)은 관리자가 특정 큐에서 누가 예약 행동을 취할 수 있는지 제어하게 합니다. 큐별로 설정할 수 있는 aclAdministerReservations, aclListReservations, aclSubmitReservations 속성으로 구성됩니다. 현재 지원되는 관리 동작은 예약 갱신·삭제입니다. 관리자는 큐의 모든 예약을 제출·나열할 수도 있습니다. 이 속성들은 "user1,user2 group1,group2" 또는 " group1,group2" 형식의 값을 취합니다. 사용자/그룹이 예약 ACL의 멤버이면 큐에 대한 행동이 허용됩니다. 어떤 사용자든 자기 자신의 예약을 갱신·삭제·나열할 수 있다는 점에 유의하세요. 예약 ACL이 활성화됐지만 정의되지 않으면 모든 사람이 접근할 수 있습니다.

ReservationSystem 구성

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

속성 설명
yarn.resourcemanager.reservation-system.enable 필수 파라미터: ResourceManager에서 ReservationSystem을 활성화. 불리언 값 기대. 기본 false, 즉 ReservationSystem이 기본으로 활성화되지 않음.
yarn.resourcemanager.reservation-system.class 선택 파라미터: ReservationSystem의 클래스 이름. 기본값은 구성된 Scheduler에 따라 선택되는데, FairScheduler가 구성되면 FairReservationSystem.
yarn.resourcemanager.reservation-system.plan.follower 선택 파라미터: 타이머에서 실행되고 FairScheduler와 Plan을 서로 동기화하는 PlanFollower의 클래스 이름. 기본값은 구성된 Scheduler에 따라 선택되는데, FairScheduler가 구성되면 FairSchedulerPlanFollower.
yarn.resourcemanager.reservation-system.planfollower.time-step 선택 파라미터: PlanFollower 타이머의 주기(밀리초). Long 값 기대. 기본 1000.

ReservationSystem은 Fair Scheduler 큐 계층과 통합되며 잎 큐에 대해서만 구성할 수 있습니다. 자세한 지침은 Allocation file format 절에 있습니다.

관리 (Administration)

공정 스케줄러는 몇 가지 메커니즘을 통해 런타임 관리를 지원합니다.

런타임에 구성 수정

allocation 파일 편집으로 최소 공유, 한도, 가중치, 선점 타임아웃, 큐 스케줄링 정책을 런타임에 수정할 수 있습니다. 스케줄러는 파일이 수정된 것을 본 뒤 10-15초 후에 다시 로드합니다.

웹 UI를 통한 모니터링

현재 애플리케이션, 큐, 공정 공유는 http://*ResourceManager URL*/cluster/scheduler에서 ResourceManager의 웹 인터페이스로 검사할 수 있습니다.

웹 인터페이스에서 각 큐에 대해 볼 수 있는 필드는 다음과 같습니다.

  • Used Resources — 큐 안 컨테이너에 할당된 자원 합계.
  • Num Active Applications — 큐에서 최소 하나의 컨테이너를 받은 애플리케이션 수.
  • Num Pending Applications — 큐에서 아직 어떤 컨테이너도 받지 못한 애플리케이션 수.
  • Min Resources — 큐에 보장된 구성된 최소 자원.
  • Max Resources — 큐에 허용된 구성된 최대 자원.
  • Instantaneous Fair Share — 큐의 순간 공정 자원 공유. 이 공유는 활성 큐(실행 중 애플리케이션이 있는 큐)만 고려하며 스케줄링 결정에 사용됩니다. 다른 큐가 쓰지 않을 때 큐는 공유를 넘어 자원을 할당받을 수 있습니다. 순간 공정 공유 이하에 있는 큐는 컨테이너가 절대 선점되지 않습니다.
  • Steady Fair Share — 큐의 안정 공정 자원 공유. 이 공유는 활성 여부와 관계없이 모든 큐를 고려합니다. 덜 자주 계산되고 구성·용량이 바뀔 때만 변합니다. 사용자가 기대할 수 있는 자원에 대한 가시성을 제공하기 위한 것이며, 그래서 Web UI에 표시됩니다.

큐 사이 애플리케이션 이동

Fair Scheduler는 실행 중 애플리케이션을 다른 큐로 이동하는 것을 지원합니다. 이는 중요한 애플리케이션을 더 높은 우선순위 큐로 이동하거나, 덜 중요한 애플리케이션을 더 낮은 우선순위 큐로 이동하는 데 유용할 수 있습니다. 앱은 yarn application -movetoqueue appID -queue targetQueueName을 실행해 이동할 수 있습니다.

애플리케이션이 큐로 이동되면 그 기존 할당은 공정성 결정을 위해 옛 큐 대신 새 큐의 할당으로 계산됩니다. 앱의 자원을 그 큐에 추가하는 것이 그 큐의 maxRunningApps나 maxResources 제약을 위반하면 애플리케이션 이동 시도는 실패합니다.

Fair Scheduler 상태 덤프

Fair Scheduler는 주기적으로 자신의 상태를 덤프할 수 있습니다. 기본적으로 비활성화되어 있습니다. 관리자는 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.statedump 로깅 레벨을 DEBUG로 설정해 활성화할 수 있습니다.

Fair Scheduler 로그는 기본적으로 Resource Manager 로그 파일로 갑니다. Fair Scheduler 상태 덤프는 많은 양의 로그 데이터를 생성할 수 있습니다. log4j.properties에서 "Fair scheduler state dump" 섹션의 주석을 해제해 상태를 별도 파일로 덤프하세요.

더 알아보기 (Learn more)