vSAN 高可用：可访问性与数据迁移两种类型的权衡

vSAN 里"主机突然宕机"和"手动进维护模式"是两回事，很多人把这两套逻辑混着算，一算就错。这篇把两个问题分开讲清楚：三台主机坏一台走的是哪套流程，以及四节点集群淘汰一台旧主机时该选"确保可访问性"还是"全部数据迁徙"。

一、故障场景和手动维护场景差在哪

先分清"意外故障"和"手动维护"的本质区别，两者触发方式和处理目标完全不同。

场景类型触发方式主机状态vSAN核心目的处理逻辑意外故障硬件或网络故障离线、不可恢复1. 优先保障虚拟机持续可用
2. 后台把数据修复到合规状态主动执行"故障检测→可用性保障→数据修复"手动维护管理员主动操作在线、可控制1. 按需要选择"临时保留数据"或"长期清空数据"
2. 避免维护期间业务中断需手动选择"确保可访问性"或"全量数据迁徙"

二、三台中坏一台时的处理逻辑

假设 3 台主机是"2 副本 + 1 见证"、FTT=1 的默认集群，一台突然故障，vSAN 分两步走，全程自动。

第一步：先保数据可用性

vSAN 会先判断故障主机上挂的是数据副本还是见证组件，再用剩余组件把业务托住：

• 情形一：故障主机是数据副本所在节点
  剩下 2 台里，一台存"另一份数据副本"，一台存"见证组件"。vSAN 用这份活着的副本加见证判断数据完整，虚拟机继续跑，一点不中断——2 副本只要还剩 1 个加 1 个见证，就满足 FTT=1 的可用性要求。
  
• 情形二：故障主机是见证组件所在节点
  剩下 2 台各存 1 份数据副本。vSAN 直接用这 2 个存活副本判断数据完整（此时不需要见证，2 副本本身已经能容忍丢 1 台），虚拟机同样无中断。
  

关键：这一步的目的是"不丢业务"，和"确保可访问性"里"优先保可用"的逻辑一致，但完全是 vSAN 主动触发的，不需要人工选——故障是突发的，系统必须第一时间兜底。

第二步：后台把数据修到合规状态

故障发生后，vSAN 会立刻在剩余 2 台主机里把缺失的组件补齐，注意不是"全量迁徙"，而是只补故障造成的那一块，最终让集群回到"2 副本 + 1 见证"的合规状态。

• 若故障主机是数据副本节点：vSAN 在剩余 2 台上从活着的副本复制一份新副本，补成 2 副本，同时保证见证正常（见证还在就保留，见证也挂了就新建）
  
• 若故障主机是见证组件节点：vSAN 在剩余 2 台上新建一个见证组件，补成"2 副本 + 1 见证"
  

修复有三个关键特点：

• 异步执行：修复在后台跑，优先级低于虚拟机 IO，不影响业务性能
  
• 增量修复：只复制缺失的组件，不是把全量数据挪一遍，速度更快
  
• 主动收敛：故障主机在修复完成前又上线了（比如临时断电后重启），vSAN 会先比对组件版本，只同步差异数据，避免重复修
  

三、为什么故障场景套用不了维护模式

简单说："确保可访问性"和"全量数据迁徙"是管理员对可控主机的主动选择，故障场景是 vSAN 对不可控主机的被动兜底，触发条件和目的都不一样。

• 故障场景没有"选择"的余地：主机突然离线，vSAN 来不及问管理员要哪种模式，只能按预设逻辑先保可用再补数据
  
• 修复范围不同：全量数据迁徙搬的是待维护主机上的所有数据，故障修复只补缺失的组件，比如故障主机上只有 1 个副本就只补这 1 个，其他无关数据一概不动
  
• 最终状态不同：维护模式的全量迁徙是让待维护主机清空数据，故障修复是让整个集群回到合规状态，不管故障主机后来有没有恢复
  

四、结论：三台坏一台算什么

3 台主机突然故障时，vSAN 走的是"主动保障可用性 + 后台修复数据"，它不属于手动维护时的任何一种模式：

• 第一步"保障可用性"，目的和"确保可访问性"一致（优先不中断业务），但完全自动
  
• 第二步"修复数据"，目的和"全量数据迁徙"的"补全组件"一致（最终让集群合规），但只补缺失部分，不是全量迁徙
  

整个过程不用人工干预，你只要在 vCenter 的"vSAN → 监控 → 数据修复"里看修复进度，等集群自己回到"2 副本 + 1 见证"的健康状态就行。

五、淘汰旧主机该选哪个模式

