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

手順

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

   (overcloud)$ openstack 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. (オプション) フレーバーのメタデータを指定するには、キー/値のペアを使用して必要な属性を設定します。

   (overcloud)$ openstack flavor set \
    --property <key=value> --property <key=value> ... <flavor_name>

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

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

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

     (overcloud)$ openstack 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. アンダークラウドに stack ユーザーとしてログインします。
2. Compute 環境ファイルを開きます。

3. CPU ピニングを必要とするインスタンス用に物理 CPU コアを確保するには、Compute 環境ファイルで NovaComputeCpuDedicatedSet パラメーターを設定します。たとえば、以下の設定では、32 コア CPU を持つコンピュートノードに専用の CPU を設定します。

   parameter_defaults:
     ...
     NovaComputeCpuDedicatedSet: 2-15,18-31
     ...

   詳細は、コンピュートノードでの CPU ピニングの設定 を参照してください。

4. エミュレータースレッド用に物理 CPU コアを確保するには、Compute 環境ファイルで NovaComputeCpuSharedSet パラメーターを設定します。たとえば、以下の設定では、32 コア CPU を持つコンピュートノードに共有の CPU を設定します。

   parameter_defaults:
     ...
     NovaComputeCpuSharedSet: 0,1,16,17
     ...

   注記

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

5. NovaSchedulerEnabledFilters パラメーターにまだ NUMATopologyFilter がなければ、この Compute スケジュールフィルターを追加します。

6. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<compute_environment_file>.yaml

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

   (overcloud)$ openstack 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. /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml ファイルを環境ファイルのディレクトリーにコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml /home/stack/templates/enable-swap.yaml

2. 以下のパラメーターを enable-swap.yaml ファイルに追加して、スワップサイズを設定します。

   parameter_defaults:
     swap_size_megabytes: <swap size in MB>
     swap_path: <full path to location of swap, default: /swap>

3. その他の環境ファイルと共に enable_swap.yaml 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/enable-swap.yaml

手順

1. Compute 環境ファイルを開きます。

2. インスタンスではないプロセス用に各 NUMA ノードで確保するヒュージページのメモリー量を設定します。

   parameter_defaults:
     ComputeParameters:
       NovaReservedHugePages: ["node:0,size:1GB,count:1","node:1,size:1GB,count:1"]

   • 各ノードの size の値を、割り当てられたヒュージページのサイズに置き換えます。以下の有効な値のいずれかに設定します。

     • 2048 (2 MB 用)
     • 1 GB
   • 各ノードの count の値を、NUMA ノードごとに OVS が使用するヒュージページの数に置き換えます。たとえば、Open vSwitch が 4096 のソケットメモリーを使用する場合、この属性を 2 に設定します。

3. コンピュートノードで Huge Page を設定します。

   parameter_defaults:
     ComputeParameters:
       ...
       KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32"

   注記

   複数の Huge Page サイズを設定する場合、初回の起動時に Huge Page フォルダーもマウントする必要があります。詳細は、初回起動時に複数の Huge Page フォルダーをマウントする を参照してください。

4. (オプション) インスタンスが 1 GB のヒュージページを割り当てるのを許可するには、CPU 機能フラグ NovaLibvirtCPUModelExtraFlags を設定して pdpe1gb を指定します。

   parameter_defaults:
     ComputeParameters:
       NovaLibvirtCPUMode: 'custom'
       NovaLibvirtCPUModels: 'Haswell-noTSX'
       NovaLibvirtCPUModelExtraFlags: 'vmx, pdpe1gb'

   注記
   • インスタンスが 2 MB のヒュージページしか要求しない場合、CPU 機能フラグを設定する必要はありません。
   • ホストが 1 GB ヒュージページの割り当てをサポートする場合に限り、インスタンスに 1 GB のヒュージページを割り当てることができます。
   • NovaLibvirtCPUMode が host-model または custom に設定されている場合にのみ、NovaLibvirtCPUModelExtraFlags を pdpe1gb に設定する必要があります。
   • ホストが pdpe1gb をサポートし、NovaLibvirtCPUMode に host-passthrough が使用される場合、NovaLibvirtCPUModelExtraFlags に pdpe1gb を設定する必要はありません。pdpe1gb フラグは Opteron_G4 および Opteron_G5 CPU モデルにのみ含まれ、QEMU がサポートする Intel CPU モデルには含まれません。
   • Microarchitectural Data Sampling (MDS) 等の CPU ハードウェアの問題を軽減するには、他の CPU フラグを設定しなければならない場合があります。詳細は、RHOS Mitigation for MDS ("Microarchitectural Data Sampling") Security Flaws を参照してください。

5. Meltdown に対する保護の適用後にパフォーマンスが失われないようにするには、CPU 機能フラグ NovaLibvirtCPUModelExtraFlags を設定して +pcid を指定します。

   parameter_defaults:
     ComputeParameters:
       NovaLibvirtCPUMode: 'custom'
       NovaLibvirtCPUModels: 'Haswell-noTSX'
       NovaLibvirtCPUModelExtraFlags: 'vmx, pdpe1gb, +pcid'

   ヒント

   詳細は、Reducing the performance impact of Meltdown CVE fixes for OpenStack guests with "PCID" CPU feature flag を参照してください。

6. NovaSchedulerEnabledFilters パラメーターにまだ NUMATopologyFilter がなければ、このフィルターを追加します。

7. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files]  \
     -e /home/stack/templates/<compute_environment_file>.yaml

手順

1. Compute 環境ファイルを開きます。

2. Compute 環境ファイルに以下のパラメーターを追加して、インスタンスの RAM 用に利用可能なホストディスク容量を MiB 単位で設定します。

   parameter_defaults:
     NovaLibvirtFileBackedMemory: 102400

3. オプション: メモリーバッキングファイルを保存するディレクトリーを設定するには、Compute 環境ファイルに QemuMemoryBackingDir パラメーターを設定します。設定しなければ、メモリーバッキングディレクトリーはデフォルトの /var/lib/libvirt/qemu/ram/ に設定されます。

   注記

   デフォルトのディレクトリー (/var/lib/libvirt/qemu/ram/) またはそれより上の階層のディレクトリーに、バッキングストアを配置する必要があります。

   バッキングストアのホストディスクを変更することもできます。詳細は、メモリーバッキングディレクトリーのホストディスクの変更 を参照してください。

4. 更新内容を Compute 環境ファイルに保存します。

5. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/<compute_environment_file>.yaml

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

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. 新しい環境ファイルを作成するか、既存の環境ファイルを開きます。

