企业官网建设流程全解析

那天晚上十一点多，我在家里正准备关电脑睡觉，手机上的监控APP突然连续弹了三条告警。打开一看，vSAN集群里有一台ESXi主机的闪存缓存磁盘状态异常，紧接着“vSAN磁盘健康状态警告”“集群重新同步中”也一起冒了出来。说句实话，看到这个告警我心里是咯噔一下的——在vSAN这种磁盘组架构里，缓存盘一旦出问题，整个磁盘组都会跟着遭殃，数据处理方式和普通虚拟机存储完全两个概念。

这几年做虚拟化运维，vSAN的闪存缓存磁盘故障处理我前前后后经历过好几轮，尤其是不少生产环境在硬件层还把缓存盘做成了RAID0卷，这种配置处理起来风险更大、步骤也更讲究。网上关于vSAN部署的教程很多，但真正把“缓存盘故障后怎么办”讲透的少之又少。所以这篇文章我打算结合自己实际处理的故障案例，把vSAN闪存缓存盘在RAID0模式下的故障诊断、数据安全评估、物理换盘、磁盘组重建这一整套流程全部拆开讲清楚，顺带把vSphere 7.0里创建vSAN时容易忽略的缓存盘规划问题、以及vSAN集群中那个特殊的“主机和vc之间的时间已同步”告警也一起聊了。不管你是刚接触vSAN的新手，还是已经在生产环境跑了好几年的运维老兵，这篇文章都值得收藏备用。

1. 先把VSAN缓存盘的作用和RAID0这个配置搞明白

1.1 缓存盘在vSAN磁盘组里的真实角色

要说故障处理，得先知道缓存盘在vSAN里到底是干嘛的。vSAN的逻辑很简单：把每台ESXi主机上的本地磁盘“池化”成一个分布式存储，对外提供虚拟机存储空间。但这个池化不是简单地把磁盘拼在一起，而是有明确的分工和层级关系。

vSAN的最小工作单元叫磁盘组（Disk Group），一个磁盘组里包含两块角色完全不同的盘：

• 缓存盘（Flash Cache）：必须是闪存类设备（SSD、NVMe），作用是提供读写缓存。
• 容量盘（Capacity Disk）：可以是HDD或SSD，负责真正持久化存放数据。

整个IO流程大概是这样的：虚拟机写入数据时，vSAN先把数据落到本主机磁盘组里的缓存盘，然后异步把数据刷到容量盘上。读取的时候，如果数据已经在缓存盘里，就直接命中返回；没命中再去容量盘里取，同时把热数据缓存一份。这个机制有点像一个中转仓库——缓存盘是“收货口”，容量盘是“真正的库房”。

这也解释了为什么缓存盘这么重要：缓存盘一旦挂了，这个磁盘组里所有容量盘的IO路径都会受影响。更麻烦的是，vSAN不会自动把缓存盘故障的磁盘组数据全部迁移走，它会尝试在集群范围内重建数据副本，但这个过程非常依赖于集群剩余容量和主机数量。所以很多刚接触vSAN的人有个误区，以为缓存盘坏了换一块就行，实际上在vSAN里，更换缓存盘通常意味着整个磁盘组都要重建。

1.2 RAID0、RAID1、RAID5、RAID10到底差在哪

既然标题提到了RAID0模式，这里就得先把这个概念彻底捋清楚。很多刚入门的朋友会把vSAN的容错机制和传统RAID混在一起，其实它们是两个层面的东西。

传统RAID是指单台服务器上，用多块物理硬盘组成一个逻辑卷，由RAID控制器或系统软件负责数据分布和冗余。常见的几种级别区别如下：

而vSAN里的容错策略（FTT）走的是另外一套逻辑——它是软件定义分布式RAID，数据会在不同主机之间形成多个副本或纠删码，靠的是多台主机的协作来保证数据不丢。vSAN里虽然没有小朋友天天挂在嘴边的“Raid 0、Raid 1”这种叫法，但它的条带化（Striping）和副本机制，本质上也是把传统RAID的思想做了一层池化封装。

那为什么大家还是会把“vSAN缓存盘”和“RAID0模式”放在一起说？这就不得不讲一下实际生产环境中常见的硬件配置了。

1.3 为什么生产环境里会见到“RAID0模式的缓存盘”

