ambari 维护模式及reset API 操作

Ambari 提供的 Maintenance Mode，是为了让用户在调试或者维护 Service 的时候，抑制不必要的告警（Alert）信息，以及避免批量操作的影响。对 Maintenance Mode 来说，有几个不同级别的设置，分别是 Service Level，Host Level，以及 Component Level。三种级别之间存在着覆盖关系。下面我会举几个例子来详细说明 Maintenance Mode 的应用场景。另外注意，在 Ambari 的 WEB GUI 上面会用一个照相机的图标，标记打开 Maintenance Mode 的模块、机器或者 Service。

Component Level（模块级别）

在 Component 页面里，如果用户对某一个 Component（模块）打开了维护模式，对该模块会有两种影响。其一，对于该机器的该模块不再受批量操作的控制；其二，抑制该机器该模块告警信息的产生。

例如，对机器 zwshen86 的 DataNode 模块打开维护模式，那么当用户从 Host Action 中关闭所有 DataNode 的时候，该机器的 DataNode 就不会被关闭。这是因为关闭 DataNode 的批量操作会直接越过 zwshen86。图 10 中可以看到 zwshen86 不在执行的序列。并且 zwshen86 的 DataNode 不会产生任何新的告警。

图 9. 确认批量操作页面
<ignore_js_op>

图 10. 关闭 DataNode 进度页面
<ignore_js_op>

Host Level（机器级别）

对 Host 级别的维护模式来说，就是打开了该机器所有模块的维护模式。操作起来也很简单，在 Hosts 页面中勾选完机器，然后在 Host Actions 里面选择“Turn On Maintenance Mode”即可。如果该机器已经有告警信息，当 Maintenance Mode 打开后，告警信息会被屏蔽，并且抑制新告警信息的产生。所有的批量操作都会越过该机器。

图 11. Host 打开 Maintenance Mode 之前
<ignore_js_op>

图 12. Host 打开 Maintenance Mode 之后
<ignore_js_op>

Service Level（服务级别）

对 Service 级别的维护模式来说，就是打开一个 Service 所有 Component 的维护模式。由于 Service 可能部署在多台机器，也就相当于用户在多个机器打开 Service Component 的维护模式。这样一来，这个 Service 就不会产生任何新的告警。当用户重启集群所有 Service 的时候，该 Service 会越过这个批量操作。当用户重启一个机器的所有 Component 的时候，该 Service 的 Component 也会被越过。下图是对 HDFS 打开维护模式的示例。

图 13. Service 打开 Maintenance Mode 之前
<ignore_js_op>

图 14. Service 打开 Maintenance Mode 之后
<ignore_js_op>

Ambari 应用举例（快速搭建 Spark on YARN 的集群）

HDP2.2 的 Stack 已经支持了 Spark。但是 metainfo 中的版本还是 1.2.1，这个版本已经很老了（Spark1.4.0 已经发布）。目前安装的 Ambari 2.0.1 和 HDP 2.2 的 Stack，很多时候也无法正常的安装 Spark。原因在于 HDP 的 repository 文件无法找到 Spark 的安装包。用户可以在搭建好的 Ambari 环境中，登录到任一个 Agent 机器，执行如下的命令。

[Plain Text] 纯文本查看复制代码

1	`yum list \| grep spark`

如果看不到 Spark 的 rpm 包，就代表无法正常的通过 Ambari 建立 Spark 集群。用户可以到 HortonWorks 的 repository 服务器上下载最新 HDP 2.2 的更新 repo 文件。我的下载的 repo 内容如下：

#VERSION_NUMBER=2.2.4.4-16

[Plain Text] 纯文本查看复制代码

[HDP-2.2.4.4]
name=HDP Version - HDP-2.2.4.4
baseurl=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4
gpgcheck=1
gpgkey=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4/
                                          RPM-GPG-KEY/RPM-GPG-KEY-Jenkins
enabled=1
priority=1
 
 
[HDP-UTILS-1.1.0.20]
name=HDP Utils Version - HDP-UTILS-1.1.0.20
baseurl=http://public-repo-1.hortonworks.com/HDP-UTILS-1.1.0.20/repos/centos6
gpgcheck=1
gpgkey=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4/
                                        RPM-GPG-KEY/RPM-GPG-KEY-Jenkins
enabled=1
priority=1

将上面的内容拷贝到 Agent 机器的 HDP_up.repo 中，并放入文件夹/etc/yum.repos.d（不能复制到已有 HDP.repo 中，否则会被覆盖掉），就可以通过 yum list 看到 Spark 的 rpm 包了。在 Github 中，我们可以发现 HDP2.3 已经配置 Spark 的版本为 1.3.1 了。

