検索
連載

クラウドでDR対策の常識が変わる! Microsoft Azure復旧サービスの全機能が正式公開Microsoft Azure最新機能フォローアップ(2)(2/2 ページ)

2014年10月3日、マイクロソフトは「Microsoft Azure Site Recovery」でプレビュー提供していた一部の機能の正式提供を開始しました。正式提供された機能は、オンプレミスのシステムを直接クラウドへレプリケーション/フェイルオーバーする機能になります。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

Azure Site Recovery、プレビューからの変更点

 今回一般提供が開始されたAzure Site RecoveryのオンプレミスのHyper-VサイトとAzure間の保護については、以下のレビュー記事で詳しく紹介しています。

 前述したように、「オンプレミスのHyper-VサイトとAzure間の保護」は、System Center 2012 R2のVMMで管理されるVMMクラウド上に展開した、Windows Server 2012 R2 Hyper-Vホスト上の仮想マシンを、Microsoft Azureのストレージを使用してレプリケーション保護します(画面7)。

画面7
画面7 Azure Site Recoveryで保護されたVMMクラウド上の2台の仮想マシン

 オンプレミスのVMMクラウドが障害などで利用できなくなった場合、あるいは計画的なメンテナンス作業のために一時的に利用できなくなる場合は、非計画的または計画的なフェイルオーバーを実行して、Microsoft Azure側で仮想マシンを復旧します。

 Microsoft Azure側では、レプリケーションされた仮想ハードディスク(VHDまたはVHDX)を使用して、Azure仮想マシンを作成し、顧客専用のAzure仮想ネットワークに接続した状態で仮想マシンを開始して復旧します(画面8)。

画面8
画面8 フェイルオーバー(この例はオンプレミスに影響しないテストフェイルオーバー)を実行すると、Azure仮想マシンが作成、開始される

 オンプレミスとAzure仮想ネットワークは、サイト間VPN接続によってシームレスに相互接続されるため、オンプレミス側のクライアントは社内ネットワークを通じてAzure仮想マシンに接続することができます。

 オンプレミス側のVMMクラウドが利用可能になった時点で、Microsoft Azureからオンプレミスに対してフェイルバックを実行すると、Azure仮想マシン側で行われた変更がオンプレミス側の仮想マシンにレプリケーションされ、レプリケーションの関係が元の運用形態に戻ります。

 「オンプレミスのHyper-VサイトとAzure間の保護」の概要をざっと説明しましたが、主要な部分はプレビューから変更されていません。プレビューからの変更点については、次に説明します。

証明書の準備とアップロード作業が不要に

 Azure Site Recoveryを利用するには、「Microsoft Azure管理コンソール」で資格情報コンテナーを作成し、そのコンテナーに事前に準備しておいた公開鍵証明書(.cer)をアップロードする必要がありました。この証明書はVMM管理サーバー側の秘密鍵証明書とペアで、資格情報コンテナーを認証、識別するために使用されるものです。

 Azure Site Recoveryサービスに対して2014年9月に行われた更新により、証明書の準備とアップロード作業の必要はなくなりました。その代わりに、Microsoft Azureポータルで登録キーファイルの生成、ダウンロードして、プロバイダーのインストール時に登録キーファイルを指定する形になります。

Azure仮想マシンは自動的にクリーンアップ

 初期のプレビューでは、Microsoft Azureからオンプレミスに対して仮想マシンをフェイルバックしたときに、仮想マシンが停止状態で残りました。課金対象から外れる「割り当て解除済み」の状態ではない停止状態であったため、残された仮想マシンに対する課金が非常に気になるところでした。

 フェイルバック時にMicrosoft Azure側に仮想マシンが残るという仕様はなくなり、テストフェイルオーバーが完了した際、あるいはフェイルバックを実行してコミットした後に、Microsoft Azure側の仮想マシンが自動的に削除されるようになりました(画面9)。そのため、フェイルオーバーを待機するために、無駄に課金が発生することがなくなりました。

画面9
画面9 テストフェイルオーバー完了時、およびフェイルバック(逆方向の計画的フェイルオーバー)のコミット時にAzure側の仮想マシンはクリーンアップされ、存在しなくなる

