第2章 Block Storage とボリューム

利用可能な追加スペックやサポートされている追加スペックは、バックエンドのドライバーにより異なります。有効な追加スペックの一覧については、ボリュームドライバーのマニュアルを参照してください。

または、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 に対する有効な値が表示されます。

デフォルトでは、すべてのボリューム種別が OpenStack の全テナントにアクセス可能です。アクセスが制限されたボリューム種別を作成する必要がある場合は、CLI から作成する必要があります。手順については「プライベートのボリューム種別の作成と設定」を参照してください。

ボリューム種別を削除するには、ボリューム種別 の表でそのボリューム種別のチェックボックスを選択して ボリューム種別の削除 をクリックします。

デフォルトでは、すべてのボリューム種別が全テナントに対して表示されます。ボリューム種別の作成中に、プライベート に指定すると、この設定をオーバーライドすることができます。そのためには、その種別の Is_Public フラグを False に設定する必要があります。

プライベートのボリューム種別は、特定のボリューム設定に対するアクセスを制限するのに役立ちます。これは通常は、特定のテナントのみが使用可能とする必要のある設定です。たとえば、テスト中の新規バックエンドや超ハイパフォーマンスの設定などが例としてあげられます。

プライベートのボリューム種別を作成するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-create --is-public false VTYPE

+ VTYPE は、プライベートのボリューム種別の名前に置き換えます。

デフォルトでは、プライベートのボリューム種別は、作成者のみがアクセス可能ですが、admin ユーザーは、以下のコマンドを使用するとプライベートのボリューム種別を特定/表示することができます。

# cinder --os-volume-api-version 2 type-list --all

このコマンドは、パブリックとプライベートの両方のボリューム種別を一覧表示します。 一覧には、各ボリューム種別の名前と ID も表示されます。ボリューム種別にアクセスするには、そのボリューム種別の ID が必要となります。

プライベートのボリューム種別へのアクセスは、テナントレベルで許可されます。テナントがプライベートのボリューム種別にアクセスできるようにするには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-add --volume-type VTYPEID --project-id TENANTID

上記の設定で、

プライベートのボリューム種別にアクセス可能なテナントを確認するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-list --volume-type VTYPE

プライベートのボリューム種別のアクセスリストからテナントを削除するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-remove --volume-type VTYPE --project-id TENANTID

管理者は、「QoS スペック」の表で QoS スペックの作成および設定を行うことができます。同じ QoS スペックには、複数のキー/値のペアを関連づけることができます。

管理者は、ボリューム種別 の表で QoS スペックを既存のボリューム種別に関連付ける事ができます。

暗号化されたボリュームを作成するには、まず 暗号化されたボリューム種別 が必要です。ボリューム種別を暗号化するには、使用すべきプロバイダークラス、暗号、キーサイズを設定する必要があります。

暗号化されたボリューム種別が設定されると、暗号化ボリュームを自動で呼び出すことができます。ボリューム種別の作成に関する情報は、「ボリューム種別の作成と設定」を参照してください。具体的には、ボリュームの作成 ウィンドウの種別のドロップダウンリストから暗号化されたボリューム種別を選択します (「ボリュームの基本的な使用方法と設定」を参照)。

暗号化されたボリューム種別の設定を再構成することも可能です。ボリューム種別の アクション コラムから 暗号化設定の更新 を選択して、ボリューム種別の暗号化設定の更新 ウィザードを開きます。

プロジェクト > コンピュート > ボリューム にある ボリューム テーブルの 暗号化 コラムでは、ボリュームが暗号化されているかが分かります。暗号化されている場合には、暗号化のコラムの はい をクリックすると暗号化設定が表示されます。

デフォルトでは、整合性グループ API は Block Storage のセキュリティーポリシーにより無効化されます。この機能を使用するには、事前に有効化しておく必要があります。そのためには、Block Storage API ストレージ (openstack-cinder-api) をホストするノードの /etc/cinder/policy.json で関連の整合性グループのエントリーを編集します。このエントリーは以下のように表示されます。

"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",

セキュリティーを強化するには、整合性グループの API およびボリューム種別管理の API のパーミッションをいずれも同じに設定します。デフォルトでは、ボリューム種別管理の API は (同じ /etc/cinder/policy.json ファイルで) "rule:admin_or_owner" に設定されています。

"volume_extension:types_manage": "rule:admin_or_owner",

