DAG を使用する場合の、ハブ トランスポートとメールボックス サーバーの役割の共存

  • [アーティクル]

 

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

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

Microsoft Exchange Server 2007 では、シングル コピー クラスター (SCC) またはクラスター連続レプリケーション (CCR) などの高可用性機能を使用するときに、同じサーバー ハードウェア上でのハブ トランスポート サーバーとメールボックス サーバーの役割の共存はサポートされていません。Exchange 2007 での高可用性展開では、最低限次の 4 台のサーバーが必要になります。メールボックスの高可用性のための 2 つのノード、およびメッセージ転送の冗長化のための 2 台のハブ トランスポート サーバー。

高可用性ソリューションを提供するのに必要なサーバー数を削減するために、Exchange Server 2010 では、データベース可用性グループ (DAG) を使用するときに、同じサーバー ハードウェア上でのハブ トランスポート サーバーとメールボックス サーバーの役割の共存がサポートされています。Exchange 2010 では、シャドウ冗長と呼ばれる、メッセージの転送中のデータの消失を保護する機能が提供されていますこれらの機能を併用すると、DAG とシャドウ冗長によって復元性の高いメッセージング インフラストラクチャが実現されます。

ここでは、DAG に参加しているメールボックス サーバーと同じサーバー ハードウェア上に展開されるときの Exchange 2010 ハブ トランスポート サーバーの役割の動作について説明します。DAG の詳細については、「データベース可用性グループについて」を参照してください。

メッセージの送信と配信

シャドウ冗長は、メッセージ パスに従ってメッセージの重複コピーを保持することで、メッセージ送信中のデータの消失を防ぎます。障害によりメッセージが送信中に消失すると、メッセージのシャドウ コピーがトランスポート コンポーネントによって再送信されます。シャドウ冗長の実装方法の詳細については、「シャドウ冗長について」を参照してください。

メールボックス サーバーは、ユーザーが [送信] をクリックしたときの最初のメッセージ送信時と、メッセージが受信者の受信トレイに保存されたときの最後の配信時に処理を実行します。メッセージがトランスポートに送信されると、メッセージのプライマリ コピーは、メッセージを送信したハブ トランスポート サーバーのキューに入ります。そのメッセージのシャドウ コピーは、送信者の送信済みアイテム フォルダーに保存されるアイテムになります。メッセージが配信されると、そのプライマリ コピーは受信者の受信トレイに保存され、そのメッセージのシャドウ コピーはトランスポート収集内に保存されます。

同じサーバー ハードウェア上でのハブ トランスポート サーバーとメールボックス サーバーの役割の共存という高可用性シナリオでは、同じサーバー上にメッセージの 2 つのコピーを保存しないようにすることが重要です。次の図に示す展開のシナリオを検証します。トポロジは、ハブ トランスポート サーバーの役割がインストールされている DAG に参加する 2 台の Exchange サーバーで構成されます。データベース DB1 と DB2 は DAG の一部です。アクティブ データベースは緑色で示され、パッシブ データベースは青色で示されます。

ハブ トランスポート サーバーとメールボックス サーバーの役割を持つ 2 台のサーバーの高可用性トポロジ

ハブおよびメールボックスの役割を持つ 2 つのサーバーの HA トポロジ

このトポロジでは、DB1 上にメールボックスを持つユーザーがメッセージを送信することを前提とします。このメッセージが Server1 上のハブ トランスポート サーバーの役割に送信されると、プライマリ メッセージとシャドウ メッセージは両方とも Server1 に物理的に保存されます。次の図に示すように、プライマリ メッセージはハブ トランスポート サーバーのキューに入り、シャドウ メッセージは送信者の送信済みアイテム フォルダーに保存されます。

望ましくない送信パス

望ましくない送信パス

同様に、Server1 のハブ トランスポート サーバーの役割が DB1 のユーザー宛てのメッセージを受け取ると、メッセージは直接配信され、プライマリ メッセージとシャドウ メッセージは両方とも Server1 に物理的に保存されます。次の図に示すように、プライマリ メッセージは受信者の受信トレイに保存され、シャドウ メッセージはトランスポート収集に保存されます。これらのインスタンスのいずれかでサーバー障害が発生すると、メッセージが消失する可能性があります。

望ましくない配信パス

望ましくない配信パス

メッセージの消失が発生する可能性があるこうしたシナリオを回避するために、Exchange では、メッセージのプライマリ コピーとシャドウ コピーが確実に異なる物理サーバーに保存されるルートを経由して、メッセージが送信または配信されます。次のセクションでは、変更されたメッセージの送信と配信の動作について説明します。

メッセージ送信の動作

