2. Pure Storage平台架构与升级对象

在动手做任何一次数据迁移或平台升级之前，必须先弄清楚一件事：我们到底在升级什么、迁移什么。Pure Storage 的产品组合并不是一个单一系统，而是由 FlashArray、FlashBlade、Pure1 以及贯穿其中的 Evergreen 架构共同构成的平台体系。它们各自承担不同的数据服务职责，又通过统一的运维与订阅模型彼此关联。理解这套架构，是判断"哪些组件需要升级、哪些版本必须匹配、哪些对象可以原地保留"的前提。

四个核心对象的分工

FlashArray 是面向块存储与结构化数据的主力阵列，承载数据库、虚拟化、ERP 等对 IOPS 和时延敏感的业务。它对外提供 iSCSI、Fibre Channel、NVMe-oF 等块协议接口，内部以 Purity 操作系统驱动，通过 DirectFlash 模块和 NVMe 介质实现全闪性能。升级 FlashArray 时，真正被替换或更新的对象包括 Purity 软件版本、控制器（含 NVRAM 与主机接口卡）、DirectFlash 模块，以及扩展柜。

FlashBlade 则是面向文件和对象存储的横向扩展平台，服务于 AI 训练数据集、日志归档、备份目标、S3 对象存储等场景。它由刀片（Blade）、机箱、Fabric 互联模块和 Purity//FB 操作系统组成，通过 NFS、SMB、S3 协议对外服务。FlashBlade 的升级对象与 FlashArray 明显不同：刀片可以逐块热插拔替换，容量与性能随刀片数量线性增长，因此它的升级更接近"按需加刀片"的横向扩展，而非整机替换。

Pure1 是云端管理与智能运维平台，它不承载业务数据，而是通过安全遥测通道收集阵列的运行指标、容量趋势、性能基线和健康状态，提供全局监控、容量预测、AI 驱动的异常检测以及升级合规性检查。在升级过程中，Pure1 的价值在于：升级前可查看目标版本的兼容性建议，升级后可对比性能基线是否发生偏移。

Evergreen 架构 不是某个具体硬件，而是一套贯穿产品生命周期的设计原则与订阅模型。它包含 Evergreen//Forever（永久拥有 + 订阅支持）、Evergreen//Flex（硬件订阅，可随时换新）、Evergreen//One（存储即服务）等形态。Evergreen 的核心承诺是"无数据迁移、无停机升级"——控制器、刀片、介质都可以在不搬迁数据的前提下替换，这直接决定了升级方案的设计思路。

版本关系：升级中最容易踩坑的地方

四个对象之间并非独立升级，而是存在明确的版本依赖链。最典型的三条约束是：

• Purity 与 Purity//FB 的版本节奏不同。FlashArray 的 Purity 与 FlashBlade 的 Purity//FB 是两套独立演进的代码基线，版本号不对应。例如 Purity 6.x 与 Purity//FB 3.x 属于不同代际，不能假设"升到同一个大版本号"就兼容。
• Pure1 的兼容性检查依赖阵列上报的版本信息。如果阵列版本过旧，Pure1 可能无法给出准确的升级路径建议，甚至提示"版本超出支持窗口"。因此升级前应先在 Pure1 中确认目标版本是否在支持矩阵内。
• Evergreen 的硬件替换有代际匹配要求。例如将老一代控制器更换为新一代控制器时，必须确认新控制器支持的 Purity 最低版本、DirectFlash 模块的兼容列表，以及扩展柜的互联协议是否一致。

升级对象的实际判断方法

面对一台具体设备，如何判断本次升级到底涉及哪些对象？可以按下面的顺序逐层确认。

第一步，确认平台类型。通过管理地址登录后，FlashArray 使用 purearray 命令族，FlashBlade 使用 purefb 命令族。两者命令不通用，这直接决定了后续升级工具的选择。

第二步，读取当前版本与硬件清单。以 FlashArray 为例，执行：

purearray list --version
purearray list --controller
purearray list --drive

输出中会分别给出 Purity 版本、控制器型号与状态、DirectFlash 模块的型号和固件版本。FlashBlade 对应使用 purefb list --version、purefb list --blade、purefb list --fabric。这些输出就是升级对象的"底账"。

第三步，对照 Pure1 兼容性矩阵。把上一步得到的控制器型号、介质型号、当前 Purity 版本填入 Pure1 的升级规划页面，系统会返回：目标版本是否可直接升级、是否需要先升到某个中间版本、哪些硬件需要同步更换。这一步是避免"升到一半发现硬件不支持"的关键。

第四步，区分"软件升级"与"硬件更换"。Purity 版本升级通常可以在线完成，控制器逐个重启，业务通过多路径切换保持连续；而控制器代际更换、DirectFlash 模块扩容、FlashBlade 加刀片则属于硬件操作，需要确认备件、槽位和供电。Evergreen 架构的价值正在于此：硬件更换不需要搬迁数据，新组件接入后由系统自动识别并纳入集群。

一个可参考的升级对象确认清单

下面这份清单可直接用于升级前的对象盘点，字段按实际环境填写即可。

版本关系对升级顺序的影响

当环境中同时存在 FlashArray 和 FlashBlade 时，升级顺序需要额外考虑。两者虽然独立升级，但如果它们之间存在数据复制、快照挂载或备份关系，就应遵循"先升被依赖方、再升依赖方"的原则。例如 FlashBlade 作为 FlashArray 的备份目标时，通常先升级 FlashBlade 的 Purity//FB，确认 S3 或 NFS 服务正常后，再升级 FlashArray 的 Purity。这样即使升级过程中出现协议兼容问题，也能在影响面较小的一侧先发现。

另外，Pure1 本身是云端服务，不需要本地升级，但它的功能会随云端发布持续更新。升级前应确认 Pure1 控制台中该阵列的"支持状态"为有效，否则可能无法获取目标版本的兼容性建议。Evergreen 订阅状态同样会影响升级资格：如果订阅已过期，部分新版本可能无法下载或激活。