最近又有人问起 CDH 6.3.2 离线部署的事情我直接给了同样的结论只要你还想用 Cloudera Manager 6.3.1 去管这套集群本地仓库方式就是最稳的办法没有之一。网上很多教程写的是在线源直接安装但真正落地过的人都知道在线源要么慢得离谱要么装到一半源就断了几十个节点全部挂在同一个公共源上等于把整个集群的命脉交到别人手里。这篇就完整记录一次 Cloudera Manager 6.3.1 CDH 6.3.2 的本地仓库搭建过程从中间机的作用、Nginx 仓库结构、Parcel 文件组织到 CM Server 初始化数据库和 Web 向导里的每一步最后附上最常见的排错思路。适合刚接手 CDH 环境、准备在纯内网里做一套测试集群或生产基础环境的朋友照着这套流程走完比自己瞎试要省很多时间。1. 先想清楚为什么推荐把能上网的那台机器变成本地仓库机1.1 在线安装的痛点装过两次的人都懂CDH 的在线安装本质上就是让每一台主机都通过 Yum 源去拉取 Cloudera Manager 相关 RPM再通过 CM Server 统一从官方 Parcel 仓库下载 CDH 的 Parcel 包。这个链路看起来简单可实际用起来有两个非常现实的问题一个是下载速度不稳定官方仓库托管在国外内网机器去拉大文件动不动就超时另一个是源不可控一旦官方调整目录结构、下架旧版本或者你所在网络访问不了对应域名整批节点全部会被卡在半中间。更隐蔽的问题在于重复下载。一个 6 节点的集群每个节点都要装一遍 CM Agent 相关依赖Parcel 包还要在 CM Server 和所有 Agent 之间分发在线模式下每个 Agent 都直接访问公共源带宽浪费极其严重。所以只要条件允许我个人的习惯从来都是先准备一台能联网或者能拿到完整包的中间机把 CM 仓库和 CDH Parcel 仓库全部镜像到本地再让集群的所有节点都走本地源。1.2 本地仓库方式的核心思路和数据流本地仓库方式说起来并不复杂中间机上跑一个 Nginx对外提供两个 Web 目录一个放 Cloudera Manager 的 Yum 仓库另一个放 CDH 6.3.2 的 Parcel 文件。集群内的所有操作都围绕这台中间机进行拓扑大致如下中间机repo-host安装 Nginx存放 CM 6.3.1 的 RPM 依赖和 CDH 6.3.2 的 Parcel 文件同时可能也扮演 CM Server 安装源。CM Server 节点从本地 Yum 源安装 cloudera-manager-server、cloudera-manager-agent、cloudera-manager-daemons之后启动 Web 界面。被管理节点安装 cloudera-manager-agent通过 Web 向导被托管最终从中间机的 Parcel 目录下载 CDH 组件包。这个结构最大的好处是无论集群里有多少台机器Parcel 包只需要下载一次。后续加节点时新节点也直接对着中间机取文件整个过程不会碰公共网络也方便排查。因为我后面所有步骤里的地址都是http://repo-host你自己替换成实际 IP 即可。2. 环境初始化自查清单主机名、免密、swap、防火墙缺一不可2.1 主机规划与版本匹配开始动手之前先把规划表列清楚。我的实验环境是 4 台机器全部使用 CentOS 7.6 版本如果你用 RedHat 7 也基本一致。CDH 6.3.2 对应的 Parcel 只支持 el7这一点在后续选包的时候要注意。主机名IP部署角色repo-host192.168.10.10Nginx 仓库 CM Servernode01192.168.10.11NameNode、ResourceManager、Hive、HBase Masternode02192.168.10.12SecondaryNameNode、Zookeeper、HiveServer2node03192.168.10.13DataNode、NodeManager、Zookeeper所有节点统一使用root操作如果是生产环境请务必做好权限管控和审计。关于版本还要说明一下Cloudera Manager 6.3.1 可以管理 CDH 6.3.1 和 6.3.2我这次选的是 CDH 6.3.2。2.2 基础环境初始化脚本每台节点上都需要做同样的基础配置。先把主机名和 hosts 搞定否则 CM Server 在探测主机时会直接失败。hostnamectl set-hostname repo-host cat /etc/hosts EOF 192.168.10.10 repo-host 192.168.10.11 node01 192.168.10.12 node02 192.168.10.13 node03 EOF然后是关闭防火墙、SELinux并设置英文时区。这一步看起来像废话但真的有人漏掉导致后面所有 Agent 心跳异常systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config timedatectl set-timezone Asia/Shanghai systemctl start chronyd systemctl enable chronyd从 CM Server 上生成 SSH 密钥把公钥分发到所有被管节点这一步必须做。CM 在接管主机并安装 Agent 的时候会通过 SSH 去执行远程命令如果还要每次输入密码自动化接管就会卡住。ssh-keygen -t rsa -b 4096 -N -f /root/.ssh/id_rsa ssh-copy-id rootnode01 ssh-copy-id rootnode02 ssh-copy-id rootnode032.3 内核参数和透明大页越早处理越省事CM 的预检查会对节点做一次体检常见的几项不通过原因里swap和透明大页占了绝大多数。建议在装任何东西之前就把参数调好echo vm.swappiness1 /etc/sysctl.conf sysctl -p echo echo never /sys/kernel/mm/transparent_hugepage/enabled /etc/rc.d/rc.local echo echo never /sys/kernel/mm/transparent_hugepage/defrag /etc/rc.d/rc.local chmod x /etc/rc.d/rc.local这里说明一下原因Hadoop 类组件对内存分配非常敏感默认的 swappiness30 会让系统在内存还有余量时就开始把进程换出对 NameNode 这种延迟敏感的进程很不友好透明大页则会在内存分配时产生大量页凝聚操作导致 CPU 突刺和延迟抖动。这两项是官方检查项直接处理掉后面 Web 向导会顺畅很多。3. 在中间机搭建 CM 6.3.1 的 Yum 本地仓库3.1 直接镜像官方 Yum 源结构而不是手工拼 RPMCloudera Manager 的官方 Yum 源本身就是一个标准仓库里面有repodata目录、大量依赖 RPM、GPG 签名文件。最省事的做法是直接用 Wget 把整个仓库目录镜像下来这样所有依赖关系都在不需要自己createrepo。依赖关系一旦被破坏后面安装 CM Server 时会缺一堆库文件排查起来非常痛苦。先确认 Nginx 已经到了中间机上并把网页目录建好yum install -y nginx systemctl enable nginx --now mkdir -p /data/repo chown -R nginx:nginx /data/repo然后切到/data/repo目录镜像 CM 仓库。注意这里的 URL 最后要带上yum/确保抓到的不是页面而是目录内容cd /data/repo wget -r -np -nH -e robotsoff \ http://archive.cloudera.com/cm6/6.3.1/redhat7/yum/命令里的-r是递归-np是不爬取父级目录-nH是不要保存主机名目录-e robotsoff忽略对方的爬虫限制文件。镜像完以后目录结构大概是/data/repo/cm6/6.3.1/redhat7/yum/repodata/repomd.xml /data/repo/cm6/6.3.1/redhat7/yum/RPMS/x86_64/cloudera-manager-daemons-6.3.1-*.rpm如果你下载完之后想确认完整性直接看repodata/repomd.xml是否存在即可。文件数量多不用一个个验证。3.2 Nginx 配置要点开启 autoindex 并允许字节范围请求在/etc/nginx/conf.d/repo.conf里写一个 server 块根目录指向/data/repo同时开启目录浏览。这里有两个容易被忽略的细节一是必须开autoindex否则 Agent 在试探仓库目录时会返回 404二是sendfile保持默认即可但一定要确保没有开启任何会吞掉 HTTP Range 请求的配置否则 CentOS 的 Yum 断点续传会变得不稳定。server { listen 80; server_name repo-host; root /data/repo; autoindex on; autoindex_exact_size off; autoindex_localtime on; charset utf-8; }改完配置后先校验再重载nginx -t systemctl reload nginx验证仓库是否真的可访问直接 curl 关键文件curl -I http://repo-host/cm6/6.3.1/redhat7/yum/repodata/repomd.xml看到200 OK就说明 Yum 仓库可用。如果你用的不是 Nginx 而是 Apache HTTPD思路完全一样只是访问路径换成/var/www/html下的映射Nginx 的优点在于轻量、并发高而且配置一眼能看明白。4. CDH 6.3.2 Parcel 仓库不仅仅是放文件那么简单4.1 需要准备的三个关键文件Parcel 仓库和 CM Yum 仓库不同它的核心文件就三个manifest.json、CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel和同名的 .sha 文件。其中 manifest.json 是清单CM 的 Web 向导在读取仓库时实际上先请求这个文件解析出里面列出的所有 Parcel 名称、版本和校验值真正的 Parcel 包则是 CDH 组件的大集合解压后各类服务就来自这里。下载命令如下mkdir -p /data/repo/cdh6/6.3.2/parcels cd /data/repo/cdh6/6.3.2/parcels wget http://archive.cloudera.com/cdh6/6.3.2/parcels/manifest.json wget http://archive.cloudera.com/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel wget http://archive.cloudera.com/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha重点讲一下.sha文件它里面只有一段 40 位的 SHA1 字符串没有任何文件名。CM 在下载 Parcel 后会拿这段值去校验完整性。很多人会直接把.sha文件打开然后手工复制内容到新建文件但最容易犯的错是文件名来源不一致。我一般直接用 Wget 保留原始文件名绝不手工改动。4.2 目录结构与访问验证现在仓库目录结构应该长这样/data/repo/cdh6/6.3.2/parcels/ ├── CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel ├── CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha └── manifest.json打开浏览器访问http://repo-host/cdh6/6.3.2/parcels/应该能看到三个文件并且点击 CDH 的 Parcel 链接是可以直接触发下载的。如果看不到文件优先检查 Nginx 的root路径是否指到了/data/repo不要指到/data/repo/cdh6否则整个 URL 匹配会错位。还有一个非常容易踩的坑manifest.json里写的 URL 是相对路径所以目录层级必须保持cdh6/6.3.2/parcels不要自作聪明换名字。比如你把目录改成cdh-parcelCM 解析清单时会按照 manifest 里的相对路径去拼 URL最终拼出来的地址就是错的表现为找不到 parcel。4.3 用 curl 模拟 CM 读取仓库的完整过程最稳的验证方式不是用浏览器点一点而是完全模拟 CM 的内部请求curl -s http://repo-host/cdh6/6.3.2/parcels/manifest.json | head -n 20 curl -s http://repo-host/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha第一个命令能看到 manifest 的 JSON 结构第二个命令能看到一小段 SHA 字符串。如果两个都有返回仓库端就完全 OK。之前我看到有人在这里纠结了很长时间其实 curl 一句话就能定位。5. CM Server 安装与数据库初始化最容易栽跟头的环节5.1 在 repo-host 上配置本地 Yum 源并安装 RPM现在所有节点都要能解析到本地 CM 源。我在中间机上创建/etc/yum.repos.d/cloudera-manager.repo[cloudera-manager] nameCloudera Manager 6.3.1 baseurlhttp://repo-host/cm6/6.3.1/redhat7/yum/ gpgcheck0 enabled1这里直接设置gpgcheck0因为在纯内网环境里验证签名反而会因为导入公钥不及时而出问题。之前我维护的一套环境就用的是本地源导入官方 key 的顺序不对导致 RPM 安装失败后来统一关闭 gpgcheck问题立刻消失。如果你的安全规范要求校验签名那就把官方RPM-GPG-KEY-cloudera放到目录里并加上gpgkey配置但那样会多不少维护成本。安装时需要按顺序装 Server 相关包yum clean all yum makecache yum install -y cloudera-manager-daemons cloudera-manager-agent cloudera-manager-server注意这里cloudera-manager-server会依赖前两个包。装完后执行rpm -qa | grep cloudera-manager确认三个包都在。如果你想省事cloudera-manager-agent可以先只装在 repo-host 上其余节点的 Agent 让 CM Web 向导自己去装也可以在这里就把所有节点的 [repo 文件] 配好再手动统一安装。5.2 初始化 CM 数据库正确理解 scm_prepare_database.sh 的参数CM Server 本身是有状态的需要把元数据存到数据库里。CM 6.3.1 支持嵌入式的 PostgreSQL但生产上建议用独立 MySQL。我这边用的是 MySQL 5.7如果是刚装的 MySQL 5.7需要先手工建一个库和用户而不是直接让脚本帮你建库CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO scm% IDENTIFIED BY scm_password; GRANT ALL ON scm.* TO scmlocalhost IDENTIFIED BY scm_password; FLUSH PRIVILEGES;然后调用 CM 提供的官方初始化脚本。这个脚本的作用是在数据库里写入 CM 元数据库表结构同时把 CM Agent 端的配置文件写到/etc/cloudera-scm-agent/config.ini里。调用方式如下/opt/cloudera/cm/schema/scm_prepare_database.sh \ -h localhost \ mysql \ -uroot -p \ --scm-host localhost \ scm scm_password参数说明一下-h是数据库主机mysql是数据库类型-uroot -p是数据库管理员账号--scm-host localhost表示 CM Server 跑在本地最后的scm是库名scm_password是用户密码。如果你不写--scm-host脚本会默认去解析当前主机名这时 hosts 写错就会导致后续 Agent 连不上。官方脚本跑成功后还要把 MySQL 的 JDBC 驱动放到指定位置否则后续从 Web 界面检查数据库健康时会出现无法加载驱动之类的错误cp mysql-connector-java-8.0.23.jar /opt/cloudera/cm/lib/mysql-connector-java.jar5.3 启动服务并看日志确认先启动 Agent再启动 Serversystemctl start cloudera-scm-agent systemctl start cloudera-scm-serverServer 启动比较慢通常要等一到三分钟因为要初始化很多默认配置。观察日志是最靠谱的tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到Started Jetty server之类的信息就说明 Server 已经起来了。此时打开浏览器访问http://repo-host:7180默认账号密码都是admin第一次登录会提示修改可以先跳过不用急着改。我在实际操作中会再建立第二个带 sudo 权限的管理员账号但这是后话。6. 浏览器向导中的每一步从接管主机到启用 Parcel 仓库6.1 登录、接受许可和选择版本协议用admin/admin登录后CM 会自动进入安装引导。先接受协议和许可条款这一步不仔细看内容直接确认即可。紧接着会让你选择版本如果你手头没有商业 License就选试用版。可能有人担心试用期过了怎么办实际上 CM 6.3.x 在试用期结束后会退回到 Free 免费版核心的 HDFS、YARN、Hive、HBase 组件都不受影响只是少了部分企业级安全特性。不要因为试用两个字就被劝退。6.2 主机接管输入 IP 列表并完成 SSH 分配在添加主机步骤把集群里所有节点的 IP 或主机名都填进去逗号分隔node01,node02,node03接下来选择根账号和 SSH 认证方式。我习惯用密码认证因为前面已经配置过 SSH 免密CM 在接管过程中其实能复用。这里如果你选择所有主机都使用相同凭据就填 root 和 root 的密码。接管过程会持续几分钟CM 会把 Agent 包推到目标机并自动修改/etc/cloudera-scm-agent/config.ini里的 server_host指向中间机。这块如果失败直接看目标机上的/var/log/cloudera-scm-agent/cloudera-scm-agent.log通常原因就是 hosts 解析错误或者 SSH 端口不通。6.3 指定本地 Parcel 仓库的准确写法主机接管之后向导会进入选择 Parcel 版本界面默认先给出一系列在线版本。这里要做的操作是不要选默认的公共仓库,去找自定义仓库 URL相关的输入框然后把本地地址填进去http://repo-host/cdh6/6.3.2/parcels/填完之后列表里应该会出现CDH 6.3.2这个条目。如果没有出现说明 CM Server 访问不到manifest.json先用 4.3 里的 curl 排查。如果出现了但界面提示Parcel 不正确或校验失败那就是.sha文件没放好。在这个阶段还会有一个GPL 条款勾选项需要勾选同意否则 Parcel 无法激活。6.4 在所有主机上部署和激活 Parcel选定 CDH 6.3.2 之后向导会依次执行下载、分发、解压、激活四步。因为仓库在本地下载速度很快分发过程会对每台 Agent 并行传输。这里最需要耐心的是解压阶段一个大 Parcel 包解压后可能占用几 GB 磁盘而且每个节点上的/opt/cloudera/parcels目录需要充足空间。等待所有节点都显示已激活就进入后续服务配置。7. Parcel 分发失败的排查链路与验证命令7.1 三类最常见故障的具体表现我在多次实施中总结过Parcel 分发阶段出问题基本都是这三个原因manifest 不可见房间里填了仓库 URL列表不出现版本。根因多为 Nginx root 路径错位或者目录里根本没有 manifest.json。下载后校验失败列表能出 CDH 6.3.2但进度条在 99% 时红叉。根因是.sha文件损坏或文件名被改名CM 用它算出的 SHA1 对不上。分发到某一台节点失败其他节点都成功只有某台失败。根因几乎都是该节点磁盘空间不足或者/opt/cloudera目录被占用了。7.2 排查链路先日志再 curl后空间遇到问题不要慌第一步永远是看日志。CM Server 的日志在/var/log/cloudera-scm-server/cloudera-scm-server.logAgent 的日志在/var/log/cloudera-scm-agent/cloudera-scm-agent.log如果在 Server 日志里看到Failed to fetch parcel from repository就去目标节点上手动测试curl -sI http://repo-host/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel确认返回200 OK之后再看目标机器上的剩余空间df -h /opt /tmp/opt/cloudera是 Parcel 解压目录如果小于 10GB建议清理或扩大分区。还有一个我不止一次踩过的坑/tmp空间被占满CM 在做远程推送时会写入临时文件然后直接报no space left on device。这种原因看 Server 端日志可能看不大出来但在 Agent 端日志里非常明显。7.3 日志速查表出问题时按图索骥日志位置主要看什么/var/log/cloudera-scm-server/cloudera-scm-server.logParcel 仓库解析、数据库连接、Web API 错误/var/log/cloudera-scm-agent/cloudera-scm-agent.logAgent 心跳、下载 Parcel、解压进度/var/log/cloudera-scm-server/cloudera-scm-server.log 的 db.properties数据库连接信息我在生产环境维护里会把这几类日志统一交给日志采集方便后续出现问题时快速搜索ERROR和Exception关键字。8. 服务角色分配与启动后的默认配置调整8.1 角色分配参考单机测试和三节点生产到了分配角色这一步如果是单机测试直接把所有角色都丢到同一台机器上即可。如果想搭一套勉强能跑开发任务的三节点集群我一般会这样分配服务node01node02node03HDFS NameNode是HDFS SecondaryNameNode是HDFS DataNode是YARN ResourceManager是YARN NodeManager是Zookeeper是是是Hive Metastore是HiveServer2是HBase Master是HBase RegionServer是这个表只是一个参考。Zookeeper 至少三节点是为了保证选主可用DataNode 和 NodeManager 放同一批机器是为了让计算尽量本地化减少跨机数据传输。8.2 启动顺序与必调参数角色分配完成之后CM 会自动生成一大堆默认配置。我每次都要手动改两个地方第一内存预留。CM 在主机-配置里默认会预留比较多的内存用来跑监控、运行 MapReduce 等辅助进程。如果机器只有 16GB我建议把 YARN 的yarn.nodemanager.resource.memory-mb调低比如设置到 8GBHDFS NameNode 堆内存根据实际元数据规模调整小集群 2GB 足够。第二HDFS 目录。默认的数据目录一般指向/dfs/nn、/dfs/dn这类路径CM 会自动创建。如果你希望数据盘挂在/data1、/data2等独立磁盘就要在角色配置里把目录改成相应位置。这里有非常重要的一个点修改目录后一定要确认目标盘挂载正确并且/dfs目录不是由不明脚本挂载的临时盘否则集群重启后数据目录丢失会非常麻烦。启动顺序建议从依赖最底层开始先 Zookeeper再 HDFS然后 YARN最后启动 Hive、HBase 等上层服务。CM 界面上有启动按钮它会自动按照依赖关系排序但如果你发现启动顺序乱套可以选择逐步启动。8.3 健康检查与常用命令服务全部启动后不要急着拿去跑任务先看一眼健康状态。直接在 CM 首页就能看到 HDFS 和 YARN 的星星点进去看是否有严重问题。我习惯在命令行再验证一层hdfs dfsadmin -report curl http://node01:8088/ws/v1/cluster/info前者能看到 DataNode 数量和容量后者能看到 ResourceManager 的集群状态。如果 HDFS 层面显示Live datanodes (0)基本就是 DataNode 进程没起来去对应机器执行systemctl status cloudera-scm-agent tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log这里要额外提一点不要用 service 命令单独启停 HDFS 的某个角色在 CDH 体系里角色的生命周期由 CM Agent 统一管理。你手动 kill 掉进程后Agent 过几秒又会拉起来看起来像服务启动失败其实是自己干扰了管理。整套流程走完我最想提醒的是CDH 6.3.x 现在越来越像一个存量方案本地仓库这种部署方式的价值反而更大了。中间机上那些 RPM 和 Parcel 一定不要随便清理后续新增节点、批量修复 Agent甚至重新搭建一套一模一样的环境都能靠它快速恢复。如果理解了整套仓库的构成后面无论换成 Apache Hadoop 还是其他发行版这个先有一台能分发的中间机再统一接管所有节点的思路都是通用的。最后再补充一个冷门小技巧部署完成后把中间机上的仓库目录做一次内网备份盘或者打成 tar 包存到离线介质里关键时刻能救命。
最近又有人问起 CDH 6.3.2 离线部署的事情我直接给了同样的结论只要你还想用 Cloudera Manager 6.3.1 去管这套集群本地仓库方式就是最稳的办法没有之一。网上很多教程写的是在线源直接安装但真正落地过的人都知道在线源要么慢得离谱要么装到一半源就断了几十个节点全部挂在同一个公共源上等于把整个集群的命脉交到别人手里。这篇就完整记录一次 Cloudera Manager 6.3.1 CDH 6.3.2 的本地仓库搭建过程从中间机的作用、Nginx 仓库结构、Parcel 文件组织到 CM Server 初始化数据库和 Web 向导里的每一步最后附上最常见的排错思路。适合刚接手 CDH 环境、准备在纯内网里做一套测试集群或生产基础环境的朋友照着这套流程走完比自己瞎试要省很多时间。1. 先想清楚为什么推荐把能上网的那台机器变成本地仓库机1.1 在线安装的痛点装过两次的人都懂CDH 的在线安装本质上就是让每一台主机都通过 Yum 源去拉取 Cloudera Manager 相关 RPM再通过 CM Server 统一从官方 Parcel 仓库下载 CDH 的 Parcel 包。这个链路看起来简单可实际用起来有两个非常现实的问题一个是下载速度不稳定官方仓库托管在国外内网机器去拉大文件动不动就超时另一个是源不可控一旦官方调整目录结构、下架旧版本或者你所在网络访问不了对应域名整批节点全部会被卡在半中间。更隐蔽的问题在于重复下载。一个 6 节点的集群每个节点都要装一遍 CM Agent 相关依赖Parcel 包还要在 CM Server 和所有 Agent 之间分发在线模式下每个 Agent 都直接访问公共源带宽浪费极其严重。所以只要条件允许我个人的习惯从来都是先准备一台能联网或者能拿到完整包的中间机把 CM 仓库和 CDH Parcel 仓库全部镜像到本地再让集群的所有节点都走本地源。1.2 本地仓库方式的核心思路和数据流本地仓库方式说起来并不复杂中间机上跑一个 Nginx对外提供两个 Web 目录一个放 Cloudera Manager 的 Yum 仓库另一个放 CDH 6.3.2 的 Parcel 文件。集群内的所有操作都围绕这台中间机进行拓扑大致如下中间机repo-host安装 Nginx存放 CM 6.3.1 的 RPM 依赖和 CDH 6.3.2 的 Parcel 文件同时可能也扮演 CM Server 安装源。CM Server 节点从本地 Yum 源安装 cloudera-manager-server、cloudera-manager-agent、cloudera-manager-daemons之后启动 Web 界面。被管理节点安装 cloudera-manager-agent通过 Web 向导被托管最终从中间机的 Parcel 目录下载 CDH 组件包。这个结构最大的好处是无论集群里有多少台机器Parcel 包只需要下载一次。后续加节点时新节点也直接对着中间机取文件整个过程不会碰公共网络也方便排查。因为我后面所有步骤里的地址都是http://repo-host你自己替换成实际 IP 即可。2. 环境初始化自查清单主机名、免密、swap、防火墙缺一不可2.1 主机规划与版本匹配开始动手之前先把规划表列清楚。我的实验环境是 4 台机器全部使用 CentOS 7.6 版本如果你用 RedHat 7 也基本一致。CDH 6.3.2 对应的 Parcel 只支持 el7这一点在后续选包的时候要注意。主机名IP部署角色repo-host192.168.10.10Nginx 仓库 CM Servernode01192.168.10.11NameNode、ResourceManager、Hive、HBase Masternode02192.168.10.12SecondaryNameNode、Zookeeper、HiveServer2node03192.168.10.13DataNode、NodeManager、Zookeeper所有节点统一使用root操作如果是生产环境请务必做好权限管控和审计。关于版本还要说明一下Cloudera Manager 6.3.1 可以管理 CDH 6.3.1 和 6.3.2我这次选的是 CDH 6.3.2。2.2 基础环境初始化脚本每台节点上都需要做同样的基础配置。先把主机名和 hosts 搞定否则 CM Server 在探测主机时会直接失败。hostnamectl set-hostname repo-host cat /etc/hosts EOF 192.168.10.10 repo-host 192.168.10.11 node01 192.168.10.12 node02 192.168.10.13 node03 EOF然后是关闭防火墙、SELinux并设置英文时区。这一步看起来像废话但真的有人漏掉导致后面所有 Agent 心跳异常systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config timedatectl set-timezone Asia/Shanghai systemctl start chronyd systemctl enable chronyd从 CM Server 上生成 SSH 密钥把公钥分发到所有被管节点这一步必须做。CM 在接管主机并安装 Agent 的时候会通过 SSH 去执行远程命令如果还要每次输入密码自动化接管就会卡住。ssh-keygen -t rsa -b 4096 -N -f /root/.ssh/id_rsa ssh-copy-id rootnode01 ssh-copy-id rootnode02 ssh-copy-id rootnode032.3 内核参数和透明大页越早处理越省事CM 的预检查会对节点做一次体检常见的几项不通过原因里swap和透明大页占了绝大多数。建议在装任何东西之前就把参数调好echo vm.swappiness1 /etc/sysctl.conf sysctl -p echo echo never /sys/kernel/mm/transparent_hugepage/enabled /etc/rc.d/rc.local echo echo never /sys/kernel/mm/transparent_hugepage/defrag /etc/rc.d/rc.local chmod x /etc/rc.d/rc.local这里说明一下原因Hadoop 类组件对内存分配非常敏感默认的 swappiness30 会让系统在内存还有余量时就开始把进程换出对 NameNode 这种延迟敏感的进程很不友好透明大页则会在内存分配时产生大量页凝聚操作导致 CPU 突刺和延迟抖动。这两项是官方检查项直接处理掉后面 Web 向导会顺畅很多。3. 在中间机搭建 CM 6.3.1 的 Yum 本地仓库3.1 直接镜像官方 Yum 源结构而不是手工拼 RPMCloudera Manager 的官方 Yum 源本身就是一个标准仓库里面有repodata目录、大量依赖 RPM、GPG 签名文件。最省事的做法是直接用 Wget 把整个仓库目录镜像下来这样所有依赖关系都在不需要自己createrepo。依赖关系一旦被破坏后面安装 CM Server 时会缺一堆库文件排查起来非常痛苦。先确认 Nginx 已经到了中间机上并把网页目录建好yum install -y nginx systemctl enable nginx --now mkdir -p /data/repo chown -R nginx:nginx /data/repo然后切到/data/repo目录镜像 CM 仓库。注意这里的 URL 最后要带上yum/确保抓到的不是页面而是目录内容cd /data/repo wget -r -np -nH -e robotsoff \ http://archive.cloudera.com/cm6/6.3.1/redhat7/yum/命令里的-r是递归-np是不爬取父级目录-nH是不要保存主机名目录-e robotsoff忽略对方的爬虫限制文件。镜像完以后目录结构大概是/data/repo/cm6/6.3.1/redhat7/yum/repodata/repomd.xml /data/repo/cm6/6.3.1/redhat7/yum/RPMS/x86_64/cloudera-manager-daemons-6.3.1-*.rpm如果你下载完之后想确认完整性直接看repodata/repomd.xml是否存在即可。文件数量多不用一个个验证。3.2 Nginx 配置要点开启 autoindex 并允许字节范围请求在/etc/nginx/conf.d/repo.conf里写一个 server 块根目录指向/data/repo同时开启目录浏览。这里有两个容易被忽略的细节一是必须开autoindex否则 Agent 在试探仓库目录时会返回 404二是sendfile保持默认即可但一定要确保没有开启任何会吞掉 HTTP Range 请求的配置否则 CentOS 的 Yum 断点续传会变得不稳定。server { listen 80; server_name repo-host; root /data/repo; autoindex on; autoindex_exact_size off; autoindex_localtime on; charset utf-8; }改完配置后先校验再重载nginx -t systemctl reload nginx验证仓库是否真的可访问直接 curl 关键文件curl -I http://repo-host/cm6/6.3.1/redhat7/yum/repodata/repomd.xml看到200 OK就说明 Yum 仓库可用。如果你用的不是 Nginx 而是 Apache HTTPD思路完全一样只是访问路径换成/var/www/html下的映射Nginx 的优点在于轻量、并发高而且配置一眼能看明白。4. CDH 6.3.2 Parcel 仓库不仅仅是放文件那么简单4.1 需要准备的三个关键文件Parcel 仓库和 CM Yum 仓库不同它的核心文件就三个manifest.json、CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel和同名的 .sha 文件。其中 manifest.json 是清单CM 的 Web 向导在读取仓库时实际上先请求这个文件解析出里面列出的所有 Parcel 名称、版本和校验值真正的 Parcel 包则是 CDH 组件的大集合解压后各类服务就来自这里。下载命令如下mkdir -p /data/repo/cdh6/6.3.2/parcels cd /data/repo/cdh6/6.3.2/parcels wget http://archive.cloudera.com/cdh6/6.3.2/parcels/manifest.json wget http://archive.cloudera.com/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel wget http://archive.cloudera.com/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha重点讲一下.sha文件它里面只有一段 40 位的 SHA1 字符串没有任何文件名。CM 在下载 Parcel 后会拿这段值去校验完整性。很多人会直接把.sha文件打开然后手工复制内容到新建文件但最容易犯的错是文件名来源不一致。我一般直接用 Wget 保留原始文件名绝不手工改动。4.2 目录结构与访问验证现在仓库目录结构应该长这样/data/repo/cdh6/6.3.2/parcels/ ├── CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel ├── CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha └── manifest.json打开浏览器访问http://repo-host/cdh6/6.3.2/parcels/应该能看到三个文件并且点击 CDH 的 Parcel 链接是可以直接触发下载的。如果看不到文件优先检查 Nginx 的root路径是否指到了/data/repo不要指到/data/repo/cdh6否则整个 URL 匹配会错位。还有一个非常容易踩的坑manifest.json里写的 URL 是相对路径所以目录层级必须保持cdh6/6.3.2/parcels不要自作聪明换名字。比如你把目录改成cdh-parcelCM 解析清单时会按照 manifest 里的相对路径去拼 URL最终拼出来的地址就是错的表现为找不到 parcel。4.3 用 curl 模拟 CM 读取仓库的完整过程最稳的验证方式不是用浏览器点一点而是完全模拟 CM 的内部请求curl -s http://repo-host/cdh6/6.3.2/parcels/manifest.json | head -n 20 curl -s http://repo-host/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha第一个命令能看到 manifest 的 JSON 结构第二个命令能看到一小段 SHA 字符串。如果两个都有返回仓库端就完全 OK。之前我看到有人在这里纠结了很长时间其实 curl 一句话就能定位。5. CM Server 安装与数据库初始化最容易栽跟头的环节5.1 在 repo-host 上配置本地 Yum 源并安装 RPM现在所有节点都要能解析到本地 CM 源。我在中间机上创建/etc/yum.repos.d/cloudera-manager.repo[cloudera-manager] nameCloudera Manager 6.3.1 baseurlhttp://repo-host/cm6/6.3.1/redhat7/yum/ gpgcheck0 enabled1这里直接设置gpgcheck0因为在纯内网环境里验证签名反而会因为导入公钥不及时而出问题。之前我维护的一套环境就用的是本地源导入官方 key 的顺序不对导致 RPM 安装失败后来统一关闭 gpgcheck问题立刻消失。如果你的安全规范要求校验签名那就把官方RPM-GPG-KEY-cloudera放到目录里并加上gpgkey配置但那样会多不少维护成本。安装时需要按顺序装 Server 相关包yum clean all yum makecache yum install -y cloudera-manager-daemons cloudera-manager-agent cloudera-manager-server注意这里cloudera-manager-server会依赖前两个包。装完后执行rpm -qa | grep cloudera-manager确认三个包都在。如果你想省事cloudera-manager-agent可以先只装在 repo-host 上其余节点的 Agent 让 CM Web 向导自己去装也可以在这里就把所有节点的 [repo 文件] 配好再手动统一安装。5.2 初始化 CM 数据库正确理解 scm_prepare_database.sh 的参数CM Server 本身是有状态的需要把元数据存到数据库里。CM 6.3.1 支持嵌入式的 PostgreSQL但生产上建议用独立 MySQL。我这边用的是 MySQL 5.7如果是刚装的 MySQL 5.7需要先手工建一个库和用户而不是直接让脚本帮你建库CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO scm% IDENTIFIED BY scm_password; GRANT ALL ON scm.* TO scmlocalhost IDENTIFIED BY scm_password; FLUSH PRIVILEGES;然后调用 CM 提供的官方初始化脚本。这个脚本的作用是在数据库里写入 CM 元数据库表结构同时把 CM Agent 端的配置文件写到/etc/cloudera-scm-agent/config.ini里。调用方式如下/opt/cloudera/cm/schema/scm_prepare_database.sh \ -h localhost \ mysql \ -uroot -p \ --scm-host localhost \ scm scm_password参数说明一下-h是数据库主机mysql是数据库类型-uroot -p是数据库管理员账号--scm-host localhost表示 CM Server 跑在本地最后的scm是库名scm_password是用户密码。如果你不写--scm-host脚本会默认去解析当前主机名这时 hosts 写错就会导致后续 Agent 连不上。官方脚本跑成功后还要把 MySQL 的 JDBC 驱动放到指定位置否则后续从 Web 界面检查数据库健康时会出现无法加载驱动之类的错误cp mysql-connector-java-8.0.23.jar /opt/cloudera/cm/lib/mysql-connector-java.jar5.3 启动服务并看日志确认先启动 Agent再启动 Serversystemctl start cloudera-scm-agent systemctl start cloudera-scm-serverServer 启动比较慢通常要等一到三分钟因为要初始化很多默认配置。观察日志是最靠谱的tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到Started Jetty server之类的信息就说明 Server 已经起来了。此时打开浏览器访问http://repo-host:7180默认账号密码都是admin第一次登录会提示修改可以先跳过不用急着改。我在实际操作中会再建立第二个带 sudo 权限的管理员账号但这是后话。6. 浏览器向导中的每一步从接管主机到启用 Parcel 仓库6.1 登录、接受许可和选择版本协议用admin/admin登录后CM 会自动进入安装引导。先接受协议和许可条款这一步不仔细看内容直接确认即可。紧接着会让你选择版本如果你手头没有商业 License就选试用版。可能有人担心试用期过了怎么办实际上 CM 6.3.x 在试用期结束后会退回到 Free 免费版核心的 HDFS、YARN、Hive、HBase 组件都不受影响只是少了部分企业级安全特性。不要因为试用两个字就被劝退。6.2 主机接管输入 IP 列表并完成 SSH 分配在添加主机步骤把集群里所有节点的 IP 或主机名都填进去逗号分隔node01,node02,node03接下来选择根账号和 SSH 认证方式。我习惯用密码认证因为前面已经配置过 SSH 免密CM 在接管过程中其实能复用。这里如果你选择所有主机都使用相同凭据就填 root 和 root 的密码。接管过程会持续几分钟CM 会把 Agent 包推到目标机并自动修改/etc/cloudera-scm-agent/config.ini里的 server_host指向中间机。这块如果失败直接看目标机上的/var/log/cloudera-scm-agent/cloudera-scm-agent.log通常原因就是 hosts 解析错误或者 SSH 端口不通。6.3 指定本地 Parcel 仓库的准确写法主机接管之后向导会进入选择 Parcel 版本界面默认先给出一系列在线版本。这里要做的操作是不要选默认的公共仓库,去找自定义仓库 URL相关的输入框然后把本地地址填进去http://repo-host/cdh6/6.3.2/parcels/填完之后列表里应该会出现CDH 6.3.2这个条目。如果没有出现说明 CM Server 访问不到manifest.json先用 4.3 里的 curl 排查。如果出现了但界面提示Parcel 不正确或校验失败那就是.sha文件没放好。在这个阶段还会有一个GPL 条款勾选项需要勾选同意否则 Parcel 无法激活。6.4 在所有主机上部署和激活 Parcel选定 CDH 6.3.2 之后向导会依次执行下载、分发、解压、激活四步。因为仓库在本地下载速度很快分发过程会对每台 Agent 并行传输。这里最需要耐心的是解压阶段一个大 Parcel 包解压后可能占用几 GB 磁盘而且每个节点上的/opt/cloudera/parcels目录需要充足空间。等待所有节点都显示已激活就进入后续服务配置。7. Parcel 分发失败的排查链路与验证命令7.1 三类最常见故障的具体表现我在多次实施中总结过Parcel 分发阶段出问题基本都是这三个原因manifest 不可见房间里填了仓库 URL列表不出现版本。根因多为 Nginx root 路径错位或者目录里根本没有 manifest.json。下载后校验失败列表能出 CDH 6.3.2但进度条在 99% 时红叉。根因是.sha文件损坏或文件名被改名CM 用它算出的 SHA1 对不上。分发到某一台节点失败其他节点都成功只有某台失败。根因几乎都是该节点磁盘空间不足或者/opt/cloudera目录被占用了。7.2 排查链路先日志再 curl后空间遇到问题不要慌第一步永远是看日志。CM Server 的日志在/var/log/cloudera-scm-server/cloudera-scm-server.logAgent 的日志在/var/log/cloudera-scm-agent/cloudera-scm-agent.log如果在 Server 日志里看到Failed to fetch parcel from repository就去目标节点上手动测试curl -sI http://repo-host/cdh6/6.3.2/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel确认返回200 OK之后再看目标机器上的剩余空间df -h /opt /tmp/opt/cloudera是 Parcel 解压目录如果小于 10GB建议清理或扩大分区。还有一个我不止一次踩过的坑/tmp空间被占满CM 在做远程推送时会写入临时文件然后直接报no space left on device。这种原因看 Server 端日志可能看不大出来但在 Agent 端日志里非常明显。7.3 日志速查表出问题时按图索骥日志位置主要看什么/var/log/cloudera-scm-server/cloudera-scm-server.logParcel 仓库解析、数据库连接、Web API 错误/var/log/cloudera-scm-agent/cloudera-scm-agent.logAgent 心跳、下载 Parcel、解压进度/var/log/cloudera-scm-server/cloudera-scm-server.log 的 db.properties数据库连接信息我在生产环境维护里会把这几类日志统一交给日志采集方便后续出现问题时快速搜索ERROR和Exception关键字。8. 服务角色分配与启动后的默认配置调整8.1 角色分配参考单机测试和三节点生产到了分配角色这一步如果是单机测试直接把所有角色都丢到同一台机器上即可。如果想搭一套勉强能跑开发任务的三节点集群我一般会这样分配服务node01node02node03HDFS NameNode是HDFS SecondaryNameNode是HDFS DataNode是YARN ResourceManager是YARN NodeManager是Zookeeper是是是Hive Metastore是HiveServer2是HBase Master是HBase RegionServer是这个表只是一个参考。Zookeeper 至少三节点是为了保证选主可用DataNode 和 NodeManager 放同一批机器是为了让计算尽量本地化减少跨机数据传输。8.2 启动顺序与必调参数角色分配完成之后CM 会自动生成一大堆默认配置。我每次都要手动改两个地方第一内存预留。CM 在主机-配置里默认会预留比较多的内存用来跑监控、运行 MapReduce 等辅助进程。如果机器只有 16GB我建议把 YARN 的yarn.nodemanager.resource.memory-mb调低比如设置到 8GBHDFS NameNode 堆内存根据实际元数据规模调整小集群 2GB 足够。第二HDFS 目录。默认的数据目录一般指向/dfs/nn、/dfs/dn这类路径CM 会自动创建。如果你希望数据盘挂在/data1、/data2等独立磁盘就要在角色配置里把目录改成相应位置。这里有非常重要的一个点修改目录后一定要确认目标盘挂载正确并且/dfs目录不是由不明脚本挂载的临时盘否则集群重启后数据目录丢失会非常麻烦。启动顺序建议从依赖最底层开始先 Zookeeper再 HDFS然后 YARN最后启动 Hive、HBase 等上层服务。CM 界面上有启动按钮它会自动按照依赖关系排序但如果你发现启动顺序乱套可以选择逐步启动。8.3 健康检查与常用命令服务全部启动后不要急着拿去跑任务先看一眼健康状态。直接在 CM 首页就能看到 HDFS 和 YARN 的星星点进去看是否有严重问题。我习惯在命令行再验证一层hdfs dfsadmin -report curl http://node01:8088/ws/v1/cluster/info前者能看到 DataNode 数量和容量后者能看到 ResourceManager 的集群状态。如果 HDFS 层面显示Live datanodes (0)基本就是 DataNode 进程没起来去对应机器执行systemctl status cloudera-scm-agent tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log这里要额外提一点不要用 service 命令单独启停 HDFS 的某个角色在 CDH 体系里角色的生命周期由 CM Agent 统一管理。你手动 kill 掉进程后Agent 过几秒又会拉起来看起来像服务启动失败其实是自己干扰了管理。整套流程走完我最想提醒的是CDH 6.3.x 现在越来越像一个存量方案本地仓库这种部署方式的价值反而更大了。中间机上那些 RPM 和 Parcel 一定不要随便清理后续新增节点、批量修复 Agent甚至重新搭建一套一模一样的环境都能靠它快速恢复。如果理解了整套仓库的构成后面无论换成 Apache Hadoop 还是其他发行版这个先有一台能分发的中间机再统一接管所有节点的思路都是通用的。最后再补充一个冷门小技巧部署完成后把中间机上的仓库目录做一次内网备份盘或者打成 tar 包存到离线介质里关键时刻能救命。
