Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第8章 パフォーマンス改善のためのコンピュートノードの設定

インスタンスのスケジューリングおよび配置を設定して、最大のパフォーマンスを得ることができます。そのためには、ネットワーク機能仮想化 (NFV) や高性能コンピューティング (HPC) などの特化されたワークロードを対象にするカスタムフレーバーを作成します。

以下の機能を使用して、最大のパフォーマンスを得るためにインスタンスを調整します。

  • CPU ピニング: 仮想 CPU を物理 CPU に固定します。
  • エミュレータースレッド: インスタンスに関連付けられたエミュレータースレッドを物理 CPU に固定します。
  • ヒュージページ: 通常のメモリー (4 KB ページ) とヒュージページ (2 MB または 1 GB ページ) の両方について、インスタンスのメモリー割り当てポリシーを調整します。
注記

これらの機能のいずれかを設定すると、インスタンス上に NUMA トポロジーが存在しない場合、暗黙的な NUMA トポロジーが作成されます。

NFV およびハイパーコンバージドインフラストラクチャー (HCI) のデプロイメントに関する詳細は、『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』「HCI および DPDK を使用するオーバークラウドのデプロイ」を参照してください。

8.1. NUMA ノードを使用する CPU ピニングの設定

本章では、NUMA トポロジーのサポートを使用して、NUMA アーキテクチャーを持つシステム上で OpenStack 環境を設定する方法について説明します。本章で説明する手順で、仮想マシン (VM) を専用の CPU コアに固定する方法を説明します。これにより、スケジューリング機能および仮想マシンのパフォーマンスが向上します。

ヒント

NUMA についての予備知識は、「What is NUMA and how does it work on Linux ?」のアーティクルに記載されています。

以下の図では、2 つのノードからなる NUMA システムの例と、CPU コアとメモリーページを利用可能にする方法の例が提供されています。

OpenStack NUMA Topology 39825 0416 ADF
注記

Interconnect 経由で利用可能なリモートのメモリーには、NUMA ノード 0 からの VM1 に NUMA ノード 1 の CPU コアがある場合 のみ アクセスすることができます。このような場合には、NUMA ノード 1 のメモリーは、VM1 の 3 番目の CPU コアのローカルとして機能しますが (例: 上記の図では、VM1 は CPU4 が割り当てられています)、同じ仮想マシンの別の CPU コアに対してはリモートメモリーとして機能します。

libvirt での NUMA のチューニングについての詳しい情報は、『仮想化のチューニングと最適化ガイド』を参照してください。

8.1.1. コンピュートノードの設定

具体的な設定は、お使いのホストシステムの NUMA トポロジーによって異なります。ただし、全 NUMA ノードにわたって、CPU コアの一部をホストのプロセス用に確保し、それ以外の CPU コアに仮想マシン (VM) を処理させる必要があります。以下の例で、2 つの NUMA ノード間で 8 つの CPU コアを均等に分散させる場合のレイアウトを説明します。

表8.1 NUMA トポロジーの例

 ノード 0ノード 1

ホストのプロセス

コア 0

コア 1

コア 4

コア 5

インスタンス

コア 2

コア 3

コア 6

コア 7

注記

標準的な作業負荷がかかった状態におけるホストのパフォーマンスを観察した上で、ホストのプロセス用に確保するコア数を決定します。

手順

  1. Compute 環境ファイルの NovaVcpuPinSet 設定を定義して、仮想マシン用に CPU コアを確保します。

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

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

    IsolCpusList: 2 3 6 7
    注記

    IsolCpusList パラメーターと isolcpus パラメーターは、目的が異なる別個のパラメーターです。

    • IsolCpusList: この heat パラメーターを使用して、cpu-partitioning プロファイルを使用して tuned.confisolated_cores を設定します。
    • isolcpus: このカーネルブートパラメーターは、KernelArgs heat パラメーターを使用して設定します。

    IsolCpusList パラメーターと isolcpus パラメーターを取り違えて使用しないでください。

    ヒント

    NFV 以外のロールで IsolCpusList を設定するには、KernelArgs および IsolCpusList を設定し、オーバークラウドデプロイメントに /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml 環境ファイルを追加する必要があります。config-download を使用してデプロイを実施し、NFV 以外のロールで IsolCpusList を設定する場合は、Red Hat のサポートにお問い合わせください。

  4. この設定を適用するには、オーバークラウドをデプロイします。

    (undercloud) $ openstack overcloud deploy --templates \
      -e /home/stack/templates/<compute_environment_file>.yaml

8.1.2. 専用の物理 CPU で実行されるエミュレータースレッドの設定

Compute のスケジューラーは、CPU リソースの使用状況を確認して、フレーバーの仮想 CPU (vCPU) 数に基づいてインスタンスを配置します。ゲストの代わりにホストで実行されるハイパーバイザー操作は数多くあります。たとえば、QEMU では、QEMU のメインイベントループや、非同期 I/O 操作などに使用されるスレッドがあるので、それらを考慮に入れて、別々にスケジュールする必要があります。

libvirt ドライバーは、KVM 向けの一般的な配置ポリシーを実装しています。このポリシーでは、仮想 CPU を実行しているのと同じ複数の物理 CPU (pCPU) 全体にわたって、QEMU エミュレータースレッドをフローティングさせることができます。これにより、エミュレータースレッドは、仮想 CPU 操作から借りた時間を使用することになります。ゲストに専用の仮想 CPU 割り当てが必要な場合には、エミュレータースレッドに 1 つまたは複数の物理 CPU を割り当てる必要があります。そのため、スケジューラーに対して、ゲストに関連する可能性のある他の CPU の用途を記述して、配置中にそれ計算に入れる必要があります。

