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

OpenShift Container Platform 4.6

実稼働環境における OpenShift Container Platform クラスターのスケーリングおよびパフォーマンスチューニング

概要

本書では、クラスターをスケーリングし、OpenShift Container Platform 環境のパフォーマンスを最適化する方法について説明します。

第4章 Node Tuning Operator の使用

Node Tuning Operator について説明し、この Operator を使用し、Tuned デーモンのオーケストレーションを実行してノードレベルのチューニングを管理する方法について説明します。

4.1. Node Tuning Operator について

Node Tuning Operator は、Tuned デーモンのオーケストレーションによるノードレベルのチューニングの管理に役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェースをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。

Operator は、コンテナー化された OpenShift Container Platform の Tuned デーモンを Kubernetes デーモンセットとして管理します。これにより、カスタムチューニング仕様が、デーモンが認識する形式でクラスターで実行されるすべてのコンテナー化された Tuned デーモンに渡されます。デーモンは、ノードごとに 1 つずつ、クラスターのすべてのノードで実行されます。

コンテナー化された Tuned デーモンによって適用されるノードレベルの設定は、プロファイルの変更をトリガーするイベントで、または終了シグナルの受信および処理によってコンテナー化された Tuned デーモンが正常に終了する際にロールバックされます。

Node Tuning Operator は、バージョン 4.1 以降における標準的な OpenShift Container Platform インストールの一部となっています。

4.2. Node Tuning Operator 仕様サンプルへのアクセス

このプロセスを使用して Node Tuning Operator 仕様サンプルにアクセスします。

手順

  1. 以下を実行します。

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

デフォルトの CR は、OpenShift Container Platform プラットフォームの標準的なノードレベルのチューニングを提供することを目的としており、Operator 管理の状態を設定するためにのみ変更できます。デフォルト CR へのその他のカスタム変更は、Operator によって上書きされます。カスタムチューニングの場合は、独自のチューニングされた CR を作成します。新規に作成された CR は、ノード/Pod ラベルおよびプロファイルの優先順位に基づいて OpenShift Container Platform ノードに適用されるデフォルトの CR およびカスタムチューニングと組み合わされます。

警告

特定の状況で Pod ラベルのサポートは必要なチューニングを自動的に配信する便利な方法ですが、この方法は推奨されず、とくに大規模なクラスターにおいて注意が必要です。デフォルトの調整された CR は Pod ラベル一致のない状態で提供されます。カスタムプロファイルが Pod ラベル一致のある状態で作成される場合、この機能はその時点で有効になります。Pod ラベル機能は、Node Tuning Operator の今後のバージョンで非推奨になる場合があります。

4.3. クラスターに設定されるデフォルトのプロファイル

以下は、クラスターに設定されるデフォルトのプロファイルです。

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - name: "openshift"
    data: |
      [main]
      summary=Optimize systems running OpenShift (parent profile)
      include=${f:virt_check:virtual-guest:throughput-performance}

      [selinux]
      avc_cache_threshold=8192

      [net]
      nf_conntrack_hashsize=131072

      [sysctl]
      net.ipv4.ip_forward=1
      kernel.pid_max=>4194304
      net.netfilter.nf_conntrack_max=1048576
      net.ipv4.conf.all.arp_announce=2
      net.ipv4.neigh.default.gc_thresh1=8192
      net.ipv4.neigh.default.gc_thresh2=32768
      net.ipv4.neigh.default.gc_thresh3=65536
      net.ipv6.neigh.default.gc_thresh1=8192
      net.ipv6.neigh.default.gc_thresh2=32768
      net.ipv6.neigh.default.gc_thresh3=65536
      vm.max_map_count=262144

      [sysfs]
      /sys/module/nvme_core/parameters/io_timeout=4294967295
      /sys/module/nvme_core/parameters/max_retries=10

  - name: "openshift-control-plane"
    data: |
      [main]
      summary=Optimize systems running OpenShift control plane
      include=openshift

      [sysctl]
      # ktune sysctl settings, maximizing i/o throughput
      #
      # Minimal preemption granularity for CPU-bound tasks:
      # (default: 1 msec#  (1 + ilog(ncpus)), units: nanoseconds)
      kernel.sched_min_granularity_ns=10000000
      # The total time the scheduler will consider a migrated process
      # "cache hot" and thus less likely to be re-migrated
      # (system default is 500000, i.e. 0.5 ms)
      kernel.sched_migration_cost_ns=5000000
      # SCHED_OTHER wake-up granularity.
      #
      # Preemption granularity when tasks wake up.  Lower the value to
      # improve wake-up latency and throughput for latency critical tasks.
      kernel.sched_wakeup_granularity_ns=4000000

  - name: "openshift-node"
    data: |
      [main]
      summary=Optimize systems running OpenShift nodes
      include=openshift

      [sysctl]
      net.ipv4.tcp_fastopen=3
      fs.inotify.max_user_watches=65536
      fs.inotify.max_user_instances=8192

  recommend:
  - profile: "openshift-control-plane"
    priority: 30
    match:
    - label: "node-role.kubernetes.io/master"
    - label: "node-role.kubernetes.io/infra"

  - profile: "openshift-node"
    priority: 40

4.4. Tuned プロファイルが適用されていることの確認

この手順を使用して、すべてのノードに適用される Tuned プロファイルを確認します。

手順

  1. 各ノードで実行されている Tuned Pod を確認します。

    $ oc get pods -n openshift-cluster-node-tuning-operator -o wide

    出力例

    NAME                                            READY   STATUS    RESTARTS   AGE    IP             NODE                                         NOMINATED NODE   READINESS GATES
    cluster-node-tuning-operator-599489d4f7-k4hw4   1/1     Running   0          6d2h   10.129.0.76    ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
    tuned-2jkzp                                     1/1     Running   1          6d3h   10.0.145.113   ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
    tuned-g9mkx                                     1/1     Running   1          6d3h   10.0.147.108   ip-10-0-147-108.eu-west-3.compute.internal   <none>           <none>
    tuned-kbxsh                                     1/1     Running   1          6d3h   10.0.132.143   ip-10-0-132-143.eu-west-3.compute.internal   <none>           <none>
    tuned-kn9x6                                     1/1     Running   1          6d3h   10.0.163.177   ip-10-0-163-177.eu-west-3.compute.internal   <none>           <none>
    tuned-vvxwx                                     1/1     Running   1          6d3h   10.0.131.87    ip-10-0-131-87.eu-west-3.compute.internal    <none>           <none>
    tuned-zqrwq                                     1/1     Running   1          6d3h   10.0.161.51    ip-10-0-161-51.eu-west-3.compute.internal    <none>           <none>

  2. 各 Pod から適用されるプロファイルを抽出し、それらを直前の一覧に対して一致させます。

    $ for p in `oc get pods -n openshift-cluster-node-tuning-operator -l openshift-app=tuned -o=jsonpath='{range .items[*]}{.metadata.name} {end}'`; do printf "\n*** $p ***\n" ; oc logs pod/$p -n openshift-cluster-node-tuning-operator | grep applied; done

    出力例

    *** tuned-2jkzp ***
    2020-07-10 13:53:35,368 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied
    
    *** tuned-g9mkx ***
    2020-07-10 14:07:17,089 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
    2020-07-10 15:56:29,005 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
    2020-07-10 16:00:19,006 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
    2020-07-10 16:00:48,989 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
    
    *** tuned-kbxsh ***
    2020-07-10 13:53:30,565 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
    2020-07-10 15:56:30,199 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
    
    *** tuned-kn9x6 ***
    2020-07-10 14:10:57,123 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
    2020-07-10 15:56:28,757 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
    
    *** tuned-vvxwx ***
    2020-07-10 14:11:44,932 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied
    
    *** tuned-zqrwq ***
    2020-07-10 14:07:40,246 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied

4.5. カスタムチューニング仕様

Operator のカスタムリソース (CR) には 2 つの重要なセクションがあります。1 つ目のセクションの profile: は Tuned プロファイルおよびそれらの名前の一覧です。2 つ目の recommend: は、プロファイル選択ロジックを定義します。

複数のカスタムチューニング仕様は、Operator の namespace に複数の CR として共存できます。新規 CR の存在または古い CR の削除は Operator によって検出されます。既存のカスタムチューニング仕様はすべてマージされ、コンテナー化された Tuned デーモンの適切なオブジェクトは更新されます。

管理状態

Operator 管理の状態は、デフォルトの Tuned CR を調整して設定されます。デフォルトで、Operator は Managed 状態であり、spec.managementState フィールドはデフォルトの Tuned CR に表示されません。Operator Management 状態の有効な値は以下のとおりです。

  • Managed: Operator は設定リソースが更新されるとそのオペランドを更新します。
  • Unmanaged: Operator は設定リソースへの変更を無視します。
  • Removed: Operator は Operator がプロビジョニングしたオペランドおよびリソースを削除します。

プロファイルデータ

profile: セクションは、Tuned プロファイルおよびそれらの名前を一覧表示します。

profile:
- name: tuned_profile_1
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other Tuned daemon plugins supported by the containerized Tuned

# ...

- name: tuned_profile_n
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

推奨プロファイル

profile: 選択ロジックは、CR の recommend: セクションによって定義されます。recommend: セクションは、選択基準に基づくプロファイルの推奨項目の一覧です。

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

一覧の個別項目:

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
1
オプション。
2
キー/値の MachineConfig ラベルのディクショナリー。キーは一意である必要があります。
3
省略する場合は、優先度の高いプロファイルが最初に一致するか、または machineConfigLabels が設定されていない限り、プロファイルの一致が想定されます。
4
オプションの一覧。
5
プロファイルの順序付けの優先度。数値が小さいほど優先度が高くなります (0 が最も高い優先度になります)。
6
一致に適用する Tuned プロファイル。例: tuned_profile_1

<match> は、以下のように再帰的に定義されるオプションの一覧です。

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4
1
ノードまたは Pod のラベル名。
2
オプションのノードまたは Pod のラベルの値。省略されている場合も、<label_name> があるだけで一致条件を満たします。
3
オプションのオブジェクトタイプ(node または pod)。省略されている場合は、node が想定されます。
4
オプションの <match> 一覧。

<match> が省略されない場合、ネストされたすべての <match> セクションが true に評価される必要もあります。そうでない場合には false が想定され、それぞれの <match> セクションのあるプロファイルは適用されず、推奨されません。そのため、ネスト化 (子の <match> セクション) は論理 AND 演算子として機能します。これとは逆に、<match> 一覧のいずれかの項目が一致する場合、<match> の一覧全体が true に評価されます。そのため、一覧は論理 OR 演算子として機能します。

machineConfigLabels が定義されている場合、マシン設定プールベースのマッチングが指定の recommend: 一覧の項目に対してオンになります。<mcLabels> はマシン設定のラベルを指定します。マシン設定は、プロファイル <tuned_profile_name> についてカーネル起動パラメーターなどのホスト設定を適用するために自動的に作成されます。この場合、マシン設定セレクターが <mcLabels> に一致するすべてのマシン設定プールを検索し、プロファイル <tuned_profile_name> を確認されるマシン設定プールが割り当てられるすべてのノードに設定する必要があります。マスターロールとワーカーのロールの両方を持つノードをターゲットにするには、マスターロールを使用する必要があります。

一覧項目の match および machineConfigLabels は論理 OR 演算子によって接続されます。match 項目は、最初にショートサーキット方式で評価されます。そのため、true と評価される場合、machineConfigLabels 項目は考慮されません。

重要

マシン設定プールベースのマッチングを使用する場合、同じハードウェア設定を持つノードを同じマシン設定プールにグループ化することが推奨されます。この方法に従わない場合は、チューニングされたオペランドが同じマシン設定プールを共有する 2 つ以上のノードの競合するカーネルパラメーターを計算する可能性があります。

例: ノード/Pod ラベルベースのマッチング

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

上記のコンテナー化された Tuned デーモンの CR は、プロファイルの優先順位に基づいてその recommend.conf ファイルに変換されます。最も高い優先順位 (10) を持つプロファイルは openshift-control-plane-es であるため、これが最初に考慮されます。指定されたノードで実行されるコンテナー化された Tuned デーモンは、同じノードに tuned.openshift.io/elasticsearch ラベルが設定された Pod が実行されているかどうかを確認します。これがない場合、 <match> セクション全体が false として評価されます。このラベルを持つこのような Pod がある場合、 <match> セクションが true に評価されるようにするには、ノードラベルは node-role.kubernetes.io/master または node-role.kubernetes.io/infra である必要もあります。

優先順位が 10 のプロファイルのラベルが一致した場合、openshift-control-plane-es プロファイルが適用され、その他のプロファイルは考慮されません。ノード/Pod ラベルの組み合わせが一致しない場合、2 番目に高い優先順位プロファイル (openshift-control-plane) が考慮されます。このプロファイルは、コンテナー化されたチューニング済み Pod が node-role.kubernetes.io/master または node-role.kubernetes.io/infra ラベルを持つノードで実行される場合に適用されます。

最後に、プロファイル openshift-node には最低の優先順位である 30 が設定されます。これには <match> セクションがないため、常に一致します。これは、より高い優先順位の他のプロファイルが指定されたノードで一致しない場合に openshift-node プロファイルを設定するために、最低の優先順位のノードが適用される汎用的な (catch-all) プロファイルとして機能します。

Decision workflow

例: マシン設定プールベースのマッチング

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

ノードの再起動を最小限にするには、ターゲットノードにマシン設定プールのノードセレクターが一致するラベルを使用してラベルを付け、上記の Tuned CR を作成してから、最後にカスタムのマシン設定プール自体を作成します。

4.6. カスタムチューニングの例

以下の CR は、ラベル tuned.openshift.io/ingress-node-label を任意の値に設定した状態で OpenShift Container Platform ノードのカスタムノードレベルのチューニングを適用します。管理者として、以下のコマンドを使用してカスタムの Tune CR を作成します。

カスタムチューニングの例

$ oc create -f- <<_EOF_
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress
_EOF_

重要

カスタムプロファイル作成者は、デフォルトの Tuned CR に含まれるデフォルトの調整されたデーモンプロファイルを組み込むことが強く推奨されます。上記の例では、デフォルトの openshift-control-plane プロファイルを使用してこれを実行します。

4.7. サポートされている Tuned デーモンプラグイン

[main] セクションを除き、以下の Tuned プラグインは、Tuned CR の profile: セクションで定義されたカスタムプロファイルを使用する場合にサポートされます。

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm

これらのプラグインの一部によって提供される動的チューニング機能の中に、サポートされていない機能があります。以下の Tuned プラグインは現時点でサポートされていません。

  • bootloader
  • script
  • systemd

詳細は、「利用可能な Tuned プラグイン」および「Tuned の使用」を参照してください。

第5章 クラスターローダーの使用

クラスターローダーとは、クラスターに対してさまざまなオブジェクトを多数デプロイするツールであり、ユーザー定義のクラスターオブジェクトを作成します。クラスターローダーをビルド、設定、実行して、さまざまなクラスターの状態にある OpenShift Container Platform デプロイメントのパフォーマンスメトリクスを測定します。

5.1. クラスターローダーのインストール

手順

  1. コンテナーイメージをプルするには、以下を実行します。

    $ podman pull quay.io/openshift/origin-tests:4.6

5.2. クラスターローダーの実行

前提条件

  • リポジトリーは認証を要求するプロンプトを出します。レジストリーの認証情報を使用すると、一般的に利用できないイメージにアクセスできます。インストールからの既存の認証情報を使用します。

手順

  1. 組み込まれているテスト設定を使用してクラスターローダーを実行し、5 つのテンプレートビルドをデプロイして、デプロイメントが完了するまで待ちます。

    $ podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z -i \
    quay.io/openshift/origin-tests:4.6 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
    openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
    should populate the cluster [Slow][Serial] [Suite:openshift]"'

    または、VIPERCONFIG の環境変数を設定して、ユーザー定義の設定でクラスターローダーを実行します。

    $ podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z \
    -v ${LOCAL_CONFIG_FILE_PATH}:/root/configs/:z \
    -i quay.io/openshift/origin-tests:4.6 \
    /bin/bash -c 'KUBECONFIG=/root/.kube/config VIPERCONFIG=/root/configs/test.yaml \
    openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
    should populate the cluster [Slow][Serial] [Suite:openshift]"'

    この例では、 ${LOCAL_KUBECONFIG} はローカルファイルシステムの kubeconfig のパスを参照します。さらに、${LOCAL_CONFIG_FILE_PATH} というディレクトリーがあり、これは test.yaml という設定ファイルが含まれるコンテナーにマウントされます。また、test.yaml が外部テンプレートファイルや podspec ファイルを参照する場合、これらもコンテナーにマウントされる必要があります。

5.3. クラスターローダーの設定

このツールは、複数のテンプレートや Pod を含む namespace (プロジェクト) を複数作成します。

5.3.1. クラスターローダー設定ファイルの例

クラスターローダーの設定ファイルは基本的な YAML ファイルです。

