冗長化構成の最後としてセルフサービスポータルの冗長化を。
セルフサービスポータルは Web サーバーですので NLB で冗長化が可能です。

■使用した環境

今回使用する環境は前回の環境のフロントとして、NLB 構成のセルフサービスポータルを追加します。

私の検証環境は TMG 2010 が構築してあるので、NLB 構成とは別にサーバーファーム構成でセルフサービスポータルを
冗長構成する構成も作ってみたいと思います。

TMG 2010 だと以下の構成になります。
 

TMG 2010 の環境は HTTPS のリスナが設定されているので、HTTPS で受けて内部的には HTTP で通信する構成にしています。

■セルフサービスポータルのインストール

セルフサービスポータルのインストールでは冗長構成の設定はありません。
セルフサービスポータルと SCVMM サーバーを分割してインストールする時と同じ方法で構築します。

[Virtual Machine Manager サーバー] に VMM サーバーの役割をインストールしているサーバーを指定します。
TMG 2010 のサーバーファームを使う際にホストヘッダーが必要になるので、適当なヘッダー名を指定しています。

VMM サーバーのファイアウォールに関しては VMM サーバーインストール時に 8100 に対してアクセス許可を自動的に
設定しているようなので、明示的に設定をする必要はないようです。

 

■NLB の設定

NLB の設定も通常の Web サーバーの NLB 設定と同じです。
NLB は DHCP による IP 割り当てでは設定ができませんので適当な固定 IP を割り当ててから作業をします。

[ネットワーク負荷分散] の機能をセルフサービスポータルの各サーバーに追加します。

今回は Hyper-V 上に構築しているので [MAC アドレスのスプーフィングを有効にする] も忘れずに。

IP は塗りつぶしていますが、できた環境がこちらです。
03 / 04 の 2 台構成で NLB を設定しています。

インストール時に指定したホストヘッダーでアクセスし、正常にセルフサービスポータルが表示されています。
HTTP 経由のアクセスなので、警告文が表示されていますね。
 

セルフサービスポータルも正常に使用できます。

通常の NLB 設定と同じなので特有の設定はありませんでした。

■冗長構成のテスト

片側の NLB を停止させながら冗長構成のテストをします。

両方が停止している状態はエラーとなりますが、片側が生きていれば正常にアクセスができる状態となっています。

■TMG 2010 で冗長化

TMG 2010 ではサーバーファームという機能があります。(ISA 2006 でもあります。)
# Web サーバー側で冗長構成を設定しなくても TMG 側で冗長構成を設定できる機能です。

  
サーバーファームとして冗長構成をしたいサーバーの IP または コンピュータ名を指定します。

サーバーファームには [接続検証] とい機能があり、NLB とは異なり死活監視で HTTP アクセスが可能かを調べることができます。
NLB の冗長化では、サーバーが生きていて IIS が死んでいる場合でも負荷分散対象となり、要求が振られたはずですが、
サーバーファームでは HTTP アクセスができない (IIS が死んでいる) 場合は負荷分散対象外とすることができます。

後はこのサーバーファームを使用する [Web 公開ルール] を作成すると TMG 経由で公開することができます。

TMG のルールでは [内部サイト名] を入力する必要があります。
各 セルフサービスポータルには内部サイト名でアクセスがされますので、インストール時に指定したホスト ヘッダーの値を設定します。

設定を進めると使用するサーバーファームを選択する画面になります。
ここで先ほど作成したサーバーファームを選択します。

あとはウィザードを進めてルールの作成を完了させます。

TMG 2010 はインターネット経由でアクセスできる環境にしてあるので、外部からアクセスしてみます。
 

外部からは HTTPS でアクセスしているのですが、セルフサービスポータルでは HTTP で受けているので、
NLB のテストの時と同様警告が表示されています。
セルフサービスポータルを HTTPS で構成しないと警告を消せないみたいですね。

あとはインターネット経由の場合はセルフサービスポータルでコンソールが開けませんでした。
接続する際にホスト OS を DNS で解決できる必要があるようで、エラーとなってしまいました。
 

セルフサービスポータルはイントラネット向けなのでしょうか…。
この辺は要調査です。

 

VMM サーバー / データベースサーバー / セルフサービスポータルの 3 回に分けて冗長構成を実験してみました。
データベースサーバーとセルフサービスポータルの冗長化は一般的な手法で構成できますが、VMM サーバーの冗長化だけ、
これといった案が導き出せませんでした。

SCVMM を複数台構成にするとなかなか奥が深いものですね。

