Exchange Serverでの負荷分散

Exchange 2016 以降の負荷分散は、Exchange 2013 で提供される Microsoft の高可用性とネットワークの回復性プラットフォームに基づいて構築されています。 これがサードパーティの負荷分散ソリューション (ハードウェアとソフトウェアの両方) の可用性と組み合わされている場合、Exchange 組織で負荷分散を実装するための複数のオプションがあります。

Exchange アーキテクチャは Exchange 2013 で変更されており、それによってメールボックス サーバーとクライアント アクセス サーバーの役割が導入されました。 クライアント アクセス、メールボックス、ハブ トランスポート、統合メッセージが別のサーバーで実行される Exchange 2010 と比較してみます。

最小限のサーバーロールを使用すると、Exchange 2016 および 2019 は次の役割を提供します。

• クライアント アクセス サービスおよびエッジ トランスポート サーバーの役割を実行するメールボックス サーバーによる展開の簡略化。

• トランスポート パイプラインで管理されるメール フロー。これは、メールボックス サーバー上のトランスポート サービス カテゴライザーにメッセージをルーティングするサービス、接続、キュー、およびコンポーネントのコレクションです。

• クライアント トラフィックを分散させるロード バランサーの展開による高可用性。

Exchange 2013 で導入された HTTP プロトコル標準は、Exchange 2016 と Exchange 2019 でセッション アフィニティが不要になっていることを意味します。 セッション アフィニティを使用すると、メッセージングが有効なサービスの永続的な接続が可能になるため、ユーザーがユーザー名とパスワードを複数回再入力する必要はありません。

以前は Exchange 2007 と Exchange 2010 で RPC over HTTP for Outlook Anywhere がサポートされていました。 Exchange 2013 では MAPI over HTTP が導入されましたが、既定では有効になっていませんでした。 Exchange 2016 と Exchange 2019 で既定で有効になりました。

HTTP プロトコルが使用されている場合、すべてのネイティブ クライアントは、Exchange Serverの HTTP と HTTP を使用して接続します。 これまで負荷分散が別のサーバーへの接続にリダイレクトされるたびに求められるユーザー資格情報の入力を回避するためにアフィニティが必要とされていましたが、この標準プロトコルでは、これが不要になりました。

Exchange Serverのサーバー ロール

Exchange 2016 および Exchange 2019 のサーバーロールの数が減るため、Exchange の実装とハードウェアの要件が簡素化されます。 Exchange 2016 および 2019 のサーバーロールの数は、メールボックス サーバーとエッジ トランスポート サーバーの 7 から 2 に縮小されます。 メールボックス サーバーの役割にはクライアント アクセス サービスが含まれますが、エッジ トランスポート サーバーは、以前のバージョンの Exchange と同様に、Exchange 2016 および Exchange 2019 でセキュリティで保護されたメール フローを提供します。

Exchange 2013 のクライアント アクセス サーバーの役割では、ユーザーがメールボックスにアクセスしようとすると、そのメールボックスにアクティブにサービスを提供しているメールボックス サーバーに対して、サーバーからその要求がプロキシ化されて戻されます。 つまり、Web 上の Outlook (旧称 Outlook Web App) などのサービスがメールボックス自体でユーザーに対して表示され、アフィニティの必要性が排除されます。

Exchange 2016 と Exchange 2019 にも同じ機能が残っています。 2 つのメールボックス サーバーが異なるメールボックスをホストしている場合、必要に応じて相互のトラフィックをプロキシ化できます。 メールボックスのアクティブなコピーをホストするメールボックス サーバーでは、そこにアクセスするユーザーが別のメールボックス サーバーに接続していてもサービスを提供します。

Exchange Serverでのサーバー ロールの変更の詳細については、Exchange Server アーキテクチャに関する記事を参照してください。

必要ありませんが、エッジ トランスポート サーバーは、以前のバージョンの Exchange と同様に境界ネットワークに配置され、Exchange 組織に安全な受信および送信メール フローを提供します。

トランスポート サービスの詳細については、「 エッジ トランスポート サーバー上のトランスポート サービスについて」を参照してください。

Exchange Serverのプロトコル

Exchange 2016 以降では、すべてのネイティブ Exchange クライアントが HTTP プロトコルを使用して指定されたサービスに接続します。ログイン時にユーザーに提供される HTTP Cookie は、クライアント アクセス サービスの SSL 証明書を使用して暗号化されます。 ログインしたユーザーは、クライアント アクセス サービスで実行している別のメールボックス サーバー上のセッションを再認証することなく再開することができます。 複数のサーバーで同じ SSL 証明書を使用すると、クライアント認証 Cookie を暗号化解除できます。

