手順

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

手順

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

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

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

   $ oc create -f enable-rfs.yaml

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

   $ oc get mc

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

   $ oc delete mc 50-enable-rfs

手順

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

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

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

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

   注記

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

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

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

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

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

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

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

手順

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

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

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

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

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

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

      # systemctl restart libvirtd

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

手順

1. NFD Operator の namespace を作成します。

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-nfd

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

      $ oc create -f nfd-namespace.yaml

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

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

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        generateName: openshift-nfd-
        name: openshift-nfd
        namespace: openshift-nfd
      spec:
        targetNamespaces:
        - openshift-nfd

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

      $ oc create -f nfd-operatorgroup.yaml

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

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

      出力例

      4.8

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

      Subscription の例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: nfd
        namespace: openshift-nfd
      spec:
        channel: "4.8"
        installPlanApproval: Automatic
        name: nfd
        source: redhat-operators
        sourceNamespace: openshift-marketplace

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

      $ oc create -f nfd-sub.yaml

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

      $ oc project openshift-nfd

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator の一覧から Node Feature Discovery を選択してから Install をクリックします。
3. Install Operator ページで、クラスターで特定の namespace を選択し、直前のセクションで作成した namespace を選択してから Install をクリックします。

1. Operators → Installed Operators ページに移動します。

2. Status が InstallSucceeded の Node Feature Discovery が openshift-nfd プロジェクトに一覧表示され ていることを確認します。

   注記

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

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

手順

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

   apiVersion: nfd.openshift.io/v1
   kind: NodeFeatureDiscovery
   metadata:
     name: nfd-instance
     namespace: openshift-nfd
   spec:
     instance: "" # instance is empty by default
     operand:
       namespace: openshift-nfd
       image: quay.io/openshift/origin-node-feature-discovery:4.8
       imagePullPolicy: Always
     workerConfig:
       configData: |
         #core:
         #  labelWhiteList:
         #  noPublish: false
         #  sleepInterval: 60s
         #  sources: [all]
         #  klog:
         #    addDirHeader: false
         #    alsologtostderr: false
         #    logBacktraceAt:
         #    logtostderr: true
         #    skipHeaders: false
         #    stderrthreshold: 2
         #    v: 0
         #    vmodule:
         ##   NOTE: the following options are not dynamically run-time configurable
         ##         and require a nfd-worker restart to take effect after being changed
         #    logDir:
         #    logFile:
         #    logFileMaxSize: 1800
         #    skipLogHeaders: false
         #sources:
         #  cpu:
         #    cpuid:
         ##     NOTE: whitelist has priority over blacklist
         #      attributeBlacklist:
         #        - "BMI1"
         #        - "BMI2"
         #        - "CLMUL"
         #        - "CMOV"
         #        - "CX16"
         #        - "ERMS"
         #        - "F16C"
         #        - "HTT"
         #        - "LZCNT"
         #        - "MMX"
         #        - "MMXEXT"
         #        - "NX"
         #        - "POPCNT"
         #        - "RDRAND"
         #        - "RDSEED"
         #        - "RDTSCP"
         #        - "SGX"
         #        - "SSE"
         #        - "SSE2"
         #        - "SSE3"
         #        - "SSE4.1"
         #        - "SSE4.2"
         #        - "SSSE3"
         #      attributeWhitelist:
         #  kernel:
         #    kconfigFile: "/path/to/kconfig"
         #    configOpts:
         #      - "NO_HZ"
         #      - "X86"
         #      - "DMI"
         #  pci:
         #    deviceClassWhitelist:
         #      - "0200"
         #      - "03"
         #      - "12"
         #    deviceLabelFields:
         #      - "class"
         #      - "vendor"
         #      - "device"
         #      - "subsystem_vendor"
         #      - "subsystem_device"
         #  usb:
         #    deviceClassWhitelist:
         #      - "0e"
         #      - "ef"
         #      - "fe"
         #      - "ff"
         #    deviceLabelFields:
         #      - "class"
         #      - "vendor"
         #      - "device"
         #  custom:
         #    - name: "my.kernel.feature"
         #      matchOn:
         #        - loadedKMod: ["example_kmod1", "example_kmod2"]
         #    - name: "my.pci.feature"
         #      matchOn:
         #        - pciId:
         #            class: ["0200"]
         #            vendor: ["15b3"]
         #            device: ["1014", "1017"]
         #        - pciId :
         #            vendor: ["8086"]
         #            device: ["1000", "1100"]
         #    - name: "my.usb.feature"
         #      matchOn:
         #        - usbId:
         #          class: ["ff"]
         #          vendor: ["03e7"]
         #          device: ["2485"]
         #        - usbId:
         #          class: ["fe"]
         #          vendor: ["1a6e"]
         #          device: ["089a"]
         #    - name: "my.combined.feature"
         #      matchOn:
         #        - pciId:
         #            vendor: ["15b3"]
         #            device: ["1014", "1017"]
         #          loadedKMod : ["vendor_kmod1", "vendor_kmod2"]
     customConfig:
       configData: |
         #    - name: "more.kernel.features"
         #      matchOn:
         #      - loadedKMod: ["example_kmod3"]
         #    - name: "more.features.by.nodename"
         #      value: customValue
         #      matchOn:
         #      - nodename: ["special-.*-node-.*"]

