クラスタ連続レプリケーションの計画

  • [アーティクル]

 

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

トピックの最終更新日: 2008-07-23

クラスタ連続レプリケーション (CCR) の展開は、ローカル連続レプリケーション (LCR) の展開やシングル コピー クラスタ (SCC) の展開と似ていますが、いくつかの重要な違いを考慮する必要があります。CCR について満たしている必要のある一般的な要件や、ハードウェア、ソフトウェア、ネットワーク、およびクラスタについて満たしている必要のある要件があります。

クラスタ連続レプリケーションの一般的な要件

CCR を展開する前に、以下のシステム全体の要件が満たされていることを確認します。

  • ストレージ グループごとに 1 つのデータベースを使用する必要があります。CCR 環境内でストレージ グループを作成するときは、1 つのデータベースしか含めることができません。この方法によって、より管理しやすい Microsoft Exchange ストレージのトポロジが作成され、回復性が向上します。
  • ドメイン ネーム システム (DNS) が実行されている必要があります。通常は、この DNS サーバーで、動的更新を受け付けるように設定しておくことをお勧めします。DNS サーバーが動的更新を受け付けない場合は、クラスタ化メールボックス サーバーごとに 1 つ、およびクラスタ自体について 1 つの DNS ホスト (A) レコードを作成する必要があります。このレコードを作成しないと、Exchange は正常に動作しません。Exchange 用に DNS を構成する方法の詳細については、マイクロソフト サポート技術情報の記事 322856「Exchange Server と一緒に使用する際の DNS の構成方法」を参照してください。
  • クラスタ ノードが、コンピュータの参加する Active Directory ディレクトリ サービス ドメイン名とは異なる名前を持つディレクトリ名前付けサービス ゾーンに属している場合、DNSHostName プロパティには既定ではサブドメイン名が含まれません。この状況では、ファイル レプリケーション サービス (FRS) などの一部のサービスが正しく動作するように、DNSHostName プロパティを変更する必要が生じる場合があります。詳細については、マイクロソフト サポート技術情報の記事 240942「Active Directory の DNSHostName プロパティにサブドメインが含まれない」を参照してください。
  • すべてのクラスタ ノードは同じドメインのメンバ サーバーである必要があります。Microsoft Exchange Server 2007 は、Active Directory サーバーでもあるノード、または異なる Active Directory ドメインのメンバであるノードではサポートされません。
  • Exchange 2007 をインストールする前に、クラスタが形成されている必要があります。Windows Server 2008 フェールオーバー クラスタ形成の詳細については、「Windows Server 2008 でのクラスタ連続レプリケーションのインストール」を参照してください。Windows Server 2003 フェールオーバー クラスタ形成の詳細については、「シングル コピー クラスタのインストール」を参照してください。
  • クラスタ化メールボックス サーバー (CMS) の名前は 15 文字以内にする必要があります。
  • Exchange 2007 がインストールされているクラスタには、Exchange Server 2003、Exchange 2000 Server、またはどのクラスタ対応バージョンの Microsoft SQL Server も含めることはできません。Exchange 2007 を、このような他のアプリケーションと共にクラスタ内で実行することはサポートされていません。データベース アプリケーションがクラスタ化されていない場合には、SQL Server 2005 Express Edition または他のデータベース アプリケーション (Microsoft Office Access など) と共にクラスタで Exchange 2007 を実行できます。
  • Exchange 2007 をインストールする前に、Exchange データをインストールするフォルダが空であることを確認します。
  • クラスタ化メールボックス サーバーのホストとして構成されているクラスタ内のすべてのノードに、同じバージョンの Exchange 2007 をインストールする必要があります。さらに、オペレーティング システムおよび Exchange ファイルは、クラスタ内のすべてのノードで同じパスとドライブにインストールする必要があります。それには、すべてのコンピュータを (まったく同一ではなくても) 類似したディスク構成にする必要があります。
  • クラスタ サービス アカウントは、クラスタ化メールボックス サーバーをホストできる各ノードのローカルの Administrators グループのメンバである必要があります。
  • 既定のクラスタ グループからクラスタ化メールボックス サーバーを含むリソース グループにリソースをインストール、作成、または移動しないでください。また、クラスタ化メールボックス サーバーのあるグループからのリソースを、既定のクラスタ グループに対してインストール、作成、または移動しないでください。既定のクラスタ グループには、クラスタ IP アドレス、ネットワーク名、およびクォーラム リソースのみを含める必要があります。リソースを既定のクラスタ グループに移動したり、既定のクラスタ グループと結合したりすることはサポートされていません。
    important重要 :
    以前のバージョンの Exchange を実行するクラスタでは、Microsoft 分散トランザクション コーディネータ (MSDTC) のクラスタ化されたインスタンスが必要です。Exchange 2007 ではクラスタ化された MSDTC リソースは不要です。CCR 環境でのクラスタ化メールボックス サーバーでは、MSDTC リソースを使用しません。そのため、MSDTC リソースをフェールオーバー クラスタにインストールする必要はありません。サード パーティのアプリケーションは、COM+ との依存関係のため、MSDTC リソースを必要とする場合があります。Windows Server 2003 では、MSDTC クラスタ リソースはクラスタ内の共有記憶域を使用する必要があります。CCR 環境への共有記憶域の追加は推奨されません。Windows Server 2008 は、Windows Server 2008 フェールオーバー クラスタにおける共有記憶域の要件を解消する、ローカルの非クラスタ化 MSDTC インスタンスを提供します。Windows Server 2008 での MSDTC の変更の詳細については、Windows Server 2008 のヘルプを参照してください。

クラスタ連続レプリケーションのハードウェア要件

ハードウェアの計画に関する一般的な情報については、「プロセッサ構成の計画」および「ディスク記憶域の計画」を参照してください。CCR 環境に固有のハードウェア要件は以下のとおりです。

  • Windows Server 2003 でファイル共有監視付きのマジョリティ ノード セット (MNS) クォーラムを使用する場合、クラスタを構成できるノードの数は 2 です。クラスタ内にノードが 1 つしかない場合や、ノードが 3 つ以上ある場合は、ファイル共有監視機能付きの MNS クォーラムは使用できません。代わりに、クラスタ内に 3 つ以上のノードが必要な、従来の MNS クォーラムを使用する必要があります。

  • Windows Server 2008 でノードおよびファイル共有マジョリティ クォーラムを使用する場合は、クラスタを構成できるノードの数は 2 です。クラスタ内にノードが 1 つしかない場合や、ノードが 3 つ以上ある場合は、ノードおよびファイル共有マジョリティ クォーラムは使用できません。代わりに、クラスタ内に 3 つ以上のノードが必要な、ノード マジョリティ クォーラムを使用する必要があります。

    note注 :
    ファイル共有監視付きの MNS クォーラムまたはノードおよびファイル共有マジョリティ クォーラムを使用する、2 ノードのフェールオーバー クラスタを使用することをお勧めします。こうすると、クラスタ内に 3 台目の投票者ノードは不要になります。

  • 使用されるサーバーは、インストール先のオペレーティング システムの Microsoft Windows テスト済み製品カタログに一覧表示されている必要があります。ただし、クラスタで共有記憶域が使用されていない場合は、サーバーがクラスタ カテゴリに一覧表示されている必要はありません。

  • メールボックス サーバーの役割をホストする 2 台のサーバーは、以下の項目について同等である必要があります。

    • CPU
    • メモリ
    • 入出力 (I/O) 機能
    • ネットワーク
    • ベンダ
    • 使用可能なディスク格納域 (ディスク容量と入出力操作機能を含む)

