Hadoop: Fair Scheduler

В главе описывается FairScheduler – подключаемый планировщик для Hadoop, позволяющий YARN-приложениям справедливо распределять ресурсы в больших кластерах.

Справедливое планирование – это метод распределения ресурсов между приложениями таким образом, чтобы все приложения в среднем получали равную долю ресурсов с течением времени. Hadoop NextGen способен планировать несколько типов ресурсов. По умолчанию в FairScheduler планирование решений основывается только на памяти. Но он также может быть сконфигурирован для планирования, основанного на памяти вместе с процессором, используя понятие Dominant Resource Fairness, разработанное Ghodsi et al.

Когда запущено одно приложение, оно использует весь кластер. А при добавлении новых приложений, им назначаются освобождающиеся ресурсы, таким образом каждое приложение в конечном итоге получает примерно одинаковый объем ресурсов. В отличие от стандартного планировщика Hadoop, который формирует очередь приложений, FairScheduler позволяет коротким приложениям завершать работу в разумные сроки, не оставляя ждать при этом долговременные приложения. Это также разумный способ разделить кластер между несколькими пользователями. Наконец, справедливое распределение может также работать с приоритетностью приложений – приоритеты используются в качестве веса для определения доли ресурсов от их совокупности, которую должны получить приложения.

Далее планировщик организует приложения в “очереди” и справедливо распределяет ресурсы между этими очередями. По умолчанию все пользователи имеют общую очередь с именем default. Если приложение специально указывает очередь в запросе ресурса контейнера, запрос отправляется в эту очередь. Также можно назначать очереди на основе имени пользователя, включенного в запрос, через конфигурацию. В каждой очереди имеется политика планирования для совместного использования ресурсов между запущенными приложениями. По умолчанию устанавливается распределение ресурсов на основе памяти, но также могут быть настроены FIFO и мультиресурсность с Dominant Resource Fairness. Очереди могут быть организованы в иерархию для разделения ресурсов и настроены с весами для совместного использования кластера в определенных пропорциях.

Кроме этого, FairScheduler позволяет назначать гарантированные минимальные доли в очереди, что полезно для обеспечения определенных пользователей, групп или рабочих приложений достаточными ресурсами. Когда очередь содержит приложения, она получает по крайней мере свою минимальную долю, но когда очередь не нуждается в полной гарантированной доле, избыток распределяется между другими запущенными приложениями. Это позволяет планировщику гарантировать пропускную способность очередей при эффективном использовании ресурсов, когда эти очереди не содержат приложений.

FairScheduler позволяет запускать все приложения по умолчанию, но также через файл конфигурации можно ограничить количество запущенных приложений на пользователя и на очередь. Это может быть полезно, когда пользователь должен одновременно отправить сотни приложений, или в целом для повышения производительности, если запуск слишком большого количества приложений может привести к созданию слишком большого объема промежуточных данных или слишком частому переключению контекста. Ограничение приложений не приводит к сбою каких-либо последующих отправленных приложений, а только к ожиданию в очереди планировщика, пока не завершатся более ранние приложения пользователя.

Иерархия очередей и политика

FairScheduler поддерживает иерархию очередей. Все очереди происходят из очереди с именем root. Доступные ресурсы распределяются между дочерними элементами root-очереди типичным способом справедливого планирования. Затем дочерние очереди таким же образом распределяют выделенные им ресурсы по своим дочерним очередям. Приложения могут быть запланированы только в leaf-очередях. Очереди можно указывать как дочерние элементы других очередей, помещая их как подэлементы в файл распределения.

Имя очереди начинается с перечисления имен ее родителей с точками в качестве разделителей. Таким образом, очередь с именем queue1 в root-очереди называется “root.queue1”, а очередь с именем queue2 в очереди с именем “parent1” называется “root.parent1.queue2”. При обращении к очередям часть имени root необязательна, поэтому queue1 может называться просто “queue1”, а queue2 – “parent1.queue2”.

Кроме того, FairScheduler позволяет устанавливать различные индивидуальные политики для каждой очереди, чтобы разрешить совместное использование ресурсов любым удобным для пользователя способом. Политика может быть построена путем расширения org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy. FifoPolicy, FairSharePolicy (по умолчанию) и DominantResourceFairnessPolicy являются встроенными и могут быть легко использованы.