2. 以下のコマンドを実行し、NodeFeatureDiscovery CR インスタンスを作成します。

   $ oc create -f NodeFeatureDiscovery.yaml

手順

1. Operators → Installed Operators ページに移動します。
2. Node Feature Discovery を見つけ、Provided APIs でボックスを表示します。
3. Create instance をクリックします。
4. NodeFeatureDiscovery CR の値を編集します。
5. Create をクリックします。

手順

1. 特定のリリースに対応する driver-toolkit のイメージ URL は、oc adm コマンドを使用してリリースイメージから取得できます。

   $ oc adm release info 4.8.0 --image-for=driver-toolkit

   出力例

   quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0fd84aee79606178b6561ac71f8540f404d518ae5deff45f6d6ac8f02636c7f4

2. このイメージは、OpenShift Container Platform のインストールに必要なプルシークレットなどの有効なプルシークレットを使用してプルできます。

1. YAML は、simple-kmod ドライバーコンテナーイメージを保存する ImageStream と、コンテナーをビルドする BuildConfig を定義します。この YAML を 0000-buildconfig.yaml.template として保存します。

   apiVersion: image.openshift.io/v1
   kind: ImageStream
   metadata:
     labels:
       app: simple-kmod-driver-container
     name: simple-kmod-driver-container
     namespace: simple-kmod-demo
   spec: {}
   ---
   apiVersion: build.openshift.io/v1
   kind: BuildConfig
   metadata:
     labels:
       app: simple-kmod-driver-build
     name: simple-kmod-driver-build
     namespace: simple-kmod-demo
   spec:
     nodeSelector:
       node-role.kubernetes.io/worker: ""
     runPolicy: "Serial"
     triggers:
       - type: "ConfigChange"
       - type: "ImageChange"
     source:
       git:
         ref: "master"
         uri: "https://github.com/openshift-psap/kvc-simple-kmod.git"
       type: Git
       dockerfile: |
         FROM DRIVER_TOOLKIT_IMAGE
   
         WORKDIR /build/
   
         RUN yum -y install git make sudo gcc \
         && yum clean all \
         && rm -rf /var/cache/dnf
   
         # Expecting kmod software version as an input to the build
         ARG KMODVER
   
         # Grab the software from upstream
         RUN git clone https://github.com/openshift-psap/simple-kmod.git
         WORKDIR simple-kmod
   
         # Prep and build the module
         RUN make buildprep KVER=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}"  kernel-core) KMODVER=${KMODVER} \
         && make all       KVER=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}"  kernel-core) KMODVER=${KMODVER} \
         && make install   KVER=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}"  kernel-core) KMODVER=${KMODVER}
   
         # Add the helper tools
         WORKDIR /root/kvc-simple-kmod
         ADD Makefile .
         ADD simple-kmod-lib.sh .
         ADD simple-kmod-wrapper.sh .
         ADD simple-kmod.conf .
         RUN mkdir -p /usr/lib/kvc/ \
         && mkdir -p /etc/kvc/ \
         && make install
   
         RUN systemctl enable kmods-via-containers@simple-kmod
     strategy:
       dockerStrategy:
         buildArgs:
           - name: KMODVER
             value: DEMO
     output:
       to:
         kind: ImageStreamTag
         name: simple-kmod-driver-container:demo

