検索

Block Storage ボリュームのバックアップ

download PDF
Red Hat OpenStack Platform 17.1

Red Hat OpenStack Platform Block Storage (cinder) バックアップサービスのデプロイおよび使用

OpenStack Documentation Team

概要

Block Storage ボリュームをバックアップおよび復元するために、Red Hat OpenStack Platform Block Storage バックアップサービスをデプロイして使用します。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

Jira でドキュメントのフィードバックを提供する

ドキュメントに関するフィードバックを提供するには、Create Issue フォームを使用します。Red Hat OpenStack Platform Jira プロジェクトで Jira Issue が作成され、フィードバックの進行状況を追跡できます。

  1. Jira にログインしていることを確認してください。Jira アカウントをお持ちでない場合は、アカウントを作成してフィードバックを送信してください。
  2. Create Issue をクリックして、Create Issue ページを開きます。
  3. Summary フィールドと Description フィールドに入力します。Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。フォーム内の他のフィールドは変更しないでください。
  4. Create をクリックします。

第1章 Block Storage バックアップサービスの概要

Red Hat OpenStack Platform (RHOSP) の Block Storage サービス (cinder) は、コントローラーノードにデプロイできるオプションのバックアップサービスを提供します。

Block Storage バックアップサービスを使用して、Block Storage ボリュームのフルバックアップまたは増分バックアップを作成および復元できます。

ボリュームバックアップは、バックアップリポジトリーに保存される Block Storage ボリュームのコンテンツの永続コピーです。

Block Storage バックアップサービスの一部の機能は、バックアップのパフォーマンスに影響を及ぼす可能性があります。詳細は、バックアップのパフォーマンスに関する考慮事項 を参照してください。

1.1. バックアップリポジトリーのバックエンド

デフォルトでは、バックアップリポジトリーは Red Hat OpenStack Platform Object Storage サービス (swift) バックエンドを使用し、ボリュームのバックアップがオブジェクトストアとして作成されます。ただし、バックアップリポジトリーのバックエンドとして Red Hat Ceph Storage、NFS、または S3 を使用することを選択できます。

Block Storage のバックアップサービスは、バックアップリポジトリーに使用するためにどのバックエンドを選んだかに関係なく、Block Storage サービス (cinder) がサポートする任意のバックエンドのボリュームをバックアップできます。

1.2. Block Storage ボリュームのバックアップメタデータ

Block Storage ボリュームのバックアップを作成すると、このバックアップのメタデータは Block Storage サービスデータベースに保存されます。Block Storage バックアップサービスは、バックアップからボリュームを復元する際に、このメタデータを使用します。

重要

Block Storage サービスデータベースの壊滅的な損失が発生した場合でもバックアップが確実に存続するように、このバックアップのメタデータを手動でエクスポートして保存できます。データベースが壊滅的に失われた後は、新しい Block Storage データベースを作成し、そのデータベースにこのバックアップメタデータを手動で再インポートする必要があります。詳細は、バックアップの保護 を参照してください。

第2章 Block Storage バックアップサービスのデプロイ

Block Storage (cinder) バックアップサービスはオプションです。コントローラーノードにデプロイするには、これを Red Hat OpenStack Platform (RHOSP) オーバークラウドデプロイメントに含める必要があります。

2.1. active-active Block Storage バックアップサービスのデプロイ

Red Hat OpenStack Platform (RHOSP) 17.1 より前のバージョンでは、Block Storage バックアップサービスは active-passive モードでデプロイされ、Pacemaker により管理されていました。

RHOSP 17.1 では、Block Storage バックアップサービスは active-active モードでデプロイされるため、各コントローラーノードで実行され、Pacemaker で管理されません。

注記

RHOSP 17.1 にアップグレードする場合、Block Storage バックアップサービスは active-passive モードのままになります。

Block Storage バックアップサービスを使用することを選択した場合は、それを RHOSP 17.1 のオーバークラウドのデプロイメントに追加する必要があります。

前提条件

  • Object Storage (swift)、Red Hat Ceph Storage、NFS、または S3 のいずれかのバックエンドを使用するバックアップリポジトリーで利用可能なストレージソース。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. この環境ファイルを他の環境ファイルと一緒にスタックに追加します: /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml

    このファイルは、Block Storage バックアップサービスを active-active モードでデプロイし、このサービスのすべての heat テンプレートパラメーターをデフォルト設定に設定します。デフォルト設定では、Object Storage (swift) バックエンドおよび zlib データ圧縮アルゴリズムを使用するようにバックアップリポジトリーを設定します。

    デフォルト設定がデプロイメント要件を満たしている場合は、それ以上何もする必要はなく、オーバークラウドをデプロイできます。

  4. バックアップリポジトリーに別のバックエンドを使用する必要がある場合や、他のデフォルト値を変更する必要がある場合は、以下を行います。

    1. これらのパラメーターと新しい値を、新規または既存の環境ファイルの parameter_defaults セクションに追加します。変更可能なパラメーターの詳細は、デフォルトの Block Storage バックアップサービスのパラメーター値の変更 を参照してください。

      たとえば、新しい環境ファイル /home/stack/templates/custom_backup_environment_file.yaml は、NFS バックエンドを指定し、データ圧縮アルゴリズムを zstd に変更します。

      parameter_defaults:
        CinderBackupBackend: nfs
        CinderBackupNfsShare: 192.168.1.1:/var/export/cinder-backup
        CinderBackupCompressionAlgorithm: zstd
    2. /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml ファイルの後に、特定のパラメーター値を含む環境ファイルを他の環境ファイルと一緒にスタックに追加し、オーバークラウドをデプロイします。この例では、以下のように設定されています。

      $ openstack overcloud deploy --templates
      -e [your other environment files]
      -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml
      -e /home/stack/templates/custom_backup_environment_file.yaml

検証:

2.2. デフォルトの Block Storage バックアップサービスのパラメーター値の変更

Block Storage バックアップサービスをデプロイする場合、その heat テンプレートパラメーターのデフォルト設定を実装します。詳細は、active-active Block Storage バックアップサービスのデプロイ を参照してください。

これらのパラメーターにデプロイメント固有の値を指定できます。

手順

  1. バックアップリポジトリーのバックエンドを選択して設定します。詳細は、バックアップリポジトリーの back-end 設定 を参照してください。
  2. 選択したバックエンドでサポートされる Block Storage バックアップサービス設定を実装します。詳細は、Block Storage バックアップサービスの設定 を参照してください。

