永続ストレージのカスタマイズ

手順

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

   $ oc rsh -n openstack openstackclient

2. ボリュームタイプの作成と設定

   $ openstack volume type create --property <key>=<value> <volume_type_name>

   次のように、個別の --property <key>=<value> 引数を指定して、ボリュームタイプに必要なプロパティーを追加します。

   • <key> をプロパティーキーに置き換えます。キーのスペルが正しいことを確認してください。スペルが間違えていてもキーは追加されますが、機能しません。
   • <value> を <key> の必要な値に置き換えます。

   • <volume_type_name> をボリュームタイプの名前に置き換えます。

     以下に例を示します。

     $ openstack volume type create \
     --property thin_provisioning=true \
     --property compression=false \
     MyVolumeType
     +-------------+-----------------------------------------------+
     | Field       | Value                                         |
     +-------------+-----------------------------------------------+
     | description | None                                          |
     | id          | c244205c-fb22-4076-9780-edebe55889bc          |
     | is_public   | True                                          |
     | name        | MyVolumeType                                  |
     | properties  | compression='false', thin_provisioning='true' |
     +-------------+-----------------------------------------------+

3. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. 暗号化されたボリュームタイプを作成します。

   $ openstack volume type create --encryption-provider <provider_name> --encryption-cipher <cipher_name> --encryption-key-size <key_size> --encryption-control-location <control_location> <encrypted_volume_type_name>

   • <provider_name> を luks 暗号化プロバイダーに置き換えます。
   • <cipher_name> を aes-xts-plain64 暗号化暗号に置き換えます。
   • <key_size> を 256 暗号鍵サイズに置き換えます。
   • <control_location> を front-end に置き換えます。これにより、ボリュームがコンピュートノードに接続されたときに Compute サービス (nova) が暗号化を実行します。

   • <encrypted_volume_type_name> を、暗号化されたボリュームタイプに使用する名前に置き換えます。

     以下に例を示します。

     openstack volume type create --encryption-provider luks --encryption-cipher aes-xts-plain64 --encryption-key-size 256 --encryption-control-location front-end MyEncryptedVolType

     暗号化されたボリュームタイプの結果テーブルには、encryption_id を示す追加の encryption フィールドがあります。この例での encryption フィールドの値は、cipher='aes-xts-plain64', control_location='front-end', encryption_id='039c8b02-2e15-41fa-899d-6e2a555b7fc8', key_size='256', provider='luks' です。

3. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. マルチアタッチボリュームタイプを作成します。

   $ openstack volume type create --property multiattach="<is> True" <multi-attach_volume_type_name>

   • <multi-attach_volume_type_name> を、マルチアタッチボリュームタイプの名前に置き換えます。

3. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. 次のように、cinder-internal という名前の汎用プロジェクトとユーザーを作成します。

   $ openstack project create --enable --description "Block Storage Internal Project" cinder-internal
   +-------------+----------------------------------+
   | Field       | Value                            |
   +-------------+----------------------------------+
   | description | Block Storage Internal Project   |
   | domain_id   | default                          |
   | enabled     | True                             |
   | id          | 670615550a5d4126b22953f76f380397 |
   | is_domain   | False                            |
   | name        | cinder-internal                  |
   | options     | {}                               |
   | parent_id   | default                          |
   | tags        | []                               |
   +-------------+----------------------------------+
   $ openstack user create --project cinder-internal cinder-internal
   +---------------------+----------------------------------+
   | Field               | Value                            |
   +---------------------+----------------------------------+
   | default_project_id  | 670615550a5d4126b22953f76f380397 |
   | domain_id           | default                          |
   | enabled             | True                             |
   | id                  | a6b3576f345346a590f2c8292f5cbd60 |
   | name                | cinder-internal                  |
   | options             | {}                               |
   | password_expires_at | None                             |
   +---------------------+----------------------------------+

3. この cinder-internal プロジェクトに対して Block Storage サービスが作成できるボリュームの最大数を変更します。

   $ openstack quota set --volumes <maxnum> cinder-internal

   • <maxnum> を、Block Storage サービスがこの cinder-internal プロジェクトに対して作成できるボリュームの最大数に置き換えます。

4. オプション: Block Storage サービスが、この cinder-internal プロジェクト用に作成できるすべてのボリュームの最大合計サイズを変更します。

   $ openstack quota set --gigabytes <maxgb> cinder-internal

   • <maxgb> を、Block Storage サービスがこの cinder-internal プロジェクト用に作成できるボリュームの最大合計サイズ (ギガバイト単位) に置き換えます。

5. openstackclient Pod を終了します。

   $ exit

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、cinder-internal プロジェクトとプロジェクトユーザーの識別子を cinder テンプレートに追加します。この例では、Block Storage サービスのバックエンドとして Red Hat Ceph Storage を使用しています。

   以下に例を示します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     extraMounts:
       ...
     cinder:
       template:
         cinderVolumes:
           ceph:
             customServiceConfig: |
               [DEFAULT]
               cinder_internal_tenant_project_id = <project_id>
               cinder_internal_tenant_user_id = <user_id>
               ...

   • <project_id> は、cinder-internal プロジェクトの ID に置き換えます。
   • <user_id> は、cinder-internal プロジェクトユーザーの ID に置き換えます。

2. 次のパラメーターを追加して、Image-Volume キャッシュを有効にし、キャッシュのサイズ制限とキャッシュに保存できるイメージの最大数を設定します。

   以下に例を示します。

   ...
             customServiceConfig: |
               [DEFAULT]
               ...
               [ceph]
               image_volume_cache_enabled = True
               image_volume_cache_max_size_gb = <max_size>
               image_volume_cache_max_count = <max_number>
   ...

   • <max_size> は、キャッシュのサイズ制限 (GB 単位) に置き換えます。
   • <max_number> は、キャッシュに保存するイメージの最大数に置き換えます。

3. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

4. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane の CR ファイル (openstack_control_plane.yaml) を開き、ブロックストレージのバックエンド設定に image_upload_use_cinder_backend パラメーターを追加します。この例では、イメージサービスはバックエンドとしてブロックストレージサービスを使用し、ブロックストレージサービスはバックエンドとして Red Hat Ceph Storage を使用します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     cinder:
       template:
         cinderVolumes:
           ceph:
             customServiceConfig: |
               [DEFAULT]
               cinder_internal_tenant_project_id = <project_id>
               cinder_internal_tenant_user_id = <user_id>
               [ceph]
               image_upload_use_cinder_backend = True
               image_upload_use_internal_tenant = True
   ...

   • <project_id> は、cinder-internal プロジェクトの ID に置き換えます。
   • <user_id> は、cinder-internal プロジェクトユーザーの ID に置き換えます。
   • 最適化を有効にするには、image_upload_use_cinder_backend をTrue に設定してください。
   • image_upload_use_internal_tenant を True に設定すると、イメージボリュームがユーザーのプロジェクトではなく、cinder-internal プロジェクトに保存されます。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

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

   $ oc rsh -n openstack openstackclient

2. 宛先バックエンドの名前を取得します。

   $ openstack volume backend pool list

   host@volume_backend_name#pool という構文を使用する宛先バックエンド名がリスト表示されます。以下に例を示します。

   +--------------------------------+
   | Name                           |
   +--------------------------------+
   | cinder-volume-lvm-0@lvm#lvm    |
   | cinder-volume-lvm2-0@lvm2#lvm2 |
   +--------------------------------+

3. ボリュームをあるバックエンドから別のバックエンドに移行します。

   $ openstack volume migrate --host <new_back_end_host>  <volume>

   • <volume> を、元のバックエンドのボリューム ID または名前に置き換えます。
   • <new_back_end_host> を、宛先バックエンドのホストに置き換えます。

4. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient
   $ source ./cloudrc

2. オプション: 必要なプロジェクトの ID または名前を取得するプロジェクトを一覧表示します。

   $ openstack project list

3. 特定プロジェクトの Block Storage リソースクォータに対する現在の制限を表示します。

   $ openstack quota show <project>

   • <project> を必要なプロジェクトの ID または名前に置き換えます。

     指定したプロジェクトの全リソースクォータの制限が表示されます。

     このプロジェクトの各ボリュームタイプは、独自のボリューム、ギガバイト、およびスナップショットクォータを提供します。これらはデフォルトでは指定されていません。つまり、Limit は -1 に設定されています。これら 3 つのボリュームタイプクォータには、ボリュームタイプ名が接尾辞として追加されています。たとえば、デフォルトのボリュームタイプ __DEFAULT__ には、volumes___DEFAULT__、gigabytes___DEFAULT__、snapshots___DEFAULT__ のクォータが関連付けられています。

     $ openstack quota show c2c1da89ed1648fc8b4f35a045f8d34c
     +-----------------------+-------+
     | Resource              | Limit |
     +-----------------------+-------+
     ...
     | volumes               |    10 |
     | snapshots             |    10 |
     | gigabytes             |  1000 |
     ...
     | volumes___DEFAULT__   |    -1 |
     | gigabytes___DEFAULT__ |    -1 |
     | snapshots___DEFAULT__ |    -1 |
     ...
     | per-volume-gigabytes  |    -1 |
     +-----------------------+-------+

4. オプション: すべての Block Storage ボリュームの合計サイズを変更します。no_snapshot_gb_quota の Block Storage 初期パラメーターには、ユーザーがプロジェクトに作成できるスナップショットのサイズが含まれています。

   $ openstack quota set --gigabytes <totalgb> <project>

   • <totalgb> を、ユーザーがこのプロジェクト用に作成できる Block Storage ボリューム (および、該当する場合はスナップショット) の合計サイズ (ギガバイト単位) に置き換えます。

5. オプション: ユーザーがプロジェクト用に作成できる Block Storage ボリュームの最大数を変更します。

   $ openstack quota set --volumes <maxvolumes> <project>

   • <maxvolumes> を、ユーザーがこのプロジェクト用に作成できる最大ボリューム数に置き換えます。

6. オプション: ユーザーがプロジェクト用に作成できる Block Storage ボリュームの最大サイズを変更します。

   $ openstack quota set --per-volume-gigabytes <maxsize> <project>

   • <maxsize> を、ユーザーがこのプロジェクト用に作成できる Block Storage ボリュームの最大サイズ (ギガバイト単位) に置き換えます。

7. オプション: ユーザーがプロジェクト用に作成できる Block Storage ボリュームスナップショットの最大数を変更します。

   $ openstack quota set --snapshots <maxsnapshots> <project>

   • <maxsnapshots> を、ユーザーがこのプロジェクト用に作成できるスナップショットの最大数に置き換えます。

8. オプション: これらの Block Storage リソースクォータの使用状況を表示し、必要に応じて特定プロジェクトの制限に対する変更を確認します。

   $ cinder quota-usage <project_id>

   • <project_id> をプロジェクトの ID に置き換えます。

     このテーブルで、該当するプロジェクトの Block Storage リソースクォータを指定する行を見つけます。このテーブルには、各ボリュームタイプに定義されたクォータも含まれます。このテーブルで、以下に示す列を確認します。

   • In_use 列は、各リソースがどれだけ使用されているかを示します。

   • Limit 列には、クォータ制限がデフォルト設定から調整されているかどうかが示されます。この例では、すべてのクォータ制限が調整されています。

     $ cinder quota-usage c2c1da89ed1648fc8b4f35a045f8d34c
     +-----------------------+--------+----------+-------+-----------+
     | Type                  | In_use | Reserved | Limit | Allocated |
     +-----------------------+--------+----------+-------+-----------+
     ...
     | gigabytes             | 750    | 0        | 1500  |           |
     | gigabytes___DEFAULT__ | 0      | 0        | -1    |           |
     | groups                | 0      | 0        | 10    |           |
     | per_volume_gigabytes  | 0      | 0        | 300   |           |
     | snapshots             | 1      | 0        | 7     |           |
     | snapshots___DEFAULT__ | 0      | 0        | -1    |           |
     | volumes               | 5      | 0        | 15    |           |
     | volumes___DEFAULT__   | 0      | 0        | -1    |           |
     +-----------------------+--------+----------+-------+-----------+

