毎月のようにサービス内容が拡充されるAzureにおいて、代表的なサービスであるのが「仮想マシン」だ。仮想マシンは、IaaSレイヤーに該当するインフラストラクチャを時間単位で利用できるサービスである。ユーザーにはOSより上位層のシステムを操作する権限が与えられ、オンプレミスのサーバと同様に、自由にOSの設定やミドルウェア、アプリケーションのインストールができるという、非常にイメージしやすいサービスだ。

　Azureの仮想マシンは、Hyper-Vの仮想マシンとして動作している。サービス名がずばり「仮想マシン」のため紛らわしいが、Azureの仮想マシンサービスのハイパーバイザーは、「VMware ESX／ESXi」でも「Xen」でもなくHyper-Vであり、その上で動作しているゲストOSとしての仮想マシンを時間単位で利用する姿を想像すると分かりやすい。

　ただしAzureの仮想マシンを利用しているときに、ユーザーがHyper-V側の動作を意識する必要はほとんどない。その管理はクラウドサービスベンダーであるMicrosoftが行う。ユーザーは、ハイパーバイザー以下のシステムを意識せずに利用できる。

　Hyper-Vの仮想マシンのイメージは「.vhd」というファイル形式で保存される。Azureの仮想マシンも同様に.vhdファイル形式で保存される（.vhdxファイルには未対応）。つまり、オンプレミスで動作させているHyper-V環境とAzure環境とでハイパーバイザーが共通のため、この2つの環境で仮想マシンのイメージを相互に移行することが可能になっている。実際の作業は、前回の記事（Hyper-Vだけじゃない、統合管理ツール「System Center Virtual Machine Manager」のカバー能力）で紹介した「System Center Virtual Machine Manager」（SCVMM）の機能、もしくはAzureのSDKに同梱されているPowerShellコマンドなどを用いて移行する（ライブマイグレーションは未対応）。

　「.vmdk」などの他の仮想マシンイメージ形式のファイルでも.vhd形式に変換すればAzureへの移行は可能であるが、Hyper-Vで動作している仮想マシンに関しては、極めてシームレスに移行が可能でありポータビリティが確保されている。例えば、あなたがHyper-Vを使って構築したプライベートクラウド環境とAzure環境を両方管理しているのであれば、仮想マシンに関してはこの環境間を自在に移行できる。また、両環境の管理を1つのSystem Centerを通じて透過的に行うことも可能だ。複数のプラットフォームを一貫して管理することができるのが、Microsoftが掲げるCloud OSビジョンである。

復旧サービス「Azure Site Recovery」、3つの利用シナリオ

　Hyper-Vに関連するAzureのサービスに、事業継続計画／災害復旧（BCP／DR）対策に効果的なサービス「Azure Site Recovery」（ASR）がある。

ASRの管理に用いるAzure管理ポータルの「復旧サービス」画面《クリックで拡大》

　ASRは、オンプレミスのHyper-V上で動作する仮想マシンのレプリカを、異なる別のオンプレミスのサイトまたはAzure上に構築するソリューションだ。通常システムを稼働させているプライマリサイトが有事の際に、コミュニケーションチャネルを通じてプライマリサイトからセカンダリサイトまたはAzure上へ自動あるいは手動でフェイルオーバーさせてシステムを継続することができる。普段からレプリケーションチャネルを通じてデータを同期しているからこそ実現できる対策である。ASRのテクノロジーは、本連載の第3回（手軽に始められる、Hyper-Vの「BCP／DR対策」「無停止運用」機能）で解説したHyper-Vレプリカの機能をベースとしている。

図1　ASRの概要

　ARSには、（1）「2つの内部設置型Hyper-Vサイトの間」、（2）「内部設置型Hyper-VとMicrosoft Azureとの間」、（3）「2つの内部設置型VMwareサイトの間」という3つの利用シナリオがあり、いずれかを選択して利用を開始する（ここでの内部設置という言葉は、オンプレミスという言葉を指している）。

