06-数据存储管理

从“能挂载”走向“可运营”

上一篇完成了 vSwitch、端口组、VMkernel 与物理网络的衔接。本篇回到虚拟化平台最容易积累隐患的位置：数据存储。很多环境在建设初期只关心 LUN 或 NFS 共享能否挂载，等虚拟机数量增长后，才逐渐暴露容量水位失控、快照膨胀、精简置备超分、路径降级、数据存储命名混乱、迁移窗口不可控和退役时误删依赖等问题。

数据存储管理并不等于“在 vCenter 里新建一个 Datastore”。它是从底层设备、主机访问路径、文件系统或协议、虚拟磁盘布局，到容量、性能、可用性、备份和生命周期治理的一整套控制方法。一个真正可运营的数据存储，至少要回答以下问题：

1. 哪些 ESXi 主机能够访问它，是否所有集群成员视图一致？
2. 它承载什么等级的业务，性能、可用性和恢复目标是什么？
3. 容量使用是实际分配、逻辑承诺还是底层阵列精简后的数字？
4. 发生延迟、路径异常或容量告急时，如何快速收集证据并止损？
5. 扩容、迁移和退役时，如何证明没有遗留虚拟机、ISO、模板、备份代理或心跳依赖？

本文以 vCenter Server Appliance 与 ESXi 8.0 Update 3 系列为验证基线，重点覆盖 VMFS、NFS、vSAN 与 vVols 的选择边界，VMFS/NFS 数据存储的配置与验收，Storage vMotion、Storage DRS、存储策略、容量治理、路径管理和安全退役。具体阵列兼容性、最大值、插件能力和支持协议仍应以 Broadcom Compatibility Guide、目标存储厂商文档与当前补丁版本为准。

一张图建立数据存储治理模型

这张图把“存储介质”和“平台治理能力”分开：VMFS、NFS、vSAN、vVols 是不同的数据承载方式；存储策略、Storage vMotion、容量告警和备份则负责让数据存储持续符合业务目标。运维设计应先确定业务服务等级，再选择承载方式，不能反过来因为已有某台阵列就把全部工作负载放在同一存储池。

四类常见承载方式

VMFS 与 NFS 并不存在绝对优劣。块存储更接近传统 SAN 的运维模型，NFS 更接近共享文件系统模型；最终选择要看现有团队能力、阵列特性、网络条件、恢复体系和厂商支持。vSAN 与 vVols 更强调策略驱动，但也要求平台、网络和存储团队共同维护策略语义，不能只由单一管理员凭经验配置。

数据存储、设备与虚拟磁盘不是同一个对象

排障前必须区分三个层次：

• 存储设备：ESXi 识别到的 LUN、NVMe Namespace、SCSI 设备或网络存储端点。
• 数据存储：在设备或共享上创建并由 vSphere 清单管理的逻辑容器，例如 VMFS Datastore 或 NFS Datastore。
• 虚拟机文件：数据存储中的 VMX、VMDK、NVRAM、日志、快照、交换文件、ISO 和模板等对象。

“数据存储不可访问”可能是设备消失、路径全部失效、NFS 服务器不可达、导出权限改变，也可能只是某台主机没有挂载；“虚拟机无法开机”也不一定是数据存储故障，可能是文件锁、空间不足、权限或虚拟磁盘链异常。先定位层次，再执行修复，能够避免在阵列、网络和 vCenter 之间盲目切换。

规划：先定义服务等级，再创建数据存储

建立可落地的存储等级

生产环境不建议按阵列品牌或管理员姓名命名存储等级。更有效的方式是围绕业务目标定义，例如：

等级定义不能只写“高、中、低”。需要把可验证指标写清楚：告警水位、延迟观察阈值、恢复点目标、恢复时间目标、允许维护窗口、是否支持 Storage vMotion、是否允许快照、是否纳入 Storage DRS、是否允许精简置备超分。

命名规范必须表达故障域

一个可读的数据存储名称应让值班人员快速判断站点、介质、协议、等级和序号。例如：

SH01-SAN-FC-GOLD-01
SH01-NAS-NFS-SILVER-01
BJ02-VSAN-GOLD-CL01
LAB-ISCSI-BRONZE-01

