# Lustre "Linux" と "cluster" を融合した名称を持つオープンソース（GNU GPL）の並列ファイルシステムである。1990 年代後半にカーネギーメロン大学の Peter J. Braam が研究プロジェクトとして開始し、2000 年代初頭に Cluster File Systems（CFS）社が商用開発を行った。2003 年 3 月に LLNL の MCR クラスタ上で初の本番運用に入り、同年 12 月に Lustre 1.0 がリリースされた。 ## 主要特性 - **アーキテクチャ**: 分散オブジェクトベースのストレージフレームワーク。MGS/MDS/OSS のサーバ群と MDT/OST のストレージターゲットから構成される。 - **スケーラビリティ**: 数百台のサーバ、数百ペタバイトのストレージ、数万のクライアントノードまでスケール可能。単一名前空間で半エクサバイト超を管理できる。 - **性能**: LNet による RDMA 対応高性能ネットワーク抽象化、LDLM 分散ロックマネージャ、データ・メタデータの分離により、集約スループットが数十 TB/s に達する。 - **コードベース**: 約 750K 行（25 年の開発蓄積）。 - **ライセンス**: GNU General Public License。 - **バックエンドファイルシステム**: ldiskfs（ext4 最適化版）または OpenZFS をサポート。 - **ネットワーク**: InfiniBand、Ethernet（TCP/IP）、OmniPath、HPE Slingshot、Cray Gemini/Aries 等に対応。 ## 採用状況 Top500 上位 10 中 6 台、上位 100 の 65%超、上位 500 の 60%超で使用されている（2024 年時点）。2006 年以来、上位 10 の少なくとも半数で一貫して採用されており、2016〜2017 年にはピーク時 10 台中 9 台に達した。[[Frontier]]、Fugaku、Perlmutter 等のリーダーシップクラスのスパコンに加え、NVIDIA Selene/Eos 等の AI/ML システムにも導入されている。 ## 開発の変遷 - **2003 年夏**: [[Cluster File Systems]] の [[Phil Schwan]] が、1,000ノード規模に向けたメタデータ、ロック、オブジェクトプロトコルの設計経験を発表した。 - **2007 年**: Sun Microsystems が CFS を買収。ZFS 統合を推進。 - **2009 年**: Oracle が Sun を買収。Lustre のオープンソース継続への懸念から [[Whamcloud]] と [[OpenSFS]] が設立。 - **2012 年**: Intel が [[Whamcloud]] を買収。Lustre 2.1 以降の開発を主導。 - **2018 年**: [[DDN]] が Intel の Lustre 事業を買収。現在に至る。 (Source: [[@2025__TOS__Lustre Unveiled - Chapter 2 The Lustre Filesystem]]) ## 2026年時点の性能比較 2026年ISCのLustre BOFで示されたHPE Cray Lustreアプライアンスは、エンクロージャあたり190 GB/s(読み取り)・140 GB/s(書き込み)を記録した。同時期に発表された中国製の[[ParaStor F9000]](Sugon)は160 GB/s・146 GB/sとほぼ匹敵する水準に達しており、Lustreが長年占めてきたオープンソース並列ファイルシステムの性能面での優位が、中国製の専有(proprietary)実装によって狭められつつあることを示す一事例となった。(Source: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]]) ## アーキテクチャ構成要素(2021年時点の実装解説) [[Understanding Lustre Internals]] 第1章は、Lustre を構成する7つのコンポーネント——MGS/MGT(構成情報の提供・永続化)、MDS/MDT(名前空間・メタデータ管理)、OSS/OST(ファイルデータの格納)、Lustre クライアント、LNet(RDMA 対応の通信層)——を整理し、MGS・MDS・OSS の集合を「フロントエンド」、OST/MDT をフォーマットする ldiskfs または ZFS を「バックエンドファイルシステム」と呼ぶ。ファイルレイアウトは Normal(RAID0、ストライプカウント・サイズによるラウンドロビン配置)と Composite(PFL・DoM・SEL を経て FLR に至る合成レイアウト)の2系統に分かれる。ファイルへのアクセスは、FID(128ビットの opaque 識別子)から MDT 上の Layout EA(対象 OST とオブジェクト FID の対応表)を解決する経路をたどる。ソフトウェアスタックは VFS → LLITE → LMV/LOV → MDC/OSC → PTL-RPC → LNet という層でクライアント要求をサーバへ伝え、サーバ側では LNet → PTL-RPC → OSS/MDS → LDLM(ロック)・OFD/OSD(データ)/OSD(メタデータ)という経路をたどる。分散名前空間(DNE)は Phase 1(Remote Directories、静的な単一 MDT 割り当て)から Phase 2(Striped Directories、ハッシュベースの複数 MDT 分散)を経て、将来の Phase 3(auto-striped directories)へ拡張が構想されている。(Source: [[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]]) ## 公式運用マニュアルによるアーキテクチャ概観 [[wiki/entities/Lustre Operations Manual|Lustre Operations Manual]] 第1章は、Lustre を「クラスタ向けストレージアーキテクチャ」と位置づけ、中核コンポーネントである Lustre ファイルシステムを POSIX 準拠の Linux ファイルシステムとして説明する。構成要素は構成情報を配布する MGS、名前空間とメタデータを扱う MDS/MDT、ファイルデータを扱う OSS/OST、通信基盤の LNet、これらへアクセスする Lustre クライアント(MGC・MDC・OSC からなり、LOV が OSC 群を、LMV が MDC 群をそれぞれ束ねて単一の一貫した名前空間を提供する)からなる。ファイルは 128 ビットの FID(64 ビット SEQ + 32 ビット OID + 32 ビットバージョン)で識別され、MDT オブジェクトの layout EA が対象 OST 上のオブジェクトへのマッピングを保持する。ファイルデータは `stripe_count`・`stripe_size` に従って RAID 0 方式で複数 OST へストライピングされ(既定値は 1 ストライプ・1MB)、単一ファイルは最大 2000 オブジェクトまでストライピング可能で、最大ファイルサイズは ldiskfs で 31.25PiB・ZFS で 8EiB に達する。同章は、Lustre がクライアントとサーバを同一ノードで小容量ストレージを共有する P2P 的な用途には、Lustre ソフトウェア層でのデータレプリケーションが無いため不向きであると明言している。(Source: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]]) ## クライアント側永続キャッシュ [[永続クライアントキャッシュ]]の一実装として、[[DDN]]・[[Huazhong University of Science and Technology]]・[[Johannes Gutenberg University Mainz]]が共同開発したNVMM-LPCC([[@2021__TOS__NVMM-Oriented Hierarchical Persistent Client Caching for Lustre]], ACM ToS 2021)がある。LustreのHSM機構とレイアウトロックを再利用し、クライアントノードのNVMMを永続キャッシュとして統合することで、ネイティブLustre比で読み取りスループット最大35.80倍・書き込みスループット最大9.83倍を達成した。既存のMDS/OSS/OST構成に変更を加えず、Llite層へのキャッシュ構造追加とHSMのcopytool連携のみで実現している点が、Lustreのアーキテクチャの拡張性を示す一事例である。 ## サーバ側リクエストスケジューリングと QoS (NRS TBF) Lustre 2.7 以降、サーバ側(MDS・OSS)の PTL-RPC 層に組み込まれた Network Request Scheduler (NRS) 上で、トークンバケットフィルタ(TBF)を用いた QoS 制御が公式サポートされている([[@2017__SC__A Configurable Rule based Classful Token Bucket Filter Network Request Scheduler for the Lustre File System]])。従来の ORR(スループット重視)や CRR-N(NID 間公平性)に対し、TBF は NID/JOBID/OPCode を組み合わせたルールベースの分類と IOPS 単位での非ワークコンサービングなレートシェーピングを提供し、高負荷時の帯域補償(HTC)や余剰帯域の比例配分(PSSB)、大域レート制限(GRL)を通じて、マルチテナント HPC 環境における I/O 干渉と飢餓を抑止する。 ## データ駆動型 I/O ロードバランシング (MCMF による OST 選択) Lustre 既定のラウンドロビン（RR）による OST 割り当て方針は空き容量の単純な閾値判定のみに依存するため、バースト的 I/O を伴う科学計算・ビッグデータ処理下で特定 OST/OSS への極端な負荷集中や不均衡（最大/平均比で 75〜125 倍）を招き、均衡収束に十数時間を要する課題があった。Virginia Tech と ORNL の共同研究([[@2017__IEEE BigData__I O Load Balancing for Big Data HPC Applications]])は、MDS 上で常時動作するグローバルマッパーを提案した。既存の監視基盤（ODDMON）に相乗りして OSS/OST/LNET の実行時統計を収集し、3次マルコフ連鎖によって将来の書き込みバイト数・ストライプ数を予測（精度 95.5%）した上で、最小費用最大流（MCMF）問題として最適な OST リストを解く。Lustre 中核コードを変更することなく、実クラスタおよび最大 3,600 OST の大規模構成において、不均衡収束時間を 7 時間に半減させ、最大 54.5% の帯域向上を MDS CPU 負荷 7.3% 未満で達成した。 ## AI 研究ワークロードにおける挙動と評価 (PRISM) Meta FAIR の 8K GPU クラスタにおける評価([[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]])では、Lustre（クラウド上のマネージド Lustre）とオールフラッシュ NAS（NFS）が比較された。Lustre はストライピングによる書き込み分散の強みを活かし、大規模な単一ファイルチェックポイント保存（`ddp_save` で NAS 比 9〜35% 高速）や低並列度の分散保存（`fsdp_save`）で競争力を維持した。しかし、80 万個の小ファイル（32KiB）を単一ディレクトリにフラット配置したデータローディングでは、メタデータ性能の限界から NAS より 3 倍以上低速となった（ディレクトリシャーディングによってこの差は縮小）。また、ディレクトリ走査（`list_files`）では NAS に比べ最大 80 倍遅延し、FSDP チェックポイント読み込み（`fsdp_load`）でも NAS が最大 3 倍高速であった。この結果は、Lustre が大容量シーケンシャル I/O に優れる一方で、多数の小ファイルや頻繁なメタデータ操作が支配的な対話的 AI 研究環境では NAS との使い分けやディレクトリ設計（シャーディング）が不可欠であることを示している。(Source: [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]]) ## 関連 - 運用組織: [[Oak Ridge National Laboratory]] / [[DDN]] / [[Whamcloud]] / [[OpenSFS]] - 導入先: [[Frontier]] / [[Orion]] - 初期設計: [[Cluster File Systems]] / [[Phil Schwan]] - 概念: [[分散ロック管理]] / [[意図ロック]] / [[オブジェクトベースストレージ]] - ソース: [[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]] / [[@2025__TOS__Lustre Unveiled - Chapter 2 The Lustre Filesystem]] / [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]] / [[@2021__TOS__NVMM-Oriented Hierarchical Persistent Client Caching for Lustre]] / [[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]] / [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]] / [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]] - 書籍: [[Understanding Lustre Internals]] / [[wiki/entities/Lustre Operations Manual|Lustre Operations Manual]]