次の方法で共有

Windows Server 2008 でのクラスタ連続レプリケーションのインストール

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

トピックの最終更新日: 2008-12-19

Windows Server 2008 でのクラスタ連続レプリケーション (CCR) の展開手順は、Windows Server 2003 での CCR の展開と似ていますが、重要な違いもいくつかあります。CCR を展開する前に、「クラスタ連続レプリケーション」を十分に確認することをお勧めします。また、「クラスタ連続レプリケーションの計画」に示す要件をすべて満たしていることを確認してください。

Windows Server 2008 での CCR のインストールは、いくつかのフェーズに分けられます。

  1. クラスタ ネットワークの形成と構成から開始し、ハードウェアのセットアップを構成します。
  2. 最初のノードから始めて、次に 2 番目のノードという順で、クラスタを形成します。
  3. クラスタ ネットワークと、クラスタ ハートビート喪失のトレランスを構成します。
  4. ファイル共有監視を構成し、セキュリティで保護します。
  5. アクティブおよびパッシブのメールボックス サーバーの役割をクラスタにインストールします。クラスタ化メールボックス サーバー (CMS) は、アクティブなメールボックス サーバーの役割のインストール中に作成されます。
    note注 :
    次のフェーズを開始する前に、前のフェーズを完了しておくことをお勧めします。すべてのフェーズを完了した後は、CCR ソリューションを運用環境で使用する前に確認することをお勧めします。

インストール後にも、次のようないくつかの作業を実行する必要があります。

  • フェールオーバー制御の設定の調整。
  • トランスポート収集に関する既定の構成の調整。
  • クラスタ内のノード間で CMS を移動できるかどうかの確認。
  • 連続レプリケーション処理のための複数のネットワークの有効化。

以下のいずれかの手順を実行する前に、対象となるコンピュータに Windows Server 2008 に必要なオペレーティング システム コンポーネントがインストールされていることを確認する必要があります。Windows Server 2008 に Microsoft Exchange の前提条件をインストールする方法の詳細については、「Windows Server 2008 または Windows Vista に Exchange 2007 SP1 および SP2 の前提条件をインストールする方法」を参照してください。

以下では、各フェーズについて詳しく説明します。

ネットワークの形成と構成

Windows Server 2008 で 2 ノード CCR 環境に CMS を作成する場合は、十分な数の IP アドレスが利用可能である必要があります。Windows Server 2008 のフェールオーバー クラスタ構成を行うことで、従来のクラスタの場合とは大幅に異なる新しいネットワーク機能を導入できます。たとえば、Windows Server 2008 のフェールオーバー クラスタにより、複数のサブネット、DHCP (動的ホスト構成プロトコル) インターネット プロトコル Version 4 (IPv4)、IPv6 のサポートが可能になります。Microsoft Exchange Server 2007 Service Pack 1 (SP1) を Windows Server 2008 のフェールオーバー クラスタで実行する場合、地理的に分散したクラスタでの 2 つのサブネット間のフェールオーバーがサポートされます。このサポートには、シングル コピー クラスタ (SCC) と、CCR 環境のメールボックス サーバーの両方が含まれています。

note注 :
Windows Server 2008 フェールオーバー クラスタでは DHCP IPv4 がサポートされますが、運用環境では静的 IP アドレスを使用することをお勧めします。フェールオーバー クラスタ内で DHCP IPv4 を使用する場合は、無期限のリースが許可されるように DHCP サーバーを構成することをお勧めします。

これで、Windows Server 2008 のフェールオーバー クラスタ構成から始めて、個々のクラスタ ノードを、ルーティングされた個別のネットワーク上に配置することが可能になります。この場合、クラスタが認識するすべてのネットワークへの直接のローカル接続をすべてのクラスタ ノードが備えている可能性は低いので、IP アドレス リソースに依存するリソース (ネットワーク名リソースなど) は、OR ロジックを実装する必要があります。このことにより、サービスやアプリケーションがリモート ノードにフェールオーバーしたときに、IP アドレスとネットワーク名リソースがオンライン状態となることが容易になります。

