演讲人：Chad Smith，Field CTO – Strategic PartnersFloyd Christofferson，Vice President Product Marketing
时间：2024年2月23日
内容概要
《加速人工智能数据管道：Hammerspace的解决方案》当前状况和问题：存在管理和访问跨多个存储系统和位置的非结构化数据难题，以及信息孤岛问题，即非结构化数据散布于多个存储类型和位置。解决方案特征：通过并行的Global File System，整合现有存储中的文件系统元数据，实现数据的全局视图和访问，无需物理移动数据，遏制了“复制泛滥”现象。客户价值：无需大量前期投资，满足人工智能及其它高性能工作流所需的高性能，提高现有基础设施的利用率。客户案例：某大型云计算供应商和一家视觉效果公司，在不改动现有基础设施的情况下实现了可扩展性，并达到了所需的性能要求。
《用Hammerspace技术驾驭非结构化数据编排》核心能力：Hammerspace Global Data Environment软件能够自动化处理非结构化数据，包括跨越多个供应商、地点和多个云基础设施的各种存储环境。解决方案要点：将文件系统元数据与实际数据分离，并将其提升到基础设施层之上，形成全局元数据控制平面。这样，就可以在不同存储系统和位置之间实现文件的通用视图，实现透明和自动的数据编排，无需中断用户访问或要求数据迁移。主要组件：基于Linux，包含两个主要组件，用于元数据控制的Anvil服务器和用于I/O处理的DSX节点。支持多协议访问：支持多协议访问，包括NFS、并行NFS和S3，并允许设置基于目标的数据管理策略，如保护、分层和地理考虑。灵活安装：可以灵活地安装在各种平台上，无论是裸金属、云实例还是虚拟机，都能促进本地存储与云资源的无缝集成。应用实例：不同行业的应用实例，比如在线游戏、火箭公司Blue Origin以及伦敦的一个数据中心，它们通过将渲染作业编排到更经济的云区域中，成功降低了成本。—【以下为正文】—
加速人工智能数据管道：Hammerspace的解决方案
如何实现高性能计算（HPC）级别的解决方案，以便在现有存储资源上高效利用数据，为基于GPU的人工智能数据管道提供动力。通过实际案例展示，指导客户如何调整现有基础设施，以满足人工智能及其它高性能工作流所需的高性能要求。
如何通过解决管理和访问跨多个存储系统和位置的非结构化数据难题，来推动人工智能数据管道的加速。借助并行的Global File System，让数据原地不动，同时提供AI工作负载所需的高性能访问。
AI数据管道中的信息孤岛问题，即非结构化数据散布于多个存储类型和位置，导致在不迁移数据到新存储库的情况下难以聚合。将现有存储中的文件系统元数据整合起来，实现数据的全局视图和访问，无需物理移动数据。这种方法有效遏制了“复制泛滥”（Copy Sprawl）现象，维护了数据治理的秩序，同时也避免了额外的资本和运营开支。
Hyperscale NAS利用标准协议和网络，提供HPC级别的并行文件系统性能，无需专有客户端或改动现有基础设施。具有存储无关性，并能加速现有的第三方存储，特别适合那些希望在不进行大量前期投资的情况下引入人工智能工作流的企业。
某大型云计算供应商的实际案例，在拥有庞大的AI训练和推理环境下，借助Hammerspace的技术，在不改动现有基础设施的前提下实现了可扩展性。另一个案例是一家视觉效果公司，在不改变其存储基础设施的情况下，达到了渲染工作所需的性能。
我们主要聚焦在非结构化数据这一领域，这类数据来自多个源头，对于我们的工作来说至关重要。我会简单介绍一下Hammerspace的功能与技术，以便为后续的讲解打下基础。接着，我将详细阐述如何实现AI模型所需的高性能计算，并给出一个实际案例。
AI管道中存在一个关键问题，那就是数据孤岛。这不仅关乎结构化数据，更重要的是企业或各处所存在的大部分非结构化数据。据分析师估计，非结构化数据占据了80%到90%的比例。AI管道在处理非结构化数据时面临的挑战在于数据的来源多种多样，可能来自不同的存储类型和位置。
为了整合这些数据，我们面临一个难题：是否需要在处理之前移动所有数据？如何在不将数据迁移到新的存储库的情况下进行访问？
因为即便在数据开始流动时，我们也会遭遇过度复制的问题，我们称之为“复制泛滥”。如何确保数据治理不被破坏，特别是在企业环境中？将所有数据迁移到全新的存储库是否会导致经济负担过重，增加资本支出（CapEx）和运营费用？
这些问题都源于数据孤岛。当我们谈到文件系统元数据时，其实是指我们在屏幕上看到的文件夹或文件本身的信息。实际上，这些数据是以二进制形式存储在存储器上的。文件系统负责呈现给用户和应用程序的视图。如果所有数据都集中在一个存储库中，那自然不是问题。但问题在于，当存储库容量达到上限时，就会出现另一组元数据，导致用户和应用程序需要访问更多的位置来获取数据。随着孤岛点的增多，数据的位置变得更加分散，不同的存储类型会导致数据访问的断裂。
问题的严重性不仅在于访问的断裂，而且现有的解决方案往往需要移动、复制或跨孤岛点保护数据，这成为了一个巨大的难题和障碍。
Hammerspace所做的事情，简单来说，Hammerspace创建了一个Global Data Environment，配备了并行Global File System，将所有存储连接起来。这样，数据可以留在原地，无需移动。无论是AI应用程序、管道还是用户，都能全局查看数据，无需担心数据在哪个存储中。他们看到的是Global File System，所有数据都集中在一起。
这也意味着管理控制、数据移动或AI管道中的原地数据查看等操作都在后台进行，无需前台中断用户访问或移动、复制数据。在整个过程中，数据保持不变，文件系统也保持一致。
即使在AI管道的背景下，数据也可能被实例化，这意味着我们可以聚合多个数据源，而无需通过移动其元数据来实现。元数据有多种类型，包括文件系统元数据。当我们从数据中提取元数据时，会收集这些元数据。此外，还有丰富的元数据，如标签、上下文元数据等，这些都可以被聚合。因此，很多预选和预过滤工作甚至可以在不移动任何数据的情况下完成。今天讨论的主要内容是，如何有效地移动数据，并为其带来所需的性能水平，特别是将其引入训练和推理模型。最后，我们还要探讨如何将数据带到最终目的地，再次强调，在标准文件系统环境中，从一个阶段复制到另一个阶段往往会造成很多问题。
Hammerspace是一种软件解决方案，我们称之为Global Data Environment。这是一个集成软件解决方案，包含两个关键组件：一是数据编排能力，这将在另一个讨论中详细探讨；二是高性能文件系统，这与AI管道密切相关，也是我今天要重点评论的内容。
传统上，企业主要依赖Scale-out NAS作为数据源。虽然存储类型众多，但Scale-out NAS在企业中的使用至关重要。它安全易用，尽管可能不如HPC级别的并行文件系统速度快。例如，它并不便宜，但在企业中，安全性和易用性往往更为重要。这意味着它必须基于标准，不能是像HPC文件系统这样的外来系统。
HPC文件系统以及用于大型模拟模型的各种HPC工作流程，虽然速度极快，但安全性不足，它们的设计初衷就是追求极快的并行性能。这些HPC文件系统，如Lustre、GPFS、BeeGFS等，都非常高速，因为它们依赖于并行性能，可以在多个存储节点和数千个服务器之间并行处理数据。在HPC环境中移动数据时，可能涉及数千台服务器同时写入单个文件。然而，在AI工作流程中，特别是当希望将AI管道引入企业时，我们不能像科学项目那样操作。它不能有专有的客户端，必须基于标准，并且还需保证安全性。
因此，我们引入了一种新的存储类别，即昨天宣布的Hyperscale NAS。它的特点在于，它基于每个数据中心已经存在的开放标准构建并行文件系统。稍后我会详细介绍，但最重要的是，它的工作速度与HPC级别的并行文件系统相当，甚至在某些情况下更快，而且在该环境中成本可控，无需创建全新的架构。
这里的关键在于，Hyperscale NAS能够在现有的基础设施中顺利运作。稍后我会给大家展示具体例子，让大家看到，我们并不需要打造全新的存储库或者大幅度增加开支。回想起早期的时代，那时候我有一台个人电脑，文件系统就是操作系统的一个组成部分。如果我要复制一个文件，我会把它放到磁盘上，这包括文件的实际内容和文件系统元数据。然后，我会把这个文件交给同事，他再放到他的机器上。这样一来，我们就有了两份文件的拷贝，但它们是分开的，这就带来了协调的问题。
因此，Scale-up NAS是在90年代开发的，NetApp在这方面非常有名。这样一来，网络上的每个人都能看到相同的文件系统元数据，尽管这些元数据是从不同位置共享的。这在某种程度上是有效的，但随后我们发现数据规模需要超越这种限制。这就是为什么在21世纪初引入了Scale-out NAS，它使得多个存储控制器成为可能。这对于企业来说是非常理想的，而且至今仍是主要的存储形式。但问题在于，Scale-out NAS仅凭其架构本身，无法达到HPC级工作流程所需的性能，特别是AI管道，它缺乏这种能力。稍后我会详细解释原因。
因此，如果能够克服经典HPC并行文件系统（如Lustre）的局限性，如果我们能够获得并行文件系统级别的性能，同时保持基于标准的意义，也就是说，无需安装专有客户端，使用标准的现成网络，无需安装外来网络，并且其可扩展性没有限制，那么这就是Hyperscale NAS的定义。它必须是存储无关的。如果我的数据集可能存储在多个旧存储或多个位置，而我又必须将所有这些数据移动到一个新存储库中才能开始工作，那就成问题了。但如果我们采用高性能并行文件系统，我就能看到所有已经存在的数据，并加速处理，甚至在现有存储中直接为AI管道提供数据，那我们就找到了解决问题的钥匙。
这里有一个现有客户的实例。实际上，这种Hyperscale NAS的能力在Hammerspace中早就得到了应用，它是我们技术的核心。但直到我们真正在规模上验证了它的可行性，我们才觉得有必要，甚至是正确的将其公之于众。
这是世界上最大的人工智能训练和推理环境之一，一个超大规模的计算中心，他们目前拥有1000个存储节点，3.2万个GPU，分布在4000个服务器上。他们面临的问题是，为了运行AI推理，他们不想在服务器上安装专有客户端，不想改变现有的存储基础设施，他们希望继续使用已有的硬件和软件。
通过Hammerspace，我们所做的是仅引入我们的元数据控制器和服务节点，我们称之为Anvil。我们的方法，正如我最初简要提到的，是将元数据集成到现有服务器中。而Hyperscale NAS完全基于标准的Linux并行NFS版本4.2与Flex Files。实际上，这个规格的大部分都是Hammerspace在过去9年里编写的，并贡献给了社区。几乎所有的Linux发行版，甚至这个超大规模的计算中心，他们所做的修改都是基于相同的Linux内核，采用并行NFS 4.2，这是一个真正的并行文件系统，能够实现大规模扩展性。
当我们进入这个客户的环境时，最初的测试是在客户的一个小子集上进行的。但随着时间的推移，他们不断添加存储节点和GPU，我不得不每隔几周就更新一下这个图表，因为环境在不断扩张，最终这个环境将拥有35万个GPU。此外，他们还有多个站点，但关键的是，无需改变现有环境，就能完成数据的编排。他们只需简单地将Hammerspace安装到现有环境中，进行扩展。而一个重要的接受标准是能够线性扩展，没有任何限制。
观众：那么，是否可以这样理解，你正在接管现有存储设备的读写操作，使得所有请求都通过Hammerspace进行处理呢？
这里的关键点是，在并行文件系统中，把元数据路径与数据路径分开了。因此，现在所有的元数据操作都完全脱离了数据路径，而不再与数据路径混在一起，这样就不会影响性能和可扩展性。在这种情况下，客户端查看的是Hammerspace呈现的文件系统，这些文件系统的元数据是4.2，这些Flex Files布局是文件系统知道文件位置的布局。因此，当调用一个文件时，它会直接指向文件在存储中的位置。这样就不必经过控制器，不必再从客户端到存储的块进行另一次跳转，而是得到了直接I/O，这就是为什么：一是，为什么能够获得比通过Scale-out NAS（无论是Shared-Everything、Shared-Nothing，还是任何类型的扩展型NAS）的控制器瓶颈所能获得的性能显著提高。另外，它也提供了线性可扩展性，因为一切都实现了并行化。增加网络、增加服务器、增加存储，它将以线性规模增长。
观众：请帮我梳理一下思路。我理解你们在尝试解决I/O问题，但其中的Global File System部分似乎与问题的描述并不吻合。当我们解决了与GPU之间的I/O问题后，Global File System究竟有何优势？比如，我有32,000个GPU，我使用的是Lustre文件系统，并不存在Global File System的问题。
这个案例看似简单，因为它就是一个大型存储阵列与一个大型GPU阵列的结合。但有一点需要注意，这些设备分布在多个数据中心，这些数据中心需要协同工作。在实际的企业环境中，很少会有单一的巨大存储库，通常会有各种孤岛式的存储系统。比如，高性能存储可能已满，或者那个Scale-out NAS已经不能满足需求，所以会再添加一个新的、甚至更多的存储系统。因此，Global File System的作用在于整合所有这些分散的数据存储库和数据源。如果你不需要它，那当然很好，但大多数企业客户并没有这样的奢侈条件。
观众：还有一个问题，你们在做什么来帮助CPU和GPU的协同工作呢？
我想在下一场演讲中深入探讨数据编排，所以这个问题我稍后再回答。但Global Data Environment不仅仅意味着拥有一个高性能的文件系统，这当然是好事。然而，如果没有其它功能——这也是Hyperscale NAS的另一个亮点。如果你已经有了Lustre并行文件系统，那么你已经拥有了卓越的性能。但在企业场景，还需要NAS功能，数据保护，以及数据编排。没有这些，你在企业环境中很难走得更远。否则，Lustre早就被广泛采用了。这就是Hammerspace的另一大价值所在，我稍后会详细解释。
 fill=%23FFFFFF%3E%3Crect x=249 y=126 width=1 height=1%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
