1. 关于Hadoop YARN

1.1 Hadoop YARN基本情况

Hadoop YARN是一个分布式的资源管理和任务调度的框架，其架构如下图所示（图片来源：Apache Hadoop 3.3.1 – HDFS Architecture
)：

YARN采用的是主从架构，RM为主节点（Master）、NM为从节点（Worker）。RM负责集群的组织协调，NM负责执行RM分配的工作。为了更好的理解YANR架构，我们通过下图的应用提交流程来理解各个组件的职责。

yarnflow.png

1. 首先Client向RM发起应用提交请求
2. RM审核通过之后，会基于调度策略协调相应的NM提供一个1号Contaienr启动运行该应用的AM
3. AM启动后会向RM进行注册
4. 在向AM注册的同时，AM还可以向RM申请额外的资源执行应用所需要执行的任务，比如Flink应用会向RM申请资源运行Flink的TaskManager，而AM则是作为Flink集群的JobManager。Spark应用则会向RM申请资源启动TaskExecutor进程。
5. RM结合当前集群的资源使用情况，判定可以陪陪资源后，会同样基于调度策略协调相应的NM创建相应的Container运行AM请求需要执行的进程。
6. 分配的应用Container会于AM建立通信
7. Client可以直接同AM进行通信以获取状态、进度等信息
8. 当应用执行完成之后，AM向RM发送停止应用的通知，则资源会被回首。

通过上述流程，可以总结各个组件的职责：

• RM：
  • 接收Client的应用提交请求
  • 协调 NM 创建AM容器进程
  • 接收来自AM的资源分配请求
  • 接收来自AM及NM的状态报告
• NM：
  • 基于RM的指示提供Container运行应用
  • 将NM当前的状态以心跳的方式发送给RM
• AM：
  • 向RM申请资源执行并管理相应的Container
  • 向RM汇报应用状态
  • 与Client通信
• Container：
  • 资源的提供形式，负责提供计算能力
• Client：
  • 与RM通信，提交应用请求

基于职责单一的涉及原则，RM内部包含两个组件：ApplicationManager和Scheduler。ApplicationManager负责管理提交到Yarn的应用，并监控AM状态，如果AM挂掉，需要负责将其重新拉起（基于策略）。Scheduler则负责资源调度，YARN提供了多种类型的Scheduler，包括默认的CapacityScheduler和FairScheduler。

1.2 YARN相关执行命令

1.2.1 启停yarn集群

• 启动：start-yarn.sh
• 停止：stop-yarn.sh

1.2.2 启停RM

• 启动：yarn --daemon start resourcemanager
• 停止：yarn --daemon stop resourcemanager

1.2.3 启停NM

• 启动：yarn --daemon start nodemanager
• 停止：yarn --daemon stop nodemanager

1.2.4 启停timeline server

• 启动：yarn --daemon start timelineserver
• 停止：yarn --daemon stop timelineserver

1.3 YARN的关键配置

1.3.1 yarn-site.xml

HA相关配置

RM具有单点故障问题，可以通过开启HA配置，通过主备（热备）架构实现RM的HA。RM提供了基于ZK的异常恢复机制，在主节点发生故障之后，能够自动实现主到备的切换。

RM Recovery

RM Restart机制能够实现RM的下线对客户无感，实现RM重新上线后，能够自动恢复在下线之前的应用的状态。

RM Restart的有两种策略：一种策略会将应用kill掉然后再拉起；另一种策略则不需要kill应用，而是通过重新获取NM及AM相关信息，从而重新构建RM的元数据。

资源容量配置

