> [!abstract] > 本文書は「Lustre Book」と呼ばれる大部の設計資料であり、2001 年から 2005 年にかけて作成された Lustre ファイルシステムのアーキテクチャ詳細を記述する。各種ユーザの要求に基づき、ストレージ、ネットワーキング、ロック管理、メタデータサービス、回復機構、セキュリティに至る全設計層を網羅する。539 ページにわたり、アーキテクチャ(第 1 部)、設計 API(第 2 部)、マニュアル(第 3 部)、付録(第 4 部)の 4 部構成をとる。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | The Lustre Storage Architecture | | 著者 | [[Peter J. Braam]] (with others) | | 所属 | [[Cluster File Systems|Cluster File Systems, Inc.]] | | arXiv | 1903.01955 (cs.OS) | | 公開日 | 2019-03-05(内容は 2001-2005 年執筆） | | ページ数 | 539 | | URL | https://arxiv.org/abs/1903.01955 | ## 概要 Lustre の原初的な設計文書である。カーネギーメロン大学の Coda プロジェクトに起源を持ち、米国国立研究所（ロスアラモス・サンディア）と産業界の資金提供を受けて開発された並列ファイルシステムの、コンポーネント設計・プロトコル仕様・API 定義を全面的に記録する。 ## 文書の性格 本文書は Lustre の初期開発期（2001-2005）に Braam が中心となり執筆した設計書であり、2019 年に歴史的資料として arXiv に公開された。製品マニュアルではなく**設計意図と代替案の記録**という性格が強い。後年実装された機能（クラスタ化メタデータ、メタデータライトバックキャッシュなど）の設計根拠が第 38-39 章に率直に述べられている点で、通常の論文にはない洞察を提供する。 ## アーキテクチャ概要 Lustre クラスタは 3 種のノードから構成される。 ### コンポーネント構成 - **クライアント**（数万台規模）: Lustre Lite ファイルシステムモジュールを実行し、OST にファイルデータ I/O を、MDS に名前空間操作を発行する。ライトバックキャッシュ・OS バイパス I/O を備える。 - **オブジェクトストレージターゲット（OST）**（数千台規模）: ファイルデータをオブジェクトとして格納する。ブロック割り当ては OST 側が担い、分散的かつスケーラブルなアロケーションメタデータを実現する。OBD フィルタドライバを介して ext3 / XFS / JFS 等のジャーナリングファイルシステムを利用する。 - **メタデータサーバ（MDS）**（数十台規模）: 名前空間・属性・ディレクトリを管理する。Lustre Lite ではシングル MDS +フェイルオーバ構成、完全版 Lustre ではクラスタ化メタデータを目指す。 3 者は分離も同一ノード上での対称配置も可能であり、モジュラーなフレームワーク設計がその柔軟性を支える。 ### Portals ネットワーキング ネットワーク層はサンディア国立研究所が開発した Portals API を基盤とする。Portals はネットワーク抽象化レイヤ（NAL）を介して Ethernet・Quadrics・InfiniBand 等の複数トランスポートに対応する。RDMA をネイティブにサポートし、TCP のバッファコピーモデルを回避することで高性能を実現する。リクエスト処理層はこの上に構築され、バルクデータ移動とイベント配信を提供する。 設計代替案として VIA・DAFS RPC・InfiniBand ネイティブ API が検討されたが、イベント配信 API の表現力と NAL によるネットワーク透過性で Portals が選択された（第 39 章）。 ### オブジェクトストレージモデル オブジェクトストレージはスタック型のモジュール構造をとる。最下層のダイレクト OBD ドライバがストレージデバイスを制御し、その上にロジカル OBD ドライバ（ストライピング用 LOV、スナップショット OBD、キャッシング OBD など）を積層する。ダイレクトドライバとロジカルドライバは同一インタフェースを公開するため、動的なドライバスタックの切り替え（ホットデータマイグレーション等）が可能である。 オブジェクト名前空間はフラットではなくオブジェクトグループに分割され、ファイルシステムスナップショットやマイグレーションを容易にする。この設計は当時の NSIC OBD 仕様からの意図的な逸脱であった。 ### メタデータサービス設計 MDS は 2 つの動作モードを提供する。 1. **クライアント-サーバモード**: 各メタデータ更新は単一 RPC に帰着する。名前空間要素はファイル識別子（fid）で一意に識別され、fid は再利用されない。ロックと属性は `mdc_enqueue` API で原子的に返却される。 2. **ライトバックキャッシュモード**: 単一のサブツリーロックが名前空間の部分木全体を保護し、クライアントがローカルに更新を蓄積した後に一括で MDS にフラッシュする。低リソース消費だが同期レイテンシが高い。 両モード間の動的切り替えをロック競合のトラフィック計測に基づいて行うポリシーが設計されている。 **クラスタ化メタデータ**（第 6.7 節）では、複数 MDS がアイノードグループを分担し、ロジカルメタデータボリューム（LMV）ドライバがクライアントからのリクエストを適切な MDS に振り分ける。ディレクトリはハッシュベースで複数 MDS に分割（ディレクトリスプリット）される。ただし回復プロトコルの複雑さから、段階的導入が計画された。 ### 分散ロックマネージャ（DLM） Lustre DLM は VAX Cluster DLM を基盤とし、重要な拡張を加えている。6 段階のロックモード（NL, CR, CW, PR, PW, EX）による互換性行列を持ち、ファイルエクステントロックとインテントロックをポリシー関数で統合した。 リソースはリソースツリーの森として管理され、祖先リソースのロックを先に取得する階層的ロック方式を採用する。分散環境ではロックディレクトリ重みベクトル（LDWV）によるハッシュベースのリソースマスタ探索が行われる。全構造がインメモリであり永続ストレージを参照しない点が特徴的である。 IBM DLM は「不必要に複雑で安定性が不十分」として採用が見送られた（第 39 章）。 ## 設計上の決定と代替案 第 38-39 章は設計の不確実性と代替案を率直に記録しており、本文書の歴史的価値の核心である。 - **対称クラスタ対非対称クラスタ**: メンバーシップ・クォーラムアルゴリズムのスケーラビリティ不足と複雑性を理由に、対称型を棄却した。クライアントを「比較的権限の弱い外部システム」とみなし、メタデータサーバ群を小規模な信頼ドメインとする非対称構成を採用した。 - **バックエンドファイルシステム**: XFS・ReiserFS も候補だったが、ext3 を選択した。理由は「性能差は最小限であり ext3 の改善速度が速い」こと、および「コードサイズが ReiserFS の 10%、XFS の 3% である」こと。 - **フェイルオーバ対完全クラスタリング**: MDS クラスタは Ensemble / Spread 等のツールキットの使用が検討されたが、「もっと単純なものが望ましい」との判断でフェイルオーバペアによる冗長化が選好された。 - **プロトコル選択**: NFSv4 / DAFS への準拠が検討されたが、メタデータライトバックとの非互換性およびストレージネットワーキングとの統合困難を理由に独自プロトコルが採用された。 - **ディレクトリ構造**: B-tree ベースの検討後、ext3 の HTree ハッシュディレクトリが選択された。ブロックへのマッピングが計算可能であり、クラスタ上の負荷分散に適するためである。 **主要な不確実性**として、1,000 ノードクラスタでの回復スケーラビリティ、メタデータロックのデッドロック問題、ライトバックキャッシュのフロー制御、コラボレイティブキャッシュの障害回復が挙げられている。 ## 回復機構 Lustre の回復設計は 4 種の障害に対応する: (1) クライアントノード障害、(2) MDS 障害、(3) OST 障害、(4) 一時的ネットワーク障害。 回復インフラストラクチャはエポック番号（ブートカウント）、インカネーション番号（MDS クラスタ構成変更）、ジェネレーション番号（接続単位）、トランザクション ID の 4 つの変数で管理される。 - **永続状態回復**: MDS と OST 間の一貫性はロジカルログで維持する。孤立オブジェクト（MDS に参照がないオブジェクト）と逆のケース（存在しないオブジェクトへの参照）の両方に対処するログベースのプロトコルが定義されている。 - **MDS フェイルオーバ**: Kimberlite / clumanager 等の高可用性ソフトウェアと連携し、アクティブ-スタンバイ構成で透過的にフェイルオーバする。クライアントは LDAP サーバにフェイルオーバ先を問い合わせて再接続する。 - **OST フェイルオーバ**: MDS と異なり、プライマリとスタンバイの両方がアクティブにリクエストを処理する。プライマリ障害時にスタンバイが引き継ぎ、復旧後はクライアント群を段階的にフェイルバックさせて負荷分散を維持する。 - **ネットワーク障害**: タイムアウトのみで検知され、サーバ障害と区別不可能である。再接続を試み、失敗すれば回復プロトコルを起動する。 「単一障害前提」が重要な設計仮定であり、大規模クラスタでは複数ノードの同時障害が稀であるとの経験則に基づく。この仮定により劇的な性能向上が可能となった。 ## セキュリティ設計 セキュリティアーキテクチャは M. Satyanarayanan の分散ファイルシステムセキュリティの議論を踏襲する。 - **信頼モデル**: ネットワークを「クラスタネットワーク」（プライベート・改竄なし）と「その他のネットワーク」に二分し、前者では暗号処理を回避して性能を優先する。 - **認証**: GSS-API を基盤とし、Kerberos 5 をバックエンドとする。Portals ネットワークインタフェースに GSS セキュリティメカニズムを結合する設計で、コネクションレスネットワーク（QSW, Myrinet）とコネクションベースネットワーク（TCP）で異なるポリシー選択を行う。 - **プロセス認証グループ（PAG）**: AFS から継承した概念で、root の setuid 攻撃を緩和する。ただし、強化カーネル（SELinux 等）なしでは「表面的な保護に過ぎない」と率直に評価されている。 - **ファイル暗号化**: StorageTek の SFS モデルを採用する。 - **認可**: 標準的な POSIX ACL に準拠し、独自のアクセス制御スキームの定義を回避する。NFS v4・Samba プロジェクトの既存 ACL 構造を踏襲する。 セキュリティ性能への懸念が第 38 章の不確実性として明記されており、「厳格なセキュリティの性能への影響を限定できるか」は当時の産業界の経験では楽観できないとされている。 ## 歴史的意義 本文書は Lustre の設計思想を最も包括的に記録した一次資料である。以下の点で特異な価値を持つ。 1. **設計根拠の記録**: 多くのシステム設計書が完成した設計のみを記述するのに対し、本文書は棄却された代替案（対称クラスタ、VIA ネットワーキング、IBM DLM など）とその理由を明記する。 2. **長期ロードマップの原点**: メタデータライトバックキャッシュ、クラスタ化 MDS、コラボレイティブキャッシュなど、ここで構想された機能の多くは実装に 10-20 年を要した。 3. **Coda/InterMezzo からの系譜**: Braam が CMU の Coda プロジェクトおよび InterMezzo で培った知見が Lustre に直接流入した経緯が随所に記されている。特にメタデータライトバックキャッシュは InterMezzo が先駆であると明記されている。 4. **産学連携の記録**: 米国国立研究所（ロスアラモス、サンディア、ローレンスリバモア）と産業界（Seagate 等）の要求がアーキテクチャ設計に与えた影響を追跡できる。 ## 強み / 弱点・課題 ### 強み - 539 ページにわたる網羅的な設計記録であり、コンポーネント間の相互作用まで含む一次資料としての完全性が高い。 - 設計代替案と不確実性の率直な記述は、分散ファイルシステムの設計判断を学ぶ教材として優れている。 - API 定義（第 2 部）は実装者向けの詳細仕様を提供する。 ### 弱点・課題 - 2001-2005 年の設計時点の記述であり、その後の 20 年間に実装・変更された機能との差異は本文書からは追跡できない。後年の進化は [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]] 等を参照する必要がある。 - 539 ページの長大さゆえに構造の一貫性にばらつきがあり、一部の章（第 13-14 章の構成管理が重複等）は編集上の整理が不十分である。 - 性能評価データは含まれておらず、設計判断の定量的根拠は限定的である。