スケーラビリティーおよびパフォーマンス

手順

1. AWS コンソールを開き、マスターインスタンスを取得します。
2. 1 つのマスターインスタンスを停止します。
3. 停止したインスタンスを選択し、Actions → Instance Settings → Change instance type をクリックします。
4. インスタンスをより大きなタイプに変更し、タイプが前の選択と同じベースであることを確認して、変更を適用します。たとえば、m5.xlarge を m5.2xlarge または m5.4xlarge に変更できます。
5. インスタンスをバックアップし、次のマスターインスタンスに対して手順を繰り返します。

手順

1. 以下の NTO サンプルプロファイルを YAML ファイルにコピーします。たとえば、thp-s390-tuned.yaml のようになります。

   apiVersion: tuned.openshift.io/v1
   kind: Tuned
   metadata:
     name: thp-workers-profile
     namespace: openshift-cluster-node-tuning-operator
   spec:
     profile:
     - data: |
         [main]
         summary=Custom tuned profile for OpenShift on IBM Z to turn off THP on worker nodes
         include=openshift-node
   
         [vm]
         transparent_hugepages=never
       name: openshift-thp-never-worker
   
     recommend:
     - match:
       - label: node-role.kubernetes.io/worker
       priority: 35
       profile: openshift-thp-never-worker

2. NTO プロファイルを作成します。

   $ oc create -f thp-s390-tuned.yaml

3. アクティブなプロファイルの一覧を確認します。

   $ oc get tuned -n openshift-cluster-node-tuning-operator

4. プロファイルを削除します。

   $ oc delete -f thp-s390-tuned.yaml

手順

1. 以下の MCO サンプルプロファイルを YAML ファイルにコピーします。たとえば、enable-rfs.yaml のようになります。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 50-enable-rfs
   spec:
     config:
       ignition:
         version: 2.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20turn%20on%20Receive%20Flow%20Steering%20%28RFS%29%20for%20all%20network%20interfaces%0ASUBSYSTEM%3D%3D%22net%22%2C%20ACTION%3D%3D%22add%22%2C%20RUN%7Bprogram%7D%2B%3D%22/bin/bash%20-c%20%27for%20x%20in%20/sys/%24DEVPATH/queues/rx-%2A%3B%20do%20echo%208192%20%3E%20%24x/rps_flow_cnt%3B%20%20done%27%22%0A
           filesystem: root
           mode: 0644
           path: /etc/udev/rules.d/70-persistent-net.rules
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20define%20sock%20flow%20enbtried%20for%20%20Receive%20Flow%20Steering%20%28RFS%29%0Anet.core.rps_sock_flow_entries%3D8192%0A
           filesystem: root
           mode: 0644
           path: /etc/sysctl.d/95-enable-rps.conf

2. MCO プロファイルを作成します。

   $ oc create -f enable-rfs.yaml

3. 50-enable-rfs という名前のエントリーが表示されていることを確認します。

   $ oc get mc

4. 非アクティブにするには、次のコマンドを実行します。

   $ oc delete mc 50-enable-rfs

手順

1. 以下の MCO サンプルプロファイルをコントロールプレーンノードの YAML ファイルにコピーします。たとえば、05-master-kernelarg-hpav.yaml です。

   $ cat 05-master-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 05-master-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

2. 以下の MCO サンプルプロファイルをコンピュートノードの YAML ファイルにコピーします。たとえば、05-worker-kernelarg-hpav.yaml です。

   $ cat 05-worker-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 05-worker-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

   注記

   デバイス ID に合わせて rd.dasd 引数を変更する必要があります。

3. MCO プロファイルを作成します。

   $ oc create -f 05-master-kernelarg-hpav.yaml

   $ oc create -f 05-worker-kernelarg-hpav.yaml

4. 非アクティブにするには、次のコマンドを実行します。

   $ oc delete -f 05-master-kernelarg-hpav.yaml

   $ oc delete -f 05-worker-kernelarg-hpav.yaml

手順

1. 任意のエディターで /etc/libvirt/qemu.conf を開きます。
2. cgroup_controllers 行に移動します。
3. 行全体を複製し、コピーから先頭の番号記号 (#) を削除します。

4. cpuset エントリーを以下のように削除します。

   cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]

5. 新しい設定を有効にするには、libvirtd デーモンを再起動する必要があります。

   1. すべての仮想マシンを停止します。

   2. 以下のコマンドを実行します。

      # systemctl restart libvirtd

   3. 仮想マシンを再起動します。

手順

