次の方法で共有


ロード バランサー機器

 

トピックの最終更新日: 2012-10-18

DNS 負荷分散を展開する場合でも、フロント エンド プールおよびディレクター プールへの HTTP トラフィックの負荷分散を行うためにロード バランサー機器が必要です。

また、リバース プロキシ サーバー用に境界ネットワークへのロード バランサー機器の展開も行いました。

最高レベルの負荷分散と高可用性を提供するために、一対のロード バランサー機器 (HLB) がグローバル サーバー ロード バランサー (GSLB) と共に各サイトに展開されました。すべてのロード バランサーがサイトとサーバーの状態に関して絶えず相互に通信することで、どちらかのセントラル サイトで 1 つのデバイスに障害が発生しても、現在接続しているユーザーにサービスの中断が発生することはなくなります。

このテスト シナリオでは、グローバル サーバー (F5 BIG-IP GTM) HLB とローカル サーバー (F5 BIG-IP LTM) HLB の双方を使用する方法を採用しました。グローバル サーバー ロード バランサーは、セントラル サイトの可用性と状態に基づいて各サイトへのトラフィックを管理するために実装され、ローカル サーバー ロード バランサーは、各サイト内のローカル サーバーに対する接続の管理を行いました。この実装には、次の利点があります。

  • ローカルおよびグローバルのレベルで最高レベルのフォールト トレランスが得られる完全にメッシュ化されたシステムです。

  • セントラル サイト内で内部トラフィックと外部トラフィックが完全にセグメント化されます。

  • 必要に応じて、ハードウェアを利用してフロント エンド サーバー、エッジ サーバー、およびディレクターに対するすべての接続の負荷分散が行えます。

いくつかの観点では最適といえますが、この展開には 2 つの欠点があります。より多くの HLB の購入が必要になることと、管理する構成が多数のデバイスによって複雑になることです。負荷分散インフラストラクチャの統合は、確かに可能であり、一部の環境では有益です。たとえば、多くの展開設計では、それぞれのセントラル サイト内に単一または一対の HLB が含まれます。こうした設計で HLB が複数のサブネットにまたがっていても、負荷分散のロジックは同じままです。F5 は、各種ネットワーク設計間のトレードオフを調査したアーキテクチャ上のガイダンスを制作しています。詳細については、http://www.f5.com/products/technology/microsoft/lync-server/ を参照してください。Lync Server で GSLB を使用せずに HLB を利用する展開の詳細については、「Microsoft Office Communications Server 2007 R2 のサイト復元に関するホワイト ペーパー」(https://go.microsoft.com/fwlink/?linkid=211387&clcid=0x411) を参照してください。このホワイト ペーパーで説明されている展開は、Lync Server 2010 の有効な参照アーキテクチャも提供します。

ローカルとグローバルの双方のロード バランサーを活用することで、ユーザーが接続する URL を 1 つしか使用せずにサーバーとサイトの双方の復元を実現しました。GTM は、選択された負荷分散アルゴリズムとグローバル サービスの可用性に基づいて 1 つの URL の解決から異なる IP アドレスを取得します。権限のある Windows DNS サーバー (contoso.com) が URL (pool.contoso.com) を GTM に委任することで、pool.contoso.com に接続しているユーザーは DNS 解決時に適切なサイトに送られます。その後、ローカル サーバー ロード バランサーは、接続を取得し、適切なサーバーに対して負荷分散を行います。

HLB は、HTTP または HTTPS モニターを使用してフロント エンド プールのメンバーを監視するように構成されていました。こうしたモニターは、サーバーの状態とパフォーマンスに関する最適な情報をロード バランサーに提供します。その後、HLB はこの情報を使用して、最適なローカル フロント エンドに対する受信接続の負荷分散を行います。また、機能優先アクティブ化という機能を使用して、すべてのローカル フロント エンドが処理能力の限界に達して機能しなくなった場合に接続を他のセントラル サイトにプロキシするように、HLB を構成しました。

グローバル サーバー ロード バランサー (GTM) は、各サイト内の HLB を監視すると共に最適な状態で実行できるサイトにユーザーを振り向けるように構成されていました。GTM は、セントラル サイトが (今回のテストと同様に) アクティブ/スタンバイ状態にある場合にすべてのユーザーを特定のサイトに送ったり、アクティブ/アクティブ状態にある展開のサイト間でユーザーの負荷分散を行ったりするように構成できます。1 つのサイトが処理能力の限界に達するか、使用不可能になった場合、GTM はユーザーを使用可能な他のサイトに振り向けます。