第2章 Block Storage とボリューム

Block Storage サービス (openstack-cinder) は、全ボリュームの管理タスク、セキュリティー、スケジューリング、全体を管理します。Compute インスタンスでは、永続ストレージとしてボリュームが主に使用されます。

2.1. バックエンド

デフォルトでは、Block Storage サービスは、ボリュームのリポジトリーとして LVM バックエンドを使用します。このバックエンドは、テスト環境に適していますが、Enterprise 環境にはより堅牢なバックエンドをデプロイすることを推奨します。

この環境に Red Hat OpenStack Platform をデプロイする際は director を使用することを推奨します。director を使用することで、Block Storage サービス (拡張でバックエンドも含む) など、各サービスが正しく設定されるようにします。director には、複数のバックエンド設定が統合されています。

Red Hat OpenStack Platform は、Block Storage バックエンドとして Red Hat Ceph および NFS をサポートします。各デプロイメントの方法は、『director のインストールと使用方法』を参照してください。特に以下のセクションを参照してください。

「Ceph Storage」 (概要)、「Ceph Storage ノードの要件」 (要件)、『オーバークラウド向けの Red Hat Ceph Storage』 (デプロイメントの説明)
「NFS ストレージの設定」

サードパーティーのストレージプロバイダー

Block Storage サービスをサポート対象のサードパーティー製ストレージアプライアンスを使用するように設定することも可能です。director には、以下が簡単にデプロイされるように、必要なコンポーネントが含まれています。

Dell EqualLogic
Dell Storage Center
NetApp (サポート対象のアプライアンス)

Fujitsu ETERNUS もバックエンドとしてサポートされていますが、director にはまだ統合されていません。カスタム (統合されていない) バックエンドをデプロイする方法は、『Custom Block Storage Back End Deployment Guide』を参照してください。

サポートされるバックエンドアプライアンスとドライバーの完全な一覧は「Component, Plug-In, and Driver Support in RHEL OpenStack Platform」を参照してください。

2.2. Block Storage サービスの管理

以下の手順では、Block Storage サービスをニーズに合わせて設定する方法を説明します。以下の手順はすべて管理者権限が必要です。

2.2.1. ボリューム種別へのボリューム設定の関連付け

OpenStack では、ボリューム種別を作成することができ、種別に関連付けられた設定を適用することができます。そのため、ボリュームの作成時 (「ボリュームの作成」) や作成後にも (「ボリューム種別の変更」) これらの設定を適用することができます。たとえば、以下のような関連付けが可能です。

ボリュームの暗号化/非暗号化 (「ボリューム種別の暗号化設定」)
ボリュームが使用するバックエンド (「ボリュームを作成するバックエンドの指定」および「バックエンド間での移行」)
Quality-of-Service (QoS) スペック

設定は、「追加スペック」と呼ばれるキーと値のペアを使用してボリューム種別に関連付けられます。ボリュームの作成時にボリューム種別を指定する際には、Block Storage のスケジューラーがこれらのキーと値のペアを設定として適用します。また、複数のキーと値のペアを同じボリューム種別に関連付けることができます。

ボリューム種別は、異なるユーザーにストレージ階層を使用できるようにする機能をします。特定のパフォーマンス、耐障害性、およびその他の設定をキーと値のペアとしてボリューム種別に関連付けることにより、階層固有の設定を異なるボリューム種別にマップすることができます。マップされた階層固有の設定は、ボリュームの作成時に対応するボリューム種別を指定することによって適用が可能です。

注記

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

2.2.1.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.1.2. ボリューム種別の作成と設定

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別の作成 をクリックします。
名前フィールドにボリューム種別の名前を入力します。
ボリューム種別の作成 をクリックします。ボリューム種別 の表に新しい種別が表示されます。
ボリューム種別の 追加スペックの表示 のアクションを選択します。
作成をクリックしてキーと値を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時にそのボリューム種別を指定するとエラーが発生してしまいます。
作成をクリックします。関連づけられた設定 (キー/値のペア) が 追加スペック の表に表示されます。

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

注記

QoS スペックをボリューム種別に関連付けることも可能です。詳しい説明は、「QoS スペックとボリューム種別の関連付け」を参照してください。

2.2.1.3. ボリューム種別の編集

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、ボリューム種別の 追加スペックの表示 のアクションを選択します。
このページの 追加スペック 表では、以下のような操作を行うことができます。
- ボリューム種別への新規設定の追加。これには、作成をクリックして、ボリューム種別に対して、関連付ける新規設定のキー/値ペアを指定します。
- ボリューム種別に関連付けられている既存の設定の編集。これには、設定の編集アクションを選択します。
- ボリューム種別に関連付けられている既存の設定の削除。これには、追加スペックのチェックボックスを選択して、このダイアログ画面と次の画面で 追加スペックの削除 をクリックします。

2.2.1.4. ボリューム種別の削除

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

2.2.1.5. プライベートのボリューム種別の作成と設定

デフォルトでは、すべてのボリューム種別が全テナントに対して表示されます。ボリューム種別の作成中に、プライベート に指定すると、この設定をオーバーライドすることができます。そのためには、その種別の 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

上記の設定で、

VTYPEID は、プライベートのボリューム種別の ID に置き換えます。
TENANTID は、VTYPEID へのアクセスを許可するプロジェクト/テナントの ID に置き換えます。

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

# 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

注記

プライベートのボリューム種別へのアクセスは、デフォルトでは管理権限のあるユーザーのみが作成、表示、設定することが可能です。

