# 並列ファイルシステム 複数のストレージサーバにデータを分散配置し、多数のクライアントから同時にアクセスすることで、単一サーバでは達成できない帯域幅と容量を実現するファイルシステムの総称である。HPC(高性能計算)やエクサスケールシステムの I/O 基盤として不可欠であり、データとメタデータの分離、オブジェクトベースストレージ、分散ロック管理が共通の設計原則として定着している。 ## 定義 並列ファイルシステムとは、ネットワーク経由で接続された複数のサーバ・ストレージデバイスにファイルデータを**ストライピング**(分散配置)し、並列 I/O によってアグリゲートスループットを最大化する分散ファイルシステムである。POSIX 互換性を維持しつつ、数千〜数万のクライアントに一貫したファイルシステムイメージを提供する。主要な実装として [[Lustre]]、GPFS(IBM Spectrum Scale)、Ceph、BeeGFS、DAOS がある。(Source: [[@2025__TOS__Lustre Unveiled - Chapter 2 The Lustre Filesystem]]) ## 設計上の共通原則 - **データとメタデータの分離**: ファイルの名前空間操作(メタデータ)とデータ I/O を異なるサーバ群に分離する。Lustre は MDS/OSS、GPFS はコントローラとデータノード、Ceph は MDS と OSD にそれぞれ分離する。 - **オブジェクトベースストレージ**: ファイルを固定サイズのオブジェクトに分割し、オブジェクト単位でストレージターゲットに配置する。ブロックデバイスを直接操作するのではなく、ストレージサーバがオブジェクトレベルの操作を公開する。 - **分散ロック管理**: 並行アクセスの一貫性を保つために分散ロックマネージャを用いる。Lustre の LDLM(バイト範囲ロック)、GPFS のトークンベースロック、DAOS のバージョン付きトランザクション制御など、設計アプローチは異なる。 - **ストライピングとレイアウト**: ファイルを複数のストレージターゲットにまたがって分散し、帯域幅を集約する。ストライプ数・チャンクサイズの粒度は実装により異なる。 ## 主要実装の比較 [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]] の Table 4–5 に基づく高水準比較: | 特性 | Lustre | GPFS | Ceph | BeeGFS | DAOS | |---|---|---|---|---|---| | データ/メタデータ分離 | MDS + OSS | 統合(ロール区別あり) | MDS + OSD | 分離 | 統合 | | ストライピング | ファイル単位で可変(PFL 含む) | 静的・FS 全体一律 | プール/名前空間単位 | ファイル単位 | オブジェクトクラス単位 | | 冗長化 | RAID + FLR(ファイル複製) | GNR(EC + レプリケーション) | レプリケーション既定 + EC | バディミラーリング | レプリケーション + EC | | 一貫性モデル | POSIX(緩和モード有) | POSIX 強一貫性 | POSIX(lazy I/O 有) | POSIX | バージョン付きトランザクション | | ロック方式 | LDLM(バイト範囲) | トークンベース | MDS 管理分散ロック | MDS 管理 | ロックレス(エポック制御) | ## エクサスケール時代の実績 Top500 上位 10 中 6 台、上位 100 の 65% 以上、上位 500 の 60% 以上が Lustre を採用している。米国初のエクサスケールスパコン [[Frontier]] の [[Orion]] ファイルシステムは、700 PB の容量で逐次書き込み 4.6 TiB/s・逐次読み出し 4.7 TiB/s を達成した。40 の MDT による分散メタデータ処理と、フラッシュ・HDD の多層ストレージ構成を採用している。(Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]]) ## 横断的知見 - **[設計上の共通原則] 並列 I/O の結合度を下げることが、共有本番環境の不均一性への実用的な対応になる**: Titan の測定では、ストライピングやファイル共有のように複数クライアントの完了を結合する構成が、ストラグラーや範囲ロックの影響を受けた。独立ファイルへ負荷を分散し、各クライアントが複数 OST を使う構成は、結合度を下げつつファンアウトを確保する。(Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]], [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]]) - **設計のルーツと現在の乖離**: 2001–2005 年の初期設計文書([[@2019__arXiv__The Lustre Storage Architecture]])では、メタデータライトバックキャッシュやクラスタ化 MDS(分散名前空間)が構想されていたが、一貫性保証の複雑さから実装が数十年遅れた。2025 年のサーベイ([[@2025__TOS__Lustre Unveiled - Chapter 7 Future Directions and Open Challenges in Lustre]])でもクライアントメタデータライトバックキャッシュは「将来の方向性」として挙げられており、当初の設計意図の実現に 20 年以上を要している。 - **POSIX の重荷と脱却の試み**: Lustre・GPFS・Ceph・BeeGFS はいずれも POSIX 一貫性をデフォルトとしつつ、性能のために緩和モードを提供する。DAOS のみがロックレスのエポック制御を採用し、従来のロックベースモデルから脱却している。POSIX 互換性は既存アプリケーションとの互換性を保つが、エクサスケールではオーバーヘッドの主因ともなる。 - **冗長化設計の分岐**: Lustre はブロック RAID に依存し、ファイルレベル冗長化(FLR)は限定的である。Ceph はレプリケーションをデフォルトとし、DAOS はオブジェクト単位でレプリケーションと EC を選択可能である。ファイルレベル EC はまだ Lustre では開発中であり、この分岐が今後のストレージ効率の競争力を左右する。 - **AI/HPC の融合がワークロード特性を変える**: 従来の HPC ワークロード(大規模逐次 I/O)から、AI/ML ワークロード(大量の小ファイルランダムアクセス、チェックポイント I/O)への移行が進み、並列ファイルシステムのメタデータ性能がボトルネックとなっている。Lustre の分散名前空間(DNE)やクライアントメタデータキャッシュは、この変化への対応策である。 - **クライアント側キャッシュは「将来の方向性」ではなく既に実装・評価済み**: [[@2025__TOS__Lustre Unveiled - Chapter 7 Future Directions and Open Challenges in Lustre]] はクライアントメタデータライトバックキャッシュを「将来の方向性」として挙げるが、[[@2021__TOS__NVMM-Oriented Hierarchical Persistent Client Caching for Lustre]](2021年発表)は既に**データ**面でのクライアント側永続キャッシュ([[永続クライアントキャッシュ]]、NVMM-LPCC)をLustreのHSM機構とレイアウトロックの上に実装し、ネイティブLustre比で読み取りスループット最大35.80倍を実証している。メタデータキャッシュとデータキャッシュは別軸の課題だが、後者が既に本番指向の実装まで到達している事実は、Lustreのアーキテクチャ拡張性(サーバ側コンポーネントを変更せずクライアント層のみで機能追加できる設計)を裏付ける。 - **初期設計の焦点は現在の主要原則に連続している**: 2003年の資料([[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]])は、1,000ノード規模の同時メタデータ更新に対して分散ロック管理とオブジェクトプロトコルを選び、2025年のサーベイ([[@2025__TOS__Lustre Unveiled - Chapter 5 Lustre Design Evolution]])が整理するデータ・メタデータ分離、オブジェクトベース設計、分散ロック管理へつながる初期の設計判断を示している。 - **高水準の機能比較は、実測が示す非対称性を映さない**: 第 4 章の比較表は 5 システムの機能有無を対等に並べるが、第 6 章の [[Orion]] 実測は、同じ「サポートあり」の中に大きな差があることを示す。データ帯域は OST 台数でほぼ線形に伸びる一方、メタデータは MDT を 40 台並べても単一 MDT の処理能力(ファイル作成 95.3K ops/s 級)が総量の構成要素として残る。機能表の粒度では、スケールする軸としない軸の区別が付かない。(Source: [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]], [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]]) - **メタデータ性能の追求は独立した主題に育っている**: 名前空間の水平分割・クライアント側キャッシュ・ロック粒度制御という 3 層の手法群は、いずれも並列ファイルシステム一般の課題でありながら、扱う時間尺度も効果の桁も異なる。詳細は [[メタデータスケーリング]] に分離した。 - **比較表の「PFL含む」という 1 行が、実際には 3 段階の合成レイアウト機構を圧縮している**: [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]] の比較表はストライピング列を「ファイル単位で可変(PFL 含む)」と 1 行で記す一方、実装解説である [[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]] は PFL(区間ごとの Normal レイアウト配列)→ DoM(先頭コンポーネントを MDT 上に配置)→ SEL(extent 到達時に OST 空き容量を見て動的に短縮・再配置)という 3 段階の拡張系列と、それらとは独立した FLR(ミラー単位の複製)を区別する。高水準の機能比較は、同じ「対応あり」の中に実装の成熟度・複雑さの差があることを覆い隠す。DNE の水平分割(名前空間側のスケーリング)と PFL/DoM/SEL(データ配置側のスケーリング)は独立した軸だが、いずれも「レイアウトを段階的・条件的に変化させる」という設計原則を共有している。(Source: [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]], [[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]]) - **DNE の段階的拡張は、2003 年の設計課題を 20 年がかりで解いた実例である**: 2003 年資料([[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]])は 1,000 ノード規模での分散ロック管理とオブジェクトプロトコルの設計経験を示すが、メタデータの水平分割そのものには踏み込んでいない。2021 年の実装解説([[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]])が示す DNE Phase 1(静的な Remote Directories)→ Phase 2(ハッシュベースの Striped Directories)→ Phase 3 構想(動的な auto-striped directories)という段階は、単一 MDT 上に集中していたメタデータ処理を複数 MDT へ分散する試みであり、[[並列ファイルシステム]] 冒頭の「設計のルーツと現在の乖離」で述べたクラスタ化 MDS 構想の 20 年越しの部分的実現として位置づけられる。 - **[定義] FID の構造は、公式運用文書と独立の技術解説の双方で一致する**: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]] が記す FID(64 ビット SEQ + 32 ビット OID + 32 ビットバージョンからなる 128 ビット識別子。ファイルシステム内の全ターゲットを横断して一意)は、[[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]] の FID・layout EA 解説と整合する。運用者向けマニュアルと独立の技術解説書が同一の識別子設計を記述しており、この部分の仕様が長期にわたり安定していることを示す。(Source: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]], [[@2021__ORNL__Understanding Lustre Internals - Chapter 1 Lustre Architecture]]) - **[冗長化設計の分岐] 運用マニュアルは、ソフトウェアレプリケーション欠如という適用境界を明言する**: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]] は、クライアントとサーバが同一ノードで小容量ストレージを共有する P2P 的な用途に Lustre が不向きな理由を「Lustre ソフトウェア層でのデータレプリケーションの欠如」と明言し、ノード障害時はそのノードの復旧までデータにアクセスできないと述べる。これは [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]] が指摘する「Lustre はブロック RAID に依存し、ファイルレベル冗長化(FLR)は限定的」という設計上の分岐(Ceph のレプリケーション既定・DAOS のオブジェクト単位選択と対照的)の理由を、運用者向けドキュメント側から補強する。(Source: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 1 Understanding Lustre Architecture]], [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]]) - **[設計上の共通原則] サーバ側 RPC スケジューリングがストレージ帯域制御とネットワーク整流の境界を担う**: 並列ファイルシステムではクライアントがアウトオブバンドで直接 OSS と RDMA 通信を行うため、ネットワークスイッチ層ではなくサーバ側 RPC レイヤ（Lustre の NRS TBF 等）で要求をキューイング・整流することが、バックエンドディスク負荷のみならずネットワーク帯域消費を直接調停する実効手段となる。さらにストライピングによって I/O が複数サーバに分散するため、局所的なレート制限とクラスタ規模の大域レート調整（GRL）の連携が不可欠である。(Source: [[@2017__SC__A Configurable Rule based Classful Token Bucket Filter Network Request Scheduler for the Lustre File System]]) - **[設計上の共通原則] 既定のラウンドロビン配置の限界と大域的テレメトリ駆動最適化**: 並列ファイルシステム（Lustre）におけるファイル作成時のオブジェクト配置は伝統的にラウンドロビン（空き容量閾値によるローテーション）に頼ってきたが、バースト的な科学計算 I/O やマルチアプリケーション並行下では OST 間や OSS CPU 負荷に極端な不均衡（最大/平均比 75〜125 倍）を招き、均衡収束に十数時間を要する。MDS 上で監視テレメトリ（ODDMON）と将来要求予測（マルコフ連鎖）を組み合わせ、最小費用最大流（MCMF）問題として大域配置を解くことで、動的マイグレーションを伴わずに不均衡収束時間を 7 時間に短縮し、最大 54.5% の帯域向上を達成できる。これは NRS などの受信側 RPC スケジューリング（ネットワーク層の局所調停）と、配置決定層（大域的ストレージ割り当て）が補完関係にあることを示している。(Source: [[@2017__IEEE BigData__I O Load Balancing for Big Data HPC Applications]], [[@2017__SC__A Configurable Rule based Classful Token Bucket Filter Network Request Scheduler for the Lustre File System]]) - **[ワークロード適性とトレードオフ] AI 研究ワークロードにおける並列ファイルシステムとフラッシュ NAS の非対称性**: 並列ファイルシステム（Lustre）は大容量シーケンシャル書き込み（単一ファイル DDP チェックポイント保存で NAS 比 9〜35% 高速）や分散保存（FSDP save）で優れたスループットを示す一方、単一ディレクトリ内の大量小ファイル読み込みではメタデータボトルネックからオールフラッシュ NAS（NFS）比で 3 倍以上遅延し、ディレクトリ走査（`list_files`）では最大 80 倍遅延する。小ファイルを複数ディレクトリへシャーディングすることでこのボトルネックは大幅に緩和されるが、多数の小ファイルや頻繁な探索を伴う対話型 AI 研究環境では、純粋なスループット志向の並列ファイルシステム単体では満たせない領域が存在し、メタデータ性能に優れた NAS との役割分担がクラスタ設計上の重要判断となる。(Source: [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]]) ## 未解決の問い - 並列ファイルシステムのストライピング環境において、中央集権的コントローラ（GRL）に依存せず各 OSS が完全自律的に大域公平性を収束させる分散スケジューリングは実現可能か。 - ファイル作成時の大域的初期配置最適化（MCMF 等）と、事後的なサーバ側 RPC レートシェーピング（NRS TBF）を密に協調させた場合、負荷不均衡の発生そのものをどの程度事前に抑止できるか。 - 共有ファイルやストライピングの結合度を下げる設計は、ファイル数増加によるメタデータ負荷と、I/O 帯域の改善をどの条件で両立できるか。 - クライアントメタデータライトバックキャッシュ(100 倍の高速化見込み)が実用化されたとき、POSIX 一貫性保証との折り合いをどうつけるのか。特にマルチテナント環境での安全性は？NVMM-LPCC([[永続クライアントキャッシュ]])のデータキャッシュにおける一貫性制御(HSM+レイアウトロック)は、メタデータキャッシュの設計に転用可能か。 - DAOS のロックレストランザクションモデルは、Lustre のような LDLM ベースのシステムに対して、エクサスケール以降で構造的優位を持つのか。あるいは POSIX 互換性の欠如が普及の制約となるのか。 - ファイルレベル EC が Lustre に導入された場合、Ceph のレプリケーション既定モデルとの容量効率・性能のトレードオフはどう変化するか。 - LLM 訓練ワークロードのチェックポイント I/O パターン([[LLM分散学習]] 参照)は、並列ファイルシステムの設計にどのような変更を要求するか。[[FlashRecovery]] のチェックポイントフリー復旧のように、ファイルシステム層を迂回する動きとの関係は。 - 2003年に試みられた意図ロックからraw操作への整理は、現行LustreのLDLM・DNE・クライアントキャッシュへどのように引き継がれたのか。 - DNE Phase 3(auto-striped directories)が実現した場合、ストライプカウントの動的増加は SEL のコンポーネント動的短縮・再配置と同様に LDLM のロック粒度へ波及するのか。名前空間側とデータ側で「動的な再配置」という同じ設計原則が独立に発展している状況を、単一の設計原理として統合できるか。 - 運用マニュアルが明記する単一ファイルの最大ストライプ数 2000(`ea_inode` 無効時の ldiskfs では 160 OST)という上限は、実装上のハード制約か運用上の推奨値か。2000 OST を超える規模のファイルシステムで複数ファイルへ I/O を分散させる運用上の回避策は、DNE の水平分割やクライアント側キャッシュの設計判断とどう関係するか。 - AI 研究クラスタにおいて、大容量書き込みに強い並列ファイルシステムとメタデータ・読み込みに強いフラッシュ NAS をハイブリッド運用する場合、データ同期の整合性コストを最小化する階層ストレージ管理手法は存在するか。 ## 関連 - ソース: [[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]] / [[Lustre Unveiled]] / [[@2019__arXiv__The Lustre Storage Architecture]] / [[@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]] / [[@2017__SC__A Configurable Rule based Classful Token Bucket Filter Network Request Scheduler for the Lustre File System]] - 既存 `papers/` 参照: [[@2019__arXiv__The Lustre Storage Architecture|2019__arXiv__The Lustre Storage Architecture]] / [[2025__TOS__Lustre Unveiled Evolution Design Advancements and Current Trends]] / [[2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3 - Compatible Object Storage]] - エンティティ: [[Lustre]] / [[Frontier]] / [[Orion]] / [[Oak Ridge National Laboratory]] / [[OpenSFS]] / [[DDN]] - 概念: [[メタデータスケーリング]] / [[LLM分散学習]] / [[チェックポイント]] / [[GPUクラスタ運用]] / [[永続クライアントキャッシュ]] / [[分散ロック管理]] / [[意図ロック]] / [[オブジェクトベースストレージ]] / [[ストレージQoS]] - MOC(一方向参照): [[HPC - MOC]] ## 出典 - [[Lustre Unveiled]] - [[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]] - [[@2019__arXiv__The Lustre Storage Architecture]] - [[@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]] - [[@2017__SC__A Configurable Rule based Classful Token Bucket Filter Network Request Scheduler for the Lustre File System]] - [[@2017__IEEE BigData__I O Load Balancing for Big Data HPC Applications]] - [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]]