次の方法で共有

トランスポート内の SMTP フェールオーバーと負荷分散について

  • [アーティクル]

 

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

トピックの最終更新日: 2016-11-28

組織内に複数のハブ トランスポート サーバーがある場合、Exchange によって、メイン トラフィックが自動的に組織内のすべてのハブ トランスポート サーバー間で分散されます。すべてのサーバーが使用可能な場合、負荷分散は正常に行われて、負荷は均等に分散されます。ただし、1 台以上のサーバーが使用不可能な場合、特に組織が複数の Active Directory サイトにわたって分散されている場合には、残りのサーバー間で負荷分散が均等に行われないことがあります。

Microsoft Exchange Server 2010 Service Pack 1 (SP1) では、ハブ トランスポート サーバー間での負荷分散の意思決定メカニズムに関していくつかの点が改善されました。

メッセージのルーティングに関連する管理タスクについては、「メッセージ ルーティングの管理」を参照してください。

目次

Exchange Server 2010 RTM の動作

Exchange 2010 SP1 の改善点

Windows ネットワーク負荷分散またはトランスポート サーバーによるサードパーティ製の負荷分散ソリューション

Exchange Server 2010 RTM の動作

RTM (Release To Manufacturing) 版の Exchange 2010 では、トランスポート サーバーが複数のメッセージを同じ宛先にルーティングする場合、最初にこれらのメッセージの次ホップを決定します。その次ホップに複数のターゲット サーバーがある場合、拡張ドメイン ネーム システム (DNS) によるラウンド ロビンを使用して、メッセージをターゲット サーバー間で均等に配信するために使用される接続を負荷分散します。たとえば、次の図に示すように、それぞれに 3 台のハブ トランスポート サーバーがある 2 つの Active Directory サイトを持つトポロジがあるとします。サイト A のハブ トランスポート サーバー (たとえば、Hub02) がメッセージをサイト B に送信する必要がある場合、そのメッセージの次ホップはサイト B になります。この場合、次ホップとしては 3 つのターゲットが考えられます:Hub04、Hub05、および Hub06。サーバーは、次の図に示すように、3 つのターゲット間で接続数を均等に分散します。この結果、一定期間の接続にわたってメッセージが均等に配布されます。

Exchange Server 2010 RTM での負荷分散

同様に、サイト B のハブ トランスポート サーバーは、サイト A 内の受信者に送信されるメッセージ数を Hub01、Hub02、および Hub03 間で均等に分散します。また、Edge01 はサイト A を購読しているため、インターネットに送信されるメッセージの次ホップのターゲットは Hub01、Hub02、および Hub03 となります。

次ホップで 1 台以上のサーバーが使用不可能な場合には問題が発生します。たとえば、サイト B の Hub04 が予定された保守のために使用不可能であるとします。サイト A のサーバーは、サイト B 内の各サーバーの稼動状態を維持管理しません。サイト A のサーバーは、サイト B 宛ての負荷をそのサイト内の 3 台のハブ トランスポート サーバー間で分散します。これらの接続のほぼ 3 分の 1 が Hub04 に送信されますが、成功しません。これらの接続は次に使用可能なサーバーにフェールオーバーされ、次の図に示すように、サイト B 内のハブ トランスポート サーバーの 1 台が他のサーバーよりはるかに多くの負荷を処理することになります。

不均等な負荷分散

このような望ましくない動作は、一般的に 3 つ以上のターゲットを持つ次ホップで使用不可能なサーバーがある場合に発生する可能性があります。次ホップとしては、前の例で示したような別の Active Directory サイトであったり、送信元サーバーとして指定されている複数のハブ トランスポート サーバーを持つコネクタ (たとえば、前の図で示したトポロジ内の購読済みのエッジ トランスポート サーバーに対する送信コネクタ) であったりします。

これは、メールボックス サーバーからのメール発信については問題になりません。メール発信サービスは、サイト内の使用不可能なハブ トランスポート サーバーを検出して、これらのサーバーへの配信を試みません。前に示した例では、サイト B 内のハブ トランスポート サーバーの 1 つがサイト間トラフィックにより負荷が大きくなりますが、サイト B 内のメールボックス サーバーによって生成される負荷は Hub05 と Hub06 間で均等に分散されます。

Exchange Server 2010 RTM の動作

Exchange 2010 SP1 の改善点

