第4章 ボリュームの管理

ボリュームとは、OpenStack インスタンスに永続ストレージを提供するブロックストレージデバイスです。

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

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

4.1.1. ボリュームの作成

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. ボリュームの作成 をクリックして、以下のフィールドを編集します。

    フィールド説明

    ボリューム名

    ボリュームの名前

    説明

    ボリュームの簡単な説明 (オプション)

    種別

    オプションのボリューム種別 (「ボリューム種別へのボリューム設定の関連付け」を参照)

    複数の Block Storage バックエンドがある場合には、このフィールドを使用して特定のバックエンドを選択します。詳しくは、「ボリュームを作成するバックエンドの指定」 を参照してください。

    容量 (GB)

    ボリュームの容量 (ギガバイト単位)

    アベイラビリティーゾーン

    アベイラビリティーゾーン (論理サーバーグループ) は、ホストアグリゲートと併せて、OpenStack 内のリソースを分離する一般的な方法です。アベイラビリティーゾーンは、インストール中に定義されます。アベイラビリティーゾーンとホストについてのさらに詳しい説明は、「ホストアグリゲートの管理」を参照してください。

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

    ソース説明

    ソースの指定なし (空のボリューム)

    ボリュームは空となり、ファイルシステムやパーティションテーブルは含まれません。

    スナップショット

    既存のスナップショットをボリュームソースとして使用します。このオプションを選択すると、「スナップショットをソースとして使用する」の一覧が新たに表示され、スナップショットを選択できるようになります。ボリュームのスナップショットについての詳しい情報は、「ボリュームスナップショットの作成、クローン、削除」を参照してください。

    イメージ

    既存のイメージをボリュームソースとして使用します。このオプションを選択すると、「イメージをソースとして使用する」の一覧が新たに表示され、イメージを選択できるようになります。

    ボリューム

    既存のボリュームをボリュームソースとして使用します。このオプションを選択すると、「ボリュームをソースとして使用する」の一覧が新たに表示され、ボリュームを選択できるようになります。

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

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

Block Storage サービスが複数のバックエンドを使用するように設定することができます。たとえば、「OpenStack で NFS バックエンドを使用するための設定」では、デフォルトのバックエンドとともに、NFS 共有を使用するように Block Storage サービスを設定する方法について順を追って説明しています。

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

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

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

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

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

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

4.1.4. ボリュームの削除

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

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

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

インスタンスは、ボリュームを永続ストレージに使用することができます。1 つのボリュームは、一度に 1 つのインスタンスにしか接続できません。インスタンスに関する詳しい情報は、「インスタンスの管理」を参照してください。

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

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

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

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

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

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

# cinder readonly-mode-update VOLUME true

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

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

# cinder readonly-mode-update VOLUME true

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

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

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

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

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

    # 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 コマンドはボリュームの所有権を消去し、譲渡用の idauth_key を作成します。この値は別のユーザーに渡すことができます。受け取ったユーザーは、その値を使用して譲渡を承認し、ボリュームの新しい所有者となります。

  4. 新規ユーザーがボリュームの所有権を宣言できる状態となりました。所有権を宣言するには、ユーザーはまず最初にコマンドラインからログインして以下のコマンドを実行する必要があります。

    # cinder transfer-accept TRANSFERID TRANSFERKEY

    TRANSFERIDTRANSFERKEY はそれぞれ、cinder transfer-create で返された idauth_key の値に置き換えます。以下に例を示します。

    # cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
注記

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

# cinder transfer-list

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

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

  1. Dashboard にボリュームの所有者としてログインして プロジェクト > ボリューム を選択します。
  2. 譲渡するボリュームの アクション のコラムで、 譲渡の作成 を選択します。
  3. ボリュームの譲渡の作成 ダイアログボックスで、譲渡名を入力して ボリュームの譲渡の作成 をクリックします。

    ボリュームの譲渡が作成され、ボリュームの譲渡 の画面で 譲渡 ID認証キー を取得して譲渡先のプロジェクトに送信することができます。

    注記

    認証キーは ボリュームの譲渡 の画面にしか表示されません。この認証キーをなくした場合には、譲渡をキャンセルし、別の譲渡を作成して新たな認証キーを生成する必要があります。

  4. ボリュームの譲渡 の画面を閉じて、ボリュームの一覧に戻ります。

    譲渡先のプロジェクトが譲渡を受理するまで、ボリュームのステータスは awaiting-transfer と表示されます。

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

  1. Dashboard にボリュームの譲渡先としてログインして プロジェクト > ボリューム を選択します。
  2. 譲渡の受理 をクリックします。
  3. ボリュームの譲渡の受理 のダイアログボックスで、ボリュームの所有者から受け取った 譲渡 ID認証キー を入力して、ボリュームの譲渡の受理 をクリックします。

    譲渡先のプロジェクトのボリューム一覧に、そのボリュームが表示されるようになります。

