Hyper-V 3.0 で Hyper-V レプリカを構成する準備

Windows Server 2012 の Hyper-V 3.0 で提供された、Hyper-V レプリカを構成してみる。

Micorosoft が提供する便利そうな機能は、ほとんどが Active Directory が必須だ。
たとえば、以前から提供されている Hyper-V のライブ マイグレーションなどは、移行元、移行先両方の Hyper-V ホストが Active Directory ドメインに参加することが必須条件になっている。
Hyper-V 3.0 で提供されたライブ マイグレーションの機能のひとつである、記憶域 (つまりは、仮想ハードディスクやスナップショットのイメージ、仮想マシンの設定ファイル) を同じ Hyper-V ホストの別のフォルダーに移動するストレージ ライブ マイグレーションは、Active Directory ドメインだろうと、ワークグループだろうと関係なく行えるが、この機能は単一の Hyper-V ホスト内のファイル移動であり、認証を使わないために Active Directory を必要としないだけと考えられる。

しかし、この Hyper-V レプリカは、レプリカ元とレプリカ先のふたつの Hyper-V ホストが存在する機能にも関わらず、ワークグループ環境のままで構成できる。
それは Hyper-V レプリカの認証機構が、Active Directory の他に電子証明書も使えるようになっているためだ。
このため、ワークグループ環境で Hyper-V レプリカを運用する場合のレプリケーションの通信路は HTTPS に限定される。
レプリカ元とレプリカ先の Hyper-V ホストが、両方共 Active Directory ドメインに参加しているときは電子証明書を使わなくてもいいため、レプリカの通信路を HTTP にもできる。
もちろん電子証明書による認証も併用して HTTPS にすることもできる。

前置きはここまでにして、ここではワークグループ環境で Hyper-V レプリカを構築する前準備として、認証に使う電子証明書を作成しよう。
また合わせて、レプリカ元とレプリカ先の通信を阻害しないように、Windows ファイアーウォールを調整しておくことにする。
なお、ワークグループ環境で Hyper−V レプリカを構成するときは、レプリカ元とレプリカ先で互いの FQDN の名前解決ができることが前提だ。

Hyper-V レプリカで使う電子証明書には、クライアント証明書とサーバー証明書の二種類が必要だ。
レプリカ元にクライアント証明書をレプリカ先にはサーバー証明書をインストールして使用する。

レプリケーションした仮想マシンをレプリカ先で起動することを「フェールオーバー」と呼ぶが、その内の「計画的フェールオーバー」を行うと、それまでレプリカ元からレプリカ先へのレプリケーションが、逆方向のレプリカ先からレプリカ元に切り替わる使用になっている。
つまり、Hyper-V レプリカをより効果的に使うには、レプリカ元とレプリカ先の区別無しに、どちらからでもレプリケーションできるようにしておくのが望ましい。
このため、レプリカ元とレプリカ先の両方それぞれに、クライント証明書とサーバー証明書を用意しておく。

なお、クライアント証明書とサーバー証明書は、1 枚の証明書の両者を統合できる。
本来であればこの証明書は、公開されている商用認証機関か、自組織内の正規の認証機関で発行すべきだが、ここでは簡易的に自己署名証明書 (俗にいう「オレオレ証明書」) を使うことにする。

自己署名証明書と言っても実は、公開されている商用認証機関に認証されていない自組織内の認証機関と信頼性に変わりはない。証明書の失効管理の有無に違いがあるくらいだろう。

自己署名証明書を発行する証明機関は、証明機関になれる機器であればなんでもいい。
電子証明書は、証明書を発行した証明機関の証明書 (ルート証明書) がなければ意味を成さないため、作成したクライント証明書とサーバー証明書に加えて、それらの証明書を発行したときのルート証明書も一緒にして用意しなくてはならない。

今回は手軽に、レプリカ元とレプリカ先のそれぞれを認証機関にして、それぞれで自身に対するサーバー証明とクライント証明の両者を併せ持つ自己署名証明書を 1 枚ずつ発行することにする。

レプリカ元とレプリカ先の OS はどちらも Windows Server 2012 (または Hyper-V Server 2012) なので、自己署名証明書の発行には makecert.exe を使う。
しかしながら、macecerte.exe は Windows Server 2012 に標準では含まれていない。
Microsoft の開発環境である Virsual Studio に付属しているらしいが、とても手に入れられない。
Windows Platform SDK に含まれているとか .Net Framework SDK に含まれているとか、どうにも情報が交錯している。
色々と探し回って試した結果、「Windows 8 用 Windows ソフトウェア開発キット (SDK)」の Web ページから Windows SDK for Windows 8 をダウンロードしてインストールすればいいという事がわかった。

Windows SDK for Windows 8 からダウンロードした sdksetup.exe は複数の SDK のインストーラーをまとめたもので、実行するとインストール先フォルダー、カスタマー エクスペリエンス向上プログラムの参加、ライセンスの承認の後に、インストールする SDK を選択する画面が表示される。

SDK をインストールするフォルダーを選ぶ
カスタマー エクスペリエンス向上プログラム
ライセンス承認
「Windows Software Development Kit」を選んで「Install」する