4. 次の設定を環境ファイルに追加して、単一インスタンスにアタッチできるストレージデバイスの最大数の制限を設定します。

   parameter_defaults:
     ...
     NovaMaxDiskDevicesToAttach: <max_device_limit>
     ...

   • <max_device_limit> を、インスタンスにアタッチできるストレージデバイスの最大数に置き換えます。
5. 更新を環境ファイルに保存します。

6. その他の環境ファイルとともに環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<environment_file>.yaml

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. 共有インスタンスストレージを設定するための環境ファイルを作成します (例: nfs_instance_disk_backend.yaml)。

4. インスタンスファイル用に NFS バックエンドを設定するには、以下の設定を nfs_instance_disk_backend.yaml に追加します。

   parameter_defaults:
     ...
     NovaNfsEnabled: True
     NovaNfsShare: <nfs_share>

   <nfs_share> をインスタンスのファイルストレージ用にマウントする NFS 共有ディレクトリーに置き換えます (例: '192.168.122.1:/export/nova' または '192.168.24.1:/var/nfs')。IPv6 を使用している場合は、二重と単一引用符の両方を使用してください (例: "'[fdd0::1]:/export/nova'")。

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

   parameter_defaults:
     ...
     NovaNfsOptions: 'context=system_u:object_r:nfs_t:s0,<additional_nfs_mount_options>'

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

   $ man 8 mount.

6. 更新を環境ファイルに保存します。

7. その他の環境ファイルと共に新しい環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/nfs_instance_disk_backend.yaml

手順

1. アンダークラウドに stack ユーザーとしてログインします。
2. Compute 環境ファイルを開きます。

3. RBD バックエンドから直接イメージをダウンロードするには、以下の設定を Compute 環境ファイルに追加します。

   parameter_defaults:
     ComputeParameters:
       NovaGlanceEnableRbdDownload: True
       NovaEnableRbdBackend: False
       ...

4. (オプション) Image サービスが複数の Red Hat Ceph Storage バックエンドを使用するように設定されている場合には、Compute 環境ファイルに以下の設定を追加して、イメージをダウンロードする RBD バックエンドを特定します。

   parameter_defaults:
     ComputeParameters:
       NovaGlanceEnableRbdDownload: True
       NovaEnableRbdBackend: False
       NovaGlanceRbdDownloadMultistoreID: <rbd_backend_id>
       ...

   <rbd_backend_id> を GlanceMultistoreConfig 設定のバックエンドを指定するために使用される ID(例: rbd2_store) に置き換えます。

5. 以下の設定を Compute 環境ファイルに追加して Image サービス RBD バックエンドを指定し、Compute サービスが Image サービス RBD バックエンドへの接続を待機する最大期間 (秒単位) を指定します。

   parameter_defaults:
     ComputeExtraConfig:
       nova::config::nova_config:
         glance/rbd_user:
           value: 'glance'
         glance/rbd_pool:
           value: 'images'
         glance/rbd_ceph_conf:
           value: '/etc/ceph/ceph.conf'
         glance/rbd_connect_timeout:
           value: '5'

6. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<compute_environment_file>.yaml

7. Compute サービスが RBD から直接イメージをダウンロードすることを確認するには、インスタンスを作成してインスタンスのデバッグログで Attempting to export RBD image: のエントリーを確認します。

手順

1. Compute 環境ファイルを開きます。

2. スケジューラーが使用するフィルターを NovaSchedulerEnabledFilters パラメーターに追加します。以下に例を示します。

   parameter_defaults:
     NovaSchedulerEnabledFilters:
       - AggregateInstanceExtraSpecsFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter

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

   parameter_defaults:
     ComputeExtraConfig:
       nova::config::nova_config:
         filter_scheduler/weight_classes:
           value: nova.scheduler.weights.all_weighers

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

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

   parameter_defaults:
     ComputeExtraConfig:
       nova::config::nova_config:
         filter_scheduler/weight_classes:
           value: nova.scheduler.weights.all_weighers
         filter_scheduler/ram_weight_multiplier:
           value: 2.0

   ヒント

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

5. 更新内容を Compute 環境ファイルに保存します。

6. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<compute_environment_file>.yaml

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 ファイルを他の環境ファイルとともにスタックに追加し、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
   -e [your environment files] \
   -e /home/stack/templates/provider.yaml

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. Controller、Compute、および ComputePCI ロールを含む、roles_data_pci_passthrough.yaml という名前の新しいロールデータファイルを、オーバークラウドに必要なその他のロールとともに生成します。

   (undercloud)$ openstack overcloud roles \
    generate -o /home/stack/templates/roles_data_pci_passthrough.yaml \
    Compute:ComputePCI Compute Controller

4. roles_data_pci_passthrough.yaml を開き、以下のパラメーターおよびセクションを編集または追加します。

   セクション/パラメーター	現在の値	新しい値
   ロールのコメント	Role: Compute	Role: ComputePCI
   ロール名	Compute	name: ComputePCI
   description	Basic Compute Node role	PCI パススルー用コンピュートノードロール
   HostnameFormatDefault	%stackname%-novacompute-%index%	%stackname%-novacomputepci-%index%
   deprecated_nic_config_name	compute.yaml	compute-pci-passthrough.yaml

5. オーバークラウドの PCI パススルー用コンピュートノードをノード定義のテンプレート node.json または node.yaml に追加して、そのノードを登録します。詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのノードの登録 を参照してください。

6. ノードのハードウェアを検査します。

   (undercloud)$ openstack overcloud node introspect \
    --all-manageable --provide

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ベアメタルノードハードウェアのインベントリーの作成 を参照してください。

7. PCI パススルー用に指定する各ベアメタルノードに、カスタムの PCI パススルーリソースクラスをタグ付けします。

   (undercloud)$ openstack baremetal node set \
    --resource-class baremetal.PCI-PASSTHROUGH <node>

   <node> をベアメタルノードの ID に置き換えてください。

8. ノード定義ファイル overcloud-baremetal-deploy.yaml に ComputePCI ロールを追加し、予測ノード配置、リソースクラス、ネットワークトポロジー、またはノードに割り当てたいその他の属性を定義します。

   - name: Controller
     count: 3
   - name: Compute
     count: 3
   - name: ComputePCI
     count: 1
     defaults:
       resource_class: baremetal.PCI-PASSTHROUGH
       network_config:
         template: /home/stack/templates/nic-config/myRoleTopology.j2 1

   1

   既存のネットワークトポロジーを再利用するか、ロール用の新しいカスタムネットワークインターフェイステンプレートを作成できます。詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの カスタムネットワークインターフェイステンプレート を参照してください。network_config プロパティーを使用してネットワーク定義を定義しない場合、デフォルトのネットワーク定義が使用されます。

   ノード定義ファイルでノード属性を設定するために使用できるプロパティーの詳細は、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。