2.2.2. Block Storage サービスの内部テナントの作成および設定

Block Storage 機能 (例: Image-Volume キャッシュ) の一部では、内部テナント の設定を必要とします。Block Storage サービスは、このテナントを使用して、通常のユーザーに公開する必要のないブロックストレージアイテムを管理します。このようなアイテムの例として、頻繁にボリュームをクローン作成したり、ボリュームの一時コピーを移行したりするためにキャッシュされたイメージなどが挙げられます。

内部テナントを設定するには、まず cinder-internal という名前の一般テナントとユーザーを作成します。これには、コントローラーノードにログインして以下のコマンドを実行します。

# keystone tenant-create --name cinder-internal --enabled true --description "Block Storage Internal Tenant"
    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |  Block Storage Internal Tenant   |
    |   enabled   |               True               |
    |      id     | cb91e1fe446a45628bb2b139d7dccaef |
    |     name    |         cinder-internal          |
    +-------------+----------------------------------+
# keystone user-create --name cinder-internal
    +----------+----------------------------------+
    | Property |              Value               |
    +----------+----------------------------------+
    |  email   |                                  |
    | enabled  |               True               |
    |    id    | 84e9672c64f041d6bfa7a930f558d946 |
    |   name   |         cinder-internal          |
    | username |         cinder-internal          |
    +----------+----------------------------------+

テナントおよびユーザーを作成すると、それぞれの ID が表示される点に注意してください。Block Storage サービスがテナントとユーザーの両方を内部テナントとして使用するように、それらの ID を指定して設定します。この操作を行うには、各 Block Storage ノードで以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id TENANTID
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id USERID

TENANTID と USERID は、keystone で作成したテナントとユーザーの各 ID に置き換えます。たとえば、上記で表示された ID を使用した例は以下のとおりです。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id cb91e1fe446a45628bb2b139d7dccaef
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id 84e9672c64f041d6bfa7a930f558d946

2.2.3. Image-Volume キャッシュの設定および有効化

Block Storage サービスには、任意の Image-Volume キャッシュ が含まれており、イメージからボリュームを作成する際にこのキャッシュを使用できます。このキャッシュは、頻繁に使用するイメージからボリュームを作成する際の時間を短縮するように設計されています。イメージからボリュームを作成する方法は「ボリュームの作成」を参照してください。

Image-Volume のキャッシュを有効化すると、ボリュームの初回作成時にベースとなったイメージのコピーが保存されます。この保存されたイメージは、Block Storage バックエンドのローカルにキャッシュされ、次回このイメージを使用してボリュームを作成する際のパフォーマンス向上に役立ちます。Image-Volume キャッシュは、サイズ (GB)、イメージ数、または両方を指定して上限を設定することができます。

Image-Volume キャッシュは、複数のバックエンドでサポートされます。サードパーティーのバックエンドを使用する場合は、Image-Volume キャッシュサポートに関する情報については、サードパーティーのドキュメントを参照してください。

注記

Image-Volume キャッシュでは、内部テナント を Block Storage サービスに設定する必要があります。方法は、「Block Storage サービスの内部テナントの作成および設定」を参照してください。

Block Storage ノードで Image-Volume キャッシュを有効化して設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_enabled = True

デフォルトでは、Image-Volume キャッシュサイズはバックエンドによってのみ制限されます。最大サイズ (MAXSIZE、GB 単位) を設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_max_size_gb = MAXSIZE

または、イメージの最大数を設定することもできます (MAXNUMBER)。設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_max_count = MAXNUMBER

Block Storage サービスのデータベースは、タイムスタンプを使用して、キャッシュされた各イメージの最終使用日時をトラッキングします。MAXSIZE と MAXNUMBER のいずれか一方または両方が設定されている場合は、Block Storage サービスは必要に応じてキャッシュされたイメージを削除し、新たにイメージをキャッシュするためのスペースを解放します。Image-Volume キャッシュが上限に達すると、最も古いタイムスタンプが付いたキャッシュイメージが最初に削除されます。

Image-Volume のキャッシュを設定した後に、Block Storage サービスを再起動します。

# openstack-service restart cinder

2.2.4. QoS スペックの使用

複数のパフォーマンス設定を単一の Quality-of-Service の仕様 (QoS スペック) にマップすることができます。これにより、ユーザータイプ別のパフォーマンス階層を提供することができます。

パフォーマンス設定はキーと値のペアとして QoS スペックにマップされます。これは、ボリュームの設定がボリューム種別に関連付けられる方法と似ていますが、QoS スペックの場合は以下の面でボリューム種別の場合とは異なります。

QoS スペックは、ディスクの読み取り/書き込み操作を制限するなどのパフォーマンス設定を適用するのに使用されます。利用可能かつサポートされているパフォーマンス設定はストレージドライバーによって異なります。
バックエンドがサポートしている QoS スペックを確認するには、そのバックエンドデバイスのボリュームドライバーのマニュアルを参照してください。
ボリューム種別はボリュームに直接適用されるのに対して QoS スペックは直接適用されるのではなく、ボリューム種別に関連付けられます。また、ボリュームの作成時にボリューム種別を指定すると、そのボリューム種別に関連付けられた QoS スペックにマップされたパフォーマンス設定も適用されます。

2.2.4.1. QoS スペックの作成と設定

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

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
QoS スペック の表で QoS スペックの作成 をクリックします。
QoS スペック の名前を入力します。