2.2.1. バックアップリポジトリーの back-end 設定

バックアップリポジトリー用に以下のバックエンドのいずれかを選択して設定します。

2.2.1.1. OpenStack Object Storage サービス (swift) のバックエンド

パラメーター

説明

CinderBackupBackend

バックアップリポジトリーのバックエンド。

注記

このデフォルトバックエンドには、追加のパラメーターはありません。

swift

デフォルトの値です。

2.2.1.2. NFS バックエンド

パラメーター

説明

CinderBackupBackend

バックアップリポジトリーのバックエンド。

nfs

CinderBackupNfsShare

バックアップを保存するためにマウントするリモート NFS 共有。

エクスポートの前に必ずサーバー名または IP を指定してください。

 

CinderBackupNfsMountOptions

オプション: NFS 共有をマウントするオプションのコンマ区切りリスト。

 

2.2.1.3. Red Hat Ceph Storage バックエンド

パラメーター

説明

CinderBackupBackend

バックアップリポジトリーのバックエンド。

ceph

CinderBackupRbdPoolName

バックアップを保存する Ceph クラスターの RBD プール名。

backups

2.2.1.4. S3 バックエンド

パラメーター

説明

CinderBackupBackend

バックアップリポジトリーのバックエンド。

s3

CinderBackupS3Bucket

バックアップを保存する S3 バケット。

注記

Block Storage バックアップサービスをデプロイする前に、S3 バックエンドでこのバケットを作成し、このバケットに書き込むために必要なパーミッションが設定されていることを確認します。

volumebackups

CinderBackupS3AccessKey

S3 バケットに接続するための S3 アクセスキー。

 

CinderBackupS3SecretKey

S3 バケットに接続するための S3 シークレットキー。

 

CinderBackupS3EndpointUrl

S3 エンドポイントの URL。

 

2.2.2. Block Storage バックアップサービスの設定

選択したバックエンドでサポートされる Block Storage バックアップサービスパラメーターを実装できます。

パラメーター

説明

CinderBackupCompressionAlgorithm

バックエンドがサポートしている場合は、バックアップリポジトリーのデータ圧縮を有効にできます。

データ圧縮には追加の CPU 電力が必要ですが、使用するネットワーク帯域幅およびストレージ領域は少なくなります。

注記

Red Hat Ceph Storage バックエンドドライバーのデータ圧縮アルゴリズムを指定することはできません。このパラメーターは、このバックエンドでは無視されます。

zlib

または、

nonebzip2zstd

第3章 Block Storage バックアップサービスの使用

Block Storage のバックアップサービスを使用して、フルバックアップまたは増分バックアップを実行し、バックアップを保護してバックアップをボリュームに復元できます。

3.1. バックアップの作成

ボリュームに障害が発生した場合にデータが失われるのを防ぐために、Block Storage ボリュームのバックアップを作成します。詳細は、ボリュームのフルバックアップの作成 を参照してください。ボリュームのスナップショットから直接、バックアップを作成することもできます。詳細は、フルスナップショットバックアップの作成 を参照してください。ボリュームデータに加えて、バックアップは名前や説明などのボリュームメタデータも保存します。

バックアップリポジトリーのデータ圧縮を有効にしている場合、バックアップが圧縮されるため、パフォーマンスが低下する可能性があります。

フルバックアップの管理は簡単ですが、ボリュームのサイズが時間の経過と共に増加すると、リソースを大量に消費する可能性があります。増分バックアップを使用すると、ボリュームへの定期的な変更をキャプチャーして、リソースの使用を最小限にとどめることができます。詳細は、増分バックアップ を参照してください。

アクセス可能なボリュームのバックアップを作成できます。プロジェクト管理者は、プロジェクトに属する任意のボリュームをバックアップできます。これらのバックアップは、管理者がバックアップの作成時に追加の引数を指定しない限り、ボリューム所有者には表示されません。詳細は、ボリューム所有者を認証するためのバックアップ引数 を参照してください。

各プロジェクト (tenant) は、バックアップの最大数と、そのプロジェクト用に作成可能なすべてのバックアップの最大合計サイズを制限します。プロジェクト管理者は、これらのクォータを表示し、変更できます。詳細は、プロジェクトのバックアップクォータの表示および変更 を参照してください。

バックアップできるのは通常、available ステータスを持つボリュームのみですが、必要な場合は in-use ステータスのボリュームをバックアップできます。詳細は、in-use ボリュームのバックアップの作成 を参照してください。

Block Storage ボリュームのバックアップを作成すると、このバックアップのメタデータは Block Storage サービスデータベースに保存されます。これは、このボリュームを復元する際に使用されます。Block Storage サービスデータベースが壊滅的に失われた場合でもバックアップが確実に存続するように、プロジェクト管理者はこのバックアップのメタデータを手動でエクスポートして保存できます。詳細は、バックアップの保護 を参照してください。

3.1.1. ボリュームのフルバックアップの作成

ボリュームのフルバックアップを 1 つ以上作成できます。

前提条件

  • ボリュームをバックアップできるのは、ボリュームの所有者とプロジェクト管理者のみ。
  • 必要な領域がバックアップリポジトリーにある。
  • プロジェクトに指定されたバックアップクォータを超えていない。詳細は、プロジェクトのバックアップクォータの表示および変更 を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. ボリュームを一覧表示し、バックアップを作成するボリュームの ID または名前を取得します。

    $ openstack volume list
    注記

    通常、available ステータスを持つボリュームのみをバックアップできますが、必要な場合は in-use ステータスのボリュームをバックアップできます。詳細は、in-use ボリュームのバックアップの作成 を参照してください。

  4. ボリュームをバックアップします。

    注記

    ボリューム所有者ではなくプロジェクト管理者である場合、ボリューム所有者がこのバックアップにアクセスできるようにするには、このバックアップの作成時に追加のパラメーターを指定する必要があります。詳細は、ボリューム所有者を認証するためのバックアップ引数 を参照してください。

    $ openstack volume backup create [--name <backup_name>] <volume>
    • <volume> を、バックアップするボリュームの ID または名前に置き換えます。
    • オプション: <backup_name> をこのバックアップの名前に置き換えます。

      このコマンドは、このバックアップの ID を即座に提供しますが、ボリュームはバックグラウンドで非同期にバックアップされます。以下に例を示します。

      $ openstack volume backup create --name vol1bu2 vol_1
      +-------+--------------------------------------+
      | Field | Value                                |
      +-------+--------------------------------------+
      | id    | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb |
      | name  | vol1bu2                              |
      +-------+--------------------------------------+

