📚 课程目录第2章 Pure Storage核心硬件与全闪存架构

2. Pure Storage核心硬件与全闪存架构

Pure Storage 的两条主力产品线——FlashArray 与 FlashBlade——虽然都建立在全闪存介质之上，但它们的硬件组织哲学截然不同。理解这种差异，是后续做虚拟化业务存储设计时判断“该选谁、怎么配、边界在哪”的基础。本节从硬件组成、NVMe 介质特性、控制器冗余机制和性能边界四个角度展开，帮助你在方案设计阶段建立清晰的物理层认知。

一、FlashArray：双控制器对称架构

FlashArray 采用经典的双控制器（Active-Active）对称架构。以 FlashArray//X 系列为例，一个机箱内包含两个控制器节点，每个节点拥有独立的 CPU、内存、NVMe SSD 插槽和主机接口卡。两个控制器通过内部 PCIe 或专用互连通道共享同一组 NVMe 盘位，任一控制器都能访问全部介质。前端主机接口通常为 16/32Gb FC、10/25/100GbE iSCSI 或 NVMe-oF，后端则通过 NVMe 直连到盘体。

这种架构的关键特征是：两个控制器同时对外提供服务，主机多路径软件（如 VMware NMP、Linux DM-Multipath）将同一卷的多个路径分别指向两个控制器，实现负载分担与故障切换。控制器之间通过心跳和镜像写缓存保持状态同步，任一控制器故障时，另一控制器接管其卷的 I/O，主机侧仅感知路径切换，业务不中断。

二、FlashBlade：刀片式横向扩展架构

FlashBlade 的设计目标不同，它面向非结构化数据（NFS、S3、对象、大数据分析），采用“刀片+分布式”架构。一个 FlashBlade 机箱内可插入多个刀片（Blade），每个刀片本身就是一个独立的存储节点，包含 CPU、内存和若干 DirectFlash 模块。所有刀片通过内部高速背板互联，对外呈现为单一命名空间。

与 FlashArray 的“双控制器共享盘体”不同，FlashBlade 的数据被条带化分布到所有刀片上，元数据也分布式管理。这意味着：增加刀片即可线性提升性能和容量，扩容时无需停机；单个刀片故障时，其上的数据通过其他刀片的冗余副本重建，系统整体性能仅轻微下降。这种架构更适合高并发、大带宽、海量小文件或对象场景。

三、NVMe 介质特性与 DirectFlash 设计

Pure Storage 全闪存阵列使用 NVMe 协议 SSD，但并非简单地把 SAS/SATA SSD 换成 NVMe。NVMe 相比传统 SAS 的关键优势在于：命令队列深度从 32 提升到 64K，中断处理从单队列变为多队列，协议栈更精简，因此单盘 IOPS 和延迟表现显著改善。在虚拟化场景中，这意味着同样的物理盘位可以承载更多虚拟机密度，且尾延迟更可控。

Pure Storage 的 DirectFlash 模块进一步去掉了传统 SSD 中的 FTL（Flash Translation Layer）和部分控制器逻辑，将介质管理上移到阵列控制器软件层。这样做的好处是：控制器可以全局调度所有闪存芯片的写入和垃圾回收，避免单盘内部 GC 造成的性能抖动；同时，盘体不再需要预留大量 OP（Over-Provisioning）空间，可用容量更高。对设计者而言，这意味着在规划容量时，不能简单套用传统 SSD 的“标称容量×0.8”经验值，而应参考 Pure 官方给出的有效容量和 Purity 软件的开销模型。

四、控制器冗余机制与故障切换

FlashArray 的冗余机制围绕“双控制器 + 多路径”展开。正常状态下，每个卷在两个控制器上都有路径，主机通过 ALUA（Asymmetric Logical Unit Access）或 Pure 的 Purity ActiveCluster 感知最优路径。当控制器 A 故障时，其上的卷由控制器 B 接管，主机多路径层在秒级内将 I/O 切换到控制器 B 的路径。整个过程对虚拟机表现为一次短暂的路径切换，通常不会导致业务中断，但可能观察到少量 I/O 延迟尖峰。

FlashBlade 的冗余则依赖数据分布和副本机制。每个刀片故障后，系统会从其他刀片上的冗余数据重建丢失的条带。重建期间，整体吞吐可能下降 10%～30%（取决于刀片数量和负载），但不会中断服务。设计时需要注意：FlashBlade 的冗余策略通常要求至少保留一个刀片的故障域，因此有效容量规划要扣除相应冗余开销。

五、性能边界与设计约束

无论哪条产品线，性能边界都由三个因素共同决定：前端接口带宽、控制器/刀片处理能力、后端介质带宽。以 FlashArray//X70 为例，其标称性能约为 150 万 IOPS（4K 随机读）和 20GB/s 带宽，但这是理想条件下的峰值。实际虚拟化场景中，如果主机侧使用 8Gb FC 单路径，单端口理论带宽仅约 800MB/s，远低于阵列能力，瓶颈会落在前端链路。因此，设计时必须先确认主机接口类型、数量和链路冗余，再评估阵列是否“喂得饱”。

另一个常被忽略的边界是延迟。全闪存阵列的稳定延迟通常在 0.1～0.5ms 量级，但当队列深度过高或发生控制器故障切换时，延迟可能瞬时上升到数毫秒。对于延迟敏感的数据库或实时业务，建议在方案中预留控制器故障切换的延迟余量，并通过多路径和队列深度调优来平滑尖峰。

设计提示：在虚拟化项目中，先用“主机接口带宽 × 链路数”估算前端上限，再与阵列标称性能对比。若前端上限明显低于阵列能力，优先升级主机接口或增加链路，而不是盲目选择更高型号的阵列。

注意：FlashArray 与 FlashBlade 的冗余模型不同。FlashArray 故障切换以控制器为单位，FlashBlade 以刀片为单位。做高可用设计时，不要将两者的故障域和恢复时间混为一谈。

总结来说，FlashArray 适合需要块存储、强一致性和低延迟的虚拟化与数据库场景；FlashBlade 适合高并发文件、对象和大数据场景。理解它们的硬件组成、NVMe 介质特性和冗余边界，才能在后续的容量规划、性能调优和故障域设计中做出合理决策。