企业官网建设流程全解析

简介：这份资源是Cloudera Manager 5.10.0在CentOS7上的完整安装包，面向大数据运维工程师、CDH集群管理员及需要搭建Hadoop生态的学习者，用于解决CM部署、CDH组件管理与集群监控等实际问题。压缩包共约2000个文件，整体615.94MB，以Python源码与字节码（py、pyc、pyo）、HTML页面、JAR包、JavaScript脚本为主，辅以DDL建表语句、PNG图标、TXT说明、SO动态库、JSON与properties配置等，覆盖服务端、代理端及Web控制台所需组件。资源内含cm-5.10.0与cloudera两个子目录，解压后可直接用于启动CM代理与服务器，并借助Web界面完成主机添加、CDH部署、性能监控与故障排查。目前已有825人学习下载，适合希望掌握CM 5.10.0安装配置流程、理解其目录结构与组件构成的中高级读者参考使用。

1. 装 Cloudera Manager 5.10 前，先把 CentOS 7 的底子摸清楚

很多人第一次拿到cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz这个包，第一反应是解压、跑 install，然后被一堆 Python 报错、JDK 版本冲突和数据库连接失败按在地上摩擦。我见过不止一个团队在装 CM 5.10 的时候，因为 CentOS 7 自带的 Python 2.7.5 和 CM 内部依赖的 MySQLdb 模块对不上，卡了整整两天。这套环境在大数据平台搭建里太常见了，CM 5.10 虽然不算新，但很多存量集群还在跑，尤其是那些从 CDH 5.10 一路用过来的老平台。装不好，后面 Hadoop、Hive、Spark 全都没法纳管，整个集群就是一堆散装进程。这篇文章适合两类人：一是第一次接触 Cloudera Manager 的运维新手，二是想把这套老环境重新拉起来的老手。我会按实际装机的顺序，把 JDK、数据库、SCM 服务、Agent 配置和验证方法一步步拆开，中间踩过的坑也一并写出来。

2. 环境准备：CentOS 7 的 JDK 和主机名先定死

2.1 为什么 JDK 版本必须锁在 1.8.0_144 附近

CM 5.10 官方推荐的是 Oracle JDK 1.8，但并不是随便一个 1.8 小版本都能过。我试过用 1.8.0_181 和 1.8.0_202，Cloudera Manager Server 启动时会在/var/log/cloudera-scm-server/cloudera-scm-server.log里报Unsupported major.minor version或者 TLS 握手相关的玄学错误。后来翻 Cloudera 的兼容性矩阵，发现 5.10 这个版本对 1.8.0_144 之后的某些更新比较敏感，尤其是涉及内部 RMI 通信的部分。所以我的习惯是直接锁定jdk-8u144-linux-x64.tar.gz，解压到/usr/java/下，然后用 alternatives 注册。

# 创建目录并解压 JDK mkdir -p /usr/java tar -zxvf jdk-8u144-linux-x64.tar.gz -C /usr/java/ # 注册 alternatives，注意路径要写全 alternatives --install /usr/bin/java java /usr/java/jdk1.8.0_144/bin/java 200 alternatives --install /usr/bin/javac javac /usr/java/jdk1.8.0_144/bin/javac 200 # 验证版本 java -version

这里--install的最后一个参数是优先级，200 表示高于系统自带的 openjdk。如果你机器上已经有 openjdk，执行完 alternatives 后还要用alternatives --config java手动选一下，否则java -version可能还是指向/usr/lib/jvm/下的旧版本。另外，JAVA_HOME环境变量要写进/etc/profile.d/java.sh，因为 CM 的 Agent 脚本会去读这个变量，光配 alternatives 不够。

# 写入环境变量，注意不要覆盖已有的 PATH cat > /etc/profile.d/java.sh <<'EOF' export JAVA_HOME=/usr/java/jdk1.8.0_144 export PATH=$JAVA_HOME/bin:$PATH EOF source /etc/profile.d/java.sh echo $JAVA_HOME

2.2 主机名和 hosts 解析：别让 Agent 找不到 Server

CM 的架构是 Server 端通过主机名去连 Agent，如果主机名解析有问题，Agent 心跳会一直失败。CentOS 7 默认把主机名放在/etc/hostname，但很多人在虚拟机克隆后忘了改，导致多台机器主机名一样。我的做法是每台机器先hostnamectl set-hostname改成规划好的名字，比如cm-server、cm-agent01，然后在所有节点的/etc/hosts里写死 IP 和主机名的映射。

# 在每台机器上执行，替换成实际主机名 hostnamectl set-hostname cm-server # 编辑 /etc/hosts，把所有节点都加进去 cat >> /etc/hosts <<'EOF' 192.168.1.10 cm-server 192.168.1.11 cm-agent01 192.168.1.12 cm-agent02 EOF