9. openstackclient Pod を終了します。

   $ exit

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、cinder テンプレートに notificationsBus パラメーターを追加して、トランスポート URL を要求する際に使用する RabbitMQ クラスター名を指定します。

   注記

   notificationsBusInstance パラメーターは非推奨です。notificationsBusInstance を使用している既存のデプロイメントは、自動的に notificationsBus インターフェイスを使用するように移行されます。

   kind: OpenStackControlPlane
   spec:
   ...
     cinder:
       template:
         ...
         notificationsBus:
           cluster: rabbitmq
         customServiceConfig: |
   ...

   通知を無効にするには、cinder テンプレートから notificationsBus パラメーターを削除し、コントロールプレーンを更新してください。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

3. Red Hat OpenShift Container Platform (RHOCP) が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

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

   $ oc rsh -n openstack openstackclient

2. QoS 仕様を作成します。

   $ openstack volume qos create [--consumer <qos_spec_consumer>] --property <key>=<value> <qos_spec_name>

   次のように、QoS 制限ごとに個別の --property <key>=<value> 引数を指定して、QoS 仕様にパフォーマンス制限を追加します。

   • <key> を必要なパフォーマンス制約の QoS プロパティーキーに置き換えます。詳細は、Block Storage QoS プロパティーキー を参照してください。

     重要

     QoS プロパティーキーのスペルが正しいことを確認してください。スペルが間違っているプロパティーキーを含むボリュームのパフォーマンス制限は無視されます。

   • <value> を QoS プロパティーキーで必要な測定単位での、このパフォーマンス制約に対するデプロイメント固有の制限に置き換えます。
   • オプション: <qos_spec_consumer> を、この QoS 仕様の必要なコンシューマーに置き換えます。指定しない場合、コンシューマーはデフォルトで both を使用します。詳細は、Consumers of QoS specifications を参照してください。

   • <qos_spec_name> を QoS 仕様の名前に置き換えます。

     以下に例を示します。

     $ openstack volume qos create \
      --property read_iops_sec=5000 \
      --property write_iops_sec=7000 \
       --consumer front-end \
      myqoslimits
     +------------+---------------------------------------------+
     | Field      | Value                                       |
     +------------+---------------------------------------------+
     | consumer   | front-end                                   |
     | id         | 9fc9a481-28e9-49b8-84eb-f0a476cc89a5        |
     | name       | myqoslimits                                |
     | properties | read_iops_sec='5000', write_iops_sec='7000' |
     +------------+---------------------------------------------+

3. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. QoS 仕様を設定して、その他のパフォーマンス制限を追加したり、既存のプロパティーの制限を変更したりします。

   $ openstack volume qos set --property <key>=<value> <qos_spec_name>

   1 つ以上の --property <key>=<value> 引数を追加できます。このコマンドでは、プロパティーの変更が成功したかどうかを確認できません。次のコマンドを実行して、QoS 仕様に加えられた変更を確認できます。

   $ openstack volume qos list

   このコマンドは、設定されているすべての QoS 仕様の詳細な設定を示すテーブルを表示し、Properties 列には各 QoS 仕様の設定済みプロパティーがすべて表示されます。

3. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. 必要な QoS 仕様を必要なボリュームタイプに関連付けます。

   $ openstack volume qos associate <qos_spec_name> <volume_type>

   • <qos_spec_name> を QoS 仕様の名前または ID に置き換えます。openstack volume qos list コマンドを実行すると、すべての QoS 仕様の名前と ID をリスト表示できます。
   • <volume_type> をボリュームタイプの名前または ID に置き換えます。openstack volume type list コマンドを実行すると、すべてのボリュームタイプの名前と ID をリスト表示できます。

3. QoS 仕様が関連付けられていることを確認します。

   $ openstack volume qos list

   出力テーブルの Associations 列には、各 QoS 仕様に関連付けられているボリュームタイプの名前が表示されます。

   以下に例を示します。

4. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. QoS 仕様に関連付けられているボリュームタイプの関連付けを解除します。

   • QoS 仕様に関連付けられた特定のボリュームタイプの関連付けを解除するには、次の手順を実行します。

     $ openstack volume qos disassociate <qos_spec_name> --volume-type <volume_type>

     • <qos_spec_name> を QoS 仕様の名前または ID に置き換えます。openstack volume qos list コマンドを実行すると、すべての QoS 仕様の名前と ID をリスト表示できます。
     • <volume_type> を、この QoS 仕様に関連付けられたボリュームタイプの名前または ID に置き換えます。cinder type-list コマンドを実行して、すべてのボリュームタイプの名前と ID を一覧表示できます。

   • QoS 仕様に関連付けられているすべてのボリュームタイプの関連付けを解除するには、次の手順を実行します。

     $ openstack volume qos disassociate <qos_spec_name> --all

3. QoS 仕様の関連付けが解除されていることを確認します。

   $ openstack volume qos list

   この QoS 仕様の Associations 列には、指定されたボリュームタイプが含まれていないか、すべてのボリュームタイプの関連付けが解除されている場合は空でなければなりません。

4. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient
   $ source ./cloudrc

2. オプション: 必要なプロジェクトの ID または名前を取得するプロジェクトを一覧表示します。

   $ openstack project list

3. 特定プロジェクトのバックアップクォータの現在の制限を表示します。

   $ openstack quota show <project>

   • <project> を必要なプロジェクトの ID または名前に置き換えます。

     これにより、指定されたプロジェクトのすべてのリソースクォータの制限が表示されます。テーブルの backup-gigabytes フィールドと backups フィールドの Limit 列に注意してください。以下に例を示します。

     $ openstack quota show c2c1da89ed1648fc8b4f35a045f8d34c
     +-----------------------+-------+
     | Resource              | Limit |
     +-----------------------+-------+
     ...
     | backups               |    10 |
     ...
     | backup-gigabytes      |  1000 |
     ...
     +-----------------------+-------+

4. オプション: ユーザーがプロジェクト用に作成できるすべての Block Storage ボリュームバックアップの合計サイズを変更します。

   $ openstack quota set --backup-gigabytes <totalgb> <project>

   • <totalgb> を、ユーザーがこのプロジェクト用に作成できるバックアップの合計サイズ (ギガバイト単位) に置き換えます。