使用者 フィールドで、QoS ポリシーを適用する先を指定します。

表2.1 使用者のタイプ

タイプ	説明
`back-end`	QoS ポリシーが Block Storage バックエンドに適用されます。
`front-end`	QoS ポリシーが Compute に適用されます。
`両方`	QoS ポリシーが Block Storage と Compute の両方に適用されます。

作成をクリックします。新規 QoS スペックが QoS スペック の表に表示されるはずです。
QoS スペック の表で、新規スペックの スペックの管理 アクションを選択します。
作成をクリックしてキーと値を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時に、この QoS スペックに関連付けられたボリューム種別を指定するとエラーが発生してしまいます。
作成をクリックします。関連づけられた設定 (キー/値のペア) が キーと値のペア の表に表示されます。

2.2.4.2. QoS スペックとボリューム種別の関連付け

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

Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
関連付ける QoS スペック のリストから QoS スペックを選択します。
割り当て をクリックします。選択した QoS スペックが、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されるようになります。

2.2.4.3. ボリューム種別からの QoS スペックの関連付け解除

Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
「関連付ける QoS スペック」のリストからなしを選択します。
割り当て をクリックします。選択した QoS スペックは、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されなくなります。

2.2.5. 静的キーを使用したボリュームの暗号化

ボリュームの暗号化は、ボリュームのバックエンドのセキュリティーを侵害されたり、完全に盗難されたりした場合に、基本的なデータ保護を提供します。暗号化ボリュームの内容は、特定のキーを使用しなければ読み取ることはできません。インスタンスが暗号化ボリュームを使用するためには、Compute サービスと Block Storage サービスの両方で同じキーを使用するように設定する必要があります。また、暗号化を使用する固有のボリューム種別を作成することや、暗号化されたボリューム種別を使用して作成された全ボリュームを作成することも可能です。

本項では、OpenStack デプロイメントで暗号化ボリュームに単一のキーを使用するように設定する方法を説明します。

重要

現在、ボリュームの暗号化はブロックデバイスでバッキングされているボリュームでのみサポートされます。ネットワークが接続されたボリュームの暗号化 (RBD) またはファイルベースのボリューム (NFS など) はまだサポートされていません。

2.2.5.1. 静的キーの設定

基本的なボリュームの暗号化を実装する第 1 のステップは、静的キーの設定です。このキーは 16 進数の文字列にする必要があります。これは Block Storage ボリュームサービス (openstack-cinder-volume) と全 Compute サービス (openstack-nova-compute) によって使用されます。両サービスがこのキーを使用するように設定するには、両サービスのそれぞれの設定ファイルの [keymgr] セクションで fixed_key 値としてキーを設定します。

コマンドラインから、openstack-cinder-volume をホストしているノードに、root としてログインします。
静的キーを設定します。
```
# openstack-config --set /etc/cinder/cinder.conf keymgr fixed_key HEX_KEY
```
HEX_KEY は、16桁の英数字の 16 進数キー (例: 04d6b077d60e323711b37813b3a68a71) に置き換えます。
以下のように openssl コマンドを使用してキーを生成します。
```
# openssl rand -hex 16
04d6b077d60e323711b37813b3a68a71
```
注記
この値はセキュアでなければなりません。
Block Storage ボリュームサービスを再起動します。
```
# openstack-service restart cinder-volume
```
次に、openstack-nova-compute をホストするノードにログインして、同じ静的キーを設定します。
```
# openstack-config --set /etc/nova/nova.conf keymgr fixed_key HEX_KEY
```
注記
複数のコンピュートノード (openstack-nova-compute をホストする複数のノード) を使用している場合には、同じ静的キーを各ノードの /etc/nova/nova.conf に設定する必要があります。
Compute サービスを再起動します。
```
# openstack-service restart nova-compute
```
注記
同様に、複数のコンピュートノードに静的キーを設定した場合には、各ノードで openstack-nova-compute サービスを再起動する必要があります。

この時点で、Compute サービスと Block Storage サービスの両方で同じ静的キーを使用してボリュームの暗号化/暗号化解除できるようになりました。つまり、新規インスタンスは静的キー (HEX_KEY) で暗号化したボリュームを使用できます。

2.2.5.2. ボリューム種別の暗号化設定

「静的キーの設定」の手順に従って設定した静的キーを使用して暗号化ボリュームを作成するには、暗号化されたボリューム種別 が必要です。ボリューム種別を暗号化設定するには、対象のボリューム種別が使用すべきプロバイダークラス、暗号、キーサイズを指定する必要があります。これには、以下のコマンドを実行します。

# cinder encryption-type-create --cipher aes-xts-plain64 --key_size BITSIZE --control_location front-end VOLTYPE nova.volume.encryptors.luks.LuksEncryptor

上記の設定で、

BITSIZE はキーのサイズに置き換えます (例: 512 ビットキーの場合は 512)。
VOLTYPE は暗号化するボリューム種別名に置き換えます。

上記のコマンドにより、nova.volume.encryptors.luks.LuksEncryptor プロバイダークラス、aes-xts-plain64 の暗号が設定されます。本リリースでは、ボリュームの暗号化でサポートされている設定はクラス/暗号のみです。

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

プロジェクト > コンピュート > ボリューム のボリュームの下の 暗号化 で Yes をクリックすると、暗号化に関するメタデータを表示することができます。

2.2.6. ボリュームを複数のバックエンドに割り当てる方法の設定

