Ambari Agent Command 处理流程

一、概述：

根据 Ambari Server 架构 文章中的介绍，由于 Ambari Server 和 Ambari Agent 之间是通过 HTTP 短连接进行通信，所以 Server 无法把需要执行的 Command，直接推送给 Agent，而是需要把命令存储在 ActionQueue 中，

然后 Agent 通过定期发送 Heartbeat 请求，把 Command 拉过去执行，并通过下次的 Heartbeat 请求，返回执行结果。下面简单分析一下 Command 的处理过程。

二、Agent Command 类型

• REGISTRATION_COMMAND：注册指令，当 Server 发现 节点未注册、节点当前状态为 HEARTBEAT_LOST、Agent 上传的主机状态 Server 处理失败的时候，会要求 Agent 重试进行注册。
• STATUS_COMMAND：汇报状态指令，Server 端有个定时任务 HeartbeatMonitor 默认1分钟执行一次，要求 Agent 汇报当前的组件状态、当前使用的配置版本等信息。
• EXECUTION_COMMAND：执行任务指令，当我们操作服务/组件的时候，比如：安装、启动、停止、更新配置等，就会发送这个指令。
• CANCEL_COMMAND：取消任务指令，中断一个操作。
• ALERT_DEFINITION_COMMAND：更新 Alert 定义指令，当我们修改了 Alert 信息、增删组件、删节点的时候，会发送这个指令。
• ALERT_EXECUTION_COMMAND：立即执行一个 Alert。

上面这些指令，除了 REGISTRATION_COMMAND，其他指令都需要先添加到 ActionQueue 中，Server 处理心跳逻辑时，如果发现 Agent 需要重新注册，会立即生成 REGISTRATION_COMMAND，要求 Agent 重新注册。

下面着重介绍一下 EXECUTION_COMMAND，可以看出来这个指令使用频率最高、最重要，处理逻辑也是最复杂的，理解了这个指令，其他指令的处理逻辑大同小异。

三、EXECUTION_COMMAND 处理流程

时机：用户触发了一个服务/组件的操作

服务端处理逻辑：

(1) 计算依赖，生成 Command，并保存到数据库
(2) 定期从数据库加载 Command，并添加到 ActionQueue
(3) 心跳逻辑：
　　· 把 ActionQueue 中的所有 Command 下发给 Agent
　　· 根据 Agent 的汇报，处理 Command 执行结果

1、计算依赖

如下图所示：

• 一个 Request 包含多个 Stage
• 一个 Stage 包含多个 Task
• 一个 Task 对应一条 Command

需要注意的是 Stage 之间有依赖关系，必须前一个 Stage 运行完，才能开始下一个 Stage；而多个 Task 可以并行执行。

 

Stage之间的依赖关系是使用有向无环图（DAG）计算出来的，下面简单介绍一下DAG：

• 节点：要执行的任务
• 有向边：依赖关系，A 到 B 的箭头，代表 B 依赖 A
• 无环：指的是没有循环依赖

举一个启动 HDFS 的例子：

在 role_command_order.json 文件中定义依赖关系：  "DATANODE-START" : ["NAMENODE-START"]

生成 Command 并保存到数据库

表关系如下图：

 2、定期从数据库中载入 Command 添加到 ActionQueue

这段逻辑在 ActionScheduler 类中，总结一下：

(1) 处理被取消的 Request

• 未下发的 Command，服务端直接改状态
• 已下发的 Command，生成 CANCEL_COMMAND

(2) 从数据库载入 Command 并添加到 ActionQueue

• 任务是否需要独占运行
• 同一个 Request，只能有一个 Stage 运行
• 超时逻辑
• 重试逻辑
• 前一个 Stage 运行失败，后边 Stage 直接取消
• 满足条件的 Command 添加到 ActionQueue