« Go with Flow | メイン | Office365 と Trend Micro Cloud App Security でより安全なクラウドへ(前編) »

2018/05/30

Arcserve UDP|仮想マシンを急いで復活させるには?

こんにちは、バックアップ担当の宮内です。
ご挨拶が遅くなりましたが、 3月のセミナーではとても多くの方にご参加いただき、誠にありがとうございました!
引き続き、Arcserveとネットワールドをよろしくお願いたします。

お礼ついでに、今回もArcserveの機能を紹介したいと思います。
紹介する機能はArcserve UDPの「仮想スタンバイ」と「インスタントVM」!

どちらも仮想マシンを迅速に復旧するための機能なのですが、「どう違うのかわかりにくい」という話を耳にします。
実際に触ったことがないと、イメージしにくいですよね。

Arcserveのブログでもまとめられているのですが、それでもまだ悩んでいる人がいる!
ということで、私の言葉でちょっとまとめて比較してみました!

ちなみに、今回はvSphere環境を前提に話を進めますが、Arcserve UDPはHyper-V環境にも対応しています。
厳密に言えば仮想化基盤ごとに異なる部分がありますが、大まかな仕組みは同じなのでご安心ください。

■通常の仮想マシンバックアップ・リカバリ

それぞれの機能の紹介をする前に、まずは仮想マシンバックアップの基本をおさらいしましょう。
まずは仮想マシンバックアップのしくみから!

VMware社からはVMware vStorage APIs - Data Protection(通称VADP)というAPIが提供されています。
このAPIを使用することで、バックアップソフトウェアはvSphere環境の機能と連携して効率よく仮想マシンのバックアップを取得することができるのです。

□仮想マシンバックアップのしくみ(vSphere環境の場合・通称VADPバックアップ)

  1. バックアップサーバーからvSphere環境(図ではvCenter)にバックアップのリクエストが送信されます
  2. VMware Snapshotが作成され、仮想マシンファイルの静止点ができます
  3. 静止点となった仮想マシンファイルがバックアップサーバーに転送されます
  4. 仮想マシンのスナップショットが削除(統合)されます

ちなみに図中にRPSと書いてあるものはArcserve UDPのバックアップサーバー「復旧ポイントサーバー」のことです。
UDPは大きく分けて「コンソール」「復旧ポイントサーバー」「エージェント」の3コンテンツで構成されていて、コンソールでバックアップを管理し、復旧ポイントサーバーが実際のバックアップを実行し、エージェントがバックアップ対象となる、というイメージです。
UDPの構成についてはArcserveさんの紹介資料がわかりやすいと思うので、是非ご一読くださいませ。

このしくみを利用した仮想マシンの一般的なバックアップ・リカバリの流れは以下のような感じです。

□仮想マシンの一般的なバックアップ・リカバリ

  1. 仮想マシンのデータがデータストアからバックアップサーバーに転送され、バックアップイメージとしてバックアップサーバーに保存されます

    -----障害発生-----

  2. バックアップサーバーからデータが転送され、仮想マシンファイルが仮想環境のデータストアにリストアされます
  3. リストアした仮想マシンファイルから仮想マシンが再作成され、電源をいれることで利用できるようになります

通常のリストアで一般的に時間がかかるとされるのは、手順2の「データ転送」の部分です。
どうにかしてこのデータ転送時間を短縮させたくて、UDPでは異なるアプローチで2つの手段を用意しました。
それが、「仮想スタンバイ」と 「インスタントVM」ということです。

ではおまたせしました、それぞれの機能を紹介いたします!


■仮想スタンバイ

仮想スタンバイとは

あらかじめ仮想マシンをリストアしておき、有事の際にはリストアしておいた仮想マシンを起動するだけで迅速な復旧を可能にする機能

データ転送に時間がかかるなら、時間に余裕があるうちに送ってしまえばいいじゃない!という発想ですね。

□仮想スタンバイを利用したバックアップ・リカバリ

  1. 仮想マシンのデータがデータストアからバックアップサーバーに転送され、バックアップイメージとしてバックアップサーバーに保存されます
  2. バックアップサーバーからデータが転送され、リストアされます。リストアした仮想マシンファイルから仮想マシンがスタンバイVMとして再作成されます

    -----障害発生-----

  3. 待機していたスタンバイVMの電源を入れることで利用できるようになります

