第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 ノードに分散する例を以下に示します。

表7.1 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 ノードのトポロジー についての理解」を参照してください。

手順

  1. 各コンピュートノードにおいて、Compute 環境ファイルの NovaComputeCpuDedicatedSet 設定を定義して、専用のインスタンス用に物理 CPU コアを確保します。

    NovaComputeCpuDedicatedSet: 1,3,5,7
  2. 各コンピュートノードにおいて、Compute 環境ファイルの NovaComputeCpuSharedSet 設定を定義して、共有のインスタンス用に物理 CPU コアを確保します。

    NovaComputeCpuSharedSet: 2,6
  3. 同じファイルの NovaReservedHostMemory オプションを、ホストのプロセス用に確保するメモリー容量に設定します。たとえば、512 MB を確保する場合、設定は以下のようになります。

    NovaReservedHostMemory: 512
  4. インスタンス用に確保した CPU コアでホストプロセスが実行されないようにするには、各 Compute 環境ファイルの IsolCpusList パラメーターに、インスタンス用に確保した CPU コアを設定します。スペース区切りの CPU インデックスのリストまたは範囲を使用して、IsolCpusList パラメーターの値を指定します。

    IsolCpusList: 1 2 3 5 6 7
  5. NUMA トポロジーに基づいてホストを除外するには、各 Compute 環境ファイルの NovaSchedulerDefaultFilters パラメーターに NUMATopologyFilter を追加します。
  6. この設定を適用するには、デプロイメントコマンドに環境ファイルを追加して、オーバークラウドをデプロイします。

    (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 ピニングを使用するインスタンスを起動することができます。

前提条件

手順

  1. CPU ピニングを要求するインスタンス用のフレーバーを作成します。

    (overcloud) $ openstack flavor create --ram <size-mb> --disk <size-gb> --vcpus <no_reserved_vcpus> pinned_cpus
  2. ピニングされた CPU を要求するには、フレーバーの hw:cpu_policy 属性を dedicated に設定します。

    (overcloud) $ openstack flavor set --property hw:cpu_policy=dedicated pinned_cpus
  3. それぞれの仮想 CPU をスレッドシブリングに配置するには、フレーバーの hw:cpu_thread_policy 属性を require に設定します。

    (overcloud) $ openstack flavor set --property hw:cpu_thread_policy=require pinned_cpus
    注記
    • ホストに SMT アーキテクチャーがない場合や、スレッドシブリングが利用可能な CPU コアが十分にない場合には、スケジューリングが失敗します。これを回避するには、hw:cpu_thread_policyrequire ではなく prefer に設定します。デフォルトの prefer ポリシーでは、スレッドシブリングが利用可能な場合には、必ず使用されます。
    • cpu_thread_policy=isolate を使用する場合は、SMT を無効にするか、SMT をサポートしないプラットフォームを使用する必要があります。
  4. 新しいフレーバーを使用してインスタンスを作成します。

    (overcloud) $ openstack server create --flavor pinned_cpus --image <image> pinned_cpu_instance
  5. 新規インスタンスが正しく配置されていることを確認するには、以下のコマンドを実行し、その出力で OS-EXT-SRV-ATTR:hypervisor_hostname の箇所を確認します。

    (overcloud) $ openstack server show pinned_cpu_instance

7.1.3. フローティングインスタンスの起動

共有 CPU ポリシーのフレーバーを指定すると、フローティング CPU に配置されているインスタンスを起動することができます。

前提条件

手順

  1. CPU ピニングを要求しないインスタンス用のフレーバーを作成します。

    (overcloud) $ openstack flavor create --ram <size-mb> --disk <size-gb> --vcpus <no_reserved_vcpus> floating_cpus
  2. フローティング CPU を要求するには、フレーバーの hw:cpu_policy 属性を shared に設定します。

    (overcloud) $ openstack flavor set --property hw:cpu_policy=shared floating_cpus
  3. 新しいフレーバーを使用してインスタンスを作成します。

    (overcloud) $ openstack server create --flavor floating_cpus --image <image> floating_cpu_instance
  4. 新規インスタンスが正しく配置されていることを確認するには、以下のコマンドを実行し、その出力で OS-EXT-SRV-ATTR:hypervisor_hostname の箇所を確認します。

    (overcloud) $ openstack server show floating_cpu_instance