Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

ハードウェアアクセラレーター

OpenShift Container Platform 4.18

ハードウェアアクセラレーター

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、人工知能および機械学習 (AI/ML) アプリケーションを作成するのに提供されるハードウェアアクセラレーション機能用に、Red Hat OpenShift AI でサポートされている GPU Operator をインストールおよび設定する手順を説明します。

第1章 ハードウェアアクセラレーターについて
リンクのコピー

専用ハードウェアアクセラレーターは、新しい生成人工知能および機械学習 (AI/ML) 業界で重要な役割を果たします。具体的には、ハードウェアアクセラレーターは、この新しいテクノロジーを支える大規模言語モデルやその他の基礎モデルのトレーニングと提供に不可欠です。データサイエンティスト、データエンジニア、ML エンジニア、開発者は、データ量の多い変換やモデルの開発と提供に特化したハードウェアアクセラレーションを活用できます。そのエコシステムの多くはオープンソースであり、複数の貢献パートナーとオープンソース財団が存在します。

Red Hat OpenShift Container Platform は、ハードウェアアクセラレーターの構成要素である次の処理ユニットを追加するカードと周辺ハードウェアをサポートしています。

  • グラフィックスプロセッシングユニット (GPU)
  • ニューラルプロセッシングユニット (NPU)
  • 特定用途向け集積回路 (ASIC)
  • データプロセッシングユニット (DPU)
サポートされているハードウェアアクセラレーターカードおよび周辺機器

専用ハードウェアアクセラレーターは、AI/ML 開発にさまざまな利点をもたらします。

1 つのプラットフォームであらゆる用途に対応
開発者、データエンジニア、データサイエンティスト、DevOps のためのコラボレーション環境
Operator による機能拡張
Operator により OpenShift Container Platform に AI/ML 機能を導入可能
ハイブリッドクラウドのサポート
モデルの開発、提供、デプロイのためのオンプレミスサポート
AI/ML ワークロードのサポート
モデルのテスト、イテレーション、統合、プロモートを行い、サービスとして運用環境に提供

Red Hat は、Red Hat Enterprise Linux (RHEL) および OpenShift Container Platform プラットフォームの Linux (カーネルとユーザー空間) および Kubernetes レイヤーで、このような専用ハードウェアアクセラレーターを有効にするために最適化されたプラットフォームを提供しています。これを実現するために、Red Hat は、Red Hat OpenShift AI と Red Hat OpenShift Container Platform の実証済みの機能を、単一のエンタープライズ対応 AI アプリケーションプラットフォームに統合しました。

ハードウェア Operator は、Kubernetes クラスターのオペレーティングフレームワークを使用して、必要なアクセラレーターリソースを有効にします。提供されているデバイスプラグインを手動で、またはデーモンセットとしてデプロイすることもできます。このプラグインにより、クラスターに GPU が登録されます。

専用ハードウェアアクセラレーターの中には、開発とテストのためのセキュリティーを確保する必要がある非接続環境内で動作するように設計されているものもあります。

1.1. ハードウェアアクセラレーター
リンクのコピー

Red Hat OpenShift Container Platform では、次のハードウェアアクセラレーターが有効になります。

  • NVIDIA GPU
  • AMD Instinct® GPU
  • Intel® Gaudi®

第2章 NVIDIA GPU アーキテクチャー
リンクのコピー

NVIDIA は、OpenShift Container Platform でのグラフィックスプロセッシングユニット (GPU) リソースの使用をサポートしています。OpenShift Container Platform は、大規模な Kubernetes クラスターのデプロイと管理用に Red Hat が開発およびサポートする、セキュリティーを重視して強化された Kubernetes プラットフォームです。OpenShift Container Platform には Kubernetes の拡張機能が含まれているため、ユーザーはが簡単に NVIDIA GPU リソースを設定し、それを使用してワークロードを高速化できます。

NVIDIA GPU Operator は、OpenShift Container Platform 内の Operator フレームワークを使用して、GPU で高速化されたワークロードの実行に必要な NVIDIA ソフトウェアコンポーネントのライフサイクル全体を管理します。

これらのコンポーネントには、NVIDIA ドライバー (CUDA を有効にするため)、GPU 用の Kubernetes デバイスプラグイン、NVIDIA Container Toolkit、GPU Feature Discovery (GFD) を使用した自動ノードタグ付け、DCGM ベースのモニタリングなどが含まれます。

注記

NVIDIA GPU Operator をサポートしているのは NVIDIA だけです。NVIDIA からサポートを受ける方法は、NVIDIA サポートの利用方法 を参照してください。

2.1. NVIDIA GPU の前提条件
リンクのコピー

  • 1 つ以上の GPU ワーカーノードを備えた OpenShift クラスターが稼働している。
  • 必要な手順を実行するために cluster-admin として OpenShift クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Node Feature Discovery (NFD) Operator をインストールし、nodefeaturediscovery インスタンスを作成している。

2.2. NVIDIA GPU の有効化
リンクのコピー

以下の図は、OpenShift で GPU アーキテクチャーがどのように有効になっているかを示しています。

図2.1 NVIDIA GPU の有効化

NVIDIA GPU の有効化
注記

MIG は、NVIDIA Ampere 生成で始まる GPU でサポートされています。MIG をサポートする GPU のリストは、NVIDIA MIG ユーザーガイド を参照してください。

2.2.1. GPU とベアメタル
リンクのコピー

NVIDIA 認定のベアメタルサーバーに OpenShift Container Platform をデプロイできますが、いくつかの制限があります。

  • コントロールプレーンノードは CPU ノードにできます。

  • AI/ML ワークロードがワーカーノードで実行される場合、そのワーカーノードは GPU ノードである必要があります。

    さらに、ワーカーノードは 1 つ以上の GPU をホストできますが、すべて同じタイプである必要があります。たとえば、ノードには 2 つの NVIDIA A100 GPU が存在することは可能ですが、A100 GPU と T4 GPU を 1 つずつ備えたノードはサポートされません。Kubernetes の NVIDIA デバイスプラグインは、同じノード上で異なる GPU モデルの組み合わせをサポートしません。

  • OpenShift を使用する場合は、1 台または 3 台以上のサーバーが必要な点に注意してください。2 台のサーバーを含むクラスターはサポートされません。単一サーバーのデプロイメントはシングルノード openShift (SNO) と呼ばれ、この設定を使用すると、高可用性 OpenShift 環境が得られません。

以下のいずれかの方法で、コンテナー化された GPU にアクセスできます。

  • GPU パススルー
  • マルチインスタンス GPU (MIG)

2.2.2. GPU と仮想化
リンクのコピー

多くの開発者や企業がコンテナー化されたアプリケーションやサーバーレスインフラストラクチャーに移行していますが、仮想マシン上で実行されるアプリケーションの開発と保守は引き続き注目されています。Red Hat OpenShift Virtualization はこの機能を提供し、企業はこの機能を使用して仮想マシンをクラスター内のコンテナー化されたワークフロー組み込むことができます。

ワーカーノードを GPU に接続する場合は、次のいずれかの方法を選択できます。

  • 仮想マシン内の GPU ハードウェアにアクセスして使用するための GPU パススルー。
  • GPU コンピュート容量がワークロードでいっぱいになっていない場合の GPU (vGPU) のタイムスライス。

2.2.3. GPU と vSphere
リンクのコピー

OpenShift Container Platform は、さまざまな GPU タイプをホストできる NVIDIA 認定の VMware vSphere サーバーにデプロイできます。

仮想マシンで vGPU インスタンスが使用されている場合は、NVIDIA GPU ドライバーをハイパーバイザーにインストールする必要があります。VMware vSphere の場合、このホストドライバーは VIB ファイルの形式で提供されます。

ワーカーノード仮想マシンに割り当てることができる vGPUS の最大数は、vSphere のバージョンによって異なります。

  • vSphere 7.0: 仮想マシンごとに最大 4 つの仮想 GPU

  • vSphere 8.0: 仮想マシンごとに最大 8 つの仮想 GPU

    注記

    vSphere 8.0 では、仮想マシンに関連付けられた複数の完全または部分的な異種プロファイルのサポートが導入されました。

次のいずれかの方法を選択して、ワーカーノードを GPU に割り当てることができます。

  • 仮想マシン内の GPU ハードウェアにアクセスして使用するための GPU パススルー
  • すべての GPU が必要でない場合の GPU (vGPU) タイムスライス

ベアメタルデプロイメントと同様に、1 台または 3 台以上のサーバーが必要です。2 台のサーバーを含むクラスターはサポートされません。

2.2.4. GPU および Red Hat KVM
リンクのコピー

OpenShift Container Platform は、NVIDIA 認定のカーネルベースの仮想マシン (KVM) サーバー上で使用できます。

ベアメタルデプロイメントと同様に、1 台または 3 台以上のサーバーが必要です。2 台のサーバーを含むクラスターはサポートされません。

ただし、ベアメタルデプロイメントとは異なり、サーバーで異なるタイプの GPU を使用できます。これは、GPU を Kubernetes ノードとして機能する別の仮想マシンに割り当てることができるためです。唯一の制限として、Kubernetes ノードがノードと同レベルで GPU タイプのセットを持つ必要があります。

以下のいずれかの方法で、コンテナー化された GPU にアクセスできます。

  • 仮想マシン内の GPU ハードウェアにアクセスして使用するための GPU パススルー
  • すべての GPU が必要でない場合の GPU (vGPU) タイムスライス

vGPU 機能を有効にするには、特別なドライバーをホストレベルでインストールする必要があります。このドライバーは RPM パッケージとして提供されます。このホストドライバーは、GPU パススルーの割り当てにはまったく必要ありません。

2.2.5. GPU と CSP
リンクのコピー

OpenShift Container Platform は、主要なクラウドサービスプロバイダー (CSP) である Amazon Web Services (AWS)、Google Cloud、Microsoft Azure のいずれかにデプロイできます。

フルマネージドデプロイメントとセルフマネージドデプロイメントの 2 つのオペレーションモードを使用できます。

  • フルマネージドデプロイメントでは、Red Hat が CSP と連携してすべてを自動化します。お客様は CSP の Web コンソールを使用して OpenShift インスタンスを要求できます。クラスターは自動的に作成され、Red Hat によって完全に管理されます。この環境内では、ノードの障害やエラーを心配する必要はありません。クラスターの稼働時間を維持する責任は Red Hat がすべて負います。フルマネージドサービスは、AWS、Azure、Google Cloud で利用できます。AWS の場合、OpenShift サービスは ROSA (Red Hat OpenShift Service on AWS) と呼ばれます。Azure の場合、このサービスは Azure Red Hat OpenShift と呼ばれます。Google Cloud の場合、このサービスは OpenShift Dedicated on Google Cloud と呼ばれます。
  • セルフマネージドデプロイメントでは、お客様が OpenShift クラスターのインスタンス化と維持を行う必要があります。この場合、Red Hat は OpenShift クラスターのデプロイを支援するために、OpenShift-install ユーティリティーを提供します。セルフマネージドサービスは、世界中のすべての CSP で利用できます。

このコンピュートインスタンスが GPU により高速化されたコンピュートインスタンスであること、および GPU タイプが NVIDIA AI Enterprise でサポートされている GPU のリストと一致することが重要です。たとえば、T4、V100、A100 はこのリストに含まれます。

以下のいずれかの方法で、コンテナー化された GPU にアクセスできます。

  • 仮想マシン内の GPU ハードウェアにアクセスして使用するための GPU パススルー。
  • GPU 全体を必要としない場合 GPU (vGPU) タイムスライス。

2.2.6. GPU と Red Hat Device Edge
リンクのコピー