注記

NFV デプロイメントでは、パケットロスを回避するために、仮想 CPU が割り込まれないようにする必要があります。

フレーバー上でエミュレータースレッドの配置ポリシーを有効にする前に、以下に示すように heat パラメーターが定義されていることを確認する必要があります。

  • NovaComputeCpuSharedSet: このパラメーターには、エミュレータースレッドを実行するように定義された CPU の一覧を設定します。
  • NovaSchedulerDefaultFilters: 定義するフィルターの一覧に NUMATopologyFilter を含めます。
注記

これらの変更を適用するには、アクティブなクラスターで heat パラメーターの値を定義または変更してから再デプロイします。

エミュレータースレッドを分離するには、以下のように設定したフレーバーを使用する必要があります。

# openstack flavor set FLAVOR-NAME \
--property hw:cpu_policy=dedicated \
--property hw:emulator_threads_policy=share

8.1.3. スケジューラーの設定

手順

  1. Compute 環境ファイルを開きます。
  2. NovaSchedulerDefaultFilters パラメーターにまだ以下の値がなければ、値を追加します。

    • NUMATopologyFilter
    • AggregateInstanceExtraSpecsFilter
  3. 設定ファイルを保存します。
  4. オーバークラウドをデプロイします。

8.1.4. アグリゲートとフレーバーの設定

ホストアグリゲートを設定して、CPU ピニングを使用するインスタンスと使用しないインスタンスを、それぞれ別のホストにデプロイします。これにより、ピニングされていないインスタンスがピニングされたインスタンスのリソース要件を使用するのを防ぐことができます。

注意

NUMA トポリジーを持つインスタンスを、NUMA トポリジーを持たないインスタンスと同じホストにデプロイしないでください。

システム上で Compute CLI を使用して以下の手順を実行して、OpenStack 環境で、特定のリソースにピニングされた仮想マシンインスタンスを実行するための準備を行います。

手順

  1. admin の認証情報を読み込みます。

    source ~/keystonerc_admin
  2. ピニング要求を受信するホスト用にアグリゲートを作成します。

    nova aggregate-create <aggregate-name-pinned>
  3. アグリゲートのメタデータを編集して、ピニングを有効化します。

    nova aggregate-set-metadata <aggregate-pinned-UUID> pinned=true
  4. その他のホスト用のアグリゲートを作成します。

    nova aggregate-create <aggregate-name-unpinned>
  5. このアグリゲートのメタデータを編集します。

    nova aggregate-set-metadata <aggregate-unpinned-UUID> pinned=false
  6. 既存のフレーバーのスペックを以下のように変更します。

    for i in $(nova flavor-list | cut -f 2 -d ' ' | grep -o '[0-9]*'); do nova flavor-key $i set "aggregate_instance_extra_specs:pinned"="false"; done
  7. ピニング要求を受信するホスト用にフレーバーを作成します。

    nova flavor-create <flavor-name-pinned> <flavor-ID> <RAM> <disk-size> <vCPUs>

    ここで、

    • <flavor-ID>: nova で UUID を生成する場合は、auto に設定します。
    • <RAM>: 必要なメモリーを MB 単位で指定します。
    • <disk-size>: 必要なディスクサイズを GB 単位で指定します。
    • <vCPUs>: 確保する仮想 CPU の数
  8. このフレーバーの hw:cpu_policy のスペックは、dedicated に指定して、CPU ピニングを有効化するための専用のリソースを必要とするように設定し、hw:cpu_thread_policy の仕様を require に指定して、スレッドシブリングに各 vCPU を配置します。

    nova flavor-key <flavor-name-pinned> set hw:cpu_policy=dedicated
    nova flavor-key <flavor-name-pinned> set hw:cpu_thread_policy=require
    注記

    ホストに SMT アーキテクチャーがない場合や、スレッドシブリングに空きのある CPU コアが十分にない場合には、スケジューリングが失敗します。このような動作が望ましくない場合や、単にホストが SMT アーキテクチャーを備えていない場合には、hw:cpu_thread_policy の仕様を使わないようにするか、require の代わりに prefer に設定してください。デフォルトの prefer ポリシーでは、スレッドシブリングが利用可能な場合には、必ず使用されます。

  9. aggregate_instance_extra_specs:pinned のスペックは「true」に指定して、このフレーバーをベースとするインスタンスが、アグリゲートのメタデータ内のこのスペックを使用するように設定します。

    nova flavor-key <flavor-name-pinned> set aggregate_instance_extra_specs:pinned=true
  10. 新規アグリゲートにホストを追加します。

    nova aggregate-add-host <aggregate-pinned-UUID> <host_name>
    nova aggregate-add-host <aggregate-unpinned-UUID> <host_name>
  11. 新規フレーバーを使用してインスタンスをブートします。

    nova boot --image <image-name> --flavor <flavor-name-pinned> <server-name>
  12. 新規サーバーが正しく配置されたことを確認するには、以下のコマンドを実行して、その出力で OS-EXT-SRV-ATTR:hypervisor_hostname の箇所をチェックします。

    nova show <server-name>