从零构建高可用分布式存储：vSAN架构解析与实战部署指南

1. 项目概述：从单机存储到共享资源池的跨越

如果你管理过几台独立的ESXi主机，肯定遇到过这样的场景：A主机上的虚拟机磁盘空间告急，而B主机上却有大把的闲置存储。传统的做法要么是手动迁移虚拟机，要么是挂载昂贵的共享存储（如SAN），过程繁琐且成本不菲。vSAN的出现，就是为了解决这个痛点。简单来说，ESXi vSAN整合多主机磁盘这个项目，其核心目标就是将集群内每台物理服务器自带的本地硬盘（包括SSD和HDD）聚合起来，形成一个统一、高性能、高可用的分布式存储资源池。这不再是简单的磁盘堆叠，而是一次存储架构的革新。它让每一台ESXi主机在贡献存储的同时，也能从整个池中按需分配，实现了真正的“我为人人，人人为我”。对于从中小型环境到大规模数据中心的运维人员、架构师而言，掌握vSAN意味着能用更低的成本构建出媲美高端存储的敏捷基础设施，无论是部署新的业务系统，还是应对突发的存储需求，都能做到心中有底，手中有术。

2. vSAN架构深度解析：不只是磁盘聚合

很多人初次接触vSAN，容易把它想象成一个“网络RAID”，但这远远不够。vSAN是一种深度融合在VMware超融合架构中的软件定义存储（SDS）解决方案。它的精妙之处在于，将存储控制逻辑从专用硬件中抽离，并以分布式系统的方式运行在每一台ESXi主机上。

2.1 核心组件与数据流动

理解vSAN，首先要搞清楚几个关键角色。在一个vSAN集群中，每台主机上的本地磁盘被划分为两个层次：缓存层和容量层。缓存层通常由高性能的NVMe或SAS SSD担当，用于存放热点数据和写入缓冲；容量层则由大容量的SSD或HDD组成，用于持久化存储数据。vSAN通过一种名为磁盘组（Disk Group）的逻辑单元来管理这些物理磁盘。一个磁盘组必须包含至少一块缓存盘和一块或多块容量盘。所有主机上的磁盘组共同构成了vSAN数据存储。

数据是如何被保护和分布的呢？这依赖于存储策略（Storage Policy Based Management, SPBM）。当你创建虚拟机磁盘时，不再是选择具体的LUN或数据存储，而是为其附加一个存储策略。这个策略定义了诸如“允许的故障数（FTT=1）”、“条带宽度（Stripe Width=2）”、“对象空间预留（Thin/Thick）”等属性。vSAN的底层系统——分布式对象存储——会根据策略自动将数据对象（如VMDK文件）分解成多个组件（Component），并通过网络将这些组件以冗余副本或纠删码（ESA架构）的形式分布到集群中不同主机、不同磁盘组的磁盘上。例如，一个FTT=1的策略，会为数据创建两个副本，分别存放在两台不同的主机上。这种机制确保了即使单台主机、单个磁盘甚至整块磁盘故障，数据依然可用且可自动重建。

2.2 两种架构选型：OSA与ESA

这是vSAN设计时必须做出的关键抉择，直接决定了性能上限、硬件要求和运维模式。

混合架构（Original Storage Architecture, OSA）：这是vSAN的传统架构，也是目前应用最广泛的模式。它严格依赖磁盘组的缓存分层设计。所有写入操作都先进入缓存层的SSD，随后再异步降级到容量层的HDD或SSD。读取时，如果是热点数据，则从缓存读取；否则从容量层读取。这种架构的优势是对硬件要求相对宽松，可以利用现有的HDD来扩充巨大容量，成本效益高。但它也受限于缓存盘的性能和容量，并且写延迟会受到容量盘（尤其是HDD）性能的影响。

注意：在OSA架构中，缓存盘是绝对的性能命脉和单点故障源。一块缓存盘故障，会导致其所在的整个磁盘组失效。因此，务必为缓存盘选择企业级高耐久度的SSD，并确保硬件RAID控制器（如果使用）处于直通（Passthrough）或HBA模式。

