シャドウ冗長

 

適用先:Exchange Server 2013

トピックの最終更新日:2015-03-09

Microsoft Exchange Server 2010 において、メッセージをメールボックスに配信する前にメッセージの冗長コピーを提供するため、シャドウの冗長性が導入されました。Exchange 2010 では、メッセージ配信パスの次のホップで配信が完了したことをサーバーが確認するまで、シャドウの冗長性がトランスポート サーバー上のトランスポート データベースからのメッセージの削除を遅延させました。次のホップで、トランスポート サーバーに正常配信を報告する前に失敗した場合、トランスポート サーバーはその次のホップにメッセージを再送信していました。Exchange 2010 サーバーは XSHADOW コマンドを使用して、サーバーのシャドウの冗長性サポートを通知していました。SMTP サーバーがシャドウの冗長性をサポートしていない場合、Exchange 2010 は受信コネクタで構成された時間間隔を基に遅延した肯定応答を使用して、メッセージの冗長コピーを作成していました。

Microsoft Exchange Server 2013 でのシャドウの冗長性の大きな改良点は、トランスポート サーバーが送信元サーバーにメッセージを正常に受信した旨の肯定応答を行う前に、受信するすべてのメッセージの冗長コピーを作成することです。送信元サーバーがシャドウの冗長性をサポートするかどうかは問題ではありません。これにより、Exchange 2013 トランスポート パイプライン内のメッセージすべてを送信中に冗長化できます。Exchange 2013 が、元のメッセージが送信中に失われたと判断すると、メッセージの冗長コピーが再配信されます。

目次

シャドウ冗長のコンポーネント

シャドウの冗長性のための要件

シャドウの冗長性は既定で有効です

シャドウ メッセージの作成方法

SMTP のタイムアウト

シャドウ メッセージの保持方法

停止後のメッセージの処理

次の表で、シャドウの冗長性のコンポーネントを説明します。以下の用語は、このトピック全体で使用されます。

 

用語 説明

トランスポート サーバー

メッセージ キューがあり、メッセージのルーティングを行う Exchange サーバー。Exchange 2013 では、トランスポート サーバーはメールボックス サーバーです (メールボックス サーバー上のトランスポート サービス)。

トランスポート データベース

Exchange 2013 トランスポート サーバー上のメッセージ キュー データベース。シャドウ キューおよびセーフティ ネットはトランスポート データベースにも格納されます。

トランスポート高可用性境界

データベース可用性グループ (DAG) 環境内の DAG、または非 DAG 環境内の Active Directory サイト。トランスポート高可用性境界内のトランスポート サーバーにメッセージが到着すると、Exchange は境界内のトランスポート サーバーで、メッセージの冗長コピー 2 部の保持を試みます。メッセージがトランスポート高可用性境界から送信されると、Exchange はメッセージの冗長コピーの保持を停止します。

プライマリ メッセージ

配信用のトランスポート パイプラインに送信されるメッセージ。

シャドウ メッセージ

プライマリ メッセージがプライマリ サーバーによって正常に処理されたことをシャドウ サーバーが確認するまで、シャドウ サーバーが保持するメッセージの情報コピー。

プライマリ サーバー

プライマリ メッセージを処理しているトランスポート サーバー。

シャドウ サーバー

プライマリ サーバーのシャドウ メッセージを保持するトランスポート サーバー。トランスポート サーバーは、あるメッセージではプライマリ サーバーに、およびその他のメッセージではシャドウ サーバーに同時になることがあります。

シャドウ キュー

シャドウ サーバーがシャドウ メッセージを格納する配信キュー。複数受信者が設定されたメッセージの場合、プライマリ メッセージのそれぞれの次のホップはそれぞれのシャドウ キューを必要とします。

破棄状態

トランスポート サーバーがシャドウ メッセージ用に保持する情報。プライマリ メッセージが正常に処理されたことを示します。

破棄通知

シャドウ サーバーがプライマリ サーバーから受信する応答。シャドウ メッセージが破棄可能な状態であることを示します。

セーフティ ネット