名称不宜塞入所有技术细节。阵列序列号、LUN ID、NAA、导出路径、控制器、存储池和责任人应记录在 CMDB 或数据存储登记表中。名称负责快速识别，资产记录负责精确追踪。

建议每个数据存储至少维护以下字段：

容量不能只看 vCenter 的 Free Space

数据存储容量至少有四个视角：

1. vSphere 逻辑容量：数据存储总容量、已用和可用空间。
2. 虚拟磁盘承诺量：厚置备、精简置备、快照和交换文件的逻辑占用。
3. 阵列或 NAS 物理容量：底层存储池实际消耗、压缩、去重、快照和保留空间。
4. 保护系统容量：备份副本、复制日志、快照保留和恢复缓存。

精简置备环境中，vCenter 显示还有空间，并不代表阵列池一定有足够物理容量；反过来，删除虚拟磁盘后，VMFS 内释放空间也不一定立即回收到阵列。必须同时监控数据存储与后端存储池，建立从 VM 到 Datastore、LUN/Share、Pool 的映射。

VMFS 数据存储配置 walkthrough

前置条件

创建 VMFS 数据存储前，先完成以下检查：

1. 存储阵列已将目标 LUN 映射给所有预期 ESXi 主机。
2. FC Zoning、iSCSI 网络、CHAP 或 NVMe over Fabrics 连接按厂商设计完成。
3. 目标设备出现在所有集群主机，NAA 标识和容量一致。
4. 设备未被其他集群、操作系统或旧数据存储使用。
5. 阵列、HBA、驱动、固件、ESXi 版本组合位于当前兼容矩阵。
6. 已确认多路径策略采用阵列厂商推荐值，而不是统一套用固定策略。

在 ESXi Shell 上可用以下命令建立基线：

esxcli storage core device list
esxcli storage core path list
esxcli storage nmp device list
esxcli storage filesystem list

如果刚完成 LUN 映射，可在 vSphere Client 对主机或集群执行存储适配器重新扫描。也可以在维护窗口按目标环境使用 ESXCLI 重新扫描适配器，但执行前应确认不会触发大量无关设备扫描或影响正在故障的路径。

esxcli storage core adapter list
esxcli storage core adapter rescan --all

通过 vSphere Client 创建

常见路径为：

Datacenter 或 Host
  -> Storage
  -> Datastores
  -> New Datastore

选择 VMFS 后，依次完成：

1. 输入符合规范的数据存储名称。
2. 选择唯一且正确的设备。
3. 选择 VMFS 版本；新建生产数据存储通常使用当前支持的 VMFS 6。
4. 确认分区和容量使用范围。
5. 检查摘要中的设备标识、容量、主机和文件系统。
6. 创建后确认所有集群成员均已挂载且状态正常。

不要仅凭容量判断 LUN。不同阵列可能提供多个同容量设备，选错设备会导致数据覆盖。变更单中应明确 NAA、阵列卷名、LUN ID 和目标集群，操作时逐项核对。

创建后的验收

esxcli storage filesystem list
esxcli storage core device list -d <naa-id>
esxcli storage core path list -d <naa-id>

验收至少包括：

• 所有集群主机看到相同的 Datastore 名称与 UUID。
• 每台主机的设备容量一致。
• 路径数量和状态符合设计，无 Dead、Off 或异常频繁切换。
• 多路径策略符合阵列厂商建议。
• 创建测试目录或测试虚拟机后可正常读写。
• 测试 VM 能在允许的主机之间执行计算 vMotion 或 Storage vMotion。
• vCenter 已配置容量、连接状态和延迟相关告警。

VMFS 扩容的正确顺序

当底层 LUN 扩容后，不要直接假设 ESXi 会自动使用新增容量。推荐顺序：

1. 在阵列侧完成扩容并确认任务结束。
2. 对所有相关主机重新扫描存储适配器。
3. 确认 ESXi 识别到新的设备容量。
4. 在 vSphere Client 执行 Increase Datastore Capacity。
5. 选择扩展现有 extent，而不是在不清楚影响时增加新的 span。
6. 扩容后再次验证所有主机看到一致容量。
7. 观察阵列池容量、告警和复制关系是否同步更新。

扩容前需要确认阵列快照、复制、容灾和备份产品是否对卷大小变化有额外要求。数据存储扩容通常比缩容容易得多；VMFS 数据存储不应被当作可随意在线缩小的普通文件系统。需要缩小容量时，通常采用新建目标数据存储、迁移工作负载、卸载旧数据存储和重新规划卷的方式。

