厳選ブログ転載

Active Directoryドメイン・コントローラ(AD)の仮想化はNG?

Microsoft MVP for Virtual Machine
日本ヒューレット・パッカード株式会社
小川 大地(http://d.hatena.ne.jp/ogawad/
2012/05/31

「厳選ブログ転載」シリーズでは、インターネット上の膨大なブログ・コンテンツの中から、特にWindows Server Insiderの読者に有用だと考えられるブログ記事を編集部が厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、Windowsシステム/ネットワーク・エンジニアのブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。

本稿は、2010年11月に公開された次のブログ記事「Active Directory ドメインコントローラ (AD) の仮想化は NG?」および2011年12月公開の「なぜゲストの時刻はずれるのか? - Active Directory 仮想化 (2) 」に簡単な校正・加筆を行ったうえで転載したものです。

 Windowsシステムの仮想化を設計・構築した経験のある人なら、一度はActive Directoryドメイン・コントローラ(AD)の仮想化を思いつくでしょう。もしかしたら、調べたこともあるかもしれません。

 現行のサーバ・マシンから見れば、Active Directoryなんて軽すぎるサービスです。ADのためだけに最新サーバを与えるなんてオーバースペックすぎてもったいないので、仮想化したくなると思います。

 そこで本稿では、まずADの仮想化の可否や注意点などを解説します。さらにAD仮想化の問題点について、筆者の専門であるハードウェアの視点から技術論を綴ってみたいと思います。なお、原則としてWindows Server 2008 R2以前のWindows OSによるADを対象としています(Windows Server 2012については本稿の最後で簡単に説明します)。

Active Directoryドメイン・コントローラの仮想化の現状

 マイクロソフトはドメイン・コントローラの仮想化をサポートしています。しかし、同時にかなりいろいろと制約や注意事項を掲げています。

 この2つの資料は煙に巻いた感じで、核心がよく分からないかもしれません。

 マイクロソフトの見解としては、同社のWindows Serverプリセールス・エンジニア・チームのブログにもう少し明確に書かれています。

設計/構築時の考慮

  • 最低1台の物理ドメイン・コントローラを確保する
  • Hyper-V 統合サービスの時刻同期機能をオフにする
  • 仮想ディスクには、差分ディスクは利用しない

運用時の考慮

  • ドメイン・コントローラを長い期間、保存・停止状態にしない
  • スナップショット機能は使わない
  • バックアップ/リストアは物理環境と同じ

上記ブログ記事より引用)

最低1台は仮想化せずにベアメタルでドメイン・コントローラを構成する

 なぜ「最低1台」かというと、下記の役割を持つサーバは、仮想化しない方がよいからです。

  • グローバル・カタログ
  • FSMOの一部
  • DNSサーバ

 理由はいくつかありますが、分かりやすいのが「仮想化するとどうしても時間が遅れてしまうため」です。これはタイムスライスのアーキテクチャ上、どうしようもありません(数分単位でNTP同期しない限り)。その理由は後で説明します。

 これに対して、上記3つの役割はADの中核技術であり、「時間のずれ」は認証機構をはじめADのさまざまな場所でトラブルを引き起こします。

 特にVDIのような、ユーザー認証を多用するシステムではご注意ください。

 「認証周りがおかしい」「ログインできない」などの現象は、VDI製品が原因ではなく、検証環境だからといってADを仮想化して立てていたことが原因だったケースを結構耳にします。

2台目以降のADの仮想化

 2台目以降のDCの仮想化については下記の記事やドキュメントがよくまとまっていますので、ガイドラインにするとよいと思います。

そもそも、仮想化するとなぜ時間がずれてしまうのか?

 どの資料もNGの理由として「仮想化すると時刻がずれるから」とは書いてあるのですが、ずれる理由について触れている文献はなかなかないようです。ここはどうも注目を浴びているようですので、理由の1つを分かりやすく書き残しておきたいと思います。

 プロセッサ・コアを4個搭載しているサーバ上で、vCPU(仮想CPU)を1個ずつ割り当てた仮想マシンをイメージしてみてください。

 仮想マシンを4個動かす場合、各々がプロセッサ・コアを占有することができます(ハイパーバイザのCPU消費はひとまず無視してください)。

vCPUに物理CPUコアが一対一で割り当てられている状態

 次に、vCPUがオーバーコミット状態の場合について考えてみます。「オーバーコミット」とは、実際のコア搭載数よりvCPUの割り当て総数の方が多い状態を指します。

 VMware vSphere(以下vSphere)もHyper-VもvCPUはオーバーコミット設定ができますが、あるクロックの瞬間、コアは1つの処理しかこなせません。すべての仮想マシンを同時処理できないため、ハイパーバイザは仮想マシンを強制的にフリーズ(いわゆるプチフリ)させます。

vCPUが物理CPUコアより多いために仮想マシンの強制フリーズが行われた状態

 フリーズしすぎると問題があるため、一定時間が経つとフリーズ対象を切り替えます。開発経験のある方は「コンテキスト・スイッチ」をイメージすると分かりやすいはずです。

強制フリーズされる仮想マシンが切り替えられた状態

 これをタイムラインに表すと、次のようになります。

各仮想マシンの稼働状況のタイムライン

 上図を拡大してみます。仮想マシンは自分が気づかないうちに強制フリーズさせられていたので、ゲストの時刻が実時刻から遅れてしまいました。

強制フリーズによって仮想マシンの時刻が遅れた状態

 実際のタイムスライスはコンマmsec以下ですが、延々と繰り返されるために、ゲストの時刻は「塵も積もれば……」的にどんどんずれていってしまうのです。

 「vCPUをオーバーコミットさせなければよい」と感じるかもしれません。しかし、実際にはハイパーバイザのCPU消費や、特権モード(Ring 0)の割り込み要求も発生するため、vCPUをオーバーコミットしていなくても時間はずれていきます。

 逆に、vCPUをオーバーコミットさせすぎると、時刻がずれやすくなるうえ、処理コアがコロコロ変わるためにプロセッサ・キャッシュが使われづらくなります。非効率なので要注意です。

Hyper-VとvSphereのCPUスケジューリングの違い

 CPUスケジューリングについては、Hyper-VとvSphereで動作が異なります。

 Hyper-Vは意外にも処理コアの切り替えが非常に高速です。普段から積極的に切り替える動きを採るくらいで、オーバーコミット状態でもロスが少ない特性があります。

 これに対し、vSphereはできる限り切り替えを避けてプロセッサ・キャッシュを活かす動きを採ります。

 Hyper-VとvSphereでこうしたスケジューリングの違いはありますが、性能を重視する場合、どちらもvCPUのオーバーコミットはできれば避けた方がよいです(ハードウェアの専門家としての個人見解)。

 Windows Server 2012からは、ある技術に対応するハイパーバイザであればADの仮想化がサポートされるそうです。詳細は筆者が記した次のブログ記事を参照してください。End of Article

 「厳選ブログ転載」


Windows Server Insider フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間