こんにちは。SB C&S の野木です。

本記事では、弊社検証環境に構築したAIクラスタ構築シリーズの第4回として、NVIDIA Network OperatorをKubernetesクラスタへ導入し、RoCEv2によるRDMA通信を行うための環境構築手順をご紹介します。

NVIDIA Network Operatorの解説や各ネットワークコンポーネントの役割については、以下の第3回の記事で紹介していますので、併せてご覧ください。
③NVIDIA Networkingで構築するAIクラスタ検証 - NVIDIA Network Operator基礎編 -

また、NVIDIA Networking製品の概要については、以下の過去記事で紹介していますので、こちらも併せてご覧いただくことをおすすめします。
【連載】AI時代をリードする NVIDIA Networking のご紹介

なお、本記事で紹介する設定およびコマンドは、弊社検証環境で使用したNVIDIA Network Operator v26.4.0をもとに確認しています。

バージョンによって設定方法や展開されるコンポーネントなどが異なる場合があるため、ご利用の環境に応じて最新のNVIDIA公式ドキュメントをご確認ください。
NVIDIA Network Operator

AIクラスタ構築の全体構成

本シリーズでは、NVIDIA Networkingを活用したAIクラスタの構築をテーマに、ネットワークスイッチの初期設定からGPUサーバー側の構築までを順を追ってご紹介します。

一般的なAIクラスタでは、GPUを搭載した複数台のベアメタルサーバーをKubernetesクラスタとして構成し、高速ネットワークを介して各GPUサーバーを接続する構成が広く採用されています。

一方、本シリーズでは社内検証環境の構成上、1台の物理サーバー上に仮想基盤（VMware vSphere）を構築し、その上にKubernetes Control Plane 1台、Worker Node 2台の計3台の仮想マシンを配置しています。

GPU処理を行うWorker Nodeには、それぞれNVIDIA L40S GPUを1枚、およびNVIDIA ConnectX®-7 HCAを1枚ずつPCIeパススルーで割り当てることで、2台のGPUサーバーを疑似的に再現しています。

また、Worker Node間はNVIDIA Spectrum™-4 Ethernetスイッチ SN5600を介して接続し、高速ネットワークを利用したGPUサーバー間通信を行う構成としています。

本シリーズでは、この検証環境を用いて以下の内容を順番にご紹介します。

• 第1回：Spectrumスイッチ初期構築
• 第2回：NVIDIA GPU Operatorの構築
• 第3回：NVIDIA Network Operator 基礎編
• 第4回：NVIDIA Network Operator 構築編（本記事）

第1回～第3回では、AIクラスタを構成する各コンポーネントの概要や構築手順についてご紹介しています。詳細については、上記の各記事も併せてご覧ください。

今回はシリーズ第4回として、NVIDIA Network OperatorをKubernetesクラスタへ導入します。

また、Worker Nodeに搭載されたConnectX-7を使用して、RoCEv2によるRDMA通信が可能なネットワーク環境を構築し、実際にPod間で通信できることを確認します。

NVIDIA Network Operatorの構築手順

ここからは、実際にNVIDIA Network OperatorをKubernetesクラスタへ導入していきます。

NVIDIA Network Operatorの導入には、KubernetesクラスタやHelmなどの環境が必要です。

基本的な導入前提条件は、第2回 NVIDIA GPU Operator構築編と共通するため、詳細についてはそちらの記事をご参照ください。

Network Operatorでは、これらの前提条件に加えて、ConnectXなどのサポート対象となるNVIDIAネットワークアダプターが必要です。本検証環境では、各Worker NodeにNVIDIA ConnectX-7を搭載しています。

また、本記事ではDOCA-OFED DriverをホストOSへ事前にインストールせず、Network OperatorからDriver Containerとして展開する構成とします。

なお、GPU OperatorなどによってNode Feature Discovery（NFD）がすでに導入されている環境では、Network OperatorからNFDを重複して導入しないよう注意が必要です。

※本検証環境ではGPU OperatorによってNFDが導入済みのため、後述するNetwork Operatorのインストール時にNFDを無効化します。

NVIDIA Network Operatorの検証は、「構築」と「動作確認」の2つのフェーズに分けて行います。

まず、構築フェーズでは以下の手順でNetwork OperatorおよびRoCEv2通信に必要なネットワーク環境を構成します。

STEP1：NVIDIAのHelm Repositoryを追加します。

STEP2：Helmを使用してNVIDIA Network OperatorをKubernetesクラスタへインストールします。

