首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

大数据平台的搭建利器之进阶篇(3)

大数据平台的搭建利器之进阶篇(3)

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。
1
2
3
<requiredServices>
<service>HDFS</service>
</requiredServices>




对于 Component 来说,也有一个字段 dependencies。在这个字段定义了 Component 的依赖关系。我以 HBASE 的 HBASE_MASTER 配置为例。可以从示例代码中看到,HBASE_MASTER 需要 HDFS 的 HDFS_CLIENT,以及 ZOOKEEPER 的 ZOOKEEPER_SERVER。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<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. 确认批量操作页面图 10. 关闭 DataNode 进度页面Host Level(机器级别)对 Host 级别的维护模式来说,就是打开了该机器所有模块的维护模式。操作起来也很简单,在 Hosts 页面中勾选完机器,然后在 Host Actions 里面选择“Turn On Maintenance Mode”即可。如果该机器已经有告警信息,当 Maintenance Mode 打开后,告警信息会被屏蔽,并且抑制新告警信息的产生。所有的批量操作都会越过该机器。
图 11. Host 打开 Maintenance Mode 之前图 12. Host 打开 Maintenance Mode 之后Service Level(服务级别)对 Service 级别的维护模式来说,就是打开一个 Service 所有 Component 的维护模式。由于 Service 可能部署在多台机器,也就相当于用户在多个机器打开 Service Component 的维护模式。这样一来,这个 Service 就不会产生任何新的告警。当用户重启集群所有 Service 的时候,该 Service 会越过这个批量操作。当用户重启一个机器的所有 Component 的时候,该 Service 的 Component 也会被越过。下图是对 HDFS 打开维护模式的示例。
图 13. Service 打开 Maintenance Mode 之前图 14. Service 打开 Maintenance Mode 之后
返回列表