1. 项目概述一次真实的vSAN实战压力测试最近在实验室里折腾了一套基于Vsphere 7.0 Update 3的vSAN集群目的很纯粹就是想看看这个版本的vSAN在实际生产模拟环境下的表现到底怎么样。很多朋友可能对vSAN有所耳闻知道它是VMware推出的超融合架构软件能把多台服务器的本地硬盘“攒”成一个高性能、高可用的共享存储池。但纸上得来终觉浅尤其是在7.0u3这个承上启下的版本它修复了不少早期问题也引入了一些新特性不亲手搭起来跑一跑心里总没底。这次测试我不仅会记录下从零搭建的全过程更会模拟一些“不那么友好”的场景比如节点故障、网络抖动、磁盘重建看看vSAN的韧性和恢复能力究竟如何。如果你正在评估虚拟化存储方案或者打算升级现有的vSAN环境这篇从一线踩坑得来的实录或许能给你一些直接的参考。2. 测试环境设计与核心思路拆解2.1 硬件选型与拓扑规划这次测试没有使用顶级的商业硬件而是选用了三台配置相同的x86服务器目的就是为了验证在通用硬件上vSAN的兼容性和稳定性。每台服务器配备了双路CPU、128GB内存最关键的是存储部分每台机器有两块480GB的SATA SSD用作缓存层四块1.92TB的NVMe SSD用作容量层另外还有一块独立的SATA SSD用于安装ESXi系统。网络方面每台服务器配备了两张双端口的10Gb以太网卡我们将其配置为用于vSAN流量的专用网络与管理网络、vMotion网络物理隔离这是保证vSAN性能与稳定性的黄金法则。为什么选择三节点这是vSAN集群允许的最小配置也是成本与冗余的平衡点。三节点集群允许一台主机故障Fault Tolerance 1同时能形成一个有效的决策多数派避免“脑裂”问题。在规划时我特别注意了磁盘组的配置一个磁盘组由一块缓存盘必须为SSD和一到七块容量盘组成。我的设计是每台主机创建两个磁盘组每个组包含一块缓存SSD和两块容量NVMe SSD。这样做的好处是万一某块缓存盘故障只会影响其所在磁盘组内的容量盘另一个磁盘组依然可用实现了故障域的隔离比将所有容量盘挂载到单一缓存盘下更稳健。2.2 软件版本与许可考量我们选择的是Vsphere 7.0 Update 3 (Build 20036589)。这个版本在vSAN方面有几个重要的改进比如对ESAvSAN Express Storage Architecture架构的增强支持、更高效的空间回收机制以及监控界面的优化。不过本次测试我们仍然采用传统的OSAOriginal Storage Architecture架构因为这是目前最广泛部署的模型。关于许可证这是一个无法回避的话题。vSAN功能需要独立的许可证授权在vSphere Client中你需要进入“集群”-“配置”-“vSAN”-“服务”中分配许可证。测试环境可以使用评估版它有60天的全功能使用期。务必注意许可证密钥是与vSAN集群的容量总量即所有容量层硬盘的总原始容量挂钩的在分配时系统会进行校验。如果未来扩容需要确保许可证的容量上限足够。2.3 测试目标与核心场景定义本次测试绝非简单的“点亮”就算成功我设定了几个层层递进的目标基础功能验证成功创建vSAN集群、数据存储并能在其上流畅创建、运行虚拟机。性能基准测试使用I/O测试工具如HCIBench或简单的FIO对vSAN数据存储进行顺序读写、随机读写测试获取IOPS、吞吐量和延迟的基线数据。故障恢复测试重头戏这是检验vSAN“成色”的关键。计划模拟以下场景主机完全故障直接关闭一台ESXi主机电源观察集群状态、虚拟机迁移如果启用了HA以及数据重建过程。磁盘故障在运行中热拔插一块容量SSD模拟磁盘损坏。观察vSAN如何标记组件降级并如何利用剩余节点上的空间开始重建数据。网络分区通过防火墙规则临时阻断一台主机在vSAN网络上的通信模拟网络闪断或隔离观察集群的响应和对象健康状态的变化。3. vSAN集群部署与配置实操要点3.1 ESXi主机安装与基础配置首先在三台物理服务器上安装ESXi 7.0 U3。安装过程比较常规但有几个细节需要注意系统盘选择务必安装在我们预留的那块独立SATA SSD上绝不能安装在计划用于vSAN缓存或容量的磁盘上否则后续无法将这些磁盘加入vSAN。主机名与IP为每台主机规划并设置固定的IP地址、主机名如esxi-01.vsanlab.local。管理网络、vSAN网络、vMotion网络最好使用不同的IP网段并在安装后于“网络”-“VMkernel网卡适配器”中逐一创建并绑定到对应的物理网卡上。为vSAN流量创建的VMkernel适配器必须启用“vSAN流量”服务。NTP配置所有ESXi主机必须保持时间同步这是vSAN以及vSphere HA、DRS等很多功能正常工作的基石。在每台主机的“配置”-“时间配置”中指向一个可靠的NTP服务器。注意在配置vSAN专用网络时确保三台主机之间的vSAN网络IP是二层互通的即在同一广播域且网络延迟低于1毫秒这是VMware的硬性建议。我通常会用vmkping命令在主机间互ping大包来测试网络质量和MTU如果启用巨帧。3.2 创建集群与启用vSAN创建集群在vCenter中创建一个新的数据中心然后在该数据中心下创建一个集群。在创建集群的向导中先不要勾选“打开vSAN”。我们将集群命名为“VSAN-Cluster-Test”。添加主机将三台配置好的ESXi主机逐一添加到这个集群中。配置vSAN服务进入集群的“配置”-“vSAN”-“服务”页面点击“配置”。选择架构在配置向导中选择“标准集群”和“单站点集群”。对于磁盘声明我选择了“手动”模式这让我能更精确地控制哪块盘用作缓存哪块用作容量。声明磁盘这是最关键的一步。系统会列出集群中所有未使用的磁盘。你需要为每台主机手动将对应的SSD根据序列号或大小识别拖拽到“缓存层”和“容量层”区域。务必反复确认缓存盘是性能更好的那批SSD。声明完成后vSAN会自动格式化这些磁盘并创建磁盘组。配置网络确保vSAN网络选择我们之前创建的、启用了vSAN流量的VMkernel适配器所在的端口组。完成检查摘要确认无误后点击完成。vSAN集群开始初始化你可以在“监控”-“vSAN”-“运行状况”中查看进度。初始化和数据同步会持续一段时间取决于磁盘大小和数量。3.3 创建第一台虚拟机与存储策略初探集群就绪后会自动生成一个名为“vsanDatastore”的数据存储。现在我们可以像使用任何其他共享存储一样使用它。创建虚拟机右键集群或主机新建虚拟机。在选择存储时选中“vsanDatastore”。你会注意到在虚拟机创建向导的后期有一个“vSAN存储策略”的选项。理解存储策略这是vSAN的精髓所在。存储策略将应用需求如允许的故障数、性能、加密等翻译成vSAN底层的存储对象布局。默认策略是“RAID-1镜像”允许的故障数为1FTT1。这意味着你的虚拟机数据会被复制成两份或更多取决于策略分布在不同的主机和磁盘上。应用与验证我们先用默认策略创建一台Windows或Linux测试机。创建完成后可以在虚拟机的“摘要”-“vSAN”部分看到其存储对象的详细布局例如“组件2个见证1个”这正符合FTT1的预期——两份数据组件加一个用于仲裁的见证组件三者分布在三台不同的主机上。4. 性能基准测试与结果分析4.1 测试工具与方法论为了获得有意义的性能数据我选择在vSAN数据存储上创建一台专用的测试虚拟机。给该VM配置了足够的vCPU如8核和内存如16GB并为其虚拟磁盘配置“厚置备延迟置零”模式以消除首次写入的性能开销。测试工具使用FIOFlexible I/O Tester因为它功能强大且可高度定制。我设计了四组主要测试场景每组运行至少300秒以消除波动4K随机读模拟数据库OLTP操作。fio --namerandread --ioenginelibaio --rwrandread --bs4k --numjobs4 --size10G --runtime300 --time_based --group_reporting4K随机写模拟日志写入。fio --namerandwrite --ioenginelibaio --rwrandwrite --bs4k --numjobs4 --size10G --runtime300 --time_based --group_reporting1M顺序读模拟大文件读取、视频流。fio --nameseqread --ioenginelibaio --rwread --bs1M --numjobs2 --size10G --runtime300 --time_based --group_reporting1M顺序写模拟数据备份、大数据写入。fio --nameseqwrite --ioenginelibaio --rwwrite --bs1M --numjobs2 --size10G --runtime300 --time_based --group_reporting4.2 测试结果与解读以下是在三节点全闪存配置下使用默认存储策略FTT1得到的近似结果测试场景平均IOPS平均带宽平均延迟4K 随机读~120,000~470 MB/s~0.33 ms4K 随机写~40,000~160 MB/s~0.98 ms1M 顺序读~3,200~3.2 GB/s~0.62 ms1M 顺序写~1,800~1.8 GB/s~1.1 ms结果分析随机读性能出色这得益于全闪存介质和vSAN分布式架构数据可以从多个节点并行读取。延迟控制在亚毫秒级对于大多数关键应用来说非常理想。随机写有损耗写操作由于FTT1的策略需要跨网络写入两份数据并等待确认因此IOPS和延迟相比读操作有显著差距。这是保障数据冗余必须付出的代价。顺序吞吐量可观大块顺序读写能有效利用网络带宽10GbE x 2达到了网卡的理论瓶颈说明vSAN在处理大数据流时效率很高。缓存的作用在持续写入测试中初期性能会非常高写入缓存但当缓存写满或需要刷入容量层时性能会有一个阶梯式下降并趋于稳定。测试时运行足够长时间就是为了捕捉这个稳定期的性能。实操心得性能测试一定要结合业务模型。如果你的应用以随机读为主如VDI启动风暴这个配置游刃有余。如果以随机写为主如高频交易日志可能需要考虑更高性能的缓存盘如NVMe SSD或调整存储策略如开启去重和压缩但会消耗CPU。在vSAN监控的“性能”视图中可以清晰地看到缓存命中率、后端读写延迟等关键指标它们是性能调优的重要依据。5. 高可用与故障恢复实战演练5.1 模拟主机故障这是最经典的测试场景。我首先确保集群的vSphere HA功能已开启。然后在一台运行着测试虚拟机的主机假设为esxi-02上直接长按电源按钮强制关机。观察与现象vCenter告警几乎立刻vCenter中弹出“主机无响应”的严重告警。虚拟机状态运行在esxi-02上的虚拟机大约在30秒取决于HA的检测时间和重启设置后开始在集群中的另一台主机esxi-01或esxi-03上自动重启。这是因为HA检测到主机故障触发了虚拟机的故障转移。vSAN状态进入“监控”-“vSAN”-“运行状况”会看到“组件状态”出现降级警告。原来位于esxi-02上的数据组件和见证组件变为“不存在”或“已降级”。vSAN会立即开始重新同步过程利用剩余两台主机上的副本为所有受影响的对象重新生成一份新的副本以满足FTT1的策略要求。数据存储访问在整个过程中vsanDatastore始终可访问。其他主机上的虚拟机运行完全不受影响体现了真正的共享存储特性。恢复过程将esxi-02主机重新加电启动。它重新加入集群后vSAN会自动将其纳入并可能触发新一轮的数据平衡将部分组件迁移回这台主机以优化数据分布。5.2 模拟容量磁盘故障这次我们通过vSphere Client对一台主机上的一块容量NVMe SSD执行“擦除分区并移除磁盘”的操作模拟磁盘故障。观察与现象磁盘组降级该磁盘所在的磁盘组状态会变为“降级”。该磁盘组内的其他容量盘仍可访问但已失去冗余保护。组件重建vSAN会计算受影响的数据对象并立即开始在其他主机的空闲空间上重建这些对象的副本组件。你可以在“运行状况”-“重新同步组件”中看到重建任务和进度。性能影响重建过程会消耗网络和磁盘I/O资源可能会对集群的整体性能产生一定影响。vSAN 7.0U3引入了更智能的流量控制可以限制重建带宽减少对生产业务的影响。更换磁盘物理更换故障磁盘后在存储设备列表中找到新磁盘可以将其“添加到存储”中并选择“向磁盘组添加磁盘”。vSAN会将其格式化并加入原有磁盘组随后可能进行数据重新平衡。注意事项vSAN的故障处理是对象级别的。一个虚拟机由多个对象如命名空间、VMDK组成。一个磁盘故障只会影响存储在该磁盘上的那些对象的组件而不是整个虚拟机。重建也是针对这些缺失的组件进行的因此恢复速度通常比传统RAID重建整个磁盘要快。5.3 模拟vSAN网络中断为了测试网络的韧性我在其中一台主机esxi-01的vSAN VMkernel端口组关联的虚拟交换机上添加了一条防火墙规则临时丢弃所有vSAN流量端口12321和23451等。观察与现象集群分区esxi-01与其他两台主机失去了vSAN网络连接。vSAN会检测到网络分区。此时拥有多数组件2台主机的分区esxi-02和esxi-03会继续提供服务。而处于少数派的主机esxi-01上的虚拟机如果其对象组件多数不在本机可能会因无法访问仲裁而停止运行如果启用了HA则可能被重启到多数派分区。对象健康状态在vSAN运行状况中可能会看到“集群分区”和“组件状态”告警。位于esxi-01上的组件会显示为“已隔离”。恢复当网络恢复后隔离的主机会重新加入集群vSAN会同步隔离期间错过的数据更新使所有组件恢复一致状态。这个过程是自动的。这个测试深刻说明了专用、冗余vSAN网络的重要性。在实际生产中必须为vSAN配置至少两个独立的物理网卡进行捆绑NIC Teaming并连接到不同的物理交换机以避免单点故障。6. 日常运维与问题排查心法6.1 关键监控指标与告警设置vSAN内置了非常全面的监控体系。除了前面用到的“运行状况”和“性能”视图以下几个地方是日常巡检的重点运行状况检查这是一个自动化检查清单涵盖硬件兼容性、网络配置、磁盘状态、集群配置等数十个项目。任何一项失败或警告都需要立即关注。我习惯每天上班第一件事就是扫一眼这里。容量监控在“监控”-“vSAN”-“容量”中可以清晰看到集群总容量、已用容量、瘦置备开销、去重压缩节省空间等。务必设置容量使用率的告警阈值例如80%提前规划扩容。性能服务如果启用了性能服务需要额外开启可以获得更细粒度的虚拟机、磁盘甚至单个对象的性能历史数据对于定位性能瓶颈至关重要。Skyline Health这是集成在vCenter中的健康诊断工具能提供更主动的问题分析和修复建议。6.2 常见问题速查与解决思路即使配置得当在生产中也可能遇到各种问题。以下是我总结的一些常见情况及其排查思路问题现象可能原因排查步骤与解决方法vSAN数据存储不可用或显示为“非vSAN”1. 集群vSAN服务未开启或异常。2. 所有主机vSAN网络中断。3. 磁盘组全部故障或离线。1. 检查集群“配置”-“vSAN”-“服务”状态。2. 在每台主机上用esxcli vsan network list命令检查vSAN网络接口状态并用vmkping测试主机间连通性。3. 检查每台主机的存储设备确认磁盘组是否在线。虚拟机创建失败提示“没有兼容的存储”1. 存储策略要求无法满足如FTT1但只有2台主机。2. 数据存储剩余空间不足考虑精简置备和策略开销。1. 检查虚拟机存储策略确保其允许的故障数FTT小于等于当前集群的容错能力N个主机最大FTT为N-1。2. 检查vSAN容量视图确保有足够的物理空间和对象空间。vSAN性能突然下降1. 正在进行后台数据重建或重新同步。2. 某台主机或磁盘组性能瓶颈。3. 网络拥塞或丢包。1. 检查“重新同步组件”和“重新平衡”任务。2. 使用性能视图逐台主机、逐个磁盘组对比吞吐量和延迟定位瓶颈点。3. 检查vSAN网络端口的丢包计数和状态。磁盘显示为“已隔离”或“错误”1. 物理磁盘故障。2. 磁盘控制器或线缆问题。3. 驱动程序或固件不兼容。1. 在主机硬件日志中确认磁盘SMART错误。2. 尝试将磁盘插到另一槽位或另一台主机判断是盘问题还是槽位/控制器问题。3. 检查VMware兼容性指南确保HBA卡驱动和磁盘固件版本在支持列表内。6.3 扩容与升级注意事项横向扩容增加主机这是增加计算和存储资源最直接的方式。将新主机加入集群后在vSAN配置中声明其磁盘vSAN会自动将新存储纳入数据池并可能触发数据重新平衡使数据分布更均匀。增加主机后集群的容错能力也可能随之提升例如从3节点FTT1升级到4节点可以配置FTT1且允许一个主机和一个磁盘同时故障的策略。纵向扩容增加磁盘在主机有空余磁盘槽位时可以向现有磁盘组添加容量盘或创建新的磁盘组。添加新容量盘操作相对安全对运行中业务影响很小。版本升级从7.0 U3升级到更高版本如8.0务必遵循VMware的互操作性矩阵和升级路径。通常顺序是先升级vCenter Server再升级ESXi主机建议逐台置于维护模式并迁移虚拟机后升级。vSAN本身会在第一台主机升级后自动进行磁盘格式升级这是一个不可逆的过程升级前必须做好完整备份和回滚计划。经过这一轮从搭建、压测到“破坏性”演练的完整流程我对Vsphere 7.0u3的vSAN有了更立体的认识。它的核心价值在于将企业级存储的可用性和管理性以一种高度集成、软件定义的方式交付并且能随着通用x86服务器的扩展而线性增长。全闪存配置下的性能足以应对绝大多数企业工作负载而基于存储策略的管理模式真正实现了以应用为中心的自动化。然而它并非“黑盒”魔法。其稳定运行的背后是对硬件兼容性、网络架构和运维规范的严格要求。任何一个环节的短板都可能成为整个系统的瓶颈。这次测试中遇到的网络模拟故障就再次强调了冗余网络设计的重要性。对于打算部署vSAN的团队我的建议是前期规划的时间至少应占总项目时间的40%仔细核对兼容性列表设计好网络和故障域并在上线前进行充分的、模拟真实故障的测试。只有理解了它的运作机制和边界才能让vSAN在的生产环境中稳定、高效地运行。
vSAN实战压力测试：从搭建到故障演练的全流程解析
1. 项目概述一次真实的vSAN实战压力测试最近在实验室里折腾了一套基于Vsphere 7.0 Update 3的vSAN集群目的很纯粹就是想看看这个版本的vSAN在实际生产模拟环境下的表现到底怎么样。很多朋友可能对vSAN有所耳闻知道它是VMware推出的超融合架构软件能把多台服务器的本地硬盘“攒”成一个高性能、高可用的共享存储池。但纸上得来终觉浅尤其是在7.0u3这个承上启下的版本它修复了不少早期问题也引入了一些新特性不亲手搭起来跑一跑心里总没底。这次测试我不仅会记录下从零搭建的全过程更会模拟一些“不那么友好”的场景比如节点故障、网络抖动、磁盘重建看看vSAN的韧性和恢复能力究竟如何。如果你正在评估虚拟化存储方案或者打算升级现有的vSAN环境这篇从一线踩坑得来的实录或许能给你一些直接的参考。2. 测试环境设计与核心思路拆解2.1 硬件选型与拓扑规划这次测试没有使用顶级的商业硬件而是选用了三台配置相同的x86服务器目的就是为了验证在通用硬件上vSAN的兼容性和稳定性。每台服务器配备了双路CPU、128GB内存最关键的是存储部分每台机器有两块480GB的SATA SSD用作缓存层四块1.92TB的NVMe SSD用作容量层另外还有一块独立的SATA SSD用于安装ESXi系统。网络方面每台服务器配备了两张双端口的10Gb以太网卡我们将其配置为用于vSAN流量的专用网络与管理网络、vMotion网络物理隔离这是保证vSAN性能与稳定性的黄金法则。为什么选择三节点这是vSAN集群允许的最小配置也是成本与冗余的平衡点。三节点集群允许一台主机故障Fault Tolerance 1同时能形成一个有效的决策多数派避免“脑裂”问题。在规划时我特别注意了磁盘组的配置一个磁盘组由一块缓存盘必须为SSD和一到七块容量盘组成。我的设计是每台主机创建两个磁盘组每个组包含一块缓存SSD和两块容量NVMe SSD。这样做的好处是万一某块缓存盘故障只会影响其所在磁盘组内的容量盘另一个磁盘组依然可用实现了故障域的隔离比将所有容量盘挂载到单一缓存盘下更稳健。2.2 软件版本与许可考量我们选择的是Vsphere 7.0 Update 3 (Build 20036589)。这个版本在vSAN方面有几个重要的改进比如对ESAvSAN Express Storage Architecture架构的增强支持、更高效的空间回收机制以及监控界面的优化。不过本次测试我们仍然采用传统的OSAOriginal Storage Architecture架构因为这是目前最广泛部署的模型。关于许可证这是一个无法回避的话题。vSAN功能需要独立的许可证授权在vSphere Client中你需要进入“集群”-“配置”-“vSAN”-“服务”中分配许可证。测试环境可以使用评估版它有60天的全功能使用期。务必注意许可证密钥是与vSAN集群的容量总量即所有容量层硬盘的总原始容量挂钩的在分配时系统会进行校验。如果未来扩容需要确保许可证的容量上限足够。2.3 测试目标与核心场景定义本次测试绝非简单的“点亮”就算成功我设定了几个层层递进的目标基础功能验证成功创建vSAN集群、数据存储并能在其上流畅创建、运行虚拟机。性能基准测试使用I/O测试工具如HCIBench或简单的FIO对vSAN数据存储进行顺序读写、随机读写测试获取IOPS、吞吐量和延迟的基线数据。故障恢复测试重头戏这是检验vSAN“成色”的关键。计划模拟以下场景主机完全故障直接关闭一台ESXi主机电源观察集群状态、虚拟机迁移如果启用了HA以及数据重建过程。磁盘故障在运行中热拔插一块容量SSD模拟磁盘损坏。观察vSAN如何标记组件降级并如何利用剩余节点上的空间开始重建数据。网络分区通过防火墙规则临时阻断一台主机在vSAN网络上的通信模拟网络闪断或隔离观察集群的响应和对象健康状态的变化。3. vSAN集群部署与配置实操要点3.1 ESXi主机安装与基础配置首先在三台物理服务器上安装ESXi 7.0 U3。安装过程比较常规但有几个细节需要注意系统盘选择务必安装在我们预留的那块独立SATA SSD上绝不能安装在计划用于vSAN缓存或容量的磁盘上否则后续无法将这些磁盘加入vSAN。主机名与IP为每台主机规划并设置固定的IP地址、主机名如esxi-01.vsanlab.local。管理网络、vSAN网络、vMotion网络最好使用不同的IP网段并在安装后于“网络”-“VMkernel网卡适配器”中逐一创建并绑定到对应的物理网卡上。为vSAN流量创建的VMkernel适配器必须启用“vSAN流量”服务。NTP配置所有ESXi主机必须保持时间同步这是vSAN以及vSphere HA、DRS等很多功能正常工作的基石。在每台主机的“配置”-“时间配置”中指向一个可靠的NTP服务器。注意在配置vSAN专用网络时确保三台主机之间的vSAN网络IP是二层互通的即在同一广播域且网络延迟低于1毫秒这是VMware的硬性建议。我通常会用vmkping命令在主机间互ping大包来测试网络质量和MTU如果启用巨帧。3.2 创建集群与启用vSAN创建集群在vCenter中创建一个新的数据中心然后在该数据中心下创建一个集群。在创建集群的向导中先不要勾选“打开vSAN”。我们将集群命名为“VSAN-Cluster-Test”。添加主机将三台配置好的ESXi主机逐一添加到这个集群中。配置vSAN服务进入集群的“配置”-“vSAN”-“服务”页面点击“配置”。选择架构在配置向导中选择“标准集群”和“单站点集群”。对于磁盘声明我选择了“手动”模式这让我能更精确地控制哪块盘用作缓存哪块用作容量。声明磁盘这是最关键的一步。系统会列出集群中所有未使用的磁盘。你需要为每台主机手动将对应的SSD根据序列号或大小识别拖拽到“缓存层”和“容量层”区域。务必反复确认缓存盘是性能更好的那批SSD。声明完成后vSAN会自动格式化这些磁盘并创建磁盘组。配置网络确保vSAN网络选择我们之前创建的、启用了vSAN流量的VMkernel适配器所在的端口组。完成检查摘要确认无误后点击完成。vSAN集群开始初始化你可以在“监控”-“vSAN”-“运行状况”中查看进度。初始化和数据同步会持续一段时间取决于磁盘大小和数量。3.3 创建第一台虚拟机与存储策略初探集群就绪后会自动生成一个名为“vsanDatastore”的数据存储。现在我们可以像使用任何其他共享存储一样使用它。创建虚拟机右键集群或主机新建虚拟机。在选择存储时选中“vsanDatastore”。你会注意到在虚拟机创建向导的后期有一个“vSAN存储策略”的选项。理解存储策略这是vSAN的精髓所在。存储策略将应用需求如允许的故障数、性能、加密等翻译成vSAN底层的存储对象布局。默认策略是“RAID-1镜像”允许的故障数为1FTT1。这意味着你的虚拟机数据会被复制成两份或更多取决于策略分布在不同的主机和磁盘上。应用与验证我们先用默认策略创建一台Windows或Linux测试机。创建完成后可以在虚拟机的“摘要”-“vSAN”部分看到其存储对象的详细布局例如“组件2个见证1个”这正符合FTT1的预期——两份数据组件加一个用于仲裁的见证组件三者分布在三台不同的主机上。4. 性能基准测试与结果分析4.1 测试工具与方法论为了获得有意义的性能数据我选择在vSAN数据存储上创建一台专用的测试虚拟机。给该VM配置了足够的vCPU如8核和内存如16GB并为其虚拟磁盘配置“厚置备延迟置零”模式以消除首次写入的性能开销。测试工具使用FIOFlexible I/O Tester因为它功能强大且可高度定制。我设计了四组主要测试场景每组运行至少300秒以消除波动4K随机读模拟数据库OLTP操作。fio --namerandread --ioenginelibaio --rwrandread --bs4k --numjobs4 --size10G --runtime300 --time_based --group_reporting4K随机写模拟日志写入。fio --namerandwrite --ioenginelibaio --rwrandwrite --bs4k --numjobs4 --size10G --runtime300 --time_based --group_reporting1M顺序读模拟大文件读取、视频流。fio --nameseqread --ioenginelibaio --rwread --bs1M --numjobs2 --size10G --runtime300 --time_based --group_reporting1M顺序写模拟数据备份、大数据写入。fio --nameseqwrite --ioenginelibaio --rwwrite --bs1M --numjobs2 --size10G --runtime300 --time_based --group_reporting4.2 测试结果与解读以下是在三节点全闪存配置下使用默认存储策略FTT1得到的近似结果测试场景平均IOPS平均带宽平均延迟4K 随机读~120,000~470 MB/s~0.33 ms4K 随机写~40,000~160 MB/s~0.98 ms1M 顺序读~3,200~3.2 GB/s~0.62 ms1M 顺序写~1,800~1.8 GB/s~1.1 ms结果分析随机读性能出色这得益于全闪存介质和vSAN分布式架构数据可以从多个节点并行读取。延迟控制在亚毫秒级对于大多数关键应用来说非常理想。随机写有损耗写操作由于FTT1的策略需要跨网络写入两份数据并等待确认因此IOPS和延迟相比读操作有显著差距。这是保障数据冗余必须付出的代价。顺序吞吐量可观大块顺序读写能有效利用网络带宽10GbE x 2达到了网卡的理论瓶颈说明vSAN在处理大数据流时效率很高。缓存的作用在持续写入测试中初期性能会非常高写入缓存但当缓存写满或需要刷入容量层时性能会有一个阶梯式下降并趋于稳定。测试时运行足够长时间就是为了捕捉这个稳定期的性能。实操心得性能测试一定要结合业务模型。如果你的应用以随机读为主如VDI启动风暴这个配置游刃有余。如果以随机写为主如高频交易日志可能需要考虑更高性能的缓存盘如NVMe SSD或调整存储策略如开启去重和压缩但会消耗CPU。在vSAN监控的“性能”视图中可以清晰地看到缓存命中率、后端读写延迟等关键指标它们是性能调优的重要依据。5. 高可用与故障恢复实战演练5.1 模拟主机故障这是最经典的测试场景。我首先确保集群的vSphere HA功能已开启。然后在一台运行着测试虚拟机的主机假设为esxi-02上直接长按电源按钮强制关机。观察与现象vCenter告警几乎立刻vCenter中弹出“主机无响应”的严重告警。虚拟机状态运行在esxi-02上的虚拟机大约在30秒取决于HA的检测时间和重启设置后开始在集群中的另一台主机esxi-01或esxi-03上自动重启。这是因为HA检测到主机故障触发了虚拟机的故障转移。vSAN状态进入“监控”-“vSAN”-“运行状况”会看到“组件状态”出现降级警告。原来位于esxi-02上的数据组件和见证组件变为“不存在”或“已降级”。vSAN会立即开始重新同步过程利用剩余两台主机上的副本为所有受影响的对象重新生成一份新的副本以满足FTT1的策略要求。数据存储访问在整个过程中vsanDatastore始终可访问。其他主机上的虚拟机运行完全不受影响体现了真正的共享存储特性。恢复过程将esxi-02主机重新加电启动。它重新加入集群后vSAN会自动将其纳入并可能触发新一轮的数据平衡将部分组件迁移回这台主机以优化数据分布。5.2 模拟容量磁盘故障这次我们通过vSphere Client对一台主机上的一块容量NVMe SSD执行“擦除分区并移除磁盘”的操作模拟磁盘故障。观察与现象磁盘组降级该磁盘所在的磁盘组状态会变为“降级”。该磁盘组内的其他容量盘仍可访问但已失去冗余保护。组件重建vSAN会计算受影响的数据对象并立即开始在其他主机的空闲空间上重建这些对象的副本组件。你可以在“运行状况”-“重新同步组件”中看到重建任务和进度。性能影响重建过程会消耗网络和磁盘I/O资源可能会对集群的整体性能产生一定影响。vSAN 7.0U3引入了更智能的流量控制可以限制重建带宽减少对生产业务的影响。更换磁盘物理更换故障磁盘后在存储设备列表中找到新磁盘可以将其“添加到存储”中并选择“向磁盘组添加磁盘”。vSAN会将其格式化并加入原有磁盘组随后可能进行数据重新平衡。注意事项vSAN的故障处理是对象级别的。一个虚拟机由多个对象如命名空间、VMDK组成。一个磁盘故障只会影响存储在该磁盘上的那些对象的组件而不是整个虚拟机。重建也是针对这些缺失的组件进行的因此恢复速度通常比传统RAID重建整个磁盘要快。5.3 模拟vSAN网络中断为了测试网络的韧性我在其中一台主机esxi-01的vSAN VMkernel端口组关联的虚拟交换机上添加了一条防火墙规则临时丢弃所有vSAN流量端口12321和23451等。观察与现象集群分区esxi-01与其他两台主机失去了vSAN网络连接。vSAN会检测到网络分区。此时拥有多数组件2台主机的分区esxi-02和esxi-03会继续提供服务。而处于少数派的主机esxi-01上的虚拟机如果其对象组件多数不在本机可能会因无法访问仲裁而停止运行如果启用了HA则可能被重启到多数派分区。对象健康状态在vSAN运行状况中可能会看到“集群分区”和“组件状态”告警。位于esxi-01上的组件会显示为“已隔离”。恢复当网络恢复后隔离的主机会重新加入集群vSAN会同步隔离期间错过的数据更新使所有组件恢复一致状态。这个过程是自动的。这个测试深刻说明了专用、冗余vSAN网络的重要性。在实际生产中必须为vSAN配置至少两个独立的物理网卡进行捆绑NIC Teaming并连接到不同的物理交换机以避免单点故障。6. 日常运维与问题排查心法6.1 关键监控指标与告警设置vSAN内置了非常全面的监控体系。除了前面用到的“运行状况”和“性能”视图以下几个地方是日常巡检的重点运行状况检查这是一个自动化检查清单涵盖硬件兼容性、网络配置、磁盘状态、集群配置等数十个项目。任何一项失败或警告都需要立即关注。我习惯每天上班第一件事就是扫一眼这里。容量监控在“监控”-“vSAN”-“容量”中可以清晰看到集群总容量、已用容量、瘦置备开销、去重压缩节省空间等。务必设置容量使用率的告警阈值例如80%提前规划扩容。性能服务如果启用了性能服务需要额外开启可以获得更细粒度的虚拟机、磁盘甚至单个对象的性能历史数据对于定位性能瓶颈至关重要。Skyline Health这是集成在vCenter中的健康诊断工具能提供更主动的问题分析和修复建议。6.2 常见问题速查与解决思路即使配置得当在生产中也可能遇到各种问题。以下是我总结的一些常见情况及其排查思路问题现象可能原因排查步骤与解决方法vSAN数据存储不可用或显示为“非vSAN”1. 集群vSAN服务未开启或异常。2. 所有主机vSAN网络中断。3. 磁盘组全部故障或离线。1. 检查集群“配置”-“vSAN”-“服务”状态。2. 在每台主机上用esxcli vsan network list命令检查vSAN网络接口状态并用vmkping测试主机间连通性。3. 检查每台主机的存储设备确认磁盘组是否在线。虚拟机创建失败提示“没有兼容的存储”1. 存储策略要求无法满足如FTT1但只有2台主机。2. 数据存储剩余空间不足考虑精简置备和策略开销。1. 检查虚拟机存储策略确保其允许的故障数FTT小于等于当前集群的容错能力N个主机最大FTT为N-1。2. 检查vSAN容量视图确保有足够的物理空间和对象空间。vSAN性能突然下降1. 正在进行后台数据重建或重新同步。2. 某台主机或磁盘组性能瓶颈。3. 网络拥塞或丢包。1. 检查“重新同步组件”和“重新平衡”任务。2. 使用性能视图逐台主机、逐个磁盘组对比吞吐量和延迟定位瓶颈点。3. 检查vSAN网络端口的丢包计数和状态。磁盘显示为“已隔离”或“错误”1. 物理磁盘故障。2. 磁盘控制器或线缆问题。3. 驱动程序或固件不兼容。1. 在主机硬件日志中确认磁盘SMART错误。2. 尝试将磁盘插到另一槽位或另一台主机判断是盘问题还是槽位/控制器问题。3. 检查VMware兼容性指南确保HBA卡驱动和磁盘固件版本在支持列表内。6.3 扩容与升级注意事项横向扩容增加主机这是增加计算和存储资源最直接的方式。将新主机加入集群后在vSAN配置中声明其磁盘vSAN会自动将新存储纳入数据池并可能触发数据重新平衡使数据分布更均匀。增加主机后集群的容错能力也可能随之提升例如从3节点FTT1升级到4节点可以配置FTT1且允许一个主机和一个磁盘同时故障的策略。纵向扩容增加磁盘在主机有空余磁盘槽位时可以向现有磁盘组添加容量盘或创建新的磁盘组。添加新容量盘操作相对安全对运行中业务影响很小。版本升级从7.0 U3升级到更高版本如8.0务必遵循VMware的互操作性矩阵和升级路径。通常顺序是先升级vCenter Server再升级ESXi主机建议逐台置于维护模式并迁移虚拟机后升级。vSAN本身会在第一台主机升级后自动进行磁盘格式升级这是一个不可逆的过程升级前必须做好完整备份和回滚计划。经过这一轮从搭建、压测到“破坏性”演练的完整流程我对Vsphere 7.0u3的vSAN有了更立体的认识。它的核心价值在于将企业级存储的可用性和管理性以一种高度集成、软件定义的方式交付并且能随着通用x86服务器的扩展而线性增长。全闪存配置下的性能足以应对绝大多数企业工作负载而基于存储策略的管理模式真正实现了以应用为中心的自动化。然而它并非“黑盒”魔法。其稳定运行的背后是对硬件兼容性、网络架构和运维规范的严格要求。任何一个环节的短板都可能成为整个系统的瓶颈。这次测试中遇到的网络模拟故障就再次强调了冗余网络设计的重要性。对于打算部署vSAN的团队我的建议是前期规划的时间至少应占总项目时间的40%仔细核对兼容性列表设计好网络和故障域并在上线前进行充分的、模拟真实故障的测试。只有理解了它的运作机制和边界才能让vSAN在的生产环境中稳定、高效地运行。