图 15. HDP2.3 已经配置 Spark 的 1.3.1 版本
<ignore_js_op>

了解了以上的背景知识，就可以开始在 Ambari 上增加 Spark 这个 Service 了（这里只简单说明，具体的 Add Service 步骤，可以阅读《Ambari——大数据平台的搭建利器》）。

如果之前了解过 Spark，就会发现 Ambari 部署的 Spark 集群的模式是 Spark on YARN。这也是为什么在 Add Spark 的时候，Ambari 会提示要选择依赖的 YARN。下图是 Ambari、YARN 与 Spark 的层级结构。

图 16. Ambari&YARN&park 结构示意图
<ignore_js_op>

搭建好 Spark 之后，我们就可以在 Ambari 的 Dashboard 看到 Spark 的 Service。

Ambari 常用的 REST API 介绍

Ambari 借鉴了很多成熟分布式软件的 API 设计。Rest API 就是一个很好地体现。通过 Ambari 的 Rest API，可以在脚本中通过 curl 维护整个集群。并且，我们可以用 Rest API 实现一些无法在 Ambari GUI 上面做的操作。下面是一些实例。

实例 1，通过 API 卸载已安装的 Service

目前 Ambari 不支持在 GUI 上面卸载已安装的 Service。所以当一个 Service 不再需要的时候，用户没法删除掉该 Service。幸运的是 Ambari 提供了 DELETE 的 Rest API，我们可以通过该 API 来删除 Ambari 中 Service。不过这里需要注意，这个方法只是从 Ambari Service 中删除了 Service。这样一来，Ambari 的 GUI 界面中不再显示这个 Service。但是 Service 本身还安装在 Agent 所在的机器。如果用户需要彻底的清除掉这个 Service，仍需要手工的到每个机器卸载（例如，在每个机器执行 yum erase）。

这里我以删除 Storm 为例。卸载之前，需要确认是否停掉了该 Service。我们通过 GET 方法来得到这个结果（这里当然也可以直接从 GUI 上面看到 Service 状态）。具体的命令如下：

[Plain Text] 纯文本查看复制代码

1 2	`curl -u admin:admin -H "X-Requested-By: ambari" -X GET` `http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM`

命令中的 zwshen86 为 Ambari Server 的机器名（端口默认为 8080），bigdata 为 cluster 名字，STORM 为 Service 的名字。

在返回的报文中，可以看到 State 字段。如果是 INSTALLED，代表这个 Service 已经是停掉的状态。我们可以继续删除步骤。如果不是 INSTALLED，则需要先停掉这个 Service，可以从 WEB 上操作，也可以用 Rest API。

图 17. Get 返回的结果
<ignore_js_op>

用 Rest API 停掉 Service 的命令格式如下，有兴趣的朋友可以尝试一下。

[Plain Text] 纯文本查看复制代码

curl -u admin:admin -H "X-Requested-By: ambari" -X PUT -d '{"RequestInfo":
        {"context":"Stop Service"},"Body":{"ServiceInfo":{"state":"INSTALLED"}}}' 
        http://AMBARI_SERVER_HOST:8080/api/v1/clusters/c1/services/SERVICE_NAME

执行如下命令删除 STORM：

[Plain Text] 纯文本查看复制代码

1 2	`curl -u admin:admin -H "X-Requested-By: ambari" -X` `DELETE http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM`

执行完成后，Storm 就从 Ambari 的 Service 里面删掉了，但是 Storm 的 package 还存在于机器。

图 18. Storm 的 RPM 包
<ignore_js_op>

如果需要彻底清除掉 Storm 的 package，则需要到各个 Agent 机器执行如下命令。

[Plain Text] 纯文本查看复制代码

1	`yum erase“storm_2_2*”`

执行完后，这个 Service 就被彻底的清除掉了。

实例 2，获取 Service 的 Component 和 Host 列表

上个实例中，让用户登录到每个机器去执行 yum 卸载安装包，其实是不太现实的。一般我们会写一个脚本先通过 curl 调用 GET 方法，先获取到 Service 的 Component 列表，然后再调用 GET 方法，获取 Component 的机器列表，接着调用 DELETE 从 Ambari 中删除 Service。最后脚本通过 SSH 登录到各个 Agent 机器上执行 yum 卸载安装包。脚本示例代码如下（该脚本只能在 Ambari Server 上执行，因为 Ambari Server 有无密码登录所有 Agent 机器的权限）。

