企业官网建设流程全解析

SELinux一定要设为disabled。很多部署失败的诡异权限问题，比如Agent没权限写临时文件、组件进程起不来，最终定位都是SELinux在捣乱。修改/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled，然后重启系统生效。如果你暂时不想重启，至少执行setenforce 0临时关掉，但一定要记得把配置文件改掉，否则重启后又回到 enforcing。

3.4 THP、swap与内核参数

透明大页（THP）是Linux内核的一个特性，初衷是提高内存管理效率，但大数据组件尤其是HBase、Kudu对THP非常敏感。THP开启会导致内存分配时的大页延迟，造成明显性能下降甚至进程卡顿。CDH官方和社区经验都是一致建议关闭。

用下面命令检查当前状态：

cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag

如果输出里有[always]或者[never]的位置不对，需要改成never。改法有两条路，一条是直接echo写入sysfs文件，但重启后失效；一条是写到/etc/rc.local里让系统启动时自动执行。我建议两条都做：临时生效用echo，永久生效写rc.local。

echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local echo 'echo never > /sys/kernel/mm/transparent_hugepage/defrag' >> /etc/rc.local chmod +x /etc/rc.d/rc.local

接下来是swap。很多大数据集群内存大，不爱用swap，但完全不配swap在某些极端情况下反而容易触发OOM。CDH官方更推荐的做法是把swappiness调低，而不是彻底关掉swap。过高的swappiness会让系统频繁把内存页换到swap，引发明显的性能抖动。建议把/etc/sysctl.conf里的vm.swappiness改成1，这样系统只在非常紧张的情况下才会使用swap。

如果你用的是CentOS 7，还有一个tuned服务要注意。tuned会定期应用性能模板，可能把手工调整的内核参数覆盖掉。建议直接关掉它，或者设置成throughput-performance模式再调参：

systemctl stop tuned systemctl disable tuned tuned-adm off

这步做完，顺手把系统服务组件一起确认：比如NetworkManager如果不是可控环境，尽量用network服务，不要默认网络配置反复跳变。

4. JDK和基础依赖：装得不对后面CM起不来

CDH5.14.0整体是跑在Java生态上的，JDK的环境配置直接决定了管理端和各个组件能否启动。我在实战里见过太多JDK相关报错，所以这一节值得单独拉出来讲。

4.1 JDK版本选择

CDH5.14.0要求Java 1.8，也就是我们常说的JDK 8。这个版本虽然老，但在CDH5.x时代是官方认证的标准。有两种选择：Oracle JDK和OpenJDK。官方文档主要针对Oracle JDK做验证，但我实际使用中发现OpenJDK在多数场景下也能正常跑，只是个别组件的SSL或者安全模块会有细微差异。生产环境求稳的话，优先选择Oracle JDK 1.8。

版本号方面，最低也要8u162以上，太老的JDK 8会有不少已发现的问题，特别是JVM参数支持和加密算法上。如果你用的是更新的JDK 11或者JDK 17，这里要明确告诉你，不要在这套环境里尝试。CDH5.14.0发布时的Java版本就是JDK8，硬上高版本只会得到一堆莫名其妙的异常。

4.2 安装JDK并设置JAVA_HOME

每台节点都要装JDK，不只Master。别只给CM Server装一个就完事。操作步骤并不复杂，但我建议使用rpm包安装，这样会统一把java命令放到/usr/bin下面，JDK本身安装到/usr/java目录。

安装前，先确认系统里有没有自带的OpenJDK，如果有就先卸载，避免环境变量和java命令冲突。

yum remove -y java-1.7.0-openjdk java-1.8.0-openjdk rpm -ivh jdk-8u162-linux-x64.rpm

安装完成后，配置环境变量。CDH的一些脚本默认会去/usr/java目录找JDK，所以这里有一个潜规则：尽量保持默认安装路径，不要自作主张把JDK放到/opt或者别的目录，否则后续组件启动时经常出现找不到JAVA_HOME的问题。