5. オプション: ユーザーがプロジェクト用に作成できる Block Storage ボリュームバックアップの最大数を変更します。

   $ openstack quota set --backups <maxnum> <project>

   • <maxnum> を、ユーザーがこのプロジェクト用に作成できるバックアップの最大数に置き換えます。

6. オプション: これらの Block Storage ボリュームのバックアップクォータの使用状況を表示し、必要に応じて、特定プロジェクトに対する制限の変更を確認します。

   $ cinder quota-usage <project_id>

   • <project_id> をプロジェクトの ID に置き換えます。

     このテーブルの最初の 2 行は、指定されたプロジェクトのバックアップクォータを指定します。このテーブルで、以下に示す列を確認します。

   • In_use 列は、各リソースがどれだけ使用されているかを示します。

   • Limit 列は、クォータ制限がデフォルト設定から調整されたかどうかを示します。この例では、両方とも調整されています。

     $ cinder quota-usage c2c1da89ed1648fc8b4f35a045f8d34c
     +-----------------------+--------+----------+-------+-----------+
     | Type                  | In_use | Reserved | Limit | Allocated |
     +-----------------------+--------+----------+-------+-----------+
     | backup_gigabytes      | 235    | 0        | 500   |           |
     | backups               | 7      | 0        | 12    |           |
     ...

7. openstackclient Pod を終了します。

   $ exit

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、glance テンプレートの customServiceConfig に次のパラメーターを追加します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
       ...
     glance:
       enabled: true
       template:
         customServiceConfig: |
           [DEFAULT]
           enabled_import_methods=web-download,glance-direct,copy-image
         glanceAPIs:
           ...

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、次のパラメーターを glance テンプレートに追加します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
       ...
     glance:
       enabled: true
       template:
         databaseInstance: openstack
         databaseUser: glance
         customServiceConfig: |
            [image_format]
           disk_formats=<raw>,<iso>
         glanceAPIs:
           ...

   • <raw> と <iso> を、有効にするフォーマットに置き換えます。その場合に選択できるサポート対象ディスクフォーマットは、none、ami、ari、aki、vhd、vhdx、vmdk、raw、qcow2、vdi、iso、ploop です。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、glance テンプレートに notificationsBus パラメーターを追加して、トランスポート URL を要求する際に使用する RabbitMQ クラスター名を指定します。

   注記

   notificationsBusInstance パラメーターは非推奨です。notificationsBusInstance を使用している既存のデプロイメントは、自動的に notificationsBus インターフェイスを使用するように移行されます。

   kind: OpenStackControlPlane
   spec:
   ...
     glance:
       template:
         ...
         notificationsBus:
           cluster: rabbitmq
         customServiceConfig: |
   ...

   通知をオフにするには、glance テンプレートから notificationsBus パラメーターを削除し、コントロールプレーンを更新してください。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

3. Red Hat OpenShift Container Platform (RHOCP) が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、次のパラメーターを glance テンプレートに追加します。rbd_thin_provisioning パラメーターを True に設定して、スパースイメージのアップロードを有効にします。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
       ...
     glance:
       template:
         databaseInstance: openstack
         databaseUser: glance
         customServiceConfig: |
           [DEFAULT]
           enabled_backends = <backend_name>:rbd
           enabled_import_methods=[web-download]
           [glance_store]
           default_backend = <backend_name>
           [<backend_name>]
           rbd_store_ceph_conf = /etc/ceph/ceph.conf
           store_description = "RBD backend"
           rbd_store_pool = images
           rbd_store_user = openstack
           rbd_thin_provisioning = True
     ...

   • <backend_name> は、デフォルトのバックエンドの名前に置き換えます。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

1. イメージファイルをローカルにダウンロードします。

   $ wget <file_location>/<file_name>

   • <file_location> をファイルの場所に置き換えます。

   • <file_name> は、ファイルの名前に置き換えます。

     以下に例を示します。

     $ wget https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1508.qcow2

2. アップロードするイメージのディスクサイズと仮想サイズを確認します。

   $ qemu-img info <file_name>

   以下に例を示します。

   $ qemu-img info CentOS-6-x86_64-GenericCloud-1508.qcow2
   
   image: CentOS-6-x86_64-GenericCloud-1508.qcow2
   file format: qcow2
   virtual size: 8 GiB (8589934592 bytes)
   disk size: 1.09 GiB
   cluster_size: 65536
   Format specific information:
   compat: 0.10
   refcount bits: 1

3. イメージをインポートします。

   $ glance image-create-via-import --disk-format qcow2 --container-format bare --name centos_1 --file <file_name>

4. イメージ ID を記録します。後続のステップで必要になります。

5. イメージがインポートされ、アクティブ状態にあることを確認します。

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

     $ oc rsh -n openstack openstackclient

   • イメージを表示します。

     $ openstack image show <image_id>

   • openstackclient Pod を終了します。

     $ exit

6. Ceph Storage ノードから、イメージのサイズが、ステップ 2 出力の仮想サイズよりも小さいことを確認します。

   $ sudo rbd -p images diff <image_id> | awk '{ SUM += $2 } END { print SUM/1024/1024/1024 " GB" }'
   
   1.03906 GB

手順

1. OpenStackControlPlane CR ファイル openstack_control_plane.yaml を開き、glance テンプレートにパラメーターを追加して新しい glanceAPI を設定します。次の例では、Object Storage サービス (swift) をバックエンドとして使用する既存の default API があり、OpenStackControlPlane を更新して新しい default1 API をデプロイします。

   ...
   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     glance:
       template:
         databaseInstance: openstack
         keystoneEndpoint: default
         glanceAPIs:
           default:
             customServiceConfig: |
               [DEFAULT]
               enabled_backends = <backend_name>:swift
               [glance_store]
               default_backend = <backend_name>
               [<backend_name>]
               swift_store_create_container_on_put = True
               swift_store_auth_version = 3
               swift_store_auth_address = {{ .KeystoneInternalURL }}
               swift_store_endpoint_type = internalURL
               swift_store_user = service:glance
               swift_store_key = {{ .ServicePassword }}
             preserveJobs: false
             replicas: 3
           default1:
             type: single
             replicas: 1
         storage:
           storageRequest: 10G
   ...

   • <backend_name> は、デフォルトのバックエンドの名前に置き換えます。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane に複数の glanceAPI がデプロイされていることを確認します。

   $ oc -n openstack get oscp  $(oc get oscp -o custom-columns=NAME:.metadata.name --no-headers) -o jsonpath='{.spec.glance.template.glanceAPIs}' | jq