推奨されているように、整合性グループの API を有効化するには、以下のようにエントリーを編集します。

"consistencygroup:create" : "rule:admin_api",
​"consistencygroup:delete": "rule:admin_api",
​"consistencygroup:update": "rule:admin_api",
​"consistencygroup:get": "rule:admin_api",
​"consistencygroup:get_all": "rule:admin_api",
​"consistencygroup:create_cgsnapshot" : "rule:admin_api",
​"consistencygroup:delete_cgsnapshot": "rule:admin_api",
​"consistencygroup:get_cgsnapshot": "rule:admin_api",
​"consistencygroup:get_all_cgsnapshots": "rule:admin_api",

"consistencygroup:create" : "rule:admin_or_owner",
​"consistencygroup:delete": "rule:admin_or_owner",
​"consistencygroup:update": "rule:admin_or_owner",
​"consistencygroup:get": "rule:admin_or_owner",
​"consistencygroup:get_all": "rule:admin_or_owner",
​"consistencygroup:create_cgsnapshot" : "rule:admin_or_owner",
​"consistencygroup:delete_cgsnapshot": "rule:admin_or_owner",
​"consistencygroup:get_cgsnapshot": "rule:admin_or_owner",
​"consistencygroup:get_all_cgsnapshots": "rule:admin_or_owner",

整合性グループの API を有効化した後に、Block Storage API サービスを再起動します。

# openstack-service restart openstack-cinder-api

整合性グループの API を有効化した後には、以下の手順で、整合性グループの作成を開始することができます。

アクション コラムから 整合性グループの編集 を選択して、整合性グループの名前または説明を変更することができます。

さらに、以下の手順に従って、直接整合性グループにボリュームを追加または削除することもできます。

整合性グループにボリュームを追加した後に、そこからスナップショットを作成することができます。その前に、まず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

上記の設定で、

利用可能な整合性グループのスナップショットの全一覧を表示するには、以下を実行します。

# cinder cgsnapshot-list

整合性グループを使用して、事前に設定されたボリューム群を一括で同時に作成することもできます。この操作は、既存の整合性グループをクローンするか、整合性グループのスナップショットを復元することによって実行できます。いずれのプロセスも同じコマンドを使用します。

既存の整合性グループのクローンを作成します。

# 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 に置き換えてください。

大半のテナントストレージクォータ (ボリューム、ボリュームのストレージ、スナップショットの数) とは異なり、バックアップクォータは現在のところ、Dashboard では編集できません。

バックアップクォータは、コマンドラインインターフェース (cinder quota-update コマンド) でのみ編集することができます。

特定のテナント(TENANTNAME) のストレージクォータを確認するには、以下のコマンドを実行します。

# cinder quota-show TENANTNAME

特定のテナントで作成可能なバックアップの最大数 (MAXNUM) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backups MAXNUM TENANTNAME

特定のテナント内の全バックアップの最大合計容量 (MAXGB) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backup-gigabytes MAXGB TENANTNAME

特定のテナントのストレージクォータの使用状況を確認するには、以下のコマンドを実行します。

# cinder quota-usage TENANTNAME

Dashboard を使用してボリュームの作成、表示、削除、復元ができるようになりました。これらの操作を実行するには、プロジェクト > コンピュート > ボリューム > ボリュームバックアップ タブを開いてください。

ただし、ボリュームバックアップ タブは、デフォルトでは有効化されません。有効にするには、Dashboard を適切に設定する必要があります。

デフォルトでは、Block Storage サービスは Object Storage サービスをバックアップリポジトリーとして使用しますが、 Block Storage サービスが Object Storage サービスの代わりに既存の NFS 共有をバックアップリポジトリーとして使用するように設定することが可能です。この設定は、以下の手順に従って行います。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_file_size SIZE

# systemctl restart openstack-cinder-backup.service

Dashboard を使用したボリューム譲渡の作成

Dashboard を使用したボリューム譲渡の受理

Red Hat Ceph を OpenStack デプロイメントのバックエンドとして使用する場合には、そのバックエンドでスナップショットの 保護 を設定することができます。OpenStack で (Dashboard または cinder snapshot-delete コマンドを使用して) 保護されているスナップショットの削除を試みると、操作は失敗します。