Block Storage サービスが複数のバックエンドを使用するように設定されている場合には、設定済みのボリューム種別を使用して、ボリュームの作成先を指定することができます。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。

ボリュームの作成時にバックエンドを指定していない場合には、Block Storage サービスにより、自動的に選択されます。Block Storage は、最初に定義したバックエンドをデフォルトとして設定します。このバックエンドは、容量がなくなるまで使用されます。容量がなくなった時点で、Block Storage は 2 番目に定義されたバックエンドをデフォルトに設定し、その容量がなくなるとさらに次のバックエンドがデフォルトに設定されるようになっています。

このメカニズムが必要な条件を満たさない場合には、フィルタースケジューラーを使用して、Block Storage がバックエンドを選択する方法を制御することができます。このスケジューラーは、以下の例に示したような異なるフィルターを使用して適切なバックエンドをトリアージすることができます。

AvailabilityZoneFilter: 要求されたボリュームのアベイラビリティーゾーン要件を満たさないバックエンドを除外します。
CapacityFilter: ボリュームを収容するのに十分な容量のあるバックエンドのみを選択します。
CapabilitiesFilter: ボリュームで指定した設定に対応可能なバックエンドのみを選択します。

フィルタースケジューラーは、以下の手順で設定します。

FilterScheduler を有効化します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_driver cinder.scheduler.filter_scheduler.FilterScheduler

アクティブにする必要のあるフィルターを設定します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_filters AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter

スケジューラーが適切なバックエンドを選択する方法を設定します。
- スケジューラーが、空き容量の最も大きなバックエンドを常に選択するようにするには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers AllocatedCapacityWeigher
# openstack-config --set /etc/cinder/cinder.conf DEFAULT allocated_capacity_weight_multiplier -1.0
```
- スケジューラーが、すべての適切なバックエンドの中から無作為に選択するようにするには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers ChanceWeigher
```
Block Storage スケジューラーを再起動して、設定を適用します。
```
# openstack-service restart openstack-cinder-scheduler
```

2.2.7. バックアップの管理

以下のセクションでは、Block Storage サービスでのボリュームのバックアップ設定をカスタマイズする方法を説明します。

2.2.7.1. テナントのバックアップクォータの表示と変更

大半のテナントストレージクォータ (ボリューム、ボリュームのストレージ、スナップショットの数) とは異なり、バックアップクォータは現在のところ、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

2.2.7.2. Dashboard を使用したボリュームバックアップ管理の有効化

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

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

/etc/openstack-dashboard/local_settings を開きます。

以下の設定を検索します。

OPENSTACK_CINDER_FEATURES = {
    'enable_backup': False,
}

この設定を以下のように変更します。

OPENSTACK_CINDER_FEATURES = {
    'enable_backup': True,
}

httpd サービスを再実行して、Dashboard を再起動します。
```
# systemctl restart httpd.service
```

2.2.7.3. バックアップリポジトリーとしての NFS 共有の設定

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

