SE の雑記

Hyper-V Server 2008 R2 が提供された当初から気になっていたことがありました。
Hyper-V Server 2008 R2 + Windows Server 2008 R2 でクラスタを組んで Live Migration はできるのか？？

昨日、検証用購入した中古の ThinkPad が届いたのでさっそく試してみました。

■使用した環境

今回の環境はこちら。
ThinkPad 2 台構成です。
共有ストレージには Windows Storage Server 2008 を使用しています。

機種	OS	CPU
ThinkPad T60	Hyper-V Server 2008 R2	# T60 標準のT5500 から T5600 に換装しています。
ThinkPad T61	Windows Server 2008 R2 Datacenter Edition

?

■クラスタの検証

Hyper-V Server 2008 R2 に関しては以前構築したクラスタ環境を使用しています。
この環境に Windows Server 2008 R2 Datacenter Edition を追加してみました。
[オペレーティング システムのインストールオプションを検証] で失敗になるのですがクラスタを構築することができました。

?

■構築された環境

できた環境がこちらになります。
[HVS-CLUSTER] という仮想ホスト名でクラスタを構築しています。
以下の画面は SCVMM で表示されるサーバーの階層になります。

ここに Live Migration 可能な OS として CSV 上に 1 台のゲスト OS を構築しています。
# メールの検証環境として構築した Windows Server 2000 を 配置しています。

■Live Migration を実行

それではさっそく Live Migration の実行です。

SCVMM で Live Migration を実行する場合は、[移行] 操作を実行します。

[フェール オーバー クラスター マネージャー] の場合は [仮想マシンを別のノードにライブ マイグレーション] で
Live Migration を実行できます。

[転送の種類] が [ライブ] となっているサーバーに対しての移行が Live Migraion になります。

エラーになることなく Live Migration が完了しました。

?

Hyper-V Server 2008 R2 と Windows Server 2008 R2 間でも Live Migration はできるんですね～。
サポートは受けられない構成でしょうけども。

以前投稿した内容に SQL Server 2008 Express Edition でメンテナンスプランの利用についてコメントをいただきました。

残念ながら SQL Server の Express Edition では、メンテナンスプランが使用できないんですよね。
SQL Server 2008 の各エディションがサポートする機能

また、SQL Server の Express Edition では SQL Server Agent も使用できないため、定期的なジョブを SQL Server 側で
実行することができません。

スキルチャージプログラムで貸与されている環境は Community Server をインストールしてあり、データベースには
SQL Server 2008 Express Edition を使用しています。
この環境ですが日次で 1 世代のバックアップだけは自動で取得する用に設定をしてあります。

メンテナンスプランと SQL Server Agent を使用できない状態で定期的にバックアップを取得するため、
タスクスケジューラ + SQLCMD.EXE を使ってバックアップのスケジューリングを設定しています。

[タスク スケジューラ] は管理ツールの中に入っています。?

このタスク スケジューラで以下のようなタスクを作成しています。
?

操作には以下のような設定を登録してあります。

操作	プログラムの開始
プログラム/スクリプト	"C:Program FilesMicrosoft SQL Server100ToolsBinnSQLCMD.EXE"
引数の追加 (オプション)	-S localhost<インスタンス名> -E -i "E:ToolsBackupCSDBBackup.sql"

?

CSDBBackup.sql には以下の内容を記載しています。
# SSMS で生成したスクリプトを記載しているだけですが。

BACKUP DATABASE [CommunityServer] TO? DISK = N’E:BackupCommunityServer.bak’ WITH NOFORMAT, INIT, NAME = N’CommunityServer-完全 データベース バックアップ’, SKIP, NOREWIND, NOUNLOAD,? STATS = 10 GO

?

同様の方法でインデックスのメンテナンスも可能です。
ざっくりと作ったインデックスの再構築のクエリです。
これを SQLCMD でタスクスケジューラから実行すると定期的にインデックスの断片化を解消することができます。
# アドホッククエリで書いてしまっていますが…。