1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
2. Add Host → New with Dialog を選択します。
3. 新規ベアメタルホストの一意の名前を指定します。
4. Boot MAC address を設定します。
5. Baseboard Management Console (BMC) Address を設定します。
6. 必要に応じて、ホストの電源管理を有効にします。これにより、OpenShift Container Platform はホストの電源状態を制御できます。
7. ホストのベースボード管理コントローラー (BMC) のユーザー認証情報を入力します。
8. 作成後にホストの電源をオンにすることを選択し、Create を選択します。
9. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシンレプリカ数を増やします。

手順

1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
2. Add Host → New from YAML を選択します。

3. 以下の YAML をコピーして貼り付け、ホストの詳細で関連フィールドを変更します。

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     name: <bare_metal_host_name>
   spec:
     online: true
     bmc:
       address: <bmc_address>
       credentialsName: <secret_credentials_name>  1
       disableCertificateVerification: True
     bootMACAddress: <host_boot_mac_address>
     hardwareProfile: unknown

   1

   credentialsName は有効な Secret CR を参照する必要があります。baremetal-operator は、credentialsName で参照される有効な Secret なしに、ベアメタルホストを管理できません。シークレットの詳細および作成方法については、シークレットについて を参照してください。

4. Create を選択して YAML を保存し、新規ベアメタルホストを作成します。

5. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシン数を増やします。

   注記

   oc scale コマンドおよび適切なベアメタルマシンセットを使用して、ベアメタルノードの数を管理することもできます。

手順

1. metal3.io/autoscale-to-hosts アノテーションを追加して、自動スケーリング用に設定するマシンセットにアノテーションを付けます。<machineset> を、マシンセット名に置き換えます。

   $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

   新しいスケーリングされたマシンが起動するまで待ちます。

1. ラベルを使用して同じ Huge Page 設定を必要とするすべてのノードにラベルを付けます。

   $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

2. 以下の内容でファイルを作成し、これに hugepages-tuned-boottime.yaml という名前を付けます。

   apiVersion: tuned.openshift.io/v1
   kind: Tuned
   metadata:
     name: hugepages 1
     namespace: openshift-cluster-node-tuning-operator
   spec:
     profile: 2
     - data: |
         [main]
         summary=Boot time configuration for hugepages
         include=openshift-node
         [bootloader]
         cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
       name: openshift-node-hugepages
   
     recommend:
     - machineConfigLabels: 4
         machineconfiguration.openshift.io/role: "worker-hp"
       priority: 30
       profile: openshift-node-hugepages

   1

   チューニングされたリソースの name を hugepages に設定します。

   2

   Huge Page を割り当てる profile セクションを設定します。

   3

   一部のプラットフォームではさまざまなサイズの Huge Page をサポートするため、パラメーターの順序に注意してください。

   4

   マシン設定プールベースのマッチングを有効にします。

3. チューニングされた hugepages プロファイルの作成

   $ oc create -f hugepages-tuned-boottime.yaml

4. 以下の内容でファイルを作成し、これに hugepages-mcp.yaml という名前を付けます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-hp
     labels:
       worker-hp: ""
   spec:
     machineConfigSelector:
       matchExpressions:
         - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-hp: ""

5. マシン設定プールを作成します。

   $ oc create -f hugepages-mcp.yaml

手順

1. 以下のアクションを実行して、Performance Addon Operator の namespace を作成します。

   1. openshift-performance-addon-operator namespace を定義する以下の Namespace カスタムリソース (CR) を作成し、YAML を pao-namespace.yaml ファイルに保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-performance-addon-operator

   2. 以下のコマンドを実行して namespace を作成します。

      $ oc create -f pao-namespace.yaml

2. 以下のオブジェクトを作成して、直前の手順で作成した namespace に Performance Addon Operator をインストールします。

   1. 以下の OperatorGroup CR を作成し、YAML を pao-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-performance-addon-operator
        namespace: openshift-performance-addon-operator

   2. 以下のコマンドを実行して OperatorGroup CR を作成します。

      $ oc create -f pao-operatorgroup.yaml

   3. 以下のコマンドを実行して、次の手順に必要な channel の値を取得します。

      $ oc get packagemanifest performance-addon-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      出力例

      4.7

   4. 以下の Subscription CR を作成し、YAML を pao-sub.yaml ファイルに保存します。

      Subscription の例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-performance-addon-operator-subscription
        namespace: openshift-performance-addon-operator
      spec:
        channel: "<channel>" 1
        name: performance-addon-operator
        source: redhat-operators 2
        sourceNamespace: openshift-marketplace

      1

      .status.defaultChannel パラメーターの直前の手順で取得した値を指定します。

      2

      redhat-operators 値を指定する必要があります。

   5. 以下のコマンドを実行して Subscription オブジェクトを作成します。

      $ oc create -f pao-sub.yaml

   6. openshift-performance-addon-operator プロジェクトに切り替えます。

      $ oc project openshift-performance-addon-operator