クラスタ連続レプリケーションのクォーラム要件

通常、クラスタ化アプリケーションは、インストール先のクラスタで使用されるクォーラムの種類を問いません。CCR 環境のクォーラム コンポーネントを設計する場合は、以下の推奨事項および用件を確認してください。

  • Windows Server 2008 では、CCR のクォーラムの種類として、ノードおよびファイル共有マジョリティ クォーラムを強くお勧めします。
  • Windows Server 2003 では、CCR のクォーラムの種類として、ファイル共有監視付きの MNS クォーラムを強くお勧めします。

CCR で上記のいずれかのクォーラムの種類を使用する場合、Microsoft Windows テスト済み製品カタログにノードが一覧表示されている必要はありません。

CCR で共有記憶域クォーラムを使用する場合、Microsoft Windows テスト済み製品カタログにシステム全体が一覧表示されている必要があります。

Exchange Server 2007 Service Pack 1 (SP1) では、ファイル共有監視またはファイル共有マジョリティが構成されていない場合、2 ノード クラスタ構成がセットアップによってブロックされます。これは、(マジョリティが維持されないため) この構成でクラスタ内のノードの損失を処理できず、クラスタがオフラインになるからではありません。

クラスタ連続レプリケーションのソフトウェア要件

CCR 環境のソフトウェア要件は以下のとおりです。

  • クラスタ内の両方のノードで、Windows Server 2008 Enterprise オペレーティング システムまたは Windows Server 2003 Enterprise Edition オペレーティング システムが、クラスタの各ノードに同じブートおよびシステム ドライブ文字を使用してインストールされている必要があります。クラスタ内の一方のノードで Windows Server 2008 を実行し、もう一方のノードで Windows Server 2003 を実行することはできません。フェールオーバー クラスタ内でオペレーティング システムの異なるバージョンを混在させることはできません。
  • Windows Server 2003 に RTM (Release To Manufacturing) 版の Exchange 2007 を使用して CCR 環境を構築する場合、フェールオーバー クラスタ内の両方のノードに Windows Server 2003 Service Pack 2 (SP2) をインストールするか、Windows Server 2003 SP1 とマイクロソフト サポート技術情報の記事 921181「それが Windows Server 2003 Service Pack 1-based サーバー クラスタにファイル共有証拠機能と構成可能なクラスタ ハートビート機能を追加するアップデートが入手できます。」で提供されている修正プログラムをインストールする必要があります。この修正プログラムは、Windows Server 2003 SP2 に含まれています。Windows Server 2003 で Exchange 2007 SP1 を使用して CCR 環境を構築する場合、フェールオーバー クラスタ内の両方のノードに Windows Server 2003 SP2 をインストールする必要があります。
  • クラスタは、従来の MNS クォーラムで構成された 3 ノード クラスタであるか、またはファイル共有監視付きの MNS クォーラムで構成された 2 ノード クラスタである必要があります。通常、Windows Server 2003 ではファイル共有監視付きの MNS クォーラムを使用する 2 ノード クラスタを使用し、Windows Server 2008 ではノードおよびファイル共有マジョリティ クォーラムを使用する 2 ノード クラスタを使用することが前提となっています。
  • MNS のファイル共有監視またはファイル共有マジョリティ クォーラムを専用のコンピュータでホストする必要はありません。Windows Server を実行しているコンピュータであれば、どれでもホストできます。ただし、ファイル共有監視は、Exchange 管理者の制御下にあるハブ トランスポート サーバー (または他の Exchange サーバー) でホストすることをお勧めします。
  • クラスタには、メールボックス サーバーの役割のみをインストールできます。フェールオーバー クラスタの一部であるコンピュータに、その他のサーバーの役割をインストールすることはできません。

クラスタ連続レプリケーションのネットワーク要件

クライアントとクラスタの通信に使用されるネットワークが正しく構成されていることが重要です。ここでは、プライベート ネットワークおよびパブリック ネットワークの設定が正しく構成されていることを確認するために必要な手順のリンクを提供します。また、クラスタ内でネットワーク接続の順序が正しく構成されていることも確認する必要があります。CCR 環境のネットワーク インフラストラクチャを設計する際は、以下の点を考慮します。

  • 各ノードには、Windows クラスタ化で使用できる少なくとも 2 つのネットワーク アダプタが必要です。クライアントおよびその他のサーバーは、2 つのネットワーク アダプタのどちらかからアクセスできるだけでかまいません。もう一方のネットワーク アダプタは、クラスタ内の通信に使用されます。推奨される構成は、プライベート ネットワークを内部クラスタ通信専用に使用し、パブリック ネットワークを混在通信用として指定することです。
  • クラスタ パブリック ネットワークは、他の Exchange サーバー、および Active Directory や DNS などのその他のサービスへの接続を提供する必要があります。ネットワーク アダプタ チームや同様のテクノロジを使用することにより、これが単一障害点になることを防止できます。
  • 独立したクラスタ プライベート ネットワークを提供する必要があります。プライベート ネットワークは、クラスタ ハートビートに使用されます。プライベート ネットワークでは DNS は必要ありません。
  • ハートビート要件は、2 データセンター構成のパブリック ネットワークの帯域幅と待機時間についての最も厳格な要件ではない場合があります。クライアント アクセス、Active Directory、トランスポート、連続レプリケーション、およびその他のアプリケーション トラフィックを含む全体的なネットワーク負荷を評価し、環境に必要なネットワーク要件を判断する必要があります。
  • 再シード時間を最大にするために、CCR 環境ではギガビット イーサネットを使用することをお勧めします。ギガビット イーサネットが推奨される理由の詳細については、このトピックの「データベース サイズとクラスタ連続レプリケーション」を参照してください。
  • Exchange 2007 RTM 版では、クラスタ化メールボックス サーバーを含むリソース グループは、ネットワーク名リソースを 1 つだけ持つことができます。Exchange 2007 RTM では、クラスタ化メールボックス サーバーを含むリソース グループが複数のネットワーク名リソースを持つことはできません。ただし、この制限は Exchange 2007 SP1 には適用されません。クラスタ化メールボックス サーバーを Exchange 2007 SP1 にアップグレードすると、クラスタ化メールボックス サーバーを含むリソース グループは、複数のネットワーク名リソースを持つようになります。

