简介这份PDF文档是VMware vSAN 6.7官方技术白皮书面向虚拟化架构师、数据中心运维人员及超融合方案选型者系统讲解vSAN作为领先HCI解决方案的核心能力与部署思路。资源包内仅含1个PDF文件大小约709KB轻量便携适合随时查阅与方案参考。白皮书围绕闪存优化存储、原生HCI加密、混合云部署、简化管理及主动式支持等模块展开并给出降低多达50% TCO、从两节点扩展至六十四节点等关键数据帮助读者理解vSAN如何基于x86服务器构建软件定义存储并与SDDC体系无缝集成。目前已有174人学习下载可作为评估超融合基础架构、撰写选型报告或规划私有云与边缘计算部署时的实用参考资料。1. vSan 6.7 白皮书到底在讲什么从一份 PDF 到一套能落地的超融合方案如果你手里只有一份《VMware vSan 6.7 技术白皮书.pdf》翻开头几页大概率会看到一堆存储策略、磁盘组、见证主机之类的名词然后就开始犯困。但这份文档真正值钱的地方不是它告诉你有多少功能而是它把一套软件定义存储的完整逻辑摊开给你看——怎么用几台标准 x86 服务器把本地磁盘聚合成一个共享存储池让 vSphere 集群里的虚拟机直接跑在上面不再依赖外置 SAN。这就是 vSan 6.7 的核心命题。它适合谁适合那些正在评估超融合、想用 vSphere 生态做私有云、或者单纯想搞明白“分布式存储到底怎么在 ESXi 内核里跑起来”的运维和架构人员。白皮书本身不是安装手册但它给出的架构约束和配置边界是你动手前必须吃透的东西。接下来我不复述 PDF 目录而是按一个工程师真正落地的顺序把 vSan 6.7 从选型、组网、磁盘组配置到排错的链路拆开讲。2. vSan 6.7 的架构底座为什么它敢把存储塞进 ESXi 内核2.1 从“外置存储”到“内核态分布式存储”的选型逻辑传统 vSphere 架构里ESXi 主机通过 FC 或 iSCSI 连到外置存储阵列虚拟机文件放在 LUN 上。这套模式稳定但扩展麻烦存储控制器容易成为瓶颈扩容要买新柜子机架空间和功耗也跟着涨。vSan 6.7 的做法是把存储层直接做成 ESXi 内核里的一个分布式对象存储系统。每台主机贡献本地磁盘SSD 做缓存层HDD 或 SSD 做容量层这些磁盘被组织成磁盘组磁盘组再聚合成一个跨主机的数据存储。虚拟机对象被切分成组件按存储策略分布到不同主机的磁盘组上。这个设计带来的直接好处是扩展线性化加一台主机就加一份 CPU、内存和存储集群整体容量和性能同步上升。但代价是网络变得极其关键——vSan 节点之间的数据同步、重建、见证通信全走网络网络一抖存储就跟着抖。白皮书里反复强调的“网络要求”本质就在这里。选型时你还要想清楚一件事vSan 6.7 支持混合架构SSD 缓存 HDD 容量和全闪架构SSD 缓存 SSD 容量。混合架构便宜但容量层是机械盘随机读性能受限于盘本身全闪架构性能好但每台主机的磁盘组配置有更细的讲究。如果你的业务是大量小文件随机读写混合架构的 HDD 容量层会成为瓶颈这时候要么上全闪要么把缓存层加大。2.2 磁盘组、缓存层与容量层的配置边界磁盘组是 vSan 的最小故障域单元。每台主机可以有一个或多个磁盘组每个磁盘组包含一块缓存盘和多块容量盘。缓存盘负责写缓冲和读缓存容量盘负责持久化数据。白皮书里给出的硬性约束是一个磁盘组最多 1 块缓存盘 7 块容量盘每台主机最多 5 个磁盘组。这些数字不是随便定的缓存盘一旦故障整个磁盘组离线所以缓存盘的数量决定了故障域的大小。配置时有一个容易翻车的点缓存盘和容量盘的型号最好一致至少同一磁盘组内容量盘要一致。如果混用不同容量或不同性能的盘vSan 在组件分布时会按最慢的盘来算整体性能被拖累。另外缓存盘不能用于容量容量盘也不能当缓存角色是固定的。全闪架构下缓存盘和容量盘都是 SSD但缓存盘的写入寿命消耗更快选型时要看 DWPD每日全盘写入次数指标别拿消费级 SSD 硬扛。网络方面vSan 6.7 要求专用 vMotion 和 vSan 流量分离推荐 10GbE 起步。如果只有 1GbE混合架构勉强能跑但全闪架构下重建和同步会慢到让你怀疑人生。白皮书里提到的“网络多播”在 6.7 里已经改为单播配置时不用再折腾 IGMP snooping但交换机端口组的 MTU 建议设成 9000减少大包分片带来的额外开销。3. 从零搭一套 vSan 6.7 集群组网、磁盘组与存储策略的实操路径3.1 网络与 ESXi 主机的准备步骤动手之前先把物理网络理清楚。每台 ESXi 主机至少需要两块物理网卡做 vSan 流量或者用一块 10GbE 网卡配 VLAN 子接口。我一般会单独划一个 VLAN 给 vSan不和管理、vMotion 混跑。交换机侧把对应端口配成 trunk允许 vSan VLAN 通过MTU 设成 9000如果端到端都支持。ESXi 主机安装完先加 vSphere 集群把主机拖进去。然后每台主机创建 vSwitch 或分布式交换机添加 VMkernel 适配器勾选 vSan 流量。这一步的坑是VMkernel 适配器的 IP 必须和 vSan 网络在同一子网且不能和管理网卡复用同一块物理网卡做 teaming否则流量争抢会导致 vSan 心跳超时。# 在 ESXi 主机上查看 vSan 网络配置通过 SSH esxcli vsan network list # 输出示例 # VmkNic Interface Enabled ... # vmk1 vSwitch1 true这个命令用来确认 vSan 流量是否绑到了正确的 VMkernel 网卡。如果 Enabled 是 false说明勾选没生效需要重新配置。参数上esxcli vsan network ip add可以手动添加但更推荐在 vCenter 界面操作避免手滑打错 IP。3.2 磁盘组的创建与缓存盘选型参数主机加入集群后在 vCenter 里选中集群进入“配置 vSan 磁盘管理”可以看到每台主机的本地磁盘。创建磁盘组时先选缓存盘再选容量盘。缓存盘建议选写密集型 SSD容量盘按业务容量需求选。如果盘上有旧分区先清空分区表否则 vSan 会报“磁盘不健康”。# 通过 ESXi Shell 查看磁盘列表和健康状态 esxcli storage core device list | grep -E Display Name|Size|Status # 查看 vSan 磁盘组状态 esxcli vsan storage listesxcli vsan storage list会列出每个磁盘组的缓存盘和容量盘以及磁盘组的健康状态。如果某块盘显示“Unhealthy”通常是分区残留或固件问题。解决方法是进“磁盘管理”里手动声明磁盘或者用partedUtil清空分区。注意清空分区会丢数据操作前确认盘是空的。磁盘组创建后vSan 数据存储会自动挂载到集群所有主机。这时候你可以在“vSan 数据存储”里看到总容量和可用容量。如果容量显示为 0检查磁盘组是否创建成功以及主机是否全部在线。3.3 存储策略的配置与虚拟机部署验证vSan 的核心优势之一是存储策略驱动。你不需要手动指定虚拟机放哪块盘而是定义策略vSan 自动按策略分布组件。常见策略项包括允许的故障数FTT、故障域类型主机或磁盘、条带宽度、强制置备、对象空间预留等。策略项推荐值生产环境说明允许的故障数1 或 2FTT1 至少 3 台主机FTT2 至少 5 台主机故障域类型主机按主机隔离避免单台主机多磁盘组同时故障条带宽度2 或 4提高并发读性能但增加组件数量强制置备否精简置备节省空间但需监控容量对象空间预留0%除非有严格性能要求否则不预留创建策略后新建虚拟机时选这个策略然后跑一个简单的 I/O 测试。我一般用fio在 Linux 虚拟机里测 4K 随机写和 1M 顺序读看 IOPS 和延迟是否符合预期。如果延迟高得离谱先查网络丢包再查缓存盘是否成为瓶颈。# 在 Linux 虚拟机内用 fio 测试 vSan 数据存储性能 fio --namerandwrite --ioenginelibaio --iodepth32 --rwrandwrite --bs4k --direct1 --size1G --numjobs4 --runtime60 --group_reporting这个命令模拟 4 个并发任务做 4K 随机写iodepth32表示队列深度direct1绕过文件系统缓存。如果 IOPS 低于预期检查虚拟机是否跨主机分布以及 vSan 网络是否跑在 10GbE 上。参数上--runtime60表示跑 60 秒--size1G是每个任务的文件大小生产环境测试可以加大。4. vSan 6.7 避坑指南从“磁盘不健康”到“组件缺席”的排查记录4.1 磁盘组创建失败现象、原因与解决现象在 vCenter 里创建磁盘组时提示“无法创建磁盘组磁盘不健康”。原因通常是磁盘上有旧分区表或残留的 vSan 元数据。解决方法是进 ESXi Shell用partedUtil删除所有分区然后重新声明磁盘。如果盘是之前 vSan 集群用过的还要清除 vSan 分区esxcli vsan storage remove -d device。注意操作前确认盘上无有用数据。4.2 虚拟机性能突然下降缓存盘写穿与网络丢包现象虚拟机运行一段时间后读写延迟从几毫秒飙到几百毫秒。原因可能是缓存盘写穿write-through导致容量层直接承受写入压力或者 vSan 网络出现丢包。排查时先看缓存盘的写入寿命和当前负载如果缓存盘 IOPS 跑满考虑换更高性能的盘或增加磁盘组。网络方面用vmkping测试 vSan VMkernel 之间的连通性和丢包率丢包超过 0.1% 就会影响性能。4.3 主机维护模式无法进入组件重建卡住现象把主机放入维护模式时vSan 提示“正在重建组件”但进度条卡住不动。原因是集群剩余容量不足无法容纳重建所需的组件副本。解决方法是先加一台主机或清理无用虚拟机释放空间再重试。如果必须立即维护可以选择“确保可访问性”模式但这样会降低数据冗余只适合临时操作。4.4 见证主机部署失败网络与资源检查现象在双主机集群里部署见证主机时提示“无法部署见证主机”。原因通常是见证主机所在的网络无法和 vSan 主机通信或者资源不足。见证主机只需要 2 核 CPU、4GB 内存和少量磁盘但它必须能 ping 通所有 vSan 主机的 vSan VMkernel。检查 DNS 解析和防火墙规则确保 12345 端口vSan 见证通信开放。4.5 存储策略不合规组件缺席与重新同步现象虚拟机摘要里显示“存储策略不合规”vSan 健康里看到“组件缺席”。原因是某台主机离线或磁盘组故障导致组件副本数不足。解决方法是先恢复故障主机或磁盘组vSan 会自动重新同步。如果主机无法恢复需要手动移除故障主机并重新创建缺失的组件。重新同步期间集群性能会下降建议在业务低峰期操作。5. vSan 6.7 进阶技巧用 esxcli 和性能图表做容量与健康预判5.1 用 esxcli vsan 命令做日常巡检vSan 的健康状态不能只看 vCenter 的绿灯有些隐患在早期没有告警。我习惯每天跑一遍esxcli vsan cluster get和esxcli vsan storage list看集群状态和磁盘组健康。如果esxcli vsan cluster get里的“集群健康”显示“降级”说明有组件需要关注。另外esxcli vsan debug limit get可以看当前 vSan 的 IOPS 和带宽限制如果接近上限说明需要扩容或优化。# 查看 vSan 集群健康摘要 esxcli vsan cluster get # 查看 vSan 性能统计需在 ESXi 主机上启用 esxcli vsan debug limit getesxcli vsan cluster get输出里的“集群健康”和“成员状态”是关键字段。如果成员状态是“离线”先查网络再查主机是否宕机。esxcli vsan debug limit get显示的是 vSan 内部限流值如果实际 IOPS 接近这个值说明存储层已经满负荷需要考虑加磁盘组或加主机。5.2 容量预警别等 vSan 数据存储爆了才扩容vSan 数据存储的容量告警默认在 70% 和 80% 触发但真正危险的是组件重建时的临时空间需求。如果集群容量超过 80%一旦有主机故障重建可能因为空间不足而失败。我一般把容量控制在 70% 以下留出至少一台主机容量的缓冲。在 vCenter 的“vSan 容量”里可以看“预留容量”和“可重建容量”如果可重建容量小于单台主机容量就该加盘或加主机了。5.3 一个具体技巧用存储策略模拟器验证策略合规性vSan 6.7 的 vCenter 里有一个“存储策略模拟器”可以在不实际部署虚拟机的情况下检查某个策略在当前集群能否满足。路径是“策略和配置文件 存储策略 模拟”。选好策略和集群点“模拟”它会告诉你需要多少主机、多少磁盘组以及当前集群是否合规。这个工具在规划扩容时特别有用避免拍脑袋买硬件。我自己的习惯是每次变更前先跑一遍模拟器确认策略能落地再动手。有一次没跑直接给一个 FTT2 的策略到 3 主机集群结果虚拟机创建失败组件一直缺席血泪教训。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/29 21:29:52 · 阅读 1.2k vSan 6.7 超融合实战：从架构原理到磁盘组配置与排错指南
简介这份PDF文档是VMware vSAN 6.7官方技术白皮书面向虚拟化架构师、数据中心运维人员及超融合方案选型者系统讲解vSAN作为领先HCI解决方案的核心能力与部署思路。资源包内仅含1个PDF文件大小约709KB轻量便携适合随时查阅与方案参考。白皮书围绕闪存优化存储、原生HCI加密、混合云部署、简化管理及主动式支持等模块展开并给出降低多达50% TCO、从两节点扩展至六十四节点等关键数据帮助读者理解vSAN如何基于x86服务器构建软件定义存储并与SDDC体系无缝集成。目前已有174人学习下载可作为评估超融合基础架构、撰写选型报告或规划私有云与边缘计算部署时的实用参考资料。1. vSan 6.7 白皮书到底在讲什么从一份 PDF 到一套能落地的超融合方案如果你手里只有一份《VMware vSan 6.7 技术白皮书.pdf》翻开头几页大概率会看到一堆存储策略、磁盘组、见证主机之类的名词然后就开始犯困。但这份文档真正值钱的地方不是它告诉你有多少功能而是它把一套软件定义存储的完整逻辑摊开给你看——怎么用几台标准 x86 服务器把本地磁盘聚合成一个共享存储池让 vSphere 集群里的虚拟机直接跑在上面不再依赖外置 SAN。这就是 vSan 6.7 的核心命题。它适合谁适合那些正在评估超融合、想用 vSphere 生态做私有云、或者单纯想搞明白“分布式存储到底怎么在 ESXi 内核里跑起来”的运维和架构人员。白皮书本身不是安装手册但它给出的架构约束和配置边界是你动手前必须吃透的东西。接下来我不复述 PDF 目录而是按一个工程师真正落地的顺序把 vSan 6.7 从选型、组网、磁盘组配置到排错的链路拆开讲。2. vSan 6.7 的架构底座为什么它敢把存储塞进 ESXi 内核2.1 从“外置存储”到“内核态分布式存储”的选型逻辑传统 vSphere 架构里ESXi 主机通过 FC 或 iSCSI 连到外置存储阵列虚拟机文件放在 LUN 上。这套模式稳定但扩展麻烦存储控制器容易成为瓶颈扩容要买新柜子机架空间和功耗也跟着涨。vSan 6.7 的做法是把存储层直接做成 ESXi 内核里的一个分布式对象存储系统。每台主机贡献本地磁盘SSD 做缓存层HDD 或 SSD 做容量层这些磁盘被组织成磁盘组磁盘组再聚合成一个跨主机的数据存储。虚拟机对象被切分成组件按存储策略分布到不同主机的磁盘组上。这个设计带来的直接好处是扩展线性化加一台主机就加一份 CPU、内存和存储集群整体容量和性能同步上升。但代价是网络变得极其关键——vSan 节点之间的数据同步、重建、见证通信全走网络网络一抖存储就跟着抖。白皮书里反复强调的“网络要求”本质就在这里。选型时你还要想清楚一件事vSan 6.7 支持混合架构SSD 缓存 HDD 容量和全闪架构SSD 缓存 SSD 容量。混合架构便宜但容量层是机械盘随机读性能受限于盘本身全闪架构性能好但每台主机的磁盘组配置有更细的讲究。如果你的业务是大量小文件随机读写混合架构的 HDD 容量层会成为瓶颈这时候要么上全闪要么把缓存层加大。2.2 磁盘组、缓存层与容量层的配置边界磁盘组是 vSan 的最小故障域单元。每台主机可以有一个或多个磁盘组每个磁盘组包含一块缓存盘和多块容量盘。缓存盘负责写缓冲和读缓存容量盘负责持久化数据。白皮书里给出的硬性约束是一个磁盘组最多 1 块缓存盘 7 块容量盘每台主机最多 5 个磁盘组。这些数字不是随便定的缓存盘一旦故障整个磁盘组离线所以缓存盘的数量决定了故障域的大小。配置时有一个容易翻车的点缓存盘和容量盘的型号最好一致至少同一磁盘组内容量盘要一致。如果混用不同容量或不同性能的盘vSan 在组件分布时会按最慢的盘来算整体性能被拖累。另外缓存盘不能用于容量容量盘也不能当缓存角色是固定的。全闪架构下缓存盘和容量盘都是 SSD但缓存盘的写入寿命消耗更快选型时要看 DWPD每日全盘写入次数指标别拿消费级 SSD 硬扛。网络方面vSan 6.7 要求专用 vMotion 和 vSan 流量分离推荐 10GbE 起步。如果只有 1GbE混合架构勉强能跑但全闪架构下重建和同步会慢到让你怀疑人生。白皮书里提到的“网络多播”在 6.7 里已经改为单播配置时不用再折腾 IGMP snooping但交换机端口组的 MTU 建议设成 9000减少大包分片带来的额外开销。3. 从零搭一套 vSan 6.7 集群组网、磁盘组与存储策略的实操路径3.1 网络与 ESXi 主机的准备步骤动手之前先把物理网络理清楚。每台 ESXi 主机至少需要两块物理网卡做 vSan 流量或者用一块 10GbE 网卡配 VLAN 子接口。我一般会单独划一个 VLAN 给 vSan不和管理、vMotion 混跑。交换机侧把对应端口配成 trunk允许 vSan VLAN 通过MTU 设成 9000如果端到端都支持。ESXi 主机安装完先加 vSphere 集群把主机拖进去。然后每台主机创建 vSwitch 或分布式交换机添加 VMkernel 适配器勾选 vSan 流量。这一步的坑是VMkernel 适配器的 IP 必须和 vSan 网络在同一子网且不能和管理网卡复用同一块物理网卡做 teaming否则流量争抢会导致 vSan 心跳超时。# 在 ESXi 主机上查看 vSan 网络配置通过 SSH esxcli vsan network list # 输出示例 # VmkNic Interface Enabled ... # vmk1 vSwitch1 true这个命令用来确认 vSan 流量是否绑到了正确的 VMkernel 网卡。如果 Enabled 是 false说明勾选没生效需要重新配置。参数上esxcli vsan network ip add可以手动添加但更推荐在 vCenter 界面操作避免手滑打错 IP。3.2 磁盘组的创建与缓存盘选型参数主机加入集群后在 vCenter 里选中集群进入“配置 vSan 磁盘管理”可以看到每台主机的本地磁盘。创建磁盘组时先选缓存盘再选容量盘。缓存盘建议选写密集型 SSD容量盘按业务容量需求选。如果盘上有旧分区先清空分区表否则 vSan 会报“磁盘不健康”。# 通过 ESXi Shell 查看磁盘列表和健康状态 esxcli storage core device list | grep -E Display Name|Size|Status # 查看 vSan 磁盘组状态 esxcli vsan storage listesxcli vsan storage list会列出每个磁盘组的缓存盘和容量盘以及磁盘组的健康状态。如果某块盘显示“Unhealthy”通常是分区残留或固件问题。解决方法是进“磁盘管理”里手动声明磁盘或者用partedUtil清空分区。注意清空分区会丢数据操作前确认盘是空的。磁盘组创建后vSan 数据存储会自动挂载到集群所有主机。这时候你可以在“vSan 数据存储”里看到总容量和可用容量。如果容量显示为 0检查磁盘组是否创建成功以及主机是否全部在线。3.3 存储策略的配置与虚拟机部署验证vSan 的核心优势之一是存储策略驱动。你不需要手动指定虚拟机放哪块盘而是定义策略vSan 自动按策略分布组件。常见策略项包括允许的故障数FTT、故障域类型主机或磁盘、条带宽度、强制置备、对象空间预留等。策略项推荐值生产环境说明允许的故障数1 或 2FTT1 至少 3 台主机FTT2 至少 5 台主机故障域类型主机按主机隔离避免单台主机多磁盘组同时故障条带宽度2 或 4提高并发读性能但增加组件数量强制置备否精简置备节省空间但需监控容量对象空间预留0%除非有严格性能要求否则不预留创建策略后新建虚拟机时选这个策略然后跑一个简单的 I/O 测试。我一般用fio在 Linux 虚拟机里测 4K 随机写和 1M 顺序读看 IOPS 和延迟是否符合预期。如果延迟高得离谱先查网络丢包再查缓存盘是否成为瓶颈。# 在 Linux 虚拟机内用 fio 测试 vSan 数据存储性能 fio --namerandwrite --ioenginelibaio --iodepth32 --rwrandwrite --bs4k --direct1 --size1G --numjobs4 --runtime60 --group_reporting这个命令模拟 4 个并发任务做 4K 随机写iodepth32表示队列深度direct1绕过文件系统缓存。如果 IOPS 低于预期检查虚拟机是否跨主机分布以及 vSan 网络是否跑在 10GbE 上。参数上--runtime60表示跑 60 秒--size1G是每个任务的文件大小生产环境测试可以加大。4. vSan 6.7 避坑指南从“磁盘不健康”到“组件缺席”的排查记录4.1 磁盘组创建失败现象、原因与解决现象在 vCenter 里创建磁盘组时提示“无法创建磁盘组磁盘不健康”。原因通常是磁盘上有旧分区表或残留的 vSan 元数据。解决方法是进 ESXi Shell用partedUtil删除所有分区然后重新声明磁盘。如果盘是之前 vSan 集群用过的还要清除 vSan 分区esxcli vsan storage remove -d device。注意操作前确认盘上无有用数据。4.2 虚拟机性能突然下降缓存盘写穿与网络丢包现象虚拟机运行一段时间后读写延迟从几毫秒飙到几百毫秒。原因可能是缓存盘写穿write-through导致容量层直接承受写入压力或者 vSan 网络出现丢包。排查时先看缓存盘的写入寿命和当前负载如果缓存盘 IOPS 跑满考虑换更高性能的盘或增加磁盘组。网络方面用vmkping测试 vSan VMkernel 之间的连通性和丢包率丢包超过 0.1% 就会影响性能。4.3 主机维护模式无法进入组件重建卡住现象把主机放入维护模式时vSan 提示“正在重建组件”但进度条卡住不动。原因是集群剩余容量不足无法容纳重建所需的组件副本。解决方法是先加一台主机或清理无用虚拟机释放空间再重试。如果必须立即维护可以选择“确保可访问性”模式但这样会降低数据冗余只适合临时操作。4.4 见证主机部署失败网络与资源检查现象在双主机集群里部署见证主机时提示“无法部署见证主机”。原因通常是见证主机所在的网络无法和 vSan 主机通信或者资源不足。见证主机只需要 2 核 CPU、4GB 内存和少量磁盘但它必须能 ping 通所有 vSan 主机的 vSan VMkernel。检查 DNS 解析和防火墙规则确保 12345 端口vSan 见证通信开放。4.5 存储策略不合规组件缺席与重新同步现象虚拟机摘要里显示“存储策略不合规”vSan 健康里看到“组件缺席”。原因是某台主机离线或磁盘组故障导致组件副本数不足。解决方法是先恢复故障主机或磁盘组vSan 会自动重新同步。如果主机无法恢复需要手动移除故障主机并重新创建缺失的组件。重新同步期间集群性能会下降建议在业务低峰期操作。5. vSan 6.7 进阶技巧用 esxcli 和性能图表做容量与健康预判5.1 用 esxcli vsan 命令做日常巡检vSan 的健康状态不能只看 vCenter 的绿灯有些隐患在早期没有告警。我习惯每天跑一遍esxcli vsan cluster get和esxcli vsan storage list看集群状态和磁盘组健康。如果esxcli vsan cluster get里的“集群健康”显示“降级”说明有组件需要关注。另外esxcli vsan debug limit get可以看当前 vSan 的 IOPS 和带宽限制如果接近上限说明需要扩容或优化。# 查看 vSan 集群健康摘要 esxcli vsan cluster get # 查看 vSan 性能统计需在 ESXi 主机上启用 esxcli vsan debug limit getesxcli vsan cluster get输出里的“集群健康”和“成员状态”是关键字段。如果成员状态是“离线”先查网络再查主机是否宕机。esxcli vsan debug limit get显示的是 vSan 内部限流值如果实际 IOPS 接近这个值说明存储层已经满负荷需要考虑加磁盘组或加主机。5.2 容量预警别等 vSan 数据存储爆了才扩容vSan 数据存储的容量告警默认在 70% 和 80% 触发但真正危险的是组件重建时的临时空间需求。如果集群容量超过 80%一旦有主机故障重建可能因为空间不足而失败。我一般把容量控制在 70% 以下留出至少一台主机容量的缓冲。在 vCenter 的“vSan 容量”里可以看“预留容量”和“可重建容量”如果可重建容量小于单台主机容量就该加盘或加主机了。5.3 一个具体技巧用存储策略模拟器验证策略合规性vSan 6.7 的 vCenter 里有一个“存储策略模拟器”可以在不实际部署虚拟机的情况下检查某个策略在当前集群能否满足。路径是“策略和配置文件 存储策略 模拟”。选好策略和集群点“模拟”它会告诉你需要多少主机、多少磁盘组以及当前集群是否合规。这个工具在规划扩容时特别有用避免拍脑袋买硬件。我自己的习惯是每次变更前先跑一遍模拟器确认策略能落地再动手。有一次没跑直接给一个 FTT2 的策略到 3 主机集群结果虚拟机创建失败组件一直缺席血泪教训。希望帮到你。本文还有配套的精品资源点击获取