手上这批机器没有外网机房只开了 7180 这个口子你又得在几天之内把一套 CDH-5.7.0 拉起来——这种场景下Parcels 离线安装配置几乎是唯一不折腾的选择。我前后折腾过十来个这样的小集群早期也走过 yum 装 RPM 包的老路最后都被依赖和版本对齐搞到怀疑人生。这篇文章要讲的就是怎么在完全无外网的环境里用本地 YUM 源把 Cloudera Manager 装好用一份完整的 Parcel 包把 CDH-5.7.0 分发到每台机器上再激活、分配角色、跑通服务。适合谁看手上有闲置物理机、内网服务器或者要给客户部署一套 POC 环境又或者公司安全策略卡死了所有出网流量的运维和开发。整套流程我会按我实际操作的顺序写包括参数怎么算、目录怎么规划、哪些地方最容易翻车你照着抄基本能复现。1. 方案定调为什么这套环境必须走 Parcel 离线1.1 先把场景讲透什么样的机房会逼你走离线这条路我接触到的离线场景大致三类。第一类是金融、政务类的内网机房物理隔离机器连外网 DNS 都不配你在上面执行yum install会一直卡在超时。第二类是客户现场交付机器是刚上架的新机器系统盘里只有基础包操作系统的软件源还没配更别说 CDH 的源。第三类是测试环境为了复现生产问题必须和生产完全一致的版本但测试网段不放通外网。这三类场景有个共同点你可以把文件拷进去但不能让机器自己去网上下载。所以整个思路就变成了把外网的东西搬到本地来然后在本地做一个微型的、自洽的软件源。Cloudera 官方其实也提供了 parcel 形式的离线分发这就是 Parcel 方案存在的意义。还有一个现实因素CDH-5.7.0 是比较老的一个版本官方仓库早就停止对外提供服务了你现在再想用在线方式装连源地址都访问不到。所以不是要不要离线而是只能离线。这一点得先想明白不然你在机房里试半天在线安装纯属浪费时间。1.2 Parcel 和 Package 的真实差异别选错了再返工Cloudera 提供了两种软件分发方式PackageRPM/deb和 Parcel。很多人觉得区别只是装法不同实际差别挺大我列个表对照一下。对比维度PackageRPM方式Parcel 方式安装位置分散在/usr/lib/hadoop等系统路径集中放在/opt/cloudera/parcels依赖处理需要解决 RPM 依赖链容易起冲突自包含不依赖系统包多版本共存很难卸载重装容易残留天然支持多个版本目录并存升级回滚风险高回滚基本靠重装切换软链接即可回滚离线部署需要完整 RPM 仓库只需一个 parcel 文件加校验文件完整性校验依赖 RPM 自身签名有 .sha 校验和 manifest 清单我在一个客户的测试集群上就吃过 RPM 的亏系统里已经装了某个版本的 snappyyum install的时候依赖解析把系统自带的库给顶掉了结果机器上另一个业务程序直接起不来。Parcel 因为整套运行时都放在自己的目录里走的是自己的LD_LIBRARY_PATH不存在这个问题。所以现在的惯例是只要不是极老的环境或者有特殊合规要求一律用 Parcel。这篇文章后面所有步骤也都基于 Parcel 展开。1.3 机器和角色规划第一台机器选错后面全得重来我先给一套五节点的规划实际你可以按数据量缩到三台但建议不要少于三台因为 HDFS 默认三副本少于三台连副本都摆不开。主机名角色配置建议磁盘规划node01CM Server、MySQL、NameNode、ZooKeeper8C/16G系统盘 200G 数据盘 1Tnode02NameNodeHA 备、DataNode、JournalNode8C/32G系统盘 200G 数据盘 2Tnode03DataNode、NodeManager、ZooKeeper8C/32G数据盘 4Tnode04DataNode、NodeManager、ZooKeeper8C/32G数据盘 4Tnode05DataNode、NodeManager、Hive Metastore8C/32G数据盘 4T这里有几个我踩过的坑值得提前说。CM Server 和元数据库放同一台机器在小集群里没问题但千万别把 CM Server 放到某台 DataNode 上再给它塞满数据盘因为 CM Server 挂了整个集群就没法管理了而它本身又不做数据放在一台脏活机器上是浪费。另外 ZooKeeper 建议三台起步且是奇数两台做不了容错四台的投票机制反而更脆。磁盘规划上还有一条数据盘不要做 LVM 跨盘卷HDFS 自己就能管多块盘你把四块盘做成一个 raid5反而丢掉了 HDFS 的副本冗余优势而且写性能会掉得厉害。我一般直接fdisk分单分区挂到/data/dfs/dn这样的目录下用 CM 里的DataNode 数据目录配置项逗号分隔列出来就行。2. 系统底座装 CM 之前必须打好的地基2.1 操作系统与 JDK 的版本红线CDH-5.7.0 支持的平台基本是 RHEL/CentOS 6.x 和 7.x我一般选 CentOS 7.2 或 7.4因为这两个版本的系统库和 CDH 5.7 的配套性最好。CentOS 8 及以上不要考虑glibc 版本和 Python 版本都对不上强行装能装上去但运行时会出各种莫名其妙的 JVM 崩溃。JDK 是整个栈里最不能含糊的一环。CDH 5.7.0 官方推荐的组合是 Oracle JDK 1.8.0_60 到 1.8.0_1xx 之间我实测用 1.8.0_144 很稳。不要用 OpenJDK也不要用更新的 1.8.0_2xx 之后的版本因为后面版本的 TLS 默认配置变了某些老组件连不上 KM Server 的 TLS 端口。所有节点必须用同一个版本、同一个小版本号JDK 不一致是后面某个节点服务起不来的高频原因。Python 这块CM 5.7 的 Agent 需要 Python 2.7。CentOS 7 自带 2.7 没问题CentOS 6 自带的是 2.6必须额外装一个 2.7并且要保证/usr/bin/python指向它否则 Agent 启动直接报语法错。JDK 的安装我习惯放在/usr/java/jdk1.8.0_144然后用alternatives注册或者直接写进环境变量。注意不要只配JAVA_HOMEPATH里也得把$JAVA_HOME/bin放最前面因为系统里可能还有别的 java 可执行文件。2.2 hosts、防火墙、SELinux 三件套这三样是装 CM 之前最基础的一步但每年还是能看到有人踩。主机名、hosts 解析、防火墙和 SELinux缺一个都会让 Agent 心跳失败或者服务启动卡住。先说主机名和 hosts。每台机器都要设置成最终要用的名字并且hostname和hostname -f返回一致。hosts 文件里每台机器都要写全所有节点包括自己。很多人只在自己的机器上写自己的 IP然后 CM 从 server 机器上分发时解析不到其他节点表现就是主机列表里只出现一台机器。# 每台机器都执行保持一致 cat /etc/hosts EOF 172.16.10.11 node01 172.16.10.12 node02 172.16.10.13 node03 172.16.10.14 node04 172.16.10.15 node05 EOF防火墙在 CentOS 7 上直接关掉firewalld因为 CDH 组件之间开的端口太多挨个放行不现实。systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/configSELinux 这里特别提醒一句setenforce 0只是临时生效机器一重启就恢复 enforcing/etc/selinux/config里的那行才是永久的。很多人装完当次没事过几天机器重启了CM Agent 起不来查半天以为是磁盘问题实际就是 SELinux 又把端口给拦了。注意如果客户的合规要求不允许关闭 SELinux那你得用semanage port -a一个个放行这活儿工作量非常大提前跟人沟通好别做到一半才发现关不了。2.3 时钟同步和内核参数被低估的隐形杀手时钟不同步在 CDH 里的表现非常隐蔽。Kerberos 认证失败、YARN 的 ResourceManager 认为 NodeManager 失联、HBase 的 region 时间戳错乱这些问题的根因往往就是某台机器慢了几十秒。内网环境没有 NTP 服务器就用 node01 做时间服务器其余机器向它同步。# node01 上启动 chronyd 作为服务端 systemctl enable chronyd systemctl start chronyd # 其余节点配置指向 node01 echo server node01 iburst /etc/chrony.conf systemctl restart chronyd chronyc sources -v内核参数方面vm.swappiness要调低Hadoop 组件最怕被换出内存vm.overcommit_memory设成 1否则 JVM 申请大堆内存时可能被内核拒绝THP透明大页一定要关这是 HBase 和 Impala 性能杀手。# /etc/sysctl.d/99-cloudera.conf vm.swappiness 10 vm.overcommit_memory 1 net.core.somaxconn 32768 net.ipv4.tcp_tw_reuse 1 net.ipv4.ip_local_port_range 10240 65000sysctl --system # 关闭 THP echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defragTHP 关闭要写进/etc/rc.local并给执行权限否则重启会恢复。文件句柄数也要放开CDH 里的 DataNode 一开起来就是上千个文件句柄默认的 1024 根本不够。cat /etc/security/limits.d/cloudera.conf EOF * soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536 EOF2.4 SSH 免密与 cloudera-scm 用户的前置准备CM Server 安装时会自动创建cloudera-scm这个用户Server 通过它去各节点执行命令、分发 Parcel所以理论上只需要 root 到各节点的免密很多操作 CM 自己会处理。但为了排查方便我习惯把 root 到所有节点的免密都打通同时把cloudera-scm用户的免密也配上。ssh-keygen -t rsa -N -f ~/.ssh/id_rsa for ip in 11 12 13 14 15; do ssh-copy-id -i ~/.ssh/id_rsa.pub root172.16.10.$ip done最后做一次批量验证确保每台机器的 hostname、JDK 版本、时间都对齐了。for ip in 11 12 13 14 15; do echo 172.16.10.$ip ssh root172.16.10.$ip hostname -f; java -version 21 | head -1; date done这一步做完地基就算打好了。后面出问题基本不会是环境问题能省掉大量排查。3. 本地 YUM 源与 Cloudera Manager 安装3.1 用 createrepo 把 RPM 变成一个可用的私有源离线环境下装 CM你需要两类文件CM 自身的 RPM 包cloudera-manager-server、cloudera-manager-daemons、cloudera-manager-agent 等以及它们依赖的系统包比如 MySQL 客户端库、Python 相关依赖。我一般在外网找一台能上网的 CentOS 7 机器用yumdownloader把依赖全部拉下来。yum install -y yum-utils createrepo httpd mkdir -p /opt/repo/cm5.7 yumdownloader --resolve --destdir/opt/repo/cm5.7 \ cloudera-manager-daemons cloudera-manager-server cloudera-manager-agent--resolve这个参数是关键它会把所有依赖包一并下载下来不然到内网再装还是缺依赖。把下好的包拷到 node01建仓并启动 HTTP 服务。mkdir -p /var/www/html/cm5.7 cp /opt/repo/cm5.7/*.rpm /var/www/html/cm5.7/ createrepo /var/www/html/cm5.7/ systemctl enable httpd systemctl start httpd curl -I http://172.16.10.11/cm5.7/repodata/repomd.xml所有节点加上这个源# /etc/yum.repos.d/cm5.7.repo [cm5.7] nameCloudera Manager 5.7 Local baseurlhttp://172.16.10.11/cm5.7/ enabled1 gpgcheck0gpgcheck0在内网自建源里问题不大但如果客户有安全审计你还需要把 RPM 的 GPG 公钥导入把gpgcheck改回 1这一步别偷懒交付的时候会被问到。提示createrepo每次加了新包都要重新执行一遍否则repodata目录里的元数据还是旧的yum install会报 No package available。3.2 MySQL 元数据库字符集和连接数提前调好CM 需要一个元数据库保存集群的配置、状态、审计日志。MySQL 是最常见的选择推荐 5.6 或 5.7。有几个参数必须在初始化前就改装完了再改会很痛苦。# /etc/my.cnf [mysqld] character-set-server utf8 collation-server utf8_general_ci max_connections 500 innodb_buffer_pool_size 2G innodb_flush_log_at_trx_commit 2 transaction-isolation READ-COMMITTEDtransaction-isolation必须是 READ-COMMITTED默认的 REPEATABLE-READ 会让 CM 在并发更新配置时出现死锁。character-set-server必须是 utf8如果用 latin1后面 Hive 的注释里有中文就会乱码甚至写入失败。建库建用户的 SQL 我现在都写成一个脚本存档重装的时候直接跑。CREATE DATABASE scm DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE amon DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE rman DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE hue DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE metastore DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE oozie DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE USER scm% IDENTIFIED BY Scm_2024#pwd; GRANT ALL PRIVILEGES ON scm.* TO scm%; -- 其余库按同样方式授权此处省略重复语句 FLUSH PRIVILEGES;密码别用简单字符CM 在安装时会做一轮校验太弱的密码会被拒绝而且包含特殊字符的时候记得在 shell 里用单引号包起来。3.3 CM Server 与 Agent 的安装细节在 node01 上装 Server 和 daemonsyum install -y cloudera-manager-daemons cloudera-manager-server其余节点装 agentyum install -y cloudera-manager-daemons cloudera-manager-agent装完先把 MySQL 的 JDBC 驱动放到位CDH 5.7 自带的是老版本驱动用新的 mysql-connector-java 5.1.47 比较稳。cp mysql-connector-java-5.1.47.jar /usr/share/java/mysql-connector-java.jar chmod 644 /usr/share/java/mysql-connector-java.jar然后初始化 SCM 元数据库这一步会创建表结构。/usr/share/cmf/schema/scm_prepare_database.sh mysql \ -h 172.16.10.11 -P 3306 \ scm scm Scm_2024#pwd成功的话会看到 All done, your SCM database is configured correctly!。如果报 Cannot connect to database多半是密码里有特殊字符被 shell 吃掉了或者 MySQL 的bind-address绑在了 127.0.0.1 上远程连不进来。在 agent 节点上修改/etc/cloudera-scm-agent/config.ini里的server_host[General] server_hostnode01 server_port7182然后所有节点含 node01启动 agentnode01 再启动 server# 全部节点 systemctl start cloudera-scm-agent # node01 systemctl start cloudera-scm-server tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log等到日志里出现 Started Jetty server 和 Generated new RSA key pair就可以用浏览器访问http://172.16.10.11:7180了默认账号密码都是admin。4. Parcel 仓库搭建与集群落地4.1 Parcel 文件的命名规则和校验方法Parcel 文件名的格式是固定的CDH-版本-构建号.parcel比如CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel。这个名字一个字都不能改改了以后 CM 认不出来界面上根本不显示这个包。我见过有人为了好识别在后面加个_final结果在界面里死活刷不出来排查了两个小时。下载的时候会有两个文件.parcel本体和.parcel.sha。把 sha 文件打开看看正常是一个 40 位的十六进制串。如果里面是 HTML 内容比如htmlhead...说明你下载的方式不对拿到的其实是某个登录页面或者 404 页面这种情况下就算你把.parcel放进去CM 也会在分配时校验失败。sha1sum CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel cat CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel.sha # 两个值必须完全一致这一步我建议在拷进内网之前就做一次拷进去之后再校验一次。U 盘、移动硬盘、跳板机中转到一半断掉的情况我都遇到过文件大小对得上但内容是坏的。4.2 本地 HTTP 服务和 parcel-repo 目录的权限CM 读 Parcel 有两种方式一种是从本地目录读配置parcel_repo_dir一种是走 HTTP 拉。我强烈推荐走 HTTP因为多节点分发时走 HTTP 服务最稳本地目录方式在节点多的时候容易因为文件锁出问题。在 node01 上建一个专门的目录mkdir -p /var/www/html/parcel-repo chown -R cloudera-scm:cloudera-scm /var/www/html/parcel-repo chmod 755 /var/www/html/parcel-repo cp CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel* /var/www/html/parcel-repo/权限这块有个坑chown到cloudera-scm之后如果 httpd 是以apache用户运行的反而读不到文件。稳妥的做法是目录权限 755、文件权限 644属组设成cloudera-scm但不影响其他用户读。然后手动生成 manifest 文件CM 就是靠它识别有哪些 parcel 可用的cd /var/www/html/parcel-repo /opt/cloudera/parcel-repo/../parcel-repo/../bin/../ # 实际用下面这条CM 5.7 提供了脚本路径是/usr/share/cmf/bin/gen_manifest.sh附近实际更常用的做法是让 CM 自己去拉。这里有个更简单的办法在 CM 界面的主机 - Parcel页里把远程 Parcel 存储库 URL填成你的 HTTP 地址CM 会自动解析目录下的所有文件并生成清单。# 验证 HTTP 服务能正常返回 curl -s http://172.16.10.11/parcel-repo/ | grep parcel如果返回的列表里有你的 parcel 文件名说明服务正常。4.3 在 CM 里完成 Parcel 的下载、分配和激活浏览器登录http://172.16.10.11:7180跟着向导走第一步输入主机名列表。这里把 node01 到 node05 一起填进去SSH 私钥用之前配好的端口默认 22登录用户填 root。向导走到集群安装页时先别急着继续点右上角的齿轮图标进Parcel 配置把远程 Parcel 存储库 URL改成http://172.16.10.11/parcel-repo/保存后回到 Parcel 页点检查新 Parcel几秒后就能看到CDH-5.7.0-1.cdh5.7.0.p0.45这一行状态是未分配。点下载CM 会通过 HTTP 从 node01 拉包然后向所有 agent 分发。这一步的时间取决于文件大小和网络CDH-5.7.0 的 parcel 大概 1.5G 到 2G千兆内网分发到五台机器我等过 8 分钟左右。有几点是要留意的第一所有机器的/opt/cloudera/parcels剩余空间要够至少留 3G。如果空间不够分配会卡在某个节点上界面上显示正在分配但进度条不动。第二agent 所在机器的/tmp空间也要够CM 分发时会先解压到临时目录。第三分发过程中不要手动去动/opt/cloudera/parcels下面的文件尤其是别去rm -rf一个看起来像残留的目录那可能是正在拷贝的目标。分配完成后状态变成已分配这时候才能点激活。激活的本质是把/opt/cloudera/parcels/CDH这个软链接指向具体版本目录。ls -l /opt/cloudera/parcels/ # CDH - CDH-5.7.0-1.cdh5.7.0.p0.45激活成功的标志是五台机器全部变成已激活。如果有一台卡在激活中直接去那台机器上看/var/log/cloudera-scm-agent/cloudera-scm-agent.log基本都是磁盘空间或者权限问题。4.4 角色分配与首次启动的参数调优Parcel 激活后向导会进入角色分配。小集群我一般选核心 Hadoop这个组合然后手动调整几个关键角色服务角色分布策略注意事项HDFSNameNode 放 node01/node02 做 HAJournalNode 必须三台且奇数YARNResourceManager 放 node01/node02与 NameNode 分开但可同机ZooKeepernode01、node03、node04千万不要和数据量最大的节点重合HiveMetastore 放 node05元数据库复用 CM 的 MySQLHue放 node01内存给到 4G 以上分配完角色进配置页调几个必调参数。HDFS 的dfs.datanode.data.dir要指到你规划的数据盘比如/data/dfs/dn不要用默认的/dfs/dn那个目录默认在系统盘上几千万小文件就能把根分区写满。YARN 的yarn.nodemanager.resource.memory-mb按物理内存的 70% 给32G 的机器给 22Gyarn.scheduler.maximum-allocation-mb给到 8G不然后面 Spark 提交大任务会报资源不足。HDFS 的dfs.datanode.max.transfer.threads建议从默认的 4096 提到 8192这在数据量大、并发读的时候差别明显。dfs.namenode.handler.count按20 * log2(节点数)估算五节点大概给 40 就够给太高反而增加 GC 压力。配置完成后点启动CM 会依次拉起所有服务。第一次启动会比较慢HDFS 要格式化 NameNode、YARN 要初始化状态存储五分钟左右属于正常。全部变绿之后跑一个hdfs dfsadmin -report看看 DataNode 是不是全部注册上来了容量是不是你规划的那个数。5. 踩坑实录那些能把人逼到凌晨的报错5.1 Parcel 一直卡在正在分配或者干脆不显示这是最高频的问题我总结下来四个原因。第一个是文件名被改过CM 识别不了去/var/www/html/parcel-repo下ls一遍确认名字完全是CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel这种格式。第二个是 HTTP 服务返回了目录列表但 CM 读不到 hash 文件。用curl http://172.16.10.11/parcel-repo/看返回的 HTML 里有没有你的文件名再用curl http://172.16.10.11/parcel-repo/CDH-5.7.0-1.cdh5.7.0.p0.45-el7.parcel.sha看内容是不是那个 40 位的串。第三个是 sha 校验失败。CM 的界面会明确显示哈希不匹配这时候不要急着重新分先sha1sum重新算一遍确认是本体的哈希。如果确实对不上那就是文件传输过程中损坏了重新拷一份。第四个是 agent 侧的磁盘空间不足。这种情况界面可能显示正在分配很久但实际是失败的去 agent 日志里搜No space left on device。我在一台机器上就遇到过/opt单独分了 20G之前装了点别的东西剩下不到 2Gparcel 解压到一半就挂了。心得我现在的做法是分发之前先在所有节点上跑一遍df -h /opt /tmp /var把空间不够的机器先处理掉比事后排查省三倍时间。5.2 主机识别不出来或者装到一半 Agent 心跳丢了主机识别不出来九成是 hosts 解析问题。在 CM Server 上执行for i in 01 02 03 04 05; do ping -c1 node$i; done如果某台不通检查 hosts 文件有没有写错 IP 或者主机名拼错。hostname -f返回的如果不是你在 hosts 里写的那个 FQDNCM 也会认为是另一台机器。这种情况一般是/etc/hostname和 hosts 不一致或者 hosts 里同一 IP 写了两个名字顺序不对。Agent 心跳丢失的原因更杂。常见的是 agent 进程挂了systemctl status cloudera-scm-agent看一下还有一种是 agent 的config.ini里server_host写的是 IP 但 server 端后来改了主机名两边对不上。我遇到过一次更诡异的agent 的心跳端口 7182 被一个残留的进程占着ss -tlnp | grep 7182一看是个不知道从哪来的服务杀掉重启 agent 就好了。还有一种情况agent 能连上但状态一直显示不良点进去看是时钟偏差超过阈值。CM 默认允许的偏差是 30 秒左右超过就报不健康。这种就去chronyc tracking看一下偏移量大的话强制同步一次chronyc makestep。5.3 元数据库连接失败与引导流程重来scm_prepare_database.sh报错的情况我遇到三类。一类是 MySQL 的bind-address绑了 127.0.0.1远程连不上改配置重启 MySQL 即可。二类是密码里有$、!这类字符在 shell 里被解释掉了用单引号包起来或者干脆换个密码。三类是 MySQL 8 的认证插件是caching_sha2_password老版本驱动连不上需要把用户改成mysql_native_password。ALTER USER scm% IDENTIFIED WITH mysql_native_password BY Scm_2024#pwd;如果是在 CM 安装向导里卡在数据库连接测试失败而且已经点过好几次重试这时候最好的做法是把/var/lib/cloudera-scm-server和/var/lib/cloudera-scm-agent里的状态清理干净重新走一遍。因为 CM 在某些步骤失败后会留下半初始化状态继续重试反而更容易出问题。清理的时候注意/var/lib/cloudera-scm-server里如果有db.properties那个文件是数据库配置删了整个向导就得从头填看情况保留。还有一次是 MySQL 的max_connections只有 151集群刚起来的时候一堆服务连接直接把连接数打满CM 界面上显示大量服务异常日志里全是Too many connections。把这个参数调到 500 之后重启 MySQL 和 CM 就好了。5.4 一张速查表覆盖大部分现场问题现象最可能的原因快速验证方式处理办法Parcel 列表为空文件名被改 / URL 写错curl目录列表恢复原始文件名检查 URL 末尾斜杠哈希不匹配文件传输损坏sha1sum对比 sha 文件重新拷贝 parcel分配卡住目标机空间不足df -h /opt清理空间或扩容激活失败目录权限不对ls -l /opt/cloudera/parcels改属主为 cloudera-scm主机列表缺机器hosts 解析失败ping、hostname -f统一 hosts 配置Agent 心跳丢失端口占用 / 配置错误ss -tlnp | grep 7182杀进程重启 agent服务启动失败元数据库连不上看 server 日志检查 MySQL 用户和密码NameNode 格式化失败目录已存在且非空ls /data/dfs/nn清空目录重启DataNode 未注册data.dir 路径不存在目标机ls该路径建目录并给 hdfs 权限6. 上线前后的验收与长期维护6.1 一份能直接交差的验收清单集群起来之后别急着交付我有一份固定的验收清单一条条过。第一hdfs dfsadmin -report看 DataNode 数量和总容量确认没有节点掉线、没有磁盘掉了配额。第二yarn node -list看 NodeManager 是否全部注册状态是不是 RUNNING。第三跑一个hdfs dfs -mkdir /tmp/test hdfs dfs -put /etc/hosts /tmp/test/再hdfs dfs -cat读出来验证读写链路通。第四用hive -e show databases;验证 Hive Metastore 能连上去。第五直接从 CM 界面看各个服务的健康检查黄色警告要逐个点开看原因很多是配置项未设置这种提示可以忽略但如果是连接超时就不能放过。第六在 Hue 里点一下查询编辑器跑个select 1验证 Hue 到 HiveServer2 的链路。还有一个容易被忽略的检查/opt/cloudera/parcels的软链接在两台 NameNode 上都指向同一个版本。做过 HA 切换测试的集群尤其要确认因为不同步的情况下切过去会直接找不到 Hadoop 命令。6.2 离线环境下的升级、备份和后续维护离线环境最难受的不是装是后面的升级。我目前的策略是每次升级前把整个/opt/cloudera/parcel-repo目录打包备份包括 manifest 和 sha 文件新版本的 parcel 拷进同一个目录在 CM 里重新检查新 Parcel会同时列出新旧两个版本分配并激活新的然后停服务、切换、重启。如果新版本有问题把软链接切回旧版本目录服务降级重启五分钟能回滚。这就是 Parcel 相对 RPM 最实在的好处。备份方面CM 的元数据库必须定期mysqldump我一般配一个每天凌晨的定时任务保留 14 天。这份备份丢了等于整个集群的配置、角色分配、用户权限全没了重建成本极高。mysqldump -u root -pxxx --single-transaction --databases scm amon rman \ /data/backup/cm_$(date %Y%m%d).sql--single-transaction这个参数必须有否则备份时会对表加锁CM 界面会短暂卡顿严重的时候会误报服务异常。我个人在实际操作中的体会是这套东西的技术难度其实不高难的是细节的密度。从 SELinux 到 THP从 hosts 到 sha 校验任何一个环节的疏忽都会让整个流程在中途停下来。我现在的习惯是把所有步骤写成一个带检查点的 shell 脚本每执行完一个大步骤就打印一行OK并记录当前时间出问题时看日志断点比凭记忆回想要靠谱得多。另外交付前那次全量验收一定要留记录截图或者导出一份报告后面出问题时责任边界清楚自己心里也踏实。