HTTP により、Exchange ネットワーク内でサービスまたはアプリケーションの正常性チェックを使用することが可能になります。 ロード バランサー ソリューションによっては、正常性プローブを実装して、システムの複数のコンポーネントをチェックできます。

クライアントに対する HTTP のみのアクセスの効果は、負荷分散も簡単です。 必要な場合は、DNS を使用して Exchange トラフィックの負荷分散を行うことができます。 すべてのメールボックス サーバーの IP アドレスをクライアントに提供し、HTTP クライアントが雑用を処理します。 Exchange サーバーが失敗した場合、プロトコルは別のサーバーへの接続を試みます。 ただし、次のセクション「Exchange Serverの負荷分散オプション」で説明する、DNS への負荷分散には欠点があります。

HTTP とExchange Serverの詳細については、Exchange Serverの MAPI over HTTP に関する記事を参照してください。

Exchange Serverの負荷分散オプション

ここに示す例では、データベース可用性グループ (DAG) で構成されている複数のサーバーが、クライアント アクセス サービスを実行しているメールボックス サーバーをホストしています。 これにより、小さい Exchange サーバーの設置面積での高可用性を実現できます。 クライアントは直接 Exchange サーバーに接続するのではなく、ロード バランサーに接続します。 ロード バランサーペアの要件はありませんが、ネットワークの回復性を向上させるためにクラスターにデプロイすることをお勧めします。

DAG では Microsoft クラスター サービスを使用することに注意してください。 これらのサービスは、Windows ネットワーク負荷分散 (NLB) と同じサーバーでは有効にできません。 したがって、Windows NLB は DAG を使用する場合のオプションにはなりません。 この場合、サードパーティ製のソフトウェアと仮想アプライアンス ソリューションを使用します。

DNS を使用することは、Exchange トラフィックを負荷分散するための最も簡単なオプションです。 DNS 負荷分散では、すべてのメールボックス サーバーの IP アドレスをクライアントに指定するだけで済みます。 その後、DNS ラウンド ロビンによって、トラフィックがメールボックス サーバーに分散されます。 HTTP クライアントは、ある Exchange サーバーが完全に失敗した場合に、別のサーバーに接続できます。

ただし、この場合、DNS ラウンド ロビンは、プログラムを使用して各サーバーがトラフィックの公平な共有を取得する方法がないため、トラフィックを本当に負荷分散するわけではありません。 また、サービス レベルの監視がないため、1 つのサービスが失敗しても、クライアントは使用可能なサービスに自動的にリダイレクトされません。 たとえば、Web 上の Outlook が障害モードになると、クライアントにはエラー ページが表示されます。

DNS 負荷分散では、外部に公開する場合は外部 IP アドレスを追加する必要があります。 つまり、組織内のそれぞれの Exchange サーバーに外部 IP アドレスが必要です。

トラフィックを負荷分散させるには、さらに優れたソリューションもあり、トランスポート レイヤー 4 またはアプリケーション レイヤー 7 を使用するハードウェアなど、クライアント トラフィックを分散させます。 ロード バランサーは、各 Exchange クライアント向けサービスを監視し、サービスエラーが発生した場合、ロード バランサーはトラフィックを別のサーバーに転送し、問題のあるサーバーをオフラインにすることができます。 また、ある負荷分散のレベルでは、1 つのメールボックス サーバーがクライアント アクセスの大部分のプロキシになっていないことを確認します。

負荷分散サービスでは、レイヤー 4、レイヤー 7、またはこの組み合わせを使用してトラフィックを管理できます。 各ソリューションには、それぞれ利点と欠点があります。

• レイヤー 4 のロード バランサーはトランスポート レイヤーで機能し、コンテンツを検査せずにトラフィックを送信します。

  トラフィックのコンテンツが検査されないため、レイヤー 4 のロード バランサーでの移送は短時間で済みます。 ただし、これには代償が伴います。 レイヤー 4 のロード バランサーでは、IP アドレス、プロトコル、および TCP ポートのみ認識されます。 単一の IP アドレスのみを認識するため、ロード バランサーが監視できるサービスは 1 つだけです。

  レイヤー 4 の負荷分散の利点は次のとおりです。

  • 必要とされるリソースが少ない (コンテンツの検査がない)。

  • トランスポート レイヤーでトラフィックを分散する。

    レイヤー 4 ソリューションには、サービスが失敗してもサーバーが利用可能なままの場合、クライアントが失敗したサービスに接続することがあるという危険性もあります。 つまり、復元性の高いレイヤー 4 の実装では、サービスごとに別個の HTTP 名前空間に、サービス レベルの監視が可能な owa.contoso.com、eas.contoso.com、mapi.contoso.com など複数の IP アドレスを構成する必要があります。