手順

1. OpenShift Container Platform Web コンソールを使用して Performance Addon Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Performance Addon Operator を選択してから Install をクリックします。
   3. Install Operator ページで、All namespaces on the cluster を選択します。次に、Install をクリックします。

2. オプション: performance-addon-operator が正常にインストールされていることを確認します。

   1. Operators → Installed Operators ページに切り替えます。

   2. Performance Addon Operator が openshift-operators プロジェクトに Succeeded の Status でリストされていることを確認します。

      注記

      インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが成功し、Succeeded メッセージが表示された場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合は、さらにトラブルシューティングを行うことができます。

      • Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、openshift-operators プロジェクトで Pod のログを確認します。

手順

1. 以下のコマンドを実行します。

   $ oc get csv

2. 出力を確認し、PHASE フィールドをチェックします。以下に例を示します。

   VERSION    REPLACES                                         PHASE
   4.7.0      performance-addon-operator.v4.6.0                Installing
   4.6.0                                                       Replacing

3. get csv を再度実行して出力を確認します。

   # oc get csv

   出力例

   NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
   performance-addon-operator.v4.7.0   Performance Addon Operator   4.7.0     performance-addon-operator.v4.6.0   Succeeded

1. Performance Addon Operator をクラスターにインストールします。
2. オプション: ノードを OpenShift Container Platform クラスターに追加します。BIOS パラメーターの設定 について参照してください。
3. ocコマンドを使用して、リアルタイム機能を必要とするワーカーノードにラベルworker-rtを追加します。

4. リアルタイムノード用の新しいマシン設定プールを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-rt
     labels:
       machineconfiguration.openshift.io/role: worker-rt
   spec:
     machineConfigSelector:
       matchExpressions:
         - {
              key: machineconfiguration.openshift.io/role,
              operator: In,
              values: [worker, worker-rt],
           }
     paused: false
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-rt: ""

   マシン設定プール worker-rt は、worker-rt というラベルを持つノードのグループに対して作成されることに注意してください。

5. ノードロールラベルを使用して、ノードを適切なマシン設定プールに追加します。

   注記

   リアルタイムワークロードで設定するノードを決定する必要があります。クラスター内のすべてのノード、またはノードのサブセットを設定できます。Performance Addon Operator は、すべてのノードが専用のマシン設定プールの一部であることを想定します。すべてのノードを使用する場合は、Performance Addon Operator がワーカーノードのロールラベルを指すようにする必要があります。サブセットを使用する場合、ノードを新規のマシン設定プールにグループ化する必要があります。

6. ハウスキーピングコアの適切なセットと realTimeKernel: enabled: true を設定して PerformanceProfile を作成します。

7. PerformanceProfile で machineConfigPoolSelector を設定する必要があります:

     apiVersion: performance.openshift.io/v2
     kind: PerformanceProfile
     metadata:
      name: example-performanceprofile
     spec:
     ...
       realTimeKernel:
         enabled: true
       nodeSelector:
          node-role.kubernetes.io/worker-rt: ""
       machineConfigPoolSelector:
          machineconfiguration.openshift.io/role: worker-rt

8. 一致するマシン設定プールがラベルを持つことを確認します。

   $ oc describe mcp/worker-rt

   出力例

   Name:         worker-rt
   Namespace:
   Labels:       machineconfiguration.openshift.io/role=worker-rt

9. OpenShift Container Platform はノードの設定を開始しますが、これにより複数の再起動が伴う可能性があります。ノードが起動し、安定するのを待機します。特定のハードウェアの場合に、これには長い時間がかかる可能性がありますが、ノードごとに 20 分の時間がかかることが予想されます。
10. すべてが予想通りに機能していることを確認します。

手順

1. QoS クラスの Guaranteed を指定して Pod を作成します。
2. オプション: DPDK の CPU 負荷分散を無効にします。
3. 適切なノードセレクターを割り当てます。

1. Pod を作成します。

   $ oc  apply -f qos-pod.yaml --namespace=qos-example

2. Pod についての詳細情報を表示します。

   $ oc get pod qos-demo --namespace=qos-example --output=yaml

   出力例

   spec:
     containers:
       ...
   status:
     qosClass: Guaranteed

   注記

   コンテナーが独自のメモリー制限を指定するものの、メモリー要求を指定しない場合、OpenShift Container Platform は制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナーが独自の CPU 制限を指定するものの、CPU 要求を指定しない場合、OpenShift Container Platform は制限に一致する CPU 要求を自動的に割り当てます。