STEP3：Network Operatorで利用するドライバーやプラグインなどを定義する「NicClusterPolicy」を作成します。Network Operatorは、この設定に基づいて必要なネットワークコンポーネントを各ノードへ展開します。

STEP4：PodがRoCEv2通信に使用する追加のネットワーク（Secondary Network）を定義する「MacvlanNetwork」を作成します。

 

続いて、動作確認フェーズでは、構築したネットワーク環境をPodから実際に利用できることを確認します。

STEP5：RDMA対応のテスト用Podを作成します。

STEP6：2つのPod間でRoCEv2によるRDMA通信が正常に行えることを確認します。

それでは、各手順について実際のコマンドとあわせてご紹介します。

NVIDIA Network Operatorを構築してみる

STEP1 NVIDIA Helm Repositoryの登録

NVIDIA Network Operatorは、NVIDIA NGCで提供されているHelm Chartを使用してインストールします。

はじめに、以下のコマンドを実行してNVIDIAのHelm Repositoryを登録し、Repositoryの情報を更新します。

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update

なお、NVIDIA GPU Operatorの構築などで、すでにNVIDIAのHelm Repositoryを追加している場合は、本手順を省略できます。

STEP2 Network Operatorのインストール

続いて、Helmを使用してNVIDIA Network OperatorをKubernetesクラスタへインストールします。

本検証では検証時点の最新バージョンであるNVIDIA Network Operator v26.4.0を使用し、以下のコマンドを実行します。

helm install network-operator \ nvidia/network-operator \ -n nvidia-network-operator \ --create-namespace \ --version v26.4.0 \ --set nfd.enabled=false \ --wait

主なオプションの内容は以下のとおりです。

• network-operator：Helm Releaseの名前を指定します。
• -n nvidia-network-operator：Network Operatorをnvidia-network-operator Namespaceへインストールします。
• --create-namespace：指定したNamespaceが存在しない場合に新しく作成します。
• --version v26.4.0：インストールするNetwork Operatorのバージョンを指定します。
• --set nfd.enabled=false：Network OperatorによるNode Feature Discovery（NFD）の導入を無効化します。
• --wait：Network Operatorのリソースが利用可能な状態になるまで待機します。

本検証環境では、前回構築したNVIDIA GPU OperatorによってNFDがすでに導入されているため、「--set nfd.enabled=false」を指定しています。

NFDが導入されていない環境では、NVIDIA Network OperatorからNFDを導入することも可能なため、環境に応じて設定を変更してください。

##出力

上記のように「STATUS: deployed」と表示されれば、NVIDIA Network Operatorのインストールは完了です。

続いて、以下のコマンドを実行し、NVIDIA Network OperatorのPodが正常に起動していることを確認します。

helm list -n nvidia-network-operator

##出力

kubectl get pods -n nvidia-network-operator

##出力

Helm Releaseの「STATUS」が「deployed」かつ「APP VERSION」が「v26.4.0」、Network OperatorのPodの「STATUS」が「Running」となっていることを確認します。

この時点ではNetwork Operator本体のみが起動しており、DOCA-OFED DriverやRDMA Shared Device Pluginなどのネットワークコンポーネントはまだ展開されていません。

次の手順では、利用するネットワークコンポーネントを定義するNicClusterPolicyを作成・適用します。

STEP3 NicClusterPolicyの作成・適用

続いて、Network Operatorで利用するネットワークコンポーネントを定義するNicClusterPolicyを作成します。

本検証では、以下のコンポーネントをNicClusterPolicyに定義します。

• DOCA-OFED Driver：ConnectXなどのHCAをOSから利用するためのドライバー
• RDMA Shared Device Plugin：HCAのRDMA機能をKubernetesリソースとして公開するためのプラグイン
• Multus CNI：Podに複数のネットワークを接続するためのCNIプラグイン
• CNI Plugins：MacVLANなどのSecondary Networkを構成するためのプラグイン

はじめに、RDMA通信に使用するConnectX-7のネットワークインターフェース名をそれぞれのWorker Nodeで確認します。

sudo lshw -class network -businfo

##出力
【cx7-ubuntu01】

【cx7-ubuntu02】

本検証環境では、両Worker NodeともConnectX-7に対応するネットワークインターフェースが「ens64np0」であることを確認できます。

この値は環境によって異なるため、ご利用の環境に合わせて以降の設定値を変更してください。

続いて、以下の内容でNicClusterPolicyのYAMLファイルを作成します。

