企业官网建设流程全解析

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定义虚拟机的冗余级别，比如FTT=1表示允许一台主机故障，FTT=2表示允许两台。策略还控制条带化、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需要直接访问每块磁盘。如果控制器做了RAID，vSAN就看不到物理磁盘了。另外，控制器的队列深度和并发处理能力直接影响存储性能，建议选择支持至少2000以上队列深度的型号。

网络方面，vSAN对网络的要求比传统架构高得多。因为每次写入都要通过网络同步副本，网络延迟和带宽直接决定存储性能。10GbE是起步配置，25GbE是当前主流推荐。如果预算允许，RDMA网卡可以显著降低网络延迟，提升vSAN性能。

下面这张表是我整理的不同规模集群的硬件配置参考：

这个表里的配置是基于通用虚拟化场景估算的，实际选型还要根据你的虚拟机数量和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会用默认策略。

默认策略一般是FTT=1，也就是允许一台主机故障。对于生产环境，我建议至少用FTT=1，关键业务用FTT=2。但FTT=2需要至少5台主机，因为vSAN需要保证在任意两台主机故障时，数据仍然有足够的副本存活。

存储策略里还有几个参数值得关注：

• 条带化：把虚拟机的数据分散到多个磁盘上，提升并行读写性能。条带数一般设置为2到4，太高会增加元数据开销。
• 对象空间预留：控制虚拟磁盘的置备方式。精简置备节省空间，但可能超配；厚置备保证空间，但浪费容量。
• IOPS限制：限制单个虚拟机的IOPS，防止某个虚拟机把存储性能吃光。这个参数在共享环境中很有用。

我一般会创建几个不同的存储策略：一个给普通业务虚拟机，FTT=1，条带数2；一个给数据库虚拟机，FTT=1，条带数4，厚置备；一个给测试虚拟机，FTT=1，精简置备，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%。

下面这张表是我整理的常见性能问题与排查方向：

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. 写在最后：一些个人体会

超融合不是银弹，它解决的是资源池化和运维简化的问题，但引入了分布式系统的复杂性。如果你没有分布式存储的基础，建议先在小规模测试环境里跑一段时间，把故障场景都演练一遍，再上生产。

我最大的体会是：超融合的稳定性高度依赖网络。网络规划做得好，超融合用起来很省心；网络规划做得差，三天两头出问题。所以如果你准备上超融合，先把网络搞好，万兆起步，巨帧开启，心跳冗余，这三件事做到位，后面能省很多麻烦。

另外，存储策略不要照搬默认配置。根据业务特点定制策略，该厚置备的厚置备，该限速的限速，该条带化的条带化。策略配好了，性能和可靠性都有保障。

最后分享一个小技巧：定期做故障演练。手动拔一块磁盘，或者关一台节点，观察集群的反应和数据重建过程。演练多了，真出故障的时候就不慌了。我在测试环境里演练过十几次，每次都能发现一些之前没注意到的细节，比如重建限速配置、见证组件的超时时间、虚拟机的重启策略。这些细节在文档里往往一笔带过，但实际运维中非常关键。