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

Red Hat Enterprise Linux OpenStack Platform 7

インスタンス、イメージ、ボリューム、コンテナーの管理

OpenStack Documentation Team

概要

インスタンス&イメージガイドは、Red Hat Enterprise Linux OpenStack Platform 環境におけるインスタンス、イメージ、ボリューム、コンテナーの管理手順を記載しています。

前書き

Red Hat Enterprise Linux OpenStack Platform (RHEL OpenStack Platform) は、Red Hat Enterprise Linux をベースとして、プライベートまたはパブリックの Infrastructure-as-a-Service (IaaS) クラウドを構築するための基盤を提供します。これにより、スケーラビリティーが極めて高く、耐障害性に優れたプラットフォームをクラウド対応のワークロード開発にご利用いただくことができます。

本ガイドでは、イメージ、インスタンス、ボリューム、コンテナーの作成/管理手順について説明します。また、インスタンス用のストレージの設定、RHEL OpenStack Platform 用の NFS バックエンドの設定手順も記載しています。

OpenStack Dashboard またはコマンドラインクライアントを使用してクラウドの管理を行うことができます。大半の手順は、これらのいずれかの方法を使用することができますが、一部の高度な手順はコマンドラインのみで実行可能となっています。本ガイドでは、可能な場合には Dashboard を使用する手順を記載しています。

注記

RHEL OpenStack Platform の全ドキュメントスイートは Red Hat Enterprise Linux OpenStack Platform の製品ドキュメント で参照してください。

第1章 Image サービス

本章では、RHEL OpenStack Platform でイメージとストレージを管理するための手順を説明します。

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

  • RAW: 非構造化のディスクイメージ形式
  • QCOW2: QEMU エミュレーターでサポートされているディスク形式
  • ISO: ディスク上のデータをセクター単位でコピーし、バイナリーファイルに格納した形式
  • AKI: Amazon Kernel Image
  • AMI: Amazon Machine Image
  • ARI: Amazon RAMDisk Image
  • VDI: VirtualBox の仮想マシンモニターおよび QEMU エミュレーターでサポートされているディスク形式
  • VHD: VMWare、VirtualBox などの仮想マシンモニターで使用されている一般的なディスク形式
  • VMDK: 数多くの一般的な仮想マシンモニターでサポートされているディスク形式

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

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

1.1. Image サービス: 新機能

RHEL OpenStack Platform 7 リリースでは、Image サービスで以下の新機能が利用できるようになりました。

  • イメージの変換: イメージのインポート中にタスク API を呼び出して、イメージを変換します (kilo リリースでは、qcow/raw 形式のみに対応)。

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

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

    注記

    フォーマットの変換は、イメージ (元のコピー) を インポート するとトリガーされます。イメージの アップロード 時には実行されません。以下に例を示します。

    $ glance --os-image-api-version 2 task-create --type import --input '{"import_from_format": "qcow2", "import_from": "http://127.0.0.1:8000/test.qcow2", "image_properties": {"disk_format": "qcow2", "container_format": "bare"}}'
  • イメージのイントロスペクション: すべてのイメージフォーマットには、イメージ自体の中に埋め込まれたメタデータセットがあります。

    たとえば、ストリーム最適化 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 であることを簡単に確認することができます。このように Image サービス内のメタデータを抽出することにより、管理者は、上書きする必要がなければ、それらのメタデータについて注意を払う必要はありません。これらのメタデータパラメーターは、イメージのコンシューマーに役立ちます。Compute では、streamOptimized ディスクをインスタンス化するワークフローは、flat ディスクをインスタンス化するワークフローとは完全に異なります。この新機能により、メタデータの抽出が可能となります。イメージのイントロスペクションは、イメージのインポート中に、タスク API を呼び出すことによって実行できます。

    注記

    Kilo リリースでイントロスペクションを実行できるのは、virtual_size メタデータパラメーターのみです。

1.2. イメージの管理

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

注記

クローンの元となっている親イメージを確認するには、glance-api.confshow_image_direct_urlTrue に設定する必要があります。詳しい情報は、『Configuration Reference』の「Chapter 8. Image Service」 を参照してください。

1.2.1. イメージの作成

本項では、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 の ISO ファイルを使用して、.qcow2 形式の OpenStack 互換イメージを手動で作成する手順について説明します。

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

すでに準備済みの RHEL KVM ゲストの qcow2 イメージは、RHEL 7 KVM Guest Image または RHEL 6.6 KVM Guest Image で入手することができます。これらのイメージは、cloud-init を使用して設定されます。適切に機能させるには、ec2 互換のメタデータサービスを利用して SSH キーをプロビジョニングする必要があります。

注記

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

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

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

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

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

キーペアを使用しない場合には、「インスタンスへの admin パスワードの挿入」の手順に従って admin パスワードを設定してください。

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

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

前提条件

  • イメージを作成する Linux ホストマシン。これは、Linux パッケージをインストール/実行することのできる任意のマシンです。
  • libvirt、virt-manager (yum groupinstall -y @virtualization のコマンドを実行)。ゲストオペレーティングシステムを作成するのに必要な全パッケージがインストールされます。
  • Libguestfs ツール (「yum install -y libguestfs-tools-c」のコマンドを実行してください)。仮想マシンイメージにアクセスして変更を行うためのツールセットがインストールされます。
  • Red Hat Enterprise Linux 7 の ISO ファイル (RHEL 7.0 Binary DVD または RHEL 6.6 Binary DVD を参照)
  • テキストエディター (kickstart ファイルを編集する必要がある場合)
注記

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

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

本項では、Red Hat Enterprise Linux 7 の ISO ファイルを使用して、.qcow2 形式の OpenStack 互換イメージを手動で作成する手順について説明します。

  1. 以下に示したように virt-install でインストールを開始します。

    [user@host]# qemu-img create -f qcow2 rhel7.qcow2 8G
    [user@host]# virt-install --virt-type kvm --name rhel7 --ram 2048 \
    --cdrom /tmp/rhel-server-7.0-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

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

    注記

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

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

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

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

    # subscription-manager register
    1. プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。

      Username: admin@example.com
      Password:
    2. 使用するチャンネルが含まれたエンタイトルメントプールを特定します。

      # subscription-manager list --available | grep -A8 "Red Hat Enterprise Linux Server"
    3. 上記のステップで特定したプール ID を使用して、Red Hat Enterprise Linux Server のエンタイトルメントをシステムにアタッチします。

      # subscription-manager attach --pool=pool_id
    4. 必須チャンネルを有効にします。

      # subscription-manager repos --enable=rhel-7-server-rpms

      RHEL OpenStack Platform 7 の場合は、必須チャンネルは rhel-7-server-openstack-7.0-rpms および rhel-7-server-rh-common-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 -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 コマンドでイメージのリセットおよびクリーニングをして、インスタンスの作成を問題なく行えるようにします。

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

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

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

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

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

本項では、 Red Hat Enterprise Linux 6 の ISO ファイルを使用して、.qcow2 形式の OpenStack 互換イメージを手動で作成する手順について説明します。

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

    [user@host]# qemu-img create -f qcow2 rhel6.qcow2 4G
    [user@host]# virt-install --connect=qemu:///system --network=bridge:virbr0 \
    --name=rhel6.6 --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.6-x86_64-dvd.iso

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

    注記

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

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

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

      インストールは、ディスクをチェックして、Media Check を実行します。チェックの結果が Success となると、そのディスクは取り出されます。

    2. 適切な 言語 および キーボード オプションを選択します。
    3. インストールに使用するデバイスタイプを尋ねるプロンプトが表示されたら、基本ストレージデバイス を選択します。 RHEL6 Install3
    4. デバイスの ホスト名 を指定します。デフォルトのホスト名は localhost.localdomain です。
    5. タイムゾーンroot パスワードを指定します。
    6. ディスクの空き容量に応じて、インストールのタイプを選択します。 RHEL6 Install4
    7. SSH サーバーをインストールする 基本サーバー インストールを選択します。 RHEL6 Install5
    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. コンテンツ配信ネットワークにマシンを登録します。

    # subscription-manager register
    1. プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。

      Username: admin@example.com
      Password:
    2. 使用するチャンネルが含まれたエンタイトルメントプールを特定します。

      # subscription-manager list --available | grep -A8 "Red Hat Enterprise Linux Server"
    3. 上記のステップで特定したプール ID を使用して、Red Hat Enterprise Linux Server のエンタイトルメントをシステムにアタッチします。

      # subscription-manager attach --pool=pool_id
    4. 必須チャンネルを有効にします。

      # subscription-manager repos --enable=rhel-6-server-rpms

      RHEL OpenStack Platform 7 の場合は、必須チャンネルは rhel-7-server-openstack-7.0-rpms および rhel-6-server-rh-common-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 コマンドでイメージのリセットおよびクリーニングをして、インスタンスの作成を問題なく行えるようにします。

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

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

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

    注記

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

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

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

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

名前

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

説明

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

イメージソース

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

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

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

形式

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

アーキテクチャー

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

最小ディスク (GB)

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

最小メモリー (MB)

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

パブリック

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

保護

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

注記

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

1.2.3. イメージの更新

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

    注記

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

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

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

1.2.4. イメージの削除

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

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

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

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

Red Hat Enterprise Linux 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 コマンドを使用して確認することができます。ブロックデバイスとして通常使用するように、フォーマット、マウント、使用が可能です。アタッチ先のインスタンス以外では、このディスクの保存や参照をする方法はありません。

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

2.2. 設定

libvirt ベースとインスタンスディスクを処理するための Compute の設定により、お使いの環境のパフォーマンスとセキュリティー両方を決定することができます。パラメーターは、/etc/nova/nova.conf ファイルで設定します。

表2.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章 仮想マシンのインスタンス

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

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

3.1. インスタンスの管理

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

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

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

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

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

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

3.1.2. インスタンスの作成

  1. Dashboard で プロジェクト > コンピュート > インスタンス を選択します。
  2. インスタンスの起動 をクリックします。
  3. 各フィールド (「*」でマークされているフィールドは必須) にインスタンスの設定値を入力し、完了したら 起動 をクリックします。
タブフィールド説明

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

プロジェクト

ドロップダウンリストからプロジェクトを選択します。

 

ユーザー

ドロップダウンリストからユーザーを選択します。

詳細

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

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

 

インスタンス名

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

 

フレーバー

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

 

インスタンス数

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

 

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

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

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

キーペア

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

 

セキュリティーグループ

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

ネットワーク

選択済みネットワーク

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

作成後

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

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

注記

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

高度な設定

ディスクパーティション

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

 

コンフィグドライブ

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

3.1.3. インスタンスの更新 (アクションメニュー)

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

アクション説明

スナップショットの作成

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

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

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

インスタンスの編集

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

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

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

コンソール

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

ログの参照

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

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

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

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

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

インスタンスのリサイズ

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

ソフトリブート

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

ハードリブート

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

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

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

インスタンスの再作成

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

インスタンスの終了

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

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

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

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

  1. 各ホストに SSH 鍵認証を設定してホスト間で通信ができるようにして、Compute が SSH を使用してディスクを他のホストに移動できるようにします (例: 複数のコンピュートノードが同じ SSH 鍵を共有することが可能です)。

    SSH 鍵認証についての詳しい情報は、Red Hat Enterprise Linux OpenStack Platform に掲載されている『インスタンスの移行ガイド』の「ノード間の SSH トンネリングの設定」の項を参照してください。

  2. 元のホストでリサイズを有効にするには、/etc/nova/nova.conf ファイルで以下のパラメーターを設定します。

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

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

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

本項では、Dashboard またはコマンドラインインターフェースを使用して、インスタンスのコンソールにアクセスする複数の方法について説明します。また、インスタンスのシリアルポートに直接接続して、ネットワーク接続が失敗しても、デバッグすることが可能です。

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

コンソールを使用すると、Dashboard 内でインスタンスに直接アクセスすることができます。

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

3.1.5.2. VNC コンソールへの直接接続

nova get-vnc-console コマンドで返された URL を使用すると、インスタンスの VNC コンソールに直接アクセスすることができます。

ブラウザー

ブラウザーの URL を取得するには、以下のコマンドを実行します。

$ nova get-vnc-console INSTANCE_ID novnc
Java クライアント

Java クライアントの URL を取得するには、以下のコマンドを実行します。

$ nova get-vnc-console INSTANCE_ID xvpvnc
注記

「nova-xvpvncviewer」は、Java クライアントの最も簡単な例を提供します。クライアントをダウンロードするには、以下のコマンドを実行します。

# git clone https://github.com/cloudbuilders/nova-xvpvncviewer
# cd nova-xvpvncviewer/viewer
# make

インスタンスの Java クライアント URL を使用してビューアーを実行します。

# java -jar VncViewer.jar _URL_

このツールは、お客様の便宜のためのみに提供されており、Red Hat では正式にサポートされていません。

3.1.5.3. シリアルコンソールへの直接接続

Websocket クライアントを使用すると、コンソールのシリアルポートに直接アクセスすることが可能です。シリアル接続は、通常デバッグツールで使用されます (たとえば、ネットワーク設定に問題がある場合でもインスタンスにアクセス可能)。実行中のインスタンスのシリアル URL を取得するには、以下のコマンドを実行します。

$ nova get-serial-console INSTANCE_ID
注記

「novaconsole」は、Websocket クライアントの最も簡単な例を提供します。クライアントをダウンロードするには、以下のコマンドを実行します。