cat <<'EOF' > nicclusterpolicy.yaml apiVersion: mellanox.com/v1alpha1 kind: NicClusterPolicy metadata:   name: nic-cluster-policy spec:   ofedDriver:     image: doca-driver     repository: nvcr.io/nvidia/mellanox     version: doca3.4.0-26.04-0.8.6.0-0   rdmaSharedDevicePlugin:     image: k8s-rdma-shared-dev-plugin     repository: nvcr.io/nvidia/mellanox     version: network-operator-v26.4.0     config: |       {         "configList": [           {             "resourceName": "rdma_shared_device_a",             "rdmaHcaMax": 63,             "selectors": {               "vendors": [],               "deviceIDs": [],               "drivers": [],               "ifNames": ["ens64np0"],               "linkTypes": ["ether"]             }           }         ]       }   secondaryNetwork:     cniPlugins:       image: plugins       repository: nvcr.io/nvidia/mellanox       version: network-operator-v26.4.0     multus:       image: multus-cni       repository: nvcr.io/nvidia/mellanox       version: network-operator-v26.4.0 EOF

本検証では、NicClusterPolicyで以下のネットワークコンポーネントを構成します。

• ofedDriver：ConnectX-7を利用するためのDOCA-OFED Driverを各Worker Nodeへ展開します。
• rdmaSharedDevicePlugin：ConnectX-7のRDMA機能をKubernetesリソースとして利用できるようにします。ifNamesには、先ほど確認したens64np0を指定しています。
• secondaryNetwork：Podに追加のネットワークを接続するために、cniPluginsとmultusを展開します。

また、repositoryやversionには、それぞれ使用するコンテナイメージのRepositoryとバージョンを指定しています。

本検証では、NVIDIA Network Operator v26.4.0に合わせたコンポーネントを使用しています。

NicClusterPolicyのYAMLファイルを作成したら、以下のコマンドでKubernetesクラスタへ適用します。

kubectl apply -f nicclusterpolicy.yaml

##出力

上記のように「created」と表示されれば、NicClusterPolicyの作成は完了です。

NicClusterPolicyを適用すると、Network Operatorが設定内容をもとにDOCA-OFED DriverやRDMA Shared Device Pluginなどのネットワークコンポーネントの展開を開始します。

次に、NicClusterPolicyを適用後、以下のコマンドを実行してネットワークコンポーネントのPodの状態を確認します。

kubectl get pods -n nvidia-network-operator

##出力

DOCA-OFED Driver、RDMA Shared Device Plugin、Multus CNI、CNI PluginsなどのPodが「Running」となっていることを確認します。

※本検証環境では、全ての Pod 起動まで5分程度かかりました。

続いて、NicClusterPolicyの状態を確認します。

kubectl get nicclusterpolicy

##出力

「STATUS」が「ready」となっていれば、NicClusterPolicyで定義したネットワークコンポーネントの構成は完了です。

STEP4 MacvlanNetworkの作成

続いて、PodがRoCEv2通信に使用する追加のネットワーク（Secondary Network）を構成するため、MacvlanNetworkを作成します。

はじめに、各Worker NodeでRoCEv2通信に使用するネットワークインターフェースを確認します。

ip link | grep ens

##出力
【cx7-ubuntu01】【cx7-ubuntu02】

 本検証環境では、両Worker Nodeに「ens64np0.104」が構成されていることを確認できます。

「ens64np0.104」は、ConnectX-7のネットワークインターフェース「ens64np0」上に作成したVLAN ID 104のVLANインターフェースです。

本検証では、このインターフェースをRoCEv2通信用のネットワークとして使用するため、後述するMacvlanNetworkの「master」に指定します。

この値は環境によって異なるため、ご利用のネットワーク構成に合わせて設定してください。

続いて、以下の内容でMacvlanNetworkのYAMLファイルを作成します。

本検証では、2つのテスト用PodにそれぞれRoCEv2通信用のIPアドレスを割り当てるため、PodごとにMacvlanNetworkを定義します。

cat <<'EOF' > roce-macvlan.yaml apiVersion: mellanox.com/v1alpha1 kind: MacvlanNetwork metadata:   name: roce-macvlan-vm1 spec:   networkNamespace: default   master: ens64np0.104   mode: bridge   mtu: 1500   ipam: |     {       "type": "host-local",       "subnet": "10.1.4.0/24",       "rangeStart": "10.1.4.201",       "rangeEnd": "10.1.4.201"     } --- apiVersion: mellanox.com/v1alpha1 kind: MacvlanNetwork metadata:   name: roce-macvlan-vm2 spec:   networkNamespace: default   master: ens64np0.104   mode: bridge   mtu: 1500   ipam: |     {       "type": "host-local",       "subnet": "10.1.4.0/24",       "rangeStart": "10.1.4.202",       "rangeEnd": "10.1.4.202"     } EOF

