次の方法で共有

シャドウ冗長

  • [アーティクル]

製品: Exchange Server 2013

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

Microsoft Exchange Server 2013 のシャドウ冗長性の主な改善点は、トランスポート サーバーが、メッセージを送信サーバーに正常に受信する前に受信したメッセージの冗長コピーを作成するようになった点です。 送信側サーバーのサポートまたはシャドウ冗長性のサポートの欠如は関係ありません。 これにより、Exchange 2013 トランスポート パイプライン内のすべてのメッセージが転送中に冗長になります。 Exchange 2013 で元のメッセージが転送中に失われたと判断された場合、メッセージの冗長コピーは再配信されます。

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

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

用語 説明
トランスポート サーバー メッセージ キューがあり、メッセージのルーティングを担当する 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 内。
  • メッセージのシャドウ冗長性に関係する 2 つ以上のトランスポート サーバーの同時失敗中。

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

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

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

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

パラメーター 既定値 説明
Set-TransportConfig の ShadowRedundancyEnabled $true
  • $true では、組織内のすべてのトランスポート サーバーでシャドウ冗長性が有効になります。
  • $false は、組織内のすべてのトランスポート サーバーのシャドウ冗長性を無効にします。
Set-TransportConfig の RejectMessageOnShadowFailure $false
  • $false: メッセージのシャドウ コピーを作成できない場合、プライマリ メッセージは、組織内のトランスポート サーバーによって受け入れられます。 これらのメッセージは、転送中に冗長に永続化されません。
  • $true: メッセージのシャドウ コピーが正常に作成されるまで、組織内のどのトランスポート サーバーでもメッセージは受け入れも確認もされません。 メッセージのシャドウ コピーを作成できない場合、プライマリ メッセージは一時的なエラーで拒否されます。 組織内のすべてのメッセージは、送信中に冗長化で保持されます。

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

このパラメーターは、 ShadowRedundancyEnabled が の $true場合にのみ意味があります。

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

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

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

トランスポート高可用性境界は、次のいずれかです。

  • DAG のメンバーであるメールボックス サーバーの DAG。 これには、複数の Active Directory サイトにまたがる DAG が含まれます。
  • DAG に属していないメールボックス サーバー用の Active Directory サイト。

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

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

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

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

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

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

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

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

  4. プライマリ サーバーがシャドウ サーバーから受信確認を受け取った後、プライマリ サーバーは、元の SMTP セッション内の元の SMTP サーバーへのプライマリ メッセージの受信を確認し、SMTP セッションが閉じられます。

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

Exchange 2013 トランスポート サーバーがトランスポート高可用性境界の外でメッセージを送信し、もう一方の側の SMTP サーバーがメッセージの受信に成功したことを確認すると、トランスポート サーバーはメッセージを Safety Net に移動します。 プライマリ メッセージがトランスポートの高可用性境界を越えて正常に送信された後、Safety Net からのメッセージの再送信は行われません。 セーフティ ネットの詳細については、「セーフティ ネット」を参照してください。

トランスポート高可用性境界の内部で送信されるメッセージ

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

同じ Active Directory サイト内の Exchange 2010 ハブ トランスポート サーバーによるシャドウ冗長

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 Hub トランスポート サーバーから受信した後、正常に処理されたメッセージを Safety Net に移動します。 ただし、Exchange 2013 メールボックスによってセーフティ ネットに格納されている正常に処理されたメッセージは、Exchange 2010 ハブ トランスポート サーバーに再送信されることはありません。

SMTP のタイムアウト

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

メッセージのシャドウ コピーが正常に作成されて確認される前に SMTP セッションのいずれかがタイムアウトした場合、結果は Set-TransportConfig コマンドレットの RejectMessageOnShadowFailure パラメーターによって制御されます。 既定では、このパラメーターの値は です $false。つまり、シャドウ コピーが作成されずにプライマリ メッセージが受け入れられます。 このパラメーターの値がプライマリ メッセージの $true 場合は、一時的なエラー 451 4.4.0で拒否されます。

メッセージのシャドウ コピーが正常に作成されたが、送信 SMTP サーバーとプライマリ サーバー間の SMTP セッションがタイムアウトした場合、プライマリ サーバーはプライマリ メッセージを受け入れて処理します。 送信 SMTP サーバーは未確認のメッセージを再配信しますが、重複メッセージ検出により、Exchange メールボックス ユーザーに重複メッセージが表示されなくなります。 送信 SMTP サーバーがメッセージを再送信すると、プライマリ サーバーによってメッセージの別のシャドウ コピーが作成されます。 送信 SMTP サーバーによるメッセージの再送信中に作成されたシャドウ メッセージの間に関係はありません。

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

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