cat >> /etc/profile <<'EOF' export JAVA_HOME=/usr/java/jdk1.8.0_162 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF source /etc/profile java -version

确认java -version输出的是jdk1.8.0_162，而不是系统自带的旧版本。这里有个小坑：如果你只是配置了/etc/profile，但没有让ssh会话重新登录，当前终端可能还是旧的PATH。做环境准备时建议每台节点都重新ssh登录一次，再验证java命令。

4.3 基础工具与系统依赖补齐

CDH的安装过程会用到不少系统命令，比如unzip、tar、wget、ntpdate、lsof、psmisc这些。如果系统是最小化安装，缺的东西可能比较多。建议在配置环境阶段一次性装齐：

yum install -y ntp wget vim unzip tar sysstat lsof psmisc bind-utils openssh-clients

如果你所在的机房是离线环境，没有外网yum源，那这些基础包需要提前下载好，制作成本地yum仓库。别等到CM安装到一半才想到缺依赖，那时候再去配本地源会非常被动。

另外，还要确认Python环境。CDH5.x的管理流程对Python有依赖，CentOS 7自带的Python 2.7可以直接满足，但千万别手闲把系统Python升级到3.x，很多依赖Python 2的老脚本会直接挂掉。我见过有人为了跑某个工具把系统默认python改成软链，结果CM安装时崩溃得一塌糊涂。

5. SSH免密登录：一张密钥解决全集群分发

CDH的自动化部署依赖管理端能免密登录到各个节点，这也是环境准备阶段一个容易被忽略但极其重要的环节。

5.1 为什么需要免密登录

CM Server在添加主机时，需要向目标节点上传agent安装包、parcel文件，并执行远程脚本。这些操作全部要通过SSH完成。如果你没有配置免密，每一次操作都会卡在密码输入上，自动化流程直接中断。所以，必须在CM Server所在节点配置对集群内其他所有节点的免密登录。

Elaborate here：在实际场景中，我一般直接用root账号做免密。虽然从安全角度来说root免密不太好看，但CDH部署阶段涉及大量的服务启停、目录创建和文件复制，用普通账号要频繁sudo，反而会把部署过程搞得极其繁琐。如果你有安全审计要求，可以在部署完成后改成更严格的权限控制。

5.2 密钥生成与分发步骤

生成密钥在CM Server节点执行。生成时建议指定rsa类型，4096位：

ssh-keygen -t rsa -b 4096 -N ""

-N ""表示不设置passphrase。如果你设置了passphrase，会在使用时要求输入，自动化部署就卡住了。

密钥生成后，公钥在/root/.ssh/id_rsa.pub，私钥在/root/.ssh/id_rsa。接下来把公钥分发到每个节点。可以用ssh-copy-id，也可以手动追加。ssh-copy-id更简单：

ssh-copy-id -i /root/.ssh/id_rsa.pub management ssh-copy-id -i /root/.ssh/id_rsa.pub master-1 ssh-copy-id -i /root/.ssh/id_rsa.pub master-2 ssh-copy-id -i /root/.ssh/id_rsa.pub>echo "StrictHostKeyChecking no" >> /etc/ssh/ssh_config

第四，分发完成后，逐台手动ssh一下，确认不需要密码。不要只抽查一台，也别直接开始装集群，我发现有些节点因为网络问题或key顺序问题会安静地失败。

6. NTP时间同步：集群稳定运行的生命线

时间同步在大数据集群里属于“看着不重要，出事就要命”的配置。很多人装完CDH后，发现DataNode心跳断断续续，Zookeeper连接老断开，查了半天才发现节点时间差了十几秒。

6.1 时间不同步的后果

HDFS的NameNode会把DataNode的block报告和心跳信息打上时间戳，如果DataNode时间和NameNode时间偏差过大，NameNode会判断该DataNode已经失联，开始进入副本复制流程，造成大量不必要的网络IO。Zookeeper严格依赖时间顺序来维持事务ID的递增，时间乱跳会导致会话失效、Leader选举异常。如果集群还接了Kerberos认证，时间偏移超过5分钟直接拿不到票据。