ネットワーク名リソースに関連付けられたすべてのオンライン IP アドレスは、ドメイン ネーム システム (DNS) に動的に登録されます (動的更新が構成されている場合)。登録されるリストの順序は、オンラインになっているこれらの IP アドレス リソースをクライアントに返す際の優先順位となります。ルーティングされた異なるネットワーク上にクラスタ ノードを配置でき、ユーザー データグラム プロトコル (UDP) (ユニキャスト) 上に実装された信頼性の高いセッション プロトコルを使用するように通信方法が変更されているため、地理的に分散されたクラスタ用のネットワーク要件は適用されなくなります。このため、組織では、仮想 LAN (VLAN) 技術を使用して 2 つの場所にクラスタ サブネットを拡張することなく、2 つの物理データ センターにまたがるフェールオーバー クラスタを展開することができます。

IP アドレスは、パブリック ネットワークとプライベート ネットワークの両方に必要です。プライベート アドレスとパブリック アドレスに関連する要件は、次のとおりです。

  • プライベート アドレス   各ノードで、クラスタ プライベート ネットワークに使用するネットワーク アダプタごとに 1 つの IP アドレスが必要です。静的 IPv4 アドレスを使用することも、動的に割り当てられた IPv6 アドレスを使用することもできます。パブリック ネットワークの 1 つとして同一のサブネットまたはネットワーク上で使用されていない IP アドレスを使用する必要があります。ノードのプライベート IP アドレスには、10.10.10.10 と 10.10.10.11 (サブネット マスク 255.255.255.0) を使用することをお勧めします。
  • パブリック アドレス   各ノードで、クラスタ パブリック ネットワーク (混合ネットワークとも呼ばれます) に使用するネットワーク アダプタごとに 1 つの IP アドレスが必要です。また、クライアントと管理者がフェールオーバー クラスタと CMS にアクセスできるように、フェールオーバー クラスタと CMS に対しても IP アドレスが必要です。プライベート ネットワークの 1 つとして同一のサブネットまたはネットワーク上で使用されていない IP アドレスを使用する必要があります。静的 IPv4 アドレス、DHCP IPv4 アドレス、または静的 IPv6 アドレスを使用できます。
    important重要 :
    クラスタ ネットワークのすべてのネットワーク アダプタで同じバージョンの TCP/IP を使用する必要があります。つまり、すべてのネットワーク アダプタで IPv4 のみを使用するか、またはすべてのネットワーク アダプタで IPv4 と IPv6 の両方を使用する必要があります。

クラスタ化メールボックス サーバーのためのネットワーク ベスト プラクティス

また、ご利用のクラスタ ネットワークについて、次のベスト プラクティスに従うことをお勧めします。

  • わかりやすい名前を使用する   クラスタを構築する際は、クラスタ ノード、クラスタ ネットワーク インターフェイス、クラスタ名、および CMS 名に対して、これらを区別できる名前を使用することができます。たとえば、他の Exchange サーバーやクライアントとの通信に使用するネットワークには、パブリックという名前を使用できます。クラスタ ノード間の通信に使用するネットワークには、プライベートという名前を使用できます。トポロジ マップを確認しなくても相互の関連付けがわかる名前を使用します。別の便利な規則は、クラスタのノードを CMS の名前と関連付けることです。たとえば、CMS と 2 つのノードに、それぞれ mbx01、mbx01-node1、mbx01-node2 という名前を使用します。

  • プライベート ネットワーク インターフェイスにプライベート IP アドレスを使用する   各ノードのプライベート ネットワーク インターフェイスに使用できる IP アドレスの範囲とサブネット マスクについては、次の表を参照してください。

    プライベート ネットワーク インターフェイス用のアドレスの範囲とサブネット マスク

    ネットワーク/ノード IP アドレスの範囲 サブネット マスク

    プライベート/NODE1

    10.10.10.10-255

    255.255.255.0

    プライベート/NODE2

    10.10.10.11-255

    255.255.255.0

次の点に注意してください。

  • 現在のパブリック ネットワークでネットワーク アドレス 10.x.x.x とサブネット マスク 255.255.255.0 を使用している場合は、別のプライベート ネットワーク IP アドレスとサブネット マスクを使用することをお勧めします。
  • プライベート ネットワークにフォールト トレラントを備えたアダプタ、またはチーミングを利用することはお勧めしません。プライベート ネットワークの冗長性を必要とする場合は、クラスタ専用に構成された複数のネットワーク アダプタを使用してください。このテクノロジを使用する場合は、使用しているファームウェアとドライバが最新バージョンであることを確認することが重要です。サーバー クラスタの互換性の詳細については、ネットワーク アダプタの製造元に問い合わせてください。フェールオーバー クラスタ展開でのネットワーク アダプタのチーミングの詳細については、マイクロソフト サポート技術情報の記事 254101「ネットワーク アダプタのチーミングとサーバーのクラスタ化」を参照してください。