ソース 既定値 説明
Set-TransportConfig の ShadowMessagePreferenceSetting PreferRemote
  • PreferRemote: 別の Active Directory サイトのメールボックス サーバーでメッセージのシャドウ コピーを作成してみてください。 操作が失敗した場合は、ローカル Active Directory サイト内のサーバーでメッセージのシャドウ コピーを作成してみてください。
  • LocalOnly: メッセージのシャドウ コピーは、ローカル Active Directory サイト内のトランスポート サーバーでのみ作成する必要があります。
  • RemoteOnly: メッセージのシャドウ コピーは、別の Active Directory サイト内のトランスポート サーバーでのみ作成する必要があります。

このパラメーターは、メッセージのシャドウ コピーを作成しようとしているプライマリ サーバーが、複数の Active Directory サイトにまたがる DAG のメンバーであるメールボックス サーバーである場合にのみ意味があります。
Set-TransportConfig の MaxRetriesForRemoteSiteShadow 4 このパラメーターは、メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合に使用されます。
  • ShadowMessagePreferenceSetting が にPreferRemote設定されている場合、まず、メールボックス サーバーは、MaxRetriesForRemoteSiteShadow で指定された回数まで、リモート Active Directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。 失敗した場合、メールボックス サーバーは、 MaxRetriesForLocalSiteShadow で指定された回数まで、ローカル Active Directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。
  • ShadowMessagePreferenceSetting が にRemoteOnly設定されている場合、メールボックス サーバーは、MaxRetriesForRemoteSiteShadow で指定された回数まで、リモート Active Directory サイト内のメールボックス サーバー上にメッセージのシャドウ コピーの作成のみを試みます。
  • その

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

  • RejectMessageOnShadowFailure が の場合、$trueプライマリ メッセージは一時的なエラーで拒否されます。
  • RejectMessageOnShadowFailure が の場合、$falseプライマリ メッセージは受け入れられますが、冗長に永続化されません。
Set-TransportConfig の MaxRetriesForLocalSiteShadow 2 このパラメーターは、次の状況で使用されます。
  • メールボックス サーバーが、複数の Active Directory サイトにまたがる DAG のメンバーである場合。
    1. ShadowMessagePreferenceSetting が にPreferRemote設定されている場合、まず、メールボックス サーバーは、MaxRetriesForRemoteSiteShadow で指定された回数まで、リモート Active Directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。 失敗した場合、メールボックス サーバーは、 MaxRetriesForLocalSiteShadow で指定された回数まで、ローカル Active Directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。
    2. ShadowMessagePreferenceSetting が にLocalOnly設定されている場合、メールボックス サーバーは、MaxRetriesForLocalSiteShadow で指定された回数まで、ローカル Active Directory サイト内の別のメールボックス サーバー上にメッセージのシャドウ コピーを作成しようとします。
  • メールボックス サーバーが DAG のメンバーではない場合、またはメールボックス サーバーが 1 つの Active Directory サイトにある DAG のメンバーである場合、メールボックス サーバーは、 MaxRetriesForLocalSiteShadow によって指定された回数まで、ローカル Active Directory サイト内の別のメールボックス サーバー上のメッセージのシャドウ コピーの作成のみを試みます。

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

  • RejectMessageOnShadowFailure が の場合、$trueプライマリ メッセージは一時的なエラーで拒否されます。
  • RejectMessageOnShadowFailure が の場合、$falseプライマリ メッセージは受け入れられますが、冗長に永続化されません。
Set-ReceiveConnector の ConnectionInactivityTimeout メールボックス サーバー上のトランスポート サービスで 5 分

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

エッジ トランスポート サーバーで 1 分。		 このパラメーターは、接続が閉じられる前に、ソース メッセージング サーバーとの開いている SMTP 接続がアイドル状態を維持できる最大時間を指定します。 このパラメーターの値は、 ConnectionTimeout パラメーターで指定された値より小さくする必要があります。
Set-ReceiveConnector の ConnectionTimeout メールボックス サーバー上のトランスポート サービスで 10 分

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

エッジ トランスポート サーバーで 5 分。		 このパラメーターは、ソース メッセージング サーバーがデータを送信している場合でも、ソース メッセージング サーバーとの SMTP 接続を開いたままにできる最大時間を指定します。 このパラメーターの値は、 ConnectionInactivityTimeout パラメーターで指定された値より大きくする必要があります。
Set-SendConnector の ConnectionInactivityTimeOut 10 分 このパラメーターには、送信先のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。

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

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

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

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

シャドウ サーバーとプライマリ サーバーの間の SMTP 通信は、サーバーの可用性を決定する ハートビート として使用されます。 事前構成された時間間隔の後にシャドウ サーバーがプライマリ サーバーとの SMTP セッションを開くことができない場合、またはプライマリ サーバーのトランスポート データベースに別のデータベース ID がある場合、シャドウ サーバーは自身をプライマリ サーバーとして昇格し、シャドウ メッセージをプライマリ メッセージとして昇格させ、メッセージを次ホップに送信します。 時間間隔は、Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーターによって制御されます。 既定値は 3 時間です。

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

  • 処理中の各プライマリ メッセージのシャドウ サーバー。
  • シャドウ サーバーに送信される破棄状態。

