それ、レプリケーションでよろしく。UDPともども。

本番環境がダウンした際の復旧方法としては、バックアップソフトでのリストア（復旧）がまず挙げられます。

しかし、近年はデータ量が大きくなってきているので、データ量に比例して時間がかかるリストアでは、業務再開まで数時間から数十時間待たなければいけないという事もあります。

こういった長時間の業務停止を避けるため、重要なシステムでは冗長化を検討されると思います。

「冗長化」とは障害が起きてもシステムを継続稼働できるよう、部品やデータ、仮想マシンなどの構成要素を複数持っておくことを言い、代表的な構成は、HAクラスタやFTがあります。

しかし、これらの高可用性を実現する手段は、専門知識を必要としたり、金額が高額になったりと、なかなか導入に踏み切ることができないケースが多々あります。

 

高可用性を実現できるArcserve ソリューションとは？

こういった高可用性ニーズに応えるべく、Arcserveには専門知識を必要とせず低価格で高可用性を実現できるソリューションがあることをご存じでしょうか？

それが以下の3つのソリューションになります。

 

・仮想スタンバイ (Arcserve UDP)

・インスタントVM (Arcserve UDP)

・フルシステム シナリオ (Arcserve Replication/HA)

 

いずれの製品、機能でも、OSを含めたシステム全体を仮想環境/クラウド上に短時間で復旧して業務再開することができます。

この3つの方法はいずれも「リストア時間ゼロ」となっていますが、違いはどこにあるのでしょうか？

以降でそれぞれの特徴と注意点を見ていきましょう！

 

仮想スタンバイ (Arcserve UDP)

Arcserve UDPの仮想スタンバイは、バックアップデータを仮想変換し、仮想環境/クラウド環境へ仮想マシンを作成します（※1）。

既に仮想マシンが作成されているため、マシンを用意する時間だけでなくデータをリストアする時間も不要になるため、障害からの復旧時間をより短縮できます。

仮想スタンバイで必要なのはArcserve UDP で取得済みのバックアップ データと、スタンバイVMを作製する先の仮想基盤/クラウド基盤のみです。Arcserve UDPの持つバックアップデータの遠隔転送機能と組み合わせる事も可能で、手軽にDR/BCP環境を構築することが出来ます。

ただし、仮想スタンバイが対応しているのは Windows サーバのみです。

また、バックアップデータからの復元になるため、スタンバイVMが持つデータは前回のバックアップ時点のものになります。

<特徴>

・バックアップの延長線上で利用できる

・vSphere、Hyper-V、Nutanix AHV、Amazon EC2、Microsoft Azure、Arcserve UDP Cloud Hybrid と、多様な環境にスタンバイできる

・仮想化/クラウド基盤に永続的に使用できる仮想マシンを作成できる

・設定ウィザード不要で電源ONで即起動

 

<注意点>

・スタンバイできるVMはWindows のみ

・前回のバックアップ以後のデータに復旧

 

<活用シーン>

・DR/BCP対策

・仮想/クラウド移行

 

仮想スタンバイに関しては以下のブログで詳しく紹介しています。

「Arcserve UDP 機能紹介 ～ (12) 仮想マシンへの自動復旧（仮想スタンバイ） ～」

 

インスタントVM (Arcserve UDP)

Arcserve UDPのインスタントVMは、仮想スタンバイと似ている機能ですが、決定的な違いは、仮想マシンの実体がバックアップデータそのものであるということです。

バックアップデータを直接マウントし、CPU/メモリリソースを割り当てて仮想マシンとして起動することで迅速な復旧を可能にする機能です。

仮想スタンバイと違い、事前に設定しておく必要がないので、必要な時に簡単な設定で起動することができます。

だたし、仮想マシンの実体がバックアップデータであるため、長期運用すればするほど、パフォーマンスが低下する懸念があるため、障害時の緊急参照用としての用途として使われるケースが多いです。

こちらは、仮想スタンバイと異なり Linux にも対応しています。

<特徴>

・バックアップの延長線上で利用できる

・vSphere、Hyper-V、Nutanix AHV、Amazon EC2、Microsoft Azure、Arcserve UDP Cloud Hybrid と、多様な環境で利用できる

・Windows/Linux両方に対応（※2）

 

