Windows Server 2016のHyper-V: NATその他

Windows Server 2016のHyper-Vにはいくつかの新機能が追加されています。特に便利だと思った機能を紹介します。

Nested Hyper-V

Hyper-V仮想マシン上でHyper-Vが動作します。

以下のPowerShellコマンドレットを実行して、親となる仮想マシンを設定する必要があります。

Set-VMProcessor -VMName VM1 -ExposeVirtualizationExtensions $true

ここでVM1が、Hyper-Vを起動する仮想マシン(Nested Hyper-V)の名前です。

物理マシンリソースを使い込まないように制限

Hyper-Vはそのままでも物理マシンのリソースを使い切ったりはしないと聞いていますが、明示的に物理マシンのリソースを保護する機能が追加されました。以下のPowerShellコマンドレットを実行してください。

Set-VMProcessor -VMName VM1 -EnableHostResourceProtection $true

ここでVM1は、リソースの使用制限をかける仮想マシンの名前です。

内部仮想スイッチをNATデバイスとして構成(WinNAT)

VMware Workstationなどではおなじみの機能です。仮想マシンに独立したプライベートネットワークを与え、物理マシンでNAT(NAPT)を有効にすることはよくあります。

Hyper-Vでは、内部仮想スイッチに対してNATを構成できます。以下のPowerShellコマンドレットを実行してください。

New-NetNat -Name mynat -InternalIPInterfaceAddressPrefix 172.16.1.0/24

ここで、172.16.1.0/24はプライベートネットワークの範囲を示します。
また、mynatはNATに対して付けられた名前です。

これで、内部ネットワークに割り当てられた物理マシンの仮想NICがルーターとなります。内部仮想スイッチに接続された仮想マシンのデフォルトゲートウェイとして指定してください。

なお、DHCPサーバーの機能は持たないため、IPアドレスの管理やDNSサーバーアドレスの設定は手動で行なうか、別途DHCPサーバーを立てる必要があります。

現時点では、インテルのプロセッサが必須で、Hyper-Vの構成バージョンは8(以上)でなければいけません。

Hyper-VまたはAzure上のドメインコントローラーでの時刻同期

以前、Hyper-V上のドメインコントローラーについて書きました(Hyper-V 仮想化環境での時刻同期)。

この時は「ドメインコントローラーについては、Hyper-Vを使ったホストとの同期を停止する」と紹介しています。根拠は、マイクロソフトの公開文書「仮想化ドメイン コントローラーの展開に関する考慮事項」です。

Microsoft Azureの仮想化基盤はHyper-Vなので、Azure上のドメインコントローラーについても同じことが言えるはずです。

しかし、Azureテクニカルサポート チームのブログ「Azure 仮想マシンの時刻同期の仕組み」では、ホスト同期を無効にする方法について触れつつも「基本的には、Azure に時刻同期を任せてしまう、という考えで、既定のままにしていただくことが便利です」とあります。

矛盾するようですが、以下のようなことではないかと想像します。

Hyper-V、つまりオンプレミス環境では複数の仮想化ホスト(物理マシン)の時刻同期がきちんと行われていない可能性があります。こうした状況でホスト同期を行うことはリスクが大きいため、ドメインコントローラー自身が持つNTP時刻同期を使う方が無難です。

しかし、Azure内にあるすべての物理マシンは時刻同期が正しく行われています。このような環境では、ホスト同期を優先した方がリスクが小さいと考えられます。

逆に言うと、すべてのHyper-Vホストが適切に時刻同期している環境であれば、ホスト同期を有効にしたままで問題ない(むしろ推奨される)と思われます。

Hyper-V仮想マシンからAzureへのフェールオーバーとフェールバック

Microsoft Azureは、オンプレミスのサーバーをAzureに複製(レプリケーション)し、必要に応じてフェールオーバー(障害時の切り替え)ができます。ただしHyper-VホストはWindows Server 2012 R2が必要です。

