今すぐ始める Hyper-Vレプリカ活用術：【徹底解説】Windows Server 2012 R2（3）（1/2 ページ）

Windows Server 2012 R2には「Hyper-Vレプリカ」という機能が標準搭載されている。ほとんどの方は、DR（Disaster Recovery：災害復旧）対策用の機能と認識しているのではないだろうか。確かに、DR対策として非常に有効な機能だが、まったく別の用途もあるのだ。

[阿部直樹，エディフィストラーニング株式会社]

　Hyper-VレプリカはWindows Server 2012から実装されたHyper-Vの機能で、DR対策としての使用が想定されていた。しかし、それ以外の用途をマイクロソフトが認識したことで、Windows Server 2012 R2では機能が拡張されている。まずは、本題であるDR対策としてのHyper-Vレプリカを見ていこう。そうすれば、おのずと別の用途が分かってくるだろう。

DR対策としてのHyper-Vレプリカ

　DR（Disaster Recovery）は災害などによる被害からのシステムの回復措置、あるいは被害を最小限に抑えるための予防措置のことである。これにはさまざまな手法があるのだが、Windows Server 2012 R2のHyper-Vレプリカでは“地理的に離れた場所にデータのコピーを置く”ことになる。Hyper-Vレプリカが提供するDR機能は、仮想マシン単位で異なるサイトにレプリカを設定し、手動でフェールオーバーするものだ。

図1：Hyper-Vレプリカの概要

　Hyper-Vレプリカでは、本番稼働のサイトを「プライマリサイト」、そのサイト上のサーバーを「プライマリサーバー」と呼ぶ。そして、プライマリサイトの代替サイトを「レプリカサイト」、そのレプリカサイト上のサーバーを「レプリカサーバー」と呼ぶ。Hyper-Vレプリカでは、プライマリサーバー上の仮想マシンを丸ごとレプリカサーバーにコピーして冗長性を確保する。

　これにより、プライマリサイトで何らかの障害が発生しても、レプリカサイトにあるプライマリサーバーから複製した仮想マシンを起動する（フェールオーバーする）ことで素早くシステムを復旧することができる。DR対策としてはこれで十分と思われるが、さらにWindows Server 2012 R2では“レプリカのレプリカ”を構成できるようになった。

専用のハードウェア、ネットワークは不要

　Hyper-Vレプリカでは専用の通信経路や特別なハードウェアを用意することなく、仮想マシンのレプリケーションが可能だ。また、クラスターシステムのようにプライマリサイトとレプリカサイトのサーバーを同一のハードウェアにする必要もない。さらに、ドメイン環境すらも必須ではない。

　以上のことから、Hyper-Vレプリカは非常に柔軟な構成を採ることが可能であり、Hyper-Vの仮想化環境さえ構築できればほとんどの環境で利用することができる。

　Hyper-Vレプリカではプライマリサーバー上の仮想マシンはオンライン状態でレプリカサーバーにレプリケーションされ、レプリカサーバー上の仮想マシンはオフライン状態で常に最新の状態にアップデートされる。

サーバーの認証はKerberosまたは証明書で

　ドメイン環境でHyper-Vレプリカを使用する場合は、Active DirectoryのKerberos認証によるHTTP（Hypertext Transfer Protocol）通信が標準構成となる。HTTPの通信なので、トラフィックは暗号化されずにネットワーク上に流れる。

　一方、ワークグループ環境では、証明書ベースの認証をHTTPS（Hypertext Transfer Protocol Secure）で通信を行う。ただし、プライマリサーバーとレプリカサーバーでお互いのFQDN（Fully Qualified Domain Name：完全修飾ドメイン名）の名前解決ができることが前提だ。HTTPSの通信なので、ネットワーク上を流れるデータは暗号化される。盗聴の危険があるネットワークでは必須の認証方法になる。なお、証明書ベースの認証はドメイン環境でも利用可能だ。

　ここで忘れてはいけないのが、認証方法に準じたファイアウォールの受信許可設定だ。適切なファイアウォール設定を行わないと、Hyper-Vレプリカの通信が失敗するので注意してほしい。

