Ambari和ClouderManager分析对比

第一章      导论

运维过hadoop集群的人都应该清楚，hadoop生态从安装、配置到后期运维是一个非常艰辛的过程，一般来说安装hadoop可能就需要几天时间，运维一个小型集群同样需要几个人。ambari和cloudera Manager这两个系统，目的就是简化hadoop生态集群的安装、配置，同时提高hadoop运维效率，以及对hadoop集群进行监控。

1.1.   ClouderManager/ambari简述

1.1.1.    Ambari

Ambari是Hortonworks公司开源的Hadoop平台的管理软件，着重于帮助大家管理自己的HDP集群，具备Hadoop组件的安装、管理、运维等基本功能，提供Web UI进行可视化的集群管理，简化了大数据平台的安装、使用难度。

1.1.2.    ClouderManager

Cloudera Manager是cloudera公司的一个产品，着重于帮助大家管理自己的CDH集群，Cloudera Manager是一个拥有集群自动化安装、中心化管理、集群监控、报警功能的一个工具（软件）,使得安装集群从几天的时间缩短在几个小时内，运维人员从数十人降低到几人以内，极大的提高集群管理的效率。

1.2.   手动部署hadoop集群和工具（ClouderManager/ambari）部署的比较：

1.2.1.    手动部署：

（1）  组件选择：采用apache hadoop组件(原生hadoop组件)

（2）  优点：

a)   各个组件完全开源免费。

b)   社区资源活跃。

c)   可以加深对各个组件的理解和掌握。

（3）  缺点：

a)   集群部署：集群部署、安装、配置耗时比较多，通常按照集群需要编写大量的配置文件，分发到每一台节点上，容易出错，效率低下。

b)   版本管理：组件的版本管理比较复杂，在Hadoop生态圈中，组件的选择、使用，比如Hive，Mahout，Sqoop，Flume，Spark，impala,Oozie等等，需要大量考虑兼容性的问题，版本是否兼容，组件是否有冲突，编译是否能通过等。经常会浪费大量的时间去编译组件，解决版本冲突问题。

c)   集群运维：对集群的监控，运维，需要安装第三方的其他软件，如ganglia，nagois等，运维难度较大，同时运维成本比较高。

1.2.2.    工具部署

（1）  组件选择：Ambari + HDP 或 Cloudera Manger + CDH

（2）  优点：

a)   基于稳定版本Apache Hadoop，解决了组件不同版本之间的冲突问题，并应用了最新Bug修复或Feature的patch，在兼容性、安全性、稳定性上有增强。

b)   默认优化了很多参数，如HDFS的snappy压缩。

c)   提供了部署、安装、配置工具，大大提高了集群部署的效率，可以在数个小时内部署好集群。

d)   第三方发行版通常都经过了大量的测试验证，有众多部署实例，大量的运行到各种生产环境。

e)   运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工作简单，有效。

（3）  缺点

a)   免费社区版功能不全，非社区版服务收费。

b)   收费标准：按节点收费，Cloudera每个节点一年4000美元，Hortonworks 每个节点一年1250美元。

第二章       Ambari 概述

2.1   Ambari简介

Ambari是Hortonworks开源的Hadoop平台的管理软件，具备Hadoop组件的安装、管理、运维等基本功能，提供Web UI进行可视化的集群管理，简化了大数据平台的安装、使用难度。

Ambari目前对接安装Hortonworks Data Platform（HDP），即Hortonworks的开源Hadoop，对Apach的Hadoop平台的生产环境部署没有找到实例；对于已经安装了Apach Hadoop或者其他Hadoop平台的，可能不能使用Ambari来管理；

2.2   ambari功能列表

2.2.1操作级别：

（1）Host Level Action（机器级别的操作）

（2）Component Level Action（模块级别的操作）

2.2.2基于角色的用户管理，5种角色：

（1）Cluster User

查看集群和Service的信息，如配置、service状态、健康状态等。Read-only

（2）Service Operator

能够操作Service的生命周期，如启动，停止，也可以进行一些如Rebalance DataNode和YARN refresh的操作

（4）  Service Administrator

在Service Operator的基础上增加了配置service，移动NameNode，启用HA等操作

（5）  Cluster Operator

在Service Administrator的基础上增加了对hosts和components的操作，如增加，删除等