9. プロビジョニングコマンドを実行して、ロールの新しいノードをプロビジョニングします。

   (undercloud)$ openstack overcloud node provision \
   --stack <stack> \
   [--network-config \]
   --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

   • <stack> を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
   • --network-config オプションの引数を含めて、cli-overcloud-node-network-config.yaml Ansible Playbook にネットワーク定義を提供します。network_config プロパティーを使用してネットワーク定義を定義しない場合、デフォルトのネットワーク定義が使用されます。

10. 別のターミナルでプロビジョニングの進捗をモニタリングします。プロビジョニングが成功すると、ノードの状態が available から active に変わります。

    (undercloud)$ watch openstack baremetal node list

11. --network-config オプションを指定してプロビジョニングコマンドを実行しなかった場合は、network-environment.yaml ファイルで <Role>NetworkConfigTemplate パラメーターを設定して、NIC テンプレートファイルを指すようにします。

    parameter_defaults:
       ComputeNetworkConfigTemplate: /home/stack/templates/nic-configs/compute.j2
       ComputePCINetworkConfigTemplate: /home/stack/templates/nic-configs/<pci_passthrough_net_top>.j2
       ControllerNetworkConfigTemplate: /home/stack/templates/nic-configs/controller.j2

    <pci_passthrough_net_top> を ComputePCI ロールのネットワークトポロジーを含むファイルの名前に置き換えます。たとえば、デフォルトのネットワークトポロジーを使用するには、compute.yaml のようにします。

手順

1. PCI パススルー用にオーバークラウド上のコントローラーノードを設定するには、環境ファイル (例: pci_passthru_controller.yaml) を作成します。

2. pci_passthrough_controller.yaml の NovaSchedulerEnabledFilters パラメーターに PciPassthroughFilter を追加します。

   parameter_defaults:
     NovaSchedulerEnabledFilters:
       - AvailabilityZoneFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter
       - ServerGroupAntiAffinityFilter
       - ServerGroupAffinityFilter
       - PciPassthroughFilter
       - NUMATopologyFilter

3. コントローラーノード上のデバイスの PCI エイリアスを指定するには、以下の設定を pci_passthrough_controller.yaml に追加します。

   parameter_defaults:
     ...
     ControllerExtraConfig:
       nova::pci::aliases:
         - name: "a1"
           product_id: "1572"
           vendor_id: "8086"
           device_type: "type-PF"

   device_type フィールドの設定に関する詳細は、PCI パススルーデバイス種別フィールド を参照してください。

   注記

   nova-api サービスが Controller 以外のロールで実行されている場合は、ControllerExtraConfig を <Role>ExtraConfig の形式でユーザーロールに置き換えます。

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

   parameter_defaults:
     ...
     ControllerExtraConfig:
       nova::pci::aliases:
         - name: "a1"
           product_id: "1572"
           vendor_id: "8086"
           device_type: "type-PF"
           numa_policy: "preferred"

5. PCI パススルー用にオーバークラウド上のコンピュートノードを設定するには、環境ファイル (例: pci_passthrough_compute.yaml) を作成します。

6. コンピュートノード上のデバイスの利用可能な PCI を指定するには、vendor_id および product_id オプションを使用して、インスタンスへのパススルーに使用できる PCI デバイスのプールに、一致するすべての PCI デバイスを追加します。たとえば、すべての Intel® Ethernet Controller X710 デバイスをインスタンスへのパススルーに使用できる PCI デバイスのプールに追加するには、以下の設定を pci_passthrough_compute.yaml に追加します。

   parameter_defaults:
     ...
     ComputePCIParameters:
       NovaPCIPassthrough:
         - vendor_id: "8086"
           product_id: "1572"

   NovaPCIPassthrough の設定方法の詳細は、NovaPCIPassthrough 設定のガイドライン を参照してください。

7. インスタンスの移行およびサイズ変更の操作を行うために、コンピュートノードの PCI エイリアスのコピーを作成する必要があります。PCI パススルー用コンピュートノード上のデバイスの PCI エイリアスを指定するには、以下の設定を pci_passthrough_compute.yaml に追加します。

   parameter_defaults:
     ...
     ComputePCIExtraConfig:
       nova::pci::aliases:
         - name: "a1"
           product_id: "1572"
           vendor_id: "8086"
           device_type: "type-PF"

   注記

   コンピュートノードのエイリアスは、コントローラーノードのエイリアスと同じでなければなりません。したがって、pci_passthrough_controller.yaml の nova::pci::aliases に numa_affinity を追加した場合は、pci_passthrough_compute.yaml の nova::pci::aliases にも追加する必要があります。

8. PCI パススルーをサポートするためにコンピュートノードのサーバー BIOS で IOMMU を有効にするには、pci_passthrough_compute.yaml に KernelArgs パラメーターを追加します。たとえば、Intel IOMMU を有効にするには、以下の KernalArgs 設定を使用します。

   parameter_defaults:
     ...
     ComputePCIParameters:
       KernelArgs: "intel_iommu=on iommu=pt"

   AMD IOMMU を有効にするには、KernelArgs を "amd_iommu=on iommu=pt" に設定します。

   注記

   KernelArgs パラメーターをロールの設定に初めて追加すると、オーバークラウドノードが自動的に再起動されます。必要に応じて、ノードの自動再起動を無効にし、代わりに各オーバークラウドのデプロイ後にノードの再起動を手動で実行できます。詳細は、KernelArgs を定義するための手動でのノード再起動の設定 を参照してください。

9. その他の環境ファイルと共にこれらのカスタム環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -r /home/stack/templates/roles_data_pci_passthrough.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/pci_passthrough_controller.yaml \
     -e /home/stack/templates/pci_passthrough_compute.yaml \
     -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
     -e /home/stack/templates/node-info.yaml

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

    (overcloud)$ openstack flavor set \
     --property "pci_passthrough:alias"="a1:2" device_passthrough

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

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

      (overcloud)$ openstack flavor set \
       --property "hw:pci_numa_affinity_policy"="required" \
       device_passthrough

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

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

      (overcloud)$ 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. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   [stack@director ~]$ source ~/stackrc