Red Hat Device Edge は MicroShift へのアクセスを提供します。MicroShift は、シングルノードデプロイメントのシンプルさと、リソースに制約のある (エッジ) コンピューティング求められる機能とサービスを備えています。Red Hat Device Edge は、リソースに制約のある環境にデプロイされるベアメタル、仮想、コンテナー化された、または Kubernetes のワークロードのニーズを満たします。

Red Hat Device Edge 環境のコンテナー上で NVIDIA GPU を有効にできます。

コンテナー化された GPU へのアクセスには、GPU パススルーを使用します。

2.3. GPU の共有方法
リンクのコピー

Red Hat と NVIDIA は、エンタープライズレベルの OpenShift Container Platform クラスター上で、GPU 加速コンピューティングを簡略化するための GPU 同時実行性と共有メカニズムを開発しました。

通常、アプリケーションにはさまざまなコンピューティング要件があり、GPU が十分に活用されていない可能性があります。デプロイメントコストを削減し、GPU 使用率を最大化するには、ワークロードごとに適切な量のコンピュートリソースを提供することが重要です。

GPU 使用率を改善するための同時実行メカニズムは、プログラミングモデル API からシステムソフトウェアやハードウェアパーティショニングまで、仮想化を含めて幅広く存在します。次のリストは、GPU 同時実行メカニズムを示しています。

  • Compute Unified Device Architecture (CUDA) ストリーム
  • タイムスライス
  • CUDA マルチプロセスサービス (MPS)
  • マルチインスタンス GPU (MIG)
  • vGPU による仮想化

さまざまな OpenShift Container Platform シナリオで GPU 同時実行メカニズムを使用する場合は、次の GPU 共有に関する推奨事項を考慮してください。

ベアメタル
vGPU は使用できません。MIG 対応カードの使用を検討してください。
仮想マシン
vGPU が最良の選択です。
ベアメタル上の MIG を持たない古い NVIDIA カード
タイムスライスの使用を検討してください。
複数の GPU を搭載し、パススルーと vGPU が必要な仮想マシン
個別の仮想マシンの使用を検討してください。
OpenShift Virtualization と複数の GPU を備えたベアメタル
ホストされた仮想マシンにはパススルー、コンテナーにはタイムスライスの使用を検討してください。

関連情報

2.3.1. CUDA ストリーム
リンクのコピー

Compute Unified Device Architecture (CUDA) は、GPU での計算全般のために NVIDIA が開発した並列コンピューティングプラットフォームおよびプログラミングモデルです。

ストリームは、GPU 上で発行順に実行される一連の操作です。CUDA コマンドは通常、デフォルトストリームで順次実行され、前のタスクが完了するまでタスクは開始されません。

ストリームをまたいだ操作の非同期処理により、タスクの並列実行が可能になります。あるストリームで発行されたタスクは、別のタスクが別のストリームで発行される前、実行中、または発行された後に実行されます。これにより、GPU は指定された順序に関係なく複数のタスクを同時に実行できるようになり、パフォーマンスの向上につながります。

関連情報

2.3.2. タイムスライス
リンクのコピー

GPU タイムスライスは、複数の CUDA アプリケーションを実行しているときに、過負荷になった GPU でスケジュールされたワークロードをインターリーブします。

Kubernetes で GPU のタイムスライスを有効にするには、GPU のレプリカセットを定義し、それを個別に Pod に配分してワークロードを実行できるようにしっます。マルチインスタンス GPU (MIG) とは異なり、メモリーや障害はレプリカ間で分離されませんが、一部のワークロードでは一切共有しないより、こちらの方が適切です。内部的には、GPU タイムスライスを使用して、基礎である同じ GPU のレプリカからのワークロードを多重化します。

クラスター全体のデフォルト設定をタイムスライスに適用できます。ノード固有の設定を適用することもできます。たとえば、タイムスライス設定を Tesla T4 GPU を備えたノードにのみ適用し、他の GPU モデルを備えたノードは変更しないようにできます。

クラスター全体のデフォルト設定を適用し、ノードにラベルを付けて、それらのノードにノード固有の設定が適用されるようにすることで、2 つのアプローチを組み合わせることができます。

2.3.3. CUDA マルチプロセスサービス
リンクのコピー

CUDA マルチプロセスサービス (MPS) を使用すると、単一の GPU で複数の CUDA プロセスを使用できます。プロセスは GPU 上で並行して実行されるため、GPU コンピュートリソースの飽和が発生しなくなります。MPS を使用すると、カーネル操作や、別のプロセスからのメモリーコピーの同時実行または重複も可能になり、使用率が向上します。

関連情報

2.3.4. マルチインスタンス GPU
リンクのコピー

マルチインスタンス GPU (MIG) を使用すると、GPU コンピュートユニットとメモリーを複数の MIG インスタンスに分割できます。これらの各インスタンスは、システムの観点からはスタンドアロン GPU デバイスであり、ノード上で実行されている任意のアプリケーション、コンテナー、または仮想マシンに接続できます。GPU を使用するソフトウェアは、これらの各 MIG インスタンスを個別の GPU として扱います。

MIG は、GPU 全体のフルパワーを必要としないアプリケーションがある場合に役立ちます。新しい NVIDIA Ampere アーキテクチャーの MIG 機能を使用すると、ハードウェアリソースを複数の GPU インスタンスに分割できます。各インスタンスは、オペレーティングシステムで独立した CUDA 対応 GPU として利用できます。

NVIDIA GPU Operator バージョン 1.7.0 以降では、A100 および A30 Ampere カードの MIG サポートを提供しています。これらの GPU インスタンスは、最大 7 つの独立した CUDA アプリケーションをサポートするように設計されており、専用のハードウェアリソースをしようしてそれぞれ完全に分離された状態で稼働します。

関連情報

2.3.5. vGPU による仮想化
リンクのコピー

仮想マシンは、NVIDIA vGPU を使用して単一の物理 GPU に直接アクセスできます。企業全体の仮想マシンで共有され、他のデバイスからアクセスできる仮想 GPU を作成できます。

この機能は、GPU パフォーマンスのパワーと、vGPU がもたらす管理およびセキュリティーの利点を組み合わせたものです。vGPU には他にも、仮想環境のプロアクティブな管理と監視、混合 VDI とコンピュートワークロードのワークロードバランシング、複数の仮想マシン間でのリソース共有などの利点があります。

関連情報

2.4. OpenShift Container Platform の NVIDIA GPU 機能
リンクのコピー

NVIDIA Container Toolkit
NVIDIA Container Toolkit を使用すると、GPU で高速化されたコンテナーを作成して実行できます。ツールキットには、コンテナーが NVIDIA GPU を使用するように自動的に設定するためのコンテナーランタイムライブラリーとユーティリティーが含まれています。
NVIDIA AI Enterprise

NVIDIA AI Enterprise は、NVIDIA 認定システムで最適化、認定、サポートされている AI およびデータ分析ソフトウェアのエンドツーエンドのクラウドネイティブスイートです。

NVIDIA AI Enterprise には、Red Hat OpenShift Container Platform のサポートが含まれています。サポートされているインストール方法は以下のとおりです。

  • GPU パススルーを使用するベアメタルまたは VMware vSphere 上の OpenShift Container Platform。
  • NVIDIA vGPU を使用する VMware vSphere 上の OpenShift Container Platform。
GPU Feature Discovery

NVIDIA GPU Feature Discovery for Kubernetes は、ノード上で使用可能な GPU のラベルを自動的に生成できるソフトウェアコンポーネントです。GPU Feature Discovery は、Node Feature Discovery (NFD) を使用してこのラベル付けを実行します。

Node Feature Discovery (NFD) Operator は、ハードウェア固有の情報でノードにラベル付けを行うことで、OpenShift Container Platform クラスターのハードウェア機能と設定の検出を管理します。NFD は、PCI カード、カーネル、OS バージョンなどのノード固有の属性で、ホストにラベル付けを行います。

Operator Hub で NFD Operator を見つけるには、"Node Feature Discovery" で検索してください。

NVIDIA GPU Operator with OpenShift Virtualization

これまで、GPU Operator は、GPU で高速化されたコンテナーを実行するためにワーカーノードのみをプロビジョニングしていました。現在は、GPU Operator を使用して、GPU で高速化された仮想マシンを実行するためのワーカーノードもプロビジョニングできます。

GPU Operator を、どの GPU ワークロードがそのワーカーノード上で実行するように設定されたかに応じて、異なるソフトウェアコンポーネントをワーカーノードにデプロイするように設定できます。

GPU モニタリングダッシュボード
モニタリングダッシュボードをインストールして、OpenShift Container Platform Web コンソールのクラスターの Observe ページに、GPU の使用状況に関する情報を表示できます。GPU 使用状況に関する情報には、使用可能な GPU の数、消費電力 (ワット単位)、温度 (摂氏)、使用率 (パーセント)、および各 GPU のその他のメトリクスが含まれます。

第3章 AMD GPU Operator
リンクのコピー

OpenShift Container Platform クラスター内で AMD Instinct GPU アクセラレーターと AMD GPU Operator を併用することで、機械学習、生成 AI、および GPU アクセラレーションアプリケーション向けのコンピューティング能力をシームレスに活用できます。

このドキュメントでは、AMD GPU Operator を有効化、設定、テストするために必要な情報を提供します。詳細は、AMD Instinct™ Accelerators を参照してください。

3.1. AMD GPU Operator について
リンクのコピー

AMD GPU Operator のハードウェアアクセラレーション機能は、Red Hat OpenShift AI を使用して人工知能および機械学習 (AI/ML) アプリケーションを作成するデータサイエンティストや開発者に、高いパフォーマンスとコスト効率を提供します。GPU 機能の特定の領域を高速化すると、CPU 処理とメモリー使用量を最小限に抑え、全体的なアプリケーション速度、メモリー消費、帯域幅の制約を改善できます。

3.2. AMD GPU Operator のインストール
リンクのコピー

クラスター管理者は、OpenShift CLI と Web コンソールを使用して AMD GPU Operator をインストールできます。これは複数のステップから成る手順であり、Node Feature Discovery Operator、Kernel Module Management Operator、AMD GPU Operator のインストールが必要です。Operator の AMD コミュニティー版リリースをインストールするには、次の手順を順に実行します。

次のステップ

  1. Node Feature Discovery Operator をインストールします。
  2. Kernel Module Management Operator をインストールします。
  3. AMD GPU Operator をインストールして設定します。

3.3. AMD GPU Operator のテスト
リンクのコピー

ROCmInfo のインストールをテストし、AMD MI210 GPU のログを表示するには、次の手順を使用します。

手順

  1. ROCmInfo をテストする YAML ファイルを作成します。 

    $ cat << EOF > rocminfo.yaml

apiVersion: v1
kind: Pod
metadata:
 name: rocminfo
spec:
 containers:
 - image: docker.io/rocm/pytorch:latest
   name: rocminfo
   command: ["/bin/sh","-c"]
   args: ["rocminfo"]
   resources:
    limits:
      amd.com/gpu: 1
    requests:
      amd.com/gpu: 1
 restartPolicy: Never
EOF

  2. rocminfo Pod を作成します。 

    $ oc create -f rocminfo.yaml

    出力例

    apiVersion: v1
pod/rocminfo created

  3. 1 つの MI210 GPU を含む rocmnfo ログを確認します。 

    $ oc logs rocminfo | grep -A5 "Agent"

    出力例

    HSA Agents
==========
*******
Agent 1
*******
  Name:                    Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
  Uuid:                    CPU-XX
  Marketing Name:          Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
  Vendor Name:             CPU
--
Agent 2
*******
  Name:                    Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
  Uuid:                    CPU-XX
  Marketing Name:          Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
  Vendor Name:             CPU
--
Agent 3
*******
  Name:                    gfx90a
  Uuid:                    GPU-024b776f768a638b
  Marketing Name:          AMD Instinct MI210
  Vendor Name:             AMD

  4. Pod を削除します。 

    $ oc delete -f rocminfo.yaml

    出力例

    pod "rocminfo" deleted

