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


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

重要

Block Storage サービス (cinder) およびファイバーチャネル (FC) バックエンドを使用するすべてのデプロイメントにおいて、すべてのコントローラーノードおよびコンピュートノードにホストバスアダプター (HBA) をインストールする必要があります。

2.3.1. ボリュームの作成

重要

デフォルトでは、1 つのプロジェクトで作成可能な最大のボリューム数は 10 です。

手順

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

    フィールド説明

    ボリューム名

    ボリュームの名前

    説明

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

    オプションのボリューム種別 (「グループボリューム設定とボリューム種別」を参照)

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

    容量 (GB)

    ボリュームの容量 (ギガバイト単位)暗号化されていないイメージから暗号化されたボリュームを作成する場合は、暗号化データがボリュームデータを切り捨てないように、ボリュームのサイズがイメージサイズより 1 GB 以上大きいようにする必要があります。

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

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

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

    ソース説明

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

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

    スナップショット

    既存のスナップショットをボリュームソースとして使用します。このオプションを選択すると、スナップショットをソースとして使用する のリストが新たに表示され、スナップショットを選択できるようになります。暗号化されたボリュームのスナップショットから新規ボリュームを作成する場合は、新規ボリュームが古いボリュームより 1 GB 以上大きいようにする必要があります。ボリュームのスナップショットについての詳しい情報は、「ボリュームスナップショットの作成、使用、削除」を参照してください。

    Image

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

    ボリューム

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

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

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

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

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

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

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

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

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

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

2.3.4. ボリュームのサイズ変更 (拡張)

注記

使用中のボリュームのサイズを変更する機能はサポートされていますが、ドライバーに依存します。RBD がサポートされています。使用中のマルチ接続ボリュームを拡張することはできません。この機能のサポートについての詳細は、Red Hat のサポートにお問い合わせください。

  1. ボリュームをリスト表示し、拡張するボリュームの ID を取得します。

    $ cinder list
  2. ボリュームのサイズを変更するには、次のコマンドを実行して正しい API マイクロバージョンを指定し、ボリューム ID と新しいサイズ (古いサイズより大きい値) をパラメーターとして渡します。

    $ OS_VOLUME_API_VERSION=<API microversion>
    $ cinder extend <volume ID> <size>

    <API_microversion>、<volume_ID>、および <size> を適切な値に置き換えます。次に例を示します。

    $ OS_VOLUME_API_VERSION=3.42
    $ cinder extend 573e024d-5235-49ce-8332-be1576d323f8 10

2.3.5. ボリュームの削除

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

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

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

インスタンスでは永続ストレージにボリュームを使用することができます。ボリュームは、1 度に 1 つのインスタンスにしか接続できません。詳細については、インスタンスの作成と管理ガイドの インスタンスへのボリュームのアタッチ を参照してください。

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

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

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

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

2.3.7. 複数インスタンスへのボリュームの接続

ボリュームのマルチ接続により、複数のインスタンスが Block Storage ボリュームに同時に読み取り/書き込みアクセスを行うことができます。Ceph RBD ドライバーがサポートされます。

警告

複数インスタンスからの書き込み操作を管理するには、マルチ接続またはクラスター対応のファイルシステムを使用する必要があります。それ以外の設定では、データの破損が生じます。

マルチ接続ボリュームの制限

  • Block Storage (cinder) のバックエンドは、マルチ接続ボリュームをサポートしている必要があります。サポートされるバックエンドについての情報は、Red Hat のサポートにお問い合わせください。
  • Block Storage (cinder) のドライバーは、マルチ接続ボリュームをサポートしている必要があります。ベンダープラグインでマルチ接続がサポートされることを確認するには、Red Hat のサポートにお問い合わせください。ベンダープラグインの認定についての詳しい情報は、以下のアーティクルおよび Web サイトを参照してください。

  • 読み取り専用のマルチ接続ボリュームはサポートされていません。
  • マルチ接続ボリュームのライブマイグレーションは利用できません。
  • マルチ接続ボリュームの暗号化はサポートされていません。
  • マルチ接続ボリュームは、ベアメタルプロビジョニングサービス (ironic) virt ドライバーではサポートされていません。マルチ接続ボリュームは、libvirt virt ドライバーによってのみサポートされます。
  • アタッチされたボリュームをマルチ接続タイプから非マルチ接続タイプに再入力したり、非マルチ接続タイプをマルチ接続タイプに再入力したりすることはできません。
  • アタッチされたボリュームの移行中に、複数の読み取り/書き込みアタッチメントを持つマルチ接続ボリュームをソースボリュームまたは宛先ボリュームとして使用することはできません。
  • 見送られていたオフロードされたインスタンスにマルチ接続ボリュームをアタッチすることはできません。