SCVMM 冗長構成第 2 弾としてデータベースの冗長化について。
クラスタは通常のインスタンスと変わらないので、今回はミラーリングされているデータベースを使用する実験を。

?

■使用した環境

今回は以下の構成を使用しています。

SCVMM サーバーは前回使用した SQL Server のクライアントコンポーネントをインストールした環境を。

データベースに関してはミラーリングした SQL Server 2008 R2 Nov CTP を 3 台用意して、自動フェールオーバーの
ミラーリングの設定をしています。

■接続設定の変更

SCVMM サーバーは前回の環境を使用しているので参照先データベースの設定が前回の状態となっています。
まずはデータベースの参照先の設定変更が必要となります。

SCVMM の管理コンソールに [データベース接続] という管理項目があるのですが、この項目で確認できるデータベースの
接続先の情報は読み取り専用のため、変更することができません。

?
?
接続先データベースの変更はレジストリを修正する必要があります。
# データベースに接続できないと管理コンソール開けないはずですので、レジストリを修正する形になっているのかと。

レジストリの修正箇所に関しては前回の投稿で書いた場所になるのですが、試してみたところ少し情報が足りなさそうでしたので、
今回の投稿でまとめてみました。

TechNet では以下の情報でデータベースの変更について記載されています。
VMM 2008 用 SQL Server のリモート インスタンスの構成

コマンドラインからのセットアップの情報も参考になりそうです。
コマンド ラインからの VMM コンポーネントのインストール

データベースの接続関連の設定は以下のキーに格納されています。

レジストリのキー

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft System Center Virtual Machine Manager ServerSettingsSql

?

正式な情報が見つからなかったので、今回の検証の結果からの内容になりますが各設定項目は以下のようになっているようです。

名前	種類	設定値
ConnectionString	REG_SZ	SCVMM で使用するデータベースの接続文字列
CreateNewInstance	REG_DWORD	0:既定のインスタンスを使用 1:SQL Server Express を使用してローカルにインスタンスを作成 セットアップ時の選択内容が設定されているようです。
DatabaseName	REG_SZ	接続先のデータベース名
InstanceName	REG_SZ	接続先のインスタンス名 ブランクの時は既定のインスタンスが使用されるようです。
MachineFQN	REG_SZ	接続先のデータベースサーバーの FQN ここに設定されている内容が SVMM の管理コンソール表示されます。 ロカールインスタンスを使用するようにセットアップをした場合は この項目は存在しません。 接続で使用されるのは [ConnectionString] の設定なのでこの項目は ラベル的な意味合いかもしれないです。
MachineName	REG_SZ	接続先のデータベースサーバーのサーバー名 ロカールインスタンスを使用するようにセットアップをした場合は この項目は存在しません。 接続で使用されるのは [ConnectionString] の設定なのでこの項目は ラベル的な意味合いかもしれないです。
OnRemoteServer	REG_SZ	0:ローカルインスタンスを使用 1:リモートインスタンスを使用

?

今回はミラーリング環境ですので、[ConnectionString] をミラーリング用に変更する必要があります。
接続先のサーバーを指定する部分を以下のように変更します。

[変更前] Server=データベースサーバー名 [変更後] Server=プリンシパルサーバー名;Failover Partner=ミラーサーバー名 [設定例] Server=2008R2-DBM-01;Failover Partner=2008R2-DBM-02

今まで、ローカルサーバーを使用していた場合は、[OnRemoteServer] の値も [1] に変更しておきます。

?

■接続先のデータベースに必要となる権限

SCVMM サーバーはデータベースサーバーの [sysadmin] 権限が必要となます。

SCVMM サーバー → データベースサーバーの接続に使用されるログインアカウントですが、

• [Virtual Machine Manager] サービスをローカルシステムアカウントで実行している場合
  コンピュータアカウントで接続
• [Virtual Machine Manager] サービスを任意のユーザーアカウントで実行している場合
  サービスの起動アカウントで接続

となりますのでサービスの実行アカウントの設定状態によって変更する必要があります。

コンピュータアカウントを SQL Server のログインとして設定する場合ですが、SQL Server Management Studio (SSMS) の
GUI を使用して設定ができなかったので、SQL を実行してログインを追加する必要がありました。

SSMS からだとオブジェクトの種類で [コンピュータ] が選択できないんですよね。
$ 付きでコンピュータアカウントを指定しても検索ができなかったので SQL で追加してしまいました。

以下はコンピュータアカウントのログインを作成するための SQL の一例です。