フェールオーバー クラスタの形成

クラスタに 1 番目のノードを追加すると、フェールオーバー クラスタが形成されます。この処理では、固有のネットワーク名と固有のネットワーク IP アドレスがクラスタに設定されます。このネットワーク名と IP アドレスは、全体としてクラスタのネットワーク ID になり、クラスタのノードがオンラインおよびオフラインに移行すると、ノード間を移動します。通常、CMS の管理では、クラスタのネットワーク ID を使用することはあまりありません。

フェールオーバー クラスタまたは以前のバージョンの Exchange クラスタの展開を十分に理解していると、CCR 用のクラスタの展開が大きく異なっていることがわかります。クラスタ ソリューションを初めて使用する場合、展開は一般的なクラスタ構成よりも非常に簡単になります。

「クラスタ連続レプリケーション用の Windows Server 2008 フェールオーバー クラスタを作成する方法」の手順に従って、新しいクラスタを構築することができます。

ノードの追加

最初のノードにクラスタ サービスをインストールした後、2 番目のノードには最初のノードより短い時間でクラスタ サービスをインストールできます。これは、セットアップ プログラムが、最初のノードに対するネットワーク構成の設定を基にして、2 番目以降のノードに対するネットワーク設定を構成するためです。2 番目のノードを追加して構成する前に、クラスタ構成を検証する必要があります。クラスタ サービスが実行されていて、クラスタが運用されていることを確認するには、コマンド プロンプトから Cluster.exe group を実行します。出力は、以下のようになります。

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

作業を続ける前に、注意する必要のあるエラーや警告をイベント ログで確認することもお勧めします。クラスタに 2 番目のノードを追加する手順の詳細については、「クラスタ連続レプリケーション用の Windows Server 2008 フェールオーバー クラスタを作成する方法」を参照してください。

クラスタ ネットワークの構成

クラスタにすべてのノードを追加した後、クラスタ ネットワーク コンポーネントを構成する必要があります。特に、クラスタとクライアント アクセスのネットワーク、およびクラスタ ハートビート喪失のトレランス設定を構成する必要があります。また、クラスタ ネットワークの名前をわかりやすい名前に変更することをお勧めします。

次の表は、クラスタ ハートビート用にクラスタ ネットワークを構成するために使用できるオプションの詳細です。

クラスタ ネットワーク構成オプション

オプション 説明

[クラスタにこのネットワークの使用を許可する] (プライベート ネットワーク)

クラスタ サービスでこのネットワークをノード間の通信トラフィックのみに使用する場合は、このオプションのみを選択します。このネットワークを使用して、クライアントが CMS に接続することはできません。

[クラスタにこのネットワークの使用を許可する] および [クライアントにこのネットワーク経由の接続を許可する] (混合ネットワーク)

クラスタ サービスでこのネットワーク アダプタをクラスタのノード間通信および外部クライアントとの通信の両方に使用する場合は、両方のオプションを選択します。クラスタ サービスはノード間の通信にこのネットワークを使用し、クライアントはこのネットワークを使用して CMS に接続することができます。

[クラスタによるこのネットワークの使用を許可しない] (管理されていないネットワーク)

クラスタ内でネットワークを使用しない場合や、クラスタ サービスでネットワークを管理する場合は、このオプションのみを選択します。クラスタ サービスはノード間の通信にこのネットワークを使用できず、クライアントもこのネットワークを使用して CMS に接続することはできません。

CCR 環境に展開される CMS には、サポートされる両方のノードに最低 2 つのネットワーク カードが必要です。Exchange 2007 SP1 では、クラスタ サービスによって管理され、クラスタでの使用とクライアント接続の両方に対して有効になっているすべてのネットワーク (たとえば、混在ネットワークとして構成されているネットワーク) は、シード、ログ配布、再シードなどの連続レプリケーション機能にも使用できます。これは、Enable-ContinuousReplicationHostName という Exchange 2007 SP1 の新しいコマンドレットを使用して実現できます。

