インスタンス作成のための Compute サービスの設定

手順

1. インスタンスが利用可能な基本的なリソースを指定するフレーバーを作成します。

   $ openstack --os-compute-api=2.86 flavor create --ram <size_mb> \
    --disk <size_gb> --vcpus <no_vcpus> \
    [--private --project <project_id>] <flavor_name>

   • <size_mb> を、このフレーバーで作成するインスタンスに割り当てる RAM の容量に置き換えます。
   • <size_gb> を、このフレーバーで作成するインスタンスに割り当てるルートディスクのサイズに置き換えます。
   • <no_vcpus> を、このフレーバーで作成するインスタンスに確保する仮想 CPU の数に置き換えます。

   • (オプション) --private および --project オプションを指定して、特定のプロジェクトまたはユーザーグループだけがフレーバーにアクセスできるようにします。<project_id> を、このフレーバーを使用してインスタンスを作成できるプロジェクトの ID に置き換えます。アクセシビリティーを指定しない場合は、フレーバーはデフォルトで public に設定されます。つまり、すべてのプロジェクトで使用可能になります。

     注記

     パブリックフレーバーの作成後は、そのフレーバーをプライベートにすることはできません。

   • <flavor_name> を、一意のフレーバー名に置き換えます。

     フレーバーの引数の詳細は、Flavor arguments を参照してください。

2. (オプション) フレーバーのメタデータを指定するには、キー/値のペアを使用して必要な属性を設定します。

   $ openstack --os-compute-api=2.86 flavor set \
    --property <key=value> --property <key=value> ... <flavor_name>

   • <key> を、このフレーバーで作成するインスタンスに割り当てる属性のメタデータキーに置き換えます。利用可能なメタデータキーのリストは、Flavor metadata を参照してください。
   • <value> を、このフレーバーで作成するインスタンスに割り当てるメタデータキーの値に置き換えます。

   • <flavor_name> を、フレーバーの名前に置き換えます。

     たとえば、以下のフレーバーを使用して起動されるインスタンスはに 2 つの CPU ソケットがあり、それぞれに 2 つの CPU が割り当てられます。

     $ openstack --os-compute-api=2.86 flavor set \
      --property hw:cpu_sockets=2 \
      --property hw:cpu_cores=2 processor_topology_flavor

1. CPU ピニング用のコンピュートノードを指定する。
2. ピニングされたインスタンス仮想 CPU プロセス、フローティングのインスタンス仮想 CPU プロセス、およびホストのプロセス用にホストコアを確保するようにコンピュートノードを設定する。
3. データプレーンをデプロイします。
4. CPU ピニングを要求するインスタンスを起動するためのフレーバーを作成する。
5. 共有 (あるいはフローティング) の CPU を使用するインスタンスを起動するためのフレーバーを作成する。

手順

1. エミュレータースレッド用にノードを設定するために、nova-extra-config.yaml という名前の ConfigMap CR を作成または更新し、[compute] の下の cpu_dedicated_set パラメーターの値を設定します。たとえば、以下の設定では、32 コア CPU を持つコンピュートノードに専用の CPU を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      33-nova-emulator-threads.conf: |
        [compute]
        cpu_dedicated_set = 2-15,18-31

2. エミュレータースレッド用に物理 CPU コアを予約するために、cpu_shared_set パラメーターを設定します。たとえば、以下の設定では、32 コア CPU を持つコンピュートノードに共有の CPU を設定します。

       [compute]
       cpu_shared_set = 0,1,16,17

   注記

   Compute スケジューラーは、共有 (またはフローティング) CPU 上で動作するインスタンス用にも共有セット内の CPU を使用します。詳細は、コンピュートノードでの CPU ピニングの設定 を参照してください。

3. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイし、ワークステーション上の compute_emulator_threads_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: openstack-emulator-threads

4. compute_emulator_threads_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、エミュレータースレッドに指定するノードを定義します。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova サービスを指す OpenStackDataPlaneService CR の名前を見つけます。

   2. OpenStackDataPlaneService CR の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      OpenStackDataPlaneService CR の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい OpenStackDataPlaneService CR を作成する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: openstack-emulator-threads
   spec:
     nodeSets:
       - openstack-edpm
       - compute-emulator-threads
       - my-data-plane-node-set
       - ...
       - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
5. compute_emulator_threads_deploy.yaml デプロイメントファイルを保存します。

6. データプレーンをデプロイします。

   $ oc create -f compute_emulator_threads_deploy.yaml

7. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   NAME STATUS MESSAGE
   compute-emulator-threads True Deployed

8. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   $ openstack hypervisor list

9. cpu_shared_set を使用して設定した共有 CPU から選択した専用の CPU 上でインスタンスのエミュレータースレッドを実行するフレーバーを設定します。

   $ openstack --os-compute-api=2.86 flavor set --property hw:cpu_policy=dedicated \
   --property hw:emulator_threads_policy=share \
   dedicated_emulator_threads

   hw:emulator_threads_policy の設定オプションの詳細は、Flavor metadata の Emulator threads policy を参照してください。

手順

1. 更新するノードセットの OpenStackDataPlaneNodeSet CR 定義ファイル (例: my_data_plane_node_set.yaml) を開きます。

2. 必要な設定を追加するか、ansibleVars の下の既存設定を変更します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: my-data-plane-node-set
   spec:
     ...
     nodeTemplate:
       ...
       ansible:
         ansibleVars:
            edpm_bootstrap_swap_size_megabytes: 1024
            edpm_bootstrap_swap_path: /swap
            edpm_bootstrap_swap_partition_enabled: false
            edpm_bootstrap_swap_partition_label: swap1
            ...

3. OpenStackDataPlaneNodeSet CR 定義ファイルを保存します。

4. 更新済みの OpenStackDataPlaneNodeSet CR 設定を適用します。

   $ oc apply -f my_data_plane_node_set.yaml -n openstack

5. データプレーンリソースが更新されたことを確認します。

   $ oc get openstackdataplanenodeset

   出力サンプル

   NAME                     STATUS MESSAGE
   my-data-plane-node-set   False  Deployment not started

6. ワークステーションに OpenStackDataPlaneDeployment CR を定義するファイル (例: my_data_plane_deploy.yaml) を作成します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: my-data-plane-deploy

   ヒント

   定義ファイルと OpenStackDataPlaneDeployment CR に、変更されたノードセットの目的を示す一意の説明的な名前を付けます。

7. 変更した OpenStackDataPlaneNodeSet CR を追加します。

   spec:
     nodeSets:
       - my-data-plane-node-set

8. OpenStackDataPlaneDeployment CR デプロイメントファイルを保存します。

9. 変更した OpenStackDataPlaneNodeSet CR をデプロイします。

   $ oc create -f my_data_plane_deploy.yaml -n openstack

10. デプロイメントの実行中に Ansible ログを表示できます。

    $ oc get pod -l app=openstackansibleee -n openstack -w
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10

11. 変更された OpenStackDataPlaneNodeSet CR がデプロイされていることを確認します。

    以下に例を示します。

    $ oc get openstackdataplanedeployment -n openstack

    出力サンプル

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete

12. NodeSet Ready メッセージが表示されるまで、oc get コマンドを繰り返します。

    以下に例を示します。

    $ oc get openstackdataplanenodeset -n openstack

    出力サンプル

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready

    返されるステータスの意味については、Red Hat OpenStack Services on OpenShift のデプロイ の データプレーンの状態 を参照してください。

手順