我在实际运维中见过不少服务器，并不是所有厂商都默认支持直通模式（Passthrough）让ESXi完全接管硬盘。有些OEM服务器出厂时，RAID控制器默认会接管所有硬盘，你必须先在里面创建逻辑卷，系统才能识别到盘。

在这种架构下，很多实施工程师图省事，会把两块或多块SSD在RAID控制器里直接做成一个RAID0卷，然后把这个卷当作vSAN的缓存盘来使用。这样做的好处是配置简单，不需要修改RAID卡的默认设置，坏了一块盘时RAID控制器层面也会给出“VD Degraded”的提示。但风险也很明显：RAID0本身没有冗余，物理硬盘如果故障严重到RAID卡无法识别，整个RAID0逻辑卷会直接丢失，vSAN端会把这个缓存盘标记为不可用。

这里我必须明确一个观点：VMware官方推荐的最佳实践，是尽量让ESXi以直通方式识别物理磁盘，不要在硬件层对vSAN磁盘做RAID。如果因为服务器厂商的限制必须用RAID0模式来“绕”过RAID控制器的接管，那一定要知道你这是用“运维便利性”换了一部分“可靠性”，后续故障处理时每一步都要更加谨慎。我这次实战处理的故障环境，用的正是RAID0卷作为vSAN缓存盘，后面的过程里可以看到这个特殊配置带来的不同处理点。

2. 缓存盘故障前，这些信号比故障本身更值得关注

2.1 告警窗口里那些能被我们抓到的提示

vSAN缓存盘故障很少是“毫无征兆”的。在真正物理损坏之前，vSphere平台往往会给出几层提示，只是很多运维人员不重视。

最基础的一层是vCenter里的vSAN健康检查。在vSphere Client中打开vSAN集群，进入“监控 -> vSAN -> 健康”，会看到“物理磁盘健康状态”这一项。正常情况下是绿色的“正常”。一旦某个缓存盘开始出现坏块、SMART错误或者IO延迟飙升，健康状态就会变成黄色警告，点进去还能看到具体是哪台主机、哪个磁盘组的哪块磁盘出了问题。

第二层是vSphere事件日志和告警。vCenter里能看到类似“vSAN：磁盘状态异常”“无法访问vSAN设备”“vSAN磁盘不可用”这类事件。需要注意的是，这里的事件可能不会直接标明“缓存盘”，而只是说某个vSAN设备有问题。要用vSAN的存储视图去对照。

第三层是ESXi hostd或vobd日志。如果缓存盘已经出现了硬件层面的错误，ESXi的系统日志里会出现类似“A device error occurred”的vobd事件，或者存储堆栈报出SCSI错误。这些日志一般运维不会主动去看，但在故障排查时很有参考价值。

我的习惯是：每周至少在vCenter里看一次vSAN健康状态，有条件的话配一个告警规则，把“vSAN集群健康状态变化”的告警直接推送到群里或手机上。等监控发短信告诉你缓存盘坏了，通常已经离故障很近了。

2.2 让vSAN健康检查和esxcli帮你说话

vSphere Client界面能看大部分状态，但真正要定位问题，还是得靠命令行工具。我平时会用这几个命令组合来确认缓存盘的实际状态。

首先要确认ESXi能识别到哪些vSAN相关设备，并查看它们在vSAN中的角色：

esxcli vsan storage list

这个命令会输出所有已声明给vSAN的磁盘明细，包括磁盘组的“所有者”、设备名、是否缓存盘等。如果你看到某个缓存盘在输出里状态显示为“degraded”或者设备丢失，那基本可以确定是这个盘出了问题。具体可以使用下面的命令过滤出损坏或状态异常的磁盘：

esxcli vsan storage list | grep -A 6 -i "state"

再看物理层的健康状态，ESXi 7.0支持直接读取部分SSD的SMART信息：

esxcli storage core device smart get -d <device_name>

另外还有一个命令很方便，直接检查vSAN集群的整体健康：

esxcli vsan health cluster list

它会一次性输出vSAN集群是否健康、是否有对象悬空、是否有磁盘损坏等信息。说实话，我每次做磁盘更换前都会先跑一遍这个命令，相当于给整个集群做一次“心电图”。

2.3 别小看“主机和vc之间的时间已同步”这条集群警报