note注 :
クラスタ ネットワークを構成するためのオプションの 1 つとして、予備ネットワーク構成を作成し、ネットワーク試験のみが選択されている状態でフェールオーバー クラスタ管理ツールの構成の検証ウィザードを実行する方法があります (たとえば、インベントリ テスト、記憶域テスト、システム構成テストをスキップします)。ネットワーク テストのみを実行する場合、処理にはそれほど時間はかかりません。検証レポートを使用すると、ネットワーク構成に必要な修正を加えることができます。クラスタ全体を構成した後、構成の検証ウィザードを再実行し、すべてのテストを選択することをお勧めします。

クラスタ ハートビート喪失のトレランス設定の構成

クラスタ通信とネットワーク優先度を構成した後で、クラスタ ハートビート喪失の特定のトレランス設定を構成することをお勧めします。これにより、クラスタ ノード間にあるネットワーク接続のクラスタ サービスの監視を短い中断に耐えるように構成します。これにより、ネットワークが短時間停止する状況で、フェールオーバーを回避できる場合があります。すべてのノードで、プライベート クラスタ ネットワークと混在したクラスタ ネットワークが 10 回のハートビート喪失に対応できるよう構成することをお勧めします。この設定レベルは約 12 秒に相当します。

クラスタ ネットワーク コンポーネントを構成する方法の詳細については、「フェールオーバー クラスタ用にクラスタ ネットワークを構成する方法」を参照してください。

クラスタ化メールボックス サーバーのネットワーク名リソースの TTL 設定の構成

次の 2 つの展開シナリオでは、停止オプションまたは回復オプションを実行するときに、CMS に割り当てられている IP アドレスが変更されます。

  • 複数のサブネット環境に CMS が展開されている。
  • 障害が発生したクラスタの回復に、スタンバイ クラスタが使用されている。

どちらのシナリオでも、CMS の名前は変更されませんが、CMS に割り当てられている IP アドレスは変更されます。クライアントおよび他のサーバーは、IP アドレスが変更された CMS と通信する場合、DNS が新しい IP アドレスで更新され、すべてのローカル DNS キャッシュが更新されるまで、CMS との通信を再確立できません。DNS の変更がクライアントおよび他のサーバーに伝わるまでにかかる時間を最小限に抑えるため、CMS ネットワーク名リソースの DNS TTL 値を 5 分に設定することをお勧めします。

note注 :
ほとんどの環境では、CMS のネットワーク名リソースにのみ DNS TTL 値を設定することをお勧めします。ただし、管理目的で名前によってクラスタに接続する Exchange 管理ツール以外のツールを含む環境では、クラスタのネットワーク名リソースの TTL 値も 5 分に設定することをお勧めします。

既定では、クラスタ サービスはネットワーク名リソースの DNS TTL 値として 20 分の設定を使用します。DNS 管理ツールを使用して、DNS データベース内のホスト名の TTL 値を直接手動で調整することができます。ただし、DNS のネットワーク名登録が更新されるごとに、DNS データベースの値は上書きされ、20 分というクラスタ サービスの既定値に設定されます。DNS のネットワーク名登録の更新は、CMS の起動時、移動時、または障害やフェールオーバーの後のオンラインへの復帰時に発生します。

Windows Server 2008 では、フェールオーバー クラスタのネットワーク名リソースに新しいプライベート プロパティが追加されました。この新しいプロパティは HostRecordTTL という名前で、Cluster.exe を使用して構成できます。

note注 :
このプロパティは、Windows Server 2008 のフェールオーバー クラスタのみで使用されます。Windows Server 2003 のフェールオーバー クラスタには、これに該当するプロパティはありません。Windows Server 2003 を実行しているフェールオーバー クラスタの場合、20 分というクラスタ サービスの既定値が常に適用されます。

複数のサブネットでの CMS またはスタンバイ クラスタの展開で使用できるように、CMS ネットワーク名リソースの DNS TTL 値を構成する手順の詳細については、「ネットワーク名リソースの DNS TTL 値を構成する方法」を参照してください。

クラスタ クォーラムの構成

クラスタ ネットワークを構成したら、次に、ノードおよびファイル共有マジョリティ クォーラム リソースを使用するように、フェールオーバー クラスタを構成します。ノードおよびファイル共有マジョリティ クォーラム モデルを使用するようにフェールオーバー クラスタを構成する方法の詳細な手順については、「ノードおよびファイル共有マジョリティ クォーラムを構成する方法」を参照してください。

フェールオーバー クラスタの検証

