1. 课程导入与HPE存储虚拟化全景
在数据中心里，业务系统对存储的要求从来不是单一的：数据库要低时延、高IOPS，虚拟化平台要并发承载成百上千台虚拟机，备份与归档要大容量、低成本，而核心交易系统还要求双活甚至多站点容灾。如果每套业务都独占一套物理阵列，结果往往是资源孤岛、利用率低下、管理复杂。HPE存储虚拟化的核心价值，正是把底层物理介质抽象为可按业务需求灵活切分、在线迁移、统一管理的存储资源池，让存储从"设备"变成"服务"。
学习目标
本课程围绕"存储虚拟化原理—HPE产品线—业务系统集成"三条主线展开。学完本章，你应当能够：说清存储虚拟化的三个层次（块级、文件级、阵列内虚拟化）及其差异；识别HPE 3PAR、Primera、Alletra三条产品线的定位与继承关系；理解业务系统集成工程的整体框架，即从需求分析、容量与性能规划、主机接入、多路径配置、数据保护到上线验证的完整链路；并能用一套可复用的方法判断某业务该落在哪类存储资源上。
存储虚拟化的三个层次
存储虚拟化并非一个单一技术，按抽象位置可分为三层。第一层是主机/网络层虚拟化，典型代表是卷管理器（LVM）和SAN网络中的虚拟化网关，它在主机或交换机侧把多个物理LUN聚合成逻辑卷，屏蔽后端差异。第二层是阵列内虚拟化，这是HPE 3PAR/Primera/Alletra的核心能力：阵列内部把物理磁盘切成小块（Chunklet），再按需组合成虚拟卷（VV），实现宽条带化、自动分层和精简配置。第三层是文件/对象层虚拟化，如分布式文件系统与对象存储，面向非结构化数据。
三层中，阵列内虚拟化对业务系统集成影响最大，因为它直接决定了LUN的呈现方式、性能特征和扩容行为。理解这一点，是后续所有配置工作的基础。
HPE存储虚拟化产品线
HPE的块存储产品线经历了清晰的演进：3PAR是早期旗舰，以ASIC加速、多控制器全活、Thin Provisioning和Peer Persistence双活著称；Primera在3PAR基础上强化了100%可用性架构、AI驱动的InfoSight运维和更低的时延，面向关键业务；Alletra则是面向云原生与混合云的新一代平台，其中Alletra 9000延续Primera的高端基因，Alletra 6000面向中端通用业务，并通过Data Services Cloud Console实现云上统一管理。三者并非互相替代的孤立产品，而是同一虚拟化内核在不同代际、不同定位上的延续。
业务系统集成工程的整体框架
把存储虚拟化能力真正交付给业务，需要一套工程化流程。它通常包含六个环节：需求分析（业务类型、IO特征、容量增长、RTO/RPO）、容量与性能规划（根据IOPS、时延、容量确定盘型与RAID级别）、主机接入（HBA、Zoning、LUN映射、多路径软件）、数据保护（快照、克隆、远程复制）、上线验证（性能压测、故障切换演练）、运维移交（监控、告警、容量趋势）。
以一个典型示例说明规划过程：某业务系统要求稳定提供 8000 IOPS、平均时延低于 2ms、初始可用容量 5TB、三年增长至 15TB。假设单块 SSD 可稳定提供 1500 IOPS，考虑 RAID5 的写惩罚与控制器开销，实际按 70% 有效能力折算，则所需 SSD 数量约为 8000 ÷ (1500 × 0.7) ≈ 8 块。容量侧，若采用 3.84TB SSD、RAID5（4+1），8 块盘可用容量约 3.84 × 6 ≈ 23TB，满足三年需求。此时可规划一个精简配置的虚拟卷，初始分配 5TB，开启自动分层与快照策略。以上参数为教学示例，实际项目需以真实业务压测数据为准。
核心价值与常见误区
存储虚拟化带来的价值可归纳为四点：提升利用率（精简配置让容量按实际写入增长）、简化管理（统一资源池、统一策略）、增强弹性（在线扩容、在线迁移、双活容灾）、降低成本（减少闲置容量与设备数量）。
实践中常见的误区有三个：一是把精简配置当成"无限容量"，忽视容量监控导致写满告警；二是只关注容量而忽略IOPS与时延，把高负载数据库放到低性能盘池；三是跳过多路径与故障演练，导致单链路故障时业务中断。这些问题的根源，都是没有把存储虚拟化能力与业务实际需求对齐。