操作场景 Yarn NodeManager定义的存储目录不正确或Yarn的存储规划变化时，MRS集群管理员需要在Manager中修改NodeManager的存储目录，以保证Yarn正常工作。NodeManager的存储目录包含本地存放目录“yarn.nodemanager.local-dirs”和日志目录“yarn.nodemanager.log-dirs”。适用于以下场景： 更改NodeManager角色的存储目录，所有NodeManager实例的存储目录将同步修改。 更改NodeManager单个实例的存储目录，只对单个实例生效，其他节点NodeManager实例存储目录不变。

在WebUI显示更多历史作业 默认情况下，Yarn WebUI界面支持任务列表分页功能，每个分页最多显示5000条历史作业，总共最多保留10000条历史作业。如果您需要在WebUI上查看更多的作业，可以配置参数如表3。具体配置操作请参考修改集群服务配置参数。 表3 参数说明 配置参数 说明 默认值 yarn.resourcemanager.max-completed-applications 设置在WebUI总共显示的历史作业数量。 10000 yarn.resourcemanager.webapp.pagination.enable 是否开启Yarn WebUI的任务列表后台分页功能。 true yarn.resourcemanager.webapp.pagination.threshold 开启Yarn WebUI的任务列表后台分页功能后，每个分页显示的最大作业数量。 5000 显示更多的历史作业，会影响性能，增加打开Yarn WebUI的时间，建议开启后台分页功能，并根据实际硬件性能修改“yarn.resourcemanager.max-completed-applications”参数。 修改参数值后，需重启Yarn服务使其生效。

在UI显示container日志 默认情况下，系统会将container日志收集到HDFS中。如果您不需要将container日志收集到HDFS中，可以配置参数见表2。具体配置操作请参考修改集群服务配置参数。 表2 参数说明 配置参数 说明 默认值 yarn.log-aggregation-enable 设置是否将container日志收集到HDFS中。 设置为true，表示日志会被收集到HDFS目录中。默认目录为“{yarn.nodemanager.remote-app-log-dir}/${user}/{thisParam}”，该路径可通过界面上的“yarn.nodemanager.remote-app-log-dir-suffix”参数进行配置。 设置为false，表示日志不会收集到HDFS中。 修改参数值后，需重启Yarn服务使其生效。 说明： 在修改值为false并生效后，生效前的日志无法在UI中获取。您可以在“yarn.nodemanager.remote-app-log-dir-suffix”参数指定的路径中获取到生效前的日志。 如果需要在UI上查看之前产生的日志，建议将此参数设置为true。 true

配置描述 有关如何配置CPU隔离与安全的CGroups功能的详细信息，请参见Hadoop官网： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/NodeManagerCgroups.html MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/NodeManagerCgroups.html 由于CGroups为Linux内核特性，是通过LinuxContainerExecutor进行开放。请参考官网资料对LinuxContainerExecutor进行安全配置。您可通过官网资料了解系统用户和用户组配置对应的文件系统权限。详情请参见： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/SecureMode.html#LinuxContainerExecutor MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-common/SecureMode.html#LinuxContainerExecutor 请勿修改对应文件系统中各路径所属的用户、用户组及对应的权限，否则可能导致本功能异常。 当参数“yarn.nodemanager.resource.percentage-physical-cpu-limit”配置过小，导致可使用的核不足1个时，例如4核节点，将此参数设置为20%，不足1个核，那么将会使用系统全部的核。Linux的一些版本不支持Quota模式，例如Cent OS。在这种情况下，可以使用CPUset模式。 配置cpuset模式，即YARN只能使用配置的CPU，需要添加以下配置。 表1 cpuset配置 参数 描述 默认值 yarn.nodemanager.linux-container-executor.cgroups.cpu-set-usage 设置为“true”时，应用以cpuset模式运行。 false 配置strictcpuset模式，即container只能使用配置的CPU，需要添加以下配置。 表2 CPU硬隔离参数配置 参数 描述 默认值 yarn.nodemanager.linux-container-executor.cgroups.cpu-set-usage 设置为“true”时，应用以cpuset模式运行。 false yarn.nodemanager.linux-container-executor.cgroups.cpuset.strict.enabled 设置为true时，container只能使用配置的CPU。 false 要从cpuset模式切换到Quota模式，必须遵循以下条件： 配置“yarn.nodemanager.linux-container-executor.cgroups.cpu-set-usage”=“false”。 删除“/sys/fs/cgroup/cpuset/hadoop-yarn/”路径下container文件夹（如果存在）。 删除“/sys/fs/cgroup/cpuset/hadoop-yarn/”路径下cpuset.cpus文件中设置的所有CPU。