Windows Server 2008 で CCR をインストールするためのネットワーク要件

Windows Server 2008 で CCR をインストールするためのネットワーク要件は、Windows Server 2003 で CCR をインストールするための要件と多少異なります。Windows Server 2003 のように、Windows Server 2008 で CCR をインストールする場合、両方のノードおよびクラスタ化メールボックス サーバー (CMS) に使用可能な十分な IP アドレスがある必要があります。ただし、Windows Server 2008 のみで使用可能な一部の追加オプションがあります (Windows Server 2003 では使用できません)。

  • クラスタ ノードが異なるサブネット上に存在できます。Windows Server 2003 では、各ノードのそれぞれのネットワークのネットワーク インターフェイスは、他のノードの対応するネットワークと同じサブネット上に存在する必要があります。この要件は、Windows Server 2008 にはありません。このため、フェールオーバー クラスタ内のノードは、ネットワーク ルータを越えて通信できます。ノードの通信に仮想 LAN (VLAN) 技術を使用する必要はありません。
  • CCR 環境で複数のサブネットを使用する場合、DNS レプリケーションが、ノード間の CMS のフェールオーバーまたはハンドオフの発生後にクライアントから CMS への接続性に影響を及ぼす場合があります。クライアントおよび他のサーバーは、IP アドレスが変更されたクラスタ化メールボックス サーバーと通信する場合、DNS が新しい IP アドレスで更新され、すべてのローカル DNS キャッシュが更新されるまで、クラスタ化メールボックス サーバーとの通信を再確立できません。DNS の変更がクライアントおよび他のサーバーに伝わるまでにかかる時間を最小限に抑えるため、クラスタ化メールボックス サーバーのネットワーク名リソースの DNS TTL (Time to Live) 値を 5 分に設定することをお勧めします。ほとんどの環境では、CMS のネットワーク名リソースにのみ DNS TTL 値を設定することをお勧めします。ただし、管理目的で名前によってクラスタに接続する Exchange 管理ツール以外のツールを含む環境では、クラスタのネットワーク名リソースに、より低い TTL 値を設定することをお勧めします。複数のサブネットでの CMS またはスタンバイ クラスタの展開で使用できるように、ネットワーク名リソースの DNS TTL 値を構成する手順の詳細については、「ネットワーク名リソースの DNS TTL 値を構成する方法」を参照してください。
  • Windows Server 2008 フェールオーバー クラスタ化の機能は、静的エントリ経由と同様に、クラスタ IP アドレス リソースが動的ホスト構成プロトコル (DHCP) サーバーからアドレス指定を取得する場所にあります。クラスタ ノード自身が DHCP サーバーから IP アドレスを取得するように構成されている場合、既定の動作ですべてのクラスタ IP アドレス リソース用に IP アドレスが自動的に取得されます。クラスタ ノードによって IP アドレスが静的に割り当てられた場合、クラスタ IP アドレス リソースは同様に静的な IP アドレスで構成する必要があります。そのため、クラスタ IP アドレス リソースの IP アドレスは、物理ノードおよびそのノード上で各固有のインターフェイスを構成した後に、割り当てられます。クラスタ化メールボックス サーバーの DHCP の使用は推奨されません。CMS の DHCP を使用する前に、以下を考慮することをお勧めします。
    • IP アドレスが変更された場合、クラスタ サービスは DHCP が有効な IP アドレス リソースをオンラインにしません。
    • DHCP サーバーは、クラスタ化メールボックス サーバーが使用するすべての DHCP 割り当てアドレスについて無制限のリースを付与するように構成する必要があります。
  • Windows Server 2008 およびそのクラスタ サービスも、インターネット プロトコル Version 6 (IPv6) をサポートします。これには、単独または 1 つのクラスタ内で一緒に IPv6 IP アドレス リソースおよび IPv4 IP アドレス リソースをサポートできることも含まれています。さらに、フェールオーバー クラスタはイントラサイト自動トンネリング アドレス設定プロトコル (ISATAP) もサポートしており、DNS での動的な登録が許可されている IPv6 アドレスのみをサポートします (AAAA ホスト レコードおよび IP6.ARPA 逆引き参照ゾーン)。IPv6 アドレスおよび IP アドレスの範囲は、Windows Server 2008 を実行しているコンピュータに Exchange 2007 SP1 が展開されており、そのコンピュータで IPv6 と IPv4 の両方が有効化されており、ネットワークで両方の IP アドレス バージョンがサポートされている場合にのみ使用できます。Exchange 2007 SP1 がこの構成で展開されている場合、すべてのサーバーの役割が、IPv6 アドレスを使用しているデバイス、サーバー、およびクライアントとデータを送受信できます。Windows Server 2008 の既定のインストールでは、IPv4 と IPv6 がサポートされています。Exchange 2007 SP1 が Windows Server 2003 にインストールされている場合、IPv6 アドレスはサポートされません。Exchange 2007 SP1 での IPv6 アドレスのサポートの詳細については、「Exchange 2007 SP1 および SP2 での IPv6 サポート」を参照してください。

Windows Server 2003 で CCR をインストールするためのネットワーク要件

Windows Server 2003 で CCR をインストールする場合、2 ノードの CCR 環境にクラスタ化メールボックス サーバーを作成する際に十分な数の静的 IP アドレスが利用可能である必要があります。IP アドレスは、クラスタおよびクラスタ化メールボックス サーバーに必要です。また、IP アドレスは、各ノードのパブリック ネットワークとプライベート ネットワークの両方に必要です。

  • プライベート アドレス   各ノードで、クラスタ プライベート ネットワークに使用するネットワーク アダプタごとに 1 つの静的 IP アドレスが必要です。パブリック ネットワークの 1 つとして同一のサブネットまたはネットワーク上で使用されていない静的 IP アドレスを使用する必要があります。サブネット マスクに 255.255.255.0 を使用し、2 ノードそれぞれのプライベート IP アドレスとして 10.10.10.10 および 10.10.10.11 を使用することをお勧めします。現在のパブリック ネットワークでネットワーク アドレス 10.x.x.x とサブネット マスク 255.255.255.0 を使用している場合は、別のプライベート ネットワーク IP アドレスとサブネット マスクを使用することをお勧めします。複数のプライベート ネットワークを構成する場合は、プライベート ネットワーク アダプタとプライベート ネットワークごとに一意のアドレスとサブネットが必要です。
  • パブリック アドレス   各ノードで、クラスタ パブリック ネットワークに使用するネットワーク アダプタごとに 1 つの静的 IP アドレスが必要です。また、クライアントと管理者がサーバー クラスタとクラスタ化メールボックス サーバーにアクセスできるように、サーバー クラスタとクラスタ化メールボックス サーバーに対しても静的 IP アドレスが必要です。プライベート ネットワークの 1 つとして同一のサブネットまたはネットワーク上で使用されていない静的 IP アドレスを使用する必要があります。

