アーキテクチャの概要
変更を提案
PDF
NetApp解決策 のBeeGFSには、検証済みのワークロードをサポートするために必要な機器、ケーブル配線、構成を決定するためのアーキテクチャ設計に関する考慮事項が含まれます。
ビルディングブロックアーキテクチャ
BeeGFSファイルシステムは、ストレージ要件に応じてさまざまな方法で導入および拡張できます。たとえば、主に多数の小さなファイルを扱うユースケースでは、メタデータのパフォーマンスと容量を強化できますが、大容量ファイルが少ないユースケースでは、実際のファイル内容よりも多くのストレージ容量とパフォーマンスを優先的に使用できます。このような複数の考慮事項は並列ファイルシステム環境のさまざまな次元に影響するため、ファイルシステムの設計と導入が複雑になります。
このような課題に対応するために、ネットアップでは、これらの要素のそれぞれをスケールアウトするための標準的なビルディングブロックアーキテクチャを設計しました。通常、BeeGFSビルディングブロックは、次の3つの設定プロファイルのいずれかに配置されます。
-
BeeGFSの管理、メタデータ、ストレージサービスなど、単一のベースとなるビルディングブロックです
-
BeeGFSメタデータとストレージビルディングブロック
-
BeeGFSストレージのみのビルディングブロック
これらの3つのオプション間のハードウェア変更は、BeeGFSメタデータに小さいドライブを使用することだけです。それ以外の場合は、すべての設定変更がソフトウェアを介して適用されます。また、導入エンジンとしてAnsibleを使用することで、特定のビルディングブロックに必要なプロファイルを設定することで、構成タスクを簡単に実行できます。
詳細については、を参照してください ハードウェアの設計を確認した。
ファイルシステムサービス
BeeGFSファイルシステムには、次の主要サービスが含まれます。
-
*管理サービス。*その他すべてのサービスを登録および監視します。
-
*ストレージ・サービス。*データ・チャンク・ファイルと呼ばれる分散ユーザー・ファイルの内容を保存します。
-
*メタデータサービス。*ファイルシステムのレイアウト、ディレクトリ、ファイル属性などを追跡します。
-
*クライアント・サービス。*保存されたデータにアクセスするためのファイル・システムをマウントします。
次の図は、NetApp Eシリーズシステムで使用されるBeeGFS解決策 のコンポーネントと関係を示しています。
BeeGFSは、並列ファイルシステムとして、複数のサーバノードを介してファイルをストライプ化することで、読み取り/書き込みのパフォーマンスと拡張性を最大化します。サーバノードは連携して動作するため、ほかのサーバノード（一般に_clients__）から同時にマウントしてアクセスすることができる単一のファイルシステムを提供します。これらのクライアントは、分散ファイルシステムをNTFS、XFS、ext4などのローカルファイルシステムと同様に認識して使用できます。
これら4つの主要サービスは、サポートされている幅広いLinuxディストリビューションで動作し、InfiniBand（IB）、Omni-Path（OPA）、RDMA over Converged Ethernet（RoCE）など、すべてのTCP/IPまたはRDMA対応ネットワークを介して通信します。BeeGFSサーバサービス（管理'ストレージ'メタデータ）はユーザ空間デーモンであり'クライアントはネイティブカーネルモジュール（パッチレス）ですすべてのコンポーネントは、リブートせずにインストールまたは更新でき、同じノード上で任意の組み合わせのサービスを実行できます。
HAアーキテクチャ
BeeGFS on NetAppは、共有ディスクハイアベイラビリティ（HA）アーキテクチャを実現するネットアップハードウェアと完全に統合された解決策 を作成することで、BeeGFSエンタープライズエディションの機能を拡張します。
|
BeeGFSコミュニティエディションは無料でご利用いただけますが、エンタープライズエディションにはネットアップなどのパートナーからプロフェッショナルサポートサブスクリプション契約を購入する必要があります。エンタープライズエディションでは、耐障害性、クォータの適用、ストレージプールなど、いくつかの追加機能を使用できます。 |
次の図は、シェアードナッシングおよび共有ディスクHAアーキテクチャの比較です。
詳細については、を参照してください "ネットアップがサポートするBeeGFSの高可用性についてお知らせします"。
ノードを確認しました
BeeGFS on NetAppソリューションでは、以下のノードが検証されました。
| ノード | ハードウェア | 詳細 |
|---|---|---|
ブロック |
NetApp EF600ストレージシステム |
要件の厳しいワークロード向けに設計された、ハイパフォーマンスなオールNVMe 2Uストレージアレイです。 |
ファイル |
Lenovo ThinkSystem SR665 V3サーバ |
PCIe 5.0デュアルAMD EPYC 9124プロセッサを搭載した2ソケット2Uサーバ。Lenovo SR665 V3の詳細については、を参照してください "LenovoのWebサイト"。 |
Lenovo ThinkSystem SR665サーバ |
PCIe 4.0、デュアルAMD EPYC 7003プロセッサを搭載した2ソケット2Uサーバ。Lenovo SR665の詳細については、を参照してください "LenovoのWebサイト"。 |
ハードウェアの設計を確認した
このソリューションのビルディングブロック（次の図を参照）では、BeeGFSファイルレイヤ用に検証済みファイルノードサーバを使用し、2台のEF600ストレージシステムをブロックレイヤとして使用します。
NetApp解決策 のBeeGFSは、導入環境のすべてのビルディングブロックで実行されます。最初に導入するビルディングブロックでは、BeeGFSの管理、メタデータ、ストレージサービス（基本ビルディングブロック）を実行する必要があります。後続のすべてのビルディングブロックは、ソフトウェアを使用して構成し、メタデータサービスとストレージサービスを拡張したり、ストレージサービスのみを提供したりできます。このモジュラ型アプローチにより、同じ基盤ハードウェアプラットフォームとビルディングブロック設計を使用しながら、ワークロードのニーズに合わせてファイルシステムを拡張できます。
最大5つのビルディングブロックを導入して、スタンドアロンのLinux HAクラスタを形成できます。これにより、Pacemakerによるリソース管理が最適化され、Corosyncとの効率的な同期が維持されます。これらのスタンドアロンBeeGFS HAクラスタの1つ以上が組み合わされてBeeGFSファイルシステムが作成され、クライアントは単一のストレージネームスペースとしてアクセスできます。ハードウェア側では、42Uラック1台に最大5つのビルディングブロックを収容でき、ストレージ/データネットワーク用に1U InfiniBandスイッチを2台搭載できます。視覚的な表現については、下の図を参照してください。
|
|
フェイルオーバークラスタでクォーラムを確立するには、少なくとも2つのビルディングブロックが必要です。2ノードクラスタには、フェイルオーバーの正常な実行を妨げる可能性がある制限があります。3つ目のデバイスをTiebreakerとして組み込むことで、2ノードクラスタを構成できますが、このドキュメントではその設計については説明していません。 |
Ansible
ネットアップのBeeGFSは、Ansible Automationを使用して提供および導入されます。この自動化はGitHubとAnsible Galaxy（BeeGFSコレクションはから入手できます "Ansible Galaxy" および "ネットアップのEシリーズGitHub"）。Ansibleは、主にBeeGFSビルディングブロックの構築に使用するハードウェアでテストされますが、サポートされているLinuxディストリビューションを使用して、ほぼすべてのx86ベースのサーバで実行するように設定できます。
詳細については、を参照してください "Eシリーズストレージを使用したBeeGFSの導入"。