ユーザー・ネットワークの管理: 使用する Load Balancer 機能の判別
この章では、ユーザー・ネットワークを管理する上で使用する機能を
判別できるように、Load Balancer コンポーネントの構成機能をリスト表示します。
Manager、Advisor、および Metric Server 機能 (Dispatcher、CBR、および Site Selector コンポーネント)
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
Dispatcher コンポーネントの機能
Dispatcher は、HTTP、FTP、SSL、
SMTP、NNTP、IMAP、POP3、Telnet、SIP、その他の TCP、
またはステートレス UDP ベースのアプリケーションに対して
ユーザー・サーバー間のロード・バランシングをサポートします。
リモート管理
連結
- _ ロード・バランシングを実行している Web サーバーと同じマシン上で Dispatcher を実行するには、『連結サーバーの使用』を参照してください。
ハイ・アベイラビリティー
サーバー類縁性のクライアント
SSL (HTTPS) トラフィックをロード・バランシング時に、
- _ 複数の接続に対してクライアントが確実に同じ SSL サーバーを使用するようにするには、『Load Balancer の類縁性機能の動作』を参照してください。
- _ HTTP および SSL トラフィックに対してクライアントが確実に同じサーバーを使用するようにするには、ポート間類縁性を参照してください。
ルール・ベースのロード・バランシング
同じ Web アドレスに対して別々のサーバー・セットにクライアントを割り当てるには、Dispatcher 構成に「ルール」を追加することができます。詳細については、ルール・ベースのロード・バランシングの構成を参照してください。
Dispatcher の CBR 転送方式を使用した Content Based Routing
クライアント要求の SSL ID に基づいて、SSL クライアントが同じ SSL サーバーに戻るようにするには、>SSL によるコンテンツ・ベースのルーティング構成に関するセクションを参照してください。
クライアント要求の URL コンテンツの突き合わせに基づくルールを使用して、別々のサーバー・セットに HTTP クライアントを割り当てるときには、詳細について Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)および 要求コンテンツに基づくルールの使用を参照してください。
- _ 特定の URL とそのサービス・アプリケーションを区別するには、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。
- _ ユーザー Web サーバーによって作成された Cookie を使用して、複数の接続で類似したコンテンツを要求したときに、クライアントが同じサーバーに確実に戻るようにするには、受動 cookie 類縁性を参照してください。
- _ 固有のコンテンツを各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックのロード・バランシングを行うには (複数マシン上のコンテンツの冗長なキャッシュを除去することによって、サイトのキャッシュ・サイズが増加します)、URI 類縁性を参照してください。
Dispatcher コンポーネントの CBR 転送方式と CBR コンポーネントの比較
Dispatcher の CBR 転送方式を使用する利点は、クライアント要求に対する応答が CBR コンポーネントよりも速いということです。また、Dispatcher の CBR 転送方式では、Caching Proxy のインストールおよび使用は不要です。
ネットワークに完全にセキュアな SSL (サーバーを介したクライアント) のトラフィックが存在する場合、(Caching Proxy とともに) CBR コンポーネント
使用する利点は、
Content Based Routing を実行するために必要な暗号化および暗号化解除を
処理できることです。完全にセキュアな接続では、
Dispatcher の CBR 転送は SSL ID 類縁性でしか構成できません。これは、
Dispatcher の CBR 転送が、クライアント要求の URL で真の Content Based Routing を
実行するための暗号化および暗号化解除を処理できないためです。
広域ロード・バランシング
広域ロード・バランシングは、幾つかの異なる方式で達成できます。
ポート・マッピング
プライベート・ネットワークでの Dispatcher のセットアップ
- _ Dispatcher トラフィックをクライアント・トラフィックと
別のネットワークに配置するには (外部ネットワークでの競合を削減して
パフォーマンスを向上させる目的で)、『プライベート・ネットワーク構成の使用』を参照してください。
ワイルドカード・クラスターとワイルドカード・ポート
「サービス妨害」攻撃の検出
バイナリー・ロギング
アラート
Content Based Routing (CBR) コンポーネントの機能
CBR は、ロード・バランシングと WebSphere® Application Server の Caching Proxy を統合して、指定の HTTP または HTTPS (SSL) サーバーに対するクライアント要求を代行します。CBR を使用するには、Caching Proxy が同じマシン上にインストールおよび構成される必要があります。CBR を使用するために Caching Proxy を構成する方法については、ステップ 1. CBR を使用する Caching Proxy の構成を参照してください。
注:
Content Based Routing (CBR) コンポーネントは、64 ビットの JVM を実行しているプラットフォームでは使用できません。ただし、HP-UX ia64 の場合は例外です。HP-UX ia64 では、CBR コンポーネントは 32 ビットのアプリケーションとして実行されます。
Load Balancer の Dispatcher コンポーネントの CBR 転送方式を使用すれば、Caching Proxy を使用しなくてもコンテンツ・ベースのルーティングを提供することができます。詳しくは、
Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式) を参照してください。
CBR コンポーネント (または Dispatcher コンポーネントの CBR 転送方式) を使用する場合には、クライアントに次の利点を提供することができます。
CBR コンポーネントと Dispatcher コンポーネントの CBR 転送方式の比較
ユーザー・ネットワークで、完全なセキュア SSL トラフィック
(サーバーを介したクライアント) を必要とする場合、CBR コンポーネント
(Caching Proxy 付き) を使用する利点は、Content Based Routing を実行するため
に SSL 暗号機能を処理できることです。
完全なセキュア SSL 接続では、Dispatcher の CBR 転送は、クライアント要求の URL で
真の Content Based Routing を実行するための暗号機能を処理できないため、SSL ID 類縁性でのみ構成することができます。
HTTP トラフィックの場合、Dispatcher の CBR 転送方式を使用する利点は、クライアント要求に対する応答が
CBR コンポーネントよりも速いということです。また、Dispatcher の CBR 転送方式では、Caching Proxy のインストールおよび使用は不要です。
リモート管理
連結
- _ CBR は、ロード・バランシングを行っているサーバーと同じマシン上で実行することができます。
詳細については、連結サーバーの使用を参照してください。
Caching Proxy の複数のインスタンスと CBR
SSL 接続に対する Content Based Routing の指定
SSL トラフィックの Content Based Routing を許可する場合に、
サーバーの区分化
ルール・ベースのロード・バランシング
同じ Web アドレスに対して別々のサーバー・セットにクライアントを割り当てるには、CBR 構成に「ルール」を追加することができます。詳細については、ルール・ベースのロード・バランシングの構成を参照してください。
- _ 要求された URL のコンテンツに基づいて別々のサーバー・セットにクライアントを割り当てるには、要求コンテンツに基づくルールの使用を参照してください。
- _ クライアント・ソース IP アドレスに基づいて別々のサーバー・セットにクライアントを割り当てるには、クライアント IP アドレスに基づくルールの使用を参照してください。
- _ 時刻に基づいて別々のサーバー・セットにクライアントを割り当てるには、時刻に基づくルールの使用を参照してください。
- _ サイト・トラフィックに基づいて別々のサーバー・セットにクライアントを割り当てる場合に、
- _ サーバーのデフォルト・セット (「サイト・ビジー」に応答するサーバー、など) にオーバーフロー・トラフィックを割り当てるには、常に真であるルールの使用を参照してください。
- _ クライアントがオーバーフロー・サーバーに確実に「固執しない」ようにクライアント類縁性をオーバーライドするには、ポート類縁性のオーバーライドを参照してください。
サーバー類縁性のクライアント
- _ 複数の接続に対してクライアントが確実に同じサーバーに戻るようにするには、Load Balancer の類縁性機能の動作を参照してください。
- _ 何らかの理由 (保守など) で、クライアント・トラフィックを中断することなくサーバーをユーザーの構成から除去するには、『サーバー接続処理の静止』を参照しください。
- _ ユーザー Web サーバーによって作成された Cookie に依存しないで
複数の接続で類似したコンテンツを要求したときに、クライアントが同じサーバーに
確実に戻るようにするには、活動 Cookie 類縁性を参照してください。
- _ ユーザー Web サーバーによって作成された Cookie を使用して、複数の接続で類似したコンテンツを要求したときに、クライアントが同じサーバーに
確実に戻るようにするには、受動 cookie 類縁性を参照してください。
- _ 固有のコンテンツを各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックのロード・バランシングを行うには (複数マシン上のコンテンツの冗長なキャッシュを除去することによって、サイトのキャッシュ・サイズが増加します)、URI 類縁性を参照してください。
Dispatcher および CBR を使用したハイ・アベイラビリティー
バイナリー・ロギング
アラート
Site Selector コンポーネントの機能
Site Selector は、サーバーのグループ間でネーム・サービス要求のロード・バランシングを行います。
リモート管理
連結
- _ Site Selector は、ロード・バランシングを行っているサーバーと同じマシン上で実行することができ、追加の構成手順は不要です。
ハイ・アベイラビリティー
- _ ハイ・アベイラビリティーは、親ネーム・サーバーの適切な構成と
通常の DNS リカバリー・メソッドがあれば、複数の冗長な Site Selector を使用する
Domain Name System (DNS) 方法論を介して、継承によって使用可能です。
通常の DNS リカバリー・メソッドの例としては、照会の再送とゾーン転送の再試行があります。
- _ Site Selector との 2 層構成で Dispatcher を使用して、ユーザー・ネットワークで Single Point of Failure の制限を除去するには、Load Balancer でハイ・アベイラビリティーを実現する方法を参照してください。
サーバー類縁性のクライアント
- _ 複数のネーム・サーバーに対してクライアントが確実に同じサーバーを使用するようにするには、Load Balancer の類縁性機能の動作を参照してください。
- _ サーバー類縁性のクライアントが Time To Live (TTL) を設定する
標準 DNS メソッドを確実に使用するようにするには、TTL の考慮事項を参照してください。
ルール・ベースのロード・バランシング
ドメイン・ネームの解決で別々のサーバー・セットにクライアント要求を
割り当てるために、Site Selector 構成に「ルール」を追加することができます。詳細については、ルール・ベースのロード・バランシングの構成を参照してください。
- _ クライアント・ソース IP アドレスに基づいて別々のサーバー・セットにクライアントを割り当てるには、クライアント IP アドレスに基づくルールの使用を参照してください。
- _ 時刻に基づいて別々のサーバー・セットにクライアントを割り当てるには、時刻に基づくルールの使用を参照してください。
- _ サーバー・セットのメトリック・ロード値に基づいて別々のサーバー・セットにクライアントを割り当てるには、次を参照してください。
- _ サーバーのデフォルト・セット (「サイト・ビジー」に応答するサーバー、など) にオーバーフロー・トラフィックを割り当てるには、常に真であるルールの使用を参照してください。
広域ロード・バランシング
Site Selector は、ローカル・エリア・ネットワーク (LAN) または WAN (広域ネットワーク) の両方で実行できます。
WAN 環境の場合、
- _ 重み付きラウンドロビン選択メソッドを使用して、クライアント・ネーム・サーバー要求のロード・バランシングを行うには、追加の構成手順は不要です。
- _ 要求されたアプリケーションを提供するサーバー (宛先サーバー) に対するクライアント・ネーム・サーバー要求の
ネットワーク接近性を考慮するには、ネットワーク接近性機能の使用を参照してください。
アラート
Cisco CSS Controller コンポーネントの機能
注:
Cisco CSS Controller コンポーネントは、Load Balancer for IPv4 バージョン 8.0 と共に出荷されていますが、このコンポーネントは新しいハードウェアをサポートしない可能性があります。サポートされるハードウェアについては、前提条件ページ: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
Cisco CSS Controller は、Cisco スイッチのサーバー・ロード・バランシング機能を機能拡張して、より優れたアプリケーションおよびシステム認識を実現します。コントローラーは、より多くのアプリケーション依存およびシステム依存メトリックを使用して、サーバーの重みを動的に計算します。重みは、SNMP を使用してスイッチに指定されます。
クライアント要求の処理時に、スイッチは重みを使用して、サーバー負荷最適化および
耐障害性の向上を実現します。
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
リモート管理
連結
- _ Cisco CSS Controller は、ロード・バランシングを行っているサーバーと同じマシン上で
実行することができます。追加の構成手順は不要です。
ハイ・アベイラビリティー
バイナリー・ロギング
アラート
Nortel Alteon Controller コンポーネントの機能
注:
Nortel Alteon Controller コンポーネントは、Load Balancer for IPv4 と共に出荷されていますが、このコンポーネントは新しいハードウェアをサポートしない可能性があります。サポートされるハードウェアについては、前提条件ページ: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
Nortel Alteon Controller は、Nortel Alteon スイッチのサーバー・ロード・バランシング機能を機能拡張して、より優れたアプリケーションおよびシステム認識を実現します。
コントローラーは、より多くのアプリケーション依存およびシステム依存メトリックを使用して、サーバーの重みを動的に計算します。重みは、SNMP を使用してスイッチに指定されます。
クライアント要求の処理時に、スイッチは重みを使用して、サーバー負荷最適化および
耐障害性の向上を実現します。
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
リモート管理
連結
- _ Nortel Alteon Controller は、ロード・バランシングを行っているサーバー
と同じマシン上で実行することができます。追加の構成手順は不要です。
ハイ・アベイラビリティー
バイナリー・ロギング
アラート