[Plain Text] 纯文本查看复制代码

#!/bin/sh
GetHostList()
{
 curl -u admin:admin -H "X-Requested-By: ambari" -X GET
 http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE/components/$1
 2>/dev/null |grep host_name|awk -F: '{print $2}'|sed 's/"//g' >> temp_host_list
}
 
GetServiceComponent()
{
 curl -u admin:admin -H "X-Requested-By: ambari" -X GET
 http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE
 2>/dev/null | grep "component_name" > ./temp_component_list
 sed -i 's/"//g' ./temp_component_list
 sed -i 's/,//g' ./temp_component_list
}
 
 
if [ $# != 4 ]; then
 echo "Usage: $0 Ambari_Server Cluster_Name Service_Name Package_Name"
 exit 1
fi
 
AMBARI_HOST=$1
CLUSTER=$2
SERVICE=$3
PACKAGE=$4
 
GetServiceComponent
 
cat ./temp_component_list|while read line
do
 COMPONENT=`echo $line|awk -F: '{print $2}'`
 GetHostList $COMPONENT
done
 
curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE
http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE
 
rm -f ./temp_component_list >/dev/null 2>&1
#delete duplicated lines (duplicated host name)
 
hosts=`cat temp_host_list|sort |uniq`
for host in $hosts
do
 ssh $host "yum erase $PACKAGE"
done
 
rm -f temp_host_list >/dev/null 2>&1

实例 3，通过 API 执行 Service 的命令

这里，我们以调用 API 执行 Service Check 为例。首先需要知道命令的名字，这里每个 Service 的 Check 命令也是不同的。不过 Service Check 是 build-in 的命令，所以有一定的格式可循。

格式大致如下：

[Plain Text] 纯文本查看复制代码

1	`NAME_SERVICE_CHCECK`

只要将 NAME 替换成对应的 Service，就是该 Service 的 Check 命令。以 YARN 为例，执行如下的命令。

[Plain Text] 纯文本查看复制代码

curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '
   {"RequestInfo":{"context":"My YARN Service Check", "command":
   "YARN_SERVICE_CHECK"},"Requests/resource_filters":[{"service_name":"YARN"}]}'
   http://zwshen86:8080/api/v1/clusters/bigdata/requests

执行完后，可以发现在 WEB GUI 上面，就多了一个正在进行的 Operation。如下图：

图 19. Service Check 执行进度
<ignore_js_op>

在这里我们可以发现，这个 Operation 的名字其实就是 context 字段的值。我们在 WEB GUI 上面直接点击 Service Check 的时候，Operation 的名字其实是 JS code 中指定了一个特殊 context。

这里我们也可以指定执行自定义命令（Custom Comand）。以给 Resource Manager 添加的 GetMem 为例。执行如下的命令。

[Plain Text] 纯文本查看复制代码

curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '
   {"RequestInfo":{"context":"Get RM host Mem
Usage","command":"GetMem"},"Requests/resource_filters":[{"service_name":
   "YARN","component_name":"RESOURCEMANAGER","hosts":"zwshen86.eng.platformlab.ibm.com"}]}'
   http://zwshen86:8080/api/v1/clusters/bigdata/requests

WEB GUI 的显示如下

图 20. 自定义命令 GetMem 的执行进度
<ignore_js_op>

跟 Service Check 相比，不难看出其中的差异。对于自定义命令，我们需要指定参数 Component 以及 Host。当这两个参数缺失的时候，Ambari 是不会接受这个请求的。

通过这三个简单实例，就可以体会到 Ambari Rest API 的作用。在 Rest API 的基础上，就算脱离了 WEB，我们也可以很好地控制 Ambari。当然，我们也不得不记住很多生涩的参数。因此，大多情况下，只有当 Ambari 的 GUI 不足以完成需求，或者不期望暴露在 GUI 上面的时候，就可以使用 Rest API。有兴趣的读者可以搜索下 Ambari Server 目录所有的 Python 脚本，其实 Ambari 自身很多地方都在用 curl 调用 Rest API。

Ambari 的发展

我们可以到 Ambari 的 Roadmap 页面查看 Ambari 最新 release 的进展，以及未来 Ambari 将会开发怎样的功能。例如现在的 Ambari Server 是存在单点问题的，如果 Server 机器宕机了，就无法恢复整个 Ambari Server 的数据，也就是说无法再通过 Ambari 管理集群。我们可以从 Ambari 的 Roadmap 中看到，Ambari 未来会在 2.2 的 release 中考虑这个问题。