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

NetApp AIPodとNVIDIA DGXシステム-解決策アーキテクチャ

共同作成者

このセクションでは、NVIDIA DGXシステムを搭載したNetApp AIPodのアーキテクチャに焦点を当てます。

DGX H100システムを搭載したNetApp AIポッド

このリファレンスアーキテクチャでは、コンピューティングノード間の400GB/秒InfiniBand(IB)接続で、コンピューティングクラスタインターコネクトとストレージアクセスに別 々 のファブリックを利用します。次の図は、DGX H100システムを搭載したNetApp AIPodの全体的な解決策トポロジを示しています。

NetApp AIPOD解決策トポロジ_
エラー:グラフィックイメージがありません

ネットワーク構成:

この構成では、コンピューティングクラスタファブリックでQM9700 400Gb/秒IBスイッチのペアを使用します。これらのスイッチは相互に接続されて高可用性が確保されます。各DGX H100システムは、8つの接続を使用してスイッチに接続されます。一方のスイッチには偶数番のポートが接続され、もう一方のスイッチには奇数番のポートが接続されます。

ストレージシステムへのアクセス、インバンド管理、およびクライアントアクセスには、SN4600イーサネットスイッチのペアを使用します。スイッチはスイッチ間リンクで接続され、さまざまなトラフィックタイプを分離するために複数のVLANで設定されます。大規模な展開では、スパインスイッチ用にスイッチペアを追加し、必要に応じてリーフを追加することで、イーサネットネットワークをリーフスパイン構成に拡張できます。

コンピューティングインターコネクトと高速イーサネットネットワークに加えて、すべての物理デバイスを1つ以上のSN2201イーサネットスイッチに接続し、アウトオブバンド管理を行います。 DGX H100システムの接続の詳細については、 "NVIDIA BasePODドキュメント"

ストレージアクセス用のクライアント設定

各DGX H100システムには、管理トラフィックとストレージトラフィック用に2つのデュアルポートConnectX-7アダプタがプロビジョニングされます。この解決策では、各カードの両方のポートが同じスイッチに接続されます。各カードの1つのポートがLACP MLAGボンドに構成され、各スイッチに1つのポートが接続されます。このボンドでは、インバンド管理、クライアントアクセス、およびユーザレベルのストレージアクセス用のVLANがホストされます。

各カードのもう一方のポートはAFF A900ストレージシステムへの接続に使用され、ワークロードの要件に応じて複数の構成で使用できます。NVIDIA Magnum IO GPUDirect StorageをサポートするためにRDMA経由のNFSを使用する構成では、他のタイプのボンドではRDMAがサポートされないため、ポートはアクティブ/パッシブボンドとして構成されます。RDMAを必要としない環境では、ストレージインターフェイスをLACPボンディングで設定して、高可用性と追加の帯域幅を実現することもできます。クライアントは、RDMAを使用するかどうかに関係なく、NFS v4.1 pNFSおよびセッショントランキングを使用してストレージシステムをマウントし、クラスタ内のすべてのストレージノードに並列アクセスできるようにします。

ストレージシステムの構成:

各AFF A900ストレージシステムは、各コントローラの4つの100GbEポートを使用して接続されます。各コントローラの2つのポートがDGXシステムからのワークロードデータアクセスに使用され、各コントローラの2つのポートがLACPインターフェイスグループとして構成され、クラスタ管理アーティファクトとユーザホームディレクトリ用の管理プレーンサーバからのアクセスをサポートします。ストレージシステムからのすべてのデータアクセスはNFS経由で提供されます。AIワークロードアクセス専用のStorage Virtual Machine(SVM)と、クラスタ管理専用の別のSVMがあります。

ワークロードSVMには合計8つの論理インターフェイス(LIF)が設定され、各物理ポートに2つのLIFがあります。この構成では、最大帯域幅と、各LIFが同じコントローラ上の別のポートにフェイルオーバーする手段が提供されるため、ネットワーク障害が発生した場合でも両方のコントローラがアクティブなままになります。この構成では、RDMA経由のNFSもサポートされ、GPUDirectストレージへのアクセスが可能になります。ストレージ容量は、クラスタ内のすべてのストレージコントローラにまたがる1つの大規模なFlexGroupボリューム(各コントローラに16個のコンスティチュエントボリューム)としてプロビジョニングされます。このFlexGroupにはSVM上のどのLIFからもアクセスできます。pNFSとセッショントランキングを使用したNFSv4.1を使用すると、クライアントはSVM内のすべてのLIFへの接続を確立します。これにより、各ストレージノードのローカルデータに並行してアクセスできるようになり、パフォーマンスが大幅に向上します。ワークロードSVMと各データLIFもRDMAプロトコルアクセス用に設定されます。ONTAPのRDMA設定の詳細については、 "ONTAP のドキュメント"

管理SVMに必要なLIFは1つだけです。このLIFは、各コントローラで設定された2ポートインターフェイスグループでホストされます。他のFlexGroupは、クラスタノードのイメージ、システム監視履歴データ、エンドユーザのホームディレクトリなど、クラスタ管理アーティファクトを格納するために管理SVM上にプロビジョニングされます。次の図は、ストレージシステムの論理構成を示しています。

NetApp A900ストレージクラスタの論理構成
エラー:グラフィックイメージがありません

管理プレーンサーバ

このリファレンスアーキテクチャには、管理プレーン用に5台のCPUベースのサーバも含まれています。このうちの2つのシステムは、クラスタの導入と管理のためのNVIDIA Base Command Managerのヘッドノードとして使用されます。他の3つのシステムは、ジョブのスケジューリングにSlurmを利用する導入環境向けに、Kubernetesマスターノードやログインノードなどの追加のクラスタサービスを提供するために使用されます。Kubernetesを活用した導入では、NetApp Astra Trident CSIドライバを活用して、AFF A900ストレージシステム上の管理ワークロードとAIワークロードの両方に永続的ストレージを使用した自動プロビジョニングとデータサービスを提供できます。

各サーバは、クラスタの導入と管理を可能にするためにIBスイッチとイーサネットスイッチの両方に物理的に接続されます。また、前述したクラスタ管理アーティファクトの保存用に、管理SVMを介したストレージシステムへのNFSマウントが設定されます。