Actiphyの新しいコミュニケーション 「Biz-Communication」始まる
アクティファイでは、以前は全国各地のお客様を積極的に訪問して、ご挨拶から情報交換、製品紹介、技術セミナー、技術支援などを行って参りましたが、現在は同じような活動が行えない状況で、まだしばらくの間は難しいと思い、今回新しいコミュニケーション「アクティファイスタディ」と「アクティファイミート」をスタートさせる事になりました。
続きを読む…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
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 移行を試してみました – その１
一度クラウド化したものの、利用コストが当初見込みを大きく上回ったりするなどの理由で、「オンプレに戻すことを考えている」というお客様の声をお聞きすることがあります。
「どげんかせんといかん」と勝手に思い込み、クラウド初心者の私が 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 上に変換された直後の仮想マシン]
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 の設定
BootCheckの手動実行
Postbackupで自動的に実行されるBootCheck機能を手動で使用できるようになりました。
今までも無償の補助アプリケーション ImageBootを使ってローカルのHyper-VやVMware workstation 等で起動確認はできていました。 今バージョンからはImage ManagerからリモートのHyperVisorを使って起動確認を行うことができます。
今回のUpdateで、物理マシンローカルのエージェントベース、仮想マシンのエージェントベース、そして仮想マシンに対するエージェントレスバックアップを統合したバックアップソリューションとして、ActiveImage Protector 2018に計画していた機能はほぼ実装されました。
＜ActiveImage Protector、フィリピンで販売開始！＞
フィリピンの弊社製品の代理店、IPSYSTEMS, Inc.が5月31日（金）にマニラのDiscovery Suites ホテルにてActiveImage Protector Launch Meetingを開催することとなり、弊社 Global Sales Teamも参加しました。
イベントが開催されたホテルはIPSYSTEMS, Inc.に近く、ビジネスで賑わうオルティガス地区の中心部に位置します。現地のディストリビューター、リセラー、そしてActiveImage Protectorに興味をお持ちのエンドユーザー様が来場されました。
いよいよスタートです。
IPSYSTEMS, Inc.社長のPatricia Celisさんがご来場の皆様への感謝、IPSYSTEMS, Inc.の歴史、ミッション、取り扱い製品についてプレゼンテーションをおこないました。
次に、弊社副社長の山﨑がネットジャパンのご紹介、そして製品ラインやActiveImage Protectorをご利用のお客様についてご紹介しました。
その後、登壇したのは弊社製品開発マネージャーのEric Simmons。仮想環境へのエージェントレスバックアップ機能を搭載した新製品「ActiveImage Protector 2018 Update Virtual Edition」をはじめとするActiveImage Protectorの機能のご紹介と様々な環境での活用事例をわかりやすくご紹介しました。
休憩時間は、会場の外の喫茶コーナーに用意されたお茶やお菓子で気分転換。
休憩後は、IPSYSTEMS, Inc.のエンジニアによる ActiveImage Protectorのバックアップ、vStandby AIPなどのデモを行いました。来場者は、ActiveImage Protectorのマニュアル不要の操作の簡単さに大変興味を持たれていました。
その後Q&Aセッションに入り、来場者からは「無料版ESXiをインストールした環境でActiveImage Protectorを使ってバックアップを取れるのか」、「翌年度の以降のサポートサービス料はライセンスの購入価格の何パーセントなのか」等々、製品の機能やライセンスポリシーについての質問が相次ぎました。
アンケートをご記入いただいた方を対象とした抽選会を行い、結果を発表！
会場が熱気に包まれる中、ActiveImage Protector Launch Meetingは幕を閉じました。最後にご来場の皆様との記念写真をパシャッ！
海外市場に挑戦するためには、乗り越えなければならない課題がたくさんあるかと思います。より多くのお客様に弊社のソリューションを活用していただけるように努力してまいります。