6.2. Image サービス用の Block Storage バックエンドの設定


ストレージバックエンドとして Block Storage サービス (cinder) を使用して、Image サービス (glance) を設定できます。

前提条件

  • ストレージバックエンド、コントロールプレーン、およびデータプレーン上のコンピュートノード間の接続を確保するために、ストレージ用にネットワークを計画している。詳細は、デプロイメントの計画ストレージネットワーク および Red Hat OpenStack Services on OpenShift のデプロイRed Hat OpenStack Services on OpenShift のネットワークの準備 を参照してください。
  • 配置、ネットワーク、およびトランスポートプロトコルの要件が満たされていることを確認する。たとえば Block Storage サービスのバックエンドがファイバーチャネル (FC) である場合、Image サービス API (glanceAPI) が実行されているノードにはホストバスアダプター (HBA) が必要です。FC、iSCSI、NVMe over Fabrics (NVMe-oF) の場合は、プロトコルをサポートし、マルチパスを使用するようにノードを設定します。詳細は、トランスポートプロトコルの設定 を参照してください。

手順

  1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、次のパラメーターを Glance テンプレートに追加して、Block Storage サービスを Image サービスのバックエンドとして設定します。

    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    spec:
      ...
      glance:
        template:
          glanceAPIs:
            default:
              replicas: 3 # Configure back end; set to 3 when deploying service
          ...
          customServiceConfig: |
            [DEFAULT]
            enabled_backends = <backend_name>:cinder
            [glance_store]
            default_backend = <backend_name>
            [<backend_name>]
            description = Default cinder backend
            cinder_store_auth_address = {{ .KeystoneInternalURL }}
            cinder_store_user_name = {{ .ServiceUser }}
            cinder_store_password = {{ .ServicePassword }}
            cinder_store_project_name = service
            cinder_catalog_info = volumev3::internalURL
            cinder_use_multipath = true
            [oslo_concurrency]
            lock_path = /var/lib/glance/tmp
    ...
    • API 全体の高可用性のために replicas3 に設定します。
    • <backend_name> は、デフォルトの cinder バックエンドの名前 (例: nfs_store) に置き換えます。
    • /var/lib/glance/tmp ディレクトリーは、共有リソースへの同時アクセスを調整するために oslo.concurrency によって使用されるロックファイルが格納される場所です。
  2. コントロールプレーンを更新します。

    $ oc apply -f openstack_control_plane.yaml -n openstack
  3. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

    $ oc get openstackcontrolplane -n openstack

    ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

    ヒント

    デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

Block Storage サービス (cinder) を Image サービス (glance) のバックエンドとして使用する場合、各イメージを、glance ユーザーが所有する Block Storage サービスプロジェクトにボリューム (イメージボリューム) として保存するのが理想的です。

ユーザーがボリュームを基盤とするイメージから複数のインスタンスまたはボリュームを作成する場合、Image サービスのホストをイメージボリュームにアタッチして、データを複数回コピーする必要があります。しかし、これによりパフォーマンスの問題が発生し、一部のインスタンスまたはボリュームが作成されなくなります。デフォルトでは、Block Storage ボリュームを同じホストに複数回アタッチできないためです。ただし、ほとんどの Block Storage バックエンドは、ボリュームのマルチアタッチプロパティーをサポートしています。このプロパティーを使用すると、ボリュームを同じホストに複数回アタッチできます。したがって、このマルチアタッチプロパティーを有効にする Image サービスバックエンドの Block Storage ボリュームタイプを作成し、このマルチアタッチボリュームタイプを使用するように Image サービスを設定することで、このようなパフォーマンスの問題を防ぐことができます。

注記

デフォルトでは、Block Storage プロジェクト管理者だけがボリュームタイプを作成できます。