4.1.8. ボリュームスナップショットの作成、クローン、削除

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

警告

インスタンスに接続されているボリュームのスナップショットを作成すると、スナップショットが破損する場合があります。インスタンスからボリュームを切断する方法については、「インスタンスからのボリュームの切断」を参照してください。

注記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下の手順では、ボリュームの高度な管理方法について説明します。これらの手順には管理者の権限が必要です。

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

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

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

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

注記

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

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

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

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

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

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

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

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

    # 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 と全く同じになります。

  3. 以下のコマンドを実行して、ボリュームのバックアップ作成が完了したことを確認します。

    # 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_servicebackup_url の値で構成されます。

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

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

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

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

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

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

# cinder backup-create VOLUME --incremental

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

注記

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

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

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

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

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

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

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

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

  1. 使用するボリュームバックエンドの ID を確認します。

    # cinder backup-list

    Volume ID は、復元するボリュームの ID と一致する必要があります。

  2. ボリュームのバックアップを復元します。

    # cinder backup-restore BACKUP_ID

    BACKUP_ID は使用するボリュームのバックアップ ID に置き換えます。

  3. バックアップが必要なくなった場合には、削除します。

    # cinder backup-delete BACKUP_ID

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

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

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

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

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

  1. /etc/openstack-dashboard/local_settings を開きます。
  2. 以下の設定を検索します。

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': False,
    }

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

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': True,
    }
  3. httpd サービスを再実行して、Dashboard を再起動します。

    # systemctl restart httpd.service

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

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

  1. バックアップサービス (openstack-cinder-backup) をホストしているノードに、管理権限のあるユーザーとしてログインします。
  2. Block Storage サービスが NFS バックアップドライバー (cinder.backup.drivers.nfs) を使用するように設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_driver cinder.backup.drivers.nfs
  3. バックアップリポジトリーとして使用する NFS 共有の詳細を設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_share NFSHOST:PATH

    各オプションについての説明は以下の通りです。

    • NFSHOST は、NFS サーバーの IP アドレスまたはホスト名に置き換えます。
    • PATH は、NFSHOST 上の NFS 共有の絶対パスに置き換えます。
  4. NFS 共有のマウントオプション設定を指定するには、以下のコマンドを実行します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_mount_options NFSMOUNTOPTS

    NFSMOUNTOPTS には、NFS マウントオプションのコンマ区切りの一覧を指定します (例: rw,sync)。サポートされているマウントオプションについての詳しい情報は、nfs および mountman ページを参照してください。

  5. Block Storage バックアップサービスを再起動して、変更を適用します。

    # systemctl restart openstack-cinder-backup.service
4.2.1.7.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

4.2.2. ボリュームの移行

ボリュームの移行ができるのは管理者のみです。使用中のボリュームやスナップショットのあるボリュームは移行できません。

  1. 管理ユーザーとして、利用可能なボリュームをすべて一覧表示します。

    # cinder list
  2. 使用可能なバックエンド (ホスト) とそれぞれのアベイラビリティーゾーンを一覧表示します。

    # cinder-manage host list
  3. 移行を開始します。

    # cinder migrate VOLUME BACKEND

    各オプションについての説明は以下の通りです。

    • VOLUME は移行するボリュームの ID に置き換えます。
    • BACKEND はボリュームの移行先となるバックエンドに置き換えます。
  4. 以下のコマンドで、移行するボリュームの現在のステータスを確認します。

    # cinder show VOLUME

    例:

    # cinder show 45a85c3c-3715-484d-ab5d-745da0e0bd5a
    +---------------------------------------+------------------+
    |                Property               |      Value       |
    +---------------------------------------+------------------+
    |                  ...                  |       ...        |
    |         os-vol-host-attr:host         |      server1     |
    |     os-vol-mig-status-attr:migstat    |       None       |
    |                  ...                  |       ...        |
    +---------------------------------------+------------------+

移行中に、以下の属性を書き留めておきます。

os-vol-host-attr:host
ボリュームの現在のバックエンド。移行が完了したら、移行先のバックエンド (BACKEND) が表示されるはずです。
os-vol-mig-status-attr:migstat
移行のステータス。ステータスが None の場合には移行は進行中でなくなったことを意味します。

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

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

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

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

