シャドウ冗長について

適用先 : Exchange Server 2010

Exchange では、高可用性の戦略において、メールボックス データベース中に格納されているデータの可用性と回復性に重点を置きました。メールボックス サーバーに高可用性ソリューションを実装すると、電子メール メッセージは失われることなく、またメッセージがメールボックス到達した後にエラーが発生しても簡単に回復できます。

ただし、これらの戦略は送信中のメッセージには適用されません。メッセージの処理中にハブ トランスポート サーバーにエラーが発生して、回復できない場合、データ損失が発生する可能性がありました。ハブ トランスポート サーバーが処理するメッセージ量が増えてくると、管理者のデータ損失の可能性に対する心配も大きくなります。

Microsoft Exchange Server 2007 では、ハブ トランスポート サーバーの役割として、トランスポート収集機能が導入されました。Exchange 2007 ハブ トランスポート サーバーは、メールボックスがクラスター化メールボックス サーバーに存在する受信者に対して最近配信されたメッセージのキューを保持します。フェールオーバーが発生すると、クラスター化メールボックス サーバーは、Active Directory サイト内のすべてのハブ トランスポート サーバーに対し、トランスポート収集キューにあるメールを再送信するよう自動的に要求します。これにより、クラスターのフェールオーバーの間にメールが失われることを防ぐことができます。ここで提供されるのは基本レベルのトランスポート冗長であるため、クラスター連続レプリケーション (CCR) 環境でのメッセージ配信にのみ使用でき、ハブ トランスポート サーバーとエッジ トランスポート サーバー間でのメッセージ送信中に発生する潜在的なメッセージ損失に対しては機能しません。

Exchange Server 2010 では、シャドウ冗長機能が導入されており、メッセージの送信時間すべてに渡ってメッセージに冗長性を提供します。このソリューションでは、トランスポート収集と同様の手法が使用されています。シャドウ冗長を使用することで、トランスポート サーバーによってメッセージのすべての次ホップの配信完了が確認されるまで、トランスポート データベースからのメッセージ削除が延期されます。配信成功のレポートが返される前に次ホップにエラーが発生すると、そのメッセージは再送信されてエラーの発生した次ポップへ配信されます。

シャドウ冗長には、以下のような利点があります。

• 特定のハブ トランスポート サーバーまたはエッジ トランスポート サーバーの状態に依存する必要がなくなります。ルーティング トポロジに冗長メッセージ パスが存在する限り、トランスポート サーバーはすべて破棄可能となります。
• トランスポート サーバーにエラーが発生した場合、キューを空にしたりメッセージを失ったりすることなく、そのサーバーを運用から削除できます。
• ハブ トランスポート サーバーやエッジ トランスポート サーバーをアップグレードしたい場合は、メッセージを失うことなく、そのサーバーをいつでもオフラインにすることができます。
• トランスポート サーバーでのストレージ ハードウェアの冗長性の必要性がなくなります。
• これにより、複数のサーバーにメッセージの重複コピーを作成するより、帯域幅の消費が少なくなります。シャドウ冗長により追加で生成されるネットワーク トラフィックは、トランスポート サーバー間でやり取りされる破棄状態だけです。破棄状態は、各トランスポート サーバーが保持する情報です。これは、メッセージがトランスポート データベースから破棄できる状態になっていることを示します。
• 復元を提供し、トランスポート サーバーの障害からの復旧を単純化します。

シャドウ冗長は、SMTP サービスを拡張することによって実装されます。サービス拡張によって、SMTP ホストはシャドウ冗長のサポートをネゴシエートし、シャドウ メッセージの破棄状態をやり取りできます。

トランスポート サーバーの管理に関連する管理タスクについては、「トランスポート サーバーの管理」を参照してください。

目次

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

シャドウ冗長のメッセージ フロー

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

メッセージを停止した後の処理

シャドウ冗長性に必要な拡張権利

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

次の表は、シャドウ冗長のすべてのコンポーネントについて説明します。

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