クラスタ内のすべてのノード用のプライベート ネットワークは同じサブネット上にある必要がありますが、2 つのノード間の相互接続では VLAN スイッチを使用できます。VLAN を使用する場合は、ポイント間のラウンド トリップ待ち時間が 0.5 秒未満である必要があります。さらに、2 つのノード間のリンクは、ノード上で稼働する Windows Server 2003 オペレーティング システムから単一のポイント間接続に見える必要があります。単一障害点を回避するために、ノード間の異なるパスには独立した VLAN ハードウェアを使用します。Windows Server 2008 で実行しているフェールオーバー クラスタには、この制限は適用されません。

クラスタ内のすべてのノードのパブリック ネットワークは同じサブネット上にある必要があり、プライベート ネットワークに使用されているサブネットとは異なるサブネットを使用する必要があります。Windows Server 2008 で実行しているフェールオーバー クラスタには、この制限は適用されません。

Windows におけるクラスタ ネットワーク接続の順序は、パブリック ネットワークが接続順序の一覧の最上位になるように構成する必要があります。また、クラスタ内のネットワークの優先度は、プライベート ネットワークが優先順位の最上位になるように構成する必要があります。

複数のデータセンターの構成で Windows Server 2003 に CCR をインストールする場合は、次の操作を行います。

  • クライアント アクセスに使用されるすべてのネットワークは、クライアントがどのデータセンターからもクラスタ化メールボックス サーバーにアクセスできるように、十分な帯域幅を提供し、待機時間を短縮する必要があります。
  • トランザクション ログのレプリケートに使用されるすべてのネットワークは、可能な場合は常にログ ファイルのバックログがない状態になるように、ログ ファイルを適切なタイミングでコピーできるだけの十分な帯域幅を提供し、待機時間を短縮する必要があります。
  • クラスタ ハートビートに使用されるネットワークは、ハートビート パケットの送受信を、構成された必須再試行回数内で行うことができる必要があります。Windows Server 2003 の SP2 に CCR をインストールする場合や、Windows Server 2003 の SP1 とマイクロソフト サポート技術情報の記事 921181「それが Windows Server 2003 Service Pack 1-based サーバー クラスタにファイル共有証拠機能と構成可能なクラスタ ハートビート機能を追加するアップデートが入手できます。」で提供されている修正プログラムに CCR をインストール場合は、インターフェイス ハートビートとノード ハートビートの再試行が喪失した回数を、クラスタ構成プロパティとして指定します。Windows Server 2008 に CCR をインストールする場合、この更新プログラムは不要です。いずれの場合も、ハートビートの送出間隔は 1.2 秒と変わりませんが、回復処理を行うための条件となる、ハートビート喪失 (パケットのドロップ、過剰な待機時間、インターフェイス エラー、ノード エラーなどの原因による) の発生回数を増やすようにクラスタを構成できます。このプロパティの値は、経過時間ではなく、ハートビート喪失の発生回数で指定します。したがって、たとえば、最初のハートビートの喪失から 5 秒経過したらインターフェイス エラーの可能性が認識されるようにクラスタを構成することはできません。その代わりに、ハートビートの喪失が 5 回発生したらインターフェイス エラーの可能性が認識されるように構成できます。また、ハートビート期間でエラーが発生するタイミングにもよりますが、5 回の喪失は約 5 ～ 6 秒に相当します。これらの設定では、最小許容値が 2 秒で、最大許容値が 20 秒です。

CCR 用の Windows 2003 ネットワークの最適化

Windows Server 2003 で CCR を使用する場合は、使用するネットワーク リンクの速度と待機時間に応じて、Windows Server TCP/IP 設定を最適化することをお勧めします。特に、アクティブ ノードとパッシブ ノードで、伝送制御プロトコル (TCP) Receive Window サイズと Request for Comments (RFC) 1323 ウィンドウのスケール オプションの調整が必要になる場合があります。さらに、アドレス解決プロトコル (ARP) キャッシュの有効期限の構成と、TCP/IP 詳細設定オプションの無効化を Windows レジストリの Windows Server 2003 Scalable Networking Pack (SNP) に対して行うことが有益であることがわかります。

これらの推奨事項に加えて、IP セキュリティ (IPsec) プロトコルを使用する環境では、CCR 環境全体を通じて IPsec を構成することをお勧めします。IPsec は、両方のノードで使用するか、またはどちらのノードでも使用しないかのいずれかにします。1 つのノードのみが IPsec を使用するように構成されている場合、IPsec セキュリティ アソシエーションのプロセスがパケット遅延またはパケット損失を引き起こす原因になります。

TCP Recieve Window および RFC 1323 のスケールのオプション

TCP Receive Window サイズは、接続で 1 度に受信できる最大のデータ量 (バイト単位) です。受信側のコンピュータからの受信確認と TCP ウィンドウの更新を待機する前に、送信側のコンピュータが送信できるデータ量はこの最大値のみです。この設定を調整して、ログ配布時のスループットを向上させた方がよい場合があります。

TCP スループットを最適化するには、送信側のコンピュータが、送信側と受信側の間のパイプが十分に満たされるパケットを送信する必要があります。ネットワークのパイプの容量は、パイプの帯域幅と待機時間 (ラウンド トリップ時間) に基づきます。待機時間が長いほど、受信確認の間にデータを送信する時間が長くなるので、容量は大きくなります。TCP ウィンドウ サイズを増やすことにより、システムでは送信するデータを増やして受信確認の合間の時間を利用できます。

TCP/IP 標準では、16 ビットの TCP ウィンドウ サイズのフィールドに指定可能な最大値である 65,535 オクテットまで Recieve Window サイズが許可されます。帯域幅が広く、高遅延のネットワーク パフォーマンスを向上させるには、RFC 1323『TCP Extensions for High Performance (高いパフォーマンスの TCP 拡張機能)』に示されているスケーラブル ウィンドウを使用して、Windows Server TCP/IP が 65,535 オクテットを超える Receive Window サイズを通知する機能をサポートするようにします。ウィンドウ スケールを使用するとき、通信中のホストは、ファイル転送プロトコルで頻繁に使用されるような大きな複数のパケットを送受信できるウィンドウ サイズが受信側のバッファで保留にされるようにネゴシエートできます。RFC 1323 には、接続確立時に TCP がウィンドウ サイズのスケール ファクタをネゴシエートできるようにすることで、さらに大きい Receive Window サイズをサポートする方法が示されています。

次の 2 つのレジストリ エントリを修正することで、Windows Server 2003 を実行しているコンピュータの TCP Receive Window サイズおよび RFC 1323 ウィンドウのスケールのオプションを最適化できます。TCPWindowSize および TCP1323Opts です。これらの機能の詳細については、マイクロソフト サポート技術情報の記事 224829「Windows 2000 および Windows Server 2003 の TCP 機能について」を参照してください。