第4章 Intel Gaudi AI アクセラレーター
リンクのコピー

OpenShift Container Platform の生成 AI および機械学習 (AI/ML) アプリケーションに Intel Gaudi AI アクセラレーターを使用できます。Intel Gaudi AI アクセラレーターは、コスト効率が高く、柔軟性と拡張性に優れたソリューションを提供し、最適化されたディープラーニングワークロードを実現します。

Red Hat は Intel Gaudi 2 および Intel Gaudi 3 デバイスをサポートしています。Intel Gaudi 3 デバイスは、トレーニング速度とエネルギー効率を大幅に向上させます。

4.1. Intel Gaudi AI アクセラレーターの前提条件
リンクのコピー

  • 少なくとも 1 つの GPU ワーカーノードを備えた OpenShift Container Platform クラスターが動作している。
  • 必要な手順を実行できるように、cluster-admin として OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Node Feature Discovery (NFD) Operator をインストールし、NodeFeatureDiscovery インスタンスを作成した。

第5章 NVIDIA GPUDirect Remote Direct Memory Access (RDMA)
リンクのコピー

NVIDIA GPUDirect Remote Direct Memory Access (RDMA) を使用すると、オペレーティングシステムを介さずに、1 台のコンピューターのアプリケーションから別のコンピューターのメモリーに直接アクセスできます。これにより、プロセスにおけるカーネルの介入を回避できるため、リソースが解放され、ネットワーク通信の処理に通常必要な CPU オーバーヘッドが大幅に削減されます。これは、GPU で高速化されたワークロードをクラスター全体に分散するのに役立ちます。RDMA は高帯域幅と低レイテンシーのアプリケーションに非常に適しているため、ビッグデータや機械学習のアプリケーションに最適です。

現在、NVIDIA GPUDirect RDMA には 3 つの設定方法があります。

共有デバイス
この方法では、NVIDIA GPUDirect RDMA デバイスを、デバイスが公開されている OpenShift Container Platform ワーカーノード上の複数の Pod 間で共有できます。
ホストデバイス
この方法では、Pod に追加のホストネットワークを作成することにより、ワーカーノード上で直接の物理イーサネットアクセスを提供します。プラグインを使用すると、ネットワークデバイスをホストのネットワーク namespace から Pod 上のネットワーク namespace に移動できます。
SR-IOV レガシーデバイス
Single Root IO Virtualization (SR-IOV) 方式では、イーサネットアダプターなどの単一のネットワークデバイスを複数の Pod と共有できます。SR-IOV は、ホストノード上で Physical Function (PF) として認識されるデバイスを、複数の Virtual Function (VF) に分割します。VF は他のネットワークデバイスと同様に使用されます。

これらの各方法は、NVIDIA GPUDirect RDMA over Converged Ethernet (RoCE) または Infiniband インフラストラクチャーで使用できます。そのため、設定方法は合計で 6 つあります。

5.1. NVIDIA GPUDirect RDMA の前提条件
リンクのコピー

NVIDIA GPUDirect RDMA のどの設定方法でも、特定の Operator のインストールが必要です。Operator をインストールするには、次の手順を実行します。

5.2. IRDMA カーネルモジュールの無効化
リンクのコピー

一部のシステム (DellR750xa など) では、DOCA ドライバーをアンロードおよびロードするときに、IRDMA カーネルモジュールによって NVIDIA Network Operator の問題が発生します。モジュールを無効にするには、次の手順を実行します。

手順

  1. 次のコマンドを実行して、次のマシン設定ファイルを生成します。 

    $ cat <<EOF > 99-machine-config-blacklist-irdma.yaml

    出力例

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-blacklist-irdma
spec:
  kernelArguments:
    - "module_blacklist=irdma"

  2. 次のコマンドを実行して、クラスターにマシン設定を作成し、ノードが再起動するのを待ちます。 

    $ oc create -f 99-machine-config-blacklist-irdma.yaml

    出力例

    machineconfig.machineconfiguration.openshift.io/99-worker-blacklist-irdma created

  3. 次のコマンドを実行して、各ノードのデバッグ Pod でモジュールがロードされていないことを確認します。 

    $ oc debug node/nvd-srv-32.nvidia.eng.rdu2.dc.redhat.com
Starting pod/nvd-srv-32nvidiaengrdu2dcredhatcom-debug-btfj2 ...
To use host binaries, run `chroot /host`
Pod IP: 10.6.135.11
If you don't see a command prompt, try pressing enter.
sh-5.1# chroot /host
sh-5.1# lsmod|grep irdma
sh-5.1#

5.3. 永続的な命名規則の作成
リンクのコピー

場合によっては、再起動後にデバイス名が保持されないことがあります。たとえば、R760xa システムでは、再起動後に Mellanox デバイスの名前が変更される可能性があります。この問題は、MachineConfig を使用して永続性を設定することで回避できます。

手順

  1. ノードのワーカーノードから MAC アドレス名をファイルに収集し、永続化する必要があるインターフェイスの名前を指定します。この例では、ファイル 70-persistent-net.rules を使用し、その中に詳細を保存します。 

    $ cat <<EOF > 70-persistent-net.rules
SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="b8:3f:d2:3b:51:28",ATTR{type}=="1",NAME="ibs2f0"
SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="b8:3f:d2:3b:51:29",ATTR{type}=="1",NAME="ens8f0np0"
SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="b8:3f:d2:f0:36:d0",ATTR{type}=="1",NAME="ibs2f0"
SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="b8:3f:d2:f0:36:d1",ATTR{type}=="1",NAME="ens8f0np0"
EOF

  2. このファイルを改行なしの base64 文字列に変換し、出力を変数 PERSIST に設定します。 

    $ PERSIST=`cat 70-persistent-net.rules| base64 -w 0`

$ echo $PERSIST
U1VCU1lTVEVNPT0ibmV0IixBQ1RJT049PSJhZGQiLEFUVFJ7YWRkcmVzc309PSJiODozZjpkMjozYjo1MToyOCIsQVRUUnt0eXBlfT09IjEiLE5BTUU9ImliczJmMCIKU1VCU1lTVEVNPT0ibmV0IixBQ1RJT049PSJhZGQiLEFUVFJ7YWRkcmVzc309PSJiODozZjpkMjozYjo1MToyOSIsQVRUUnt0eXBlfT09IjEiLE5BTUU9ImVuczhmMG5wMCIKU1VCU1lTVEVNPT0ibmV0IixBQ1RJT049PSJhZGQiLEFUVFJ7YWRkcmVzc309PSJiODozZjpkMjpmMDozNjpkMCIsQVRUUnt0eXBlfT09IjEiLE5BTUU9ImliczJmMCIKU1VCU1lTVEVNPT0ibmV0IixBQ1RJT049PSJhZGQiLEFUVFJ7YWRkcmVzc309PSJiODozZjpkMjpmMDozNjpkMSIsQVRUUnt0eXBlfT09IjEiLE5BTUU9ImVuczhmMG5wMCIK

  3. 次のコマンドを実行して、マシン設定を作成し、カスタムリソースファイルで base64 エンコードを設定します。 

    $ cat <<EOF > 99-machine-config-udev-network.yaml
     
    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
   labels:
     machineconfiguration.openshift.io/role: worker
   name: 99-machine-config-udev-network
spec:
   config:
     ignition:
       version: 3.2.0
     storage:
       files:
       - contents:
           source: data:text/plain;base64,$PERSIST
         filesystem: root
         mode: 420
         path: /etc/udev/rules.d/70-persistent-net.rules

  4. 次のコマンドを実行して、クラスターにマシン設定を作成します。 

    $ oc create -f 99-machine-config-udev-network.yaml

    出力例

    machineconfig.machineconfiguration.openshift.io/99-machine-config-udev-network created

  5. get mcp コマンドを使用して、マシン設定のステータスを表示します。 

    $ oc get mcp

    出力例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-9adfe851c2c14d9598eea5ec3df6c187   True      False      False      1              1                   1                     0                      6h21m
worker   rendered-worker-4568f1b174066b4b1a4de794cf538fee   False     True       False      2              0                   0                     0                      6h21m

ノードが再起動し、更新フィールドが false に戻ったら、デバッグ Pod でデバイスを調べてノードを検証できます。

5.4. NFD Operator の設定
リンクのコピー

Node Feature Discovery (NFD) Operator は、ノードにハードウェア固有の情報をラベル付けすることで、OpenShift Container Platform クラスター内のハードウェア機能と設定の検出を管理します。NFD は、PCI カード、カーネル、オペレーティングシステムのバージョンなど、ノード固有の属性でホストにラベルを付けます。

前提条件

  • NFD Operator がインストールされている。

手順

  1. 次のコマンドを実行して、openshift-nfd namespace 内の Pod を確認し、Operator がインストールされ、実行されていることを確認します。 

    $ oc get pods -n openshift-nfd

    出力例

    NAME                                      READY   STATUS    RESTARTS   AGE
nfd-controller-manager-8698c88cdd-t8gbc   2/2     Running   0          2m

  2. NFD コントローラーを実行している状態で、NodeFeatureDiscovery インスタンスを生成し、クラスターに追加します。

    NFD Operator の ClusterServiceVersion 仕様では、Operator ペイロードの一部である NFD オペランドイメージなどのデフォルト値が指定されています。次のコマンドを実行してその値を取得します。 

    $ NFD_OPERAND_IMAGE=`echo $(oc get csv -n openshift-nfd -o json | jq -r '.items[0].metadata.annotations["alm-examples"]') | jq -r '.[] | select(.kind == "NodeFeatureDiscovery") | .spec.operand.image'`

  3. オプション: より多くのネットワークアダプター (NVIDIA BlueField DPU など) をサポートするには、デフォルトの deviceClassWhiteList フィールドにエントリーを追加します。 

    apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
  name: nfd-instance
  namespace: openshift-nfd
spec:
  instance: ''
  operand:
    image: '${NFD_OPERAND_IMAGE}'
    servicePort: 12000
  prunerOnDelete: false
  topologyUpdater: false
  workerConfig:
    configData: |
      core:
        sleepInterval: 60s
      sources:
        pci:
          deviceClassWhitelist:
            - "02"
            - "03"
            - "0200"
            - "0207"
            - "12"
          deviceLabelFields:
            - "vendor"

  4. 次のコマンドを実行して、'NodeFeatureDiscovery` のインスタンスを作成します。 

    $ oc create -f nfd-instance.yaml

    出力例

    nodefeaturediscovery.nfd.openshift.io/nfd-instance created

  5. 次のコマンドを実行して、openshift-nfd namespace 配下の Pod を確認し、インスタンスが起動して実行されていることを確認します。 

    $ oc get pods -n openshift-nfd

    出力例

    NAME                                    READY   STATUS    RESTARTS   AGE