Windows Server 2008 には、構成の検証ウィザードという名前の新しいウィザードが含まれています。このウィザードを使用して、フェールオーバー クラスタの状態や構成を検証することができます。クラスタに Exchange 2007 をインストールする前に、このウィザードを実行することをお勧めします。Exchange 2007 をインストールする前にこのウィザードを実行することによって、Exchange のインストールを妨げる可能性のあるクラスタ内の構成の問題を特定し、対処することができます。

構成の検証ウィザードには 4 つのテスト グループが含まれています。これらは、クラスタが、Microsoft によってサポートされるために必要な要件を満たしているかどうかを検証するために設計されています。この場合の要件とは、互換性を示すための "Designed for Windows Server 2008" のロゴをクラスタ ソリューションが取得していることのほかに、さらに求められる要件のことです。

テスト グループは、インベントリ、ネットワーク、記憶域、システム構成の 4 つです。CCR は共有記憶域を使用しないので、ストレージ テスト グループを実行する必要はありません。CCR 用に設計されたフェールオーバー クラスタなど、クラスタ化された記憶域リソースを持たないフェールオーバー クラスタに対してストレージ テスト グループを実行した場合、ストレージ テスト グループは失敗します。CCR 用に設計されたフェールオーバー クラスタでは共有記憶域が存在しないと想定されるため、ストレージ テスト グループの失敗はすべて無視しても問題ありません。

フェールオーバー クラスタを検証する手順の詳細については、「フェールオーバー クラスタ構成を検証する方法」を参照してください。

クラスタ化メールボックス サーバーのインストールおよび構成

各ノードでいくつかの手順を実行することで、クラスタにメールボックス サーバーの役割をインストールできます。クラスタが形成および検証され、さらに、クラスタがファイル共有監視を設定した Majority Node Set (MNS) クォーラムを使用するよう構成された後で、最初にアクティブ ノードにメールボックス サーバーの役割をインストールする必要があります。アクティブ ノードにメールボックス サーバーの役割をインストールする方法の詳細については、「Windows Server 2008 の CCR 環境にアクティブ クラスタ化メールボックスの役割をインストールする方法」を参照してください。

アクティブ ノードにメールボックス サーバーの役割および CMS をインストールして、最初のストレージ グループの構成を確認した後で、パッシブ ノードにメールボックス サーバーの役割をインストールする必要があります。パッシブ ノードにメールボックス サーバーの役割をインストールする方法の詳細については、「Windows Server 2008 で CCR 環境にパッシブ クラスタ化メールボックスの役割をインストールする方法」を参照してください。

メールボックス サーバーの役割をインストールした後は、必要に応じて、フェールオーバーの設定をチューニングすることができます。フェールオーバーのチューニングの詳細については、「クラスタ連続レプリケーションのマウントとフェールオーバーの設定をチューニングする方法」を参照してください。

セットアップ後の作業

両方のノードにメールボックス サーバーの役割をインストールして、CMS が作成された後は、セットアップ後の作業をいくつか実行する必要があります。これには、以下の作業が含まれます。

  • 連続レプリケーション処理のための複数のネットワークの有効化。
  • フェールオーバー制御の設定の調整。
  • トランスポート収集に関する既定の構成の調整。
  • クラスタ内のノード間で CMS を移動できるかどうかの確認。

連続レプリケーション処理のための複数のネットワークの有効化

Microsoft Exchange Server 2007 の RTM (Release To Manufacturing) 版では、ログ ファイルのコピーとシードはすべてパブリック ネットワークを介して行われます。Exchange 2007 SP1 では、混合ネットワークとして構成されたすべてのクラスタ ネットワークで、連続レプリケーション処理を有効にできます。この処理には、ストレージ グループのシードと再シード、およびログ配布が含まれます。

Exchange 2007 SP1 では、混合ネットワークとして指定されたクラスタ ネットワークのみで、連続レプリケーションを有効にできます。混合ネットワークとは、クラスタ (ノード間通信) およびクライアント アクセス トラフィックの両方の目的に構成されているクラスタ ネットワークのことです。クラスタ アクセス用に構成されており、クライアント アクセス用には構成されていないクラスタ ネットワーク (プライベート ネットワークとも呼ばれます) では、連続レプリケーションを有効にできません。

混合ネットワークを介したログ配布のサポートは、Enable-ContinuousReplicationHostName という新しいコマンドレットを使用して構成されます。また、この機能をオフにするには、Disable-ContinuousReplicationHostName コマンドレットを使用します。管理者は、CCR 環境に CMS が存在するようになった後、クラスタの両方のノードで Enable-ContinuousReplicationHostName を実行し、2 つの IP アドレスとホスト名を指定することができます。この指定後、構成が正常に完了し、混合ネットワークが機能していることが確認されると、システムによってログのコピー用の混合ネットワークがランダムに選択されます。

