Skip to main content
NetApp artificial intelligence solutions
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Lustre と NetApp Eシリーズ ストレージ - 解決策アーキテクチャ

PDF

Lustre と NetApp Eシリーズ ストレージが、構成要素、高可用性、ネットワークトポロジー、およびクライアントをどのように活用して、容量、パフォーマンス、およびフェイルオーバーを計画できるようにするかについて説明します。

ビルディングブロック設計

ビルディングブロックは、NetApp Eシリーズ Lustre 解決策の基本的なスケーラブルな単位です。各ビルディングブロックは、Lustre オブジェクトストレージサーバー（OSS）およびメタデータサーバー（MDS）機能を提供する高可用性（HA）ペアとして構成された2つのサーバーノード、2つのNetApp Eシリーズ オールフラッシュアレイ、サーバーとアレイ間の専用バックエンド NVMe over Fabrics（NVMe-oF）接続、およびクライアントとノード間通信のための専用フロントエンド Lustre ネットワーキング（LNet）接続で構成されています。PacemakerとCorosyncのHAクラスタは、1つ以上のビルディングブロックからのサーバーペアを含むことができます。NetApp `ansible-lustre`コレクションは、Ansible 自動化を使用して Lustre サービスをデプロイおよび構成します。

Lustre ビルディングブロック

2つのOSS/MDSサーバーノードと2つのEシリーズEF80アレイを備えたLustre HAビルディングブロック

構成要素は、ファイルシステムの成長要件に合わせて拡張可能です。すべてのファイルシステムには、1つの基本構成要素が必要です。基本構成要素は、管理ターゲット（MGT）上に管理サーバー（MGS）をホストし、初期メタデータターゲット（MDT）およびオブジェクトストレージターゲット（OST）の容量を提供します。追加の構成要素はファイルシステムを拡張し、基本構成要素のMGSに対してMDTおよびOSTターゲットを登録します。モジュール式のアプローチにより、ワークロードのニーズに応じて容量とパフォーマンスを個別に拡張できます。

NetAppは、ほとんどのデプロイメントに対して以下の構成要素構成プロファイルを推奨します。MGS、MDT、およびOSTのカウントは、Eシリーズ ストレージアレイのパフォーマンスと容量を最大化するように最適化された推奨デフォルト値です。ワークロードのニーズに合わせて、Ansibleインベントリ内のターゲット数、ボリュームサイズ、およびEシリーズのドライブ割り当てを調整してください。たとえば、より大きなメタデータストレージ容量を必要とするデプロイメントでは、同じビルディングブロックハードウェア内でより多くのMDTをプロビジョニングし、OSTを少なくすることができます。

以下の表は、構成要素の種類と推奨される目標数をまとめたものです。

タイプ MGS MDT OST 用途

基本

1

8

32

ファイルシステムの最初の構成要素。MGSおよび初期のMDTとOSTの容量をホストします。

MDT+OST

0

8

32

メタデータとデータ容量を追加します。基本構成要素MGSに対して登録します。

OST のみ

0

0

32

データ容量のみを追加します。基本構成要素MGSに対して登録します。

  • ドライブの種類とプールレイアウト： Eシリーズは従来のRAIDボリュームグループとダイナミックディスクプール（DDP）をサポートします。TLC NVMeドライブの場合、OSTストレージにはRAID 6ボリュームグループを、MGSおよびMDTストレージにはRAID 1ボリュームグループを使用してください。QLC NVMeドライブの場合は、共有ドライブプールにDDPを使用してください。

  • ＊ターゲットの分散：＊各ビルディングブロック内のLustreターゲットは、両方のOSS/MDSサーバーノードと両方のEシリーズ アレイ間でバランスよく配置されます。このレイアウトにより、I/OがサーバーのCPUとアレイコントローラーに分散され、NVMe-oFパスのパフォーマンスが向上し、冗長性が維持されます。"ハードウェア コンポーネント"の"ターゲット分散とNVMe-oF接続"を参照してください。

サポートされているオペレーティングシステム、Lustreバージョン、アレイファームウェア、および関連するビルディングブロックコンポーネントは、"NetApp Interoperability Matrix Tool（IMT）"の E-Series Lustre に記載されています。詳細なボリューム数、ドライブレイアウト、およびサイジングガイドラインについては、"ハードウェア コンポーネント"を参照してください。ソフトウェアコンポーネントについては、"ソフトウェアコンポーネント"を参照してください。

スケーリングに関する推奨事項

