ActiveImage Protector

低コストでシステムのDR対策を実現「ActiveImage Protector 2018 Update for RDX」のご紹介

今回は、低コストで実現するシステムのDR対策(災害復旧対策)として、「ActiveImage Protector 2018 Update for RDX」の活用例について紹介します。

近年の度重なる集中豪雨や台風による水害などの自然災害、火災、ランサムウェアに代表されるコンピュータウイルスは事業継続を脅かす脅威になっています。これらの災害時に、迅速な復旧による事業継続のシナリオを確保するためには、バックアップによるシステムやデータの保護は必要不可欠といえます。

しかし、災害によってすべてのバックアップデータが一気に消失したら、業務継続はもちろんですが、企業としての信頼を損なう可能性があります。このため、バックアップデータをリモートサイトやクラウドストレージなど安全な場所に保管するための対策が必要になります。ただし、膨大なバックアップデータをネットワーク経由で転送するための高速な回線やバックアップ保存先の大容量のストレージなど設備が必要となることから、限られた予算の中で対策を実現することは依然として重要な課題となっています。

災害復旧対策の1つの現実解

DR対策として、タンベルグデータ社のRDXをバックアップ保存先として使用する専用バックアップツール「ActiveImage Protector for RDX」について活用例を交えて紹介していきます。

◇ ActiveImage Protector for RDXの特長

① シンプルなバックアップ構成

ActiveImage Protector for RDXは、WindowsおよびLinuxサーバーに、USBに接続したRDX装置(*1)にシステムおよびデータを丸ごと簡単にバックアップできます。また、大容量のサーバーやNASについては、複数のRDXカートリッジを1つのカートリッジとして使用することも可能な最大8つのRDXカートリッジを搭載可能なiSCSI接続のRDX装置も利用できます。

* 1:RDX(Removable Disk Exchange system)とは

DDSやDATテープの代替を主な目的に開発されたHDDを内蔵したカートリッジをRDXドライブに着脱して使用するバックアップ装置です。小型で軽量なカートリッジは非常に頑丈な設計で、持ち運び・外部保管に適しているので災害対策もできるバックアップ装置です。

② バックアップデータを暗号化して安全に外部保管が可能

RDXカートリッジは、可搬性や外部保管にすぐれていますので、高速なネットワーク接続や高価な保管先のストレージが無くても、定期的にRDXカートリッジを取り外してリモートサイトへの搬送や耐火金庫に保管して、バックアップデータを災害から安全に保護することができます。また、不測の事態にはRDXカートリッジを手でもって安全な場所に避難するだけでもバックアップデータを保護することができるのです。さらに、ActiveImage Protector for RDXは、バックアップデータを暗号化してRDXカートリッジに保存する機能を搭載していますので外部保管も安心です。

③ 自動イジェクト機能によるバックアップデータのオフライン化

ランサムウェアはネットワークを介して感染を広げることから、ネットワークに接続されているストレージのバックアップデータまで暗号化される可能性があります。この点を考慮すると、バックアップ保存先はネットワークから完全に隔離できる媒体を選択することも有効な対策となります。

ActiveImage Protector for RDXは、バックアップ終了後など以下のタイミングでRDXカートリッジを自動的にイジェクトしてオフラインにする機能を搭載しています。これにより、RDXカートリッジを取り外し忘れるというミスをなくすことで、バックアップデータの損失やウィルス感染のリスクを軽減することができます。

・週単位: 特定曜日の最後のバックアップ完了後

・日単位: 毎日特定の時間

・バックアップ終了後: 毎回バックアップ完了後

◇ 最後に

自然災害、火災、ウィルスなどの災害に対して、100%未然に防ぐことは不可能であることを考慮すると、日々のバックアップ運用はもちろんですが、バックアップデータの保護も重要となります。しかし、バックアップデータの保護対策まで手が回らず後回しになっているケースが多いのではないでしょうか。

今回、DR対策として低コストで簡単に導入できる「ActiveImage Protector for RDX」を検討いただければ幸いです。

参考情報

ActiveImage Protector for RDX 製品紹介サイト

ActiveImage Protector for RDX 評価版申込サイト

タンベルグデータ社 RDX 紹介サイト

データストレージ社のWindows用 RDX バンドルモデル紹介サイト

Actiphyの新しいコミュニケーション 「Biz-Communication」始まる