（6）  Cluster Administrator

集群的超级管理员，拥有无上的权利，可以操作任何组件。

2.2.3 Dashboard 监控

（1）Roll Start功能。根据Service的依赖关系，按照一定的顺序启动每个Service。比如HBase依赖HDFS和Zookeeper，Ambari会先启动HDFS和Zookeeper，之后启动HBase。

（2）关键的运维指标（metrics）–metrics 是“度量,指标”的意思

（3）在左侧的 Service 列表,中间部分是 Service 的模块（Component）信息，也就是该 Service 有哪些模块及其数目。右上角有个 Service Action 的按钮，包括service的启动、停止、删除等操作。

（4）Quick links（导向组件原生管理界面） 

• NameNode UI、ResourceManage UI、HBase Master UI
• http://unix191:50070/logs/ HDFS的NameNode的logs
• http://unix192:8088/logs/ YARN的ResourceManage 的logs
• http://unix191:16010/logs/ Hbase的logs

2.3        Alert介绍

（1）Alert 告警级别： 
OK 、Warning、Critical、Unknown、None

（2）Alert 告警类型： 
WEB、Port、Metric、Aggregate 和 Script

表 1. Ambari 中的 Alert 类型对比

类型	用途	告警级别	阀值是否可配置	单位
PORT	用来监测机器上的一个端口是否可用	OK, WARN, CRIT	是	秒
METRIC	用来监测 Metric 相关的配置属性	OK, WARN, CRIT	是	变量
AGGREGATE	用于收集其他某些 Alert 的状态	OK, WARN, CRIT	是	百分比
WEB	用于监测一个 WEB UI（URL）地址是否可用	OK, WARN, CRIT	否	无
SCRIPT	Alert 的监测逻辑由一个自定义的 python 脚本执行	OK, CRIT	否	无

2.4   Hadoop代表组件功能说明

2.4.1 HDFS

• 启动、停止、重启HDFS，也支持HDFS的删除，前提是删除依赖HDFS的其他service
• 高级配置 
  支持对core-site.xml、hdfs-site.xml的高级配置
• 下载配置文件
• 状态查看 
  NameNode和SNameNode的健康状况以及所在的节点、硬盘使用率、块的状态（丢失、冲突的个数）
• 文件查看 
  嵌入了HDFS原生的文件目录查看功能，没有一键上传、下载文件的功能
• 日志查看 
  日志查看可以通过QuickLinks中导向HDFS原生日志查看Web UI界面，没有经过界面的优化，日志查看也没有辅助功能（如检索）
• 移动NameNode、SNameNode
• Rebalancing HDFS 
  使得DataNodes上的块分布均匀
• NameNode UI 
  通过QuickLinks导向HDFS原生UI
• HA 
  一键配置NameNode的高可用，使用JournalNode、NFS为共享存储
• 启动、停止、重启Zookeeper集群
• 状态查看 
  Zookeeper Server和Client的健康状况，所在的节点
• 高级配置 
  zoo.cfg、日志输出格式(log4j的配置)
• 添加Zookeeper Server节点
• 下载配置文件
• 启动HBase集群，启动RegionServer，停止集群，删除HBase集群
• 添加HBase Master节点
• 状态查看 
  HBase Master、RegionServers的状态及其所处节点，master启动时间，平均负载（regions/regionsServer）
• 高级配置 
  HBase Master、RegionServer、Client的内存限制、心跳时间等。可以启用Kerberos（前提是安装该Service），也可以开启Phoenix SQL
• 日志查看 
  日志查看可以通过QuickLinks中导向原生日志查看Web UI界面
• Master UI界面 
  通过QuickLinks导向HDFS原生UI
• Kafka的启动、停止、重启，Brokers的重启，Service的删除
• 高级配置 
  对Kafka Broker、Producer、Consumer的配置。Broker支持连接参数设置、Topic配置、日志配置等，
• 状态查看 
  Broker的状态、所在节点位置，结合Ambari Metrics可以查看更多状态，如Topics、Controller、Replica

2.4.2 Zookeeper

2.4.3 HBase

2.4.5 Kafka

2.5       Ambari总结

Ambari通过HDP将Hadoop的组件进行集成，通过栈的形式提供Service的组合使用，它主要解决的问题如下：