Lustreファイルシステムは、メタデータ容量、データ容量、またはその両方が制限要因となった場合に、構成要素を追加することで拡張します。MDTはファイル数とメタデータIOPSに基づいてスケーリングし、OSTは容量と集約スループット要件に基づいてスケーリングします。

  1. ファイルシステムごとに1つの基本ビルディングブロック： 正確に1つの基本ビルディングブロックをデプロイします。これは、MGS、初期MDT、およびOSTターゲットをホストします。

  2. 追加のビルディングブロックプロファイル： 既存のMDT容量が十分で、データ容量またはスループット要件を増やす必要がある場合は、OST専用のビルディングブロックを追加します。メタデータのパフォーマンスや名前空間の容量がボトルネックになった場合は、MDT+OSTのビルディングブロックを追加します。

  3. HAクラスタの制限： PacemakerおよびCorosyncの各HAクラスタを5つのビルディングブロック（10個のLustreサーバーノード）に制限します。大規模な構成では、リソースの制約を回避するために、大規模なデプロイメントを複数のHAクラスタに均等に分割します。

次の図は、42Uラックに最大5つのビルディングブロックを積み重ねた状態を示しています（ラックごとに1つのPacemaker HAクラスタ）。複数のラックが単一のLustreファイルシステムに参加できますが、MGSをホストするのは基本ビルディングブロックのみです。

Lustreパラレルファイルシステムラックスケーリング

Lustre並列ファイルシステムは、複数の42Uラックにまたがってスケーリングし、各ラックには1つのPacemaker HAクラスタ内に最大5つのビルディングブロックが含まれます。

サイズの例については、"サイズガイド"を参照してください。

HAアーキテクチャ

Lustre with NetApp E-Series Storageは、NetApp Eシリーズ ストレージと統合された共有ディスク高可用性（HA）アーキテクチャを使用します。PacemakerがHAリソースを管理し、Corosyncがクラスタメンバーシップとメッセージングを提供します。これらが連携して、各ビルディングブロック内の2つのOSS/MDSサーバノード間におけるLustreターゲットのフェイルオーバーを管理します。マルチパスNVMe-oFが両方のOSS/MDSサーバノードを同じEシリーズ ボリュームに接続するため、必要に応じてどちらのノードでもターゲットサービスを引き継ぐことができます。

MGS、MDT、およびOSTはそれぞれ、Pacemakerリソースグループ内の依存関係とともにHAリソースとして構成されます。Pacemakerは、リソースが正しい順序で起動および停止し、同じノード上に常駐し、一度に1つのノードでのみ実行されることを保証します。両方のノードから同じターゲットに同時にアクセスすると、基盤となるファイルシステムが破損する可能性があります。

  • ターゲットのフェイルオーバー： OSS/MDSサーバーノードは両方ともクラスタ内でピアですが、各Lustreターゲットは一度に1つのノードでのみアクティブになります。Pacemakerの監視リソースは、各ターゲットとその依存関係の状態を監視し、ターゲットが現在のノードで利用できなくなった場合にフェイルオーバーをトリガーします。障害発生時、Pacemakerは影響を受けるリソースグループをパートナーノード上で正しい順序で再起動し、サービスが再開されるとクライアントは透過的にターゲットの新しい場所に再接続します。各ターゲットは単一のノード上でアクティブ化されるため、ファイルシステムが両方のノードからの同時書き込みにさらされることはありません。

  • 共有ストレージ アクセス： マルチパスNVMe-oFパスは、各OSS/MDSサーバーノードをビルディングブロック内のすべてのEシリーズコントローラに接続するため、どのノードからでもすべてのターゲットボリュームにアクセスできます。サーバーノードに障害が発生した場合、パートナーノードは既に同じボリュームへのアクティブなパスを保持しているため、ストレージ接続を再構成することなくターゲットの所有権を引き継ぐことができます。アレイコントローラまたはパスに障害が発生した場合、マルチパスはI/Oを稼働中のコントローラにリダイレクトします。この二重冗長性により、LustreターゲットはOSS/MDSサーバーノード間またはアレイコントローラー間で、バッキングボリュームへのアクセスを失うことなくフェイルオーバーできます。

  • STONITH フェンシング： 障害が発生すると、Pacemaker は障害のあるノードと通信して、ターゲットが停止していることを確認できない場合があります。Pacemaker は、他の場所でこれらのターゲットを再起動する前に、障害が発生したノードをフェンスし、理想的には電源を遮断して、そのノードが確実に停止していることを確認します。フェンシングは、両方のノードが同時に同じターゲットにアクセスして基盤となるファイルシステムを破損させるスプリットブレイン状態を防ぎ、フェイルオーバー時のデータ整合性を維持します。NetApp は、Redfish 対応のベースボード管理コントローラー（BMC）を搭載したサーバーに `fence_redfish`を推奨します。その他のフェンスエージェント（ `fence_apc`など）もサポートされています。