レプリケーションの反転はフェイルバック時に

 Azure Site Recoveryのオンプレミスのサイト間の保護(旧:Azure Hyper-V Recovery Manager)の場合、バックアップ用のVMMクラウドにフェイルオーバーした後に、元のVMMクラウドが復旧したらレプリケーションを反転させることができます。完全に同期した段階で、もう一度逆方向の計画的フェイルオーバーを実行すると、正常運用時のレプリケーションの関係に戻ります。

 これに対し、オンプレミスとAzure間の保護の場合、「計画的か、非計画的か」というフェイルオーバーの種類に関係なく、レプリケーションの反転は常にフェイルバックの実行時に行われます。フェイルバックとは関係なくレプリケーションを反転させ、Azure仮想マシンをオンプレミスのVMMで保護するという運用はできないようです。

 フェイルバックを実行する際には、「同期を最小限にする」方法と「ダウンタイムを最小限にする」方法の二つから選択できます。

 「同期を最小限にする」方法は、Azure仮想マシンのシャットダウンを開始して、レプリケーションを反転し、Azure仮想マシン側の変更をオンプレミス側に完全に同期してから、仮想マシンをオンプレミス側にフェイルオーバーします。

 「ダウンタイムを最小限にする」方法は、フェイルオーバー中のAzure仮想マシンを稼働させたままでレプリケーションを反転させ、レプリケーションの同期が完了してフェイルオーバーの準備が整った段階で、ユーザーの指示によりフェイルオーバーの残りの処理を実行します。フェイルオーバーの準備が整った時点だけを見れば、Azure仮想マシンをオンプレミスのVMMクラウドで保護している形になりますが、一連のフェイルバック処理の中でレプリケーションが反転していることには変わりません。

 また、フェイルバックが完了すると、Azure側の既存のレプリカは破棄され、もう一度、オンプレミス側の仮想マシンの初期レプリケーションがAzureに対して行われます。仮想マシンの保護を設定したときと同じだけの、大量のデータ送信が始まるということです(画面10)。オンプレミスとAzure間の保護におけるこの辺りの動作が、オンプレミスのサイト間の保護とは異なる点に注意が必要です。

画面10
画面10 Azure仮想マシンが稼働中に仮想ハードディスクに対して行った変更は、フェイルバックの一連の処理の中でオンプレミス側の仮想マシンにレプリケーションされる。フェイルバック後は、もう一度、初期レプリケーションから始まることに注意

オンプレミスからAzureの復旧計画でスクリプトの実行をサポート

 Azure Site Recoveryでは「復旧計画」(Recovery Plan)を作成することで、複数の仮想マシンをグループ化し、依存関係を考慮して仮想マシンの開始順序を構成できます。復旧計画を使用すると、VMMクラウドにある全ての仮想マシン(またはその一部)をワンクリックでフェイルオーバーできます。

 オンプレミスからオンプレミスのサイト間保護では、復旧計画のプロセスの一部として、スクリプト(Windows PowerShell)の実行が以前からサポートされていました。オンプレミスからAzureのサイト間保護では、プレビュー開始時点ではスクリプトの実行がサポートされていませんでしたが、2014年9月12日(日本時間)にサービスが拡張され、Azure Automation(プレビュー)との統合によるスクリプトの実行がサポートされました(画面11)。

画面11
画面11 オンプレミスからAzureのサイト回復のための復旧計画において、Azure Automationを利用したスクリプトの実行がサポートされた

Azure Site Recoveryの価格にIaaS分は含まれない

 Azure Site Recoveryは、保護される仮想マシンの台数に基づいて課金されます。課金は1カ月における1日当たりの平均の仮想マシン数を「1単位」として計算され、オンプレミスのサイト間の保護の場合は仮想マシン1台当たり月額1632円、オンプレミスとAzure間の保護の場合は仮想マシン1台当たり月額5508円(12月1日から、11月30日までは50%オフのプレビュー料金を継続)かかります。

 いずれも仮想マシンの保護に対する課金であることに注意してください。オンプレミスとAzure間の場合、これとは別にAzureストレージへのレプリケーションのためにストレージの利用に対して課金が発生します。具体的には、使用したストレージ容量、ストレージトランザクション、転送されたデータ(Azureからの送信方向のみ)に基づいて課金されます。このストレージの課金については、次に説明するAzure Site Recoveryサブスクリプションライセンスでカバーする方法もあります。

 また、オンプレミスとAzure間の場合、オンプレミスとのサイト間VPN接続やフェイルオーバーのために追加の課金が発生します。フェイルオーバーには、Microsoft Azureの仮想マシンおよび仮想ネットワークが利用されます。仮想マシンは、保護される仮想マシンがWindowsかLinuxであるかによって課金レートが異なります。Azure仮想ネットワークは、オンプレミスとのサイト間VPN接続のためのVPNゲートウェイが利用可能になっている間、課金される時間当たりの料金と、VPN接続を通るデータ転送(Azureからの送信方向のみ)に課金されるGbyte当たりの料金が掛かります。