利用シナリオ（1）2つの内部設置型Hyper-Vサイトの間

　SCVMMで管理される2つのオンプレミスのサイト間で、仮想マシンのレプリケーションを構成する。有事の際には、ワンクリックでプライマリサイトからセカンダリサイトにフェイルオーバーすることができる。ワンクリックというシンプルなアクションでフェイルオーバーに関する一連の処理を実行するため、あらかじめ復旧計画という定義を作成し、対象となるSCVMMサーバやオンプレミスサーバとの依存関係を考慮し、仮想マシン群の起動の順番などを定義することができる。

図2　利用シナリオ（1）2つの内部設置型Hyper-Vサイトの間

利用シナリオ（2）内部設置型Hyper-VサイトとMicrosoft Azureの間

　SCVMMで管理されるオンプレミスのサイトと、Azureの仮想マシンとでレプリケーションを構成する。（1）の利用シナリオと同様、復旧計画を定義しておくことができる。特徴は、セカンダリサイトがAzure上のためハードウェアが不要であること、平常時はデータの同期のみでAzure上の仮想マシン自体は起動しておらず、フェイルオーバー後に初めて起動するというコールドスタンバイである。Azureの課金に無駄がなく、リーズナブルにフェイルオーバーを実現できる。これぞASRの真骨頂を発揮する利用シナリオである。

図3　利用シナリオ2：内部設置型Hyper-VサイトとMicrosoft Azureの間

利用シナリオ（3）2つの内部設置型VMwareサイトの間

　VMware環境および物理サーバを対象とした利用シナリオになる。VMware環境で構成された2つのプライベートクラウド間や、WindowsまたはLinuxが稼働する物理サーバとVMware環境間のレプリケーションが可能となる。なぜMicrosoftがVMware環境を扱うのかという問いは至極当然の疑問である。これは、VMware環境を含むヘテロジニアス（異種混合）な環境を対象とするDRやバックアップのソリューションを持っていたInMageという企業をMicrosoftが買収し、それをASRの機能として取り込んだからだ。このように、Azureでは多くの利用シーンでDRやバックアップを実現できる。

図4　利用シナリオ3：2つの内部設置型VMwareサイト間

　以上、各自の環境に適した利用シナリオでASRを活用することで、オンプレミスだけでなくクラウドを活用したBCP／DR対策ができることを説明してきた。

　既に世の中はクラウド時代に本格的に突入している。Hyper-Vによる仮想化の先には必ずAzureがある。このことを念頭に置くことで、先々まで見通したIT投資計画を立てていただきたい。

　さて、今回で本連載は最終回となる。Microsoftの仮想化の歴史、Hyper-Vを活用した移行、Hyper-Vの先進的な機能やその活用方法、Cloud OSビジョンに基づくSystem CenterやAzureの機能といった解説を終える。

　Hyper-Vはテクノロジーとして確立されており、既に多くの実績がある。またHyper-VをベースとしたクラウドサービスのAzureも、かなりの勢いで活用が進んでいる。Windows Server 2003を活用しているユーザーの皆さんには、2015年7月にサポートが終了することをいま一度念頭に置いて、これまで紹介した機能や活用方法を十分に活用してほしいと願う次第である。

田中 隆三郎（たなか りゅうさぶろう）

日本マイクロソフト インキュベーションセールス部 テクノロジースペシャリスト

現在の担当はMicrosoft Azureのプリセールス。

ソフトウェアディベロッパーとして数社で開発業務に従事した後、SIer企業にてSAPアップグレード業務や、AWSやGoogleなどのパブリッククラウドを活用した事業推進に従事。2013年より現職に就く。現在の関心事は、クラウドのテクノロジーとそれを取り巻く業界全般。

ベーシストかつスキューバダイバーで、最近の趣味は温泉とゆるキャラ。

ブログ：Heart and Soul

Twitter：@rewtheblow