云服务器搭建CDH前要准备哪些环境和配置

很多企业做数据平台，都会先上测试环境。云服务器搭建cdh就是这一步里很常见的需求。和本地机房相比，云环境开通快、扩容方便，前期不用压太多硬件成本，拿来做POC验证、教学实验或者部门级试点都合适。

但CDH放到云上，并不是把几台机器创建出来就能顺利装完。主机名解析、节点间网络、时钟同步、磁盘挂载、系统参数、依赖版本，这些基础项只要有一处不规整，问题通常不会立刻集中爆发，而是卡在安装检查、Parcel分发，或者装完后出现Agent掉线、DataNode不稳、服务反复重启。前面省下的时间，后面基本都会补回来。

如果你正准备做云服务器搭建cdh，可以把准备工作分成三块看：节点怎么分、机器怎么选、基础环境怎么统一。把这三件事理顺，后面的Cloudera Manager安装和集群服务部署会顺很多。

为什么很多团队先在云上部署CDH

CDH本身整合了HDFS、YARN、Hive、HBase、Spark、Impala这些常见组件，适合搭一套完整的大数据平台。放在云服务器上，优势很现实。

• 启动门槛低：不用先采购物理机，几台云服务器就能把基础链路跑起来，适合验证方案。
• 资源调整快：节点规格、磁盘容量、带宽可以按阶段变更，前期不用一次定死。
• 环境隔离更容易：开发、测试、预生产分开部署，互相影响会小很多。
• 能直接配合云上基础设施：安全组、监控告警、对象存储、负载均衡这些能力，后面做运维会方便。

云上也有云上的坑。最常见的误区，是把它当成普通中间件安装。CDH对磁盘IO、内网通信、时钟一致性、目录规划都比较敏感，尤其是多角色混布时，资源冲突会很快放大。学习环境还能凑合跑，部门测试环境往往扛不住。

云服务器搭建cdh前，先把节点和规格想清楚

节点角色怎么分

一个基础CDH集群，至少会涉及这些角色：Cloudera Manager Server、NameNode、Secondary NameNode或Standby NameNode、ResourceManager、DataNode、NodeManager、ZooKeeper、Hive Metastore、HiveServer2。

如果只是学习或功能验证，3台云服务器可以做最小化部署，很多角色只能混在一起。这样做能跑通流程，但不太适合做稳定性验证。只要开始导数据、跑任务，管理服务和计算存储服务就容易互相抢资源。

部门级测试环境更适合从5台起步，至少把管理节点、主节点和工作节点大致拆开。主从角色混得太厉害，问题排查会很麻烦。比如NameNode和MySQL、Hive Metastore堆在一台小规格机器上，平时看不出什么，碰到任务集中、元数据操作变多，卡顿就会很明显。

机器规格别只盯着CPU和内存

云服务器搭建cdh时，很多人先看核数和内存，实际上磁盘和网络同样关键。常见做法是：

• 管理节点从4核8G起步，放CM Server、数据库以及少量管理类服务。
• 工作节点用8核16G或更高，比较适合承载HDFS和YARN任务。
• 系统盘和数据盘分开，避免系统日志、服务日志和业务数据挤在一起。
• 优先选性能稳定的云盘，HDFS对磁盘抖动比较敏感。

这里有个很容易忽略的细节：测试环境也别把所有目录都堆到系统盘。短期看省事，等HDFS数据目录、YARN本地缓存、日志文件一起涨，系统盘先满。满盘后不只是DataNode告警，Cloudera Manager本身也可能出现异常。

如果你准备做更接近生产的测试集群，建议直接挂多块数据盘，为HDFS配置多个数据目录。这样做一方面是把IO压力摊开，另一方面是后面排查性能问题时，目录和挂载点更清楚，不会所有服务混成一团。

基础环境没配好，安装阶段就会反复卡住

网络、主机名、时钟同步是前置条件

不少部署失败，问题常常出在云环境基础配置不规范。下面这些项，最好在装Cloudera Manager之前一次性处理好：

1. 所有节点主机名唯一，并且能双向解析。DNS没准备好的话，至少把hosts维护一致。
2. 安全组提前放通必要端口，不然Agent和Server通信会出问题。
3. 防火墙和SELinux要么按要求关闭，要么按部署规则提前配置好，不要一边装一边试。
4. 统一NTP时钟同步。时间漂移看起来不起眼，但会影响服务注册，后面如果接Kerberos，问题会更明显。
5. 配置免密登录，方便批量分发脚本、巡检和后续维护。
6. 把文件句柄、进程数、swap等系统参数按要求设好，别等主机检查报错后再回头改。

安装时最烦的情况，就是表面上机器都能连，Web页面也能打开，但Cloudera Manager一到主机检查、Parcel分发、Agent注册这些步骤就断断续续报错。这类问题大多是基础配置有一两项没统一，查起来反而更耗时间。

操作系统和依赖版本别想当然

CDH对操作系统版本、JDK版本有兼容要求，部署前要先确认支持矩阵。通常要准备的内容包括：受支持的CentOS或RHEL版本、本地YUM源或可访问的镜像仓库、JDK及JAVA_HOME、MySQL或PostgreSQL作为管理库和元数据库。

