ストレージ管理

Red Hat OpenShift は、オンプレミスおよびクラウドプロバイダーの両方で、複数の種類のストレージをサポートしています。OpenShift 仮想化は、ワークロードが実行されている環境でサポートされているコンテナストレージインターフェイス（CSI）プロビジョナーを使用できます。

物理ストレージシステムの例としては、Dell/EMC、富士通、日立、NetApp、Pure Storage などがあります。

ソフトウェア定義ストレージの例としては、IBM Fusion Data Foundation、OpenShift Data Foundation (ODF)、Portworx などがあります。

このリストは完全なものではありません。サポート対象のストレージソリューションのすべての情報については、 Red Hat EcoSystem Catalog を参照してください。

このラボでは、プロバイダーにストレージを要求し、VMディスクを保存するために使用されるPVC（Persistent Volume Claim）について説明します。多くのストレージプロバイダーは、デバイスのスナップショットやクローンもサポートしています。CSIドライバーとストレージデバイスがサポートする機能については、必ずベンダーに確認してください。

特に、OpenShift Virtualization固有のストレージプロトコル（NFS、iSCSI、FCなど）に関する制限はありません。唯一の要件は、クラスタ内のVMのライブマイグレーションをサポートするために必要な RWXアクセスモード が利用可能であることです。それ以外では、組織のVMとアプリケーションのニーズに最も適したストレージを選択することが適切です。

Red Hat OpenShift でストレージをプロビジョニングする際の CSI ワークフローのデモについては、以下の図を参照してください。

00 Disk Concepts

VM の PVC を確認する

このラボでは、先ほど作成した仮想マシン fedora01 のバックエンドストレージを詳しく見ていきます。

  1. 左側のメニューで Storage → Persistent Volume Claims をクリックして開始します。 vmexamples-{user} ネームスペースにいることを確認してください。前のセクションで fedora01 仮想マシンを作成したときに作成された fedora01 PVCが表示されるはずです。

    01 PVC List

  2. fedora01 PVCをクリックすると、VMをバックアップするストレージボリュームに関する追加の詳細情報が表示されます。

  3. PVCに関する以下の情報に注目してください:

    1. PVCは現在、正常にバインドされています

    2. PVCは30GiBの容量とサイズを要求しています

    3. PVCのアクセスモードはReadWriteMany (RWX) です

    4. PVCのボリュームモードはBlockです

    5. ボリュームは ocs-external-storagecluster-ceph-rbd ストレージクラスを使用しています。

      02 Fedora01 PVC Details

スナップショットの管理

OpenShift Virtualizationは、仮想マシンのディスクスナップショットを作成するために、CSIストレージプロバイダーのスナップショット機能に依存しています。スナップショットは、VMが実行中の場合は「オンライン」で、VMの電源がオフの場合は「オフライン」で取得できます。VMにKVM統合パッケージ（qemu-tools）がインストールされている場合、ゲストオペレーティングシステムを自動的に静止させるオプションも利用できます（静止により、ディスクのスナップショットがゲストファイルシステムの整合性のある状態を確実に反映します。例えば、バッファがフラッシュされ、ジャーナルが整合性のある状態になります）。

ディスクのスナップショットは、CSIによって抽象化されたストレージ実装に依存するため、パフォーマンスへの影響と使用容量はストレージプロバイダによって異なります。ストレージベンダーと協力して、システムがPVCスナップショットをどのように管理するか、また、期待されるパフォーマンスにどのような影響があるか（または影響がないか）を判断してください。

スナップショットは、通常、元の物理ボリュームと同じストレージシステム上にローカルに保存されるため、それ自体ではバックアップや災害復旧機能を提供しません。真の災害から生き延びるためには、データを別の方法で保護する必要があります。例えば、1つ以上のコピーを別の場所に保存したり、ストレージシステム自体の故障を回避するために、リモートロケーションのストレージシステムにミラーリングしたりします。

VMスナップショット機能により、クラスタ管理者およびアプリケーション開発者は、以下の操作を行うことができます:

  • 新しいスナップショットの作成

  • 特定のVMにアタッチされたすべてのスナップショットのリスト表示

  • VMをスナップショットに復元

  • 既存のVMスナップショットを削除