DAG のメンバーであるデータベースにメールボックスを持つユーザーがメッセージを送信すると、メール送信サービスは、ローカル サーバー上にもハブ トランスポート サーバーがインストールされていることを検出しても、リモート ハブ トランスポート サーバーを優先します。図 "ハブ トランスポート サーバーとメールボックス サーバーの役割を持つ 2 台のサーバーの高可用性トポロジ" に示すように、DB1 にメールボックスを持つユーザーがメッセージを送信すると、メール送信サービスは、Server2 にインストールされているハブ トランスポート サーバーを使用して、メッセージを送信しようとします。次の図はこの優先メッセージ送信パスを示したものです。

優先送信パス

優先送信パス

サイト内に他に利用可能なハブ トランスポート サーバーが存在しない (たとえば、予定された保守のために Server2 が利用できない) 場合では、メッセージ送信サービスはローカル ハブ トランスポート サーバーへのメッセージ送信にフォールバックします。これが冗長性を確保にとって望ましくない送信パスであったとしても、Exchange はメッセージの配信を遅延しません。可用性および短い配信待機時間という点からは、このフォールバック送信パスは望ましいものです。

メッセージ配信の動作

メッセージ ルーティングと配信の動作はほとんど変更されていません。たとえば、図 "ハブ トランスポート サーバーとメールボックス サーバーの役割を持つ 2 台のサーバーの高可用性トポロジ" に示す Server1 が DB2 の受信者のメールを受信すると、Server1 は、データベースが別のサーバー上でアクティブであるため、通常どおりメッセージを配信します。ハブ トランスポート サーバーが受信メッセージを異なる方法で処理する唯一のシナリオは、対象となるメールボックスが DAG の一部であるデータベース上にあり、さらにローカル サーバー上でアクティブである場合です。このシナリオではメールを直接配信すると、配信されたメッセージと、トランスポート収集内に保存されたコピーの両方が同じサーバー上に存在することになるため、ハブ トランスポート サーバーは、このメッセージを同じサイト内の別のハブ トランスポート サーバーに再ルーティングします。次の図は、このシナリオでのメッセージ配信パスを示します。

優先配信パス

優先配信パス

サイト内に利用可能なハブ トランスポート サーバーが他に存在しない場合は、冗長の確保のためには望ましくない配信パスであっても、ハブ トランスポート サーバーはローカル配信にフォールバックします。先ほどと同様に、可用性および短い配信待機時間という点からは、このフォールバック配信パスは望ましいものです。

メッセージ フローのシナリオ

ここでは、ハブ トランスポート サーバーとメールボックス サーバーの役割を同じサーバーに共存させるときのメッセージ フローのさまざまなシナリオにおける処理を詳細に説明します。次の図に示すトポロジを使用して、メッセージ フローの考えられるさまざまなシナリオを説明します。

メッセージ フローのシナリオのサンプル トポロジ

メッセージ フローのシナリオのサンプル トポロジ

次の表は、さまざまなシナリオで Server1 上のハブ トランスポート サーバーの役割がメッセージをどのように処理するかを示します。これらすべてのケースでは、Server1 をエントリ ポイントとしています。

送信者の場所 受信者の場所 通常のメッセージ パス 高可用性のシナリオ

DB1、Server1 でアクティブになる

DB1、Server1 でアクティブになる

  1. Server1 の送信サービスは、Server2 のハブ トランスポート サーバーの役割にメッセージを送信します。

  2. Server2 のハブ トランスポート サーバーの役割は、Server1 の DB1 にメッセージを配信し、そのメッセージを Server2 のトランスポート収集に追加します。

  • メッセージの送信が完了する前に Server1 に障害が発生すると、送信者の送信トレイにあるメッセージは消失する可能性があります。

  • メッセージの送信が完了する前に Server2 に障害が発生すると、メッセージは Server1 のハブ トランスポート サーバーの役割に送信されます。

  • Server2 のハブ トランスポート サーバーの役割へのメッセージ送信が完了した後に Server1 に障害が発生すると、DB1 は Server2 でアクティブになります。メッセージは、DB1 がマウントされるまで Server2 のキューに入り、ハブ トランスポート サーバーの役割によってローカルに配信されます。

  • Server2 のハブ トランスポート サーバーの役割へのメッセージ送信が完了した後に Server2 に障害が発生すると、DB1 内のシャドウ メッセージは Server1 のハブ トランスポート サーバーの役割に再送信され、Server1 のハブ トランスポート サーバーの役割によってローカルに配信されます。

  • メッセージ配信が完了した後に Server1 に障害が発生すると、DB1 は Server2 でアクティブになります。配信されたメッセージがデータベースにコミットされていない場合は、このメッセージは Server2 のトランスポート収集から再度配信されます。

DB1、Server1 でアクティブになる