2.3.7.1. マルチ接続ボリューム種別の作成

複数のインスタンスにボリュームを接続するには、ボリュームの追加スペックで multiattach フラグを <is> True に設定します。マルチ接続のボリューム種別を作成すると、ボリュームはフラグを継承し、マルチ接続のボリュームになります。

注記

デフォルトでは、新規ボリューム種別の作成は管理者だけができる操作です。

手順

  1. 以下のコマンドを実行し、マルチ接続のボリューム種別を作成します。

    $ cinder type-create multiattach
    $ cinder type-key multiattach set multiattach="<is> True"
    注記

    この手順では、マルチ接続をサポートする任意のバックエンドにボリュームを作成します。したがって、マルチ接続をサポートするバックエンドが 2 つある場合、スケジューラーは、ボリューム作成時に利用可能な領域に基づいて使用するバックエンドを決定します。

  2. バックエンドを指定するには、以下のコマンドを実行します。

    $ cinder type-key multiattach set volume_backend_name=<backend_name>

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

ボリュームをマルチ接続可能な種別に変更することや、マルチ接続可能なボリュームを複数インスタンスに接続できない種別に変更することが可能です。ただし、ボリューム種別を変更することができるのは、ボリュームが使用中ではなくそのステータスが available の場合に限られます。

マルチ接続のボリュームを接続する場合、一部のハイパーバイザーでは、キャッシュを無効にする場合など、特別な考慮が必要になります。現在、接続済みのボリュームを接続したまま安全に更新する方法はありません。複数のインスタンスに接続されているボリュームの種別変更を試みると、変更に失敗します。

2.3.7.3. マルチ接続ボリュームの作成

マルチ接続のボリューム種別を作成したら、マルチ接続のボリュームを作成します。

手順

  1. 以下のコマンドを実行し、マルチ接続のボリュームを作成します。

    $ cinder create <volume_size> --name <volume_name> --volume-type multiattach
  2. 以下のコマンドを実行して、ボリュームがマルチ接続に対応していることを確認します。ボリュームがマルチ接続に対応している場合、multiattach フィールドは True と表示されます。

    $ cinder show <vol_id> | grep multiattach
    
    | multiattach | True |

これで、複数のインスタンスにボリュームを接続できるようになりました。インスタンスにボリュームをアタッチする方法についての詳細は、インスタンスへのボリュームの接続と切断 を参照してください。

2.3.7.4. サポート対象のバックエンド

Block Storage のバックエンドは、マルチ接続をサポートしている必要があります。サポートされるバックエンドについての情報は、Red Hat のサポートにお問い合わせください。

2.3.8. 読み取り専用ボリューム

データが誤って上書きまたは削除されないように、ボリュームを読み取り専用に指定することができます。これを行うには、次のコマンドを使用して、ボリュームを読み取り専用に設定します。

# cinder readonly-mode-update <VOLUME-ID> true

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

# cinder readonly-mode-update <VOLUME-ID> false

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

ボリュームの所有者を変更するには、ボリューム転送を実行する必要があります。ボリュームの転送はボリュームの所有者によって開始され、所有権の変更は、転送が新しい所有者によって受け入れられた後に完了します。

2.3.9.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

2.3.9.2. ダッシュボードを使用してボリュームを転送する

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

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

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

    譲渡認証情報のダウンロード ボタンをクリックして transfer nametransfer IDauthorization key が記載されている .txt ファイルをダウンロードします。

    注記

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

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

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

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

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

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

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

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