2. Keystone カタログに登録されている現在の glanceAPI を特定します。

   $ oc -n openstack get oscp $(oc get oscp -o custom-columns=NAME:.metadata.name --no-headers) -o jsonpath='{.spec.glance.template.keystoneEndpoint}'

3. 新しい glanceAPI に Keystone エンドポイントがあることを確認します。

   $ oc exec -it openstackclient bash -- openstack endpoint list | grep image

4. 削除する glanceAPI が Keystone カタログに登録されている API である場合は、OpenStackControlPlane CR ファイルの openstack_control_plane.yaml を開いて API を廃止し、keystoneEndpoint パラメーターを更新します。次の例では、default という名前の glanceAPI を削除し、keystoneEndpoint パラメーターを default1 に更新します。

   ...
   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   spec:
     glance:
       template:
         keystoneEndpoint: default1
         glanceAPIs:
           default1:
             type: single
             replicas: 1
         storage:
           storageRequest: 10G
   ...

5. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane CR ファイル openstack_control_plane.yaml を開き、次のパラメーターを glance テンプレートに追加して、すべての glanceAPI インスタンスに適用するイメージクォータを設定します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack
   spec:
     glance:
       template:
         ...
         quotas:
           imageSizeTotal: 1000
           imageStageTotal: 1000
           imageCountUpload: 1000
           imageCountTotal: 1000
   ...

   • クォータ制限を 0 に設定すると、クォータの種類に応じて動作が異なります。次に例を示します。

     • imageCountTotal: 0: ユーザーがイメージの作成を防ぎます。
     • imageCountUpload: 0: ユーザーが任意のイメージにデータをアップロードできます。

2. Identity サービスに登録されているイメージクォータへの glance ユーザーアクセスを確保するには、reader ロールアクセスを割り当てて検証します。

   1. openstackclient のリモートシェルにアクセスします。

      $ oc rsh openstackclient

   2. glance ユーザーに reader ロールアクセスを割り当てます。

      $ openstack role add --user glance --system all reader

   3. glance CLI にアクセスします。

      $ source /home/cloud-admin/cloudrc

   4. イメージクォータへの glance ユーザーアクセスを確認します。

      $ glance usage
      +-----------------------+-------+-------+
      | Quota                 | Limit | Usage |
      +-----------------------+-------+-------+
      | image_size_total      | 10    | 0     |
      | image_stage_total     | 10    | 0     |
      | image_count_total     | 10    | 0     |
      | image_count_uploading | 10    | 0     |
      +-----------------------+-------+-------+

   5. openstackclient Pod を終了します。

      $ exit

3. オプション: image_size_cap を設定するには、glance テンプレートの customServiceConfig セクションに次のパラメーターを追加します。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack
   spec:
     glance:
       template:
         ...
         quotas:
           ...
         customServiceConfig |
           [DEFAULT]
           ...
           image_size_cap = 1099511627776
   ...

   • デフォルト値 1099511627776 (1 TB) は、最大値 9223372036854775808 までの値に置き換えることができます。利用可能なバックエンドストレージ容量によっては、値が低いとイメージのアップロードが失敗する可能性があり、値が高いとストレージの消費量が増加します。

4. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

5. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

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

   $ oc rsh -n openstack openstackclient

2. プロジェクト固有のクォータをリスト表示、表示、作成、更新、または削除します。

   • 特定のプロジェクトに関連付けられているリソース制限を一覧表示します。

     $ openstack limit list
           --project <project>

     • <project> は、リソース制限を一覧表示するプロジェクトの名前に置き換えます。

   • 特定の制限の詳細を表示します。

     $ openstack limit show <limit_id>

     • <limit_id> は、表示する制限の ID に置き換えます。

   • プロジェクト固有のリソース制限を作成します。

     $ openstack limit create
           [--description <description>]
           [--region <region>]
           --project <project>
           --service <service>
           --resource-limit <resource_limit>
           <resource_name>

     • オプション: <description> は、制限の説明に置き換えます。
     • オプション: 特定のリージョンに制限を適用する場合は、<region> をリージョンに置き換えます。
     • <project> は、制限を適用するプロジェクトの名前に置き換えます。
     • <service> は、制限を作成するリソースを担当するサービスに置き換えます。
     • <resource_limit> は、プロジェクトの制限として設定する値に置き換えます。
     • <resource_name> は、制限を作成するリソースの名前に置き換えます。

   • 特定のプロジェクトのリソース制限を更新します。

     $ openstack limit set
           [--description <description>]
           --resource-limit <resource_limit>
           <limit_id>

   • リソース制限を削除します。

     $ openstack limit delete <limit_id> [<limit_id> ...]

3. openstackclient Pod を終了します。

   $ exit

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、swift テンプレートの swiftProxy パラメーターで Ceilometer ミドルウェアとオブジェクト暗号化を有効にします。

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           ceilometerEnabled: true
           encryptionEnabled: true
           replicas: 2
   ...

2. swiftRing パラメーターの下に、minPartHours、partPower、ringReplicas の値を追加します。

   ...
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           ...
         swiftRing:
           minPartHours: <number_of_hours>
           partPower: <partition_power>
           ringReplicas: <number_of_copies>
   ...

   • <number_of_hours> を、リバランス後にリングパーティションを移動できるようになるまでの最小時間 (時間単位) に置き換えてください。
   • <partition_power> を、Object Storage リングのビルド時に使用するパーティションのべき乗 (例: 12) に置き換えます。
   • <number_of_copies> を、クラスター内に必要なオブジェクトコピーの数に置き換えます。

