2.2. Block Storage サービスの管理
以下の手順で、Block Storage サービスをニーズに合わせて設定する方法を説明します。以下の手順はすべて管理者権限が必要です。
Block Storage サービス (cinder) およびファイバーチャネル (FC) バックエンドを使用するすべてのデプロイメントにおいて、すべてのコントローラーノードおよびコンピュートノードにホストバスアダプター (HBA) をインストールする必要があります。
2.2.1. 高可用性のためのアクティブ/アクティブデプロイメント
- 重要
- アクティブ/アクティブモードは、エッジサイトの分散コンピュートノード (DCN) アーキテクチャーでのみサポートされます。
アクティブ/パッシブモードでは、Block Storage サービスがハイパーコンバージドデプロイメントで失敗した場合、ノードのフェンシングは望ましくありません。これは、ノードのフェンシングがトリガーとなり、不要なストレージのリバランスが行われる場合があるためです。Pacemaker は制御サイトに存在しますが、エッジサイトは Pacemaker をデプロイしません。その代わりに、エッジサイトは、高可用性ハイパーコンバージドデプロイメントをサポートするために、アクティブ/アクティブ設定の Block Storage サービスをデプロイします。
アクティブ/アクティブのデプロイメントでは、利用可能なすべてのノードに負荷をバランスさせることにより、スケーリング機能およびパフォーマンスが向上し、応答時間が短縮されます。アクティブ/アクティブ設定の Block Storage サービスをデプロイすると高可用性環境が構築され、ネットワークの部分的な障害や単一または複数ノードでのハードウェア異常が発生している間に管理レイヤーが維持されます。アクティブ/アクティブのデプロイメントにより、クラスターはノードに障害が発生している間 Block Storage サービスの提供を続けることができます。
ただし、アクティブ/アクティブのデプロイメントでは、ワークフローが自動的に再開することはありません。サービスが停止すると、障害が発生したノードで実行中の個々の操作も、障害が発生している間は実施に失敗します。この場合は、サービスが停止していることを確認し、インフライトの操作に提供されていたリソースのクリーンアップを開始します。
2.2.1.1. 高可用性のためのアクティブ/アクティブ設定の有効化
cinder-volume-active-active.yaml
ファイルを使用すると、アクティブ/アクティブ設定で Block Storage サービスをデプロイすることができます。このファイルにより、director は Pacemaker 以外の cinder-volume heat テンプレートを使用し、etcd
サービスを分散ロックマネージャー (DLM) としてデプロイメントに追加するようになります。
cinder-volume-active-active.yaml
ファイルの CinderVolumeCluster
パラメーターに値を割り当てて、アクティブ/アクティブ設定のクラスターの名前も定義します。CinderVolumeCluster
は、Block Storage のグローバルパラメーターです。したがって、同じデプロイメントにクラスター化した (アクティブ/アクティブ) バックエンドとクラスター化していないバックエンドを含めることはできません。
現在、アクティブ/アクティブ設定の Block Storage は、Ceph RADOS Block Device (RBD) バックエンドでのみ機能します。複数のバックエンドを使用する場合、すべてのバックエンドがアクティブ/アクティブ設定をサポートする必要があります。アクティブ/アクティブ設定をサポートしないバックエンドがデプロイメントに含まれている場合には、そのバックエンドをストレージに使用することはできません。アクティブ/アクティブのデプロイメントでは、アクティブ/アクティブ設定をサポートしないバックエンドにデータを保存した場合、データ損失の危険性があります。
手順
アクティブ/アクティブ設定の Block Storage サービスのボリュームを有効にするには、オーバークラウドのデプロイメントに以下の環境ファイルを追加します。
-e /usr/share/openstack-tripleo-heat-templates/environments/cinder-volume-active-active.yaml
2.2.1.2. アクティブ/アクティブ設定のメンテナンスコマンド
API バージョン 3.17 以降を使用している場合、アクティブ/アクティブ設定のデプロイ後に、さまざまなコマンドを使用して環境と対話することができます。
ユーザーのアクション | コマンド |
クラスター名、ホスト、ゾーン、ステータス、状態、無効にした理由、およびバックエンドの状態などの情報を含む、サービスのリストを表示する。
注記: Ceph バックエンド用に director によりデプロイされた場合、デフォルトのクラスター名は |
|
個別サービスではなく、クラスター全体についての詳細および概要情報を表示する。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
特定クラスターについての詳細情報を表示する。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
無効にしたサービスを有効にする。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
クラスター化したサービスを無効にする。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
2.2.1.3. ボリュームの管理と管理解除
管理解除および管理のメカニズムにより、バージョン X を使用するあるサービスからバージョン X+1 を使用する別のサービスに、ボリュームを容易に移行することができます。このプロセス中、どちらのサービスも稼働を続けます。
API バージョン 3.17 以降では、Block Storage クラスター内の管理に使用できるボリュームおよびスナップショットのリストを確認することができます。これらのリストを表示するには、cinder manageable-list
または cinder snapshot-manageable-list
で --cluster
引数を使用します。
API バージョン 3.16 以降では、cinder manage
コマンドにもオプションの --cluster
引数を指定できるので、以前に管理解除したボリュームを Block Storage クラスターに追加することができます。
2.2.1.4. クラスター化したサービスでのボリュームの移行
API バージョン 3.16 以降を使用すると、cinder migrate
および cinder-manage
コマンドに --cluster
引数を指定して、アクティブ/アクティブデプロイメントのデプロイ先を定義することができます。
Block Storage クラスター化サービスのボリュームを移行する場合、オプションの --cluster
引数を渡し、位置に関する host
引数を省略します。これは、引数が互いに排他的であるためです。
2.2.1.5. サーバーメンテナンスの開始
すべての Block Storage ボリュームサービスは、起動時に独自のメンテナンスを実行します。複数のボリュームサービスがクラスターにグループ化されている環境では、現在実行されていないサービスをクリーンアップすることができます。
コマンド work-cleanup
により、サーバーのクリーンアップがトリガーされます。このコマンドは以下の出力を返します。
- コマンドでクリーンアップすることのできるサービスのリスト
- 現在クラスター内で実行されていないため、コマンドでクリーンアップすることのできないサービスのリスト
work-cleanup
コマンドは、API バージョン 3.24 以降を実行しているサーバーでのみ機能します。
手順
以下のコマンドを実行して、クラスターのすべてのサービスが実行中かどうかを確認します。
$ cinder cluster-list --detailed
あるいは、
cluster show
コマンドを実行します。いずれかのサービスが実行されていない場合は、以下のコマンドを実行してそのサービスを特定します。
$ cinder service-list
以下のコマンドを実行してサーバーのクリーンアップを開始します。
$ cinder work-cleanup [--cluster <cluster-name>] [--host <hostname>] [--binary <binary>] [--is-up <True|true|False|false>] [--disabled <True|true|False|false>] [--resource-id <resource-id>] [--resource-type <Volume|Snapshot>]
注記--cluster
、--host
、--binary
等のフィルターで、コマンドでクリーンアップする対象を定義します。特定のリソースを含め、クラスター名、ホスト名、サービスの種別、およびリソースの種別で絞り込むことができます。フィルターを適用しない場合、コマンドはクリーンアップ可能なすべてを対象に処理を試みます。クラスター名で絞り込む例を以下に示します。
$ cinder work-cleanup --cluster tripleo@tripleo_ceph
2.2.2. グループボリューム設定とボリューム種別
Red Hat OpenStack Platform では、ボリューム種別を作成することができ、関連する設定をボリューム種別に適用することができます。ボリュームの作成時に設定を適用することができます。ボリュームの作成 を参照してください。ボリュームの作成後に設定を適用することもできます。ボリューム種別の変更 を参照してください。ボリューム種別に適用することができる関連設定の一部を、リストにして以下に示します。
- ボリュームの暗号化。詳細は、Dashboard を使用したボリューム種別の暗号化設定 参照してください。
- ボリュームが使用するバックエンド。詳細は、ボリュームを作成するバックエンドの指定 および ボリュームの移行 を参照してください。
- Quality-of-Service (QoS) スペック
設定は、追加スペックと呼ばれるキーと値のペアを使用してボリューム種別に関連付けられます。ボリュームの作成時にボリューム種別を指定する際には、Block Storage のスケジューラーがこれらのキーと値のペアを設定として適用します。また、複数のキーと値のペアを同じボリューム種別に関連付けることができます。
ボリューム種別は、異なるユーザーにストレージ階層を使用できるようにする機能をします。特定のパフォーマンス、耐障害性、およびその他の設定をキーと値のペアとしてボリューム種別に関連付けることにより、階層固有の設定を異なるボリューム種別にマッピングすることができます。マッピングされた階層固有の設定は、ボリュームの作成時に対応するボリューム種別を指定することによって適用が可能です。
2.2.2.1. ホストドライバーの機能のリスト表示
利用可能な追加スペックやサポートされている追加スペックは、バックエンドのドライバーにより異なります。有効な追加スペックのリストについては、ボリュームドライバーのマニュアルを参照してください。
または、Block Storage ホストに直接クエリーを送信して、そのドライバーがサポートしている、明確に定義された標準の追加スペックを確認することができます。まず、コマンドラインから Block Storage サービスをホストするノードにログインします。次に、以下のコマンドを実行します。
# cinder service-list
このコマンドは、各 Block Storage サービス (cinder-backup、cinder-scheduler、および cinder-volume) のホストが含まれるリストを返します。以下に例を示します。
+------------------+---------------------------+------+--------- | Binary | Host | Zone | Status ... +------------------+---------------------------+------+--------- | cinder-backup | localhost.localdomain | nova | enabled ... | cinder-scheduler | localhost.localdomain | nova | enabled ... | cinder-volume | *localhost.localdomain@lvm* | nova | enabled ... +------------------+---------------------------+------+---------
Block Storage サービスのドライバーの機能を表示するには (これによりサポートされる追加スペックを判断)、以下のコマンドを実行します。
# cinder get-capabilities _VOLSVCHOST_
VOLSVCHOST は cinder-volume のホストの完全な名前に置き換えます。以下に例を示します。
# cinder get-capabilities localhost.localdomain@lvm +---------------------+-----------------------------------------+ | Volume stats | Value | +---------------------+-----------------------------------------+ | description | None | | display_name | None | | driver_version | 3.0.0 | | namespace | OS::Storage::Capabilities::localhost.loc... | pool_name | None | | storage_protocol | iSCSI | | vendor_name | Open Source | | visibility | None | | volume_backend_name | lvm | +---------------------+-----------------------------------------+ +--------------------+------------------------------------------+ | Backend properties | Value | +--------------------+------------------------------------------+ | compression | {u'type': u'boolean', u'description'... | qos | {u'type': u'boolean', u'des ... | replication | {u'type': u'boolean', u'description'... | thin_provisioning | {u'type': u'boolean', u'description': u'S... +--------------------+------------------------------------------+
Backend properties のコラムには設定可能な追加スペックキーのリストが、Value のコラムには、Backend properties に対する有効な値が表示されます。
2.2.2.2. ボリューム種別の作成と設定
- Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- ボリューム種別の作成 をクリックします。
- Name フィールドにボリューム種別の名前を入力します。
- Create Volume Type をクリックします。Volume Types の表に新しい種別が表示されます。
- ボリューム種別の View Extra Specs のアクションを選択します。
- Create をクリックして Key と Value を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時にそのボリューム種別を指定するとエラーが発生してしまいます。
- Create をクリックします。関連付けられた設定 (キー/値のペア) が 追加スペック の表に表示されます。
デフォルトでは、OpenStack の全テナントがすべてのボリューム種別にアクセス可能です。アクセスが制限されたボリューム種別を作成する必要がある場合は、CLI から作成する必要があります。その方法は、「プライベートのボリューム種別の作成と設定」を参照してください。
QoS スペックをボリューム種別に関連付けることも可能です。詳細は、「QoS スペックとボリューム種別の関連付け」 を参照してください。
2.2.2.3. ボリューム種別の編集
- Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- ボリューム種別 の表で、ボリューム種別の 追加スペックの表示 のアクションを選択します。
このページの 追加スペック の表では、以下のような操作を行うことができます。
- ボリューム種別への新規設定の追加。そのためには、作成 をクリックして、ボリューム種別に関連付ける新規設定のキー/値ペアを指定します。
- ボリューム種別に関連付けられている既存の設定の編集。そのためには、設定の 編集 アクションを選択します。
- ボリューム種別に関連付けられている既存の設定の削除。そのためには、追加スペックのチェックボックスを選択して、表示中のダイアログ画面と次の画面で 追加スペックの削除 をクリックします。
2.2.2.4. ボリューム種別の削除
ボリューム種別を削除するには、ボリューム種別 の表でそのボリューム種別のチェックボックスを選択して ボリューム種別の削除 をクリックします。
2.2.2.5. プライベートのボリューム種別の作成と設定
デフォルトでは、全テナントですべてのボリューム種別を使用することができます。アクセスが制限されたボリューム種別を作成するには、ボリューム種別を プライベート に指定します。そのためには、ボリューム種別の is-public
フラグを false に設定します。
プライベートのボリューム種別は、特定の属性を持つボリュームへのアクセスを制限するのに役立ちます。これは通常は、特定のテナントのみが使用可能とする必要のある設定です。たとえば、テスト中の新規バックエンドや超ハイパフォーマンスの設定などが例としてあげられます。
プライベートのボリューム種別を作成するには、以下のコマンドを実行します。
$ cinder type-create --is-public false <TYPE-NAME>
デフォルトでは、プライベートのボリューム種別には作成者のみがアクセスできます。ただし、管理ユーザーは、以下のコマンドを使用してプライベートボリューム種別を特定/表示することができます。
$ cinder type-list --all
このコマンドは、パブリックとプライベートの両方のボリューム種別をリスト表示します。リストには、各ボリューム種別の名前と ID も表示されます。ボリューム種別にアクセスするには、そのボリューム種別の ID が必要となります。
プライベートのボリューム種別へのアクセスは、テナントレベルで許可されます。テナントがプライベートのボリューム種別にアクセスできるようにするには、以下のコマンドを実行します。
$ cinder type-access-add --volume-type <TYPE-ID> --project-id <TENANT-ID>
プライベートのボリューム種別にアクセス可能なテナントを確認するには、以下のコマンドを実行します。
$ cinder type-access-list --volume-type <TYPE-ID>
プライベートのボリューム種別のアクセスリストからテナントを削除するには、以下のコマンドを実行します。
$ cinder type-access-remove --volume-type <TYPE-ID> --project-id <TENANT-ID>
プライベートのボリューム種別へのアクセスは、デフォルトでは管理権限のあるユーザーのみが作成、表示、設定することが可能です。
2.2.3. Block Storage サービスの内部テナントの作成および設定
Block Storage 機能の一部 (例: Image-Volume キャッシュ) では、内部テナントの設定を必要とします。Block Storage サービスは、このテナント (またはプロジェクト) を使用して、通常のユーザーに公開する必要のないブロックストレージアイテムを管理します。このようなアイテムの例として、ボリュームの頻繁なクローン作成のためにキャッシュされたイメージや、移行中のボリュームの一時コピーなどが挙げられます。
内部プロジェクトを設定するには、まず cinder-internal という名前の一般プロジェクトとユーザーを作成します。そのためには、コントローラーノードにログインして以下のコマンドを実行します。
# openstack project create --enable --description "Block Storage Internal Tenant" cinder-internal +-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Block Storage Internal Tenant | | enabled | True | | id | cb91e1fe446a45628bb2b139d7dccaef | | name | cinder-internal | +-------------+----------------------------------+ # openstack user create --project cinder-internal cinder-internal +----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | None | | enabled | True | | id | 84e9672c64f041d6bfa7a930f558d946 | | name | cinder-internal | |project_id| cb91e1fe446a45628bb2b139d7dccaef | | username | cinder-internal | +----------+----------------------------------+
新たな設定オプションを追加する手順により、内部テナントが作成されます。詳細は、「Image-Volume キャッシュの設定および有効化」 を参照してください。
2.2.4. Image-Volume キャッシュの設定および有効化
Block Storage サービスには、任意の Image-Volume キャッシュ が含まれており、イメージからボリュームを作成する際にこのキャッシュを使用できます。このキャッシュは、頻繁に使用するイメージからボリュームを作成する際の時間を短縮するように設計されています。イメージからボリュームを作成する方法は、「ボリュームの作成」を参照してください。
Image-Volume のキャッシュを有効化すると、ボリュームの初回作成時にベースとなったイメージのコピーが保存されます。この保存されたイメージは、Block Storage バックエンドのローカルにキャッシュされ、次回このイメージを使用してボリュームを作成する際のパフォーマンス向上に役立ちます。Image-Volume キャッシュは、サイズ (GB)、イメージ数、または両方を指定して上限を設定することができます。
Image-Volume キャッシュは、複数のバックエンドでサポートされます。サードパーティーのバックエンドを使用する場合は、Image-Volume キャッシュサポートに関する情報については、サードパーティーのドキュメントを参照してください。
Image-Volume キャッシュでは、内部テナント を Block Storage サービスに設定する必要があります。手順は、「Block Storage サービスの内部テナントの作成および設定」を参照してください。
バックエンド (BACKEND) で Image-Volume キャッシュを有効にして設定するには、アンダークラウドの環境ファイルの ExtraConfig
セクションに値を追加します。以下に例を示します。
parameter_defaults: ExtraConfig: cinder::config::cinder_config: DEFAULT/cinder_internal_tenant_project_id: value: TENANTID DEFAULT/cinder_internal_tenant_user_id: value: USERID BACKEND/image_volume_cache_enabled: 1 value: True BACKEND/image_volume_cache_max_size_gb: value: MAXSIZE 2 BACKEND/image_volume_cache_max_count: value: MAXNUMBER 3
Block Storage サービスのデータベースは、タイムスタンプを使用して、キャッシュされた各イメージの最終使用日時をトラッキングします。MAXSIZE と MAXNUMBER のいずれか一方または両方が設定されている場合は、Block Storage サービスは必要に応じてキャッシュされたイメージを削除し、新たにイメージをキャッシュするためのスペースを解放します。Image-Volume キャッシュが上限に達すると、最も古いタイムスタンプが付いたキャッシュイメージが最初に削除されます。
/home/stack/templates/
に環境ファイルを作成したら、stack ユーザーとしてログインして、以下のコマンドを実行して設定をデプロイします。
$ openstack overcloud deploy --templates \ -e /home/stack/templates/<ENV_FILE>.yaml
ここで、ENV_FILE.yaml
は、前のステップで ExtraConfig
設定を追加したファイルの名前です。
オーバークラウドの作成時に追加の環境ファイルを渡した場合は、予定外の変更がオーバークラウドに加えられないように、ここで -e
オプションを使用して環境ファイルを再度渡します。
openstack overcloud deploy コマンドについての詳しい情報は、director のインストールと使用方法の デプロイメントコマンド を参照してください。
2.2.5. Quality-of-Service スペックの使用
複数のパフォーマンス設定を単一の Quality-of-Service の仕様 (QoS スペック) にマッピングすることができます。これにより、ユーザータイプ別のパフォーマンス階層を提供することができます。
パフォーマンス設定はキーと値のペアとして QoS スペックにマッピングされます。これは、ボリュームの設定がボリューム種別に関連付けられる方法と似ています。ただし、QoS スペックの場合は以下の面でボリューム種別の場合とは異なります。
QoS スペックは、ディスクの読み取り/書き込み操作を制限するなどのパフォーマンス設定を適用するのに使用されます。利用可能かつサポートされているパフォーマンス設定はストレージドライバーによって異なります。
バックエンドがサポートしている QoS スペックを確認するには、そのバックエンドデバイスのボリュームドライバーのマニュアルを参照してください。
- QoS スペックとは異なり、ボリューム種別はボリュームに直接適用されます。QoS スペックは、ボリューム種別に関連付けられます。また、ボリュームの作成時にボリューム種別を指定すると、そのボリューム種別に関連付けられた QoS スペックにマッピングされたパフォーマンス設定も適用されます。
2.2.5.1. ボリュームの基本 Quality-of-Service
ボリュームの基本 QoS 値を使用して、ボリュームごとにボリュームのパフォーマンス制限を定義することができます。Block Storage サービスでは、以下のオプションがサポートされます。
-
read_iops_sec
-
write_iops_sec
-
total_iops_sec
-
read_bytes_sec
-
write_bytes_sec
-
total_bytes_sec
-
read_iops_sec_max
-
write_iops_sec_max
-
total_iops_sec_max
-
read_bytes_sec_max
-
write_bytes_sec_max
-
total_bytes_sec_max
-
size_iops_sec
2.2.5.2. QoS スペックの作成と設定
管理者は、QoS スペックの表で QoS スペックの作成および設定を行うことができます。同じ QoS スペックには、複数のキー/値のペアを関連付けることができます。
- Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- QoS スペック の表で QoS スペックの作成 をクリックします。
- QoS スペック の名前を入力します。
使用者 フィールドで、QoS ポリシーを適用する対象を指定します。
表2.1 使用者の種別 型 説明 back-end
QoS ポリシーが Block Storage バックエンドに適用されます。
front-end
QoS ポリシーが Compute に適用されます。
both
QoS ポリシーが Block Storage と Compute の両方に適用されます。
- Create をクリックします。新規 QoS スペックが QoS スペック の表に表示されるはずです。
- QoS スペック の表で、新規スペックの スペックの管理 アクションを選択します。
作成 をクリックして キー と 値 を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時に、この QoS スペックに関連付けられたボリューム種別を指定するとエラーが発生してしまいます。
たとえば、読み取りの IOPS 上限を
500
に設定するには、以下のキー/値のペアを使用します。read_iops_sec=500
- Create をクリックします。関連付けられた設定 (キー/値のペア) が キーと値のペア の表に表示されます。
2.2.5.3. 容量ベースの QoS 上限の設定
ボリュームの種別を使用して、容量ベースの Quality-of-Service (QoS) 上限をボリュームに実装することができます。これにより、プロビジョニングされるボリュームのサイズに基づいて、確定的な IOPS スループットを設定することができます。このように設定すると、ストレージリソースがユーザーにプロビジョニングされる方法が簡素化され、プロビジョニングされるボリュームのサイズに基づいて、事前に決定された (最終的には高度に予測可能な) スループット速度が提供されます。
特に、Block Storage サービスでは、実際にプロビジョニングされるサイズに基づいてボリュームに割り当てる IOPS を設定することができます。このスループットは、以下の QoS キーを使用して、1 GB あたりの IOPS で設定されます。
read_iops_sec_per_gb write_iops_sec_per_gb total_iops_sec_per_gb
これらのキーにより、プロビジョニングされるボリュームのサイズに応じてスケーリングするための読み取り、書き込み、IOPS 合計を設定することができます。たとえば、ボリューム種別に read_iops_sec_per_gb=500
を指定した場合には、プロビジョニングされる 3 GB のボリュームには、読み取り IOPS が 1500 に自動設定されます。
容量ベースの QoS 上限はボリューム種別ごとに設定され、通常の QoS スペックと同様に設定されます。また、これらの上限は配下の Block Storage サービスにより直接サポートされており、特定のドライバーに依存しません。
ボリューム種別に関する詳しい情報は、「グループボリューム設定とボリューム種別」および「ボリューム種別の作成と設定」を参照してください。QoS スペックの設定方法については、「Quality-of-Service スペックの使用」を参照してください。
容量ベースの QoS 上限を使用して、接続済みのボリュームにボリューム種別を適用した場合 (またはボリューム種別を変更した場合) には、上限は適用されません。この上限は、そのボリュームをインスタンスから接続解除した後にのみ適用されます。
ボリューム種別の変更に関する情報は、「ボリューム種別の変更」を参照してください。
2.2.5.4. QoS スペックとボリューム種別の関連付け
管理者は、ボリューム種別 の表で QoS スペックを既存のボリューム種別に関連付ける事ができます。
- Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
- 関連付ける QoS スペック のリストから QoS スペックを選択します。
- 割り当て をクリックします。選択した QoS スペックが、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されるようになります。
2.2.5.5. ボリューム種別からの QoS スペックの関連付け解除
- Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
- 関連付ける QoS スペックのリストから なし を選択します。
- 割り当て をクリックします。選択した QoS スペックは、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されなくなります。
2.2.6. ボリュームの暗号化設定
ボリュームの暗号化は、ボリュームのバックエンドのセキュリティーが侵害されたり、盗難されたりした場合に、基本的なデータ保護を提供します。Compute および Block Storage サービスを両方統合して、インスタンスがアクセスを読み込み、暗号化されたボリュームを使用できるようにします。ボリュームの暗号化を使用するには、Key Manager サービス (barbican) をデプロイする必要があります。
- ボリュームの暗号化は、ファイルベースのボリューム (例: NFS) ではサポートされていません。
- 暗号化されていないボリュームを同じサイズの暗号化されたボリュームに種別変更する操作はサポートされません。暗号化したボリュームには、暗号化データを格納するための追加領域が必要なためです。暗号化されていないボリュームの暗号化に関する詳細は、暗号化されていないボリュームの暗号化 を参照してください。
ボリュームの暗号化は、ボリューム種別を使用して適用されます。暗号化されたボリューム種別に関する情報は、「Dashboard を使用したボリューム種別の暗号化設定」を参照してください。
2.2.6.1. Dashboard を使用したボリューム種別の暗号化設定
暗号化されたボリュームを作成するには、まず 暗号化されたボリューム種別 が必要です。ボリューム種別を暗号化するには、使用すべきプロバイダークラス、暗号、キーサイズを設定する必要があります。
- Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
- 暗号化するボリューム種別の アクション コラムで 暗号化設定の作成 を選択して、ボリューム種別の暗号化設定の作成 ウィザードを開きます。
このウィザードで、ボリューム種別の暗号化の プロバイダー、制御場所、暗号、および キーサイズ を設定します。説明 のコラムで各設定について説明されています。
重要プロバイダー、暗号、および キーサイズ のオプションとしてサポートされるは、以下に示す値だけです。
-
プロバイダー に
luks
と入力します。 -
暗号 に
aes-xts-plain64
と入力します。 -
キーサイズ に
256
と入力します。
-
プロバイダー に
- ボリューム種別の暗号化設定の作成 をクリックします。
ボリューム種別の暗号化設定が完了したら、その設定を使用して、暗号化されたボリュームを自動的に作成することができます。ボリューム種別の作成に関する詳しい情報は、「ボリューム種別の作成と設定」を参照してください。具体的には、ボリュームの作成 ウィンドウの 種別 のドロップダウンから暗号化されたボリューム種別を選択します (「ボリュームの基本的な使用方法と設定」を参照)。
CLI を使用して暗号化されたボリューム種別を設定するには、「CLI を使用したボリューム種別の暗号化設定」を参照してください。
暗号化されたボリューム種別の暗号化設定を再設定することも可能です。
- ボリューム種別の アクション コラムから 暗号化設定の更新 を選択して、ボリューム種別の暗号化設定の更新 ウィザードを開きます。
- ボリュームが暗号化されているかどうかを判断するには、プロジェクト > コンピュート > ボリューム にある ボリューム テーブルの 暗号化 コラムを確認します。
- ボリュームが暗号化されている場合には、暗号化のコラムの はい をクリックすると暗号化設定が表示されます。
2.2.6.2. CLI を使用したボリューム種別の暗号化設定
Block Storage ボリュームの暗号化を設定するには、以下の手順を実施します。
ボリューム種別を作成します。
$ cinder type-create encrypt-type
暗号、キーサイズ、制御場所、およびプロバイダー設定を定義します。
$ cinder encryption-type-create --cipher aes-xts-plain64 --key-size 256 --control-location front-end encrypt-type luks
暗号化されたボリュームを作成します。
$ cinder --debug create 1 --volume-type encrypt-type --name DemoEncVol
2.2.6.3. ボリュームイメージ暗号化キーの自動削除
Block Storage サービス (cinder) が暗号化されたボリュームを Image サービス (glance) にアップロードする際に、Key Management サービス (barbican) に暗号鍵を作成します。これにより、暗号鍵と保存されるイメージに 1 対 1 の関係が形成されます。
暗号鍵を削除することで、Key Management サービスがリソースを無制限に消費するのを防ぐことができます。Block Storage サービス、Key Management サービス、および Image サービスは、暗号化されたボリュームの鍵を自動的に管理します。これには、鍵の削除が含まれます。
Block Storage サービスは、自動的に 2 つの属性をボリュームイメージに追加します。
-
cinder_encryption_key_id
: Key Management サービスが特定のイメージ用に保存する暗号鍵の識別子 -
cinder_encryption_key_deletion_policy
: Image サービスはこのポリシーにしたがって、このイメージに関連付けられた鍵を削除するかどうかを Key Management サービスに指示します。
これらの属性の値は、自動的に割り当てられます。意図しないデータ損失を避けるため、これらの値を調整しないでください。
ボリュームイメージを作成すると、Block Storage サービスは cinder_encryption_key_deletion_policy
属性を on_image_deletion
に設定します。cinder_encryption_key_deletion_policy
が on_image_deletion
に設定されている場合、ボリュームイメージを削除すると、Image サービスは対応する暗号鍵を削除します。
Red Hat では、cinder_encryption_key_id
または cinder_encryption_key_deletion_policy
属性を手動で操作することを推奨しません。cinder_encryption_key_id
の値で識別される暗号鍵を他の目的で使用すると、データが失われる危険性があります。
詳しい情報は、Manage Secret with the OpenStack Key Manager を参照してください。
2.2.7. ボリュームを複数のバックエンドに割り当てる方法の設定
Block Storage サービスが複数のバックエンドを使用するように設定されている場合には、設定済みのボリューム種別を使用して、ボリュームの作成先を指定することができます。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。
ボリュームの作成時にバックエンドを指定していない場合には、Block Storage サービスにより、自動的に選択されます。Block Storage は、最初に定義したバックエンドをデフォルトとして設定します。このバックエンドは、容量がなくなるまで使用されます。容量がなくなった時点で、Block Storage は 2 番目に定義されたバックエンドをデフォルトに設定し、その容量がなくなるとさらに次のバックエンドがデフォルトに設定されるようになっています。
このメカニズムが必要な条件を満たさない場合には、フィルタースケジューラーを使用して、Block Storage がバックエンドを選択する方法を制御することができます。このスケジューラーは、以下の例に示したような異なるフィルターを使用して適切なバックエンドをトリアージすることができます。
- AvailabilityZoneFilter
- 要求されたボリュームのアベイラビリティーゾーン要件を満たさないバックエンドを除外します。
- CapacityFilter
- ボリュームを収容するのに十分な容量のあるバックエンドのみを選択します。
- CapabilitiesFilter
- ボリュームで指定した設定に対応可能なバックエンドのみを選択します。
- InstanceLocality
- クラスターが、同じノードに対してローカルのボリュームを使用するように設定します。
フィルタースケジューラーを設定するには、以下の内容を記載した環境ファイルをデプロイメントに追加します。
parameter_defaults: ControllerExtraConfig: # 1 cinder::config::cinder_config: DEFAULT/scheduler_default_filters: value: 'AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter,InstanceLocality'
- 1
ControllerExtraConfig:
フックとそのネストされているセクションを、既存の環境ファイルのparameter_defaults:
セクションに追加することもできます。
2.2.8. アベイラビリティーゾーンのデプロイ
アベイラビリティーゾーンは、クラウドインスタンスおよびサービスをグループ化するためのプロバイダー固有の方法です。director は CinderXXXAvailabilityZone
パラメーターを使用して、Block Storage ボリュームのバックエンドごとに異なるアベイラビリティーゾーンを設定します (XXX
は特定のバックエンドに対応する値です)。
手順
Block Storage ボリュームのバックエンドごとに異なるアベイラビリティーゾーンをデプロイするには、以下の手順を実施します。
以下のパラメーターを環境ファイルに追加して、2 つのアベイラビリティーゾーンを作成します。
parameter_defaults: CinderXXXAvailabilityZone: zone1 CinderYYYAvailabilityZone: zone2
以下に示す例のように、XXX および YYY を、サポートされるバックエンドの値に置き換えます。
CinderISCSIAvailabilityZone CinderNfsAvailabilityZone CinderRbdAvailabilityZone
注記/usr/share/openstack-tripleo-heat-templates/deployment/cinder/
ディレクトリーでバックエンドに関連付けられた heat テンプレートを探し、正しいバックエンドの値を確認してください。2 つのバックエンドをデプロイする例を以下に示します。ここでは、
rbd
がゾーン 1 でiSCSI
がゾーン 2 です。parameter_defaults: CinderRbdAvailabilityZone: zone1 CinderISCSIAvailabilityZone: zone2
- 更新された環境ファイルを追加して、オーバークラウドをデプロイします。
2.2.9. 整合性グループの設定と使用
Block Storage (cinder) サービスを使用して、整合性グループを設定して複数のボリュームを単一のエンティティーとしてグループ化することができます。つまり、複数のボリュームに対して個別に操作を実行するのではなく、同時に複数のボリュームに対して操作を実行することができます。整合性グループを使用して、複数ボリュームのスナップショットを同時に作成することができます。また、これらのボリュームを同時にリストアまたはクローン作成することも可能です。
1 つのボリュームを複数の整合性グループのメンバーにすることができます。ただし、ボリュームを整合性グループに追加した後に、そのボリュームを削除、種別変更、移行することはできません。
2.2.9.1. 整合性グループの設定
デフォルトでは、整合性グループの API は Block Storage のセキュリティーポリシーにより無効にされています。この機能を使用するには、ここで有効にする必要があります。Block StorageAPI サービスをホストするノードの /etc/cinder/policy.json
ファイルの関連する整合性グループエントリー openstack-cinder-api
にデフォルト設定がリストされています。
"consistencygroup:create" : "group:nobody", "consistencygroup:delete": "group:nobody", "consistencygroup:update": "group:nobody", "consistencygroup:get": "group:nobody", "consistencygroup:get_all": "group:nobody", "consistencygroup:create_cgsnapshot" : "group:nobody", "consistencygroup:delete_cgsnapshot": "group:nobody", "consistencygroup:get_cgsnapshot": "group:nobody", "consistencygroup:get_all_cgsnapshots": "group:nobody",
環境ファイルでこれらの設定を変更してから、openstack overcloud deploy
コマンドを使用してオーバークラウドにデプロイする必要があります。JSON ファイルを直接編集しないでください。次回オーバークラウドがデプロイされる際に変更が上書きされてしまうためです。
手順
-
環境ファイルを編集し、
parameter_defaults
セクションに新しいエントリーを追加します。これにより、openstack overcloud deploy
コマンドを使用して環境が再デプロイされるたびに、エントリーがコンテナーで更新され保持されるようになります。 CinderApiPolicies
を使用して環境ファイルに新規セクションを追加し、整合性グループの設定を定義します。JSON ファイルのデフォルト設定を持つ同等のparameter_defaults
セクションは、次のように表示されます。parameter_defaults: CinderApiPolicies: { \ cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'group:nobody' }, \ cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'group:nobody' }, \ cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'group:nobody' }, \ cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'group:nobody' }, \ cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'group:nobody' }, \ cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'group:nobody' }, \ cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'group:nobody' }, \ cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'group:nobody' }, \ cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'group:nobody' }, \ }
-
値
'group:nobody'
は、この機能を使用できるグループがないことを決定するため、効果的に無効になります。これを有効にするには、グループを別の値に変更します。 セキュリティーを強化するためには、整合性グループの API とボリューム種別管理の API の両方に、同じアクセス権限を設定します。デフォルトでは、ボリューム種別管理の API は (同じ
/etc/cinder/policy.json_ file
) で"rule:admin_or_owner"
に設定されています。"volume_extension:types_manage": "rule:admin_or_owner",
整合性グループの機能をすべてのユーザーが利用できるようにするには、API ポリシーのエントリーを設定して、ユーザーが専用の整合性グループを作成、使用、および管理できるようにします。そのためには、
rule:admin_or_owner
を使用します。CinderApiPolicies: { \ cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'rule:admin_or_owner' }, \ cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'rule:admin_or_owner’ }, \ }
/home/stack/templates/
に環境ファイルを作成したら、スタックユーザーとしてログインし、設定をデプロイします。$ openstack overcloud deploy --templates \ -e /home/stack/templates/<ENV_FILE>.yaml
<ENV_FILE.yaml>
を、追加したExtraConfig
設定のファイル名に置き換えます。重要オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで
-e
オプションを使用して環境ファイルを再度渡します。
openstack overcloud deploy
コマンドの詳細については、 Director インストールおよび使用ガイドの CLI ツールを使用したオーバークラウドの作成 を参照してください。
2.2.9.2. 整合性グループの作成
整合性グループの API を有効にしたら、整合性グループの作成を開始することができます。
手順
- Dashboard で管理者ユーザーとして プロジェクト > コンピュート > ボリューム > ボリュームの整合性グループ を選択します。
- 整合性グループの作成 をクリックします。
- ウィザードの 整合性グループの情報 タブで、整合性グループの名前と説明を入力します。次に アベイラビリティーゾーン を指定します。
- 整合性グループにボリューム種別を追加することもできます。整合性グループにボリュームを作成する際には、Block Storage サービスにより、これらのボリューム種別から互換性のある設定が適用されます。ボリューム種別を追加するには、利用可能な全ボリューム種別 リストから追加するボリューム種別の + ボタンをクリックします。
- 整合性グループの作成 をクリックします。次回、作成した整合性グループが ボリュームの整合性グループ テーブルに表示されます。
2.2.9.3. 整合性グループの管理
手順
- (オプション) アクション コラムから 整合性グループの編集 を選択して、整合性グループの名前または説明を変更することができます。
- 整合性グループから直接にボリュームを追加または削除するには、Dashboard で管理者ユーザーとして プロジェクト > コンピュート > ボリューム > ボリュームの整合性グループ を選択します。
設定する整合性グループを特定します。その整合性グループの アクション コラムで、ボリュームの管理 を選択します。これにより、整合性グループボリュームの追加/削除 ウィザードが起動します。
- 整合性グループにボリュームを追加するには、利用可能な全ボリューム リストから追加するボリュームの + ボタンをクリックします。
- 整合性グループからボリュームを削除するには、選択済みのボリューム リストから削除するボリュームの - ボタンをクリックします。
- 整合性グループの編集 をクリックします。
2.2.9.4. 整合性グループのスナップショットの作成および管理
整合性グループにボリュームを追加したら、そこからスナップショットを作成することができます。
手順
openstack-cinder-api
をホストするノードのコマンドラインからadmin
ユーザーとしてログインし、次のように入力します。# export OS_VOLUME_API_VERSION=2
これにより、
openstack-cinder-api
のバージョン2
を使用するようにクライアントが設定されます。利用可能な整合性グループおよびその ID をすべて表示します。
# cinder consisgroup-list
整合性グループを使用してスナップショットを作成します。
# cinder cgsnapshot-create --name <CGSNAPNAME> --description "<DESCRIPTION>" <CGNAMEID>
以下を置き換えます。
-
<CGSNAPNAME>
とスナップショットの名前 (オプション)。 -
スナップショットの説明を含む
<DESCRIPTION>
(オプション)。 -
<CGNAMEID>
と整合性グループの名前または ID。
-
利用可能な整合性グループのスナップショットの全リストを表示します。
# cinder cgsnapshot-list
2.2.9.5. 整合性グループのクローン作成
整合性グループを使用して、事前に設定されたボリューム群を一括で同時に作成することもできます。この操作は、既存の整合性グループをクローンするか、整合性グループのスナップショットをリストアすることによって実行できます。いずれのプロセスも同じコマンドを使用します。
手順
既存の整合性グループのクローンを作成するには、以下のコマンドを実行します。
# cinder consisgroup-create-from-src --source-cg <CGNAMEID> --name <CGNAME> --description "<DESCRIPTION>"
以下を置き換えます。
-
<CGNAMEID>
は、複製する整合性グループの名前または ID です。 -
<CGNAME>
は、整合性グループの名前です (オプション)。 -
<DESCRIPTION>
は、整合性グループの説明です (オプション)。
-
整合性グループのスナップショットから整合性グループを作成するには、以下のコマンドを実行します。
# cinder consisgroup-create-from-src --cgsnapshot <CGSNAPNAME> --name <CGNAME> --description "<DESCRIPTION>
<CGSNAPNAME>
は、整合性グループの作成に使用するスナップショットの名前または ID に置き換えてください。