3. Controller、Compute、および ComputeVdpa ロールを含む、roles_data_vdpa.yaml という名前の新しいロールデータファイルを生成します。

   (undercloud)$ openstack overcloud roles \
    generate -o /home/stack/templates/roles_data_vdpa.yaml \
    ComputeVdpa Compute Controller

4. VDPA ロールの roles_data_vdpa.yaml ファイルを更新します。

   ###############################################################################
   # Role: ComputeVdpa                                                         #
   ###############################################################################
   - name: ComputeVdpa
     description: |
       VDPA Compute Node role
     CountDefault: 1
     # Create external Neutron bridge
     tags:
       - compute
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_subnet
       Tenant:
         subnet: tenant_subnet
       Storage:
         subnet: storage_subnet
     HostnameFormatDefault: '%stackname%-computevdpa-%index%'
     deprecated_nic_config_name: compute-vdpa.yaml

5. オーバークラウド用の VDPA コンピュートノードをノード定義のテンプレート node.json または node.yaml に追加して、そのノードを登録します。詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのノードの登録 を参照してください。

6. ノードのハードウェアを検査します。

   (undercloud)$ openstack overcloud node introspect \
    --all-manageable --provide

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ベアメタルノードハードウェアのインベントリーの作成 を参照してください。

7. カスタム VDPA リソースクラスを使用して、VDPA 用に指定する各ベアメタルノードにタグを付けます。

   (undercloud)$ openstack baremetal node set \
    --resource-class baremetal.VDPA <node>

   <node> は、ベアメタルノードの名前または UUID に置き換えます。

8. ノード定義ファイル overcloud-baremetal-deploy.yaml に ComputeVdpa ロールを追加し、予測ノード配置、リソースクラス、ネットワークトポロジー、またはノードに割り当てるその他の属性を定義します。

   - name: Controller
     count: 3
   - name: Compute
     count: 3
   - name: ComputeVdpa
     count: 1
       defaults:
         resource_class: baremetal.VDPA
         network_config:
           template: /home/stack/templates/nic-config/<role_topology_file>

   • <role_topology_file> を、ComputeVdpa ロールに使用するトポロジーファイルの名前 (vdpa_net_top.j2 など) に置き換えます。既存のネットワークトポロジーを再利用するか、ロール用の新しいカスタムネットワークインターフェイステンプレートを作成できます。詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの カスタムネットワークインターフェイステンプレート を参照してください。デフォルトのネットワーク定義設定を使用するには、ロール定義に network_config を含めないでください。

   ノード定義ファイルでノード属性を設定するために使用できるプロパティーの詳細は、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。

9. ネットワークインターフェイステンプレート vdpa_net_top.j2 を開き、次の設定を追加して、VDPA 対応のネットワークインターフェイスを OVS ブリッジのメンバーとして指定します。

   - type: ovs_bridge
     name: br-tenant
     members:
       - type: sriov_pf
         name: enp6s0f0
         numvfs: 8
         use_dhcp: false
         vdpa: true
         link_mode: switchdev
       - type: sriov_pf
         name: enp6s0f1
         numvfs: 8
         use_dhcp: false
         vdpa: true
         link_mode: switchdev

10. ロールの新しいノードをプロビジョニングします。

    (undercloud)$ openstack overcloud node provision \
    [--stack <stack>] \
    [--network-config \]
    --output <deployment_file> \
    /home/stack/templates/overcloud-baremetal-deploy.yaml

    • オプション: <stack> をベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。デフォルトは overcloud です。
    • オプション: --network-config オプションの引数を含めて、Ansible Playbook cli-overcloud-node-network-config.yaml にネットワーク定義を提供します。network_config プロパティーを使用してノード定義ファイルにネットワーク定義を定義していない場合は、デフォルトのネットワーク定義が使用されます。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-baremetal-deployed.yaml)。

11. 別のターミナルでプロビジョニングの進捗をモニタリングします。プロビジョニングが成功すると、ノードの状態が available から active に変わります。

    (undercloud)$ watch openstack baremetal node list

12. --network-config オプションを指定せずにプロビジョニングコマンドを実行した場合は、network-environment.yaml ファイルで <Role>NetworkConfigTemplate パラメーターを設定して、NIC テンプレートファイルを指すようにします。

    parameter_defaults:
       ComputeNetworkConfigTemplate: /home/stack/templates/nic-configs/compute.j2
       ComputeVdpaNetworkConfigTemplate: /home/stack/templates/nic-configs/<role_topology_file>
       ControllerNetworkConfigTemplate: /home/stack/templates/nic-configs/controller.j2

    <role_topology_file> を、ComputeVdpa ロールのネットワークトポロジーを含むファイルの名前 (vdpa_net_top.j2 など) に置き換えます。デフォルトのネットワークトポロジーを使用するには、compute.j2 に設定します。

手順

1. VDPA コンピュートノードを設定するための新しいコンピューティング環境ファイル (vdpa_compute.yaml など) を作成します。

2. PciPassthroughFilter と NUMATopologyFilter を、vdpa_compute.yaml の NovaSchedulerEnabledFilters パラメーターに追加します。

   parameter_defaults:
     NovaSchedulerEnabledFilters: ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']

3. NovaPCIPassthrough パラメーターを vdpa_compute.yaml に追加して、コンピュートノード上の VDPA デバイスで使用可能な PCI を指定します。たとえば、NVIDIA® ConnectX®-6 Dx デバイスを、インスタンスへのパススルーに使用できる PCI デバイスのプールに追加するには、次の設定を vdpa_compute.yaml に追加します。

   parameter_defaults:
     ...
     ComputeVdpaParameters:
       NovaPCIPassthrough:
       - vendor_id: "15b3"
         product_id: "101d"
         address: "06:00.0"
         physical_network: "tenant"
       - vendor_id: "15b3"
         product_id: "101d"
         address: "06:00.1"
         physical_network: "tenant"

   NovaPCIPassthrough の設定方法の詳細は、NovaPCIPassthrough 設定のガイドライン を参照してください。

4. KernelArgs パラメーターを vdpa_compute.yaml に追加して、各コンピュートノード BIOS で入出力メモリー管理ユニット (IOMMU) を有効にします。たとえば、Intel Corporation IOMMU を有効にするには、次の KernalArgs 設定を使用します。

   parameter_defaults:
     ...
     ComputeVdpaParameters:
       ...
       KernelArgs: "intel_iommu=on iommu=pt"

   AMD IOMMU を有効にするには、KernelArgs を "amd_iommu=on iommu=pt" に設定します。

   注記

   KernelArgs パラメーターをロールの設定に初めて追加すると、オーバークラウドのデプロイメント中にオーバークラウドノードが自動的に再起動します。必要に応じて、ノードの自動再起動を無効にし、代わりに各オーバークラウドのデプロイ後にノードの再起動を手動で実行できます。詳細は、KernelArgs を定義するための手動でのノード再起動の設定 を参照してください。