nfd-controller-manager-7cb6d656-jcnqb   2/2     Running   0          4m
nfd-gc-7576d64889-s28k9                 1/1     Running   0          21s
nfd-master-b7bcf5cfd-qnrmz              1/1     Running   0          21s
nfd-worker-96pfh                        1/1     Running   0          21s
nfd-worker-b2gkg                        1/1     Running   0          21s
nfd-worker-bd9bk                        1/1     Running   0          21s
nfd-worker-cswf4                        1/1     Running   0          21s
nfd-worker-kp6gg                        1/1     Running   0          21s

  6. しばらく待ってから、NFD によってノードにラベルが追加されたことを確認します。NFD のラベルには feature.node.kubernetes.io という接頭辞が付いているため、簡単にフィルタリングできます。 

    $ oc get node -o json | jq '.items[0].metadata.labels | with_entries(select(.key | startswith("feature.node.kubernetes.io")))'
{
  "feature.node.kubernetes.io/cpu-cpuid.ADX": "true",
  "feature.node.kubernetes.io/cpu-cpuid.AESNI": "true",
  "feature.node.kubernetes.io/cpu-cpuid.AVX": "true",
  "feature.node.kubernetes.io/cpu-cpuid.AVX2": "true",
  "feature.node.kubernetes.io/cpu-cpuid.CETSS": "true",
  "feature.node.kubernetes.io/cpu-cpuid.CLZERO": "true",
  "feature.node.kubernetes.io/cpu-cpuid.CMPXCHG8": "true",
  "feature.node.kubernetes.io/cpu-cpuid.CPBOOST": "true",
  "feature.node.kubernetes.io/cpu-cpuid.EFER_LMSLE_UNS": "true",
  "feature.node.kubernetes.io/cpu-cpuid.FMA3": "true",
  "feature.node.kubernetes.io/cpu-cpuid.FP256": "true",
  "feature.node.kubernetes.io/cpu-cpuid.FSRM": "true",
  "feature.node.kubernetes.io/cpu-cpuid.FXSR": "true",
  "feature.node.kubernetes.io/cpu-cpuid.FXSROPT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBPB": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBRS": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBRS_PREFERRED": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBRS_PROVIDES_SMP": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBS": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSBRNTRGT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSFETCHSAM": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSFFV": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSOPCNT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSOPCNTEXT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSOPSAM": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSRDWROPCNT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBSRIPINVALIDCHK": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBS_FETCH_CTLX": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBS_OPFUSE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.IBS_PREVENTHOST": "true",
  "feature.node.kubernetes.io/cpu-cpuid.INT_WBINVD": "true",
  "feature.node.kubernetes.io/cpu-cpuid.INVLPGB": "true",
  "feature.node.kubernetes.io/cpu-cpuid.LAHF": "true",
  "feature.node.kubernetes.io/cpu-cpuid.LBRVIRT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MCAOVERFLOW": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MCOMMIT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MOVBE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MOVU": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MSRIRC": "true",
  "feature.node.kubernetes.io/cpu-cpuid.MSR_PAGEFLUSH": "true",
  "feature.node.kubernetes.io/cpu-cpuid.NRIPS": "true",
  "feature.node.kubernetes.io/cpu-cpuid.OSXSAVE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.PPIN": "true",
  "feature.node.kubernetes.io/cpu-cpuid.PSFD": "true",
  "feature.node.kubernetes.io/cpu-cpuid.RDPRU": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_64BIT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_ALTERNATIVE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_DEBUGSWAP": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_ES": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_RESTRICTED": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SEV_SNP": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SHA": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SME": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SME_COHERENT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SPEC_CTRL_SSBD": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SSE4A": "true",
  "feature.node.kubernetes.io/cpu-cpuid.STIBP": "true",
  "feature.node.kubernetes.io/cpu-cpuid.STIBP_ALWAYSON": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SUCCOR": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVM": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVMDA": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVMFBASID": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVML": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVMNP": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVMPF": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SVMPFT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SYSCALL": "true",
  "feature.node.kubernetes.io/cpu-cpuid.SYSEE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.TLB_FLUSH_NESTED": "true",
  "feature.node.kubernetes.io/cpu-cpuid.TOPEXT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.TSCRATEMSR": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VAES": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VMCBCLEAN": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VMPL": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VMSA_REGPROT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VPCLMULQDQ": "true",
  "feature.node.kubernetes.io/cpu-cpuid.VTE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.WBNOINVD": "true",
  "feature.node.kubernetes.io/cpu-cpuid.X87": "true",
  "feature.node.kubernetes.io/cpu-cpuid.XGETBV1": "true",
  "feature.node.kubernetes.io/cpu-cpuid.XSAVE": "true",
  "feature.node.kubernetes.io/cpu-cpuid.XSAVEC": "true",
  "feature.node.kubernetes.io/cpu-cpuid.XSAVEOPT": "true",
  "feature.node.kubernetes.io/cpu-cpuid.XSAVES": "true",
  "feature.node.kubernetes.io/cpu-hardware_multithreading": "false",
  "feature.node.kubernetes.io/cpu-model.family": "25",
  "feature.node.kubernetes.io/cpu-model.id": "1",
  "feature.node.kubernetes.io/cpu-model.vendor_id": "AMD",
  "feature.node.kubernetes.io/kernel-config.NO_HZ": "true",
  "feature.node.kubernetes.io/kernel-config.NO_HZ_FULL": "true",
  "feature.node.kubernetes.io/kernel-selinux.enabled": "true",
  "feature.node.kubernetes.io/kernel-version.full": "5.14.0-427.35.1.el9_4.x86_64",
  "feature.node.kubernetes.io/kernel-version.major": "5",
  "feature.node.kubernetes.io/kernel-version.minor": "14",
  "feature.node.kubernetes.io/kernel-version.revision": "0",
  "feature.node.kubernetes.io/memory-numa": "true",
  "feature.node.kubernetes.io/network-sriov.capable": "true",
  "feature.node.kubernetes.io/pci-102b.present": "true",
  "feature.node.kubernetes.io/pci-10de.present": "true",
  "feature.node.kubernetes.io/pci-10de.sriov.capable": "true",
  "feature.node.kubernetes.io/pci-15b3.present": "true",
  "feature.node.kubernetes.io/pci-15b3.sriov.capable": "true",
  "feature.node.kubernetes.io/rdma.available": "true",
  "feature.node.kubernetes.io/rdma.capable": "true",
  "feature.node.kubernetes.io/storage-nonrotationaldisk": "true",
  "feature.node.kubernetes.io/system-os_release.ID": "rhcos",
  "feature.node.kubernetes.io/system-os_release.OPENSHIFT_VERSION": "4.17",
  "feature.node.kubernetes.io/system-os_release.OSTREE_VERSION": "417.94.202409121747-0",
  "feature.node.kubernetes.io/system-os_release.RHEL_VERSION": "9.4",
  "feature.node.kubernetes.io/system-os_release.VERSION_ID": "4.17",
  "feature.node.kubernetes.io/system-os_release.VERSION_ID.major": "4",
  "feature.node.kubernetes.io/system-os_release.VERSION_ID.minor": "17"
}

  7. 検出されたネットワークデバイスがあることを確認します。 

    $ oc describe node | grep -E 'Roles|pci' | grep pci-15b3
                    feature.node.kubernetes.io/pci-15b3.present=true
                    feature.node.kubernetes.io/pci-15b3.sriov.capable=true
                    feature.node.kubernetes.io/pci-15b3.present=true
                    feature.node.kubernetes.io/pci-15b3.sriov.capable=true

5.5. SR-IOV Operator の設定
リンクのコピー

Single Root I/O Virtualization (SR-IOV) は、単一のデバイスを複数の Pod 間で共有できるようにすることで、NVIDIA GPUDirect RDMA のパフォーマンスを向上させます。

前提条件

  • SR-IOV Operator がインストールされている。

手順

  1. 次のコマンドを実行して、openshift-sriov-network-operator namespace 内の Pod を確認し、Operator がインストールされ、実行されていることを確認します。 

    $ oc get pods -n openshift-sriov-network-operator

    出力例

    NAME                                      READY   STATUS    RESTARTS   AGE
sriov-network-operator-7cb6c49868-89486   1/1     Running   0          22s

  2. デフォルトの SriovOperatorConfig CR を MLNX_OFED コンテナーで動作させるために、次のコマンドを実行して次の値を更新します。 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 2

  3. 次のコマンドを実行して、クラスターにリソースを作成します。 

    $ oc create -f sriov-operator-config.yaml

    出力例

    sriovoperatorconfig.sriovnetwork.openshift.io/default created

  4. 次のコマンドを実行して、sriov-operator にパッチを適用し、MOFED コンテナーと連携できるようにします。 

    $ oc patch sriovoperatorconfig default   --type=merge -n openshift-sriov-network-operator   --patch '{ "spec": { "configDaemonNodeSelector": { "network.nvidia.com/operator.mofed.wait": "false", "node-role.kubernetes.io/worker": "", "feature.node.kubernetes.io/pci-15b3.sriov.capable": "true" } } }'

    出力例

    sriovoperatorconfig.sriovnetwork.openshift.io/default patched

5.6. NVIDIA Network Operator の設定
リンクのコピー

NVIDIA Network Operator は、NVIDIA GPUDirect RDMA ワークロードを有効にするために、NVIDIA ネットワークリソースと、ドライバーやデバイスプラグインなどのネットワーク関連コンポーネントを管理します。

前提条件

  • NVIDIA Network Operator がインストールされている。

手順

  1. 次のコマンドを実行して、コントローラーが nvidia-network-operator namespace で実行されていることを確認し、Network Operator がインストールされ、実行されていることを確認します。 

    $ oc get pods -n nvidia-network-operator

    出力例

    NAME                                                          READY   STATUS             RESTARTS        AGE
nvidia-network-operator-controller-manager-6f7d6956cd-fw5wg   1/1     Running            0                5m

  2. Operator を実行している状態で、NicClusterPolicy カスタムリソースファイルを作成します。実際に選択するデバイスはシステム構成によって異なります。この例では、Infiniband インターフェイス ibs2f0 がハードコードされており、共有 NVIDIA GPUDirect RDMA デバイスとして使用されます。 

    apiVersion: mellanox.com/v1alpha1
kind: NicClusterPolicy
metadata:
  name: nic-cluster-policy
spec:
  nicFeatureDiscovery:
    image: nic-feature-discovery
    repository: ghcr.io/mellanox
    version: v0.0.1
  docaTelemetryService:
    image: doca_telemetry
    repository: nvcr.io/nvidia/doca
    version: 1.16.5-doca2.6.0-host
  rdmaSharedDevicePlugin:
    config: |
      {
        "configList": [
          {
            "resourceName": "rdma_shared_device_ib",
            "rdmaHcaMax": 63,
            "selectors": {
              "ifNames": ["ibs2f0"]
            }
          },
          {
            "resourceName": "rdma_shared_device_eth",
            "rdmaHcaMax": 63,
            "selectors": {
              "ifNames": ["ens8f0np0"]
            }
          }
        ]
      }
    image: k8s-rdma-shared-dev-plugin
    repository: ghcr.io/mellanox
    version: v1.5.1
  secondaryNetwork:
    ipoib:
      image: ipoib-cni
      repository: ghcr.io/mellanox
      version: v1.2.0
  nvIpam:
    enableWebhook: false
    image: nvidia-k8s-ipam
    repository: ghcr.io/mellanox
    version: v0.2.0
  ofedDriver:
    readinessProbe:
      initialDelaySeconds: 10
      periodSeconds: 30
    forcePrecompiled: false
    terminationGracePeriodSeconds: 300
    livenessProbe:
      initialDelaySeconds: 30
      periodSeconds: 30
    upgradePolicy:
      autoUpgrade: true
      drain:
        deleteEmptyDir: true
        enable: true
        force: true
        timeoutSeconds: 300
        podSelector: ''
      maxParallelUpgrades: 1
      safeLoad: false
      waitForCompletion:
        timeoutSeconds: 0
    startupProbe:
      initialDelaySeconds: 10
      periodSeconds: 20
    image: doca-driver
    repository: nvcr.io/nvidia/mellanox
    version: 24.10-0.7.0.0-0
    env:
    - name: UNLOAD_STORAGE_MODULES
      value: "true"
    - name: RESTORE_DRIVER_ON_POD_TERMINATION
      value: "true"
    - name: CREATE_IFNAMES_UDEV
      value: "true"

  3. 次のコマンドを実行して、クラスターに NicClusterPolicy カスタムリソースを作成します。 

    $ oc create -f network-sharedrdma-nic-cluster-policy.yaml

    出力例

    nicclusterpolicy.mellanox.com/nic-cluster-policy created

  4. DOCA/MOFED コンテナーで次のコマンドを実行して、NicClusterPolicy を検証します。 

    $ oc get pods -n nvidia-network-operator

    出力例

    NAME                                                          READY   STATUS    RESTARTS   AGE
