1. Pure Storage存储架构与故障诊断运维体系概览

Pure Storage 的存储产品线以 Purity 操作系统为统一软件基座，向上承载 FlashArray 与 FlashBlade 两类硬件平台。理解故障诊断与运维体系，首先要建立“软件定义、硬件直连、全局遥测”的整体认知：Purity 负责数据路径、元数据管理、快照与复制等核心逻辑；硬件层则通过 NVMe 直连闪存、冗余控制器和高速互联，把介质故障、链路抖动、控制器切换等事件暴露给上层。运维人员看到的不是孤立告警，而是一条从物理介质到逻辑卷、再到上层主机的完整信号链。

Purity 操作系统与硬件平台的分层关系

Purity 运行在 FlashArray 的控制器上，采用双控制器 Active-Active 架构。每个控制器拥有独立的 CPU、内存和 NVMe 通道，但共享同一份后端闪存资源。FlashArray 的典型数据路径是：主机通过 FC/iSCSI/NVMe-oF 发起 I/O，控制器接收后写入 NVRAM 并镜像到对端控制器，随后由 Purity 的元数据引擎决定数据落盘位置，最终写入 DirectFlash 模块。FlashBlade 则采用刀片式架构，多个刀片通过内部 Fabric 互联，Purity 以分布式方式管理对象与文件数据，适合非结构化负载。

从故障诊断角度看，分层关系决定了排查顺序：先确认是主机侧、网络侧、控制器侧还是介质侧的问题。例如，主机报“路径丢失”，可能是 FC 交换机 zone 配置错误，也可能是控制器端口故障，还可能是 Purity 内部卷映射异常。只有把每一层的正常状态和异常特征都建立起来，才能快速定位。

核心组件交互关系与故障传播路径

在 FlashArray 中，一次写 I/O 的完整路径是：主机 HBA 发出写命令 → FC 交换机转发 → 控制器前端端口接收 → Purity 写入 NVRAM 并镜像到对端 → 返回写确认 → 后台异步写入 DirectFlash。这条路径上任何一环异常，都会在主机侧表现为延迟升高或 I/O 错误。例如，NVRAM 镜像链路中断时，Purity 会主动禁用写缓存，导致写延迟从亚毫秒级升至数毫秒；此时 purearray list --controller 会显示控制器状态异常，而 purealert 会推送 NVRAM 相关告警。

FlashBlade 的交互关系略有不同：数据通过内部 Fabric 在多个刀片间分布，Purity 以分布式元数据管理对象。若某个刀片离线，系统会触发数据重建，重建期间读性能可能下降，但不会中断服务。诊断时应重点关注 pureblade list 中的刀片状态、Fabric 链路误码率以及重建进度。

故障诊断运维的整体框架与关键能力

Pure Storage 的运维体系可以概括为“三层能力”：第一层是主动监控，通过 Pure1 云端遥测收集阵列的实时指标，包括 IOPS、延迟、带宽、容量、介质寿命和控制器健康度；第二层是本地诊断，利用 Purity 内置的 purearray、purevol、purehost 等命令查看配置与状态；第三层是故障恢复，包括控制器切换、路径切换、卷重新映射和介质更换。

实际运维中，建议建立以下关键能力：

• 基线能力：记录正常状态下的延迟、IOPS 和队列深度，作为异常判断的参照。例如，某 FlashArray //X70 在 4K 随机读场景下，正常延迟约 0.3ms，若突然升至 2ms 以上，需立即排查。
• 告警分级能力：区分“信息”“警告”“严重”三级。信息级如快照完成，警告级如单路径丢失，严重级如控制器离线或介质故障。
• 根因定位能力：按照“主机→网络→控制器→Purity→介质”的顺序逐层排除，避免跳层猜测。
• 恢复验证能力：故障处理后，必须验证主机多路径状态、阵列告警清除、性能回归基线。

关键参数与判断依据