バージョン 7.0
文書番号 GD88-6862-00
ご注意 |
---|
本書および本書で紹介する製品をご使用になる前に、付録 E. 特記事項に記載されている情報をお読みください。 |
第 1 版 (2008 年 6 月)
本書は、以下のプログラムに適用されます。
また、新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。
資料を注文する場合は、IBM 担当者または最寄りの IBM 営業所にご連絡ください。
(C) Copyright International Business Machines Corporation 2008. All rights reserved.
Content Based Routing (CBR) コンポーネント
Nortel Alteon Controller コンポーネント
本書は、AIX(R)、HP-UX、Linux(TM)、Solaris、および Windows(R) オペレーティング・システム用 IBM(R) WebSphere(R) Application Server Load Balancer の計画、インストール、構成、使用、およびトラブルシューティングの方法について説明します。 この製品は、以前は Edge Server Network Dispatcher、SecureWay(R) Network Dispatcher、eNetwork Dispatcher、および Interactive Network Dispatcher と呼ばれていました。
「Load Balancer 管理ガイド」は、オペレーティング・システムと インターネット・サービスの提供についてよく知っている、経験のあるネットワークおよびシステム管理者を対象として作成されています。 Load Balancer を事前に経験している必要はありません。
本書は、前のリリースの Load Balancer をサポートするためのものではありません。
Edge Components インフォメーション・センター Web サイトから、本書の HTML 形式と PDF 形式の現行バージョンにリンクしています。
Load Balancer の最新の更新については、Web サイトのサポート・ページと、Technote サイトにアクセスしてください。
これらの Web ページおよび関連 Web ページにアクセスするには、『関連資料および Web サイト』にリストされている URL を使用してください。
アクセシビリティー機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるように サポートします。 以下は、Load Balancer の主要なアクセシビリティー機能です。
IBM にお客様のご意見をお寄せください。本書または Edge Components に関するその他の資料についてお気付きの点がありましたら、次のようにしてください。
この部分では、Load Balancer およびそのコンポーネントの概説、使用可能な構成フィーチャーの概要説明、ハードウェア要件およびソフトウェア要件のリスト、およびインストール手順について記述します。この部には、以下の章があります。
この章では、Load Balancer の概要について説明します。この章には、以下のセクションが含まれています。
ユーザーのネットワーク管理に使用する機能を計画する上で役に立つ、Load Balancer の各コンポーネントで提供される構成機能の全体的なリストについては、『ネットワークの管理: 使用する Load Balancer 機能の決定』を参照してください。
Load Balancer とは、着信するクライアント要求を各サーバー間で分散するためのソフトウェア・ソリューションです。 これは、TCP/IP セッション要求をサーバー・グループ内の各サーバーに指図することによって、サーバーのパフォーマンスを高め、これによりすべてのサーバー間における要求を平衡化します。このロード・バランシングは、ユーザーや他のアプリケーションに透過的に行われます。Load Balancer は、e-mail サーバー、World Wide Web サーバー、分散並列データベース照会などのアプリケーションや、その他の TCP/IP アプリケーションに有効です。
Web サーバーで使用する場合、Load Balancer はユーザー・サイトの潜在能力を最大化するために、ピーク需要の問題に対して強力で、柔軟性があり、拡張が容易な解決策を提供します。 最大需要時にユーザーがサイトにアクセスできないような場合は、 Load Balancer を使用すると着信要求の処理に最適なサーバーが自動的に検出され、 顧客満足度と収益性が向上します。
Load Balancer は次の 5 つのコンポーネントから構成されており、これらの機能を別々または一緒に使用して、すぐれたロード・バランシングを提供します。
HTTP プロトコルの場合は、Dispatcher のコンテンツ・ベース・ルーティング機能を使用してクライアント要求の内容に基づいてロード・バランシングを実行することもできます。 指定されたルールに対して URL を突き合わせた結果に応じて、サーバーが選択されます。 Dispatcher のコンテンツ・ベース・ルーティング (CBR 転送方式) では、 Caching Proxy は必要とされません。
Dispatcher、CBR、Site Selector、Cisco CSS Controller、および Nortel Alteon Controller の各コンポーネントについて詳しくは、『Load Balancer のコンポーネントとは』を参照してください。
グローバル・インターネットに接続されたユーザーおよびネットワークの数は急速に増えています。この増加現象によって受け入れ規模の問題が生じ、 人気サイトへのユーザー・アクセスが制限されることがあります。
現在、ネットワーク管理者は、アクセスの最大化を図るためにいろいろなメソッドを使用しています。それらメソッドの中に は、最初に選択した処理が遅かったり応答しなかったりした場合に、別のサーバーを無作為に選択できるようにするものもあります。 この方法は面倒で、いらいらさせ、非効率です。この他に標準ラウンドロビン・メソッドもあり、この場合は、ドメイン・ネーム・サーバーが要求処理のためのサーバーを順番に選択します。この方法は前にあげた方法よりも優れてはいますが、サーバー作業負荷を考慮に入れないでトラフィックを 転送するという理由から、やはり非効率です。さらに、サーバーが失敗しても、要求は引き続きそこへ送信されます。
Load Balancer はさらに強力な解決策が必要であるというニーズから作成されました。 これは、従来の競合する解決策に比べ、数多くの利点を備えています。
クライアント要求の増加に伴い、サーバーを動的に追加して、何十、何百ものサーバーで 1 日当たり何千万という要求に対するサポートを提供することができます。
ロード・バランシングは、標準ラウンドロビン・メソッドの場合に頻繁に起こるホット・スポットを最小化することにより、各サーバー・グループがそれぞれのハードウェアを最適使用するようにします。
Load Balancer は標準の TCP/IP または UDP/IP プロトコルを使用します。 既存のネットワークに物理的な変更を加えることなく、そのネットワークにこれを追加できます。これのインストールと構成は簡単です。
簡単な MAC レベル転送方式を使用すると、Dispatcher コンポーネントは、クライアントからサーバーへのインバウンド・フローだけをモニターします。サーバーからクライアントへのアウトバウンド・フローをモニターする必要はありません。このために他の方法に比べてアプリケーションに対する影響を大幅に軽減し、ネットワーク・パフォーマンスを向上させることができます。
Dispatcher、Cisco CSS Controller、および Nortel Alteon Controller の各コンポーネントは組み込みのハイ・アベイラビリティーを提供します。そのため、プライマリー・サーバー・マシンに障害が発生した場合には、いつでもロード・バランシングを引き継げるようになっている バックアップ・マシンを使用します。 サーバーの 1 つに障害が発生した場合、要求へのサービス提供は別のサーバーによって継続されます。 このプロセスによってサーバーが Single Point of Failure ではなくなるため、 サイトのハイ・アベイラビリティーが実現されます。
詳しくは、『Load Balancer でハイ・アベイラビリティーを実現する方法』を参照してください。
CBR コンポーネントは、Caching Proxy と連携し、要求したコンテンツに基づいて特定のサーバーへの HTTP 要求および HTTPS (SSL) 要求を代行することができます。例えば、要求において URL のディレクトリー部分にストリング "/cgi-bin/" が含まれて、サーバー名がローカル・サーバーである場合は、CGI 要求を処理するために特に割り振られている一連のサーバーで最適なサーバーに CBR は要求を送信できます。
Dispatcher コンポーネントも Content Based Routing を提供しますが、これは Caching Proxy をインストールする必要がありません。Dispatcher コンポーネントの Content Based Routing はパケットを受け取るとカーネル中で実行されるので、CBR コンポーネントより 高速 の Content Based Routing を提供できます。Dispatcher コンポーネントは、HTTP (「コンテンツ」タイプ・ルールを使用) および HTTPS (SSL セッション ID 類縁性を使用) に対してコンテンツ・ベース・ルーティングを実行します。
Dispatcher コンポーネントにはハイ・アベイラビリティー機能が組み込まれており、ユーザーのネットワークから Single Point of Failure となる Dispatcher を除去します。 この機能では、2 番目の Dispatcher マシンを使用して、メイン・マシン (プライマリー・マシン) をモニターし、プライマリー・マシンに障害が発生した場合にいつでもロード・バランシングのタスクを引き継げるように待機します。 また、Dispatcher コンポーネントでは相互ハイ・アベイラビリティーが提供されているため、2 つのマシンが相互にプライマリーとセカンダリー (バックアップ) の両方になることができます。 『ハイ・アベイラビリティーの構成』を参照してください。
CBR を備えた複数のサーバー間で、Dispatcher マシンがトラフィックを ロード・バランシングする、2 層の構成を使用する場合は、 CBR コンポーネントを使用して一定レベルのハイ・アベイラビリティーを達成することもできます。
コントローラーには、Single Point of Failure としてのコントローラーを除去するハイ・アベイラビリティー機能があります。 1 つのマシン上のコントローラーがプライマリーとして構成され、別のマシン上のコントローラーがバックアップとして構成されることが あります。バックアップは、プライマリーをモニターし、プライマリーが失敗した場合には、サーバーの重みをスイッチに指定するタスクを引き継げるように待機します。 詳しくは、ハイ・アベイラビリティーを参照してください。
この章では、Load Balancer の各コンポーネントの概要について説明します。この章には、以下のセクションが含まれています。
Load Balancer の各コンポーネントで提供される構成機能の全体的なリスト、およびユーザーのネットワーク管理に使用する機能を計画する上で役に立つ情報については、『ネットワークの管理: 使用する Load Balancer 機能の決定』を参照してください。
Load Balancer には 5 つのコンポーネント、Dispatcher、Content Based Routing (CBR)、Site Selector、Cisco CSS Controller、および Nortel Alteon Controller があります。 Load Balancer は、ユーザーのサイト構成に応じて、コンポーネントをそれぞれ別個に使用したり組み合わせて使用したりできる柔軟性があります。 このセクションでは、次のコンポーネントの概説を説明します。
Dispatcher コンポーネントは、ロード・バランシングと管理ソフトウェアを固有に組み合わせることにより、各サーバー全体のトラフィックのバランスを取ります。 また、Dispatcher は障害が発生したサーバーを検出し、それをう回してトラフィックを転送することもできます。 Dispatcher は、HTTP、FTP、SSL、SMTP、NNTP、IMAP、POP3、Telnet、SIP、 およびその他の TCP またはステートレス UDP ベースのアプリケーションをサポートします。
Dispatcher マシンに送信されたすべてのクライアント要求は、動的に設定される重みに従って最適なサーバーに送信されます。 これらの重みに対してデフォルト値を使用することもできますし、構成プロセス時にこれらの値を変更することもできます。
Dispatcher は、次の 3 つの転送方式 (ポートに指定される) を提供します。
Dispatcher コンポーネントは、大規模で拡張が容易なサーバー・ネットワークを安定的、効率的に管理する上でのキーです。 Dispatcher により、多数の個別サーバーをリンクして単一に見える仮想サーバーにできます。 サイトは単一の IP アドレスとして表示されます。Dispatcher 機能は、ドメイン・ネーム・サーバーとは独立して機能します。すなわち、すべての要求は Dispatcher マシンの IP アドレスに送信されます。
Dispatcher は、トラフィック負荷の平衡化における明確な利点をクラスター・サーバーにもたらすため、サイトの管理を安定的かつ効率的に行うことができるになります。
図 1. Dispatcher を使用してローカル・サーバーを管理するサイトを物理的に示した例
図 1 は、イーサネット・ネットワーク構成を使用するサイトの物理表現を示しています。 Dispatcher マシンは、ネットワークに物理的な変更を加えることなくインストールできます。 MAC 転送方式を使用する場合には、クライアント要求が Dispatcher によって最適なサーバーに送信され、次にその応答が Dispatcher の介入なしにサーバーからクライアントへ直接送信されます。
図 2. Dispatcher および Metric Server を使用してサーバーを管理するサイトの例
図 2 は、すべてのサーバーが 1 つのローカル・ネットワーク上にあるサイトを示しています。 Dispatcher コンポーネントは要求の転送に使用され、Metric Server は Dispatcher マシンへのシステム負荷情報の提供に使用されます。
この例では、Metric Server デーモンが各バックエンド・サーバーに インストールされています。Metric Server は、Dispatcher コンポーネントまたはその他の Load Balancer コンポーネントと組み合わせて使用できます。
図 3. Dispatcher を使用してローカル・サーバーとリモート・サーバーを管理するサイトの例
Dispatcher の広域サポートによって、ローカル・サーバーとリモート・サーバー (異なるサブネット上のサーバー) の両方を使用できます。 図 3 は、あるローカルの Dispatcher (Dispatcher 1) がすべての要求に対するエントリー・ポイントとして機能する構成を示しています。 その管理対象のローカル・サーバー (ServerA、 ServerB、ServerC) およびリモートの Dispatcher (Dispatcher 2) に要求が分散されます。 リモート側では、そのローカル・サーバー (ServerG、ServerH、ServerI) にロード・バランシングが実行されます。
Dispatcher の NAT 転送方式を使用するとき、または GRE サポートを使用するときには、リモート・サイト (ここでは ServerD、ServerE、および ServerF があります) で Dispatcher を使用せずに Dispatcher の広域ポートを実行できます。詳しくは、『Dispatcher の NAT/NAPT (nat 転送方式)』および『GRE (総称経路指定カプセル化) サポート』を参照してください。
CBR は Caching Proxy と連携して指定された HTTP または HTTPS (SSL) サーバーに対するクライアント要求のプロキシーとして機能します。 これによって、キャッシュ処理の詳細を操作し、ネットワーク帯域幅の要件が低くても、より高速に Web 文書を検索することができます。 CBR および Caching Proxy は、 指定のルール・タイプを使用して HTTP 要求を調べます。
CBR を使用すれば、要求内容の正規表現一致に基づいて要求を処理する一組のサーバーを指定できます。 CBR では各要求タイプごとに複数のサーバーを指定することができるため、 最適のクライアント応答を得るために要求のロード・バランシングを行うことができます。CBR は、サーバー・セット内の 1 つのサーバーがいつ失敗したかを検出して、そのサーバーへの要求の経路指定を停止することもできます。 CBR コンポーネントによって使用されるロード・バランシング・アルゴリズムは、Dispatcher コンポーネントによって使用される実証済みのアルゴリズムと同じです。
要求が Caching Proxy によって受信されると、CBR コンポーネントに定義されたルールに照合して検査されます。 一致すると、そのルールに関連する 1 つのサーバーが要求処理のために選択されます。 次に Caching Proxy は通常の処理を実行して、選択されたサーバーへの要求をプロキシー処理します。
CBR は、ハイ・アベイラビリティー、SNMP サブエージェント、広域、およびその他の構成コマンドのいくつかを除いて、Dispatcher と同じ機能を持っています。
CBR でクライアント要求のロード・バランシングを開始するには、Caching Proxy が実行されている必要があります。
図 4. CBR を使用してローカル・サーバーを管理するサイトの例
図 4 は、CBR を使用してローカル・サーバーからのコンテンツを代行するサイトの論理的な表現を示しています。 CBR コンポーネントは、Caching Proxy を使用して URL のコンテンツに基づいてクライアント要求 (HTTP または HTTPS) をサーバーに転送します。
Site Selector は、ドメイン・ネーム・システム内の他のネーム・サーバーとの組み合わせで機能するネーム・サーバーの 1 つとして作動して、収集される測定値および重みを使用してサーバーのグループ間でのロード・バランシングを行います。 クライアント要求に使用されるドメイン・ネームに基づいて、サーバー・グループ全体でトラフィックのロード・バランシングを実行するサイト構成を作成できます。
クライアントが、ネットワーク内部のネーム・サーバーに対してドメイン・ネームを解決する要求を出します。ネーム・サーバーはその要求を Site Selector マシンに転送します。すると Site Selector は、そのドメイン・ネームをサイト名に基づいて構成されたいずれかのサーバーの IP アドレスに解決します。Site Selector は選択したサーバーの IP アドレスをネーム・サーバーに戻します。ネーム・サーバーは、その IP アドレスをクライアントに戻します。
Metric Server は、Load Balancer のシステム・モニター・コンポーネントであり、構成内のロード・バランシング対象の各サーバーにインストールされている必要があります。 Metric Server を使用して、Site Selector はサーバー上でアクティビティー・レベルをモニターし、サーバーの負荷が最小のときを検出し、障害の起きたサーバーを検出することができます。負荷とは、サーバーが作動している忙しさの程度を示す尺度です。システム・メトリック・スクリプト・ファイルをカスタマイズすることにより、負荷を測るために使用する測定タイプを制御できます。 アクセス頻度、ユーザー総数、アクセス・タイプ (例えば、短時間の照会、長時間の照会、 または CPU 集中の負荷) などの要因を考慮に入れて、自分の環境に適合するように Site Selector を構成できます。
図 5. Site Selector および Metric Server を使用してローカル・サーバーおよびリモート・サーバーを管理するサイトの例
図 5 は、要求への応答に Site Selector コンポーネントが使用されるサイトを示しています。 Server1、Server2、および Server3 はローカルです。Server4、Server5、および Server6 はリモートです。
クライアントが、クライアント・ネーム・サーバーに対してドメイン・ネームを解決する要求を出します。 クライアント・ネーム・サーバーは、DNS 経由で要求を Site Selector マシンに転送します (パス 1)。 すると Site Selector が、ドメイン・ネームをいずれかのサーバーの IP アドレスに解決します。Site Selector は選択したサーバーの IP アドレスをクライアント・ネーム・サーバーに戻します。ネーム・サーバーは、その IP アドレスをクライアントに戻します。
クライアントは、サーバーの IP アドレスを受け取った後、アプリケーションの要求を 選択されたサーバーに直接に経路指定します (パス 2)。
Cisco CSS Controller は、Cisco の CSS 11000 シリーズ・スイッチと連携する補完的なソリューションです。 この統合ソリューションでは、CSS 11000 シリーズの堅固なパケット転送およびコンテンツ経路指定機能と Load Balancer の高度の認識アルゴリズムを組み合わせて、サービス (バックエンド・サーバー・アプリケーションまたはデータベース) の負荷情報および可用性を判別します。 Cisco CSS Controller 機能では、Load Balancer の重み計算アルゴリズム、標準 advisor、カスタム advisor、および Metric Server を使用して、サービスのメトリック、正常性、および負荷を判別します。 この情報を使用して、最適なサービス選択、負荷の最適化、および耐障害性について Cisco CSS Switch に送信されるサービスの重みが Cisco CSS Controller によって生成されます。
Cisco CSS Controller では、以下のような多数の基準がトラッキングされます。
Cisco CSS Switch が Cisco CSS Controller なしでコンテンツ提供サービスの正常性を判別する場合は、コンテンツ要求またはその他のネットワーク測定の応答時間を使用します。 Cisco CSS Controller が使用される場合、これらのアクティビティーは Cisco CSS Switch から Cisco CSS Controller にオフロードされます。 Cisco CSS Controller はコンテンツを提供するサービスの重みまたは能力に影響し、サービスの可用性の増加または減少に応じてそのサービスを適切に活動化または中断します。
Cisco CSS Controller:
図 6. Cisco CSS Controller および Metric Server を使用してローカル・サービスを管理するサイトの例
Cisco CSS Controller は Cisco CSS Switch と連携して、高度なアプリケーション認識、耐障害性、およびサービス負荷最適化にワイヤー・スピードのコンテンツ交換を統合した「双方に最適な」ソリューションを提供します。 Cisco CSS Controller は、Cisco CSS Switch と IBM WebSphere Application Server Load Balancer の間の総括的補足ソリューションの一部です。
Nortel Alteon Controller は Nortel Alteon ファミリーの Web スイッチと連携して、スイッチのパケット転送速度と能力に、サーバーの重みを判別する Load Balancer の高度な認識アルゴリズムを組み合わせた補完的なソリューションを提供します。
Nortel Alteon Controller では、サービスのデプロイに使用される、アプリケーションの可用性および負荷のよりインテリジェントなアプリケーション認識の評価を実行する機能があるカスタム advisor を開発できます。
Metric Server は、CPU およびメモリーの使用率情報、およびカスタムのシステム・ロード測定用のフレームワークなどのシステム負荷情報を提供します。
Nortel Alteon Controller は、Nortel Alteon Web Switches によるロード・バランシング対象のサーバーに対する重みを判別するために、以下に示すような、多数のタイプのメトリック・データを収集します。
Nortel Alteon Controller は SNMP を使用して、スイッチと通信します。 構成、状態、および接続の情報は、スイッチから取得されます。サーバーの重みは、コントローラーによって計算されると、スイッチ上に設定されます。スイッチは、コントローラーによって設定された重みを使用して、サービスに対するクライアント要求を処理する最適のサーバーを選択します。
図 7. Nortel Alteon Controller を使用してローカル・サーバーを管理するサイトの例
ブラウザー、リモート GUI、またはリモート・コマンド行インターフェースを使用しているコントローラーを管理できます。
Nortel Alteon Controller は Nortel Alteon ファミリーの Web スイッチと連携して、高度なアプリケーション認識、耐障害性、およびサーバー負荷最適化にワイヤー・スピードのパケット交換を統合した、「双方に最適な」ソリュー ションを提供します。 Nortel Alteon Controller は、Nortel Alteon ファミリー の Web スイッチおよび IBM WebSphere の補完的ソリューションの一部です。
この章では、ユーザー・ネットワークを管理する上で使用する機能を決定できるように、Load Balancer コンポーネントの構成機能がリストされています。
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
Dispatcher は、HTTP、FTP、SSL、 SMTP、NNTP、IMAP、POP3、Telnet、SIP、その他の TCP、 またはステートレス UDP ベースのアプリケーションに対して ユーザー・サーバー間のロード・バランシングをサポートします。
_ Load Balancer が常駐するマシンとは別のマシンから Load Balancer 構成を実行するには、Load Balancer のリモート管理を参照してください。
_ ロード・バランシングを実行している Web サーバーと同じマシン上で Dispatcher を実行するには、『連結サーバーの使用』を参照してください。
_ ユーザー・ネットワークでの Single Point of Failure の制限を除去する目的で Dispatcher を使用するには、『単純なハイ・アベイラビリティー』および『相互ハイ・アベイラビリティー』を参照してください。
SSL (HTTPS) トラフィックをロード・バランシング時に、
_ 複数の接続に対してクライアントが確実に同じ SSL サーバーを使用するようにするには、『Load Balancer の類縁性機能の動作』を参照してください。
_ HTTP および SSL トラフィックに対してクライアントが確実に同じサーバーを使用するようにするには、『ポート間類縁性』を参照してください。
_ 複数の接続に対してクライアントが確実に同じサーバーを使用するようにするには、『Load Balancer の類縁性機能の動作』を参照してください。
_ 複数の接続に対してクライアントのグループが確実に同じサーバーを使用するようにするには、『類縁性アドレス・マスク (stickymask)』を参照してください。
_ 何らかの理由 (保守など) で、クライアント・トラフィックを中断することなくサーバーをユーザーの構成から除去するには、『サーバー接続静止の処理』を参照しください。
同じ Web アドレスに対して別々のサーバー・セットにクライアントを割り当てるには、Dispatcher 構成に「ルール」を追加することができます。詳しくは、 『ルール・ベースのロード・バランシングの構成』を参照してください。
_ クライアント・ソース IP アドレスに基づいて別々のサーバー・セットにクライアントを割り当てるには、『クライアント IP アドレスに基づくルールの使用』を参照してください。
_ クライアント・ポートに基づいて別々のサーバー・セットにクライアントを割り当てるには、『クライアント・ポートに基づくルールの使用』を参照してください。
_ 時刻に基づいて別々のサーバー・セットにクライアントを割り当てるには、『時刻に基づくルールの使用』を参照してください。
_ ネットワーク・パケットの Type of Service (TOS) ビットに基づいてサーバーにクライアントを割り当てるには、『Type of Service (TOS) を基にしたルールの使用法』を参照してください。
_ サイト・トラフィックに基づいて別々のサーバー・セットにクライアントを割り当てる場合に、
_ 秒当たりの接続数を使用するには、『1 秒当たりの接続数に基づくルールの使用』を参照してください。
_ 活動中の総接続数を使用するには、『活動状態の総接続数に基づくルールの使用』を参照してください。
_ 別々の Web アドレスに対する帯域幅の予約と共用については、『予約済み帯域幅および共用帯域幅に基づくルールの使用』を参照してください。
_ それぞれのサーバーのセットごとのトラフィックの適正な測定の確保については、『ルールのサーバー評価オプション』を参照してください。
_ サーバーのデフォルト・セット (「サイト・ビジー」に応答するサーバーなど) にオーバーフロー・トラフィックを割り当てるには、『常に真であるルールの使用』を参照してください。
_ クライアントがオーバーフロー・サーバーに「固執しない」ようにクライアント類縁性をオーバーライドするには、『ポート類縁性のオーバーライド』を参照してください。
クライアント要求の SSL ID に基づいて、SSL クライアントが同じ SSL サーバーに戻るようにするには、
_ HTTPS (SSL) に関するセクションを参照してください。
クライアント要求の URL コンテンツの突き合わせに基づくルールを使用して、別々のサーバー・セットに HTTP クライアントを割り当てる場合について詳しくは、『Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)』および『要求コンテンツに基づくルールの使用』を参照してください。
_ 特定の URL とそのサービス・アプリケーションを区別するには、『サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバー』を参照してください。
_ ユーザーの Web サーバーによって作成された Cookie を使用して、複数の接続で類似したコンテンツを要求した場合に、クライアントが同じサーバーに確実に戻るようにするには、『受動 cookie 類縁性』を参照してください。
_ 固有のコンテンツを各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックのロード・バランシングを行うには (複数マシン上のコンテンツの冗長なキャッシュを除去することによって、サイトのキャッシュ・サイズが増加します)、『URI 類縁性』を参照してください。
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 サポートの構成』および『GRE (総称経路指定カプセル化) サポート』を参照してください。
_ Dispatcher の NAT 転送方式を使用してリモート・サーバーのロード・バランシングを行うには、『Dispatcher の NAT/NAPT (NAT 転送方式)』を参照してください。
_ 1 つの Web アドレスに対して同じマシン上の複数のサーバー・デーモンでロード・バランシングを実行するには (各デーモンが固有のポートを listen する)、『Dispatcher の NAT/NAPT (NAT 転送方式)』を参照してください。
_ Dispatcher トラフィックをクライアント・トラフィックと 別のネットワークに配置するには (外部ネットワークでの競合を削減して パフォーマンスを向上させる目的で)、『プライベート・ネットワーク構成の使用』を参照してください。
_ 複数の Web アドレスを単一の構成に結合するには、『ワイルドカード・クラスターを使用したサーバー構成の結合』を参照してください。
_ ファイアウォールのロード・バランシングを行うには、『ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング』を参照してください。
_ すべての宛先ポートに対するトラフィックを送信するには、『ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信』を参照してください。
_ 可能性のある「サービス妨害」攻撃を検出するには、『サービス妨害攻撃の検出』を参照してください。
_ サーバー・トラフィックを分析するには、『バイナリー・ログを使用したサーバー統計の分析』を参照してください。
_ サーバーがアップまたはダウンとマークされる場合にアラートを生成するには、『アラートまたはレコード・サーバー障害を生成するスクリプトの使用』を参照してください。
CBR は、ロード・バランシングと WebSphere Application Server の Caching Proxy を統合して、指定の HTTP または HTTPS (SSL) サーバーに対するクライアント要求を代行します。CBR を使用するには、Caching Proxy が同じマシン上にインストールおよび構成される必要があります。CBR を使用するために Caching Proxy を構成する方法について詳しくは、『ステップ 1. CBR を使用する Caching Proxy の構成』を参照してください。
CBR コンポーネント (または Dispatcher コンポーネントの CBR 転送方式) を使用する場合には、クライアントに次の利点を提供することができます。
_ 異なるタイプのコンテンツのクライアント要求に対してサーバーのセットにロード・バランシングを実行する。 (『別々のコンテンツ・タイプに対する要求のロード・バランシング』を参照してください。)
_ ユーザー・サイトのコンテンツを Web サーバー間で最適に分割して、応答時間を向上させる。 (『応答時間を改善するためのサイト・コンテンツの分割』を参照してください。)
_ 複数のサーバーをそれぞれのタイプのコンテンツに割り当てることを可能にして、サーバーの障害時に中断しないクライアント・トラフィックを確保する。 (『Web サーバー・コンテンツのバックアップの提供』を参照してください。)
ユーザー・ネットワークで、完全なセキュア 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 のインストールおよび使用は不要です。
_ Load Balancer が常駐するマシンとは別のマシンから Load Balancer 構成を実行するには、Load Balancer のリモート管理を参照してください。
_ CBR は、ロード・バランシングを実行しているサーバーと同じマシン上で実行できます。 詳しくは、『連結サーバーの使用』を参照してください。
_ 複数の Caching Proxy プロセスを使用して CPU 使用率を改善するには、『CPU 使用率を改善するための複数 Caching Proxy 処理の使用』を参照してください。
SSL トラフィックの Content Based Routing を許可する場合に、
_ 両方のサイド (クライアントからプロキシーおよびプロキシーからクライアント) でのセキュア接続の使用については、『完全なセキュア (SSL) 接続でのロード・バランシング』を参照してください。
_ クライアントからプロキシーのサイドのみでのセキュア接続の使用については、『SSL 中のクライアント - プロキシーおよび HTTP 中のプロキシー - サーバーのロード・バランシング』を参照してください。
_ 特定の URL とそのサービス・アプリケーションを区別するには、『サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバー』を参照してください。
同じ Web アドレスに対して別々のサーバー・セットにクライアントを割り当てるには、CBR 構成に「ルール」を追加することができます。詳しくは、 『ルール・ベースのロード・バランシングの構成』を参照してください。
_ 要求された URL のコンテンツに基づいて別々のサーバー・セットにクライアントを割り当てるには、『要求コンテンツに基づくルールの使用』を参照してください。
_ クライアント・ソース IP アドレスに基づいて別々のサーバー・セットにクライアントを割り当てるには、『クライアント IP アドレスに基づくルールの使用』を参照してください。
_ 時刻に基づいて別々のサーバー・セットにクライアントを割り当てるには、『時刻に基づくルールの使用』を参照してください。
_ サイト・トラフィックに基づいて別々のサーバー・セットにクライアントを割り当てる場合に、
秒当たりの接続数を使用するには、『1 秒当たりの接続数に基づくルールの使用』を参照してください。
活動中の総接続数を使用するには、『活動状態の総接続数に基づくルールの使用』を参照してください。
_ サーバーのデフォルト・セット (「サイト・ビジー」に応答するサーバーなど) にオーバーフロー・トラフィックを割り当てるには、『常に真であるルールの使用』を参照してください。
_ クライアントがオーバーフロー・サーバーに「固執しない」ようにクライアント類縁性をオーバーライドするには、『ポート類縁性のオーバーライド』を参照してください。
_ 複数の接続に対してクライアントが確実に同じサーバーに戻るようにするには、『Load Balancer の類縁性機能の動作』を参照してください。
_ 何らかの理由 (保守など) で、クライアント・トラフィックを中断することなくサーバーをユーザーの構成から除去するには、『サーバー接続静止の処理』を参照しください。
_ ユーザー Web サーバーによって作成された Cookie に依存しないで複数の接続で類似したコンテンツを要求したときに、 クライアントが同じサーバーに確実に戻るようにするには、『活動 Cookie 類縁性』を参照してください。
_ ユーザーの Web サーバーによって作成された Cookie を使用して、複数の接続で類似したコンテンツを要求した場合に、クライアントが同じサーバーに確実に戻るようにするには、『受動 cookie 類縁性』を参照してください。
_ 固有のコンテンツを各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックのロード・バランシングを行うには (複数マシン上のコンテンツの冗長なキャッシュを除去することによって、サイトのキャッシュ・サイズが増加します)、『URI 類縁性』を参照してください。
_ CBR との 2 層構成で Dispatcher を使用して、ユーザー・ネットワークでの Single Point of Failure の制限を除去するには、『Load Balancer でハイ・アベイラビリティーを実現する方法』を参照しください。
_ サーバー・トラフィックを分析するには、『バイナリー・ログを使用したサーバー統計の分析』を参照してください。
_ サーバーがアップまたはダウンとマークされる場合にアラートを生成するには、『アラートまたはレコード・サーバー障害を生成するスクリプトの使用』を参照してください。
Site Selector は、サーバーのグループ間でネーム・サービス要求のロード・バランシングを行います。
_ Load Balancer が常駐するマシンとは別のマシンから Load Balancer 構成を実行するには、Load Balancer のリモート管理を参照してください。
_ 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 スイッチのサーバー・ロード・バランシング機能を拡張して、より優れたアプリケーションおよびシステム認識を実現します。 コントローラーは、より多くのアプリケーション依存およびシステム依存メトリックを使用して、サーバーの重みを動的に計算します。重みは、SNMP を使用してスイッチに指定されます。 クライアント要求の処理時に、スイッチは重みを使用して、サーバー負荷最適化および 耐障害性の向上を実現します。
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
_ Load Balancer が常駐するマシンとは別のマシンから Load Balancer 構成を実行するには、Load Balancer のリモート管理を参照してください。
_ Cisco CSS Controller は、ロード・バランシングを行っているサーバーと同じマシン上で実行することが可能であり、追加の構成手順は不要です。
_ ユーザー・ネットワークでの Single Point of Failure の制限を除去するため、Cisco CSS Switch および Cisco CSS Controller の両方にハイ・アベイラビリティー機能があります。 スイッチについては、ハイ・アベイラビリティー機能は、CSS 冗長度プロトコルの使用が可能です。 Cisco CSS Controller の場合は、2 つのコントローラーのホット・スタンバイ構成を可能にする、独自のプロトコルを使用します。
ハイ・アベイラビリティーの構成について詳しくは、『ハイ・アベイラビリティー』を参照してください。
_ サーバー・トラフィックを分析するには、『バイナリー・ログを使用したサーバー統計の分析』を参照してください。
_ サーバーがアップまたはダウンとマークされる場合にアラートを生成するには、『アラートまたはレコード・サーバー障害を生成するスクリプトの使用』を参照してください。
Nortel Alteon Controller は、Nortel Alteon スイッチのサーバー・ロード・バランシング機能を拡張して、より優れたアプリケーションおよびシステム認識を実現します。 コントローラーは、より多くのアプリケーション依存およびシステム依存メトリックを使用して、サーバーの重みを動的に計算します。重みは、SNMP を使用してスイッチに指定されます。 クライアント要求の処理時に、スイッチは重みを使用して、サーバー負荷最適化および 耐障害性の向上を実現します。
サーバー間のロード・バランシングを最適化して「適切な」サーバーが確実に選択されるようにするには、次を参照してください。
_ Load Balancer が常駐するマシンとは別のマシンから Load Balancer 構成を実行するには、Load Balancer のリモート管理を参照してください。
_ Nortel Alteon Controller は、ロード・バランシングを行っているサーバーと同じマシン上で実行することが可能であり、追加の構成手順は不要です。
_ ユーザー・ネットワークでの Single Point of Failure の制限を除去するため、Nortel Alteon Web Switch および Nortel Alteon Controller の両方にハイ・アベイラビリティー機能があります。 スイッチについて、ハイ・アベイラビリティーは、サーバーとの接続およびサービスに対する 冗長性プロトコルの使用が可能です。Nortel Alteon Controller には、2 つのコントローラーのホット・スタンバイ構成を可能にする所有プロトコルを使用する ハイ・アベイラビリティーが提供されています。
ハイ・アベイラビリティーの構成について詳しくは、『ハイ・アベイラビリティー』を参照してください。
_ サーバー・トラフィックを分析するには、『バイナリー・ログを使用したサーバー統計の分析』を参照してください。
_ サーバーがアップまたはダウンとマークされる場合にアラートを生成するには、『アラートまたはレコード・サーバー障害を生成するスクリプトの使用』を参照してください。
本章では、システム・パッケージ化ツールを使用した Load Balancer インストール、 およびサポートされるすべてのオペレーティング・システムでの要件について説明します。
製品セットアップ・プログラムを使用したインストールの説明については、Edge Components 概念、計画とインストール を参照してください。
Java 2 SDK は、すべてのプラットフォームで Load Balancer と一緒に自動的にインストールされます。
以前のバージョンの Load Balancer からマイグレーションする場合、 またはオペレーティング・システムを再インストールする場合は、インストールに先立ち 、Load Balancer の既存の構成ファイルやスクリプト・ファイルを保管しておきます。
インストールのタイプにもよりますが、このセクションに記載されている Load Balancer コンポーネント・パッケージが すべて提供されるとは限りません。
ハードウェアおよびソフトウェアの要件 (サポートされるブラウザーを含む) については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
表 1 には、Load Balancer の installp イメージ、およびシステムのパッケージ・インストール・ツールを使用してインストールする場合に推奨される順番がリストされています。
ベース | ibmlb.base.rte |
管理 (メッセージ付き) |
|
デバイス・ドライバー | ibmlb.lb.driver |
ライセンス | ibmlb.lb.license |
Load Balancer コンポーネント (メッセージ付き) |
|
文書 (メッセージ付き) |
|
Metric Server | ibmlb.ms.rte |
ここで、component には disp (Dispatcher)、CBR (CBR)、ss (Site Selector)、cco (Cisco CSS Controller) または nal (Nortel Alteon Controller) が入ります。 インストールしたいコンポーネントを任意で選択してください。
language には下記が入ります。
文書パッケージに入っているのは英語の文書のみです。Load Balancer の文書セットの翻訳は、 Web サイト www.ibm.com/software/webservers/appserv/ecinfocenter.html にあります。
旧バージョンがインストールされている場合は、現行バージョンをインストールする前に その旧バージョンをアンインストールしてください。 最初に、すべての executor およびすべてのサーバーが停止していることを確認してください。 その後、製品全体をアンインストールするには、installp -u ibmlb (または前の名前、例えば intnd) と入力します。 特定のファイル・セットをアンインストールするには、パッケージ名を指定する代わりに、ファイル・セットを明確にリストします。
製品のインストール時に、以下の項目の任意のものをインストールするか、 すべてをインストールするかを選択できます。
以下のステップに従って、Load Balancer を AIX システムにインストールします。
SMIT の使用:
コマンドが完了したら、「完了 (Done)」を押して、「終了 (Exit)」メニューから「Smit 終了 (Exit Smit)」を選択するか、F12 を押します。SMITTY を使用している場合は、F10 を押して プログラムを終了します。
コマンド行の使用:
CD からインストールする場合は、以下のコマンドを入力して CD をマウントしなければなりません。
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
以下の表を参照して、必要な Load Balancer パッケージを AIX システムにインストールする場合に入力するコマンドを判別してください。
ベース | installp -acXgd device ibmlb.base.rte |
管理 (メッセージ付き) | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
デバイス・ドライバー | installp -acXgd device ibmlb.lb.driver |
ライセンス | installp -acXgd device ibmlb.lb.license |
Load Balancer コンポーネント (メッセージ付き)。 Dispatcher、CBR、Site Selector、Cisco CSS Controller、および Nortel Alteon Controller を含む。 | installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
文書 (メッセージ付き) | installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd device ibmlb.ms.rte |
ここで、device は以下のとおりです。
インストール (APPLY) する Load Balancer の各パーツに対して、サマリーの結果の列に SUCCESS が含まれていることを確認してください。 インストールしたいパーツがすべて正常に適用されていないかぎり、続行しないでください。
installp -ld device
ここで、device は以下のとおりです。
CD をアンマウントするには、以下を入力します。
unmount /cdrom
lslpp -h | grep ibmlb
フル・プロダクトをインストールした場合は、このコマンドは以下を戻します。
ibmlb.base.rte ibmlb.admin.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<component>.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.language.admin ibmlb.msg.en_US.doc ibmlb.msg.language.lb
Load Balancer には、次のようなインストール・パスがあります。
リモート・メソッド呼び出し (RMI) を使用した Load Balancer のリモート管理の場合には、 クライアントに管理、ベース、コンポーネント、およびライセンスの各パッケージをインストールする必要があります。 RMI について詳しくは、『リモート・メソッド呼び出し (RMI)』を参照してください。
ハードウェアおよびソフトウェアの要件 (サポートされるブラウザーを含む) については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
このセクションでは、製品 CD を使用して Load Balancer を HP-UX システムにインストールする方法について説明します。
インストール手順を開始する前に、ソフトウェア・インストールのためのルート権限を持っていることを確認してください。
旧バージョンがインストールされている場合は、そのバージョンをアンインストールしてから現行バージョンをインストールしなければなりません。最初に、executor およびサーバーの両方を停止させます。次に、Load Balancer をアンインストールするには、『パッケージ・アンインストールの説明』を参照してください。
表 3 には、Load Balancer のインストール・パッケージ名、およびシステムのパッケージ・インストール・ツールを使用してパッケージをインストールする場合に推奨される順番がリストされています。
表 3. Load Balancer 用の HP-UX パッケージのインストールの詳細
パッケージの説明 | HP-UX パッケージ名 |
ベース | ibmlb.base |
管理およびメッセージ | ibmlb.admin ibmlb.nlv-lang |
Load Balancer ライセンス | ibmlb.lic |
Load Balancer コンポーネント | ibmlb.component |
文書 | ibmlb.doc |
Metric Server | ibmlb.ms |
注:
|
この作業を行うために必要なステップについて、以下で順を追って詳細に説明します。
su - root パスワード: パスワード
swinstall -s /source package_name
ここで、source は パッケージの入っているディレクトリーの絶対パス、package_name は パッケージの名前です。
CD のルートからインストールする場合、 次のコマンドでは Load Balancer のベース・パッケージ (ibmlb.base) のみが インストールされます。
swinstall -s /source ibmlb.base
Load Balancer のすべてのパッケージを インストールするには、CD のルートからインストールする場合、 次のコマンドを発行します。
swinstall -s /source ibmlb
swlist コマンドを発行して、インストールしたパッケージをすべてリストします。例えば、以下のようになります。
swlist -l fileset ibmlb
swremove コマンドを使用して、パッケージをアンインストールします。インストールしたときとは逆順で、パッケージを除去してください。例えば、以下のコマンドを発行します。
swremove ibmlb
個々のパッケージ (例えば Dispatcher コンポーネント) をアンイ ンストールするには、次のコマンドを発行します。
swremove ibmlb.disp
ハードウェアおよびソフトウェアの要件 (サポートされるブラウザーを含む) については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
このセクションでは、製品 CD を使用して Load Balancer を Linux システムにインストールする方法について説明します。
インストール手順を開始する前に、ソフトウェア・インストールのためのルート権限を持っていることを確認してください。
旧バージョンがインストールされている場合は、現行バージョンをインストールする前に その旧バージョンをアンインストールする必要があります。 最初に、すべての executor およびすべてのサーバーが停止していることを確認してください。 その後、製品全体をアンインストールするために、rpm -e pkgname と入力します。 アンインストールする際、パッケージのインストールに使用した順序を逆に行って、管理パッケージが最後にアンインストールされるようにします。
Load Balancer をインストールするには、以下を実行します。
インストール・イメージは、 eLBLX-version:tar.z の形式のファイルです。
以下は、RPM インストール可能パッケージのリストです。
ここで、
文書パッケージに入っているのは英語の文書のみです。Load Balancer の文書セットの翻訳は、 Web サイト www.ibm.com/software/webservers/appserv/ecinfocenter.html にあります。
パッケージをインストールするコマンドは、RPM ファイルが入っているディレクトリーから発行する必要があります。コマンド rpm -i package.rpm を発行して、各パッケージをインストールします。
Red Hat Linux システム: Red Hat Linux で既知の問題があるため、_db* RPM ファイルも削除する必要があります。 削除しないとエラーが発生します。
rpm -qa | grep ibmlb
全製品をインストールすると、以下のようなリストが作成されます。
リモート・メソッド呼び出し (RMI) を使用した Load Balancer のリモート管理の場合には、 クライアントに管理、ベース、コンポーネント、およびライセンスの各パッケージをインストールする必要があります。 RMI について詳しくは、『リモート・メソッド呼び出し (RMI)』を参照してください。
ハードウェアおよびソフトウェアの要件 (サポートされるブラウザーを含む) については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
このセクションでは、製品 CD を使用して Load Balancer を Solaris システムにインストールする方法について説明します。
インストール手順を開始する前に、ソフトウェア・インストールのためのルート権限を持っていることを確認してください。
旧バージョンがインストールされている場合は、そのバージョンをアンインストールしてから現行バージョンをインストールしなければなりません。最初に、すべての executor およびサーバーを停止させます。次に、Load Balancer をアンインストールするには、 pkgrm pkgname と入力します。
Load Balancer をインストールするには、以下を実行します。
コマンド・プロンプトで、pkgadd -d pathname と入力します。 ここで、pathname は、CD-ROM ドライブのデバイス名またはこのパッケージが入っているハード・ディスクのディレクトリーです。 例えば、pkgadd -d /cdrom/cdrom0/。
以下に示すのは、表示されるパッケージのリストと、 それらをインストールする場合に推奨される順番です。
文書パッケージ (ibmlbdoc) に含まれているのは英語の文書のみです。 Load Balancer の文書セットの翻訳は、 Web サイト www.ibm.com/software/webservers/appserv/ecinfocenter.html にあります。
すべてのパッケージをインストールする場合は、「all」とだけ入力して、return キーを押します。 いくつかのコンポーネントをインストールする場合は、インストールするパッケージに対応する名前をスペースまたはコンマで区切って入力し、return キーを押します。既存のディレクトリーまたはファイルに対する 許可を変更するように促されます。単に return キーを押すか、または「yes」と応答します。前提パッケージをインストールする必要があります (それは、前提順ではなく、アルファベット順にインストールされるため)。 「all」と応答した場合は、すべてのプロンプトに対して「yes」と応答すると、インストールが正常に完了します。
Dispatcher コンポーネントのみを 文書および Metric Server と一緒にインストールする場合、 パッケージ ibmlbbase、ibmlbadm、ibmlblic、ibmdisp、ibmlbdoc、 および ibmlbms をインストールする必要があります。
リモート・メソッド呼び出し (RMI) を使用した Load Balancer のリモート管理の場合には、 クライアントに管理、ベース、コンポーネント、およびライセンスの各パッケージをインストールする必要があります。 RMI について詳しくは、『リモート・メソッド呼び出し (RMI)』を参照してください。
Load Balancer のインストール・パスは次のとおりです。
ハードウェアおよびソフトウェアの要件 (サポートされるブラウザーを含む) については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
このセクションでは、製品 CD を使用して Load Balancer を Windows システムにインストールする方法について説明します。
インストールするパッケージを選択することができます。
リモート・メソッド呼び出し (RMI) を使用した Load Balancer のリモート管理の場合には、 クライアントに管理、ライセンス、およびコンポーネントの各パッケージをインストールする必要があります。 RMI について詳しくは、『リモート・メソッド呼び出し (RMI)』を参照してください。
制約事項: Windows バージョン の Load Balancer は IBM Firewall と同じマシンにはインストールできません。
インストール手順を開始する前に、管理者としてか、または管理者の権限を持ったユーザーとしてログインしていることを確認してください。
旧バージョンがインストールされている場合は、現行バージョンをインストールする前に その旧バージョンをアンインストールする必要があります。 「プログラムの追加/削除」を使用してアンインストールするには、以下のようにします。
Load Balancer をインストールするには、以下を実行します。
E:\setup
Load Balancer には、次のようなインストール・パスがあります。
更新の取得では、以下のメディアで AIX、HP-UX、Linux、Solaris オペレーティング・システム、または Microsoft Windows オペレーティング・システム用の Edge Components のフィックスパックを取得できます。
サポート対象のオペレーティング・システムについて詳しくは、IBM ポート・サイトにある「WebSphere Application Server detailed system requirements」を参照してください。
Edge Components のリフレッシュ・パックまたはフィックスパックへのリンクは、IBM サポート・サイトの「Recommended downloads for WebSphere Application Server」にあります。
リフレッシュ・パックまたはフィックスパックをインストールする前に、アップグレードするバージョンよりも前の既存のバージョンの Load Balancer を停止してアンインストールしてください。
dscontrol executor stop
Load Balancer の executor は、dsserver が停止しても実行されている場合があります。 dsserver が実行されていないことを示すメッセージが表示された場合は、dsserver を開始してコマンドを再発行します。
dsserver stop
表 4. Load Balancer をアンインストールするシステム固有のコマンド
Load Balancer をアンインストールするシステム固有のコマンド | |
---|---|
プラットフォーム | コマンド |
AIX | 以下のコマンドを使用して、Load Balancer の製品パッケージをすべてアンインストールします。
installp -u ibmlb |
HP-UX | 以下のコマンドを使用して、Load Balancer の製品パッケージをすべてアンインストールします。
swremove ibmlb |
Linux |
|
Solaris |
|
Load Balancer がインストールされていない場合は、リフレッシュ・パックまたはフィックスパックをインストールする前に、Load Balancer のライセンス・ファイルである lb70Full.LIC のみをインストールする必要があります。 ライセンスは、Load Balancer のライセンス・パッケージをインストールすることにより取得できます。
フィックスパックまたはリフレッシュ・パックをインストールするには、以下のようにします。
表 5. リフレッシュ・パックまたはフィックスパックをインストールするシステム固有のコマンド
リフレッシュ・パックまたはフィックスパックをインストールするシステム固有のコマンド | |
---|---|
システム | コマンド |
AIX |
|
HP-UX |
swinstall -s /source package_name ここで、source はパッケージの存在場所のディレクトリーであり、package_name はパッケージの名前です。 例えば、現行ディレクトリーから基本パッケージをインストールするには、次のコマンドを発行します。 swinstall -s /lb ibmlb.base |
Linux |
rpm -iv package_name ここで、package_name はパッケージの名前です。 例えば、次のコマンドでは、パッケージが現行ディレクトリーにある場合に Load Balancer のすべてのパッケージをインストールします。 rpm -iv ibmlb*.rpm
|
Solaris |
pkgadd -d pathname package_name ここで、pathname はパッケージの存在場所のディレクトリーであり、package_name はパッケージの名前です。 例えば、現行ディレクトリーから管理パッケージをインストールするには、次のコマンドを発行します。 pkgadd -d . ibmlbadm |
この表には、Edge Components で提供されるすべてのパッケージ、およびその必要なインストール順序がリストされています。 リフレッシュ・パックまたはフィックスパックに含まれているパッケージは、以下の表に示されている順序に従ってインストールしてください。
パッケージのリスト | |
インストール済みコンポーネント | この順序でパッケージを更新 (一般名でリスト) |
|
|
Edge Components 文書 | doc-lang |
Edge Components のセットアップ・プログラムを使用して以下のようにアップグレードします。
ほとんどのコンポーネントの場合、リフレッシュ・パックまたはフィックスパックが除去されると、構成ファイルが oldfiles/component ディレクトリーに保存されます。 再インストールしたバージョンの製品でこれらの構成ファイルを使用し、 パッチ適用以前のバージョンにおいてパッチ適用の構成を維持できます。 Load Balancer コンポーネントの場合は、構成ファイルを手動で保存して、パッチ適用後の構成を維持する必要があります。
この部では、クイック・スタート構成や計画の考慮事項に関する情報を提供し、Load Balancer の Dispatcher コンポーネントの構成方法について説明します。 この部には、以下の章があります。
このクイック・スタートの例では、Dispatcher コンポーネントの mac 転送方式を使用して 3 つのローカル接続ワークステーションを構成して、2 つのサーバー間の Web トラフィックのロード・バランスを取る方法を示します。 この構成は、本質的に他の任意の TCP またはステートレス UDP アプリケーションのトラフィックを平衡化する場合と同じです。
MAC 転送方式はデフォルトの転送方式で、これにより、Dispatcher がサーバーに対して 受信要求のロード・バランスを取り、サーバーがクライアントに応答を直接戻します。 Dispatcher の MAC 転送方式について詳しくは、『Dispatcher の MAC レベル・ルーティング (MAC 転送方式)』を参照してください。
このクイック・スタートの例の場合、3 つのワークステーションと 4 つの IP アドレスが必要です。 ワークステーションの 1 つは Dispatcher マシンで、 他の 2 つは Web サーバーです。 各 Web サーバーには IP アドレスが 1 つずつ必要です。 Dispatcher ワークステーションには、非転送先アドレス (NFA)、および Web サイトにアクセスするクライアントに指定するクラスター・アドレス (ロード・バランシング対象のアドレス) という 2 つの アドレスが必要です。
ワークステーション | 名前 | IP アドレス |
---|---|---|
1 | server1.Intersplashx.com | 9.47.47.101 |
2 | server2.Intersplashx.com | 9.47.47.102 |
3 | server3.Intersplashx.com | 9.47.47.103 |
ネットマスク = 255.255.255.0 |
各ワークステーションには、標準のイーサネット・ネットワーク・インターフェース・カードが 1 つだけ装備されています。
Name= www.Intersplashx.com IP=9.47.47.104
server2.Intersplashx.com および server3.Intersplashx.com にある ループバック・インターフェースに www.Intersplashx.com の別名を追加してください。
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.255
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
これで、2 つの Web サーバー・ワークステーションに必要なすべての構成ステップが完了しました。
Dispatcher の場合は、コマンド行、構成ウィザード、またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。
コマンド行を使用する場合は、以下のステップに従ってください。
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:server2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:server3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
これで、サーバーのパフォーマンスに基づいて Dispatcher がロード・バランシングを実行するようになります。
dscontrol advisor start http 80
これで Dispatcher はクライアント要求が障害のある Web サーバーに送信されないようにします。
ローカル接続サーバーの基本構成はこれで完了です。
構成が機能するかどうかを調べるためにテストを行います。
Dispatcher GUI の使用について詳しくは、『GUI』および『付録 A. GUI: 一般的な説明』を参照してください。
構成ウィザードの使用について詳しくは、『構成ウィザードによる構成』を参照してください。
ユーザー・サイトをサポートするように Load Balancer を構成するには、多くの方法があります。すべての顧客が接続されているサイトに対してホスト名が 1 つしかない場合は、サーバーの単一クラスターを定義できます。これらのサーバーごとに、Load Balancer が通信に使用するポートを構成します。 『図 9』を参照してください。
図 9. 単一クラスターと 2 つのポートで構成された Dispatcher の例
Dispatcher コンポーネントのこの例では、1 つのクラスターが www.productworks.com に定義されています。このクラスターには、HTTP 用のポート 80 および SSL 用のポート 443 の 2 つのポートがあります。http://www.productworks.com (ポート 80) に 要求を出すクライアントは、https://www.productworks.com (ポート 443) に要求を出すクライアントとは 異なるサーバーを呼び出します。
サポートされる各プロトコルごとに専用の多数のサーバーがある非常に大きなサイトの場合は、Load Balancer の構成には別の方法が適している可能性があります。 この場合、『図 10』に示されるように、多数のサーバーではなく、単一のポートで、プロトコルごとにクラスターを定義することが必要になる場合があります。
図 10. 2 つのクラスターにそれぞれ 1 つのポートを構成した Dispatcher の例
Dispatcher コンポーネントのこの例では、ポート 80 (HTTP) 用の www.productworks.com およびポート 443 (SSL) 用の www.testworks.com という 2 つのクラスターが定義されています。
複数の会社または部門 (それぞれが別々の URL を使用してサイトに入ってくる) に対してコンテンツのホスティングを行うサイトの場合は、Load Balancer を構成する 3 番目の方法が必要になる場合があります。 この場合は、『図 11』に示されるように、それぞれの会社または部門ごとにクラスターを定義し、その URL で接続を受け取る任意のポートを定義する必要があります。
図 11. 2 つのクラスターにそれぞれ 2 つのポートを構成した Dispatcher の例
Dispatcher コンポーネントのこの例では、www.productworks.com および www.testworks.com の各サイトに対して 2 つのクラスターがポート 80 (HTTP の場合) とポート 23 (Telnet の場合) で定義されています。
この章では、Dispatcher コンポーネントのインストールおよび構成を行う前に、ネットワーク計画担当者が考慮する必要がある事項について説明します。
この章には、以下のセクションが含まれています。
manager の使用はオプションです。ただし、manager を使用しない場合は、現行サーバーの重みに基づいて 重み付きラウンドロビン・スケジューリングを使用してロード・バランシングが行われ、advisor は使用できません。
また、Dispatcher では、プロトコル固有の情報を交換しない advisor (DB2 サーバーの正常性を報告する DB2(R) advisor、およびサーバーが ping に応答するかどうかを報告する ping advisor など) も提供されます。 advisor の完全なリストについては、『advisor のリスト』を参照してください。
また、ユーザー独自の advisor を作成することもできます (『カスタム (カスタマイズ可能) advisor の作成』を参照)。
advisor の使用はオプションですが、使用することをお勧めします。
Dispatcher の 3 つの主要な機能 (executor、manager、および advisor) は相互に対話して、サーバー間で受信要求を平衡化およびディスパッチします。 ロード・バランシング要求とともに、executor は新規の接続、活動中の接続、および終了状態の接続の数をモニターします。また、executor は完了またはリセットした接続のガーベッジ・コレクションも実行し、この情報を manager に提供します。
manager は、executor、advisor、およびシステム・モニター・プログラム (例えば Metric Server) から情報を収集します。 manager は、受け取った情報に基づいて、各ポートでのサーバー・マシンの重み付けの方法を調整し、新規接続の平衡化で使用する新規の重み値を executor に指定します。
advisor は、割り当てられたポート上の各サーバーをモニターしてサーバーの応答時間と使用可能度を決定してから、この情報を manager に提供します。advisor も、サーバーが起動しているかいないかをモニターします。manager および advisor がないと、executor は、現行サーバーの重み付けに基づいてラウンドロビン・スケジューリングを行います。
Dispatcher を使用して、ポート・レベルで指定された MAC 転送、NAT/NAPT 転送、または CBR (Content Based Routing) 転送という 3 つの転送方式のいずれかを選択できます。
Dispatcher の MAC 転送方式 (デフォルトの転送方式) を使用して、Dispatcher は選択したサーバーへの受信要求のロード・バランシングを行い、 そのサーバーは Dispatcher の介入なしに 直接 クライアントに応答を戻します。この転送方式を使用すると、Dispatcher がモニターするのはクライアントからサーバーへのインバウンド・フローだけです。サーバーからクライアントへのアウトバウンド・フローをモニターする必要はありません。このためにアプリケーションに対する影響を大幅に軽減し、ネットワーク・パフォーマンスを向上させることができます。
転送方式は、dscontrol port add cluster:port method value コマンドを使用してポートを追加するときに選択できます。デフォルト転送方式値は mac です。メソッド・パラメーターを指定できるのは、ポートが追加されるときだけです。一度ポートを追加すると、転送方式の設定は変更できません。詳しくは、『dscontrol port -- ポートの構成』を参照してください。
Linux の制約事項: Linux システムでは、 ARP を使用してハードウェア・アドレスを IP アドレスに公示する、ホスト・ベースのモデルを使用しています。 このモデルは、Load Balancer の MAC 転送方式における、 バックエンド・サーバーまたはハイ・アベイラビリティー・コロケーション・サーバーの要件に合致していません。 Linux システムの動作を変更して Load Balancer の MAC 転送方式と互換になるようにする複数の方法が説明されている『Load Balancer の MAC 転送を使用する場合に代替を別名割り当てする Linux ループバック』を参照してください。
zSeries または S/390 サーバーを使用する場合の Linux の制限: オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する場合には、 いくつかの制限があります。 使用可能な回避策については、『問題: Linux で、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の Dispatcher 構成の制限』を参照してください。
Dispatcher のネットワーク・アドレス変換 (NAT) またはネットワーク・アドレス・ポート変換 (NAPT) 機能を使用すると、ロード・バランシングされたサーバーがローカル接続ネットワーク上に置かれるという制限がなくなります。サーバーをリモート・ロケーションに置きたいときには、GRE/WAN カプセル化技法ではなく、NAT 転送方式技法を使用してください。また、NAPT 機能を使用して、各ロード・バランシングされたサーバー・マシン (各デーモンが固有のポートを listen しています) 上に常駐している複数のサーバー・デーモンをアクセスできます。
複数のデーモンを使用して 1 つのサーバーを構成する方法には、次の 2 つがあります。
このアプリケーションは、上位レベルのアプリケーション・プロトコル (例えば HTTP、SSL、IMAP、POP3、 NNTP、SMTP、Telnet など) と適切に連動します。
制限:
Dispatcher マシンには、nfa、クラスター、およびリターン・アドレスの 3 つの IP アドレスが必要になります。NAT/NAPT 実装するには、以下を実行してください (『Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップ』も参照)。
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
これはクライアント要求の宛先ポート番号 (Dispatcher 用) を、Dispatcher がクライアント要求の ロード・バランシングを行うために使用するサーバーのポート番号にマップします。 Mapport により、Load Balancer は 1 つのポートでクライアント要求を受信し、その要求をサーバー・マシン上の別のポートに送信できます。 mapport を使用して、複数のサーバー・デーモンを実行している可能性があるサーバー・マシンに対する クライアント要求をロード・バランシングできます。 mapport のデフォルトは、クライアント要求の宛先ポート番号です。
リターン・アドレスは Dispatcher マシン上で構成される固有のアドレスまたはホスト名です。 サーバーに対するクライアント要求のロード・バランシングを行うときに、Dispatcher はリターン・アドレスをその送信元アドレスとして使用します。これによって、サーバーはパケットを直接クライアントに送信せずに、Dispatcher マシンに戻すようになります。(次に Dispatcher は IP パケットをクライアントに転送します。) サーバーの追加時には、リターン・アドレス値を指定する必要があります。リターン・アドレスは、サーバーを除去してもう一度追加しない限り変更できません。リターン・アドレスは、クラスター、サーバー、または NFA アドレスと同じにはできません。
NAT または CBR 転送方式を使用する場合は、Load Balancer とバックエンド・サーバー間の通信用のリターン・アドレスを定義する必要があります。 Load Balancer がバックエンド・サーバーとの間でアクティブに保持できる接続の数は、定義されたリターン・アドレスの数によって制限されます。 Load Balancer では、リターン・アドレスとサーバーの組み合わせではなく、リターン・アドレスのみに基づいてポートを使用します。 使用可能なポートがすべて使用中である場合、以降の接続は失敗します。 ビジー状態の環境においては、 複数のリターン・アドレスを使用して、使用可能なポートが不足しないようにします。
リモート・サーバーへのルーターのアドレス。これがローカル接続サーバーである場合は、 サーバー・アドレスを入力します。ただし、そのサーバーが Load Balancer と同一マシン上にある場合を除きます。 その場合は、ルーターの実アドレスを引き続き使用してください。
Dispatcher コンポーネントにより、Caching Proxy を使用しなくても HTTP (「コンテンツ」タイプ・ルールを使用) および HTTPS (SSL セッション ID 類縁性を使用) に対してコンテンツ・ベース・ルーティングを実行できます。 HTTP および HTTPS トラフィックの場合、Dispatcher コンポーネントの CBR 転送方式は、Caching Proxy が必要な CBR コンポーネントよりも高速のコンテンツ・ベース・ルーティングを提供できます。
HTTP の場合: Dispatcher のコンテンツ・ベース・ルーティングにおけるサーバー選択は、URL または HTTP ヘッダーのコンテンツに基づきます。 これは「コンテンツ」タイプ・ルールを使用して構成されています。コンテンツ・ルールの構成時には、ルールに検索ストリング "pattern" と一連のサーバーを指定します。新規受信要求の処理時には、このルールは指定されたストリングをクライアントの URL またはクライアント要求で指定された HTTP ヘッダーと比較します。
Dispatcher がクライアント要求でそのストリングを検出すると、Dispatcher は要求をルール内のいずれかのサーバーに転送します。次に Dispatcher は応答データをサーバーからクライアントに中継します ("CBR" 転送方式)。
Dispatcher がクライアント要求でそのストリングを検出しない場合は、Dispatcher はルール内の一連のサーバーからサーバーを選択 しません。
HTTPS (SSL) の場合: Dispatcher の Content Based Routing は、クライアント要求の SSL ID セッション・フィールドを基にしてロード・バランシングされます。 SSL では、クライアント要求には前のセッションの SSL セッション ID が入っていて、サーバーは前の SSL 接続のキャッシュを保守します。Dispatcher の SSL ID セッション類縁性により、クライアントおよびサーバーはサーバーとの前の接続のセキュリティー・パラメーターを使用して新規接続を確立できます。 SSL セキュリティー・パラメーター (共有鍵や暗号化アルゴリズムなど) の再ネゴシエーションを除去することによって、サーバーは CPU サイクルを節約して、クライアントへの応答がより高速になります。 SSL セッション ID 類縁性を使用可能にするには、ポートに指定されるプロトコル・タイプを SSL にして、ポートの stickytime をゼロ以外の値に設定する必要があります。stickytime が経過すると、クライアントは前のとは異なる別のサーバーに送信します。
Dispatcher マシンには、nfa、クラスター、およびリターン・アドレスの 3 つの IP アドレスが必要になります。Dispatcher のコンテンツ・ベース・ルーティング実装するには、以下のようにします (『Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップ』も参照)。
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
ここで、pattern はコンテンツ・タイプ・ルールに使用するパターンを指定します。コンテンツ・ルール・タイプについて詳しくは、『要求コンテンツに基づくルールの使用』を参照してください。 pattern の有効な式について詳しくは、『付録 B. コンテンツ・ルール (パターン) 構文』を参照してください。
図 12. Dispatcher の NAT または CBR 転送方式の使用例
Dispatcher マシンには、少なくとも 3 つの IP アドレスが必要です。 『図 12』において、Dispatcher の NAT または CBR 転送方式の最小構成に必要なステップは、以下のとおりです。
1.executor を開始します。 dscontrol executor start 2.クライアント・ゲートウェイを定義します。 dscontrol executor set clientgateway 1.2.3.5 NOTE: サブネットにローカル・ルーターが無い場合、IP 転送を行なうように マシンを構成し、それを clientgateway として使用します。 ご使用のオペレーティング・システムの資料を参照し、IP 転送を有効にする 方法を確認してください。 3.クラスター・アドレスを定義します。 dscontrol cluster add 1.2.3.44 4.クラスター・アドレスを構成します。 dscontrol executor configure 1.2.3.44 5.NAT または CBR の方式でポートを定義します。 dscontrol port add 1.2.3.44:80 method nat または dscontrol port add 1.2.3.44:80 method cbr protocol http 6. Load Balancer の別名リターン・アドレスを構成します (イーサネット・カード 0 を使用)。 注: Linux システムでは、連結したマシンで NAT 転送を使用する場合、 リターン・アドレスの別名を指定する必要はありません。 dscontrol executor configure 10.10.10.99 または ifconfig コマンドを使用します (Linux または UNIX の場合のみ): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7.バックエンド・サーバーを定義します。 dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
クライアント・ゲートウェイ (1.2.3.5) は Load Balancer とクライアントとの間の ルーター 1 のアドレスです。 ルーター (10.10.10.6) は Load Balancer とバックエンド・サーバーとの間の ルーター 2 のアドレスです。 クライアント・ゲートウェイまたはルーター 2 のアドレスがはっきりとわからない場合は、クライアント (またはサーバー) アドレスを指定して traceroute プログラムを使用することで ルーター・アドレスを判別することができます。 このプログラムの正確な構文は、使用するオペレーティング・システムによって異なります。 このプログラムの詳細については、ご使用のオペレーティング・システムの文書を参照してください。
サーバーが Load Balancer と同じサブネットにある場合 (つまり、traceroute を使用したときに、ルーターが戻されない場合)、ルーター・アドレスとしてサーバー・アドレスを入力してください。 ただし、サーバーが Load Balancer と同一マシン上にある場合は、 サーバー・アドレスの代わりに、ルーター・フィールドにルーター・アドレスを 入力する必要があります。 ルーター・アドレスは、ステップ 7 で Load Balancer マシンの "server add" コマンドに使用されたアドレスです。
サーバーの区分化で、特定の URL とその固有のアプリケーションをさらに区別できます。 例えば、1 つの Web サーバーは JSP ページ、HTML ページ、GIF ファイル、データベース要求などを提供できます。現在では、Load Balancer は、1 つのクラスターおよびポート固有のサーバーをいくつかの論理サーバーに区分化する機能を提供しています。 これにより、マシン上の特定サービスについて、サーブレット・エンジンまたはデータベース要求が高速で実行中か、あるいは全く実行中でないかを検出することをアドバイスできます。
サーバーの区分化によって、Load Balancer は、例えば、HTML サービスがページを高速で提供中であるが、データベース接続はダウンしていることなどを検出できます。 これにより、サーバー全体の重み単独でではなく、よりきめ細かなサービス固有の作業負荷を基にして負荷を分散できます。
サーバー区分化は、HTTP および HTTPS advisor とともに使用すると便利です。 例えば、HTML、GIF、および JSP ページを処理する HTML サーバーがあり、ポート 80 でそのサーバーを (追加することによって) 定義した場合、HTTP サーバー全体に対して負荷値を 1 つのみ受け取ります。 これは、GIF サービスがサーバーで機能していない可能性があるため、誤解を招く恐れがあります。 Dispatcher は、引き続き GIF ページをサーバーに転送しますが、クライアントではタイムアウトまたは障害が発生します。
このポートでサーバーを 3 回 (ServerHTML、ServerGIF、ServerJSP など) 定義し、論理サーバーごとに別のストリングを使用して サーバー advisorrequest パラメーターを定義した場合、サーバー上の特定のサービスの状態を照会することができます。 ServerHTML、ServerGIF、および ServerJSP は、1 つの物理サーバーから 区分化された 3 つの論理サーバーを表します。 ServerJSP では、advisorrequest ストリングを定義して、JSP ページを処理する マシン上のサービスを照会できます。 ServerGIF では、advisorrequest ストリングを定義して GIF サービスを照会できます。 また、ServerHTML では、advisorrequest を定義して HTML サービスを照会できます。 このため、GIF サービスを照会するための advisorrequest からクライアントが 応答を取得しなかった場合、Dispatcher はその論理サーバー (ServerGIF) を ダウンとしてマークしますが、他の 2 つの論理サーバーは正常である可能性があります。 Dispatcher は、GIF を物理サーバーに転送しなくなりますが、引き続き JSP および HTML 要求をサーバーに送ることは可能です。
advisorrequest パラメーターについて詳しくは、『要求および応答 (URL) オプションによる HTTP または HTTPS advisor の構成』を参照してください。
Dispatcher 構成では、cluster:port:server の階層を使用して物理サーバーまたは論理サーバーを表現できます。 このサーバーは、シンボル名または IP アドレス形式のいずれかのマシン (物理サーバー) の固有 IP アドレスとすることができます。または、区分化されたサーバーを表すようにこのサーバーを定義する場合は、dscontrol server add コマンドの address パラメーターで物理サーバーの解決可能なサーバー・アドレスを指定する必要があります。 詳しくは、dscontrol server -- サーバーの構成を参照してください。
以下は、さまざまなタイプの要求を処理するために、物理サーバーを論理サーバーに区分化している例です。
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
この例では、サーバー 1.1.1.2 は、"A" (HTML 要求の処理) と "B" (GIF 要求の処理) という 2 つの論理サーバーに区分化されています。 サーバー 1.1.1.3 は "C" (HTML 要求の処理) と "D" (JSP 要求の処理) という 2 つの論理サーバーに区分化されています。 サーバー 1.1.1.4 は "E" (GIF 要求の処理) と "F" (JSP 要求の処理) という 2 つの論理サーバーに区分されています。
図 13. 単純なハイ・アベイラビリティーを使用した Dispatcher の例
ハイ・アベイラビリティー機能では、2 番目の Dispatcher マシンが使用されます。最初の Dispatcher マシンは、単一 Dispatcher 構成の場合と同様に、すべてのクライアント・トラフィックに対して ロード・バランシングを実行します。 2 番目の Dispatcher マシンは、最初のマシンの「正常性」をモニターし、最初の Dispatcher マシンの失敗を検出した場合に、ロード・バランシングのタスクを引き継ぎます。
この 2 つのマシンには、それぞれ特定の役割、つまり、プライマリー または バックアップ のいずれかが割り当てられます。プライマリー・マシンは、処理の進行とともに接続データをバックアップ・マシンに送信します。プライマリー・マシンが 活動状態 (ロード・バランシングを行っている) の間は、バックアップは 待機状態 になり、必要な場合には継続的に更新されていつでも引き継ぎできる状態になっています。
この 2 つのマシンの間の通信セッションは、heartbeat と呼ばれます。heartbeat により、それぞれのマシンが相手の「状態」をモニターできます。
バックアップ・マシンが活動マシンの失敗を検出すると、後を引き継いでロード・バランシングを開始します。この時点で 2 つのマシンの 状況 が反転します。つまり、バックアップ・マシンが 活動状態 になり、プライマリー・マシンが 待機状態 になります。
ハイ・アベイラビリティーの構成では、プライマリー・マシンとバックアップ・マシンの両方が同一の構成で同じサブネット上になければなりません。
ハイ・アベイラビリティーの構成については、『ハイ・アベイラビリティー』を参照してください。
図 14. 相互ハイ・アベイラビリティーを使用した Dispatcher の例
相互ハイ・アベイラビリティー機能では、2 つの Dispatcher マシンが使用されます。両方のマシンがクライアント・トラフィックのロード・バランシングを能動的に実行し、互いにバックアップを行います。単純なハイ・アベイラビリティーの構成では、1 つのマシンだけがロード・バランシングを実行します。相互ハイ・アベイラビリティーの構成では、両方のマシンがクライアント・トラフィックの部分のロード・バランシングを行います。
相互ハイ・アベイラビリティーの場合には、クライアント・トラフィックは、クラスター・アドレス・ベースで各 Dispatcher マシンに割り当てられます。各クラスターは、そのプライマリー Dispatcher の NFA (非転送先アドレス) を使用して構成されます。プライマリー Dispatcher マシンは通常、そのクラスターのロード・バランシングを実行します。障害が発生した場合に、他方のマシンが自己のクラスターおよび障害が発生した Dispatcher のクラスターの両方に対してロード・バランシングを実行します。
共用「クラスター・セット A」および共用「クラスター・セット B」の相互ハイ・アベイラビリティーの説明については、『図 14』を参照してください。 各 Dispatcher は、そのプライマリー・クラスターのパケットをアクティブに経路指定できます。いずれかの Dispatcher に障害が起きてそのプライマリー・クラスターのパケットをアクティブに経路指定できなくなると、他の Dispatcher がそのバックアップ・クラスターのパケットの経路指定を受け継ぎます。
ハイ・アベイラビリティーおよび相互ハイ・アベイラビリティーの構成については、『ハイ・アベイラビリティー』を参照してください。
この章のステップを実行するに前に、『Dispatcher の計画』を参照してください。 この章では、Load Balancer の Dispatcher コンポーネントの基本構成を作成する方法について説明します。
この表の構成ステップを始める前に、Dispatcher マシンとすべてのサーバー・マシンをネットワークに接続し、有効な IP アドレスが設定され、相互に ping できるようにしてください。
タスク | 説明 | 関連情報 |
---|---|---|
Dispatcher マシンをセットアップする。 |
ロード・バランシング構成をセットアップします。 | Dispatcher マシンのセットアップ |
ロード・バランシング対象のマシンをセットアップする | ループバック・デバイスに別名割り当てし、エクストラ経路をチェックし、エクストラ経路を削除します。 | ロード・バランシングのためのサーバー・マシンのセットアップ |
Dispatcher の構成には、以下のように 4 つの基本的な方法があります。
これは、Dispatcher を構成する最も直接的な方法です。 コマンド・パラメーター値は、英字で入力する必要があります。 唯一の例外は、ホスト名 (クラスター、サーバー、およびハイ・アベイラビリティー・コマンドで使用) およびファイル名 (ファイル・コマンドで使用) です。
コマンド行から Dispatcher を開始するには、次のようにします。
パラメーターの固有文字を入力することで、dscontrol コマンド・パラメーターの最小化バージョンを使用できます。例えば、file save コマンドに関するヘルプを表示するには、dscontrol help file の代わりに dscontrol he f と入力することができます。
コマンド行インターフェースを始動するには、dscontrol を実行して、dscontrol コマンド・プロンプトを表示します。
コマンド行インターフェースを終了するには、exit または quit を実行します。
構成スクリプト・ファイルに Dispatcher を構成するコマンドを入力して、それらを一緒に実行できます。 『サンプルの Load Balancer 構成ファイル』を参照してください。
dscontrol file appendload myscript
dscontrol file newload myscript
現在の構成をスクリプト・ファイル (例えば savescript) に保管するには、次のコマンドを実行します。
dscontrol file save savescript
このコマンドは、構成スクリプト・ファイルを ...ibm/edge/lb/servers/configurations/dispatcher ディレクトリーに保管します。
グラフィカル・ユーザー・インターフェース (GUI) の一般的な説明と例については、図 41を参照してください。
GUI を開始するには、以下のステップに従ってください。
dsserver
GUI から Dispatcher コンポーネントを構成するには、ツリー構造で Dispatcher を最初に 選択しなければなりません。 一度ホストに接続すると、executor および manager を 開始することができるようになります。また、ポートとサーバーを含むクラスターを作成したり、manager の advisor を開始したりすることもできます。
GUI を使用して、dscontrol コマンドで 行うあらゆる処理を実行することができます。例えば、コマンド行を使用してクラスターを定義するには、dscontrol cluster add cluster コマンドを入力します。クラスターを GUI から定義するには、「Executor」を右マウス・ボタンでクリックしてから、ポップアップ・メニューの「クラスターの追加」を左マウス・ボタンでクリックします。 ポップアップ・ウィンドウでクラスター・アドレスを入力して、「OK」をクリックします。
既存の Dispatcher 構成ファイルは、「ホスト」ポップアップ・メニューに表示される 「新規構成のロード」オプション (現行の構成を完全に置き換える場合) と 「現行の構成に追加」オプション (現行の構成を更新する場合) を使用してロードすることができます。 Dispatcher 構成は、「ホスト」ポップアップ・メニューに 表示される「構成ファイルの別名保管」オプションを使用して定期的にファイルに保管しなければなりません。GUI の上部にある「ファイル」メニューを使用して、現行のホスト接続をファイルに保管したり、すべての Load Balancer コンポーネント全体で既存のファイルにある接続を復元したりできます。
構成コマンドは、リモートでも実行することができます。詳しくは、『リモート・メソッド呼び出し (RMI)』を参照してください。
GUI からコマンドを実行するには、GUI ツリーでホスト・ノードを強調表示し、「ホスト」ポップアップ・メニューから「コマンドの送信....」を選択します。 コマンド入力フィールドに、実行したいコマンド (例えば executor report) を入力します。 現行セッションでのコマンド実行の結果およびヒストリーが、ウィンドウに表示されます。
Load Balancer ウィンドウの右上隅にある疑問符のアイコンをクリックすると、「ヘルプ」にアクセスできます。
GUI の使用に関する詳細については、付録 A. GUI: 一般的な説明を参照してください。
構成ウィザードを使用する場合は、以下のステップに従ってください。
dsserver
ウィザードは、Dispatcher コンポーネントの基本クラスターを作成するプロセスを段階的に案内します。ここでは、ネットワークについての情報を入力します。Dispatcher のためのクラスターのセットアップを通して、サーバーのグループの間のトラフィックのロード・バランシングを行います。
Dispatcher マシンをセットアップする前に、 root ユーザー (AIX、HP-UX、Linux、または Solaris システムの場合) または Windows システムの場合は管理者になる必要があります。
サポート対象のすべてのプラットフォームにおいて、Load Balancer ではサーバーの連結 が可能です。 連結とは、Load Balancer がロード・バランシングを実行しているサーバー・マシンに物理的に常駐できることを意味します。
Dispatcher マシンの場合、MAC 転送方式の使用時には、少なくとも 2 つの有効な IP アドレスが必要になります。 CBR または NAT 転送方式の場合、少なくとも 3 つの有効 IP アドレスが必要になります。
この IP アドレスは、Dispatcher マシンのプライマリー IP アドレスであり、非転送先アドレス (NFA) とも呼ばれます。 デフォルトでは、hostname コマンドによって戻されるアドレスと 同じです。このアドレスは、Telnet を介したリモートでの構成 や SNMP サブエージェントへのアクセスなどの管理目的でマシンに 接続するために使用します。Dispatcher マシンが既にネットワーク上の他のマシンに ping できる場合は、非転送先アドレスのセットアップに追加の処理は必要ありません。
クラスター・アドレスは、ホスト名 (www.yourcompany.com など) に関連するアドレスです。この IP アドレスは、クライアントがクラスター内のサーバーに接続するために使用します。これは、Dispatcher によるロード・バランシングの対象のアドレスです。
サーバーに対するクライアント要求のロード・バランシングを行うときに、Dispatcher はリターン・アドレスをその送信元アドレスとして使用します。これによって、サーバーはパケットを直接クライアントに送信せずに、Dispatcher マシンに戻すようになります。(次に Dispatcher は IP パケットをクライアントに転送します。) サーバーの追加時には、リターン・アドレス値を指定する必要があります。リターン・アドレスは、サーバーを除去してもう一度追加しない限り変更できません。
Load Balancer がバックエンド・サーバーとの間でアクティブに保持できる接続の数は、定義されたリターン・アドレスの数によって制限されます。 Load Balancer では、リターン・アドレスとサーバーの組み合わせではなく、リターン・アドレスのみに基づいてポートを使用します。 使用可能なポートがすべて使用中である場合、以降の接続は失敗します。 ビジー状態の環境においては、 複数のリターン・アドレスを使用して、使用可能なポートが不足しないようにします。
Solaris システムのみ:
例えば、デフォルト設定を変更するには、次のように、 /opt/ibm/edge/lb/servers/ibmlb.conf ファイルを編集します。
複数のタイプのアダプターをサポートするには、ibmlb.conf ファイル内の行を複製し、 装置タイプに一致するように各行を変更します。
例えば、2 つの 100 Mbps イーサネット・アダプターを使用する計画である場合は、ibmlb.conf ファイルに eri デバイスを指定する 1 行が必要です。
10 Mbps イーサネット・アダプターと 100 Mbps イーサネット・アダプターを 1 つずつ使用する計画である場合は、ibmlb.conf ファイルに le デバイスを指定する 1 行、および eri デバイスを指定する 1 行の合計 2 行が必要です。
ifconfig -a
以下が結果として出力される場合、
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 9.42.93.208 netmask fffffc00 broadcast 9.42.95.255 ether 0:3:ba:2d:24:45
以下のように、ibmlb.conf ファイルを編集します。
eri -1 0 ibmlb
例えば、クラスター X および Y が、ibmlb.conf にリストされている任意のアダプターで CBR コンポーネントにより使用されるように構成されている場合、dscontrol executor start コマンドまたは dscontrol executor stop コマンドを実行するとクラスター X および Y が構成解除されます。 これは望ましくない場合があります。クラスター X および Y を goAliases スクリプトで構成すると、Dispatcher executor を開始または停止した後でクラスターが自動的に再構成されます。
IP 転送が、TCP/IP プロトコルに対して使用可能になっていないことを確認します。
図 15 には、クラスターが 1 つ、ポートが 2 つ、およびサーバーが 3 つの Dispatcher のセットアップ例が示されています。
図 15. Dispatcher マシンに必要な IP アドレスの例
この手順で使用されるコマンドのヘルプについては、『Dispatcher および CBR のコマンド解説書』を参照してください。
サンプルの構成ファイルについては、『サンプルの Load Balancer 構成ファイル』を参照してください。
AIX、HP-UX、Linux、または Solaris システム: サーバー機能を開始するには、dsserver と入力します。
Windows システム: サーバー機能は自動的に開始します。
executor 機能を開始するには、dscontrol executor start コマンドを入力します。この時点で、さまざまな executor 設定値を変更することもできます。『Dispatcher および CBR のコマンド解説書』を参照してください。
非転送先アドレスは、このマシンに対して Telnet または SMTP を使用するなどの管理目的でマシンに接続するために使用します。デフォルトではこのアドレスはホスト名です。
非転送先アドレスを定義するには、dscontrol executor set nfa IP_address コマンドを入力するか、サンプル構成ファイルを編集します。IP_address は、シンボル名または IP アドレスです。
Dispatcher は、クラスター・アドレスに送信された要求と、そのクラスターのポート上に構成されたサーバーとのバランシングを行います。
クラスターは、シンボル名、小数点付き 10 進表記アドレス、またはワイルドカード・クラスターを定義する特別なアドレス 0.0.0.0 のいずれかです。 クラスターを定義するには、コマンド dscontrol cluster add を発行します。 クラスター・オプションを設定するには、コマンド dscontrol cluster set を発行します。また、GUI を使用してコマンドを発行することもできます。ワイルドカード・クラスターを使用すると、ロード・バランシングを行う着信パケットの複数の IP アドレスに一致させることができます。詳しくは、『ワイルドカード・クラスターを使用したサーバー構成の結合』、『ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング』および『透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用する』を参照してください。
クラスターが定義されると、通常は Dispatcher マシンのネットワーク・インターフェース・カードのいずれか 1 つでクラスター・アドレスを構成する必要があります。 これを実行するには、コマンド dscontrol executor configure cluster_address を発行します。 これによって、クラスター・アドレスと同じサブネットに属する既存のアドレスを持つ アダプターが検索されます。その後で、検出されたアダプターおよびそのアダプター上で検出された既存のアドレスのネットマスクを使用して、そのクラスター・アドレスのオペレーティング・システムのアダプター構成コマンドを実行します。例えば、以下のようになります。
dscontrol executor configure 204.67.172.72
クラスター・アドレスを構成しない場合は、ハイ・アベイラビリティー・モードの待機状態のサーバーにクラスターを追加する場合か、リモート・サーバーとして動作する広域 Dispatcher にクラスターを追加する場合です。また、スタンドアロン・モードでサンプルの goIdle スクリプトを使用する場合は、executor configure コマンドを実行する必要はありません。 goIdle スクリプトについて詳しくは、『スクリプトの使用』を参照してください。
まれに、既存のアドレスのいずれのサブネットともクラスター・アドレスが一致しない場合があります。この場合は、executor configure コマンドの 2 番目の形式を使用して、明示的にインターフェース名とネットマスクを提供してください。 dscontrol executor configure cluster_address interface_name netmask を使用してください。
例には、以下のようなものがあります。
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (AIX systems) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (Linux systems) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (Solaris systems) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (Windows systems)
Windows システムで executor configure コマンドの 2 番目の形式を使用するには、 使用するインターフェース名を特定する必要があります。 マシンにイーサネット・カードが 1 つしかない場合、インターフェース名は en0 になります。 トークンリング・カードが 1 つしかない場合は、インターフェース名は tr0 です。 いずれかのタイプのカードが複数ある場合は、そのカードのマッピングを判別する必要があります。以下のステップを使用します。
出力は画面に表示されます。Load Balancer 構成に使用するインターフェース名を判別 するには、 Number of NIC records に続く行で Load Balancer マシンの IP アドレスを検索します。
Load Balancer マシンの IP アドレスは、ia->ia_addr としてリストされます。 関連インターフェース名は、ifp->if_name としてリストされ ます。
executor configure コマンドによって割り当てられたインターフェース名は、 このコマンドでリストされたインターフェース名にマップされます。
このマッピング情報を入手すれば、クラスター・アドレスに対してネットワーク・インターフェースで別名を作成することができます。
Linux または UNIX(R) システムの場合、executor configure コマンドでは ifconfig コマンドが実行されます。
サーバーの IP が含まれない IP アドレスのリストにバインドする、バインド固有のサーバー・アプリケーション を使用している場合には、ifconfig ではなく arp publish コマンドを使用し、Load Balancer マシンで動的に IP アドレスを設定します。 例えば、以下のようになります。
arp -s <cluster> <Load Balancer MAC address> pub
ポートを定義するには、dscontrol port add cluster:port コマンドを入力するか、サンプル構成ファイルを編集するか、GUI を使用します。cluster は、シンボル名または IP アドレスです。port は、そのプロトコルに使用するポートの番号です。また、この時点でさまざまなポート設定値を変更することもできます。1 つのポートに対して、すべてのサーバーを定義して構成しなければなりません。『Dispatcher および CBR のコマンド解説書』を参照してください。
ポート番号 0 (ゼロ) は、ワイルドカード・ポートを指定するために使用します。 このポートでは、クラスターに定義されたポートのいずれにも定められないポートに対するトラフィックを受け入れます。 ワイルドカード・ポートは、すべてのポートについてルールとサーバーを構成するために使用します。 この機能は、複数のポートに同じサーバーとルールの構成がある場合にも使用できます。 このため、あるポートのトラフィックが、他のポートのトラフィックのロード・バランシング決定に影響を与えることがあります。 ワイルドカード・ポートの使用が必要な場合について詳しくは、『ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信』を参照してください。
ロード・バランシングが行われるサーバー・マシンを定義するには、dscontrol server add cluster:port:server コマンドを入力するか、サンプル構成ファイルを編集するか、GUI を使用します。cluster および server は、シンボル名または IP アドレスです。port は、そのプロトコルに使用するポートの番号です。ロード・バランシングを行うためには、クラスター上の 1 つのポートに対して複数のサーバーを定義しなければなりません。
バインド固有サーバー: Dispatcher コンポーネントがバインド固有サーバーに対してロード・バランシングを行う場合、そのサーバーはクラスター・アドレスにバインドするように構成される必要が あります。 Dispatcher は宛先 IP アドレスを変更しないでパケットを転送するので、パケットがサーバーに到着した時は、そのパケットには宛先としてクラスター・アドレスが入ったままとなります。サーバーが、 クラスター・アドレス以外の IP アドレスにバインドするよう に構成されている場合は、サーバーはクラスター向けの要求を受け入れられなくなります。
サーバーがバインド固有のものかどうかを判別するには、netstat -an コマンドを発行して server:port を検索します。サーバーが バインド固有でない場合、このコマンドの結果は 0.0.0.0:80 です。サーバーが バインド固有の場合、192.168.15.103:80 のようなアドレスが表示されます。
マルチアドレスの連結: 連結された構成では、連結サーバー・マシンのアドレスは非転送先アドレス (NFA) と同じである必要はありません。 ご使用のマシンが複数の IP アドレスで定義されている場合には、別のアドレスを使用することができます。 Dispatcher コンポーネントの場合、連結されたサーバー・マシンは、dscontrol server コマンドを使用して collocated と定義しなければなりません。連結されたサーバーについて詳しくは、『連結サーバーの使用』を参照してください。
dscontrol server のコマンド構文について詳しくは、『dscontrol server -- サーバーの構成』を参照してください。
manager 機能によって、ロード・バランシング性能が向上します。 manager を開始するには、dscontrol manager start コマンドを入力するか、サンプル構成ファイルを編集するか、GUI を使用します。
advisor は、ロード・バランシングが行われるサーバー・マシンが要求に応答する能力 に関する詳細情報を manager に提供します。advisor はプロトコル固有です。例えば、HTTP advisor を開始するには、以下のコマンドを発行します。
dscontrol advisor start http portadvisor のリストおよびそのデフォルトのポートについては、『Dispatcher および CBR のコマンド解説書』を参照してください。 各 advisor の説明については、『advisor のリスト』を参照してください。
advisor を開始すると、ロード・バランシングの判断に含まれる advisor 情報に指定された重要度の割合を変更できます。 クラスターの割合を設定するには、dscontrol cluster set cluster proportions コマンドを発行します。 詳しくは、状況情報に与えられる重要性の割合を参照してください。
以下の条件のいずれかにあてはまる場合は、以下のステップを実行してください。
注:
MAC 転送方式を使用している時には、 IP アドレス (バックエンド・サーバーが ARP (アドレス解決プロトコル) 要求に対して応答してしまわないもの) を 追加することでループバック・アダプターを構成することが可能なサーバー間でのみ、 Dispatcher のロード・バランシングが行われます。 このセクションのステップに従って、ロード・バランシングが行われるサーバー・マシンをセットアップします。
ロード・バランシングが行われるサーバー・マシンを機能させるには、ループバック・デバイス (通常は lo0 と呼ばれます) をクラスター・アドレスに設定しなければなりません (別名割り当てされることをお勧めします)。MAC 転送方式を使用している場合、Dispatcher コンポーネントはパケットを TCP サーバー・マシンに転送する前に、TCP/IP パケット中の宛先 IP アドレスを変更しません。 ループバック・デバイスをクラスター・アドレスに設定または別名割り当てすることで、ロード・バランシングが行われるサーバー・マシンは、クラスター・アドレスにアドレス指定されたパケットを受け入れます。
オペレーティング・システムがネットワーク・インターフェースの別名割り当てをサポートしている場合 (AIX、HP-UX、 Linux、Solaris、または Windows システムなど) は、ループバック・デバイスをクラスター・アドレスに別名で割り当ててください。 別名をサポートするオペレーティング・システムを使用する利点は、ロード・バランシングが行われるサーバー・マシンを、複数のクラスター・アドレスについてサービスを提供するように構成できることです。
重要: Linux システムの場合は、『Load Balancer の MAC 転送を使用する場合に代替を別名割り当てする Linux ループバック』を参照してください。
サーバーのオペレーティング・システムが 別名をサポートしない場合は、ループバック・デバイスを クラスター・アドレスに設定しなければなりません。
『表 8』に示されているご使用のオペレーティング・システム用のコマンドを使用して、ループバック・デバイスを設定するか、別名を割り当てます。
表 8. Dispatcher のループバック・デバイス (lo0) の別名を割り当てるコマンド
いくつかのオペレーティング・システムでは、デフォルトの経路が既に作成されている場合があります。その場合には、その経路を削除する必要があります。
route print
重要: Windows 2003 では、エクストラ経路を無視する必要があります。 別名割り当ての後、経路指定で問題が生じた場合、別名を除 去し、異なった netmask を使用して別名を再度追加します。
netstat -nr
Windows の場合の例:
Active Routes: Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
エクストラ経路は削除しなければなりません。『表 9』に示されているオペレーティング・システム用のコマンドを使用して、エクストラ経路を削除します。
例: ステップ 2 の「活動状態の経路」の例に示されているエクストラ経路を削除するためには、次のように入力してください。
route delete 9.0.0.0 9.67.133.158
表 9. Dispatcher のすべてのエクストラ経路を削除するコマンド
『図 15』に示されている例を使用し、AIX システムで実行されるサーバー・マシンをセットアップする場合のコマンドは、以下のようになります。
route delete -net 204.0.0.0 204.67.172.72
バックエンドのサーバーが適正に構成されていることを確認するためには、同じサブネット上の別のマシンで、Load Balancer の未実行時、かつクラスターの未構成時に、以下のステップを実行してください。
arp -d cluster
ping cluster
無応答でなければなりません。 ping に対して応答がある場合には、クラスター・アドレスをインターフェースに ifconfig していないことを確認してください。 どのマシンも、クラスター・アドレスに対する公開された arp 項目をもっていないことを確認してください。
arp -a
コマンドからの出力の中に、サーバーの MAC アドレスがあるはずです。 以下のコマンドを発行する。
arp -s cluster server_mac_address
arp -d cluster
一部の Linux システムのバージョンでは、マシン上に存在するすべてのインターフェースに構成されたすべての IP アドレスに対して、 ARP 応答を送出します。 Linux はまた、 ARP who-has 照会に対して、マシン上に存在するすべての IP アドレスに 基づいて ARP ソース IP アドレスを選択する場合があります。 これらのアドレスがどのインターフェース上で構成されているかは関係ありません。 このことにより、クラスターのトラフィックはすべて、 単一のサーバーに対して不確定に送信されます。
Dispatcher で MAC 転送方式を使用する場合は、 クラスターに宛てられたトラフィックをバックエンド・サーバーのスタックが確実に受けることができるように するための機構が必要です。 ハイ・アベイラビリティーと連結の両方が使用されている場合は、 これらのバックエンド・サーバーには、連結されたハイ・アベイラビリティーのスタンバイ・マシンも含まれます。
多くの場合は、ループバックでクラスター・アドレスに別名を割り当てる必要があります。 そのため、バックエンドのサーバーはループバック上でクラスターに別名が割り当てられている必要があり、 またハイ・アベイラビリティーと連結を使用している場合は、 スタンバイのロード・バランシング・サーバーはループバック上でクラスターに別名が割り当てられている必要が あります。
Linux システムがループバック上のアドレスを公示しないようにするために、以下の 4 つの解決方法のいずれかを使用して、 Linux システムに Dispatcher の MAC 転送との互換性を持たせます。
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1以降は、クラスターは通常の方法で別名を割り当てることができます。たとえば、次のようにします。
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2次に、 以下のコマンドでクラスターに別名を割り当てます。
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loハイ・アベイラビリティーの連結構成の場合は、 同様のコマンドを go* スクリプトに入れる必要があります。
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTこのコマンドにより、Linux システムは各パケットごとに宛先 NAT を行い、 クラスター・アドレスをインターフェース・アドレスに変換します。 この方式では、一秒毎の接続数のスループットに 6.4% の低下があります。 この方式は、通常のサポートされる配布で機能し、 カーネル・モジュールまたはカーネル・パッチ + ビルド + インストールの必要がありません。
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS nic-primary-addrここ で nic-primary-addr は、クラスター・アドレスと同じサブネット中のアドレスです。 以降は、クラスターは通常の方法で別名を割り当てることができます。たとえば、次のようにします。
# ifconfig lo:1 cluster address netmask 255.255.255.255 up
この部では、クイック・スタート構成の説明、計画の考慮事項、および Load Balancer の CBR コンポーネントを構成する方法について説明します。 この部には、以下の章があります。
このクイック・スタートの例では、CBR と Caching Proxy を使用する 3 つの ローカル接続ワークステーションを構成して、2 つのサーバー間の Web トラフィックのロード・バランスを取る方法を示します。 (わかりやすくするために、この例では同じ LAN セグメント上のサーバーを例として 使用していますが、CBR では同じ LAN 上のサーバーの使用について制限はありません。)
このクイック・スタートの例の場合、3 つのワークステーションと 4 つの IP アドレスが必要です。 ワークステーションの 1 つは CBR マシンとして 使用され、他の 2 つは Web サーバーとして使用されます。 各 Web サーバーには IP アドレスが 1 つずつ必要です。CBR ワークステーションには、実アドレスが 1 つと、ロード・バランシングが行われるアドレスが 1 つ必要です。
CBR を使用するには、同じサーバー上に Caching Proxy がインストールされていなければなりません。 CBR 用に Caching Proxy を構成するには、『ステップ 1. CBR を使用する Caching Proxy の構成』を参照してください。
ワークステーション | 名前 | IP アドレス |
---|---|---|
1 | server1.mywebsite.com | 9.27.27.101 |
2 | server2.mywebsite.com | 9.27.27.102 |
3 | server3.mywebsite.com | 9.27.27.103 |
ネットマスク = 255.255.255.0 |
各ワークステーションには、標準のイーサネット・ネットワーク・インターフェース・カードが 1 つだけ装備されています。
Name= www.mywebsite.com IP=9.27.27.104
CBR の場合は、コマンド行、構成ウィザード、または グラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。 このクイック・スタートの例では、コマンド行を使用して構成ステップを説明します。
コマンド・プロンプトから、以下のステップに従ってください。
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.mywebsite.com
cbrcontrol port add www.mywebsite.com:80
cbrcontrol server add www.mywebsite.com:80:server2.mywebsite.com
cbrcontrol server add www.mywebsite.com:80:server3.mywebsite.com
cbrcontrol rule add www.mywebsite.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.mywebsite.com:80:guestRule type content pattern uri=*/guest/*
この例では、Web サイト www.mywebsite.com へのクライアント要求は、コンテンツ・ルールを使用して、その URI 要求パス内の ディレクトリーに基づいた別のサーバーに送信されます。 詳しくは、『付録 B. コンテンツ・ルール (パターン) 構文 』を参照してください。
cbrcontrol rule useserver www.mywebsite:80:memberRule server2.mywebsite.com
cbrcontrol rule useserver www.mywebsite:80:guestRule server3.mywebsite.com
これで、CBR はコンテンツ・ベースのルールに基づいたロード・バランシングを行います。 /member/ を含む URL 要求を持つクライアントは、server2.mywebsite.com に送信されます。 /guest を含む URL 要求を持つクライアントは、server3.mywebsite.com に送信されます。
cbrcontrol manager start
cbrcontrol advisor start http 80
これで CBR はクライアント要求が失敗 Web サーバーに送信されないようにします。
ローカル接続サーバーの基本構成はこれで完了です。
構成が機能するかどうかを調べるためにテストを行います。
cbrcontrol server report www.mywebsite.com:80:2 つのサーバーを加算した合計接続数の欄が「2」になります。
CBR GUI の使用について詳しくは、『GUI』および『 付録 A. GUI: 一般的な説明』を参照してください。
CBR ウィザードの使用について詳しくは、『構成ウィザード』を参照してください。
ユーザー・サイトをサポートするように CBR を構成するには、多くの方法があります。 すべての顧客が接続されているサイトに対してホスト名が 1 つしかない場合は、サーバーの単一クラスターを定義できます。これらのサーバーごとに、CBR が通信に使用するポートを構成します。 『図 9』を参照してください。
図 17. 単一クラスターと 2 つのポートで構成された CBR の例
CBR コンポーネントのこの例では、1 つのクラスターが www.productworks.com に定義されています。 このクラスターには、HTTP 用のポート 80 および SSL 用のポート 443 の 2 つのポートがあります。http://www.productworks.com (ポート 80) に要求を出すクライアントは、https://www.productworks.com (ポート 443) に要求を出すクライアントとは異なるサーバーを呼び出します。
サポートされる各プロトコルに専用の多数のサーバーを持つ非常に大きなサイトがある場合は、CBR の構成には別の方法が適しています。 この場合、『図 10』に示されるように、多数のサーバーではなく、単一のポートで、プロトコルごとにクラスターを定義することが必要になる場合があります。
図 18. 2 つのクラスターにそれぞれ 1 つのポートを構成した CBR の例
CBR コンポーネントのこの例では、ポート 80 (HTTP) 用の www.productworks.com および ポート 443 (SSL) 用の www.testworks.com という 2 つのクラスターが定義されています。
いくつかの会社または部門 (それぞれが別々の URL を使用してユーザー・サイトへ入ってくる) について、サイトがコンテンツ・ホスティングを行う場合は、CBR を構成するための 3 つめの方法が必要になります。 この場合は、『図 11』に示されるように、それぞれの会社または部門ごとにクラスターを定義し、その URL で接続を受け取る任意のポートを定義する必要があります。
図 19. 2 つのクラスターにそれぞれ 2 つのポートを構成した CBR の例
CBR コンポーネントのこの例では、www.productworks.com および www.testworks.com の 各サイトに対して 2 つのクラスターがポート 80 (HTTP) とポート 443 (SSL) で定義されています。
この章では、Caching Proxy 付きの CBR コンポーネントをインストールおよび構成する前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。
本章には、以下のセクションが含まれています。
CBR コンポーネントにより、要求を代行する Caching Proxy を使用して、HTTP および SSL トラフィックをロード・バランシングできます。 CBR を使用すると、cbrcontrol コマンドによって CBR 構成ファイルを使用して構成するサーバーのロード・バランシングを行うことができます。
CBR は、そのコンポーネントの構造の点で Dispatcher とよく似ています。CBR は以下の機能から構成されています。
manager の使用はオプションです。ただし、manager を使用しない場合は、現在のサーバーの重みに基づいて重み付きラウンドロビン・スケジューリングを使用してロード・バランシングが行われ、advisor は使用できなくなります。
CBR の 3 つの主要な機能 (executor、manager、および advisor) は相互に対話して、サーバー間で受信要求を平衡化およびディスパッチします。 ロード・バランシング要求とともに、executor は、新規接続と活動接続の数をモニターし、この情報を manager に提供します。
CBR コンポーネントでは、クライアント要求のコンテンツを突き合わせる正規表現に基づいて要求を処理する、サーバーのセットを指定する機能が提供されます。 CBR を使用すればサイトを区分化することができるため、別のサーバー・セットから別の内容またはアプリケーション・サービスを提供することができます。この区分化は、 サイトにアクセスするクライアントには透過的です。
サイトを分割する方法の 1 つは、CGI 要求だけを処理するためにいくつかのサーバーを割り当てることです。こうすれば、数値計算の cgi スクリプトによってサーバーの通常の HTML トラフィックが低下するのを防止することができるため、クライアントは全般的な応答時間を改善することができます。この方式を使用すれば、通常の要求に対してより強力なワークステーションを割り当てることもできます。これにより、クライアントは、すべてのサーバーをアップグレードすることなしに、よりよい応答時間を得ることができます。また、cgi 要求に対してより強力なワークステーションを割り当てることもできます。
もう 1 つのサイト区分化方法は、登録が必要なページにアクセスするクライアントを 1 つのサーバー・セットに割り当て、その他のすべての要求を別のサーバー・セットに割り当てることです。こうすれば、登録するクライアントが使用すると考えられるリソースをサイトのブラウザーが表示しないようになります。このほか、より強力なワークステーションを使用して、登録済みのクライアントにサービスを提供することもできます。
もちろん、これらの方式を組み合わせて、さらに融通性のある、よりよいサービスを提供することもできます。
CBR では各要求タイプごとに複数のサーバーを指定することができるため、 最適のクライアント応答を得るために要求のロード・バランシングを行うことができます。各タイプの内容に複数のサーバーを割り当てることができるため、1 つのワークステーションまたはサーバーが失敗してもユーザーは保護されます。CBR は、この失敗を認識し、引き続きクライアント要求をセット内の他のサーバーでロード・バランシングします。
Caching Proxy は、プラグイン・インターフェースを使用して CBR プロセスと通信します。 これが機能するために、CBR はローカル・マシン上で 実行していなければなりません。これは 2 つの別個の処理であるため、Caching Proxy の複数インスタンスを実行し、CBR の単一インスタンスを 処理することができます。このセットアップは、複数の Caching Proxy 間でアドレスと機能性を分離させたり、または 複数の Caching Proxy にクライアント・トラフィックを処理させてマシンのリソース使用率を 向上させたりするために構成する場合があります。プロキシー・インスタンスは、トラフィック要件に最も適した内容によって、別々のポート上で listen したり、または同一ポート上で固有の IP アドレスにバインドしたりすることができます。
CBR および Caching Proxy は、指定のルール・タイプを使用して HTTP 要求数を調べます。Caching Proxy は実行中にクライアント要求を受け入れて、最適なサーバーについて CBR コンポーネントに照会します。この照会に基づき、CBR は優先順位が付けられたルールのセットとこの要求を突き合わせます。ルールと一致した場合は、事前に構成されたサーバー・セットから適切なサーバーを選択します。最後に、CBR は選択したサーバーを Caching Proxy に通知し、そのサーバーで要求が代行されます。
あるクラスターのロード・バランシングを行うように定義した場合は、そのクラスターに対するすべての要求にサーバーを選択するルールがあることを確認する必要があります。特定の要求と一致しないルールが見つかると、クライアントは Caching Proxy からエラー・ページを受け取ります。すべての要求をあるルールと一致させるための最も簡単な方法は、「常に真」であるルールを非常に高い優先順位番号で作成することです。このルールによって使用されるサーバーは、それより低い優先順位のルールによって明示的に処理されなかったすべての要求を処理できることを確認してください。(注: 優先順位の低いルールが先に評価されます。)
詳しくは、『ルール・ベースのロード・バランシングの構成』を参照してください。
Caching Proxy 付きの CBR は、クライアントからプロキシーへの (クライアント - プロキシー・サイド) SSL 送信と、プロキシーから SSL サーバーへの (プロキシー - サーバー・サイド) サポート送信を受信できます。SSL 要求をクライアントから受け取るために CBR 構成のサーバー上に SSL ポートを定義すると、セキュア (SSL) サーバーのロード・バランシングを行う CBR を使用して完全セキュア・サイトを保守する機能を得ます。
プロキシーからサーバーのサイドでの SSL 暗号化を使用可能にするには、CBR 用に変更された他の ibmproxy.conf ファイルの他に、Caching Proxy 用 ibmproxy.conf ファイルに別の構成ステートメントを追加する必要があります。 形式は以下のとおりでなければなりません。
proxy uri_pattern url_pattern address
ここで、uri_pattern は突き合わせるパターンの 1 つ (例: /secure/*) であり、url_pattern は置換 URL (例: https://clusterA/secure/*) であり、さらに address はクラスター・アドレス (例: clusterA) です。
Caching Proxy 付きの CBR がクライアントから SSL 送信を受け取ると、HTTP サーバーに対する SSL 要求を代行する前にその要求を暗号化解除します。 CBR で、SSL でのクライアントからプロキシー、および HTTP でのプロキシーからサーバーをサポートするため、cbrcontrol server コマンドには任意指定のキーワード mapport があります。 サーバー上のポートがクライアントからの着信ポートと異なることを示す必要があるときには、このキーワードを使用してください。以下は、mapport キーワードを使用してポートを追加する例です。ここでクライアントのポートは 443 (SSL) であり、サーバーのポートは 80 (HTTP) です。
cbrcontrol server add cluster:443 mapport 80
mapport のポート番号は、任意の正整数値にできます。デフォルトは、クライアントからの着信ポートのポート番号値です。
CBR ではポート 443 (SSL) で構成されたサーバーへの HTTP 要求に対してアドバイスできる必要があるため、特殊な advisor ssl2http が提供されています。 この advisor はポート 443 (クライアントからの着信ポート) を開始して、そのポートに構成されているサーバーにアドバイスします。クラスターが 2 つ構成されて、各クラスターに異なる mapport で構成されたポート 443 およびサーバーがある場合には、結果的に advisor の単一インスタンスが該当するポートをオープンできます。以下はこの構成の例です。
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
この章のステップを実行する前に、『Content Based Routing の計画』を参照してください。 この章では、Load Balancer の CBR コンポーネントの基本構成を作成する方法について説明します。
この表の構成ステップを始める前に、CBR マシンとすべてのサーバー・マシンをネットワーク に接続し、有効な IP アドレスを与え、相互に ping できるようにしてください。
タスク | 説明 | 関連情報 |
---|---|---|
CBR マシンをセットアップする | 要件を探します。 | CBR マシンのセットアップ |
ロード・バランシング対象のマシンをセットアップする | ロード・バランシング構成をセットアップします。 | ステップ 7. ロード・バランシングが行われるサーバー・マシンの定義 |
Load Balancer の CBR コンポーネントの基本構成を作成するには、次の 4 つの方法があります。
CBR を使用するには、Caching Proxy がインストールされている必要があります。
これは、CBR を構成する最も直接的な方法です。コマンド・パラメーター値は、英字で入力する必要があります。 唯一の例外は、ホスト名 (例えば、クラスターおよびサーバー・コマンドで使用される) およびファイル名です。
コマンド行から CBR を開始するには、以下を行います。
Windows システムの場合は、「スタート」>「設定」 (Windows 2000 の場合) > 「コントロール パネル」>「管理ツール」>「サービス」をクリックします。 「 IBM Content Based Routing」を右クリックして、「開始」を選択します。サービスを停止するには、同様のステップに従って、「停止」を選択します。
cbrcontrol コマンド・パラメーターの省略バージョンを入力できます。入力する必要があるのは、パラメーターの固有文字だけです。例えば、file save コマンドに関するヘルプを表示するには、cbrcontrol help file の代わりに cbrcontrol he f と入力することができます。
コマンド行インターフェースを始動するには、cbrcontrol を発行して cbrcontrol コマンド・プロンプトを受信します。
コマンド行インターフェースを終了するには、exit または quit を実行します。
注:
( ) 右および左括弧
& アンパーサンド
| 縦線
! 感嘆符
* アスタリスク
オペレーティング・システムのシェルは、これらを特殊文字として解釈し、cbrcontrol が評価する前に代替テキストに変換することがあります。
上のリスト中の特殊文字は cbrcontrol rule add コマンドではオプショナル文字であり、コンテンツ・ルールのパターンを指定するときに使用されます。例えば、以下のコマンドが有効であるのは、cbrcontrol>> プロンプトを使用する場合のみです。
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*
同じコマンドをオペレーティング・システムのプロンプトで使用する場合には、以下のように二重引用符 (" ") でパターンを囲む必要があります。
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
引用符を使用しないと、ルールを CBR に保管するときにパターンの一部が切り捨てされる場合があります。引用符は cbrcontrol>> コマンド・プロンプトの使用ではサポートされていないことに注意してください。
CBR を構成するための複数のコマン ドを構成スクリプト・ファイルに入力して、 まとめて実行することができます。
cbrcontrol file appendload myscript
cbrcontrol file newload myscript
現在の構成をスクリプト・ファイル (例えば savescript) に保管するには、次のコマンドを実行します。
cbrcontrol file save savescript
このコマンドは、構成スクリプト・ファイルを ...ibm/edge/lb/servers/configurations/cbr ディレクトリーに保管します。
グラフィカル・ユーザー・インターフェース (GUI) の一般的な説明と例については、図 41を参照してください。
GUI を開始するには、以下のステップに従ってください。
GUI から CBR コンポーネントを構成するには、ツリー構造で Content Based Routing を 最初に選択しなければなりません。ホストに接続後は、manager を開始することができます。また、ポートとサーバーを含むクラスターを作成したり、manager の advisor を開始したりすることもできます。
GUI を使用して、cbrcontrol コマンドで 行う任意の処理を実行することができます。例えば、コマンド行を使用してクラスターを定義するには、cbrcontrol cluster add cluster コマンドを入力します。GUI からクラスターを定義するには、「Executor」を右クリックしてから、ポップアップ・メニューで「クラスターの追加」を左クリックします。 ポップアップ・ウィンドウでクラスター・アドレスを入力して、「OK
」をクリックします。既存の CBR 構成ファイルは、「ホスト」ポップアップ・メニューに表示される 「新規構成のロード」オプション (現行の構成を完全に置き換える場合) と 「現行の構成に追加」オプション (現行の構成を更新する場合) を使用してロードすることができます。 CBR 構成は、「ホスト」ポップアップ・メニューに 表示される「構成ファイルの別名保管」オプションを使用して定期的にファイルに保管しなければなりません。GUI の上部にある「ファイル」メニューを使用して、現行のホスト接続をファイルに保管したり、すべての Load Balancer コンポーネント全体で既存のファイルにある接続を復元したりできます。
Load Balancer ウィンドウの右上隅にある疑問符のアイコンをクリックすると、「ヘルプ」にアクセスできます。
GUI からコマンドを実行するためには、GUI ツリーでホスト・ノードを強調表示し、「ホスト」ポップアップ・メニューから「コマンドの送信....」を選択します。 コマンド入力フィールドに、実行したいコマンド (例えば executor report) を入力します。 現行セッションでのコマンド実行の結果およびヒストリーが、ウィンドウに表示されます。
GUI の使用に関する詳細については、付録 A. GUI: 一般的な説明を参照してください。
構成ウィザードを使用する場合は、以下のステップに従ってください。
cbrwizard を発行することによって、コマンド・プロンプトからウィザードを立ち上げます。あるいは、GUI で示したように、CBR コンポーネント・メニューから構成ウィザードを選択します。
AIX、HP-UX、Linux、または Solaris システムの場合: Caching Proxy を開始するには、ibmproxy と入力します。
Windows システムの場合: Caching Proxy を開始するには「サービス」パネルに進みます: 「スタート」>「設定」(Windows 2000 の場合) >「コントロール パネル」>「管理ツール」>「サービス」
CBR ウィザードは、CBR コンポーネントの基本構成を作成するプロセスを段階的に案内します。 このウィザードでは、ユーザーのネットワークについて質問して、クラスターをセットアップしながら手引きします。このクラスターによって、CBR がサーバーのグループ間のトラフィックに対するロード・バランシングを行うことができます。
CBR マシンをセットアップする前に、root ユーザー (AIX、HP-UX、Linux、 または Solaris システムの場合)、または管理者 (Windows の場合) になる必要があります。
セットアップするサーバーのクラスターごとに IP アドレスが 1 つずつ必要です。 クラスター・アドレスは、ホスト名 (www.company.com など) に関連するアドレスです。この IP アドレスは、クライアントがクラスター内のサーバーに接続するために使用します。このアドレスは、クライアントからの URL 要求で使用されます。同じクラスター・アドレスに対する要求は、すべて CBR によってロード・バランシングが行われます。
Solaris システムの場合のみ: CBR コンポーネントを使用する前に、IPC (プロセス間通信) のシステム・デフォルトを変更しなければなりません。共用メモリー・セグメントの最大サイズとセマフォー ID の数を増加する必要があります。CBR をサポートするようにシステムを調整するには、システム上の /etc/system ファイルを編集して以下のステートメントを追加し、その後でリブートしてください。
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
共用メモリー・セグメントを上述の値に増やさないと、cbrcontrol executor start コマンドは失敗します。
CBR を使用するには、Caching Proxy がインストールされている必要があります。
Caching Proxy 構成ファイル (ibmproxy.conf) に対して以下を変更する必要があります。
着信 URL ディレクティブ CacheByIncomingUrl が「off」(デフォルト) であることを 確認します。
構成ファイルのマッピング規則セクションで、それぞれのクラスターごとに、次のようなマッピング規則を追加します。
Proxy /* http://cluster.domain.com/* cluster.domain.com
CBR プラグイン用に編集しなければならない項目は以下の 4 つです。
各オペレーティング・システムに関する、構成ファイルへの固有の追加事項は以下のとおりです。
図 20. AIX、Linux、および Solaris システムの CBR 構成ファイル
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
図 22. Windows システムの CBR 構成ファイル
ServerInit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:¥Program Files¥IBM¥edge¥lb¥servers¥lib¥liblbcbr.dll:ndServerTerm
CBR サーバー機能を開始するには、コマンド行で cbrserver と入力します。
デフォルトの構成ファイル (default.cfg) は、cbrserver の開始時に自動的にロードされます。 ユーザーが CBR 構成を default.cfg に保管することに決定すると、次に cbrserver を開始するときに、このファイルに保管されたすべてが自動的にロードされます。
executor 機能を開始するには、cbrcontrol executor start コマンドを入力します。この時点で、さまざまな executor 設定値を変更することもできます。『dscontrol executor -- executor の制御』を参照してください。
CBR は、クラスターに送信された要求を、そのクラスターのポートで構成された対応するサーバーに対して平衡化します。
このクラスターは、URL のホスト部分にあるシンボル名で、ibmproxy.conf ファイルの Proxy ステートメントで使用されている名前に一致する必要があります。
CBR で定義されたクラスターは着信要求に一致するように定義する必要があります。 クラスターは、着信要求に含まれるのと同じホスト名または IP アドレスを使用して定義されなければなりません。例えば、要求が IP アドレスで入力されるならば、クラスターは IP アドレスで定義します。単一の IP アドレスに解決する複数のホスト名がある場合 (そして要求をそれらのホスト名の 1 つで 着信する場合) は、すべてのホスト名をクラスターとして定義する必要があります。
クラスターを定義するには、以下のコマンドを発行します。
cbrcontrol cluster add cluster
クラスター・オプションを設定するには、以下のコマンドを発行します。
cbrcontrol cluster set cluster option value
詳しくは、『Dispatcher および CBR のコマンド解説書』を参照してください。
リバース・プロキシーとして構成された Caching Proxy を実行する場合に、 複数 Web サイトのロード・バランシングを行うには、各 Web サイトのクラスター・アドレスを Load Balancer マシンのネットワーク・インターフェース・カードの少なくとも 1 つに追加する必要があります。 そうでない場合は、このステップは省略できます。
AIX、HP-UX、Linux、または Solaris システムの場合: ネットワーク・インターフェースにクラスター・アドレスを追加するには、
ifconfig コマンドを使用します。
『表 11』に示されている、該当するオペレーティング・システム用のコマンドを使用してください。
AIX | ifconfig interface_name alias cluster_address netmask netmask |
HP-UX | ifconfig interface_name cluster_address netmask netmask up |
Linux | ifconfig interface_name cluster_address netmask netmask up |
Solaris 8、Solaris 9、および Solaris 10 | ifconfig interface_name addif cluster_address netmask netmask up |
Windows 2000 の場合: ネットワーク・インターフェースにクラスター・アドレスを追加するには、以下を実行します。
Windows 2003 の場合: ネットワーク・インターフェースにクラスター・アドレスを追加するには、以下を実行します。
ポート番号は、サーバー・アプリケーションが listen するポートです。HTTP トラフィックを実行中の Caching Proxy 付き CBR の場合は、一般に、これはポート 80 です。
前のステップで定義したクラスターにポートを定義するには、次のコマンドを実行します。
cbrcontrol port add cluster:port
ポート・オプションを設定するには、以下のコマンドを発行します。
cbrcontrol port set cluster:port option value
詳しくは、『Dispatcher および CBR のコマンド解説書』を参照してください。
サーバー・マシンは、ロード・バランシングを行うアプリケーションを実行するマシンです。server は、サーバー・マシンのシンボル名または小数点付き 10 進表記アドレスです。 クラスターおよびポートでサーバーを定義するには、次のコマンドを発行します。
cbrcontrol server add cluster:port:server
ロード・バランシングを行うためには、クラスター上の 1 つのポートに対して複数のサーバーを定義しなければなりません。
これは、Caching Proxy で CBR を構成する場合の重要なステップです。ルールは、URL 要求を識別していずれかの適切なサーバー・セットに送信する方法を定義します。CBR によって使用される特別なルール・タイプを、コンテンツ・ルールといいます。コンテンツ・ルールを定義するには、以下のコマンドを発行します。
cbrcontrol rule add cluster:port:rule type content pattern pattern
値 pattern は正規表現で、各クライアント要求の URL と比較されます。 pattern の構成方法について詳しくは、『付録 B, コンテンツ・ルール (パターン) 構文』を参照してください。
Dispatcher で定義されたその他のルール・タイプの中には、CBR でも使用できるものがあります。詳しくは、 『ルール・ベースのロード・バランシングの構成』を参照してください。
クライアント要求とルールを突き合わせるときには、最適なサーバーを求めてルールのサーバー・セットが照会されます。ルールのサーバー・セットは、ポートで定義されたサーバーのサブセットです。ルールのサーバー・セットにサーバーを追加するには、以下のコマンドを発行します。
cbrcontrol rule useserver cluster:port:rule server
manager 機能によって、ロード・バランシング性能が向上します。 manager を開始するには、以下のコマンドを発行します。
cbrcontrol manager start
advisor は、ロード・バランシングが行われるサーバー・マシンが要求に応答する能力に関する詳細情報を manager に提供します。advisor はプロトコル固有です。例えば、HTTP advisor を開始するには、以下のコマンドを発行します。
cbrcontrol advisor start http port
advisor を開始すると、ロード・バランシングの判断に含まれる advisor 情報に指定された重要度の割合を変更できます。 クラスターの割合を設定するには、cbrcontrol cluster set cluster proportions コマンドを発行します。 詳しくは、状況情報に与えられる重要性の割合を参照してください。
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Program Files\IBM\edge\lb\servers\lib
新規の環境での Caching Proxy の開始: コマンド・プロンプトから ibmproxy を発行します。
この部では、クイック・スタート構成の説明、計画の考慮事項、および Load Balancer の Site Selector コンポーネントを構成する方法について説明します。 この部には、以下の章があります。
このクイック・スタートの例では、クライアント要求に使用されるドメイン・ネームに基づいてサーバー・セット間の トラフィックのロード・バランスを取るために、Site Selector を使用して サイト名構成を作成する方法を説明します。
このクイック・スタート構成の例では、以下が必要です。
このクイック・スタートの例では、会社のサイト・ドメインは mywebshop.com です。 Site Selector は、mywebshop.com 内のサブドメインを担当します。そのため、 mywebshop.com 内にサブドメインを定義する必要があります。 例えば、apps.mywebshop.com です。 Site Selector は BIND のような完全にインプリメントされた DNS ではなく、 DNS 階層の中のリーフノードとして機能します。 Site Selector は apps.mywebshop.com サブドメインに対して権限を持ちます。 サブドメイン apps.mywebshop.com には、サイト名 marketing.apps.mywebshop.com and developer.apps.mywebshop.com が含まれます。
apps.mywebshop.com. IN NS siteselector.mywebshop.com
Site Selector の場合は、コマンド行、構成ウィザード、またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。 このクイック・スタートの例では、コマンド行を使用して構成ステップを説明します。
コマンド・プロンプトから、以下のステップに従ってください。
sscontrol nameserver start
sscontrol sitename add marketing.apps.mywebshop.com
sscontrol sitename add developer.apps.mywebshop.com
sscontrol server add marketing.apps.mywebshop.com:server1+server2
sscontrol server add developer.apps.mywebshop.com:server3+server4
sscontrol manager start
sscontrol advisor start http marketing.apps.mywebshop.com:80
sscontrol advisor start ftp developer.apps.mywebshop.com:21
これで Site Selector はクライアント要求が失敗サーバーに送信されないようにします。
基本 Site Selector 構成はこれで完了です。
構成が機能するかどうかを調べるためにテストを行います。
sscontrol server status marketing.apps.mywebshop.com:
sscontrol server status developer.apps.mywebshop.com:
サーバーごとの合計ヒット項目は ping とアプリケーション要求になります。
Site Selector GUI の使用について詳しくは、『GUI』および『付録 A. GUI: 一般的な説明』を参照してください。
Site Selector ウィザードの使用について詳しくは、『構成ウィザード』を参照してください。
この章では、Site Selector コンポーネントのインストールおよび構成を行う前に、ネットワーク計画担当者が考慮する必要がある事項について説明します。
この章には、以下のセクションが含まれています。
Site Selector はドメイン・ネーム・サーバーと連携して作動し、収集した測定値および重みを使用してサーバー・グループ全体のロード・バランシングを行います。 クライアント要求に使用されるドメイン・ネームに基づいて、サーバー・グループ全体でトラフィックのロード・バランシングを実行するサイト構成を作成できます。
制限: Site Selector がサポートする DNS 照会は、 タイプ A の照会のみです。他のタイプの照会では、戻りコード NOTIMPL (イ ンプリメントされていません) が 出されます。ドメイン全体を Site Selector に委任する場合は、 そのドメインがタイプ A の照会のみを受け取ることを確認してください。
サブドメインを DNS 環境内の Site Selector 用にセットアップする場合は、Site Selector にはその所有サブドメインに対する権限が必要です。 例えば (『図 24』を参照)、ユーザーの会社には company.com ドメインに対する権限が割り当てられているとします。 その社内には、いくつかのサブドメインがあります。 Site Selector には siteload.company.com についての権限が必要になる一方、DNS サーバー (1 つまたは複数) は atlanta.company.com および boston.company.com の権限を依然として維持することになります。
会社のネーム・サーバーが、Site Selector は siteload サブドメインについての権限があると認識するためには、ネーム・サーバー項目がその名前付きデータ・ファイルに追加されていることが必要になります。 例えば、AIX システムの場合、ネーム・サーバー項目は次のようになります。
siteload.company.com. IN NS siteselector.company.com
ここで、siteselector.company.com は Site Selector マシンの hostname です。 同等の項目が、DNS サーバーによって使用される任意の他の名前付きデータベース・ファイル中に作成されていることが必要になります。
クライアントが、ネットワーク内部のネーム・サーバーに対してドメイン・ネームを解決する要求を出します。ネーム・サーバーはその要求を Site Selector マシンに転送します。すると Site Selector は、そのドメイン・ネームをサイト名に基づいて構成されたいずれかのサーバーの IP アドレスに解決します。Site Selector は選択したサーバーの IP アドレスをネーム・サーバーに戻します。その IP アドレスをネーム・サーバーがクライアントに戻します。 (Site Selector は非再帰的 (リーフ・ノード) ネーム・サーバーとして動作し、ドメイン・ネーム要求を解決しない場合はエラーを戻します。)
『図 5』を参照してください。この図では、Site Selector が DNS システムと連携して使用され、 ローカルおよびリモート・サーバー全体でロード・バランシングを行うサイトが示されています。
Site Selector は、以下の機能で構成されています。
manager の使用はオプションです。ただし、manager を使用しない場合は、現在のサーバーの重みに基づいて重み付きラウンドロビン・スケジューリングを使用してロード・バランシングが行われ、advisor は使用できなくなります。
Metric Server を使用して、Site Selector はサーバー上でアクティビティー・レベルをモニターし、サーバーの負荷が最小のときを検出し、障害のあるサーバーを検出することができます。負荷とは、サーバーが作動している忙しさの程度を示す尺度です。システムの Site Selector 管理者は、負荷の測定に使用する測定のタイプを制御します。 アクセス頻度、ユーザー総数、アクセス・タイプ (例えば、短時間の照会、長時間の照会、 または CPU 集中の負荷) などの要因を考慮に入れて、自分の環境に適合するように Site Selector を構成できます。
ロード・バランシングはサーバーの重みに基づきます。Site Selector では、manager が重みを判別するために使用する割合に以下の 4 つがあります。
CPU およびメモリー値のすべては Metric Server によって提供されます。 したがって、Site Selector コンポーネントでは Metric Server の使用が 推奨されます。
詳しくは、『Metric Server』を参照してください。
Site Selector の 4 つのキー機能 (ネーム・サーバー、manager、Metric Server、および advisor) は対話して、サーバー間の受信要求を平衡化および解決します。
DNS ベース・ロード・バランシングを使用するには、ネーム・レゾリューションのキャッシングが使用不可にされていることが必要です。 TTL (存続時間) 値により、DNS ベース・ロード・バランシングの有効性が判別されます。 TTL により、別のネーム・サーバーが解決済みの応答をキャッシュする時間が決定されます。 小さい TTL 値は、サーバーにおける微妙な変更、またはより迅速に実現されるネットワーク負荷の場合に使用できます。 しかし、キャッシングを使用不可にすると、クライアントがすべてのネーム・レゾリューションのために信頼すべきネーム・サーバーに接続することが必要なので、クライアントの待ち時間が増加する可能性があります。 TTL 値を選択する場合は、キャッシングを使用不可にすることが環境に及ぼす影響に対して細心の考慮を払う必要があります。 また、DNS ベースのロード・バランシングはネーム・レゾリューションのクライアント・サイドのキャッシングによって制限される可能性があることも知っておいてください。
TTL は sscontrol sitename [add | set] コマンドを使用して構成できます。 詳しくは、sscontrol sitename -- サイト名の構成を参照してください。
ネットワーク接近性とは、要求しているクライアントに対する各サーバーの接近性の計算です。ネットワーク接近性を判別するために、Metric Server エージェント (各ロード・バランシングされたサーバー上に常駐していなければなりません) がクライアント IP アドレスに PING を送り、Site Selector に応答時間を戻します。Site Selector はロード・バランシング判断に接近性応答を使用します。 Site Selector はネットワーク接近性応答値を manager からの重みと結合し、サーバーの結合済み最終重み値を作成します。
Site Selector でのネットワーク接近性機能の使用はオプションです。
Site Selector は以下のネットワーク接近性オプションを提供し、これはサイト名ごとに設定できます。
「はい」を設定すると、Metric Server はクライアントを ping して、接近性応答時間を得ます。ネーム・サーバーはすべての Metric Server が応答するか、またはタイムアウトが起きるのを待ちます。次に、各サーバーではネーム・サーバーが接近性応答時間と manager が計算した重みを結合して、各サーバーの「結合重み」値を作成します。Site Selector は、最適の結合重みがあるサーバー IP アドレスのクライアントを提供します。 (ほとんどのクライアント・ネーム・サーバーのタイムアウトは 5 秒であると予想されます。Site Selector はタイムアウトを超えるまで応答を試みます。)
「いいえ」に設定すると、現在の manager 重みに基づいてネーム・レゾリューションがクライアントに提供されます。次に、Metric Server はクライアントを ping して、接近性応答時間を得ます。ネーム・サーバーは Metric Server から受け取る応答時間をキャッシュします。クライアントが 2 番目の要求を戻すと、ネーム・サーバーは現在の manager 重みを各サーバーのキャッシュされた ping 応答値と結合し、最適な「結合された重み」があるサーバーを獲得します。Site Selector は、2 番目の要求についてこのサーバーの IP アドレスをクライアントに戻します。
ネットワーク接近性オプションは、sscontrol sitename [add/set] コマンドで設定できます。詳しくは Site Selector のコマンド解説を参照してください。
この章の手順を実行する前に、Site Selector の計画を参照してください。この章では、Load Balancer の Site Selector コンポーネントの基本構成を作成する方法について説明します。
表 12. Site Selector コンポーネントの構成タスク
タスク | 説明 | 関連情報 |
---|---|---|
Site Selector マシンをセットアップする | 要件を探します。 | Site Selector マシンのセットアップ |
ロード・バランシング対象のマシンをセットアップする | ロード・バランシング構成をセットアップします。 | ステップ 4. ロード・バランシングが行われるサーバー・マシンの定義 |
Load Balancer の Site Selector コンポーネントの基本構成を作成するために、Site Selector コンポーネントを構成する以下の基本的な 4 つの方法があります。
これは、Site Selector を構成するための最も直接的な方法です。コマンド・パラメーター値は、英字で入力する必要があります。 唯一の例外は、ホスト名 (例えば、サイト名およびサーバー・コマンドで使用される) およびファイル名です。
コマンド行から Site Selector を開始するには、以下を行います。
sscontrol コマンド・パラメーターは、最小限バージョンで入力することができます。 入力する必要があるのは、パラメーターの固有文字だけです。例えば、file save コマンドに関するヘルプを表示するには、sscontrol help file の代わりに sscontrol he f と入力することができます。
コマンド行インターフェースを始動するには、sscontrol を実行して、sscontrol コマンド・プロンプトを表示します。
コマンド行インターフェースを終了するには、exit または quit を実行します。
Site Selector を構成するための複数のコマンドを 1 つの構成スクリプト・ファイルに入力して、一緒に実行することができます。
sscontrol file appendload myscript
sscontrol file newload myscript
現在の構成をスクリプト・ファイル (例えば savescript) に保管するには、次のコマンドを実行します。
sscontrol file save savescript
このコマンドは、構成スクリプト・ファイルを ...ibm/edge/lb/servers/configurations/ss ディレクトリーに保管します。
一般的な説明および GUI の例については、図 41 を参照してください。
GUI を開始するには、以下のステップに従ってください。
GUI から Site Selector コンポーネントを構成するには、最初にツリー構造で「Site Selector」を選択する必要があります。ssserver を実行しているホストに接続すると、サーバーを含むサイト名を作成し、マネージャーを開始し、advisor を開始することができます。
GUI を使用して、sscontrol コマンドで 行うあらゆる処理を実行することができます。例えば、コマンド行を使用してサイト名を定義するには、sscontrol sitename add sitename コマンドを入力します。GUI からサイト名を定義するには、「ネーム・サーバー」を右クリックしてから、ポップアップ・メニューで「サイト名の追加」を左クリックします。ポップアップ・ウィンドウでサイト名を入力してから、「了解
」をクリックします。既存の Site Selector 構成ファイルは、「ホスト」ポップアップ・メニューに表示される 「新規構成のロード」オプション (現行の構成を完全に置き換える場合) と 「現行の構成に追加」オプション (現行の構成を更新する場合) を使用してロードすることができます。 Site Selector 構成は、「ホスト」ポップアップ・メニューに表示される「構成ファイルの別名保管」オプションを使用して定期的にファイルに保存する必要があります。GUI の上部にある「ファイル」メニューを使用して、現行のホスト接続をファイルに保存したり、すべての Load Balancer コンポーネントにわたって既存のファイルにある接続を復元したりすることができます。
GUI からコマンドを実行するためには、GUI ツリーでホスト・ノードを強調表示し、 「ホスト」ポップアップ・メニューから「コマンドの送信....」を 選択します。コマンド入力フィールドに、実行したいコマンド (例えば nameserver status) を入力します。 現行セッションでのコマンド実行の結果およびヒストリーが、ウィンドウに表示されます。
Load Balancer ウィンドウの右上隅にある疑問符のアイコンをクリックすると、「ヘルプ」にアクセスすることができます。
GUI の使用に関する詳細については、付録 A. GUI: 一般的な説明を参照してください。
構成ウィザードを使用する場合は、以下のステップに従ってください。
ssserver
で開始します。 sswizard を発行して、コマンド・プロンプトからこのウィザードを立ち上げることができます。 または、GUI で表示される Site Selector コンポーネント・メニューから構成ウィザードを選択します。
Site Selector ウィザードは、Site Selector コンポーネントの基本構成を作成するプロセスを段階的に案内します。このウィザードは、使用しているネットワークについて質問し、サイト名をセットアップする時の手引きをします。このサイト名によって、Site Selector はサーバーのグループ間のトラフィックのロード・バランスを取ることができます。
Site Selector マシンをセットアップする前に、root ユーザー (AIX、HP-UX、Linux、または Solaris システムの場合) か、管理者 (Windows の場合) になっておく必要があります。
セットアップするサーバー・グループのサイト名として使用する、解決不能の完全修飾ホスト名が必要になります。 サイト名は、クライアントがサイト (www.yourcompany.com など) にアクセスするために使用する名前です。 Site Selector は DNS を使用して、サーバーのグループ間でこのサイト名のトラフィックのロード・バランシングを行います。
Site Selector サーバー機能を開始するには、コマンド行で ssserver と入力します。
ネーム・サーバーを始動するには、sscontrol nameserver start コマンドを入力します。
オプションで指定アドレスにだけバインドするには、bindaddress キーワードを使用してネーム・サーバーを開始してください。
Site Selector は、構成済みの対応サーバーに送信されるサイト名要求のバランスをとります。
このサイト名は、クライアントから要求されることになる解決不能のホスト名です。 サイト名は、完全修飾ドメイン・ネーム (例えば、www.dnsdownload.com) でなければなりません。クライアントがこのサイト名を要求すると、このサイト名に関連付けられているサーバー IP アドレスの 1 つが返されます。
サイト名を定義するには、次のコマンドを発行します。
sscontrol sitename add sitename
サイト名オプションを設定するには、以下のコマンドを発行します。
sscontrol sitename set sitename option value
詳しくは、Site Selector のコマンド解説を参照してください。
サーバー・マシンは、ロード・バランシングを行うアプリケーションを実行するマシンです。server は、サーバー・マシンのシンボル名または小数点付き 10 進表記アドレスです。 ステップ 3 のサイト名にサーバーを定義するには、以下のコマンドを発行します。
sscontrol server add sitename:server
ロード・バランシングを実行するためには、サイト名のもとで複数のサーバーを定義しなければなりません。
manager 機能によって、ロード・バランシング性能が向上します。 manager 機能の開始前に、Metric Server がロード・バランシング済みマシンのすべてにインストールされていることを確認してください。
manager を開始するには、以下のコマンドを発行します。
sscontrol manager start
advisor は、ロード・バランシングが行われるサーバー・マシンが要求に応答する能力に関する詳細情報を manager に提供します。advisor はプロトコル固有です。Load Balancer は多くの advisor を提供します。例えば、特定サイト名前の HTTP advisor を開始するには、以下のコマンドを出します。
sscontrol advisor start http sitename:port
システム・メトリックおよび Metric Server の使用法については、Metric Server を参照してください。
advisor を開始すると、ロード・バランシングの判断に含まれる advisor (ポート) 情報に指定された重要度の割合を変更できます。 サイト名の割合を設定するには、sscontrol sitename set sitename proportions コマンドを実行してください。詳しくは、状況情報に与えられる重要性の割合を参照してください。
Metric Server を Site Selector コンポーネントと一緒に使用します。Site Selector がロード・バランシングを行うすべてのサーバー・マシンで Metric Server をセットアップする方法については、Metric Server を参照してください。
この部では、クイック・スタート構成の説明、計画の考慮事項、および Load Balancer の Cisco CSS Controller コンポーネントを構成する方法について説明します。 この部には、以下の章があります。
このクイック・スタートの例では、Cisco CSS Controller コンポーネントを使用して 構成を作成する方法を示します。 Cisco CSS Controller は、ロード・バランシングの決定で最適なサーバーを選択するときに Cisco CSS Switch が利用できるサーバー重み情報を提供します。
図 25. 単純な Cisco CSS Controller 構成
このクイック・スタート構成の例では、以下が必要です。
この例の構成を開始する前に、以下のステップを完了してください。
Cisco CSS Controller では、コマンド行またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。 このクイック・スタートの例では、コマンド行を使用して構成ステップを説明します。
コマンド・プロンプトから、以下のステップに従ってください。
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
これで、Cisco CSS Switch との接続が確認され、SNMP 読み取り/書き込みコミュニティー名が 正常に機能していることが検査されます。
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
これらの値は、Cisco CSS Switch の対応している属性と一致していなければなりません。
これで、Cisco CSS Controller は SNMP を介してスイッチと通信でき、スイッチから必要な構成情報を取得します。 このステップの後に、指定した所有者コンテンツに対してどのサービスが Cisco CSS Switch に構成されたかについての情報が Cisco CSS Controller に表示されます。
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
このコマンドによって、重みの計算に使用するためにサービスから収集する メトリック情報と割合が構成されます。 すべてのメトリックの割合の合計は 100 でなければなりません。
ccocontrol consultant start SwConsultant-1
このコマンドによって、すべてのメトリック・コレクターが開始され、サービス重みの計算が開始されます。 Cisco CSS Controller は、そのサービス重みの計算の結果を SNMP を使用して Cisco CSS Switch に送信します。
Cisco CSS Controller の基本構成はこれで完了です。
構成が機能するかどうかを調べるためにテストを行います。
Cisco CSS Controller GUI の使用法については、GUI および付録 A、GUI: 一般的な説明を参照してください。
この章では、Cisco CSS Controller コンポーネントをインストールおよび構成する前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。
この章では、以下について説明します。
ハードウェアおよびソフトウェアの要件については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
また、以下のものが必要です。
Cisco CSS Controller は、一組のスイッチ・コンサルタントを管理します。それぞれのコンサルタントは、単一のスイッチによって ロード・バランスが取られているサービスの重みを判別します。 コンサルタントが重みを提供するスイッチは、コンテンツ・ロード・バランシング用に 構成されています。 コンサルタントは SNMP プロトコルを使用して、計算された重みをスイッチに送信します。 ロード・バランシング・アルゴリズムが重み付きラウンドロビンのとき、スイッチは重みを使用して、ロード・バランスを取っているコンテンツ・ルールのサービスを選択します。 重みを判別するために、コンサルタントは以下の 1 つ以上の情報を使用します。
コンテンツ・ロード・バランシングの説明およびスイッチの構成の詳細については、「Cisco Content Services Switch Getting Started Guide」を参照してください。
コンサルタントがサービスの重みの判別に必要な情報を入手するには、以下のものが必要です。
図 26 に示すように、コンサルタントは、コンサルタントが重みを提供するスイッチの 後ろにあるネットワークに接続される場合があります。 スイッチとコントローラーに対してそれぞれいくつかのパラメーターを構成して、コントローラー、スイッチ、およびサービスの間の接続を使用可能にする必要があります。
図 26 では
スイッチ上での VLAN の構成および IP ルーティングの詳細情報については、「Cisco Content Services Switch Getting Started Guide」を参照してください。
以下のいずれかのインターフェースを使用して Cisco CSS Controller を管理できます。
リモート管理の場合、図 27 では
詳細については、「Cisco Content Services Switch Getting Started Guide」を 参照してください。
図 27. ユーザー・インターフェースをスイッチの前方にして、スイッチの背後で構成されたコンサルタント (オプションのハイ・アベイラビリティー・パートナーと共に) の例
コントローラー・ハイ・アベイラビリティーは、Load Balancer の耐障害性機能を機能拡張します。パケット転送ハイ・アベイラビリティーを構想に設計されたものですが、コントローラー・ハイ・アベイラビリティーには、1 つのコントローラーにプライマリー役割を、そして別の 1 つにセカンダリー役割をと、同時に実行する 2 つのコントローラーが含まれています。
それぞれのコントローラーは、同一のスイッチ情報で構成されます。 アクティブになるのは一度に 1 つのコントローラーだけです。すなわち、ハイ・アベイラビリティー論理による判別に従って、アクティブ・コントローラーのみが計算を実行し、新しい重みでスイッチを更新します。
コントローラー・ハイ・アベイラビリティーは、ユーザーが構成するアドレスおよび ポート上で単純なユーザー・データグラム・プロトコル (UDP) パケットを使用して そのパートナーと通信します。これらのパケットは、ハイ・アベイラビリティー (リーチ情報) に関連する コントローラー間で情報を交換するために、およびパートナー・コントローラー可用性 (heartbeat) を 判別するために使用されます。待機コントローラーは、アクティブ・コントローラーになんらかの理由で 障害が発生したと判別した場合には、障害が発生したコントローラーから引き継ぎます。続いて、待機コントローラーは、アクティブ・コントローラーとなり、計算を開始し、新しい重みでスイッチを更新します。
パートナー可用性の他に、リーチ・ターゲットはハイ・アベイラビリティーに対して 構成することができます。コントローラー・ハイ・アベイラビリティーは、リーチ情報を使用して、アクティブ・コントローラーと待機コントローラーを 判別します。アクティブ・コントローラーは、より多くのターゲットを PING することができるコントローラーで、そのパートナーから到達可能です。
詳しくは、ハイ・アベイラビリティーを参照してください。
コンサルタントは、サービスが使用不可であると判別した場合には、スイッチ上でそのサービスを中断させて、 要求のロード・バランシングを行う際にスイッチがそのサーバーを考慮しないようにします。 サービスが再び使用可能になったとき、コンサルタントはスイッチ上でそのサービスをアクティブにして、 要求のロード・バランシングを行うことを考慮するようにします。
Cisco CSS Controller は以下のログに項目を記入します。
これらのログは、以下のディレクトリーに置かれます。
ログごとに、ログ・サイズとログ・レベルを設定できます。 詳しくは、Load Balancer ログの使用を参照してください。
この章の手順を実行する前に、Cisco CSS Controller の計画を参照してください。この章では、Load Balancer の Cisco CSS Controller コンポーネントの基本構成を作成する方法について説明します。
本章の構成方式のいずれかを開始する前に、以下を行ってください。
表 13. Cisco CSS Controller コンポーネントの構成タスク
タスク | 説明 | 関連情報 |
---|---|---|
Cisco CSS Controller マシンのセットアップ | 要件を探します。 | Cisco CSS Switch 用コントローラー・マシンのセットアップ |
構成をテストする | 構成が作動中であることを確認します。 | 構成のテスト |
Load Balancer の Cisco CSS Controller コンポーネントの基本構成を作成するには、以下の 3 つの方式があります。
これは、Cisco CSS Controller を構成するための最も直接的な方法です。 本書の手順では、コマンド行の使用を想定しています。コマンド・パラメーター値は、英字で入力する必要があります。 唯一の例外は、ホスト名 (例えば、consultant add コマンドで使用される) およびファイル名です。
コマンド行から Cisco CSS Controller を開始するには、以下を行います。
のように入力します。注:
ccocontrol コマンドのパラメーターの省略バージョンを入力できます。 入力する必要があるのは、パラメーターの固有文字だけです。例えば、file save コマンドに関するヘルプを表示するには、ccocontrol help file の代わりに ccocontrol he f を入力することができます。
コマンド行インターフェースを始動するには、ccocontrol を実行して、ccocontrol コマンド・プロンプトを表示します。
コマンド行インターフェースを終了するには、exit または quit を実行します。
現行定義の構成は XML ファイルに保管することができます。 この操作によって、後で構成を素早く再作成する必要があるときに、構成をロードすることができます。
XML ファイル (例えば、myscript.xml) の コンテンツを実行するには、以下のコマンドのいずれかを使用します。
ccocontrol file save XMLFilename
ccocontrol file load XMLFileName
ファイル保管を前に行った場合にだけ、ロード・コマンドを使用します。
XML ファイルは、...ibm/edge/lb/servers/configurations/cco/ ディレクトリーに保管されます。
グラフィカル・ユーザー・インターフェース (GUI) の一般的な説明と例については、図 41 を参照してください。
GUI を開始するには、以下のステップに従ってください。
ccoserver
Cisco CSS Controller コンポーネントを GUI から構成するには、以下を行います。
GUI を使用して、ccocontrol コマンドで行うあらゆる処理を実行できます。例えば、以下のようになります。
GUI からコマンドを実行するには、以下のステップに従います。
現在のセッションで実行したコマンドの結果とヒストリーは「結果」ボックスに表示されます。
「ヘルプ」にアクセスするには、Load Balancer ウィンドウの右上隅にある疑問符 (?) アイコンをクリックしてください。
GUI の使用に関する詳細については、付録 A. GUI: 一般的な説明を参照してください。
Cisco CSS Controller マシンをセットアップする前に、root ユーザー (AIX、HP-UX、Linux、または Solaris システムの場合) か、管理者 (Windows システムの場合) にならなければなりません。
コンサルタントは Cisco CSS Switch 管理者として Cisco CSS Switch に接続できなければなりません。
コンサルタントを構成するときは、アドレスと SNMP コミュニティー名が Cisco CSS Switch 上の対応する属性と一致するように構成する必要があります。
この手順で使用するコマンドについては、Cisco CSS Controller のコマンド解説を参照してください。
ccoserver がまだ実行されていない場合は、ccoserver と入力して、これをルートとして開始します。
ccocontrol と入力してコマンド行インターフェースを開始します。
スイッチ・アドレスおよび SNMP コミュニティー名を構成しなければなりません。これらの値は、Cisco CSS Switch の対応している属性と一致していなければなりません。
コンサルタントを追加するには、次のように入力します。
consultant add switchConsultantID address switchIPAddress community communityName
ownercontent は所有者のコンテンツ・ルールを表現したもので、Cisco CSS Switch で定義されています。所有者名とコンテンツ・ルールはスイッチでの定義方法が一致している必要があります。
ownercontent を追加するには、次のように入力します。
ownercontent add switchConsultantID:ownercontentID ownername ownerName contentrule contentRuleName
ownercontent を定義するとき、コンサルタントはスイッチに構成されているサービスを検索することで構成を完了します。 スイッチ上の構成をコンサルタントの構成と比較し、サービスが一致していることを確認します。
メトリックとは、サービスの重みとそれに関連付けられた割合 (別のメトリックと比較した、それぞれの メトリックの重要性) を判別するために使用される測定値のことで、接続データ・メトリック、アプリケーション advisor メトリック、および メトリック server メトリックの任意の組み合わせが可能です。割合の合計は常に 100 でなければなりません。
ownercontent が構成されるとき、デフォルトのメトリックは activeconn および connrate と定義されます。追加のメトリックが必要な場合、またはデフォルトと完全に異なるメトリックが必要な場合、次のように入力します。
ownercontent metrics switchConsultantID:ownercontentID metric1 proportion1 metric2 proportion2...metricN proportionN
コンサルタントを開始するには、次のように入力します。
consultant start switchConsultantID
これにより、メトリック・コレクターが開始し、重みの計算が始まります。
ステップ 5 でシステム・メトリックが定義される場合、Metric Server はサービス・マシンで始動される必要があります。 Metric Server の使用法については、Metric Server を参照してください。
ハイ・アベイラビリティーを構成するには、次のように入力します。
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
ハイ・アベイラビリティー環境では、複数スイッチを構成できます。 あるスイッチが別のスイッチを引き継ぐときに重み情報が常に使用できるようにするには、Cisco CSS Controller を、すべてのスイッチとそのバックアップの重みを提供するように構成する必要があります。
コントローラーのハイ・アベイラビリティーを使用し、構成する方法については、Cisco CSS Controller および Nortel Alteon Controller の拡張機能を参照してください。
構成が機能するかどうかを調べるためにテストを行います。
この部では、クイック・スタート構成や計画の考慮事項に関する情報を提供し、Load Balancer の Nortel Alteon Controller コンポーネントの構成方法について説明します。 この部には、以下の章があります。
このクイック・スタートの例では、Nortel Alteon Controller コンポーネントを使用して 構成を作成する方法を示します。 Nortel Alteon Controller は、Nortel Alteon Web Switch にサーバーの重みを提供します。この重みは、スイッチがロード・バランスを取っているサービス用のサーバーを選択するために使用されます。
図 28. 単純な Nortel Alteon Controller 構成
このクイック・スタート構成の例では、以下が必要です。
この例の構成を開始する前に、以下のステップを完了してください。
Nortel Alteon Controller では、コマンド行またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。 このクイック・スタートの例では、コマンド行を使用して構成ステップを説明します。
コマンド・プロンプトから、以下のステップに従ってください。
nalcontrol consultant add Consultant-1 address 9.87.32.50
これで、Nortel Alteon Web Switch との接続が確認され、SNMP コミュニティー名が 正常に機能していることが検査されます。
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
これで、Nortel Alteon Controller は SNMP を介してスイッチと通信し、必要な構成情報を このスイッチから取得します。 このステップの後に、サービス用にどのサーバーが Nortel Alteon Web Switch に構成されているかについての情報が Nortel Alteon Controller に表示されます。
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
このコマンドによって、重みの計算でサーバーから収集したい メトリック情報と、そのメトリックの相対重要度が構成されます。
nalcontrol consultant start Consultant-1
このコマンドによって、すべてのメトリック・コレクターが開始され、サーバー重みの計算が開始されます。 Nortel Alteon Controller は、そのサーバー重み計算の結果を SNMP を使用して Nortel Alteon Web Switch に送信します。
Nortel Alteon Controller の基本構成はこれで完了です。
構成が機能するかどうかを調べるためにテストを行います。
Nortel Alteon Controller GUI の使用法については、GUI および付録 A、GUI: 一般的な説明を参照してください。
この章では、Nortel Alteon Controller コンポーネントをインストールして構成する前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。
この章では、以下について説明します。
ハードウェアおよびソフトウェアの要件については、 Web ページ http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 を参照してください。
また、以下のものが必要です。
Nortel Alteon Controller は、一組のスイッチ・コンサルタントを管理します。各コンサルタントは、単一のスイッチによってロード・バランスされているサーバーの重みを判別します。 コンサルタントが重みを指定する対象のスイッチは、サーバー・ロード・バランシングに対して構成されます。 コンサルタントは SNMP プロトコルを使用して、計算された重みをスイッチに送信します。 スイッチは、重みを使用して、ロード・バランシングの対象のサービスに対してサーバーを選択します。 重みを判別するために、コンサルタントは以下の 1 つ以上の情報を使用します。
サーバー・ロード・バランシングの説明およびスイッチの構成の詳細情報については、「Nortel Alteon Web OS Application Guide」を参照してださい。
コンサルタントがサーバーの重みの判別に必要な情報を入手するには、以下のものが必要です。
コンサルタントは、重みを指定する対象のスイッチの前または後ろのネットワークに接続することができます。 コントローラー、スイッチ、およびサーバー間の接続を使用可能にするために、一部のパラメーターはスイッチ上で構成する必要があり、一部のパラメーターはコントローラー上で構成する必要があります。
図 29 では
スイッチ上での VLAN の構成および IP ルーティングの詳細情報については、「Nortel Alteon Web OS Application Guide」または「Command Reference」を参照してください。
図 29. スイッチの後方で接続されているコンサルタントの例
図 30 では
図 30. スイッチの前のイントラネットを介して接続されたコンサルタントの例
以下のいずれかのインターフェースを使用して Nortel Alteon Controller を管理できます。
図 31 では
図 31. スイッチの背後のコンサルタントおよびスイッチの前のユーザー・インターフェースの例
コンサルタントが、スイッチによってロード・バランシングされるサービスを指定するサーバーの重みを計算するとき、コンサルタントは、サーバーに対する不要なトラフィックを削減するために、スイッチでの通常のサーバー状態検査を使用不可にします。 サービスの重みの指定を停止したとき、コンサルタントはサーバーの状態検査をもう一度使用可能にします。 サーバー状態検査の間隔は、MIB 変数 slbNewCgRealServerPingInterval に対応します。
コンサルタントは、サーバーが使用不可であると判別した場合には、そのサーバーの最大接続数をゼロに設定して、要求のロード・バランシングを行う際にスイッチがそのサーバーを考慮しないようにします。サーバーがもう一度使用可能になったとき、最大接続数はオリジナル値に復元されます。 サーバーの最大接続数の値は、MIB 変数 slbNewCfgRealServerMaxCons に対応します。
実サーバーに対して重みを計算するとき、その重みはそのサーバーに 設定されます。サーバー重み値は、MIB 変数 slbNewCfgRealServerWeight に対応します。
スイッチを使用して、一部のサーバーを他のサーバーのバックアップとして構成することができます。 スイッチは、バックアップを持つサーバーが使用不可であると判断した場合には、要求をバックアップへ送信し始めます。 コンサルタントは、バックアップの役割を持つサービスの重みを計算するとき、バックアップとプライマリー・サーバーの両方の重みを計算し、その後、バックアップ必要時のサーバー選択に使用する重みを計算します。
バックアップ・サーバーの重みは、プライマリー・サーバーの重みより大きな値です。その理由は、スイッチがバックアップ・サーバーの使用を決定するまで、バックアップ・サーバーのロードが低くなるように、要求はバックアップ・サーバーに転送されないからです。
アイドル状態のサーバー・リソースを避けるため、通常は、1 つのサービスに割り当てられているサーバーが、別のサービスに割り当てられているサーバーのバックアップとして使用されます。 このような構成を実装するときは、同一の実サーバーを、複数の同時にアクティブなサービスに割り当てることを避けてください。 これが起こった場合には、サーバーの重みは、そのサーバーが構成の一部である各サービスのコンサルタントによって 上書きされます。
各実サーバーは整数によって識別され、重みと IP アドレス属性が 指定されます。2 つの実サーバーには、同じ IP アドレスが指定されることがあります。 その場合、2 つの実サーバーは、同じ物理サーバー・マシンに関連付けられています。 バックアップとして識別された実サーバーは、単一サービスのバックアップとしてのみ 構成します。同一の物理サーバー・マシンが、複数のサービスを割り当てられたサーバーをバックアップする場合、 一度それぞれのサービスごとに物理サーバー・マシンを構成し、それぞれのサービスごとに 固有のサーバー ID を割り当てる必要があります。そうすることにより、バックアップには、バックアップしているそれぞれのサービスごとに固有の重みが割り当てることができます。
図 32. バックアップ・サーバーがある場合のコンサルタント構成例
スイッチ上のサーバーは複数のグループの一部として構成することができます。また、スイッチ上のグループは複数のサービスを提供するように構成することができます。
複数のサービスに対して同一のサーバーを構成することが可能であるため、サーバーが構成の一部である、それぞれのサービスごとに重みを計算します。 そのため、重みの対象がどのサービスであるのかが不明であるため、重みが不適切となる可能性があります。
さらに、コンサルタントによる重みの判別が、ある 1 つのサービスに対するもので、別のサービスに対するものでない場合には、コンサルタントが重みを計算している対象のサービスのサーバー状態検査が使用不可になっている可能性があります。 この場合、スイッチは、そのサービスのロード・バランシングを適切に行わない可能性があります。
上記のような可能性により、ロード・バランシング中の複数のサービスに 実サーバーを割り当てないことを確認する必要があります。このことは、複数のサービスに対する要求を、同一のマシンがサービス提供できないと いうことではありません。サーバー・マシンが要求を処理する対象のそれぞれのサービスごとに、固有の ID を持つ実サーバーをスイッチ上で構成しなければならないという意味です。
Nortel Alteon Controller および Nortel Alteon Web Switch はどちらもハイ・アベイラビリティー機能を持っています。
ホット・スタンバイ構成の別々のシステムで実行するように 2 つのコントローラーを構成することができます。
複数のスイッチのうちの 1 つを仮想 IP インターフェース・ルーター (VIR) として構成し、別の 1 つを仮想 IP サーバー・ルーター (VSR) として機能するように構成すると、これらのスイッチは相互にバックアップします。
1 つのコンサルタント (コントローラーが管理) は、1 つのスイッチだけに重みを指定します。バックアップ・スイッチによるマスターの引き継ぎは随時に起こる可能性があるため、マスターになる可能性のある、それぞれのスイッチごとに、コントローラーを 1 つのコンサルタントで構成する必要があります。このようにしておけば、スイッチがマスターになるときに、スイッチに重みが確実に指定されます。
さらに、コントローラーは、VIR に接続される際に、仮にスイッチのうちの 1 つの接続が失われたとしても、サーバー、スイッチ、およびバックアップ・コントローラーとの通信を確保することができます。
スイッチのハイ・アベイラビリティーの詳細情報については、Nortel Alteon Web OS Application Guide を参照してください。
コントローラー・ハイ・アベイラビリティーは、Load Balancer の耐障害性機能を機能拡張します。従来のパケット転送ハイ・アベイラビリティーを構想に設計されたものですが、コントローラー・ハイ・アベイラビリティーには、1 つのコントローラーにプライマリー役割を、そして別の 1 つにセカンダリー役割をと、同時に実行する 2 つのコントローラーが含まれています。
それぞれのコントローラーは、同一のスイッチ情報で構成されています。 従来のハイ・アベイラビリティーと同様に、アクティブになるのは一度に 1 つのコントローラーだけです。 すなわち、ハイ・アベイラビリティー論理による判別に従って、アクティブ・コントローラーのみが計算を実行し、新しい重みでスイッチを更新します。
コントローラー・ハイ・アベイラビリティーは、ユーザーが構成するアドレスおよび ポート上で単純なユーザー・データグラム・プロトコル (UDP) パケットを使用して そのパートナーと通信します。これらのパケットは、ハイ・アベイラビリティー (リーチ情報) に関連する コントローラー間で情報を交換するために、およびパートナー・コントローラー可用性 (heartbeat) を 判別するために使用されます。待機コントローラーは、アクティブ・コントローラーになんらかの理由で 障害が発生したと判別した場合には、障害が発生したコントローラーから引き継ぎます。続いて、待機コントローラーは、アクティブ・コントローラーとなり、計算を開始し、新しい重みでスイッチを更新します。
パートナー可用性の他に、リーチ・ターゲットはハイ・アベイラビリティーに対して 構成することができます。従来のハイ・アベイラビリティーの場合と同様に、コントローラー・ハイ・アベイラビリティーは、リーチ情報を使用して、アクティブ・コントローラーと待機コントローラーを 判別します。アクティブ・コントローラーは、より多くのターゲットを PING することができるコントローラーで、そのパートナーから到達可能です。
詳しくは、ハイ・アベイラビリティーを参照してください。
図 33 では
図 33. Nortel Alteon Controller および Nortel Alteon Web Switch のハイ・アベイラビリティーの例
重みがあまりにも頻繁に変更されないようにするには、重要度しきい値でコンサルタントを構成することができます。重大度しきい値は、重みが変更される前に古い重みと新しい重みの間に 発生する必要のある変更の量を指定します。 詳しくは重要度しきい値を参照してください。
スイッチが重みの変更でビジー状態になった場合には、コントローラー、サーバー、およびスイッチ間のトラフィックを削減するために、コンサルタント・スリープ時間を 大きくすることができます。スリープ時間は、重み設定サイクル間のスリープ時間を秒数で設定します。
サーバーが処理する、コンサルタントからのモニター要求の数が多すぎる場合には、メトリック・コレクターのスリープ時間を変更することができます。詳細説明については、重み計算のスリープ時間を参照してください。
Cisco CSS Controller は以下のログに項目を記入します。
これらのログは、以下のディレクトリーに置かれます。
ログごとに、ログ・サイズとログ・レベルを設定できます。 詳しくは、Load Balancer ログの使用を参照してください。
この章の手順を実行する前に、Nortel Alteon Controller の計画を参照してください。この章では、Load Balancer の Nortel Alteon Controller コンポーネントの基本構成を作成する方法について説明します。
本章で説明している構成方式のいずれかを開始する前に、Nortel Alteon Web Switch およびすべてのサーバー・マシンが正しく構成されていることを確認してください。
表 14. Nortel Alteon Controller コンポーネントの構成タスク
タスク | 説明 | 関連情報 |
---|---|---|
Nortel Alteon Web Switch およびサーバーを構成する | スイッチを構成します。 | ページ (SETSWITCH) のスイッチの構成 |
Nortel Alteon Controller マシンをセットアップする | コントローラーを構成します。 | ステップ 1. サーバー機能の開始 |
構成をテストする | 構成が作動中であることを確認します。 | 構成のテスト |
Load Balancer の Nortel Alteon Controller コンポーネントの基本構成を作成するには、以下の 3 つの方式があります。
これは、Nortel Alteon Controller を構成するための最も直接的な方法です。本書の手順では、コマンド行の使用を想定しています。
コマンド行から Nortel Alteon Controller を開始するには、以下を行います。
のように入力します。注:
パラメーターの固有の文字を入力して、nalcontrol コマンド・パラメーターの省略バージョンを使用できます。例えば、file save コマンドに関するヘルプを表示するには、nalcontrol help file の代わりに nalcontrol he f と入力することができます。
コマンド行インターフェースを終了するには、exit または quit と入力します。
注:
現行定義の構成は XML ファイルに保管することができます。 この操作によって、後で構成を素早く再作成する必要があるときに、構成をロードすることができます。
XML ファイル (例えば、myscript.xml) の コンテンツを実行するには、以下のコマンドを使用します。
nalcontrol file save XMLFilename
ファイル保管を前に行った場合にだけ、ロード・コマンドを使用します。
nalcontrol file load XMLFileName
ファイル保管を前に行った場合にだけ、ロード・コマンドを使用します。
XML ファイルは ...ibm/edge/lb/servers/configurations/nal/ ディレクトリーに 保管されます。
グラフィカル・ユーザー・インターフェース (GUI) の例については、図 41 を参照してください。
GUI を開始するには、以下のステップに従います。
Nortel Alteon Controller コンポーネントを GUI から構成するには、以下を行います。
GUI を使用して、nalcontrol コマンドで行うあらゆる処理を実行できます。例えば、以下のようになります。
GUI からコマンドを実行するには、以下のステップに従います。
現在のセッションで実行したコマンドの結果とヒストリーは「結果」ボックスに表示されます。
「ヘルプ」にアクセスするには、Load Balancer ウィンドウの右上隅の疑問符 (?) アイコンをクリックします。
GUI の使用に関する詳細については、付録 A. GUI: 一般的な説明を参照してください。
この手順で使用するコマンドについては、Nortel Alteon Controller のコマンド解説を参照してください。
Nortel Alteon Controller マシンをセットアップする前に、以下のことを確認してください。
nalserver がまだ実行されていない場合は、nalserver と入力して、これをルートとして開始します。
nalcontrol と入力してコマンド行インターフェースを開始します。
スイッチ・コンサルタントを追加するには、次のように入力します。
consultant add switchconsultantID address switchIPAddress
サービスを追加するには、次のように入力します。
service add switchConsultantID:serviceID vsid virtualServerID vport virtualPortNumber
サービスは、仮想サーバー ID (VSID) および仮想ポート (VPORT) 番号によって 識別されます。これらは両方とも、そのスイッチ上で以前に構成された仮想サーバーと 関連付けられています。
メトリックとは、サーバーの重みを判別するために使用される情報です。 各メトリックには、別のメトリックと相対比較した、それぞれのメトリックの重要性を示す割合が 割り当てられます。接続データ・メトリック、アプリケーション advisor メトリック、およびメトリック server メトリックを 任意に組み合わせて構成することができます。割合の合計は常に 100 でなければなりません。
サービスが構成されるとき、デフォルトのメトリックは activeconn および connrate と定義されます。追加のメトリックが必要な場合、またはデフォルトと完全に異なるメトリックが必要な場合、次のように入力します。
service metrics switchConsultantID:serviceID metricName 50 metricName2 50
コンサルタントを開始するには、次のように入力します。
consultant start switchConsultantID
これにより、メトリック・コレクターが開始し、重みの計算が始まります。
ハイ・アベイラビリティーを構成するには、次のように入力します。
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
コントローラーのハイ・アベイラビリティーを使用し、構成する方法については、Cisco CSS Controller および Nortel Alteon Controller の拡張機能を参照してください。
ステップ 5 でシステム・メトリックが定義される場合、Metric Server はサービス・マシンで始動される必要があります。 Metric Server の使用法については、Metric Server を参照してください。
Nortel Alteon Web Switch の構成を変更した場合、コントローラー構成をリフレッシュできます。 次のように入力します。
service refresh
構成の最新表示を行う前にコンサルタントを停止します。 refresh コマンドで構成を更新後に、コンサルタントを再始動してください。
構成が機能するかどうかを調べるためにテストを行います。
この部では、Load Balancer で使用可能な機能と拡張構成機能に関する情報を提供します。 この部には、以下の章があります。
本章では、ロード・バランシング・パラメーターの構成方法、および Load Balancer の manager、advisor、および Metric Server 機能のセットアップ方法について説明します。
タスク | 説明 | 関連情報 |
---|---|---|
オプションでロード・バランシングの設定値を変更する |
以下のロード・バランシング設定値を変更することができます。
| Load Balancer によって提供されるロード・バランシングの最適化 |
スクリプトを使用して、manager がサーバーにダウンまたはアップのマークを付けるときに アラートまたはレコード・サーバー障害を生成する | Load Balancer は、manager がサーバーにダウンまたはアップのマークを付ける時点をカスタマイズできるスクリプトを起動するユーザー出口を提供します。 | アラートまたはレコード・サーバー障害を生成するスクリプトの使用 |
advisor を使用する | サーバーの特定の状況について報告する advisor を説明およびリストします。 | advisor |
HTTP または HTTPS advisor の要求および応答 (URL) オプションを使用する | マシンで照会したいサービスに固有の一意的なクライアント HTTP URL ストリングを定義します。 | 要求および応答 (URL) オプションによる HTTP または HTTPS advisor の構成 |
self advisor を使用する | Load Balancer の 2 層 WAN 構成におけるバックエンド・サーバーの負荷状況を提供します。 | 2 層 WAN 構成内の self advisor の使用 |
カスタム advisor を作成する | 独自のカスタム advisor の書き込み方法を説明します。 | カスタム (カスタマイズ可能) advisor の作成 |
Metric Server エージェントを使用する | Metric Server はシステム負荷情報を Load Balancer に提供します。 | Metric Server |
作業負荷管理機能 advisor (WLM) を使用する | WLM advisor は、システム負荷情報を Load Balancer に提供します。 | 作業負荷管理機能 advisor |
Load Balancer の manager 機能は、以下の設定を基にしてロード・バランシングを実行します。
これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。
manager は、その重みの判断で、以下の外的要因の一部またはすべてを使用できます。
または
CPU: ロード・バランシングされた各サーバー・マシンで使用中の CPU のパーセンテージ (Metric Server エージェントからの入力)。Site Selector の場合に限り、この割合は活動中の接続割合欄に表示されます。
または
メモリー: ロード・バランシングされた各サーバーで使用中のメモリーのパーセンテージ (Metric Server エージェントからの入力)。Site Selector の場合に限り、この割合は新規接続割合欄に表示されます。
manager は、各サーバーごとの現行の重みと、その計算に必要なその他の何らかの情報とともに、executor から最初の 2 つの値 (活動中の接続および新規接続) を得ます。これらの値は、executor の内部で生成および保管された情報に基づいています。
クラスター (またはサイト名) ごとの 4 つの値の重要性の相対的な割合を変更できます。この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトの割合は 50/50/0/0 で、これは advisor およびシステム情報を無視しています。使用環境によっては、最良のパフォーマンスが得られる組み合わせを見つけるために、別の割合を試すことが必要な場合があります。
WLM advisor を追加するときに、システム・メトリックの割合がゼロになっていると、manager はこの値を 1 に増加します。相対的な割合の合計は 100 でなければならないので、最大値は 1 だけ減らされます。
活動状態の接続の数は、クライアントの数によって異なるだけでなく、ロード・バランシング対象のサーバー・マシンが提供するサービスを使用するために必要な時間の長さによっても異なります。クライアント接続が高速 (HTTP GET を使用して提供される小さな Web ページのように) であれば、活動状態の接続の数はかなり低くなります。クライアントの接続が低速 (データベース照会のように) であれば、活動状態の接続の数は高くなります。
活動中の接続と新規接続の割合を低く設定しすぎることは避ける必要があります。これらの最初の 2 つの値を少なくともそれぞれ 20 に設定しておかない限り、ロード・バランシングおよび平滑化は使用不可になります。
重要性の値の割合を設定するには、dscontrol cluster set cluster proportions コマンドを使用してください。詳しくは dscontrol cluster -- クラスターの構成を参照してください。
重みは、executor の内部カウンター、advisor からのフィードバック、および Metric Server などのシステム・モニター・プログラムからのフィードバックに基づいて、manager 機能によって設定されます。manager の実行中に重みを手作業で設定したい場合は、fixedweight オプションを dscontrol サーバー・コマンドに指定してください。fixedweight オプションの説明については、manager 固定重みを参照してください。
重みは、サーバー上のすべてのポートに適用されます。特定ポートについて、要求は相互に相対的な重みに基づいてサーバー間で分散されます。例えば、一方のサーバーが重み 10 に設定され、他方が 5 に設定されると、10 に設定されたサーバーは 5 に設定されたサーバーの 2 倍の要求を得るはずです。
すべてのサーバーに指定できる最大の重み境界を指定するには、dscontrol port set port weightbound weight コマンドを入力してください。 このコマンドは、各サーバーが受け取る要求数の間で生じる差の大きさに影響します。 最大 weightbound を 1 に設定すると、すべてのサーバーが 1、停止ならば 0、あるいはマーク・ダウンならば -1 の重みを持つことができます。 この数を増加すると、サーバーに掛かる重みの差は増加します。最大 weightbound が 2 の 場合、1 つのサーバーが受ける要求の数は他の 2 倍になります。 最大 weightbound が 10 の場合、 1 つのサーバーが、他の 10 倍の要求を受けることができます。デフォルトでは、最大 weightbound は 20 です。
advisor は、サーバーが停止したことを検出すると manager に通知し、これを受けてサーバーの重みは 0 に設定されます。この結果、executor は、重みが 0 のままである限り、追加の接続をそのサーバーに送信しません。重みが変更になる前に、そのサーバーに活動状態の接続があった場合は、そのまま正常に完了します。
すべてのサーバーがダウンしている場合は、マネージャーは重みを weightbound の半分に設定します。
manager がなければ、advisor は実行されず、サーバーがダウンしているかどうかを検出することができません。advisor を実行することを選択するが、特定のサーバー用に設定した重みを manager に更新させたく ない 場合には、dscontrol server コマンドで fixedweight オプションを使用します。例えば、以下のようになります。
dscontrol server set cluster:port:server fixedweight yes
fixedweight を yes に設定した後で、dscontrol server set weight コマンドを使用して、重みを所要の値に設定します。固定重みが no に設定された別の dscontrol server コマンドが発行されるまで、manager が実行されている間はサーバー重み値は固定されたままです。詳細については、dscontrol server -- サーバーの構成を参照してください。
TCP reset が活動化されている場合、Dispatcher は、重みが 0 であるサーバーにクライアントが接続されている場合に、そのクライアントに TCP reset を送信します。 サーバーの重みは、それが 0 に構成されている場合か、または advisor がダウンさせた場合に 0 になる可能性があります。 TCP リセットにより、接続は即時にクローズします。 この機能は、長時間存続する接続の場合に有用であり、失敗した接続を再折衝するためのクライアントの機能を促進します。 TCP リセットを活動化するには、dscontrol port add|set port reset yes コマンドを使用します。 reset のデフォルト値は no です。
TCP リセットとともに構成のために便利な機能は、 advisor retry です。 この機能によって、advisor は、サーバーにダウンのマークを付ける前に接続を再試行することができます。これは、advisor が早まってサーバーにダウンのマークを付けてしまい、 結果として接続リセット問題が起こるのを防止するのに役立ちます。 つまり、advisor が最初の試行に失敗したからといって、既存の接続にも障害が起こっているということには必ずしもならないことを意味します。 詳しくは、advisor 再試行を参照してください。
全体パフォーマンスを最適化するために、manager が executor と対話する頻度が制限されます。この間隔は、dscontrol manager interval および dscontrol manager refresh コマンドを入力することで変更できます。
manager 間隔は、executor が接続の経路指定の際に使用するサーバーの重みを更新する頻度を指定します。manager 間隔が短過ぎると、manager が絶えず executor に割り込むことになり、パフォーマンスの低下が生じることになります。manager 間隔が長過ぎる場合は、executor の要求経路指定が正確な最新情報に基づいていないことを意味します。
例えば、manager 間隔を 1 秒に設定するには、以下のコマンドを入力します。
dscontrol manager interval 1
manager のリフレッシュ・サイクルは、manager が executor に状況情報を求める頻度を指定します。リフレッシュ・サイクルは、時間間隔に基づいています。
例えば、manager のリフレッシュ・サイクルを 3 に設定するには、以下のコマンドを入力します。
dscontrol manager refresh 3
これで、manager は 3 間隔待ってから executor に状況を要求することになります。
他の方法を使用して、サーバーのロード・バランシングを最適化することができます。 最高速で働くために、サーバーの重みが大幅に変わった場合にだけそれが更新されます。サーバー状況にほとんど変更がないのに、絶えず重みを更新すると、無用なオーバーヘッドを生むことになります。 ポートのすべてのサーバーに対する重みの合計の変化の割合が重要度しきい値より大きい場合、manager は executor が使用する重みを更新して、接続を分散させます。例えば、重みの合計が 100 から 105 に変化したとします。変化は 5% です。デフォルトの重要度しきい値の 5 では、変化率がしきい値を超えていないので、manager は executor が使用する重みを更新しません。しかし、重みの合計が 100 から 106 に変化すると、manager は重みを更新します。manager の重要度しきい値をデフォルト以外の値 (6 など) に設定するには、以下のコマンドを入力します。
dscontrol manager sensitivity 6
ほとんどの場合に、この値を変更する必要はありません。
manager は、サーバーの重みを動的に計算します。この結果、更新された重みが前の重みより相当に異なる場合もあります。ほとんどの状況では、これが問題になることはありません。ただし、時には、要求のロード・バランシングの方法に対する影響が変動する場合があります。例えば、重みが高いために、1 つのサーバーが要求の大部分を受信してしまうこともあります。manager は、サーバーが高い数の活動状態の接続を持ち、サーバーが応答が遅いことを調べます。そこで、manager は重み過剰を空きサーバーに移し、そこでも同じ影響が生じて、リソースの非効率使用が作りだされます。
この問題を緩和するために、manager は平滑化索引を使用します。平滑化索引は、サーバーの重みが変われる量を制限し、要求の分散における変更を効率的に平滑化します。平滑化索引が高いと、サーバーの重みの変更頻度が減少します。索引が低いと、サーバーの重みの変更頻度が増大します。平滑化索引のデフォルト値は 1.5 です。1.5 では、サーバーの重みがかなり動的になります。索引が 4 または 5 では、重みはもっと安定します。例えば、平滑化索引を 4 に設定するには、以下のコマンドを入力します。
dscontrol manager smoothing 4
ほとんどの場合に、この値を変更する必要はありません。
Load Balancer は、カスタマイズできるスクリプトを起動するユーザー出口を提供します。自動化された (サーバーがダウンとマークされると管理者にアラートを通知するか、単に障害のイベントを記録するなどの) アクションを実行するスクリプトを作成できます。カスタマイズできるサンプル・スクリプトは、 ...ibm/edge/lb/servers/samples インストール・ディレクトリーに入っています。このファイルを実行するためには、それらのファイルを ...ibm/edge/lb/servers/bin ディレクトリーに移動して、「sample」ファイル拡張子を除去しなければなりません。以下のサンプル・スクリプトが提供されています。
クラスターのすべてのサーバーに、(ユーザーまたは advisor によって) ダウンのマークが付けられている場合は、 managerAlert (構成されている場合) が開始し、Load Balancer は、ラウ ンドロビン手法で トラフィックをサーバーに経路指定しようとします。クラスターの最後のサーバーがオフラインであることが検出されたときは、serverDown スクリプトは実行されません。
Load Balancer は設計上、サーバーがオンラインに復帰して要求に応答する場合のために、 トラフィックのルーティングを継続します。もし Load Balancer がすべてのトラフィックを破棄したなら、 クライアントは応答を受けなくなってしまいます。
Load Balancer が、クラスターの最初のサーバーがオンラインに復帰していることを 検出すると、managerClear スクリプト (構成済みの場合) が実行されますが、 serverUp スクリプト (構成済みの場合) は追加のサーバーがオンラインに復帰するまで実行されません。
serverUp および serverDown スクリプトを使用するときの考慮事項:
advisor は Load Balancer 内のエージェントです。これは、サーバー・マシンの状態および負荷の状態を評価することを目的としています。これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。
当製品は、最も一般的なプロトコルに対して、いくつかのプロトコル特有の advisor を提供します。しかし、Load Balancer のすべてのコンポーネントで提供されたすべての advisor を使用しても意味がありません。(例えば、CBR コンポーネントでは Telnet advisor を使用することにはなりません。) また、Load Balancer は、ユーザーが独自の advisor を作成できる「カスタム advisor」の概念もサポートします。
バインド固有のサーバー・アプリケーションを使用する場合の 制限: バインド固有 サーバー上の advisor を使用するためには、サーバーの 2 つのインスタンスを開始します。 1 つは cluster:port 上でバインドするためのインスタンスで、もう 1 つは server:port 上で バインドするためのインスタンスです。 サーバーがバインド固有のものかどうかを判別するには、netstat -an コマンドを発行して server:port を検索します。サーバーが バインド固有でない場合、このコマンドの結果は 0.0.0.0:80 です。サーバーが バインド固有の場合、192.168.15.103:80 のようなアドレスが表示されます。
HP-UX および Solaris システムで、バインド固有のサーバー・アプリケーションを使用する上での制限: ifconfig alias コマンドの代わりに arp publish を使用しており、バインド固有のサーバー・アプリケーション (CBR または Site Selector など他の Load Balancer コンポーネントを含む) がクラスター IP アドレスにバインドしている場合は、それらのアプリケーションでサーバーのロード・バランスを取るときに、Load Balancer は advisor の使用をサポートします。 ただし、バインド固有のサーバー・アプリケーションに対して advisor を使用している場合は、同じマシン上の Load Balancer をサーバー・アプリケーションに連結しないでください。
-DLB_ADV_SRC_ADDR=IP_address
advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP "HEAD" 要求をサーバーに送信します。
advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この「負荷」値を計算するために、ほとんどの advisor は、サーバーが応答するまでの時間を測定して、この値 (ミリ秒単位) を負荷として使用します。
次に advisor は、負荷値を manager 機能に報告します。この値は、manager 報告書の「Port」列に出力されます。manager は、その割合に応じて全送信元からの重み値を集計して、これらの重み値を executor 機能に設定します。executor は、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。
サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値を manager に報告します。サーバーが活動状態でないと advisor が判断した場合は、特別な負荷値である -1 を戻します。 manager および executor は、サーバーが稼働状態に戻るまで、それ以上そのサーバーに接続を転送しなくなります。
advisor は、すべてのクラスター (グループ advisor) 間の特定ポート用に開始できます。あるいは、同一ポートで、別のクラスター (クラスター/サイト固有の advisor) ではなくて、別の advisor を実行することを選択できます。例えば、Load Balancer をそれぞれがポート 80 になっている 3 つのクラスター (clusterA、clusterB、clusterC) で定義している場合は、以下を実行できます。
dscontrol advisor start http clusterA:80このコマンドは、HTTP advisor をポート 80 で clusterA 用に開始します。この HTTP advisor は、ポート 80 で clusterA 用に接続されているすべてのサーバーでアドバイスされることになります。
dscontrol advisor start ADV_custom 80このコマンドは、ADV_custom advisor をポート 80 で clusterB および clusterC 用に開始します。カスタム advisor は、clusterB および clusterC 用にポート 80 に接続されているすべてのサーバーでアドバイスされることになります。(カスタム advisor の詳細については、カスタム (カスタマイズ可能) advisor の作成を参照してください。)
グループ advisor の前述の構成例を使用して、クラスターの一方または 両方 (clusterB および clusterC) で、 ポート 80 のカスタム advisor ADV_custom を停止できます。
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
advisor 間隔は、advisor がモニターして、その結果を manager に報告するポートのサーバーから 状況を求める頻度を設定します。advisor 間隔が短過ぎると、advisor が絶えずサーバーに割り込むことになり、パフォーマンスの低下を生じることになります。advisor 間隔が長過ぎると、manager の重みに関する決定が、正確な最新情報に基づいていないことを意味します。
例えば、ポート 80 の HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。
dscontrol advisor interval http 80 3
manager 間隔より小さい advisor 間隔を指定することは無意味です。デフォルトの advisor 間隔は 7 秒です。
タイムアウト日付がロード・バランシングの判断で manager によって使用されないことを確実にするために、manager は、タイム・スタンプが advisor 報告タイムアウトで設定されている時刻より古い、advisor からの情報を使用しないことになります。advisor 報告タイムアウトは、advisor ポーリング間隔よりも大きくなっている必要があります。タイムアウトが小さいと、manager は、論理的には使用すべき報告を無視します。デフォルトでは、advisor 報告はタイムアウトにはなりません -- デフォルト値は無制限です。
例えば、ポート 80 の HTTP advisor のために、advisor 報告タイムアウトを 30 秒に設定するには、次のコマンドを入力してください。
dscontrol advisor timeout http 80 30
advisor 報告タイムアウトの設定の詳細については、dscontrol advisor -- advisor の制御を参照してください。
Load Balancer の場合は、advisor のタイムアウト値を設定することができ、advisor はそのタイムアウト値の時点でサーバー ( サービス) 上の特定のポートが失敗したことを検出します。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待つ時間が決定されます。
失敗したサーバー の検出を最も速くするために、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor および manager 間隔時間を最小値 (1 秒) に設定します。
例えば、ポート 80 で HTTP advisor の connecttimeout および receivetimeout を 9 秒に設定するには、次のコマンドを入力します。
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
接続タイムアウトと受信タイムアウトのデフォルトは、advisor 間隔に指定されている値の 3 倍です。
advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 回だけサーバー照会が失敗するまでは、サーバーを ダウンとしてマーク付けしません。retry 値は 3 以下にしてください。 以下のコマンドは、ポート 389 の LDAP advisor に 2 の retry 値を設定します。
dscontrol advisor retry ldap 389 2
HTTP または HTTPS advisor の URL オプションは Dispatcher および CBR コンポーネントに使用可能です。
HTTP または HTTPS advisor を開始した後で、サーバーで照会したいサービスに固有の一意なクライアント HTTP URL ストリングを定義できます。 これにより、advisor は、サーバー内の個々のサービスの状態を評価できます。 これは、同一物理 IP アドレスをもつ論理サーバーを一意的なサーバー名を付けて定義することによって実行できます。 詳細については、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。
HTTP ポートの下に定義済みの論理サーバーごとに、サーバーで照会したいサービスに固有の一意的なクライアント HTTP URL ストリングを指定できます。HTTP または HTTPS advisor は advisorrequest ストリングを使用して、サーバーの正常性を照会します。 デフォルト値は HEAD / HTTP/1.0 です。 advisorresponse ストリングは、advisor が HTTP 応答でスキャンする 応答です。advisor は advisorresponse ストリ ングを使用して、サーバーから受信した実際の応答と比較します。デフォルト値は null です。
重要: ブランクが HTTP URL ストリングに含まれている場合は、次の通りです。
server set cluster:port:server advisorrequest "head / http/1.0" server set cluster:port:server advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:server advisorrequest "¥"head / http/1.0¥"" dscontrol server set cluster:port:server advisorresponse "\"HTTP 200 OK\""
バックエンド・サーバーが機能しているかどうかを確認するために、要求を作成し、HTTP または HTTPS advisor からバックエンド・サーバーに送信する場合は、ユーザーが HTTP 要求の開始部を入力し、 Load Balancer が以下を使用して要求の残りの部分を完成させます。
¥r¥nAccept: */*\r\nUser-Agent:IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n
Load Balancer がこのストリングを要求の最後に追加する前に、他の HTTP ヘッダー・フィールドを追加したい場合、独自の \r\n ストリングを要求に組み込むことによってこれを行うことができます。 以下は、HTTP ホスト・ヘッダー・フィールドを要求に追加するために入力する内容の例です。
GET /pub/WWW/TheProject.html HTTP/1.0 ¥r¥nHost: www.w3.org
詳しくは、dscontrol server -- サーバーの構成を参照してください。
self advisor は Dispatcher コンポーネントで使用可能です。
2 層 WAN (広域ネットワーク) 構成の Load Balancer の場合、Dispatcher は、バックエンド・サーバーで負荷状況情報を収集する self advisor を提供します。
図 34. self advisor を使用する 2 層 WAN 構成の例
この例では、self advisor は Metric Server と一緒に、最上層 Load Balancer によってロード・バランシングされている 2 つの Dispatcher マシンにあります。 self advisor は、特に Dispatcher のバックエンド・サーバーで秒当たりの接続数の率を executor レベルで計測します。
self advisor は、結果を dsloadstat ファイルに書き込みます。 また、Load Balancer は dsload と呼ばれる外部メトリックも提供します。Metric Server エージェントは各 Dispatcher マシンで、外部メトリック dsload を呼び出すその構成を実行します。 dsload スクリプトは、dsloadstat ファイルからストリングを抽出し、それを Metric Server エージェントに戻します。 その後、(各 Dispatcher の) 各 Metric Server エージェントは、最上層 Load Balancer に負荷状況値を戻します。この値は、クライアント要求を転送する Dispatcher の判別に使用されます
dsload 実行可能ファイルは、Load Balancer の ...ibm/edge/lb/ms/script ディレクトリーにあります。
広域 Dispatcher サポートの構成を参照してください。 Metric Server の詳細については、Metric Server を参照してください。
カスタム (カスタマイズ可能) advisor は、基本コードによって呼び出される小規模な Java コードであり、ユーザーによりクラス・ファイルとして提供されます。基本コードは、カスタム advisor のインスタンスの開始と停止、状況と報告書の提供、およびヒストリー情報のログ・ファイルへの記録などのあらゆる管理サービスを提供します。また、結果を manager コンポーネントに報告します。基本コードは advisor サイクルを定期的に実行し、各サイクルで構成内のサーバーをすべて評価します。これは、サーバー・マシンとの接続を オープンすることによって開始されます。ソケットがオープンすると、基本コードは、カスタム advisor の "getLoad" メソッド (関数) を呼び出します。その後、カスタム advisor は、サーバーの状態を評価するために必要なステップをすべて実行します。一般的には、ユーザー定義のメッセージをサーバーに送信してから応答を待機します。(オープンしたソケットへのアクセスがカスタム advisor に提供されます。) その後、基本コードは、サーバーとのソケットをクローズして、manager に負荷情報を報告します。
基本コードおよびカスタム advisor は、通常モードおよび置換モードのいずれでも機能します。動作モードの選択は、カスタム advisor ファイルでコンストラクター・メソッドのパラメーターとして指定します。
通常モードでは、カスタム advisor がサーバーとデータを交換し、基本 advisor コードが交換の時間を測定して負荷値を計算します。基本コードは、この負荷値を manager に 報告します。カスタム advisor は、0 (正常) または負の値 (エラー) を戻す必要があるのみです。通常モードを指定するには、コンストラクターの代替フラグを false に設定します。
置換モードでは、基本コードはいかなる時間測定も行いません。カスタム advisor コードは、固有の要件に必要な操作をすべて実行して、実際の負荷値を戻します。基本コードは、その数値を受け入れて manager に報告します。最善の結果を得るためには、負荷値を 10 から 1000 までの間に正規化し、10 で高速なサーバーを表し、1000 で低速なサーバーを表してください。置換モードを指定するには、コンストラクターの代替フラグを true に設定します。
この機能によって、ユーザー自身の advisor を作成し、ユーザーが必要とするサーバーに関する正確な情報を得ることができます。
サンプルのカスタム advisor (ADV_sample.java) は、Load Balancer 製品に付属しています。
Load Balancer のインストール後、サンプル・コードは
...<install
directory>/servers/samples/CustomAdvisors インストール・ディレクトリーにあります。
デフォルトのインストール・ディレクトリー は、以下のとおりです。
カスタム advisor が追加の Java クラスを参照する場合は、Load Balancer 開始スクリプト・ファイル内のクラスパス (dsserver、cbrserver、ssserver) を更新して、その場所を含めてください。
WebSphere Application Server (WAS) advisor 専用のサンプル・カスタム advisor ファイルが Load Balancer インストール・ディレクトリーにあります。
WebSphere Application Server advisor サンプル・ファイルは、ADV_sample.java ファイルと同じサンプル・ディレクトリーに入っています。
カスタム advisor のファイル名は "ADV_myadvisor.java." の形式でなければなりません。接頭部 " ADV_" は大文字にする必要があります。それ以後の文字は、すべて小文字でなければなりません。
Java の規則に従い、ファイル内で定義されたクラスの名前は、ファイルの名前と一致していなければなりません。サンプル・コードをコピーする場合は、ファイル内の "ADV_sample" のインスタンスをすべて新しいクラス名に変更してください。
カスタム advisor は、Java 言語で作成します。Load Balancer と共にインストールされた Java コンパイラーを使用してください。 以下のファイルは、コンパイル中に参照されます。
クラスパスは、コンパイル時にカスタム advisor ファイルと基本クラス・ファイルの両方を指していなければなりません。
Windows システムの場合、サンプル・コンパイル・コマンドは次のとおりです。
install_dir/java/bin/javac -classpath install_dir\lb\servers\lib\ibmlb.jar ADV_fred.java
ここで、
コンパイルの出力は以下のようなクラス・ファイルです。
ADV_fred.class
advisor を開始する前に、クラス・ファイルを ...ibm/edge/lb/servers/lib/CustomAdvisors インストール・ ディレクトリーにコピーしてください。
AIX、HP-UX、Linux、および Solaris システムでの構文は似ています。
カスタム advisor を実行するには、次のように、最初にクラス・ファイルを正しいインストール・ディレクトリーに コピーしなければなりません。
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
コンポーネントを構成し、その manager 機能を開始して、カスタム advisor を開始するためのコマンドを出します。
dscontrol advisor start fred 123
ここで、
カスタム advisor が追加の Java クラスを参照する場合は、Load Balancer 開始スクリプト・ファイル内のクラスパス (dsserver、cbrserver、ssserver) を更新して、その場所を含めてください。
すべての advisor と同様に、カスタム advisor は、ADV_Base という advisor ベースの機能を拡張します。これは、manager の重みのアルゴリズムで 使用するために manager に負荷を報告する などの advisor の機能のほとんどを実際に実行する advisor ベースです。また、advisor ベースは、ソケット接続とクローズ操作も実行し、advisor が使用するための send および receive メソッドを提供します。advisor 自体は、アドバイスされるサーバーのポートとの間で データを送受信するためにのみ使用されます。advisor ベースの TCP メソッドは時間が測定され、負荷が計算されます。必要な場合は、ADV_base のコンストラクターにあるフラグによって、advisor から戻された新しい負荷で既存の負荷が上書きされます。
基本クラスのメソッドを以下に示します。
Load Balancer は、最初に、提供されているネイティブの advisor のリストを参照します。 指定された advisor がそこに見つからない場合、Load Balancer はカスタマイズされた advisor のリストを参照します。
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:¥Program Files¥IBM¥edge¥lb¥servers¥lib¥CustomAdvisors
サンプル advisor のプログラム・リストは、サンプル advisorに入っています。インストールすると、このサンプル advisor は ...ibm/edge/lb/servers/samples/CustomAdvisors ディレクトリーに入ります。
この機能は、すべての Load Balancer コンポーネントに使用可能です。
Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer manager は、各サーバーに常駐している Metric Server エージェントに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も manager 報告書に入れられます。
Metric Server の操作 (始動および停止) と Metric Server ログの使用方法については、Metric Server コンポーネントの使用を参照してください。
構成の例については、図 5 を参照してください。
WLM advisor と同様に、Metric Server は、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 WLM および Metric Server は、両方とも manager 報告書の system 列に結果を入れます。結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。
Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。
以下は、Dispatcher の Metric Server を構成するためのステップです。Load Balancer のその他のコンポーネントの Metric Server を構成する場合も、同様のステップを使用してください。
を発行します。port は、実行するためにすべての Metric Server エージェント用に選択する RMI ポートです。metricserver.cmd ファイル中で設定されているデフォルト RMI ポートは 10004 です。
を発行します。systemMetric は、指定されたクラスター (またはサイト名) の下の構成でサーバーのそれぞれで実行される (バックエンド・サーバーに存在している) スクリプトの名前です。2 つのスクリプト cpuload および memload がお客様提供されます。あるいは、カスタム・システム・メトリック・スクリプトを作成できます。スクリプトには、0 から 100 までの範囲の数値か、サーバーがダウンしている場合は -1 の値を戻すコマンドが含まれています。 この数値は、アベイラビリティー値ではなくロード測定値を表します。
制限: Windows プラットフォームでは、システム・メトリック・スクリプトの名前に ".exe" 以外の拡張子が付いている場合、ファイルのフルネーム (例えば "mysystemscript.bat") を指定する必要があります。これは Java の制限によるものです。
オプションで、Metric Server がサーバー・マシンで出すコマンドを定義したユーザー独自のカスタマイズ済みメトリック・スクリプト・ファイルを作成できます。すべてのカスタム・スクリプトが実行可能であること、および ...ibm/edge/lb/ms/script ディレクトリーにあることを確認してください。 カスタム・スクリプトは、範囲が 0 ~ 100 の数字の負荷の値を戻さなければなりません。
Metric Server がローカル・ホスト以外のアドレスで実行されるようにするには、ロード・バランスされるサーバー・マシン上の metricserver ファイルを編集する必要があります。 metricserver ファイル中の "java" のオカレンスの後に、以下を挿入します。
-Djava.rmi.server.hostname=OTHER_ADDRESS
さらに、metricserver ファイル中の "if" ステートメントの前に、次の行を追加します: hostname OTHER_ADDRESS。
Windows プラットフォームの場合: Metric Server マシンの Microsoft スタックで OTHER_ADDRESS に別名を割り当てることも必要です。 例えば、以下のようになります。
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
さまざまなドメイン間でメトリックを収集するときは、サーバー・スクリプト (dsserver、cbrserver 等) で java.rmi.server.hostname をメトリックを要求するマシンの完全修飾ドメイン名に明確に設定しなければなりません。 これは、使用するセットアップおよびオペレーティング・システムによっては、InetAddress.getLocalHost.getHostName() が FQDN を戻さない可能性があるので必要とされます。
WLM は、MVS メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。
OS/390 システムで MVS 作業負荷管理が構成されている場合、Dispatcher は、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。 WLM advisor を使用して、Dispatcher は、定期的に Dispatcher ホスト・テーブルにある 各サーバーの WLM ポートを介して接続をオープンし、戻された容量を表す整数を受け取ります。これらの整数は その時点で使用可能な容量を表しますが、Dispatcher は各マシン の負荷を表す値を想定しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (つまり、 容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを 表します)。結果として得られる負荷は、manager 報告書の System 列に入ります。
WLM advisor と他の Dispatcher advisor の間には、重要な違いがいくつかあります。
Metric Server エージェントと同様に、WLM エージェントは、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 Metric Server および WLM は、manager 報告書の system 列に結果を入れます。 結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。
本章では、ロード・バランシング・パラメーターの構成方法と、拡張機能に関する Load Balancer のセットアップ方法について説明します。
タスク | 説明 | 関連情報 |
---|---|---|
ロード・バランシングを行っているマシン上の Load Balancer を連結する | 連結された Load Balancer マシンをセットアップします。 | 連結サーバーの使用 |
高可用性または相互高可用性を構成する | 2 番目の Dispatcher マシンをセットアップしてバックアップを提供します。 | ハイ・アベイラビリティー |
ルール・ベースのロード・バランシングを構成する | サーバーのサブセットが使用される条件を定義します。 | ルール・ベースのロード・バランシングの構成 |
ポート類縁性のオーバーライドを使用して、サーバーがポート・スティッキー機能をオーバーライドするメカニズムを提供する | サーバーは、そのポートのスティッキー時間の設定をオーバーライドできます。 | ポート類縁性のオーバーライド |
スティッキー (類縁性機能) を使用して、クラスターのポートをスティッキーになるように構成する | クライアント要求を同じサーバーに送信できます。 | Load Balancer の類縁性機能の動作 |
ポート間類縁性を使用して、スティッキー (類縁性) 機能をポート全体に拡張する | 異なるポートから受け取ったクライアント要求を、同じサーバーに送信できます。 | ポート間類縁性 |
類縁性アドレス・マスクを使用して、共通の IP サブネット・アドレスを指定する | 同じサブネットから受け取ったクライアント要求を、同じサーバーに送信できます。 | 類縁性アドレス・マスク (stickymask) |
活動中の cookie の類縁性を使用して、CBR のサーバーのロード・バランシングを行う | セッションにおいて特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | 活動 Cookie 類縁性 |
受動 Cookie の類縁性を使用して、Dispatcher の Content Based Routing (CBR) および CBR コンポーネントについてサーバーのロード・バランシングを行う | セッションにおいて Cookie 名/Cookie 値を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | 受動 cookie 類縁性 |
URI の類縁性を使用して、個々の各サーバーのキャッシュに入れる固有のコンテンツがある Caching Proxy サーバーにわたってロード・バランシングを行う | セッションにおいて URI を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | URI 類縁性 |
広域 Dispatcher サポートを構成する | リモート Dispatcher をセットアップして、広域ネットワークにわたるロード・バランシングを行います。あるいは、GRE をサポートするサーバー・プラットフォームを使用して (リモート Dispatcher を使用しない) 広域ネットワークにわたるロード・バランシングを行います。 | 広域 Dispatcher サポートの構成 |
明示リンクを使用する | リンクで Dispatcher をバイパスしないようにします。 | 明示リンクの使用 |
プライベート・ネットワークを使用する | Dispatcher を構成して、プライベート・ネットワークにあるサーバーのロード・バランシングを行います。 | プライベート・ネットワーク構成の使用 |
ワイルドカード・クラスターを使用して、共通のサーバー構成を結合する | 明示的に構成されていないアドレスでは、トラフィックのロード・バランシングを行うための方法としてワイルドカード・クラスターが使用されます。 | ワイルドカード・クラスターを使用したサーバー構成の結合 |
ワイルドカード・クラスターを使用して、ファイアウォールのロード・バランシングを行う | ファイアウォールに対して、すべてのトラフィックのロード・バランシングが行われます。 | ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング |
透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用する | 透過プロキシーを使用可能にするために Dispatcher を使用できるようにします。 | 透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用する |
ワイルドカード・ポートを使用して、構成されていないポートのトラフィックを送信する | 特定のポートに対して構成されていないトラフィックを処理します。 | ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信 |
「サービス妨害攻撃 (Denial of Service Attack)」を使用して、潜在的なアタックを管理者に (アラートによって) 通知する | Dispatcher は、サーバーでハーフ・オープン TCP 接続の著しい量の受信要求を分析します。 | サービス妨害攻撃の検出 |
バイナリー・ログを使用して、サーバーの統計を分析する | サーバー情報をバイナリー・ファイルに保管して検索できるようにします。 | バイナリー・ログを使用したサーバー統計の分析 |
連結クライアント構成を使用する | Load Balancer をクライアントと同一マシン上に 常駐できるようにします。 | 連結クライアントの使用 |
Load Balancer は、要求のロード・バランシングを行っている対象のサーバーと同じマシン上に常駐できます。 これは一般に、サーバーの連結と呼ばれています。連結は、Dispatcher および Site Selector コンポーネントに適用されます。 連結は CBR に対してもサポートされていますが、バインド固有の Web サーバーおよびバインド固有の Caching Proxy を使用する場合に限られます。
Linux システム: MAC 転送方式を使用して Dispatcher コンポーネントを実行している場合に、連結と高可用性の両方を同時に構成するには、Linux における Load Balancer の MAC 転送の使用時のループバック別名割り当ての代替手段を参照してください。
Windows システム: MAC 転送方式を使用して Dispatcher コンポーネントを実行している場合に、連結と高可用性の両方を同時に構成するには、連結および高可用性の構成 (Windows システム) を参照してください。
Solaris システム: エントリー・ポイント Dispatcher が連結されている WAN advisor を構成できないという制限があります。Dispatcher の広域サポートとリモート advisor の使用を参照してください。
以前のリリースでは、連結サーバーのアドレスは構成内の非転送先アドレス (NFA) と同じになるように指定する必要がありました。この制限は、取り除かれました。
サーバーが連結されるように構成するために、dscontrol server コマンドには collocated というオプションがあります。このオプションは、yes または no に設定できます。デフォルトは no です。サーバーのアドレスは、マシン上のネットワーク・インターフェース・カードの有効な IP アドレスでなければなりません。Dispatcher の NAT または CBR 転送方式で連結したサーバーには、collocated パラメーターを設定しないでください。
連結サーバーは、次の方法のいずれかで構成できます。
Dispatcher の NAT または CBR 転送については、 NFA 上で未使用のアダプター・アドレスを構成する (別名を割り当てる) 必要があります。 サーバーは、このアドレスに対して listen するように構成します。 次のコマンド構文を使用してサーバーを構成してください。
dscontrol server add cluster:port:new_alias address new_alias router router_ip returnaddress return_address
この構成をしないと、システム・エラーが出されるか、 サーバーからの応答が得られないか、その両方につながります。
Dispatcher の nat 転送メソッドを使用して連結サーバーを 構成する場合、dscontrol server add コマンドで指定するルーターは、 サーバーの IP アドレスではなく、ルーターの実アドレスでなければなりません。
Dispatcher の nat 転送方式を構成しているときの連結サポートは、Dispatcher マシンで以下のステップを実行している場合、すべてのオペレーティング・システムで行うことができます。
arp -s hostname ether_addr pub
ether_addr にはローカル MAC アドレスが入ります。 これで、ローカル・アプリケーションはカーネル内のリターン・アドレスにトラフィックを送信することができます。
CBR は、追加構成が不要なプラットフォームのすべてで連結をサポートします。 しかし、使用される Web サーバーおよび Caching Proxy はバインド固有でなければなりません。
Site Selector は、追加構成が不要のすべてのプラットフォームで連結をサポートします。
ハイ・アベイラビリティー機能 (dscontrol highavailability コマンドで構成可能) は、Dispatcher コンポーネントに使用可能 (CBR または Site Selector コンポーネントでは使用不可) です。
Dispatcher の可用性を向上させるために、Dispatcher のハイ・アベイラビリティー機能は以下のメカニズムを使用します。
可能な場合には、heartbeat ペアの少なくとも 1 つを、 通常のクラスター・トラフィックではなく別個のサブネットにまたがるようにしてください。 heartbeat トラフィックを別個に保持すると、非常に重いネットワーク負荷の最中に起こる偽の引き継ぎを防ぎ、 フェイルオーバー後の完全なリカバリーの時間を短縮させます。
dscontrol highavailability の完全な構文は、dscontrol highavailability -- 高可用性の制御を参照してください。
下記のタスクの多くについて詳しくは、Dispatcher マシンのセットアップを参照してください。
dscontrol highavailability heartbeat add sourceaddress destinationaddress
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3少なくとも 1 つの heartbeat ペアには、送信元アドレスおよび宛先アドレスとしてそのペア の NFA が必要です。
可能な場合には、heartbeat ペアの少なくとも 1 つを、 通常のクラスター・トラフィックではなく別個のサブネットにまたがるようにしてください。 heartbeat トラフィックを別個に保持すると、非常に重いネットワーク負荷の最中に起こる偽の引き継ぎを防ぎ、 フェイルオーバー後の完全なリカバリーの時間を短縮させます。
実行プログラムがハイ・アベイラビリティー heartbeat のタイムアウトに使用する秒数を設定してください。例えば、以下のようになります。
dscontrol executor set hatimeout 3
デフォルトは 2 秒です。
dscontrol highavailability reach add 9.67.125.18リーチ・ターゲットをお勧めしますが、必須ではありません。詳細については、heartbeat およびリーチ・ターゲットを使用した障害検出機能を参照してください。
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusマシンには、それぞれ正しい役割 (バックアップとプライマリー、または両方)、状態、および副状態があるはずです。プライマリーは、活動状態であり、かつ同期化されていなければなりません。バックアップは待機モードであって、間もなく同期化されなければなりません。ストラテジーは同じでなければなりません。
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB primaryhost NFAdispatcher2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA primaryhost NFAdispatcher1
注:
障害検出の基本的な基準 (heartbeat メッセージによって検出される、活動状態と待機 Dispatcher 間での接続性の喪失) 以外には、到達可能性基準 というもう 1 つの障害検出機構があります。Dispatcher を構成する場合は、正しく機能するようにするために、Dispatcher のそれぞれが到達できるホストのリストを提供できます。2 つの HA パートナーは、heartbeat を通じて互いに継続的に連絡を取り、2 つのうちいずれかが ping できるリーチ・ターゲット数を相互に更新します。待機 Dispatcher が活動状態の Dispatcher より多くのリーチ・ターゲットを ping する場合、フェイルオーバーが発生します。
heartbeat は、活動状態の Dispatcher によって送信され、スタンバイ Dispatcher によって 1/2 秒ごとに受信されることが予想されます。スタンバイ Dispatcher が 2 秒以内に heartbeat を受信できない場合、フェイルオーバーが始まります。heartbeat は、スタンバイ Dispatcher からの引き継ぎを発生させるためにすべて中断しなければなりません。 つまり、2 組みの heartbeat を構成するときは、両方の heartbeat を中断する必要があるということになります。ハイ・アベイラビリティー環境を 安定させてフェイルオーバーを回避するためには、複数の heartbeat ペアを追加します。
リーチ・ターゲットの場合、Dispatcher マシンが使用するサブネットごとに、少なくとも 1 つのホストを選択しなければなりません。ホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合か、プライマリー Dispatcher が到達可能性基準に一致しなくなり、待機 Dispatcher が到達可能である場合は、フェイルオーバーが起こります。あらゆる使用可能な情報をもとに判断するため、活動状態の Dispatcher は、その到達可能性の機能を定期的に待機 Dispatcher に送信します。待機 Dispatcher は、この機能とそれ自身の機能と比較して、切り替えを行うかどうかを決定します。
プライマリー・マシンおよび バックアップ と いう第 2 マシンの 2 つの Dispatcher マシンが構成されます。始動時に、プライマリー・マシンは、マシンが同期化するまで、すべての接続データをバックアップ・マシンに送信します。プライマリー・マシンは 活動状態 になります、つまり、プライマリー・マシンはロード・バランシングが開始します。その間、バックアップ・マシンは、プライマリー・マシンの状況をモニターしていて、待機 状態にあるといわれます。
バックアップ・マシンは、いつでも、プライマリー・マシンが失敗したことを検出すると、プライマリー・マシンのロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンは、再度操作可能になると、ユーザーによるリカバリー・ストラテジー の構成方法に応じて応答します。 ストラテジーには、以下の 2 種類があります。
ストラテジー・パラメーターの設定は、両マシンとも同じでなければなりません。
手動リカバリー・ストラテジーでは、引き継ぎコマンドを使用して、パケットの経路指定を強制的に特定のマシンに向けることができます。手動リカバリーは、他のマシンで保守が行われているときは便利です。自動リカバリー・ストラテジーは、通常の不在操作用に設計されています。
相互 HA 構成の場合は、クラスターごとの障害はありません。 一方のマシンでなんらかの問題が発生する場合、たとえその問題が 1 方だけのクラスターに影響を及ぼしても、他方のマシンは両方のクラスターを引き継ぎます。
Dispatcher がパケットを経路指定するには、それぞれのクラスター・アドレスがネットワーク・インターフェース・デバイスに対して 別名割り当てされなければなりません。
ネットワーク・インターフェース・カードに対する別名割り当てについては、ステップ 5. ネットワーク・インターフェース・カードの別名割り当てを参照してください。
Dispatcher マシンは障害を検出すると状態を変更するので、上記のコマンドは自動的に出されなければなりません。Dispatcher は、ユーザー作成のスクリプトを実行して、これを行います。サンプル・スクリプトは ...ibm/edge/lb/servers/samples ディレクトリーにあり、実行するためには ...ibm/edge/lb/servers/bin ディレクトリーに移動しなければなりません。スクリプトは、dsserver の稼働中のみ自動的に実行されます。
注:
以下のサンプル・スクリプトを使用できます。
Windows システムの場合: 構成セットアップにおいて、HA 環境で稼働している 2 つの Dispatcher マシンのロード・バランシングを Site Selector で行うようにする場合は、Metric Server 用の Microsoft スタック上の別名を追加することが必要になります。 この別名が goActive スクリプトに追加されます。 例えば、以下のようになります。
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
goStandby および goInOp の場合は、この別名を除去することが必要になります。 例えば、以下のようになります。
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
マシン上に複数の NIC がある場合は、最初に、コマンド・プロンプトで次のコマンドを出すことによってどのインターフェースを使用するかを調べてください: netsh interface ip show address。 このコマンドは正しく構成されたインターフェースのリストを戻し、「ローカル・エリア接続」に番号を付ける (例えば、「ローカル・エリア接続 2」など) ので、どれを使用するかが判別できます。
Linux for S/390(R) の場合: Dispatcher は、IP アドレスをある Dispatcher から別の Dispatcher に移動するための無償 ARP を発行します。 従ってこのメカニズムは、基礎ネットワーク・タイプと関連しています。Linux for S/390 を実行しているとき、Dispatcher は、無償 ARP を発行してローカル・インターフェースでアドレスを構成できるインターフェースに対してのみ、高可用性の引き継ぎ (IP アドレスの移動を含む完全なもの) をネイティブに行うことができます。この仕組みは、IUCV や CTC などの point-to-point インターフェースでは正常に動作せず、また qeth/QDIO の一部の構成でも正常に動作しません。
Dispatcher のネイティブな IP 引き継ぎ機能が正常に動作しないこれらのインターフェースや構成の場合には、go スクリプトに適切なコマンドを置き、手動でアドレスを移動することができます。これで、ネットワークの接続形態も確実にハイ・アベイラビリティーの利益を受けられるようになります。
Windows サーバーでは、ハイ・アベイラビリティーと連結の両方を構成することが できます。ただし、Load Balancer のこの両機能を一緒に Windows システムで構 成するには、 さらにいくつかのステップが必要です。
Windows システムでは、連結とハイ・アベイラビリティーを同時に使用する場合、 Windows システム上のループバック・アダプターに追加できる追加の IP アドレス、 つまり一種のダミー IP アドレスが必要です。ループバック・アダプターは、 プライマリー・マシンとバックアップ・マシンの両方にインストールする必要があります。Windows システムでループバック・デバイスをインストールする場合は、ロード・バランシングのためのサーバー・マシンのセットアップで概説している手順に従ってください。
そのステップでクラスター IP アドレスをループバックに追加するよ うに指示されたら、 クラスター・アドレスではなくダミー IP アドレスを追加してください。その理由は、 Windows システム用のハイ・アベイラビリティー go* スクリプトが、Load Balancer マシンが 活動中か待機中かによって、ループバック・デバイスに対してクラスター・アドレスを 削除したり追加したりする必要があるためです。
Windows システムでは、最後に構成された IP アドレスはループバック・デバイスから 除去できません。ループバック・デバイスが DHCP モードでは機能しないためです。 ダミー・アドレスを使用すると、Load Balancer はそのクラスター・アドレスを いつでも除去できます。ダミー IP アドレスは、どんなタイプのトラフィックにも使用されないため、 活動中のマシンでも待機マシンでも使用することができます。
Load Balancer の go* スクリプトを活動中のマシンと待機マシンの両方で更新および移動し、 その後、Dispatcher を開始してください。クラスター・アドレスは、ネットワーク・インターフェースと ループバック・デバイスの両方で、適切なときに追加されたり除去されたりします。
ルール・ベースのロード・バランシングを使用して、パケットが送信されるサーバー、時刻、および理由を微調整することができます。Load Balancer は最初の優先度から最後の優先度に追加したルールをすべてレビューし、真である最初のルールで停止し、ルールに関連するサーバー間のコンテンツのロード・バランシングを行います。 ルールを使用しなくても 宛先およびポートに基づいてロード・バランシングが行われますが、ルールを使用すると接続を分散する機能を拡張することができます。
ルールを構成するときはほとんどの場合、その他の優先度が より高いルールによって渡される要求をキャッチするために、 デフォルトの常に真ルールを構成する必要があります。このデフォルトは、 他のすべてのサーバーがクライアント要求に失敗すると、「残念ながら、このサイトは現在ダウンしています。 後でやり直してください。」応答になる場合があります。
なんらかの理由でサーバーのサブセットを使用する場合は、ルールに基づいたロード・バランシングを Dispatcher および Site Selector とともに使用する必要があります。常に、CBR コンポーネントにはルールを使用し なければなりません。
ルールを構成に追加し始める前に、ルールがどのような 論理に従うかの計画を立ててください。
すべてのルールには名前、タイプ、優先順位があり、サーバーのセットと一緒に、範囲の開始値および範囲の終了値がある場合があります。 さらに、CBR コンポーネントのコンテンツ・タイプ・ルールには、それと関連付けられている一致している正規表現パターンもあります。 (コンテンツ・ルールおよびコンテンツ・ルールに有効なパターン構文の使用法の例とシナリオについては、付録 B. コンテンツ・ルール (パターン) 構文を参照してください。)
ルールは優先度の順序で評価されます。すなわち、優先度が 1 (小さい方の数) のルールは、優先度が 2 (大きい方の数) のルールより前に評価されます。条件を満たした最初のルールが適用されます。ルールが満たされると、それ以上のルールの評価は行われなくなります。
ルールが条件を満たすように、以下の 2 つの条件を満たさなければなりません。
ルールにサーバーが関連していない場合は、ルールは、条件 1 のみを満たしている必要があります。この場合、Dispatcher は接続要求をドロップし、Site Selector はネーム・サーバー要求をエラーで戻し、CBR は Caching Proxy がエラー・ページを戻すようにします。
ルールが満たされない場合、Dispatcher はポートで使用可能なサーバーの全セットからサーバーを選択し、Site Selector はサイト名で使用可能なサーバーの全セットからサーバーを選択し、CBR は Caching Proxy がエラー・ページを戻すようにします。
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
顧客を選別して顧客のアクセス元に基づいてリソースを割り振る場合は、クライアント IP アドレスに基づいたルールを使用することも考えられます。
例えば、IP アドレスの特定のセットからアクセスしているクライアントから、未払いの (したがって望ましくない) トラフィックが ネットワークに多く到着するとします。dscontrol rule コマンドを使用してルールを作成します。例えば、以下のようにします。
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
この "ni" ルールは、望ましくないクライアントからの接続を 排除します。その後、アクセスできるようにしたいサーバーをルールに追加します。サーバーをルールに追加しないと、9.x.x.x アドレスからの要求に対してサーバーが まったくサービスを提供しなくなります。
このルール・タイプは Dispatcher コンポーネントでしか使用できません。
要求時に TCP/IP から特定のポートを要求する種類の ソフトウェアをクライアントが使用している場合に、クライアント・ポートに基づくルールを使用したい場合があります。
例えば、クライアント・ポートが 10002 のクライアント要求が、特に大切な顧客からのアクセスであることが分かっているため、このポートを持つすべての要求が特別に高速のサーバーのセットを使用するように 指示するルールを作成することができます。
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
容量の計画のため、時刻に基づくルールを使用することも考えられます。例えば、Web サイトが毎日同じ時間帯に アクセスされる場合は、5 つの追加サーバーをピークの時間帯に専用にすることも考えられます。
時刻に基づくルールを使用する理由として、毎晩深夜に一部のサーバーを停止して保守するときに、保守に必要な時間だけそれらのサーバーを除外するルールを設定することなどがあげられます。
このルール・タイプは Dispatcher コンポーネントでしか使用できません。
IP ヘッダーの "type of service" (TOS) の内容に基づくルールを使用することも考えられます。 例えば、クライアント要求が、通常のサービスを示す TOS 値付きで着信した場合には、その要求を 1 つのサーバーのセットに経路指定することができます。別のクライアント要求が、優先順位が高いサービスを示す別の TOS 値付きで着信した場合には、その要求を別のサーバーのセットに経路指定することができます。
TOS ルールを使用すると、dscontrol rule コマンドを使用して、各ビットを TOS バイトで完全に構成することができます。 TOS バイトで一致させたい有効なビットには、0 または 1 を使用します。それ以外は、x を使用します。以下は、TOS ルールを追加する例です。
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
このルール・タイプは、Dispatcher および CBR コンポーネントで使用可能です。
サーバーのいくつかを他のアプリケーションで共用する必要がある場合に、1 秒当たりの接続数に基づくルールを使用したい場合があります。例えば、以下の 2 つのルールを設定できます。
Telnet を使用している場合に、1 秒当たりの接続数が特定のレベル以上に増加するときを除いて、Telnet 用の 5 つのサーバーのうち 2 つを予約したい場合もあります。このようにすると、Dispatcher によって、ピーク時に 5 つのサーバーの すべてにわたってロード・バランシングが行われます。
"connection" タイプ・ルールとともにルール評価オプション "upserversonrule" を設定する: 接続タイプ・ルールの使用時、および upserversonrule オプションの設定時に、サーバー・セット内のサーバーの一部が停止した場合、残りのサーバーが過負荷にならないことを確認できます。 詳細については、ルールのサーバー評価オプションを参照してください。
このルール・タイプは、Dispatcher または CBR コンポーネントで使用可能です。
サーバーが過負荷になり、パケットを破棄する場合に、ポートの活動状態の接続の総数に基づくルールを使用したい場合があります。特定の Web サーバーは、要求に応答するスレッドが十分にない場合でも接続を受け入れ続けます。この結果、クライアント要求はタイムアウトになり、Web サイトにアクセスしている顧客にサービスが提供されなくなります。活動状態の接続数に基づくルールを使用して、サーバーのプールで容量のバランスを取ることができます。
例えば、サーバーが 250 の接続を受け入れた後、サービスの提供を停止することが経験的に分かっているとします。 dscontrol rule コマンドまたは cbrcontrol rule コマンドを使用してルールを作成することができます。例えば、
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 または cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
このルールに、現行のサーバーと、他の処理に使用する追加サーバーを追加します。
予約済み帯域幅および共用帯域幅ルールは、Dispatcher コンポーネントでのみ使用可能です。
帯域幅ルールでは、Dispatcher は、データが特定のサーバー・セットによってクライアントに送達される速度として帯域幅を計算します。 Dispatcher は、サーバー、ルール、ポート、クラスター、および executor のレベルで容量を追跡します。 これらのレベルごとに、バイト・カウンター・フィールド (秒当たりの転送 K バイト数) があります。 Dispatcher はこれらの速度を 60 秒の間隔を基準に計算します。 これらの速度は GUI から、あるいはコマンド行報告の出力から表示できます。
予約済み帯域幅ルールによって、1 セットのサーバーによって送達された秒当たりの K バイト数を制御できます。 構成中のサーバーのセットごとにしきい値を設定する (指定された帯域幅の範囲を割り振る) ことによって、クラスターとポートの組み合わせごとに使用される帯域幅の量を制御および保証できます。
以下は、reservedbandwidth ルールを追加する例です。
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
範囲の開始値と範囲の終了値は秒当たりの K バイト数で指定します。
共用帯域幅ルールを構成する前に、sharedbandwidth オプションを指定した dscontrol executor または dscontrol cluster コマンドを使用して、executor レベルまたはクラスター・レベルで共用できる帯域幅の最大容量 (K バイト/秒) を指定しなければなりません。 sharebandwidth 値は、使用可能な合計帯域幅 (合計ネットワーク容量) を超えることはできません。dscontrol コマンドを使用して共用帯域幅を設定すると、ルールの上限だけが決まります。
以下は、コマンド構文の例です。
dscontrol executor set sharedbandwidth size dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size
sharedbandwidth の size は整数値 (秒当たりの K バイト数) です。デフォルトは 0 です。この値がゼロの場合は、帯域幅を共用できません。
帯域幅をクラスター・レベルで共用すると、クラスターは指定された最大帯域幅を使用できます。 クラスターによって使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が指定された容量より大きい場合、このルールは偽と評価されます。
executor レベルで帯域幅を共用することにより、Dispatcher 構成全体が最大容量の帯域幅を共用することができます。 executor レベルで使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が定義された容量より大きい場合、このルールは偽と評価されます。
以下は、sharedbandwidth ルールを追加または設定する例です。
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value dscontrol rule set 9.20.34.11:80:shrule sharelevel value
sharelevel の value は executor またはクラスターのいずれかです。sharelevel は sharebandwidth ルールで必須パラメーターの 1 つです。
Dispatcher によって、予約済み帯域幅 ルールを使用して、指定された帯域幅を構成内のサーバーのセットに割り振ることができます。 範囲の開始値と終了値を指定することにより、サーバーのセットによってクライアントに送達される K バイトの範囲を制御できます。 そのルールが真と評価されなくなる (範囲の終了値を超過する) と、次に低い優先度のルールが評価されます。 次に低い優先度のルールが「常に真」ルールの場合、サーバーがクライアントに「サイト・ビジー」応答を返すよう選択できます。
例: ポート 2222 に 3 つのサーバーによるグループがあると想定します。 予約済み帯域幅が 300 に設定されている場合、60 秒の期間に基づいて、1 秒当たりの最大 K バイトは 300 になります。 この速度を超えると、ルールは真と評価されません。 ルールがこれだけであれば、要求を処理するため、3 つのサーバーのうち 1 つが Dispatcher によって選択されます。 より低い優先度の「常に真」ルールがあれば、要求は別のサーバーにリダイレクトされ、「サイト・ビジー」を返される可能性があります。
共用帯域幅ルールは、クライアントへのサーバー・アクセスをさらに提供できます。 特に、予約済み帯域幅ルールに従う低い優先度のルールとして使用される場合、予約済み帯域幅を超過していても、クライアントはサーバーにアクセスできます。
例: 予約済み帯域幅ルールに従う共用帯域幅ルールを使用することによって、制限された方法でクライアントが 3 つのサーバーにアクセスするようにできます。 使用可能な共用帯域幅があるかぎり、ルールは真と評価され、アクセスが認可されます。 共用帯域幅がない場合、そのルールは真ではなく、次のルールが評価されます。 「常に真」ルールが後に続く場合、必要に応じて要求をリダイレクトできます。
前の例で説明した予約済みおよび共用帯域幅の両方を使用することによって、サーバーへのアクセスを認可 (または禁止) するとき、より大きな柔軟性と制御が可能になります。 帯域幅の使用において特定のポートでのサーバーを限定すると同時に、他のサーバーが可能なかぎり多くの帯域幅を使用するようにできます。
このルール・タイプは Site Selector コンポーネントでのみ使用できます。
メトリック全体ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みのサーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値は、実行するルールの範囲内になっていなければなりません。
以下は、メトリック全体ルールを構成に追加する例です。
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
このルール・タイプは Site Selector コンポーネントでのみ使用できます。
メトリック平均ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みの各サーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値の 平均 が、実行するルールの範囲内になっていなければなりません。
以下は、メトリック平均ルールを構成に追加する例です。
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
"常に真" のルールを作成することができます。このようなルールは、関連するサーバーがすべて停止しない限り、常に選択されます。このため、通常は、他のルールよりも 優先順位が低くなければなりません。
複数の "常に真" ルールを用意して、それぞれについて関連するサーバーのセットを持たせることができます。使用可能なサーバーを持つ最初の true のルールが選択されます。例えば、6 つのサーバーを持っているとします。このうちの 2 つに、両方とも停止してしまわない限り、あらゆる状況でトラフィックを処理させます。最初の 2 つのサーバーが停止した場合は、サーバーの 2 番目のセットにトラフィックを処理させます。これらのサーバーが 4 つとも停止した場合は、最後の 2 つのサーバーを使用してトラフィックを処理させます。この場合は、3 つの "常に真" ルールを設定することができます。サーバーの最初のセットは、少なくとも 1 つが稼働している限り常に選択されます。両方とも停止した場合は、2 番目のセットから 1 つ選択され、以下同様に行われます。
他の例として、"常に真" ルールによって、設定済みのどのルールとも着信クライアントが一致しない場合にサービスが提供されないようにしたい場合があります。以下のように dscontrol rule コマンドを使用してルールを作成します。
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
サーバーをルールに追加しないと、クライアント・パケットが応答なしのままドロップしてしまいます。
複数の "常に真" ルールを定義して、優先順位のレベルを変更することによって、実行するルールを調整することができます。
このルール・タイプは、CBR コンポーネントまたは Dispatcher コンポーネント (Dispatcher の CBR 転送方式を使用している場合) で使用可能です。
コンテンツ・タイプ・ルールを使用して、ユーザー・サイトのトラフィックのなんらかのサブセットを処理するようにセットアップされたサーバー・セットに要求を送信します。例えば、あるサーバー・セットを使用してすべての cgi-bin 要求を処理し、別のサーバー・セットを使用してすべてのストリーミング・オーディオ要求を処理し、さらに別のサーバー・セットを使用してその他のすべての要求を処理することができます。 cgi-bin ディレクトリーへのパスと一致するパターンを持つルールを追加し、ストリーミング・オーディオ・ファイルのファイル・タイプと一致するパターンを持つルールを追加し、さらにその他のトラフィックを処理するための、常に真のルールを追加します。 次に、該当するサーバーをそれぞれのルールに追加します。
重要: コンテンツ・ルールおよびコンテンツ・ルールに有効なパターン構文の使用法の例とシナリオについては、付録 B. コンテンツ・ルール (パターン) 構文を参照してください。
ポート類縁性のオーバーライドを使用すると、特定サーバーに対するポートのスティッキー性をオーバーライドすることができます。例えば、各アプリケーション・サーバーへの接続量を制限するルールを使用している とします。そして、オーバーフロー・サーバーは、そのアプリケーションに対して、「後でもう一度お試しください」というメッセージを常に出すように設定されているとします。 ポートの stickytime 値は 25 分です。したがって、クライアントがそのサーバーに対してスティッキーになることは望ましくありません。 ポート類縁性のオーバーライドを使用すると、オーバーフロー・サーバーを変更して、通常そのポートに関連した類縁性を変更することができます。 クライアントが次回にクラスターを要求するとき、オーバーフロー・サーバーではなく、最も使用可能なアプリケーション・サーバーでロード・バランシングが行われます。
サーバーの sticky オプションを使用したポート類縁性のオーバーライドのためのコマンド構文の詳細については、dscontrol server -- サーバーの構成を参照してください。
サンプル構成ファイルを編集することによって、あるいはグラフィカル・ユーザー・インターフェース (GUI) によって、dscontrol rule add コマンドを使用してルールを追加できます。定義したすべてのポートに 1 つまたは複数のルールを追加することができます。
これは、ルールを追加してから、ルールが真の場合にサービスを提供するサーバーを 定義するという 2 つのステップの処理です。例えば、システム管理者が サイトの各部門からのプロキシー・サーバーの使用の程度を追跡するとします。IP アドレスは部門ごとに与えられます。 クライアント IP アドレスに基づくルールの最初のセットを作成して、各部門の負荷を分割します。
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
次に、 異なるサーバーを各ルールに追加してから、各サーバーの負荷を測定し、 それらが使用したサービスに対して部門への請求が正しく行われるように します。例えば、以下のようになります。
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
サーバー評価オプションは Dispatcher コンポーネントでのみ使用可能です。
dscontrol rule コマンドには、ルールのサーバー評価オプションがあります。evaluate オプションは、ポートのすべてのサーバー間のルールの条件を評価するか、ルール内のサーバー間だけのルールの条件を評価する場合に使用します。 (Load Balancer の初期バージョンでは、ポート上のすべてのサーバー間の各ルールの条件を測ることしかできませんでした。)
注:
以下は、予約済み帯域幅ルールに評価オプションを追加または設定する例です。
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level dscontrol rule set 9.22.21.3:80:rbweval evaluate level
evaluate level は、port、rule、または upserversonrule のいずれかに設定できます。デフォルトは port です。
ルール内のサーバー間のルールの条件を測るためのオプションによって、以下の特性を使用して 2 つのルールを構成できます。
結果は、トラフィックが最初のルール内のサーバーのしきい値を超えると、トラフィックは 2 番目のルール内の「サイト・ビジー」サーバーに 送信されます。トラフィックが最初のルール内のサーバーのしきい値を下回ると、新規トラフィックは最初のルール内のサーバーにもう一度続けられます。
前の例で説明した 2 つのルールを使用して、最初のルールの evaluate オプションを port (ポート上のすべてのサーバー間でルールの条件を評価) に設定した場合は、トラフィックがそのルールのしきい値を超えると、トラフィックは 2 番目のルールと関連付けられている「サイト・ビジー」サーバーに送信されます。
最初のルールは、ポート上のすべてのサーバー・トラフィック (「サイト・ビジー」サーバーを含む) を測って、そのトラフィックがしきい値を超えているかどうかを判断します。最初のルールに関連したサーバーの輻輳が低下すると、ポートのトラフィックはまだ最初のルールのしきい値を超えているので、トラフィックは「サイト・ビジー」サーバーに送信され続けるという、意図しない結果が起こる場合があります。
Dispatcher および CBR コンポーネントの場合: クラスターのポートをスティッキーになるよう構成すると、類縁性機能が使用可能になります。 クラスターのポートをスティッキーになるように構成すると、以降のクライアント要求を同じサーバーに送信することができます。 これは、executor、クラスター、またはポート・レベルのスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不能になります。
ポート間類縁性を使用可能にしている場合は、共用ポートの stickytime 値は同じ (ゼロ以外) でなければなりません。 詳細については、ポート間類縁性を参照してください。
Site Selector コンポーネントの場合: サイト名をスティッキーになるよう構成すると、類縁性機能が使用可能になります。 sitename をスティッキーとして構成することにより、複数のネーム・サービス要求に対してクライアントは同じサーバーを使用できます。 これは、サイト名のスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不能になります。
サーバーのスティッキー時間値は、ある接続がクローズしてから 新しい接続がオープンするまでの時間間隔で、この間にクライアントは、 最初の接続で使用したサーバーと同じサーバーに送られます。スティッキー時間 の有効期限が切れると、クライアントは最初のサーバーとは異なるサーバ ーに送られる場合が あります。サーバーのスティッキー時間値は、dscontrol executor、 port、または cluster コマンドを使用して構成されます。
類縁性機能が使用不能な場合に、新しい TCP 接続がクライアントから受信されると、Load Balancer は、その時点の適切なサーバーを時間内に選出してパケットを転送します。 次の接続が同じクライアントから到着すると、Load Balancer はその接続を関連のない新しい接続として処理し、その時点の適切なサーバーを時間内に再度選出します。
類縁性機能を使用可能にすると、以降の要求を同じクライアントから受け取った場合に、その要求は同じサーバーに送信されます。
時間が経過すると、クライアントはトランザクションを終了し、類縁性レコードが廃棄されます。これがスティッキー "時間" の意味です。各類縁性レコードは、秒単位の "スティッキー時間" の間だけ存在し続けます。次の接続がスティッキー時間内に受信されると、類縁性レコードは有効のままになり、要求は同じサーバーに送信されます。次の接続がスティッキー時間外に受信されると、レコードは除去されます。その時間の後に受信される接続については、新しいサーバーがその接続に対して選択されます。
サーバーをオフラインにするには、サーバー・ダウン・コマンド (dscontrol server down) を使用します。サーバーが終了するのは、スティッキー時間値の有効期限が切れてからです。
ポート間類縁性は Dispatcher コンポーネントの MAC および NAT/NATP 転送方式にしか適用されません。
ポート間類縁性は、複数のポートを取り扱うために拡張されたスティッキー機能です。 例えば、クライアント要求を最初に 1 つのポートで受け取り、次の要求を別のポートで受け取る場合、ポート間類縁性を使用すると、Dispatcher はそのクライアント要求を同じサーバーに送信することができます。 この機能を使用するには、ポートを以下のようにしなければなりません。
2 つ以上のポートが、同じ crossport にリンクできます。同じポートまたは共用ポートの同じクライアントから引き続き接続が着信すると、同じサーバーがアクセスされます。以下は、ポート間類縁性をもつ複数のポートをポート 10 に構成している例です。
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
ポート間類縁性が確立されると、ポートの stickytime 値を柔軟に変更することができます。 ただし、すべての共用ポートの stickytime 値を同じ値に変更することをお勧めします。そうでないと、予想外の結果が発生する場合があります。
ポート間類縁性を除去するには、crossport 値を独自のポート番号に戻します。crossport オプションのコマンド構文の詳細については、dscontrol port -- ポートの構成を参照してください。
類縁性アドレス・マスクは Dispatcher コンポーネントにしか適用されません。
類縁性アドレス・マスクは、共通サブネット・アドレスを基に、クライアントをグループ化するためにスティッキー機能を拡張したものです。 dscontrol port コマンドに stickymask を指定することにより、32 ビット IP アドレスの共通高位ビットをマスクできます。 この機能が構成された場合、クライアント要求が最初にポートに接続すると、同じサブネット・アドレス (マスクされているアドレスのサブネット・アドレス部分で表される) を持つクライアントからの以降の要求すべてが、同じサーバーに送信されます。
例えば、同じネットワーク Class A アドレスをもつすべての着信クライアント要求を同じサーバーに送信したい場合は、そのポートの stickymask 値を 8 (ビット) に設定します。 同じネットワーク Class B アドレスをもつクライアント要求をグループ化するには、stickymask 値を 16 (ビット) に設定します。 同じネットワーク Class C アドレスをもつクライアント要求をグループ化するには、stickymask 値を 24 (ビット) に設定します。
最適な結果を得るには、Load Balancer の初回開始時に、stickymask 値を設定します。 stickymask 値を動的に変更すると、予期しない結果が発生します。
ポート間類縁性との相互作用: ポート間類縁性を使用可能にする場合は、共有ポートの stickymask 値は同じでなければなりません。詳細については、ポート間類縁性を参照してください。
類縁性アドレス・マスクを使用可能にするには、以下のような dscontrol port コマンドを発行します。
dscontrol port set cluster:port stickytime 10 stickymask 8
可能な stickymask 値は 8、16、24 および 32 です。 値 8 は、IP アドレス (ネットワーク Class A アドレス) の 最初の 8 の高位ビットをマスクすることを指定します。値 16 は、IP アドレス (ネットワーク Class B アドレス) の 最初の 16 の高位ビットをマスクすることを指定します。 値 24 は、IP アドレス (ネットワーク Class C アドレス) の 最初の 24 の高位ビットをマスクすることを指定します。 値 32 を指定すると、IP アドレス全体をマスクしていて、類縁性アドレス・マスク機能を効果的に使用不可にします。stickymask のデフォルト値は 32 です。
stickymask (類縁性アドレス・マスク機能) のコマンド構文の詳細については、dscontrol port -- ポートの構成を参照してください。
処理の静止は、Dispatcher および CBR コンポーネントに適用されます。
何らかの理由 (更新、アップグレード、保守など) でサーバーを Load Balancer 構成から除去するには、dscontrol manager quiesce コマンドを使用できます。quiesce サブコマンドによって、既存の接続は、(切断しないで) 完了し、その接続がスティッキーと指定されていて、スティッキー時間が満了していると、その後のクライアントからの新規接続のみを静止サーバーに転送できます。quiesce サブコマンドはそのサーバーへのその他のいかなる新規接続も認可しません。
スティッキー時間が設定されていて、スティッキー時間が満了する前に新規接続を (静止したサーバーの代わりに) 別のサーバーに送信したい場合は、quiesce "now" を使用します。 以下は、サーバー 9.40.25.67 を静止する now オプションの使用例です。
dscontrol manager quiesce 9.40.25.67 now
now オプションは、スティッキー接続を次のように処理する方法を判別します。
これは、安全かつ無理のないサーバーの静止方法です。例えば、サーバーを安全に静止してから、最少量のトラフィックしかない時間 (多分、早朝) を待って、構成からサーバーを除去できます。
dscontrol rule コマンドには、以下のタイプの類縁性を指定できます。
受動 Cookie は、CBR コンポーネントおよび Dispatcher コンポーネントの CBR 転送方式に適用されます。
URI 類縁性は、CBR コンポーネントおよび Dispatcher コンポーネントの CBR 転送方式に適用されます。
affinity オプションのデフォルトは "none" です。 活動 Cookie、受動 Cookie、または URI に対する rule コマンドで affinity オプションを設定するためには、port コマンドの stickytime オプションはゼロ (使用不可) になっていなければなりません。 類縁性がルールに対して設定されていると、そのポートで stickytime は使用可能にはできません。
活動 Cookie 類縁性フィーチャーが適用されるのは、CBR コンポーネントに対してだけです。
これは、特定のサーバーに対してクライアントを「スティッキー」にする方法を提供します。 この機能は、ルールのスティッキー時間を正数に設定し、類縁性を "activecookie" に設定することによって使用可能となります。これは、ルールを追加するか、あるいは rule set コマンドを使用すると実行できます。コマンド構文の詳細については、dscontrol rule -- ルールの構成を参照してください。
活動 Cookie 類縁性に対してルールが使用可能になると、同じクライアントからの正常に実行された要求が最初に選択したサーバーに送信される間に、標準 CBR アルゴリズムを使用して新規クライアント要求のロード・バランスされます。選択したサーバーは、クライアントへの応答で Cookie として保管されます。クライアントの将来の要求に Cookie が入っていて、各要求がスティッキー時間間隔内に到達する限り、クライアントは初期サーバーとの類縁性を保守します。
活動 cookie 類縁性は、同じサーバーに対する任意の期間のロード・バランシングをクライアントが継続することを確認するために使用されます。 これは、クライアント・ブラウザーが保管する Cookie を送信することによって実行されます。 Cookie には、決定を行うために使用した cluster:port:rule、ロード・バランシングを行ったサーバー、および類縁性が有効でなくなったときのタイムアウト・タイム・スタンプが含まれています。 Cookie は IBMCBR=cluster:port:rule+server-time! という形式になっています。 cluster:port:rule および server 情報はエンコードされているため、CBR 構成に関する情報は公開されません。
オンにされた活動 Cookie 類縁性があるルールが起動されると常に、クライアントによって送信される Cookie が調べられます。
次にこの新規 Cookie はクライアントに戻るヘッダーに挿入され、クライアントのブラウザーが Cookie を受け入れるように構成されている場合は以降の要求を戻します。
Cookie の類縁性インスタンスはそれぞれ、長さ 65 バイトで、感嘆符で終了します。 この結果、4096 バイトの Cookie は、ドメインごとに約 60 の活動状態 Cookie ルールを持つことができます。 Cookie が完全に一杯になると、すべての有効期限切れ類縁性インスタンスが除去されます。 すべてのインスタンスがまだ有効な場合、最も古いものがドロップされ、現在のルール用のインスタンスが追加されます。
ポート・スティッキー時間がゼロ (使用不可) である場合は、ルール・コマンドの活動 Cookie 類縁性オプションに設定できるのは activecookie だけです。 活動 Cookie 類縁性がルールに対して活動状態になっていると、そのポートで stickytime は使用可能にはできません。
特定のルールに対して、活動 cookie 類縁性を使用可能にするには、rule set コマンドを使用してください。
rule set cluster:port:rule stickytime 60 rule set cluster:port:rule affinity activecookie
ルール・スティッキーの作成は、通常はサーバー上のクライアント状態を保管する CGI またはサーブレットに使用されます。この状態は、Cookie ID によって識別されます (これがサーバー Cookie です)。クライアント状態は選択したサーバー上にのみ存在するので、 クライアントは要求間で状態を保持するためにそのサーバーからの Cookie を必要とします。
活動状態の Cookie 類縁性には、現在のサーバー時刻にスティッキー時間間隔を加算し、さらに 24 時間を加えたデフォルトの有効期限があります。 クライアント (CBR マシンに要求を送信している側) のシステムの時刻が不正確であると (例えば、サーバー時刻よりも 1 日進んでいると)、これらのクライアントのシステムでは、Cookie がすでに期限切れになっていると思い、CBR からの Cookie を無視してしまいます。 もっと長い有効期限を設定するには、cbrserver スクリプトを変更します。 これを行うためには、スクリプト・ファイル内の javaw 行を編集して、LB_SERVER_KEYS の後に -DCOOKIEEXPIREINTERVAL=X というパラメーターを追加します (ただし、X は有効期限に加算する日数です)。
AIX、Solaris、および Linux システムでは、cbrserver ファイルは /usr/bin ディレクトリーにあります。
Windows システムでは、cbrserver ファイルは \winnt\system32 ディレクトリーにあります。
受動 cookie 類縁性は、Dispatcher コンポーネントの Content Based Routing (CBR) 転送方式 および CBR コンポーネントに適用されます。Dispatcher の CBR 転送方式を構成する方法については、Dispatcher の Content Based Routing (CBR 転送方式) を参照してください。
受動 cookie 類縁性は、クライアントを特定のサーバーに対してスティッキーにする手段を提供します。ルールの類縁性が "passivecookie" に設定されていると、受動 cookie 類縁性によって、サーバーによって生成された自己識別 cookies を基にして、同一サーバーに対する類縁性で Web トラフィックをロード・バランシングできます。受動 cookie 類縁性はルール・レベルで構成してください。
ルールが始動されると、受動 Cookie 類縁性が使用可能になっている場合は、Load Balancer はクライアント要求の HTTP ヘッダー中の Cookie 名に基づいてサーバーを選択します。Load Balancer によって、クライアントの HTTP ヘッダーの Cookie 名と各サーバーに対して構成済みの Cookie 値との比較が開始されます。
Load Balancer は、Cookie 値にクライアントの Cookie 名を含む サーバーを最初に見つけたときに、要求に対してそのサーバーを選択します。
クライアント要求中の cookie 名が見つからないか、サーバーの cookie 値の内容のいずれとも一致しない場合は、サーバーは既存のサーバー選択か重み付きラウンドロビン技法を使用して選択されます。
受動 cookie 類縁性を構成するには、以下を行います。
ポート・スティッキー時間がゼロ (使用不可) の場合は、ルール・コマンドの受動 cookie 類縁性オプションに設定できるのは passivecookie だけです。受動 cookie 類縁性がルールに対して活動状態になっていると、ポートに対して stickytime は使用可能にはできません。
URI 類縁性は、Dispatcher の CBR 転送方式および CBR コンポーネントに適用されます。CBR 転送方式を構成する方法については、Dispatcher の Content Based Routing (CBR 転送方式) を参照してください。
URI 類縁性によって、固有のコンテンツを個々の個々の各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックをロード・バランシングできます。 この結果、複数のマシン上のコンテンツの冗長なキャッシュを除去することによって、サイトのキャッシュの容量が効果的に増加します。 URI 類縁性はルール・レベルで構成します。ルールが始動した後、URI 類縁性が使用可能になっていて、同一セットのサーバーが起動して応答している場合、Load Balancer は同じ URI が指定されている新規着信クライアント要求を同じサーバーに転送します。
一般に、Load Balancer は、同一のコンテンツを提供する複数のサーバーに要求を分散できます。キャッシュ・サーバーのグループとともに Load Balancer を使用すると、頻繁にアクセスされるコンテンツは、結局、すべてのサーバーのキャッシュに入れられた状態になります。これは、複数のマシンのキャッシュに入れられた同一のコンテンツを複製することによって、非常に高いクライアントの負荷をサポートします。これが特に役立つのは、高いボリュームの Web サイトの場合です。
しかし、Web サイトが非常に多様なコンテンツに対してクライアント・トラフィックの適度のボリュームをサポートしていて、より大容量のキャッシュを複数のサーバー間に分散したい場合、各キャッシュ・サーバーに固有のコンテンツが入っていて、Load Balancer がそのコンテンツが入っているキャッシュ・サーバーだけに要求を分散すると、ユーザーのサイトのパフォーマンスが向上します。
URI 類縁性を使用すると、Load Balancer によって、キャッシュに入れられたコンテンツを個々のサーバーに分散して、複数マシンでの冗長なキャッシュを除去できます。この機能強化によって、Caching Proxy サーバーを使用する多様なコンテンツ・サーバー・サイトのパフォーマンスは向上することになります。同一サーバーに送信されるのは同一の要求なので、コンテンツは単一サーバーでのみキャッシュに入れられます。さらに、キャッシュの有効サイズは、各新規サーバー・マシンがプールに追加されることによってさらに増大します。
URI 類縁性を構成するには、以下を行います。
ポート・スティッキー時間がゼロ (使用不可) の場合は、ルール・コマンドの URI 類縁性オプションに設定できるのは URI だけです。URI 類縁性がルールに対して活動状態になっていると、ポートに対して stickytime は使用可能にはできません。
この機能は Dispatcher コンポーネントにのみ使用可能です。
Dispatcher の広域サポートを使用しておらず、Dispatcher の NAT 転送方式を使用していない場合、Dispatcher 構成では、Dispatcher マシンおよびそのサーバーがすべて同一の LAN セグメントに接続されている必要があります (図 35 を参照してください)。 クライアントの要求は Dispatcher マシンに送られ、さらにサーバーに送信されます。 サーバーから、応答が直接クライアントに返されます。
図 35. 単一の LAN セグメントから構成される構成の例
広域 Dispatcher 機能では、リモート・サーバー として知られるオフサイト・サーバーのサポートが追加されています (図 36 を参照してください)。GRE がリモート・サイトでサポートされておらず、Dispatcher の NAT 転送方式を使用していない場合、そのリモート・サイトは、リモート Dispatcher マシン (Dispatcher 2) およびそのローカル接続されたサーバー (サーバー G、サーバー H、およびサーバー I) から成っていなければなりません。 クライアントのパケットは、インターネットからイニシャル Dispatcher マシンへ移動します。そのイニシャル Dispatcher マシンから、 パケットは、地理的リモート Dispatcher マシンおよびそのローカル接続サーバーの 1 つに移動します。
広域構成で実行するためには、すべての Dispatcher マシン (ローカルおよびリモート) が同じタイプのオペレーティング・システムおよびプラットフォーム上になければなりません。
図 36. ローカルおよびリモートのサーバーを使用する構成の例
これによって、1 つのクラスター・アドレスで、世界中のクライアント要求をすべてサポートするとともに、世界中のサーバーに負荷を分散させることができます。
さらに、パケットを最初に受信する Dispatcher マシンは、引き続きローカル・サーバーに接続しておくことができ、ローカル・サーバーとリモート・サーバーの間で負荷を分散させることができます。
広域サポートを構成するには、以下を行います。
dscontrol server add cluster:port:server router address
router キーワードの詳細については、dscontrol server -- サーバーの構成を参照してください。
エントリー・ポイント Dispatcher の場合:
AIX、Linux (GRE を使用)、または Solaris プラットフォームで稼働しているエントリー・ポイント Dispatcher は、アドバイザー・ロードを正常に表示します。他のプラットフォームは、ラウンドロビン・ロード・バランシングに依存するか、または広域ネットワーキングの代わりに、Dispatcher の nat/cbr 転送方式を使用する必要があります。
AIX システム
HP-UX システム
Linux システム
Solaris システム
arp -s my_cluster_address my_mac_address pub
Windows システム
リモート Dispatcher の場合: それぞれのリモート・クラスター・アドレスごとに、以下の構成ステップを行います。 リモート Dispatcher ロケーションにあるハイ・アベイラビリティー構成の場合は、 両方のマシンでこれらのステップを実行しなければなりません。
AIX システム
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
HP-UX システム、Linux、Solaris、および Windows システム
図 37. リモート Load Balancer がある構成の広域の例
この例は図 37 で説明する構成に適用します。
ここでは、Dispatcher マシンを構成して、ポート 80 のクラスター・アドレス xebec を サポートする方法について説明します。LB1 は「エントリー・ポイント」Load Balancer として定義されています。イーサネット接続を想定します。LB1 には定義済みのサーバーが 5 つ、すなわち、3 つのローカル (ServerA、ServerB、ServerC) および 2 つのリモート (LB2 および LB3) があることに注意してください。リモートの LB2 および LB3 には、それぞれ 3 つのローカル・サーバーが定義されています。
最初の Dispatcher (LB1) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
2 番目の Dispatcher (LB2) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
3 番目の Dispatcher (LB3) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
総称経路指定カプセル化 (GRE) は RFC 1701 および RFC 1702 に指定されているインターネット・プロトコルの 1 つです。GRE を使用することで、Load Balancer はクライアント IP パケットを IP/GRE パケットの内部にカプセル化し、それを GRE をサポートしている OS/390 などのサーバー・プラットフォームに転送できます。 GRE サポートによって、Dispatcher コンポーネントは、1 つの MAC アドレスと関連付けられている複数のサーバー・アドレス当てのパケットをロード・バランシングできます。
Load Balancer は GRE を WAN フィーチャーの一部として実装します。 これにより、Load Balancer は、GRE パケットをアンラップできるすべてのサーバー・システムに対する広域ロード・バランシングを直接提供できます。リモート・サーバーがカプセル化された GRE パケットをサポートしている場合、Load Balancer はリモート・サイトにインストールされている必要はありません。Load Balancer は、GRE キー・フィールドが 10 進数値 3735928559 に設定された WAN パケットをカプセル化します。
図 38. GRE をサポートするサーバー・プラットフォームがある広域の例の構成
この例 (図 38) では、GRE をサポートするリモートの ServerD を追加するために、WAN サーバーを cluster:port:server 階層内に定義する場合と同様に、ServerD を Load Balancer 構成内に定義します。
dscontrol server add cluster:port:ServerD router Router1
Linux システムには、GRE のカプセル化を解除するネイティブ機能があります。これによって、Load Balancer は、多くのサーバー・イメージが MAC アドレスを共用している Linux for S/390 サーバー・イメージに対してロード・バランシングを行うことができます。 これによってエントリー・ポイント Load Balancer は、リモート・サイトの Load Balancer を経由することなく、直接 Linux WAN サーバーに対するロード・バランシングを行うことが可能になります。 これにより、エントリー・ポイント Load Balancer の advisor は、各リモート・サーバーで直接操作することもできます。
エントリー・ポイント Load Balancer で、WAN の場合について説明したように構成してください。
それぞれの Linux バックエンド・サーバーを構成するには、root として以下のコマンドを実行します。 (これらのコマンドは、変更がリブート後も保持されるようにするために、システムの始動機能に追加することができます。)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add cluster address dev gre-nd
一般に、Dispatcher のロード・バランシング機能は、当製品が使用されるサイトの内容とは関係なく働きます。ただし、サイトの内容が重要であり、かつ内容に関する判断が Dispatcher の効率に重大な影響を与える可能性がある領域が 1 つあります。これは、リンク・アドレスの領域です。
サイトの個別のサーバーを指すリンクをページで指定すると、強制的にクライアントが特定のマシンにアクセスするようになるので、すべてのロード・バランシング機能が迂回され、効果がなくなってしまいます。このため、 ページに含まれるすべてのリンクで、常に Dispatcher のアドレスを使用してください。 サイトで自動プログラミングを使用して HTML を動的に作成する場合は、使用するアドレスの種類が常に明らかであるとは限りません。ロード・バランシングを最大限に活用するには、明示アドレスに注意して、可能な場合には回避しなければなりません。
プライベート・ネットワークを使用する Dispatcher および TCP サーバー・マシンを セットアップすることができます。この構成によって、パフォーマンスに影響を与える可能性がある公衆ネットワーク や外部ネットワークでの競合を削減することができます。
AIX システムの場合は、この構成によって、Dispatcher および TCP サーバー・マシンを SP フレームのノードで実行している場合に、高速な SP(TM) ハイパフォーマンス・スイッチを利用することもできます。
プライベート・ネットワークを作成するには、各マシンに少なくとも 2 つの LAN カードを用意し、一方のカードをプライベート・ネットワークに接続しなければなりません。異なるサブネットで 2 番目の LAN カードも 構成しなければなりません。Dispatcher マシンは、プライベート・ネットワークを介して TCP サーバー・マシンに クライアント要求を送信します。
Windows システム: executor configure コマンドを使用して、nonforwarding アドレスを構成してください。
dscontrol server add コマンドを使用して追加されたサーバーは、プライベート・ネットワーク・アドレスを使用して追加する必要があります。例えば、図 39 の Apple サーバーの例では、以下のようにコマンドをコーディングする必要があります。
dscontrol server add cluster_address:80:10.0.0.1
以下のようであってはなりません。
dscontrol server add cluster_address:80:9.67.131.18
Site Selector を使用して負荷情報を Dispatcher に提供している場合は、プライベート・アドレスに基づいて負荷を報告するように Site Selector を構成する必要があります。
図 39. Dispatcher を使用するプライベート・ネットワークの例
プライベート・ネットワーク構成は Dispatcher コンポーネントでしか使用できません。
ワイルドカード・クラスターを使用してサーバー構成を結合する操作は、Dispatcher コンポーネントでしか行えません。
"ワイルドカード" は、複数の IP アドレスに一致するクラスターの機能を指します (つまり、ワイルドカードとして機能します)。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
クラスター・アドレスの多くについてロード・バランシングを行っており、ポート/サーバー構成が全クライアントについて同じである場合は、すべてのクラスターを 1 つのワイルドカード・クラスター構成に結合することができます。
この場合でも、Dispatcher ワークステーションのネットワーク・アダプターのいずれかで、各クラスター・アドレスを明示的に構成しなければなりません。ただし、dscontrol cluster add コマンドを使用して 全クラスター・アドレスを Dispatcher 構成に追加する必要はありません。
ワイルドカード・クラスター (アドレス 0.0.0.0) のみを追加して、ロード・バランシングに必要な ポートおよびサーバーを構成します。アドレスを構成したアダプターへのトラフィックについては、すべてワイルドカード・クラスター構成を使用して ロード・バランシングが行われます。
この方法の利点は、最適なサーバーを判別するときに、すべてのクラスター・アドレスへのトラフィックが考慮されることです。1 つのクラスターが受信するトラフィックが多く、サーバーのいずれかで多くの活動状態の接続を作成した場合は、この情報を使用して、他のクラスター・アドレスへのトラフィックについて ロード・バランシングが行われます。
固有のポート/サーバー構成を持つクラスター・アドレスがある場合は、ワイルドカード・クラスターを実際のクラスターと結合し、いくつかを共通構成と結合することができます。固有の構成は、それぞれ実際のクラスター・アドレスに割り当てなければなりません。共通構成は、すべてワイルドカード・クラスターに割り当てることができます。
ワイルドカード・クラスターを使用しファイアウォールをロード・バランシングする操作は、Dispatcher コンポーネントでしか行えません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
ワイルドカード・クラスターは、Dispatcher ワークステーションのネットワーク・アダプターで明示的に 構成されていないアドレスへのトラフィックについてロード・バランシングを 行うために使用することができます。これを行うためには、少なくとも、ロード・バランシングを行うトラフィックを Dispatcher が すべて確認することができなければなりません。Dispatcher ワークステーションは、トラフィックのセットに対するデフォルトの経路としてセットアップされていない限り、そのネットワーク・アダプターのいずれでも明示的に構成されていない アドレスへのトラフィックを確認しません。
一度 Dispatcher をデフォルトの経路として構成すると、Dispatcher マシンを介した TCP トラフィックまたは UDP トラフィックは、すべてワイルドカード・クラスター構成を使用してロード・バランシングが行われます。
このアプリケーションの 1 つは、ファイアウォールのロード・バランシングを行うためのものです。ファイアウォールは、すべての宛先アドレスおよび宛先ポートに対するパケットを処理するので、宛先アドレスおよびポートに関係なく、トラフィックのロード・バランシングを行える必要があります。
ファイアウォールは、保護されていないクライアントから保護されたサーバーまでのトラフィック、および保護されたサーバーからの応答をはじめ、保護された側のクライアントから保護されていない側のサーバーへのトラフィック および応答を処理するために使用されます。
2 つの Dispatcher マシンをセットアップし、一方のマシンでは保護されていないファイアウォール・アドレスに対して 保護されていないトラフィックのロード・バランシングを行い、もう一方のマシンでは 保護されたファイアウォール・アドレスに対して保護されたトラフィックのロード・バランシングを 行わなければなりません。これらの Dispatcher の両方が、サーバー・アドレスの異なるセットとともに ワイルドカード・クラスターおよびワイルドカード・ポートを使用しなければならないので、2 つの Dispatcher は 2 つの別個のワークステーションになければなりません。
ワイルドカード・クラスターを Caching Proxy とともに透過プロキシーに使用する操作は、Dispatcher コンポーネントでしか行えません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
また、ワイルドカード・クラスター機能によって、Dispatcher を使用して Dispatcher と同じマシン上にある Caching Proxy サーバーの透過プロキシー機能を使用可能にできます。 これは、Dispatcher コンポーネントからオペレーティング・システムの TCP コンポーネントへの通信が必要なので、AIX のみの機能です。
この機能を使用可能にするには、Caching Proxy によるポート 80 でのクライアント要求の listen を開始しなければなりません。 その後、ワイルドカード・クラスターを構成します (0.0.0.0)。ワイルドカード・クラスターで、ポート 80 を構成します。ポート 80 で、Dispatcher マシンの NFA を唯一のサーバーとして構成します。これで、ポート 80 の任意のアドレスに対するクライアント・トラフィックが、すべて Dispatcher ワークステーションで実行されている Caching Proxy サーバーに送達されるようになります。 クライアント要求は、通常どおりに代行され、応答が Caching Proxy からクライアントに返送されます。このモードでは、Dispatcher コンポーネントはロード・バランシングを行いません。
ワイルドカード・ポートは、明示的に構成されたポートに 対するトラフィックではないトラフィックを処理するために使用することができます。例えば、ファイアウォールのロード・バランシングに使用することができます。また、構成されていないポートへのトラフィックが適切に処理されることを 確認するために使用することもできます。サーバーを指定せずにワイルドカード・ポートを定義することによって、構成されていないポートへの要求が確実に廃棄され、オペレーティング・システムには戻されないようにすることができます。 ポート番号 0 (ゼロ) は、ワイルドカード・ポートを指定するために使用します。例えば、以下のようになります。
dscontrol port add cluster:0
受動 FTP およびワイルドカード・ポート処理のためにクラスターを構成すると、受動 FTP はデータ接続のためにデフォルトで非特権 TCP ポート範囲全体を使用します。これは、クライアントが、ロード・バランシング・クラスターを通じた FTP 制御ポートへの既存接続で、Load Balancer によって FTP 制御接続と同じサーバーに自動的に経路指定された同じクラスターへの後続の制御接続および高位ポート接続 (ポート >1023) を持つことを意味します。
同じクラスター上のワイルドカード・ポートと FTP ポートのサーバー・セットが同じでない場合、高位ポート・アプリケーション (ポート >1023) は、クライアントに既存の FTP 制御接続がないと失敗する可能性があります。したがって、同一クラスター上の FTP とワイルドカード・ポートに異なるサーバー・セットを構成することはお勧めしません。このシナリオが望ましい場合は、FTP デーモン受動ポートの範囲は Load Balancer 構成内で構成しなければなりません。
この機能は Dispatcher コンポーネントにのみ使用可能です。
Dispatcher は、潜在的な「サービス妨害」攻撃を検出し、アラートによって管理者に通知する機能を提供します。Dispatcher は、 サーバーでハーフ・オープン TCP 接続の著しい量の受信要求 (単純なサービス妨害攻撃 (Denial of Service Attack) の特性) を 分析することによってこれを行います。 サービス妨害攻撃では、サイトは多数の送信元 IP アドレスおよび送信元ポート番号から大量の偽造された SYN パケットを受信しますが、このサイトはそれらの TCP 接続用のその後のパケットを 1 個も受信しません。これにより、サーバー上で多数の TCP 接続がハーフ・オープン状態になり、時を経るとサーバーは非常に低速化して、新規着信接続を全く受け入れなくなる可能性があります。
Load Balancer は、サービス妨害攻撃の可能性を示すアラートを管理者に通知する、カスタマイズ可能なスクリプトを起動するユーザー出口を提供します。 Dispatcher は、次のサンプル・スクリプト・ファイルを ...ibm/edge/lb/servers/samples ディレクトリーに提供しています。
このファイルを実行するためには、それらのファイルを ...ibm/edge/lb/servers/bin ディレクトリーに移動して、".sample" ファイル拡張子を除去しなければなりません。
DoS 攻撃検出をインプリメントするには、maxhalfopen パラメーターを dscontrol port コマンドで次のように設定します。
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
前述の例では、Dispatcher はハーフ・オープンの現在の合計接続数 (ポート 80 のクラスター 127.40.56.1 にあるすべてのサーバー) としきい値 1000 (maxhalfopen パラメーターによって指定) を比較します。現在のハーフ・オープン接続数がこのしきい値を超えると、アラート・スクリプト (halfOpenAlert) への呼び出しが行われます。ハーフ・オープン接続数がこのしきい値を下回っていると、攻撃は終了していることを示すために、別のアラート・スクリプト (halfOpenAlertDone) への呼び出しが行われます。
maxhalfopen 値を設定する方法を判別する場合: ユーザー・サイトで中から高程度のトラフィックが発生しているときに、定期的に (例えば 10 分ごとに) ハーフ・オープン接続報告 (dscontrol port halfopenaddressreport cluster:port) を実行します。 ハーフ・オープン接続報告は、現在の「合計受信ハーフ・オープン接続数」を戻します。 maxhalfopen は、ユーザー・サイトで経験しているハーフ・オープン接続の最大数より 50 から 200% 大きな値に設定する必要があります。
報告される統計データの他に、halfopenaddressreport は、ハーフ・オープン接続になったサーバーにアクセスしたクライアント・アドレス (最大約 8000 個までのアドレスのベア) すべてのログ (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) 中に項目を生成します。
バックエンド・サーバーのサービス妨害攻撃からの追加保護を提供するために、ワイルドカード・クラスターおよびポートを構成できます。特に各構成済みクラスターの下にサーバーを使用しないワイルドカード・ポートを追加してください。また、ワイルドカード・ポートがあってサーバーがないワイルドカード・クラスターも追加してください。これには、非ワイルドカード・クラスターおよびポートを扱わないすべてのパケットを廃棄する効果があります。ワイルドカード・クラスターおよびワイルドカード・ポートの詳細については、ワイルドカード・クラスターを使用したサーバー構成の結合およびワイルドカード・ポートを使用した未構成ポート・トラフィックの送信を参照してください。
バイナリー・ログ機能を使用すれば、サーバー情報をバイナリー・ファイルに保管できます。 これらのファイルを処理して、ある時間にわたって収集されたサーバー情報を分析することができます。
以下の情報が、構成で定義されたサーバーごとのバイナリー・ログに保管されます。
この情報には、manager サイクルの一部として executor から取得されるものもあります。したがって、情報をバイナリー・ログに記録するために、manager が実行されていなければなりません。
dscontrol log コマンド・セットを使用して、バイナリー・ロギングを構成します。
start オプションは、ログ・ディレクトリーにあるバイナリー・ログへのサーバー情報の記録を開始します。ログは、毎時 0 分に その日時をファイル名として作成されます。
stop オプションは、バイナリー・ログへのサーバー情報の 記録を停止します。ログ・サービスは、デフォルトによって停止しています。
set interval オプションは、情報がログに 書き込まれる頻度を制御します。manager はサーバー情報を manager 間隔ごとにログ・サーバーへ送信します。情報は、最後にログにレコードが書き込まれてから、指定した秒数の経過後にログに書き込まれます。 デフォルトでは、ログ記録間隔は 60 秒に設定されています。manager 間隔と ログ記録間隔の設定の間には、相関関係があります。ログ・サーバーは manager 間隔秒数以下の速度で情報を提供するので、manager 間隔より短いログ記録間隔を設定しようとしても、実際には manager 間隔と同じ値に設定されます。このログ記録方法によって、サーバー情報を取り込む頻度を任意に細分化することができます。サーバーの重みを計算するために、manager によって確認されるサーバー情報に対する 変更をすべて取り込むことができます。ただし、おそらく、この情報は、サーバーの使用および傾向の分析に必要ではありません。60 秒ごとにサーバー情報をログ記録すると、時間の経過とともにサーバー情報のスナップショットがとられます。ログ記録間隔を非常に低く設定すると、膨大な量のデータが生成される場合があります。
set retention オプションは、ログ・ファイルが保持される期間を制御します。指定した保存時間よりも古いログ・ファイルは、ログ・サーバーによって削除されます。これは、ログ・サーバーが manager によって 呼び出されている場合にのみ行われるので、manager が停止していると古いログ・ファイルでも削除されません。
status オプションは、ログ・サービスの現行の設定を戻します。これらの設定は、サービスが開始されているかどうか、間隔、および保存時間です。
サンプル Java プログラムおよびコマンド・ファイルは、...ibm/edge/lb/servers/samples/BinaryLog ディレクトリーに提供されています。このサンプルは、ログ・ファイルからすべての情報を検索して画面に出力する方法を示します。カスタマイズすると、データについて必要な種類の分析を行うことができます。Dispatcher に提供されているスクリプトおよびプログラムの使用例を以下に示します。
dslogreport 2001/05/01 8:00 2001/05/01 17:00
これによって、2001 年 5 月 1 日の午前 8:00 から午後 5:00 までの Dispatcher コンポーネント・サーバー情報の報告書が得られます。 (CBR の場合、cbrlogreport を使用してください。)
Load Balancer と同一マシンにクライアントを配置する構成を サポートしているのは、Linux システムのみです。
連結クライアント構成は、他のプラットフォームでは正しく機能しない場合があります。 これは、Load Balancer が別の手法を使用して、サポートする各種のオペレーティング・システムで 着信パケットを検査するためです。ほとんどの場合、 Linux 以外のシステムでは、Load Balancer はローカル・マシンからのパケットを 受信しません。ネットワークから入ってくるパケットだけを受信します。このため、 ローカル・マシンからクラスター・アドレスへの要求は、Load Balancer によって受信されず、 サービスの対象にもなりません。
この章には、以下のセクションが含まれています。
Cisco CSS Controller または Nortel Alteon Controller は、要求のロード・バランシングを行っているサーバーと同じマシン上に常駐できます。 これは一般に、サーバーの連結と呼ばれています。追加の構成ステップは必要ありません。
Cisco CSS Controller および Nortel Alteon Controller で高可用性機能が使用可能になりました。
コントローラー耐障害性を向上させるため、ハイ・アベイラビリティー機能には以下のフィーチャーが含まれています。
xxxcontrol highavailability の完全な構文については、ccocontrol highavailability -- 高可用性の制御および nalcontrol highavailability -- 高可用性の制御を参照してください。
コントローラーのハイ・アベイラビリティーを構成するには、次のようにします。
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondary
address パラメーターと partneraddress パラメーターは、プライマリーおよびセカンダリー・マシンで逆になります。
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20
ローカルおよびパートナー・コントローラーで、同数のリーチ・ターゲットを構成しなければなりません。
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeover
これは保守用にのみ必要です。
注:
heartbeat メッセージによって検出される、アクティブ・コントローラーと待機コントローラー間での接続性の 喪失以外に、到達可能性というもう 1 つの障害検出機構があります。
コントローラー・ハイ・アベイラビリティーを構成する場合は、正しく機能するようにするために、コントローラーのそれぞれが到達しなければならないホストのリストを提供できます。 コントローラー・マシンが使用するサブネットごとに、少なくとも 1 つのホストがなければなりません。 これらのホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。
ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合、またはアクティブ・コントローラーが到達可能性基準に一致しなくなり、待機コントローラーが到達可能である場合は、切り替えが起こります。すべての使用可能な情報をもとにこの判断を行うため、アクティブ・コントローラーは、その到達可能性の機能を定期的に待機コントローラーに送信します。その反対の場合も同じです。次にコントローラーは到達可能性情報をそのパートナーの情報と比較し、どちらを活動状態にすべきかを決定します。
2 つのコントローラー・マシンの役割は、プライマリーおよびセカンダリーとして構成されています。 始動時に、これらのコントローラー・マシンは、各マシンが同期化するまで、情報を交換します。 この時点で、プライマリー・コントローラーは活動状態となり、重みの計算とスイッチの更新を開始しますが、セカンダリー・マシンは待機状態に移り、プライマリー・マシンの可用性をモニターします。
待機マシンはいつでも、活動状態のマシンの障害を検出すると、活動状態のマシン (障害を起こした) の ロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンが再び作動可能になると、この 2 つのマシンは、リカバリー・ストラテジーの構成内容に従って、どちらのコントローラーが活動状態になるかを決定します。
リカバリー・ストラテジーには、以下の 2 種類があります。
プライマリー・コントローラーは活動状態になり、重みを計算および更新し、再び作動可能になります。 セカンダリー・マシンは、プライマリーが活動状態になった後、待機状態に移ります。
活動状態のセカンダリー・コントローラーは、プライマリー・コントローラーが作動可能になった後でも、アクティブ状態のままです。
プライマリー・コントローラーは待機状態に移ります。 活動状態に移るには、手動による介入が必要です。
ストラテジー・パラメーターの設定は、両マシンとも同じでなければなりません。
Cisco CSS Controller の HA 構成の例については、例を参照してください。
Nortel Alteon Controller の HA 構成の例については、例を参照してください。
Load Balancer のコントローラー機能は、以下の設定を基にしてロード・バランシングを実行します。
これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。
コントローラーは、その重みの判断で、以下のメトリック・コレクターの一部またはすべてを使用できます。
デフォルトのメトリックは activeconn と connrate です。
メトリック値の相対的な重要性の割合を変更できます。 この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトでは、活動中の接続および新規接続メトリックが使用され、その割合は 50 対 50 です。 ユーザーの環境では、最良のパフォーマンスが得られる組み合わせを判別するため、別のメトリック割合の組み合わせを試す必要がある場合があります。
割合値を設定するには、以下のように入力します。
重みは、アプリケーション応答時間と可用性、advisor からのフィードバック、および Metric Server などのシステム・モニター・プログラムからのフィードバックに基づいて設定されます。重みを手作業で設定する場合は、サーバーに fixedweight オプションを指定してください。 fixedweight オプションについては、コントローラー固定重みを参照してください。
重みは、サービスを提供するすべてのポートに適用されます。特定のサービスについて、要求は、互いに相対的な重みに基づいてサーバー間で分散されます。 例えば、一方のサーバーが重み 10 に設定され、他方が 5 に設定されると、10 に設定されたサーバーは 5 に設定されたサーバーの 2 倍の要求を得るはずです。
advisor は、サーバーが停止したことを検出した場合には、サーバーの重みは -1 に設定されます。 Cisco CSS Controller および Nortel Alteon Controller の場合、サーバーが使用不可であることがスイッチに伝えられ、スイッチはサーバーに接続を割り当てることを停止します。
コントローラーがなければ、advisor は実行されず、サーバーがダウンしているかどうかを検出することができません。 advisor を実行することを選択するが、特定のサーバー用に設定した重みをコントローラーに更新させたくない場合には、Cisco CSS Controller では ccocontrol service コマンドで、または Nortel Alteon Controller では nalcontrol server コマンドで fixedweight オプションを使用します。
重みに所要の値を設定するには、fixedweight コマンドを使用します。 固定重みが no に設定された別のコマンドが発行されるまで、コントローラーが実行されている間は、サーバー重みの値は固定されたままです。
全体的パフォーマンスを最適化するには、メトリック収集の回数を制限することができます。
コンサルタント・スリープ時間は、コンサルタントがサーバーの重みを更新する回数を指定します。 コンサルタント・スリープ時間が短すぎると、コンサルタントが絶えずスイッチに割り込むことになり、パフォーマンスの低下が生じることになります。 コンサルタント・スリープ時間が長過ぎる場合は、スイッチのロード・バランシングが正確な最新情報に基づいていないことを意味します。
例えば、コンサルタント・スリープ時間を 1 秒に設定するには、以下のコマンドを入力します。
xxxcontrol consultant set consultantID sleeptime interval
他の方法を使用して、サーバーのロード・バランシングを最適化することができます。 最高速で働くために、サーバーの重みが大幅に変わった場合にだけそれが更新されます。サーバー状況にほとんど変更がないのに、絶えず重みを更新すると、無用なオーバーヘッドを生むことになります。 サービスを提供するすべてのサーバーの重みの合計に対するパーセントの重みの変更が重要度しきい値より大きい場合には、Load Balancer が接続を分散するために使用する重みは更新されます。 例えば、重みの合計が 100 から 105 に変化したとします。変化は 5% です。デフォルトの重要度しきい値の 5 では、変化率がしきい値を超えないので、Load Balancer が使用する重みは更新されません。 ただし、重みの合計が 100 から 106 に変化すると、重みは更新されます。 コンサルタントの重要度しきい値をデフォルト以外の値に設定するには、以下のコマンドを入力します。
xxxcontrol consultant set consultantID sensitivity percentageChange
ほとんどの場合に、この値を変更する必要はありません。
advisor は Load Balancer 内のエージェントです。advisor は、サーバー・マシンの状態および負荷の状態を評価することを目的とします。 これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。
advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP "HEAD" 要求をサーバーに送信します。
advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この負荷値を 計算するため、advisor のほとんどは、サーバーが応答するまでの時間を測定して、負荷としてこの値 (ミリ秒単位) を使用します。
次に advisor は、負荷値をコンサルタント機能に報告します。この値はコンサルタント報告書に出力されます。 コンサルタントは、その割合に応じて全送信元からの重み値を集計して、これらの重み値をスイッチに送信します。 スイッチは、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。
サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値をコンサルタントに報告します。 サーバーが活動状態でないと advisor が判断した場合は、サーバーがダウンしていることをスイッチに伝えるために特別な負荷値である -1 を戻します。 その後、スイッチは、サーバーが再びアップするまで、それ以上そのサーバーに接続を転送しなくなります。
advisor スリープ時間は、advisor がモニターして、その結果をコンサルタントに報告するポートのサーバーから状況を求める頻度を設定します。 advisor スリープ時間が短すぎると、advisor が絶えずサーバーに割り込むことになるため、パフォーマンスの低下が生じることになります。 advisor スリープ時間が長すぎる場合は、コンサルタントの重みに関する決定が正確な最新情報に基づいていないことを意味します。
例えば、HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。
xxxcontrol metriccollector set consultantID:HTTP sleeptime 3
サーバーまたはサービス上の特定のポートに障害が起きたことを検出するために費やす時間の値を設定することができます。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待機する時間が決定されます。
障害が発生したサーバーを最短時間で検出するには、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor およびコンサルタント・スリープ時間も最小値 (1 秒) に設定します。
HTTP advisor の場合に、timeoutconnect を 9 秒に設定するには、以下のコマンドを入力します。
xxxcontrol metriccollector set consultantID:HTTP timeoutconnect 9
接続タイムアウトと受信タイムアウトのデフォルトは、advisor スリープ時間に指定されている値の 3 倍です。
advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 だけサーバー照会が失敗するまでは、サーバーをダウンとしてマーク付けしません。設定されなければ、デフォルトで retry 値はゼロになります。
Cisco CSS Controller の場合、ccocontrol ownercontent set コマンドを使用して retry 値を設定します。 詳細については、ccocontrol ownercontent -- 所有者名およびコンテンツ・ルールの制御を参照してください。
Nortel Alteon Controller の場合、nalcontrol service set コマンドを使用して retry 値を設定します。 詳細については、nalcontrol service -- サービスの構成を参照してください。
カスタム (カスタマイズ可能) advisor は、基本コードによって呼び出される小規模な Java コードで、ユーザーによりクラス・ファイルとして提供されます。 基本コードは、以下に示すようなすべての管理サービスを提供します。
また、結果をコンサルタントに報告します。基本コードは advisor サイクルを定期的に実行し、各サイクルで構成内のサーバーをすべて評価します。 これは、サーバー・マシンとの接続を オープンすることによって開始されます。ソケットがオープンすると、基本コードは、カスタム advisor の getLoad メソッド (関数) を呼び出します。 その後、カスタム advisor は、サーバーの状態を評価するために必要なステップをすべて実行します。 一般的には、ユーザー定義のメッセージをサーバーに送信してから応答を待機します。 (オープンしたソケットへのアクセスがカスタム advisor に提供されます。) その後、基本コードは、サーバーとのソケットをクローズして、コンサルタントに負荷情報を報告します。
基本コードおよびカスタム advisor は、通常モードおよび置換モードのいずれでも機能します。動作モードの選択は、カスタム advisor ファイルでコンストラクター・メソッドのパラメーターとして指定します。
通常モードでは、カスタム advisor がサーバーとデータを交換し、基本 advisor コードが交換の時間を測定して負荷値を計算します。基本コードは、この負荷値をコンサルタントに報告します。 カスタム advisor は、0 (正常) または負の値 (エラー) を戻す必要があるのみです。通常モードを指定するには、コンストラクターの代替フラグを false に設定します。
置換モードでは、基本コードはいかなる時間測定も行いません。カスタム advisor コードは、固有の要件に必要な操作をすべて実行して、実際の負荷値を戻します。基本コードは、その数値を受け入れて、コンサルタントに報告します。 最善の結果を得るためには、負荷値を 10 から 1000 までの間に正規化し、10 で高速なサーバーを表し、1000 で低速なサーバーを表してください。置換モードを指定するには、コンストラクターの代替フラグを true に設定します。
この機能によって、ユーザー自身の advisor を作成し、必要とするサーバーに関する正確な情報を得ることができます。 サンプルのカスタム advisor、 ADV_ctlrsample.java はコントローラーに添付されています。 Load Balancer のインストール後、サンプル・コードは、...ibm/edge/lb/servers/samples/CustomAdvisors インストール・ディレクトリーにあります。
デフォルトのインストール・ディレクトリーは以下のとおりです。
カスタム advisor のファイル名は ADV_myadvisor.java の形式でなければなりません。 つまり、大文字の接頭部 ADV_ で始まらなければなりません。 それ以後の文字は、すべて小文字でなければなりません。
Java の規則に従い、ファイル内で定義されたクラスの名前は、ファイルの名前と一致していなければなりません。サンプル・コードをコピーする場合は、ファイル内の ADV_ctrlsample のインスタンスをすべて新しいクラス名に変更してください。
カスタム advisor は、Java 言語で作成します。Load Balancer と共にインストールされた Java コンパイラーを使用してください。 コンパイル時には、以下のファイルが参照されます。
クラスパスは、コンパイル時にカスタム advisor ファイルと基本クラス・ファイルの両方を指していなければなりません。
Windows プラットフォームの場合、コンパイル・コマンドは以下のようになります。
install_dir/java/bin/javac -classpath install_dir\lb\servers\lib\ibmlb.jar ADV_pam.java
ここで、
コンパイルの出力は以下のようなクラス・ファイルです。 例えば、以下のようになります。
ADV_pam.class
advisor を開始する前に、クラス・ファイルを ...ibm/edge/lb/servers/lib/CustomAdvisors インストール・ ディレクトリーにコピーしてください。
AIX、HP-UX、Linux、および Solaris システムでの構文は似ています。
カスタム advisor を実行するには、次のように、最初にクラス・ファイルを正しいインストール・ディレクトリーに コピーしなければなりません。
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
コンサルタントを開始し、続いて、次のコマンドを実行してカスタム advisor を開始します。
ここで、
すべての advisor と同様に、カスタム advisor は、ADV_Base という advisor ベースの機能を拡張します。これは、コンサルタントの 重みのアルゴリズムで使用するためにコンサルタントに負荷を報告するなどの advisor の機能のほとんどを実際に実行する advisor ベースです。 また、advisor ベースは、ソケット接続とクローズ操作も実行し、advisor が使用するための send および receive メソッドを提供します。advisor 自体は、アドバイスされるサーバーのポートとの間で データを送受信するためにのみ使用されます。advisor ベースの TCP メソッドは時間が測定され、負荷が計算されます。必要な場合は、ADV_base のコンストラクターにあるフラグによって、advisor から戻された新しい負荷で既存の負荷が上書きされます。
基本クラスのメソッドを以下に示します。
コントローラーは、最初に、提供されているネイティブ advisor のリストを参照します。 指定された advisor がそこに見つからないと、コントローラーはカスタム advisor のリストを参照します。
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:¥Program Files¥IBM¥edge¥lb¥servers¥lib¥CustomAdvisors
コントローラーのサンプル advisor のプログラム・リストは、サンプル advisor に入っています。インストールすると、このサンプル advisor は ...ibm/edge/lb/servers/samples/CustomAdvisors ディレクトリーに入ります。
Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer コンサルタントは、各サーバーに常駐している Metric Server エージェントに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も、Cisco CSS Controller ではサービス報告書に、または Nortel Alteon Controller ではサーバー報告書に入ります。
Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。
以下は、コントローラーの Metric Server を構成するためのステップです。
Nortel Alteon Controller の場合、スイッチ・コンサルタントを追加し、続いて、サービスを追加します。
ここで、metricName は、Metric Server スクリプトの名前。
システム・メトリック・スクリプトは、バックエンド・サーバーにあって、指定された ownercontent または service の下の構成でサーバーそれぞれで実行します。 2 つのスクリプト (cpuload および memload) が提供されるか、またはカスタム・システム・メトリック・スクリプトを作成できます。 スクリプトには、数値を返すコマンドが入っています。この数値はロード測定値を表しますが、これは使用可能な値ではありません。
制限: Windows システムの場合は、システム・メトリック・スクリプトの名前に .exe 以外の拡張子が付いている場合、ファイルのフルネーム (例えば、mySystemScript.bat) を指定する必要があります。 これは Java コードの制限です。
オプションで、Metric Server がサーバー・マシンで出すコマンドを定義したユーザー独自のカスタマイズ済みメトリック・スクリプト・ファイルを作成できます。 すべてのカスタム・スクリプトが実行可能であること、および ...ibm/edge/lb/ms/script ディレクトリーにあることを確認してください。カスタム・スクリプトは、数字の負荷の値を戻さなければなりません。
Metric Server がローカル・ホスト以外のアドレスで実行されるようにするには、ロード・バランシングされるサーバー・マシン上の metricserver ファイルを編集します。metricserver ファイル中の java の後に、以下を挿入します。
-Djava.rmi.server.hostname=OTHER_ADDRESS
さらに、metricserver ファイル中の "if" ステートメントの前に、次の行を追加します。 hostname OTHER_ADDRESS。
Windows システムの場合: Microsoft スタック上の OTHER_ADDRESS に別名を割り当てます。 Microsoft スタック上のアドレスに別名を付ける方法については、Metric Server 用の Microsoft スタック上の別名の構成 を参照してください。
WLM は、MVS メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。
OS/390 システムで MVS 作業負荷管理が構成されている場合、コントローラーは、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。WLM advisor を使用して、コントローラーは、コンサルタント・ホスト・テーブルにある各サーバーの WLM ポートを介して接続を定期的にオープンし、戻された容量を表す整数を受け取ります。これらの整数はその時点で使用可能な容量を表しますが、コンサルタントは各マシンの負荷を表す値を要求しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (例えば、容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを表します)。WLM advisor と他のコントローラー advisor の間には、重要な違いがいくつかあります。
バイナリー・ログ機能を使用すれば、サーバー情報をバイナリー・ファイルに保管できます。 これらのファイルを処理して、ある時間にわたって収集されたサーバー情報を分析することができます。
以下の情報が、構成で定義されたサーバーごとのバイナリー・ログに保管されます。
情報をバイナリー・ログに記録するために、コンサルタントが実行されていなければなりません。
xxxcontrol consultant binarylog コマンドを使用して、バイナリー・ロギングを構成します。
start オプションは、ログ・ディレクトリーにあるバイナリー・ログへのサーバー情報の記録を開始します。ログは、毎時 0 分に その日時をファイル名として作成されます。
stop オプションは、バイナリー・ログへのサーバー情報の 記録を停止します。ログ・サービスは、デフォルトによって停止しています。
set interval オプションは、情報がログに 書き込まれる頻度を制御します。コンサルタントは、サーバー情報をコンサルタント間隔ごとに ログ・サーバーへ送信します。情報は、最後にログにレコードが書き込まれてから、指定した秒数の経過後にログに書き込まれます。 デフォルトでは、ログ記録間隔は 60 秒に設定されています。
コンサルタント間隔とログ記録間隔の設定の間には、相関関係があります。ログ・サーバーはコンサルタント間隔秒数以下の速度で情報を提供するので、コンサルタント間隔より短いログ記録間隔を設定しようとしても、実際にはコンサルタント間隔と同じ値に 設定されます。
このログ記録方法によって、サーバー情報を取り込む頻度を任意に細分化することができます。サーバーの重みを計算するために、コンサルタントによって確認されるサーバー情報に対する変更を すべて取り込むことができます。ただし、おそらく、この程度の情報量は、サーバーの使用および傾向の分析に必要ではありません。60 秒ごとにサーバー情報をログ記録すると、時間の経過とともにサーバー情報のスナップショットがとられます。ログ記録間隔を非常に低く設定すると、膨大な量のデータが生成される場合があります。
set retention オプションは、ログ・ファイルが保持される期間を制御します。指定した保存時間よりも古いログ・ファイルは、ログ・サーバーによって削除されます。このことは、ログ・サーバーがコンサルタントによって呼び出されているときに 発生します。そのため、コンサルタントを停止した場合には、古いログ・ファイルは削除されません。
サンプル Java プログラムおよびコマンド・ファイルは、...ibm/edge/lb/servers/samples/BinaryLog ディレクトリーに提供されています。 このサンプルは、ログ・ファイルからすべての情報を検索して画面に出力する方法を示します。カスタマイズすると、データについて必要な種類の分析を行うことができます。
提供されているスクリプトおよびプログラムの使用例を以下に示します。
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
これによって、2002 年 5 月 1 日の午前 8:00 から午後 5:00 までのコントローラーのサーバー情報の 報告書が得られます。
Load Balancer は、カスタマイズできるスクリプトを起動するユーザー出口を提供します。自動化された (サーバーがダウンとマークされると管理者にアラートを通知するか、単に障害のイベントを記録するなどの) アクションを 実行するスクリプトを作成できます。カスタマイズできるサンプル・スクリプトは、 ...ibm/edge/lb/servers/samples インストール・ディレクトリーに入っています。ファイルを実行するには、ファイルを ...ibm/edge/lb/servers/bin ディレクトリーにコピーし、続いて、スクリプトに記述されている指示に従って、各ファイルを名前変更します。
以下のサンプル・スクリプトが提供されています。xxx は、Cisco CSS Controller では cco、および Nortel Alteon Controller では nal です。
この部では、Load Balancer の管理とトラブルシューティングに関する情報を提供します。この部には、以下の章があります。
この章では、Load Balancer の操作および管理の方法について説明しています。この章には以下のセクションがあります。
Load Balancer では、Load Balancer が常駐するマシンとは別のマシンで構成プログラムを実行する方法として、異なる 2 つの方法が用意されています。 構成プログラム (dscontrol、cbrcontrol、sscontrol、ccocontrol、nalcontrol) と サーバー (dsserver、cbrserver など) との通信は、以下の方法のいずれかを使用して行われます。
RMI を使用するリモート管理の利点は、パフォーマンスが Web ベース管理よりも高速だということです。
Web ベース管理を使用する利点は、Web ベース管理では、安全な認証リモート管理が提供されるということと、ファイアウォールがある場合でも Load Balancer マシンとの通信が可能だということです。 また、この管理方法では、Load Balancer マシンと通信するリモート・クライアント・マシンに認証キー (lbkeys) をインストールしたり、このリモート・クライアント・マシンで認証キーを使用する必要がありません。
RMI では、リモート管理のために Load Balancer マシンに接続するコマンドは、dscontrol host:remote_host です。
RMI 呼び出しがローカル・マシン以外のマシンから行われた場合は、公開鍵と秘密鍵の認証シーケンスを行わなければ、構成コマンドは受信されません。
コンポーネント・サーバーと同じマシンで実行する制御プログラムの間の通信は認証されません。
以下のコマンドを使用して、リモート認証に使用する公開鍵および秘密鍵を生成します。
このコマンドは、Load Balancer と同じマシン上でのみ実行できます。
create オプションを使用すると、それぞれの Load Balancer コンポーネントごとにサーバー鍵ディレクトリー (...ibm/edge/lb/servers/key/) に秘密鍵が作成され、管理鍵ディレクトリー (...ibm/edge/lb/admin/keys/) に公開鍵が作成されます。 公開鍵のファイル名は component-ServerAddress-RMIport です。 これらの公開鍵は、リモート・クライアントに移送して、管理鍵ディレクトリーに入れなければなりません。
各コンポーネントにデフォルト RMI ポートを使用するホスト名アドレス 10.0.0.25 の Load Balancer マシンの場合には、lbkeys create コマンドで以下のファイルを生成します。
管理ファイル・セットは、別のマシンにインストールされています。 公開鍵ファイルは、リモート・クライアント・マシンの ...ibm/edge/lb/admin/keys ディレクトリーに入っていなければなりません。
これでリモート・クライアントに対して 10.0.0.25 にある Load Balancer の構成が許可されます。
10.0.0.25 にある Load Balancer の構成を許可するすべてのリモート・クライアントでは、これらの同じ鍵を使用する必要があります。
lbkeys create コマンドを再度実行すると、公開鍵と秘密鍵の新しいセットが生成されます。つまり、以前の鍵を使用して接続しようとしたすべてのリモート・クライアントが許可されなくなります。新しい鍵は、再度許可するこれらのクライアントの正しいディレクトリーに入れなければなりません。
lbkeys delete コマンドは、サーバー・マシンにある 秘密鍵および公開鍵を削除します。 これらの鍵が削除されると、リモート・クライアントはサーバーへの接続を許可されなくなります。
lbkeys create と lbkeys delete の両方の場合に、force オプションがあります。 force オプションは、既存の鍵を上書きするか、あるいは削除するかを尋ねるコマンド・プロンプトを抑止します。
RMI 接続を確立すると、コマンド・プロンプトから dscontrol、cbrcontrol、 sscontrol、ccocontrol、nalcontrol、dswizard、cbrwizard、および sswizard コマンドを使用して構成プログラム間の通信を行うことができます。 また、コマンド・プロンプトから lbadmin を入力して GUI から Load Balancer を 構成することもできます。
Web ベース管理を使用するには、リモート管理を行うクライアント・マシンに 以下がインストールされている必要があります。
リモート Web ベース管理を行うには、アクセスするホスト・マシンに 以下がインストールされている必要があります。
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥lbwebaccess.pl Pass /lb-admin/help/* C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥help¥* Pass /lb-admin/*.jar C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥lib¥*.jar Pass /lb-admin/* C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*ここで、lang はご使用の言語のサブディレクトリー (例えば en_US) です。
Linux および UNIX システムの場合 --
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Web ベース管理を実行するには、これを Load Balancer ホスト・マシンで開始する必要があります。 開始するには、ホスト・マシンのコマンド・プロンプトから lbwebaccess を実行します。
リモートでアクセスするホスト・マシンのユーザー ID およびパスワードも必要です。 ユーザー ID とパスワードは、Caching Proxy 管理ユーザー ID およびパスワードと同じです。
Load Balancer の Web ベース管理を行うには、リモート・ロケーションから Web ブラウザーで 次の URL にアクセスします。
http:// host_name/lb-admin/lbadmin.html
host_name は、Load Balancer との通信を行うためにアクセスするマシンの名前です。
Web ページがロードされると、リモート Web ベース管理を 行うための Load Balancer GUI がブラウザー・ウィンドウに表示されます。
Load Balancer GUI から、構成制御コマンドを実行することもできます。 GUI からコマンドを実行するには、以下を行います。
リモート Web ベース管理では、複数の管理者が別のロケーションから Load Balancer 構成を 更新する場合、別の管理者によって追加 (または削除) されたクラスター、ポート、またはサーバーを (例えば) 表示するには、構成をリフレッシュする必要があります。 リモート Web ベース管理 GUI には、「構成をリフレッシュ」 および「すべての構成をリフレッシュ」機能があります。
Web ベース GUI から構成をリフレッシュするには、次を行います。
Load Balancer は、サーバー・ログ、manager ログ、メトリック・モニター・ログ (Metric Server エージェントでのロギング通信)、および使用する各 advisor のログに項目を追加します。
ログ・レベルを設定して、ログに書き込まれるメッセージの増え方を定義することができます。レベル 0 では、エラーが記録されて、Load Balancer は一度だけ発生したイベント (例えば、manager ログに書き込まれ始めた advisor に関するメッセージ) のヘッダーとレコードも記録します。 レベル 1 には継続中の情報などが組み込まれ、レベル 5 には必要に応じて生成される問題のデバッグに役立つメッセージが組み込まれます。manager、advisor、サーバー、またはサブエージェントのログのデフォルトは 1 です。
ログの最大サイズを設定することもできます。ログ・ファイルに最大サイズを設定すると、ファイルは循環します。つまり、ファイルが指定サイズに達すると、次の入力がファイルの最上部に書き込まれ、前のログ入力を上書きします。ログ・サイズを現行サイズより小さい値に設定することができません。ログ項目にはタイム・スタンプが記されるため、書き込まれた順序が分かります。
ログ・レベルの設定が高いほど、ログ・サイズの選択には注意を要します。レベル 0 では、ログ・サイズをデフォルトの 1MB のままにおくと安全です。ただし、レベル 3 以上でログ記録するときには、小さ過ぎて役に立たなくならない程度にサイズを制限する必要があります。
デフォルトでは、Load Balancer によって生成されるログは、Load Balancer インストールのログ・ディレクトリーに保管されます。このパスを変更するには、dsserver スクリプトで lb_logdir 変数を設定してください。
AIX、HP-UX、Linux、および Solaris システムの場合: dsserver スクリプトは /usr/bin ディレクトリーにあります。このスクリプトでは、変数 lb_logdir はデフォルトのディレクトリーに設定されています。この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
LB_LOGDIR=/path/to/my/logs/
Windows システム: dsserver ファイルは Windows システム・ディレクトリーにあります。Windows 2003 の場合は C:\WINNT\SYSTEM32 です。 dsserver ファイルでは、変数 lb_logdir はデフォルト・ディレクトリーに設定されています。この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
set LB_LOGDIR=c:\path\to\my\logs\
すべてのオペレーティング・システムにおいて、等号の両側にはスペースを置かず、パスが (必要に応じて) スラッシュ (/) または円記号 (¥) で終了していなければなりません。
Load Balancer のバイナリー・ログ機能は、他のログ・ファイルと同じログ・ディレクトリーを使用します。 バイナリー・ログを使用してサーバーの統計を分析するを参照してください。
ログ・レベルを設定して、ログに書き込まれるメッセージの増え方を定義することができます。レベル 0 では、エラーが記録されて、Load Balancer は一度だけ発生したイベント (例えば、コンサルタント・ログに書き込まれ始めた advisor に関するメッセージ) のヘッダーおよびレコードも記録します。 レベル 1 には継続中の情報などが組み込まれ、レベル 5 には必要に応じて生成される問題のデバッグに役立つメッセージが組み込まれます。ログの デフォルトは 1 です。
ログの最大サイズを設定することもできます。ログ・ファイルに最大サイズを設定すると、ファイルは循環します。つまり、ファイルが指定サイズに達すると、次の入力がファイルの最上部に書き込まれ、前のログ入力を上書きします。ログ・サイズを現行サイズより小さい値に設定することができません。ログ項目にはタイム・スタンプが記されるため、書き込まれた順序が分かります。
ログ・レベルの設定が高いほど、ログ・サイズの選択には注意を要します。レベル 0 では、ログ・サイズをデフォルトの 1MB のままにおくと安全です。ただし、レベル 3 以上でログ記録するときには、小さ過ぎて役に立たなくならない程度にサイズを制限する必要があります。
Cisco CSS Controller および Nortel Alteon Controller のログは次のとおりです。
次は、Metric Server エージェントとの通信を記録する メトリック・モニター・ログのログ・レベルおよび最大ログ・サイズの構成例です。
xxxcontrol metriccollector set consultantID:serviceID:metricName loglevel x logsize y
デフォルトでは、コントローラーによって生成されるログは、コントローラー・インストールのログ・ディレクトリーに保管されます。 このパスを変更するには、xxxserver スクリプトに xxx_logdir 変数を 設定してください。
AIX、HP-UX、Linux、および Solaris システムの場合: xxxserver スクリプトは /usr/bin ディレクトリーにあります。このスクリプトでは、変数 xxx_logdir はデフォルトのディレクトリーに設定されています。 この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
xxx_LOGDIR=/path/to/my/logs/
Windows システム: xxxserver ファイルは Windows システム・ディレクトリー (通常は C:\WINNT\SYSTEM32) にあります。xxxserver ファイルでは、変数 xxx_logdir はデフォルトのディレクトリーに設定されています。 この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
set xxx_LOGDIR=c:\path\to\my\logs\
すべてのオペレーティング・システムにおいて、等号の両側にはスペースを置かず、パスが (必要に応じて) スラッシュ (/) または円記号 (¥) で終了していなければなりません。
Load Balancer のバイナリー・ログ機能は、他のログ・ファイルと同じログ・ディレクトリーを使用します。 バイナリー・ログを使用してサーバーの統計を分析するを参照してください。
このセクションでは、Dispatcher コンポーネントの操作および管理方法について説明します。
Load Balancer では、ステイル・タイムアウトに指定された秒数の間にその接続でアクティビティーがなかった場合は、接続は期限切れと見なされます。アクティビティーなしでその秒数を過ぎると、Load Balancer はその接続レコードをテーブルから除去し、その接続での後続のトラフィックは廃棄されます。
例えばポート・レベルでは、dscontrol port set staletimeout コマンドでステイル・タイムアウト値を指定できます。
ステイル・タイムアウトは、executor、クラスター、およびポート・レベルで設定できます。executor レベルおよびクラスター・レベルでは、デフォルトは 300 秒であり、そのポートにフィルター掛けします。ポート・レベルでは、デフォルトはポートに依存します。ポートの定義によって、デフォルトのステイル・タイムアウト値は異なります。例えば、Telnet ポート 23 のデフォルトは、259,200 秒です。
また、サービスによっては、独自のステイル・タイムアウトとなることもあります。例えば LDAP (Lightweight Directory Access Protocol) には idletimeout と呼ばれる構成パラメーターがあります。idletimeout の秒数が過ぎると、アイドル中のクライアント接続は強制的にクローズされます。また、Idletimeout を 0 に設定すると、接続は強制的にクローズされることがなくなります。
接続問題は、Load Balancer のステイル・タイムアウト値がサービスのタイムアウト値より小さいときに起きることがあります。 LDAP の場合には、Load Balancer のステイル・タイムアウト値のデフォルトは 300 秒です。 接続において 300 秒間アクティビティーがないと、Load Balancer はテーブルから接続レコードを除去します。idletimeout 値が 300 秒より大きい (または 0 に設定されている) 場合には、クライアントはサーバーとの接続がまだ保たれていると考えます。クライアントがパケットを送信すると、そのパケットは Load Balancer によって廃棄されます。これが、サーバーに対して要求すると LDAP の停止を引き起こすことになります。この問題を避けるには、LDAP idletimeout を Load Balancer のステイル・タイムアウト値以下の非ゼロ値に設定してください。
クライアントは、そのパケットをすべて送信した後に FIN パケットを送信し、 サーバーがトランザクションの終了を認識するようにします。 Dispatcher は FIN パケットを受信すると、 そのトランザクションに活動状態から FIN 状態へのマークを付けます。 トランザクションに FIN のマークが付けられると、その接続に予約されたメモリーはクリア可能になります。
接続レコードの割り振りと再利用の効率を高めるには、 executor set fintimeout コマンドを使用し、 Dispatcher が FIN 状態の接続を Dispatcher テーブルでアクティブに保ち、トラフィックを受け続けさせる 期間を制御します。 FIN 状態の接続が fintimeout を超過すると、 Dispatcher のテーブルから削除され、再利用可能になります。 FIN タイムアウトは、dscontrol executor set fincount コマンドを使用して 変更することができます。
dscontrol executor set staletimeout コマンドを使用して、 Dispatcher テーブルでアクティブなトラフィックが見られないときに、 Dispatcher が接続を Established 状態に保ち、トラフィ ックを受け入れ続ける期間を制御します。 詳しくは、ステイル・タイムアウト値の使用を参照してください。
各種の図表は、executor からの情報を基にして表示して、manager に中継できます。 (GUI モニター・メニュー・オプションでは、manager 機能が実行中であることが必要です):
ネットワーク管理システムは断続的に実行される プログラムであり、ネットワークのモニター、状況の反映、および制御に使用されます。Simple Network Management Protocol (SNMP) は ネットワーク内の装置と通信するための一般的なプロトコルであり、現在のネットワーク管理の標準となっています。ネットワーク装置は、通常は SNMP エージェント と、1 つまたは複数のサブエージェントを持ちます。SNMP エージェントは、ネットワーク管理ステーション と通信するか、コマンド行 SNMP 要求に応答します。SNMP サブエージェント は、データを取得および更新し、そのデータを SNMP エージェントに提供して 要求側に戻します。
Dispatcher は SNMP 管理情報ベース (ibmNetDispatcherMIB) および SNMP サブエージェントを提供します。これによって、Tivoli(R) NetView(R)、Tivoli Distributed Monitoring、HP OpenView などの任意のネットワーク管理システムを使用して、Dispatcher の状態、スループット、およびアクティビティーをモニターすることができます。MIB データは、管理対象の Dispatcher について記述するものであり、現在の Dispatcher の状況を反映しています。 MIB は ..lb/admin/MIB サブディレクトリーにインストールされています。
ネットワーク管理システムは、SNMP GET コマンドを使用して他のマシンの MIB 値を調べます。指定されたしきい値を超えた場合は、ユーザーに通知します。その後、Dispatcher の構成データを変更することによって、Dispatcher のパフォーマンスに影響を与え、Dispatcher の問題が Dispatcher や Web サーバーの障害に至る前に未然に調整または修正を行うことができます。
システムによって、通常、ネットワーク管理ステーションごとに 1 つの SNMP エージェントが提供されます。ユーザーは SNMP エージェントに GET コマンドを送信します。次に、この SNMP エージェントも GET コマンドを送信して、これらの MIB 変数を管理するサブエージェントから、指定の MIB 変数を取得します。
Dispatcher は、MIB データの更新および取得を行うサブエージェントを提供します。 SNMP エージェントが GET コマンドを送信すると、サブエージェントは適切な MIB データで応答します。SNMP エージェントは、このデータをネットワーク管理ステーションに送信します。ネットワーク管理ステーションは、指定されたしきい値を超えた場合にはユーザーに通知することができます。
Dispatcher SNMP サポートには、分散プログラム・インターフェース (DPI(R)) 機能を使用する SNMP サブエージェントが含まれます。DPI は、SNMP エージェントとそのサブエージェントの間のインターフェースです。Windows オペレーティング・システムは、SNMP エージェントとそのサブエージェントの間のインターフェースとして Windows 拡張エージェントを使用します。
図 40. Linux および UNIX システムの SNMP コマンド
AIX システムは、SNMP Multiplexer プロトコル (SMUX) を使用する SNMP エージェントを提供し、また DPID2 を提供します。DPID2 は、DPI と SMUX の間の変換プログラムとして機能する追加の実行可能プログラムです。
HP-UX システムの場合は、SNMP 対応の SNMP エージェントを入手する必要があります。これは HP-UX では提供されないためです。 Load Balancer は、HP-UX システムに DPID2 を提供します。
Linux システムは、SMUX を使用する SNMP エージェントを提供します。多くのバージョンの Linux (Red Hat など) に UCD SNMP パッケージが付属しています。 UCD SNMP バージョン 4.1 またはそれ以降には、SMUX 使用可能エージェントが備わっています。 Load Balancer は、Linux システムに DPID2 を提供します。
Solaris システムの場合は SMUX 可能な SNMP エージェントを得る必要があります。これは Solaris では提供されないためです。Load Balancer は、/opt/ibm/edge/lb/servers/samples/SNMP ディレクトリーに Solaris システム用の DPID2 を提供します。
DPI エージェントは、root ユーザーとして実行しなければなりません。DPID2 デーモンを実行する前に、以下のように /etc/snmpd.peers ファイルおよび /etc/snmpd.conf ファイルを更新してください。
AIX および Solaris システムの場合:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Linux システムの場合:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
また、snmpd.conf ファイル内の com2sec、group、view、または access で始まるすべての行を コメント化する必要もあります。
HP-UX SNMP サポートをインストールするには、以下を行います。
SuSE Linux システムで Load Balancer SNMP を使用するには、以下を行う必要があります。
snmpd をリフレッシュして (すでに実行中の場合)、snmpd.conf ファイルを 再読み取りするようにします。
refresh -s snmpd
DPID SMUX 対等機能を開始します。
dpid2
このデーモンは、以下の順序で開始しなければなりません。
Solaris SNMP サポートをインストールするには、以下を行います。
/etc/rc3.d/S76snmpdx to /etc/rc3.d/K76snmpdx
/etc/rc3.d/S77dmi to /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
注:
http://sunfreeware.com/ Web サイトでは、これらの名前に .gz の拡張子が 付いているため、これらを gunzip/untar しないでください。 その代わりに、pkgadd packageName を使用します。
Windows SNMP サポートをインストールするには、以下を行います。
executor 実行では、dscontrol subagent start [communityname] コマンドを使用して、Windows OS 拡張エージェントと SNMP エージェントとの間で使用されるコミュニティー名を定義します。
重要: Windows 2003 では、SNMP はデフォルトでは表示されたいずれのコミュニティー名にも応答しません。このような場合には、SNMP サブエージェントはいずれの SNMP 要求にも応答しません。SNMP サブエージェントがコミュニティー名に応答するようにするには、適切なコミュニティー名および宛先ホストで「SNMP サービス・プロパティー」を設定しなければなりません。 SNMP セキュリティー・プロパティーを以下のように構成します。
SNMP は、しきい値に達したなど、管理されている装置が例外条件または重要なイベントの発生を報告するために送信するメッセージとして トラップ を送受信することによって通信します。
サブエージェントは以下のトラップを使用します。
indHighAvailStatus トラップは、ハイ・アベイラビリティー状況の状態変数 (hasState) の値が変化したことを通知します。 hasState の指定できる値は以下のとおりです。
indSrvrGoneDown トラップは、オブジェクト ID の csID (クラスター ID)、psNum (ポート番号)、および ssID (サーバー ID) の部分で指定されたサーバーの重みがゼロになったことを通知します。トラップでは、最終的に既知であったサーバーの活動状態の接続の数が送信されます。このトラップは、Dispatcher が判別できる限りにおいて、指定のサーバーが終了していることを示します。
indDOSAttack トラップは、numhalfopen (SYN パケットだけで構成されるハーフ・オープン接続の数) が、オブジェクト ID の csID (クラスター ID) および psNum (ポート番号) の部分で指定されたポートに対する maxhhalfopen しきい値を超過したことを示します。ポート上で構成されたサーバー数がトラップで送信されます。このトラップは、Load Balancer がサービス妨害攻撃を受けている可能性があることを示しています。
indDOSAttackDone トラップは、numhalfopen (SYN パケットだけで構成されるハーフ・オープン接続の数) が、オブジェクト ID の csID および psNum の部分で指定されたポートに対する maxhalfopen しきい値を下回ったことを示します。ポート上で構成されたサーバー数がトラップで送信されます。Load Balancer がサービス妨害攻撃の可能性がある攻撃が終了したことを判別すると、indDOSAttack トラップが送信された後にこのトラップが送信されます。
Linux および UNIX システムの場合、SMUX API の制限により、ibmNetDispatcher のエンタープライズ ID である 1.3.6.1.4.1.2.6.144 の代わりに、ibmNetDispatcher サブエージェントからのトラップで報告されたエンタープライズ ID が dpid2 のエンタープライズ ID である場合があります。 ただし、データに ibmNetDispatcher MIB 内からのオブジェクト ID が含まれるため、SNMP 管理ユーティリティーはトラップの送信元を判別することができます。
dscontrol subagent start コマンドは、SNMP サポートをオンにします。dscontrol subagent stop コマンドは、SNMP サポートをオフにします。
dscontrol コマンドの詳細については、dscontrol subagent -- SNMP サブエージェントを構成するを参照してください。
Linux カーネルには、ipchains と呼ばれるファイアウォール機能が組み込まれています。 Load Balancer と ipchains を並行して実行すると、Load Balancer が最初にパケットを読み込み、 次に ipchains が処理されます。これにより、ipchains を使用すると、Linux Load Balancer マシン (例えば、ファイアウォールのロード・バランスを取るために使用される Load Balancer マシン) を強化することができます。
ipchains または iptables が完全に制限される (インバウンドまたはアウトバウンド・トラフィックが許可されない) ように構成されている場合、Load Balancer のパケット転送部分は正常に機能し続けます。
ipchains および iptables は、ロード・バランシング前に着信トラフィックをフィルターに掛けるためには使用できない ことに注意してください。
すべての Load Balancer が適切に機能するためには、 一部の追加トラフィックが許可されている必要があります。 この通信のいくつかの例は、次のとおりです。
一般に Load Balancer マシンでは、(バックエンド・サーバー、パートナー高可用性 Load Balancer、 すべてのリーチ・ターゲット、またはすべての構成ホストとの間のトラフィックを除く) すべてのトラフィックを認可しないというのが ipchains の適切な方針です。
Linux カーネルのバージョン 2.4.10.x で Load Balancer が実行されている場合は、iptables を活動状態にすることはお勧めしません。 この Linux カーネルのバージョンで活動化すると、時間の経過と共にパフォーマンスが低下する可能性があります。
iptables を活動停止するには、モジュール (lsmod) をリストして、どのモジュールが ip_tables および ip_conntrack を調べてから、rmmod ip_tables および rmmod ip_conntrack を実行してそれらを除去します。 マシンをリブートすると、これらのモジュールが再び追加されるので、リブートするたびにこれらのステップを繰り返す必要があります。
詳細については、問題: Linux iptables がパケットの経路指定を干渉するを参照してください。
このセクションでは、Load Balancer の CBR コンポーネントの操作方法および管理方法について説明します。
CBR および Caching Proxy は、Caching Proxy プラグイン API を介して、HTTP および HTTPS (SSL) の要求を共同で処理します。CBR に対してサーバーのロード・バランシングを開始するには、Caching Proxy は同じマシン上で実行している必要があります。CBR および Caching Proxy を CBR 構成の例の説明に従ってセットアップしてください。
CBR の開始後に、以下の方式のいずれかを使用して制御できます。
CBR が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Site Selector の開始後に、以下の方式のいずれかを使用して制御できます。
Site Selector が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Cisco CSS Controller の開始後に、以下の方式のいずれかを使用して制御できます。
Cisco CSS Controller が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Nortel Alteon Controller の開始後に、以下の方式のいずれかを使用して制御できます。
Nortel Alteon Controller が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Metric Server は Load Balancer にサーバー・ロード情報を提供します。 Metric Server は、ロード・バランシングされている各サーバー上に常駐します。
Linux および UNIX システム:
Windows システム:
「スタート」>「設定」(Windows 2000 の場合) >「コントロール パネル」>「管理ツール」>「サービス」をクリックします。「IBM Metric Server」を右クリックして、「開始」を選択します。サービスを停止するには、同様のステップに従って、「停止」を選択します。
Metric Server 始動スクリプトのログ・レベルを変更します。Load Balancer ログでのログ・レベル範囲と同様に、 ログ・レベルの範囲を 0 から 5 に指定できます。これにより、 ...ms/logs ディレクトリーにエージェント・ログが生成されます。
この章は、Load Balancer に関連する問題の検出と解決に役立ちます。
このセクションの情報を使用して IBM サービスが必要とするデータを収集します。 情報は以下の件名に分かれています。
Dispatcher コンポーネントにのみ、オペレーティング・システム固有のデータおよびコンポーネント固有の構成ファイルを自動的に収集する問題判別ツールがあります。 このツールを実行するには、適切なディレクトリーから lbpd と入力します。
Linux および UNIX システムの場合: /opt/ibm/edge/lb/servers/bin/
Windows システムの場合: C:\Program Files\IBM\edge\lb\servers\bin
この問題判別ツールは、以下のようにデータをファイルにパッケージします。
Linux および UNIX システムの場合: /opt/ibm/edge/lb/lbpmr.tar.Z
Windows システムの場合: C:\Program Files\IBM\edge\lb\lbpmr.zip
IBM サービスに連絡する前に、以下の情報を入手してください。
dscontrol file save primary.cfg
このコマンドによって、構成ファイルが .../ibm/edge/lb/servers/configuration/component/ ディレクトリーに置かれます。
java -fullversion
AIX、HP-UX、Linux、および Solaris システムの場合: netstat -ni
Windows システムの場合: ipconfig /all
これについては、すべてのサーバーおよび Load Balancer からの情報が必要です。
AIX、HP-UX、Linux、および Solaris システムの場合: netstat -nr
Windows システムの場合: route print
これについては、すべてのサーバーおよび Load Balancer からの情報が必要です。
HA 環境での問題の場合、以下の必須情報を収集します。
AIX、HP-UX、Linux、および Solaris システムの場合: /opt/ibm/edge/lb/servers/bin
Windows システムの場合: C:\Program Files\ibm\edge\lb\servers\bin
スクリプト名は以下のとおりです。
goActive
goStandby
goIdle (もしあれば)
goInOp (もしあれば)
さらに、構成ファイルも必要です。一般情報 (必須) を参照してください。
例えば、advIsor がサーバーに誤ってダウンのマークを付けるときなど、advisor の問題の場合は、以下の必須情報を収集します。
dscontrol advisor loglevel http 80 5
または
dscontrol advisor loglevel advisorName port loglevel
または
dscontrol advisor loglevel advisorName cluster:port loglevel
または
nalcontrol metriccollector set consultantID:serviceID:metricName loglevel value
これにより、ADV_advisorName.log という名前 (例えば ADV_http.log) の ログが作成されます。 このログは以下のロケーションに置かれます。
AIX、HP-UX、Linux、および Solaris プラットフォームの場合: /opt/ibm/edge/lb/servers/logs/component
Windows プラットフォームの場合: C:\Program Files\ibm\edge\lb\servers\logs\component
ここで、component は以下のとおりです。
dispatcher = Dispatcher
CBR = Content Based Routing
cco = Cisco CSS Controller
nal = Nortel Alteon Controller
ss = Site Selector
ADVLOG 呼び出しは、レベルが advisor に関連したロギング・レベルより低いときに、advisor ログ・ファイルにステートメントをプリントします。ログ・レベルが 0 の場合、ステートメントが常に書き込まれます。コンストラクターから ADVLOG を使用することができません。ログ・ファイル名はコンストラクターに設定される情報によって決まるので、ログ・ファイルは、カスタムの advisor のコンストラクターが完成する直後まで作成されません。
この制限を回避し、カスタムの advisor をデバッグする別の方法があります。System.out.println(message) ステートメントを使用して、ウィンドウにメッセージを プリントすることができます。dsserver スクリプトを編集し、javaw から java に変更してプリント・ステートメントをウィンドウに表示します。dsserver の開始に使用したウィンドウは、プリントの表示のために開いておかなければなりません。Windows プラットフォームをご使用の場合は、Dispatcher のサービスとしての実行を停止し、 ウィンドウから手動で開始してメッセージを表示する必要があります。
ADVLOG の詳細については、「Edge Components プログラミング・ガイド」を参照してください。
Content Based Routing の問題の場合、以下の必須情報を収集します。
Linux および UNIX システムの場合: /etc/
Windows システムの場合: C:\Program Files\IBM\edge\cp\etc\en_US\
Linux および UNIX システムの場合: /opt/ibm/edge/lb/servers/configurations/cbr
Windows システムの場合: C:\Program Files\IBM\edge\lb\servers\configurations\cbr
クラスターをヒットできない場合、両方の Load Balancer マシンでクラスターが別名割り当てされていないか、 または両方のマシンでクラスターが別名割り当てされている可能性があります。 どのマシンにクラスターがあるかを判別するには、以下を行います。
ping cluster arp -aDispatcher の NAT または CBR 転送方式を使用している場合は、戻りアドレスも ping します。
AIX および HP-UX システムの場合: netstat -ni
Linux および Solaris システムの場合: ifconfig -a
Windows システムの場合: ipconfig /all
ping からの応答がなく、ULB を使用していない場合は、どちらのマシンに おいても、インターフェースにクラスター IP アドレス (例えば en0、tr0 など) が別名割り当てされていない可能性があります。
経路指定の問題を解決できず、その他のすべてが失敗した場合、以下のコマンドを実行してネットワーク・トラフィック上でトレースを実行します。
iptrace -a -s failingClientIPAddress -d clusterIPAddress -b iptrace.trc
トレースを実行し、問題を再作成してから、プロセスを強制終了します。
tcpdump -i lan0 host cluster and host client
HP-UX GNU ソフトウェアのアーカイブ・サイトのいずれかから、tcpdump をダウンロードする必要がある場合があります。
tcpdump -i eth0 host cluster and host client
トレースを実行し、問題を再作成してから、プロセスを強制終了します。
snoop -v clientIPAddress destinationIPAddress > snooptrace.out
また、さまざまログ・レベル (manager ログ、advisor ログなど) を上げて、その出力を調べることもできます。
サービス・リリース・フィックスまたはパッチですでに修正されている問題を確認するには、 アップグレードを確認してください。 修正された Edge Components の問題のリストを取得するには、WebSphere Application Server Web サイトのサポート・ページ (http://www.ibm.com/software/webservers/appserv/was/support/) を参照してください。 サポート・ページから、修正サービスのダウンロード・サイトへのリンクをたどってください。
Load Balancer インストールの一部として適切なバージョンの Java コードがインストールされます。
サポートおよびライブラリーの Web ページへのリンクについては、参照情報を参照してください。Web サポート・ページには、テクニカル・ノート形式のセルフ・ヘルプへのリンクが含まれます。
以下を参照してください。
表 17. Dispatcher トラブルシューティングの表
症状 | 考えられる原因 | 参照箇所 |
---|---|---|
Dispatcher が正常に実行されない | ポート番号が競合している | Dispatcher のポート番号の確認 |
連結されたサーバーを構成したが、ロード・バランシング要求に応答しない | アドレスが誤っているか競合している | 問題: Dispatcher およびサーバーが応答しない |
クライアント・マシンからの接続がサービスを受けていない、あるいは接続がタイムアウトである |
| 問題: Dispatcher 要求が平衡化されない |
クライアント・マシンにサービスが提供されていないか、タイムアウトになっている | ハイ・アベイラビリティーが機能しない | 問題: Dispatcher の高可用性機能が機能しない |
heartbeat を追加できない (Windows プラットフォーム) | アダプターに送信元アドレスが構成されていない | 問題: heartbeat を追加できない (Windows プラットフォーム) |
サーバーが要求に対するサービスを提供しない (Windows プラットフォーム) | エクストラ経路が経路指定テーブルに作成されている | 問題: エクストラ経路 (Windows 2000) |
advisor が広域で正しく機能しない | advisor がリモート・マシンで実行されていない | 問題: advisor が正しく機能しない |
Dispatcher、Microsoft IIS、および SSL が機能しない、または続行しない | 暗号化されたデータをプロトコルを介して送信できない | 問題: Dispatcher、Microsoft IIS、および SSL が機能しない (Windows プラットフォーム) |
リモート・マシンへの接続が拒否された | 古いバージョンのキーがまだ使用されている | 問題: リモート・マシンへの Dispatcher 接続 |
dscontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」メッセージが表示される |
| 問題: dscontrol コマンドまたは lbadmin コマンドが失敗する |
「ファイルが見つかりません...」というエラー・メッセージが、Netscape をデフォルト・ブラウザーとして稼働し、オンライン・ヘルプを表示すると出される (Windows プラットフォーム) | HTML ファイルの関連付けの設定が誤っている | 問題: 「ファイルが見つかりません...」というエラー・メッセージが、オンライン・ヘルプを表示しようとすると出される (Windows プラットフォーム) |
グラフィカル・ユーザー・インターフェースが正しく開始されない | 不適当なページング・スペース | 問題: グラフィカル・ユーザー・インターフェース (GUI) が正しく開始されない |
Caching Proxy がインストールされた Dispatcher の実行のエラー | Caching Proxy のファイル依存関係 | 問題: Caching Proxy をインストールした状態で Dispatcher を 実行するとエラーが発生する |
グラフィカル・ユーザー・インターフェースが正しく表示されない | レゾリューションが誤りである | 問題: グラフィカル・ユーザー・インターフェース (GUI) が正しく表示されない |
ヘルプ・パネルが他のウィンドウの背後に隠れて見えなくなることがある | Java の制限 | 問題: Windows プラットフォームにおいてヘルプ・ウィンドウが他のウィンドウの背後に隠れて見えなくなることがある |
Load Balancer がフレームを処理および転送できない | 各 NIC に対して固有の MAC アドレスが必要 | 問題: Load Balancer がフレームを処理および転送できない |
青い画面が表示される | ネットワーク・カードがインストールおよび構成されていない | 問題: Load Balancer executor を開始すると青い画面が表示される |
Discovery へのパスが戻りトラフィックを妨げる | クラスターがループバック上で別名割り当てされる | 問題: Discovery へのパスが Load Balancer での戻りトラフィックを妨げる |
Load Balancer の広域モードで高可用性が動作しない | Remote Dispatcher をローカル Dispatcher 上のクラスターにおいてサーバーとして定義する必要がある | 問題: Load Balancer の広域モードで高可用性が機能しない |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
リモート接続で正しく IP アドレスに解決されない | セキュア Socks インプリメンテーションでリモート・クライアントを使用するとき、 完全修飾ドメイン・ネームまたはホスト名が正しい IP アドレスに解決されないことがある | 問題: リモート接続で正しく IP アドレスに解決されない |
AIX および Linux システムにおいて、韓国語の Load Balancer インターフェースで、文字が重なり合ったフォントまたは不適切なフォントが表示される | デフォルトのフォントを変更する必要がある | 問題: AIX および Linux システムにおいて、韓国語の Load Balancer インターフェースで、文字が重なり合ったフォントまたは不適切なフォントが表示される |
Windows システムにおいて MS ループバック・アダプターの別名割り当て後に、hostname などのコマンドを実行すると、OS が別名アドレスを使用して不正に応答する | ネットワーク接続リストで、新たに追加された別名をローカル・アドレスの上に リストしてはいけない | 問題: Windows システムにおいて、hostname などのコマンドを実行したときに、ローカル・アドレスではなく別名アドレスが返される |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォーム上で Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
Linux システムにおいて "rmmod ibmlb" を実行すると、システム・ハングなどの予期しない振る舞いが発生する | Load Balancer カーネル・モジュール (ibmlb) を手動で除去すると、問題が発生する | 問題: rmmod ibmlb を実行すると予期しない振る舞いが発生する (Linux システム) |
Dispatcher マシンでコマンドを実行したときの応答が遅い | 高ボリュームのクライアント・トラフィックによるマシンの過負荷が原因で、応答が遅くなっている可能性がある | 問題: Dispatcher マシンでコマンドを実行したときの応答が遅い |
Dispatcher の mac 転送方式で、SSL または HTTPS advisor がサーバーの負荷を登録しない | SSL サーバー・アプリケーションがクラスター IP アドレスで 構成されていないことが原因で問題が発生する | 問題: SSL または HTTPS advisor がサーバーの負荷を登録しない (mac 転送方式使用時) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
ソケット・プールが使用可能で、Web サーバーが 0.0.0.0 にバインドされている | Microsoft IIS サーバーをバインド固有になるように構成する | 問題: ソケット・プールが使用可能で、Web サーバーが 0.0.0.0 にバインドされている |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows システム上で、コマンド・プロンプト・ウィンドウに破壊された Latin 1 国別文字が表示される |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システム上で、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合に、IP アドレスをホスト名に解決する際に問題が発生する | ホスト名として設定する IP アドレスは、レジストリーの最初に表示される必要があります。 | 問題: Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合、IP アドレスをホスト名に解決する際の問題 |
Windows プラットフォームで、ネットワーク障害後に高可用性セットアップで advisor が機能しない | システムは、ネットワーク障害を検出すると、アドレス解決プロトコル (ARP) キャッシュを消去します。 | 問題: Windows システムで、ネットワーク障害後に高可用性セットアップで advisor が機能しない |
Linux システムで、「IP address add」コマンドと、複数のクラスター・ループバックの別名が非互換 | ループバック・デバイスの複数のアドレスに別名を割り当てるときは、ip address add ではなく ifconfig コマンドを使用する必要があります。 | 問題: Linux システムで、ループバック・デバイスの複数のクラスターに別名を割り当てるときには、IP address add コマンドは使用しない |
エラー・メッセージ: サーバーの追加を試行中に、 「ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません」 | サーバーの追加時に発生した問題を判別するための情報のチェックリスト | 問題: 「ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません」のエラー・メッセージ |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
Load Balancer 構成の読み込み時に、速度の低下が見られる | 遅延は、サーバー・アドレスを解決して検証す るために行われた、ドメイン・ネーム・システム (DNS) 呼び出しが原因である場合があります。 | 問題: Load Balancer 構成のロード中に遅延が発生する |
Windows システムで、次のエラー・メッセージが 表示される:「ネットワーク上の他のシステムとの IP アドレスの競合があります」 | ハイ・アベイラビリティーが構成されている場合は、 短時間の間、両方のマシンでクラスター・アドレスが構成されることがあり、この エラー・メッセージが出される原因となります。 | 問題: Windows システムの場合、IP アドレス競合のエラー・メッセージが表示される |
プライマリー・マシンおよびバックアップ・マシンが両方とも HA 構成でアクティブになる | この問題は、go スクリプトがプライマリー・マシンおよびバックアップ・マシンの両方で稼働していないときに発生することがあります。 | 問題: プライマリー・マシンおよびバックアップ・マシンが両方ともハイ・アベイラビリティー構成でアクティブになる |
Dispatcher が大容量のページを戻そうとすると、 クライアント要求が失敗する | NAT または CBR 転送方式を使用している場合、最大伝送単位 (MTU) が Dispatcher マシンに適切に設定されていないと、クライアントは、 大容量のページの結果がタイムアウトを応答するように要求します。 | 問題: 大容量のページ応答を戻そうとする時、クライアント要求が失敗する |
Windows システムの場合、dscontrol または lbadmin コマンドを発行すると、「サーバーが応答していません」というエラーが発生する | 複数の IP アドレスが Windows システムに存在し、 ホスト・ファイルがホスト名に関連づけられたアドレスを指定しない時です。 | 問題: Windows システムで、dscontrol または lbadmin を発行すると、「サーバーが応答していません」というエラーが発生する |
高可用性 Dispatcher マシンが qeth デバイス上の Linux for S/390 で同期するのに失敗することがある | qeth ネットワーク・ドライバーと一緒に Linux for S/390 でハイ・アベイラビリティーを使用しているときに、 活動中および待機中の Dispatcher が同期できないことがあります。 | 問題: ハイ・アベイラビリティー Dispatcher マシンが qeth デバイス上の Linux for S/390 で同期するのに失敗する可能性がある |
Load Balancer 用の高可用性機能の構成に関するヒント | これらのヒントは、以下のようなハイ・アベイラ
ビリティーの問題の改善に役立ちます。
| 問題: ハイ・アベイラビリティーの構成に関するヒント |
zSeries および S/390 プラットフォームでの Dispatcher の MAC 転送構成の制限事項 | Linux では、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の制限があります。 実行可能な次善策が提供されます。 | 問題: Linux で、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の Dispatcher 構成の制限 |
一部の Red Hat Linux バージョンでは、 manager と advisor で構成された Load Balancer の実行中にメモリー・リークが発生することがある | Red Hat Enterprise Linux 3.0 などの一部の Linux 配布版に同梱の JVM の IBM Java SDK バージョンおよび Native POSIX Thread Library (NPTL) では、 メモリー・リークが起こる可能性があります。 | 問題: 一部の Linux バージョンで、manager と advisor で構成された Dispatcher の実行中にメモリー・リークが発生する |
SUSE Linux Enterprise Server 9 で、 Dispatcher 報告書に、パケットが転送された (パケット数が増加する) にもかかわらず、 パケットが実際にバックエンド・サーバーに到達しないということが示される | iptables NAT モジュールはロード済みです。 このバージョンの iptables では、Dispatcher との 対話で異常な振る舞いが発生するという、起こりうるが未確認のエラーが発 生します。 | 問題: SUSE Linux Enterprise Server 9 で、Dispatcher がパケットを転送してもパケットがバックエンド・サーバーに到達しない |
Windows システムで、 Dispatcher の高可用性機能を使用するときに、引き継ぎ中に問題が発生することがある | 活動中のマシンでクラスターの IP アドレスを構成する go スクリプトを、 バックアップ・マシンで IP クラスター・アドレスの構成を解除する go スクリプトの前に実行すると、問題が発生することがあります。 | 問題: Windows システムで、ハイ・アベイラビリティーの引き継ぎ中に IP アドレス競合メッセージが表示される |
Linux システムで、iptables によ ってパケットの経路指定が干渉される場合がある | Linux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Load Balancer マシンでは無効にする必要があります。 | 問題: Linux iptables がパケットの経路指定を干渉す る |
システム・パッケージ化ツールを使用してサービス修正をインストールしたり、ネイティブでインストールしたりすると、Java ファイル・セット警告メッセージが表示される | 製品のインストールは、同じマシンにインストー ルする必要はない複数のパッケージで構成されており、各パッケー ジが Java ファイル・セットをインストールします。 同じマシンにインストールすると、Java ファイル・セットが別のファイル・セットにも所有されていることを示す警告メッセージが表示されます。 | サービス修正のインストール時に Java 警告メッセージが表示される |
Load Balancer のインストールとともに提供された Java ファイル・セットのアップグレード | Java ファイル・セットに問題が見つかった場合は、 その問題を IBM サービスに報告し、Load Balancer インストールとともに 提供された Java ファイル・セットのアップグレードを受け取れるようにする必要があります。 | Load Balancer のインストールとともに提供された Java ファイル・セットのアップグレード |
Windows プラットフォームでの高可用性の引き継ぎ中に、持続接続が中断することがある | Microsoft Windows オペレーティング・システム上では、高可用性の引き継ぎ時に パーシスタント接続が切断される場合があります。この問題は、MAC 転送方式を使用する連結サーバーの場合にのみ発生します。 | 問題: 高可用性の引き継ぎ中に、持続接続が中断することがある |
zSeries 用 32 ビット Linux オペレーティング・システムで、インストール・プログラムが実行できない |
zSeries 用 32 ビット Linux オペレーティング・システムで ./install を使用して WebSphere Edge Server をインストールしようとすると、「JVM が見つかりません」というメッセージが出力されます。
| 問題: zSeries 用 32 ビット Linux オペレーティング・システムで ./install を使用して WebSphere Edge Server をインストールしようとすると、「JVM が見つかりません」というメッセージが出力される |
Linux オペレーティング・システムで、アンインストール・プロセスが正常に完了しない |
Linux オペレーティング・システムでは、WebSphere Edge Server のアンインストール・プロセスはハングします。
| 問題: Linux オペレーティング・システムで、WebSphere Edge Server のアンインストール・プロセスがハングする |
症状 | 考えられる原因 | 参照箇所 |
CBR が正常に実行されない | ポート番号が競合している | CBR ポート番号のチェック |
cbrcontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」というメッセージが表示される | コマンドは socks 化スタックが原因で失敗する。 あるいは、コマンドは cbrserver の未始動が原因で失敗する。 | 問題: cbrcontrol コマンドまたは lbadmin コマンドが失敗する |
要求がロード・バランシングされない | executor の開始前に Caching Proxy が開始された | 問題: 要求がロード・バランシングされない |
Solaris で、cbrcontrol executor start コマンドが、 「エラー: executor が開始されていませんでした」というメッセージを出して失敗するmessage | コマンドは、システム IPC デフォルトを変更する必要があるか、 ライブラリーへのリンクに誤りがあるために失敗します。 | 問題: Solaris システムにおいて cbrcontrol executor start コマンドが失敗する |
URL ルールが機能しない | 構文エラーまたは構成エラー | 問題: 構文エラーまたは構成エラー |
Windows システムを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォーム上で Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォーム上で、コマンド・プロンプト・ウィンドウに破壊された Latin 1 国別文字が表示される |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システム上で、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合に、IP アドレスをホスト名に解決できない問題 | ホスト名として設定する IP アドレスは、レジストリーの最初に表示される必要があります。 | 問題: Windows システム上で、1 つのアダプターに複数のアドレスが構成されている場合に、IP アドレスがホスト名に解決される |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
表 19. Site Selector に関するトラブルシューティングの表
症状 | 考えられる原因 | 参照箇所 |
---|---|---|
Site Selector が正常に動作していない | ポート番号の競合 | Site Selector のポート番号の確認 |
Site Selector が Solaris クライアントからの受信要求をラウンドロビンしない | Solaris システムが「ネーム・サービス・キャッシュ・デーモン」を実行する | 問題: Site Selector が Solaris クライアントからのトラフィックをラウンドロビンしない |
sscontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」というメッセージが表示される | コマンドは socks 化スタックが原因で失敗する。 または ssserver の未始動が原因でコマンドが失敗する | 問題: sscontrol コマンドまたは lbadmin コマンドが失敗する |
Windows プラットフォームで、ssserver が開始できない | Windows システムでは、DNS にホスト名が入っている必要はありません。 | 問題: Windows プラットフォームで、ssserver が開始できない |
重複経路のあるマシンが正しくロード・バランシングされず、ネーム・レゾリューションが失敗する | 複数アダプターのある Site Selector マシンが同じサブネットに接続されている | 問題: 重複経路のある Site Selector が正しくロード・バランシングされない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォーム上で Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォーム上で、コマンド・プロンプト・ウィンドウに破壊された Latin 1 国別文字が表示される |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システム上で、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
表 20. Cisco CSS スイッチ用コントローラーに関するトラブルシューティングの表
症状 | 考えられる原因 | 参照箇所 |
---|---|---|
ccoserver が開始されない | ポート番号が競合している | Cisco CSS Controller のポート番号の確認 |
ccocontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」というメッセージが表示される | コマンドは socks 化スタックが原因で失敗する。 または ccoserver の未始動が原因でコマンドが失敗する | 問題: ccocontrol または lbadmin コマンドが失敗する |
エラーを受信: ポート 13099 でレジストリーを作成できない | 製品ライセンスの有効期限切れ | 問題: ポート 13099 でレジストリーを作成できない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォーム上で Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
コンサルタントの追加時に接続エラーを受け取った | スイッチまたはコントローラーで構成設定が正しくない | 問題: コンサルタントの追加時に接続エラーを受け取った |
スイッチで重みが更新されない | コントローラーとスイッチとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: スイッチで重みが更新されない |
リフレッシュ・コマンドによってコンサルタント構成が更新されなかった | スイッチとコントローラーとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: リフレッシュ・コマンドによってコンサルタント構成が更新されなかった |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォーム上で、コマンド・プロンプト・ウィンドウに破壊された Latin 1 国別文字が表示される |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
表 21. Nortel Alteon Controller に関するトラブルシューティングの表
症状 | 考えられる原因 | 参照箇所 |
---|---|---|
nalserver が開始されない | ポート番号が競合している | Nortel Alteon Controller のポート番号の確認 |
nalcontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」というメッセージが表示される | コマンドは socks 化スタックが原因で失敗する。 または nalserver の未始動が原因でコマンドが失敗する。 | 問題: nalcontrol または lbadmin コマンドが失敗する |
エラーを受信: ポート 14099 でレジストリーを作成できない | 製品ライセンスの有効期限切れ | 問題: ポート 14099 でレジストリーを作成できない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォーム上で Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
コンサルタントの追加時に接続エラーを受け取った | スイッチまたはコントローラーで構成設定が正しくない | 問題: コンサルタントの追加時に接続エラーを受け取った |
スイッチで重みが更新されない | コントローラーとスイッチとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: スイッチで重みが更新されない |
リフレッシュ・コマンドによってコンサルタント構成が更新されなかった | スイッチとコントローラーとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: リフレッシュ・コマンドによってコンサルタント構成が更新されなかった |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows システム上で、コマンド・プロンプト・ウィンドウに破壊された Latin 1 国別文字が表示される |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
表 22. Metric Server に関するトラブルシューティングの表
症状 | 考えられる原因 | 参照箇所 |
---|---|---|
Windows プラットフォーム上で .bat または .cmd ユーザー・メトリック・ファイルを実行すると、Metric Server の IOException が発生する | 完全なメトリック名が必要です。 | 問題: Windows プラットフォーム上で .bat または .cmd ユーザー・メトリック・ファイルを実行すると、Metric Server の IOException が発生する |
Metric Server が Load Balancer マシンに負荷情報を報告していない | 考えられる原因には、以下が含まれます。
| 問題: Metric Server が負荷を Load Balancer マシンに報告していない |
Metric Server ログに、サーバーへのキー・ファイルの転送時には「エージェントへのアクセスにはシグニチャーが必要です」と報告されています。 | キー・ファイルは破壊が原因で許可に失敗しています。 | 問題: Metric Server ログに、「エージェントへのアクセスにはシグニチャーが必要です」と報告される |
AIX システムで、マルチプロセッサー・システム (AIX 4.3.3、または AIX 5.1) 上で Metric Server が高ストレスの状態で実行されている場合に、ps -vg コマンド出力が破壊されることがある | APAR IY33804 がこの既知の AIX の問題を訂正します。 | 問題: AIX システム上で、Metric Server が高ストレスの状態で実行されている間に、ps -vg コマンド出力が破壊される場合がある |
高可用性 Dispatcher 間の Site Selector ロード・バランシングを使用した 2 層構成での Metric Server の構成 | Metric Server (第 2 層に常駐) は新規 IP アドレスで listen するように構成されていません。 | 問題: ハイ・アベイラビリティー Dispatcher 間の Site Selector ロード・バランシングを使用した 2 層構成での Metric Server の構成 |
マルチ CPU の Solaris マシンで実行されている スクリプト (metricserver、cpuload、memload) が、希望と異なるコンソール・メッセージを出力する | この動作は、カーネルから CPU とメモリーの統計を収集するため に VMSTAT システム・コマンドが使用されていることによるものです。 | 問題: マルチ CPU の Solaris マシン上で実行されているスクリプトが 望まれないコンソール・メッセージを出す |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
Metric Server の始動後、メトリック値が -1 を戻す | この問題は、鍵ファイルをクライアントに転送中に、鍵ファイルの保全性が失われたために発生することがあります。 | 問題: Metric Server の始動後、メトリック値が -1 を戻す |
Dispatcher の実行で問題に遭遇した場合、通常は Dispatcher が使用するポート番号を使用しているアプリケーションがある可能性があります。Dispatcher サーバーは次のポート番号を使用します。
別のアプリケーションが Dispatcher のポート番号の 1 つを使用している場合は、Dispatcher のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Dispatcher のポート番号を変更します。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
CBR の実行で問題が起こっている場合、CBR が通常使用するポート番号を使用しているアプリケーションがある可能性があります。 CBR は以下のポート番号を使用します。
別のアプリケーションが CBR のポート番号の 1 つを使用している場合は、CBR のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、CBR のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Site Selector コンポーネントの実行で問題が起きる場合、Site Selector が通常使用するポート番号を使用しているアプリケーションがある可能性があります。Site Selector は次のポート番号を使用します。
別のアプリケーションが Site Selector のポート番号の 1 つを使用している場合は、Site Selector のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Site Selector のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Cisco CSS Controller コンポーネントの実行で問題が起きる場合には、Cisco CSS Controller の ccoserver が使用するポート番号の 1 つを別のアプリケーションが使用している可能性があります。Cisco CSS Controller は次のポート番号を使用することに注意してください。
13099。 ccocontrol からのコマンド受信用
10004。Metric Server へのメトリック照会送信用
13199。RMI サーバー・ポート用
別のアプリケーションが Cisco CSS Controller のポート番号の 1 つを使用している場合は、Cisco CSS Controller のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Cisco CSS Controller のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Nortel Alteon Controller コンポーネントの実行で問題が起きる場合、Nortel Alteon Controller の nalserver が使用するポート番号の 1 つを別のアプリケーションが使用している可能性があります。Nortel Alteon Controller は次のポート番号を使用することに注意してください。
14099。nalcontrol からのコマンド受信用
10004。Metric Server へのメトリック照会送信用
14199。RMI サーバー・ポート用
別のアプリケーションが Nortel Alteon Controller のポート番号の 1 つを使用している場合は、Nortel Alteon Controller のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Nortel Alteon Controller のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
この問題は、Dispatcher が使用するポートのいずれかを別のアプリケーションが使用している場合に起こります。詳細については、Dispatcher のポート番号の確認を参照してください。
この問題は、指定したアドレス以外の他のアドレスが使用されている場合に起こります。Dispatcher とサーバーを連結している場合は、構成で使用されるサーバー・アドレスは NFA アドレスであるか、連結したものとして構成されていなければなりません。 また、ホスト・ファイルで適正なアドレスを確認してください。
この問題には、クライアント・マシンからの接続が使用されていない、接続がタイムアウトであるなどの症状があります。以下のチェックを行い、この問題を診断します。
Windows およびその他のプラットフォームの場合、ロード・バランシングのためのサーバー・マシンのセットアップも参照してください。
この問題は、Dispatcher の HA 環境が構成されており、クライアント・マシンからの接続がサービスを提供されていない、あるいはタイムアウトになっている場合に起こります。以下をチェックして、問題を訂正または診断します。
以下のステップは、ハイ・アベイラビリティー・スクリプトが適切に 機能していることを検査する有効な方法です。
2 つの報告書は、スクリプトが適切に構成されている場合、同一です。
この Windows プラットフォームのエラーは、アダプターに送信元のアドレスが構成されていない場合に起こります。以下をチェックして、問題を訂正または診断します。
dscontrol executor configure <ip address>
サーバー・マシンをセットアップすると、意図せずに 1 つまたは複数のエクストラ経路が作成されてしまう場合があります。これらのエクストラ経路を除去しないと、Dispatcher が稼働しなくなってしまいます。エクストラ経路を確認して削除するには、ロード・バランシングのためのサーバー・マシンのセットアップを参照してください。
広域サポートを使用している場合に、advisor が正しく機能していないと考えられる場合は、 ローカルおよびリモート両方の Dispatcher で advisor が開始していることを確認してください。
ICMP ping は、advisor が要求する前に、サーバーに対して発行されます。 Load Balancer とサーバーとの間にファイアウォールが存在する場合、ping が ファイアウォールを越えてサポートされることを確認してください。このセットアップがご使用のネットワークにセキュリティー・リスクを出している場合、dsserver の java ステートメントを 変更して、java プロパティーを追加することでサーバーに対するすべての ping を オフにしてください。
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Dispatcher の広域サポートとリモート advisor の使用を参照してください。
Dispatcher、Microsoft IIS、および SSL の使用時に、これらが連係して動作しない場合、SSL セキュリティーの使用可能化で問題となることがあります。 鍵ペアの生成、証明書の取得、鍵ペアを含む証明書のインストール、SSL を必要とするディレクトリーの構成に関する詳細については、「Microsoft Information and Peer Web Services 」 資料を参照してください。
Dispatcher は、鍵を使用して、ユーザーがリモート・マシンに接続して構成できるようにします。鍵は、接続用の RMI ポートを指定します。セキュリティー上の理由および競合のため、RMI ポートを変更することができます。RMI ポートを変更した場合は、鍵のファイル名が異なります。同じリモート・マシンの鍵ディレクトリーに複数の鍵があり、異なる RMI ポートを指定している場合は、コマンド行は、最初に見つかったものしか試行しません。誤っていると、接続は拒否されます。誤った鍵を削除しない限り、接続は確立されません。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで稼働していて、dscontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、dsserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=10199 を LB_RMISERVERPORT= yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、dsserver を再始動し、ポート 10099、10004、10199、および 10100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
例: java -Djava.rmi.server.hostname="10.1.1.1"
Windows プラットフォームでは、デフォルトのブラウザーとして Netscape を使用している場合、 「ファイル '<filename>.html' (またはコンポーネントの 1 つ) が見つかりません」というエラー・メッセージが表示されることがあります。 パスおよびファイル名が正しいか確認し、必要なライブラリーがすべて使用可能 になっているようにしてください。
この問題は、HTML ファイルの関連付けが誤っていることが原因です。解決策は、以下のとおりです。
グラフィカル・ユーザー・インターフェース (GUI) の lbadmin を正しく機能させるには、十分なページング・スペースが必要です。使用可能なページング・スペースが不十分な場合には、GUI は正しく開始されません。これが起こる場合には、ページング・スペースを調べて、必要があればページング・スペースを増加してください。
別のバージョンを再インストールするために Load Balancer をアンインストールして、Dispatcher コンポーネントを開始しようとしたときにエラーが起きた場合には、Caching Proxy がインストールされているかどうかを調べてください。Caching Proxy にはいずれかの Dispatcher ファイルに依存関係があり、このファイルがアンインストールされるのは Caching Proxy をアンインストールしたときだけです。
この問題を避けるには、次のようにしてください。
Load Balancer の GUI の外観に問題が起きる場合は、オペレーティング・システムのデスクトップ解像度の設定を調べてください。GUI の表示には 1024x768 ピクセルのレゾリューションが最適です。
Windows プラットフォームでは、ヘルプ・ウィンドウを最初に開いたとき、既存のウィンドウの背後に隠れて見えなくなることがあります。これが起こる場合は、ウィンドウをクリックして、もう一度前面に出してください。
Solaris 上では、各ネットワーク・アダプターにはデフォルトで同じ MAC アドレスがあります。これは、各アダプターが異なる IP サブネット上にあるときには正しく機能します。しかし、スイッチ環境において、同じ MAC と同じ IP サブネット・アドレスをもつ複数の NIC が同じスイッチと通信すると、そのスイッチはすべてのトラフィックを同じワイヤーの下にある単一 MAC (および両方の IP) に送ります。フレームを最後にワイヤーに入れたアダプターだけが、両方のアダプター行きの IP パケットを表示できます。Solaris は、「誤った」インターフェースに届いた有効な IP アドレスのパケットを破棄する可能性があります。
すべてのネットワーク・インターフェースが、ibmlb.conf で構成されているように Load Balancer 用に指定されておらず、 かつ ibmlb.conf で定義されていない NIC がフレームを受け取った場合には、Load Balancer にはそのフレームを処理および転送する機能はありません。
この問題を避けるには、デフォルトを上書きして、それぞれのインターフェースごとに固有の MAC アドレスを設定する必要があります。以下のコマンドを使用してください。
ifconfig interface ether macAddr
例えば、以下のようになります。
ifconfig eri0 ether 01:02:03:04:05:06
Windows プラットフォームでは、ネットワーク・カードをインストールおよび構成していないと、executor を開始できません。
AIX オペレーティング・システムには、パス MTU ディスカバリーと呼ばれるネットワーク・パラメーターが入っています。クライアントとのトランザクション中に、発信パケットに小さめの最大送信単位 (MTU) を使用しなければならないとオペレーティング・システムが判別すると、パス MTU ディスカバリーは AIX にデータを記憶させるための経路を作成させます。 新規経路はその特定クライアント IP 用であり、そこに到達するために必要な MTU を記録します。
経路を作成しているときには、クラスターがループバック上に別名割り当てされる結果、サーバー上で問題が起きます。経路のゲートウェイ・アドレスがクラスター/ネットマスクのサブネットで途切れると、AIX システムはループバック上で経路を作成します。これは、そのサブネットを別名割り当てされた最後のインターフェースだった場合に起こります。
例えば、クラスターが 9.37.54.69 であり、255.255.255.0 のネットマスクが使用されて、使用予定のゲートウェイが 9.37.54.1 である場合、AIX システムは経路のループバックを使用します。 これにより、サーバーの応答がマシンから出されることがなくなり、クライアントは待機状態でタイムアウトしてしまいます。 通常は、クライアントにはクラスターからの応答が 1 つ表示され、次に経路が作成されてそのクライアントはそれ以上何も受け取りません。
この問題に対するソリューションには、以下の 2 つがあります。
注:
広域 Load Balancer をセットアップするときには、リモート Dispatcher をローカル Dispatcher のクラスターにあるサーバーとして定義しなければなりません。通常は、リモート Dispatcher の非転送アドレス (NFA) をリモート・サーバーの宛先アドレスとして使用します。これを実行してからリモート Dispatcher 上のハイ・アベイラビリティーをセットアップすると、これは失敗します。 これの NFA を使用してアクセスするときに、ローカル Dispatcher がリモート・サイドのプライマリーを常にポイントしているために、これが起こります。
この問題を回避するには、次のようにしてください。
リモート・プライマリー Dispatcher を使用すると、このアドレスをアダプター上で別名割り当てしてトラフィックを受け入れできるようにします。障害が起きる場合には、アドレスがバックアップ・マシンに移動して、バックアップがそのアドレスのトラフィックの受け入れを継続します。
lbadmin または Web 管理 (lbwebaccess) を使用して大規模の構成ファイル (おおよそ 200 個以上の add コマンド) を ロードしようとすると、GUI がハングするか、あるいは予期しない振る舞い (画面変更への応答が極端に低速になるなど) を示す場合があります。
これは、Java にこのように大きな構成を処理するだけの十分なメモリーへのアクセス権がないことが原因で起こります。
Java に使用可能なメモリー割り振りプールを増やすために指定できる、実行時環境についてのオプションがあります。
オプション -Xmxn です。 ここで、n はメモリー割り振りプールの最大サイズ (バイト単位) です。 n は 1024 の倍数になっていなければならず、2MB より大きくなっていなければなりません。 値 n には、K バイトを示すために k または K が続いているか、あるいは M バイトを示すために m または M が続いていてもかまいません。 例えば、-Xmx128M と -Xmx81920k は両方とも有効です。 デフォルト値は 64M です。 Solaris 8 では、最大値は 4000M です。
例えば、このオプションを追加するには、lbadmin スクリプト・ファイルを編集し、次のように "javaw" を "javaw -Xmxn" に変更します。 (AIX システムの場合、"java" を "java -Xmxn" に変更します):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
n の推奨値はありませんが、デフォルト・オプションよりも 大きい数値にする必要があります。 手始めに手ごろなのはデフォルト値の 2 倍を指定することです。
構成を更新した後に Load Balancer 管理 (lbadmin) がサーバーから切断される場合は、構成しようとしているサーバーの dsserver のバージョンを確認して、これが lbadmin または dscontrol のバージョンと同じであることを確認してください。
セキュア Socks インプリメンテーションでリモート・クライアントを使用するとき、 完全修飾ドメイン・ネームまたはホスト名が正しい IP アドレス形式表記の IP アドレスに 解決されないことがあります。Socks インプリメンテーションは、特定の Socks 関連データを DNS 解決に追加する場合があります。
リモート接続で正しく IP アドレスに解決されない場合は、IP アドレス形式表記の IP アドレスを指定してください。
韓国語の Load Balancer インターフェースでの重複フォントまたは不適切なフォントを訂正するには、以下を行います。
AIX システムの場合
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
Linux システムの場合
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
Windows システムで MS ループバック・アダプターの別名割り当て後に、hostname などのコマンドを実行すると、OS がローカル・アドレスではなく別名アドレスを使用して不正に応答します。この問題を訂正するには、ネットワーク接続リストで、新たに追加された別名を ローカル・アドレスの下にリストする必要があります。 これで、ループバック別名の前にローカル・アドレスにアクセスされるようになります。
ネットワーク接続リストを確認するには、以下を行います。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。 マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
Linux システムで、Load Balancer カーネル・モジュールの手動除去中に dsserver が まだ実行中の場合、システム・ハングや javacore などの予期しない振る舞いが発生することがあります。 Load Balancer カーネル・モジュールを手動で除去するときは、最初に dsserver を 停止する必要があります。
"dsserver stop" が機能しない場合、SRV_KNDConfigServer を使用して java プロセスを停止してください。 そのプロセスを停止するには、 ps -ef|grep SRV_KNDConfigServer コマンドを使用してプロセス ID を見つけてから、 killprocess_id コマンドを使用してそのプロセスを終了します。
"rmmod ibmlb" コマンドを実行して カーネルから Load Balancer モジュールを安全に除去することができます。
ロード・バランシング用に Dispatcher コンポーネントを実行している場合、クライアント・トラフィックでコンピューターが過負荷になることがあります。 Load Balancer カーネル・モジュールは最も高い優先度を持っており、これが絶え間なくクライアント・パケットを処理している場合、残りのシステムが 応答しなくなる場合があります。 ユーザー・スペースでコマンドを実行すると、完了するまでに非常に時間がかかるか、または完了しない可能性があります。
これが発生した場合、セットアップを再構成して、Load Balancer マシンが トラフィックで過負荷になることを回避する必要があります。 別の方法としては、複数の Load Balancer マシンに負荷を分散する、または Load Balancer マシンをより処理能力が高く、高速なコンピューターに 置き換える、というものがあります。
高クライアント・トラフィックが原因でマシンの応答が遅いのかどうかを判別するとき、この問題がクライアント・ピーク・トラフィック時間に発生するかどうかを検討します。 システムが誤って構成され、これが経路指定ループを招く場合には、同じ症状を引き起こすことがあります。 Load Balancer セットアップを変更する前に、この症状が高クライアント負荷によるものかどうかを 判別してください。
mac ベースの転送方式の使用すると、Load Balancer は、ループバックで別名を割り当てられた クラスター・アドレスを使用してパケットをサーバーに送信します。 いくつかのサーバー・アプリケーション (SSL など) は、構成情報 (証明書など) が IP アドレスに 基づいていることを必要とします。 受信パケットのコンテンツと一致するには、IP アドレスは、ループバックで 構成されたクラスター・アドレスでなければなりません。 サーバー・アプリケーションの構成時にクラスターの IP アドレスを使用しなかった場合、クライアント要求は正しくサーバーに転送されません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Microsoft IIS サーバー バージョン 5.0 を Windows バックエンド・サーバーで実行している場合、Microsoft IIS サーバーをバインド固有になるように構成する必要があります。 そうしなれければ、ソケット・プールがデフォルトとして使用可能になり、Web サーバーが、サイトの複数の ID として構成された仮想 IP アドレスではなく、0.0.0.0 にバインドされ、すべてのトラフィックを listen します。 ソケット・プールが有効なときにローカル・ホスト上のアプリケーションが停止する場合、 AIX または Windows ND サーバーの advisor がこれを検出します。ただし、ローカル・ホストの稼働中に仮想ホスト上のアプリケーションが停止する場合、advisor はこの障害を検出せず、Microsoft IIS は、停止したアプリケーションのトラフィックを含む、すべてのトラフィックに応答し続けます。
ソケット・プールが使用可能で、Web サーバーが 0.0.0.0 にバインドされているかどうかを 判別するには、次のコマンドを実行します。
netstat -an
Microsoft IIS サーバーを、バインド固有になる (ソケット・プールを使用不可にする) ように構成する方法は、Microsoft Product Support Services Web サイトに記載されています。以下のいずれかの URL にアクセスしてこの情報を入手することもできます。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、以下のようにします。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
Windows プラットフォームでは、複数の IP アドレスを使用して 1 つのアダプターを構成する場合、ホスト名に関連付ける IP アドレスはレジストリーの先頭に構成します。
Load Balancer は多くのインスタンス (例えば、lbkeys create など) で InetAddress.getLocalHost() に依存するため、単一アダプターに複数の別名 IP アドレスを割り当てると、問題が起こる可能性があります。この問題を回避するには、ホスト名に解決される IP アドレスをレジストリーの先頭にリストします。例えば、以下のようになります。
デフォルトでは、Windows オペレーティング・システムは、ネットワーク障害を検出すると、すべての静的エントリーを含むアドレス解決プロトコル (ARP) キャッシュをクリアします。ネットワークが使用可能になると、ネットワークで送信された ARP 要求によって ARP キャッシュが再入力されます。
ハイ・アベイラビリティー構成では、ネットワーク接続の切断がサーバーのどちらか、または両方に影響を与えると、両方のサーバーが 1 次運用を引き継ぎます。 ARP 要求が ARP キャッシュを再入力するために送信されると、両方のサーバーが応答し、これによって ARP キャッシュがエントリーに無効のマークを付けます。このため、advisor はバックアップ・サーバーに対するソケットを作成できなくなります。
接続が切断されても Windows オペレーティング・システムが ARP キャッシュをクリアしないようにすると、この問題が解決します。Microsoft は、この作業を行う方法を説明する記事を公開しています。この記事は、Microsoft サポート技術情報、記事番号 239924 (Microsoft Web サイト: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924) で参照できます。
以下は、Microsoft の記事で解説されている、システムによる ARP キャッシュの消去を回避する手順の要約です。
HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters
Linux カーネル 2.4.x サーバーおよび Dispatcher の MAC 転送方式を使用する場合には、 一定の考慮事項があります。 サーバーに、ip address add コマンドを使用してループバック・デバイスにクラスター・アドレスが構成されている場合、1 つのクラスター・アドレスにしか別名アドレスを割り当てることができません。
ループバック・デバイスへの複数のクラスターに別名アドレスを割り当てるときは、 ifconfig コマンドを使用します。例えば、次のようになります。
ifconfig lo:num clusterAddress netmask 255.255.255.255 up
また、インターフェースを構成する ifconfig メソッドと ip メソッドには、いくつかの非互換性があります。最良実例では、サイトが 1 つのメソッドを選択し、そのメソッドを排他的に使用することが提案されています。
Dispatcher 構成にサーバーを追加するときに、次の エラー・メッセージが出されることがあります。 "エラー: ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません"
この問題を判別するには、次のチェックリストを使用してください。
router パラメーターのデフォルト値は 0 で、サーバーがローカルであることを示しています。 サーバーのルーター・アドレスを 0 以外に設定すると、サーバーが別のサブネット上のリモート・サーバーであることを示します。 server add コマンドの router パラメーターの詳細については、dscontrol server -- サーバーの構成を参照してください。
追加するサーバーが別のサブネット上に存在する場合は、 router パラメーターの値は、ローカル・サブネット上でリモート・サーバーと通信するために使用される ルーターのアドレスにしてください。
Solaris システムでは、Load Balancer スクリプト (dsserver や lbadmin など) を 端末ウィンドウから開始した場合、そのウィンドウを終了すると、 Load Balancer プロセスも終了します。
この問題を解決するには、nohup コマンドを使用して Load Balancer スクリプトを 開始します。 例えば、次のようになります。 nohup dsserver このコマンドを使用すると、端末セッションが終了するときに 端末セッションから開始されたプロセスが端末からハングアップ・シグナルを受けず、端末セッションが終了した後もプロセスが継続することができます。 端末セッションの終了後も処理を継続させる Load Balancer スクリプトの前には、 nohup コマンドを使用してください。
Load Balancer 構成のロードには、長時間かかることがあります。 これは、サーバー・アドレスを解決して検証するために、ドメイン・ネーム・システム (DNS) 呼び出しが行われるためです。
Load Balancer マシンの DNS の構成に誤りがある場合、または DNS 全般に長時間かかる場合は、 ネットワーク上で DNS 要求を送信する Java プロセスが原因で、構成のロードの速度が低下します。
この問題に対する次善策は、サーバー・アドレスおよびホスト名を ローカルの /etc/hosts ファイルに追加することです。
ハイ・アベイラビリティーが構成されている場合は、 短時間の間、両方のマシンでクラスター・アドレスが構成されていることがあり、 その結果次のエラー・メッセージが出されます:「ネットワーク上の他のシステムとの IP アドレスの競合があります」。 この場合は、メッセージを無視しても問題がありません。 クラスター・アドレスを、短時間の間、両方のハイ・アベイラビリティー・マシンで同時に構成することは可能です (特に片方のマシンのスタートアップ中や、テークオーバーが開始されたとき)。
go* スクリプトを調べ、クラスター・アドレスが正しく構成されたり構成から外されるようになっている ことを確認してください。 ユーザーが構成ファイルを呼び出しており、go* スクリプトがインストールされている場合は、 構成ファイルのクラスター・アドレスに対する "executor configure" コマンド・ステートメントが使用されていない ことを確認してください。このステートメントが使用されていると、go* スクリプト の configure および unconfigure コマンドと競合します。
高可用性の構成時の go* スクリプトについて詳しくは、スクリプトの使用を参照してください。
この問題は、go スクリプトがプライマリー・マシンおよびバックアップ・マシンの両方で稼働していないときに発生することがあります。go スクリプトは dsserver が、両方のマシンで開始されていないと稼働しません。 両方のマシンを検査して、dsserver が稼働しているかどうか確認してください。
最大伝送単位 (MTU) が Dispatcher マシンに適切に設定されていないと、クライアントは、 大容量のページの結果がタイムアウトを応答するように要求します。Dispatcher コンポーネントの CBR および NAT 転送方式の場合、Dispatcher が値をネゴシエーションするのではなく、MTU 値を デフォルトとして取るため、これが発生します。
MTU は、通信メディア・タイプ (たとえば、イーサネットまたはトークンリング) を基にした オペレーティング・システムごとに設定されます。ローカル・セグメントからのルーターは、 異なるタイプの通信メディアに接続する場合、より小さな MTU セットを持ち ます。標準 TCP トラフィックのもとでは、MTU ネゴシエーションは、接続セットアップ中に 起こり、最も小さな MTU が、マシン間のデータ送信に使用されます。
Dispatcher は、Dispatcher の CBR または NAT 転送方式では MTU ネゴシエーションを サポートしません。TCP 接続のエンドポイントとして積極的に組み込まれているからです。 CBR および NAT 転送方式の場合、Dispatcher はデフォルトとして MTU 値を 1500 に します。この値は、標準イーサネットの標準 MTU サイズです。それで、ほとんどのカスタマーは この設定を調整する必要がありません。
Dispatcher の CBR または NAT 転送方式を使用している時、より小さな MTU を持つ ローカル・セグメントに対するルーターの場合、より小さな MTU にマッチングするする Dispatcher マシンに MTU を設定する必要があります。
この問題を解決するには、次のコマンドを使用して最大セグメント・サイズ (mss) の値を設定します。dscontrol executor set mss new_value
例えば、以下のようになります。
dscontrol executor set mss 1400
mss のデフォルト値は 1460 です。
mss の設定は、Dispatcher の mac 転送形式、または Load Balancer の 任意の non-Dispatcher コンポーネントには適用されません。
複数の IP アドレスが Windows システムに存在し、ホスト・ファイルが ホスト名に関連づけられたアドレスを指定しない時、 オペレーティング・システムは最も小さなアドレスを選択して、ホスト名に関連づけます。
この問題を解決するには、c:\Windows\system32\drivers\etc\hosts ファイルを、使用するマシンのホスト名、ホスト名に関連付ける IP アドレスで更新してください。
重要: その IP アドレスは、クラスター・アドレスにすることはできません。
qeth ネットワーク・ドライバーと一緒に Linux for S/390 マシンで ハイ・アベイラビリティーを使用している時、活動中および待機中の Dispatchers が同期するのに失敗することがあります。 この問題は、Linux Kernel 2.6 に限定される可能性があります。
この問題が発生した場合、以下の次善策を使用してください。
活動中と待機中の Dispatcher イメージ間の channel-to-channel (CTC) ネットワーク・デバイスを定義して、2 つの CTC エンドポイント IP アドレス間に ハートビートを追加します。
Load Balancer のハイ・アベイラビリティー機能を使用すると、 プライマリー・パートナーの障害やシャットダウンの場合に、 パートナー・マシンがロード・バランシングを引き継ぐことができます。 ハイ・アベイラビリティー・パートナー間の接続を維持するために、 2 台のマシン間で接続レコードが受け渡しされます。 バックアップ・パートナーがロード・バランシング機能を引き継ぐと、 クラスター IP アドレスがバックアップ・マシンから除去され、新しいプライマリー・マシンに追加されます。 この引き継ぎ操作に影響する可能性のある、タイミングと構成に関する考 慮事項がいくつかあります。
このセクションにリストされているヒントは、以下のようなハイ・アベ イラビリティーの構成上の問題から発生する問題の改善に役立ちます。
以下のヒントは、Load Balancer マシンでハイ・アベイラビリティーを正しく構成するのに役立ちます。
ハイ・アベイラビリティー・コマンドの例として、以下のものがあります。
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
通常、ハイ・アベイラビリティーの定義はファイルの終わりに配置する必要があります。 クラスター、ポート、およびサーバーのステートメントは、ハイ・アベイラビリティー・ステートメントの前に配置する必要があります。 これは、ハイ・アベイラビリティーが同期する際に、 接続レコードの受信時にクラスター、ポート、およびサーバー定義を検索 するためです。
クラスター、ポート、およびサーバーが存在しない場合、接続レコードはドロップされます。 引き継ぎが行われたときにパートナー・マシンに接続レコードが複製されていないと、 接続は失敗します。
このルールの例外は、MAC 転送方式で構成された連結サーバーを使用する場合です。 この場合、ハイ・アベイラビリティー・ステートメントは、連結サーバー・ステートメントの前に配置する必要があります。 ハイ・アベイラビリティー・ステートメントが連結サーバー・ステートメントの前にない場合、 Load Balancer は連結サーバーに対する要求を受け取りますが、 この要求はクラスターに対する着信要求と同じように表示され、ロード・バランシングが行われます。 その結果、ネットワーク上でパケットがループし、余分なトラフィックが 発生します。 ハイ・アベイラビリティー・ステートメントが連結サーバーの前に配置されると、 Load Balancer は、活動状態になるまで着信トラフィックを転送 してはならないことを認識します。
この振る舞いを訂正するには、goActive スクリプトにスリープ遅延を追加します。 スリープに必要な時間は、デプロイメントによって異なります。 最初はスリープ遅延時間を 10 にすることをお勧めします。
デフォルトで、マシンは 1/2 秒ごとに相互通信を試み、 4 回失敗すると失敗が検出されます。 ビジーのマシンがあると、システムが正しく機能していても、フェ イルオーバーになることがあります。 次のコマンドを実行して、失敗になるまでの回数を増やすことができます。
dscontrol executor set hatimeout <value>
これを行うには、長期に渡って、前の接続がメモリーに残 らないようにする必要があります。 特に、LDAP ポートと (1 日を超過する) 長い staletimeout 期間に関する問題があります。 長い staletimeout 期間を設定すると、 前の接続がメモリーに残り、同期の際に渡される接続レコードが増え、 両方のマシンでのメモリー使用量も増えます。
妥当な staletimeout 期間で同期が失敗した場合は、 次のコマンドを実行して同期タイムアウトを増やすことができます。
e xm 33 5 new_timeoutこのコマンドは、保存の際には構成ファイルに保管されないので、シャットダウンが起こってもこの設定が存続する必要がある場合は、このコマンドを手動で構成ファイルに追加する必要があります。
タイムアウト値は 1/2 秒単位で保管されます。 したがって、new_timeout のデフォルト値は 100 (50 秒) です。
一般に、MAC 転送方式を使用する場合、Load Balancer 構成のサーバーは、 プラットフォームに関係なく、すべて同じネットワーク・セグメント上に存 在する必要があります。 Load Balancer は、ルーター、ブリッジ、およびファイアウォールなどの活動中のネットワーク装置によって干渉されます。 これは、Load Balancer が、ネクスト・ホップと最終ホップへのリン ク層ヘッダーのみを変更する、特殊なルーターとして機能するため です。 ネクスト・ホップが最終ホップではないネットワーク・トポロジーは、 Load Balancer では無効です。
OSA カードを共用する zSeries および S/390 サーバー向けの制限があります。 これは、このアダプターが通常のネットワーク・カードとは異なる動作をするためです。 OSA カードには、独自の仮想リンク層が実装されています。 これは、イーサネットとは関係がなく、その背後にある Linux および z/OS ホスト向けです。 事実上、各 OSA カードは、ちょうどイーサネット間ホスト (OSA ホスト向けではありません) のようなもので、 このカードを使用するホストは、このカードがあたかもイーサネットであるか のように これに応答します。
OSA カードには、IP 層に直接関連したいくつかの機能も実行します。 ARP (アドレス解決プロトコル) 要求への応答は、このホストが実行する機能の 1 例です。 もう 1 つの機能は、イーサネット・アドレスの代わりに、 宛先の IP アドレスを基に、共用 OSA が IP パケットをレイヤー 2 スイッチとして経路指定することです。 事実上、OSA カードは、それ自体へブリッジされたネットワーク・セグメントです。
S/390 Linux または zSeries Linux ホスト上で実行される Load Balancer は、 同じ OSA 上のホストやイーサネット上のホストに転送できます。 同じ共用 OSA 上のすべてのホストは、事実上同じセグメント上にあります。
Load Balancer は、OSA ブリッジの性質により、共用 OSA の外部に転送 することができます。 このブリッジは、クラスター IP を所有する OSA ポートを認識します。 このブリッジは、直接イーサネット・セグメントに接続されているホストの MAC アドレスを認識します。 したがって、Load Balancer は 1 つの OSA ブリッジを介して MAC 転送することができます。
ただし、Load Balancer は共用 OSA 内に転送することはできません。 バックエンド・サーバーが Load Balancer とは異なる OSA カードを使用しているときに、 Load Balancer が S/390 Linux 上にある場合も同様です。 バックエンド・サーバー向けの OSA は、サーバー IP の OSA MAC アドレスを通知しますが、 サーバーの OSA カードは、パケットがサーバー向けの OSA のイーサネットの宛先アドレスとクラスター IP とともに到着した場合、 どのホスト (存在する場合) がそのパケットを受け取るのかを認識しません。 ある共用 OSA の外部へ向けた OSA からイーサネットへの MAC 転送が許可 されるときと同じ原理は、共用 OSA の内部に向けて転送する際には無効です。
次善策:
OSA カードを備えた zSeries または S/390 サーバーを使用する Load Balancer 構成では、 前述の問題の次善策として実行できる方法が 2 つあります。
Load Balancer 構成のサーバーが、同じタイプの zSeries または S/390 プラットフォーム上にある場合、 Load Balancer と各サーバーの間で point-to-point (CTC または IUCV) 接続を定義できます。 プライベート IP アドレスを持つエンドポイントをセットアップします。 point-to-point 接続は、Load Balancer とサーバー間のトラフィックにのみ使用します。 次に、トンネルのサーバー・エンドポイントの IP アドレスを持つサーバーを追加します。 この構成により、クラスター・トラフィックが Load Balancer の OSA カードを介して到達し、 point-to-point 接続を介して転送されます。 この場合、サーバーは独自のデフォルトの経路を通って応答します。 応答は、サーバーの OSA カードを使用して発信されますが、 このカードは同じである場合もあれば、異なる場合もあります。
Load Balancer 構成内のサーバーが同じタイプの zSeries ある いは S/390 プラットフォーム上にない場合、 または Load Balancer と各サーバーの間で point-to-point 接続を定義できない場合は、 Load Balancer の総称経路指定カプセル化 (GRE) 機能を使用することをお勧めします。 これは、Load Balancer に、ルーターを介した転送を許可するプロトコルです。
GRE を使用している場合、クライアントからクラスターへの IP パケットは、 Load Balancer が受け取り、カプセル化してサーバーに送信します。 サーバーでは、元のクライアントからクラスターへの IP パケットがカプセル化され、 サーバーが直接クライアントに応答します。 GRE を使用する利点は、Load Balancer が、サーバーからクライアントへのトラフィックではなく、 クライアントからサーバーへのトラフィックのみを認識することです。 欠点は、カプセル化のオーバーヘッドにより、TCP 接続の最大セグメント・サイズ (MSS) が小さくなることです。
GRE カプセル化を使用して転送するように Load Balancer を構成するには、 次のコマンドを使用してサーバーを追加します。
dscontrol server add cluster_add:port:backend_server router backend_server
この場合、router backend_server は、 Load Balancer とバックエンド・サーバーが同じ IP サブネット上にある場合に有効です。 そうでない場合は、有効な、ネクスト・ホップの IP アドレスをルーター として指定します。
ネイティブの GRE カプセル化を実行するように Linux システムを 構成するには、バックエンド・サーバーごとに、以下のコマンドを発行します。
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add cluster_addr dev grelb0
manager および advisor 機能で構成された Load Balancer を実行中に、 一部の Red Hat Linux バージョンで大量のメモリー・リークが発生することがあります。 advisor の時間間隔を短く設定して構成すると、Java のメモリー・リークが増加します。
Red Hat Enterprise Linux 3.0 などの一部の Linux 配布版に同梱の JVM の IBM Java SDK バージョンおよび Native POSIX Thread Library (NPTL) では、 メモリー・リークが起こる可能性があります。拡張スレッド化ライブラリー NPTL は、NPTL をサポートするいくつかの Linux システムの配布版 (Red Hat Enterprise Linux 3.0 など) に同梱されます。
Linux システムおよびこれらのシステムに同梱の IBM Java SDK に関する最新情報については、 http://www.ibm.com/developerworks/java/jdk/linux/tested.html を参照してください。
問題判別ツールとして、vmstat または ps コマンドを使用してメモリー・リークを検出します。
メモリー・リークを修正するには、Load Balancer マシンを実行する前に 、次のコマンドを発行して NPTL ライブラリーを使用不可にします。
export LD_ASSUME_KERNEL=2.4.10
Suse Linux Enterprise Server 9 では、MAC 転送方式の使用中、 DisPatcher 報告書に、パケットが転送された (パケット数が増加) にも かかわらず、バックエンド・サーバーに到達していないということが示される場合があります。
この問題が発生した場合は、以下のいずれか、またはその両方を監視します。
ip_finish_output2: No header cache and no neighbour!
ICMP Destination unreachable: Fragmentation Needed
この問題は、ロードされた iptables NAT モジュールが原因で発生することがあります。 SLES 9 では、このバージョンの iptables で、Dispatcher との 対話で異常な振る舞いが発生するという、起こりうるが未確認のエラーが発生 します。
解決策:
iptables NAT モジュールと接続トラッキング・モジュールをアンロードします。
例えば、以下のようになります。
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
モジュールをその使用順序に従って除去します。 具体的には、モジュールは参照数 (lsmod 出力の最終列) がゼロである場合にのみ除去できます。 iptables のルールを構成した場合は、それらを除去する必要があります。 例えば、iptables -t nat -F のようにします。
iptable_nat モジュールは ip_conntrack を使用するので、 まず iptable_nat モジュールを除去してから ip_conntrack モジュールを除去します。
Windows システムでは、Load Balancer のハイ・アベイラビリティー機能を実行する場合、 go スクリプトを使用して活動中の Load Balancer 上にクラスター IP を構成し、 引き継ぎが行われるときにバックアップ・システム上のクラスター IP の構成を解除します。 活動中のマシンでクラスターの IP アドレスを構成する go スクリプトを、 バックアップ・マシンで IP クラスター・アドレスの構成を解除する go スクリプトの前に実行すると、問題が発生することがあります。 システムで IP アドレスの競合が検出されたことを通知するポップアップ・ウィンドウが表示される場合があります。 ipconfig all コマンドを実行した場合に、マシン上に 0.0.0.0 という IP アドレスがあると表示される場合もあります。
解決策:
次のコマンドを発行して、プライマリー・マシンから手動でクラスター IP アドレスの構成を解除します。
dscontrol executor unconfigure clusterIP
これにより、 Windows IP スタックから 0.0.0.0 アドレスが除去されます。
ハイ・アベイラビリティー・パートナーがクラスター IP アドレスを解放した後、 次のコマンドを発行して、手動でクラスター IP を追加し直します。
dscontrol executor configure clusterIP
このコマンドの発行後、次のコマンドを発行して、Windows IP スタ ックで再度クラスター IP アドレスを検索します。
ipconfig /all
Linux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Dispatcher マシンでは無効にする必要があります。
次のコマンドを発行して、iptables がロードされているかを判別します。
lsmod | grep ip_tables
このコマンドからの出力は、次のようになります。
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
出力にリストされて いる各 iptable に対して次のコマンドを発行して、テーブルのルールを表示します。
iptables -t <short_name> -L
例えば、以下のようになります。
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
iptable_nat がロード済みの場合は、アンロードする必要があります。 iptable_nat は iptable_conntrack に依存するため、iptable_conntrack も除去する必要があります。 次のコマンドを発行して、これら 2 つの iptables をアンロードします。
rmmod iptable_nat iptable_conntrack
Load Balancer では、製品のインストールとともに Java ファイル・セットが提供されています。 製品のインストールは、同じマシンにインストールする必要がない、複数のパ ッケージで構成されています。 Metric Server パッケージ、管理パッケージ、および基本パッケージがその例です。 これらすべてのコード・パッケージでは、 Java ファイル・セットが機能することが必要ですが、3 つのパッケージはそれぞれ別のマシンにインストールすることもできます。 そのため、これらのパッケージは、それぞれが Java ファイル・セットをインストールします。 同じマシンにインストールされた場合、Java ファイル・セットはこれらの各ファイル・セットによって所有されます。 2 番目と 3 番目の Java ファイル・セットをインストールすると、 Java ファイル・セットが別のファイル・セットでも所有されているという警告メッセージが表示されます。
ネイティブのインストール方式 (例えば AIX の installp) を使用してコードをインストールする場合は、 Java ファイル・セットが別のファイル・セットによって所有されているという警告メッセージを無視する必要があります。
Load Balancer のインストール・プロセスでは、Java ファイル・セットもインストールされます。 Load Balancer は、製品とともにインストールされる Java バージョンを使用する唯一のアプリケーションです。 このバージョンの Java ファイル・セットは、独自にアップグレードしないでください。 Java ファイル・セットのアップグレードを必要とするような問題がある場合は、 IBM サービスに連絡した上で、Load Balancer に同梱の Java ファイル・セットを正式な修正レベルでアップグレードしてください。
Microsoft Windows オペレーティング・システム上では、高可用性の引き継ぎ時に パーシスタント接続が切断される場合があります。この問題は、MAC 転送方式を使用する連結サーバーの場合にのみ発生します。
イーサネット・インターフェースまたはループバック・インターフェースからクラスター IP アドレスが削除された場合、その IP アドレス上のすべての接続がリリースされます。リリースされた接続上でパケットを受信すると、オペレーティング・システムはクライアントに RST 応答を送信し、接続は終了します。
高可用性の引き継ぎ中に接続が切断されるのを回避するには、MAC 転送方式の使用時に、Windows オペレーティング・システム上で連結サーバーを使用しないでください。
この問題は、zSeries 32 ビット Linux オペレーティング・システム上で Edge インストーラーに制限があることが原因です。
この問題を避けて作業を行うには、32 ビット zSeries Linux オペレーティング・システムに対して手動インストールを実行します。詳しくは、Linux システムの場合のインストールを参照してください。
この問題は、Linux オペレーティング・システム上で Edge インストーラーに制限があることが原因です。
Linux オペレーティング・システム上で WebSphere Edge Server をアンインストールするには、製品を手動でアンインストールする必要があります。製品全体をアンインストールするには、 コマンド rpm -e 'rpm -qa | grep ibmlb' を入力します。
個別のパッケージをアンインストールするには、コマンド rpm -e <package name> を入力します。パッケージ名は、セクション Linux システムの場合のインストールで検索することができます。インストール時の逆の順序でパッケージをアンインストールすることに注意してください。
この問題は、他のアプリケーションが CBR によって使用されるポートのいずれかを使用している場合に起こります。詳しくは、CBR ポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、 Load Balancer がファイアウォールと同じマシン上で実行されている場合に cbrcontrol コマンドが発行されると、「エラー: サーバーが応答していません」などのエラーが表示される場合があります。
この問題を避けるには、cbrserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=11199 を LB_RMISERVERPORT= yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、cbrserver を再始動し、ポート 11099、10004、11199、および 11100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
Caching Proxy および CBR は開始されましたが、要求はロード・バランシングされていません。このエラーは、executor を開始する前に Caching Proxy を開始すると起こる可能性があります。これが起こる場合は、Caching Proxy の stderr ログにエラー・メッセージ「ndServerInit: executor に接続できません」が入ります。この問題を避けるには、Caching Proxy を開始する前に executor を開始します。
Solaris システムの場合は、cbrcontrol executor start コマンドにより、 「エラー: executor が開始されていませんでした」が戻されます。このエラーは、そのシステムの IPC (プロセス間通信) を構成していないために、共用メモリー・セグメントとセマフォー ID の最大サイズが、オペレーティング・システムのデフォルトより大きくなっている場合に起こります。共用メモリー・セグメントおよびセマフォー ID のサイズを増加するには、/etc/system ファイルを編集する必要があります。このファイルの構成方法について詳しくは、 IPC (プロセス間通信) のシステム・デフォルトの変更 を参照してください。
URL ルールが機能しないときには、構文エラーまたは構成エラーのある可能性があります。この問題が起きる場合には、以下をチェックしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。 マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する セクションの手順を参照してください。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
これらの設定を構成する手順については、問題: Windows システム上で、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける を参照してください。
Windows プラットフォームでは、複数の IP アドレスを使用して 1 つのアダプターを構成する場合、ホスト名に関連付ける IP アドレスはレジストリーの先頭に構成します。
Load Balancer は多くのインスタンス (例えば、lbkeys create など) で InetAddress.getLocalHost() に依存するため、単一アダプターに複数の別名 IP アドレスを割り当てると、問題が起こる可能性があります。この問題を回避するには、ホスト名に解決される IP アドレスをレジストリーの先頭にリストします。
ホスト名をレジストリーの先頭に構成する手順については、問題: Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合、IP アドレスをホスト名に解決する を参照してください。
この問題は、他のアプリケーションが Site Selector によって使用されるポートのいずれかを使用している場合に発生します。詳しくは、Site Selector のポート番号のチェックを参照してください。
症状: Site Selector コンポーネントが Solaris クライアントからの受信要求をラウンドロビンしません。
考えられる原因: Solaris システムがネーム・サービス・キャッシュ・デーモンを実行しています。このデーモンが実行されていると、後続のリゾルバー要求は Site Selector ではなくこのキャッシュから応答されます。
解決法: Solaris マシン上のネーム・サービス・キャッシュ・デーモンをオフにしてください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、 Load Balancer がファイアウォールと同じマシン上で実行されている場合に sscontrol コマンドが発行されると、「エラー: サーバーが応答していません」などのエラーが表示される場合があります。
この問題を避けるには、ssserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=10199 を LB_RMISERVERPORT= yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、ssserver を再始動し、ポート 12099、10004、12199、および 12100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
Site Selector は DNS に参加していなければなりません。 構成に関係しているマシンのすべては、このシステムにも関係している必要があります。 Windows システムでは、必ずしも DNS 内でホスト名が構成されている必要はありません。Site Selector は、正しく開始されるために、そのホスト名が DNS に定義されていることが必要です。
このホストが DNS に定義されていることを確認してください。 ssserver.cmd ファイルを編集し、"w" を "javaw" から除去してください。 これで、エラーについてより多くの情報が提供されます。
Site Selector のネーム・サーバーがマシン上のどのアドレスにもバインドされていません。これは、マシン上の有効な任意の IP 用に予定された要求に応答します。Site Selector は、クライアントに戻す応答の経路指定をオペレーティング・システムに依存します。Site Selector マシンに複数のアダプターがあり、そのいくつかが同じサブネットに接続されている場合は、O/S がクライアントへの応答を受け取ったものとは異なるアドレスから送信することが可能です。クライアント・アプリケーションによっては、送信したアドレス以外から受信した応答を受け入れません。そのために、ネーム・レゾリューションにより失敗することになります。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。 マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する セクションの手順を参照してください。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
これらの設定を構成する手順については、問題: Windows システム上で、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける を参照してください。
この問題は、他のアプリケーションが Cisco CSS Controller の ccoserver によって使用されるポートのいずれかを使用している場合に発生します。詳しくは、Cisco CSS Controller のポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、 Load Balancer がファイアウォールと同じマシン上で実行されている場合に ccocontrol コマンドが発行されると、「エラー: サーバーが応答していません」などのエラーが表示される場合があります。
この問題を避けるには、ccoserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 CCO_RMISERVERPORT=14199 を CCO_RMISERVERPORT= yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、ccoserver を再始動し、ポート 13099、10004、13199、および 13100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
この問題は、有効な製品ライセンスがないときに起こります。ccoserver を開始するときに、以下のメッセージを受け取ります。
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
この問題を訂正するには、次のようにしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。 マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
コンサルタントの追加時に、正しくない構成設定が原因で接続エラーが発生することがあります。 この問題を修正するには、次のようにしてください。
この問題を修正するには、次のようにしてください。
コンサルタントのログ・レベルを上げ、コマンドを再試行します。 再度失敗した場合、ログで SNMP タイムアウトまたはその他の SNMP 通信エラーを検索してください。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する セクションの手順を参照してください。
この問題は、他のアプリケーションが Nortel Alteon Controller の nalserver によって使用されるポートのいずれかを使用している場合に発生します。詳しくは、Nortel Alteon Controller のポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、 Load Balancer がファイアウォールと同じマシン上で実行されている場合に nalcontrol コマンドが発行されると、「エラー: サーバーが応答していません」などのエラーが表示される場合があります。
この問題を避けるには、nalserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 NAL_RMISERVERPORT=14199 を NAL_RMISERVERPORT= yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、nalserver を再始動し、ポート 14099、10004、14199、および 14100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
この問題は、有効な製品ライセンスがないときに起こります。nalserver を開始するときに、以下のメッセージを受け取ります。
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
この問題を訂正するには、次のようにしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。 マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
コンサルタントの追加時に、正しくない構成設定が原因で接続エラーが発生することがあります。 この問題を修正するには、次のようにしてください。
この問題を修正するには、次のようにしてください。
コンサルタントのログ・レベルを上げ、コマンドを再試行します。 再度失敗した場合、ログで SNMP タイムアウトまたはその他の SNMP 通信エラーを検索してください。
Windows プラットフォームのオペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、問題: HP-UX 上で、Java メモリー不足/スレッド・エラーが発生する セクションの手順を参照してください。
Windows プラットフォーム上で実行する Metric Server のユーザー作成メトリックには、完全メトリック名を使用する必要があります。 例えば、usermetric ではなく、usermetric.bat を指定しなければなりません。usermetric の名前はコマンド行では有効ですが、実行時環境内部から実行するときには動作しません。完全メトリック名を使用しないと、Metric Server 入出力例外を受け取ります。metricserver コマンド・ファイルにおいて LOG_LEVEL 変数を 3 の値に設定してから、ログ出力にチェックを入れてください。この例では、例外は次のように表示されます。
... java.io.IOException: CreateProcess: usermetric error=2
Metric Server が負荷情報を Load Balancer に報告していない理由はいくつか考えられます。この原因を判別するには、以下の検査を実行します。
この問題は、metricserver スクリプトの Java プロパティー java.rmi.server.hostname にホスト名を指定することによっても解決できます。
Metric Server ログには、キー・ファイルがサーバーに転送された後で、このエラー・メッセージが報告されています。
このエラーが記録されるのは、ペアのキーの破壊が原因で、キー・ファイルがペアのキーによる許可に失敗する場合です。 この問題を訂正するには、以下を試みます。
マルチプロセッサー AIX プラットフォーム (4.3.3、32 ビット 5.1、または 64 ビット 5.1) 上で Metric Server が高ストレスの状態で実行されている間に、ps -vg コマンドからの出力が破壊される場合があります。 例えば、以下のようになります。
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
ps コマンドの SIZE フィールドまたは RSS フィールド (あるいは、その両方) で、メモリーが過剰に使用されていることを示す場合があります。
これは、AIX カーネルに関する既知の問題です。APAR IY33804 がこの問題を訂正します。 http://techsupport.services.ibm.com/server/fixes の AIX サポートからフィックスを入手するか、 またはお近くの AIX サポート担当者に連絡してください。
2 層 Load Balancer 構成では、Site Selector (第 1 層) が Dispatcher ハイ・アベイラビリティー・パートナーのペアでロード・バランシングを行っている場合、Metric Server コンポーネントを構成するために完了しなければならない手順があります。Metric Server 専用の新規 IP アドレスで listen するように、Metric Server を構成する必要があります。2 つのハイ・アベイラビリティー Dispatcher マシンにおいては、Metric Server はアクティブ Dispatcher でのみアクティブになります。
このセットアップを正しく構成するには、次の手順を完了してください。
例えば、以下のようになります。
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Sleep either max 60 seconds or until the metricserver stops let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
例えば、以下のようになります。
call netsh interface ip delete address "Local Area Connection" addr=9.27.23.61 call netsh interface ip add address "Local Area Connection 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
metricserver、cpuload、および memload スクリプトは、マルチ CPU の Solaris マシンで実行する場合は、 ユーザーの望まないコンソール・メッセージを出す場合があります。 この動作は、カーネルから CPU とメモリーの統計を収集するため に VMSTAT システム・コマンドが使用されていることによるものです。 VMSTAT が戻すメッセージの一部は、 カーネルの状態が変更したことを示しています。 スクリプトは、 これらのメッセージをハンドルできないので、その結果 シェルから不要なコンソール・メッセージが表示されます。
これらのコンソール・メッセージの例として、次のものがあります。
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
これらのメッセージは、無視することができます。
この問題は、クライアントへの転送中に鍵ファイルの保全性が失われた結果、発生することがあります。
FTP を使用して Load Balancer マシンからバックエンド・サーバーに鍵ファイルを転送する場合は、 必ずバイナリー・モードを使用して FTP サーバーとの間で鍵ファイルを put または get してください。
この部では、すべての Load Balancer コンポーネントに関するコマンド解説情報が提供されます。この部には、以下の章があります。
構文図は、オペレーティング・システムが正しくユーザーの入力を解釈できるように、コマンドの指定方法を示すものです。構文図は左から右へ、 上から下へ、水平線 (メインパス) に沿って読み進めます。
構文図では、以下の記号が使用されます。
構文図に示されているコロン、引用符、負符号 (-) などの句読点は、すべてそのとおりに指定してください。
構文図では、以下のようなタイプのパラメーターが使用されています。
パラメーターは、キーワードまたは変数に分類されます。キーワードは小文字で示され、小文字で入力することが可能です。例えば、コマンド名などがキーワードになります。変数はイタリックで示され、ユーザーの入力する名前や値を示します。
以下の例では、user コマンドがキーワードになります。user_id は必須の変数であり、password は任意指定の変数です。変数の値はユーザーが独自に置き換えます。
>>-user--user_id--+----------+--------------------------------->< '-password-'
必須のキーワード: 必須のキーワードおよび変数はメインパス上に示されます。
>>-required_keyword--------------------------------------------><
必須のキーワードおよび値は必ずコーディングしなければなりません。
スタックの中から必須項目を 1 つ選択する: 一緒に指定できない複数の必須キーワードまたは必須変数の中から 1 つを指定しなければならない場合には、項目は英数字順に縦方向に並べてスタックされます。
>>-+-required_parameter_1-+------------------------------------>< '-required_parameter_2-'
任意指定の値: 任意指定のキーワードおよび変数はメインパスの下に示されます。
>>-+---------+------------------------------------------------->< '-keyword-'
任意指定キーワードおよび変数は必ずしも指定する必要はありません。
スタックの中から任意指定項目を 1 つ選択する: 一緒に指定できない複数の任意指定キーワードまたは変数の中から 1 つを指定しなければならない場合には、項目は英数字順にメインパスより下に縦方向でスタックされます。
>>-+-------------+--------------------------------------------->< +-parameter_1-+ '-parameter_2-'
変数: イタリックで示される単語はすべて 変数 です。構文内に変数がある場合には、ユーザーがテキストの定義に従って使用可能な名前または値で置き換える必要があります。
>>-variable----------------------------------------------------><
英数字以外の文字: 構文図に英数字以外の文字 (コロン、引用符、負符号 (-) など) が示されている場合には、それらの文字も構文の一部としてコーディングする必要があります。この例では、cluster:port とコーディングします。
>>-cluster:port------------------------------------------------><
この章では、Dispatcher dscontrol コマンドの使用方法について説明します。これは CBR のコマンド解説でもあります。
前のバージョンでは、製品は Network Dispatcher として知られており、Dispatcher 制御コマンド名は ndcontrol でした。 Dispatcher 制御コマンド名は、現在 dscontrol です。 以前のスクリプト・ファイルをすべて更新し、Dispatcher の構成に ndcontrol ではなく dscontrol を使用していることを確認してください。
CBR は、このコマンド解説書にリスとされている Dispatcher コマンドのサブセットを使用します。CBR でこれらの構文図を使用する場合、dscontrol の 代わりに cbrcontrol を使用します。詳しくは、CBR と Dispatcher との間の構成の違いを参照してください。
以下のリストには、本章で特に言及されているコマンドが含まれます。
dscontrol コマンド・パラメーターは、最小限バージョンで入力することができます。 入力する必要があるのは、パラメーターの固有文字だけです。例えば、file save コマンドに関するヘルプを表示するには、dscontrol help file の代わりに dscontrol he f と入力することができます。
コマンド行インターフェースを始動するには、dscontrol を実行して、dscontrol コマンド・プロンプトを表示します。
コマンド行インターフェースを終了するには、exit または quit を実行します。
コマンド・パラメーター値は、英字で入力する必要があります。 唯一の例外は、ホスト名 (クラスター、サーバー、およびハイ・アベイラビリティー・コマンドで使用) およびファイル名 (ファイル・コマンドで使用) です。
CBR コマンド行インターフェースは、Dispatcher のコマンド行インターフェースのサブセットです。CBR では、dscontrol の代わりに cbrcontrol コマンドを使用してコンポーネントを構成します。
CBR で 省略されている コマンドのいくつかを以下にリストします。
>>-dscontrol--advisor--+-connecttimeout--name--+-port---------+--timeoutseconds-+->< | '-cluster:port-' | +-interval--name--+-port---------+--seconds--------------+ | '-cluster:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port---------+--level----------------+ | '-cluster:port-' | +-logsize--name--+-port---------+--+-unlimited---------+-+ | '-cluster:port-' '-number of records-' | +-receivetimeout--name--+-port---------+--timeoutseconds-+ | '-cluster:port-' | +-report--name--+-port---------+-------------------------+ | '-cluster:port-' | +-retries--name--+-port---------+--numretries------------+ | '-cluster:port-' | +-start--name--+-port---------+--+----------+------------+ | '-cluster:port-' '-log file-' | +-status--name--+-port---------+-------------------------+ | '-cluster:port-' | +-stop--name--+-port---------+---------------------------+ | '-cluster:port-' | +-timeout--name--+-port---------+--+-unlimited-+---------+ | '-cluster:port-' '-seconds---' | '-version--name--+-port---------+------------------------' '-cluster:port-'
Load Balancer が提供する advisor について詳しくは、advisor のリストを参照してください。
カスタマイズされた advisor の名前は xxxx の形式になっています。ここで、ADV_xxxx は、カスタム advisor をインプリメントするクラスの名前です。詳しくは、カスタム (カスタマイズ可能) advisor の作成を参照してください。
クラスターは IP アドレス形式またはシンボル名のアドレスです。ポートは、advisor がモニターするポートの番号です。
advisor 名 | プロトコル | ポート |
---|---|---|
cachingproxy | HTTP (Caching Proxy 経由) | 80 |
connect | ICMP | 12345 |
db2 | プライベート | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | プライベート | 12345 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | プライベート | 10,007 |
デフォルトのファイルは、advisorname_port.log (http_80.log など) です。ログ・ファイルを保存するディレクトリーを 変更するには、ログ・ファイル・パスの変更を参照してください。クラスター (またはサイト) 固有の advisor のデフォルト・ログ・ファイルは、クラスター・アドレスを使用して作成されます。例えば、http_127.40.50.1_80.log です。
例
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listこのコマンドによって、以下のような出力が生成されます。
--------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21このコマンドによって、以下のような出力が生成されます。
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
dscontrol advisor status http 80このコマンドにより、以下のような出力が生成されます。
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
dscontrol advisor timeout ftp 21 5
dscontrol advisor version ssl 443このコマンドにより、以下のような出力が生成されます。
Version: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--hours--+-+ | '-interval--seconds-' | '-status---------------------'
>>-dscontrol--cluster--+-add--cluster+c2+...--+----------------------------------------+-+->< | +-address--address-----------------------+ | | +-proportions--active--new--port--system-+ | | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-set--cluster+c2+...--+-proportions--active--new--port--system-+-+ | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-remove--cluster-------------------------------------------------+ +-report--cluster-------------------------------------------------+ '-status--cluster-------------------------------------------------'
dscontrol cluster add コマンドの例外として、ワイルドカードとしての働きをするコロン (:) を使用することができます。例えば、次のコマンド dscontrol cluster set : weightbound 80 は、結果的にすべてのクラスターに重み限界 80 を選択することになります。
クラスターの primaryhost を変更すると、プライマリーおよびバックアップは開始済みとなり、相互ハイ・アベイラビリティーを実行します。 また、新規のプライマリー・ホストに強制的に引き継ぎを行わなければなりません。スクリプトを更新し、クラスターを手動で正しく構成解除して正しく構成する必要もあります。 詳しくは、相互高可用性を参照してください。
例
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167このコマンドによって、以下のような出力が生成されます。
Cluster Status: ---------------- Cluster ................................. 9.67.131.167 Address ................................. 9.67.131.167 Number of target ports .................. 3 Default sticky time ..................... 0 Default stale timeout ................... 30 Default port weight bound ............... 20 Maximum number of ports ................. 8 Default port protocol ................... tcp/udp Default maximum number of servers ....... 32 Proportion given to active connections... 0.5 Proportion given to new connections...... 0.5 Proportion given specific to the port.... 0 Proportion given to system metrics....... 0 Shared bandwidth (KBytes) ............... 0 Primary Host Address .................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--IP address------------+------------------------------+ | +-maxclusters--size----------+ | | +-maxports--size-------------+ | | +-fintimeout--fintimeout-----+ | | +-hatimeout--time------------+ | | +-hasynctimeout--time--------+ | | +-maxservers--size-----------+ | | +-mss--size------------------+ | | +-staletimeout--staletimeout-+ | | +-stickytime--time-----------+ | | +-clientgateway--address-----+ | | +-weightbound--weight--------+ | | +-porttype--type-------------+ | | +-wideportnumber--port-------+ | | '-sharedbandwidth--size------' | +-configure--interface_address+i2+...--+-------------------------+-+ | '-interface_name--netmask-' | +-unconfigure--interface_address-----------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
プライマリー・マシンとバックアップ・マシンを 確実に同期するには、タイマーを使用します。ただし、接続数が多すぎて、 活動中のマシンが処理する着信トラフィック負荷が引き続き相当量になる場合は、 タイマーが切れるまでに同期が完了しないことがあります。その結果、 Load Balancer は常に再同期を行おうとし、2 つのマシンは決して 同期しません。このような状態になった場合は、hasynctimeout を デフォルトより大きな値に設定して、2 つのマシンに、既存の接続に関する情報を交換するための 十分な時間を与えてください。このタイマーを設定するには、hasynctimeout コマンドを、 dscontrol executor start コマンドの後、 ハイ・アベイラビリティー・コマンド (dscontrol highavailability ) の前に発行する必要があります。
例
dscontrol executor status Executor Status: ---------------- Nonforwarding address ............... 9.67.131.151 Client gateway address .............. 0.0.0.0 Fin timeout ......................... 60 Wide area network port number ....... 0 Shared bandwidth (Kbytes) ........... 0 Default maximum ports per cluster ... 8 Maximum number of clusters .......... 100 Default maximum servers per port .... 32 Default stale timeout ............... 300 Default sticky time ................. 0 Default weight bound ................ 20 Default port type ................... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--file--+-delete--file[.ext]----------+------------>< +-appendload--file[.ext]------+ +-report----------------------+ +-save--file[.ext]--+-------+-+ | '-force-' | '-newload--file[.ext]---------'
ファイル拡張子 (.ext) は、任意のものを使用することも省略することもできます。
例
dscontrol file delete file3 File (file3) was deleted.
dscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
dscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 The configuration was saved into file (file3).
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
例
dscontrol helpこのコマンドによって、以下のような出力が生成されます。
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster help - print complete help text advisor - help on advisor command cluster - help on cluster command executor - help on executor command file - help on file command host - help on host command binlog - help on binary log command manager - help on manager command metric - help on metric command port - help on port command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on server log status subagent - help on subagent command highavailability - help on high availability command<> 内のパラメーターは変数であることに注意してください。
fintimeout <cluster address>|all <time> -Change FIN timeout (Use 'all' to change all clusters)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--address--mask------------+ | '-delete-' | +-heartbeat--+-add--srcaddress--dstaddress-+--+ | '-delete--address-------------' | '-takeover--+---------+-----------------------' '-address-'
さらに、status キーワードは、さまざまな副状態に関する 情報を戻します。
相互 HA 構成 (各 Dispatcher マシンのロールは both です)。
注:
例
dscontrol highavailability status
出力は以下のとおりです。
High Availability Status: ------------------------- Role ........................primary Recovery Strategy ........... manual State ....................... Active Sub-state.............. Synchronized Primary host........... 9.67.131.151 Port .........................12345 Preferred Target....... 9.67.134.223 Heartbeat Status: ----------------- Count ......................... 1 Source/destination ............ 9.67.131.151/9.67.134.223 Reachability Status: -------------------- Count ................ 1 Address .............. 9.67.131.1 reachable
dscontrol highavailability backup add primary auto 80
dscontrol highavailability reach add 9.67.125.18
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3
dscontrol highavailability takeover
>>-dscontrol--host:--remote_host-------------------------------><
dscontrol host:remote_host
コマンド・プロンプトでこのコマンドを発行した後、リモート Load Balancer マシンへ発行する有効な dscontrol コマンドのいずれかを入力します。
>>-dscontrol--logstatus----------------------------------------><
例
logstatus を表示するには、以下を入力します。
dscontrol logstatus
このコマンドによって、以下のような出力が生成されます。
Dispatcher Log Status: ------------------------------ Log filename ............... C:¥PROGRA~1¥IBM¥edge¥lb¥servers¥logs¥dispatcher ¥server.log Log level .................. 1 Maximum log size (bytes) ... 1048576
>>-dscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-quiesce--server--+-----+---------------+ | '-now-' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-refresh--refresh cycle-----------------+ +-report--+----------------+-------------+ | '-cluster+c2+...-' | +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+-----------------------+-------+ | '-log file--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--server----------------------+ '-version--------------------------------'
あるいは、サーバー区分化を使用している場合には、論理サーバーの固有名を使用してください。詳細については、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。
デフォルト・ファイルは、logs ディレクトリーにインストールされます。 付録 C、サンプル構成ファイルを参照してください。ログ・ファイルを保存するディレクトリーを 変更するには、ログ・ファイル・パスの変更を参照してください。
例
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportこのコマンドによって、以下のような出力が生成されます。
-------------------------------------------------------------------- | SERVER | IP ADDRESS | STATUS | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIVE | | mach15.dmz.com | 10.6.21.15 | ACTIVE | -------------------------------------------------------------------- ----------------------------- | MANAGER REPORT LEGEND | ----------------------------- | ACTV | Active Connections | | NEWC | New Connections | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | | CONN | Connections | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 21 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 80 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Restarting the manager to update codeこのコマンドによって、以下のような出力が生成されます。
320-14:04:54 Restarting the manager to update code
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusこのコマンドによって、以下の例のような出力が生成されます。
Manager status: =============== Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 0.05 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7 Metric monitor log file name.................. MetricMonitor.log Metric monitor log level...................... 1 Maximum metric monitor log size............... 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--cluster+c2+...+cN:metric+metric1+...+metricN--------------+->< +-remove--cluster+c2+...+cN:metric+metric1+...+metricN-----------+ +-proportions--cluster+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:metric+metric1+...+metricN-----------'
例
dscontrol metric add site1:metric1
dscontrol metric proportions site1 0 100
dscontrol metric status site1:metric1このコマンドにより、以下のような出力が生成されます。
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 50 Server .................... plm3 Metric data ............... -1
>>-dscontrol--port--+-add--cluster:port--+----------------------+-+->< | +-crossport--otherport-+ | | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-method--type---------+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-protocol--type-------+ | | '-reset--value---------' | +-set--cluster:port--+-crossport--otherport-+-+ | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-maxhalfopen--value---+ | | '-reset--value---------' | +-remove--cluster:port------------------------+ +-report--cluster:port------------------------+ +-status--cluster:port------------------------+ '-halfopenaddressreport--cluster:port---------'
crossport 機能を除去するには、crossport 値をその固有のポート番号に設定し直します。ポート間類縁性機能について詳しくは、ポート間類縁性を参照してください。
Dispatcher コンポーネントの場合:
CBR コンポーネントの場合: ポート・スティッキー時間を非ゼロ値に設定した場合は、そのルールに対する類縁性タイプは none (デフォルト) でなければなりません。 スティッキー時間がそのポートに対して設定されていると、ルール・ベース類縁性 (受動 Cookie、URI、活動 Cookie) は共存できません。
注:
正の値は、現在のハーフ・オープン接続がしきい値を超えるかどうかの検査が行われることを示します。現在値がしきい値を超えている場合は、アラート・スクリプトへの呼び出しが行われます。詳しくは、サービス妨害アタックの検出を参照してください。
例
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80このコマンドによって、以下のような出力が生成されます。
Port Status: ------------ Port number .................... 80 Cluster ........................ 9.67.131.153 Stale timeout .................. 300 Weight bound ................... 20 Maximum number of servers ...... 32 Sticky time .................... 0 Port type ...................... tcp/udp Cross Port Affinity ............ 80 Sticky mask bits ............... 32 Max Half Open Connections ...... 0 Send TCP Resets ................ no
dscontrol port report 9.62.130.157:80このコマンドによって、以下のような出力が生成されます。
Port Report: ------------ Cluster address ................ 9.62.130.157 Port number .................... 80 Number of servers .............. 5 Maximum server weight .......... 10 Total active connections ....... 55 Connections per second ......... 12 KBytes per second .............. 298 Number half open ............... 0 TCP Resets sent ................ 0 Forwarding method .............. MAC Based Forwarding
dscontrol port halfopenaddressreport 9.67.127.121:80このコマンドによって、以下のような出力が生成されます。
Half open connection report successfully created: ------------ Half Open Address Report for cluster:port = 9.67.127.121:80 Total addresses with half open connections reported ... 0 Total number of half open connections reported ........ 0 Largest number of half open connections reported ...... 0 Average number of half open connections reported ...... 0 Average half open connection time (seconds) reported .. 0 Total half open connections received .................. 0
>>-dscontrol--rule--+-add--cluster:port:rule--type--type--| opts |-+->< +-dropserver--cluster:port:rule--server--------+ +-remove--cluster:port:rule--------------------+ +-report--cluster:port:rule--------------------+ +-set--cluster:port:rule--| opts |-------------+ +-status--cluster:port:rule--------------------+ '-useserver--cluster:port:rule--server+s2+...--' opts: |--+---------------------------------+--------------------------| +-beginrange--low--endrange--high-+ +-priority--level-----------------+ +-pattern--pattern----------------+ +-tos--value----------------------+ +-stickytime--time----------------+ +-affinity--affinity_type---------+ +-cookiename--value---------------+ +-evaluate--level-----------------+ '-sharelevel--level---------------'
詳しくは、アクティブ Cookie 類縁性を参照してください。
「activecookie」の類縁性タイプにより、Load Balancer によって生成される Cookie に基づいて、 類縁性をもつ Web トラフィックを同じサーバーに対してロード・バランシングすることができます。
「passivecookie」の類縁性タイプにより、サーバーによって生成される自己識別 cookie に基づいて、 類縁性をもつ Web トラフィックを同じサーバーとロード・バランシングすることができます。cookiename パラメーターに受動 cookie 類縁性を指定して使用する必要があります。
類縁性タイプ "URI" によって、キャッシュのサイズを効果的に増やす方法で、Web トラフィックを caching proxy サーバーにロード・バランシングすることができます。
詳しくは、アクティブ Cookie 類縁性、受動 Cookie 類縁性、および URI 類縁性を参照してください。
詳しくは、受動 Cookie 類縁性を参照してください。
connection タイプ・ルールに対しては、evaluate オプション -- upserversonrule を指定することもできます。upserversonrule を指定することで、サーバー・セット内のサーバーの一部がダウンした場合でも、ルール内の残りのサーバーが 過負荷にならないようにすることができます。
あるいは、サーバー区分化を使用している場合には、論理サーバーの固有名を使用してください。詳細については、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。
例
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--cluster:port:server--+-------------------------+-+->< | +-address--address--------+ | | +-collocated--value-------+ | | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-mapport--portvalue------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-returnaddress--addr-----+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-set--cluster:port:server--+-collocated--value-------+-+ | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-down--cluster:port:server-----------------------------+ +-remove--cluster:port:server---------------------------+ +-report--cluster:port:server---------------------------+ +-up--cluster:port:server-------------------------------+ '-status--cluster:port:server---------------------------'
あるいは、IP アドレスに対して解決されない固有名を使用する場合は、 dscontrol server add コマンドに、サーバーの address パラメーターを提供しなければなりません。詳細については、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。
サーバー・ダウン・コマンドを使用して サーバーをオフラインにする場合、そのサーバーのスティッキー時間値が非ゼロであれば、既存のクライアントは、 スティッキー時間の有効期限が切れるまで、そのサーバーのサービスを引き続き受けることになります。サーバーが 終了するのは、スティッキー時間値の有効期限が切れてからです。
例
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154このコマンドによって、以下のような出力が生成されます。
Server Status: -------------- Server ......................... 9.67.143.154 Port number .................... 80 Cluster ........................ 9.67.131.167 Cluster address ................ 9.67.131.167 Quiesced ....................... N Server up ...................... Y Weight ......................... 10 Fixed weight ................... N Sticky for rule ................ Y Remote server .................. N Network Router address ......... 0.0.0.0 Collocated ..................... N Advisor request................. HEAD / HTTP/1.0 Advisor response................ Cookie value ................... n/a Clone ID ....................... n/a
>>-dscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-dscontrol--status-------------------------------------------><
例
dscontrol statusこのコマンドによって、以下のような出力が生成されます。
Executor has been started. Manager has been started. ---------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--level--------------------+->< +-logsize--+-bytes-----+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-community_name--logfile-' | +-status-----------------------------+ +-stop-------------------------------+ '-version----------------------------'
Windows プラットフォームの場合: オペレーティング・システムのコミュニティー名が使用されます。
例
dscontrol subagent start bigguy bigguy.log
この章では、以下の Site Selector sscontrol コマンドの使用方法について説明します。
sscontrol コマンド・パラメーターは、最小限バージョンで入力することができます。 入力する必要があるのは、パラメーターの固有文字だけです。例えば、file save コマンドに関するヘルプを表示するには、sscontrol help file の代わりに sscontrol he f と入力することができます。
>>-sscontrol--advisor--+-connecttimeout--name--+-port----------+--seconds-------+->< | '-sitename:port-' | +-interval--name--+-port----------+--seconds-------------+ | '-sitename:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port----------+--level---------------+ | '-sitename:port-' | +-logsize--name--+-port----------+--+-size | unlimited-+-+ | '-sitename:port-' '-bytes------------' | +-receivetimeout--name--+-port----------+--seconds-------+ | '-sitename:port-' | +-report--name--+-port----------+------------------------+ | '-sitename:port-' | +-retries--name--+-port----------+--numretries-----------+ | '-sitename:port-' | +-start--name--+-port----------+--+----------+-----------+ | '-sitename:port-' '-log file-' | +-status--name--+-port----------+------------------------+ | '-sitename:port-' | +-stop--name--+-port----------+--------------------------+ | '-sitename:port-' | +-timeout--name--+-port----------+-----------------------+ | '-sitename:port-' | '-version--name--+-port----------+--seconds--------------' '-sitename:port-'
.
advisor 名 | プロトコル | ポート |
---|---|---|
Connect | なし | ユーザー定義 |
db2 | プライベート | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | N/A |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
デフォルトのファイルは、advisorname_port.log (http_80.log など) です。ログ・ファイルを保管するディレクトリーを変更するには、ログ・ファイル・パスの変更を参照してください。
各 sitename ごとに 1 つの advisor だけを始動できます。
例
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listこのコマンドによって、以下のような出力が生成されます。
--------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http mysite:80 0
sscontrol advisor logsize ftp mysite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21このコマンドによって、以下のような出力が生成されます。
Advisor Report: --------------- Advisor name ............. http Port number .............. 80 sitename ................. mySite Server address ........... 9.67.129.230 Load ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80このコマンドにより、以下のような出力が生成されます。
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--filename.ext----------+---------->< +-appendload--filename.ext------+ +-report------------------------+ +-save--filename.ext--+-------+-+ | '-force-' | '-newload--filename.ext---------'
ファイル拡張子 (.ext) は任意指定で、指定する場合は任意のものを指定できます。
例
sscontrol file delete file3 File (file3) was deleted.
sscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
sscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 The configuration was saved into file (file3).
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
例
sscontrol helpこのコマンドによって、以下のような出力が生成されます。
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help name help - print complete help text advisor - help on advisor command file - help on file command host - help on host command manager - help on manager command metric - help on metric command sitename - help on sitename command nameserver - help on nameserver command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on logstatus command< > 内のパラメーターは変数です。
logsize <number of bytes | unlimited> -Set the maximum number of bytes to be logged in the log file
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-report--sitename+sn2+...+snN-----------+ +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+----------------------+--------+ | '-logfile--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
デフォルト・ファイルは、logs ディレクトリーにインストールされます。 付録 C、サンプル構成ファイルを参照してください。 ログ・ファイルを保存するディレクトリーを変更するには、ログ・ファイル・パスの変更を参照してください。
例
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportこのコマンドによって、以下のような出力が生成されます。
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- -------------------------- | MANAGER REPORT LEGEND | -------------------------- | CPU | CPU Load | | MEM | Memory Load | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | -------------------------- ------------------------------------------------------------------------ | mySite | WEIGHT | CPU 49% | MEM 50% | PORT 1% | SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT LOAD | WT LOAD | WT LOAD | WT LOAD | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALS:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Restarting the manager to update codeこのコマンドによって、以下のような出力が生成されます。
320-14:04:54 Restarting the manager to update code
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusこのコマンドによって、以下の例のような出力が生成されます。
Manager status: ============= Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 5 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--sitename+sn2+...+snN:metric+metric1+...+metricN--------------+->< +-remove--sitename+sn2+...+snN:metric+metric1+...+metricN-----------+ +-proportions--sitename+sn2+...+snN:proportion1 prop2 prop3...propN-+ '-status--sitename+sn2+...+snN metric+metric1+...+metricN-----------'
例
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status site1:metric1このコマンドにより、以下のような出力が生成されます。
Metric Status: ------------ sitename ..................... site1 Metric name ................... metric1 Metric proportion ............. 50 Server ......... 9.37.56.100 Metric data .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--address-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--sitename+sn2+...+snN:rule+r2+...+rN--type--value--| value |--| opts |-+->< +-dropserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN---------+ +-remove--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ +-set--sitename+sn2+...+snN:rule+r2+...+rN--| value |--| opts |--------------+ +-status--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ '-useserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN----------' opts: |--+---------------------------------+--------------------------| +-beginrange--low--endrange--high-+ +-priority--value-----------------+ '-metricname--value---------------'
例
sscontrol rule add sitename:rulename type true priority 100
sscontrol rule add sitename:rulename type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add sitename:rulename type time beginrange 11 endrange 14 sscontrol rule useserver sitename:rulename server05
>>-sscontrol--server--+-add--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+->< | +-metricaddress--address-+ | | '-weight--value----------' | +-down--sitename+sn2+...+snN:server+s2+...+sN----------------------------+ +-remove--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ +-set--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+ | +-metricaddress--address-+ | | '-weight--value----------' | +-status--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ '-up--sitename+sn2+...+snN:server+s2+...+sN------------------------------'
例
sscontrol server add site1:27.65.89.42
sscontrol server down site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up site1:27.65.89.42
>>-sscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-sscontrol--sitename--+-add--sitename+sn2+...+snN--+----------------------------------------+-+->< | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | +-remove--sitename+sn2+...+snN------------------------------------------+ +-set--sitename+sn2+...+snN--+----------------------------------------+-+ | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | '-status--sitename+sn2+...+snN------------------------------------------'
例
sscontrol sitename add 130.40.52.153
sscontrol sitename set mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteこのコマンドによって、以下のような出力が生成されます。
SiteName Status: --------------- SiteName ........................... mySite WeightBound ........................ 20 TTL ................................ 5 StickyTime ......................... 0 Number of Servers .................. 1 Proportion given to CpuLoad ........ 49 Proportion given to MemLoad ........ 50 Proportion given to Port ........... 1 Proportion given to System metric .. 0 Advisor running on port ............ 80 Using Proximity .................... N
>>-sscontrol--status-------------------------------------------><
例
sscontrol statusこのコマンドによって、以下のような出力が生成されます。
NameServer has been started. Manager has been started. ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
本章では、Cisco CSS Controller の以下の ccocontrol コマンドの使用法について説明します。
パラメーターの固有の文字を入力して、ccocontrol コマンド・パラメーターの省略バージョンを使用できます。 例えば、file save コマンドに関するヘルプを表示するには、ccocontrol help file の代わりに ccocontrol he f を入力することができます。
ccocontrol コマンド・プロンプトを取得するには、ccocontrol と入力します。
コマンド行インターフェースを終了するには、exit または quit と入力します。
>>-ccocontrol--consultant--+-add--scID--address--swIPAddr--community--commName-+->< +-binarylog--scID+scID2...--+-report-------------+--+ | +-set--+-interval--+-+ | | | '-retention-' | | | +-start--------------+ | | '-stop---------------' | +-remove--scID+scID2...-----------------------------+ +-report--scID+scID2...-----------------------------+ +-set--+-loglevel--level----------------+-----------+ | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...------------------------------+ '-stop--scID+scID2...-------------------------------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
ccocontrol consultant add sc1 address 9.37.50.17 community comm2
ccocontrol consultant binarylog sc1 start
ccocontrol consultant report sc1
このコマンドによって、以下のような出力が生成されます。
Consultant sc1 connected to switch at 9.37.50.1:cn1 Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 Log size = 1,048,576 ownerContent(s): ownerContent oc1
ccocontrol consultant set sc1 sleeptime 10
ccocontrol consultant start sc1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
ccocontrol controller report
このコマンドによって、以下のような出力が生成されます。
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--filename----------+------------->< +-load--filename------------+ +-report--------------------+ '-save--filename--+-------+-' '-force-'
インストール (デフォルト) ディレクトリー: C:\Program Files\ibm\edge\lb\servers\configurations\cco
例
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
このコマンドによって、以下のような出力が生成されます。
FILE REPORT: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
例
ccocontrol help
このコマンドによって、以下のような出力が生成されます。
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors ownerContent - operate on ownerContents service - operate on services
>>-ccocontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
このコマンドによって、以下のような出力が生成されます。
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner --------------------------------------- No reach targets configured
>>-ccocontrol--metriccollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-timeoutconnect--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-timeoutreceive--sec----+ '-sleeptime--sec---------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
ccocontrol metriccollector report sc1:http
このコマンドによって、以下のような出力が生成されます。
MetricCollector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
ccocontrol metriccollector set sc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--scID:ocN--ownername--oN--contentrule--cN------------------------------+->< +-metrics--scID+scID2...:ocN+ocN2...--mN--importance--mN2--i2----------------+ +-refresh--scID+scID2...:ocN+ocN2...-----------------------------------------+ +-remove--scID+scID2...:ocN+ocN2...------------------------------------------+ +-report--scID+scID2...:ocN+ocN2...------------------------------------------+ '-set--scID+scID2...:ocN+ocN2...----metric--mN--+------------------------+---' +-requeststring--string--+ +-responsestring--string-+ '-retry--numretries------'
有効なメトリック名とそれに関連したポートのリストを以下に示します。
advisor 名 | プロトコル | ポート |
---|---|---|
connect | ICMP | 12345 |
db2 | プライベート | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (Caching Proxy 経由) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | プライベート | 10,007 |
activeconn | なし | なし |
connrate | なし | なし |
cpuload | なし | なし |
memload | なし | なし |
例
ccocontrol ownerContent add sc1:oc1 ownername owner1 contentrule content1
ccocontrol ownerContent metrics sc1:oc1 activeconn 50 http 50
ccocontrol ownerContent report sc1:oc1
このコマンドによって、以下のような出力が生成されます。
ownerContent sc1:oc1 Weightbound = 10 Metric activeconn has proportion 25 ResponseString... n/a RequestString.... n/a Metric http has proportion 50 ResponseString... n/a RequestString.... n/a Metric connrate has proportion 25 ResponseString... n/a RequestString.... n/a Contains Service t3 Contains Service t2 Contains Service t1
ccocontrol ownerContent set sc1:oc1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--scID+scID2...:ocN+ocN2...:svc+svc2...---------------------------------+->< '---set--scID+scID2...:ocN+ocN2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-integer-+--+ | '-off-----' | +-requestsourceip--IPAd-----+ +-metricserveraddress--IPAd-+ '-metricserverport--portN---'
例
ccocontrol service report sc1:oc1:t1
このコマンドによって、以下のような出力が生成されます。
Service sc1:oc1:ta has weight 10 Fixed weight is off Request Source Ip..... 9.27.24.156 Application port...... 80 MetricServer address.. 1.0.0.1 MetricServer port..... 10004 Metric activeconn has value -99 Metric http has value -99 Metric connrate has value -99
ccocontrol service set sc1:oc1:t2 metricserveraddress 9.37.50.17
本章では、Nortel Alteon Controller の以下の nalcontrol コマンドの使用法について説明します。
パラメーターの固有の文字を入力して、nalcontrol コマンド・パラメーターの省略バージョンを使用できます。例えば、file save コマンドに関するヘルプを表示するには、nalcontrol help file の代わりに nalcontrol he f と入力することができます。
nalcontrol コマンド・プロンプトを取得するには、nalcontrol と入力します。
コマンド行インターフェースを終了するには、exit または quit と入力します。
>>-nalcontrol--consultant--+-add--scID--address--swIPAddr--+---------------------------+-+->< | +-rcommunity--readCommName--+ | | '-wcommunity--writeCommName-' | +-binarylog--scID+scID2...--+-report------------------------+-+ | +-set--+-interval--interval---+-+ | | | '-retention--retention-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--scID+scID2...---------------------------------------+ +-report--scID+scID2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--level----------------+ | | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...----------------------------------------+ '-stop--scID+scID2...-----------------------------------------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
nalcontrol consultant add sc1 address 9.37.50.17
nalcontrol consultant binarylog sc1 start
nalcontrol consultant report sc1
このコマンドによって、以下のような出力が生成されます。
Consultant ID: sc1 Switch IP addr: 9.37.50.1 Read Community: public Write Community: private Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 log size = 1,048,576 Service(s): Service svc1
nalcontrol consultant set sc1 sleeptime 10
nalcontrol consultant start sc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
nalcontrol controller report
このコマンドによって、以下のような出力が生成されます。
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--filename-+---------------------->< +-load--filename---+ +-report-----------+ '-save--filename---'
共通インストール・ディレクトリー・パス -- C:\Program Files\ibm\edge\lb\servers\configurations\nal
ネイティブのインストール・ディレクトリー・パス -- C:\Program Files\ibm\lb\servers\configurations\nal
例
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
このコマンドによって、以下のような出力が生成されます。
FILE R EPORT: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
例
nalcontrol help
このコマンドによって、以下のような出力が生成されます。
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors server - operate on servers service - operate on services
>>-nalcontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
このコマンドによって、以下のような出力が生成されます。
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 Started. . . . . . . . . . N State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner ---------------------------------------
>>-nalcontrol--metricollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-connecttimeout--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-receivetimeout--sec----+ '-sleeptime--sec---------'
0 = なし
1 = 最小
2 = 基本
3 = 普通
4 = 拡張
5 = 詳細
例
nalcontrol metrinalllector report sc1:http
このコマンドによって、以下のような出力が生成されます。
Metrinalllector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
nalcontrol metrinalllector set sc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--scID+scID2...:svcID+svcID2...:serverID+svrID2...-----------------------------------+->< '---set--scID+scID2...:svcID+svcID2...:serverID+svrID2--+--------------------------------+---' +-fixedweight--+-integer-+-------+ | '-off-----' | +-requestsourceip--IPAddress-----+ +-metricserveraddress--IPAddress-+ '-metricserverport--portNumber---'
例
nalcontrol server report sc1:svc1:1
このコマンドによって、以下のような出力が生成されます。
Server sc1:svc1:1 has weight -99 Fixed weight is off Request Source Ip...... 9.27.24.156 Application port....... 99 MetricServer address... 9.99.99.98 MetricServer port...... 10004 Metric activeconn has value -99 Metric connrate has value -99
nalcontrol server set sc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--scID+scID2...:serviceID+svcID2...--vsid--virSvrID--vport--virPortNum------+->< +-metrics--scID+scID2...:svcID+svcID2...--mN--importance--mCN2--i2---------------+ +-refresh--scID+scID2...:svcID+svcID2...-----------------------------------------+ +-remove--scID+scID2...:svcID+svcID2...------------------------------------------+ +-report--scID+scID2...:svcID+svcID2...------------------------------------------+ '-set--scID+scID2...:svcID+svcID2...----metric--mN----+-requeststring--string--+-' +-responsestring--string-+ '-retry--numretries------'
有効なメトリック名とそれに関連したポートのリストを以下に示します。
advisor 名 | プロトコル | ポート |
---|---|---|
connect | ICMP | 12345 |
db2 | プライベート | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (Caching Proxy 経由) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | プライベート | 10,007 |
activeconn | なし | なし |
connrate | なし | なし |
cpuload | なし | なし |
memload | なし | なし |
例
nalcontrol service add sc1:svc1 vsid 1 vport 80
nalcontrol service metrics sc1:svc1 activeconn 50 http 50
nalcontrol service report sc1:svc1
このコマンドは x のような出力を生成します。
Service sc1:svc1 Weightbound = 48 Metric activeconn has proportion 50 Metric connrate has rpoportion 50 Contains Server 4 Contains Server 3 Contains Server 2 Contains Server 1
nalcontrol service set sc1:svc1 metric http requeststring getLastErrorCode
Load Balancer グラフィカル・ユーザー・インターフェース (GUI) では、パネルの左側に、最上位の Load Balancer のツリー構造が表示され、Dispatcher、Content Based Routing (CBR)、Site Selector、Cisco CSS Controller、Nortel Alteon Controller がコンポーネントとして表示されます。
図 41. Dispatcher コンポーネントの GUI ツリー構造展開を表示するグラフィカル・ユーザー・インターフェース (GUI)
図 42. CBR コンポーネントの GUI ツリー構造展開を表示するグラフィカル・ユーザー・インターフェース (GUI)
図 43. Site Selector コンポーネントの GUI ツリー構造展開を表示するグラフィカル・ユーザー・インターフェース (GUI)
図 44. Cisco CSS Controller コンポーネントの GUI ツリー構造展開を表示するグラフィカル・ユーザー・インターフェース (GUI)
図 45. Nortel Alteon Controller コンポーネントの GUI ツリー構造展開を表示するグラフィカル・ユーザー・インターフェース (GUI)
コンポーネントは、すべて GUI から構成することができます。ツリー構造にあるエレメントを選択するにはマウス・ボタン 1 (通常は左ボタン) でクリックし、ポップアップ・メニューを表示させるにはマウス・ボタン 2 (通常は右ボタン) でクリックします。また、ツリー・エレメントのポップアップ・メニューには、パネル上部のメニュー・バーからアクセスすることもできます。
正符号 (+) または負符号 (-) をクリックすると、ツリー構造の項目が展開または縮小されます。
GUI からコマンドを実行するには、GUI ツリーで「ホスト」ノードを強調表示し、「ホスト」ポップアップ・メニューから「コマンドの送信....」を選択します。 コマンド入力フィールドに、実行したいコマンド (例えば executor report) を入力します。 現行セッションでのコマンド実行の結果およびヒストリーが、ウィンドウに表示されます。
パネルの右側に、現在選択されているエレメントについての状況標識のタブが 2 つ表示されます。
「ヘルプ」にアクセスするには、Load Balancer ウィンドウの右上隅にある疑問符 (?) をクリックします。
この付録では、CBR コンポーネント用コンテンツ・ルール (パターン) 構文および Dispatcher コンポーネントの CBR 転送方式の使用方法を、その使用のシナリオおよび例とともに説明します。
適用できるのは、ルール・タイプに "content" を選択した場合だけです。
使用したいパターン構文は、以下の制限を使用して入力します。
予約済みのキーワードの後ろには、必ず等号 (=) を付けます。
結果的に、ブラウザー・ターゲットの指定 http://www.company.com/path/webpage.htm は次のような値になる可能性があります:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
例えば、次のコマンドが有効であるのは、cbrcontrol>> プロンプトを使用するときか、構成ファイルから使用するときだけです。
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
特殊文字を使用するときは、これと同じコマンドがオペレーティング・システムのプロンプトで機能するためには、以下のように、コマンド全体を二重引用符で囲む必要があります。
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
引用符を使用しないと、ルールを CBR に保管するときにパターンの一部が切り捨てされる場合があります。
以下は、パターン構文を使用する場合の使用可能なシナリオおよび例の集合です。
シナリオ 1:
1 つのクラスター名のセットアップには、標準 HTML コンテンツ用の Web サーバーの 1 セット、サーブレット要求用の WebSphere Application Server のある Web サーバーの別のセット、NSF ファイル用の Lotus(R) Notes(R) サーバーの別のセットなどが必要となります。 要求されたこれらのページを区別するためには、クライアント・データへのアクセスが必要です。また、それらを該当するサーバーに送ることも必要です。 コンテンツ・パターン・マッチング・ルールは、これらのタスクを実行するために必要な分離を提供します。要求に必要な分離が自動的に行なわれるように、一連のルールが構成されます。例えば、次のコマンドは言及された 3 つの分割を実行します:
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
NSF ファイルに対する要求が Load Balancer に到着すると、最初にサーブレット・ルールが検査されますが、一致しません。 そうすると、この要求は Notes ルールで検査され、一致を戻します。クライアントは、server3 と server4 の間でロード・バランシングされます。
シナリオ 2
別の共通シナリオは、メイン Web サイトがいくつかの異なる内部グループを制御する場合です。例えば、 www.company.com/software には、異なるサーバーのセットおよび www.company.com/hardware 部門からのコンテンツが含まれています。要求はすべてルート www.company.com クラスターには基づいていないので、コンテンツ・ルールは URI の違いを検出してロード・バランシングを完了する必要があります。シナリオのルールは以下のようになります:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
シナリオ 3
一定の組み合わせは、ルールが検索される順序に依存します。例えば、シナリオ 2 では、クライアントはそれらの要求パスの中のディレクトリーに基づいて分割されますが、ターゲット・ディレクトリーはパスの複数のレベルで現れることがあり、配置上の別の物を意味することがあります。例えば、www.company.com/pcs/fixes/software は、www.company.com/mainframe/fixes/software とは違うターゲットです。ルールは、この可能性を考慮して定義しなければならず、同時に多くのシナリオをキャッチしないようにしなければなりません。 例えば、"uri=*/software/*" テストは、この場合のワイルドカード検索には範囲が広すぎます。 代わりのルールを次の方法で組み立ててください。
組み合わせ検索を以下の範囲に絞ることができます。
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
使用する組み合わせがない場合には、順序が重要となります。
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
"pcs" が後のディレクトリー・スポット (最初ではなく) に現れると、2 番目のルールがキャッチされます。
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
ほとんどすべての場合に、他のルールを失敗させるものをすべてキャッチするために、デフォルトのルール 常に真 を使用してルールを完了する必要があります。このクライアントの他のすべてのサーバーが失敗するシナリオの場合は、これは、「このサイトは現在ダウンしています。後からやり直してください。」というサーバーとなることがあります。
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
この付録には、Load Balancer の Dispatcher コンポーネントに関するサンプル構成ファイルを記載しています。
サンプル・ファイルは ...ibm/edge/lb/servers/samples/ ディレクトリーに入っています。
#!/bin/bash
#
# configuration.sample - Sample configuration file for the
Dispatcher component
#
#
# Ensure the root user is the one executing this script.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "You must login as root to run this script"
# exit 2
# fi
#
# First start the server
#
# dsserver start
# sleep 5
#
# Then start the executor
#
# dscontrol executor start
#
# The Dispatcher can be removed at any time using the
# "dscontrol executor stop" and "dsserver stop" commands to
# stop the executor and server respectively prior to removing
# the Dispatcher software.
#
# The next step in configuring the Dispatcher is to set the
# NFA (non-forwarding address) and the cluster address(es).
#
# The NFA is used to remotely access the Dispatcher machine
# for administration or configuration purposes. This
# address is required since the Dispatcher will forward packets
# to the cluster address(es).
#
# The CLUSTER address is the hostname (or IP address) to
# which remote clients will connect.
#
# Anywhere in this file, you may use hostnames and IP
# addresses interchangeably.
#
# NFA=hostname.domain.name
# CLUSTER=www.yourcompany.com
# echo "Loading the non-forwarding address"
# dscontrol executor set nfa $NFA
#
# The next step in configuring the Dispatcher is to create
# a cluster. The Dispatcher will route requests sent to
# the cluster address to the corresponding server machines
# defined to that cluster. You may configure and server
# multiple cluster address using Dispatcher.
# Use a similar configuration for CLUSTER2, CLUSTER3, etc.
#
# echo "Loading first CLUSTER address "
# dscontrol cluster add $CLUSTER
#
# Now we must define the ports this cluster will use. Any
# requests received by the Dispatcher on a defined port will
# be forwared to the corresponding port of one of the server
# machines.
#
# echo "Creating ports for CLUSTER: $CLUSTER"
# dscontrol port add $CLUSTER:20+21+80
#
# The last step is to add each of the server machines to the
# ports in this cluster.
# Again, you can use either the hostname or the IP address
# of the server machines.
#
# SERVER1=server1name.domain.name
# SERVER2=server2name.domain.name
# SERVER3=server3name.domain.name
# echo "Adding server machines"
# dscontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# We will now start the load balancing components of the
# Dispatcher. The main load balancing component is called
# the manager and the second load balancing components are the
# advisors. If the manager and advisors are not running the
# Dispatcher sends requests in a round-robin format. Once the
# manager is started, weighting decisions based on the number
# of new and active connections is employed and incoming
# requests are sent to the best server. The advisors give the
# manager further insight into a servers ability to service
# requests as well as detecting whether a server is up. If
# an advisor detects that a server is down it will be
# marked down (providing the manager proportions have been
# set to include advisor input) and no further requests will be
# routed to the server.
# The last step in setting up the load balancing components
# is to set the manager proportions. The manager updates the
# weight of each of the servers based on four policies:
# 1. The number of active connections on each server.
# 2. The number of new connections to each server.
# 3. Input from the advisors.
# 4. Input from the system level advisor.
# These proportions must add up to 100. As an example, setting
# the manager proportions to
# dscontrol manager proportions 48 48 0 0
# will give active and new connections 48% input into the
# weighting decision, the advisors will contribute 4% and
# the system input will not be considered.
#
# NOTE: By default the manager proportions are set to 50 50 0 0
#
# echo "Starting the manager..."
# dscontrol manager start
# echo "Starting the FTP advisor on port 21 ..."
# dscontrol advisor start ftp 21
# echo "Starting the HTTP advisor on port 80 ..."
# dscontrol advisor start http 80
# echo "Starting the Telnet advisor on port 23 ..."
# dscontrol advisor start telnet 23
# echo "Starting the SMTP advisor on port 25 ..."
# dscontrol advisor start smtp 25
# echo "Starting the POP3 advisor on port 110 ..."
# dscontrol advisor start pop3 110
# echo "Starting the NNTP advisor on port 119 ..."
# dscontrol advisor start nntp 119
# echo "Starting the SSL advisor on port 443 ..."
# dscontrol advisor start ssl 443
#
# echo "Setting the manager proportions..."
# dscontrol manager proportions 58 40 2 0
#
# The final step in setting up the Dispatcher machine is to
# alias the Network Interface Card (NIC).
#
# NOTE: Do NOT use this command in a high availability
# environment. The go* scripts will configure the NIC and
# loopback as necessary.
# dscontrol executor configure $CLUSTER
# If your cluster address is on a different NIC or subnet
from the NFA use the following format for the cluster configure
command.
# dscontrol executor configure $CLUSTER tr0 0xfffff800
# where tr0 is your NIC (tr1 for the second token ring card, en0
# for the first ethernet card) and 0xfffff800 is a valid
# subnet mask for your site.
#
#
# The following commands are set to the default values.
# Use these commands as a guide to change from the defaults.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
以下は、Load Balancer の configuration.cmd.sample というサンプル構成ファイルであり、Windows で使用するものです。
@echo off rem configuration.cmd.sample - Sample configuration file for the rem Dispatcher component. rem rem dsserver must be started by Services rem rem rem Then start the executor rem rem call dscontrol executor start rem rem The next step in configuring the Dispatcher is to set the rem NFA (non-forwarding address) and to set the cluster rem address(es). rem rem The NFA is used to remotely access the Dispatcher rem machine for administration configuration purposes. This rem address is required since the Dispatcher will forward rem packets to the cluster address(es). rem rem The CLUSTER address is the hostname (or IP address) to which rem remote clients will connect. rem rem Anywhere in this file, you may use hostnames and IP rem addresses interchangeably. rem NFA=[non-forwarding address] rem CLUSTER=[your clustername] rem rem set NFA=hostname.domain.name rem set CLUSTER=www.yourcompany.com rem echo "Loading the non-forwarding address" rem call dscontrol executor set nfa %NFA% rem rem The following commands are set to the default values. rem Use these commands to change the defaults rem call dscontrol executor set fintimeout 30 rem rem The next step in configuring the Dispatcher is to create rem a cluster. The Dispatcher will route requests sent to rem the cluster address to the corresponding server machines rem defined to that cluster. You may configure and server rem multiple cluster addresses using Dispatcher. rem Use a similar configuration for CLUSTER2, CLUSTER3, etc. rem rem echo "Loading first CLUSTER address " rem call dscontrol cluster add %CLUSTER% rem rem Now we must define the ports this cluster will use. Any rem requests received by the Dispatcher on a defined port rem will be forwarded to the corresponding rem port of one of the server machines. rem rem echo "Creating ports for CLUSTER: %CLUSTER%" rem call dscontrol port add %CLUSTER%:20+21+80 rem rem The last step is to add each of the server machines to rem the ports in this cluster. Again, you can use either the rem hostname or the IP address of the server machines. rem rem set SERVER1=server1name.domain.name rem set SERVER2=server2name.domain.name rem set SERVER3=server3name.domain.name rem echo "Adding server machines" rem call dscontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem We will now start the load balancing components of the rem Dispatcher. The main load balancing component is called rem the manager and the second load balancing components are the rem advisors. If the manager and advisors are not rem running the Dispatcher sends requests in a round-robin rem format. Once the manager is started, weighting decisions rem based on the number of new and active connections is rem employed and incoming requests are sent to the best rem server. The advisors give the manager further insight rem into a servers ability to service requests as well as rem detecting whether a server is up. If an advisor detects rem that a server is down it will be marked down (providing the rem manager proportions have been set to include advisor rem input) and no further requests will be routed to the server. rem The last step in setting up the load balancing rem components is to set the manager proportions. The rem manager updates the weight of each of the servers based rem on four policies: rem 1. The number of active connections on each server rem 2. The number of new connections for each server rem 3. Input from the advisors. rem 4. Input from the system level advisor. rem rem These proportions must add up to 100. As an example, rem setting the cluster proportions using rem dscontrol cluster set <cluster> proportions 48 48 4 0 rem will give active and new connections 48% input into the rem weighting decision, the advisor will contribute 4% and rem the system input will not be considered. rem rem NOTE: By default the manager proportions are set to rem 50 50 0 0 rem echo "Starting the manager..." rem call dscontrol manager start rem echo "Starting the FTP advisor on port 21 ..." rem call dscontrol advisor start ftp 21 rem echo "Starting the HTTP advisor on port 80 ..." rem call dscontrol advisor start http 80 rem echo "Starting the Telnet advisor on port 23 ..." rem call dscontrol advisor start telnet 23 rem echo "Starting the SMTP advisor on port 25 ..." rem call dscontrol advisor start smtp 25 rem echo "Starting the POP3 advisor on port 110 ..." rem call dscontrol advisor start pop3 110 rem echo "Starting the NNTP advisor on port 119 ..." rem call dscontrol advisor start nntp 119 rem echo "Starting the SSL advisor on port 443 ..." rem call dscontrol advisor start ssl 443 rem rem echo "Setting the cluster proportions..." rem call dscontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem The final step in setting up the Dispatcher machine is rem to alias the Network Interface Card (NIC). rem rem NOTE: Do NOT use this command in a high availability rem environment. The go* scripts will configure the NIC and rem loopback as necessary. rem rem dscontrol executor configure %CLUSTER% rem If your cluster address is on a different NIC or subnet rem from the NFA use the following format for the cluster rem configure command. rem dscontrol executor configure %CLUSTER% tr0 0xfffff800 rem where tr0 is your NIC (tr1 for the second token ring card, rem en0 for the first ethernet card) and 0xfffff800 is rem a valid subnet mask for your site. rem rem rem The following commands are set to the default values. rem Use these commands to guide to change from the defaults. rem call dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
以下は、ADV_sample という サンプル advisor ファイルです。
/**
* ADV_sample: The Load Balancer HTTP advisor
*
*
* This class defines a sample custom advisor for Load Balancer. Like all
* advisors, this custom advisor extends the function of the advisor base,
* called ADV_Base. It is the advisor base that actually performs most of
* the advisor's functions, such as reporting loads back to the Load Balancer
* for use in the Load Balancer's weight algorithm. The advisor base also
* performs socket connect and close operations and provides send and receive
* methods for use by the advisor. The advisor itself is used only for
* sending and receiving data to and from the port on the server being
* advised. The TCP methods within the advisor base are timed to calculate
* the load. A flag within the constructor in the ADV_base overwrites the
* existing load with the new load returned from the advisor if desired.
*
* Note: Based on a value set in the constructor, the advisor base supplies
* the load to the weight algorithm at specified intervals. If the actual
* advisor has not completed so that it can return a valid load, the advisor
* base uses the previous load.
*
* NAMING
*
* The naming convention is as follows:
*
* - The file must be located in the following Load Balancer directory:
*
* lb/servers/lib/CustomAdvisors/ (lb¥servers¥lib¥CustomAdvisors on Windows)
*
* - The Advisor name must be preceded with "ADV_". The advisor can be
* started with only the name, however; for instance, the "ADV_sample"
* advisor can be started with "sample".
*
* - The advisor name must be in lowercase.
*
* With these rules in mind, therefore, this sample is referred to as:
*
* <base directory>/lib/CustomAdvisors/ADV_sample.class
*
*
* Advisors, as with the rest of Load Balancer, must be compiled with the
* prereq version of Java. To ensure access to Load Balancer classes, make
* sure that the ibmlb.jar file (located in the lib subdirectory of the base
* directory) is included in the system's CLASSPATH.
*
* Methods provided by ADV_Base:
*
* - ADV_Base (Constructor):
*
* - Parms
* - String sName = Name of the advisor
* - String sVersion = Version of the advisor
* - int iDefaultPort = Default port number to advise on
* - int iInterval = Interval on which to advise on the servers
* - String sDefaultName = Unused. Must be passed in as "".
* - boolean replace = True - replace the load value being calculated
* by the advisor base
* False - add to the load value being calculated
* by the advisor base
* - Return
* - Constructors do not have return values.
*
* Because the advisor base is thread based, it has several other methods
* available for use by an advisor. These methods can be referenced using
* the CALLER parameter passed in getLoad().
*
* These methods are as follows:
*
* - send - Send a packet of information on the established socket connection
* to the server on the specified port.
* - Parms
* - String sDataString - The data to be sent in the form of a string
* - Return
* - int RC - Whether the data was sucessfully sent or not: zero indicates
* data was sent; a negative integer indicates an error.
*
* - receive - Receive information from the socket connection.
* - Parms
* - StringBuffer sbDataBuffer - The data received during the receive call
* - Return
* - int RC - Whether the data was successfully received or not; zero
* indicates data was sent; a negative integer indicates
* an error.
*
* If the function provided by the advisor base is not sufficient,
* you can create the appropriate function within the advisor and
* the methods provided by the advisor base will then be ignored.
*
* An important question regarding the load returned is whether to apply
* it to the load being generated within the advisor base,
* or to replace it; there are valid instances of both situations.
*
* This sample is essentially the Load Balancer HTTP advisor. It functions
* very simply: a send request--an http head request--is issued. Once a
* response is received, the getLoad method terminates, flagging the advisor
* base to stop timing the request. The method is then complete. The
* information returned is not parsed; the load is based on the time
* required to perform the send and receive operations.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface
{
String COPYRIGHT =
"(C) Copyright IBM Corporation 1997, All Rights Reserved.¥n";
static final String ADV_NAME = "Sample";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Note: Most server protocols require a carriage return ("¥r") and line
// feed ("¥n") at the end of messages. If so, include them in
// your string here.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0¥r¥nAccept: */*¥r¥nUser-Agent: " +
"IBM_Load_Balancer_HTTP_Advisor¥r¥n¥r¥n";
/**
* Constructor.
*
* Parms: None; but the constructor for ADV_Base has several parameters
* that must be passed to it.
*
*/
public ADV_sample()
{
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // not used
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Any Advisor-specific initialization that must take place after the
* advisor base is started. This method is called only once and is
* typically not used.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* This method is called by the advisor base to complete the advisor's
* operation, based on details specific to the protocol. In this sample
* advisor, only a single send and receive are necessary; if more complex
* logic is necessary, multiple sends and receives can be issued. For
* example, a response might be received and parsed. Based on the
* information learned thereby, another send and receive could be issued.
*
* Parameters:
*
* - iConnectTime - The current load as it refers to the length of time it
* took to complete the connection to the server through
* the specified port.
*
* - caller - A reference to the advisor base class where the Load
* Balancer-supplied methods are to perform simple TCP requests,
* mainly send and receive.
*
* Results:
*
* - The load - A value, expressed in milliseconds, that can either be added
* to the existing load, or that can replace the existing load, as
* determined by the constructor's "replace" flag.
*
* The larger the load, the longer it took the server to respond;
* therefore, the lower the weight will become within the Load Balancer.
*
* If the value is negative, an error is assumed. An error from an
* advisor indicates that the server the advisor is trying to reach is not
* accessible and has been identified as being down. Load Balancer will
* not attempt to load balance to a server that is down. Load Balancer will
* resume load balancing to the server when a positive value is received.
*
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Send tcp request
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Perform a receive
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
/**
* In the normal advisor mode ("replace" flag is false), the load
* returned is either 0 or 1 indicating the server is up or down.
* If the receive is successful, a load of zero is returned
* indicating that the load built within the base advisor is to be used.
*
* Otherwise ("replace" flag is true), return the desired load value.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // End - ADV_sample
この付録では、Load Balancer の 2 つのコンポーネント (Dispatcher コンポーネントおよび CBR コンポーネント) の機能が Caching Proxy と一緒に結合されている、2 層 HA 構成のセットアップ方法について説明します。
図 46. Dispatcher、CBR、および Caching Proxy を使用する 2 層 HA 構成例
図 46 に対応するサーバー・マシン・セットアップは、以下のとおりです。
図 46 には、複数のバックエンド Web サーバー間でロード・バランシングされる複数のサーバー (EdgeServer1、EdgeServer2、EdgeServer3) の基本表現が示されています。 CBR コンポーネントは Caching Proxy を使用して、URL のコンテンツを基にして要求をバックエンド Web サーバーに転送します。 Dispatcher コンポーネントは、EdgeServer 間の CBR コンポーネントのロード・バランシングを行うために使用されます。 Dispatcher コンポーネントのハイ・アベイラビリティー・フィーチャーは、ハイ・アベイラビリティー・プライマリー・マシン (EdgeServer1) がいつ失敗しても、バックエンド・サーバーに対する要求が継続されることを保証するために使用されます。
基本構成ガイドライン:
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.company.com/* http://www.company.com/*
サンプル構成ファイル:
以下のサンプル構成ファイルは、図 46 に示されている Edge Component 構成のセットアップ時に作成されるファイルに類似しています。 サンプル構成ファイルは、Load Balancer の Dispatcher および CBR コンポーネント用のファイルを表しています。 サンプル構成では、単一のイーサネット・アダプターが EdgeServer マシンのそれぞれに使用され、アドレスのすべてはプライベート・サブネット内で表されます。 サンプル構成ファイルでは、指定されたマシン用に以下の IP アドレスが使用されます。
プライマリー・ハイ・アベイラビリティー EdgeServer 上の Dispatcher コンポーネント用サンプル構成ファイル:
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
EdgeServer 上の CBR コンポーネント用サンプル構成ファイル:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
本書は米国 IBM が提供する製品およびサービスについて作成したものです。
本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。 本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラムまたはサービスを使用することができます。 ただし、IBM 以外の製品、プログラムまたはサービスの 操作性の評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について
実施権を許諾することを意味するものではありません。
実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒106-8711
東京都港区六本木 3-2-12
日本アイ・ビー・エム株式会社
法務・知的財産
知的財産権ライセンス渉外
以下の保証は、国または地域の法律に沿わない場合は、適用されません。
IBM およびその直接または間接の子会社は、本書を特定物として現存するままの 状態で提供し、商品性の保証、特定目的適合性の保証および法律上の 瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、 便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものでは ありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部では ありません。それらの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムと
その他のプログラム (本プログラムを含む) との間での情報交換、
および (ii) 交換された情報の相互利用を可能にすることを目的として、
本プログラムに関する情報を必要とする方は、下記に連絡してください。
IBM Corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
U.S.A.
本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他の ライセンス資料は、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、 IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で 決定されたものです。 そのため、他の操作環境で得られた結果は、異なる可能性があります。 一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。 さらに、一部の測定値が、推定値である可能性があります。 実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、 他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
IBM の将来の方向または意向に関する記述については、 予告なしに変更または撤回される場合があり、単に目標を示しているものです。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。 より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。 これらの名称はすべて架空のものであり、 名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は 表示されない場合があります。
以下は、International Business Machines Corporation の米国およびその他の国における商標または登録商標です。
AFS
AIX
DFS
IBM
iSeries(TM)
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries(R)
Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。
Microsoft、Windows、Windows NT および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。
Intel(TM)、Intel Inside (ロゴ)、MMX(TM) および Pentium(R) は、Intel Corporation の米国およびその他の国における商標です。
UNIX は The Open Group の米国およびその他の国における登録商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。