最要命的是，时间同步问题通常不是突然爆发的，而是慢慢积累到一定程度才触发阈值。到那时候你已经很难回头定位是哪一天开始漂移的。所以，NTP必须在所有节点上从一开始就配置好。

6.2 配置NTP的具体步骤

先安装NTP服务：

yum install -y ntp

然后确定时间源。有两种常见方案：一是全部节点连接外网NTP服务器，适合能访问外网的环境；二是在内网没有NTP服务的情况下，选一台Master节点做时间服务器，其他节点指向它。

如果是外网NTP，编辑/etc/ntp.conf，把server行指向公共NTP或公司内网的时间源。如果是内网独立集群，Master节点的ntp.conf可以保持指向外网或配置为一台权威源，而其他节点配置为指向Master节点：

# Master节点的 /etc/ntp.conf server ntp1.aliyun.com iburst server ntp2.aliyun.com iburst # Worker和其他节点的 /etc/ntp.conf server master-1 iburst

配置完后，先做一次立即同步，避免一直等ntpd慢慢收敛。如果你的节点时间差了好几个小时，直接启动ntpd可能会因拒绝步进而不愿意同步，所以先用ntpdate手动校准一次：

systemctl stop ntpd ntpdate -u master-1 systemctl start ntpd systemctl enable ntpd

再顺手把硬件时钟也设成UTC对齐，防止下次重启后系统时间又被硬件时钟带偏：

hwclock --systohc

6.3 时间校准后的验证

配置完成不等于工作完成，NTP这种服务要持续观察。用ntpq -p查看同步状态：

ntpq -p

重点看remote列是否有时间源的地址，以及offset列的值。offset越小越好，超过50ms就要警惕了。稳定运行一段时间后，如果offset持续增长，说明NTP服务可能没有正常工作，或者网络有严重延迟。

另外，Cloudera Manager本身也有时间检查项。如果部署时CM页面报“时钟偏移过大”类似的警告，基本可以断定NTP配置有问题。我建议你把ntp配置放到环境准备检查清单里，部署前统一跑一遍，而不是等CM检查弹警告。

7. 文件句柄与内核参数：顺手设置的隐藏关卡

如果说前面几节是明面上的坑，那这一节设置的参数就属于“默认值也能跑但迟早出问题”的类型。CDH部署完以后，系统里会同时运行很多Java进程，每个进程都要占用文件句柄和线程资源。默认的1024或4096限制根本扛不住。

7.1 limits.conf 合理值

/etc/security/limits.conf是用来配置用户资源限制的地方。CDH官方建议把文件句柄和进程数同时调大。这里不要只设置root或者hdfs用户，建议用*通配，让所有用户都继承这个限制。

cat >> /etc/security/limits.conf <<'EOF' * soft nofile 32768 * hard nofile 32768 * soft nproc 65536 * hard nproc 65536 EOF

nofile是文件句柄数，nproc是进程数上限。这两个值设置后，默认情况下当前终端不会立刻生效，需要重新登录或重启。检查是否生效：

ulimit -n ulimit -u