前のセクションで説明した問題に対処するために、Healthy Server Selector と呼ばれる新しいコンポーネントが Exchange 2010 SP1 に追加されました。Healthy Server Selector は、使用不可能なサーバーの一覧を維持管理します。この一覧は拡張 DNS によって使用され、負荷分散用にラウンド ロビン ロジックを適用する際に使用不可能なサーバーをフィルターで除外します。Healthy Server Selector がどのように負荷分散に役立つかを示すため、前の図で示した問題のある状態を考えてみましょう。Exchange 2010 SP1 では、拡張 DNS は、最初に次ホップのサイト B で考えられるターゲットの一覧をコンパイルします。次に、Healthy Server Selector に対して一覧をフィルター処理するように依頼します。Healthy Server Selector は、次ホップのサイト B で Hub04 が異常と報告します。拡張 DNS は、次ホップのサイト B で考えられるターゲットの一覧から Hub04 を削除し、次の図に示すように、Hub05 と Hub06 の間にのみラウンド ロビン負荷分散を使用します。

Healthy Server Selector による負荷分散

Healthy Server Selector

Healthy Server Selector は、最も単純な形式では、異常と見なされるサーバーを追跡して、それらのサーバーがラウンド ロビン負荷分散に組み込まれないようにします。異常なサーバーの定義とは、Healthy Server Selector の観点からは、接続試行によって何らかの Windows ソケット (Winsock) エラー コードが返されるサーバーのことです。

異常な各サーバーについて、Healthy Server Selector では次の情報を保持します。

  • サーバー IP アドレス

  • 再試行回数

  • 最終再試行時刻

再試行動作

サーバーに不正常というマークが付けられている場合、Healthy Server Selector では、その特定サーバーがオンラインになった時点を検出できるように、サーバーに対する接続を再試行します。Healthy Server Selector では、次の設定を使用して異常なサーバーに対する接続試行頻度を決定します。

  • QueueGlitchRetryInterval および QueueGlitchRetryCount   これらの設定は、特定のサーバーに初めて異常のマークが付けられたときに、Healthy Server Selector がそのサーバーに対して接続を再試行する回数と間隔を決定します。これらの設定は、EdgeTransport.exe.config ファイルで構成されます。これらの設定の既定値は、1 分および 4 再試行回数です。これらの値は、既定の構成で異常なサーバーに対する接続が毎分、4 回試行されることを意味します。

  • TransientFailureRetryInterval および TransientFailureRetryCount   異常なサーバーが使用不可能な場合、Healthy Server Selector では、これらの設定を使用して再試行回数の次のセットの頻度を決定します。これらの設定はトランスポート サーバーごとに構成されます。既定値は、5 分 (エッジ トランスポート サーバーでは 10 分) および 6 再試行回数です。これらの値は、既定の構成で最初の 4 分が経過した後、異常なサーバーに対する接続が 5 分ごとに 6 回試行されることを意味します。

  • OutboundConnectionFailureRetryInterval   異常なサーバーが使用不可能な場合、Healthy Server Selector では、このパラメーターに指定された頻度で接続の再試行を継続します。この設定はトランスポート サーバーごとに構成されます。既定値は 10 分 (エッジ トランスポート サーバーでは 30 分) です。これは、既定の構成で最初の 34 分が経過した後、異常なサーバーに対する接続が 10 分ごとに試行されることを意味します。

これらの設定を構成する詳しい手順については、「メッセージの再試行、再送信、および有効期限の間隔を構成する」を参照してください。

接続を再試行する時点になると、Healthy Server Selector では、異常なサーバーに対する接続試行を 1 回のみ許可します。その接続が成功すると、SMTP 送信コンポーネントは Healthy Server Selector にその接続が成功したことを通知します。この時点で、Healthy Server Selector は異常なサーバーの一覧からそのサーバーを削除します。

Healthy Server Selector とシャドウ冗長

トランスポートのシャドウ冗長コンポーネントには、ハートビート機能が含まれています。ハートビートとは、以前ターゲット サーバーに送信されたメッセージの状態についてクエリを実行するために使用される簡単な SMTP 接続です。Healthy Server Selector のフィルター機能は、シャドウ冗長マネージャーによるハートビート接続試行の発行を防止しません。サーバーに異常なサーバーに送信されたシャドウ メッセージがある場合、サーバーはその異常なサーバーに対してハートビート接続を試行しようとします。異常なサーバーに対するハートビート接続が成功すると、そのターゲット サーバーは Healthy Server Selector によって異常なサーバーの一覧から直ちに削除されます。

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