provider: local 1
ClusterLoader:
  cleanup: true
  projects:
    - num: 1
      basename: clusterloader-cakephp-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: cakephp-mysql.json

    - num: 1
      basename: clusterloader-dancer-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: dancer-mysql.json

    - num: 1
      basename: clusterloader-django-postgresql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: django-postgresql.json

    - num: 1
      basename: clusterloader-nodejs-mongodb
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: quickstarts/nodejs-mongodb.json

    - num: 1
      basename: clusterloader-rails-postgresql
      tuning: default
      templates:
        - num: 1
          file: rails-postgresql.json

  tuningsets: 2
    - name: default
      pods:
        stepping: 3
          stepsize: 5
          pause: 0 s
        rate_limit: 4
          delay: 0 ms
1
エンドツーエンドテストのオプション設定。local に設定して、過剰に長いログメッセージを回避します。
2
このチューニングセットでは、速度制限やステップ設定、複数の Pod バッチ作成、セット間での一時停止などが可能になります。クラスターローダーは、以前のステップが完了したことをモニタリングしてから、続行します。
3
ステップ設定では、オブジェクトが N 個作成されてから、M 秒間一時停止します。
4
速度制限は、次のオブジェクトを作成するまで M ミリ秒間待機します。

この例では、外部テンプレートファイルや Pod 仕様ファイルへの参照もコンテナーにマウントされていることを前提とします。

重要

Microsoft Azure でクラスターローダーを実行している場合、AZURE_AUTH_LOCATION 変数を、インストーラーディレクトリーにある terraform.azure.auto.tfvars.json の出力が含まれるファイルに設定する必要があります。

5.3.2. 設定フィールド

表5.1 クラスターローダーの最上位のフィールド

フィールド説明

cleanup

true または false に設定します。設定ごとに 1 つの定義を設定します。true に設定すると、cleanup は、テストの最後にクラスターローダーが作成した namespace (プロジェクト) すべてを削除します。

projects

1 つまたは多数の定義が指定されたサブオブジェクト。projects の下に、作成する各 namespace が定義され、projects には必須のサブヘッダーが複数指定されます。

tuningsets

設定ごとに 1 つの定義が指定されたサブオブジェクト。tuningsets では、チューニングセットを定義して、プロジェクトやオブジェクト作成に対して設定可能なタイミングを追加することができます (Pod、テンプレートなど)。

sync

設定ごとに 1 つの定義が指定されたオプションのサブオブジェクト。オブジェクト作成時に同期できるかどうかについて追加します。

表5.2 projects の下にあるフィールド

フィールド説明

num

整数。作成するプロジェクト数の 1つの定義。

basename

文字列。プロジェクトのベース名の定義。競合が発生しないように、同一の namespace の数が Basename に追加されます。

tuning

文字列。オブジェクトに適用するチューニングセットの 1 つの定義。 これは対象の namespace にデプロイします。

ifexists

reuse または delete のいずれかが含まれる文字列。ツールが実行時に作成するプロジェクトまたは namespace の名前と同じプロジェクトまたは namespace を見つける場合のツールの機能を定義します。

configmaps

キーと値のペア一覧。キーは設定マップの名前で、値はこの設定マップの作成元のファイルへのパスです。

secrets

キーと値のペア一覧。キーはシークレットの名前で、値はこのシークレットの作成元のファイルへのパスです。

pods

デプロイする Pod の 1 つまたは多数の定義を持つサブオブジェクト

templates

デプロイするテンプレートの 1 つまたは多数の定義を持つサブオブジェクト

表5.3 pods および templates のフィールド

フィールド説明

num

整数。デプロイする Pod またはテンプレート数。

image

文字列。プルが可能なリポジトリーに対する Docker イメージの URL

basename

文字列。作成するテンプレート (または Pod) のベース名の 1 つの定義。

file

文字列。ローカルファイルへのパス。 作成する Pod 仕様またはテンプレートのいずれかです。

parameters

キーと値のペア。parameters の下で、Pod またはテンプレートでオーバーライドする値の一覧を指定できます。

表5.4 tuningsets の下にあるフィールド

フィールド説明

name

文字列。チューニングセットの名前。 プロジェクトのチューニングを定義する時に指定した名前と一致します。

pods

Pod に適用される tuningsets を特定するサブオブジェクト

templates

テンプレートに適用される tuningsets を特定するサブオブジェクト

表5.5 tuningsets pods または tuningsets templates の下にあるフィールド

フィールド説明

stepping

サブオブジェクト。ステップ作成パターンでオブジェクトを作成する場合に使用するステップ設定。

rate_limit

サブオブジェクト。オブジェクト作成速度を制限するための速度制限チューニングセットの設定。

表5.6 tuningsets pods または tuningsets templatesstepping の下にあるフィールド

フィールド説明

stepsize

整数。オブジェクト作成を一時停止するまでに作成するオブジェクト数。

pause

整数。stepsize で定義したオブジェクト数を作成後に一時停止する秒数。

timeout

整数。オブジェクト作成に成功しなかった場合に失敗するまで待機する秒数。

delay

整数。次の作成要求まで待機する時間 (ミリ秒)。

表5.7 sync の下にあるフィールド

フィールド説明

server

enabled および port フィールドを持つサブオブジェクト。ブール値 enabled を指定すると、Pod を同期するために HTTP サーバーを起動するかどうか定義します。port の整数はリッスンする HTTP サーバーポートを定義します (デフォルトでは 9090)。

running

ブール値。selectors に一致するラベルが指定された Pod が Running の状態になるまで待機します。

succeeded

ブール値。selectors に一致するラベルが指定された Pod が Completed の状態になるまで待機します。

selectors

Running または Completed の状態の Pod に一致するセレクター一覧

timeout

文字列。Running または Completed の状態の Pod を待機してから同期をタイムアウトするまでの時間。0 以外の値は、単位 [ns|us|ms|s|m|h] を使用してください。