アクティファイでは、以前は全国各地のお客様を積極的に訪問して、ご挨拶から情報交換、製品紹介、技術セミナー、技術支援などを行って参りましたが、現在は同じような活動が行えない状況で、まだしばらくの間は難しいと思い、今回新しいコミュニケーション「アクティファイスタディ」と「アクティファイミート」をスタートさせる事になりました。

  • アクティファイスタディ

今まで毎月定期セミナーとして開催しておりました技術セミナーです。9月中旬開催予定の初回は、ギガスクール需要でまだまだご要望の多い、キッティングに関連するセミナーを開催いたします。

■ パソコンキッティングの効率化セミナー内容(予定)

・キッティングとは

・マスターの作成(Sysprep、Windows Updateについて)

・マスターの展開(ActiveImage Deploy USBのご説明)

・質疑応答

  • アクティファイミート

時間の都合等で「アクティファイスタディ」では詳細が分からない場合などのフォローを時間制限のない「アクティファイミート」で対応させて頂きます。

「アクティファイミート」はアポイント制となりますので、近日中に弊社ホームページからのお申込み受付を開始いたします。

お急ぎの案件やご不明な点などございましたら、お気軽に弊社営業本部( sales@actiphy.com )にご一報頂ければ幸いです。

皆様からのご参加とお誘いを心よりお待ちしております。

AWS EC2からHyper-VへのVM移行を試してみました – その6(最終回)

今回は、最後となりますが、以下のステップ5のHyper-Vへの仮想マシンの移行後に必要な処理について解説していきます。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

移行後に、必ず行う必要があるのが、以下の1) のOSのライセンス認証と2) のネットワーク設定です。
3) については、私が調べた限りでは、AWSのプログラム等はオンプレ上では不要と思われますので削除しています。

1) OSのライセンス認証
移行直後は、Windowsのライセンス認証が外れています。

» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その5

前回は、Hyper-VへのVM移行に使用するイメージファイルの作成手順を紹介しましたが、今回は、以下のステップ4の[ActiveImage Protector] の仮想化機能を利用して、EC2インスタンスのバックアップイメージから、直接、検証用のHyper-V上に変換した仮想マシンを作成する手順を紹介していきます。以下の検証環境図の赤枠の部分です。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その4

前回までは、検証用のEC2の作成、バックアップ保存先のストレージボリューム追加の手順を紹介してきましたが、いよいよ本題に入ります。

今回は、以下のステップ3の[ActiveImage Protector]を利用してEC2インスタンスのバックアップを行い、前回、作成した保存先のボリュームへVM移行に使用するイメージファイルを取得してみます。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理


» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その3

前回は、検証用のEC2インスタンスを構築しましたが、今回は、以下の[ステップ2]のEC2のVM移行作業において、「ActiveImage Protector」のバックアップ保存先として、一時的に利用するストレージボリュームをAWS上に新規に作成してみたいと思います。以下の検証環境図の[赤枠] の部分です。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その2

「AWS EC2からHyper-VへのVM移行を試してみました – その1」をお読みいただき、ありがとうございます。

今回は、以下の「ステップ1:AWS EC2を構築」について、EC2 仮想マシン(VM)の移行検証環境として、移行元のEC2インスタンスを構築してみます。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

具体的には、以下の構成概要図の[VPC(Virtual Private Cloud)]と[EC2(Elastic Compute Cloud)]を作成して、リモートデスクトップ(RDP)から接続するまで進めてみたいと思います。また、どなたでも試していただけるように、詳細にまとめてみました。

» 続きを詳しく読む

AWS EC2 から Hyper-V への VM 移行を試してみました – その1

一度クラウド化したものの、利用コストが当初見込みを大きく上回ったりするなどの理由で、「オンプレに戻すことを考えている」というお客様の声をお聞きすることがあります。
「どげんかせんといかん」と勝手に思い込み、クラウド初心者の私が AWS EC2 から Hyper-V への VM 移行を「ActiveImage Protector」の「バックアップ」と「仮想化」機能を使って試してみましたので、その話をしようと思います。

試す前に、AWS EC2、VPC、EBS・・、意味不明な用語について、得意のインターネットからググり何とか理解?して、試行錯誤の末に以下の検証環境を構築しました。

・移行元: AWS EC2インスタンス(Windows Server 2016 (x86_64) t2.micro)
・バックアップ保存先:追加ストレージボリューム(Amazon EBS)
・移行先: Hyper-V(Windows 10 Enterprise)

検証概要は、こんな感じです。
悩みましたが、簡単、確実、且つローコストで移行できる方法ではないかと、いつものごとく勝手に思い込んでいます。

