4.8. ボリュームサービスの設定
Block Storage サービス (cinder) には、ボリューム、スナップショット、およびグループに関連する操作を管理するボリュームサービス (cinderVolumes セクション) があります。これらの操作には、ボリュームの作成、削除、クローン作成、およびスナップショットの作成が含まれます。
このサービスには、OpenStackControlPlane CR の networkAttachments 内のストレージバックエンド (storage) およびストレージ管理 (storageMgmt) ネットワークへのアクセスが必要です。空のボリュームやスナップショットの作成をはじめとする一部の操作では、ボリュームサービスとストレージバックエンド間でのデータ移動は必要ありません。しかし、ストレージバックエンド間のデータ移行など、ボリュームサービスを通過してデータを渡す必要がある操作の場合はアクセスが必要です。
ボリュームサービスの設定は、customServiceConfig、customServiceConfigSecrets、networkAttachments、replicas、および nodeSelector セクションで設定されたパラメーターを使用して cinderVolumes セクションで実行されます。
ボリュームサービスは複数のレプリカを持てません。
手順
-
OpenStackControlPlaneCR ファイルであるopenstack_control_plane.yamlを開きます。 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 サービスのパラメーター を参照してください。
-
- ファイルを保存します。
コントロールプレーンを更新します。
$ oc apply -f openstack_control_plane.yaml -n openstackRHOCP が
OpenStackControlPlaneCR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。$ oc get openstackcontrolplane -n openstackステータスが "Setup complete" であれば、
OpenStackControlPlaneリソースが作成されています。ヒントデプロイの進行状況を追跡するには、
getコマンドの末尾に-wオプションを追加します。
4.8.1. Volume サービスのパラメーター リンクのコピーリンクがクリップボードにコピーされました!
Volume サービスのパラメーターは、Block Storage サービスの cinderVolumes 部分を設定するために提供されています。
| パラメーター | 説明 |
|---|---|
|
|
バックエンドのアベイラビリティーゾーンを設定します。これは |
|
| 特定のドライバー実装のバックエンド名を設定します。デフォルト値はありません。 |
|
| ボリューム作成に使用するドライバーを設定します。特定のクラスの Python namespace の形式で指定されます。デフォルト値はありません。 |
|
|
使用するバックエンド名のリストを設定します。これらのバックエンド名は、一意の [CONFIG] グループとそのオプションでバックアップされる必要があります。これはコンマで区切られた値のリストです。デフォルト値は、 |
|
|
イメージ変換中の位置時保存場所に使用するディレクトリーを設定します。デフォルト値は |
|
|
ストレージバックエンドからの使用状況の統計情報を取得するためのボリュームリクエスト間の間隔 (秒数)。デフォルトは |
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