转载：CDH6.3.2 详细介绍

CDH6.3.2 详细介绍

官方文档：Cloudera Enterprise 6.3 Documentation

一. 简介 :

• CDH：全称Cloudera’s Distribution Including Apache Hadoop。
• hadoop是一个开源项目，所以很多公司在这个基础进行商业化，Cloudera对hadoop做了相应的改变。Cloudera公司的发行版，我们将该版本称为CDH(Cloudera Distribution Hadoop)。 是Hadoop众多分支中的一种，由Cloudera维护，基于稳定版本的Apache Hadoop构建 。

Apache Hadoop 不足之处

• 版本管理混乱
• 部署过程繁琐、升级过程复杂
• 兼容性差
• 安全性低

Hadoop 发行版有哪些

• Apache Hadoop
• Cloudera’s Distribution Including Apache Hadoop（CDH）
• Hortonworks Data Platform (HDP)
• MapR
• EMR
• …

CDH能解决哪些问题

• 1000台服务器的集群，最少要花费多长时间来搭建好Hadoop集群，包括Hive、Hbase、Flume、Kafka、Spark等等
• 只给你一天时间，完成以上工作？
• 对于以上集群进行hadoop版本升级，你会选择什么升级方案，最少要花费多长时间？
• 新版本的Hadoop，与Hive、Hbase、Flume、Kafka、Spark等等兼容？

CDH的优点　　

• 版本划分清晰
• 版本更新速度快
• 支持Kerberos安全认证
• 文档清晰
• 支持多种安装方式（Cloudera Manager方式）

CDH安装方式

• Cloudera Manager
• Yum
• Rpm
• Tarball

二. CDH正式

Cloudera Manager 的概念

简单来说，Cloudera Manager是一个拥有集群自动化安装、中心化管理、集群监控、报警功能的一个工具（软件）,使得安装集群从几天的时间缩短在几个小时内，运维人员从数十人降低到几人以内，极大的提高集群管理的效率。

如下图所示，Cloudera Manager 的核心是 Cloudera Manager Server（以下简称Server）。Server 托管管理控制台 web 服务和应用程序逻辑，并负责软件的安装、配置、服务的启动与关闭以及管理集群。

Server 和其他一些组件共同工作：

• Agent - 安装在每台主机上。Agent 负责进程的启动和停止，解压配置，触发安装以及监视主机。
• Management Service - 由一组角色组成的服务，这些角色执行各种监视，警报和报告功能。
• Database - 存储配置以及监控信息。通常情况下，多个逻辑数据库运行在一个或多个数据库服务器上。例如，Cloudera Manager Server 和 monitoring roles 使用不同的逻辑数据库。
• Cloudera Repository - Cloudera Manager分发软件的存储库。
• Clients - 与Server交互的接口
• Admin Console - 管理员 web 界面版
• API - 用于开发者创建 Cloudera Manager 程序

CM6.3.1+CDH6.3.2环境搭建

CM6.3.1+CDH6.3.2环境搭建 - 知乎 (zhihu.com)

Cloudera Manager的基本使用

• Cloudera Manager是一个管理CDH的端到端的应用。

功能：

1. 管理监控集群主机（主要监控硬件和软件的信息）
2. 统一管理配置（主要是针对服务，比如hdfs，hbase等等）
3. 管理维护Hadoop平台系统。

相关名词解释：

• 主机 - host
• 机架 - rack
• 集群 - Cluster
• 服务 - service
• 服务实例 - service instance
• 角色 - role
• 角色实例 - role instance
• 角色组 - role group
• 主机模板 - host template
• parcel
• 静态服务池 - static service pool
• 动态资源池 - dynamic resource pool

Cloudera Management Service

Cloudera Management Service 可作为一组角色实施各种管理功能