コンポーネント	説明
プライマリ メッセージ	配信用にトランスポートに送信された元のメッセージ。
シャドウ メッセージ	トランスポート サーバーが、メッセージの次ポップすべてが問題なく配信されたことを確認するまで保持するメッセージのコピー。
プライマリ サーバー	現在メッセージを処理しているトランスポート サーバー。
シャドウ サーバー	プライマリ サーバーへのメッセージ配信後に、メッセージのシャドウ コピーを保持するトランスポート サーバー。
シャドウ キュー	トランスポート サーバーを使用してシャドウ メッセージを格納するキュー。トランスポート サーバーは、プライマリ メッセージの配信先であるホップごとに、個別にシャドウ キューを持ちます。
破棄状態	トランスポート サーバーが保持する、シャドウ メッセージが破棄可能な状態であることを示す情報。
破棄通知	シャドウ サーバーがプライマリ サーバーから受信する、メッセージが破棄可能な状態であることを示す応答。
シャドウ冗長マネージャー	シャドウ冗長を管理するトランスポート コンポーネント。
ハートビート	相互の可用性を確認するトランスポート サーバーのプロセス。

ページのトップへ

シャドウ冗長のメッセージ フロー

シャドウ冗長が有効なメール フローについて説明するために、ハブ トランスポート サーバーが、境界ネットワークのエッジ トランスポート サーバー経由で、サード パーティのメール サーバーに対してメッセージを送信するという簡単なシナリオを考えてみましょう。

シャドウ冗長が有効なメッセージ フロー

このシナリオでは、メッセージ フローは次の段階を通過します。

1. ハブ トランスポート サーバーがエッジ トランスポート サーバーにメッセージを配信します。
   1. ハブ トランスポート サーバーがエッジ トランスポート サーバーとの SMTP セッションを開始します。
   2. エッジ トランスポートがシャドウ冗長のサポートを通知します。
   3. ハブ トランスポート サーバーが、エッジ トランスポート サーバーに破棄状態の追跡を通知します。
   4. ハブ トランスポート サーバーがエッジ トランスポート サーバーにメッセージを送信します。
   5. エッジ トランスポート サーバーがメッセージ受信を確認し、メッセージの破棄情報を送信するためハブ トランスポート サーバー名を記録します。
   6. ハブ トランスポート サーバーがメッセージをエッジ トランスポート サーバー向けのシャドウ キューに移動し、エッジ トランスポート サーバーをプライマリ サーバーとしてマークします。ハブ トランスポート サーバーはシャドウ サーバーになります。
2. エッジ トランスポート サーバーは、次ホップにメッセージを配信します。
   1. エッジ トランスポート サーバーは、サード パーティのメール サーバーにメッセージを送信します。
   2. サード パーティのメール サーバーがメッセージの受信を確認します。
   3. エッジ トランスポート サーバーが、メッセージの破棄状態を配信完了に更新します。
3. ハブ トランスポート サーバーがエッジ トランスポート サーバーに対し、破棄状態に関するクエリを実行します (成功した場合)。
   1. ハブ トランスポート サーバーは、エッジ トランスポート サーバーとの各 SMTP セッションの終了時に、エッジ トランスポート サーバーに対し、以前送信したメッセージの破棄状態に関するクエリを実行します。ハブ トランスポート サーバーが最初のメッセージ送信後にエッジ トランスポート サーバーとの SMTP セッションを開始していなかった場合、ハブ トランスポート サーバーは一定の時間経過後に、破棄状態に関するクエリ実行だけを目的として、エッジ トランスポート サーバーとの SMTP セッションを開始します。
   2. エッジ トランスポート サーバーがローカルの破棄状態を確認し、配信済みのメッセージ一覧を返信した後、破棄情報を削除します。
   3. ハブ トランスポート サーバーがシャドウ キューからメッセージ一覧を削除します。
4. ハブ トランスポート サーバーがエッジ トランスポート サーバーに対し、破棄状態に関するクエリを実行し、メッセージを再送信します (失敗した場合)。
   1. ハブ トランスポート サーバーがエッジ トランスポート サーバーと通信できない場合、ハブ トランスポート サーバーはプライマリ サーバーの役割を再開し、シャドウ キューにあるメッセージを再送信します。
   2. 再送信されたメッセージは他のエッジ トランスポート サーバーに配信され、ワークフローが第 1 段階から開始されます。

      注 :
      (前の図の 2 番目のエッジ トランスポート サーバーのような) シャドウ メッセージに使用できる代替ルートがない場合、そのメッセージは再送信されませんが、シャドウ キューに残ります。

