スタンバイ連続レプリケーションの計画

  • [アーティクル]

 

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

トピックの最終更新日: 2008-09-11

スタンバイ連続レプリケーション (SCR) の展開は、ローカル連続レプリケーション (LCR) の展開と似ていますが、いくつかの重要な違いについて考慮する必要があります。SCR には一般的な要件があります。

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

SCR のストレージ グループを有効にする前に、SCR のソースとターゲットに対する次の要件を理解しておくことをお勧めします。

  • 1 つのソースが複数のターゲットを持つことができます。たとえば、ソースと同じデータセンター内にターゲットの 1 つがあり、別のターゲットが別のデータセンター内に存在する場合です。ソースごとのターゲット数の制限はありません。ただし、1 つのソースあたりのターゲットは 4 個以下にすることをお勧めします。5 個以上のターゲットを構成する場合は、ソース サーバーに対する追加の影響を検証し、その結果を考慮して計画を立てる必要があります。
  • 1 つのターゲットが複数のソース サーバーを持つことができます。ソース システムとターゲット システムの両方が Exchange 2007 SP1 を実行している必要があります。オペレーティング システムは、Exchange 2007 SP1 でサポートされるオペレーティング システムであれば、どれでもかまいません (Windows Server 2008 や Windows Server 2003 など)。ただし、SCR ターゲットのすべてのコンピュータが、SCR ソースのコンピュータと同じオペレーティング システムを実行している必要があります。SCR ソースと SCR ターゲットで異なるオペレーティング システムを使用することはできません (SCR ソースが Windows Server 2003 で、SCR ターゲットが Windows Server 2008 である場合、またはその逆の場合など)。
  • SCR ターゲット コンピュータには、Exchange 2007 SP1 のメールボックス サーバーの役割がインストールされている必要があります。SCR ターゲット コンピュータがクラスタ ノードである場合、そのノードはパッシブ ノードである必要があり (たとえば、パッシブ クラスタ化メールボックスの役割がインストールされている)、クラスタにクラスタ化メールボックス サーバーを含めることはできません。
  • SCR ターゲット アクティブ化プロセスの一部としてスタンバイ クラスタおよびクラスタ化メールボックス サーバーの回復機能 (Setup /RecoverCMS) を使用する場合は、Exchange Server のインストール パスの計画にいっそうの注意を払う必要があります。サーバー回復プロセスを使用するには、Exchange Server のインストール パスが、SCR ソース コンピュータと SCR ターゲット コンピュータとで同一であることが必要です。SCR ソース コンピュータで Exchange Server が %ProgramFiles%\Microsoft\Exchange Server にインストールされている場合は、この SCR ソース サーバーの SCR ターゲットとなるすべてのコンピュータでも %ProgramFiles%\Microsoft\Exchange Server にインストールされている必要があります。これらのインストール パスが一致しない場合は、レジストリ内のインストール パスと Active Directory ディレクトリ サービスのメールボックス サーバー オブジェクトの msExchInstallPath 属性の値が一致しなくなるため、Setup /RecoverCMS の実行に失敗します。
  • アクティブ化プロセスにクラスタ化メールボックス サーバーの回復が含まれる場合は、アクティブ化プロセスの一部として Setup /RecoverCMS を使用する前に、クラスタ化メールボックス サーバー上のすべてのストレージ グループに対して SCR を無効にする必要があります。SCR がすべてのストレージ グループに対して無効になっていない場合、Setup /RecoverCMS は失敗します。
  • SCR ソースとすべてのターゲット上のストレージ グループおよびデータベース パスが、他のストレージ グループやデータベース パスと競合しないようにする必要があります。SCR ソースが使用するストレージ グループおよびデータベースのパスは、そのソースのすべての SCR ターゲットでストレージ グループおよびデータベースのコピーに使用されるため、SCR を使用する場合は、ストレージ グループおよびデータベースのパスを慎重に検討する必要があります。
  • SCR ソースと SCR ターゲットのコンピュータが存在する Active Directory ドメインは同一でなければなりませんが、Active Directory サイトは同一でも異なっていてもかまいません。
  • 各ターゲット コンピュータがサポートするターゲットの最大数は、Exchange 2007 の Enterprise Edition を使用する場合は 50 SCR ターゲット (ストレージ グループ 50 個をレプリケート)、Exchange 2007 の Standard Edition を使用する場合は 5 SCR ターゲットです。

SCR ターゲット コンピュータに関する制約

パッシブ ノードまたはスタンドアロン メールボックス サーバーを SCR ターゲットとして構成すると、以下の機能がブロックされます。

  • SCR ターゲットとして指定されたスタンドアロン メールボックス サーバーで、ストレージ グループに対して LCR を有効にすることはできません。Microsoft Exchange Replication Service は、LCR と別のソースからのレプリケーションの両方を管理するようには作られていません。
  • SCR ターゲットとして指定されたパッシブ ノードがメンバとなっているフェールオーバー クラスタに、クラスタ化メールボックス サーバーが含まれていてはなりません。これは、スタンバイ クラスタと呼ばれます。スタンバイ クラスタの詳細については、「高可用性」を参照してください。