属性	值	说明
yarn.nodemanager.resource.memory-mb	xxx	配置NodeManager可分配的物理内存大小，如果配置为-1，同时${yarn.nodemanager.resource.detect-hardware-capabilities}为true，则YARN进行自动检测，默认默认为8G
yarn.nodemanager.vmem-pmem-ratio	2.1	配置虚拟内存与物理内存的占比，用于约束容器占用的虚拟内存的大小，即{yarn.nodemanager.vmem-pmem-ratio}
yarn.nodemanager.container-executor.class	org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor	YARN支持三种内存控制模型：轮询机制（DefaultContainerExecutor)、通过CGroups进行严格内存控制以及通过CGoup进行弹性内存控制。其中轮询机制是一种遗留特性，是通过定期检视每个container的内存使用情况来决定是否执行kill操作的，这个官方文档说如果存在delay可能导致node挂掉；而第二种则是利用Linux的内核特性提供的OOM killer对超出内存限制的容器进行回收；第三种弹性内存机制则不会限制单个container的内存超用，只有当整个NM的内存使用情况超过了{yarn.nodemanager.vmem-pmem-ratio}两个参数的限制时会向NM发送通知，然后由NM对Container执行回收。默认的回收策略是回收最近的一个超用的container或者最近启动的container。
yarn.nodemanager.resource.memory.enforced	true	开启CGroups内存严格检查
yarn.nodemanager.pmem-check-enabled	true	开启物理内存检查
yarn.nodemanager.resource.cpu-vcores	xxx	配置NM能够使用的虚拟核数

资源调度配置

超时时间控制

日志

YARN提供了日志聚合能力，能够将YARN上运行的Container产生的日志收集到指定位置，这样便于日志的查看。另外，YARN还提供了Timeline Server，提供了应用运行历史的查看及运行日志的链接。YARN提供了两个版本的Timeline Server。V1版本具有单点问题，V2解决了单点问题，但是需要依赖HBASE，而且依赖的HBase版本比较混乱，因此我们在实际验证中，没有进行验证，选择保留应用Timeline Server V1版本。虽然V1有单点问题，但是实际上应用运行的日志已经收集到了HDFS上，也就是日志数据是可靠的，即使Timeline Server V1服务挂掉了，我们依然可以基于一定规则找到相应的日志数据。
关于日志的配置如下。

Label

Node Label能够实现将YARN节点进行分区管理，从而实现在提交应用时指定在哪里执行。通过Node Label同时能够实现ACL控制，以及与调度队列组合实现资源占比的配比。

在我们这个项目中，我们期望通过Node Label来实现在指定机器上执行Flink Job，但是经过验证后发现，虽然Node Label能够满足这种需要，但是由于我们的任务是long running的实时JOB，需要保证所有JOB必须能够运行起来，而如果给Node打上了Label，如果Label相关分区资源不足，虽然整个集群还有剩余资源，但是该应用还是没办法正常启动，所以在实际结论上，不会使用Label。

一下是关于Label的一些配置

Label相关的命令：

Add cluster node labels list:

• Executing yarn rmadmin -addToClusterNodeLabels "label_1(exclusive=true/false),label_2(exclusive=true/false)" to add node label.
• If user don’t specify “(exclusive=…)”, exclusive will be true by default.
• Run yarn cluster --list-node-labels to check added node labels are visible in the cluster.

Remove cluster node labels:

• To remove one or more node labels, execute the following command: yarn rmadmin -removeFromClusterNodeLabels "<label>[,<label>,...]". The command argument should be a comma-separated list of node labels to remove.
• It is not allowed to remove a label which has been associated with queues, i.e., one or more queues have access to this label.
• To verify if specified node labels have been successfully removed, run yarn cluster --list-node-labels.

Configuring nodes to labels mapping in Centralized NodeLabel setup

• Executing yarn rmadmin -replaceLabelsOnNode “node1[:port]=label1 node2=label2” [-failOnUnknownNodes]. Added label1 to node1, label2 to node2. If user don’t specify port, it adds the label to all NodeManagers running on the node. If option -failOnUnknownNodes is set, this command will fail if specified nodes are unknown.

其他

1.3.2 capacity-scheduler.xml

YARN提供了两种Scheduler：CapacityScheduler和FairScheduler。由于本次验证的Flink on YARN的场景是实时运行的Long-running的JOB，特点是必须保证所有的任务都能启动起来，所以核心逻辑还是需要底层硬件资源池能够cover住这些任务，所以跟调度策略不太匹配。本次只验证了一些简单的CapacityScheduler配置，如下。