doca-telemetry-service-hwj65                                  1/1     Running   2          160m
kube-ipoib-cni-ds-fsn8g                                       1/1     Running   2          160m
mofed-rhcos4.16-9b5ddf4c6-ds-ct2h5                            2/2     Running   4          160m
nic-feature-discovery-ds-dtksz                                1/1     Running   2          160m
nv-ipam-controller-854585f594-c5jpp                           1/1     Running   2          160m
nv-ipam-controller-854585f594-xrnp5                           1/1     Running   2          160m
nv-ipam-node-xqttl                                            1/1     Running   2          160m
nvidia-network-operator-controller-manager-5798b564cd-5cq99   1/1     Running   2         5d23h
rdma-shared-dp-ds-p9vvg                                       1/1     Running   0          85m

  5. mofed コンテナーに rsh で接続し、次のコマンドを実行してステータスを確認します。 

    $ MOFED_POD=$(oc get pods -n nvidia-network-operator -o name | grep mofed)
$ oc rsh -n nvidia-network-operator -c mofed-container ${MOFED_POD}
sh-5.1# ofed_info -s

    出力例

    OFED-internal-24.07-0.6.1:
     

    sh-5.1# ibdev2netdev -v

    出力例

    0000:0d:00.0 mlx5_0 (MT41692 - 900-9D3B4-00EN-EA0) BlueField-3 E-series SuperNIC 400GbE/NDR single port QSFP112, PCIe Gen5.0 x16 FHHL, Crypto Enabled, 16GB DDR5, BMC, Tall Bracket                                                       fw 32.42.1000 port 1 (ACTIVE) ==> ibs2f0 (Up)
0000:a0:00.0 mlx5_1 (MT41692 - 900-9D3B4-00EN-EA0) BlueField-3 E-series SuperNIC 400GbE/NDR single port QSFP112, PCIe Gen5.0 x16 FHHL, Crypto Enabled, 16GB DDR5, BMC, Tall Bracket                                                       fw 32.42.1000 port 1 (ACTIVE) ==> ens8f0np0 (Up)

  6. IPoIBNetwork カスタムリソースファイルを作成します。 

    apiVersion: mellanox.com/v1alpha1
kind: IPoIBNetwork
metadata:
  name: example-ipoibnetwork
spec:
  ipam: |
    {
      "type": "whereabouts",
      "range": "192.168.6.225/28",
      "exclude": [
       "192.168.6.229/30",
       "192.168.6.236/32"
      ]
    }
  master: ibs2f0
  networkNamespace: default

  7. 次のコマンドを実行して、クラスターに IPoIBNetwork リソースを作成します。 

    $ oc create -f ipoib-network.yaml

    出力例

    ipoibnetwork.mellanox.com/example-ipoibnetwork created

  8. 他のインターフェイス用に MacvlanNetwork カスタムリソースファイルを作成します。 

    apiVersion: mellanox.com/v1alpha1
kind: MacvlanNetwork
metadata:
  name: rdmashared-net
spec:
  networkNamespace: default
  master: ens8f0np0
  mode: bridge
  mtu: 1500
  ipam: '{"type": "whereabouts", "range": "192.168.2.0/24", "gateway": "192.168.2.1"}'

  9. 次のコマンドを実行して、クラスターにリソースを作成します。 

    $ oc create -f macvlan-network.yaml

    出力例

    macvlannetwork.mellanox.com/rdmashared-net created

5.7. GPU Operator の設定
リンクのコピー

GPU Operator は、NVIDIA ドライバー、GPU のデバイスプラグイン、NVIDIA Container Toolkit、および GPU プロビジョニングに必要なその他のコンポーネントの管理を自動化します。

前提条件

  • GPU Operator がインストールされている。

手順

  1. 次のコマンドを実行して、Operator Pod が実行されていることを確認し、namespace 配下の Pod を確認します。 

    $ oc get pods -n nvidia-gpu-operator

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE
gpu-operator-b4cb7d74-zxpwq   1/1     Running   0          32s

  2. 次の例のような GPU クラスターポリシーのカスタムリソースファイルを作成します。 

    apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
  name: gpu-cluster-policy
spec:
  vgpuDeviceManager:
    config:
      default: default
    enabled: true
  migManager:
    config:
      default: all-disabled
      name: default-mig-parted-config
    enabled: true
  operator:
    defaultRuntime: crio
    initContainer: {}
    runtimeClass: nvidia
    use_ocp_driver_toolkit: true
  dcgm:
    enabled: true
  gfd:
    enabled: true
  dcgmExporter:
    config:
      name: ''
    serviceMonitor:
      enabled: true
    enabled: true
  cdi:
    default: false
    enabled: false
  driver:
    licensingConfig:
      nlsEnabled: true
      configMapName: ''
    certConfig:
      name: ''
    rdma:
      enabled: false
    kernelModuleConfig:
      name: ''
    upgradePolicy:
      autoUpgrade: true
      drain:
        deleteEmptyDir: false
        enable: false
        force: false
        timeoutSeconds: 300
      maxParallelUpgrades: 1
      maxUnavailable: 25%
      podDeletion:
        deleteEmptyDir: false
        force: false
        timeoutSeconds: 300
      waitForCompletion:
        timeoutSeconds: 0
    repoConfig:
      configMapName: ''
    virtualTopology:
      config: ''
    enabled: true
    useNvidiaDriverCRD: false
    useOpenKernelModules: true
  devicePlugin:
    config:
      name: ''
      default: ''
    mps:
      root: /run/nvidia/mps
    enabled: true
  gdrcopy:
    enabled: true
  kataManager:
    config:
      artifactsDir: /opt/nvidia-gpu-operator/artifacts/runtimeclasses
  mig:
    strategy: single
  sandboxDevicePlugin:
    enabled: true
  validator:
    plugin:
      env:
        - name: WITH_WORKLOAD
          value: 'false'
  nodeStatusExporter:
    enabled: true
  daemonsets:
    rollingUpdate:
      maxUnavailable: '1'
    updateStrategy: RollingUpdate
  sandboxWorkloads:
    defaultWorkload: container
    enabled: false
  gds:
    enabled: true
    image: nvidia-fs
    version: 2.20.5
    repository: nvcr.io/nvidia/cloud-native
  vgpuManager:
    enabled: false
  vfioManager:
    enabled: true
  toolkit:
    installDir: /usr/local/nvidia
    enabled: true

  3. GPU ClusterPolicy カスタムリソースが生成されたら、次のコマンドを実行してクラスターにリソースを作成します。 

    $ oc create -f gpu-cluster-policy.yaml

    出力例

    clusterpolicy.nvidia.com/gpu-cluster-policy created

  4. 次のコマンドを実行して、Operator がインストールされ、実行されていることを確認します。 

    $ oc get pods -n nvidia-gpu-operator

    出力例

    NAME                                                  READY   STATUS      RESTARTS   AGE
gpu-feature-discovery-d5ngn                           1/1     Running     0          3m20s
gpu-feature-discovery-z42rx                           1/1     Running     0          3m23s
gpu-operator-6bb4d4b4c5-njh78                         1/1     Running     0          4m35s
nvidia-container-toolkit-daemonset-bkh8l              1/1     Running     0          3m20s
nvidia-container-toolkit-daemonset-c4hzm              1/1     Running     0          3m23s
nvidia-cuda-validator-4blvg                           0/1     Completed   0          106s
nvidia-cuda-validator-tw8sl                           0/1     Completed   0          112s
nvidia-dcgm-exporter-rrw4g                            1/1     Running     0          3m20s
nvidia-dcgm-exporter-xc78t                            1/1     Running     0          3m23s
nvidia-dcgm-nvxpf                                     1/1     Running     0          3m20s
nvidia-dcgm-snj4j                                     1/1     Running     0          3m23s
nvidia-device-plugin-daemonset-fk2xz                  1/1     Running     0          3m23s
nvidia-device-plugin-daemonset-wq87j                  1/1     Running     0          3m20s
nvidia-driver-daemonset-416.94.202410211619-0-ngrjg   4/4     Running     0          3m58s
nvidia-driver-daemonset-416.94.202410211619-0-tm4x6   4/4     Running     0          3m58s
nvidia-node-status-exporter-jlzxh                     1/1     Running     0          3m57s
nvidia-node-status-exporter-zjffs                     1/1     Running     0          3m57s
nvidia-operator-validator-l49hx                       1/1     Running     0          3m20s
nvidia-operator-validator-n44nn                       1/1     Running     0          3m23s

  5. オプション: Pod が実行中であることを確認したら、NVIDIA ドライバーの daemonset Pod でリモートシェルを起動し、NVIDIA モジュールがロードされていることを確認します。具体的には、nvidia_peermem がロードされていることを確認します。 

    $ oc rsh -n nvidia-gpu-operator $(oc -n nvidia-gpu-operator get pod -o name -l app.kubernetes.io/component=nvidia-driver)
sh-4.4# lsmod|grep nvidia

    出力例

    nvidia_fs             327680  0
nvidia_peermem         24576  0
nvidia_modeset       1507328  0
video                  73728  1 nvidia_modeset
nvidia_uvm           6889472  8
nvidia               8810496  43 nvidia_uvm,nvidia_peermem,nvidia_fs,gdrdrv,nvidia_modeset
ib_uverbs             217088  3 nvidia_peermem,rdma_ucm,mlx5_ib
drm                   741376  5 drm_kms_helper,drm_shmem_helper,nvidia,mgag200

  6. オプション: nvidia-smi ユーティリティーを実行して、ドライバーとハードウェアの詳細を表示します。 
sh-4.4# nvidia-smi

+ 出力例 

Wed Nov  6 22:03:53 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07              Driver Version: 550.90.07      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A40                     On  |   00000000:61:00.0 Off |                    0 |
|  0%   37C    P0             88W /  300W |       1MiB /  46068MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA A40                     On  |   00000000:E1:00.0 Off |                    0 |
|  0%   28C    P8             29W /  300W |       1MiB /  46068MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

  1. ドライバーの Pod に接続したまま、nvidia-smi コマンドを使用して GPU クロックを最大に設定します。 

    $ oc rsh -n nvidia-gpu-operator nvidia-driver-daemonset-416.94.202410172137-0-ndhzc
sh-4.4# nvidia-smi -i 0 -lgc $(nvidia-smi -i 0 --query-supported-clocks=graphics --format=csv,noheader,nounits | sort -h | tail -n 1)

    出力例

    GPU clocks set to "(gpuClkMin 1740, gpuClkMax 1740)" for GPU 00000000:61:00.0
All done.
     

    sh-4.4# nvidia-smi -i 1 -lgc $(nvidia-smi -i 1 --query-supported-clocks=graphics --format=csv,noheader,nounits | sort -h | tail -n 1)

    出力例

    GPU clocks set to "(gpuClkMin 1740, gpuClkMax 1740)" for GPU 00000000:E1:00.0
All done.

  2. 次のコマンドを実行して、リソースが利用可能であることをノードの詳細情報で確認します。 

    $ oc describe node -l node-role.kubernetes.io/worker=| grep -E 'Capacity:|Allocatable:' -A9

    出力例

    Capacity:
  cpu:                          128
  ephemeral-storage:            1561525616Ki
  hugepages-1Gi:                0
  hugepages-2Mi:                0
  memory:                       263596712Ki
  nvidia.com/gpu:               2
  pods:                         250
  rdma/rdma_shared_device_eth:  63
  rdma/rdma_shared_device_ib:   63