注記

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

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

ボリュームのバックアップについての詳しい情報は、Block Storage Backup Guide を参照してください。

ボリュームのスナップショットを作成するには、以下の手順を実施します。

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

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

重要

暗号化されたボリュームのスナップショットから新規ボリュームを作成する場合は、新規ボリュームが古いボリュームより 1 GB 以上大きいようにします。

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

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

注記

スナップショットから作成される Block Storage サービス (cinder) の RADOS ブロックデバイス (RBD) ボリュームの場合は、CinderRbdFlattenVolumeFromSnapshot heat パラメーターを使用してフラット化し、スナップショットの依存関係を削除することができます。CinderRbdFlattenVolumeFromSnapshottrue に設定すると、Block Storage サービスは RBD ボリュームをフラット化してスナップショットの依存関係を削除すると共に、それ以降のスナップショットもすべてフラット化します。デフォルト値は false で、cinder RBD ドライバーのデフォルト値も false です。

スナップショットをフラット化すると、親との潜在的なブロック共有が削除され、バックエンドでのスナップショットサイズが大きくなり、スナップショット作成の時間が長くなることに注意してください。

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

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

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

詳細については、Red HatCeph ストレージブロックデバイスガイドの次のリンクを参照してください。

2.3.11. スナップショットを使用したボリュームの最後の状態への復元

ボリュームの最新スナップショットの状態に復元することができます。つまり、インプレースでボリュームデータをその最新スナップショットの状態に戻すことができます。

警告
ボリュームの最新スナップショットの状態に復元する機能はサポート対象ですが、ドライバーに依存します。この機能を正しく実装するには、ドライバー側の支援が必要です。この機能に対するサポートの詳細は、ドライバーのベンダーにお問い合わせください。

制限

  • マルチ接続のボリュームの場合、スナップショットの状態に戻す機能の使用には制限が適用される可能性があります。この機能を使用する前に、このような制限が適用されるかどうかを確認してください。
  • スナップショットの作成後にサイズを変更 (拡張) したボリュームを元に戻すことはできません。
  • 接続済みまたは使用中のボリュームに対して、スナップショットの状態に戻す機能を使用することはできません。

前提条件

  • Block Storage (cinder) API マイクロバージョン 3.40 またはそれ以降
  • ボリュームのスナップショットを少なくとも 1 つ作成していること。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. source コマンドで overcloudrc ファイルを読み込みます。

    [stack@undercloud ~] $ source overcloudrc
  3. ボリュームを切断します。

    $ nova volume-detach <instance_id> <vol_id>

    <instance_id> および <vol_id> を、元に戻すインスタンスおよびボリュームの ID に置き換えてください。

  4. 元に戻すスナップショットの ID または名前を探します。元に戻すことができるのは最新のスナップショットだけです。

    $ cinder snapshot-list
  5. スナップショットの状態に戻します。

    $ cinder --os-volume-api-version=3.40 revert-to-snapshot  <snapshot_id or snapshot_name>

    <snapshot_id or snapshot_name> をスナップショットの ID または名前に置き換えてください。

  6. オプション: cinder snapshot-list コマンドを使用して、元に戻しているボリュームが reverting の状態にあることを確認することができます。

    $  cinder snapshot-list
  7. ボリュームを再接続します。

    $  nova volume-attach <instance_id> <vol_id>

    <instance_id> および <vol_id> を、元に戻したインスタンスおよびボリュームの ID に置き換えてください。

2.3.11.1. 正常に復元していることの確認

手順

  • 手順が正常に行われたことを確認するには、cinder list コマンドを使用して、元に戻したボリュームが available の状態にあることを検証します。

    $ cinder list
    注記
    Block Storage (cinder) をブート可能なルートボリュームとして使用した場合、ボリュームは available の状態にないため、そのボリュームでスナップショットの状態に戻す機能を使用することはできません。この機能を使用するには、インスタンスが終了した場合にブートボリュームを保持するために、delete_on_termination=false (デフォルト) の属性を設定してインスタンスをブートしている必要があります。スナップショットの状態に戻す場合は、ボリュームが利用可能になるように、まず初期インスタンスを削除する必要があります。その後、元に戻してボリュームから新規インスタンスを作成することができます。