トランスポート収集の Exchange 2013 改良版。メールボックス サーバー上のトランスポート サービスにより正常に処理されたか、メールボックス受信者に正常に配信されたメッセージは、セーフティ ネットに移動します。詳細については、「セーフティ ネット」を参照してください。

シャドウ冗長マネージャー

シャドウ冗長を管理するトランスポート コンポーネント。

ハートビート

プライマリ サーバーとシャドウ サーバーが、互いの稼働状況を確認するためのプロセス。

ページのトップへ

自明ですが、シャドウの冗長性は複数の Exchange 2013 メールボックス サーバーを必要とします。メールボックス サーバーは、スタンドアロン サーバーにすることも、同一コンピューター上にインストールされたメールボックス サーバーとクライアント アクセス サーバーにすることもできます。

  • メールボックス サーバーが DAG のメンバーではない場合、その他のメールボックス サーバーがローカル Active Directory サイト内に存在する必要があります。

  • メールボックス サーバーが DAG のメンバーである場合、その他のメールボックス サーバーは同じ DAG に属す必要があります。DAG に属すその他のメールボックスは、ローカル Active Directory サイト、またはリモートの Active Directory サイトのいずれに存在してもかまいません。DAG が複数の Active Directory サイトにまたがる場合、シャドウの冗長性はサイトの回復性のため、リモート Active Directory サイトにメッセージの冗長コピーを作成しようとします。

シャドウの冗長性が送信中のメッセージを保護できない状況を以下に挙げます:

  • 単一 Exchange サーバー環境内。

  • プロビジョニング不足の DAG 内。

  • メッセージのシャドウ冗長性に係わる 1 つまたは複数のトランスポート サーバーで同時に障害が発生しているとき。

ページのトップへ

既定で、Set-TransportConfig コマンドレットの ShadowRedundancyEnabled パラメーターを使用することで、すべてのメールボックス サーバーのトランスポート サービスでグローバルにシャドウの冗長性が有効になります。既定で、メールボックス サーバー上のトランスポート サービスがメッセージの冗長コピーを作成できない場合、メッセージは拒否されません。ただし、Set-TransportConfig コマンドレットの RejectMessageOnShadowFailure パラメーターを使用することで、メッセージの冗長コピーが作成されない場合、メッセージを拒否するように Exchange 2013 を構成できます。メッセージは一時的な障害で拒否されますが、送信サーバーはメッセージを再送信できます。SMTP 応答コードは 451 4.4.0 Message failed to be made redundant. です。組織に複数の Exchange 2013 メールボックス サーバーが存在する場合のみ、冗長化不可能なメッセージを拒否するように Exchange 2013 を構成するべきです。

次の表で、シャドウの冗長性を有効にするパラメーターを説明します。

シャドウの冗長性を有効にするパラメーター

パラメーター 既定値 説明

Set-TransportConfigShadowRedundancyEnabled

$true

  • $true により、組織内のすべてのトランスポート サーバー上でシャドウの冗長性が有効になります。

  • $false により、組織内のすべてのトランスポート サーバー上でシャドウの冗長性が無効になります。

Set-TransportConfigRejectMessageOnShadowFailure

$false

  • $false   メッセージのシャドウ コピーを作成できない場合でも、組織内のトランスポート サーバーはプライマリ メッセージを受け入れます。このようなメッセージは、送信中に冗長化で保持されません。

  • $true   メッセージのシャドウ コピーが正常に作成されない限り、組織内のトランスポート サーバーはメッセージを受け入れず、肯定応答も行いません。メッセージのシャドウ コピーを作成できない場合、プライマリ サーバーは一時的エラーにより却下されます。組織内のすべてのメッセージは、送信中に冗長化で保持されます。

    メッセージのシャドウ コピーが作成可能な DAG または Active Directory サイト内に、複数の Exchange 2013 メールボックス サーバーが存在する場合のみ、この値を $true に設定するべきです。

このパラメーターは、ShadowRedundancyEnabled$true に設定されている場合のみ有効です。

ページのトップへ

