容量被切成孤岛
不同主机和业务各自预留空间，利用率不高却无法灵活调配。
解决：将本地磁盘组织为可按策略使用的共享资源池。平台视图
数据平台关系
- 01 数据路径
- 02 存储池
- 03 故障域
- 04 保护
02 / 系统集成与基础架构
SAN 与存储虚拟化
把主机本地磁盘、存储策略、故障域和容量管理组织成统一资源池，解决传统 SAN 扩容复杂、资源利用率低和故障边界难判断的问题。
存储对象主机 / 磁盘组 / 资源池
技术重点策略 / 故障域 / 容量
交付结果统一 / 冗余 / 可运营
01 / 问题剖面
存储虚拟化解决的不是“把盘放一起”，而是“让资源池可预测地承载业务”
传统存储环境中，容量、性能、控制器、链路和故障域常常分别管理。扩容要停机或重新规划，业务增长后才发现容量和性能无法同时满足，故障时也很难判断影响范围。
SAN 与存储虚拟化的核心，是把主机本地磁盘、磁盘组、策略和故障域放回同一套资源模型中，让不同业务可以按性能、容量和冗余要求获得合适的存储服务。
实施时不仅要看软件平台，还要核对硬件兼容、网络带宽、磁盘类型、容量增长、重建窗口和运维工具，避免资源池上线后才暴露结构性问题。
三类核心问题
把重复出现的建设、连接和交接问题收敛成三类，先判断影响，再安排技术工作。
性能与冗余无法同时核对
只看容量或单个磁盘指标，无法判断策略落地后的实际性能和保护级别。
解决：把策略、性能、冗余和故障域一起验证。节点或磁盘故障影响不可预测
重建、降级和容量预留没有被纳入运行计划，故障处理依赖临场判断。
解决：明确故障域、重建窗口和恢复条件。存储策略没有进入交付资料
后续人员只能看到容量，无法知道不同业务应使用什么策略。
解决：交付策略、容量、告警和运行操作基线。02 / 架构关系
从主机磁盘到统一资源池，存储边界需要被看见
存储虚拟化把物理磁盘、磁盘组、主机、网络和策略连接成可管理的资源关系。
架构设计需要说明数据如何分布、策略如何保护、故障域如何隔离，以及主机与存储网络如何共同承载读写和重建流量。
这样才能在容量增长、节点维护和磁盘故障时，判断业务是否仍处于可接受的性能与保护边界内。
四层关系
从现场连接一直追到业务运行
把系统放在关系中看，才能知道一项设备变更会影响哪些链路、权限、应用和运维动作。下面四层不是孤立模块，而是从承载条件到业务结果的连续路径。
主机与磁盘组
确认磁盘类型、缓存、容量和主机分布。
策略与保护
按业务要求定义副本、纠删、性能和可用性策略。
网络与故障域
隔离存储流量并确认节点、机架和链路的故障边界。
容量与运行
持续监控容量、重建、告警和策略合规。
03 / 技术范围
把 vSAN 方案拆成五个可核对的技术面
存储虚拟化的范围不能只写“建设资源池”，还要说明硬件、网络、策略、容量与交付如何落地。
从兼容性到运行策略，每个技术面都决定资源池能否稳定扩展和恢复。
将这些面拆开核对，可以把平台能力转成现场可执行的安装、配置和验收任务。
硬件兼容
核对主机、磁盘、控制器、固件和版本兼容关系。
主机 / 磁盘 / 固件 / 版本网络连接
确认存储网络带宽、延迟、MTU、冗余和端口配置。
带宽 / 延迟 / MTU / 冗余存储策略
按业务等级定义副本、性能、空间效率和故障响应。
副本 / 性能 / 空间 / 可用性容量与重建
预留增长、故障重建和维护窗口，避免池内资源被耗尽。
增长 / 重建 / 预留 / 窗口运行交接
移交容量、策略、告警、节点、磁盘和日常操作说明。
容量 / 策略 / 告警 / 操作04 / 连接与资源
存储网络决定资源池的性能上限和故障半径
vSAN 的数据读写、同步和重建都依赖稳定的网络路径，网络配置需要和存储策略一起验证。
要同时关注吞吐、延迟、链路冗余、交换机配置和网络隔离，避免业务高峰或重建流量互相影响。
通过实际读写、故障切换和重建验证，才能知道资源池在异常状态下的真实边界。
路径与冗余
确认主机到交换网络和节点之间的双路径。
流量隔离
把存储、管理、业务和迁移流量按边界分开。
性能验证
验证带宽、延迟、丢包和高峰期的资源池行为。
故障切换
测试链路、交换机、节点和磁盘故障下的业务影响。
05 / 容量与运行
资源池要持续回答：容量、策略和故障预留还够不够
存储虚拟化上线后，容量、策略合规、节点状态、磁盘健康和告警需要进入持续运行视图。
资源池不是一次建设后不再变化的对象。业务增长、节点扩展、磁盘替换和策略调整都会改变可用容量与重建边界。
通过日常巡检、容量趋势、告警分级和变更记录，把平台状态转成运维人员能快速判断的信号。
容量趋势
按业务增长和保护策略计算真实可用容量。
策略合规
发现业务策略与实际存储配置之间的偏差。
节点与磁盘
监控健康、温度、性能、重建和更换状态。
变更与扩展
在容量、版本和维护窗口明确后再执行扩展。
06 / 实施与交付
从兼容性检查到策略验收，把资源池交付成可维护平台
vSAN 项目需要把硬件、网络、平台、策略、业务和运维团队放进同一条交付链路。
- 01
兼容性与现状
核对硬件、版本、网络、磁盘和现有业务。
- 02
集群与网络
完成主机、磁盘组、交换网络和冗余配置。
- 03
策略与资源池
建立资源池、存储策略、容量和故障域。
- 04
业务测试
验证性能、切换、重建、告警和业务访问。
- 05
运行交接
移交策略、容量、节点、磁盘和日常巡检方法。
07 / 交付资料
让存储策略、容量和故障边界成为可继续使用的资料
存储虚拟化的运行价值需要通过策略、容量、告警和故障处理资料延续到项目之后。
集群与磁盘
保留主机、磁盘组、磁盘类型、节点和故障域关系。
策略与容量
记录业务等级、存储策略、可用容量和增长预留。
网络与测试
保存端口、MTU、带宽、延迟、切换和重建结果。
告警与操作
说明巡检、告警分级、磁盘更换、扩展和回退操作。
FAQ
常见问题
先确认服务边界和现有条件，再决定实施范围与后续支持方式。
vSAN 与传统 SAN 的核心区别是什么？
传统 SAN 通常以独立阵列提供存储，vSAN 则将集群主机本地磁盘组织为统一资源池，并通过策略管理容量、性能和冗余。
存储虚拟化是否只需要关注软件？
不是。硬件兼容、磁盘类型、网络带宽、MTU、故障域、容量预留和运维能力都会影响最终结果。
资源池扩容需要停机吗？
是否停机取决于现有架构、版本、业务窗口和扩容方式，实施前需要先确认依赖、回退和验证条件。