5.4. 既知の問題

  • クラスターローダーは設定なしで呼び出される場合に失敗します。(BZ#1761925)
  • IDENTIFIER パラメーターがユーザーテンプレートで定義されていない場合には、テンプレートの作成は error: unknown parameter name "IDENTIFIER" エラーを出して失敗します。テンプレートをデプロイする場合は、このエラーが発生しないように、以下のパラメーターをテンプレートに追加してください。

    {
      "name": "IDENTIFIER",
      "description": "Number to append to the name of resources",
      "value": "1"
    }

    Pod をデプロイする場合は、このパラメーターを追加する必要はありません。

第6章 CPU マネージャーの使用

CPU マネージャーは、CPU グループを管理して、ワークロードを特定の CPU に制限します。

CPU マネージャーは、以下のような属性が含まれるワークロードに有用です。

  • できるだけ長い CPU 時間が必要な場合
  • プロセッサーのキャッシュミスの影響を受ける場合
  • レイテンシーが低いネットワークアプリケーションの場合
  • 他のプロセスと連携し、単一のプロセッサーキャッシュを共有することに利点がある場合

6.1. CPU マネージャーの設定

手順

  1. オプション: ノードにラベルを指定します。

    # oc label node perf-node.example.com cpumanager=true
  2. CPU マネージャーを有効にする必要のあるノードの MachineConfigPool を編集します。この例では、すべてのワーカーで CPU マネージャーが有効にされています。

    # oc edit machineconfigpool worker
  3. ラベルをワーカーのマシン設定プールに追加します。

    metadata:
      creationTimestamp: 2020-xx-xxx
      generation: 3
      labels:
        custom-kubelet: cpumanager-enabled
  4. KubeletConfigcpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。machineConfigPoolSelector セクションを参照してください。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s 2
    1
    ポリシーを指定します。
    • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。
    • staticこのポリシーにより、特定のリソース特性を持つ Pod の CPU アフィニティーを増やし、これらの Pod のノードにおける排他性を付与することができます。
    2
    オプション。CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。
  5. 動的な kubelet 設定を作成します。

    # oc create -f cpumanager-kubeletconfig.yaml

    これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。

  6. マージされた kubelet 設定を確認します。

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    出力例

           "ownerReferences": [
                {
                    "apiVersion": "machineconfiguration.openshift.io/v1",
                    "kind": "KubeletConfig",
                    "name": "cpumanager-enabled",
                    "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
                }
            ]

  7. ワーカーで更新された kubelet.conf を確認します。

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    出力例

    cpuManagerPolicy: static        1
    cpuManagerReconcilePeriod: 5s   2

    1 2
    これらの設定は、KubeletConfig CR を作成する際に定義されたものです。
  8. コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。

    # cat cpumanager-pod.yaml

    出力例

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: cpumanager-
    spec:
      containers:
      - name: cpumanager
        image: gcr.io/google_containers/pause-amd64:3.0
        resources:
          requests:
            cpu: 1
            memory: "1G"
          limits:
            cpu: 1
            memory: "1G"
      nodeSelector:
        cpumanager: "true"

  9. Pod を作成します。

    # oc create -f cpumanager-pod.yaml
  10. Pod がラベル指定されたノードにスケジュールされていることを確認します。

    # oc describe pod cpumanager

    出力例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

  11. cgroups が正しく設定されていることを確認します。pause プロセスのプロセス ID (PID) を取得します。

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    QoS (quality of service) 階層 Guaranteed の Pod は、kubepods.slice に配置されます。他の QoS の Pod は、kubepods の子である cgroups に配置されます。

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    出力例

    cpuset.cpus 1
    tasks 32706

  12. 対象のタスクで許可される CPU 一覧を確認します。

    # grep ^Cpus_allowed_list /proc/32706/status

    出力例

     Cpus_allowed_list:    1

  13. システム上の別の Pod (この場合は burstable QoS 階層にあるPod) が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    出力例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    この仮想マシンには、2 つの CPU コアがあります。system-reserved 設定は 500 ミリコアを予約し、Node Allocatable の量になるようにノードの全容量からコアの半分を引きます。ここで Allocatable CPU は 1500 ミリコアであることを確認できます。これは、それぞれがコアを 1 つ受け入れるので、CPU マネージャー Pod の 1 つを実行できることを意味します。1 つのコア全体は 1000 ミリコアに相当します。2 つ目の Pod をスケジュールしようとする場合、システムは Pod を受け入れますが、これがスケジュールされることはありません。

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

第7章 Topology Manager の使用

Topology Manager は、CPU マネージャー、デバイスマネージャー、およびその他の Hint Provider からヒントを収集し、同じ Non-Uniform Memory Access (NUMA) ノード上のすべての QoS (Quality of Service) クラスについて CPU、SR-IOV VF、その他デバイスリソースなどの Pod リソースを調整します。

Topology Manager は、収集したヒントのトポロジー情報を使用し、設定される Topology Manager ポリシーおよび要求される Pod リソースに基づいて、Pod がノードから許可されるか、または拒否されるかどうかを判別します。

Topology Manager は、ハードウェアアクセラレーターを使用して低遅延 (latency-critical) の実行と高スループットの並列計算をサポートするワークロードの場合に役立ちます。

注記

Topology Manager を使用するには、static ポリシーで CPU マネージャーを使用する必要があります。CPU マネージャーの詳細は、「CPU マネージャーの使用」を参照してください。

7.1. Topology Manager ポリシー

Topology Manager は、CPU マネージャーやデバイスマネージャーなどの Hint Provider からトポロジーのヒントを収集し、収集したヒントを使用して Pod リソースを調整することで、すべての QoS (Quality of Service) クラスの Pod リソースを調整します。

注記

CPU リソースを Pod 仕様の他の要求されたリソースと調整するには、CPU マネージャーを static CPU マネージャーポリシーで有効にする必要があります。

Topology Manager は、cpumanager-enabled カスタムリソース (CR) で割り当てる 4 つの割り当てポリシーをサポートします。

none ポリシー
これはデフォルトのポリシーで、トポロジーの配置は実行しません。
best-effort ポリシー
best-effort トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は 各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこれを保管し、ノードに対して Pod を許可します。
restricted ポリシー
restricted トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は 各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこの Pod をノードから拒否します。これにより、Pod が Pod の受付の失敗により Terminated 状態になります。
single-numa-node ポリシー
single-numa-node トポロジー管理ポリシーがある Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は単一の NUMA ノードのアフィニティーが可能かどうかを判別します。可能である場合、Pod はノードに許可されます。単一の NUMA ノードアフィニティーが使用できない場合には、Topology Manager は Pod をノードから拒否します。これにより、Pod は Pod の受付失敗と共に Terminated (終了) 状態になります。

7.2. Topology Manager のセットアップ

Topology Manager を使用するには、 cpumanager-enabled カスタムリソース (CR) で割り当てポリシーを設定する必要があります。CPU マネージャーをセットアップしている場合は、このファイルが存在している可能性があります。ファイルが存在しない場合は、作成できます。

前提条件

  • CPU マネージャーのポリシーを static に設定します。「スケーラビリティーおよびパフォーマンス」セクションの「 CPU マネージャーの使用」を参照してください。

手順

Topololgy Manager をアクティブにするには、以下を実行します。

  1. cpumanager-enabled カスタムリソース (CR) で Topology Manager 割り当てポリシーを設定します。

    $ oc edit KubeletConfig cpumanager-enabled
    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s
         topologyManagerPolicy: single-numa-node 2
    1
    このパラメーターは static である必要があります。
    2
    選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、defaultbest-effortrestrictedsingle-numa-node です。

関連情報

CPU マネージャーの詳細は、「CPU マネージャーの使用」を参照してください。

7.3. Pod の Topology Manager ポリシーとの対話

以下のサンプル Pod 仕様は、Pod の Topology Manger との対話について説明しています。

以下の Pod は、リソース要求や制限が指定されていないために BestEffort QoS クラスで実行されます。

spec:
  containers:
  - name: nginx
    image: nginx

以下の Pod は、要求が制限よりも小さいために Burstable QoS クラスで実行されます。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

選択したポリシーが none以外の場合は、Topology Manager はこれらの Pod 仕様のいずれかも考慮しません。

以下の最後のサンプル Pod は、要求が制限と等しいために Guaranteed QoS クラスで実行されます。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

Topology Manager はこの Pod を考慮します。Topology Manager は、利用可能な CPU のトポロジーを返す CPU マネージャーの静的ポリシーを確認します。また Topology Manager はデバイスマネージャーを確認し、example.com/device の利用可能なデバイスのトポロジーを検出します。

Topology Manager はこの情報を使用して、このコンテナーに最適なトポロジーを保管します。この Pod の場合、CPU マネージャーおよびデバイスマネージャーは、リソース割り当ての段階でこの保存された情報を使用します。

第8章 Cluster Monitoring Operator のスケーリング

OpenShift Container Platform は、Cluster Monitoring Operator が収集し、Prometheus ベースのモニタリングスタックに保存するメトリクスを公開します。管理者は、Grafana という 1 つのダッシュボードインターフェースでシステムリソース、コンテナーおよびコンポーネントのメトリクスを表示できます。

8.1. Prometheus データベースのストレージ要件

Red Hat では、異なるスケールサイズに応じて各種のテストが実行されました。

注記

以下の Prometheus ストレージ要件は規定されていません。ワークロードのアクティビティーおよびリソースの使用に応じて、クラスターで観察されるリソースの消費量が大きくなる可能性があります。

表8.1 クラスター内のノード/Pod の数に基づく Prometheus データベースのストレージ要件

ノード数Pod 数1 日あたりの Prometheus ストレージの増加量15 日ごとの Prometheus ストレージの増加量RAM 領域 (スケールサイズに基づく)ネットワーク (tsdb チャンクに基づく)

50

1800

6.3 GB

94 GB

6 GB

16 MB

100

3600

13 GB

195 GB

10 GB

26 MB

150

5400

19 GB

283 GB

12 GB

36 MB

200

7200

25 GB

375 GB

14 GB

46 MB

ストレージ要件が計算値を超過しないようにするために、オーバーヘッドとして予期されたサイズのおよそ 20% が追加されています。

上記の計算は、デフォルトの OpenShift Container Platform Cluster Monitoring Operator についての計算です。

注記

CPU の使用率による影響は大きくありません。比率については、およそ 50 ノードおよび 1800 Pod ごとに 1 コア (/40) になります。

OpenShift Container Platform についての推奨事項

  • 3 つ以上のインフラストラクチャー (infra) ノードを使用します。
  • NVMe (non-volatile memory express) ドライブを搭載した 3 つ以上の openshift-container-storage ノードを使用します。

8.2. クラスターモニタリングの設定

手順

Prometheus のストレージ容量を拡張するには、以下を実行します。

  1. YAML 設定ファイル cluster-monitoring-config.yml を作成します。以下は例になります。

    apiVersion: v1
    kind: ConfigMap
    data:
      config.yaml: |
        prometheusOperator:
          baseImage: quay.io/coreos/prometheus-operator
          prometheusConfigReloaderBaseImage: quay.io/coreos/prometheus-config-reloader
          configReloaderBaseImage: quay.io/coreos/configmap-reload
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        prometheusK8s:
          retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
          baseImage: openshift/prometheus
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          volumeClaimTemplate:
            spec:
              storageClassName: gp2
              resources:
                requests:
                  storage: {{PROMETHEUS_STORAGE_SIZE}} 2
        alertmanagerMain:
          baseImage: openshift/prometheus-alertmanager
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          volumeClaimTemplate:
            spec:
              storageClassName: gp2
              resources:
                requests:
                  storage: {{ALERTMANAGER_STORAGE_SIZE}} 3
        nodeExporter:
          baseImage: openshift/prometheus-node-exporter
        kubeRbacProxy:
          baseImage: quay.io/coreos/kube-rbac-proxy
        kubeStateMetrics:
          baseImage: quay.io/coreos/kube-state-metrics
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        grafana:
          baseImage: grafana/grafana
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        auth:
          baseImage: openshift/oauth-proxy
        k8sPrometheusAdapter:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
    metadata:
      name: cluster-monitoring-config
    namespace: openshift-monitoring
    1
    標準の値は PROMETHEUS_RETENTION_PERIOD=15d になります。時間は、サフィックス s、m、h、d のいずれかを使用する単位で測定されます。
    2
    標準の値は PROMETHEUS_STORAGE_SIZE=2000Gi です。ストレージの値には、サフィックス E、P、T、G、M、K のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。
    3
    標準の値は ALERTMANAGER_STORAGE_SIZE=20Gi です。ストレージの値には、サフィックス E、P、T、G、M、K のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。
  2. 保持期間とストレージサイズなどの値を設定します。
  3. 以下を実行して変更を適用します。

    $ oc create -f cluster-monitoring-config.yml

第9章 オブジェクトの最大値に合わせた環境計画

OpenShift Container Platform クラスターの計画時に以下のテスト済みのオブジェクトの最大値を考慮します。

これらのガイドラインは、最大規模のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。

重要

これらのガイドラインは、Open Virtual Network (OVN) ではなく、ソフトウェア定義ネットワーク (SDN) を使用する OpenShift Container Platform に該当します。

ほとんど場合、これらの制限値を超えると、パフォーマンスが全体的に低下します。ただし、これによって必ずしもクラスターに障害が発生する訳ではありません。

9.1. メジャーリリースについての OpenShift Container Platform のテスト済みクラスターの最大値

OpenShift Container Platform 3.x のテスト済みクラウドプラットフォーム: Red Hat OpenStack (RHOSP)、Amazon Web Services および Microsoft AzureOpenShift Container Platform 4.x のテスト済み Cloud Platform : Amazon Web Services、Microsoft Azure および Google Cloud Platform

最大値のタイプ3.x テスト済みの最大値4.x テスト済みの最大値

ノード数

2,000

2,000

Pod 数 [1]

150,000

150,000

ノードあたりの Pod 数

250

500 [2]

コアあたりの Pod 数

デフォルト値はありません。

デフォルト値はありません。

namespace 数 [3]

10,000

10,000

ビルド数

10,000(デフォルト Pod RAM 512 Mi)- Pipeline ストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

namespace ごとの Pod 数 [4]

25,000

25,000

サービス数 [5]

10,000

10,000

namespace ごとのサービス数

5,000

5,000

サービスごとのバックエンド数

5,000

5,000

namespace ごとのデプロイメント数 [4]

2,000

2,000

  1. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
  2. これは、ワーカーノードごとに 500 の Pod を持つ 100 ワーカーノードを含むクラスターでテストされています。デフォルトの maxPods は 250 です。500 maxPods に到達するには、クラスターはカスタム kubelet 設定を使用し、maxPods500 に設定された状態で作成される必要があります。500 ユーザー Pod が必要な場合は、ノード上に 10-15 のシステム Pod がすでに実行されているため、hostPrefix22 である必要があります。永続ボリューム要求 (PVC) が割り当てられている Pod の最大数は、PVC の割り当て元のストレージバックエンドによって異なります。このテストでは、OpenShift Container Storage v4 (OCS v4) のみが本書で説明されているノードごとの Pod 数に対応することができました。
  3. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。
  4. システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  5. 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。

9.2. OpenShift Container Platform のテスト済みのクラスターの最大値

最大値のタイプ4.1 および 4.2 テスト済みの最大値4.3 テスト済みの最大値4.4 テスト済みの最大値4.5 テスト済みの最大値4.6 テスト済みの最大値

ノード数

2,000

2,000

250

500

500

Pod 数 [1]

150,000

150,000

62,500

62,500

62,500

ノードあたりの Pod 数

250

500

500

500

500

コアあたりの Pod 数

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

namespace 数 [2]

10,000

10,000

10,000

10,000

10,000

ビルド数

10,000(デフォルト Pod RAM 512 Mi)- Pipeline ストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

namespace ごとの Pod 数 [3]

25,000

25,000

25,000

25,000

25,000

サービス数 [4]

10,000

10,000

10,000

10,000

10,000

namespace ごとのサービス数

5,000

5,000

5,000

5,000

5,000

サービスごとのバックエンド数

5,000

5,000

5,000

5,000

5,000

namespace ごとのデプロイメント数 [3]

2,000

2,000

2,000

2,000

2,000

  1. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
  2. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。
  3. システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  4. 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。

OpenShift Container Platform 4.6 では、CPU コア(500 ミリコア)の半分がシステムによって予約されます(OpenShift Container Platform 3.11 以前のバージョンと比較)。

9.3. クラスターの最大値がテスト済みの OpenShift Container Platform 環境および設定

AWS クラウドプラットフォーム:

ノードフレーバーvCPURAM(GiB)ディスクタイプディスクサイズ (GiB)/IOSカウントリージョン

マスター/etcd [1]

r5.4xlarge

16

128

io1

220 / 3000

3

us-west-2

インフラ [2]

m5.12xlarge

48

192

gp2

100

3

us-west-2

ワークロード [3]

m5.4xlarge

16

64

gp2

500 [4]

1

us-west-2

ワーカー

m5.2xlarge

8

32

gp2

100

3/25/250/500 [5]

us-west-2

  1. 3000 IOPS を持つ io1 ディスクは、etcd が I/O 集約型であり、かつレイテンシーの影響を受けやすいため、マスター/etcd ノードに使用されます。
  2. インフラストラクチャーノードは、モニタリング、Ingress およびレジストリーコンポーネントをホストするために使用され、これにより、それらが大規模に実行する場合に必要とするリソースを十分に確保することができます。
  3. ワークロードノードは、パフォーマンスとスケーラビリティーのワークロードジェネレーターを実行するための専用ノードです。
  4. パフォーマンスおよびスケーラビリティーのテストの実行中に収集される大容量のデータを保存するのに十分な領域を確保できるように、大きなディスクサイズが使用されます。
  5. クラスターは反復的にスケーリングされ、パフォーマンスおよびスケーラビリティーテストは指定されたノード数で実行されます。

9.4. テスト済みのクラスターの最大値に基づく環境計画

重要

ノード上で物理リソースを過剰にサブスクライブすると、Kubernetes スケジューラーが Pod の配置時に行うリソースの保証に影響が及びます。メモリースワップを防ぐために実行できる処置について確認してください。

一部のテスト済みの最大値については、単一の namespace/ユーザーが作成するオブジェクトでのみ変更されます。これらの制限はクラスター上で数多くのオブジェクトが実行されている場合には異なります。

本書に記載されている数は、Red Hat のテスト方法、セットアップ、設定、およびチューニングに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。

環境の計画時に、ノードに配置できる Pod 数を判別します。

required pods per cluster / pods per node = total number of nodes needed

ノードあたりの現在の Pod の最大数は 250 です。ただし、ノードに適合する Pod 数はアプリケーション自体によって異なります。「アプリケーション要件に合わせて環境計画を立てる方法」で説明されているように、アプリケーションのメモリー、CPU およびストレージの要件を検討してください。

シナリオ例

クラスターごとに 2200 の Pod のあるクラスターのスコープを設定する場合、ノードごとに最大 500 の Pod があることを前提として、最低でも 5 つのノードが必要になります。

2200 / 500 = 4.4

ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。

2200 / 20 = 110

ここで、

required pods per cluster / total number of nodes = expected pods per node

9.5. アプリケーション要件に合わせて環境計画を立てる方法

アプリケーション環境の例を考えてみましょう。

Pod タイプPod 数最大メモリーCPU コア数永続ストレージ

apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推定要件: CPU コア 550 個、メモリー 450GB およびストレージ 1.4TB

ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスごとのコストなどの要因を考慮する必要があります。

ノードのタイプ数量CPURAM (GB)

ノード (オプション 1)

100

4

16

ノード (オプション 2)

50

8

32

ノード (オプション 3)

25

16

64

アプリケーションによってはオーバーコミットの環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。

アプリケーション Pod は環境変数または DNS のいずれかを使用してサービスにアクセスできます。環境変数を使用する場合、それぞれのアクティブなサービスについて、変数が Pod がノードで実行される際に kubelet によって挿入されます。クラスター対応の DNS サーバーは、Kubernetes API で新規サービスの有無を監視し、それぞれに DNS レコードのセットを作成します。DNS がクラスター全体で有効にされている場合、すべての Pod は DNS 名でサービスを自動的に解決できるはずです。DNS を使用したサービス検出は、5000 サービスを超える使用できる場合があります。サービス検出に環境変数を使用する場合、引数の一覧は namespace で 5000 サービスを超える場合の許可される長さを超えると、Pod およびデプロイメントは失敗します。デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。

---
apiVersion: v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    portalIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

namespace で実行できるアプリケーション Pod の数は、環境変数がサービス検出に使用される場合にサービスの数およびサービス名の長さによって異なります。システムの ARG_MAX は、新規プロセスの引数の最大の長さを定義し、デフォルトで 2097152 KiB に設定されます。Kubelet は、以下を含む namespace で実行するようにスケジュールされる各 Pod に環境変数を挿入します。

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

引数の長さが許可される値を超え、サービス名の文字数がこれに影響する場合、namespace の Pod は起動に失敗し始めます。たとえば、5000 サービスを含む namespace では、サービス名の制限は 33 文字であり、これにより namespace で 5000 Pod を実行できます。

第10章 ストレージの最適化

ストレージを最適化すると、すべてのリソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。

10.1. 利用可能な永続ストレージオプション

永続ストレージオプションについて理解し、OpenShift Container Platform 環境を最適化できるようにします。

表10.1 利用可能なストレージオプション

ストレージタイプ説明

Block

  • ブロックデバイスとしてオペレーティングシステムに公開されます。
  • ストレージを完全に制御し、ファイルシステムを通過してファイルの低いレベルで操作する必要のあるアプリケーションに適しています。
  • ストレージエリアネットワーク (SAN) とも呼ばれます。
  • 共有できません。 一度に 1 つのクライアントだけがこのタイプのエンドポイントをマウントできるという意味です。

AWS EBS および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的なプロビジョニングをサポートします。

File

  • マウントされるファイルシステムのエクスポートとして、OS に公開されます。
  • ネットワークアタッチストレージ (NAS) とも呼ばれます。
  • 同時実行、レイテンシー、ファイルロックのメカニズムその他の各種機能は、プロトコルおよび実装、ベンダー、スケールによって大きく異なります。

RHEL NFS、NetApp NFS [1]、および Vendor NFS

オブジェクト

  • REST API エンドポイント経由でアクセスできます。
  • OpenShift Container Platform レジストリーで使用するために設定できます。
  • アプリケーションは、ドライバーをアプリケーションやコンテナーに組み込む必要があります。

AWS S3

  1. NetApp NFS は Trident プラグインを使用する場合に動的 PV のプロビジョニングをサポートします。
重要

現時点で、CNS は OpenShift Container Platform 4.6 ではサポートされていません。

10.3. データストレージ管理

以下の表は、OpenShift Container Platform コンポーネントがデータを書き込むメインディレクトリーの概要を示しています。

表10.3 OpenShift Container Platform データを保存するメインディレクトリー

ディレクトリー備考サイジング予想される拡張

/var/log

すべてのコンポーネントのログファイルです。

10 から 30 GB。

ログファイルはすぐに拡張する可能性があります。サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。

/var/lib/etcd

データベースを保存する際に etcd ストレージに使用されます。

20 GB 未満。

データベースは、最大 8 GB まで拡張できます。

環境と共に徐々に拡張します。メタデータのみを格納します。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

/var/lib/containers

これは CRI-O ランタイムのマウントポイントです。アクティブなコンテナーランタイム (Pod を含む) およびローカルイメージのストレージに使用されるストレージです。レジストリーストレージには使用されません。

16 GB メモリーの場合、1 ノードにつき 50 GB。このサイジングは、クラスターの最小要件の決定には使用しないでください。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

拡張は実行中のコンテナーの容量によって制限されます。

/var/lib/kubelet

Pod の一時ボリュームストレージです。これには、ランタイムにコンテナーにマウントされる外部のすべての内容が含まれます。環境変数、kube シークレット、および永続ボリュームでサポートされていないデータボリュームが含まれます。

変動あり。

ストレージを必要とする Pod が永続ボリュームを使用している場合は最小になります。一時ストレージを使用する場合はすぐに拡張する可能性があります。

第11章 ルーティングの最適化

OpenShift Container Platform HAProxy ルーターは、パフォーマンスを最適化するためにスケーリングします。

11.1. ベースライン Ingress コントローラー(ルーター)のパフォーマンス

OpenShift Container Platform Ingress コントローラーまたはルーターは、宛先が OpenShift Container Platform サービスのすべての外部トラフィックに対する Ingress ポイントです。

1 秒に処理される HTTP 要求について、単一の HAProxy ルーターを評価する場合に、パフォーマンスは多くの要因により左右されます。特に以下が含まれます。

  • HTTP keep-alive/close モード
  • ルートタイプ
  • TLS セッション再開のクライアントサポート
  • ターゲットルートごとの同時接続数
  • ターゲットルート数
  • バックエンドサーバーのページサイズ
  • 基礎となるインフラストラクチャー (ネットワーク/SDN ソリューション、CPU など)

特定の環境でのパフォーマンスは異なりますが、Red Hat ラボはサイズが 4 vCPU/16GB RAM のパブリッククラウドインスタンスでテストしています。1kB 静的ページを提供するバックエンドで終端する 100 ルートを処理する単一の HAProxy ルーターは、1 秒あたりに以下の数のトランザクションを処理できます。

HTTP keep-alive モードのシナリオの場合:

暗号化LoadBalancerServiceHostNetwork

なし

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP close (keep-alive なし) のシナリオの場合:

暗号化LoadBalancerServiceHostNetwork

なし

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

ROUTER_THREADS=4 が設定されたデフォルトの Ingress コントローラー設定が使用され、2 つの異なるエンドポイントの公開ストラテジー (LoadBalancerService/HostNetwork) がテストされています。TLS セッション再開は暗号化ルートについて使用されています。HTTP keep-alive の場合は、単一の HAProxy ルーターがページサイズが 8kB でも、1 Gbit の NIC を飽和させることができます。

最新のプロセッサーが搭載されたベアメタルで実行する場合は、上記のパブリッククラウドインスタンスのパフォーマンスの約 2 倍のパフォーマンスになることを予想できます。このオーバーヘッドは、パブリッククラウドにある仮想化層により発生し、プライベートクラウドベースの仮想化にも多くの場合、該当します。以下の表は、ルーターの背後で使用するアプリケーション数についてのガイドです。

アプリケーション数アプリケーションタイプ

5-10

静的なファイル/Web サーバーまたはキャッシュプロキシー

100-1000

動的なコンテンツを生成するアプリケーション

通常、HAProxy は、使用されるて技術に応じて 5 から 1000 のアプリケーションのルーターをサポートします。Ingress コントローラーのパフォーマンスは、言語や静的コンテンツと動的コンテンツの違いを含め、その背後にあるアプリケーションの機能およびパフォーマンスによって制限される可能性があります。

Ingress またはルーターのシャード化は、アプリケーションに対してより多くのルートを提供するために使用され、ルーティング層の水平スケーリングに役立ちます。

Ingress のシャード化についての詳細は、「ルートラベルを使用した Ingress コントローラーのシャード化の設定」および「namespace ラベルを使用した Ingress コントローラーのシャード化の設定」を参照してください。

11.2. Ingress コントローラー(ルーター)のパフォーマンスの最適化

OpenShift Container Platform では、環境変数 (ROUTER_THREADSROUTER_DEFAULT_TUNNEL_TIMEOUTROUTER_DEFAULT_CLIENT_TIMEOUTROUTER_DEFAULT_SERVER_TIMEOUT、および RELOAD_INTERVAL) を設定して Ingress コントローラーのデプロイメントを変更することをサポートしていません。

Ingress コントローラーのデプロイメントは変更できますが、Ingress Operator が有効にされている場合、設定は上書きされます。

第12章 ネットワークの最適化

OpenShift SDN は OpenvSwitch、VXLAN (Virtual extensible LAN) トンネル、OpenFlow ルール、iptables を使用します。このネットワークは、ジャンボフレーム、ネットワークインターフェースカード (NIC) のオフロード、マルチキュー、ethtool の設定を使用してチューニングが可能です。

OVN-Kubernetes は、トンネルプロトコルとして VXLAN ではなく Geneve (Generic Network Virtualization Encapsulation) を使用します。

VXLAN は、4096 から 1600 万以上にネットワーク数が増え、物理ネットワーク全体で階層 2 の接続が追加されるなど、VLAN での利点が提供されます。これにより、異なるシステム上で実行されている場合でも、サービスの背後にある Pod すべてが相互に通信できるようになります。

VXLAN は、User Datagram Protocol (UDP) パケットにトンネル化されたトラフィックをすべてカプセル化しますが、CPU 使用率が上昇してしまいます。これらの外部および内部パケットは、移動中にデータが破損しないようにするために通常のチェックサムルールの対象になります。これらの外部および内部パケットはどちらも、移動中にデータが破損しないように通常のチェックサムルールの対象になります。CPU のパフォーマンスによっては、この追加の処理オーバーヘッドによってスループットが減り、従来の非オーバーレイネットワークと比較してレイテンシーが高くなります。

クラウド、仮想マシン、ベアメタルの CPU パフォーマンスでは、1 Gbps をはるかに超えるネットワークスループットを処理できます。10 または 40 Gbps などの高い帯域幅のリンクを使用する場合には、パフォーマンスが低減する場合があります。これは、VXLAN ベースの環境では既知の問題で、コンテナーや OpenShift Container Platform 固有の問題ではありません。VXLAN トンネルに依存するネットワークも、VXLAN 実装により同様のパフォーマンスになります。

1 Gbps 以上にするには、以下を実行してください。

  • Border Gateway Protocol (BGP) など、異なるルーティング技術を実装するネットワークプラグインを評価する。
  • VXLAN オフロード対応のネットワークアダプターを使用します。VXLAN オフロードは、システムの CPU から、パケットのチェックサム計算と関連の CPU オーバーヘッドを、ネットワークアダプター上の専用のハードウェアに移動します。これにより、CPU サイクルを Pod やアプリケーションで使用できるように開放し、ネットワークインフラストラクチャーの帯域幅すべてをユーザーは活用できるようになります。

VXLAN オフロードはレイテンシーを短縮しません。ただし、CPU の使用率はレイテンシーテストでも削減されます。

12.1. ネットワークでの MTU の最適化

重要な Maximum Transmission Unit (MTU) が 2 つあります (ネットワークインターフェースカード (NIC) MTU とクラスターネットワーク MTU です)。

NIC MTU は OpenShift Container Platform のインストール時にのみ設定されます。MTU は、お使いのネットワークの NIC でサポートされる最大の値以下でなければなりません。スループットを最適化する場合は、可能な限り大きい値を選択します。レイテンシーを最低限に抑えるために最適化するには、より小さい値を選択します。

SDN オーバーレイの MTU は、最低でも NIC MTU より 50 バイト少なくなければなりません。これは、SDN オーバーレイのヘッダーに相当します。そのため、通常のイーサネットネットワークでは、この値を 1450 に設定します。ジャンボフレームのイーサネットネットワークの場合は、これを 8950 に設定します。

OVN および Geneve については、MTU は最低でも NIC MTU より 100 バイト少なくなければなりません。

注記

50 バイトのオーバーレイヘッダーは OpenShift SDN に関連します。他の SDN ソリューションの場合はこの値を若干変動させる必要があります。

12.3. IPsec の影響

ノードホストの暗号化、復号化に CPU 機能が使用されるので、使用する IP セキュリティーシステムにかかわらず、ノードのスループットおよび CPU 使用率の両方でのパフォーマンスに影響があります。

IPSec は、NIC に到達する前に IP ペイロードレベルでトラフィックを暗号化して、NIC オフロードに使用されてしまう可能性のあるフィールドを保護します。つまり、IPSec が有効な場合には、NIC アクセラレーション機能を使用できない場合があり、スループットの減少、CPU 使用率の上昇につながります。

第13章 ベアメタルホストの管理

OpenShift Container Platform をベアメタルクラスターにインストールする場合、クラスターに存在するベアメタルホストの machine および machineset カスタムリソース (CR) を使用して、ベアメタルノードをプロビジョニングし、管理できます。

13.1. ベアメタルホストおよびノードについて

Red Hat Enterprise Linux CoreOS (RHCOS) ベアメタルホストをクラスター内のノードとしてプロビジョニングするには、まずベアメタルホストハードウェアに対応する MachineSet カスタムリソース (CR) オブジェクトを作成します。ベアメタルホストマシンセットは、お使いの設定に固有のインフラストラクチャーコンポーネントを記述します。特定の Kubernetes ラベルをこれらのマシンセットに適用してから、インフラストラクチャーコンポーネントを更新して、それらのマシンでのみ実行されるようにします。

Machine CR は、metal3.io/autoscale-to-hosts アノテーションを含む関連する MachineSet をスケールアップする際に自動的に作成されます。OpenShift Container Platform は Machine CR を使用して、MachineSet CR で指定されるホストに対応するベアメタルノードをプロビジョニングします。

13.2. ベアメタルホストのメンテナンス

OpenShift Container Platform Web コンソールからクラスター内のベアメタルホストの詳細を維持することができます。ComputeBare Metal Hosts に移動し、Actions ドロップダウンメニューからタスクを選択します。ここでは、BMC の詳細、ホストの起動 MAC アドレス、電源管理の有効化などの項目を管理できます。また、ホストのネットワークインターフェースおよびドライブの詳細を確認することもできます。

ベアメタルホストをメンテナンスモードに移行できます。ホストをメンテナンスモードに移行すると、スケジューラーはすべての管理ワークロードを対応するベアメタルノードから移動します。新しいワークロードは、メンテナンスモードの間はスケジュールされません。

Web コンソールでベアメタルホストのプロビジョニングを解除することができます。ホストのプロビジョニング解除により以下のアクションが実行されます。

  1. ベアメタルホスト CR に cluster.k8s.io/delete-machine: true のアノテーションを付けます。
  2. 関連するマシンセットをスケールダウンします。
注記

デーモンセットおよび管理対象外の静的 Pod を別のノードに最初に移動することなく、ホストの電源をオフにすると、サービスの中断やデータの損失が生じる場合があります。

13.2.1. Web コンソールを使用したベアメタルホストのクラスターへの追加

Web コンソールのクラスターにベアメタルホストを追加できます。

前提条件

  • RHCOS クラスターのベアメタルへのインストール
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

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

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

13.2.2. Web コンソールの YAML を使用したベアメタルホストのクラスターへの追加

ベアメタルホストを記述する YAML ファイルを使用して、Web コンソールのクラスターにベアメタルホストを追加できます。

前提条件

  • クラスターで使用するために RHCOS コンピュートマシンをベアメタルインフラストラクチャーにインストールします。
  • cluster-admin 権限を持つユーザーとしてログインすること。
  • ベアメタルホストの Secret CR を作成します。

手順

  1. Web コンソールで、ComputeBare Metal Hosts に移動します。
  2. Add HostNew 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. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。ComputeMachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシン数を増やします。

    注記

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

13.2.3. 利用可能なベアメタルホストの数へのマシンの自動スケーリング

利用可能な BareMetalHost オブジェクトの数に一致する Machine オブジェクトの数を自動的に作成するには、metal3.io/autoscale-to-hosts アノテーションを MachineSet オブジェクトに追加します。

前提条件

  • クラスターで使用する RHCOS ベアメタルコンピュートマシンをインストールし、対応する BareMetalHost オブジェクトを作成します。
  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

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

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

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

注記

BareMetalHost オブジェクトを使用してクラスター内にマシンを作成し、その後ラベルまたはセレクターが BareMetalHost で変更される場合、BareMetalHost オブジェクトは Machine オブジェクトが作成された MachineSet に対して引き続きカウントされます。

第14章 Huge Page の機能およびそれらがアプリケーションによって消費される仕組み

14.1. Huge Page の機能

メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。

Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Pages (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

OpenShift Container Platform では、Pod のアプリケーションが事前に割り当てられた Huge Page を割り当て、消費することができます。

14.2. Huge Page がアプリケーションによって消費される仕組み

ノードは、Huge Page の容量をレポートできるように Huge Page を事前に割り当てる必要があります。ノードは、単一サイズの Huge Page のみを事前に割り当てることができます。

Huge Page は、リソース名の hugepages-<size> を使用してコンテナーレベルのリソース要件で消費可能です。この場合、サイズは特定のノードでサポートされる整数値を使用した最もコンパクトなバイナリー表記です。たとえば、ノードが 2048KiB ページサイズをサポートする場合、これはスケジュール可能なリソース hugepages-2Mi を公開します。CPU やメモリーとは異なり、Huge Page はオーバーコミットをサポートしません。

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
hugepages のメモリー量は、実際に割り当てる量に指定します。この値は、ページサイズで乗算した hugepages のメモリー量に指定しないでください。たとえば、Huge Page サイズが 2MB と仮定し、アプリケーションに Huge Page でバックアップする RAM 100 MB を使用する場合には、Huge Page は 50 に指定します。OpenShift Container Platform により、計算処理が実行されます。上記の例にあるように、100MB を直接指定できます。

指定されたサイズの Huge Page の割り当て

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケールサフィックス [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。

Huge page の要件

  • Huge Page 要求は制限と同じでなければなりません。制限が指定されているにもかかわらず、要求が指定されていない場合には、これがデフォルトになります。
  • Huge Page は、Pod のスコープで分割されます。コンテナーの分割は、今後のバージョンで予定されています。
  • Huge Page がサポートする EmptyDir ボリュームは、Pod 要求よりも多くの Huge Page メモリーを消費することはできません。
  • shmget()SHM_HUGETLB を使用して Huge Page を消費するアプリケーションは、proc/sys/vm/hugetlb_shm_group に一致する補助グループで実行する必要があります。

14.3. Huge Page の設定

ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Huge Page を予約する方法は、ブート時とランタイム時に実行する 2 つの方法があります。ブート時の予約は、メモリーが大幅に断片化されていないために成功する可能性が高くなります。Node Tuning Operator は、現時点で特定のノードでの Huge Page のブート時の割り当てをサポートします。

14.3.1. ブート時

手順

ノードの再起動を最小限にするには、以下の手順の順序に従う必要があります。

  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
    チューニングされたリソースの namehugepages に設定します。
    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

断片化されていないメモリーが十分にある場合、worker-hp マシン設定プールのすべてのノードには 50 2Mi の Huge Page が割り当てられているはずです。

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
警告

この機能は、現在 Red Hat Enterprise Linux CoreOS (RHCOS) 8.x ワーカーノードでのみサポートされています。Red Hat Enterprise Linux (RHEL) 7.x ワーカーノードでは、チューニングされた [bootloader] プラグインは現時点でサポートされていません。

第15章 低レイテンシーのノード向けの Performance Addon Operator

15.1. 低レイテンシー

Telco / 5G の領域でのエッジコンピューティングの台頭は、レイテンシーと輻輳を軽減し、アプリケーションのパフォーマンスを向上させる上で重要な役割を果たします。

簡単に言うと、レイテンシーは、データ (パケット) が送信側から受信側に移動し、受信側の処理後に送信側に戻るスピードを決定します。レイテンシーによる遅延を最小限に抑えた状態でネットワークアーキテクチャーを維持することが 5 G のネットワークパフォーマンス要件を満たすのに鍵となります。4G テクノロジーと比較し、平均レイテンシーが 50ms の 5G では、レイテンシーの数値を 1ms 以下にするようにターゲットが設定されます。このレイテンシーの減少により、ワイヤレスのスループットが 10 倍向上します。

Telco 領域にデプロイされるアプリケーションの多くは、ゼロパケットロスに耐えられる低レイテンシーを必要とします。パケットロスをゼロに調整すると、ネットワークのパフォーマンス低下させる固有の問題を軽減することができます。詳細は、「Tuning for Zero Packet Loss in Red Hat OpenStack Platform (RHOSP)」を参照してください。

エッジコンピューティングの取り組みは、レイテンシーの削減にも役立ちます。コンピュート能力が文字通りクラウドのエッジ上にあり、ユーザーの近く置かれること考えてください。これにより、ユーザーと離れた場所にあるデータセンター間の距離が大幅に削減されるため、アプリケーションの応答時間とパフォーマンスのレイテンシーが短縮されます。

管理者は、すべてのデプロイメントを可能な限り低い管理コストで実行できるように、多数のエッジサイトおよびローカルサービスを一元管理できるようにする必要があります。また、リアルタイムの低レイテンシーおよび高パフォーマンスを実現するために、クラスターの特定のノードをデプロイし、設定するための簡単な方法も必要になります。低レイテンシーノードは、Cloud-native Network Functions (CNF) や Data Plane Development Kit (DPDK) などのアプリケーションに役立ちます。

現時点で、OpenShift Container Platform はリアルタイムの実行および低レイテンシーを実現するために OpenShift Container Platform クラスターでソフトウェアを調整するメカニズムを提供します (約 20 マイクロ秒未満の応答時間)。これには、カーネルおよび OpenShift Container Platform の設定値のチューニング、カーネルのインストール、およびマシンの再設定が含まれます。ただし、この方法では 4 つの異なる Operator を設定し、手動で実行する場合に複雑であり、間違いが生じる可能性がある多くの設定を行う必要があります。

OpenShift Container Platform は、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現するために自動チューニングを実装する Performance Addon Operator を提供します。クラスター管理者は、このパフォーマンスプロファイル設定を使用することにより、より信頼性の高い方法でこれらの変更をより容易に実行することができます。管理者は、カーネルを kernel-rt、ハウスキーピング用に予約される CPU、ワークロードの実行に使用される CPU に更新するかどうかを指定できます。

15.2. Performance Addon Operator のインストール

Performance Addon Operator は、一連のノードで高度なノードのパフォーマンスチューニングを有効にする機能を提供します。クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Performance Addon Operator をインストールできます。

15.2.1. CLI を使用した Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • ベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) をインストールすること。
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

  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
      spec:
        targetNamespaces:
        - 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.6

    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

15.2.2. Web コンソールを使用した Performance Addon Operator のインストール

クラスター管理者は、Web コンソールを使用して Performance Addon Operator をインストールできます。

注記

先のセクションで説明されているように Namespace CR および OperatorGroup CR を作成する必要があります。

手順

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

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から Performance Addon Operator を選択してから Install をクリックします。
    3. Install Operator ページの A specific namespace on the cluster の下で、 openshift-performance-addon-operator を選択します。次に、Install をクリックします。
  2. オプション: performance-addon-operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. StatusInstallSucceeded の状態で、Performance Addon Operatoropenshift-performance-addon-operator プロジェクトに一覧表示されていることを確認します。

      注記

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

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

      • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • WorkloadsPods ページに移動し、performance-addon-operator プロジェクトで Pod のログを確認します。
重要

本書で説明されている機能は 開発者プレビュー を目的としており、現時点では Red Hat では サポートされていません。この機能を使用すると、ノードが再起動され、利用できなくなる可能性があります。

15.3. Performance Addon Operator のアップグレード

次のマイナーバージョンの Performance Addon Operator に手動でアップグレードし、Web コンソールを使用して更新のステータスをモニターできます。

15.3.1. Performance Addon Operator のアップグレードについて

  • OpenShift Web コンソールを使用して Operator サブスクリプションのチャネルを変更することで、Performance Addon Operator の次のマイナーバージョンにアップグレードできます。
  • Performance Addon Operator のインストール時に z-stream の自動更新を有効にできます。
  • 更新は、OpenShift Container Platform のインストール時にデプロイされる Marketplace Operator 経由で提供されます。Marketplace Operator は外部 Operator をクラスターで利用可能にします。
  • 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。

15.3.1.1. Performance Addon Operator のクラスターへの影響

  • 低レイテンシーのチューニング Huge Page は影響を受けません。
  • Operator を更新しても、予期しない再起動は発生しません。

15.3.1.2. Performance Addon Operator の次のマイナーバージョンへのアップグレード

OpenShift Container Platform Web コンソールを使用して Operator サブスクリプションのチャネルを変更することで、Performance Addon Operator を次のマイナーバージョンに手動でアップグレードできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。

手順

  1. OpenShift Web コンソールにアクセスし、 Operators → Installed Operators に移動します。
  2. Performance Addon Operator をクリックし、Operator Details ページを開きます。
  3. Subscription タブをクリックし、Subscription Overview ページを開きます。
  4. Channel ペインで、バージョン番号の右側にある鉛筆アイコンをクリックし、Change Subscription Update Channel ウィンドウを開きます。
  5. 次のマイナーバージョンを選択します。たとえば、Performance Addon Operator 4.6 にアップグレードする場合は、4.6 を選択します。
  6. Save をクリックします。
  7. Operators → Installed Operators に移動してアップグレードのステータスを確認します。以下の oc コマンドを実行してステータスを確認することもできます。

    $ oc get csv -n openshift-performance-addon-operator

15.3.2. アップグレードステータスの監視

Performance Addon Operator アップグレードステータスをモニターする最適な方法として、ClusterServiceVersion (CSV) PHASE を監視できます。Web コンソールを使用するか、または oc get csv コマンドを実行して CSV の状態をモニターすることもできます。

注記

PHASE および状態の値は利用可能な情報に基づく近似値になります。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。
  • OpenShift CLI (oc) をインストールすること。

手順

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

    $ oc get csv
  2. 出力を確認し、PHASE フィールドをチェックします。以下は例になります。

    VERSION    REPLACES                                         PHASE
    4.6.0      performance-addon-operator.v4.5.0                Installing
    4.5.0                                                       Replacing
  3. get csv を再度実行して出力を確認します。

    # oc get csv

    出力例

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
    performance-addon-operator.v4.5.0   Performance Addon Operator   4.6.0     performance-addon-operator.v4.5.0   Succeeded

15.4. リアルタイムおよび低レイテンシーワークロードのプロビジョニング

多くの企業や組織は、非常に高性能なコンピューティングを必要としており、とくに金融業界や通信業界では、低い、予測可能なレイテンシーが必要になる場合があります。このような固有の要件を持つ業界では、OpenShift Container Platform は Performance Addon Operatorを提供して、OpenShift Container Platformアプリケーションの低レイテンシーのパフォーマンスと一貫性のある応答時間を実現するための自動チューニングを実装します。

クラスター管理者は、このパフォーマンスプロファイル設定を使用することにより、より信頼性の高い方法でこれらの変更をより容易に実行することができます。管理者は、カーネルを kernel-rt (リアルタイム)、ハウスキーピング用に予約される CPU、ワークロードの実行に使用される CPU に更新するかどうかを指定できます。

15.4.1. リアルタイムの既知の制限

注記

RT カーネルはワーカーノードでのみサポートされます。

リアルタイムモードを完全に使用するには、コンテナーを昇格した権限で実行する必要があります。権限の付与についての情報は、「Set capabilities for a Container」を参照してください。

OpenShift Container Platform は許可される機能を制限するため、SecurityContext を作成する必要がある場合もあります。

注記

この手順は、Red Hat Enterprise Linux CoreOS (RHCOS) システムを使用したベアメタルのインストールで完全にサポートされます。

パフォーマンスの期待値を設定する必要があるということは、リアルタイムカーネルがあらゆる問題の解決策ではないということを意味します。リアルタイムカーネルは、一貫性のある、低レイテンシーの、決定論に基づく予測可能な応答時間を提供します。リアルタイムカーネルに関連して、追加のカーネルオーバーヘッドがあります。これは、主に個別にスケジュールされたスレッドでハードウェア割り込みを処理することによって生じます。一部のワークロードのオーバーヘッドが増加すると、スループット全体が低下します。ワークロードによって異なりますが、パフォーマンスの低下の程度は 0% から 30% の範囲になります。ただし、このコストは決定論をベースとしています。

15.4.2. リアルタイム機能のあるワーカーのプロビジョニング

  1. Performance Addon Operator をクラスターにインストールします。
  2. オプション: ノードを OpenShift Container Platform クラスターに追加します。BIOS パラメーターの設定について参照してください。
  3. オプション: リアルタイムノード向けに新規の設定マシン設定を作成します。
  4. ノードロールラベルを使用して、ノードを適切なマシン設定プールに追加します。

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

  5. ハウスキーピングコアの適切なセットと realTimeKernel: enabled: true を設定して PerformanceProfile を作成します。
  6. 以下に示すように、PerformanceProfile でノードセレクターを指定します。

    apiVersion: performance.openshift.io/v1
    kind: PerformanceProfile
    metadata:
     name: example-performanceprofile
    spec:
     [...]
      realTimeKernel:
        enabled: true
      nodeSelector:
        node-role.kubernetes.io/worker-rt: ""
  7. 一致するマシン設定プールがラベルを持つことを確認します。

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

15.4.3. リアルタイムカーネルのインストールの確認

以下のコマンドを使用して、リアルタイムカーネルがインストールされていることを確認します。

$ oc get node -o wide

文字列 4.18.0-211.rt5.23.el8.x86_64 が含まれる、ロール worker-rt を持つワーカーに留意してください。

NAME                               	STATUS   ROLES           	AGE 	VERSION                  	INTERNAL-IP
EXTERNAL-IP   OS-IMAGE                                       	KERNEL-VERSION
CONTAINER-RUNTIME
cnf-worker-0.example.com	          Ready	 worker,worker-rt   5d17h   v1.19.0-rc.2+aaf4ce1-dirty
128.66.135.107   <none>    	        Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa)
4.18.0-211.rt5.23.el8.x86_64   cri-o://1.19.0-90.rhaos4.6.git4a0ac05.el8-rc.1
[...]

15.4.4. リアルタイムで機能するワークロードの作成

リアルタイム機能を使用するワークロードを準備するには、以下の手順を使用します。

手順

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

アプリケーションを作成する場合には、「アプリケーションのチューニングとデプロイメント」に記載されている一般的な推奨事項に従ってください。

15.4.5. QoS クラスの Guaranteed を指定した Pod の作成

QoS クラスの Guaranteed が指定されている Pod を作成する際には、以下を考慮してください。

  • Pod のすべてのコンテナーにはメモリー制限およびメモリー要求があり、それらは同じである必要があります。
  • Pod のすべてのコンテナーには CPU の制限と CPU 要求が必要であり、それらは同じである必要があります。

以下の例は、1 つのコンテナーを持つ Pod の設定ファイルを示しています。コンテナーにはメモリー制限とメモリー要求があり、どちらも 200 MiB に相当します。コンテナーには CPU 制限と CPU 要求があり、どちらも 1 CPU に相当します。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"
  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 要求を自動的に割り当てます。

15.4.6. オプション: DPDK 用の CPU 負荷分散の無効化

CPU 負荷分散を無効または有効にする機能は CRI-O レベルで実装されます。CRI-O のコードは、以下の要件を満たす場合にのみ CPU の負荷分散を無効または有効にします。

  • Pod は performance-<profile-name> ランタイムクラスを使用する必要があります。以下に示すように、パフォーマンスプロファイルのステータスを確認して、適切な名前を取得できます。

    apiVersion: performance.openshift.io/v1
    kind: PerformanceProfile
    ...
    status:
      ...
      runtimeClass: performance-manual
  • Pod には cpu-load-balancing.crio.io: true アノテーションが必要です。

Performance Addon Operator は、該当するノードで高パフォーマンスのランタイムハンドラー設定スニペットの作成や、クラスターで高パフォーマンスのランタイムクラスの作成を行います。これには、 CPU 負荷分散の設定機能を有効にすることを除くと、デフォルトのランタイムハンドラーと同じ内容が含まれます。

Pod の CPU 負荷分散を無効にするには、 Pod 仕様に以下のフィールドが含まれる必要があります。

apiVersion: v1
kind: Pod
metadata:
  ...
  annotations:
    ...
    cpu-load-balancing.crio.io: "true"
    ...
  ...
spec:
  ...
  runtimeClassName: performance-<profile_name>
  ...
注記

CPU マネージャーの静的ポリシーが有効にされている場合に、CPU 全体を使用する Guaranteed QoS を持つ Pod について CPU 負荷分散を無効にします。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。

15.4.7. 適切なノードセレクターの割り当て

Pod をノードに割り当てる方法として、以下に示すようにパフォーマンスプロファイルが使用するものと同じノードセレクターを使用することが推奨されます。

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  [...]
  nodeSelector:
     node-role.kubernetes.io/worker-rt: ""

ノードセレクターの詳細は、「Placing pods on specific nodes using node selectors」を参照してください。

15.4.8. リアルタイム機能を備えたワーカーへのワークロードのスケジューリング

Performance Addon Operator によって低レイテンシーを確保するために設定されたマシン設定プールに割り当てられるノードに一致するラベルセレクターを使用します。詳細は、「Assigning pods to nodes」を参照してください。

15.5. Huge Page の設定

ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Performance Addon Operator を使用し、特定のノードで Huge Page を割り当てます。

OpenShift Container Platform は、Huge Page を作成し、割り当てる方法を提供します。Performance Addon Operator は、パーマンスプロファイルを使用してこれを実行するための簡単な方法を提供します。

たとえば、パフォーマンスプロファイルの hugepages pages セクションで、sizecount、およびオプションで node の複数のブロックを指定できます。

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1
1
node は、Huge Page が割り当てられる NUMA ノードです。node を省略すると、ページはすべての NUMA ノード間で均等に分散されます。
注記

更新が完了したことを示す関連するマシン設定プールのステータスを待機します。

これらは、Huge Page を割り当てるのに必要な唯一の設定手順です。

検証

  • 設定を確認するには、ノード上の /proc/meminfo ファイルを参照します。

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    出力例

    AnonHugePages:    ###### ##
    ShmemHugePages:        0 kB
    HugePages_Total:       2
    HugePages_Free:        2
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       #### ##
    Hugetlb:            #### ##

  • 新規サイズを報告するには、oc describe を使用します。

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    出力例

                                       hugepages-1g=true
     hugepages-###:  ###
     hugepages-###:  ###

15.6. 複数の Huge Page サイズの割り当て

同じコンテナーで異なるサイズの Huge Page を要求できます。これにより、Huge Page サイズのニーズの異なる複数のコンテナーで構成されるより複雑な Pod を定義できます。

たとえば、サイズ 1G2M を定義でき、Performance Addon Operator は以下に示すようにノード上に両方のサイズを設定できます。

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G
重要

本書で説明されている機能は 開発者プレビュー を目的としており、現時点では Red Hat では サポートされていません。この機能を使用すると、ノードが再起動され、利用できなくなる可能性があります。

15.7. パフォーマンスプロファイルによる低レイテンシーを実現するためのノードのチューニング

パフォーマンスプロファイルを使用すると、特定のマシン設定プールに属するノードのレイテンシーの調整を制御できます。設定を指定すると、PerformanceProfile オブジェクトは実際のノードレベルのチューニングを実行する複数のオブジェクトにコンパイルされます。

  • ノードを操作する MachineConfig ファイル。
  • Topology Manager、CPU マネージャー、および OpenShift Container Platform ノードを設定する KubeletConfig ファイル。
  • Node Tuning Operator を設定する Tuned プロファイル。

手順

  1. クラスターを準備します。
  2. マシン設定プールを作成します。
  3. Performance Addon Operator をインストールします。
  4. ハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。パフォーマンスプロファイルでは、カーネルを kernel-rt、hugepages の割り当て、オペレーティングシステムのハウスキーピング用に予約される CPU、およびワークロードの実行に使用される CPU に更新するかどうかを指定できます。

    これは、典型的なパフォーマンスプロファイルです。

    apiVersion: performance.openshift.io/v1
    kind: PerformanceProfile
    metadata:
     name: performance
    spec:
     cpu:
      isolated: "5-15"
      reserved: "0-4"
     hugepages:
      defaultHugepagesSize: "1G"
      pages:
      -size: "1G"
       count: 16
       node: 0
     realTimeKernel:
      enabled: true  1
     numa:  2
      topologyPolicy: "best-effort"
     nodeSelector:
      node-role.kubernetes.io/worker-cnf: ""
1
有効な値は true または false です。true 値を設定すると、ノード上にリアルタイムカーネルがインストールされます。
2
Topology Manager ポリシーを設定するには、このフィールドを使用します。有効な値は none (デフォルト)、 best-effortrestricted、および single-numa-node です。詳細は、「Topology Manager Policies」を参照してください。

15.7.1. CPU のパーティション設定

単一の NUMA ノードからオペレーティングシステムのハウスキーピングタスク用にコアまたはスレッドを予約し、ワークロードを別の NUMA ノードに配置することができます。これを実行する理由として、ハウスキーピングプロセスで同じ CPU 上で実行されるレイテンシーの影響を受けるプロセスに影響を与える可能性がある方法で CPU を使用する可能性があるためです。ワークロードを別の NUMA ノードで維持することにより、プロセスが相互に干渉しないようにすることができます。また、各 NUMA ノードには共有されない独自のメモリーバスがあります。

spec セクションに、CPU の 2 つのグループを指定します。

  • isolated: 最も低いレイテンシーが設定されます。このグループのプロセスには割り込みがないため、DPDK ゼロパケットロスの帯域幅がより高くなります。
  • reserved: ハウスキーピング CPU予約されたグループのスレッドはビジーになる可能性があるため、レイテンシーの影響を受けるアプリケーションは分離されたグループで実行される必要があります。「Create a pod that gets assigned a QoS class of Guaranteed」を参照してください。

15.8. プラットフォーム検証のエンドツーエンドテストの実行

Cloud-native Network Functions (CNF) テストイメージは、CNF ペイロードの実行に必要な機能を検証するコンテナー化されたテストスイートです。このイメージを使用して、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている CNF 対応の OpenShift クラスターを検証できます。

イメージで実行されるテストは、3 つの異なるフェーズに分かれます。

  • 単純なクラスター検証
  • セットアップ
  • エンドツーエンドテスト

検証フェーズでは、テストに必要なすべての機能がクラスターに正しくデプロイされていることを確認します。

検証には以下が含まれます。

  • テストするマシンに属するマシン設定プールのターゲット設定
  • ノードでの SCTP の有効化
  • Performance Addon Operator がインストールされていること
  • SR-IOV Operator がインストールされていること
  • PTP Operator がインストールされていること
  • OVN kubernetes の SDN としての使用

テストは、実行されるたびに環境設定を実行する必要があります。これには、SR-IOV ノードポリシー、パフォーマンスプロファイル、または PTP プロファイルの作成などの項目が関係します。テストですでに設定されているクラスターを設定できるようにすると、クラスターの機能が影響を受ける可能性があります。また、SR-IOV ノードポリシーなどの設定項目への変更により、設定の変更が処理されるまで環境が一時的に利用できなくなる可能性があります。

15.8.1. 前提条件

  • テストエントリーポイントは /usr/bin/test-run.sh です。設定されたテストセットと実際の適合テストスイートの両方を実行します。最小要件として、これをボリューム経由でマウントされる kubeconfig ファイルおよび関連する $KUBECONFIG 環境変数と共に指定します。
  • このテストでは、特定の機能が Operator、クラスターで有効にされるフラグ、またはマシン設定の形式でクラスターで利用可能であることを前提としています。
  • テストによっては、変更を追加するための既存のマシン設定プールが必要です。これは、テストを実行する前にクラスター上に作成する必要があります。

    デフォルトのワーカープールは worker-cnf であり、以下のマニフェストを使用して作成できます。

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

    ROLE_WORKER_CNF 変数を使用して、ワーカープール名を上書きできます。

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e
    ROLE_WORKER_CNF=custom-worker-pool registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh
    注記

    現時点で、プールに属するノードですべてのテストが選択的に実行される訳ではありません。

15.8.2. テストの実行

ファイルが現在のフォルダーにある場合、テストスイートを実行するコマンドは以下のようになります。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

これにより、kubeconfig ファイルを実行中のコンテナー内から使用できます。

15.8.3. イメージパラメーター

要件に応じて、テストは異なるイメージを使用できます。以下の環境変数を使用して変更できるテストで、以下の 2 つのイメージが使用されます。

  • CNF_TESTS_IMAGE
  • DPDK_TESTS_IMAGE

たとえば、カスタムレジストリーを使用して CNF_TESTS_IMAGE を変更するには、以下のコマンドを実行します。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

15.8.3.1. ginkgo パラメーター

テストスイートは、ginkgo BDD フレームワーク上に構築されます。これは、テストをフィルターするか、または省略するためのパラメーターを受け入れることを意味します。

-ginkgo.focus パラメーターを使用してテストセットをフィルターできます。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh -ginkgo.focus="performance|sctp"
注記

特定のテストでは、SR-IOV と SCTP の両方が必要になります。focus パラメーターの選択的な性質を考慮すると、このテストは sriov Matcher のみを配置してトリガーできます。テストが SR-IOV がインストールされているクラスターに対して実行されるものの、SCTP がはない場合、-ginkgo.skip=SCTP パラメーターを追加すると、テストは SCTP テストを省略します。

15.8.3.2. 利用可能な機能

フィルターに使用できる機能のセットは以下になります。

  • performance
  • sriov
  • ptp
  • sctp
  • dpdk

15.8.4. ドライラン

このコマンドを使用してドライランモードで実行します。これは、テストスイートの内容を確認し、イメージが実行するすべてのテストの出力を提供します。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh -ginkgo.dryRun -ginkgo.v

15.8.5. 非接続モード

CNF は、非接続クラスター、つまり外部レジストリーに到達できないクラスターでテストを実行してイメージのサポートをテストします。これは 2 つの手順で行います。

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

15.8.5.1. クラスターからアクセスできるカスタムレジストリーへのイメージのミラーリング

mirror 実行可能ファイルはイメージに含まれ、テストをローカルレジストリーに対して実行するために必要なテストをミラーリングするために oc で必要な入力を提供します。

クラスターおよびインターネット経由で registry.redhat.io にアクセスできる中間マシンから、以下のコマンドを実行します。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror -registry my.local.registry:5000/ |  oc image mirror -f -

次に、イメージの取得に使用されるレジストリーを上書きする方法について、以下のセクションの手順に従います。

15.8.5.2. テストに対してカスタムレジストリーからのそれらのイメージを使用するように指示します。

これは、IMAGE_REGISTRY 環境変数を設定して実行されます。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY="my.local.registry:5000/" -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

15.8.5.3. クラスター内部レジストリーへのミラーリング

OpenShift Container Platform は、クラスター上の標準ワークロードとして実行される組み込まれたコンテナーイメージレジストリーを提供します。

手順

  1. レジストリーをルートを使用して公開し、レジストリーへの外部アクセスを取得します。

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. レジストリーエンドポイントを取得します。

    REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. イメージを公開する namespace を作成します。

    $ oc create ns cnftests
  4. イメージストリームを、テストに使用されるすべての namespace で利用可能にします。これは、テスト namespace が cnftests イメージストリームからイメージを取得できるようにするために必要です。

    $ oc policy add-role-to-user system:image-puller system:serviceaccount:sctptest:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:dpdk-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:sriov-conformance-testing:default --namespace=cnftests
  5. docker シークレット名と認証トークンを取得します。

    SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
    TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
  6. 以下のような dockerauth.json を作成します。

    echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
  7. ミラーリングを実行します。

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true -a=$(pwd)/dockerauth.json -f -
  8. テストを実行します。

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh

15.8.5.4. イメージの異なるセットのミラーリング

手順

  1. mirror コマンドは、デフォルトで u/s イメージのミラーリングを試行します。これは、以下の形式のファイルをイメージに渡すことで上書きできます。

    [
        {
            "registry": "public.registry.io:5000",
            "image": "imageforcnftests:4.6"
        },
        {
            "registry": "public.registry.io:5000",
            "image": "imagefordpdk:4.6"
        }
    ]
  2. これを mirror コマンドに渡します。たとえば、images.json としてローカルに保存できます。以下のコマンドでは、ローカルパスはコンテナー内の /kubeconfig にマウントされ、これを mirror コマンドに渡すことができます。

    $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/mirror --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" |  oc image mirror -f -

15.8.6. 検出モード

検出モードでは、設定を変更せずにクラスターの機能を検証できます。既存の環境設定はテストに使用されます。テストは必要な設定項目の検索を試行し、それらの項目を使用してテストを実行します。特定のテストの実行に必要なリソースが見つからない場合、テストは省略され、ユーザーに適切なメッセージが表示されます。テストが完了すると、事前に設定された設定項目のクリーンアップは行われず、テスト環境は別のテストの実行にすぐに使用できます。

一部の設定項目は、テストで引き続き作成されます。これらの項目は、テストを実行するために必要な特定の項目です (例: SR-IOV ネットワーク)。これらの設定項目はカスタム namespace に作成され、テストの実行後にクリーンアップされます。

さらに、これによりテストの実行時間が削減されます。設定項目はすでに存在しているので、環境設定および安定化に追加の時間は取る必要はありません。

検出モードを有効にするには、以下のように DISCOVERY_MODE 環境変数を設定してテストに対して指示する必要があります。

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
DISCOVERY_MODE=true registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh

15.8.6.1. 必要な環境設定の前提条件

SR-IOV テスト

ほとんどの SR-IOV テストには以下のリソースが必要です。

  • SriovNetworkNodePolicy
  • SriovNetworkNodePolicy で指定されるリソースの 1 つ以上が割り当て可能な状態であること。リソース数が 5 以上の場合に十分であると見なされます。

テストによっては、追加の要件があります。

  • 利用可能なポリシーリソースがあるノード上の未使用のデバイス。リンク状態が DOWN であり、ブリッジスレーブではない。
  • MTU 値が 9000SriovNetworkNodePolicy

DPDK テスト

DPDK 関連のテストには、以下が必要です。

  • パフォーマンスプロファイル
  • SR-IOV ポリシー。
  • SRIOV ポリシーで利用可能なリソースが含まれ、PerformanceProfile ノードセレクターで利用可能なノード。

PTP テスト

  • スレーブ PtpConfig (ptp4lOpts="-s" ,phc2sysOpts="-a -r")。
  • スレーブ PtpConfig に一致するラベルの付いたノード。

SCTP テスト

  • SriovNetworkNodePolicy
  • SriovNetworkNodePolicy および SCTP を有効にする MachineConfig の両方に一致するノード。

Performance Operator のテスト

各種のテストにはそれぞれ異なる要件があります。以下はその一部になります。

  • パフォーマンスプロファイル
  • profile.Spec.CPU.Isolated = 1 を持つパフォーマンスプロファイル。
  • profile.Spec.RealTimeKernel.Enabled == true を持つパーマンスプロファイル。
  • Huge Page が使用されていないノード。

15.8.6.2. テスト中に使用されるノードの制限

テストが実行されるノードは、NODES_SELECTOR 環境変数を指定して制限できます。テストによって作成されるリソースは、指定されるノードに制限されます。

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
NODES_SELECTOR=node-role.kubernetes.io/worker-cnf registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh

15.8.6.3. 単一のパフォーマンスプロファイルの使用

DPDK テストで必要なリソースは、パフォーマンスのテストスイートで必要なリソースのレベルよりも高くなります。実行をより高速にするために、テストで使用されるパフォーマンスプロファイルは、DPDK テストスイートも提供するプロファイルを使用して上書きできます。

これを実行するには、コンテナー内にマウントできる以下のようなプロファイルを使用し、パフォーマンステストに対してこれをデプロイするように指示できます。

apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "4-15"
    reserved: "0-3"
  hugepages:
    defaultHugepagesSize: "1G"
    pages:
    - size: "1G"
      count: 16
      node: 0
  realTimeKernel:
    enabled: true
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""

使用されるパフォーマンスプロファイルを上書きするには、マニフェストをコンテナー内にマウントし、PERFORMANCE_PROFILE_MANIFEST_OVERRIDE パラメーターを設定してテストに対して指示する必要があります。

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh

15.8.6.4. パフォーマンスプロファイルのクリーンアップの無効化

検出モードで実行されない場合、スイートは作成されるすべてのアーティファクトおよび設定をクリーンアップします。これには、パフォーマンスプロファイルが含まれます。

パフォーマンスプロファイルを削除する際に、マシン設定プールが変更され、ノードが再起動されます。新規の繰り返しの後に、新規プロファイルが作成されます。これにより、長いテストサイクルが実行間に生じます。

このプロセスを迅速化するには、CLEAN_PERFORMANCE_PROFILE="false" を設定し、パフォーマンスプロファイルをクリーンアップしないようにテストに指示します。これにより、次の反復でこれを作成し、これが適用されるのを待機する必要がなくなります。

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
CLEAN_PERFORMANCE_PROFILE="false" registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh

15.8.7. トラブルシューティング

クラスターはコンテナー内からアクセスできる必要があります。これを確認するには、以下を実行します。

$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig
registry.redhat.io/openshift-kni/cnf-tests oc get nodes

これが機能しない場合は、原因が DNS、MTU サイズ、またはファイアウォールの問題に関連している可能性があります。

15.8.8. テストレポート

CNF エンドツーエンドテストにより、JUnit テスト出力とテスト失敗レポートという 2 つの出力が生成されます。

15.8.8.1. JUnit テスト出力

レポートがダンプされるパスと共に --junit パラメーターを渡すと、JUnit 準拠の XML が作成されます。

$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/junitdest:/path/to/junit -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh --junit /path/to/junit

15.8.8.2. テスト失敗レポート

クラスターの状態とトラブルシューティング用のリソースに関する情報が含まれるレポートは、レポートがダンプされるパスと共に --report パラメーターを渡すことで生成できます。

$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/reportdest:/path/to/report -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh --report /path/to/report

15.8.8.3. podman に関する注記

非 root として、また権限なしで podman を実行する場合、「permission denied」というエラーを出してパスのマウントに失敗する可能性があります。これを機能させるには、:Z をボリューム作成に追加します。たとえば、-v $(pwd)/:/kubeconfig:Z を使用して podman が SELinux のラベルを適切に書き換えることができます。

15.8.8.4. OpenShift Container Platform 4.4 での実行

以下を除き、CNF のエンドツーエンドのテストは OpenShift Container Platform 4.4 と互換性があります。

[test_id:28466][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through openshift-node-performance profile
[test_id:28467][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through the openshift-node-performance profile

これらのテストを省略するには、-ginkgo.skip "28466|28467" パラメーターを追加します。

15.8.8.5. 単一のパフォーマンスプロファイルの使用

DPDK テストには、パフォーマンステストスイートに必要なリソースよりも多くのリソースが必要です。実行をより迅速にするには、DPDK テストスイートを提供するプロファイルを使用して、テストが使用するパフォーマンスプロファイルを上書きすることができます。

これを実行するには、コンテナー内にマウントできる以下のようなプロファイルを使用し、パフォーマンステストに対してこれをデプロイするように指示できます。

apiVersion: performance.openshift.io/v1
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "5-15"
  reserved: "0-4"
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  -size: "1G"
   count: 16
   node: 0
 realTimeKernel:
  enabled: true
 numa:
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""

パフォーマンスプロファイルを上書きするには、マニフェストをコンテナー内にマウントし、PERFORMANCE_PROFILE_MANIFEST_OVERRIDE を設定してテストに対して指示する必要があります。

$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift4/cnf-tests-rhel8:v4.6 /usr/bin/test-run.sh

15.8.9. クラスターへの影響

機能によっては、テストスイートを実行すると、クラスターに異なる影響が及ぶ可能性があります。通常、SCTP テストのみではクラスター設定を変更しません。他のすべての機能は設定にさまざまな影響を与えます。

15.8.9.1. SCTP

SCTP テストは、接続性をチェックするために異なるノードで異なる Pod を実行するのみです。クラスターへの影響は、2 つのノードでの単純な Pod の実行に関連します。

15.8.9.2. SR-IOV

SR-IOV テストには、SR-IOV ネットワーク設定での変更が必要になります。この場合、テストは異なるタイプの設定を作成し、破棄します。

これは、既存の SR-IOV ネットワーク設定がクラスターにインストールされている場合に影響を与える可能性があります。これらの設定の優先順位によっては競合が生じる可能性があるためです。

同時に、テストの結果は既存の設定による影響を受ける可能性があります。

15.8.9.3. PTP

PTP テストは、PTP 設定をクラスターのノードセットに適用します。SR-IOV と同様に、これはすでに有効な既存の PTP 設定と競合する可能性があります。これにより予測不可能な結果が出される可能性があります。

15.8.9.4. パフォーマンス

パフォーマンステストにより、パフォーマンスプロファイルがクラスターに適用されます。これにより、ノード設定の変更、CPU の予約、メモリー Huge Page の割り当て、およびカーネルパッケージのリアルタイムの設定が行われます。performance という名前の既存のプロファイルがクラスターですでに利用可能な場合、テストはこれをデプロイしません。

15.8.9.5. DPDK

DPDK はパフォーマンスおよび SR-IOV 機能の両方に依存するため、テストスイートはパフォーマンスプロファイルと SR-IOV ネットワークの両方を設定します。そのため、これによる影響は SR-IOV テストおよびパフォーマンステストで説明されているものと同じになります。

15.8.9.6. クリーンアップ

テストスイートの実行後に、未解決のリソースすべてがクリーンアップされます。

15.9. 低レイテンシー CNF チューニングステータスのデバッグ

PerformanceProfile カスタムリソース (CR) には、チューニングのステータスを報告し、レイテンシーのパフォーマンスの低下の問題をデバッグするためのステータスフィールドが含まれます。これらのフィールドは、Operator の調整機能の状態を記述する状態について報告します。

パフォーマンスプロファイルに割り当てられるマシン設定プールのステータスが degraded 状態になると典型的な問題が発生する可能性があり、これにより PerformanceProfile のステータスが低下します。この場合、マシン設定プールは失敗メッセージを発行します。

Performance Addon Operator には performanceProfile.spec.status.Conditions ステータスフィールドが含まれます。

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status フィールドには、 パフォーマンスプロファイルのステータスを示す Type 値を指定する Conditions が含まれます。

Available
すべてのマシン設定および Tuned プロファイルが正常に作成され、クラスターコンポーネントで利用可能になり、それら (NTO、MCO、Kubelet)を処理します。
Upgradeable
Operator によって維持されるリソースは、アップグレードを実行する際に安全な状態にあるかどうかを示します。
Progressing
パフォーマンスプロファイルからのデプロイメントプロセスが開始されたことを示します。
Degraded

以下の場合にエラーを示します。

  • パーマンスプロファイルの検証に失敗しました。
  • すべての関連するコンポーネントの作成が完了しませんでした。

これらのタイプには、それぞれ以下のフィールドが含まれます。

Status
特定のタイプの状態 (true または false)。
Timestamp
トランザクションのタイムスタンプ。
Reason string
マシンの読み取り可能な理由。
Message string
状態とエラーの詳細を説明する人が判読できる理由 (ある場合)。

15.9.1. マシン設定プール

パフォーマンスプロファイルとその作成される製品は、関連付けられたマシン設定プール (MCP) に従ってノードに適用されます。MCP は、カーネル引数、kube 設定、Huge Page の割り当て、および rt-kernel のデプロイメントを含むパフォーマンスアドオンが作成するマシン設定の適用についての進捗に関する貴重な情報を保持します。パフォーマンスアドオンコントローラーは MCP の変更を監視し、それに応じてパフォーマンスプロファイルのステータスを更新します。

MCP がパフォーマンスプロファイルのステータスに返す状態は、MCP が Degraded の場合のみとなり、この場合、performaceProfile.status.condition.Degraded = true になります。

以下の例は、これに作成された関連付けられたマシン設定プール (worker-cnf) を持つパフォーマンスプロファイルのサンプルです。

  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

15.10. Red Hat サポート向けの低レイテンシーのチューニングデバッグデータの収集

サポートケースを作成する際、ご使用のクラスターについてのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。

must-gather ツールを使用すると、ノードのチューニング、NUMA トポロジー、および低レイテンシーの設定に関する問題のデバッグに必要な OpenShift Container Platform クラスターについての診断情報を収集できます。

迅速なサポートを得るには、OpenShift Container Platform と低レイテンシーチューニングの両方の診断情報を提供してください。

15.10.1. must-gather ツールについて

oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。

  • リソース定義
  • 監査ログ
  • サービスログ

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

15.10.2. 低レイテンシーチューニングデータの収集について

oc adm must-gather CLI コマンドを使用してクラスターについての情報を収集できます。これには、以下を始めとする低レイテンシーチューニングに関連する機能およびオブジェクトが含まれます。

  • Performance Addon Operator namespace および子オブジェクト
  • MachineConfigPool および関連付けられた MachineConfig オブジェクト
  • Node Tuning Operator および関連付けられた Tuned オブジェクト
  • Linux カーネルコマンドラインオプション
  • CPU および NUMA トポロジー
  • 基本的な PCI デバイス情報と NUMA 局所性

must-gather を使用して Container-native Virtualization データを収集するには、Container-native Virtualization イメージを指定する必要があります。

--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8.

15.10.3. 特定の機能に関するデータ収集

oc adm must-gather CLI コマンドを --image または --image-stream 引数と共に使用して、特定に機能についてのデバッグ情報を収集できます。must-gather ツールは複数のイメージをサポートするため、単一のコマンドを実行して複数の機能についてのデータを収集できます。

注記

特定の機能データに加えてデフォルトのmust-gather データを収集するには、--image-stream=openshift/must-gather 引数を追加します。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。
  • OpenShift Container Platform CLI (oc) がインストールされている。

手順

  1. must-gather データを保存するディレクトリーに移動します。
  2. oc adm must-gather コマンドを 1 つまたは複数の --image または --image-stream 引数と共に実行します。たとえば、以下のコマンドは、デフォルトのクラスターデータと Container-native Virtualization に固有の情報の両方を収集します。

    $ oc adm must-gather \
     --image-stream=openshift/must-gather \ 1
    
     --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8 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 カスタマーポータル で作成したサポートケースに添付します。

関連情報

第16章 Intel FPGA PAC N3000 および Intel vRAN Dedicated Accelerator ACC100 でのデータプレーンのパフォーマンスの最適化

16.1. OpenShift Container Platform 向け Intel ハードウェアアクセラレーターカードについて

Intel 高速 4G/LTE および 5G Virtualized Radio Access Networks (vRAN) ワークロードからのハードウェアアクセラレーターカード。これにより、市販の既製のプラットフォームの全体的な計算能力が向上します。

Intel FPGA PAC N3000

Intel FPGA PAC N3000 はリファレンス FPGA であり、5G または 4G/LTE RAN レイヤー 1 (L1) 基地局ネットワーク機能を高速化するワークロードの例として 4G/LTE または 5G フォワードエラー補正 (FEC) を使用します。vRAN ワークロードをサポートするために、4G/LTE または 5G ビットストリームを持つ Intel FPGA PAC N3000 カードをフラッシュします。

Intel FPGA PAC N3000 は、マルチワークロードネットワーキングアプリケーションアクセラレーション向け全二重、100 Gbps インシステムの再プログラム可能なアクセラレーションカードです。

Intel FPGA PAC N3000 が 4G/LTE または 5G ビットストリームでプログラム化されると、vRAN ワークロードの FEC を加速するのに使用する SR-IOV (Single Root I/O Virtualization) の仮想関数 (VF) デバイスを公開します。クラウドネイティブなデプロイメントのためにこの機能を活用するには、複数の VF を作成するために、デバイスの物理関数 (PF) を pf-pci-stub ドライバーにバインドする必要があります。VF の作成後、VF は、vRAN ワークロードを実行する特定の Pod に割り当てるために DPDK ユーザー空間ドライバー (vfio) にバインドする必要があります。

OpenShift Container Platform での Intel FPGA PAC N3000 サポートは 2 つの Operator に依存します。

  • Intel FPGA PAC N3000 (プログラミング) 向け OpenNESS Operator
  • ワイヤレス FEC Accelerator 向け OpenNESS Operator

vRAN Dedicated Accelerator ACC100

Intel の eASIC テクノロジーに基づく vRAN Dedicated Accelerator ACC100 は、4G/LTE および 5G テクノロジーに対する前方誤り訂正のコンピューター集約型プロセスをオフロードし、処理能力を解放するように設計されています。Intel eASIC デバイスは構成された ASIC で、FPGA と標準のアプリケーション固有の統合サーキット (ASIC) 間の中間テクノロジーです。

OpenShift Container Platform での Intel vRAN Dedicated Accelerator ACC100 サポートは 1 つの Operator を使用します。

  • ワイヤレス FEC Accelerator 向け OpenNESS Operator

16.2. Intel FPGA PAC N3000 向け OpenNESS Operator のインストール

Intel FPGA PAC N3000 向け OpenNESS Operator は、OpenShift Container Platform クラスター内の Intel FPGA PAC N3000 カードによって公開されるリソースまたはデバイスをオーケストレーションし、管理します。

vRAN ユースケースの場合、Intel FPGA PAC N3000 向け OpenNESS Operator はワイヤレス FEC Accelerator の OpenNESS Operator で使用されます。

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Intel FPGA PAC N3000 の OpenNESS Operator をインストールできます。

16.2.1. CLI を使用した Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • ベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) をインストールすること。
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

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

    1. 以下の例のように n3000-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 n3000-namespace.yaml
  2. 直前の手順で作成した namespace に N3000 Operator をインストールします。

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

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
          name: n3000-operators
          namespace: vran-acceleration-operators
      spec:
          targetNamespaces:
          - vran-acceleration-operators
    2. 以下のコマンドを実行して OperatorGroup CR を作成します。

      $ oc create -f n3000-operatorgroup.yaml
    3. 以下のコマンドを実行して、次の手順に必要な channel の値を取得します。

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

      出力例

      stable

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: n3000-subscription
          namespace: vran-acceleration-operators
      spec:
          channel: "<channel>"        1
          name: n3000
          source: certified-operators 2
          sourceNamespace: openshift-marketplace
      1
      .status.defaultChannel パラメーターの直前の手順で取得した値からチャネルの値を指定します。
      2
      certified-operators 値を指定する必要があります。
    5. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f n3000-sub.yaml

検証

  • Operator がインストールされていることを確認します。

    $ oc get csv

    出力例

    NAME            DISPLAY                                         VERSION  REPLACES    PHASE
    n3000.v1.1.0    OpenNESS Operator for Intel® FPGA PAC N3000     1.1.0                Succeeded

    Operator が正常にインストールされました。

16.2.2. Web コンソールを使用した Intel FPGA PAC N3000 Operator 向け OpenNESS Operator のインストール

クラスター管理者は、Web コンソールを使用して Intel FPGA PAC N3000 の OpenNESS Operator をインストールできます。

注記

先のセクションで説明されているように Namespace および OperatorGroup CR を作成する必要があります。

手順

  1. OpenShift Container Platform Web コンソールを使用して、Intel FPGA PAC N3000 向け OpenNESS Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から Intel FPGA PAC N3000 向け OpenNESS Operator を選択し、Install をクリックします。
    3. Install Operator ページで、All namespaces on the cluster を選択します。次に、Install をクリックします。
  2. オプション: N3000 Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. Intel FPGA PAC N3000 向け OpenNESS OperatorStatusInstallSucceededvran-acceleration-operators プロジェクトに一覧表示されていることを確認します。

      注記

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

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

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

16.3. Intel FPGA PAC N3000 向けの OpenNESS Operator のプログラミング

Intel FPGA PAC N3000 が vRAN 5G ビットストリームでプログラムされると、ハードウェアは vRAN 5G ビットストリームで Intel FPGA PAC N3000 を公開します。このビットストリームは、vRAN ワークロードの FEC を加速するために使用される SR-IOV (Single Root I/O Virtualization) 仮想機能 (VF) デバイスを公開します。

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Intel FPGA PAC N3000 の OpenNESS Operator をインストールできます。

16.3.1. vRAN ビットストリームを持つ N3000 のプログラミング

クラスター管理者は、vRAN 5G ビットストリームを持つ Intel FPGA PAC N3000 をプログラムできます。このビットストリームは、vRAN ワークロードの前方誤り訂正 (FEC) を加速するために使用される SR-IOV (Single Root I/O Virtualization) 仮想機能 (VF) デバイスを公開します。

前方誤り訂正 (FEC) の役割は、メッセージ内の特定のビットが失われたり、文字化けしている可能性がある転送エラーの修正です。伝送メディアのノイズ、干渉、または信号強度の低下により、メッセージが失われたり文字化けしたりする可能性があります。FEC を使用しないと、文字化けしたメッセージは、ネットワーク負荷に加え、スループットとレイテンシーの両方に影響を与える必要があります。

前提条件

  • Intel FPGA PAC N3000 カード
  • RT カーネル設定のある Performance Addon Operator
  • Intel FPGA PAC N3000 向け OpenNESS Operator でインストールされる 1 つまたは複数のノード
  • cluster-admin 権限を持つユーザーとしてログインします。

    注記

    すべてのコマンドは vran-acceleration-operators namespace で実行されます。

手順

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

    $ oc project vran-acceleration-operators
  2. Pod が実行されていることを確認します。

    $ oc get pods

    出力例

    NAME                                        READY       STATUS          RESTARTS    AGE
    fpga-driver-daemonset-8xz4c                 1/1         Running         0           15d
    fpgainfo-exporter-vhvdq                     1/1         Running         1           15d
    N3000-controller-manager-b68475c76-gcc6v    2/2         Running         1           15d
    N3000-daemonset-5k55l                       1/1         Running         1           15d
    N3000-discovery-blmjl                       1/1         Running         1           15d
    N3000-discovery-lblh7                       1/1         Running         1           15d

    以下のセクションでは、インストールされた Pod に関する情報を提供します。

    • fpga-driver-daemonset は必要な Open Programmable Accelerator Engine (OPAE) ドライバーを提供し、読み込みます。
    • fpgainfo-exporter は Prometheus に N3000 Telemetry データを提供します。
    • N3000-controller-manager は N3000Node CR をクラスターに適用し、すべてのオペランドコンテナーを管理します。
    • N3000-daemonset が主要なワーカーアプリケーションです。これは各ノードの CR の変更を監視し、変更に基づいて動作します。このデーモンに実装されたロジックは、カードの FPGA ユーザーイメージおよび NIC ファームウェアの更新を行います。また、ノードをドレイン (解放) し、更新で必要になる場合に提出します。
    • N3000-discovery は、デバイスが存在する場合にワーカーノードがインストールされ、ラベルのワーカーノードがある場合に N3000 Accelerator デバイスを検出します。
  3. Intel FPGA PAC N3000 カードを含むすべてのノードを取得します。

    $ oc get n3000node

    出力例

    NAME                       FLASH
    node1                      NotRequested

  4. 各ノードのカードに関する情報を取得します。

    $ oc get n3000node node1 -o yaml

    出力例

    status:
      conditions:
      - lastTransitionTime: "2020-12-15T17:09:26Z"
        message: Inventory up to date
        observedGeneration: 1
        reason: NotRequested
        status: "False"
        type: Flashed
      fortville:
      - N3000PCI: 0000:1b:00.0
        NICs:
        - MAC: 64:4c:36:11:1b:a8
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1a:00.0
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:a9
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1a:00.1
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:ac
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1c:00.0
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
        - MAC: 64:4c:36:11:1b:ad
          NVMVersion: 7.00 0x800052b0 0.0.0
          PCIAddr: 0000:1c:00.1
          name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
      fpga:
      - PCIAddr: 0000:1b:00.0 1
        bitstreamId: "0x23000410010310" 2
        bitstreamVersion: 0.2.3
        deviceId: "0x0b30"

    1
    PCIAddr フィールドは、カードの PCI アドレスを表示します。
    2
    bitstreamId フィールドは、現在フラッシュに保存されるビットストリームを示します。
  5. 現在の bitstreamIdPCIAddr、名前、および deviceId を「0x」パディングなしで保存します。

    $ oc get n3000node -o json
  6. Intel FPGA PAC N3000 カードのユーザービットストリームを更新します。

    1. 以下の例のように n3000-cluster.yaml という名前のファイルを作成し、N3000 クラスターリソースをプログラムに定義します。

      apiVersion: fpga.intel.com/v1
      kind: N3000Cluster
      metadata:
          name: n3000 1
          namespace: vran-acceleration-operators
      spec:
          nodes:
            - nodeName: "node1" 2
              fpga:
                - userImageURL: "http://10.10.10.122:8000/pkg/20ww27.5-2x2x25G-5GLDPC-v1.6.1-3.0.0_unsigned.bin" 3
                  PCIAddr: "0000:1b:00.0" 4
                  checksum: "0b0a87b974d35ea16023ceb57f7d5d9c" 5
      1
      名前を指定します。名前は n3000 である必要があります。
      2
      プログラムするノードを指定します。
      3
      ユーザービットストリームの URL を指定します。このビットストリームファイルは、HTTP または HTTPS サーバーでアクセスできる必要があります。
      4
      プログラムするカードの PCI アドレスを指定します。
      5
      userImageURL フィールドに指定されるビットストリームの MD5 チェックサムを指定します。

      N3000 デーモンは、Open Programmable Acceleration Engine (OPAE) ツールを使用して FPGA ユーザービットストリームを更新し、PCI デバイスをリセットします。FPGA ユーザービットストリームの更新では、カードごとに最大 40 分かかる場合があります。複数のノードでカードをプログラミングする場合、プログラミングは一度に 1 つのノードで構成されます。

    2. 更新を適用して、ビットストリームでカードのプログラミングを開始します。

      $ oc apply -f n3000-cluster.yaml

      N3000 デーモンは、適切な 5G FEC ユーザービットストリーム (この例では 20ww27.5-2x2x25G-5GLDPC-v1.6.1-3.0.0_unsigned.bin などがプロビジョニングされた後、および CR が作成された後に) ビットストリームのプログラミングを開始します。

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

      oc get n3000node

      出力例

      NAME             FLASH
      node1            InProgress

  7. ログを確認します。

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

      $ oc get pod -o wide | grep n3000-daemonset | grep node1

      出力例

      n3000-daemonset-5k55l              1/1     Running   0          15d

    2. ログを表示します。

      $ oc logs n3000-daemonset-5k55l

      出力例

      ...
      {"level":"info","ts":1608054338.8866854,"logger":"daemon.drainhelper.cordonAndDrain()","msg":"node drained"}
      {"level":"info","ts":1608054338.8867319,"logger":"daemon.drainhelper.Run()","msg":"worker function - start"}
      {"level":"info","ts":1608054338.9003832,"logger":"daemon.fpgaManager.ProgramFPGAs","msg":"Start program","PCIAddr":"0000:1b:00.0"}
      {"level":"info","ts":1608054338.9004142,"logger":"daemon.fpgaManager.ProgramFPGA","msg":"Starting","pci":"0000:1b:00.0"}
      {"level":"info","ts":1608056309.9367146,"logger":"daemon.fpgaManager.ProgramFPGA","msg":"Program FPGA completed, start new power cycle N3000 ...","pci":"0000:1b:00.0"}
      {"level":"info","ts":1608056333.3528838,"logger":"daemon.drainhelper.Run()","msg":"worker function - end","performUncordon":true}
      ...

      ログファイルは、以下のイベントのフローを示します。

      • ビットストリームがダウンロードされ、検証されています。
      • ノードはドレイン (解放) され、現時点でワークロードを実行できません。
      • フラッシュが開始します。

        • ビットストリームはカードにフラッシュされます。
        • ビットストリームが適用されます。
      • フラッシュが完了すると、1 つまたは複数のノードの PCI デバイス (1 つまたは複数) が再読み込みされます。ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator が、新しいフラッシュデバイス (1 つまたは複数) を検索できるようになりました。

検証

  1. FPGA のユーザービットストリームの更新が完了した後にステータスを確認します。

    oc get n3000node

    出力例

    NAME             FLASH
    node1            Succeeded

  2. カードのビットストリーム ID が変更されたことを確認します。

    oc get n3000node node1 -o yaml

    出力例

    status:
          conditions:
              - lastTransitionTime: "2020-12-15T18:18:53Z"
                message: Flashed successfully 1
                observedGeneration: 2
                reason: Succeeded
                status: "True"
                type: Flashed
          fortville:
          - N3000PCI: 0000:1b:00.0
            NICs:
            - MAC: 64:4c:36:11:1b:a8
              NVMVersion: 7.00 0x800052b0 0.0.0
              PCIAddr: 0000:1a:00.0
              name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
            - MAC: 64:4c:36:11:1b:a9
              NVMVersion: 7.00 0x800052b0 0.0.0
              PCIAddr: 0000:1a:00.1
              name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
            - MAC: 64:4c:36:11:1b:ac
              NVMVersion: 7.00 0x800052b0 0.0.0
              PCIAddr: 0000:1c:00.0
              name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
            - MAC: 64:4c:36:11:1b:ad
              NVMVersion: 7.00 0x800052b0 0.0.0
              PCIAddr: 0000:1c:00.1
              name: Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
          fpga:
          - PCIAddr: 0000:1b:00.0 2
            bitstreamId: "0x2315842A010601" 3
            bitstreamVersion: 0.2.3
            deviceId: "0x0b30" 4

    1
    message フィールドは、デバイスが正常にフラッシュされたことを示します。
    2
    PCIAddr フィールドは、カードの PCI アドレスを表示します。
    3
    bitstreamId フィールドは、更新されたビットストリームID を示します。
    4
    deviceID フィールドは、システムに公開されるカード内のビットストリームのデバイス ID を示します。
  3. ノード上の FEC PCI デバイスを確認します。

    1. ノードの設定が正しく適用されていることを確認します。

      $ oc debug node/node1

      予想される出力

      Starting pod/<node-name>-debug ...
      To use host binaries, run `chroot /host`
      
      Pod IP: <ip-address>
      If you don't see a command prompt, try pressing enter.
      
      sh-4.4#

    2. ノードのファイルシステムを使用できることを確認します。

      sh-4.4# chroot /host

      予想される出力

      sh-4.4#

    3. システムのアクセラレーターに関連付けられた PCI デバイスを一覧表示します。

      $ lspci | grep accelerators

      予想される出力

      1b:00.0 Processing accelerators: Intel Corporation Device 0b30
      1d:00.0 Processing accelerators: Intel Corporation Device 0d8f (rev 01)

      FPGA に属するデバイスは出力で報告されます。デバイス ID 0b30 はカードのプログラムに使用される RSU インターフェースです。0d8f は、新規プログラムの 5G デバイスの物理機能です。

16.4. ワイヤレス FEC Accelerator 向けの OpenNESS SR-IOV Operator のインストール

ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator の役割は、OpenShift Container Platform クラスター内のさまざまな Intel vRAN FEC アクセラレーションハードウェアにより公開されるデバイスをオーケストレーションし、管理することです。

最もコンピューター集約型な 4G/LTE および 5G ワークロードの 1 つは、RAN レイヤー 1 (L1) 前方誤り訂正 (FEC) になります。FEC は、信頼性が低い通信チャネルまたはノイズー通信チャネルでデータ転送エラーを解決します。FEC テクノロジーは、再送信を必要とせずに 4G/LTE または 5G データ内のエラーの一部を検出して修正します。

FEC デバイスは、vRAN ユースケースとして Intel FPGA PAC N3000 および Intel vRAN Dedicated Accelerator ACC100 により提供されます。

注記

Intel FPGA PAC N3000 FPGA には、4G/LTE または 5G ビットストリームを持つフラッシュが必要です。

ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator は、FEC デバイスの仮想機能 (VF) を作成し、それらを適切なドライバーにバインドし、4G/LTE または 5G デプロイメントの機能について VF キューを設定します。

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して、ワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator をインストールできます。

16.4.1. CLI の使用によるワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator のインストール

クラスター管理者は、CLI を使用してワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator をインストールできます。

前提条件

  • ベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) をインストールすること。
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

  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

検証

  • Operator がインストールされていることを確認します。

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

    出力例

    Name                                        Phase
    sriov-fec.v1.1.0                            Succeeded

16.4.2. Web コンソールを使用したワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator のインストール

クラスター管理者は、Web コンソールを使用してワイヤレス FEC Accelerator の OpenNESS SR-IOV Operator をインストールできます。

注記

先のセクションで説明されているように Namespace および OperatorGroup CR を作成する必要があります。

手順

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

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から ワイヤレス FEC Accelerator 向け OpenNESS SR-IOV Operator を選択し、Install をクリックします。
    3. Install Operator ページで、All namespaces on the cluster を選択します。次に、Install をクリックします。
  2. オプション: SRIOV-FEC Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. ワイヤレス FEC Accelerator 向け OpenNESS SR-IOV OperatorStatusInstallSucceededvran-acceleration-operators プロジェクトに一覧表示されていることを確認します。

      注記

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

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

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

16.4.3. Intel FPGA PAC N3000 向け SR-IOV-FEC Operator の設定

このセクションでは、Intel FPGA PAC N3000 向け SR-IOV-FEC Operator をプログラムする方法を説明します。SR-IOV-FEC Operator は、vRAN L1 アプリケーションの FEC プロセスを加速するために使用される前方誤り訂正 (FEC) デバイスの管理を処理します。

SR-IOV-FEC Operator を設定するには、以下のことを行う必要があります。

  • FEC デバイスに必要な仮想機能 (VF) の作成
  • VF を適切なドライバーにバインド
  • 4G または 5G デプロイメントで希望する機能向け VF キューの設定

前方誤り訂正 (FEC) の役割は、メッセージ内の特定のビットが失われたり、文字化けしている可能性がある転送エラーの修正です。伝送メディアのノイズ、干渉、または信号強度の低下により、メッセージが失われたり文字化けしたりする可能性があります。FEC を使用しないと、文字化けしたメッセージは、ネットワーク負荷に加え、スループットとレイテンシーに影響を与える必要があります。

前提条件

  • Intel FPGA PAC N3000 カード
  • Intel FPGA PAC N3000 (プログラミング) 向け OpenNESS Operator でインストールされる 1 つまたは複数のノード
  • ワイヤレス FEC Accelerator 向け OpenNESS Operator でインストールされる 1 つまたは複数のノード
  • Performance Addon Operator で設定された RT カーネル

手順

  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
    n3000.v1.1.0                                Succeeded

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

    $  oc get pods

    出力例

    NAME                                            READY       STATUS      RESTARTS    AGE
    fpga-driver-daemonset-8xz4c                     1/1         Running     0           15d
    fpgainfo-exporter-vhvdq                         1/1         Running     1           15d
    N3000-controller-manager-b68475c76-gcc6v        2/2         Running     1           15d
    N3000-daemonset-5k55l                           1/1         Running     1           15d
    N3000-discovery-blmjl                           1/1         Running     1           15d
    N3000-discovery-lblh7                           1/1         Running     1           15d
    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

    以下のセクションでは、インストールされた Pod に関する情報を提供します。

    • fpga-driver-daemonset は必要な Open Programmable Accelerator Engine (OPAE) ドライバーを提供し、読み込みます。
    • fpgainfo-exporter は Prometheus に N3000 Telemetry データを提供します。
    • N3000-controller-manager は N3000Node CR をクラスターに適用し、すべてのオペランドコンテナーを管理します。
    • N3000-daemonset が主要なワーカーアプリケーションです。
    • N3000-discovery は、デバイスが存在する場合にワーカーノードがインストールされ、ラベルのワーカーノードがある場合に N3000 Accelerator デバイスを検出します。
    • 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.1d.00.0 1
              vendorID: "8086"
              virtualFunctions: [] 2

    1
    このフィールドは、カードの PCI Address を示します。
    2
    このフィールドは、仮想関数が空であることを示します。
  6. 希望の設定で FEC デバイスを設定します。

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

      apiVersion: sriovfec.intel.com/v1
      kind: SriovFecClusterConfig
      metadata:
          name: config
          namespace: vran-acceleration-operators
      spec:
        nodes:
          - nodeName: node1 1
            physicalFunctions:
              - pciAddress: 0000:1d:00.0 2
                pfDriver: pci-pf-stub
                vfDriver: vfio-pci
                vfAmount: 2 3
                bbDevConfig:
                  n3000:
                    # Network Type: either "FPGA_5GNR" or "FPGA_LTE"
                    networkType: "FPGA_5GNR"
                    pfMode: false
                    flrTimeout: 610
                    downlink:
                      bandwidth: 3
                      loadBalance: 128
                      queues: 4
                        vf0: 16
                        vf1: 16
                        vf2: 0
                        vf3: 0
                        vf4: 0
                        vf5: 0
                        vf6: 0
                        vf7: 0
                    uplink:
                      bandwidth: 3
                      loadBalance: 128
                      queues: 5
                        vf0: 16
                        vf1: 16
                        vf2: 0
                        vf3: 0
                        vf4: 0
                        vf5: 0
                        vf6: 0
                        vf7: 0
      1
      ノード名を指定します。
      2
      SR-IOV-FEC Operator がインストールされているカードの PCI Address を指定します。
      3
      仮想関数の数を指定します。2 つの仮想関数を作成します。
      4
      vf0 で、16 バス (ダウンリンクおよびアップリンク) を使用してキューを 1 つ作成します。
      5
      vf1 で、16 バス (ダウンリンクおよびアップリンク) を使用してキューを 1 つ作成します。
      注記

      vRAN Acceleration 向け Intel PAC N3000 では、ユーザーが最大 8 個の VF デバイスを作成できます。各 FEC PF デバイスでは、設定可能な合計 64 個のキュー (アップリンク用に 32 個と、ダウンリンク用に 32 個) が提供されます。キューは通常、VF 全体に均等に分散されます。

    2. CR を適用します。

      $ oc apply -f sriovfec_n3000_cr.yaml

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

検証

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

    $ oc get sriovfecclusterconfig config -o yaml

    出力例

    status:
        conditions:
        - lastTransitionTime: "2020-12-15T17:19:37Z"
          message: Configured successfully
          observedGeneration: 1
          reason: ConfigurationSucceeded
          status: "True"
          type: Configured
        inventory:
          sriovAccelerators:
          - deviceID: 0d8f
            driver: pci-pf-stub
            maxVirtualFunctions: 8
            pciAddress: 0000:1d:00.0
            vendorID: "8086"
            virtualFunctions:
            - deviceID: 0d90
              driver: vfio-pci
              pciAddress: 0000:1d:00.1
            - deviceID: 0d90
              driver: vfio-pci
              pciAddress: 0000:1d:00.2

  2. ログを確認します。

    1. SR-IOV デーモン Pod の名前を確認します。

      $ oc get pod | grep sriov-fec-daemonset

      出力例

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

    2. ログを表示します。

      $ oc logs sriov-fec-daemonset-kqqs6

      出力例

      2020-12-16T12:46:47.720Z        INFO    daemon.NodeConfigurator.applyConfig     configuring PF  {"requestedConfig": {"pciAddress":"0000:1d:00.0","pfDriver":"pci-pf-stub","vfDriver":"vfio-pci","vfAmount":2,"bbDevConfig":{"n3000":{
      "networkType":"FPGA_5GNR","pfMode":false,"flrTimeout":610,"downlink":{"bandwidth":3,"loadBalance":128,"queues":{"vf0":16,"vf1":16}},"uplink":{"bandwidth":3,"loadBalance":128,"queues":{"vf0":16,"vf1":16}}}}}}
      2020-12-16T12:46:47.720Z        INFO    daemon.NodeConfigurator.loadModule      executing command       {"cmd": "/usr/sbin/chroot /host/ modprobe pci-pf-stub"}
      2020-12-16T12:46:47.724Z        INFO    daemon.NodeConfigurator.loadModule      commands output {"output": ""}
      2020-12-16T12:46:47.724Z        INFO    daemon.NodeConfigurator.loadModule      executing command       {"cmd": "/usr/sbin/chroot /host/ modprobe vfio-pci"}
      2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator.loadModule      commands output {"output": ""}
      2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.0/driver_override"}
      2020-12-16T12:46:47.727Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/pci-pf-stub/bind"}
      2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.1/driver_override"}
      2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/vfio-pci/bind"}
      2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator device's driver_override path   {"path": "/sys/bus/pci/devices/0000:1d:00.2/driver_override"}
      2020-12-16T12:46:47.998Z        INFO    daemon.NodeConfigurator driver bind path        {"path": "/sys/bus/pci/drivers/vfio-pci/bind"}
      2020-12-16T12:46:47.999Z        INFO    daemon.NodeConfigurator.applyConfig     executing command       {"cmd": "/sriov_workdir/pf_bb_config FPGA_5GNR -c /sriov_artifacts/0000:1d:00.0.ini -p 0000:1d:00.0"}
      2020-12-16T12:46:48.017Z        INFO    daemon.NodeConfigurator.applyConfig     commands output {"output": "ERROR: Section (FLR) or name (flr_time_out) is not valid.
      FEC FPGA RTL v3.0
      UL.DL Weights = 3.3
      UL.DL Load Balance = 1
      28.128
      Queue-PF/VF Mapping Table = READY
      Ring Descriptor Size = 256 bytes
      
      --------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
              |  PF | VF0 | VF1 | VF2 | VF3 | VF4 | VF5 | VF6 | VF7 |
      --------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
      UL-Q'00 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'01 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'02 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'03 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'04 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'05 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'06 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'07 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'08 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'09 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'10 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'11 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'12 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'13 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'14 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'15 |     |  X  |     |     |     |     |     |     |     |
      UL-Q'16 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'17 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'18 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'19 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'20 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'21 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'22 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'23 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'24 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'25 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'26 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'27 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'28 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'29 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'30 |     |     |  X  |     |     |     |     |     |     |
      UL-Q'31 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'32 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'33 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'34 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'35 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'36 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'37 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'38 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'39 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'40 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'41 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'42 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'43 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'44 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'45 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'46 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'47 |     |  X  |     |     |     |     |     |     |     |
      DL-Q'48 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'49 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'50 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'51 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'52 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'53 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'54 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'55 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'56 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'57 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'58 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'59 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'60 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'61 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'62 |     |     |  X  |     |     |     |     |     |     |
      DL-Q'63 |     |     |  X  |     |     |     |     |     |     |
      --------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
      
      Mode of operation = VF-mode
      FPGA_5GNR PF [0000:1d:00.0] configuration complete!"}
      2020-12-16T12:46:48.017Z        INFO    daemon.NodeConfigurator.enableMasterBus executing command       {"cmd": "/usr/sbin/chroot /host/ setpci -v -s 0000:1d:00.0 COMMAND"}
      2020-12-16T12:46:48.037Z        INFO    daemon.NodeConfigurator.enableMasterBus commands output {"output": "0000:1d:00.0 @04 = 0102\n"}
      2020-12-16T12:46:48.037Z        INFO    daemon.NodeConfigurator.enableMasterBus executing command       {"cmd": "/usr/sbin/chroot /host/ setpci -v -s 0000:1d:00.0 COMMAND=0106"}
      2020-12-16T12:46:48.054Z        INFO    daemon.NodeConfigurator.enableMasterBus commands output {"output": "0000:1d:00.0 @04 0106\n"}
      2020-12-16T12:46:48.054Z        INFO    daemon.NodeConfigurator.enableMasterBus MasterBus set   {"pci": "0000:1d:00.0", "output": "0000:1d:00.0 @04 0106\n"}
      2020-12-16T12:46:48.160Z        INFO    daemon.drainhelper.Run()        worker function - end   {"performUncordon": true}

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

    $ oc get sriovfecnodeconfig node1 -o yaml

    出力例

    status:
        conditions:
        - lastTransitionTime: "2020-12-15T17:19:37Z"
          message: Configured successfully
          observedGeneration: 1
          reason: ConfigurationSucceeded
          status: "True"
          type: Configured
        inventory:
          sriovAccelerators:
          - deviceID: 0d8f 1
            driver: pci-pf-stub
            maxVirtualFunctions: 8
            pciAddress: 0000:1d:00.0
            vendorID: "8086"
          virtualFunctions:
          - deviceID: 0d90 2
            driver: vfio-pci
            pciAddress: 0000:1d:00.1
          - deviceID: 0d90
            driver: vfio-pci
            pciAddress: 0000:1d:00.2

    1
    0d8f は、FEC デバイスの deviceID 物理機能です。
    2
    0d90 は、FEC デバイスの deviceID 仮想機能です。

16.4.4. Intel vRAN Dedicated Accelerator ACC100 向け SR-IOV-FEC Operator の設定

Intel vRAN Dedicated Accelerator ACC100 のプログラミングは、vRAN ワークロードで FEC を加速するのに使用される SR-IOV (Single Root I/O Virtualization) 仮想関数 (VF) デバイスを公開します。Intel vRAN Dedicated Accelerator ACC100 は 4G および 5G vRAN (Virtualized Radio Access Networks) ワークロードを加速します。これにより、市販の既製のプラットフォームの全体的な計算能力が向上します。このデバイスは Mount Bryce としても知られています。

SR-IOV-FEC Operator は、vRAN L1 アプリケーションの FEC プロセスを加速するために使用される前方誤り訂正 (FEC) デバイスの管理を処理します。

SR-IOV-FEC Operator を設定するには、以下のことを行う必要があります。

  • FEC デバイスの VF (Virtual Function) の作成
  • VF を適切なドライバーにバインド
  • 4G または 5G デプロイメントで希望する機能向け VF キューの設定

前方誤り訂正 (FEC) の役割は、メッセージ内の特定のビットが失われたり、文字化けしている可能性がある転送エラーの修正です。伝送メディアのノイズ、干渉、または信号強度の低下により、メッセージが失われたり文字化けしたりする可能性があります。FEC を使用しないと、文字化けしたメッセージは、ネットワーク負荷に加え、スループットとレイテンシーに影響を与える必要があります。

前提条件

  • Intel FPGA ACC100 5G/4G カード
  • ワイヤレス FEC Accelerator 向け OpenNESS Operator でインストールされる 1 つまたは複数のノード
  • ノードの BIOS でグローバル SR-IOV および VT-d 設定を有効にします。
  • Performance Addon Operator で設定された RT カーネル
  • cluster-admin 権限を持つユーザーとしてログインします。

手順

  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 仮想機能です。

16.4.5. アプリケーション Pod アクセスおよび OpenNESS での FPGA 使用量の 確認

OpenNESS は、あらゆるタイプのネットワーク上のアプリケーションおよびネットワーク機能をオンボーディングおよび管理するために使用できるエッジコンピューティングソフトウェアツールキットです。

SR-IOV バインディング、デバイスプラグイン、ワイヤレス Base Band Device (bbdev) 設定、root 以外の Pod 内での SR-IOV (FEC) VF 機能など、すべての OpenNESS 機能がすべて連携していることを確認するには、イメージをビルドし、デバイスの単純な検証アプリケーションを実行できます。

詳細は、openess.org にアクセスします。

前提条件

  • オプション: Intel FPGA PAC N3000 カード
  • n3000-operator でインストールされる 1 つまたは複数のノード
  • SR-IOV-FEC Operator でインストールされる 1 つまたは複数のノード
  • Performance Addon Operator で設定されたリアルタイムカーネルおよび Huge Page
  • cluster-admin 権限を持つユーザーとしてログインします。

手順

  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_5g: '1' 6
            #intel.com/intel_fec_acc100: '1'
            #intel.com/intel_fec_lte: '1'
          limits:
            memory: 4Gi
            cpu: "4"
            hugepages-1Gi: 4Gi
            intel.com/intel_fec_5g: '1'
            #intel.com/intel_fec_acc100: '1'
            #intel.com/intel_fec_lte: '1
    1
    手順 1 で作成した namespace を指定します。
    2
    コンパイルされた DPDK を含むテストイメージを定義します。
    3
    コンテナーが root ユーザーとして内部で実行するようにします。
    4
    hugepage サイズ hugepages-1Gi および Pod に割り当てられる hugepage の量を指定します。hugepages および分離された CPU は、Performance Addon Operator を使用して設定する必要があります。
    5
    CPU の数を指定します。
    6
    N3000 5G FEC 設定のテストは、intel.com/intel_fec_5g でサポートされています。
    注記

    ACC100 設定をテストするには、# 記号を削除して、intel.com/intel_fec_acc100 をコメント解除します。N3000 4G/LTE 設定をテストするには、# 記号を削除して intel.com/intel_fec_lte をコメント解除します。一度にアクティブにできるリソースは 1 つだけです。

  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. 環境変数の一覧を出力します。

    sh-4.4# env

    出力例

    N3000_CONTROLLER_MANAGER_METRICS_SERVICE_PORT_8443_TCP_ADDR=172.30.133.131
    SRIOV_FEC_CONTROLLER_MANAGER_METRICS_SERVICE_PORT_8443_TCP_PROTO=tcp
    DPDK_VERSION=20.11
    PCIDEVICE_INTEL_COM_INTEL_FEC_5G=0.0.0.0:1d.00.0 1
    ~/usr/bin/env
    HOSTNAME=fec-pod

    1
    これは、仮想関数の PCI アドレスです。pod-test.yaml ファイルで要求したリソースに応じて、以下の 3 つの PCI アドレスのいずれかを使用することができます。
    • PCIDEVICE_INTEL_COM_INTEL_FEC_ACC100
    • PCIDEVICE_INTEL_COM_INTEL_FEC_5G
    • PCIDEVICE_INTEL_COM_INTEL_FEC_LTE
  7. test-bbdev ディレクトリーに移動します。

    sh-4.4# cd test/test-bbdev/
    注記

    ディレクトリーは Pod にあり、ローカルコンピューター上にはない。

  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_5G}" -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
    一部のテストはスキップできますが、ベクターテストに合格していることを確認してください。

16.5. 関連情報