• Activity Monitor：收集有关服务运行的活动的信息
• Host Monitor：收集有关主机的运行状况和指标信息
• Service Monitor：收集有关服务的运行状况和指标信息
• Event Server：聚合组件的事件并将其用于警报和搜索
• Alert Publisher ：为特定类型的事件生成和提供警报
• Reports Manager：生成图表报告，它提供用户、用户组的目录的磁盘使用率、磁盘、io等历史视图

心跳（Heartbeating）

• Heartbeats是Cloudera Manager中的主要通信机制。默认情况下，Agent 每15秒发送一次心跳给 Server。当然，这个心跳频率可以进行调整。
• 通过这个心跳机制，Agent 向 Server 汇报自己的活动。反过来，Server 会响应 Agent 的活动。Agent 和 Server 最终都会进行一些对帐。例如，如果你启动一个服务， Agent 尝试启动相应的进程，如果这个进程启动失败，Server会标记这个失败的启动命令。

状态管理（State Management）

• Server 维护集群的状态。这个状态可以划分为两类：model 和 runtime， 二者都保存在 Server 的数据库中。
• Cloudera Manager 为 CDH 建模以及管理服务：角色、配置以及内部依赖。模型告诉我们应该在什么地方运行什么以及使用什么样的配置。例如，模型状态捕获了一个事实，即一个集群包含17个主机，每个主机应该运行一个DataNode。你可以使用管理控制台的配置页或者 API 来操作模型，例如 “Add Service”。
• Runtime 状态这个概念可以理解为：进程在哪里运行，什么命令正在运行等。在管理控制台页面中选择“启动”时，服务器将收集相关服务和角色的所有配置，对其进行验证，生成配置文件并将其存储在数据库中。
• 当你更新配置（例如更改 Hue Server 的 web 端口），你就更新了 Model 状态。然后， 当 Hue 正在运行时改变端口，它仍然会使用老的端口。当这种情况发生时，角色会被标记为拥有一个“过时的配置”。为了达到同步，你必须重启角色（触发配置文件重新生成以及进程重启）。

配置管理（Configuration Management）

Cloudera Manager 定义了几个配置级别：

• 服务级别（service level）: 针对整个服务实例的配置，例如 HDFS 服务默认的复制因子（dfs.replication）。
• 角色组级别（role group level）: 应用到角色成员的配置，例如 Datanode 的句柄数（dfs.datanode.handler.count）。针对不同的 Datanode，这个设置可能不同。例如，在性能更好的硬件上，这个值可以设置更大一些。
• 角色实例级别（role instance level）: 这个级别的配置会覆盖继承自角色组的配置。这里需要谨慎使用，因为会导致与角色组配置之间存在差异。在一些特殊情况下可以使用，比如零时打开 debug 日志级别以发现并解决一些问题。
• 主机也有一些配置，比如配置监控、软件管理以及资源管理等。
• Cloudera Manager本身具有与其自身管理操作相关的配置。

角色组（Role Groups）

• 你可以给服务实例（例如 HDFS）进行配置，也可以个角色实例（例如 host17上的 Datanode）进行配置。单个角色的配置从服务级别继承，并且如果角色上进行了配置，它将覆盖这个继承。这种机制提供了配置的灵活性，用户也不需要为每一个角色单独进行配置，减少繁杂的配置工作。
• Cloudera Manager 支持角色组配置，这是一种将配置分配给一个角色组的机制。这样，组中各个角色都会继承这个配置。例如，在一个拥有不同性能主机组成的集群中，因为性能不同，我们可以为部署在其上的 Datanode 构建不同的配置组（性能好的配置高点，差的配置低点）。在性能高的一些主机上，我们为 Datanode组 运用配置A,性能低的一些主机上，我们运用配置B。

主机模板（Host Templates）

通常情况下，一些主机拥有相同的硬件，并且有相同的服务运行在上面。主机模板在集群中提供了一系列角色组，这样做有两个好处：