連続レプリケーション処理用にクラスタ ネットワークを有効にする手順の詳細については、「Windows Server 2008 でログ配布とシード用に冗長クラスタ ネットワークを有効にする方法」を参照してください。

note注 :
Enable-ContinuousReplicationHostName コマンドレットを実行するたびに、ホスト名、IP アドレス、およびフェールオーバー クラスタに作成されるクラスタ グループに加え、CMS が含まれる Active Directory ドメインにコンピュータ アカウントも作成することになります。既定では、Windows Server 2008 で、ドメイン管理者特権が委任されておらず、コンピュータ オブジェクト作成およびコンピュータ オブジェクト削除のアクセス制御エントリ (ACE) が与えられていないユーザーが追加できるコンピュータ アカウントの最大数は 10 個です。 Enable-ContinuousReplicationHostName コマンドレットと Disable-ContinuousReplicationHostName コマンドレットを頻繁に実行し、ドメイン管理者特権または前に示した ACE を持っていない Exchange 管理者は、すぐに 10 個のアカウント制限に達する可能性があります。この問題については回避策の情報が提供されており、マイクロソフト サポート技術情報の記事 307532「コンピュータ オブジェクト変更時のクラスタ サービス アカウントのトラブルシューティング方法」で説明されています。詳細については、マイクロソフト サポート技術情報の記事 251335「ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない」を参照してください。

CCR 環境でのシードおよび再シードは、Update-StorageGroupCopy コマンドレットを使用して行われます。Exchange 2007 SP1 では、このコマンドレットは拡張され、DataHostNames という新しいパラメータが含まれています。このパラメータは、シードまたは再シードに使用するネットワークを指定するために使用されます。この値は、完全修飾ドメイン名 (FQDN) またはホスト名の 2 つの名前による複数値の一覧です。この中のいずれかの名前にはパッシブ ノードを指定する必要があります。

フェールオーバー制御の設定の調整

CCR には、CMS のフェールオーバー動作の制御を可能にする属性が含まれています。これらの属性は、Set-MailboxServer コマンドレットを使用して構成できます。これらの属性は、次の 2 つの決定アルゴリズムを制御できるようにするために提供されています。

  • アルゴリズム 1   アルゴリズム 1 は、フェールオーバー時にデータベースをマウントするかどうかを制御します。フェールオーバー時に、データベースで失われたログが構成済みのログの量より少ないことが検出されると、データベースは自動的にマウントされます。許容される失われたログの数は、AutoDatabaseMountDial と呼ばれる値を使用して構成できます。このパラメータは、Active Directory 内では msExchDataLossForAutoDatabaseMount という名前の Exchange Server 属性で表され、ロスレス、中可用性、および高可用性という 3 つの値があります。失われたログの数は、ロスレスでは 0、中可用性では 3、および既定の高可用性では 6 です。これらの値を構成する手順の詳細については、「クラスタ連続レプリケーションのマウントとフェールオーバーの設定をチューニングする方法」を参照してください。
  • アルゴリズム 2   アルゴリズム 2 を使用すると、オフラインにするよりも、古いデータを使用してオンラインにすることの方が重要かどうかを判断できます。アルゴリズム 1 に基づいてデータベースをマウントできなかった場合は、2 回目のチェックを行う時間を設定できます。待機する時間は、ForcedDatabaseMountAfter 属性によって構成されます。値は時間単位で、既定値は無制限です。
    important重要 :
    ForcedDatabaseMountAfter の値に達すると、ストレージ グループのコピーが 1 ログ分遅れているか、10 ログ分遅れているか、1,000 ログ分遅れているかに関係なくデータベースがマウントされ、この結果、相当なデータ損失が発生する場合があります。このため、サービス レベル契約 (SLA) が、発生する可能性のあるデータ損失量の最大値を保証している場合は、このパラメータを使用しないようにします。

トランスポート収集の調整

トランスポート収集は、ローカル連続レプリケーション (LCR) または CCR を使用する場合に構成する必要のあるハブ トランスポート サーバーの役割の機能であり、この機能は LCR および CCR 環境でのみ使用されます。トランスポート収集は、予定されていない停止の後で最近配信されたメールを送信します。LCR または CCR を使用する場合、トランスポート収集は常に有効にしておく必要があります。トランスポート収集は、ストレージ グループごとに使用できる記憶域の容量を設定し、メールをトランスポート収集内で保持する時間を設定することによって、組織全体で有効にすることができます。

