企业官网建设流程全解析

简介：这份资源是VMware vSphere 6.7 HA环境搭建的完整实战文档，面向虚拟化运维工程师、系统架构师及企业IT规划人员，系统梳理了在多台ESXi主机与vCenter组成的实验环境中构建高可用集群的完整流程。资源为单个docx文档，大小约2.36MB，正文按“环境介绍—网络配置—部署过程—HA测试—问题记录”组织，具体涵盖管理/vMotion/存储/生产网络的多网段划分、标准交换机与分布式交换机配置、基于FreeNAS的iSCSI存储挂载、虚拟机创建及端口组绑定等内容，并配有截图与参数说明。HA测试章节包含迁移测试和模拟物理故障测试，问题记录环节也汇总了常见踩坑点与解决思路。当前已有728人学习，适合需要快速掌握从规划到落地的全套配置步骤、或为生产环境高可用改造做技术储备的虚拟化人员。

1. 接了台没被子机保护的 vSphere 6.7，先从 HA 说起

如果你维护的虚拟化环境里只有一台 ESXi 主机，宕机一次就是全部虚拟机关闭，那接下来的内容对你就是刚需。vSphere HA 解决的是「物理主机真正挂掉之后，虚拟机怎么自动在别的宿主上重新起来」这件事：不等管理员从床上爬起来手动开机，而是由集群里的另一台主机按预设策略接管全部虚拟机，把 RTO 从小时级压到分钟级。这篇笔记围绕 VMware vSphere 6.7 环境里的 HA 搭建展开，从 HA 的故障判定机制、部署前置条件，到 vCenter 6.7 上创建 HA 集群的详细步骤，再到握手过程中常见的翻车点和排查方法，最后给出可操作的故障演练方案。适合刚接手 vSphere 环境、准备上「虚拟机自动故障切换」的运维和虚拟化实施工程师。

2. HA 在 6.7 里怎么判定故障：FDM、两类心跳与隔离地址

2.1 HA 的 FDM 怎么选主，以及备代理什么时候接管

vSphere HA 在每台加入集群的 ESXi 主机上装一个叫 FDM（Fault Domain Manager）的代理。你可以在 SSH 登录主机后看到它的状态，它对应的进程叫 fdm，包名一般显示为 vSphere HA Agent。FDM 之间会通过选举机制推举出一个主代理（active master），主代理持有整个集群的资源清单、虚拟机位置和故障切换策略。你可以把主代理理解成整个 HA 体系的大脑，所有故障判定都由它来下结论，而不是由每台主机自己乱猜。

备代理平时只做两件事：接收主代理的心跳，定期同步集群状态。一旦主代理进程崩溃或者和 vCenter 失去连接，备代理会自动接管。这里有个容易误会的点：很多人以为主代理一定在 vCenter 所在的 ESXi 上，其实不是，主代理是从集群所有节点里自动挑出来的，选主依据是主机健康度和网络连通性，你不需要也无法手工指定，完全由 FDM 自己搞定。查看当前哪台是主代理，可以登录任意一台主机看 FDM 日志，也可以用下面的命令确认代理是否在运行：

# 登录任意一台 ESXi 主机（SSH），检查 FDM 进程是否存在 /etc/init.d/vmware-fdm status # 查看 FDM 进程行，确认代理已加载 esxcli software list | grep -i fd # 主代理与备代理的日志都在这条路径下 tail -100 /var/log/vmware/fdm/fdm.log

/etc/init.d/vmware-fdm status如果返回 running，说明 HA 代理已经在这台 ESXi 上正常工作了。日志路径/var/log/vmware/fdm/fdm.log是后续排查故障判定最关键的入口，后面讲隔离和误判时你会反复用到它。esxcli 的软件列表主要用来核对 HA 代理组件是否装上，不过大多数情况下你不用去手动装它，vCenter 把主机加入 HA 集群时会自动下发。

2.2 管理网络心跳和存储心跳怎么配合，什么时候算主机故障

6.7 的 HA 心跳分两路：管理网络心跳和存储心跳，缺一路和缺两路的判定结果完全不同。管理网络心跳是 FDM 之间通过管理网络发送的探活包，频率很高，通常每秒一次。存储心跳则是主代理在共享数据存储里的.vSphere-HA目录写入一个心跳文件，各主机持续读写这个文件来证明自己还活着。这样设计的意图很清晰：如果一台主机只是管理网断了，但存储还能读写，它不一定是死了，只是「被隔离」；如果管理网络和存储同时不可达，那基本可以断定主机真的宕了。

