Exchange 2013 での負荷分散


(この記事は 2014 年 3 月 5 日に The Exchange Team Blog に投稿された記事 Load Balancing in Exchange 2013 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

この記事は、名前空間の計画、負荷分散の原則、クライアントの接続性証明書の計画のそれぞれについて説明した連載の第 2 回です。

 

負荷分散

以前のバージョンの Exchange と異なり、Exchange 2013 では負荷分散層でセッション アフィニティが不要になりました。

このことについてよくご理解いただき、お客様のシステム設計にどのような影響があるかを把握していただくため、CAS2013 が機能するしくみについてご説明します。プロトコルという視点から見ると、次のような処理が実行されます。

1. クライアントが、負荷分散対象の仮想 IP アドレスに対して名前空間の名前解決を実行します。
2. ロード バランサーが、負荷分散対象のプールに存在する CAS メンバーの 1 つにセッションを割り当てます。
3. CAS が Active Directory にアクセスしてこの要求の認証およびサービスの検出を実行します。これにより、次の情報が取得されます。
     a.メールボックスのバージョン (今回の場合は Exchange 2013 のメールボックスを想定します)
     b.メールボックスの位置情報 (データベースの情報や ExternalURL の値など)
4. CAS が、要求を「プロキシ転送」するか、または同一フォレスト内の他の CAS インフラストラクチャに「リダイレクト」するかを決定します。
5. CAS がアクティブ マネージャーのインスタンスにクエリを発行し、該当するデータベースのどのメールボックス サーバーでアクティブ コピーをホストするかを決定します。
6. CAS が、アクティブ コピーをホストしているメールボックス サーバーに要求をプロキシ転送します。

手順 5 は、ロード バランサーでセッション アフィニティを不要にするために根本的に変更された点です。特定のプロトコル セッションにおいて、CAS は、ユーザーのデータをホストしているメールボックス サーバーと 1 対 1 の関係を維持するようになりました。データベースのアクティブ コピーが別のメールボックス サーバーに移動される場合、CAS は前のサーバーとのセッションを終了して、新しいサーバーとのセッションを確立します。つまり、発生元の場所 (負荷分散対象のアレイ内に存在している CAS メンバーなど) にかかわらず、すべてのセッションは同じ場所 (データベースのアクティブ コピーをホストしているメールボックス サーバー) で終了します。これが、以前のバージョンと大きく異なる点です。Exchange 2010 では、特定のクライアントから発行された要求がすべて同じエンドポイントで終了するとは限らず、これがユーザー エクスペリエンスに悪影響を及ぼしていました。

手順 6 で使用されるプロトコルは、CAS への接続で使用されるプロトコルに依存します。クライアントが HTTP プロトコルを使用する場合は、クライアント アクセス サーバーとメールボックス サーバーの間でも HTTP が使用されます (ただし、自己署名証明書を使用した SSL でセキュリティが確保されます)。クライアントが IMAP または POP を使用する場合は、クライアント アクセス サーバーとメールボックス サーバーの間でも IMAP または POP が使用されます。

ただし、テレフォニーの要求の場合は特殊で、CAS は、手順 6 で要求をプロキシ転送するのではなく、ユーザーのデータベースのアクティブ コピーをホストしているメールボックス サーバーに要求をリダイレクトします。これは、テレフォニー デバイスではリダイレクトがサポートされていて、メールボックス サーバーのユニファイド メッセージング コンポーネントとの SIP セッションおよび RTP セッションを直接確立する必要があるためです。

図 1: Exchange 2013 のクライアント アクセス プロトコルのアーキテクチャ

ただし、このアーキテクチャ変更により発生する問題があります。ロード バランサーがセッション アフィニティを使用しないため、ロード バランサーはターゲット URL や要求の内容を把握できません。ロード バランサーが使用するのは、次に示すように、レイヤー 4 の情報である IP アドレスと、プロトコルとポートの組み合わせ (TCP 443) です。

図 2: レイヤー 4 での負荷分散処理

ロード バランサーでは、負荷分散対象のプールから対象のサーバーを選択する際に、ラウンドロビン (各受信接続が、輪番のリスト内の次の対象サーバーに割り当てられる) や最小接続 (そのときに確立されている接続数が最小のサーバーに、ロード バランサーが新たな接続を割り当てる) など、さまざまな方法を使用できます。

正常性プローブの確認

ターゲット URL (または要求の内容) を把握できないことにより、正常性プローブに関連する処理が複雑になっています。

Exchange 2013 には、管理可用性とよばれる監視ソリューションが組み込まれています。管理可用性の機能にはオフライン レスポンダーが搭載されていて、このオフライン レスポンダーが呼び出されると、影響を受けるプロトコル (またはサーバー) はサービスから除外されます。管理可用性機能によりオフラインとマークされたクライアント アクセス サーバーに対して負荷分散機能がトラフィックをルーティングしないようにするには、負荷分散機能の正常性プローブが <仮想ディレクトリ名>/healthcheck.htm (例: https://mail.contoso.com/owa/healthcheck.htm) を確認するように構成されている必要があります。ここで、healthcheck.htm は仮想ディレクトリ内部に実際に存在しているわけではないという点に注意が必要です。このファイルは、実行されているプロトコルのコンポーネントの状態に基づいて、インメモリで生成されます。

ロード バランサーの正常性プローブがステータス コード 200 の応答を受け取る場合、そのプロトコルは動作中です。ロード バランサーがこれ以外のステータス コードを受け取った場合は、管理可用性機能が、クライアント アクセス サーバーの該当するプロトコルのインスタンスはダウンしているとしてマークします。その結果、ロード バランサーはこのエンドポイントが停止していると判断し、該当するクライアント アクセス サーバーを利用可能な負荷分散プールから除外します。

管理者は、メンテナンスの際に手動でプロトコルをオフラインに設定し、利用可能な負荷分散プールから除外することができます。たとえば、OWA のプロキシ プロトコルをクライアント アクセス サーバーのローテーションから除外する場合、次のコマンドを実行します。

Set-ServerComponentState <クライアント アクセス サーバー名> -Component OwaProxy –Requestor Maintenance –Status Inactive

サーバー コンポーネントの状態についての詳細は、「Exchange 2013 のサーバー コンポーネントの状態 (英語)」の記事を参照してください。

ロード バランサーの正常性プローブが healthcheck.htm を監視していなかった場合どうなるか

ロード バランサーが正常性プローブで healthcheck.htm を使用していないと、ロード バランサーは、管理可用性機能がサーバーを利用可能な負荷分散プールから除外したこと (または再度追加したこと) を把握できません。このため、ロード バランサーと管理可用性機能との間で相違が発生します。このような状況では、管理可用性機能によって停止しているとマークされたクライアント アクセス サーバーに対して、ロード バランサーが要求をリダイレクトする可能性があり、ユーザー エクスペリエンスへの悪影響や、機能停止につながるおそれがあります。以上の理由から、負荷分散機能の正常性プローブでは healthcheck.htm を使用することを推奨します。

名前空間とアフィニティのシナリオ

ここまでは、正常性チェックの実行方法について説明しました。ここからは、次の 3 つのシナリオについて説明します。

  1. 名前空間が 1 つ/セッション アフィニティなし
  2. 名前空間が 1 つ/セッション アフィニティあり
  3. 名前空間が複数/セッション アフィニティなし

名前空間が 1 つ/レイヤー 4 (セッション アフィニティなし)

このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) にデプロイされていて、ロード バランサーはレイヤー 4 を使用し、セッション アフィニティを保持しないように構成されていると想定します。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のクライアント アクセス サーバーの正常性を確認します。しかし、このシナリオではレイヤー 4 で処理が行われるため、この構成ではロード バランサーが正常性を確認する仮想ディレクトリは 1 つだけです (OWA の要求と RPC の要求を判別できないため)。管理者は、正常性プローブが確認を行う仮想ディレクトリを指定する必要があり、通常は使用頻度が高い仮想ディレクトリを選択します。たとえば、ユーザーの大半が OWA を使用している場合は、OWA の仮想ディレクトリを正常性プローブの対象に設定します。

3: 名前空間が 1 つ/セッション アフィニティなしのシナリオ

OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する CAS を負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブからの応答が異常な場合、ロード バランサーは、特定の名前空間に関連付けられた要求すべてについて、対象の CAS を負荷分散プールから除外します。つまり、この例では、ロード バランサーから見た特定の名前空間の正常性は、プロトコルごとではなくサーバーごとに決定されます。このため、正常性プローブの応答が異常な場合、クライアントの要求は、プロトコルによらず、すべて他のサーバーにリダイレクトされる必要があります

4: 名前空間が 1 つ/セッション アフィニティなしのシナリオ – 正常性プローブの応答が異常な場合

名前空間が 1 /レイヤー 7 (セッション アフィニティなし)

このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) にデプロイされていて、ロード バランサーはレイヤー 7 を使用するものと想定します。この場合、SSL の終端処理が実行され、ロード バランサーはターゲット URL を把握しています。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のクライアント アクセス サーバーの正常性を確認します。このシナリオでは、正常性プローブは各仮想ディレクトリに対して構成されています。

OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する CAS を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブの応答が異常な場合、ロード バランサーは、OWA の要求について対象の CAS を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに決定されます。このため、正常性プローブの応答が異常な場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。


5: 名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし) のシナリオ – 正常性プローブの応答が異常な場合

名前空間が 1 /セッション アフィニティあり

このシナリオでは、1 つの名前空間がすべての HTTP プロトコルのクライアント (mail.contoso.com) にデプロイされていて、ロード バランサーはレイヤー 7 を使用し、セッション アフィニティを保持するように構成されているものと想定します。この場合、SSL の終端処理が実行され、ロード バランサーはターゲット URL を把握しています。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のクライアント アクセス サーバーの正常性を確認します。このシナリオでは、正常性プローブは各仮想ディレクトリに対して構成されています。

OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する CAS を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブの応答が異常な場合、ロード バランサーは、OWA の要求について対象の CAS を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに決定されます。このため、正常性プローブの応答が異常な場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。


6: 名前空間が 1 つ/セッション アフィニティありのシナリオ - 正常性プローブの応答が異常な場合

: セッション アフィニティを有効にすると、Cookie に基づく負荷分散処理や SSL (Secure Sockets Layer) のセッション ID などのアフィニティ オプションに関連する処理に演算能力が使用され、ロード バランサーの能力と使用率は低下します。負荷分散処理のスケーラビリティを決定する際には、セッション アフィニティによる影響についてお客様のベンダーと確認してください。