ハブ トランスポート サーバーは、次の場所の CMS に最近配信されたメールのキューを保持します。ロスレスではないフェールオーバーが起こったときは、CCR は自動的にサイト内のすべてのハブ トランスポート サーバーにトランスポート収集キューからのメールを再送信するよう要求します。LCR 環境では、再送信の要求は、Restore-StorageGroupCopy タスクの一部として実行されます。再送信が実行されると、インフォメーション ストアは自動的に複製を削除し、失われたメールを再配信します。Set-TransportConfig コマンドレットを使用すると、トランスポート収集の既定の構成設定を変更できます。この設定は、ストレージ グループのレベルで適用されます。また、Exchange 2007 SP1 では、Exchange 管理コンソールを使用して、トランスポート収集の値を構成することもできます。

ストレージ グループあたりの最大サイズ (MaxDumpsterSizePerStorageGroup パラメータ) は、送信可能なメッセージの最大サイズの 1.5 倍に構成することをお勧めします。たとえば、メッセージの最大サイズが 10 MB の場合、MaxDumpsterSizePerStorageGroup パラメータは、15 MB の値に設定します。メッセージの最大サイズを指定していない組織では、ストレージ グループあたりの最大サイズを、組織内で送信されるメッセージの平均サイズの 1.5 倍に構成することをお勧めします。

また、ストレージ グループあたりの最大保持期間 (MaxDumpsterTime パラメータ) は、7 日を表す 07.00:00:00 の値に構成することをお勧めします。これは、長時間の停止が発生しても電子メールが失われないようにするために十分な時間です。トランスポート収集機能を使用する場合、トランスポート収集キューをホストするために、ハブ トランスポート サーバー上に追加のディスク領域が必要です。必要な記憶域の容量は、MaxDumpsterSizePerStorageGroup の値と、ハブ トランスポート サーバーが含まれている Active Directory サイト内の連続レプリケーションを使用するすべてのメールボックス サーバー上にあるストレージ グループの数を乗算した値にほぼ等しくなります。

トランスポート収集を有効化して構成する方法の詳細については、「トランスポート収集を構成する方法」を参照してください。

CCR ソリューションの確認

CCR ソリューションのインストールを完了した後、または大幅な構成の変更を行った後には、CMS の稼働状態、および両方のノードが CMS をサポートするように正しく構成されていることを確認することをお勧めします。

CMS の稼働状態を確認する方法として、Test-ReplicationHealth、Get-StorageGroupCopyStatus、Get-ClusteredMailboxServerStatus の各コマンドレットを実行することをお勧めします。

  • Test-ReplicationHealth は、Exchange 2007 SP1 で新たに導入されたコマンドレットです。このコマンドレットは、連続レプリケーションおよび連続レプリケーション パイプラインの予防的監視用に設計されています。Test-ReplicationHealth コマンドレットは、レプリケーション、クラスタ サービス、およびストレージ グループ レプリケーションのすべての側面をチェックし、状態を再生して、レプリケーション システムの詳細な概要を提供します。Test-ReplicationHealth コマンドレットの詳細については、「Test-ReplicationHealth」を参照してください。
  • Get-StorageGroupCopyStatus コマンドレットは、各ストレージ グループの現在のレプリケーションの状態情報を表示します。CCR 環境内にあるストレージ グループの状態を表示する方法の詳細については、「Exchange 管理シェルを使用してクラスタ連続レプリケーション コピーの状態を表示する方法」を参照してください。
  • Get-ClusteredMailboxServerStatus コマンドレットは、CMS の基本的な動作状態を表示します。CMS の基本的な動作状態を取得する手順の詳細については、「クラスタ化メールボックス サーバーの状態を表示する方法」を参照してください。

両方のノードで CMS をオンラインにできるかどうかを確認する場合は、Move-ClusteredMailboxServer コマンドレットを使用して CMS を各ノードに移動することをお勧めします。Exchange 2007 SP1 では、Exchange 管理コンソールのクラスタ化メールボックス サーバーの管理ウィザードを使用して、ノード間で CMS を移動し、両方のノードで CMS をオンラインにできるかどうかを確認することもできます。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。