ちなみに、仮想スタンバイ中は本番マシンのモニタリングができるので、本番機に障害があったときに自動的にスタンバイVMが起動するようにも設定できます。
欠点としては、普段使わない仮想マシンが常に1台存在するので、仮想環境側のリソースを余分に使ってしまうことですね。
ただ、復旧後にあれこれする必要がないというのは、障害対応の大変さを考えるとなかなかのメリットだと思います!

■インスタントVM

インスタントVMとは

バックアップイメージを一時的なデータストアとしてESXiホストにマウントし、本来のデータストアへのデータ転送をすることなく迅速な復旧を可能にする機能

データ転送に時間がかかるなら、とりあえずデータ転送しなければいいじゃない!という発想ですね。

□仮想スタンバイを利用したバックアップ・リカバリ

  1. 仮想マシンのデータがデータストアからバックアップサーバーに転送され、バックアップイメージとしてバックアップサーバーに保存されます

    -----障害発生-----

  2. バックアップサーバー内のバックアップイメージを一時的なデータストアとしてESXiホストにNFSマウントします
  3. 一時的なデータストア内の仮想マシンファイルから仮想マシンが再作成され、電源をいれることで利用できるようになります

本来のデータストアに仮想マシンのファイルがなくても、仮想マシンを使えるようになるんです。
もちろん、そのままずっと使い続けるわけには行きませんが、ご心配なく!
あとからvMotionで本来のデータストアにお引越しさせればいいんです。
(正式に復活させずに、必要な仕事だけしてもらってすぐに消すのも選択肢の一つです)
インスタントVMのパフォーマンスは通常の仮想マシンと比較すると悪いので、いずれにせよ早めの2次処理がおすすめかな、と思います。

そうそう、仮想スタンバイの欠点として先程触れた「仮想環境側のリソースを余分に使う」といった心配は、インスタントVMではありません。
リカバリ後の処理は必要になるものの、バックアップ時点で何も準備しなくても使える、というのもインスタントVMの強みですね!

■まとめ

Arcserve UDPにおける、仮想マシンを迅速に復旧させるための2つの機能をご紹介しました。
簡単に2つの機能をまとめたいと思います。

仮想スタンバイ:予め仮想マシンをリストアしておく機能

  • バックアップの時点で準備が必要
  • 復旧時の手間が少ない
  • 仮想環境のリソースを余分に使う
  • スタンバイVMのパフォーマンスは本番機と同じくらい

インスタントVM:データを転送せずに仮想マシンを起動する機能

  • バックアップの時点で準備は必要なし
  • 復旧時に手間がかかる
  • 仮想環境のリソースを余分に使わない
  • インスタントVMのパフォーマンスは本番機より落ちる

最後に、仮想マシンを迅速に復旧させるために、他のバックアップ製品はどんな機能を備えているか、代表的なものを紹介して終わりたいと思います!
みんな考えることは似ていますが、ちょっとずつ特長があるので、比べてみると面白いかもしれません。

□Veritas NetBackup

  • AIR(Auto Image Replication)

    遠隔地でもすぐにリストアできるよう準備してくれるレプリケーション機能。
    リストアしてあるわけではないので、仮想スタンバイほどではありませんが有事の際の一手間が省けます!
    仮想マシン以外もレプリケーションできます。
    ※リンクはネットワールドネットワールドの製品紹介ページです

  • インスタントリカバリ

    インスタントVMとほぼ同じ機能。
    一時的なデータの書き込み領域を別途用意するため、一時的な仮想マシンのパフォーマンスが落ちにくいのが優位点!
    ※リンクは以前書いたブログ記事です

□Veeam Backup & Replication

  • フェールオーバーとフェールバック

    仮想マシンのレプリカを作成し、本番VMがダウンしたら即座にフェールオーバーさせる機能。
    フェールバックで切り戻します。
    アプローチはちょっと違うかもしれませんが、発想は仮想スタンバイと似ていますね。

  • インスタントVMリカバリ

    インスタントVMとほぼ同じ機能。
    仮想マシン復旧後のvMotionまでVeeamのコンソールで実行できるのが特長!


ありがとうございました!

書いた人:宮内