> [!abstract] > Lustre ファイルシステムは高性能並列ストレージの重要な構成要素であり、科学・研究・企業の各環境で増大する需要に応えている。AI/ML から石油・ガス、創薬、気象学、製造業に至るまで、HPC 環境に広く導入されており、膨大かつ増加し続けるデータへの効率的なアクセスという普遍的課題に取り組んでいる。Lustre は現在、世界最速のスパコン上位 10 中 6 台、上位 100 の 65%超、上位 500 の 60%超で選択されるファイルシステムである。その広範な普及にもかかわらず、Lustre の進化・設計・各種改良を網羅した最新かつ包括的なリファレンスは欠如している。本論文はこのギャップを埋めるべく、Lustre の歴史と HPC への重要な貢献、詳細なアーキテクチャと設計要素、進化の過程で加えられた改良、そして将来の方向性を含む包括的な行程を提供する。加えて、同時代の他の主要ストレージ技術との比較を行う。Lustre の現状を示すため、初のエクサスケールスパコン [[Frontier]] 上の Lustre ファイルシステム [[Orion]] における利用状況、性能、使用パターンなど複数のファイルシステム動向を分析する。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | Lustre Unveiled: Evolution, Design, Advancements, and Current Trends | | 著者 | [[Anjus George]], [[Andreas Dilger]], Michael J. Brim, Richard Mohr, Amir Shehata, Jong Youl Choi, Ahmad Maroof Karimi, Jesse Hanley, James Simmons, Dominic Manno, Veronica Melesse Vergara, [[Sarp Oral]], Christopher Zimmer | | 所属 | [[Oak Ridge National Laboratory]] NCCS, [[Whamcloud]]/[[DDN]], Los Alamos National Laboratory, ORNL 計算機科学・数学部門 | | 掲載誌 | ACM Transactions on Storage, Vol. 21, No. 3, Article 21 | | 出版日 | 2025 年 6 月 | | DOI | 10.1145/3736583 | | ライセンス | CC-BY-SA 4.0 | | 分量 | 109 ページ | ## 概要 25 年以上の開発史を持つオープンソース並列ファイルシステム [[Lustre]] について、アーキテクチャ・設計原則・主要機能・他システムとの比較・実運用実績・将来展望を一冊に凝縮した包括的サーベイである。約 750K 行のコードベースから成る Lustre の全貌を、教育的リファレンスとして体系化した初の試みである。 ## 問題設定 Lustre に関する既存の文献は断片的かつ古く、アーキテクチャ・設計・機能・歴史を統合的に扱った最新のリファレンスが存在しなかった。本論文はこのギャップを埋め、現世代と将来世代の双方に向けた包括的教育資源を提供することを目的とする。 ## 提案手法 本論文は記述的研究アプローチを採り、Lustre の現在の姿と設計目標の達成方法に焦点を当てる。 ### アーキテクチャ概要 Lustre は分散オブジェクトベースのストレージフレームワーク上に構築される。主要コンポーネントは以下のとおりである。 - **MGS（マネジメントサーバ）**: ファイルシステムの構成データとレジストリを管理する。MGT 上に永続的な構成情報を保存し、クライアントとサーバに提供する。 - **MDS（メタデータサーバ）**: 名前空間とメタデータサービスを提供する。ディレクトリ階層、ファイル属性、アクセス権限を管理する。 - **OSS（オブジェクトストレージサーバ）**: ファイルデータオブジェクトを管理し、クライアントのアクセスを仲介する。 - **MDT（メタデータターゲット）**: MDS がメタデータを格納する論理ストレージターゲット。各ファイルの inode はレイアウト拡張属性を通じて OST オブジェクトを参照する。 - **OST（オブジェクトストレージターゲット）**: ファイル内容を格納する論理ストレージターゲット。一つのファイルは複数の OST オブジェクトにストライピングされる。 - **LNet**: RDMA 対応の高性能ネットワーク抽象化レイヤー。InfiniBand、Ethernet、OmniPath、HPE Slingshot 等を透過的に扱う。 - **LDLM（分散ロックマネージャ）**: 共有リソースへの整合的アクセスを管理する。6 種のロックモード（EX/PW/PR/CW/CR/NL）と 4 種のロックタイプ（エクステント/inode ビット/flock/プレーン）を持つ。 - **FID（ファイル識別子）**: 128 ビットのグローバル一意識別子。64 ビットシーケンス番号、32 ビットオブジェクト ID、32 ビットバージョンから構成され、分散的に生成可能である。 ### 設計原則 Lustre の設計は 5 つの原則に基づく: **スケーラビリティ**、**パフォーマンス**、**レジリエンス**、**ユーザビリティ**、**互換性**。これらの原則から以下の主要機能が導かれている。 - **データ・メタデータ分離**: MDS は高 IOPS ストレージ上で CPU/RAM 集約的なメタデータ操作を、OSS は高帯域ストレージ上でファイル I/O を処理する。各サービスを独立にスケール可能にしている。 - **オブジェクトベース設計**: ファイルデータを 1 つ以上の OST オブジェクトに分散し、低レベルのブロック割り当てを各 OSS に委譲する。中央の競合点を排除し、並列 I/O を実現する。 - **データレイアウト（ストライピング）**: RAID-0 方式でファイルデータを複数 OST に分散する。ストライプカウントとストライプサイズをファイル単位で設定可能であり、Progressive File Layout（PFL）によりファイルサイズに応じた段階的レイアウトも実現する。 - **分散名前空間（DNE）**: 名前空間をディレクトリレベルで複数の MDT に分散する。単一ディレクトリを複数 MDT にストライピングすることも可能であり、数百億のファイルを管理できる。 - **POSIX 準拠**: ローカル ext4 と同等の POSIX ユニットテストに合格する完全準拠を達成している。アクセスタイム更新に関するわずかな例外のみ存在する。 - **フェイルオーバー**: サーバ障害時に待機サーバへ透過的にサービスを移行する。MDS/OSS 双方で対応し、アプリケーションからは中断が見えない設計である。 - **クライアントキャッシュ**: 頻繁にアクセスされるデータとメタデータをクライアント RAM に保持する。書き込みにはライトバックキャッシュを使用し、複数の小規模書き込みを集約してネットワーク転送を効率化する。 ### ソフトウェアスタック クライアント側では、アプリケーションの I/O システムコールが Linux VFS を通じて Lustre `llite` カーネルモジュールに渡され、メタデータ要求は Logical Metadata Volume（LMV）→ Metadata Client（MDC）→ PtlRPC → LNet の経路で MDS に到達する。データ要求は Logical Object Volume（LOV）→ Object Storage Client（OSC）→ PtlRPC → LNet の経路で OSS に到達する。書き込みデータの実転送はサーバ側が RDMA で開始する設計であり、OSS のメモリとネットワーク帯域の過負荷を防ぐ。 ## 新規性 - Lustre のアーキテクチャ・設計・機能を**単一の論文に統合**した初の包括的リファレンスである。 - 現行実装の最新状態を反映し、将来の開発計画も詳述している。 - 機能をその設計動機（スケーラビリティ/パフォーマンス/レジリエンス/ユーザビリティ）で分類し体系化した。 - 初のエクサスケール Lustre ファイルシステムの実アーキテクチャと性能データを公開した。 ## 設計進化の主要機能（第 5 章） 第 5 章ではスケーラビリティ/パフォーマンス、レジリエンス/可用性、ユーザビリティ/管理性、セキュリティの 4 軸に沿った機能進化を記述している。 - **キャッシュ機構**: メタデータキャッシュ（ルックアップ/属性/レイアウト）、データページキャッシュ、ステートアヘッド（先行ロック取得）、リードアヘッド（先行データフェッチ）が協調動作し、ネットワーク RPC 数を削減する。 - **LNet マルチレール**: 1 ノードに複数の NIC を構成し、帯域を集約する。ピア間のトラフィック分散と NIC 障害時のフェイルオーバーを提供する。 - **DNE（分散名前空間環境）**: DNE1（リモートディレクトリ: MDT 間のディレクトリ分散）と DNE2（ストライプディレクトリ: 単一ディレクトリの複数 MDT ストライピング）の 2 段階で導入された。 - **FLR（ファイルレベル冗長性）**: Lustre 2.10 以降、ファイルデータを複数 OST にミラーリングして OST 障害時のデータ可用性を確保する。ミラーは選択的に適用可能であり、全ファイルへの一律適用は不要である。 - **Persistent Client Cache（PCC）**: クライアントのローカル NVMe/SSD を Lustre キャッシュとして利用し、繰り返しアクセスされるデータを高速化する。読み書き双方に対応する。 - **Data on MDT（DoM）**: 小ファイルのデータを MDT 上に直接格納し、OST への RPC を不要にする。メタデータティアの高 IOPS を活用して小ファイル性能を大幅に改善する。 ## 比較対象 第 4 章で Lustre を GPFS、BeeGFS、DAOS、Ceph と高レベルで比較している。主な知見は以下のとおりである。 - **データ・メタデータ分離**: Lustre、Ceph、BeeGFS はメタデータとデータを別サーバで処理する。GPFS と DAOS はメタデータとデータを等価に扱い、クラスタ全体に分散する。 - **データストライピング**: Lustre と BeeGFS はユーザによるファイル単位のストライプ設定をサポートする。GPFS のストライピングは静的な全体構成である。Lustre は PFL や SEL などより高度なレイアウトを提供する点で優位である。 - **データ冗長性**: Ceph はデフォルトでオブジェクト複製を行う唯一のシステムである。GPFS は GNR でソフトウェアベースの冗長性を提供する。DAOS はオブジェクト単位のレプリケーションとイレイジャーコーディング（EC）を双方サポートする。Lustre は FLR によるファイルミラーリングをサポートするが、ネイティブ EC は開発中である。 - **一貫性モデル**: 全システムが POSIX セマンティクスに準拠するが、各システムは性能向上のための緩和モードも提供する。DAOS はエポックベースの楽観的並行性制御を用いる独自のアプローチを採る。 - **アーキテクチャ的類似性**: BeeGFS が最も Lustre に近いが、フェイルオーバー機構（Lustre は共有ストレージ、BeeGFS はバディミラーリング）とストライピング機能（Lustre がより高度）で差異がある。Ceph はレジリエンスと弾力性を、DAOS は NVM 最適化のパフォーマンスを最重視する設計思想で Lustre と異なる。 ## Frontier/Orion の実績 [[Frontier]] は ORNL の初のエクサスケールスパコンであり、9,472 台の計算ノード（AMD EPYC 7A53 + MI250X GPU ×4）を擁する。その Lustre ファイルシステム [[Orion]] は 3 層のマルチティアアーキテクチャを採る。 ### ストレージ構成 | ティア | 容量 | 読み出し帯域 | 書き込み帯域 | 媒体 | |---|---|---|---|---| | メタデータ | 10.0 PB | 0.8 TB/s | 0.4 TB/s | NVMe（KIOXIA 30 TB）| | パフォーマンス | 11.5 PB | 10.0 TB/s | 10.0 TB/s | NVMe（Samsung 3.2 TB）| | キャパシティ | 679.0 PB | 5.5 TB/s | 4.6 TB/s | HDD（Seagate PMR 18 TB）| 合計容量は約 700 PB。40 台の MDS/MDT、450 台の OSS（NVMe OST 450 基 + HDD OST 900 基）、169 台の LNet ルータ、2 台の MGS から構成される。バックエンドファイルシステムは ZFS v2.1.7 で、dRAID-2 構成を採用している。 ### 性能実績 - **PFS レベル逐次 I/O**: 書き込みピーク **4.6 TiB/s**（512 KiB リクエスト時）、読み出しピーク **4.7 TiB/s**（32 MiB リクエスト時）。 - **パフォーマンスティア逐次読み出し**: ピーク 12.4 TiB/s（32 MiB リクエスト時）。 - **ランダム I/O**: 読み出しピーク 3.9 TiB/s、書き込みピーク 1.7 TiB/s（16 MiB リクエスト時）。 - **メタデータ性能**（単一 MDT）: ファイル作成 95.3K ops/s、ファイルルックアップ 200K+ ops/s、getattr 211K ops/s。40 MDT 全体では作成・削除が 100K ops/s 超、stat が 500K ops/s 超に達する。 ### ファイルシステム構成（2024 年 3 月時点） - ファイル数: 約 29.7 億、ディレクトリ数: 約 1.02 億、シンボリックリンク: 約 1,611 万 - 集計ファイルサイズ: 193.65 PiB（容量利用率 31.12%） - 平均ファイルサイズ: 69.95 MiB - デフォルト PFL により 70%のファイルが DoM レイヤー（MDT 上の最初の 256 KiB）に収まり、18%がパフォーマンスティアに、12%がキャパシティティアに到達する。 ### Darshan による I/O パターン分析（2023 年 10〜12 月） 3 ヶ月間で累積書き込み約 10 PB、累積読み出し約 1 PB。書き込み操作は約 10^13 回に達する。全体的に書き込み優位のワークロードであり、チェックポインティングの影響が大きい。科学領域別の利用では物理学が最大（40 PiB 超、全体の 22.63%）、次いで流体力学（22.46 PiB）、天体物理学（18.99 PiB）が続く。ファイルサイズ分布では 4 KiB 以下が約 30%（約 8.83 億ファイル）を占めるが、容量ベースでは 16 GiB バケットが全体の 73%を消費するという逆転構造が見られる。大規模ニューラルネットワークモデルの普及に伴い、チェックポインティングが必須となり書き込み操作が増加傾向にある。 ## 将来の方向性 ### 1. クライアントメタデータライトバックキャッシュ（WBC） クライアントがメタデータ更新（ファイル/ディレクトリ作成・削除・属性変更）をローカルメモリで実行し、MDS への RPC を遅延させる機能である。排他的 LDLM ロックによりディレクトリツリー内のローカル操作を保護する。初期評価では一般的なメタデータ操作で **100 倍以上の高速化**を示し、ローカル RAM ベースファイルシステムに匹敵する性能を達成している。Lustre 2.16 ではバッチ RPC 操作が導入され、WBC のキャッシュフラッシュを効率化する基盤が整備された。 ### 2. クライアントサイドデータ圧縮（CSDC） gzip、lz4、lzo 等のカーネル内圧縮アルゴリズムを用い、ファイル/ディレクトリ/コンポーネント単位で圧縮を適用できる。64 KiB〜4 MiB の固定サイズチャンク単位で独立に圧縮・展開可能であり、並列書き込み時のオーバーヘッドを最小化する。 ### 3. ファイルレベル冗長性 — イレイジャーコーディング（FLR EC） K 個のデータストライプに R 個の冗長ストライプを付加し、任意の R ストライプ喪失に耐える。K=8, R=2 で 25%のオーバーヘッドでの RAID-6 相当の冗長性を実現する（トリプルミラーリングの 200%に対して大幅削減）。大きなストライプカウントのファイルでは EC サブグループに分割可能である。 ### 4. MDT プール OST プールと同様に MDT をグループ化し、サブディレクトリやファイルの作成先を特定の MDT 群に指定する。データローカリティ、負荷分離、DNE リカバリ時の MDT 間依存の低減が期待される。 ### 5. Lustre メタデータ冗長性（LMR） MGS、FLDB、クォータデータベース、ROOT ディレクトリを複数の MDT にレプリケーションし、MDT0000 の単一障害点を排除する一連のプロジェクトである。ディレクトリツリー単位の構成可能なレプリケーションも計画されている。 ## 歴史的コンテキスト - **1990 年代後半**: カーネギーメロン大学の Peter J. Braam が研究プロジェクトとして開始。AFS、Coda、InterMezzo、GPFS 等から着想を得た。 - **2003 年 3 月**: LLNL の MCR クラスタ（Top500 第 3 位）で初の本番運用。1,152 計算ノード、2 MDS、64 OST。 - **2003 年 12 月**: Lustre 1.0 リリース。上位 5 スパコン中 4 台に導入、11.1 GB/s のスループットを達成。 - **2006 年**: 世界上位 30 スパコンの 10 台で採用。InfiniBand RDMA サポート等が導入された。 - **2007 年**: Sun Microsystems が CFS を買収。HPC セクターの上位 10 中 7 台で支配的地位を確立。 - **2009 年**: Oracle による Sun 買収後、[[Whamcloud]] と [[OpenSFS]] が設立され、オープンソース開発の継続が確保された。 - **2012 年**: Intel が Whamcloud を買収。Lustre 2.x 系列の主要機能（ZFS サポート、DNE 等）が開発された。 - **2018 年**: [[DDN]] が Intel の Lustre 事業を買収。現在に至るまで商用開発を主導している。 - **2023 年**: [[Frontier]] が ORNL で本番運用を開始。700 PB の [[Orion]] ファイルシステムがエクサスケールの I/O 課題に対応。 ## 強み / 弱点・課題 ### 強み - HPC 並列ファイルシステムに関する**最も包括的かつ最新の単一リファレンス**であり、25 年の歴史を体系的に整理している。 - 初のエクサスケール Lustre ファイルシステムの実運用データを詳細に公開しており、再現性と教育的価値が高い。 - 設計原則に基づく機能分類により、Lustre の設計思想を構造的に理解可能にしている。 - 他システム（GPFS/BeeGFS/DAOS/Ceph）との比較が公平かつ明確で、各システムの設計重点の違いが整理されている。 - CC-BY-SA 4.0 ライセンスで公開されており、教育・研究用途での二次利用が容易である。 ### 弱点・課題 - 比較はハイレベルに留まり、定量的なベンチマーク比較は範囲外と明示されている。各システムの性能データの直接対比はない。 - 109 ページの大部であるが、コード内部の実装詳細には踏み込んでいない（意図的な範囲外設定）。 - Orion の性能評価は特定の構成・条件下でのものであり、汎用的な性能保証として一般化するには注意が必要である。SSU レベルの性能測定は時間的制約から代表的な SSU のみで実施されている。 - 将来機能（WBC、CSDC、FLR EC 等）は開発中または計画段階のものが含まれ、実運用への投入時期は不明確である。 - Lustre の弱点として、ネイティブのオブジェクト/ファイルレベル EC がまだ本番投入されていない点、メタデータの冗長性が MDT フェイルオーバーに限定されている点が比較表から読み取れる。 ## 関連 - エンティティ: [[Anjus George]] / [[Andreas Dilger]] / [[Sarp Oral]] / [[Lustre]] / [[Frontier]] / [[Orion]] / [[DDN]] / [[Whamcloud]] / [[OpenSFS]] / [[Oak Ridge National Laboratory]]