SO豹猫先说我这边的一个判断：不管你是刚把第一套Hadoop集群搬上云，还是正在纠结“在云主机上跑Hadoop到底行不行”，这块内容都有一个绕不开的前提——Hadoop本身是给物理机房设计的分布式架构，到了云环境里，网络、磁盘、主机名、防火墙这些基础条件全变了，很多物理机时代“根本不用管”的细节，会变成集群能否稳定运行的关键。
我这两年做过好几个基于云主机的大数据平台项目，从一套三节点的测试集群起步，后来扩到几十个节点，中间踩过的坑比看过的文档还多。这篇就围绕“Hadoop在云主机上的部署”这个主题，把从架构规划、环境准备、安装配置到上线运维的完整思路捋一遍，特别会讲清楚哪些环节和物理机部署不一样、为什么不一样、怎么处理才不会留隐患。适合正在搭集群、后续要做扩容，或者已经在云端跑了Hadoop但经常出问题的朋友参考。
1. 为什么说“把物理机部署方案直接搬到云上”是最容易翻车的做法
很多教程教你装Hadoop时，默认你手里有物理服务器，于是直接给一套“三台机器、各配几百GB磁盘”的方案。但你放到云上，按这个思路买完机器、改完配置，大概率会出现两种情况：一是集群能起来，但跑几天数据节点开始掉线；二是NameNode Web界面都能打开，但DataNode就是注册不进来。这些现象背后，不是Hadoop配置写错了，而是云环境的基础设施模型和物理机房有着本质区别。
1.1 数据本地性在云网络里可能失效
HDFS设计时有个核心假设：数据分成多个Block存在不同的DataNode上，计算框架（比如MapReduce或Spark）会尽量把任务调度到“数据所在的那台机器”上执行，避免把大量数据从网络另一端搬过来，这就叫数据本地性。
物理机房里，机架内部走的是万兆内网，跨机架带宽也有保障，数据本地性的收益非常明显。但在云上，虚拟机之间的流量会经过云厂商的虚拟交换机，带宽上限和你购买的实例规格直接挂钩。假如你为了省钱买了低配实例，或者把主节点和计算节点放在不同可用区，那“数据本地”的优势就会被网络带宽削掉大半，甚至出现“任务大部分时间都在等数据”的尴尬局面。
所以云上部署Hadoop，第一件事不是选Hadoop版本，而是把网络模型看清楚：所有集群节点尽量放在同一个 VPC（私有网络）下的同一个可用区，节点之间走内网通信；跨可用区可以做容灾，但不要把一个Hadoop集群劈成两半放在不同可用区里。
1.2 云磁盘的IOPS瓶颈会影响NameNode
NameNode是HDFS的元数据中心，所有文件的增删改查都要先问它，它自身并不存业务数据，但会频繁读写磁盘上的元数据镜像（fsimage）和编辑日志（edits）。这两个文件的读写性能，直接决定集群能支撑多大的请求压力。
物理机上配个SAS盘加RAID卡，顺序写性能基本够用。但云主机的默认系统盘往往只是“能启动系统”的级别，IOPS和延迟表现平庸。要是NameNode/JournalNode跑在这种磁盘上，集群文件一多，元数据操作就会明显变慢，观察起来就是“文件操作卡顿”“心跳延迟升高”。
我的建议是：给NameNode、JournalNode这类承担元数据职责的节点配SSD规格的云盘，DataNode的存储盘反而可以用大容量普通云盘，因为DataNode存的是大块数据，顺序读写为主，对单盘IOPS要求不那么极端。这块选择做对了，集群规模扩大后能省很多麻烦。
1.3 云安全组就是机房的防火墙，但它不在你的主机里
物理机房里，防火墙通常设在机柜或机房出口，服务器本机的iptables很多时候是空策略。云环境里不一样——每个云主机前面都有一层安全组规则，它拦截在你机器外面，你操作系统里看不到任何日志，但端口就是不通。
这意味着什么？你用systemctl或ps命令看到Hadoop进程都活着，Service端口也监听着，但从别的机器访问却连接超时，这类问题经常被误判成Hadoop启动失败，实际上就是安全组没放行对应端口。这个点我在后面运维故障部分还会详细讲，这里先提醒一句：不要只信主机内部的状态，要会用安全组视图审视整个集群的连通性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 云上集群拓扑：主节点、数据节点和辅助节点怎么规划
说实话，如果你只是做学习测试，一台8核16G的云主机就能跑伪分布式Hadoop。但生产环境至少得有个“像样”的拓扑。云上部署的节点规划，核心就三个问题：主节点要不要做HA、数据节点怎么配存储、ZooKeeper这类辅助组件放在哪。
2.1 主节点：先跑通单NameNode，还是直接上HA
很多教程一开始就让你搭NameNode HA（高可用），两个Active/Standby节点加三个JournalNode加ZooKeeper，听起来很完整。但我想给个更务实的建议：如果你的集群规模还没到上百TB数据、几十个计算任务并发，而且你刚好是第一回在云上搭集群，那先部署一台NameNode把链路跑通，是更稳的路径。
原因不复杂：NameNode HA虽然解决了单点故障，但也引入了更多需要维护的组件——ZooKeeper集群、JournalNode集群、故障自动转移机制。任何一个环节配置不对，可能比NameNode本身宕机还让人崩溃。而且云平台本身提供了磁盘快照能力，NameNode机器的系统盘和数据盘可以定期打快照，遇到问题时用快照恢复，比在Hadoop层面做HA的恢复成本低、见效快。
等集群规模变大了、业务对连续性要求确实高，再补上NameNode HA也不迟。到那时你已经有完整的部署和监控经验，加HA只是“照着规范补充组件”的事。我的建议是分两步走：第一步用单NameNode交付，第二步按业务需求决定是否升级HA。
2.2 DataNode规格：计算和存储要不要绑在一起
经典Hadoop架构里，DataNode兼任计算节点，数据存在本地磁盘，计算任务也在这台机器上跑，这是为了数据本地性。云上有个特殊选择：能不能把计算和存储分开，DataNode只管存数据，计算用另外的弹性资源池？
答案是可以，但要分情况。如果你主要跑MapReduce、Spark这类对数据本地性敏感的计算引擎，计算和存储分离会导致每个任务都要通过内网拉取远端数据，网络开销不小，尤其数据量大时效率感人。如果你的核心场景是“数据先落到HDFS，偶尔跑跑离线分析，更多时候是外部系统通过API读文件”，那存储节点规划成独立实例反而更清晰。
我自己的经验是：大多数中小企业场景，DataNode和NodeManager放在同一批实例上仍然是最稳、最省心的做法。 存储和计算分离适合那种计算任务波峰波谷特别明显的团队——平时低负载，月底集中跑批，这时可以让DataNode保持稳定数量，计算节点高峰时扩容、空闲时缩容，节约成本。
2.3 ZooKeeper节点别省：三个小实例比一个大实例更可靠
如果后续要上HBase、Kafka或者NameNode HA，ZooKeeper基本是标配。ZooKeeper集群要求“奇数节点”，一般生产环境用三个。云上部署时，很多人习惯开三台大规格机器跑ZK，其实没必要——ZooKeeper对CPU和内存的要求不算高，关键是节点数量和网络质量。
我通常给客户开三台2核4G的小实例，放在和Hadoop集群同一个VPC里，ZooKeeper进程单独部署，不跟其他大数据组件混布。原因有两方面：一是ZK的选举机制需要节点间低延迟通信，独立部署能避免资源争抢导致的心跳超时；二是ZK故障时影响面要尽量小，和数据节点混在一起容易放大故障。
3. 初始化环境与Hadoop部署的逐步落地
这节是最容易照着抄的部分。我把从一台全新的云主机到能正常提交MapReduce任务的完整过程分步展开，过程中标注清楚哪些命令在物理机和云上是有差异的。
3.1 JDK版本选择和安装
Hadoop 3.3.x官方支持Java 8和Java 11。我建议用Java 8，倒不是Java 11不行，而是很多配套生态组件（比如Hive、Spark的某些老版本）对Java 8的兼容性验证最充分，你无法确定未来会扩展哪些组件，选Java 8给自己留的余地最大。
在云主机上装JDK没有特殊之处，用包管理器安装或者手动解压tar包都行。注意一点：云厂商的某些系统镜像默认带的是OpenJDK，如果你之前跑过其他Java应用，机器上可能已经有JAVA_HOME的环境变量了，装完Hadoop后最好显式确认java -version的版本，避免和Hadoop自带的脚本判断产生冲突。
我习惯把JDK统一装到/usr/local/java，然后在/etc/profile里写入：
bash复制export JAVA_HOME=/usr/local/java/jdk1.8.0_202
export PATH=$JAVA_HOME/bin:$PATH
有没有必要在每台机器上都手动操作一遍？集群节点少的时候可以，节点一多就要用自动化工具批量分发。我后面会专门讲到批量部署的思路。
3.2 Hadoop解压、环境变量与常见PATH问题
Hadoop的二进制包解压到/usr/local/hadoop后，需要设置两个关键环境变量：HADOOP_HOME和PATH。
bash复制export HADOOP_HOME=/usr/local/hadoop
export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH
这里有个非常多人踩过的坑：执行hdfs dfs -ls或提交任务时报“jar does not exist or is not a normal file”这类错误。它通常不是因为某个jar文件真的丢了，而是命令行工具在解析Hadoop安装路径时出了问题——比如HADOOP_HOME路径末尾多了个斜杠、或者你修改了Hadoop安装目录但没同步修改所有引用路径。
排查思路很简单：先echo $HADOOP_HOME确认路径，再用hadoop version检查能否正常加载，最后看/usr/local/hadoop/share/hadoop/common/下有没有对应版本的jar包。这个目录结构是Hadoop标准布局，不要随意改动。
3.3 核心配置文件：core-site.xml和hdfs-site.xml
Hadoop的配置集中在$HADOOP_HOME/etc/hadoop/下。最小可用集群至少要改四个文件，我把常用配置和“为什么这样设”放在一起解释。
core-site.xml
xml复制<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://namenode-host:9820</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/data/hadoop/tmp</value>
</property>
</configuration>
fs.defaultFS是客户端访问HDFS的入口，这个地址会被所有客户端和DataNode引用，配置的host必须是集群内所有节点都能解析的主机名。hadoop.tmp.dir默认值在/tmp下，云主机一旦重启，/tmp可能被系统清理，所以必须把这个目录改到独立数据盘，这是云部署中不能省的操作。
hdfs-site.xml
xml复制<configuration>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>/data/hadoop/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>/data/hadoop/datanode</value>
</property>
</configuration>
dfs.replication在测试集群里可以设成1或2，生产环境还是建议按默认3来，它决定了数据块有几个副本。云上如果跨可用区部署，可以设置dfs.replication为3并且让副本分布在不同可用区，不过前提是网络带宽你能扛得住。
dfs.namenode.name.dir和dfs.datanode.data.dir这两项尤其重要。云主机通常有一块系统盘和若干数据盘，一定要把元数据和数据块放到独立的数据盘上——这既避免系统盘被写满拖垮整台机器，也是将来磁盘扩容的前置条件。
3.4 SSH免密登录是云上集群最容易出问题的配置项
启动Hadoop集群时，主节点会通过SSH登录到各DataNode启动进程。如果你没有配置SSH免密，脚本会卡在密码输入上，表现为“某一台节点起不来”或者“只能手动逐个启动”。物理机上一般通过ssh-copy-id把公钥分发到各节点，云上同样如此。
但云上有个额外问题：很多云主机默认禁止root远程登录，或者没有给root设置可登录的密钥。我的经验是专门创建一个hadoop用户来管理集群，所有组件和进程都以这个用户运行，然后把主节点的公钥分发到各节点的hadoop用户下。这比直接用root更安全，也避免了一些Hadoop脚本在root权限下行为怪异的问题。
bash复制# 在主节点生成密钥对
ssh-keygen -t rsa -b 4096
# 将公钥复制到各节点
ssh-copy-id hadoop@datanode01
ssh-copy-id hadoop@datanode02
3.5 格式化NameNode：一次格式化背后的状态一致性
执行hdfs namenode -format之前，一定要确认dfs.namenode.name.dir指向的目录是空的。格式化的动作是生成初始的元数据镜像和Cluster ID，这个Cluster ID会被所有DataNode记住。
特别提醒：如果格式化后发现启动不了，调整了配置、重新执行一次hdfs namenode -format，这样做大概率会让新的Cluster ID和旧的DataNode上保存的Cluster ID不一致，于是DataNode启动后无法注册到NameNode，日志里出现Incompatible clusterIDs的异常。
我在生产环境见过不少次这种场景。解决办法不是反复格式化，而是：
- 确认NameNode和DataNode的存储目录。
- 如果集群还没有正式数据，把所有节点上的
dfs.namenode.name.dir和dfs.datanode.data.dir清空，再重新格式化。 - 如果已经有业务数据，坚决不能简单格式化，而要借助
hdfs namenode -recover或从fsimage镜像恢复。
格式化成功后会打印successfully formatted，同时在NameNode目录下生成current/VERSION文件。看到这个文件再启动HDFS，就算是过关了。
3.6 首次启动集群并验证可用性
格式化完NameNode后，在主节点执行：
bash复制start-dfs.sh
这个脚本会按workers文件（老版本叫slaves）里列出的主机名逐个启动DataNode。启动后用jps查看进程：
- 主节点应有
NameNode进程。 - 每个数据节点应有
DataNode进程。
接着在浏览器访问NameNode的Web界面，默认端口是9870（Hadoop 3.x）或50070（Hadoop 2.x）。如果你用的是云主机，此时大概率会发现浏览器打不开——原因我前面提过：安全组还没放行端口。先去云控制台给这台主机加上放行9870端口的安全组规则，并把来源限制为你的办公IP，而不是0.0.0.0/0。
4. 踩坑实录：集群启动后最常见的三个故障排查
我不敢说下面的故障你一定遇到，但根据我帮别人排查的经验，这三个坑在云部署场景中的出现频率排前三。
4.1 DataNode进程启动又退出，日志出现“Incompatible clusterIDs”
现象：start-dfs.sh执行完，主节点NameNode正常，某个或全部数据节点的DataNode进程启动几秒后消失，查看日志/usr/local/hadoop/logs/hadoop-hadoop-datanode-*.log发现Incompatible clusterIDs字样。
原因：格式化NameNode后数据节点内存的Cluster ID和NameNode存储的Cluster ID不是同一个。多半是重复格式化导致的，也可能是你直接把某台节点的数据盘从一个集群迁移到了另一个集群。
解决步骤：
- 先确认当前NameNode的Cluster ID：查看
/data/hadoop/namenode/current/VERSION文件中的clusterID。 - 各DataNode查看
/data/hadoop/datanode/current/VERSION中的clusterID。 - 如果不一致且数据可丢弃，把DataNode目录清空后重启DataNode，让它自动注册新Cluster ID。
- 如果有数据不能丢，绝对不能清空目录，建议从NameNode侧恢复DataNode的注册信息或者回滚NameNode到原始状态。这里头最忌讳的就是手忙脚乱反复操作，把情况搞复杂。
我的心得：给NameNode格式化操作写个固定且唯一的执行流程，比如只有在新集群首次部署时才执行format，之后无论遇到什么启动问题都不再format。这样Cluster ID不一致的故障基本能杜绝。
4.2 NameNode安全模式卡住，无法写入文件
现象：集群正常启动后，NameNode进入Safe Mode，执行文件上传命令提示Name node is in safe mode，等了很长时间都出不来。
原因：NameNode启动时会加载元数据并等待DataNode上报数据块信息。安全模式是HDFS自我保护机制，当可用数据块比例达到配置阈值时才自动退出。云上场景常见触发因素有两个：一是DataNode数量少且其中几台启动缓慢，导致上报的数据块未达阈值；二是DataNode网络中断或注册不上，NameNode认为很多数据块丢失。
解决步骤：
- 先通过
hdfs dfsadmin -report查看当前有多少DataNode在线。 - 确认在线DataNode数正常后，用
hdfs dfsadmin -safemode leave手动退出安全模式。 - 如果退出后过一会儿又自动进入，说明有节点不稳定，回到第4.1节检查DataNode日志。
需要警惕的是：如果DataNode在线数量本身就不满足副本要求，强制退出安全模式并不会让数据变安全，反而可能让客户端写入成功但数据实际没达到副本数。这种场景要优先修复节点，而不是急着关闭保护机制。
4.3 从业务服务器访问HDFS超时，但集群内部完全正常
现象：你在集群里任何节点上执行hdfs dfs -ls /都正常，但换到另外一台不在集群里的服务器上，配置好客户端后怎么都连不上。
原因：这种问题的九成以上是网络层被拦截。云主机的安全组分为“入方向”和“出方向”，你只给集群内部机器之间放了行，但业务服务器所在的安全组和Hadoop集群所在的安全组之间没有建立互通规则。
排查清单：
| 排查项 | 具体操作 |
|---|---|
| 安全组入方向 | 是否放行了HDFS RPC端口（默认9820/9000） |
| 来源IP | 业务服务器内网IP是否在放行范围内 |
| 系统防火墙 | 云主机里的firewalld或ufw是否额外拦截了端口 |
| 客户端hosts解析 | 客户端能否解析fs.defaultFS配置的主机名 |
我建议从一开始就把集群节点和业务服务器放入同一个VPC下，通过安全组之间的规则互相放行，而不是依赖公网IP访问HDFS。用公网访问会引入安全和带宽双重问题，非常不推荐。
5. 扩容、HA引入与云端高可用
集群跑起来只是开始，业务数据增长后，你手头迟早会碰到两件事：扩容DataNode、增加NameNode高可用。
5.1 DataNode扩容的完整流程
云上加一台DataNode比物理机省事，但并不是“创建完机器加入集群就行”。
先在新机器上完成基础环境：JDK、Hadoop安装包、环境变量、与主节点SSH免密。然后把主节点上/usr/local/hadoop/etc/hadoop/下的配置文件同步过来，特别是core-site.xml和hdfs-site.xml。之后把新主机名追加到主节点的workers文件里，执行hdfs dfsadmin -refreshNodes，再在新节点执行：
bash复制hdfs --daemon start datanode
yarn --daemon start nodemanager
启动后到NameNode Web界面的Datanodes标签页确认新节点状态为In Service。新增节点不会自动迁移已有数据块，需要通过hdfs balancer触发数据均衡：
bash复制hdfs balancer -threshold 10
-threshold 10表示集群中各个节点磁盘使用率偏差超过10%时才迁移数据。这个过程可能持续几个小时到几天，取决于数据规模和网络带宽，属于正常现象。
云上的一个关键操作：在创建新数据节点时，直接购买一块独立的数据盘挂载到/data目录，别让数据落在系统盘上。不然以后扩容磁盘、做快照都会很被动。
5.2 从单NameNode升级到NameNode HA的步骤框架
如果你决策要上HA，需要的额外组件是ZooKeeper集群和JournalNode集群。JournalNode一般部署在三台机器上，负责同步Active NameNode的编辑日志给Standby NameNode。
整体步骤是这样：
- 部署三节点ZooKeeper并启动验证。
- 在原来的主节点和一台新节点上分别准备NameNode环境，配置
dfs.nameservices、dfs.ha.namenodes等相关参数。 - 在三台机器上启动JournalNode。
- 先格式化JournalNode：
hdfs namenode -initializeSharedEdits。 - 启动两个NameNode，将其中一个设为Standby。
- 配置并启动ZooKeeper Failover Controller进程，让ZKFC自动监控NameNode健康状态。
这套配置涉及的xml参数很多，不适合临场凭记忆写。建议动手前先参考官方HDFS High Availability文档，把hdfs-site.xml和core-site.xml的相关配置逐项核对清楚。这里我先说一个最多人忽略的点——dfs.client.failover.proxy.provider必须正确配置成ConfiguredFailoverProxyProvider，否则客户端不知道如何在两个NameNode之间切换。
5.3 云厂商能力与Hadoop高可用的配合方式
云平台提供了负载均衡、弹性伸缩、快照、重启策略这些能力，它们不能替代Hadoop内部的HA，但可以形成互补。
比如在主节点前面加一个云负载均衡，把HDFS RPC端口通过VIP暴露给内部业务服务。这样即使NameNode切到Standby节点，客户端的访问地址也不用改。ZooKeeper这一层的选主对客户端来说是透明的，但客户端首次连接有个配置切换的过程，有负载均衡就平滑很多。
另外，云主机的“自动重启”策略值得开启。如果哪台物理宿主机故障导致你的NameNode云主机重启了，至少系统能自动恢复，不用深更半夜爬起来手动开机。当然这只针对云主机层面的故障，Hadoop层面的进程崩溃还得靠supervisord或systemd这样的进程守护来拉起，我通常把NameNode、ResourceManager这些关键进程托管给systemd，这样崩了能自动重启。
6. 写入业务数据前的最后检查：配置、日志与命令
很多团队把HDFS建好后直接丢给业务方用，结果业务方一上传数据就报错。这里列几个真正值得在生产写入前做一遍的检查项。
6.1 hdfs-site.xml里容易忽略的目录权限
HDFS默认权限模型和Linux类似，DataNode存储目录、NameNode元数据目录的owner必须是启动Hadoop的那个用户。云主机如果当初不是用同一个用户解压和启动的，很容易出现Permission denied问题。
我在部署时会把整个Hadoop安装目录和/data/hadoop目录统一授权给hadoop用户：
bash复制chown -R hadoop:hadoop /usr/local/hadoop /data/hadoop
这个操作要在所有节点上执行一遍，包括NameNode和DataNode。
6.2 用命令行验证HDFS的关键操作
上传下载是最基础的验证，我更建议做一轮覆盖更多组件的健康检查：
bash复制# 查看整体健康度和节点状态
hdfs dfsadmin -report
# 查看数据块健康情况
hdfs fsck / -files -blocks -locations
# 创建一个测试目录并上传文件
hdfs dfs -mkdir -p /tmp/test
hdfs dfs -put /etc/hostname /tmp/test/
hdfs dfs -cat /tmp/test/hostname
hdfs fsck可能有些朋友没用过，它能扫描指定路径下的文件块是否完整、副本数是否达标，是上线前发现隐患的好工具。比如某个文件的副本数只有1，而副本策略要求2，fsck会直接报WARN。
6.3 资源管理组件YARN的检查
如果你还要跑MapReduce或Spark，ResourceManager和NodeManager也是重点。启动YARN：
bash复制start-yarn.sh
验证方式：在浏览器访问ResourceManager Web界面（默认8088端口），看Active Nodes数是否等于DataNode数。如果NodeManager无法启动，多半是yarn-site.xml里的yarn.nodemanager.resource.memory-mb或yarn.nodemanager.resource.cpu-vcores设置超出了云主机实际规格。
我见过一个典型错误：在2核4G的小机器上按物理机标准配置给NodeManager分了16G内存，导致NodeManager因为无法分配那么多虚拟内存而启动失败。云上配置不能照抄模板，必须跟实例规格对齐。核数是几核、内存是多大，先看云控制台再填参数，别想当然。
7. 云上Hadoop部署的自动化和成本控制建议
最后聊点对生产更有帮助的方向：部署自动化和成本优化。
7.1 用脚本或配置管理工具批量部署
手工在每台机器上敲命令，只适合节点数在5个以内的阶段。节点一多，手动操作既慢又容易出错。我常用的路径有两种：
轻量脚本方案：用Ansible写一套playbook，把JDK安装、Hadoop解压、配置分发、目录授权、启动服务这些步骤定义好。Ansible基于SSH执行，不需要在每台机器上装Agent，和Hadoop的SSH免密天然兼容。
容器化方案：这几年也有人在云上用Docker或Kubernetes部署Hadoop，社区有现成的镜像。但我的态度比较保守：如果团队没有丰富的K8s运维经验，不建议一上来就在容器里跑Hadoop。Hadoop本身对网络和存储的假设比较“重型”，容器化后会引入很多额外的复杂性和排障成本。有那精力，不如先把裸机/虚机上的部署做好。
7.2 成本优化，但不要省在关键节点上
大数据集群在云上的账单不小，很多团队为了省钱，会从DataNode规格上动手。DataNode确实可以适当降低CPU规格，因为磁盘IO和网络带宽往往才是瓶颈。但有两块不能省：
一是NameNode和ResourceManager等主节点，它们的稳定性直接影响整个集群，配置尽可能高一些，磁盘尽量用SSD云盘。
二是不管哪个节点，都要设置好云磁盘的定期快照。快照本身有少量费用，但能换来“误删数据、配置损坏、集群起不来”时的快速回滚能力，这个投入我认为比买更高配置更值得。
7.3 维护一套“部署文档+检查脚本”
就我自己的习惯来说，集群越复杂，越要把所有部署执行过的命令、修改过的配置、特殊目录和端口整理成文档。不要依赖记忆，也不要只放在某一位同事的笔记本里。团队里任何一个人照着文档能完整搭出一套新集群时，你才真正把“部署”变成了“可复制的能力”。
再配合一个简单的巡检脚本，定期检查：所有节点磁盘空间、NameNode安全模式状态、DataNode在线数、YARN运行节点数、关键端口开放状态。把这些输出到一个文件里，哪天集群表现不对劲，先看巡检记录就成功了一半。
云上跑Hadoop，和物理机最大的不同，可能就是你既要懂Hadoop本身，又要懂云平台那些“看起来不相关”的基础设施规则。这篇文章里写的每一条，都是从实际部署和故障排查里长出来的经验，照着走能帮你少走很多弯路。