1. ミラーリングの実行。
2. テストに対してカスタムレジストリーからのイメージを使用するように指示します。

1. 関連付けられたマシン設定プールの状態は degraded (低下) になります。

   # oc get mcp

   出力例

   NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master       rendered-master-2ee57a93fa6c9181b546ca46e1571d2d       True      False      False      3              3                   3                     0                      2d21h
   worker       rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f       True      False      False      2              2                   2                     0                      2d21h
   worker-cnf   rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c   False     True       True       2              1                   1                     1                      2d20h

2. MCP の describe セクションには理由が示されます。

   # oc describe mcp worker-cnf

   出力例

     Message:               Node node-worker-cnf is reporting: "prepping update:
     machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
     found"
       Reason:                1 nodes are reporting degraded status on sync

3. degraded (低下) の状態は、degraded = true とマークされたパフォーマンスプロファイルの status フィールドにも表示されるはずです。

   # oc describe performanceprofiles performance

   出力例

   Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
   Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
   reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
   \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
      Status:  True
      Type:    Degraded

手順

1. must-gather データを保存するディレクトリーに移動します。

2. oc adm must-gather コマンドを 1 つまたは複数の --image または --image-stream 引数と共に実行します。たとえば、以下のコマンドは、デフォルトのクラスターデータと Performance Addon Operator に固有の情報の両方を収集します。

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
   
    --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.7 2

   1

   デフォルトの OpenShift Container Platform must-gather イメージ。

   2

   低レイテンシーチューニングの診断用の must-gather イメージ。

3. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/ を実際のディレクトリー名に置き換えます。

4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

手順

1. 以下のアクションを実行して、ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator の namespace を作成します。

   1. 以下の例のように sriov-namespace.yaml という名前のファイルを作成し、vran-acceleration-operators namespace を定義します。

      apiVersion: v1
      kind: Namespace
      metadata:
          name: vran-acceleration-operators
          labels:
             openshift.io/cluster-monitoring: "true"

   2. 以下のコマンドを実行して namespace を作成します。

      $ oc create -f sriov-namespace.yaml

2. 以下のオブジェクトを作成して、ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator を直前の手順で作成した namespace にインストールします。

   1. 以下の OperatorGroup カスタムリソース (CR) を作成し、YAML を sriov-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
          name: vran-operators
          namespace: vran-acceleration-operators
      spec:
          targetNamespaces:
            - vran-acceleration-operators

   2. 以下のコマンドを実行して OperatorGroup CR を作成します。

      $ oc create -f sriov-operatorgroup.yaml

   3. 以下のコマンドを実行して、次の手順に必要な channel の値を取得します。

      $ oc get packagemanifest sriov-fec -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      出力例

      stable

   4. 以下の Subscription CR を作成し、YAML を sriov-sub.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: sriov-fec-subscription
          namespace: vran-acceleration-operators
      spec:
          channel: "<channel>" 1
          name: sriov-fec
          source: certified-operators 2
          sourceNamespace: openshift-marketplace

      1

      .status.defaultChannel パラメーターの直前の手順で取得した値からチャネルの値を指定します。

      2

      certified-operators 値を指定する必要があります。

   5. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f sriov-sub.yaml

手順

1. OpenShift Container Platform Web コンソールを使用して、ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から ワイヤレス FEC Accelerator 向け OpenNESS SR-IOV Operator を選択し、Install をクリックします。
   3. Install Operator ページで、All namespaces on the cluster を選択します。次に、Install をクリックします。

2. オプション: SRIOV-FEC Operator が正常にインストールされていることを確認します。

   1. Operators → Installed Operators ページに切り替えます。

   2. ワイヤレス FEC Accelerator 向け OpenNESS SR-IOV Operator が Status が InstallSucceeded の vran-acceleration-operators プロジェクトに一覧表示されていることを確認します。

      注記

      インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      コンソールが Operator がインストールされていることを示していない場合は、以下のトラブルシューティング手順を実行します。

      • Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、vran-acceleration-operators プロジェクトで Pod のログを確認します。

手順

1. vran-acceleration-operators プロジェクトに切り替えます。

   $ oc project vran-acceleration-operators

2. SR-IOV-FEC Operator がインストールされていることを確認します。

   $ oc get csv -o custom-columns=Name:.metadata.name,Phase:.status.phase

   出力例

   Name                                        Phase
   sriov-fec.v1.1.0                            Succeeded