1. nova-extra-config.yaml という名前の ConfigMap CR を作成または更新し、[default] および [libvirt] の下にあるパラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      28-nova-huge-pages.conf: | 

   1

   
         [default]
         reserved_huge_pages = node:0,size:2048,count:64
         reserved_huge_pages = node:1,size:1GB,count:1
         [libvirt]
         cpu_mode = custom
         cpu_models = Haswell-noTSX
         cpu_model_extra_flags = vmx, pdpe1gb, +pcid

   1

   新しいコンピュート設定ファイルの名前。nova-operator は、01-nova.conf という名前のデフォルト設定ファイルを生成します。デフォルト名は、transport_url などのインフラストラクチャー設定をオーバーライドするため、使用しないでください。nova-compute サービスは、/etc/nova/nova.conf.d/ の下にあるファイルをすべて辞書順に適用します。そのため、後のファイルで定義された設定は、前のファイルで定義された同じ設定をオーバーライドします。

   注記
   • インスタンスによる huge page の要求を 2 MB に制限するための CPU 機能フラグを設定しないでください。
   • ホストが 1 GB huge page の割り当てをサポートする場合に限り、インスタンスに 1 GB の huge page を割り当てることができます。
   • cpu_mode が host-model または custom に設定されている場合に限り、cpu_model_extra_flags を pdpe1gb に設定する必要があります。

   • ホストが pdpe1gb をサポートし、cpu_mode に host-passthrough が使用される場合、cpu_model_extra_flags に pdpe1gb を設定する必要はありません。

     注記

     pdpe1gb フラグは Opteron_G4 および Opteron_G5 CPU モデルにのみ含まれ、QEMU がサポートする Intel CPU モデルには含まれません。Microarchitectural Data Sampling (MDS) などの CPU ハードウェア問題を軽減するには、他の CPU フラグを設定する必要がある場合があります。詳細は、「RHOS による MDS ("Microarchitectural Data Sampling") セキュリティーの不具合の軽減」を参照してください。

   ConfigMap オブジェクトの作成の詳細は、config map の作成と使用 を参照してください。

2. 新しい OpenStackDataPlaneDeployment CR を作成し、データプレーンノード上のサービスを設定してデータプレーンをデプロイし、ワークステーション上の compute_huge_pages_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: openstack-edpm-huge-pages