3. swiftStorage パラメーターの下に defaultConfigOverwrite パラメーターを追加して、object-server サービスのワーカー数を変更します。

   ...
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           ...
         swiftRing:
           ...
         swiftStorage:
           replicas: 3
           storageClass: local-storage
           storageRequest: 10Gi
           defaultConfigOverwrite:
             01-object-server.conf: |
               [DEFAULT]
               workers = <number_of_workers>

   • <number_of_workers> を、object-server サービスで必要なワーカーの数に置き換えます。

4. オプション: オブジェクトストレージサービスコンテナーのリソース制限を設定して、サービス品質 (QoS) クラスを BestEffort から Burstable に変更します。swift テンプレートの下に swiftProxy と swiftStorage の リソース を追加します。

   ...
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           ...
           resources:
             limits:
               cpu: <cpu_limit>
               memory: <memory_limit>
             requests:
               cpu: <cpu_request>
               memory: <memory_request>
         swiftStorage:
           ...
           resources:
             limits:
               cpu: <cpu_limit>
               memory: <memory_limit>
             requests:
               cpu: <cpu_request>
               memory: <memory_request>
   ...

   • <cpu_limit> は、このサービスの Pod に対する CPU の最大絶対割り当て量 (ミリ CPU 単位) に置き換えます。たとえば、2000m に設定すると、このサービスの Pod への CPU 割り当てを 200% に制限できます。
   • <memory_limit> は、このサービスの Pod に対するメモリーの最大割り当てに置き換えます。たとえば、5Gi に設定すると、このサービスの Pod へのメモリー割り当てが 5 GiB に制限されます。
   • <cpu_request> は、このサービスの Pod に要求する CPU の最小割り当て量 (ミリ CPU 単位) に置き換えます。たとえば、500m に設定すると、このサービス用の Pod に CPU の 50% が割り当てられます。
   • <memory_request> は、このサービスの Pod に要求するメモリーの最小割り当てに置き換えます。たとえば、5Gi に設定すると、このサービス用の Pod に 5GiB のメモリーが割り当てられます。

5. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

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

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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

手順

1. OpenStackControlPlane CR を更新して、swiftStorage レプリカを必要な数まで増やします。

   $ oc patch openstackcontrolplane $(oc get oscp -n openstack -o custom-columns=NAME:.metadata.name --no-headers) -n openstack --type=merge -p '{"spec": {"swift": {"template": {"swiftStorage": {"replicas": <required_count>}}}}}'

   • <required_count> を、必要なストレージレプリカの総数に置き換えてください。たとえば、レプリカ数を 3 から 5 に増やすには、<required_count> を5 に設定します。

2. 新しい PVC が作成され、ストレージクラスに正常にバインドされていることを確認します。

   $ oc get pvc -n openstack -l service=swift

   出力例

   NAME                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   swift-swift-storage-0    Bound    pvc-3c7d003e-529c-47c0-ae97-5c6159003a2f   100Gi      RWO            swift-storage    10d
   swift-swift-storage-1    Bound    pvc-8f2a1b9c-6d4e-11ec-90d6-0242ac120003   100Gi      RWO            swift-storage    10d
   swift-swift-storage-2    Bound    pvc-a3c4d5e6-6d4e-11ec-90d6-0242ac120003   100Gi      RWO            swift-storage    10d
   swift-swift-storage-3    Bound    pvc-b7e8f9a0-6d4e-11ec-90d6-0242ac120003   100Gi      RWO            swift-storage    1m
   swift-swift-storage-4    Bound    pvc-c9f0a1b2-6d4e-11ec-90d6-0242ac120003   100Gi      RWO            swift-storage    1m

   すべての PVC は バインド済み の ステータス を表示する必要があります。

3. すべての swift-storage Pod が作成され、実行 状態になっていることを確認してください。

   $ oc get pods -n openstack -l service=swift

   出力例

   NAME                      READY   STATUS    RESTARTS   AGE
   swift-proxy-0             3/3     Running   0          10d
   swift-proxy-1             3/3     Running   0          10d
   swift-storage-0           4/4     Running   0          10d
   swift-storage-1           4/4     Running   0          10d
   swift-storage-2           4/4     Running   0          10d
   swift-storage-3           4/4     Running   0          2m
   swift-storage-4           4/4     Running   0          2m

   すべての Pod は、STATUS: Running と表示され、すべてのコンテナーが準備完了している必要があります。

4. 自動リングリバランスが完了するまでお待ちください。

   $ oc get job -n openstack -l job-name=swift-ring-rebalance

   出力例

   NAME                   COMPLETIONS   DURATION   AGE
   swift-ring-rebalance   1/1           45s        3m

   COMPLETIONS に 1/1 と表示されたら、作業は完了です。

   注記

   swift-operator は、 ストレージデバイスを追加すると、自動的にリングの再バランスを実行します。ただし、リバランスは minPartHours 間隔 (デフォルト:24 時間) を尊重します。この 24 時間以内に複数のリバランスが発生した場合、オペレーターは間隔が経過するのを待たずに処理を実行します。その代わりに、即座にリバランスがトリガーされますが、すべてのデータレプリカが新しいデバイスに移行するわけではありません。このシナリオでは、レプリカのカバー率が 100% であることを確認した後、手動でリバランスを行う必要があります。詳細は、オブジェクトストレージリングの再バランス を参照してください。

5. オブジェクトストレージクラスターが更新された容量を認識していることを確認してください。

   $ oc rsh -c proxy-server $(oc get pods -n openstack -l service=swift,component=swift-proxy -o name | head -n 1) swift-recon --diskusage

   出力例

   [2026-04-16 10:30:15] Checking disk usage on 5 hosts...
   -> 192.168.122.100:6200: 0.00% used (100.00 GiB / 100.00 GiB)
   -> 192.168.122.101:6200: 0.00% used (100.00 GiB / 100.00 GiB)
   -> 192.168.122.102:6200: 0.00% used (100.00 GiB / 100.00 GiB)
   -> 192.168.122.103:6200: 0.00% used (100.00 GiB / 100.00 GiB)
   -> 192.168.122.104:6200: 0.00% used (100.00 GiB / 100.00 GiB)

   ホスト数と総容量は、想定していた設定と一致しています。

手順