NFS 数据存储配置 walkthrough

NFS 设计重点

NFS 数据存储的故障边界主要在网络、名称解析、导出权限和 NAS 服务。部署前应明确：

• 使用受支持的 NFS 版本及 NAS 厂商推荐方式。
• NFS 流量使用的 VMkernel、VLAN、上联和 MTU。
• NAS 服务地址是否为稳定 IP 或受支持的多路径/会话设计。
• 导出路径和 ESXi 主机访问权限。
• 防火墙与中间网络是否允许所需协议。
• 是否需要 Kerberos，以及身份、DNS、时间同步是否具备条件。

NFS 存储网络应避免与高峰业务、备份或 vMotion 无控制地争抢带宽。即使共享物理上联，也应通过 VLAN、流量控制、队列和容量规划维持可预测性。

创建 NFS 数据存储

在 vSphere Client 创建 NFS Datastore 时，填写：

Name: SH01-NAS-NFS-SILVER-01
NFS version: 按 NAS 与 vSphere 支持矩阵选择
Server: 10.50.0.20
Folder: /exports/vsphere/prod01
Hosts: CLU-PROD-01 的全部主机

创建前从各主机的存储 VMkernel 验证网络：

vmkping -I vmk2 10.50.0.20
vmkping -I vmk2 -d -s 8972 10.50.0.20

第二条仅适用于端到端计划使用 9000 MTU 的环境。若网络仍为 1500 MTU，不应照抄 Jumbo 测试。MTU 必须在 VMkernel、vSwitch/vDS、物理交换机和 NAS 接口全路径一致。

创建后可检查：

esxcli storage nfs list
esxcli storage nfs41 list
esxcli storage filesystem list

具体命令与输出字段会随 ESXi 版本和 NFS 版本不同，应以当前 ESXCLI 帮助和官方文档为准。

NFS 常见错误

导出权限不匹配：NAS 只允许某个主机 IP，而集群其他主机无法挂载，导致迁移或 HA 后虚拟机不可用。

使用不稳定名称：通过 DNS 名称挂载但 DNS 记录或解析路径不可靠，故障时所有主机同时失去服务定位。

混淆 NFS 3 与 NFS 4.1 行为：不同版本在连接、会话、安全和多路径能力上不同，不能把一套参数机械复制到另一套。

只测 ICMP，不测真实负载：Ping 正常并不能证明 NAS 服务、导出权限、吞吐和延迟正常。验收需要实际创建测试 VM、写入数据、迁移和观察延迟。

删除 NAS 导出后再卸载：正确顺序应先清理 vSphere 依赖并从所有主机卸载，再在 NAS 端停止导出。反向操作会留下 inaccessible Datastore 和大量告警。

存储路径与多路径治理

块存储环境中，ESXi 通常通过 Native Multipathing Plugin 与阵列类型对应的 SATP、PSP 或厂商插件管理路径。常见路径状态包括 Active、Standby、Dead、Disabled 等。运维人员不应只看“还有一条路径可用”，而应判断是否已经从冗余状态降级。

建立路径基线

esxcli storage core path list
esxcli storage nmp device list
esxcli storage core device stats get -d <naa-id>

基线应记录：

• 每个设备期望路径数。
• 每条路径对应的 HBA、Target、LUN 和控制器。
• 正常状态下的 Active/Optimized 与 Active/Non-Optimized 分布。
• 路径选择策略。
• 阵列故障切换模型。
• 故障时由谁检查 FC Fabric、IP 网络和阵列控制器。

如果一台主机有 4 条路径，故障后剩 2 条，虚拟机可能仍正常运行，但平台已经失去部分冗余。告警系统应把这种状态视为需要处理的降级事件，而不是等到所有路径丢失才报警。

不要盲目修改路径策略

Round Robin、Most Recently Used、Fixed 或厂商插件策略的适用条件不同。某些阵列对 IO Operations Limit、ALUA、控制器所有权或队列深度有明确要求。未经兼容性与厂商建议确认，批量修改策略可能造成路径抖动、性能不稳定甚至不可用。

安全做法是：