很多人在vCenter里看到一条警报写着“主机和vc之间的时间已同步”，第一反应是：这不是正常的吗？为什么还报警？甚至连一些有经验的运维也会忽略它。

这条警报在vSphere 7.0中确实出现得很频繁，本质上它是一个信息级警报，意思是“主机与vCenter之间的时间差异已经恢复到正常范围内”。但如果它反复跳出来，尤其是配合vSAN健康检查一起出现时，就要警惕了。vSAN集群对时间同步要求非常高，因为vSAN对象、组件和证书机制都依赖时间戳。如果ESXi主机和vCenter或NTP服务器的时间偏差超过一定阈值（一般是5分钟左右），vSAN健康检查会报”集群时间同步异常“，严重时还会影响vSAN的证书校验和主机心跳。

我之前排查过一个案例：vSAN集群健康状态一直亮黄灯，报“vSAN集群时间同步”问题，但vCenter告警里却在“时间已同步”和“时间未同步”之间来回切换。最后查下来，是因为ESXi主机的NTP配置指向了一个不稳定的NTP服务器，部分主机同步成功、部分失败，时间漂移反复波动。所以如果你看到vSAN集群异常，同时有“主机和vc之间的时间已同步”这样反复出现的消息，第一件事就去核对每台主机的NTP设置和实际时间：

esxcli system time get esxcli network ntp get

确保所有ESXi都指向同一个可靠的NTP服务器，且防火墙放行了NTP的123端口。普通虚拟机集群时间偏差可以容忍，vSAN集群不行，这一点在创建集群第一天就应该配置好。

3. 缓存盘损坏后的完整更换实操（含踩坑记录）

3.1 动手前先做风险评估，别急着拔盘

确认缓存盘确实坏了之后，最忌讳的就是直接冲到机房拔盘。vSAN是分布式存储，拔一块盘牵扯的可不只是那块盘本身，而是整个磁盘组的数据可用性问题。

动手前，我先做这几件事：

第一，确认vSAN的容错策略FTT（Fault Tolerance Method）。如果FTT=1，意味着集群里每个对象至少有两个副本，坏一台主机不影响数据可用性。如果集群是两节点或使用纠删码的特殊情况，风险等级又要单独评估。

第二，检查集群剩余空间。缓存盘故障后，vSAN会把受影响的组件在其他主机上重建，这个过程会消耗大量的集群空闲容量。如果空闲容量不足，重建可能会卡住甚至失败。我习惯打开vCenter里的“vSAN容量”页面，看剩余空间是否超过受影响数据量的1倍以上。

第三，评估受影响的范围。缓存盘所在的磁盘组里挂了多少容量盘？这些容量盘上存放了哪些虚拟机？需要提前通知业务方吗？我在实际操作时，会先在vSphere Client的主机->存储设备列表里，把故障主机上所有vSAN设备列出来，再对照磁盘组关系确认。

这一步做完，心里大概就有数了。如果FTT=1、集群主机数>=3、剩余容量充足，那缓存盘故障整体风险可控，可以在不关机的情况下完成更换。如果FTT=0或者集群容量已经很紧张，那就要严肃考虑业务窗口了，必要时先进行容量扩容，再进行磁盘更换。

3.2 在vSphere中正确移除故障磁盘组

缓存盘故障后，我建议的操作路径是这样的。

先把故障主机进入维护模式。这不是必须的，但能极大降低重建风险。在vSphere Client中选择主机 -> 维护模式 -> 进入维护模式，此时会弹出一个窗口，让你选择vSAN数据迁移方式：

• 不迁移数据：只是把主机置为维护状态，vSAN数据不会主动迁移。不推荐用来处理物理硬件更换。
• 确保可访问性：会保证数据仍然满足FTT容错要求，但不会把所有数据都搬走。
• 迁移所有数据：会把该主机上的vSAN组件全部迁移到集群中的其他主机，耗时最长但最安全。

对于要更换缓存盘这种操作，我强烈建议选“迁移所有数据”。虽然时间长一点，但换盘过程中数据已经全部在其他主机上有了可用的副本，后续删除磁盘组时对业务的影响最小。

等主机进入维护模式、所有vSAN组件迁移完成后，接下来就要在vSphere Client里操作：