2. 以下のコマンドで、DRIVER_TOOLKIT_IMAGE の代わりに、実行中の OpenShift Container Platform バージョンのドライバーツールキットイメージを置き換えます。

   $ OCP_VERSION=$(oc get clusterversion/version -ojsonpath={.status.desired.version})

   $ DRIVER_TOOLKIT_IMAGE=$(oc adm release info $OCP_VERSION --image-for=driver-toolkit)

   $ sed "s#DRIVER_TOOLKIT_IMAGE#${DRIVER_TOOLKIT_IMAGE}#" 0000-buildconfig.yaml.template > 0000-buildconfig.yaml

   注記

   ドライバーツールキットは、OpenShift Container Platform バージョン 4.8、バージョン 4.7.11 の時点でバージョン 4.7、バージョン 4.6.30 の時点で 4.6 に導入されました。

3. 以下でイメージストリームおよびビルド設定を作成します。

   $ oc create -f 0000-buildconfig.yaml

4. ビルダー Pod が正常に完了したら、ドライバーコンテナーイメージを DaemonSet としてデプロイします。

   1. ホスト上でカーネルモジュールを読み込むには、特権付きセキュリティーコンテキストでドライバーコンテナーを実行する必要があります。以下の YAML ファイルには、ドライバーコンテナーを実行するための RBAC ルールおよび DaemonSet が含まれます。この YAML を 1000-drivercontainer.yaml として保存し ます。

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: simple-kmod-driver-container
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: simple-kmod-driver-container
      rules:
      - apiGroups:
        - security.openshift.io
        resources:
        - securitycontextconstraints
        verbs:
        - use
        resourceNames:
        - privileged
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: simple-kmod-driver-container
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: simple-kmod-driver-container
      subjects:
      - kind: ServiceAccount
        name: simple-kmod-driver-container
      userNames:
      - system:serviceaccount:simple-kmod-demo:simple-kmod-driver-container
      ---
      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: simple-kmod-driver-container
      spec:
        selector:
          matchLabels:
            app: simple-kmod-driver-container
        template:
          metadata:
            labels:
              app: simple-kmod-driver-container
          spec:
            serviceAccount: simple-kmod-driver-container
            serviceAccountName: simple-kmod-driver-container
            containers:
            - image: image-registry.openshift-image-registry.svc:5000/simple-kmod-demo/simple-kmod-driver-container:demo
              name: simple-kmod-driver-container
              imagePullPolicy: Always
              command: ["/sbin/init"]
              lifecycle:
                preStop:
                  exec:
                    command: ["/bin/sh", "-c", "systemctl stop kmods-via-containers@simple-kmod"]
              securityContext:
                privileged: true
            nodeSelector:
              node-role.kubernetes.io/worker: ""

   2. RBAC ルールおよびデーモンセットを作成します。

      $ oc create -f 1000-drivercontainer.yaml

5. Pod がワーカーノードで実行された後に、simple_kmod カーネルモジュールが lsmod のホストマシンで正常に読み込まれることを確認します。

   1. Pod が実行されていることを確認します。

      $ oc get pod -n simple-kmod-demo

      出力例

      NAME                                 READY   STATUS      RESTARTS   AGE
      simple-kmod-driver-build-1-build     0/1     Completed   0          6m
      simple-kmod-driver-container-b22fd   1/1     Running     0          40s
      simple-kmod-driver-container-jz9vn   1/1     Running     0          40s
      simple-kmod-driver-container-p45cc   1/1     Running     0          40s

   2. ドライバーコンテナー Pod で lsmod コマンドを実行します。

      $ oc exec -it pod/simple-kmod-driver-container-p45cc -- lsmod | grep simple

      出力例

      simple_procfs_kmod     16384  0
      simple_kmod            16384  0