Некоторые дополнения еще не поддерживаются в оригинальном (MR1) Fair Scheduler. Среди них – использование индивидуальных политик, управляющих приоритетом “boosting” над определенными приложениями.

Размещение приложений в очередях

Планировщик Fair Scheduler позволяет администраторам настраивать политики, которые автоматически помещают отправленные приложения в соответствующие очереди. Размещение может зависеть от пользователя и групп отправителя и запрашиваемой очереди. Политика состоит из набора правил, которые применяются последовательно для классификации входящего приложения. Каждое правило либо помещает приложение в очередь, либо отклоняет его, либо переходит к следующему правилу. Далее в документации приведен Формат файла распределения для настройки этих политик.

Установка

Для использования Fair Scheduler сначала необходимо назначить соответствующий класс планировщика в yarn-site.xml:

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

Конфигурация

Настройка планировщика Fair Scheduler обычно включает в себя изменение двух файлов. Во-первых, можно настроить параметры всего планировщика, добавив свойства конфигурации в файл yarn-site.xml в существующую директорию. Во-вторых, в большинстве случаев пользователи желают создать список файлов распределения, в котором указываются существующие очереди и соответствующий им вес и пропускная способность. Файл распределения перезагружается каждые 10 секунд, позволяя вносить изменения на лету.

Свойства в файле yarn-site.xml

yarn.scheduler.fair.allocation.file – путь к файлу распределения. Файл распределения – это XML-манифест, описывающий очереди и их свойства в дополнение к определенным параметрам политики по умолчанию. Этот файл должен быть в формате XML, описанном в следующем параграфе. Если указан относительный путь, то поиск файла осуществляется по classpath (который обычно включает в себя каталог Hadoop conf). По умолчанию используется fair-scheduler.xml.

yarn.scheduler.fair.user-as-default-queue – определяет, следует ли использовать имя пользователя, связанное с распределением, в качестве имени очереди по умолчанию, если другого не указано. Если для параметра установлено значение false или не задано вовсе, все задачи имеют общую очередь по умолчанию с именем “default”. По умолчанию значение параметра устанавливается на true. Если в файле распределения указывается политика размещения в очереди, то данное свойство игнорируется.

yarn.scheduler.fair.preemption – определяет, следует ли использовать преимущественное право preemption. По умолчанию устанавливается на false.

yarn.scheduler.fair.preemption.cluster-utilization-threshold – порог использования, после которого вступает в действие преимущественное право preemption. Вычисляется как максимальное отношение использования к пропускной способности среди всех ресурсов. По умолчанию задается 0,8f.

yarn.scheduler.fair.sizebasedweight – определяет, следует ли назначать общие ресурсы отдельным приложениям, основываясь на их размере, вместо того, чтобы предоставлять равные ресурсы всем приложениям независимо от их размера. При значении true приложения взвешиваются по натуральному логарифму – единица плюс вся запрашиваемая память приложения, поделенная на натуральный логарифм 2. По умолчанию значение false.

yarn.scheduler.fair.assignmultiple – определяет, разрешить ли назначение нескольких контейнеров в одном heartbeat-сообщении. По умолчанию false.

yarn.scheduler.fair.dynamic.max.assign – устанавливает, следует ли динамически определять количество ресурсов, которое может быть назначено за одно heartbeat-сообщение, если для атрибута assignmultiple задано значение true. При включенном параметре около половины нераспределенных ресурсов на узле распределяются по контейнерам за одинарное heartbeat-сообщение. По умолчанию true.

yarn.scheduler.fair.max.assign – максимальное количество контейнеров, которое может быть назначено за одно heartbeat-сообщение, при условии: значение assignmultiple задано true, а для dynamic.max.assign равно false. По умолчанию параметр устанавливается в -1, что не задает никаких ограничений.

yarn.scheduler.fair.locality.threshold.node – число возможностей планирования для приложений, которые запрашивают контейнеры на определенных узлах, с момента последнего назначения контейнера в ожидании перед принятием размещения на другом узле. Выражается в виде числа с плавающей запятой (float) от 0 до 1, которое в виде доли от размера кластера представляет собой количество возможностей планирования, которые необходимо упустить. Значение по умолчанию -1.0 означает, что никаких возможностей планирования упускаться не будет.

