1. 从一个机柜说起为什么我开始啃超融合三年前我还在用传统三层架构维护一个中小规模的虚拟化集群三台服务器加一台磁盘阵列外加两台光纤交换机。每次扩容都像做一场外科手术先算控制器端口够不够再算阵列的IOPS余量然后纠结新买的服务器HBA卡和旧交换机能不能握手。直到有一次客户机房搬迁一台存储控制器在运输途中出了故障整个集群停了六个小时我才下定决心认真研究超融合基础设施。超融合最直观的价值就是把计算、存储、网络这三个原本各自为政的层揉进同一个资源池里。你不再需要单独规划存储网络、不再需要为LUN的容量和性能做复杂的映射扩容的时候往集群里加一台标准节点就行。听起来很美好但真正落地的时候坑一点都不少。我前后在测试环境里折腾了将近两个月从硬件选型到网络规划从存储策略到故障演练踩过的坑足够写一本小册子。这篇笔记主要面向两类人一类是刚接触超融合、准备做POC验证的运维工程师另一类是用过传统虚拟化、但对分布式存储和vSAN这类技术心里没底的同行。我会把整个学习路径拆成几个阶段从底层原理到实操配置再到故障排查尽量把每个决策背后的逻辑讲清楚。你不需要有超融合基础但最好对虚拟化和基础网络有一定了解这样读起来会更顺畅。2. 超融合到底融了什么核心概念拆解2.1 从传统架构到超融合的演进逻辑传统架构里计算和存储是分离的。服务器通过HBA卡或者iSCSI适配器连接到外置存储阵列存储阵列负责RAID保护、缓存加速、快照复制这些功能。这种模式的好处是存储资源可以独立扩展坏处是架构复杂、成本高、扩展粒度粗。你想加10TB容量可能得买一整台阵列你想提升IOPS可能得换控制器。超融合的思路完全不同。它把每台服务器本地的磁盘SSD和HDD通过分布式存储软件聚合成一个共享存储池虚拟机可以在集群内任意节点之间迁移数据通过副本或者纠删码机制保证可靠性。计算和存储在同一台物理机上扩展的时候按节点加容量和性能线性增长。这里有个关键点很多人一开始会误解超融合不是把存储“虚拟化”了而是把存储“分布式化”了。数据不再集中在一个阵列里而是分散在所有节点的本地磁盘上通过一致性哈希或者类似算法定位数据块。这意味着任何一台节点故障数据仍然可以从其他节点的副本中读取集群整体不受影响。2.2 vSAN在超融合中的角色定位vSAN是超融合架构里负责存储层的那部分软件。它运行在ESXi内核里把每台主机的本地磁盘组成一个分布式共享数据存储。虚拟机看到的是一个统一的vSAN数据存储但实际上数据是分散在多个主机上的。vSAN的核心概念有几个必须搞清楚磁盘组每台主机上一块SSD做缓存层最多七块HDD或SSD做容量层组成一个磁盘组。缓存层负责读写缓存和元数据容量层负责持久化数据。存储策略通过VM Storage Policy定义虚拟机的冗余级别比如FTT1表示允许一台主机故障FTT2表示允许两台。策略还控制条带化、IOPS限制、强制置备等。见证组件在双主机集群或者延伸集群中见证组件放在第三方站点用来打破脑裂场景下的投票僵局。我一开始最困惑的是缓存层和容量层的比例怎么算。后来实测下来全闪配置下缓存层和容量层的比例建议不低于1:10混合配置下缓存层至少要能容纳一天的热数据写入量。这个比例不是拍脑袋定的而是根据vSAN的写入机制推导出来的所有写入先落到缓存层然后再根据策略逐步下沉到容量层。如果缓存层太小写入瓶颈会非常明显。2.3 超融合适用的场景与边界超融合不是万能的。它最适合的场景是通用虚拟化、VDI、私有云资源池、分支机构IT基础设施。这些场景的共同特点是虚拟机数量多、单机性能要求适中、需要快速扩展和简化运维。但它不太适合以下场景极致性能需求比如高频交易、实时大数据分析这些场景对存储延迟的要求在微秒级超融合的分布式架构会引入额外网络跳数。超大规模单一集群虽然vSAN支持扩展到几十个节点但集群越大网络广播和元数据同步的开销越明显。一般建议单集群不超过32个节点。非虚拟化工作负载超融合的核心价值在于为虚拟化提供弹性资源池如果你还在跑物理机数据库超融合的优势发挥不出来。我个人的经验是如果你管理的虚拟机数量在50到500台之间且对存储性能的要求不是极端苛刻超融合的投入产出比是最高的。低于50台传统架构可能更简单高于500台可能需要考虑专用存储或者更复杂的分布式方案。3. 动手之前的必修课硬件与网络规划3.1 硬件选型中的关键参数计算硬件选型是超融合落地最容易翻车的地方。我见过太多人随便买几台服务器就开始装结果发现磁盘控制器不在兼容列表里或者网卡不支持RDMA最后只能换硬件。先说CPU和内存。超融合节点上CPU不仅要跑虚拟机还要承担vSAN的存储处理开销。根据我的实测vSAN大约会消耗每节点10%到15%的CPU资源。内存方面vSAN需要预留一部分内存做缓存和元数据管理一般建议每节点至少256GB起步如果跑VDI或者内存密集型应用512GB更稳妥。磁盘控制器的选择比很多人想象的重要。vSAN对磁盘控制器的要求是必须支持直通模式不能做RAID因为vSAN需要直接访问每块磁盘。如果控制器做了RAIDvSAN就看不到物理磁盘了。另外控制器的队列深度和并发处理能力直接影响存储性能建议选择支持至少2000以上队列深度的型号。网络方面vSAN对网络的要求比传统架构高得多。因为每次写入都要通过网络同步副本网络延迟和带宽直接决定存储性能。10GbE是起步配置25GbE是当前主流推荐。如果预算允许RDMA网卡可以显著降低网络延迟提升vSAN性能。下面这张表是我整理的不同规模集群的硬件配置参考集群规模节点数每节点CPU每节点内存缓存层容量层网络小型32×16核256GB1×960GB NVMe4×4TB SAS2×10GbE中型5-82×24核512GB2×1.6TB NVMe6×8TB SAS2×25GbE大型10-162×32核768GB2×3.2TB NVMe8×16TB SAS2×25GbE这个表里的配置是基于通用虚拟化场景估算的实际选型还要根据你的虚拟机数量和IOPS需求做调整。计算逻辑是这样的先统计所有虚拟机的总IOPS需求然后除以节点数得到每节点需要承担的IOPS再根据磁盘的随机读写性能反推需要的磁盘数量和类型。3.2 网络规划万兆只是起点网络规划是超融合实施中最容易被低估的环节。很多人觉得万兆够用了结果上线后发现虚拟机迁移慢、存储性能上不去最后不得不重新规划网络。vSAN的网络流量分为几种类型存储心跳、元数据同步、副本写入、数据重建。其中数据重建是最吃带宽的。当一台节点故障后vSAN会启动重建把故障节点上的数据副本重新分布到其他节点。这个过程会占用大量网络带宽如果网络规划不合理重建期间业务性能会严重下降。我的建议是vSAN流量和虚拟机业务流量分开走不同的物理网卡或者VLAN。如果预算有限至少要用VLAN做逻辑隔离并配置流量整形保证vSAN流量不会把业务流量挤死。另外多播在vSAN早期版本中是必须的但从vSAN 6.6开始已经改为单播网络配置简化了很多。不过MTU还是建议设置为9000也就是巨帧。巨帧可以减少网络包的处理开销提升存储性能。但要注意从虚拟机到物理交换机再到对端主机整条路径上的MTU必须一致否则会出现丢包和性能下降。3.3 磁盘组的规划与缓存层设计磁盘组的规划直接决定vSAN的性能上限。每台主机可以创建多个磁盘组每个磁盘组由一块缓存盘和多块容量盘组成。缓存盘负责读写缓存和元数据容量盘负责持久化。这里有个关键决策缓存盘用SSD还是NVMe我的实测数据是NVMe缓存盘比SATA SSD的随机写入性能高出3到5倍延迟降低60%以上。如果预算允许缓存层强烈建议上NVMe。容量盘的选择要看场景。全闪配置下容量盘也用SSD或NVMe性能最好但成本高。混合配置下容量盘用HDD成本低但性能受限于HDD的随机读写能力。混合配置适合容量需求大、性能要求不高的场景比如文件服务器、备份存储。磁盘组的数量也有讲究。每台主机至少创建一个磁盘组如果容量盘数量多可以创建多个磁盘组每个磁盘组独立管理自己的缓存和容量。多个磁盘组的好处是并行处理能力更强坏处是缓存层被分散每个磁盘组的缓存容量变小。我的经验是每台主机创建1到2个磁盘组比较均衡超过3个磁盘组后性能提升不明显反而增加管理复杂度。4. 从零搭建vSAN集群配置实操4.1 集群初始化与磁盘组创建假设你已经装好了ESXi网络也配置好了接下来就是创建vSAN集群。这个过程在vSphere Client里操作步骤不复杂但有几个细节容易出错。第一步在vCenter里新建一个集群然后开启vSAN功能。开启的时候会提示你选择vSAN的版本和存储架构一般选最新版本就行。这里要注意vSAN开启后集群内的ESXi主机必须全部加入vSAN不能有主机游离在外。第二步把ESXi主机加入集群。加入的时候主机的磁盘会被vSAN自动识别。如果磁盘之前有分区或者RAID信息需要先清空。我遇到过好几次因为磁盘残留分区导致vSAN无法识别的情况解决办法是在ESXi Shell里用partedUtil命令手动清除分区表。第三步创建磁盘组。在vSAN的磁盘管理界面选择一台主机点击创建磁盘组然后选择一块缓存盘和多块容量盘。创建完成后vSAN会自动格式化磁盘并加入存储池。这里有个实操心得创建磁盘组之前先把所有主机的磁盘固件升级到最新版本。我踩过一次坑某型号SSD的旧固件有掉盘问题导致vSAN频繁报磁盘故障升级固件后问题消失。另外磁盘组的创建过程会清空磁盘数据如果磁盘上有旧数据提前备份。4.2 存储策略的制定与虚拟机部署存储策略是vSAN的灵魂。它决定了虚拟机的数据怎么分布、怎么保护、怎么分配性能。创建虚拟机的时候必须给它分配一个存储策略否则vSAN会用默认策略。默认策略一般是FTT1也就是允许一台主机故障。对于生产环境我建议至少用FTT1关键业务用FTT2。但FTT2需要至少5台主机因为vSAN需要保证在任意两台主机故障时数据仍然有足够的副本存活。存储策略里还有几个参数值得关注条带化把虚拟机的数据分散到多个磁盘上提升并行读写性能。条带数一般设置为2到4太高会增加元数据开销。对象空间预留控制虚拟磁盘的置备方式。精简置备节省空间但可能超配厚置备保证空间但浪费容量。IOPS限制限制单个虚拟机的IOPS防止某个虚拟机把存储性能吃光。这个参数在共享环境中很有用。我一般会创建几个不同的存储策略一个给普通业务虚拟机FTT1条带数2一个给数据库虚拟机FTT1条带数4厚置备一个给测试虚拟机FTT1精简置备IOPS限制500。这样不同业务各取所需资源分配更合理。4.3 集群健康检查与性能基线测试集群搭建完成后不要急着上业务。先做健康检查和性能基线测试确认集群状态正常。健康检查在vSAN的监控界面里会列出所有检查项包括磁盘健康、网络健康、集群平衡、数据健康等。如果有项目显示警告或者错误必须逐项排查。我见过最常见的问题是网络MTU不一致和磁盘组不平衡。性能基线测试我一般用两个工具一个是VMware自带的esxcli vsan storage命令可以查看磁盘组的IOPS和延迟另一个是第三方的fio工具在虚拟机里跑随机读写测试模拟真实业务负载。测试的时候要注意先跑单虚拟机测试再跑多虚拟机并发测试。单虚拟机测试看的是单条IO路径的性能多虚拟机测试看的是集群整体的并发处理能力。我实测下来一个配置合理的全闪vSAN集群单虚拟机随机读IOPS可以跑到8万以上延迟在1毫秒以内多虚拟机并发时集群总IOPS可以线性增长到几十万。如果测试结果不理想排查顺序是先看网络有没有丢包和延迟再看磁盘组有没有瓶颈最后看存储策略有没有配置不当。网络问题占了我遇到问题的七成以上尤其是MTU不一致和网卡协商速率不对。5. 那些文档里不会写的坑故障排查实录5.1 磁盘组故障与数据重建磁盘组故障是vSAN运维中最常见的问题。故障类型主要有三种缓存盘故障、容量盘故障、磁盘组整体离线。缓存盘故障是最严重的因为缓存盘上保存了元数据和写缓存一旦故障整个磁盘组的数据都不可用。不过vSAN有副本机制只要其他节点上有副本数据就不会丢。故障发生后vSAN会自动把故障磁盘组上的数据副本重新分布到其他节点这个过程叫数据重建。数据重建的速度取决于网络带宽和集群负载。我实测过一个场景3节点集群每节点4块4TB HDD一块960GB SSD缓存一台节点缓存盘故障后重建了大约6小时。重建期间集群的存储性能下降了约30%因为重建流量占用了网络和磁盘资源。这里有个避坑技巧数据重建期间尽量不要做虚拟机迁移或者快照操作否则会进一步加重集群负担。另外如果集群容量接近上限重建可能会失败因为vSAN需要足够的空闲空间来存放重建的数据副本。所以平时要保持集群至少有25%到30%的空闲容量。5.2 网络分区与脑裂场景处理网络分区是vSAN集群最危险的故障之一。当集群内的主机因为网络问题被分成两个或多个分区时每个分区都认为自己是正常的试图独立运行这就是脑裂。vSAN通过见证组件来防止脑裂。在双主机集群或者延伸集群中见证组件放在第三方站点当网络分区发生时只有能够联系到见证组件的分区才能继续提供服务另一个分区会被隔离。但在多主机集群中情况更复杂。如果集群有5台主机网络分区把3台和2台分开3台的分区因为占多数可以继续运行2台的分区会被隔离。这个机制叫多数派投票。我遇到过一次网络分区原因是机柜交换机的固件bug导致间歇性丢包。当时集群被分成了两个分区业务虚拟机在少数派分区上被vSAN隔离后自动关机了。虽然数据没丢但业务中断了将近20分钟。后来排查发现是交换机固件问题升级后恢复正常。这个经历给我的教训是超融合集群的网络设备必须用企业级交换机并且固件要定期更新。另外建议配置vSAN的网络心跳冗余用独立的物理网卡和VLAN跑心跳流量避免业务流量和心跳流量互相干扰。5.3 性能瓶颈的定位与优化性能瓶颈的定位需要一套系统的方法。我一般按照“从下到上”的顺序排查物理层、网络层、存储层、虚拟机层。物理层看CPU和内存使用率如果CPU持续超过70%说明计算资源不足如果内存使用率超过90%说明需要加内存。网络层看带宽利用率和丢包率如果带宽利用率超过80%说明网络是瓶颈如果有丢包说明网络配置有问题。存储层看磁盘组的IOPS和延迟如果延迟超过10毫秒说明存储性能不足。虚拟机层看虚拟机的资源使用情况如果某个虚拟机IOPS异常高可能是应用问题。优化手段有几个方向增加缓存层容量、调整存储策略的条带数、升级网络到25GbE、增加磁盘组数量。我试过最有效的优化是升级缓存盘到NVMe延迟直接从5毫秒降到1毫秒以内。其次是调整条带数从2调到4后随机读写性能提升了约40%。下面这张表是我整理的常见性能问题与排查方向现象可能原因排查方法解决方向虚拟机延迟高缓存层不足查看缓存盘使用率扩容缓存盘或升级NVMe集群IOPS上不去网络带宽瓶颈查看网络利用率升级25GbE或增加网卡数据重建慢网络或磁盘负载高查看重建进度和资源占用限速重建或错峰重建磁盘组不平衡容量分配不均查看各磁盘组使用率手动平衡或调整策略虚拟机迁移慢网络延迟高查看迁移流量路径优化网络或错峰迁移6. 超融合运维的日常监控、扩容与升级6.1 监控体系的搭建与关键指标超融合集群的监控比传统架构更重要因为分布式系统的故障传播更快一个小问题可能引发连锁反应。我一般从三个层面搭建监控硬件层、vSAN层、虚拟机层。硬件层监控CPU、内存、磁盘、网卡的状态和性能。vSAN层监控磁盘组健康、存储策略合规性、数据重建进度、集群容量。虚拟机层监控虚拟机的资源使用和性能指标。关键指标有几个必须重点关注磁盘组的延迟和IOPS、网络带宽利用率、集群空闲容量、数据重建进度、存储策略合规状态。这些指标如果出现异常往往预示着更大的问题。我用的监控工具是vRealize Operations它可以自动发现异常并给出根因分析。如果没有这个工具也可以用vSAN自带的监控界面虽然功能简单一些但核心指标都有。6.2 集群扩容的时机与操作步骤扩容时机的判断标准有两个容量使用率和性能余量。容量使用率超过70%就该考虑扩容了性能余量低于30%也该扩容。扩容的操作很简单把新节点加入集群配置好网络创建磁盘组vSAN会自动把部分数据重新分布到新节点上。但扩容有几个注意事项新节点的硬件配置最好和现有节点一致否则可能出现性能不均衡扩容前要确认集群的网络带宽足够因为数据重新分布会占用大量网络资源扩容最好在业务低峰期做避免影响业务性能。我扩容过三次每次都是加一台节点。第一次扩容时没注意网络带宽结果数据重新分布把业务流量挤占了虚拟机延迟飙升。后来学乖了扩容前先限速把重新分布的带宽限制在总带宽的50%以内业务影响就小多了。6.3 版本升级与补丁管理超融合的版本升级比传统架构复杂因为涉及vCenter、ESXi、vSAN三个组件的兼容性。升级前必须查兼容性矩阵确认目标版本支持你当前的硬件和软件组合。升级顺序一般是先升级vCenter再升级ESXi最后升级vSAN。升级过程中集群会进入维护模式业务可能会短暂中断。为了减少影响可以用滚动升级的方式一台一台升级保证集群始终有足够的节点提供服务。补丁管理也很重要。vSAN的补丁通常修复的是磁盘兼容性、网络稳定性、数据一致性问题。我建议每季度检查一次补丁关键补丁及时打。但打补丁前一定要在测试环境验证我见过一次补丁导致磁盘组无法挂载的事故后来回滚才恢复。7. 写在最后一些个人体会超融合不是银弹它解决的是资源池化和运维简化的问题但引入了分布式系统的复杂性。如果你没有分布式存储的基础建议先在小规模测试环境里跑一段时间把故障场景都演练一遍再上生产。我最大的体会是超融合的稳定性高度依赖网络。网络规划做得好超融合用起来很省心网络规划做得差三天两头出问题。所以如果你准备上超融合先把网络搞好万兆起步巨帧开启心跳冗余这三件事做到位后面能省很多麻烦。另外存储策略不要照搬默认配置。根据业务特点定制策略该厚置备的厚置备该限速的限速该条带化的条带化。策略配好了性能和可靠性都有保障。最后分享一个小技巧定期做故障演练。手动拔一块磁盘或者关一台节点观察集群的反应和数据重建过程。演练多了真出故障的时候就不慌了。我在测试环境里演练过十几次每次都能发现一些之前没注意到的细节比如重建限速配置、见证组件的超时时间、虚拟机的重启策略。这些细节在文档里往往一笔带过但实际运维中非常关键。 
长河君 · 2026/10/9 12:24:52 · 阅读 1.2k 超融合与vSAN实战：从硬件选型到故障排查的运维笔记
1. 从一个机柜说起为什么我开始啃超融合三年前我还在用传统三层架构维护一个中小规模的虚拟化集群三台服务器加一台磁盘阵列外加两台光纤交换机。每次扩容都像做一场外科手术先算控制器端口够不够再算阵列的IOPS余量然后纠结新买的服务器HBA卡和旧交换机能不能握手。直到有一次客户机房搬迁一台存储控制器在运输途中出了故障整个集群停了六个小时我才下定决心认真研究超融合基础设施。超融合最直观的价值就是把计算、存储、网络这三个原本各自为政的层揉进同一个资源池里。你不再需要单独规划存储网络、不再需要为LUN的容量和性能做复杂的映射扩容的时候往集群里加一台标准节点就行。听起来很美好但真正落地的时候坑一点都不少。我前后在测试环境里折腾了将近两个月从硬件选型到网络规划从存储策略到故障演练踩过的坑足够写一本小册子。这篇笔记主要面向两类人一类是刚接触超融合、准备做POC验证的运维工程师另一类是用过传统虚拟化、但对分布式存储和vSAN这类技术心里没底的同行。我会把整个学习路径拆成几个阶段从底层原理到实操配置再到故障排查尽量把每个决策背后的逻辑讲清楚。你不需要有超融合基础但最好对虚拟化和基础网络有一定了解这样读起来会更顺畅。2. 超融合到底融了什么核心概念拆解2.1 从传统架构到超融合的演进逻辑传统架构里计算和存储是分离的。服务器通过HBA卡或者iSCSI适配器连接到外置存储阵列存储阵列负责RAID保护、缓存加速、快照复制这些功能。这种模式的好处是存储资源可以独立扩展坏处是架构复杂、成本高、扩展粒度粗。你想加10TB容量可能得买一整台阵列你想提升IOPS可能得换控制器。超融合的思路完全不同。它把每台服务器本地的磁盘SSD和HDD通过分布式存储软件聚合成一个共享存储池虚拟机可以在集群内任意节点之间迁移数据通过副本或者纠删码机制保证可靠性。计算和存储在同一台物理机上扩展的时候按节点加容量和性能线性增长。这里有个关键点很多人一开始会误解超融合不是把存储“虚拟化”了而是把存储“分布式化”了。数据不再集中在一个阵列里而是分散在所有节点的本地磁盘上通过一致性哈希或者类似算法定位数据块。这意味着任何一台节点故障数据仍然可以从其他节点的副本中读取集群整体不受影响。2.2 vSAN在超融合中的角色定位vSAN是超融合架构里负责存储层的那部分软件。它运行在ESXi内核里把每台主机的本地磁盘组成一个分布式共享数据存储。虚拟机看到的是一个统一的vSAN数据存储但实际上数据是分散在多个主机上的。vSAN的核心概念有几个必须搞清楚磁盘组每台主机上一块SSD做缓存层最多七块HDD或SSD做容量层组成一个磁盘组。缓存层负责读写缓存和元数据容量层负责持久化数据。存储策略通过VM Storage Policy定义虚拟机的冗余级别比如FTT1表示允许一台主机故障FTT2表示允许两台。策略还控制条带化、IOPS限制、强制置备等。见证组件在双主机集群或者延伸集群中见证组件放在第三方站点用来打破脑裂场景下的投票僵局。我一开始最困惑的是缓存层和容量层的比例怎么算。后来实测下来全闪配置下缓存层和容量层的比例建议不低于1:10混合配置下缓存层至少要能容纳一天的热数据写入量。这个比例不是拍脑袋定的而是根据vSAN的写入机制推导出来的所有写入先落到缓存层然后再根据策略逐步下沉到容量层。如果缓存层太小写入瓶颈会非常明显。2.3 超融合适用的场景与边界超融合不是万能的。它最适合的场景是通用虚拟化、VDI、私有云资源池、分支机构IT基础设施。这些场景的共同特点是虚拟机数量多、单机性能要求适中、需要快速扩展和简化运维。但它不太适合以下场景极致性能需求比如高频交易、实时大数据分析这些场景对存储延迟的要求在微秒级超融合的分布式架构会引入额外网络跳数。超大规模单一集群虽然vSAN支持扩展到几十个节点但集群越大网络广播和元数据同步的开销越明显。一般建议单集群不超过32个节点。非虚拟化工作负载超融合的核心价值在于为虚拟化提供弹性资源池如果你还在跑物理机数据库超融合的优势发挥不出来。我个人的经验是如果你管理的虚拟机数量在50到500台之间且对存储性能的要求不是极端苛刻超融合的投入产出比是最高的。低于50台传统架构可能更简单高于500台可能需要考虑专用存储或者更复杂的分布式方案。3. 动手之前的必修课硬件与网络规划3.1 硬件选型中的关键参数计算硬件选型是超融合落地最容易翻车的地方。我见过太多人随便买几台服务器就开始装结果发现磁盘控制器不在兼容列表里或者网卡不支持RDMA最后只能换硬件。先说CPU和内存。超融合节点上CPU不仅要跑虚拟机还要承担vSAN的存储处理开销。根据我的实测vSAN大约会消耗每节点10%到15%的CPU资源。内存方面vSAN需要预留一部分内存做缓存和元数据管理一般建议每节点至少256GB起步如果跑VDI或者内存密集型应用512GB更稳妥。磁盘控制器的选择比很多人想象的重要。vSAN对磁盘控制器的要求是必须支持直通模式不能做RAID因为vSAN需要直接访问每块磁盘。如果控制器做了RAIDvSAN就看不到物理磁盘了。另外控制器的队列深度和并发处理能力直接影响存储性能建议选择支持至少2000以上队列深度的型号。网络方面vSAN对网络的要求比传统架构高得多。因为每次写入都要通过网络同步副本网络延迟和带宽直接决定存储性能。10GbE是起步配置25GbE是当前主流推荐。如果预算允许RDMA网卡可以显著降低网络延迟提升vSAN性能。下面这张表是我整理的不同规模集群的硬件配置参考集群规模节点数每节点CPU每节点内存缓存层容量层网络小型32×16核256GB1×960GB NVMe4×4TB SAS2×10GbE中型5-82×24核512GB2×1.6TB NVMe6×8TB SAS2×25GbE大型10-162×32核768GB2×3.2TB NVMe8×16TB SAS2×25GbE这个表里的配置是基于通用虚拟化场景估算的实际选型还要根据你的虚拟机数量和IOPS需求做调整。计算逻辑是这样的先统计所有虚拟机的总IOPS需求然后除以节点数得到每节点需要承担的IOPS再根据磁盘的随机读写性能反推需要的磁盘数量和类型。3.2 网络规划万兆只是起点网络规划是超融合实施中最容易被低估的环节。很多人觉得万兆够用了结果上线后发现虚拟机迁移慢、存储性能上不去最后不得不重新规划网络。vSAN的网络流量分为几种类型存储心跳、元数据同步、副本写入、数据重建。其中数据重建是最吃带宽的。当一台节点故障后vSAN会启动重建把故障节点上的数据副本重新分布到其他节点。这个过程会占用大量网络带宽如果网络规划不合理重建期间业务性能会严重下降。我的建议是vSAN流量和虚拟机业务流量分开走不同的物理网卡或者VLAN。如果预算有限至少要用VLAN做逻辑隔离并配置流量整形保证vSAN流量不会把业务流量挤死。另外多播在vSAN早期版本中是必须的但从vSAN 6.6开始已经改为单播网络配置简化了很多。不过MTU还是建议设置为9000也就是巨帧。巨帧可以减少网络包的处理开销提升存储性能。但要注意从虚拟机到物理交换机再到对端主机整条路径上的MTU必须一致否则会出现丢包和性能下降。3.3 磁盘组的规划与缓存层设计磁盘组的规划直接决定vSAN的性能上限。每台主机可以创建多个磁盘组每个磁盘组由一块缓存盘和多块容量盘组成。缓存盘负责读写缓存和元数据容量盘负责持久化。这里有个关键决策缓存盘用SSD还是NVMe我的实测数据是NVMe缓存盘比SATA SSD的随机写入性能高出3到5倍延迟降低60%以上。如果预算允许缓存层强烈建议上NVMe。容量盘的选择要看场景。全闪配置下容量盘也用SSD或NVMe性能最好但成本高。混合配置下容量盘用HDD成本低但性能受限于HDD的随机读写能力。混合配置适合容量需求大、性能要求不高的场景比如文件服务器、备份存储。磁盘组的数量也有讲究。每台主机至少创建一个磁盘组如果容量盘数量多可以创建多个磁盘组每个磁盘组独立管理自己的缓存和容量。多个磁盘组的好处是并行处理能力更强坏处是缓存层被分散每个磁盘组的缓存容量变小。我的经验是每台主机创建1到2个磁盘组比较均衡超过3个磁盘组后性能提升不明显反而增加管理复杂度。4. 从零搭建vSAN集群配置实操4.1 集群初始化与磁盘组创建假设你已经装好了ESXi网络也配置好了接下来就是创建vSAN集群。这个过程在vSphere Client里操作步骤不复杂但有几个细节容易出错。第一步在vCenter里新建一个集群然后开启vSAN功能。开启的时候会提示你选择vSAN的版本和存储架构一般选最新版本就行。这里要注意vSAN开启后集群内的ESXi主机必须全部加入vSAN不能有主机游离在外。第二步把ESXi主机加入集群。加入的时候主机的磁盘会被vSAN自动识别。如果磁盘之前有分区或者RAID信息需要先清空。我遇到过好几次因为磁盘残留分区导致vSAN无法识别的情况解决办法是在ESXi Shell里用partedUtil命令手动清除分区表。第三步创建磁盘组。在vSAN的磁盘管理界面选择一台主机点击创建磁盘组然后选择一块缓存盘和多块容量盘。创建完成后vSAN会自动格式化磁盘并加入存储池。这里有个实操心得创建磁盘组之前先把所有主机的磁盘固件升级到最新版本。我踩过一次坑某型号SSD的旧固件有掉盘问题导致vSAN频繁报磁盘故障升级固件后问题消失。另外磁盘组的创建过程会清空磁盘数据如果磁盘上有旧数据提前备份。4.2 存储策略的制定与虚拟机部署存储策略是vSAN的灵魂。它决定了虚拟机的数据怎么分布、怎么保护、怎么分配性能。创建虚拟机的时候必须给它分配一个存储策略否则vSAN会用默认策略。默认策略一般是FTT1也就是允许一台主机故障。对于生产环境我建议至少用FTT1关键业务用FTT2。但FTT2需要至少5台主机因为vSAN需要保证在任意两台主机故障时数据仍然有足够的副本存活。存储策略里还有几个参数值得关注条带化把虚拟机的数据分散到多个磁盘上提升并行读写性能。条带数一般设置为2到4太高会增加元数据开销。对象空间预留控制虚拟磁盘的置备方式。精简置备节省空间但可能超配厚置备保证空间但浪费容量。IOPS限制限制单个虚拟机的IOPS防止某个虚拟机把存储性能吃光。这个参数在共享环境中很有用。我一般会创建几个不同的存储策略一个给普通业务虚拟机FTT1条带数2一个给数据库虚拟机FTT1条带数4厚置备一个给测试虚拟机FTT1精简置备IOPS限制500。这样不同业务各取所需资源分配更合理。4.3 集群健康检查与性能基线测试集群搭建完成后不要急着上业务。先做健康检查和性能基线测试确认集群状态正常。健康检查在vSAN的监控界面里会列出所有检查项包括磁盘健康、网络健康、集群平衡、数据健康等。如果有项目显示警告或者错误必须逐项排查。我见过最常见的问题是网络MTU不一致和磁盘组不平衡。性能基线测试我一般用两个工具一个是VMware自带的esxcli vsan storage命令可以查看磁盘组的IOPS和延迟另一个是第三方的fio工具在虚拟机里跑随机读写测试模拟真实业务负载。测试的时候要注意先跑单虚拟机测试再跑多虚拟机并发测试。单虚拟机测试看的是单条IO路径的性能多虚拟机测试看的是集群整体的并发处理能力。我实测下来一个配置合理的全闪vSAN集群单虚拟机随机读IOPS可以跑到8万以上延迟在1毫秒以内多虚拟机并发时集群总IOPS可以线性增长到几十万。如果测试结果不理想排查顺序是先看网络有没有丢包和延迟再看磁盘组有没有瓶颈最后看存储策略有没有配置不当。网络问题占了我遇到问题的七成以上尤其是MTU不一致和网卡协商速率不对。5. 那些文档里不会写的坑故障排查实录5.1 磁盘组故障与数据重建磁盘组故障是vSAN运维中最常见的问题。故障类型主要有三种缓存盘故障、容量盘故障、磁盘组整体离线。缓存盘故障是最严重的因为缓存盘上保存了元数据和写缓存一旦故障整个磁盘组的数据都不可用。不过vSAN有副本机制只要其他节点上有副本数据就不会丢。故障发生后vSAN会自动把故障磁盘组上的数据副本重新分布到其他节点这个过程叫数据重建。数据重建的速度取决于网络带宽和集群负载。我实测过一个场景3节点集群每节点4块4TB HDD一块960GB SSD缓存一台节点缓存盘故障后重建了大约6小时。重建期间集群的存储性能下降了约30%因为重建流量占用了网络和磁盘资源。这里有个避坑技巧数据重建期间尽量不要做虚拟机迁移或者快照操作否则会进一步加重集群负担。另外如果集群容量接近上限重建可能会失败因为vSAN需要足够的空闲空间来存放重建的数据副本。所以平时要保持集群至少有25%到30%的空闲容量。5.2 网络分区与脑裂场景处理网络分区是vSAN集群最危险的故障之一。当集群内的主机因为网络问题被分成两个或多个分区时每个分区都认为自己是正常的试图独立运行这就是脑裂。vSAN通过见证组件来防止脑裂。在双主机集群或者延伸集群中见证组件放在第三方站点当网络分区发生时只有能够联系到见证组件的分区才能继续提供服务另一个分区会被隔离。但在多主机集群中情况更复杂。如果集群有5台主机网络分区把3台和2台分开3台的分区因为占多数可以继续运行2台的分区会被隔离。这个机制叫多数派投票。我遇到过一次网络分区原因是机柜交换机的固件bug导致间歇性丢包。当时集群被分成了两个分区业务虚拟机在少数派分区上被vSAN隔离后自动关机了。虽然数据没丢但业务中断了将近20分钟。后来排查发现是交换机固件问题升级后恢复正常。这个经历给我的教训是超融合集群的网络设备必须用企业级交换机并且固件要定期更新。另外建议配置vSAN的网络心跳冗余用独立的物理网卡和VLAN跑心跳流量避免业务流量和心跳流量互相干扰。5.3 性能瓶颈的定位与优化性能瓶颈的定位需要一套系统的方法。我一般按照“从下到上”的顺序排查物理层、网络层、存储层、虚拟机层。物理层看CPU和内存使用率如果CPU持续超过70%说明计算资源不足如果内存使用率超过90%说明需要加内存。网络层看带宽利用率和丢包率如果带宽利用率超过80%说明网络是瓶颈如果有丢包说明网络配置有问题。存储层看磁盘组的IOPS和延迟如果延迟超过10毫秒说明存储性能不足。虚拟机层看虚拟机的资源使用情况如果某个虚拟机IOPS异常高可能是应用问题。优化手段有几个方向增加缓存层容量、调整存储策略的条带数、升级网络到25GbE、增加磁盘组数量。我试过最有效的优化是升级缓存盘到NVMe延迟直接从5毫秒降到1毫秒以内。其次是调整条带数从2调到4后随机读写性能提升了约40%。下面这张表是我整理的常见性能问题与排查方向现象可能原因排查方法解决方向虚拟机延迟高缓存层不足查看缓存盘使用率扩容缓存盘或升级NVMe集群IOPS上不去网络带宽瓶颈查看网络利用率升级25GbE或增加网卡数据重建慢网络或磁盘负载高查看重建进度和资源占用限速重建或错峰重建磁盘组不平衡容量分配不均查看各磁盘组使用率手动平衡或调整策略虚拟机迁移慢网络延迟高查看迁移流量路径优化网络或错峰迁移6. 超融合运维的日常监控、扩容与升级6.1 监控体系的搭建与关键指标超融合集群的监控比传统架构更重要因为分布式系统的故障传播更快一个小问题可能引发连锁反应。我一般从三个层面搭建监控硬件层、vSAN层、虚拟机层。硬件层监控CPU、内存、磁盘、网卡的状态和性能。vSAN层监控磁盘组健康、存储策略合规性、数据重建进度、集群容量。虚拟机层监控虚拟机的资源使用和性能指标。关键指标有几个必须重点关注磁盘组的延迟和IOPS、网络带宽利用率、集群空闲容量、数据重建进度、存储策略合规状态。这些指标如果出现异常往往预示着更大的问题。我用的监控工具是vRealize Operations它可以自动发现异常并给出根因分析。如果没有这个工具也可以用vSAN自带的监控界面虽然功能简单一些但核心指标都有。6.2 集群扩容的时机与操作步骤扩容时机的判断标准有两个容量使用率和性能余量。容量使用率超过70%就该考虑扩容了性能余量低于30%也该扩容。扩容的操作很简单把新节点加入集群配置好网络创建磁盘组vSAN会自动把部分数据重新分布到新节点上。但扩容有几个注意事项新节点的硬件配置最好和现有节点一致否则可能出现性能不均衡扩容前要确认集群的网络带宽足够因为数据重新分布会占用大量网络资源扩容最好在业务低峰期做避免影响业务性能。我扩容过三次每次都是加一台节点。第一次扩容时没注意网络带宽结果数据重新分布把业务流量挤占了虚拟机延迟飙升。后来学乖了扩容前先限速把重新分布的带宽限制在总带宽的50%以内业务影响就小多了。6.3 版本升级与补丁管理超融合的版本升级比传统架构复杂因为涉及vCenter、ESXi、vSAN三个组件的兼容性。升级前必须查兼容性矩阵确认目标版本支持你当前的硬件和软件组合。升级顺序一般是先升级vCenter再升级ESXi最后升级vSAN。升级过程中集群会进入维护模式业务可能会短暂中断。为了减少影响可以用滚动升级的方式一台一台升级保证集群始终有足够的节点提供服务。补丁管理也很重要。vSAN的补丁通常修复的是磁盘兼容性、网络稳定性、数据一致性问题。我建议每季度检查一次补丁关键补丁及时打。但打补丁前一定要在测试环境验证我见过一次补丁导致磁盘组无法挂载的事故后来回滚才恢复。7. 写在最后一些个人体会超融合不是银弹它解决的是资源池化和运维简化的问题但引入了分布式系统的复杂性。如果你没有分布式存储的基础建议先在小规模测试环境里跑一段时间把故障场景都演练一遍再上生产。我最大的体会是超融合的稳定性高度依赖网络。网络规划做得好超融合用起来很省心网络规划做得差三天两头出问题。所以如果你准备上超融合先把网络搞好万兆起步巨帧开启心跳冗余这三件事做到位后面能省很多麻烦。另外存储策略不要照搬默认配置。根据业务特点定制策略该厚置备的厚置备该限速的限速该条带化的条带化。策略配好了性能和可靠性都有保障。最后分享一个小技巧定期做故障演练。手动拔一块磁盘或者关一台节点观察集群的反应和数据重建过程。演练多了真出故障的时候就不慌了。我在测试环境里演练过十几次每次都能发现一些之前没注意到的细节比如重建限速配置、见证组件的超时时间、虚拟机的重启策略。这些细节在文档里往往一笔带过但实际运维中非常关键。