Allocatable:
  cpu:                          127500m
  ephemeral-storage:            1438028263499
  hugepages-1Gi:                0
  hugepages-2Mi:                0
  memory:                       262445736Ki
  nvidia.com/gpu:               2
  pods:                         250
  rdma/rdma_shared_device_eth:  63
  rdma/rdma_shared_device_ib:   63
--
Capacity:
  cpu:                          128
  ephemeral-storage:            1561525616Ki
  hugepages-1Gi:                0
  hugepages-2Mi:                0
  memory:                       263596672Ki
  nvidia.com/gpu:               2
  pods:                         250
  rdma/rdma_shared_device_eth:  63
  rdma/rdma_shared_device_ib:   63
Allocatable:
  cpu:                          127500m
  ephemeral-storage:            1438028263499
  hugepages-1Gi:                0
  hugepages-2Mi:                0
  memory:                       262445696Ki
  nvidia.com/gpu:               2
  pods:                         250
  rdma/rdma_shared_device_eth:  63
  rdma/rdma_shared_device_ib:   63

5.8. マシン設定の作成
リンクのコピー

リソース Pod を作成する前に、ユーザー特権を必要とせずに GPU およびネットワークリソースへのアクセスを提供する machineconfig.yaml カスタムリソース (CR) を作成する必要があります。

手順

  1. Machineconfig CR を生成します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 02-worker-container-runtime
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZV0KZGVmYXVsdF91bGltaXRzID0gWwoibWVtbG9jaz0tMTotMSIKXQo=
        mode: 420
        overwrite: true
        path: /etc/crio/crio.conf.d/10-custom

5.9. ワークロード Pod の作成
リンクのコピー

共有デバイスとホストデバイス用のワークロード Pod を作成するには、このセクションの手順を使用します。

5.9.1. RoCE 上での共有デバイス RDMA の作成
リンクのコピー

NVIDIA Network Operator のために、RDMA over Converged Ethernet (RoCE) 上の共有デバイス RDMA 用のワークロード Pod を作成し、Pod の設定をテストします。

NVIDIA GPUDirect RDMA デバイスは、デバイスが公開される OpenShift Container Platform ワーカーノード上の Pod 間で共有されます。

前提条件

  • Operator が実行されていることを確認する。
  • NicClusterPolicy カスタムリソース (CR) が存在する場合は削除する。

手順

  1. カスタム Pod リソースを生成します。 

    $ cat <<EOF > rdma-eth-32-workload.yaml
apiVersion: v1
kind: Pod
metadata:
  name: rdma-eth-32-workload
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: rdmashared-net
spec:
  nodeSelector:
    kubernetes.io/hostname: nvd-srv-32.nvidia.eng.rdu2.dc.redhat.com
  containers:
  - image: quay.io/edge-infrastructure/nvidia-tools:0.1.5
    name: rdma-eth-32-workload
    resources:
      limits:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_eth: 1
      requests:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_eth: 1

EOF

$ cat <<EOF > rdma-eth-33-workload.yaml
apiVersion: v1
kind: Pod
metadata:
  name: rdma-eth-33-workload
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: rdmashared-net
spec:
  nodeSelector:
    kubernetes.io/hostname: nvd-srv-33.nvidia.eng.rdu2.dc.redhat.com
  containers:
  - image: quay.io/edge-infrastructure/nvidia-tools:0.1.5
    name: rdma-eth-33-workload
    securityContext:
      capabilities:
        add: [ "IPC_LOCK" ]
    resources:
      limits:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_eth: 1
      requests:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_eth: 1
EOF

  2. 次のコマンドを使用して、クラスターに Pod を作成します。 

    $ oc create -f rdma-eth-32-workload.yaml

    出力例

    pod/rdma-eth-32-workload created
     

    $ oc create -f rdma-eth-33-workload.yaml

    出力例

    pod/rdma-eth-33-workload created

  3. 次のコマンドを使用して、Pod が実行されていることを確認します。 

    $ oc get pods -n default

    出力例

    NAME                   READY   STATUS    RESTARTS   AGE
rdma-eth-32-workload   1/1     Running   0          25s
rdma-eth-33-workload   1/1     Running   0          22s

5.9.2. RoCE 上でのホストデバイス RDMA の作成
リンクのコピー

NVIDIA Network Operator のために、ホストデバイスの Remote Direct Memory Access (RDMA) 用のワークロード Pod を作成し、Pod の設定をテストします。

前提条件

  • Operator が実行されていることを確認する。
  • NicClusterPolicy カスタムリソース (CR) が存在する場合は削除する。

手順

  1. 以下に示すように、新しいホストデバイス NicClusterPolicy (CR) を生成します。 

    $ cat <<EOF > network-hostdev-nic-cluster-policy.yaml
apiVersion: mellanox.com/v1alpha1
kind: NicClusterPolicy
metadata:
  name: nic-cluster-policy
spec:
  ofedDriver:
    image: doca-driver
    repository: nvcr.io/nvidia/mellanox
    version: 24.10-0.7.0.0-0
    startupProbe:
      initialDelaySeconds: 10
      periodSeconds: 20
    livenessProbe:
      initialDelaySeconds: 30
      periodSeconds: 30
    readinessProbe:
      initialDelaySeconds: 10
      periodSeconds: 30
    env:
    - name: UNLOAD_STORAGE_MODULES
      value: "true"
    - name: RESTORE_DRIVER_ON_POD_TERMINATION
      value: "true"
    - name: CREATE_IFNAMES_UDEV
      value: "true"
  sriovDevicePlugin:
      image: sriov-network-device-plugin
      repository: ghcr.io/k8snetworkplumbingwg
      version: v3.7.0
      config: |
        {
          "resourceList": [
              {
                  "resourcePrefix": "nvidia.com",
                  "resourceName": "hostdev",
                  "selectors": {
                      "vendors": ["15b3"],
                      "isRdma": true
                  }
              }
          ]
        }
EOF

  2. 次のコマンドを使用して、クラスターに NicClusterPolicy CR を作成します。 

    $ oc create -f network-hostdev-nic-cluster-policy.yaml

    出力例

    nicclusterpolicy.mellanox.com/nic-cluster-policy created

  3. DOCA/MOFED コンテナーで次のコマンドを使用して、ホストデバイスの NicClusterPolicy CR を確認します。 

    $ oc get pods -n nvidia-network-operator

    出力例

    NAME                                                          READY   STATUS    RESTARTS   AGE
mofed-rhcos4.16-696886fcb4-ds-9sgvd                           2/2     Running   0          2m37s
mofed-rhcos4.16-696886fcb4-ds-lkjd4                           2/2     Running   0          2m37s
nvidia-network-operator-controller-manager-68d547dbbd-qsdkf   1/1     Running   0          141m
sriov-device-plugin-6v2nz                                     1/1     Running   0          2m14s
sriov-device-plugin-hc4t8                                     1/1     Running   0          2m14s

  4. 次のコマンドを使用して、リソースがクラスターの oc describe node セクションに表示されることを確認します。 

    $ oc describe node -l node-role.kubernetes.io/worker=| grep -E 'Capacity:|Allocatable:' -A7

    出力例

    Capacity:
  cpu:                 128
  ephemeral-storage:   1561525616Ki
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              263596708Ki
  nvidia.com/hostdev:  2
  pods:                250
Allocatable:
  cpu:                 127500m
  ephemeral-storage:   1438028263499
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              262445732Ki
  nvidia.com/hostdev:  2
  pods:                250
--
Capacity:
  cpu:                 128
  ephemeral-storage:   1561525616Ki
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              263596704Ki
  nvidia.com/hostdev:  2
  pods:                250
Allocatable:
  cpu:                 127500m
  ephemeral-storage:   1438028263499
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              262445728Ki
  nvidia.com/hostdev:  2
  pods:                250

  5. HostDeviceNetwork CR ファイルを作成します。 

    $ cat <<EOF >  hostdev-network.yaml
apiVersion: mellanox.com/v1alpha1
kind: HostDeviceNetwork
metadata:
  name: hostdev-net
spec:
  networkNamespace: "default"
  resourceName: "hostdev"
  ipam: |
    {
      "type": "whereabouts",
      "range": "192.168.3.225/28",
      "exclude": [
       "192.168.3.229/30",
       "192.168.3.236/32"
      ]
    }
EOF

  6. 次のコマンドを使用して、クラスターに HostDeviceNetwork リソースを作成します。 

    $ oc create -f hostdev-network.yaml

    出力例

    hostdevicenetwork.mellanox.com/hostdev-net created

  7. 次のコマンドを使用して、リソースがクラスターの oc describe node セクションに表示されることを確認します。 

    $ oc describe node -l node-role.kubernetes.io/worker=| grep -E 'Capacity:|Allocatable:' -A8

    出力例

    Capacity:
  cpu:                 128
  ephemeral-storage:   1561525616Ki
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              263596708Ki
  nvidia.com/gpu:      2
  nvidia.com/hostdev:  2
  pods:                250
Allocatable:
  cpu:                 127500m
  ephemeral-storage:   1438028263499
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              262445732Ki
  nvidia.com/gpu:      2
  nvidia.com/hostdev:  2
  pods:                250
--
Capacity:
  cpu:                 128
  ephemeral-storage:   1561525616Ki
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              263596680Ki
  nvidia.com/gpu:      2
  nvidia.com/hostdev:  2
  pods:                250
Allocatable:
  cpu:                 127500m
  ephemeral-storage:   1438028263499
  hugepages-1Gi:       0
  hugepages-2Mi:       0
  memory:              262445704Ki
  nvidia.com/gpu:      2
  nvidia.com/hostdev:  2
  pods:                250

5.9.3. RoCE 上での SR-IOV レガシーモード RDMA の作成
リンクのコピー

RoCE 上で Single Root I/O Virtualization (SR-IOV) レガシーモードホストデバイス RDMA を設定します。

手順

  1. 新しいホストデバイスの NicClusterPolicy カスタムリソース (CR) を生成します。 

    $ cat <<EOF > network-sriovleg-nic-cluster-policy.yaml
apiVersion: mellanox.com/v1alpha1
kind: NicClusterPolicy
metadata:
  name: nic-cluster-policy
spec:
  ofedDriver:
    image: doca-driver
    repository: nvcr.io/nvidia/mellanox
    version: 24.10-0.7.0.0-0
    startupProbe:
      initialDelaySeconds: 10
      periodSeconds: 20
    livenessProbe:
      initialDelaySeconds: 30
      periodSeconds: 30
    readinessProbe:
      initialDelaySeconds: 10
      periodSeconds: 30
    env:
    - name: UNLOAD_STORAGE_MODULES
      value: "true"
    - name: RESTORE_DRIVER_ON_POD_TERMINATION
      value: "true"
    - name: CREATE_IFNAMES_UDEV
      value: "true"
EOF

  2. 次のコマンドを使用して、クラスターにポリシーを作成します。 

    $ oc create -f network-sriovleg-nic-cluster-policy.yaml

    出力例

    nicclusterpolicy.mellanox.com/nic-cluster-policy created

  3. DOCA/MOFED コンテナーで次のコマンドを使用して Pod を検証します。 

    $ oc get pods -n nvidia-network-operator

    出力例

    NAME                                                          READY   STATUS    RESTARTS      AGE
mofed-rhcos4.16-696886fcb4-ds-4mb42                           2/2     Running   0             40s
mofed-rhcos4.16-696886fcb4-ds-8knwq                           2/2     Running   0             40s
nvidia-network-operator-controller-manager-68d547dbbd-qsdkf   1/1     Running   13 (4d ago)   4d21h

  4. SR-IOV レガシーモードで動作させる必要があるデバイス用の Virtual Function (VF) を生成する SriovNetworkNodePolicy CR を作成します。以下の例を参照してください。 

    $ cat <<EOF > sriov-network-node-policy.yaml
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: sriov-legacy-policy
  namespace:  openshift-sriov-network-operator