全闪存架构（Express Storage Architecture, ESA）：这是vSAN 7.0 U1及以后版本引入的现代架构。它取消了专用的缓存层概念，集群中所有磁盘都是性能一致的NVMe或SATA/SAS SSD。数据保护和性能优化不再依赖于缓存分层，而是通过高效的纠删码（Erasure Coding）和先进的算法来实现。ESA能提供更低、更一致的延迟，更高的吞吐量，并且支持新的存储策略功能（如去重和压缩可以同时开启）。其硬件要求更高，需要所有主机都配备至少25 GbE或更快的网络，并且磁盘必须全是SSD。

如何选择？如果你的环境追求极致的性能和最低的延迟，且预算允许全部采用SSD，那么ESA是未来方向。如果你的环境容量需求巨大，希望利用现有HDD控制成本，或者网络基础设施尚未升级到25GbE以上，那么成熟的OSA混合架构是更稳妥的选择。对于首次部署，我通常建议从OSA开始，因为它更易于理解和排错，硬件生态也更成熟。

3. 实战部署：从零构建一个vSAN集群

理论说得再多，不如动手搭一遍。下面我将以一个包含三台ESXi主机的集群为例，演示vSAN OSA架构的完整部署流程。假设每台主机已安装好ESXi 7.0 U3，并配置了万兆网络互通，每台主机有1块800GB SSD（作缓存）和2块4TB HDD（作容量）。

3.1 前期准备与硬件检查

部署前的准备工作至关重要，许多后期诡异的问题都源于前期的不规范。

1. 网络配置：vSAN对网络有严格要求。你需要为vSAN流量专门创建一个VMkernel网络适配器。确保所有主机上的vSAN VMkernel端口位于同一子网，并且启用vSAN流量服务。多播（早期版本）或单播（6.6及以后）通信必须畅通。使用esxcli network ip connection list命令或通过vCenter的“网络健康检查”来验证主机间网络延迟（应<1ms）和带宽。
2. 磁盘格式与模式：这是最容易出错的一步。用于vSAN的磁盘必须处于**“未配置”状态**，并且由ESXi直接管理。如果服务器有硬件RAID卡，务必将其设置为JBOD模式或直通（Passthrough）模式，让ESXi看到每一块物理磁盘，而不是一个RAID虚拟卷。在ESXi主机的存储设备列表中，确认磁盘显示为“本地设备”或“SSD/HDD”，而不是“VMFS”或“已分区”。
3. vCenter Server：vSAN必须通过vCenter Server进行集中管理和配置。确保你有一个正常运行的vCenter Server实例（可以是嵌入式或外部部署的PSC），并且所有ESXi主机都已加入其数据中心。

3.2 创建集群并启用vSAN

登录vSphere Client，进入你的数据中心。

1. 右键点击数据中心，选择“新建集群”。
2. 为集群命名（如VSAN-Cluster-Prod），务必勾选“打开vSAN”选项。其他如DRS（分布式资源调度）和HA（高可用性）也建议一并启用，它们与vSAN能完美协同。
3. 将准备好的三台ESXi主机拖拽或添加到这个新建的集群中。

现在，进入集群的“配置”->“vSAN”->“服务”页面。点击“配置”按钮，启动配置向导。

• 第一步：选择架构。我们选择“混合”。
• 第二步：声明磁盘。这是核心步骤。系统会自动扫描集群中所有主机上可用的磁盘。你需要为每台主机手动或自动将磁盘分配到缓存层和容量层。
  • 手动声明：对于生产环境，我强烈建议手动声明。在主机列表下，展开每台主机，你会看到可用的磁盘。将那块800GB SSD拖拽到“缓存层”区域，将两块4TB HDD拖拽到“容量层”区域。这个操作需要逐台主机进行。
  • 自动声明：适用于测试或非常标准的硬件环境，但生产环境慎用。
• 第三步：配置网络。确认每台主机用于vSAN流量的VMkernel适配器选择正确。
• 第四步：确认配置。检查摘要，特别是磁盘分配情况。确认无误后，点击“完成”。