现在 2 台旧机 + 2 台新机，HA 和 vSAN 均衡都已经做了，要淘汰 1 台旧主机，进维护模式时推荐选"全部数据迁徙（Full Data Migration）"，不要选"确保可访问性（Ensure Accessibility）"。判断依据很直接：淘汰的本质是"永久移除"，必须把数据彻底清干净，才能保证集群长期稳定。

六、两种模式的核心区别

模式核心操作适用场景对淘汰旧主机的适配性确保可访问性只搬"不搬就会影响数据可用"的组件，允许部分数据组件继续留在待维护主机上。短期维护（比如 1-2 小时的硬件维修），修完主机还会重新进集群。❌ 不适合淘汰：旧主机将被永久移除，残留组件会变成"孤立组件"，导致存储策略长期不合规。全部数据迁徙强制迁走待维护主机上的所有 vSAN 数据组件（副本、见证、缓存等），确保主机上不残留任何 vSAN 数据。长期维护（主机退役、永久下线），主机不会再回到集群。✅ 适合淘汰：彻底清掉旧主机数据，避免后续集群因残留组件出现策略违规或数据管理混乱。

七、选全部数据迁徙的三个理由

• 避免孤立组件带来的长期风险
  淘汰旧主机等于它永久离开集群。选"确保可访问性"的话，旧机上会残留一部分数据组件（比如不影响当前可用性的副本或缓存），这些组件会变成孤立组件：
  
  
  
  • vSAN 会一直报"组件缺失"（旧主机已经不在，这些组件再也访问不到）
    
  • 后面集群一旦出故障，这些孤立组件可能导致修复失败（vSAN 会误以为"还有副本在"，实际已经不可用）
    
  • 长期占用 vSAN 的组件计数，干扰集群对"数据合规性"的判断（比如误判"已满足 2 副本"，实际有效副本不足）
    
  
  "全部数据迁徙"会把旧主机的 vSAN 数据一次清空，从根上避开上面这些坑。
  
  
• 保证集群一直满足存储策略 FTT=1
  4 节点集群默认策略是 FTT=1（允许坏 1 台），要满足"2 副本 + 1 见证"且组件分布在不同主机。
  
  
  
  • 淘汰 1 台旧机后集群变成 3 节点（1 旧 + 2 新），FTT=1 仍要满足
    
  • "全部数据迁徙"会把旧机上的组件迁到剩下 3 台，重新分布成"2 副本 + 1 见证"，新集群照样合规（可容忍 1 台主机故障）
    
  • 选"确保可访问性"可能导致组件集中到少数主机（比如 2 个副本都落在 1 台新机上），违反"副本分散"原则，容错能力反而下降
    
  
  
  
• 后续运维更省事，避免数据管理混乱
  旧主机淘汰后可能会被拆机、重装系统或挪作他用。要是有残留 vSAN 数据：
  
  
  
  • 旧主机万一意外重启并接回原网络，vSAN 可能误识别"残留组件"，造成数据版本冲突（同一份数据出现多个"有效副本"）
    
  • 运维人员还得手动清理孤立组件（走 RVC 命令或 vSAN 对象管理），白白增加操作成本
    
  
  "全部数据迁徙"一次性清干净，让旧主机"干净退场"，后面不用再管。
  
  

八、操作时的三条注意事项

• 迁之前查资源：确认剩下 3 台（1 旧 + 2 新）的 CPU、内存（接虚拟机）和存储容量（接迁移的组件）够用，别因为资源不够把迁移搞失败
  
• 迁过程中盯进度：在 vCenter 的"近期任务"里看"主机进入维护模式"和"vSAN 组件迁徙"的进度，出现"资源不足"告警时，可以临时把部分虚拟机迁到别的主机腾出资源
  
• 迁完验合规：旧主机移除后进 vSAN"监控 → 虚拟对象"，确认所有对象"状态正常"（没有缺失组件），而且每个对象的组件分布符合"2 副本 + 1 见证"（在"对象浏览器"里能看）
  

九、小结

淘汰旧主机的核心是"永久移除"，所以必须选"全部数据迁徙"——它通过彻底清掉旧主机的 vSAN 数据，保证剩下集群的存储策略合规、数据分布安全，也避开后续运维风险。本质是用"牺牲一段迁移时间（数据量大，迁移慢）"换"集群长期的稳定和可维护性"，跟"短期维护优先速度"的场景正好反过来。

编辑提示

动手前先把剩余主机的容量算够，迁完记得回"虚拟对象"页面核对一遍组件分布，别只盯着任务列表显示成功。