1. ノードは 2 つの論理制御ユニット (LCU) 間で分散され、コントロールプレーン/etcd ノードのディスク I/O 負荷を最適化します。etcd の I/O 需要が他のワークロードに干渉してはなりません。
2. 100/250/500 Pod で同時に複数の反復を実行するテストには、4 つの計算ノードが使用されます。まず、Pod をインスタンス化できるかどうかを評価するために、アイドリング Pod が使用されました。次に、ネットワークと CPU を必要とするクライアント/サーバーのワークロードを使用して、ストレス下でのシステムの安定性を評価しました。クライアント Pod とサーバー Pod はペアで展開され、各ペアは 2 つのコンピューティングノードに分散されました。
3. 個別のワークロードノードは使用されませんでした。ワークロードは、2 つの計算ノード間のマイクロサービスワークロードをシミュレートします。
4. 使用されるプロセッサーの物理的な数は、6 つの Integrated Facilities for Linux (IFL) です。
5. 使用される物理メモリーの合計は 512 GiB です。

手順

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

手順

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

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

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

   1 1 1

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

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

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

   注記

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

手順

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

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

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

手順

1. プロビジョナーノードから削除するコンピューティングマシンセットに、baremetalhost.metal3.io/detached アノテーションを追加してアノテーションを付けます。

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

   新しいマシンが起動するまで待ちます。

   注記

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

2. プロビジョニングのユースケースでは、次のコマンドを使用して、再起動が完了した後にアノテーションを削除します。

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

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

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

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

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

   1

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

   2

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

   3

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

   4

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

3. チューニングされた hugepages オブジェクトの作成

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

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

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

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

   $ oc create -f hugepages-mcp.yaml

手順

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

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-performance-addon-operator
        annotations:
          workload.openshift.io/allowed: management

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

      $ oc create -f pao-namespace.yaml

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

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

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

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

      $ oc create -f pao-operatorgroup.yaml

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

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

      出力例

      4.8

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

      Subscription の例

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

      1

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

      2

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

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

      $ oc create -f pao-sub.yaml

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

      $ oc project openshift-performance-addon-operator

手順

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

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

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

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

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

      注記

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

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

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

手順

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

   $ oc get csv

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

   VERSION    REPLACES                                         PHASE
   4.8.0      performance-addon-operator.v4.8.0                Installing
   4.7.0                                                       Replacing

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

   # oc get csv

   出力例

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

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

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

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

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

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

   注記

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

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

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

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

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

   $ oc describe mcp/worker-rt

   出力例

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

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

手順

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

1. Pod を作成します。

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

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

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

   出力例

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

   注記

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

1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
2. パフォーマンスプロファイルの apiVersion を performance.openshift.io/v2 を使用するように設定します。
3. globallyDisableIrqLoadBalancing フィールドを削除するか、またはこれを false に設定します。

4. 適切な分離された CPU と予約された CPU を設定します。以下のスニペットは、2 つの CPU を確保するプロファイルを示しています。IRQ 負荷分散は、isolated CPU セットで実行されている Pod について有効にされます。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: dynamic-irq-profile
   spec:
     cpu:
       isolated: 2-5
       reserved: 0-1
   ...

   注記

   予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。

5. 排他的な CPU を使用する Pod を作成し、irq-load-balancing.crio.io および cpu-quota.crio.io アノテーションを disable に設定します。以下に例を示します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: dynamic-irq-pod
     annotations:
        irq-load-balancing.crio.io: "disable"
        cpu-quota.crio.io: "disable"
   spec:
     containers:
     - name: dynamic-irq-pod
       image: "quay.io/openshift-kni/cnf-tests:4.8"
       command: ["sleep", "10h"]
       resources:
         requests:
           cpu: 2
           memory: "200M"
         limits:
           cpu: 2
           memory: "200M"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     runtimeClassName: performance-dynamic-irq-profile
   ...