• 加入新主机到集群会变得简单 - 应用已经存在的角色组，简单的操作即可完成新主机的加入
• 对一些列主机进行角色的配置修改将变得简单 - 用户不需要一个个进行修改，用户可以快速的修改集群配置来应对不同的性能负载以及不同用户的需求

服务以及客户端配置（Server and Client Configuration）

• 用户有时会诧异，为什么修改 /etc/hadoop/conf 配置并重启 HDFS后并没有生效。这是因为使用 Cloudera Manager 启动服务实例并不是从默认位置的配置文件中读取。拿 HDFS 举例，不适用 Cloudera Manager 管理的话，通常每个主机上都需要进行配置，配置文件是 /etc/hadoop/conf/hdfs-site.xml。相同主机上的服务进程以及客户端将使用相同的配置。
• Cloudera Manager 区分服务配置以及客户端配置。同样拿 HDFS 举例，/etc/hadoop/conf/hdfs-site.xml 文件中配置项适用于 HDFS 客户端。也就是说默认情况下，你运行一个需要跟 Hadoop 交互的程序时，它是从这个路径下拿到 NameNode、JobTracker 以及其他服务的配置项。同样，/etc/hbase/conf 和 /etc/hive/conf 情况也是一样。
• 对比之下，HDFS 角色实例（例如，Datanode 或 Namenode）则会从每个进程的私有目录中（/var/run/cloudera-scm-agent/process/unique-process-name）获取配置信息。给每个进程提供私有的运行以及配置环境，会使得 Cloudera Manager 能够独立地控制每个进程。例如，下面是 63-hdfs-DATANODE 进程目录下的内容：

[root@cdh01 process]# tree -a /var/run/cloudera-scm-agent/process/63-hdfs-DATANODE /var/run/cloudera-scm-agent/process/63-hdfs-DATANODE├── cloudera-monitor.properties├── cloudera-stack-monitor.properties├── config.zip├── core-site.xml├── event-filter-rules.json├── exit_code├── hadoop-metrics2.properties├── hadoop-policy.xml├── hdfs.keytab├── hdfs-site-refreshable.xml├── hdfs-site.xml├── http-auth-signature-secret├── log4j.properties├── logs│ ├── stderr.log│ └── stdout.log├── process_timestamp├── proc.json├── redaction-rules.json├── ssl-client.xml├── ssl-server.xml├── supervisor.conf└── supervisor_status

区分服务配置和客户端配置有以下几个好处：

• 服务端配置中的一些敏感信息不会暴露给用户，例如用于存储 HIVE 元数据的数据库的密码。
• 一个服务依赖如另外一个服务，有时就需要这个依赖服务提供特定的版本。例如，为了获得 HDFS 更好的读性能，Impala 需要指定版本的 HDFS 客户端配置，但是这样做会影响其他通用的客户端访问。为了解决这个问题，我们可以将 HDFS 配置分为针对普通客户端（/etc/hadoop/conf）以及 Impala 客户端（Impala 进程私有的配置目录）。
• 客户端配置文件更小且更加易读。这也避免了一些不相关的配置项困扰 Hadoop 入门者。

使用：

1、集群管理

• 添加、删除集群
• 启动、停止、重启集群
• 重命名集群
• 全体集群配置
• 移动主机

2、主机管理

• 查看主机详细
• 主机检查
• 集群添加主机
• 分配机架
• 主机模板
• 维护模式
• 删除主机

3、服务管理

• 添加服务
• 对比不同集群上的服务配置
• 启动、停止、重启服务
• 滚动重启
• 终止客户端正在执行的命令
• 删除服务
• 重命名服务
• 配置最大进程数 rlimit_fds

4、角色管理

• 角色实例
• 添加角色实例
• 启动、停止、重启角色实例
• 解除授权
• 重新授权
• 删除角色实例
• 角色组
• 创建角色组
• 管理角色组

5、资源管理

• 动态资源池

CDH Yarn资源队列划分管理

场景：根据不同项目或不同用户，对yarn资源队列进行划分，达到资源管控，任务管控的目的

1） yarn资源队列参数设置：

yarn.scheduler.fair.user-as-default-queue

Fair Scheduler：yarn的公平调度器，对全局资源和对所有的应用作业都均匀分配的资源分配方法。 默认情况下，它是基于内存来安排公平调度策略，也可以配置成为同时基于内存和CPU来进行调度。总的来说，它是一种基于内存，给集群中所提交的应用程序分配资源的调度器。

yarn.scheduler.fair.allow-undeclared-pools

默认是true，允许创建未定义的资源池。当用户提交了一个作业，指定的队列不存在的时候，会自动创建出这个不存在的队列。设置成false，如果任务中指定了一个未定义的资源池，那么这个资源池将不会被创建，该任务会被分配到默认的资源池中，default。

2）CDH 动态资源队列配置

如图，第一步我们划分了2个资源池:

root.default:默认池，没有划分资源池的用户会提交到default资源池

权重定义了资源池之间分配资源的比例，目前集群中的default资源池和users资源池的权重各为1,那么集群中的资源会将50%分配给default，50%分配给users，但是这里的资源分配不是一个静态的概念，假如users中没有任务在运行，那么default资源池是允许使用超过50%的资源的，且资源池配置允许在线修改，修改后不需要重启yarn，因为RM会周期性的读取资源池的配置信息

设置default资源池的调度算法：使用DRF，即根据内存和CPU进行资源调度

yarn.scheduler.fair.preemption解释：启用后，如果在某些时间段未达到池的最小共享，Fair Scheduler 可以优先选取其他池中的应用程序。优先权可保证生产应用程序不缺乏资源，同时还可使群集用于实验和研究应用程序。为尽量减少计算资源浪费，Fair Scheduler 会优先选取最近启动的应用程序。

该项不建议开启。

Yarn的资源抢占本身就具有一定的资源开销，并且如果开启了资源抢占，对于长时间运行的任务容易出现延迟的情况。所以在此也建议配置队列时，要将长时间运行任务和执行时间较短的任务放在不同的队列中。同时对于队列的maxResource，可以适当的配置大些，这样即使不打开抢占，RM也是可以将一个队列的已经运行完成的资源回收分配给别的队列。从而达到提高资源的利用率。

访问控制：

yarn.acl.enable：指定是否应检查管理 ACL 中指定的用户和组执行管理操作的授权。

yarn.admin.acl：确定哪些用户和组可在任何池中提交和中止应用程序以及可以对 ResourceManager 角色发出命令的 ACL。

3）动态资源池配置——计划模式

假如规定我们将所有开发测试的job全部提交到root.dev资源池，所有的生产任务全部提交到root.prod资源池。由于我们的离线任务大多放在夜间执行，而开发测试工作主要在白天执行，很显然，root.dev在白天的时候需要更多的资源，root.prod在夜间需要更多的资源。计划模式就能够自动帮助我们在不同的时间段，刷新不同的资源池配置。

（1）创建计划规则

日间计划规则

夜间计划规则

（2）修改资源池

修改root.default将daytime的日间权重适当调大，此处上调到3。

按照相同的步骤，将root.users的夜间权重适当调大，也上调至3。

4）动态资源池配置——放置规则

动态资源池规划完毕后，需要思考的问题就是，如何确定一个job提交后会被放置到哪一个资源池中。以下是放置规则

放置规则可以设置多个，从上到下依次校验，只要有一个规则校验成功，该任务就会被放置到该资源池中，后续规则不再校验，此处设置规则如下

5）动态资源池配置——用户限制

用户限制可对具体用户设置同时运行任务数的上限。

6）刷新动态资源池

动态资源池刷新之后才可生效

6、用户管理

7、安全管理

CDH6.3.2 启用Kerberos 认证 - 知乎 (zhihu.com)

Kerberos 常用命令 - 知乎 (zhihu.com)