回答 在某些情况下，已经观察到诊断消息可能无限增长。由于诊断消息存储在状态存储中，不建议允许诊断消息无限增长。因此，需要有一个属性参数用于设置诊断消息的最大大小。 如果您需要设置“yarn.app.attempt.diagnostics.limit.kc”参数值，具体操作参考修改集群服务配置参数，进入Yarn“全部配置”页面，在搜索框搜索以下参数。 表1 参数描述 参数 描述 默认值 yarn.app.attempt.diagnostics.limit.kc 定义每次应用连接的诊断消息的数据大小，以千字节为单位（字符数*1024）。当使用ZooKeeper来存储应用程序的行为状态时，需要限制诊断消息的大小，以防止YARN拖垮ZooKeeper。如果将“yarn.resourcemanager.state-store.max-completed-applications”设置为一个较大的数值，则需要减小该属性参数的值以限制存储的总数据大小。 64

配置描述 参考修改集群服务配置参数进入Yarn服务参数“全部配置”界面，在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 yarn.nodemanager.vmem-check-enabled 是否进行虚拟内存检测的开关。如果任务使用的内存量超出分配值，则直接将任务强制终止。 设置为true时，进行虚拟内存检测； 设置为false时，不进行虚拟内存检测。 true yarn.nodemanager.pmem-check-enabled 是否进行物理内存检测的开关。如果任务使用的内存量超出分配值，则直接将任务强制终止。 设置为true时，进行物理内存检测； 设置为false时，不进行物理内存检测。 true

回答 如果应用程序没有设置标签表达式，那么该应用程序上新增的container/resource将使用其所在队列默认的标签表达式。如果队列没有默认的标签表达式，则将其标签表达设置为“default label”。 当应用程序（app1）提交到队列（Q1）上时，应用程序上新增的container/resource使用队列默认的标签表达式（“label1”）。如果app1正在运行时Q1被删除，则app1被移动到“lost_and_found”队列上。由于“lost_and_found”队列没有标签表达式，其标签表达式设置为“default label”，此时app1上新增的container/resource也将其标签表达式设置为“default label”。当app1被移回正常运行的队列（例如，Q2）时，如果Q2支持调用app1中的所有标签表达式（包含“label1”和“default label”），则app1能正常运行直到结束；如果Q2仅支持调用app1中的部分标签表达式（例如，仅支持调用“default label”），那么app1在运行时，拥有“label1”标签表达式的部分任务的资源请求将无法获得资源，从而被挂起，不能正常运行。 因此当把应用程序从“lost_and_found”队列移动到其他运行正常的队列上时，需要保证目标队列能够调用该应用程序的所有标签表达式。 建议不要删除正在运行应用程序的队列。

使用Yarn客户端 安装客户端，具体请参考安装MRS客户端。 以客户端安装用户，登录安装客户端的节点。 执行以下命令，切换到客户端安装目录。 cd /opt/client 执行以下命令配置环境变量。 source bigdata_env 如果集群为安全模式，执行以下命令进行用户认证。普通模式集群无需执行用户认证。 kinit 组件业务用户 直接执行Yarn命令。例如： yarn application -list

操作场景 抢占任务可精简队列中的job运行并提高资源利用率，由ResourceManager的capacity scheduler实现，其简易流程如下： 假设存在两个队列A和B。其中队列A的capacity为25%，队列B的capacity为75%。 初始状态下，任务1发送给队列A，此任务需要75%的集群资源。之后任务2发送到了队列B，此任务需要50%的集群资源。 任务1将会使用队列A提供的25%的集群资源，并从队列B获取的50%的集群资源。队列B保留25%的集群资源。 启用抢占任务特性，则任务1使用的资源将会被抢占。队列B会从队列A中获取25%的集群资源以满足任务2的执行。 当任务2完成后，集群中存在足够的资源时，任务1将重新执行。