シャドウの冗長性の主要な目標は、メッセージが送信中であるときに、トランスポート高可用性境界内で、常にメッセージのコピーを 2 部保持することにあります。メッセージの冗長コピーが作成される場所とタイミングは、メッセージの送信元と送信先によって異なります。3 つの主要な決定要因があります:

  • トランスポート高可用性境界の外部から受信したメッセージ。

  • トランスポート高可用性境界の外部に送信されるメッセージ。

  • トランスポート高可用性境界の内部にあるメールボックス サーバーの、メールボックス トランスポート発信サービスから受信したメッセージ。

トランスポート高可用性境界とは、以下のいずれかの項目を指します:

  • DAG (DAG のメンバーであるメールボックス サーバーの場合)。これには、複数の Active Directory サイトにまたがる DAG が含まれます。

  • Active Directory サイト (DAG に属さないメールボックス サーバーの場合)。

シャドウの冗長性は、トランスポート高可用性境界を越えてシャドウ メッセージを追跡することはありません。メッセージがトランスポート高可用性境界を越えると、シャドウの冗長性は開始、または再開します。これにより、シャドウ メッセージの保守トラフィックを減らし、シャドウ メッセージがトランスポート高可用性境界を越えて再送信されることを防ぎます。Exchange 2010 ハブ トランスポート サーバーは特別な場合で、本稿で後述します。

Exchange 2013 メールボックス サーバー上のトランスポート サービスがトランスポート高可用性境界の外部からメッセージを受信する場合、メールボックス サーバーは、送信元サーバーがシャドウの冗長性をサポートするかどうかを問題としません。シャドウの冗長性が有効である限り、メッセージを受信するメールボックス サーバーは、メッセージを受信した旨の肯定応答を送信元サーバーに送信する前に、トランスポート高可用性境界内の別のメールボックス サーバー上にメッセージの冗長コピーを作成します。処理の仕組みの一例:

シャドウ メッセージの作成
  1. SMTP サーバーは、メールボックス サーバー上のトランスポート サービスにメッセージを送信します。メールボックス サーバーはプライマリ サーバーで、メッセージはプライマリ メッセージです。

  2. SMTP サーバーとの元の SMTP セッションがアクティブであれば、プライマリ サーバー上のトランスポート サービスは、組織内の異なるメールボックス サーバー上のトランスポート サービスとの新しい SMTP セッションを同時に開き、メッセージの冗長コピーを作成します。

    • プライマリ サーバーが DAG のメンバーである場合、プライマリ サーバーは同じ DAG の異なるメールボックス サーバーに接続します。DAG が複数の Active Directory サイトにまたがる場合、異なる Active Directory サイト内のメールボックス サーバーが既定で優先されます。この動作は、Set-TransportService コマンドレットの ShadowMessagePreference パラメーターで制御されます。既定値は PreferRemote ですが、RemoteOnly または LocalOnly に変更できます。

    • プライマリ サーバーが DAG のメンバーではない場合、ShadowMessagePreference パラメーターの値にかかわらず、プライマリ サーバーは同じ Active Directory サイト内の異なるメールボックス サーバーに接続します。

  3. プライマリ サーバーはその他のメールボックス サーバー上のトランスポート サービスにメッセージのコピーを送信し、そのメールボックス サーバー上のトランスポート サービスは、メッセージのコピーが正常に作成された旨の肯定応答を行います。メッセージのコピーはシャドウ メッセージであり、そのメッセージを保持するメールボックス サーバーは、プライマリ サーバーのシャドウ サーバーになります。メッセージは、シャドウ サーバー上のシャドウ キューに存在します。

  4. プライマリ サーバーがシャドウ サーバーから肯定応答を受信すると、元の SMTP セッションの元の SMTP サーバーに対し、プライマリ メッセージを受信した旨の肯定応答を行い、その SMTP セッションは閉じられます。

Exchange 2013 トランスポート サーバーがトランスポート高可用性境界の外部にメッセージを送信すると、受信側となる SMTP サーバーは、メッセージを正常に受信した旨の肯定応答を行います。トランスポート サーバーはメッセージをセーフティ ネットに移動します。プライマリ メッセージがトランスポート高可用性境界を越えて正常に送信されると、セーフティ ネットからメッセージを再送信できなくなります。セーフティ ネットの詳細については、「セーフティ ネット」を参照してください。

