Cloudera Manager和CDH的本地仓库方式搭建一直是很多大数据团队过不去的坎。网上教程不少但多数要么版本对不上要么跳过了关键细节照着做很容易卡在半路。这次要分享的是CM 6.3.1配CDH 6.3.2的完整离线搭建流程重点围绕“本地仓库方式”展开——也就是把安装包全部同步到内网通过自建yum源和parcel本地源来完成整个集群部署。这种方式适合没有外网、或者外网带宽紧张的生产环境也适合想彻底掌控版本依赖、不被在线仓库变动牵着走的团队。整个过程我自己在测试环境和生产环境各走过一遍踩了不少坑这篇就按我最终跑通的顺序来写尽量把每个容易卡住的地方都讲透。1. 为什么选本地仓库方式三个绕不开的诉求1.1 本地仓库和在线安装的本质差别CDH的安装看起来只有两条路在线方式和本地仓库方式。在线方式在CM向导里填一个官方地址剩下的交给系统自己下载看似省事但实际用起来很痛苦。Cloudera官方仓库在国外国内网络环境下经常下载一半就中断parcel包动辄两三个GB重来一次的成本太高。另外一个隐藏问题是在线方式下CM和CDH的版本是绑定的官方仓库里的文件列表一变你按旧教程填的地址就可能404整个流程被迫中断。本地仓库方式的本质是把“下载”和“安装”这两个阶段彻底分离。下载阶段一次性把CM的rpm包、CDH的parcel包、依赖的JDK等全部同步到内网服务器上然后用nginx或httpd做一个静态文件服务集群里的所有节点都从这个内网地址拉取安装内容。这样做的好处很直接安装过程不再依赖外网质量所有节点下载速度取决于内网带宽几百MB的文件几乎是秒级完成版本完全可控官方仓库内容发生变化时本地仓库不受影响排错也简单哪个包缺失、文件损坏直接在本地目录里检查就行。1.2 版本搭配逻辑为什么是CM 6.3.1配CDH 6.3.2版本选择上CM 6.3.1和CDH 6.3.2是官方明确支持的搭配组合。CDH 6.3.2是6.x系列里比较稳定的一个版本对应Hadoop 3.0.0系列生态组件Hive、HBase、Kafka、Spark等主流组件版本都比较成熟社区里跑这个组合的团队很多遇到问题时能找到大量参考资料。CM 6.3.1作为管理端对CDH 6.3.2的兼容性在官方文档里写得很清楚不会出现“管理端认识不到底层组件版本”这种尴尬局面。需要注意的是不要自己去随意组合版本。比如CM 6.3.0配CDH 6.3.2表面上可能能跑起来但CM的parcel校验逻辑是写死在代码里的如果parcel清单里某些组件版本和CM预期不一致安装过程中会在“检查主机”或“分发parcel”阶段报各种奇怪的错误而且这种错误很难通过日志定位。所以版本搭配上建议大家一步到位直接按CM 6.3.1 CDH 6.3.2这套组合来。1.3 搭建前的硬件与系统环境准备清单本地仓库方式虽然对硬件要求不高但集群本身的角色分配会影响后续的安装参数。这里给出我实际部署用的一套规划大家可以根据自己的节点数量调整。节点角色数量配置要求担任角色仓库服务器12核4GB起磁盘至少200GBnginx文件服务存放CM rpm包与CDH parcel包主节点18核16GB起磁盘500GB以上CM Server、NameNode、ResourceManager、HBase Master等从节点按需4核8GB起磁盘按数据量规划DataNode、NodeManager、RegionServer等操作系统建议选择CentOS 7.9或兼容版本内核版本不要太高CDH 6.3.2在CentOS 7.x上验证得最充分。所有节点需要提前做好三件事关闭SELinuxsetenforce 0并修改/etc/selinux/config、关闭或配置防火墙本地仓库搭建期间建议先关闭集群跑起来后再按需开放端口、配置好主机名解析/etc/hosts要求所有节点都能通过主机名互相ping通。另外所有节点的时间必须同步CDH对时钟偏移非常敏感NTP或chrony都行但一定要确保偏差在几十毫秒以内。这一步别偷懒后面很多“玄学问题”其实就是时间不同步引起的。2. 搭建本地仓库核心操作全流程2.1 仓库服务器的目录规划与nginx配置仓库服务器是整个安装过程中的“粮仓”所有节点都要从这里拿安装资源。我习惯把目录结构规划得清晰一些/var/www/html/ ├── cm │ └── 6.3.1 │ └── repodata ├── cdh │ └── 6.3.2 │ ├── 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 └── jdk └── jdk-8u202-linux-x64.tar.gznginx配置只需要一个简单的静态文件服务。关键配置点是root指向/var/www/htmlautoindex on打开目录索引这样后面在CM向导里填URL时可以直接浏览到文件列表方便排查路径问题。如果nginx还不熟悉直接用httpd替代也可以核心就是一个能通过HTTP访问的静态目录。配置示例nginxserver { listen 80; server_name repo-server; root /var/www/html; autoindex on; charset utf-8; }启动后先自己在浏览器里访问 http://仓库服务器IP/cm/6.3.1/ 验证一下能看到repodata目录就说明基本通了。2.2 同步CM的rpm包与CDH的parcel包CM仓库的rpm包文件需要在Cloudera官网的下载页面找到CM 6.3.1对应的repository。里面有一个cm6.3.1/目录对应RedHat7的rpm包放在repodata目录下。你可以直接用wget递归下载整个目录也可以手动下载几个核心rpm包再补全依赖。我实际测试下来最省心的方式是找一台有外网的机器用wget把整个repo目录镜像下来然后再传到内网仓库服务器上。命令示例wget --mirror --no-parent -nH -P /var/www/html/cm/6.3.1/ \ https://archive.cloudera.com/cm6/6.3.1/redhat7/yum/RPM-GPG-KEY-cloudera但cm6.3.1的完整rpm列表比较多强烈建议先确认网络稳定再执行否则中途断了就前功尽弃。同步完之后在仓库服务器上执行createrepo命令生成元数据cd /var/www/html/cm/6.3.1 createrepo .CDH的parcel包也是从Cloudera官网下载找到CDH 6.3.2对应的parcel目录。需要下载三个文件parcel主包、同名的.sha校验文件、manifest.json清单。parcel文件比较大3GB左右下载时记得校验大小是否完整。这几个文件下载后放到/var/www/html/cdh/6.3.2/目录下即可parcel不需要createrepo。2.3 配置所有节点的本地yum源仓库服务器准备好之后集群里的所有节点都要新增一个指向本地仓库的yum源配置文件。在/etc/yum.repos.d/目录下新建cloudera-manager.repo[cloudera-manager] nameCloudera Manager baseurlhttp://仓库服务器IP/cm/6.3.1/ gpgcheck0 enabled1gpgcheck这里建议直接设为0。因为本地仓库已经可控没必要再做GPG校验这样可以避免密钥导入问题导致安装失败。如果你确实想开启gpgcheck需要先把官网的RPM-GPG-KEY-cloudera文件下载到本地并import但实际收益很低反而多一个出错点。配置完成后执行yum clean all yum makecache看到仓库元数据缓存成功说明本地yum源已经生效。然后用yum list | grep cloudera验证一下能列出cloudera-manager-server等包名就说明这一步成功了。3. 安装Cloudera Manager Server与Agent3.1 主节点安装CM Server在主节点上直接通过yum安装CM Serveryum -y install cloudera-manager-daemons cloudera-manager-agent cloudera-manager-server这一步会把CM的daemons、agent、server全部装上依赖的JDK版本也会自动匹配。CM 6.3.1默认会带OpenJDK但我个人更建议后面手动替换成Oracle JDK 8因为生产环境上Oracle JDK的兼容性和性能表现更稳定尤其是跑Spark或Hive这种计算密集型的组件时区别更明显。安装完成后CM Server需要连接数据库。如果规模不大、节点数在十台以内直接用CM自带的嵌入式PostgreSQL是最省事的安装脚本会自动完成数据库初始化/opt/cloudera/cm/schema/scm_prepare_database.sh embedded如果要用外部MySQL需要提前建好数据库和账号并下载对应的JDBC驱动jar包放到/usr/share/java/目录下命名为mysql-connector-java.jar。这个细节很多人容易漏漏掉的后果是启动CM Server时日志里报“找不到JDBC驱动”排查起来很头疼。3.2 Agent安装与配置所有从节点上只需要安装Agentyum -y install cloudera-manager-agent安装后修改/etc/cloudera-scm-agent/config.ini把server_host改成主节点的主机名或IPserver_host主节点主机名然后启动Agent服务systemctl start cloudera-scm-agent systemctl enable cloudera-scm-agent这里有个重要的验证技巧在CM Server所在的主节点上查看/var/log/cloudera-scm-agent/cloudera-scm-agent.log如果Agent成功注册日志里会显示与Server建立了连接同时心跳信息会持续更新。如果日志一直报连接拒绝先检查主节点的7180端口是否监听再确认config.ini里的server_host是否真的能被解析。3.3 数据库初始化与CM Server启动依赖数据库类型不同启动前先验证一下数据库状态。用嵌入式PostgreSQL的话CM安装包自带的服务会自动启动。用外部MySQL的话先确认scm账号可以正常连接mysql -uscm -p -h主节点IP scm确认无误后启动CM Serversystemctl start cloudera-scm-serverCM Server的启动过程比较慢首次启动需要初始化大量配置最少要等两三分钟。查看日志tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到“Started Jetty server”这行日志说明CM Server已经启动完成。此时访问 http://主节点IP:7180 应该能进入Cloudera Manager的登录页面默认账号密码是admin/admin首次登录会强制修改密码。4. 通过CM界面安装CDH集群本地仓库的关键应用4.1 创建集群并添加主机登录CM界面后第一步是创建集群。向导会要求填写集群名称然后进入“添加主机”步骤。这里建议勾选“当前管理的主机”也就是让CM自动发现已经通过Agent注册的节点。在添加主机时CM会要求提供SSH凭据需要填入root账号的密码或密钥。实际上如果Agent已经正常运行CM是可以跳过SSH直接识别主机的但SSH这一步同时承担了后续parcel分发的任务所以还是建议提前配置好SSH免密登录让主节点到所有从节点的免密都通。主机识别成功后CM会提示给主机分配角色目录直接保持默认即可后面可以在“主机”页面单独调整。4.2 指定本地parcel仓库地址这是整个流程里最容易出错的环节。在向导的“选择存储库”步骤默认情况下CM会填写Cloudera官方仓库地址必须把它改成我们自己的本地仓库地址。具体操作是选择“自定义存储库”把官方地址删掉填入http://仓库服务器IP/cdh/6.3.2/填完之后CM会去读取该目录下的manifest.json文件解析出可用的parcel包列表。这里有两个高频报错提示“无法获取manifest.json”多半是URL路径不对或者autoindex没开启先在浏览器里访问试试。提示“parcel文件校验失败”.sha文件内容与parcel包实际生成的SHA值不一致多半是下载时文件损坏。重新下载parcel包并把.sha文件内容里多出来的换行符去掉确保只有一串64位哈希值。4.3 分发parcel与角色分配仓库地址配置正确后CM会列出CDH-6.3.2的parcel包点击“下载”按钮。由于parcel已经在本地仓库CM会直接把parcel文件从仓库服务器复制到主节点然后再从主节点分发到所有从节点。这个过程非常快因为走的是内网带宽。分发完成后还需要点击“分发”和“激活”按钮parcel才会真正生效。角色分配这一步强烈建议不要使用CM的默认自动分配而是手动规划。我的经验是主节点承载NameNode、ResourceManager、HBase Master、Hive Metastore Server、Oozie Server这些管理型角色。从节点统一承载DataNode、NodeManager、RegionServer这些计算存储型角色。HiveServer2或Impala Daemon可以放在其中一个从节点上但要注意内存预留。角色分配完成后CM会检查各项配置。如果是中小规模集群内存配置保持默认即可如果是大内存机器要注意调整hadoop-heap-size和HBase的堆内存参数否则可能出现“内存分配超出物理内存”的警告。4.4 集群安装完成后的首次启动验证安装向导最后一步会依次启动所有服务。第一个启动完成的通常是HDFS可以重点关注NameNode的启动日志。首次启动偶尔会遇到DataNode无法连接NameNode的问题绝大多数原因都是时间同步或者主机名解析出了问题。建议等所有服务启动完成后做几个基础验证HDFS执行hdfs dfsadmin -report确认所有DataNode都已上报存储空间和实际磁盘一致。YARN访问ResourceManager的Web界面确认NodeManager列表完整。Hive在beeline里执行一个简单的show databases确认Metastore连通。HBase进入HBase Shell执行status确认RegionServer在线。这几个验证都通过整个CDH集群基本就算搭建完成了。5. 常见问题与排查技巧实录5.1 仓库相关报错速查表报错现象可能原因解决方法yum makecache失败baseurl路径错误或目录无repodata检查仓库目录/var/www/html/cm/6.3.1下是否有repodata然后重新createrepoCM页面提示无法获取manifest.json仓库URL末尾的目录层级不对在浏览器里访问URL确认能列出CDH-6.3.2-...parcel文件parcel下载后校验失败.sha文件带换行或parcel包损坏去除.sha换行重新下载parcel添加主机时SSH连接失败SSH端口不是22或免密没配对手动测试ssh 主机名确保免密通过Agent无法连接Serverconfig.ini的server_host配置错误检查/var/log/cloudera-scm-agent下日志看连接报错的具体IPHDFS DataNode起不来时钟偏移过大NTP强制同步后重启DataNode5.2 时间同步与权限的隐形坑时间同步这个问题我在第一套环境里吃过亏。当时多个节点时间差了将近五分钟表现是NameNode正常但DataNode就是反复启动失败日志里报一堆接收块超时。后来排查了一圈才发现是时钟问题。推荐用chrony配置并且安装完集群后每天自动同步这一点在/var/log/messages里能看到NTP校正的痕迹。另一个隐形坑是parcel目录的权限。nginx默认以nobody用户运行如果parcel文件是从别的地方拷贝过来的属主可能是root权限不足会导致CM下载parcel时HTTP返回403。所有放在/var/www/html下的文件建议统一执行chown -R nobody:nobody /var/www/html这个细节看起来很不起眼但实际遇到的人不少。5.3 印象最深的一个排障过程我印象最深的一次排障是某次安装时CM向导在“分发parcel”环节卡在99%进度条一直不动。第一反应是网络问题但内网带宽明明很足。后来在CM的主节点上执行lsof -p $(pgrep -f parcel)发现有一个java进程一直占着一个打开的parcel文件句柄文件本身并没有在写入。最后发现是因为CM在分发前需要先做一次SHA校验而校验过程会读取整个parcel文件3GB的文件在磁盘IO本身就繁忙的节点上耗时很长看起来就像卡住了。解决方案也很简单等它十分钟左右就自动过去了不需要任何额外操作。但如果超过半小时还在99%就要检查主节点磁盘IO和CM日志里是否有读取异常。这个现象说明了本地仓库方式的性能优势parcel分发走内网瓶颈几乎只在磁盘IO而不是网络。5.4 已经安装完成后的运维小建议集群能跑起来只是开始后面维护才是重头戏。有几个小建议都是实际运维中验证过的本地仓库服务器建议做RAID1或定期备份因为parcel包一旦损坏重新从官网下载的成本很高。每次安装新组件前先看CM页面的“存储库”设置确认还是指向本地仓库防止误操作用在线方式拉包。定期检查/var/log/cloudera-scm-server和/var/log/cloudera-scm-agent的磁盘占用日志滚动不及时会把根分区撑满。版本升级前在本地仓库下载好新版本parcel并测试分发再操作线上集群避免升级过程中下载失败导致集群状态不一致。结尾本地仓库这套流程后续还能怎么扩展说实话本地仓库方式这套流程是CDH部署里最值得花时间彻底搞懂的一条路。官方在线方式虽然看起来快但一旦网络抖动、仓库调整、包版本变动会让你浪费大把时间在等下载和找包上。自己把仓库建好掌握文件、目录、校验、分发这条链路之后后续无论是加节点、加服务、还是升级组件都会变得非常顺。大家把环境搭好之后签个名比如校验parcel的SHA把这一步固定成操作模板平时维护就可以更放心。如果后面有空再写一篇关于日常维护和组件升级的文章。