具体判定逻辑展开讲大概是这样的。主代理在一定时间内收不到某台主机的心跳包，会先尝试和这台主机通信，如果管理和存储心跳都超时，直接判定为主机故障，进入故障切换流程，在该主机上运行的虚拟机被标记为需要重新启动。如果管理网络心跳断了，但存储心跳还能持续写入，FDM 会先把这台主机标记为「隔离」，并触发隔离响应，默认动作是「保持电源状态」，也就是虚拟机不关机、也不迁移，等着管理员恢复网络。这个细节极其重要，下面有一节专门说默认隔离响应坑人的地方。

再补充一点，存储心跳是写在共享数据存储上的，不是本地存储。如果集群里只有本地磁盘，HA 的心跳文件无处落盘，集群会持续报错，甚至拒绝启用 HA。所以共享存储是硬前提，不管是 iSCSI、NFS 还是 Fibre Channel，必须让集群里的主机访问到同一份存储。检查主机的存储心跳文件可以这样看：

# 列出当前主机的所有 VMFS 卷 esxcli storage filesystem list # 通过 vmkfstools 看共享存储信息 vmkfstools -P -v1 /vmfs/volumes/你的存储名 # 进入 HA 心跳文件目录，确认文件正在生成 ls -la /vmfs/volumes/你的存储名/.vSphere-HA/

正常情况下，.vSphere-HA目录里会有一个以主机 ID 命名的 heartbeat 文件，并且文件时间戳持续更新。如果这个目录不存在或者文件不更新，说明该主机没参与存储心跳，需要去集群设置里检查。

2.3 两个默认参数的效果：隔离响应保持电源，虚拟机监控默认只看着

6.7 的 HA 集群默认配置里，有两个参数我认为值得每个部署者提前理解，因为它们直接决定了整个集群「看着像开着 HA，实际保护效果却差一大截」。第一个是隔离响应，默认是「保持电源状态」。这句话的实际意思是：当主机被判定为隔离（管理网断了、存储心跳还在），HA 不会对这台主机上的虚拟机做任何操作，虚拟机继续跑在已经断网的主机上，直到你人工介入。默认这样设定其实是有意的，因为主机还活着，强行重启虚拟机可能造成双写或者数据损坏。但对大多数业务来说，一台断网的主机等于对外不可用，保持电源状态意味着业务黑洞，必须有人发现并手动处理。

第二个参数是「虚拟机监控」，默认是「仅监控」，不做响应。它监控的是虚拟机内部的 VMware Tools 心跳和存储 I/O 延迟。仅监控模式下，即使检测到虚拟机卡死或者存储无响应，HA 也不做任何动作，只上报事件。生产环境里如果想把「虚拟机卡死自动重启」也交给 HA 托管，需要手动改成「监控并响应」，响应的默认动作是重置虚拟机。但这里有个经典坑：VMCP（Virtual Machine Component Protection）对存储故障非常敏感，存储阵列抖动几秒就可能触发大量虚拟机被重置，很多团队第一次开启后被打得措手不及，所以这个参数我一般建议先在仅监控状态观察两到三周，让存储和虚拟机的基线数据跑出来再决定要不要开响应。改这个参数的路径是：集群 → 配置 → 服务 → vSphere HA → 编辑 → 虚拟机监控。

3. 搭 HA 之前先做这五项检查：版本许可、网络、时间、存储与证书

3.1 版本与许可：免费版 ESXi 没有 HA，别踩这个空

在动手建集群之前，先确认你手上的许可到底支不支持 HA。vSphere HA 属于 vSphere Standard 及以上版本的功能，免费版 ESXi 以及仅购买了 vSphere Essentials 的低配许可都不包含 HA 模块。这个问题看起来基础，但在实际项目里我见过不止一次：客户拿免费版 ESXi 做了两台主机，试图开 HA，集群创建成功后 vCenter 直接提示该功能的许可证不可用。另一个容易忽略的是 vCenter Server 本身必须是 6.7 版本，如果你还在用 5.5 或 6.0 的 vCenter 管理 6.7 的 ESXi，HA 配置界面和事件信息会有差异，比如部分高级参数不生效。所以第一步，先登录 vCenter 的许可页面，确认集群里每一台 ESXi 都分配了正确的许可证。