yarn.scheduler.fair.locality.threshold.rack – число возможностей планирования для приложений, запрашивающих контейнеры на определенных стойках, с момента последнего назначения контейнера для ожидания перед принятием размещения на другой стойке. Выражается в виде числа с плавающей запятой (float) от 0 до 1, которое в виде доли от размера кластера представляет собой количество возможностей планирования, которые необходимо пропустить. Значение по умолчанию -1.0 означает, что никаких возможностей планирования упускаться не будет.

yarn.scheduler.fair.allow-undeclared-pools – если параметр установлен на true, то во время отправки приложения могут быть созданы новые очереди, так как они указаны отправителем в качестве очереди приложения либо благодаря свойству user-as-default-queue property. Если значение установлено на false, то каждый раз, когда приложение помещается в очередь, которая не определена в файле распределения, оно помещается в очередь default. По умолчанию параметр уставновлен на true. Если в файле распределения указывается политика размещения в очереди, то данное свойство игнорируется.

yarn.scheduler.fair.update-interval-ms – интервал, в течение которого можно заблокировать планировщик и пересчитать справедливые доли и спрос и проверить, не требуется ли что-либо для преимущественного права preemption. По умолчанию устанавливается 500 мс.

yarn.resource-types.memory-mb.increment-allocation – инкремент памяти. Если отправить задачу с запросом ресурса, не кратным параметру, запрос округляется до ближайшего инкремента. По умолчанию 1024 МБ.

yarn.resource-types.vcores.increment-allocation – инкремент vcores. Если отправить задачу с запросом ресурса, не кратным параметру, запрос округляется до ближайшего инкремента. По умолчанию 1.

yarn.resource-types.<resource>.increment-allocation – инкремент <resource>. Если отправить задачу с запросом ресурса, не кратным параметру, запрос округляется до ближайшего инкремента. Если свойство не указано для ресурса, округление не применяется. Если единица измерения не указана, принимается единица измерения ресурса по умолчанию.

yarn.scheduler.increment-allocation-mb – инкремент памяти. По умолчанию 1024 МБ. Вместо данного параметра предпочитается yarn.resource-types.memory-mb.increment-allocation.

yarn.scheduler.increment-allocation-vcores – инкремент CPU vcores. По умолчанию 1. Вместо данного параметра предпочитается yarn.resource-types.vcores.increment-allocation.

Формат файла распределения

Файл распределения должен быть в формате XML.

