第14回 Commvault による Oracle Cloud Infrastructure のバックアップ
Commvault は VMware や Hyper-V をはじめとした多くの仮想化環境のバックアップ / リストアに対応していますが、Commvault V11 SP14 より、 Oracle Cloud Infrastructure (OCI) 上の仮想マシン (Compute) のバックアップ / リストアにも対応しました。第14回となる今回は、実際に OCI 上の仮想マシンのバックアップ / リストアを実行した際の OCI 側の画面を使用して、Commvault がどのように OCI と連携するかをご紹介させていただきます。
目次:
(1) OCI 上の仮想マシンのバックアップ / リストアの動作について
(2) OCI 上の仮想マシンのバックアップ / リストアに必要なもの
(3) バックアップ / リストア中の OCI 側の動作について
(3)-1: バックアップ中の OCI 側の動き
(3)-2: リストア中の OCI 側の動き
まとめ
(1) OCI 上の仮想マシンのバックアップ / リストアの動作について
OCI 上の仮想マシンのバックアップの動作ですが、
- バックアップ対象仮想マシンの Boot Volume Backup および Block Volume Backup を作成
- 作成した Boot Volume Backup および Block Volume Backup を Commvault のVirtual Server Agent (VSA) がインストールされた仮想マシンにアタッチしてバックアップ
- バックアップ終了後、Boot Volume Backup および Block Volume Backup をデタッチして削除
という処理を行います。
VMware 仮想マシンのバックアップ方式をご存知の方であれば、「HotAdd モードに近いバックアップ処理です」とお伝えするとイメージが掴みやすいかもしれません。
VMware 仮想マシンのバックアップでは HotAdd モード以外に、SAN モードや NBD モードといったバックアップ方式を提供していますが、OCI の場合はBoot Volume Backup を OCI の外部から参照することができないため、OCI 上の仮想マシンに VSA をインストールした方式のみサポートしています。
バックアップ対象の仮想マシンを選択する際も、他の仮想化環境と同様に OCI 上のインスタンス情報が Commvault の画面からも参照できるので、バックアップ管理者は OCI の画面を使用せずにバックアップの設定、実行が可能です。なお、OCI 上の仮想マシンのバックアップ / リストアは Commvault の Command Center からのみ実行できます。
Commvault (Command Center) 上の VM グループ (サブクライアント) 構成画面
(2) OCI 上の仮想マシンのバックアップ / リストアに必要なもの
OCI 上の仮想マシンのバックアップ / リストアでは、Commvault から OCI に対して REST API を発行しますので、Commvault 側に以下の情報を登録する必要があります。
- 公開鍵 / 秘密鍵の作成
事前に公開鍵および秘密鍵を作成しておきます。
公開鍵は Oracle Cloud Infrastructure Console (OCI Console) の API Key からアップロードしておき、秘密鍵は VSA がインストールされたホストに適用しておきます。
- OCID 情報の取得
以下の OCID 情報を OCI Console から取得しておきます。
- Tenancy OCID
- User OCID
- Compartment OCID
(3) バックアップ / リストア中の OCI 側の動作について
Commvault V11 SP14 を使用して、実際に OCI 上の仮想マシンをバックアップ / リストアしてみました。Commvault から OCI に対してどのような処理が行われているか、OCI 側の画面ベースでご紹介します。
今回は OCI 上で以下の 2 つの仮想マシンを用意しました。
- vm01 : VSA がインストールされた仮想マシン (バックアップ ホスト)
- vm02 : バックアップ / リストア対象仮想マシン
実際の構成では CommServe や MediaAgent 等のホストも使用していますが、省略します。
(3)-1: バックアップ中の OCI 側の動き
バックアップ ジョブが実行されている間に OCI 側でどのような処理が行われているか確認してみます。
OCI Console のメニューから [Compute] > [Boot Volume Backup] を選択して Boot Volume Backup の情報を確認します。バックアップ ジョブ開始時点の Boot Volume Backup には何もありません。
バックアップ ジョブが開始すると、バックアップ対象仮想マシンの Boot Volume Backupを作成します。Original Boot Volume の値を確認すると、vm02 の Boot Volume のバックアップであることが確認できます。
_GX_BACKUP_3328_4000_154935724 という名前の Boot Volume Backup が作成されました。
今回の検証では Boot Volume しかない仮想マシンのバックアップでしたが、Boot Volume 以外に Block Volume がアタッチされた仮想マシンのバックアップを行った場合は、Boot Volume Backup の作成に続いて Block Volume Backup の作成を行います。
VSA ホストの状態を確認します。OCI Console のメニューから [Compute] > [Instances] > [vm01 (VSA がインストールされた仮想マシン) ]を選択します。
Attached Block Volume の状態を確認してみます。バックアップ ジョブが開始後、Boot Volume Backup が作成された時点では Attached Block Volumes の数は 0 です。
vm01 に Block Volume がアタッチされます。ボリュームの名前を確認すると_GX_BACKUP_3328_4000_154935724となっているので、Boot Volume Backup であることが確認できます。Block Volume がある仮想マシンのバックアップでは、Boot Volume Backup のアタッチに続いて Block Volume Backup がアタッチされます。
アタッチされると、VSA がボリュームのデータをバックアップします。
バックアップが終了すると、デタッチされます。
デタッチされ、Attached Block Volumes の数が 0 になります。
Boot Volume Backup が削除されます。
(3)-2: リストア中の OCI 側の動き
リストア ジョブが実行されている間に OCI 側でどのような処理が行われているか確認してみます。
V11 SP14 では、リストア ジョブを開始する前にリストア対象の仮想マシンを削除しておく必要があります。V11 SP15 以降では上書きオプションが追加され、同名のインスタンスがある場合に削除することが可能になっています。
リストア ジョブの開始後に OCI Console のメニューから [Compute] > [Instances] を選択します。リストア対象のインスタンスが作成されますが、このインスタンスはリストア先のBoot Volume を作成するための「一時」インスタンスです。
OCI Console のメニューから [Compute] > [Boot Volume] を選択します。インスタンスの作成に連動して Boot Volume が作成されます。
Boot Volume が作成されました。
リストア先の Boot Volume が作成されたので、Boot Volume の削除はせずにインスタンスのみを削除します。
一時インスタンスが削除されました。
OCI Console のメニューから [Compute] > [Instances] > [vm01 (VSA がインストールされた仮想マシン) ]を選択します。Block Volume がアタッチされていて、ボリュームの名前を確認するとvm02 の Boot Volume であることが確認できます。Block Volume がある仮想マシンのバックアップでは、Boot Volumeのアタッチに続いて Block Volumeがアタッチされます。アタッチ後、バックアップされているデータを各ボリュームに書き込みます。
OCI Console のメニューから [Compute] > [Boot Volumes] を選択します。こちらの画面からも、vm02 用の Boot Volume が vm01 にアタッチされていることが確認できます。
データの書き込みが終わると、vm01 から Block Volume をデタッチします。
データが書き込まれた Boot Volume を使用してリストア先のインスタンスを起動します。
OCI Console の [Compute] > [Boot Volume] からも vm02 にアタッチされていることが確認できます。
vm02 が起動しました。Block Volume がある場合は続いて Block Volume がアタッチされます。
アタッチしたボリュームを OS 側に認識させるために、インスタンスが再起動されます。Block Volume がアタッチされていないインスタンスでもこの処理は実行されます。
再起動が完了し、リストアジョブも完了します。
まとめ
今回は OCI 側の画面を中心にバックアップ / リストアの仕組みをご紹介させていただきました。Commvault は OCI 上の仮想マシンのバックアップ / リストアに対応していますが、Commvault がすべてを担っているのではなく、OCI 側が提供する各種機能と連携してバックアップ / リストアを実現している、ということがおわかりいただけたかと思います。また、VMware 仮想マシンのバックアップを OCI 上の仮想マシンとしてリストアすることもサポートしていますので、Commvault はバックアップ / リストアだけではなく、DR や移行ツールとしてお使いいただくことも可能です。
※このブログでご紹介しているCommvaultの画面ショットは、V11 SP14の環境で確認したものです。
【参考資料】
- 用語集
- Oracle Cloud Infrastructure: System Requirements
- Adding an Oracle Cloud Infrastructure Hypervisor
- Adding a VM Group
- Restoring Full Instances for Oracle Cloud Infrastructure
Posted on 2019.05