• レイヤー 7 のロード バランサーはアプリケーション レイヤーで機能し、トラフィックのコンテンツを検査し、適宜送信できます。

  レイヤー 7 のロード バランサーでは、mail.contoso.com など単一の名前空間による簡易さ、およびサービスごとの監視について、レイヤー 4 の負荷分散の生のパフォーマンスの利点を上回っています。 レイヤー 7 ロード バランサーでは、/owa or /Microsoft-Server-ActiveSync, or /mapi, などの HTTP パスを解釈し、監視データに基づいて稼働中のサーバーにトラフィックを送信できます。

  レイヤー 7 の負荷分散の利点は次のとおりです。

  • 単一の IP アドレスのみが必要です。

  • コンテンツを検査し、トラフィックを送信できます。

  • 失敗したサービスをオフラインにできることを通知します。

  • ロード バランサーの SSL 終了を処理します。

  • アプリケーション レイヤーでトラフィックを分散し、リンク先の URL を認識します。

ロード バランサーで SSL 攻撃を修正できる一元的な場所が提供されるため、SSL はロード バランサーで終了します。

負荷分散が必要なポートには、Exchange 組織で使用されない IMAP4 または POP3 などのポートも含まれます。

Exchange Serverでの負荷分散のデプロイ シナリオ

Exchange 2016 では、名前空間と負荷分散アーキテクチャに大幅な柔軟性が導入されました。 Exchange 組織に負荷分散を展開するさまざまなオプションを使用して、単純な DNS から高度なサード パーティ製レイヤー 4 およびレイヤー 7 ソリューションまで、組織内のニーズを考慮して確認することをお勧めします。

次のシナリオでは、利点と制限事項について説明します。また、それぞれを理解することが、Exchange 組織に最適なソリューションを実装する鍵になります。

• シナリオ A 単一の名前空間、セッション アフィニティなし:レイヤー 4 またはレイヤー 7

• シナリオ B 単一の名前空間、セッション アフィニティなし:レイヤー 7

• シナリオ C 単一の名前空間、セッション アフィニティあり、レイヤー 7

• シナリオ D 複数の名前空間、セッション アフィニティなし、レイヤー 4

シナリオ A 単一の名前空間、セッション アフィニティなし:レイヤー 4 またはレイヤー 7

このレイヤー 4 のシナリオでは、単一の名前空間 mail.contoso.com が HTTP プロトコル クライアントに展開されています。 ロード バランサーはセッション アフィニティを保持していません。 これはレイヤー 4 ソリューションであるため、OUTLOOK ON THE WEB要求と RPC 要求を区別できないため、ロード バランサーは 1 つの仮想ディレクトリのみの正常性を確認するように構成されています。

この例のロード バランサーの観点から見ると、正常性はサーバーごとであり、指定された名前空間のプロトコルごとではありません。 管理者は、正常性プローブの対象にする仮想ディレクトリを選択する必要があります。頻繁に使用される仮想ディレクトリを選択することをお勧めします。 たとえば、ユーザーの大半がOutlook on the webを使用している場合は、正常性プローブでOutlook on the web仮想ディレクトリを選択します。

Outlook on the web正常性プローブの応答が正常である限り、ロード バランサーは宛先メールボックス サーバーを負荷分散プールに保持します。 ただし、何らかの理由でOutlook on the web正常性プローブが失敗した場合、ロード バランサーは、その名前空間に関連付けられているすべての要求の負荷分散プールから宛先メールボックス サーバーを削除します。 つまり、正常性プローブが失敗した場合、その名前空間に対するすべてのクライアント要求は、プロトコルに関係なく別のサーバーに送信されます。

シナリオ B 単一の名前空間、セッション アフィニティなし:レイヤー 7

このレイヤー 7 のシナリオでは、単一の名前空間 mail.contoso.com がすべての HTTP プロトコル クライアントに展開されます。 ロード バランサーはセッション アフィニティを保持していません。 ロード バランサーはレイヤー 7 用に構成されているため、SSL 終了があり、ロード バランサーは宛先 URL を認識します。

Exchange 2016 および Exchange 2019 では、この構成をお勧めします。 負荷分散プール内の宛先メールボックス サーバーの正常性を確認するようにロード バランサーが構成され、各仮想ディレクトリに正常性プローブが構成されます。

