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) の場合は、プロトコルをサポートし、マルチパスを使用するようにノードを設定します。詳細は、トランスポートプロトコルの設定 を参照してください。
手順
OpenStackControlPlaneCR ファイル (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 全体の高可用性のために
replicasを3に設定します。 -
<backend_name>は、デフォルトのcinderバックエンドの名前 (例:nfs_store) に置き換えます。 -
/var/lib/glance/tmpディレクトリーは、共有リソースへの同時アクセスを調整するためにoslo.concurrencyによって使用されるロックファイルが格納される場所です。
-
API 全体の高可用性のために
コントロールプレーンを更新します。
$ oc apply -f openstack_control_plane.yaml -n openstackRHOCP が
OpenStackControlPlaneCR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。$ oc get openstackcontrolplane -n openstackステータスが "Setup complete" であれば、
OpenStackControlPlaneリソースが作成されています。ヒントデプロイの進行状況を追跡するには、
getコマンドの末尾に-wオプションを追加します。
6.2.1. ボリュームを基盤とするイメージから複数のインスタンスまたはボリュームを作成可能にする リンクのコピーリンクがクリップボードにコピーされました!
Block Storage サービス (cinder) を Image サービス (glance) のバックエンドとして使用する場合、各イメージを、glance ユーザーが所有する Block Storage サービスプロジェクトにボリューム (イメージボリューム) として保存するのが理想的です。
ユーザーがボリュームを基盤とするイメージから複数のインスタンスまたはボリュームを作成する場合、Image サービスのホストをイメージボリュームにアタッチして、データを複数回コピーする必要があります。しかし、これによりパフォーマンスの問題が発生し、一部のインスタンスまたはボリュームが作成されなくなります。デフォルトでは、Block Storage ボリュームを同じホストに複数回アタッチできないためです。ただし、ほとんどの Block Storage バックエンドは、ボリュームのマルチアタッチプロパティーをサポートしています。このプロパティーを使用すると、ボリュームを同じホストに複数回アタッチできます。したがって、このマルチアタッチプロパティーを有効にする Image サービスバックエンドの Block Storage ボリュームタイプを作成し、このマルチアタッチボリュームタイプを使用するように Image サービスを設定することで、このようなパフォーマンスの問題を防ぐことができます。
デフォルトでは、Block Storage プロジェクト管理者だけがボリュームタイプを作成できます。
手順
ワークステーションから
openstackclientPod のリモートシェルにアクセスします。$ oc rsh -n openstack openstackclient次のように、マルチアタッチプロパティーを有効にする 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=iscsiopenstackclientPod を終了します。$ exitOpenStackControlPlaneCR ファイルである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>は、デフォルトのバックエンドの名前に置き換えます。
-
コントロールプレーンを更新します。
$ oc apply -f openstack_control_plane.yaml -n openstackRHOCP が
OpenStackControlPlaneCR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。$ oc get openstackcontrolplane -n openstackステータスが "Setup complete" であれば、
OpenStackControlPlaneリソースが作成されています。ヒントデプロイの進行状況を追跡するには、
getコマンドの末尾に-wオプションを追加します。
6.2.2. Block Storage バックエンドを設定するためのパラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenStackControlPlane CR ファイルの glance テンプレートの customServiceConfig、[<backend_name>] セクションの末尾に次のパラメーターを追加できます。
| パラメーター = デフォルト値 | 型 | 使用方法の説明 |
|---|---|---|
|
| ブール値 |
デプロイメントでマルチパスをサポートする場合は |
|
| ブール値 |
マルチパスが実行されていない場合にイメージ転送用のボリュームのアタッチを中止するには、 |
|
| 文字列値 | マウントポイント (Image サービスが NFS 共有をマウントするディレクトリー) の絶対パスを表す文字列を指定します。 注記 このパラメーターは、Image サービスに NFS Block Storage バックエンドを使用する場合にのみ適用されます。 |
|
| ブール値 |
イメージが 1 GB を超える場合は
Block Storage サービスは、最初に 1 GB のボリュームを作成し、イメージ全体のデータが格納されるまで、ボリュームサイズを 1 GB ずつ拡張します。このパラメーターが追加されていないか、 注記 このパラメーターを使用するには、アタッチされた (使用中の) ボリュームの拡張を Block Storage バックエンドがサポートしている必要があります。バックエンドドライバーのドキュメントでサポートされている機能を参照してください。 |
|
| 文字列値 | イメージ用のボリュームを作成するために最適化できる Block Storage ボリュームタイプの名前を指定します。たとえば、ボリュームを基盤とするイメージから複数のインスタンスまたはボリュームを作成できるボリュームタイプを作成できます。詳細は、マルチアタッチボリュームタイプの作成 を参照してください。 このパラメーターを使用しない場合、ボリュームはデフォルトの Block Storage ボリュームタイプを使用して作成されます。 |