さまざまな異なるシナリオでのメッセージ フローの詳細については、「シャドウ冗長メール フローのシナリオ」を参照してください。

複数ホップのシナリオ

メッセージがシャドウ冗長をサポートする複数のサーバーを経由する場合、シャドウ メッセージは、メッセージ パス内の次のサーバーによって配信が確認されるまでの間だけ、サーバーに保持されます。この動作について説明するため、ハブ トランスポート サーバーがインストールされている 5 つの Active Directory サイトのある組織について考えてみます。サイトは次の図のように相互に接続されています。組織には、ハブ サイトとして構成されている New York と London というサイトがあるため、Chicago や Atlanta からのメッセージが Dublin というサイトに到達するためには、New York サイトと London サイトのハブ トランスポート サーバーを経由する必要があります。

複数ホップのシナリオのサンプル トポロジ

メッセージが Chicago サイトのユーザーから Dublin サイトのユーザーに送信されるとします。このメッセージが Dublin に到達するには、New York サイトと London サイトを経由する必要があります。この場合は次の処理が行われます。

1. Chicago のハブ トランスポート サーバーは、New York のハブ トランスポート サーバーにメッセージを送信し、メッセージのシャドウ コピーを保持します。
2. New York のハブ トランスポート サーバーは、London のハブ トランスポート サーバーにメッセージを送信し、Chicago のハブの破棄状態をキューに登録します。
3. Chicago のハブは New York のハブに対し、メッセージの破棄状態に関するクエリを実行して破棄通知を受信します。この時点で、シャドウ メッセージをデータベースから削除できます。メッセージが London から Dublin に配信されたかどうかは、Chicago サーバーがシャドウ メッセージを削除する際には影響しません。

相互運用性

シャドウ冗長が使用されるかどうかは、新しい SMTP 接続を確立する間に決定されます。SMTP 接続している両方のサーバーがシャドウ冗長をサポートしていれば、前述のワークフローが使用されます。ただし、Exchange 2010 トランスポート サーバーがシャドウ冗長をサポートしていないメール サーバーとメッセージをやり取りするという状況もあります。このような状況としては、サード パーティのメール サーバー、以前のバージョンの Exchange、またはシャドウ冗長が有効になっていない Exchange 2010 組織などの場合があります。

シャドウ冗長をサポートしているExchange 2010 トランスポート サーバーがシャドウ冗長をサポートしていないサーバーとの接続を確立すると、以下のイベントが発生します。

1. Exchange によってターゲット サーバーへの SMTP 接続が確立されます。
2. ターゲット サーバーは、シャドウ冗長のサポートを通知しません。
3. ターゲット サーバーが冗長をサポートしていないため、Exchange は各メッセージで以下を実行します。
   1. ターゲット サーバーにメッセージを配信します。
   2. シャドウ冗長マネージャーによって、次ポップへのメッセージ配信がマークされます。
   3. すべての次ホップに配信された後で、メッセージを削除します。

シャドウ冗長をサポートしていないサーバーが Exchange 2010 サーバーとの接続を確立すると、次のイベントが発生します。

1. 送信側サーバーが Exchange を使用して SMTP 接続を確立します。
2. Exchange が、シャドウ冗長のサポートを通知します。
3. 送信サーバーはシャドウ冗長をサポートしていないため、これを使用しません。Exchange サーバーにメッセージを配信します。
4. Exchange は受信した各メッセージに次の操作を行います。
   1. 次ホップにメッセージを配信するか、そのシャドウ コピーを作成します。
   2. 受信確認を送信側サーバーに送信します。

遅延受信確認

シャドウ冗長の主な原則は、すべての次ホップにメッセージが問題なく配信されたことをサーバーが確認するまで、前のホップにメッセージのコピーを保持することです。これは、Exchange 2010 トランスポート サーバーがシャドウ冗長をサポートしていないメール サーバーからメッセージを受信している場合には不可能です。このようなメール サーバーは、以前のバージョンの Exchange を実行する Exchange サーバー、標準の SMTP クライアント、またはインターネット上の Exchange 以外のメール サーバーである可能性があります。この場合 Exchange は、すべての次ポップへのメッセージ配信が内部で問題なく完了したことを確認するまでメール サーバーへの受信確認を遅らせることで、シャドウ冗長を達成しようとします。この方法の場合、Exchange 2010 サーバーに問題が発生すると、送信メール サーバーはメッセージが Exchange に配信されなかったものとして、再度配信しようとします。

