在Apache Hadoop YARN 3.x（简称YARN）中，切换到Capacity Scheduler有很多好处，但也有一些缺点。为了将这些功能带给当前正在使用Fair Scheduler的用户，Cloudera与上游YARN社区一起创建了一个工具来帮助迁移过程。
为什么要切换到Capacity Scheduler
通过切换到“容量调度程序”，我们可以获得什么？几个例子：
o 一次查看多个节点
o 细粒度的锁
o 多个分配线程
o 吞吐量提高5-10倍
• 亲和力和反亲和力：仅在运行应用程序Y的那些节点上运行应用程序X，反之亦然，切勿在同一节点上运行应用程序X和应用程序Y。
• 调度程序和应用程序活动：用于调试重要调度决策的消息，可以通过RESTful API进行记录和公开。
另外，随着CDP的发布，Cloudera的愿景是支持Capacity Scheduler作为YARN的默认调度程序，并逐步淘汰Fair Scheduler。同时支持两个调度程序会带来一些问题：不仅需要更多的支持和工程能力，而且由于功能缺陷，还需要额外的测试，更复杂的测试用例和测试套件。
经过长期仔细的分析，我们决定选择Capacity Scheduler作为默认调度程序。我们整理了一份文档，比较了
YARN-9698 （
直接链接 ）下的“容量调度程序”和“公平调度程序”的功能。
如果您是本主题的新手，可以通过阅读以下文章来熟悉Capacity Scheduler：
YARN – Capacity Scheduler
• 介绍Fair Scheduler-> Capacity Scheduler转换工具
• 描述其内部运作方式
• 解释命令行开关
• 提供有关如何使用该工具的示例
• 解释该工具的局限性，因为尚无法从Fair Scheduler到Capacity Scheduler 100％自动转换
• 谈论未来的调度
请注意，尽管我们使用各种Fair Scheduler和YARN站点配置测试了该工具，但它是Apache Hadoop的新增功能。强烈建议手动检查和检查生成的输出文件。
转换器本身是CLI应用程序，它是yarn 命令的一部分。要调用该工具，您需要将yarn fs2cs 命令与各种命令行参数一起使用。
该工具将生成两个文件作为输出：Capacity -scheduler.xml 和yarn-site.xml 。请注意，站点配置只是一个增量：它仅包含Capacity Scheduler的新设置，这意味着您必须手动将这些值复制粘贴到现有站点配置中。保留现有的Fair Scheduler属性不太可能造成任何伤害或故障，但是我们建议删除它们以避免混乱。
生成的属性也可以转到标准输出，而不是前面提到的文件。
该工具是CDH到CDP升级的正式组成部分，在
此处进行了说明 。
yarn fs2cs -y /path/to/yarn-site.xml [-f /path/to/fair-scheduler.xml] {-o /output/path/ | -p} [-t] [-s] [-d]-y /path/to/yarn-site.xml [-f /path/to/fair-scheduler.xml] {-o /output/path/ | -p} [-t] [-s] [-d]
在[] 大括号之间列出的开关是可选的。
大括号{} 表示该开关是强制性的，您必须选择一个。
yarn fs2cs --yarnsiteconfig /path/to/yarn-site.xml [--fsconfig /path/to/fair-scheduler.xml] {--output-directory /output/path/ | --print} [--no-terminal-rule-check] [--skip-verification] [--dry-run]--yarnsiteconfig /path/to/yarn-site.xml [--fsconfig /path/to/fair-scheduler.xml] {--output-directory /output/path/ | --print} [--no-terminal-rule-check] [--skip-verification] [--dry-run]
yarn fs2cs --yarnsiteconfig /home/hadoop/yarn-site.xml --fsconfig /home/hadoop/fair-scheduler.xml --output-directory /tmp--yarnsiteconfig /home/hadoop/yarn-site.xml --fsconfig /home/hadoop/fair-scheduler.xml --output-directory /tmp
重要
：
始终对-f / –fsconfig 使用绝对路径。
有关所有命令行开关及其说明的列表，可以使用yarn fs2cs –help 。CLI选项在本
文档 中列出。
假设我们有以下简单的fair-scheduler.xml ：
<allocations> <queue name="root"><queue name="root"> <weight>1.0</weight><weight>1.0</weight> <schedulingPolicy>drf</schedulingPolicy><schedulingPolicy>drf</schedulingPolicy> <queue name="default"><queue name="default"> <weight>1.0</weight><weight>1.0</weight> <schedulingPolicy>drf</schedulingPolicy><schedulingPolicy>drf</schedulingPolicy> </queue></queue> <queue name="users" type="parent"><queue name="users" type="parent"> <maxChildResources>memory-mb=8192, vcores=1</maxChildResources><maxChildResources>memory-mb=8192, vcores=1</maxChildResources> <weight>1.0</weight><weight>1.0</weight> <schedulingPolicy>drf</schedulingPolicy><schedulingPolicy>drf</schedulingPolicy> </queue></queue> </queue></queue> <queuePlacementPolicy><queuePlacementPolicy> <rule name="specified" create="true"/><rule name="specified" create="true"/> <rule name="nestedUserQueue" create="true"><rule name="nestedUserQueue" create="true"> <rule name="default" create="true" queue="users"/><rule name="default" create="true" queue="users"/> </rule></rule> <rule name="default"/><rule name="default"/> </queuePlacementPolicy></queuePlacementPolicy></allocations>
我们在yarn-site.xml中还有以下条目（仅列出与Fair Scheduler相关的条目）：
yarn.scheduler.fair.allow-undeclared-pools = true.scheduler.fair.allow-undeclared-pools = trueyarn.scheduler.fair.user-as-default-queue = true.scheduler.fair.user-as-default-queue = trueyarn.scheduler.fair.preemption = false.scheduler.fair.preemption = falseyarn.scheduler.fair.preemption.cluster-utilization-threshold = 0.8.scheduler.fair.preemption.cluster-utilization-threshold = 0.8yarn.scheduler.fair.sizebasedweight = false.scheduler.fair.sizebasedweight = falseyarn.scheduler.fair.assignmultiple = true.scheduler.fair.assignmultiple = trueyarn.scheduler.fair.dynamicmaxassign = true.scheduler.fair.dynamicmaxassign = trueyarn.scheduler.fair.maxassign = -1.scheduler.fair.maxassign = -1yarn.scheduler.fair.continuous-scheduling-enabled = false.scheduler.fair.continuous-scheduling-enabled = falseyarn.scheduler.fair.locality-delay-node-ms = 2000.scheduler.fair.locality-delay-node-ms = 2000
~$ yarn fs2cs -y /home/examples/yarn-site.xml -f /home/examples/fair-scheduler.xml -o /tmp$ yarn fs2cs -y /home/examples/yarn-site.xml -f /home/examples/fair-scheduler.xml -o /tmp
2020-05-05 14:22:41,384 INFO [main] converter.FSConfigToCSConfigConverter (FSConfigToCSConfigConverter.java:prepareOutputFiles(138)) - Output directory for yarn-site.xml and capacity-scheduler.xml is: /tmp-05-05 14:22:41,384 INFO [main] converter.FSConfigToCSConfigConverter (FSConfigToCSConfigConverter.java:prepareOutputFiles(138)) - Output directory for yarn-site.xml and capacity-scheduler.xml is: /tmp
2020-05-05 14:22:41,388 INFO [main] converter.FSConfigToCSConfigConverter (FSConfigToCSConfigConverter.java:loadConversionRules(177)) - Conversion rules file is not defined, using default conversion config!-05-05 14:22:41,388 INFO [main] converter.FSConfigToCSConfigConverter (FSConfigToCSConfigConverter.java:loadConversionRules(177)) - Conversion rules file is not defined, using default conversion config!
[...] output trimmed for brevity output trimmed for brevity
2020-05-05 14:22:42,572 ERROR [main] converter.FSConfigToCSConfigConverterMain (MarkerIgnoringBase.java:error(159)) - -05-05 14:22:42,572 ERROR [main] converter.FSConfigToCSConfigConverterMain (MarkerIgnoringBase.java:error(159)) - Error while starting FS configuration conversion! while starting FS configuration conversion!
[...] output trimmed for brevity output trimmed for brevity
Caused by: org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.AllocationConfigurationException: Rules after rule 2 in queue placement policy can never be reachedat org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.QueuePlacementPolicy.updateRuleSet(QueuePlacementPolicy.java:115)
[...]
这是一个非常典型的错误。
如果查看fair-scheduler.xml的放置规则，则可以看到默认规则位于nestedUserQueue之后。
我们需要使用–no-terminal-rule-check开关来忽略Fair Scheduler中的终端规则检查。
为什么？
请参阅以下部分。
默认情况下，Fair Scheduler会严格检查放置规则是否为终端规则。这意味着，如果您使用<reject> 规则，然后使用<specified> 规则，则不允许这样做，因为后者不可访问。但是，在
YARN-8967 （将
FairScheduler
更改为使用
PlacementRule
接口）之前，Fair Scheduler比较宽松，并允许某些不再有效的规则序列。如前所述，我们使用该工具实例化Fair Scheduler实例来读取和解析分配文件。为了使Fair Scheduler接受此类配置，请使用-t 或–no-terminal-rule-check必须提供参数以抑制Fair Scheduler引发的异常。在CDH 5.x中，这类放置配置很常见，因此建议始终使用-t 。
使用–no-terminal-rule-check 再次运行该工具
~$ yarn fs2cs -y /home/examples/yarn-site.xml -f /home/examples/fair-scheduler.xml -o /tmp
2020-05-05 14:41:39,189 INFO [main] capacity.CapacityScheduler (CapacityScheduler.java:initScheduler(384)) - Initialized CapacityScheduler with calculator=class org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator, minimumAllocation=<<memory:1024, vCores:1>>, maximumAllocation=<<memory:8192, vCores:4>>, asynchronousScheduling=false, asyncScheduleInterval=5ms,multiNodePlacementEnabled=false
2020-05-05 14:41:39,190 INFO [main] converter.ConvertedConfigValidator (ConvertedConfigValidator.java:validateConvertedConfig(72)) - Capacity scheduler was successfully started
This time, the conversion succeeded!
• Fair Scheduler不会引发异常，它只会打印一条规则不可达的警告。
2020-05-05 14:41:38,908 WARN [main] converter.FSConfigToCSConfigRuleHandler (ConversionOptions.java:handleWarning(48)) - Setting <userMaxAppsDefault> is not supported, ignoring conversion
2020-05-05 14:41:38,945 WARN [main] converter.FSConfigToCSConfigRuleHandler (ConversionOptions.java:handleWarning(48)) - Setting <maxChildResources> is not supported, ignoring conversion
如前所述，两个调度程序之间存在一些功能差距，默认情况下，每当检测到不支持的设置时，都会打印警告。
这对于操作员查看升级后必须微调哪些功能很有用。
• 可以清楚地看到，已启动Capacity Scheduler实例来验证转换后的配置是否有效。
如果我们查看/tmp/yarn-site.xml ，我们会发现它确实很短：
yarn.scheduler.capacity.resource-calculator =org.apache.hadoop.yarn.util.resource.DominantResourceCalculatoryarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled = trueyarn.resourcemanager.scheduler.class = org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
这里没有太多参数。
这是因为禁用了许多与调度相关的设置：
没有抢占，没有连续调度，没有机架或节点位置阈值设置。
让我们看一下新的Capacity-scheduler.xml（同样，此处已格式化，并删除了不必要的XML标记）：
yarn.scheduler.capacity.root.users.maximum-capacity = 100yarn.scheduler.capacity.root.default.capacity = 50.000yarn.scheduler.capacity.root.default.ordering-policy = fairyarn.scheduler.capacity.root.users.capacity = 50.000yarn.scheduler.capacity.root.default.maximum-capacity = 100yarn.scheduler.capacity.root.queues = default,usersyarn.scheduler.capacity.root.maximum-capacity = 100yarn.scheduler.capacity.maximum-am-resource-percent = 0.5
请注意属性yarn.scheduler.capacity.maximum-am-resource-percent 设置为0.5 。
fair-scheduler.xml中缺少此功能，那么为什么在这里呢？
该工具必须进行设置，因为Capacity Scheduler中的默认设置为10％，而Fair Scheduler中的默认设置为50％。
yarn.scheduler.fair.preemption - trueyarn.scheduler.fair.sizebasedweight - trueyarn.scheduler.fair.continuous-scheduling-enabled - true
再次运行转换后，这些设置现在反映在新的yarn-site.xml中：
yarn.scheduler.capacity.resource-calculator =org.apache.hadoop.yarn.util.resource.DominantResourceCalculatoryarn.scheduler.capacity.schedule-asynchronously.scheduling-interval-ms = 5yarn.scheduler.capacity.schedule-asynchronously.enable = trueyarn.resourcemanager.monitor.capacity.preemption.monitoring_interval = 10000yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill = 15000yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled = trueyarn.resourcemanager.scheduler.class =org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduleryarn.resourcemanager.scheduler.monitor.enable = true
基于大小的权重设置也影响了Capacity-scheduler.xml ：
yarn.scheduler.capacity.root.default.ordering-policy.fair.enable-size-based-weight = trueyarn.scheduler.capacity.root.users.ordering-policy.fair.enable-size-based-weight = trueyarn.scheduler.capacity.root.users.capacity = 50.000yarn.scheduler.capacity.root.queues = default,usersyarn.scheduler.capacity.root.users.maximum-capacity = 100yarn.scheduler.capacity.root.ordering-policy.fair.enable-size-based-weight = true[...] rest is omitted because it’s the same as before
一个关键问题是如何转换权重。从长远来看，权重决定队列的“公平份额”。公平份额是队列可以获取的资源数量，限制了提交给该队列的应用程序可以使用多少资源。
例如，如果“ root.a”和“ root.b”的权重分别为3和1，则“ root.a”将获得群集资源总数的75％，而“ root.b”将获得25％。
但是，如果我们仅向“ root.b”提交申请该怎么办？只要“ root.a”为空，“ root.b”中的应用程序就可以自由占用整个集群（现在让我们忽略<maxResources> ）。
我们如何在Capacity Scheduler中模拟权重？
事实证明，Capacity Scheduler的“容量”非常接近权重的概念，只是将其表示为百分比，而不是整数。但是默认情况下，容量是有上限的，这意味着容量为25.00的“ root.b”将始终仅使用群集的25％。这就是弹性概念出现的地方。弹性意味着可以将集群中的空闲资源分配给超出其默认容量的队列。该值也以百分比表示。因此，我们必须为所有队列启用完全弹性。
FairScheduler权重对CapacityScheduler配置的简单示例
总而言之，我们可以使用以下属性来实现类似于Fair Scheduler的行为：
yarn.scheduler.capacity.root.a.capacity = 75.000yarn.scheduler.capacity.root.a.maximum-capacity = 100.000yarn.scheduler.capacity.root.b.capacity = 25.000yarn.scheduler.capacity.root.b.maximum-capacity = 100.000
假设以下简单队列层次结构在Fair Scheduler中具有权重：
root = 1root.users = 20root.default = 10root.users.alice = 3root.users.bob = 1
yarn.scheduler.capacity.root.capacity = 100.000yarn.scheduler.capacity.root.maximum-capacity = 100.000yarn.scheduler.capacity.root.users.capacity = 66.667yarn.scheduler.capacity.root.users.maximum-capacity = 100.000yarn.scheduler.capacity.root.default.capacity = 33.333yarn.scheduler.capacity.root.default.maximum-capacity = 100.000yarn.scheduler.capacity.root.users.alice.capacity = 75.000yarn.scheduler.capacity.root.users.alice.maximum-capacity = 100.000yarn.scheduler.capacity.root.users.bob.capacity = 25.000yarn.scheduler.capacity.root.users.bob.maximum-capacity = 100.000
在执行了一些基本的验证步骤（例如，如果输出目录存在，输入文件存在等）之后，它将加载yarn-site.xml 并转换与调度相关的属性，例如抢占、连续调度和机架/节点位置设置。
该工具使用Fair Scheduler实例加载和解析分配文件。它还会检测到不受支持的属性，并分别显示警告消息，表明不会转换特定设置。不支持的设置和已知限制将在本文后面解释。
转换完成并生成输出文件后，最后一步是验证。默认情况下，fs2cs 尝试使用转换后的配置在内部启动Capacity Scheduler。
目前，Fair Scheduler和Capacity Scheduler之间存在一些功能上的差距–也就是说，仅当您不使用Capacity Scheduler中当前未实现的Fair Scheduler配置中的设置时，才可以进行完全转换。
保留系统设置的转换被完全跳过，在可预见的将来这可能不会改变。原因是它不是一个经常使用的功能，并且在两个调度程序中的工作方式完全不同。
放置规则在公平调度器定义哪些队列提交的申请应放置到YARN中。放置规则遵循“失败”逻辑：如果第一个规则不适用（该规则返回的队列不存在），则尝试下一个规则，依此类推。如果最后一条规则未能返回有效队列，那么将拒绝应用程序提交。
容量调度程序采用概念上类似的方法，称为
映射规则。但是，实现方式有所不同：将放置规则转换为映射规则目前无法正确完成。原因有很多：
1) 如果映射规则匹配，它将返回一个队列，并且不会继续进行下一个队列。它要么是一个特定的队列，要么是root.default 。
2) 映射规则使用占位符，例如％primary_group ，％secondary_group 和％user 。这与Fair Scheduler中的功能非常相似。但是，它缺少％specified 。
3) 放置规则可以具有创建标志。如果create = true ，那么将动态创建队列。Capacity Scheduler没有基于每个规则的自动队列创建功能。如果父级是所谓的托管父级，则它能够按需创建队列（启用了属性auto-create-child-queue ）。但是托管父队列不能具有静态叶队列，即。它们下的子级不能在Capacity-scheduler.xml中定义。
4) 主要组和次要组的嵌套规则使事情变得更加复杂，因为create 标志在外部和内部规则上均被解释。
这些差异使将放置规则转换为映射规则变得困难，有时甚至是不可能。在这种情况下，集群运营商必须具有创造力，并偏离其原始的放置算法。
• 每个用户的最大应用程序数
• <userMaxAppsDefault> –每个用户的默认最大应用程序
• <minResources> –队列的最小资源
• <maxResources> –队列的最大资源
• <maxChildResources> –动态创建的队列的最大资源
• 队列级别的DRF排序策略：在Capacity Scheduler中，DRF必须是全局的。在Fair Scheduler中，可以在DRF父项下使用常规的“ Fair”策略。
仍在积极地进行开发以提供更好的用户体验。
最重要的任务是：
1) 在Capacity Scheduler（YARN-9936 ）中将百分比向量作为资源处理。用户将不仅可以定义单个容量，还可以定义不同资源的多个值。
2) 手柄maxRunningApps 每用户userMaxAppsDefault （YARN-9930 ）我们有“每用户最多的应用程序”设置，但它不是直接配置和繁琐，因为它的三个设置的组合。我们还必须注意不要破坏现有行为–如果超过了最大设置，Capacity Scheduler中的现有逻辑将拒绝提交应用程序，而在Fair Scheduler中，该应用程序始终被接受，并将在以后进行调度。
3) 处理minResources ，maxResources 和maxChildResources 这些在很大程度上取决于YARN-9936 。在Fair Scheduler中，用户可以通过多种方式（单个百分比，两个单独的百分比或绝对资源）表达这些设置。为了支持Capacity Scheduler中的类似设置，我们需要YARN-9936 。
4) 使映射规则的行为类似于Fair Scheduler中存在的实现。在“放置规则”部分中说明了如何评估映射规则。我们可能需要一种新的，可插入的方法–这样，我们就不会在已经非常复杂的现有代码库中引入回归。
5) 关于DRF和其他调度策略的改进（YARN-9892 ）当前，我们有一个由属性yarn.scheduler.capacity.resource-calculator 定义的全局资源计算器。这在Fair Scheduler中更加细腻。
6) 关于整个转换过程的通用微调在Capacity Scheduler 中有一些属性，例如“ user-limit-factor”或“ minimum-user-limit-percent”。我们暂时不使用这些设置，但是事实证明，在某些配置中，它们被证明是有用的。
该fs2cs 工具已成为CDH-CDP的升级路径，帮助客户将基于调度程序的公平配置，容量调度的一个组成部分。我们了解了为什么切换到Capacity Scheduler具有明显的好处。
我们已经看到，目前并非所有事物都是完美的。Fair Scheduler中的某些功能可能会丢失，或者在Capacity Scheduler中仅部分受支持。在转换过程中遇到这样的设置时，该工具将显示警告消息。
转换的某些方面非常具有挑战性，尤其是展示位置规则。即使在概念上相似，这两个调度程序遵循的队列放置原理也略有不同，这需要我们付出额外的努力才能使Capacity Scheduler映射规则以相同的方式工作。
尽管如此，我们仍致力于实施所有必要的更改，以提高客户满意度并改善用户体验。
原文链接：https://blog.cloudera.com/fair-scheduler-to-capacity-scheduler-conversion-tool/
原文作者：
Peter Bacsko
&
Rudolf Reti
