4.8. ボリュームサービスの設定


Block Storage サービス (cinder) には、ボリューム、スナップショット、およびグループに関連する操作を管理するボリュームサービス (cinderVolumes セクション) があります。これらの操作には、ボリュームの作成、削除、クローン作成、およびスナップショットの作成が含まれます。

このサービスには、OpenStackControlPlane CR の networkAttachments 内のストレージバックエンド (storage) およびストレージ管理 (storageMgmt) ネットワークへのアクセスが必要です。空のボリュームやスナップショットの作成をはじめとする一部の操作では、ボリュームサービスとストレージバックエンド間でのデータ移動は必要ありません。しかし、ストレージバックエンド間のデータ移行など、ボリュームサービスを通過してデータを渡す必要がある操作の場合はアクセスが必要です。

ボリュームサービスの設定は、customServiceConfigcustomServiceConfigSecretsnetworkAttachmentsreplicas、および nodeSelector セクションで設定されたパラメーターを使用して cinderVolumes セクションで実行されます。

ボリュームサービスは複数のレプリカを持てません。

手順

  1. OpenStackControlPlane CR ファイルである openstack_control_plane.yaml を開きます。
  2. CR ファイルを編集し、バックエンドの設定を追加します。

    次の例は、Red Hat Ceph Storage バックエンドのサービス設定を示しています。

    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    metadata:
      name: openstack
    spec:
      cinder:
        template:
          customServiceConfig: |
            [DEFAULT]
            debug = true
          cinderVolumes:
            ceph:
              networkAttachments:
              - storage
              customServiceConfig: |
                [ceph]
                volume_backend_name = ceph
                volume_driver = cinder.volume.drivers.rbd.RBDDriver
    • ceph: 個々のバックエンドの設定領域。各バックエンドには個別の設定領域が必要です。デフォルトではバックエンドはデプロイされません。デプロイ時に少なくとも 1 つのバックエンドが設定されていない限り、Block Storage サービスのボリュームサービスは実行されません。バックエンドの設定の詳細は、Block Storage サービス (cinder) バックエンド および 複数の Block Storage サービス (cinder) バックエンド を参照してください。
    • networkAttachments: バックエンドネットワーク接続の設定領域。
    • volume_backend_name: このバックエンドに割り当てられた名前。
    • volume_driver: このバックエンドに接続するために使用されるドライバー。

      よく使用されるボリュームサービスパラメーターのリストについては、Volume サービスのパラメーター を参照してください。

  3. ファイルを保存します。
  4. コントロールプレーンを更新します。

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

    $ oc get openstackcontrolplane -n openstack

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

    ヒント

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

4.8.1. Volume サービスのパラメーター

Volume サービスのパラメーターは、Block Storage サービスの cinderVolumes 部分を設定するために提供されています。

Expand
パラメーター説明

backend_availability_zone

バックエンドのアベイラビリティーゾーンを設定します。これは [DEFAULT] セクションで設定されます。デフォルト値は storage_availability_zone です。

volume_backend_name

特定のドライバー実装のバックエンド名を設定します。デフォルト値はありません。

volume_driver

ボリューム作成に使用するドライバーを設定します。特定のクラスの Python namespace の形式で指定されます。デフォルト値はありません。

enabled_backends

使用するバックエンド名のリストを設定します。これらのバックエンド名は、一意の [CONFIG] グループとそのオプションでバックアップされる必要があります。これはコンマで区切られた値のリストです。デフォルト値は、volume_backend_name オプションを持つセクションの名前です。

image_conversion_dir

イメージ変換中の位置時保存場所に使用するディレクトリーを設定します。デフォルト値は /var/lib/cinder/conversion です。

backend_stats_polling_interval

ストレージバックエンドからの使用状況の統計情報を取得するためのボリュームリクエスト間の間隔 (秒数)。デフォルトは 60 です。

4.8.2. Block Storage サービス (cinder) バックエンド

各 Block Storage サービスのバックエンドには、cinderVolumes セクションに個別の設定セクションが必要です。これにより、各バックエンドが専用 Pod で実行されるようになります。このアプローチには次の利点があります。

  • 分離を強化します。
  • 素早くバックエンドの追加および削除でき、実行中の他のバックエンドに影響を与えません。
  • 設定を変更しても、実行中の他のバックエンドに影響を与えません。
  • ボリューム Pod を別のノードに自動的に分散します。

Block Storage サービスの各バックエンドは、ストレージトランスポートプロトコルを使用してボリューム内のデータにアクセスします。トランスポートプロトコルの設定 で説明されているとおり、各ストレージトランスポートプロトコルにはそれぞれの要件があります。ストレージプロトコル情報は、各ベンダーのインストールガイドにも記載されているはずです。

注記

各バックエンドを独立した Pod で設定します。RHOSP のディレクターベースのリリースでは、すべてのバックエンドが単一の cinder-volume コンテナー内で実行されます。これはベストプラクティスではなくなりました。

デフォルトではバックエンドはデプロイされません。デプロイ時に少なくとも 1 つのバックエンドが設定されていない限り、Block Storage サービスのボリュームサービスは実行されません。

すべてのストレージベンダーは、ベストプラクティス、デプロイメント設定、ベンダードライバーの設定オプションを含むインストールガイドを提供しています。これらのインストールガイドには、デプロイメント用にボリュームサービスを適切に設定するために必要な特定の設定情報が記載されています。インストールガイドは Red Hat Ecosystem Catalog で入手できます。

ベンダードライバーの統合と認定の詳細は、パートナーコンテンツの統合 を参照してください。

Red Hat Ceph Storage バックエンド設定の詳細は、Red Hat Ceph Storage の統合 および ハイパーコンバージドインフラストラクチャー環境のデプロイ を参照してください。

汎用 (ベンダー固有ではない) NFS バックエンドの設定については、汎用 NFS バックエンドの設定 を参照してください。

注記

認定されたストレージバックエンドとドライバーを使用します。汎用 NFS バックエンドから提供される NFS ストレージを使用する場合、その機能は認定されたストレージバックエンドおよびドライバーと比較して制限されます。

4.8.3. 複数の Block Storage サービス (cinder) バックエンド

複数の Block Storage サービスバックエンドは、cinderVolumes 設定セクションに複数の独立したエントリーを追加することでデプロイされます。各バックエンドは独立した Pod で実行されます。

次の設定例では、iSCSI 用と NFS 用の 2 つの独立したバックエンドをデプロイします。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderVolumes:
        nfs:
          networkAttachments:
          - storage
          customServiceConfigSecrets:
          - cinder-volume-nfs-secrets
          customServiceConfig: |
        	[nfs]
        	volume_backend_name=nfs
        iSCSI:
          networkAttachments:
          - storage
          - storageMgmt
          customServiceConfig: |
        	[iscsi]
        	volume_backend_name=iscsi
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る