1. 课程导入与全景认知
在虚拟化环境中，存储系统不再是“后台的一块磁盘”，而是直接决定虚拟机密度、业务弹性、故障恢复速度和运维效率的关键基础设施。Pure Storage 虚拟化业务存储系统设计的核心任务，是把全闪存阵列的稳定低时延、数据缩减、快照与复制能力，与 VMware vSphere、Microsoft Hyper-V、KVM 等虚拟化平台的资源调度、集群高可用和业务连续性要求对齐，形成一套可落地、可验证、可扩展的存储架构。
本课程面向已经具备一定存储与虚拟化基础、需要承担方案设计或运维优化工作的工程师。我们不把 Pure Storage 当作孤立设备来讲解，而是把它放进“业务—虚拟化—存储—网络—保护”这条完整链路中，逐层拆解设计目标、参数关系、配置方法和验证手段。学完本章，你应当能够回答三个问题：这套系统为谁服务、由哪些层次构成、后续 29 章分别解决什么问题。
设计目标：从业务需求倒推存储能力
虚拟化业务存储系统的设计目标通常不是“买一台最快的阵列”，而是同时满足以下五类约束：
- 性能确定性：虚拟机密度提高后，随机读写 IOPS 和时延必须保持稳定，避免“平均很快、峰值卡顿”。Pure Storage 全闪存阵列通过 NVMe 后端和全局磨损均衡，把时延波动控制在较小范围，但前提是前端队列深度、多路径和虚拟机磁盘类型配置合理。
- 容量效率：虚拟化场景中大量虚拟机磁盘存在重复数据块，数据缩减（去重、压缩）直接影响可用容量和采购成本。设计时需要区分“逻辑容量”和“物理容量”，并预留快照、克隆和元数据开销。
- 业务连续性：通过快照、克隆、ActiveCluster 双活或异步复制，把 RPO/RTO 目标转化为具体的保护策略和保护组配置。
- 可运维性：Pure1 云端管理、REST API、vSphere 插件等工具应纳入日常监控与容量规划流程，而不是事后补装。
- 可扩展性：横向扩展（增加阵列节点）和纵向扩展（增加盘位/容量）的边界要提前明确，避免业务增长后被迫迁移。
这五类目标之间存在权衡。例如，过度追求数据缩减可能增加元数据开销；过度追求双活可能提高网络和授权成本。设计过程本质上是在业务 SLA、预算和运维能力之间找到可验证的平衡点。
核心价值：为什么虚拟化场景需要专门设计
Pure Storage 在虚拟化业务中的价值，可以归纳为“三个对齐”：
第一，性能与虚拟机生命周期对齐。虚拟机创建、克隆、迁移、快照、删除等操作会带来突发 IO。Pure Storage 的 Purity 操作系统通过卷（Volume）和一致性组（Consistency Group）管理这些操作，使克隆和快照接近瞬时完成，减少运维窗口。
第二，容量与数据缩减对齐。虚拟化环境中，同一操作系统模板可能被复制数十次。阵列级去重和压缩可以在不改变虚拟机使用方式的前提下，显著降低物理容量占用。但设计时必须确认哪些数据不适合缩减（如已加密或已压缩的镜像），避免误判容量收益。
第三，保护与业务等级对齐。不同虚拟机对 RPO/RTO 的要求不同。通过保护组、快照计划和复制策略，可以把“核心数据库”“一般应用”“测试环境”分层保护，而不是对所有卷采用同一策略。
整体架构层次：从物理介质到业务虚拟机
为了便于后续章节展开，我们把系统划分为六个层次，自下而上依次是：
- 物理硬件层：NVMe 闪存模块、控制器节点、内部交换网络、电源与散热。
- Purity 存储操作系统层：负责数据缩减、快照、克隆、复制、加密、QoS 等核心服务。
- 存储资源层：卷、一致性组、保护组、主机与主机组、端口与子网。
- 存储网络层：Fibre Channel 或 iSCSI 链路、多路径、分区（Zoning）与访问控制。
- 虚拟化平台层：vSphere/Hyper-V/KVM 的存储适配器、数据存储（Datastore）、集群与 HA/DRS 策略。
- 业务虚拟机层：虚拟机磁盘、操作系统、应用与业务 SLA。
这六层不是简单堆叠，而是存在明确的依赖与反馈关系：上层业务需求决定下层资源规格，下层性能与容量变化又反过来影响上层虚拟机密度和迁移策略。下面的 SVG 用结构关系图表达这一层次模型，并标注每层的关键对象和设计关注点。
理解这张层次图后，后续章节的学习路径就清晰了：先建立物理与 Purity 层的能力边界，再逐层向上完成资源映射、网络配置、虚拟化集成和保护策略设计，最后通过性能验证与容量规划形成闭环。
学习路径：30 章如何组织
本课程按“认知—设计—实现—验证—优化”推进，但不会机械重复同一套流程。前几章建立架构与术语基础；中间章节分别深入卷与一致性组、主机与端口、FC/iSCSI 网络、vSphere/Hyper-V/KVM 集成、快照与克隆、复制与双活、QoS 与性能调优；后段进入容量规划、监控告警、故障排查和方案复盘。每一章都会给出可操作的参数示例、配置片段或判断依据，而不是停留在概念介绍。
以虚拟机密度估算为例，假设某业务集群有 200 台虚拟机，平均每台配置 80 GB 虚拟磁盘，逻辑容量约 16 TB。若阵列实测数据缩减比为 3:1，并预留 20% 快照与元数据开销，则物理容量需求约为 16 TB ÷ 3 × 1.2 ≈ 6.4 TB。这个示例说明：容量设计必须同时考虑逻辑容量、缩减比和预留系数，三者缺一不可。后续章节会进一步展开如何获取真实缩减比、如何按业务分层设置预留。