5. ネットワーク環境ファイルを開き、次の設定を追加して物理ネットワークを定義します。

   parameter_defaults:
     ...
     NeutronBridgeMappings:
     - <bridge_map_1>
     - <bridge_map_n>
     NeutronTunnelTypes: '<tunnel_types>'
     NeutronNetworkType: '<network_types>'
     NeutronNetworkVLANRanges:
     - <network_vlan_range_1>
     - <network_vlan_range_n>

   • <bridge_map_1>、および <bridge_map_n> までのすべてのブリッジマッピングを、VDPA ブリッジに使用する論理から物理へのブリッジマッピングに置き換えます。たとえば、tenant:br-tenant です。
   • <tunnel_types> を、プロジェクトネットワークのトンネルタイプのコンマ区切りリストに置き換えます。たとえば、geneve です。
   • <network_types> を Networking サービス (neutron) のプロジェクトネットワークタイプのコンマ区切りリストに置き換えます。利用可能なネットワークがすべてなくなるまで、最初に指定した種別が使用されます。その後、次の種別が使用されます。たとえば、geneve,vlan です。
   • <network_vlan_range_1>、および<network_vlan_range_n> までのすべての物理ネットワークと VLAN 範囲を、サポートする ML2 および OVN VLAN マッピング範囲に置き換えます。たとえば、datacentre:1:1000、tenant:100:299。

6. その他の環境ファイルと共にこれらのカスタム環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -r /home/stack/templates/roles_data_vdpa.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/vdpa_compute.yaml \
     -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
     -e /home/stack/templates/node-info.yaml

検証

1. VDPA デバイスでインスタンスを作成します。詳細は、インスタンスの作成と管理 ガイドの VDPA インターフェイスを使用したインスタンスの作成 を参照してください。
2. クラウドユーザーとしてインスタンスにログインします。詳細は、インスタンスの作成と管理 ガイドの インスタンスへの接続 を参照してください。

3. インスタンスから VDPA デバイスにアクセスできることを確認します。

   $ openstack port show vdpa-port

1. vGPU 用のコンピュートノードを指定する。
2. 仮想 GPU 用のコンピュートノードを設定する。
3. オーバークラウドをデプロイする。
4. オプション: vGPU タイプのカスタム特性を作成します。
5. オプション: カスタム GPU インスタンスイメージを作成します。
6. vGPU を持つインスタンスを起動するための vGPU フレーバーを作成します。

手順

1. 新しい特性を作成します。

   (overcloud)$ openstack --os-placement-api-version 1.6 trait \
    create CUSTOM_<TRAIT_NAME>

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

2. 各ホストの既存のリソースプロバイダー特性を収集します。

   (overcloud)$ existing_traits=$(openstack --os-placement-api-version 1.6 resource provider trait list -f value <host_uuid> | sed 's/^/--trait /')

3. 既存のリソースプロバイダー特性に、ホストまたはホストアグリゲートに必要な特性があることを確認します。

   (overcloud)$ echo $existing_traits

4. 必要な特性がまだリソースプロバイダーに追加されていない場合は、既存の特性と必要な特性を各ホストのリソースプロバイダーに追加してください。

   (overcloud)$ openstack --os-placement-api-version 1.6 \
    resource provider trait set $existing_traits \
    --trait CUSTOM_<TRAIT_NAME> \
    <host_uuid>

   • <TRAIT_NAME> を、リソースプロバイダーに追加する特性の名前に置き換えます。必要に応じて、--trait オプションを複数回使用して、さらに特性を追加することができます。

     注記

     このコマンドは、リソースプロバイダーの特性をすべて置き換えます。したがって、ホスト上の既存のリソースプロバイダー特性のリストを取得して、削除されないように再度設定する必要があります。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. source コマンドで overcloudrc 認証情報ファイルを読み込みます。

   $ source ~/overcloudrc

3. 仮想 GPU インスタンスが必要とするハードウェアおよびソフトウェアプロファイルでインスタンスを作成します。

   (overcloud)$ openstack server create --flavor <flavor> \
    --image <image> temp_vgpu_instance

   • <flavor> を、仮想 GPU インスタンスが必要とするハードウェアプロファイルを持つフレーバーの名前または ID に置き換えてください。仮想 GPU フレーバー作成に関する詳細は、Creating a vGPU flavor for instances を参照してください。
   • <image> を、仮想 GPU インスタンスが必要とするソフトウェアプロファイルを持つイメージの名前または ID に置き換えてください。RHEL クラウドイメージのダウンロードについて、詳細は イメージの作成と管理 の RHEL KVM または RHOSP 互換イメージの作成 を参照してください。
4. cloud-user としてインスタンスにログインします。
5. NVIDIA のガイダンス (Licensing an NVIDIA vGPU on Linux by Using a Configuration File) に従って、インスタンス上に gridd.conf NVIDIA GRID ライセンスファイルを作成します。

6. インスタンスに GPU ドライバーをインストールします。NVIDIA ドライバーのインストールについての詳細は、Installing the NVIDIA vGPU Software Graphics Driver on Linux を参照してください。

   注記

   hw_video_model イメージ属性を使用して GPU ドライバーの種別を定義します。仮想 GPU インスタンスのエミュレートされた GPU を無効にする場合は、none を選択します。サポートされているドライバーの詳細は、イメージ設定パラメーター を参照してください。

7. インスタンスのイメージスナップショットを作成します。

   (overcloud)$ openstack server image create \
    --name vgpu_image temp_vgpu_instance

8. オプション: インスタンスを削除します。

手順

1. NVIDIA GPU フレーバーを作成します。以下に例を示します。

   (overcloud)$ openstack flavor create --vcpus 6 \
    --ram 8192 --disk 100 m1.small-gpu

2. vGPU リソースをフレーバーに割り当てます。

   (overcloud)$ openstack flavor set m1.small-gpu \
    --property "resources:VGPU=1"

   注記

   各インスタンスに割り当てられる仮想 GPU は 1 つだけです。