Элементы очереди. Элементы очереди могут принимать необязательный атрибут type, который при установке на parent делает очередь родительской. Это полезно в случаях, когда необходимо создать родительскую очередь без настройки каких-либо leaf-очередей. Каждый элемент очереди может содержать следующие свойства:

  • minResources: минимальные ресурсы, на которые имеет право очередь, в форме “X mb, Y vcores”. При политике single-resource значение vcores игнорируется. Если минимальная общая доля очереди не удовлетворяется, ей предлагаются доступные ресурсы прежде, чем любой другой очереди с тем же родителем. В соответствии с политикой single-resource очередь считается неудовлетворенной, если ее использование памяти ниже минимального совместно используемого объема памяти. В соответствии с принципом dominant resource очередь считается неудовлетворенной, если ее использование в качестве основного ресурса относительно производительности кластера ниже минимальной доли для этого ресурса. Если в этой ситуации не удовлетворяется несколько очередей, ресурсы попадают в очередь с наименьшим соотношением между соответствующим использованием ресурсов и минимальным. Важно обратить внимание, что существует вероятность того, что очередь, которая находится ниже своего минимума, может не сразу достичь этого минимума при отправке приложения, поскольку ресурсы могут использоваться уже выполняющимися заданиями.
  • maxResources: максимальное количество ресурсов, выделяемых очереди, выраженное либо в абсолютных значениях (“X mb, Y vcores”), либо в процентах от ресурсов кластера (“X% memory, Y% cpu”). Очередь не назначается контейнеру, превышающему данный предел ее совокупного использования.
  • maxChildResources: максимальное количество ресурсов, выделяемых специально для дочерней очереди, выраженное либо в абсолютных значениях (“X mb, Y vcores”), либо в процентах от ресурсов кластера (“X% memory, Y% cpu”). Очередь не назначается контейнеру, превышающему данный предел ее совокупного использования.
  • maxRunningApps: лимит на количество приложений из очереди для одновременного запуска.
  • maxAMShare: лимит на долю очереди, который может быть использован для запуска Application Masters. Свойство можно использовать только для leaf-очередей. Например, если задается значение 1.0f, то Masters в leaf-очереди могут занимать до 100% от общей доли памяти и ЦПУ. Значение -1.0f отключает функцию, и тогда amShare не проверяется. Значением по умолчанию является 0,5f.
  • weight: возможность делить кластер непропорционально с другими очередями. Вес очереди задается по умолчанию 1, в таком случае очередь с установленным весом 2 получает примерно в два раза больше ресурсов.
  • schedulingPolicy: установка политики планирования для любой очереди. Допустимыми значениями являются: fifo / fair / drf или любой класс, который расширяет org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy. Значение по умолчанию fair. Если устанавливается fifo, приложениям с более ранним временем отправки отдается предпочтение для контейнеров, но при этом одновременно могут выполняться отправленные позже приложения при условии наличия пространства в кластере после удовлетворения запросов ранних приложений.
  • aclSubmitApps: список пользователей и/или групп, которые могут отправлять приложения в очередь. Более подробно о формате списка и как работают ACL очереди приведено в Списки контроля доступа к очереди.
  • aclAdministerApps: список пользователей и/или групп, которые могут управлять очередью. В настоящее время единственным административным действием является уничтожение приложения. Более подробно о формате списка и как работают ACL очереди приведено в Списки контроля доступа к очереди.
  • minSharePreemptionTimeout: количество секунд, в течение которых очередь находится под минимальным общим ресурсом, прежде чем предпринять попытки зарезервировать контейнеры для получения ресурсов из других очередей. Если не установлено, очередь наследует значение от своей родительской очереди. Значением по умолчанию является Long.MAX_VALUE, что означает, что контейнеры резервироваться не будут, пока не будет задано полноценное значение параметра.
  • fairSharePreemptionTimeout: количество секунд, в течение которых очередь находится ниже порогового значения fairShare, прежде чем предпринять попытки зарезервировать контейнеры для получения ресурсов из других очередей. Если не установлено, очередь наследует значение от своей родительской очереди. Значением по умолчанию является Long.MAX_VALUE, что означает, что контейнеры резервироваться не будут, пока не будет задано полноценное значение параметра.
  • fairSharePreemptionThreshold: порог преимущественного права fairShare для очереди. Если очередь ожидает fairSharePreemptionTimeout, не получая ресурсы fairSharePreemptionThreshold*fairShare, то допускается резервирование контейнеров для получения ресурсов из других очередей. Если не установлено, очередь наследует значение от своей родительской очереди. По умолчанию задается 0.5f.
  • allowPreemptionFrom: определяет, разрешено ли планировщику резервировать ресурсы из очереди. По умолчанию устанавливается true. При значении false свойство рекурсивно применяется ко всем дочерним очередям.
  • reservation: указывает ReservationSystem, что ресурсы очереди доступны для бронирования пользователями. Относится только к leaf-очередям. При этом leaf-очередь не может быть забронирована, если свойство не настроено.

Элементы пользователя. Представляют сообой настройки, управляющие поведением отдельных пользователей. Они могут содержать одно свойство: maxRunningApps – ограничение количества запущенных приложений для конкретного пользователя.

Элемент userMaxAppsDefault. Устанавливает лимит запуска приложения по умолчанию для всех пользователей, у которых не указано иное ограничение.

Элемент defaultFairSharePreemptionTimeout. Задает тайм-аут преимущественного права preemption для root-очереди. Переопределяется элементом fairSharePreemptionTimeout в root-очереди. По умолчанию значение Long.MAX_VALUE.