3. sriov-fec Pod が実行していることを確認します。

   $  oc get pods

   出力例

   NAME                                            READY       STATUS      RESTARTS    AGE
   sriov-device-plugin-j5jlv                       1/1         Running     1           15d
   sriov-fec-controller-manager-85b6b8f4d4-gd2qg   1/1         Running     1           15d
   sriov-fec-daemonset-kqqs6                       1/1         Running     1           15d

   • sriov-device-plugin は、FEC 仮想機能をノードの下にあるリソースとして公開します。
   • sriov-fec-controller-manager は CR をノードに適用し、オペランドコンテナーを維持します。

   • sriov-fec-daemonset は、次のことを行います。

     • 各ノードで SRIOV NIC の検出
     • ステップ 6 で定義されたカスタムリソース (CR) のステータスの同期
     • CR の spec を入力として実行し、検出された NIC の設定

4. サポート対象の vRAN FEC アクセラレーターデバイスのいずれかを含むすべてのノードを取得します。

   $ oc get sriovfecnodeconfig

   出力例

   NAME             CONFIGURED
   node1            Succeeded

5. 設定する SR-IOV FEC アクセラレーターデバイスの Physical Function (PF) を検索します。

   $ oc get sriovfecnodeconfig node1 -o yaml

   出力例

   status:
       conditions:
       - lastTransitionTime: "2021-03-19T17:19:37Z"
         message: Configured successfully
         observedGeneration: 1
         reason: ConfigurationSucceeded
         status: "True"
         type: Configured
       inventory:
          sriovAccelerators:
          - deviceID: 0d5c
            driver: ""
            maxVirtualFunctions: 16
            pciAddress: 0000:af:00.0 1
            vendorID: "8086"
            virtualFunctions: [] 2

   1

   このフィールドは、カードの PCI アドレスを表示します。

   2

   このフィールドは、仮想関数が空であることを示します。

6. FEC デバイスの仮想機能とキューグループの数を設定します。

   1. 以下のカスタムリソース (CR) を作成し、YAML を sriovfec_acc100cr.yaml ファイルに保存します。

      注記

      この例では、5G の ACC100 8/8 キューグループ、Uplink 向け 4 キューグループ、および Downlink の別の 4 つのキューグループを設定します。

      apiVersion: sriovfec.intel.com/v1
      kind: SriovFecClusterConfig
      metadata:
        name: config 1
      spec:
        nodes:
         - nodeName: node1 2
           physicalFunctions:
             - pciAddress: 0000:af:00.0 3
               pfDriver: "pci-pf-stub"
               vfDriver: "vfio-pci"
               vfAmount: 16 4
               bbDevConfig:
                 acc100:
                   # Programming mode: 0 = VF Programming, 1 = PF Programming
                   pfMode: false
                   numVfBundles: 16
                   maxQueueSize: 1024
                   uplink4G:
                     numQueueGroups: 0
                     numAqsPerGroups: 16
                     aqDepthLog2: 4
                   downlink4G:
                    numQueueGroups: 0
                    numAqsPerGroups: 16
                    aqDepthLog2: 4
                   uplink5G:
                    numQueueGroups: 4
                    numAqsPerGroups: 16
                    aqDepthLog2: 4
                   downlink5G:
                    numQueueGroups: 4
                    numAqsPerGroups: 16
                    aqDepthLog2: 4

      1

      CR オブジェクトの名前を指定します。指定できる唯一の名前は config です。

      2

      ノード名を指定します。

      3

      SR-IOV-FEC Operator がインストールされているカードの PCI アドレスを指定します。

      4

      作成する仮想関数の数を指定します。Intel vRAN Dedicated Accelerator ACC100 の場合は、16 個の VF をすべて作成します。

      注記

      カードは、グループごとに最大 16 個のキューを持つ最大 8 個のキューを提供するように設定されます。キューグループは、5G と 4G と Uplink と Downlink に割り当てられたグループ間で分割できます。Intel vRAN Dedicated Accelerator ACC100 を設定することができます。

      • 4G または 5G のみ
      • 4G と 5G を同時に

      設定した各 VF は、すべてのキューにアクセスできます。各キューグループの優先度は、それぞれ個別の優先レベルを持ちます。特定のキューグループの要求はアプリケーションレベル (FEC デバイスを利用する vRAN アプリケーション) から行われます。

   2. CR を適用します。

      $ oc apply -f sriovfec_acc100cr.yaml

      CR の適用後、SR-IOV FEC デーモンは FEC デバイスの設定を開始します。

検証

1. ステータスを確認します。

   $ oc get sriovfecclusterconfig config -o yaml

   出力例

   status:
       conditions:
       - lastTransitionTime: "2021-03-19T11:46:22Z"
         message: Configured successfully
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Configured
       inventory:
         sriovAccelerators:
         - deviceID: 0d5c
           driver: pci-pf-stub
           maxVirtualFunctions: 16
           pciAddress: 0000:af:00.0
           vendorID: "8086"
           virtualFunctions:
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.0
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.1
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.2
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.3
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.4

