Ambari 中 Service 之间的依赖关系
在 Hadoop 的生态圈中，一个完整的解决方案往往是需要几个 framework 共同的协作才能完成的。所以 Ambari 必须支持定义 Service 之间、Component 之间的依赖关系，以及 Component 状态和 Action 之间的依赖关系。
对于 Service 和 Component 之间的依赖关系，可以在 metainfo.xml 中定义。例如打开 YARN 的 metainfo.xml，就可以看到在 YARN 的 Service 段，有一个 requiredService 的字段。每个 Service 段底下，可以用这个字段来定义一个 Service 依赖哪些其他的 Service。YARN 所示配置如下，代表 YARN 需要 HDFS。
<requiredServices> <service>HDFS</service> </requiredServices>
对于 Component 来说，也有一个字段 dependencies。在这个字段定义了 Component 的依赖关系。我以 HBASE 的 HBASE_MASTER 配置为例。可以从示例代码中看到，HBASE_MASTER 需要 HDFS 的 HDFS_CLIENT，以及 ZOOKEEPER 的 ZOOKEEPER_SERVER。
<component> <name>HBASE_MASTER</name> <displayName>HBase Master</displayName> <category>MASTER</category> <cardinality>1+</cardinality> <versionAdvertised>true</versionAdvertised> <dependencies> <dependency> <name>HDFS/HDFS_CLIENT</name> <scope>host</scope> <auto-deploy> <enabled>true</enabled> </auto-deploy> </dependency> <dependency> <name>ZOOKEEPER/ZOOKEEPER_SERVER</name> <scope>cluster</scope> <auto-deploy> <enabled>true</enabled> <co-locate>HBASE/HBASE_MASTER</co-locate> </auto-deploy> </dependency> </dependencies> </component>
对于 Service 和 Component 的依赖，还是比较容易发现和理解的。但是对于 Component 状态以及 Action 之间的依赖关系，就比较难理解了。Ambari 的 Service 目录中，存在很多个叫做 role_command_order.json 的文件。在这个文件中定义了状态之间以及 Action 的依赖。在 resource 目录下的 role_command_order.json 定义着全局的的依赖。每个 Stack 目录下也会存在 role_command_order.json。相同的配置，Stack 下面的会覆盖全局的（overwrite）。对于不同的配置，Ambari 会拼接在一起（merge）。高版本的 Stack 会继承低版本的配置。相同的也会 overwrite，不同的也会 merge。
Ambari 的维护模式（Maintenance Mode）介绍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. 确认批量操作页面
对 Host 级别的维护模式来说，就是打开了该机器所有模块的维护模式。操作起来也很简单，在 Hosts 页面中勾选完机器，然后在 Host Actions 里面选择“Turn On Maintenance Mode”即可。如果该机器已经有告警信息，当 Maintenance Mode 打开后，告警信息会被屏蔽，并且抑制新告警信息的产生。所有的批量操作都会越过该机器。
图 11. Host 打开 Maintenance Mode 之前
对 Service 级别的维护模式来说，就是打开一个 Service 所有 Component 的维护模式。由于 Service 可能部署在多台机器，也就相当于用户在多个机器打开 Service Component 的维护模式。这样一来，这个 Service 就不会产生任何新的告警。当用户重启集群所有 Service 的时候，该 Service 会越过这个批量操作。当用户重启一个机器的所有 Component 的时候，该 Service 的 Component 也会被越过。下图是对 HDFS 打开维护模式的示例。
图 13. Service 打开 Maintenance Mode 之前