スナップショットの作成と使用

  1. Virtualization パースペクティブドロップダウンに戻り、左側のメニューで VirtualMachines をクリックします。 中央列のプロジェクト vmexamples-{user} を展開し、fedora01 仮想マシンをハイライトします。

    03 VM Overview

  2. 現在、このVMのスナップショットは概要ページに表示されていないことに注意してください。

    04 Snapshots Overview

  3. ページ上部の Snapshots タブに移動します。

    05 Snapshot Menu

  4. Take snapshot をクリックすると、ダイアログが開きます。

    06 VM Snapshot Dialog
    cloudinitdisk がスナップショットに含まれないという警告が表示されます。これは初期ブートに使用される一時的なディスクであるため、想定される動作です。

  5. スナップショットには自動的に名前が生成されます。 Save をクリックし、ステータスが Operation complete と表示されるまで待ちます。

    07 VM Snapshot Taken

  6. 3点のドットメニューをクリックします。VMが現在実行中であるため、Restore オプションがグレーアウトされていることを確認します。

    08 VM Restore Disabled

  7. 次に、Console タブに切り替えます。ログインして、VMが起動できないように変更を加えます。

    09 Console Login
    User name と Password の両方の隣にコピーアイコンがあり、Paste to console (コンソールに貼り付け)ボタンも利用可能です。

  8. ログイン後、次のコマンドを実行します。

    sudo rm -rf /boot/grub2; sudo shutdown -r now

  9. 実行すると、仮想マシンは自動的に再起動しますが、正常に起動することはできなくなります。

    10 Bootloader Broken
    前のステップでは、ゲスト内でオペレーティングシステムをシャットダウンしました。しかし、VMをホストしているPodがまだ実行中であるため、OpenShift仮想化はデフォルトでポリシーに基づいて自動的に再起動します。この動作は、グローバルまたはVMごとに変更できます。

  10. 右上の Actions ドロップダウンメニューまたはショートカットボタンを使用して、VMを Stop します。 このプロセスは、マシンが不安定な状態にあるため、正常なシャットダウンを試みるため、時間がかかる場合があります。Actions ドロップダウンメニューを再度クリックすると、Force stop オプションが表示されます。 ラボを継続するには、このオプションを使用してください。

  11. Overview タブをクリックして、VM が停止したことを確認できます。 また、先ほど取得したスナップショットが Snapshot タイルに表示されていることも確認できます。

    11 VM Stopped Snapshot

  12. Snapshot タイルで、当社のスナップショットの横にある3つのドットのメニューをクリックします。VMが停止している状態で、Restore がグレー表示ではなくなります。クリックします。

    12 VM Restore

  13. 表示されるダイアログで Restore をクリックします。

    13 VM Restore Dialog

  14. VM が復元されるまで待ちます。このプロセスはかなり速く完了します。 上部にある Snapshots タブをクリックすると、直近の復元操作の詳細を確認できます。

    14 VM Restored

  15. Overview タブに戻り、VM を起動します。

    15 VM Start

  16. Console タブをクリックして、VM が再起動し、OS に正常にブートアップしたことを確認します。

    16 VM Running

仮想マシンのクローン

クローニングにより、ストレージとして独自のディスクイメージを使用する新しいVMが作成されますが、クローンの構成および保存データのほとんどはソースVMと同一です。

  1. Overview 画面に戻り、Actions ドロップダウンメニューをクリックしてVMをクローニングするオプションを表示します。

    17 Overview Actions Clone

  2. Actions メニューから Clone をクリックすると、ダイアログが開きます。 複製したVMに fedora02 という名前を付け、Start VirtualMachine on clone のチェックボックスがチェックされていないことを確認してから、Clone をクリックします。

    18 VM Clone Dialog

  3. 新しいVMが作成され、ディスクが複製され、ポータルが自動的に新しいVMにリダイレクトされます。 Created の時間がごく最近であることがわかります。

    19 VM Cloned
    クローンされたVMはソースVMと同じIDを持つため、VMとやり取りするアプリケーションや他のクライアントとの間で競合が発生する可能性があります。外部ネットワークに接続されているVMや同じプロジェクト内のVMをクローンする場合は、注意が必要です。

  4. 画面上部の YAML メニューをクリックすると、VMの名前が「fedora02」となっていることがわかりますが、ソースVM fedora01 から残っているラベルがいくつかあり、これらは手動で更新する必要があります。

    20 Cloned VM YAML

  5. YAML内の app と kubevirt.io/domain の値を fedora02 に設定し、下部の Save ボタンをクリックすると、fedora02 が新しいバージョンに更新された旨のメッセージが表示されます。この作業を今行うことで、後のモジュールでこのVMを使用する際に問題を回避することができます。

    21 Cloned VM YAML Saved

  6. 仮想マシンの YAML の変更が完了したら、fedora01 と fedora02 の両方を実行するように起動します。

    22 Fedora02 Running

まとめ

このセクションでは、仮想マシンを管理する際に利用可能なストレージオプションについて説明しました。また、仮想マシンのスナップショットを取得して基本的な復元を行うことや、他のプロジェクトで使用したり、今後の開発を効率化するために仮想マシンのクローンを作成することなど、仮想マシンに用意されたストレージに依存するいくつかのVM管理機能も実行しました。