たとえば、Outlook on the web正常性プローブの応答が正常である限り、ロード バランサーは宛先メールボックス サーバーをOutlook on the web負荷分散プールに保持します。 ただし、何らかの理由でOutlook on the web正常性プローブが失敗した場合、ロード バランサーは、Outlook on the web要求の負荷分散プールからターゲット メールボックス サーバーを削除します。 この例では、正常性はプロトコルごとであり、正常性プローブが失敗した場合に影響を受けるクライアント プロトコルだけが別のサーバーに送信されます。

シナリオ C 単一の名前空間、セッション アフィニティあり、レイヤー 7

このレイヤー 7 のシナリオでは、単一の名前空間 mail.contoso.com がすべての HTTP プロトコル クライアントに展開されます。 ロード バランサーはレイヤー 7 用に構成されているため、SSL 終了があり、ロード バランサーはリンク先 UL を認識しています。 ロード バランサーは、負荷分散プール内のターゲット メールボックス サーバーの正常性を確認するようにも構成されます。 正常性プローブは、各仮想ディレクトリで構成されています。

ただし、セッション アフィニティを有効にすると、容量と使用率が低下します。 これは、より複雑なアフィニティ オプション、Cookie ベースの負荷分散、または Secure Sockets Layer (SSL) セッション ID が必要になるためです。これには、より多くの処理とリソースが必要です。 セッション アフィニティが負荷分散のスケーラビリティにどのように影響するかについては、ベンダーに確認することをお勧めします。

前のシナリオと同様に、Outlook on the web正常性プローブの応答が正常である限り、ロード バランサーは宛先メールボックス サーバーをOutlook on the web負荷分散プールに保持します。 ただし、何らかの理由でOutlook on the web正常性プローブが失敗した場合、ロード バランサーは、Outlook on the web要求の負荷分散プールからターゲット メールボックス サーバーを削除します。 ここでは、正常性はプロトコルごとであり、正常性プローブが失敗した場合に影響を受けるクライアント プロトコルだけが別のサーバーに送信されます。

シナリオ D 複数の名前空間、セッション アフィニティなし

この最後のシナリオでは、名前空間は複数あり、セッション アフィニティはなく、プロトコルごとの正常性チェックとレイヤー 4 の機能を提供しています。 HTTP プロトコル クライアントごとに一意の名前空間が展開されます。 たとえば、mail.contoso.com、mapi.contoso.com、eas.contoso.com という HTTP プロトコル クライアントを構成するとします。

このシナリオでは、プロトコルごとの正常性チェックを実行し、複雑な負荷分散ロジックは必要としません。 ロード バランサーはレイヤー 4 を使用し、セッション アフィニティを維持するように構成されていません。 ロード バランサーの構成では、負荷分散プール内の宛先メールボックス サーバーの正常性がチェックされます。 この設定では、それぞれの仮想ディレクトリに一意の名前空間があるため、正常性プローブは各仮想ディレクトリの正常性をターゲットとするよう構成されます。 これはレイヤー 4 用に構成されているため、ロード バランサーは URL へのアクセスがあるかどうかを識別しないまま、その結果には識別したものとして表示します。 正常性はプロトコルごとであるため、正常性プローブが失敗した場合、影響を受けるクライアント プロトコルだけが別のサーバーに送信されます。

Exchange Serverでの負荷分散とマネージド可用性

利用可能なサーバーとサービスの監視は、高可用性ネットワークの鍵となります。 一部の負荷分散ソリューションでは、ターゲット URL や要求の内容に関する知識がないため、Exchange 正常性プローブの複雑さが生じる可能性があります。

Exchange 2016 と Exchange 2019 には、マネージド可用性と呼ばれる組み込みの監視ソリューションが含まれています。 マネージド 可用性 (アクティブ監視またはローカル アクティブ監視とも呼ばれます) は、組み込みの監視と回復アクションと Exchange 高可用性プラットフォームの統合です。

可用性管理には、オフラインのレスポンダーが含まれています。 オフライン レスポンダーが呼び出されると、影響を受けるプロトコル (またはサーバー) がサービスから削除されます。

マネージド可用性がオフラインとしてマークされているメールボックス サーバーにトラフィックをロード バランサーがルーティングしないようにするには、仮想ディレクトリ>/healthcheck.htm (など<https://mail.contoso.com/owa/healthcheck.htm>) を確認<するようにロード バランサーの正常性プローブを構成する必要があります。

マネージド可用性の詳細については、「マネージド可用性」を 参照してください。