第7章 パフォーマンス改善のためのコンピュートノードの設定
インスタンスのスケジューリングおよび配置を設定して、最大のパフォーマンスを得ることができます。そのためには、NFV や高性能コンピューティング (HPC) などの特化されたワークロードを対象にするカスタムフレーバーを作成します。
以下の機能を使用して、最大のパフォーマンスを得るためにインスタンスを調整します。
- CPU ピニング: 仮想 CPU を物理 CPU に固定します。
- エミュレータースレッド: インスタンスに関連付けられたエミュレータースレッドを物理 CPU に固定します。
- ヒュージページ: 通常のメモリー (4 KB ページ) とヒュージページ (2 MB または 1 GB ページ) の両方について、インスタンスのメモリー割り当てポリシーを調整します。
これらの機能のいずれかを設定すると、インスタンス上に NUMA トポロジーが存在しない場合、暗黙的な NUMA トポロジーが作成されます。
7.1. コンピュートノードでの CPU ピニングの設定
専用のホスト CPU 上で実行されるようにインスタンスを設定することができます。CPU ピニングを有効にすると、暗示的にゲスト NUMA トポロジーが設定されます。この NUMA トポロジーの各 NUMA ノードは、個別のホストの NUMA ノードにマッピングされます。NUMA の詳細は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 の「 CPU と NUMA ノード 」を参照してください。
ホストシステムの NUMA トポロジーに基づいて、コンピュートノードでの CPU ピニングを設定します。効率を高めるために、全 NUMA ノードにわたって、CPU コアの一部をホストのプロセス用に確保します。残りの CPU コアをインスタンスの管理に割り当てます。
8 つの CPU コアを 2 つの NUMA ノードに分散する例を以下に示します。
NUMA ノード 0 | NUMA ノード 1 | ||
コア 0 | コア 1 | コア 2 | コア 3 |
コア 4 | コア 5 | コア 6 | コア 7 |
同じコンピュートノードで、専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンスをスケジューリングすることができます。以下の手順では、コア 0 および 4 をホストのプロセス用に、コア 1、3、5、および 7 を CPU ピニングが必要なインスタンス用に、そしてコア 2 および 6 を CPU ピニングが不要なフローティングインスタンス用に、それぞれ確保します。
ホストが同時マルチスレッド (SMT) をサポートする場合、スレッドシブリングを専用または共有セットのいずれかにグルーピングします。スレッドシブリングは共通のハードウェアを共有するため、あるスレッドシブリング上で動作しているプロセスが、他のスレッドシブリングのパフォーマンスに影響を与える可能性があります。
たとえば、ホストは、4 つのデュアルコア CPU (0、1、2、および 3) を識別し、SMT をサポートします。この 4 つの CPU に対して、スレッドシブリングのペアが 2 つあります。
- スレッドシブリング 1: CPU 0 および 2
- スレッドシブリング 2: CPU 1 および 3
このシナリオでは、CPU 0 および 1 を専用として、2 および 3 を共有として割り当てないでください。そうではなく、0 および 2 を専用として、1 および 3 を共有として割り当てる必要があります。
前提条件
- コンピュートノードの NUMA トポロジーを把握している。詳しくは、『 ネットワーク機能仮想化( NFV)のプランニングおよび設定ガイド』 の「NUMA ノードのトポロジー についての理解」を参照してください。
手順
各コンピュートノードにおいて、Compute 環境ファイルの
NovaComputeCpuDedicatedSet
設定を定義して、専用のインスタンス用に物理 CPU コアを確保します。NovaComputeCpuDedicatedSet: 1,3,5,7
各コンピュートノードにおいて、Compute 環境ファイルの
NovaComputeCpuSharedSet
設定を定義して、共有のインスタンス用に物理 CPU コアを確保します。NovaComputeCpuSharedSet: 2,6
同じファイルの
NovaReservedHostMemory
オプションを、ホストのプロセス用に確保するメモリー容量に設定します。たとえば、512 MB を確保する場合、設定は以下のようになります。NovaReservedHostMemory: 512
インスタンス用に確保した CPU コアでホストプロセスが実行されないようにするには、各 Compute 環境ファイルの
IsolCpusList
パラメーターに、インスタンス用に確保した CPU コアを設定します。スペース区切りの CPU インデックスのリストまたは範囲を使用して、IsolCpusList
パラメーターの値を指定します。IsolCpusList: 1 2 3 5 6 7
-
NUMA トポロジーに基づいてホストを除外するには、各 Compute 環境ファイルの
NovaSchedulerDefaultFilters
パラメーターにNUMATopologyFilter
を追加します。 この設定を適用するには、デプロイメントコマンドに環境ファイルを追加して、オーバークラウドをデプロイします。
(undercloud) $ openstack overcloud deploy --templates \ -e [your environment files] -e /home/stack/templates/<compute_environment_file>.yaml
7.1.1. CPU ピニング設定のアップグレード
Red Hat OpenStack Platform (RHOSP) 16 以降、専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンス種別を別個のホスト上で実行するのに、ホストアグリゲートを使用する必要はありません。また、[DEFAULT] reserved_host_cpus
設定オプションは不要になり、未設定にすることができます。
CPU ピニングの設定を以前のバージョンの RHOSP からアップグレードするには、以下の手順を実施します。
-
これまでピニングされたインスタンス用に使用されていたホストの場合には、
NovaVcpuPinSet
の値をNovaComputeCpuDedicatedSet
に変更します。 -
これまでピニングされていないインスタンス用に使用されていたホストの場合には、
NovaVcpuPinSet
の値をNovaComputeCpuSharedSet
に変更します。 -
NovaVcpuPinSet
に値が設定されていない場合には、実行中のインスタンスの種別に応じて、すべてのホストコアをNovaComputeCpuDedicatedSet
またはNovaComputeCpuSharedSet
のどちらかに割り当てる必要があります。
アップグレードが完了したら、同一のホストで両方のオプションの設定を始めることができます。ただし、そのためには、すべてのインスタンスをホストから移行する必要があります。ピニングされていないインスタンス用のコアが NovaComputeCpuSharedSet
に記載されていない場合や、ピニングされたインスタンス用のコアが NovaComputeCpuDedicatedSet
に記載されていない場合は、Compute サービスを起動することができないためです。
7.1.2. CPU ピニングが設定されたインスタンスの起動
専用 CPU ポリシーのフレーバーを指定すると、CPU ピニングを使用するインスタンスを起動することができます。
前提条件
- ホストで同時マルチスレッド (SMT) が有効である。
- コンピュートノードが CPU ピニングを許可するように設定されている。詳しくは、「コンピュートノードでの CPU ピニングの設定」を参照してください。
手順
CPU ピニングを要求するインスタンス用のフレーバーを作成します。
(overcloud) $ openstack flavor create --ram <size-mb> --disk <size-gb> --vcpus <no_reserved_vcpus> pinned_cpus
ピニングされた CPU を要求するには、フレーバーの
hw:cpu_policy
属性をdedicated
に設定します。(overcloud) $ openstack flavor set --property hw:cpu_policy=dedicated pinned_cpus
それぞれの仮想 CPU をスレッドシブリングに配置するには、フレーバーの
hw:cpu_thread_policy
属性をrequire
に設定します。(overcloud) $ openstack flavor set --property hw:cpu_thread_policy=require pinned_cpus
注記-
ホストに SMT アーキテクチャーがない場合や、スレッドシブリングが利用可能な CPU コアが十分にない場合には、スケジューリングが失敗します。これを回避するには、
hw:cpu_thread_policy
をrequire
ではなくprefer
に設定します。デフォルトのprefer
ポリシーでは、スレッドシブリングが利用可能な場合には、必ず使用されます。 -
cpu_thread_policy=isolate
を使用する場合は、SMT を無効にするか、SMT をサポートしないプラットフォームを使用する必要があります。
-
ホストに SMT アーキテクチャーがない場合や、スレッドシブリングが利用可能な CPU コアが十分にない場合には、スケジューリングが失敗します。これを回避するには、
新しいフレーバーを使用してインスタンスを作成します。
(overcloud) $ openstack server create --flavor pinned_cpus --image <image> pinned_cpu_instance
新規インスタンスが正しく配置されていることを確認するには、以下のコマンドを実行し、その出力で
OS-EXT-SRV-ATTR:hypervisor_hostname
の箇所を確認します。(overcloud) $ openstack server show pinned_cpu_instance
7.1.3. フローティングインスタンスの起動
共有 CPU ポリシーのフレーバーを指定すると、フローティング CPU に配置されているインスタンスを起動することができます。
前提条件
- コンピュートノードがフローティングインスタンス用に物理 CPU コアを確保するように設定されている。詳しくは、「コンピュートノードでの CPU ピニングの設定」を参照してください。
手順
CPU ピニングを要求しないインスタンス用のフレーバーを作成します。
(overcloud) $ openstack flavor create --ram <size-mb> --disk <size-gb> --vcpus <no_reserved_vcpus> floating_cpus
フローティング CPU を要求するには、フレーバーの
hw:cpu_policy
属性をshared
に設定します。(overcloud) $ openstack flavor set --property hw:cpu_policy=shared floating_cpus
新しいフレーバーを使用してインスタンスを作成します。
(overcloud) $ openstack server create --flavor floating_cpus --image <image> floating_cpu_instance
新規インスタンスが正しく配置されていることを確認するには、以下のコマンドを実行し、その出力で
OS-EXT-SRV-ATTR:hypervisor_hostname
の箇所を確認します。(overcloud) $ openstack server show floating_cpu_instance