注意，/etc/hosts里不要保留127.0.0.1那行带主机名的记录，否则 CM Server 启动时会绑定到回环地址，Agent 连不上。另外，防火墙和 SELinux 在安装阶段建议先关掉，等集群跑通再按需放开端口。我一般用systemctl stop firewalld和setenforce 0临时处理，永久关闭需要改/etc/selinux/config里的SELINUX=disabled。

2.3 数据库选型：MySQL 5.7 还是 MariaDB

CM 5.10 的 Server 端需要外部数据库存元数据，官方支持 MySQL、PostgreSQL 和 Oracle。生产环境我一般用 MySQL 5.7，因为社区资料多，驱动也好找。CentOS 7 自带的 MariaDB 版本是 5.5，虽然也能跑，但 CM 5.10 的 schema 脚本在 MariaDB 5.5 上偶尔会报索引长度超限的错误，需要改innodb_large_prefix参数，比较折腾。所以我的建议是直接装 MySQL 5.7 的社区版，用官方 yum 源。

# 下载 MySQL 5.7 的 yum 源并安装 wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm rpm -ivh mysql57-community-release-el7-11.noarch.rpm yum install -y mysql-community-server # 启动并设置开机自启 systemctl start mysqld systemctl enable mysqld # 获取临时密码 grep 'temporary password' /var/log/mysqld.log

拿到临时密码后，用mysql_secure_installation改密码，然后创建 CM 需要的数据库和用户。这里有个细节：CM 5.10 的 Server 和 Agent 用的数据库是分开的，Server 库叫cm，Agent 库叫amon，但如果你只装一个 Server 和一个 Agent，也可以共用一个 MySQL 实例，建两个库就行。

-- 创建 CM Server 和 Agent 的数据库 CREATE DATABASE cm CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE amon CHARACTER SET utf8 COLLATE utf8_general_ci; -- 创建用户并授权，密码按实际改 GRANT ALL PRIVILEGES ON cm.* TO 'cmuser'@'%' IDENTIFIED BY 'CmPass123!'; GRANT ALL PRIVILEGES ON amon.* TO 'cmuser'@'%' IDENTIFIED BY 'CmPass123!'; FLUSH PRIVILEGES;

MySQL 的my.cnf里要加几个参数，否则 CM 初始化 schema 时会报错。常见做法是在/etc/my.cnf的[mysqld]段落下加transaction-isolation = READ-COMMITTED、max_connections = 500、innodb_buffer_pool_size根据内存调整。改完重启 mysqld 生效。

3. 安装 Cloudera Manager Server：解压、建库、起服务

3.1 解压 tar.gz 包和 RPM 的安装顺序

cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz这个包里其实包含了两部分：CM Server 的 RPM 包和 CM Agent 的 RPM 包，还有一堆依赖的 parcel 文件。很多人直接解压后找不到 install 脚本，是因为这个包不是一键安装包，而是离线仓库的打包。正确的做法是先解压到/opt/下，然后进入解压目录，用yum localinstall装 RPM。

# 解压到 /opt 目录 tar -zxvf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz -C /opt/ # 进入解压后的目录，查看 RPM 文件 cd /opt/cm-5.10.0/RPMS/x86_64/ ls -l # 安装 Server 和 Agent 的 RPM，注意依赖顺序 yum localinstall -y cloudera-manager-server-5.10.0-1.cm5100.p0.4.el7.x86_64.rpm yum localinstall -y cloudera-manager-daemons-5.10.0-1.cm5100.p0.4.el7.x86_64.rpm yum localinstall -y cloudera-manager-agent-5.10.0-1.cm5100.p0.4.el7.x86_64.rpm

这里cloudera-manager-daemons是 Server 和 Agent 共用的依赖，必须先装。如果你只装 Server 不装 Agent，后面添加主机时会报Agent not found。装完后，/etc/cloudera-scm-server/和/etc/cloudera-scm-agent/目录会自动生成，配置文件都在里面。

3.2 用 scm_prepare_database.sh 初始化数据库

CM 提供了一个脚本scm_prepare_database.sh来初始化数据库连接，位置在/opt/cm-5.10.0/share/cmf/schema/下。这个脚本会往数据库里写 CM 的元数据表，并生成/etc/cloudera-scm-server/db.properties文件。执行的时候要指定数据库类型、主机、库名、用户和密码。

# 进入 schema 目录 cd /opt/cm-5.10.0/share/cmf/schema/ # 执行初始化脚本，-p 后面是密码 ./scm_prepare_database.sh mysql -h localhost -u cmuser -p cm

执行后会提示输入密码，输入之前创建的CmPass123!。如果成功，会看到All done, your SCM database is configured correctly!的输出。如果报JDBC driver not found，说明 MySQL 的 JDBC 驱动没放到 CM 的 lib 目录下。CM 5.10 自带的是mysql-connector-java-5.1.47，但有时候需要手动复制到/usr/share/java/下。

