Exchange 2016 での負荷分散
(この記事は 2015 年 10 月 8 日に Exchange Team Blog に投稿された記事 Load Balancing in Exchange 2016 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)
Exchange 2013 と同様、Exchange 2016 でも負荷分散層でセッション アフィニティが不要です。
このことについてよくご理解いただき、お客様のシステム設計にどのような影響があるかを把握していただくために、MBX2016 が機能するしくみについてご説明します。プロトコルという視点から見ると、次のような処理が実行されます。
1. クライアントが、負荷分散対象の仮想 IP アドレスに対して名前空間の名前解決を実行します。
2. ロード バランサーが、負荷分散対象のプールに存在する MBX サーバーの 1 つにセッションを割り当てます。
3. MBX サーバー上に存在するクライアント アクセス サービスが Active Directory にアクセスしてこの要求の認証およびサービスの検出を実行します。これにより、次の情報が取得されます。
a. メールボックスのバージョン (今回の場合は Exchange Server 2016 のメールボックスを想定します)
b.メールボックスの位置情報 (データベースの情報や ExternalURL の値など)
4. MBX サーバー上のクライアント アクセス サービスが、要求を別の MBX インフラストラクチャ (同一フォレスト内) にプロキシ転送するか、リダイレクトするかを決定します。
5. MBX サーバー上のクライアント アクセス サービスが、アクティブ マネージャーのインスタンスにクエリを発行し、該当するデータベースのどのメールボックス サーバーでアクティブ コピーをホストするかを決定します。
6. MBX サーバー上のクライアント アクセス サービスが、アクティブ コピーをホストしているメールボックス サーバーに要求をプロキシ転送します。
手順 5 は、ロード バランサーでセッション アフィニティを不要にするために根本的に変更された点です。特定のプロトコル セッションにおいて、MBX サーバー上に存在するクライアント アクセス サービスは、ユーザーのデータをホストしているメールボックス サーバーと 1 対 1 の関係を維持するようになりました。データベースのアクティブ コピーが別のメールボックス サーバーに移動される場合、MBX は前のサーバーとのセッションを終了して、新しいサーバーとのセッションを確立します。つまり、発生元の場所 (負荷分散対象のアレイ内の MBX サーバーなど) にかかわらず、すべてのセッションは同じ場所 (データベースのアクティブ コピーをホストしているメールボックス サーバー) で終了します。これが、Exchange 2013 よりも前のバージョンと大きく異なる点です。たとえば Exchange 2010 では、特定のクライアントから発行された要求がすべて同じエンドポイントで終了するとは限らず、これがユーザー エクスペリエンスに悪影響を及ぼしていました。
手順 6 で使用されるプロトコルは、MBX への接続で使用されるプロトコルに依存します。クライアントが HTTP プロトコルを使用する場合は、メールボックス サーバー間でも HTTP プロトコルが使用されます (ただし、自己署名証明書を使用した SSL でセキュリティが確保されます)。クライアントが IMAP プロトコルまたは POP プロトコルを使用する場合は、メールボックス サーバー間でも IMAP プロトコルまたは POP プロトコルが使用されます。
ただし、テレフォニー要求は他の場合とは異なります。MBX は、手順 6 で要求をプロキシ転送するのではなく、ユーザーのデータベースのアクティブ コピーをホストしているメールボックス サーバーに要求をリダイレクトします。これは、テレフォニー デバイスではリダイレクトがサポートされていて、メールボックス サーバーのユニファイド メッセージング コンポーネントとの SIP セッションおよび RTP セッションを直接確立する必要があるためです。
図 1: Exchange 2016 のクライアント アクセス プロトコルのアーキテクチャ
ただし、このアーキテクチャ変更により発生する問題があります。ロード バランサーがセッション アフィニティを使用しないため、ロード バランサーはターゲット URL や要求の内容を把握できません。ロード バランサーが使用するのは、次の図に示すように、レイヤー 4 の情報である IP アドレスと、プロトコルとポートの組み合わせ (TCP 443) です。
図 2: レイヤー 4 での負荷分散処理
ロード バランサーでは、負荷分散対象のプールから対象のサーバーを選択する際に、ラウンドロビン (各受信接続が、輪番のリスト内の次の対象サーバーに割り当てられる) や最小接続 (そのときに確立されている接続数が最小のサーバーに、ロード バランサーが新たな接続を割り当てる) など、さまざまな方法を使用できます。
正常性プローブの確認
ターゲット URL (または要求の内容) を把握できないことにより、正常性プローブに関連する処理が複雑になっています。
Exchange 2016 には、管理可用性と呼ばれる監視ソリューションが組み込まれています。管理可用性の機能にはオフライン レスポンダーが搭載されていて、このオフライン レスポンダーが呼び出されると、影響を受けるプロトコル (またはサーバー) はサービスから除外されます。管理可用性機能によりオフラインとマークされたメールボックス サーバーに対して負荷分散機能がトラフィックをルーティングしないようにするには、負荷分散機能の正常性プローブが <仮想ディレクトリ名>/healthcheck.htm (例: https://mail.contoso.com/owa/healthcheck.htm) を確認するように構成されている必要があります。ここで、healthcheck.htm は仮想ディレクトリ内部に実際に存在しているわけではないという点に注意が必要です。このファイルは、実行されているプロトコルのコンポーネントの状態に基づいて、インメモリで生成されます。
ロード バランサーの正常性プローブがステータス コード 200 の応答を受け取る場合、そのプロトコルは動作中です。ロード バランサーがこれ以外のステータス コードを受け取った場合は、管理可用性機能によって、メールボックス サーバーの該当するプロトコルのインスタンスはダウンしているとしてマークされます。その結果、ロード バランサーはこのエンドポイントが停止していると判断し、該当するメールボックス サーバーを利用可能な負荷分散プールから除外します。
管理者は、メンテナンスの際に手動でプロトコルをオフラインに設定し、利用可能な負荷分散プールから除外することができます。たとえば、OWA のプロキシ プロトコルをメールボックス サーバーのローテーションから除外する場合、次のコマンドを実行します。
| Set-ServerComponentState <メールボックス サーバー名> -Component OwaProxy –Requestor Maintenance –State Inactive |
サーバー コンポーネントの状態についての詳細は、「Exchange 2013 のサーバー コンポーネントの状態 (英語)」の記事を参照してください。
ロード バランサーの正常性プローブが healthcheck.htm を監視していなかった場合どうなるか
ロード バランサーが正常性プローブで healthcheck.htm を使用していないと、ロード バランサーは、管理可用性機能がサーバーを利用可能な負荷分散プールから除外したこと (または再度追加したこと) を把握できません。このため、ロード バランサーと管理可用性機能との間で相違が発生します。このような状況では、管理可用性機能によって停止しているとマークされたメールボックス サーバーに対して、ロード バランサーが要求をリダイレクトする可能性があり、ユーザー エクスペリエンスへの悪影響や、機能停止につながるおそれがあります。以上の理由から、負荷分散機能の正常性プローブでは healthcheck.htm を使用することを推奨します。
名前空間とアフィニティのシナリオ
ここまでは、正常性チェックの実行方法について説明しました。ここからは、次の 4 つのシナリオについて説明します。
- 名前空間が 1 つ/レイヤー 4 (セッション アフィニティなし)
- 名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし)
- 名前空間が 1 つ/セッション アフィニティあり
- 名前空間が複数/セッション アフィニティなし
名前空間が 1 つ/レイヤー 4 (セッション アフィニティなし)
このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) に展開されています。ロード バランサーはレイヤー 4 で実行され、セッション アフィニティを保持していません。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のメールボックス サーバーの正常性を確認します。しかし、このシナリオではレイヤー 4 で処理が行われるため、ロード バランサーは 1 つの仮想ディレクトリのみの正常性を確認するように構成されます (OWA の要求と RPC の要求を判別できないため)。管理者は、正常性プローブが確認を行う仮想ディレクトリを指定する必要があり、通常は使用頻度が高い仮想ディレクトリを選択します。たとえば、ユーザーの大半が OWA を使用している場合は、OWA の仮想ディレクトリを正常性プローブの対象に設定します。
図 3: 名前空間が 1 つ/セッション アフィニティなしのシナリオ
OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する MBX を負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブが失敗する場合、ロード バランサーは、特定の名前空間に関連付けられたすべての要求について、対象の MBX を負荷分散プールから除外します。つまり、この例では、ロード バランサーから見た特定の名前空間の正常性が、プロトコルごとではなくサーバーごとに判断されます。このため、正常性プローブが失敗する場合、その名前空間のクライアントの要求は、プロトコルによらず、すべて他のサーバーにリダイレクトされる必要があります。
図 4: 名前空間が 1 つ/セッション アフィニティなしのシナリオ – 正常性プローブが失敗する場合
名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし)
このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) に展開されていて、ロード バランサーはレイヤー 7 を使用するように構成されています。この場合、SSL の終端処理が実行され、ロード バランサーはターゲット URL を把握しています。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のメールボックス サーバーの正常性を確認します。この MBX では、正常性プローブは各仮想ディレクトリに対して構成されています。
OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する MBX を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブが失敗する場合、ロード バランサーは、OWA の要求に対して対象の MBX を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに判断されます。このため、正常性プローブが失敗する場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。 
図 5: 名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし) のシナリオ – 正常性プローブが失敗する場合
Exchange 2016 では、セッション アフィニティなしでレイヤー 7 を使用する 1 つの名前空間が、名前空間およびロード バランサー構成として推奨されています。
名前空間が 1 つ/レイヤー 7 (セッション アフィニティあり)
このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) に展開されていて、ロード バランサーはレイヤー 7 を使用してセッション アフィニティを保持するように構成されています。この場合、SSL の終端処理が実行され、ロード バランサーはターゲット URL を把握しています。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のメールボックス サーバーの正常性を確認します。この MBX では、正常性プローブは各仮想ディレクトリに対して構成されています。
OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する MBX を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブが失敗する場合、ロード バランサーは、OWA の要求に対して対象の MBX を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに判断されます。このため、正常性プローブが失敗する場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。
図 6: 名前空間が 1 つ/レイヤー 7 (セッション アフィニティあり) のシナリオ – 正常性プローブが失敗する場合
| 注: セッション アフィニティを有効にすると、Cookie に基づく負荷分散処理や SSL (Secure Sockets Layer) のセッション ID などのアフィニティ オプションに関連する処理に演算能力が使用され、ロード バランサーの能力と使用率は低下します。負荷分散処理のスケーラビリティを決定する際には、セッション アフィニティによる影響についてお客様のベンダーに確認してください。 |
名前空間が複数/セッション アフィニティなし
このシナリオは、プロトコルごとの正常性確認が可能でありながら複雑な負荷分散ロジックが不要であるという、2 つの要素のメリットを両方とも得られる方法です。
このシナリオでは、次の図に示すように、HTTP プロトコルのクライアントごとに一意の名前空間が展開されます。
図 7: 名前空間が複数/セッション アフィニティなしのシナリオ
| 注: 上図で示すとおり、ECP にも独自の名前空間が提供されます。ECP と OWA は互いに緊密に関連付けられているので、ECP は独自の名前空間を必要としません。しかし、ECP は独自のアプリケーション プールを保持しており、構成によっては、Exchange 管理センターのエンドポイントとなることも、Outlook クライアントがこれを使用することもあります。このため、ECP で独自の名前空間を使用したほうがよい場合もあります。 |
ロード バランサーはレイヤー 4 を使用し、セッション アフィニティを保持しないように構成されています。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のメールボックス サーバーの正常性を確認します。このシナリオでは、正常性プローブは各仮想ディレクトリの正常性が得られるように構成されています。各仮想ディレクトリは一意の名前空間で定義されているので、ロード バランサーがアクセス元の URL を把握していなくても、それを把握している場合と同様の結果が得られます。
OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する MBX を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブが失敗する場合、ロード バランサーは、OWA の要求に対して対象の MBX を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに判断されます。このため、正常性プローブが失敗する場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。 
図 8: 名前空間が複数/セッション アフィニティなしのシナリオ – 正常性プローブが失敗する場合
この手法には、名前空間および VIP (名前空間ごとに 1 つ) が余分に必要になるというデメリットがあります。このため、証明書にサブジェクト代替名として追加する名前の数が増加し、証明書プロバイダーのコストが上昇するおそれがあります。しかし、エンド ユーザーにとっては複雑性が増すことはなく、ユーザーが把握しておく必要のある URL は OWA の URL だけです。ActiveSync、Outlook、および Exchange Web サービスのクライアントは、適切な URL を決定するために自動検出機能を使用します。
Exchange シナリオのまとめ
次の表は、それぞれの手法のメリットとデメリットをまとめたものです。
| メリット | デメリット | |
| 名前空間が 1 つ/レイヤー 4 (セッション アフィニティなし) |
|
|
| 推奨: 名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし) |
|
|
| 名前空間が 1 つ/レイヤー 7 (セッション アフィニティあり) |
|
|
| 名前空間が複数/セッション アフィニティなし |
|
|
Office Online サーバーの負荷分散
Exchange Server 2016 では、Office Online サーバーを使用して、OWA 向けにリッチ ドキュメントのプレビュー機能および編集機能を提供しています。これは Office Server スイート全体で同一のエクスペリエンスを実現するために必要な変更ですが、Office Online サーバーを使用しない環境では複雑性が増すというトレードオフが生じます。
アーキテクチャと名前空間の計画についての各記事でご説明したように、Office Online サーバーのインフラストラクチャには一意の名前空間が必要です。ロード バランサーは、Office Online サーバーの各名前空間に対してレイヤー 7 を使用し、セッション アフィニティを保持するように構成されています (Cookie ベースの永続性を使用)。この場合、SSL の終端処理が実行され、ロード バランサーはターゲット URL を把握しています。これによって、クライアントは常に同じ Office Online サーバーに接続され、ユーザーは OWA のドキュメント共同作業機能を使用できます。
まとめ
Exchange 2016 では、名前空間と負荷分散アーキテクチャの柔軟性が大幅に向上しました。負荷分散機能については、機能性と簡潔性のバランスを考慮して最終的に判断する必要があります。最も簡潔なソリューションでは、セッション アフィニティの管理とプロトコルごとの正常性チェックに対応できませんが、1 つの名前空間のみで展開することができます。一方、複雑なソリューションでは、セッション アフィニティを管理することも、1 つの名前空間でプロトコルごとに正常性をチェックすることもできますが、複雑性が高まりコストが増大します。また、機能性と簡潔性を両立させるために、セッション アフィニティがない負荷分散ソリューションを展開する方法もあります。このシナリオではプロトコルごとに正常性をチェックできる反面、各プロトコルに一意の名前空間が必要になるのでコストがかかります。
プリンシパル プログラム マネージャー
Office 365 カスタマー エクスペリエンス担当