ただし次ホップへのメッセージ配信は、ルーティング インフラストラクチャが複雑であったり、次ホップの 1 つにエラーがあることが原因で時間がかかる場合があります。このような場合、Exchange 2010 トランスポート サーバーは、SMTP セッションがタイムアウトしないよう、送信メール サーバーに受信確認を送信します。この場合、メールの冗長性は保証されませんが、これがベスト エフォートです。たとえば、メッセージは以下の状況で失われる可能性があります。インターネット メール サーバーは、エッジ トランスポート サーバーにメッセージを送信します。エッジ トランスポート サーバーは、ネットワークの問題が原因でハブ トランスポート サーバーと通信できず、メッセージの受信確認をインターネット メール サーバーに送ります。次にエッジ トランスポート サーバーにエラーが発生し、ネットワークの問題が解決するまで回復できません。この時点で、メッセージは失われます。

遅延した受信確認のタイムアウト値は、各受信コネクタの MaxAcknowledgementDelay 属性によって制御されます。 既定値は 30 秒です。この属性の構成の詳細については、「シャドウの冗長性を構成する」を参照してください。

ページのトップへ

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

シャドウ冗長マネージャーは、シャドウ冗長を管理する Exchange 2010 トランスポート サーバーのコア コンポーネントです。

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

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

シャドウ冗長マネージャーは、サーバーがシャドウ キューに持っているすべてのシャドウ メッセージに関する以下の機能を持ちます。

• シャドウ メッセージごとのプライマリ サーバーの一覧の維持。
• キューにシャドウ メッセージを持っている各プライマリ サーバーの可用性の確認。
• プライマリ サーバーからの通知の破棄処理。
• すべての予想される破棄通知の受信後に、データベースからシャドウ メッセージを削除。
• シャドウ サーバーがシャドウ メッセージの所有権を引き継いでプライマリ サーバーになる時期の決定。

またシャドウ冗長マネージャーは、シャドウ冗長に関するパフォーマンス カウンターの管理も行います。

ハートビート

シャドウ冗長マネージャーはハートビートを使用して、キューにシャドウ メッセージを持つサーバーの可用性を判断します。シャドウ冗長をサポートする 2 台のサーバー間の SMTP セッションの間に、接続を開始するサーバーはターゲット サーバーに対して、以前そのサーバーに送信されたメッセージの破棄状態についてのクエリを実行します。開始側のサーバーは、XQUERYDISCARD コマンドを実行して操作を実行します。応答として、対象サーバー破棄通知を返します。この 2 台のサーバー間のやり取りは、シャドウ冗長のハートビートとして使用されます。

ハートビートにはタイムアウト値があります。(シャドウ冗長マネージャーがその期間のシャドウ キューを保持している) サーバーとの間で接続が確立していない場合、サーバーは破棄状態のクエリを実行してタイマーをリセットするため、プライマリ サーバーとの間に SMTP 接続を確立しようとします。タイムアウト値は Set-TransportConfig コマンドレットの ShadowHeartbeatTimeoutInterval パラメーターによって制御され、デフォルトで 300 秒に設定されています。

タイムアウト値に達した時点でサーバーがプライマリ サーバーとの接続を確立できていないと、サーバーはタイマーをリセットして再試行します。3 回連続してタイムアウト値に達すると、サーバーはプライマリ サーバーが失敗したと判断し、シャドウ メッセージの所有権を前提として、失敗したプライマリ サーバーに送信するシャドウ メッセージの破棄通知の生成を開始します。サーバーが、プライマリ サーバーが失敗したと判断する前に待機するタイムアウトの回数は、Set-TransportConfig コマンドレットの ShadowHeartbeatRetryCount パラメーターで制御されます。

シャドウ冗長のハートビートの構成の詳細については、「シャドウの冗長性を構成する」を参照してください。

ページのトップへ

メッセージを停止した後の処理

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