Windows Server 2012 R2のHyper-Vホストは以下の仮想マシンをサポートします。

• 第1世代(BIOS)および第2世代(UEFI)の仮想マシン
• VHD形式およびVHDX形式の仮想ディスク

一方、Microsoft Azureがサポートする仮想マシンは以下の通りです。

• 第1世代(BIOS)
• VHD形式の仮想ディスク

そのため、Hyper-Vの第2世代は第1世代に変換され、VHDX形式はVHD形式に変換されます。この処理は自動的に行われるため、特に作業は必要ありません。

一方、フェールバック(Azureで起動した仮想マシンをオンプレミスに戻す)時は注意が必要です。

大規模災害などで、データセンタが破損したあと、システムが復旧したとします。この場合、Azureから「フェールバック」を行うことで、元のシステムを復元できます(操作メニューは「フェールオーバー」を使います)。

オンプレミスの仮想マシン存在しなくても「オンプレミスにVMを作成する」オプションを指定すれば、自動的に復元します。

この時、Azureから戻ってきた仮想ディスクはVHD形式に変換されたままですが、容量可変ディスクに戻ります。以前の状態を覚えているのでしょうね。

ただし、フェールバック(Azureから戻す)で、Azureの(変換された)第1世代PCを(元の)第2世代に戻すことはできません。しかし、どうもAzureは第2世代に戻そうとするようです。こちらも以前の状態を覚えているようですね。

もちろんこの作業は失敗するため、第2世代の仮想マシンを戻す(フェールバックする)ことはできません)。図のエラーはそれを示しています。

本記事の内容は「Microsoft Azureによる災害復旧手法 ～Azure バックアップとAzure Site Recoveryでの仮想マシン保護～」で扱っています。

「ホスティッド・プライベート・クラウド勉強会」に行ってきました

12月17日(木)「ホスティッド・プライベート・クラウド勉強会　～Windows Azure Pack on IBM SoftLayer～」に行ってきました。

「ホステッドプライベートクラウド」は、パブリッククラウドのリソースを使ってプライベートクラウドを作る仕組みです。「仮想プライベートクラウド」とほぼ同じ意味のようですが、「ホステッド」の方は物理リソースを固定するようです。

もっとも、いずれも厳密な定義はないみたいなので、話をするときは注意してください。

さて、この勉強会、メインスピーカが、IBMの北瀬公彦さんと、マイクロソフトの高添修さんでした。

IBMはSoftLayer、マイクロソフトはMicrosoft Azureというパブリッククラウドを提供していますが、今どきのIT業界は少々の競合があっても連携してしまいます。

SoftLayerの最大の利点は、物理マシン(ベアメタルサーバー)が簡単に入手できることです。しかし、複数マシンの管理・監視ツールが標準で提供されるわけではありません。また、社内システムとの接続の少々弱いところです。単に接続するだけなら何の問題もないんですが、IT基盤全体の管理となるとちょっと難しい。

一方、マイクロソフトはMicrosoft Azureというパブリッククラウドの他、System Center製品を使ったプライベートクラウドの構築ツールを持っています。そして、System Centerによるプライベートクラウドを、Microsoft AzureそっくりのGUIで管理するためのソフトウェアが「Azure Pack」です。

Azure Packは、System Centerとともに動作しますので、SoftLayer上のベアメタルサーバーにSystem Centerを入れても当然使えるはずです。そうすると、SoftLayerの持つベアメタルサーバーの調達機能を使ったプライベートクラウドが構築できます。

もっとも面倒なベアメタルサーバーの調達や廃棄をSoftLayerに任せる、ということで、なかなか面白い構成です。

ちなみに、System CenterにはMicrosoft Azureと連携したハイブリッドクラウドを構成する機能もありますから、Microsoft Azureとの連携も可能です。もっとも、これはIBM的にはちょっと微妙かもしれませんが。