2.3.12. Image サービスへのボリュームのアップロード

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

  1. Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
  2. 対象のボリュームの イメージにアップロード アクションを選択します。
  3. ボリュームの イメージ名 を指定して、リストから ディスク形式 を選択します。
  4. アップロード をクリックします。

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

2.3.13. バックエンド間でのボリュームの移動

ボリュームをあるストレージバックエンドから別のストレージバックエンドに移動する理由には、以下のような理由があります。

  • サポートされなくなったストレージシステムの使用を停止するため。
  • ボリュームのストレージクラスまたは階層を変更するため。
  • ボリュームのアベイラビリティーゾーンを変更するため。

Block Storage サービス (cinder) を使用すると、以下の方法でバックエンド間でボリュームを移動することができます。

  • 種別の変更: デフォルトのポリシーにより、ボリュームの所有者と管理者はボリューム種別を変更することができます。種別変更の操作は、バックエンド間でボリュームを移動する最も一般的な方法です。
  • 移行: デフォルトのポリシーでは、管理者のみがボリュームを移行することができます。ボリュームの移行は特定のユースケース用に制限されます。これは、移行に制約があるため、またデプロイメントの動作について明確に理解する必要があるためです。詳細は、ボリュームの移行 を参照してください。

制約

Red Hat は、同一または異なるアベイラビリティーゾーン (AZ) にあるバックエンド間のボリュームの移動をサポートしますが、以下の制約があります。

  • 移行するボリュームは、利用可能な状態または使用中の状態のいずれかでなければなりません。
  • 使用中のボリュームのサポートはドライバーに依存します。
  • ボリュームにはスナップショットを含めることができません。
  • ボリュームは、グループまたは整合性グループに所属させることはできません。

2.3.14. 利用可能なボリュームの移動

すべてのバックエンド間で利用可能なボリュームを移動できますが、パフォーマンスは使用するバックエンドにより異なります。多くのバックエンドは、アシスト付き移行をサポートします。バックエンドのアシスト付き移行のサポートについての詳細は、ベンダーにお問い合わせください。

アシスト付き移行は、ボリューム種別変更およびボリュームの移行の両方で機能します。アシスト付き移行により、バックエンドはソースバックエンドから移行先バックエンドへのデータの移動を最適化しますが、両方のバックエンドが同じベンダーから取得されている必要があります。

注記

Red Hat は、マルチプールバックエンドを使用する場合、または RBD などのシングルプールバックエンドに cinder の移行操作を使用する場合のみ、バックエンドアシスト付き移行をサポートしています。

2.3.14.1. 通常のボリューム移行

バックエンド間のアシスト付き移行ができない場合には、Block Storage サービスは通常のボリューム移行を実行します。

通常のボリューム移行では、Block Storage (cinder) サービスが移行元ボリュームからコントローラーノードに、およびコントローラーノードから移行先ボリュームにデータを移動する前に、両方のバックエンド上のボリュームを接続する必要があります。Block Storage サービスは、ソースおよび宛先のバックエンドのストレージの種類に関わらず、プロセスをシームレスに実行します。

重要

通常のボリューム移行を実行する前に、十分な帯域幅を確保してください。通常のボリューム移行にかかる時間は、ボリュームのサイズと直接比例するため、操作はアシスト付き移行よりも遅くなります。

2.3.15. 使用中のボリュームの移動

使用中のボリュームを移動する場合、最適化のオプションまたはアシスト付きのオプションはありません。使用中のボリュームを移行する場合には、Compute サービス (nova) がハイパーバイザーを使用して、移行元バックエンドのボリュームから移行先バックエンドのボリュームにデータを転送する必要があります。これには、ボリュームが使用されているインスタンスを実行するハイパーバイザーとの連携が必要です。

Block Storage サービス (cinder) と Compute サービスは、連携してこの操作を実施します。データがコンピュートノードを介してあるボリュームから別のボリュームにコピーされるため、Compute サービスがほとんどの作業を管理します。