注記

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

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

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

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

注記

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

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

  1. Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. ボリューム種別 の表で、ボリューム種別の 追加スペックの表示 のアクションを選択します。
  3. このページの 追加スペック 表では、以下のような操作を行うことができます。

    • ボリューム種別への新規設定の追加。これには、作成 をクリックして、ボリューム種別に対して、関連付ける新規設定のキー/値ペアを指定します。
    • ボリューム種別に関連付けられている既存の設定の編集。これには、設定の 編集 アクションを選択します。
    • ボリューム種別に関連付けられている既存の設定の削除。これには、追加スペックのチェックボックスを選択して、このダイアログ画面と次の画面で 追加スペックの削除 をクリックします。

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

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

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

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

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

4.2.4. QoS スペックの使用

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

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

  • QoS スペックは、ディスクの読み取り/書き込み操作を制限するなどのパフォーマンス設定を適用するのに使用されます。利用可能かつサポートされているパフォーマンス設定はストレージドライバーによって異なります。

    バックエンドがサポートしている QoS スペックを確認するには、そのバックエンドデバイスのボリュームドライバーのマニュアルを参照してください。

  • ボリューム種別はボリュームに直接適用されるのに対して QoS スペックは直接適用されるのではなく、ボリューム種別に関連付けられます。また、ボリュームの作成時にボリューム種別を指定すると、そのボリューム種別に関連付けられた QoS スペックにマップされたパフォーマンス設定も適用されます。

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

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

  1. Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
  2. QoS スペック の表で QoS スペックの作成 をクリックします。
  3. QoS スペック の名前を入力します。
  4. 使用者 フィールドで、QoS ポリシーを適用する先を指定します。

    表4.1 使用者のタイプ

    種別説明

    バックエンド

    QoS ポリシーが Block Storage バックエンドに適用されます。

    フロンドエンド

    QoS ポリシーが Compute に適用されます。

    両方

    QoS ポリシーが Block Storage と Compute の両方に適用されます。

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

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

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

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

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

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

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

ボリュームの暗号化は、ボリュームのバックエンドのセキュリティーを侵害されたり、完全に盗難されたりした場合に、基本的なデータ保護を提供します。暗号化ボリュームの内容は、特定のキーを使用しなければ読み取ることはできません。インスタンスが暗号化ボリュームを使用するためには、Compute サービスと Block Storage サービスの両方で同じキーを使用するように設定する必要があります。本項では、単一のキーを使用してボリュームを暗号化するように OpenStack デプロイメントを設定する方法について説明します。

重要

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

4.2.5.1. 静的キーの設定

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

  1. コマンドラインから、openstack-cinder-volume をホストしているノードに、root としてログインします。
  2. 静的キーを設定します。

    # openstack-config --set /etc/cinder/cinder.conf keymgr fixed_key HEX_KEY

    HEX_KEY は、16 桁の英数字の 16 進数のキー (例: 0000000000000000000000000000000000000000000000000000000000000000) に置き換えます。

  3. Block Storage ボリュームサービスを再起動します。

    # openstack-service restart cinder-volume
  4. 次に、openstack-nova-compute をホストするノードにログインして、同じ静的キーを設定します。

    # openstack-config --set /etc/nova/nova.conf keymgr fixed_key HEX_KEY
    注記

    複数のコンピュートノード (openstack-nova-compute をホストする複数のノード) を使用している場合には、同じ静的キーを各ノードの /etc/nova/nova.conf に設定する必要があります。

  5. Compute サービスを再起動します。

    # openstack-service restart nova-compute
    注記

    同様に、複数のコンピュートノードに静的キーを設定した場合には、各ノードで openstack-nova-compute サービスを再起動する必要があります。

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

4.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 の暗号が設定されます。本リリースでは、ボリュームの暗号化でサポートされている設定はクラス/暗号のみです。

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

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

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

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

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

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

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

  1. FilterScheduler を有効化します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_driver cinder.scheduler.filter_scheduler.FilterScheduler
  2. アクティブにする必要のあるフィルターを設定します。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_filters AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter
  3. スケジューラーが適切なバックエンドを選択する方法を設定します。

    • スケジューラーが、空き容量の最も大きなバックエンドを常に選択するようにするには、以下のコマンドを実行します。

      # 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
  4. Block Storage スケジューラーを再起動して、設定を適用します。

    # openstack-service restart openstack-cinder-scheduler