Menu Close

Red Hat Training

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

インスタンス&イメージガイド

Red Hat OpenStack Platform 13

インスタンスとイメージの管理

概要

インスタンス&イメージガイドには、Red Hat OpenStack Platform 環境におけるインスタンスおよびイメージの管理の手順を記載しています。

前書き

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

第1章 Image サービス

Red Hat OpenStack Platform (RHOSP) でのイメージおよびストレージを管理することができます。

仮想マシンのイメージとは、ブート可能なオペレーティングシステムがインストールされた仮想ディスクが含まれるファイルです。仮想マシンのイメージは、複数の形式をサポートしています。以下は、RHOSP で利用可能な形式です。

  • RAW: 非構造化のディスクイメージ形式
  • QCOW2: QEMU エミュレーターでサポートされているディスク形式。この形式には、QEMU 1.1 以降が必要な QCOW2v3 (QCOW3 と呼ばれる場合があります) が含まれます。
  • ISO: ディスク上のデータをセクター単位でコピーし、バイナリーファイルに格納した形式
  • AKI: Amazon Kernel Image
  • AMI: Amazon Machine Image
  • ARI: Amazon RAMDisk Image
  • VDI: VirtualBox の仮想マシンモニターおよび QEMU エミュレーターでサポートされているディスク形式
  • VHD: VMware、VirtualBox などの仮想マシンモニターで使用されている一般的なディスク形式
  • VMDK: 数多くの一般的な仮想マシンモニターでサポートされているディスク形式
  • PLOOP: OS コンテナーを実行するのに Virtuozzo でサポートおよび使用されているディスク形式
  • OVA: Image サービス (glance) に保存されているのが OVA tar アーカイブファイルであることを示します。
  • DOCKER: Image サービス (glance) に保存されているのがコンテナーファイルシステムの Docker tar アーカイブであることを示します。

ISO ファイルにはオペレーティングシステムがインストール済みのブート可能なファイルシステムが含まれているので、他の形式の仮想マシンイメージファイルと同様に ISO ファイルを使用することができます。

公式の Red Hat Enterprise Linux クラウドイメージをダウンロードするには、お使いのアカウントに有効な Red Hat Enterprise Linux サブスクリプションが必要です。

カスタマーポータルにログインしていない場合には、プロンプトが表示されるので Red Hat アカウントの認証情報を入力する必要があります。

1.1. Image サービスについての理解およびその最適化

以下の Red Hat OpenStack Platform (RHOSP) Image サービス (glance) の機能を使用して、RHOSP デプロイメントのイメージおよびストレージを管理および最適化することができます。

1.1.1. サポート対象の Image サービス (glance) バックエンド

以下に示す Image サービス (glance) バックエンドのシナリオがサポートされます。

  • Ceph を使用する場合には、RBD がデフォルトのバックエンドです。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「Ceph Storage の設定」を参照してください。
  • Object Storage (swift)。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「外部の Object Storage クラスターの使用」を参照してください。
  • Block Storage (cinder)。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「Image サービス用 cinder バックエンドの設定」を参照してください。

    注記
    Image サービスは、Block Storage の種別およびバックエンドをデフォルトとして使用します。
  • NFS。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「NFS ストレージの設定」を参照してください。

    重要

    NFS はサポート対象の Image サービス用デプロイメントオプションですが、より堅牢なオプションを利用することができます。

    NFS は Image サービスネイティブではありません。NFS 共有を Image サービスにマウントした場合、Image サービスは操作を管理しません。Image サービスはファイルシステムにデータを書き込みますが、バックエンドが NFS 共有であることを認識しません。

    この種別のデプロイメントでは、ファイル共有に異常が発生しても、Image サービスは要求をリトライすることができません。つまり、バックエンドで障害が発生した場合、ストアは読み取り専用モードに移行するか、ローカルファイルシステムにデータの書き込みを続けます。この場合、データを損失する可能性があります。この状況から回復するには、ファイル共有がマウントされ同期されている状態にし、続いて Image サービスを再起動する必要があります。このような理由により、Red Hat では、Image サービスのバックエンドとして NFS を推奨しません。

    ただし、Image サービスのバックエンドに NFS を使用することを選択した場合には、以下のベストプラクティスがリスクを軽減するのに役立ちます。

    • 実稼働環境グレードの NFS バックエンドを使用する。
    • コントローラーノードと NFS バックエンドの間でレイヤー 2 接続が確立されるようにする。
    • マウントされたファイル共有のモニタリングおよびアラート機能を追加する。
    • ベースとなる FS アクセス権限を設定する。

      • glance-api プロセスが実行されるユーザーおよびグループが、ローカルファイルシステムのマウントポイントに対する書き込み権限を持たないようにしてください。これにより、プロセスはマウントの異常を検出して、書き込みを試みる際にストアを読み取り専用モードに移行することができます。
      • 書き込み権限は、ストアとして使用する共有ファイルシステムに設定する必要があります。

1.1.2. イメージの署名および検証

イメージの署名および検証により、デプロイ担当者がイメージに署名して、その署名と公開鍵の証明書をイメージの属性として保存できるようにすることで、イメージの整合性と信頼性を保護します。

この機能を活用すると、以下が可能になります。

  • 秘密鍵を使用してイメージに署名し、そのイメージ、署名、公開鍵の証明書 (検証メタデータ) への参照をアップロードすることができます。Image サービスは、署名が有効かどうかを検証します。
  • Compute サービスでイメージを作成し、Compute サービスがそのイメージに署名し、イメージや検証メタデータをアップロードすることができます。Image サービスは、この場合も、署名が有効であるかどうかを検証します。
  • Compute サービスで署名済みのイメージを要求することができます。Image サービスは、イメージと検証メタデータを提供します。これにより、Compute サービスはイメージを起動する前に検証することができます。

イメージの署名および検証に関する詳しい情報は、『Manage Secrets with OpenStack Key Manager』「Validate glance images」の章を参照してください。

1.1.3. イメージの変換

イメージの変換は、イメージのインポート中にタスク API を呼び出して、イメージを変換します。

インポートのワークフローの一環として、プラグインがイメージの変換機能を提供します。このプラグインは、デプロイ担当者の設定に基づいて、アクティブ化/非アクティブ化することができます。そのため、デプロイ担当者は、デプロイメントに希望のイメージ形式を指定する必要があります。

内部では、Image サービスが特定の形式でイメージのビットを受信します。これらのビットは、一時的な場所に保管されます。次にプラグインが起動されて、イメージを対象のフォーマットに変換し、最終的な保管場所に移動します。タスクが終了すると、一時的な場所は削除されます。このため、Image サービスでは最初にアップロードした形式は保持されません。

イメージの変換についての詳細は、「イメージ変換の有効化」を参照してください。

注記

イメージをインポートする場合に限り、変換をトリガーすることができます。イメージのアップロード時に変換は実行されません。以下は例になります。

$ glance image-create-via-import \
    --disk-format qcow2 \
    --container-format bare \
    --name <name> \
    --visibility public \
    --import-method web-download \
    --uri <http://server/image.qcow2>

1.1.4. イメージのイントロスペクション

イメージ形式はすべて、イメージ自体の中にメタデータセットが埋め込まれた状態で提供されます。たとえば、ストリーム最適化 VMDK には、以下のようなパラメーターが含まれます。

$ head -20 so-disk.vmdk

# Disk DescriptorFile
version=1
CID=d5a0bce5
parentCID=ffffffff
createType="streamOptimized"

# Extent description
RDONLY 209714 SPARSE "generated-stream.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "buslogic"
ddb.geometry.cylinders = "102"
ddb.geometry.heads = "64"
ddb.geometry.sectors = "32"
ddb.virtualHWVersion = "4"

この vmdk をイントロスペクションすることにより、disk_typestreamOptimized で、adapter_typebuslogic であることを確認することができます。これらのメタデータパラメーターは、イメージのコンシューマーに役立ちます。Compute では、streamOptimized ディスクをインスタンス化するワークフローは、flat ディスクをインスタンス化するワークフローとは完全に異なります。この新機能により、メタデータの抽出が可能となります。イメージのイントロスペクションは、イメージのインポート中に、タスク API を呼び出すことによって実行できます。管理者は、メタデータの設定をオーバーライドすることができます。

1.1.5. 相互運用可能なイメージのインポート

OpenStack Image サービス (glance) では、相互運用可能なイメージインポートワークフローを使用して、イメージをインポートするための 2 つの方法が提供されています。

  • URI からイメージをインポートする web-download (デフォルト)
  • ローカルファイルシステムからインポートする glance-direct

1.2. イメージの管理

OpenStack Image サービス (glance) は、ディスクおよびサーバーイメージの検出、登録、および配信のサービスを提供します。サーバーイメージのコピーやスナップショットを作成して直ちに保管する機能を提供します。保管したイメージは、テンプレートとして使用し、新規サーバーを迅速に稼働させるのに使用することができます。これはサーバーのオペレーティングシステムをインストールしてサービスを個別に設定するよりも一貫性の高い方法です。

1.2.1. イメージの作成

Red Hat Enterprise Linux 7、Red Hat Enterprise Linux 6、または Windows の ISO ファイルを使用して、QCOW2 形式の Red Hat OpenStack Platform (RHOSP) 互換イメージを手動で作成します。

1.2.1.1. Red Hat OpenStack Platform における KVM ゲストイメージの使用

すでに準備済みの RHEL KVM ゲスト QCOW2 イメージを使用することができます。

これらのイメージは、cloud-init を使用して設定されます。適切に機能させるには、ec2 互換のメタデータサービスを利用して SSH キーをプロビジョニングする必要があります。

準備済みの Windows KVM ゲスト QCOW2 イメージはありません。

注記

KVM ゲストイメージでは、以下の点に注意してください。

  • KVM ゲストイメージでは root アカウントが無効になっていますが、cloud-user という名前の特別なユーザーに sudo アクセスが許可されています。
  • このイメージには root パスワードは設定されていません。

root パスワードは、/etc/shadow で 2 番目のフィールドに !! と記載することによりロックされます。

RHOSP インスタンスでは、RHOSP Dashboard またはコマンドラインから ssh キーペアを生成し、その鍵の組み合わせを使用して、インスタンスに対して root として SSH 公開認証を実行することを推奨します。

インスタンスの起動時には、この公開鍵がインスタンスに挿入されます。続いて、キーペア作成時にダウンロードした秘密鍵を使用して認証できます。

キーペアを使用しない場合には、admin パスワードを注入する手順に設定されている admin パスワードを使用することができます。「インスタンスへの admin パスワードの挿入」を参照してください。

Red Hat Enterprise Linux または Windows のカスタムイメージを作成する場合は、以下を参照してください。

1.2.1.2. Red Hat Enterprise Linux または Windows のカスタムイメージの作成

前提条件

  • イメージを作成する Linux ホストマシン。これは、Linux パッケージをインストール/実行することのできる任意のマシンです。
  • libvirt、virt-manager (yum groupinstall -y @virtualization のコマンドを実行)。ゲストオペレーティングシステムを作成するのに必要な全パッケージがインストールされます。
  • Libguestfs ツール (「yum install -y libguestfs-tools-c」のコマンドを実行してください)。これにより、仮想マシンイメージにアクセスして変更するための一連のツールがインストールされます。
  • Red Hat Enterprise Linux 7 もしくは 6 ISO ファイル (RHEL 7.2 Binary DVD もしくは RHEL 6.8 Binary DVD を参照)、または Windows ISO ファイル。Windows ISO ファイルがない場合には、Microsoft TechNet Evaluation Center に移動して評価版イメージをダウンロードしてください。
  • テキストエディター (kickstart ファイルを編集する必要がある場合 - RHEL のみ)
重要

アンダークラウドに libguestfs-tools パッケージをインストールする場合は、アンダークラウドの tripleo_iscsid サービスとのポートの競合を避けるために iscsid.socket を無効にします。

$ sudo systemctl disable --now iscsid.socket
注記

以下の手順では、プロンプトに [root@host]# と表示されているコマンドはすべて、お使いのホストマシンで実行する必要があります。

1.2.1.2.1. Red Hat Enterprise Linux 7 イメージの作成

Red Hat Enterprise Linux 7 の ISO ファイルを使用して、QCOW2 形式の Red Hat OpenStack Platform (RHOSP) 互換イメージを手動で作成します。

手順

  1. virt-install でインストールを開始します。

    [root@host]# qemu-img create -f qcow2 rhel7.qcow2 8G
    [root@host]# virt-install --virt-type kvm --name rhel7 --ram 2048 \
    --cdrom /tmp/rhel-server-7.2-x86_64-dvd.iso \
    --disk rhel7.qcow2,format=qcow2 \
    --network=bridge:virbr0 --graphics vnc,listen=0.0.0.0 \
    --noautoconsole --os-type=linux --os-variant=rhel7

    このコマンドによりインスタンスが起動し、インストールプロセスが開始します。

    注記

    インスタンスが自動的に起動しない場合には、virt-viewer のコマンドを実行して、コンソールを確認します。

    [root@host]# virt-viewer rhel7
  2. 以下の手順に従って、仮想マシンを設定します。

    1. インストーラーの初期起動メニューで、Install Red Hat Enterprise Linux 7.X のオプションを選択します。
    2. 適切な 言語 および キーボード オプションを選択します。
    3. インストールに使用するデバイスタイプを尋ねるプロンプトが表示されたら、自動検出したインストールメディア を選択します。
    4. インストール先を尋ねるプロンプトが表示されたら、ローカルの標準ディスク を選択します。その他のストレージタイプオプションには、自動構成のパーティション構成 を選択します。
    5. ソフトウェアのオプションには、最小限のインストール を選択します。
    6. ネットワークとホスト名の設定では、イーサネットに eth0 を選択し、デバイスの ホスト名 を指定します。デフォルトのホスト名は localhost.localdomain です。
    7. root パスワードを選択します。インストールプロセスが完了すると、完了しました! の画面が表示されます。
  3. インストールが完了した後には、インスタンスを再起動して、root ユーザーとしてログインします。
  4. /etc/sysconfig/network-scripts/ifcfg-eth0 ファイルを編集して、以下の値のみが記載されている状態にします。

    TYPE=Ethernet
    DEVICE=eth0
    ONBOOT=yes
    BOOTPROTO=dhcp
    NM_CONTROLLED=no
  5. マシンを再起動します。
  6. コンテンツ配信ネットワークにマシンを登録します。

    # sudo subscription-manager register
    # sudo subscription-manager attach --pool=Valid-Pool-Number-123456
    # sudo subscription-manager repos --enable=rhel-7-server-rpms
  7. システムを更新します。

    # yum -y update
  8. cloud-init パッケージをインストールします。

    # yum install -y cloud-utils-growpart cloud-init
  9. /etc/cloud/cloud.cfg 設定ファイルを編集して、cloud_init_modules の下に以下を追加します。

    - resolv-conf

    resolv-conf オプションは、インスタンスの初回起動時に resolv.conf を自動的に設定します。このファイルには、nameserversdomain、その他のオプションなどのインスタンスに関連した情報が記載されています。

  10. /etc/sysconfig/network に以下の行を追加し、EC2 メタデータサービスへのアクセスで問題が発生するのを回避します。

    NOZEROCONF=yes
  11. コンソールメッセージが Dashboard の ログ タブおよび nova console-log の出力に表示されるようにするには、以下のブートオプションを /etc/default/grub ファイルに追記します。

    GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"

    grub2-mkconfig コマンドを実行します。

    # grub2-mkconfig -o /boot/grub2/grub.cfg

    以下のような出力が表示されます。

    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-3.10.0-229.7.2.el7.x86_64
    Found initrd image: /boot/initramfs-3.10.0-229.7.2.el7.x86_64.img
    Found linux image: /boot/vmlinuz-3.10.0-121.el7.x86_64
    Found initrd image: /boot/initramfs-3.10.0-121.el7.x86_64.img
    Found linux image: /boot/vmlinuz-0-rescue-b82a3044fb384a3f9aeacf883474428b
    Found initrd image: /boot/initramfs-0-rescue-b82a3044fb384a3f9aeacf883474428b.img
    done
  12. 仮想マシンの登録を解除して、作成されるイメージをベースにクローン作成される全インスタンスに同じサブスクリプション情報が含まれないようにします。

    # subscription-manager repos --disable=*
    # subscription-manager unregister
    # yum clean all
  13. インスタンスの電源をオフにします。

    # poweroff
  14. virt-sysprep コマンドでイメージのリセットおよびクリーニングをして、問題なくインスタンスの作成に使用できるようにします。

    [root@host]# virt-sysprep -d rhel7
  15. virt-sparsify コマンドを使用してイメージのサイズを縮小します。このコマンドにより、ディスクイメージ内の空き容量は、ホスト内の空き容量に戻ります。

    [root@host]# virt-sparsify --compress /tmp/rhel7.qcow2 rhel7-cloud.qcow2

    このコマンドを実行すると、その場所に rhel7-cloud.qcow2 ファイルが作成されます。

rhel7-cloud.qcow2 イメージファイルを Image サービスにアップロードする準備が整いました。Dashboard を使用してこのイメージを RHOSP デプロイメントにアップロードする方法については、「イメージのアップロード」を参照してください。

1.2.1.2.2. Red Hat Enterprise Linux 6 イメージの作成

Red Hat Enterprise Linux 6 の ISO ファイルを使用して、QCOW2 形式の Red Hat OpenStack Platform (RHOSP) 互換イメージを手動で作成します。

手順

  1. virt-install を使用してインストールを開始します。

    [root@host]# qemu-img create -f qcow2 rhel6.qcow2 4G
    [root@host]# virt-install --connect=qemu:///system --network=bridge:virbr0 \
    --name=rhel6 --os-type linux --os-variant rhel6 \
    --disk path=rhel6.qcow2,format=qcow2,size=10,cache=none \
    --ram 4096 --vcpus=2 --check-cpu --accelerate \
    --hvm --cdrom=rhel-server-6.8-x86_64-dvd.iso

    このコマンドによりインスタンスが起動し、インストールプロセスが開始します。

    注記

    インスタンスが自動的に起動しない場合には、virt-viewer のコマンドを実行して、コンソールを確認します。

    [root@host]# virt-viewer rhel6
  2. 仮想マシンを以下のように設定します。

    1. インストーラーの初期起動メニューで、Install or upgrade an existing system のオプションを選択します。インストールのプロンプトに従います。デフォルト値を受け入れます。

      インストーラーは、ディスクの有無を確認して、インストール前にインストールメディアのテストを行うかどうかを決定するように促します。テストを実行するには OK を、テストを行わずに続行するには Skip を選択します。

    2. 適切な 言語 および キーボード オプションを選択します。
    3. インストールに使用するデバイスタイプを尋ねるプロンプトが表示されたら、基本ストレージデバイス を選択します。
    4. デバイスの ホスト名 を指定します。デフォルトのホスト名は localhost.localdomain です。
    5. タイムゾーンroot パスワードを指定します。
    6. ディスクの空き容量に応じて、インストールのタイプを選択します。
    7. SSH サーバーをインストールする 基本サーバー インストールを選択します。
    8. インストールプロセスが完了し、おめでとうございます。Red Hat Enterprise Linux のインストールが完了しました。の画面が表示されます。
  3. インスタンスを再起動して、root ユーザーとしてログインします。
  4. /etc/sysconfig/network-scripts/ifcfg-eth0 ファイルを編集して、以下の値のみが記載されている状態にします。

    TYPE=Ethernet
    DEVICE=eth0
    ONBOOT=yes
    BOOTPROTO=dhcp
    NM_CONTROLLED=no
  5. マシンを再起動します。
  6. コンテンツ配信ネットワークにマシンを登録します。

    # sudo subscription-manager register
    # sudo subscription-manager attach --pool=Valid-Pool-Number-123456
    # sudo subscription-manager repos --enable=rhel-6-server-rpms
  7. システムを更新します。

    # yum -y update
  8. cloud-init パッケージをインストールします。

    # yum install -y cloud-utils-growpart cloud-init
  9. /etc/cloud/cloud.cfg 設定ファイルを編集して、cloud_init_modules の下に以下を追加します。

    - resolv-conf

    resolv-conf オプションは、インスタンスの初回起動時に resolv.conf 設定ファイルを自動的に設定します。このファイルには、nameserversdomain、その他のオプションなどのインスタンスに関連した情報が記載されています。

  10. ネットワークの問題が発生するのを防ぐために、以下のように /etc/udev/rules.d/75-persistent-net-generator.rules ファイルを作成します。

    # echo "#" > /etc/udev/rules.d/75-persistent-net-generator.rules

    これにより、/etc/udev/rules.d/70-persistent-net.rules ファイルが作成されるのを防ぎます。/etc/udev/rules.d/70-persistent-net.rules が作成されてしまうと、スナップショットからのブート時にネットワークが適切に機能しなくなる可能性があります (ネットワークインターフェースが eth0 ではなく eth1 として作成され、IP アドレスが割り当てられません)。

  11. /etc/sysconfig/network に以下の行を追加し、EC2 メタデータサービスへのアクセスで問題が発生するのを回避します。

    NOZEROCONF=yes
  12. コンソールメッセージが Dashboard の ログ タブおよび nova console-log の出力に表示されるようにするには、以下のブートオプションを /etc/grub.conf ファイルに追記します。

    console=tty0 console=ttyS0,115200n8
  13. 仮想マシンの登録を解除して、作成されるイメージをベースにクローン作成される全インスタンスに同じサブスクリプション情報が含まれないようにします。

    # subscription-manager repos --disable=*
    # subscription-manager unregister
    # yum clean all
  14. インスタンスの電源をオフにします。

    # poweroff
  15. virt-sysprep コマンドでイメージのリセットおよびクリーニングをして、問題なくインスタンスの作成に使用できるようにします。

    [root@host]# virt-sysprep -d rhel6
  16. virt-sparsify コマンドを使用してイメージのサイズを縮小します。このコマンドにより、ディスクイメージ内の空き容量は、ホスト内の空き容量に戻ります。

    [root@host]# virt-sparsify --compress rhel6.qcow2 rhel6-cloud.qcow2

    このコマンドを実行すると、その場所に新しい rhel6-cloud.qcow2 ファイルが作成されます。

    注記

    インスタンスに適用されているフレーバーのディスクスペースに応じて、イメージをベースとするインスタンスのパーティションを手動でリサイズする必要があります。

rhel6-cloud.qcow2 イメージファイルを Image サービスにアップロードする準備が整いました。Dashboard を使用してこのイメージを RHOSP デプロイメントにアップロードする方法については、「イメージのアップロード」を参照してください。

1.2.1.2.3. Windows イメージの作成

Windows の ISO ファイルを使用して、QCOW2 形式の Red Hat OpenStack Platform (RHOSP) 互換イメージを手動で作成します。