1. 根据阵列型号和 ESXi 版本确认推荐策略。
2. 在测试主机或非关键 LUN 上验证。
3. 记录修改前后策略与路径状态。
4. 观察延迟、错误计数和阵列端口负载。
5. 具备恢复原策略的命令和窗口。

Storage vMotion：迁移不是简单复制文件

Storage vMotion 可以在虚拟机保持运行时迁移其配置文件与虚拟磁盘，也可用于改变虚拟磁盘格式或存储位置。它是容量治理、阵列迁移、维护和分层放置的重要工具，但会同时消耗源存储、目标存储、主机 CPU、网络与阵列带宽。

迁移前检查

迁移应分批执行。不要在容量告警触发后立即把几十台高 IO 虚拟机同时迁往同一目标。先迁移一台低风险测试 VM，验证目标性能、备份、快照、HA 和监控，再逐步扩大批次。

迁移后的验收

1. VM 配置文件和所有 VMDK 位于预期数据存储。
2. 存储策略状态为 Compliant 或符合预期。
3. 客户机文件系统和应用服务正常。
4. 备份产品重新识别并完成下一次备份。
5. 源数据存储不再遗留快照、ISO、交换文件或孤立目录。
6. 迁移期间与迁移后延迟未持续异常。
7. CMDB 和存储映射记录已更新。

Storage DRS 与数据存储集群

数据存储集群将多个数据存储组成资源池，Storage DRS 可基于空间和 IO 负载提供初始放置与迁移建议，具体自动化能力取决于版本、许可、配置和存储类型。它的价值不是替代容量规划，而是减少数据存储之间长期不均衡。

适合纳入同一集群的数据存储

应尽量具备相似特征：

• 相同或相近的业务等级。
• 相似介质和性能能力。
• 相同保护与复制策略。
• 相同主机访问范围。
• 相近的运维窗口和责任团队。

不要把 Gold 全闪存与 Archive 大容量存储放入同一数据存储集群后依赖 Storage DRS 自动判断业务价值。平台看到的是空间、延迟和规则，无法自动理解某台 ERP 数据库的业务优先级。

初期采用建议模式

新建 Storage DRS 时，建议先使用手动建议模式，观察一段时间：

1. 建议是否符合业务放置规则。
2. 迁移是否总在备份窗口发生。
3. 空间阈值是否过于敏感。
4. IO 指标是否受阵列缓存、复制或突发任务影响。
5. VM Affinity/Anti-Affinity 规则是否合理。

确认建议稳定后，再评估自动化级别。自动化不应绕过变更窗口和业务约束，尤其是数据库、超大 VMDK、复制设备和备份代理。

容量治理：把“空间不足”变成可预测事件

建议水位

通用起点可以是：

这些阈值不是固定标准。数据存储越小，预留空间的绝对值越重要；高变更、高快照、高增长工作负载需要更大缓冲。阵列精简池还要设置更早的物理容量告警，因为多个数据存储可能共享同一个后端池。

快照治理

VMware 快照用于短期变更保护，不是备份。快照会形成增量磁盘链，持续写入会让 delta 文件增长，合并时产生额外 IO 和空间需求。常见治理规则：

• 创建时必须填写用途、责任人和过期时间。
• 生产快照默认保留小时或少量天数，而不是长期保留。
• 每日检查超期快照和异常大快照。
• 删除前确认数据存储有足够合并空间。
• 合并期间监控延迟，不在高峰批量处理。
• 备份软件产生的快照应由备份流程正常清理。

PowerCLI 可用于清点快照，示例只展示查询思路：

Connect-VIServer vcsa01.lab.example.com

Get-VM |
  Get-Snapshot |
  Select-Object VM, Name, Created, SizeGB, Description |
  Sort-Object Created

执行删除前应确认快照用途和业务窗口，不能把自动发现直接等同于自动删除。

精简置备与空间回收

精简置备提高容量利用率，也引入超分风险。治理重点包括：

1. 监控虚拟磁盘逻辑承诺量。
2. 监控数据存储实际使用量。
3. 监控阵列存储池物理使用量。
4. 确认删除数据后的空间回收路径。
5. 避免所有数据存储在同一阵列池上同时高比例超分。

VMFS 6 支持自动空间回收相关能力，但具体行为、粒度、优先级和阵列支持应按当前 vSphere 文档与存储设备能力确认。不要因为启用了 UNMAP 就假设空间会立即回收，也不要在高峰期主动发起大规模回收而不观察阵列延迟。

