この章では、HTTP ロードバランサプラグインについて説明します。ここで説明する内容は次のとおりです。
その他の種類の負荷分散については、第 10 章「Java Message Service 負荷分散とフェイルオーバー」および第 11 章「RMI-IIOP 負荷分散とフェイルオーバー」を参照してください。
ここでは、Application Server に付属している HTTP ロードバランサプラグインの使用方法について説明します。もう 1 つの HTTP 負荷分散オプションは、Application Server で Sun Secure Application Switch を使用し、ハードウェアベースの負荷分散ソリューションを構築するというものです。このソリューションを設定するためのチュートリアルについては、Clustering and Securing Web Applications: A Tutorial を参照してください。
Sun Java System Application Server 9.1 では、ロードバランサの機能が強化されており、次の各機能を通じて柔軟性と使いやすさの向上を実現しています。
Application Server では、管理コンソールで行ったロードバランサ設定の変更を、ネットワーク経由で自動的に Web サーバーの構成ディレクトリに送信できます。Application Server の以前のバージョンでは、ロードバランサ設定をエクスポートしてから、Web サーバーの構成ディレクトリにコピーする必要がありました。
ロードバランサでは、HTTP 要求の配信の改良を実現しています。管理者は「重み」と呼ばれる属性を使用して、重みに比例した形で要求をインスタンスにルーティングする方式を指定できます。たとえば、あるクラスタに 2 つのインスタンスがあり、管理者がインスタンス x に 100 の重みを、インスタンス y に 400 の重みを割り当てたとします。その場合、100 個の要求のうち 20 個がインスタンス x に、80 個がインスタンス y に振り分けられます。
Application Server では、HTTP 要求の分散に関するカスタムポリシーを管理者が定義できます。カスタムポリシーでは、ロードバランサプラグインが使用しなければならない負荷分散アルゴリズムを定義します。言い換えると、どの Application Server インスタンスが HTTP 要求を処理するかを管理者が定義できます。この機能を使用するには、指定された着信要求のヘッダーを評価し、その要求を処理できるインスタンスを何らかの基準に従って選択するなどの目的に使用できる共有ライブラリを管理者が開発する必要があります。この共有ライブラリはロードバランサによって読み込まれます。
この共有ライブラリは、appserver_install_dir/lib/install/templates 下の loadbalancer.h で定義されているインタフェースを実装する必要があります。
Application Server には、基本的なラウンドロビンアルゴリズムを実装するサンプルモジュール roundrobin.c も付属しています。管理者はこのサンプルモジュールを、共有ライブラリを構築するためのテンプレートとして使用できます。このサンプルモジュールは appserver_install_dir/lib/install/templates にも収録されています。
roundrobin.c を、appserver_install_dir/lib/install/templates から作業ディレクトリ (例: /home/user/workspacelb) にコピーします。
Sun Studio コンパイラや GCC などの ANSI C/C++ コンパイラを使用して、roundrobin.c をコンパイルします。必ず、静的な実行可能ファイルではなく動的な共有ライブラリとしてビルドしてください。
Sun Studio CC Compiler を使用している場合、次のコマンドを使用してコンパイルを行います。
cc -G -I<appserver install dir>/lib/install/templates roundrobin.c -o roundrobin.so
GCC を使用している場合、次のコマンドで共有ライブラリをコンパイルします。
gcc -shared -I<appserver install dir>/lib/install/templates roundrobin.c -o roundrobin.so
再配置エラーが発生した場合、オプション「-fPIC」を使用してもう一度コンパイルします。コマンドは次のようになります。
gcc -shared -fPIC -I <appserver install dir>/lib/install/templates roundrobin.c -o roundrobin.so
Microsoft Windows では、http://www.redhat.com/services/custom/cygwin から Cygwin ユーティリティーをダウンロードします。このユーティリティーには GCC が付属しています。次の GCC コマンドを使用して、ダイナミックリンクライブラリ (dll) を作成します。
gcc -shared -I<appserver_install_dir>/lib/install/templates roundrobin.c -o roundrobin.dll
新しく構築されたモジュールを指すように loadbalancer.xml を変更します。編集後の loadbalancer.xml は次のようになります。
<cluster name="cluster1" policy="user-defined" policy-module="home/user/workspacelb/roundrobin.so">
roundrobin.so を Web サーバーインスタンスのディレクトリにコピーします。
稼働していない場合は Web サーバーを起動するか、またはロードバランサが再構成されるまで待ちます。
ロードバランサの目的は、スタンドアロンまたはクラスタ化された複数の Application Server インスタンスの間でワークロードを均等に分散させ、それにより、システムの全体的なスループットを向上させることです。
HTTP ロードバランサにより、Java EE アプリケーションサーバーに配備されるサービスの高可用性を実現できます。負荷分散処理の間、それまでサービスを提供していたインスタンスが稼働していないか、または正常な状態でないために要求を処理できないことが検出された場合、HTTP ロードバランサはセッション要求を別のサーバーインスタンスにフェイルオーバーします。HTTP セッションの情報を持続させるためには、クラスタプロファイルを使用していること、HADB がインストールされ設定されていること、および、HTTP セッション持続性が設定されていることが必要です。詳細については、第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。
ロードバランサは、8K バイトを超える URI や URL を処理しません。
Sun Java System Application Server のロードバランサはデフォルトで、スティッキラウンドロビンアルゴリズムを使用して、着信 HTTP および HTTPS 要求を負荷分散します。
新しい HTTP 要求がロードバランサプラグインに送信されると、単純なラウンドロビンスキーマに基づいてアプリケーションサーバーインスタンスに転送されます。要求がセッションベースのアプリケーションに対するものである場合、これには新しいセッションに対する要求も含まれます。同じセッションベースのアプリケーションに対する同じクライアントからの後続の要求は、割り当て済み要求 (スティッキ要求) と見なされ、ロードバランサによって同じインスタンスにルーティングされます。スティッキ (sticky: 粘着性の) ラウンドロビンという名前が付いているのはそのような理由からです。セッションベースでないアプリケーションへの要求や、セッションベースのアプリケーションに対する最初の要求は未割り当て要求と呼ばれます。スティッキー性は Cookie を使用して、または明示的 URL 書き換えによって実現されます。ロードバランサは、スティッキ度を判断する方法を自動的に決定します。
ロードバランサプラグインは次の方法を使ってセッションのスティッキ度を判断します。
Cookie に基づいた方法: ロードバランサプラグインは、個別の Cookie を使用してルート情報を記録します。Cookie に基づいた方法を使用するには、HTTP クライアント (通常は Web ブラウザ) が Cookie をサポートしている必要があります。HTTP クライアントが Cookie を受け入れることができない場合、プラグインは次の方法を使用します。
明示的な URL 書き換え: スティッキ情報が URL に追加されます。この方法は、HTTP クライアントが Cookie をサポートしない場合でも機能します。
スティッキ情報から、ロードバランサプラグインは、まず、以前に要求が転送されたインスタンスを判断します。そのインスタンスが正常であるとわかると、ロードバランサプラグインは、要求をその特定のアプリケーションサーバーインスタンスに転送します。したがって、特定のセッションに対するすべての要求が同じアプリケーションサーバーインスタンスに送信されます。
この節では、ロードバランサプラグインを設定する方法について説明します。次の項目が含まれています。
ロードバランサを設定する前に、次の手順を実行する必要があります。
サポートされている Web サーバーをインストールし、必要な設定を行います。サポートされている Web サーバーの設定については、第 4 章「負荷分散のための Web Server の設定」を参照してください。
ロードバランサプラグインをインストールします。
インストール手順については、『Sun Java System Application Server 9.1 Installation Guide』を参照してください。
負荷分散に参加する Application Server クラスタまたはサーバーインスタンスを作成します。
これらのクラスタまたはインスタンスに対してアプリケーションを配備します。
Application Server インスタンスとロードバランサが異なるネットワークドメインにインストールされる配備状況では、ノードエージェントの作成時に、オプション --agentproperties を使用して完全指定ドメイン名を指定する必要があります。たとえば、asadmin create-node-agent --agentproperties remoteclientaddress=machine1.server.example.com test-na のようになります。このコマンドの詳細については、create-node-agent(1) を参照してください。
ユーザーの環境で負荷分散を設定するには、管理コンソールの GUI または asadmin ツールを使用します。以降の節では、さらに詳しい情報を示します。
ロードバランサ設定を作成します。
管理コンソールでは、左側の区画で「HTTP ロードバランサ」をクリックし、「新規」をクリックします。「新しい HTTP ロードバランサ」ページで、デバイスの詳細を指定し、ターゲットのクラスタまたはインスタンスも選択します。
ロードバランサが管理するクラスタまたはスタンドアロンサーバーインスタンスへの参照を追加します。
管理コンソールを使用してこれを行うには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「ターゲット」タブを開き、「ターゲットを管理」をクリックします。「ロードバランサのターゲットを管理」ページで、必要なターゲットを選択します。
ターゲットを指定してロードバランサ設定を作成しており、そのターゲットが、ロードバランサが参照する唯一のクラスタまたはスタンドアロンサーバーインスタンスである場合は、この手順を飛ばしてください。
ロードバランサによって参照されるクラスタまたはスタンドアロンサーバーインスタンスを有効にします。
管理コンソールを使用してスタンドアロンサーバーインスタンスを有効にするには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「ターゲット」タブを開き、「ターゲット」テーブルで、有効にするインスタンスの隣のチェックボックスにチェックマークを付け、「有効」をクリックします。
クラスタ内のサーバーインスタンスを有効にするには、上で説明した手順でロードバランサを選択し、「ターゲット」タブで目的のクラスタをクリックします。次に、「インスタンス」タブを開き、目的のインスタンスを選択し、「ロードバランサの操作」ドロップダウンリストから、「負荷分散の有効化」を選択します。
クラスタまたはスタンドアロンインスタンスを有効にするための同様のコマンドは、asadmin enable-http-lb-server です。
アプリケーションの負荷分散を有効にします。
これを管理コンソールで行うには、上で説明した手順で「ターゲット」タブを開き、必要なクラスタをクリックします。ここで「アプリケーション」タブを開き、必要なアプリケーションを選択し、「その他の操作」ドロップダウンリストから、「ロードバランサ有効」を選択します。
これらのアプリケーションは、ロードバランサが参照するクラスタまたはスタンドアロンインスタンスで使用するために、事前に配備および有効にしておく必要があります。負荷分散のためにアプリケーションを有効にする手順は、アプリケーションを使用可能にする手順とは別です。
健全性検査を作成します。
これを管理コンソールを使用して行うには、前に説明した手順でロードバランサの「ターゲット」タブを開き、「ターゲット」テーブルで「健全性チェッカを編集」をクリックします。
健全性チェッカは、不健全なサーバーインスタンスを監視し、それらの健全性が戻ったときにロードバランサが新しい要求を送信できるようにします。
Sun Java System Web Server (6.1 または 7.0) を使用している場合は、手順 6 および 7 を実行する代わりに、ロードバランサ設定ファイルを生成してネットワーク経由でデータを Web Server に送信すれば、処理を 1 つの手順で完了できます。
これを管理コンソールを使用して行うには、目的のロードバランサをクリックし、「エクスポート」タブを開きます。このタブで、「今すぐ適用」をクリックします。これにより、データは Web サーバーの構成ディレクトリに送信されます。
ロードバランサ設定ファイルを生成します。
これを管理コンソールを使用して行うには、ロードバランサをクリックし、「エクスポート」タブを開きます。このタブで、「今すぐエクスポート」をクリックします。
このコマンドは、Sun Java System Application Server に同梱されているロードバランサプラグインとともに使用する設定ファイルを生成します。
ロードバランサ設定ファイルを、ロードバランサプラグイン設定ファイルが格納されている Web サーバーの config ディレクトリにコピーします。
ロードバランサ設定ファイルを自動生成し、ネットワーク経由で Web サーバーにデータを送信する処理を 1 つの手順で行うには、SSL 設定用に Web サーバーを設定し、DAS 証明書をインポートする必要があります。Sun Java System Web Server の設定については、「Sun Java System Web Server の設定」を参照してください。
ロードバランサ設定を作成します。
これを行うには、コマンド asadmin create-http-lb-config を使用します。
次のすべての手順 (手順 2 〜 7) を、単一の asadmin コマンド create-http-lb とそのオプションを使用して実行できます。このコマンドの詳細については、create-http-lb(1) を参照してください。
ロードバランサが管理するクラスタまたはスタンドアロンサーバーインスタンスへの参照を追加します。
これを行うには、コマンド asadmin create-http-lb-ref を使用します。このコマンドの詳細については、create-http-lb-ref(1) を参照してください。
ターゲットを指定してロードバランサ設定を作成しており、そのターゲットが、ロードバランサが参照する唯一のクラスタまたはスタンドアロンサーバーインスタンスである場合は、この手順を飛ばしてください。
ロードバランサによって参照されるクラスタまたはスタンドアロンサーバーインスタンスを有効にします。
これを行うには、コマンド asadmin enable-http-lb-server を使用します。このコマンドの詳細については、enable-http-lb-server(1) を参照してください。
アプリケーションの負荷分散を有効にします。
これを行うには、コマンド asadmin enable-http-lb-application を使用します。このコマンドの詳細については、enable-http-lb-application(1) を参照してください。
これらのアプリケーションは、ロードバランサが参照するクラスタまたはスタンドアロンインスタンスで使用するために、事前に配備および有効にしておく必要があります。負荷分散のためにアプリケーションを有効にする手順は、アプリケーションを使用可能にする手順とは別です。
健全性検査を作成します。
これを行うには、コマンド asadmin create-http-health-checker を使用します。このコマンドの詳細については、create-http-health-checker(1) を参照してください。
健全性チェッカは、不健全なサーバーインスタンスを監視し、それらの健全性が戻ったときにロードバランサが新しい要求を送信できるようにします。
Sun Java System Web Server (6.1 または 7.0) を使用している場合は、手順 6 および 7 を実行する代わりに、ロードバランサ設定ファイルを生成してネットワーク経由でデータを Web Server に送信すれば、処理を 1 つの手順で完了できます。
asadmin ツールを使用してこれを行うには、create-http-lb コマンドの --autoapplyenabled オプションを true に設定します。このコマンドの詳細については、create-http-lb(1) を参照してください。
ロードバランサ設定ファイルを生成します。
これを行うには、コマンド asadmin export-http-lb-config を使用します。このコマンドの詳細については、export-http-lb-config(1) を参照してください。このコマンドは、Sun Java System Application Server に同梱されているロードバランサプラグインとともに使用する設定ファイルを生成します。
ロードバランサ設定ファイルを、ロードバランサプラグイン設定ファイルが格納されている Web サーバーの config ディレクトリにコピーします。
ロードバランサ設定ファイルを自動生成し、ネットワーク経由で Web サーバーにデータを送信する処理を 1 つの手順で行うには、SSL 設定用に Web サーバーを設定し、DAS 証明書をインポートする必要があります。Sun Java System Web Server の設定については、「Sun Java System Web Server の設定」を参照してください。
ロードバランサは、目標や環境に応じて、以下の節で説明している各種の方法で設定できます。
ロードバランサを配備するためのもっとも一般的な方法は、サーバーインスタンスのクラスタ (1 つまたは複数) を使用する方法です。デフォルトでは、クラスタ内のすべてのインスタンスは同じ設定を持ち、同じアプリケーションが配備されています。ロードバランサは、サーバーインスタンスの間でワークロードを分散させ、正常でないインスタンスから正常なインスタンスへのフェイルオーバーを要求します。HTTP セッション持続性を設定している場合は、要求が処理を引き継がれるとセッション情報は保持されます。
複数のクラスタがある場合、要求はクラスタ間で負荷分散されますが、要求のフェイルオーバーは単一クラスタ内のインスタンス間でのみ行われます。ロードバランサで複数のクラスタを使用すると、アプリケーションの順次アップグレードが容易に可能になります。詳細については、「可用性を低下させないアプリケーションのアップグレード」を参照してください。
クラスタ間およびスタンドアロンインスタンス間で要求を負荷分散することはできません。
複数のスタンドアロンインスタンスを使用するようにロードバランサを設定し、要求をそれらのインスタンス間で負荷分散したりフェイルオーバーしたりすることも可能です。ただし、この設定では、それぞれのスタンドアロンインスタンスに同種の環境が確保され、同じアプリケーションが配備されていることを手動で確認する必要があります。クラスタでは自動的に同種の環境が維持されるため、ほとんどの状況では、クラスタの使用がより適切で、より容易な方法です。
ロードバランサ設定は domain.xml ファイルに保持されます。ロードバランサの設定は非常に柔軟性があります。
ロードバランサがサービスを提供するドメインは 1 つだけですが、ドメインは関連する複数のロードバランサを持つことができます。
各ロードバランサ設定は、関連する複数のロードバランサを持つことができます。ただし、1 つのロードバランサには、1 つのロードバランサ設定しかできません。
以下の節では、ロードバランサ設定を作成、変更、および使用する方法についてさらに詳しく説明します。
Application Server 9.1 では、管理コンソールまたは asadmin コマンド create-http-lb を使用して、DAS 上のロードバランサ設定を作成できます。以降の手順ではその方法を説明します。asadmin コマンド create-http-lb、delete-http-lb、および list-http-lbs の詳細については、『Sun Java System Application Server 9.1 Reference Manual』を参照してください。
管理コンソールの左区画で下にスクロールして「HTTP ロードバランサ」ノードをクリックし、右側の「HTTP ロードバランサ」ページで「新規」をクリックします。「新しい HTTP ロードバランサ」ページで、ロードバランサのホストになるマシンについて次の情報を指定します。
フィールド |
説明 |
名前 |
ロードバランサ設定の名前。 |
有効 |
「有効」チェックボックスにチェックを入れると、ロードバランサ設定の変更が、Web サーバー構成ディレクトリ内の物理ロードバランサに自動的に送信されます。 |
ホスト |
Web サーバーインスタンスがインストールされているサーバー。 |
管理ポート |
Web サーバーインスタンスによって使用される管理ポート番号。 |
プロキシホスト |
プロキシサーバーインスタンスがインストールされているサーバー。 |
プロキシポート |
プロキシサーバーによって使用されるポート番号。 |
ロードバランサ設定は、asadmin コマンド create-http-lb-config を使用して作成することもできます。表 5–1 は、パラメータについての説明です。create-http-lb-config、delete-http-lb-config、および list-httplb-configs コマンドの詳細については、『Sun Java System Application Server 9.1 Reference Manual』を参照してください。
表 5–1 ロードバランサ設定のパラメータ
パラメータ |
説明 |
---|---|
応答タイムアウト |
サーバーインスタンスが応答を返すまでの秒数。タイムアウト時間内に応答が着信しない場合、サーバーが正常でないと判断されます。デフォルトは 60 です。 |
HTTPS ルーティング |
ロードバランサに対する HTTPS 要求の結果が、サーバーインスタンスに対する HTTPS または HTTP 要求となるかどうかを指定します。詳細については、「HTTPS ルーティングの設定」を参照してください。 |
再読み込み間隔 |
ロードバランサ設定ファイル loadbalancer.xml に対する変更をチェックする間隔。チェックによって変更が検出されると、設定ファイルが再読み込みされます。この値が 0 の場合は、再読み込みが無効になります。詳細については、「動的再設定を有効にする」を参照してください。 |
監視 |
ロードバランサで監視が有効かどうかを指定します。 |
ルート Cookie |
ロードバランサプラグインがルート情報を記録するために使用する Cookie の名前を指定します。HTTP クライアントは Cookie をサポートする必要があります。Cookie を格納する前に確認するようにブラウザが設定されている場合は、その Cookie の名前は「JROUTE」です。 |
ターゲット |
ロードバランサ設定のターゲットを指定します。ターゲットを指定すると、設定に参照を追加した場合と同じ結果になります。ターゲットは、クラスタまたはスタンドアロンインスタンスです。 |
ロードバランサでスタンドアロンのサーバーまたはクラスタへの参照を作成すると、ロードバランサが制御するターゲットサーバーおよびクラスタの一覧に、参照先のサーバーまたはクラスタが追加されます。この場合でも、参照先のサーバーまたはクラスタに対する要求を負荷分散する前に、そのサーバーまたはクラスタを有効化する必要があります。ターゲットを指定してロードバランサ設定を作成した場合、そのターゲットはすでに参照として追加されています。
管理コンソールを使用して参照を作成するには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「ターゲット」タブを開き、「ターゲットを管理」をクリックします。「ロードバランサのターゲットを管理」ページで、必要なターゲットを選択します。別の方法として、create-http-lb-ref を使用して参照を作成することもできます。ロードバランサ設定名と、ターゲットサーバーインスタンスまたはクラスタを指定する必要があります。
参照を削除するには、delete-http-lb-ref を使用します。参照を削除する前に、disable-http-lb-server を使用して参照先のサーバーまたはクラスタを無効にする必要があります。
このコマンドの詳細については、『Sun Java System Application Server 9.1 Reference Manual』を参照してください。
サーバーインスタンスまたはクラスタへの参照を作成したら、enable-http-lb-server を使用してサーバーインスタンスまたはクラスタを有効にします。ロードバランサ設定の作成時にサーバーインスタンスまたはクラスタをターゲットとして使用した場合は、それを有効にする必要があります。管理コンソールを使用してこれを行うには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。ここで「ターゲット」タブを開き、「ターゲット」テーブルで、有効にするインスタンスの隣のチェックボックスにチェックマークを付け、「有効」をクリックします。
このコマンドの詳細については、enable-http-lb-server(1) を参照してください。
ロードバランサによって管理されるすべてのサーバーは、アプリケーションの同じセットが配備されていることを含め、同じように設定されている必要があります。アプリケーションが配備されてアクセス可能になると (配備手順の実行中または完了後)、負荷分散を有効にする必要があります。アプリケーションで負荷分散が有効化されていない場合、そのアプリケーションが配備されているサーバーへの要求が負荷分散およびフェイルオーバーされていても、アプリケーションへの要求は負荷分散およびフェイルオーバーされません。
アプリケーションを有効にする際に、アプリケーション名とターゲットを指定します。ロードバランサが複数のターゲット (2 つのクラスタなど) を管理している場合は、すべてのターゲットでアプリケーションを有効にしてください。
管理コンソールを使用してアプリケーションを有効化するには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。前の手順の説明に従って「ターゲット」タブを開き、必要なクラスタをクリックします。ここで「アプリケーション」タブを開き、必要なアプリケーションを選択し、「その他の操作」ドロップダウンリストから、「ロードバランサ有効」を選択します。コマンド行からこれを行う場合、コマンド asadmin enable-http-lb-application を使用できます。コマンドの詳細については、enable-http-lb-application(1) を参照してください。
新しいアプリケーションを配備する場合にも、アプリケーションで負荷分散を有効にして、再度ロードバランサ設定をエクスポートする必要があります。
ロードバランサの健全性検査は、設定されている Application Server インスタンスの中で、正常ではないとしてマークされているすべてのインスタンスを定期的にチェックします。健全性検査は必須ではありませんが、このプログラムが存在しない場合、または無効になっている場合は、正常でないインスタンスの定期的な健全性検査は実行されません。ロードバランサは、正常でないインスタンスが正常になるタイミングを判断することはできません。
ロードバランサの健全性検査メカニズムは、HTTP を使用してアプリケーションサーバーと通信します。健全性検査は、指定された URL に HTTP 要求を送信し、応答を待ちます。HTTP 応答ヘッダー内の状態コードが 100 〜 500 の間であれば、インスタンスが正常であることを示します。
ロードバランサがクラスタに対するフロントエンドであり、クライアント証明書認証を有効にしてセキュリティー保護ポートを使用しているインスタンスがそのクラスタに含まれる配備状況では、健全性検査はインスタンスの診断を実行できません。したがって、そのようなインスタンスは常に正常でないと認識され、それらのインスタンスには要求は送られません。
健全性検査のプロパティーを指定するために、管理コンソールまたは asadmin create-http-health-checker コマンドを使用できます。管理コンソールでこれを行うには、「HTTP ロードバランサ」ノードに移動し、ノードを展開してロードバランサを選択します。次に「ターゲット」タブを開き、「ターゲット」テーブルで目的のターゲットの「健全性検査を編集」リンクをクリックします。次のパラメータを指定します。
表 5–2 健全性検査のパラメータ
パラメータ |
説明 |
デフォルト |
---|---|---|
ロードバランサ |
選択したサーバーで負荷分散を使用できるようにするには、「有効」チェックボックスにチェックを入れます。 |
False/無効 |
無効タイムアウト |
このサーバーが無効にされてから休止状態に入るまでの時間 (分単位)。 |
30 分 |
url |
ロードバランサが健康状態を判断するためにチェックするリスナーの URL を指定します。 |
“/” |
interval |
インスタンスの健全性検査を実行する間隔を秒単位で指定します。0 を指定すると、健全性検査が無効になります。 |
30 秒 |
timeout |
正常だと見なされるリスナーが応答を受け取るまでのタイムアウト間隔を秒単位で指定します。 |
10 秒 |
アプリケーションサーバーインスタンスが正常でないとマークされている場合、健全性検査が正常ではないインスタンスをポーリングして、インスタンスが正常になったかどうかを判断します。健全性検査は、指定された URL を使用して正常でないアプリケーションサーバーインスタンスをすべてチェックし、それらが正常な状態に戻っているかどうかを判断します。
健全性検査により、正常ではないインスタンスが正常になったことが確認されると、そのインスタンスが正常なインスタンスのリストに加えられます。
各コマンドの詳細については、create-http-health-checker(1) および delete-http-health-checker(1) を参照してください。
create-http-health-checker によって作成された健全性検査は、正常ではないインスタンスのみをチェックします。正常なインスタンスを定期的にチェックするには、エクスポートした loadbalancer.xml ファイルに追加のプロパティーをいくつか設定します。
これらのプロパティーは、loadbalancer.xml ファイルをエクスポートしたあとに手動で編集することによってのみ設定できます。同機能を持つ asadmin コマンドはありません。
正常なインスタンスをチェックするには、次のプロパティーを設定します。
表 5–3 健全性検査の手動のプロパティー
プロパティー |
定義 |
---|---|
サーバーインスタンスが正常であるかどうかを調べるために、それらに対して Ping を実行するかどうかを示す true/false フラグ。サーバーインスタンスに対して Ping を実行するには、このフラグを true に設定します。 |
|
ロードバランサの健全性検査が、応答しないサーバーインスタンスを正常でないとマークするまでに、それらに対して Ping を実行する回数を指定します。有効な範囲は 1 〜 1000 です。デフォルト値は 3 に設定します。 |
loadbalancer.xml ファイルを編集して、プロパティーを設定します。次に例を示します。
<property name="active-healthcheck-enabled" value="true"/> <property name="number-healthcheck-retries" value="3"/>
これらのプロパティーを追加し、続いて loadbalancer.xml ファイルをふたたび編集およびエクスポートする場合、新しくエクスポートされた設定には追加のプロパティーが含まれません。したがって、新しくエクスポートされた設定にこれらのプロパティーを再度追加する必要があります。
Sun Java System Application Server で提供されるロードバランサプラグインは、loadbalancer.xml という設定ファイルを使用します。ロードバランサを設定したあとで、設定の詳細を domain.xml から loadbalancer.xml ファイルにエクスポートできます。これは、管理コンソールまたは asadmin ユーティリティーを使用して行うことができます。
「HTTP ロードバランサ」ノードに移動し、ノードを展開します。
目的のロードバランサをクリックします。
すべてのロードバランサ設定の詳細が「一般」、「設定」、および「ターゲット」の各タブに表示されます。
「エクスポート」タブを開き、「今すぐエクスポート」をクリックします。
エクスポートしたロードバランサ設定ファイルを、Web サーバーの構成ディレクトリにコピーします。
asadmin コマンドの export-http-lb-config を使用して、loadbalancer.xml ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
特定のロードバランサ設定の loadbalancer.xml ファイルをエクスポートします。パスまたは別のファイル名を指定できます。ファイル名を指定しない場合、ファイルには loadbalancer.xml. load-balancer-config-name という名前が付けられます。パスを指定しない場合、ファイルは domain-dir/generated ディレクトリに作成されます。
Windows でパスを指定する場合は、パスを引用符で囲みます。たとえば、"C:\Sun\AppServer\loadbalancer.xml" のように指定します。
エクスポートしたロードバランサ設定ファイルを、Web サーバーの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、通常のコピー先は web-server-root/config となります。
Web サーバーの構成ディレクトリ内のロードバランサ設定ファイルには、loadbalancer.xml という名前を付ける必要があります。loadbalancer.xml. load-balancer-config-name などの別の名前を付けた場合は、変更する必要があります。
サーバーへの参照の作成または削除、新しいアプリケーションの配備、サーバーまたはアプリケーションの有効化/無効化などによってロードバランサ設定を変更した場合は、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーします。詳細については、「ロードバランサ設定ファイルのエクスポート」を参照してください。
ロードバランサプラグインは、ロードバランサ設定で指定した再読み込み間隔に従って、更新された設定を定期的にチェックします。指定した時間が経過して、ロードバランサが新しい設定ファイルを検出した場合は、その設定を使用して再読み込みが開始されます。
動的再設定で、ロードバランサプラグインは更新された設定がないかどうかを定期的にチェックします。
動的再設定を有効にするには、次の手順に従います。
ロードバランサ設定を作成するときに、asadmin create-http-lb で --reloadinterval オプションを使用します。コマンドの詳細については、create-http-lb(1) を参照してください。
このオプションは、ロードバランサ設定ファイル loadbalancer.xml に対する変更のチェックの間隔を設定します。この値が 0 の場合は、動的再設定が無効になります。デフォルトでは、動的再設定が有効になり、再読み込み間隔は 60 秒に設定されます。
以前に動的再設定を無効にしていた場合、または再読み込み間隔を変更する場合は、asadmin set コマンドを使用します。
再読み込み間隔を変更したら、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーしたあと、Web サーバーを再起動します。
ロードバランサがそれ自体の再設定を試みているときにハードディスク読み込みエラーが発生した場合、ロードバランサは現在メモリーに格納されている設定を使用します。ロードバランサはまた、既存の設定を上書きする前に、変更された設定データが必ず DTD に適合するようにします。
ディスク読み込みエラーが発生すると、Web サーバーのエラーログファイルに警告メッセージが記録されます。
Sun Java System Web Server のエラーログは、次の場所にあります。web-server-install-dir/web-server-instance/logs/。
何らかの理由でアプリケーションサーバーを停止する場合は、その前に、インスタンスで要求の処理が完了する必要があります。サーバーインスタンスまたはクラスタを正常に無効にするプロセスは、休止と呼ばれます。
ロードバランサは、アプリケーションサーバーインスタンスを休止するために、次のポリシーを使用します。
あるインスタンス (スタンドアロンまたはクラスタの一部分) が無効化され、タイムアウトが経過していない場合、スティッキ要求はインスタンスに配信され続けます。ただし、新しい要求は無効化されたインスタンスに送信されません。
タイムアウトを経過すると、インスタンスは無効化されます。ロードバランサからインスタンスへのすべてのオープン接続が閉じられます。このインスタンスに固定されている一部のセッションが無効化されなかった場合でも、ロードバランサはこのインスタンスに要求を送りません。ロードバランサはスティッキ要求を別の正常なインスタンスにフェイルオーバーします。
asadmin disable-http-lb-server を実行して、タイムアウトを分単位で設定します。コマンドの詳細については、disable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
エクスポートした設定を Web サーバーの config ディレクトリにコピーします。
サーバーインスタンスを停止します。
Web アプリケーションの配備を取り消す前に、アプリケーションで要求の処理が完了する必要があります。アプリケーションを正常に無効にするプロセスは、休止と呼ばれます。アプリケーションを休止する場合は、タイムアウトピリオドを指定します。ロードバランサは、指定されたタイムアウトピリオドに基づいて、アプリケーションを休止するために次のポリシーを使用します。
タイムアウトピリオドが経過していない場合、ロードバランサは新しい要求をアプリケーションには転送せずに、Web サーバーに返します。ただし、タイムアウトピリオドが経過するまで、スティッキ要求の転送は引き続き行います。
タイムアウトピリオドを経過すると、ロードバランサは、スティッキ要求を含むアプリケーションへのすべての要求を受け付けなくなります。
ロードバランサが参照するすべてのサーバーインスタンスまたはクラスタから、あるアプリケーションを無効にする場合、無効化されたアプリケーションのユーザーは、アプリケーションが再度有効化されるまでサービスを受けられません。1 つのサーバーインスタンスまたはクラスタからアプリケーションを無効にして、別のサーバーインスタンスまたはクラスタでは有効にする場合、ユーザーは引き続きアプリケーションにアクセスできます。詳細については、「可用性を低下させないアプリケーションのアップグレード」を参照してください。
asadmin disable-http-lb-application を使用して、次のパラメータを指定します。
タイムアウト (分単位)
無効にするアプリケーションの名前
無効化を実行するターゲットクラスタまたはインスタンス
コマンドの詳細については、disable-http-lb-application(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
エクスポートした設定を Web サーバーの config ディレクトリにコピーします。
HTTP/HTTPS セッションが接続されていた元のアプリケーションサーバーインスタンスが利用できなくなった場合、ロードバランサプラグインは、そのセッションを別のアプリケーションサーバーインスタンスにフェイルオーバーします。この節では、HTTP/HTTPS ルーティングとセッションフェイルオーバーを有効にするようにロードバランサプラグインを設定する方法について説明します。
ロードバランサプラグインは、すべての着信 HTTP または HTTPS 要求をアプリケーションサーバーインスタンスにルーティングします。ただし、HTTPS ルーティングが有効になっている場合、ロードバランサプラグインは HTTPS ポートのみを使用して HTTPS 要求をアプリケーションサーバーに転送します。HTTPS ルーティングは、新しい要求とスティッキ要求の両方について実行されます。
HTTPS 要求が受信され、処理中のセッションがない場合、ロードバランサプラグインは設定されている HTTPS ポートを使用して使用可能なアプリケーションサーバーインスタンスを選択し、要求をそのインスタンスに転送します。
継続中の HTTP セッションで、同じセッションに対して新しい HTTPS 要求が受信された場合、HTTP セッション中に保存されたセッションおよびスティッキ情報を使用して HTTPS 要求がルーティングされます。新しい HTTPS 要求は、最後の HTTP 要求が処理された同じサーバーにルーティングされます。ただし、HTTPS ポートが使用されます。
create-http-lb-config コマンドの httpsrouting オプションは、負荷分散に関わるすべてのアプリケーションサーバーに対して HTTPS ルーティングが有効か無効かを制御します。このオプションが false に設定されている場合、すべての HTTP および HTTPS 要求は HTTP として転送されます。true に設定されている場合、HTTPS は HTTPS 要求として転送されます。新しいロードバランサ設定を作成する場合、または、作成後に asadmin set コマンドを使用して変更する場合には、HTTPS ルーティングを設定してください。
HTTPS ルーティングを動作させるには、1 つまたは複数の HTTPS リスナーを設定する必要があります。
https-routing が true に設定されていて、クラスタ内に正常な HTTPS リスナーが存在していない状態で新しい要求またはスティッキ要求が着信した場合、その要求はエラーを生成します。
ロードバランサには、HTTP/HTTPS 要求の処理に関する次の制限事項があります。
あるセッションが HTTP 要求と HTTPS 要求を組み合わせて使用する場合、最初の要求は必ず HTTP 要求にする必要があります。最初の要求が HTTPS 要求の場合、そのあと HTTP 要求を続けられません。これは、HTTPS セッションに関連付けられている Cookie がブラウザによって返されないからです。ブラウザは、異なる 2 つのプロトコルを異なる 2 つのサーバーと解釈し、新しいセッションを開始します。この制限は、httpsrouting が true に設定されている場合のみ有効です。
あるセッションに HTTP 要求と HTTPS 要求の組み合わせが含まれる場合、アプリケーションサーバーインスタンスは HTTP リスナーと HTTPS リスナーの両方を使用して設定される必要があります。この制限は、httpsrouting が true に設定されている場合のみ有効です。
あるセッションに HTTP 要求と HTTPS 要求の組み合わせが含まれる場合、アプリケーションサーバーインスタンスは、標準ポート番号、すなわち HTTP には 80、HTTPS には 443 を使用する HTTP および HTTPS リスナーによって設定される必要があります。この制限は、httpsrouting に設定された値に関係なく適用されます。
リダイレクトを使用して、ある URL から別の URL へ要求をリダイレクトします。たとえば、リダイレクトを使用して、ユーザーを別の Web サイトに送信したり (旧バージョンのアプリケーションから新しいバージョンへリダイレクトする場合など)、HTTP から HTTPS へ、または HTTPS から HTTP へ送信したりします。アプリケーション内でリダイレクトを有効にする方法はいくつもあります (たとえば、servlet ベースのリダイレクト、web.xml リダイレクト)。ただし、ロードバランサを通してリダイレクト URL を送信するには、Application Server またはロードバランサに対していくつか追加設定が必要な場合があります。リダイレクトは HTTPS ルーティングを使用して転送される要求とは異なるので注意してください。リダイレクトを使用するときには、httpsrouting を false に設定します。HTTPS 要求を HTTP に転送するように設定する場合は、「HTTPS ルーティング」を使用します。
リダイレクトに影響するプロパティーは次のとおりです。HTTP サービスまたは HTTP リスナーの authPassthroughEnabled および proxyHandler プロパティーと、loadbalancer.xml ファイル内の rewrite-location プロパティー。
Application Server authPassthroughEnabled プロパティーを true に設定した場合、カスタムな要求ヘッダーを使用して、元のクライアント要求に関する情報 (クライアント IP アドレス、SSL キーサイズ、認証されたクライアント証明書チェーンなど) が HTTP リスナーへ送信されます。authPassThroughEnabled プロパティーを使用すると、ハードウェアアクセラレータ (インストールされている場合) を利用して SSL 認証をより高速にできます。ハードウェアアクセラレータの設定は、クラスタ化されたそれぞれの Application Server インスタンス上よりも、ロードバランサ上で行う方が簡単です。
authPassthroughEnabled は、Application Server がファイアウォールの後ろにある場合のみ true に設定します。
asadmin set コマンドを使用して、HTTP サービスまたは個別の HTTP リスナー上に authPassthroughEnabled プロパティーを設定します。個別の HTTP リスナーに対する設定は、HTTP サービスに対する設定よりも優先されます。
すべての HTTP および HTTPS リスナー上に authPassthroughEnabled プロパティーを設定するには、次のコマンドを使用します。
asadmin set cluster-name-config.http-service.property.authPassthroughEnabled=true
このプロパティーを個別のリスナー上に設定するには、次のコマンドを使用します。
asadmin set cluster-name-config.http-service.http-listener.listener-name.property.authPassthroughEnabled=true
Application Server のプロキシハンドラは、プロキシサーバー (この場合はロードバランサ) によって遮断されて Application Server に転送された元のクライアント要求に関する情報を取得し、クライアント要求のターゲットである (Application Server 上に配備された) Web アプリケーションでこの情報を使用できるようにする役目を担っています。遮断するプロキシサーバーが SSL の終端となる場合、プロキシハンドラは、元の要求が HTTPS 要求であったのか、SSL クライアント認証が有効なのかなど元の要求に関する追加の情報を取得して使用可能にします。proxyHandler プロパティーは、authPassThroughEnabled が true に設定されている場合のみ使用します。
プロキシハンドラは、プロキシサーバーが元のクライアント要求に関する情報を伝達するのに使用するカスタムな要求ヘッダーについて着信要求を調べ、標準の ServletRequest API を使用してこの情報を Application Server 上の Web アプリケーションで使用できるようにします。
プロキシハンドラの実装は、proxyHandler プロパティーを使用して、HTTP サービスレベルでグローバルに設定することも、個別の HTTP リスナーに対して設定することもできます。このプロパティーの値は、com.sun.appserv.ProxyHandler 抽象クラスの実装の完全修飾クラス名を指定します。設定可能なプロキシハンドラの実装が、HTTP 要求ヘッダー名について認識し、プロキシサーバーが元のクライアント要求に関する情報を伝達するのに使用する値の書式を理解しているかぎり、プロキシハンドラの実装によって Application Server は任意のプロキシサーバーで動作できます。
Application Server のプロキシハンドラは、要求ヘッダーから SSL 証明書チェーンを読み込んで解析します。これによって、バックエンドのアプリケーションサーバーインスタンスは、SSL 終端となるプロキシサーバー (ここではロードバランサ) によって遮断された元のクライアント要求に関する情報を取得できるようになります。デフォルトのプロキシハンドラ設定を使用することも、HTTP サービスまたは HTTP/HTTPS リスナーの proxyHandler プロパティーを使用してユーザー設定することもできます。proxyHandler プロパティーでは、そのリスナーまたはすべてのリスナーによって使用される com.sun.appserv.ProxyHandler 抽象クラスのカスタム実装の完全修飾クラス名を指定します。
この抽象クラスの実装は、Application Server インスタンスへの元のクライアント要求に関する情報を伝達するためにプロキシサーバーが使用するカスタム要求ヘッダーに対して行われる特定の要求を調べ、その情報を呼び出し元に返します。デフォルトの実装では、Proxy-ip という名前の HTTP 要求ヘッダーからクライアント IP アドレスを、Proxy-keysize という名前の HTTP 要求ヘッダーから SSL キーサイズを、Proxy-auth-cert という名前の HTTP 要求ヘッダーから SSL クライアント証明書チェーンを読み取ります。Proxy-auth-cert 値には、BEGIN CERTIFICATE および END CERTIFICATE の境界がなく、\n が % d% a によって置き換えられた BASE-64 エンコードのクライアント証明書チェーンを含む必要があります。
このプロパティーは、authPassThroughEnabled を true に設定した場合のみ使用できます。個別の HTTP または HTTPS リスナー上に proxyHandler プロパティーを設定すると、すべてのリスナーのデフォルト設定が上書きされます。
asadmin set コマンドを使用して、HTTP サービスまたは個別の HTTP リスナー上に proxyHandler プロパティーを設定します。
proxyHandler プロパティーを、すべての HTTP および HTTPS リスナー上に設定するには、次のコマンドを使用します。
asadmin set cluster-name-config.http-service.property.proxyHandler=classname
このプロパティーを個別のリスナー上に設定するには、次のコマンドを使用します。
asadmin set cluster-name-config.http-service.http-listener.listener-name.property.proxyHandler=classname
rewrite-location プロパティーを true に設定すると、元の要求情報が書き換えられ、プロトコル (HTTP または HTTPS)、ホスト、およびポートの情報が追加されます。デフォルトでは、以前のリリースの Application Server との後方互換性を保つために、rewrite-location プロパティーは true に設定されます。
rewrite-location プロパティーは、asadmin create-http-lb-config または asadmin set コマンドを介して使用することはできません。このプロパティーを使用するには、ロードバランサ設定をエクスポートしてから、loadbalancer.xml ファイルにこのプロパティーを手動で追加します。たとえば、エクスポートした loadbalancer.xml ファイルに、次の内容を追加します。
<property name="rewrite-location" value="false"/>
rewrite-location プロパティーを設定するときには、次の点に注意します。
httpsrouting が false で、Application Server 上で authPassthroughEnabled が有効でない場合は、rewrite-location プロパティーを true に設定します。authPassthroughEnabled が有効でない場合、Application Server は元の要求のプロトコル (HTTP または HTTPS) を認識しません。rewrite-location を true に設定することで、ロードバランサは書き換えの場所のプロトコル部分を適切に変更します。つまり、クライアントが HTTPS 要求を送信していれば、ロードバランサはクライアントをロードバランサ上の HTTPS が有効になっているリスナーポートにリダイレクトします。このプロセスは HTTP 要求の場合と同じです。
httpsrouting が false で、authPassthroughEnabled が Application Server 上で有効になっている場合、Application Server はクライアント要求が HTTP と HTTPS のどちらであるのかを認識しているので、rewrite-location を true または false に設定することができます。authPassthroughEnabled が有効になっている場合、Application Server は書き換えの場所のプロトコル部分を適切に変更します。rewrite-location が false に設定されている場合、ロードバランサはリダイレクトされた URL の場所を書き換えません。true に設定されている場合は、リダイレクトされた URL の場所を書き換えます。しかしこの書き換えは、Application Server がクライアントからの HTTPS 接続を認識していれば必要ありません。また、アプリケーションが HTTP から HTTPS または HTTPS から HTTP にリダイレクトする必要のある場合、rewrite-location パラメータを false に設定する必要があります。
べき等要求とは、再試行時にアプリケーションに変更や不一致をもたらさないタイプの要求です。HTTP の場合、GET などの一部のメソッドはべき等的ですが、POST などその他のメソッドはそうではありません。べき等 URL の再試行では、サーバーまたはデータベースの値が変更されてはいけません。ユーザーが受信する応答が変更されるだけです。
べき等要求の例としては、検索エンジンクエリーやデータベースクエリーがあります。基礎となる原則は、再試行によってデータの更新や変更が発生しないことです。
配備されたアプリケーションの可用性を向上させるには、ロードバランサによって処理されたすべてのアプリケーションサーバーインスタンスに、失敗したべき等の HTTP 要求を再試行する環境を設定します。このオプションは、検索要求の再試行など、読み取り専用の要求に使用されます。
sun-web.xml ファイルに、べき等 URL を設定します。ロードバランサ設定をエクスポートする場合、べき等 URL の情報は自動的に loadbalancer.xml ファイルに追加されます。
べき等 URL の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の「Configuring Idempotent URL Requests」を参照してください。
Sun Java System Application Server インストーラでは、1 台のマシンに複数のロードバランサプラグインをインストールできません。1 つまたは複数のクラスタ内の 1 台のマシンに、ロードバランサプラグインとともに複数の Web サーバーを置くには、いくつかの手順を手動で実行してロードバランサプラグインを設定する必要があります。
ロードバランサプラグインを使用するように新しい Web サーバーインスタンスを設定します。
詳細な手順については、「Sun Java System Web Server の設定」を参照してください。
既存の Web サーバーインスタンスの config ディレクトリから、DTD ファイル sun-loadbalancer_1_1.dtd を新しいインスタンスの config ディレクトリにコピーします。
ロードバランサ設定ファイルを設定します。次のいずれかを実行します。
既存のロードバランサ設定をコピーします。
既存のロードバランサ設定を使用して、既存の Web サーバーインスタンスの config ディレクトリから、loadbalancer.xml ファイルを新しいインスタンスの config ディレクトリにコピーします。
新しいロードバランサ設定を作成します。
asadmin create-http-lb-config を使用して、新しいロードバランサ設定を作成します。
asadmin export http-lb-config を使用して、新しい設定を loadbalancer.xml ファイルにエクスポートします。
loadbalancer.xml ファイルを、新しい Web サーバーの config ディレクトリにコピーします。
ロードバランサ設定を作成し、それを loadbalancer.xml ファイルにエクスポートする方法については、「DAS 上での HTTP ロードバランサの設定」を参照してください。
ユーザーへの可用性を低下させることなくアプリケーションを新しいバージョンにアップグレードする方法は、順次アップグレードと呼ばれます。アップグレードの前後で 2 つのバージョンのアプリケーションを慎重に管理することによって、アプリケーションの現在のユーザーが中断されることなくタスクを完了できる一方で、新しいユーザーが新しいバージョンのアプリケーションを透過的に取得できるようになります。順次アップグレードの場合、ユーザーはアップグレードが行われたことに気付きません。
順次アップグレードでは、2 つのアプリケーションバージョン間の変更の大きさに応じて、さまざまなレベルの困難が発生します。
変更が、たとえば、静的なテキストやイメージへの変更のような表面的なものであれば、2 つのバージョンのアプリケーションには互換性があり、同じクラスタ内で両方のバージョンを一度に実行することができます。
互換性のあるアプリケーションは、次の条件を備えている必要があります。
同じセッション情報を使用している。
互換性のあるデータベーススキーマを使用している。
一般に互換性のあるアプリケーションレベルのビジネスロジックを採用している。
同じ物理データソースを使用している。
互換性のあるアプリケーションの順次アップグレードは、単一のクラスタまたは複数のクラスタのどちらでも実行できます。詳細については、「単一クラスタでのアップグレード」を参照してください。
2 つのバージョンのアプリケーションが上の一部の条件を満たしていない場合、これらのアプリケーションは互換性がないと見なされます。互換性のないバージョンのアプリケーションを同じクラスタ内で実行すると、アプリケーションデータが破壊され、セッションフェイルオーバーが発生して正しく機能しなくなる場合があります。発生する問題は、非互換性の種類や程度によって異なります。新しいバージョンを配備して古いクラスタやアプリケーションを徐々に休止する「シャドウクラスタ」を作成して、互換性のないアプリケーションをアップグレードすることをお勧めします。詳細については、「互換性のないアプリケーションのアップグレード」を参照してください。
アプリケーション開発者および管理者は、アプリケーションのバージョンに互換性があるかどうかを判断できる最適な人びとです。不明な場合は、バージョンには互換性がないと仮定してください。これがもっとも安全な方法です。
単一のクラスタに配備されたアプリケーションの順次アップグレードは、そのクラスタの設定がほかのどのクラスタとも共有されていないと仮定して行うことができます。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。コマンドの詳細については、backup-domain(1) を参照してください。
クラスタの動的再設定を無効にします (有効になっている場合)。
管理コンソールを使用してこれを行うには、次の手順に従います。
あるいは、次のコマンドを使用します。
asadmin set --user user --passwordfile password-file cluster-name-config.dynamic-reconfiguration-enabled=false
ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。
管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。asadmin を使用している場合は、ターゲットのドメインを指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
asadmin enable-http-lb-application を使用して、インスタンスに対して再配備したアプリケーションを有効にします。コマンドの詳細については、enable-http-lb-application(1) を参照してください。
ロードバランサから、クラスタ内の 1 つのサーバーインスタンスを休止します。
次の手順を実行します。
asadmin disable-http-lb-server を使用して、サーバーインスタンスを無効にします。コマンドの詳細については、disable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir /https-host-name /config/loadbalancer.xml となります。確実にロードバランサに新しい設定ファイルをロードさせるために、ロードバランサ設定の reloadinterval を設定して、動的再設定が有効であることを確認します。
タイムアウトが経過するまで待機します。
ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。
クラスタ内のほかのインスタンスが実行中の間に、無効になっていたサーバーインスタンスを再起動します。
再起動すると、サーバーはドメインと同期し、アプリケーションを更新します。
再起動したサーバー上でアプリケーションをテストし、正しく動作していることを確認します。
ロードバランサで、サーバーインスタンスをふたたび有効にします。
次の手順を実行します。
asadmin enable-http-lb-server を使用して、サーバーインスタンスを有効にします。コマンドの詳細については、enable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
設定ファイルを Web サーバーの構成ディレクトリにコピーします。
クラスタ内の各インスタンスに対して、手順 5 〜 8 を繰り返します。
すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、そのクラスタに対して動的再設定を再度有効にすることができます。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。コマンドの詳細については、backup-domain(1) を参照してください。
すべてのクラスタの動的再設定を無効にします (有効になっている場合)。
管理コンソールを使用してこれを行うには、次の手順に従います。
「設定」ノードを開きます。
1 つのクラスタの設定の名前をクリックします。
「システムプロパティーの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。
「保存」をクリックします。
ほかのクラスタに対して上記手順を繰り返します
あるいは、次のコマンドを使用します。
asadmin set --user user --passwordfile password-file cluster-name-config.dynamic-reconfiguration-enabled=false
ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。
管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。asadmin を使用している場合は、ターゲットのドメインを指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
asadmin enable-http-lb-application を使用して、クラスタに対して再配備したアプリケーションを有効にします。コマンドの詳細については、enable-http-lb-application(1) を参照してください。
ロードバランサから 1 つのクラスタを休止します
asadmin disable-http-lb-server を使用して、クラスタを無効にします。 コマンドの詳細については、disable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir/ https-host-name/config/loadbalancer.xml となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の reloadinterval を設定して、ロードバランサの動的再設定を有効にする必要があります。
タイムアウトが経過するまで待機します。
ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。
ほかのクラスタが実行中の間に、無効となっていたクラスタを再起動します。
再起動すると、クラスタはドメインと同期し、アプリケーションを更新します。
再起動したクラスタ上でアプリケーションをテストし、正しく動作していることを確認します。
ロードバランサでクラスタを有効にします。
asadmin enable-http-lb-server を使用して、クラスタを有効にします。コマンドの詳細については、enable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
設定ファイルを Web サーバーの構成ディレクトリにコピーします。
ほかのクラスタに対して、手順 5 〜 8 を繰り返します。
すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、すべてのクラスタに対して動的再設定を再度有効にすることができます。
アプリケーションの新しいバージョンと古いバージョンとの間に互換性がない場合、次の手順を実行します。アプリケーションの互換性に必要な条件については、「アプリケーションの互換性」を参照してください。互換性のないアプリケーションは、2 つ以上のクラスタでアップグレードする必要があります。クラスタが 1 つしかない場合は、後述の説明に従って、アップグレードのための「シャドウクラスタ」を作成します。
互換性のないアプリケーションをアップグレードする場合は、次の手順を実行します。
新しいバージョンのアプリケーションに、古いバージョンのアプリケーションとは別の名前を付けます。このあとの手順は、アプリケーションの名前が変更されていることを前提にしています。
データスキーマに互換性がない場合は、データの移行を計画したあとに、別の物理データソースを使用します。
新しいバージョンを、古いバージョンが配備されているクラスタとは別のクラスタに配備します。
アプリケーションへの要求は新しいクラスタに処理を引き継がないため、クラスタをオフラインにする前に、古いアプリケーションを実行しているクラスタには適切な長いタイムアウトを設定します。これらのユーザーセッションは、単純に失敗します。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。コマンドの詳細については、backup-domain(1) を参照してください。
同じマシンセットまたは別のマシンセットに、既存のクラスタとして「シャドウクラスタ」を作成します。2 番目のクラスタがすでに存在する場合、この手順はスキップします。
管理コンソールを使用して、既存のクラスタで名前を付けられている設定から新しいクラスタと参照を作成します。
既存のアクティブポートとの競合を回避するために、各マシンで新しいインスタンスのポートをカスタマイズします。
asadmin create-resource-ref を使用して、クラスタに関連付けられたすべてのリソースについて、新しく作成されたクラスタにリソース参照を追加します。 コマンドの詳細については、create-resource-ref(1) を参照してください。
asadmin create-application-ref を使用して、新しく作成されたクラスタから、クラスタに配備されているほかのすべてのアプリケーション (現在再配備されているアプリケーションを除く) への参照を作成します。コマンドの詳細については、create-application-ref(1) を参照してください。
asadmin configure-ha-cluster を使用して、クラスタを高可用性に設定します。コマンドの詳細については、configure-ha-cluster(1) を参照してください。
asadmin create-http-lb-ref を使用して、ロードバランサ設定ファイル内の新しく作成されたクラスタへの参照を作成します。コマンドの詳細については、create-http-lb-ref(1) を参照してください。
新しいバージョンのアプリケーションに、古いバージョンとは別の名前を付けます。
新しいクラスタをターゲットとして、新しいアプリケーションを配備します。別のコンテキストルートを使用します。
asadmin enable-http-lb-application を使用して、クラスタに対して配備した新しいアプリケーションを有効にします。コマンドの詳細については、enable-http-lb-application(1) を参照してください。
ほかのクラスタが実行している間に、新しいクラスタを起動します。
起動すると、クラスタはドメインと同期し、新しいアプリケーションで更新されます。
新しいクラスタ上でアプリケーションをテストして、正しく動作していることを確認します。
asadmin disable-http-lb-server を使用して、ロードバランサから古いクラスタを無効にします。コマンドの詳細については、disable-http-lb-server(1) を参照してください。
無応答のセッションに対するタイムアウト時間を設定します。
asadmin enable-http-lb-server を使用して、ロードバランサから新しいクラスタを有効にします。コマンドの詳細については、enable-http-lb-server(1) を参照してください。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。コマンドの詳細については、export-http-lb-config(1) を参照してください。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir/ https-host-name/config/loadbalancer.xml となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の reloadinterval を設定して、ロードバランサの動的再設定を有効にする必要があります。
タイムアウト期間が経過するか、または古いアプリケーションのすべてのユーザーが終了したら、古いクラスタを停止し、古いアプリケーションを削除します。
ロードバランサプラグインは、Web サーバーのログメカニズムを使用してメッセージを書き込みます。Application Server のデフォルトのログレベルは、Sun Java System Web Server (INFO)、Apache Web Server (WARN)、および Microsoft IIS (INFO) のデフォルトのログレベルに設定されています。アプリケーションサーバーのログレベルである FINE、FINER、および FINEST は、Web サーバーの DEBUG レベルに対応します。
これらのログメッセージは Web サーバーのログファイルに書き込まれます。これらは raw データ形式で、スクリプトを使用して解析されるかまたは表計算ドキュメントにインポートされて、必要なメトリックスを計算します。
ロードバランサプラグインは、次の種類のログメッセージを生成します。
これらのメッセージは、べき等 URL とエラーページ設定を使用している場合に記録されます。
べき等 URL のパターン設定の出力には、次の情報が含まれます。
ログレベルが FINE に設定されている場合:
CONFxxxx: IdempotentUrlPattern configured <url-pattern> <no-of-retries> for web-module : <web-module> (意味) IdempotentUrlPattern によって、Web モジュール <web-module> に対する <url-pattern> <no-of-retries> が設定されました
ログレベルが SEVERE に設定されている場合:
CONFxxxx: Duplicate entry of Idempotent URL element <url-pattern> for webModule <web-module> in loadbalancer.xml." (意味) loadbalancer.xml の Web モジュール <web-module> に対するべき等 URL 要素 <url-pattern> のエントリが重複しています
ログレベルが WARN に設定されている場合:
CONFxxxx: Invalid IdempotentUrlPatternData <url-pattern> for web-module <web-module> (意味) Web モジュール <web-module> の IdempotentUrlPatternData <url-pattern> が無効です
エラーページの URL 設定の出力には、次の情報が含まれます (ログレベルが WARN に設定されている場合)。
CONFxxxx: Invalid error-url for web-module <web-module> (意味) Web モジュール <web-module> の error-url が無効です
これらのログメッセージは、要求が負荷分散およびディスパッチされている間に生成されます。
各メソッドの始まりの標準的なログの出力には、次の情報が含まれます (ログレベルが FINE に設定されている場合)。
ROUTxxxx: Executing Router method <method_name> (意味) ルーターメソッド <method_name> を実行しています
各メソッドの始まりのルーターログの出力には、次の情報が含まれます (ログレベルが INFO に設定されている場合)。
ROUTxxxx: Successfully Selected another ServerInstance for idempotent request <Request-URL> (意味) べき等要求 <Request-URL> に対する別の ServerInstance の選択に成功しました
実行時ログの出力には、次の情報が含まれます (ログレベルが INFO に設定されている場合)。
RNTMxxxx: Retrying Idempotent <GET/POST/HEAD> Request <Request-URL> (意味) べき等の <GET/POST/HEAD> 要求 <Request-URL> を再試行しています
これらのエラーは、参照先のカスタムエラーページがなくなっているなど、設定上の問題がある場合に表示されます。
ログレベルが INFO に設定されている場合:
ROUTxxxx: Non Idempotent Request <Request-URL> cannot be retried (意味) 非べき等要求 <Request-URL> は、再試行されません
次に例を示します。ROUTxxxx: Non Idempotent Request http://sun.com/addToDB?x=11&abc=2 cannot be retried
ログレベルが FINE に設定されている場合:
RNTMxxxx: Invalid / Missing Custom error-url / page: <error-url> for web-module: <web-module> (意味) Web モジュール <web-module> に対するカスタムエラー URL またはページ <error-url> が、無効または不明です
次に例を示します。RNTMxxxx: Invalid / Missing Custom error-url / page: myerror1xyz for web-module: test
ロードバランサプラグインは、次の情報をログに記録します。
すべての要求の開始/終了情報。
要求が正常ではないインスタンスから正常なインスタンスにフェイルオーバーされた際の、引き継がれた要求の情報。
すべての健全性検査サイクルの最後にある正常ではないインスタンスのリスト。
ロードバランサのログが有効になっていて、Web サーバーのログレベルが DEBUG かまたは verbose メッセージを出力するように設定されている場合、ロードバランサは Web サーバーのログファイルに HTTP セッション ID を記録します。したがって、ロードバランサプラグインをホストしている Web サーバーが DMZ 内にある場合、本稼動環境では DEBUG または同等のログレベルを使用しないでください。
ログレベル DEBUG を使用する必要がある場合は、loadbalancer.xml で require-monitor-data プロパティーを false に設定して、ロードバランサのログを無効にしてください。
Web サーバーのログオプションを設定します。この手順は、Web サーバーによって異なります。
ロードバランサ設定の「監視」オプションを true に設定します。
asadmin create-http-lb-config コマンドを使用して最初にロードバランサ設定を作成する際に監視を true に設定するか、asadmin set コマンドを使用してあとから true に設定します。デフォルトでは、監視は無効になっています。
ロードバランサプラグインのログメッセージの形式は、次のとおりです。
HTTP 要求の開始時には、次の情報が含まれます。
RequestStart Sticky(New) <req-id> <time-stamp> <URL>
タイムスタンプの値は、1970 年 1 月 1 日からの時間がミリ秒単位で表されます。
RequestStart New 123456 602983 http://austen.sun.com/Webapps-simple/servlet/Example1
HTTP 要求の最後には、RequestExit メッセージが次のように表示されます。
RequestExit Sticky(New) <req-id> <time-stamp> <URL> <listener-id> <response-time> Failure-<reason for error>(incase of a failure)
次に例を示します。
RequestExit 新規 123456 603001 http://austen.sun.com/Webapps-simple/servlet/Example1 http://austen:2222 18
RequestExit メッセージでは response-time は、要求の合計ターンアラウンドタイムをロードバランサプラグインの側からミリ秒単位で表します。
正常ではないインスタンスのリストは、次のとおりです。
UnhealthyInstances <cluster-id> <time-stamp> <listener-id>, <listener-id>...
次に例を示します。
UnhealthyInstances cluster1 701923 http://austen:2210, http://austen:3010
フェイルオーバーされた要求のリストは、次のとおりです。
FailedoverRequest <req-id> <time-stamp> <URL> <session-id> <failed-over-listener-id> <unhealthy-listener-id>
次に例を示します。
FailedoverRequest 239496 705623 http://austen.sun.com/Apps/servlet/SessionTest 16dfdac3c7e80a40 http://austen:4044 http://austen:4045