企业官网建设流程全解析

手上这批机器没有外网，机房只开了 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 提供了两种软件分发方式：Package（RPM/deb）和 Parcel。很多人觉得区别只是"装法不同"，实际差别挺大，我列个表对照一下。

我在一个客户的测试集群上就吃过 RPM 的亏：系统里已经装了某个版本的 snappy，yum install的时候依赖解析把系统自带的库给顶掉了，结果机器上另一个业务程序直接起不来。Parcel 因为整套运行时都放在自己的目录里，走的是自己的LD_LIBRARY_PATH，不存在这个问题。

所以现在的惯例是：只要不是极老的环境或者有特殊合规要求，一律用 Parcel。这篇文章后面所有步骤也都基于 Parcel 展开。

1.3 机器和角色规划：第一台机器选错，后面全得重来

我先给一套五节点的规划，实际你可以按数据量缩到三台，但建议不要少于三台，因为 HDFS 默认三副本，少于三台连副本都摆不开。

这里有几个我踩过的坑值得提前说。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_HOME，PATH里也得把$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/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

SELinux 这里特别提醒一句：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 65000

sysctl --system # 关闭 THP echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag

THP 关闭要写进/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 EOF

2.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 root@172.16.10.$ip done

最后做一次批量验证，确保每台机器的 hostname、JDK 版本、时间都对齐了。

for ip in 11 12 13 14 15; do echo "=== 172.16.10.$ip ===" ssh root@172.16.10.$ip "hostname -f; java -version 2>&1 | 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] name=Cloudera Manager 5.7 Local baseurl=http://172.16.10.11/cm5.7/ enabled=1 gpgcheck=0

gpgcheck=0在内网自建源里问题不大，但如果客户有安全审计，你还需要把 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-COMMITTED

transaction-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 和 daemons：

yum install -y cloudera-manager-daemons cloudera-manager-server

其余节点装 agent：

yum 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_host=node01 server_port=7182

然后所有节点（含 node01）启动 agent，node01 再启动 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 内容（比如<html><head>...），说明你下载的方式不对，拿到的其实是某个登录页面或者 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"这个组合，然后手动调整几个关键角色：

分配完角色，进"配置"页调几个必调参数。HDFS 的dfs.datanode.data.dir要指到你规划的数据盘，比如/data/dfs/dn，不要用默认的/dfs/dn，那个目录默认在系统盘上，几千万小文件就能把根分区写满。YARN 的yarn.nodemanager.resource.memory-mb按物理内存的 70% 给，32G 的机器给 22G，yarn.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，之前装了点别的东西，剩下不到 2G，parcel 解压到一半就挂了。

心得：我现在的做法是，分发之前先在所有节点上跑一遍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 里写的那个 FQDN，CM 也会认为是另一台机器。这种情况一般是/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 一张速查表，覆盖大部分现场问题

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 -p'xxx' --single-transaction --databases scm amon rman \ > /data/backup/cm_$(date +%Y%m%d).sql

--single-transaction这个参数必须有，否则备份时会对表加锁，CM 界面会短暂卡顿，严重的时候会误报服务异常。

我个人在实际操作中的体会是，这套东西的技术难度其实不高，难的是细节的密度。从 SELinux 到 THP，从 hosts 到 sha 校验，任何一个环节的疏忽都会让整个流程在中途停下来。我现在的习惯是把所有步骤写成一个带检查点的 shell 脚本，每执行完一个大步骤就打印一行"OK"并记录当前时间，出问题时看日志断点，比凭记忆回想要靠谱得多。另外，交付前那次全量验收一定要留记录，截图或者导出一份报告，后面出问题时责任边界清楚，自己心里也踏实。