手順

  1. virt-install を使用してインストールを開始します。

    [root@host]# virt-install --name=<name> \
    --disk size=<size> \
    --cdrom=<path>` \
    --os-type=windows \
    --network=bridge:virbr0 \
    --graphics spice \
    --ram=<RAM>

    以下のように virt-install パラメーターの値を置き換えます。

    • <name>: Windows ゲストの名前。
    • <size>: ディスクのサイズ (GB)
    • <path>: Windows のインストール ISO ファイルへのパス
    • <RAM>: 要求するメモリー容量 (MB)

      注記

      --os-type=windows パラメーターにより、Windows ゲストのクロックが正しく設定され、Hyper-V エンライトメント機能が有効化されるようになります。

      デフォルトでは、virt-install/var/lib/libvirt/images/<name>.qcow2 としてゲストイメージを保存します。ゲストイメージを別の場所に保存するには、以下のように --disk のオプションを変更してください。

      --disk path=<filename>,size=<size>

      <filename> は、ゲストイメージを保存する必要のあるファイル名 (およびオプションでそのパス) に置き換えてください。たとえば、path=win8.qcow2,size=8 は現在の作業ディレクトリーに win8.qcow2 という名前の 8 GB のファイルを作成します。

      ヒント

      ゲストが自動的に起動しない場合には、virt-viewer のコマンドを実行して、コンソールを確認します。

      [root@host]# virt-viewer <name>
  2. Windows システムのインストールは、本書の対象範囲外となります。Windows のインストール方法に関する説明は、適切な Microsoft のドキュメントを参照してください。
  3. 新規インストールした Windows システムで仮想化ハードウェアを使用できるようにするには、virtio ドライバー をインストールしなければならない場合があります。これには、まずホストシステムで virtio-win パッケージをインストールします。このパッケージには virtio ISO イメージが含まれており、そのイメージを CD-ROM ドライブとして Windows ゲストにアタッチします。「KVM 準仮想化 (virtio) ドライバー」(『仮想化の導入および管理ガイド』) を参照し、virtio-win パッケージのインストール、ゲストへの virtio ISO イメージの追加、virtio ドライバーのインストール方法を確認してください。
  4. Windows システムで Cloudbase-Init をダウンロード、実行して、設定を完了します。Cloudbase-Init のインストールの最後に、Run SysprepShutdown チェックボックスを選択します。Sysprep ツールは、特定の Microsoft サービスで使用する OS ID を生成して、ゲストを一意にします。

    重要

    Red Hat は Cloudbase-Init に関するテクニカルサポートは提供しません。問題が発生した場合は、Cloudbase Solutions にお問い合わせください

Windows システムがシャットダウンしたら、<name>_.qcow2 イメージファイルを Image サービスにアップロードすることができます。Dashboard またはコマンドラインを使用してこのイメージを RHOSP デプロイメントにアップロードする方法については、「イメージのアップロード」を参照してください。

注記

libosinfo データ

Compute サービスでは、libosinfo データを使用してデフォルトのデバイスモデルを設定する操作が非推奨になりました。これに代わって、以下のイメージメタデータ属性を使用して、インスタンス用の最適な仮想ハードウェアを設定します。

  • os_distro
  • os_version
  • hw_cdrom_bus
  • hw_disk_bus
  • hw_scsi_model
  • hw_vif_model
  • hw_video_model
  • hypervisor_type

これらのメタデータ属性についての詳細は、「付録A イメージの設定パラメーター」を参照してください。

1.2.2. イメージのアップロード

手順

  1. Dashboard で プロジェクト > コンピュート > イメージ を選択します。
  2. イメージの作成 をクリックします。
  3. 各フィールドに値を入力し、完了したら イメージの作成 をクリックします。

表1.1 イメージオプション

フィールド説明

名前

イメージの名前。そのプロジェクト内で一意な名前にする必要があります。

説明

イメージを識別するための簡単な説明

イメージソース

イメージソース: イメージの場所 または イメージファイル。ここで選択したオプションに応じて次のフィールドが表示されます。

イメージの場所またはイメージファイル

  • イメージの場所の URL を指定するには、イメージの場所 オプションを選択します。
  • ローカルディスクからイメージをアップロードするには、イメージファイル オプションを選択します。

形式

イメージの形式 (例: qcow2)

アーキテクチャー

イメージのアーキテクチャー。たとえば 32 ビットのアーキテクチャーには i686、64 ビットのアーキテクチャーには x86_64 を使用します。

最小ディスク (GB)

イメージのブートに必要な最小のディスクサイズ。このフィールドに値が指定されていない場合には、デフォルト値は 0 です (最小値なし)。

最小メモリー (MB)

イメージのブートに必要な最小のメモリーサイズ。このフィールドに値が指定されていない場合には、デフォルト値は 0 です (最小値なし)。

パブリック

このチェックボックスを選択した場合には、プロジェクトにアクセスできる全ユーザーにイメージが公開されます。

保護

このチェックボックスを選択した場合には、特定のパーミッションのあるユーザーのみがこのイメージを削除できるようになります。

イメージが正常にアップロードされたら、イメージのステータスは、イメージが使用可能であることを示す active に変わります。Image サービスは、アップロードの開始時に使用した Identity サービストークンのライフタイムよりもアップロードの所要時間が長くかかる大容量のイメージも処理することができる点に注意してください。これは、アップロードが完了してイメージのステータスが更新される際に、新しいトークンを取得して使用できるように、Identity サービスは最初に Identity サービスとのトラストを作成するためです。

注記

glance image-create コマンドに --property のオプションを指定して実行する方法でイメージをアップロードすることもできます。コマンドラインで操作を行った方が、より多くの値を使用することができます。利用可能なメタデータ属性の完全なリストは、「イメージの設定パラメーター」を参照してください。

1.2.3. イメージの更新

手順

  1. Dashboard で プロジェクト > コンピュート > イメージ を選択します。
  2. 一覧から イメージの編集 をクリックします。

    注記

    イメージの編集 オプションは、admin ユーザーとしてログインした場合にのみ使用することができます。demo ユーザーとしてログインした場合には、インスタンスの起動 または ボリュームの作成 のオプションを使用することができます。

  3. フィールドを更新して、終了したら イメージの更新 をクリックします。次の値を更新することができます (名前、説明、カーネル ID、RAM ディスク ID、アーキテクチャー、形式、最小ディスク、最小メモリー、パブリック、保護)。
  4. メニューをクリックして メタデータの更新 オプションを選択します。
  5. 左のコラムから右のコラムに項目を追加して、メタデータを指定します。左のコラムには、Image サービスのメタデータカタログからのメタデータの定義が含まれています。その他 を選択して、任意のキーを使用してメタデータを追加し、完了したら 保存 をクリックします。
注記

glance image-update コマンドに --property オプションを指定して実行する方法でイメージを更新することもできます。コマンドラインで操作を行った方が、より多くの値を使用することができます。利用可能なメタデータ属性の完全なリストは、「イメージの設定パラメーター」を参照してください。

1.2.4. イメージのインポート

URI からイメージをインポートする web-download とローカルファイルシステムからイメージをインポートする glance-direct を使用して、Image サービス (glance) にイメージをインポートすることができます。web-download オプションはデフォルトで有効化されています。

インポートの方法は、クラウド管理者によって設定されます。glance import-info コマンドを実行して、利用可能なインポートオプションを一覧表示します。

1.2.4.1. リモート URI からのインポート

web-download メソッドを使用して、2 段階のプロセスでリモートの URI からイメージコピーすることができます。まず最初にイメージのレコードが作成されてから、イメージが URI から取得されます。このメソッドは、Image API v1 で使用されていた非推奨となった copy-from メソッドよりもセキュアにイメージをインポートする方法です。

手順

  1. イメージを作成して、インポートするイメージの URI を指定します。

    $ glance image-create --uri <URI>
  2. イメージの可用性をモニターできます。

    $ openstack image show <image_id> command.

    ID を、イメージの作成時に指定したものに置き換えます。

1.2.4.2. ローカルボリュームからのインポート

glance-direct メソッドは、イメージレコードを作成し、それによりイメージ ID が生成されます。イメージがローカルボリュームからサービスにアップロードされるとステージングエリアに保管され、設定されているチェックに合格した後にアクティブとなります。高可用性 (HA) 構成で使用される場合には、glance-direct メソッドには共通のステージングエリアが必要です。

注記

HA 環境では、glance-direct メソッドを使用したイメージのアップロードは、共通のステージエリアがない場合には失敗します。HA の アクティブ/アクティブ環境では、API コールは複数の Image サービスのコントローラーに分散されます。ダウンロード API コールは、イメージをアップロードする API コールとは別のコントローラーに送信することが可能です。ステージングエリアの設定に関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』「ストレージの設定」セクションを参照してください。

glance-direct メソッドは、以下の呼び出しを使用してイメージをインポートします。

  • glance image-create
  • glance image-stage
  • glance image-import

手順

  1. glance image-create-via-import コマンドを使用すると、これらの 3 つのコールを 1 つのコマンドで実行することができます。

    $ glance image-create-via-import --container-format <format> --disk-format <disk_format> --name <name> --file <path_to_image>

    イメージがステージングエリアからバックエンドの場所に移動すると、そのイメージはリストされます。ただし、イメージがアクティブになるには、多少時間がかかる場合があります。

  2. イメージの可用性をモニターできます。

    $ openstack image show <image_id> command.

    ID を、イメージの作成時に指定したものに置き換えます。

1.2.5. イメージの削除

手順

  1. Dashboard で プロジェクト > コンピュート > イメージ を選択します。
  2. 削除するイメージを選択し、イメージの削除 ボタンをクリックします。

1.2.6. イメージ変換の有効化

GlanceImageImportPlugins パラメーターを有効にすると、QCOW2 イメージをアップロードすることができ、Image サービスはそのイメージを RAW に変換します。

手順

  • イメージの変換を有効にするには、以下のパラメーター値が含まれる環境ファイルを作成し、openstack overcloud deploy コマンドで -e オプションを使用して、デプロイメントに関連するその他の環境ファイルと共に新しい環境ファイルを追加します。

    parameter_defaults:
      GlanceImageImportPlugins:'image_conversion'

1.2.7. RAW 形式へのイメージの変換

Red Hat Ceph は QCOW2 イメージを保管することはできますが、そのイメージを使用して仮想マシン (VM) のディスクをホストすることはできません。

アップロードした QCOW2 イメージから仮想マシンを作成する場合には、コンピュートノードはイメージをダウンロードして RAW に変換し、それを Ceph にアップロードし直してからでないと使用することができません。このプロセスは仮想マシンの作成時間に影響を及ぼします (特に、並行して仮想マシンを作成する場合)。

たとえば、複数の仮想マシンを同時に作成する場合には、Ceph クラスターへの変換済みイメージのアップロードが、すでに実行中の負荷に影響を及ぼす可能性があります。IOPS のこれらの負荷に対するリソースがアップロードプロセスにより枯渇し、ストレージの反応が遅くなる場合があります。

Ceph において仮想マシンをより効率的に起動するには (一時バックエンドまたはボリュームからの起動)、Image サービスのイメージの形式を RAW にする必要があります。

手順

  1. イメージを RAW に変換すると、イメージサイズが元の QCOW2 イメージファイルより大きくなる場合があります。最終的な RAW イメージのサイズを確認するには、変換前に以下のコマンドを実行します。

    qemu-img info <image>.qcow2
  2. イメージを QCOW2 から RAW 形式に変換します。

    qemu-img convert -p -f qcow2 -O raw <original_qcow2_image>.qcow2 <new_raw_image>.raw

1.2.7.1. RAW および ISO だけを受け入れる Image サービスの設定

RAW および ISO イメージ形式のみを受け入れるように Image サービスを設定することができます。

手順

  1. その他の環境ファイルと共に、openstack overcloud deploy コマンドに以下の内容が含まれる別の環境ファイルを追加します。

    parameter_defaults:
      ExtraConfig:
        glance::config::api_config:
          image_format/disk_formats:
            value: "raw,iso"

1.2.8. RAW 形式でのイメージの保存

手順

  • QCOW2 イメージをアップロードしてそれを自動的に RAW 形式に変換するには、GlanceImageImportPlugins パラメーターを有効にして以下のコマンドを実行します。

    $ glance image-create-via-import \
        --disk-format qcow2 \
        --container-format bare \
        --name <name> \
        --visibility public \
        --import-method web-download \
        --uri <http://server/image.qcow2>
  • <name> をイメージの名前に置き換えます。これは openstack image list に表示される名前です。
  • --uri: <http://server/image.qcow2> を QCOW2 イメージの場所およびファイル名に置き換えます。
注記

このコマンド例では、イメージレコードを作成し、web-download メソッドを使用してそのイメージレコードをインポートします。glance-api は、インポートプロセス中に --uri で定義した場所からイメージをダウンロードします。web-download が利用できない場合、glanceclient はイメージデータを自動的にダウンロードすることができません。利用可能なイメージのインポート方法を一覧表示するには、glance import-info コマンドを実行します。

第2章 Compute (nova) サービスの設定

環境ファイルを使用して Compute (nova) サービスをカスタマイズします。Puppet は、この設定を生成して /var/lib/config-data/puppet-generated/<nova_container>/etc/nova/nova.conf ファイルに保存します。Compute サービスの設定をカスタマイズするには、以下の設定方法を使用します。

  • Heat パラメーター: 詳細は、『オーバークラウドのパラメーター』「Compute (nova) パラメーター」セクションを参照してください。以下は例になります。

    parameter_defaults:
      NovaSchedulerDefaultFilters: AggregateInstanceExtraSpecsFilter,RetryFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter
      NovaNfsEnabled: true
      NovaNfsShare: '192.0.2.254:/export/nova'
      NovaNfsOptions: 'context=system_u:object_r:nfs_t:s0'
      NovaNfsVersion: '4.2'
  • Puppet パラメーター: /etc/puppet/modules/nova/manifests/* で定義されます。

    parameter_defaults:
        ComputeExtraConfig:
            nova::compute::force_raw_images: True
    注記

    この方法は、等価な heat パラメーターが存在しない場合にのみ使用してください。

  • 手動での hieradata の上書き: heat パラメーターまたは Puppet パラメーターが存在しない場合の、パラメーターカスタマイズ用。たとえば、以下の設定により Compute ロールの [DEFAULT] セクションに disk_allocation_ratio が定義されます。

    parameter_defaults:
        ComputeExtraConfig:
            nova::config::nova_config:
                DEFAULT/disk_allocation_ratio:
                    value: '2.0'
警告

heat パラメーターが存在する場合は、Puppet パラメーターではなくそのパラメーターを使用する必要があります。Puppet パラメーターは存在するが heat パラメーターが存在しない場合は、手動で上書きする方法ではなく Puppet パラメーターを使用する必要があります。手動で上書きする方法は、等価な heat パラメーターまたは Puppet パラメーターがない場合にのみ使用してください。

ヒント

特定の設定をカスタマイズする際に heat パラメーターまたは Puppet パラメーターが利用可能かどうかを判断するには、『オーバークラウドの高度なカスタマイズ』の「変更するパラメーターの特定」のガイダンスに従ってください。

オーバークラウドサービス設定の詳細は、『オーバークラウドの高度なカスタマイズ』「パラメーター」を参照してください。

2.1. オーバーコミットのためのメモリー設定

メモリーのオーバーコミットを使用する場合 (NovaRAMAllocationRatio >= 1.0)、割り当て率をサポートするのに十分なスワップ領域を確保してオーバークラウドをデプロイする必要があります。

注記

NovaRAMAllocationRatio パラメーターが 1 より小さい値 に設定されている場合は、RHEL でのスワップサイズの推奨事項に従ってください。詳しくは、RHEL の『ストレージデバイスの管理』「システムの推奨スワップ領域」を参照してください。

前提条件

手順

  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 \

2.2. コンピュートノード上で確保するホストメモリーの計算

ホストのプロセス用に確保する RAM 容量の合計を判断するには、以下の各項目に十分なメモリーを割り当てる必要があります。

  • ノードで実行されるリソース。たとえば、OSD は 3 GB のメモリーを消費します。
  • ホスト上のインスタンスを視覚化するのに必要なエミュレーターのオーバーヘッド
  • 各インスタンスのハイパーバイザー

メモリーへの追加要求を計算したら、以下の式を使用して各ノードのホストプロセス用に確保するメモリーの容量を決定します。

NovaReservedHostMemory = total_RAM - ( (vm_no * (avg_instance_size + overhead)) + (resource1 * resource_ram) + (resource _n_ * resource_ram))
  • vm_no は、インスタンスの数に置き換えてください。
  • avg_instance_size は、各インスタンスが使用できるメモリーの平均容量に置き換えてください。
  • overhead は、各インスタンスに必要なハイパーバイザーのオーバーヘッドに置き換えてください。
  • resource1 は、ノード上のリソース種別の数に置き換えてください。
  • resource_ram は、この種別の各リソースに必要な RAM の容量に置き換えてください。

2.3. スワップサイズの計算

割り当てるスワップサイズは、メモリーのオーバーコミットを処理するのに十分な容量でなければなりません。以下の式を使用して、ノードに必要なスワップサイズを計算することができます。

  • overcommit_ratio = NovaRAMAllocationRatio - 1
  • 最小スワップサイズ (MB) = (total_RAM * overcommit_ratio) + RHEL_min_swap
  • 推奨 (最大) スワップサイズ (MB) = total_RAM * (overcommit_ratio + percentage_of_RAM_to_use_for_swap)

percentage_of_RAM_to_use_for_swap 変数は、QEMU のオーバーヘッドおよびオペレーティングシステムまたはホストのサービスが消費するその他のリソースに対応するバッファーです。

たとえば、RAM 容量の合計が 64 GB で NovaRAMAllocationRatio1 に設定されている場合、利用可能な RAM の 25% をスワップに使用するには、

  • 推奨 (最大) スワップサイズ = 64000 MB * (0 + 0.25) = 16000 MB

NovaReservedHostMemory の値を計算する方法は、「コンピュートノード上で確保するホストメモリーの計算」を参照してください。

RHEL_min_swap の値を決定する方法は、RHEL の『ストレージデバイスの管理』「システムの推奨スワップ領域」を参照してください。

第3章 OpenStack Compute 用のストレージの設定

本章では、OpenStack Compute (nova) のイメージのバックエンドストレージのアーキテクチャーについて説明し、基本的な設定オプションを記載します。

3.1. アーキテクチャーの概要

Red Hat OpenStack Platform では、OpenStack Compute サービスは KVM ハイパーバイザーを使用してコンピュートのワークロードを実行します。libvirt ドライバーが KVM とのすべての対話を処理し、仮想マシンが作成できるようにします。

コンピュートには、2 種類の libvirt ストレージを考慮する必要があります。

  • Image サービスのイメージのコピーをキャッシュ済み/フォーマット済みのベースイメージ
  • libvirt ベースを使用して作成され、仮想マシンインスタンスのバックエンドとなるインスタンスディスク。インスタンスディスクデータは、コンピュートの一時ストレージ (libvirt ベースを使用) または永続ストレージ (例: Block Storage を使用) のいずれかに保存されます。

Creation of Virtual Machines

Compute は、以下の手順で仮想マシンインスタンスを作成します。

  1. Image サービスのバッキングイメージを libvirt ベースとしてキャッシュします。
  2. ベースイメージを Raw 形式に変換します (設定されている場合)。
  3. 仮想マシンのフレーバーの仕様に一致するようにベースイメージのサイズを調節します。
  4. ベースイメージを使用して libvirt インスタンスディスクを作成します。

上図では、#1 のインスタンスディスクは一時ストレージを使用し、#2 のディスクは Block Storage ボリュームを使用します。

一時ストレージとは、インスタンスで追加で利用可能な、フォーマットされていない空のディスクのことです。このストレージの値は、インスタンスのフレーバーにより定義されます。ユーザーが指定した値は、フレーバーで定義した一時ストレージの値以下でなければなりません。デフォルト値は 0 です。0 を指定すると、一時ストレージが作成されません。

一時ディスクは、外付けのハードドライブや USB ドライブと同じ方法で表示されます。一時ディスクはブロックデバイスとして利用でき、lsblk コマンドを使用して確認することができます。ブロックデバイスとして通常使用するように、フォーマット、マウント、使用が可能です。アタッチ先のインスタンス以外では、このディスクの保存や参照をする方法はありません。

ブロックストレージボリュームは、実行中のインスタンスがどのような状態であっても、インスタンスを利用できる一時ストレージです。

3.2. 設定

Compute (nova) の設定ファイルをカスタマイズして、仮想ディスクのパフォーマンスチューニングおよびセキュリティーを設定することができます。Compute は、『オーバークラウドのパラメーター』「Compute (nova) パラメーター」セクションで説明するパラメーターを使用して、カスタム環境ファイルおよび Heat テンプレートで設定します。生成された設定は、/var/lib/config-data/puppet-generated/<nova_container>/etc/nova/nova.conf ファイルに保存されます。詳細を以下の表に示します。

表3.1 Compute のイメージのパラメーター

セクションパラメーター説明デフォルト

[DEFAULT]

force_raw_images

non-raw でキャッシュしたベースイメージを raw (ブール型) に変換するかどうかを設定します。non-raw イメージが Raw に変換された場合には、コンピュートは以下の操作を行います。

  • セキュリティー上問題がある可能性があるバッキングファイルを無効にします。
  • 既存の圧縮を削除して、CPU のボトルネックを回避します。

ベースを Raw に変換すると、ハイパーバイザーが直接使用可能なイメージの容量よりも、容量が多く使用されます (例: qcow2 イメージ)。I/O が遅いシステムや空き容量が少ないシステムを使用している場合は、false に指定して、圧縮の際のCPU 要件を軽減することで入力の帯域幅を最小限に抑えます。

Raw ベースイメージは常に libvirt_images_type=lvm と合わせて使用されます。

true

[DEFAULT]

use_cow_images

libvirt インスタンスディスク (ブール型) に CoW (Copy of Write) イメージを使用するかどうかを設定します。

  • false: Raw 形式が使用されます。CoW を使用しない場合には、ディスクイメージの共通の部分により多くの容量が使用されます。
  • true: cqow2 形式が使用されます。CoW を使用する場合には、バッキングストアとホストのキャッシュによっては、各仮想マシンが独自のコピー上で稼働することで、並行処理が改善される可能性があります。

true

[DEFAULT]

preallocate_images

libvirt インスタンスディスクに対する事前割り当てモード。値は以下のとおりです。

  • none: インスタンスの起動時にはストレージがプロビジョニングされません。
  • space: インスタンスの開始時には、(fallocate を使用して) ストレージが完全に割り当てられます。領域および I/O パフォーマンスの両方を確保しやすくします。

CoW インスタンスディスクを使用しない場合でも、各仮想マシンが取得するコピーはスパースであるため、仮想マシンが ENOSPC でランタイムに予期せず失敗する可能性があります。インスタンスディスクに fallocate(1) を実行すると、コンピュートは即時に、ファイルシステム内でイメージに領域を効率的に割り当てます (サポートされている場合)。ファイルシステムではランタイム時にブロックを動的に割り当てる必要がないため、ランタイムのパフォーマンスも向上されるはずです (CPU オーバーヘッドの削減、より重要な点としてファイルの断片化の軽減)。

none

[DEFAULT]

resize_fs_using_block_device

ブロックデバイス (ブール型) を使用してイメージにアクセスすることで、ベースイメージのサイズを直接調節することができるかどうかを設定します。これは、(それ自体ではサイズ調節ができないため) cloud-init のバージョンがより古いイメージでのみ必要です。

このパラメーターにより、セキュリティーの関係上、無効にされる可能性のあるイメージを直接マウントできるため、デフォルトでは有効化されていません。

false

[DEFAULT]

default_ephemeral_format

新規の一時ボリュームに使用されるデフォルトの形式。値は、ext2ext3ext4 のいずれかを使用できます。ext4 形式では、ext3 に比べ、サイズの大きい新規ディスクを初期化する時間が大幅に短縮されます。また、guest_format の設定オプションを使用することで、インスタンスごとの設定を優先させることも可能です。

ext4

[DEFAULT]

image_cache_manager_interval

libvirt コンピュートノードにキャッシュするベースに影響を与える、イメージキャッシュマネージャーを次に実行するまでの待機時間 (秒数)。この時間は、未使用のキャッシュされたイメージを自動削除する際にも使用されます (remove_unused_base_imagesremove_unused_original_minimum_age_seconds 参照)。

2400

[DEFAULT]

remove_unused_base_images

未使用のベースイメージを自動的に削除できるようにするかどうかを設定します (image_cache_manager_interval の秒の間隔でチェック)。イメージは、remove_unused_original_minimum_age_seconds (秒) の期間アクセスされなかった場合に unused と定義されます。

true

[DEFAULT]

remove_unused_original_minimum_age_seconds

未使用となったベースイメージが libvirt キャッシュから削除されるまでの期間を設定します (remove_unused_base_images 参照)。

86400

[libvirt]

images_type

libvirt インスタンスディスクに使用するイメージ種別 (use_cow_images は廃止予定)。使用可能な値は、rawqcow2lvmrbddefault のいずれかです。default が指定されている場合は、use_cow_images パラメーターに使用された値が使用されます。

default

3.3. Compute サービスと Block Storage サービス間のサービストークンの有効化

ボリュームの接続または切断時にユーザーのリクエストトークンがタイムアウトするのを防ぐには、管理者は Compute (nova) サービスまたは Block Storage (cinder) サービスを実行するすべてのオーバークラウドノードでサービストークンを有効にする必要があります。

手順

  1. サービストークンを設定するための環境ファイルを作成します (例: service_tokens.yaml)。
  2. サービストークンの環境ファイルに以下の設定パラメーターを追加します。

    parameter_defaults:
      ComputeExtraConfig:
        nova::config::nova_config:
          service_user/send_service_user_token:
            value: true
          service_user/username:
            value: nova
          service_user/auth_strategy:
            value: keystone
          service_user/auth_type:
            value: password
          service_user/password:
            value: "%{hiera('nova::placement::password')}"
          service_user/auth_url:
            value: "%{hiera('nova::placement::auth_url')}"
          service_user/user_domain_name:
            value: "Default"
          service_user/project_name:
            value: "%{hiera('nova::placement::project_name')}"
          service_user/project_default_name:
            value: "Default"
    
      ControllerExtraConfig:
        nova::config::nova_config:
          keystone_authtoken/service_token_roles_required:
            value: true
          keystone_authtoken/service_token_roles:
            value: admin
          service_user/send_service_user_token:
            value: true
          service_user/username:
            value: nova
          service_user/auth_strategy:
            value: keystone
          service_user/auth_type:
            value: password
          service_user/password:
            value: "%{hiera('nova::keystone::authtoken::password')}"
          service_user/auth_url:
            value: "%{hiera('nova::keystone::authtoken::auth_url')}"
          service_user/user_domain_name:
            value: "%{hiera('nova::keystone::authtoken::user_domain_name')}"
          service_user/project_name:
            value: "%{hiera('nova::keystone::authtoken::project_name')}"
          service_user/project_domain_name:
            value: "%{hiera('nova::keystone::authtoken::project_domain_name')}"
    
        cinder::config::cinder_config:
          keystone_authtoken/service_token_roles_required:
            value: true
          keystone_authtoken/service_token_roles:
            value: admin
          service_user/send_service_user_token:
            value: true
          service_user/username:
            value: cinder
          service_user/auth_strategy:
            value: keystone
          service_user/auth_type:
            value: password
          service_user/password:
            value: "%{hiera('cinder::keystone::authtoken::password')}"
          service_user/auth_url:
            value: "%{hiera('cinder::keystone::authtoken::auth_url')}"
          service_user/user_domain_name:
            value: "%{hiera('cinder::keystone::authtoken::user_domain_name')}"
          service_user/project_name:
            value: "%{hiera('cinder::keystone::authtoken::project_name')}"
          service_user/project_domain_name:
            value: "%{hiera('cinder::keystone::authtoken::project_domain_name')}"
    
      BlockStorageExtraConfig:
        cinder::config::cinder_config:
          keystone_authtoken/service_token_roles_required:
            value: true
          keystone_authtoken/service_token_roles:
            value: admin
          service_user/send_service_user_token:
            value: true
          service_user/username:
            value: cinder
          service_user/auth_strategy:
            value: keystone
          service_user/auth_type:
            value: password
          service_user/password:
            value: "%{hiera('cinder::keystone::authtoken::password')}"
          service_user/auth_url:
            value: "%{hiera('cinder::keystone::authtoken::auth_url')}"
          service_user/user_domain_name:
            value: "%{hiera('cinder::keystone::authtoken::user_domain_name')}"
          service_user/project_name:
            value: "%{hiera('cinder::keystone::authtoken::project_name')}"
          service_user/project_domain_name:
            value: "%{hiera('cinder::keystone::authtoken::project_domain_name')}"
  3. その他の環境ファイルと共にサービストークンの環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

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

第4章 仮想マシンのインスタンス

OpenStack Compute (nova) は、仮想マシンをオンデマンドで提供する中核的なコンポーネントです。Compute は、認証には Identity サービス (keystone)、インスタンスを起動するイメージには Image サービス (glance)、ユーザー/管理者用のインターフェースには Dashboard サービスと対話します。

Red Hat OpenStack Platform (RHOSP) により、クラウド内の仮想マシンインスタンスを容易に管理することができます。Compute サービスはインスタンスの作成、スケジューリング、管理を行い、この機能をその他の OpenStackコンポーネントに公開します。本章では、これらの手順に加えて、キーペア、セキュリティーグループ、ホストアグリゲート、フレーバーなどのコンポーネントを追加する手順について説明します。OpenStack の インスタンス という用語は、仮想マシンインスタンスを意味します。

4.1. インスタンスの管理

インスタンスを作成する前には、その他の特定の OpenStack コンポーネント (例: ネットワーク、キーペア、イメージ、ブートソースとなるボリュームなど) をそのインスタンスが利用できる状態にしておく必要があります。

本項では、これらのコンポーネントを追加して、インスタンスを作成/管理する手順について説明します。インスタンスの管理には、更新、ログイン、使用状況の確認、リサイズ、削除などの操作が含まれます。

4.1.1. コンポーネントの追加

以下の各項の手順に従って、ネットワーク、キーペアを作成し、イメージまたはボリュームソースをアップロードします。デフォルトで利用できないインスタンスを作成する場合は、これらのコンポーネントを使用します。また、新規セキュリティーグループ作成して、ユーザーが SSH アクセスできるようにする必要があります。

  1. Dashboard で プロジェクト を選択します。
  2. ネットワーク > ネットワーク を選択し、新規インスタンスを接続することができるプライベートネットワークが存在していることを確認してください (ネットワークの作成方法については『ネットワークガイド』「ネットワークの作成」のセクションを参照してください)。
  3. コンピュート > アクセスとセキュリティー > キーペア を選択して、キーペアが存在していることを確認します (キーペアの作成方法については、「キーペアの作成」を参照)。
  4. ブートソースに使用可能なイメージまたはボリュームのいずれかがあることを確認してください。

    • ブートソースのイメージを表示するには、イメージ タブを選択します (イメージを作成する場合は「イメージの作成」を参照してください)。
    • ブートソースのボリュームを表示するには、ボリューム タブを選択します (ボリュームを作成する場合は『ストレージガイド』「ボリュームの作成」を参照してください)。
  5. コンピュート > アクセスとセキュリティー > セキュリティーグループ を選択し、セキュリティーグループルールが作成済みであることを確認します (セキュリティーグループの作成については、『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください)。

4.1.2. インスタンスの起動

Dashboard から 1 つまたは複数のインスタンスを起動します。

注記

デフォルトでは、インスタンスの起動フォームがインスタンスの起動に使用されます。ただし、必要なステップを簡単に実行することのできるインスタンスの起動ウィザードを有効にすることも可能です。詳細は、「付録B インスタンスの起動ウィザードの有効化」を参照してください。

  1. Dashboard で プロジェクト > コンピュート > インスタンス を選択します。
  2. インスタンスの起動 をクリックします。
  3. 各フィールド (* は必須フィールドを表します) に設定値を入力し、起動 をクリックします。

指定したオプションに基づいて、1 つまたは複数のインスタンスが作成され、起動されます。

注意

ルートディスクサイズがコンピュートノードの HDD より大きい場合、Block Storage (cinder) ボリュームでインスタンスを起動することはできません。インスタンスが Block Storage ボリュームで起動できるようにするには、以下の回避策のいずれかを使用します。

  • ルートディスクおよび一時ディスクが 0 に設定されたフレーバーを使用する。
  • NovaSchedulerDefaultFilters 設定から DiskFilter を削除する。

4.1.2.1. インスタンスの起動のオプション

以下の表には、新しいインスタンスの起動フォームを使用して新規インスタンスを起動する際に利用可能なオプションをまとめています。インスタンスの起動ウィザードでも同じオプションが利用できます。

表4.1 インスタンスの起動フォームのオプション

タブフィールド説明

プロジェクトおよびユーザー

プロジェクト

一覧からプロジェクトを選択します。

 

ユーザー

一覧からユーザーを選択します。

詳細

アベイラビリティーゾーン

ゾーンとは、インスタンスが配置されるクラウドリソースの論理グループです。不明な場合にはデフォルトのゾーンを使用してください (詳しくは「ホストアグリゲートの管理」を参照)。

 

インスタンス名

インスタンスを識別するための名前

 

フレーバー

フレーバーは、インスタンスに提供されるリソースを決定します (例: メモリー)。デフォルトのフレーバーの割り当ておよび新規フレーバー作成に関する情報は、「フレーバーの管理」を参照してください。

 

インスタンス数

ここに記載のパラメーターで作成するインスタンスの数。1 が事前に設定されています。

 

インスタンスのブートソース

選択した項目に応じて異なる新規フィールドが表示され、ソースを選択することができます。

  • イメージソースは OpenStack との互換性がある必要があります (「イメージの管理」を参照)。
  • ボリュームまたはボリュームソースを選択した場合、そのソースはイメージを使用してフォーマットする必要があります (『ストレージガイド』「ボリュームの基本的な使用方法と設定」を参照)。

アクセスとセキュリティー

キーペア

指定したキーペアがインスタンスに挿入され、SSH を使用したインスタンスへのリモートアクセスに使用されます (直接のログイン情報や静的キーペアが提供されない場合)。通常は 1 プロジェクトあたり 1 つのキーペアが作成されます。

 

セキュリティーグループ

セキュリティーグループには、インスタンスのネットワークトラフィックの種別と方向をフィルタリングするファイアウォールルールが含まれます。グループの設定に関する情報は、『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください。

ネットワーク

選択済みネットワーク

ネットワークは、少なくとも 1 つ選択する必要があります。インスタンスは通常プライベートネットワークに割り当てられ、その後に Floating IP アドレスが割り当てられて外部アクセスが可能になります。

作成後

カスタマイズスクリプトの入力方法

インスタンスのブート後に実行されるコマンドセットまたはスクリプトファイルを指定することができます (例: インスタンスのホスト名やユーザーパスワードの設定など)。直接入力 を選択した場合には、スクリプトデータフィールドにコマンドを書き込みます。それ以外の場合には、スクリプトファイルを指定してください。

注記

#cloud-config」で開始するスクリプトは、cloud-config 構文を使用するものとして解釈されます (この構文についての情報は、http://cloudinit.readthedocs.org/en/latest/topics/examples.html を参照してください)。

高度な設定

ディスクパーティション

デフォルトでは、インスタンスは単一のパーティションとして作成されて、必要に応じて動的にリサイズされます。ただし、パーティションを手動で設定する方法を選択することも可能です。

 

コンフィグドライブ

このオプションを選択した場合には、OpenStack はメタデータを読み取り専用の設定ドライブに書き込みます。インスタンスがブートした後には、このドライブをマウントしてコンテンツを表示することができます (これにより、ユーザーがファイルをインスタンスに提供することが可能となります)。

4.1.3. インスタンスの更新

インスタンスを更新するには、プロジェクト > コンピュート > インスタンス を選択してから、そのインスタンスに対して実行するアクションを アクション コラムで選択します。これらのアクションにより、数多くの方法でインスタンスを操作することができます。

表4.2 インスタンスの更新オプション

アクション説明

スナップショットの作成

スナップショットは、実行中のインスタンスのディスクの状態を保存します。スナップショットは、インスタンスの移行やバックアップコピーの保存などの目的で作成することができます。

Floating IP の割り当て/割り当て解除

外部のネットワークとの通信および外部ユーザーによるアクセスを可能にするには、インスタンスを Floating IP アドレス (外部) に割り当てる必要があります。外部サブネットには、外部アドレスの数が限定されているため、使用していないアドレスは割り当て解除することを推奨します。

インスタンスの編集

インスタンスの名前を更新して、セキュリティーグループを割り当てます。

セキュリティーグループの編集

利用可能なセキュリティーグループの一覧を使用して、インスタンスにセキュリティーグループを追加/削除します (グループの設定についての詳しい説明は、『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください)。

コンソール

ブラウザーでインスタンスのコンソールを表示します (インスタンスに容易にアクセスすることができます)。

ログの参照

インスタンスのコンソールログの最新のセクションを表示します。このログを開く時「すべてのログの表示」をクリックすると、ログ全体を参照することができます。

インスタンスの一時停止/再開

インスタンスを即時に一時停止します (操作を確認するメッセージは表示されません)。インスタンスの状態はメモリー (RAM) に保存されます。

インスタンスの休止/再開

インスタンスを即時に休止します (操作を確認するメッセージは表示されません)。ハイバネートと同様に、インスタンスの状態はディスクに保存されます。

インスタンスのリサイズ

インスタンスのリサイズ ウィンドウが表示されます (「インスタンスのリサイズ」を参照)。

ソフトリブート

インスタンスを正常に停止して再起動します。ソフトリブートは、全プロセスを正常にシャットダウンしてから、インスタンスを再起動するように試みます。

ハードリブート

インスタンスを停止して再起動します。ハードリブートは、実質的にはインスタンスの 電源 をオフにしてから再びオンにします。

インスタンスのシャットダウン

インスタンスを正常に停止します。

インスタンスの再ビルド

イメージおよびディスクパーティションのオプションを使用してイメージを再作成します (インスタンスをシャットダウンして、イメージを再作成して、再起動します)。このオプションは、オペレーティングシステムに問題が発生した場合に、インスタンスを終了して一からやり直すよりも簡単です。

インスタンスの終了

インスタンスを完全に破棄します (操作を確認するメッセージが表示されます)。

外部の IP アドレスを作成して確保することができます。「Floating IP アドレスの作成、割り当て、解放」を参照してください。

4.1.4. インスタンスのリサイズ

インスタンスのリサイズ (メモリーまたは CPU 数) を行うには、適切な容量のあるインスタンスで新規フレーバーを選択する必要があります。サイズを大きくする場合には、ホストに十分な容量があることをあらかじめ確認することを忘れないようにしてください。

  1. 各ホストに SSH 鍵認証を設定してホスト間の通信が可能な状態にし、Compute が SSH を使用してディスクを他のホストに移動できるようにします。たとえば、コンピュートノードが同じ SSH 鍵を共有できます。
  2. 元のホストでリサイズを有効にするには、Controller ロールについて allow_resize_to_same_host パラメーターを True に設定します。

    注記

    allow_resize_to_same_host パラメーターによって、同じホスト上のインスタンスはリサイズされません。このパラメーターが全コンピュートノードで True に指定されている場合も、スケジューラーは同じホスト上のインスタンスのりサイズを強制しません。これは、想定されている動作です。

  3. Dashboard で プロジェクト > コンピュート > インスタンス を選択します。
  4. インスタンスの アクション コラムの矢印をクリックして、インスタンスのリサイズ を選択します。
  5. 新しいフレーバー フィールドで新規フレーバーを選択します。
  6. 起動時にインスタンスのパーティション分割を手動で行うには、以下の手順で設定します (これにより、ビルドタイムが短縮されます)。

    1. 高度な設定 を選択します。
    2. ディスクパーティション フィールドで、手動 を選択します。
  7. リサイズ をクリックします。

4.1.5. インスタンスへの接続

Dashboard またはコマンドラインインターフェースを使用して、インスタンスのコンソールにアクセスすることができます。また、インスタンスのシリアルポートに直接接続して、ネットワーク接続に失敗しても、デバッグを行うことができます。

4.1.5.1. Dashboard を使用したインスタンスのコンソールへのアクセス

ダッシュボードからインスタンスのコンソールに接続することができます。

手順

  1. Dashboard で コンピュート > インスタンス を選択します。
  2. インスタンスの ドロップダウンメニュー をクリックして、コンソール を選択します。 console access
  3. イメージのユーザー名とパスワードを使用してログインします (例: CirrOS イメージでは「cirros」と「cubswin:)」を使用します)。

4.1.5.2. CLI を使用したインスタンスのコンソールへのアクセス

ブラウザーに VNC コンソールの URL を入力して、インスタンスの VNC コンソールに直接接続することができます。

手順

  1. インスタンスの VNC コンソールの URL を表示するには、以下のコマンドを入力します。

    $ openstack console url show <vm_name>
    +-------+------------------------------------------------------+
    | Field | Value					     	       |
    +-------+------------------------------------------------------+
    | type  | novnc					               |
    | url	| http://172.25.250.50:6080/vnc_auto.html?token=       |
    |	| 962dfd71-f047-43d3-89a5-13cb88261eb9         	       |
    +-------+-------------------------------------------------------+
  2. VNC コンソールに直接接続するには、ブラウザーに表示される URL を入力します。

4.1.6. インスタンスの使用状況の表示

以下のような使用状況統計が提供されます。

  • プロジェクト別

    プロジェクト別の使用状況を確認するには、プロジェクト > コンピュート > 概要 を選択します。全プロジェクトインスタンスの使用状況の概要が即時に表示されます。

    使用状況を照会する期間を指定して 送信 ボタンをクリックすると、特定の期間の統計を表示することもできます。

  • ハイパーバイザー別

    管理者としてログインしている場合には、全プロジェクトの情報を表示することができます。管理 > システム をクリックしてからタブを 1 つ選択します。たとえば、リソース使用状況 タブでは、特定の期間のレポートを確認することができます。また、ハイパーバイザー をクリックすると、現在の仮想 CPU、メモリー、ディスクの統計を確認することができます。

    注記

    仮想 CPU 使用量 の値 (y 中 x 使用中) には、全仮想マシンの仮想 CPU の合計数 (x) とハイパーバイザーのコアの合計数 (y) が反映されます。

4.1.7. インスタンスの削除

  1. Dashboard で プロジェクト > コンピュート > インスタンス を選択して、対象のインスタンスにチェックを付けます。
  2. インスタンスの削除 をクリックします。
注記

インスタンスを削除しても、接続されていたボリュームは削除されません。この操作は別途実行する必要があります (『ストレージガイド』「ボリュームの削除」を参照)。

4.1.8. 複数のインスタンスの同時管理

同時に複数のインスタンスを起動する必要がある場合には (例: コンピュートまたはコントローラーのメンテナンスでダウンしている場合など)、プロジェクト > コンピュート > インスタンス から簡単に起動できます。

  1. 起動するインスタンスの最初のコラムにあるチェックボックスをクリックします。全インスタンスを選択するには、表の最初の行のチェックボックスをクリックします。
  2. 表の上にある その他のアクション をクリックして インスタンスの起動 を選択します。

同様に、適切なアクションを選択して、複数のインスタンスを終了またはソフトリブートすることができます。

4.2. インスタンスのセキュリティーの管理

適切なセキュリティーグループ (ファイアウォールのルールセット) およびキーペア (SSH を介したユーザーのアクセスの有効化) を割り当てることによってインスタンスへのアクセスを管理することができます。また、インスタンスに Floating IP アドレスを割り当てて外部ネットワークへのアクセスを有効にすることができます。以下の各項では、キーペア、セキュリティーグループ、Floating IP アドレスの作成/管理方法と SSH を使用したログインの方法について説明します。また、インスタンスに admin パスワードを挿入する手順についても記載しています。

セキュリティーグループの管理に関する情報は、『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください。

4.2.1. キーペアの管理

キーペアにより、インスタンスへ SSH でアクセスすることができます。キーペアの生成時には毎回、証明書がローカルマシンにダウンロードされ、ユーザーに配布できます。通常は、プロジェクトごとにキーペアが 1 つ作成されます (そのキーペアは、複数のインスタンスに使用されます)。

既存のキーペアを OpenStack にインポートすることも可能です。

4.2.1.1. キーペアの作成

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. キーペア タブで キーペアの作成 をクリックします。
  3. キーペア名 フィールドに名前を指定し、キーペアの作成 をクリックします。

キーペアが作成されると、ブラウザーを介してキーペアファイルが自動的にダウンロードされます。後ほど外部のマシンから接続できるように、このファイルを保存します。また、コマンドラインの SSH 接続には、以下のコマンドを実行して、このファイルを SSH にロードすることができます。

# ssh-add ~/.ssh/os-key.pem

4.2.1.2. キーペアのインポート

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. キーペア タブで キーペアのインポート をクリックします。
  3. キーペア名 のフィールドに名前を指定し、公開鍵の内容をコピーして、公開鍵 のフィールドにペーストします。
  4. キーペアのインポート をクリックします。

4.2.1.3. キーペアの削除

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. キーペア タブでそのキーの キーペアの削除 ボタンをクリックします。

4.2.2. セキュリティーグループの作成

セキュリティーグループとは、プロジェクトのインスタンスに割り当て可能な IP フィルターのルールセットで、インスタンスへのネットワークのアクセス権限を定義します。セキュリティーグループはプロジェクト別になっており、プロジェクトメンバーは自分のセキュリティーグループのデフォルトルールを編集して新規ルールセットを追加することができます。

  1. Dashboard で プロジェクト タブを選択して、コンピュート > アクセスとセキュリティー をクリックします。
  2. セキュリティーグループ タブで、+ セキュリティーグループの作成 をクリックします。
  3. セキュリティーグループに名前と説明を指定して、セキュリティーグループの作成 をクリックします。

プロジェクトセキュリティーの管理に関する情報は、『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください。

4.2.3. Floating IP アドレスの作成、割り当て、解放

デフォルトでは、インスタンスを最初に作成する際に、そのインスタンスに内部 IP アドレスが割り当てられます。ただし、Floating IP アドレス (外部アドレス) を作成して割り当てることによりパブリックネットワークを介したアクセスを有効にすることができます。インスタンスに割り当てられている IP アドレスは、インスタンスの状態に関わらず変更することができます。

プロジェクトには、使用できる Floating IP アドレスの範囲が限定されているので (デフォルトの上限は 50)、必要がなくなったアドレスは、再利用できるように解放することを推奨します。Floating IP アドレスは、既存の Floating IP プールからのみ確保することができます。詳細は『ネットワークガイド』「Floating IP アドレスプールの作成」を参照してください。

4.2.3.1. プロジェクトへの Floating IP アドレスの確保

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. Floating IP タブで Floating IP の確保 をクリックします。
  3. プール のフィールドで、IP アドレスを確保するネットワークを選択します。
  4. IP の確保 をクリックします。

4.2.3.2. Floating IP の割り当て

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. Floating IP タブでアドレスの 割り当て ボタンをクリックします。
  3. IP アドレスフィールドで割り当てるアドレスを選択します。

    注記

    割り当てることのできるアドレスがない場合には、+ ボタンをクリックして新規アドレスを作成することができます。

  4. IP を割り当てるポート フィールドで割り当て先となるインスタンスを選択します。1 つのインスタンスに割り当てることができる Floating IP アドレスは 1 つのみです。
  5. 割り当て をクリックします。

4.2.3.3. Floating IP の解放

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. Floating IP タブで、アドレスの 割り当て/割り当て解除 ボタンの横にある矢印メニューをクリックします。
  3. Floating IP の解放 を選択します。

4.2.4. インスタンスへのログイン

前提条件

  • インスタンスのセキュリティーグループには SSH ルールが設定されているようにしてください (『ユーザーおよびアイデンティティー管理ガイド』「プロジェクトのセキュリティー管理」を参照してください)。
  • インスタンスに Floating IP アドレス (外部アドレス) が割り当てられていることを確認します (「Floating IP アドレスの作成、割り当て、解放」を参照)。
  • インスタンスのキーペアの証明書を取得します。証明書は、キーペアの作成時にダウンロードされます。キーペアを自分で作成しなかった場合には、管理者に問い合わせてください (「キーペアの管理」を参照)。

最初に、キーペアのファイルを SSH に読み込み、次に名前を指定せずに ssh を使用します

  1. 生成したキーペアの証明書のアクセス権を変更します。

    $ chmod 600 os-key.pem
  2. ssh-agent がすでに実行されているかどうかを確認します。

    # ps -ef | grep ssh-agent
  3. 実行されていない場合には、次のコマンドで起動します。

    # eval `ssh-agent`
  4. ローカルマシンで、キーペアの証明書を SSH に読み込みます。以下に例を示します。

    $ ssh-add ~/.ssh/os-key.pem
  5. これで、イメージにより提供されるユーザーで、ファイルに SSH アクセスできるようになりました。

以下のコマンドの例は、Red Hat Enterprise Linux のゲストイメージに cloud-user として SSH アクセスする方法を示しています。

$ ssh cloud-user@192.0.2.24
注記

証明書を直接使用することも可能です。以下は例になります。

$ ssh -i /myDir/os-key.pem cloud-user@192.0.2.24

4.2.5. インスタンスへの admin パスワード挿入

以下の手順に従って、admin (root) パスワードを挿入することができます。

  1. /etc/openstack-dashboard/local_settings ファイルで、change_set_password パラメーターの値を True に設定します。

    can_set_password: True
  2. Compute 環境ファイルの inject_password パラメーターを「True」に設定します。

    inject_password=true
  3. Compute サービスを再起動します。

    # service nova-compute restart

nova boot コマンドを使用して、新規インスタンスを起動する際には、コマンドの出力に adminPass パラメーターが表示されます。このパスワードを使用して、インスタンスに root ユーザーとしてログインすることができます。

Compute サービスは、/etc/shadow ファイル内のパスワード値を root ユーザー用に上書きします。以下の手順は、KVM ゲストイメージの root アカウントをアクティブ化するのにも使用することが可能です。KVM ゲストイメージの使用方法についての詳しい情報は、「Red Hat OpenStack Platform における KVM ゲストイメージの使用」を参照してください。

Dashboard からカスタムパスワードを設定することも可能です。これを有効にするには、can_set_password パラメーターを true に設定した後に、以下のコマンドを実行します。

# systemctl restart httpd.service

新規追加された admin パスワードフィールドは以下のように表示されます。

dashboard

上記のフィールドは、インスタンスの起動/再ビルド時に使用することができます。

4.3. フレーバーの管理

作成する各インスタンスには、インスタンスのサイズや容量を決定するためのフレーバー (リソースのテンプレート) を指定します。また、フレーバーを使用して、セカンダリー一時ストレージやスワップディスク、使用率を制限するためのメタデータ、特別なプロジェクトへのアクセスを指定することも可能です (デフォルトのフレーバーにはこのような追加の属性は一切定義されていません)。

表4.3 デフォルトのフレーバー

名前仮想 CPU の数メモリールートディスクのサイズ

m1.tiny

1

512 MB

1 GB

m1.small

1

2048 MB

20 GB

m1.medium

2

4096 MB

40 GB

m1.large

4

8192 MB

80 GB

m1.xlarge

8

16384 MB

160 GB

エンドユーザーの大半は、デフォルトのフレーバーを使用できます。ただし、特化したフレーバーを作成/管理することができます。たとえば、以下の操作を行うことができます。

  • 基になるハードウェアの要件に応じて、デフォルトのメモリーと容量を変更する
  • インスタンスに特定の I/O レートを強制するためのメタデータ、またはホストアグリゲートと一致させるためのメターデータを追加する
注記

イメージのプロパティーを使用して設定した動作は、フレーバーを使用して設定した動作よりも優先されます。詳しい説明は、「イメージの管理」を参照してください。

4.3.1. 設定パーミッションの更新

デフォルトでは、フレーバーの作成およびフレーバーの完全リストの表示ができるのは管理者のみです (「管理 > システム > フレーバー」を選択)。全ユーザーがフレーバーを設定できるようにするには、/etc/nova/policy.json ファイル (nova-api サーバー) で以下の値を指定します。

"compute_extension:flavormanage": "",

4.3.2. フレーバーの作成

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > フレーバー を選択します。
  2. フレーバーの作成 をクリックして、以下のフィールドに入力します。

    表4.4 フレーバーのオプション

    タブフィールド説明

    フレーバー情報

    名前

    一意な名前

     

    ID

    一意な ID。デフォルト値は auto で、UUID4 値を生成しますが、整数または UUID4 値 を手動で指定することもできます。

     

    仮想 CPU

    仮想 CPU 数

     

    メモリー (MB)

    メモリー (メガバイト単位)

     

    ルートディスク (GB)

    一時ディスクのサイズ (ギガバイト単位)。ネイティブイメージサイズを使用するには 0 を指定します。このディスクは、Instance Boot Source=Boot from Volume と指定されている場合には使用されません。

     

    一時ディスク (GB)

    インスタンスで利用可能なセカンダリー一時ディスクのサイズ (ギガバイト単位)。このディスクは、インスタンスの削除時に破棄されます。

    デフォルト値は 0 です。この値を指定すると、一時ディスクは作成されません。

     

    スワップディスク (MB)

    スワップディスクのサイズ (メガバイト単位)

    フレーバーアクセス権

    選択済みのプロジェクト

    そのフレーバーを使用することができるプロジェクト。プロジェクトが選択されていない場合には、全プロジェクトにアクセスが提供されます (Public=Yes)。

  3. フレーバーの作成 をクリックします。

4.3.3. 一般属性の更新

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > フレーバー を選択します。
  2. 対象のフレーバーの フレーバーの編集 ボタンをクリックします。
  3. 値を更新して、保存 をクリックします。

4.3.4. フレーバーのメタデータの更新

一般属性の編集に加えて、フレーバーにメタデータ (extra_specs) を追加することが可能です。メタデータは、インスタンスの使用方法を微調整するのに役立ちます。たとえば、最大許容帯域幅やディスクの書き込みを設定する場合などです。

  • 事前定義済みのキーにより、ハードウェアサポートやクォータが決定されます。事前定義済みのキーは、使用するハイパーバイザーによって限定されます (libvirt の場合は 表4.5「Libvirt のメタデータ」を参照してください)。
  • 事前定義済みおよびユーザー定義のキーはいずれも、インスタンスのスケジューリングを決定します。たとえば、SpecialComp=True と指定すると、このフレーバーを使用するインスタンスはすべてメタデータのキーと値の組み合わせが同じホストアグリゲートでのみ実行可能となります (「ホストアグリゲートの管理」を参照)。

4.3.4.1. メタデータの表示

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > フレーバー を選択します。
  2. フレーバーの メタデータ リンク (はい または いいえ) をクリックします。現在の値はすべて右側の 選択済みのメタデータ の下に一覧表示されます。

4.3.4.2. メタデータの追加

キーと値 のペアを使用してフレーバーのメタデータを指定します。

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > フレーバー を選択します。
  2. フレーバーの メタデータ リンク (はい または いいえ) をクリックします。現在の値はすべて右側の 選択済みのメタデータ の下に一覧表示されます。
  3. 利用可能なメタデータその他 のフィールドをクリックして、追加するキーを指定します (表4.5「Libvirt のメタデータ」を参照)。
  4. 「+」ボタンをクリックします。選択済みのメタデータ の下に新しいキーが表示されるようになりました。
  5. 右側のフィールドにキーの値を入力します。

    flavor metadata

  6. キーと値のペアの追加が終了したら 保存 をクリックします。

表4.5 Libvirt のメタデータ

キー説明

hw:action

インスタンスごとにサポート制限を設定するアクション。有効なアクションは以下のとおりです。

  • cpu_max_sockets: サポートされている最大の CPU ソケット数
  • cpu_max_cores: サポートされている最大の CPU コア数
  • cpu_max_threads: サポートされている最大の CPU スレッド数
  • cpu_sockets: 推奨される CPU ソケット数
  • cpu_cores: 推奨される CPU コア数
  • cpu_threads: 推奨される CPU スレッド数
  • serial_port_count: 1 インスタンスあたりの最大シリアルポート数

例: hw:cpu_max_sockets=2

hw:NUMA_def

インスタンスの NUMA トポロジーの定義。RAM および vCPU の割り当てがコンピュートホスト内の NUMA ノードのサイズよりも大きいフレーバーの場合には、NUMA トポロジーを定義することでホストが NUMA を効果的に使用してゲスト OS のパフォーマンスを向上することができます。フレーバーで定義された NUMA の定義は、イメージの定義をオーバーライドします。有効な定義は以下のとおりです。

  • numa_nodes: インスタンスに公開する NUMA ノードの数。イメージの NUMA 設定が上書きされるようにするには 1 を指定します。
  • numa_cpus.0: 仮想 CPU N-M を NUMA ノード 0 へマッピング (コンマ区切りの一覧)
  • numa_cpus.1: 仮想 CPU N-M を NUMA ノード 1 へマッピング (コンマ区切りの一覧)
  • numa_mem.0: メモリー N MB を NUMA ノード 0 へマッピング
  • numa_mem.1: メモリー N MB を NUMA ノード 1 へマッピング
  • numa_cpu.N および numa_mem.N は、numa_nodes が設定されている場合のみに有効です。また、これらの定義が必要になるのは、インスタンスの NUMA ノードの CPU および RAM が対称的に割り当てられていない場合のみです (NFV ワークロードの一部には重要)。
注記

numa_cpu または numa_mem.N の値が利用可能な値よりも多く指定されている場合には、例外が発生します。

インスタンスに 8 個の仮想 CPU、4 GB の RAM が指定されている場合の例:

  • hw:numa_nodes=2
  • hw:numa_cpus.0=0,1,2,3,4,5
  • hw:numa_cpus.1=6,7
  • hw:numa_mem.0=3072
  • hw:numa_mem.1=1024

スケジューラーは、NUMA ノードが 2 つあり、そのうちの 1 つのノードで 6 つの CPU および 3072 MB または 3 GB のメモリーを実行し、別のノードで 2 つの CPU および 1024 MB または 1 GB のメモリーを実行できるホストを検索します。ホストに 8 つの CPU および 4 GB のメモリーを実行できる NUMA ノードが 1 つある場合は、有効な一致とは見なされません。

hw:watchdog_action

インスタンスのウォッチドッグデバイスを使用して、インスタンスに何らかの理由でエラー (またはハング) が発生した場合にアクションをトリガーすることができます。有効なアクションは以下のとおりです。

  • disabled: デバイスは接続されません (デフォルト値)。
  • pause: インスタンスを一時停止します。
  • poweroff: インスタンスを強制終了します。
  • reset: インスタンスを強制リセットします。
  • none: ウォッチドッグを有効化しますが、インスタンスにエラーが発生してもアクションは実行しません。

例: hw:watchdog_action=poweroff

hw:pci_numa_affinity_policy

このパラメーターを使用して、PCI パススルーデバイスおよび SR-IOV インターフェースの NUMA アフィニティーポリシーを指定することができます。以下の有効な値のいずれかに設定します。

  • required: インスタンスの NUMA ノードの少なくとも 1 つが PCI デバイスとのアフィニティーを持つ場合に限り、Compute サービスは PCI デバイスを要求するインスタンスを作成します。このオプションは、最高のパフォーマンスを提供します。
  • preferred: Compute サービスは、NUMA アフィニティーに基づきベストエフォートで PCI デバイスの選択を試みます。これができない場合には、Compute サービスは PCI デバイスとのアフィニティーを持たない NUMA ノード上でインスタンスをスケジュールします。
  • legacy: (デフォルト) 以下のいずれかの場合に、Compute サービスは PCI デバイスを要求するインスタンスを作成します。

    • PCI デバイスが少なくとも 1 つの NUMA ノードとのアフィニティーを持つ。
    • PCI デバイスが NUMA アフィニティーに関する情報を提供しない。

例: hw:pci_numa_affinity_policy=required

hw_rng:action

イメージプロパティーを使用して乱数生成器をインスタンスに追加することができます (Red Hat OpenStack Platform ドキュメントの『Command-Line Interface Reference』で hw_rng_model を参照してください)。

このデバイスを追加した場合の有効なアクションは以下のとおりです。

  • allowed: True に指定すると、デバイスが有効化され、False に指定すると無効化されます。デフォルトではデバイスは無効となっています。
  • rate_bytes: エントロピープールを満たすために、インスタンスのカーネルが rate_period (整数) の間隔でホストから読み取ることのできる最大のバイト数
  • rate_period: 秒単位で示した読み取り期間 (整数)

例: hw_rng:allowed=True

hw_video:ram_max_mb

ビデオデバイスの最大許容 RAM (MB 単位)

例: hw:ram_max_mb=64

quota:option

インスタンスの制限を強制します。有効なオプションは以下のとおりです。

  • cpu_period: cpu_quota を強制する時間 (マイクロ秒単位)。指定した cpu_period 内では、各仮想 CPU は cpu_quota を超えるランタイムを使用することはできません。値は [1000, 1000000] の範囲内で指定する必要があります。0値なし を意味します。
  • cpu_quota: 各 cpu_period における仮想 CPU の最大許容帯域幅 (マイクロ秒単位)。この値は、[1000, 18446744073709551] の範囲内で指定する必要があります。0値なし を意味し、負の値は仮想 CPU が制御されないことを意味します。cpu_quota および cpu_period を使用して、全仮想 CPU が同じ速度で実行されるようにすることができます。
  • cpu_shares: ドメインの CPU 時間の共有。この値は、同じドメイン内の他のマシンに対する重み付けがされている場合にのみに有意となります。つまり、200 のフレーバーを使用するインスタンスには、100 のインスタンスのマシン時間の 2 倍の時間が割り当てられることになります。
  • disk_read_bytes_sec: 最大のディスク読み取り速度 (バイト毎秒単位)
  • disk_read_iops_sec: 1 秒あたりの最大の読み取り I/O 操作回数
  • disk_write_bytes_sec: 最大のディスク書き込み速度 (バイト毎秒単位)
  • disk_write_iops_sec: 1 秒あたりの最大の書き込み I/O 操作回数
  • disk_total_bytes_sec: 総スループットの上限 (バイト毎秒単位)
  • disk_total_iops_sec: 1 秒あたりの最大の総 I/O 操作数
  • vif_inbound_average: 受信トラフィックの指定平均値
  • vif_inbound_burst: vif_inbound_peak の速度で受信可能なトラフィックの最大量
  • vif_inbound_peak: 受信トラフィックの最大受信速度
  • vif_outbound_average: 送信トラフィックの指定平均値
  • vif_outbound_burst: vif_outbound_peak の速度で送信可能なトラフィックの最大量
  • vif_outbound_peak: 送信トラフィックの最大送信速度

例: quota:vif_inbound_average=10240

さらに、VMware ドライバーは、CPU、メモリー、ディスク、ネットワークの上限、下限を制御する以下のクォータオプションや、テナントで利用可能なリソースの相対割り当てを制御するのに使用可能な 共有 をサポートします。

  • cpu_limit: 仮想マシンで利用可能な最大 CPU 周波数 (MHz 単位)
  • cpu_reservation: 仮想マシンで利用可能な確保済みの最大 CPU リソース (MHz 単位)
  • cpu_shares_level: 競合が発生した場合の CPU 割り当てレベル (共有)。許容値は highnormallow、および custom です。
  • cpu_shares_share: 割り当て済みの CPU 共有数。cpu_shares_levelcustom に設定されている場合のみ適用可能です。
  • memory_limit: 仮想マシンで利用可能な最大メモリー容量 (MB 単位)
  • memory_reservation: 仮想マシンで利用可能な確保済みの最大メモリー容量 (MB 単位)
  • memory_shares_level: 競合が発生した場合のメモリー割り当てレベル (共有)。許容値は highnormallow、および custom です。
  • memory_shares_share: 割り当て済みのメモリー共有数。memory_shares_levelcustom に設定されている場合のみ適用可能です。
  • disk_io_limit: 仮想マシンでの最大 I/O 使用率 (1 秒あたりの I/O 操作回数単位)
  • disk_io_reservation: 仮想マシンで利用可能な確保済みの最大ディスクリソース (1 秒あたりの I/O 操作回数単位)
  • disk_io_shares_level: 競合が発生した場合の I/O 割り当てレベル (共有)。許容値は highnormallow、および custom です。
  • disk_io_shares_share: 割り当て済みの I/O 共有数。disk_io_shares_levelcustom に設定されている場合のみ適用可能です。
  • vif_limit: 仮想ネットワークアダプターで利用可能な最大ネットワーク帯域幅 (Mbps 単位)
  • vif_reservation: 仮想ネットワークアダプターで利用可能な確保済みの最小ネットワーク帯域幅 (Mbps 単位)
  • vif_shares_level: 競合が発生した場合のネットワーク帯域幅の割り当てレベル (共有)。許容値は highnormallow、および custom です。
  • vif_shares_share: 割り当て済みの帯域幅共有数。vif_shares_levelcustom に設定されている場合のみ適用可能です。

4.4. ホストアグリゲートの管理

パフォーマンスおよび管理目的で、単一の Compute デプロイメントを複数の論理グループにパーティショニングすることができます。OpenStack では以下のような用語を使用しています。

  • ホストアグリゲート: ホストアグリゲートは、ホストをグループ化してまとめることによって OpenStack デプロイメント内に論理ユニットを作成します。アグリゲートは、割り当てられた Compute ホストと関連付けられたメタデータです。ホストアグリゲートの表示と作成ができるのは管理者のみです。

    アグリゲートのメタデータは通常、Compute のスケジューラーで使用する情報を提供します (例: 特定のフレーバーやイメージを複数のホストの 1 つのサブネットに制限するなど)。ホストアグリゲートで指定されるメタデータは、フレーバー内で同じメタデータが指定されているインスタンスにホストの使用を限定します。

    管理者は、ホストアグリゲートを使用して、ロードバランスの処理、物理的な分離 (または冗長) の強制、共通の属性を持つサーバーのグループ化、ハードウェアクラスの分類などを行うことができます。アグリゲートの作成時には、ゾーン名を指定する必要があります。この名前がエンドユーザーに表示されます。

  • アベイラビリティーゾーン: アベイラビリティーゾーンとは、ホストアグリゲートのエンドユーザーのビューです。エンドユーザーはゾーンがどのホストで構成されているかを表示したり、ゾーンのメタデータを確認したりすることはできません。ユーザーが見ることができるのはゾーン名のみです。

    一定の機能や一定のエリア内で設定された特定のゾーンを使用するようにエンドユーザーを誘導することができます。

4.4.1. ホストアグリゲートのスケジューリングの有効化

デフォルトでは、ホストアグリゲートのメタデータは、インスタンスの使用先のフィルタリングには使用されません。メタデータの使用を有効にするには、Compute のスケジューラーの設定を更新する必要があります。

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

    • ホストアグリゲートのメタデータ用の AggregateInstanceExtraSpecsFilter

      注記

      同じ NovaSchedulerDefaultFilters パラメーターの値として AggregateInstanceExtraSpecsFilter および ComputeCapabilitiesFilter フィルターの両方を指定する場合には、フレーバー extra_specs の設定にスコープを定義した仕様を使用する必要があります。使用しない場合には、ComputeCapabilitiesFilter は適切なホストの選択に失敗します。詳しくは 表4.7「スケジューリングフィルター」を参照してください。

    • インスタンス起動時のアベイラビリティーゾーンのホストの仕様用の AvailabilityZoneFilter
  3. 設定ファイルを保存します。
  4. オーバークラウドをデプロイします。

4.4.2. アベイラビリティーゾーンまたはホストアグリゲートの表示

Dashboard に管理ユーザーとしてログインして 管理 > システム > ホストアグリゲート を選択します。ホストアグリゲート のセクションに現在定義済みのアグリゲートがすべてリストされます。アベイラビリティーゾーン のセクションには全ゾーンがリストされます。

4.4.3. ホストアグリゲートの追加

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > ホストアグリゲート を選択します。ホストアグリゲート のセクションに現在定義済みのアグリゲートがすべてリストされます。
  2. ホストアグリゲートの作成 をクリックします。
  3. 名前 フィールドにアグリゲートの名前を入力します。この名前が アベイラビリティーゾーン フィールドでエンドユーザーに表示されます。
  4. アグリゲートのホストの管理 をクリックします。
  5. 「+」アイコンをクリックしてホストを選択します。
  6. ホストアグリゲートの作成 をクリックします。

4.4.4. ホストアグリゲートの更新

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > ホストアグリゲート を選択します。ホストアグリゲート のセクションに現在定義済みのアグリゲートがすべてリストされます。
  2. インスタンスの 名前 または アベイラビリティーゾーン を更新するには、以下の手順で行います。

    • アグリゲートの ホストアグリゲートの編集 ボタンをクリックします。
    • 名前 または アベイラビリティーゾーン のフィールドを更新して、保存 をクリックします。
  3. インスタンスの 割り当て済みのホスト を更新するには、以下の手順で行います。

    • アクション の下にあるアグリゲートの矢印アイコンをクリックします。
    • ホストの管理 をクリックします。
    • 「+」または「-」のアイコンをクリックしてホストの割り当てを変更します。
    • 終了したら、保存 をクリックします。
  4. インスタンスの メタデータ を更新するには、以下の手順で行います。

    • アクション の下にあるアグリゲートの矢印アイコンをクリックします。
    • メタデータの更新 ボタンをクリックします。現在の値はすべて右側の 選択済みのメタデータ の下に一覧表示されます。
    • 利用可能なメタデータその他 のフィールドをクリックして、追加するキーを指定します。事前に定義したキー (表4.6「ホストアグリゲートのメタデータ」を参照) を使用するか、独自のキーを追加します (このキーと全く同じキーがインスタンスのフレーバーに設定されている場合にのみ有効となります)。
    • 「+」ボタンをクリックします。選択済みのメタデータ の下に新しいキーが表示されるようになりました。

      注記

      キーを削除するには、「-」のアイコンをクリックします。

    • 保存 をクリックします。

      表4.6 ホストアグリゲートのメタデータ

      キー説明

      filter_tenant_id

      指定した場合には、アグリゲートはこのテナント (プロジェクト) のみをホストします。これは、Compute のスケジューラーに設定されている AggregateMultiTenancyIsolation フィルターによって異なります。

4.4.5. ホストアグリゲートの削除

  1. Dashboard に管理ユーザーとしてログインして 管理 > システム > ホストアグリゲート を選択します。ホストアグリゲート のセクションに現在定義済みのアグリゲートがすべてリストされます。
  2. 割り当てられている全ホストをアグリゲートから削除します。

    1. アクション の下にあるアグリゲートの矢印アイコンをクリックします。
    2. ホストの管理 をクリックします。
    3. 「-」アイコンをクリックして、全ホストを削除します。
    4. 終了したら、保存 をクリックします。
  3. アクション の下にあるアグリゲートの矢印アイコンをクリックします。
  4. このダイアログ画面と次の画面で ホストアグリゲートの削除 をクリックします。

4.5. ホストのスケジュール

Compute のスケジューリングサービスは、インスタンスの配置先となるホスト (もしくはホストアグリゲート) を決定します。管理者は、設定を使用して、スケジューラーによるインスタンスの配置先の決定方法を定義することができます。たとえば、特定のグループや適切な量の RAM があるホストにスケジューリングを限定することが可能です。

以下のコンポーネントを設定することができます。

  • フィルター: インスタンスの配置先候補となるホストの初期セットを決定します (「スケジューリングフィルターの設定」を参照)。
  • 重み: フィルタリングの完了時に選出されたホストのセットは重み付けのシステムを使用して優先順位が決定されます。最も高い重みが最優先されます (「スケジューリングの重みの設定」を参照)。
  • スケジューラーサービス: スケジューラーホスト上の /var/lib/config-data/puppet-generated/<nova_container>/etc/nova/nova.conf ファイルには数多くの設定オプションがあります。これらのオプションは、スケジューラーがタスクを実行する方法や、重み/フィルターを処理する方法を決定します。

下図では、フィルタリング後には Host 1 と Host 3 の両方が条件に適合しています。Host 1 の重みが最も高いため、スケジューリングで最優先されます。

Scheduling Hosts

4.5.1. スケジューリングフィルターの設定

スケジューラーが使用するフィルターを定義するには、Compute 環境ファイルの NovaSchedulerDefaultFilters パラメーターにフィルターを追加または削除します。

デフォルト設定では、スケジューラーで以下のフィルターが実行されます。

  • RetryFilter
  • AvailabilityZoneFilter
  • ComputeFilter
  • ComputeCapabilitiesFilter
  • ImagePropertiesFilter
  • ServerGroupAntiAffinityFilter
  • ServerGroupAffinityFilter

一部のフィルターは、以下の方法でインスタンスに渡されるパラメーターの情報を使用します。

以下の表には、利用可能なすべてのフィルターをまとめています。

表4.7 スケジューリングフィルター

フィルター説明

AggregateImagePropertiesIsolation

インスタンスのイメージのメタデータが一致するホストアグリゲート内のホストのみを渡します。詳細は、「イメージの作成」を参照してください。

AggregateInstanceExtraSpecsFilter

ホストアグリゲート内のメタデータは、ホストのフレーバーのメタデータと一致する必要があります。詳細は、「フレーバーのメタデータの更新」を参照してください。

 

このフィルターを ComputeCapabilitiesFilter と同じ NovaSchedulerDefaultFilters パラメーターで使用するには、正しい名前空間でフレーバー extra_specs キーをプレフィックスしてそのスコープを定義する必要があります。

  • ComputeCapabilitiesFilter 名前空間: "capabilities:"
  • AggregateInstanceExtraSpecsFilter 名前空間: "aggregate_instance_extra_specs:"

AggregateMultiTenancyIsolation

filter_tenant_id を指定したホストには、そのテナント (プロジェクト) からのインスタンスのみを配置することができます。

注記

テナントが他のホストにインスタンスを配置することは可能です。

AllHostsFilter

利用可能な全ホストを渡します (ただし、他のフィルターは無効化しません)。

AvailabilityZoneFilter

インスタンスに指定されているアベイラビリティーゾーンを使用してフィルタリングします。

ComputeCapabilitiesFilter

Compute のメタデータが正しく読み取られるようにします。「:」よりも前の部分はすべて名前空間として読み取られます。たとえば、quota:cpu_period では quota が名前空間として、cpu_period がキーとして使用されます。

ComputeFilter

稼働中の有効なホストのみを渡します。

DifferentHostFilter

指定されている単一または複数のホストとは別のホスト上でインスタンスをビルドできるようにします。nova boot--different_host オプションを使用して、different (別の) ホストを指定します。

ImagePropertiesFilter

インスタンスのイメージプロパティーに一致するホストのみを渡します。詳細は、「イメージの作成」を参照してください。

IsolatedHostsFilter

isolated_hosts および isolated_images (コンマ区切りの値) を使用して指定されている分離されたイメージを実行中の分離されたホストのみを渡します。

JsonFilter

インスタンスのカスタム JSON フィルターを認識/使用します。

  • 有効な演算子: =、<、>、in、⇐、>=、not、or、and
  • 認識される値: $free_ram_mb、$free_disk_mb、$total_usable_ram_mb、$vcpus_total、$vcpus_used
 

このフィルターは、クエリーヒントとして nova boot コマンドで指定されます。以下に例を示します。

--hint query='['>=', '$free_disk_mb', 200 * 1024]'

MetricsFilter

このフィルタを使用して、metrics/weight_setting を使用して設定されたメトリックを報告するコンピュートノードにスケジューリングを制限します。

このフィルターを使用するには、Compute 環境ファイルに以下の設定を追加します。

parameter_defaults:
  ComputeExtraConfig:
    nova::config::nova_config:
      DEFAULT/compute_monitors:
        value: 'cpu.virt_driver'

デフォルトでは、Compute のスケジューリングサービスは 60 秒ごとにメトリックを更新します。メトリックが最新の状態になるようにするには、update_resources_interval 設定オプションを使用してメトリックデータの更新頻度を上げることができます。たとえば、以下の設定を使用すると、2 秒ごとにメトリックデータが更新されます。

parameter_defaults:
  ComputeExtraConfig:
    nova::config::nova_config:
      DEFAULT/update_resources_interval:
        value: '2'

NUMATopologyFilter

NUMA トポロジーに基づいてホストを除外します。インスタンスにトポロジーが未定義の場合には、任意のホストを使用することができます。このフィルターは、NUMA トポロジーが完全に同じインスタンスとホストをマッチングするように試みます (そのホスト上ではインスタンスのスケジューリングは試みません)。また、このフィルターは、NUMA ノードの標準的なオーバーサブスクリプションの上限を確認し、それに応じて、コンピュートホストに対して制限を指定します。

RetryFilter

スケジュールを試みて失敗したホストを除外します。scheduler_max_attempts が正の値の場合に有効です (デフォルトは「3」)。

SameHostFilter

指定されている単一または複数のホストを渡します。nova boot--hint same_host オプションを使用するインスタンスのホストを指定します。

ServerGroupAffinityFilter

特定のサーバーグループのホストのみを渡します。

  • サーバーグループにアフィニティーポリシーを指定します (nova server-group-create --policy affinity groupName)。
  • そのグループでインスタンスをビルドします (nova boot--hint group=UUID オプション)。

ServerGroupAntiAffinityFilter

インスタンスをまだホストしていないサーバーグループ内のホストのみを渡します。

  • サーバーグループにアンチアフィニティーポリシーを指定します (nova server-group-create --policy anti-affinity groupName)。
  • そのグループでインスタンスをビルドします (nova boot--hint group=UUID オプション)。

SimpleCIDRAffinityFilter

インスタンスの cidr および build_new_host_ip のヒントで指定されている IP サブネット範囲のホストのみを渡します。以下に例を示します。

--hint build_near_host_ip=192.0.2.0 --hint cidr=/24

4.5.2. スケジューリングの重みの設定

ホストは、スケジューリング用に重み付けすることができます。(フィルタリング後に) 重みが最大のホストが選択されます。(フィルタリング後に) 重みが最大のホストが選択されます。ノードの重みは以下のように計算されます。

w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...

重みのオプションは、コンピュートノードの設定ファイルで定義することができます。

表4.8 スケジューリングサービスの重みの設定オプション

設定オプション詳細

filter_scheduler/weight_classes

このパラメーターを使用して、各ホストの重みを計算するのに以下の属性のどれを使用するかを設定します。

  • nova.scheduler.weights.ram.RAMWeigher: コンピュートノードで利用可能な RAM を重み付けします。
  • nova.scheduler.weights.cpu.CPUWeigher: コンピュートノードで利用可能な CPU の数を重み付けします。
  • nova.scheduler.weights.disk.DiskWeigher: コンピュートノードで利用可能なディスクを重み付けします。
  • nova.scheduler.weights.metrics.MetricsWeigher: コンピュートノードのメトリクスを重み付けします。
  • nova.scheduler.weights.affinity.ServerGroupSoftAffinityWeigher: 指定したインスタンスグループの他のノードとコンピュートノードの近接性を重み付けします。
  • nova.scheduler.weights.affinity.ServerGroupSoftAntiAffinityWeigher: 指定したインスタンスグループの他のノードとコンピュートノードの近接性を重み付けします。
  • nova.scheduler.weights.compute.BuildFailureWeigher: 直近ブート試行の失敗回数でコンピュートノードを重み付けします。
  • nova.scheduler.weights.io_ops.IoOpsWeigher: ワークロードでコンピュートノードを重み付けします。
  • nova.scheduler.weights.pci.PCIWeigher: PCI の可用性でコンピュートノードを重み付けします。
  • nova.scheduler.weights.cross_cell.CrossCellWeigher: 置かれているセルに基づいてコンピュートノードを重み付けします。インスタンスを移動する際に、移行元セル内にあるコンピュートノードを優先します。
  • nova.scheduler.weights.all_weighers: (デフォルト) 上記の重み付け関数をすべて使用します。

型: 文字列

filter_scheduler/ram_weight_multiplier

このパラメーターを使用して、利用可能な RAM 容量に基づいてホストを重み付けするのに使用する重みの乗数を指定します。

利用可能な RAM 容量がより大きいホストを優先するには、正の値に設定します。この場合、インスタンスは多くのホストに分散されます。

利用可能な RAM 容量がより小さいホストを優先するには、負の値に設定します。この場合、可能な限り多くのインスタンスをホストに分担 (スタック) させた後に、使用率が低いホストをスケジューリングします。

正または負の絶対値で、他の重み付け関数と比べて RAM の重み付け関数をどれだけ優先するかを指定します。

デフォルトでは、スケジューラーはインスタンスをすべてのホストに均等に分散します (ram_weight_multiplier=1.0)。

型: 浮動小数点

filter_scheduler/disk_weight_multiplier

このパラメーターを使用して、利用可能なディスク容量に基づいてホストを重み付けするのに使用する重みの乗数を指定します。

利用可能なディスク容量がより大きいホストを優先するには、正の値に設定します。この場合、インスタンスは多くのホストに分散されます。

利用可能なディスク容量がより小さいホストを優先するには、負の値に設定します。この場合、可能な限り多くのインスタンスをホストに分担 (スタック) させた後に、使用率が低いホストをスケジューリングします。

正または負の絶対値で、他の重み付け関数と比べてディスクの重み付け関数をどれだけ優先するかを指定します。

デフォルトでは、スケジューラーはインスタンスをすべてのホストに均等に分散します (disk_weight_multiplier=1.0)。

型: 浮動小数点

filter_scheduler/cpu_weight_multiplier

このパラメーターを使用して、利用可能な仮想 CPU の数に基づいてホストを重み付けするのに使用する重みの乗数を指定します。

利用可能な仮想 CPU の数がより多いホストを優先するには、正の値に設定します。この場合、インスタンスは多くのホストに分散されます。

利用可能な仮想 CPU の数がより少ないホストを優先するには、負の値に設定します。この場合、可能な限り多くのインスタンスをホストに分担 (スタック) させた後に、使用率が低いホストをスケジューリングします。

正または負の絶対値で、他の重み付け関数と比べて仮想 CPU の重み付け関数をどれだけ優先するかを指定します。

デフォルトでは、スケジューラーはインスタンスをすべてのホストに均等に分散します (cpu_weight_multiplier=1.0)。

型: 浮動小数点

filter_scheduler/io_ops_weight_multiplier

このパラメーターを使用して、負荷に基づいてホストを重み付けするのに使用する重みの乗数を指定します。

負荷がより軽いホストを優先するには、負の値に設定します。この場合、負荷はより多くのホストに分散されます。

負荷がより重いホストを優先するには、正の値に設定します。この場合、インスタンスはすでにビジー状態にあるホストにスケジューリングされます。

正または負の絶対値で、他の重み付け関数と比べて I/O 操作の重み付け関数をどれだけ優先するかを指定します。

デフォルトでは、スケジューラーは負荷をより多くのホストに分散します (io_ops_weight_multiplier=-1.0)。

型: 浮動小数点

filter_scheduler/build_failure_weight_multiplier

このパラメーターを使用して、直近のビルド失敗回数に基づいてホストを重み付けするのに使用する重みの乗数を指定します。

ホストから報告される直近のビルド失敗回数をより重要視するには、正の値に設定します。直近ビルドに失敗したホストは、選択されにくくなります。

直近の失敗回数でコンピュートホストを重み付けするのを無効にするには、0 に設定します。

デフォルト: 1000000.0

型: 浮動小数点

filter_scheduler/cross_cell_move_weight_multiplier

このパラメーターを使用して、セルを越えて移動する際にホストを重み付けするのに使用する重みの乗数を指定します。このオプションは、インスタンスを移動する際に、同じ移動元セル内にあるホストに加える重みを決定します。インスタンスを移行する場合、デフォルトではスケジューラーは同じ移行元セル内にあるホストを優先します。

現在インスタンスを実行中のセル内にあるホストを優先するには、正の値に設定します。現在インスタンスを実行中のセルとは別のセルにあるホストを優先するには、負の値に設定します。

デフォルト: 1000000.0

型: 浮動小数点

filter_scheduler/pci_weight_multiplier

このパラメーターを使用して、ホスト上の PCI デバイスの数とインスタンスが要求する PCI デバイスの数に基づいてホストを重み付けするのに使用する重みの乗数を指定します。インスタンスが PCI デバイスを要求する場合、より多くの PCI デバイスを持つコンピュートノードにより高い重みが割り当てられます。

たとえば、ホストが 3 台利用可能で、PCI デバイスが 1 つのホストが 1 台、複数の PCI デバイスがあるホストが 1 台、PCI デバイスがないホストが 1 台の場合には、Compute のスケジューラーはインスタンスの需要に基づいてこれらのホストの優先順位付けを行います。インスタンスが PCI デバイスを 1 つ要求している場合には 1 番目のホスト、複数の PCI デバイスを要求している場合には 2 番目のホスト、PCI デバイスを要求していない場合には 3 番目のホストが優先されるべきです。

このオプションを設定して、PCI を要求しないインスタンスが PCI デバイスを持つホストのリソースを占有するのを防ぎます。

デフォルト: 1.0

型: 正の浮動小数点

filter_scheduler/host_subset_size

このパラメーターを使用して、ホストを選択するサブセット (絞り込まれたホストのサブセット) のサイズを指定します。1 以上に設定する必要があります。値を 1 に指定した場合には、重み付け関数によって最初に返されるホストが選択されます。1 未満の値が設定された場合には、無視されて 1 が使用されます。

類似の要求を処理する複数のスケジューラープロセスが同じホストを選択して競合状態が生じるのを防ぐには、1 より大きい値に設定します。要求に最も適した N 台のホストからホストを無作為に選択することで、競合の可能性が低減されます。ただし、この値を高く設定すると、選択されるホストが特定の要求に対して最適ではない可能性が高くなります。

デフォルト: 1

型: 整数

filter_scheduler/soft_affinity_weight_multiplier

このパラメーターを使用して、グループのソフトアフィニティーのホストを重み付けするのに使用する重みの乗数を指定します。

デフォルト: 1.0

型: 正の浮動小数点

filter_scheduler/soft_anti_affinity_weight_multiplier

このパラメーターを使用して、グループのソフト非アフィニティーのホストを重み付けするのに使用する重みの乗数を指定します。

デフォルト: 1.0

型: 正の浮動小数点

metrics/weight_multiplier

このパラメーターを使用して、メトリックの重み付けに使用する重みの乗数を指定します。デフォルトでは weight_multiplier=1.0 に設定されており、使用可能な全ホストの間でインスタンスを分散します。

重み全体でメトリックの影響を増大させるには、1.0 を超える数値に設定します。

重み全体でメトリックの影響を減少させるには、0.0 と 1.0 の間の数値に設定します。

メトリックの値を無視して「weight_of_unavailable」オプションの値を返すには、0.0 に設定します。

低いメトリックのホストを優先してインスタンスをホストにスタックするには、負の数値に設定します。

デフォルト: 1.0

型: 浮動小数点

metrics/weight_setting

このパラメーターを使用して、重み付けに使用するメトリック、および各メトリックの重みを計算するのに使用する比率を指定します。有効なメトリック名は以下のとおりです。

  • cpu.frequency: CPU の周波数
  • cpu.user.time: CPU のユーザーモード時間
  • cpu.kernel.time: CPU のカーネル時間
  • cpu.idle.time: CPU のアイドル時間
  • cpu.iowait.time: CPU の I/O 待機時間
  • cpu.user.percent: CPU のユーザーモード率
  • cpu.kernel.percent: CPU のカーネル率
  • cpu.idle.percent: CPU のアイドル率
  • cpu.iowait.percent: CPU の I/O 待機率
  • cpu.percent: 汎用 CPU の使用率

例: weight_setting=cpu.user.time=1.0

型: metric=ratio ペアのコンマ区切りリスト

metrics/required

このパラメーターを使用して、設定した metrics/weight_setting メトリックが使用できない場合の処理方法を指定します。

  • True: メトリックは必須です。メトリックが使用できない場合には、例外が発生します。この例外を回避するには、NovaSchedulerDefaultFiltersMetricsFilter フィルターを使用します。
  • False: 使用できないメトリックは、重み付け処理において負の係数として扱われます。weight_of_unavailable 設定オプションを使用して、戻り値を設定します。

型: ブール値

metrics/weight_of_unavailable

このパラメータを使用して、metrics/weight_setting メトリックが使用できず、かつ metrics/required=False の場合に用いる重みを指定します。

デフォルト: -10000.0

型: 浮動小数点

4.5.3. PCI デバイスがアタッチされている NUMA ノードの確保

Compute はフィルタースケジューラーを使用して、PCI を要求するインスタンスに対して、PCI デバイスがアタッチされたホストの優先順位付けを行います。ホストの重み付けは、PCIWeigher オプションが使用して、ホスト上で利用可能な PCI デバイスの数と、インスタンスによって要求されている PCI デバイスの数に基づいて行われます。インスタンスが PCI デバイスを要求している場合は、より多くの PCI デバイスがアタッチされたホストに、他のホストよりも高い加重値が割り当てられます。インスタンスが PCI デバイスを要求していない場合には、優先順位付けは行われません。

この機能は、以下のような場合に特に役立ちます。

  • オペレーターが、PCI デバイスを要求するゲストインスタンス向けに PCI デバイスがアタッチされたノード (通常は高コストでリソースが限定される) を確保する場合
  • インスタンスを起動するユーザーが、必要時に PCI デバイスを利用できるようにする場合。
注記

この値が考慮されるようにするには、Compute 環境ファイルの NovaSchedulerDefaultFilters パラメーターに、PciPassthroughFilter または NUMATopologyFilter どちらかの値を追加する必要があります。

pci_weight_multiplier 設定オプションは、正の値でなければなりません。

4.6. インスタンスのスナップショットの管理

インスタンスのスナップショットを使用すると、インスタンスから新規イメージを作成することができます。これは、ベースイメージのアップロードや、公開イメージを取得してローカルで使用するためにカスタマイズする際に非常に便利です。

Image サービスに直接アップロードしたイメージと、スナップショットで作成したイメージの相違点は、スナップショットで作成したイメージには Image サービスデータベースのプロパティーが追加されている点です。これらのプロパティーは image_properties テーブルにあり、以下のパラメーターが含まれます。

表4.9 スナップショットのオプション

名前

image_type

snapshot

instance_uuid

<uuid_of_instance_that_was_snapshotted>

base_image_ref

<uuid_of_original_image_of_instance_that_was_snapshotted>

image_location

snapshot

スナップショットでは、指定のスナップショットをベースにして新規インスタンスを作成して、その状態にインスタンスを復元することができます。インスタンスの実行中に、このアクションを実行できます。

デフォルトでは、スナップショットをベースとするインスタンスが起動している間は、選択したユーザーとプロジェクトがそのスナップショットにアクセスできます。

4.6.1. インスタンスのスナップショットの作成

注記

インスタンスのスナップショットをテンプレートとして使用して新規インスタンスを作成する場合には、ディスクの状態が一貫していることを確認してください。スナップショットを作成する前に、スナップショットのイメージメタデータのプロパティーを os_require_quiesce=yes に設定します。

$ openstack image set --property os_require_quiesce=yes <image_id>

このコマンドが機能するには、ゲストに qemu-guest-agent パッケージがインストール済みで、メタデータプロパティーのパラメーターを hw_qemu_guest_agent=yes に指定してイメージを作成する必要があります。

$ openstack image create \
--disk-format raw \
--container-format bare \
--file <file_name> \
--is-public True \
--property hw_qemu_guest_agent=yes \
--progress \
--name <name>

hw_qemu_guest_agent=yes パラメーターを無条件で有効化した場合には、別のデバイスをゲストに追加してください。この設定により、PCI スロットが使用され、ゲストに割り当てることのできる他のデバイスの数が制限されます。また、これにより、Windows ゲストでは、未知のハードウェアデバイスについての警告のメッセージが表示されます。

このような理由により、hw_qemu_guest_agent=yes パラメーターの設定はオプションとなっており、QEMU ゲストエージェントを必要とするそれらのイメージにのみ使用すべきです。

  1. Dashboard で プロジェクト > コンピュート > インスタンス を選択します。
  2. スナップショットを作成するインスタンスを選択します。
  3. アクション コラムで、スナップショットの作成 をクリックします。
  4. スナップショットの作成 ダイアログでは、スナップショットの名前を入力して スナップショットの作成 をクリックします。

    イメージ カテゴリーには、インスタンスのスナップショットが表示されます。

スナップショットからインスタンスを起動するには、スナップショットを選択して 起動 をクリックします。

4.6.2. スナップショットの管理

  1. Dashboard で プロジェクト > イメージ を選択します。
  2. 作成したスナップショットはすべて プロジェクト オプションの下に表示されます。
  3. 作成するスナップショットごとに、ドロップダウンリストを使用して以下の機能を実行できます。

    1. ボリュームの作成 オプションを使用して、ボリュームを作成してボリューム名の値、説明、イメージソース、ボリューム種別、サイズ、アベイラビリティーゾーンを入力します。詳しい情報は『ストレージガイド』「ボリュームの作成」を参照してください。
    2. イメージの編集 オプションを使用して、名前、説明、カーネル ID、Ramdisk ID、アーキテクチャー、形式、最小ディスク (GB)、最小メモリー (MB)、パブリックまたはプライベートを更新して、スナップショットのイメージを更新します。詳細は、「イメージの更新」を参照してください。
    3. イメージの削除 オプションを使用してスナップショットを削除します。

4.6.3. スナップショットの状態へのインスタンスの再構築

スナップショットがベースとなっているインスタンスを削除する場合には、スナップショットにはインスタンス ID が保存されます。nova image-list コマンドを使用してこの情報を確認して、スナップショットでインスタンスを復元します。

  1. Dashboard で プロジェクト > コンピュート > イメージ を選択します。
  2. インスタンスを復元するスナップショットを選択します。
  3. アクション コラムで、インスタンスの起動 をクリックします。
  4. インスタンスの起動 ダイアログで、インスタンスの名前とその他の詳細を入力して 起動 をクリックします。

インスタンスの起動に関する詳細は、「インスタンスの起動」を参照してください。

4.6.4. 一貫性のあるスナップショット

以前のリリースでは、バックアップの一貫性を確保するには、アクティブなインスタンスのスナップショットを作成する前にファイルシステムを手動で停止 (fsfreeze) する必要がありました。

Compute の libvirt ドライバーは、QEMU ゲストーエージェントにファイルシステムを (fsfreeze-hook がインストールされている場合には、アプリケーションも対象) フリーズするように自動的に要求するようになりました。ファイルシステムの停止に対するサポートにより、スケジュールされた自動スナップショット作成をブロックデバイスレベルで実行できるようになりました。

この機能は、QEMU ゲストエージェント (qemu-ga) がインストール済みで、かつイメージのメタデータで有効化されている (hw_qemu_guest_agent=yes) 場合にのみ有効です。

注記

システムのバックアップの代わりにスナップショットを使用しないでください。

4.7. インスタンスのレスキューモードの使用

Compute では、仮想マシンをレスキューモードで再起動する方法があります。レスキューモードは、仮想マシンイメージが原因で、インスタンスがアクセス不可能な状態となっている場合に、そのインスタンスにアクセスするためのメカニズムを提供します。レスキューモードの仮想マシンは、ユーザーが仮想マシンに新規 root パスワードを使用してアクセスし、そのマシンを修復することができます。この機能は、インスタンスのファイルシステムが破損した場合に役立ちます。デフォルトでは、レスキューモードのインスタンスは初期イメージから起動して、第 2 のイメージとして現在のブートディスクをアタッチします。

4.7.1. レスキューモードのインスタンス用のイメージの準備

ブートディスクとレスキューモード用のディスクには同じ UUID が使用されているため、仮想マシンがレスキューモード用のディスクの代わりにブートディスクから起動されてしまう可能性があります。

この問題を回避するには、「イメージの作成」の手順に従い、レスキューイメージとして新しいイメージを作成してください。

注記

rescue イメージは、デフォルトでは glance に保管され、nova.conf で設定されていますが、レスキューを実行する際に選択することもできます。

4.7.1.1. ext4 ファイルシステムを使用するイメージのレスキュー

ベースイメージが ext4 ファイルシステムを使用する場合は、以下の手順を使用してそれをベースにレスキューイメージを作成できます。

  1. tune2fs コマンドを使用して、UUID を無作為な値に変更します。

    # tune2fs -U random /dev/<device_node>

    <device_node> を、sdavda などのルートデバイスノードに置き換えます。

  2. 新しい UUID を含む、ファイルシステムの詳細を確認します。

    # tune2fs -l
  3. /etc/fstab ファイルで UUID を新しい値に置き換えます。fstab にマウントされている追加のパーティションがある場合には、UUID を新しい値に置き換える必要がある場合があります。
  4. /boot/grub2/grub.conf ファイルを更新し、ルートディスクの UUID パラメーターを新しい UUID に置き換えます。
  5. シャットダウンして、このイメージをレスキューイメージに使用します。これにより、レスキューイメージには新たに無作為な UUID が割り当てられ、レスキューするインスタンスとの競合が発生しなくなります。
注記

XFS ファイルシステムでは、実行中の仮想マシン上のルートデバイスの UUID は変更できません。仮想マシンがレスキューモード用のディスクから起動するまで再起動を続けます。

4.7.2. OpenStack Image サービスへのレスキューイメージの追加

対象のイメージの UUID を変更したら、以下のコマンドを実行して、生成されたレスキューイメージを OpenStack Image サービスに追加します。

  1. Image サービスにレスキューイメージを追加します。

    # openstack image create --name <image_name> --disk-format qcow2 \
      --container-format bare --is-public True --file <image_path>

    <image_name> をイメージの名前に置き換え、<image_path> をイメージの場所に置き換えます。

  2. image-list コマンドを使用して、インスタンスをレスキューモードで起動するのに必要な <image_id> を取得します。

    # openstack image list

OpenStack Dashboard を使用してイメージをアップロードすることも可能です。「イメージのアップロード」を参照してください。

4.7.3. レスキューモードでのインスタンスの起動

  1. デフォルトのイメージではなく、特定のイメージを使用してインスタンスをレスキューする必要があるため、--image パラメーターを使用します。

    # openstack server rescue --image <image> <instance>
    • <image> を使用するイメージの名前または ID に置き換えてください。
    • <instance> を、レスキューするインスタンスの名前または ID に置き換えてください。
    注記

    インスタンスのレスキューに関する詳しい情報は https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.1/html/instances_and_images_guide/assembly-managing-an-instance_instances#rescuing-an-instance_instances を参照してください。

    デフォルトでは、インスタンスのシャットダウンには 60 秒かかります。イメージメタデータの設定 os_shutdown_timeout 設定を使用して、イメージごとのタイムアウト値を上書きすることができます。これは、異なるタイプのオペレーティングシステムを正常にシャットダウンするのに必要な時間を指定します。

  2. 仮想マシンを再起動します。
  3. nova list コマンドまたは Dashboard を使用して、コントローラーノード上で仮想マシンのステータスが RESCUE であることを確認します。
  4. レスキューモード用のパスワードを使用して、新しい仮想マシンのダッシュボードにログインします。

これで、インスタンスに必要な変更を加えて、問題を修正できる状態となりました。

4.7.4. インスタンスのアンレスキュー

修正したインスタンスは unrescue して、ブートディスクから再起動することができます。

  1. コントローラーノードで以下のコマンドを実行します。

    # nova unrescue <virtual_machine_id>

    <virtual_machine_id> はアンレスキューする仮想マシンの ID に置き換えます。

レスキューからの復帰操作が正常に完了すると、インスタンスのステータスは ACTIVE に戻ります。

4.8. カスタムインスタンスの作成

クラウドユーザーは、インスタンスがブート時に実行するシェルスクリプトなど、インスタンスを起動する際に使用する追加データを指定することができます。クラウドユーザーは、以下の手段を使用してデータをインスタンスに渡すことができます。

ユーザーデータ
cloud-init が実行するインスタンスの起動コマンドに指示を追加するのに使用します。
インスタンスメタデータ
インスタンスの作成または更新時に指定することができるキー/値のペアの一覧

コンフィグドライブまたはメタデータサービスを使用して、インスタンスに渡される追加データにアクセスすることができます。

コンフィグドライブ
インスタンスのブート時に、インスタンスにコンフィグドライブをアタッチすることができます。コンフィグドライブは読み取り専用ドライブとしてインスタンスに提示されます。インスタンスはこのドライブをマウントして、そこからファイルを読み取ることができます。このコンフィグドライブを cloud-init の情報源として使用できます。コンフィグドライブは、cloud-init (サーバーのブートストラップ用) と組み合わせる場合や、インスタンスに大容量のファイルを渡す場合に有用です。たとえば、cloud-init を設定して、インスタンスの初回ブート中にコンフィグドライブを自動的にマウントして設定スクリプトを実行することができます。コンフィグドライブは config-2 のボリュームラベルで作成され、インスタンスのブート時にインスタンスにアタッチされます。コンフィグドライブに渡される追加ファイルの内容は、コンフィグドライブの openstack/{version}/ ディレクトリー内の user_data ファイルに追加されます。cloud-init はこのファイルからユーザーデータを取得します。
メタデータサービス
REST API を使用して、インスタンス固有のデータを取得します。インスタンスは、169.254.169.254 または fe80::a9fe:a9fe からこのサービスにアクセスします。

cloud-init は、コンフィグドライブとメタデータサービスの両方を使用して、インスタンスのカスタマイズ用の追加データを利用することができます。cloud-init パッケージは、さまざまなデータ入力形式をサポートします。シェルスクリプトおよび cloud-config 形式が、最も一般的な入力形式です。

  • シェルスクリプト: データ宣言は #! または Content-Type: text/x-shellscript で始まります。シェルスクリプトは、ブートプロセスの最後に呼び出されます。
  • cloud-config format: データ宣言は #cloud-config または Content-Type: text/cloud-config で始まります。cloud-config ファイルが cloud-init により解析および実行されるためには、有効な YAML でなければなりません。
注記

cloud-init では、インスタンスに渡されるユーザーデータの最大サイズは 16384 バイトです。サイズの制限を変更することはできないため、サイズの制限を超えるデータが必要な場合は、gzip 圧縮を使用します。

4.8.1. ユーザーデータを使用したインスタンスのカスタマイズ

ユーザーデータを使用して、インスタンスの起動コマンドに指示を追加することができます。cloud-init はこれらのコマンドを実行して、ブートプロセスの最後のステップとしてインスタンスをカスタマイズします。

手順

  1. cloud-init への指示が含まれるファイルを作成します。たとえば、インスタンス上に Web サーバーをインストールして有効にする bash スクリプトを作成します。

    $ vim /home/scripts/install_httpd
    #!/bin/bash
    
    yum -y install httpd python-psycopg2
    systemctl enable httpd --now
  2. --user-data オプションを使用してインスタンスを起動し、bash スクリプトを渡します。

    $ openstack server create \
    --image rhel8 \
    --flavor default \
    --nic net-id=web-server-network \
    --security-group default \
    --key-name web-server-keypair \
    --user-data /home/scripts/install_httpd \
    --wait web-server-instance
  3. インスタンスの状態がアクティブになったら、Floating IP アドレスを割り当てます。

    $ openstack floating ip create web-server-network
    $ openstack server add floating ip web-server-instance 172.25.250.123
  4. SSH でインスタンスにログインします。

    $ ssh -i ~/.ssh/web-server-keypair cloud-user@172.25.250.123
  5. カスタマイズが正常に実行されたことを確認します。たとえば、Web サーバーがインストールされ有効になっていることを確認するには、以下のコマンドを入力します。

    $ curl http://localhost | grep Test
    <title>Test Page for the Apache HTTP Server on Red Hat Enterprise Linux</title>
    <h1>Red Hat Enterprise Linux <strong>Test Page</strong></h1>
  6. /var/log/cloud-init.log が実行したかどうかなど、関連するメッセージの有無を cloud-init ファイルで確認します。

    $ sudo less /var/log/cloud-init.log
    ...output omitted...
    ...util.py[DEBUG]: Cloud-init v. 0.7.9 finished at Sat, 23 Jun 2018 02:26:02 +0000. Datasource DataSourceOpenStack [net,ver=2].  Up 21.25 seconds

4.8.2. メタデータを使用したインスタンスのカスタマイズ

インスタンスのメタデータを使用して、インスタンスの起動コマンドにインスタンスの属性を指定することができます。

手順

  1. --property <key=value> オプションでインスタンスを起動します。たとえば、インスタンスを Web サーバーとして識別するには、以下の属性を設定します。

    $ openstack server create \
    --image rhel8 \
    --flavor default \
    --property role=webservers \
    --wait web-server-instance
  2. (オプション) インスタンスの作成後に、さらにインスタンスに属性を追加します。以下に例を示します。

    $ openstack server set \
    --property region=emea \
    --wait web-server-instance

4.8.3. コンフィグドライブを使用したインスタンスのカスタマイズ

インスタンスのブートプロセス中にアタッチされる、インスタンス用のコンフィグドライブを作成することができます。コンフィグドライブに渡したコンテンツは、コンフィグドライブによりインスタンスに提供されます。

手順

  1. コンフィグドライブを有効にし、コンフィグドライブで利用可能にするコンテンツが含まれるファイルを指定します。たとえば、以下のコマンドは config-drive-instance という名前の新規インスタンスを作成し、ファイル my-user-data.txt のコンテンツが含まれるコンフィグドライブをアタッチします。

    (overcloud)$ openstack server create --flavor m1.tiny \
      --config-drive true \
      --user-data ./my-user-data.txt \
      --image cirros config-drive-instance

    このコマンドにより、ボリュームラベルが config-2 のコンフィグドライブが作成され、インスタンスのブート時にアタッチされます。また、my-user-data.txt のコンテンツが、コンフィグドライブの openstack/{version}/ ディレクトリーにある user_data ファイルに追加されます。

  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

第5章 コンピュートノード間の仮想マシンインスタンスの移行

メンテナンスを実行する場合やワークロードのリバランスを行う場合、あるいは障害が発生した/障害が発生しつつあるノードを置き換える場合に、あるコンピュートノードからオーバークラウド内の別のコンピュートノードにインスタンスを移行しなければならない場合があります。

コンピュートノードのメンテナンス
ハードウェアのメンテナンスや修理、カーネルのアップグレードおよびソフトウェアの更新を行うなどの理由により、コンピュートノードを一時的に停止する必要がある場合、コンピュートノード上で実行中のインスタンスを別のコンピュートノードに移行することができます。
障害が発生しつつあるコンピュートノード
コンピュートノードで障害が発生する可能性があり、ノードのサービスまたは置き換えが必要な場合、障害が発生しつつあるコンピュートノードから正常なコンピュートノードにインスタンスを移行することができます。
障害が発生したコンピュートノード
コンピュートノードですでに障害が発生している場合には、インスタンスを退避させることができます。同じ名前、UUID、ネットワークアドレス、およびコンピュートノードに障害が発生する前にインスタンスに割り当てられていたその他すべてのリソースを使用して、元のイメージから別のコンピュートノードにインスタンスを再ビルドすることができます。
ワークロードのリバランス
ワークロードをリバランスするために、1 つまたは複数のインスタンスを別のコンピュートノードに移行することができます。たとえば、コンピュートノード上のインスタンスを 1 つにまとめて電力を節約する、他のネットワークリソースに物理的に近いコンピュートノードにインスタンスを移行してレイテンシーを低減する、インスタンスを全コンピュートノードに分散してホットスポットをなくし復元力を向上させる、等が可能です。

director は、すべてのコンピュートノードがセキュアな移行を提供するように設定します。すべてのコンピュートノードには、移行プロセス中それぞれのホストのユーザーが他のコンピュートノードにアクセスできるように、共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、すべての Compute ロールにデフォルトで含まれているメインのサービスの 1 つです。詳細は、『オーバークラウドの高度なカスタマイズ』「コンポーザブルサービスとカスタムロール」を参照してください。

注記

バックアップの目的で正常に機能しているコンピュートノードインスタンスのコピーを作成する場合や、インスタンスを別の環境にコピーする場合は、『director のインストールと使用方法』「オーバークラウドへの仮想マシンのインポート」の手順に従います。

5.1. 移行の種別

Red Hat OpenStack Platform (RHOSP) では、以下の移行種別がサポートされています。

コールドマイグレーション

コールドマイグレーション (あるいは、非ライブマイグレーション) では、動作中のインスタンスをシャットダウンしてから、移行元コンピュートノードから移行先コンピュートノードに移行すします。

Cold Migration

コールドマイグレーションでは、インスタンスに多少のダウンタイムが発生します。移行したインスタンスは、引き続き同じボリュームおよび IP アドレスにアクセスすることができます。

注記

コールドマイグレーションを行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。

ライブマイグレーション

ライブマイグレーションでは、インスタンスをシャットダウンせずに、動作状態を維持しながら移行元コンピュートノードから移行先コンピュートノードに移行します。

Live Migration

インスタンスのライブマイグレーションを行う場合、ダウンタイムはほとんど発生しません。状況によっては、インスタンスのライブマイグレーションを行うことができない場合があります。詳細は、「移行の制約」を参照してください。

注記

ライブマイグレーションを行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。

退避

コンピュートノードですでに障害が発生しているためインスタンスを移行する必要がある場合、インスタンスを退避させることができます。

5.2. 移行の制約

状況によっては、インスタンスの移行に追加の制約が生じる場合があります。移行の制約は通常、ブロックマイグレーション、設定ディスク、またはいずれかのインスタンスがコンピュートノード上の物理ハードウェアにアクセスする場合に生じます。

CPU に関する制約

移行元および移行先コンピュートノードの CPU アーキテクチャーは、同一であることが必須です。たとえば、Red Hat では、x86_64 CPU から ppc64le CPU へのインスタンスの移行をサポートしません。CPU ホストパススルーを使用するインスタンス等の場合には、移行元および移行先コンピュートノードの CPU は、完全に同一でなければなりません。すべてのケースで、移行先ノードの CPU 機能は、移行元ノードの CPU 機能の上位セットであることが必須です。CPU ピニングが使用されている場合には、さらに制約が生じます。詳細は、「ライブマイグレーションに関する制約」を参照してください。

メモリーに関する制約

移行先コンピュートノードでは、十分な RAM が利用可能でなければなりません。メモリーのオーバーサブスクリプションが、移行失敗の原因となる可能性があります。また、NUMA トポロジーを使用するインスタンスの場合、移行先コンピュートノードの同じ NUMA ノードで十分な RAM が利用可能でなければなりません。

ブロックマイグレーションに関する制約

インスタンスの使用するディスクがコンピュートノード上にローカルに格納されている場合、その移行には、共有ストレージ (Red Hat Ceph Storage 等) を使用するボリュームベースのインスタンスよりもはるかに長い時間がかかります。このレイテンシーは、OpenStack Compute (nova) がコンピュートノード間でローカルディスクをブロックごとに移行するために発生します。この処理は、デフォルトではコントロールプレーンネットワークを通じて行われます。これとは対照的に、Red Hat Ceph Storage 等の共有ストレージを使用するボリュームベースのインスタンスでは、ボリュームを移行する必要がありません。それぞれのコンピュートノードが、共有ストレージにアクセスできるためです。

注記

大量の RAM を消費するローカルディスクまたはインスタンスの移行により、コントロールプレーンネットワークに輻輳が生じ、コントロールプレーンネットワークを使用する他のシステム (RabbitMQ 等) のパフォーマンスに悪影響を及ぼす場合があります。

読み取り専用ドライブの移行に関する制約

ドライブの移行は、ドライブに読み取りおよび書き込み両方の機能がある場合に限りサポートされます。たとえば、OpenStack Compute (nova) は CD-ROM ドライブまたは読み取り専用のコンフィグドライブを移行することはできません。ただし、OpenStack Compute (nova) は、vfat 等のドライブ形式を持つコンフィグドライブなど、読み取りおよび書き込み両方の機能を持つドライブを移行することができます。

ライブマイグレーションに関する制約

RHEL マイナーバージョン間の移行

通常、移行元コンピュートノードのインスタンスマシン種別のバージョンが移行先コンピュートノードと同じか、またはそれよりも低い場合、RHEL マイナーバージョン間でインスタンスのライブマイグレーションを行うことができます。たとえば、RHEL 7.6 コンピュートノード上で実行中の RHEL 7.6 マシン種別のインスタンスを RHEL 7.5 コンピュートノードにライブマイグレーションすることはできません。RHEL 7.5 コンピュートノードは RHEL 7.6 マシン種別を認識しないためです。

ただし、マシン種別を明示的に設定しない場合、インスタンスはデフォルトのマシン種別を受け取り、サポート対象の RHEL マイナーバージョン間のライブマイグレーションは成功します。たとえば、デフォルトマシン種別 RHEL 7.6 のインスタンスを、RHEL 7.8 コンピュートノードから RHEL 7.7 コンピュートノードにライブマイグレーションすることができます。

移行中に新しい操作を行うことができない
移行元および移行先ノードのインスタンスのコピー間で状態の整合性を確保するために、RHOSP ではライブマイグレーション中の新規操作を拒否する必要があります。拒否しないと、ライブマイグレーションでメモリーの状態を複製する前にメモリーへの書き込みが行われた場合、ライブマイグレーションに長い時間がかかる状況や、永久に完了しない状況が発生する可能性があります。
NUMA、CPU ピニング、ヒュージページ、および DPDK

OpenStack Compute では、環境が以下の条件を満たしている場合に、NUMA、CPU ピニング、または DPDK を使用するインスタンスのライブマイグレーションが可能です。

  • 移行先コンピュートノードには、インスタンスが移行元コンピュートノードで使用するのと同じ NUMA ノードに十分な容量がなければなりません。たとえば、インスタンスが overcloud-compute-0NUMA 0 を使用している場合に、インスタンスを overcloud-compute-1 にライブマイグレーションするには、overcloud-compute-1NUMA 0 にインスタンスをサポートするのに十分な空き容量を確保する必要があります。
  • Compute の設定で NovaEnableNUMALiveMigration が「True」に設定されている。このパラメーターは、コンピュートホストが OVS-DPDK デプロイメント用に設定されている場合に限り、デフォルトで有効になります。
  • Compute 設定の NovaSchedulerDefaultFilters パラメーターには、AggregateInstanceExtraSpecsFilter および NUMATopologyFilter の値が含まれている必要があります。
  • CPU ピニング: フレーバーで CPU ピニングが使用される場合、フレーバーは暗黙的に NUMA トポロジーをインスタンスに適用し、その CPU およびメモリーを特定のホスト CPU およびメモリーにマッピングします。シンプルな NUMA トポロジーと CPU ピニングの違いは、NUMA では CPU コアの範囲が指定されるのに対して、CPU ピニングでは特定の CPU コアが使用される点です。詳細は、「NUMA ノードを使用する CPU ピニングの設定」を参照してください。CPU ピニングを使用するインスタンスのライブマイグレーションを行うには、移行先ホストが空で、等価なハードウェアが使用されている必要があります。
  • Data Plane Development Kit (DPDK): インスタンスが DPDK を使用する場合 (Open vSwitch と dpdk-netdev を組み合わせて実行するインスタンスなど)、インスタンスはヒュージページも使用します。この場合、OpenStack Compute (nova) がインスタンスを NUMA ノードに固定するような NUMA トポロジーが適用されます。DPDK を使用するインスタンスを移行する場合、移行先コンピュートノードのハードウェア仕様と設定は、移行元コンピュートノードと同一でなければなりません。また、移行元コンピュートノードの NUMA トポロジーを維持するために、移行先コンピュートノードに実行中のインスタンスがあってはいけません。

ライブマイグレーションの妨げとなる制約

インスタンスに以下の機能が設定されている場合、ライブマイグレーションを行うことはできません。

  • Single-root Input/Output Virtualization (SR-IOV): インスタンスに SR-IOV Virtual Function (VF) を割り当てることができます。ただし、これによりライブマイグレーションが妨げられます。通常のネットワークデバイスとは異なり、SR-IOV VF ネットワークデバイスは、永続的な一意の MAC アドレスを持ちません。コンピュートノードがリブートするたびに、またはスケジューラーがインスタンスを新しいコンピュートノードに移行する際に、VF ネットワークデバイスには新しい MAC アドレスが割り当てられます。したがって、OpenStack Compute は SR-IOV を使用するインスタンスのライブマイグレーションを行うことができません。SR-IOV を使用するインスタンスでは、コールドマイグレーションを行う必要があります。
  • PCI パススルー: QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスをインスタンスにアタッチすることができます。PCI パススルーを使用すると、インスタンスは PCI デバイスに排他的にアクセスすることができ、これらのデバイスがインスタンスのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理アドレスが必要なため、OpenStack Compute は PCI パススルーを使用するインスタンスのライブマイグレーションをサポートしません。

5.3. 移行の準備

1 つまたは複数のインスタンスを移行する前に、コンピュートノード名および移行するインスタンスの ID を把握する必要があります。

手順

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

    (undercloud)$ source ~/overcloudrc
    (overcloud)$ openstack compute service list
  2. 移行元コンピュートノード上のインスタンスを一覧表示し、移行するインスタンスの ID を特定します。

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

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

  3. (オプション) メンテナンスのために移行元となるコンピュートノードを停止するには、メンテナンス中にスケジューラーが新しいインスタンスを割り当てないように、アンダークラウドからそのコンピュートノードを無効にします。

    (overcloud)$ source ~/stackrc
    (undercloud)$ openstack compute service set <source> nova-compute --disable

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

NUMA、CPU ピニング、または DPDK を使用するインスタンスを移行するのでなければ、これで移行を行う準備が整いました。「インスタンスのコールドマイグレーション」または「インスタンスのライブマイグレーション」に詳細を示す必要手順に従います。

NUMA、CPU ピニング、または DPDK を使用するインスタンスを移行する場合は、移行先ノードの準備を行う必要があります。「DPDK インスタンス向けの追加準備作業」に詳細を示す手順を完了してください。

5.4. DPDK インスタンス向けの追加準備作業

NUMA、CPU ピニング、または DPDK を使用するインスタンスを移行する場合は、移行先ノードの準備を行う必要があります。

手順

  1. NUMA、CPU ピニング、または DPDK インスタンスの移行先コンピュートノードが無効ではない場合には、これを無効にしてスケジューラーがそのノードにインスタンスを割り当てるのを防ぎます。

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

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

  2. 複数の DPDK または NUMA インスタンスを移行する場合、移行元コンピュートノードから先に移行していたインスタンスを除き、移行先コンピュートノードにはインスタンスが存在しないようにしてください。

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

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

  3. 移行先コンピュートノードに、NUMA、CPU ピニング、または DPDK インスタンスを実行するのに十分なリソースを確保するようにしてください。

    (overcloud)$ openstack host show <dest>
    $ ssh <dest>
    $ numactl --hardware
    $ exit

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

  4. 移行元または移行先コンピュートノードの NUMA 情報を検出するには、以下のコマンドを実行します。

    $ ssh root@overcloud-compute-n
    # lscpu && lscpu | grep NUMA
    # virsh nodeinfo
    # virsh capabilities
    # exit

    ssh を使用して overcloud-compute-n に接続します。ここで、overcloud-compute-n は移行元または移行先コンピュートノードです。

  5. インスタンスが NUMA を使用しているかどうか不明な場合は、インスタンスのフレーバーを確認してください。

    (overcloud)$ openstack server list -c Name -c Flavor --name <vm>
    (overcloud)$ openstack flavor show <flavor>
    • <vm> をインスタンスの名前または ID に置き換えてください。
    • <flavor> をフレーバーの名前または ID に置き換えてください。

      • 表示される properties フィールドの hw:mem_page_size の値が any 以外 (2MB2048、または 1GB) の場合、インスタンスは NUMA トポロジーを持ちます。
      • properties フィールドに aggregate_instance_extra_specs:pinned='true' が含まれる場合には、インスタンスは CPU ピニングを使用しています。
      • properties フィールドに hw:numa_nodes が含まれる場合、OpenStack Compute (nova) サービスはインスタンスを特定の NUMA ノードに制限します。
  6. NUMA を使用する各インスタンスについて、移行完了後に移行先コンピュートノードの NUMA トポロジーが移行元コンピュートノードの NUMA トポロジーを反映していることを確認できるように、ベースとなるコンピュートノードから NUMA トポロジーに関する情報を取得することができます。以下のコマンドを使用して、この確認を行うことができます。

    • NUMA および CPU ピニングに関する詳細を確認するには、以下のコマンドを実行します。

      $ ssh root@overcloud-compute-n
      # virsh vcpuinfo <vm>

      <vm> をインスタンスの名前に置き換えてください。

    • インスタンスがどの NUMA ノードを使用しているかの詳細を確認するには、以下のコマンドを実行します。

      $ ssh root@overcloud-compute-n
      # virsh numatune <vm>

      <vm> をインスタンスの名前に置き換えてください。

5.5. インスタンスのコールドマイグレーション

インスタンスのコールドマイグレーションでは、インスタンスを停止して別のコンピュートノードに移動します。コールドマイグレーションは、PCI パススルーまたは Single-Root Input/Output Virtualization (SR-IOV) を使用するインスタンスの移行など、ライブマイグレーションでは対応することのできない移行シナリオに対応します。移行先コンピュートノードは、スケジューラーにより自動的に選択されます。詳細は、「移行の制約」を参照してください。

注記

コールドマイグレーション中、Compute サービスは移行するインスタンスをゼロから再ビルドし、マシン種別を移行先コンピュートノードのマシン種別に合わせます。したがって、RHEL 7.5 コンピュートノード上で実行中の RHEL 7.5 マシン種別のインスタンスを RHEL 7.6 コンピュートノードにコールドマイグレーションする場合、移行先コンピュートノードに移行したインスタンスのマシン種別は RHEL 7.6 に設定されます。

手順

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

    (overcloud)$ openstack server migrate <vm> --wait
    • <vm> を移行するインスタンスの名前または ID に置き換えてください。
    • ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。
  2. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  3. インスタンスのステータスを確認します。

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

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

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

      (overcloud)$ openstack server resize --confirm <vm>`

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

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

      (overcloud)$ openstack server resize --revert <vm>`

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

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

    (overcloud)$ openstack server start <vm>

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

インスタンスの移行が終了したら、「移行の完了」に進みます。

5.6. インスタンスのライブマイグレーション

ライブマイグレーションでは、ダウンタイムを最小限に抑えて、インスタンスを移行元コンピュートノードから移行先コンピュートノードに移動します。ライブマイグレーションがすべてのインスタンスに適しているとは限りません。詳細は、「移行の制約」を参照してください。

注記

ライブマイグレーションでは、移行先コンピュートノードでインスタンスのマシン種別が保持されます。したがって、RHEL 7.5 コンピュートノード上で実行中の RHEL 7.5 マシン種別のインスタンスを RHEL 7.6 コンピュートノードにライブマイグレーションする場合、移行先コンピュートノードに移行したインスタンスは RHEL 7.5 のマシン種別を維持します。マシンの種別を変更するには、イメージのメタデータ属性 hw_machine_type を設定するか、各コンピュートノードで NovaHWMachineType パラメーターを設定する必要があります。

手順

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

    (overcloud)$ openstack server migrate <vm> --live <dest> --wait
    • <vm> をインスタンスの名前または ID に置き換えてください。
    • <dest> を移行先コンピュートノードの名前または ID に置き換えてください。

      注記

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

      (overcloud)$ openstack server migrate <vm> --live <dest> --wait --block-migration
  2. インスタンスが移行されていることを確認します。

    $ openstack server show <vm>
    
    +----------------------+--------------------------------------+
    | Field                | Value                                |
    +----------------------+--------------------------------------+
    | ...                  | ...                                  |
    | status               | MIGRATING                            |
    | ...                  | ...                                  |
    +----------------------+--------------------------------------+
  3. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  4. インスタンスのステータスをチェックして、移行が成功したかどうかを確認します。

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

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

  5. (オプション) NUMA、CPU ピニング、または DPDK を使用するインスタンスについて、コンピュートノードから NUMA トポロジーに関する情報を取得して、移行の準備手順の実施中に取得した NUMA トポロジーと比較します。移行元と移行先コンピュートノードの NUMA トポロジーを比較して、移行元と移行先コンピュートノードが同じ NUMA トポロジーを使用するようにします。

    • NUMA および CPU ピニングに関する詳細を確認するには、以下のコマンドを実行します。

      $ ssh root@overcloud-compute-n
      # virsh vcpuinfo <vm>
      • overcloud-compute- をコンピュートノードのホスト名に置き換えてください。
      • <vm> をインスタンスの名前に置き換えてください。
    • インスタンスがどの NUMA ノードを使用しているかの詳細を確認するには、以下のコマンドを実行します。

      $ ssh root@overcloud-compute-n
      # virsh numatune <vm>
      • overcloud-compute- をコンピュートノードのホスト名に置き換えてください。
      • <vm> をインスタンスの名前または ID に置き換えてください。

インスタンスの移行が終了したら、「移行の完了」に進みます。

5.7. 移行ステータスの確認

移行が完了するまでに、さまざまな移行状態を遷移します。正常な移行では、通常、移行状態は以下のように遷移します。

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

手順

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

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

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

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

    $ nova server-migration-show <vm> <migration-id>
    • <vm> をインスタンスの名前または ID に置き換えてください。
    • <migration-id> を移行の ID に置き換えてください。

      nova 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           |
      +------------------------+--------------------------------------+
      ヒント

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

インスタンスの移行に長い時間がかったり、エラーが発生したりする場合があります。詳細は、「移行に関するトラブルシューティング」を参照してください。

5.8. 移行の完了

1 つまたは複数のインスタンスを移行したら、スケジューラーが新しいインスタンスを移行元コンピュートノードに割り当てられるように、アンダークラウドから移行元コンピュートノードを再度有効にする必要があります。DPDK を使用する移行済みインスタンスについては、アンダークラウドから移行先コンピュートノードも再度有効にする必要があります。

手順

  1. 移行元コンピュートノードを再度有効にします。

    (overcloud)$ source ~/stackrc
    (undercloud)$ openstack compute service set <source> nova-compute --enable

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

  2. (オプション) DPDK を使用するインスタンスについては、アンダークラウドから移行先コンピュートノードを再度有効にします。

    (undercloud)$ openstack compute service set <dest> nova-compute --enable

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

5.9. インスタンスの退避

インスタンスを障害の発生したコンピュートノードまたはシャットダウンしたコンピュートノードから同じ環境内の新しいホストに移動する場合、インスタンスを退避させることができます。退避プロセスにより、インスタンスが別のコンピュートノードに再ビルドされます。インスタンスが共有ストレージを使用する場合、インスタンスのルートディスクは退避プロセス中に再ビルドされません。移行先コンピュートノードが引き続きこのディスクにアクセス可能なためです。インスタンスが共有ストレージを使用しない場合は、インスタンスのルートディスクも移行先コンピュートノードに再ビルドされます。

注記
  • コンピュートノードがフェンシングされ、API が報告するコンピュートノードの状態が「down」または「forced-down」である場合に限り、退避を行うことができます。コンピュートノードが「down」または「forced-down」と報告されない場合、evacuate コマンドは失敗します。
  • クラウド管理者でなければ、退避を行うことはできません。
  • 退避中、Compute サービスは退避するインスタンスをゼロから再ビルドし、マシン種別を移行先コンピュートノードのマシン種別に合わせます。したがって、RHEL 7.5 コンピュートノード上で実行中の RHEL 7.5 マシン種別のインスタンスを RHEL 7.6 コンピュートノードに退避する場合、移行先コンピュートノードに移行したインスタンスのマシン種別は RHEL 7.6 に設定されます。

5.9.1. 単一のインスタンスの退避

インスタンスを一度に 1 つずつ退避させることができます。

手順

  1. 障害の発生したコンピュートノードに管理者としてログインします。
  2. コンピュートノードを無効にします。

    (overcloud)[stack@director ~]$ openstack compute service set \
    <host> <service> --disable
    • <host> をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。
    • <service> を無効にするサービスの名前 (例: nova-compute) に置き換えてください。
  3. インスタンスを退避させるには、以下のコマンドを実行します。

    (overcloud)[stack@director ~]$ nova evacuate [--password <pass>] <vm> [dest]
    • <pass> を退避するインスタンスに設定する admin パスワードに置き換えてください。パスワードを指定しなかった場合には、無作為に生成され、退避の完了時に出力されます。
    • <vm> を退避させるインスタンスの名前または ID に置き換えてください。
    • [dest] をインスタンスの退避先となるコンピュートノードの名前に置き換えてください。退避先コンピュートノードを指定しなかった場合には、Compute スケジューラーがノードを選択します。退避先に指定可能なコンピュートノードを確認するには、以下のコマンドを使用します。

      (overcloud)[stack@director ~]$ openstack hypervisor list

5.9.2. ホスト上の全インスタンスの退避

指定したコンピュートノード上の全インスタンスを退避させることができます。

手順

  1. 障害の発生したコンピュートノードに管理者としてログインします。
  2. コンピュートノードを無効にします。

    (overcloud)[stack@director ~]$ openstack compute service set \
    <host> <service> --disable
    • <host> をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。
    • <service> を無効にするサービスの名前 (例: nova-compute) に置き換えてください。
  3. 指定したコンピュートノード上の全インスタンスを退避させます。

    (overcloud)[stack@director ~]$ nova host-evacuate [--target_host <dest>] [--force] <host>
    • <dest> をインスタンスの退避先となるコンピュートノードの名前に置き換えてください。退避先を指定しなかった場合には、Compute のスケジューラーがノードを選択します。退避先に指定可能なコンピュートノードを確認するには、以下のコマンドを使用します。

      (overcloud)[stack@director ~]$ openstack hypervisor list
    • <host> をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。

5.9.3. 共有ストレージの設定

共有ストレージを使用する場合には、Compute サービスのインスタンスディレクトリーを 2 つのノードにエクスポートし、ノードにアクセスできることを確認します。ディレクトリーのパスは、Compute 環境ファイルの state_path および instances_path パラメーターで設定されます。この手順では、デフォルト値の /var/lib/nova/instances を使用しています。共有ストレージを設定することができるのは、root アクセスのあるユーザーのみです。以下の手順の Compute サービスユーザーは、すべてのコントローラーノードおよびコンピュートノードについて同じでなければなりません。

手順

  1. コントローラーノードで以下の手順を実施します。

    1. 以下の例に示すように、Compute サービスのユーザーに /var/lib/nova/instances ディレクトリーの読み取り/書き込み権限があることを確認します。

      drwxr-xr-x.  9 nova nova 4096 Nov  5 20:37 instances
    2. /etc/exports ファイルに以下の行を追加します。

      /var/lib/nova/instances node1_IP(rw,sync,fsid=0,no_root_squash)
      /var/lib/nova/instances node2_IP(rw,sync,fsid=0,no_root_squash)

      node1_IP および node2_IP を 2 つのコンピュートノードの IP アドレスに置き換えてください。以下に例を示します。

      /var/lib/nova/instances 192.168.24.9(rw,sync,fsid=0,no_root_squash)
      /var/lib/nova/instances 192.168.24.21(rw,sync,fsid=0,no_root_squash)
    3. /var/lib/nova/instances ディレクトリーをコンピュートノードにエクスポートします。

      # exportfs -avr
    4. NFS サーバーを再起動します。

      # systemctl restart nfs-server
  2. 各コンピュートノードで以下の手順を実施します。

    1. /var/lib/nova/instances ディレクトリーがローカルに存在することを確認します。
    2. /etc/fstab ファイルに以下の行を追加します。

      NFS_SHARE_PATH:/var/lib/nova/instances /var/lib/nova/instances nfs4 defaults 0 0
    3. コントローラーのインスタンスディレクトリーをマウントし、/etc/fstab に記載されているすべてのデバイスをマウントします。

      # mount -a -v
    4. QEMU がディレクトリーのイメージにアクセスできることを確認します。

      # ls -ld /var/lib/nova/instances
      drwxr-xr-x. 9 nova nova 4096 Nov  5 20:37 /var/lib/nova/instances
    5. ノードでインスタンスディレクトリーを表示できることを確認します。

      drwxr-xr-x. 9 nova nova 4096 Nov  5 20:37 /var/lib/nova/instances
注記

以下のコマンドを実行して、全マウント済みデバイスを確認することもできます。

# df -k

5.10. 移行に関するトラブルシューティング

インスタンスの移行時に、以下の問題が発生する可能性があります。

  • 移行プロセスでエラーが生じる。
  • 移行プロセスが終了しない。
  • 移行後にインスタンスのパフォーマンスが低下する。

5.10.1. 移行中のエラー

以下の問題が発生すると、移行操作が error 状態に遷移します。

  • 実行しているクラスターに異なるバージョンの Red Hat OpenStack Platform (RHOSP) が存在する。
  • 指定したインスタンス ID が見つからない。
  • 移行を試みているインスタンスが error 状態にある。
  • Compute サービスが停止している。
  • 競合状態が発生している。
  • ライブマイグレーションが failed 状態に移行する。

ライブマイグレーションが failed 状態に移行すると、通常は error 状態になります。failed 状態の原因となる可能性のある典型的な問題を、以下に示します。

  • 移行先コンピュートホストが利用可能な状態にない。
  • スケジューラーの例外が発生する。
  • コンピューティングリソースが不十分なため、再ビルドプロセスに失敗する。
  • サーバーグループの確認に失敗する。
  • 移行先コンピュートノードへの移行が完了する前に、移行元コンピュートノードのインスタンスが削除される。

5.10.2. ライブマイグレーションのスタック

ライブマイグレーションが完了せず、永久に running 状態のままになる可能性があります。ライブマイグレーションが永久に完了しない一般的な理由は、Compute サービスがインスタンスの変更を移行先コンピュートノードに複製するより早く、クライアントのリクエストにより移行元コンピュートノード上で実行中のインスタンスに変更が生じることです。

この状況に対処するには、以下のいずれかの方法を使用します。

  • ライブマイグレーションを中止する。
  • ライブマイグレーションを強制的に完了させる。

ライブマイグレーションの中止

移行プロセスがインスタンスの状態の変化を移行先ノードにコピーするより早くインスタンスの状態が変化する状況で、インスタンスの動作を一時的に中断したくない場合には、ライブマイグレーションを中止することができます。

手順

  1. インスタンスの移行の一覧を取得します。

    $ nova server-migration-list <vm>

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

  2. ライブマイグレーションを中止します。

    $ nova live-migration-abort <vm> <migration-id>
    • <vm> をインスタンスの名前または ID に置き換えてください。
    • <migration-id> を移行の ID に置き換えてください。

ライブマイグレーション完了の強制

移行プロセスがインスタンスの状態の変化を移行先ノードにコピーするより早くインスタンスの状態が変化する状況で、インスタンスの動作を一時的に中断して移行を強制的に完了させたい場合には、ライブマイグレーションの手順を強制的に完了させることができます。

重要

ライブマイグレーションを強制的に完了させると、かなりのダウンタイムが発生する可能性があります。

手順

  1. インスタンスの移行の一覧を取得します。

    $ nova server-migration-list <vm>

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

  2. ライブマイグレーションを強制的に完了させます。

    $ nova live-migration-force-complete <vm> <migration-id>
    • <vm> をインスタンスの名前または ID に置き換えてください。
    • <migration-id> を移行の ID に置き換えてください。

5.10.3. 移行後のインスタンスパフォーマンスの低下

NUMA トポロジーを使用するインスタンスの場合、移行元および移行先コンピュートノードの NUMA トポロジーおよび設定は同一でなければなりません。移行先コンピュートノードの NUMA トポロジーでは、十分なリソースが利用可能でなければなりません。移行元および移行先コンピュートノード間で NUMA 設定が同一でない場合、ライブマイグレーションは成功するがインスタンスのパフォーマンスが低下する可能性があります。たとえば、移行元コンピュートノードは NIC 1 を NUMA ノード 0 にマッピングするが、移行先コンピュートノードは NIC 1 を NUMA ノード 5 にマッピングする場合、移行後にインスタンスはバス内の最初の CPU からのネットワークトラフィックを NUMA ノード 5 の別の CPU にルーティングし、トラフィックを NIC 1 にルーティングする可能性があります。その結果、予想されたとおりに動作はしますが、パフォーマンスが低下します。同様に、移行元コンピュートノードの NUMA ノード 0 では十分な CPU および RAM が利用可能だが、移行先コンピュートノードの NUMA ノード 0 にリソースの一部を使用するインスタンスがすでに存在する場合、インスタンスは正しく動作するがパフォーマンスが低下する可能性があります。詳細は、「移行の制約」を参照してください。

第6章 PCI パススルーの設定

PCI パススルーを使用して、グラフィックカードまたはネットワークデバイス等の物理 PCI デバイスをインスタンスにアタッチすることができます。デバイスに PCI パススルーを使用する場合、インスタンスはタスクを実行するためにデバイスへの排他的アクセスを確保し、ホストはデバイスを利用することができません。

重要

ルーティング対応プロバイダーネットワークでの PCI パススルーの使用

Compute サービスは、複数のプロバイダーネットワークにまたがる単一のネットワークをサポートしません。ネットワークに複数の物理ネットワークが含まれる場合、Compute サービスは最初の物理ネットワークだけを使用します。したがって、ルーティング対応プロバイダーネットワークを使用する場合は、すべてのコンピュートノードで同じ physical_network 名を使用する必要があります。

VLAN またはフラットネットワークのルーティング対応プロバイダーネットワークを使用する場合は、すべてのセグメントで同じ physical_network 名を使用する必要があります。その後、ネットワークに複数のセグメントを作成し、そのセグメントを適切なサブネットにマッピングします。

クラウドユーザーが PCI デバイスがアタッチされたインスタンスを作成できるようにするには、以下の手順を実施する必要があります。

  1. PCI パススルー用のコンピュートノードを指定する。
  2. 必要な PCI デバイスを持つ PCI パススルー用のコンピュートノードを設定する。
  3. オーバークラウドをデプロイする。
  4. PCI デバイスがアタッチされたインスタンスを起動するためのフレーバーを作成する。

前提条件

  • 必要な PCI デバイスを持つコンピュートノード

6.1. PCI パススルー用コンピュートノードの指定

物理 PCI デバイスがアタッチされたインスタンス用のコンピュートノードを指定するには、以下の操作を行う必要があります。

  • PCI パススルーロールを設定するための新規ロールファイルを作成する。
  • PCI パススルー用コンピュートノードをタグ付けするための、PCI パススルー用の新規オーバークラウドフレーバーを設定する。

手順

  1. roles_data_pci_passthrough.yaml という名前で、ControllerCompute、および ComputePCI ロールが含まれる新しいロールデータファイルを生成します。

    (undercloud)$ openstack overcloud roles \
     generate -o /home/stack/templates/roles_data_pci_passthrough.yaml \
     Compute:ComputePCI Compute Controller
  2. roles_data_pci_passthrough.yaml を開き、以下のパラメーターおよびセクションを編集または追加します。

    セクション/パラメーター現在の値新しい値

    ロールのコメント

    Role: Compute

    Role: ComputePCI

    ロール名

    Compute

    name: ComputePCI

    説明

    Basic Compute Node role

    PCI パススルー用コンピュートノードロール

    HostnameFormatDefault

    %stackname%-novacompute-%index%

    %stackname%-novacomputepci-%index%

    deprecated_nic_config_name

    compute.yaml

    compute-pci-passthrough.yaml

  3. オーバークラウドの PCI パススルー用コンピュートノードをノード定義のテンプレート node.json または node.yaml に追加して、そのノードを登録します。詳しい情報は、『director のインストールと使用方法』「オーバークラウドノードの登録」を参照してください。
  4. ノードのハードウェアを検査します。

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

    詳細は、『director のインストールと使用方法』「ノードのハードウェアの検査」を参照してください。

  5. PCI パススルー用に指定するノードをタグ付けするための compute-pci-passthrough ベアメタルフレーバーを作成します。

    (undercloud)$ openstack flavor create --id auto \
     --ram <ram_size_mb> --disk <disk_size_gb> \
     --vcpus <no_vcpus> compute-pci-passthrough
    • <ram_size_mb> をベアメタルノードの RAM (MB 単位) に置き換えます。
    • <disk_size_gb> をベアメタルノード上のディスク容量 (GB 単位) に置き換えます。
    • <no_vcpus> をベアメタルノードの CPU 数に置き換えます。

      注記

      これらの属性は、インスタンスのスケジューリングには使用されません。ただし Compute スケジューラーは、ディスク容量を使用してルートパーティションのサイズを決定します。

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

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

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

  7. compute-pci-passthrough フレーバーをカスタムの PCI パススルーリソースクラスに関連付けます。

    (undercloud)$ openstack flavor set \
     --property resources:CUSTOM_BAREMETAL_PCI_PASSTHROUGH=1 \
      compute-pci-passthrough

    Bare Metal サービスノードのリソースクラスに対応するカスタムリソースクラスの名前を指定するには、リソースクラスを大文字に変換し、すべての句読点をアンダースコアに置き換え、CUSTOM_ のプレフィックスを追加します。

    注記

    フレーバーが要求できるのは、ベアメタルリソースクラスの 1 つのインスタンスだけです。

  8. 以下のフレーバー属性を設定して、Compute スケジューラーがインスタンスのスケジューリングにベアメタルフレーバー属性を使用するのを防ぎます。

    (undercloud)$ openstack flavor set \
     --property resources:VCPU=0 --property resources:MEMORY_MB=0 \
     --property resources:DISK_GB=0 compute-pci-passthrough
  9. 以下のパラメーターを node-info.yaml ファイルに追加して、PCI パススルー用コンピュートノードの数および PCI パススルー対応コンピュートノードに使用するフレーバーを指定します。

    parameter_defaults:
      OvercloudComputePCIFlavor: compute-pci-passthrough
      ComputePCICount: 3
  10. ロールが作成されたことを確認するには、以下のコマンドを入力します。

    (undercloud)$ openstack overcloud profiles list

6.2. PCI パススルー用コンピュートノードの設定

クラウドユーザーが PCI デバイスがアタッチされたインスタンスを作成できるようにするには、PCI デバイスを持つコンピュートノードとコントローラーノードの両方を設定する必要があります。

手順

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

    parameter_defaults:
      NovaSchedulerDefaultFilters: ['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 の設定方法の詳細は、「Guidelines for configuring 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.yamlnova::pci::aliasesnuma_affinity を追加した場合は、pci_passthrough_compute.yamlnova::pci::aliases にも追加する必要があります。

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

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

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

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

    (undercloud)$ openstack overcloud deploy --templates \
      -e [your environment files] \
      -e /home/stack/templates/pci_passthrough_controller.yaml \
      -e /home/stack/templates/pci_passthrough_compute.yaml \
  10. クラウドユーザーが PCI デバイスを要求するのに使用できるフレーバーを作成および設定します。以下の例では、ステップ 7 で定義したエイリアスを使用して、それぞれベンダー ID および製品 ID が 8086 および 1572 の 2 つのデバイスを要求します。

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

検証

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

    # openstack server create --flavor device_passthrough \
     --image <image> --wait test-pci
  2. クラウドユーザーとしてインスタンスにログインします。詳細は、「インスタンスへのログイン」を参照してください。
  3. インスタンスが PCI デバイスにアクセスできることを確認するには、インスタンスから以下のコマンドを入力します。

    $ lspci -nn | grep <device_name>

6.3. PCI パススルーデバイス種別フィールド

Compute サービスでは、デバイスが報告する機能に応じて、PCI デバイスは 3 つの種別のいずれかに分類されます。device_type フィールドに設定することのできる有効な値を、以下の一覧に示します。

type-PF
デバイスは、SR-IOV をサポートする親またはルートデバイスです。SR-IOV を完全にサポートするデバイスをパススルーするには、このデバイス種別を指定します。
type-VF
デバイスは、SR-IOV をサポートするデバイスの子デバイスです。
type-PCI
デバイスは SR-IOV をサポートしません。device_type フィールドが設定されていない場合は、これがデフォルトのデバイス種別です。
注記

コンピュートノードとコントローラーノードの device_type を、同じ値に設定する必要があります。

6.4. NovaPCIPassthrough 設定のガイドライン

  • NIC のデバイス名は変更される可能性があるため、PCI パススルーを設定する場合は devname パラメーターを使用しないでください。代わりに、vendor_idproduct_id の方が安定しているため使用するか、NIC の address を使用してください。
  • product_id パラメーターを使用して Physical Function (PF) のパススルーを設定するには、PF の address も指定する必要があります。ただし、アドレスはそれぞれのホストで一意なので、address パラメーターだけを使用して PF を指定することができます。
  • すべての Virtual Function (VF) のパススルーを設定する場合は、product_id および vendor_id を指定するだけで十分です。NIC の分割に SRIOV を使用し、VF 上で OVS を実行している場合は、address も指定する必要があります。
  • PF の VF のパススルーだけを設定し、PF そのもののパススルーは設定しない場合は、address パラメーターを使用して PF の PCI アドレスを指定し、product_id を使用して VF の 製品 ID を指定することができます。

第7章 データベースのクリーニング

Compute サービスには管理ツール nova-manage が含まれています。このツールを使用して、データベーススキーマの適用、アップグレード中のオンラインデータ移行の実行、データベースの管理およびクリーンアップ等の、デプロイメント、アップグレード、クリーンアップ、およびメンテナンス関連のタスクを実行することができます。

director は、cron を使用してオーバークラウドでの以下のデータベース管理タスクを自動化します。

  • 削除された行を実稼働テーブルからシャドウテーブルに移動して、削除されたインスタンスレコードをアーカイブする。
  • アーカイブ処理が完了した後に、シャドウテーブルから削除された行をパージする。

7.1. データベース管理の設定

cron ジョブは、デフォルト設定を使用してデータベース管理タスクを実行します。デフォルトでは、データベースをアーカイブする cron ジョブは毎日 00:01 に実行され、データベースをパージする cron ジョブは 毎日 05:00 に実行されます。共にジッターは 0 秒から 3600 秒の間です。必要に応じて、これらの設定は heat パラメーターを使用して変更することができます。

手順

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

    parameter_defaults:
      …
      NovaCronArchiveDeleteRowsPurge: True

    データベースの cron ジョブを管理する heat パラメーターの完全一覧は、「OpenStack Compute (nova) のデータベース自動管理用設定オプション」を参照してください。

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

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

7.2. OpenStack Compute (nova) のデータベース自動管理用設定オプション

以下の heat パラメーターを使用して、データベースを管理する自動 cron ジョブを有効化および変更します。

表7.1 OpenStack Compute (nova) の cron パラメーター

パラメーター詳細

NovaCronArchiveDeleteAllCells

すべてのセルから削除されたインスタンスレコードをアーカイブするには、このパラメーターを「True」に設定します。

デフォルト値: True

NovaCronArchiveDeleteRowsAge

このパラメーターを使用して、削除されたインスタンスレコードを経過時間 (日数単位) に基づいてアーカイブします。

シャドウテーブル内の本日以前のデータをアーカイブするには、0 に設定します。

デフォルト値: 90

NovaCronArchiveDeleteRowsDestination

このパラメーターを使用して、削除されたインスタンスレコードを記録するファイルを設定します。

デフォルト値は /var/log/nova/nova-rowsflush.log です。

NovaCronArchiveDeleteRowsHour

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動する cron コマンドを実行する時刻の時間部分を設定します。

デフォルト値: 0

NovaCronArchiveDeleteRowsMaxDelay

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動するまでの最大遅延時間 (秒単位) を設定します。

デフォルト値: 3600

NovaCronArchiveDeleteRowsMaxRows

このパラメーターを使用して、別のテーブルに移動することのできる削除インスタンスレコード数の最大値を設定します。

デフォルト値: 1000

NovaCronArchiveDeleteRowsMinute

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動する cron コマンドを実行する時刻の分部分を設定します。

デフォルト値: 1

NovaCronArchiveDeleteRowsMonthday

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動する cron コマンドを実行する日にちを設定します。

デフォルト値: * (毎日)

NovaCronArchiveDeleteRowsMonth

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動する cron コマンドを実行する月を設定します。

デフォルト値: * (毎月)

NovaCronArchiveDeleteRowsPurge

スケジュールされたアーカイブ処理の直後にシャドウテーブルをパージするには、このパラメーターを「True」に設定します。

デフォルト値は False です。

NovaCronArchiveDeleteRowsUntilComplete

すべてのレコードを移動するまで削除されたインスタンスレコードを別のテーブルに移動し続けるには、このパラメーターを「True」に設定します。

デフォルト値: True

NovaCronArchiveDeleteRowsUser

このパラメーターを使用して、削除されたインスタンスレコードをアーカイブする crontab の所有権を持ち、crontab が使用するログファイルにアクセスできるユーザーを設定します。

デフォルト値は nova です。

NovaCronArchiveDeleteRowsWeekday

このパラメーターを使用して、削除されたインスタンスレコードを別のテーブルに移動する cron コマンドを実行する曜日を設定します。

デフォルト値: * (毎日)

NovaCronPurgeShadowTablesAge

このパラメーターを使用して、シャドウテーブルを経過時間 (日数単位) に基づいてパージします。

本日以前のシャドウテーブルをパージするには、0 に設定します。

デフォルト値: 14

NovaCronPurgeShadowTablesAllCells

すべてのセルからシャドウテーブルをパージするには、このパラメーターを「True」に設定します。

デフォルト値: True

NovaCronPurgeShadowTablesDestination

このパラメーターを使用して、パージされたシャドウテーブルを記録するファイルを設定します。

デフォルト値は /var/log/nova/nova-rowspurge.log です。

NovaCronPurgeShadowTablesHour

このパラメーターを使用して、シャドウテーブルをパージする cron コマンドを実行する時刻の時間部分を設定します。

デフォルト値: 5

NovaCronPurgeShadowTablesMaxDelay

このパラメーターを使用して、シャドウテーブルをパージするまでの最大遅延時間 (秒単位) を設定します。

デフォルト値: 3600

NovaCronPurgeShadowTablesMinute

このパラメーターを使用して、シャドウテーブルをパージする cron コマンドを実行する時刻の分部分を設定します。

デフォルト値: 0

NovaCronPurgeShadowTablesMonth

このパラメーターを使用して、シャドウテーブルをパージする cron コマンドを実行する月を設定します。

デフォルト値: * (毎月)

NovaCronPurgeShadowTablesMonthday

このパラメーターを使用して、シャドウテーブルをパージする cron コマンドを実行する日にちを設定します。

デフォルト値: * (毎日)

NovaCronPurgeShadowTablesUser

このパラメーターを使用して、シャドウテーブルをパージする crontab の所有権を持ち、crontab が使用するログファイルにアクセスできるユーザーを設定します。

デフォルト値は nova です。

NovaCronPurgeShadowTablesVerbose

このパラメーターを使用して、パージされたシャドウテーブルに関するログファイルの詳細ロギングを有効にします。

デフォルト値は False です。

NovaCronPurgeShadowTablesWeekday

このパラメーターを使用して、シャドウテーブルをパージする cron コマンドを実行する曜日を設定します。

デフォルト値: * (毎日)

第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>

8.2. コンピュートノードでのヒュージページの設定

インスタンスがヒュージページを要求できるようにコンピュートノードを設定します。

手順

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

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

    各属性についての説明は以下のとおりです。

    属性

    説明

    size

    割り当てるヒュージページのサイズ。有効な値は 2048 (2 MB 用) および 1 GB です。

    count

    NUMA ノードごとに OVS が使用するヒュージページの数。たとえば、Open vSwitch が 4096 のソケットメモリーを使用する場合、この属性を 2 に設定します。

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

    parameter_defaults:
       ComputeExtraConfig:
         nova::compute::libvirt::libvirt_cpu_mode: 'custom'
         nova::compute::libvirt::libvirt_cpu_model: 'Haswell-noTSX'
         nova::compute::libvirt::libvirt_cpu_model_extra_flags: 'vmx, pdpe1gb'
    注記
    • インスタンスが 2 MB のヒュージページしか要求しない場合、CPU 機能フラグを設定する必要はありません。
    • ホストが 1 GB ヒュージページの割り当てをサポートする場合に限り、インスタンスに 1 GB のヒュージページを割り当てることができます。
    • cpu_modehost-model または custom に設定されている場合に限り、cpu_model_extra_flagspdpe1gb に設定する必要があります。
    • ホストが pdpe1gb をサポートし、cpu_modehost-passthrough が使用される場合、cpu_model_extra_flagspdpe1gb を設定する必要はありません。pdpe1gb フラグは Opteron_G4 および Opteron_G5 CPU モデルにのみ含まれ、QEMU がサポートする Intel CPU モデルには含まれません。
    • Microarchitectural Data Sampling (MDS) 等の CPU ハードウェアの問題を軽減するには、他の CPU フラグを設定しなければならない場合があります。詳しくは、「RHOS Mitigation for MDS ("Microarchitectural Data Sampling") Security Flaws」を参照してください。
  3. Meltdown に対する保護の適用後にパフォーマンスが失われないようにするには、CPU 機能フラグ cpu_model_extra_flags を設定して「+pcid」を指定します。

    parameter_defaults:
       ComputeExtraConfig:
         nova::compute::libvirt::libvirt_cpu_mode: 'custom'
         nova::compute::libvirt::libvirt_cpu_model: 'Haswell-noTSX'
         nova::compute::libvirt::libvirt_cpu_model_extra_flags: 'vmx, pdpe1gb, +pcid'
  4. 各 Compute 環境ファイルの NovaSchedulerDefaultFilters パラメーターにまだ NUMATopologyFilter がなければ、このフィルターを追加します。
  5. デプロイコマンドに環境ファイルを追加してオーバークラウドをデプロイし、このヒュージページの設定を適用します。

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

8.2.1. インスタンスへのヒュージページの割り当て

インスタンスがヒュージページを使用することを指定するには、hw:mem_page_size 追加仕様キーを使用してフレーバーを作成します。

前提条件

手順

  1. ヒュージページを要求するインスタンス用のフレーバーを作成します。

    $ openstack flavor create --ram <size-mb> --disk <size-gb> --vcpus <no_reserved_vcpus> huge_pages
  2. ヒュージページのフレーバーを設定します。

    $ openstack flavor set huge_pages --property hw:mem_page_size=1GB

    有効な hw:mem_page_size の値は以下のとおりです。

    • large: ホストでサポートされる最大のページサイズを選択します。x86_64 システムでは 2 MB または 1 GB です。
    • small: (デフォルト) ホストでサポートされる最小のページサイズを選択します。X86_64 システムでは、4 kB (通常のページ) です。
    • any: libvirt ドライバーで決定される、利用可能な最大のヒュージページサイズを選択します。
    • <pagesize>: (文字列) ワークロードに具体的な要件がある場合、ページサイズを明示的に設定します。整数値のページサイズを、kB またはその他の標準単位で指定します。たとえば、4kB、2MB、2048、1GB と設定します。
  3. 新しいフレーバーを使用してインスタンスを作成します。

    $ openstack server create --flavor huge_pages --image <image> huge_pages_instance

検証

スケジューラーは、インスタンスのメモリーをサポートするのに十分なサイズの空きヒュージページを持つホストを特定します。スケジューラーが十分なページを持つホストおよび NUMA ノードを検出できない場合、リクエストは失敗して NoValidHost エラーが報告されます。

第9章 インスタンスへのメタデータの追加

Compute (nova) サービスは、メタデータを使用してインスタンスの起動時に設定情報を渡します。インスタンスは、コンフィグドライブまたはメタデータサービスを使用してメタデータにアクセスすることができます。

コンフィグドライブ
コンフィグドライブは、インスタンスのブート時にアタッチすることのできる特別なドライブです。コンフィグドライブは読み取り専用ドライブとしてインスタンスに提示されます。インスタンスはこのドライブをマウントしてそこからファイルを読み取り、通常メタデータサービスから利用する情報を取得することができます。
メタデータサービス
Compute サービスは、REST API としてメタデータサービスを提供します。これを使用して、インスタンス固有のデータを取得することができます。インスタンスは、169.254.169.254 または fe80::a9fe:a9fe からこのサービスにアクセスします。

9.1. インスタンスメタデータの種別

クラウドユーザー、クラウド管理者、および Compute サービスは、メタデータをインスタンスに渡すことができます。

クラウドユーザーが提供するデータ
クラウドユーザーは、インスタンスがブート時に実行するシェルスクリプトなど、インスタンスを起動する際に使用する追加データを指定することができます。クラウドユーザーは、インスタンスを作成または更新する際に、ユーザーデータ機能を使用し、キー/値のペアを必要な属性として渡すことで、データをインスタンスに渡すことができます。
クラウド管理者が提供するデータ

RHOSP 管理者は、ベンダーデータ機能を使用してデータをインスタンスに渡します。Compute サービスの提供するベンダーデータモジュール StaticJSON および DynamicJSON により、管理者はメタデータをインスタンスに渡すことができます。

  • StaticJSON:(デフォルト)全インスタンスで共通のメタデータに使用します。
  • DynamicJSON: 各インスタンスで異なるメタデータに使用します。このモジュールは外部の REST サービスにリクエストを行い、インスタンスに追加するメタデータを決定します。

ベンダーデータの設定は、インスタンスの以下の読み取り専用ファイルのいずれかにあります。

  • /openstack/{version}/vendor_data.json
  • /openstack/{version}/vendor_data2.json
Compute サービスが提供するデータ
Compute サービスはメタデータサービスの内部実装を使用して、要求されたインスタンスのホスト名やインスタンスが属するアベイラビリティーゾーン等の情報をインスタンスに渡します。この操作はデフォルトで実施され、クラウドユーザーまたは管理者が設定を行う必要はありません。

9.2. 全インスタンスへのコンフィグドライブの追加

管理者は Compute サービスを設定し、常にインスタンス用のコンフィグドライブを作成し、コンフィグドライブにデプロイメント固有のメタデータを設定することができます。たとえば、以下の理由によりコンフィグドライブを使用する場合があります。

  • デプロイメントにおいて、インスタンスへの IP アドレスの割り当てに DHCP を使用しない場合に、ネットワーク設定を渡すため。インスタンスのネットワーク設定を行う前に、コンフィグドライブを通じてインスタンスの IP アドレス設定を渡すことができます。インスタンスは、コンフィグドライブをマウントして設定にアクセスすることができます。
  • Active Directory ポストブートにインスタンスを登録するのに使用される暗号化トークン等、インスタンスを起動するユーザーがアクセスできないデータをインスタンスに渡すため。
  • ローカルにキャッシュされたディスク読み取りを作成し、インスタンスのリクエストの負荷を管理するため。これにより、ファクトのチェックインおよびビルドのために定期的にメタデータサーバーにアクセスするインスタンスの影響が軽減されます。

ISO 9660 または VFAT ファイルシステムをマウントできるインスタンスのオペレーティングシステムは、すべてコンフィグドライブを使用することができます。

手順

  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}/ で、メタデータのファイルを検査します。

9.3. インスタンスへの静的メタデータの追加

デプロイメント内のすべてのインスタンスで、静的メタデータを利用可能にすることができます。

手順

  1. メタデータの JSON ファイルを作成します。
  2. Compute 環境ファイルを開きます。
  3. 環境ファイルに JSON ファイルへのパスを追加します。

    parameter_defaults:
      ComputeExtraConfig:
        nova::config::nova_config:
          ...
          api/vendordata_jsonfile_path:
            value: <path_to_the_JSON_file>
  4. 更新内容を Compute 環境ファイルに保存します。
  5. その他の環境ファイルと共に Compute 環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

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

9.4. インスタンスへの動的メタデータの追加

デプロイメントを設定してインスタンス固有のメタデータを作成し、そのインスタンスが JSON ファイルを使用してメタデータを利用できるようにすることができます。

ヒント

アンダークラウド上で動的メタデータを使用して、director を Red Hat Identity Management (IdM) サーバーと統合することができます。IdM サーバーは認証局として使用することができ、オーバークラウドで SSL/TLS が有効な場合にオーバークラウドの証明書を管理することができます。詳細は、「IdM へのアンダークラウドの追加」を参照してください。

手順

  1. Compute 環境ファイルを開きます。
  2. ベンダーデータプロバイダーモジュールに DynamicJSON を追加します。

    parameter_defaults:
      ComputeExtraConfig:
        nova::config::nova_config:
          ...
          api/vendordata_providers:
            value: StaticJSON,DynamicJSON
  3. メタデータを生成するためにアクセスする REST サービスを指定します。必要な数だけ目的の REST サービスを指定することができます。以下に例を示します。

    parameter_defaults:
      ComputeExtraConfig:
        nova::config::nova_config:
          ...
          api/vendordata_providers:
            value: StaticJSON,DynamicJSON
          api/vendordata_dynamic_targets:
            value: target1@http://127.0.0.1:125
          api/vendordata_dynamic_targets:
            value: 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 \

第10章 Real-time Compute の設定

一部のユースケースでは、低レイテンシーのポリシーを順守しリアルタイム処理を実行するために、コンピュートノードにインスタンスが必要となります。Real-time コンピュートノードには、リアルタイム対応のカーネル、特定の仮想化モジュール、および最適化されたデプロイメントパラメーターが設定され、リアルタイム処理の要求に対応してレイテンシーを最小限に抑えます。

リアルタイムコンピュートを有効にするプロセスは、以下のステップで構成されます。

  • コンピュートノードの BIOS 設定の定義
  • real-time カーネルおよび Real-Time KVM (RT-KVM) カーネルモジュールを持つ real-time のイメージのビルド
  • コンピュートノードへの ComputeRealTime ロールの割り当て

NFV 負荷に対して Real-time Compute をデプロイするユースケースの例については、『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』「例: ODL および VXLAN トンネリングを使用する OVS-DPDK の設定」セクションを参照してください。

10.1. Real-time 用コンピュートノードの準備

注記

Real-time コンピュートノードは、Red Hat Enterprise Linux バージョン 7.5 以降でのみサポートされます。

オーバークラウドに Real-time Compute をデプロイするには、Red Hat Enterprise Linux Real-Time KVM (RT-KVM) を有効にし、real-time をサポートするように BIOS を設定し、real-time のイメージをビルドする必要があります。

前提条件

  • RT-KVM コンピュートノードには、Red Hat 認定済みサーバーを使用する必要があります。詳しくは、Red Hat Enterprise Linux for Real Time 7 用認定サーバー を参照してください。
  • real-time のイメージをビルドするには、RT-KVM 用の rhel-7-server-nfv-rpms リポジトリーを有効にする必要があります。

    注記

    このリポジトリーにアクセスするためには、Red Hat OpenStack Platform for Real Time に対する別のサブスクリプションが必要です。リポジトリーの管理およびアンダークラウド用のサブスクリプションに関する詳細は、『director のインストールと使用方法』「アンダークラウドの登録と更新」セクションを参照してください。

    リポジトリーからインストールされるパッケージを確認するには、以下のコマンドを実行します。

    $ yum repo-pkgs rhel-7-server-nfv-rpms list
    Loaded plugins: product-id, search-disabled-repos, subscription-manager
    Available Packages
    kernel-rt.x86_64                                                                     3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-debug.x86_64                                                               3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-debug-devel.x86_64                                                         3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-debug-kvm.x86_64                                                           3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-devel.x86_64                                                               3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-doc.noarch                                                                 3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    kernel-rt-kvm.x86_64                                                                 3.10.0-693.21.1.rt56.639.el7                                                       rhel-7-server-nfv-rpms
    [ output omitted…]

real-time のイメージのビルド

Real-time コンピュートノード用のオーバークラウドイメージをビルドするには、以下のステップを実行します。

  1. アンダークラウドに libguestfs-tools パッケージをインストールして、virt-customize ツールを取得します。

    (undercloud) [stack@undercloud-0 ~]$ sudo yum install libguestfs-tools
    重要

    アンダークラウドに libguestfs-tools パッケージをインストールする場合は、アンダークラウドの tripleo_iscsid サービスとのポートの競合を避けるために iscsid.socket を無効にします。

    $ sudo systemctl disable --now iscsid.socket
  2. イメージを抽出します。

    (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/overcloud-full.tar
    (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/ironic-python-agent.tar
  3. デフォルトのイメージをコピーします。

    (undercloud) [stack@undercloud-0 ~]$ cp overcloud-full.qcow2 overcloud-realtime-compute.qcow2
  4. イメージを登録して、必要なサブスクリプションを設定します。

    (undercloud) [stack@undercloud-0 ~]$  virt-customize -a overcloud-realtime-compute.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]'
    [  0.0] Examining the guest ...
    [ 10.0] Setting a random seed
    [ 10.0] Running: subscription-manager register --username=[username] --password=[password]
    [ 24.0] Finishing off

    username および password の値を、ご自分の Red Hat カスタマーアカウント情報に置き換えてください。Real-time オーバークラウドイメージのビルドに関する一般的な情報は、ナレッジベースの記事「Modifying the Red Hat Enterprise Linux OpenStack Platform Overcloud Image with virt-customize」を参照してください。

  5. 以下の例に示すように、Red Hat OpenStack Platform for Real Time サブスクリプションの SKU を探します。SKU は、同じアカウントおよび認証情報を使用してすでに Red Hat サブスクリプションマネージャーに登録済みのシステムに置かれている場合があります。以下に例を示します。

    $ sudo subscription-manager list
  6. Red Hat OpenStack Platform for Real Time サブスクリプションをイメージにアタッチします。

    (undercloud) [stack@undercloud-0 ~]$  virt-customize -a overcloud-realtime-compute.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]'
  7. イメージ上で rt を設定するためのスクリプトを作成します。

    (undercloud) [stack@undercloud-0 ~]$ cat rt.sh
      #!/bin/bash
    
      set -eux
    
      subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-openstack-13-rpms --enable=rhel-7-server-nfv-rpms
      yum -v -y --setopt=protected_packages= erase kernel.$(uname -m)
      yum -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host
    
      # END OF SCRIPT
  8. real-time のイメージを設定するスクリプトを実行します。

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 -v --run rt.sh 2>&1 | tee virt-customize.log
  9. SELinux の再ラベル付けをします。

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 --selinux-relabel
  10. vmlinuz および initrd を抽出します。

    (undercloud) [stack@undercloud-0 ~]$ mkdir image
    (undercloud) [stack@undercloud-0 ~]$ guestmount -a overcloud-realtime-compute.qcow2 -i --ro image
    (undercloud) [stack@undercloud-0 ~]$ cp image/boot/vmlinuz-3.10.0-862.rt56.804.el7.x86_64 ./overcloud-realtime-compute.vmlinuz
    (undercloud) [stack@undercloud-0 ~]$ cp image/boot/initramfs-3.10.0-862.rt56.804.el7.x86_64.img ./overcloud-realtime-compute.initrd
    (undercloud) [stack@undercloud-0 ~]$ guestunmount image
    注記

    vmlinuz および initramfs のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。

  11. イメージをアップロードします。

    (undercloud) [stack@undercloud-0 ~]$ openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2

これで、選択したコンピュートノード上の ComputeRealTime コンポーザブルロールで使用することのできる real-time イメージの準備ができました。

Real-time コンピュートノード上での BIOS 設定の変更

Real-time コンピュートノードのレイテンシーを短縮するには、コンピュートノードの BIOS 設定を変更する必要があります。コンピュートノードの BIOS 設定で、以下のコンポーネントの全オプションを無効にする必要があります。

  • 電源管理
  • ハイパースレッディング
  • CPU のスリープ状態
  • 論理プロセッサー

これらの設定に関する説明と、無効化の影響については、「BIOS パラメーターの設定」を参照してください。BIOS 設定の変更方法に関する詳しい情報は、ハードウェアの製造会社のドキュメントを参照してください。

10.2. Real-time Compute ロールのデプロイメント

Red Hat OpenStack Platform director では、ComputeRealTime ロールのテンプレートが利用可能です。これを使用して、Real-time コンピュートノードをデプロイすることができます。ただし、コンピュートノードを real-time 用に指定するためには、追加のステップを実施する必要があります。

  1. /usr/share/openstack-tripleo-heat-templates/environments/compute-real-time-example.yaml ファイルをベースに、ComputeRealTime ロールのパラメーターを設定する compute-real-time.yaml 環境ファイルを作成します。

    cp /usr/share/openstack-tripleo-heat-templates/environments/compute-real-time-example.yaml /home/stack/templates/compute-real-time.yaml

    ファイルには、以下のパラメーター値を含める必要があります。

    • IsolCpusList および NovaVcpuPinSet: リアルタイム負荷のために確保する分離 CPU コアおよび仮想 CPU のピニングの一覧。この値は、Real-time コンピュートノードの CPU ハードウェアにより異なります。
    • KernelArgs: Real-time コンピュートノードのカーネルに渡す引数。たとえば、default_hugepagesz=1G hugepagesz=1G hugepages=<number_of_1G_pages_to_reserve> hugepagesz=2M hugepages=<number_of_2M_pages> を使用して、複数のサイズのヒュージページを持つゲストのメモリー要求を定義することができます。この例では、デフォルトのサイズは 1 GB ですが、2 MB のヒュージページを確保することもできます。
  2. ComputeRealTime ロールをロールデータのファイルに追加し、ファイルを再生成します。以下は例になります。

    $ openstack overcloud roles generate -o /home/stack/templates/rt_roles_data.yaml Controller Compute ComputeRealTime

    このコマンドにより、以下の例のような内容で ComputeRealTime ロールが生成され、ImageDefault オプションに overcloud-realtime-compute が設定されます。

    ###############################################################
    # Role: ComputeRealTime                                                               #
    ###############################################################
    
    - name: ComputeRealTime
      description: |
        Compute role that is optimized for real-time behaviour. When using this role
        it is mandatory that an overcloud-realtime-compute image is available and
        the role specific parameters IsolCpusList and NovaVcpuPinSet are set
        accordingly to the hardware of the real-time compute nodes.
      CountDefault: 1
      networks:
        - InternalApi
        - Tenant
        - Storage
      HostnameFormatDefault: '%stackname%-computerealtime-%index%'
      disable_upgrade_deployment: True
      ImageDefault: overcloud-realtime-compute
      RoleParametersDefault:
        TunedProfileName: "realtime-virtual-host"
        KernelArgs: ""      # these must be set in an environment file or similar
        IsolCpusList: ""    # according to the hardware of real-time nodes
        NovaVcpuPinSet: ""  #
      ServicesDefault:
        - OS::TripleO::Services::Aide
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        - OS::TripleO::Services::CephExternal
        - OS::TripleO::Services::CertmongerUser
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::ComputeCeilometerAgent
        - OS::TripleO::Services::ComputeNeutronCorePlugin
        - OS::TripleO::Services::ComputeNeutronL3Agent
        - OS::TripleO::Services::ComputeNeutronMetadataAgent
        - OS::TripleO::Services::ComputeNeutronOvsAgent
        - OS::TripleO::Services::Docker
        - OS::TripleO::Services::Fluentd
        - OS::TripleO::Services::Ipsec
        - OS::TripleO::Services::Iscsid
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::LoginDefs
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::NeutronBgpVpnBagpipe
        - OS::TripleO::Services::NeutronLinuxbridgeAgent
        - OS::TripleO::Services::NeutronVppAgent
        - OS::TripleO::Services::NovaCompute
        - OS::TripleO::Services::NovaLibvirt
        - OS::TripleO::Services::NovaMigrationTarget
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::ContainersLogrotateCrond
        - OS::TripleO::Services::OpenDaylightOvs
        - OS::TripleO::Services::Rhsm
        - OS::TripleO::Services::RsyslogSidecar
        - OS::TripleO::Services::Securetty
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::SkydiveAgent
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::Vpp
        - OS::TripleO::Services::OVNController
        - OS::TripleO::Services::OVNMetadataAgent
        - OS::TripleO::Services::Ptp

    カスタムロールおよび roles-data.yaml に関する一般的な情報は、「ロール」セクションを参照してください。

  3. リアルタイム負荷用に指定するノードをタグ付けするために、compute-realtime フレーバーを作成します。以下は例になります。

    $ source ~/stackrc
    $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute-realtime
    $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute-realtime" compute-realtime
  4. リアルタイム負荷用に指定するそれぞれのノードを、compute-realtime プロファイルでタグ付けします。

    $ openstack baremetal node set --property capabilities='profile:compute-realtime,boot_option:local' <NODE UUID>
  5. 以下の内容の環境ファイルを作成して、ComputeRealTime ロールを compute-realtime フレーバーにマッピングします。

    parameter_defaults:
      OvercloudComputeRealTimeFlavor: compute-realtime
  6. -e オプションを使用して openstack overcloud deploy コマンドを実行し、新しいロールファイルと共に作成したすべての環境ファイルを指定します。以下は例になります。

    $ openstack overcloud deploy -r /home/stack/templates/rt~/my_roles_data.yaml  -e /home/stack/templates/compute-real-time.yaml <FLAVOR_ENV_FILE>
    注記

    同じコンピュートノードで追加の real-time インスタンスを実行する場合は、nova.conf ファイルの realtime_schedule_priority パラメーターでインスタンスの優先度を変更することができます。

10.3. デプロイメントの例およびテストシナリオ

以下の手順の例では、単純な単一ノードのデプロイメントを使用して、環境変数およびその他の補助設定が正しく定義されていることをテストします。実際の実行結果は、クラウドにデプロイするノードおよびゲストの数により異なります。

  1. 以下のパラメーターで compute-real-time.yaml ファイルを作成します。

    parameter_defaults:
      ComputeRealTimeParameters:
        IsolCpusList: "1"
        NovaVcpuPinSet: "1"
        KernelArgs: "default_hugepagesz=1G hugepagesz=1G hugepages=16"
  2. ComputeRealTime ロールを設定して新たな rt_roles_data.yaml ファイルを作成します。

    $ openstack overcloud roles generate -o ~/rt_roles_data.yaml Controller ComputeRealTime
  3. その他の環境ファイルと共に、新たなリアルタイムロールデータファイルおよびリアルタイム環境ファイルの両方をスタックに追加して、オーバークラウドをデプロイします。

    (undercloud) $ openstack overcloud deploy --templates \
      -r /home/stack/rt_roles_data.yaml
      -e [your environment files]
      -e /home/stack/templates/compute-real-time.yaml

    このコマンドにより、コントローラーノードおよび Real-time コンピュートノードが 1 台ずつデプロイされます。

  4. Real-time コンピュートノードにログインし、以下のパラメーターを確認します。<...> は、compute-real-time.yaml からの該当するパラメーターの値に置き換えてください。

    [root@overcloud-computerealtime-0 ~]# uname -a
    Linux overcloud-computerealtime-0 3.10.0-693.11.1.rt56.632.el7.x86_64 #1 SMP PREEMPT RT Wed Dec 13 13:37:53 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    [root@overcloud-computerealtime-0 ~]# cat /proc/cmdline
    BOOT_IMAGE=/boot/vmlinuz-3.10.0-693.11.1.rt56.632.el7.x86_64 root=UUID=45ae42d0-58e7-44fe-b5b1-993fe97b760f ro console=tty0 crashkernel=auto console=ttyS0,115200 default_hugepagesz=1G hugepagesz=1G hugepages=16
    [root@overcloud-computerealtime-0 ~]# tuned-adm active
    Current active profile: realtime-virtual-host
    [root@overcloud-computerealtime-0 ~]# grep ^isolated_cores /etc/tuned/realtime-virtual-host-variables.conf
    isolated_cores=<IsolCpusList>
    [root@overcloud-computerealtime-0 ~]# cat /usr/lib/tuned/realtime-virtual-host/lapic_timer_adv_ns
    X (X != 0)
    [root@overcloud-computerealtime-0 ~]# cat /sys/module/kvm/parameters/lapic_timer_advance_ns
    X (X != 0)
    [root@overcloud-computerealtime-0 ~]# cat /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages
    X (X != 0)
    [root@overcloud-computerealtime-0 ~]# grep ^vcpu_pin_set /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf
    vcpu_pin_set=<NovaVcpuPinSet>

10.4. Real-time インスタンスの起動およびチューニング

Real-time コンピュートノードをデプロイして設定したら、それらのノードで real-time インスタンスを起動することができます。CPU ピニング、NUMA トポロジー、およびヒュージページを使用して、これらの real-time インスタンスをさらに設定することができます。

インスタンスのリアルタイムポリシーの設定

リアルタイムポリシーは real-time インスタンスを優先し、負荷のピーク時のレイテンシーを最小限に抑えます。このポリシーを設定するには、compute-realtime フレーバーに以下のパラメーターを追加します。

$ openstack flavor set compute-realtime \
  --property hw:cpu_realtime=yes
  --property hw:cpu_realtime_mask=^0

real-time インスタンスの起動

  1. 「Real-time Compute ロールのデプロイメント」セクションで説明したように、オーバークラウド上に compute-realtime フレーバーが存在する状態にしてください。
  2. real-time インスタンスを起動します。

    # openstack server create  --image <rhel> --flavor r1.small --nic net-id=<dpdk-net> test-rt
  3. コンピュートホストへの管理者アクセス権限を持つ場合、オプションとして、割り当てられたエミュレータースレッドをインスタンスが使用していることを確認することができます。

    # virsh dumpxml <instance-id> | grep vcpu -A1
    <vcpu placement='static'>4</vcpu>
    <cputune>
      <vcpupin vcpu='0' cpuset='1'/>
      <vcpupin vcpu='1' cpuset='3'/>
      <vcpupin vcpu='2' cpuset='5'/>
      <vcpupin vcpu='3' cpuset='7'/>
      <emulatorpin cpuset='0-1'/>
      <vcpusched vcpus='2-3' scheduler='fifo'
      priority='1'/>
    </cputune>

CPU のピニングおよびエミュレータースレッドポリシーの設定

リアルタイム負荷用に各リアルタイムコンピュートノードの CPU を十分に確保するためには、インスタンス用仮想 CPU (vCPU) の少なくとも 1 つをホストの物理 CPU (pCPU) にピニングする必要があります。その結果、その仮想 CPU のエミュレータースレッドは、ピニングした物理 CPU 専用として維持されます。

  1. emulator_thread_policy パラメーターを isolate に設定します。以下は例になります。
# openstack flavor set --property hw:emulator_threads_policy=isolate
  1. 専用 CPU のポリシーを使用するようにフレーバーを設定します。そのためには、フレーバーで hw:cpu_policy パラメーターを dedicated に設定します。以下は例になります。
# openstack flavor set --property hw:cpu_policy=dedicated 99
注記

リソースクオータに、Real-time コンピュートノードが消費するのに十分な pCPU があることを確認してください。

CPU ピニングに関する一般的な情報は、「NUMA ノードを使用する CPU ピニングの設定」セクションを参照してください。

ネットワーク設定の最適化

デプロイメントのニーズによっては、特定のリアルタイム負荷に合わせてネットワークをチューニングするために、network-environment.yaml ファイルのパラメーターを設定しなければならない場合があります。

OVS-DPDK 用に最適化した設定の例を確認するには、『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』「RT-KVM 対応の OVS-DPDK の設定」セクションを参照してください。

ヒュージページの設定

デフォルトのヒュージページサイズを 1 GB に設定することを推奨します。このように設定しないと、TLB のフラッシュにより仮想 CPU の実行にジッターが生じます。

compute-realtime フレーバーのヒュージページサイズを設定するには、以下のコマンドを実行します。

openstack flavor set compute-realtime --property hw:mem_page_size=large

ヒュージページの使用に関する一般的な情報については、『DPDK Getting Started Guide for Linux』の「Running DPDK applications」を参照してください。

第11章 インスタンス用の仮想 GPU の設定

インスタンスで GPU ベースのレンダリングをサポートするには、利用可能な物理 GPU デバイスおよびハイパーバイザーの種別に応じて、仮想 GPU (vGPU) リソースを定義し、管理できます。この設定を使用して、レンダリングの負荷をすべての物理 GPU デバイス間でより効果的に分割し、仮想 GPU 対応のインスタンスをスケジューリングする際の制御性を向上させることができます。

OpenStack Compute で仮想 GPU を有効にするには、クラウドユーザーが仮想 GPU デバイスの設定された Red Hat Enterprise Linux (RHEL) インスタンスを作成するのに使用できるフレーバーを作成します。これにより、各インスタンスは物理 GPU デバイスに対応する仮想 GPU デバイスで GPU 負荷に対応することができます。

OpenStack Compute サービスは、各ホストに定義する GPU プロファイルで利用可能な仮想 GPU デバイスの数を追跡します。Compute サービスはフレーバーに基づいてこれらのホストにインスタンスをスケジュールし、デバイスをアタッチし、使用状況を継続的に監視します。インスタンスが削除されると、Compute サービスは仮想 GPU デバイスを利用可能なプールに戻します。

11.1. サポートされる構成および制限

サポートされる GPU カード

サポートされる NVIDIA GPU カードの一覧については、NVIDIA の Web サイトで「Virtual GPU Software Supported Products」を参照してください。

仮想 GPU デバイスを使用する際の制限

  • 各コンピュートノードで有効にできる仮想 GPU の種別は 1 つだけです。
  • 各インスタンスが使用できる仮想 GPU のリソースは 1 つだけです。
  • ホスト間での仮想 GPU のライブマイグレーションはサポートされていません。
  • libvirt の制限により、仮想 GPU 対応インスタンスでの休止操作はサポートされていません。代わりに、インスタンスのスナップショット作成またはシェルブ処理が可能です。
  • 仮想 GPU フレーバーが設定されたインスタンスでサイズ変更およびコールドマイグレーション操作を行っても、仮想 GPU のリソースはインスタンスに自動的には再割り当てされません。インスタンスのサイズ変更または移行後に、インスタンスを手動で再ビルドし、仮想 GPU のリソースを再割り当てする必要があります。
  • デフォルトでは、コンピュートホストの仮想 GPU の種別は API ユーザーに公開されません。アクセス権限を付与するには、ホストをホストアグリゲートに追加します。詳細は、「ホストアグリゲートの管理」を参照してください。
  • NVIDIA アクセラレーターハードウェアを使用する場合は、NVIDIA ライセンス要件に従う必要があります。たとえば、NVIDIA vGPU GRID にはライセンスサーバーが必要です。NVIDIA のライセンス要件の詳細は、NVIDIA の Web サイトで「Virtual GPU License Server Release Notes」を参照してください。

11.2. コンピュートノードでの仮想 GPU の設定

クラウドユーザーが仮想 GPU (vGPU) を使用するインスタンスを作成できるようにするには、物理 GPU を持つコンピュートノードを設定する必要があります。

  1. GPU 対応のカスタムオーバークラウドイメージをビルドする。
  2. 仮想 GPU 用のコンピュートノードを指定するために、GPU ロール、プロファイル、およびフレーバーを準備する。
  3. 仮想 GPU 用のコンピュートノードを設定する。
  4. オーバークラウドをデプロイする。
注記

NVIDIA GRID vGPU を使用するには、NVIDIA GRID ライセンス要件に従う共に、セルフホストライセンスサーバーの URL が必要です。詳細は、「Virtual GPU License Server Release Notes」の Web ページを参照してください。

11.2.1. GPU 対応カスタムオーバークラウドイメージのビルド

オーバークラウドの Compute イメージに NVIDIA GRID ホストドライバーをインストールし、イメージを OpenStack Image サービス (glance) にアップロードするには、director ノードで以下の手順を実施します。

手順

  1. オーバークラウドイメージをコピーし、コピーしたイメージに gpu の接尾辞を追加します。

    $ cp overcloud-full.qcow2 overcloud-full-gpu.qcow2
  2. YUM から ISO イメージ生成器ツールをインストールします。

    $ sudo yum install genisoimage -y
  3. NVIDIA の Web サイトから、GPU デバイスに対応する NVIDIA GRID ホストドライバー RPM パッケージをダウンロードします。必要なドライバーを確認するには、NVIDIA ドライバーダウンロードポータル を参照してください。

    注記

    ポータルからドライバーをダウンロードするには、NVIDIA カスタマーとして登録されている必要があります。

  4. ドライバー RPM パッケージから ISO イメージを作成し、イメージを nvidia-host ディレクトリーに保存します。

    $ genisoimage -o nvidia-host.iso -R -J -V NVIDIA nvidia-host/
    I: -input-charset not specified, using utf-8 (detected in locale settings)
      9.06% done, estimate finish Wed Oct 31 11:24:46 2018
     18.08% done, estimate finish Wed Oct 31 11:24:46 2018
     27.14% done, estimate finish Wed Oct 31 11:24:46 2018
     36.17% done, estimate finish Wed Oct 31 11:24:46 2018
     45.22% done, estimate finish Wed Oct 31 11:24:46 2018
     54.25% done, estimate finish Wed Oct 31 11:24:46 2018
     63.31% done, estimate finish Wed Oct 31 11:24:46 2018
     72.34% done, estimate finish Wed Oct 31 11:24:46 2018
     81.39% done, estimate finish Wed Oct 31 11:24:46 2018
     90.42% done, estimate finish Wed Oct 31 11:24:46 2018
     99.48% done, estimate finish Wed Oct 31 11:24:46 2018
    Total translation table size: 0
    Total rockridge attributes bytes: 358
    Total directory bytes: 0
    Path table size(bytes): 10
    Max brk space used 0
    55297 extents written (108 MB)
  5. nouveau ドライバーも無効にし新しい initramfs を生成するドライバーインストールスクリプトを作成します。以下のサンプルスクリプト install_nvidia.sh では、nouveau ドライバーを無効にし、新しい initramfs を生成し、オーバークラウドイメージに NVIDIA GRID ホストドライバーをインストールします。

    #/bin/bash
    
    cat <<EOF >/etc/modprobe.d/disable-nouveau.conf
    blacklist nouveau
    options nouveau modeset=0
    EOF
    echo 'omit_drivers+=" nouveau "' > /etc/dracut.conf.d/disable-nouveau.conf
    dracut -f
    
    # NVIDIA GRID package
    mkdir /tmp/mount
    mount LABEL=NVIDIA /tmp/mount
    rpm -ivh /tmp/mount/<host_driver>.rpm
    • <host_driver> をステップ 3 でダウンロードしたホストドライバーに置き換えます。
  6. ステップ 4 で生成した ISO イメージをアタッチし、ステップ 5 で作成したドライバーインストール用のスクリプトを実行して、オーバークラウドイメージをカスタマイズします。

    $ virt-customize --attach nvidia-packages.iso -a overcloud-full-gpu.qcow2  -v --run install_nvidia.sh
    [   0.0] Examining the guest ...
    libguestfs: launch: program=virt-customize
    libguestfs: launch: version=1.36.10rhel=8,release=6.el8_5.2,libvirt
    libguestfs: launch: backend registered: unix
    libguestfs: launch: backend registered: uml
    libguestfs: launch: backend registered: libvirt
  7. SELinux でカスタマイズしたイメージのラベルを付け直します。

    $ virt-customize -a overcloud-full-gpu.qcow2 --selinux-relabel
    [   0.0] Examining the guest ...
    [   2.2] Setting a random seed
    [   2.2] SELinux relabelling
    [  27.4] Finishing off
  8. OpenStack Image サービスにアップロードするカスタムイメージファイルを準備します。

    $ mkdir /var/image/x86_64/image
    $ guestmount -a overcloud-full-gpu.qcow2 -i --ro image
    $ cp image/boot/vmlinuz-3.10.0-862.14.4.el8.x86_64 ./overcloud-full-gpu.vmlinuz
    $ cp image/boot/initramfs-3.10.0-862.14.4.el8.x86_64.img ./overcloud-full-gpu.initrd
  9. アンダークラウドから、OpenStack Image サービスにカスタムイメージをアップロードします。

    (undercloud) $ openstack overcloud image upload --update-existing --os-image-name overcloud-full-gpu.qcow2

11.2.2. 仮想 GPU 向けコンピュートノードの指定

仮想 GPU 負荷用のコンピュートノードを指定するには、仮想 GPU ロールを設定するための新規ロールファイルを作成し、GPU 対応のコンピュートノードをタグ付けするための新規フレーバーを設定する必要があります。

手順

  1. 新規 ComputeGpu ロールファイルを作成するには、/usr/share/openstack-tripleo-heat-templates/roles/Compute.yaml ファイルを /usr/share/openstack-tripleo-heat-templates/roles/ComputeGpu.yaml にコピーし、以下のファイルセクションを編集します。

    表11.1 ComputeGpu ロールファイルの編集

    セクション/パラメーター現在の値新しい値

    ロールのコメント

    Role: Compute

    Role: ComputeGpu

    name (ロール名)

    Compute

    ComputeGpu

    description

    Basic Compute Node role

    GPU Compute Node role

    ImageDefault

    該当なし

    overcloud-full-gpu

    HostnameFormatDefault

    -compute-

    -computegpu-

    deprecated_nic_config_name

    compute.yaml

    compute-gpu.yaml

    ComputeGpu ロールの詳細の例を以下に示します。

    #####################################################################
    # Role: ComputeGpu                                                  #
    #####################################################################
    - name: ComputeGpu
      description: |
        GPU Compute Node role
      CountDefault: 1
      ImageDefault: overcloud-full-gpu
      networks:
        - InternalApi
        - Tenant
        - Storage
      HostnameFormatDefault: '%stackname%-computegpu-%index%'
      RoleParametersDefault:
        TunedProfileName: "virtual-host"
      # Deprecated & backward-compatible values (FIXME: Make parameters consistent)
      # Set uses_deprecated_params to True if any deprecated params are used.
      uses_deprecated_params: True
      deprecated_param_image: 'NovaImage'
      deprecated_param_extraconfig: 'NovaComputeExtraConfig'
      deprecated_param_metadata: 'NovaComputeServerMetadata'
      deprecated_param_scheduler_hints: 'NovaComputeSchedulerHints'
      deprecated_param_ips: 'NovaComputeIPs'
      deprecated_server_resource_name: 'NovaCompute'
      deprecated_nic_config_name: 'compute-gpu.yaml'
      ServicesDefault:
        - OS::TripleO::Services::Aide
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        - OS::TripleO::Services::CephExternal
        - OS::TripleO::Services::CertmongerUser
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::ComputeCeilometerAgent
        - OS::TripleO::Services::ComputeNeutronCorePlugin
        - OS::TripleO::Services::ComputeNeutronL3Agent
        - OS::TripleO::Services::ComputeNeutronMetadataAgent
        - OS::TripleO::Services::ComputeNeutronOvsAgent
        - OS::TripleO::Services::Docker
        - OS::TripleO::Services::Fluentd
        - OS::TripleO::Services::Ipsec
        - OS::TripleO::Services::Iscsid
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::LoginDefs
        - OS::TripleO::Services::MetricsQdr
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::NeutronBgpVpnBagpipe
        - OS::TripleO::Services::NeutronLinuxbridgeAgent
        - OS::TripleO::Services::NeutronVppAgent
        - OS::TripleO::Services::NovaCompute
        - OS::TripleO::Services::NovaLibvirt
        - OS::TripleO::Services::NovaLibvirtGuests
        - OS::TripleO::Services::NovaMigrationTarget
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::ContainersLogrotateCrond
        - OS::TripleO::Services::OpenDaylightOvs
        - OS::TripleO::Services::Rhsm
        - OS::TripleO::Services::RsyslogSidecar
        - OS::TripleO::Services::Securetty
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::SkydiveAgent
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::Tuned
        - OS::TripleO::Services::Vpp
        - OS::TripleO::Services::OVNController
        - OS::TripleO::Services::OVNMetadataAgent
        - OS::TripleO::Services::Ptp
  2. roles_data_gpu.yaml という名前で、ControllerCompute、および ComputeGpu ロールが含まれる新しいロールデータファイルを生成します。

    (undercloud) [stack@director templates]$ openstack overcloud roles \
      generate -o /home/stack/templates/roles_data_gpu.yaml \
      ComputeGpu Compute Controller
  3. オーバークラウドノードを登録します。詳しい情報は、『director のインストールと使用方法』「オーバークラウドノードの登録」を参照してください。
  4. ノードのハードウェアを検査します。詳細は、『director のインストールと使用方法』「ノードのハードウェアの検査」を参照してください。
  5. 仮想 GPU 負荷用に指定するノードをタグ付けするための、compute-vgpu-nvidia フレーバーを作成します。

    (undercloud) [stack@director templates]$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute-vgpu-nvidia
    +----------------------------+--------------------------------------+
    | Field                      | Value                                |
    +----------------------------+--------------------------------------+
    | OS-FLV-DISABLED:disabled   | False                                |
    | OS-FLV-EXT-DATA:ephemeral  | 0                                    |
    | disk                       | 40                                   |
    | id                         | 9cb47954-be00-47c6-a57f-44db35be3e69 |
    | name                       | compute-vgpu-nvidia                  |
    | os-flavor-access:is_public | True                                 |
    | properties                 |                                      |
    | ram                        | 6144                                 |
    | rxtx_factor                | 1.0                                  |
    | swap                       |                                      |
    | vcpus                      | 4                                    |
    +----------------------------+--------------------------------------+
  6. GPU 負荷用に指定するそれぞれのノードを、compute-vgpu-nvidia プロファイルでタグ付けします。

    (undercloud) [stack@director templates]$ openstack baremetal node set --property capabilities='profile:compute-vgpu-nvidia,boot_option:local' <node>

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

  7. ロールが作成されたことを確認するには、以下のコマンドを入力します。

    (undercloud) [stack@director templates]$ openstack overcloud profiles list

11.2.3. 仮想 GPU 向けコンピュートノードの設定およびオーバークラウドのデプロイ

環境内の物理 GPU デバイスに対応する仮想 GPU の種別を取得して割り当て、仮想 GPU 用コンピュートノードを設定するための環境ファイルを準備する必要があります。

手順

  1. Red Hat Enterprise Linux と NVIDIA GRID ドライバーを一時コンピュートノードにインストールし、そのノードを起動します。NVIDIA GRID ドライバーのインストールについての詳細は、「GPU 対応カスタムオーバークラウドイメージのビルド」を参照してください。
  2. コンピュートノードで、有効にする物理 GPU デバイスに対応する仮想 GPU の種別を確認します。libvirt の場合、仮想 GPU は仲介デバイスまたは mdev 種別のデバイスです。サポートされている mdev デバイスを検出するには、以下のコマンドを入力します。

    [root@overcloud-computegpu-0 ~]# ls /sys/class/mdev_bus/0000\:06\:00.0/mdev_supported_types/
    nvidia-11  nvidia-12  nvidia-13  nvidia-14  nvidia-15  nvidia-16  nvidia-17  nvidia-18  nvidia-19  nvidia-20  nvidia-21  nvidia-210  nvidia-22
    
    [root@overcloud-computegpu-0 ~]# cat /sys/class/mdev_bus/0000\:06\:00.0/mdev_supported_types/nvidia-18/description
    num_heads=4, frl_config=60, framebuffer=2048M, max_resolution=4096x2160, max_instance=4
  3. compute-gpu.yaml ファイルを network-environment.yaml ファイルに追加します。

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::ComputeGpu::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute-gpu.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
      #OS::TripleO::AllNodes::Validation: OS::Heat::None
  4. 以下のパラメーターを node-info.yaml ファイルに追加して、GPU コンピュートノードの数および vGPU が指定されたコンピュートノード用に使用するフレーバーを指定します。

    parameter_defaults:
      OvercloudControllerFlavor: control
      OvercloudComputeFlavor: compute
      OvercloudComputeGpuFlavor: compute-vgpu-nvidia
      ControllerCount: 1
      ComputeCount: 0
      ComputeGpuCount: 3 #set to the no of GPU nodes you have
  5. gpu.yaml ファイルを作成し、GPU デバイスの仮想 GPU 種別を指定します。

    parameter_defaults:
      ComputeGpuExtraConfig:
        nova::compute::vgpu::enabled_vgpu_types:
          - nvidia-18
    注記

    各物理 GPU がサポートするのは 1 つの仮想 GPU 種別だけです。このプロパティーで複数の仮想 GPU 種別を指定した場合は、最初の種別だけが使用されます。

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

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

11.3. 仮想 GPU イメージおよびフレーバーの作成

クラウドユーザーが仮想 GPU (vGPU) を使用するインスタンスを作成できるようにするには、仮想 GPU 対応のカスタムイメージを定義すると共に、仮想 GPU フレーバーを作成することができます。

11.3.1. カスタム GPU インスタンスイメージの作成

GPU 対応のコンピュートノードと共にオーバークラウドをデプロイしたら、NVIDIA GRID ゲストドライバーおよびライセンスファイルを使用して仮想 GPU 対応のカスタムインスタンスイメージを作成することができます。

手順

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

    (overcloud) [stack@director ~]$ openstack server create --flavor <flavor> --image <image> temp_vgpu_instance
    • <flavor> を、仮想 GPU インスタンスが必要とするハードウェアプロファイルを持つフレーバーの名前または ID に置き換えてください。デフォルトのフレーバーに関する情報は、「フレーバーの管理」を参照してください。
    • <image> を、仮想 GPU インスタンスが必要とするソフトウェアプロファイルを持つイメージの名前または ID に置き換えてください。RHEL クラウドイメージのダウンロードに関する情報は、「Image サービス」を参照してください。
  2. cloud-user としてインスタンスにログインします。詳細は、「インスタンスへのログイン」を参照してください。
  3. NVIDIA のガイダンス (「Licensing an NVIDIA vGPU on Linux by Using a Configuration File」) に従って、インスタンス上に gridd.conf NVIDIA GRID ライセンスファイルを作成します。
  4. インスタンスに GPU ドライバーをインストールします。NVIDIA ドライバーのインストールについての詳細は、「Installing the NVIDIA vGPU Software Graphics Driver on Linux」を参照してください。

    注記

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

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

    (overcloud) [stack@director ~]$ openstack server image create --name vgpu_image temp_vgpu_instance
  6. オプション: インスタンスを削除します。

11.3.2. インスタンス用の仮想 GPU フレーバーの作成

GPU 対応のコンピュートノードと共にオーバークラウドをデプロイしたら、カスタムフレーバーを作成することができます。このフレーバーを使用して、クラウドユーザーは GPU 負荷用のインスタンスを起動することができます。

手順

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

    (overcloud) [stack@virtlab-director2 ~]$ openstack flavor create --vcpus 6 --ram 8192 --disk 100 m1.small-gpu
    +----------------------------+--------------------------------------+
    | Field                      | Value                                |
    +----------------------------+--------------------------------------+
    | OS-FLV-DISABLED:disabled   | False                                |
    | OS-FLV-EXT-DATA:ephemeral  | 0                                    |
    | disk                       | 100                                  |
    | id                         | a27b14dd-c42d-4084-9b6a-225555876f68 |
    | name                       | m1.small-gpu                         |
    | os-flavor-access:is_public | True                                 |
    | properties                 |                                      |
    | ram                        | 8192                                 |
    | rxtx_factor                | 1.0                                  |
    | swap                       |                                      |
    | vcpus                      | 6                                    |
    +----------------------------+--------------------------------------+
  2. 作成したフレーバーに仮想 GPU のリソースを割り当てます。各インスタンスに割り当てられる仮想 GPU は 1 つだけです。

    (overcloud) [stack@virtlab-director2 ~]$ openstack flavor set m1.small-gpu --property "resources:VGPU=1"
    
    (overcloud) [stack@virtlab-director2 ~]$ openstack flavor show m1.small-gpu
    +----------------------------+--------------------------------------+
    | Field                      | Value                                |
    +----------------------------+--------------------------------------+
    | OS-FLV-DISABLED:disabled   | False                                |
    | OS-FLV-EXT-DATA:ephemeral  | 0                                    |
    | access_project_ids         | None                                 |
    | disk                       | 100                                  |
    | id                         | a27b14dd-c42d-4084-9b6a-225555876f68 |
    | name                       | m1.small-gpu                         |
    | os-flavor-access:is_public | True                                 |
    | properties                 | resources:VGPU='1'                   |
    | ram                        | 8192                                 |
    | rxtx_factor                | 1.0                                  |
    | swap                       |                                      |
    | vcpus                      | 6                                    |
    +----------------------------+--------------------------------------+

11.3.3. 仮想 GPU インスタンスの起動

GPU 負荷用の GPU 対応インスタンスを作成することができます。

手順

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

    (overcloud) [stack@virtlab-director2 ~]$ 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>

11.4. GPU デバイスの PCI パススルーの有効化

PCI パススルーを使用して、グラフィックカード等の物理 PCI デバイスをインスタンスに接続することができます。デバイスに PCI パススルーを使用する場合、インスタンスはタスクを実行するためにデバイスへの排他的アクセスを確保し、ホストはデバイスを利用することができません。

前提条件

手順

  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 パススルー用にオーバークラウド上のコントローラーノードを設定するには、環境ファイル (例: pci_passthru_controller.yaml) を作成します。
  3. pci_passthru_controller.yamlNovaSchedulerDefaultFilters パラメーターに PciPassthroughFilter を追加します。

    parameter_defaults:
      NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
  4. コントローラーノード上のデバイスの PCI エイリアスを指定するには、以下の設定を pci_passthru_controller.yaml に追加します。

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

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

  5. PCI パススルー用にオーバークラウド上のコンピュートノードを設定するには、環境ファイル (例: pci_passthru_compute.yaml) を作成します。
  6. コンピュートノード上のデバイスで利用可能な PCI を指定するには、以下の設定を pci_passthru_compute.yaml に追加します。

    parameter_defaults:
      NovaPCIPassthrough:
        - vendor_id: "10de"
          product_id: "1eb8"
  7. PCI パススルーをサポートするためにコンピュートノードのサーバー BIOS で IOMMU を有効にするには、pci_passthru_compute.yamlKernelArgs パラメーターを追加します。

       parameter_defaults:
          ...
          ComputeParameters:
            KernelArgs: "intel_iommu=on iommu=pt"
  8. その他の環境ファイルと共にカスタム環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

    (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
  9. 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 rhelgpu --wait test-pci
  2. クラウドユーザーとしてインスタンスにログインします。
  3. インスタンスに GPU ドライバーをインストールします。たとえば、以下のスクリプトを実行して NVIDIA ドライバーをインストールします。

    $ sh NVIDIA-Linux-x86_64-430.24-grid.run
  4. インスタンスが GPU にアクセスできることを確認するには、インスタンスから以下のコマンドを入力します。

    $ lspci -nn | grep <gpu_name>
  5. 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                                                 |
    -----------------------------------------------------------------------------

付録A イメージの設定パラメーター

以下のキーは、glance image-update および glance image-create の両コマンドの property オプションに使用することができます。以下は例になります。

$ glance image-update <image_uuid> --property architecture=x86_64
注記

フレーバーで同じ属性と競合するイメージ属性を設定した場合には、フレーバー属性が使用されるか、またはエラーが発生します。レガシー互換性を確保するために、この動作にはいくつかの例外があります。

表A.1 属性のキー

対象コンポーネントキー説明サポートされている値

すべて

architecture

ハイパーバイザーがサポートする必要のある CPU アーキテクチャー。たとえば、x86_64armppc64 等。マシンのアーキテクチャーを確認するには、uname -m を実行します。

  • alpha - DEC 64 ビット RISC
  • armv7l - ARM Cortex-A7 MPCore
  • cris- Ethernet, Token Ring、AXis-Code Reduced Instruction Set
  • i686 - Intel sixth-generation x86 (P6 マイクロアーキテクチャー)
  • ia64 - Itanium
  • lm32 - Lattice Micro32
  • m68k - Motorola 68000
  • microblaze - Xilinx 32 ビット FPGA (Big Endian)
  • microblazeel - Xilinx 32 ビット FPGA (Little Endian)
  • mips - MIPS 32 ビット RISC (Big Endian)
  • mipsel - MIPS 32 ビット RISC (Little Endian)
  • mips64 - MIPS 64 ビット RISC (Big Endian)
  • mips64el - MIPS 64 ビット RISC (Little Endian)
  • openrisc - OpenCores RISC
  • parisc - HP Precision Architecture RISC
  • parisc64 - HP Precision Architecture 64 ビット RISC
  • ppc - PowerPC 32 ビット
  • ppc64 - PowerPC 64 ビット
  • ppcemb - PowerPC (Embedded 32 ビット)
  • s390 - IBM Enterprise Systems Architecture/390
  • s390x - S/390 64 ビット
  • sh4 - SuperH SH-4 (Little Endian)
  • sh4eb - SuperH SH-4 (Big Endian)
  • sparc - Scalable Processor Architecture、32 ビット
  • sparc64 - Scalable Processor Architecture、64 ビット
  • unicore32 - Microprocessor Research and Development Center RISC Unicore32
  • x86_64 - IA-32 の 64 ビット拡張
  • xtensa - Tensilica Xtensa 構成可能マイクロプロセッサーコア
  • xtensaeb - Tensilica Xtensa 構成可能マイクロプロセッサーコア (Big Endian)

すべて

hypervisor_type

ハイパーバイザーのタイプ

kvmvmware

すべて

instance_uuid

スナップショットイメージの場合に、このイメージを作成するのに使用したサーバーの UUID

有効なサーバーの UUID

すべて

kernel_id

AMI 形式のイメージをブートする際にカーネルとして使用する必要のある Image サービスに保管されているイメージの ID

有効なイメージ ID

すべて

os_distro

オペレーティングシステムのディストリビューションの小文字による一般名

  • arch - Arch Linux。archlinux および org.archlinux は使用しないでください。
  • centos - Community Enterprise Operating System。org.centos および CentOS は使用しないでください。
  • debian - Debian。Debian および org.debian は使用しないでください。
  • fedora: Fedora。Fedoraorg.fedoraorg.fedoraproject は使用しないでください。
  • freebsd: FreeBSD。org.freebsdfreeBSDFreeBSD は使用しないでください。
  • gentoo: Gentoo Linux。Gentoo および org.gentoo は使用しないでください。
  • mandrake: Mandrakelinux (MandrakeSoft) ディストリビューション。mandrakelinux および MandrakeLinux は使用しないでください。
  • mandriva: Mandriva Linux。mandrivalinux は使用しないでください。
  • mes: Mandriva Enterprise Server。mandrivaent および mandrivaES は使用しないでください。
  • msdos Microsoft Disc Operating System。ms-dos は使用しないでください。
  • netbsd: NetBSD。NetBSD および org.netbsd は使用しないでください。
  • netware: Novell NetWare。novell および NetWare は使用しないでください。
  • openbsd: OpenBSD。OpenBSD および org.openbsd は使用しないでください。
  • opensolaris: OpenSolaris。OpenSolaris および org.opensolaris は使用しないでください。
  • opensuse: openSUSE。suseSuSEorg.opensuse は使用しないでください。
  • rhel: Red Hat Enterprise Linux。redhatRedHatcom.redhat は使用しないでください。
  • sled: SUSE Linux Enterprise Desktop。com.suse は使用しないでください。
  • ubuntu: Ubuntu。Ubuntucom.ubuntuorg.ubuntucanonical は使用しないでください。
  • windows: Microsoft Windows。com.microsoft.server は使用しないでください。

すべて

os_version

ディストリビューターによって指定されるオペレーティングシステムのバージョン

バージョン番号 (例:「11.10」)

すべて

ramdisk_id

AMI 形式のイメージをブートする際に ramdisk として使用する必要のある、Image サービスに保管されているイメージの ID

有効なイメージ ID

すべて

vm_mode

仮想マシンのモード。仮想マシンに使用されるホスト/ゲストの ABI (アプリケーションバイナリーインターフェース) を示します。

hvm: 完全仮想化。これは QEMU および KVM で使用されるモードです。

libvirt API ドライバー

hw_disk_bus

ディスクデバイスの接続先となるディスクコントローラーのタイプを指定します。

scsivirtioideusb のいずれか。iscsi を使用している場合には、hw_scsi_modelvirtio-scsi に設定する必要がある点に注意してください。

libvirt API ドライバー

hw_cdrom_bus

CD-ROM デバイスの接続先となるディスクコントローラーの種別を指定します。

scsivirtioideusb のいずれか。iscsi を指定する場合は、hw_scsi_model パラメーターを virtio-scsi に設定する必要があります。

libvirt API ドライバー

hw_numa_nodes

インスタンスに公開する NUMA ノードの数 (フレーバーの定義はオーバーライドしません)

整数。NUMA トポロジー定義の詳しい例は、「メタデータの追加」で「hw:NUMA_def key」を参照してください。

libvirt API ドライバー

hw_numa_cpus.0

vCPU N-M から NUMA ノード 0 へのマッピング (フレーバーの定義はオーバーライドしません)

整数のコンマ区切りリスト

libvirt API ドライバー

hw_numa_cpus.1

vCPU N-M から NUMA ノード 1 へのマッピング (フレーバーの定義はオーバーライドしません)

整数のコンマ区切りリスト

libvirt API ドライバー

hw_numa_mem.0

N MB の RAM から NUMA ノード 0 へのマッピング (フレーバーの定義はオーバーライドしません)

整数

libvirt API ドライバー

hw_numa_mem.1

N MB の RAM から NUMA ノード 1 へのマッピング (フレーバーの定義はオーバーライドしません)

整数

libvirt API ドライバー

hw_qemu_guest_agent

ゲストエージェントのサポート。yes に設定し、かつ qemu-ga もインストールされている場合には、ファイルシステムが休止 (フリーズ) し、スナップショットが自動的に作成されます。

yes / no

libvirt API ドライバー

hw_rng_model

乱数生成器をイメージのインスタンスに追加します。インスタンスのフレーバーを設定することにより、クラウド管理者は、デバイスの動作を有効化して制御することができます。デフォルトでは以下のように設定されます。

  • 乱数生成器は無効化されます。
  • /dev/random がデフォルトのエントロピーソースとして使用されます。物理ハードウェアの乱数生成器を指定するには、Compute 環境ファイルで rng_dev_path を「/dev/hwrng」に設定します。

virtio またはその他のサポートされているデバイス

libvirt API ドライバー

hw_scsi_model

VirtIO SCSI (virtio-scsi) の使用を有効にして、コンピュートインスタンスのブロックデバイスアクセスを提供します。VirtIO SCSI は準仮想化 SCSI コントローラーデバイスで、より高いスケーラビリティーとパフォーマンスを提供し、高度な SCSI ハードウェアに対応します。

virtio-scsi

libvirt API ドライバー

hw_video_model

仮想マシンインスタンスで使用するビデオデバイスドライバー

サポートされるドライバーの一覧を優先される順に示します。

  • virtio: (推奨) Gallium GPU 仕様の仮想 GPU で、OpenGL をレンダリングするのに VIRGL レンダラーを使用します。この GPU モデルはすべてのアーキテクチャーでサポートされ、ホストに専用の GPU がある場合には、ハードウェアアクセラレーションを利用することができます。詳細は、Virgil 3D GPU プロジェクト を参照してください。
  • qxl: Spice または noVNC 環境用の高性能ドライバー
  • cirrus: レガシードライバー。QXL ドライバーが利用できない場合に使用します。
  • vga: IBM Power 環境用にこのドライバーを使用します。
  • gop: QEMU/KVM 環境ではサポートされません。
  • xen: KVM 環境ではサポートされません。
  • vmvga: レガシードライバー。このドライバーは使用しないでください。
  • none: この値を使用して、仮想 GPU (vGPU) インスタンスのエミュレートされたグラフィックスまたはビデオを無効にします。この場合、ドライバーは別途設定されます。詳細は、「11章インスタンス用の仮想 GPU の設定」を参照してください。

libvirt API ドライバー

hw_video_ram

ビデオイメージの最大 RAM。フレーバーの extra_specshw_video:ram_max_mb の値が設定済みで、かつその値が hw_video_ram で設定されている値を上回る場合にのみ使用されます。

整数 (MB 単位。例: 64)

libvirt API ドライバー

hw_watchdog_action

サーバーがハングした場合に指定したアクションを実行する仮想ハードウェアウォッチドッグデバイスを有効にします。このウォッチドッグは、i6300esb デバイスを使用します (PCI Intel 6300ESB をエミュレート)。hw_watchdog_action が指定されていない場合には、ウォッチドッグは無効になります。

  • disabled: デバイスは接続されていません。イメージのフレーバーを使用して有効化されている場合でも、ユーザーがイメージのウォッチドッグを無効にすることができます。このパラメーターのデフォルト値は「disabled」です。
  • reset: ゲストを強制的にリセットします。
  • poweroff: ゲストの電源を強制的に切断します。
  • pause: ゲストを一時停止します。
  • none: ウォッチドッグを有効化するのみで、サーバーがハングした場合には何もしません。

libvirt API ドライバー

os_command_line

デフォルトではなく、libvirt ドライバーで使用されるカーネルコマンドライン。Linux Containers (LXC) の場合は、この値が初期化の引数として使用されます。このキーは、Amazon カーネル、ramdisk、またはマシンイメージ (aki、ari、または ami) にのみ有効です。

 

libvirt API ドライバーおよび VMware API ドライバー

hw_vif_model

使用する仮想ネットワークインターフェースデバイスのモデルを指定します。

設定したハイパーバイザーによって有効なオプションは異なります。

  • KVM および QEMU: e1000、ne2k_pci、pcnet、rtl8139、virtio
  • VMware: e1000、e1000e、VirtualE1000、VirtualE1000e、VirtualPCNet32、VirtualSriovEthernetCard、VirtualVmxnet
  • Xen: e1000、netfront、ne2k_pci、pcnet、rtl8139

VMware API ドライバー

vmware_adaptertype

ハイパーバイザーが使用する仮想 SCSI または IDE コントローラー

lsiLogicbusLogic、または ide

VMware API ドライバー

vmware_ostype

イメージにインストールされているオペレーティングシステムを示す VMware GuestID。この値は、仮想マシンの作成時にハイパーバイザーに渡されます。指定しなかった場合には、このキーの値はデフォルトの otherGuest に設定されます。

詳細は、「Images with VMware vSphere」を参照してください。

VMware API ドライバー

vmware_image_version

現在は使用されていません。

1

XenAPI ドライバー

auto_disk_config

true に指定した場合には、ディスク上の root パーティションは、インスタンスがブートする前に自動的にリサイズされます。この値は、Xen ベースのハイパーバイザーを XenAPI ドライバーと共に使用する場合にのみ Compute サービスによって考慮されます。Compute サービスは、イメージに単一のパーティションがあり、かつそのパーティションが ext3 またはext4 のフォーマットの場合にのみリサイズを試みます。

true / false

libvirt API ドライバーおよび XenAPI ドライバー

os_type

イメージ上にインストールされるオペレーティングシステム。XenAPI ドライバーには、イメージの os_type パラメーターの値によって異なるアクションを実行するロジックが組み込まれています。たとえば、os_type=windows イメージの場合には、Linux スワップパーティションの代わりに、FAT32 ベースのスワップパーティションを作成し、挿入されるホスト名を 16 文字未満に制限します。

linux または windows

付録B インスタンスの起動ウィザードの有効化

Dashboard からインスタンスを起動するには、2 つの方法があります。

  • インスタンスの起動フォーム
  • インスタンスの起動ウィザード

インスタンスの起動フォームはデフォルトで有効化されますが、インスタンスの起動ウィザードを随時有効化することができます。インスタンスの起動のフォームとウィザードを同時に有効化することも可能です。インスタンスの起動ウィザードにより、インスタンスの作成に必要なステップが簡素化されます。

  1. /etc/openstack-dashboard/local_settings ファイルを編集して以下の値を追加します。

    LAUNCH_INSTANCE_LEGACY_ENABLED = False
    LAUNCH_INSTANCE_NG_ENABLED = True
  2. httpd サービスを再起動します。

    # systemctl restart httpd

インスタンスの起動フォームとウィザードの設定が更新されます。

これらのオプションのいずれか 1 つのみを有効にした場合には、Dashboard で インスタンスの起動 ボタンをクリックすると、そのオプションがデフォルトで開きます。両方のオプションを有効化した場合には、Dashboard に インスタンスの起動 ボタンが 2 つ表示され、左のボタンはインスタンスの起動ウィザード、右のボタンはインスタンスの起動フォームを表示します。