実は、この企画「ホスティッド・プライベート・クラウド勉強会　～Windows Azure Pack on IBM SoftLayer～」は、グローバルナレッジが開催した「G-Tech 2015」の懇親会に参加いただいたことがきっかけだそうです(G-Techについては「今年もやりますG-Tech ～役に立つ楽しいイベントを目指します～」をご覧ください)。

最近、グローバルナレッジでは、単に教育サービスを提供するだけでなく、各種勉強会やコミュニティも積極的に支援していきたいと考えています。

ベンダーをまたがったサービスの勉強会なども企画できますので、「アイデアはあるけど、自分で企画するのはちょっと...」という方はぜひご相談ください。

実はベンダーをまたがったサービスは、ライセンスの縛りなどがあり、我々のビジネスにするのも案外難しいんです。勉強会ならできることもありますので、アイデアをお待ちしています。

会場について

今回の会場は、dots.というイベント&コミュニティスペースでした。渋谷のディズニーストアの横にあり、アクセスも良好で、ゆったりした作りのいい環境でした。

実は、同日同時刻、すぐ近くのタワーレコード渋谷店で「柊木りお」のフリーライブがあったんですが、断念しました。ちなみに、彼女の代表曲が「輪廻の恋」。

さらに同日、その少し前に、マイクロソフトの「女子高生AI(人工知能)」と称した「りんな」のイベントが原宿でありました。こちらは時間が早すぎて、やはり断念。

「輪廻の恋」と「りんなのAI(アイ)」と、うまくつながったんですが、って全然関係ないですね。

近況など

しばらくご無沙汰でしたが、これは編み物(棒針です)を再開していただめです。セーターは編むのに1シーズン近くかかるので、ちょっと面倒になってきました。友人に強く勧められて帽子を編んでみました。

人に上げようと思って編んだのですが、ついでにあと2つ編もうと思い、そうしたらもう1つ何か別の物を、と欲が出てきました。現在はネックウォーマーを制作中です。

すべてを年内に完成したかったのですが、ちょっと無理そうなのであきらめてブログを書いてます。

VDI仮想マシンの再作成

VDI(Virtual Desktop Infrastructure)は、クライアントPCを仮想マシンとして構成し、外部からリモートデスクトップ接続するサービスです。

Windows Server 2012では、VDI環境が大幅に強化され、Windows Server 2008 R2に比べて圧倒的に簡単になりました。

▲「マイクロソフトデスクトップ仮想化ソリューション」テキストより

VDIには、個人ごとに1台の仮想マシンを固定する「個人用仮想デスクトップ」と、一定台数の仮想マシンを使い回す(たとえば、10台あれば先着10人が使えて、誰かがログオフすれば他の人が使える)「プールされた仮想デスクトップ」があります。

「プールされた仮想デスクトップ」は、誰が使っても同じ環境になるように、全仮想マシンを同時に更新する仕組みが用意されています(実際には更新ではなくて、入れ換え)。

入れ替えのタイミングは、以下の2種類が選択できます。

• ユーザーが仮想デスクトップからログオフするとき
• スケジュールに基づく

ユーザーが仮想デスクトップからログオフするとき

開始時刻と終了時刻を指定し、この範囲で入れ替えを行います。開始時刻を現在時刻よりも前に設定すれば、即座に更新が始まります。

終了時刻の扱いについて、具体的な動作を記述したドキュメントが見当たらないので、実際に試してみました。システムに負荷をかけないように、指定された時刻の範囲で徐々に更新されていくようですが、即座に更新されることもありました。

ただし、ログオン中の仮想デスクトップマシンは、ユーザーがログオフするまで更新は行われません。指定された終了時刻を過ぎていても、ログオフすれば更新が始まります。

スケジュールに基づく

ログオン中のユーザーがいても、強制ログオフして更新を行います。

こちらは、今すぐ実行するか、更新予定時刻を指定するか、どちらかを選びます。

なお、テンプレートとなる仮想マシンにはスナップショットがあっても構いません。仮想マシンに展開するときにスナップショットが統合されます。