検証

  • バックアップを一覧表示します。

    $ openstack volume backup list

    このバックアップのステータスが available になると、ボリュームバックアップが作成されます。以下に例を示します。

    +--------------------------------------+---------+-------------+-----------+------+
    | ID                                   | Name    | Description | Status    | Size |
    +--------------------------------------+---------+-------------+-----------+------+
    | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb | vol1bu2 | None        | available |    1 |
    | b604a932-94a5-468e-bf6b-841ac16f69a8 | None    | None        | available |    1 |
    +--------------------------------------+---------+-------------+-----------+------+

3.1.2. フルスナップショットバックアップの作成

スナップショットに関連付けられたボリュームの ID を使用して、スナップショットからフルバックアップを作成できます。

バックアップは、スナップショットに直接アタッチして作成されます。これは、スナップショットのクローンをボリュームに作成してからこのボリュームをバックアップするよりも速く作成できます。ただし、この機能は、スナップショットからボリュームを作成するという追加の手順が必要なため、バックアップのパフォーマンスに影響を及ぼす可能性があります。

前提条件:

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. スナップショットを一覧表示し、バックアップを作成するスナップショットの名前または ID を取得します。

    $ openstack volume snapshot list
  4. このスナップショットの詳細を一覧表示し、このスナップショットに関連付けられたボリュームの ID を取得します。

    $ openstack volume snapshot show <snapshot>
    • <snapshot> をバックアップするスナップショットの名前または ID に置き換えます。

      volume_id フィールドの値は、このスナップショットに関連付けられたボリュームの ID です。以下に例を示します。

      $ openstack volume snapshot show snap_1
      +--------------------------------------------+--------------------------------------+
      | Field                                      | Value                                |
      +--------------------------------------------+--------------------------------------+
      | created_at                                 | 2023-07-18T08:14:16.000000           |
      | description                                | None                                 |
      | id                                         | 2d95b707-6657-49af-ac8f-f9a7417d4650 |
      | name                                       | snap_1                               |
      | os-extended-snapshot-attributes:progress   | 100%                                 |
      | os-extended-snapshot-attributes:project_id | c2c1da89ed1648fc8b4f35a045f8d34c     |
      | properties                                 |                                      |
      | size                                       | 1                                    |
      | status                                     | available                            |
      | updated_at                                 | 2023-07-18T08:14:17.000000           |
      | volume_id                                  | 6841e3d1-8a1a-4496-bc51-f7c04b787e8f |
      +--------------------------------------------+--------------------------------------+
  5. スナップショットをバックアップします。

    $ openstack volume backup create [--name <backup_name>] --snapshot <snapshot> <volume_id>
    • <volume_id> をこのスナップショットに関連付けられたボリュームの ID に置き換えます。
    • オプション: <backup_name> をこのバックアップの名前に置き換えます。

      このコマンドは、このバックアップの ID を即座に提供しますが、スナップショットはバックグラウンドで非同期にバックアップされます。以下に例を示します。

      $ openstack volume backup create --name snap1bu1 --snapshot snap_1 6841e3d1-8a1a-4496-bc51-f7c04b787e8f
      +-------+--------------------------------------+
      | Field | Value                                |
      +-------+--------------------------------------+
      | id    | 867e6cfb-9be7-47fa-8a79-221b0e80c757 |
      | name  | snap1bu1                             |
      +-------+--------------------------------------+

検証

  • バックアップを一覧表示します。

    $ openstack volume backup list

    このバックアップのステータスが available になると、スナップショットのバックアップが作成されます。以下に例を示します。

    +--------------------------------------+------------+-------------+-----------+------+
    | ID                                   | Name       | Description | Status    | Size |
    +--------------------------------------+------------+-------------+-----------+------+
    | 867e6cfb-9be7-47fa-8a79-221b0e80c757 | snap1bu1    | None        | available |    1 |
    +--------------------------------------+------------+-------------+-----------+------+

3.1.3. in-use ボリュームのバックアップの作成

通常、バックアップできるのは available ステータスのボリュームのみです。ただし、バックアップの作成時に --force オプションを使用して、ステータスが in-use のボリュームをバックアップすることができます。

--force ボリュームバックアップオプションを使用すると、バックアップの実行前にボリュームが静止されないため、クラッシュ整合性のあるバックアップは作成されますが、アプリケーション整合性のあるバックアップは作成されません。したがって、データはそのままですが、バックアップの実行時にどのアプリケーションが実行されていたかは、バックアップでは認識されません。

前提条件

  • ボリュームをバックアップできるのは、ボリュームの所有者とプロジェクト管理者のみ。
  • 必要な領域がバックアップリポジトリーにある。
  • プロジェクトに指定されたバックアップクォータを超えていない。詳細は、プロジェクトのバックアップクォータの表示および変更 を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. ボリュームを一覧表示し、バックアップを作成するボリュームの ID または名前を取得します。

    $ openstack volume list

    以下に例を示します。

    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | ID                                   | Name           | Status    | Size | Attached to                    |
    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | 6841e3d1-8a1a-4496-bc51-f7c04b787e8f | vol_1          | available |    1 |                                |
    | 92800cf6-82ae-448a-a2bb-872fa4d98099 | Pansible_vol_2 | in-use    |    1 | Attached to inst1 on /dev/vdc  |
    +--------------------------------------+----------------+-----------+------+--------------------------------+
  4. バックアップするボリュームのステータスが in-use の場合は、強制的にバックアップします。

    $ openstack volume backup create [--name <backup_name>] --force <volume>
    • <volume> を、バックアップするボリュームの ID または名前に置き換えます。
    • オプション: <backup_name> をこのバックアップの名前に置き換えます。

      このコマンドは、このバックアップの ID を即座に提供しますが、ボリュームはバックグラウンドで非同期にバックアップされます。以下に例を示します。

      $ openstack volume backup create --name panvol2bu1 --force Pansible_vol_2
      +-------+--------------------------------------+
      | Field | Value                                |
      +-------+--------------------------------------+
      | id    | 8c72bbf3-eb8e-4459-83e9-c7654ebe6343 |
      | name  | panvol2bu1                           |
      +-------+--------------------------------------+