シャドウ冗長マネージャーは、シャドウ サーバーがシャドウ キューに含むすべてのシャドウ メッセージに対して、次の処理を行います。

  • シャドウ メッセージごとのプライマリ サーバーの一覧の維持。
  • 元のデータベース ID と、メッセージのプライマリ コピーが格納されているキュー データベースの現在の ID の比較。
  • キューにシャドウ メッセージを持っている各プライマリ サーバーの可用性の確認。
  • プライマリ サーバーからの通知の破棄処理。
  • 適切な破棄通知すべてを受信した後に、シャドウ キューからシャドウ メッセージを削除。
  • シャドウ サーバーがシャドウ メッセージの所有権を引き継いでプライマリ サーバーになる時期の決定。
  • メッセージの重複コピーが完全に処理されるまで、メッセージの冗長コピーが解放されていないことを確認するために、メッセージの分岐と配信状態通知 (DSN) やジャーナル レポートなどのその他の副作用メッセージを追跡します。

次の表では、シャドウ メッセージの管理方法を制御するパラメーターについて説明します。

パラメーター 既定値 説明
Set-TransportConfig の ShadowHeartbeatFrequency 2 分 シャドウ サーバーが、メッセージの破棄状態をチェックするのにプライマリ サーバーへの SMTP 接続を開くまでに待機する最長時間。
Set-TransportConfig の ShadowResubmitTimeSpan 3 時間 サーバーがプライマリ サーバーで障害が発生したと判断するまでの待ち時間。この時間が経過すると、サーバーは、シャドウ キューにある、到達不可能なプライマリ サーバーのためのシャドウ メッセージの所有権を引き継ぎます。
Set-TransportConfig の ShadowMessageAutoDiscardInterval 2 日 サーバーが、正常に配信されたメッセージの破棄イベントを保持する期間。 プライマリ サーバーは、シャドウ サーバーがクエリを実行するまで破棄イベントをキューに保持します。 ただし、パラメーターで指定した期間内にプライマリ サーバーに対してシャドウ サーバーがクエリを実行しない場合は、プライマリ サーバーは、キューにある破棄イベントを削除します。
Set-TransportConfig の SafetyNetHoldTime 2 日 正常に処理されたメッセージがセーフティ ネットで保持される期間。 未確認のシャドウ メッセージは、Set-TransportService の SafetyNetHoldTime と MessageExpirationTimeout の合計の後、最終的に Safety Net から期限切れになります。
Set-TransportService の MessageExpirationTimeout 2 日 期限前にメッセージがキューに残る時間。

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

シャドウ冗長性により、サーバーの停止によるメッセージ損失が最小限に抑えられます。 障害が発生した後にトランスポート サーバーがオンラインに戻ると、次の 2 つのシナリオがあります。

  • サーバーは新しいトランスポート データベースを使用してオンラインに戻ります。このシナリオでは、データの破損やハードウェア障害が原因でトランスポート データベースが復旧できません。 この場合、トランスポート サーバーには新しいデータベース ID があるため、組織内の他のトランスポート サーバーによって新しいルートとして認識されます。 これは、サーバーを復旧できず、新しいサーバーが代替としてプロビジョニングされた状況にも当てはまります。

  • サーバーは同じトランスポート データベースでオンラインに戻ります。このシナリオでは、特定のトランスポート サーバーは失敗しませんでしたが、シャドウ サーバーがメッセージの所有権を引き受けて再送信するのに十分な時間はオフラインでした。 たとえば、ネットワーク カードの障害やサーバーのメンテナンスが長い場合は、このシナリオが発生します。

次の表は、シャドウ冗長性がこれら 2 つのシナリオにどのように対応するかをまとめたものです。 わかりやすくするために、障害が発生したサーバーの名前が Mailbox01 であるとします。

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

回復のシナリオ 実行された処理
Mailbox01 は、新しいデータベースを使用してオンラインに戻ります。 Mailbox01 が使用できなくなった場合、Mailbox01 のキューに入っているシャドウ メッセージを持つ各サーバーは、それらのメッセージの所有権を引き受けて再送信します。 その後、メッセージは宛先に配信されます。

メッセージの最大遅延は、Set-TransportConfig コマンドレットの ShadowHeartbeatFrequency パラメーターの値です。 既定値は 2 分です。
Mailbox01 は、同じデータベースでオンラインに戻ります。 Mailbox01 がオンラインに戻ると、メールボックス 01 のメッセージのシャドウ コピーを保持するサーバーによって既に配信されているキューにメッセージが配信されます。 これにより、これらのメッセージが重複して配信されます。 Exchange メールボックス ユーザーには、重複メッセージ検出のために重複メッセージが表示されません。 ただし、Exchange 以外のメッセージング システムの受信者は、メッセージの重複コピーを受け取る可能性があります。

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