1. 进入vSAN集群，选择“配置 -> vSAN -> 磁盘管理”。
2. 右侧会列出所有主机和磁盘组。找到故障缓存盘所属的磁盘组。
3. 在磁盘组操作中，选择“删除”。
4. 系统会弹出一个警告“删除磁盘组将删除该磁盘组中的所有组件数据”。这里要冷静——如果你的数据已经在上一步迁移完成，删除磁盘组时vSAN不会真的把数据抹掉，而是会触发组件重新分布。如果上一步没做数据迁移，这一步才真的要小心。

删除磁盘组后，vSAN会开始重新分配受影响的组件，可以在“监控 -> vSAN -> 重新同步状态”里观察进度。等重新同步百分比走到100%，再断电换盘。

这里要特别提一个我踩过的坑：有一年我换缓存盘时，图快选了“确保可访问性”模式，结果主机进维护模式后组件确实还是可访问的，但数据并没有完全迁移走。删除磁盘组时，vSAN只能在“牺牲冗余”的情况下重建数据，如果有两台主机恰好同时故障，数据就真的危险了。从那以后，凡是动缓存盘，我都老老实实选“迁移所有数据”。

3.3 物理更换缓存盘并重建磁盘组

等vSphere里磁盘组已经删除，主机也处于维护模式，这时候才能去机房动手。

第一步，确认故障盘槽位。建议通过服务器管理界面（比如iLO、DRAC、OMSA）查看对应控制器下的物理硬盘状态面向服务器的槽位编号。如果控制器的面板灯还在闪烁，可以直接找亮黄灯或红灯的那块。

第二步，处理RAID0卷的问题。如果你的缓存盘之前是RAID0卷，这里要额外注意：如果只是RAID卡检测到卷内某块盘故障，你需要先查清楚这个RAID0卷包含了几块物理盘。如果只包含一块，那就简单，直接拔掉坏盘，换上新盘后重新创建RAID0卷。如果坏盘所在卷里同时还包含其他盘（比如做了跨盘RAID0），那就不能随便动，必须先备份软RAID配置或联系服务器厂商确认。

我的故障环境是单盘RAID0，所以操作路径是：

1. 在服务器管理界面确认坏盘槽位。
2. 物理拔盘，换上同型号的新SSD。最好用兼容列表里的盘，这点我后面会展开讲。
3. 开机进入RAID控制器配置界面，把新盘做成RAID0卷。如果是HPE服务器，也可以在POST阶段按F9或通过SSA工具在线操作；戴尔服务器就是Ctrl+R进入PERC配置界面。
4. 创建完RAID0卷，回到操作系统，在ESXi中执行“存储 -> 重新扫描”，让系统识别到新设备。

第三步，在vSphere中重新创建磁盘组。回到vSphere Client的vSAN磁盘管理页面，此时应该能看到新加入的未声明磁盘。点击“创建磁盘组”，选择新缓存盘，再把原磁盘组里那些容量盘一起加回去。注意：容量盘是可以复用的，如果之前磁盘组里的容量盘还在，它们会被重新声明并加入新的磁盘组。

创建完成后，vSAN会提示磁盘组正在“重新同步”“重建”。此时整个集群开始进入数据回填阶段，虚拟机的IO会一点一点迁移回来。

关于新盘型号，这里多说一句：vSAN非常挑盘，不是随便拿一块SSD就能当缓存盘用的。一定要去VMware兼容性指南里查一下你这台服务器和SSD型号是不是在支持列表内。如果不在，即使vSAN创建成功，健康检查也会一直报“硬件兼容性”警告，严重时可能不被vSAN声明。我处理过一次用户自行买盘导致vSAN不认盘的案例，最后只能退换货。这点在RAID0模式下尤其重要，因为RAID层可能掩盖掉盘的真实型号信息，导致vSAN识别到的设备信息不完整。

3.4 重建完成后的数据验证与性能确认

磁盘组创建完不代表工作结束了，真正要盯的是后续的重建进度和性能恢复。

重建进度可以通过vSphere Client的“监控 -> vSAN -> 重新同步状态”查看，也可以使用命令行：

esxcli vsan cluster resync status

这个命令会显示集群级别的重建任务、正在处理的组件数量、剩余大小。如果两个主机之间的网卡带宽不足，re-sync可能会非常慢。我现场实践过的经验：vSAN重同步的数据流走的是专门的vSAN VMKernel网络，如果这个网络带宽不够，重建时不仅慢，还可能影响正常业务IO。有条件的话，vSAN流量建议用万兆网卡，至少也要保证专用VLAN。

