Pure Storage如何开发 FlashBlade//EXA 系统

纯 Storage 最初以全闪存存储阵列 (AFA) 供应商的身份成立，在一波类似创业公司的崛起中一路生存并获得成功——这些创业公司曾短暂风光一时，随后被收购或因更成熟竞争对手采纳该技术而退出市场，从而使新进入者难以立足。

在2010～2015年及之后的时期，包括 Dell、Hitachi Vantara、HPE、IBM、NetApp 以及 Pure 在内的主流企业级老牌公司，以基本上采用双控制器和驱动器架构并具备横向扩展（scale-up）功能的 AFA 方案主导了市场。虽然也存在诸如 Isilon 等有限的横向扩展方案，但想要实现真正的横向扩展，就必须转向高性能计算 (HPC) 领域，比如采用基于并行文件系统的供应商，如 DDN。

随后，在2016年，AFA 矿井中诞生了一颗离散化的金丝雀：VAST Data 亮相，其采用独立横向扩展的元数据控制器以及横向扩展的全闪存存储节点，这些节点通过 NVMe RDMA 架构相互通信。尽管 VAST 系统中还包含了许多巧妙的软件设计，但其根本的区别在于采用了离散化设计，并辅以单一存储层的 QLC 闪存驱动器。

接着，随着 AI 热潮的兴起，VAST Data 和诸如 DDN 等基于并行文件系统的 AFA 供应商受益匪浅。只有这些系统能在不遭遇数据 I/O 等待的情况下，支持 GPU 服务器集群运行生成式 AI 训练工作负载。虽然传统企业级 AFA 供应商也加入了 Nvidia GPUDirect 以加速数据传输到 GPU 服务器，但他们始终无法匹配离散化横向扩展和并行文件系统供应商所实现的数据容量优势。因此，VAST Data 与 DDN 在 Nvidia 引领的 GPU 服务器大规模数据训练领域中蓬勃发展。

这一现象使其他供应商开始重新评估自己的产品。HPE 采用了类似 VAST 的架构，推出了 Alletra 存储；Dell 组建了 Project Lightning，为其 PowerScale/Isilon 存储增添了并行性；而 NetApp 则启动了 ONTAP for AI 项目。至于 Pure，几周前他们正式宣布了 FlashBlade//EXA。

该方案巧妙之处在于，现有的双控制器 FlashBlade 系统被用作元数据控制器层，而采用独立横向扩展的 QLC 闪存存储节点通过 RDMA 架构进行访问。我们采访了 Pure 的技术副总裁 Chadd Kenny ，进一步了解了相关细节。

Blocks & Files：FlashBlade//EXA 看起来像是对 FlashBlade 架构的根本性改造，使其具备了并行处理的操作方式。是否也可以用 FlashArray 实现同样的方式？这个问题是否显得有些愚蠢？

Chadd Kenny：不，这个问题很有意思。让我介绍一些关于 EXA 生成背景的情况，这或许能帮助你理解我们为何决定构建这一系统。这是一个非常有趣的项目，我们花了很多时间思考当今市场上有哪些架构，我们希望从中获取哪些额外价值，同时评估我们自身具备哪些核心竞争力，可以运用到新的解决方案中。

因此，这个项目很有意思，因为我们可以尝试几种不同方案。第一种显然是，可以制造更大节点，打破传统机箱配置，并且大节点能提供更多计算能力，允许我们以不同的方式进行扩展。这能带来相当可观的性能提升，但仍不足以满足需求。

客户开始向我们提出需求，很有意思的是，在与客户沟通中，他们要求的性能达到了每秒 10TB 或 20TB。因此，我们百思不得其解：如此庞大的性能要求如何实现？接着我们开始思考，将基础设施进行解耦是否是一种有趣的可能性，但问题在于如何实现。

于是，我们反复讨论我们试图为客户解决的核心竞争力是什么。一直以来我们听到的一个问题是，元数据性能非常成问题，而且在扩展方式上往往非常受限。例如，之前有一些类似 PNFS 或 Lustre 的替代方案尝试将元数据分离出去，但缺点在于它们无法以非常细粒度的方式相互独立地扩展，无法满足“我要海量元数据但容量很少”或者“我要大容量但元数据很少”的需求。

这一点引起了我们的兴趣：如何通过不同的机制来实现这一目标？

第二个思考点是，回顾 FlashArray 的初衷，其本质是一个被高度优化以适配闪存的键值存储系统，用于访问数据。我们将相同的键值存储系统引入 FlashBlade，并在这些节点之间进行了横向扩展，这让我们认识到其中存在几个关键优势。

一是系统支持多客户端连接下的极高速度；二是其对象计数可达到 40 千万亿级别，数量之庞大令人难以置信。因此，当我们进一步思考时，我们认为，如果将 FlashBlade 核心的元数据引擎保持不变，利用其可扩展的对象数量，我们可以无限扩展数据节点的数量。

实际上，我们甚至不知道数据节点的极限数量是多少。于是，我们必须测试这些数据节点是否能以线性方式扩展。于是，当我们以这种解耦方式加入数据节点时，我们决定采用 PNFS，因为这是客户最初向我们提出的需求。