数据存储变更与安全退役

退役操作最危险的部分不是 Unmount，而是遗漏依赖。一个看似没有 VM 的数据存储，仍可能承载 ISO、模板、内容库、HA 心跳、备份代理缓存、日志目录、交换文件或某台关机 VM 的文件。

依赖检查清单

在 vSphere Client 中检查：

• Virtual Machines。
• Templates。
• Datastore Browser 中的目录。
• ISO 挂载关系。
• Content Library。
• HA Datastore Heartbeating。
• Storage DRS 与 Datastore Cluster 成员关系。
• Host Swap、Scratch、Syslog 或 Core Dump 配置。

在操作系统和工具侧检查：

• 备份软件是否仍引用该数据存储。
• 监控、报表和自动化脚本是否使用旧名称。
• CMDB、容量报表和成本分摊是否仍保留映射。
• 阵列快照、复制、容灾和一致性组是否包含对应卷。

推荐退役顺序

1. 标记为待退役，禁止新工作负载放置。
2. 迁移 VM、模板、ISO 和其他文件。
3. 验证数据存储浏览器无有效依赖。
4. 从 Storage DRS 或数据存储集群中移出。
5. 确认 HA 心跳不再依赖。
6. 在维护窗口从所有主机卸载 Datastore。
7. 对块设备执行 Detach，确认没有主机继续使用。
8. 存储团队撤销主机映射或 NAS 导出。
9. 阵列侧删除卷或回收容量。
10. 更新 CMDB、监控、备份和变更记录。

必须保持“先 vSphere、后网络/阵列”的顺序。先删除 LUN、撤销 Zoning 或关闭 NFS 导出，会让 ESXi 留下失效设备和不可访问数据存储，增加 APD/PDL 风险与清理难度。

APD 与 PDL 的运维含义

• APD（All Paths Down）：主机暂时无法通过任何路径访问设备，但无法确认设备是否永久消失。常见于网络、Fabric、控制器或路径中断。
• PDL（Permanent Device Loss）：存储系统明确告知设备永久不可用或已被移除。

两者对虚拟机、主机响应和恢复动作的影响不同。遇到全路径异常时，不应立即重启所有主机。先判断阵列是否仍提供设备、其他主机是否可见、故障是暂时链路中断还是永久撤销映射，并按官方与阵列厂商流程处理。

故障排查 runbook

排障时先记录时间线、影响范围和最近变更，再按“主机视图、访问路径、网络、阵列、工作负载”收集证据。不要一开始就执行 Rescan、Restart Agent、Unmount 或重启主机，因为这些动作会改变现场。

场景一：数据存储显示 Inaccessible

先回答四个问题：

1. 是一台主机异常，还是整个集群异常？
2. 是一个数据存储异常，还是同一阵列的多个数据存储异常？
3. 块设备还在不在，还是 NFS 共享无法连接？
4. 故障前是否发生阵列维护、网络变更、Zoning、LUN Masking 或 NAS 权限调整？

块存储检查：

esxcli storage filesystem list
esxcli storage core device list
esxcli storage core path list
esxcli storage nmp device list

NFS 检查：

esxcli storage nfs list
esxcli storage nfs41 list
vmkping -I <storage-vmk> <nas-ip>

判断逻辑：

• 仅一台主机异常：优先检查该主机 HBA、VMkernel、上联、路径和挂载状态。
• 同一 Fabric 上多台主机异常：检查交换机、Zoning、阵列端口或控制器。
• 只有一个 LUN 异常：检查卷映射、LUN Masking、设备状态和阵列任务。
• 所有 NFS Datastore 异常：检查 NAS 服务、网关、VLAN、MTU、DNS 和导出策略。

场景二：延迟突然升高

高延迟不应只用单一平均值判断。需要区分：

• 设备延迟是否升高。
• 内核排队是否升高。
• 客户机内应用延迟是否同步升高。
• 只有某个数据存储异常，还是整台主机/阵列异常。
• 是否与备份、快照合并、Storage vMotion、病毒扫描、复制或批处理时间重合。

可收集：

esxtop