• 简化了部署过程，在HDP栈中支持的Service只需要图形化的安装即可，可以方便的指定master所在的节点，使集群快速运行起来
• 通过Ambari Metrics实现集群状态的监控，并通过集成Grafana进行数据的展示（CPU、内存、负载等）
• Service的高级配置。集群部署之后，可以方便的通过dashboard进行参数的修改（如HDFS的core-site等）
• 快速链接。Ambari提供快速导向Hadoop组件原生管理界面的链接
• 节点的扩展。如HBase Master的增加。
• 可定制的Alert功能。Ambari的报警信息可以自定义，使得用户可以根据自己的需要，设置哪些情况下需要报警，哪些不需要。
• 增值功能。如HDFS的Rebalance DataNode、NameNode的HA等
• Ambari自身的用户管理，基于RBAC赋予用户对Hadoop集群的管理权限。

Ambari并没有对Hadoop组件进行过多的功能集成，如日志分析等，只是提供了安装，配置，启停等功能，尽量保持了跟原生Hadoop组件的隔离性，对于该组件的具体操作，通过Quick Links 直接导向原生的管理界面（如HBase Master UI），它的做法保持了对于Hadoop组件的低侵入性。

第三章 ClouderManager概述

3.1 clouderManager简介

Cloudera Manager是cloudera公司的一个产品，着重于帮助大家管理自己的CDH集群，通过Cloudera Manager统一的UI界面来快速地自动配置和部署CDH和其相关组件，同时Cloudera Manager还提供了各种丰富的可自定义化的监视诊断和报告功能，集群上统一的日志管理功能，统一的集群配置管理和实时配置变更功能，多租户功能，高可用容灾部署功能和自动恢复功能等， 方便企业统一管理和维护自己的数据中心。它细分为免费的Express版本和功能完全并提供众多增值服务的收费版本Enterprise。

3.2 cloudera manager功能简述：

管理：对大数据集群进行管理，如添加、删除节点等操作。

监控：监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控。

诊断：对集群出现的问题进行诊断，对出现的问题给出建议解决方案。

集成：对hadoop的多组件进行整合。

3.3 Cloudera Manager核心组成部分

cloudera manager的核心是管理服务器，该服务器承载管理控制台的Web服务器和应用程序逻辑，并负责安装软件，配置，启动和停止服务，以及管理上的服务运行群集。

Agent：安装在每台主机上。该代理负责启动和停止的过程，拆包配置，触发装置和监控主机。
Management Service：由一组执行各种监控，警报和报告功能角色的服务。
Database：存储配置和监视信息。通常情况下，多个逻辑数据库在一个或多个数据库服务器上运行。例如，Cloudera的管理服务器和监控角色使用不同的逻辑数据库。
Cloudera Repository：软件由Cloudera 管理分布存储库。
Clients：是用于与服务器进行交互的接口：

Admin Console ：基于Web的用户界面与管理员管理集群和Cloudera管理。
API ：与开发人员创建自定义的Cloudera Manager应用程序的API。

 

第四章 hadoop生态圈原生的webUI

4.1 原生webUI简介

Apache hadoop 原生组件的webUI界面可以查看组件的运行状态，历史日志，内存消耗，硬盘消耗情况等。

相比clouderManager和ambari：

（1）原生的webUI不能执行服务的启停操作

（2）各个组件之间的webUI界面是相互独立的

（3）大部分功能仅限于read-only的操作，无法执行其它操作

（4）很难统一监控整个集群的运行情况

第五章 Ambari和ClouderManager的比较

 

组件	Ambari	ClouderaManager
开发公司	Hortonworks公司	Cloudera公司
部署方式	Ambari + HDP	Cloudera Manger + CDH
生产运行情况	比较稳定	很稳定
使用情况	市场占用率较高	市场占用率高
开源情况	产品开源，服务好像收费	有免费版和商业版
维护	依靠社区力量	cloudera做了一些定制开发，自行维护或打patch会离社区越来越远
配置版本控制和历史记录	支持	不支持
二次开发	支持	不支持
集成	支持	no (不支持redis、kylin、es)
权限控制	ranger(相对简单)	sentry(复杂)
视图定制	支持创建自己的视图，添加自定义服务	不支持

 

第六章 版本选择分析

当我们决定是否采用某个软件用于开源环境时，通常需要考虑以下几个因素：

