Exchange Q & ASCR を使用したサイト回復性の確保、推奨されるルート ボリューム サイズなど
Henrik Walther
Q 現在、大企業向けに Exchange Server 2007 ベースのメッセージ インフラストラクチャを構築していますが、そのソリューションではサイトの回復性を確保する必要があります。そこで、Windows Server 2008 フェールオーバー クラスタで、クラスタ連続レプリケーション (CCR) ベースのメールボックス サーバーを、次の構成で展開することを考えています。アクティブ ノードをメインの (アクティブな) データセンターに配置し、パッシブ ノードをサブの (バックアップの) データセンターに配置するという展開です。
各データセンターは別のサブネットに存在していますが、同じ Active Directory サイトに属しているので、これは Windows Server 2008 コンピュータに CCR ベースのメールボックス サーバーを展開する場合にサポートされているシナリオです。複数のサブネットがある環境で CCR ベースのメールボックス サーバーを展開することは、推奨される構成でしょうか。
A データセンター間で Active Directory サイトを拡張すれば、そのシナリオはサポートされます。というのも、Exchange Server 2007 では別の Active Directory サイトに CCR ベースのアクティブ ノードとパッシブ ノードを展開することがサポートされていないからです。ですが、本来、CCR は、1 つのデータセンターで可用性を実現することを目的に設計されたもので、サイトの回復性を実現することを目的としたものではないことに留意する必要があります (サイトの回復性は、高可用性よりも障害回復に重点を置いています)。
このような特殊な理由により、Exchange 製品グループは、Exchange Server 2007 SP1 でスタンバイ連続レプリケーション (SCR) を導入しました。SCR では、CCR と同様にログ配布と再生テクノロジを使用していますが、CCR と異なり Windows のフェールオーバー クラスタリング機能には依存していません。つまり、クラスタ化の有無にかかわらずメールボックス サーバーは、SCR ターゲットにレプリケートできます。SCR ターゲットは、クラスタ化されていないメールボックス サーバーまたはパッシブ クラスタ化メールボックス サーバーの役割がインストールされたスタンバイ クラスタのいずれかで構成できます。
この構成を、図 1 に示します (この図は、「スタンバイ連続レプリケーション」でも使用されているものです)。
地理的に拡散された CCR ベースのクラスタ (ジオクラスタ) を構成することはお勧めしませんが、既に説明したように、マイクロソフトでは、このシナリオがサポートされています。ただし、このアプローチには欠点があることに留意する必要があります。
図 1 スタンバイ連続レプリケーションのモデル (画像をクリックすると拡大表示されます)
まず、拡張した Active Directory サイトを使用する必要があります。質問者の方は既にその手配をされているようですが、ご存じない読者のために明記しておきます。次に、CCR ノードが異なるサブネットに配置されているので、もう一方のサイトにフェールオーバーすると、クラスタ化されたメールボックス サーバー (CMS) の IP アドレスが変更されることにも注意する必要があります。この変更は、Microsoft Outlook クライアントで使用されているすべての DNS サーバーにレプリケートする必要があります。また、CMS に接続している Outlook クライアントがインストールされたすべてのコンピュータで DNS キャッシュをフラッシュする必要もあります。
この処理が行われている間、Outlook クライアントは CMS のメールボックスから切断された状態になります。そのため、CMS ネットワーク名リソースの DNS の有効期限 (TTL) の値を 5 分 (300 秒) 以内に変更する必要があります。この詳細については、technet.microsoft.com/library/bb676687.aspx を参照してください。
さらに、ファイル共有監視 (FSW) を配置する場所についても考慮が必要です。FSW はハブ トランスポート サーバーに作成することをお勧めしますが、どちらのサイトに作成するのかが問題となります。メインのデータセンターのハブ トランスポート サーバーに作成し、メインのデータセンターで障害が発生した場合、自動的にフェールオーバーが実行されるのか、ということが懸念されるでしょう。いずれかの CCR ノードと FSW が同時にダウンした場合は、実行されません。その一方、ジオ CCR シナリオでは、自動フェールオーバーが好まれないこともあります。詳細については、Exchange Server Team ブログのジオ CCR シナリオにおける FSW の配置ガイドに関する投稿を参照してください。
バックアップのデータセンターに配置されたパッシブ ノードへのフェールオーバーが実行されると、メインのデータセンターに配置されたハブ トランスポート サーバーはダウンしているので、ハブ トランスポート サーバーのトランスポート収集コンポーネントからのバックフィルは行われないことにも注意する必要があります。その結果、電子メールが行方不明になるという問題が発生します。
このように、ご使用の環境にジオ CCR を展開する前には、サイトの回復性を確保するために SCR を使うよりも考慮すべき事項が多くあります。
Q 私の組織は、アメリカ国内だけでなく、欧州、中近東、アフリカにある複数の物理サイトで構成されています。現状では、すべてのユーザーのメールボックスが各物理サイトのローカルに展開されたメールボックス サーバーでホスト管理されていますが、これをアメリカ国内にある 1 つのデータセンターにまとめたいと考えています。このような構成に変更した場合、キャッシュ モードで実行されている Outlook 2003 または Outlook 2007 クライアントで発生する最大待ち時間はどのくらいになりますか。
A お使いのクライアントがすべて Outlook 2003 または Outlook 2007 で、かつキャッシュ モードで実行されているのは良いことです。なぜなら、このような統合では、一般的に、キャッシュ モードが救世主となるからです。
以前、マイクロソフトでは、キャッシュ モードで実行している Outlook 2003 クライアントが使用するメールボックス サーバーのエンドツーエンドの待機時間を 1,000 ms 以下にすることを推奨していました。また、キャッシュ モードで実行していない Outlook 2003 クライアントの場合は、200 ms 以下でした。
個人的な経験からすれば、1,000 ms という待機時間は、Outlook 2007 のクライアントでもやや長すぎます。というのも、待機時間が 500 ms を超えると、一般的に、Outlook クライアントがハングし始めたり、動きが緩慢になるからです。ですから、個人的には Outlook クライアントとホーム メールボックス サーバー間の待機時間を 500 ms 以下にすることをお勧めします。図 2 は Redmond にあるメールボックス サーバーに接続した Outlook 2007 クライアントの平均応答時間を示しています。
ここでヒントを紹介しましょう。図 2 に示した [接続状態] ウィンドウを表示するには、Ctrl キーを押しながらシステム トレイの Outlook アイコンを右クリックします。または、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、「Outlook.exe /RPCDIAG」と入力して表示することもできます。
図 2 Outlook 2007 の平均応答時間
私がデンマークにいるとすれば、この平均応答時間は許容範囲です。グローバル カタログ サーバーの平均応答時間はかなり長いことがわかりますが、グローバル カタログ サーバーは、アドレス帳の参照などに使われるもので、使用頻度が低いので、たいした問題ではありません。
Q 最近、組織に Exchange Server 2007 SP1 を展開しました。Active Directoty トポロジは 2 つのサイトで構成されています。1 つ目のサイト内には、CCR ベースのメールボックス サーバーを展開し、ハブ トランスポート サーバーの役割とクライアント アクセス サーバーの役割のそれぞれをインストールした 2 台のサーバーを展開しました。2 つ目のサイト内には、シングル コピー クラスタ (SCC) ベースのメールボックス サーバーを展開し、1 つ目のサイトと同様にハブ トランスポート サーバーの役割とクライアント アクセス サーバーの役割のそれぞれをインストールした 2 台のサーバーを展開しました。
各 Active Directory サイトでは、大半のクライアントが Outlook 2003 です。そのため、空き時間情報やオフライン アドレス帳の処理にパブリック フォルダ ストアが必要です (パブリック フォルダは、データ リポジトリとしてではなく、単に空き時間情報やオフライン アドレス帳の処理に使用されます)。当初の計画では、CCR ベースのメールボックス サーバーと SCC ベースのメールボックス サーバーの両方のパブリック フォルダ ストアをマウントして、パブリック フォルダへの変更内容が Active Directory サイト間でレプリケートされるようにすることを考えていました。しかし、パブリック フォルダのレプリケーションと CCR のレプリケーションはうまく連動しないので、CCR ベースのメールボックス サーバーで 1 つ以上のパブリック フォルダ ストアをホストしている場合、マイクロソフトでは、Exchange Server 組織で複数のパブリック フォルダ ストアを使用することを推奨していないという話を聞きました。
これらの情報を踏まえて、どのようにすれば良いか回答をお願いします。マイクロソフトで推奨されていない方法は採用したくありません。ですが、各 Active Directory サイトの Outlook 2003 クライアントがもう一方の Active Directory サイトにあるパブリック フォルダ ストアにアクセスする方法は避けたいと思っています。
A これは良い質問ですね。パブリック フォルダのレプリケーションと、パブリック フォルダ ストアの CCR レプリケーションは組み合わせるべきでないというのは、ご指摘のとおりです (詳細については、2009 年 1 月号の Exchange Queue & A コラムを参照してください)。古いバージョンの Outlook クライアントが空き時間情報の読み取りや、オフライン アドレス帳 (OAB) のダウンロードを行うためにパブリック フォルダ機能を使用する必要があるということですので、CCR ベースのメールボックス サーバーが配置されている Active Directory サイト内のハブ トランスポート サーバーとクライアント アクセス サーバーの両方の役割をインストールしたサーバーの 1 つにメールボックス サーバーの役割もインストールすることをお勧めします。それから、パブリック フォルダ ストアを、CCR ベースのメールボックス サーバーからこのサーバーに移動します。
パブリック フォルダ レプリケーションが正常に動作するには、このサーバーでメールのデータベースが運用されている必要があることに注意してください。ハブ トランスポート サーバーとクライアント アクセス サーバーの役割を兼任したサーバーで、空き時間情報や OAB へのアクセスを処理しても、サーバーに対して大きな負荷をかけることにはなりません。この方法は、類似シナリオで、多くの Exchange 設計者が実際に採用しているものです。
Q 今後 6 か月以内に移行する予定の Exchange Server 2007 環境に含めるメールボックス サーバーのストレージ レイアウトを考えています。ユーザー数が非常に多いので、メールボックス サーバーはすべて CCR ベースにして、各サーバーには 48 個のストレージ グループを用意するつもりです。
ストレージ グループの数も多いので、マウント ポイントを使用するつもりです。CCR ベースの各メールボックス サーバーの論理ユニット番号 (LUN) ごとにマウント ポイントを作成するので、マウント ポイントを作成するアンカー ドライブの推奨最小サイズを知りたいと思っています。
A サポート技術情報の記事「Windows Server 2008 のサーバー クラスタでボリューム マウント ポイントを構成する方法」では、ボリューム マウント ポイントを Windows Server 2008 環境のサーバー クラスタで構成する方法を説明しています。この記事によると、ルート (ホスト) ボリューム (通称、アンカー LUN) をマウント ポイント専用に使用する場合、そのサイズは 5 MB 以上にする必要があります。しかし、Exchange Server の場合はルート ボリュームの推奨サイズが異なります。
以前のバージョンと同様に、Exchange Server 2007 の場合も、100 ～ 500 MB のルート ボリュームを使用することをお勧めします。Windows Server 2003 ベースのサーバーで Exchange Server 2007 を実行するときには、ルート ボリュームの空き容量が 20 MB 以下場合、新しいデータベースを作成すると問題が発生することがあります。この問題の詳細については、「Exchange Server 2007 で新しいデータベースを作成した後にイベント 104 が記録される」を参照してください。
Q 私が所属している組織では、Exchange Server 2007 SP1 ベースのメッセージング インフラストラクチャを使用しています。すべての Exchange Server 2007 サーバーが同じデータセンター内に配置されており、サーバーは CCR クラスタリング テクノロジ ベースであるので、ローカルの冗長性が確保されています。最近、災害時に、メインのデータセンターで障害が発生した場合に備えて、バックアップ用に 2 つ目のデータセンターが設置されました。
Exchange Server に関しては、このバックアップのデータセンターに、ハブ トランスポート サーバー、クライアント アクセス サーバー、およびメール ボックス サーバーを、それぞれ 1 台ずつ展開することで、サイトの回復性を実現したいと考えています。そして、メインのデータセンターにある CCR ベースのメールボックス サーバーからバックアップのデータセンターにあるメールボックス サーバーに対して SCR を有効にすることを検討しています。そこで、Exchange Server 2007 サーバーをバックアップのデータセンター内に配置して構成する前に聞きたいことがあります。CCR ベースのメールボックス サーバーで構成された SCR ソースとスタンドアロン メールボックス サーバーで構成された SCR ターゲットの間で、SCR を有効にすることはサポートされていますか。サポートされている場合、このアプローチは推奨されているものですか。
A 手短にお答えすると、そのアプローチは完全にサポートされています。詳しくお答えした場合でも、このアプローチはサポートされているということになりますが、/RecoverCMS スイッチを使用して SCR ソース サーバー上のクラスタ化されたメールボックス サーバー (CMS) を回復することはできないという点は覚えておいてください。/RecoverCMS スイッチを使用して CMS を回復できるのは、SCR ターゲットがパッシブ クラスタ化メールボックス サーバーの役割だけがインストールされている Windows Server 2003 または Windows Server 2008 のフェールオーバー クラスタである場合に限られます。
スタンドアロンのメールボックス サーバーを SCR ターゲットとして展開する場合、データベース ポータビリティを使用してデータベースを回復するという、/RecoverCMS スイッチを使用するよりも煩雑な手順が必要になります。必要な手順の詳細については、Exchange Server 2007 のドキュメント「スタンバイ連続レプリケーション: データベースの移植性」を参照してください。Windows Server 2003 または Windows Server 2008 の Enterprise Edition が SCR ターゲットにインストールされていれば、SCR ターゲットからメールボックス サーバーの役割を削除し、フェールオーバー クラスタを構成して、フェールオーバー クラスタ ノードのいずれかにパッシブ クラスタ化メールボックス サーバーの役割をインストールすると、/RecoverCMS オプションを使用して CMS を回復することができます。
現在、使用できる物理コンピュータが 1 台しかなくても、近いうちに、(Windows Server 2003 または Windows Server 2008 の Enterprise Edition と Exchange Server 2007 Enterprise Edition のライセンスを含めて) もう 1 台のコンピュータを用意できるのであれば、1 つのノードで構成された Windows Server 2003 または Windows Server 2008 のフェールオーバー クラスタを構成して、このノードにパッシブ クラスタ化メールボックス サーバーの役割をインストールして、ご希望の環境構築に取り掛かることも可能です。2 台目のコンピュータの用意ができたら、このコンピュータに Windows Server 2003 または Windows Server 2008 をインストールしてネットワークの設定などを行えば、これを Windows フェールオーバー クラスタに追加することができます。
Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 15 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。Trifork Infrastructure Consulting (デンマークを拠点とするマイクロソフト ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corporation (ドキュメント管理とローカライズ サービス専門とする米国の企業) でテクニカル ライターを務めています。