USE [master] GO — コンピュータアカウントのログインを作成 CREATE LOGIN [<ドメイン名><SCVMM サーバー名>$] FROM WINDOWS WITH DEFAULT DATABASE = [<SCVMM で使用するデータベース名] GO — 作成したログインに [sysadmin] 権限を付与 EXEC [master]..[sp_addsrvrolemember] @loginname=N’<ドメイン名><SCVMM サーバー名>$’, @rolename = N’sysadmin’ GO

?

■設定の反映

これでミラーリングされたデータベースを使用する準備は完了です。

[Virtual Machine Manager] サービスを再起動し、設定内容を反映させます。

再起動後に開始できないようでしたらレジストリの設定値が間違っている可能性があります。
# データベースに接続ができなくてもサービスは起動します。
開始できない場合はスペルミスがないか見直した方がよいかと思います。

?

■テストの実施

プリンシパルサーバーのサービスの停止または、手動フェールオーバーでデータベースをプリンシパル → ミラーに
フェールオーバーさせてテストを実施します。
?
?

SCVMM サーバーのデータベースの参照状態に依存するとは思うのですが、フェールオーバー中に必ず切断されるということは
ありませんでした。
# フェールオーバー時の復旧に時間がかかると切断されてしまうことがありましたが。

100% 接続を維持できるということはミラーリングの使用上難しい (アプリケーション側の再接続のロジックとの兼ね合い) ですが、
フェールオーバークラスタより、フェールオーバー時の停止時間は短いと思います。

残るはセルフサービスポータルの冗長化ですね。
これは今から検証環境を準備して次回投稿したいと思います。
# 私が普段使っている検証環境にセルフサービスポータルが入っていないことに今気付きました…。

SCVMM 2008 R2 の冗長構成はどうするのだろうと少し調べていました。

Twitter で呟いてみたところ、
– [既存の SCVMM のデータベースを別の SCVMM のデータベースに関連付けできないか]
というフォローを頂くことができました。

なるほど。面白そうな構成だな～。と思い実験してみました。

用意した環境がこちら。

現在使用している検証環境の SCVMM のデータベースを新規に構築した SCVMM も参照する構成で実験をしています。
専用 SQL Serverを用意するときれいな環境だったのですが面倒だったもので…。
# SCVMM #1 のファイアウォールで SQL Server のポートに対して着信許可を設定しています。

■SCVMM #2 のインストール

まずは上記の構成を作るために新規サーバーに SCVMM をインストールします。
インストールは通常の方法と変わらないのですが、SCVMM で使用するデータベースを新規データベースではなく、
既存のデータベースに設定します。

# サーバー名とインスタンス名は塗りつぶしていますが、図の [SCVMM #1] を指定しています。

無事にインストール完了です。

最初試したところ、ロックされているジョブがありますといったエラーが表示されインストールできないことがありました。
その場合は、SCVMM 用のデータベースの [dbo].[tbl_VMM_Lock] テーブルの内容を削除するとインストールができました。
# 実験なので問答無用で上記のテーブルを Truncate してしまいました。

■ホスト OS のグループにコンピュータアカウントを追加

通常はインストールが終了したら、各ホスト OS にエージェントをインストールします。
今回は各ホスト OS は SCVMM #1 で管理されているのでエージェントの再導入は避けたいです。

そこで、ホスト OS の以下のローカルグループにコンピュータアカウントを手動で追加します。

• Administrators
• Virtual Machine Manager Servers

これらのグループに SCVMM のコンピュータアカウントを追加しないと SCVMM 上でホスト OS の状態を取得できず、
仮想環境の管理をすることができません。

?

構築し終わった環境がこちら。