并行NFS与Flex Files自2018年以来就一直是规范的一部分，其中大部分内容尤其是Flex Files都是由Hammerspace的工程师开发的。我们的首席技术官是NFS的Linux内核维护者，所以我们所做的设计初衷就是要成为开源社区的一部分，并且已经提交至Upstream。
观众：我还有一个问题。你稍后会详细介绍你的付费产品与内核中可用产品之间的区别吗？
实际上，从功能上来说，两者并没有本质的区别。但我们的产品不仅仅是内核中的那些功能。从内核的角度看，就像超大规模计算中心一样，我们不需要在客户的服务器上安装专有客户端或专有版本的Linux客户端。他们使用的标准Linux发行版中的机制，与我们在Hammerspace中使用的机制是完全相同的。
观众：因此，他们使用的是Linux内核服务器，客户端工具也只是标准的NFS客户端。
标准NFS的使用方式没有任何不同。只是在Flex Files方面，据我所知，我们是唯一一家实际采用这种技术的公司。这就是我们的秘密武器，因为它允许我们将布局直接推送到服务器上，而无需进行任何定制处理。在Hammerspace生态系统中，我们显然拥有数据编排、其它元数据控制以及各种其它功能，而这一切都是基于这个并行NFS核心建立的。
再次强调，这是一个开放标准，并非专有技术。而我们之所以能够如此运作，正是因为它与我们的技术堆栈紧密集成，使我们能够充分利用其特性，实现真正的并行性。
从Hammerspace的角度来看，元数据服务是由我们的Anvils处理的。它们负责将布局推送到服务器，确保数据路径与元数据路径完全分离。推送完成后，每个服务器就可以根据它们各自的工作内容，直接从标准存储中读取数据。这里的后端存储是NFSv3或4.1标准的，因此无需对存储进行任何改动，也无需在服务器或存储端放置代理或客户端。
但我们的技术并不仅限于此，Hammerspace还包括我们所说的数据服务节点。这些节点可能需要满足某些用户的访问需求，比如那些不使用4.2版本的用户，他们可能需要标准的文件访问功能。无论他们是在Linux客户端上，还是在Windows或Mac上，他们可能都需要SMB访问。因此，我们会使用DSX节点，即我们的数据服务节点来满足这些需求。这些节点可以扩展，我指的是标准DSX节点可以扩展到60个，以应对带宽方面的挑战。但从根本上说，我们是在创建一个全局视图，让未经修改的应用程序和用户都能看到相同的内容。
对于高性能并行文件系统，我们可能会将其与NVMe存储或其它存储前端进行隔离。稍后我会展示一个示例，说明即使只使用标准的分布式存储，我们也能实现大幅的加速效果。
另外一点值得提到的是，顶层的数据处理必须兼具这两种能力，否则就会形成新的孤岛状态。我们必须让用户能够通过标准的文件访问方式在HPC世界中访问数据，同时也能够在处理环境中执行相同的操作。
GPUDirect也是一样，通过启用Flex Files直接将数据送入GPU服务器，使其背后的任何存储都能实现GPU的直接访问。
我们还可以在超融合环境中执行这一操作，以获得更多的加速效果。因此，这里的灵活性体现在，无论使用何种存储、何种服务器，只要运行任何版本的Linux，即任何标准版本的Linux，都能获得这种性能优势，而且无需对现有的服务器或存储进行任何更改。
在这个例子中，我们面临的情况是一个视觉效果客户。他们依赖一个由32节点组成的分布式Lustre存储系统来支持其渲染工作流。尽管Lustre存储在性能上尚可接受，但在这种HPC级别的工作负载下，它却无法满足需求。具体来说，他们有300个渲染节点，但只能完成一半的工作流程。这就面临一个选择：是更换存储系统，还是增加更多存储？尽管他们已经对当前存储系统投入了大量资源，但通过引入Hammerspace，他们可以在不改变基础架构的情况下，简单地引入一个超大规模NAS架构。
借助Hammerspace，他们可以快速地从现有的分布式文件系统中收集元数据，整个过程耗时极短，几分钟内即可完成，且所有操作均在后台自动执行。通过避免数据经过额外的控制器跳转，而是直接通过并行NFS进行I/O管理，他们不仅实现了所需的300个节点性能，还将节点扩展到了600个，同时无需对存储基础设施进行任何改动。因此，他们既无需改变现有的存储架构，也无需增加更多存储，就能更好地利用现有资源。
在AI背景下，可能有数据存储在现有的分布式存储系统上，但如何将其引入我们的环境？如何在推理或训练管道中以高性能工作流的方式使用它？
观众：那么对于Hammerspace来说，只要存储运行正确的Linux内核？
任何Linux内核。
观众：是任何Linux内核，所以不需要并行？
所有的pNFS 4.2都包含在Linux中。存储不需要那个，存储只是标准的NFSv3。这个的pNFS部分在元数据层面上是将元数据与数据路径分离，但目标只是标准的NFSv3。
观众：所以你们正在运行NFS，使用的是Hammerspace运行在NFS v4.2上？
我们运行v3、4.2，所有的这些组件都是Linux的一部分，所以我们在那个数据路径和元数据的分离上使用的是标准的现成的Linux。
观众：我想问的是，如果你来告诉我安装Hammerspace，听起来很酷，因为我在这张幻灯片上听到的是你安装它，不太确定你可能把它放在一个服务器上，然后它去找到所有的东西？
我会在我们下一节中详细讨论一下构建模块，当我们安装时，它是一个软件定义的解决方案，所以我们可以在VM上安装，或者在那个大型超大规模计算中心的情况下，它是三个实例以实现冗余，但基本上即使在这里，它也是两个服务器，那是元数据控制器的HA配对，所以我们会将其安装在一个VM上，或者裸金属上，然后它会去收集元数据，或者从原地的数据中获取元数据。
观众：而且那是存储在任何地方的所有数据，无论你在网络的任何地方存储？
只要他们允许，并且他们想要指向那里。
观众：那么它可以为你进行任何类型的超大规模操作，因为用户仍在使用的数据仍然在原地，那么Hammerspace就像中间人一样起作用吗？
是的，但你提出了一个很好的观点，我会在下一次会话中更详细地讨论这个问题，通过将文件系统的元数据层与实际文件所在的位置分离开来，可以实现无损数据编排。我可能打开一个文件，因为我正在查看并行文件系统的前端，我正在查看那个文件系统，但是那个数据可能在这里、那里，甚至在另一个站点，但是因为我正在查看相同的元数据层，就像在早期的Scale-up NAS的例子中一样，在不同的盘片上可能有不同的数据，可能在不同的磁盘上，我看到的是相同的文件级别，我不是在看这些文件的副本。
观众：那么从用户视角看，如果在他们底下的东西可能会动来动去，性能会怎么样，以及你们有哪些保护措施来防止数据丢失。
这是一个更深入的话题，我稍后会详细介绍一些内容。由于元数据被抽象化，这意味着你可以有多个文件实例化。我的主要副本可能在我的本地文件系统上，也许我在另一个DR站点或其它地方有第二个实例，但都是同一个文件，不是元数据的分叉副本，而是相同的文件元数据。不仅如此，Hammerspace的NAS功能的一部分是启用版本控制，例如或者全局快照，因此在元数据上有多层保护，因此你的元数据无论是在一个站点还是多个站点上，或者数据本身，因为你没有创建分叉副本，所以是相同的副本，即使你可能在其它地方有不同的实例。
观众：这个解决方案是否支持像纠删码或镜像这样的数据存储跨服务器？
是的，它支持，这是我们DSX节点的另一个特性，我们会将实际存储连接到那里，但在这些类型的示例中，我们将使用现有存储的任何底层RAID或纠删码技术，我们将使用他们已经拥有的东西。
观众：所以存储服务器本身可以有自己的RAID解决方案或其它什么？
当然，再次强调，关键点在于元数据与数据的分离。
观众：所以在你目前展示的两个例子中，你正在加速访问一个NFS V3环境，除了编排部分之外，这些特定环境中是否存在风险，我实施了这个，然后我的NAS供应商会升级到4.2并启用并行访问，这只是我知道这只是你的产品所做的一小部分，但这是否是一个复杂性问题，是一个遮盖了NAS解决方案失败的绷带。
看看存储行业，我是说，简单地说，任何供应商都可能这么做。
观众：我并不是说这没有价值，我只是指出你目前展示的东西。
这有几个方面，它是否支持他们竞争对手的存储平台，或者是否仅在他们自己的生态系统中存在。当前有存储供应商，有一个存储供应商正在使用4.2，但它只在他们自己的生态系统中起作用，几乎每个存储供应商都希望人们购买他们的存储，他们不希望人们有能力使用他们已经拥有的数据，他们更愿意你将所有数据移动到他们全新的存储库中，这样他们就可以做出他们声称的所有高级操作。
我们的观点是，如果我可以使用已经投入使用的存储基础设施，现在无论是全力投入到AI工作流程，例如我使用的超大规模计算中心示例，还是作为企业，我想试探一下，看看这对我是否有价值，那么我该怎么做呢？如果我已经必须承诺购买一个全新的基础设施，那么我们通过带来这种基于标准的东西，所以我不必改变我的环境，我不必安装客户端，我不必安装代理，我所做的就是在元数据层面，然后这样做就使得访问变得更加容易。
我已经谈到过这个问题，但Scale-out架构虽然具备标准协议和企业级功能，可一旦你拥有一个单独的网络并需要通过控制器，每个Scale-out NAS都会遇到性能瓶颈的阈值。当你节点数量达到一定规模时，人们就会引入第二个Scale-out NAS。这是因为必须能够处理混合工作负载，实现线性扩展，并确保基于标准协议。
如果要求客户在他们的客户端安装特定版本的软件，这对厂商来说可能有利，但会限制客户的选择，并不利于客户。因此，我们希望分离元数据路径和数据路径，以获得所需的性能。顺便说一句，如果能加速现有第三方存储不是更好吗？由于它是软件定义的，可以部署在虚拟机、云实例或裸金属上，不在乎使用哪种存储，因为这样能减少复杂性。我不再需要像在Lustre环境中那样使用特定的网络，如InfiniBand，而可以使用现成的标准网络。
在企业中，管理、治理、数据管理和NAS功能至关重要。
观众：能稍微深入谈谈治理方面的内容吗？你指的是什么？
因为我们控制了元数据，下次谈话我会详细讨论数据编排。但我现在想回答你的问题。关于文件的实际生成，如果你有领域限制或需要控制平面进行协调，我们可以谈论基于目标的策略自动化。这样，你就能确定数据应在何时何地存放，以及如何从这里移动到那里，如何保护数据，以及了解有多少实例、它们的版本等。
观众：现在我明白你的意思了，你所说的很到位。
观众：是的，我认为如果将这个理念应用到AI工作负载上，分离元数据和实际数据确实是一个很好的方式，也是正确的方向。在AI场景中，控制性能至关重要，而查找文件常常是一个挑战。传统的文件系统在处理数百万个文件时表现良好，但一旦文件数量达到数十亿甚至数万亿级别，元数据就会成为性能瓶颈。对于更传统的文件系统来说，要解决这个问题并不容易。因此，我认为有效地管理文件位置至关重要。除了文件数量的问题，实际数据和元数据之间的不均衡也是一个需要考虑的因素。特别是当我们谈到小文件问题时，尽管我们可以期望线性性能，但如果你的数据总量达到10PB，但所有的文件都只有100字节大小，那么元数据的管理就会变得…
这正是Lustre这类文件系统所面临的挑战之一。Lustre虽然具有出色的元数据性能，但它主要是为HPC类型的仿真工作流程设计的，可能涉及成千上万个节点。目前，我们在洛斯阿拉莫斯进行的一个测试中，测试系统包含了1000个节点。在Lustre的术语中，这意味着可能有1000个节点同时向单个文件写入数据。然而，在人工智能工作流程中，更多的是小文件问题，可能会出现多对多的情况。这正是pNFS的优势所在，特别是它利用了元数据与数据路径分离的特点，同时又能整个系统进行Scale-out扩展。
观众：那么，你是如何解决处理数十亿、数万亿文件的问题呢？从某种程度上来说，它是线性的扩展，对吧？是不是只需要通过增加更多的硬件就能解决呢？
从数据方面来看，确实只需要增加存储空间。而从元数据方面来看，则需要增加元数据的大小，也就是不断地扩展它。当我们处理可能只有一百万个文件的小环境时，元数据控制器或元数据服务节点可能相对适中和小巧。但一旦开始处理数十亿个文件，特别是当开始添加丰富的元数据时——这在AI环境中尤为重要，因为丰富的元数据是分类和其他类型操作的一部分——那么就需要更多的元数据空间，道理就这么简单。
观众：总的来说，可以说它是线性扩展的，直到达到某个极限？
除了它永远不是一个集群之外。在我的下一个讲座中，我将详细谈谈我们如何跨多个站点进行Scale-out扩展。即使在那个超大规模的例子中，你看到的三个元数据服务节点，以及它们的HA对，它们的主要目的不是为了Scale-out扩展，而是为了冗余。不过，这也为你提供了分区和扩展的能力。
观众：那么，你们一些最大的客户是不是拥有数十亿甚至数万亿的文件？
是的，关于数万亿的文件，我目前还不太清楚，但确实有客户拥有数十亿的文件。
观众：嗯，这只是时间的问题。
确实，问题在于，如果你设计的是一个不基于底层硬件而是基于软件的系统，并且你的基础是现场可部署的，那么它必须能够扩展到传统的Scale-out NAS无法企及的级别。传统的NAS系统会受到限制，因为它们是根据控制器中的硬件配置来设计的，一旦达到某个极限，就会遇到扩展障碍。而我们的系统是根据线性比例设计的，所以只要增加网络、存储和服务器，你就可以继续无缝扩展。到目前为止，即使在极端规模的情况下，我们也没有遇到过任何问题。
用Hammerspace技术驾驭非结构化数据编排
深入探讨Hammerspace Global Data Environment软件的核心能力，以及它是如何自动化处理跨多个供应商、地点，甚至多个云存储环境中的非结构化数据的。重点关注如何解决分布在各种孤岛环境、地点和云中的数据对AI流程的需求问题。
Hammerspace Global Data Environment软件如何自动化处理非结构化数据的能力，包括跨越多个供应商、地点和多个云基础设施的各种存储环境。对于AI工作流程来说非常有益，因为数据往往分布在不同地点和孤岛环境中。Hammerspace的解决方案关键在于将文件系统元数据与实际数据分离，并将其提升到基础设施层之上，形成全局元数据控制平面。这样，就可以在不同存储系统和位置之间实现文件的通用视图，实现透明和自动的数据编排，无需中断用户访问或要求数据迁移。
基于Linux，包含两个主要组件：用于元数据控制的Anvil服务器和用于I/O处理的DSX节点。它支持多协议访问，包括NFS、并行NFS和S3，并允许设置基于目标的数据管理策略，如保护、分层和地理考虑。可以灵活地安装在各种平台上，无论是裸金属、云实例还是虚拟机，都能促进本地存储与云资源的无缝集成。这使得诸如将AI工作负载突发到云端、管理全球站点间的数据以及通过自动化数据移动优化计算资源成本等用例变得轻松实现。
不同行业的应用实例，比如在线游戏、火箭公司Blue Origin以及伦敦的一个数据中心，它们通过将渲染作业编排到更经济的云区域中，成功降低了成本。
在之前的交流中，我已经提到AI流程中涉及多来源数据的问题。而Hammerspace有一个解决方案，能够自动化地不仅聚合这些数据，还能在不移动数据的情况下进行数据编排。大家可以参考我之前的讲解内容。
问题在于，当企业面临多种存储类型时，他们经常需要在数据已经存储在现有的孤岛存储环境中时，运行推理训练或推理工作流。这时，文件系统元数据与实际数据本身是分开的，也就是说，文件系统元数据被锁定在底层存储中。因此，我们必须通过技术手段来移动这些数据，这在工作流中确实是个大问题。
在Hammerspace中，我们通过将文件系统提升到基础设施层之上，成功解决了这个问题。这意味着我们将文件系统元数据提取出来，并没有移动实际数据，只是将元数据整合到Hammerspace的并行Global File System中，进入我们的Global Data Environment。如此一来，通过把文件系统提升到基础设施层之上，我们创建了一个通用的元数据控制平面，这样每个人都能看到相同的文件。这也意味着任何在后台进行的数据编排都是完全透明的。
我可以打开一个文件并进行操作，而在这个过程中，数据可能会根据策略或其它条件从一个存储移动到另一个存储，甚至从一个位置迁移到另一个位置，我对此却一无所知。就像我看着磁盘上的文件时，即使它正在从一个盘片移动到另一个盘片，或者从一个磁盘子系统迁移到另一个磁盘子系统，在独立的NAS中，我也察觉不到。
我们进一步扩展了这个概念，让用户只看到一个文件，他们看到的是文件系统，却看不到任何差异。与此同时，管理员拥有全局控制权。
整个Hammerspace堆栈从多协议前端开始，无论是通过NFS接入，还是需要高性能的并行NFS，就像我之前提到的，或者是S3。如果你有一个Kubernetes环境，你想要访问所有这些文件系统元数据，但关键在于，现在你拥有了提供丰富数据服务或数据保护的能力，无论是分层还是其它可能在后台进行的操作，所有这些都是在后台默默完成的，这样用户就永远不会受到任何干扰。就像你之前提到的那样，它不会给用户增加任何复杂性。
Hammerspace的组件，再次强调一下，这是软件定义的，可以灵活地安装在裸金属、云机器实例以及虚拟机上。所有这些组件都是基于Linux系统的，它包含两个部分：一个是软件加载，一切都包含在内；另一个则是标准的基于Linux的Anvil服务器，它扮演着元数据控制平面的角色。而DSX节点则是数据服务节点，负责处理所有的I/O操作。因为我们特意将数据路径与元数据路径分开，所以你看到的左侧是NFS v4.2元数据在并行NFS环境中的展现，例如我们的Hyperscale NAS。这些其实都只是元数据，而在最右侧，则是直接的数据路径。在混合工作负载中，不论在Mac上还是在Windows机器上，我都需要看到相同的文件系统。我可以通过标准的NFS进行访问，所有的I/O操作如果不是通过并行文件系统访问进行直接IO，而是通过pNFS访问进行的，它们都会经过扩展的DSX节点。现在这些操作都可以自动化了。
在Hammerspace内部，关键在于文件系统是全局的，所以任何数据编排的操作都是在幕后默默进行的，不会影响到我。你可以根据目标设定策略，决定你希望达到什么效果，如何保护数据。无论数据是临时存储的你不在乎，还是需要受保护的重要数据，都可以设定相应的策略。如果需要，数据还可以被转移到DR站点。
另外，由于治理原因，数据可能不能移出特定的地理位置，这可以通过自定义元数据或简单的分层环境来实现。
例如，你可能想将数据从高性能分层转移到下游。这些都可以在设置中完成。它其实就是一系列if语句来构建目标，所以当新数据落地时，根据它的特定元数据标签或属性，或者来源，你可以决定如何处理这些数据。这些策略不仅可以应用于活动文件，还可以应用于任何数据。
更重要的是，在AI环境中，你可以使用标准的Hammerscript来编写脚本，进行数据编排。也许一个元数据标签就会成为决定因素，决定以何种方式实现这些目标。
而且，这些目标可以在文件的粒度级别进行设定，所以你不需要为整个卷设置相同的策略。如果你有需要以特定方式访问的单个文件，系统会不断地监视目标和数据是否与实际目标一致，并进行实时监视。一旦发现不一致，它会立即发送警报。举个例子来说，作为一个存储管理员，我可能会面临多个数据孤岛的问题。我希望确保底层存储系统不仅能对存储本身进行适当操作，还能对存储上的数据进行适当处理。因此，这个全局控制平面让我能够自动化数据的位置、放置方式以及何时移动或应该移动。
这些数据服务现在可以跨所有数据，不论是在传统存储上、新存储上，还是在云上、远程站点上，我都能采取这种全局观和全局控制来自动化所有这些操作。而且，我还可以在AI环境中自动化这一切。这可能意味着，我们首先从现有存储中提取数据的元数据来进行初步过滤，接着创建一个编排策略，将其分阶段或推送到GPU引擎、更快的存储介质或其它地方。但由于这些操作都是在后台默默进行的，所以并没有创建分支副本，也不需要用户或应用程序改变访问位置。他们在操作前后看到的都是相同的文件系统。
在我们刚刚宣布的Hyperscale NAS中，我们充分利用了pNFS 4.2的特性，仅需要元数据控制器控制平面。我们向客户端发送文件系统布局的命令，这些命令都是基于标准Linux的，无需定制安装，无论是存储端还是服务器端都能顺畅运行。
通常，客户会有更多的存储需求。他们可能拥有其它存储系统，特别是当人们开始涉足AI领域时，他们可能需要一定量的高性能存储。如果他们能够使用本地GPU，那么他们可能还需要其它文件存储。所有这些数据都需要得到妥善管理，并有可能被输入到AI管道中。
如果他们无法获取本地GPU，也许他们想要将业务扩展到云端。也许他们并不需要长时间保留AI基础设施，只需要运行一次任务。这时，他们可以在云中租用GPU集群。在云端，Hammerspace可以安装在云实例中，并且这个并行的Global File System可以从他们的本地环境无缝延伸到云端。这意味着，不仅在存储方面你能将本地存储扩展到云端，而且你的用户也只会看到一个文件系统。数据存储在云端还是本地环境中，完全取决于管理员的策略。对于用户或应用程序来说，他们只看到这个文件，甚至不知道它具体存储在哪里。但如果需要将这种能力扩展到云端，我们可以在几分钟内启动一个Hammerspace实例。我有一个实例，稍后我会展示给大家看。文件系统元数据现在可以被扩展，我可以编排作业到云实例中运行GPU工作负载，完成后关闭它，这样就不会产生不必要的成本。
这项技术还可以跨多个站点扩展。例如，我们的客户中有一家拥有多达12个全球站点的在线游戏公司。这些站点遍布全球，拥有12个数据中心。在他们的图形制作中，这些数据中心都共享着同一个文件系统的相同视图。这基本上是一个全天候的工作流程，随着太阳的移动而不断工作。但从用户的角度来看，他们只看到一个文件系统。所有的数据编排都是在后台自动完成的。
在一个非常大的语言模型环境中，这项技术正在被使用，并与我们的Hyperscale NAS配置相结合。我们使用的是标准的现成Linux，客户端和存储服务器上都不需要安装任何来自Hammerspace的额外软件。通过简单地使用现有的并行NFS——Linux内核中的高性能并行文件系统，我们就能够轻松管理这一切。
在其它环境中，以Blue Origin这家火箭公司为例，他们拥有多个站点，包括云端的站点。因此，他们面临的问题是数据可能在汉斯维尔或得克萨斯州产生，却需要华盛顿的资源进行分析，甚至可能还需利用云来完成。这家公司由杰夫·贝索斯创立，他同时也与亚马逊有关联，但亚马逊自己也无法解决这一难题。通过构建Global File System，将这个并行文件系统推向全球，随后利用数据编排自动化文件的实例化，这样就不会打扰到用户，不会造成复制泛滥，也不会局限于某种类型的存储。这只是一个使问题得以进一步解决的方案。
再举一个例子，一家主要数据中心位于伦敦的公司，他们希望实现按需扩展。就像将数据推送到云中的GPU农场一样，他们也需要将数据推送到云中的渲染农场。在伦敦，这些云端服务器的电力和制冷费用非常昂贵。但如果他们能将数据推送到加拿大，比如利用那里的水冷却或水发电，他们就能节省30%的费用。在他们的情况下，一个作业可能价值一百万美元，30%的节省可是一大笔钱。
所有这一切对用户来说都是透明的，通过数据编排在后台自动化进行，用户甚至不知道Hammerspace的存在。因为一切都是自动的，用户只需简单地添加一个名为“render”的元数据标签，系统就会通过套利算法理解，今天加拿大的计算资源费用比科罗拉多州便宜，于是将其无缝路由到加拿大。系统会在远程云区域启动一个Hammerspace实例，同步元数据，作业运行。这些作业可能需要一个月才能完成。一旦完成，数据会被带回他们的本地区域，他们关闭实例，因此不会浪费任何额外的资源。
所以，在运行AI应用程序时，全局访问至关重要。你需要能够查看所有数据，而非仅其中的一部分。同时，你也需要在幕后拥有强大的编排能力，并能享受全球数据服务。
—【本文完】—
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）