# 查找并复制 JDBC 驱动 find /opt/cm-5.10.0 -name "mysql-connector-java*.jar" cp /opt/cm-5.10.0/share/cmf/lib/mysql-connector-java-5.1.47.jar /usr/share/java/

3.3 启动 Server 并观察日志

数据库初始化完成后，就可以启动 CM Server 了。CentOS 7 用的是 systemd，服务名是cloudera-scm-server。启动后不要急着去开 Web UI，先看日志，因为 Server 启动要初始化一堆 Spring Bean，大概需要 1 到 2 分钟。

# 启动 Server systemctl start cloudera-scm-server # 实时查看日志 tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log

日志里看到Started Jetty server和Server started才算真正起来。如果卡在Initializing Spring root WebApplicationContext不动，多半是数据库连接有问题，去检查db.properties里的密码和 JDBC URL。另外，Server 默认监听 7180 端口，用ss -tlnp | grep 7180确认端口起来了。

4. 配置 Agent 和添加主机：心跳通了才算装完

4.1 Agent 配置文件里最容易写错的两个参数

CM Agent 的配置文件是/etc/cloudera-scm-agent/config.ini，里面有两个参数必须改：server_host和server_port。server_host要写 CM Server 的主机名，不是 IP，因为 Agent 会用这个值去拼 URL。如果写 IP，Server 端在添加主机时可能会因为反向解析失败而报错。

# /etc/cloudera-scm-agent/config.ini 关键片段 [General] server_host=cm-server server_port=7182

server_port默认是 7182，这是 Agent 向 Server 汇报的端口，不是 Web UI 的 7180。改完配置后，启动 Agent 服务。

# 启动 Agent systemctl start cloudera-scm-agent # 查看 Agent 日志 tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log

Agent 日志里出现Connected to server或者Heartbeat sent就说明心跳通了。如果一直报Connection refused，检查 Server 的 7182 端口是否监听，以及防火墙有没有放行。

4.2 在 Web UI 添加主机时的 parcel 分发技巧

心跳通了之后，打开浏览器访问http://cm-server:7180，默认账号密码都是admin。登录后第一件事是分配 parcel，也就是 CDH 的安装包。CM 5.10 对应的 CDH 版本是 5.10.0，parcel 文件在解压目录的parcels/下。我一般先把 parcel 文件复制到/opt/cloudera/parcel-repo/，然后改一下manifest.json的权限，让 Server 能读到。

# 复制 parcel 文件 mkdir -p /opt/cloudera/parcel-repo cp /opt/cm-5.10.0/parcels/*.parcel /opt/cloudera/parcel-repo/ cp /opt/cm-5.10.0/parcels/*.sha /opt/cloudera/parcel-repo/ cp /opt/cm-5.10.0/parcels/manifest.json /opt/cloudera/parcel-repo/ # 修改权限 chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo

然后在 Web UI 的 Hosts 页面添加主机，输入 Agent 节点的主机名，CM 会自动分发 Agent 的 RPM 并启动。如果分发失败，多半是 Agent 节点的/etc/hosts没配好，或者 SSH 免密没做。CM 添加主机时默认用 root 用户和 SSH 密钥，所以提前在所有节点上配好 root 的免密登录会省很多事。

4.3 主机添加后的角色分配原则

主机添加成功后，CM 会要求你分配角色，比如 NameNode、DataNode、ResourceManager 等。我的习惯是先把管理角色（NameNode、ResourceManager）放在 Server 节点，数据角色（DataNode、NodeManager）放在 Agent 节点。如果机器少，也可以混布，但要注意内存和磁盘的隔离。分配完角色后，CM 会生成一堆配置并启动服务，这时候去 Clusters 页面看各个服务的健康状态，绿色才算正常。

5. 避坑排查：装 CM 5.10 时我踩过的五个坑

5.1 坑一：Agent 启动报 Python 模块缺失

现象：systemctl start cloudera-scm-agent后，日志里报ImportError: No module named MySQLdb。原因：CM 5.10 的 Agent 内部用 Python 2.7 写了一些脚本，依赖MySQL-python模块，但 CentOS 7 最小化安装没带。解决：用 yum 装MySQL-python，如果源里没有，就装python2-pip然后pip install MySQL-python。注意要装 Python 2 的版本，Python 3 的mysqlclient不兼容。

yum install -y MySQL-python # 或者 yum install -y python2-pip pip2 install MySQL-python

5.2 坑二：Server 启动卡在数据库连接池

现象：cloudera-scm-server.log里一直刷Waiting for database connection。原因：MySQL 的max_connections太小，或者db.properties里的密码有特殊字符没转义。解决：先把 MySQL 的max_connections调到 500 以上，然后检查db.properties里的password字段，如果有#或!，用引号包起来或者改成简单密码。