ネットワーク リンクとネットワーク遅延に基づいたレジストリ エントリに対して最適な設定を行うために、Version 13 またはそれ以降の Exchange 2007 メールボックス サーバーの役割の記憶域要件計算用シートを使用することをお勧めします。この計算用シートは、Exchange チーム ブログからダウンロードできます (このサイトは英語の場合があります)。記憶域計算用シートには、サーバー上のレジストリ値に入力する手順も含まれています。

note注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。 

ARP キャッシュの有効期限

ARP キャッシュは、IP アドレスをメディア アクセス制御 (MAC) アドレスにマップするメモリ内テーブルです。ARP キャッシュのエントリは、送信パケットがエントリ内の IP アドレスに送信されるたびに参照されます。既定では、Windows Server 2003 が ARP キャッシュ サイズをシステムのニーズに合わせて自動的に調整します。送信データグラムによるエントリの使用が 2 分間行われないと、エントリは ARP キャッシュから削除されます。参照されているエントリは、10 分後に ARP キャッシュから削除されます。手動で追加されたエントリは、キャッシュから自動的に削除されることはありません。

マイクロソフト内の IT 部門による内部テストによって、既定の ARP キャッシュの有効期限の設定が CCR 環境と SCR 環境のパケット損失を引き起こしていることが示されました。パケット損失が生じた場合、送信側のサーバーは損失データを再配信する必要があります。連続レプリケーション環境では、ログ ファイルがパッシブ ノードにできる限り迅速にコピーされることが重要です。さらに、パケット損失によるデータの再配信はログ配布のスループットに悪影響を及ぼします。

Windows レジストリの ArpCacheMinReferencedLife TCP/IP パラメータを変更して、ARP キャッシュの有効期限を制御できます。このパラメータによって、ARP キャッシュ テーブルから参照されるエントリを削除せずに残しておく時間が判断されます。マイクロソフト内部では、ArpCacheMinReferencedLife レジストリ値の最適な設定値は、ネットワーク上のルーターが ARP キャッシュの有効期限に対して使用する値と同じ値 (4 時間) であることを確認しています。

各自の環境で ArpCacheMinReferencedLife の値を変更する前に、Microsoft ネットワーク モニタまたは同様のキャプチャ ツールを使用して、アクティブ ノードからパッシブ ノードへのログのコピーに使用するネットワーク インターフェイス上のネットワーク トラフィックを収集および分析することをお勧めします。ArpCacheMinReferencedLife レジストリ値を変更する詳細な手順については、「Appendix A: TCP/IP Configuration Parameters」を参照してください (このサイトは英語の場合があります)。

Scalable Networking Pack の TCP/IP 詳細設定の機能

Windows Server 2003 Scalable Networking Pack (SNP) は Windows Server 2003 の個別の更新プログラムで、Windows ネットワーク スタックを加速するステートフル オフロードとステートレス オフロードがあります。この更新プログラムには、TCP Chimney オフロード、Receive Side Scaling (RSS)、およびネットワーク ダイレクト メモリ アクセス (NetDMA) が含まれます。

TCP Chimney はステートフル オフロードです。TCP Chimney オフロードは、TCP/IP プロセスがハードウェア内の TCP/IP プロセスを制御できるネットワーク アダプタにオフロードできるようにします。

RSS および NetDMA はステートレス オフロードです。単一のコンピュータに複数の CPU が存在する場所では、単一の CPU に対する処理を行う "受信" プロトコルが Windows ネットワーク スタックによって制限されます。RSS は、複数の CPU 間に負荷が分散されるようにネットワーク アダプタから受信するパケットを有効にすることによりこの問題を解決します。NetDMA は、PCI (Peripheral Component Interconnect) バスでダイレクト メモリ アクセス (DMA) エンジンを有効にします。TCP/IP スタックは、コピー操作を制御する CPU を中断する代わりに、データをコピーする DMA エンジンを使用できます。関連するコンポーネントの TCPA では、受信プロセスに役立つ PCI バスのハードウェア DMA エンジンにある別のオフロード機能が使用されます。

これらの機能によって一部の環境ではネットワーク パフォーマンスが向上しますが、他のテクノロジが使用されているために、使用できない状況があります。たとえば、以下のテクノロジのいずれかが使用されている場合、TCP Chimney オフロードおよび NetDMA は使用できません。

  • Windows ファイアウォール
  • インターネット プロトコル セキュリティ (IPsec)
  • インターネット プロトコル ネットワーク アドレス変換 (IPNAT)
  • サードパーティ製のファイアウォール
  • NDIS 5.1 中間ドライバ

さらに、Microsoft Exchange を含め一部の環境で、これらの機能を使用する場合にネットワーク パフォーマンスが低下する既知の問題があります。これらの問題のうちいくつかの詳細については、Exchange チーム ブログの投稿「Windows 2003 Scalable Networking pack and its possible effects on Exchange」を参照してください (このサイトは英語の場合があります)。

note注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。

Windows Server 2003 オペレーティング システム上で動作している CCR 環境では、両方のオペレーティング システムおよびシステムの各ネットワーク インターフェイス カード (NIC) ですべての機能を無効にすることをお勧めします。次の内容に従って、これらの機能を無効にします。

SNP の詳細については、マイクロソフト サポート技術情報の記事 912222「Microsoft Windows Server 2003 Scalable Networking Pack のリリース」およびスケーラブルなネットワークについての Web サイトを参照してください (このサイトは英語の場合があります)。

複数サブネット フェールオーバー クラスタでクラスタ化メールボックス サーバーをフェールオーバーした後の Outlook の動作

地理的に分散した複数のサブネットのフェールオーバー クラスタに CMS を展開しており、その CMS で移動またはフェールオーバーが行われた場合、その CMS の名前は保持されます。ただし、その名前に割り当てられた IP アドレスは保持されません。クライアントと他のサーバーに対するこのサーバーの機能は、DNS による新しい IP アドレスの伝達状況によって異なります。DNS の伝達処理には時間がかかる場合があります。このため、CMS の DNS ホスト レコードの Time to Live (TTL) 値を 5 分 (300 秒) に構成することをお勧めします。CMS の DNS TTL 値を構成する手順の詳細については、「ネットワーク名リソースの DNS TTL 値を構成する方法」を参照してください。CMS の DNS TTL 値を構成した後、変更を有効にするには、CMS を一度停止してから起動する必要があります。

内部の Microsoft Office Outlook クライアントには新しい IP アドレスを使用して接続するための新規または再構成されたプロファイルは必要ありませんが、CMS 名の名前解決で古い IP アドレスから新しい IP アドレスに変更されるように、ローカル DNS キャッシュがクリアされるのを待つ必要があります。IP アドレスが該当する DNS サーバーに伝達された後に、クライアントのコマンド プロンプトから次のコマンドを実行することによって、Outlook クライアントの DNS キャッシュを消去できます。

ipconfig /flushdns

以下のセクションでは、さまざまな構成での Outlook の動作について説明します。

