📚 课程目录第2章 Pure Storage架构解析

2. Pure Storage架构解析

Pure Storage 的产品线中，FlashArray 与 FlashBlade 虽然都建立在全闪存介质之上，但它们的硬件组织方式、数据访问模型和冗余策略差异明显。理解这些差异，是判断“某类数据库负载该落在哪套平台上”的前提。本节从硬件架构入手，再落到介质特性与控制器冗余，最后给出与数据库工作负载的匹配逻辑。

一、FlashArray：双控制器对称架构与块级访问

FlashArray 面向块存储与结构化数据，典型形态是双控制器（Controller）对称架构。两个控制器通过内部高速互连（如 PCIe/NVMe 或专有背板链路）连接同一组 NVMe 闪存盘位，对外各自提供 FC、iSCSI 或 NVMe-oF 前端端口。任一控制器都能访问全部盘位，因此不存在“某块盘只属于某个控制器”的静态绑定。

其数据路径可以概括为：主机通过多路径（MPIO）把 I/O 同时下发到两个控制器；控制器在写路径上先落 NVRAM/持久化写缓存并做镜像，再向闪存写入；读路径则直接从闪存读取并利用 DRAM 缓存加速。卷（Volume）是基本分配单位，快照、克隆、复制都建立在卷之上。对数据库而言，这意味着一个 LUN/卷可以被两个控制器同时服务，路径故障时由 MPIO 切换，而不是由存储端重新“接管”。

二、FlashBlade：横向扩展刀片架构与文件/对象访问

FlashBlade 面向非结构化与并行访问场景，采用横向扩展（Scale-out）的刀片式架构。一个机箱内有多块刀片（Blade），每块刀片自带计算、内存与闪存，通过内部高速交换网络互联，对外呈现为统一的文件（NFS/SMB）或对象（S3）命名空间。数据被条带化分布到多块刀片，元数据也由多节点协同管理。

与 FlashArray 的“双控制器对称”不同，FlashBlade 的冗余是“多节点分布式”：单块刀片故障时，其承载的数据可通过其他刀片上的冗余编码重建，客户端连接由其他节点继续服务。它的优势在于高并发、高吞吐的文件/对象访问，而不是低延迟的随机块 I/O。

三、全闪存介质特性对数据库的实际影响

全闪存的核心变化不只是“快”，而是访问延迟从毫秒级降到百微秒级，且随机与顺序访问的差距大幅缩小。这带来三个对数据库直接相关的后果：

随机读不再是瓶颈。传统磁盘上需要靠大块顺序读来掩盖寻道延迟，全闪存下随机 4K/8K 读同样高效，因此索引扫描、单行查找的代价显著下降。
写放大与寿命需要管理。闪存以页写入、块擦除，数据库频繁的小块更新会产生写放大。Pure 通过全局磨损均衡、在线去重与压缩降低实际写入量，但前提是数据库侧不要做无意义的全表反复重写。
延迟一致性比峰值更重要。数据库事务对 P99 延迟敏感。全闪存阵列若在垃圾回收或重建时出现延迟毛刺，会直接表现为提交抖动，因此需要关注阵列在后台任务期间的延迟表现。

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

FlashArray 的双控制器采用 Active-Active 模式，两个控制器同时服务 I/O。写操作在返回主机确认前，必须完成 NVRAM 镜像，即两个控制器都持久化了该写请求。若控制器 A 故障，控制器 B 已持有镜像数据，可立即继续服务，主机侧通过 MPIO 把路径切到 B。这个过程对数据库表现为一次短暂的路径切换，而不是数据丢失或长时间中断。

FlashBlade 的冗余粒度是刀片。数据以冗余编码方式跨刀片分布，单刀片故障时，其他刀片根据编码重建丢失的数据分片，客户端连接由剩余节点继续承载。它的恢复过程是分布式的，适合容忍单节点故障但要求整体吞吐不塌陷的场景。

判断冗余是否真正生效，不能只看“有没有双控制器”，而要看写确认路径：写请求是否在返回主机前已完成镜像或冗余编码。若写确认只落在单侧，故障时仍可能丢最近写入。

五、与数据库工作负载的匹配逻辑

把上述差异落到选型上，可以按以下顺序判断：

先看访问协议。数据库需要块设备（如 Oracle ASM、SQL Server 数据文件、MySQL InnoDB）时选 FlashArray；需要 NFS/S3 共享访问（如数据仓库外部表、备份归档、AI 训练数据）时选 FlashBlade。
再看 I/O 形态。以小块随机读写为主、延迟敏感的 OLTP，优先 FlashArray；以大块顺序扫描、高吞吐为主的 OLAP/分析，优先 FlashBlade。
再看并发模型。单库多路径共享卷、RAC/AlwaysOn 这类需要块级共享的场景，FlashArray 的卷模型更直接；多客户端并行读同一数据集，FlashBlade 的统一命名空间更自然。
最后看冗余与恢复目标。要求亚毫秒级切换、写不丢的，依赖 FlashArray 的 NVRAM 镜像；可接受节点级重建、更看重整体吞吐的，依赖 FlashBlade 的分布式冗余。

一个常见的组合是：核心交易库放在 FlashArray 上，通过快照/克隆快速生成测试库；历史数据、日志与备份落到 FlashBlade，用 NFS 或 S3 供分析平台并行读取。这样既保住了事务延迟，又用横向扩展承接了分析吞吐。

不要把 FlashBlade 当作低延迟块设备使用，也不要把 FlashArray 当作高并发文件共享平台使用。两者的硬件组织与冗余模型决定了它们各自的最优区间，错配会在延迟或吞吐上直接暴露。

总结来看，FlashArray 的关键词是“双控对称、块访问、NVRAM 镜像、低延迟”；FlashBlade 的关键词是“横向扩展、文件/对象、分布式冗余、高吞吐”。数据库负载的匹配，本质上是在延迟、协议、并发和冗余四个维度上做取舍，而不是简单比较容量或价格。