Exchange 2010 の負荷分散について
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2016-11-28
負荷分散は、サーバーによるトラフィックの受信を管理するための方法です。負荷分散によってフェイルオーバーによる冗長性が提供され、コンピューターで障害が発生した場合にも、ユーザーは引き続き Exchange のサービスを受けられることを保証します。これにより、クライアントには単一のホスト名を提供しつつ、展開において 1 台のサーバーが処理可能な量を超えるトラフィックを処理できるようにもなります。
負荷分散に加えて、MicrosoftExchange Server 2010 は切換えおよびフェイルオーバーによる冗長性に対して、いくつかの解決方法を提供します。これらの解決方法には次のようなものがあります。
高可用性とサイト復元 2 つの Active Directory サイトを地理的に離れた場所に展開し、2 つのサイト間でメールボックス のデータの同期を維持して、一方のサイトに障害が発生した場合は、もう一方がすべての負荷を引き受けます。Exchange 2010 はデータベース可用性グループ (DAG) を使用して、同期した別々のサーバー上でメールボックスの複数のコピーを維持します。
メールボックスのオンライン移動 メールボックスのオンライン移動では、移動中もエンド ユーザーは自分の電子メール アカウントにアクセスできます。ユーザーがロックアウトされるのは、処理の最後の短い間 (最終的な同期が行われている間) だけです。オンライン メールボックス移動は、Exchange 2010 データベース間、および Exchange Server 2007 Service Pack 3 (SP3) または Exchange 2007 以降のバージョンおよび Exchange 2010 データベースの間でサポートされています。メールボックスのオンライン移動は、フォレスト間または同じフォレスト内で実行できます。
シャドウ冗長 シャドウ冗長は、メッセージの送信中における可用性と回復性を保護します。シャドウ冗長を使用することで、トランスポート サーバーがメッセージのすべてのネクスト ホップが完了したことを確認するまで、トランスポート データベースのメッセージの削除は遅延されます。ネクスト ホップのいずれかに失敗して、配信が正常に行われたことを示すレポートが届かなかった場合は、完了しなかったホップに配信されるようにメッセージが再送信されます。
目次
負荷分散の概要
Exchange 2010 のトラフィックの負荷について
負荷分散のオプションについて
負荷分散に関する推奨事項
アフィニティのオプション
負荷分散の概要
負荷分散には 2 つの主な目的があります。これにより、Active Directory サイトのうち 1 箇所における単一のクライアント アクセス サーバー障害による影響を軽減します。さらに、負荷分散によってクライアント アクセス サーバーとハブ トランスポート コンピューターの負荷が均等に分散されるようになります。
Exchange 2010 における負荷分散アーキテクチャの変更
Exchange 2010 におけるいくつかの変更によって、負荷分散は組織において重要になっています。クライアント アクセス サーバーの役割の Exchange RPC クライアント アクセス サービスおよび Exchange アドレス帳サービスにより、メールボックスのフェイルオーバー中にメールボックス アクセスの接続エンドポイントを Outlook およびその他の MAPI クライアントから、メールボックス サーバー役割の代わりにクライアント アクセス サーバー役割へと移動させることによって、ユーザーの操作性が向上します。Exchange の以前のバージョンにおいては、Outlook はユーザーのメールボックスをホストしているメールボックス サーバーに直接接続されていて、ディレクトリ接続はメールボックス サーバーを通してプロキシ接続するかまたは特定の Active Directory グローバル カタログ サーバーに直接参照するかのいずれかでした。これらの接続はクライアント アクセス サーバー役割によって処理されるようになり、外部および内部の Outlook 接続は展開においてフォールト トレランスを実現するために、クライアント アクセス サーバーのアレイにわたって負荷分散される必要があります。
負荷分散されたクライアント アクセス サーバーのアレイは、それぞれの Active Directory サイトおよび Exchange の各バージョンにおいて推奨されます。1 つの負荷分散されたクライアント アクセス サーバーのアレイを複数の Active Directory サイトで共有したり、同じアレイ内で Exchange の異なるバージョンまたは Exchange の異なるサービス パックのバージョンを混在させることはできません。
Exchange 2010 を既存の組織内にインストールし、以前のバージョンの Exchange との共存用に従来の名前空間を構成すると、クライアントは Exchange 2010 クライアント アクセス サーバーまたはサーバー アレイに自動的に接続します。Exchange 2010 クライアント アクセス サーバーまたはクライアント アクセス サーバー アレイは、古いバージョンの Exchange 上のメールボックスに対するクライアント要求を、メールボックスのバージョンが一致する Exchange 2003 フロントエンド サーバーまたは Exchange 2007 クライアント アクセス サーバーのいずれかにプロキシまたはリダイレクトします。詳細については、「Exchange 2010 へのアップグレードについて」を参照してください。
注意
Quick Fix Engineering (QFE) および更新プログラムのロールアップを、アレイのすべてまたは一部に適用する場合はそれらを混在させることができます。QFE および更新プログラムのロールアップをアレイ内のすべてのコンピューターに適用することをお勧めします。
負荷分散の構成は、クライアントが接続に使用するホスト名および使用する SSL (Secure Sockets Layer) に直接の影響をもたらします。Exchange 2010 の証明書の詳細については、「デジタル証明書と SSL について」を参照してください。
クライアント アクセス サーバー アレイを構成する
1 つの Active Directory サイトにつき、構成可能なクライアント アクセス サーバー アレイは 1 つです。クライアント アクセス サーバー アレイを構成した後はすぐに、クライアント アクセス サーバー アレイを特定のクライアント アクセス サーバーとしてではなく MAPI エンドポイントとして使用するようにメールボックス データベースを構成します。
クライアント アクセス サーバー アレイおよびクライアント アクセス サーバー アレイを特定の Active Directory サイトに使用するようにメールボックス データベースを構成する方法の詳細は、「RPC クライアント アクセスについて」を参照してください。
Exchange 2010 のトラフィックの負荷について
負荷分散を構成する前に、Exchange 2010 クライアント アクセス サーバーに対する負荷を理解する必要があります。Exchange 2010 クライアント アクセス サーバーは、次の 3 種類のトラフィックを受信します。
外部クライアントからのトラフィック
内部クライアントからのトラフィック
他のクライアント アクセス サーバーからのプロキシ トラフィック
他のクライアント アクセス サーバーからのプロキシ トラフィックは、もともと外部または内部のクライアントから 1 つのクライアント アクセス サーバーに対して送信されたトラフィックですが、別のクライアント アクセス サーバーにプロキシされたものです。これはさまざまな理由によって発生しますが、一般的に発信元のクライアントが送信先のクライアント アクセス サーバーに直接に接続できない場合に発生します。これはユーザーがインターネットからメールボックスにアクセスする場合に、メールボックスがインターネットに面していない内部の Active Directory サイトにある場合に発生することがあります。プロキシの詳細については、「プロキシとリダイレクトについて」を参照してください。
クライアント アクセス サーバーによって受信されたトラフィックの種類のそれぞれには、プロトコルの一覧からの要求および特性の異なるクライアント デバイスとコンピューターからの応答が含まれます。これらの違いは、使用する負荷分散の戦略に影響を与えます。
ページのトップへ
負荷分散のオプションについて
さまざまな負荷分散ソリューションには、いくつかの主要なテクノロジーで違いがあります。
パフォーマンス ソリューションが 1 秒あたりに処理できる要求の数。
管理性 負荷分散のソリューションを構成して展開することの単純さ。
**フェイルオーバーの自動化と検出 ** クライアント アクセス サーバーまたはサービスに障害が発生した場合に、負荷分散機能がどれだけ賢く検出するか。
**アフィニティ ** 負荷分散ソリューションがサポートする、クライアントとクライアント アクセス サーバー間のアフィニティの種類。
アフィニティについて
負荷分散ソリューションが、クライアントとクライアント アクセス サーバー間でアフィニティを提供する場合、それは特定のクライアントと特定のクライアント アクセス サーバーとの間に、長時間にわたる関連付けが存在することを意味します。クライアントは、ラップトップ上で実行している Outlook、モバイル デバイス上で実行している Microsoft Exchange ActiveSync、Microsoft Office Outlook Web App、Exchange Web サービス、または別のクライアント アプリケーションのいずれかです。
この長い時間にわたる関連付け、またはアフィニティ、すべての要求はクライアントから送信され、同じクライアント アクセス サーバーに向かうことを確認します。いくつかの Exchange 2010 プロトコルはアフィニティを必要とし、その他の Exchange プロトコルは必要としません。
Windows ネットワーク負荷分散
Windows ネットワーク負荷分散 (WNLB) は、Exchange サーバーで使用される、最も一般的なソフトウェア負荷分散機能です。WNLB を Microsoft Exchange と共に展開することに関連して、制限事項がいくつかあります。
WNLB は、メールボックス DAG も使用されている Exchange サーバー上では使用できません。なぜなら、WNLB は Windows フェイルオーバー クラスタリングと互換性が無いからです。Exchange 2010 DAG を現在使用していて WNLB を使用する場合は、クライアント アクセス サーバー役割とメールボックス サーバー役割を別のサーバー上で実行する必要があります。
パフォーマンスの問題のため、WNLB によって負荷分散されたアレイに 8 台を超えるクライアント アクセス サーバーを追加することはお勧めしません。
WNLB はサービスの停止を検出しません。WNLB は IP アドレスでサーバーの停止を検出するだけです。これは、Outlook Web App のような特定の Web サービスが失敗したにもかかわらず、サーバーが継続して機能している場合、WNLB は障害を検出せず、依然として要求をクライアント アクセス サーバーにルーティングします。障害が発生しているクライアント アクセス サーバーは、負荷分散プールから取り除くために手動による介入が必要です。
WNLB 構成によってはポート フラッディングが発生し、ネットワークに大きな負担を与えます。
WNLB は、送信元の IP アドレスを使用したクライアントのアフィニティのみを実行するため、送信元の IP プールが小さい場合には効率的なソリューションではありません。これは送信元の IP プールがリモート ネットワーク サブネットから来ている場合、または組織がネットワーク アドレス変換を使用している場合に起こります。
負荷分散に関する推奨事項
使用可能な負荷分散のオプションはいくつかあります。使用するオプションは、ネットワークのサイズと構成に依存します。
ソース IP アフィニティ による Windows ネットワーク負荷分散
最初の負荷分散オプションは、ソース IP アフィニティによる WNLB です。このソリューションは、Active Directory サイトにつき、クライアント アクセス サーバーが 1 台よりも多く 8 台よりも少ない場合に適切です。このソリューションは Windows に組み込まれており、追加のコンピューターを必要としません。
WNLB を使用しないシナリオとしては 2 つあります。
組織に、WNLB 仮想 IP アドレスを通さず、クライアント アクセス サーバーと直接通信するリバース プロキシ サーバーがある。リバース プロキシ サーバーは、クライアント アクセス サーバー アレイからクライアント IP アドレスを隠します。そのため、ソース IP アフィニティは期待どおりに動作しません。ただし、内部トラフィックの負荷分散に WNLB を使用することはできます。
組織には、非常に数少ない IP アドレスのセットを通してクライアント アクセス サーバーにアクセスしている、数多くのクライアントが存在します。WNLB は、クラス C サブネット全体を、1 つのクライアント アクセス サーバーにアフィニティ化する傾向があります。
ハードウェア負荷分散
1 つの Active Directory サイトに 8 台を超えるクライアント アクセス サーバーがある場合は、より堅牢性の高い負荷分散ソリューションが組織に必要です。ソフトウェアによる負荷分散ソリューションも利用可能ですが、ハードウェアによる負荷分散ソリューションは最大の能力を提供します。Exchange 2010 サーバーの負荷分散ソリューションの詳細については、「Microsoft Unified Communications の負荷分散装置の展開」を参照してください。
ハードウェアによる負荷分散機能は非常に高いトラフィック スループットをサポートし、さまざまな方法で負荷分散を構成できます。ほとんどのハードウェア負荷分散機能のベンダーは、製品の Exchange 2010 との連携に関して詳細なマニュアルを用意しています。ハードウェアの負荷分散機能を構成する最も単純な方法は、負荷分散機能によって適用されるアフィニティ方式のフォールバック一覧を作成することです。たとえば、負荷分散機能は最初に Cookie ベースのアフィニティ、次に SSL セッション ID、そしてソース IP アフィニティを試みます。
リバース プロキシ ソリューション
Microsoft Forefront Threat Management Gateway (TMG) や Forefront Unified Access Gateway (UAG) など、インターネットに公開するサーバーに対して負荷分散を実行できるリバース プロキシ ソリューションがある場合は、リバース プロキシ ソリューションの使用をお勧めします。
トラフィックがリバース プロキシ サーバーを通過してクライアント アクセス サーバーに到達すると、クライアントの元の IP アドレスはリバース プロキシ サーバーの IP アドレスに置き換えられます。これにより、ソース IP アフィニティが中断されます。この問題を解決するには、リバース プロキシ サーバーをプロキシ先のサブネットに対してデフォルト ゲートウェイとなるように構成するなどの方法があります。
ただし、現在のほとんどのリバース プロキシ サーバーは、インターネットに対して公開しているサービスの負荷分散を行うことができます。これらのリバース プロキシ サーバーは、Exchange サービスが対応していれば、負荷分散装置が作成した Cookie を使用してサービスの負荷分散を実行することが可能です。これは、ソース IP の負荷分散よりも信頼性の高いソリューションです。これが動作するためには、リバース プロキシ サーバーが HTTP データ ストリームの読み取りおよび変更を行える必要があります。SSL を使用している場合、これはリバース プロキシ サーバーがトラフィックを解読して、ストリーム内に Cookie を作成する必要があることを意味しています。この解読は、クライアントがクライアント アクセス サーバーに接続する時に、クライアント証明書の認証を使用しているような場合では不可能です。
ページのトップへ
アフィニティのオプション
負荷分散ソリューションが異なれば、クライアントを特定のクライアント アクセス サーバーに関連付ける方法は異なります。異なる負荷分散製品で利用可能なアフィニティには、ハードウェアおよびソフトウェアの両方において、いくつかの一般的な種類があります。次の例で示すように、すべての種類のアフィニティが、すべての負荷分散オプションで利用可能なわけではありません。
WNLB では、ソース IP アフィニティまたはアフィニティなしのみをサポートします。
特定のサーバー アレイにおけるソフトウェアによる負荷分散装置は、負荷分散装置がこれらの Cookie と残りの製品に対するソース IP アフィニティをサポートするプロトコル用に作成した Cookie を使用できます。
ハードウェア負荷分散装置を SSL オフロードと併用する場合、より複雑な動作を構成できます。例えば、負荷分散装置によって作成された Cookie、SSL セッション ID、およびソース IP と同様に、これらの Cookie をサポートするプロトコルに影響を与える、既存の Cookie のセットを構成できます。
異なる負荷分散ソリューションでサポートされているオプションに加えて、これらの手順のうち、特定の Exchange プロトコルおよびサービスにのみ適用される一部を構成することもできます。各プロトコルの動作は異なるので、これによりパフォーマンスを最適化できます。
既存の Cookie または HTTP ヘッダー
既存の Cookie または HTTP ヘッダーを使用する方法は、クライアントを識別して特定のクライアント アクセス サーバーに関連付けるのに最も信頼できる方法です。これらの Cookie およびヘッダーは通信プロトコルの一部として、クライアントまたはサーバーによって作成されます。このオプションは、パフォーマンスの向上に役立つ、トラフィックを変更するための負荷分散装置も必要としません。
このアフィニティ オプションを使用する場合、以下のことに注意します。
負荷分散装置が、この種類のアフィニティをサポートしている必要があります。現在、このアフィニティをサポートしているのは、ハードウェアによる負荷分散装置だけです。
このアフィニティは、HTTP トラフィックを通過するプロトコルでのみ機能します。
クライアント セッションの間中、一定のまま変わらない既存の Cookie またはヘッダーが存在している必要があり、それは特定のクライアント、またはクライアントの小さなセットに対してプロトコル内で一意です。
負荷分散装置のソリューションは、HTTP データ ストリームを読み取って解釈できる必要があります。SSL を使用している場合、これは負荷分散装置が内容を読み取るためにトラフィックを解読する必要があることを示しています。場合によっては、この結果負荷分散装置の負荷が増加することがあります。また、この解読は、クライアントがクライアント アクセス サーバーに接続する時に、SSL セッションによるクライアント証明書の認証を使用しているような場合では不可能です。
負荷分散に適切な既存の Cookie および HTTP ヘッダーで、Exchange 2010 プロトコルで利用可能なものは次のとおりです。
HTTP 基本認証承認ヘッダー このヘッダーは HTTP 基本認証が使用される場合に動作します。基本認証は既定の認証で、Exchange ActiveSync で最も一般的に使用されている種類の認証です。このヘッダーは、他のプロトコルおよび認証方法では一般的ではありません。基本認証承認ヘッダーは、基本認証を使用して特定のユーザーから送信されるすべてのトラフィックを、同じクライアント アクセス サーバーに送信します。このヘッダーはまた、Outlook トラフィックが HTTP を通して完全に送信される場合で、クライアントがリバース プロキシ サーバーの背後にある場合に使用されます。
HTTP OWA UserContext Cookie この Cookie は Outlook Web App で動作し、それを使用する唯一のクライアントです。フォーム ベース認証 (FBA) を Outlook Web App で使用する場合 (既定の構成)、Outlook Web App セッションの開始時において、UserContext が作成される前に、小さな要求のセットが作成されます。これらの要求がアフィニティを使用してクライアントを同じクライアント アクセス サーバーに接続していることを確認するため (フォーム ベース認証が動作するために必須)、UserContext Cookie を使用する場合は、フォールバック アフィニティ オプションが存在する必要があります。負荷分散装置が UserContext Cookie を取得して使用する前に、それらの初期要求に対してアフィニティを提供するために、SSL セッション ID またはソース IP アフィニティをフォールバックとして使用することをお勧めします。
注意
Outlook Web App では、特定のメールボックスのアクセスに明示的なログオンの使用が要求され、その結果、UserContext Cookie を異なる名前と ID で使用することになります。Cookie は UserContext で始まりますが、個別のメールボックスを識別する文字列が追加されます。これにより、UserContext Cookie による負荷分散が複雑化します。なぜなら、負荷分散装置は最初に UserContext で始まる Cookie を見つける必要があるからです。この結果、パフォーマンスが低下します。
HTTP Exchange コントロール パネル msExchEcpCanary Cookie この Cookie は Exchange コントロール パネルでのみ動作します。
HTTP Outlook 2010 OutlookSession Cookie ハードウェアによる負荷分散装置は、OutlookSession Cookie とその他の一般的な Cookie をサポートしています。次の表は、Outlook RPC/HTTP における OutlookSession クライアントの Cookie のサポート要件を示しています。
Windows XP
Windows Vista
Windows 7
Outlook 2003
非サポート
非サポート
非サポート
Outlook 2007
非サポート
非サポート
非サポート
Outlook 2007 ホスティング パック (KB2544404)
非サポート
サポート
サポート
Outlook 2010
非サポート
サポート
サポート
注意
Windows XP 上で動作する Microsoft Outlook は、負荷分散の OutlookSession Cookie をサポートしていません。このシナリオでは、IP の負荷分散を使用することをお勧めします。
HTTP リモート PowerShell MS-WSMAN Cookie この方法は、リモート PowerShell でのみ動作します。
ページのトップへ
負荷分散装置によって作成された Cookie
クライアント セッションをクライアント アクセス サーバーに関連付けるのに 2 番目に信頼できる方法は、負荷分散装置によって作成された Cookie を使用する方法です。負荷分散装置は HTTP Cookie をクライアント / サーバー プロトコル通信に追加し、その Cookie を使用してどのクライアント アクセス サーバーが受信要求を処理するかを決定します。この方法をサポートする Exchange 2010 アプリケーションは、Outlook Web App、Exchange コントロール パネル、およびリモート PowerShell です。このタイプの Cookie には、いくつかの制限があります。
負荷分散装置は、この種類のアフィニティをサポートしている必要があります。現時点では、ハードウェアによる負荷分散装置と、別のサーバー層で実行している負荷分散装置だけが、このアフィニティをサポートしています。
この方法は、HTTP トラフィックを通過するプロトコルでのみ機能します。RPC クライアント アクセス サービス、Exchange アドレス帳サービス、POP3、または IMAP4 に対してこの方法は使用できません。
負荷分散装置のソリューションは、HTTP データ ストリームを読み取って解釈できる必要があります。SSL を使用している場合、これは負荷分散装置が内容を読み取るためにトラフィックを解読する必要があることを示しています。場合によっては、この結果負荷分散装置の負荷が増加することがあります。その他の場合、クライアント アクセス サーバー上でクライアント証明書の認証を使用するような場合、負荷分散装置が HTTP データ ストリームを解釈することは不可能です。
クライアントは、サーバーからの独自の Cookie を受信できるようにする必要があり、それらの Cookie をクライアントからサーバーに送信されるすべての将来の要求に含める必要があります。Exchange ActiveSync クライアント、Outlook Anywhere クライアント、および Exchange Microsoft Communications Server 2007 デバイスなどのある種の Office Web サービス クライアントは、これをサポートしていません。
SSL セッション ID
SSL セッション ID を基にした負荷分散は、ソース IP アフィニティを基にしたものよりも詳細で、異なるクライアントからのトラフィックを、同じ IP アドレスから来たトラフィックであっても分割できます。SSL セッション ID 負荷分散には、SSL トラフィックを解読せずに負荷分散を行えるという利点もあります。これは、クライアント資格情報の認証を使用する場合、およびクライアント アクセス サーバーで SSL 接続を切断する場合に必要です。
SSL セッション ID のアフィニティは、次の 2 つの状況では推奨されていません。
Internet Explorer 8 のような一部のクライアントでは、クライアント上で実行しているブラウザーのプロセスそれぞれに対して、SSL セッションを再作成します。この結果、Outlook Web App ウィンドウそれぞれに対して新しい SSL セッションが作成されます。これにより Outlook Web App アフィニティが失われるため、この方法による負荷分散の展開は Exchange 2010 ではサポートされていません。Apple の iPhone といった一部のモバイル機器でも、Exchange との Exchange ActiveSync 通信の一部で新規の SSL セッションを作成します。
注意
クライアント資格情報の認証を使用する場合、ブラウザーは指定されたホスト名に対するすべてのトラフィックに対して、同じ SSL セッションを使用します。クライアント資格情報の認証が有効な限り、SSL セッション ID は Outlook Web App および Exchange コントロール パネルに対する有効なアフィニティ オプションです。
Outlook Anywhere の場合、クライアント アクセス サーバーは Windows RPC Proxy コンポーネントを使用して RPC_DATA_IN と RPC_DATA_OUT 通信を一組にします。これにより、パフォーマンスに悪影響を及ぼす可能性があります。
送信元 IP
クライアントとクライアント アクセス サーバー間にアフィニティを提供する最も一般的な方法は、ソース IP アフィニティを使用することです。負荷分散装置は、クラインとの IP アドレスを確認し、特定のソース IP からのすべてのトラフィックを特定のクライアント アクセス サーバーに送信します。これが唯一 WNLB によってサポートされているアフィニティの種類です。ソース IP アフィニティを使用する場合、2 つの重要な考慮すべき側面があります。
アフィニティは、クライアントの IP アドレスが変更されると失われます。これは、ラップトップを有線の LAN から Wi-Fi または別の Wi-Fi ネットワーク間をローミングする時に起こります。クライアントの IP アドレスが変更されると、ユーザーに影響を与えます。例えば、ユーザーが Outlook Web App を使用している場合、ユーザーはコンピューターが新しい IP アドレスを取得するたびに、毎回認証を行う必要があります。
クライアントの多数が同じ IP アドレスから負荷分散ソリューションにアクセスすると、負荷の分散は不均衡になります。これによる影響は、特定の IP アドレスの背後に隠されたクライアントの数に依存します。例えば、4 台のクライアント アクセス サーバーがあり、50% のクライアントが同じ IP アドレスから負荷分散装置にアクセスしている場合、少なくともトラフィックの 50% は 1 台のクライアント アクセス サーバーへと向かい、その他の 3 台のクライアント アクセス サーバーが残りのトラフィックを処理します。ほとんどのクライアントが単一の IP アドレスを通して Exchange 組織にアクセスする理由としては主に 2 つあります。
Microsoft Forefront Threat Management Gateway (TMG) などの、ネットワーク アドレス変換 (NAT) または送信プロキシ サーバー。クライアントとクライアント アクセス サーバーの間に NAT または送信プロキシ サーバーがある場合、元のクライアント IP アドレスは NAT または送信プロキシ サーバーの IP アドレスによって隠されます。
クライアント アクセス サーバーからクライアント アクセス サーバー プロキシへのトラフィック。シナリオによっては、1 台のクライアント アクセス サーバーが別のクライアント アクセス サーバーへのトラフィックをプロキシします。通常、これは Active Directory サイト間で発生します。なぜなら、クライアントは自身のめーっるボックスとして、同じ Active Directory サイトにあるクライアント アクセス サーバーにアクセスする必要があるからです。プロキシの詳細については、「プロキシとリダイレクトについて」を参照してください。
アフィニティなし
アフィニティの最後の種類は、アフィニティなしです。アフィニティを使用しない場合、クライアントのそれぞれの要求は、クライアント アクセス サーバーにランダムに割り当てられます。アフィニティを必要とするプロトコルまたはアフィニティによってパフォーマンス上の利点が得られるプロトコルには、このオプションは推奨しません。
SSL オフロードが構成されている場合、アフィニティが必要ないプロトコルにアフィニティを使用することはお勧めしません。
ページのトップへ
負荷分散のオプションの概要
次の表では、利用可能な負荷分散のオプションの概要を示します。
| 解決方法 | クライアントからクライアント アクセス サーバーのアフィニティ | フェイルオーバーの方法 | 容量 | コスト |
|---|---|---|---|---|
ハードウェアによる負荷分散装置 |
プロトコルとクライアントによっては、次の間でフォールバックします。
|
クライアントのダウンタイムを最小限に抑えた自動フェールオーバー。ハードウェアによる負荷分散装置は、特定のプロトコルに対してフェールオーバーを提供することもできます。 |
++++ |
$$$ |
別のサーバー層におけるソフトウェアによる負荷分散装置 注:外部トラフィックに関しては、TMG と UAG だけが使用可能なソリューションです。 |
プロトコルおよびクライアントに依存して、負荷分散装置によって作成された Cookie またはソース IP のいずれか。 |
クライアントのダウンタイムを最小限に抑えた自動フェールオーバー。 |
++ |
$$ |
クライアント アクセス サーバーとして、同じサーバー層にあるソフトウェア負荷分散装置 (WNLB) |
送信元 IP。 |
クライアントのダウンタイムを最小限に抑えた自動フェールオーバー。 |
+ |
$ |
DNS ラウンド ロビン |
各クライアントは、ランダムなクライアント アクセス サーバーの IP アドレスを取得します。 |
手動による手順で、問題と回復を検出する。管理者によって回復が実行された後も、ブラウザーとオペレーティング システム DNS キャッシュ動作によって、クライアント接続ができなくなる可能性があります。このソリューションによって、Outlook Web App、Exchange Web サービス、および Exchange コントロール パネルといった多くのプロトコルのアフィニティは失われます。 |
+++ |
$ |
負荷分散装置なし |
各クライアント アクセス サーバーに別々のホスト名が手動で割り当てられます。 |
手動による手順で、問題とフェールオーバーを検出する。クライアント DNS キャッシュにより、フェールオーバーの速度が低下します。 |
+ |
該当なし |
これらのオプションのそれぞれに、長所および短所がいくつかあります。
ハードウェア負荷分散装置には、通常 SSL オフロードおよびトラフィック検査といったパフォーマンスおよびセキュリティの機能が含まれています。
別のサーバー層のソフトウェア負荷分散装置は通常、事前認証、SSL オフロード、および広範囲なトラフィック検査のようなリバース プロキシ機能と共に、大きなソフトウェア パッケージの一部として含まれています。ソフトウェア負荷分散装置がユーザーを事前認証すると、クライアント アクセス サーバーがアフィニティに失敗した場合に、それらのユーザーは再認証する必要がなくなります。ただし、ソフトウェア負荷分散装置によっては、クライアントとリバース プロキシ サーバー間のアフィニティを必要とするものもあります。この場合、これらのリバース プロキシ サーバーがクライアント アクセス サーバーに対して負荷分散業務を実行する前に、リバース プロキシ サーバーの前段階に追加の負荷分散層が必要です。
© 2010 Microsoft Corporation.All rights reserved.