第1章 Image サービス

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

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

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

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

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

カスタマーポータルにログインしていない場合には、Red Hat アカウントの認証情報を入力するように求められます。

1.1. Image サービスについての理解

OpenStack Image サービス (glance) は、以下のような注目すべき機能を提供しています。

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

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

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

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

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

1.1.2. イメージの変換

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

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

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

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

注記

イメージの変換は、イメージをインポートする時にだけトリガーされます。イメージのアップロード時には実行されません。以下に例を示します。

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

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

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

$ head -20 so-disk.vmdk

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

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

# The Disk Data Base
#DDB

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

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

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

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

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

1.1.5. Image サービスのキャッシュ機能を使用したスケーラビリティーの向上

glance-api キャッシュメカニズムを使用して、ローカルマシンにイメージのコピーを保存し、イメージを自動的に取得してスケーラビリティーを向上させます。Image サービスのキャッシュ機能を使用することで、複数のホスト上で glance-api を実行することができます。つまり、同じイメージをバックエンドストレージから何度も取得する必要はありません。Image サービスのキャッシュ機能は、Image サービスの動作には一切影響を与えません。

Red Hat OpenStack Platform director (tripleo) heat テンプレートを使用して Image サービスのキャッシュ機能を設定するには、以下の手順を実施します。

手順

  1. 環境ファイルの GlanceCacheEnabled パラメーターの値を true に設定します。これにより、glance-api.conf Heat テンプレートの flavor の値が自動的に keystone+cachemanagement に設定されます。

    parameter_defaults:
        GlanceCacheEnabled: true
  2. オーバークラウドを再デプロイする際に、openstack overcloud deploy コマンドにその環境ファイルを追加します。
  3. オプション: オーバークラウドを再デプロイする際に、glance_cache_pruner を異なる頻度に調節します。5 分間の頻度の例を以下に示します。

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    ファイルシステムを使い果たす状況を回避するために、ご自分のニーズに合わせて頻度を調節します。異なる頻度を選択する場合は、以下の要素を考慮に入れます。

    • 実際の環境でキャッシュするファイルのサイズ
    • 利用可能なファイルシステムの容量
    • 環境がイメージをキャッシュする頻度

1.1.6. イメージの事前キャッシュ

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

1.1.6.1. 定期的にイメージを事前キャッシュする際のデフォルト間隔の設定

Red Hat OpenStack Platform director は、glance-api サービスの一部としてイメージを事前キャッシュできるようになったので、イメージを事前キャッシュするのに glance-registry は必要なくなりました。デフォルトの間隔は 300 秒です。実際の要件に応じて、デフォルトの間隔を増減することができます。

手順

  1. アンダークラウドの環境ファイルの ExtraConfig パラメーターを使用して、実際の要件に応じて新しい間隔を追加します。

    parameter_defaults:
      ControllerExtraConfig:
        glance::config::glance_api_config:
          DEFAULT/cache_prefetcher_interval:
            value: '<300>'

    <300> を、イメージを事前キャッシュする間隔の秒数に置き換えてください。

  2. /home/stack/templates/ の環境ファイルで間隔を修正したら、stack ユーザーとしてログインして設定をデプロイします。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<ENV_FILE>.yaml

    <ENV_FILE> は、追加した ExtraConfig 設定が含まれる環境ファイルの名前に置き換えてください。

重要

オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e オプションを使用して環境ファイルを再度渡します。

openstack overcloud deploy コマンドについての詳しい情報は、『 director のインストールと使用方法』 の「 デプロイメントコマンド 」を参照してください。

1.1.6.2. 定期的なジョブを使用したイメージの事前キャッシュ

前提条件

定期的なジョブを使用してイメージを事前キャッシュするには、glance_api サービスを実行しているノードに直接接続された glance-cache-manage コマンドを使用する必要があります。サービスの要求に応答するノードを非表示にするプロキシーは使用しないでください。アンダークラウドは glance_api サービスを実行しているネットワークにアクセスできない可能性があるため、最初のオーバークラウドノード (デフォルトでは controller-0 という名前です) でコマンドを実行します。