操作步骤 参数入口： 参考修改集群服务配置参数进入Yarn服务参数“全部配置”界面，在搜索框中输入参数名称。 表1 Preemption配置 参数 描述 默认值 yarn.resourcemanager.scheduler.monitor.enable 根据“yarn.resourcemanager.scheduler.monitor.policies”中的策略，启用新的scheduler监控。设置为“true”表示启用监控，并根据scheduler的信息，启动抢占的功能。设置为“false”表示不启用。 false yarn.resourcemanager.scheduler.monitor.policies 设置与scheduler配合的“SchedulingEditPolicy”的类的清单。 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy yarn.resourcemanager.monitor.capacity.preemption.observe_only 设置为“true”，则执行策略，但是不对集群资源进程抢占操作。 设置为“false”，则执行策略，且根据策略启用集群资源抢占的功能。 false yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval 根据策略监控的时间间隔，单位为毫秒。如果将该参数设置为更大的值，容量检测将不那么频繁地运行。 3000 yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill 应用发送抢占需求到停止container（释放资源）的时间间隔，单位为毫秒。取值范围大于等于0。 默认情况下，如果ApplicationMaster15秒内没有终止container，ResourceManager等待15秒后会强制终止。 15000 yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round 在一个周期内能够抢占资源的最大的比例。可使用这个值来限制从集群回收容器的速度。计算出了期望的总抢占值之后，策略会伸缩回这个限制。 0.1 yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity 集群中资源总量乘以此配置项的值加上某个队列（例如队列A）原有的资源量为资源抢占盲区。当队列A中的任务实际使用的资源超过该抢占盲区时，超过部分的资源将会被抢占。取值范围：0~1。 说明： 设置的值越小越有利于资源抢占。 0 yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor 设置抢占目标，Container只会抢占所配置比例的资源。 示例，如果设置为0.5，则在5*“yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill”的时间内，任务会回收所抢占资源的近95%。即接连抢占5次，每次抢占待抢占资源的0.5，呈几何收敛，每次的时间间隔为“yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill”。取值范围：0~1。 1

Application master使用异步接口AMRMClientAsync.createAMRMClientAsync()与ResourceManager交互 不建议直接使用protocol接口ClientRMProxy.createRMProxy(config,ApplicationMasterProtocol.class) 创建application master与resource manager交互的客户端。

多线程安全登录方式 如果有多线程进行login的操作，当应用程序第一次登录成功后，所有线程再次登录时应该使用relogin的方式。 login的代码样例： private Boolean login(Configuration conf){ boolean flag = false; UserGroupInformation.setConfiguration(conf); try { UserGroupInformation.loginUserFromKeytab(conf.get(PRINCIPAL), conf.get(KEYTAB)); System.out.println("UserGroupInformation.isLoginKeytabBased(): " +UserGroupInformation.isLoginKeytabBased()); flag = true; } catch (IOException e) { e.printStackTrace(); } return flag; } relogin的代码样例： public Boolean relogin(){ boolean flag = false; try { UserGroupInformation.getLoginUser().reloginFromKeytab(); System.out.println("UserGroupInformation.isLoginKeytabBased(): " +UserGroupInformation.isLoginKeytabBased()); flag = true; } catch (IOException e) { e.printStackTrace(); } return flag; }