SCR およびパブリック フォルダ データベース

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

note注 :
データベースの移植性はメールボックス データベースにのみ使用できるので、パブリック フォルダ データベースの SCR ターゲット コピーのアクティブ化は、サーバーまたはクラスタ化メールボックス サーバーの回復操作 (Setup /m:recoverServer または Setup /recoverCMS など) の一環としてのみ実行できます。

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

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

Exchange 組織内に複数のパブリック フォルダ データベースが存在し、SCR が有効なストレージ グループ内で 1 つ以上のパブリック フォルダ データベースがホストされている間に、SCR ソース ストレージ グループで障害が発生し、SCR ターゲット パブリック フォルダ データベースをアクティブにする必要がある場合、パブリック フォルダ データベースをホストしているストレージ グループのすべてのログを使用可能な場合にのみマウント可能にすることができます。SCR ソースの障害により、欠落しているログまたは使用できないログがある場合、パブリック フォルダ データベースの SCR ターゲット コピーをアクティブにすることはできません。この場合、データ損失を防ぐために SCR ソースをオンラインにするか、パブリック フォルダ データベースを SCR ソースで再作成し、SCR ターゲット コピー以外のパブリック フォルダ データベースからパブリック フォルダ レプリケーションを使用してそのコンテンツを回復する必要があります。

SCR とバックアップ

SCR のターゲット コピーをバックアップすることはできません。LCR および CCR では、アクティブ コピーとパッシブ コピーのどちらからもバックアップを作成できます。SCR では、SCR ソースのバックアップのみがサポートされます。サポートされるバックアップを SCR ソース ストレージ グループに対して作成すると、SCR ターゲットのデータベース ヘッダーが更新され、ログ ファイルが切り詰められます。SCR ソース ストレージ グループに対して CCR または LCR が有効になっている場合は、SCR ソース ストレージ グループのアクティブ コピーまたはパッシブ コピーのバックアップが作成されると、SCR ターゲットのデータベース ヘッダーが更新され、ログ ファイルが切り詰められます。

SCR と復元

SCR ソース データベースが以前のバージョンのデータベースで置き換えられる場合は、Suspend-StorageGroupCopy と Resume-StorageGroupCopy をそれぞれ使用して、ストレージ グループの連続レプリケーションを中断してから再開する必要があります。このプロセスは、正しいログ生成情報を持つ Microsoft Exchange Replication Service を更新するために必要になります。連続レプリケーションが中断されず、また再開されない場合、Replication Service は古いログ生成情報を保持し、ログ ファイルのレプリケーションを停止します。

SCR とログ ファイルの切り詰め

Exchange 2007 RTM では、連続レプリケーション環境においては、ログ ファイルがバックアップされ、再生されてデータベースのコピーに反映されるまではログ ファイルが削除されないという規則が適用されます。SCR を使用するときは、この規則が変更されます。複数データベース コピーの概念が導入された SCR では、すべての SCR ターゲット コンピュータによってログ ファイルが検査されると、SCR ソース側でのログ ファイル切り詰めが可能になります。すべてのログがすべての SCR ターゲットに再生されるのを待たずに SCR ソース側でログが切り詰められるのは、SCR ターゲット コピーのログ再生遅延を長く設定できるからです。ただし、ストレージ グループの 1 つ以上の SCR ターゲットが停止している場合、SCR ソースでのログの切り詰めは行われません。SCR ソースでログが切り詰められるには、SCR ターゲット コンピュータがオンラインで、ソースからアクセスできる必要があります。

SCR ターゲット側では、切り詰めが必要なログ ファイルの有無を調べるバックグラウンド スレッドが 3 分おきに実行されます。次の 3 つの条件が満たされると、ログ ファイルは SCR ターゲット上で切り詰められます。

  • ログ ファイルが SCR ソース上で切り詰められている。
  • ログ ファイル世代シーケンスが、ストレージ グループのログ ファイル チェックポイントよりも下である。
  • ログ ファイルが ReplayLagTime + TruncationLagTime より古い。各パラメータについては、「スタンバイ連続レプリケーション」の「SCR に関するコマンドレットの更新」を参照してください。

LCR 環境または CCR 環境で SCR を利用する場合は、次の 3 つの条件が満たされると、LCR または CCR 環境のアクティブ コピーおよびパッシブ コピーのログ ファイルが切り詰められます。

  • ログ ファイルがバックアップされている。
  • ログ ファイル世代シーケンスが、ストレージ グループのログ ファイル チェックポイントよりも下である。
  • すべての SCR ターゲットによってログ ファイルが検査された。

SCR のための Windows 2003 ネットワークの最適化

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

これらの推奨事項に加えて、IP セキュリティ (IPsec) プロトコルを使用する環境では、SCR 環境全体を通じて IPsec を構成することをお勧めします。SCR ソースとそのすべての SCR ターゲットが IPsec を使用するか、SCR ソースもそのいずれのターゲットも 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 チームのブログの「Exchange 2007 Mailbox Server Role Storage Requirements Calculator」を参照してください (このサイトは英語の場合があります)。記憶域計算用シートには、サーバー上のレジストリ値に入力する手順も含まれています。

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

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

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