Exchange 2013 内ではメッセージ ルーティングが最適化されるため、最終的な送信先が DAG 内部または Active Directory サイトである場合、その DAG または Active Directory サイト内のメールボックス サーバー上のトランスポート サービス間の複数ホップは、通常必要ありません。メッセージの最終的な送信先を含む DAG または Active Directory サイト内のメールボックス サーバー上のトランスポート サーバーがメッセージを受け入れると、メッセージの次のホップは通常最終的な送信先になります。送信中のメッセージのコピーを 2 部保持するというシャドウの冗長性の目標は、DAG または Active Directory サイト内にメッセージのシャドウ コピーが 1 部存在するだけで満たされます。通常、メールボックス サーバー上のアクティブ キューをドレインするのに Redirect-Message コマンドレットを必要とする DAG 内のフェールオーバー シナリオでのみ、同一トランスポート高可用性境界内に複数のホップが必要になります。

Exchange 2010 ハブ トランスポート サーバーが同じ Active Directory サイト内の Exchange 2013 メールボックス サーバーにメッセージを送信するとき、Exchange 2010 ハブ トランスポート サーバーは、XSHADOW コマンドを使用してシャドウの冗長性のサポートを通知しますが、メールボックス サーバーはシャドウの冗長性のサポートを通知しません。これで、Exchange 2010 ハブ トランスポート サーバーが Exchange 2013 メールボックス サーバー上にメッセージのシャドウ コピーを作成するのを防ぎます。

Exchange 2013 メールボックス サーバー上のトランスポート サービスが、同じ Active Directory サイト内の Exchange 2010 ハブ トランスポートにメッセージを送信するとき、Exchange 2013 メールボックス サーバーは Exchange 2010 ハブ トランスポート サーバー向けのメッセージをシャドウ コピーします。Exchange 2013 メールボックス サーバーが Exchange 2010 ハブ トランスポート サーバーからメッセージを正常に受信した旨の肯定応答を受信すると、Exchange 2013 メールボックス サーバーはセーフティ ネットに正常に処理されたメッセージを移動します。ただし、Exchange 2013 メールボックスによりセーフティ ネットに格納された正常に処理されたメッセージは、Exchange 2010 ハブ トランスポート サーバーに再送信されることはありません。

ページのトップへ

メッセージの冗長コピーの作成を試行している間、送信 SMTP サーバーとプライマリ サーバー間の SMTP 接続、またはプライマリ サーバーとシャドウ サーバー間の SMTP セッションはタイムアウトすることがあります。受信コネクタと送信コネクタの両方に、データがコネクタで実際に送信されるまでの時間のための ConnectionInactivityTimeOut パラメーターがあります。受信コネクタには、絶対 ConnectionTimeOut パラメーターもあります。

メッセージのシャドウ コピーが正常に作成され肯定応答が行われる前に、いずれかの SMTP セッションがタイムアウトした場合の結果は、Set-TransportConfig コマンドレットの RejectMessageOnShadowFailure パラメーターで制御されます。既定で、このパラメーターの値は $false です。これは、シャドウ コピーが作成されずにプライマリ メッセージが受け入れられることを意味します。このパラメーターの値が $true であると、プライマリ メッセージは却下され、一時的なエラー 451 4.4.0 が表示されます。

メッセージのシャドウ コピーが正常に作成された場合に、送信 SMTP サーバーとプライマリ サーバー間の SMTP セッションがタイムアウトすると、プライマリ サーバーはプライマリ メッセージを受け入れ、処理します。送信 SMTP サーバーは肯定応答されていないメッセージを再配信しますが、重複メッセージ検出機能により、Exchange メールボックス ユーザーが重複メッセージを受け取ることはありません。送信 SMTP サーバーがメッセージを再送信すると、プライマリ サーバーはメッセージのシャドウ コピーをもう 1 部作成します。送信 SMTP サーバーによるメッセージの再送信中に作成されたシャドウ メッセージ間に関係はありません。

次の表で、シャドウ メッセージの作成を制御するパラメーターを説明します

シャドウ メッセージ作成パラメーター