インストールした中で実際に使うのは、Windows Software Development Kit の中の makecert.exe ただひとつだけだ。
具体的には "C:Program Files (x86)Windows Kits8.0binx64" フォルダーの makecert.exe だけでいい。
別の Windows PC に Windows Software Development Kit をインストールして、そこから makecert.exe だけをコピーして使ってもいいだろう。

筆者は何も考えずに、レプリカ元とレプリカ先の両方に Windows Software Development Kit をインストールしたので、以下では "C:Program Files (x86)Windows Kits8.0binx64makecert.exe" を直接使っている。

まずはレプリカ元の Hyper-V ホストで以下の手順を行う。

最初に mkdir "C:UsersPublicDocumentscerts" コマンドを実行して、これから作成する証明書ファイルを保存するフォルダーを用意する。
次に、管理者権限を持ったコマンド プロンプトで以下のコマンドを実行して、自己署名をするためのルート証明書を作成する。
環境変数 CA にセットした値がこのルート証明書の名称になる。
どんな名前でもいいが、次に作成するレプリカ先のルート証明書と異なる名前にしておかないと区別できなくなってしまう。
ここでは SelfSignedRootCA-Primary としてみた。

これでルート証明書がレプリカ元の証明書ストアに保存され、その公開鍵が C:UsersPublicDocumentscerts フォルダーの SelfSignedRootCA-Primary.cer ファイルに保存される。
C:UsersPublicDocumentscerts フォルダーに保存された SelfSignedRootCA-Primary.cer ファイルは後ほど、レプリカ先の Hyper-V ホストにコピーして使用する。

続いて、管理者権限を持ったコマンド プロンプトで以下のコマンドを実行して、先ほど作成したルート証明書で署名されたサーバー証明とクライアント証明を持つ証明書を作成する。
先ほど作成したルート証明書を指定するために、環境変数 CA には先の手順と同じ値をセットする。
環境変数 FQDN にはサーバー証明とクライアント証明の対象になるレプリカ元の Hyper-V ホスト、つまり自分自身の FQDN をセットする。
ここでは primary.hyper-v.local をこの Hyper-V ホストの FQDN とした。

これで replicat.hyper-v.local という FQDN のホストに関するサーバー証明とクライアント証明を持つ証明書が、証明書ストアに保存される。

上の二組の処理は、以下のようにまとめて実行できる。

作成したルート証明書と、サーバー証明・クライアント証明を持つ証明書を確認するには MMC (Microsoft Management Colsole) を使う。
証明書の MMC は標準では用意されていないので、MMC を単独で立ち上げてスナップインを追加することになる。
具体的な手順は、まず mmc.exe を実行し「ファイル」メニューから「スナップインの追加と削除」を選択、実行して、「スナップインの追加と削除」ダイアログを表示する。
「スナップインの追加と削除」ダイアログの左側にある「利用できるスナップイン」リストの一番下にある「証明書」を選択して「追加」ボタンをクリックすると、「証明書スナップイン」の設定ウィザードが表示される。

スナップインの追加と削除で「証明書」を追加する

「証明書スナップイン」の設定ウィザードの「このスナップインで管理する証明書」では [コンピューター アカウント] にチェックを入れて「次へ」ボタンをクリックする。
作成したふたつの証明書はどちらもコンピューター アカウントの証明書ストアに保存されているので、それを確認するのはここで [コンピューター アカウント] にチェックを入れなければならない。

この証明書スナップインで管理する証明書の種類として「コンピューター アカウント」を選択して「次へ」進む
この証明書スナップインが接続するコンピューターを選択して、スナップインの設定を「完了」する

「証明書スナップイン」の設定ウィザードで次に表示される「このスナップインで管理するコンピューター」では [ローカル コンピューター (このコンソールを実行しているコンピューター)] にチェックを入れて「完了」ボタンをクリックする。
ここでももちろん、[ローカル コンピューター] にチェックを入れなければ意味が無い。

証明書スナップインを追加して「完了」する

「証明書スナップイン」の設定ウィザードが閉じ「スナップインの追加と削除」ダイアログに戻ったら、「OK」ボタンをクリックする。
これで証明書ストアを管理する MMC の用意ができた。

この証明書 MMC で、先ほど作成したルート証明書を確認するには、左側ペインのツリーを [コンソール ルート - 証明書 – 信頼されたルート証明機関 - 証明書] と辿り、サーバー証明とクライアント証明を持つ証明書を確認するには [コンソール ルート - 証明書 – 個人 - 証明書] と辿る。

信頼されたルート証明機関
個人証明書

ここで、先ほど C:UsersPublicDocumentscerts フォルダーに作成した SelfSignedRootCA-Primary.cer ファイルを、レプリカ先の Hyper-V ホストの C:UsersPublicDocumentscerts フォルダーにコピーする。
コピー先のフォルダーは別にどこでもいいのだが、今までの作業手順に合わせてみた。