手順

  1. ワークステーションから openstackclient Pod のリモートシェルにアクセスします。

    $ oc rsh -n openstack openstackclient
  2. 次のように、マルチアタッチプロパティーを有効にする Image サービスバックエンドの Block Storage ボリュームタイプを作成します。

    $ openstack volume type create glance-multiattach
    $ openstack volume type set --property multiattach="<is> True"  glance-multiattach

    このボリュームタイプにバックエンドを指定しない場合、Block Storage スケジューラーサービスが各イメージボリュームの作成時に使用するバックエンドを決定するため、イメージボリュームが別々のバックエンドに保存される可能性があります。このボリュームタイプに volume_backend_name プロパティーを追加することで、バックエンドの名前を指定できます。マルチアタッチボリュームタイプの正しい volume_backend_name については、Block Storage 管理者に問い合わせる必要がある場合があります。この例では、バックエンド名として iscsi を使用しています。

    $ openstack volume type set glance-multiattach --property volume_backend_name=iscsi
  3. openstackclient Pod を終了します。

    $ exit
  4. OpenStackControlPlane CR ファイルである openstack_control_plane.yaml を開きます。glance テンプレートで、customServiceConfig[<backend_name>] セクションの末尾に次のパラメーターを追加して、Image サービスが Block Storage マルチアタッチボリュームタイプを使用するように設定します。

    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    spec:
      ...
      glance:
        template:
          ...
          customServiceConfig: |
          ...
          [<backend_name>]
          ...
            cinder_volume_type = glance-multiattach
    ...
    • <backend_name> は、デフォルトのバックエンドの名前に置き換えます。
  5. コントロールプレーンを更新します。

    $ oc apply -f openstack_control_plane.yaml -n openstack
  6. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

    $ oc get openstackcontrolplane -n openstack

    ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

    ヒント

    デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

6.2.2. Block Storage バックエンドを設定するためのパラメーター

OpenStackControlPlane CR ファイルの glance テンプレートの customServiceConfig[<backend_name>] セクションの末尾に次のパラメーターを追加できます。

Expand
表6.1 Image サービス用の Block Storage バックエンドのパラメーター
パラメーター = デフォルト値使用方法の説明

cinder_use_multipath = False

ブール値

デプロイメントでマルチパスをサポートする場合は True に設定します。

cinder_enforce_multipath = False

ブール値

マルチパスが実行されていない場合にイメージ転送用のボリュームのアタッチを中止するには、True に設定します。

cinder_mount_point_base = /var/lib/glance/mnt

文字列値

マウントポイント (Image サービスが NFS 共有をマウントするディレクトリー) の絶対パスを表す文字列を指定します。

注記

このパラメーターは、Image サービスに NFS Block Storage バックエンドを使用する場合にのみ適用されます。

cinder_do_extend_attached = False

ブール値

イメージが 1 GB を超える場合は True に設定して、各イメージに必要なボリュームサイズを作成する Block Storage プロセスを最適化します。

Block Storage サービスは、最初に 1 GB のボリュームを作成し、イメージ全体のデータが格納されるまで、ボリュームサイズを 1 GB ずつ拡張します。このパラメーターが追加されていないか、False に設定されている場合、ボリュームを拡張する増分プロセスに長い時間がかかります。ボリュームを後でデタッチし、ボリュームがイメージサイズよりもまだ小さい場合は 1 GB 拡張してから再アタッチする必要があるためです。このパラメーターを True に設定すると、ボリュームがアタッチされている間に 1 GB のボリューム拡張が連続して実行され、このプロセスが最適化されます。

注記

このパラメーターを使用するには、アタッチされた (使用中の) ボリュームの拡張を Block Storage バックエンドがサポートしている必要があります。バックエンドドライバーのドキュメントでサポートされている機能を参照してください。

cinder_volume_type = __DEFAULT__

文字列値

イメージ用のボリュームを作成するために最適化できる Block Storage ボリュームタイプの名前を指定します。たとえば、ボリュームを基盤とするイメージから複数のインスタンスまたはボリュームを作成できるボリュームタイプを作成できます。詳細は、マルチアタッチボリュームタイプの作成 を参照してください。

このパラメーターを使用しない場合、ボリュームはデフォルトの Block Storage ボリュームタイプを使用して作成されます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る