検証

  • バックアップを一覧表示します。

    $ openstack volume backup list

    このバックアップのステータスが available になると、ボリュームバックアップが作成されます。以下に例を示します。

    +--------------------------------------+------------+-------------+-----------+------+
    | ID                                   | Name       | Description | Status    | Size |
    +--------------------------------------+------------+-------------+-----------+------+
    | 8c72bbf3-eb8e-4459-83e9-c7654ebe6343 | panvol2bu1    | None        | available |    1 |
    +--------------------------------------+------------+-------------+-----------+------+

3.1.4. 増分バックアップ

ボリュームに少なくとも 1 つのフルバックアップがある場合は、Block Storage バックアップサービスを使用して、増分バックアップを作成できます。詳細は、増分バックアップの作成 を参照してください。

フルバックアップの管理は簡単ですが、ボリュームのサイズが時間の経過と共に増加すると、リソースを大量に消費する可能性があります。増分バックアップを使用すると、ボリュームへの定期的な変更をキャプチャーして、リソースの使用量を最小限にとどめることができます。

増分バックアップは、最後のフルバックアップまたは増分バックアップ以降にボリュームに加えられた変更のみを保存します。

増分バックアップは、バックアップの管理に必要な管理オーバーヘッドを増やします。たとえば、フルバックアップにすでに 1 つ以上の増分バックアップがある場合は、フルバックアップを削除することはできず、最新の増分バックアップのみを削除できます。

増分バックアップはフルバックアップよりもパフォーマンスが低下します。増分バックアップを作成する際は、まずボリューム内のすべてのデータを読み取り、フルバックアップと後続の各増分バックアップの両方のデータと比較する必要があります。

3.1.4.1. 増分バックアップの作成

増分バックアップを作成して、最後のフルバックアップまたは増分バックアップ以降にボリュームに加えられた変更のみを保存することができます。

前提条件:

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. ボリュームを一覧表示し、バックアップを作成するボリュームの ID または名前を取得します。

    $ openstack volume list
  4. ボリュームをバックアップし、--incremental オプションを使用します。

    $ openstack volume backup create --incremental [--name <backup_name>] <volume>
    • <volume> を、バックアップするボリュームの ID または名前に置き換えます。
    • オプション: <backup_name> をこのバックアップの名前に置き換えます。

      このコマンドは、このバックアップの ID を即座に提供しますが、ボリュームはバックグラウンドで非同期にバックアップされます。以下に例を示します。

      $ openstack volume backup create --name vol3incbu1 --incremental vol_3
      +-------+--------------------------------------+
      | Field | Value                                |
      +-------+--------------------------------------+
      | id    | f1681313-b5ed-4520-9b63-5b533f7cdc11 |
      | name  | vol3incbu1                           |
      +-------+--------------------------------------+

検証

  • バックアップを一覧表示します。

    $ openstack volume backup list

    このバックアップのステータスが available になると、ボリュームバックアップが作成されます。以下に例を示します。

    +--------------------------------------+---------+-------------+-----------+------+
    | ID                                   | Name    | Description | Status    | Size |
    +--------------------------------------+---------+-------------+-----------+------+
    | f1681313-b5ed-4520-9b63-5b533f7cdc11 | vol3incbu1 | None        | available |    1 |
    | f0e9ba67-67e1-4c2c-96ce-221df75bf2c2 | vol3bu1    | None        | available |    1 |
    +--------------------------------------+---------+-------------+-----------+------+

3.1.5. バックアップのパフォーマンスに関する考慮事項

増分バックアップやデータ圧縮などの Block Storage バックアップサービスの一部の機能は、バックアップのパフォーマンスを低下させる可能性があります。

ボリュームへの定期的な変更のみをキャプチャーすることで、増分バックアップはリソースの使用量を最小限に抑えることができます。詳細は、増分バックアップ を参照してください。ただし、増分バックアップはフルバックアップよりもパフォーマンスが低下します。増分バックアップを作成する際は、まずボリューム内のすべてのデータを読み取り、フルバックアップと後続の各増分バックアップの両方のデータと比較する必要があります。

スナップショットに直接アタッチすることで、バックアップをスナップショットから作成することもできます。これは、スナップショットのクローンをボリュームに作成するよりも速くできます。詳細は、フルスナップショットバックアップの作成 を参照してください。ただし、この機能は、スナップショットからボリュームを作成するという追加の手順が必要なため、バックアップのパフォーマンスに影響を及ぼす可能性があります。

バックアップリポジトリーのデータ圧縮を有効にするには、追加の CPU 電力が必要ですが、使用するネットワーク帯域幅とストレージ領域は全体で少なくなります。Block Storage バックアップサービスを設定して、バックアップリポジトリーのデータ圧縮を有効または無効にすることができます。詳細は、Block Storage バックアップサービスの設定 を参照してください。

注記

Red Hat Ceph Storage バックエンドではデータ圧縮を使用できません。

3.1.6. ボリューム所有者を認証するためのバックアップ引数

プロジェクト管理者は、プロジェクトに属する任意のボリュームをバックアップできますが、これらのバックアップはボリューム所有者には表示されません。

ボリューム所有者もボリュームバックアップにアクセスできるようにするには、プロジェクト管理者は、ボリュームのバックアップ時に以下の追加の引数を指定して、ボリューム所有者として認証する必要があります。