重建进度走到100%后，再跑一遍：

esxcli vsan health cluster list

确认所有健康检查项都恢复到正常状态，尤其要看“对象完整性”“物理磁盘健康”“集群重新同步状态”这几项。

最后记得退出维护模式。这一步很多人会忘，结果第二天看到主机一直显示“维护模式”才知道忘记退出。退出后，主机重新加入vSAN集群资源池，vSAN会触发新一轮的数据平衡，把之前迁移走的数据重新均匀分布到这台主机上。这种主机间的数据均衡通常也会持续一段时间，属于正常现象。

性能确认方面，我会在重建完成后的半天内，观察vSAN的延迟、IOPS指标。用esxtop也能看到vSAN设备级别的IO表现，但如果嫌麻烦，直接在vCenter的“性能”图表里看“虚拟磁盘”延迟就好。正常SATA SSD缓存盘的写延迟应该在个位数毫秒内，如果看到延迟飙升或者持续高延迟，那就要再排查是不是新盘的固件版本、缓存算法有差异。

4. 常见问题、排查技巧与我的避坑心得

4.1 实操中高频问题速查表

把这几年来处理vSAN缓存盘故障遇到的高频问题整理成了一张表，希望能帮你少走弯路。

这里要单独强调一下“主机和vc之间的时间已同步”这个告警。如果你在vSAN集群里遇到它，不用慌，很多时候它只是一个提示，并不代表故障。但如果它反复出现，我建议立刻去核对NTP配置和主机时间同步状态。vSAN集群是分布式存储，主机之间的时间漂移会直接影响到组件写入的时序和证书校验。你可以通过esxcli system time get来确认当前时间偏差，确保所有主机都指向同一个可靠NTP源。这个动作最好在vSAN集群部署的第一天就完成，而不是等出事了再补。

4.2 我个人关于vSAN缓存盘维护的几点体会

说了这么多操作细节，最后分享几个常年积累下来的运维习惯。

第一，vSAN缓存盘备件一定要准备。容量盘坏一块，磁盘组还能撑一下；缓存盘故障，整个磁盘组都要重建，备件不及时等于把集群置于长期降级状态。我在运维规范里要求，每个vSAN集群至少常备一块与现网型号一致的缓存盘，避免“等到货”期间提心吊胆。

第二，动缓存盘之前，做好标记和拍照。物理换盘最怕拔错盘。我见过有人把容量盘当成缓存盘拔了，结果整个磁盘组数据重新分布，业务半夜报警。我现在的习惯是，在vSphere Client找到故障盘后，通过服务器的指示灯功能让对应槽位亮灯，再到机房里核对一次，拔盘前再拍一张照片留底。

第三，不要把RAID0模式当成理所应当。如果你的服务器环境允许，尽量把vSAN的磁盘设置为直通模式。直通模式下，ESXi可以直接看到每块物理盘的SMART信息，故障定位更准确，更换也简单。如果因为服务器限制只能用RAID0卷，那一定要确保RAID控制器管理界面和vSphere里看到的设备状态都能对上，甚至可以在日常巡检时把RAID控制器的状态截图归档保存。

第四，重建期间不要叠加其他变更。磁盘组重建是一个高负载操作，会占用大量CPU、磁盘IO和网络带宽。我建过一个规矩：vSAN里只要有重新同步任务，集群就进入“冻结期”，禁止同时做ESXi升级、主机重启、容量扩展这些操作。这个规矩看起来保守，但真的避免了好几次因为变更叠加导致的意外。

第五，vSAN健康检查里的“重新同步状态”和“对象完整性”这两项，应该成为日常巡检的默认项。我之前有一个习惯是把健康检查报告每周导出一次PDF归档，虽然有点仪式感，但真出问题时，往前的历史报告能帮你快速定位“这个盘是什么时候开始有征兆的”。

最后再分享一个小技巧：更换完缓存盘、重新创建磁盘组之后，建议马上做一次vSAN健康检查的“高级校验”，虽然它会跑一段时间，但能非常细致地检查所有对象和磁盘的状态。我每次做完缓存盘更换都会跑一次，等结果全绿，才敢放心下班。如果检查里出现警告项，务必点进去看具体原因，很多看似不起眼的小警告，背后其实藏着下一轮故障的引子。