更新時は、大量のファイルコピーが発生しますが、Windows Server 2012のオフロードデータ転送(ODX)に対応したストレージデバイスを使う場合は、LANではなくSAN内でデータ転送を行えるため、大幅に速度が向上する場合があります。

Hyper-VのDHCPガードの意味

Windows Server 2012以降のHyper-Vには「DHCPガード」という機能があります。説明には「承認されていない仮想マシンからのDHCPサーバーメッセージを削除します」とあります。

実際に、このチェックボックスをオンにすると、DHCPパケットが仮想マシン外に飛びません(DHCPサーバーとして実用的な動作はしません)。

▲DHCPサーバーガードの構成は仮想マシン単位で行う

Windows ServerにはDHCPサーバーをActive Directoryで承認する機能があるため、この「承認」も何らかの操作を指すと思っている人が多いようです。

実は、ここでいう「承認」は「管理者が正しいと判断する」という意味です。つまり、管理者が、正しいDHCPサーバーを立てたと思ったらチェックを外すという手順を意味します。

存在しない機能を探すのは難しいのですが、一応、それらしいものがありました。英語版TechNet Forumの「How to configure DHCP guard in Hyper-V 2012?」では、モデレータのBrian Ehlertさんがこう答えています。

Unauthorized and Authorized is a procedural / process phrase. It is not a technical phrase or any setting that can be applied.  It is the business decision to call machine authorized or not.

意訳

「承認されていない/承認されている」は手続きの順序を意味しており、技術的な方法や設定手順を意味するものではありません。「承認されている/いない」は、仮想マシンを構成するときのビジネス的な判断(DHCPサーバーにするかしないかを管理者が決めること)を意味します。

Hyper-V管理者と、仮想マシン管理者が同一の場合は意味を持ちませんが、以下のような運用を想定しています。

1. Hyper-V管理者が仮想マシンVMを作成
2. VM管理者はDHCPサーバーでないことをHyper-V管理者に通知
3. Hyper-V管理者が仮想マシンVMのDHCPガードを有効化
4. 誤ってVMにDHCPサーバーをインストールしてもDHCPパケットは廃棄される

物理マシンの認証を仮想マシンのドメインコントローラーで行うには

マイクロソフト製品の多くは、Active Directoryドメインサービスを必要とします。しかし、ドメインコントローラーはIDとセキュリティ管理の要なので、構築や複製が何かと面倒です。

特にVDI環境を構築するときは、物理マシンをドメインのメンバーにする必要があり、通常は物理マシンを2台必要とします。

何とか1台でできないものでしょうか。

ksakakiさんのブログ「More Than One Way」の記事「世界のブログから - 「ドメイン コントローラーどうしよう」に、ドメインコントローラーを仮想マシンとして構成し、その仮想マシンホストをメンバーとする手順が掲載されています。

詳細はksakakiさんのブログを読んでいただくとして、要点だけを整理してみましょう。

1. ドメインコントローラー仮想マシン(DC)は自動起動
   既定値は[サービスが停止したときに実行されていた場合は自動起動する]
2. ドメインコントローラー仮想マシン(DC)は最初に起動
   既定値は0
3. ドメインコントローラー仮想マシン(DC)は自動シャットダウン
   既定値は[保存]
4. 万一に備えて物理マシンのローカル管理者アカウントを正しく構成
   ドメインコントローラーが動かないと、ドメインのユーザーでログオンできません。セキュリティ対策としてローカル管理者Administratorの名前を変えたり、無効化する場合もありますが、Hyper-Vホストには必ずローカル管理者としてログオンできるようにしておいてください。

上記1から3は、以下のPowerShellコマンドレットで構成できます(`は継続行の印)。

Set-VM -VMName 仮想マシン名  `
    -AutomaticStartAction Start   `
    -AutomaticStartDelay 0          `
    -AutomaticStopAction ShutDown

しかし、これだけでは起動時のタイミングによってはエラーが出ます。追加の設定が「世界のブログから - Hyper-Vとドメイン コントローラーに関してもう一つ」として公開されています。

1. 確実に認証させるため、資格情報のキャッシュを停止
   物理マシンで以下のようにレジストリを変更します(PowerShellの場合)。
   Set-ItemProperty `
       'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' '
        -Name cachedlogonscount –Value 0
   (`は継続行の印)