自研超级调度器Superior Scheduler原理 Superior Scheduler是一个专门为Hadoop YARN分布式资源管理系统设计的调度引擎，是针对企业客户融合资源池，多租户的业务诉求而设计的高性能企业级调度器。 Superior Scheduler可实现开源调度器、Fair Scheduler以及Capacity Scheduler的所有功能。另外，相较于开源调度器，Superior Scheduler在企业级多租户调度策略、租户内多用户资源隔离和共享、调度性能、系统资源利用率和支持大集群扩展性方面都做了针对性的增强。设计的目标是让Superior Scheduler直接替代开源调度器。 类似于开源Fair Scheduler和Capacity Scheduler，Superior Scheduler通过YARN调度器插件接口与YARN Resource Manager组件进行交互，以提供资源调度功能。图1为其整体系统图。 图1 Superior Scheduler内部架构 图1中，Superior Scheduler的主要模块如下： Superior Scheduler Engine：具有丰富调度策略的高性能调度器引擎。 Superior YARN Scheduler Plugin：YARN Resource Manager和Superior Scheduler Engine之间的桥梁，负责同YARN Resource Manager交互。 在调度原理上，开源的调度器都是基于计算节点心跳驱动的资源反向匹配作业的调度机制。具体来讲，每个计算节点定期发送心跳到YARN的Resource Manager通知该节点状态并同时启动调度器为这个节点分配作业。这种调度机制把调度的周期同心跳结合在一起，当集群规模增大时，会遇到系统扩展性以及调度性能瓶颈。另外，因为采用了资源反向匹配作业的调度机制，开源调度器在调度精度上也有局限性，例如数据亲和性偏于随机，另外系统也无法支持基于负载的调度策略等。主要原因是调度器在选择作业时，缺乏全局的资源视图，很难做到好的选择。 Superior Scheduler内部采用了不同的调度机制。Superior Scheduler的调度器引入了专门的调度线程，把调度同心跳剥离开，避免了系统心跳风暴问题。另外，Superior Scheduler调度流程采用了从作业到资源的正向匹配方法，这样每个调度的作业都有全局的资源视图，可以很大的提高调度的精度。相比开源调度器，Superior Scheduler在系统吞吐量、利用率、数据亲和性等方面都有很大提升。 图2 Superior Scheduler性能对比 Superior Scheduler除了提高系统吞吐量和利用率，还提供了以下主要调度功能： 多资源池 多资源池有助于在逻辑上划分集群资源并在多个租户/队列之间共享它们。资源池的划分可以基于异构的资源或完全按照应用资源隔离的诉求来划分。对于一个资源池，不同队列可配置进一步的策略。 每个资源池多租户调度（reserve、min、share、max） Superior Scheduler提供了灵活的层级多租户调度策略。并允许针对不同的资源池可以访问的租户/队列，配置不同策略，如下所示。 表1 策略描述 策略名称 描述 reserve 预留租户资源。即使租户没有作业，其他租户也不能使用该预留的资源。其值可以是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者的最大值。缺省的reserve值为0。相对于定义一个专用资源池并指定具体机器的方式，reserve的策略可以认为提供了一种灵活的浮动预留功能，由于并不限定具体的机器，可以提高计算的数据亲和性，也不会受具体机器故障的影响。 min 具有抢占支持的最低保证资源。其他租户可以使用这部分资源，但是本租户享有优先使用权。其值可以是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者的最大值。缺省值是0。 share 不支持抢占的共享资源。本租户要使用这部分资源时，需要等待其他租户完成作业并释放资源。其值是百分比或绝对值。 max 允许的最大资源数量。租户无法获得比允许的最大资源多的资源。其值是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者最大值。缺省值不受限制。 租户资源分配策略示意图，如图3所示。 图3 策略示意图 其中“total”表示总资源，不是调度策略。 同开源的调度器相比，Superior Scheduler同时提供了租户级百分比和绝对值的混配策略，可以很好的适应各种灵活的企业级租户资源调度诉求。例如，用户可以在一级租户提供最大绝对值的资源保障，这样租户的资源不会因为集群的规模改变而受影响。但在下层的子租户之间，可以提供百分比的分配策略，这样可以尽可能提升一级租户内的资源利用率。 异构和多维资源调度 Superior Scheduler除支持CPU和内存资源的调度外，还支持扩展以下功能： 节点标签可用于识别不同节点的多维属性，可以根据这些标签进行调度。 资源池可用于对同一类别的资源进行分组并分配给特定的租户/队列。 租户内多用户公平调度 在叶子租户里，多个用户可以使用相同的队列来提交作业。相比开源调度器，Superior Scheduler可以支持在同一租户内灵活配置不同用户的资源共享策略。例如可以为VIP用户配置更多的资源访问权重。 数据位置感知调度 Superior Scheduler采用“从作业到节点的调度策略”，即尝试在可用节点之间调度给定的作业，使得所选节点适合于给定作业。通过这样做，调度器将具有集群和数据的整体视图。如果有机会使任务更接近数据，则保证了本地化。而开源调度器采用“从节点到作业的调度策略”，在给定节点中尝试匹配适当的作业。 Container调度时动态资源预留 在异构和多样化的计算环境中，一些container需要更多的资源或多种资源，例如Spark作业可能需要更大的内存。当这些container与其他需要较小资源的container竞争时，可能没有机会在合理的时间内获得所需的资源而处于饥饿状态。由于开源的调度器是基于资源反向匹配作业的调度方式，会为这些作业盲目的进行资源预留以防进入饥饿状态。这就导致了系统资源的整体浪费。Superior Scheduler与开源特性的不同之处在于： 基于需求的匹配：由于Superior Scheduler采用“从作业到节点的调度”，能够选择合适的节点来预留资源提升这些特殊container的启动时间，并避免浪费。 租户重新平衡：启用预留逻辑时，开源调度器并不遵循配置的共享策略。Superior Scheduler采取不同的方法。在每个调度周期中，Superior Scheduler将遍历租户，并尝试基于多租户策略重新达到平衡，且尝试满足所有策略（reserve，min，share等），以便可以释放预留的资源，将可用资源流向不同租户下的其他本应得到资源的container。 动态队列状态控制（Open/Closed/Active/Inactive） 支持多个队列状态，有助于MRS集群管理员操作和维护多个租户。 Open状态（Open/Closed）：如果是Open（默认）状态，将接受提交到此队列的应用程序，如果是Closed状态，则不接受任何应用程序。 Active状态（Active/Inactive）：如果处于Active（默认）状态，租户内的应用程序是可以被调度和分配资源。如果处于Inactive状态则不会进行调度。 应用等待原因 如果应用程序尚未启动，则提供作业等待原因信息。 Superior Scheduler和YARN开源调度器作了对比分析，如表2所示： 表2 对比分析 领域 YARN开源调度器 Superior Scheduler 多租户调度 在同构集群上，只能选择容量调度器（Capacity Scheduler）或公平调度器（Fair Scheduler）两者之一，且集群当前不支持公平调度器（Fair Scheduler）。容量调度器只支持百分比方式配置，而公平调度器只支持绝对值方式。 支持异构集群和多资源池。 支持预留，以保证直接访问资源。 数据位置感知调度 从节点到作业的调度策略导致降低数据本地化命中率，潜在影响应用的执行性能。 从作业到节点的调度策略。可具有更精确的数据位置感知，数据本地化调度的作业命中率比较高。 基于机器负载的均衡调度 不支持 Superior Scheduler在调度时考虑机器的负载和资源分配情况，做到均衡调度。 租户内多用户公平调度 不支持 租户内用户的公平调度，支持关键字default、others。 作业等待原因 不支持 作业等待原因信息可显示为什么作业需等待。 综上所述，Superior Scheduler是一个高性能调度器，拥有丰富的调度策略，在功能、性能、资源利用率和扩展性方面都优于Capacity Scheduler。