Windows Server 2003 でのストレッチ CCR (1 つのサブネット)

この構成には、1 つのネットワーク名リソースと、そのネットワーク名リソースが依存している 1 つの IP アドレス リソースがあります。DNS では、ネットワーク名は IP アドレスに関連付けられます。IP アドレス リソースを含むすべてのリソースは、クラスタ内の 2 つのノード間を移動できます。Outlook の観点から見ると、フェールオーバー時の唯一のネットワーク変更が IP アドレスとコンピュータの MAC アドレスとの関連付けであり、これはクライアントに対して透過的であるため、IP アドレスの変更は発生しません。

Windows Server 2008 でのストレッチ CCR (2 つのサブネット、IPv4 前提)

この構成には、論理 "OR" として、1 つのネットワーク名リソースと、そのネットワーク名が依存している 2 つの IP アドレス リソースがあります。DNS では、ネットワーク名は現在オンラインになっている IP アドレスに関連付けられます。フェールオーバー中、ネットワーク名リソースがオンラインになると、クラスタ サービスがネットワーク名の DNS エントリを、もう一方のサブネットに対応する 2 番目の IP アドレスで更新します。レコードの更新は、DNS 全体に伝達する必要があります。Outlook の観点から見ると、Outlook は、新規または再構成されたプロファイルを必要としませんが、ネットワーク名をもう一方の IP アドレスに解決できるようにするために、ローカル DNS キャッシュがフラッシュされるまで待機する必要はありません。この操作は、クライアント上で次のコマンドを実行して手動で行うことができます。

IPConfig /flushdns

リモート サイトの SCR を併用したローカル CCR (1 つまたは 2 つのサブネット)

この構成には、1 つのネットワーク名リソースと、そのネットワーク名が依存している 1 つの IP アドレス リソースがあります。IP アドレスを含むすべてのリソースは、クラスタ内の 2 つのノード間を移動できます。Setup.com /recoverCMS を実行することによって SCR ターゲットがアクティブ化されるサイト フェールオーバーでは、CMS は別のサイトまたはクラスタに移されます。このコマンドを実行するときに、リモート サイトのネットワーク名に関連付ける IP アドレスを指定します。セットアップは、ネットワーク名リソースと IP アドレス リソースを作成し、クラスタ サービスは、DNS を新しい IP アドレスで更新します。DNS の更新は、DNS 全体に伝達する必要があります。Outlook の観点から見ると、Outlook は、新規または再構成されたプロファイルを必要としませんが、ネットワーク名をもう一方の IP アドレスに解決できるようにするために、ローカル DNS キャッシュがフラッシュされるまで待機する必要はありません。この操作は、クライアント上で次のコマンドを実行して手動で行うことができます。

IPConfig /flushdns

クラスタ連続レプリケーションの格納域要件

CCR は、Windows クラスタ内の共有記憶域が必要なくなるように設計されています。共有記憶域は、以前のバージョンの Exchange の要件でした。Windows によってサポートされる格納域からは、CCR の唯一の格納域要件は、十分なパフォーマンスと容量です。

CCR では、ストレージ グループやデータベースで使用される格納域についての、入出力に関する追加の考慮事項は発生しません。CCR ストレージ ソリューションを設計する場合は、以下のベスト プラクティスに従うことをお勧めします。

  • ストレージ グループとデータベースの場所は、すべてのクラスタ ノードで同一にする必要があります。
  • データベース ファイルとトランザクション ログ ファイルは、別の論理ユニット番号 (LUN) に格納します。
  • NTFS ファイル システム ボリューム マウント ポイントを使用して、ボリュームをオペレーティング システムが認識できるようにします。
  • ホストされているストレージ グループまたはデータベースに直接、かつ明確に結び付く、認識可能な名前を使用します。ログとデータベースに別のボリュームを使用する場合は、パスでデータの種類を識別できるようにしてください。この方法は、データベースやストレージ グループの数が増えた場合の人為的なミスの防止に役立ちます。既定のインストールを実行した場合、ストレージ グループとデータベースは、Exchange 2007 のインストール先に作成されます。
    note注 :
    Exchange 2007 は、ボリュームのルートへのトランザクション ログまたはデータベース ファイルの配置はサポートしていません。

CCR 環境では、十分なパフォーマンスと容量を提供する格納域が必要です。それぞれのストレージ グループとデータベースについて同じ場所 (ドライブ文字とパス) を使用している 2 つのノードでは、システムのパフォーマンスと容量が同等になるように格納域を構成する必要があります。

データベース サイズとクラスタ連続レプリケーション

CCR で致命的なストレージ エラーまたはデータベースの物理的な破損が発生した場合の第一の対応策は、データのパッシブ コピーを戻し、バックアップからは何も復元しないことです。これにより、アーカイブやテープからの復元に基づく目標回復時間 (RTO) を短縮することの重要性は低くなります。テープから復元する代わりに、データベースのパッシブ コピーをアクティブ化すると、クライアントは数分以内 (数時間ではなく) にデータを利用できます。この意味で CCR は高速回復機構と見なすことができます。Exchange Server 2003 のボリューム シャドウ コピー サービス (VSS) を使用して作成されたハードウェアベースのスナップショットや複製と同じ位置付けになります。

バックアップ不良 (テープの不良または復元の失敗など) が原因の修復作業など、管理者がオフラインのデータベース操作を実行することはよくあります。CCR を使用すると、このようなシナリオは回避され、データベース修復が必要になる可能性が大幅に低くなります。ただし、修復が必要になる状況の割合は大幅に減るものの、実際には、修復が必要になるときは必ずあります。データベースのサイズを決定するときは、最悪の場合のダウンタイムをどれだけ許容できるかを考慮してください。

CCR を使用すると、オンライン保守ウィンドウを拡張できます。CCR ではストレージ グループのパッシブ コピーからバックアップを作成できるので、アクティブなクラスタ ノードのオンライン保守ウィンドウを拡張できます。多くの場合、オンライン保守ウィンドウは 2 倍にすることができます。これにより、メールボックスやデータベースのサイズも拡張できるようになります。

Exchange 2007 には、消失ログ復元 (LLR) と呼ばれる機能があり、これは、ログの損失によってデータベースの不整合が発生する頻度を大幅に低減します。通常、管理者がデータベースを修復する最も一般的な理由は、必要なログが失われたり、破損したりして、データベースをマウントできないときに、データベースを整合状態に戻すためです。LLR には、このようなログの損失または破損のシナリオの多くに対する復元機能が用意されており、修復を行わなくても、データベースのマウントが可能になります。LLR の詳細については、「Exchange 2007 での消失ログの復元とトランザクション ログの処理」を参照してください。