左が [SCVMM #1]、右が [SCVMM #2] になります。

同一のデータベースを参照しているのでバーチャルマシンの登録状況は一緒ですね。
SCVMM #2 のジョブでエラーが結構出力されているのと、両方の SCVMM サーバーのサービスが起動していると
管理コンソールが切断されることが多くなっているのが気になります。
# 私の SCVMM の環境は管理コンソールが切断されることがしばしばあるのですが、両サーバーを起動していると
　 切断される頻度が高くなった気がします。
コールドスタンバイ環境とするのであれば実用的かも。

PRO 機能との連携もどうなるのか気になるところですね。

SCVMM のバックアップはデータベースがきちんと取得できていれば再構築はさほど面倒ではないので、
サーバー冗長化ではなく、バックアップ + 再構築の手順を確立することで障害発生時に備えるという考えでも
いいのかもしれないですね。

予備機を作っておいて、以下のレジストリを変更し参照先 DB を変更してからエージェント再導入といった考えもあるかも。
VMM 2008 用 SQL Server のリモート インスタンスの構成

Exchange 2007 ではメールボックスの復旧をする際に使用する [回復ストレージグループ] を EMC の
[データベース回復管理] から作成することが可能でした。

Exchange 2010 では、[データベース回復管理] がなくなっています。

また、Exchange 2010 ではストレージグループがなくなっていますので、[回復ストレージグループ] ではなく、
[回復用データベース] となっています。

回復用データベースの使用は、EMC からではなく、EMS を使用してコマンドでデータベースの作成を行います。
New-MailboxDatabase

回復用データベースを使用したメールボックス回復の一連の作業としては、

New-MailboxDatabase ?Recovery ?EdbFilePath “<EDB ファイルパス>” ?LogFolderPath “<ログフォルダパス>” ?Server “<サーバー名>” ?Name “<回復用データベース名>” ESEUTIL /R データベースの識別子 /d”<EDB フォルダパス>” /l"<ログフォルダパス>” Mount-Database “<回復用データベース名>” Restore-Mailbox ?Identity “<対象のユーザー>” ?RecoveryDatabase “<回復用データベース名>” Dismount-Database “<回復用データベース名>” Remove-MailboxDatabase “<回復用データベース名>”

というようにコマンドベースで回復を行っていきます。

サードパーティーのバックアップソフトを使わなくてもOS 標準の Windows Server バックアップ + 回復用データベースで
ある程度は復旧ができますよね。

一度メモを残しておくと便利そうでしたので投稿しておきたいと思います。

Exchange Server 2007 では Standard Edition ではクラスタを使用することができませんでした。
Exchange Server 2007 のエディションおよびクライアント アクセス ライセンス

そのため、Standard Editoin では [シングル コピー クラスタ] と [クラスタ連続レプリケーション] はサポートなしとなっています。

クラスタの構成がされている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定すると、
以下のエラーが発生し、プロダクトキーを確定することができません。

Exchange Server 2010 の場合はエディションによる機能比較は以下の情報ぐらいしか見当たりませんでした。
Exchange 2010: Editions and Versions

Exchange 2010 でも作成できるメールボックスデータベース数には差があるのですが、機能面に関しては特に言及されていません。
試しに DAG が設定されている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定してみました。

Exchange 2010 では Standard Edition で DAG (クラスタ構成の Exchange) を構成することが可能です。
# 海外のブログで Standard Edition + DAG について書かれているものがいくつかあります。

機能面に関しては、Standard CAL または Enterprise CAL のどちらを使用するかで変わるようですね。
Exchange Server 2010 Standard Edition + Enterprise CAL という組み合わせもできたはずです。
この辺の情報はパートナー向けの Exchange 2010 の販売ガイドが記載されています。

Windows Server 2008 R2 Enterprise Edition + Exchange Server 2010 Standard Edition で冗長構成を持った
メールボックスサーバーが構築できるのはコストを抑えられて良いですね。

Exchange 2010 で承認済みドメインを変更しながら、メールフローの確認をしていました。
[電子メールアドレスポリシー] の [Default Policy] で設定されている承認済みドメインを [外部の中継ドメイン] に
変更しようとしたところ、以下のエラーが発生しました。

電子メールアドレスポリシーで設定されているドメインに関しては、[外部の中継ドメイン] に設定できないようでしたので、
[Default Policy] から該当のドメインを削除しようとしたところ、以下のエラーが発生してしまい EMS からは変更できませんでした。

既定の電子メール アドレス ポリシーでは、この操作を実行できません。

既定の電子メール アドレス ポリシーは EMC ではなく EMS (Exchange Management Shell) で変更する必要があります。
既定の電子メール アドレス ポリシーでは、[-EnabledEmailAddressTemplates] と [-Identity] 以外は指定できないのが原因のようです。

EMS で以下のようなコマンドを実行することで既定の電子メール アドレス ポリシーを変更することが可能です。

set-EmailAddressPolicy ?EnabledEmailAddressTemplates ‘<メールアドレス>’ ?Identity ‘Default Policy’

Exchange 2007 で既定の電子メール アドレス ポリシーを設定し、Exchange 2010 に移行していたため、ポリシーを
操作する機会がなく、今までエラーが発生することに気づきませんでした。

ISA 2006 でも同じだと思います。

検証環境の Exchange Server 2010 の OWA は TMG 2010 の後ろに配置しています。
帰宅の電車の中で時間があったので、Outlook Anywhere を設定しようとしていたのですが、プロファイル設定時に
サーバーに接続することができませんでした。

TMG 2010 のログを確認していたところ、OWA 用のアクセスルールで賄えていないパスに対してアクセスされていました。

そういえば、Outlook Anywhere は [/rpc] に対してアクセスできる必要がありましたね。
Outlook Anywhere での ISA Server の使用

私が使用していたルールでは以下のパスしか設定されていませんでした。

なんでだろうと考えていたところ、作成するときに使用していたのが、[Outlook Web Access] だったからのようでした。
[Outlook Anywhere (RPC/HTTP)] でルールを作成すると Outlook Anywhere 用に [rpc] が設定されているルールが作成されました。

[Outlook Web Access] 用のルールに [/rpc/*] のパスを追加することで、TMG 2010 経由で Outlook Anywhere を
使用することができるようになりました。

最近は SQL Server ではなく、Exchange Server の引き合いに関わることが多くなってきました。
昔、話題に上がることのあった、Exchange のストレージエンジンの SQL Server への変更が行われるのであれば、
Exchange Server に携わることで SQL Server のスキルアップもできて一挙両得なんですけどね。
実際に、ESE が SQL Server に変わる日は来るのでしょうかね～。

Exchange Server 2007 ではメッセージの配信状況を確認する際に、[追跡ログ エクスプローラー] を使用していました。
Exchange Server 2010 でも引き続き追跡ログ エクスプローラーが提供されています。

しかし、エッジト ランスポートサーバーで追跡ログ エクスプローラーを使用しようとすると以下の画面のエラーとなります。
# ハブ トランスポートでは発生しません。

?

Exchange 2010 でこの現象が発生するのは知っていたのですが、今まで原因を調べていませんでした。
今日、時間があったので少し調べてみたところ技術情報が掲載されていました。

アシスタントの Exchange トラブルシューティング ツールは、Exchange Server 2010 エッジ サーバー上でメッセージ追跡用のタスクが動作しません。

Exchange 2010 の不具合のようですね。
現状は [Get-MessageTrackingLog] コマンドレットで追跡ログを確認するしかないようです。

SP1 で修正されるようですが、最近 RU1 が提供されたばかりですので修正はもう少し先になるのでは。

検証用に Exchange 2007 のクラスタ環境を作成しようと思い、ドメインコントローラーを Windows Server 2008 R2 で
構築していました。

Windows Server 2008 R2 で Exchange 2007 SP2 用のスキーマ拡張をしようとしたところ以下のエラーが。

Windows Server 2008 R2 上では Exchange 2007 のスキーマ拡張はできないようですね。

Windows Server 2008 スキーマ拡張を実行したところ、Windows Server 2008 R2 でドメインコントローラーを
構築していてもスキーマ拡張を実行することができました。

Windows Server 2008 R2 上では Exchange Server 2007 はインストールできないとは認識していたのですが、
スキーマ拡張まで実行できないとは思っていませんでした。

記憶に残っているうちに投稿しておきたいと思います。

ISA 2006 Enterprise Edition のシステム要件には以下のように記載されています。
ISA Server 2006 のシステム要件

ISA Server 2006 Enterprise Edition は、統合ネットワーク負荷分散のための冗長化構成に、 追加のネットワークアダプタが 1 台必要

?

ISA 2006 Enterprise Edition は統合 NLB を設定することにより、ISA で NLB を統合管理することができるようになります。

ISA 2006 の既定の設定では、NLB がユニキャストモードで設定されます。
ユニキャストモードの NLB では NIC の MAC アドレスの書き換えが発生し、各ホスト間は NLB で使用している NIC では
通信ができなくなります。
そのため、ISA 2006 Enterprise Edition の統合 NLB では、ホスト間通信用に追加の NIC が必要とされています。
ISA はホスト間通信ができないと、アレイ内のサーバー通信ができなくなってしまいノード間の死活監視ができなくなります。

Windows Server 2003 SP1 以降であればレジストリを変更することでホスト間通信が可能になるのですが試したことはありません…。
大抵、マルチキャストモードで構築してしまうんですよね。

Windows Server 2003 では、NLB が有効なネットワーク アダプター経由で通信できないユニキャスト NLB ノード

TMG 2010 であれば統合 NLB の設定時にユニキャスト / マルチキャストの選択ができるのですが、ISA 2006 では管理コンソールで
普通に設定を行うとユニキャストモードとなります。

マルチキャストモードで ISA 2006 の統合 NLB を使用する場合には、以下の KB の作業を実施する必要があります。

ISA Server NLB の統合の更新を有効にマルチキャスト操作

[/nlb:multicast] でマルチキャストモードに設定することにより、単一 NIC でもホスト間通信が可能となります。
Enterprise Edition でも単一 NIC で統合 NLB が使用できるのでメモとして。