Элемент defaultMinSharePreemptionTimeout. Устанавливает минимальное время ожидания преимущественного права preemption для root-очереди. Переопределяется элементом minSharePreemptionTimeout в root-очереди. По умолчанию значение Long.MAX_VALUE.

Элемент defaultFairSharePreemptionThreshold. Задает порог преимущественного права для root-очереди. Переопределяется элементом fairSharePreemptionThreshold в root-очереди. По умолчанию значение 0.5f.

Элемент queueMaxAppsDefault. Устанавливает ограничение по умолчанию для запущенного приложения для очередей. Переопределяется элементом maxRunningApps в каждой очереди.

Элемент queueMaxResourcesDefault. Задает максимальный лимит ресурсов по умолчанию для очереди. Переопределяется элементом maxResources в каждой очереди.

Элемент queueMaxAMShareDefault. Устанавливает ограничение ресурса Application Master по умолчанию для очереди. Переопределяется элементом maxAMShare в каждой очереди.

Элемент defaultQueueSchedulingPolicy. Устанавливает политику планирования по умолчанию для очередей. Переопределяется элементом schedulingPolicy в каждой очереди, если указан. По умолчанию fair.

Элемент reservation-agent. Задает имя класса для реализации ReservationAgent, который пытается разместить запрос пользователя на резервирование в Plan. Значением по умолчанию является org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.

Элемент reservation-policy. Задает имя класса реализации SharingPolicy, который проверяет, не нарушает ли новое резервирование какие-либо инварианты. Значением по умолчанию является org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.

Элемент reservation-planner. Задает имя класса для реализации Planner, который вызывается, если пропускная способность Plan падает ниже зарезервированных пользователем ресурсов (из-за планового обслуживания или отказов узла). Значение по умолчанию org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner, что приводит к сканированию Plan и жадному удалению резервирований в обратном порядке (LIFO) до тех пор, пока зарезервированные ресурсы не оказываются в пределах производительности Plan.

Элемент queuePlacementPolicy. Содержит список элементов правил, которые сообщают планировщику, как в очередях размещать входящие приложения. Правила применяются в том порядке, в котором они перечислены. Правила могут принимать аргументы. Все правила принимают аргумент create, который указывает, может ли правило создавать новую очередь. Create по умолчанию имеет значение true. Если установлено значение false и правило помещает приложение в очередь, которая не настроена в файле распределения, осуществляется переход к следующему правилу. Последнее правило должно быть заключительным, не вызывающим продолжения. Допустимые правила:

  • 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 либо настроив по крайней мере одну leaf-очередь, что сделает ее родительской (приведено далее в примере распределенного файла).
  • default: приложение помещается в очередь, указанную в правиле по умолчанию в атрибуте queue. Если атрибут не указан, приложение помещается в очередь root.default.
  • reject: приложение отклоняется.

Пример распределенного файла:

<?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>

Important

Для обратной совместимости с исходным FairScheduler элементы queue могут быть названы как элементы pool

Списки контроля доступа к очереди

Списки контроля доступа к очереди (Queue Access Control Lists, Queue ACL) позволяют администраторам контролировать, кто может выполнять действия в определенных очередях. Они настраиваются с помощью свойств aclSubmitApps и aclAdministerApps, которые можно установить для каждой очереди. В настоящее время единственным поддерживаемым административным действием является уничтожение приложения. Администратор также может отправлять приложения на уничтожение. Свойства принимают значения в формате “user1,user2 group1,group2” или ” group1,group2” (с учетом пробела). Действия в очереди разрешены, если пользователь/группа является членом Queue ACL самой очереди или любой из ее родителей. Таким образом, если queue2 находится в queue1, а user1 находится в ACL queue1, а user2 находится в ACL queue2, тогда оба пользователя могут отправиться в queue2.

Important

Пробел является разделителем. Для того, чтобы указать только группы ACL, значение должно начинаться с символа пробела

Important

По умолчанию списки ACL для root-очереди имеют значение *, что означает, что по причине того, что списки ACL передаются, любой пользователь может отправлять и уничтожать приложения из любой очереди. Для ограничения доступа необходимо изменить ACL root-очереди на что-то отличное от указанного символа

Списки контроля доступа к резервированию