ここまでの説明で、連続レプリケーションを使用すると、リスクを心配する必要なく、データベースを希望のサイズに拡張できるように見えます。ただし、現実はそのようにはいきません。データベースごとに妥当な時間内で完了するオンライン保守は、データベース サイズの制限要因になっています。CCR の場合は、データベースを再シードする必要が生じる可能性もデータベース サイズの制限要因になっています。CCR はデータベースの冗長性を実現します。したがって、データベースのアクティブ コピーが損失または破損した場合は、データベースのパッシブ コピーをアクティブ化することで、短時間のうちにデータベースを回復できます。CCR では、フェールオーバーと呼ばれる処理を通じて自動アクティブ化を実現します。

フェールオーバーが行われた後は、データベースの新しいアクティブ コピーが 1 つしか残りません。パッシブ コピーは存在しないので、データベースの復元ができなくなる可能性があります。ただし、バックアップは残っています。復元を再度有効にするには、損失または破損したデータベースを削除し、データベースのアクティブ コピーから新しいパッシブ コピーを作成および再シードする必要があります。データベースのサイズによっては、この作業には長い時間がかかる場合があります。最悪のシナリオは、すべてのアクティブ コピーが損失または破損することです。その場合は、すべてのパッシブ コピーを再シードする必要があります。CCR 環境でギガビット イーサネットが推奨されるのも、これが理由の 1 つです。

CCR 環境では、ディスクまたはプロセッサの障害がない状態のとき、ギガビット イーサネットによって次の処理速度が達成されます。

  • 単一データベースの再シード : 約 25 MB/秒
  • 複数データベースの再シード (並列) :約 100 MB/秒 (ネットワーク帯域幅による制限あり)

連続レプリケーションを使用すると、最大データベース サイズがさらに拡大する可能性があります。Exchange 2007 では、次の最大データベース サイズを使用することをお勧めします。

  • 連続レプリケーションを使用しないメールボックス サーバーでホストされるデータベース :100 ギガバイト (GB)

  • 連続レプリケーションとギガビット イーサネットを使用するメールボックス サーバーでホストされるデータベース :200 GB

    note注 :
    大規模なデータベースでは、修復時のシナリオに対応できるように、より帯域幅の広い、新しいストレージ テクノロジが必要になる場合もあります。
    important重要 :
    データベースの本来の最大サイズは、組織で導入されているサービス レベル アグリーメント (SLA) によって決まります。組織の SLA で指定された期間内にバックアップおよび復元できる最大のサイズを計算することで、データベースの最大サイズが決まります。

クラスタ連続レプリケーションの Active Directory の要件

CCR では、Active Directory インフラストラクチャに関する、スタンドアロン サーバーと同じすべての要件に加えて、次の要件が追加されます。複数データセンターのソリューションでは、任意の時点で、クラスタ化メールボックス サーバーをいずれのデータセンターがホストしている可能性もあるため、両方のデータセンターが十分な Active Directory インフラストラクチャ サポートを提供する必要があります。この容量は、他のデータセンターが使用できない場合にも存在する必要があります。さらに、クラスタ内のノードはすべて同じドメインに存在する必要があり、クラスタ サービス アカウントは適切なアクセス許可を持っている必要があります。

note注 :
クラスタのすべてのノードは同じサイトのメンバでなければならないため、地理的に分散している 1 つのクラスタ内のメールボックス サーバーでは、単一の Active Directory サイトがデータセンター間に広がっている必要があります。ただし、両方のデータセンターにある他のサーバーが、同じサブネットまたは同じ Active Directory サイトに存在する必要はありません。

クラスタ連続レプリケーションのサービス アカウント要件

Windows Server 2008 に CCR をインストールする場合、クラスタ サービス アカウントは LocalSystem (SYSTEM) アカウントで実行されます。

Windows Server 2003 に CCR をインストールする場合、クラスタ サービス アカウントにはドメイン アカウントを使用する必要があります。クラスタ内のノードはすべて同じドメインのメンバである必要があります。また、クラスタ内のノードはすべて同じクラスタ サービス アカウントを使用する必要があります。クラスタ サービス アカウントは、クラスタ化メールボックス サーバーをホストできる各ノードのローカルの Administrators グループのメンバである必要もあります。

クラスタ サービス アカウントは、フェールオーバー クラスタのネットワーク名リソースがオンラインになったときに、このリソースで識別および関連付けられるコンピュータ アカウントの作成と保守の役割を担います。クラスタ サービス アカウントに適切なアクセス許可が設定されるようにするには、マイクロソフト サポート技術情報の記事 307532「コンピュータ オブジェクト変更時のクラスタ サービス アカウントのトラブルシューティング方法」を参照してください。詳細については、マイクロソフト サポート技術情報の記事 251335「ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない」を参照してください。

クラスタ連続レプリケーションおよびパブリック フォルダ データベース

CCR およびパブリック フォルダ レプリケーションは、Exchange に組み込まれた 2 つのまったく異なるレプリケーション フォームです。連続レプリケーションとパブリック フォルダ レプリケーションの間には相互運用性に関して制限があるため、Exchange 組織内の複数のメールボックス サーバーがパブリック フォルダ データベースを保持している場合、パブリック フォルダ レプリケーションが有効になり、パブリック フォルダ データベースは CCR 環境でホストされません。

Exchange 組織でパブリック フォルダ データベースと CCR を使用するための推奨構成を以下に示します。

  • Exchange 組織内にメールボックス サーバーが 1 つだけあり、それが CCR 環境内のクラスタ化メールボックス サーバーである場合は、メールボックス サーバーはパブリック フォルダ データベースをホストできます。この構成では、Exchange 組織に単一のパブリック フォルダ データベースが存在しています。したがって、パブリック フォルダ レプリケーションは無効になります。このシナリオでは、パブリック フォルダ データベースの冗長性は CCR を使用して達成されます。CCR は、パブリック フォルダ データベースに対して 2 つのコピーを維持します。
  • 複数のメールボックス サーバーがある場合は、Exchange 組織全体でパブリック フォルダ データベースが 1 つしかない場合に限り、CCR 環境でパブリック フォルダ データベースをホストできます。このシナリオでは、CCR を使用することでパブリック フォルダ データベースの冗長性も得られます。この構成では、Exchange 組織に単一のパブリック フォルダ データベースが存在しています。したがって、パブリック フォルダ レプリケーションは無効になります。
  • パブリック フォルダ データを CCR 環境に移行している場合、パブリック フォルダ レプリケーションを使用して、SCC 内のスタンドアロン メールボックス サーバーまたはクラスタ化メールボックス サーバーから CCR 環境内のクラスタ化メールボックス サーバーにパブリック フォルダ データベースのコンテンツを移動できます。CCR 環境でのパブリック フォルダ データベースの作成後、パブリック フォルダ データが完全に CCR 環境にレプリケートされるまでの間だけ、他のパブリック フォルダ データベースが存在する必要があります。レプリケーションが正常に完了したら、CCR 環境外にあるすべてのパブリック フォルダ データベースを削除し、Exchange 組織内では他のパブリック フォルダ データベースをホストしないでください。
  • パブリック フォルダ データを CCR 環境以外に移行している場合、パブリック フォルダ レプリケーションを使用して、CCR 環境内のクラスタ化メールボックス サーバーから SCC 内のスタンドアロン メールボックス サーバーまたはクラスタ化メールボックス サーバーにパブリック フォルダ データベースのコンテンツを移動できます。CCR 環境外での他のパブリック フォルダ データベースの作成後、パブリック フォルダ データが他のパブリック フォルダ データベースに完全にレプリケートされるまでの間だけ、CCR 環境内のパブリック フォルダ データベースが存在する必要があります。レプリケーションが正常に完了したら、すべての CCR 環境内のすべてのパブリック フォルダ データベースを削除し、それ以降のパブリック フォルダ データベースは、連続レプリケーションが有効なストレージ グループではホストしないでください。