在 esxtop 的磁盘设备和虚拟机视图中观察当前版本提供的延迟、队列和 IO 指标。不同版本字段含义和阈值应以官方性能文档为准，不应把固定数字当成所有阵列的通用故障线。

止损顺序通常是：

1. 暂停非关键批量迁移和备份任务。
2. 停止创建新快照和高 IO 部署。
3. 确认阵列是否重建、降级或控制器故障。
4. 将部分低风险 VM 迁往健康数据存储。
5. 降低并发，保留核心业务 IO。
6. 与存储团队联合分析主机、Fabric、阵列三侧时间线。

场景三：容量接近 100%

不要先删除不认识的目录。按可逆性从高到低处理：

1. 暂停新建 VM、大磁盘扩容和非必要快照。
2. 查找超期快照、失败备份残留和异常日志。
3. 迁移低风险 VM 或冷数据。
4. 扩容后端卷并扩展数据存储。
5. 检查精简置备阵列池是否同样告急。
6. 确认删除和空间回收后容量真实下降。

Datastore Browser 中的目录可能属于关机 VM、模板、备份代理或已从清单移除但仍需保留的系统。任何手工删除都必须先根据 VMX、VMDK 描述文件、CMDB、备份和业务负责人确认归属。

场景四：部分主机看不到新 LUN

检查顺序：

1. 阵列 Host/Host Group 是否包含全部主机 Initiator。
2. FC WWPN、iSCSI IQN 或 NVMe 标识是否登记正确。
3. Zoning 与 LUN Masking 是否一致。
4. 主机 HBA/软件 iSCSI 适配器状态是否正常。
5. 存储网络 VMkernel、VLAN、MTU 和路由是否一致。
6. 重新扫描后设备是否出现。
7. 设备是否因重复签名、旧分区或过滤规则被特殊处理。

不要为了让设备出现而在不清楚原因时执行强制挂载、重新签名或格式化。设备上可能存在其他集群正在使用的 VMFS。

场景五：Storage vMotion 卡住或失败

优先检查：

• 源和目标容量。
• 目标数据存储连通性。
• 快照链和虚拟磁盘锁。
• VM 是否连接 ISO 或使用特殊设备。
• 存储策略兼容性。
• vCenter 任务事件和 ESXi 日志。
• 阵列延迟、队列和并发迁移数量。

迁移失败后，先确认 VM 当前运行和文件位置，不要立即删除源目录。vSphere 可能已完成部分复制但未切换，或已回滚到源。只有在清单、虚拟磁盘链和任务结果都明确后，才处理残留。

自动化审计与日常操作

PowerCLI 清点示例

以下示例用于生成基础容量清单：

Connect-VIServer vcsa01.lab.example.com