重要

使用中のボリュームを移動する前に、十分な帯域幅を確保してください。この操作にかかる時間は、ボリュームのサイズと直接比例するため、操作はアシスト付き移行よりも遅くなります。

制約

  • 使用中のマルチ接続ボリュームは、複数の nova インスタンスに接続している間は移動できません。
  • ターゲットバックエンドのストレージプロトコルを iSCSI、ファイバーチャネル (FC)、または RBD に制限する、非ブロックデバイスはサポートされません。

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

ボリューム種別の変更は、あるバックエンドから別のバックエンドにボリュームを移動する標準的な方法です。操作を実行するには、管理者はそれぞれのバックエンドに適切なボリューム種別を定義する必要があります。デフォルトのポリシーにより、ボリュームの所有者と管理者はボリューム種別を変更することができます。

ボリューム種別を変更する際には、ボリューム種別とその設定を既存のボリュームに適用します。ボリューム種別の詳しい情報は、「グループボリューム設定とボリューム種別」を参照してください。

新規ボリューム種別の追加スペックを既存のボリュームに適用できる場合、ボリューム種別を変更することができます。ボリューム種別を変更して、事前定義の設定やストレージ属性を既存ボリュームに適用することができます。以下に例を示します。

  • 異なるバックエンドへボリュームを移行する場合
  • ボリュームのストレージクラスまたは階層を変更するため。
  • レプリケーションなどの機能を有効または無効にする場合

ボリューム種別を変更したからといって、そのボリュームをあるバックエンドから別のバックエンドに移動しなければならない訳ではありません。ただし、種別変更を完了するのにボリュームを移動しなければならない場合があります。

  • 新しいボリュームタイプには、異なる volume_backend_name 定義されています。
  • 現在のボリュームタイプの volume_backend_name は未定義であり、ボリュームは新しいボリュームタイプの volume_backend_name で指定されたものとは異なるバックエンドに格納されます。

ボリュームをあるバックエンドから別のバックエンドに移動するには、非常に多くの時間とリソースが必要になる場合があります。したがって、種別の変更でデータを移動する必要がある場合には、Block Storage サービスはデフォルトではデータを移動しません。種別変更の要求の一部として移行ポリシーを指定して移動を明示的に許可しない限り、操作は失敗します。詳細は、「コマンドラインを使用したボリューム種別の変更」を参照してください。

制約

  • すべてのボリューム種別を変更することはできません。バックエンド間のボリュームの移動に関する詳細は、「バックエンド間でのボリュームの移動」を参照してください。
  • 暗号化されないボリューム種別を暗号化ボリューム種別に変更することはできませんが、暗号化ボリューム種別を暗号化されないボリューム種別に変更することはできます。
  • 管理者権限のないユーザーは、自分が所有するボリュームの種別しか変更できません。

2.3.16.1. Dashboard UI を使用したボリューム種別の変更

Dashboard UI を使用してボリューム種別を変更します。

重要

暗号化されていないボリュームを同じサイズの暗号化されたボリュームに種別変更する操作はサポートされません。暗号化したボリュームには、暗号化データを格納するための追加領域が必要なためです。暗号化されていないボリュームの暗号化に関する詳細は、暗号化されていないボリュームの暗号化 を参照してください。

前提条件

手順

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

2.3.16.2. コマンドラインを使用したボリューム種別の変更

Dashboard UI の手順と同様に、コマンドラインからボリューム種別を変更することができます。

重要

暗号化されていないボリュームを同じサイズの暗号化されたボリュームに種別変更する操作はサポートされません。暗号化したボリュームには、暗号化データを格納するための追加領域が必要なためです。暗号化されていないボリュームの暗号化に関する詳細は、暗号化されていないボリュームの暗号化 を参照してください。

前提条件