1. OpenStackDataPlaneNodeSet CR に新しいストレージデバイスを追加します。

   • ノードセット内のすべてのノードにディスクを追加するには、nodeTemplate.ansible.ansibleVars.edpm_swift_disks リストを更新します。

     apiVersion: dataplane.openstack.org/v1beta1
     kind: OpenStackDataPlaneNodeSet
     metadata:
       name: openstack-edpm-swift
       namespace: openstack
     spec:
       ...
       nodeTemplate:
         ansible:
           ansibleVars:
             edpm_swift_disks:
             - device: /dev/vdb
               path: /srv/node/vdb
               region: 0
               weight: 4000
               zone: 0
             - device: /dev/vdc
               path: /srv/node/vdc
               region: 0
               weight: 4000
               zone: 0
             - device: /dev/vdd
               path: /srv/node/vdd
               region: 0
               weight: 4000
               zone: 0
       ...

   • ストレージデバイスを特定のノードにのみ追加するには、nodes.<node_name>.ansible.ansibleVars.edpm_swift_disks リストを更新します。

     apiVersion: dataplane.openstack.org/v1beta1
     kind: OpenStackDataPlaneNodeSet
     metadata:
       name: openstack-edpm-swift
       namespace: openstack
     spec:
       ...
       nodes:
         edpm-swift-0:
           ansible:
             ansibleVars:
               edpm_swift_disks:
               - device: /dev/vdd
                 path: /srv/node/vdd
                 region: 0
                 weight: 1000
                 zone: 0
           ...
       ...

     各項目の説明:

     device

     ストレージディスクのブロックデバイスパスを指定します。

     path

     オブジェクトストレージサービスがディスクにアクセスするマウントポイントパスを指定します。

     region

     ディスクのリージョン識別子を指定します。デフォルトのリージョンには 0 を 使用してください。

     weight

     ディスクの容量 (GiB 単位) に基づいて、ディスクの相対的な重量を指定します。重みによって、オブジェクトストレージリング内のディスクに割り当てられるパーティションの数が決まります。

     zone

     ディスクのゾーン識別子を指定します。デフォルトゾーンには 0 を 使用してください。

2. 更新された OpenStackDataPlaneNodeSet CR を適用します。

   $ oc apply -f <nodeset_file>.yaml -n openstack

3. Swift サービスを実行する OpenStackDataPlaneDeployment CR を作成して、データプレーンノードに変更をデプロイします。

   $ oc apply -n openstack -f - << EOF
   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: swift-storage-expansion
   spec:
     servicesOverride:
       - swift
     nodeSets:
       - <nodeset_name>
   EOF

   • <nodeset_name> をOpenStackDataPlaneNodeSet CR の名前に置き換えてください。

4. デプロイメントが完了するまで待ちます。

   $ oc wait openstackdataplanedeployment swift-storage-expansion --for condition=Ready --timeout=600s -n openstack

5. リングリバランスを実行して、新しいストレージデバイス全体にデータを分散します。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-tool rebalance'

   注記

   リングのリバランスは、minPartHours 間隔 (デフォルト:24 時間) を尊重します。この 24 時間以内に複数のリング変更が発生した場合は、データの耐久性を確保するために、レプリカのカバー率が 100% であることを確認した後、手動でリバランスを行う必要があります。詳細は、オブジェクトストレージリングの再バランス を参照してください。

6. 更新されたリングをデータプレーンノードにプッシュします。

   $ oc delete --ignore-not-found --wait openstackdataplanedeployment swift-ring-update -n openstack
   $ oc apply -n openstack -f - << EOF
   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: swift-ring-update
   spec:
     ansibleTags: swiftrings
     servicesOverride:
       - swift
     nodeSets:
       - <nodeset_name>
   EOF

7. リングアップデートのデプロイメントが完了するまでお待ちください。

   $ oc wait openstackdataplanedeployment swift-ring-update --for condition=Ready --timeout=300s -n openstack

検証

1. オブジェクトストレージクラスターが更新された容量を認識していることを確認してください。

   $ oc rsh -c proxy-server $(oc get pods -n openstack -l service=swift,component=swift-proxy -o name | head -n 1) swift-recon --diskusage

   出力例

   [2026-04-16 10:30:15] Checking disk usage on 8 hosts...
   -> edpm-swift-0:6200: 0.00% used (100.00 GiB / 100.00 GiB)
   -> edpm-swift-0:6201: 0.00% used (100.00 GiB / 100.00 GiB)
   -> edpm-swift-0:6202: 0.00% used (100.00 GiB / 100.00 GiB)
   ...

   出力には、更新された総容量を持つすべてのノードとディスクが表示されます。

2. リバランス後、すべてのオブジェクトレプリカが正しく配置されていることを確認してください。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-report'

   出力例

   Queried 1024 objects for dispersion reporting, 3s, 0 retries
   100.00% of object copies found (3072 of 3072)
   Queried 1024 containers for dispersion reporting, 2s, 0 retries
   100.00% of container copies found (3072 of 3072)

   別のスケーリング操作またはリングのリバランスを実行する前に、すべての値が 100.00% になっていることを確認してください。

手順

1. リングの再バランスを手動で実行する:

   重要

   前回のリバランスが完全に複製された後にのみ、リバランスが実行されます。レプリケーションが完了する前にリバランスを行うと、データが複数回移動される可能性があり、一時的なデータ利用不能のリスクが高まります。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-tool rebalance'

   これにより、すべてのオブジェクトストレージリングのバランスが再調整され、swift-ring-files ConfigMap 内のリングファイルが更新されます。

2. 外部データプレーンノードを使用する場合は、更新されたリングをデータプレーンノードにプッシュしてください。以前のリング更新デプロイメントをすべて削除し、swiftrings Ansible タグを使用して swift サービスのみを実行する新しい OpenStackDataPlaneDeployment CR を作成します。これにより、完全なデプロイメントを実行することなく、更新されたリングファイルがすべてのデータプレーンノードに配布されます。

   $ oc delete --ignore-not-found --wait openstackdataplanedeployment swift-ring-update -n openstack
   $ oc apply -n openstack -f - << EOF
   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: swift-ring-update
   spec:
     ansibleTags: swiftrings
     servicesOverride:
       - swift
     nodeSets:
       - <nodeset_name>
   EOF

   • <nodeset_name> をOpenStackDataPlaneNodeSet CR の名前に置き換えてください。