配置过程会自动进行，包括格式化磁盘、创建磁盘组、初始化vSAN数据存储。你可以在“监控”->“vSAN”->“虚拟对象”中观察后台数据同步的进度。

3.3 配置存储策略与创建虚拟机

vSAN数据存储创建好后，你会发现它和普通数据存储外观无异，但内涵完全不同。接下来就是应用存储策略的时刻。

1. 创建存储策略：进入“策略和配置文件”->“虚拟机存储策略”。点击“创建”。

   • 名称：VSAN-Policy-Gold-RAID1
   • 规则集1：在“vSAN”下，设置“允许的故障数”为1（这意味着需要至少3台主机，保存2个数据副本）。
   • 规则集1：设置“每个对象的磁盘带数”为1（默认即可，如需更高性能可设为2，但会占用更多容量）。
   • 规则集1：设置“对象空间预留”为0%（精简置备）或100%（厚置备）。
   • 点击“确定”保存策略。

2. 部署虚拟机：像往常一样创建新虚拟机或迁移现有虚拟机。当进行到“选择存储”步骤时，选择我们创建的vSAN数据存储。关键的一步来了：在“虚拟机存储策略”下拉菜单中，选择我们刚刚创建的VSAN-Policy-Gold-RAID1。这意味着这个虚拟机的所有磁盘都将遵循FTT=1的策略，在集群中自动保存两份副本。

部署完成后，你可以右键点击虚拟机，选择“策略和配置文件”->“管理虚拟机存储策略”，来验证其磁盘对象是否合规。也可以在vSAN监控界面，看到这个虚拟机的VMDK对象被分解成多个组件，分布在不同主机的磁盘上。

4. 日常运维、扩容与故障处理实录

vSAN上线只是开始，日常运维才是保证其稳定运行的关键。这里分享几个高频操作和踩过的坑。

4.1 容量管理与性能监控

vSAN是一个“用空间换可靠性和性能”的系统，因此容量规划至关重要。

• 监控仪表板：经常查看“监控”->“vSAN”->“容量”视图。这里会清晰展示已用容量、可用容量、闪存读/写缓存命中率、去重与压缩节省空间等。务必关注“已用容量”不要超过“已用容量阈值”（通常为80%），否则会影响性能和重建操作。
• 性能监控：使用“性能”选项卡，关注“每台主机延迟”、“吞吐量”和“IOPS”。如果发现某台主机延迟异常高，可能是磁盘故障、网络问题或该主机负载过重的信号。
• 扩容操作：当容量不足时，扩容非常灵活。你可以：
  1. 向现有磁盘组添加容量盘：如果主机有空的磁盘槽位，可以直接将新磁盘标记为“容量”角色，并添加到现有磁盘组。操作在线进行，对业务无影响。
  2. 为主机添加新的磁盘组：如果主机有更多SSD和HDD，可以创建第二个、第三个磁盘组来增加该主机的容量和性能贡献。
  3. 向集群添加新主机：这是最彻底的扩容方式，不仅能增加容量和性能，还能提高集群的冗余度。新主机加入集群后，在vSAN配置中声明其磁盘即可。

4.2 常见故障场景与排查心法

vSAN的自动化程度高，但出了问题，排查思路必须清晰。

场景一：vSAN集群显示“降级”或“不存在”状态。这是最常见的问题。首先去“监控”->“vSAN”->“物理磁盘”视图，检查是否有磁盘显示为“异常”或“脱机”。

• 如果是单个容量盘故障：vSAN会自动利用其他副本重建数据到健康磁盘上。此时集群状态为“降级但合规”。你需要做的是尽快物理更换故障磁盘。更换后，新磁盘会被自动识别并重新加入到磁盘组，开始重建数据。
• 如果是缓存盘故障：这是严重事件！在OSA架构下，会导致整个磁盘组失效。集群状态会严重告警。你必须立即更换缓存盘。更换后，需要手动重新创建磁盘组，并等待vSAN从其他副本重建该磁盘组上的所有数据。因此，缓存盘的质量和监控至关重要。

