简介这份资源是面向大数据运维与Hadoop集群管理学习者的Cloudera Manager 5.14.2离线安装包专为CentOS 7环境准备解决在无外网或受限网络下部署CM管理平台的难题。压缩包共含18362个文件约793.9MB以py、pyo、pyc等Python运行与字节码文件、html与js前端页面、jar依赖库、ddl建表脚本、xml与properties配置、so动态库及sh启动脚本为主完整覆盖CM服务端、Agent、内置数据库与Web控制台所需组件。资源描述配套《Cloudera Manager在CentOS7上的安装与配置详解》涉及系统需求、Yum仓库配置、服务端与数据库初始化、Web界面访问、集群创建、监控告警及Kerberos安全实践等环节可帮助读者搭建并管理CDH集群。目前已有278人学习适合具备Linux与Hadoop基础、希望掌握Cloudera平台部署与运维的中高级用户参考。1. 离线部署 Cloudera Manager为什么一个 tar.gz 能决定集群能不能上线手里拿到cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz这个包的人大概率面对的是同一个场景生产环境没有外网或者外网访问被严格限制但业务又必须把一套 Hadoop 生态集群搭起来。在线安装靠 yum 源和 Cloudera 官方仓库一路 next 当然舒服可一旦机器出不了公网yum install cloudera-manager-server这条命令就直接卡死。这个 tar.gz 就是为这种场景准备的——它把 Cloudera Manager Server、Agent、Daemons 以及配套的 RPM 包全部打在一起解压后本地建源整条安装链路不依赖任何外部网络。它解决的核心问题是「离线环境下的集群管理平面搭建」。适合两类人一类是在隔离网络里做大数据平台交付的运维工程师另一类是需要在测试环境快速复现一套 CM 管理集群、又不想被在线源版本漂移折腾的开发者。CM 5.14.2 对应的是 CDH 5.14.x 系列基于 CentOS 7整套东西不算新但存量环境里跑的量依然很大踩坑资料也最全。2. 解压之前先想清楚CM 5.14.2 的组件构成与依赖关系2.1 这个 tar.gz 里到底装了什么把包解开之后目录结构通常长这样一个cm/目录放 Cloudera Manager 自身的 RPM一个cdh/目录放 CDH 各组件的 parcel 或 RPM外加一些manifest.json、cloudera-manager.repo之类的元数据文件。不同来源的打包方式略有差异但核心就三块CM Server 的安装包、CM Agent 的安装包、以及被管理组件Hadoop、Hive、Spark 等的安装介质。理解这个分层很关键。CM Server 是管理平面的大脑负责下发配置、调度服务、收集监控指标CM Agent 装在每个受管节点上听 Server 的指令去起停进程、拉取 parcelCDH 的 parcel 才是真正跑业务的运行时。很多人第一次装失败就是把这三层的安装顺序和依赖搞混了——Server 没起来就去装 AgentAgent 连不上 Server 又回头怀疑网络来回折腾。2.2 版本锁定带来的连锁约束CM 5.14.2 不是一个孤立版本它和 JDK、数据库、操作系统有明确的兼容矩阵。CentOS 7 上官方推荐 JDK 8具体来说是 Oracle JDK 8u 某个区间或 OpenJDK 8。数据库方面CM Server 自己的元数据库支持 MySQL、PostgreSQL、Oracle生产上 MySQL 5.7 用得最多。这里有个容易翻车的点MySQL 8.0 的默认认证插件和驱动兼容性在 CM 5.14.2 上并不好连元数据库时经常报认证失败所以老老实实上 MySQL 5.7 最稳。另一个约束是 Python。CM 5.14.2 的 Agent 和部分脚本依赖 Python 2.7CentOS 7 自带的就是 2.7这点刚好匹配。但如果你在系统里装了 Python 3 并改了默认指向Agent 启动脚本可能直接报语法错误。这不是 CM 的 bug是版本锁定带来的必然结果。2.3 离线源的组织方式离线安装的本质是把远程 yum 源换成本地文件源。有两种常见做法一种是用createrepo把 RPM 目录做成一个本地 repo通过 HTTP 或 file:// 暴露另一种是直接用 tar.gz 里自带的 repo 文件配合yum --disablerepo* --enablerepolocal来装。前者更灵活适合多节点后者更简单适合单机验证。我一般会选第一种因为集群规模一上来每台机器都去挂载同一个目录不现实起一个轻量 HTTP 服务比如 nginx 或 python -m SimpleHTTPServer把 repo 目录暴露出去所有节点统一指向这个地址后续加节点也不用改配置。3. 从零搭一套本地源并跑通 CM Server 安装3.1 准备工作目录规划与依赖检查先在作为管理节点的机器上规划好目录。我习惯把安装介质统一放在/opt/cloudera-media本地 repo 放在/var/www/html/cm-repoparcel 放/opt/cloudera/parcel-repo。这样分区清晰后面排查问题时知道去哪找文件。# 创建介质目录和 repo 目录 mkdir -p /opt/cloudera-media mkdir -p /var/www/html/cm-repo mkdir -p /opt/cloudera/parcel-repo # 解压 tar.gz 到介质目录 tar -xzvf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt/cloudera-media # 查看解压后的结构确认 RPM 和 parcel 的位置 find /opt/cloudera-media -maxdepth 3 -type d | head -30这段命令做完你应该能看到cm和cdh两个顶层目录。find那一步是为了确认打包结构不同来源的包目录层级可能差一层先看清楚再往下走比盲目复制命令强。依赖检查方面确认几件事java -version输出 1.8python --version输出 2.7systemctl status firewalld看防火墙状态测试环境可以先关生产环境要按需放行 7180、7182、8888 等端口getenforce看 SELinux建议设成 permissive 或按文档配策略否则 Agent 起进程时会被拦。3.2 用 createrepo 建立本地 yum 源把 RPM 集中到一个目录然后生成 repodata。# 把 CM 和 CDH 的 RPM 汇总到一个目录 find /opt/cloudera-media -name *.rpm -exec cp {} /var/www/html/cm-repo/ \; # 安装 createrepo 工具如果本机有网或者从系统盘里找 yum install -y createrepo # 生成 repodata createrepo /var/www/html/cm-repo/ # 起一个简单的 HTTP 服务暴露这个目录 cd /var/www/html python -m SimpleHTTPServer 80 createrepo会在目录下生成repodata/子目录里面是 RPM 的元数据索引。yum 客户端靠这个索引来解析依赖。HTTP 服务用 Python 自带的 SimpleHTTPServer 只是图方便生产上换成 nginx 更稳但验证阶段够用。然后在每台节点上配置 repo 文件# 在 /etc/yum.repos.d/ 下新建 local-cm.repo cat /etc/yum.repos.d/local-cm.repo EOF [local-cm] nameLocal Cloudera Manager Repo baseurlhttp://管理节点IP/cm-repo/ enabled1 gpgcheck0 EOF # 清理缓存并验证源可用 yum clean all yum repolistgpgcheck0是因为本地自建的源没有签名测试环境可以接受。生产环境如果在意完整性校验需要自己导入 GPG key 并开启检查。yum repolist能列出local-cm且包数量不为零说明源配通了。3.3 安装 CM Server 与 Agent 并初始化元数据库源通了之后安装本身反而简单。# 在管理节点安装 server 和 agent yum install -y cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent # 在所有受管节点安装 agent 和 daemons yum install -y cloudera-manager-agent cloudera-manager-daemons装完之后先别急着启动 Server元数据库还没初始化。CM Server 需要一个数据库来存配置和状态用 MySQL 的话先建库建用户-- 在 MySQL 中执行 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO scm% IDENTIFIED BY YourPassword; FLUSH PRIVILEGES;然后用 CM 自带的脚本初始化# 初始化 SCM 元数据库 /opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm YourPassword这个脚本会建表、写配置。执行成功后会提示Your SCM database is configured correctly!。如果报连接失败先检查 MySQL 的 bind-address 和用户权限再检查 JDBC 驱动是否在/usr/share/java/mysql-connector-java.jar。CM 5.14.2 对驱动版本有要求太新的驱动反而可能不认。启动 Serversystemctl start cloudera-scm-server # 跟踪日志等待出现 Started Jetty server tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到 Jetty 启动完成后浏览器访问http://管理节点IP:7180默认账号密码都是 admin。能进登录页说明 Server 这一层通了。4. 用 Parcel 分发 CDH 并调通 Agent 心跳4.1 Parcel 的放置与校验CM Server 起来只是管理平面就绪真正跑 Hadoop 还需要 CDH 的 parcel。tar.gz 里的 parcel 文件通常是.parcel和.parcel.sha两个文件要放到 Server 的 parcel-repo 目录。# 把 parcel 和校验文件复制到 parcel-repo cp /opt/cloudera-media/cdh/*.parcel /opt/cloudera/parcel-repo/ cp /opt/cloudera-media/cdh/*.parcel.sha /opt/cloudera/parcel-repo/ # 确认文件权限CM 以 cloudera-scm 用户读取 chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo/这里有个细节.parcel.sha文件里的哈希值必须和 parcel 实际内容匹配否则 CM 会认为文件损坏一直卡在「正在下载」或「校验失败」。如果 sha 文件丢失可以手动生成sha1sum xxx.parcel | awk {print $1} xxx.parcel.sha。但要注意 CM 期望的是 SHA1不是 SHA256。4.2 Agent 配置与心跳排查每个受管节点上的 Agent 需要知道 Server 在哪。配置文件在/etc/cloudera-scm-agent/config.ini关键项是server_host。# /etc/cloudera-scm-agent/config.ini 关键片段 [General] server_host管理节点IP server_port7182改完重启 Agentsystemctl restart cloudera-scm-agent。然后在 CM Web 界面的「主机」页面看是否能自动发现新节点。如果节点没出现按这个顺序查Agent 进程是否在跑、7182 端口是否通、/var/log/cloudera-scm-agent/cloudera-scm-agent.log里有没有连接被拒的记录。常见的一个坑是主机名解析。CM 对主机名很敏感如果 Agent 上报的是短名而 Server 记录的是 FQDN或者/etc/hosts里正反解不一致节点会显示成「不良」状态。统一用 FQDN 并在所有节点的/etc/hosts里写全能省掉大量玄学问题。4.3 分配 Parcel 并启动集群服务节点被识别后在 CM 界面里分配 parcel、激活然后走「添加服务」向导。向导会检查各节点的环境包括 JDK、Python、目录权限、时钟同步。这一步的检查项最好一条条过不要跳过。尤其是 NTP 时钟同步CM 对时间偏差敏感偏差大了监控数据会乱。启动 HDFS、YARN 这些服务时第一次启动慢是正常的因为要格式化 NameNode、创建目录。如果某个角色起不来先看该角色的日志再看 Agent 日志最后看 Server 日志这个顺序能覆盖绝大多数问题。5. 避坑指南离线装 CM 最容易翻车的五个地方5.1 坑一元数据库连不上报认证或驱动错误现象是scm_prepare_database.sh执行失败或者 Server 启动日志里刷Communications link failure。原因通常是三类MySQL 没授权远程访问、JDBC 驱动版本不对、或者密码里有特殊字符没转义。解决方法是先用mysql -h host -u scm -p手动验证连通性再确认/usr/share/java/mysql-connector-java.jar存在且版本在 5.1.x 区间最后检查脚本参数里的密码是否需要加引号。5.2 坑二Agent 装上了但节点一直不出现现象是 Web 界面主机列表为空。原因多半是 Agent 的server_host配错或者 7182 端口被防火墙拦了。解决方法是telnet server 7182测连通性检查 Agent 日志里的连接目标地址确认/etc/hosts正反解一致。还有一个隐蔽原因是 Agent 的 UUID 冲突——克隆虚拟机时如果没清理/var/lib/cloudera-scm-agent/uuid多台机器会用同一个 UUIDServer 只认一台。5.3 坑三Parcel 校验失败一直卡在分发中现象是 parcel 状态显示「正在下载」或「校验失败」。原因是.parcel.sha内容不对或者文件权限导致 CM 读不到。解决方法是手动核对 sha1 值确认 parcel-repo 目录属主是 cloudera-scm并检查 Server 日志里具体的校验报错信息。有时候是文件传输过程中损坏重新复制一遍就好。5.4 坑四服务启动时报目录权限或端口占用现象是 HDFS 或 YARN 的某个角色起不来日志里报Permission denied或Address already in use。原因是 CM 默认用各服务自己的系统用户跑进程如果目录属主不对或者上一个残留进程没清干净就会冲突。解决方法是按日志里的路径检查属主用ss -tlnp查端口占用必要时手动清理残留进程再重启。5.5 坑五时钟不同步导致监控数据错乱现象是 CM 界面里图表数据跳变、告警时间对不上。原因是节点间时间偏差超过阈值。解决方法是所有节点配同一个 NTP 源用chronyc sources或ntpq -p确认同步状态。这个坑不致命但很烦属于典型的「不影响跑但影响判断」的问题早点配好省心。6. 进阶技巧把离线部署做成可重复的流程走到这一步单套集群能跑起来了。但如果你要交付多套环境每次都手动敲命令迟早出错。我的习惯是把整个流程脚本化分成三个阶段准备阶段解压、建源、配 repo、安装阶段装包、初始化数据库、起 Server、纳管阶段配 Agent、分发 parcel、启动服务。每个阶段一个脚本中间用配置文件传参比如管理节点 IP、数据库密码、集群名称。验证一套离线 CM 是否装得健康我一般看四个指标Server 日志里没有持续报错、所有 Agent 心跳正常、parcel 状态是「已激活」、以及随便挑一个服务比如 HDFS做一次重启能成功。这四个都过基本可以交付。还有一个实用技巧是保留一份「最小可用」的 parcel 集合。CDH 的 parcel 动辄几个 G但实际业务可能只用 HDFS、YARN、Hive、Spark 这几个。把不需要的组件 parcel 剔掉能显著缩短分发时间也减少磁盘占用。CM 支持只分发已分配的 parcel所以介质准备阶段就可以做裁剪。最后说个血泪经验离线环境的介质一定要做校验和备份。tar.gz 在多次拷贝、U 盘传递过程中损坏的概率不低等到装到一半才发现包坏了现场又没有第二份那种感觉相当难受。我现在的习惯是拿到包先sha256sum记下来复制到目标环境后再校验一次确认一致再动手。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向大数据运维与Hadoop集群管理学习者的Cloudera Manager 5.14.2离线安装包专为CentOS 7环境准备解决在无外网或受限网络下部署CM管理平台的难题。压缩包共含18362个文件约793.9MB以py、pyo、pyc等Python运行与字节码文件、html与js前端页面、jar依赖库、ddl建表脚本、xml与properties配置、so动态库及sh启动脚本为主完整覆盖CM服务端、Agent、内置数据库与Web控制台所需组件。资源描述配套《Cloudera Manager在CentOS7上的安装与配置详解》涉及系统需求、Yum仓库配置、服务端与数据库初始化、Web界面访问、集群创建、监控告警及Kerberos安全实践等环节可帮助读者搭建并管理CDH集群。目前已有278人学习适合具备Linux与Hadoop基础、希望掌握Cloudera平台部署与运维的中高级用户参考。1. 离线部署 Cloudera Manager为什么一个 tar.gz 能决定集群能不能上线手里拿到cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz这个包的人大概率面对的是同一个场景生产环境没有外网或者外网访问被严格限制但业务又必须把一套 Hadoop 生态集群搭起来。在线安装靠 yum 源和 Cloudera 官方仓库一路 next 当然舒服可一旦机器出不了公网yum install cloudera-manager-server这条命令就直接卡死。这个 tar.gz 就是为这种场景准备的——它把 Cloudera Manager Server、Agent、Daemons 以及配套的 RPM 包全部打在一起解压后本地建源整条安装链路不依赖任何外部网络。它解决的核心问题是「离线环境下的集群管理平面搭建」。适合两类人一类是在隔离网络里做大数据平台交付的运维工程师另一类是需要在测试环境快速复现一套 CM 管理集群、又不想被在线源版本漂移折腾的开发者。CM 5.14.2 对应的是 CDH 5.14.x 系列基于 CentOS 7整套东西不算新但存量环境里跑的量依然很大踩坑资料也最全。2. 解压之前先想清楚CM 5.14.2 的组件构成与依赖关系2.1 这个 tar.gz 里到底装了什么把包解开之后目录结构通常长这样一个cm/目录放 Cloudera Manager 自身的 RPM一个cdh/目录放 CDH 各组件的 parcel 或 RPM外加一些manifest.json、cloudera-manager.repo之类的元数据文件。不同来源的打包方式略有差异但核心就三块CM Server 的安装包、CM Agent 的安装包、以及被管理组件Hadoop、Hive、Spark 等的安装介质。理解这个分层很关键。CM Server 是管理平面的大脑负责下发配置、调度服务、收集监控指标CM Agent 装在每个受管节点上听 Server 的指令去起停进程、拉取 parcelCDH 的 parcel 才是真正跑业务的运行时。很多人第一次装失败就是把这三层的安装顺序和依赖搞混了——Server 没起来就去装 AgentAgent 连不上 Server 又回头怀疑网络来回折腾。2.2 版本锁定带来的连锁约束CM 5.14.2 不是一个孤立版本它和 JDK、数据库、操作系统有明确的兼容矩阵。CentOS 7 上官方推荐 JDK 8具体来说是 Oracle JDK 8u 某个区间或 OpenJDK 8。数据库方面CM Server 自己的元数据库支持 MySQL、PostgreSQL、Oracle生产上 MySQL 5.7 用得最多。这里有个容易翻车的点MySQL 8.0 的默认认证插件和驱动兼容性在 CM 5.14.2 上并不好连元数据库时经常报认证失败所以老老实实上 MySQL 5.7 最稳。另一个约束是 Python。CM 5.14.2 的 Agent 和部分脚本依赖 Python 2.7CentOS 7 自带的就是 2.7这点刚好匹配。但如果你在系统里装了 Python 3 并改了默认指向Agent 启动脚本可能直接报语法错误。这不是 CM 的 bug是版本锁定带来的必然结果。2.3 离线源的组织方式离线安装的本质是把远程 yum 源换成本地文件源。有两种常见做法一种是用createrepo把 RPM 目录做成一个本地 repo通过 HTTP 或 file:// 暴露另一种是直接用 tar.gz 里自带的 repo 文件配合yum --disablerepo* --enablerepolocal来装。前者更灵活适合多节点后者更简单适合单机验证。我一般会选第一种因为集群规模一上来每台机器都去挂载同一个目录不现实起一个轻量 HTTP 服务比如 nginx 或 python -m SimpleHTTPServer把 repo 目录暴露出去所有节点统一指向这个地址后续加节点也不用改配置。3. 从零搭一套本地源并跑通 CM Server 安装3.1 准备工作目录规划与依赖检查先在作为管理节点的机器上规划好目录。我习惯把安装介质统一放在/opt/cloudera-media本地 repo 放在/var/www/html/cm-repoparcel 放/opt/cloudera/parcel-repo。这样分区清晰后面排查问题时知道去哪找文件。# 创建介质目录和 repo 目录 mkdir -p /opt/cloudera-media mkdir -p /var/www/html/cm-repo mkdir -p /opt/cloudera/parcel-repo # 解压 tar.gz 到介质目录 tar -xzvf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt/cloudera-media # 查看解压后的结构确认 RPM 和 parcel 的位置 find /opt/cloudera-media -maxdepth 3 -type d | head -30这段命令做完你应该能看到cm和cdh两个顶层目录。find那一步是为了确认打包结构不同来源的包目录层级可能差一层先看清楚再往下走比盲目复制命令强。依赖检查方面确认几件事java -version输出 1.8python --version输出 2.7systemctl status firewalld看防火墙状态测试环境可以先关生产环境要按需放行 7180、7182、8888 等端口getenforce看 SELinux建议设成 permissive 或按文档配策略否则 Agent 起进程时会被拦。3.2 用 createrepo 建立本地 yum 源把 RPM 集中到一个目录然后生成 repodata。# 把 CM 和 CDH 的 RPM 汇总到一个目录 find /opt/cloudera-media -name *.rpm -exec cp {} /var/www/html/cm-repo/ \; # 安装 createrepo 工具如果本机有网或者从系统盘里找 yum install -y createrepo # 生成 repodata createrepo /var/www/html/cm-repo/ # 起一个简单的 HTTP 服务暴露这个目录 cd /var/www/html python -m SimpleHTTPServer 80 createrepo会在目录下生成repodata/子目录里面是 RPM 的元数据索引。yum 客户端靠这个索引来解析依赖。HTTP 服务用 Python 自带的 SimpleHTTPServer 只是图方便生产上换成 nginx 更稳但验证阶段够用。然后在每台节点上配置 repo 文件# 在 /etc/yum.repos.d/ 下新建 local-cm.repo cat /etc/yum.repos.d/local-cm.repo EOF [local-cm] nameLocal Cloudera Manager Repo baseurlhttp://管理节点IP/cm-repo/ enabled1 gpgcheck0 EOF # 清理缓存并验证源可用 yum clean all yum repolistgpgcheck0是因为本地自建的源没有签名测试环境可以接受。生产环境如果在意完整性校验需要自己导入 GPG key 并开启检查。yum repolist能列出local-cm且包数量不为零说明源配通了。3.3 安装 CM Server 与 Agent 并初始化元数据库源通了之后安装本身反而简单。# 在管理节点安装 server 和 agent yum install -y cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent # 在所有受管节点安装 agent 和 daemons yum install -y cloudera-manager-agent cloudera-manager-daemons装完之后先别急着启动 Server元数据库还没初始化。CM Server 需要一个数据库来存配置和状态用 MySQL 的话先建库建用户-- 在 MySQL 中执行 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO scm% IDENTIFIED BY YourPassword; FLUSH PRIVILEGES;然后用 CM 自带的脚本初始化# 初始化 SCM 元数据库 /opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm YourPassword这个脚本会建表、写配置。执行成功后会提示Your SCM database is configured correctly!。如果报连接失败先检查 MySQL 的 bind-address 和用户权限再检查 JDBC 驱动是否在/usr/share/java/mysql-connector-java.jar。CM 5.14.2 对驱动版本有要求太新的驱动反而可能不认。启动 Serversystemctl start cloudera-scm-server # 跟踪日志等待出现 Started Jetty server tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到 Jetty 启动完成后浏览器访问http://管理节点IP:7180默认账号密码都是 admin。能进登录页说明 Server 这一层通了。4. 用 Parcel 分发 CDH 并调通 Agent 心跳4.1 Parcel 的放置与校验CM Server 起来只是管理平面就绪真正跑 Hadoop 还需要 CDH 的 parcel。tar.gz 里的 parcel 文件通常是.parcel和.parcel.sha两个文件要放到 Server 的 parcel-repo 目录。# 把 parcel 和校验文件复制到 parcel-repo cp /opt/cloudera-media/cdh/*.parcel /opt/cloudera/parcel-repo/ cp /opt/cloudera-media/cdh/*.parcel.sha /opt/cloudera/parcel-repo/ # 确认文件权限CM 以 cloudera-scm 用户读取 chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo/这里有个细节.parcel.sha文件里的哈希值必须和 parcel 实际内容匹配否则 CM 会认为文件损坏一直卡在「正在下载」或「校验失败」。如果 sha 文件丢失可以手动生成sha1sum xxx.parcel | awk {print $1} xxx.parcel.sha。但要注意 CM 期望的是 SHA1不是 SHA256。4.2 Agent 配置与心跳排查每个受管节点上的 Agent 需要知道 Server 在哪。配置文件在/etc/cloudera-scm-agent/config.ini关键项是server_host。# /etc/cloudera-scm-agent/config.ini 关键片段 [General] server_host管理节点IP server_port7182改完重启 Agentsystemctl restart cloudera-scm-agent。然后在 CM Web 界面的「主机」页面看是否能自动发现新节点。如果节点没出现按这个顺序查Agent 进程是否在跑、7182 端口是否通、/var/log/cloudera-scm-agent/cloudera-scm-agent.log里有没有连接被拒的记录。常见的一个坑是主机名解析。CM 对主机名很敏感如果 Agent 上报的是短名而 Server 记录的是 FQDN或者/etc/hosts里正反解不一致节点会显示成「不良」状态。统一用 FQDN 并在所有节点的/etc/hosts里写全能省掉大量玄学问题。4.3 分配 Parcel 并启动集群服务节点被识别后在 CM 界面里分配 parcel、激活然后走「添加服务」向导。向导会检查各节点的环境包括 JDK、Python、目录权限、时钟同步。这一步的检查项最好一条条过不要跳过。尤其是 NTP 时钟同步CM 对时间偏差敏感偏差大了监控数据会乱。启动 HDFS、YARN 这些服务时第一次启动慢是正常的因为要格式化 NameNode、创建目录。如果某个角色起不来先看该角色的日志再看 Agent 日志最后看 Server 日志这个顺序能覆盖绝大多数问题。5. 避坑指南离线装 CM 最容易翻车的五个地方5.1 坑一元数据库连不上报认证或驱动错误现象是scm_prepare_database.sh执行失败或者 Server 启动日志里刷Communications link failure。原因通常是三类MySQL 没授权远程访问、JDBC 驱动版本不对、或者密码里有特殊字符没转义。解决方法是先用mysql -h host -u scm -p手动验证连通性再确认/usr/share/java/mysql-connector-java.jar存在且版本在 5.1.x 区间最后检查脚本参数里的密码是否需要加引号。5.2 坑二Agent 装上了但节点一直不出现现象是 Web 界面主机列表为空。原因多半是 Agent 的server_host配错或者 7182 端口被防火墙拦了。解决方法是telnet server 7182测连通性检查 Agent 日志里的连接目标地址确认/etc/hosts正反解一致。还有一个隐蔽原因是 Agent 的 UUID 冲突——克隆虚拟机时如果没清理/var/lib/cloudera-scm-agent/uuid多台机器会用同一个 UUIDServer 只认一台。5.3 坑三Parcel 校验失败一直卡在分发中现象是 parcel 状态显示「正在下载」或「校验失败」。原因是.parcel.sha内容不对或者文件权限导致 CM 读不到。解决方法是手动核对 sha1 值确认 parcel-repo 目录属主是 cloudera-scm并检查 Server 日志里具体的校验报错信息。有时候是文件传输过程中损坏重新复制一遍就好。5.4 坑四服务启动时报目录权限或端口占用现象是 HDFS 或 YARN 的某个角色起不来日志里报Permission denied或Address already in use。原因是 CM 默认用各服务自己的系统用户跑进程如果目录属主不对或者上一个残留进程没清干净就会冲突。解决方法是按日志里的路径检查属主用ss -tlnp查端口占用必要时手动清理残留进程再重启。5.5 坑五时钟不同步导致监控数据错乱现象是 CM 界面里图表数据跳变、告警时间对不上。原因是节点间时间偏差超过阈值。解决方法是所有节点配同一个 NTP 源用chronyc sources或ntpq -p确认同步状态。这个坑不致命但很烦属于典型的「不影响跑但影响判断」的问题早点配好省心。6. 进阶技巧把离线部署做成可重复的流程走到这一步单套集群能跑起来了。但如果你要交付多套环境每次都手动敲命令迟早出错。我的习惯是把整个流程脚本化分成三个阶段准备阶段解压、建源、配 repo、安装阶段装包、初始化数据库、起 Server、纳管阶段配 Agent、分发 parcel、启动服务。每个阶段一个脚本中间用配置文件传参比如管理节点 IP、数据库密码、集群名称。验证一套离线 CM 是否装得健康我一般看四个指标Server 日志里没有持续报错、所有 Agent 心跳正常、parcel 状态是「已激活」、以及随便挑一个服务比如 HDFS做一次重启能成功。这四个都过基本可以交付。还有一个实用技巧是保留一份「最小可用」的 parcel 集合。CDH 的 parcel 动辄几个 G但实际业务可能只用 HDFS、YARN、Hive、Spark 这几个。把不需要的组件 parcel 剔掉能显著缩短分发时间也减少磁盘占用。CM 支持只分发已分配的 parcel所以介质准备阶段就可以做裁剪。最后说个血泪经验离线环境的介质一定要做校验和备份。tar.gz 在多次拷贝、U 盘传递过程中损坏的概率不低等到装到一半才发现包坏了现场又没有第二份那种感觉相当难受。我现在的习惯是拿到包先sha256sum记下来复制到目标环境后再校验一次确认一致再动手。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