2. ログを確認します。

   1. SR-IOV デーモンの Pod 名を判別します。

      $ oc get po -o wide | grep sriov-fec-daemonset | grep node1

      出力例

      sriov-fec-daemonset-kqqs6                      1/1     Running   0          19h

   2. ログを表示します。

      $ oc logs sriov-fec-daemonset-kqqs6

      出力例

      {"level":"Level(-2)","ts":1616794345.4786215,"logger":"daemon.drainhelper.cordonAndDrain()","msg":"node drained"}
      {"level":"Level(-4)","ts":1616794345.4786265,"logger":"daemon.drainhelper.Run()","msg":"worker function - start"}
      {"level":"Level(-4)","ts":1616794345.5762916,"logger":"daemon.NodeConfigurator.applyConfig","msg":"current node status","inventory":{"sriovAccelerat
      ors":[{"vendorID":"8086","deviceID":"0b32","pciAddress":"0000:20:00.0","driver":"","maxVirtualFunctions":1,"virtualFunctions":[]},{"vendorID":"8086"
      ,"deviceID":"0d5c","pciAddress":"0000:af:00.0","driver":"","maxVirtualFunctions":16,"virtualFunctions":[]}]}}
      {"level":"Level(-4)","ts":1616794345.5763638,"logger":"daemon.NodeConfigurator.applyConfig","msg":"configuring PF","requestedConfig":{"pciAddress":"
      0000:af:00.0","pfDriver":"pci-pf-stub","vfDriver":"vfio-pci","vfAmount":2,"bbDevConfig":{"acc100":{"pfMode":false,"numVfBundles":16,"maxQueueSize":1
      024,"uplink4G":{"numQueueGroups":4,"numAqsPerGroups":16,"aqDepthLog2":4},"downlink4G":{"numQueueGroups":4,"numAqsPerGroups":16,"aqDepthLog2":4},"uplink5G":{"numQueueGroups":0,"numAqsPerGroups":16,"aqDepthLog2":4},"downlink5G":{"numQueueGroups":0,"numAqsPerGroups":16,"aqDepthLog2":4}}}}}
      {"level":"Level(-4)","ts":1616794345.5774765,"logger":"daemon.NodeConfigurator.loadModule","msg":"executing command","cmd":"/usr/sbin/chroot /host/ modprobe pci-pf-stub"}
      {"level":"Level(-4)","ts":1616794345.5842702,"logger":"daemon.NodeConfigurator.loadModule","msg":"commands output","output":""}
      {"level":"Level(-4)","ts":1616794345.5843055,"logger":"daemon.NodeConfigurator.loadModule","msg":"executing command","cmd":"/usr/sbin/chroot /host/ modprobe vfio-pci"}
      {"level":"Level(-4)","ts":1616794345.6090655,"logger":"daemon.NodeConfigurator.loadModule","msg":"commands output","output":""}
      {"level":"Level(-2)","ts":1616794345.6091156,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:af:00.0/driver_override"}
      {"level":"Level(-2)","ts":1616794345.6091807,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/pci-pf-stub/bind"}
      {"level":"Level(-2)","ts":1616794345.7488534,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:b0:00.0/driver_override"}
      {"level":"Level(-2)","ts":1616794345.748938,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/vfio-pci/bind"}
      {"level":"Level(-2)","ts":1616794345.7492096,"logger":"daemon.NodeConfigurator","msg":"device's driver_override path","path":"/sys/bus/pci/devices/0000:b0:00.1/driver_override"}
      {"level":"Level(-2)","ts":1616794345.7492566,"logger":"daemon.NodeConfigurator","msg":"driver bind path","path":"/sys/bus/pci/drivers/vfio-pci/bind"}
      {"level":"Level(-4)","ts":1616794345.74968,"logger":"daemon.NodeConfigurator.applyConfig","msg":"executing command","cmd":"/sriov_workdir/pf_bb_config ACC100 -c /sriov_artifacts/0000:af:00.0.ini -p 0000:af:00.0"}
      {"level":"Level(-4)","ts":1616794346.5203931,"logger":"daemon.NodeConfigurator.applyConfig","msg":"commands output","output":"Queue Groups: 0 5GUL, 0 5GDL, 4 4GUL, 4 4GDL\nNumber of 5GUL engines 8\nConfiguration in VF mode\nPF ACC100 configuration complete\nACC100 PF [0000:af:00.0] configuration complete!\n\n"}
      {"level":"Level(-4)","ts":1616794346.520459,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"executing command","cmd":"/usr/sbin/chroot /host/ setpci -v -s 0000:af:00.0 COMMAND"}
      {"level":"Level(-4)","ts":1616794346.5458736,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"commands output","output":"0000:af:00.0 @04 = 0142\n"}
      {"level":"Level(-4)","ts":1616794346.5459251,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"executing command","cmd":"/usr/sbin/chroot /host/ setpci -v -s 0000:af:00.0 COMMAND=0146"}
      {"level":"Level(-4)","ts":1616794346.5795262,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"commands output","output":"0000:af:00.0 @04 0146\n"}
      {"level":"Level(-2)","ts":1616794346.5795407,"logger":"daemon.NodeConfigurator.enableMasterBus","msg":"MasterBus set","pci":"0000:af:00.0","output":"0000:af:00.0 @04 0146\n"}
      {"level":"Level(-4)","ts":1616794346.6867144,"logger":"daemon.drainhelper.Run()","msg":"worker function - end","performUncordon":true}
      {"level":"Level(-4)","ts":1616794346.6867719,"logger":"daemon.drainhelper.Run()","msg":"uncordoning node"}
      {"level":"Level(-4)","ts":1616794346.6896322,"logger":"daemon.drainhelper.uncordon()","msg":"starting uncordon attempts"}
      {"level":"Level(-2)","ts":1616794346.69735,"logger":"daemon.drainhelper.uncordon()","msg":"node uncordoned"}
      {"level":"Level(-4)","ts":1616794346.6973662,"logger":"daemon.drainhelper.Run()","msg":"cancelling the context to finish the leadership"}
      {"level":"Level(-4)","ts":1616794346.7029872,"logger":"daemon.drainhelper.Run()","msg":"stopped leading"}
      {"level":"Level(-4)","ts":1616794346.7030034,"logger":"daemon.drainhelper","msg":"releasing the lock (bug mitigation)"}
      {"level":"Level(-4)","ts":1616794346.8040674,"logger":"daemon.updateInventory","msg":"obtained inventory","inv":{"sriovAccelerators":[{"vendorID":"8086","deviceID":"0b32","pciAddress":"0000:20:00.0","driver":"","maxVirtualFunctions":1,"virtualFunctions":[]},{"vendorID":"8086","deviceID":"0d5c","pciAddress":"0000:af:00.0","driver":"pci-pf-stub","maxVirtualFunctions":16,"virtualFunctions":[{"pciAddress":"0000:b0:00.0","driver":"vfio-pci","deviceID":"0d5d"},{"pciAddress":"0000:b0:00.1","driver":"vfio-pci","deviceID":"0d5d"}]}]}}
      {"level":"Level(-4)","ts":1616794346.9058325,"logger":"daemon","msg":"Update ignored, generation unchanged"}
      {"level":"Level(-2)","ts":1616794346.9065044,"logger":"daemon.Reconcile","msg":"Reconciled","namespace":"vran-acceleration-operators","name":"pg-itengdvs02r.altera.com"}

3. カードの FEC 設定を確認します。

   $ oc get sriovfecnodeconfig node1 -o yaml

   出力例

   status:
       conditions:
       - lastTransitionTime: "2021-03-19T11:46:22Z"
         message: Configured successfully
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Configured
       inventory:
         sriovAccelerators:
         - deviceID: 0d5c 1
           driver: pci-pf-stub
           maxVirtualFunctions: 16
           pciAddress: 0000:af:00.0
           vendorID: "8086"
           virtualFunctions:
           - deviceID: 0d5d 2
             driver: vfio-pci
             pciAddress: 0000:b0:00.0
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.1
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.2
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.3
           - deviceID: 0d5d
             driver: vfio-pci
             pciAddress: 0000:b0:00.4

   1

   0d5c の値は、FEC デバイスの deviceID の物理機能です。

   2

   0d5d の値は、FEC デバイスの deviceID 仮想機能です。

手順

1. 以下のアクションを実行して、テスト用の namespace を作成します。

   1. 以下の例のように test-bbdev-namespace.yaml という名前のファイルを作成し、test-bbdev namespace を定義します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: test-bbdev
        labels:
          openshift.io/run-level: "1"

   2. 以下のコマンドを実行して namespace を作成します。

      $ oc create -f test-bbdev-namespace.yaml

2. 以下の Pod 仕様を作成してから、YAML を pod-test.yaml ファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-bbdev-sample-app
     namespace: test-bbdev 1
   spec:
     containers:
     - securityContext:
         privileged: false
         capabilities:
           add:
           - IPC_LOCK
           - SYS_NICE
       name: bbdev-sample-app
       image: bbdev-sample-app:1.0  2
       command: [ "sudo", "/bin/bash", "-c", "--" ]
       runAsUser: 0 3
       resources:
         requests:
           hugepages-1Gi: 4Gi 4
           memory: 1Gi
           cpu: "4" 5
           intel.com/intel_fec_acc100: '1' 6
         limits:
           memory: 4Gi
           cpu: "4"
           hugepages-1Gi: 4Gi
           intel.com/intel_fec_acc100: '1'

   1

   手順 1 で作成した namespace を指定します。

   2

   コンパイルされた DPDK を含むテストイメージを定義します。

   3

   コンテナーが root ユーザーとして内部で実行するようにします。

   4

   hugepage サイズ hugepages-1Gi および Pod に割り当てられる hugepage の量を指定します。hugepages および分離された CPU は、Performance Addon Operator を使用して設定する必要があります。

   5

   CPU の数を指定します。

   6

   ACC100 5G FEC 設定のテストは、intel.com/intel_fec_acc100 でサポートされています。

3. Pod を作成します。

   $ oc apply -f pod-test.yaml

4. Pod が作成されていることを確認します。

   $ oc get pods -n test-bbdev

   出力例

   NAME                                            READY           STATUS          RESTARTS        AGE
   pod-bbdev-sample-app                            1/1             Running         0               80s

5. リモートシェルを使用して pod-bbdev-sample-app にログインします。

   $ oc rsh pod-bbdev-sample-app

   出力例

   sh-4.4#

6. Pod に割り当てられる VF を出力します。

   sh-4.4# printenv | grep INTEL_FEC

   出力例

   PCIDEVICE_INTEL_COM_INTEL_FEC_ACC100=0.0.0.0:1d.00.0 1

   1

   これは、仮想関数の PCI アドレスです。

7. test-bbdev ディレクトリーに移動します。

   sh-4.4# cd test/test-bbdev/

8. Pod に割り当てられている CPU を確認します。

   sh-4.4# export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
   sh-4.4# echo ${CPU}

   これにより、fec.pod に割り当てられた CPU が出力されます。

   出力例

   24,25,64,65

9. test-bbdev アプリケーションを実行してデバイスをテストします。

   sh-4.4# ./test-bbdev.py -e="-l ${CPU} -a ${PCIDEVICE_INTEL_COM_INTEL_FEC_ACC100}" -c validation \ -n 64 -b 32 -l 1 -v ./test_vectors/*"

   出力例

   Executing: ../../build/app/dpdk-test-bbdev -l 24-25,64-65 0000:1d.00.0 -- -n 64 -l 1 -c validation -v ./test_vectors/bbdev_null.data -b 32
   EAL: Detected 80 lcore(s)
   EAL: Detected 2 NUMA nodes
   Option -w, --pci-whitelist is deprecated, use -a, --allow option instead
   EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
   EAL: Selected IOVA mode 'VA'
   EAL: Probing VFIO support...
   EAL: VFIO support initialized
   EAL:   using IOMMU type 1 (Type 1)
   EAL: Probe PCI driver: intel_fpga_5ngr_fec_vf (8086:d90) device: 0000:1d.00.0 (socket 1)
   EAL: No legacy callbacks, legacy socket not created
   
   
   
   ===========================================================
   Starting Test Suite : BBdev Validation Tests
   Test vector file = ldpc_dec_v7813.data
   Device 0 queue 16 setup failed
   Allocated all queues (id=16) at prio0 on dev0
   Device 0 queue 32 setup failed
   Allocated all queues (id=32) at prio1 on dev0
   Device 0 queue 48 setup failed
   Allocated all queues (id=48) at prio2 on dev0
   Device 0 queue 64 setup failed
   Allocated all queues (id=64) at prio3 on dev0
   Device 0 queue 64 setup failed
   All queues on dev 0 allocated: 64
   + ------------------------------------------------------- +
   == test: validation
   dev:0000:b0:00.0, burst size: 1, num ops: 1, op type: RTE_BBDEV_OP_LDPC_DEC
   Operation latency:
           avg: 23092 cycles, 10.0838 us
           min: 23092 cycles, 10.0838 us
           max: 23092 cycles, 10.0838 us
   TestCase [ 0] : validation_tc passed
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +
    + Test Suite Summary : BBdev Validation Tests
    + Tests Total :        1
    + Tests Skipped :      0
    + Tests Passed :       1 1
    + Tests Failed :       0
    + Tests Lasted :       177.67 ms
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

   1

   一部のテストはスキップできますが、ベクターテストに合格していることを確認してください。