6. performance-<profile_name> の形式で Pod runtimeClassName を入力します。ここで、<profile_name> は PerformanceProfile YAML の name です (例: performance-dynamic-irq-profile)。
7. ノードセレクターを cnf-worker をターゲットに設定するように設定します。

8. Pod が正常に実行されていることを確認します。ステータスが running であり、正しい cnf-worker ノードが設定されている必要があります。

   $ oc get pod -o wide

   予想される出力

   NAME              READY   STATUS    RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
   dynamic-irq-pod   1/1     Running   0          5h33m   <ip-address>   <node-name>   <none>           <none>

9. IRQ の動的負荷分散向けに設定された Pod が実行される CPU を取得します。

   $ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

   予想される出力

   Cpus_allowed_list:  2-3

10. ノードの設定が正しく適用されていることを確認します。そのノードに対して SSH を実行し、設定を確認します。

    $ oc debug node/<node-name>

    予想される出力

    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#

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

    sh-4.4# chroot /host

    予想される出力

    sh-4.4#

12. デフォルトのシステム CPU アフィニティーマスクに dynamic-irq-pod CPU(例: CPU 2 および 3) が含まれないようにします。

    $ cat /proc/irq/default_smp_affinity

    出力例

    33

13. システム IRQ が dynamic-irq-pod CPU で実行されるように設定されていないことを確認します。

    find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    出力例

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

手順

1. 設定する必要のあるホストのどの CPU でどのスレッドが実行されているかを確認します。

   クラスターにログインして以下のコマンドを実行し、ホスト CPU で実行されているスレッドを表示できます。

   $ lscpu --all --extended

   出力例

   CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
   0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
   4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

   この例では、4 つの物理 CPU コアで 8 つの論理 CPU コアが実行されています。CPU0 および CPU4 は物理コアの Core0 で実行されており、CPU1 および CPU5 は物理コア 1 で実行されています。

   または、特定の物理 CPU コア (以下の例では cpu0) に設定されているスレッドを表示するには、コマンドプロンプトを開いて以下のコマンドを実行します。

   $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

   出力例

   0-4

2. PerformanceProfile YAML で分離された CPU および予約された CPU を適用します。たとえば、論理コア CPU0 と CPU4 をisolated として設定し、論理コア CPU1 から CPU3 および CPU5 から CPU7 をreserved として設定できます。予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。

   ...
     cpu:
       isolated: 0,4
       reserved: 1-3,5-7
   ...

   注記

   予約済みの CPU プールと分離された CPU プールは重複してはならず、これらは共に、ワーカーノードの利用可能なすべてのコアに広がる必要があります。

手順

1. 環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。

2. infra およびアプリケーションコンテナー用に予約して分離する CPU で、 reserved および isolated パラメーターを追加します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: infra-cpus
   spec:
     cpu:
       reserved: "0-4,9" 1
       isolated: "5-8" 2
     nodeSelector: 3
       node-role.kubernetes.io/worker: ""

   1

   クラスターおよびオペレーティングシステムのハウスキーピングタスクを実行する infra コンテナーの CPU を指定します。

   2

   アプリケーションコンテナーがワークロードを実行する CPU を指定します。

   3

   オプション: ノードセレクターを指定してパフォーマンスプロファイルを特定のノードに適用します。

手順

1. cluster-admin 権限を持つユーザーとして、Performance Addon Operator を実行する OpenShift Container Platform クラスターにログインします。
2. お使いのハードウェアとトポロジーに適したパフォーマンスプロファイルを作成して適用します。プロファイルの作成に関するガイダンスは、パフォーマンスプロファイルの作成のセクションを参照してください。

3. この作成したパフォーマンスプロファイルを編集します。

   $ oc edit -f <your_profile_name>.yaml

