简介面向需要在CentOS 7上离线部署Cloudera Manager的大数据运维与平台工程师这份cm5.14.2_x86_64安装包提供了完整的管理端与Agent组件可解决无外网环境下Hadoop集群统一部署、监控与配置管理的难题。包内共18362个文件以Java归档库jar、Python脚本py/pyc/pyo、Web控制台静态资源html/js/css、服务配置文件xml/conf/properties、数据库DDL脚本与动态链接库so等为主覆盖服务端、代理端、内置数据库、Supervisor进程守护及监控组件压缩包约793.9MB结构基本对应CM标准安装目录便于离线装机和排查依赖。已有276人学习下载适合参照配套的《Cloudera平台搭建》博客离线搭建CM并通过7180端口完成CDH集群配置。资源不仅包含安装介质还带有初始化数据库、启动守护进程所需的脚本与配置模板能在防火墙隔离或内网环境下快速落地避免逐一下载依赖的繁琐流程是构建可复现大数据实验环境的基础包。 看到cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz这个文件名我猜你现在的处境跟我差不多要么接手了一套跑了好几年的 CDH 老集群要么手里有一台网络隔离得干干净净的 CentOS 7 机器外网连不上官网下载入口早就没了唯一能指望的就是当初拷下来的这个 tar.gz。CDH 5.14.2 放到今天不算新但它和 CentOS 7 的配合实在太成熟尤其离线部署能力非常能打——一个管理端安装包加上几个 parcel 文件完全不需要外网也能把 HDFS、Hive、HBase 这一整套拉起来。这篇文章不聊理论就把我从裸机到集群可用的完整过程、用到的命令、以及反复踩过的坑全部摊开讲给同样要在隔离环境里做部署的同学当一份参考。1. 这个安装包和 CDH 的关系先搞清楚再动手很多新手容易把 Cloudera ManagerCM和 CDH 当成同一个东西。CM 是管理平台负责装 Agent、分发 parcel、监控和配置集群CDH 才是真正跑 Hadoop 生态组件的发布包。你手里的cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz只包含 CM 5.14.2 的管理端和 Agent 程序CDH 本身需要另外准备 parcel 文件。解压这个包之后你会看到几个关键内容cloudera-manager-installer.bin在线引导安装器离线环境基本用不上、RPMS/目录里面是 cloudera-manager-server、cloudera-manager-agent、cloudera-manager-daemons 等 rpm以及一堆配置文件模板。生产环境里我习惯不直接跑 installer.bin而是手动解压、手动创建用户、手动启动服务这样每一步出问题都能看日志定位不会被引导脚本把细节吞掉。为什么选 CM 5.14.2 而不是更新的版本说实话一部分原因是存量系统的元数据本来就是 CDH 5.14.x 的升级牵扯太大另一部分原因是 5.x 分支的部署逻辑相对简单。Cloudera 后来 6.x、7.x 的许可证模型和安装复杂度都在上升很多离线环境根本不给你折腾的空间。5.14.2 配合 CentOS 7 的 x86_64 镜像算是一套经典组合网上能搜到的踩坑记录也最全。当然如果你手头是 CDH 6.3.2 的包部署思路大体相似只是 parcel 版本和依赖检查有些差别但那份工作改天再单独写。2. 环境准备先把三个卡脖子的点解决掉2.1 CentOS 7 停止维护后的 yum 源修复第一个要处理的就是热门搜索里那条cannot find a valid baseurl for repo: base/7/x86_64。CentOS 7 停止维护之后默认的 mirrorlist.centos.org 已经不再指向有效仓库你只要在某台机器上执行 yum install就会看到这条报错。更麻烦的是CM 的 Agent 在安装依赖时也可能会偷偷调 yum所以这个坑不提前填后面处处被绊。如果你能连外网最省事的是把 yum 源切换到 vaultsed -i s|^mirrorlist|#mirrorlist|g; s|^#baseurlhttp://mirror.centos.org|baseurlhttp://vault.centos.org|g /etc/yum.repos.d/CentOS-*.repo yum clean all yum makecache如果机房彻底隔离就用本地 ISO 做源。CentOS-7-x86_64-DVD-2009.iso 或 Everything 版本都行挂载后写一个 local.repomkdir -p /mnt/centos7 mount -o loop /path/to/CentOS-7-x86_64-DVD-2009.iso /mnt/centos7 cat /etc/yum.repos.d/local.repo EOF [local] namecentos7-local baseurlfile:///mnt/centos7 gpgcheck0 enabled1 EOF yum clean all yum makecache我的建议是不管有没有外网部署之前把所有节点的基础依赖psmisc、lsof、rsync、ntpdate、wget先装齐。CM 安装过程中临时缺包是最被动的局面因为你往往找不到一个正在运行的包管理器环境去补。2.2 主机名、hosts 与 SSH 免密CDH 对主机名的执念比一般 Linux 服务强得多。CM 的 Agent 注册依赖 FQDN你在/etc/hosts里写死了node1.local就必须在所有节点上统一这份映射并且保证每台机器的hostname -f能正确反解析。这里最容易犯的错是想当然地只改/etc/hostname结果反解析对不上CM 控制台里主机一直显示 Host not found。另外新装 CentOS 7 默认可能走 DHCP节点重启后 IP 一变整个集群的 hosts 映射就废了。所以装完系统第一件事就是配静态 IP确保/etc/hosts里的映射在重启后依然成立。我通常会先在所有节点上做三件事hostnamectl set-hostname cm-server.local # 按节点替换 cat /etc/hosts EOF 192.168.10.11 cm-server.local 192.168.10.12 data1.local 192.168.10.13 data2.local EOF ssh-keygen -t rsa -N -f ~/.ssh/id_rsa ssh-copy-id rootdata1.local ssh-copy-id rootdata2.localCM 的 Agent 安装阶段会从 Server 节点向其他节点同步配置没有免密登录的话你会在 Web 向导里反复输入密码心情会非常差。2.3 JDK、专用用户和基础参数CM 5.x 对 JDK 的要求是 1.8Oracle JDK 或 OpenJDK 都可以。这里提醒一句如果你在搜 CentOS 7 装 JDK 11那大概率是拿新应用镜像的习惯迁移到了 CDH 上但 CDH 5.14.2 的组件基本只认 Java 8强行用 JDK 11 会在 Hive、HBase 启动时冒出一堆奇怪的类加载错误。版本匹配这件事CM 比别的软件都敏感。离线环境里我建议提前把 jdk-8uXXX-linux-x64.tar.gz 放到所有节点统一安装到/usr/java/jdk1.8.0_xxx。CM 的 Agent 进程会去找/usr/java/default所以装完建个软链最稳ln -s /usr/java/jdk1.8.0_xxx /usr/java/default创建 CM 专用用户也是老规矩useradd --system --home/opt/cloudera-manager/cm-5.14.2/run/cloudera-scm-server --shell/bin/false cloudera-scm同时顺手把透明大页THP和 swap 的检查项提前处理掉这个后面第 5 节细说但如果你想一次通过 Web 向导的主机检查现在可以先执行echo never /sys/kernel/mm/transparent_hugepage/defrag echo never /sys/kernel/mm/transparent_hugepage/enabled sysctl -w vm.swappiness103. 解压初始化CM Server 和 Agent 跑起来3.1 解压与目录规划在 CM Server 节点上把包解压到/opttar -zxf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt解压出来的目录是/opt/cloudera-manager/cm-5.14.2。这里有个容易被忽略的点tar 包里的配置模板会在首次启动时生成/etc/cloudera-scm-server和/etc/cloudera-scm-agent的配置不需要你手工去复制。但如果机器上之前装过老版本残留的配置会把新版本带偏所以解压前最好先清一遍相关目录。Server 的日志在/var/log/cloudera-scm-server/cloudera-scm-server.log数据库配置在/etc/cloudera-scm-server/db.properties。启动后判断是否成功一般是看日志里出现 Started Jetty server或者检测 7180 端口是否在监听。我第一次部署时等了好一会儿才看到端口起来别一分钟没反应就断定失败了。3.2 数据库初始化嵌入式 PostgreSQL 还是外部 MySQLCM 需要一个元数据库来存集群配置、主机状态和运行历史。单机实验环境可以直接用包自带的嵌入式 PostgreSQL省事生产或节点较多的环境建议用外部 MySQL 或标准 PostgreSQL方便备份和扩展。嵌入式方式最简单先启动数据库服务再启动 Server/opt/cloudera-manager/cm-5.14.2/etc/init.d/cloudera-scm-server-db start /opt/cloudera-manager/cm-5.14.2/etc/init.d/cloudera-scm-server start外部 MySQL 的方式需要先在 MySQL 里建好库和用户CREATE DATABASE scm DEFAULT CHARACTER SET utf8; CREATE USER scm% IDENTIFIED BY scm2018; GRANT ALL ON scm.* TO scm%; FLUSH PRIVILEGES;然后把 MySQL Connector/J 的 jar 放到/usr/share/java/mysql-connector-java.jar再用分区包里的脚本初始化 CM 元数据/opt/cloudera-manager/cm-5.14.2/share/cmf/schema/scm_prepare_database.sh mysql -h db-server -u scm -p scm2018 --scm-host cm-server scm scm scm2018注意scm_prepare_database.sh的参数顺序很容易记错多带一个--scm-host参数是为了让 CM Server 知道自己该从哪个 host 去连数据库避免后面 Web 界面里出现一系列主机状态异常。3.3 Agent 配置与启动Agent 节点包括 CM Server 自己都需要装 Agent 并指向 Server。从 tar 包解压到/opt/cloudera-manager之后编辑首次启动生成的/etc/cloudera-scm-agent/config.ini修改server_host[General] server_hostcm-server启动 Agent 的方式和 Server 类似/opt/cloudera-manager/cm-5.14.2/etc/init.d/cloudera-scm-agent start启动后看/var/log/cloudera-scm-agent/cloudera-scm-agent.log出现 Successfully connected 之类的字样说明心跳已经建立。这一步我建议给 Agent 一点缓冲时间正常情况二三十秒内就会完成注册不用盯着日志狂刷。4. Web 端部署Parcel 仓库和集群创建4.1 先搭一个本地 Parcel 源CDH 的组件不是靠 CM 的 tar 包分发的而是通过 parcel 包分发。你需要单独准备CDH-5.14.2-1.cdh5.14.2.p0.3-el7.parcel和对应的manifest.json。我习惯在 CM Server 节点上装个极简 HTTP 服务把 parcel 目录暴露出去mkdir -p /var/www/html/cdh5 cp CDH-5.14.2-1.cdh5.14.2.p0.3-el7.parcel manifest.json /var/www/html/cdh5/ cd /var/www/html/cdh5 sha1sum CDH-5.14.2-1.cdh5.14.2.p0.3-el7.parcelmanifest.json里记录了 parcel 的 SHA1 值。如果拷贝过程中文件损坏Web 端下载 parcel 时直接报 hash mismatch所以建议先做一次校验确认文件和 manifest 里的值一致再开始。4.2 控制台向导的操作路径浏览器打开http://cm-server:7180默认账号是admin/admin首次登录会提示修改密码。接着按向导走选择 Cloudera Enterprise 试用版或 Cloudera Express填写需要纳管的主机列表推荐填 hosts 里统一的主机名如果 Agent 已经手动装好向导会直接识别否则它会通过 SSH 尝试安装 Agent在 Parcel 配置里填上本地仓库地址http://cm-server/cdh5/依次执行 Download、Distribute、Activate这里有个省时间的技巧如果节点多建议提前在所有节点把 Agent 装好、启动好而不是让向导去挨个装。离线环境里向导自动安装 Agent 很容易踩 yum 源缺失的问题手动批量执行反而完全可控。另外服务选择那一步不要贪多只需要 HDFS 和 ZooKeeper 就先只勾这两个等集群稳定后再通过 CM 添加 Hive、HBase、Hue。一次性全勾上首次启动会因为依赖顺序问题报各种内存不足非常被动。4.3 主机检查那几步最容易卡住部署向导过程中会跑一遍主机运行状况检查不合格的项目会被标红。常见的危险项有THP透明大页未关闭Hadoop 在这种内存模式下性能下降明显CM 检测到/sys/kernel/mm/transparent_hugepage/enabled不是never就会报错。swappiness 过高建议设成 10 或更低CM 的推荐值在检查报告里写得很明确。DNS 反解析不通过hosts 没写全或hostname -f和hostname -i对不上。e2fsprogs 版本异常某些组件在离线环境下会用到e2fsck、resize2fsCentOS 7 自带的版本一般没问题但如果你是最小化安装建议用rpm -qa | grep e2fsprogs确认一下版本缺失就从本地 ISO 里补装。这些检查项不要等报红了才处理按照第 2 节说的方法提前配置好向导会顺很多。5. 实际部署中的坑与完整排查链路5.1 cannot find a valid baseurl 的根因与修复这个报错表面上只影响 yum实际会间接弄挂部署。有一次我加节点Agent 日志里一直循环报安装依赖失败的错误点进去看才发现它内部在调 yum install而 CentOS 7 EOL 之后镜像源全部移到了 vaultAgent 自带的 yum 操作自然找不到 base。完整的排查链路是这样的# 1. 手动执行 Agent 报错对应的 yum 命令复现 yum install -y lzo # 2. 看到 cannot find a valid baseurl for repo: base/7/x86_64 # 3. 检查 /etc/yum.repos.d/CentOS-Base.repo确认 mirrorlist 指向失效域名 # 4. 执行 vault 源切换或改用本地 ISO repo # 5. yum clean all yum makecache 后重试这个案例的教训是离线部署前务必先把所有节点的本地 yum repo 建好或者干脆把所有依赖打成本地 rpm 包远程分发别把 yum 的可用性留到 Agent 安装阶段再赌。5.2 THP 和 swap看不见的检查项威力却很大CM 的检查机制很直白它读取的就是/sys/kernel/mm/transparent_hugepage/enabled和/proc/sys/vm/swappiness这类内核参数。你不提前处理向导走到一半给你标红你还得回到每台机器去改再回 Web 界面点重检来回折腾。一次性调整可以这样写for host in cm-server data1 data2; do ssh root$host echo never /sys/kernel/mm/transparent_hugepage/defrag; echo never /sys/kernel/mm/transparent_hugepage/enabled; sysctl -w vm.swappiness10; echo vm.swappiness10 /etc/sysctl.conf done想让配置重启后依然生效最好把 THP 关闭逻辑写进/etc/rc.local或 GRUB 启动参数否则节点重启后就打回原形集群性能又开始波动。5.3 /tmp noexec 与 Agent 起不来的隐藏原因还有一次 Agent 启动失败我以为是配置问题排查到最后才发现是/tmp分区挂了noexec选项。Agent 在交互时会把临时脚本丢到/tmp没有执行权限直接被拒。检查方式很简单mount | grep /tmp 如果确实挂了noexec要么重挂成exec要么把 Agent 的临时目录改到/var/tmp。另外最小化安装的 CentOS 7 有些工具没带全比如libpcap某些网络采集组件会用到提前从本地 ISO 或 rpm 包补上别等部署到一半才急着找包。5.4 Agent 注册不上hosts 与 server_host 的排错链当 Web 向导里一直看不到某台主机的 Agent或者主机状态是 Bad host 时我的排查顺序是固定的# 1. 确认 agent 进程活着 ps -ef | grep cloudera-scm-agent # 2. 看 agent 日志最后几行 tail -n 50 /var/log/cloudera-scm-agent/cloudera-scm-agent.log # 3. 确认 server_host 配置 grep -n server_host /etc/cloudera-scm-agent/config.ini # 4. 确认 7182 端口能通agent 与 server 的心跳端口 nc -vz cm-server 7182 # 5. 确认本机 FQDN 反解析正常 hostname -f getent hosts $(hostname -f)有一次问题出在/etc/hosts里把主机名和 IP 写反了hostname -f返回了错误的主机名Agent 向 Server 注册时带的 hostname 不合法直接被拒。把 hosts 修正统一之后Agent 重新注册就正常了。6. 部署完成后的参数调整与经验沉淀集群跑起来之后有几件事我会立刻做而不是等性能报警了才处理。一是把 swappiness 固化成 10 或 1。Hadoop 节点上我不建议设成 0因为极端内存压力下内核完全没有 swap 反而容易 OOM。二是把 THP 关闭状态写进开机启动避免后续内核更新或重启后被重置。三是给所有节点调大文件描述符和进程数在/etc/security/limits.conf里加上* soft nofile 65536、* hard nofile 65536、* soft nproc 65536、* hard nproc 65536不然 HBase 这类组件跑久了就会出现 too many open files。部署完我一般会先看一眼 CM 主页的集群运行状况总览确认 HDFS 的 DataNode 数量、YARN 的 NodeManager 数量以及每个角色所在主机都对得上。很多时候你以为部署成功了其实某个 DataNode 进程没起来只是 CM 还没来得及刷新告警图标。另外CM 5.14.2 元数据库、/etc/cloudera-scm-server配置目录、/var/lib/cloudera-scm-server里的数据都建议纳入备份范围。db.properties里的数据库密码是明文存储的权限至少设成 600。有一次我误操作清理了/tmp恰好有个 Agent 的临时状态文件在里面结果集群状态视图卡了半天最后重建 Agent 状态才恢复。这些老版本的坑比想象中隐蔽备份永远比事后修复便宜。最后分享一个我自己的习惯把安装包版本号、parcel 文件名、数据库初始化命令、每台节点的 hostname 映射全部写进一份 deployment.md放到/opt/cloudera-manager目录里。CDH 这种老派系统部署频率不高但每次间隔都很久三个月后再回来看记忆完全是空白的有这份文档比什么经验都值钱。本文还有配套的精品资源点击获取