2. 起動時の待ち時間を回避するため、サービス起動順序を構成
   ドメインコントローラー(つまり仮想マシン)で以下のコマンドを実行
   sc config netlogon depend= LanmanWorkstation/LanmanServer/DNS
   (現在の依存関係は sc qc コマンドで表示できます)

以上の構成をしたら、あとは物理マシンの優先DNSに仮想マシンのDNSサーバーアドレスを指定し、通常どおりドメインに参加してください。

だいたいこれで大丈夫なのですが、VDIを構成する場合は以下のようなトラブルがありました。

• 仮想化ホストの構成時に警告が出る
  仮想化ホストの構成時に、ローカルグループの設定に失敗することがあります。管理ツールで見ると、ローカルグループは正しく構成されているようです。実際、そのままでも動作しましたが仮想化、念のためホストをVDIから削除して、再構成した方が無難です。
• 複数のNICがあると、クライアントOSの展開に失敗する
  仮想化ホスト(物理マシン)に、NICが2枚構成されていると(たとえば外部ネットワークと内部ネットワーク)、クライアントOSの展開に失敗しました。同じ構成で成功したこともあるので、詳細は分かりません。

前者はVDIの再構成で、後者は内部ネットワークをやめ、VLANで物理ネットワークを分離することで解決しました。ただ、そもそもなぜ複数NICで問題が発生したかは分かりませんので、もう少し調べてみます。

仮想マシンとしてのドメインコントローラーとディスクキャッシュ

Windows Serverをドメインコントローラーにした場合、Active Directoryデータベースの整合性を維持するため、書き込みキャッシュを無効にします。

仮想マシンをドメインコントローラーとして構成した場合、物理マシンのキャッシュが無効になるため、性能が低下するらしいが本当ですか。

という質問をいただきました。

最終的な答えはNOですが、いくつか微妙な問題があったのでまとめておきます。なお、以下の文書はすべてWindows Server 2008ベースのものですが、Windows Server 2012 R2でも状況は同じだと思われます。

サポート技術情報888794「仮想ホスト環境で Active Directory ドメイン コントローラーをホストする場合の考慮事項」には以下のことが記載されています。

仮想ホスト環境のソフトウェアで、Force Unit Access (FUA) をサポートする SCSI エミュレーション モードが正しくサポートされている場合、この環境で Active Directory が実行するバッファーなし書き込みはホスト オペレーティング システムに渡されます。

FUA がサポートされていない場合は、Active Directory データベース、ログ、およびチェックポイント ファイルをホストするゲスト オペレーティング システム上のすべてのボリュームにおいて、書き込みキャッシュを無効にする必要があります。

後半は自動的に設定されるため、特に意識する必要はありません。

FUAは、キャッシュ制御をするためのSCSIコマンドです。このコマンドが、仮想マシンから物理マシンに正しく送られる場合、キャッシュを無視してアクセスを行えるようです。

つまり、キャッシュを無効にしなくても、仮想マシンDCからのI/O要求に関してはキャッシュを使わずにディスクをアクセスします。

もちろんSCSIコマンドを発行するのは、仮想マシンの仮想ディスクに対してですから、仮想マシンには仮想SCSIディスクが必要です。また、最終的にSCSIコマンドを受け取るのは物理ディスクですから、物理ディスクもSCSIディスクでなければいけません。

物理ディスクがSCSIでない(IDE/ATA)の場合は、VHD(VHDX)ファイルが破損しないように、キャッシュを手動で無効にする必要があります。

なお、仮想ディスクは、ドメインコントローラーの既定の動作によりSCSIであろうとなかろうと書き込みキャッシュを無効にします。