Azure Site Recoveryサブスクリプションは必須ではなくなった

 オンプレミスとAzure間のサービスのプレビュー提供が開始されたとき、料金詳細ページにはMicrosoft Enterprise Agreement(EA)が必要であると明記されていました。このEAとは、「Azure Site Recoveryサブスクリプションライセンス」のことです。Azure Site Recoveryサブスクリプションライセンスは、Microsoft Enterprise Agreementボリュームライセンスを通じて2014年8月1日より販売されています。

 オンプレミスからAzureのサイト回復の一般提供が開始されたいま、Azure Site Recoveryサブスクリプションライセンスは必須要件ではなくなりました。Azure Site Recoveryは従量課金の料金体系だけで利用できます。Azure Site Recoveryサブスクリプションライセンスは、従量課金ではない企業向けの契約タイプと考えれば良いでしょう。

 現在、Azure復旧サービスのサブスクリプションライセンスとして、次の三つの契約が用意されています。

  • Azure Backup:月100Gbyteまでのバックアップデータの保存に対応
  • Azure Site Recoveryオンプレミスからオンプレミスのサイト回復:オンプレミスの二つのサイト間のレプリケーション保護に対応。InMage Scoutソフトウェアの使用権を含む
  • Azure Site RecoveryオンプレミスからAzureのサイト回復:オンプレミスとAzure間のレプリケーション保護に対応。仮想マシンごとに1カ月当たり100Gbyteまでのレプリケーションおよびストレージの利用枠を含む

 サブスクリプション契約の上限を超える利用については、通常の従量課金のレートに基づいて課金されます。InMage Scoutソフトウェアの使用権は、Azure Site Recoveryサブスクリプションライセンスでのみ提供されます。

特に中小規模企業の災害対策にお勧め

 Azure BackupサービスとAzure Site RecoveryのオンプレミスとAzure間の保護は両方とも、Microsoft Azureというパブリッククラウドのインフラストラクチャを自社の災害対策の二次拠点として利用できるため、自前で遠隔地に二次拠点を用意するのが難しい中小規模の企業にとって魅力的でしょう。

 Microsoft Azureの東日本(埼玉県)と西日本(大阪府)のデータセンターは、相互に大規模災害の影響を受けないだけの十分な距離が離れているので、自社から遠い方のデータセンターを利用すればよいのです。

 災害対策の拠点がパブリッククラウドなので、設備やハードウェアのコストがかからない分、少ないコストで有効な災害対策を実装できるでしょう。日本国内のデータセンターを利用できるので、海外のデータセンターを利用するよりも安心感がありますし、ネットワークの遅延の影響も少なくて済みます。ただし、Azure Site Recoveryの方は、VMMの管理環境が必須になることだけは留意してください。スタンドアロンのHyper-Vホストを、Azure Site Recoveryで保護するということは、少なくとも現状はできません。

クラウドへの移行シナリオにも応用可能

 Azure Site RecoveryのオンプレミスとAzure間の保護は、災害対策としてではなく、オンプレミスのHyper-V仮想マシンをAzure仮想マシンに移行する目的で利用することもできるようです。仮想マシンのAzureへのレプリケーションが完了し、フェイルオーバーしたら、フェイルバックせずに仮想マシンの保護を無効化します(画面12)。すると、フェイルオーバー後のAzure仮想マシンは、Azure Site Recoveryの管理から外れた状態でそのまま残ります(画面13)。この残ったAzure仮想マシンは、通常のAzure仮想マシンとして利用できます。

画面12
画面12 仮想マシンをAzureにフェイルオーバーしたら仮想マシンの保護を無効化する
画面13
画面13 Azure Site Recoveryで仮想マシンの保護を無効にすると、Azure側にフェイルオーバーされた仮想マシンはそのまま残る。この方法でオンプレミスのHyper-V仮想マシンをAzureに移行することができる

 Azureへの移行についてはこの他、InMage Scoutの機能を利用してヘテロジニアスな環境の仮想マシンや物理サーバーをAzure仮想マシンに移行できる「Microsoft Migration Accelerator for Azure」の限定プレビューが始まりました。

 Microsoft Migration Accelerator for Azureは、マルチテナントのポータルであり、オンプレミスおよびMicrosoft Azure仮想マシン環境にセットアップしたInMage Scoutのコンポーネントと連携して動作します(図5)。この移行方法は、Azure Site Recoveryのサービスとは別に動作するもののようです。

図5
図5 Microsoft Migration Accelerator Previewの利用イメージ。VMware仮想マシン、物理サーバー、Hyper-V仮想マシン、Amazon Web Services(AWS)インスタンスのAzureへの移行に対応(クリックで拡大します)

筆者紹介

山市 良(やまいち りょう)

岩手県花巻市在住。Microsoft MVP:Hyper-V(Oct 2008 - Sep 2014)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る