检查许可的命令行方式也有，在 vCenter Web Client 里点「管理 → 许可」即可看到所有主机状态，如果你更习惯用命令行，也可以在 ESXi 上执行：

# 查看当前 ESXi 的许可证属性 esxcli system license list

输出里如果看到License Name是 Free 或者 Essentials，那就要先解决许可问题再往下走。另外要提醒的是，vCenter 自身的虚拟机要不要放进 HA 集群保护，算是个经典选择题。放进集群之后，一旦 vCenter 所在的主机故障，HA 会尝试把 vCenter 的虚拟机一起重启，但重启过程里 vCenter 是断的，集群状态和故障切换能力的可见性会暂时丢失。更稳妥的做法是给 vCenter 这台虚拟机单独配置主机反亲和规则，让它落在另一台独立主机上，或者干脆用 vCenter HA（Active/Passive/Witness）方案保护 vCenter 自身，这个后面最后一章再展开说。

3.2 DNS 与 NTP 的关键作用：6.7 的 HA 代理很依赖名字和时间

HA 代理的安装和主代理选举都非常依赖 DNS 解析，而且要求正反向解析都能通。很多 HA 代理一直处于「正在安装」状态，查到最后都是主机名解析问题。具体来说，vCenter 解析每台 ESXi 的主机名应该得到管理 IP，ESXi 解析自己的主机名也应该得到管理 IP，两个方向都不能指向别的地址。如果你们公司 DNS 是外部托管的，有临时解析抖动，我建议直接在 vCenter 和所有 ESXi 的/etc/hosts里互相写死记录，别让 HA 的选主过程被 DNS 超时拖死。检查主机名和解析的命令如下：

# 查看当前 ESXi 的主机名 esxcli system hostname get # 查看 /etc/hosts 内容 cat /etc/hosts # 测试 vCenter 主机名的双向解析 getent hosts vcenter.example.com

再一个就是 NTP。6.7 的 HA 对时间偏差的容忍度很低，主机与 vCenter 之间时间差太大会直接导致 HA 代理无法启动，表现是集群里主机显示「vSphere HA Agent 不可访问」。我一般要求所有 ESXi 和 vCenter 的时间偏差保持在 5 秒以内，最好都指向同一个 NTP 源。这里有个容易被忽略的坑：很多人给 ESXi 配置了 NTP，但忘了 vCenter 自身的时区或时钟源有偏移，两边各走各的，集群时间永远对不齐。检查 NTP 的同步状态可以这样查：

# 查看 NTP 服务状态 esxcli system ntp get # 立即强制同步时间 esxcli system ntp set --server=ntp.example.com --enabled=true # 查看当前时间和时区 date -R

提示：如果 ESXi 本身没有配置 NTP 客户端，也请不要主动用date命令手工调时间，直接改 NTP 源之后等待系统自动同步，手工改时间会干扰 HA 心跳文件的时间戳校验。

3.3 对照一份可抄的前置条件清单，逐项打勾

下面是一张我在每次 HA 部署前都会逐项检查的清单，直接照着抄即可。注意这是「硬性条件」，不符合的话别急着建集群，先逐条解决再继续。

这张表里的「隔离地址」和「根目录空间」是最容易被忽略的，前者会导致 HA 误判，后者会导致 HA 心跳文件写不进去。特别是根目录空间，我看到很多 ESXi 因为/var/log长期不清理，根分区被撑到 90% 以上，然后 HA 代理神秘罢工，问题定位时往往先想到网络和存储，最后才发现是磁盘满。建议把根分区监控纳入日常告警，低于 4GB 就提前清理日志或者扩展分区容量。

4. 用 vCenter 6.7 创建 HA 集群的完整过程：从新建集群到故障切换演练

4.1 创建集群并勾选 vSphere HA / DRS：选项这样填才算有效

打开 vCenter Web Client 后，在数据中心上右键 → 新建集群。6.7 的界面里会有三个跟 HA 有关的选项：vSphere HA、vSphere DRS、vSphere EVC。如果你需要的是「主机故障后虚拟机自动迁移复活」，这里勾选 vSphere HA 是必须的；同时建议一起勾上 vSphere DRS，两个功能配合起来效果更好：HA 负责故障判定和重启虚拟机，DRS 负责正常情况下的负载均衡。vCenter 6.7 部署 HA 和 DRS 属于最常见的一对组合，我基本每次建集群都会同时开，否则后续主机负载不均还得手动迁移虚拟机。