クラスタ管理とフェンシング設定については、"ansible-lustreコレクション"の"HAユーザーガイド"を参照してください。

ネットワーク アーキテクチャ

このソリューションでは、ストレージバックエンドのトラフィックとLNetフロントエンドのトラフィックにそれぞれ別のネットワークパスを使用します。

  • バックエンド（NVMe-oF）： OSS/MDSサーバーノードは、NVMe/InfiniBandまたはNVMe/RoCEを使用して、NVMe-oF経由でEシリーズ アレイに接続します。NVMe-oFパスは、LustreターゲットサービスとEシリーズ ボリュームの間でブロックI/Oを転送します。EF80の6つのHCAバックエンドのケーブル接続については、"Lustre ハードウェアのラックとケーブル接続"を参照してください。ノードとアレイ間での推奨されるターゲット配置については、"ハードウェア コンポーネント"の"ターゲット分布"を参照してください。

  • フロントエンド（LNet）： LustreクライアントとOSS/MDSサーバーノードは、NVIDIA OFEDスタックの `@o2ib`ネットワークタイプを使用してLNet経由で通信します。InfiniBandとRoCEはどちらも検証済みのフロントエンドトランスポートです。ansible-lustreコレクションは、マルチレールLNet用のすべてのフロントエンドインターフェースを設定します。マルチレールLNetは、複数のポートを集約することで帯域幅を拡大し、クライアントおよびノード間のトラフィックに対してパスの冗長性を提供します。

  • 管理とクラスター： アウトオブバンド管理ネットワークは、サーバー管理、BMC アクセス、およびアレイ管理を提供します。STONITH フェンシングエージェント（ `fence_redfish`など）は、このネットワークを使用してサーバーの BMC にアクセスし、障害が発生したノードから電源を遮断します。Corosync は、フロントエンドファブリックに加えて、このネットワーク上でクラスタ通信を追加リングとして実行することもできます。Corosync を複数のリングで構成することで、クラスタメッセージングの冗長性が向上し、単一のネットワーク障害によってクォーラムが中断されるリスクが軽減されます。

Lustre クライアント

Lustreクライアントは、クライアントカーネルモジュールをロードし、OSS/MDSサーバーノードへのLNet接続を確立し、ファイルシステムをマウントして、単一の一貫性のあるPOSIX準拠の名前空間をアプリケーションに提供します。入出力は、アクティブなOST全体に並列に分散されます。クライアントノードはビルディングブロックの外部にあり、フロントエンドのLNetファブリックを介してファイルシステムを使用します。クライアントオペレーティングシステムはこの解決策のIMTには記載されていません。テスト済みのクライアントディストリビューションと、デプロイされたLustreリリースでサポートされているカーネルバージョン（例：Red Hat Enterprise Linux 9、SUSE Linux Enterprise Server 15、Ubuntu 24.04）については、"Lustre サポートマトリックス"を参照してください。

クライアントノードは、OSS/MDSサーバーノードと同じLNetファブリックおよびネットワークタイプへの接続を必要とします。必要に応じて、LNetルーターは複数のLNetサブネットまたはファブリックをブリッジ接続できます。

NetAppは、Rocky Linux 9.8およびRed Hat Enterprise Linux 9.8用のLustreサーバーRPMパッケージ（ビルド済み）を提供します。NetAppは、事前に構築されたクライアントパッケージを提供していません。"netapp-lustreリポジトリ"にあるLustreソースコードから、クライアントオペレーティングシステムとカーネル用のクライアントパッケージをビルドしてください。

クライアント パッケージのインストール後、"ansible-lustreコレクション" のオプションの lustre_client ロールが、クライアント ネットワーク インターフェイスと LNet を設定し、選択されている場合はマルチレール LNet を有効にし、接続性を検証して、永続的な systemd マウント ユニットを管理します。このロールは Lustre をビルドしません。このロールは、 lustre_client_packages が設定されている場合にのみクライアント パッケージをインストールします。必要に応じて、クライアントを手動で設定することもできます。段階的な手順については、"解決策をデプロイする" および "lustre_client ロールのドキュメント" を参照してください。