レプリカ先の Hyper-V ホストの C:UsersPublicDocumentscerts フォルダーに、レプリカ元で作成した SelfSignedRootCA-Primary.cer ファイルをコピーしたら、それを証明書ストアに保存する。
そのためにはレプリカ先の Hyper-V ホストの管理者権限を持ったコマンド プロンプトで以下のコマンドを実行する。

証明書ストアに保存されたことを確認するには、レプリカ元の Hyper-V ホストでやったのと同様に証明書 MMC を使う。

Hyper-V レプリカの相手側で作成したルート証明書を追加した「信頼されたルート証明機関」

レプリカ元の Hyper-V ホストで確認したのとアイコンが異なっているはずだ。
これは、レプリカ元のルート証明書には公開鍵と秘密鍵が一緒に保存されているが、レプリカ先では公開鍵だけしか保存されていないためだ。

これでレプリカ元の証明書の準備が整った。
次はレプリカ先の証明書を作成する。

レプリカ先の Hyper-V ホストでも、やることは基本的にレプリカ元と同じだ。
レプリカ先で使用するルート証明書を作成し、それを使ってサーバー証明とクライアント証明を持つ証明書を作成する。
そして、ルート証明書の公開鍵のファイルを、レプリカ元の Hyper-V ホストにコピーして証明書ストアに保存すればいい。

具体的手順は以下のとおりだ。
まず、レプリカ先の Hyper-V ホストの管理者権限を持ったコマンド プロンプトで以下のコマンドを実行する。

C:UsersPublicDocumentscerts フォルダーに作成された SelfsignedRootCA-Replica.cer ファイルを、レプリカ元の Hyper-V ホストの C:UsersPublicDocumentscerts フォルダーにコピーし、レプリカ元の Hyper-V ホストの管理者権限を持ったコマンド プロンプトで以下のコマンドを実行する。

さらに、自己署名証明書は証明書の失効確認が使えないということなので、レジストリを修正して失効確認しないようしておく。
それにはレジストリ エディターを起動して当該箇所を修正するか、管理者権限を持ったコマンド プロンプトで以下のコマンドを実行する。

レジストリの修正も、レプリカ元とレプリカ先の両方で実施する。

以上で、Hyper-V レプリカで使用する電子証明書の準備が整った。

最後にレプリカ元とレプリカ先の通信を阻害しないように、Windows ファイアウォールを調整する。
レプリカ元からレプリカ先への通信には HTTPS が使われるので、これを許可することになる。
Windows ファイアウォールにはこれに関する定義が標準で用意されているので、作業としてはこれを有効にするだけだ。

具体的には、コントロールパネルから「セキュリティが強化された Windows ファイアウォール」を開き、左側のペインのツリーを [ローカル コンピューターのセキュリティが強化された Windows ファイアウォール - 受信の規則] と辿る。
真ん中のペインに表示される「受信の規則」の一覧から「Hyper-V レプリカ HTTPS リスナー (TCP 受信)」を右クリックして表示されるコンテキスト メニューから「規則の有効化」をクリックする。

Windows ファイアウォールで「Hyper-V レプリカ HTTPS リスナー (TCP 受信)」の受信規則を有効にする

受信規則はレプリカ先の Hyper-V ホストでだけ有効にすればいいのだが、Hyper-V レプリカを効果的に使うためにレプリカ元の規則も有効にする。

なお、「セキュリティが強化された Windows ファイアウォール」で「Hyper-V レプリカ HTTPS リスナー (TCP 受信)」の受信規則を有効にするときに、すぐ上にある「Hyper-V レプリカ HTTP リスナー (TCP 受信)」と間違えないようにする。
「Hyper-V レプリカ HTTP リスナー (TCP 受信)」は、Active Directory 環境で HTTPS を使わずにレプリケーションするときの項目だ。

関連記事

「Hyper-V 3.0 で Hyper-V レプリカを構成する準備」への3件のフィードバック

  1. おかげさまで、ワークグループ環境でなんとかレプリケーションできました。
    DNSの解決は、ベタにHOSTSファイルへのIPアドレスとFQDN記述で対応しました。
    認証の方法は当初まるでちんぷんかんぷんでしたので、この記事なくしては設定を完遂することは不可能でした。
    ありがとうございます。

  2. 有用な情報をありがとうございます。
    このサイトを参考にしてWorkgroup環境でHyper-Vレプリカの構成を進めておりますが、Hyper-Vへの証明書登録でエラーが出ており、先に進めておりません。
    エラー内容としては証明書失効確認が行えないという内容となります。
    レジストリの失効確認無効化はレジストリを変更して対応しております。

    山口様の書込みではDNSの解決が必要との事ですが、Workgroup環境でも必ずサフィックスをつける必要があるのでしょうか。
    お分かりになられる方がいらっしゃいましたらご教授いただけると幸いです。

    突然の書込にて失礼を致しました。

    1. 証明する対象のサーバー名は FQDN でなくてはならないはずです (確証はないけど。) つまり、証明書MakeCert コマンドで証明書を作成するときの -n オプションで指定するコンピューター名はサフィックスを付けて FQDN にします。

コメントを残す