Exchange 組織内に複数のパブリック フォルダ データベースが存在し、1 つ以上のパブリック フォルダ データベースが CCR 環境でホストされている場合 (前述した移行シナリオなど)、スケジュールされた停止 (ロスレス) とスケジュールされていない停止 (損失を伴う) の動作の違いを考慮する必要があります。

  • スケジュールされた正常な停止 (ロスレス) の場合は、パブリック フォルダ データベースはオンラインになり、パブリック フォルダ レプリケーションは意図したとおりに継続します。
  • スケジュールされていない停止が発生した場合は、元のサーバーが利用できるようになり、パブリック フォルダ データベースをホストしているストレージ グループに対するすべてのログが利用できるようになるまで、パブリック フォルダ データベースはオンラインになりません。停止の結果としてデータが失われた場合は、パブリック フォルダ レプリケーションが有効になっても、CCR はパブリック フォルダ データベースのオンライン化を許可しません。この場合、データ損失を防ぐために元のノードをオンラインにするか、パブリック フォルダ データベースを CCR 環境内のクラスタ化メールボックス サーバーで再作成し、CCR 環境外のパブリック フォルダ データベースからパブリック フォルダ レプリケーションを使用してそのコンテンツを回復する必要があります。

バックアップおよび復元とクラスタ連続レプリケーション

Exchange 対応のバックアップは、VSS 技術を使用して、運用とコピーの両方のストレージ グループおよびデータベースでサポートされます。ストリーミング バックアップは、アクティブ ノードからのみサポートされます。

note注 :
Exchange 対応のバックアップ中に行われる一般的なタスクとして、バックアップが正常に完了した後でトランザクション ログ ファイルの切り詰めが実行されます。CCR のレプリケーション機能によって、レプリケートされていないログが削除されないことが保証されます。この動作は、ログを削除するモードでバックアップを実行する場合、レプリケーションがログのコピー操作において大きく遅れると、実際には領域が解放されない可能性があることを意味します。

Exchange 対応のアクティブ コピーへの復元は、ストリーミング ソリューションまたは VSS バックアップ ソリューションを使用して実行できます。Exchange 対応の復元はパッシブ コピーではサポートされません。

note注 :
復元を実行する前に、パッシブ ストレージ グループのコピーから、すべてのストレージ グループとデータベース ファイルを削除する必要があります。

バックアップから CCR 環境内のストレージ グループにデータベースを復元したら、Suspend-StorageGroupCopy を使用してストレージ グループの連続レプリケーションを中断し、Resume-StorageGroupCopy を使用して再開する必要があります。このプロセスは、正しいログ生成情報を持つ Microsoft Exchange Replication Service を更新するために必要になります。連続レプリケーションが中断されず、また再開されない場合、Microsoft Exchange Replication Service は古いログ生成情報を保持し、ログ ファイルのレプリケーションを停止します。

Exchange 2007 SP1 でのオンライン保守によるデータベース チェックサムおよびオンライン保守データベース ページ除去

チェックサムとは、データベースの整合性を確認する処理です。ページ除去とは、ストリーミング バックアップの最後にデータベースを消去する処理です。Exchange 2007 RTM は、データベースのオンライン完全ストリーミング バックアップの実行時に、データベース全体のチェックサムを行います。前に説明したように、連続レプリケーション環境では、ストリーミング バックアップはデータベースのアクティブ コピーに対してのみ行えます。データベースのパッシブ コピーのストリーミング バックアップは作成できません。VSS を使用すると、パッシブ コピーの完全なスナップショットまたは完全な複製を作成することができ、完全なスナップショットおよび複製もチェックサムされます。ただし、連続レプリケーション環境では通常、管理者の介入なしでは、いずれかのデータベース コピー (アクティブ コピーまたはパッシブ コピー) のみをチェックサムでき、ダウン タイムが発生します。この理由は次のとおりです。

  • データベースのアクティブ コピーのストリーミング バックアップを作成し、同じデータベースのパッシブ コピーの VSS バックアップも作成するには負荷がかかります。
  • VSS はデータベースのアクティブ コピーとパッシブ コピーの両方に使用できますが、アクティブ コピーからパッシブ コピーへのバックアップ操作の負荷軽減を求める推奨事項には反します。
  • Exchange Server データベース ユーティリティ (Eseutil) を使用して手動で整合性チェックを実行するには連続レプリケーションを中断する必要があるので、回復が一時的に中断される可能性があります。

前述の問題が発生するのを防いだり、それらの問題に対処するために、すべてのデータベース コピーでページ除去およびデータベース チェックサムを有効にするために、Exchange 2007 SP1 には 2 つの機能が用意されています。オンライン保守によるデータベース チェックサムとオンライン保守による占有領域の解放処理です。これらの機能を使用すると、管理者はデータベースのバックグラウンド ページ除去とバックグラウンド チェックサムの両方を有効にすることができます。これらの機能は、個別に有効にすることも、まとめて有効することもできます。それには、スキャン対象のデータベースが含まれているメールボックス サーバーで手動でレジストリ値を構成してから、Microsoft Exchange Information Store サービスを再開します。レジストリ値は、Microsoft Exchange Information Store レベルで構成されます。したがって、有効にした後は、メールボックス サーバー上のすべてのデータベースは、構成されたバックグラウンド アクティビティを実行します。使用可能なレジストリ エントリについては、後で説明します。

Caution注意 :
レジストリに対して誤った編集を行うと、重大な問題が発生する可能性があり、オペレーティング システムの再インストールが必要になる場合があります。 誤ったレジストリ編集に起因する問題は、解決できない場合もあります。 レジストリを編集する前に、重要なデータをバックアップしてください。

オンライン保守によるデータベース チェックサムの有効化

場所 :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名前 :Online Maintenance Checksum

種類 :REG_DWORD

値 :0x00000001

オンライン保守による占有領域の解放処理の有効化

場所 :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名前 :Zero Database Pages During Checksum

種類 :REG_DWORD

値 :0x00000001

オンライン保守によるデータベース チェックサムの調整

場所 :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名前 :Throttle Checksum

種類 :REG_DWORD

値 :0x00000000 (ミリ秒)

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