Kerberos（HTTP）	証明書（HTTPS）
Hyper-Vレプリカ HTTPリスナー（TCP受信）	Hyper-Vレプリカ HTTPSリスナー（TCP受信）

表1：認証方法とファイアウォール設定の関係

初期と差分、2つのレプリケーション方法

　Hyper-Vレプリカでは仮想マシンをプライマリサーバーからレプリカサーバーへコピー（レプリケーション）することで、冗長性を確保していることは先に述べた通りだが、このレプリケーションには次の2種類がある。

図2：初期レプリケーションの設定画面

• 初期レプリケーション

　Hyper-Vレプリカの構成後、最初に行うレプリケーション。プライマリサイトからレプリカサイトに仮想マシン全体をコピーする。

　初期レプリケーションにはネットワーク経由と、外部媒体を使用してオフラインで行う2つの方法がある。実際の環境では、外部メディアに初期レプリケーションをコピーしてレプリカサイトに配置することになるだろう。仮想マシンは数GB単位の容量になるので、それをWAN回線経由でレプリケーションするにはネットワーク帯域に余裕がないと厳しいからだ。十分な帯域を確保できるのであれば、ネットワーク経由でも問題はない。しかし、その際も深夜などなるべくネットワークが利用されていない時間帯でレプリケーションを行うべきだろう。

• 差分レプリケーション

　初期レプリケーション完了後に実行されるレプリケーションで、仮想マシンの差分データを一定の間隔でレプリカサイトに転送する。Windows Server 2012 R2では、この間隔を「30秒」「5分」「15分」から選択できるようになった。

図3：レプリケーションの頻度の構成

　レプリカサーバー上にある仮想マシンのレプリケーションデータの保存を「回復ポイント」と呼び、デフォルトは常に最新の回復ポイントを保存する「最新の回復ポイントだけを保持する」に設定されている。しかし、この設定では過去のデータは保持されずに、スナップショットは「標準レプリカ」として動作する。

図4：「追加の回復ポイントの構成」画面

　「追加の回復ポイントの構成」画面で「追加の時間単位の回復ポイントを作成する」を選択すると、レプリケーションされた仮想マシンの履歴を保持するようになり、1時間に1回レプリケーションデータを履歴として保存できるようになる。これはレプリカサイト側の仮想マシンのスナップショット機能を利用しており、最大で24世代分の履歴を保持することができる。

　スナップショットの保存方法は2種類あり、デフォルトでは「標準レプリカ」が使用される。標準レプリカの特徴としては、プライマリ仮想マシンのクラッシュコンシステントレプリカ^（＊）であるということだ。

（＊）クラッシュコンシステント：変更を保存していない状態や開いているファイルを回復できない状態のこと

　もう1つの保存方法は「アプリケーションと整合性のあるレプリカ」で、「ボリュームシャドウコピーサービス（VSS）スナップショットの頻度（時間）」をチェックすることで設定可能だ。これは仮想マシン上のアプリケーションがVSSに対応していれば、アプリケーションの整合性を保持できるレプリカとなる。例えば、4時間ごとに設定した場合、1時間ごとに「標準レプリカ」が、4時間目に「アプリケーションと整合性のあるレプリカ」がそれぞれ保存され、以後それが繰り返される。

仮想マシンのIPアドレスに注意

　サイトが異なればIPネットワークアドレスも異なる。従って、レプリカサーバーを使用する際には、プライマリサーバーのIPアドレスがそのまま使用された状態で起動しても通信ができない。そこで、Hyper-Vレプリカではフェールオーバー時のTCP/IP設定を行うことで、レプリカサーバー上で起動する仮想マシンのIPアドレス設定を変更することができる。

図5：フェールオーバーのTCP/IPの構成画面

　図5の画面はHyper-Vレプリカを構成した仮想マシンだけに表示され、レプリカサーバー上の仮想マシンが起動する際は、ここで指定したIPアドレスに変更された状態で起動するようになる。ちなみに、レガシーネットワークアダプターを使用した場合は「フェールオーバーのTCP/IP」の設定画面は表示されないので注意が必要だ。