DRS 的自动化级别，我建议先用「半自动」，等运行稳定后改成「全自动」。半自动模式下 DR S 只给出迁移建议不自动执行，比较适合第一次上集群、还没摸清工作负载特性的阶段。对话框里的 EVC 模式可以先不开，它主要用于跨代 CPU 的 vMotion 兼容性，和 HA 没有直接关系，开了反而可能限制主机的 CPU 特性集。

点击确定后集群创建完成，接下来要把 ESXi 主机加入集群。添加主机的过程比较简单，选中集群 → 右键 → 添加主机，输入主机 IP、账号密码，vCenter 会校验证书并建立连接。全部主机加入后，回到集群的「配置 → 服务 → vSphere HA」页面，确认状态显示「已启用」。如果这里显示红色感叹号或者「配置错误」，后面的步骤就不用继续了，先回第 3 章逐项排查前置条件。

4.2 套用这套参数：隔离响应、接入控制、心跳数据存储与隔离地址

集群创建好以后，编辑 vSphere HA 设置的窗口里有一堆参数，很多第一次接触的人不知道该怎么选。我根据不同业务线总结过一套比较稳妥的参数组合，可以直接抄：

隔离响应这里我想再强调一下。6.7 默认是「保持电源状态」，我建议生产环境改成「关闭虚拟机电源并重启」，因为管理网断了意味着业务网络大概率也断了，虚拟机留在原地对用户没有任何价值，不如尽快在其他主机上重启副本。当然你也要想清楚双写场景：如果原主机只是管理网断、业务网还能通，强制重启会造成同一份数据有两个写入方，后果只能由业务侧来权衡。所以更稳妥的做法是：先改隔离地址让误判率降低，再开「关闭虚拟机电源并重启」。

数据存储心跳这里也有讲究。默认「自动选择可用数据存储」在大存储池里可能出现全部心跳落在一个存储上的情况，一旦这个存储阵列故障，整个集群的心跳全断，后果很严重。手工指定两个物理位置不同的共享存储是更稳的选法。特别注意：不要选本地存储作为心跳，也不要只勾一个存储，否则这个存储一旦离线，HA 判定逻辑直接失效。

最后是隔离地址的配置，这一步很多人会漏掉。进入集群 → 配置 → 服务 → vSphere HA → 编辑 → 网络 → 管理网络，在 IPv4 设置里找到「VMware HA 隔离地址」，默认只有一个网关地址。建议额外添加一个真实可达的内网 IP，比如内网 DNS 服务器的地址，这样即使网关因为策略禁 ping 或者短暂抖动，HA 也有第二个地址可以用来判断主机是否真正隔离。

4.3 故障切换演练：拔网线能触发隔离，强制断电才能触发故障切换

集群配置完成后，强烈建议做一次真实的故障演练，不要等到生产宕机才第一次看 HA 的反应。演练目标主机选一台没有重要业务的测试虚拟机所在的主机，尽量别拿生产主机做首次实验。第一步，先把 vCenter 虚拟机移到另一台物理主机上，或者至少确认 vCenter 不在演练目标主机上面，否则 vCenter 随着主机断电，你会失去整个集群的观察视角。

演练方式有两种：拔出管理网线，模拟的是「网络隔离」场景；强制断电，模拟的是「主机故障」场景。两者触发路径完全不同，建议分开测。拔网线后，观察集群事件会先出现「主机与隔离地址断开」，然后主机进入「已隔离」状态，隔离响应触发，虚拟机按策略在其他主机重启。强制断电后，管理网络和存储心跳几乎同时丢失，主代理判定为主机故障，虚拟机重启流程走的路径会更快。两种场景做完后，检查集群事件里的时间轴，记下从故障发生到虚拟机在新主机上开始启动的间隔，这就是你能对外承诺的 RTO 基线。

下面的命令可以在演练前后用来抓取 HA 的判定记录：

# 查看 FDM 日志里的隔离与故障事件 grep -i "isolation\|host failed\|restart" /var/log/vmware/fdm/fdm.log # 查看 vCenter 的 HA 相关任务记录 vim-cmd vimsvc/task_info # 检查虚拟机当前所在主机 vim-cmd vmsvc/getallvms

grep的几条关键字能帮你快速定位判定事件。getallvms输出的最后一列就是虚拟机当前宿主，演练后对比前后变化，确认虚拟机确实完成了跳变。

5. 常见问题与排查：HA 代理起不来、主机被误判隔离、虚拟机被误重置

