2. Pure Storage文件与块存储产品架构
Pure Storage 的产品线并不是“一台设备同时做所有事”，而是用两条硬件平台分别承载不同的存储语义：FlashArray 面向块存储，提供 LUN、卷、快照、克隆、复制等块级能力；FlashBlade 面向文件与对象存储，提供 NFS、SMB、S3 等文件/对象访问接口。两者共享同一套软件基因——Purity 操作系统，但针对不同负载形态做了不同的硬件与软件实现。理解这一节的关键，是看清“块”与“文件/对象”在硬件形态、数据路径和软件服务上的分界与统一。
一、FlashArray：为块存储而生的硬件与软件架构
FlashArray 的硬件核心是双控制器（Active-Active）加全闪存盘柜。两个控制器同时在线、互为冗余，主机通过 FC、iSCSI 或 NVMe-oF 等多路径接入，任一控制器故障时另一控制器接管卷的 I/O，主机侧通过多路径软件感知路径切换。盘柜内使用 NVMe SSD，控制器与盘之间通过 PCIe/NVMe 高速互联，避免传统 SAS 扩展的带宽瓶颈。
软件层是 Purity for FlashArray（常称 Purity//FA）。它把物理闪存抽象成卷（Volume），卷再通过主机组（Host Group）映射给主机。Purity 的关键机制包括：全局磨损均衡，把写入均匀分布到所有 SSD，避免单盘热点；内联去重与压缩，在数据落盘前完成指纹比对和压缩，减少实际写入量；元数据分离，将数据块与指向它们的元数据分开管理，使快照、克隆只复制元数据指针而非整块数据。因此，一个 1TB 卷的快照在创建瞬间即可完成，空间开销取决于后续变更量，而不是卷容量本身。
对块存储而言，主机看到的是“一块可读写的地址空间”，文件系统由主机自己管理。FlashArray 不解析文件语义，只负责按块读写、保证一致性、提供快照与复制。这种“不越界”的设计让它在数据库、虚拟化、容器持久卷等场景中延迟低、行为可预测。
二、FlashBlade：为文件与对象而生的横向扩展架构
FlashBlade 的硬件形态与 FlashArray 明显不同：它采用刀片式（Blade）横向扩展架构，多个刀片通过内部高速背板互联，每个刀片自带计算与闪存资源。容量和性能随刀片数量线性增长，适合海量非结构化数据——日志、影像、备份归档、AI 训练数据集、S3 对象桶等。
软件层是 Purity for FlashBlade（常称 Purity//FB）。它对外提供三类接口：NFS（Linux/Unix 文件共享）、SMB（Windows 文件共享）、S3（对象访问）。文件系统采用分布式元数据设计，目录和文件信息分散在多个刀片上，避免单点元数据瓶颈；对象存储则通过 S3 兼容接口提供桶和对象键值访问。FlashBlade 同样具备快照、复制、安全策略等能力，但语义围绕“文件/对象”展开，而不是“块地址”。
这里有一个容易混淆的点：FlashBlade 也能通过 NFS/SMB 暴露文件，主机挂载后看到的是目录树；而 FlashArray 暴露的是块设备，主机需要先建文件系统才能看到目录。两者在“用户最终看到什么”上相似，但在“存储系统内部按什么单位管理数据”上完全不同。
三、Purity 操作系统如何统一提供块与文件服务
Purity 是 Pure Storage 的底层操作系统，运行在两类硬件之上。它统一了闪存管理、数据缩减、快照、复制、加密、监控等基础能力，但根据硬件平台加载不同的服务模块：在 FlashArray 上启用块服务栈（卷、LUN、主机映射），在 FlashBlade 上启用文件/对象服务栈（NFS、SMB、S3、目录树、桶）。
这种“统一内核 + 平台化服务”的设计带来三个实际好处。第一，运维体验一致：无论管理 FlashArray 还是 FlashBlade，都通过 Pure1 或命令行/API 使用相似的命名和监控逻辑，快照、复制、告警的语义一致。第二，数据缩减策略一致：去重、压缩、清零检测等机制在两类平台上都生效，只是块与文件/对象的粒度不同。第三，升级与扩展路径清晰：Purity 版本统一发布，FlashArray 通过加盘柜扩展容量，FlashBlade 通过加刀片扩展容量和性能，软件能力随版本升级获得。
需要强调的是，Purity 并没有把块存储“变成”文件存储，也没有把文件存储“降级”成块。它做的是在同一套软件框架下，为不同硬件平台提供各自匹配的存储服务。块存储追求低延迟、强一致、地址级控制；文件/对象存储追求高并发、海量元数据、共享访问。两者在 Purity 层共享基础能力，在服务层各司其职。
四、从架构到选型：实际判断依据
理解了架构差异，选型判断就变得直接。如果业务需要的是块设备——例如 Oracle RAC 共享存储、VMware VMFS 数据存储、Kubernetes PVC、SQL Server 数据盘——应选择 FlashArray，因为主机需要的是可寻址的块空间，文件系统由主机侧管理。如果业务需要的是共享文件或对象——例如多台 Linux 服务器同时读写同一目录、Windows 文件共享、备份软件写入 S3 桶、AI 训练读取海量小文件——应选择 FlashBlade，因为文件/对象语义由存储系统直接提供，客户端无需再建文件系统。
一个常见的实际判断方法是看“谁管理目录结构”。如果目录结构由主机操作系统管理，存储只提供块设备，那就是 FlashArray 场景；如果目录结构或对象键由存储系统管理，客户端直接挂载或通过 S3 API 访问，那就是 FlashBlade 场景。这个判断不需要看容量或性能数字，只看数据访问语义即可。
最后需要明确，FlashArray 和 FlashBlade 不是替代关系，而是互补关系。一个数据中心可能同时部署两者：FlashArray 承载数据库和虚拟化块存储，FlashBlade 承载日志、备份、AI 数据集和 S3 对象。Purity 让两者在管理、监控、快照、复制等层面保持一致的操作逻辑，降低运维复杂度，但不会改变它们各自对外的存储语义。理解这一点，就抓住了 Pure Storage 产品架构的核心。