主な設定内容は以下のとおりです。

• networkNamespace：MacvlanNetworkに対応するNetworkAttachmentDefinitionを作成するNamespaceを指定します。本検証ではdefaultを指定します。
• master：MacvlanNetworkが使用する親インターフェースを指定します。本検証では、先ほど確認したRoCEv2通信用のVLANインターフェースens64np0.104を指定します。
• mode：MacVLANの動作モードを指定します。本検証ではbridgeを使用します。
• mtu：ネットワークインターフェースのMTUを指定します。本検証では1500を指定します。
• ipam：Podに割り当てるIPアドレスを設定します。本検証では「10.1.4.0/24」のネットワークを使用し、roce-macvlan-vm1には10.1.4.201、roce-macvlan-vm2には10.1.4.202を割り当てます。

これらのIPアドレスやネットワーク設定は本検証環境固有の値となるため、ご利用の環境に合わせて変更してください。

続いて、作成したMacvlanNetworkをKubernetesクラスタへ適用します。

kubectl apply -f roce-macvlan.yaml

##出力

MacvlanNetworkを適用したら、以下のコマンドで状態を確認します。

kubectl get macvlannetwork

##出力

「STATUS」が「ready」となっていれば、MacvlanNetworkの作成は完了です。

また、MacvlanNetworkを作成すると、PodからSecondary Networkを利用するためのNetworkAttachmentDefinitionが自動的に作成されます。

次のSTEP5では、このNetworkAttachmentDefinitionを指定してRDMA対応のテスト用Podを作成します。

STEP5 RDMA対応Podの作成

続いて、構築したネットワーク環境の動作確認を行うため、RDMA通信に対応したテスト用Podを作成します。

本検証では、2台のWorker Nodeにそれぞれ1つずつPodを配置し、STEP 4で作成したMacvlanNetworkを使用してRoCEv2通信用のネットワークを追加します。

以下の内容でテスト用PodのYAMLファイルを作成します。

cat <<'EOF' > rdma-test.yaml apiVersion: v1 kind: Pod metadata:   name: rdma-test-1   annotations:     k8s.v1.cni.cncf.io/networks: roce-macvlan-vm1 spec:   nodeName: cx7-ubuntu01   restartPolicy: Never   containers:     - name: rdma-test       image: ubuntu:24.04       command:         - /bin/bash         - -c         - |           apt-get update && \           DEBIAN_FRONTEND=noninteractive apt-get install -y \             iproute2 \             iputils-ping \             rdma-core \             ibverbs-utils \             perftest && \           sleep infinity       resources:         limits:           rdma/rdma_shared_device_a: 1 --- apiVersion: v1 kind: Pod metadata:   name: rdma-test-2   annotations:     k8s.v1.cni.cncf.io/networks: roce-macvlan-vm2 spec:   nodeName: cx7-ubuntu02   restartPolicy: Never   containers:     - name: rdma-test       image: ubuntu:24.04       command:         - /bin/bash         - -c         - |           apt-get update && \           DEBIAN_FRONTEND=noninteractive apt-get install -y \             iproute2 \             iputils-ping \             rdma-core \             ibverbs-utils \             perftest && \           sleep infinity       resources:         limits:           rdma/rdma_shared_device_a: 1 EOF

主な設定内容は以下のとおりです。

• v1.cni.cncf.io/networks：Podに接続するMacvlanNetworkを指定します。本検証では、Step 4で作成したroce-macvlan-vm1、roce-macvlan-vm2をそれぞれ指定します。
• nodeName：Podを配置するWorker Nodeを指定します。2つのPodを異なるWorker Nodeに配置するため、cx7-ubuntu01とcx7-ubuntu02をそれぞれ指定します。
• command：RoCEv2によるRDMA通信の確認に必要なrdma-core、ibverbs-utils、perftestなどのツールをPod起動時にインストールします。※本検証では動作確認を簡略化するため、Pod起動時に必要なツールをインストールしています。
• resources.limits：Podが使用するRDMAリソースを指定します。本検証では、RDMA Shared Device PluginによってConnectX-7のRDMA機能をKubernetesリソースとして公開したrdma/rdma_shared_device_aを1つ割り当てます。