このようなエラーが発生した場合には、最初に Red Hat Ceph バックエンドでスナップショットを 保護解除 に設定すると、OpenStack で通常通りに削除することができるようになるはずです。

関連する手順については、「Protecting a Snapshot」および「Unprotecting a Snapshot」を参照してください。

ボリュームをバックアップするには、cinder backup-create コマンドを使用します。デフォルトでは、このコマンドは、ボリュームの完全バックアップを作成します。ボリュームに既存のバックアップがある場合には、完全バックアップの代わりに、増分 バックアップの作成を選択することができます (詳しくは 「ボリュームの増分バックアップの作成」 を参照)。

ボリュームのバックアップを作成できるのは、そのボリュームにアクセス可能なユーザーなので、管理権限があるユーザーは、ボリュームを誰が所有しているかにかかわらず、任意のボリュームのバックアップを作成できることになります。 詳しい説明は、「admin としてのボリュームのバックアップ作成」を参照してください。

この時点で、ボリュームのバックアップのメタデータをエクスポートして保管することもできます。これにより、Block Storage データベースで致命的なデータ損失が発生した場合でも、ボリュームのバックアップを復元することができます。以下のコマンドを実行します。

# cinder --os-volume-api-version 2 backup-export BACKUPID

BACKUPID はボリュームのバックアップの ID または名前に置き換えます。

+----------------+------------------------------------------+
|    Property    |                Value                     |
+----------------+------------------------------------------+
| backup_service |     cinder.backup.drivers.swift          |
|   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
|                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
+----------------+------------------------------------------+

ボリュームのバックアップのメタデータは backup_service と backup_url の値で構成されます。

# cinder --os-auth-url KEYSTONEURL --os-tenant-name TENANTNAME --os-username USERNAME --os-password PASSWD backup-create VOLUME

デフォルトでは、cinder backup-create コマンドを実行すると、ボリュームの完全バックアップが作成されますが、ボリュームに既存のバックアップがある場合には、増分 バックアップを作成することが可能です。

増分バックアップは、前回のバックアップ (完全または増分バックアップ) 以降に加えられた変更をキャプチャーします。ボリュームの完全バックアップを何度も定期的に行うと、時間の経過とともにボリュームの容量が拡大されて、リソースを集中的に使用することになります。この点に関しては、増分バックアップの場合には、一定期間の変更のみをキャプチャーして、リソースの使用を最小限に抑えることができます。

増分バックアップを作成するには、--incremental オプションを使用します。

# cinder backup-create VOLUME --incremental

VOLUME の箇所は、バックアップするボリュームの ID または 表示名 に置き換えます。

増分バックアップは、NFS および Object Storage のバックアップリポジトリーで完全にサポートされています。 Ceph のバックアップリポジトリーでも増分バックアップはサポートされていますが、ボリュームも Ceph バックエンド上で保管されている場合のみとなります。

通常、Block Storage のデータベースのデータ損失が発生すると、ボリュームのバックアップを復元できなくなります。これは、Block Storage データベースにボリュームのバックアップサービス (openstack-cinder-backup) で必要とされるメタデータが含まれているためです。このメタデータは backup_service と backup_url の値で構成され、ボリュームのバックアップ作成後に (「ボリュームの完全バックアップの作成」に記載した手順に従って) エクスポートすることができます。

メタデータをエクスポートして保管した場合には、新しい Block Storage データベースにインポートすることができます (これにより、ボリュームのバックアップを復元することができます)。

バックエンド間でボリュームを移行するには ボリューム種別の変更 を行う必要があります。新規バックエンドに移行するためには、以下の条件を満たす必要があります。

詳細は、「ボリューム種別へのボリューム設定の関連付け」と「ボリュームを作成するバックエンドの指定」を参照してください。

追加スペックとしてバックエンドを定義する場合は、キー として volume_backend_name を使用します。これに対応する値は、Block Storage の設定ファイル (/etc/cinder/cinder.conf) に定義されているバックエンド名になります。このファイルでは、各バックエンドは独自のセクションに定義され、対応する名前は volume_backend_name のパラメーターに設定されています。

移行先のボリューム種別にバックエンドを定義すると、ボリューム種別の変更 でバックエンドにボリュームを移行することができます。この際には、移行先のボリューム種別をボリュームに再適用し、それにより新しいバックエンドの設定が適用されます。方法は 「ボリューム種別の変更」 を参照してください。

以下の手順に従って設定します。