診断情報

Exchange 2010 SP1 では、接続ログに Healthy Server Selector および拡張負荷分散機能の診断情報が含まれています。Healthy Server Selector によってサーバーが異常なサーバーの一覧に追加されると、そのイベントは接続ログに記録されます。このイベントを見つけるには、接続ログで MarkedUnhealthy という語句を検索します。この語句を含む行で、次の情報を検索できます。

  • ターゲット ホストの IP アドレス

  • ターゲット ホストの完全修飾ドメイン名 (FQDN)

  • 受信した Winsock エラー

  • 状態:MarkedUnhealthy

  • 現在の失敗回数

  • 次の再試行時刻

このエントリから、Winsock エラー コードを評価して失敗の理由を識別できます。Winsock エラー コードとその定義のすべての一覧については、「Windows ソケット エラー コード」を参照してください (このサイトは英語の場合があります)。

Current Failure Count フィールドと Next Retry Time フィールドを評価すると、失敗した接続試行の回数および次に予定されている再試行を特定することもできます。

この診断情報を表示するには、トランスポート サーバーで接続ログを有効にしておく必要があります。接続ログは、既定では、ハブ トランスポート サーバーおよびエッジ トランスポート サーバーで無効になっています。接続ログの構成の詳細については、「接続ログを構成する」を参照してください。

Exchange Server 2010 RTM の動作

Windows ネットワーク負荷分散またはトランスポート サーバーによるサードパーティ製の負荷分散ソリューション

このトピックで前述したように、Exchange 2010 は拡張 DNS を使用してエッジ トランスポート、ハブ トランスポート、およびメールボックス サーバー間のすべての組織間のメッセージ トラフィックを自動的に負荷分散します。ただし、この機能は外部のメール サーバー、サードパーティ製のスパム対策またはウイルス対策ソリューション、Exchange 組織の外部のすべての内部メール サーバー、基幹業務 (LOB) アプリケーション、および POP ベースまたは IMAP ベースの電子メール クライアントなどの、Exchange 以外の送信元から受信されたメッセージの負荷分散には対応していません。

これらのメールの送信元が 1 つ以上ある場合、組織内のトランスポート サーバーにまたがって外部の電子メール メッセージを配布する、統一された SMTP 名前空間 (smtp.contoso.com など) を使用した受信 SMTP トラフィックの負荷分散を選択できます。Windows ネットワーク負荷分散 (NLB) またはサードパーティの製造元によるハードウェアベースの負荷分散ソリューションの両方がサポートされています。製造元によってテスト済みで、かつ Microsoft によって Exchange 2010 の要件を満たしていると確認された負荷分散装置の一覧については、「マイクロソフトの統合コミュニケーションの負荷分散装置の展開」を参照してください。

重要

負荷分散ソリューションを使用して組織内の Exchange サーバー間のメッセージ トラフィックを処理することは、サポートされていません。環境内に展開したあらゆる負荷分散ソリューションから、Exchange サーバー間のメッセージ トラフィックを除外する必要があります。

エッジ トランスポート サーバー間の受信インターネット メッセージの負荷分散

最も一般的な状況は、インターネットからの受信メッセージを処理する場合です。エッジ トランスポート サーバーにわたって負荷を配布するために、負荷分散ソリューションを展開する必要はありません。DNS ラウンド ロビンおよび次の図で示すような同じ preference の値を持つメール交換レコード (MX レコード) を使用することにより、実現できます。

DNS ラウンド ロビンおよび MX レコードを使用したインターネット メッセージの負荷分散

受信インターネット メッセージを配布するのに Windows NLB またはハードウェアの負荷分散ソリューションを使用することを選択する場合、負荷分散ソリューションを指し示す単一の MX レコードを公開する必要があります。負荷分散装置は、次の図で示すように、受信メッセージをその構成にリストされているすべてのエッジ トランスポート サーバーに対して配布します。

負荷分散ソリューションを使用したインターネット メッセージの配布

ハブ トランスポート サーバー間における Exchange 以外のメッセージの負荷分散

Exchange 2010 では、受信メッセージを受け入れるために受信コネクタを使用します。既定では、Exchange 2010 ハブ トランスポート サーバーが TCP ポート 25 を介して SMTP 経由で電子メール メッセージを受信する場合、受信コネクタという既定の受信コネクタによって処理されます。