名前空間が複数/セッション アフィニティなし

このシナリオは、プロトコルごとの正常性確認が可能でありながら複雑な負荷分散ロジックが不要であるという、2 つの要素のメリットを両方とも得られる方法です。

このシナリオでは、次の図に示すように、HTTP プロトコルのクライアントごとに一意の名前空間がデプロイされます。

図 7: 名前空間が複数/セッション アフィニティなしのシナリオ

: 上図で示すとおり、ECP にも独自の名前空間が提供されます。ECP と OWA は互いに緊密に関連付けられているので、ECP は独自の名前空間を必要としません。しかし、ECP は独自のアプリケーション プールを保持しており、構成によっては、Exchange 管理センターのエンドポイントとなることも、Outlook クライアントがこれを使用することもあります。このため、ECP で独自の名前空間を使用したほうがよい場合もあります。

ロード バランサーはレイヤー 4 を使用し、セッション アフィニティを保持しないように構成されていると想定します。また、構成に従って、ロード バランサーは負荷分散プール内に存在する対象のクライアント アクセス サーバーの正常性を確認します。このシナリオでは、正常性プローブは各仮想ディレクトリの正常性が得られるように構成されています。各仮想ディレクトリは一意の名前空間で定義されているので、ロード バランサーがアクセス元の URL を把握していなくても、それを把握している場合と同様の結果が得られます。

OWA の正常性プローブの応答が正常である限り、ロード バランサーは該当する CAS を OWA の負荷分散プール内に保持します。しかし、何らかの理由で OWA の正常性プローブの応答が異常な場合、ロード バランサーは、OWA の要求に対して対象の CAS を負荷分散プールから除外します。つまり、この例では、正常性はプロトコルごとに決定されます。このため、正常性プローブの応答が異常な場合、影響を受けるクライアント プロトコルのみが他のサーバーにリダイレクトされます。


8: 名前空間が複数/セッション アフィニティなしのシナリオ – 正常性プローブの応答が異常な場合

この手法には、名前空間が余分に必要になるというデメリットがあります。このため、証明書にサブジェクト代替名として追加する名前の数が増加し、証明書プロバイダーのコストが上昇する可能性があります。しかし、エンド ユーザーにとっては複雑さが増すことはなく、ユーザーが把握しておく必要のある URL は OWA の URL だけです。ActiveSync、Outlook、および Exchange Web サービスのクライアントは、適切な URL を決定するために Autodiscover を使用します。

シナリオのまとめ

次の表は、それぞれの手法のメリットとデメリットをまとめたものです。

                                                  

メリット                                              

デメリット                                                                

名前空間が 1 つ/レイヤー 4 (セッション アフィニティなし)

  名前空間が 1 つのみ

  ロード バランサーに関する複雑さが軽減

  セッション アフィニティが CAS で保持される

  正常性の判断はサーバーごと

名前空間が 1 つ/レイヤー 7 (セッション アフィニティなし)

  名前空間が 1 つのみ

  正常性の判断はプロトコルごと

  SSL オフロードによりロード バランサーのスケーラビリティに影響がでる可能性がある

名前空間が 1 つ/レイヤー 7 (セッション アフィニティあり)

  名前空間が 1 つのみ

  正常性の判断はプロトコルごと

  セッション アフィニティがロード バランサーで保持される

  ロード バランサーに関する複雑さが増す

  ロード バランサーのスケーラビリティが低い

名前空間が複数/セッション アフィニティなし

  正常性の判断はプロトコルごと

  セッション アフィニティが CAS で保持される

  ユーザーは OWA の URL のみを把握すればよい

  複数の名前空間が必要

  証明書の名前の数が増加

  ロード バランサーのルール セットが余分に必要

  複数の VIP が必要

まとめ

Exchange 2013 では、名前空間と負荷分散アーキテクチャの柔軟性が大幅に向上しました。負荷分散機能については、機能性と簡潔性のバランスを考慮した最終的な判断が必要となります。最も簡潔なソリューションにはセッション アフィニティ管理とプロトコルごとの正常性確認の機能がありませんが、1 つの名前空間のみでデプロイできます。逆に、複雑なソリューションでは、セッション アフィニティ管理機能が使用可能で、また 1 つの名前空間でプロトコルごとの正常性確認もできますが、複雑さが増すことによるコストが掛かります。また、機能性と簡潔性のバランスをとり、セッション アフィニティがない反面、プロトコルごとの正常性確認が可能ながらもプロトコルごとに一意の名前空間のコストが必要となる負荷分散ソリューションをデプロイすることもできます。

Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

Skip to main content