Lustre 并行文件系统¶

Lustre 是 Top500 超算中使用最广泛的并行文件系统¹，诞生于 Carnegie Mellon University，现由 OpenSFS / EOFS 社区维护。它的核心设计目标是：在数千节点的 HPC/AI 集群上，提供单一 POSIX 命名空间，同时达到 TB/s 级聚合 IO 带宽。

1. 核心设计决策：元数据与数据分离¶

传统文件系统（ext4、XFS）将元数据和数据放在同一设备上，单机 IO 能力就是上限。Lustre 的第一个关键决策是把"文件叫什么、在哪里"和"文件内容是什么"拆到不同的服务器角色：

┌─────────────┐   命名空间操作    ┌─────────────────────────┐
│  Client      │ ◄──────────────► │  MDS（Metadata Server）  │
│  (POSIX 挂载) │                  │  管理 MDT（Metadata Target）│
│              │   批量数据 IO     ├─────────────────────────┤
│              │ ◄──────────────► │  OSS（Object Storage Server）│
│              │                  │  管理 OST（Object Storage Target）│
└─────────────┘                  └─────────────────────────┘
                                          ▲
                                 ┌────────┴────────┐
                                 │ MGS（Management  │
                                 │  Server）         │
                                 │ 管理 MGT：全局配置 │
                                 └─────────────────┘

设计权衡：

关键数字²：单文件系统可扩展至数百台 OSS、数千个 OST，聚合容量数百 PB，聚合吞吐 TB/s 级。

2. 条带化（Striping）：并行 IO 的核心机制¶

Lustre 的第二个关键决策是将文件数据切片分布到多个 OST，而非整文件存放在单一设备上。

工作原理¶

一个文件的字节流按固定大小（stripe_size，默认 1-4 MB）切分为条带，轮转分配到 stripe_count 个 OST：

文件逻辑视图：  [Chunk 0][Chunk 1][Chunk 2][Chunk 3][Chunk 4][Chunk 5]
                    │         │         │         │         │         │
物理分布：       OST-0     OST-1     OST-2     OST-0     OST-1     OST-2
                (stripe_count = 3, stripe_size = 4MB)

用户可控的条带参数¶

条带布局在文件创建时确定，后续修改需显式迁移（lfs migrate）。用户通过 lfs setstripe 逐文件或逐目录设置：

设计权衡¶

关键约束：Lustre 默认不跨 OST 复制数据——条带化提升的是带宽，不是冗余。数据可靠性完全依赖 OST 底层的 RAID 或 ZFS 冗余。

3. LNet：自建网络协议层¶

Lustre 没有直接使用 TCP/IP 或 InfiniBand verbs，而是自建了 LNet（Lustre Networking）——一个内核态网络抽象层，解决两个问题：

1. 多 fabric 抽象：同一套文件系统代码运行在 Ethernet、InfiniBand、OPA 等不同网络上，通过可插拔的 LND（Lustre Network Driver）适配
2. RPC + RDMA 优化：所有 IO 走 Portal RPC（PTL-RPC），批量数据传输利用 RDMA 零拷贝

架构分层¶

Lustre 文件系统层（LLITE / LOV / MDC / OSC）
        │
    PTL-RPC（Portal RPC：请求/响应 + 批量数据描述符）
        │
      LNet（网络抽象：路由、Multi-Rail、负载均衡）
        │
      LND（驱动层：socklnd = TCP，o2iblnd = InfiniBand/RoCE/OPA）

关键能力¶

• 异构路由：LNet 路由器桥接不同网络（如 InfiniBand 集群 ↔ Ethernet 管理网），客户端无需直连所有服务器
• Multi-Rail：同一节点的多块网卡聚合带宽 + 故障容错，对上层透明
• 零拷贝：RDMA 场景下，OSS 直接 GET/PUT 客户端内存中的数据缓冲区，无需内核 bounce buffer

设计权衡：自建协议栈增加了维护成本和内核依赖（Lustre 必须以内核模块运行），但换来了极致的 IO 路径控制——从文件系统语义到网卡 DMA，全链路由 Lustre 管理。

4. LDLM：分布式锁保障 POSIX 一致性¶

数千客户端并发访问同一命名空间，POSIX 语义要求强一致性（如 read 必须看到最新 write）。Lustre 通过 LDLM（Lustre Distributed Lock Manager）实现：

冲突处理流程¶

Client A 持有文件 F 的写锁（extent [0, 4MB]）
Client B 请求 F 的 [2MB, 6MB] 区间的读锁
    → MDS/OSS 检测冲突
    → 向 Client A 发送 Blocking AST（回调）
    → Client A 刷新脏数据、释放锁（或降级为读锁）
    → Client B 获得锁，执行读取

设计权衡：强一致性保障了 POSIX 语义正确性，但锁冲突是性能杀手——大量客户端并发写同一文件时，Blocking AST 风暴会显著降低吞吐。实践中通过条带化（不同客户端写不同 OST 区间）和 lockahead hint 缓解。

5. 存储后端：ldiskfs vs ZFS¶

每个 Target（MDT/OST/MGT）是一个格式化的块设备，Lustre 支持两种后端：

选型权衡：ldiskfs 是历史默认选择，元数据操作延迟更低；ZFS 不需要内核补丁，提供数据完整性保障（对科学计算的长周期数据尤为重要），且扩展上限高一个数量级。

6. HA 设计：配对服务器 + 共享存储¶

Lustre 不做跨服务器数据复制，而是用共享存储 + 主备切换实现高可用：

┌──────────┐    共享存储柜    ┌──────────┐
│  OSS-A   │◄──────────────►│  OSS-B   │
│ (主：OST1,2) │  多端口 SAS/FC  │ (备：空闲)  │
└──────────┘                └──────────┘
       │                          │
       │  OSS-A 故障               │
       │  ──────────►              │
       │                    OSS-B 挂载 OST1,2
       │                    继续服务 IO

HA 构建单元：两台服务器 + 共享存储柜组成最小 HA 对。整个文件系统由多个 HA 对组成——每个 HA 对有确定的容量和吞吐，可线性扩展。

设计权衡：

7. 与 AI 训练工作负载的关联¶

Lustre 在 AI 基础设施中的位置是存储网络层的并行文件系统³：

GPUDirect Storage 集成：Lustre 支持 NVIDIA GPUDirect Storage（GDS），数据从 OST 通过 RDMA 直达 GPU 显存，绕过 CPU bounce buffer，在大规模数据加载场景下显著降低延迟和 CPU 开销。

参考资料¶