简介这是一份面向CentOS 7大数据环境离线部署的Cloudera Manager 5.10.0安装包主要服务于需要搭建CDH集群的运维工程师和数据平台管理员。压缩包内含cm-5.10.0与cloudera两个目录可在无外网条件下完成CM代理、服务端及CDH组件的安装和配置避免在线源不稳定带来的版本匹配与下载耗时问题。资源共2000个文件大小约615.94MB包括2800余个Python脚本及编译产物、1600余个JAR依赖包、2400余个HTML页面、大量JS/CSS前端资源以及DDL、SQL、Properties、Conf等配置类文件覆盖Web管理界面、后端服务、数据库初始化和组件启停等核心模块便于离线分发和批量部署。目前已有825人浏览学习适合希望获取完整CM安装介质并参照部署说明搭建本地集群的技术人员使用。1. 离线安装 CM 5.10.0装到一半翻车的人多半栽在环境上大数据环境里Cloudera Manager 5.10 配 CentOS 7 是挺经典的存量组合。手头这份 cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz已经省掉了在线下载的漫长等待但离线归离线装之前没把 JDK、SELinux、数据库驱动理清楚装完照样起不来。我见过太多人卡在同一处包解压好了rpm 也装了最后 Web 界面要么打不开要么 agent 心跳全红。我按实际装通的过程把环境准备、MySQL、本地 yum 源、初始化命令和日志排错完整走一遍适合正在给大数据集群补环境的开发者也适合第一次接触 CM 离线部署的运维新手。2. 环境准备JDK、hosts、SELinux、NTP四件事一次做完2.1 先装 Oracle JDK 1.8别让系统默认 JDK 搅局CM 5.10 的启动脚本和底层组件对 JDK 版本非常敏感。CentOS 7 默认源里的 JDK 往往带的是老 OpenJDK要是系统里还存在更高版本CM 5.10 的老代码在类加载阶段就会闹脾气日志里全是 UnsupportedClassVersionError排错成本极高。我一般一上来就装 JDK 1.8 的 x86_64 rpm 包文件名类似 jdk-8uXXX-linux-x64.rpm小版本选 8u144 之后含的版本都行CM 5.10 认的是 1.8 这个大版本。rpm -ivh jdk-8uXXX-linux-x64.rpm ln -s /usr/java/jdk1.8.0_XXX /usr/java/default java -version第一行把 JDK rpm 包装上第二行建立 default 软链接第三行验证版本输出。注意第二行的目录名必须对应当前实际装的版本别照抄否则软链接是断的。确认输出里含 1.8.0_XXX 再往后走。CM 的 cloudera-scm-server 启动脚本会找 /usr/java/default 这个固定路径系统里就算装过其他 JDK只要这个软链接存在CM 就认它这一条很多人不知道容易踩。顺手把 JAVA_HOME 写进 /etc/profile.d/java.sh后面装 CDH parcel 里的组件时也会读它。echo export JAVA_HOME/usr/java/default /etc/profile.d/java.sh echo export PATH$JAVA_HOME/bin:$PATH /etc/profile.d/java.sh source /etc/profile.d/java.sh第一行创建环境变量脚本第二行追加 PATH第三行让当前 shell 立即生效。别写到 /etc/profile 里那是登录 shell 才加载的地方systemd 起的 CM 服务不会读它。2.2 hosts 与主机名先定名字后面所有配置都跟着走CM 的 server 和 agent 之间通信用主机名。不写 /etc/hosts 的话agent 第一次注册时大概率报无法解析主机名或者被解析到 127.0.0.1 这种本地回环上之后管理界面里看到的节点状态全是灰色。我在所有节点上统一做一件事把 server 主机名和 IP 的静态映射写进 /etc/hosts同时保证 hostname 命令输出的名字与映射一致。192.168.1.20 cm-server 192.168.1.21 cm-agent01第一行是 CM server 节点第二行是后续要纳管的 agent 节点。cm-server 和 cm-agent01 是我起的示例名部署时换成自己的主机名。写完后用 getent hosts cm-server 确认能解析出内网 IP。主机名里别用下划线CM 对下划线主机名的支持很差我遇到过一次 agent 注册后立刻掉线查了一圈最后发现是主机名带下划线。主机名建议用 hostnamectl set-hostname 设置它会同步修改好几个相关配置比手动改 /etc/hostname 稳妥。2.3 关闭 SELinux防火墙提前放行 7180 和 7182SELinux 在 enforcing 状态下CM 的 agent 向 server 建连、Web 界面读取监控数据这些操作都可能被策略拦掉表现又很隐蔽日志里不会直接告诉你被 SELinux 拒了。我装 CM 类产品一律先关它实验环境尤其别犹豫。sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config setenforce 0 getenforce第一条修改配置文件保证重启后仍是 disabled第二条临时关闭当前内核状态第三条输出应为 Permissive 或 Disabled。注意别只做第二条很多人漏了改 config重启后又回到 enforcingagent 起得莫名其妙地慢。防火墙这边内网实验环境直接停掉 firewalld 最省事如果生产必须保留至少放行 7180 和 7182 两个端口一个给 Web 界面一个给 server 与 agent 通信。用 firewall-cmd --permanent --add-port7180/tcp --add-port7182/tcp 加 reload 就能生效但别顺手把其他大数据组件的端口忘了那要等装 CDH 的时候再补。2.4 NTP 时间同步agent 心跳消失先看时间CM 对时间戳很较真server 和 agent 时间差超过一定范围时日志里不会直接写“时间不对”而是出现 agent 注册成功但心跳一直断的现象或者管理界面显示“主机上次心跳时间在几分钟前”。我处理过的离线集群问题里有一半最后都查出是某台机器时间漂了。常见做法是所有节点装 ntpserver 节点同步时间源agent 节点指向 server 节点。yum install -y ntp systemctl enable ntpd systemctl start ntpd ntpdate -u 192.168.1.20前三条是安装并常驻 ntpd第四条是首轮手动校时192.168.1.20 是假设的 ntp server 地址。手动校时在做心跳排查时很管用跑完后再过一两分钟看 agent 日志心跳恢复得就很快。CentOS 7 上如果系统还开着 chronyd记得先停掉它两个时间服务会抢同一个配置行为不可预测。3. 配置 MySQL 元数据库scm 库、账号与 JDBC 驱动三件套3.1 数据库选型CentOS 7 自带 MariaDB 还是另装 MySQLCM 5.10 那个年代支持的数据库组合主要是 MySQL 5.6 / 5.7 和 MariaDB 5.5。CentOS 7 自带 MariaDB 5.5省事直接 yum 装完就能用。不过我实际部署时更倾向装 MySQL 5.7CM 的监控数据是持续写入的5.5 和 5.7 在性能和事务行为上有差别而且后面给 Hive、Oozie 建库时用 MySQL 的兼容面更宽。如果一个环境之前已经用 MariaDB 跑过也不一定要推倒重来只要库字符集是 utf8 就能继续。数据库CM 5.10 兼容性备注MySQL 5.6 / 5.7兼容建议优先初始化脚本和组件适配成熟MariaDB 5.5兼容CentOS 7 自带小规模集群够用MySQL 8.x不建议认证插件和字符集行为差异大MariaDB 10.x不推荐CM 5.10 时代支持有限装完 MariaDB 后启动并做基础加固systemctl start mariadb systemctl enable mariadb mysql_secure_installation第一行启动服务第二行开机自启第三行清掉匿名账号和默认测试库。mysql_secure_installation 交互里一路选 yes最后给 root 设个密码后面初始化脚本要用。如果已经选了 MySQL 5.7启动命令换成 systemctl start mysqld初始化密码会写在 /var/log/mysqld.log 里用 grep temporary password 取出来再改MariaDB 和 MySQL 在这一步行为不太一样。3.2 建 scm 库和账号host 尽量用 %避免连接方式被卡死CM server 通过 JDBC 连 MySQL连接地址默认是 localhost但实际配置里很容易写成内网 IP。我建账号的时候习惯把 localhost 和 % 都授权了省得之后改 db.properties 时还要回头补一次授权那一步漏了会一直看到 Access denied。建库这一步只处理 scm 库就够后续 Hive、Oozie 的库可以等装 CDH 时在界面上再建到时候单独分配账号权限收敛一些更安全。mysql -uroot -p CREATE DATABASE scm DEFAULT CHARACTER SET utf8; CREATE USER scm% IDENTIFIED BY scm_passwd; GRANT ALL PRIVILEGES ON scm.* TO scm%; GRANT ALL PRIVILEGES ON scm.* TO scmlocalhost; FLUSH PRIVILEGES;第一行进入 MySQL 命令行第二行建库并指定 utf8后面几行分别建账号和授权。CM 5.10 对字符集敏感库字符集不设 utf8 的话导入 schema 时中文注释和监控字符串都可能变成乱码。scm_passwd 记得换成自己的强密码。建完检查一下授权是否生效SELECT User, Host FROM mysql.user; 能看到 scm 的两行记录就行。3.3 JDBC 驱动放对位置路径错了直接报 Driver not foundscm_prepare_database.sh 执行时会在 /usr/share/java/ 下找 mysql-connector-java.jar而且只认这个不带版本号的文件名。路径错一位或者文件名带后缀报错都是 Driver not found。我见过有人把驱动放在 /usr/local/lib 下配了 CLASSPATH 也还是不行因为 CM 的脚本不读 CLASSPATH只按固定路径找。mkdir -p /usr/share/java tar zxf mysql-connector-java-5.1.45.tar.gz cp mysql-connector-java-5.1.45/mysql-connector-java-5.1.45-bin.jar /usr/share/java/mysql-connector-java.jar ls -l /usr/share/java/mysql-connector-java.jar第一行创建目录第二行解压驱动包第三行复制并重命名为 CM 要求的文件名第四行确认文件存在。如果你装的是 mysql-connector-java 的 rpm 包它自带的路径通常就在 /usr/share/java/ 下直接建个软链指向同名文件就行。注意有些发行版会把驱动放在 /usr/share/java 的子目录里CM 一律不认必须平铺在 java 目录本身。想确认驱动能加载可以跑 jar tf /usr/share/java/mysql-connector-java.jar | head能看到 com/mysql/jdbc/Driver 这类路径就说明文件完整。4. 解压与安装 CM 5.10.0从 tar.gz 到本地 yum 源4.1 解压后先看目录RPMS 和 repodata 是重点mkdir -p /opt/cloudera tar zxf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz -C /opt/cloudera ls -l /opt/cloudera第一行建目标目录第二行解压到 /opt/cloudera第三行看目录结构。解压完先确认实际目录名通常是 cm-5.10.0 或 cloudera-manager后面的路径都要基于它来写别凭记忆硬套。目录里一般会看到 RPMS、etc 等子目录RPMS/x86_64/ 下躺着 daemons、server、agent、server-db 等一堆 rpm这是我们安装的主要来源。如果目录里有 repodata 文件说明这个离线包已经带好了仓库索引可以直接给 yum 用没有的话就得先建索引。包里常见的 rpm 文件名前缀包名前缀作用是否安装cloudera-manager-daemons基础守护进程server 和 agent 都依赖必装cloudera-manager-serverCM 服务端跑 Web 界面和集群管理必装cloudera-manager-agent被管节点上的客户端程序必装cloudera-manager-server-db内嵌 PostgreSQL 的数据库包不装走外部 MySQL先记录实际目录名再用下面命令检查 repodataexport CM_DIR/opt/cloudera/cm-5.10.0 ls $CM_DIR/RPMS/x86_64/repodata有输出就说明包里自带仓库索引可以跳过 createrepo直接看 4.2 的仓库文件字段没有 repodata 目录的话就按 4.2 的 createrepo 流程先生成索引再配置仓库文件。export 那条命令里的路径要替换成实际解压出来的目录名后面 4.2 的命令也都要沿用这个变量。4.2 搭建本地 yum 源绕开在线 repo 的不确定性CM 5.10 的在线仓库源在公网上解析慢、连接时常中断yum 装到一半断掉rpm 数据库就乱了再装要处理一堆残留。离线包的价值就在这里把它变成本地 repo安装过程完全可控。缺 repodata 时先装 createrepo这也是 CentOS 7 基础源里的工具装它不会引入额外负担。yum install -y createrepo createrepo $CM_DIR/RPMS/x86_64/ cat /etc/yum.repos.d/cloudera-manager.repo EOF [cloudera-manager] nameCloudera Manager 5.10 Local Repo baseurlfile:///opt/cloudera/cm-5.10.0/RPMS/x86_64/ enabled1 gpgcheck0 EOFcreaterepo 跑完后repo 文件里的 baseurl 指向刚才那个目录。gpgcheck0 是因为离线包不一定携带可信任的签名 key开着 gpgcheck 反而装不上。写完仓库配置文件后执行 yum clean all yum makecache 重建缓存再用 yum list | grep cloudera-manager 确认能看到包名列表。这里常见的报错是 baseurl 写错路径yum makecache 时报 could not open/read repomd.xml多半是路径多写或少写了一层目录。报错时先确认 $CM_DIR 变量指向的目录里确实有 repodata 目录再看 repo 文件里的 baseurl 和实际路径一不一致。4.3 安装 RPMdaemons 先装再装 server 和 agent依赖关系大致是 cloudera-manager-daemons 为底座server 和 agent 都依赖它server-db 只给内嵌 PostgreSQL 用走外部 MySQL 的话不装。安装顺序建议 daemons、server、agent 三步走用 yum 而不是 rpm -ivh依赖会自动补全不用手动翻着找依赖包。yum install -y cloudera-manager-daemons yum install -y cloudera-manager-server yum install -y cloudera-manager-agent第一条先装 daemons第二条装 server第三条装 agent。执行完检查关键配置文件是否存在ls /etc/cloudera-scm-server/ ls /etc/cloudera-scm-agent/分别能看到 db.properties 和 config.ini 时说明包装活了。此时注意 agent 的 config.ini 里 server_host 默认是 localhost要改成 CM server 的主机名不改的话 agent 只会找本机纳管必失败。这里也提一句为什么不装 server-db它内嵌了一套 PostgreSQL适合只跑单机演示的场景但正式环境里 MySQL 已经建好了再启一套数据库纯属给自己增加维护负担。5. 初始化数据库与启动服务常见启动失败与日志排查5.1 用 scm_prepare_database.sh 初始化 scm 库安装完 server 后/usr/share/cmf/schema/ 下会有一个 scm_prepare_database.sh这是 CM 的数据库初始化脚本负责把 schema 灌进 scm 库并把连接参数写进 /etc/cloudera-scm-server/db.properties。/usr/share/cmf/schema/scm_prepare_database.sh mysql -h localhost -u root -p --scm-host cm-server scm scm scm_passwd参数拆开看mysql 是数据库类型-h 指向 MySQL 地址-u root 和 -p 表示用管理员身份执行--scm-host 写 CM server 自己的主机名后面三个参数依次是库名 scm、账号 scm、密码 scm_passwd。跑完后没有报错db.properties 里会多出 com.cloudera.cmf.db.host、db.name、db.user 等配置。这一步最常见的失败就是 JDBC 驱动找不到按第 3.3 节把驱动放好重跑即可脚本本身没有副作用可以反复执行。也可以先 cat /etc/cloudera-scm-server/db.properties 看看四行关键配置是否和自己建库时一致不一致就手动改掉再重启服务改完注意文件属主要保持 cloudera-scm 用户可读。5.2 启动服务日志才是真正的黑匣子启动命令很简单但排错必须看日志。先启动 server再启动 agent顺序别颠倒agent 启动时会立刻尝试向 server 注册server 没起来的话留给你的只有一串 connection refused。systemctl start cloudera-scm-server systemctl start cloudera-scm-agent tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log第一条启动服务端第二条启动客户端第三条实时看服务端日志。server 首次启动要初始化 Jetty Web 容器和数据库连接通常要一两分钟看到日志里出现 Started Jetty server 类似字样说明 Web 端已就绪。agent 日志在 /var/log/cloudera-scm-agent/cloudera-scm-agent.log里面会周期性地出现注册和心跳记录。这里有一条经验不要靠 systemctl status 的 active 判断一切正常CM 的 active 只代表进程活着不代表业务就绪唯一可靠的是日志关键字和端口监听状态。看日志时如果刷的报错看不懂先记下出现时间再配合前后几行一起分析CM 的日志写得还算规矩错误基本都会落在 Spring 初始化、Hibernate 连接、Jetty 启动这三块附近。5.3 高频坑现象、原因、解决第一个是 Java 版本不对。现象cloudera-scm-server 启动后日志里刷 class 版本异常进程反复重启原因系统默认 JDK 是 11CM 5.10 的老代码不认解决按第 2.1 节装 JDK 1.8 并把 /usr/java/default 指过去重启服务。第二个是 agent 连不上 server。现象agent 日志里报 connect refused 或解析不了主机名Web 界面上节点心跳一直是灰的原因/etc/cloudera-scm-agent/config.ini 里的 server_host 还是 localhost或者 /etc/hosts 没写映射解决改 server_host 为 server 节点主机名补好 hosts重启 agent。第三个是数据库连接失败。现象server 日志反复报 Communications link failure 或 Access denied for user scm原因MySQL 的 bind-address 只监听 127.0.0.1而 JDBC 走了内网 IP或者 scm 账号授权没覆盖来源地址解决my.cnf 里设 bind-address0.0.0.0 后重启 MySQL再确认 scm 账号有 % 授权。第四个是时间不同步这种玄学问题。现象agent 注册成功但心跳立刻消失过一阵又恢复原因server 和 agent 时间差超过阈值解决全套 ntp 同步手动 ntpdate 校时后观察日志别等着它自己慢慢校准。第五个是防火墙和 SELinux 双重夹击。现象本机 curl 7180 通但浏览器远程访问超时原因firewalld 没放行或 SELinux 策略拦截解决按第 2.3 节处理实验环境直接关闭生产环境精确放行端口别在生产上为了省事把 SELinux 关了还不记录变更。6. 验证跑通7180 端口、agent 心跳与浏览器界面6.1 端口与进程检查命令预期结果用途ss -tunlp | grep -E 7180|7182有 LISTEN 记录确认服务端端口就绪curl -I http://cm-server:7180返回 HTTP 302 之类响应确认 Web 服务可访问systemctl status cloudera-scm-serveractive (running)确认守护进程存活curl 返回 302 是正常的CM 会把未登录请求重定向到登录页。如果 curl 连接被拒回到日志排查重点看 5.2 里提到的几类报错。6.2 登录界面与 agent 心跳浏览器打开 http://cm-server:7180默认账号 admin密码 admin。登录后首页会列出纳入管理的节点。agent 状态应该是绿色recent heartbeat 在 1 分钟以内。如果 agent 状态异常按 5.3 的清单逐条核对不要在界面上反复重启重启解决不了配置问题。首次登录后要先走授权许可、CDH parcel 上传这些向导步骤这个阶段不要急着点先把 agent 心跳稳住再进入下一步安装 CDH 组件。parcel 上传到 managed host 也是会走网络传输的这时候如果 agent 掉线上传大概率失败所以心跳是否稳定是后续所有操作的前提。6.3 之后的部署习惯从那次踩了主机名下划线和 JDBC 驱动路径两个坑之后每次装 CM 5.10 这套环境我都会强制走一遍完整流程先确认 JDK 1.8 的软链再刷一遍 hosts关闭 SELinux数据库初始化成功后才启动服务。整套流程里最折腾的从来不是 tar 包解压而是环境参数里那些看不见的依赖与路径问题。希望这份记录能帮你在装 CM 5.10 时少走点弯路希望帮到你。本文还有配套的精品资源点击获取