3. compute_huge_pages_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、huge page に指定するノードを定義します。

   警告

   ノードセット全体のみ設定できます。ノードセット内のノードのサブセットを再設定することはサポートされていません。ノードセット内のノードのサブセットを再設定する必要がある場合は、ノードセットをスケールダウンし、以前に削除したノードから新しいノードセットを作成する必要があります。

   警告

   デプロイメントに複数のノードセットがある場合、nova-extra-config.yaml ConfigMap への変更は複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config.yaml ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストに移動し、nova を指す DataPlaneService` の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: openstack-edpm-huge-pages
   spec:
      nodeSets:
       - openstack-edpm
       - compute-huge-pages
       - ...
       - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
4. compute_huge_pages_deploy.yaml デプロイメントファイルを保存します。

5. データプレーンをデプロイします。

   $ oc create -f compute_huge_pages_deploy.yaml

6. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME           STATUS MESSAGE
   compute-huge-pages True   Deployed

7. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

手順

1. nova-extra-config.yaml という名前の ConfigMap CR を作成または更新し、[libvirt] の下にあるパラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      30-nova-file-backed-memory.conf: |
         [libvirt]
         file_backed_memory = 1048576

   ConfigMap オブジェクトの作成の詳細は、config map の作成と使用 を参照してください。

2. オプション: メモリーバッキングファイルを保存するディレクトリーを設定するには、memory_backing_dir パラメーターを設定します。デフォルトのメモリーバックアップディレクトリーは /var/lib/libvirt/qemu/ram/ です。

   [libvirt]
   file_backed_memory = 1048576
   memory_backing_dir = <new_directory_location>

   • <new_directory_location> を、メモリーバッキングディレクトリーの場所に置き換えます。

     注記

     デフォルトのディレクトリー (/var/lib/libvirt/qemu/ram/) またはそれより上の階層のディレクトリーに、バッキングストアを配置する必要があります。バッキングストアのホストディスクを変更することもできます。詳細は、メモリーバッキングディレクトリーのホストディスクの変更 を参照してください。

3. 新しい OpenStackDataPlaneDeployment CR を作成し、データプレーンノード上のサービスを設定してデータプレーンをデプロイし、ワークステーション上の compute_file_backed_memory_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-file-backed-memory

4. compute_file_backed_memory_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、ファイルバックアップメモリーに指定するノードを定義します。

   警告

   ノードセット全体のみ設定できます。ノードセット内のノードのサブセットを再設定することはサポートされていません。ノードセット内のノードのサブセットを再設定する必要がある場合は、ノードセットをスケールダウンし、以前に削除したノードから新しいノードセットを作成する必要があります。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-file-backed-memory
   spec:
      nodeSets:
        - openstack-edpm
        - compute-file-backed-memory
        - ...
        - <nodeSet_name>

   • <nodeSet_name> を、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
5. compute_file_backed_memory_deploy.yaml デプロイメントファイルを保存します。

6. データプレーンをデプロイします。

   $ oc create -f compute_file_backed_memory_deploy.yaml

7. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME                       STATUS MESSAGE
   compute-file-backed-memory True   Deployed

8. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

1. メモリーの暗号化用に AMD SEV コンピュートノードを指定する。
2. メモリーの暗号化用にコンピュートノードを設定する。
3. データプレーンをデプロイします。
4. メモリーを暗号化してインスタンスを起動するためのフレーバーまたはイメージを作成する。

手順

1. nova-extra-config という名前の ConfigMap CR を作成または更新し、[compute] の下にあるパラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      31-nova-max-storage-devices.conf: |
         [compute]
         max_disk_devices_to_attach = <max_device_limit>

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

2. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイします。CR を、ワークステーション上の compute_storage_devices_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-storage-devices

   OpenStackDataPlaneDeployment CR の作成の詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの データプレーンのデプロイ を参照してください。

3. compute_storage_devices_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、1 つのインスタンスにアタッチするストレージデバイスの最大数を設定するノードを定義します。

   警告

   ノードセット内のノードのサブセットは再設定できません。そうする必要がある場合は、ノードセットをスケールダウンし、以前に削除したノードから新しいノードセットを作成する必要があります。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成し、必要なノードセットでそのカスタムサービスを使用する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-storage-devices
   spec:
      nodeSets:
        - openstack-edpm
        - compute-storage-devices
        - ...
        - <nodeSet_name>

   • <nodeSet_name> を、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
4. compute_storage_devices_deploy.yaml デプロイメントファイルを保存します。

5. データプレーンをデプロイします。

   $ oc create -f compute_storage_devices_deploy.yaml

6. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME                STATUS MESSAGE
   compute-storage-devices True   Deployed

7. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

手順

1. 更新するノードセットの OpenStackDataPlaneNodeSet CR 定義ファイル (例: my_data_plane_node_set.yaml) を開きます。

2. 必要な設定を追加するか、ansibleVars の下の既存設定を変更します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
   name: my-data-plane-node-set
   spec:
   ...
     nodeTemplate:
       ansible:
         ansibleVars:
           edpm_bootstrap_command: |
             dnf -y install conntrack-tools
           edpm_extra_mounts:
           - fstype: nfs4
             opts: context=system_u:obje/var/lib/nova/instances
             path: /var/lib/nova/instances
             src: <nfs_path>

   • <nfs_path> は NFS へのパスに置き換えます。たとえば、192.168.122.1:/home/nfs/nova です。

3. オプション: NFS バックエンドストレージが有効な場合、NFS ストレージ用のデフォルトのマウント SELinux コンテキストは context=system_u:object_r:nfs_t:s0 です。以下のパラメーターを追加して、NFS インスタンスファイルストレージのマウントポイントのマウントオプションを変更します。

   [compute]
   nfs_mount_options = 'context=system_u:object_r:nfs_t:s0,<additional_nfs_mount_options>'

   • <additional_nfs_mount_options> を、NFS インスタンスファイルストレージに使用するマウントオプションのコンマ区切りリストに置き換えます。利用可能なマウントオプションの詳細は、mount の man ページを参照してください。

     $ man 8 mount

4. OpenStackDataPlaneNodeSet CR 定義ファイルを保存します。

5. 更新済みの OpenStackDataPlaneNodeSet CR 設定を適用します。

   $ oc apply -f my_data_plane_node_set.yaml -n openstack

6. データプレーンリソースが更新されたことを確認します。

   $ oc get openstackdataplanenodeset

   出力サンプル

   NAME STATUS MESSAGE
   my-data-plane-node-set False Deployment not started

7. ワークステーションに OpenStackDataPlaneDeployment CR を定義するファイル (例: my_data_plane_deploy.yaml) を作成します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
   name: my-data-plane-deploy

   ヒント

   定義ファイルと OpenStackDataPlaneDeployment CR に、変更されたノードセットの目的を示す一意の説明的な名前を付けます。

8. 変更した OpenStackDataPlaneNodeSet CR を追加します。

   spec:
   nodeSets:
   - my-data-plane-node-set

9. OpenStackDataPlaneDeployment CR デプロイメントファイルを保存します。

10. 変更した OpenStackDataPlaneNodeSet CR をデプロイします。

    $ oc create -f my_data_plane_deploy.yaml -n openstack

11. デプロイメントの実行中に Ansible ログを表示できます。

    $ oc get pod -l app=openstackansibleee -n openstack -w
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10

12. 変更された OpenStackDataPlaneNodeSet CR がデプロイされていることを確認します。

    以下に例を示します。

    $ oc get openstackdataplanedeployment -n openstack

    出力サンプル

    NAME STATUS MESSAGE
    my-data-plane-node-set True Setup Complete

13. NodeSet Ready メッセージが表示されるまで、oc get コマンドを繰り返します。

    例

    $ oc get openstackdataplanenodeset -n openstack

    出力サンプル

    NAME STATUS MESSAGE
    my-data-plane-node-set True NodeSet Ready

    返されるステータスの意味については、Red Hat OpenStack Services on OpenShift のデプロイ の データプレーンの状態 を参照してください。

手順

1. nova-extra-config という名前の ConfigMap CR を作成または更新し、[glance] の下のパラメーターの値を設定して、Image サービス RBD バックエンドと、Compute サービスが Image サービス RBD バックエンドへの接続を待機する最大時間 (秒単位) を指定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      33-nova-image-rbd.conf: |
        [glance]
        enable_rbd_download=True
        rbd_user=openstack
        rbd_pool=images
        rbd_ceph_conf=/etc/ceph/ceph.conf
        rbd_connect_timeout=5

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

2. 新しい OpenStackDataPlaneDeployment CR を作成し、データプレーンノード上のサービスを設定してデータプレーンをデプロイし、ワークステーション上の compute_image_rbd_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-image-rbd

3. compute_image_rbd_deploy.yaml CR で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR を含めるようにしてください。これは、RBD から直接イメージのダウンロードを設定するノードを定義します。

   警告

   ノードセット内のノードのサブセットは再設定できません。そうする必要がある場合は、ノードセットをスケールダウンし、以前に削除したノードから新しいノードセットを作成する必要があります。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成し、必要なノードセットでそのカスタムサービスを使用する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-image-rbd
   spec:
      nodeSets:
        - openstack-edpm
        - compute-image-rbd
        - ...
        - <nodeSet_name>

   • <nodeSet_name> を、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
4. compute_image_rbd_deploy.yaml デプロイメントファイルを保存します。

5. データプレーンをデプロイします。

   $ oc create -f compute_image_rbd_deploy.yaml

6. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME           STATUS MESSAGE
   compute-image-rbd True   Deployed

7. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

手順

1. ワークステーションで、OpenStackControlPlane カスタムリソース (CR) ファイル (openstack_control_plane.yaml) を開きます。

2. スケジューラーが使用するフィルターを [filter_scheduler] enabled_filters パラメーターに追加します。以下はその例です。

   spec:
       nova:
         template:
           schedulerServiceTemplate:
             customServiceConfig: |
               [filter_scheduler]
               enabled_filters = AggregateInstanceExtraSpecsFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter

3. 各コンピュートノードの重みを計算するのに使用する属性を指定します。以下に例を示します。

   spec:
       nova:
         template:
           schedulerServiceTemplate:
             customServiceConfig: |
               [filter_scheduler]
               weight_classes = nova.scheduler.weights.all_weighers

   利用可能な属性の詳細は、Compute スケジューラーの重み を参照してください。

4. オプション: 各重み付け関数に適用する重みの乗数を設定します。たとえば、コンピュートノードの利用可能な RAM が他のデフォルトの重み付け関数よりも高い重みを持つように指定し、Compute スケジューラーが、利用可能な RAM が少ないコンピュートノードよりも、利用可能な RAM が多いコンピュートノードを優先するには、以下の設定を使用します。

   spec:
       nova:
         template:
           schedulerServiceTemplate:
             customServiceConfig: |
               [filter_scheduler]
               weight_classes = nova.scheduler.weights.all_weighers
               [filter_scheduler]
               ram_weight_multiplier = 2.0

   ヒント

   また、重みの乗数を負の値に設定することもできます。上記の例では、利用可能な RAM が多いコンピュートノードよりも利用可能な RAM が少ないノードを優先するには、ram_weight_multiplier を -2.0 に設定します。

5. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

6. RHOCP が OpenStackControlPlane CR に関連するリソースを作成した後、次のコマンドを実行してステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

   ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

   ヒント

   デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

7. オプション: 作成した各セルの openstack namespace 内の Pod を確認して、コントロールプレーンがデプロイされていることを確認します。

   $ oc get pods -n openstack

   すべての Pod が完了または実行中の状態であれば、コントロールプレーンがデプロイされています。

1. スケジューラーは、各重みを 0.0 から 1.0 までの値に正規化します。
2. スケジューラーは、正規化された重みを重み付け関数の乗数で乗算します。

手順

1. /home/stack/templates/ に provider.yaml というファイルを作成します。

2. リソースプロバイダーを設定するには、provider.yaml ファイルに次の設定を追加します。

   meta:
     schema_version: '1.0'
   providers:
     - identification:
         uuid: <node_uuid>

   • <node_uuid> をノードの UUID に置き換えます (例: '5213b75d-9260-42a6-b236-f39b0fd10561')。あるいは、name プロパティーを使用してリソースプロバイダーを指定することもできます (name: 'EXAMPLE_RESOURCE_PROVIDER')。

3. リソースプロバイダー用に使用可能なカスタムリソースクラスを設定するには、次の設定を provider.yaml ファイルに追加します。

   meta:
     schema_version: '1.0'
   providers:
     - identification:
         uuid: <node_uuid>
       inventories:
         additional:
           - CUSTOM_EXAMPLE_RESOURCE_CLASS:
               total: <total_available>
               reserved: <reserved>
               min_unit: <min_unit>
               max_unit: <max_unit>
               step_size: <step_size>
               allocation_ratio: <allocation_ratio>

   • CUSTOM_EXAMPLE_RESOURCE_CLASS をリソースクラスの名前に置き換えます。カスタムリソースクラスは接頭辞 CUSTOM_ で始まり、A から Z までの文字、0 から 9 までの数字、およびアンダースコア "_" だけを使用する必要があります。
   • <total_available> は、このリソースプロバイダーで使用可能な CUSTOM_EXAMPLE_RESOURCE_CLASS の数に置き換えます。
   • <reserved> は、このリソースプロバイダーで使用可能な CUSTOM_EXAMPLE_RESOURCE_CLASS の数に置き換えます。
   • <min_unit> は、単一インスタンスが消費できるリソースの最小単位に置き換えます。
   • <max_unit> は、単一インスタンスが消費できるリソースの最大単位に置き換えます。
   • <step_size> は、このリソースプロバイダーで使用できる CUSTOM_EXAMPLE_RESOURCE_CLASS の数に置き換えます。
   • <allocation_ratio> は、割り当て比率を設定する値に置き換えます。allocation_ratio が 1.0 に設定されている場合、過剰割り当ては許可されません。しかし、allocation_ration が 1.0 より大きい場合、使用可能なリソースの合計は物理的に存在するリソースよりも多くなります。

4. リソースプロバイダー用に使用可能な特性を設定するには、provider.yaml ファイルに次の設定を追加します。

   meta:
     schema_version: '1.0'
   providers:
     - identification:
         uuid: <node_uuid>
       inventories:
         additional:
         ...
         traits:
         additional:
           - 'CUSTOM_EXAMPLE_TRAIT'

   • CUSTOM_EXAMPLE_TRAIT を特性の名前に置き換えます。カスタムの特性は接頭辞 CUSTOM_ で始まり、A から Z までの文字、0 から 9 までの数字、およびアンダースコア "_" だけを使用する必要があります。

     provider.yaml ファイルの例: 次の例では、リソースプロバイダーに対して 1 つのカスタムリソースクラスと 1 つのカスタム特性を宣言します。

     meta:
       schema_version: 1.0
     providers:
       - identification:
           uuid: $COMPUTE_NODE
         inventories:
           additional:
             CUSTOM_LLC:
               # Describing LLC on this compute node
               # max_unit indicates maximum size of single LLC
               # total indicates sum of sizes of all LLC
               total: 22 

     1

     
               reserved: 2 

     2

     
               min_unit: 1 

     3

     
               max_unit: 11 

     4

     
               step_size: 1 

     5

     
               allocation_ratio: 1.0 

     6

     
         traits:
             additional:
                 # Describing that this compute node enables support for
                 # P-state control
                 - CUSTOM_P_STATE_ENABLED

     1

     このハイパーバイザーには 22 ユニットの最終レベルキャッシュ (LLC) があります。

     2

     LLC のユニットのうち 2 つはホスト用に予約されています。

     3 4

     min_unit および max_unit の値は、単一の仮想マシンが消費できるリソースのユニット数を定義します。

     5

     ステップサイズは消費量の増分を定義します。

     6

     割り当て比率は、リソースの過剰割り当てを設定します。

5. provider.yaml ファイルを保存して閉じます。

6. コンピュートノードがカスタム特性とリソースの宣言に provider.yaml ファイルを使用するように設定する ConfigMap CR を作成し、ワークステーション上の compute-provider.yaml という名前のファイルに保存します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: compute-provider
      namespace: openstack
   data:
      provider.yaml: |

   ConfigMap オブジェクトの作成の詳細は、「config map の作成と使用」を参照してください。

7. ConfigMap オブジェクトを作成します。

   $ oc create -f compute-provider.yaml

8. compute-provider ConfigMap オブジェクトをはじめとする新しいカスタムサービス (compute-provider) を作成し、ワークステーション上の compute-provider-service.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
      name: compute-provider
      namespace: openstack
   spec:
     label: dataplane-deployment-compute
     playbook: osp.edpm.nova
     secrets: []
     dataSources:
        - secretRef:
              name: nova-cell1-compute-config
        - secretRef:
              name: nova-migration-ssh-key
        - configMapRef:
              name: compute-provider
        - configMapRef:
              name: nova-extra-config
              optional: true

9. compute-provider サービスを作成します。

   $ oc apply -f compute-provider-service.yaml

10. カスタム特性とリソースの宣言に provider.yaml ファイルを使用するノードを定義する新しい OpenStackDataPlaneNodeSet CR を作成し、ワークステーション上の compute-provider.yaml という名前のファイルに保存します。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: compute-provider

    OpenStackDataPlaneNodeSet CR の作成方法の詳細は、「データプレーンノードセットの作成」を参照してください。

11. compute-provider OpenStackDataPlaneNodeSet CR を、デフォルトの Compute サービスの代わりに compute-provider-service サービスを使用するように変更します。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: compute-provider
    spec:
      services:
        - download-cache
        - configure-network
        - validate-network
        - install-os
        - configure-os
        - run-os
        - ovn
        - libvirt
        - compute-provider-service #replaced the nova service
        - telemetry

12. compute-provider.yaml OpenStackDataPlaneNodeSet CR 定義ファイルを保存します。

13. データプレーンリソースを作成します。

    $ oc create -f compute-provider.yaml

14. データプレーンリソースが作成されたことを確認します。

    $ oc get openstackdataplanenodeset
    NAME              STATUS MESSAGE
    compute-provider False  Deployment not started

15. サービスが作成されたことを確認します。

    $ oc get openstackdataplaneservice
    NAME                AGE
    download-cache      6d7h
    configure-network   6d7h
    configure-os        6d6h
    install-os          6d6h
    run-os              6d6h
    validate-network    6d6h
    ovn                 6d6h
    libvirt             6d6h
    compute-provider    6d6h
    telemetry           6d6h

16. 新しい OpenStackDataPlaneDeployment CR を作成し、データプレーンノード上のサービスを設定してノードをデプロイし、ワークステーション上の compute-provider_deploy.yaml という名前のファイルに保存します。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: compute-provider

    OpenStackDataPlaneDeployment CR の作成方法の詳細は、「データプレーンのデプロイ」を参照してください。

17. デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: compute-provider
    spec:
      nodeSets:
        - openstack-edpm
        - compute-provider
        - ...
        - <nodeSet_name>

    • <nodeSet_name> を、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
18. compute-provider_deploy.yaml デプロイメントファイルを保存します。

19. データプレーンをデプロイします。

    $ oc create -f compute-provider_deploy.yaml

20. データプレーンがデプロイされていることを確認します。

    $ oc get openstackdataplanedeployment
    NAME             			STATUS   MESSAGE
    compute-provider  	True     Deployment Completed
    
    $ oc get openstackdataplanenodeset
    NAME             	STATUS   MESSAGE
    openstack-edpm   	True     Deployed
    compute-provider 	True     Deployed

21. デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

    $ oc rsh nova-cell0-conductor-0 nova-manage cell_v2 discover_hosts --verbose

22. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

    $ oc rsh -n openstack openstackclient
    $ openstack hypervisor list

手順

1. per-project クォータのクォータ適用については、システムスコープの reader ロールを Compute サービスユーザーに追加します。

   $ oc exec openstackclient -- openstack role add --user nova --user-domain <service_domain_name> --system all reader

   • <service_domain_name> をサービスドメイン名に置き換えます。

2. Compute サービスエンドポイント ID を取得します。nova-api および nova-conductor サービスを設定するには、この値が必要です。

   $ oc exec openstackclient -- openstack endpoint list --service nova -f value -c ID

3. ワークステーションで OpenStackControlPlane カスタムリソース (CR) ファイル openstack_control_plane.yaml を開きます。

4. openstack_control_plane.yaml で nova-api および nova-conductor サービスを設定します。driver パラメーターを nova.quota.UnifiedLimitsDriver に設定します。前の手順で取得した Compute サービスの endpoint_id を、各セルの apiServiceTemplate.customServiceConfig と conductorServiceTemplate.customServiceConfig に定義する必要があります。

   簡単な例:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     nova:
       template:
         apiServiceTemplate:
           customServiceConfig: |
             [quota]
             driver = nova.quota.UnifiedLimitsDriver
             [oslo_limit]
             endpoint_id = <service_endpoint_id>
         cellTemplates:
           cell0:
             conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>
           cell1:
             conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>

   • <service_endpoint_id> を、前の手順で取得した Compute サービスエンドポイント ID に置き換えます。

     注記

     セルを追加する場合は、新しいセルにも統合制限を設定する必要があります。新しいセルを追加するには、Red Hat OpenStack Services on OpenShift デプロイメントのカスタマイズ ガイドの コントロールプレーンへのコンピュートセルの追加 を参照してください。

5. オプション: unified_limits_resource_list パラメーターを設定することで、[quota] 統合制限リソースストラテジーとして、登録済みの制限を無視 (ignore) するか要求 (require) するかを設定します。デフォルトのストラテジーは require であり、デフォルトのリソースリストには servers が含まれます。

   リソースストラテジーが require の設定例:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     nova:
       template:
         apiServiceTemplate:
           customServiceConfig: |
             [quota]
             driver = nova.quota.UnifiedLimitsDriver
             unified_limits_resource_strategy = require
   
             # Do not allow allocation of a resource in this list unless it has
             # a limit set in Keystone.
             unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
             [oslo_limit]
             endpoint_id = <service_endpoint_id>
         cellTemplates:
           cell0:
              conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 unified_limits_resource_strategy = require
   
                 # Do not allow allocation of a resource in this list unless it has
                 # a limit set in Keystone.
                 unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>
           cell1:
              conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 unified_limits_resource_strategy = require
   
                 # Do not allow allocation of a resource in this list unless it has
                 # a limit set in Keystone.
                 unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>

   リソースストラテジーが ignore の設定例:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     nova:
       template:
         apiServiceTemplate:
           customServiceConfig: |
             [quota]
             driver = nova.quota.UnifiedLimitsDriver
             unified_limits_resource_strategy = ignore
   
             # Allow unlimited allocation of a resource in this list unless it
             # has a limit set in Keystone.
   
             unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
             [oslo_limit]
             endpoint_id = <service_endpoint_id>
         cellTemplates:
           cell0:
              conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 unified_limits_resource_strategy = ignore
   
                 # Allow unlimited allocation of a resource in this list unless it
                 # has a limit set in Keystone.
                 unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>
           cell1:
              conductorServiceTemplate:
               customServiceConfig: |
                 [quota]
                 driver = nova.quota.UnifiedLimitsDriver
                 unified_limits_resource_strategy = ignore
   
                 # Allow unlimited allocation of a resource in this list unless it
                 # has a limit set in Keystone.
                 unified_limits_resource_list = servers,class:VCPU,class:MEMORY_MB,class:DISK_GB
                 [oslo_limit]
                 endpoint_id = <service_endpoint_id>

6. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

7. Red Hat OpenShift Container Platform (RHOCP) が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

   ステータスが Setup complete であれば、OpenStackControlPlane リソースが作成されています。

   ヒント

   デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

8. オプション: 作成した各セルの openstack namespace 内の Pod を確認して、コントロールプレーンがデプロイされていることを確認します。すべての Pod が完了または実行中の状態であれば、コントロールプレーンがデプロイされています。

手順

1. nova コンダクター Pod で、移行コマンドを 1 回実行してデフォルトの制限を移行し、欠落している制限を検出します。

   $ oc exec nova-cell0-conductor-0 -- nova-manage limits migrate_to_unified_limits

   Identity サービスで制限が設定されていないリソースを示すテーブルが出力されます。

2. オプション: nova コンダクター Pod では、プロジェクトごとに移行コマンドを 1 回実行して、per-project 制限を移行できます。

   $ oc exec nova-cell0-conductor-0 -- nova-manage limits migrate_to_unified_limits --no-embedded-flavor-scan --quiet --project-id <project_id>

   • <project_id> をプロジェクトの ID 番号に置き換えます。

3. 残りのリソースに対して、デフォルトの登録済み制限と per-project 制限を手動で作成します。無制限を示すには、制限を -1 に設定します。

   • デフォルトの制限を設定します。

     $ oc exec openstackclient -- openstack registered limit create --service nova --default-limit <limit> <resource>

     • <limit> を制限値に置き換えます。
     • <resource> をリソースの名前に置き換えます。

   • プロジェクトの制限を設定します。

     $ oc exec openstackclient -- openstack limit create --service nova --project <project_id> --resource-limit <limit> <resource>

     クォータリソース名の形式は次のとおりです。

     Expand

     $RESOURCE	説明
     class:VCPU	プロジェクトごとに許可される共有 CPU コア (VCPU) の数
     class:PCPU	プロジェクトごとに許可される専用 CPU コア (PCPU) の数
     servers	プロジェクトごとに許可されるインスタンスの数
     server_key_pairs	ユーザーごとに許可されるキーペアの数
     server_metadata_items	インスタンスごとに許可されるメタデータ項目の数
     class:MEMORY_GB	プロジェクトごとに許可されるインスタンス RAM のメガバイト数
     server_groups	プロジェクトごとのサーバーグループ数
     server_group_members	サーバーグループごとのサーバー数
     class:DISK_GB	プロジェクトごとに許可されるインスタンスディスクのギガバイト数
     class:<resource_class>	Placement API サービスの任意のリソースクラスに指定できるクォータ制限 (例: class:VGPU)

     Show more

手順

1. ワークステーションで OpenStackControlPlane カスタムリソース (CR) ファイル openstack_control_plane.yaml を開きます。

2. nova テンプレートに customServiceConfig フィールドを追加して、コンピュートノード上の PCI デバイスの PCI エイリアスを指定します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     nova:
       apiOverride:
         route: {}
       template:
         secret: osp-secret
         apiServiceTemplate:
           replicas: 3
           customServiceConfig: |
             [pci]
             alias = {"name":"a1", "product_id":"<prod_id>", "vendor_id": "<vendor_id>", "device_type": "<device_type>"}

   • <prod_id> を PCI デバイスの製品 ID (例: 1572) に置き換えます。
   • <vendor_id> を PCI デバイスのベンダー ID (例: 8086) に置き換えます。

   • <device_type> を PCI デバイスのタイプ (例: type-PF) に置き換えます。

     注記

     PCI デバイスがインストールされているシステムで lspci -nn コマンドを使用すると、製品 ID とベンダー ID を確認できます。device_type フィールドの設定の詳細は、PCI パススルーデバイス種別フィールド を参照してください。

3. オプション: PCI パススルーデバイスのデフォルトの NUMA アフィニティーポリシーを設定するには、設定に numa_policy を追加します。

             [pci]
             alias = {"name":"a1", "product_id":"<prod_id>", "vendor_id": "<vendor_id>", "device_type": "<device_type>", "numa_policy": "<pci_numa_policy>"}

   • <prod_id> を PCI デバイスの製品 ID (例: 1572) に置き換えます。
   • <vendor_id> を PCI デバイスのベンダー ID (例: 8086) に置き換えます。
   • <device_type> を PCI デバイスのタイプ (例: type-PF) に置き換えます。
   • <pci_numa_policy> を required、socket、preferred、または legacy の値に置き換えます。詳細は、Nova PCI パススルーを設定するためのガイドライン を参照してください。

4. コントロールプレーンを更新します。

   oc apply -f openstack_control_plane.yaml -n openstack

5. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

   出力例:

   NAME                      STATUS    MESSAGE
   openstack-control-plane   Unknown   Setup started

   ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

   ヒント

   デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

6. オプション: 各セルの openstack namespace 内の Pod を確認して、コントロールプレーンがデプロイされていることを確認します。

   $ oc get pods -n openstack

   すべての Pod が完了または実行中の状態であれば、コントロールプレーンがデプロイされています。

手順

1. インスタンスの移行およびサイズ変更の操作を行うために、コンピュートノードの PCI エイリアスのコピーを作成します。PCI パススルーコンピュートノード上のデバイスの PCI エイリアスを指定するには、nova-extra-config という名前の ConfigMap CR を作成または更新し、[pci] alias パラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      32-nova-pci-alias.conf: |
        [pci]
        alias = {"name":"a1", "product_id":"1572", "vendor_id": "8086", "device_type": "type-PF", "numa_policy": "preferred"}

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

   注記

   コンピュートノードのエイリアスは、コントローラーノードのエイリアスと同じでなければなりません。したがって、OpenStackControlPlane カスタムリソース (CR) ファイル openstack_control_plane.yaml で apiServiceTemplate の customServiceConfig に numa_affinity を追加した場合は、nova-extra-config の PCI エイリアスにもそれを追加する必要があります。

2. alias パラメーターの下で、device_spec パラメーターを設定して、nova が PCI デバイスにアクセスできるようにします。

   alias = {"name":"a1", "product_id":"1572", "vendor_id": "8086", "device_type": "type-PF", "numa_policy": "preferred"}
   device_spec = {"vendor_id":"8086", "product_id":"1572", "address": "0000:06:"}

   注記

   GPU タイプに固有のベンダー ID を使用するようにしてください。

3. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイし、ワークステーション上の compute_pci_alias_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-pci-alias

4. compute_pci_alias_deploy.yaml CR で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。OpenStackDataPlaneNodeSet CR は、設定するノードを定義します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-pci-alias
   spec:
      nodeSets:
        - openstack-edpm
        - compute-pci-alias
        - ...
        - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。

     警告

     デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

     1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。
     2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

     DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成する必要があります。

5. compute_pci_alias_deploy.yaml デプロイメントファイルを保存します。

6. データプレーンをデプロイします。

   $ oc create -f compute_pci_alias_deploy.yaml

7. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME              STATUS MESSAGE
   compute-pci-alias True   Deployed

8. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

9. PCI パススルーをサポートするためにコンピュートノードのサーバー BIOS で IOMMU を有効にするには、更新するノードセットの OpenStackDataPlaneNodeSet CR 定義ファイル (例: my_data_plane_node_set.yaml) を開きます。

10. 必要な設定を追加するか、既存の設定を my_data_plane_node_set.yaml に変更します。設定を ansibleVars の下に配置します。次の例では、Intel IOMMU を有効にします。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
        name: my-data-plane-node-set
    spec:
        …
        nodeTemplate:
            …
            ansible:
                ansibleVars:
    edpm_kernel_args: "default_hugepagesz=1GB hugepagesz=1G hugepages=64 intel_iommu=on iommu=pt tsx=off isolcpus=2-11,14-23 vfio-pci.ids=<pci_device_id> rd.driver.pre=vfio-pci"

    • <pci_device_id> は、使用している GPU の PCI デバイス ID (例: 10de:1eb8) に置き換えます。GPU 固有のデバイス ID を使用するようにしてください。

      注記

      ロールの設定に KernelArgs パラメーターを初めて追加すると、コントロールプレーンノードが自動的に再起動されます。必要に応じて、ノードの自動再起動を無効にして、代わりに各デプロイメント後にノードの再起動を手動で実行できます。

11. OpenStackDataPlaneNodeSet CR 定義ファイルを保存します。

12. 更新済みの OpenStackDataPlaneNodeSet CR 設定を適用します。

    $ oc apply -f my_data_plane_node_set.yaml -n openstack

13. データプレーンリソースが更新されたことを確認します。

    $ oc get openstackdataplanenodeset
    Sample output:
    NAME                     STATUS MESSAGE
    my-data-plane-node-set   False  Deployment not started

14. ワークステーションに OpenStackDataPlaneDeployment CR を定義するファイル (例: my_data_plane_deploy.yaml) を作成します。

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: my-data-plane-deploy

    ヒント

    定義ファイルと OpenStackDataPlaneDeployment CR に、変更されたノードセットの目的を示す一意の説明的な名前を付けます。

15. 変更した OpenStackDataPlaneNodeSet CR を追加します。

    spec:
      nodeSets:
        - my-data-plane-node-set

16. OpenStackDataPlaneDeployment CR デプロイメントファイルを保存します。

17. 変更した OpenStackDataPlaneNodeSet CR をデプロイします。

    $ oc create -f my_data_plane_deploy.yaml -n openstack

18. デプロイメントの実行中に Ansible ログを表示できます。

    $ oc get pod -l app=openstackansibleee -n openstack -w
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10

19. 変更された OpenStackDataPlaneNodeSet CR がデプロイされていることを確認します。

    $ oc get openstackdataplanedeployment -n openstack
    Sample output
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete

20. NodeSet Ready メッセージが表示されるまで、oc get コマンドを繰り返します。

    $ oc get openstackdataplanenodeset -n openstack
    Sample output:
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready

    返されるステータスの意味の詳細は、Red Hat OpenStack Services on OpenShift のデプロイ の データプレーンの状態 を参照してください。

21. クラウドユーザーが PCI デバイスを要求するのに使用できるフレーバーを作成および設定します。次の例では、手順 7 で定義されたエイリアスを使用して、ベンダー ID が 8086、製品 ID が 1572 の 2 つのデバイスを要求します。

    $ openstack --os-compute-api=2.86 flavor set \
     --property "pci_passthrough:alias"="a1:2" device_passthrough

22. (オプション) フレーバーまたはイメージに NUMA アフィニティーポリシーの属性キーを追加して、PCI パススルーデバイスのデフォルト NUMA アフィニティーポリシーをオーバーライドすることができます。

    • フレーバーを使用してデフォルトの NUMA アフィニティーポリシーをオーバーライドするには、hw:pci_numa_affinity_policy 属性キーを追加します。

      $ openstack --os-compute-api=2.86 flavor set \
       --property "hw:pci_numa_affinity_policy"="required" \
       Device_passthrough

      hw:pci_numa_affinity_policy の有効な値の詳細は、フレーバーメタデータ を参照してください。

    • イメージを使用してデフォルトの NUMA アフィニティーポリシーをオーバーライドするには、hw_pci_numa_affinity_policy 属性キーを追加します。

      $ openstack image set \
       --property hw_pci_numa_affinity_policy=required \
       device_passthrough_image

      注記

      イメージとフレーバーの両方で NUMA アフィニティーポリシーを設定する場合には、属性の値が一致している必要があります。フレーバーの設定は、イメージおよびデフォルトの設定よりも優先されます。したがって、イメージの NUMA アフィニティーポリシーの設定は、フレーバーで属性が設定されていない場合に限り効果を持ちます。

1. PCI パススルーデバイスを設定してインスタンスを作成します。

   $ openstack server create --flavor device_passthrough \
   --image <image> --wait test-pci

2. クラウドユーザーとしてインスタンスにログインします。詳細は、インスタンスの作成と管理 の インスタンスへの接続 を参照してください。

3. インスタンスが PCI デバイスにアクセスできることを確認するには、インスタンスから以下のコマンドを入力します。

   $ lspci -nn | grep <device_name>

手順

1. nova-extra-config.yaml という名前の ConfigMap カスタムリソース (CR) を作成または更新します。

2. one_time_use タグを追加して、OTU デバイスとしてタグ付けするデバイスの device_spec を追加または編集します。

   以下は、このタグが追加された device_spec の例です。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      32-nova-pci-alias.conf: |
         [pci]
         alias = {"name":"a1", "product_id":"1572", "vendor_id": "8086", "device_type": "type-PF", "numa_policy": "preferred"}
         device_spec = {"vendor_id":"8086", "product_id":"1572", "address": "0000:06:", "one_time_use": true}

   注記

   device_spec 設定オプションは複数回定義することができ、Red Hat OpenStack Services on OpenShift (RHOSO) はこれらの定義をそれぞれ 1 つの device_spec 値リストにマージします。つまり、device_spec 値は、後続の device_spec 定義で上書きできません。デバイスを OTU デバイスとして設定する場合、device_spec を定義した元の設定ファイルで one_time_use タグを定義する必要があります。

   たとえば、PCI パススルー用の OpenStackDataPlaneNodeSet CR の作成 では、クラウドユーザーによる PCI デバイスが割り当てられたインスタンスの作成を可能にする方法が定義されています。通常、この段階でタグが device_spec に追加されます。

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

3. nova-extra-config.yaml ファイルを保存します。

4. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイします。CR を、ワークステーション上の compute_otu_devices_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-otu-devices

5. compute_otu_devices_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、OTU デバイスとして設定するノードを定義します。

   警告

   ノードセット内のノードのサブセットは再設定できません。そうする必要がある場合は、ノードセットをスケールダウンし、以前に削除したノードから新しいノードセットを作成する必要があります。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。
   2. DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成し、必要なノードセットでそのカスタムサービスを使用する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-otu-devices
   spec:
      nodeSets:
        - openstack-edpm
        - ...
        - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
6. compute_otu_devices_deploy.yaml デプロイメントファイルを保存します。

7. データプレーンをデプロイします。

   $ oc create -f compute_otu_devices_deploy.yaml

8. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME                STATUS MESSAGE
   compute-otu-devices True   Deployed

9. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   
   $ openstack hypervisor list

手順

1. HW_PCI_ONE_TIME_USE トレイトを持つデバイスを特定します。

   $ openstack resource provider list --required HW_PCI_ONE_TIME_USE

   以下はこのコマンドの出力例です。

   $ openstack resource provider list --required HW_PCI_ONE_TIME_USE
   +--------------------------------------+--------------------+------------+--------------------------------------+--------------------------------------+
   | uuid                                 | name               | generation | root_provider_uuid                   | parent_provider_uuid                 |
   +--------------------------------------+--------------------+------------+--------------------------------------+--------------------------------------+
   | b9e67d7d-43db-49c7-8ce8-803cad08e656 | compute-01:00:01.0 |         39 | 2ee402e8-c5c6-4586-9ac7-58e7594d27d1 | 2ee402e8-c5c6-4586-9ac7-58e7594d27d1 |
   +--------------------------------------+--------------------+------------+--------------------------------------+--------------------------------------+

2. リスト内の各デバイスに対して、次のタスクを実行します。

   1. reserved 属性の値が 1、used 属性の値が 0 であることを確認します。

      $ openstack resource provider inventory list <device_uuid>

      • <device_uuid> は、デバイスの UUID に置き換えます。

        以下はこのコマンドの出力例です。

        $ openstack resource provider inventory list b9e67d7d-43db-49c7-8ce8-803cad08e656
        +----------------------+------------------+----------+----------+----------+-----------+-------+------+
        | resource_class       | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used |
        +----------------------+------------------+----------+----------+----------+-----------+-------+------+
        | CUSTOM_PCI_1B36_0100 |              1.0 |        1 |        1 |        1 |         1 |     1 |    0 |
        +----------------------+------------------+----------+----------+----------+-----------+-------+------+

        重要

        used 属性の値が 0 でない場合は、デバイスの予約状態をクリアしないでください。

   2. reserved 属性の値を 0 に設定します。

      $ openstack resource provider inventory set --amend \
          --resource <device_resource_class>:reserved=0 \
          <device_uuid>

      • <device_resource_class> は、デバイスの resource_class に置き換えます。
      • <device_uuid> は、デバイスの UUID に置き換えます。

手順

1. nova-extra-config という名前の ConfigMap CR を作成または更新し、[pci] report_in_placement パラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      37-nova-pci-placement.conf: |
        [pci]
        report_in_placement = true

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

2. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイし、ワークステーション上の compute_pci_tracking_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: compute_pci_tracking

   OpenStackDataPlaneDeployment CR の作成の詳細は、Red Hat OpenStack Services on OpenShift のデプロイ の データプレーンのデプロイ を参照してください。

3. compute_pci_tracking_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、CPU ピニングに指定するノードを定義します。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: compute-pci_tracking
   spec:
     nodeSets:
       - openstack-edpm
       - compute-pci-alias
       - compute-pci_tracking
       - ...
       - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
4. compute_pci_tracking_deploy.yaml デプロイメントファイルを保存します。

5. データプレーンをデプロイします。

   $ oc create -f compute_pci_tracking_deploy.yaml

6. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   NAME           STATUS MESSAGE
   compute-pci_tracking True   Deployed

7. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   $ openstack resource provider list

手順

1. ワークステーションで OpenStackControlPlane カスタムリソース (CR) ファイル openstack_control_plane.yaml を開きます。

   . Add the following `[filter_scheduler] pci_in_placement` configuration to the `nova` service configuration:
    nova:
       template:
         apiServiceTemplate:
           customServiceConfig: |
             [filter_scheduler]
             pci_in_placement = true
         cellTemplates:
           cell0:
             conductorServiceTemplate:
               customServiceConfig: |
                 [filter_scheduler]
                 pci_in_placement = true
           cell1:
             conductorServiceTemplate:
               customServiceConfig: |
                 [filter_scheduler]
                 pci_in_placement = true
         schedulerServiceTemplate:
           customServiceConfig: |
             [filter_scheduler]
             pci_in_placement = true

   注記

   複数のセルが存在する場合は、各セルに [filter_scheduler] pci_in_placement 設定を適用する必要があります。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

3. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

   ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

   ヒント

   デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

4. オプション: 各セルの openstack namespace 内の Pod を確認して、コントロールプレーンがデプロイされていることを確認します。

   $ oc get pods -n openstack

   すべての Pod が完了または実行中の状態であれば、コントロールプレーンがデプロイされています。

手順

1. 特定のデバイス (たとえば、compute1 上の PCI アドレス 0000:09:00.0 のデバイス) を予約するには、コマンドでデバイスリソースプロバイダー (RP) を使用して、デバイスの UUID を取得する必要があります。デバイス RP は、コンピュートノードのホスト名と GPU の PCI アドレスを組み合わせたものです (例: compute1_0000:09:00.0)。

   $ openstack resource provider list --name compute1_0000:09:00.0
   +--------------------------------------+-----------------------+------------+--------------------------------------+--------------------------------------+
   | uuid                                 | name                  | generation | root_provider_uuid                   | parent_provider_uuid                 |
   +--------------------------------------+-----------------------+------------+--------------------------------------+--------------------------------------+
   | d3d0f3d7-8376-487f-8849-e43027c31582 | compute1_0000:09:00.0 |          2 | e909b54b-4cea-49f9-bfcb-17c833db51d1 | e909b54b-4cea-49f9-bfcb-17c833db51d1 |
   +--------------------------------------+-----------------------+------------+--------------------------------------+--------------------------------------+

2. デバイスの uuid を使用して、RP の現在のインベントリーを確認します。この例の UUID は d3d0f3d7-8376-487f-8849-e43027c31582 です。

   $ openstack resource provider inventory list d3d0f3d7-8376-487f-8849-e43027c31582
   +----------------------+------------------+----------+----------+----------+-----------+-------+------+
   | resource_class       | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used |
   +----------------------+------------------+----------+----------+----------+-----------+-------+------+
   | CUSTOM_PCI_8086_10C9 |              1.0 |        1 |        1 |        0 |         1 |     1 |    0 |
   +----------------------+------------------+----------+----------+----------+-----------+-------+------+

   注記

   デバイスを予約すると、Compute スケジューラーサービスは以降のスケジュールでそのデバイスを使用できなくなります。ただし、引き続きデバイスは既存の仮想マシンによって使用される場合があります。インベントリーリスト出力の used 列の値が 0 に設定されている場合、デバイスは既存の仮想マシンによって使用されていません。

3. デバイスを予約するには、reserved の値を 1 に設定します。

   openstack resource provider inventory set d3d0f3d7-8376-487f-8849-e43027c31582 --amend --resource CUSTOM_PCI_8086_10C9:reserved=1
   +----------------------+------------------+----------+----------+----------+-----------+-------+
   | resource_class       | allocation_ratio | min_unit | max_unit | reserved | step_size | total |
   +----------------------+------------------+----------+----------+----------+-----------+-------+
   | CUSTOM_PCI_8086_10C9 |              1.0 |        1 |        1 |        1 |         1 |     1 |
   +----------------------+------------------+----------+----------+----------+-----------+-------+

4. デバイスの予約を解除し、Compute スケジューラーサービスで再度使用できるようにするには、reserved の値を 0 に設定します。

   openstack resource provider inventory set d3d0f3d7-8376-487f-8849-e43027c31582 --amend --resource CUSTOM_PCI_8086_10C9:reserved=0
   +----------------------+------------------+----------+----------+----------+-----------+-------+
   | resource_class       | allocation_ratio | min_unit | max_unit | reserved | step_size | total |
   +----------------------+------------------+----------+----------+----------+-----------+-------+
   | CUSTOM_PCI_8086_10C9 |              1.0 |        1 |        1 |        0 |         1 |     1 |
   +----------------------+------------------+----------+----------+----------+-----------+-------+

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh openstackclient

2. vGPU に使用するノードを特定します。

   1. vGPU に使用するコンピュートノードの IP アドレスを取得します。

      $ openstack hypervisor list

   2. SSH を使用してデータプレーンノードに接続します。

      $ ssh <node_ipaddress>

   3. /etc/modprobe.d/blacklist-nouveau.conf ファイルを作成します。

   4. blacklist-nouveau.conf に次の設定を追加して、nouveau ドライバーを無効にします。

      blacklist nouveau
      options nouveau modeset=0

   5. initramfs を再生成します。

      $ dracut --force
      $ grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline

   6. NVIDIA ポータルから NVIDIA ドライバーをダウンロードしてインストールします。詳細は、NVIDIA DOCS HUB を参照してください。

   7. ノードをリブートします。

      $ sudo reboot

3. vGPU インスタンスに割り当てるすべてのノードに対してこの手順を繰り返します。

手順

1. 仮想 GPU は仲介デバイスです。各コンピュートノード上で仲介デバイスを作成できる各デバイスの PCI アドレスを取得します。

   $ ls /sys/class/mdev_bus/

   注記

   GPU の PCI アドレス (または vGPU を作成できる GPU SR-IOV Virtual Function (VF)) が、デバイスドライバーディレクトリー名として使用されます (例: 0000:84:00.0)。この手順では、vGPU 対応リソースは mdev デバイスと呼ばれます。

   注記

   最近の世代の NVIDIA カードでは SR-IOV がサポートされるようになりました。GPU が SR-IOV に対応しているか確認するには、NVIDIA のドキュメントを参照してください。

2. 各コンピュートノードで利用可能な各 pGPU デバイスでサポートされている mdev タイプを確認して、利用可能な vGPU タイプを見つけます。

   $ ls /sys/class/mdev_bus/<mdev_device>/mdev_supported_types

   • <mdev_device> を mdev デバイスの PCI アドレス (例: 0000:84:00.0) に置き換えます。たとえば、次のコンピュートノードには 4 つの pGPU があり、各 pGPU は 11 個の同じ vGPU タイプをサポートしています。

     [root@computegpu-0 ~]# ls /sys/class/mdev_bus/0000:84:00.0/mdev_supported_types:
     NVIDIA-35  NVIDIA-36  NVIDIA-37  NVIDIA-38  NVIDIA-39  NVIDIA-40  NVIDIA-41  NVIDIA-42  NVIDIA-43  NVIDIA-44  NVIDIA-45
     [root@computegpu-0 ~]# ls /sys/class/mdev_bus/0000:85:00.0/mdev_supported_types:
     NVIDIA-35  NVIDIA-36  NVIDIA-37  NVIDIA-38  NVIDIA-39  NVIDIA-40  NVIDIA-41  NVIDIA-42  NVIDIA-43  NVIDIA-44  NVIDIA-45
     [root@computegpu-0 ~]# ls /sys/class/mdev_bus/0000:86:00.0/mdev_supported_types:
     NVIDIA-35  NVIDIA-36  NVIDIA-37  NVIDIA-38  NVIDIA-39  NVIDIA-40  NVIDIA-41  NVIDIA-42  NVIDIA-43  NVIDIA-44  NVIDIA-45
     [root@computegpu-0 ~]# ls /sys/class/mdev_bus/0000:87:00.0/mdev_supported_types:
     NVIDIA-35  NVIDIA-36  NVIDIA-37  NVIDIA-38  NVIDIA-39  NVIDIA-40  NVIDIA-41  NVIDIA-42  NVIDIA-43  NVIDIA-44  NVIDIA-45

3. nova-extra-config.yaml という名前の ConfigMap CR を作成または更新し、[devices] の下にあるパラメーターの値を設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      34-nova-vgpu.conf: |
         [devices]
         enabled_mdev_types = nvidia-35, nvidia-36

   ConfigMap オブジェクトの作成の詳細は、config map の作成と使用 を参照してください。

4. オプション: 複数の vGPU タイプを設定するには、サポートされる vGPU タイプを pGPU にマップします。

   [devices]
   enabled_mdev_types = nvidia-35, nvidia-36
   [mdev_nvidia-35]
   device_addresses = 0000:84:00.0,0000:85:00.0
   [vgpu_nvidia-36]
   device_addresses = 0000:86:00.0

   nvidia-35 vGPU タイプは、PCI アドレス 0000:84:00.0 および 0000:85:00.0 にある pGPU によってサポートされます。nvidia-36 vGPU タイプは、PCI アドレス 0000:86:00.0 にある pGPU でのみサポートされます。

5. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイして、ワークステーション上の compute_vgpu_deploy.yaml という名前のファイルに保存します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
      name: compute-vgpu

6. compute_vgpu_deploy.yaml CR で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。この OpenStackDataPlaneNodeSet CR は、vGPU に使用するノードを定義します。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。

   2. DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。

      DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: compute-vgpu
   spec:
     nodeSets:
       - openstack-edpm
       - compute-vgpu
       - ...
       - <nodeSet_name>

   • <nodeSet_name> を、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
7. compute_vgpu_deploy.yaml デプロイメントファイルを保存します。

8. データプレーンをデプロイします。

   $ oc create -f compute_vgpu_deploy.yaml

9. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   
   NAME                    STATUS    MESSAGE
   compute-vgpu   True            Deployed

   ヒント

   デプロイメントの進行状況を追跡するには、get コマンドの最後に -w オプションを追加します。

10. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

    $ oc rsh -n openstack openstackclient
    
    $ openstack hypervisor list

11. オプション: GPU の SR-IOV VF を有効にします。詳細は、NVIDIA DOCS HUB の Preparing virtual function for SRIOV vGPU を参照してください。

手順

1. SR-IOV NVIDIA GPU が特定の仮想 GPU タイプに対して作成できる vGPU の最大数を定義するには、nova-extra-config.yaml という名前の ConfigMap CR を作成または更新します。仮想 GPU タイプの特定の mdev セクションで、enabled_mdev_types パラメーターと max_instances パラメーターの値を設定する必要があります。この設定例は、最大 24 個の仮想 GPU を作成できる A40-2Q NVIDIA GPU タイプ用です。

   apiVersion: v1
   kind: ConfigMap
   metadata:
      name: nova-extra-config
      namespace: openstack
   data:
      36-nova-max-instances.conf: |
         [devices]
         enabled_mdev_types = nvidia-558
   
         [mdev_nvidia-558]
         max_instances = 24

   ConfigMap オブジェクトの作成の詳細は、ノード の config map の作成と使用 を参照してください。

2. nova-extra-config.yaml ファイルを保存します。

3. 新しい OpenStackDataPlaneDeployment CR を作成して、データプレーンノード上のサービスを設定し、データプレーンをデプロイして、ワークステーション上の compute_vgpus_max_instance_deploy.yaml という名前のファイルに保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: compute_ vgpus_max_instance

4. compute_vgpus_max_instance_deploy.yaml で、デプロイするすべての OpenStackDataPlaneNodeSet CR を含めるように nodeSets を指定します。前提条件として選択した OpenStackDataPlaneNodeSet CR が含まれていることを確認してください。

   警告

   デプロイメントに複数のノードセットがある場合、ノードセットと DataPlaneServices がどのように設定されているかにより、nova-extra-config.yaml ConfigMap への変更が複数のノードセットに直接影響する可能性があります。ノードセットが nova-extra-config ConfigMap を使用しているために再設定の影響を受けるかを確認するには、次の手順を実行します。

   1. ノードセットのサービスリストを確認し、nova を指す DataPlaneService の名前を見つけます。DataPlaneService の edpmServiceType フィールドの値が nova に設定されていることを確認します。
   2. DataPlaneService の dataSources リストに nova-extra-config という名前の configMapRef が含まれている場合、このノードセットはこの ConfigMap を使用し、その結果この ConfigMap に加えた設定変更の影響を受けます。影響を受けるノードセットの一部を再設定しない場合は、これらのノードセットの別の ConfigMap を指す新しい DataPlaneService を作成し、必要なノードセットでそのカスタムサービスを使用する必要があります。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: compute-vgpus_max_instance
   spec:
     nodeSets:
       - openstack-edpm
       - compute_vgpus_max_instance
       - ...
       - <nodeSet_name>

   • <nodeSet_name> は、データプレーンデプロイメントに含める OpenStackDataPlaneNodeSet CR の名前に置き換えます。
5. compute_vgpus_max_instance_deploy.yaml デプロイメントファイルを保存します。

6. データプレーンをデプロイします。

   $ oc create -f compute_vgpus_max_instance_deploy.yaml

7. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanenodeset
   NAME           STATUS MESSAGE
   compute_vgpus_max_instance True   Deployed

8. openstackclient のリモートシェルにアクセスし、デプロイされたコンピュートノードがコントロールプレーンに表示されることを確認します。

   $ oc rsh -n openstack openstackclient
   $ openstack hypervisor list

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh openstackclient

2. インスタンスを作成し、NVIDIA デバイスドライバーをインストールします。

   $ openstack server create --flavor <flavor> \
     --image <image> --network <network> \
     --wait myInstanceFromImage

   • <flavor> は、フレーバーの名前または ID に置き換えます。
   • <image> は、イメージの名前または ID に置き換えます。

   • <network> は、ネットワークの名前または ID に置き換えます。必要に応じて、--network オプションを複数回使用して、インスタンスを複数のネットワークに接続することができます。

     インスタンスの作成の詳細は、インスタンスの作成と管理 の インスタンスの作成 を参照してください。

     1. /etc/modprobe.d/blacklist-nouveau.conf ファイルを作成します。

     2. blacklist-nouveau.conf に次の設定を追加して、nouveau デバイスドライバーを無効にします。

        $ blacklist nouveau
        $ options nvidia modeset=0

     3. initramfs を再生成します。

        $ dracut --force
        $ grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline

     4. 製品ポータルから NVIDIA デバイスドライバーをダウンロードしてインストールします。詳細は、NVIDIA DOCS HUB を参照してください。

     5. ノードをリブートします。

        $ sudo reboot

3. GPU パススルーインスタンスに割り当てるすべてのインスタンスに対してこの手順を繰り返します。