场景二：虚拟机存储策略“不合规”。这意味着vSAN无法满足你为虚拟机设定的策略要求。最常见的原因是主机或磁盘故障导致冗余度不足。例如，一个FTT=1的策略需要2个副本，但如果集群中只剩2台主机健康，它就无法将两个副本放在不同的故障域（主机）上，从而导致不合规。解决方法要么是修复故障主机，要么是临时修改虚拟机存储策略（降低FTT），待主机恢复后再改回来。

场景三：性能突然下降。

• 检查网络：使用ping和vmkping命令检查主机间vSAN网络延迟和丢包。网络是vSAN的血液。
• 检查磁盘负载：在ESXi命令行使用esxtop，按d进入磁盘视图，观察DAVG/cmd（设备延迟）和KAVG/cmd（内核延迟）是否过高。高延迟可能指向磁盘瓶颈。
• 检查去重与压缩：如果开启了去重和压缩，在数据重构或高负载时，可能会消耗大量CPU资源。评估是否需要在业务高峰时段暂时关闭。

4.3 磁盘更换实操步骤（以更换故障容量盘为例）

1. 确认故障：在vCenter中，确认磁盘状态为“异常”或“脱机”，且vSAN正在其他组件上重建数据。
2. 物理更换：将服务器下电（或在支持热插拔的情况下直接操作），拔掉故障硬盘，插入同型号或vSAN兼容性列表中的新硬盘。
3. 标记磁盘：服务器上电后，在ESXi存储设备中，新磁盘可能显示为“未格式化”或“SSD/HDD”。不要手动格式化！
4. 在vSAN中声明：进入集群的vSAN配置页面，“磁盘管理”选项卡。找到对应主机，你应该能看到新磁盘处于“符合磁盘组资格”状态。将其拖拽到原先故障盘所属的磁盘组的“容量”区域。
5. 自动重建：vSAN会自动将新磁盘纳入磁盘组，并开始将之前重建的临时数据（可能在其他磁盘的预留空间）迁移回新磁盘，最终恢复完全冗余状态。整个过程在后台静默完成，你可以在“正在重新同步的组件”中观察进度。

5. 高级优化与规划建议

当基本功能稳定后，可以考虑一些优化措施来提升效率或应对更复杂的场景。

利用存储策略实现服务分级：不要只用一个存储策略。你可以创建多个策略，例如：

• VSAN-Policy-Platinum-RAID1：FTT=2（需要至少5台主机，3个副本），用于核心数据库。
• VSAN-Policy-Silver-RAID5：FTT=1，但使用RAID-5/6纠删码（ESA或OSA 7.0 U1后支持），在保证冗余的同时，提供更高的存储利用率，用于一般应用服务器。
• VSAN-Policy-Bronze：FTT=0（无冗余），仅用于绝对非关键的测试或临时环境。 在部署虚拟机时按需选择，实现精细化的成本与性能控制。

延伸集群（Stretched Cluster）与双活：对于有容灾需求的场景，vSAN支持配置延伸集群。将主机分布在两个机房（站点），并配置一个独立的见证主机（通常放在第三个站点或云端）。这样，虚拟机可以跨站点运行，实现站点级故障切换。这需要精心的网络设计（站点间链路要求高带宽、低延迟）和更复杂的故障域配置。

与备份方案的集成：vSAN本身不是备份方案。务必使用专业的备份软件（如Veeam, Commvault等）对vSAN上的虚拟机进行定期备份。确保你的备份软件版本支持vSAN，并且备份代理或存储库不要部署在vSAN数据存储本身，以免形成循环依赖。

最后，我个人最深刻的一个体会是：vSAN将存储的复杂性从采购和硬件配置阶段，转移到了软件策略设计和日常监控阶段。它给予了你前所未有的灵活性，但也要求你更深入地理解数据分布、冗余策略和性能特征。每一次存储策略的调整，都像在下一盘棋，需要通盘考虑容量、性能和可靠性。多花时间在测试环境中模拟各种故障，熟悉监控告警，你的vSAN之旅就会从容许多。