以下のアクションを確認するには、以下の前提条件の手順を実行します。

  • 適切なホストからコマンドを実行します。
  • 必要な認証情報がある。
  • glance-api コンテナー内から glance-cache-manage コマンドを実行している。

    1. アンダークラウドに stack ユーザーとしてログインし、controller-0 のプロビジョニング IP アドレスを特定します。

      $ ssh stack@undercloud-0
      [stack@undercloud-0 ~]$ source ~/overcloudrc
      (overcloud) [stack@undercloud-0 ~]$ openstack server list -f value -c Name -c Networks | grep controller
      overcloud-controller-1 ctlplane=192.168.24.40
      overcloud-controller-2 ctlplane=192.168.24.13
      overcloud-controller-0 ctlplane=192.168.24.71
      (overcloud) [stack@undercloud-0 ~]$
    2. オーバークラウドに対して認証するには、/home/stack/overcloudrc (デフォルト) に保存されている認証情報を controller-0 にコピーします。

      (overcloud) [stack@undercloud-0 ~]$ scp ~/overcloudrc heat-admin@192.168.24.71:/home/heat-admin/
    3. controller-0heat-admin ユーザーとして接続します。

      (overcloud) [stack@undercloud-0 ~]$ ssh heat-admin@192.168.24.71
    4. controller-0 において、heat-admin ユーザーとして glance_api service の IP アドレスを特定します。以下の例では、IP アドレスは 172.25.1.105 です。

      [heat-admin@controller-0 ~]$ sudo grep -A 10 '^listen glance_api' /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg
      listen glance_api
       server controller0-0.internalapi.redhat.local 172.25.1.105:9292 check fall 5 inter 2000 rise 2
      ...
    5. 「glance-cache-manage\」コマンドは glance_api コンテナーでしか利用できないので、オーバークラウド認証の環境変数がすでに設定されているコンテナーに対して実行するスクリプトを作成する必要があります。controller-0/home/heat-admin に、以下の内容でスクリプト glance_pod.sh を作成します。

      sudo podman exec -ti \
       -e NOVA_VERSION=$NOVA_VERSION \
       -e COMPUTE_API_VERSION=$COMPUTE_API_VERSION \
       -e OS_USERNAME=$OS_USERNAME \
       -e OS_PROJECT_NAME=$OS_PROJECT_NAME \
       -e OS_USER_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \
       -e OS_PROJECT_DOMAIN_NAME=$OS_PROJECT_DOMAIN_NAME \
       -e OS_NO_CACHE=$OS_NO_CACHE \
       -e OS_CLOUDNAME=$OS_CLOUDNAME \
       -e no_proxy=$no_proxy \
       -e OS_AUTH_TYPE=$OS_AUTH_TYPE \
       -e OS_PASSWORD=$OS_PASSWORD \
       -e OS_AUTH_URL=$OS_AUTH_URL \
       -e OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \
       -e OS_COMPUTE_API_VERSION=$OS_COMPUTE_API_VERSION \
       -e OS_IMAGE_API_VERSION=$OS_IMAGE_API_VERSION \
       -e OS_VOLUME_API_VERSION=$OS_VOLUME_API_VERSION \
       -e OS_REGION_NAME=$OS_REGION_NAME \
      glance_api /bin/bash
    6. source コマンドで overcloudrc ファイルを読み込み、glance_pod.sh スクリプトを実行して、オーバークラウドのコントローラーノードに対して認証するのに必要な環境変数が設定されている glance_api コンテナーに対して実行します。

      [heat-admin@controller-0 ~]$ source overcloudrc
      (overcloudrc) [heat-admin@controller-0 ~]$ bash glance_pod.sh
      ()[glance@controller-0 /]$
    7. glance image-list 等のコマンドを使用して、コンテナーでオーバークラウドに対して認証されたコマンドを実行できることを確認します。

      ()[glance@controller-0 /]$ glance image-list
      +--------------------------------------+----------------------------------+
      | ID                                   | Name                             |
      +--------------------------------------+----------------------------------+
      | ad2f8daf-56f3-4e10-b5dc-d28d3a81f659 | cirros-0.4.0-x86_64-disk.img       |
      +--------------------------------------+----------------------------------+
      ()[glance@controller-0 /]$

手順

  1. 管理ユーザーとして、キャッシュするイメージをキューに追加します。

    ()[glance@controller-0 /]$ glance-cache-manage --host=<HOST-IP> queue-image <IMAGE-ID>

    <HOST-IP> を glance-api コンテナーが実行されているコントローラーノードの IP アドレスに、<IMAGE-ID> をキューに追加するイメージの ID に、それぞれ置き換えてください。事前キャッシュするイメージをキューに追加すると、cache_images 定期ジョブはキューに追加されたすべてのイメージを同時に事前取得します。

    注記

    イメージキャッシュは各ノードにローカルなので、Red Hat OpenStack Platform が HA 構成でデプロイされている場合 (3、5、または 7 台のコントローラー)、glance-cache-manage コマンドを実行する際に --host オプションでホストのアドレスを指定する必要があります。

  2. 以下のコマンドを実行して、イメージキャッシュ内のイメージを表示します。

    ()[glance@controller-0 /]$ glance-cache-manage --host=<HOST-IP> list-cached

    <HOST-IP> を環境内のホストの IP アドレスに置き換えてください。

警告

この手順を完了したら、コントローラーノードから overcloudrc ファイルを削除します。

関連情報

以下の目的で、さらに glance-cache-manage コマンドを使用することができます。

  • list-cached: 現在キャッシュされているすべてのイメージを一覧表示する。
  • list-queued: キャッシュするために現在キューに追加されているすべてのイメージを一覧表示する。
  • queue-image: キャッシュするためにイメージをキューに追加する。
  • delete-cached-image: キャッシュからイメージを削除する。
  • delete-all-cached-images: キャッシュからすべてのイメージを削除する。
  • delete-cached-image: キャッシュのキューからイメージを削除する。
  • delete-all-queued-images: キャッシュのキューからすべてのイメージを削除する。