4. spec フィールドに net オブジェクトを設定します。オブジェクトリストには、以下の 2 つのフィールドを含めることができます。

   • userLevelNetworking は、ブール値フラグとして指定される必須フィールドです。userLevelNetworking が true の場合、サポートされているすべてのデバイスのキュー数は、予約された CPU 数に設定されます。デフォルトは false です。

   • devices は、キューを予約 CPU 数に設定するデバイスの一覧を指定する任意のフィールドです。デバイス一覧に何も指定しないと、設定がすべてのネットワークデバイスに適用されます。設定は以下のとおりです。

     • InterfaceName: このフィールドはインターフェイス名を指定し、正または負のシェルスタイルのワイルドカードをサポートします。

       • ワイルドカード構文の例: <string> .*
       • 負のルールには、感嘆符のプリフィックスが付きます。除外リスト以外のすべてのデバイスにネットキューの変更を適用するには、!<device> を使用します (例: !eno1)。
     • vendorID: 16 ビット (16 進数) として表されるネットワークデバイスベンダー ID。接頭辞は 0x です。

     • 9deviceID: 16 ビット (16 進数) として表されるネットワークデバイス ID (モデル)。接頭辞は 0x です。

       注記

       deviceID が指定されている場合は、vendorID も定義する必要があります。デバイスエントリー interfaceName、vendorID、または vendorID と deviceID のペアで指定されているすべてのデバイス識別子に一致するデバイスは、ネットワークデバイスとしての資格があります。その後、このネットワークデバイスは net キュー数が予約 CPU 数に設定されます。

       2 つ以上のデバイスを指定すると、net キュー数は、それらのいずれかに一致する net デバイスに設定されます。

5. このパフォーマンスプロファイルの例を使用して、キュー数をすべてのデバイスの予約 CPU 数に設定します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,54-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

6. このパフォーマンスプロファイルの例を使用して、定義されたデバイス識別子に一致するすべてのデバイスの予約 CPU 数にキュー数を設定します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,54-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: “eth0”
       - interfaceName: “eth1”
       - vendorID: “0x1af4”
       - deviceID: “0x1000”
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

7. このパフォーマンスプロファイルの例を使用して、インターフェイス名 eth で始まるすべてのデバイスの予約 CPU 数にキュー数を設定します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,54-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: “eth*”
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

8. このパフォーマンスプロファイルの例を使用して、eno1 以外の名前のインターフェイスを持つすべてのデバイスの予約 CPU 数にキュー数を設定します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,54-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: “!eno1”
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

9. このパフォーマンスプロファイルの例を使用して、インターフェイス名 eth0、0x1af4 の vendorID、および 0x1000 の deviceID を持つすべてのデバイスの予約 CPU 数にキュー数を設定します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,54-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: “eth0”
       - vendorID: “0x1af4”
       - deviceID: “0x1000”
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

10. 更新されたパフォーマンスプロファイルを適用します。

    $ oc apply -f <your_profile_name>.yaml

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

   # oc get mcp

   出力例

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

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

   # oc describe mcp worker-cnf

   出力例

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

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

   # oc describe performanceprofiles performance

   出力例

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

手順

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

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

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

   1

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

   2

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

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

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

   1

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

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

手順

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

2. クラスターで must-gather を実行します。

   $ oc adm must-gather --image=<PAO_image> --dest-dir=<dir>

   注記

   must-gather コマンドは、performance-addon-operator-must-gather イメージを使用して実行する必要があります。この出力はオプションで圧縮できます。Performance Profile Creator ラッパースクリプトを実行している場合は、出力を圧縮する必要があります。

   例

   $ oc adm must-gather --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.8 --dest-dir=must-gather

3. must-gather ディレクトリーから圧縮ファイルを作成します。

   $ tar cvaf must-gather.tar.gz must-gather/

手順

1. マシン設定プールを確認します。

   $ oc get mcp

   出力例

   NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
   worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

2. Podman を使用して、registry.redhat.io への認証を行います。

   $ podman login registry.redhat.io

   Username: myrhusername
   Password: ************