如果云服务器不能直接访问公网，最好提前准备内网YUM仓库和Parcel仓库。这样做有两个好处：一是多节点安装时速度稳定，不容易因为外部网络抖动中断；二是后续扩容更省事，新节点进来后可以直接复用现有仓库，不用再临时找包。

还有一个容易踩的点是数据库初始化。Cloudera Manager和Hive这类服务对数据库编码、权限、连接参数都有要求，前面图快随手建库，后面创建服务时才报错，会把问题拖到更靠后的位置，定位起来更绕。

云服务器搭建cdh的部署顺序，别一口气把组件全装上

先装Cloudera Manager，再分阶段起服务

标准流程一般是这样：先在管理节点安装Cloudera Manager Server和数据库，再在各节点安装Agent；然后通过Web控制台导入主机，做环境检查，分发Parcel，激活对应版本。

这一步里，除了数据库编码和权限，主机资源预检也要认真看。像透明大页、swap、ulimit这些检查项，即使暂时没阻断安装，也别当成“警告无所谓”。很多后续稳定性问题，都是这里埋下的。

进入服务部署阶段后，不建议初次做云服务器搭建cdh的团队一开始就把HDFS、YARN、ZooKeeper、Hive、Spark、Impala全选上。组件越多，变量越多，任何一个角色参数不合适，都会把问题放大。

更稳妥的顺序是：

1. 先把ZooKeeper跑起来，确认基础协调服务正常。
2. 再部署HDFS，先看NameNode、DataNode状态和数据目录是否工作正常。
3. 然后上YARN，检查NodeManager注册和容器资源配置。
4. 基础链路稳定后，再按业务需要增加Hive、Spark、Impala。

这样排查更直接：哪一步出问题，就回到哪一层查，不会一上来就被一堆服务告警淹没。

一个5台云服务器搭建cdh测试集群的常见场景

中小型项目里，5台云服务器是比较常见的起步规模。比如一套测试集群可以这样分：

• 1号节点放CM Server、MySQL、Hive Metastore。
• 2号节点放NameNode、ResourceManager。
• 3到5号节点放DataNode、NodeManager。
• 1到3号节点同时部署ZooKeeper。

每台机器8核16G，系统盘100G，再挂2块500G数据盘，这个配置拿来验证日志采集、离线分析、即席查询，基本能跑起来。问题往往出在“图省事”的那一步。

比如HDFS目录直接放系统盘，开始导入测试数据时看着没事，过一阵子日志文件、临时文件和业务数据一起涨，系统盘很快就紧张。接下来你会看到DataNode频繁告警，服务也变得不稳定。把数据目录迁到独立云盘，再把YARN本地目录单独规划，集群状态通常会立刻好很多。

还有一种情况也很常见：某台云服务器重建后内网IP变了，但hosts没有同步更新。结果是Agent和Server时通时不通，页面上节点状态一会儿正常、一会儿丢失。这个问题不复杂，修正主机名解析、重启Agent就能恢复，但排查时很容易误以为是CM或者网络本身有故障。

这类问题有个共同点：机器能登录、服务能启动，不代表环境就真的规范。云服务器搭建cdh最怕的，就是基础设施“看起来可用”，细节却没统一。

部署过程中常见的几类问题

Parcel下载或分发失败

常见原因有公网访问受限、磁盘空间不足、Agent通信异常，也可能是/opt/cloudera/parcel-cache这类目录权限不对。云上环境如果网络路径不稳定，提前准备本地Parcel仓库，比反复在线下载省事得多。

主机检查过不去

遇到这类问题，先看几项基础内容：swap是否关闭、透明大页是否禁用、Python和JDK版本是否匹配、时钟和hosts是否统一。别一上来就怀疑安装包，很多时候就是系统基线没处理完。

HDFS写入性能差

如果用了低规格云盘，或者多种服务混跑在同一块盘上，写入性能下降会很明显。比较稳妥的做法，是把NameNode元数据目录、DataNode数据目录、YARN本地缓存目录分开规划。这样即使后面要调优，也知道瓶颈大概落在哪一层。

内存告警反复出现

不一定只是机器规格不够，也可能是YARN资源分配过大、Hive或Impala默认参数偏高，或者一台机器上混了太多角色。处理时别只看“剩余内存少不少”，要结合节点职责，重新算堆内存和容器上限。

想让云服务器搭建cdh更稳，几个习惯很有用

• 先小规模跑通，再扩容：3到5节点先把流程打顺，比一开始追求全组件上线更实际。
• 把配置做成标准：主机名、挂载点、目录命名、账号权限尽量统一，后面扩节点不容易乱。
• 监控早点上：磁盘使用率、JVM内存、GC、网络延迟、服务心跳，这些指标越早看，越容易发现问题趋势。
• 系统和数据分开：系统盘只放操作系统和基础日志，业务数据、HDFS目录尽量放独立盘。
• 给后续扩容留位置：子网规划、节点命名规则、磁盘布局最好一开始就定下来，后面补救成本更高。

如果目标只是学习环境，重点是把安装流程完整走通；如果是企业测试环境，关注点会更偏向稳定、可复制、便于扩容。两者都能用云服务器搭建cdh，但准备工作的细致程度不能一样。

实际做的时候，先把主机规范、磁盘布局、基础网络和系统参数收拾干净，再去装Cloudera Manager和业务组件，效率通常比“先装起来再修”高得多。CDH能不能在云上稳定跑，往往取决于这些前置环境有没有认真准备。