# 並列ファイルシステム 複数のストレージサーバにデータを分散配置し、多数のクライアントから同時にアクセスすることで、単一サーバでは達成できない帯域幅と容量を実現するファイルシステムの総称である。HPC(高性能計算)やエクサスケールシステムの I/O 基盤として不可欠であり、データとメタデータの分離、オブジェクトベースストレージ、分散ロック管理が共通の設計原則として定着している。 ## 定義 並列ファイルシステムとは、ネットワーク経由で接続された複数のサーバ・ストレージデバイスにファイルデータを**ストライピング**(分散配置)し、並列 I/O によってアグリゲートスループットを最大化する分散ファイルシステムである。POSIX 互換性を維持しつつ、数千〜数万のクライアントに一貫したファイルシステムイメージを提供する。主要な実装として [[Lustre]]、GPFS(IBM Spectrum Scale)、Ceph、BeeGFS、DAOS がある。(Source: [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]]) ## 設計上の共通原則 - **データとメタデータの分離**: ファイルの名前空間操作(メタデータ)とデータ I/O を異なるサーバ群に分離する。Lustre は MDS/OSS、GPFS はコントローラとデータノード、Ceph は MDS と OSD にそれぞれ分離する。 - **オブジェクトベースストレージ**: ファイルを固定サイズのオブジェクトに分割し、オブジェクト単位でストレージターゲットに配置する。ブロックデバイスを直接操作するのではなく、ストレージサーバがオブジェクトレベルの操作を公開する。 - **分散ロック管理**: 並行アクセスの一貫性を保つために分散ロックマネージャを用いる。Lustre の LDLM(バイト範囲ロック)、GPFS のトークンベースロック、DAOS のバージョン付きトランザクション制御など、設計アプローチは異なる。 - **ストライピングとレイアウト**: ファイルを複数のストレージターゲットにまたがって分散し、帯域幅を集約する。ストライプ数・チャンクサイズの粒度は実装により異なる。 ## 主要実装の比較 [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]] の 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 - Evolution, Design, Advancements, and Current Trends]]) ## 横断的知見 - **設計のルーツと現在の乖離**: 2001–2005 年の初期設計文書([[@2019__arXiv__The Lustre Storage Architecture]])では、メタデータライトバックキャッシュやクラスタ化 MDS(分散名前空間)が構想されていたが、一貫性保証の複雑さから実装が数十年遅れた。2025 年のサーベイ([[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]])でもクライアントメタデータライトバックキャッシュは「将来の方向性」として挙げられており、当初の設計意図の実現に 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)やクライアントメタデータキャッシュは、この変化への対応策である。 ## 未解決の問い - クライアントメタデータライトバックキャッシュ(100 倍の高速化見込み)が実用化されたとき、POSIX 一貫性保証との折り合いをどうつけるのか。特にマルチテナント環境での安全性は？ - DAOS のロックレストランザクションモデルは、Lustre のような LDLM ベースのシステムに対して、エクサスケール以降で構造的優位を持つのか。あるいは POSIX 互換性の欠如が普及の制約となるのか。 - ファイルレベル EC が Lustre に導入された場合、Ceph のレプリケーション既定モデルとの容量効率・性能のトレードオフはどう変化するか。 - LLM 訓練ワークロードのチェックポイント I/O パターン([[LLM分散学習]] 参照)は、並列ファイルシステムの設計にどのような変更を要求するか。[[FlashRecovery]] のチェックポイントフリー復旧のように、ファイルシステム層を迂回する動きとの関係は。 ## 関連 - ソース: [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]] / [[@2019__arXiv__The Lustre Storage Architecture]] - 既存 `papers/` 参照: [[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]] - 概念: [[LLM分散学習]] / [[チェックポイント]] / [[GPUクラスタ運用]] - MOC(一方向参照): [[HPC - MOC]] ## 出典 - [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]] - [[@2019__arXiv__The Lustre Storage Architecture]]