@2025__TOS__Lustre Unveiled - Chapter 3 Architectural Details of Lustre

# Lustre Unveiled - Chapter 3: Architectural Details of Lustre > 前: [[@2025__TOS__Lustre Unveiled - Chapter 2 The Lustre Filesystem]] | 次: [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]] | 全体: [[Lustre Unveiled]] ## 要約第3章は、第5章で扱う高度な機能の土台として、Lustreのアーキテクチャ詳細を4節構成で解説する。§3.1ではデータ・メタデータを保持する分散オブジェクトストレージの基本単位と識別子(FID・OI)、§3.2ではクライアント/サーバのソフトウェアスタックとファイルシステム操作の処理経路、§3.3では並列I/Oにおける整合性を担保する分散ロックマネージャ(LDLM)、§3.4ではLustreのネットワーキング層LNetを扱う。 ## データとメタデータのオブジェクトストレージ Lustreのアーキテクチャ設計の中心は分散オブジェクトストレージである。オブジェクトはフィルシステム内でグローバルに一意な識別子を持つ論理的な格納位置であり、オブジェクトのグローバルIDが与えられれば、任意のクライアントまたはサーバがそのオブジェクトを保持するストレージターゲットを導出できる。オブジェクトに格納されるデータの種類は、ストレージターゲットの種類に依存する。 **データオブジェクト**。Lustreファイルの内容は、ファイルレイアウトに従って1つ以上のデータオブジェクトに分散配置される。最も単純で一般的なファイルレイアウトはRAID-0に類似した「プレーン」ストライピングレイアウトであり、ストライプカウントとストライプサイズという2つのパラメータで定義される。ストライプカウントはファイルのデータを保持するOSTの数を示し、データオブジェクトは各ラウンドで1つずつ、レイアウトに含まれるOSTへラウンドロビン方式で割り当てられる。ストライプサイズは、次のOSTへ移る前に各OST上のデータオブジェクトへ書き込むデータ量である。例えばストライプカウント3、ストライプサイズ1MiBのファイルへ書き込む場合、Lustreは3つの異なるOSTにデータオブジェクトを割り当て、最初の1MiBチャンクは1番目のOST、2番目のチャンクは2番目のOST、3番目のチャンクは3番目のOSTへ書き込まれ、4番目のチャンクで再び1番目のOSTへ戻るというラウンドロビンが続く。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig3-plain-file-striping.png]] (図3. Lustreにおけるプレーンファイルストライピング。File Aはストライプカウント3、File Bはカウント1で全データを1つのOSTに配置、File Cはより大きなストライプサイズかつカウント2の例を示す。より複雑なファイルレイアウト〔§5.3.5〕も、このプレーンレイアウトを用いたコンポーネントの集合として構成される。§3.1) **メタデータオブジェクト**。メタデータオブジェクトは、ユーザから見える名前空間内のファイルに対するメタデータ(POSIXファイル属性など)を保持する。これらはMDTバックエンドファイルシステム内で階層的な名前空間構造を反映するように組織化され、バックエンドファイルシステムの各ディレクトリはユーザから見える名前空間の対応するディレクトリ(同名、同じ親・子ディレクトリ)に対応する。ファイルを表すメタデータオブジェクトは、その親ディレクトリ内に存在する。各メタデータオブジェクトの拡張属性には、ファイルのレイアウトやアクセス制御リスト(ACL、§5.4.2)などの情報が記録される。 **FIDと分散管理されるグローバルオブジェクト識別子**。FID(File Identifier)は各オブジェクトに対する128ビットの一意な識別子で、Lustre 2.0で初めて導入された。FIDは3つの主要要素に分割されており、フィルシステムの各部分が他ホストとの直列化や通信を必要とせず自律的にFIDを生成できるようになっている。 - シーケンス番号(SEQ): 単一のホスト(クライアント、MDS、OSS)が管理する64ビット整数で、FIDの大きな範囲を一意に識別する。 - オブジェクトID(OID): 特定のSEQ範囲内で、フィルシステム全体のあらゆるMDTまたはOSTオブジェクトを一意に識別する32ビット整数。 - オブジェクトバージョン(VER): オブジェクトの複数の変種を識別しうる32ビット整数。現時点では未使用で常にゼロであり、統合されたフィルシステムスナップショットやサブボリューム(ZFSデータセットなど)向けに将来の使用のため予約されている。 FIDの64ビットSEQ範囲はSequence Controllerによってグローバルに管理される。Sequence Controllerは、各MDTおよびOSTが最初にフィルシステムをマウントする際に、10億個の連続値からなる大きなブロックを割り当てる。この大きな範囲によって、MDTやOSTは自らSequence Serverとしてふるまい、中央での調整点や競合なしに、数か月から数年にわたってピアへ個々のSEQ値をさらに割り当てることができる。各MDTはOSTのSequence ServerからそのOST上でオブジェクトを事前割り当てするためのSEQ番号を割り当てられ、各クライアントはMDT上に新規ファイル・ディレクトリを作成する際のFID生成のため、MDTのSequence ServerからSEQ番号を割り当てられる。 SEQの割り当てはFID Location Database(FLDB)にグローバルに可視化されるため、すべてのクライアント・サーバは特定のSEQを管理するMDTまたはOSTへマッピングできる。大きな割り当てブロックのおかげでFLDBはコンパクトであり(ターゲットあたり1〜2エントリ)、実質的に静的であるためすべてのホストで頻繁な更新なしにキャッシュできる。SEQ空間の一部は、フィルシステムのルートディレクトリ、設定ファイル、トランザクションログといった「well known」なFID向けに静的に予約されている。 **オブジェクトインデックス(OI)**。各ターゲット上で管理されるOIは、個々のFID番号を各バックエンドファイルシステムのローカルなファイルシステム識別子(inode番号と世代)にマッピングする。OIはバックエンドのinode番号をグローバル名前空間から抽象化しているため、下位のファイルシステムのinode番号が変化しても、他のデータ構造中のFIDへの参照を書き換える必要がない。例えばMDTやOSTを`tar`ユーティリティでバックアップ・復元した場合、inode番号は保存されないが、OIを再生成することでFID番号を同じオブジェクトへ再度マッピングできる。 ## ファイルシステム操作 Lustreのソフトウェアスタックはいくつかの層状コンポーネントから構成される。図4はこれらのコンポーネント間の関係を、クライアントからMDSまたはOSSへの要求の流れを矢印で示している(サーバからクライアントへの応答経路は図示されていないが、実質的に矢印を逆にしたものと同じである)。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig4-software-stack.png]] (図4. Lustreソフトウェアスタックの基本的な構成。§3.2) アプリケーションのI/Oシステムコールは、まずクライアントマシン上のLinux仮想ファイルシステム(VFS)層で処理され、必要なVFS操作を実装するLustre `llite`カーネルモジュールへ渡される。この時点で要求は種類に応じて2つの経路のいずれかを取る。メタデータアクセス要求はLogical Metadata Volume(LMV)コンポーネントへ、データ要求はLogical Object Volume(LOV)コンポーネントへルーティングされる。クライアントはフィルシステム内の各MDTに対してMetadata Client(MDC)コンポーネントを保持する。LMVはFID、またはディレクトリレイアウトとファイル名のハッシュに基づき、メタデータ要求を正しいMDCへルーティングする。MDCは要求をPortals RPC(PtlRPC)サブシステム向けに準備し、LNetを介して配送する。サーバ側では、LNet層からの着信要求がPtlRPC層を経てMDSコンポーネントへ渡る。MDSはロック関連の要求をLustre Distributed Lock Manager(LDLM)層へ送り、メタデータ要求はlookup・パーミッションチェック・属性・xattrなど一般的なメタデータ機能を実装するMetadata Device(MDD)で処理される。これらの要求はさらにバックエンドのOSDファイルシステムと直接やり取りするOSD層へ渡される。データ要求の経路も類似している。クライアントはフィルシステム内の各OSTに対してObject Storage Client(OSC)コンポーネントを保持する。LOVはOSCコンポーネント群の抽象化層としてふるまい、要求の最終ターゲットに基づいてデータ要求を正しいOSCへルーティングする。MDCと同様、OSCは要求をPtlRPC → LNet → 物理ネットワーク → LNet → PtlRPCという経路で送り、サーバ側のOSS層に到達する。OSSはロック関連要求をLDLMコンポーネントへ、データ要求は複合OSDトランザクション・I/O・属性要求・リカバリログといった一般的なオブジェクト機能を扱うOBD Filter Device(OFD)コンポーネントへ送る。これらの要求もバックエンドのOSDファイルシステムとやり取りするOSD層へ渡される。 **パス解決**。フィルシステムの名前空間を辿るため、クライアントはパス名の各コンポーネントについて、特定の親ディレクトリFIDとその中のファイル名に対応するメタデータオブジェクトのFIDを取得するために、適切なMDSへ要求を送りながら段階的にlookupを行う。クライアントが以前にその親ディレクトリへアクセス済みであれば、親のFIDはクライアントのメタデータキャッシュに存在するはずである(§5.1.1参照)。存在しなければ、クライアントはまず同じパス解決処理で親のFIDを取得しなければならない。最悪の場合、クライアントは名前空間のROOTディレクトリから各ディレクトリコンポーネントごとにファイル名lookupを行う。 **ディレクトリエントリの一覧表示**。ディレクトリの一覧表示要求は、そのディレクトリ内容を保持する1つ以上のMDTへ送られる。対象のMDTは通常のパス解決プロセスによって決まる。クライアントへ返されるメタデータには、ディレクトリエントリ(ファイル・サブディレクトリの名前)の一覧、それらのFID、対象ディレクトリ内の各エントリの種類が含まれる。クライアントは、返されたディレクトリ内容をLDLMロックのもとでキャッシュしてよい(§5.1.1参照)。 **ファイル・ディレクトリの作成**。クライアントが新しいディレクトリエントリ(ファイルまたはサブディレクトリ)を作成する際、作成要求は新規エントリの親ディレクトリを保持するMDTへ転送される。対象MDTはパス解決プロセスで決まる。要求にはクライアントが選んだ新規エントリのFID、名前、基本属性が含まれる。ファイル作成時、クライアントは作成要求に特定のファイルレイアウトを含めるオプションを持つ。特定のレイアウトが指定されなければ、ファイルは親ディレクトリに関連付けられたデフォルトのファイルレイアウト、なければフィルシステムのルートディレクトリのものを継承する。ファイルレイアウト情報はファイルに関連付けられたメタデータオブジェクトの拡張属性に格納され、これをLayout Extended Attribute、略してLayout EAと呼ぶ(図5参照)。MDSは作成時に、Progressive File Layout(PFL、§5.3.5で述べる高度なファイルレイアウト)の最初のコンポーネント、あるいはプレーンレイアウトの場合はファイル全体について、要求されたOSTオブジェクト数を割り当てることでファイルのレイアウトを実体化する。OSTオブジェクトの割り当ては対象OSTへの要求送信によって行われる。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig5-fid-layout-ea.png]] (図5. FIDを用いてファイルのLayout拡張属性と対応するOSTオブジェクトへアクセスする様子。§3.2.3) **既存ファイルのオープン**。Lustreクライアントがファイルデータへアクセスしたい場合、クライアントはパス名の各コンポーネントを段階的にlookupしながら辿る。クライアントはファイル名の最後のコンポーネントに対するlookupのため、ロックインテント要求(§5.1.4参照)を送る。MDSはそのファイル名に対応するFIDを、Layout EA・その他の拡張属性・種類やアクセスモード、タイムスタンプなどのファイル属性とともに返す。クライアントはinodeメタデータをLDLMロックのもとでキャッシュし(§3.3.1参照)、Layout EAを用いてLustreファイルのすべてのOSTオブジェクトの位置を特定する。この時点でクライアントは該当OSTへ直接アクセスし、データの読み書きができる。図6はこの処理の要約を示す。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig6-io-operation.png]] (図6. Lustreのファイルデータ要求を伴うI/O操作の流れ。§3.2.4) **ファイルへのデータ書き込み**。ファイルへの書き込み操作の際、クライアントは論理ファイルオフセットと書き込みバッファ長を用いて、ファイルエクステントとそのエクステント内のデータを含むOSTオブジェクトを特定する。ファイルエクステントは、特定のストライピングパラメータで定義され複数のOSTにまたがってストライピングされうる、ファイルの論理的な区間である。クライアントは次にOST(s)へ書き込みロックを要求する(§3.3.1参照)。データはOSTへの書き込み要求が送信されるまでクライアントのRAMにキャッシュされる。バルクRPCサイズ(典型的には1MBまたは4MB)より小さい書き込みについては、クライアントは数秒程度の短時間待機し、後続のアプリケーションによる`write()`操作からさらにデータを集約してフルサイズのバルクRPCを形成しようとする。書き込みデータの集約は、各OSTへのネットワーク転送回数を減らし、バックエンドストレージへのより効率的な割り当てと書き込みを可能にする利点がある。キャッシュされたデータに対する書き込み要求は、キャッシュデータがフルサイズのバルクRPCを形成できたとき、アプリケーションの`fsync()`呼び出し時、または他のクライアントが競合するロックをエンキューしたとき(§5.1.4参照)に即座に送信される。なお、クライアントがOSTへ書き込みRPCを送る際、これはOSSのメモリ・ネットワーク帯域を圧迫しないよう書き込みのメタデータのみであり、データ自体ではない。OSTがその書き込みRPCを処理した時点で初めて、サーバ側のバッファがファイルデータ用に準備され、OSSからクライアントへのデータRDMA転送が開始される。OSSは、ファイルへの書き込みに応じて各OSTオブジェクトの正式なデータサイズを保持する。 **ファイルからのデータ読み込み**。読み込み操作の際、クライアントは論理ファイルオフセットと読み込みバッファ長を用いて読み込み対象のファイルエクステントを特定し、ローカルのデータキャッシュにその可用性を確認する。データがページキャッシュに無ければ、クライアントはそのエクステント内のデータを含むOSTオブジェクトを特定し、OST(s)へ読み込みロックを要求する(§3.3.1参照)。データはOST(s)への読み込み要求を通じて取得され、クライアント上にローカルキャッシュされる。アプリケーションが既定で2MB未満の小さいファイルを読む場合、複数の小さな読み込み要求をOSTへ送るのではなく、単一の要求でファイル全体をクライアントのページキャッシュへ取得する。アプリケーションが大きなファイルへ連続する複数の読み込みを行う場合、クライアントはシーケンシャルまたはストライドの読み込みパターンを検知し、アプリケーションの`read()`呼び出しに先立ってページキャッシュへデータを先読みする非同期リードアヘッドを開始し、アプリケーションの帯域を改善しレイテンシを削減する。 **ファイルのクローズ**。アプリケーションがファイルを閉じる際、ファイルのアクセスパターンによってはクライアントはオープンファイルロックをローカルにキャッシュし、同じファイルに対するオープン・クローズRPCの繰り返し送信をMDSへ避けることができる。ファイルの最終クローズ時、クライアントはもはやそのファイルにアクセスしていないことをMDSへRPCで通知し、現在のサイズ・ブロック数・タイムスタンプ属性を併せて送り、MDTがそれをLazy Size-on-MDT(LSOM)拡張属性へ将来の参照用にキャッシュできるようにする。MDSは、以前に送られた値より増加している場合のみLSOM属性を更新する。LSOM属性は正式なファイルサイズ情報を構成するものではないが、正確なサイズ情報に依存しないフィルシステムスキャンやポリシーエンジンにとって有用である。 ## 並列I/Oの並行性と整合性ファイルに対するクライアントのI/O操作・メタデータ操作は、個々のオブジェクトを対象とする1つ以上のアクションへ変換される。これらのオブジェクトが複数のサーバやターゲットにまたがって分散している場合、Lustreのクライアントアーキテクチャは、リモートアクションの並行的な通信と処理を可能にする。さらに、並列アプリケーションはしばしば多数のクライアントから単一のサーバやオブジェクトへ並行して要求を発行する。そのためサーバコンポーネントはマルチスレッド化されており、同一サーバ上の複数のストレージターゲット(MDTまたはOST)への要求を並行して処理できる。クライアント・サーバ双方でのこうした並列性の許容は性能とスケーラビリティの提供に不可欠だが、その一方でフィルシステムのメタデータとデータ内容の整合性を保証するための追加要件をもたらす。本節ではLustreの分散ロックマネージャ(LDLM)と、ロック名前空間・ロックリソース・ロック粒度といったその設計の基本要素を紹介する。 **分散ロッキングによる分散整合性**。LDLMはフィルシステム全体にわたる共有リソースへの一貫したアクセスを管理する。LDLMはファイルやディレクトリへのアクセスを求めるクライアントへロックを付与し、多数のホストが同じデータとやり取りしながらも、アプリケーションに対して常に一貫したデータ・メタデータのビューを提示できるようにする。大規模データセットへの同時アクセスが一般的なHPC環境において、LDLMアーキテクチャは並行する数百万件のロック要求を効率的に処理し、数千クライアント・数PBのデータを持つシステムに対するLustreのスケーラビリティに貢献する。LDLMの設計には、読み取り(共有)・書き込み・排他といった複数のロックモードが組み込まれており、各ロックモードは、同一ファイルの属性・データを多数のクライアントが読み取り・キャッシュする、ファイルの異なる部分へ並行して書き込む、あるいはファイルレイアウトへの変更を行うため他のすべてのロックを排他的にキャンセルするといった、許容される並行性の種類を制御する。LDLMは待機や変換といったロック状態・遷移をインテリジェントに管理し、リソースアクセスを最適化して遅延を最小化する。これにより単純な読み取りから複雑なデータ操作まで、フィルシステム操作の効率的かつ信頼性の高い実行が保証される。さらにLDLMはクライアント障害の処理でも重要な役割を果たし、生存しているクライアントが中断なく動作を継続できるようにする。クライアントの無応答や通信途絶が長期化した場合、そのクライアントはeviction(クラスタから強制的に排除)され、リソースが解放されて他のクライアントがブロックされていたロックを獲得できるようになる。 **ロック名前空間**。ロック名前空間は、異なるリソース上のロックを分離し、それぞれのリソースのストレージを管理する個々のサーバが独立して扱えるようにする。各MDT・OSTはそれぞれ独自のロック名前空間を持ち、MGTも同様である。クライアントは各ターゲットに対する自身のロックのサブセットを管理する「シャドウ」名前空間を持つ。各名前空間は、自身が持つ特定のローカルリソース群(ファイルやオブジェクトなど)に関連するロックの管理を担う。このアプローチにより、LDLMはフィルシステムが数十億のファイルとPB規模のデータへ拡張していく中でも、数千のサーバにまたがる数百万のロックを効率的にスケールさせ並行管理できる。ロック名前空間(すなわちロックサーバ)の数も、管理対象リソースの数に応じて増加する。クライアントは名前空間内の特定リソースに関連するロックを要求する。クライアントは名前空間全体のリソースすべてではなく、自身が作業中または作業しそうな特定のファイル・ディレクトリ・オブジェクトに対してのみロックを要求する。その結果、各クライアントは現在の操作や関心に関連する部分のみを含む、局所化・簡略化された名前空間のバージョンである「シャドウ名前空間」を維持する(図7参照)。このアプローチにより、サーバや他クライアントの活動によって絶えず変化する名前空間全体のグローバルな状態を追跡する必要がなくなり、クライアント側のオーバーヘッドが削減される。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig7-shadow-namespace.png]] (図7. クライアント上のシャドウ名前空間。§3.3.1) **ロックリソース**。LDLMにおけるロックリソースとは、ロック名前空間内でアクセスの制御・同期が必要な特定のエンティティ(ファイル・ディレクトリ・オブジェクトなど)を指す。各リソースはフィルシステム全体で一意な数値識別子(4つの64ビットフィールドから成る)を持つ。なおLDLM層は、ロック対象となるリソースの性質そのものには特定の解釈を与えず、リソースの性質を考慮せずにロックを管理する。多くの場合、リソースの最初の3フィールドは、MDTまたはOST上の個々のオブジェクトのFIDトリプレット(Sequence, OID, Version)にマッピングされ、MDTディレクトリの場合はファイル名のハッシュが4番目のフィールドに拡張される。設定レコードやクォータ上限といった非オブジェクトリソースをロックする場合は、意図しない衝突を避けるためFIDとは別の数値空間が使われる。各リソースは自身のロックを独立に管理し、単一のリソース上に1つまたは多数の個別ロックが存在しうる。単一のファイル・ディレクトリリソースにはしばしば1つのロックしかない場合もあれば(例: 新規作成された単一ストライプファイルへの単一プロセスの書き込み)、単一のリソース上に数千のロックが存在する場合もあり(例: 全クライアントがアクセスするフィルシステムルートディレクトリ)、対応する数のOSTオブジェクトへストライピングされているため単一ファイル自体が(それぞれ数千のエクステントロックを持つ)数千のリソースを持つこともある。複数のロックが単一リソース上で共存できるのは、互換性のあるロック種別を持つ場合(後述)、またはリソースの重複しない領域(エクステントやビット)をロックしている場合である。名前空間内のリソースにはリソース間の順序が本来存在しないため、効率的なリソースルックアップを行うためスケーラブルなハッシュテーブルで管理される。 **ロック粒度**。LDLMのロッキング方式は、フィルシステムリソースへのアクセスを効率的に管理するため、細粒度と粗粒度の両方のロックを含む。細粒度ロックは、個々のファイル、ファイルの一部、単一ディレクトリ内のファイル名など、並行してアクセス・変更されうるリソースを対象とする。細粒度ロックにより、同一または異なるリソースに対する複数の操作を並行して進めることができ、競合を大幅に削減し性能を向上させる。粗粒度ロックは、フィルシステム設定レコードのように効果的に細分化できないリソースを対象とする。粗粒度ロックは必要なロック数を減らすことでロック管理を単純化する。ロックの粒度は、LDLMにおける各種のロックタイプとロックモードによって実現される。LDLMのロックは6つのロックモードと4つのロックタイプを持つ。 **ロックモード**: 表2は6つのロックモードの名称、付与されるアクセス、意味を要約する。 | モード | 名称 | 付与されるアクセス | 意味 | |---|---|---|---| | EX | Exclusive(排他) | RW | 他のプロセスはRアクセスもWアクセスも得られない | | PW | Protected Write(保護付き書き込み) | W | 他のプロセスはWアクセスを得られない | | PR | Protected Read(保護付き読み取り) | R | 他のプロセスはWアクセスを得られない | | CW | Concurrent Write(並行書き込み) | W | 他のプロセスへの制限なし | | CR | Concurrent Read(並行読み取り) | R | 他のプロセスへの制限なし | | NL | Null | なし | リソースへの関心を示すのみ | - **EX(Exclusive)モード**: 単一ホストによるリソースへの排他アクセスを保証し、そのリソース上の他のすべてのロックがキャンセル済みであることを確実にするために用いられる。メタデータやフィルシステム構造の変更を伴う操作に特に適用される。例えば新規ファイル作成時、MDSは親ディレクトリのFIDとファイル名ハッシュで識別されるリソースにEXロックを開始し、同じディレクトリ内で他のプロセスが同時に同名のファイルを作成(または削除)しないようにする。 - **PW(Protected Write)モード**: 並行する読み取り操作が不整合なデータへアクセスしないことを保証しながら書き込み操作を進めるためのモード。クライアントがOSTオブジェクトへデータを書き込む要求を出す際、通常は書き込み対象となるファイルの(少なくとも)エクステントに対してPWロックが付与される。 - **PR(Protected Read)モード**: 読み取り中のデータが不整合や破損につながる形で並行して変更されないことを保証するために、読み取り操作へ付与されるロック。クライアントがファイルを読み取りまたは実行のために開く場合を含む。PRロックは複数クライアントによる同一リソースからの並行読み取りを許可しつつ、読み取りデータの整合性に影響しうる書き込み操作から保護する。 - **CW(Concurrent Write)モード**: Lustreのストライプレベルロッキングと書き込みシリアライゼーション機構によって制御されつつ、複数クライアントがリソースの異なる部分へ同時に書き込むことを可能にするモード。OST固有のポリシーとクライアント側のキャッシュ戦略を通じたアクセス調整によりデータ整合性を確保し、並行書き込みを最適化する。 - **CR(Concurrent Read)モード**: ファイルやディレクトリのlookupなど、データを変更せずに読み取る操作に用いられるモード。クライアントがパスlookupを実行する際、MDSはパスの必要なコンポーネントに対してCRロックを付与する。このロックモードにより、複数クライアントが競合なく同一リソースから同時に読み取れる。 - **NL(Null)モード**: LDLM内のプレースホルダまたはマーカーとして機能するモード。ロック要求が確認されたが、特定のアクセス権限は付与されていないことを示す。ロック要求の存在の追跡や、LDLM内部の特定の管理タスクに有用である。これら6つのロックモードを用いて、ロックの共存可否を判定するための互換性マトリクスが構成される。表3はこの互換性マトリクスを示し、0は非互換、1は完全な互換を意味する。図8はロックレベルの severity(厳格さ)を示しており、EXが最も厳格でNLが最も緩やかである。 | | EX | PW | PR | CW | CR | NL | |---|---|---|---|---|---|---| | EX | 0 | 0 | 0 | 0 | 0 | 1 | | PW | 0 | 0 | 0 | 0 | 1 | 1 | | PR | 0 | 0 | 1 | 0 | 1 | 1 | | CW | 0 | 0 | 0 | 1 | 1 | 1 | | CR | 0 | 1 | 1 | 1 | 1 | 1 | | NL | 1 | 1 | 1 | 1 | 1 | 1 | ![[_attachments/survey-2025-lustre-unveiled/ch03-fig8-ldlm-lock-severity.png]] (図8. LDLMにおける各ロックモードのlock severity。§3.3.1) **ロックタイプ**: LDLMで定義される4種のロックタイプはExtentロック、Flock、Inodebitロック、Plainロックである。 - **Extentロック**: OSTオブジェクト内の特定のデータ範囲へのアクセスを管理し、複数クライアントによるOST上のデータの安全かつ並行なアクセス・変更を保証する。Extentロックの粒度はオブジェクトの個々のバイト単位だが、実際にはLinuxページキャッシュがページ単位でしか粒度を管理できないため、Extentロックは4KiBまたは64KiB境界の倍数に整列・サイズ調整される。単一のリソース(OSTオブジェクト)は一度に数千のExtentロックを持ちうるため、これを効率的に扱う必要がある。Extentロックは区間木(interval tree)を用いて、オブジェクト上のカバー領域によってロックを順序づけ、ロックエンキュー時の競合チェックにおいて重複するエクステントを効率的に検出できるようにする。Extentロックのエンキュー時、クライアントは直後に読み書きしようとしているオブジェクトのバイト範囲を要求するが、ロックサーバ(OSS)は現時点で競合がなければ、将来のロック要求数を減らすため、オブジェクトのより広い範囲(アドレス可能な全範囲まで)へ機会主義的にエクステントロックを拡大することがある。 - **Inodeロック(Inodebits/ibits)**: ファイル・ディレクトリのメタデータ属性へのアクセスを制御し、MDT上に格納されたメタデータを保護し一貫したメタデータ操作を保証する。Inodeロックの各ビットは、ディレクトリ内のファイル名lookupの可否、ファイルアクセス権限、ファイルレイアウト、拡張属性、Data-on-MDT(DoM)といった、キャッシュ・変更されうる異なる属性を表す。単一のリソース(MDT inode)は一度に数千のInodebitロックを持つことがある。リソース上のとりうるビット数は比較的少ないため、スキップリストを用いて個々のロックを同一ビットのリストへ分類し、ロックエンキュー時の効率的なチェックを可能にしている(各リストの1つのロックとのみ競合をチェックすればよく、すべてのロックと照合する必要がない)。Extentロックと同様、クライアントは操作(例: ファイル名のlookup)に必要な最小限のビットを要求するが、サーバ(MDS)は競合のないリソースについて追加のビット(例: xattrキャッシュ)を機会主義的に付与し、将来の要求を最小化することがある。 - **Flock(ファイルロック)**: POSIXのファイルロッキングセマンティクスを実装し、ファイルに対するアドバイザリロック操作のユーザ空間からの要求をサポートすることで、従来のファイルロック機構に依存するアプリケーションとの互換性を実現する。flockロッキングの使用はファイルデータの内部整合性には影響しない。Extentロックと同様、flockロックは区間木を用いてファイル領域によってロックを順序づけ、エンキュー時の効率的な競合検出を可能にする。 - **Plainロック**: LDLMロッキングの最も原始的で単純な形式であり、リソース上に単一のロックのみが必要となる場面に適する。用途にはMGS設定ログやクォータレコードのロックが含まれる。 ## Lustreネットワーキング(LNet) Lustreのネットワーキング層であるLNetは、クライアントとストレージサーバ(OSS、MDS、MGS)の間、およびサーバ間の通信を担う。メッセージの送受信、接続の管理、効率的なデータ転送を行う責務を持つ。LNetは下位のネットワークを抽象化し、InfiniBand、Ethernet、OmniPathなどさまざまな種類のネットワーク上でLustreを動作させられるようにする。LNetの主要な設計原則は以下のとおりである。 - **スケーラビリティ**: 大規模Lustreデプロイメントの複雑な通信要求を処理できるよう設計されており、多数のLustreクライアント・サーバ間の相互作用を並列かつ分散した形で効率的に管理する。 - **性能**: HPCクラスタに対する高速でスケーラブルなストレージソリューションを提供するというLustreの使命を果たすうえで重要な、高性能向けにチューニングされている。HPC環境の並列I/O操作に不可欠な高速データ転送を難なく処理する。 - **モジュール性**: 本質的にモジュール化されており、ネットワーク抽象化層を使うソフトウェアコンポーネントに変更を加えることなく、多様なネットワークトランスポート群の統合を受け入れられる。 - **信頼性**: マルチレール(MR、§5.1.3)、MRディスカバリ(§5.3.8)、LNetヘルス(§5.2.5)を含む、HPC環境内でのデータの完全性とアクセス可能性を保つために不可欠な信頼性機能を組み込んでいる。 - **互換性**: システム管理者がLustreデプロイメントの特定のニーズに合わせて設定できる手段を提供する。適切なネットワークトランスポートの選択、性能関連パラメータの最適化、下位のハードウェアインフラとの互換性の確保を含む。 **モジュラーアーキテクチャ**。図9に示すLNetのアーキテクチャは、ユーザ空間とカーネル空間のコンポーネントに分かれる。ユーザ空間ではLNetの設定に`lnetctl`ユーティリティが用いられる。`lnetctl`は設定APIを実装するDynamic Library Configuration(DLC)ライブラリとやり取りする。DLCはAPI経由で提供された設定を、カーネル空間のLNet Netlinkコンポーネントが理解するNetlinkプロトコルメッセージへ変換する。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig9-lnet-architecture.png]] (図9. LNetのアーキテクチャ。§3.4.1) もともとDLCプロジェクトの一部であった`lnetctl`は、当初はネットワーク識別子・ピア・ルートといったさまざまなLNetパラメータを設定するために`ioctl`システムコールを使うよう設計されていたが、時間とともに効率性と柔軟性の向上のため変化を遂げ、現在はLinux Netlinkプロトコルを用いている。ユーザはコマンドラインインタフェースを通じて`lnetctl`とやり取りし動的にLNetを設定できるほか、システム起動時に特に有用な構造化アプローチとしてYAML設定ファイルを用いることもできる。加えて`lnetctl`は既存のLNet設定をYAML形式で抽出でき、設定の複製を容易にする。システム初期化中、LNetカーネルモジュールはLNetモジュールパラメータファイルに格納された設定パラメータを読み込む。カーネルモジュールはLNetの設定、およびメッセージの送受信のための独自のAPI群を公開しており、後者はLNetメッセージを管理するPortal RPCカーネルモジュールと統合されている。メッセージ処理のコアロジックはLNetモジュールにあり、Lustre Network Drivers(LNDs)がハードウェア固有のインタフェースとして機能する。代表的なLNDには、TCP/IPおよびTCP/IPv6の両方をサポートするTCPソケットベース通信向けの`socklnd`、MellanoxやOmniPathなどverbsインタフェースをサポートするハードウェア向けの`o2iblnd`、HPEのSlingshotドライバ向けに調整された`kfilnd`、Crayの旧世代GeminiおよびAriesインターコネクト向けの`gnilnd`がある。 **ネットワーク抽象化と柔軟性**。下位のネットワークインフラを効果的に仮想化するため、LNetは4つの主要概念を導入する。 - **ネットワークインタフェース記述子(NID)**: LNetは各ホストをNIDで一意に識別する。NIDはネットワークアドレス・ネットワーク種別・ネットワーク番号から構成され、`<ネットワークアドレス>@<ネットワーク種別><ネットワーク番号>`という形式である。ネットワークアドレスは使用中のLNDに基づいて決まり、`socklnd`ならIPv4/IPv6アドレス、`o2iblnd`ならIPv4アドレス、`gnilnd`なら単なる整数のホスト識別子となる。例えば`o2iblnd`インタフェースは`10.10.10.1@o2ib`のようなアドレスを持ちうる。ネットワーク種別は、`o2iblnd`向けの`o2ib`や`socklnd`向けの`tcp`のように、特定のLNDに対応する仮想ネットワークを分類する。 - **ネットワーク番号**: 同一種別の複数の非ルーテッドネットワークを識別できるようにする。各独立したネットワークはネットワーク種別と番号によって一意に識別され、`tcp0`・`o2ib0`・`ib27`のような形になる。単一のLustreネットワーク内では、ピア同士はルーティングなしで直接通信できる。しかし異なるネットワークに属す2つのホストが通信する必要がある場合は、それらの通信を橋渡しするLNetルータが必要となる。例えば異なる計算クラスタ内部の別々のInfinibandネットワークは、ストレージクラスタと通信するためにLNetルータを必要とする。各種別ごとに最大65535個の独立したネットワークを持てる。 - **ネットワークインタフェース(NI)**: LNet内で各ホストは少なくとも1つの設定済みNIを持つ必要があり、通常は物理ネットワークカードに相当する。ホストに関連付けられた各NIはネットワーク上で一意なNIDを持ち、LNetは設定済みの各NIに対して内部データ構造を維持する。これらの構造には状態・ヘルス・そのNI固有のその他の詳細情報が含まれる。 - **ピア**: LNetメッセージが初めてあるホストから別のホストへ送信される際、必須の識別・状態情報を追跡するためのピア構造が生成される。これには通知されたNID群、NIDのヘルス状態、ルーティング詳細、ホスト間の効率的な通信・調整を助けるその他の重要データが含まれる。図10(a)に示すように、LNetの基本的な機能は、同一ネットワーク上に単一のNIを直接設定した2つのホスト(Node AとNode B)間の通信である。図10(b)に示す基本ケースを超えるシナリオは「ルーテッドシングルホップ」構成と呼ばれ、個々のホストが異なるネットワーク種別上に位置する場合である。Node Aは`o2ib`ネットワーク上にインタフェースを持ち、Node Bは`tcp`ネットワーク上にインタフェースを持つ。これらのホスト間でメッセージ交換を可能にするため、`o2ib`と`tcp`両方のネットワーク上にインタフェースを備えたLNetルータホストが設けられる。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig10-lnet-configurations.png]] (図10. LNetの機能: (a)単一NI種別によるdirect構成、(b)ルーテッドシングルホップ、(c)複数LNetルータによるルーテッドシングルホップ、(d)ルーテッドマルチホップ。§3.4.2) Node A上では、`tcp`ネットワーク宛のメッセージを指定のLNetルータへルーティングするようLNetへ指示するルートが設定される。同様にNode B上でも、`o2ib`ネットワーク宛のメッセージを同じLNetルータへ転送するようLNetへ指示する逆方向のルートが設定される。Node A上のLustreがNode B宛のメッセージを開始すると、LNetはNode BのNIDからネットワーク種別を調べ、`tcp`ネットワーク上に設定済みNIが存在しないことを認識する。その結果、設定済みルートの一覧を参照し、ルートで指定されたルータアドレスへメッセージを転送する。メッセージを受け取ったLNetルータはヘッダを検査して最終的な宛先NIDを判定する。最終宛先NIDがルータホストのローカルNIに対応していれば、ルータはそのメッセージをローカルに処理する。ただしLNetルータは既定ではLustreメッセージを受け付けず、LNet pingやヘルスステータスメッセージなど限られた種類のメッセージのみを扱う。最終宛先NIDがルータのローカルではないが、同一ネットワーク上のローカルNIと一致する場合、ルータはそのネットワーク上へメッセージを転送する。例えばNode AがNode Bの`tcp` NID宛のメッセージを送った場合、ルータは自身の`tcp` NIを認識しそのメッセージを`tcp`ネットワーク上へ転送する。各ホストは、それらのルート内で指定されたルータへ定期的にpingを送ることで、設定済みルートの状態を監視する。ルータが応答すればルートは「up」とみなされ、そうでなければ「down」と判定される。メッセージ転送に利用されるのは「up」のルートのみである。「複数LNetルータによるルーテッドシングルホップ」(図10(c)参照)と呼ばれる別のシナリオでは、それぞれ独自のルーティング設定を持つ複数のLNetルータが設けられる。このシナリオでは、Node AとNode Bはそれぞれ異なるルータを指す複数のルートを設定できる。各ルートには優先度を割り当てることができ、同じ優先度のルートはラウンドロビン方式で利用され、優先度が異なる場合は最も優先度の高いルートが選ばれる。最後に「ルーテッドマルチホップ」(図10(d)参照)は前述のシナリオに似ているが、Node AとBの間に複数のルータホストが介在する点が異なる。Node AとBの視点からは処理ロジックに実質的な違いはない。設定済みルートは各ノードから到達可能な直近のルータを指し示し、LNetルータ側では、それぞれの直接の到達範囲を超えたネットワークへメッセージを転送できるよう追加のルートが設定される。 **ネットワークメッセージング概念**。LNetはそのネットワークメッセージング設計において特有の用語を用いる。Portal(ポータル)は、着信・発信メッセージを分類・管理するゲートウェイとして機能する論理的なエンティティである。各ポータルは特定の種類の通信やサービスに関連付けられる。制御メッセージ・データ転送・メタデータ操作といった異なる種類のネットワークトラフィックを別々のポータルへ割り当てることで、LNetはネットワークメッセージを正しいハンドラへ多重分離・ルーティングできる。これにより受信側でメッセージをキューイングし優先順位づけできる。 ![[_attachments/survey-2025-lustre-unveiled/ch03-fig11-lnet-message-entities.png]] (図11. LNetメッセージ処理エンティティの概要。MEとMDはそれぞれmatching entry〔マッチングエントリ〕とmemory descriptor〔メモリディスクリプタ〕を表す。§3.4.3。原本ch-03.txtは本図に対応する説明本文がPortalの定義の途中でページ送りにより途切れており、キャプション以上の詳細は原本テキストに現れない) ## 関連 - [[@2025__TOS__Lustre Unveiled - Chapter 2 The Lustre Filesystem]] — 前章。Lustre全体のアーキテクチャ概観とMDS/OSS/OSTの基本用語を扱う。 - [[@2025__TOS__Lustre Unveiled - Chapter 4 A Comparative Study of Lustre versus Related Storage Technologies]] — 次章。他のストレージ技術との比較。 - [[Lustre Unveiled]] — 本書のハブentity。 - [[wiki/entities/Lustre|Lustre]] — Lustre本体のentity(パス修飾リンク。`notes/system-engineering/Lustre.md` との衝突回避)。