EC2 の移行と書くと凄そうですが、単にバックアップ保存先を EC2 のローカルボリュームに配置することぐらいです。失敗談として、バックアップ保存先の追加ボリュームが別リージョンに作成されていたため、バックアップ検証毎にデータ転送料金「DataTransfer」が加算されていました。

最後に、実際試してみて「ActiveImage Protector」の「バックアップ」と「仮想化」機能を利用すれば、クラウドからオンプレへの移行が簡単にできます。今回の検証方法について、全部一気に書くととても長くなってしまいますので、今後、以下のステップで紹介していきます。

次回は、「AWS EC2インスタンスを構築」についての話をしたいと思います。

・ステップ1:AWS EC2 を構築
・ステップ2:AWS EC2 にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2 をバックアップ
・ステップ4:バックアップから直接 Hyper-V 上に仮想マシン作成
・ステップ5:移行後の処理

By Oki

[仮想化設定の画面]

[Hyper-V 上に変換された直後の仮想マシン]

続きはこちら:「AWS EC2 から Hyper-V への VM 移行を試してみました – その2

HyperBoot リリース

HyperBootをリリースしました。

HyperBoot とは

HyperBootリリースしました。この製品はActiveImage Protector のユーザー向けに無償配布していたImageBootの後継製品です。

HyperBootはActiveImage Protector のバックアップイメージファイルを直接仮想マシンの仮想ディスクとしてアタッチして起動し使用できます。
通常はバックアップイメージを利用するためには、物理にしろ仮想にしろ実際に復元作業をする必要がありました。ディスクの実体を作成してそこから起動というのが通常の手順です。
これを直接イメージファイルをディスクとしてシステムに認識させることで復元作業をせずに、即時起動できるようにしたのがImageBootでした。

ImageBootでは、VMware Workstation,Player,VirtualBox,ローカルのHyper-Vで利用が可能でしたが、イメージファイルの物理ディスク化のためにローカルマシン上で動作するデバイスドライバを使用していたのでローカルマシン上の仮想環境アプリケーション、ハイパーバイザーのみという制約がありました。

iSCSI対応の技術開発

iSCSIはその名前の通り、インターネットを介したSCSIプロトコルの接続です。
ActiveImage Protector のアップデートにはiSCSI対応の開発が含まれており、完了しました。ActiveImageのバックアップイメージをiSCSIのターゲットとして公開し外部から接続できる技術です。

最近のハイパーバイザーではiSCSIのディスクを仮想ディスクとして扱うことができるので、iSCSI接続のディスクを使った仮想マシンの起動が可能です。もちろん起動するまでにはイニシエーターの設定から始まり、仮想ディスク、仮想マシンの設定、アタッチが必要なので詳しい人ならできる、という状態でした。

そこで、この技術をImageBootでも採用し、GUIを含めてすべて見直して作り直すことにしました。リモートのハイパーバイザーを使ってバックアップイメージからの仮想マシンの直接起動が簡単にできるようになりました。

HyperBootの操作

操作は非常に簡単です。イメージファイルから起動した復元ポイントを選択して起動するだけです。

バックアップイメージファイルを保存したフォルダを指定すると、ソースのコンピューター名(クライアント名)最新の復元ポイントが表示されます。各クライアント毎の復元ポイントを個別に指定することもできます。

HyperBootの起動に使用する仮想マシンの設定を行います。起動確認だけでなくしばらく運用したい場合にはリソースを多めに取っておきます。

 

起動後に変更した部分は差分ファイルとして保存されます。一時的な運用を行った場合でも、その間のデーターを失うことはありません。停止後に再開もできますし、差分ファイルから復元を行えば作業内容も含めて復元できます。

vMotionによるシームレス復旧

さて、せっかく起動したのでそのまま実運用にしてしまいたくなる気持ちが湧いてくるのではないでしょうか?正直なところ起動した状態そのままの運用はイメージと直接やりとりをしているのでリソース的にも速度的に推奨というわけにはいきません。

一方で、イメージファイルから即起動して運用を再開、しばらくしたら自動的に本番環境の復旧が終わっている、そのようなソリューションがあればと思います。

以前からのActiveImage Protectorユーザーなら実際にそうした機能を実現していた  Hyper-V版のReZoom™ it! ライブや、SHR(シームレスホットリストア)機能を思い出すかもしれません。即起動してバックグラウンドで復元を行ってしまう。そのような機能をリモートのハイパーバイザーでも実現できないでしょうか?残念ながら現在のHyperBootではまだそこまでカバーはしていません。

しかし、ESXi限定になりますがvMotionのストレージ移動機能を使えば実現できます。