3. 必要に応じて、PPC ツールのヘルプを表示します。

   $ podman run --entrypoint performance-profile-creator registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.8 -h

   出力例

   A tool that automates creation of Performance Profiles
   
   Usage:
     performance-profile-creator [flags]
   
   Flags:
         --disable-ht                        Disable Hyperthreading
     -h, --help                              help for performance-profile-creator
         --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
         --mcp-name string                   MCP name corresponding to the target machines (required)
         --must-gather-dir-path string       Must gather directory path (default "must-gather")
         --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
         --profile-name string               Name of the performance profile to be created (default "performance")
         --reserved-cpu-count int            Number of reserved CPUs (required)
         --rt-kernel                         Enable Real Time Kernel (required)
         --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
         --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
         --user-level-networking             Run with User level Networking(DPDK) enabled

4. Performance Profile Creator ツールを検出モードで実行します。

   注記

   検出モードは、must-gather からの出力を使用してクラスターを検査します。生成された出力には、以下のような情報が含まれます。

   • 割り当てられた CPU ID でパーティションされた NUMA セル
   • ハイパースレッディングが有効にされているかどうか

   この情報を使用して、Performance Profile Creator ツールにわたす一部の引数に適切な値を設定できます。

   $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.8 --info log --must-gather-dir-path /must-gather

   注記

   このコマンドは、Performance Profile Creator を、podman への新規エントリーポイントとして使用します。これは、ホストの must-gather データをコンテナーイメージにマッピングし、ユーザーが提示した必須のプロファイル引数を呼び出し、my-performance-profile.yaml ファイルを生成します。

   -v オプションでは、以下のいずれかへのパスを指定できます。

   • must-gather 出力ディレクトリー
   • must-gather の展開済みの tarball を含む既存のディレクトリー

   info オプションでは、出力形式を指定する値が必要です。使用できる値は log と JSON です。JSON 形式はデバッグ用に確保されています。

5. podman を実行します。

   $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.8 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node --must-gather-dir-path /must-gather  --power-consumption-mode=ultra-low-latency > my-performance-profile.yaml

   注記

   Performance Profile Creator の引数については Performance Profile Creator 引数の表に示しています。必要な引数は、以下の通りです。

   • reserved-cpu-count
   • mcp-name
   • rt-kernel

   この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。Single Node OpenShift (SNO) には --mcp-name=master を使用します。

6. 作成した YAML ファイルを確認します。

   $ cat my-performance-profile.yaml

   出力例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: performance
   spec:
     additionalKernelArgs:
     - nmi_watchdog=0
     - audit=0
     - mce=off
     - processor.max_cstate=1
     - intel_idle.max_cstate=0
     - idle=poll
     cpu:
       isolated: 1,3,5,7,9,11,13,15,17,19-39,41,43,45,47,49,51,53,55,57,59-79
       reserved: 0,2,4,6,8,10,12,14,16,18,40,42,44,46,48,50,52,54,56,58
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     numa:
       topologyPolicy: single-numa-node
     realTimeKernel:
       enabled: true

7. 生成されたプロファイルを適用します。

   注記

   プロファイルを適用する前に、Performance Addon Operator をインストールしてください。

   $ oc apply -f my-performance-profile.yaml

手順

1. ローカルマシンにファイル (例: run-perf-profile-creator.sh) を作成します。

   $ vi run-perf-profile-creator.sh