バックアップサービス (openstack-cinder-backup) をホストしているノードに、管理権限のあるユーザーとしてログインします。
Block Storage サービスが NFS バックアップドライバー (cinder.backup.drivers.nfs) を使用するように設定します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_driver cinder.backup.drivers.nfs
```
バックアップリポジトリーとして使用する NFS 共有の詳細を設定します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_share NFSHOST:PATH
```
上記の設定で、
- NFSHOST は、NFS サーバーの IP アドレスまたはホスト名に置き換えます。
- PATH は、NFSHOST 上の NFS 共有の絶対パスに置き換えます。
NFS 共有のマウントオプション設定を指定するには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_mount_options NFSMOUNTOPTS
```
NFSMOUNTOPTS には、NFS マウントオプションのコンマ区切りの一覧を指定します (例: rw,sync)。サポートされているマウントオプションについての詳しい情報は、nfs および mount の man ページを参照してください。
Block Storage バックアップサービスを再起動して、変更を適用します。
```
# systemctl restart openstack-cinder-backup.service
```

2.2.7.3.1. 異なるバックアップファイルサイズの設定

バックアップサービスのバックアップするファイルのサイズは、最大 バックアップファイルサイズ を上限としています。ボリュームのバックアップがこの値を超える場合には、作成されるバックアップは複数のチャンクに分割されます。デフォルトのバックアップファイルサイズは 1.8 GB です。

異なるバックアップファイルサイズを設定するには、以下のコマンドを実行します。

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

SIZE は指定するファイルサイズ (バイト単位) に置き換えます。Block Storage バックアップサービスを再起動して、変更を適用します。

# systemctl restart openstack-cinder-backup.service

2.3. ボリュームの基本的な使用方法と設定

以下の手順では、基本的なエンドユーザー向けのボリューム管理方法について説明します。これらの手順には管理者の権限は必要ありません。

2.3.1. ボリュームの作成

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。

ボリュームの作成 をクリックして、以下のフィールドを編集します。

フィールド	説明
ボリューム名	ボリュームの名前
説明	ボリュームの簡単な説明 (オプション)
タイプ	オプションのボリューム種別 (「ボリューム種別へのボリューム設定の関連付け」を参照) 複数の Block Storage バックエンドがある場合には、このフィールドを使用して特定のバックエンドを選択します。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。
容量 (GB)	ボリュームの容量 (ギガバイト単位)
アベイラビリティーゾーン	アベイラビリティーゾーン (論理サーバーグループ) は、ホストアグリゲートと併せて、OpenStack 内のリソースを分離する一般的な方法です。アベイラビリティーゾーンは、インストール中に定義されます。アベイラビリティーゾーンとホストについてのさらに詳しい説明は、Red Hat OpenStack Platform から『インスタンスおよびイメージガイド』の「ホストアグリゲートの管理」を参照してください。

ボリュームソース を指定します。

ソース	説明
ソースの指定なし (空のボリューム)	ボリュームは空となり、ファイルシステムやパーティションテーブルは含まれません。
スナップショット	既存のスナップショットをボリュームソースとして使用します。このオプションを選択すると、「スナップショットをソースとして使用する」の一覧が新たに表示され、スナップショットを選択できるようになります。ボリュームのスナップショットについての詳しい情報は、「ボリュームスナップショットの作成、使用、削除」を参照してください。
イメージ	既存のイメージをボリュームソースとして使用します。このオプションを選択すると、「イメージをソースとして使用する」の一覧が新たに表示され、イメージを選択できるようになります。
ボリューム	既存のボリュームをボリュームソースとして使用します。このオプションを選択すると、「ボリュームをソースとして使用する」の一覧が新たに表示され、ボリュームを選択できるようになります。

ボリュームの作成 をクリックします。ボリュームが作成されると、ボリューム の表に名前が表示されます。

後ほどボリュームの種別を変更することも可能です。詳しくは「ボリューム種別の変更」を参照してください。

2.3.2. ボリュームを作成するバックエンドの指定

複数の Block Storage バックエンドが設定された場合には、必ず、バックエンドごとにボリューム種別を作成する必要があります。その種別を使用して、作成したボリュームに、どのバックエンドを使用すべきかを指定することができます。ボリューム種別の詳しい情報は、「ボリューム種別へのボリューム設定の関連付け」を参照してください。

ボリュームの作成時にバックエンドを指定するには「種別」のドロップダウンリストから適切なボリューム種別を選択します (「ボリュームの作成」を参照)。

ボリュームの作成時にバックエンドを指定しない場合には、Block Storage サービスにより自動的に選択されます。デフォルトでは、このサービスは、最も空き容量の多いバックエンドを選択します。また、Block Storage サービスが利用可能な全バックエンドから無作為に選択するように設定することも可能です。詳しくは「ボリュームを複数のバックエンドに割り当てる方法の設定」を参照してください。

2.3.3. ボリュームの名前と説明の編集

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの ボリュームの編集 ボタンをクリックします。
必要に応じて、ボリュームの名前または説明を編集します。
ボリュームの編集 をクリックして、変更を保存します。

注記

暗号化ボリュームを作成するには、最初にボリュームの暗号化専用に設定されたボリューム種別を使用する必要があります。また、Compute サービスと Block Storage サービスの両方で、同じ静的キーを使用するように設定しておく必要があります。ボリュームの暗号化に必要な設定の方法についての説明は、「静的キーを使用したボリュームの暗号化」を参照してください。

2.3.4. ボリュームの削除

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
ボリューム の表で、削除するボリュームを選択します。
ボリュームの削除 をクリックします。

注記

スナップショットが存在する場合には、ボリュームは削除できません。スナップショットの削除手順については、「ボリュームスナップショットの作成、使用、削除」を参照してください。

2.3.5. インスタンスへのボリュームの接続と切断

インスタンスの永続ストレージにボリュームを使用することができます。ボリュームは、1 度に 1 つのインスタンスにしか接続できません。インスタンスに関する詳しい情報は、Red Hat OpenStack Platform から、『インスタンスおよびイメージガイド』の「インスタンスの管理」を参照してください。

2.3.5.1. インスタンスへのボリュームの接続

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの 接続の編集 アクションを選択します。ボリュームがインスタンスに接続されていない場合には、インスタンスへの接続 のドロップダウンリストが表示されます。
インスタンスへの接続 の一覧から、ボリュームの接続先となるインスタンスを選択します。
ボリュームの接続 をクリックします。

2.3.5.2. インスタンスからのボリュームの切断

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの 接続の管理 アクションを選択します。ボリュームがインスタンスに接続されている場合には、そのインスタンスの名前が 接続状況 の表に表示されます。
このダイアログ画面と次の画面で ボリュームの切断 をクリックします。

2.3.6. ボリュームの読み取り専用設定

1 つのボリュームでコンテンツを編集できないようにして、複数のユーザーに共有アクセスを許可することができます。そのためには、以下のコマンドを実行して、ボリュームを read-only に設定します。

# cinder readonly-mode-update VOLUME true

VOLUME は、ターゲットボリュームの ID に置き換えます。

読み取り専用ボリュームを読み取り/書き込み可能に戻すには、以下のコマンドを実行します。

# cinder readonly-mode-update VOLUME false

2.3.7. ボリュームの所有者の変更

ボリュームの所有者を変更するには、ボリュームの譲渡を行います。ボリュームの譲渡は、ボリュームの所有者が開始し、ボリュームの新しい所有者が譲渡を承認すると、そのボリュームの所有権の変更が完了します。

2.3.7.1. コマンドラインを使用したボリュームの譲渡

コマンドラインから、ボリュームの現在の所有者としてログインします。
利用可能なボリュームを一覧表示します。
```
# cinder list
```

以下のコマンドを実行して、ボリュームの譲渡を開始します。

# cinder transfer-create VOLUME

VOLUME は譲渡するボリュームの名前または ID に置き換えます。

  +------------+--------------------------------------+
  |  Property  |                Value                 |
  +------------+--------------------------------------+
  |  auth_key  |           f03bf51ce7ead189           |
  | created_at |      2014-12-08T03:46:31.884066      |
  |     id     | 3f5dc551-c675-4205-a13a-d30f88527490 |
  |    name    |                 None                 |
  | volume_id  | bcf7d015-4843-464c-880d-7376851ca728 |
  +------------+--------------------------------------+

cinder transfer-create コマンドはボリュームの所有権を消去し、譲渡用の id と auth_key を作成します。この値は別のユーザーに渡すことができます。受け取ったユーザーは、その値を使用して譲渡を承認し、ボリュームの新しい所有者となります。

新規ユーザーがボリュームの所有権を宣言できる状態となりました。所有権を宣言するには、ユーザーは最初にコマンドラインからログインして以下のコマンドを実行する必要があります。
```
# cinder transfer-accept TRANSFERID TRANSFERKEY
```
TRANSFERID と TRANSFERKEY はそれぞれ、cinder transfer-create で返された id と auth_key の値に置き換えます。以下に例を示します。
```
# cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
```

注記

利用可能なボリュームの譲渡をすべて表示するには、以下のコマンドを実行します。

# cinder transfer-list

2.3.7.2. ダッシュボードを使用したボリュームの譲渡

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

Dashboard にボリュームの所有者としてログインして プロジェクト > ボリューム を選択します。
譲渡するボリュームの アクション のコラムで、 譲渡の作成 を選択します。
ボリュームの譲渡の作成 ダイアログボックスで、譲渡名を入力して ボリュームの譲渡の作成 をクリックします。
ボリュームの譲渡が作成され、ボリュームの譲渡 の画面で 譲渡 ID と 認証キー を取得して譲渡先のプロジェクトに送信することができます。
注記
認証キーは ボリュームの譲渡 の画面にしか表示されません。この認証キーをなくした場合には、譲渡をキャンセルし、別の譲渡を作成して新たな認証キーを生成する必要があります。
ボリュームの譲渡 の画面を閉じて、ボリュームの一覧に戻ります。
譲渡先のプロジェクトが譲渡を受理するまで、ボリュームのステータスは awaiting-transfer と表示されます。

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

Dashboard にボリュームの譲渡先としてログインして プロジェクト > ボリューム を選択します。
譲渡の受理 をクリックします。
ボリュームの譲渡の受理 のダイアログボックスで、ボリュームの所有者から受け取った 譲渡 ID と 認証キー を入力して、ボリュームの譲渡の受理 をクリックします。
譲渡先のプロジェクトのボリューム一覧に、そのボリュームが表示されるようになります。

2.3.8. ボリュームスナップショットの作成、使用、削除

ボリュームのスナップショットを作成することによって、ある特定の時点のボリュームの状態を保持することができます。そのスナップショットを使用して、新規ボリュームをクローン作成することが可能です。

注記

ボリュームのバックアップはスナップショットとは異なります。バックアップはボリューム内のデータを保持するのに対して、スナップショットはある特定の時点におけるボリュームの状態を保持します。また、スナップショットが存在している場合にはボリュームを削除することはできません。ボリュームのバックアップはデータ損失を防ぐ目的で使用されるのに対してスナップショットはクローン作成を円滑に行う目的で使用されます。

このため、スナップショットのバックエンドは、クローン作成中のレイテンシーを最小限に抑えるように、通常ボリュームのバックエンドと同じ場所に配置されます。一方、バックアップのリポジトリーは通常、一般的なエンタープライズデプロイメント内の別の場所に配置されます (例: 異なるノード、物理ストレージ、あるいは別の地理的ロケーションの場合もあり)。これは、ボリュームのバックエンドが一切ダメージを受けないように保護することを目的とします。

ボリュームのバックアップについての詳しい情報は、「ボリュームのバックアップと復元」を参照してください。

ボリュームのスナップショットの作成手順

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの スナップショットの作成 アクションを選択します。
作成するスナップショッットの スナップショット名 を指定して ボリュームのスナップショットの作成 をクリックします。ボリュームのスナップショット タブに全スナップショットが表示されます。

ボリュームのスナップショット の表にスナップショットが表示されたら、そのスナップショットから新規ボリュームをクローン作成することができます。この操作を行うには、対象のボリュームの ボリュームの作成 アクションを選択します。ボリュームの作成に関する詳しい説明は、「ボリュームの作成」を参照してください。

スナップショットを削除するには、ボリュームスナップショットの削除 アクションを選択します。

OpenStack デプロイメントで Red Hat Ceph バックエンドを使用している場合には、「Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除」でスナップショットのセキュリティーとトラブルシューティングについての詳しい情報を参照してください。

2.3.8.1. Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除

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

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

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

2.3.9. Image サービスにボリュームをアップロードする手順

イメージとして既存のボリュームを Image サービスに直接アップロードすることができます。これには、以下の手順を実行してください。

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの イメージにアップロード アクションを選択します。
ボリュームの イメージ名 を指定して、一覧から ディスク形式 を選択します。
アップロード をクリックします。QEMU ディスクイメージのユーティリティーにより、指定した名前を使用して、選択した形式で新規イメージがアップロードされます。

アップロードしたイメージを表示するには、プロジェクト > コンピュート > イメージ を選択します。新しいイメージが イメージ の表に表示されます。イメージの使用方法や設定方法に関する情報は、Red Hat OpenStack Platform から『インスタンスおよびイメージガイド』の「イメージの管理」を参照してください。

2.3.10. ボリューム種別の変更

ボリューム種別の変更 は、ボリューム種別 (およびその設定) を既存のボリュームに適用するプロセスです。ボリューム種別に関する情報は「ボリューム種別へのボリューム設定の関連付け」を参照してください。

既存のボリューム種別の有無に拘らず、ボリューム種別は変更できます。いずれの場合も、ボリューム種別の追加スペックがボリュームに適用できる場合のみ、ボリューム種別の変更は成功します。これは、事前定義の設定を適用する際や、ストレージの属性を既存のボリュームに適用する際に役立ちます。以下に例を示します。

異なるのバックエンドへボリュームを移行する場合 (「バックエンド間での移行」)
ボリュームのストレージクラス/層を変更する場合

管理者権限のないユーザーは、自分が所有するボリューム種別しか変更できません。ボリューム種別を変更するには、以下のステップを実行します。

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリューム種別の変更 を選択します。
ボリューム種別の変更 ダイアログで、種別のドロップダウンリストから新しいバックエンドを定義する、移行先のボリューム種別を選択します。
注記
別のバックエンドにボリュームを移行する場合は、移行ポリシー のドロップダウンリストから 要求時 を選択します。詳しい情報は「バックエンド間での移行」を参照してください。
ボリューム種別の変更 をクリックして移行を開始します。

2.4. ボリュームの高度な設定

以下の手順では、ボリュームの高度な管理方法について説明します。

2.4.1. ボリュームのバックアップと復元

ボリュームのバックアップは、ボリュームのコンテンツの永続的なコピーです。ボリュームのバックアップは通常オブジェクトストアとして作成されるため、デフォルトでは、Object Storage サービスで管理されますが、バックアップに異なるリポジトリーを設定することができます。OpenStack は、バックアップ用のバックエンドのオプションとして Red Hat Ceph、NFS をサポートしています。

ボリュームのバックアップの作成時には、バックアップのメタデータはすべて Block Storage サービスのデータベースに保管されます。cinder ユーティリティーはこのメタデータを使用して、バックアップからボリュームを復元します。このため、データベースの致命的なデータ損失から回復する際には、バックアップからボリュームを復元する前に Block Storage サービスのデータベースを復元する必要があります。これは、元のボリュームのバックアップのメタデータがすべて完全な状態で Block Storage サービスのデータベースが復元されることも前提としています。

データベースの致命的なデータ損失が発生した際にボリュームのバックアップのサブセットのみを保護するように設定する場合は、バックアップのメタデータをエクスポートすることも可能です。メタデータをエクスポートすると、エクスポートしたデータを後で Block Storage のデータベースに再度インポートしてボリュームのバックアップを通常のように復元することができます。

注記

ボリュームのスナップショットに関する詳しい情報は、「ボリュームスナップショットの作成、使用、削除」を参照してください。

2.4.1.1. ボリュームの完全バックアップの作成

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

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

バックアップするボリュームの ID または 表示名 を確認します。
```
# cinder list
```

以下のコマンドを実行して、ボリュームをバックアップします。

# cinder backup-create VOLUME

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

  +-----------+--------------------------------------+
  |  Property |                Value                 |
  +-----------+--------------------------------------+
  |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
  |    name   |                 None                 |
  | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
  +-----------+--------------------------------------+

注記

作成されるバックアップの volume_id は、ソースボリュームの ID と全く同じになります。

以下のコマンドを実行して、ボリュームのバックアップ作成が完了したことを確認します。
```
# cinder backup-list
```
バックアップエントリーの ステータス が available に変わったら、ボリュームのバックアップ作成は完了です。

この時点で、ボリュームのバックアップのメタデータをエクスポートして保管することもできます。これにより、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 の値で構成されます。

2.4.1.1.1. admin としてのボリュームのバックアップ作成

管理者権限のあるユーザー (例: デフォルトの admin アカウントなど) は、OpenStack で管理されている任意のボリュームをバックアップすることができます。admin ユーザーが、admin 以外のユーザーの所有するボリュームをバックアップする場合には、そのボリュームの所有者からはバックアップはデフォルトでは表示されないように設定されます。

また、admin ユーザーとしてバックアップしたボリュームを、特定のテナントが利用できるようにすることも可能です。そのためには、以下のコマンドを実行します。

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

上記の設定で、

TENANTNAME は、バックアップを利用できるテナントの名前に置き換えます。
USERNAME と PASSWD は、TENANTNAME 内のユーザーのユーザー名とパスワードに置き換えます。
VOLUME は、バックアップするボリュームの名前または ID に置き換えます。
KEYSTONEURL は、Identity サービスの URL エンドポイントに置き換えます (通常は http://IP:5000/v2 の形式。IP は Identity サービスホストの IP アドレス)。

この操作を実行する場合は、作成されるバックアップの容量は、admin テナントではなく、TENANTNAME のクォータに対して加算されます。

2.4.1.2. ボリュームの増分バックアップの作成

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

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

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

# cinder backup-create VOLUME --incremental

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

注記

増分バックアップがすでに作成されている場合には、ベースとなっている完全バックアップを削除することはできません。また、完全バックアップに複数の増分バックアップがある場合、削除できるのは、最新の増分バックアップのみとなります。

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

2.4.1.3. Block Storage データベースでデータ損失が発生した後の復元

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

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

管理者権限を持つユーザーとして以下のコマンドを実行します。

# cinder --os-volume-api-version 2 backup-import backup_service backup_url

backup_service および backup_url は、エクスポートしたメタデータに置き換えます。たとえば、「ボリュームの完全バックアップの作成」でエクスポートしたメタデータを使用します。

# cinder --os-volume-api-version 2 backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
+----------+--------------------------------------+
| Property |                Value                 |
+----------+--------------------------------------+
|    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
|   name   |                 None                 |
+----------+--------------------------------------+

メタデータが Block Storage サービスのデータベースにインポートされたら、通常のようにボリュームを復元することができます (「バックアップからのボリュームの復元」を参照)。

2.4.1.4. バックアップからのボリュームの復元

使用するボリュームバックエンドの ID を確認します。
```
# cinder backup-list
```
Volume ID は、復元するボリュームの ID と一致する必要があります。
ボリュームのバックアップを復元します。
```
# cinder backup-restore BACKUP_ID
```
BACKUP_ID は使用するボリュームのバックアップ ID に置き換えます。
バックアップが必要なくなった場合には、削除します。
```
# cinder backup-delete BACKUP_ID
```

2.4.2. ボリュームの移行

Block Storage サービスでは、ホストまたはバックエンドの間でボリュームを移行することができます。現在使用中 (インスタンスに接続されている) ボリュームを移行することができますが、スナップショットがあるボリュームは移行できません。

ホスト間でボリュームを移行する際には、いずれのホストも同じバックエンドに配置する必要があります。これには以下のステップを実行します。

Dashboard で 管理 > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリュームの管理 を選択します。
ボリュームの管理 ダイアログでは、移行先ホスト ドロップダウンリストからボリュームを移行する先のホストを選択します。
注記
ホストの移行でドライバーの最適化をスキップするには、強制ホストコピー のチェックボックスを選択します。
移行をクリックして移行を開始します。

2.4.2.1. バックエンド間での移行

バックエンド間でボリュームを移行するには ボリューム種別の変更 を行う必要があります。つまり。新規バックエンドを移行するには、以下が前提となります。

新規バックエンドは、別の 移行先のボリューム種別 の 追加スペック として指定する必要があります。
移行先のボリューム種別に定義された、その他の追加スペックは、ボリュームの移行元のボリューム種別と互換性がなければなりません。

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

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

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

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

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリューム種別の変更 を選択します。
ボリューム種別の変更 ダイアログで、種別のドロップダウンリストから新しいバックエンドを定義する、移行先のボリューム種別を選択します。
移行ポリシー から 要求時 を選択します。
ボリューム種別の変更 をクリックして移行を開始します。

第2章 Block Storage とボリューム

2.1. バックエンド

2.2. Block Storage サービスの管理

2.2.1. ボリューム種別へのボリューム設定の関連付け

2.2.1.1. ホストドライバーの機能一覧

2.2.1.2. ボリューム種別の作成と設定

2.2.1.3. ボリューム種別の編集

2.2.1.4. ボリューム種別の削除

2.2.1.5. プライベートのボリューム種別の作成と設定

2.2.2. Block Storage サービスの内部テナントの作成および設定

2.2.3. Image-Volume キャッシュの設定および有効化

2.2.4. QoS スペックの使用

2.2.4.1. QoS スペックの作成と設定

2.2.4.2. QoS スペックとボリューム種別の関連付け

2.2.4.3. ボリューム種別からの QoS スペックの関連付け解除

2.2.5. 静的キーを使用したボリュームの暗号化

2.2.5.1. 静的キーの設定

2.2.5.2. ボリューム種別の暗号化設定

2.2.6. ボリュームを複数のバックエンドに割り当てる方法の設定

2.2.7. バックアップの管理

2.2.7.1. テナントのバックアップクォータの表示と変更

2.2.7.2. Dashboard を使用したボリュームバックアップ管理の有効化

2.2.7.3. バックアップリポジトリーとしての NFS 共有の設定

2.2.7.3.1. 異なるバックアップファイルサイズの設定

2.3. ボリュームの基本的な使用方法と設定

2.3.1. ボリュームの作成

2.3.2. ボリュームを作成するバックエンドの指定

2.3.3. ボリュームの名前と説明の編集

2.3.4. ボリュームの削除

2.3.5. インスタンスへのボリュームの接続と切断

2.3.5.1. インスタンスへのボリュームの接続

2.3.5.2. インスタンスからのボリュームの切断

2.3.6. ボリュームの読み取り専用設定

2.3.7. ボリュームの所有者の変更

2.3.7.1. コマンドラインを使用したボリュームの譲渡

2.3.7.2. ダッシュボードを使用したボリュームの譲渡

2.3.8. ボリュームスナップショットの作成、使用、削除

2.3.8.1. Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除

2.3.9. Image サービスにボリュームをアップロードする手順

2.3.10. ボリューム種別の変更

2.4. ボリュームの高度な設定

2.4.1. ボリュームのバックアップと復元

2.4.1.1. ボリュームの完全バックアップの作成

2.4.1.1.1. admin としてのボリュームのバックアップ作成

2.4.1.2. ボリュームの増分バックアップの作成

2.4.1.3. Block Storage データベースでデータ損失が発生した後の復元

2.4.1.4. バックアップからのボリュームの復元

2.4.2. ボリュームの移行

2.4.2.1. バックエンド間での移行

Comments

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links