Hyper-Vのインストール

メーカー製のインストールディスクを使うことで、サーバーのセットアップは順調に進んだ。サーバーマネージャでHyper-V役割を追加した場合、外部仮想ネットワークの構成も同時に行える。

Hyper-V役割の追加後は、再起動が2回行なわれる。少し時間がかかること、あまりに寒いこと、騒音で頭痛もしてきたこと、そしてこの日の作業はHyper-V役割を追加した時点で終了予定だったことから、完了を待たずに帰ることにした。これが大失敗だった。

Hyper-Vの仮想マシンは「仮想ネットワーク」と呼ばれる仮想ハブを使う。よく使われるのは「外部ネットワーク」と呼ばれる構成である。外部ネットワークを構成すると、物理マシン上に仮想的なNICが追加され、既存の物理NICのTCP/IP構成がコピーされる。一方、元の物理NICはレイヤー2レベルの特殊なプロトコルだけがバインドされ、外部ネットワーク(ハブ)に接続される。外部LANからのケーブルが接続されると考えても良いだろう。物理NICのTCP/IP構成がコピーされた仮想NICや、仮想マシンの仮想NICはすべて「外部ネットワーク」に接続され、外部と通信を行なう(図3)。

図3: 外部ネットワーク

物理NICからTCP/IP構成をコピーするときは一時的にネットワークが切断されるが、しばらくすると自動的につながる。ところが、ごくまれに複製に失敗することがある。この場合、新しく作られた仮想NICはDHCPクライアントとなるが、サーバーセグメントにDHCPサーバーがいないと、適切なIPアドレスが取得できない。データセンターでの作業中に、まさにこのトラブルに遭遇してしまった。

Hyper-V役割をインストールし、再起動中にオフィスに帰った私はリモートデスクトップ機能を使って続きの作業を行なった。再起動は成功し、ログオンも成功した。サーバーマネージャでHyper-V役割を追加した場合、再起動後の最初のログオンでサーバーマネージャが自動起動し、最後の構成を行なう。仮想ネットワークの作成はこのタイミングで行なわれる。そしてネットワークが切断され、二度とつながらなかった。仕方がないのでデータセンターに逆戻りした。同様のトラブルはVLANタグについてもあてはまる。ネットワーク管理者と相談しながら構成してほしい。

なお、今回利用したサーバーは管理用の専用NICを持っており、そこにIPアドレスを割り当てていれば今回のような自体は起きなかったはずだ。緊急用の機能は、最初に構成すべきである。

仮想ハードディスク

仮想マシンのシステムディスクには容量可変ディスクを割り当てた。容量可変ディスクは書き込み性能に劣るが、システムディスクに対する書き込みは少ないので性能上の問題はないと判断した。SQL Server用のデータベース格納ディスクには容量固定ディスクを割り当てた。最高の性能を発揮するのはパススルーディスクだが、仮想化の特徴である柔軟性を損なう。やはり容量固定ディスクが最適だと考えた。

Windows Updateと自動再起動

構成が完了し、運用フェーズに入ってからは目立ったトラブルもなく、安定稼働している。修正プログラムはWindows Updateを使った推奨構成だが問題は一度もない。

唯一の問題は、データセンターでネットワークアダプタがオフラインになると、無条件でシステム管理者に連絡が来ることだ。当初、インストール(つまり再起動の可能性がある)時刻を午前3時にしていたら、IT部門の担当者から「深夜の連絡は勘弁してほしい」と泣きが入った。一定時間後にネットワークがオンラインになったら報告しないとか、そもそも報告対象から外すとか、そういう柔軟なオプションはないらしい。仕方がないのでインストール時刻を午前8時に設定した。これなら常識的な時間である。

仮想マシンの方は、再起動しても物理ネットワークアダプタはオフラインにならないので問題ない。インストール時刻は午前3時に設定した。