3. デプロイメントが完了するまで待ちます。

   $ oc wait openstackdataplanedeployment swift-ring-update --for condition=Ready --timeout=300s -n openstack

4. すべてのリングが整合しており、レプリケーションが進行していることを確認することで、クラスターの健全性を検証します。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -rT --md5'

   • すべてのリングの MD5 ハッシュ値がノード間で一貫していることを確認してください。
   • レプリケーションのタイムスタンプを確認してください。最も古い完了時刻から最も長いレプリケーション時刻を引いた値が、最後のレプリケーション処理の開始時刻の最も早い時刻になります。この開始時刻は、リングの ConfigMap が更新され、すべてのノードが新しいリングとの完全なレプリケーション処理を完了したことが確認された後でなければなりません。

5. または、オブジェクトレプリケーターの ログを直接確認して、完全なレプリケーション処理が完了したことを検証することもできます。

   $ oc logs --timestamps -l component=swift-storage -c object-replicator --tail 1000 | grep replicated

   レプリケーション処理の完了を示すログエントリーを探してください。例:

   $ oc logs --timestamps -c object-replicator swift-storage-0
   2026-04-02T10:44:13.863401909Z object-replicator: Object replication complete.  (33.00 minutes)

   完了タイムスタンプから所要時間を引いたものが、パスの開始時刻になります。たとえば、完了時刻が 10:44:13 で所要時間が 33.00 分 の場合、パスの開始時刻は 10:11:13 となります。この開始時刻は、リングの ConfigMap が更新された後でなければなりません。ConfigMap の更新前に処理が開始された場合、古いリングが使用されているため、次の完全な処理が完了するまで待つ必要があります。

6. swift-dispersion-report を 実行して、すべてのレプリカが正しく配置されていることを確認してください。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-report'

   出力には、すべてのレプリカが見つかったオブジェクトとコンテナーの割合が表示されます。次のリバランスを実行する前に、すべての値が 100% になっている必要があります。

手順

1. コントローラーノードのいずれかにログインします。

2. 以下のコマンドを実行します。

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -arqlT --md5'

   • (オプション) --all オプションを使用して、追加の出力を返します。

     このコマンドは、リング上のすべてのサーバーに対して、以下のデータのクエリーを実行します。

     • Async pendings: クラスターの負荷が非常に高くプロセスがデータベースファイルを十分な速度で更新できない場合、一部の更新は非同期で行われます。これらの数は徐々に減少します。
     • Replication metrics: レプリケーションのタイムスタンプを確認します。完全なレプリケーションパスは頻繁に行われ、エラーはほとんど発生しません。古いエントリー (例: 6 カ月前のタイムスタンプを持つエントリー) ば、そのノードでのレプリケーションが過去 6 カ月間完了していないことを意味します。
     • Ring md5sums: これにより、すべてのノードですべてのリングファイルの一貫性が確保されます。
     • swift.conf md5sums: これにより、すべてのノードですべての設定ファイルの一貫性が確保されます。
     • Quarantined files: すべてのノードについて、隔離されたファイルがない (あるいは、ほとんどない) はずです。
     • Time-sync: すべてのノードが同期されている必要があります。

手順

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

   $ oc rsh -n openstack openstackclient

2. 共有タイプを作成するには、次のコマンドを実行します。

   $ openstack share type create default <driver_handles_share_servers>

   • <driver_handles_share_servers> を true または false に置き換えます。

3. デフォルトの共有タイプに仕様を追加するか、別のバックエンドで使用する追加の共有タイプを作成します。この例では、CephFS バックエンドを選択するようにデフォルトの共有タイプを設定します。また、NetApp driver_handles_share_servers=true バックエンドを使用する追加の共有タイプを設定します。

   $ openstack share type create default false \
     --extra-specs share_backend_name='cephfs'
   $ openstack share type create netapp true \
     --extra-specs share_backend_name='netapp_ontap'

4. openstackclient Pod を終了します。

   $ exit

手順

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

   $ oc rsh -n openstack openstackclient

2. ファイル共有を管理します。

   $ openstack share adopt
       --name <name>
       --description <description>
       --share-type <share_type>
       --driver-options [<key=value> [<key=value> ...]]
                           [--public] [--share-server-id <share_server_id>] \
                           [--wait] <service_host> <protocol> <export_path>

   • <name> を、わかりやすい共有名に置き換えます。
   • <description> を、共有の説明に置き換えます。
   • <share_type> を、共有の共有タイプに置き換えます。
   • <key=value> を、共有に関連付けるドライバープロパティーのキーと値のペアに置き換えます。イメージに関連付けるキーと値のペアは複数使用できます。
   • <share_server_id> を、共有サーバーの ID に置き換えます。
   • <service_host> を、ホストサーバーに置き換えます。
   • <protocol> を、共有の NAS プロトコル (例: nfs) に置き換えます。
   • <export_path> を、共有のエクスポートパスに置き換えます。

3. 共有が利用可能であることを確認します。

   $ openstack share show <name>

4. ファイル共有の管理を解除します。

   $ openstack share abandon [--wait] <name>

5. openstackclient Pod を終了します。

   $ exit

手順

1. OpenStackControlPlane CR ファイル (openstack_control_plane.yaml) を開き、manila テンプレートに notificationsBus パラメーターを追加して、トランスポート URL を要求する際に使用する RabbitMQ クラスター名を指定します。

   注記

   notificationsBusInstance パラメーターは非推奨です。notificationsBusInstance を使用している既存のデプロイメントは、自動的に notificationsBus インターフェイスを使用するように移行されます。

   kind: OpenStackControlPlane
   spec:
     ...
     manila:
       template:
         ...
         notificationsBus:
           cluster: rabbitmq
         customServiceConfig: |
   ...

   通知を無効にするには、manila テンプレートから notificationsBus パラメーターを削除し、コントロールプレーンを更新してください。

2. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

3. Red Hat OpenShift Container Platform (RHOCP) が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。

   $ oc get openstackcontrolplane -n openstack

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

   ヒント

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