CDH6.3.2离线安装避坑实录从环境配置到CM启动的深度排雷指南当你在内网环境中第一次尝试部署CDH集群时可能会天真地认为只要按照官方文档一步步操作就能顺利完成。但现实往往会给你当头一棒——那些在标准教程里轻描淡写的步骤在实际操作中可能变成一个个深不见底的坑。本文将分享我在三个不同客户环境中部署CDH6.3.2时遇到的真实故障案例以及从这些血泪教训中总结出的避坑方法论。1. 环境准备阶段的隐形陷阱1.1 系统配置的魔鬼细节大多数教程都会告诉你关闭防火墙和SELinux但很少有人会强调这些操作必须在特定顺序下完成。我曾遇到一个案例管理员在安装完成后才禁用SELinux导致CM Agent无法正常注册。正确的操作序列应该是# 正确的操作顺序所有节点 setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config systemctl stop firewalld systemctl disable firewalld注意修改SELinux配置后必须重启服务器才能完全生效这是90%安装失败的根本原因透明大页(THP)问题看似简单实则暗藏杀机。仅仅执行echo never /sys/kernel/mm/transparent_hugepage/enabled是不够的因为重启后配置会丢失。必须将其写入启动脚本cat EOF /etc/rc.local echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag EOF chmod x /etc/rc.local1.2 时间同步的连环坑NTP服务配置不当会导致各种灵异问题特别是在Kerberos认证环境中。除了常规的ntp.conf配置外还需要检查chrony服务是否彻底禁用与ntpd冲突BIOS时间是否与系统时间一致执行hwclock --systohc同步各节点时区是否统一timedatectl set-timezone Asia/Shanghai我曾花费两天时间追踪一个随机性的Zookeeper故障最终发现是因为某个节点的时间比主节点快了15分钟。2. 本地Yum源搭建的常见陷阱2.1 路径权限的隐藏问题当使用Apache HTTP服务提供本地仓库时很多人会忽略SELinux上下文问题。即使关闭了SELinux残留的上下文标签仍可能导致403错误。正确的解决方法是# 修复目录上下文假设仓库放在/var/www/html/cdh semanage fcontext -a -t httpd_sys_content_t /var/www/html/cdh(/.*)? restorecon -Rv /var/www/html/cdh2.2 仓库元数据创建的注意事项使用createrepo命令时90%的教程不会告诉你需要添加-update参数来增量更新。当需要添加新的RPM包时createrepo --update /var/www/html/cdh致命陷阱如果在仓库中同时存放了不同架构的包如x86_64和noarch必须确保主仓库目录结构正确/var/www/html/cdh/ ├── RPMS │ ├── x86_64 │ └── noarch └── repodata3. 数据库初始化的那些坑3.1 字符集与排序规则陷阱虽然官方文档说utf8字符集足够但在实际使用中会遇到各种奇怪问题。更安全的做法是使用utf8mb4CREATE DATABASE scm DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;3.2 连接数限制引发的血案CM Server启动时会建立大量数据库连接默认的MySQL配置可能导致连接耗尽。必须调整# /etc/my.cnf [mysqld] max_connections500 wait_timeout288004. CM服务启动的疑难杂症4.1 内存不足的假象当看到Java heap space错误时不要急着增加内存。首先检查/var/log/cloudera-scm-server/cloudera-scm-server.log中的真实错误是否误用了32位JDK必须使用64位ulimit设置是否合理建议ulimit -n 655364.2 端口冲突的隐蔽表现7180端口被占用是最常见的问题但有时表现很隐蔽。诊断方法# 检查端口占用 netstat -tulnp | grep 7180 # 如果被其他进程占用可以修改CM端口 vi /etc/cloudera-scm-server/cm.properties # 添加 server_port71814.3 最棘手的Parcel分发问题当Parcel分发卡在70%时通常是因为网络MTU设置不一致所有节点应统一为1500磁盘空间不足需要至少2倍Parcel大小的空间反向DNS解析失败确保所有节点能正确解析彼此主机名诊断命令# 检查网络MTU ip link show | grep mtu # 检查磁盘空间 df -h /opt/cloudera/parcels5. 那些官方文档没告诉你的经验5.1 安装后的必要检查清单所有节点的/etc/cloudera-scm-agent/config.ini中的server_host是否指向正确的主节点检查/tmp目录权限需要1777权限验证各节点的IPC信号量设置# 检查当前值 ipcs -l # 永久修改 echo kernel.sem 250 32000 100 500 /etc/sysctl.conf sysctl -p5.2 性能调优的黄金参数在/etc/default/cloudera-scm-server中添加export CMF_JAVA_OPTS-XX:UseConcMarkSweepGC -XX:CMSParallelRemarkEnabled -XX:UseParNewGC -XX:UseNUMA -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/var/log/cloudera-scm-server对于Agent节点在/etc/default/cloudera-scm-agent中添加export CMF_AGENT_JAVA_OPTS-XX:UseConcMarkSweepGC -XX:UseParNewGC -XX:UseNUMA -XX:HeapDumpOnOutOfMemoryError6. 当一切都不奏效时如果经过上述所有检查仍然无法解决问题最后的救命稻草是重置CM环境# 停止所有服务 systemctl stop cloudera-scm-server systemctl stop cloudera-scm-agent # 清理数据库危险操作 mysql -uroot -p -e DROP DATABASE scm; CREATE DATABASE scm DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci; # 重新初始化 /opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm 密码 # 删除Parcel缓存 rm -rf /opt/cloudera/parcel-cache/* rm -rf /opt/cloudera/parcels/* # 重新启动 systemctl start cloudera-scm-server记住在离线环境中安装CDH就像在雷区中行走每个步骤都可能隐藏着意想不到的问题。保持耐心仔细阅读日志最重要的是——做好每一步的备份。