spec:
  deviceType: netdevice
  mtu: 1500
  nicSelector:
    vendor: "15b3"
    pfNames: ["ens8f0np0#0-7"]
  nodeSelector:
    feature.node.kubernetes.io/pci-15b3.present: "true"
  numVfs: 8
  priority: 90
  isRdma: true
  resourceName: sriovlegacy
EOF

  5. 次のコマンドを使用して、クラスターに CR を作成します。

    注記

    SR-IOV Global Enable が有効になっていることを確認してください。詳細は、Unable to enable SR-IOV and receiving the message "not enough MMIO resources for SR-IOV" in Red Hat Enterprise Linux を参照してください。 

    $ oc create -f sriov-network-node-policy.yaml

    出力例

    sriovnetworknodepolicy.sriovnetwork.openshift.io/sriov-legacy-policy created

  6. 各ノードのスケジューリングが無効になっています。設定を適用するためにノードが再起動します。次のコマンドを使用してノードを表示できます。 

    $ oc get nodes

    出力例

    NAME                                       STATUS                        ROLES                         AGE     VERSION
edge-19.edge.lab.eng.rdu2.redhat.com       Ready                         control-plane,master,worker   5d      v1.29.8+632b078
nvd-srv-32.nvidia.eng.rdu2.dc.redhat.com   Ready                         worker                        4d22h   v1.29.8+632b078
nvd-srv-33.nvidia.eng.rdu2.dc.redhat.com   NotReady,SchedulingDisabled   worker                        4d22h   v1.29.8+632b078

  7. ノードが再起動したら、各ノードでデバッグ Pod を開いて、VF インターフェイスが存在することを確認します。以下のコマンドを実行します。 

    a$ oc debug node/nvd-srv-33.nvidia.eng.rdu2.dc.redhat.com

    出力例

    Starting pod/nvd-srv-33nvidiaengrdu2dcredhatcom-debug-cqfjz ...
To use host binaries, run `chroot /host`
Pod IP: 10.6.135.12
If you don't see a command prompt, try pressing enter.
sh-5.1# chroot /host
sh-5.1# ip link show | grep ens8
26: ens8f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
42: ens8f0v0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
43: ens8f0v1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
44: ens8f0v2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
45: ens8f0v3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
46: ens8f0v4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
47: ens8f0v5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
48: ens8f0v6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
49: ens8f0v7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

  8. 必要に応じて、2 番目のノードで前のステップを繰り返します。

  9. オプション: 次のコマンドを使用して、リソースがクラスターの oc describe node セクションに表示されることを確認します。 

    $ oc describe node -l node-role.kubernetes.io/worker=| grep -E 'Capacity:|Allocatable:' -A8

    出力例

    Capacity:
  cpu:                       128
  ephemeral-storage:         1561525616Ki
  hugepages-1Gi:             0
  hugepages-2Mi:             0
  memory:                    263596692Ki
  nvidia.com/gpu:            2
  nvidia.com/hostdev:        0
  openshift.io/sriovlegacy:  8
--
Allocatable:
  cpu:                       127500m
  ephemeral-storage:         1438028263499
  hugepages-1Gi:             0
  hugepages-2Mi:             0
  memory:                    262445716Ki
  nvidia.com/gpu:            2
  nvidia.com/hostdev:        0
  openshift.io/sriovlegacy:  8
--
Capacity:
  cpu:                       128
  ephemeral-storage:         1561525616Ki
  hugepages-1Gi:             0
  hugepages-2Mi:             0
  memory:                    263596688Ki
  nvidia.com/gpu:            2
  nvidia.com/hostdev:        0
  openshift.io/sriovlegacy:  8
--
Allocatable:
  cpu:                       127500m
  ephemeral-storage:         1438028263499
  hugepages-1Gi:             0
  hugepages-2Mi:             0
  memory:                    262445712Ki
  nvidia.com/gpu:            2
  nvidia.com/hostdev:        0
  openshift.io/sriovlegacy:  8

  10. SR-IOV レガシーモード用の VF の準備が整ったら、SriovNetwork CR ファイルを生成します。以下の例を参照してください。 

    $ cat <<EOF > sriov-network.yaml
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: sriov-network
  namespace:  openshift-sriov-network-operator
spec:
  vlan: 0
  networkNamespace: "default"
  resourceName: "sriovlegacy"
  ipam: |
    {
      "type": "whereabouts",
      "range": "192.168.3.225/28",
      "exclude": [
       "192.168.3.229/30",
       "192.168.3.236/32"
      ]
    }
EOF

  11. 次のコマンドを使用して、クラスターにカスタムリソースを作成します。 

    $ oc create -f sriov-network.yaml

    出力例

    sriovnetwork.sriovnetwork.openshift.io/sriov-network created

5.9.4. Infiniband 上での共有デバイス RDMA の作成
リンクのコピー

Infiniband インストール環境用に、共有デバイス Remote Direct Memory Access (RDMA) 用のワークロード Pod を作成します。

手順

  1. カスタム Pod リソースを生成します。 

    $ cat <<EOF > rdma-ib-32-workload.yaml
apiVersion: v1
kind: Pod
metadata:
  name: rdma-ib-32-workload
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: example-ipoibnetwork
spec:
  nodeSelector:
    kubernetes.io/hostname: nvd-srv-32.nvidia.eng.rdu2.dc.redhat.com
  containers:
  - image: quay.io/edge-infrastructure/nvidia-tools:0.1.5
    name: rdma-ib-32-workload
    resources:
      limits:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_ib: 1
      requests:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_ib: 1
EOF

$ cat <<EOF > rdma-ib-32-workload.yaml
apiVersion: v1
kind: Pod
metadata:
  name: rdma-ib-33-workload
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: example-ipoibnetwork
spec:
  nodeSelector:
    kubernetes.io/hostname: nvd-srv-33.nvidia.eng.rdu2.dc.redhat.com
  containers:
  - image: quay.io/edge-infrastructure/nvidia-tools:0.1.5
    name: rdma-ib-33-workload
    securityContext:
      capabilities:
        add: [ "IPC_LOCK" ]
    resources:
      limits:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_ib: 1
      requests:
        nvidia.com/gpu: 1
        rdma/rdma_shared_device_ib: 1
EOF

  2. 次のコマンドを使用して、クラスターに Pod を作成します。 

    $ oc create -f rdma-ib-32-workload.yaml

    出力例

    pod/rdma-ib-32-workload created
     

    $ oc create -f rdma-ib-33-workload.yaml

    出力例

    pod/rdma-ib-33-workload created

  3. 次のコマンドを使用して、Pod が実行されていることを確認します。 

    $ oc get pods

    出力例

    NAME                  READY   STATUS    RESTARTS   AGE
rdma-ib-32-workload   1/1     Running   0          10s
rdma-ib-33-workload   1/1     Running   0          3s

5.10. RDMA 接続の検証
リンクのコピー

システム間で、特にレガシー Single Root I/O Virtualization (SR-IOV) イーサネットに関して、Remote Direct Memory Access (RDMA) 接続が機能していることを確認します。

手順

  1. 次のコマンドを使用して、各 rdma-workload-client Pod に接続します。 

    $ oc rsh -n default rdma-sriov-32-workload

    出力例

    sh-5.1#

  2. 次のコマンドを使用して、最初のワークロード Pod に割り当てられた IP アドレスを確認します。この例では、最初のワークロード Pod は RDMA テストサーバーです。 

    sh-5.1# ip a

    出力例

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if3970: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 0a:58:0a:80:02:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.128.2.167/23 brd 10.128.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::858:aff:fe80:2a7/64 scope link
       valid_lft forever preferred_lft forever
3843: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 26:34:fd:53:a6:ec brd ff:ff:ff:ff:ff:ff
    altname enp55s0f0v5
    inet 192.168.4.225/28 brd 192.168.4.239 scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::2434:fdff:fe53:a6ec/64 scope link
       valid_lft forever preferred_lft forever
sh-5.1#

    この Pod に割り当てられた RDMA サーバーの IP アドレスは、net1 インターフェイスです。この例では、IP アドレスは 192.168.4.225 です。

  3. ibstatus コマンドを実行して、各 RDMA デバイス mlx5_x に関連付けられている link_layer タイプ (Ethernet または Infiniband) を取得します。出力で state フィールドを確認することで、すべての RDMA デバイスのステータスもわかります。フィールドには ACTIVE または DOWN のいずれかが表示されます。 

    sh-5.1# ibstatus

    出力例

    Infiniband device 'mlx5_0' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_1' port 1 status:
	default gid:	 fe80:0000:0000:0000:e8eb:d303:0072:1415
	base lid:	 0xc
	sm lid:		 0x1
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 InfiniBand

Infiniband device 'mlx5_2' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_3' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_4' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_5' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_6' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_7' port 1 status:
	default gid:	 fe80:0000:0000:0000:2434:fdff:fe53:a6ec
	base lid:	 0x0
	sm lid:		 0x0
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_8' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_9' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

sh-5.1#

  4. ワーカーノード上の各 RDMA mlx5 デバイスの link_layer を取得するために、ibstat コマンドを実行します。 

    sh-5.1# ibstat | egrep "Port|Base|Link"

    出力例

    Port 1:
		Physical state: LinkUp
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Physical state: LinkUp
		Base lid: 12
		Port GUID: 0xe8ebd30300721415
		Link layer: InfiniBand
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Physical state: LinkUp
		Base lid: 0
		Port GUID: 0x2434fdfffe53a6ec
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
	Port 1:
		Base lid: 0
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
sh-5.1#

  5. RDMA 共有デバイスまたはホストデバイス用のワークロード Pod では、mlx5_x という名前の RDMA デバイスがすでに認識されており、通常は mlx5_0 または mlx5_1 です。RDMA レガシー SR-IOV ワークロード Pod では、どの RDMA デバイスがどの Virtual Function (VF) サブインターフェイスに関連付けられているかを確認する必要があります。この情報は次のコマンドを使用して表示します。 

    sh-5.1# rdma link show

    出力例

    link mlx5_0/1 state ACTIVE physical_state LINK_UP
link mlx5_1/1 subnet_prefix fe80:0000:0000:0000 lid 12 sm_lid 1 lmc 0 state ACTIVE physical_state LINK_UP
link mlx5_2/1 state DOWN physical_state DISABLED
link mlx5_3/1 state DOWN physical_state DISABLED
link mlx5_4/1 state DOWN physical_state DISABLED
link mlx5_5/1 state DOWN physical_state DISABLED
link mlx5_6/1 state DOWN physical_state DISABLED
link mlx5_7/1 state ACTIVE physical_state LINK_UP netdev net1
link mlx5_8/1 state DOWN physical_state DISABLED
link mlx5_9/1 state DOWN physical_state DISABLED

    この例では、RDMA デバイス名 mlx5_7 が net1 インターフェイスに関連付けられています。この出力は、次のコマンドで RDMA 帯域幅テストを実行するために使用します。このテストでは、ワーカーノード間の RDMA 接続も検証します。

  6. 次の ib_write_bw RDMA 帯域幅テストコマンドを実行します。 

    sh-5.1# /root/perftest/ib_write_bw -R -T 41 -s 65536 -F -x 3 -m 4096 --report_gbits -q 16 -D 60  -d mlx5_7 -p 10000 --source_ip  192.168.4.225 --use_cuda=0 --use_cuda_dmabuf

    ここでは、以下のようになります。

    • mlx5_7 RDMA デバイスを -d スイッチで渡します。
    • RDMA サーバーを起動するための送信元 IP アドレスは 192.168.4.225 です。
    • --use_cuda=0、--use_cuda_dmabuf スイッチは、GPUDirect RDMA の使用を示します。

    出力例

    WARNING: BW peak won't be measured in this run.