SET NOCOUNT ON USE [CommunityServer] GO DECLARE @name sysname DECLARE @SQL nvarchar(500) SELECT * INTO [#tables] FROM [sys].[tables] DECLARE [table_cursor] CURSOR FOR SELECT [name] FROM [#tables] OPEN [table_cursor] FETCH NEXT FROM [table_cursor] INTO @name WHILE @@FETCH_STATUS = 0 BEGIN ??? SET @SQL = N’ALTER INDEX ALL ON [‘ + @name + ‘] REBUILD’ ??? EXECUTE sp_executesql @SQL ??? FETCH NEXT FROM [table_cursor] INTO @name END CLOSE [table_cursor] DEALLOCATE [table_cursor]

?

自分でクエリを書くのが面倒な場合は、定期的に実行したい操作を SSMS からスクリプト化しておけばよいと思います。

Express Edition を使っていてもデータベースのメンテナンスは定期的に実行しないと駄目ですが、無償版なので
この辺の機能がないのは仕方ないですね。

SCVMM のセルフサービスポータルをインターネット経由で公開できないかなといろいろと検証していました。
インターネット経由だと VPN か Direct Access 辺りを使用しないと厳しそうなのですが、調べたことを投稿しておきたいと思います。

今回の検証をするにあたり、Tech Fielders のライトニングトークの [ここまではできる SCVMM セルフサービスポータル] を
参考にさせていただきました。
Tech Fielders セミナー これまでのライトニングトーク登壇者
# ライトニングトークの内容を自分で検証してみたという投稿になっているかと。

SCVMM のセルフサービスポータルにログインした後のゲスト OS の接続には 2 種類の接続方法が用意されています。

1. VM に接続
2. リモート デスクトップ

どちらを使うかによってアクセスの経路が変わります。

■VM に接続

VM に接続は SCVMM の管理コンソールの [バーチャル マシンに接続] と同じ機能になります。
SCVMM の管理コンソールで接続した場合は、以下のように表示されます。
?

これをセルフサービスポータルで表示すると以下のように表示されます。

ゲスト OS のコンソールを直接開く機能ですね。

この機能ですが以下の接続がされているようです。
ポート 2179 で直接ホストに接続しているみたいですね。
SCVMM の管理コンソールのバーチャルマシンに接続で実行される [VirtualMachineViewer.exe] も、ポート 2179 で接続が
されているので、セルフサービスポータルの ActiveX も同様の動作になるんですね。

SCVMM がホスト OS にアクセスして表示しているのではなく、クライアントがホスト OS に接続をしているようです。
そのためクライアントが直接ホスト OS にアクセスできないといけないようです。

また、ホスト OS に接続をする関係上、ホスト OS を名前解決できないと接続ができません。
ホスト OS の名前解決ができないと以下の画面になってしまい接続ができません。

■リモートデスクトップ

リモートデスクトップですがこちらはゲスト OS のリモートデスクトップに接続をします。
そのため、ゲスト OS でリモートデスクトップを設定する必要があります。

私の環境の問題のような気もするのですが、[ネットワーク レベル認証で～] にしてリモートデスクトップを設定していると
セルフサービスポータルで接続することができませんでした。

[リモート デスクトップを実行している～] だと接続ができました。

リモートデスクトップだと以下の接続になるようですね。
直接ゲスト OS にリモートデスクトップのデフォルトポート 3389 で接続されます。
そのため、ゲスト OS でリモートデスクトップのポートを 3389 から変更すると接続できませんでした…。

こちらも直接接続していますので、ゲスト OS の名前解決ができないとエラーになります。

?

SCVMM のセルフサービスポータルからコンソールを開く場合は、ホストまたはゲスト OS に直接接続できる必要があるので、
インターネット経由での接続は簡単にはできなさそうですね。

インストールマニアックス 3 の VPS コースでは DotNetPanel という Web 管理ツールが提供されているのですが、
こちらはコンソールを操作する機能は提供されていないんですよね。

Hyper-V + SCVMM で IaaS の環境が作れれば面白いな～と思ったのですが、コンソールの利用を考えるとなかなか難しいですね。

自宅の検証環境にはインストールマニアックス 3 の勉強用で構築した Hyper-V Server 2008 R2 が 1 台あります。
# 私は VPS コースだったのですが勉強を兼ねて構築していました。

せっかくなので、この環境で Live Migration 環境を作ってみたいと思います。
1 台なので Live Migration のテストはできませんが。
# 2 月のどこかで中古の ThinkPad を購入して Live Migration の検証環境を作りたいな～とは思っているのですが。
??? UPS の電源容量が小さいので Live Migration 環境を ML115 で作ろうとすると UPS がなり始めてしまうのですよね･･･。

ちなみにこの環境はドメインに参加済みの環境です。

■クラスタのインストール

まずはクラスタ環境を構築する必要があります。
Hyper-V Server 2008 R2 では [sconfig.cmd] で表示されるメニューからクラスタの有効化ができます。

1. [11] を選択
   ?
2. [はい] をクリックします。
   
3. DISM で機能が有効化されます。
   
4. [OK] をクリックします。
   

?

■iSCSI イニシエーターサービスの自動起動化

デフォルトでは iSCSI イニシエーターのサービスは自動起動になっていませんので、自動起動に設定し初回の起動を行います。
# ローカルで MMC が使えないのでコマンドで。

1. コマンドプロンプトで以下のコマンドを実行し、サービスを自動起動にします。
   

   sc config MSiSCSI start= auto

2. 自動にしてもサーバーが再起動しないとサービスが起動されないので、再起動しない場合は以下のコマンドで起動させます。

   sc start MSiSCSI

?

■iSCSI ターゲットへの接続

iSCSI ターゲットへの接続ですが、iSCSI イニシエータのコマンドとして [iscsicli.exe] が用意されています。
Server Core 環境なのでコマンドで設定するしかないのかと思っていたのですが、GUI である、[iscsicpl.exe] が使えるんですね。

これは楽でいいです。

ターゲットを入力してクイック接続してみます。
# ターゲット側で、iSCSI ターゲットを作成し、Hyper-V Server 2008 R2 の iSCSI イニシエータの FQN を追加済みです。

接続できました。

ターゲット側でディスクを割り当てておきましたので、まずはクォーラム用のディスクが使用可能な状態です。

ひとまず、[DISKPART] コマンドで Q ドライブに割り当てておきます。
今回は、ディスク 2 に新規のディスクが割り当てられていますので以下のコマンドを実行していきます。

diskpart list disk select disk 2 create part primary format quick assign letter=Q exit

?

■クラスタの構築

[cluster.exe] を使ってクラスタを構築してもいいのですが今回は勉強を兼ねて PowerShell で。
ドメインにクラスタ用のコンピュータアカウントを作成して無効状態にし、セキュリティとして今回の作業に
使用するドメインユーザーのフルコントロールを付与している状態です。
??

後は以下のコマンドを順次実行していきます。
クラスタのコンピュータアカウントにフルコントロールを指定したユーザーをローカルの Administrators に入れるところから
コマンドを記載しています。
現在のサーバーは DHCP で IP を割り当てているので、クラスタの作成時に静的 IP を指定していません。

net localgroup “Administrators” “<ドメイン名"ユーザー名>” /add
runas /user:“<ドメイン名ユーザー名>”? cmd
powershell

Import-Module FailoverClusters
New-Cluster ?Name “HVS-CLUSTER” ?Node $ENV:COMPUTERNAME

これでクラスタの構築は完了です。
他の端末に、RSAT の [フェールオーバー クラスタリング ツール] を導入して接続してみたいと思います。

?

正常に接続できました。

クラスターの作成自体も管理ツールからリモートで実施できるので、管理端末が用意できるのであれば、Hyper-V Server 上で
PowerShell を使わなくても構築することが可能です。

■クォーラムディスクの設定

作成直後のクォーラムはノードマジョリティになっているので、Q ドライブに割り当てているディスクをクォーラムとして
追加したいと思います。

Get-ClusterQuorum Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterResource | ft -Wrap Set-ClusterQuorum -NodeAndDiskMajority "クラスター ディスク 1"

?

これでクォーラムがノードおよびディスクマジョリティになりました。

Get-ClusterQuorum Cluster??????????????????? QuorumResource??????????????????????????? QuorumType ——-??????????????????? ————–??????????????????????????? ———- HVS-CLUSTER??????????????? クラスター ディスク 1??????????? NodeAndDiskMajority

?

■CSV の有効化

初期状態では CSV は無効になっているので、これを有効化します。

Get-Cluster | %{$_.EnableSharedVolumes="Enabled/NoticeRead"}

EnabledSharedVolumes は [Enabled/NoticeRead] を指定する必要があります。
CSV を有効にするときには以下の通知が表示されます。

[Enabled] だけですと上記の通知がコンソール内に表示されるだけで有効にすることができません。
有効にするためには通知を読んだ事を指定する必要がありますので、[Enabled/NoticeRead] が必要となります。
無効にする場合は、[Disabled] を指定します。

GUI から CSV の無効化はできないみたいなので、CSV を無効にする場合には PowerShell から実行する必要があるようですね。

■CSV にディスクを追加

現在はクォーラム用のディスクしか iSCSI に作っていなかったので CSV 用のディスクを新規に作り、CSV に割り当てたいと思います。
私の環境の iSCSI ターゲットは Storage Server 2008 ですので、仮想ディスクを追加して、iSCSI イニシエータでマッピングします。

あとはこのディスクも DiskPart でフォーマットしておきます。
今回はドライブ文字は不要ですのでアサインはしません。
# クォーラムも不要なのですが、今までのクラスタ構築の癖で Q ドライブを割り当てちゃうんですよね。

diskpart list disk select disk 3 create part primary format quick exit

?

後はこのディスクを CSV に追加します。

Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterResource | ft -Wrap Add-ClusterSharedVolume "クラスター ディスク 2"

?

これで CSV の追加は完了です。
CSV に追加されているディスクを確認してみます。

Get-ClusterSharedVolume Name?????????????????????? State????????????????????? Node —-?????????????????????? —–????????????????????? —- クラスター ディスク 2????? Online???????????????????? hvs2008r2

?

■仮想マシンの作成

残るは Live Migration する仮想マシンの作成です。
ひとまず管理用端末の GUI で仮想マシンを作りたいと思います。

クラスタの管理は RSAT の [フェールオーバー クラスタリング ツール] をインストールすればよいのですが、仮想マシンの作成は
クラスタ用の管理ツールではできません。

仮想マシンを作成する場合は [Hyper-V ツール] をインストールする必要があります。

今回は管理用端末に SCVMM 2008 R2 の端末を使用しているのですが、この場合でも RSAT の Hyper-V ツールが必要になるんですね。

GUI を使用して CSV を使用する仮想マシンを作成することができました。

?

PowerShell の場合は、[Add-ClusterVirtualMachineRole] を使用すればよいと思うのですが、私の環境では
エラーになってしまうんですよね･･･。
GUI からは作成できているのでコマンドのオプションを間違っているような気がするのですが原因までは追えていません。

?

コマンドからの仮想マシンの作成がうまくいっていないのですがひとまずこれで Live Migration に必要となる環境までは
設定ができたと思います。

GUI って楽だな～と改めて実感しました･･･。

冗長化の最後として、サーバーをシャットダウンしながら冗長化のテストをしてみたいと思います。

■管理コンソールの接続

まずは管理コンソールの接続テストから。

1. 両サーバーが停止している場合
   両サーバーをシャットダウンしている状態です。
   当然ながら接続できませんね。
   
2. 片側のサーバーが起動している場合
   片側のサーバー (2008R2-MDOP-01) だけ起動してみました。

   この状態は正常に接続ができますね。

    

   2008R2-MDOP-02 だけが起動している状態でも正常に接続ができます。

3. ファイルサーバーが停止している場合 (MED-V サーバー起動後)
   MED-V サーバー (2008R2-MDOP-01 / 02) の起動後にファイルサーバーをシャットダウンした場合のテストです。
   MED-V サーバーの起動後にファイルサーバーをシャットダウンしているので、サービスは起動している状態です。
    
   共有ディレクトリ上にあるポリシーのファイルが読み込めずにエラーとなります。

    
   開かれたワークスペースも以下のように空の状態です。
    

4. ファイルサーバーを起動
   上記の状態のときにファイルサーバーを再度起動させてみます。

   MED-V サーバーの再起動やサービスの再起動の必要なく接続ができるようになりました。

    

5. ファイルサーバーが停止している場合 (MED-V サーバー起動前)
   MED-V サーバー起動時にファイルサーバーが停止していた場合です。

   この場合は MED-V のサービスが起動しないですね。
   

6. ファイルサーバーを起動
   上記の状態ときにファイルサーバーを起動してみます。
   サービスは停止状態ですので、手動でサービスの起動を実施します。

   起動するかなと思ったら起動しませんでした…。
   定番のエラーが表示されていました。
   
   サーバーを再起動してもサービスは起動できませんでした。
   ファイルサーバーの [PublicKey.xml] を削除してサービスを起動してみます。

   2008R2-MDOP-01 では正常に起動しました。
   
   2008R2-MDOP-02 ではエラーとなり以前としてサービスが起動できません。
   2008R2-MDOP-01 の KeyPair.xml を 2008R2-MDOP-02 にコピーしたところ正常にサービスが起動できました。
   構築時に発生した現象が再発したみたいですね。

   ファイルサーバーが起動していない状態で MED-V を起動しただけなのですがこのような状態になるとは…。

接続関してはどちらかのサーバーが起動していれば問題はなさそうですね。
ただし、ファイルサーバーが起動していない状態で MED-V サーバーを起動した場合は修復作業が必要になりそうですが。

■接続後にサーバーがシャットダウンされた場合

サーバー接続後に接続されているサーバーがシャットダウンされた場合の挙動を確認してみたいと思います。

まずは片側のサーバーを NLB の負荷分散対象外とします。

これで 2008R2-MDOP-01 に接続がされるようになります。

この状態で MED-V クライアントで管理コンソールを起動させた後に、でサーバーの負荷分散対象を逆転させます。
 
管理コンソールは起動したままです。

 

この状態でイメージをアップロードしようとすると以下のエラーになります。
 

一度更新のボタンを押して、情報をリフレッシュすると正常にアップロードできるようになりました。

 

管理コンソールを使った冗長テストは以上で。
基本的な NLB のサーバー製品と考え方は変わらなさそうですね。
ファイルサーバーが起動していない場合の動作に関しては予想していませんでしたが…。

サーバー停止時の MED-V で実行されるアプリケーションの実行ですがこれに関してはオフライン実行と関連がありますので、
オフライン時 (サーバーと接続できない場合) の操作に関しては別途まとめていきたいと思います。

冗長化の最後として、サーバーをシャットダウンしながら冗長化のテストをしてみたいと思います。

■管理コンソールの接続

まずは管理コンソールの接続テストから。

1. 両サーバーが停止している場合
   両サーバーをシャットダウンしている状態です。
   当然ながら接続できませんね。
   
2. 片側のサーバーが起動している場合
   片側のサーバー (2008R2-MDOP-01) だけ起動してみました。

   この状態は正常に接続ができますね。

   ?

   2008R2-MDOP-02 だけが起動している状態でも正常に接続ができます。

3. ファイルサーバーが停止している場合 (MED-V サーバー起動後)
   MED-V サーバー (2008R2-MDOP-01 / 02) の起動後にファイルサーバーをシャットダウンした場合のテストです。
   MED-V サーバーの起動後にファイルサーバーをシャットダウンしているので、サービスは起動している状態です。
   ?
   共有ディレクトリ上にあるポリシーのファイルが読み込めずにエラーとなります。

   ?
   開かれたワークスペースも以下のように空の状態です。
   ?

4. ファイルサーバーを起動
   上記の状態のときにファイルサーバーを再度起動させてみます。

   MED-V サーバーの再起動やサービスの再起動の必要なく接続ができるようになりました。

   ?

5. ファイルサーバーが停止している場合 (MED-V サーバー起動前)
   MED-V サーバー起動時にファイルサーバーが停止していた場合です。

   この場合は MED-V のサービスが起動しないですね。
   

6. ファイルサーバーを起動
   上記の状態ときにファイルサーバーを起動してみます。
   サービスは停止状態ですので、手動でサービスの起動を実施します。

   起動するかなと思ったら起動しませんでした…。
   定番のエラーが表示されていました。
   
   サーバーを再起動してもサービスは起動できませんでした。
   ファイルサーバーの [PublicKey.xml] を削除してサービスを起動してみます。

   2008R2-MDOP-01 では正常に起動しました。
   
   2008R2-MDOP-02 ではエラーとなり以前としてサービスが起動できません。
   2008R2-MDOP-01 の KeyPair.xml を 2008R2-MDOP-02 にコピーしたところ正常にサービスが起動できました。
   構築時に発生した現象が再発したみたいですね。

   ファイルサーバーが起動していない状態で MED-V を起動しただけなのですがこのような状態になるとは…。

接続関してはどちらかのサーバーが起動していれば問題はなさそうですね。
ただし、ファイルサーバーが起動していない状態で MED-V サーバーを起動した場合は修復作業が必要になりそうですが。

■接続後にサーバーがシャットダウンされた場合

サーバー接続後に接続されているサーバーがシャットダウンされた場合の挙動を確認してみたいと思います。

まずは片側のサーバーを NLB の負荷分散対象外とします。

これで 2008R2-MDOP-01 に接続がされるようになります。

この状態で MED-V クライアントで管理コンソールを起動させた後に、でサーバーの負荷分散対象を逆転させます。
?
管理コンソールは起動したままです。

?

この状態でイメージをアップロードしようとすると以下のエラーになります。
?

一度更新のボタンを押して、情報をリフレッシュすると正常にアップロードできるようになりました。

?

管理コンソールを使った冗長テストは以上で。
基本的な NLB のサーバー製品と考え方は変わらなさそうですね。
ファイルサーバーが起動していない場合の動作に関しては予想していませんでしたが…。

サーバー停止時の MED-V で実行されるアプリケーションの実行ですがこれに関してはオフライン実行と関連がありますので、
オフライン時 (サーバーと接続できない場合) の操作に関しては別途まとめていきたいと思います。

前回の投稿で構成ファイルを共有ディレクトリに配置するところまでができました。
これでワークスペース関連の情報に関しては各サーバーで共有することができますが、MED-V から配信するゲスト OS の
イメージファイルはまだ、各サーバーのローカルに配置されています。

今度は IIS の設定を変更して、ゲスト OS のイメージファイルを共有ディレクトリ上に配置したいと思います。

■UNC 共有の設定

現在 IIS に設定している MED-V 用のイメージ展開のパスは以下の用になっています。

[物理パス] がローカルドライブになっていますので、これをファイルサーバーに変更します。

1. 設定を開く
   IIS マネージャでローカルに設定していた仮想ディレクトリを右クリックし、[仮想ディレクトリの管理] → [詳細設定] を
   クリックします。
   
2. 物理パスの変更
   ローカルドライブになっている物理ドライブを共有ディレクトリに変更します。
   
3. 共有ディレクトリの接続ユーザーの設定
   IIS で UNC 共有を使用したマッピングを行う場合は、その共有ディレクトリへの接続に使用するユーザーを
   仮想ディレクトリ単位で設定することができます。

   [物理パス資格情報] の […] をクリックすると接続に使用するユーザーを指定できます。
    

   今回はドメインユーザーを作成して、ファイルサーバーの共有ディレクトリにアクセス許可を設定しています。
   # ユーザー名は [ドメイン名ユーザー名] の形式で指定します。
   ワークグループ環境の場合は全サーバーで同一ユーザー名 / 同一パスワードのユーザーを作成してミラーアカウントで
   接続を行う必要があります。
    
    

4. BITS の設定
   この設定が微妙なのですが…。
   ログインして IIS マネージャを操作しているユーザーが共有ディレクトリにアクセスができるのであれば問題ありません。
   通常の設定通り、BITS を有効にすれば OK です。

   ただし、ログインしているユーザーが共有ディレクトリにアクセスできない場合はまず、IIS マネージャで仮想ディレクトリを
   開くことができません。
   
   BITS を有効にしようとしても以下のエラーになります。
   
   ひとまず、ネットワークドライブの割り当てで、仮想ディレクトリのマッピングで使用しているユーザーで
   セッションを確立しておきます。
   # [NET USE] コマンドでも大丈夫です。
    
   そうするとエラーの内容が変わります。
   

   [SeSecurityPrivilege] 特権は [監査とセキュリティ ログの管理] の権限だと思ったのですが、既定ではこの権限は
   [Administrators] グループのユーザーにしか付与されていません。
   
   今回は [Domain Users] グループである [MEDV User] を仮想ディレクトリの接続のユーザーに使用しているので
   このユーザーに上記の権限を [ローカル セキュリティ ポリシー] を使用して [ファイルサーバー] に設定します。
   # 今回だと 2008R2-MDOP-03 のローカルセキュリティポリシーに設定します。

   設定が終わったら念のため再起動して、再度ネットワークドライブのセッシ
   ョンを確立してから BITS を有効にします。

IIS の設定は以上で終了です。
両サーバーで操作を実施して、仮想ディレクトリは共有を使用するように設定します。

■MED-V サーバーの設定変更

サーバー側の最後の作業として、設定の変更を実施します。

設定変更は、[MED-V Server Configuration Manager] を使用して実施します。

デフォルトの状態ではローカルのドライブを使用してインストールをしていますので、設定もローカル環境が基準となっています。

これを NLB と共有ディレクトリに変更します。
# NLB の仮想ホスト名は DNS に登録済みです。

変更後はサービスの再起動が必要となります。
[Yes] をクリックしてサービスを再起動します。

クリック後に以下のメッセージが表示された場合は、共有ディレクトリの [PublicKey.xml] の現象が再発しているので
再度ファイルサーバー上の [PublicKey.xml] を削除します。

今回設定した内容がローカルの [ServerSettings.xml] に保存されています。
 

TechNet のクラスターモードの構築方法に書かれていた最後の手順である [ServerSettings.xml] のコピーを実施します。
今回は [2008R2-MDOP-01] → [2008R2-MDOP-02] にファイルをコピーします。

コピー後に 2008R2-MDOP-02 でサービスの再起動をします。
残念ながら、再起動できませんでした…。
 

設定を更新したタイミングで、[KeyPair.xml] ファイルが書き変わっていたようです。
このファイルも [2008R2-MDOP-01] → [2008R2-MDOP-02] にコピーします。

これで設定完了です。
サーバー再起動してサービスが正常に起動していることを確認します。

■MED-V クライアントの設定変更

今まではクライアントは 2008R2-MDOP-01 に接続をしていましたのでそれを NLB の仮想ホストに変更します。

通知領域の MED-V のアイコンを右クリックして [Settings] をクリックします。

[Server address] を NLB の仮想ホスト名に変更して、[OK] をクリックします。

これでようやくクラスターモードの構築は完了です。

 

 

完成した環境がこちら。

一部の設定 (展開先情報) は MED-V サーバー上にも残りますが仮想環境展開に関する情報がファイルサーバーに集約されます。

作った環境のテストはその 3 で投稿したいと思います。

前回の投稿で構成ファイルを共有ディレクトリに配置するところまでができました。
これでワークスペース関連の情報に関しては各サーバーで共有することができますが、MED-V から配信するゲスト OS の
イメージファイルはまだ、各サーバーのローカルに配置されています。

今度は IIS の設定を変更して、ゲスト OS のイメージファイルを共有ディレクトリ上に配置したいと思います。

■UNC 共有の設定

現在 IIS に設定している MED-V 用のイメージ展開のパスは以下の用になっています。

[物理パス] がローカルドライブになっていますので、これをファイルサーバーに変更します。

1. 設定を開く
   IIS マネージャでローカルに設定していた仮想ディレクトリを右クリックし、[仮想ディレクトリの管理] → [詳細設定] を
   クリックします。
   
2. 物理パスの変更
   ローカルドライブになっている物理ドライブを共有ディレクトリに変更します。
   
3. 共有ディレクトリの接続ユーザーの設定
   IIS で UNC 共有を使用したマッピングを行う場合は、その共有ディレクトリへの接続に使用するユーザーを
   仮想ディレクトリ単位で設定することができます。

   [物理パス資格情報] の […] をクリックすると接続に使用するユーザーを指定できます。
   ?

   今回はドメインユーザーを作成して、ファイルサーバーの共有ディレクトリにアクセス許可を設定しています。
   # ユーザー名は [ドメイン名ユーザー名] の形式で指定します。
   ワークグループ環境の場合は全サーバーで同一ユーザー名 / 同一パスワードのユーザーを作成してミラーアカウントで
   接続を行う必要があります。
   ?
   ?

4. BITS の設定
   この設定が微妙なのですが…。
   ログインして IIS マネージャを操作しているユーザーが共有ディレクトリにアクセスができるのであれば問題ありません。
   通常の設定通り、BITS を有効にすれば OK です。

   ただし、ログインしているユーザーが共有ディレクトリにアクセスできない場合はまず、IIS マネージャで仮想ディレクトリを
   開くことができません。
   
   BITS を有効にしようとしても以下のエラーになります。
   
   ひとまず、ネットワークドライブの割り当てで、仮想ディレクトリのマッピングで使用しているユーザーで
   セッションを確立しておきます。
   # [NET USE] コマンドでも大丈夫です。
   ?
   そうするとエラーの内容が変わります。
   

   [SeSecurityPrivilege] 特権は [監査とセキュリティ ログの管理] の権限だと思ったのですが、既定ではこの権限は
   [Administrators] グループのユーザーにしか付与されていません。
   
   今回は [Domain Users] グループである [MEDV User] を仮想ディレクトリの接続のユーザーに使用しているので
   このユーザーに上記の権限を [ローカル セキュリティ ポリシー] を使用して [ファイルサーバー] に設定します。
   # 今回だと 2008R2-MDOP-03 のローカルセキュリティポリシーに設定します。

   設定が終わったら念のため再起動して、再度ネットワークドライブのセッシ
   ョンを確立してから BITS を有効にします。

IIS の設定は以上で終了です。
両サーバーで操作を実施して、仮想ディレクトリは共有を使用するように設定します。

■MED-V サーバーの設定変更

サーバー側の最後の作業として、設定の変更を実施します。

設定変更は、[MED-V Server Configuration Manager] を使用して実施します。

デフォルトの状態ではローカルのドライブを使用してインストールをしていますので、設定もローカル環境が基準となっています。

これを NLB と共有ディレクトリに変更します。
# NLB の仮想ホスト名は DNS に登録済みです。

変更後はサービスの再起動が必要となります。
[Yes] をクリックしてサービスを再起動します。

クリック後に以下のメッセージが表示された場合は、共有ディレクトリの [PublicKey.xml] の現象が再発しているので
再度ファイルサーバー上の [PublicKey.xml] を削除します。

今回設定した内容がローカルの [ServerSettings.xml] に保存されています。
?

TechNet のクラスターモードの構築方法に書かれていた最後の手順である [ServerSettings.xml] のコピーを実施します。
今回は [2008R2-MDOP-01] → [2008R2-MDOP-02] にファイルをコピーします。

コピー後に 2008R2-MDOP-02 でサービスの再起動をします。
残念ながら、再起動できませんでした…。
?

設定を更新したタイミングで、[KeyPair.xml] ファイルが書き変わっていたようです。
このファイルも [2008R2-MDOP-01] → [2008R2-MDOP-02] にコピーします。

これで設定完了です。
サーバー再起動してサービスが正常に起動していることを確認します。

■MED-V クライアントの設定変更

今まではクライアントは 2008R2-MDOP-01 に接続をしていましたのでそれを NLB の仮想ホストに変更します。

通知領域の MED-V のアイコンを右クリックして [Settings] をクリックします。

[Server address] を NLB の仮想ホスト名に変更して、[OK] をクリックします。

これでようやくクラスターモードの構築は完了です。

?

?

完成した環境がこちら。

一部の設定 (展開先情報) は MED-V サーバー上にも残りますが仮想環境展開に関する情報がファイルサーバーに集約されます。

作った環境のテストはその 3 で投稿したいと思います。

ここ数日は通勤時間や、帰宅してから MED-V のクラスターモードの構築について調べていました。
本日ようやく一通り使えそうな環境まで設定することができました。
最初は構成ファイルの冗長化の手順を。

MED-V の冗長化にはクラスターモードという設定が使われます。
このクラスターモードですがクラスターとついていますが、実際には NLB と共有フォルダで冗長化された構成になります。

以前の投稿にも記載しましたが、基本的な設定方法は以下の URL に記載されています。
Configuring the MED-V Server in Cluster Mode

実は MED-V 日本語のドキュメントもあったりします。
展開、 操作ガイド

こちらのガイドにもクラスターモードについて記載されています。

ただし、上記のガイドに記載されている方法では私はクラスターモードは構築できませんでした。
# これが原因でなかなかクラスターモードについて投稿ができませんでした。

■クラスターモードにする前の構成

まずは NLB を設定した MED-V の 2 ノード構成の環境を用意します。
今回は以下の構成です。
2 台のサーバーそれぞれに MED-V をインストールして、NLB を組んでいます。
現時点では MED-V の設定は各ローカルサーバー上に保持しています。
クラスターモードを構築するためのファイルサーバーはこの時点では共有ディレクトリを持っているだけです。

MED-V はドメイン環境が必須でないため、上記環境はワークグループ環境でも構成可能です。
クラスターモードをワークグループ環境で構築することも可能です。

今回はワークグループ環境の設定も交えながら記載していきたいと思います。
最終的な環境はドメイン環境で。

■クラスターモードを設定 (構成ファイル)

それではいよいよクラスターモードを設定していきたいと思います。

1. 共有ディレクトリを作成
   まずはファイルサーバー 2008R2-MDOP-03 に共有ディレクトリを作成します。
   必要となるディレクトリは以下の 2 種類です。
   # 厳密には分ける必要はありませんが管理上良さそうなので。

   –  構成ファイル保存用ディレクトリ
   – 展開イメージ保存用ディレクトリ

   今回は、C ドライブの下に [MED-V] というディレクトリを作成しその配下に、[Config] / [Images] というディレクトリを
   作成しています。
    

   ディレクトリの準備が終わったら、C ドライブ直下の [MED-V] ディレクトリに共有設定を行います。
   共有設定はドメインかワークグループかによって設定が異なります。

   [ドメイン環境の場合]
   ドメイン環境の場合は、アクセス許可にコンピュータアカウントを使用することができます。
   そのため、共有とフォルダのアクセス許可を以下のように設定します。
    
   – 共有のアクセス許可 –

   
   – フォルダのアクセス許可 –

   各、コンピュータアカウントにはフルコントロールを許可しておきます。

   [ワークグループ環境の場合]
   ワークグループ環境の場合は、コンピュータアカウントを使用することができません。
   そのため各 MED-V サーバーの設定変更が必要となります。

   通常 MED-V のサービスは、[ローカル システム アカウント] で起動されています。
   

   MED-V のサービスが起動したときに共有ディレクトリ上に構成ファイルを保存している場合、サービスの起動アカウントで、
   共有ディレクトリに接続を試みます。
   ドメイン環境であればコンピュータアカウントでの接続が可能なため、ローカル システム アカウントで起動していても
   最終的にはコンピュータアカウントの権限を使用して接続がされるのですが、ワークグループではコンピュータアカウントを
   使用したアクセス許可が設定できないため、構成を変更した後にサービスが起動できなくなります。

   そこでミラーアカウントを使用して共有ディレクトリに接続を行います。

   具体的には、サービスの起動アカウントをローカルユーザーに変更し、同一のユーザー名 /  パスワードのユーザーを
   ファイルサーバーにも作成して、共有ディレクトリとフォルダに対してフルコントロールを付与します。

   たとえば、2008R2-MDOP-01 / 02 の MEDV Server サービスの起動アカウントを [Administrator] に変更します。
   # 両サーバーで Administrator のパスワードは同一です。
   

   そして、ファイルサーバーである 2008R2-MDOP-03 の Administrator のパスワードも 2008R2-MDOP-01 / 02 と
   同一に設定し、共有とフォルダのアクセス権を以下の用に設定します。

   
   – 共有のアクセス許可 –

    
   – フォルダのアクセス許可 –
   

2. 構成ファイルを共有ディレクトリにコピー
   MED-V の構成ファイルを共有ディレクトリにコピーします。
   今回は初期のマスターは 2008R2-MDOP-01 としています。

   2008R2-MDOP-01 の [C:Program FilesMicrosoft Enterprise Desktop VirtualizationConfigurationServer]ディレクトリを
   2008R2-MDOP-03 の [2008R2-MDOP-01MED-VConfig] にコピーします。
   共有フォルダにアクセスができない場合は一時的に、共有フォルダに書き込みができるユーザーを用意してアクセス権を設定し、
   そのユーザーを使用して共有ディレクトリにファイルをコピーします。
   # ファイルコピー後はアクセス権を削除しておきます。
   　 コンピュータアカウントのアクセス許可だとファイル名を指定して実行から接続できないかもしれません。

   
   – コピー元-

   
   – コピー先 –

3. 構成ファイルの変更
   共有ディレクトリの構成ファイルを使用するように、2008R2-MDOP-01 / 02 の[ServerConfiguration.xml] を変更します。
   このファイルは、上記の手順でコピーした [ConfigurationServer] ディレクトリと同一のディレクトリ内にあります。

    
   このファイルをテキストエディタで開きます。

   このファイル内の [<StorePath>] を以下のように変更します。

    

4. KeyPair.xml ファイルのコピー
   先ほど操作したファイルと同一のディレクトリ内に [KeyPair.xml] というファイルが存在しています。
   このファイルを 2008R2-MDOP-01 から 2008R2-MDOP-02 にコピーし上書きします。
   
5. サービスの再起動
   これで TechNet に掲載されている手順は完了です。
   # ServerSettings.xml はその 2 で同期しようと思っていますので今回は作業はパスします。
   手順に従って MED-V のサービスを再起動します。
   

   きっとこの手順では再起動時にエラーになります。
    

   イベントビューアの [アプリケーション] をみるとこのようなエラーが。
   

   この現象を解決するのに手間取りました…。
   # この現象の解決にインシデントを使おうとしたところ、現状の MED-V のサポートが英語版の Windows 2008 だけだと
   　 教えていただきました。

   また、共有ディレクトリへのアクセス権が正しくないと以下のエラーになります。
   

6. 共有ディレクトリの [PublicKey.xml] の削除
   上記のエラーは共有ディレクトリの [PublicKey.xml] が影響して発生しているようでした。
   
   一度共有ディレクトリの [PublicKey.xml] を削除します。

   もう一度サービスを起動してみると今回は正常に起動します。
   # サービスは両サーバーで再起動します。
   

   サービスの起動時に共有ディレクトリの [PublicKey.xml] と [ClientSettings.xml] の 2 ファイルを読み込んでいるようです。
   [PublicKey.xml] はサーバーのローカルフォルダにも存在しており、構成ファイル用のディレクトリのものと整合性が取れていないと
   いけないのかもしれないですね。
   構成ファイルの場所を変更した場合は、構成ファイルのディレクトリの [PublicKey.xml] を一度削除しないと同様の
   現象が発生してしまう気がしています。
   # [KeyPair.xml] を各 MED-V サーバーで同一のものを使用しているので、このファイルも関係しているのかと。

長くなってきましたのでその 1 はここまでで。
その 2 でイメージ展開用の IIS の設定を投稿したいと思います。

今日、業務で Exchange 2010 の Exchange Management Console を使っていてはじめて気付きました。

Exchange 2007 の Exchange 管理コンソールでもメールボックスの新規作成や、移動などの操作では、操作内容の
PowerShell が出力される機能が付いていました。
Exchange 2010 でも引き続き一部の操作では PowerShell が表示されます。

それとは別に PowerShell を表示する機能が Exchange 2010 に存在していたんですね。

■変更箇所の PowerShell の生成機能

Exchange 2010 の設定をしていたところ左下に見慣れないアイコンが。

このアイコンです。

普段はグレーアウトしているのですが設定を変更すると色がつきます。
# 適用ボタンが押せるタイミングと一緒に変わっているみたいです。

何だろうと押してみたらこんなダイアログが。

変更した部分の管理シェルを生成してくれる機能のようです。

Exchange 2010 は Beta のときから少しずつは触っていたのですが今まで気づきませんでした…。