# Lustre Unveiled - Chapter 5: Lustre Design Evolution > 前: [[@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]] | 全体: [[Lustre Unveiled]] ## 要約 本章は、本書で最長(38 ページ)の中核章であり、Lustre がコア設計原則を維持しながらワークロードとストレージ技術の変化に適応してきた過程を、4 つの設計目標軸に沿って整理する(§5)。第 3 章がアーキテクチャの静的な構成要素(LNet・LDLM・DNE 等)を説明したのに対し、本章は同じ構成要素を**進化の観点**、すなわち「何がいつ・なぜ追加されたか」から再度扱う。将来機能(WBC・CSDC・FLR の EC フェーズ等)は第 7 章の担当であり、本章は既に実装済みの進化のみを扱う。 ## 分類軸(4 つの設計目標) - **Scalability and Performance(§5.1)**: キャッシュ、LNet によるデータ転送効率、LDLM のロック管理、DNE によるメタデータ分散、OSS/MDS の弾力性など、大規模化と高性能化を支える機能群。 - **Resilience and Availability(§5.2)**: RAID によるハードウェア冗長化、フェイルオーバー、トランザクションリプレイ、LFSCK による整合性検査など、障害時にもサービスを継続する機能群。 - **Usability and Manageability(§5.3)**: 監視・HSM 連携・OST プール・プロジェクトクォータ・PFL・OSD 層・動的 LNet 設定など、運用者と利用者の利便性を高める機能群。 - **Security(§5.4)**: UID/GID による分離から ACL・サブディレクトリマウント分離・クライアント側暗号化・Kerberos・nodemap まで、データ保護とマルチテナント対応の機能群。 ## Scalability and Performance(§5.1) ### キャッシュ機構(§5.1.1) クライアント・サーバ双方の Linux ページキャッシュを使ってレイテンシ削減とスループット向上を図る多層キャッシュである。 - **クライアントデータキャッシュ**: LDLM エクステントロックで一貫性を保ちつつ、ライトバックキャッシュ方式でクライアント RAM に書き込みを一時保持し、フル RPC 分たまるかロック解放時に非同期で OSS へ書き戻す。読み取りはリードアヘッドで先読みする。 - **クライアントメタデータキャッシュ**: LDLM ibits ロックでコヒーレンシを管理する。更新操作では MDS がクライアントに代わって変更を行い、完了後に読み取りロックを返す方式を取る(メタデータライトバックキャッシュ導入までの暫定形。第 7 章参照)。 - **サーバデータキャッシュ**: write-through 方式で OSS ページキャッシュと OST に同時書き込みし、障害時のデータ安全性を確保する。8 MiB 未満かつ HDD 向けではページキャッシュを使い、大きい要求や NVMe では RDMA でキャッシュを迂回する。 - **サーバメタデータライトバックキャッシュ**: メタデータ変更をトランザクションとして MDS ページキャッシュに集約し、まとめてコミットすることで同期書き込みを減らす。クラッシュ時はリプレイ/リカバリで一貫状態に復元する。 - **Persistent Client Cache(PCC)**: クライアントローカルの NVMe 等の永続ストレージを活用し、機械学習のような反復アクセスワークロードでネットワーク負荷を削減する。バージョン番号でキャッシュの新鮮さを検証する。PCC-RW(単一クライアント向け読み書き)と PCC-RO(複数クライアント共有の読み取り専用)の 2 モードを持つ。 ### LNet によるデータ転送効率化(§5.1.2) LNet は RDMA の PUT/GET 操作を send/receive API に抽象化し、下位の LND 層へ橋渡しする。PUT はクライアントからサーバへのデータ送信、GET はサーバがクライアントからデータを引き出す際に使う。LNet ルータはルーティングテーブルとバッファをあらかじめ確保し、クォータベースの信用枠(クレジット)でホストごとのバッファ消費を制限し、輻輳を防ぐ。 ### LNet Multi-Rail(§5.1.3) 大規模計算機(SGI UV・NVIDIA DGX 等)で複数ネットワークインターフェース(NI)を活用するために導入された機能である。従来は複数 LNet ネットワークや仮想インターフェースを個別設定する必要があったが、Multi-Rail(MR)は 1 台のホストに複数 NI を同一ネットワークへ束ねて設定を簡素化し、帯域集約と経路多重化による耐障害性を両立する。単一ネットワーク構成(複数 NI を 1 つの LNet ネットワークに接続)と複数ネットワーク構成(異種ネットワークを同一ピアへ接続し、ポリシーに応じて NID を選択)の 2 用途をサポートする。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig12-lnet-multi-rail.png]] (図12. LNet Multi-Rail の 2 用途: (a) 単一ネットワーク、(b) 複数ネットワーク。§5.1.3) ### LDLM のロック管理(§5.1.4) 第 3 章で導入された分散ロックマネージャ(LDLM)の高度化機能群である。ロックは granted・waiting・converting の 3 リストで管理され、global(サーバ側の権威状態)/local(クライアントシャドウ名前空間のコピー)に区別される。 - **ロック要求処理**: 競合チェックを経て即時許可・待機リストへの登録・変換要求のいずれかに振り分けられる。図13 はこの流れをまとめたものである。 - **ロックプロロング**: 高負荷時に書き込み要求ごとにロックタイムアウトを延長し、正当なクライアントの誤退去(eviction)を防ぐ。 - **ロックデッドロック回避**: OST 資源はファイルレイアウト順、MDT 資源は親子ディレクトリ関係の順で厳格な取得順序を強制する。 - **ロックインテント**: open・lookup 等のクライアントの最終目的をサーバへ伝え、RPC 往復を削減する。8 種類のインテント操作が定義されている。 - **ロックグリンプス**: `ls -l` 等のためにファイルサイズだけをロック取得なしで取得する軽量な機構。 - **ロックリプレイ/リカバリ**: LDLM ロックは RAM 上にのみ存在するため、クライアント/サーバ障害時にはリプレイで再構築する(§5.2.3 と連動)。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig13-ldlm-lock-flowchart.png]] (図13. LDLM におけるロック要求処理からキャンセルまでのフローチャート。R は要求者、WL は待機リストを表す。§5.1.4) ### Distributed Namespace Environment(DNE、§5.1.5) 初期 Lustre は単一 MDS/MDT しかサポートせず、大規模化に伴いメタデータ性能がボトルネックになった。DNE はこれに対応するために 3 フェーズで開発された。 - **Phase 1(リモートディレクトリ)**: MDT0 以外の MDT にリモートディレクトリを配置できるようにした。MDT0 配下のディレクトリのみがリモートサブディレクトリを持てるという制約により、MDT 障害時に名前空間の一部が到達不能になる事態を防ぐ。 - **Phase 2(ストライプディレクトリ)**: 大規模ディレクトリのメタデータ性能を改善するため、1 つのディレクトリを複数 MDT にストライプする。クライアント側の LMV 層がこれを単一ディレクトリとして透過的に見せる。 - **Phase 3(バランスドリモートディレクトリ)**: 管理者の手動指定なしに、MDT 間の空き容量を見て新規ディレクトリ作成先を自動的に分散させる。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig14-dne1-remote-directory.png]] (図14. DNE Phase 1 のリモートディレクトリ構成。§5.1.5) ![[_attachments/survey-2025-lustre-unveiled/ch05-fig15-dne2-striped-directory.png]] (図15. DNE Phase 2 のストライプディレクトリ構成。§5.1.5) ### OSS/MDS の弾力性(§5.1.6) サービス無停止のまま OSS/MDS ホストや OST/MDT を追加・撤去できる機能である。新規ファイルオブジェクトの割り当ては空き容量比に基づく重み付きランダム選択で新しい/空の OST を優先し、削除は古い/満杯の OST を優先することで受動的に空間バランスを取る。深刻な偏りがある場合のみ、能動的なファイル/ディレクトリ移行を行う。 ## Resilience and Availability(§5.2) ### データ冗長性と高可用性(§5.2.1) Lustre 自体はデータをレプリケートしないが、RAID(MDT に RAID-1、OST/MDT に RAID-6 が一般的)による物理層冗長化と、フェイルオーバーによるサービス継続を組み合わせる。 - **フェイルオーバー構成**: MDS・OSS・MGS いずれもフェイルオーバー可能で、Pacemaker/Corosync 等の HA ソフトウェアと共有ストレージ(SAN/NAS/ハードウェア RAID)を用いる。MDT は active/passive(単一 MDT を 2 台の MDS で待機)と active/active(複数 MDT を 2 台の MDS で相互バックアップ)、OST は通常 active/active(2 台の OSS が互いの OST の予備を担う)を取る。Multiple Mount Protection(MMP)で同時マウントによる破損を防止する。 - **File Level Redundancy(FLR)**: 複数 OST に同一ファイルデータを保持することで OST 障害時も読み取りを継続できるようにする機能。4 フェーズ(遅延ミラーリング・EC・即時冗長化と最適化リシンク・ポリシーエンジン統合)のうち、現行版は第 1 フェーズの遅延ミラーリングのみを実装し、Changelog を使ったユーザー空間ユーティリティで再同期する。ミラーリング粒度はファイル単位で、MDT の冗長化は対象外である。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig16-failover-configurations.png]] (図16. フェイルオーバー構成: (a) active/passive、(b) active/active の MDT フェイルオーバー、(c) active/active の OST フェイルオーバー。§5.2.1) ### 障害リカバリシナリオ(§5.2.2) - **クライアント障害**: ブロッキングコールバックへの無応答やハートビート途絶で退去(eviction)され、保持ロックはサーバが解放する。 - **MDS 障害**: HA 構成では外部 HA ソフトウェア(Heartbeat 等)がフェイルオーバー先を検知・切り替える。クライアントはタイムアウトで検知し、新 MDS へ再接続してメタデータリプレイを開始する。 - **OST 障害**: OSC がリカバリモードに入り、I/O を保留する。MDS は当該 OST への新規オブジェクト割り当てを回避し、復旧後は孤立オブジェクトの自動リカバリを行う。 - **一時的ネットワーク分断**: 再接続とレスポンス再構築で、重複実行を避けつつ透過的に処理する。 ### トランザクションリプレイとリカバリ処理(§5.2.3) サーバが正常終了せずに再起動すると、リカバリモードに入り、以前接続していたクライアントの再接続とリプレイ/再送を待つ。各クライアント要求には一意増加する XID が付与され、サーバは状態変更操作に単調増加のトランザクション番号を割り当てる。メタデータリプレイはトランザクション番号順に処理され、リクエストリプレイの後にロックリプレイが完了して初めて非リカバリ操作が許可される。返信が失われた場合はサーバがリプレイ再構築で同じ返信を再生成し、非冪等操作の重複実行を防ぐ。 ### 高度なリカバリ機能(§5.2.4) - **Version-Based Recovery(VBR)**: inode バージョンを追跡し、特定クライアントのリプレイ失敗が他クライアントの巻き込み退去を招かないようにする。事前/事後の inode バージョンが一致した場合のみリプレイを成立させる。 - **Imperative Recovery(IR)**: MGS が保持するターゲット状態テーブルを通じて、サーバ障害をクライアントへ能動的に通知し、タイムアウトベースのリカバリより短時間でリカバリウィンドウを縮小する。MGS 自身の再起動時は一時的に IR を無効化する。 ### LNet Health(§5.2.5) Multi-Rail の耐障害性を高めるための健全性監視機能である。ローカル/リモートインターフェース障害とタイムアウトの 3 種の失敗要因を区別し、各 NI にヘルス値(初期値 1000)を割り当てて、一時的エラーで急減・安定送信で緩やかに回復させる。ヘルス値・近接性・クレジット残量に基づき最適な送信経路を選択する。 ### Lustre Filesystem Consistency Checker(LFSCK、§5.2.6) オンライン分散整合性チェッカーで、稼働中のファイルシステムを止めずに実行できる。3 フェーズで開発された。 - **Phase 1(OI スクラブ)**: MDT/OST 内部の Object Index(OI)整合性を検査・修復する。ファイルレベルバックアップ復元後の inode 番号不一致対策として実装された。 - **Phase 2(MDT-OST レイアウト整合性)**: MDT inode と OST オブジェクト間の親子参照(ダングリング参照・非参照オブジェクト)を検査・修復し、UID/GID もクロス検証する。 - **Phase 3(DNE のリモート/ストライプディレクトリ)**: DNE 環境固有の複数 MDT にまたがる名前空間整合性(ダングリング名前エントリ、孤立 MDT オブジェクト等)を検査・修復する。 ### 「良い」ハードウェア(§5.2.7) クライアントを MDS/OSS と同居させると、メモリ圧迫によるハングやリカバリ・デッドロック問題を招くため、本番環境ではクライアントを専用ホストに分離することが推奨される。表 6 は各コンポーネントの推奨構成をまとめたものである。 | コンポーネント | 推奨構成 | |---|---| | MGS | 非本番は MDS と共有ストレージ可、本番は分離ストレージ | | MGT | 1 GiB 未満、RAID-1 でミラー化 | | MDS | DNE・大規模メタデータ向けに大容量 RAM(標準 60 GiB、DNE フェイルオーバー時 96 GiB) | | MDT | SSD/NVMe または高回転数 SAS。個別コントローラ 2 台での RAID-1 + 内部ジャーナル、複数 RAID-1 の RAID-0 化、ZFS はミラー VDEV | | OSS | 1 台あたり OST 2〜8 個、各 32〜1024 TB 容量 | | OST | HDD または NVMe、大規模 OST には RAID-6 | | Lustre クライアント | 本番では MDS/OSS と別ホスト | 64 台の OSS(各 512 TB の OST 2 個)で 75 PB 超を実現でき、HDD ベースの RAID-6 構成では OSS あたり約 10 GB/秒、NVMe ベースでは書き込み 65 GB/秒・読み取り 90 GB/秒程度の端対端スループットが得られると報告されている(§5.2.7)。 ## Usability and Manageability(§5.3) ### 監視と管理(§5.3.1) `lctl get_param` で統計を取得する。標準 stats(OST/MDT ごとのイベント記録)と、SLURM 等のジョブスケジューラの JobID ごとに集計する jobstats(YAML 形式)がある。Lustre Changelog はファイル作成・削除・リネーム等の名前空間変更を FID・タイムスタンプ・ユーザー情報とともに永続記録し、アーカイブ更新・ミラー複製・監査に使われる。監視ツールとして LMT(サーバ側のみ)、CollectL、lltop/xltop、tacc_stats が併用される。 ### Hierarchical Storage Management(HSM、§5.3.2) Lustre を低速な外部ストレージ階層に対する高速キャッシュとして機能させる連携機能である。アーカイブ(HSM への転送)とリストア(Lustre への取り出し)の 2 プロセスからなり、RobinHood(Changelog 利用)や PoliMOR(全走査型)といった外部ポリシーエンジンが対象を判定する。アーカイブ/リストアの実データ転送は、コーディネータ(MDS 上で稼働)の指揮のもと、コピーツールを実行するエージェント(Lustre クライアント)が担う。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig17-hsm-integration.png]] (図17. Lustre と HSM 連携のブロックレベル構成。§5.3.2) ### OST プール(§5.3.3) 性能特性が似た OST(SSD 群・HDD 群等)をグループ化し、階層化データ配置を単純化する機能で、Frontier・LUMI・El Capitan のようなマルチティア構成の基盤となっている。1 つの OST は複数プールに属せ、プール定義変更は既存ファイルに影響しない。 ### プロジェクトクォータ(§5.3.4) ユーザー/グループクォータに加え、管理者が任意に割り当てる Project ID 単位のクォータをサポートする。ディレクトリに Project ID を継承フラグ付きで割り当てることで、所有者や所属グループを問わずプロジェクト単位の容量・inode 使用量を集計できる。 ### Progressive File Layout(PFL、§5.3.5) デフォルトの plain layout はファイル全体に単一のストライプ設定を適用するのに対し、PFL は非重複エクステントごとに独立したレイアウトコンポーネントを持つ複合レイアウトである。ファイル作成時は先頭コンポーネントのみを初期化し、以降のコンポーネントは実際に書き込まれる際に遅延初期化するため、未使用 OST オブジェクトの割り当てを避けられる。`lfs setstripe` の `--component-end`(`-E`)オプションでエクステント境界を指定する。 ![[_attachments/survey-2025-lustre-unveiled/ch05-fig18-plain-vs-pfl-layout.png]] (図18. plain layout と progressive file layout の比較。§5.3.5) ### Object Storage Device 層(§5.3.6) ldiskfs(ext4 拡張)と ZFS という異なるバックエンドファイルシステムに対する抽象化層である。OI(第 3 章 §3.1.4)が Lustre FID をバックエンド固有の識別子(ldiskfs では inode 番号+世代番号、ZFS では 64 ビットオブジェクト番号)に変換する。OSD API はトランザクション制御・ローカルオブジェクトロック・クォータ会計(QSD/QMT 連携による分散クォータ)を提供する。 ### 動的 LNet 設定(§5.3.7) Lustre 2.7.0 以前は `modprobe` でカーネルモジュールを再読込する必要があり、対象ホストに一時的なダウンタイムが発生した。2.7.0 で導入された `lnetctl` により、稼働中のカーネルモジュールを止めずに LNet 設定を変更できる Dynamic LNet Configuration(DLC)が可能になった。 ### LNet Multi-Rail Dynamic Discovery(§5.3.8) 大規模クラスタで Multi-Rail のピア設定を手動で行うのはエラーを招きやすいため導入された、ピアのインターフェースを LNet ping ベースのプロトコルで自動発見する機能(デフォルト有効)。ピアが MR 対応かどうかをフィーチャービットで判定し、対応していれば NID リストを交換する。LNet Health(§5.2.5)と統合され、ゲートウェイ障害時の経路切替にも利用される。 ### クロス互換性(§5.3.9) Lustre サーバは RHEL 系での運用が最も広く検証されている。表 7 は最新 LTS 版 2.15.4 の対応 Linux ディストリビューションで、サーバは RHEL 8.9、クライアントは RHEL 8.9/9.3・SLES15 SP5・Ubuntu 22.04 をサポートすると要約されている。NFS(knfsd/Ganesha)や Samba 経由の CIFS 再エクスポートで非 Linux クライアントとも共有できるが、いずれも POSIX 準拠ではなくキャッシュコヒーレンシも失われる。各 LTS 版は直前の LTS 版と後方互換性を持つ(例: 2.15 は 2.12 と互換)。 ## Security(§5.4) ### ID ベースのセキュリティと分離(§5.4.1) UID・GID・Project ID の 3 層で権限・クォータ制御を行う。UID/GID はアクセス制御に直結するが、Project ID はアクセス制御ではなく容量・資源会計にのみ用いる。 ### アクセス制御リスト(ACL、§5.4.2) POSIX 標準の owner/group/other モデルを拡張し、`setfacl`/`getfacl` 等の Linux 標準ツールでよりきめ細かな権限設定を可能にする。ファイルシステム全体で有効/無効を統一する。 ### サブディレクトリマウント分離(§5.4.3) マルチテナント向けに、テナントごとに名前空間の一部(fileset)だけを見せる分離機構である。nodemap(§5.4.6)でクライアント群をテナントに紐付け、fileset を割り当てる。分離の実効性は NID の正当性検証や Kerberos・Shared-Secret Key(SSK)による強固なクライアント識別に依存する。 ### クライアント側暗号化(§5.4.4) カーネルの fscrypt ライブラリを用い、クライアント側でファイルデータとファイル名を暗号化する機能。暗号鍵はサーバへ送信されないため、サーバ側の攻撃者はファイル内容を復元できない(オフライン攻撃への耐性)。ファイルサイズやタイムスタンプ等の非ファイル名メタデータは保護対象外である。暗号方式は AES-256-XTS/CTS-CBC、AES-128-CBC/CTS-CBC(低電力組込み機器向け)、Adiantum の組み合わせから選択する。暗号化ディレクトリツリーはマスターキー(最大 64 バイト)で保護され、ファイルごとの鍵はマスターキーと nonce から KDF で導出する。 ### Kerberos セキュリティ(§5.4.5) KDC を介した相互認証で、認証(Authentication)・完全性(Integrity)・機密性(Privacy)の 3 つを提供する。セキュリティフレーバー(`null`・`krb5n`・`krb5a`・`krb5i`・`krb5p`)によって保護レベルと性能オーバーヘッドのトレードオフをマウント時に選択する。 ### Nodemap(§5.4.6) クライアント群を NID 範囲で名前付きグループにまとめ、管理権限を委譲する機能である。UID/GID/PROJID をリモートシステムとファイルシステム側で個別にマッピングでき、異なる管理ドメイン間の ID 衝突を回避する。`admin`/`trusted` プロパティの組み合わせで root の扱い(直接マップ/スカッシュ)が変わる。変更は通常 10 秒程度でクラスタ全体に伝播する。 ## 傾向と未解決課題 - 4 軸を通じて共通する傾向は、**単一障害点・単一ボトルネックの段階的な除去**である。単一 MDT(→ DNE)、静的レイアウト(→ PFL)、集中管理型セキュリティ(→ nodemap によるマルチテナント委譲)のように、初期設計の制約を後方互換性を保ったまま段階的に緩和してきた。 - メタデータ書き込みは依然として MDS 側が代行する方式(§5.1.1)であり、クライアント側で直接更新できる Metadata Writeback Cache は未実装(第 7 章の担当)。 - FLR は遅延ミラーリングの第 1 フェーズのみ実装済みで、即時ミラーリングと EC は今後の拡張(第 7 章)。 - LFSCK・LNet Health・Imperative Recovery のように、障害検知・復旧の自動化が段階的に整備されてきた一方、VBR や IR はいずれも既存の再送/リプレイ機構を置き換えるのではなく補完する設計であり、単純化よりも堅牢性の積み増しを優先していることが読み取れる。 ## 関連 - [[@2025__TOS__Lustre Unveiled - Chapter 3 Architectural Details of Lustre]] — LNet・LDLM・DNE の基礎構造を扱う前段の章。 - [[@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]] — 本章の機能群が実運用でどう使われるかの事例。 - [[@2025__TOS__Lustre Unveiled - Chapter 7 Future Directions and Open Challenges in Lustre]] — WBC・CSDC・FLR の EC フェーズ等の将来機能。 - [[wiki/entities/Lustre|Lustre]] - [[Lustre Unveiled]]