YARN的权限控制 Hadoop YARN的权限机制是通过访问控制列表（ACL）实现的。按照不同用户授予不同权限控制，主要介绍下面两个部分： 集群运维管理员控制列表（Admin Acl） 该功能主要用于指定YARN集群的运维管理员，其中，MRS集群管理员列表由参数“yarn.admin.acl”指定。集群运维管理员可以访问ResourceManager WebUI，还能操作NodeManager节点、队列、NodeLabel等，但不能提交任务。 队列访问控制列表（Queue Acl） 为了方便管理集群中的用户，YARN将用户/用户组分成若干队列，并指定每个用户/用户组所属的队列。每个队列包含两种权限：提交应用程序权限和管理应用程序权限（比如终止任意应用程序）。 开源功能： 虽然目前YARN服务的用户层面上支持如下三种角色： 集群运维管理员 队列管理员 普通用户 但是当前开源YARN提供的WebUI/RestAPI/JavaAPI等接口上不会根据用户角色进行权限控制，任何用户都有权限访问应用和集群的信息，无法满足多租户场景下的隔离要求。 增强： 安全模式下，对开源YARN提供的WebUI/RestAPI/JavaAPI等接口上进行了权限管理上的增强，支持根据不同的用户角色，进行相应的权限控制。 各个角色对应的权限如下： 集群运维管理员：拥有在YARN集群上执行管理操作（如访问ResourceManager WebUI、刷新队列、设置NodeLabel、主备倒换等）的权限。 队列管理员：拥有在YARN集群上所管理队列的修改和查看权限。 普通用户：拥有在YARN集群上对自己提交应用的修改和查看权限。

支持CPU硬隔离 YARN无法严格控制每个container使用的CPU资源。在使用CPU子系统时，container可能会超额占用资源。此时使用CPUset控制资源分配。 为了解决这个问题，CPU将会被严格按照虚拟核和物理核的比例分配至各个container。如果container需要一整个物理核，则分配给它一整个物理核。若container只需要部分物理核，则可能发生几个container共享同一个物理核的情况。下图为CPU配额示例，假定虚拟核和物理核的比例为2:1。 图4 CPU配额