ソース 既定値 説明

Set-TransportConfigShadowMessagePreferenceSetting

PreferRemote

  • PreferRemote   メッセージのシャドウ コピーを別の Active Directory サイト内のメールボックス サーバーに作成してください。操作に失敗した場合、メッセージのシャドウ コピーをローカル Active Directory サイトのサーバー上に作成してください。

  • LocalOnly   メッセージのシャドウ コピーは、ローカル Active Directory サイトのトランスポート サーバー上にのみ作成する必要があります。

  • RemoteOnly: メッセージのシャドウ コピーは、異なる Active Directory サイトのトランスポート サーバー上にのみ作成する必要があります。

このパラメーターは、メッセージのシャドウ コピーを作成しようとしているプライマリ サーバーが、複数の Active Directory サイトにまたがる DAG のメンバーであるメールボックス サーバーである場合にのみ、有効です。

Set-TransportConfigMaxRetriesForRemoteSiteShadow

4

このパラメーターは、メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合にのみ、有効です。

  • ShadowMessagePreferenceSettingPreferRemote に設定すると、最初にメールボックス サーバーは、MaxRetriesForRemoteSiteShadow によって指定されている回数まで、リモート Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。メールボックス サーバーは、これに失敗すると、MaxRetriesForLocalSiteShadow によって指定されている回数まで、ローカル Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。

  • ShadowMessagePreferenceSettingRemoteOnly に設定すると、メールボックス サーバーは、MaxRetriesForRemoteSiteShadow によって指定されている回数まで、リモート Active Directory サイトのメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。

メッセージのシャドウ コピーが正常に作成できない場合:

  • RejectMessageOnShadowFailure$true である場合、プライマリ メッセージは一時的なエラーで拒否されます。

  • RejectMessageOnShadowFailure$false である場合、プライマリ メッセージは受け入れられますが、重複して永続化されません。

Set-TransportConfigMaxRetriesForLocalSiteShadow

2

このパラメーターは、以下の状況で使用します:

  • メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合。

    1. ShadowMessagePreferenceSettingPreferRemote に設定すると、最初にメールボックス サーバーは、MaxRetriesForRemoteSiteShadow によって指定されている回数まで、リモート Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。メールボックス サーバーは、これに失敗すると、MaxRetriesForLocalSiteShadow によって指定されている回数まで、ローカル Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。

    2. ShadowMessagePreferenceSettingLocalOnly に設定すると、メールボックス サーバーは、MaxRetriesForLocalSiteShadow によって指定されている回数まで、ローカル Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。

  • メールボックス サーバーが DAG のメンバーではない場合、またはメールボックス サーバーがある Active Directory サイトに含まれる DAG のメンバーである場合、メールボックス サーバーは、MaxRetriesForLocalSiteShadow によって指定されている回数まで、ローカル Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。

メッセージのシャドウ コピーが正常に作成できない場合:

  • RejectMessageOnShadowFailure$true である場合、プライマリ メッセージは一時的なエラーで拒否されます。

  • RejectMessageOnShadowFailure$false である場合、プライマリ メッセージは受け入れられますが、重複して永続化されません。

Set-ReceiveConnectorConnectionInactivityTimeout

メールボックス サーバー上のトランスポート サービスで 5 分

クライアント アクセス サーバー上のフロント エンド トランスポート サービスで 5 分。

エッジ トランスポート サーバーで 1 分。

このパラメーターには、送信元のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。このパラメーターの値は、ConnectionTimeout パラメーターによって指定される値未満にする必要があります。

Set-ReceiveConnectorConnectionTimeout

メールボックス サーバー上のトランスポート サービスで 10 分

クライアント アクセス サーバー上のフロント エンド トランスポート サービスで 10 分。

エッジ トランスポート サーバーで 5 分。

このパラメーターには、送信元のメッセージング サーバーとの SMTP 接続を開いておくことができる時間の上限を指定します。この制限は、送信元のメッセージング サーバーがデータを転送していても適用されます。このパラメーターの値は、ConnectionInactivityTimeout パラメーターによって指定される値より大きくする必要があります。

Set-SendConnectorConnectionInactivityTimeOut

