シャドウ冗長

製品: Exchange Server 2013

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

Microsoft Exchange Server 2013 のシャドウ冗長性に対する主な機能強化は、トランスポート サーバーが、送信側サーバーへのメッセージの正常な受信を確認する前に、受信したすべてのメッセージの冗長コピーを作成するようになったことです。 シャドウ冗長性に対する送信側サーバーのサポート有無は関係ありません。 これにより、Exchange 2013 トランスポート パイプライン内のすべてのメッセージが転送中に冗長化されるようになります。 元のメッセージが転送中に失われたと 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. organizationで複数の Exchange 2013 メールボックス サーバーを使用できる場合にのみ、冗長にすることができないメッセージを拒否するように Exchange 2013 を構成する必要があります。

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

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

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

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

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

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

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

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

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

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

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

2. SMTP サーバーとの元の SMTP セッションがまだアクティブな間は、プライマリ サーバー上のトランスポート サービスは、organization 内の別のメールボックス サーバー上のトランスポート サービスとの新しい同時 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 サイト内の任意の場所に存在する場合に達成されます。 通常、メールボックス サーバー上のアクティブなキューをドレインするために Redirect-Message コマンドレットを必要とする 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 ハブ トランスポート サーバーから受け取った後、Exchange 2013 メールボックス サーバーは、正常に処理されたメッセージをセーフティ ネットに移動します。 ただし、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 サーバーによるメッセージの再送信中に作成されるシャドウ メッセージの間に関係はありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の表は、これら 2 つのシナリオに対するシャドウ冗長性の応答をまとめたものです。 わかりやすくするために、機能が停止したサーバーの名前が Mailbox01 であるとします。

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