• サーバーが新しいトランスポート データベースで再度オンラインになる   このシナリオでは、トランスポート データベースはデータの破損またはハードウェアのエラーが原因で回復不能となっています。この場合、トランスポート データベースは新しいデータべース ID を持つため、組織内の他のトランスポート サーバーはこれを新しいルートと認識します。これは、サーバーが回復できず、新しいサーバーが代わりにプロビジョニングされた場合にも適用されます。
• サーバーが同じトランスポート データベースで再度オンラインになる   これは、特定のトランスポート サーバーが、失敗はしていないが長時間オフラインになっていた場合のシナリオです。たとえばネットワーク カードのエラーや、長時間のサーバー保守などが、このシナリオの原因となります。

次の表は、シャドウ冗長が有効な場合の、これら 2 つのシナリオでのトランスポートの対応方法についてまとめたものです。簡略化のため、停止したサーバーの名前を Hub01 としています。

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

回復の事例	代替ルートを持つメッセージに対して実行されたアクション	メッセージでない代替ルート アクション
Hub01 で新しいデータベースがオンラインに復帰する。	Hub01 が使用不可となると、Hub01 のシャドウ メッセージをキューに持つ各サーバーは、それらのメッセージの所有権を前提として、メッセージを再送信します。メッセージは、代替ルートを使用して、宛先に配信を取得します。 メッセージ遅延の合計時間は、組織で構成されているハートビートのタイムアウト間隔と、ハートビートの再試行回数を掛けた値と同じになります。	これらのメッセージは、Hub01 のシャドウ メッセージをキューに持つ各サーバーのシャドウ キューに残ります。Hub01 が新しいデータベース ID で再度オンライン状態になると、シャドウ サーバーによってそれが新しいデータベースとして検出され、シャドウ キューにあるメッセージが Hub01 に再送信されます。これは、これらのメッセージ用の代替ルートを即座に検出するのと同等です。 メッセージの遅延時間の合計は、停止時間により変わります。
Hub01 で同じデータベースがオンラインに復帰する。	Hub01 はキュー内のメッセージを配信します。結果として、これらのメッセージは重複配信されることになります。Exchange メールボックス ユーザーには、重複メッセージの検出のために重複したメッセージは表示されません。ただし、外部システム上の受信者には、重複コピーが表示されることがあります。 メッセージ遅延の合計時間は、組織で構成されているハートビートのタイムアウト間隔と、ハートビートの再試行回数を掛けた値と同じになります。	Hub 01 はキュー内のメッセージを配信し、次にシャドウ サーバーに破棄通知を送信します。 メッセージの遅延時間の合計は、停止時間により変わります。

ページのトップへ

シャドウ冗長性に必要な拡張権利

Exchange 2010 はシャドウ冗長性を実現するために必要な次の 2 つの拡張権利を導入します。

• ms-Exch-SMTP-Accept-XSHADOW
• ms-Exch-SMTP-Send-XSHADOW

Exchange 2010 トランスポート サーバーとの SMTP 接続が確立されると、ms-Exch-SMTP-Accept-XSHADOW という拡張された権利が使用中の受信コネクタに存在する場合は、シャドウ冗長のサポートが通知されます。また受信コネクタでの認証機構は、Exchange Server 認証であるか、外部的にセキュリティで保護されているかのいずれかである必要があります。

Exchange 2010 トランスポート サーバーが、シャドウ冗長のサポートを通知している他のサーバーとの SMTP 接続を確立すると、セッションに対して ms-Exch-SMTP-Send-XSHADOW という拡張された権利が付与されている場合にのみ、XSHADOW コマンドが発行されます。

既定では、これらの拡張された権利は、内部の送信コネクタおよび受信コネクタの Exchange Server グループすべてに対して付与されます。

注 :
シャドウ冗長性は、Set-TransportConfig コマンドレットの ShadowRedundancyEnabled パラメーターを使用することで、組織全体で有効または無効にできます。この設定は、ここで説明する拡張権利よりも優先されます。組織でシャドウ冗長性が無効になっていると、必要な拡張された権利が SMTP セッションに付与されていても、Exchange がシャドウ冗長のサポートを通知したり XSHADOW コマンドを発行したりすることはありません。

ページのトップへ