10 分

このパラメーターには、送信先のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。

ページのトップへ

メッセージが正常に作成されてからも、シャドウの冗長性の作業は続きます。プライマリ サーバーとシャドウ サーバーは、メッセージの進行状況を追跡するため、互いに通信し続ける必要があります。

プライマリ サーバーがメッセージを次のホップに正常に送信し、次のホップがメッセージ受信の肯定応答を行うと、プライマリ サーバーは配信完了としてメッセージの破棄状態を更新します。破棄状態とは基本的に、監視対象メッセージの一覧を含むメッセージのことです。正常に配信されたメッセージはシャドウ キューに保持する必要はなくなるため、プライマリ サーバーがメッセージを次のホップにまで正常に送信したことをシャドウ サーバーが認識すると、シャドウ サーバーはシャドウ キューからセーフティ ネットに、シャドウ メッセージを移動します。

シャドウ サーバーは、プライマリ サーバーを照会して、シャドウ キュー内のシャドウ メッセージの破棄状態を決定します。シャドウ サーバーがなんらかの理由でプライマリ サーバーとの SMTP セッション (その他の無関係メッセージの送信を含む) を開くと、シャドウ サーバーは XQDISCARD コマンドを発行して、プライマリ メッセージの破棄状態を判断します。シャドウ サーバーが、事前構成された時間間隔を経過してもプライマリ サーバーとの SMTP セッションを開いていない場合、シャドウ サーバーはプライマリ サーバーとの SMTP セッションを開いて、XQDISCARD コマンドを発行します。間隔は、Set-TransportConfig コマンドレットの ShadowHeartbeatFrequentcy パラメーターによって制御されます。この既定値は 2 分です。シャドウ サーバーがプライマリ サーバーとの SMTP セッションを開くと、プライマリ サーバーは照会を行ったシャドウ サーバーに適用されるメッセージの破棄状態を応答します。Exchange 2013 では、破棄通知はメモリではなくディスクに格納されます。このため、Microsoft Exchange トランスポート サービスを再開しても、破棄通知は保持されます。サービスが起動すると、プライマリ サーバーは正常に処理したメッセージを把握しているため、その情報はシャドウ サーバーにも通知されます。

シャドウ サーバーとプライマリ サーバー間の SMTP 通信は、ハートビートとして使用されます。これにより、サーバーの稼働状況を判断します。シャドウ サーバーが、事前構成された時間間隔を経過してもプライマリ サーバーとの SMTP セッションを開けない場合、またはプライマリ サーバーのトランスポート データベースに異なるデータベース ID が設定されている場合、シャドウ サーバーは自身をプライマリ サーバーに昇格し、シャドウ メッセージをプライマリ メッセージに昇格し、次のホップにメッセージを送信します。間隔は、Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーターによって制御されます。既定値は 3 時間です。

シャドウ冗長マネージャーは、シャドウ冗長を管理する Exchange 2013 トランスポート サーバーのコア コンポーネントです。シャドウ冗長マネージャーによって、サーバーが現在処理中であるすべてのプライマリ メッセージの、以下の情報が保持されます。

  • 各プライマリ メッセージを処理中のシャドウ サーバー。

  • シャドウ サーバーに送信される破棄状態。

シャドウの冗長性マネージャーは、シャドウ サーバーがシャドウ キューに保持するすべてのシャドウ メッセージに対し、以下の操作を実行します:

  • シャドウ メッセージごとのプライマリ サーバーの一覧の維持。

  • 元のデータベース ID と、メッセージのプライマリ コピーが格納されているキュー データベースの現在の ID の比較。

  • キューにシャドウ メッセージを持っている各プライマリ サーバーの可用性の確認。

  • プライマリ サーバーからの通知の破棄処理。

  • 適切な破棄通知すべてを受信した後に、シャドウ キューからシャドウ メッセージを削除。

  • シャドウ サーバーがシャドウ メッセージの所有権を引き継いでプライマリ サーバーになる時期の決定。

  • メッセージの分岐、および配信状態通知 (DSN) およびジャーナル レポートなどのその他の副次的メッセージの追跡。これにより、メッセージのすべてのフォークが完全に処理されるまで、メッセージの冗長コピーが解放されないことを確認します。

