第10章 GPU集群的存储设计与实现
2025.12.07在前面的章节中，我们已经为GPU集群构建了强大的计算核心（GPU服务器）、高速的内部“神经网络”（计算网络）以及灵活的虚拟“城市规划”（网络虚拟化）。现在，我们来到了构建这个“AI都市”的最后一块，也是同样至关重要的一块基石——存储。
存储系统是整个GPU集群的“粮仓”和“资料库”。它承载着从操作系统、应用程序、到海量的训练数据集、中间检查点、再到最终生成的模型等所有数据。如果存储系统性能不佳，数据供给跟不上，那么再强大的GPU和再快的网络也只能“望眼欲穿”，整个集群的效率将一落千丈。正如一句行业名言所说：“在高性能计算中，你花在计算上的每一分钱，都得在I/O上花同样的钱来支撑。”
然而，为大规模GPU集群设计存储，并非选择一块“足够大的硬盘”那么简单。AI工作负载对存储的需求是多样化、多层次、且极其苛刻的。 操作系统和程序需要一个稳定、可靠、低延迟的存储卷。
动辄PB级的原始数据集（图片、视频、文本）需要一个容量巨大、成本可控、易于管理的存储池。
在分布式训练过程中，成百上千个计算节点需要并发地、高性能地读取同一批训练数据，对存储的并发读性能提出了极致挑战。
训练过程中产生的巨大模型检查点（Checkpoint），需要被快速地写入，以减少训练中断时间。
没有任何一种单一的存储技术能够完美地满足所有这些需求。因此，一个成功的GPU集群存储架构，必然是一个分层的、异构的、针对不同需求采用不同技术的组合方案。
本章，我们将作为存储架构师，系统性地探讨如何为GPU集群设计和实现一个高性能、高可用的分层存储体系。我们将围绕AI工作流中三种典型的存储需求，来剖析三种主流的分布式存储技术：
- 程序与系统存储——分布式块存储：我们将探讨为何需要分布式块存储，以及它是如何为虚拟机和容器提供类似本地硬盘的、高可用的“云硬盘”服务的。我们将以业界应用最广的开源项目Ceph RBD为例，深入其原理。
- 海量非结构化数据存储——分布式对象存储：我们将学习对象存储是如何以其近乎无限的扩展能力、极低的成本和简单的HTTP接口，成为存储海量原始数据集的理想选择。我们将介绍其代表作Ceph RGW和MinIO。
- AI训练素材存储——分布式并发高性能存储：这是本章的重点。我们将聚焦于如何解决大规模并行训练中的“数据喂养”难题，深入剖析为HPC和AI而生的分布式并行文件系统，如经典的Lustre和GPFS，以及它们是如何与GPU Direct Storage等技术结合的。
通过本章的学习，你将掌握一套完整的GPU集群存储架构设计方法论，能够根据不同的数据类型和访问模式，选择最合适的存储技术，并懂得如何将它们组合起来，构建一个既能“存得下”，又能“跑得快”的强大数据底座，为你的AI集群提供源源不断的“数据燃料”。
10.1 程序与系统存储——分布式块存储
在我们的GPU集群中，无论是运行在虚拟机还是裸金属服务器上的操作系统，以及部署在容器中的应用程序，都需要一个地方来安装和运行。这个“地方”就是它们的根文件系统，它需要被挂载在一个块设备（Block Device）上。
在传统的单机环境中，这个块设备就是一块本地的SATA或NVMe SSD。但在一个大规模的、云化的集群环境中，依赖本地盘存在诸多问题：可靠性差（本地盘损坏会导致整个系统或应用丢失）、无法迁移、管理不便。因此，我们需要一种网络化的、分布式的块存储，它能像“即插即用”的U盘一样，为任何一个计算节点提供一个高可用的、性能良好的虚拟硬盘，这就是“云硬盘”服务的由来，其底层技术核心正是分布式块存储。
10.1.1 块存储的业务需求
- 稳定可靠的系统盘：为成百上千个计算节点的操作系统提供启动盘。这些盘必须具备高可用性，即使后端某个物理硬盘或存储服务器损坏，操作系统的运行也不应中断。
- 持久化的容器卷：容器本身是无状态的，但许多应用（如数据库、中间件）需要将数据持久化。分布式块存储可以为这些有状态的容器提供一个生命周期独立于容器的、可持久化的存储卷（Persistent Volume, PV）。当容器在不同节点间迁移时，这个存储卷可以被轻松地“卸载”再“挂载”。
- 虚拟机磁盘：在虚拟化环境中，每个虚拟机的虚拟磁盘（如VMDK, qcow2文件）需要存放在一个共享的、高性能的存储上，以便支持虚拟机的创建、快照、迁移等高级功能。分布式块存储是承载这些虚拟磁盘文件的理想后端。
- 低延迟与中等吞吐：系统和程序盘的访问模式通常是大量的、随机的小文件读写，对延迟（Latency）和IOPS（每秒读写次数）比较敏感，而对持续的大块读写吞吐量要求相对不高。
10.1.2 集中式块存储与分布式块存储
集中式块存储（SAN）：传统的企业级存储方案是采用专用的存储区域网络（Storage Area Network, SAN）。一个昂贵的、高性能的集中式存储阵列（如EMC, NetApp的产品）通过Fibre Channel或iSCSI协议，向服务器提供块设备。
优点：性能高，功能成熟丰富。
缺点：成本高昂，存在纵向扩展（Scale-up）瓶颈，管理专有复杂，是典型的“烟囱式”架构。
分布式块存储：现代云环境更青睐分布式块存储。它采用横向扩展（Scale-out）的架构，将成百上千台普通x86服务器上的本地硬盘，通过软件组织成一个统一的、巨大的存储资源池。
10.1.3 开源实现：Ceph RBD (RADOS Block Device)
Ceph是当今最流行、功能最全面的开源分布式存储系统。它是一个统一的存储平台，可以在同一个集群上同时提供块存储（RBD）、对象存储（RGW）和文件存储（CephFS）。我们首先来剖析其块存储组件——RBD。
Ceph的核心架构：RADOS
Ceph的底层基石是一个名为RADOS（Reliable, Autonomic Distributed Object Store）的、高度可靠的分布式对象存储系统。理解RADOS是理解Ceph所有上层服务的关键。
OSD（Object Storage Daemon）：Ceph集群由许多个存储节点组成，每个节点上运行着多个OSD守护进程。每一个OSD进程都直接管理着一块物理硬盘。数据的存储和读取最终都是由OSD来完成的。
对象（Object）：在RADOS中，所有数据，无论上层是块、文件还是对象，最终都会被切分成固定大小（默认为4MB）的对象来存储。
PG（Placement Group）：为了高效地管理海量的对象，Ceph引入了PG的概念。PG是一个逻辑上的对象集合。系统会将对象通过哈希算法，映射到某个PG中。数据的分布和复制，都是以PG为单位进行的。
CRUSH算法：这是Ceph的“灵魂”。当需要读写一个对象时，客户端如何知道这个对象存储在哪台服务器的哪个硬盘上？传统分布式系统通常需要一个中心化的元数据服务器来记录这些信息，但这会成为瓶颈。Ceph独创了CRUSH（Controlled Replication Under Scalable Hashing）算法。客户端只需要知道集群的拓扑结构图（CRUSH Map），就可以通过一系列哈希计算，自行、实时地计算出任何一个对象所对应的PG，以及这个PG的主副本和备副本分别位于哪些OSD上。这实现了无中心元数据的设计，带来了极高的扩展性。
MON（Monitor）：MON是集群的“监视器”和“仲裁者”。它不存储用户数据，只维护集群的关键状态信息，如OSD的存活状态、CRUSH Map、认证信息等。一个Ceph集群通常需要3个或5个MON来组成一个高可用的Paxos集群。
RBD的工作原理：
- 创建RBD镜像：管理员在Ceph集群上创建一个RBD“镜像”（Image），例如一个100GB的虚拟硬盘。
- 条带化（Striping）：Ceph会将这个100GB的逻辑卷，在逻辑上切分成连续的、固定大小（默认为4MB）的对象。例如，
image_object.0000,image_object.0001, ...。 - 客户端挂载：在GPU服务器上，可以通过内核RBD驱动（krbd）或用户态的librbd库（用于QEMU/KVM）来访问这个RBD镜像。客户端会从MON获取最新的CRUSH Map。
- I/O流程：当操作系统要向这个块设备的第5MB处写入数据时，RBD客户端驱动会计算出这个位置对应的是
image_object.0001这个对象。接着，客户端利用CRUSH算法，自行计算出image_object.0001所属的PG，以及这个PG的主OSD在哪里。然后，客户端直接与这个主OSD建立连接，并将写请求发送给它。主OSD收到数据后，负责将数据复制到该PG的其他备副本OSD上。当所有副本都写入成功后，才向客户端确认写入完成。
10.1.4 分布式块存储的故障恢复
OSD故障：当一个OSD进程或其所在的硬盘/服务器故障时，MON会很快发现它心跳超时，并将其标记为down。
所有包含这个故障OSD的PG，都会进入“降级（degraded）”状态。
Ceph会立刻启动自愈（Self-Healing）过程。对于每个降级的PG，它会从其幸存的副本中，选择一个新的、健康的OSD，并将丢失的数据重新复制一份过去，使PG恢复到完整的、健康的副本数状态。整个过程完全自动，无需人工干预。
10.1.5 分布式块存储的性能优化
使用SSD/NVMe作为OSD：对于需要高IOPS和低延迟的块存储场景（如系统盘），强烈建议使用SSD或NVMe硬盘作为OSD的物理介质。
日志盘（Journal/WAL）：Ceph OSD在写入数据前，会先将写入操作记录到一个日志中。可以将这个日志配置在更高性能的介质上（例如，用HDD作为数据盘，用一小块NVMe SSD作为所有HDD OSD的共享日志盘），这可以极大地加速写操作的响应。
缓存层（Cache Tiering）：Ceph支持设置一个由高速SSD组成的“缓存层”和一个由大容量HDD组成的“基础层”。热点数据会被自动地提升到缓存层中，以加速访问。
通过Ceph RBD，我们可以为整个GPU集群提供一个统一的、高可用、可扩展的块存储资源池，完美地解决了操作系统、容器持久化卷和虚拟机磁盘的存储需求。
10.2 海量非结构化数据存储——分布式对象存储
AI训练所需的数据集，特别是图像、视频、音频、文本等，都是非结构化的。这些数据集的特点是：
容量巨大：动辄TB、PB甚至EB级别。
文件数量众多：可能包含数百万甚至数十亿个小文件。
访问模式：通常是一次写入、多次读取（WORM, Write-Once-Read-Many）。数据上传后很少被修改。
访问接口：需要一个简单、标准的访问方式，便于各种数据处理工具和框架的集成。
对于这种场景，传统的文件系统（无论是本地文件系统还是NFS）都难以应对。而分布式对象存储（Distributed Object Storage）则成为了存储这类海量非结构化数据的理想选择。
10.2.1 对象存储的核心概念
与文件系统和块存储都不同，对象存储采用了一种极其扁平、简单的三级数据模型：
- 数据（Data）：原始的数据内容，即文件本身。
- 元数据（Metadata）：描述数据的一组键值对，可以是系统预定义的（如大小、创建时间），也可以是用户自定义的（如
label:cat,source:camera1）。 - 全局唯一ID（Universally Unique ID, UUID）：每个对象在整个存储系统中都有一个唯一的ID。
扁平的命名空间：对象存储没有文件系统中那种复杂的、层级的目录树结构。所有的对象都“平铺”在一个称为存储桶（Bucket）的逻辑容器中。对象的访问路径通常是Bucket_Name/Object_Key。
通过API访问：对象存储的主要访问方式不是挂载成一个本地文件系统，而是通过简单、标准化的RESTful HTTP API。最著名的就是Amazon S3（Simple Storage Service）API，它已经成为了对象存储领域的事实标准。用户通过GET, PUT, DELETE等HTTP动词，就可以完成对象的上传、下载和管理。
10.2.2 对象存储的优势
近乎无限的扩展性：扁平的命名空间和无中心元数据的架构（很多对象存储系统也借鉴了类似CRUSH的算法），使得对象存储系统可以轻松地横向扩展到数千个节点，管理EB级别的数据和万亿级别的对象。
极低的成本：对象存储通常被设计运行在便宜的、大容量的SATA硬盘和通用x86服务器上，单位存储成本非常低。它还支持纠删码（Erasure Coding）等技术，可以用比多副本更低的冗余度来保证数据可靠性，进一步降低成本。
高持久性：通过多副本或纠删码，可以提供极高的数据持久性（如11个9或更高）。
标准化的接口：基于HTTP的S3 API简单易用，拥有极其广泛的生态系统支持。几乎所有的大数据工具、AI框架和客户端库都能与S3-兼容的存储进行交互。
10.2.3 入门级对象存储的首选：Ceph RGW (RADOS Gateway)
Ceph再次登场。RGW是Ceph提供的、构建在RADOS底层之上的一个S3兼容的对象存储网关。
工作原理：
RGW是一个无状态的守护进程，可以部署多个以实现高可用和负载均衡。
当一个S3客户端（例如一个数据预处理脚本）发送一个PUT请求来上传一个对象时，请求首先到达某个RGW网关。
RGW负责处理S3协议的认证、授权等。
然后，RGW将这个上传的对象，切分成多个RADOS对象，并像RBD一样，利用CRUSH算法计算出这些对象应该存储在哪些OSD上。
最后，RGW直接与这些OSD通信，完成对象的写入。
优点：如果你已经为了块存储部署了一套Ceph集群，那么增加对象存储功能几乎是“零成本”的，只需要启动几个RGW进程即可。它提供了一个统一存储的便利性。
缺点：RGW的性能和S3元数据操作的效率，相比一些专门为对象存储设计的系统，可能不是最优的。
10.2.4 开源海量对象存储：Swift
Swift是OpenStack开源云计算项目中的对象存储组件。它是最早的、影响力巨大的开源对象存储系统之一。
架构特点：一致性哈希环（Consistent Hashing Ring）
Swift不使用像CRUSH那样的动态计算，而是维护一个静态的“环”。这个环是一个巨大的哈希空间，所有的存储节点（硬盘）都被映射到这个环上的不同位置。
当要存储一个对象时，通过哈希对象的名称，在环上找到一个位置，然后顺时针选择接下来的N个节点（例如3个）来存放该对象的副本。
优点：架构简单，易于理解和实现。
缺点：环的变更（如增删节点）操作相对复杂和耗时，扩展性和灵活性不如Ceph。
现状：Swift在OpenStack生态中仍然有广泛应用，但在新的项目中，其光芒在一定程度上被Ceph和MinIO所掩盖。
10.2.5 商业化对象存储：大型公有云对象存储私有化
各大公有云厂商（AWS, Google Cloud, Azure, 阿里云等）都提供世界级的、极其成熟的对象存储服务。近年来，它们也开始将其在公有云上验证过的对象存储技术，打包成软硬件一体机或纯软件的形式，提供给企业在本地数据中心进行私有化部署。
优点：可以获得与公有云一致的体验、功能和企业级支持。
缺点：价格昂贵，技术栈通常是闭源的，存在厂商锁定的风险。
10.2.6 未来之星：RustFS
RustFS 是一个以“极速+云原生”为定位的新兴开源对象存储项目（Apache 2.0 许可证），用 Rust 从零重写，社区对标 MinIO（参见项目仓库）。以下特性均来自其自述口径，尚缺独立第三方评测验证，读者选型时应自行压测。
核心特点（项目自述）：
为极致性能而生：全程 async/await + Tokio，对 NVMe-oF、RDMA、100 GbE 做了零拷贝路径优化；项目方给出的对比口径为 4 KB 小对象场景下吞吐约为 MinIO 的 2.3 倍（厂商/社区自测基准，未经独立复核，且小对象表现不能外推到大对象顺序读写场景）。
云原生设计：单二进制文件＋无状态，提供 K8s Operator 与 Helm Chart，支持容器化部署与自动扩缩容。
S3 兼容：宣称兼容主流 S3 API（含加密、Multipart、Versioning、Lifecycle 等），具体通过率以项目文档为准。
架构简洁：元数据与数据同盘存放，去除了独立元数据库依赖；水平扩容时加入节点即可自动完成 rebalancing。
在 AI 领域的应用（合成示例，用于说明架构模式，非实测数据）：
凭借内存级延迟与 Rust 的内存安全，可以将 RustFS 用作“热数据缓存层”。典型流程：
- 冷数据存放在低成本 HDD Ceph 或公有云归档层；
- 训练前通过 rustfs-cli preload 将当前 Epoch 所需子集异步拉取到 NVMe RustFS 集群；
- GPU 节点通过 S3-API 直接高并发读取。这一“冷热分层＋预取”模式的收益取决于数据集大小、网络带宽与访问局部性，须以实际负载压测为准。
10.3 AI训练素材存储——分布式并发高性能存储
我们已经为系统和海量原始数据找到了合适的“家”。现在，我们面临整个存储设计中最严峻的挑战：如何“喂饱”正在进行大规模分布式训练的成百上千个GPU？
这个场景的I/O模式极其特殊：
大规模并发读（Massively Concurrent Read）：数百个计算节点上的数千个data loader进程，可能会在几乎同一时刻，读取同一组训练文件（例如，同一个epoch中的数据）。这会给存储系统带来巨大的并发压力，形成所谓的“读取风暴”。
高吞吐量需求：为了不让GPU空闲，存储系统必须能够提供持续的、与所有GPU节点总网络带宽相匹配的聚合读取带宽。例如，一个拥有128个DGX A100节点的集群，其存储网络总带宽可能高达128 * 200Gbps = 25.6 Tbps = 3.2 TB/s！
对小文件性能有要求：许多数据集（如ImageNet）是由数百万个小文件组成的。存储系统必须能够高效地处理这些小文件的元数据操作和数据读取。
POSIX兼容性：大多数AI框架和数据加载库，仍然习惯于通过标准的POSIX文件接口（open, read, seek）来访问数据。
对于这种“多对一”的高并发、高性能读取场景，传统的NFS（Network File System）会因为其中心化的元数据服务器而迅速成为瓶颈。分布式对象存储虽然扩展性好，但其基于HTTP的、高延迟的访问方式，以及最终一致性的模型，不适合作为训练的热数据层。
真正的解决方案，是为HPC（高性能计算）而生的分布式并行文件系统。
10.3.1 并行文件系统的核心思想：元数据与数据分离
并行文件系统的核心架构思想，是将文件系统的两大功能——元数据管理和数据存储——进行分离。
元数据服务器（Metadata Server, MDS）：一个或多个专用的服务器，负责处理所有的元数据操作。这包括：文件和目录的创建、删除、重命名、权限检查、获取文件属性（stat）、以及最重要的——告诉客户端一个文件的具体数据块存储在哪里。
数据服务器（Object Storage Server, OSS / Data Server）：大量的服务器，负责实际的数据存储。每个OSS都管理着若干个存储目标（Object Storage Target, OST），即物理硬盘。文件的数据会被切分成条带（Stripe），并以轮询（Round-robin）的方式，并行地存储在多个不同的OSS和OST上。
客户端（Client）：运行在计算节点上的文件系统客户端。
I/O流程：
- Open操作：当客户端要打开一个文件时，它首先向MDS发送请求。
- MDS进行权限检查，然后在自己的元数据存储中查找该文件的“布局信息”（Layout），即这个文件的数据被条带化地存储在了哪些OSS的哪些OST上。
- MDS将这个布局信息返回给客户端。
- Read/Write操作：接下来，当客户端要读写文件数据时，它不再需要与MDS通信。它会根据从MDS获取的布局信息，直接、并行地与所有相关的OSS建立连接，并同时从多个OSS上读取（或写入）数据条带。
优势：
并发与带宽聚合：通过将数据条带化到大量OSS上，多个客户端可以并行地访问不同的OSS，或者一个客户端可以并行地从多个OSS读取数据。整个文件系统的聚合带宽，是所有OSS带宽的总和，可以随着OSS数量的增加而线性扩展。
元数据性能：将元数据操作集中到专用的MDS上，可以对MDS进行专门的优化（如使用高速NVMe、大内存），以应对海量小文件带来的元数据压力。MDS也可以配置为高可用集群。
10.3.2 开源大数据存储鼻祖：HDFS
HDFS（Hadoop Distributed File System）是Hadoop生态系统中的分布式文件系统。虽然它并非严格意义上的POSIX兼容并行文件系统，但其设计思想对后世有深远影响。
架构：拥有一个中心化的NameNode（负责所有元数据）和大量的DataNode（负责存储数据块）。
特点：为大文件、流式读取而优化，一次写入、多次读取。
在AI中的局限性：
NameNode是单点瓶颈，元数据性能有限，不擅长处理大量小文件。
并非完全POSIX兼容，需要通过专门的API或FUSE来访问，对现有AI应用不够友好。
10.3.3 业界对HDFS的改进
为了克服HDFS的元数据瓶颈，业界出现了许多改进方案，如Alluxio（一个内存优先的虚拟分布式文件系统，可以作为HDFS的上层缓存）、以及一些商业公司推出的支持多个元数据节点的HDFS变种。
10.3.4 长青松柏：Lustre
Lustre是HPC领域应用最广泛、历史最悠久的开源并行文件系统之一。世界上最快的超级计算机中，有许多都采用Lustre作为其主存储系统。
架构：是典型的元数据/数据分离架构。
MDS (Metadata Server)：负责元数据。
OSS (Object Storage Server)：负责数据。
客户端：Lustre客户端是一个内核模块，提供了完全的POSIX兼容性。
特点：
极致的性能和扩展性：Lustre被设计用来支持数十万个客户端和EB级别的存储，提供TB/s级别的聚合带宽。
成熟稳定：经过数十年的发展和在顶级超算中心的应用，Lustre非常成熟和稳定。
与AI的结合：Lustre可以与GPUDirect Storage技术完美结合。Lustre客户端可以直接将数据从OSS通过RDMA网络，写入到GPU的显存中，实现端到端的高性能数据加载。
挑战：
部署和管理复杂：部署和调优一个大规模Lustre集群，对运维人员的技术水平要求非常高。
10.3.5 另一个巨头：IBM Spectrum Scale (原GPFS)
GPFS是IBM推出的商业并行文件系统，与Lustre齐名，在HPC和商业领域有广泛应用。
特点：
去中心化架构：GPFS在架构上比Lustre更进一步，它没有一个像Lustre MDS那样的中心化元数据瓶颈，元数据管理能力分布在集群的多个节点上，扩展性更好。
丰富的功能：提供了快照、多级存储、云集成等丰富的企业级功能。
商业产品：GPFS是商业软件，需要购买许可证。
10.3.6 如何选择训练素材存储？
对于追求极致性能、不计成本和运维复杂度的顶级AI超算中心，Lustre或GPFS是当然之选。
对于许多企业级的AI平台，也可以考虑一些更易于部署和管理的商业并行文件系统（如WekaIO, DDN EXAScaler），或者利用高性能的NVMe CephFS/MinIO集群，结合上层的数据缓存/预取方案（如Alluxio）来作为训练存储，以在成本和性能之间取得平衡。
10.4 本章小结
在本章中，我们为GPU集群的“数据生命”——存储系统——进行了一次全面的架构设计。我们深刻认识到，单一的存储方案无法满足AI工作流多样化的需求，一个分层的、异构的存储体系才是最佳实践。
我们根据不同的数据类型和访问模式，将集群存储划分为三个逻辑层次，并为每个层次匹配了最合适的技术：
- 对于程序与系统存储，我们选择了以Ceph RBD为代表的分布式块存储。它通过将普通服务器的硬盘池化，为操作系统、容器和虚拟机提供了高可用、类似本地盘体验的“云硬盘”，解决了系统和应用自身的持久化需求。我们深入了其基于RADOS和CRUSH算法的无中心化设计，理解了其高可用和自愈能力的来源。
- 对于海量的非结构化原始数据集，我们选择了以Ceph RGW和MinIO为代表的分布式对象存储。我们学习了对象存储以其扁平的命名空间、S3兼容的API、近乎无限的扩展能力和极低的成本，成为了存储PB级训练数据的理想“数据湖”。
- 对于要求最苛刻的AI训练素材并发访问场景，我们聚焦于为HPC而生的分布式并行文件系统。我们剖析了其元数据与数据分离的核心架构，理解了它如何通过将数据条带化到大量数据服务器上，实现了惊人的并发读取能力和聚合带宽，从而能够“喂饱”成百上千个饥渴的GPU。我们介绍了该领域的两大经典——Lustre和GPFS，并认识到它们是构建顶级AI训练集群存储底座的不二之选。
通过这套分层存储架构的设计，我们为GPU集群构建了一个功能完备、性能均衡的数据底座：
冷数据层/数据湖：用低成本的分布式对象存储（如HDD Ceph）来归档海量的原始数据集。
温数据层/热数据层：用高性能的分布式并行文件系统（如NVMe Lustre）来存放当前正在被训练任务高并发访问的数据子集。
系统与应用层：用高可用的分布式块存储（如SSD Ceph RBD）来承载操作系统和容器持久化卷。
这套存储体系，与我们之前设计的计算、网络架构紧密配合，特别是通过GPUDirect Storage等技术，打通了从存储阵列直达GPU显存的“最后一公里”，共同构成了一个高效、无瓶颈的、真正为大模型时代而生的数据基础设施。在后续的章节中，我们将在此基础之上，探讨如何构建更上层的应用开发与运行平台。