📚 课程目录第2章 Pure Storage平台架构与升级影响面

2. Pure Storage平台架构与升级影响面

在动手做数据迁移或平台升级之前，必须先建立一张清晰的“平台地图”。Pure Storage 的产品体系并不是单一存储阵列，而是由 FlashArray、FlashBlade、Pure1 与 Evergreen 体系共同构成的组合：前两者承载数据服务，Pure1 提供云端管理与遥测，Evergreen 则决定硬件与软件如何持续演进。升级影响面之所以复杂，正是因为一次操作往往同时牵动这四层中的多个组件与依赖关系。

一、四个核心对象各自承担什么

FlashArray 是面向块与文件工作负载的统一存储阵列，核心是 Purity 操作系统。它对外提供 iSCSI、Fibre Channel、NVMe-oF 等块协议，以及 SMB、NFS 文件服务。阵列内部由控制器（Controller）、NVMe 盘位（DirectFlash）、NVRAM 写缓存和主机接口卡组成，双控制器通过内部 PCIe 交换结构互连，形成 Active-Active 高可用。升级时，Purity 版本、控制器固件、盘位固件、主机接口卡固件是四个需要分别确认的层面。

FlashBlade 是面向非结构化数据的横向扩展平台，核心是 Purity//FB。它由刀片（Blade）、交换模块（Fabric）、管理模块组成，数据以对象和文件形式分布在全刀片集群上。与 FlashArray 的“双控”不同，FlashBlade 的升级更强调集群级一致性：刀片固件、Fabric 固件、Purity//FB 版本必须按官方兼容矩阵协同推进，否则可能出现刀片重启或数据重建。

Pure1 是云端管理与智能运维平台，通过 Pure1 Connect 从阵列采集遥测数据，提供容量预测、性能分析、健康评估和升级建议。它本身不承载业务数据，但升级前查看 Pure1 的兼容性报告和升级路径建议，是判断“能不能升、先升什么”的关键依据。

Evergreen 体系 是 Pure 的“永不中断升级”架构承诺，包含 Evergreen//Forever（订阅式硬件与软件持续更新）、Evergreen//Flex（按需订阅）、Evergreen//One（存储即服务）等模式。它的技术基础是控制器与盘位解耦、无数据迁移的控制器更换，以及 Purity 的在线升级能力。理解 Evergreen，才能理解为什么很多升级可以做到业务不中断。

二、升级涉及的核心组件与依赖关系

一次典型的 Purity 升级，表面上是“升一个版本”，实际牵动以下依赖链：

Purity 版本：决定功能集与 API 行为，是升级的主对象。
控制器固件：与 Purity 版本绑定，通常随 Purity 升级一并更新。
盘位固件（DFM）：DirectFlash 模块固件，需与 Purity 兼容。
主机接口卡固件：FC、iSCSI、NVMe-oF 卡固件，影响协议兼容性。
复制与保护关系：ActiveCluster、ActiveDR、异步复制对两端版本有对称性要求。
Pure1 连接：升级期间遥测可能短暂中断，需确认不影响支持服务。
主机侧多路径与驱动：如 VMware NMP、Linux DM-Multipath、Windows MPIO，需确认与目标 Purity 版本兼容。

这些依赖不是并列的，而是有先后与约束：Purity 版本是根节点，固件与协议兼容性是其子约束，复制关系与主机侧则构成外部依赖。升级前必须按“兼容矩阵 → 复制关系 → 主机侧 → 阵列本体”的顺序逐层确认。

三、升级影响面的实际判断方法

把上面的依赖关系落到操作层面，升级前应完成以下确认。以 FlashArray 从 Purity 6.4.x 升级到 6.5.x 为例（示例参数，实际以官方矩阵为准）：

# 1. 查看当前版本与组件状态（示例）
purearray list --controller
# 输出示例：
# Name       Model    Version    Status
# ctrl0      FA-X70   6.4.8      ready
# ctrl1      FA-X70   6.4.8      ready

# 2. 检查盘位固件版本
purearray list --drive
# 关注 DFM 版本是否满足 6.5.x 最低要求

# 3. 检查复制关系两端版本
purearray list --connection
# ActiveCluster 要求两端 Purity 版本一致或兼容

# 4. 检查主机侧多路径状态
# VMware：esxcli storage nmp device list
# Linux：multipath -ll

判断逻辑是：若 Pure1 兼容性报告显示“可升级”，且复制两端版本满足对称要求，主机侧多路径无异常，则可进入升级窗口。若复制关系两端版本差距过大，需先升级对端或解除复制关系，否则升级可能触发复制中断。

注意：FlashArray 与 FlashBlade 的升级节奏不同。FlashArray 通常可在线滚动升级控制器，业务不中断；FlashBlade 的集群升级可能涉及刀片重启，需确认数据重建窗口与业务容忍度。两者不可套用同一套升级窗口假设。

四、Evergreen 如何改变升级影响面

传统存储升级往往意味着“换阵列 + 数据迁移”，影响面覆盖业务停机、数据拷贝、主机重新映射。Evergreen 体系通过控制器与盘位解耦，把升级拆成两个独立动作：换控制器时数据留在原盘位，新控制器接管后无需迁移；Purity 在线升级则在双控滚动模式下完成，主机多路径自动切换。这样，升级影响面从“全栈停机”收缩为“单路径短暂切换 + 固件更新窗口”。

但 Evergreen 并不消除依赖。换控制器前仍需确认新控制器型号与现有盘位、主机接口卡、Purity 版本的兼容性；Evergreen//One 模式下，升级节奏由服务方编排，用户侧需确认维护窗口与业务 SLA。理解这一点，才能在升级规划中正确划分“谁负责、何时做、影响谁”。

实践建议：把 Pure1 的兼容性报告作为升级前的第一道闸门，把复制关系与主机侧多路径作为第二道闸门，把 Evergreen 的维护窗口作为第三道闸门。三道闸门全部通过，再执行升级，可显著降低回退概率。

总结来看，Pure Storage 平台架构的升级影响面，本质是“Purity 版本为根、固件与协议为枝、复制与主机侧为外部依赖、Evergreen 为升级方式”的四层结构。看清这四层，才能把一次升级从“碰运气”变成“可规划、可验证、可回退”的工程动作。