DB2、Server2 でアクティブになる

  1. Server1 の送信サービスは、Server2 のハブ トランスポート サーバーの役割にメッセージを送信します。

  2. Server2 のハブ トランスポート サーバーの役割は、Server1 のハブ トランスポート サーバーの役割にメッセージを再ルーティングします。

  3. Server1 のハブ トランスポート サーバーの役割は、Server2 の DB2 にメッセージを配信し、そのメッセージを Server1 のトランスポート収集に追加します。

  • メッセージ送信の完了前にいずれかのサーバーに障害が発生すると、前の行の説明と同じ方法で障害が処理されます。

  • Server2 のハブ トランスポート サーバーの役割へのメッセージ送信が完了した後に Server1 に障害が発生すると、Server2 のハブ トランスポート サーバーの役割はメッセージをローカルに配信します。

  • Server2 のハブ トランスポート サーバーの役割へのメッセージ送信が完了した後に Server2 に障害が発生すると、DB2 は Server1 でアクティブになります。Server1 のハブ トランスポート サーバーの役割は、Server2 のハブ トランスポート サーバーの役割が利用不可能であることを検出すると、シャドウ メッセージを再送信します。DB2 が Server1 にマウントされた後、メッセージはローカルに配信されます。

  • メッセージが配信のために Server1 に再ルーティングされた後に Server1 に障害が発生すると、Server2 のハブ トランスポート サーバーの役割は、Server1 のハブ トランスポート サーバーの役割が利用不可能であることを検出した場合、シャドウ メッセージを再送信します。その後、メッセージをローカルに配信します。

  • メッセージが配信のために Server1 に再ルーティングされた後に Server2 に障害が発生すると、DB2 は Server1 でアクティブになります。メッセージは、DB2 が Server1 上にマウントされローカルに配信されるまで、キューに入ったままになります。

  • メッセージ配信が完了した後に Server2 に障害が発生すると、DB2 は Server1 でアクティブになります。配信されたメッセージがデータベースにコミットされていない場合は、このメッセージは Server1 のトランスポート収集から再度配信されます。

外部

DB1、Server1 でアクティブになる

  1. Server1 のハブ トランスポート サーバーの役割は、Server2 のハブ トランスポート サーバーの役割にメッセージを再ルーティングします。

  2. Server2 のハブ トランスポート サーバーの役割は、Server1 の DB1 にメッセージを配信し、そのメッセージを Server2 のトランスポート収集に追加します。

  • Server1 が Edge1 からのメッセージの受信を完了する前に Server1 に障害が発生すると、Edge1 は Server2 のハブ トランスポート サーバーの役割への配信を試みます。

  • Server1 が Edge1 からのメッセージの受信を完了した後に Server1 に障害が発生すると、Edge1 は、Server1 のハブ トランスポート サーバーの役割が利用不可能であることを検出した場合、Server2 のハブ トランスポート サーバーの役割にメッセージを再送信します。Server2 のハブ トランスポート サーバーの役割は、DB1 が Server2 にマウントされた後にメッセージをローカルに配信します。

  • その他すべての障害発生のシナリオは、最初の行の説明と同じ方法で処理されます。

外部

DB2、Server2 でアクティブになる

  1. Server1 のハブ トランスポート サーバーの役割は、Server2 の DB2 にメッセージを配信し、そのメッセージを Server1 のトランスポート収集に追加します。

  • Server1 が Edge1 からのメッセージの受信を完了する前に Server1 に障害が発生すると、Edge1 は Server2 のハブ トランスポート サーバーの役割への配信を試みます。

  • Server1 が Edge1 からのメッセージの受信を完了し、受信したメッセージを Server2 の DB2 に配信する前に、Server1 に障害が発生すると、Edge1 は Server2 のハブ トランスポート サーバーの役割にシャドウ メッセージを再送信します。これは、Server1 が DB2 にメッセージの配信を正常に完了するまで、Edge1 に受信確認を送信しないためです。Edge1 は受信確認を受け取らなかったため、Server1 が利用不可能であることを検出した後にメッセージを再送します。

  • メッセージ配信が完了した後に Server2 に障害が発生すると、DB2 は Server1 でアクティブになります。配信されたメッセージがデータベースにコミットされていない場合は、このメッセージは Server1 のトランスポート収集から再度配信されます。

前の表では、サイト内にハブ トランスポート サーバーが 2 台のみで、どちらのサーバーも DAG に参加するメールボックス サーバーの役割を持つ最小限のシナリオについて説明しています。利用可能な専用のハブ トランスポート サーバーをさらに備えているより複雑な展開では、これらのサーバーのルーティングを決定する際にも使用します。ただし、専用のハブ トランスポート サーバーが使用できる規模的に十分な展開である場合、DAG に参加するメール ボックス サーバー上にハブ トランスポート サーバーの役割をインストールしないことをお勧めします。

 © 2010 Microsoft Corporation.All rights reserved.