手順

  1. 以下のコマンドを入力してボリューム種別を変更します。

    $ cinder retype <volume id> <new volume type name>
  2. 種別変更の操作で、あるバックエンドから別のバックエンドにボリュームを移動する必要がある場合は、Block Storage サービスには特定のフラグが必要です。

    $ cinder retype --migration-policy on-demand <volume id> <new volume type name>
    注記

    種別変更の操作が進むと、ボリュームのステータスが retyping に変わります。

  3. 次のコマンドを入力し、volume_type フィールドを確認して、再入力操作が成功したことを確認します。volume_type フィールドには、新しいボリュームタイプが表示されます。

    $ cinder show <volume id>
    注記

    種別変更の操作を開始すると、ボリューム名が重複します。そのボリューム名で cinder show コマンドを実行すると、シンダークライアントは次のようなエラーを返します。ERROR: Multiple volume matches found for '<volume name>'このエラーを回避するには、ボリューム名の代わりにボリューム ID を使用します。

2.3.17. オーバークラウドノードでの LVM2 フィルターの有効化

特定の BlockStorage Service (cinder) バックエンドで LVM2 (Logical Volume Management) ボリュームを使用する場合、Red Hat OpenStack Platform (RHOSP) ゲスト内で作成したボリュームが、cinder-volume または nova-compute をホストするオーバークラウドノードに表示される場合があります。この場合、ホスト上の LVM2 ツールは、OpenStack ゲストが作成する LVM2 ボリュームをスキャンします。これにより、コンピュートノードまたはコントローラーノードで次の問題が 1 つ以上発生する可能性があります。

  • LVM がゲストからのボリュームグループを表示するように見える
  • LVM が重複するボリュームグループ名を報告する
  • LVM がストレージにアクセスしているため、ボリュームの切り離しが失敗する
  • LVM の問題が原因でゲストがブートに失敗する
  • ゲストマシン上の LVM は、実際に存在するディスクが見つからないため、部分的な状態にある
  • LVM を持つデバイスで Block Storage サービス (cinder) のアクションが失敗する
  • Block Storage サービス (cinder) のスナップショットが正しく削除されない
  • ライブマイグレーション中のエラー: /etc/multipath.conf が存在しない

この誤ったスキャンを防ぎ、ゲスト LVM2 ボリュームをホストノードから分離するために、オーバークラウドのデプロイまたは更新時に LVMFilterEnabled heat パラメーターを使用してフィルターを有効にし、設定できます。このフィルターは、アクティブな LVM2 ボリュームをホストする物理デバイスのリストから計算されます。LVMFilterAllowlist および LVMFilterDenylist パラメーターを使用して、ブロックデバイスを明示的に許可および拒否することもできます。このフィルタリングは、グローバルに、特定のノードロールに、または特定のデバイスに適用できます。

注記

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能の詳細は、対象範囲の詳細 を参照してください。

前提条件

  • アンダークラウドの正常なインストール。詳しくは、Installing the undercloud を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. source コマンドでアンダークラウドの認証情報ファイルを読み込みます。

    $ source ~/stackrc
  3. 新しい環境ファイルを作成するか、既存の環境ファイルを変更します。この例では、新しいファイル lvm2-filtering.yaml を作成します。

    $ touch ~/lvm2-filtering.yaml
  4. 環境ファイルに以下のパラメーターを追加します。

    parameter_defaults:
      LVMFilterEnabled: true

    LVM2 フィルターの実装はさらにカスタマイズできます。たとえば、コンピュートノードでのみフィルタリングを有効にするには、次の設定を使用します。

    parameter_defaults:
      ComputeParameters:
        LVMFilterEnabled: true

    これらのパラメーターは、正規表現もサポートしています。コンピュートノードでのみフィルタリングを有効にし、/dev/sd で始まるすべてのデバイスを無視するには、次の設定を使用します。

    parameter_defaults:
      ComputeParameters:
        LVMFilterEnabled: true
        LVMFilterDenylist:
          - /dev/sd.*
  5. openstack overcloud deploy コマンドを実行し、LVM2 フィルタリング設定を含む環境ファイルと、オーバークラウドデプロイメントに関連するその他の環境ファイルを含めます。

    $ openstack overcloud deploy --templates \
    <environment-files> \
    -e lvm2-filtering.yaml
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.