如果你设置完发现ulimit -n还是1024，说明可能被/etc/security/limits.d/*.conf里的配置覆盖了。CentOS系统里通常会有一份90-nproc.conf或者其他文件，注意把冲突项一起改掉。

还有一个容易踩的坑：在Linux下，limits.conf对通过systemd启动的服务不生效。CDH的agent进程如果是通过systemd管理的，可能需要额外配置。不过我实际部署中，CDH的agent是通过SysV风格脚本启动的，所以limits.conf能正常接管。如果你发现调了limits但agent进程仍显示老限制，可以用systemctl edit给对应服务单独加LimitNOFILE。

7.2 sysctl.conf 关键项

内核参数调优是另一块。CDH集群中比较关键的几个参数如下：

cat >> /etc/sysctl.conf <<'EOF' vm.swappiness = 1 vm.max_map_count = 262144 net.core.somaxconn = 2048 EOF sysctl -p

vm.swappiness刚才讲过，控制在1左右即可。vm.max_map_count主要影响Java进程能创建的内存映射区域数量，默认值65530在某些场景下不够用，容易出现“Too many open files”或mmap失败。我把它调到262144是一个比较常见且稳妥的值。

net.core.somaxconn影响TCP连接队列长度，高并发环境下适当调高一些，能缓解组件之间连接堆积的问题。

另外还有一些参数比如vm.overcommit_memory，有些人喜欢设为1来保证HBase的大内存分配不失败，但我建议保持默认值，因为overcommit模式并不适合所有业务。不同组件会向内核申请内存，overcommit反响很难说。除非你遇到了明显的内存分配问题再针对调。

7.3 让参数永久生效

永久生效靠两个地方：sysctl.conf和rc.local。sysctl.conf由sysctl -p加载，重启后系统自动加载，没问题。rc.local则需要确认有执行权限。CentOS 7默认/ect/rc.d/rc.local可能没有可执行权限，记得：

chmod +x /etc/rc.d/rc.local

这样里面写的THP关闭命令才会在开机时执行。

在生产环境里，我建议把这些参数收敛到一个初始化配置脚本里，在所有节点统一跑一遍。比手动一台台敲命令可靠得多，也不容易漏配置。后面我会给大家留一个自检脚本，可以直接复制用。

8. 一套顺手的环境自检脚本与常见坑排查

环境准备做得怎么样，不能靠“我觉得没问题”，必须有一份可以机械执行的检查清单。这里我分享一个自检脚本和一张排查表。

8.1 环境自检脚本

这个脚本设计成在每台节点上单独执行，把前面讲过的检查项全部扫一遍，输出关键状态。因为是自检用，不追求复杂，关键是直观。

#!/bin/bash echo "===== 1. 主机名 =====" hostname echo "===== 2. hosts解析 =====" ping -c1 -W1 "$(hostname)" >/dev/null 2>&1 && echo "hostname解析OK" || echo "hostname解析失败" echo "===== 3. SELinux状态 =====" getenforce echo "===== 4. 防火墙状态 =====" systemctl is-active firewalld 2>/dev/null || echo "firewalld未运行" systemctl is-active iptables 2>/dev/null || echo "iptables未运行" echo "===== 5. 透明大页THP =====" cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag echo "===== 6. swappiness =====" sysctl vm.swappiness echo "===== 7. 文件句柄与进程数限制 =====" ulimit -n ulimit -u echo "===== 8. JDK版本 =====" java -version 2>&1 | head -1 echo "JAVA_HOME=$JAVA_HOME" echo "===== 9. NTP同步状态 =====" ntpq -p 2>/dev/null | head -10 || echo "ntpq不可用" echo "===== 10. 磁盘挂载 =====" df -h | grep -E "^/dev|Filesystem"

检查时重点关注几个输出：SELinux显示Disabled，THP的enabled和defrag都显示[never]，swappiness是1，ulimit -n不小于32768，NTP有输出并且offset不大。

如果你自己有批量操作工具，可以把脚本分发到所有节点循环执行，把输出统一收集起来看，效率高很多。

8.2 常见报错和排查对照表

下面的表格是我在实际部署和帮人排查时遇到最多的几类问题，直接对照排查可以省掉很多时间。

8.3 下一步之前必须完成的最后确认

环境检查做完后，我还有一个习惯：把所有节点的IP、主机名、角色、数据盘挂载点、JDK路径全部整理成一张表，放在安装文档首页。看似多花十分钟，但等真正操作CM界面的时候，你会发现不用来回翻各种记录。

这套环境准备做完，下一步就可以开始下载安装包、初始化数据库、启动管理端服务了。我个人在实际操作中的体会是：环境准备这步，做得越细，后面CM界面里的操作就越轻松。真正安装CDH5.14.0的图形化过程反而没什么好讲的，最多就是下一屏、选版本、选服务、点继续。真正区分一次部署流程是顺利还是灾难的，就是今天这篇里讲的这些前置工作。