（1）是否为开源软件，即是否免费。

（2） 是否有稳定版，这个一般软件官方网站会给出说明。

（3） 是否经过实践验证，这个可通过检查是否有一些大点的公司已经在生产环境中使用知道。

（4） 是否有强大的社区支持，当后期出现一个问题时，能够通过社区、论坛等网络资源快速获取解决方法。

第七章 Ambari补充资料

Ambari是hadoop分布式集群配置管理工具，是由hortonworks主导的开源项目。它已经成为apache基金会的顶级项目，已经成为hadoop运维系统中的得力助手，引起了业界和学术界的关注。

Ambari采用的不是一个新的思想和架构，也不是完成了软件的新的革命，而是充分利用了一些已有的优秀开源软件，巧妙地把它们结合起来，使其在分布式环境中做到了集群式服务管理能力、监控能力、展示能力。这些优秀开源软件有：

• 在agent端，采用了puppet管理节点;
• 在Web端，采用了ember.js作为前端的MVC构架和NodeJS相关工具，用handlebars.js作为页面渲染引擎，在CSS/HTML方面还用了Bootstrap 框架;
• 在Server端，采用了Jetty, Spring，Jetty，JAX-RS等;
• 同时利用了Ganglia，Nagios的分布式监控能力。

Ambari架构采用的是Server/Client的模式，主要由两部分组成：ambari-agent和ambari-server。ambari依赖其它已经成熟的工具，例如其ambari-server 就依赖python，而ambari-agent还同时依赖ruby, puppet，facter等工具，还有它也依赖一些监控工具nagios和ganglia用于监控集群状况。其中：

1. puppet是分布式集群配置管理工具，也是典型的Server/Client模式，能够集中式管理分布式集群的安装配置部署，主要语言是ruby。
2. facter是用python写的一个节点资源采集库，用于采集节点的系统信息，例如OS信息，主机信息等。由于ambari-agent主要是用python写的，因此用facter可以很好地采集到节点信息。

一、Ambari系统架构

除了ambari-server和ambari-agent，ambari还提供一个界面清亮的管理监控页面ambari-web，这些页面由ambari-server提供。ambari-server开放了REST API，这些API也主要分两大类，其中一类为ambari-web提供管理监控服务，另一类用于与ambari-agent交互，接受ambari-agent向ambari-server发送的心跳请求。下图是Ambari的系统架构。其中master模块接受API和Agent Interface的请求，完成ambari-server的集中式管理监控逻辑，而每个agent节点只负责所在节点的状态采集及维护。

 

二、Ambari-Agent内部架构

ambari-agent是一个无状态的。其功能主要分两部分：

1. 采集所在节点的信息并且汇总发心跳汇报给ambari-server;
2. 处理ambari-server的执行请求。

因此它有两种队列：

1. 消息队列MessageQueue，或为ResultQueue。包括节点状态信息（包括注册信息）和执行结果信息，并且汇总后通过心跳发送给ambari-server;
2. 操作队列ActionQueue。用于接收ambari-server返回过来的状态操作，然后能过执行器按序调用puppet或python脚本等模块完成任务。

 

三、Ambari-Server内部架构

ambari-server是一个有状态的，它维护着自己的一个有限状态机FSM。同时这些状态机存储在数据库中，前期数据库主要采用postgres。如下图所示，server端主要维护三类状态：

1. Live Cluster State：集群现有状态，各个节点汇报上来的状态信息会更改该状态;
2. Desired State：用户希望该节点所处状态，是用户在页面进行了一系列的操作，需要更改某些服务的状态，这些状态还没有在节点上产生作用;
3. Action State：操作状态，是状态改变时的请求状态，也可以看作是一种中间状态，这种状态可以辅助Live Cluster State向Desired State状态转变。

 

Ambari-server的Heartbeat Handler模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护着该节点的状态，并且把返回的操作结果信息返回给Action Manager去做进一步的处理。

Coordinator模块又可以称为API handler，主要在接收WEB端操作请求后，会检查它是否符合要求，stage planner分解成一组操作，最后提供给Action Manager去完成执行操作。

因此，从上图就可以看出，Ambari-Server的所有状态信息的维护和变更都会记录在数据库中，用户做一些更改服务的操作都会在数据库上做一些相应的记录，同时，agent通过心跳来获得数据库的变更历史。