# Lustre Unveiled - Chapter 2: The Lustre Filesystem > 前: [[@2025__TOS__Lustre Unveiled - Chapter 1 Introduction]] | 次: [[@2025__TOS__Lustre Unveiled - Chapter 3 Architectural Details of Lustre]] | 全体: [[Lustre Unveiled]] ## 要約 第2章は、Lustre の本体解説に入る前の導入章にあたる。§2.1 でアーキテクチャの主要コンポーネントとその用語を定義し、§2.2 で Lustre の開発を導いた設計原則とそこから派生した10の主要機能を整理し、§2.3 で 1990年代末の発端から 2010年代後半までの HPC への貢献を略史として辿る。より詳細なアーキテクチャは第3章、詳細な歴史は付録 A で扱われる(章冒頭の記述による)。 ## アーキテクチャ概要と主要コンポーネント Lustre のアーキテクチャは、サーバによって管理され、ネットワーク越しにクライアント計算機からアクセスされる、分散オブジェクトベースストレージフレームワークの上に構築されている。サーバは 2 つの機能を提供する。メタデータサーバ(MDS)はファイルシステムの名前空間・アクセス制御・初期のデータオブジェクト割り当てを管理し、オブジェクトストレージサーバ(OSS)はファイルのストレージ空間割り当てと実データの格納を担う。Lustre では、1 ファイルはメタデータオブジェクト 1 個とデータオブジェクト 1 個以上から構成される。メタデータオブジェクトはメタデータターゲット(MDT)に、データオブジェクトはオブジェクトストレージターゲット(OST)にそれぞれ格納される。さらに、サーバ・クライアント・ストレージターゲット・ファイルシステム構成パラメータを追跡する専用の管理サーバ(MGS)が存在する。 クライアントは 1 つ以上の MDT からメタデータ名前空間を、1 つ以上の OST からオブジェクトデータを集約し、アプリケーションからアクセス可能な一貫した POSIX ファイルシステムを構成する。クライアントはバックエンドファイルシステムやストレージへ直接アクセスすることはなく、すべての I/O 操作はネットワーク経由でサーバによってある程度調停される。Lustre クライアントソフトウェアは I/O 操作をメタデータとブロックデータに分割し、それぞれ適切なサービスと通信することで、小さくランダムな IOPS 主体のメタデータトラフィックと、大きく帯域主体のストリーミングブロック I/O とを効果的に分離する。この設計により、アプリケーションのニーズに応じてメタデータ性能とデータ性能・容量を独立にスケールできる。 ![[_attachments/survey-2025-lustre-unveiled/ch02-fig1-lustre-architecture.png]] (図1. 基本的なクラスタにおける Lustre のアーキテクチャと構成要素。§2.1) 主要コンポーネントは以下のとおりである。 - **管理サーバ(MGS)**: 全アクティブサーバ・クライアントに関わる構成情報とファイルシステムレジストリを扱うホスト。永続的な構成情報を管理ターゲット(MGT)というブロックデバイス上に保存し、クライアントとサーバへ提供する。マウント時にクライアントは MGS へ接続し参加サーバやネットワーク識別子などの構成を取得する。MGS はマウント後の構成変更もクライアントへ通知し、サーバ障害・再起動時の復旧手続きでも重要な役割を持つ。MGT が必要とするストレージは通常 1GB 以下と小さく、先頭の MDT と共有することもできる。1 サイトに複数の MGS ノードを置けるが、あるファイルシステムを管理する MGS は常時 1 つのみである。1 つの MGT を複数の MGS ノードで共有し、HA(高可用性)と MGS フェイルオーバーを実現することもできる。 - **メタデータサーバ(MDS)**: 名前空間を管理し、クライアントへメタデータサービスを提供するホスト。この名前空間にはディレクトリ・ファイル名の階層と、所有者・グループ・プロジェクト識別子・作成時刻・アクセス/更新時刻・アクセス権・拡張属性などのメタデータオブジェクトが含まれる。MDS はファイル・ディレクトリの作成/削除、ファイルデータオブジェクトの割り当て(データ管理自体は通常担わない)、権限管理などのメタデータ操作を統括する。Lustre は常に最低 1 つの MDS を持つが、多数のクライアントが数百万の小ファイルを作成・アクセスするような高負荷ワークロードでは、追加の MDS ノードを投入して性能を改善できる。この構成は MDS 間のフェイルオーバーによる HA の利点もあわせ持つ。1 つの MDS が複数の独立したファイルシステムのストレージを管理することも可能である。 - **メタデータターゲット(MDT)**: MDS がメタデータ情報を格納するために利用する論理ストレージターゲット。通常ファイル・ディレクトリ・シンボリックリンク・特殊ファイルごとに一意な MDT inode を用いる。inode は通常のファイル属性に加え、ファイルデータブロックへの直接参照ではなく 1 つ以上の OST オブジェクトを参照するレイアウトを拡張属性として保持する。Lustre は常にファイルシステムのルートディレクトリを保持するプライマリ MDT を最低 1 つ持つが、複数の MDT を用いて名前空間を分割し容量と性能を高めることもできる。一般的には MDS サーバ 1 台につき MDT 1 個の構成だが、1 つの MDS が複数の MDT を管理することも可能である。これらの MDT は複数の MDS ノード間で共有しハードウェア障害時の可用性を高められるが、各 MDT を同時にマウントできる MDS は常に 1 つのみである。 - **オブジェクトストレージサーバ(OSS)**: ファイルデータオブジェクトを管理し、オブジェクト属性とデータ内容を Lustre クライアントへ公開することでアクセスを調停するホスト。典型的な Lustre ファイルシステムでは複数の OSS ノードを用いて集合的に高いネットワーク帯域と追加ストレージを提供する。OSS ノードは複数クライアントからの並列で整合性のある書き込みを 1 つ以上の OST オブジェクトに対して受け付け、計算クラスタ全体に分散したクライアントプロセスによる非常に大きなファイルの作成と並列アクセスを可能にする。 - **オブジェクトストレージターゲット(OST)**: OSS がファイル内容を格納するために利用する論理ストレージターゲット。通常 1 つの OSS が複数の OST を管理し、ストレージ容量とデータ並列性を高め、耐障害性を改善する。デュアルアタッチドライブや SAN(Storage Area Network)といった特殊構成を用いれば、複数の OSS ノードから共有アクセスすることもできる(この場合 1 つの OSS がアクティブサーバ、残りがスタンバイサーバとして待機する)。ただし MDT と同様、各 OST を同時にマウント・アクセスできる OSS は 1 つのみである。各ファイルは 1 つ以上の OST オブジェクトから構成され、MDT 上のメタデータ inode に格納されたレイアウトに応じて、複数の異なる OST にまたがって分散配置できる。Lustre ファイルシステムは最低 1 つの OST を持ち、追加の OSS ノードや OST を組み込むことでストレージ容量・性能をスケールできる。ファイルシステム全体の総ストレージ容量は、全 OSS ノードに接続された全 OST の容量の合計である。 - **オブジェクトストレージデバイス(OSD)**: ストレージデバイスへのアクセスを管理する、Lustre ストレージスタック内の下位層ソフトウェア抽象化層。OST・MDT・MGT のようなストレージターゲット(単なるブロックデバイスのパーティションや論理ボリューム)とは区別される。OST と MDT(および任意で MGT)は、バックエンドファイルシステムと呼ばれるローカルディスクファイルシステムでローカルブロックストレージデバイスを管理する。この橋渡しのため、OSD API はバックエンドファイルシステム内のオブジェクトへアクセスするための抽象化層をサーバに提供し、その実装はファイルシステムの種類ごとにカスタマイズされる。現在は ldiskfs(Linux ext4 の最適化版)と OpenZFS の両方がバックエンドファイルシステムとしてサポートされている。OSD API は属性・データ・拡張属性ストレージ向けのオブジェクトアクセス、ディレクトリ用のインデックスインタフェースとその他の Lustre 状態管理用キーバリューテーブル、復旧用のアトミックなマルチオブジェクトトランザクション、トランザクションの永続化を通知する非同期コミットコールバック、クォータ用の空き容量アカウンティング・管理を提供する。OSD API は将来的な他バックエンドファイルシステムの利用も可能にしており、実際 ReiserFS と BTRFS 向けの OSD インタフェースが一時実装されたが後に放棄された。ブロックサイズ・最大ファイルサイズ・利用可能機能などバックエンドファイルシステムの一部詳細は、性能と空間管理の最適化のため OST・MDT・クライアントへ公開される。管理目的でファイルシステムのリサイズや fstrim といったバックエンドファイルシステムの追加機能を公開する「パススルー」インタフェースも存在する。 - **Lustre クライアント**: ユーザアプリケーションとサーバ上のメタデータ・データとの橋渡しを担う。POSIX 準拠の名前空間と I/O インタフェース、および非 POSIX の拡張機能を提供する。アプリケーションは標準の POSIX システムコールを用いれば Lustre 固有のコーディングを必要としない。1 台のホスト(仮想マシンやコンテナでもよい)上で従来型のマウントポイントを介して 1 つ以上のファイルシステムへアクセスでき、1 つのファイルシステムに数百〜数万のクライアントが同時にアクセスすることも珍しくない。Lustre クライアントは各 MDS・OSS と直接通信し、異なるサーバとのやり取りは並行に行われる。この並列化はクライアントワークロードを複数サーバへ分散させ性能を最大化するうえで重要である。非並列ファイルシステムでは、メタデータやデータのホットスポットがサーバ間の性能不均衡を招き、クライアント性能を低下させうる。 - **Lustre ネットワーキング(LNet)**: Lustre クライアントは LNet プロトロコル経由でネットワーク上のファイルシステムへ接続し、クライアント・サーバ間の通信を仲介するとともに、下層のネットワークプロトコルとインタフェースの詳細を抽象化する。LNet は低レイテンシネットワーク上での RDMA(Remote Direct Memory Access)による高効率・高性能なデータ転送を実現し、多様なネットワーク環境間のルーティングを可能にする。これにより Lustre は、すべての I/O トランザクションがネットワーク RPC 経由で実行されるネットワーク中心のファイルシステムとして機能できる。LNet は標準的な InfiniBand・Ethernet(TCP/IP)・Omni-Path から、スーパーコンピュータで用いられる独自の高性能ネットワークまで多様なネットワーク技術に対応する。 MGS・MDS・OSS のノード群は集合的にファイルシステムのストレージクラスタを構成する。図1 は基本的なストレージクラスタ内の Lustre コンポーネントを簡略化して示したものであり、この図では MGS を MDS と別に描いているが、実際には多くのファイルシステムで MGS と MDS を単一のホストマシンに統合するのが一般的であり、MGT がプライマリ MDT と同一のブロックデバイス上に共存する場合もある。 ## 設計原則と主要機能 Lustre の設計は、スケーラビリティ・性能・レジリエンス・ユーザビリティ・互換性という 5 つの主要原則に動機付けられている。 - **スケーラビリティ(Scalability)**: 増大し続ける需要(アプリケーションクライアント数、データストレージ容量、ファイルシステムエントリ数、ストレージサーバ/デバイス数など)に対応してファイルシステムを成長させる能力。需要が増えてもコア設計を変えずに済むアーキテクチャがスケーラブルとされる。 - **性能(Performance)**: ストレージデバイス・サーバマシン・ネットワークといった構成資源の集約的な能力を、多様なアプリケーションクライアントに届ける能力。多くの場合、大規模ストリーミング I/O については帯域(バイト/秒)、小さな I/O 操作とメタデータアクセスについては最小レイテンシと高スループットで測られる。並列ファイルシステムとして、Lustre は高頻度の並行 I/O・メタデータ操作を生む並列アプリケーションでの性能を特に重視する。 - **レジリエンス(Resilience)**: 構成資源に一時的または継続的な障害条件が生じても正しく動作し続ける能力。信頼性(Reliability)・可用性(Availability)・保守性(Serviceability)(まとめて RAS)の各側面を組み合わせた一般的な性質である。信頼性は構成要素が故障して観測可能な誤動作を招く確率、可用性は障害条件によってファイルシステムがクライアントへサービスできなくなる時間の割合、保守性はシステムを稼働状態へ復旧させるまでの速さを表す。 - **ユーザビリティ(Usability)**: システムを利用・管理する人々(ユーザと管理者)に「良い」体験を提供することに焦点を当てた抽象的な原則。管理者向けのユーザビリティ機能は、しばしば「マネージャビリティ(Manageability)」の改善として分類される。柔軟性(Flexibility)は、ユーザ入力や管理者が与える構成に基づいて挙動を変えられる能力を指すユーザビリティの一形態である。 - **互換性(Compatibility)**: コンプライアンス(Compliance)・ポータビリティ(Portability)・相互運用性(Interoperability)の各側面を組み合わせた一般的な原則。コンプライアンスは確立された標準や慣行への準拠能力、ポータビリティは多様な構成資源を利用できる能力、相互運用性は外部のシステム・サービス・資源と統合できる能力を指す。 これらの原則に動機付けられた主要機能は以下の10点である。 1. **データとメタデータの分離(スケーラビリティ・性能・レジリエンス)**: MDS と OSS という 2 種類のストレージサービスにデータとメタデータの管理を分離する。MDS はより多くの CPU・RAM 資源と高 IOPS ストレージを持つノードでファイル作成・削除・ディレクトリ検索などのメタデータ操作を扱い、OSS は通常高帯域なストレージでファイル I/O 操作を管理する。この分離により、各ノード・ストレージ種別が特定タスクに最適化されボトルネックを防ぎ、システム性能が向上する。MDS/OSS ノードを追加するだけでワークロード増大にほぼ線形にスケールでき、メタデータワークロードを複数の MDS ノードへ分散させることでストレージ容量とは独立にスケールできる。MDS 障害時は別の MDS が当該 MDT の管理を引き継ぎ、継続的な運用を維持する。 2. **オブジェクトベース設計(スケーラビリティと並列性能)**: 各ファイルのデータを 1 つ以上の OST に格納し、下層のストレージ技術とその管理をクライアントから抽象化する。クライアントは新規ファイル作成時に MDT を選び、対応する MDS へ inode 割り当てを要求する。MDS は作成時点でファイルレイアウトを組み立てて MDT inode の拡張属性として保存し、実データを格納する OST オブジェクトを 1 つ以上割り当てる。各 OSS が自身のオブジェクトを独立に管理するため、低レベルのブロック割り当ての詳細を OSS ノード自身が扱える。この分散配置により、ファイル I/O 操作時の中央集権的な競合点を回避し、伝統的なファイルシステムに共通するボトルネックを排除しつつ、単一ファイル内オブジェクトの並列 I/O も可能になる。異なる OST へオブジェクトを配置することで実行時の動的な負荷・空間バランシングや、ワークロードに適したストレージ種別(HDD・SSD など)の選択も可能になる。 3. **データレイアウト(並列性能・ユーザビリティ・スケーラビリティ)**: ファイルのレイアウトとは、ファイルデータが 1 つ以上の OST へマッピングされるパターンを指す。レイアウトは 1 つ以上のコンポーネントから構成され、各コンポーネントはファイルオフセットの範囲を対応する OST オブジェクトオフセットの範囲(ストライプとも呼ぶ)へマッピングする。1 つのコンポーネントは、帯域向上や空間使用量のバランシングのため RAID-0 的に複数の OST オブジェクトにまたがってストライピングされうる。このオブジェクト分散により並列 I/O が可能になり、ファイル I/O 発生時に複数のストライプを異なる OSS ノードが独立に扱うことで並行してアクセス・更新できる。この並列性は複数クライアントによる大ファイルアクセス時の I/O スループットを大きく高め、単一 OST 上でキューイングするのではなく複数の読み書き操作を同時に実行できるためシステム全体の帯域も改善する。ファイルレイアウトはオブジェクトベースアーキテクチャと整合し、OST を追加するだけで水平方向にスケールできる。またファイルごとに異なる OST オブジェクトからなる一意なレイアウトを用いることで、頻繁なメタデータ更新なしに小ファイル・大ファイルの両方を柔軟に負荷分散できる。 4. **分散名前空間(スケーラビリティと性能)**: ディレクトリとファイル、その属性からなる論理構造である名前空間を複数の MDT にまたがって分散させる。単一の MDS が名前空間全体を管理するとボトルネックとなり性能・容量のスケーラビリティを制限しうるため、名前空間はディレクトリレベルで分割され複数の MDS ノードによって管理される。各 MDT が名前空間の一部を保持することでメタデータワークロードを分散し、単一サーバへの負荷を減らす。システムの規模・複雑さが増すにつれ MDS ノードと MDT ストレージを追加でき、ファイル・ディレクトリ数が数百億に達しうる大規模システムでの効率的な管理を支える。単一のディレクトリを複数の MDT にまたがってストライピングし、数千万ファイルを含むディレクトリでの並行ワークロードの性能・容量を改善することもできる。 5. **ネットワーク抽象化層(性能・互換性・ユーザビリティ)**: LNet はネットワーキング層として、Lustre のコアファイルシステム操作を下層のネットワークハードウェアから切り離す抽象化層であり、InfiniBand・Ethernet・OmniPath といった一般的なネットワーク種別や、Cray Gemini・Bull BXI・HPE Slingshot などベンダー固有のネットワークにも対応する。この柔軟性は、性能特性やコスト効率の要求が異なる多様な HPC 環境への Lustre 展開に不可欠である。LNet のアーキテクチャは高度にモジュール化されており、新しいネットワーク技術の登場にも適応できる。これにより主要な HPC 技術・インフラとのシームレスな統合も促進される。さらに LNet はネットワーク種別ごとに通信プロトコルを最適化し、HPC 環境での高性能維持に不可欠な効率的なデータ転送とレイテンシ最小化を図る。LNet の設計には RDMA のような先進的なネットワーキング機能への対応も含まれており、クライアント・サーバ両方の CPU オーバーヘッドを抑えた効率的な低レイテンシデータ転送によりさらに性能を高める。 6. **フェイルオーバー機構(レジリエンス)**: ハードウェア・ソフトウェア障害発生時にも可用性と信頼性を確保するよう設計されており、継続的な運用の維持に不可欠である。この機構は MGS・MDS・OSS・クライアントに組み込まれている。サーバ障害発生時、アーキテクチャは事前設定されたスタンバイまたはセカンダリサーバへサービス責任をシームレスに移行できる。MGS は移行後、当該ストレージターゲットを管理する新サーバをクライアントへ通知する。このフェイルオーバー処理はアプリケーションに対して透過的であり、ダウンタイムを最小化しデータへのアクセスを維持するよう設計されている。MDS についてはファイル名検索やディレクトリアクセスなどのメタデータ操作が、当該 MDT を管理する MDS に問題が生じても中断なく継続する。OSS についても同様に、障害を起こしたサーバ上のデータをアプリケーション中断なしに別サーバからアクセスできる。このサーバ役割の冗長性は Lustre の信頼性の基本であり、単一障害点に対する堅牢な防御を提供する。さらにフェイルオーバー処理にはデータ整合性チェックと同期の機構も含まれ、移行中にデータの喪失・破損が起きないようにする。 7. **クライアントキャッシュ(性能とスケーラビリティ)**: クライアント側キャッシュにより、頻繁にアクセスされるデータ・メタデータをクライアントの RAM に保持できる。ファイル読み取り時にそのデータと属性をローカルにキャッシュすれば、同じデータ・属性への以降の読み取りはサーバへのリクエストを必要とせず、読み取りレイテンシとネットワーク競合を大きく低減する。書き込み操作については、他のクライアントが同じデータへアクセスしていない限り、データをまずクライアントの RAM に格納し後で OST へ書き戻すライトバックキャッシュを利用できる。これによりクライアントは複数の小さなアプリケーション書き込みをより少数の大きな書き込みへ集約でき、ネットワーク帯域の利用とストレージメディアの効率を高める。 8. **POSIX 準拠(ユーザビリティと互換性)**: POSIX 標準への準拠により、POSIX ファイルシステムインタフェースに依存する既存の多種多様なアプリケーション・ソフトウェアエコシステムとシームレスに連携できる。この互換性は、現行のソフトウェア基盤を刷新することなく Lustre の高性能能力を活用したい組織にとって特に重要である。ユーザ・管理者にとっては馴染みのあるインタフェースにより学習曲線が大幅に緩やかになり、他の POSIX システムで培ったスキル・知識をそのまま Lustre へ転用できる。POSIX 準拠はファイル操作の予測可能で一貫した挙動も意味し、標準的なファイルシステムセマンティクスに依存する開発者・ユーザにとって不可欠である。この一貫性により、他の POSIX 準拠ファイルシステム向けに開発されたアプリケーションへの多大な投資が、分散・並列という性質にもかかわらず Lustre 上でも正しく機能する。Lustre 自体は完全に POSIX 準拠であり、アクセス時刻更新に関するごく限られた例外を除き、ローカルの ext4 ファイルシステムと同じ POSIX ユニットテストに合格できる。 9. **オープンソース・コミュニティ主導開発(ユーザビリティと互換性)**: GNU General Public License の下でライセンスされたオープンソースソフトウェアプロジェクトとして、Lustre は開発者・研究者・エンドユーザからなるグローバルコミュニティの多様な専門知識と視点の恩恵を受けている。この幅広い協働は継続的な革新のアイデアと解決策の流入を生む。例えば学術・商用双方の背景を持つ開発者が、それぞれの専門知識を活かして修正・改善・新機能・最適化を貢献できる。この共同体的な知性のプールが開発・問題解決のペースを加速し、Lustre が HPC 領域における新興技術や変化するユーザニーズへ迅速に適応することを可能にしている。さらにコミュニティ主導開発は、より動的で反復的な開発プロセスを促す。開発者は新機能を迅速にプロトタイプし、幅広いユーザ基盤から即座にフィードバックを得て、これらの機能を短いサイクルで洗練できる。 10. **多様な領域への適応性(ユーザビリティと互換性)**: Lustre の適応性はその汎用的なアーキテクチャに根ざしており、従来型 HPC からクラウドベース・ハイブリッドシステムまで幅広いコンピューティング環境への展開を可能にしている。この柔軟性は LNet が多様なハードウェア・ネットワーク構成と統合できる点にも表れている。この適応性は、数百の CPU コア・数テラバイトの RAM・GPU を備えた多様なクライアント計算ハードウェアの性能特性とも統合でき、既存の計算基盤への組み込みを促進する。この互換性は SMB(Server Message Block)や NFS(Network File System)といった多様なファイルアクセスプロトコル・API のサポートにも及び、異なる領域のユーザが既存のワークフロー・アプリケーションに沿った形で Lustre と相互作用できるようにする。さらに、Lustre の相互運用性はマルチプラットフォーム環境における重要な利点であり、データセンタ内や広域ネットワークを越えたアプリケーション・システム間のシームレスなデータ交換・協働を可能にする。これは、データが多様な計算プラットフォーム間で共有される多くの研究・商用の現場で不可欠な要件である。 ## 大規模計算への貢献(略史) Lustre の歩みは 1990 年代末、HPC クラスタ環境に適した、より高いスケーラビリティと効率性を持つファイルシステムへの需要から始まった。当時 Carnegie Mellon University のシニアサイエンティストであった Peter J. Braam 博士が、研究プロジェクトとして Lustre を開始した。2000年代初頭、Braam はスタートアップ Cluster File Systems(CFS)を設立し、当時のファイルシステムにとって想像もできない規模だった数万ノード・ペタバイト級データをサポート可能なスケーラブルなファイルシステムとして Lustre を開発した。Lustre は AFS・Coda・InterMezzo・GPFS などの分散・共有ストレージファイルシステムから着想を得ており、初期の設計目標は、柔軟なストレージデバイス利用、一貫したキャッシュ統合、適応性、最適なインターコネクト利用、POSIX 整合性、信頼領域内での安全な運用、障害へのレジリエンス、最小限の中央集権的制御による効率的かつ独立なスケーリングを重視していた。 Lustre の初期開発は、米国エネルギー省(DOE)の Accelerated Strategic Computing Initiative(ASCI)Path Forward プロジェクトによって資金提供された。ディスク上のストレージ管理に Linux ext2 ファイルシステムを活用し、Lustre は Object-Based Disk Filesystem(OBDFS)のプロトタイプから分散クラスタファイルシステムへと進化した。この過程には米国の国立研究所群と国防総省(Department of Defense)の重要な貢献があった。Lustre は 2003年3月、Lawrence Livermore National Laboratory(LLNL)の MCR クラスタ(1,152 計算ノード・2 台の MDS・64 台の OST から構成、2003年6月時点で Top500 第3位)で本番稼働を開始した。CFS による Lustre 1.0 の初版リリースは 2003年12月であり、Pacific Northwest National Laboratory(PNNL)、Sandia National Laboratory(SNL)、National Center for Supercomputing Applications(NCSA)、Los Alamos National Laboratory(LANL)の大規模本番クラスタへ速やかに展開され、画期的な I/O 性能を示した。発足当初から GNU GPL の下でリリースされ、無料での利用・改変が継続的に保証されている。初期の Lustre リリースには、より迅速な展開を狙った簡略版「Lustre Lite」も導入された。Lustre 1.0 は当時の上位5スーパーコンピュータのうち4台に展開され、11.1GB/s のスループットを達成した。2004年末までに、LLNL の 4,000-CPU クラスタや、約25,000の Lustre クライアントを持つ SNL の Red Storm、Oak Ridge National Laboratory(ORNL)の Jaguar システムなど、複数の HPC サイトで稼働していた。 2006年までに、Lustre は複数プラットフォームと互換性を持ち商用製品にも組み込まれる、極限 HPC 環境向けの選好されるファイルシステムとして台頭した。LLNL の最上位機 IBM BlueGene/L を含む、世界の上位30台のスーパーコンピュータのうち10台を支えるまでになった。以降のリリースでは InfiniBand RDMA ネットワークサポート、クライアント CPU アーキテクチャ互換性の拡張、ノードあたり複数ネットワークインタフェース(NI)対応など、複数の機能強化が導入された。これらのリリースはエクステントベースの割り当てとクォータ、災害復旧用の新しいファイルシステムチェックツール、異なる Lustre バージョン間の相互運用性のためのプロトコル互換性ネゴシエーション機能を導入し、HPC クラスタを完全停止させることなく段階的な開発・展開・システムアップグレードを可能にした。代表的な展開例として、1,280 クライアント・104 の OSS ノード・140TB の OST ストレージを備えた NCSA の Tungsten クラスタがあり、堅牢なアーキテクチャと一貫した HA を示した。 2007年、Lustre は HPC セクターにおける優位を確立し、上位10台の HPC クラスタのうち7台を支えるに至った。汎用データセンタバックエンドとしての能力により、様々な産業分野へも浸透した。Red Hat と Novell は Lustre パッチを適用したカーネルを提供することで導入を簡素化し、月間約10,000ダウンロードという広範な採用を示した。Lustre のスケーラビリティにより、複数のファイルシステムを 1 つに統合してストレージ管理を大幅に簡素化し、主要 HPC データセンタで必要なストレージ総量を削減することも可能になった。この年、Lustre は書き込みレートとファイル作成レートでも大きな改善を示し、Ibrix や Panasas のような特定ハードウェアアーキテクチャに依存する他の分散ファイルシステムとは対照的な、商用ハードウェア向けのオープンソース・ソフトウェアオンリーのソリューションとしての位置付けを際立たせた。 一方2007年、Sun Microsystems が CFS を買収し、以後 ZFS(Zettabyte File System)と Lustre を統合して HPC 向け製品を強化した。しかし 2009年に Oracle が Sun を買収した後、Lustre の将来に対する懸念から、元 Lustre 開発者らによる Whamcloud の設立と、OpenSFS・EOFS・HPCFS といった独立系コミュニティコンソーシアムの結成が促された。いずれも Lustre の継続的なオープンソース開発を確保することを目的とした。Oracle が Lustre のオープンソースプロジェクトとしての開発を打ち切ったことを受け、Cray・DDN・LLNL・ORNL を含む連合により OpenSFS が結成され、Lustre を中心としたハイエンドのオープンソースファイルシステム技術の推進を目指した。OpenSFS はコミュニティ主導開発の勢いを維持し、HPC 向け世界最先端のオープンソース並列ファイルシステムとしての Lustre を支え続けた。 ![[_attachments/survey-2025-lustre-unveiled/ch02-fig2-top500-adoption.png]] (図2. Top500 リストの (a) 上位10位、(b) 上位100位以内で Lustre を採用しているスーパーコンピューティングシステム数の推移。§2.3) 2011年までに Whamcloud が Lustre 2.1 開発を主導し、Lustre コミュニティにとって重要な節目となった。この取り組みはコードの最適化に向けた協調的な取り組みを促進し、オープンなコミュニティテスト基盤の推進にもつながった。結果として Lustre は、LLNL・ORNL・Cray・DDN といった組織の強力な後押しを受けつつ、ペタスケールシステムの 80% のストレージバックボーンとしての地位を確立した。同時に OpenSFS は Whamcloud と契約し、メタデータ性能・オンラインファイルシステムチェック・分散名前空間に焦点を当てた Lustre 開発を委託した。このパートナーシップは 2012年の Intel による Whamcloud 買収へとつながり、Lustre はさらに HPC の枠を超えて拡大した。加えて 2013年に Xyratex が Oracle から Lustre の知的財産を取得し、OpenSFS はコミュニティ主導の Lustre 開発・リソース支援を継続した。 LLNL の Hyperion や ORNL の Spider といった大規模 HPC 展開は、Whamcloud の支援のもと Lustre のテストと改善に重要な役割を果たし、2012年までに Top500 上位100台のうち59台という広範な採用と卓越した信頼性につながった。Lustre 2.0 から 2.6 にかけての、アーキテクチャ再構成・相互運用性の強化、ZFS サポートや水平方向のメタデータスケーリングといった新機能を含む大きな進展が、この成功に寄与した。図2 は Top500 の上位10位・上位100位ランキングにおける Lustre の利用状況を示している。2006年以降、Lustre は Top500 上位10位のうち少なくとも50%のシステムで一貫して採用され続けており、2016〜2017年には10台中9台という採用のピークを記録した。2002年から2010年にかけて、上位100システムにおける Lustre 展開は一貫した成長を示し、年平均91%の増加率であった。2013年に一時的な展開数の落ち込みがあったものの、2014年以降は上位100システムの少なくとも60%で Lustre が利用されている。展開数の最高値は2017年に記録され、100システム中77システムが Lustre を採用していた。 これらの統計は、Top500 リスト自体が各システムの利用ファイルシステムを示さないため、Top500 リストの手作業による分析によって収集された。この分析は、Lustre を利用しているシステムや顧客の特定、プレスリリース、可能な場合はシステム管理者への確認によって行われた。ただし、Lustre を利用するシステム数の増加とソフトウェアのオープンソースという性質上、こうした情報について権威ある出典は存在しない点に留意が必要である。 2015年から2016年にかけて、Lustre は産業ソリューション・学術研究・連邦政府機関の能力を高めながら、様々な分野で著しい成長と広範な採用を経験した。OpenSFS の下でのコミュニティ主導プロジェクトモデルへの移行や、Intel の Azure 向け Cloud Edition for Lustre をはじめとするエンタープライズ・クラウド環境への拡大が見られた。2017年以降、Intel は Lustre への貢献をオープンソースコミュニティへ転換した。2018年に DDN が Intel の Lustre 事業を買収し、以降も大きな進展が続いた(章末はここで途切れる。以降の詳細な歴史は付録 A で扱われる)。 ## 関連 - [[@2025__TOS__Lustre Unveiled - Chapter 1 Introduction]] - [[@2025__TOS__Lustre Unveiled - Chapter 3 Architectural Details of Lustre]] - [[@2025__TOS__Lustre Unveiled - Appendix A The Complete History of Lustre]](Lustre の詳細な歴史) - [[wiki/entities/Lustre|Lustre]] - [[Lustre Unveiled]]