Microsoft TechNetのドキュメント「仮想化ドメイン コントローラーの展開に関する考慮事項」には以下の記述があります。

Active Directory のデータが壊れる可能性を減らすため、SCSI コントローラーを使用するか、ATA ドライブまたは IDE ドライブで書き込みキャッシュを無効にしてください。

仮想ドメイン コントローラーをホストする Hyper-V サーバーでは、IDE ドライブや ATA ドライブではなく SCSI 物理ドライブを使用してください。SCSI ドライブを使用できない場合は、仮想ドメイン コントローラーをホストする ATA ドライブまたは IDE ドライブで書き込みキャッシュを必ず無効にしてください。詳細については、「Event ID 1539 – Database Integrity (イベント ID 1539 - データベースの整合性に関するページ)」を参照してください。

ドメイン コントローラーとして実行するすべての仮想マシンで、仮想 SCSI コントローラーを使用してください。仮想 SCSI コントローラーを使用できない場合は、ドメイン コントローラーとして実行する仮想マシンの仮想 IDE ドライブで書き込みキャッシュを必ず無効にしてください。インストールされているディスク コントローラーの種類は Virtual Machine Manager の設定ダイアログ ボックスで確認できます。詳細については、「仮想マシンを構成する」を参照してください。

まとめると、以下の通りです。

• 物理ディスクがATAの場合
  • 物理ディスク…手動でキャッシュ無効化
  • 仮想ディスク…自動的にキャッシュ無効化

• 物理ディスクがSCSIの場合で仮想ディスクがATAの場合
  • 物理ディスク…手動でキャッシュ無効化
  • 仮想ディスク…自動的にキャッシュ無効化

• 物理ディスクも仮想ディスクもSCSIの場合
  • 物理ディスク…FUAによる自動制御
  • 仮想ディスク…自動的にキャッシュ無効化

より詳細な内容は、以下のドキュメントをダウンロードしてください(英語です)。

Hyper-V でのドメイン コントローラーの実行に関するページ (ダウンロード可能な Word 文書)

Hyper-V 仮想化環境での時刻同期

時刻同期は今ではサーバーの非常に重要な要件となりました。時刻が同期されていないと、各種のログの照合が難しくなるだけでなく、認証プロトコルが失敗することさえあります。

Hyper-Vを含め、多くの仮想化環境では、仮想マシンの時刻が遅れる傾向にあります。

昔「任天堂ゲームウォッチ」という携帯ゲームがありました。単機能なので、学校でゲーム機本体の交換を行った経験のある人もいるでしょう。ゲームウォッチは、名前の通り本来は時計なのですが、内蔵されたCPUでソフトウェア的に時刻情報を管理していたようです。頻繁にゲームを行うと、CPU割り込みが増え、表示時刻が遅れるという問題がありました。仮想環境でもこれと似たような問題が発生します。

ちなみにゲームウォッチの発売は1980年なので、このたとえ話は40歳代以上にしか分からないと思います。何しろファミリーコンピューター(ファミコン)以前の話です。

●Hyper-V統合サービスでの時刻同期

閑話休題、そこでHyper-Vでは「統合サービス」を仮想マシン上で動作させることで、時刻の遅れを防ぎます。

マイクロソフトのWebサイト「ヒント: Hyper-V 仮想化環境におけるゲスト OS の時刻同期について」によると、時刻同期は以下のように行われます(Windows Server 2008/2008 R2での記載ですが、2012でも同じだと思われます)。

• ゲストOSの時刻が、ホストOSより遅れている場合(5秒以上)
  強制的に時刻同期を行う
• ゲストOSの時刻とホストOSの時刻のずれが5 秒未満の場合
  時刻同期を行うかどうかは NTP (w32timeサービス) に委任
  統合サービスの時刻同期 はVM IC Time Synchronization Provider という名前の NTP Time Providerとして提供
• ゲストOSの時刻が、ホストOSの時刻より進んでいる場合(5秒以上)
  時刻同期しないので、必要に応じてNTPなど、他の時刻同期機構を利用