5.1 HA 代理一直初始化中，日志里的 fdm 进程反复退出

这是 HA 部署里出现频率最高的问题：集群里主机显示「vSphere HA Agent 正在安装」或「代理不可访问」，下方任务进度长时间卡住。SSH 登录主机后看/var/log/vmware/fdm/fdm.log，一般能看到 fdm 进程启动后立刻退出，或者反复重启。

原因通常有三类，按概率排：第一是 DNS 解析不通，vCenter 反查不到主机名，FDM 选主失败；第二是时间偏差过大，主机和 vCenter 的时间差超过证书或认证的容忍阈值；第三是 ESXi 根分区空间不足，FDM 无法创建自己的状态目录。排查顺序很固定，先看时间和空间，再看 DNS。

# Step1：检查根分区剩余空间 df -h # Step2：检查时间偏差 date -R # Step3：反查主机名是否被正确解析 getent hosts $(hostname) # Step4：看 FDM 日志尾部，重点看报错代码 tail -200 /var/log/vmware/fdm/fdm.log

根据根因做对应处理：空间不足就清理/var/log下的旧日志；时间偏差就修正 NTP 并强制同步一次；DNS 解析失败就在/etc/hosts里补记录。全部完成后回到 vCenter，先移除 HA 再重新启用，强迫代理重新安装，比手动重启 fdm 服务要干净。

5.2 网关禁 ping，整个集群把主机误判成「已隔离」

一个非常经典的翻车现场：某天某台主机管理网络只是发生了轻微波动，但很快恢复，vCenter 里却立刻冒出大量「主机与隔离地址断开」的 HA 事件，所有虚拟机都停在原地，没有一台自动切换。原因就是 HA 默认用网关作为隔离地址，而你们的网络管理员在防火墙上把 ICMP 给禁了。HA 探活收不到网关响应，误认为主机已经与外界隔离，于是触发隔离响应。如果隔离响应改成了「关闭虚拟机电源并重启」，这里还会直接造成虚拟机被强行重启，损失更大。

治本的办法就两条：一是在集群的网络设置里给隔离地址追加一个真正可达且不回 ICMP 的地址，比如内网 DNS 的 IP；二是让网络团队开放管理网段到网关的 ICMP 权限。如果你无法影响网络策略，推荐用前者，成本最低。另外补充一个细节：6.7 的 FDM 在双击隔离地址时会尝试解析主机名，如果地址不能反解成名字，一些版本会因为这个解析超时延长判定时间，所以追加地址时尽量用 IP，不要用手工主机名。

5.3 “vSphere HA 心跳数据存储”异常：根目录被日志占满

共享存储和心跳文件都正常，但集群状态页持续显示「vSphere HA 心跳数据存储」问题。这时候去检查每台 ESXi 的根分区，大概率已经爆满。原因是 ESXi 的根目录只有几十 GB，大量日志、vobd 告警和 HA 代理历史文件堆积后，根目录剩余空间低于 2GB，HA 心跳文件就无法正常写入，FDM 会一直报存储异常。

解决分两步。第一步临时释放空间：清理/var/log下早期的*.gz日志，或者用esxcli system syslog clean直接清空 syslog。第二步是根上治理：把 syslog 配置到远端日志服务器，别让 ESXi 本地无限堆积；同时设置 HA 心跳数据存储的选择策略，让它只落在容量足够的共享存储上。

# 查看根分区占用 df -h # 查看 syslog 目录占的空间最大文件 du -sh /var/log/* # 清空旧日志 esxcli system syslog clean

提示：清理/var/log的时候不要直接rm -f正在被进程写的小文件，容易让句柄失效，优先用truncate或者系统自带清理命令。

5.4 HA 故障切换资源不足：接入控制策略与预留资源写的不对

集群里有两台 32GB 内存的主机，每台虚拟机的内存预留都设得很大，启用 HA 之后 vCenter 报警「资源不足，无法满足 HA 故障切换容量」。这个报错的原因非常直白：HA 接入控制会预先保留一台主机的故障切换资源，当你虚拟机的内存预留总和接近或超过另一台主机的空闲资源时，系统认为「万一这台主机挂了，没有足够资源装下它上面的虚拟机」，因此拒绝提供完整保护。