# git clone https://github.com/larsks/novaconsole/
# cd novaconsole

インスタンスのシリアル URL を使用してクライアントを実行します。

# python console-client-poll.py

このツールは、お客様の便宜のためのみに提供されており、Red Hat では正式にサポートされていません。

ただし、インストールによっては、管理者があらかじめ「nova-serialproxy」サービスを設定する必要がある場合があります。プロキシーサービスは、OpenStack Compute のシリアルポートへの接続が可能な Websocket プロキシーです。

3.1.5.3.1. nova-serialproxy のインストールと設定
  1. nova-serialproxy サービスをインストールします。

    # yum install openstack-nova-serialproxy
  2. /etc/nova/nova.confserial_console セクションを更新します。

    1. nova-serialproxy サービスを有効化します。

      $ openstack-config --set /etc/nova/nova.conf serial_console enabled true
    2. nova get-serial-console コマンドで提供される URL の生成に使用する文字列を指定します。

      $ openstack-config --set /etc/nova/nova.conf serial_console base_url ws://PUBLIC_IP:6083/

      PUBLIC_IP は、nova-serialproxy サービスを実行するホストのパブリック IP アドレスに置き換えます。

    3. インスタンスのシリアルコンソールをリッスンする IP アドレスを指定します (文字列)。

      $ openstack-config --set /etc/nova/nova.conf serial_console listen 0.0.0.0
    4. プロキシークライアントが接続する必要のあるアドレスを指定します (文字列)。

      $ openstack-config --set /etc/nova/nova.conf serial_console proxyclient_address ws://HOST_IP:6083/

      HOST_IP は、Compute ホストの IP アドレスに置き換えます。たとえば、nova-serialproxy サービスを有効化する設定は、以下のようになります。

      [serial_console]
      enabled=true
      base_url=ws://192.0.2.0:6083/
      listen=0.0.0.0
      proxyclient_address=192.0.2.3
  3. Compute サービスを再起動します。

    # openstack-service restart nova
  4. nova-serialproxy サービスを起動します。

    # systemctl enable openstack-nova-serialproxy
    # systemctl start openstack-nova-serialproxy
  5. 実行中のインスタンスを再起動して、正しいソケットをリッスンするようになったことを確認します。
  6. シリアル/コンソール間のポート接続のためにファイアウォールを開きます。シリアルポートは、/etc/nova/nova.conf[serial_console]` port_range を使用して設定します。デフォルトの範囲は、10000:20000 です。以下のコマンドを実行して、iptables を更新します。

    # iptables -I INPUT 1 -p tcp --dport 10000:20000 -j ACCEPT

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

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

  • プロジェクト別

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

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

  • ハイパーバイザー別

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

    注記

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

3.1.7. インスタンスの削除

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

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

3.1.8. 複数のインスタンスの一括管理

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

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

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

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

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

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

3.2.1. キーペアの管理

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

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

3.2.1.1. キーペアの作成

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

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

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

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

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

3.2.1.3. キーペアの削除

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

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

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

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

プロジェクトのセキュリティー管理に関する詳しい情報は、Red Hat Enterprise Linux OpenStack Platform で『 Users and Identity Management Guide』の「プロジェクトのセキュリティー管理」の項を参照してください。

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

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

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

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

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

3.2.3.2. Floating IP の割り当て

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

    注記

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

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

3.2.3.3. Floating IP の解放

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

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

前提条件

  • インスタンスのセキュリティーグループには、SSH ルールが設定されていることを確認します (Red Hat Enterprise Linux OpenStack Platform で『 ユーザーおよびアイデンティティー管理ガイド』の「プロジェクトのセキュリティー管理」の項を参照してください)。
  • インスタンスに 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

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

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

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

    can_set_password: True
  2. /etc/nova/nova.conf ファイルで、inject_password パラメーターを True に設定します。

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

    # service nova-compute restart

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

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

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

# systemctl restart httpd.service

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

dashboard

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

3.3. フレーバーの管理

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

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

名前仮想 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 レートを強制するためのメタデータ、またはホストアグリゲートと一致させるためのメターデータを追加する
注記

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

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

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

"compute_extension:flavormanage": "",

3.3.2. フレーバーの作成

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

    タブフィールド説明

    フレーバー情報

    名前

    一意な名前

     

    ID

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

     

    仮想 CPU

    仮想 CPU 数

     

    メモリー (MB)

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

     

    ルートディスク (GB)

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

     

    一時ディスク (GB)

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

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

     

    スワップディスク (MB)

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

    フレーバーアクセス権

    選択済みのプロジェクト

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

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

3.3.3. 一般属性の更新

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

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

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

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

3.3.4.1. メタデータの表示

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

3.3.4.2. メタデータの追加

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

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

    flavor metadata

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

表3.2 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_mempolicy: メモリーの割り当てポリシー。有効なポリシーは以下の通りです。

    • strict: バインディングされる NUMA ノードからインスタンスの RAM が割り当てられるようにするには必須です (numa_nodes が指定されている場合にはデフォルト)。
    • preferred: カーネルは、代替ノードを使用するようにフォールバックすることが可能です。numa_nodes が「1」に設定されている場合に有用です。
  • numa_cpus.0: vCPU N-M を NUMA ノード 0 へマッピング (コンマ区切りの一覧)
  • numa_cpus.1: vCPU N-M を NUMA ノード 1 へマッピング (コンマ区切りの一覧)
  • numa_mem.0: メモリー N GB を NUMA ノード 0 へマッピング
  • numa_mem.1: メモリー N GB を NUMA ノード 1 へマッピング
  • numa_cpu.N および numa_mem.N は、numa_nodes が設定されている場合のみに有効です。また、これらの定義が必要になるのは、インスタンスの NUMA ノードの CPU および RAM が対称的に割り当てられていない場合のみです (NFV ワークロードの一部には重要)。
注記

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

インスタンスに 8 個の vCPU、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=3
  • hw:numa_mem.1=1

スケジューラーは、NUMA ノードが 2 つあり、そのうちの 1 つのノードで 6 つの CPU および 3 GB のメモリーを実行し、別のノードで 2 つの CPU および 1 GB のメモリーを実行できるホストを検索します。ホストに 8 つの CPU および 4 GB のメモリーを実行できる NUMA ノードが 1 つある場合は、有効な一致とは見なされません。numa_mempolicy の設定に関わらず、同様のロジックがスケジューラーで適用されます。

hw:watchdog_action

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

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

例: hw:watchdog_action=poweroff

hw_rng:action

イメージプロパティーを使用して乱数生成器をインスタンスに追加することができます (RHEL 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

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

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

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

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

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

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

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

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

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

  1. /etc/nova/nova.conf ファイルを編集します (root または nova ユーザーのパーミッションが必要です)。
  2. scheduler_default_filters パラメーターに以下の値が含まれていることを確認します。

    • ホストアグリゲートのメタデータ用の AggregateInstanceExtraSpecsFilter。たとえば、以下のように記載します。

      scheduler_default_filters=AggregateInstanceExtraSpecsFilter,RetryFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter
    • インスタンス起動時のアベイラビリティーゾーンのホストの仕様用の AvailabilityZoneFilter。たとえば、以下のように記載します。

      scheduler_default_filters=AvailabilityZoneFilter,RetryFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter
  3. 設定ファイルを保存します。

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

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

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

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

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

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

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

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

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

      注記

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

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

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

      キー説明

      cpu_allocation_ratio

      物理 CPU に対する仮想 CPU の割り当ての比率を設定します。これは、Compute のスケジューラーに設定されている AggregateCoreFilter フィルターによって異なります。

      disk_allocation_ratio

      物理ディスクに対する仮想ディスクの割り当ての比率を設定します。これは、Compute のスケジューラーに設定されている AggregateDiskFilter フィルターによって異なります。

      filter_tenant_id

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

      ram_allocation_ratio

      物理メモリーに対する仮想メモリーの割り当ての比率を設定します。これは、Compute のスケジューラーに設定されている AggregateRamFilter フィルターによって異なります。

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

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

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

3.5. ホストとセルのスケジュール

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

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

  • フィルター: インスタンスの配置先候補となるホストの初期セットを決定します (「スケジューリングフィルターの設定」を参照)。
  • 重み: フィルタリングの完了時に選出されたホストのセットは重み付けのシステムを使用して優先順位が決定されます。最も高い重みが最優先されます (「スケジューリングの重みの設定」を参照)。
  • スケジューラーサービス: スケジューラーホスト上の /etc/nova/nova.conf ファイルには数多くの設定オプションがあります。これらのオプションは、スケジューラーがタスクを実行する方法や、重み/フィルターを処理する方法を決定します。ホストとセルの両方にスケジューラーがあります。これらのオプションの一覧は『Configuration Reference』(RHEL OpenStack Platform の製品ドキュメント) を参照してください。

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

Scheduling Hosts

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

scheduler_default_filters オプションでスケジューラーが使用するフィルターを定義します (/etc/nova/nova.conf ファイル。root または nova ユーザーのパーミッションが必要)。

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

scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

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

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

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

フィルター説明

AggregateCoreFilter

ホストアグリゲートのメタデータキー cpu_allocation_ratio を使用して、オーバーコミット比 (物理 CPU に対する仮想 CPU の割り当ての比率) を超過したホストを除外します。これは、インスタンスにホストアグリゲートが指定されている場合のみに有効です。

 

この比率が設定されている場合には、フィルターは /etc/nova/nova.conf ファイルの cpu_allocation_ratio の値を使用します。デフォルト値は 16.0 です (1 物理 CPU に対して 16 仮想 CPU を割り当て可能)。

AggregateDiskFilter

ホストアグリゲートのメタデータキー disk_allocation_ratio を使用して、オーバーコミット比 (物理ディスクに対する仮想ディスクの割り当ての比率) を超過したホストを除外します。これは、インスタンスにホストアグリゲートが指定されている場合のみに有効です。

 

この比率が設定されている場合には、フィルターは /etc/nova/nova.conf ファイルの disk_allocation_ratio の値を使用します。デフォルト値は 1.0 です (1 物理ディスク に対して 1 仮想ディスクを割り当て可能)。

AggregateImagePropertiesIsolation

インスタンスのイメージのメタデータが一致するホストアグリゲート内のホストのみを渡します。これは、そのインスタンスにホストアグリゲートが指定されている場合にのみ有効です。詳しい情報は、「イメージの作成」を参照してください。

AggregateInstanceExtraSpecsFilter

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

AggregateMultiTenancyIsolation

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

注記

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

AggregateRamFilter

ホストアグリゲートのメタデータキー ram_allocation_ratio を使用して、オーバーコミット比 (物理メモリーに対する仮想メモリーの割り当ての比率) を超過したホストを除外します。これは、インスタンスにホストアグリゲートが指定されている場合のみに有効です。

 

この比率が設定されている場合には、フィルターは /etc/nova/nova.conf ファイルの ram_allocation_ratio の値を使用します。デフォルト値は 1.5 です (1 物理メモリーに対して 1.5 仮想メモリーを割り当て可能)。

AllHostsFilter

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

AvailabilityZoneFilter

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

ComputeCapabilitiesFilter

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

ComputeFilter

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

CoreFilter

/etc/nova/nova.conf ファイルの cpu_allocation_ratio を使用して、オーバーコミット比 (物理 CPU に対する仮想 CPU の比率) を超過したホストを除外します。デフォルトの値は 16.0 です (1 物理 CPU に対して 16 仮想 CPU を割り当て可能)。

DifferentHostFilter

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

DiskFilter

/etc/nova/nova.conf ファイルの disk_allocation_ratio を使用して、オーバーコミット比 (物理ディスクに対する仮想ディスクの比率) を超過したホストを除外します。デフォルトの値は 1.0 です (1 物理ディスクに対して 1 仮想ディスクを割り当て可能)。

ImagePropertiesFilter

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

IsolatedHostsFilter

/etc/nova/nova.conf ファイルで 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]'

MetricFilter

メトリックが利用できないホストを除外します。

NUMATopologyFilter

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

RamFilter

/etc/nova/nova.conf ファイルの ram_allocation_ratio を使用して、オーバーコミット比 (物理メモリーに対する仮想メモリーの比率) を超過したホストを除外します。デフォルトの値は 1.5 です (1 物理メモリーに対して 1 仮想メモリーを割り当て可能)。

RetryFilter

スケジュールを試みて失敗したホストを除外します。scheduler_max_attempts の値がゼロを超える場合に有効です (デフォルトでは、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

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

セルとホストはいずれも、スケジューリング用に重み付けすることができます。(フィルタリング後に) 重みが最大のホストまたはセルが選択されます。重み付け関数にはすべて、ノードの重みを正規化した後に適用される乗数が指定されます。ノードの重みは以下のように計算されます。

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

重みのオプションは、ホストの /etc/nova/nova.conf ファイルで設定することができます (root または nova ユーザーのパーミッションが必要です)。

3.5.2.1. ホストの重みのオプション設定

スケジューラーが使用するホストの重み付け関数は、[DEFAULT] scheduler_weight_classes のオプションで定義することができます。有効な重み付け関数は以下の通りです。

  • nova.scheduler.weights.ram: ホストの使用可能なメモリーを重み付けします。
  • nova.scheduler.weights.metrics: ホストのメトリックを重み付けします。
  • nova.scheduler.weights.all_weighers: 全ホストの重み付け関数を使用します (デフォルト)。

表3.5 ホストの重みのオプション

重み付け関数オプション説明

all

[DEFAULT] scheduler_host_subset_size

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

metrics

[metrics] required

[metrics] weight_setting 内で使用できないメトリックの処理方法を指定します。

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

metrics

[metrics] weight_of_unavailable

[metrics] weight_setting 内のメトリックが使用できない場合に重みとして使用されます。required=False の場合に有効です。

metrics

[metrics] weight_multiplier

メトリックを重み付けする乗数。デフォルトでは weight_multiplier=1.0 に設定されており、使用可能な全ホストの間でインスタンスを分散します。この値が負の場合には、最も低いメトリックのホストが優先され、インスタンスが複数のホストでスタッキングされます。

metrics

[metrics] weight_setting

重み付けに使用されるメトリックと比率を指定します。metric=ratio のペアのコンマ区切りリストを使用します。有効なメトリック名は以下の通りです。

  • 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

ram

[DEFAULT] ram_weight_multiplier

RAM の乗数 (浮動小数点)。デフォルトでは、ram_weight_multiplier=1.0 に設定されており、使用可能な全ホストの間でインスタンスを分散します。この値が負の場合には、最も RAM が低いホストが優先され、インスタンスが複数のホストでスタッキングされます。

3.5.2.2. セルの重みオプションの設定

[cells] scheduler_weight_classes オプション (/etc/nova/nova.conf ファイル。root または nova ユーザーのパーミッションが必要) でスケジューラーが使用するセルの重み付け関数を定義します。

注記

本リリースでは、セルの使用機能は テクノロジープレビュー として提供されているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。 テクノロジープレビューについての詳しい情報は 「対象範囲の詳細」 を参照してください。

有効な重み付け関数:

  • nova.cells.weights.all_weighers: すべてのセルの重み付け関数を使用します (デフォルト)。
  • nova.cells.weights.mute_child: セルが容量や機能の更新をしばらく送信していなかったかどうかによって重み付けします。
  • nova.cells.weights.ram_by_instance_type: セルの使用可能な RAM を重み付けします。
  • nova.cells.weights.weight_offset: セルの重みのオフセットを評価します。

    注記

    セルの重みのオフセットは、--woffset `in the `nova-manage cell create コマンドを使用して指定します。

表3.6 セルの重みのオプション

重み付け関数オプション説明

mute_child

[cells] mute_weight_multiplier

しばらく更新がなかったホストの乗数 (負の浮動小数点)。デフォルトではこの値は -10.0 です。

mute_child

[cells] mute_weight_value

更新がなかったホストに適用される重みの値 (正の浮動小数点)。デフォルトでは、この値は 1000.0 です。

ram_by_instance_type

[cells] ram_weight_multiplier

RAM の重み付け乗数 (浮動小数点)。デフォルトではこの値は 1.0 に設定されており、使用可能な全セルの間でインスタンスを分散します。この値が負の場合には、最も RAM が低いセルが優先され、インスタンスがセルにスタッキングされます。

weight_offset

[cells] offset_weight_multiplier

セルを重み付けする乗数 (浮動小数点)。重みのオフセットを 999999999999999 に設定することにより (重みが最も高いセルが優先)、インスタンスが優先するセル (浮動小数点) を指定できるようになります。デフォルトではこの値は 1.0 です。

3.6. インスタンスの退避

停止中またはシャットダウンされたコンピュートノードから同じ環境内の新規ホストサーバーにインスタンスを移動するには (例: サーバーをスワップアウトする必要がある場合など)、nova evacuate を使用してそのサーバーを退避することができます。

  • 退避は、インスタンスのディスクが共有ストレージ上にある場合またはインスタンスのディスクが Block Storage ボリュームである場合にのみ有用です。それ以外の場合には、ディスクへのアクセスは不可能なので、新規コンピュートノードからアクセスはできません。
  • インスタンスは、サーバーがシャットダウンされている場合にのみ退避させることができます。サーバーがシャットダウンされなていない場合には、evacuate コマンドは失敗します。
注記

正常に機能するコンピュートノードがある場合には、以下のような操作が可能です。

  • バックアップ目的またはインスタンスを別の環境にコピーするために静的な (実行中でない) インスタンスのコピーを作成: nova image-create を使用してスナップショットを作成します (「静的なインスタンスの移行」の記事を参照)。
  • 静的 (実行中でない) 状態のインスタンスを同じ環境内の別のホストに移動 (共有ストレージが必要): nova migrate を使用して移行します (「静的なインスタンスの移行」の記事を参照)。
  • 稼働状態 (実行中) のインスタンスを同じ環境内の別のホストに移動: nova live-migration コマンドを使用して移行します (「ライブ (実行中の) インスタンスの移行」の記事を参照)。

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

  1. 以下のコマンドを実行して、インスタンスを 1 つ退避します。

    # nova evacuate [--password pass] [--on-shared-storage] instance_name [target_host]

    各オプションについての説明は以下の通りです。

    • --password: 退避するインスタンスに設定する管理パスワード (--on-shared-storage が指定されている場合には使用できません)。パスワードを指定しなかった場合には、無作為に生成され、退避の完了時に出力されます。
    • --on-shared-storage: インスタンスのファイルがすべて共有ストレージ上にあることを指定します。
    • instance_name: 退避するインスタンスの名前
    • target_host: インスタンスの退避先となるホスト。このホストを指定しなかった場合には、Compute のスケジューラーがホストを 1 台選択します。退避先に指定可能なホストを確認するには、以下のコマンドを実行します。

      # nova host-list | grep compute

      以下に例を示します。

      # nova evacuate myDemoInstance Compute2_OnEL7.myDomain

3.6.2. 全インスタンスの退避

  1. 以下のコマンドを実行して、指定したホストに全インスタンスを退避します。

    # nova host-evacuate instance_name [--target target_host] [--on-shared-storage] source_host

    各オプションについての説明は以下の通りです。

    • --target: インスタンスの退避先となるホスト。このホストを指定しなかった場合には、Compute のスケジューラーがホストを 1 台選択します。退避先に指定可能なホストを確認するには、以下のコマンドを実行します。

      # nova host-list | grep compute
    • --on-shared-storage: インスタンスのファイルがすべて共有ストレージ上にあることを指定します。
    • source_host: 退避されるホストの名前

      以下に例を示します。

      # nova host-evacuate --target Compute2_OnEL7.localdomain myDemoHost.localdomain

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

共有ストレージを使用する場合には、以下の手順に従って Compute サービスのインスタンスディレクトリーを 2 つのノードにエクスポートし、ノードがアクセスできることを確認します。ディレクトリーのパスは /etc/nova/nova.conf ファイルの state_path および instances_path のパラメーターで設定されます。この手順では、デフォルト値の /var/lib/nova/instances を使用しています。共有ストレージを設定することができるのは、root アクセスのあるユーザーのみです。

  1. コントローラーホストで以下のステップを実行します。

    1. Compute サービスのユーザーに /var/lib/nova/instances ディレクトリーの読み取り/書き込み権限があることを確認します (このユーザーは、全コントローラー/ノードにおいて同じユーザーである必要があります)。アクセス権はたとえば以下のように表示されます。

      drwxr-xr-x.  9 nova nova 4096 Nov  5 20:37 instances
    2. 以下の行を /etc/exports ファイルに追加します。node1_IP および node2_IP は、2 つのコンピュートノードの IP アドレスに置き換えます。

      /var/lib/nova/instances (rw,sync,fsid=0,no_root_squash)
      /var/lib/nova/instances (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 ファイルに以下の行を追加します。

      :/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

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

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

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

名前

image_type

snapshot

instance_uuid

<スナップショットを作成したインスタンスの uuid>

base_image_ref

<スナップショットを作成したインスタンスのオリジナルイメージの uuid>

image_location

snapshot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

スナップショットは、実際のシステムバックアップの代わりとみなすべきではありません。

第4章 ボリュームの管理

ボリュームとは、OpenStack インスタンスに永続ストレージを提供するブロックストレージデバイスです。

4.1. ボリュームの基本的な使用方法と設定

以下の手順では、基本的なエンドユーザー向けのボリューム管理方法について説明します。これらの手順には管理者の権限は必要ありません。

4.1.1. ボリュームの作成

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. ボリュームの作成 をクリックして、以下のフィールドを編集します。

    フィールド説明

    ボリューム名

    ボリュームの名前

    説明

    ボリュームの簡単な説明 (オプション)

    種別

    オプションのボリューム種別 (「ボリューム種別へのボリューム設定の関連付け」を参照)

    複数の Block Storage バックエンドがある場合には、このフィールドを使用して特定のバックエンドを選択します。詳しくは、「ボリュームを作成するバックエンドの指定」 を参照してください。

    容量 (GB)

    ボリュームの容量 (ギガバイト単位)

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

    アベイラビリティーゾーン (論理サーバーグループ) は、ホストアグリゲートと併せて、OpenStack 内のリソースを分離する一般的な方法です。アベイラビリティーゾーンは、インストール中に定義されます。アベイラビリティーゾーンとホストについてのさらに詳しい説明は、「ホストアグリゲートの管理」を参照してください。

  3. ボリュームソース を指定します。

    ソース説明

    ソースの指定なし (空のボリューム)

    ボリュームは空となり、ファイルシステムやパーティションテーブルは含まれません。

    スナップショット

    既存のスナップショットをボリュームソースとして使用します。このオプションを選択すると、「スナップショットをソースとして使用する」の一覧が新たに表示され、スナップショットを選択できるようになります。ボリュームのスナップショットについての詳しい情報は、「ボリュームスナップショットの作成、クローン、削除」を参照してください。

    イメージ

    既存のイメージをボリュームソースとして使用します。このオプションを選択すると、「イメージをソースとして使用する」の一覧が新たに表示され、イメージを選択できるようになります。

    ボリューム

    既存のボリュームをボリュームソースとして使用します。このオプションを選択すると、「ボリュームをソースとして使用する」の一覧が新たに表示され、ボリュームを選択できるようになります。

  4. ボリュームの作成 をクリックします。ボリュームが作成されると、ボリューム の表に名前が表示されます。

4.1.2. ボリュームを作成するバックエンドの指定

Block Storage サービスが複数のバックエンドを使用するように設定することができます。たとえば、「OpenStack で NFS バックエンドを使用するための設定」では、デフォルトのバックエンドとともに、NFS 共有を使用するように Block Storage サービスを設定する方法について順を追って説明しています。

複数の Block Storage バックエンドが設定された場合には、必ず、バックエンドごとにボリューム種別を作成する必要があります。その種別を使用して、作成したボリュームに、どのバックエンドを使用すべきかを指定することができます。ボリューム種別の詳しい情報は、「ボリューム種別へのボリューム設定の関連付け」を参照してください。

ボリュームの作成時にバックエンドを指定するには「種別」のドロップダウンリストから適切なボリューム種別を選択します (「ボリュームの作成」を参照)。

ボリュームの作成時にバックエンドを指定しない場合には、Block Storage サービスにより自動的に選択されます。デフォルトでは、このサービスは、最も空き容量の多いバックエンドを選択します。また、Block Storage サービスが利用可能な全バックエンドから無作為に選択するように設定することも可能です。詳しくは「ボリュームを複数のバックエンドに割り当てる方法の設定」を参照してください。

4.1.3. ボリュームの名前と説明の編集

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの ボリュームの編集 ボタンをクリックします。
  3. 必要に応じて、ボリュームの名前または説明を編集します。
  4. ボリュームの編集 をクリックして、変更を保存します。
注記

暗号化ボリュームを作成するには、まず最初にボリュームの暗号化専用に設定されたボリューム種別を使用する必要があります。また、Compute サービスと Block Storage サービスの両方で、同じ静的キーを使用するように設定しておく必要があります。ボリュームの暗号化に必要な設定の方法についての説明は、「静的キーを使用したボリュームの暗号化」を参照してください。

4.1.4. ボリュームの削除

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

スナップショットが存在する場合には、ボリュームは削除できません。スナップショットの削除手順については、「ボリュームスナップショットの作成、クローン、削除」を参照してください。

4.1.5. インスタンスへのボリュームの接続と切断

インスタンスは、ボリュームを永続ストレージに使用することができます。1 つのボリュームは、一度に 1 つのインスタンスにしか接続できません。インスタンスに関する詳しい情報は、「インスタンスの管理」を参照してください。

4.1.5.1. インスタンスへのボリュームの接続

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの 接続の編集 アクションを選択します。ボリュームがインスタンスに接続されていない場合には、「インスタンスへの接続」のドロップダウンリストが表示されます。
  3. インスタンスへの接続 の一覧から、ボリュームの接続先となるインスタンスを選択します。
  4. ボリュームの接続 をクリックします。

4.1.5.2. インスタンスからのボリュームの切断

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの 接続の管理 アクションを選択します。ボリュームがインスタンスに接続されている場合には、そのインスタンスの名前が 接続状況 の表に表示されます。
  3. このダイアログ画面と次の画面で ボリュームの切断 をクリックします。

4.1.6. ボリュームの読み取り専用設定

1 つのボリュームでコンテンツを編集できないようにして、複数のユーザーに共有アクセスを許可することができます。そのためには、以下のコマンドを実行して、ボリュームを read-only に設定します。

# cinder readonly-mode-update VOLUME true

VOLUME は、ターゲットボリュームの ID に置き換えます。

読み取り専用ボリュームを読み取り/書き込み可能に戻すには、以下のコマンドを実行します。

# cinder readonly-mode-update VOLUME true

4.1.7. ボリュームの所有者の変更

ボリュームの所有者を変更するには、ボリュームの譲渡を行います。ボリュームの譲渡は、ボリュームの所有者が開始し、ボリュームの新しい所有者が譲渡を承認すると、そのボリュームの所有権の変更が完了します。

4.1.7.1. コマンドラインを使用したボリュームの譲渡

  1. コマンドラインから、ボリュームの現在の所有者としてログインします。
  2. 利用可能なボリュームを一覧表示します。

    # cinder list
  3. 以下のコマンドを実行して、ボリュームの譲渡を開始します。

    # cinder transfer-create VOLUME

    VOLUME は譲渡するボリュームの名前または ID に置き換えます。

      +------------+--------------------------------------+
      |  Property  |                Value                 |
      +------------+--------------------------------------+
      |  auth_key  |           f03bf51ce7ead189           |
      | created_at |      2014-12-08T03:46:31.884066      |
      |     id     | 3f5dc551-c675-4205-a13a-d30f88527490 |
      |    name    |                 None                 |
      | volume_id  | bcf7d015-4843-464c-880d-7376851ca728 |
      +------------+--------------------------------------+

    cinder transfer-create コマンドはボリュームの所有権を消去し、譲渡用の idauth_key を作成します。この値は別のユーザーに渡すことができます。受け取ったユーザーは、その値を使用して譲渡を承認し、ボリュームの新しい所有者となります。

  4. 新規ユーザーがボリュームの所有権を宣言できる状態となりました。所有権を宣言するには、ユーザーはまず最初にコマンドラインからログインして以下のコマンドを実行する必要があります。

    # cinder transfer-accept TRANSFERID TRANSFERKEY

    TRANSFERIDTRANSFERKEY はそれぞれ、cinder transfer-create で返された idauth_key の値に置き換えます。以下に例を示します。

    # cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
注記

利用可能なボリュームの譲渡をすべて表示するには、以下のコマンドを実行します。

# cinder transfer-list

4.1.7.2. ダッシュボードを使用したボリュームの譲渡

Dashboard を使用したボリューム譲渡の作成

  1. Dashboard にボリュームの所有者としてログインして プロジェクト > ボリューム を選択します。
  2. 譲渡するボリュームの アクション のコラムで、 譲渡の作成 を選択します。
  3. ボリュームの譲渡の作成 ダイアログボックスで、譲渡名を入力して ボリュームの譲渡の作成 をクリックします。

    ボリュームの譲渡が作成され、ボリュームの譲渡 の画面で 譲渡 ID認証キー を取得して譲渡先のプロジェクトに送信することができます。

    注記

    認証キーは ボリュームの譲渡 の画面にしか表示されません。この認証キーをなくした場合には、譲渡をキャンセルし、別の譲渡を作成して新たな認証キーを生成する必要があります。

  4. ボリュームの譲渡 の画面を閉じて、ボリュームの一覧に戻ります。

    譲渡先のプロジェクトが譲渡を受理するまで、ボリュームのステータスは awaiting-transfer と表示されます。

Dashboard を使用したボリューム譲渡の受理

  1. Dashboard にボリュームの譲渡先としてログインして プロジェクト > ボリューム を選択します。
  2. 譲渡の受理 をクリックします。
  3. ボリュームの譲渡の受理 のダイアログボックスで、ボリュームの所有者から受け取った 譲渡 ID認証キー を入力して、ボリュームの譲渡の受理 をクリックします。

    譲渡先のプロジェクトのボリューム一覧に、そのボリュームが表示されるようになります。

4.1.8. ボリュームスナップショットの作成、クローン、削除

ボリュームのスナップショットを作成することによって、ある特定の時点のボリュームの状態を保持することができます。そのスナップショットを使用して、新規ボリュームをクローン作成することが可能です。

警告

インスタンスに接続されているボリュームのスナップショットを作成すると、スナップショットが破損する場合があります。インスタンスからボリュームを切断する方法については、「インスタンスからのボリュームの切断」を参照してください。

注記

ボリュームのバックアップはスナップショットとは異なります。バックアップはボリューム内のデータを保持するのに対して、スナップショットはある特定の時点におけるボリュームの状態を保持します。また、スナップショットが存在している場合にはボリュームを削除することはできません。ボリュームのバックアップはデータ損失を防ぐ目的で使用されるのに対してスナップショットはクローン作成を円滑に行う目的で使用されます。

このため、スナップショットのバックエンドは、クローン作成中のレイテンシーを最小限に抑えるように、通常ボリュームのバックエンドと同じ場所に配置されます。一方、バックアップのリポジトリーは通常、一般的なエンタープライズデプロイメント内の別の場所に配置されます (例: 異なるノード、物理ストレージ、あるいは別の地理的ロケーションの場合もあり)。これは、ボリュームのバックエンドが何らかのダメージを受けないように保護することを目的とします。

ボリュームのバックアップについての詳しい情報は、「ボリュームのバックアップと復元」を参照してください。

ボリュームスナップショットの作成手順

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの スナップショットの作成 アクションを選択します。
  3. 作成するスナップショッットの スナップショット名 を指定して ボリュームのスナップショットの作成 をクリックします。ボリュームのスナップショット タブに全スナップショットが表示されます。

ボリュームのスナップショット の表にスナップショットが表示されたら、そのスナップショットから新規ボリュームをクローン作成することができます。この操作を行うには、対象のボリュームの ボリュームの作成 アクションを選択します。ボリュームの作成に関する詳しい説明は、「ボリュームの作成」を参照してください。

スナップショットを削除するには、ボリュームスナップショットの削除 アクションを選択します。

OpenStack デプロイメントで Red Hat Ceph バックエンドを使用している場合には、「Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除」でスナップショットのセキュリティーとトラブルシューティングについての詳しい情報を参照してください。

4.1.8.1. Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除

Red Hat Ceph を OpenStack デプロイメントのバックエンドとして使用する場合には、そのバックエンドでスナップショットの 保護 を設定することができます。OpenStack で (Dashboard または cinder snapshot-delete コマンドを使用して) 保護されているスナップショットの削除を試みると、操作は失敗します。

このようなエラーが発生した場合には、最初に Red Hat Ceph バックエンドでスナップショットを 保護解除 に設定すると、OpenStack で通常通りに削除することができるようになるはずです。

関連する手順については、「Protecting a Snapshot」および「Unprotecting a Snapshot」を参照してください。

4.1.9. Image サービスにボリュームをアップロードする手順

イメージとして既存のボリュームを Image サービスに直接アップロードすることができます。これには、以下の手順を実行してください。

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの イメージにアップロード アクションを選択します。
  3. ボリュームの イメージ名 を指定して、一覧から ディスク形式 を選択します。
  4. アップロード をクリックします。QEMU ディスクイメージのユーティリティーにより、指定した名前を使用して、選択した形式で新規イメージがアップロードされます。

アップロードしたイメージを表示するには、プロジェクト > コンピュート > イメージ を選択します。新しいイメージが イメージ の表に表示されます。イメージの使用方法や設定方法に関する情報は、「イメージの管理」を参照してください。

4.2. ボリュームの高度な設定

以下の手順では、ボリュームの高度な管理方法について説明します。これらの手順には管理者の権限が必要です。

4.2.1. ボリュームのバックアップと復元

ボリュームのバックアップは、ボリュームのコンテンツの永続的なコピーです。ボリュームのバックアップは通常オブジェクトストアとして作成されるため、デフォルトでは、Object Storage サービスで管理されますが、バックアップに異なるリポジトリーを設定することができます。OpenStack は、バックアップ用のバックエンドのオプションとして Ceph、GlusterFS、NFS をサポートしています。

ボリュームのバックアップの作成時には、バックアップのメタデータはすべて Block Storage サービスのデータベースに保管されます。cinder ユーティリティーはこのメタデータを使用して、バックアップからボリュームを復元します。このため、データベースの致命的なデータ損失から回復する際には、バックアップからボリュームを復元する前に Block Storage サービスのデータベースを復元する必要があります。これは、元のボリュームのバックアップのメタデータがすべて完全な状態で Block Storage サービスのデータベースが復元されることも前提としています。

データベースの致命的なデータ損失が発生した際にボリュームのバックアップのサブセットのみを保護するように設定する場合は、バックアップのメタデータをエクスポートすることも可能です。メタデータをエクスポートすると、エクスポートしたデータを後で Block Storage のデータベースに再度インポートしてボリュームのバックアップを通常のように復元することができます。

注記

ボリュームのバックアップはスナップショットとは異なります。バックアップはボリューム内のデータを保持するのに対して、スナップショットはある特定の時点におけるボリュームの状態を保持します。また、スナップショットが存在している場合にはボリュームを削除することはできません。ボリュームのバックアップはデータ損失を防ぐ目的で使用されるのに対してスナップショットはクローン作成を円滑に行う目的で使用されます。

このため、スナップショットのバックエンドは、クローン作成中のレイテンシーを最小限に抑えるように、通常ボリュームのバックエンドと同じ場所に配置されます。一方、バックアップのリポジトリーは通常、一般的なエンタープライズデプロイメント内の別の場所に配置されます (例: 異なるノード、物理ストレージ、あるいは別の地理的ロケーションの場合もあり)。これは、ボリュームのバックエンドが何らかのダメージを受けないように保護することを目的とします。

ボリュームのスナップショットに関する詳しい情報は、「ボリュームスナップショットの作成、クローン、削除」を参照してください。

4.2.1.1. ボリュームの完全バックアップの作成

ボリュームをバックアップするには、cinder backup-create コマンドを使用します。デフォルトでは、このコマンドは、ボリュームの完全バックアップを作成します。ボリュームに既存のバックアップがある場合には、完全バックアップの代わりに、増分 バックアップの作成を選択することができます (詳しくは 「ボリュームの増分バックアップの作成」 を参照)。

ボリュームのバックアップを作成できるのは、そのボリュームにアクセス可能なユーザーなので、管理権限があるユーザーは、ボリュームを誰が所有しているかにかかわらず、任意のボリュームのバックアップを作成できることになります。 詳しい説明は、「admin としてのボリュームのバックアップ作成」を参照してください。

  1. バックアップするボリュームの ID または 表示名 を確認します。

    # cinder list
  2. 以下のコマンドを実行して、ボリュームをバックアップします。

    # cinder backup-create VOLUME

    VOLUME の箇所は、バックアップするボリュームの ID または 表示名 に置き換えます。以下に例を示します。

      +-----------+--------------------------------------+
      |  Property |                Value                 |
      +-----------+--------------------------------------+
      |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
      |    name   |                 None                 |
      | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
      +-----------+--------------------------------------+
    注記

    作成されるバックアップの volume_id は、ソースボリューム の ID と全く同じになります。

  3. 以下のコマンドを実行して、ボリュームのバックアップ作成が完了したことを確認します。

    # cinder backup-list

    バックアップエントリーの ステータスavailable に変わったら、ボリュームのバックアップ作成は完了です。

この時点で、ボリュームのバックアップのメタデータをエクスポートして保管することもできます。これにより、Block Storage データベースで致命的なデータ損失が発生した場合でも、ボリュームのバックアップを復元することができます。以下のコマンドを実行します。

# cinder --os-volume-api-version 2 backup-export BACKUPID

BACKUPID はボリュームのバックアップの ID または名前に置き換えます。

+----------------+------------------------------------------+
|    Property    |                Value                     |
+----------------+------------------------------------------+
| backup_service |     cinder.backup.drivers.swift          |
|   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
|                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
+----------------+------------------------------------------+

ボリュームのバックアップのメタデータは backup_servicebackup_url の値で構成されます。

4.2.1.1.1. admin としてのボリュームのバックアップ作成

管理者権限のあるユーザー (例: デフォルトの admin アカウントなど) は、OpenStack で管理されている任意のボリュームをバックアップすることができます。admin ユーザーが、admin 以外のユーザーの所有するボリュームをバックアップする場合には、そのボリュームの所有者からはバックアップはデフォルトでは表示されないように設定されます。

また、admin ユーザーとしてバックアップしたボリュームを、特定のテナントが利用できるようにすることも可能です。そのためには、以下のコマンドを実行します。

# cinder --os-auth-url KEYSTONEURL --os-tenant-name TENANTNAME --os-username USERNAME --os-password PASSWD backup-create VOLUME

各オプションについての説明は以下の通りです。

  • TENANTNAME は、バックアップを利用できるテナントの名前に置き換えます。
  • USERNAMEPASSWD は、TENANTNAME 内のユーザーのユーザー名とパスワードに置き換えます。
  • VOLUME は、バックアップするボリュームの名前または ID に置き換えます。
  • KEYSTONEURL は、Identity サービスの URL エンドポイントに置き換えます (通常は http://IP:5000/v2 の形式。IP は Identity サービスホストの IP アドレス)。

この操作を実行する場合は、作成されるバックアップの容量は、admin テナントではなく、TENANTNAME のクォータに対して加算されます。

4.2.1.2. ボリュームの増分バックアップの作成

デフォルトでは、cinder backup-create コマンドを実行すると、ボリュームの完全バックアップが作成されますが、ボリュームに既存のバックアップがある場合には、増分 バックアップを作成することが可能です。

増分バックアップは、前回のバックアップ (完全または増分バックアップ) 以降に加えられた変更をキャプチャーします。ボリュームの完全バックアップを何度も定期的に行うと、時間の経過とともにボリュームの容量が拡大されて、リソースを集中的に使用することになります。この点に関しては、増分バックアップの場合には、一定期間の変更のみをキャプチャーして、リソースの使用を最小限に抑えることができます。

増分バックアップを作成するには、--incremental オプションを使用します。

# cinder backup-create VOLUME --incremental

VOLUME の箇所は、バックアップするボリュームの ID または 表示名 に置き換えます。

注記

増分バックアップを作成した後に場合には、ベースとなっている完全バックアップを削除することはできません。また、完全バックアップに複数の増分バックアップがある場合、削除できるのは、最新の増分バックアップのみとなります。

増分バックアップは、NFS および Object Storage のバックアップリポジトリーで完全にサポートされています。 Ceph のバックアップリポジトリーでも増分バックアップはサポートされていますが、ボリュームも Ceph バックエンド上で保管されている場合のみとなります。

4.2.1.3. Block Storage データベースでデータ損失が発生した後の復元

通常、Block Storage のデータベースのデータ損失が発生すると、ボリュームのバックアップを復元できなくなります。これは、Block Storage データベースにボリュームのバックアップサービス (openstack-cinder-backup) で必要とされるメタデータが含まれているためです。このメタデータは backup_servicebackup_url の値で構成され、ボリュームのバックアップ作成後に (「ボリュームの完全バックアップの作成」に記載した手順に従って) エクスポートすることができます。

メタデータをエクスポートして保管した場合には、新しい Block Storage データベースにインポートすることができます (これにより、ボリュームのバックアップを復元することができます)。

  1. 管理者権限を持つユーザーとして以下のコマンドを実行します。

    # cinder --os-volume-api-version 2 backup-import backup_service backup_url

    backup_service および backup_url は、エクスポートしたメタデータに置き換えます。たとえば、「ボリュームの完全バックアップの作成」でエクスポートしたメタデータを使用します。

    # cinder --os-volume-api-version 2 backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
    +----------+--------------------------------------+
    | Property |                Value                 |
    +----------+--------------------------------------+
    |    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
    |   name   |                 None                 |
    +----------+--------------------------------------+
  2. メタデータが Block Storage サービスのデータベースにインポートされたら、通常のようにボリュームを復元することができます (「バックアップからのボリュームの復元」を参照)。

4.2.1.4. バックアップからのボリュームの復元

  1. 使用するボリュームバックエンドの ID を確認します。

    # cinder backup-list

    Volume ID は、復元するボリュームの ID と一致する必要があります。

  2. ボリュームのバックアップを復元します。

    # cinder backup-restore BACKUP_ID

    BACKUP_ID は使用するボリュームのバックアップ ID に置き換えます。

  3. バックアップが必要なくなった場合には、削除します。

    # cinder backup-delete BACKUP_ID

4.2.1.5. テナントのバックアップクォータの表示と変更

大半のテナントストレージクォータ (ボリューム、ボリュームのストレージ、スナップショットの数) とは異なり、バックアップクォータは現在のところ、Dashboard では編集できません。

バックアップクォータは、コマンドラインインターフェース (cinder quota-update コマンド) でのみ編集することができます。

特定のテナント(TENANTNAME) のストレージクォータを確認するには、以下のコマンドを実行します。

# cinder quota-show TENANTNAME

特定のテナントで作成可能なバックアップの最大数 (MAXNUM) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backups MAXNUM TENANTNAME

特定のテナント内の全バックアップの最大合計容量 (MAXGB) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backup-gigabytes MAXGB TENANTNAME

特定のテナントのストレージクォータの使用状況を確認するには、以下のコマンドを実行します。

# cinder quota-usage TENANTNAME

4.2.1.6. Dashboard を使用したボリュームバックアップ管理の有効化

Dashboard を使用してボリュームの作成、表示、削除、復元ができるようになりました。これらの操作を実行するには、プロジェクト > コンピュート > ボリューム > ボリュームバックアップ タブを開いてください。

ただし、ボリュームバックアップ タブは、デフォルトでは有効化されません。有効にするには、Dashboard を適切に設定する必要があります。

  1. /etc/openstack-dashboard/local_settings を開きます。
  2. 以下の設定を検索します。

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': False,
    }

    この設定を以下のように変更します。

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': True,
    }
  3. httpd サービスを再実行して、Dashboard を再起動します。

    # systemctl restart httpd.service

4.2.1.7. バックアップリポジトリーとしての NFS 共有の設定

デフォルトでは、Block Storage サービスは Object Storage サービスをバックアップリポジトリーとして使用しますが、 Block Storage サービスが Object Storage サービスの代わりに既存の NFS 共有をバックアップリポジトリーとして使用するように設定することが可能です。この設定は、以下の手順に従って行います。

  1. バックアップサービス (openstack-cinder-backup) をホストしているノードに、管理権限のあるユーザーとしてログインします。
  2. Block Storage サービスが NFS バックアップドライバー (cinder.backup.drivers.nfs) を使用するように設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_driver cinder.backup.drivers.nfs
  3. バックアップリポジトリーとして使用する NFS 共有の詳細を設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_share NFSHOST:PATH

    各オプションについての説明は以下の通りです。

    • NFSHOST は、NFS サーバーの IP アドレスまたはホスト名に置き換えます。
    • PATH は、NFSHOST 上の NFS 共有の絶対パスに置き換えます。
  4. NFS 共有のマウントオプション設定を指定するには、以下のコマンドを実行します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_mount_options NFSMOUNTOPTS

    NFSMOUNTOPTS には、NFS マウントオプションのコンマ区切りの一覧を指定します (例: rw,sync)。サポートされているマウントオプションについての詳しい情報は、nfs および mountman ページを参照してください。

  5. Block Storage バックアップサービスを再起動して、変更を適用します。

    # systemctl restart openstack-cinder-backup.service
4.2.1.7.1. 異なるバックアップファイルサイズの設定

バックアップサービスのバックアップするファイルのサイズは、最大 バックアップファイルサイズ を上限としています。ボリュームのバックアップがこの値を超える場合には、作成されるバックアップは複数のチャンクに分割されます。デフォルトのバックアップファイルサイズは 1.8 GB です。

異なるバックアップファイルサイズを設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_file_size SIZE

SIZE は指定するファイルサイズ (バイト単位) に置き換えます。Block Storage バックアップサービスを再起動して、変更を適用します。

# systemctl restart openstack-cinder-backup.service

4.2.2. ボリュームの移行

ボリュームの移行ができるのは管理者のみです。使用中のボリュームやスナップショットのあるボリュームは移行できません。

  1. 管理ユーザーとして、利用可能なボリュームをすべて一覧表示します。

    # cinder list
  2. 使用可能なバックエンド (ホスト) とそれぞれのアベイラビリティーゾーンを一覧表示します。

    # cinder-manage host list
  3. 移行を開始します。

    # cinder migrate VOLUME BACKEND

    各オプションについての説明は以下の通りです。

    • VOLUME は移行するボリュームの ID に置き換えます。
    • BACKEND はボリュームの移行先となるバックエンドに置き換えます。
  4. 以下のコマンドで、移行するボリュームの現在のステータスを確認します。

    # cinder show VOLUME

    例:

    # cinder show 45a85c3c-3715-484d-ab5d-745da0e0bd5a
    +---------------------------------------+------------------+
    |                Property               |      Value       |
    +---------------------------------------+------------------+
    |                  ...                  |       ...        |
    |         os-vol-host-attr:host         |      server1     |
    |     os-vol-mig-status-attr:migstat    |       None       |
    |                  ...                  |       ...        |
    +---------------------------------------+------------------+

移行中に、以下の属性を書き留めておきます。

os-vol-host-attr:host
ボリュームの現在のバックエンド。移行が完了したら、移行先のバックエンド (BACKEND) が表示されるはずです。
os-vol-mig-status-attr:migstat
移行のステータス。ステータスが None の場合には移行は進行中でなくなったことを意味します。

4.2.3. ボリューム種別へのボリューム設定の関連付け

OpenStack では、ボリューム種別を作成することができます。これにより、ボリュームの作成時に関連付けられた設定を適用することができるようになります (「ボリュームの作成」)。たとえば、以下のような関連付けが可能です。

設定は、「追加スペック」と呼ばれるキーと値のペアを使用してボリューム種別に関連付けられます。ボリュームの作成時にボリューム種別を指定する際には、Block Storage のスケジューラーがこれらのキーと値のペアを設定として適用します。また、複数のキーと値のペアを同じボリューム種別に関連付けることができます。

ボリューム種別は、異なるユーザーにストレージ階層を使用できるようにする機能をします。 特定のパフォーマンス、耐障害性、およびその他の設定をキーと値のペアとしてボリューム種別に関連付けることにより、階層固有の設定を異なるボリューム種別にマップすることができます。マップされた階層固有の設定は、ボリュームの作成時に対応するボリューム種別を指定することによって適用が可能です。

注記

利用可能な追加スペックやサポートされている追加スペックは、ボリュームのドライバーにより異なります。有効な追加スペックの一覧については、ボリュームドライバーのマニュアルを参照してください。

4.2.3.1. ボリューム種別の作成と設定

  1. Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. ボリューム種別の作成 をクリックします。
  3. 名前 フィールドにボリューム種別の名前を入力します。
  4. ボリューム種別の作成 をクリックします。ボリューム種別 の表に新しい種別が表示されます。
  5. ボリューム種別の 追加スペックの表示 のアクションを選択します。
  6. 作成 をクリックして キー を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時にそのボリューム種別を指定するとエラーが発生してしまいます。
  7. 作成 をクリックします。関連付けられた設定 (キー/値のペア) が 追加スペック の表に表示されます。

デフォルトでは、すべてのボリューム種別が OpenStack の全テナントにアクセス可能です。アクセスが制限されたボリューム種別を作成する必要がある場合は、CLI から作成する必要があります。手順については「プライベートのボリューム種別の作成と設定」を参照してください。

注記

QoS スペックをボリューム種別に関連付けることも可能です。詳しい説明は、「QoS スペックとボリューム種別の関連付け」を参照してください。

4.2.3.2. ボリューム種別の編集

  1. Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. ボリューム種別 の表で、ボリューム種別の 追加スペックの表示 のアクションを選択します。
  3. このページの 追加スペック 表では、以下のような操作を行うことができます。

    • ボリューム種別への新規設定の追加。これには、作成 をクリックして、ボリューム種別に対して、関連付ける新規設定のキー/値ペアを指定します。
    • ボリューム種別に関連付けられている既存の設定の編集。これには、設定の 編集 アクションを選択します。
    • ボリューム種別に関連付けられている既存の設定の削除。これには、追加スペックのチェックボックスを選択して、このダイアログ画面と次の画面で 追加スペックの削除 をクリックします。

4.2.3.3. ボリューム種別の削除

ボリューム種別を削除するには、ボリューム種別 の表でそのボリューム種別のチェックボックスを選択して ボリューム種別の削除 をクリックします。

4.2.3.4. プライベートのボリューム種別の作成と設定

デフォルトでは、すべてのボリューム種別が全テナントに対して表示されます。ボリューム種別の作成中に、プライベート に指定すると、この設定をオーバーライドすることができます。そのためには、その種別の Is_Public フラグを False に設定する必要があります。

プライベートのボリューム種別は、特定のボリューム設定に対するアクセスを制限するのに役立ちます。これは通常は、特定のテナントのみが使用可能とする必要のある設定です。たとえば、テスト中の新規バックエンドや超ハイパフォーマンスの設定などが例としてあげられます。

プライベートのボリューム種別を作成するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-create --is-public false _VTYPE_

+ VTYPE は、プライベートのボリューム種別の名前に置き換えます。

デフォルトでは、プライベートのボリューム種別は、作成者のみがアクセス可能ですが、admin ユーザーは、以下のコマンドを使用するとプライベートのボリューム種別を特定/表示することができます。

# cinder --os-volume-api-version 2 type-list --all

このコマンドは、パブリックとプライベートの両方のボリューム種別を一覧表示します。 一覧には、各ボリューム種別の名前と ID も表示されます。ボリューム種別にアクセスするには、そのボリューム種別の ID が必要となります。

プライベートのボリューム種別へのアクセスは、テナントレベルで許可されます。テナントがプライベートのボリューム種別にアクセスできるようにするには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-add --volume-type _VTYPEID_ --project-id _TENANTID_

各オプションについての説明は以下の通りです。

  • VTYPEID は、プライベートのボリューム種別の ID に置き換えます。
  • TENANTID は、VTYPEID へのアクセスを許可するプロジェクト/テナントの ID に置き換えます。

プライベートのボリューム種別にアクセス可能なテナントを確認するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-list --volume-type _VTYPE_

プライベートのボリューム種別のアクセスリストからテナントを削除するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-remove --volume-type _VTYPE_ --project-id _TENANTID_
注記

プライベートのボリューム種別へのアクセスは、デフォルトでは管理権限のあるユーザーのみが作成、表示、設定することが可能です。

4.2.4. QoS スペックの使用

複数のパフォーマンス設定を単一の Quality-of-Service の仕様 (QoS スペック) にマップすることができます。これにより、ユーザータイプ別のパフォーマンス階層を提供することができます。

パフォーマンス設定はキーと値のペアとして QoS スペックにマップされます。これは、ボリュームの設定がボリューム種別に関連付けられる方法と似ていますが、QoS スペックの場合は以下の面でボリューム種別の場合とは異なります。

  • QoS スペックは、ディスクの読み取り/書き込み操作を制限するなどのパフォーマンス設定を適用するのに使用されます。利用可能かつサポートされているパフォーマンス設定はストレージドライバーによって異なります。

    バックエンドがサポートしている QoS スペックを確認するには、そのバックエンドデバイスのボリュームドライバーのマニュアルを参照してください。

  • ボリューム種別はボリュームに直接適用されるのに対して QoS スペックは直接適用されるのではなく、ボリューム種別に関連付けられます。また、ボリュームの作成時にボリューム種別を指定すると、そのボリューム種別に関連付けられた QoS スペックにマップされたパフォーマンス設定も適用されます。

4.2.4.1. QoS スペックの作成と設定

管理者は、「QoS スペック」の表で QoS スペックの作成および設定を行うことができます。同じ QoS スペックには、複数のキー/値のペアを関連付けることができます。

  1. Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. QoS スペック の表で QoS スペックの作成 をクリックします。
  3. QoS スペック の名前を入力します。
  4. 使用者 フィールドで、QoS ポリシーを適用する先を指定します。

    表4.1 使用者のタイプ

    種別説明

    バックエンド

    QoS ポリシーが Block Storage バックエンドに適用されます。

    フロンドエンド

    QoS ポリシーが Compute に適用されます。

    両方

    QoS ポリシーが Block Storage と Compute の両方に適用されます。

  5. 作成 をクリックします。新規 QoS スペックが QoS スペック の表に表示されるはずです。
  6. QoS スペック の表で、新規スペックの スペックの管理 アクションを選択します。
  7. 作成 をクリックして キー を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時に、この QoS スペックに関連付けられたボリューム種別を指定するとエラーが発生してしまいます。
  8. 作成 をクリックします。関連付けられた設定 (キー/値のペア) が キーと値のペア の表に表示されます。

4.2.4.2. QoS スペックとボリューム種別の関連付け

管理者は、ボリューム種別 の表で QoS スペックを既存のボリューム種別に関連付ける事ができます。

  1. Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
  3. 関連付ける QoS スペック のリストから QoS スペックを選択します。
  4. 割り当て をクリックします。選択した QoS スペックが、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されるようになります。

4.2.4.3. ボリューム種別からの QoS スペックの関連付け解除

  1. Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
  3. 「関連付ける QoS スペック」のリストから なし を選択します。
  4. 割り当て をクリックします。選択した QoS スペックは、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されなくなります。

4.2.5. 静的キーを使用したボリュームの暗号化

ボリュームの暗号化は、ボリュームのバックエンドのセキュリティーを侵害されたり、完全に盗難されたりした場合に、基本的なデータ保護を提供します。暗号化ボリュームの内容は、特定のキーを使用しなければ読み取ることはできません。インスタンスが暗号化ボリュームを使用するためには、Compute サービスと Block Storage サービスの両方で同じキーを使用するように設定する必要があります。本項では、単一のキーを使用してボリュームを暗号化するように OpenStack デプロイメントを設定する方法について説明します。

重要

現在、ボリュームの暗号化はブロックデバイスでバッキングされているボリュームでのみサポートされます。ネットワークが接続されたボリュームの暗号化 (RBD) またはファイルベースのボリューム (NFS など) はまだサポートされていません。

4.2.5.1. 静的キーの設定

基本的なボリュームの暗号化を実装する第 1 のステップは、静的キーの設定です。このキーは 16 進数の文字列にする必要があります。これは Block Storage ボリュームサービス (openstack-cinder-volume) と全 Compute サービス (openstack-nova-compute) によって使用されます。両サービスがこのキーを使用するように設定するには、両サービスのそれぞれの設定ファイルの [keymgr] セクションで fixed_key 値としてキーを設定します。

  1. コマンドラインから、openstack-cinder-volume をホストしているノードに、root としてログインします。
  2. 静的キーを設定します。

    # openstack-config --set /etc/cinder/cinder.conf keymgr fixed_key HEX_KEY

    HEX_KEY は、16 桁の英数字の 16 進数のキー (例: 0000000000000000000000000000000000000000000000000000000000000000) に置き換えます。

  3. Block Storage ボリュームサービスを再起動します。

    # openstack-service restart cinder-volume
  4. 次に、openstack-nova-compute をホストするノードにログインして、同じ静的キーを設定します。

    # openstack-config --set /etc/nova/nova.conf keymgr fixed_key HEX_KEY
    注記

    複数のコンピュートノード (openstack-nova-compute をホストする複数のノード) を使用している場合には、同じ静的キーを各ノードの /etc/nova/nova.conf に設定する必要があります。

  5. Compute サービスを再起動します。

    # openstack-service restart nova-compute
    注記

    同様に、複数のコンピュートノードに静的キーを設定した場合には、各ノードで openstack-nova-compute サービスを再起動する必要があります。

この時点で、Compute サービスと Block Storage サービスの両方で同じ静的キーを使用してボリュームの暗号化/暗号化解除できるようになりました。つまり、新規インスタンスは静的キー (HEX_KEY) で暗号化したボリュームを使用できます。

4.2.5.2. ボリューム種別の暗号化設定

「静的キーの設定」の手順に従って設定した静的キーを使用して暗号化ボリュームを作成するには、暗号化されたボリューム種別 が必要です。ボリューム種別を暗号化設定するには、対象のボリューム種別が使用すべきプロバイダークラス、暗号、キーサイズを指定する必要があります。これには、以下のコマンドを実行します。

# cinder encryption-type-create --cipher aes-xts-plain64 --key_size BITSIZE --control_location front-end VOLTYPE nova.volume.encryptors.luks.LuksEncryptor

各オプションについての説明は以下の通りです。

  • BITSIZE はキーのサイズに置き換えます (例: 512 ビットキーの場合は 512)。
  • VOLTYPE は暗号化するボリューム種別名に置き換えます。

上記のコマンドにより、nova.volume.encryptors.luks.LuksEncryptor プロバイダークラス、aes-xts-plain64 の暗号が設定されます。本リリースでは、ボリュームの暗号化でサポートされている設定はクラス/暗号のみです。

暗号化されたボリューム種別が設定されると、暗号化ボリュームを自動で呼び出すことができます。具体的には、ボリュームの作成 ウィンドウの種別のドロップダウンリストから暗号化されたボリューム種別を選択します (「ボリュームの基本的な使用方法と設定」を参照)。

4.2.6. ボリュームを複数のバックエンドに割り当てる方法の設定

Block Storage サービスが複数のバックエンドを使用するように設定されている場合には、設定済みのボリューム種別を使用して、ボリュームの作成先を指定することができます。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。

ボリュームの作成時にバックエンドを指定していない場合には、Block Storage サービスにより、自動的に選択されます。Block Storage は、最初に定義したバックエンドをデフォルトとして設定します。このバックエンドは、容量がなくなるまで使用されます。容量がなくなった時点で、Block Storage は 2 番目に定義されたバックエンドをデフォルトに設定し、その容量がなくなるとさらに次のバックエンドがデフォルトに設定されるようになっています。

このメカニズムが必要な条件を満たさない場合には、フィルタースケジューラーを使用して、Block Storage がバックエンドを選択する方法を制御することができます。このスケジューラーは、以下の例に示したような異なるフィルターを使用して適切なバックエンドをトリアージすることができます。

AvailabilityZoneFilter
要求されたボリュームのアベイラビリティーゾーン要件を満たさないバックエンドを除外します。
CapacityFilter
ボリュームを収容するのに十分な容量のあるバックエンドのみを選択します。
CapabilitiesFilter
ボリュームで指定した設定に対応可能なバックエンドのみを選択します。

フィルタースケジューラーは、以下の手順で設定します。

  1. FilterScheduler を有効化します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_driver cinder.scheduler.filter_scheduler.FilterScheduler
  2. アクティブにする必要のあるフィルターを設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_filters AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter
  3. スケジューラーが適切なバックエンドを選択する方法を設定します。

    • スケジューラーが、空き容量の最も大きなバックエンドを常に選択するようにするには、以下のコマンドを実行します。

      # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers AllocatedCapacityWeigher
      # openstack-config --set /etc/cinder/cinder.conf DEFAULT allocated_capacity_weight_multiplier -1.0
    • スケジューラーが、すべての適切なバックエンドの中から無作為に選択するようにするには、以下のコマンドを実行します。

      # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers ChanceWeigher
  4. Block Storage スケジューラーを再起動して、設定を適用します。

    # openstack-service restart openstack-cinder-scheduler

第5章 コンテナーの管理

OpenStack Object Storage (swift) は、コンテナー内にオブジェクト (データ) を格納します。コンテナーとは、ファイルシステムにおけるディレクトリーと似ています。ただし、入れ子にはできません。コンテナーは、あらゆるタイプの非構造化データを格納する簡単な方法をユーザーに提供します。たとえば、オブジェクトには写真、テキストファイル、イメージなどが含まれます。格納されるオブジェクトは暗号化や圧縮はされません。

擬似フォルダーは、オブジェクトを格納することができる論理デバイスで、入れ子が可能となっているので、整理がしやすくなります。たとえば、画像を保管する Images フォルダーや、ビデオを保管する Media フォルダーなどを作成することができます。

各プロジェクトに 1 つまたは複数のコンテナーを作成することができます。また、各コンテナーには、1 つまたは複数の擬似フォルダーを作成することができます。

5.1. コンテナーの作成

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. コンテナーの作成 をクリックします。
  3. コンテナー名 を指定して、コンテナーアクセス フィールドで以下のいずれかのオプションを選択します。

    種別説明

    プライベート

    現在のプロジェクトでユーザーに対してアクセスを制限します。

    パブリック

    パブリックの URL を使用して API アクセスを全員に許可します。ただし、Dashboard では、プロジェクトユーザーには、他のプロジェクトのパブリックコンテナーおよびデータは表示されません。

  4. コンテナーの作成 をクリックします。

5.2. コンテナー用の擬似フォルダーの作成

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. 擬似フォルダーを追加するコンテナーの名前をクリックします。
  3. 疑似フォルダーの作成 をクリックします。
  4. 疑似フォルダー名 フィールドに名前を指定し、作成 をクリックします。

5.3. オブジェクトのアップロード

実際のファイルをアップロードしない場合でも、オブジェクトは (プレースホルダーとして) 作成され、後でファイルをアップロードする際に使用することができます。

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. アップロードしたオブジェクトの配置先となるコンテナーの名前をクリックします。そのコンテナーに擬似フォルダーがすでに存在している場合には、擬似フォルダーの名前をクリックすることもできます。
  3. ファイルをブラウズしてオブジェクトのアップロード をクリックします。
  4. オブジェクト名 フィールドに名前を指定します。

    • 擬似フォルダーはスラッシュ (/) の記号を使用して指定することができます (例: Images/myImage.jpg)。指定したフォルダーがまだ存在していない場合には、オブジェクトのアップロード時に作成されます。
    • その場所 (オブジェクトがすでに存在している場所) に一意ではない名前は、そのオブジェクトの以前のコンテンツを上書きします。
  5. オブジェクトのアップロード をクリックします。

5.4. オブジェクトのコピー

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. オブジェクトのコンテナーまたはフォルダーの名前をクリックします (オブジェクトを表示します)。
  3. オブジェクトのアップロード をクリックします。
  4. コピーするファイルを参照し、矢印メニューで コピー を選択します。
  5. 以下の項目を設定します。

    フィールド説明

    宛先コンテナー

    新規プロジェクトの宛先コンテナー

    パス

    宛先コンテナーの擬似フォルダー。フォルダーが存在しない場合は、作成されます。

    宛先オブジェクト名

    新規オブジェクト名。その場所に一意ではない名前を使用した場合 (そのオブジェクトがすでに存在している場合) には、そのオブジェクトの以前のコンテンツが上書きされます。

  6. オブジェクトのコピー をクリックします。

5.5. オブジェクトの削除

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. 一覧を参照して対象のオブジェクトを特定し、矢印メニューで オブジェクトの削除 を選択します。
  3. オブジェクトの削除 をクリックして、オブジェクトを削除する操作を確定します。

5.6. コンテナーの削除

  1. Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
  2. コンテナー のセクションの一覧を参照して全オブジェクトが削除済みであることを確認します (「オブジェクトの削除」を参照)。
  3. 対象のコンテナーの矢印メニューで コンテナーの削除 を選択します。
  4. コンテナーの削除 をクリックして、コンテナーを削除する操作を確定します。

5.7. Object Storage サービスの Erasure Code

Erasure coding (EC) は、データの断片化、拡張、冗長データによる暗号化、別の場所やストレージメディアセットでの保存の際にデータを保護する方法です。EC は、従来のレプリケーションより小さいストレージボリュームを使用して、必要とされる耐久性を取得します。レプリケーションファクターが 3 のものと比較すると、注意深くデプロイメントを行うことで、50% の節約が実現できます。ただし、ワークロードによっては、Erasure Coding がパフォーマンスに悪影響を与える可能性があります。

RHEL OpenStack Platform 7 リリースには、Object Storage サービス向けの Erasure Coding サポートがテクノロジープレビューとして利用できます。テクノロジープレビューとして提供されている機能のサポート範囲についての詳しい情報は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

Erasure Coding は、Object Storage サービス向けにストレージポリシーとしてサポートされます。ストレージポリシーにより複数のオブジェクトリングを作成することでさまざまな目的のクラスターをセグメント化できます。Red Hat は、Erasure Coding およびレプリケーションストレージポリシーで使用するデバイスを分割することを推奨します。これにより、クラスターの動きをより簡単に分析することができます。

選択する方向性は、Erasure Coding ポリシーのデプロイの理由により異なります。主な検討事項は以下のとおりです。

  • 既存のインフラストラクチャーのレイアウト
  • 専用の Erasure Coding ノード (または Erasure Coding デバイス)の追加コスト
  • 目的とする使用モデル

5.7.1. Erasure Coding の設定

Erause Coding ポリシーを使用するには、swift.conf ファイルで Erasure Coding ポリシーを定義して、関連のオブジェクトリングを作成、設定します。Erasure Coding ポリシーの設定方法例は、以下のとおりです。

[storage-policy:2]
name = ec104
policy_type = erasure_coding
ec_type = jerasure_rs_vand
ec_num_data_fragments = 10
ec_num_parity_fragments = 4
ec_object_segment_size = 1048576

以下の表では、ストレージポリシーの用語を説明しています。

name

これは、標準のストレージポリシーのパラメーターです。

policy_type

これは erasure_coding に設定して、Erasure Coding ポリシーであることを指定します。

ec_type

この値は、選択した PyECLib バックエンドの利用可能なオプションに合わせて設定します。これは、使用する Erasure Coding スキームを指定します。たとえば、ここで示すオプションでは、Vandermonde Reed-Solomon の暗号化を選択していますが、flat_xor_hd_3 のオプションは Flat-XOR ベースの HD の組み合わせコードを選択します。完全な詳細は、PyECLib を参照してください。

ec_num_data_fragments

データを構成する断片の合計数

ec_num_parity_fragments

パリティーを構成する断片の合計数

ec_object_segment_size

セグメントをエンコーダー/デコーダーにフィードする前に増やすデータのバッファー量。デフォルト値は 1048576 です。

PyECLib がオブジェクトを暗号化する際には、N 個の断片に分割します。設定時に、断片のうち何個がデータで、何個がパリティーであるかを知っておくことが重要です。上記の例では、PyECLib はオブジェクトを 14 個の断片に分割して、そのうち、実際のオブジェクトデータは 10 個で、パリティーデータは 4 個 (計算は ec_type に左右される) です。このような設定では、システムは、ディスクの障害は 4 回分までであればデータの損失なしで済みます。その他に一般的に使用される設定は 4+2 (データ断片 4 個とパリティー断片 2 個) または 8+3 (データ断片 8 個とパリティー断片 3 個) です。

注記

ポリシーをデプロイして、そのポリシーでオブジェクトを作成した後にはこれらの設定オプションの変更はできない点にご注意ください。設定の変更が望ましい場合には、新規ポリシーを作成して、データを新しいコンテナーに移行します。ただし、定義が済むと、ポリシーのインデックスは破棄できません。ポリシーを終了する場合には、ポリシーを無効にすることはできますが、削除はできません。基本的に、以前のポリシーが残っていてもパフォーマンスへの影響はありませんが、若干、管理の負担が出てきます。

5.7.2. オブジェクトストレージリングの設定

オブジェクトストレージは、リング と呼ばれるデータ構造を使用して、パーティション領域をクラスターに分散します。このパーティション領域は、Object Storage サービスのレプリケーションシステムにとって中核部分となります。これにより、Object Storage サービスが迅速かつ簡単にクラスター内の各パーティションを同期できるようになります。Swift のコンポーネントがデータと対話する必要がある場合には、ローカルでリング内を素早く検索して、各レプリカに使用可能なパーティションが決まります。

Object Storage サービスにはすでに 3 つのリングがあり、各種データが格納されています。リングは、アカウント情報に 1 つ、(アカウント内のオブジェクトを整理するのに役立つ) コンテナーに 1 つ、オブジェクトのレプリカに 1 つあります。Erasure Code をサポートするために、Erasure Code のチャンクを格納するために作成された追加のリングがあります。

たとえば、典型的なレプリケーションリングを作成するには、以下のコマンドを使用します。

swift-ring-builder object-1.builder create 10 3 1

3 は、レプリカの数です。

以下のように、Erasure Coding のオブジェクトリングを作成するには、レプリカの数の部分に断片の数を指定する必要があります。

swift-ring-builder object-1.builder create 10 14 1

14 は、データ断片 10 とパリティー断片 4 (10+4) を合わせた設定です。

Erasure Coding ポリシーのオブジェクトリングで使用するデバイスを決定する際には、パフォーマンスの影響を考慮します。デプロイメントの前の設定に対して、テスト環境でパフォーマンスのベンチマーキングを実行することを推奨します。swift.conf で Erasure Coding のポリシーを設定してオブジェクトリングを作成した後には、指定のポリシー名でコンテナーを作成して通常通りに対話することで、アプリケーションでの Erauser Coding の使用準備が整います。

5.8. Image サービスのバックエンドとしてのオブジェクトストレージの設定

デフォルトでは、OpenStack の Image サービスは、イメージおよびインスタンスのスナップショットを /var/lib/glance/images/ のローカルのファイルシステムに保存します。または、(可能な場合には) Image サービスが Object Storageサービスにイメージとスナップショットを保存するように設定することも可能です。

この設定には、以下の手順を実行します。

  1. root として Image サービスを実行中のノード (Identity も実行するコントローラーノード) にログインし、OpenStack の認証情報 (これは通常 openrc という名前のファイル) の取得元として指定します。

    # source ~/openrc
  2. Image サービスが admin ロールを持つ service テナントの一部であることを確認します。

    # keystone user-role-list --user glance --tenant service

    返されたロールの 1 つは、admin でなければなりません。

  3. /etc/glance/glance.conf ファイルを開き、以下の行をコメントアウトします。

    ##### DEFAULT OPTIONS #####
    #default_store = file
    #filesystem_store_datadir = /var/lib/glance/images/
  4. 同じファイル内で DEFAULT OPTIONS のセクションに以下の行を追加します。

    default_store = swift
    swift_store_auth_address = http://KEYSTONEIP:35357/v2.0/
    swift_store_user = service:glance
    swift_store_key = ADMINPW
    swift_store_create_container_on_put = True

    各オプションについての説明は以下の通りです。

    • KEYSTONEIP は、Identity サービスの IP アドレスに置き換えてください。
    • ADMINPW は、/etc/glance/glance-api.conf ファイルの管理者パスワードの値に置き換えてください。
  5. Image サービスを再起動して変更を適用します。

    # systemctl restart openstack-glance-api
    # systemctl restart openstack-glance-registry

この時点から、(Dashboard または glance 経由) Image サービスにアップロードされたイメージは glance という名前の Object Storage コンテナーに保存されるはずです。このコンテナーは、サービスアカウントに存在します。

新規作成イメージが Image サービスに保存されたことを確認するには、以下を実行します。

# ls /var/lib/glance/images

Dashboard または glance image-list により、イメージがアクティブな状態であることが報告されたら、以下のコマンドを実行してイメージがオブジェクトストレージにあるかどうかを確認できます。

# swift --os-auth-url http://KEYSTONEIP:5000/v2.0 --os-tenant-name service --os-username glance --os-password ADMINPW list glance

第6章 OpenStack で NFS バックエンドを使用するための設定

本章は、OpenStack Volume サービス (openstack-cinder-volume) が既存の NFS サーバーを追加のバックエンドとして使用するように設定する方法について説明します。さらに、NFS 共有をバックエンドとしたボリュームの作成を呼び出すために使用可能なボリューム種別の作成方法についても記載しています。

必須条件:

  • バックエンドとして使用する NFS 共有は、事前に正しく設定しておく必要があります。
  • OpenStack Volume サービスをホストするノードには、NFS 共有への読み取り/書き込み権限が必要です。
  • また、OpenStack Volume サービスをホストするノードへの root アクセスが必要です。

前提条件:

  • OpenStack デプロイメントが Red Hat Enterprise Linux OpenStack Platform インストーラー でプロビジョニングされていないこと
  • OpenStack Block Storage サービスがデフォルトのバックエンドを使用していること (このバックエンドでは Packstack でデプロイされた lvm というバックエンド名を使用)

6.1. SELinux の設定

クライアントで SELinux が有効になっており、クライアントがインスタンス上の NFS ボリュームにアクセスする必要がある場合には、virt_use_nfs のブール値も有効にする必要があります。このブール値を有効にして (再起動後も有効な状態を保つには)、root で以下のコマンドを実行してください。

# setsebool -P virt_use_nfs on

インスタンス上の NFS ボリュームにアクセスする必要がある全クライアントのホストで、このコマンドを実行します。これには、全コンピュートノードも含まれます。

6.2. 共有の設定

まず、NFS のバックエンド追加における最初の手順として、OpenStack Volume サービスが使用する NFS 共有を定義します。これには以下を実行します。

  1. OpenStack Volume サービスをホストするノードへ root でログインします。
  2. /etc/cinder/ ディレクトリーに、nfs_share という名前の新規テキストファイルを作成します。

    /etc/cinder/nfs_share
  3. 以下の形式で、/etc/cinder/nfs_share に NFS 共有を定義します。

    HOST:SHARE

    各オプションについての説明は以下の通りです。

    • 「HOST」は、NFS サーバーの IP アドレスまたはホスト名に置き換えます。
    • 「SHARE」は、HOST にエクスポートされる NFS 共有への絶対パスに置き換えます。
  4. 次に、ユーザー root とグループ cinder を /etc/cinder/nfs_share の所有者に設定します。

    # chown root:cinder /etc/cinder/nfs_share
  5. 最後に、/etc/cinder/nfs_share を設定して、cinder グループのメンバーが読み取ることができるようにします。

    # chmod 0640 /etc/cinder/nfs_share

6.3. 新規バックエンドの定義の作成

デフォルトでは、Packstack により、LVM のバックエンドの定義が /etc/cinder/cinder.conf に作成されます。

[lvm]
iscsi_helper=lioadm
volume_group=cinder-volumes
iscsi_ip_address=
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=lvm

/etc/cinder/cinder.conf で NFS 共有を定義した後には、この共有に対して、追加でバックエンドの定義を設定することができます。この設定には、以下を実行します。

  1. OpenStack Volume サービスをホストするノードへ root でログインします。
  2. NFS バックエンドの新しい定義を作成して、Volume Servive が NFS 共有を定義するファイル (/etc/cinder/nfs_share) を使用するように設定します。

    # openstack-config --set /etc/cinder/cinder.conf nfs nfs_shares_config /etc/cinder/nfs_shares

    ここでは、定義名に nfsbackend という名前を使用します。

  3. Volume サービスが cinder.volume.drivers.nfs.NfsDriver という名前の NFS ボリュームドライバーを使用するように設定します。

    # openstack-config --set /etc/cinder/cinder.conf nfs volume_driver cinder.volume.drivers.nfs.NfsDriver
  4. NFS バックエンドのボリュームのバックエンド名を定義します (以下のコマンドでは、nfs という名前を使用します)。

    # openstack-config --set /etc/cinder/cinder.conf nfs volume_backend_name nfsbackend
  5. 必要なマウントオプションを (MOUNTOPTIONS) nfs_mount_options の設定キーに追加します。

    # openstack-config --set /etc/cinder/cinder.conf nfs nfs_mount_options _MOUNTOPTIONS_

この時点で、以下のセクションが /etc/cinder/cinder.conf に表示されるはずです。

[nfs]
nfs_shares_config = /etc/cinder/nfs_shares
volume_driver = cinder.volume.drivers.nfs.NfsDriver
volume_backend_name = nfsbackend
nfs_mount_options =

NFS バックエンドを有効化できるようになりました。バックエンドは、/etc/cinder/cinder.confenabled_backends 設定キーで有効化します。Packstack で作成されるデフォルトのバックエンドは、そこに表示されているはずです。

enabled_backends=lvm

以下のように、一覧に新規の NFS バックエンド定義を追加します。

enabled_backends=lvm,nfs

NFS バックエンドが有効になったら、OpenStack の Volume サービスを再起動します。

# openstack-service restart cinder-volume

6.4. NFS バックエンドのボリューム種別の作成

新規の NFS バックエンドが利用できるようになりましたが、新規ボリュームの作成時にはまだ使用することができません。新規ボリュームがこの NFS バックエンドを使用するように設定するには、まず、このボリュームに ボリュームの種別 を作成する必要があります。

  1. 既存のボリューム種別を表示します。デフォルトでは、lvm バックエンドに対して、(iscsi という名前の) ボリューム種別が存在します。

      +--------------------------------------+-------+
      |                  ID                  |  Name |
      +--------------------------------------+-------+
      | f8d31dc8-a20e-410c-81bf-6b0a971c61a0 | iscsi |
      +--------------------------------------+-------+
  2. NFS バックエンドに nfstype という名前の新規ボリューム種別を作成します。

    # cinder type-create nfstype
  3. バックエンド名 (nfsbackend) を使用して、NFS バックエンドで nfstype というボリューム種別 が使用されるように設定します。

    # cinder type-key nfstype set volume_backend_name=nfsbackend
  4. 新しい種別が正しく作成、設定されていることを確認します。

    +--------------------------------------+---------+
    |                  ID                  |   Name  |
    +--------------------------------------+---------+
    | bbff44b5-52b1-43d6-beb4-83aa2d20bc59 | nfstype |
    | f8d31dc8-a20e-410c-81bf-6b0a971c61a0 |  iscsi  |
    +--------------------------------------+---------+
    +-----------------------+-------+---------------------------------------+
    |           ID          |  Name |               extra_specs             |
    +-----------------------+-------+---------------------------------------+
    |bbff44b5-~-83aa2d20bc59|nfstype|{u'volume_backend_name': u'nfsbackend'}|
    |f8d31dc8-~-6b0a971c61a0| iscsi |    {u'volume_backend_name': u'lvm'}   |
    +-----------------------+-------+---------------------------------------+
注記

ボリューム種別の作成や設定は、Dashboard からも行うことができます。詳しくは、「ボリューム種別へのボリューム設定の関連付け」を参照してください。

6.5. 新しい NFS バックエンドのテスト

新規 NFS バックエンドをテストするには、nfsvolume という新規ボリュームを作成し、nfstype というボリューム種別を呼び出します。

+---------------------+--------------------------------------+
|       Property      |                Value                 |
+---------------------+--------------------------------------+
|     attachments     |                  []                  |
|  availability_zone  |                 nova                 |
|       bootable      |                false                 |
|      created_at     |      2015-01-06T05:14:09.271114      |
| display_description |                 None                 |
|     display_name    |              nfsvolume               |
|      encrypted      |                False                 |
|          id         | 0cd7ac45-622a-47b0-9503-7025bbedc8ed |
|       metadata      |                  {}                  |
|         size        |                  1                   |
|     snapshot_id     |                 None                 |
|     source_volid    |                 None                 |
|        status       |               creating               |
|     volume_type     |               nfstype                |
+---------------------+--------------------------------------+

ボリュームが正しく作成されたら、(NFS サーバー上の) NFS 共有を確認します。該当するボリューム (名前に新規作成されたボリュームの ID が含まれているボリューム) が以下のように表示されるはずです。

drwxrwxrwx.  2 root      root      4.0K Jan  6 15:14 .
drwxr-xr-x. 18 root      root      4.0K Jan  5 04:03 ..
-rw-rw-rw-.  1 nfsnobody nfsnobody 1.0G Jan  6 15:14+  +volume-0cd7ac45-622a-47b0-9503-7025bbedc8ed

第7章 NUMA ノードを使用する CPU ピニングの設定

本章では、NUMA トポロジーのサポートと、同技術に対応したシステム上における OpenStack 環境の設定について説明します。この構成では、仮想マシンを専用の CPU コアに固定化 (ピニング) することにより、よりスマートなスケジューリングが可能となり、ゲストのパフォーマンスが向上します。

ヒント

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

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

OpenStack NUMA Topology 39825 0416 ADF
注記

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

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

警告

現在、CPU ピニングを使用するように設定されているインスタンスは移行できません。この問題に関する詳しい情報は、「Instance migration fails when using cpu-pinning from a numa-cell and flavor-property "hw:cpu_policy=dedicated"」のソリューションを参照してください。

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

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

表7.1 NUMA トポロジーの例

 

ノード 0

ノード 1

ホストのプロセス

コア 0

コア 1

コア 4

コア 5

ゲストのプロセス

コア 2

コア 3

コア 6

コア 7

注記

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

コンピュートノードの設定は、以下の手順に従って行います。

  1. /etc/nova/nova.conf ファイルの vcpu_pin_set オプションに、ゲストのプロセス用に確保する CPU コアの一覧を設定します。上記の例を使用する場合、設定は以下のようになります。

    vcpu_pin_set=2,3,6,7

    vcpu_pin_set オプションを設定すると、以下のようなcpuset 属性が libvirt の XML 設定ファイルにも追加されます。

    <vcpu placement='static' cpuset='2-3,6-7'>1</vcpu>

    これにより、ゲストの仮想 CPU は一覧に設定されている物理 CPU コアに固定され、スケジューラーにはそれらのコアだけが見えるようになります。

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

    reserved_host_memory_mb=512
  3. 以下のコマンドを実行して、コンピュートノードで Compute サービスを再起動します。

    systemctl restart openstack-nova-compute.service
  4. systemdCPUAffinity 機能を使用して、ゲストプロセス用に確保されている CPU コアでホストプロセスが実行されないようにします。 上記のトポロジーにしたがって、/etc/systemd/system.conf ファイルを編集して、以下の行をコメント解除または追加します。

    CPUAffinity=2,3,6,7
    注記

    CPUAffinity オプションを使用することにより、下層のコンピュートノードは、対応する物理 CPU を自らは使用しないようになります。物理 CPU はインスタンス専用となります。

  1. システムを再起動します。

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

  1. OpenStack Compute Scheduler を実行している各システムの /etc/nova/nova.conf ファイルを編集します。scheduler_default_filters オプションを確認し、コメントアウトされている場合には、コメント解除して、フィルターのリストに AggregateInstanceExtraSpecFilterNUMATopologyFilter を追加します。行全体は以下のようになります。

    scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,
    ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter,
    NUMATopologyFilter,AggregateInstanceExtraSpecsFilter
  2. openstack-nova-scheduler サービスを再起動します。

    systemctl restart openstack-nova-scheduler.service

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

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

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

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

    nova aggregate-create name

    nameperformancecpu_pinning などの適切な名前に置き換えます。

  3. アグリゲートのメタデータを編集して、ピニングを有効化します。

    nova aggregate-set-metadata 1 pinned=true

    このコマンドで、数字の 1 は、前のステップで作成したアグリゲートの ID に置き換えます。

  4. その他のホスト用のアグリゲートを作成します。

    nova aggregate-create name

    name は、適切な名前 (例: normal) に置き換えます。

  5. このアグリゲートのメタデータを編集します。

    nova aggregate-set-metadata 2 pinned=false

    このコマンドでは、数字の 2 を使用しています。これは、最初のアグリゲートの ID 1 の後で作成されたアグリゲートの ID を指定するためです。

  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 name ID RAM disk vCPUs

    name は適切な名前 (例: m1.small.performancepinned.small など)、ID は新規フレーバーの識別子 (標準のフレーバーが 5 つある場合には 6nova が UUID を生成するようにするには auto を指定)、RAM は指定するメモリー容量 (MB 単位) 、disk は指定するディスク容量 (GB 単位) 、vCPUs は確保する仮想 CPU 数に置き換えます。

  8. このフレーバーの hw:cpu_policy のスペックは、dedicated に指定して、CPU ピニングを有効化するための専用のリソースを必要とするように設定します。

    nova flavor-key ID set hw:cpu_policy=dedicated

    ID は、前のステップで作成したフレーバーの ID に置き換えます。

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

    nova flavor-key ID set aggregate_instance_extra_specs:pinned=true

    この場合にも、ID をフレーバーの ID に置き換えます。

  10. 新規アグリゲートにホストを追加します。

    nova aggregate-add-host ID_1 host_1

    ID_1 は最初の (「パフォーマンス」/「ピニング」用) アグリゲートの ID に、host_1 はアグリゲートに追加するホストのホスト名に置き換えます。

    nova aggregate-add-host ID_2 host_2

    ID_2 は 2 番目の ID (「通常」の) アグリゲートの ID に、host_2 はアグリゲートに追加するホストのホスト名に置き換えます。

これで新規フレーバーを使用してインスタンスをブートできるようになりました。

nova boot --image image --flavor flavor server_name

image は保存した仮想マシンイメージの名前に (nova image-list を参照)、flavor はフレーバー名に (m1.small.performancepinned.small、または使用したその他の名前)、 server_name は新規サーバーの名前に置き換えます。

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

nova show server_name

付録A イメージの設定パラメーター

以下のキーは、glance image-update および glance image-create の両コマンドの property オプションに使用することができます。

$ glance image-update IMG-UUID --property architecture=x86_64
注記

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

表A.1 プロパティーのキー

対象コンポーネントキー説明サポートされている値

all

アーキテクチャー

ハイパーバイザーがサポートする必要のある CPU アーキテクチャー (例: x86_64armppc64)。uname -m を実行してマシンのアーキテクチャーを確認します。このためには、 libosinfo project で定義されているアーキテクチャーデータボキャブラリーを使用することを強く推奨します。

  • alpha-DEC 64-bit 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)

all

hypervisor_type

ハイパーバイザーのタイプ

kvmvmware

all

instance_uuid

スナップショットイメージの場合に、このイメージを作成するのに使用したサーバーの UUID

有効なサーバーの UUID

all

kernel_id

AMI 形式のイメージをブートする際にカーネルとして使用する必要のある Image サービスに保管されているイメージの ID

有効なイメージ ID

all

os_distro

オペレーティングシステムのディストリビューションの一般名 (小文字。libosinfo project と同じデータボキャブラリーを使用)。このフィールドで認識済みの値のみを指定します。認識済みの値の検索で役立つように、非推奨の値を以下にリストします。

  • arch: Arch Linux。archlinux および org.archlinux は使用しないでください。
  • centos: Community Enterprise Operating System。org.centos および CentOS は使用しないでください。
  • debian: Debian。Debian および org.debian は使用しないでください。
  • fedora: Fedora。Fedora、org.fedora、org.fedoraproject は使用しないでください。
  • freebsd: FreeBSD。org.freebsd、freeBSD、FreeBSD は使用しないでください。
  • 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。suse、SuSE、org.opensuse は使用しないでください。
  • rhel-Red Hat Enterprise Linux。redhat、RedHat、com.redhat は使用しないでください。
  • sled-SUSE Linux Enterprise Desktop。com.suse は使用しないでください。
  • ubuntu-Ubuntu。Ubuntu、com.ubuntu、org.ubuntu、canonical は使用しないでください。
  • windows-Microsoft Windows。com.microsoft.server は使用しないでください。

all

os_version

ディストリビューターによって指定されるオペレーティングシステムのバージョン

バージョン番号 (例:「11.10」)

all

ramdisk_id

AMI 形式のイメージをブートする際に ramdisk として使用する必要のある、Image サービスに保管されているイメージの ID

有効なイメージ ID

all

vm_mode

仮想マシンのモード。仮想マシンに使用されるホスト/ゲストの ABI (アプリケーションバイナリーインターフェース) を示します。

hvm: 完全仮想化。これは QEMU および KVM で使用されるモードです。

libvirt API ドライバー

hw_disk_bus

ディスクデバイスの接続先となるディスクコントローラーのタイプを指定します。

scsivirtioideusb

libvirt API ドライバー

hw_numa_nodes

インスタンスに公開する NUMA ノードの数 (フレーバーの定義はオーバーライドしません)

整数。NUMA トポロジー定義の詳しい例は、「メタデータの追加」で「hw:NUMA_def key」を参照してください。

libvirt API ドライバー

hw_numa_mempolicy

NUMA のメモリー割り当てポリシー (フレーバーの定義はオーバーライドしません)

「strict」に設定すると、インスタンスのメモリーが、バインディングされている NUMA ノードから割り当てられます (uma_nodes が指定されている場合にはデフォルト) 。「preferred」に設定すると、カーネルは別のノードを使用してフォールバックすることが可能となります。これは、「hw:numa_nodes」パラメーターが「1」に設定されている場合に有用です。

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 GB の RAM から NUMA ノード 0 へのマッピング (フレーバーの定義はオーバーライドしません)

整数

libvirt API ドライバー

hw_numa_mem.1

N GB の RAM から NUMA ノード 1 へのマッピング (フレーバーの定義はオーバーライドしません)

整数

libvirt API ドライバー

hw_qemu_guest_agent

ゲストエージェントのサポート。yes に設定し、かつ qemu-ga もインストールされている場合には、ファイルシステムが休止 (フリーズ) し、すナップショットが自動的に作成されます。

yes / no

libvirt API ドライバー

hw_rng_model

乱数生成器をイメージのインスタンスに追加します。インスタンスのフレーバーを設定することにより、クラウド管理者は、デバイスの動作を有効化して制御することができます。デフォルトでは以下のように設定されます。

  • 乱数生成器は無効化されます。
  • /dev/random がデフォルトのエントロピーソースとして使用されます。物理ハードウェアの乱数生成器を指定するには、nova.conf ファイルで「rng_dev_path=/dev/hwrng」のオプションを使用します。

virtio またはその他のサポートされているデバイス

libvirt API ドライバー

hw_scsi_model

VirtIO SCSI (virtio-scsi) の使用を有効にして、コンピュートインスタンスのブロックデバイスアクセスを提供します。デフォルトでは、インスタンスは VirtIO Block (virtio-blk) を使用します。VirtIO SCSI とは、より高いスケーラビリティーとパフォーマンスを提供する、高度な SCSI ハードウェア対応の準仮想化 SCSI コントローラーデバイスです。

virtio-scsi

libvirt API ドライバー

hw_video_model

使用されるビデオイメージドライバー

vgacirrusvmvgaxenqxl

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 に設定されます。

thinkvirt.com を参照してください。

VMware API ドライバー

vmware_image_version

現在は使用されていません。

1

XenAPI ドライバー

auto_disk_config

true に指定した場合には、ディスク上の root パーティションは、インスタンスがブートする前に自動的にリサイズされます。この値は、Xen ベースのハイパーバイザーを XenAPI ドライバーと共に使用する場合にのみ Compute サービスによって考慮されます。Compute サービスは、イメージに単一のパーティションがあり、かつそのパーティションが ext3 またはext4 のフォーマットの場合にのみリサイズを試みます。

true / false

XenAPI ドライバー

os_type

イメージ上にインストールされるオペレーティングシステム。 XenAPI ドライバーには、イメージの os_type パラメーターの値によって異なるアクションを実行するロジックが組み込まれています。たとえば、os_type=windows イメージの場合には、Linux スワップパーティションの代わりに、FAT32 ベースのスワップパーティションを作成し、挿入されるホスト名を 16 文字未満に制限します。

linux または windows

法律上の通知

Copyright © 2017 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.