次の表で、シャドウ メッセージの保持方法を制御するパラメーターを説明します。

 

パラメーター 既定値 説明

Set-TransportConfigShadowHeartbeatFrequency

2 分

シャドウ サーバーが、メッセージの破棄状態をチェックするのにプライマリ サーバーへの SMTP 接続を開くまでに待機する最長時間。

Set-TransportConfigShadowResubmitTimeSpan

3 時間

サーバーがプライマリ サーバーで障害が発生したと判断するまでの待ち時間。この時間が経過すると、サーバーは、シャドウ キューにある、到達不可能なプライマリ サーバーのためのシャドウ メッセージの所有権を引き継ぎます。

Set-TransportConfigShadowMessageAutoDiscardInterval

2 日

サーバーが、正常に配信されたメッセージの破棄イベントを保持する期間。プライマリ サーバーは、シャドウ サーバーがクエリを実行するまで破棄イベントをキューに保持します。ただし、パラメーターで指定した期間内にプライマリ サーバーに対してシャドウ サーバーがクエリを実行しない場合は、プライマリ サーバーは、キューにある破棄イベントを削除します。

Set-TransportConfigSafetyNetHoldTime

2 日

正常に処理されたメッセージがセーフティ ネットで保持される期間。肯定応答されていないシャドウ メッセージは、Set-TransportServiceSafetyNetHoldTimeMessageExpirationTimeout の合計時間が経過すると、セーフティ ネットから事実上失効します。

Set-TransportServiceMessageExpirationTimeout

2 日

期限前にメッセージがキューに残る時間。

ページのトップへ

シャドウの冗長サーバーの停止によるメッセージの損失を最小限に抑えることができます。トランスポート サーバーが停止後に再度オンラインになる場合として、次の 2 つのシナリオがあります。

  • サーバーが新しいトランスポート データベースで再度オンラインになる   このシナリオでは、トランスポート データベースはデータの破損またはハードウェアのエラーが原因で回復不能となっています。この場合、トランスポート データベースは新しいデータベース ID を持つため、組織内の他のトランスポート サーバーはこれを新しいルートと認識します。これは、サーバーが回復できず、新しいサーバーが代わりにプロビジョニングされた場合にも適用されます。

  • サーバーが同じトランスポート データベースで再度オンラインになる   このシナリオでは、特定のトランスポート サーバーで障害は発生していないものの、長時間オフラインであったため、シャドウ サーバーがメッセージの所有権を引き継ぎ、メッセージを再送信します。たとえばネットワーク カードのエラーや、長時間のサーバー保守などが、このシナリオの原因となります。

次の表に、シャドウの冗長性がこれらの 2 つのシナリオにどのように対応するのかをまとめます。分かりやすくするため、停止したサーバーの名前を Mailbox01 とします。

メッセージの回復のシナリオでの処理

回復のシナリオ 実行された処理

Mailbox01 で新しいデータベースがオンラインに復帰する。

Mailbox01 が使用不可となると、Mailbox01 のシャドウ メッセージをキューに持つ各サーバーは、それらのメッセージの所有権を引き継ぎ、メッセージを再送信します。メッセージは送信先に配信されます。

メッセージの最大遅延は、Set-TransportConfig コマンドレットの ShadowHeartbeatFrequency パラメーターの値になります。この既定値は 2 分です。

Mailbox01 で同じデータベースがオンラインに復帰する。

Mailbox01 がオンラインに復帰すると、Mailbox01 はキューにあるメッセージを配信します。しかし、このメッセージは Mailbox01 のメッセージのシャドウ コピーを保持するサーバーにより既に配信済みです。結果として、これらのメッセージは重複配信されることになります。重複メッセージ検出機能により、Exchange メールボックス ユーザーが重複メッセージを受け取ることはありません。ただし、Exchange 以外のメッセージング システム上の受信者は、メッセージの重複コピーを受け取ることがあります。

メッセージの最大遅延は、Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーターの値になります。既定値は 3 時間です。

ページのトップへ

 
表示: