1. 为什么单节点部署 Cloudera Manager 是集群搭建的关键一步

搞过大数据平台的人都知道，CDH 这套东西虽然现在社区版已经不再更新了，但存量项目里用得还是相当多，尤其是那些早年搭建、至今仍在稳定跑着离线任务和实时链路的集群。我接触过的几个数据平台，底层清一色是 CDH 6.x，有的是 6.0，有的是 6.1，差别不大，核心组件版本略有不同而已。而整个集群搭建过程中，Cloudera Manager 的安装是整个部署流程的分水岭——装好了，后面添加节点、分配角色、启动服务都是界面点点点的事；装不好，后面每一步都是坑。

标题里特别强调了一句“只需要在 NODE1 做”，这句话看着简单，但背后其实藏着一个很重要的架构认知：Cloudera Manager 采用的是Server-Agent 架构，Server 端只需要部署在一个节点上，也就是我们常说的管理节点，而 Agent 端则需要在集群中每一台受管节点上安装。很多人第一次搭 CDH 的时候不理解这个设计，觉得“为什么不能每台机器都装一个 Server 互相备份”，结果折腾半天发现根本行不通。所以这篇文章我就围绕这个核心点，把 Cloudera Manager 在 NODE1 上的完整安装过程拆开来讲，包括前置准备、安装方式选型、具体操作步骤、参数配置逻辑，以及我自己踩过的那些坑。

这篇文章适合谁看？如果你正在搭建 CDH 6.0 或 6.1 集群，手头有一批服务器等着装环境，或者你之前装过一次但过程稀里糊涂、想彻底搞明白每一步在干什么，那这篇内容应该能帮到你。我会尽量把“为什么这么做”讲清楚，而不是只丢一堆命令让你复制粘贴。毕竟安装过程本身不算特别复杂，真正让人头疼的是那些文档里不写、但实际一定会遇到的问题。

2. 安装前的整体设计与方案选型

2.1 为什么 Cloudera Manager 只装在 NODE1

先把这个核心问题说透。Cloudera Manager 的架构本质上是一个集中式管理平台，它由三个部分组成：Server（服务端）、Agent（代理端）、Database（数据库）。Server 负责整个集群的协调、监控、配置下发和服务生命周期管理；Agent 安装在每台受管主机上，负责执行 Server 下发的指令并上报本机状态；Database 则存储所有的配置信息、监控数据和审计日志。

Server 和 Database 只需要一份，通常放在同一个节点上，也就是 NODE1。Agent 则是每台机器都要有。这个设计的好处很直接：管理入口统一，不会出现多个 Server 争抢状态导致数据不一致的问题。你可以把它理解成一个公司的管理层——CEO 只有一个，但每个部门都有对接人。如果设两个 CEO，下面的人听谁的？所以“只需要在 NODE1 做”不是偷懒，而是架构本身的要求。

那 NODE1 需要什么样的配置？根据我的经验，如果集群规模在 10 台以内，NODE1 给16 核 CPU、64GB 内存、500GB 以上 SSD是比较稳妥的。Cloudera Manager Server 本身占不了太多资源，但它背后的 PostgreSQL 或 MySQL 数据库、以及监控数据的积累会随着时间增长。内存太小的话，跑一段时间后 Web 界面会明显变卡。磁盘一定要用 SSD，因为监控数据的写入频率很高，机械盘容易成为瓶颈。

2.2 安装方式的选择：离线包 vs 在线仓库

Cloudera Manager 的安装方式主要有两种：一种是通过 Cloudera 官方仓库在线安装，另一种是下载离线包手动部署。这两种方式我都用过，各有适用场景。

在线安装的好处是简单，配好 yum 源之后一条命令就能搞定，适合网络环境好、能稳定访问外部仓库的场景。但问题是，很多生产环境是内网隔离的，根本连不出去，这时候就只能走离线包。而且即使网络能通，在线安装的下载速度也不一定稳定，装到一半断掉的情况我遇到过不止一次。

离线包的方式稍微麻烦一点，需要提前下载好 Cloudera Manager 的 parcel 包和对应的 manifest 文件，然后搭建一个本地的 HTTP 服务来分发。但它的优势在于可控性强——版本固定、不依赖外网、可以重复使用。对于生产环境，我一般推荐离线方式，因为一次准备好之后，后面扩容或者重装都能直接用。

这里有个细节需要注意：CDH 6.0 和 6.1 对应的 Cloudera Manager 版本是不一样的。6.0 对应的是 CM 6.0.x，6.1 对应的是 CM 6.1.x。版本必须匹配，不能混用，否则后面添加服务的时候会出现兼容性问题。我见过有人用 CM 6.1 去管理 CDH 6.0 的 parcel，结果分配角色时一直报错，排查了半天才发现是版本不匹配。

2.3 数据库的选型考量

Cloudera Manager Server 需要一个数据库来存储元数据。官方支持 PostgreSQL、MySQL 和 Oracle。Oracle 在企业环境里用得多，但配置相对复杂，而且需要额外的授权。PostgreSQL 和 MySQL 都是免费开源的，选哪个都行。

我个人的偏好是PostgreSQL，原因是 Cloudera 官方文档里对 PostgreSQL 的支持描述最详细，而且 PostgreSQL 在处理并发写入时的表现比较稳定。MySQL 也不是不行，但需要注意字符集和连接数的配置，尤其是max_connections这个参数，默认值往往不够用，Cloudera Manager 在运行过程中会创建不少连接。

数据库可以和 Cloudera Manager Server 装在同一台机器上，也就是 NODE1。对于中小规模集群，这样部署完全没问题。但如果集群规模超过 50 台，建议把数据库独立出来，避免资源争抢。不过这是后话了，大部分场景下 NODE1 单机搞定就行。

3. 核心细节解析与实操要点

3.1 系统层面的前置准备

在装 Cloudera Manager 之前，NODE1 上有一堆系统层面的东西需要先处理好。这些东西看着琐碎，但少做一步后面就可能卡住。

首先是主机名和 hosts 解析。NODE1 的主机名要设置成 FQDN 格式，比如node1.cluster.local这种，不要用简单的node1。因为 Cloudera Manager 在通信时会用完整域名，如果 hosts 文件里没配好，Agent 注册的时候会失败。我一般会在所有节点的/etc/hosts里把集群所有机器的 IP 和主机名都写进去，这样不依赖 DNS 也能正常解析。

然后是防火墙和 SELinux。这两个是安装过程中最常见的拦路虎。Cloudera Manager 需要用到很多端口，比如 7180（Web UI）、7182（Agent 通信）、7432（数据库）等等。手动开端口太麻烦，我通常直接关掉防火墙和 SELinux，等装完再根据实际需要收紧策略。命令很简单：

systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

还有时间同步。集群里所有节点的时间必须一致，否则监控数据会乱掉，证书校验也可能出问题。用 chronyd 或者 ntpd 都行，确保 NODE1 和其他节点的时间差在秒级以内。

最后是JDK 的安装。Cloudera Manager 6.x 需要 JDK 8，不支持 JDK 11。而且必须是 Oracle JDK 或者 OpenJDK 的特定版本，太新的版本可能会有兼容性问题。我一般用 OpenJDK 1.8.0_xxx，装好之后设置好JAVA_HOME环境变量，并且在/usr/java/下创建一个默认的软链接，因为 Cloudera Manager 的某些脚本会去这个路径找 Java。

3.2 数据库的初始化配置

数据库这块需要做几件事：安装数据库软件、创建 Cloudera Manager 专用的数据库和用户、导入初始表结构。

以 PostgreSQL 为例，安装完之后需要创建一个名为scm的数据库和一个名为scm的用户，密码自己设定。然后需要调整一些数据库参数，比如max_connections至少设为 100，shared_buffers根据内存大小调整。这些参数在/var/lib/pgsql/data/postgresql.conf里修改。

创建完数据库后，需要导入 Cloudera Manager 提供的建表脚本。这个脚本在 Cloudera Manager 的安装包里有，路径通常是/opt/cloudera/cm/schema/scm_prepare_database.sh。执行这个脚本的时候需要提供数据库类型、主机名、数据库名、用户名和密码，脚本会自动创建表结构并配置 Cloudera Manager 的数据库连接信息。

注意：这个脚本执行一次就够了，重复执行会报错说表已存在。如果确实需要重新初始化，得先把数据库删掉重建。

3.3 Cloudera Manager Server 的安装

到了正式安装 Cloudera Manager Server 的环节。如果用在线方式，先配置好 yum 源，然后执行：

yum install cloudera-manager-daemons cloudera-manager-server

这两个包一个是守护进程，一个是服务端主程序。安装过程会自动处理依赖关系，但前提是 yum 源配置正确。如果用的是离线包，需要先挂载或者解压安装介质，然后通过rpm或者yum localinstall来安装。

安装完成后，Cloudera Manager Server 的服务文件会出现在/etc/init.d/cloudera-scm-server，配置文件在/etc/cloudera-scm-server/目录下。其中最重要的是db.properties文件，里面记录了数据库的连接信息。如果之前用scm_prepare_database.sh脚本配置过，这个文件应该已经自动生成好了。

启动服务之前，建议先检查一下/etc/cloudera-scm-server/db.properties里的内容是否正确，特别是数据库密码有没有特殊字符导致解析问题。我遇到过一次密码里带了#号，结果配置文件把它当成注释了，服务一直起不来。后来把密码改成纯字母数字组合就好了。

启动命令：

systemctl start cloudera-scm-server

启动过程需要一点时间，因为它要初始化数据库连接、加载配置、启动内部服务。可以通过查看日志来确认进度：

tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log

当日志里出现Started Jetty server或者Server started之类的字样时，说明服务已经起来了。这时候就可以通过浏览器访问http://NODE1_IP:7180来打开 Cloudera Manager 的 Web 界面了。默认的用户名和密码都是admin。

3.4 Agent 端的安装准备

虽然标题说“只需要在 NODE1 做”，但这里有个容易混淆的地方：Cloudera Manager Server 确实只装在 NODE1，但 Agent 是每台节点都要装的。不过 Agent 的安装通常不需要手动操作，而是在 Web 界面里通过“添加主机”向导来批量推送安装。所以严格来说，NODE1 上做的是 Server 的安装，其他节点的 Agent 安装是后续步骤。

但有一个例外情况：如果 NODE1 本身也要作为受管节点（通常都是这样），那 NODE1 上也需要装 Agent。这个 Agent 可以在安装 Server 的时候一起装，也可以后面通过向导装。我一般是在装 Server 的时候顺便把 Agent 也装上，命令是：

yum install cloudera-manager-agent

装完之后不需要手动启动，等 Server 端的向导来触发就行。

4. 实操过程与核心环节实现

4.1 完整安装流程的逐步拆解

我把整个安装过程按实际操作顺序梳理一遍，你可以跟着一步步来。

第一步：确认 NODE1 的基础环境

登录 NODE1，检查主机名、hosts、防火墙、SELinux、JDK、时间同步这些是否都处理好了。可以用以下命令快速检查：

hostname -f cat /etc/hosts systemctl status firewalld getenforce java -version chronyc sources

每一项都要确认无误。特别是hostname -f的输出必须是 FQDN 格式，如果只显示短主机名，说明 hosts 文件里没有配对应的解析记录。

第二步：安装并配置数据库

以 PostgreSQL 为例：

yum install postgresql-server postgresql-contrib postgresql-setup initdb systemctl start postgresql systemctl enable postgresql

然后切换到 postgres 用户，创建数据库和用户：

su - postgres psql CREATE DATABASE scm; CREATE USER scm WITH PASSWORD 'your_password'; GRANT ALL PRIVILEGES ON DATABASE scm TO scm; \q

接着调整pg_hba.conf，允许 Cloudera Manager Server 从本机连接数据库。找到local和host相关的行，把认证方式改成md5或trust。改完之后重启 PostgreSQL。

第三步：初始化 Cloudera Manager 的数据库

执行建表脚本：

/opt/cloudera/cm/schema/scm_prepare_database.sh postgresql scm scm your_password

如果脚本提示找不到，说明 Cloudera Manager 的包还没装。所以这一步其实应该在安装完 Server 包之后再做。顺序上可以调整：先装包，再初始化数据库，最后启动服务。

第四步：安装 Cloudera Manager Server 和 Agent

yum install cloudera-manager-daemons cloudera-manager-server cloudera-manager-agent

安装完成后，确认/etc/cloudera-scm-server/db.properties里的数据库连接信息正确。

第五步：启动 Cloudera Manager Server

systemctl start cloudera-scm-server systemctl enable cloudera-scm-server

查看日志确认启动成功：

tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log

第六步：访问 Web 界面

浏览器打开http://NODE1_IP:7180，用admin/admin登录。如果能正常看到界面，说明 Server 端安装成功。

4.2 关键参数的计算与选择

在安装过程中，有几个参数需要根据实际情况来定，不能随便填。

数据库连接数：Cloudera Manager Server 默认会创建大约 50 个数据库连接。如果 PostgreSQL 的max_connections设得太小（默认是 100），再加上其他服务的连接，很容易不够用。我一般会把max_connections设为 200 以上。计算公式大概是：基础连接数 50 + 每个受管服务约 5 个连接 × 服务数量。比如集群要跑 HDFS、YARN、Hive、HBase 等 10 个服务，那就是 50 + 50 = 100，留点余量设 200 比较稳妥。

JVM 堆内存：Cloudera Manager Server 的 JVM 堆内存默认是 2GB，对于中小集群够用。但如果集群规模超过 30 台，建议调到 4GB。修改位置在/etc/cloudera-scm-server/下的环境变量文件里，找到CMF_JAVA_OPTS或者类似的参数，把-Xmx的值改大。

Agent 心跳间隔：Agent 默认每 15 秒向 Server 发送一次心跳。这个频率一般不用改，但如果集群规模很大（超过 100 台），可以适当调大到 30 秒，减轻 Server 端的压力。配置位置在 Agent 的配置文件里。

4.3 实操现场记录与验证

我最近一次在测试环境搭 CDH 6.1 的时候，NODE1 用的是 16 核 64GB 的虚拟机，CentOS 7.9 系统。整个安装过程大概花了 40 分钟，其中大部分时间花在等数据库初始化和 Server 启动上。

启动成功后，Web 界面第一次加载会提示你接受许可协议、选择试用版还是正式版。这里选试用版就行，功能上没有区别，只是试用期 60 天。然后会进入集群安装向导，引导你添加主机、分配 parcel、安装服务。

有一个验证 Server 是否正常的小技巧：在浏览器访问http://NODE1_IP:7180/cmf/health，如果返回 JSON 格式的健康状态信息，说明 Server 的 API 接口是通的。这个接口在后面做自动化运维的时候也会用到。

另外，安装完成后建议检查一下/var/log/cloudera-scm-server/目录下的日志，看看有没有 ERROR 级别的记录。有些警告信息不影响使用，但 ERROR 一定要处理。我见过一次因为数据库字符集问题导致部分表创建失败，日志里报了 ERROR，但 Web 界面看起来正常，结果后面添加服务的时候才暴露出来。

5. 常见问题与排查技巧实录

5.1 安装过程中的典型报错与解决

问题一：Server 启动失败，日志显示数据库连接被拒绝

这个是最常见的问题。原因通常是数据库没启动、pg_hba.conf配置不对、或者密码错误。排查步骤：先用psql -h localhost -U scm -d scm手动连接一下数据库，确认能连上。如果连不上，检查 PostgreSQL 服务状态和认证配置。如果手动能连上但 Server 连不上，检查db.properties里的密码有没有特殊字符被转义。

问题二：Web 界面打不开，提示连接超时

先确认 Server 进程是否在运行：systemctl status cloudera-scm-server。如果进程在但端口没监听，用netstat -tlnp | grep 7180检查端口。如果端口没监听，可能是 Server 启动过程中卡住了，看日志找原因。如果端口监听了但外部访问不了，检查防火墙规则。

问题三：Agent 注册失败，提示证书错误

Cloudera Manager 使用自签名证书进行 Server 和 Agent 之间的通信。如果 Agent 之前连接过其他 Server，本地会缓存旧的证书，导致新 Server 注册失败。解决方法是删除 Agent 的证书缓存目录：rm -rf /var/lib/cloudera-scm-agent/*，然后重启 Agent。

问题四：数据库初始化脚本执行报错

常见原因是数据库用户权限不够。确保scm用户对scm数据库有全部权限，并且能创建表。另外，脚本执行时需要用 root 用户或者有 sudo 权限的用户，因为它需要写入/etc/cloudera-scm-server/db.properties文件。

5.2 独家避坑经验分享

坑一：主机名不要用下划线

Cloudera Manager 对主机名的格式有要求，只允许字母、数字和连字符，下划线会导致 Agent 注册失败。我一开始不知道这个限制，用了node_1这样的主机名，结果折腾了好久才发现问题。后来改成node1就正常了。

坑二：/opt 目录空间要留够

Cloudera Manager 的安装包、parcel 文件、日志都放在/opt目录下。如果/opt是独立分区且空间不足，安装到一半会失败。建议/opt至少留 50GB 空间。如果不够，可以提前把 parcel 的存储路径改到其他分区。

坑三：不要用 root 用户跑所有服务

虽然安装 Cloudera Manager 本身需要 root 权限，但后面添加服务的时候，Cloudera Manager 会为每个服务创建独立的系统用户。如果之前手动用 root 跑过某些服务，可能会和 Cloudera Manager 管理的服务冲突。所以装之前最好确认一下系统里没有残留的 Hadoop 相关进程。

坑四：时间同步不是可选项

我遇到过因为 NODE1 和其他节点时间差了 5 分钟，导致 Agent 心跳超时、服务状态显示异常的情况。时间同步一定要在安装前就配好，而且要用同一个时间源。

5.3 常见问题速查表

6. 安装完成后的下一步动作

Cloudera Manager Server 在 NODE1 上装好、Web 界面能正常访问之后，接下来的事情就是在界面里走集群安装向导了。向导会引导你添加其他节点、分发 CDH parcel、分配角色、启动服务。这些步骤虽然是在界面上操作，但背后的逻辑和命令行安装是一样的，理解了 Server-Agent 的架构之后，操作起来会顺畅很多。

有一点需要提醒：在添加其他节点之前，确保这些节点的基础环境（主机名、hosts、防火墙、SELinux、JDK、时间同步）都已经处理好。Cloudera Manager 的添加主机向导会做一次环境检查，如果有问题会直接报出来。与其在向导里一个个修，不如提前批量处理好，省时省力。

另外，安装完成后建议把 NODE1 上的 Cloudera Manager 相关目录做个备份，特别是/etc/cloudera-scm-server/和数据库的备份。后面如果要做升级或者迁移，这些备份能省很多事。我自己就吃过亏，有一次升级失败想回滚，结果发现没备份配置文件，只能从头重装。

最后分享一个小技巧：Cloudera Manager 的 Web 界面里有一个“诊断包”功能，可以一键收集所有节点的日志和配置信息。遇到解决不了的问题时，先收集诊断包，然后慢慢分析，比一个个节点登录去看日志效率高得多。这个功能在排查集群级别的问题时特别有用。