$ openstack --os-auth-url <keystoneurl> --os-project-name <projectname> --os-username <username> --os-password <password> volume backup create [--name <backup_name>] <volume>
  • <keystoneurl> を Identity サービスの URL エンドポイント (通常は http://IP:5000/v3) に置き換えます。ここの IP は、Identity サービスホストの IP アドレスになります。
  • <projectname> をボリューム所有者のプロジェクト (tenant) の名前に置き換えます。
  • <username><password> をこのプロジェクト内のボリューム所有者であるユーザーのユーザー名とパスワードの認証情報に置き換えます。
注記

[--name <backup_name>] <volume> は、ボリュームバックアップを作成するときの一般的な引数です。

3.1.7. プロジェクトのバックアップクォータの表示および変更

プロジェクト管理者は、特定のプロジェクト (tenant) 用に作成可能なバックアップの最大数とすべてのバックアップの最大合計サイズ (ギガバイト単位) を変更または表示し、このプロジェクトのバックアップクォータの使用状況を確認できます。

前提条件

  • プロジェクトのバックアップクォータを表示または変更するには、プロジェクト管理者である必要がある。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. 必要なプロジェクトの ID または名前を取得するプロジェクトを一覧表示します。

    $ openstack project list
  4. 特定のプロジェクトのバックアップクォータを表示します。

    $ openstack quota show <project>
    • <project> を必要なプロジェクトの ID または名前に置き換えます。

    テーブルの backup-gigabytes フィールドの値は、このプロジェクトで作成できるすべてのバックアップの最大合計サイズです。テーブルの backups フィールドの値は、このプロジェクトで作成できるバックアップの最大数です。以下に例を示します。

    +

    $ openstack quota show c2c1da89ed1648fc8b4f35a045f8d34c
    +-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Field                 | Value                                                                                                                                                                                               |
    +-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | backup-gigabytes      | 1000                                                                                                                                                                                                |
    | backups               | 10
  5. プロジェクト用に作成されたすべてのバックアップの最大合計サイズを変更します。

    $ openstack quota set --backup-gigabytes <maxgb> <project>
    • <maxgb> をこのプロジェクト用に作成可能なバックアップの最大合計サイズ (ギガバイト単位) に置き換えます。
  6. プロジェクト用に作成可能なバックアップの最大数を変更します。

    $ openstack quota set --backups <maxnum> <project>
    • <maxnum> を、このプロジェクト用に作成可能なバックアップの最大数に置き換えます。
  7. 特定のプロジェクトのこれらのバックアップクォータの使用状況を表示します。

    $ cinder quota-usage <project_id>
    • <project_id> をプロジェクトの ID に置き換えます。

      以下に例を示します。

      $ cinder quota-usage c2c1da89ed1648fc8b4f35a045f8d34c
      +-----------------------+--------+----------+-------+-----------+
      | Type                  | In_use | Reserved | Limit | Allocated |
      +-----------------------+--------+----------+-------+-----------+
      | backup_gigabytes      | 7      | 0        | 1000   |           |
      | backups               | 7      | 0        | 10    |           |
      | gigabytes             | 6      | 0        | 1000  |           |
      | gigabytes_multiattach | 0      | 0        | -1    |           |
      | gigabytes_tripleo     | 6      | 0        | -1    |           |
      | groups                | 0      | 0        | 10    |           |
      | per_volume_gigabytes  | 0      | 0        | -1    |           |
      | snapshots             | 1      | 0        | 10    |           |
      | snapshots_multiattach | 0      | 0        | -1    |           |
      | snapshots_tripleo     | 1      | 0        | -1    |           |
      | volumes               | 5      | 0        | 10    |           |
      | volumes_multiattach   | 0      | 0        | -1    |           |
      | volumes_tripleo       | 5      | 0        | -1    |           |
      +-----------------------+--------+----------+-------+-----------+

検証

  • これらのクォータのいずれかを変更した場合は、これらの変更を確認してください。

    $ openstack quota show <project>

    変更された値がテーブルの backup-gigabytes フィールドおよび backups フィールドで指定されていることを確認します。以下に例を示します。

    +-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Field                 | Value                                                                                                                                                                                               |
    +-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | backup-gigabytes      | 500                                                                                                                                                                                                 |
    | backups               | 12

3.1.8. バックアップのキャンセル

バックアップをキャンセルするには、バックアップの強制削除を要求する必要があります。

重要

バックアップリポジトリーに Red Hat Ceph Storage バックエンドを使用する場合は、バックアップをキャンセルできません。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. バックアップを一覧表示し、キャンセルするバックアップの ID または名前を取得します。

    $ openstack volume backup list
  4. バックアップをキャンセルします。

    # openstack volume backup delete --force <backup>
    • <backup> をキャンセルするボリュームバックアップの ID または名前に置き換えます。

      バックアップを正常にキャンセルするまでにわずかな遅延が生じる可能性があります。

検証

  • 以下のコマンドによりバックアップレコードが一覧表示されない場合、バックアップはキャンセルされます。

    $ openstack volume backup show <backup>

3.2. エッジサイト間のバックアップおよびリストア

エッジサイトの分散コンピュートノード (DCN) アーキテクチャーおよびアベイラビリティーゾーン間で、Block Storage サービス (cinder) ボリュームをバックアップしてリストアすることができます。cinder-backup サービスは中央のアベイラビリティーゾーン (AZ) で実行され、バックアップは中央の AZ に保存されます。Block Storage サービスは、DCN サイトにバックアップを保存しません。

前提条件

  • オプションの Block Storage バックアップサービスをデプロイします。詳細は、Block Storage ボリュームのバックアップBlock Storage バックアップサービスのデプロイ を参照してください。
  • Block Storage (cinder) REST API マイクロバージョン 3.51 以降。
  • すべてのサイトは共通の openstack cephx クライアント名を使用する必要があります。詳細は、分散コンピュートノード (DCN) アーキテクチャーのデプロイ外部アクセス用 Ceph キーの作成 を参照してください。

手順

  1. 最初の DCN サイトのボリュームのバックアップを作成します。

    $ cinder --os-volume-api-version 3.51 backup-create --name <volume_backup> --availability-zone <az_central> <edge_volume>
    • <volume_backup> をボリュームバックアップの名前に置き換えます。
    • <az_central> を、cinder-backup サービスをホストする中央アベイラビリティーゾーンの名前に置き換えます。
    • <edge_volume> をバックアップするボリュームの名前に置き換えます。

      注記

      Ceph キーリングに問題がある場合には、cinder-backup コンテナーを再起動して、キーリングがホストからコンテナーに正常にコピーされるようにする必要がある場合があります。

  2. 2 番目の DCN サイトの新規ボリュームにバックアップを復元します。

    $ cinder --os-volume-api-version 3.51 create --availability-zone <az_2> --name <new_volume> --backup-id <volume_backup> <volume_size>
    • <az_2> を、バックアップを復元するアベイラビリティーゾーンの名前に置き換えます。
    • <new_volume> を新規ボリュームの名前に置き換えます。
    • <volume_backup> を、前のステップで作成したボリュームバックアップの名前に置き換えます。
    • <volume_size> を、元のボリュームのサイズと同じまたはそれ以上の値に置き換えます (GB 単位)。

3.3. バックアップの保護

Block Storage ボリュームのバックアップを作成すると、このバックアップのメタデータは、このボリュームの復元に使用される Block Storage サービスデータベースに保存されます。Block Storage サービスデータベースの壊滅的な損失が発生してもバックアップが存続できるようにするために、プロジェクト管理者はこのバックアップのメタデータを手動でエクスポートし、オフサイトバックアップなどの安全な場所に保存できます。詳細は、バックアップメタデータのエクスポート を参照してください。

Block Storage サービスデータベースに壊滅的な損失が発生すると、このデータベースにはバックアップの復元時に使用されるバックアップメタデータが含まれるため、バックアップを復元できなくなります。ただし、プロジェクト管理者が手動でバックアップのメタデータをエクスポートして保存した場合、プロジェクト管理者はこのメタデータを新しい Block Storage データベースにインポートし、このバックアップを使用してボリュームを復元できます。詳細は、バックアップメタデータのインポート を参照してください。

注記

増分バックアップの場合、ボリュームの復元に使用する前に、以前のすべてのバックアップのメタデータをインポートする必要があります。

3.3.1. バックアップメタデータのエクスポート

プロジェクト管理者は、バックアップのメタデータをエクスポートしてファイルに保存できるため、Block Storage データベースが壊滅的な損失を受けた場合でも、ボリュームバックアップを復元できます。詳細は、バックアップの保護 を参照してください。

注記

増分バックアップの場合は、以前のすべてのバックアップのメタデータをエクスポートする必要があります。

前提条件

  • バックアップメタデータをエクスポートするには、プロジェクト管理者である必要がある。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. バックアップを一覧表示し、バックアップの ID または名前を取得します。

    $ openstack volume backup list
  4. バックアップのメタデータをエクスポートし、これを適切な名前の YAML ファイルに保存します。

    $ openstack volume backup record export -f yaml <backup> > <filename>.yaml
    • <backup> をボリュームバックアップの ID または名前に置き換えます。
    • <filename> をYAML ファイルの名前に置き換えて、このバックアップのエクスポートされた backup_service 値と backup_url 値を保存します。

      以下に例を示します。

      $ openstack volume backup record export -f yaml vol1bu2 > vol1bu2.yaml
  5. ファイルをオフサイトバックアップなどの安全な場所にコピーします。

検証

  • ファイルを編集して、backup_service および backup_url の値がこのコマンドによって提供される値と一致することを確認します。

    $ openstack volume backup record export -f yaml <backup>

    以下に例を示します。

    $ openstack volume backup record export -f yaml vol1bu2
    backup_service: cinder.backup.drivers.ceph.CephBackupDriver
    backup_url: eyJkcml2 … YWxzZX0=

3.3.2. バックアップメタデータのインポート

プロジェクト管理者がボリュームバックアップのメタデータをエクスポートして保存している場合、Block Storage サービスデータベースが壊滅的に失われた後、プロジェクト管理者は、このバックアップを使用できるようにこのメタデータをインポートできます。

この手順を使用して、削除されたバックアップを再作成することもできます。

注記

増分バックアップの場合は、以前のすべてのバックアップのメタデータもインポートする必要があります。

前提条件

  • ボリュームバックアップメタデータを Block Storage データベースにインポートするには、プロジェクト管理者である必要がある。
  • このバックアップの backup_service および backup_url メタデータ値を指定する必要がある。詳細は、バックアップメタデータのエクスポート を参照してください。
  • このバックアップがまだ含まれていない Block Storage データベースがある。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. このバックアップのエクスポートされた backup_service および backup_url メタデータ値を保存したファイルを見つけます。
  4. このボリュームバックアップのメタデータ値を Block Storage データベースにインポートします。

    $ openstack volume backup record import <backup_service> <backup_url>
    • <backup_service> を、このボリュームバックアップの backup_service メタデータ値に置き換えます。
    • <backup_url> を、このボリュームバックアップの backup_url メタデータ値に置き換えます。

      このコマンドは、このバックアップの名前と ID を提供します。以下に例を示します。

      $ openstack volume backup record import cinder.backup.drivers.ceph.CephBackupDriver eyJkcml2 … YWxzZX0=
      +-------+--------------------------------------+
      | Field | Value                                |
      +-------+--------------------------------------+
      | id    | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb |
      | name  | vol1bu2                              |
      +-------+--------------------------------------+

次のステップ

3.4. バックアップの復元

Block Storage ボリュームのバックアップを作成したら、必要に応じてこのバックアップデータを復元できます。

以下のいずれかの方法を使用して、バックアップを復元できます。

重要

Block Storage サービスデータベースに壊滅的な損失が発生した場合、メタデータをエクスポートして保存していない限り、バックアップを復元することはできません。詳細は、バックアップの保護 を参照してください。

ボリュームバックアップの復元をキャンセルできるのは、プロジェクト管理者のみです。詳細は、バックアップの復元のキャンセル を参照してください。

3.4.1. 特定のボリュームへのバックアップの復元

ボリュームバックアップは、すでに作成済みの available ボリュームに復元できます。

暗号化したバックアップからボリュームを復元する場合は、復元先ボリュームの種類も暗号化する必要があります。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. バックアップを一覧表示し、復元するバックアップの名前または ID を取得します。

    $ openstack volume backup list

    以下に例を示します。

    +--------------------------------------+---------+-------------+-----------+------+
    | ID                                   | Name    | Description | Status    | Size |
    +--------------------------------------+---------+-------------+-----------+------+
    | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb | vol1bu2 | None        | available |    1 |
  4. ボリュームを一覧表示します。

    $ openstack volume list

    必要なボリュームのステータスが available になっていることを確認してから、このボリュームの名前または ID を取得します。以下に例を示します。

    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | ID                                   | Name           | Status    | Size | Attached to                    |
    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | 654e2be8-bc79-4528-96a7-5f773d31c201 | vol_3          | available |    1 |                                |
  5. バックアップをボリュームに復元します。

    $ openstack volume backup restore <backup> <volume>
    • <backup> を Block Storage ボリュームのバックアップの名前または ID に置き換えます。
    • <volume>available Block Storage ボリュームの名前または ID に置き換えます。

      以下に例を示します。

      $ openstack volume backup restore vol1bu2 vol_3
      +-------------+--------------------------------------+
      | Field       | Value                                |
      +-------------+--------------------------------------+
      | backup_id   | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb |
      | volume_id   | 654e2be8-bc79-4528-96a7-5f773d31c201 |
      | volume_name | vol_3                                |
      +-------------+--------------------------------------+
  6. このコマンドで指定された backup_id が復元されたバックアップの ID に対応していること、および volume_namevolume_id の値が指定されたボリュームの名前と ID に対応していることを確認してください。
  7. バックアップが必要なくなった場合は、バックアップを削除します。

    $ openstack volume backup delete <backup>

3.4.2. 新しいボリュームへのバックアップの復元

Block Storage ボリュームのバックアップを復元する際に、新しいボリュームを作成することができます。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. バックアップを一覧表示し、復元するバックアップの名前または ID を取得します。

    $ openstack volume backup list

    以下に例を示します。

    +--------------------------------------+---------+-------------+-----------+------+
    | ID                                   | Name    | Description | Status    | Size |
    +--------------------------------------+---------+-------------+-----------+------+
    | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb | vol1bu2 | None        | available |    1 |
  4. バックアップを新しいボリュームに復元します。

    $ cinder backup-restore <backup>
    • <backup> を Block Storage ボリュームのバックアップの名前または ID に置き換えます。

      以下に例を示します。

      $ cinder backup-restore vol1bu2
      +-------------+-----------------------------------------------------+
      | Property    | Value                                               |
      +-------------+-----------------------------------------------------+
      | backup_id   | 83dadc43-2aa9-4c0b-bc05-a12203a8f4cb                |
      | volume_id   | 296c853c-c749-4eb6-857a-57ec182232a6                |
      | volume_name | restore_backup_83dadc43-2aa9-4c0b-bc05-a12203a8f4cb |
      +-------------+-----------------------------------------------------+
  5. このコマンドによって提供される backup_id が、復元されたバックアップの ID に対応していることを確認します。

    volume_id の値は、作成されたボリュームの ID です。ただし、volume_name は、バックアップされたボリュームの名前に置き換えられる一時的な名前にすることができます。

  6. ボリュームを一覧表示し、ID が volume_id のボリュームが作成されていることを確認し、このボリューム名を取得します。

    $ openstack volume list

    以下に例を示します。

    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | ID                                   | Name           | Status    | Size | Attached to                    |
    +--------------------------------------+----------------+-----------+------+--------------------------------+
    | 296c853c-c749-4eb6-857a-57ec182232a6 | vol_1          | available |    1 |                                |
  7. バックアップが必要なくなった場合は、バックアップを削除します。

    $ openstack volume backup delete <backup>

3.4.3. バックアップの復元のキャンセル

プロジェクト管理者は、バックアップのステータスを error に変更することで、ボリュームバックアップの復元をキャンセルできます。ただし、Red Hat Ceph Storage がバックアップリポジトリーのバックエンドである場合は、バックアップの復元をキャンセルできません。

警告

開始後にバックアップの復元をキャンセルすると、宛先ボリュームが実際に復元されたデータ量 (存在する場合) を把握できないため、宛先ボリュームは役に立ちません。

前提条件

  • ボリュームのバックアップの復元をキャンセルするには、プロジェクト管理者である必要がある。
  • バックアップリポジトリーのバックエンドが Red Hat Ceph Storage ではないことを確認する。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. バックアップを一覧表示し、復元を停止するバックアップの名前または ID を取得します。

    $ openstack volume backup list
  4. このバックアップのステータスを error に変更し、復元操作をキャンセルします。

    $ openstack volume backup set --state error <backup>
    • <backup> を復元したくないボリュームバックアップの名前または ID に置き換えます。

    バックアップリポジトリーのバックエンドは復元をキャンセルする前にバックアップステータスの変更を検出する必要があるため、復元のキャンセルは非同期アクションになります。

検証

  • ボリュームのバックアップを一覧表示し、復元がキャンセルされたことを確認します。

    $ openstack volume backup list

    バックアップのステータスが available に変更されると、復元はキャンセルされます。

第4章 Block Storage バックアップサービスのトラブルシューティング

Block Storage サービスが正しく実行されていることを確認し、ログファイルでエラーメッセージを調べることにより、多くの問題を診断できます。

4.1. Block Storage バックアップサービスのデプロイメントの確認

デプロイメント後、または問題のトラブルシューティングを行う際は、必要な Block Storage サービスがホスト上で正しく実行されていることを確認することが重要となります。Block Storage スケジューラーサービスと同様に、Block Storage バックアップサービスがすべてのコントローラーノードで実行されていることを確認します。

必要な Block Storage サービスが正しく実行されていることを確認したら、Block Storage バックアップサービスが正常にデプロイされていることを確認する必要があります。

手順

  1. openstack volume service list コマンドを実行します。

    # openstack volume service list
    +------------------+-------------------------+------+---------+-------+----------------------------+
    | Binary           | Host                    | Zone | Status  | State | Updated At                 |
    +------------------+-------------------------+------+---------+-------+----------------------------+
    | cinder-scheduler | controller-0            | nova | enabled | up    | 2023-06-21T13:07:42.000000 |
    | cinder-scheduler | controller-1            | nova | enabled | up    | 2023-06-21T13:07:42.000000 |
    | cinder-scheduler | controller-2            | nova | enabled | up    | 2023-06-21T13:07:42.000000 |
    | cinder-backup    | controller-0            | nova | enabled | up    | 2023-06-21T13:07:46.000000 |
    | cinder-backup    | controller-1            | nova | enabled | up    | 2023-06-21T13:07:46.000000 |
    | cinder-backup    | controller-2            | nova | enabled | up    | 2023-06-21T13:07:46.000000 |
    | cinder-volume    | hostgroup@tripleo_iscsi | nova | enabled | up    | 2023-06-21T13:07:47.000000 |
    +------------------+-------------------------+------+---------+-------+----------------------------+
  2. すべてのサービスの State エントリーが up であることを確認します。確認できない場合は、関連するログファイルを確認します。これらのログファイルの場所に関する詳細は、オーバークラウドの可観測性の管理Block Storage (cinder) のログファイル を参照してください。
  3. Block Storage ボリュームをバックアップし、バックアップが正常に実行されることを確認して、Block Storage バックアップサービスが正常にデプロイされたことを確認します。詳細は、バックアップのトラブルシューティング を参照してください。

4.2. バックアップのトラブルシューティング

Block Storage のバックアップサービスは、Block Storage (cinder) ボリュームのバックアップ要求を受信する際に、静的チェックを実行します。これらのチェックが失敗した場合は、すぐに通知が届きます。

  • 無効なボリューム参照 (missing) の有無を確認してください。
  • ボリュームが in-use か、インスタンスにアタッチされているか確認します。in-use の場合は、--force オプションを使用してバックアップを実行する必要があります。詳細は、in-use ボリュームのバックアップの作成 を参照してください。

    --force ボリュームバックアップオプションを使用すると、バックアップの実行前にボリュームが静止されないため、クラッシュ整合性のあるバックアップは作成されますが、アプリケーション整合性のあるバックアップは作成されません。したがって、データはそのままですが、バックアップの実行時にどのアプリケーションが実行されていたかは、バックアップでは認識されません。

これらのチェックに成功すると、Block Storage バックアップサービスはこのボリュームをバックアップする要求を受け入れ、CLI backup コマンドは即座に返され、ボリュームはバックグラウンドでバックアップされます。

そのため、バックアップが失敗しても CLI backup コマンドは返されます。バックアップエントリーの Statusavailable の場合、openstack volume backup list コマンドを使用して、ボリュームバックアップが成功したことを確認できます。

バックアップが失敗した場合は、Block Storage バックアップサービスのログファイルでエラーメッセージを調べて、原因を特定します。詳細は、Block Storage バックアップサービスのログファイルの検証 を参照してください。

4.3. Block Storage バックアップサービスのログファイルの検証

バックアップまたは復元に成功しない場合は、Block Storage バックアップサービスのログファイルで、原因の特定に役立つエラーメッセージを調べることができます。

手順

  • バックアップサービスが実行されているコントローラーノードで、Block Storage バックアップサービスのログファイルを見つけます。

    このログファイルは、/var/log/containers/cinder/cinder-backup.log パスにあります。

4.4. ボリュームバックアップのワークフロー

以下の図は、ユーザーが cinder API に Block Storage (cinder) ボリュームのバックアップを要求するときに発生する手順について説明しています。

図4.1 Block Storage ボリュームのバックアップの作成

OpenStack BlockStorage のバックアップ
  1. ユーザーは、REST API である cinder API にリクエストを発行し、Block Storage ボリュームをバックアップします。
  2. cinder API は、HAProxy から要求を受信し、要求、ユーザー認証情報、およびその他の情報を検証します。
  3. cinder API は、SQL データベースにバックアップレコードを作成します。
  4. AMQP を介して、cinder-backup への非同期 RPC 呼び出しを行い、ボリュームのバックアップを作成します。
  5. cinder API は、ID を持つ現在のバックアップレコードを API 呼び出し元に返します。
  6. RPC 作成メッセージは、バックアップサービスのいずれかに届きます。
  7. cinder-backup は、get_backup_デバイス への同期 RPC 呼び出しを実行します。
  8. cinder-volume は、正しいデバイスが呼び出し元に返されるようにします。通常は同じボリュームですが、ボリュームが使用中の場合は、設定によっては一時クローンボリュームまたは一時スナップショットが返されます。
  9. cinder-backup は、cinder-volume に別の同期 RPC を発行して、ソースデバイスを公開するようにします。
  10. cinder-volume サービスは、ソースデバイス (ボリュームまたはスナップショット) をエクスポートしてマッピングし、適切な接続情報を返します。
  11. cinder-backup サービスは、接続情報を使用してソースデバイスをアタッチします。
  12. cinder-backup サービスは、デバイスがすでにアタッチされている状態でバックアップバックエンドドライバーを呼び出します。これにより、バックアップリポジトリーへのデータ転送が開始されます。
  13. ソースデバイスは、バックアップホストから切り離されます。
  14. cinder-backup は、同期 RPC を cinder-volume に発行して、ソースデバイスの接続を解除します。
  15. cinder-volume サービスは、デバイスのマッピングを解除し、エクスポートを削除します。
  16. 一時ボリュームまたは一時スナップショットが作成された場合、cinder-backupcinder-volume を呼び出してそのボリュームを削除します。
  17. cinder-volume により、一時ボリュームが削除されます。
  18. バックアップが完了すると、データベースのバックアップレコードが更新されます。

4.5. ボリュームの復元のワークフロー

以下の図は、ユーザーが cinder API に Block Storage サービス (cinder) バックアップの復元を要求したときに発生する手順について説明しています。

図4.2 Block Storage のバックアップの復元

OpenStack BlockStorage の復元
  1. ユーザーは REST API である cinder API にリクエストを発行し、Block Storage のバックアップを復元します。
  2. cinder API は、HAProxy から要求を受信し、要求、ユーザー認証情報、およびその他の情報を検証します。
  3. 要求に宛先として既存のボリュームが含まれていない場合、cinder API は非同期 RPC 呼び出しを実行して新しいボリュームを作成し、利用可能となるまでボリュームのステータスをポーリングします。
  4. cinder-scheduler がボリュームサービスを選択し、RPC 呼び出しを実行してボリュームを作成します。
  5. 選択した cinder-volume サービスにより、ボリュームが作成されます。
  6. cinder API がボリュームが使用可能であることを検出すると、データベースにバックアップレコードが作成されます。
  7. cinder API は、AMQP 経由でバックアップサービスへの非同期 RPC 呼び出しを行い、バックアップを復元します。
  8. cinder API は、現在のボリューム ID、バックアップ ID、およびボリューム名を API 呼び出し元に返します。
  9. RPC 作成メッセージは、バックアップサービスのいずれかに届きます。
  10. cinder-backup サービスは、cinder-volume への同期 RPC 呼び出しを実行して、ボリュームを公開します。
  11. cinder-volume サービスは、適切な接続情報を返すボリュームをエクスポートしてマッピングします。
  12. cinder-backup サービスは、接続情報を使用してボリュームをアタッチします。
  13. cinder-backup サービスは、ボリュームがすでにアタッチされているバックエンドドライバーを呼び出し、これにより、ボリュームへのデータの復元が開始されます。
  14. ボリュームがバックアップホストから切り離されます。
  15. cinder-backup サービスは、cinder-volume に対して同期 RPC を発行して、ボリュームを切断します。
  16. cinder-volume サービスはマッピングを解除し、ボリュームのエクスポートを削除します。
  17. ボリュームが復元されると、データベース内のバックアップレコードが更新されます。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.