3. オプション: 特定の vGPU タイプ用のフレーバーをカスタマイズするには、必要な特性をフレーバーに追加します。

   (overcloud)$ openstack flavor set m1.small-gpu \
    --property trait:CUSTOM_NVIDIA_11=required

   各 vGPU タイプのカスタムリソースプロバイダー特性を作成する方法については、カスタム vGPU リソースプロバイダー特性の作成 を参照してください。

手順

1. GPU フレーバーおよびイメージを使用して、インスタンスを作成します。以下に例を示します。

   (overcloud)$ openstack server create --flavor m1.small-gpu \
    --image vgpu_image --security-group web --nic net-id=internal0 \
    --key-name lambda vgpu-instance

2. cloud-user としてインスタンスにログインします。

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

   $ lspci -nn | grep <gpu_name>

手順

1. 各パススルーデバイス種別のベンダー ID および製品 ID を確認するには、PCI カードを持つ物理サーバーで以下のコマンドを入力します。

   # lspci -nn | grep -i <gpu_name>

   たとえば、NVIDIA GPU のベンダーおよび製品 ID を確認するには、以下のコマンドを入力します。

   # lspci -nn | grep -i nvidia
   3b:00.0 3D controller [0302]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)
   d8:00.0 3D controller [0302]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1db4] (rev a1)

2. 各 PCI デバイスに Single Root I/O Virtualization (SR-IOV) 機能があるかどうかを確認するには、PCI カードを持つ物理サーバーで以下のコマンドを入力します。

   # lspci -v -s 3b:00.0
   3b:00.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev a1)
             ...
             Capabilities: [bcc] Single Root I/O Virtualization (SR-IOV)
             ...

3. PCI パススルー用にオーバークラウド上のコントローラーノードを設定するには、環境ファイル (例: pci_passthru_controller.yaml) を作成します。

4. pci_passthru_controller.yaml の NovaSchedulerEnabledFilters パラメーターに PciPassthroughFilter を追加します。

   parameter_defaults:
     NovaSchedulerEnabledFilters:
       - AvailabilityZoneFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter
       - ServerGroupAntiAffinityFilter
       - ServerGroupAffinityFilter
       - PciPassthroughFilter
       - NUMATopologyFilter

5. コントローラーノード上のデバイスの PCI エイリアスを指定するには、以下の設定を pci_passthru_controller.yaml に追加します。

   • PCI デバイスに SR-IOV 機能がある場合:

     ControllerExtraConfig:
       nova::pci::aliases:
         - name: "t4"
           product_id: "1eb8"
           vendor_id: "10de"
           device_type: "type-PF"
         - name: "v100"
           product_id: "1db4"
           vendor_id: "10de"
           device_type: "type-PF"

   • PCI デバイスに SR-IOV 機能がない場合:

     ControllerExtraConfig:
       nova::pci::aliases:
         - name: "t4"
           product_id: "1eb8"
           vendor_id: "10de"
         - name: "v100"
           product_id: "1db4"
           vendor_id: "10de"

     device_type フィールドの設定に関する詳細は、PCI passthrough device type field を参照してください。

     注記

     nova-api サービスが Controller 以外のロールで実行されている場合は、ControllerExtraConfig を <Role>ExtraConfig の形式でユーザーロールに置き換えます。

6. PCI パススルー用にオーバークラウド上のコンピュートノードを設定するには、環境ファイル (例: pci_passthru_compute.yaml) を作成します。

7. コンピュートノード上のデバイスで利用可能な PCI を指定するには、以下の設定を pci_passthru_compute.yaml に追加します。

   parameter_defaults:
     NovaPCIPassthrough:
       - vendor_id: "10de"
         product_id: "1eb8"

8. インスタンスの移行およびサイズ変更の操作を行うために、コンピュートノードの PCI エイリアスのコピーを作成する必要があります。コンピュートノード上のデバイスの PCI エイリアスを指定するには、以下の設定を pci_passthru_compute.yaml に追加します。

   • PCI デバイスに SR-IOV 機能がある場合:

     ComputeExtraConfig:
       nova::pci::aliases:
         - name: "t4"
           product_id: "1eb8"
           vendor_id: "10de"
           device_type: "type-PF"
         - name: "v100"
           product_id: "1db4"
           vendor_id: "10de"
           device_type: "type-PF"

   • PCI デバイスに SR-IOV 機能がない場合:

     ComputeExtraConfig:
       nova::pci::aliases:
         - name: "t4"
           product_id: "1eb8"
           vendor_id: "10de"
         - name: "v100"
           product_id: "1db4"
           vendor_id: "10de"

     注記

     コンピュートノードのエイリアスは、コントローラーノードのエイリアスと同じでなければなりません。

9. PCI パススルーをサポートするためにコンピュートノードのサーバー BIOS で IOMMU を有効にするには、pci_passthru_compute.yaml に KernelArgs パラメーターを追加します。

   parameter_defaults:
     ...
     ComputeParameters:
       KernelArgs: "intel_iommu=on iommu=pt"

   注記

   KernelArgs パラメーターをロールの設定に初めて追加すると、オーバークラウドノードが自動的に再起動されます。必要に応じて、ノードの自動再起動を無効にし、代わりに各オーバークラウドのデプロイ後にノードの再起動を手動で実行できます。詳細は、KernelArgs を定義するための手動でのノード再起動の設定 を参照してください。

10. その他の環境ファイルと共にこれらのカスタム環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

    (undercloud)$ openstack overcloud deploy --templates \
      -e [your environment files] \
      -e /home/stack/templates/pci_passthru_controller.yaml \
      -e /home/stack/templates/pci_passthru_compute.yaml

11. PCI デバイスを要求するためのフレーバーを設定します。以下の例では、それぞれベンダー ID および製品 ID が 10de および 13f2 の 2 つのデバイスをリクエストします。

    # openstack flavor set m1.large \
     --property "pci_passthrough:alias"="t4:2"

検証

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

   # openstack server create --flavor m1.large \
    --image <custom_gpu> --wait test-pci

   <custom_gpu> を、必要な GPU ドライバーがインストールされたカスタムインスタンスイメージの名前に置き換えます。

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

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

   $ lspci -nn | grep <gpu_name>

4. NVIDIA System Management Interface のステータスを確認するには、インスタンスから以下のコマンドを入力します。

   $ nvidia-smi

   出力例:

   -----------------------------------------------------------------------------
   | NVIDIA-SMI 440.33.01    Driver Version: 440.33.01    CUDA Version: 10.2     |
   |---------------------------------------------------------------------------+
   | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
   | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
   |===========================================================================|
   |   0  Tesla T4            Off  | 00000000:01:00.0 Off |                    0 |
   | N/A   43C    P0    20W /  70W |      0MiB / 15109MiB |      0%      Default |
   ---------------------------------------------------------------------------
   
   -----------------------------------------------------------------------------
   | Processes:                                                       GPU Memory |
   |  GPU       PID   Type   Process name                             Usage      |
   |=============================================================================|
   |  No running processes found                                                 |
   -----------------------------------------------------------------------------