続いて、作成したYAMLファイルを適用します。

kubectl apply -f rdma-test.yaml

Podを作成したら、以下のコマンドで状態と配置先を確認します。

kubectl get pods -o wide

##出力

2つのPodが「Running」となり、それぞれ異なるWorker Nodeに配置されていることを確認します。

続いて、各PodにRoCEv2通信用のネットワークが追加されていることを確認します。

kubectl exec rdma-test-1 -- ip -br addr kubectl exec rdma-test-2 -- ip -br addr

##出力
【rdma-test-1】【rdma-test-2】

「net1」に、MacvlanNetworkで設定した「10.1.4.201/24」と「10.1.4.202/24」がそれぞれ割り当てられていることを確認します。

最後に、各PodからRDMAデバイスを認識できることを確認します。

kubectl exec rdma-test-1 -- ibv_devices kubectl exec rdma-test-2 -- ibv_devices

##出力
【rdma-test-1】
【rdma-test-2】

両方のPodから「mlx5_0」が認識されていれば、PodからConnectX-7のRDMAデバイスを利用できる状態になっています。

これでRoCEv2によるRDMA通信を行うためのテスト用Podの準備は完了です。

次のSTEP6では、この2つのPod間で実際にRoCEv2によるRDMA通信を行います。

STEP6 RoCEv2によるRDMA通信の確認

最後に、2つのテスト用Pod間でRoCEv2によるRDMA通信が正常に行えることを確認します。

本検証では、ib_write_bwを使用して、rdma-test-1をServer、rdma-test-2をClientとしてRDMA Writeの帯域測定を実行します。

はじめに、rdma-test-1で以下のコマンドを実行し、Serverとして待機します。

kubectl exec -it rdma-test-1 -- \ ib_write_bw -d mlx5_0 -x 11 -F --report_gbits

「Waiting for client to connect...」と表示された状態で、別のターミナルからrdma-test-2で以下のコマンドを実行します。

kubectl exec -it rdma-test-2 -- \ ib_write_bw -d mlx5_0 -x 11 -F --report_gbits 10.1.4.201

主なオプションの内容は以下のとおりです。

・-d mlx5_0：通信に使用するRDMAデバイスを指定します。本検証では、Podから認識したConnectX-7のRDMAデバイス「mlx5_0」を使用します。
・-x 11：RoCEv2通信で使用するGID Indexを指定します。本検証環境では「11」を使用します。
・-F：CPU周波数に関するチェックを抑制します。本検証では仮想マシン上で測定を行うため指定しています。
・--report_gbits：測定結果の帯域幅をGbit/s単位で表示します。
・10.1.4.201：Clientから接続するServer側PodのRoCEv2通信用IPアドレスを指定します。

※GID Indexはネットワーク構成によって異なるため、ご利用の環境に合わせて確認・指定してください。

##出力

出力から「Link type」が「Ethernet」、「GID index」が「11」となっており、2つのPod間でRoCEv2によるRDMA通信が行われていることを確認できます。

また、本検証では5,000回の通信テストが正常に完了し、平均帯域は約220.84 Gbit/sとなりました。これによりRoCEv2によるRDMA通信によって、Pod間でも200 Gbit/sを超える広帯域な通信が行えていることが確認できました。

以上で、NVIDIA Network Operatorを使用したRoCEv2/RDMA環境の構築と動作確認は完了です。

まとめ

本記事では、AIクラスタ構築シリーズの第4回として、NVIDIA Network OperatorをKubernetesクラスタへ導入し、ConnectX-7を使用したRoCEv2によるRDMA通信が行える環境を構築しました。

本シリーズでは、第1回のSpectrum-4 Ethernetスイッチ初期構築編、第2回のNVIDIA GPU Operator構築編、第3回のNVIDIA Network Operator 基礎編、そして本記事のNVIDIA Network Operator 構築編を通して、GPUと高速ネットワークをKubernetesから活用できるAIクラスタ環境の構築をご紹介してきました。

これらを組み合わせることで、Kubernetes上でGPUを利用するだけでなく、高速なネットワークを介して複数のGPUサーバーを連携させる環境を構成できます。

今後は、今回構築した環境をベースに、複数ノード・複数GPUを利用した分散学習や分散推論など、より大規模なAIワークロードへの活用にもつなげることができます。

全4回の記事が、NVIDIA Networkingを活用したAIクラスタの構築や、今後のAIインフラを検討する際の参考になれば幸いです。

最後までご覧いただき、ありがとうございました。