Perftest doesn't supports CUDA tests with inline messages: inline size set to 0

************************************
* Waiting for client to connect... *
************************************

  7. 別のターミナルウィンドウを開き、RDMA テストクライアント Pod として機能する 2 番目のワークロード Pod で、oc rsh コマンドを実行します。 

    $ oc rsh -n default rdma-sriov-33-workload

    出力例

    sh-5.1#

  8. 次のコマンドを使用して、net1 インターフェイスから RDMA テストクライアント Pod の IP アドレスを取得します。 

    sh-5.1# ip a

    出力例

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if4139: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 0a:58:0a:83:01:d5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.131.1.213/23 brd 10.131.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::858:aff:fe83:1d5/64 scope link
       valid_lft forever preferred_lft forever
4076: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 56:6c:59:41:ae:4a brd ff:ff:ff:ff:ff:ff
    altname enp55s0f0v0
    inet 192.168.4.226/28 brd 192.168.4.239 scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::546c:59ff:fe41:ae4a/64 scope link
       valid_lft forever preferred_lft forever
sh-5.1#

  9. 次のコマンドを使用して、各 RDMA デバイス mlx5_x に関連付けられている link_layer タイプを取得します。 

    sh-5.1# ibstatus

    出力例

    Infiniband device 'mlx5_0' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_1' port 1 status:
	default gid:	 fe80:0000:0000:0000:e8eb:d303:0072:09f5
	base lid:	 0xd
	sm lid:		 0x1
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 InfiniBand

Infiniband device 'mlx5_2' port 1 status:
	default gid:	 fe80:0000:0000:0000:546c:59ff:fe41:ae4a
	base lid:	 0x0
	sm lid:		 0x0
	state:		 4: ACTIVE
	phys state:	 5: LinkUp
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_3' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_4' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_5' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_6' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_7' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_8' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

Infiniband device 'mlx5_9' port 1 status:
	default gid:	 0000:0000:0000:0000:0000:0000:0000:0000
	base lid:	 0x0
	sm lid:		 0x0
	state:		 1: DOWN
	phys state:	 3: Disabled
	rate:		 200 Gb/sec (4X HDR)
	link_layer:	 Ethernet

  10. オプション: ibstat コマンドを使用して、Mellanox カードのファームウェアバージョンを取得します。 

    sh-5.1# ibstat

    出力例

    CA 'mlx5_0'
	CA type: MT4123
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0xe8ebd303007209f4
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_1'
	CA type: MT4123
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0xe8ebd303007209f5
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 200
		Base lid: 13
		LMC: 0
		SM lid: 1
		Capability mask: 0xa651e848
		Port GUID: 0xe8ebd303007209f5
		Link layer: InfiniBand
CA 'mlx5_2'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0x566c59fffe41ae4a
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x546c59fffe41ae4a
		Link layer: Ethernet
CA 'mlx5_3'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0xb2ae4bfffe8f3d02
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_4'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0x2a9967fffe8bf272
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_5'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0x5aff2ffffe2e17e8
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_6'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0x121bf1fffe074419
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_7'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0xb22b16fffed03dd7
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_8'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0x523800fffe16d105
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
CA 'mlx5_9'
	CA type: MT4124
	Number of ports: 1
	Firmware version: 20.43.1014
	Hardware version: 0
	Node GUID: 0xd2b4a1fffebdc4a9
	System image GUID: 0xe8ebd303007209f4
	Port 1:
		State: Down
		Physical state: Disabled
		Rate: 200
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00010000
		Port GUID: 0x0000000000000000
		Link layer: Ethernet
sh-5.1#

  11. クライアントワークロード Pod が使用する Virtual Function サブインターフェイスに関連付けられている RDMA デバイスを特定するために、次のコマンドを実行します。この例では、net1 インターフェイスは RDMA デバイス mlx5_2 を使用しています。 

    sh-5.1# rdma link show

    出力例

    link mlx5_0/1 state ACTIVE physical_state LINK_UP
link mlx5_1/1 subnet_prefix fe80:0000:0000:0000 lid 13 sm_lid 1 lmc 0 state ACTIVE physical_state LINK_UP
link mlx5_2/1 state ACTIVE physical_state LINK_UP netdev net1
link mlx5_3/1 state DOWN physical_state DISABLED
link mlx5_4/1 state DOWN physical_state DISABLED
link mlx5_5/1 state DOWN physical_state DISABLED
link mlx5_6/1 state DOWN physical_state DISABLED
link mlx5_7/1 state DOWN physical_state DISABLED
link mlx5_8/1 state DOWN physical_state DISABLED
link mlx5_9/1 state DOWN physical_state DISABLED
sh-5.1#

  12. 次の ib_write_bw RDMA 帯域幅テストコマンドを実行します。 

    sh-5.1# /root/perftest/ib_write_bw -R -T 41 -s 65536 -F -x 3 -m 4096 --report_gbits -q 16 -D 60  -d mlx5_2 -p 10000 --source_ip  192.168.4.226 --use_cuda=0 --use_cuda_dmabuf 192.168.4.225

    ここでは、以下のようになります。

    • mlx5_2 RDMA デバイスを -d スイッチで渡します。
    • 送信元 IP アドレスは 192.168.4.226 で、RDMA サーバーの送信先 IP アドレスは 192.168.4.225 です。

    • --use_cuda=0、--use_cuda_dmabuf スイッチは、GPUDirect RDMA の使用を示します。

      出力例

      WARNING: BW peak won't be measured in this run.
Perftest doesn't supports CUDA tests with inline messages: inline size set to 0
Requested mtu is higher than active mtu
Changing to active mtu - 3
initializing CUDA
Listing all CUDA devices in system:
CUDA device 0: PCIe address is 61:00

Picking device No. 0
[pid = 8909, dev = 0] device name = [NVIDIA A40]
creating CUDA Ctx
making it the current CUDA Ctx
CUDA device integrated: 0
using DMA-BUF for GPU buffer address at 0x7f8738600000 aligned at 0x7f8738600000 with aligned size 2097152
allocated GPU buffer of a 2097152 address at 0x23a7420 for type CUDA_MEM_DEVICE
Calling ibv_reg_dmabuf_mr(offset=0, size=2097152, addr=0x7f8738600000, fd=40) for QP #0
---------------------------------------------------------------------------------------
                    RDMA_Write BW Test
 Dual-port       : OFF		Device         : mlx5_2
 Number of qps   : 16		Transport type : IB
 Connection type : RC		Using SRQ      : OFF
 PCIe relax order: ON		Lock-free      : OFF
 ibv_wr* API     : ON		Using DDP      : OFF
 TX depth        : 128
 CQ Moderation   : 1
 CQE Poll Batch  : 16
 Mtu             : 1024[B]
 Link type       : Ethernet
 GID index       : 3
 Max inline data : 0[B]
 rdma_cm QPs	 : ON
 Data ex. method : rdma_cm 	TOS    : 41
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x012d PSN 0x3cb6d7
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x012e PSN 0x90e0ac
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x012f PSN 0x153f50
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0130 PSN 0x5e0128
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0131 PSN 0xd89752
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0132 PSN 0xe5fc16
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0133 PSN 0x236787
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0134 PSN 0xd9273e
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0135 PSN 0x37cfd4
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0136 PSN 0x3bff8f
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0137 PSN 0x81f2bd
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0138 PSN 0x575c43
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x0139 PSN 0x6cf53d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x013a PSN 0xcaaf6f
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x013b PSN 0x346437
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 local address: LID 0000 QPN 0x013c PSN 0xcc5865
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x026d PSN 0x359409
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x026e PSN 0xe387bf
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x026f PSN 0x5be79d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0270 PSN 0x1b4b28
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0271 PSN 0x76a61b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0272 PSN 0x3d50e1
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0273 PSN 0x1b572c
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0274 PSN 0x4ae1b5
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0275 PSN 0x5591b5
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0276 PSN 0xfa2593
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0277 PSN 0xd9473b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0278 PSN 0x2116b2
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x0279 PSN 0x9b83b6
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x027a PSN 0xa0822b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x027b PSN 0x6d930d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x027c PSN 0xb1a4d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 65536      10329004         0.00               180.47 		     0.344228
---------------------------------------------------------------------------------------
deallocating GPU buffer 00007f8738600000
destroying current CUDA Ctx
sh-5.1#

      テストが正常な場合は、期待される BW average と Mpps 単位の MsgRate が表示されます。

      ib_write_bw コマンドが完了すると、サーバー側の出力もサーバー Pod に表示されます。以下の例を参照してください。

      出力例

      WARNING: BW peak won't be measured in this run.
Perftest doesn't supports CUDA tests with inline messages: inline size set to 0

************************************
* Waiting for client to connect... *
************************************
Requested mtu is higher than active mtu
Changing to active mtu - 3
initializing CUDA
Listing all CUDA devices in system:
CUDA device 0: PCIe address is 61:00

Picking device No. 0
[pid = 9226, dev = 0] device name = [NVIDIA A40]
creating CUDA Ctx
making it the current CUDA Ctx
CUDA device integrated: 0
using DMA-BUF for GPU buffer address at 0x7f447a600000 aligned at 0x7f447a600000 with aligned size 2097152
allocated GPU buffer of a 2097152 address at 0x2406400 for type CUDA_MEM_DEVICE
Calling ibv_reg_dmabuf_mr(offset=0, size=2097152, addr=0x7f447a600000, fd=40) for QP #0
---------------------------------------------------------------------------------------
                    RDMA_Write BW Test
 Dual-port       : OFF		Device         : mlx5_7
 Number of qps   : 16		Transport type : IB
 Connection type : RC		Using SRQ      : OFF
 PCIe relax order: ON		Lock-free      : OFF
 ibv_wr* API     : ON		Using DDP      : OFF
 CQ Moderation   : 1
 CQE Poll Batch  : 16
 Mtu             : 1024[B]
 Link type       : Ethernet
 GID index       : 3
 Max inline data : 0[B]
 rdma_cm QPs	 : ON
 Data ex. method : rdma_cm 	TOS    : 41
---------------------------------------------------------------------------------------
 Waiting for client rdma_cm QP to connect
 Please run the same command with the IB/RoCE interface IP
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x026d PSN 0x359409
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x026e PSN 0xe387bf
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x026f PSN 0x5be79d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0270 PSN 0x1b4b28
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0271 PSN 0x76a61b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0272 PSN 0x3d50e1
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0273 PSN 0x1b572c
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0274 PSN 0x4ae1b5
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0275 PSN 0x5591b5
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0276 PSN 0xfa2593
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0277 PSN 0xd9473b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0278 PSN 0x2116b2
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x0279 PSN 0x9b83b6
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x027a PSN 0xa0822b
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x027b PSN 0x6d930d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 local address: LID 0000 QPN 0x027c PSN 0xb1a4d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:225
 remote address: LID 0000 QPN 0x012d PSN 0x3cb6d7
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x012e PSN 0x90e0ac
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x012f PSN 0x153f50
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0130 PSN 0x5e0128
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0131 PSN 0xd89752
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0132 PSN 0xe5fc16
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0133 PSN 0x236787
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0134 PSN 0xd9273e
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0135 PSN 0x37cfd4
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0136 PSN 0x3bff8f
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0137 PSN 0x81f2bd
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0138 PSN 0x575c43
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x0139 PSN 0x6cf53d
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x013a PSN 0xcaaf6f
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x013b PSN 0x346437
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
 remote address: LID 0000 QPN 0x013c PSN 0xcc5865
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:192:168:04:226
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 65536      10329004         0.00               180.47 		     0.344228
---------------------------------------------------------------------------------------
deallocating GPU buffer 00007f447a600000
destroying current CUDA Ctx

Legal Notice
リンクのコピー

Copyright © Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of the OpenJS Foundation.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る