シャドウ冗長

製品: 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. 組織が複数の Exchange 2013 メールボックス サーバーを使用できる場合にのみ冗長化できないメッセージを拒否するように Exchange 2013 を構成する必要があります。

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

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

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

シャドウ冗長の主要な目標は、メッセージが送信中であるときに、トランスポート高可用性境界内で、常にメッセージのコピーを 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 サーバーによるメッセージの再送信中に作成されたシャドウ メッセージの間に関係はありません。

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

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

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

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

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

シャドウ サーバーは、プライマリ サーバーを照会して、シャドウ キュー内のシャドウ メッセージの破棄状態を決定します。 シャドウ サーバーが何らかの理由でプライマリ サーバーとの 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) やジャーナル レポートなどのその他の副作用メッセージを追跡します。

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

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

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

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

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

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

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