Списки контроля доступа к резервированию (Reservation Access Control Lists, Reservation ACL) позволяют администраторам контролировать, кто может выполнять действия по резервированию в определенных очередях. Они настраиваются с помощью свойств aclAdministerReservations, aclListReservations и aclSubmitReservations, которые можно установить для каждой очереди. В настоящее время поддерживаемые административные действия – это обновление и удаление резервирований. Администратор также может отправлять и перечислять все резервирования в очереди. Свойства принимают значения в формате “user1,user2 group1,group2” или ” group1,group2” (с учетом пробела). Действия в очереди разрешены, если пользователь/группа является членом Reservation ACL. Важно обратить внимание, что любой пользователь может обновлять, удалять или перечислять свои собственные резервирования.

Important

Если Reservation ACL включены, но не определены, доступ будет иметь каждый пользователь

Настройка ReservationSystem

Fair Scheduler поддерживает ReservationSystem, позволяющую пользователям резервировать ресурсы заблаговременно. Таким образом приложение может запросить зарезервированные ресурсы во время выполнения, указав reservationId. Для этого могут быть настроены следующие параметры конфигурации в yarn-site.xml:

yarn.resourcemanager.reservation-system.enable – обязательный параметр: включить ReservationSystem в ResourceManager. Значение может быть только логическим (boolean), по умолчанию является false, то есть ReservationSystem не включена.

yarn.resourcemanager.reservation-system.class – необязательный параметр: имя класса ReservationSystem. Значение по умолчанию выбирается на основе настроенного планировщика, то есть если настроен FairScheduler, то классом является FairReservationSystem.

yarn.resourcemanager.reservation-system.plan.follower – необязательный параметр: имя класса PlanFollower, который запускается по таймеру и синхронизирует FairScheduler с Plan и наоборот. Значение по умолчанию выбирается на основе настроенного планировщика, то есть если настроен FairScheduler, то классом является FairSchedulerPlanFollower.

yarn.resourcemanager.reservation-system.planfollower.time-step – необязательный параметр: частота таймера PlanFollower (в миллисекундах). Значением по умолчанию является 1000.

ReservationSystem интегрирована с иерархией очереди Fair Scheduler и может быть настроена только для leaf-очередей.

Администрирование

Изменение конфигурации на лету

Есть возможность изменения минимальных долей, лимитов, веса, тайм-аута преимущественного права preemtion и политики планирования очередей на лету во время выполнения посредством редактирования файла распределения. Планировщик перезагружает файл через 10-15 секунд после того, как увидит, что он изменен.

Мониторинг через веб-интерфейс

Текущие приложения, очереди и общие ресурсы можно просмотреть через веб-интерфейс ResourceManager по адресу http://*ResourceManager URL*/cluster/scheduler. Для каждой очереди в веб-интерфейсе можно просмотреть следующие поля:

  • Used Resources – сумма ресурсов, выделенных контейнерам в очереди;
  • Num Active Applications – количество приложений в очереди, которые получили хотя бы один контейнер;
  • Num Pending Applications – количество приложений в очереди, которые еще не получили ни одного контейнера;
  • Min Resources – настроенные минимальные ресурсы, которые гарантированы для очереди;
  • Max Resources – настроенные максимальные ресурсы, которые разрешены в очереди;
  • Instantaneous Fair Share – мгновенная справедливая доля ресурсов. Эти общие ресурсы учитывают только активные очереди (с запущенными приложениями) и используются для планирования решений. Очередям могут быть выделены ресурсы за пределами их общих ресурсов в случаях, когда другие очереди в них не нуждаются. На очередь, потребление ресурсов которой находится на уровне или ниже ее справедливой доли, не влияет преимущественное право preemption контейнеров;
  • Steady Fair Share – постоянная справедливая доля ресурсов в очереди. Эти общие ресурсы учитывают все очереди независимо от того, активны ли они (имеют запущенные приложения). Они вычисляются реже и изменяются только при изменении конфигурации или пропускной способности. Предназначены для обеспечения видимости ресурсов, которые пользователь может ожидать, и поэтому отображаются в веб-интерфейсе.

Перемещение приложений между очередями

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 state dump в log4j.properties.