0895-Cloudera Manager的工作原理

1.Cloudera Manager词汇

下图说明了Cloudera Manager的基本名词和关系：

一个Deployment代表了全部，包括Cluster。Cluster是一些运行相同版本CDH的Host的集合，不同的Host又会划给不同的Rack。Service是特定系统的实例，跨越了许多Role，每个Role都会被分配给一个Host。角色配置组是一次配置多个角色的一种方式，这也是常见的情况。

Configuration被附加到多个上下文，并且可以酌情级联。例如存储DataNode日志文件的路径通常附加到“Role Config Group”，但它也可能作为覆盖附加到特定角色。

“服务”和“角色”容易造成混淆的地方就跟很多编程语言中的class-type和class-instance一样，比如“string”可能表示类型（“java.lang.String”）或该类型的实例（“hey there”）。我们有时说“角色”来表示类型（“RegionServer”）或实例（“机器17上的RegionServer”）。当有歧义时，我们尝试使用“角色类型”和“角色实例”来区分这两种情况。服务（“HBase”或“生产集群上的HBase服务”）也会有同样的问题。

始终记住一个原则可以帮助理解这个事：传统系统是多个服务运行在一个主机上，而在 Hadoop 和其他分布式系统中是单个服务运行在多个主机上。

2.Agent/Server架构

Cloudera Manager运行在一台服务器上，称作Cloudera Manager Server，以前也叫“SCM Server”和“CMF Server”，这台服务器上包括一个Web UI Server以及管理CDH的应用程序逻辑。与安装CDH、配置服务以及启动和停止服务相关的一切都由 Cloudera Manager Server管理。

Cloudera Manager Agent安装在每台托管主机上。它们负责启动和停止Linux进程、解包配置、触发各种安装路径以及监控主机。

3.心跳

心跳构成Cloudera Manager中的主要通信通道，默认情况下Agent每15秒向Server发送一次心跳，以知道自己该做什么。为了减少用户延迟，也有一种优化是可以在事情发生变化时加快心跳。

Agent在心跳时说:"Here's what I'm up to!" Server在其响应说说:"Here’s what you should be doing." Agent和Server最终都会进行一些协调：例如，如果用户通过UI停止了服务，Agent将停止相关进程；如果进程启动失败，Server会将启动命令标记为失败。

4.Agent进程Supervision详解

Agent的主要职责之一是启动和停止进程。当Agent看到一个新进程从心跳进来时，代理会在/var/run/cloudera-scm-agent中为其创建一个目录并解压缩配置。这是很重要的一点：Cloudera Manager进程永远不会单独运行。进程不仅仅是exec()的参数 - 它还包括配置文件、需要创建的目录和其它信息（如cgroups设置）。这样就永远不会有任何关于配置文件过期的问题。

为每个进程提供自己的私有执行和配置环境允许我们独立控制每个进程，这对于一些更为复杂的配置场景至关重要。以下是一个唯一命名的示例，进程879目录的内容：

$ tree -a /var/run/cloudera-scm-agent/process/879-hdfs-NAMENODE/  /var/run/cloudera-scm-Agent/process/879-hdfs-NAMENODE/  ├── cloudera_manager_Agent_fencer.py  ├── cloudera_manager_Agent_fencer_secret_key.txt  ├── cloudera-monitor.properties  ├── core-site.xml  ├── dfs_hosts_allow.txt  ├── dfs_hosts_exclude.txt  ├── event-filter-rules.json  ├── hadoop-metrics2.properties  ├── hdfs.keytab  ├── hdfs-site.xml  ├── log4j.properties  ├── logs  │   ├── stderr.log  │   └── stdout.log  ├── topology.map  └── topology.py

要实际启动和停止该过程，我们依赖于一个名为supervisord的开源系统。它负责重定向日志文件、通知我们进程失败、设置正确的用户等等。

Cloudera Manager将Hadoop的“客户端配置”放在/etc/hadoop/conf中，同样对于HBase和Hive服务则是放在/etc/hbase/conf和/etc/hive/conf中。默认情况下如果你要运行的应用程序需要与Hadoop通信，它将从该目录获取NameNode和ResourceManager的地址和其它重要配置。Cloudera Manager区分服务端和客户端配置，默认HDFS的复制因子或者MapReduce任务的Heap Size等设置是客户端配置。因此当这些设置发生变化是，你需要执行“部署客户端配置”操作来更新这些目录。

Cloudera Manager管理的进程（实际的守护进程，如RegionServer和DataNode等）不使用/etc/hadoop/conf。就像上面描述的一样，它们使用自己的配置文件。这有两个目的：首先它允许Cloudera Manager管理这些配置的生命周期；其次它可以让守护进程明确这些配置来自于Cloudera Manager Server。所以Cloudera Manager在执行重启操作时不会将更改覆盖到/etc目录。