また、統合サービスの "時刻の同期" は、他の時刻ソース(他の NTP サーバー)の参照環境と共存可能なように実装されているそうです。

その他に、ゲストOSの起動時に同期します。ゲストOSの時刻はシャットダウンまたは保存時に停止するため、次に起動したときは必ず遅れています。つまり、メカニズムとしては「5秒以上遅れている場合」と同じです。

 

●NTPの構成

NTPのパラメータ調整はW32TMコマンドを使います。仮想マシンンに依存しない時刻同期については、私と同じDirectory ServicesのMicrosoft MVPである小鮒道成さんが書いた記事が参考になります。

「Windowsネットワーク時刻同期の基礎とノウハウ」

万一時刻がずれてしまったらどうするかということも問題になります。時刻変更の影響が予測できる場合で、許容できる程度のリスクであれば、一気に同期させるのもひとつの方法です。

時計を進めることは、遅らせることに比べてリスクが少ないと考えられます。通常、仮想マシンンは時刻が遅れるので、多くの場合は問題が出ません。

しかし、時刻変更の影響が予測できない場合や、リスクが大きい場合はどうすればいいでしょう。NTPのパラメータで調整できるならそうしてください。そうでなければ、人間が少しずつ時刻差を縮めていくしかありません。

 

●【追記】ドメインコントローラーの構成

仮想マシンドメインコントローラーでは特別な注意があります。

Microsoft TechNetのドキュメント「仮想化ドメイン コントローラーの展開に関する考慮事項」から引用します(太字は私の注釈)。

ドメイン コントローラーとして構成された仮想マシンでは、統合サービスを通じてホストとの時間の同期を無効にしてください。代わりに、既定の Windows タイム サービス (W32time) ドメイン階層時間の同期を使用してください。

ホスト時間の同期では、ゲスト オペレーティング システムは各自のシステム クロックをホスト オペレーティング システムのシステム クロックに同期させることができます。ドメイン コントローラーはそれぞれ独自の時間同期メカニズムを持っているので、ドメイン コントローラーとして構成された仮想マシンではホスト時間の同期を無効にする必要があります。ドメイン コントローラーが各自のソースから時間を同期させると同時にホストからも時間を同期させた場合、ドメイン コントローラーの時間が頻繁に変化する可能性があります。ドメイン コントローラーのタスクの多くはシステム時間に関連付けられているので、システム時間が突然変化した場合、それが原因で残留オブジェクトがディレクトリに残り、レプリケーションが停止する可能性があります。

Hyper-V マネージャーの [統合サービス] セクションにある仮想マシンの設定で [コンピューターの時計の同期] チェック ボックスをオフにすることで、ホスト時間の同期を無効にすることができます。

Hyper-VとVMware

今日は(もう昨日ですか)、Hyper-VとVMwareの話をしてきました。VMwareの部分は、社内のエキスパートと相談して作りました。

どちらもサーバー仮想化製品ですが、そこでのビジネスはもう終わっていて、大ざっぱに言えば「どちらでも問題ない」というレベルになっています。

その証拠に、各社、ハイパーバイザー単体では値段がついていません。

じゃあ、何がビジネスの中心かというと、まずはストレージとネットワーク、そしてIT運用全体を管理するITMS(ITサービスマネージメント)でしょう。

マイクロソフト製品で言うと、ストレージはWindowsの「記憶域プール」およびサードパーティ製品のSAN。そしてSMB 3.0ベースのNASです。

ちょっとしつこかったかも知れませんが、SMB 3.0は本当にいいプロトコルに大変身しています。仮想マシンの置き場所として十分機能します。

ネットワークはHyper-Vの拡張機能としてのNVGREと、それを制御するSystem Center Virtual Machine Managerですね。

そして、運用管理はSystem Center製品の連携です。

System Centerは複雑な製品ですが、これからのITサービス管理に必須の製品になるはずです。