シャドウ冗長について

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2015-03-09

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

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

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

Exchange Server 2010 では、シャドウ冗長機能が導入されており、メッセージが送信される期間中メッセージに冗長性を提供します。このソリューションでは、トランスポート収集と同様の手法が使用されています。シャドウ冗長を使用することで、トランスポート サーバーがメッセージのすべてのネクスト ホップの配信が完了したことを確認するまで、トランスポート データベースのメッセージの削除は遅延されます。配信の成功が報告される前にいずれかの次ホップが失敗した場合、メッセージはその次ホップに対する配信のために再送信されます。

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

• 特定のハブ トランスポート サーバーまたはエッジ トランスポート サーバーの状態に依存する必要がなくなります。ルーティング トポロジに冗長メッセージ パスが存在する限り、トランスポート サーバーはすべて破棄可能となります。

• トランスポート サーバーにエラーが発生した場合、キューを空にしたりメッセージを失ったりすることなく、そのサーバーを運用から削除できます。

• ハブ トランスポート サーバーやエッジ トランスポート サーバーをアップグレードしたい場合は、メッセージを失うことなく、そのサーバーをいつでもオフラインにすることができます。

• トランスポート サーバーでのストレージ ハードウェアの冗長性の必要性がなくなります。

• これにより、複数のサーバーにメッセージの重複コピーを作成するより、帯域幅の消費が少なくなります。シャドウ冗長により追加で生成されるネットワーク トラフィックは、トランスポート サーバー間でやり取りされる破棄状態だけです。破棄状態は、各トランスポート サーバーが保持する情報です。これは、メッセージがトランスポート データベースから破棄できる状態になっていることを示します。

• 復元を提供し、トランスポート サーバーの障害からの復旧を単純化します。

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

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

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

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

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

ページのトップへ

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

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

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

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

1. ハブ トランスポート サーバーがエッジ トランスポート サーバーにメッセージを配信します。

   1. ハブ トランスポート サーバーがエッジ トランスポート サーバーとの SMTP セッションを開始します。

   2. エッジ トランスポートがシャドウ冗長のサポートを通知します。

   3. ハブ トランスポート サーバーが、エッジ トランスポート サーバーに破棄状態の追跡を通知します。

   4. ハブ トランスポート サーバーがエッジ トランスポート サーバーにメッセージを送信します。

   5. エッジ トランスポート サーバーがメッセージ受信を確認し、メッセージの破棄情報を送信するためハブ トランスポート サーバー ID を記録します。

   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 サーバーがシャドウ メッセージを削除する際には影響しません。

ハブ トランスポートとメールボックス サーバーの役割が DAG と共存している場合のシャドウ冗長保護

データベース可用性グループ (DAG) を使用している場合、メールボックス データベースにコミットされているメッセージは DAG アーキテクチャで保護されます。DAG の一部であるメールボックス データベースに配信されるメッセージの場合、すべての DAG メンバーにメッセージがレプリケートされるまで、そのメッセージのシャドウ コピーがトランスポート収集に保持されます。同様に、DAG メンバーからハブ トランスポート サーバーに送信されるメッセージには 2 つのコピーがあります。1 つはハブ トランスポート サーバー キューで配信まで待機しているコピー、もう 1 つは送信者の送信済みアイテム フォルダー内のシャドウ コピーです。この方法が、シャドウ冗長の重要なコンポーネントです。

ただし、ハブ トランスポートとメールボックス サーバーの役割が同じサーバー上に共存しており、DAG の一部であるメールボックス データベースがある場合は、同じサーバーのハードウェアにプライマリ メッセージとシャドウ メッセージが混在しないよう、ハブ トランスポート サーバーが別のホップ経由でメッセージをルーティングする必要がある場合があります。ハブ トランスポートの役割は、特に次の 2 つのシナリオを回避しようとします。1 台のサーバーで障害が発生した結果、プライマリ メッセージとシャドウ メッセージの両方が失われる可能性があるためです。

• メッセージ配信時に、メッセージ受信者のアクティブ メールボックス データベースと、メッセージのシャドウ コピーを含むトランスポート収集が同じサーバー上にある このシナリオを回避するため、ハブ トランスポート サーバーはサイト内の別のハブ トランスポート サーバー経由でメッセージをルーティングします。これにより、シャドウ メッセージが別のサーバー ハードウェアに到達します。ただし他のハブ トランスポート サーバーが使用できない場合、メッセージは直接配信されます。

• メッセージ送信時に、プライマリ メッセージを含むトランスポート キューと、送信者の送信済みアイテムフォルダー内のシャドウ メッセージが、同じサーバー上に存在する   このシナリオを回避するため、ストア ドライバーにとっては、サイト内にメッセージ送信用の他のハブ トランスポート サーバーがある方が望ましい状態です。ただし、サイト内で他のハブ トランスポート サーバーを使用できない場合、ストア ドライバーはローカルのハブ トランスポート サーバーに直接メッセージを送信します。

DAG 使用時にハブ トランスポートとメールボックス サーバーの役割が共存する場合の詳細については、「DAG を使用する場合の、ハブ トランスポートとメールボックス サーバーの役割の共存」を参照してください。

相互運用性

シャドウ冗長が使用されるかどうかは、新しい 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 秒です。この属性の構成の詳細については、「シャドウの冗長性を構成する」を参照してください。

遅延受信確認の省略

遅延受信確認がタイムアウトにならないとメッセージが配信されないような場合もあります。このような場合、トランスポート サーバーは、次のいずれかの方法を使用してメッセージを操作します。

• 遅延受信確認のスキップ トランスポート サーバーは、SMTP 受信スループットを維持するため、既定で遅延受信確認をスキップします。トランスポート サーバーは基本的に、タイムアウトになる前に確認を発行します。

• シャドウ冗長プロモーション Microsoft Exchange Server 2010 Service Pack 1 (SP1) では、遅延受信確認をスキップするのではなく、サイト内の別のトランスポート サーバーにメッセージを中継するようにトランスポート サーバーを構成することができます。これにより、メッセージをシャドウ冗長パイプラインに効率的に挿入して保護できます。このプロセスは、シャドウ冗長プロモーションと呼ばれます。この方法では、遅延受信確認をスキップする場合よりも、組織内の保護されないメッセージ数を最小限に減らすことができます。既定では、この機能は無効になっています。シャドウ冗長プロモーションを有効にするには、管理者が Edgetransport.exe.config ファイルを編集し、shadowredundancypromotionenabled キーを true に変更し、この変更をファイルに保存し、Microsoft Exchange Transport サービス (MSExchangeTransport.exe) を再起動する必要があります。その詳細な方法については、シャドウの冗長性を構成する トピックの「シャドウ冗長プロモーションを有効にする」セクションを参照してください。

次の表では、トランスポート サーバーによる遅延受信確認の省略に関する異なるシナリオと、Exchange 2010 サーバーによるそのシナリオの処理方法について示します。

ページのトップへ

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

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

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

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

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

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

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

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

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

• すべての予想される破棄通知の受信後に、データベースからシャドウ メッセージを削除。

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

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

ハートビート

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

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

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

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

ページのトップへ

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

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

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

• サーバーが同じトランスポート データベースで再度オンラインになる   これは、特定のトランスポート サーバーが、失敗はしていないが長時間オフラインになっていた場合のシナリオです。たとえばネットワーク カードのエラーや、長時間のサーバー保守などが、このシナリオの原因となります。

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

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

ページのトップへ

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

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 グループすべてに対して付与されます。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.