2. ファイルに以下のコードを貼り付けます。

   #!/bin/bash
   
   readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
   readonly CURRENT_SCRIPT=$(basename "$0")
   readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
   readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
   readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
   readonly MUST_GATHER_VOL="/must-gather"
   
   PAO_IMG="registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.8"
   MG_TARBALL=""
   DATA_DIR=""
   
   usage() {
     print "Wrapper usage:"
     print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
     print ""
     print "Options:"
     print "   -h                 help for ${CURRENT_SCRIPT}"
     print "   -p                 Performance Addon Operator image"
     print "   -t                 path to a must-gather tarball"
   
     ${IMG_EXISTS_CMD} "${PAO_IMG}" && ${CMD} "${PAO_IMG}" -h
   }
   
   function cleanup {
     [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
   }
   trap cleanup EXIT
   
   exit_error() {
     print "error: $*"
     usage
     exit 1
   }
   
   print() {
     echo  "$*" >&2
   }
   
   check_requirements() {
     ${IMG_EXISTS_CMD} "${PAO_IMG}" || ${IMG_PULL_CMD} "${PAO_IMG}" || \
         exit_error "Performance Addon Operator image not found"
   
     [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
     [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"
   
     DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
     tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
     chmod a+rx "${DATA_DIR}"
   
     return 0
   }
   
   main() {
     while getopts ':hp:t:' OPT; do
       case "${OPT}" in
         h)
           usage
           exit 0
           ;;
         p)
           PAO_IMG="${OPTARG}"
           ;;
         t)
           MG_TARBALL="${OPTARG}"
           ;;
         ?)
           exit_error "invalid argument: ${OPTARG}"
           ;;
       esac
     done
     shift $((OPTIND - 1))
   
     check_requirements || exit 1
   
     ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${PAO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
     echo "" 1>&2
   }
   
   main "$@"

3. このスクリプトの実行権限を全員に追加します。

   $ chmod a+x run-perf-profile-creator.sh

4. オプション: run-perf-profile-creator.sh コマンドの使用方法を表示します。

   $ ./run-perf-profile-creator.sh -h

   予想される出力

   Wrapper usage:
     run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]
   
   Options:
      -h                 help for run-perf-profile-creator.sh
      -p                 Performance Addon Operator image 1
      -t                 path to a must-gather tarball 2
   
   A tool that automates creation of Performance Profiles
   
      Usage:
        performance-profile-creator [flags]
   
      Flags:
            --disable-ht                        Disable Hyperthreading
        -h, --help                              help for performance-profile-creator
            --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
            --mcp-name string                   MCP name corresponding to the target machines (required)
            --must-gather-dir-path string       Must gather directory path (default "must-gather")
            --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
            --profile-name string               Name of the performance profile to be created (default "performance")
            --reserved-cpu-count int            Number of reserved CPUs (required)
            --rt-kernel                         Enable Real Time Kernel (required)
            --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
            --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
            --user-level-networking             Run with User level Networking(DPDK) enabled

   注記

   引数には、以下の 2 つのタイプがあります。

   • ラッパー引数名は、-h、-p、および -t です。
   • PPC 引数

   1

   オプション: Performance Addon Operator イメージを指定します。設定されていない場合、デフォルトのアップストリームイメージ registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.8 が使用されます。

   2

   -t は、必須のラッパースクリプトの引数で、must-gather tarball へのパスを指定します。

5. Performance Profile Creator ツールを検出モードで実行します。

   注記

   検出モードは、must-gather からの出力を使用してクラスターを検査します。生成された出力には、以下のような情報が含まれます。

   • 割り当てられた CPU ID を使用した NUMA セルのパーティション設定
   • ハイパースレッディングが有効にされているかどうか

   この情報を使用して、Performance Profile Creator ツールにわたす一部の引数に適切な値を設定できます。

   $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=log

   注記

   info オプションでは、出力形式を指定する値が必要です。使用できる値は log と JSON です。JSON 形式はデバッグ用に確保されています。

6. マシン設定プールを確認します。

   $ oc get mcp

   出力例

   NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
   worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

7. パフォーマンスプロファイルを作成します。

   $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yaml

   注記

   Performance Profile Creator の引数については Performance Profile Creator 引数の表に示しています。必要な引数は、以下の通りです。

   • reserved-cpu-count
   • mcp-name
   • rt-kernel

   この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。Single Node OpenShift (SNO) には --mcp-name=master を使用します。

8. 作成した YAML ファイルを確認します。

   $ cat my-performance-profile.yaml

   出力例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: performance
   spec:
     cpu:
       isolated: 1-39,41-79
       reserved: 0,40
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: false

9. 生成されたプロファイルを適用します。

   注記

   プロファイルを適用する前に、Performance Addon Operator をインストールしてください。

   $ oc apply -f my-performance-profile.yaml