前阵子有个朋友从外地打电话过来说单位新采购了一批复原服务器出厂预装的全是 alinux3可集团上层的数仓平台又指定要用 CDH 6.3.2。他在网上搜了一圈发现 CDH 6.3.2 的官方支持列表里只写了 RHEL 7 和 CentOS 7当场心态就炸了。第一天尝试直接装 Cloudera ManagerAgent 都装不上第二天好不容易把 CM Server 拉起来Parcel 下载校验又报错第三天他差点准备把所有机器重装成 CentOS 7。其实这两年国产化操作系统替换和 CentOS 8 过渡叠加在一起很多人都在 CentOS 8、alinux3 或者其他基于 EL8 的兼容发行版上装 CDH 6.3.2。我前后在好几套环境里把这条链路完整踩了一遍适配方案基本稳定了这里面的操作有不少是官方文档里找不到的今天整理出来给需要的人省点时间。1. 为什么在 CentOS 8 上装 CDH 6.3.2 会这么费劲1.1 官方兼容矩阵与真实需求的冲突先说结论CDH 6.3.2 不是完全装不上 CentOS 8而是 Cloudera 的整套安装链路——从 Cloudera Manager Server、CM Agent 到 Parcel 激活——都默认你跑在 EL7 上。它内部有一堆脚本会去读操作系统版本号、检查 python 解释器、找特定版本的动态库一旦某个环节不在它预期内就直接给你一个让人摸不着头脑的报错。官方支持矩阵里CDH 6.3.2 对应的是 RHEL 7 / CentOS 7 系的 7.6、7.7数据库支持 MySQL 5.7、PostgreSQL 等。这套东西发布的时间点CentOS 8 都还没有完全铺开Cloudera 自然没有义务为它做适配。但现实里大家遇到 CentOS 8 / alinux3 无非三种情况企业新购服务器预装了 alinux3为了过等保或者集团统一基线不让你重装系统业务侧强制推进国产化操作系统替代CentOS 7 到期之后必须迁到 EL8 系单纯的测试环境手头只有 CentOS 8 镜像不想再折腾 CentOS 7。所以我们需要做的工作其实并不是让 CDH 支持 CentOS 8而是让 CDH 的安装链路自认为跑在 CentOS 7 上同时把 EL8 系统里缺失的运行时依赖补齐。这是个很微妙的思路后面所有操作都是围绕它展开的。1.2 alinux3 和 CentOS 8 到底差在哪alinux3 全称是阿里云 Linux 3底层基于 EL8跟 CentOS 8 在用户态上高度一致绝大多数 rpm 包可以直接互用。它甚至自带阿里云的 yum 源内网环境如果开了专线访问 OSS 源装基础依赖比原版 CentOS 8 还方便。但有几个 EL8 系的通病需要留意默认 python 指向 python3而 CM Agent 和 CDH 的很多脚本还依赖 python2.7默认没有安装 libnsl、ncurses-compat-libs 这类老库CDH 里 Impala、Kudu 等组件启动时可能直接报找不到 libnsl.so.1系统自带的 openssl、glibc 版本比 EL7 新部分在 CentOS 7 上编译好的二进制动态库依赖会不满足默认 firewalld 是随开机启动的SELinux 也是 Enforcing这两样不关CM Agent 和 HDFS 角色很容易出现权限和端口问题。我后面在文里把这些坑一个个填掉。你只要记住凡是基于 EL8 重新构建的发行版大体都可以参考同一套适配方法只是个别包的名字或源位置略有差异。2. 装系统阶段就该打好的地基2.1 分区、主机名与初始化的三个建议很多人在装系统的时候不重视规划等 CDH 部署到一半才发现磁盘不够、主机名带下划线、swap 分区过大最后哭着收场。我建议从源头就按生产标准来数据盘独立HDFS 数据目录、Zookeeper 数据目录、MySQL 数据目录至少各自挂一块独立磁盘。用df -h检查挂载点不要一股脑全扔在根分区。CDH 的 HDFS 数据目录默认是/dfs/nn、/dfs/dn如果你根分区只有 50G一个 10 节点集群跑两天就把盘打满了。主机名规范主机名不要出现下划线不要以数字开头大小写尽量统一。CDH 的 Host Inspector 对主机名解析很敏感尤其要注意/etc/hosts里必须把本机 IP 和 hostname、FQDN 全部对应上。我见过最多的问题就是/etc/hosts写成了127.0.0.1 localhost.localdomain localhost然后 CM 在启动角色时按主机名找 IP结果所有 agent 都注册到期 backup 节点上。swap 分区如果内存超过 64Gswap 可以设小一点如果内存不大swap 设置成内存一半即可。vm.swappiness后面会调低但如果 swap 本身就是个几 GB 的大分区调了也能帮你兜底内存突发压力。2.2 网络配置分歧NetworkManager 与静态 IPCentOS 8 和 alinux3 默认都用 NetworkManager 管理网络这和 CentOS 7 时代大家习惯用的 network.service 差别很大。CDH 本身不依赖网络管理工具但它要求所有节点静态 IP、主机名可解析所以网络配置必须稳定。使用 NetworkManager 配置静态 IP 的方式很简单nmcli connection modify ens3 ipv4.addresses 192.168.10.11/24 nmcli connection modify ens3 ipv4.gateway 192.168.10.1 nmcli connection modify ens3 ipv4.dns 192.168.10.1 nmcli connection modify ens3 ipv4.method manual nmcli connection up ens3配置完之后用ip addr确认地址生效。这里有个常见的坑如果你先配置好 IP再修改 hostnameNetworkManager 可能会因为主机名变化把连接反复重建所以建议顺序是——先hostnamectl set-hostname cdh01.example.com再配置网络最后把所有节点的/etc/hosts写好再做一次systemctl restart NetworkManager。另外如果你确实更习惯老的 network-scripts在 EL8 上需要额外安装dnf install network-scripts但我不太推荐在生产上这么干因为 EL8 后续版本对 network-scripts 的支持已经降到极低优先级保持 NetworkManager 是更省心的选择。2.3 内核参数、防火墙、SELinux 与小工具依赖安装 CDH 之前每个节点上都要做几件事不然后面排查起来会非常痛苦。关闭防火墙和 SELinuxsystemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/config内核参数调整编辑/etc/sysctl.conf追加以下内容vm.swappiness1 vm.overcommit_memory1 net.ipv4.ip_forward1 net.core.rmem_max16777216 net.core.wmem_max16777216执行sysctl -p让配置生效。其中vm.swappiness调低是避免系统频繁使用 swap影响 HDFS 和 Impala 的读写性能vm.overcommit_memory1是 Impala 官方文档明确要求的它让 Impala 在做内存分配判断时不至于因为系统内存几何级估算而拒绝启动。关闭透明大页 THP这是大内存集群最容易忽略的性能杀手echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag为了重启后依然生效把它写进/etc/rc.local并给 rc.local 加执行权限。基础工具包装 CDH 前建议把常用依赖一次性补齐dnf install -y psmisc perl openldap-clients dmidecode bc unzip tar wget curl \ libxslt lzo python2 libnsl ncurses-compat-libs这里重点提一下python2和libnsl它们不是可选依赖是 CentOS 8 / alinux3 上装 CDH 必装的兼容层。此外如果你发现系统里缺了某个动态库可以用ldconfig -p | grep 库名去查再去阿里云源搜包省去反复试错的功夫。顺带说一句如果你在 EL8 上开了图形界面又一直在被远程桌面自动注销折磨最简单的办法是生产集群直接不装图形界面或者把默认启动级别改到 multi-user.targetsystemctl set-default multi-user.target我是不建议在集群节点上留 GUI 的纯属给自己增加维护负担。3. 骗过 Cloudera Manager操作系统识别适配3.1 改 redhat-release 只是第一步Cloudera Manager 从 Server 到 Agent 再到 Parcel 激活都会读取/etc/redhat-release来做操作系统类型识别。所以第一个要动的就是它。备份原文件再修改cp /etc/redhat-release /etc/redhat-release.bak echo CentOS Linux release 7.9.2009 (Core) /etc/redhat-release注意不是只改 CM Server 那一台是所有参与集群的节点都要改。因为 CM Agent 上报操作系统类型给 ServerParcel 分发到每台 agent 节点时agent 本地也要通过校验。改完之后有些系统工具如yum、dnf可能会读取这个文件做仓库判断实际上影响不大因为 yum/dnf 更多依赖/etc/os-release。如果你的发行版还有自己的/etc/os-release不用动它CM 基本不认这个文件。有个容易被忽略的细节当你在 CM 界面上做 Add Hosts 向导时CM 会尝试用 SSH 连到每台新主机来装 Agent这一步如果它检测到系统版本异常可能在向导阶段就中断。所以不等向导报错你在操作系统层面就把版本伪装好后面会顺很多。3.2 python2 兼容层是如何救命的CDH 6.3.2 发布时Ansible、Cloudera Manager 脚本和部分组件进程管理脚本默认走/usr/bin/python而且往往用的是 Python 2 语法。CentOS 8 / alinux3 的默认 python 指向 python3在安装过程中你会看到各种诡异的报错比如cloudera-scm-agent启动后立刻退出日志里写ImportError: No module named cm_client或SyntaxErrorParcel 解压后激活失败提示UnicodeDecodeErroryum插件被某个脚本调用时出现 Python 运行时错误。解决办法是显式安装 python2并把/usr/bin/python软链到 python2dnf install -y python2 ln -sf /usr/bin/python2 /usr/bin/python python --version执行到最后一步你应该看到输出Python 2.7.x。这个改动对整个系统的影响可以说非常小因为 EL8 上很多运维脚本已经改成显式调用python3了不会有路径冲突。但 CM 的脚本是千年不变的/usr/bin/python所以有这个软链它才能跑起来。如果你只想治标不治本也可以去改 CM 脚本头部改解释器路径但几十个脚本分布在/opt/cloudera/下面一个个改不仅累还容易在下次升级时被覆盖。我觉得用软链是性价比最高的方案。3.3 离线环境下的 RPM 依赖收集与 openssh 自定义打包经验有些政企内网环境所有机器都不能访问公网。这种时候「在线 yum 安装」就是奢望只能在能联网的跳板机上把依赖包全部倒腾下来再拷贝进去。这里分享一个流程照着做基本不会漏包。方法一dnf download收集指定依赖dnf install -y dnf-plugins-core dnf download cloudera-manager-server-6.3.2-1468238.el7.x86_64.rpm \ cloudera-manager-agent-6.3.2-1468238.el7.x86_64.rpm \ --resolve --alldeps --destdir/data/rpm_packages--resolve会把依赖全部拉下来这个命令需要在联网的 CentOS 8 / alinux3 环境执行然后把整个/data/rpm_packages目录打包传到内网。方法二先用rpm -qpR查依赖再逐个下载rpm -qpR cloudera-manager-agent-6.3.2-*.rpm拿到依赖列表后去在线仓库逐个下载。这个方法适合你只缺一两个包的时候效率很高。另外专门说一下 OpenSSH 打包 rpm 的事。很多内网安全基线要求 OpenSSH 升级到特定版本比如修复 CVE 的版本但 EL8 基础源里的 openssh 版本不满足要求。这时需要自行用 rpmbuild 重打包dnf install -y rpm-build openssl-devel zlib-devel gcc mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} tar xf openssh-9.6p1.tar.gz -C ~/rpmbuild/SOURCES/编辑 openssh.spec 时重点检查%configure那段加上--with-openssl路径选项再执行rpmbuild -ba openssh.spec。生成的新 rpm 会放在~/rpmbuild/RPMS/x86_64/下。这里有个容易踩的坑如果你在 CentOS 7 上打了这个包拿到 CentOS 8 / alinux3 上装很容易出现 glibc 版本兼容问题所以建议在哪套系统上生产就在哪套系统上构建。4. 数据库层选 MySQL 8.0 还是 5.74.1 CDH 6.3.2 对数据库的隐性要求CDH 6.3.2 默认自带一个嵌入式的 PostgreSQL用于 CM Server 的元数据存储。可一旦你要上生产我强烈建议把数据库外置。原因有两点CM 自带的 PostgreSQL 只有单机模式没有备份和主从方案挂了一次整个管理面就全凉业务上通常已经有统一的 MySQL 运维规范接入现有 MySQL 体系比另维护一套 PG 更省事。CDH 6.3.2 在官方文档里对 MySQL 的支持主要针对 5.7但实际生产里我用 MySQL 8.0 跑通了好几次关键点在于解决认证插件和 JDBC 驱动问题。如果你所在团队有条件选优先用 MySQL 5.7因为 CM 对它的兼容性是开箱即用的如果由于集团数据库规范强制 MySQL 8.0那就参考我下面的适配方案。4.2 MySQL 8.0 认证插件与 JDBC 驱动的适配方案MySQL 8.0 默认的认证插件是caching_sha2_password而 CDH 内部很多组件进程——Hive Metastore、Cloudera Manager Server、Hue、Ranger——走 JDBC 连接数据库时如果使用旧版驱动特别是 mysql-connector-java 5.1.x就会报Unable to load authentication plugin caching_sha2_password。解决办法有两个方向方向一让 MySQL 兼容旧认证方式在/etc/my.cnf的[mysqld]段加上default_authentication_pluginmysql_native_password或者在创建用户时显式指定CREATE USER scm% IDENTIFIED WITH mysql_native_password BY your_password;这样即使驱动比较旧也能正常认证。方向二升级 JDBC 驱动下载 mysql-connector-java 8.0.x 版本放到所有需要连接 MySQL 的节点上。我建议把 jar 包统一放到两个位置/usr/share/java/mysql-connector-java.jar /opt/cloudera/cm/lib/mysql/mysql-connector-java.jar其中/usr/share/java/mysql-connector-java.jar是 CM 的引导脚本会主动扫描的路径如果你不放在这里后面执行scm_prepare_database.sh时它会提示找不到驱动。权限方面记得是cloudera-scm用户可读最好把属主直接改成cloudera-scm:cloudera-scm。使用 MySQL 8.0 新版驱动时JDBC URL 里要注意两个参数jdbc:mysql://cdh01:3306/hive?useSSLfalseallowPublicKeyRetrievaltrueuseSSLfalseMySQL 8.0 默认开启 SSL 校验如果你没配证书连接会直接失败allowPublicKeyRetrievaltrue配合caching_sha2_password认证时需要这个参数才能允许从服务器获取公钥否则连接过程会报 Public Key Retrieval is not allowed。4.3 scm/hive 等库的初始化与 db.properties 配置安装 MySQL 并启动后先创建 CDH 需要的各个元数据库CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE amon DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE rman DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE hive DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE nav DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE navms DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE USER scm% IDENTIFIED WITH mysql_native_password BY scm_password; CREATE USER amon% IDENTIFIED WITH mysql_native_password BY amon_password; CREATE USER rman% IDENTIFIED WITH mysql_native_password BY rman_password; CREATE USER hive% IDENTIFIED WITH mysql_native_password BY hive_password; CREATE USER sentry% IDENTIFIED WITH mysql_native_password BY sentry_password; CREATE USER nav% IDENTIFIED WITH mysql_native_password BY nav_password; CREATE USER navms% IDENTIFIED WITH mysql_native_password BY navms_password; GRANT ALL PRIVILEGES ON scm.* TO scm%; GRANT ALL PRIVILEGES ON amon.* TO amon%; GRANT ALL PRIVILEGES ON rman.* TO rman%; GRANT ALL PRIVILEGES ON hive.* TO hive%; GRANT ALL PRIVILEGES ON sentry.* TO sentry%; GRANT ALL PRIVILEGES ON nav.* TO nav%; GRANT ALL PRIVILEGES ON navms.* TO navms%; FLUSH PRIVILEGES;之后在 CM Server 节点执行初始化脚本/opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm_password这个脚本会往scm库里写入 CM 自己的 Schema。执行前确认/etc/cloudera-scm-server/db.properties里的连接信息匹配如果你用的是 MySQL 8.0脚本如果因驱动找不到失败多半是 JDBC jar 路径问题按 4.2 里我给的路径放好再试一遍即可。5. Cloudera Manager 部署和 Parcel 分发的完整链路5.1 用 rpm 离线装 CM Server/Agent 的关键步骤在线安装方式没有多少技术含量但在内网环境我推荐把 rpm 包下载下来用dnf localinstall去装这样既可控又能保留安装日志。先到 Cloudera Archive 仓库找到对应版本号的 rpm 包下载列表主要下载四个包cloudera-manager-daemonscloudera-manager-servercloudera-manager-agentcloudera-manager-server-db如果要用自带 PG 才装生产环境可跳过安装顺序先装 daemons再装 server 和 agentdnf localinstall -y cloudera-manager-daemons-6.3.2-*.el7.x86_64.rpm dnf localinstall -y cloudera-manager-server-6.3.2-*.el7.x86_64.rpm dnf localinstall -y cloudera-manager-agent-6.3.2-*.el7.x86_64.rpmdaemons 是 CM Server 和 Agent 共用的运行环境里面包含了脚本、库文件、默认配置。装上之后在 CM Server 节点启动systemctl start cloudera-scm-server systemctl start cloudera-scm-agentAgent 节点上只需要安装 daemons 和 agent 两个包然后把/etc/cloudera-scm-agent/config.ini里的server_host改成 CM Server 的主机名或 IPserver_hostcdh01.example.com再启动 agent。启动后去 CM Server 节点上看日志tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到类似“Started Jetty server”的日志就说明 Server 起来了。如果一直卡在初始化阶段大概率是数据库连接或者 JDBC 驱动的问题回到第 4 章排查。5.2 Parcel 仓库的放置、校验与 HTTP 分发Parcel 是 CDH 分发组件的打包格式它在 CM 界面里叫Parcel本质是一个.parcel文件加一个manifest.json。你需要下载 CDH-6.3.2 的 EL7 parcel 包注意这里用的是el7.parcel不是 el8 或 el6。mkdir -p /opt/cloudera/parcel-repo cd /opt/cloudera/parcel-repo wget https://archive.cloudera.com/cdh6/cdh/6/CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel wget https://archive.cloudera.com/cdh6/cdh/6/manifest.json chown cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo/*放好之后先用 sha256 校验一遍sha256sum CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel把结果去manifest.json里搜一下确认一致。不要跳过这步很多内网用网盘转披的 parcel 文件容易被截断校验不过直接激活失败而且是那种毫无提示的失败。接下来打开 CM 管理界面主机 → Parcel → 添加新 Parcel选择本地仓库路径CM 会自动读取/opt/cloudera/parcel-repo下的文件。点击下载后 CM 会把 parcel 分发到所有 agent 节点的/opt/cloudera/parcels下。如果你节点很多又走公网下载速度会很感人。我的经验是在 CM Server 节点直接用 nginx 把 parcel-repo 目录暴露成 HTTP 服务然后在 CM 界面填远程仓库 URL这样内网节点之间走千兆网口分分钟跑完。dnf install -y nginx cat /etc/nginx/conf.d/parcel.conf EOF server { listen 8080; root /opt/cloudera/parcel-repo; autoindex on; } EOF systemctl start nginx5.3 创建集群时容易被忽略的角色分配与目录权限Parcel 激活之后进入集群创建向导。这一步我见过太多人图省事一路下一步结果后续全部返工。几个关键点角色分配建议把 NameNode、ResourceManager、ZooKeeper 分散到不同节点避免单节点故障时整个集群管理面全挂。小规模集群可以接受一台物理机上多个角色但至少把 HDFS NameNode 和 YARN ResourceManager 分开。目录权限HDFS 的数据目录最好单独创建比如/data/dfs/nn、/data/dfs/dn。CM 会提示目录为空、属主为hdfs:hdfs。如果是自己手动 mkdir记得执行mkdir -p /data/dfs/nn /data/dfs/dn chown -R hdfs:hdfs /data/dfs/nn /data/dfs/dnHive Metastore 数据库配置向导中让你填 Hive Metastore 数据库时JDBC URL 按我在 4.2 提到的带useSSLfalseallowPublicKeyRetrievaltrue的格式填。很多人在这步卡到怀疑人生其实就是连接串少了参数。Spark 日志目录Spark on YARN 模式下spark.eventLog.dir建议配置为 HDFS 路径hdfs://cdh01:8020/user/spark/spark2History并预先创建好 HDFS 目录否则跑到第一个 Spark 作业时 History Server 各种报错。6. 首次部署后必踩的高频问题与完整排查思路6.1 从角色启动失败到 systemd 单元日志的分析链路几乎每个第一次在 EL8 上装 CDH 的人打开 CM 界面都会看到一堆角色是红色状态。这时候别慌按下面的链路排查。第一步去/var/log/cloudera-scm-agent/cloudera-scm-agent.log看 Agent 的状态。如果 Agent 没正常连上 ServerCM 界面显示的主机状态就是托管中或坏。常见报错是Exec format error或者python2相关的 import 错误前者多半是你没装 python2 或软链没建立后者多半是系统python指到了 python3。第二步看具体角色的运行日志。比如 HDFS 的 DataNode 起不来在 CM 界面点角色 → 查看日志或直接翻/var/log/hadoop-hdfs/hadoop-hdfs-datanode-hostname.log。如果是libnsl.so.1: cannot open shared object file就到节点上补装dnf install -y libnsl ncurses-compat-libs第三步用 systemd 的 journal 看进程退出原因journalctl -u cloudera-scm-agent -n 200如果是权限问题日志里会写Permission denied大概率是 SELinux 没关或者/opt/cloudera目录属主不对。我遇到过一次特别隐蔽的情况CM 升级后/opt/cloudera/parcels下多了一层目录导致 agent 读到两个 CDH 版本手动把老目录删掉再systemctl restart cloudera-scm-agent就好了。6.2 MySQL 连接失败、Redis 连不上的共同根因端口与 hosts很多人在集群刚搭好时跑去验证某个独立组件发现 Redis 连不上、MySQL 也连不上第一反应是是不是 CDH 影响了网络。其实大多数情况下是端口监听和 hosts 解析的问题。MySQL 连接失败的经典报错是Cannot connect to MySQL server (110)。这个 110 是Connection timed out的 errno排查顺序看看 MySQL 是不是只监听 127.0.0.1ss -lntp | grep 3306如果是127.0.0.1:3306那其他节点当然连不上。需要改/etc/my.cnf里的bind-address0.0.0.0重启 MySQL。检查防火墙是否真的关干净了systemctl status firewalld firewall-cmd --state如果 firewalld 又在运行先放行 3306 端口或再次彻底关闭。Redis 连不上的逻辑完全一样。Redis 默认bind 127.0.0.1且启用protected-mode yes只允许本机连。如果你要让 CDH 某台节点连接 Redis必须改配置bind 0.0.0.0 protected-mode no然后重启 redis。这两个问题经常被当成网络问题去抓包其实十分钟就能查完。6.3 ulimit、swappiness、THP 对集群稳定性的影响集群跑起来之后真正影响稳定性的往往是那些看起来无关紧要的系统参数。CM 界面的 Host Inspector 会提示 ulimit 值不满足比如ulimit -n建议至少 65536。解决办法cat /etc/security/limits.conf EOF * soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536 EOF但如果角色进程是通过 systemd 拉起limits.conf可能不完全生效需要给对应 service 单元加 override。不过 CDH 的角色由 CM 托管的进程管理通常继承 agent 的 ulimit所以把 agent 的 systemd 单元也加上限制mkdir -p /etc/systemd/system/cloudera-scm-agent.service.d cat /etc/systemd/system/cloudera-scm-agent.service.d/limits.conf EOF [Service] LimitNOFILE65536 LimitNPROC65536 EOF systemctl daemon-reload systemctl restart cloudera-scm-agent再说到 THP如果你没有按第 2 章的方法关闭透明大页集群跑了几天后DataNode 会频繁出现因为内存碎片导致的分配失败特别是 Impala 这种大内存常驻进程直接表现为进程反复 OOM。关闭 THP 后最好再重启一次集群角色让内存重新统一切换到普通页表模式。vm.swappiness的作用我在内核参数里提过这里再补一句如果节点内存不充裕swappiness 调太低会让系统宁可回收页缓存也不换出内存反而拖慢读写。所以不要无脑调到 0建议 1 或 10 即可CDH 默认建议是 10 以下。7. 上线前的几个收尾动作7.1 健康检查的第一轮该看什么激活集群、所有服务变绿之后先别急着上业务。我会按这个顺序做第一轮检查在 CM 首页看绿色/黄色告警逐个点开黄色的不用慌红色的必须处理。最常见的黄色是磁盘空间低于阈值和文件描述符数量过多前者检查数据盘挂载后者按 6.3 配置好 ulimit 即可。跑一次 HDFS 自带的校验hdfs fsck / -files -blocks -locations重点看有没有损坏的块。如果不行说明磁盘或网络有问题趁早换盘。跑一次简单的 MR 或 Spark 作业验证资源调度yarn jar /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 4 1000如果 YARN 分配资源失败去看 ResourceManager 日志和 NodeManager 日志多半是内存配置超了物理机实际可用内存回到 CM 的 YARN 配置里调低yarn.nodemanager.resource.memory-mb。Hive 验证一条简单查询确认 Metastore 连接正常。不进查询界面直接用 beeline/opt/cloudera/parcels/CDH/bin/beeline -u jdbc:hive2://cdh01:10000 -e show databases;如果报数据库连接错误优先回到 MySQL 授权和 JDBC 驱动上检查。7.2 快照、备份与监控建议正式环境接入业务前我强烈建议做三件事第一给所有节点打虚拟机快照。不用多说CDH 最怕的是装到一半想回滚却发现没有还原点。第二备份 CM Server 的元数据库和配置。CM 的scm库里不仅有集群配置还有租户信息、角色分配丢失后恢复的代价极高。可以配置每天凌晨用mysqldump把scm、hive两个库导出来保留最近 7 天即可。第三配置一套告警通道。即使你不用 CM 自带的邮件告警也建议至少把监控端口暴露到 Zabbix/Prometheus 体系里。大集群里我踩过的坑是某个 DataNode 磁盘满了CM 有告警但没人及时看邮箱最后整个 HDFS 进入安全模式。所以告警要接即时通信或短信通道不要只靠邮件。7.3 我个人的一点体会这套 CDH 6.3.2 在 CentOS 8 / alinux3 上的安装方案本质就是版本伪装 兼容库补齐 数据库适配三个动作的组合。跑通之后只要不去做系统大版本升级、不重装 glibc、不乱删/etc/redhat-release集群日常稳定性跟 CentOS 7 上没什么差别。最后分享一个我自己留的小技巧在所有节点上保留一份/etc/redhat-release.bak同时在运维文档里写清楚哪个节点改过系统版本。否则过几个月你接手的人看到系统版本显示 CentOS 7 但底层明明是 alinux3会百思不得其解。如果你刚好也在折腾这套东西按照上面的顺序一步步来大概率一天之内能把集群拉到全绿状态。要是遇到别的报错先把日志看透再动手别一上来就重装系统——至少我的经验里绝大多数问题都不是系统本身的锅。