手順

1. Compute 環境ファイルを開きます。

2. インスタンスの起動時に常にコンフィグドライブをアタッチするには、以下のパラメーターを True に設定します。

   parameter_defaults:
     ComputeExtraConfig:
       nova::compute::force_config_drive: 'true'

3. (オプション) コンフィグドライブの形式をデフォルト値の iso9660 から vfat に変更するには、設定に config_drive_format パラメーターを追加します。

   parameter_defaults:
     ComputeExtraConfig:
       nova::compute::force_config_drive: 'true'
       nova::compute::config_drive_format: vfat

4. 更新内容を Compute 環境ファイルに保存します。

5. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<compute_environment_file>.yaml \

検証

1. インスタンスを作成します。

   (overcloud)$ openstack server create --flavor m1.tiny \
    --image cirros test-config-drive-instance

2. インスタンスにログインします。

3. コンフィグドライブをマウントします。

   • インスタンスの OS が udev を使用する場合:

     # mkdir -p /mnt/config
     # mount /dev/disk/by-label/config-2 /mnt/config

   • インスタンスの OS が udev を使用しない場合は、まずコンフィグドライブに対応するブロックデバイスを特定する必要があります。

     # blkid -t LABEL="config-2" -odevice
     /dev/vdb
     # mkdir -p /mnt/config
     # mount /dev/vdb /mnt/config

4. マウントされたコンフィグドライブディレクトリー mnt/config/openstack/{version}/ で、メタデータのファイルを検査します。

手順

1. Compute 環境ファイルを開きます。

2. ベンダーデータプロバイダーモジュールに DynamicJSON を追加します。

   parameter_defaults:
     ControllerExtraConfig:
      nova::vendordata::vendordata_providers:
         - DynamicJSON

3. メタデータを生成するためにアクセスする REST サービスを指定します。必要な数だけ目的の REST サービスを指定することができます。以下に例を示します。

   parameter_defaults:
      ControllerExtraConfig:
      nova::vendordata::vendordata_providers:
         - DynamicJSON
         nova::vendordata::vendordata_dynamic_targets:
           "target1@http://127.0.0.1:125"
         nova::vendordata::vendordata_dynamic_targets:
           "target2@http://127.0.0.1:126"

   Compute サービスは設定されたターゲットサービスから取得したメタデータが含まれる JSON ファイル vendordata2.json を生成し、それをコンフィグドライブディレクトリーに保存します。

   注記

   ターゲットサービスに同じ名前を複数回使用しないでください。

4. 更新内容を Compute 環境ファイルに保存します。

5. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/<compute_environment_file>.yaml

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. カスタム環境ファイル (kernelargs_manual_reboot.yaml など) で KernelArgsDeferReboot ロールパラメーターを有効にします。

   parameter_defaults:
     <Role>Parameters:
       KernelArgsDeferReboot: True

4. その他の環境ファイルと共にこれらのカスタム環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /home/stack/templates/kernelargs_manual_reboot.yaml

5. コンピュートノードのリストを取得して、再起動するノードのホスト名を特定します。

   (undercloud)$ source ~/overcloudrc
   (overcloud)$ openstack compute service list

6. 再起動するコンピュートノードで Compute サービスを無効にして、Compute スケジューラーが新しいインスタンスをノードに割り当てないようにします。

   (overcloud)$ openstack compute service set <node> nova-compute --disable

   <node> を、Compute サービスを無効にするノードのホスト名に置き換えます。

7. 移行するコンピュートノードでホストされているインスタンスのリストを取得します。

   (overcloud)$ openstack server list --host <node_UUID> --all-projects

8. インスタンスを別の Compute ノードに移行します。インスタンスの移行については、コンピュートノード間での仮想マシンインスタンスの移行 を参照してください。
9. 再起動するノードにログインします。

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

    [tripleo-admin@overcloud-compute-0 ~]$ sudo reboot

11. ノードがブートするまで待ちます。

12. Compute ノードを再度有効にします。

    (overcloud)$ openstack compute service set <node_UUID>  nova-compute --enable

13. Compute ノードが有効であることを確認します。

    (overcloud)$ openstack compute service list

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. Compute 環境ファイルを開きます。

4. インスタンスへの VNC コンソール接続に使用する最小プロトコルバージョンを設定します。

   parameter_defaults:
     ...
     NovaVNCProxySSLMinimumVersion: <version>

   <version> を、許可される最小の SSL/TLS プロトコルバージョンに置き換えます。以下の有効な値のいずれかに設定します。

   • default: 基礎となるシステム OpenSSL のデフォルトを使用します。

   • tlsv1_1: 新しいバージョンをサポートしていないクライアントがある場合に使用します。

     注記

     TLS 1.0 および TLS 1.1 は RHEL 8 で廃止され、RHEL 9 ではサポートされていません。

   • tlsv1_2: インスタンスへの VNC コンソール接続に使用する SSL/TLS 暗号を設定する場合に使用します。
   • tlsv1_3: TLSv1.3 の標準暗号ライブラリーを使用する場合に使用します。NovaVNCProxySSLCiphers パラメーターの設定は無視されます。

5. 使用可能な最小の SSL/TLS プロトコルバージョンを tlsv1_2 に設定する場合は、インスタンスへの VNC コンソール接続に使用する SSL/TLS 暗号を設定します。

   parameter_defaults:
     NovaVNCProxySSLCiphers: <ciphers>

   <ciphers> を、許可する暗号スイートのコロン区切りリストに置き換えます。openssl から利用可能な暗号のリストを取得します。

6. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files]  \
     -e /home/stack/templates/<compute_environment_file>.yaml

1. vTPM デバイスを持つンスタンスのサポートを有効にし、オーバークラウドをデプロイします。
2. vTPM デバイスを持つインスタンスを起動するためのフレーバーまたはイメージを作成します。

手順

1. Compute 環境ファイルを開きます。

2. 追加または変更する cron ジョブを制御する heat パラメーターを追加します。たとえば、シャドウテーブルをアーカイブ直後にパージするには、次のパラメーターを "True" に設定します。

   parameter_defaults:
     ...
     NovaCronArchiveDeleteRowsPurge: True

   データベースの cron ジョブを管理する heat パラメーターの完全リストは、Configuration options for the Compute service automated database management を参照してください。

