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能够很好地采集到节点信息。

1、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节点只负责所在节点的状态采集及维护。

 

2、Ambari-Agent内部架构

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

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

所以它有两种队列：

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

 

3、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经过心跳来得到数据库的变动历史。