Get-Datastore |
  Select-Object Name,
    Type,
    @{N='CapacityGB';E={[math]::Round($_.CapacityGB, 2)}},
    @{N='FreeGB';E={[math]::Round($_.FreeSpaceGB, 2)}},
    @{N='UsedPercent';E={
      [math]::Round((1 - $_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
    }} |
  Sort-Object UsedPercent -Descending

查询数据存储上的虚拟机：

Get-Datastore -Name 'SH01-SAN-FC-GOLD-01' |
  Get-VM |
  Select-Object Name, PowerState, ProvisionedSpaceGB, UsedSpaceGB

自动化脚本应具备异常处理、只读默认、凭据保护和审计记录。用于告警的脚本可以自动运行；用于迁移、删除快照、卸载或分离设备的脚本必须增加审批、白名单、并发限制和回退检查。

每日、每周、每月基线

每日：

• 检查 Inaccessible、APD/PDL、路径降级和容量高水位。
• 检查超期快照、失败备份和异常大增长。
• 观察核心数据存储延迟是否偏离基线。
• 核对阵列池是否有重建、控制器或磁盘告警。

每周：

• 输出数据存储容量趋势和预计耗尽日期。
• 检查集群主机视图是否一致。
• 检查多路径数量和策略漂移。
• 检查 Storage DRS 建议、规则和迁移活动。
• 核对孤立目录、ISO 和临时文件。

每月：

• 复核业务等级与实际放置。
• 抽查备份恢复和 Storage vMotion。
• 核对 vSphere、阵列、Fabric/NAS 兼容性与补丁风险。
• 更新 CMDB 中 Datastore-LUN/Share-Pool 映射。
• 评估未来 90 天容量、采购和迁移计划。

生产设计反模式

一个巨大数据存储承载所有业务

大数据存储减少对象数量，但扩大容量、性能和变更故障域。核心数据库、通用应用、测试环境、模板和备份代理混在一起，任何快照膨胀或高 IO 任务都会影响全部对象。应按业务等级、故障域和运维边界拆分，而不是追求“管理页面看起来简单”。

用数据存储空闲量代替阵列容量

精简置备和共享池环境中，这是最危险的误判之一。必须把后端池纳入同一告警与容量报表。

长期保留快照

快照不是低成本备份。长期快照增加容量、性能和合并风险，也让恢复链更复杂。

所有主机路径策略完全相同

统一不等于正确。不同阵列、协议、设备类型和厂商插件可能需要不同策略。应统一“按兼容性和厂商基线管理”，而不是统一某一个策略值。

先撤销阵列映射，再清理 vSphere

这会制造不可访问设备、APD/PDL、告警和残留对象。退役必须先疏散依赖、卸载、分离，再回收阵列资源。

容量告急时批量 Storage vMotion

迁移本身会产生额外 IO，并可能把压力转移到目标。应先止住快照、备份和新交付，再按业务优先级小批迁移。

验收清单

完成本篇配置后，可按以下清单自检：

• [ ] 数据存储名称能表达站点、协议、等级和序号。
• [ ] CMDB 记录了 Datastore、设备/共享、后端池和责任人映射。
• [ ] 所有集群主机看到一致的数据存储和容量。
• [ ] 块存储路径数、状态和策略符合阵列建议。
• [ ] NFS VMkernel、VLAN、MTU、导出权限和 NAS 服务均已验证。
• [ ] 容量告警覆盖 Datastore 与后端存储池。
• [ ] 快照具备用途、责任人和过期时间。
• [ ] Storage vMotion 已用测试 VM 验证。
• [ ] Storage DRS 规则和自动化级别符合业务窗口。
• [ ] 备份、恢复和空间回收路径经过验证。
• [ ] 数据存储退役流程明确先 vSphere、后阵列/NAS。
• [ ] 故障排查记录主机、网络/Fabric、阵列和工作负载四侧证据。

总结

数据存储管理的核心不是记住 VMFS 或 NFS 的创建菜单，而是建立从业务等级到底层容量和访问路径的可追踪关系。VMFS、NFS、vSAN 与 vVols 提供不同承载模型；存储策略、Storage vMotion、Storage DRS、容量告警、备份和退役流程让这些承载模型进入可运营状态。

生产环境应先定义服务等级和故障域，再选择数据存储；同时监控 vSphere 逻辑容量和阵列物理容量；把快照视为短期变更工具；把路径降级视为故障而不是“尚能运行”；把迁移和退役设计成带验证、回退和依赖检查的流程。做到这些后，存储问题会从临近满盘或全路径中断时的被动救火，转变为可预测、可审计、可演练的日常治理。

下一篇将进入 HA 与 DRS，讨论当主机故障、资源争用和维护窗口出现时，集群如何基于共享存储、网络和准入控制维持虚拟机可用性。

验证环境说明：

• vCenter：vCenter Server Appliance 8.0 Update 3 系列
• ESXi：VMware ESXi 8.0 Update 3 系列
• 管理方式：vSphere Client、ESXCLI、PowerCLI
• 典型存储：FC/iSCSI VMFS 6、NFS、vSAN 或受支持的 vVols 阵列
• 研究与撰写日期：2026-06-15
• 兼容性边界：阵列、HBA、驱动、固件、VASA Provider、协议和路径策略必须按当前 Broadcom Compatibility Guide 与存储厂商文档复核

参考资料

1. Broadcom TechDocs: VMware vSphere 8.0 Product Documentation - https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0.html
2. Broadcom Compatibility Guide - https://compatibilityguide.broadcom.com/
3. Broadcom Developer: VMware vSphere Automation SDKs and PowerCLI Documentation - https://developer.broadcom.com/
4. Broadcom Knowledge Base: VMware vSphere Storage troubleshooting and operational articles - https://knowledge.broadcom.com/
5. VMware PowerCLI Cmdlet Reference: Get-Datastore, Get-VM, Get-Snapshot - https://developer.broadcom.com/powercli/latest/