Exchange Server のシャドウ冗長性

適用対象: 2016 2019 サブスクリプション エディション

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

Exchange 2016 および Exchange 2019 には、Exchange 2013 のシャドウ冗長性に対して行われたのと同じ機能強化があります。メールボックス サーバー上のトランスポート サービスは、送信サーバーへのメッセージの受信を確認する前に、受信したメッセージの冗長コピーを作成するようになりました。 シャドウ冗長性は送信側サーバーでサポートされている機能に依存しなくなったため (シャドウ冗長性のサポートの有無は関係ありません)、転送中のメッセージの冗長コピーを維持することは、機能する場合と機能しないベスト エフォート以上のものです (シャドウ冗長性のサポートの有無は関係ありません)。 これにより、トランスポート パイプライン内のすべてのメッセージが転送中に冗長化されるようになります。 Exchange が元のメッセージが転送中に失われたと判断した場合、メッセージの冗長コピーが再配信されます。

Exchange Server のトランスポートの高可用性機能の詳細については、「Exchange Server のトランスポートの高可用性」を参照してください。 メッセージが正常に配信された後のメッセージ冗長性の詳細については、「Exchange Server のセーフティ ネット」を参照してください。

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

次の表は、メールボックス サーバー上のトランスポート サービスにおけるシャドウ冗長のコンポーネントを示しています。 以下の用語は、このトピック全体で使用されます。

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

当たり前のことのように思えるかもしれませんが、シャドウ冗長性には複数のメールボックス サーバーが必要です。

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

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

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

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

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

• メッセージのシャドウ冗長に係わる 2 つ以上のメールボックス サーバーで同時に障害が発生しているとき。

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

既定では、シャドウ冗長はすべてのメールボックス サーバー上のトランスポート サービスでグローバルに有効です。 次の表に、シャドウ冗長を有効にするパラメーターを示します。

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

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

• トランスポート高可用性境界の外部から受信したメッセージ (DAG、もしくは非 DAG 環境内の Active Directory サイト)。

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

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

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

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

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

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

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

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

   • プライマリ サーバーが DAG のメンバーではない場合、プライマリ サーバーは同じ Active Directory サイト内の別のメールボックス サーバーに接続します ( ShadowMessagePreferenceSetting パラメーターの値に関係なく)。

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

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

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

メールボックス サーバーがトランスポートの高可用性境界外でメッセージを送信し、反対側のメッセージング サーバーがメッセージの受信に成功を確認し、メールボックス サーバーがメッセージをセーフティ ネットに移動する場合。 プライマリ メッセージがトランスポートの高可用性境界を越えて正常に送信された後は、セーフティ ネットからのメッセージを再送信することはできません。 セーフティ ネットの詳細については、「Exchange Server のセーフティ ネット」を参照してください。

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

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

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

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

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

SMTP のタイムアウト

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

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

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

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

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

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

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

シャドウ サーバーは、プライマリ サーバーを照会して、シャドウ キュー内のシャドウ メッセージの破棄状態を決定します。 シャドウ サーバーがなんらかの理由でプライマリ サーバーとの SMTP セッション (その他の無関係メッセージの送信を含む) を開くと、シャドウ サーバーは XQDISCARD コマンドを発行して、プライマリ メッセージの破棄状態を判断します。 それ以外の場合、シャドウ サーバーは、事前に構成された時間間隔 (Set-TransportConfig コマンドレットの ShadowHeartbeatFrequency パラメーター。既定値は 2 分) が経過した後に、プライマリ サーバーとの SMTP セッションを自動的に開きます。

シャドウ サーバーがプライマリ サーバーとの SMTP セッションを開くと、プライマリ サーバーは照会を行ったシャドウ サーバーに適用されるメッセージの破棄通知を応答します。 破棄通知はディスクに保存されるので (メモリではない)、Microsoft Exchange トランスポート サービスが再起動しても破棄通知は保持されます。 サービスが起動すると、プライマリ サーバーは正常に処理したメッセージを把握しているため、その情報はシャドウ サーバーにも通知されます。

シャドウ サーバーとプライマリ サーバーの間の SMTP 通信は、サーバーの可用性を判断する ハートビート として使用されます。 シャドウ サーバーがあらかじめ設定された時間間隔 (Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーター。既定値は 3 時間) が経過した後にプライマリ サーバーとの SMTP セッションを開くことができない場合、シャドウ サーバーは自身をプライマリ サーバーとして昇格させ、シャドウ メッセージをプライマリ メッセージとして昇格させ、メッセージを次のホップに送信します。 ただし、シャドウ サーバーは、プライマリ サーバーのキュー データベース ID が変更されたことを検出すると常に、シャドウ サーバーもプライマリ サーバーとして昇格し、シャドウ メッセージをプライマリ メッセージとして昇格させ、メッセージを次のホップに送信します。 これは、 ShadowResubmitTimeSpan パラメーター値が渡されるかなり前に発生する可能性があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

次の表は、シャドウ冗長がどのようにメッセージの損失を最小限に抑えるかをまとめています。 分かりやすくするため、停止したサーバーの名前を Mailbox01 とします。