5.3 坑三：添加主机时提示“Agent 未响应”

现象：Web UI 添加主机时，进度条卡在“正在向 Agent 发送请求”。原因：Agent 节点的 7182 端口没监听，或者 Server 和 Agent 的时间不同步。解决：在 Agent 节点执行ss -tlnp | grep 7182确认端口，然后用ntpdate同步时间。CM 对时间敏感，差超过 5 分钟就会拒绝心跳。

# 同步时间 yum install -y ntpdate ntpdate ntp.aliyun.com

5.4 坑四：parcel 分发时提示哈希校验失败

现象：Web UI 里 parcel 状态显示“哈希不匹配”。原因：复制 parcel 文件时只复制了.parcel，没复制对应的.sha文件，或者manifest.json里的哈希值和实际文件对不上。解决：确保.parcel、.sha和manifest.json三个文件都在/opt/cloudera/parcel-repo/下，并且权限是cloudera-scm。如果还不行，删掉 parcel 重新下载。

5.5 坑五：服务启动后报“权限被拒绝”

现象：DataNode 或 NodeManager 启动失败，日志里报Permission denied。原因：CM 用cloudera-scm用户去启动服务，但数据目录的属主是 root。解决：把所有数据目录的属主改成cloudera-scm，或者改成hdfs、yarn等对应的服务用户。我一般用chown -R cloudera-scm:cloudera-scm /data/先统一，再按服务细分。

6. 装完怎么验证：三个必须跑一遍的检查项

装完 CM 5.10 不代表万事大吉，我见过太多“Web UI 全绿但实际跑任务就挂”的情况。所以每次装完，我都会强制走一遍下面三个检查，确认集群是真的能跑，而不是表面健康。

6.1 检查项一：用 hdfs dfsadmin 看 NameNode 状态

Web UI 的绿色图标有时候会骗人，最直接的方法是去 Server 节点执行 HDFS 的管理命令。如果 NameNode 没真正起来，这个命令会直接报连接失败。

# 切换到 hdfs 用户 sudo -u hdfs hdfs dfsadmin -report # 正常输出会显示 Live datanodes 数量和容量

如果报Connection refused，去 NameNode 日志里找java.net.BindException，多半是端口被占用或者dfs.namenode.rpc-address配错了。我一般会先netstat -tlnp | grep 8020确认端口，再去 CM 的 HDFS 配置页面搜NameNode相关的绑定地址。

6.2 检查项二：跑一个 WordCount 验证 YARN 和 MapReduce

HDFS 通了之后，用自带的hadoop-mapreduce-examples.jar跑一个 WordCount，这是验证 YARN 资源调度和 MapReduce 运行时的最快方法。如果这个能跑通，说明 ResourceManager、NodeManager 和容器执行环境都没问题。

# 准备输入文件 sudo -u hdfs hdfs dfs -mkdir -p /tmp/wordcount/input echo "hello cloudera manager" > /tmp/test.txt sudo -u hdfs hdfs dfs -put /tmp/test.txt /tmp/wordcount/input/ # 提交 WordCount 任务 sudo -u hdfs yarn jar /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar \ wordcount /tmp/wordcount/input /tmp/wordcount/output # 查看结果 sudo -u hdfs hdfs dfs -cat /tmp/wordcount/output/part-r-00000

如果任务卡在ACCEPTED状态不动，去 YARN 的 Web UI（通常是 8088 端口）看队列资源。常见原因是yarn.nodemanager.resource.memory-mb设得太小，容器申请不到内存。我一般会把 NodeManager 的内存调到物理内存的 80%，然后yarn.scheduler.minimum-allocation-mb设成 1024。

6.3 检查项三：Cloudera Manager 的健康检查与告警

CM 自带一个健康检查功能，在 Web UI 的“管理”->“健康检查”里可以手动触发。这个检查会跑一遍所有服务的连通性和配置一致性。我一般会重点看两个告警：一个是“时钟偏移”，一个是“交换分区使用率”。时钟偏移前面说过，用 ntpdate 解决；交换分区使用率过高说明物理内存不够，需要调vm.swappiness参数。

# 临时降低 swappiness sysctl vm.swappiness=10 # 永久生效 echo "vm.swappiness=10" >> /etc/sysctl.conf

另外，CM 的告警邮件默认是关的，如果想让集群出问题时能收到通知，去“管理”->“告警”里配 SMTP。我一般会配一个内部邮件中继，这样 NameNode 挂了或者磁盘满了能第一时间知道。

从那以后我每次装完 CM，不管 Web UI 多绿，都会强制跑一遍hdfs dfsadmin -report和 WordCount，确认数据能写能算。这套习惯帮我省了好几次“表面健康、实际瘫痪”的尴尬。希望帮到你。

本文还有配套的精品资源，点击获取