1. 课程导入与全景认知

在企业存储平台的演进过程中，Pure Storage 的版本升级与硬件换代往往不是一次简单的“打补丁”，而是一次涉及数据搬迁、主机路径切换、复制关系重建、策略继承与业务连续性验证的系统工程。本课程围绕“数据迁移”与“平台升级”两条主线展开，帮助学员建立从目标定义到落地验证的完整认知框架。本章作为导入章节，重点回答五个问题：为什么要做、做哪些、什么场景下做、做到什么程度算成功、以及用什么方法论保证可控。

一、目标：从“换设备”到“保业务、提能力”

Pure Storage 数据迁移与平台升级的核心目标可以归纳为三层。第一层是业务连续性目标：在迁移或升级窗口内，关键业务的中断时间必须控制在可接受范围内，通常以 RTO（恢复时间目标）和 RPO（恢复点目标）作为量化约束。例如，某核心数据库要求 RTO ≤ 15 分钟、RPO = 0，则迁移方案必须支持在线同步复制或快照一致性切换，而不能采用停机拷贝。第二层是数据完整性目标：迁移前后数据必须保持块级或文件级一致，包括卷、快照、克隆、复制链路与保护策略的继承关系。第三层是平台能力目标：升级后应获得新版本在性能、容量效率、安全合规、云集成或 NVMe 端到端支持等方面的实际收益，而不是仅仅完成硬件替换。

这三层目标之间存在优先级：业务连续性优先于数据完整性，数据完整性优先于能力收益。当窗口冲突时，应优先保证业务不中断，再通过后续阶段补齐能力优化。

二、范围：迁移与升级到底涉及哪些对象

Pure Storage 环境中的迁移与升级范围通常包括以下对象：

• 数据面：卷（Volume）、文件系统、快照（Snapshot）、克隆（Clone）、保护组（Protection Group）、Pod、ActiveCluster 配对关系。
• 主机面：iSCSI/FC/NVMe-oF 发起端、多路径软件、主机集群（如 Oracle RAC、SQL AlwaysOn、VMware vSphere 集群）。
• 复制面：FlashArray 之间的异步/同步复制、ActiveDR、ActiveCluster 仲裁链路。
• 管理面：Purity 版本、Pure1 连接、目录服务、RBAC 角色、告警与报告策略。
• 硬件面：控制器、NVMe 盘位、外置扩展柜、FC/iSCSI 交换机端口与 zoning。

范围界定的关键是“迁移单元”的划分。以卷为单元适合数据库与虚拟化场景；以保护组为单元适合应用一致性要求高的场景；以 Pod 为单元适合多租户或 ActiveCluster 场景。范围一旦确定，后续的兼容性检查、窗口规划与回退方案都围绕该单元展开。

三、典型场景：四类常见触发条件

实际项目中，迁移与升级通常由以下四类场景触发：

1. 硬件生命周期替换：旧阵列过保或容量/性能不足，需要将数据迁移到新阵列，同时保留原有保护策略。
2. Purity 版本升级：为获得新功能或修复缺陷，在同一硬件上进行无中断升级，需关注版本兼容矩阵与升级路径。
3. 架构演进：从 FC 转向 NVMe-oF、从单站点转向 ActiveCluster 双活、从本地保护转向 ActiveDR 远程复制。
4. 数据中心整合或拆分：并购、搬迁、云上云下混合部署导致的数据重新分布。

不同场景对窗口、回退和验证的要求差异很大。例如，Purity 无中断升级通常可在业务运行中完成，但仍需准备控制器逐个重启的观察点；而跨阵列迁移往往需要主机多路径配合，窗口内要完成路径切换与一致性校验。

四、成功标准：可量化、可验证、可回退

成功标准不能停留在“迁移完成”这一模糊表述。建议从五个维度定义：

其中“可回退”常被忽视。任何迁移方案在实施前都应明确回退触发条件、回退步骤和回退后的数据状态，避免出现“迁过去回不来”的被动局面。

五、整体方法论：评估—设计—演练—实施—验证—收尾

本课程采用六阶段方法论，贯穿所有章节。其核心思想是“先看清、再设计、先演练、后实施、必验证、有收尾”。下图展示了该方法论与关键输入输出、判断节点的关系。

需要强调的是，六阶段不是一次性线性流程。验证阶段若发现数据不一致或性能不达标，应触发回退或回到设计阶段调整迁移单元与窗口策略。这种“带反馈的闭环”才是方法论真正落地的方式。

六、本课程的学习路径

后续章节将依次展开：迁移前的资产发现与兼容性检查、迁移单元与窗口设计、主机多路径与 zoning 调整、Purity 升级路径与控制器重启观察、快照与克隆的一致性处理、ActiveCluster/ActiveDR 复制关系重建、迁移后性能与保护策略验证、以及常见故障的排障思路。每一章都会给出可执行的检查项、示例参数与判断依据，帮助学员在实际项目中直接复用。