尽管我认为基于 S3 的 ObjectStore 通过 RDMA 实现可能是长期方案，但 PNFS 是客户当下普遍关注的需求。因此，在构建过程中，我们逐渐发现，随着节点数量增加，性能呈现精准的线性上升，大约每秒 85 到 100 GB。这让我们非常兴奋，我们可以构建一个系统，该系统能够应对各种不同的客户端访问模式，并使总带宽实现线性扩展。

于是，我们突然间为打造一个离散化产品感到异常兴奋。最初的逻辑之一是，我们将构建自己的数据节点。我们讨论了很长时间，考虑是否应该这么做。超大规模市场的胜利也为我们提供了一些方案思路。接着我们与客户沟通——你会如何使用这个系统？有意思的是，大多数客户表示，他们已经投资建设了庞大的数据节点基础设施，是否可以直接使用现有设备？

我们回答说，即使是竞争对手的节点，幽默的是，只要满足最低要求（要求其实很低），我们就可以将其纳入系统。因此，我们决定首先采用市面上现成的符合要求的节点及 Linux 发行版，配以一组小型软件包来优化工作流程，比如我们的 rapid file toolkit 及其他若干技术堆栈。

这一切让我们非常兴奋：我们可以将这一新产品推向市场，其性能完全能跳跃式超越竞争对手，并满足一些常人无法通过特定配置实现的大型 GPU 云性能需求。

Blocks & Files：我询问 FlashArray 是否也能采用这种方法，实际上就好比问 FlashArray 中的计算引擎能否采用这种方式，这是否显得有些愚蠢？

Chadd Kenny：这个概念很有趣，我认为我们始终对新概念和创意持开放态度，并在 CTO 办公室花了很多时间验证这些新构想，探讨是否能改变我们构建设计的方式。FlashBlade 与众不同的地方在于，我们采用了开放硬件生态系统。所以它的运行模式与我们以往构建的系统有所不同。我们通常构建那些优美、简洁、简单易用的系统，任何人都能在几分钟内上手。而 EXA 显然有点不同，但我们发现客户喜欢这种 DIY 的构建方式；而在传统企业模式中，客户更偏好黑盒产品，即插即用，万事俱备。

Blocks & Files：是指一体机吗？

Chadd Kenny：是的。在 FlashArray 上，问题在于它在自身生态中表现得实在太出色，而且我们已经构建了几乎所有可能的层级。事实上，你会看到在 Accelerate 大会期间我们还会发布一些相关公告……不过我们也正计划在 FlashArray 上实现接近 EXA 级别的性能。因此，我们非常喜欢当前 FlashArray 的设计，至今还没有找到一种让它解耦的合理方案。我想你也会看到，也许我们以后会尝试一些新的介质类型，我们之后会讨论，但 QLC 仍然是我们实现多层次设计的主流方案。所以说，FlashArray 将大体保持现状，说实话一直以来客户也没有提出要改变它的需求。

Blocks & Files：你是否认为现有的 FlashArray 能否与 EXA 共享同一命名空间，这样 FlashArray 上的数据也能包含在 EXA 的命名空间中？

Chadd Kenny：是的，很好的问题。我认为你将会看到，我们很快在 Accelerate 大会中发布的消息里，Fusion 将会跨产品统一 API。

比如就 Object 而言，将来你可能会在其他产品上看到 Object 功能。所以这些 API 将会通过 Fusion 层转发，然后你可以根据需要声明最终数据存放的位置。也就是说，你会看到更多抽象层覆盖在各系统之上，这些抽象层将通过策略驱动的配置和管理，让消费者很可能不必关心数据是存放在 FlashArray 还是 FlashBlade 上。当然，对于块存储（Block），它很可能会落在 FlashArray 上，但消费者可能不必知道具体是哪个 FlashArray。

我这边正努力开发的平台功能包括：利用已有的遥测数据构建智能推荐系统，从而允许用户通过策略驱动的自动化和部分 Copilot 能力（自然语言处理的提升）与这些推荐结果互动。

此外，在平台内部我们正在构建工作流自动化以及连接更广泛生态系统的“食谱”。我们将在 Accelerate 大会期间看到我们的平台实现部分功能。这里就不透漏太多，但大方向是：我们不是在试图在阵列级别桥接命名空间，而是在 Fusion 中构建一切，通过 Fusion 决定数据落入哪个系统。

Blocks & Files：假设六个月后，我作为 Hammerspace 的销售人员，上门拜访一个了解这些动态的客户，并介绍我们卓越的数据编排解决方案。那么，客户是否有可能直接对 Hammerspace 说“不用你了，我已经有这个系统了”？

Chadd Kenny：是的。我们在 EXA 中嵌入了 FlexFiles 模块，这一点我们之前并未详细谈及。所以，数据节点可以部署在任意位置，并且都可以整合到统一命名空间里。刚开始时我们并未大肆宣传这一点，因为核心应用场景下，大多数客户会将数据集中布置在与 GPU 紧邻的数据中心。

从长远来看，我认为你会看到更多地理分布式的部署。这也是 FlashBlade 整体规划的一部分；当我们将 pNFS 架构内嵌到 FlashBlade 体系中后，你将看到 FlexFiles 和多机箱方案被无缝连接，形成一个公共的命名空间。所以我认为，类似需求会逐渐显现。当然，我们依然全闪存，并且支持其他介质类型，因此可能会拓展到一些我们目前尚未充分涉及的应用场景，比如超大规模归档等。但我相信，随着容量达到 300 TB、600 TB 以及更大的增量扩展，我们会逐步进入类似的应用领域。