<注意点>

・一時的な参照に向いている

 

<利用シーン>

・緊急参照用

 

インスタントVMに関する詳しい機能等は以下のブログで紹介しています。

「Arcserve UDP v6 新機能紹介 ～ (2) 仮想マシンとして即時復旧 (インスタントVM) ～」

 

前述の仮想スタンバイとの違いは、以下のブログにて紹介しています。

「インスタントVMと仮想スタンバイとの違い」

 

フルシステム シナリオ (Arcserve Replication/HA)

Arcserve Replication/HA の18.0からフルシステム シナリオという新機能が搭載されました。

このフルシステム シナリオはリアルタイムでOSを含めたシステム全体が複製されるので、障害発生直前の環境で複製済みのVM(レプリカ)をご使用いただけます。

また、このリアルタイムという点は移行ツールとして使用する際にも便利です。

移行作業中にデータを複製する必要がなく、複製元（マスタ）サーバを停止後、複製先（レプリカ）を起動させるだけで、短時間で手間をかけずにシステムを切り替えることが出来ます。

もともとArcserve Replication/HAはLinux未対応でしたが、18.0からフルシステム シナリオ限定でLinux対応となりましたので、WindowsとLinuxが混在している環境でも柔軟に対応することができます。

Arcserve Replication/HAは Arcserve UDP とは別なソフトウェアで、「Arcserve RHA エンジン」と呼ばれるエージェントのようなコンポーネントを複製対象のサーバにインストールし、複製先には仮想アプライアンスを用意する必要があります。（※3）

ライセンスも別に買う事ができますが、Arcserve UDP Premium Plus Edition を購入すれば、Arcserve UDPとArcserve Replication/HA の両方のライセンスがセットになっているのでお得です。

<特徴>

・リアルタイム複製で障害直前の状態で復旧できる

・vSphere、Hyper-V、Amazon EC2、Microsoft Azureへシステムを複製できる

・Windows/Linux両方に対応

 

<注意点>

・世代管理(バックアップ)が必要な場合は、 Arcserve UDP のようなバックアップソフトも合わせてご検討ください

 

<利用シーン>

・DR/BCP対策

・仮想/クラウド移行

 

以下のブログでArcserve RHA フルシステム シナリオを詳しくご紹介していますので、ぜひご確認ください！

「Arcserve Replication/HA 18.0 新機能！フルシステムシナリオでサーバを丸ごと複製」

「Arcserve Replication/HA 18.0ではLinuxサーバ全体のレプリケーションが可能に！」

「Arcserve Replication/HA：フル システム シナリオとそれ以外のシナリオの使い分け」

 

まとめ

これまでご紹介してきた3つのソリューションの、それぞれの特徴を以下にまとめました！

いずれのソリューションも代替運用として使用できますが、それが長期的なのか短期的なのかで選択してください。

Windowsでデータ更新の多いサーバは仮想スタンバイ、データ更新のないサーバはインスタントVM をお勧めします。

また、仮想環境/クラウドで起動する仮想マシンの起動状態が、障害発生直前のデータでご使用いただきたいのであればフルシステム シナリオ、とりためたバックアップの世代から選択したい場合は仮想スタンバイをお勧めします。

対するインスタントVMは、緊急参照用としての用途が適しています。

例えば、システムがランサムウェアに感染し、バックアップデータのどの時点まで戻ればよいかわからないようなときに、インスタントVMで複数起動して正常な状態を特定するような場合に使ったりすることができます。

 

このように、ご使用の環境に応じて、柔軟にこれらArcserveソリューションを選択することができます。

システムの冗長化や、災害時の自動復旧、仮想環境/クラウドへのシステム移行でお悩みの方は是非、Arcserve ソリューションでの実現をご検討ください！

 

---

※1
初回の仮想変換以降は増分バックアップの度にスナップショットを追加していくことで、短時間で仮想変換が完了します。また、任意のバックアップ時点での復旧が可能になります。

 

※2
Nutanix AHV、Amazon EC2、Microsoft Azure、Arcserve UDP Cloud Hybrid では Linux サーバのみがインスタントVMとして起動できます。

 

※3
Hyper-Vの場合はホスト側にRHAエンジンをインストールするため、仮想マシンは不要