3. 更新内容を Compute 環境ファイルに保存します。

4. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/<compute_environment_file>.yaml

手順

1. 移行元コンピュートノードのホスト名および移行先コンピュートノードのホスト名を特定します。

   (undercloud)$ source ~/overcloudrc
   (overcloud)$ openstack compute service list

2. 移行元コンピュートノード上のインスタンスをリスト表示し、移行するインスタンスの ID を特定します。

   (overcloud)$ openstack server list --host <source> --all-projects

   <source> を移行元コンピュートノードの名前または ID に置き換えてください。

3. オプション: ノードのメンテナンスを行うためにインスタンスを移行元コンピュートノードから移行する場合、ノードを無効にして、メンテナンス中にスケジューラーがノードに新規インスタンスを割り当てるのを防ぐ必要があります。

   (overcloud)$ openstack compute service set <source> nova-compute --disable

   <source> を移行元コンピュートノードのホスト名に置き換えてください。

手順

1. インスタンスのコールドマイグレーションを行うには、以下のコマンドを入力してインスタンスの電源をオフにして移動します。

   (overcloud)$ openstack server migrate <instance> --wait

   • <instance> を移行するインスタンスの名前または ID に置き換えてください。
   • ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。
2. 移行が完了するまで待ちます。インスタンスの移行が完了するのを待つ間、移行のステータスを確認することができます。詳細は、Checking migration status を参照してください。

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

   (overcloud)$ openstack server list --all-projects

   ステータスが "VERIFY_RESIZE" と表示される場合は、移行を確認する、または元に戻す必要があることを示しています。

   • 予想どおりに機能している場合は、移行を確認します。

     (overcloud)$ openstack server resize --confirm <instance>

     <instance> を移行するインスタンスの名前または ID に置き換えてください。ステータスが "ACTIVE" と表示される場合は、インスタンスを使用する準備が整っていることを示しています。

   • 予想どおりに機能していない場合は、移行を元に戻します。

     (overcloud)$ openstack server resize --revert <instance>

     <instance> をインスタンスの名前または ID に置き換えてください。

4. インスタンスを再起動します。

   (overcloud)$ openstack server start <instance>

   <instance> をインスタンスの名前または ID に置き換えてください。

5. オプション: メンテナンスのために移行元コンピュートノードを無効にした場合は、新規インスタンスがノードに割り当てられるようにノードを再度有効にする必要があります。

   (overcloud)$ openstack compute service set <source> nova-compute --enable

   <source> を移行元コンピュートノードのホスト名に置き換えてください。

手順

1. インスタンスのライブマイグレーションを行うには、インスタンスおよび移行先コンピュートノードを指定します。

   (overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait

   • <instance> をインスタンスの名前または ID に置き換えてください。

   • <dest> を移行先コンピュートノードの名前または ID に置き換えてください。

     注記

     openstack server migrate コマンドは、共有ストレージを持つインスタンスの移行が対象です。これがデフォルトの設定です。ローカルに確保されたボリュームを移行するには、--block-migration フラグを指定します。

     (overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait --block-migration

2. インスタンスが移行されていることを確認します。

   (overcloud)$ openstack server show <instance>
   
   +----------------------+--------------------------------------+
   | Field                | Value                                |
   +----------------------+--------------------------------------+
   | ...                  | ...                                  |
   | status               | MIGRATING                            |
   | ...                  | ...                                  |
   +----------------------+--------------------------------------+

3. 移行が完了するまで待ちます。インスタンスの移行が完了するのを待つ間、移行のステータスを確認することができます。詳細は、Checking migration status を参照してください。

4. インスタンスのステータスをチェックして、移行が成功したかどうかを確認します。

   (overcloud)$ openstack server list --host <dest> --all-projects

   <dest> を移行先コンピュートノードの名前または ID に置き換えてください。

5. オプション: メンテナンスのために移行元コンピュートノードを無効にした場合は、新規インスタンスがノードに割り当てられるようにノードを再度有効にする必要があります。

   (overcloud)$ openstack compute service set <source> nova-compute --enable

   <source> を移行元コンピュートノードのホスト名に置き換えてください。

1. Queued: Compute サービスはインスタンス移行の要求を受け入れ、移行は保留中です。
2. Preparing: Compute サービスはインスタンス移行の準備中です。
3. Running: Compute サービスはインスタンスを移行中です。
4. Post-migrating: Compute サービスはインスタンスを移行先コンピュートノードにビルドし、移行元コンピュートノードのリソースを解放しています。
5. Completed: Compute サービスはインスタンスの移行を完了し、移行元コンピュートノードのリソース解放を終了しています。

手順

1. インスタンスの移行 ID のリストを取得します。

   $ openstack server migration list --server <instance>
   +----+-------------+-----------  (...)
   | Id | Source Node | Dest Node | (...)
   +----+-------------+-----------+ (...)
   | 2  | -           | -         | (...)
   +----+-------------+-----------+ (...)

   <instance> をインスタンスの名前または ID に置き換えてください。

2. 移行のステータスを表示します。

   $ openstack server migration show <instance> <migration_id>

   • <instance> をインスタンスの名前または ID に置き換えてください。

   • <migration_id> を移行の ID に置き換えてください。

     openstack server migration show コマンドを実行すると、次の出力例が返されます。

     +------------------------+--------------------------------------+
     | Property               | Value                                |
     +------------------------+--------------------------------------+
     | created_at             | 2017-03-08T02:53:06.000000           |
     | dest_compute           | controller                           |
     | dest_host              | -                                    |
     | dest_node              | -                                    |
     | disk_processed_bytes   | 0                                    |
     | disk_remaining_bytes   | 0                                    |
     | disk_total_bytes       | 0                                    |
     | id                     | 2                                    |
     | memory_processed_bytes | 65502513                             |
     | memory_remaining_bytes | 786427904                            |
     | memory_total_bytes     | 1091379200                           |
     | server_uuid            | d1df1b5a-70c4-4fed-98b7-423362f2c47c |
     | source_compute         | compute2                             |
     | source_node            | -                                    |
     | status                 | running                              |
     | updated_at             | 2017-03-08T02:53:47.000000           |
     +------------------------+--------------------------------------+

     ヒント

     Compute サービスは、コピーする残りのメモリーのバイト数によって移行の進捗を測定します。時間が経過してもこの数字が減少しない場合、移行を完了することができず、Compute サービスは移行を中止する可能性があります。