vMotionは仮想マシン、仮想ディスクの実体を物理ホスト間で仮想マシンを起動したままの状態で移動できるESXiの機能です。ストレージ移動する時に移動元としてiSCSI経由でアタッチしたディスクも対象にできます。つまり、HyperBootで起動した状態でvMotionを使ってストレージを本番環境に移動すれば仮想マシンを復旧したのと同じ状態になりますので、そのまま継続して使用可能になります。

vMotion自体は簡単で、ESXiの管理コンソールから仮想マシンを指定して、移動するだけです。

HyperBootでは内部的にiSCSI接続をしていますが、ActiveImage Protector の最新版ではiSCSI Target 機能があるので汎用的にiSCSIディスクとしてバックアップイメージを利用することができます。また、バックアップ直後に起動を確認するBootCheck機能もあります。起動確認からさらにアプリケーションなどの復元確認を行う必要がある場合にはHyperBootを使うことで運用段階での動作確認が可能です。

ActiveImage Protector 2018 Update 4

ActiveImage Protector 2018 Update 4 リリース

ActiveImage Protector 2018 Updateも順調に4番目のリリースになりました。
今回の主なアップデート内容は

  • HyperStandby/HyperRestore のLinux LVMへの対応
  • レプリケーション機能の追加
  • BootCheckの手動実行

になります。

HyperStandby/HyperRestoreのLinux LVM への対応

HyperAgentは仮想マシンのディスクから直接バックアップイメージファイルを作成します。前バージョンでは、Windowsに関してはほぼ問題ありませんでしたが、Linux特にLVMシステムへの対応ができておらず別のハイパーバイザーなどにリストアした場合起動しない場合がありました。
HyperStandbyはHyperAgentが取得した仮想マシンイメージを使って、別ホストのハイパーバイザー経由でスタンバイ仮想マシンを作成しておき、必要なときにすぐに起動できるソリューションです。vStandby、vStandby AIPと続くNetJapanのStandby機能のひとつですが、やはりスタンバイ仮想マシンの作成に成功しても起動しないという場合がありました。
とくに、ハイパーバイザーを混在しての運用の場合、元と違うハイパーバイザーに仮想マシンを作成すると、各々のハイパーバイザーで使うドライバ、特にディスクコントローラーが欠けているとシステムは起動しませんので、ひと手間くわえた仮想変換を行う必要があります。

新しいバージョンではバックアップイメージを作成時に正しいドライバを含む環境の情報を組み込むようになるため、殆どの場合で起動が可能になります。

レプリケーション機能の追加

レプリケーションを使うと取得したバックアップイメージファイルをソースマシンとは別の場所にバックアップファイルを隔離して地理的な障害に対応することができます。

いままでは、無償で提供されているActiveImage Protector の補助ツール ImageCenterで行う運用でした。ImageCenterはバックアップイメージフォルダを監視して新しいファイルが作成されたら自動的にレプリケーションやコンソリデーションを行います。独立したアプリケーションなのでバックアップしているソースマシンとは別のマシンで動かすことができるためレプリケーションの負荷分散を行うことができました。 もちろん同じマシンで動かしても問題ありません。

一方でバックアップ直後にすぐレプリケーションをしておきたいという要望もありました。もちろんImageCenterでもバックアップ後すぐにレプリケーションは可能ですが、ポストバックアッププロセルに組み込んでおけば細かい設定は不要になります。

また、レプリケーション先としてクラウドストレージにも対応しました。ImageCenterでも可能だった Azure Storage に加えて OneDrive for Bussiness, Google Drive, Dropboxをレプリケーション先として選択可能です。各々のクラウドストレージに保存するには、各々の認証システムに従った設定が必要になります。

新しいレプリケーションターゲット

新しいレプリケーションターゲット

OneDrive for Bussiness の設定

OneDrive for Bussiness の設定

BootCheckの手動実行

Postbackupで自動的に実行されるBootCheck機能を手動で使用できるようになりました。
今までも無償の補助アプリケーション ImageBootを使ってローカルのHyper-VやVMware workstation 等で起動確認はできていました。 今バージョンからはImage ManagerからリモートのHyperVisorを使って起動確認を行うことができます。

今回のUpdateで、物理マシンローカルのエージェントベース、仮想マシンのエージェントベース、そして仮想マシンに対するエージェントレスバックアップを統合したバックアップソリューションとして、ActiveImage Protector 2018に計画していた機能はほぼ実装されました。

アーカイブ

Powered by WordPress, WP Theme designed by WSC Project. ログイン