用户的集群中通常还会有边缘节点，客户端节点或者Gateway节点，它们不运行任何Hadoop守护程序，但会与集群处于同一个网络中。用户往往会将这些节点用作启动作业，访问文件等的跳板机。如果你想在这些机器上部署客户端配置，你需要在这些机器上添加“Gateway”角色，然后当你使用“部署客户端配置”操作时，这些机器就会接收到新的客户端配置。

那么是谁来启动Agent的呢？重启Agent会发生什么呢？Agent通常由init.d在启动时启动，Agent会联系Server并确定应该运行哪些进程。Agent会作为主机监控的一部分被Cloudera Manager进行监控，如果Agent停止心跳，主机将被标记为健康状况不良。

5.同时，在Server端…

CM Server维护集群的整个状态，可以粗略的将其划分为“model”和“runtime”状态，两者都存储在Cloudera Manger Server后端的数据库中。

Model状态是应该在哪里运行的东西，有什么配置。比如你有17台主机，每台主机都应该运行一个DataNode，这就是Model状态。Cloudera已经对Hadoop技术栈进行了建模：它的角色、配置和相互依赖关系。用户通过界面上的配置模块（比如“添加服务”等操作）与Model进行交互。

Runtime状态是哪些进程在哪里运行，以及当前正在执行哪些命令比如rebalance HDFS，执行灾备计划，滚动重启或者普通停止。Runtime状态还包括一些细节比如运行进程所需的确切配置文件。实际上当你再Cloudera Manager中点击“启动”时，CM Server就会收集相关服务和角色的所有配置，对其进行验证，并生成配置文件，并将它们存储在数据库中。

当你更新了一个配置，比如Hue的Web端口，实际上你就是更新了Model。但是你在更新配置的时候Hue正在运行，它监听的还是旧的端口。当这种不匹配发生时，这个角色就会被标记为“过期的配置”。这时你需要重新启动角色，这会触发配置重新生成和进程重新启动。

许多用户问我们应该如何进行备份。一个简单的方法是使用Cloudera Manager API来抓取/api/cm/deployment endpoint的信息，这会捕获所有Model信息，但是不会捕获Runtime信息。第二种方法是备份整个Cloudera Manager Server的数据库，一般都比较小。每台主机上几乎没有什么要备份的，因为Agent的配置通常只是服务器的主机名。

当我们尝试对所有合理的配置进行建模时，我们发现不可避免的会出现一些遗漏。当用户在处理一些bug或者探索不受支持的选项时，我们提供了一个替代方案，就是“安全阀（safety valve）”，让用户可以直接插入配置文件。

6.监控和其它管理服务

Cloudera Manager还管理了一些其它服务，比如Service Monitor，Host Monitor，Event Server，Reports Manager和Alert Publisher。为了方便扩展，这些服务Cloudera Manager都是单独管理的，在大规模集群中，我们建议将这些服务独立部署在不同的主机，比如将Service Monitor和Host Monitor部署在专门的服务器上。

6.1.指标收集

Cloudera Manager会收集指标以进行监控。这些指标就是一些简单的数值，比如“cpu seconds”，然后和它们适用的实体比如“host17”以及时间戳相关联。大部分指标收集由Agent完成，Agent与supervised进程进行通话，获取指标然后转发给Service Monitor。大多数情况下这个操作每分钟执行一次。

Service Monitor本身还会收集一些特殊的指标，比如Service Monitor托管了一个HDFS canary，它会定期尝试从 HDFS 写入、读取和删除文件，除了收集成功与否还会记录执行时间。一旦收集到指标，它们就会被聚合和存储。

使用Cloudera Manager中的“图表”页面，用户可以查询和探索正在收集的指标。一些指标如“total_cpu_seconds”是计数器，查询它们的适当方法是随着时间的推移计算它们的速率，这就是为什么很多指标查询看起来像“dt0(total_cpu_seconds)”的原因。（“dt0”语法旨在提醒你衍生工具，“0”表示由于我们正在查看单调递增计数器的速率，因此我们永远不应该有负速率。）

6.2.健康检查

Service Monitor会一直评估系统中每个实体的“健康检查”。一个简单的健康检查比如NameNode的数据目录是否有足够的空间，复杂一点的比如HDFS的最后一个检查点何时与阈值进行比较，或者DataNode是否连接到NameNode。其中一些健康检查还会聚合其它健康检查：在像HDFS这样的分布式系统中，有几个DataNode宕机是正常的（假设你有几十台机器），所以我们允许设置一个多少百分比节点挂掉的阈值来代表整个服务挂掉。

当健康检查变为红色时，会创建事件，并通过电子邮件或SNMP发出告警

一个常见的问题是监控是否可以与配置分开，答案是否定的。我们的监控目标是当用户启用它时，无需进行额外的配置和安装额外的工具比如Nagios。通过深入的配置模型，我们能够知道要监控哪些目录、要与哪些端口通信，以及为这些端口使用哪些凭据。这种紧耦合意味着当你安装完Cloudera产品时，所有监控立即可用。