POP または IMAP クライアントが電子メール メッセージを Exchange 2010 ハブ トランスポート サーバーに送信すると、メッセージは既定で TCP ポート 587 を介して送信されます。これは、POP または IMAP クライアントから送信された電子メール メッセージは、クライアント受信コネクタという既定の別の受信コネクタによって処理されることを意味します。

負荷分散ソリューションをハブ トランスポート サーバーの前に配置することを計画している場合は、その目的のために別の受信コネクタを作成して、その特定のコネクタによって処理されるトラフィックだけが負荷分散の対象となることを確認する必要があります。これは、追加の IP アドレスをハブ トランスポート サーバーに追加し、新しい受信コネクタにこの IP アドレスを関連付けることで実現できます。また、[Exchange Server 認証] オプションは、Exchange トラフィックが受信コネクタを経由しないように無効にする必要があります。次の図では、POP3 または IMAP4 クライアントおよび 2 つのハブ トランスポート サーバー間において Exchange SMTP サーバー以外から受信したメッセージを、負荷分散装置を使用して配布する構成を示します。

ハブ トランスポート サーバー間における Exchange 以外のメッセージの負荷分散

Windows ネットワーク負荷分散

Windows NLB は、Exchange サーバーで使用される、最も一般的なソフトウェア負荷分散機能です。Exchange 2010 ハブ トランスポート サーバーで Windows NLB を展開することに関連していくつかの制限が存在します。

  • Windows NLB は、ハブ トランスポートおよびメールボックス サーバーの役割が共存していて、かつサーバーがデータベース可用性グループ (DAG) にも参加している場合は Exchange サーバーで使用できません。

    これは、Windows NLB の機能が Windows フェールオーバー クラスターと互換性が無いことによるものです。Exchange 2010 DAG を現在使用していて Windows NLB を使用する場合は、ハブ トランスポート サーバー役割とメールボックス サーバー役割を別のコンピューター上で実行する必要があります。また、Windows NLB は、DAG メンバーとハブ トランスポート サーバー役割が同じサーバー上に共存している場合、メッセージ ルーティングに対して影響を与えます。詳細については、「DAG を使用する場合の、ハブ トランスポートとメールボックス サーバーの役割の共存」を参照してください。

  • Windows NLB によって負荷分散されたアレイに 8 台を超えるハブ トランスポート サーバーを追加することはお勧めしません。8 台を超えるハブ トランスポート サーバーを負荷分散する必要がある場合は、ハードウェアベースのソリューションを展開する必要があります。

  • Windows NLB はサービスの停止を検出しません。

    IP アドレスでサーバーの停止を検出するだけです。Exchange トランスポート サーバーが停止したが、サーバーは依然として機能している場合、Windows NLB は停止を検出しないため、受信電子メール メッセージを引き続きそのハブ トランスポートサーバーにルーティングします。障害が発生しているハブ トランスポート サーバーは、手動で介入して負荷分散プールから取り除く必要があります。

  • Windows NLB 構成によってはポート フラッディングが発生し、ネットワークに大きな負担を与えます。

    これは、Windows NLB が、すべての受信クライアント パケットをすべてのスイッチ ポートに同時に配信するよう設計されているためです。この動作により、Windows NLB は非常に高いスループットで配信できるようになりますが、スイッチの高占有を引き起こす場合があります。

Windows を構成する手順の詳細については、「ハブ トランスポート サーバーの Windows ネットワーク負荷分散の構成」を参照してください。

ハードウェア負荷分散

Exchange 以外のメッセージ トラフィックを負荷分散するために 8 台を超えるハブ トランスポート サーバーがある場合、より拡張性を備えた負荷分散ソリューションが必要です。ソフトウェアによる負荷分散ソリューションも利用可能ですが、ハードウェアによる負荷分散ソリューションは最大の能力を提供します。

IP アドレスによってのみサーバーの停止を検出する Windows NLB とは異なり、ハードウェアの負荷分散装置は Exchange トランスポート サーバーの停止を検出するよう構成可能で、受信電子メール メッセージを手動による介入なしに他のハブ トランスポート サーバーにルーティングできます。

ハードウェア負荷分散ソリューションを構成するための詳細な手順については、「ハブ トランスポート サーバーのハードウェア負荷分散の構成」を参照してください。

 © 2010 Microsoft Corporation.All rights reserved.