解决方式有三种。第一，把接入控制策略从「允许一台主机故障」改成百分比模式，保留的容量按主机总资源比例计算，比如 25%，可用的容量会变大，但保护强度会下降。第二，调整虚拟机的内存预留，让它们更贴近实际占用而不是预留一大半。第三，直接加一台同配置的主机进集群，从物理上扩大冗余空间。还有一个小技巧：接入控制策略里的「预留内存」指的是「主机故障时需要腾出的内存空间」，如果你把虚拟机的所有内存都设成预留，等于任何一台虚拟机都要整块内存空余才满足条件，很容易把整个集群的空间绑死。

5.5 vSphere Client 证书过期后的应急登录与后续处理

ESXi 或者 vCenter 的证书过期后，最直接的现象是 vSphere Client 网页提示证书无效，连接被浏览器拦截，然后你连 vCenter 都进不去，更别说处理 HA 状态。更隐蔽的是 vCenter 与 ESXi 之间的通信会因为证书校验失败而中断，HA 代理从 vCenter 视角看会突然全部变成红色。这个场景最考验应急能力，我一般这样处理：先用浏览器的「继续前往」忽略证书警告的方式登录进去，再在 vCenter 的证书管理页面重新生成证书。

在 6.7 里，vCenter 内置的证书管理界面支持重新生成证书，路径是「系统管理 → 证书 → 证书管理」，选到过期的证书点「续订」即可。ESXi 主机的证书过期则需要登录每台 ESXi 的本地管理界面重新生成：

# 在 ESXi 上重新生成证书 /sbin/generate-certificates # 重启管理服务使证书生效 /etc/init.d/vpxa restart /etc/init.d/fdm restart

这个处理顺序很重要：先在 vCenter 里续订，然后再处理 ESXi 主机的证书，否则 vCenter 和主机互相校验还是会失败。证书这个问题在生产环境里两年爆发一次，建议在 vCenter 里设置证书过期提醒，提前一个月续订，别等到 HA 事件刷屏才意识到出事。

6. 通过故障演练把 HA 从“能搭通”变成“带得回”：验证接入控制与 RTO

6.1 演练设计：先保 vCenter 自身的高可用，再拔电

故障演练最好有一个固定剧本，别临时起意。我的习惯是每个月做一次，每次只用一台主机，且演练前先把 vCenter 的虚拟机和演练目标主机加一条反亲和规则，确保 vCenter 不被选中迁移到故障主机上。如果你连 vCenter 都还没有做任何保护，那第一次演练就相当于给自己找事，vCenter 断掉后整个观察窗口全瞎。更稳妥的方案是先给 vCenter 启用 vCenter HA，这样演练过程中即使 vCenter 所在主机被意外波及，也还有一个备用的 vCenter 实例帮你盯着集群状态。

演练步骤建议固定在四步内：第一步，在 vCenter 里检查 HA 状态全部正常；第二步，确认目标主机上运行的虚拟机清单，优先选测试虚拟机或低优先级业务；第三步，直接拔电源（不要用 shutdown，优雅关机会让 HA 认为主机正常下线而不触发故障切换）；第四步，观察集群事件、记录虚拟机重启完成时间。

6.2 从 fdm.log 提炼故障时间线，验证 RTO

故障切换完成以后，不要只看虚拟机有没有起来，要把时间线扒出来，这份数据才是你之后做容量规划和给业务承诺 RTO 的依据。具体看fdm.log里这样几条关键日志：主机失联时间、主代理判定故障的时间、虚拟机被调度到目标主机的时间、虚拟机开始启动的时间。这四段时间相减，就是一次完整故障切换的开销。

# 演练后抓取本轮故障时间线 grep "HostMonitor\|restart\|failover" /var/log/vmware/fdm/fdm.log | tail -50 # 查看目标主机的虚拟机启动情况 vim-cmd vmsvc/getallvms

如果时间线里「主机失联到判定故障」超过了一两分钟，去检查主机的 HA 心跳数据存储选的哪个，以及隔离地址的 ICMP 是否真的可达；如果「虚拟机开始启动」的时间和判定时间差距过大，多半是目标主机资源不足，虚拟机排队等待 CPU 或内存预留，这时候就需要回头调整接入控制策略了。演练结束后的最后一件事是把主机加回集群，等 HA 代理重新注册后再离开。

我个人的习惯是也把一次演练里误触发、误判的时间线截图存起来，每次调完参数都做一次对比，长期积累下来的数据比任何厂商宣讲都可靠。希望这篇 HA 搭建笔记能帮你少走点弯路，也祝你第一次拔电演练就顺利跑通。

本文还有配套的精品资源，点击获取