Sun ロゴ      前へ      目次      次へ     

Sun Java System Application Server Enterprise Edition 8.1 2005Q1 管理ガイド

第 3 章
ロードバランスとフェイルオーバーの設定

この章では、Sun Java System Application Server の HTTP 要求のロードバランスの設定方法について説明します。また、ロードバランサによって制御されるサーバーインスタンス間のフェイルオーバーの設定方法についても説明します。さらに、RMI-IIOP ロードバランスとフェイルオーバーについても説明します。

この章には次の節が含まれています。


HTTP ロードバランスとフェイルオーバーについて

HTTP ロードバランスとフェイルオーバー

ロードバランスの目的は、スタンドアロンまたはクラスタ化された複数の Sun Java System Application Server インスタンスの間でワークロードを均等に分散させ、その結果、システム全体のスループットを増加することです。

ロードバランサを使用しても、1 つのインスタンスから別のインスタンスへのフェイルオーバーを要求できます。HTTP セッションの情報を持続させるために、HTTP セッションの持続性を設定します。詳細については、「可用性とセッション持続性の設定」を参照してください。

管理コンソールではなく、asadmin ツールを使用して、HTTP ロードバランスを設定します。

HTTP ロードバランスに対する要件

HTTP 要求にロードバランサプラグインを使用するには、次の要件を満たす必要があります。

割り当て要求と非割り当て要求について

最初に HTTP クライアントからロードバランサに要求が入ってきた時点で、その要求は新規セッションの要求となります。新しいセッションに対する要求は、非割り当て要求と呼ばれます。ロードバランサはこの要求を、ラウンドロビンアルゴリズムに従って、クラスタ内のアプリケーションサーバーインスタンスにルーティングします。詳細については、「HTTP ロードバランスアルゴリズム」を参照してください。

セッションがアプリケーションサーバーインスタンスに作成されると、ロードバランサは、そのセッションに関するすべての後続要求を特定のインスタンスにだけルーティングします。既存のセッションに対する要求は、割り当てまたはスティッキ要求と呼ばれます。

HTTP ロードバランスアルゴリズム

Sun Java System Application Server のロードバランサは、スティッキラウンドロビンアルゴリズムを使用して、着信 HTTP および HTTPS 要求をロードバランスします。特定のセッションに対するすべての要求は、同じアプリケーションサーバーインスタンスに送信されます。スティッキロードバランサでは、セッションデータは、クラスタ内の全インスタンスに分散されるのではなく、単一のアプリケーションサーバーにキャッシュされます。

したがって、スティッキラウンドロビンスキーマでは、パフォーマンス上、大きなメリットが得られます。これは、純粋なラウンドロビンによる、より均一化された分散負荷によるメリット以上のものです。

スティッキラウンドロビンロードバランスアルゴリズムについて

新しい HTTP 要求がロードバランサプラグインに送信されると、単純なラウンドロビンスキームに基づいてアプリケーションサーバーインスタンスに転送されます。次にこの要求は、Cookie または URL を明示的に書き換えることによって、この特定のアプリケーションサーバーに「固定」されます。

スティッキ情報から、ロードバランサプラグインは、まず、以前に要求が転送されたインスタンスを判断します。そのインスタンスが正常であるとわかると、ロードバランサプラグインは、要求をその特定のアプリケーションサーバーインスタンスに転送します。したがって、特定のセッションに対するすべての要求が同じアプリケーションサーバーインスタンスに送信されます。

ロードバランサプラグインは次の方法を使ってセッションのスティッキ度を判断します。

Cookie に基づいた方法

Cookie に基づいた方法では、ロードバランサプラグインは、個別の Cookie を使って、ルート情報を記録します。


Cookie に基づいた方法を使用するには、HTTP クライアントが Cookie をサポートしている必要があります。


URL の明示的書き換えによる方法

URL を明示的に書き換えて、スティッキ情報を URL に追加します。この方法は、HTTP クライアントが Cookie をサポートしない場合でも機能します。

ロードバランスとフェイルオーバーのサンプルアプリケーション

次のディレクトリには、ロードバランスとフェイルオーバーを示すサンプルアプリケーションが含まれています。

install_dir/samples/ee-samples/highavailability install_dir/samples/ee-samples/failover

ee-samplesディレクトリには、サンプルを実行する環境を設定するための情報も含まれています。

HTTP ロードバランス設定の概要

asadmin ツールを使用して、環境に対するロードバランスを設定します。次の手順に従います。

  1. Web サーバーと Application Server インスタンスとクラスタの両方、またはどちらかのインストールと設定など、「HTTP ロードバランスに対する要件」を完了します。
  2. asadmin コマンドの create-http-lb-config を使用して、ロードバランサ設定を作成します。
  3. 作成したロードバランサのクラスタとスタンドアロンサーバーインスタンスへの参照を追加し、asadmin create-http-lb-ref を使用して管理するようにします。
  4. ターゲットを指定してロードバランサ設定を作成しており、そのターゲットが、ロードバランサが参照する唯一のクラスタまたはスタンドアロンサーバーインスタンスである場合は、この手順を飛ばしてください。

  5. asadmin enable-http-lb-server を使用してロードバランサが実行するクラスタまたはスタンドアロンサーバーインスタンスの参照を有効にします。
  6. asadmin enable-http-lb-application を使用してロードバランスするアプリケーションを有効にします。
  7. これらのアプリケーションは、ロードバランサが参照するクラスタまたはスタンドアロンインスタンスで使用するために、事前に配備および有効にしておく必要があります。ロードバランスを有効にする手順は、使用可能にする手順とは別です。

  8. asadmin create-health-checker を使用して、診断プログラムを作成します。
  9. 診断プログラムは、正常でないサーバーインスタンスを監視し、それらが正常に戻ったときにロードバランサが新しい要求を送信できるようにします。

  10. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルを生成します。
  11. このコマンドは、Sun Java System Application Server に同梱されているロードバランサプラグインと一緒に使用する設定ファイルを生成します。

  12. ロードバランサ設定ファイルを、ロードバランサプラグイン設定ファイルが格納されている Web サーバーの config ディレクトリにコピーします。


HTTP ロードバランスのための Web Server の設定

Web サーバーの設定について

ロードバランサプラグインインストールプログラムは、Web サーバーの設定ファイルに対していくつかの変更を加えます。これらの変更は、Web サーバーによって異なります。


ロードバランサプラグインは、サポートされている Web サーバーを実行するマシン上に、Sun Java System Application Server Enterprise Edition とともにインストールすることも、または個別にインストールすることもできます。

インストール手順の詳細については、『Sun Java System Application Server Installation Guide』を参照してください。


Sun Java System Web Server に対する変更

インストールプログラムは、Sun Java System Web Server の設定ファイルに対して次のような変更を加えます。

  1. 次のようなロードバランサプラグイン固有のエントリを、Web サーバーインスタンスの magnus.conf ファイルに追加します。
  2. ##EE lb-plugin
    Init fn="load-modules" shlib="
    web_server_install_dir/plugins/lbplugin/bin/libpassthrough.so" funcs="init-passthrough,service-passthrough,name-trans-passthrough" Thread="no"

    Init fn="init-passthrough"

    ##end addition for EE lb-plugin

  3. 次のようなロードバランサプラグイン固有のエントリを、Web サーバーインスタンスの obj.conf ファイルに追加します。
  4. <Object name=default> NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="web_server_install_dir/web_server_instance/config/loadbalancer.xml" <Object name="lbplugin">
    ObjectType fn="force-type" type="magnus-internal/lbplugin"
    PathCheck fn="deny-existence" path="*/WEB-INF/*"
    Service type="magnus-internal/lbplugin" fn="service-passthrough"
    Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
    </object>

    lbplugin は、Object を一意に識別する名前であり、web_server_install_dir/web_server_instance/config/loadbalancer.xml は、ロードバランサが動作するように設定されている仮想サーバーの XML 設定ファイルの場所です。

インストールが完了したら、「HTTP ロードバランス設定の概要」で説明されている方法でロードバランサを設定します。

Apache Web サーバーに対する変更

ロードバランサプラグインを Apache にインストールする前に、付録 A 「Apache Web サーバーのコンパイルと設定」の Apache のコンパイルと設定に関する情報を参照してください。

インストーラによって行われる変更

ロードバランサプラグインインストールプログラムは、必要なファイルを、Web サーバーのルートディレクトリの下の libexec (Apache 1.3) または modules (Apache 2.0) フォルダに抽出します。このプログラムはまた、次のようなロードバランサプラグイン固有のエントリを、Web サーバーインスタンスの httpd.conf ファイルに追加します。

<VirtualHost machine_name:443>

##Addition for EE lb-plugin

LoadFile /usr/lib/libCstd.so.1

LoadModule apachelbplugin_module libexec/mod_loadbalancer.so
#AddModule mod_apachelbplugin.cpp
<IfModule mod_apachelbplugin.cpp>
        config-file
webserver_instance/conf/loadbalancer.xml
locale en
</IfModule>

<VirtualHost machine_ip_address>
DocumentRoot "
webserver_instance/htdocs"
ServerName server_name
</VirtualHost>

##END EE LB Plugin ParametersVersion 7


  • Apache 1.3 で、複数の Apache の子プロセスが動作している場合、各プロセスは固有のロードバランスラウンドロビンシーケンスを使用しています。

    たとえば、Apache の子プロセスが 2 つ動作していて、ロードバランスプラグインが 2 つのアプリケーションサーバーインスタンスに対してロードバランスする場合、最初の要求はインスタンス #1 に送信され、2 番目の要求もインスタンス #1 に送信されます。3 番目の要求はインスタンス #2 に送信され、4 番目の要求も同じくインスタンス #2 に送信されます。このパターンが繰り返されます (インスタンス 1、インスタンス 1、インスタンス 2、インスタンス 2、以下同様)。

    この動作は、インスタンス 1、インスタンス 2、インスタンス 1、インスタンス 2、というユーザーが予想する順序とは異なります。Sun Java System Application Server では、Apache 用のロードバランスプラグインは Apache プロセスごとにロードバランサインスタンスをインスタンス化して、独立したロードバランスシーケンスを作成します。
  • --with-mpm=worke オプションを使用してコンパイルした場合、Apache 2.0 は動作をマルチスレッド化します。

インストール後の変更

Microsoft Windows に対する追加の変更

プラグインのインストール後に Microsoft Windows 上で Apache を実行している場合は、一部の環境変数を変更する必要があります。

「スタート」 - >「設定」 - >「コントロールパネル」 - >「システム」 - >「詳細」 - >「環境変数」 - >「システム環境変数」を選択して、Path 環境変数に新しいパスを追加します。Path 変数に、次の内容が含まれるように編集します。

application_server_install_dir/bin

さらに、Apache Web サーバーを起動する前に、環境変数 NSPR_NATIVE_THREADS_ONLY を 1 に設定します。

「環境変数」ウィンドウで、「システム環境変数」の下の「新規」をクリックします。次の名前と値のペアを入力します。

変数名: NSPR_NATIVE_THREADS_ONLY

変数値: 1

マシンを再起動します。

Microsoft IIS に対する変更

Microsoft Internet Information Services (IIS) がロードバランサプラグインを使用するように設定するには、Windows Internet Services Manager の特定のプロパティを変更します。Internet Services Manager は、「コントロールパネル」フォルダの「管理ツール」フォルダに置かれています。

Sun Java System Application Server をインストールしたら、次の変更を行います。

  1. Internet Services Manager を開きます。
  2. プラグインを有効にする Web サイトを選択します。この Web サイトは通常、デフォルトの Web サイトとして指定されます。
  3. この Web サイト上で右クリックして「プロパティ」を選択し、「プロパティ」ノートブックを開きます。
  4. 新しい ISAPI フィルタを追加するには、「ISAPI フィルタ」タブを開いて「追加」をクリックし、次の手順に従います。
    1. 「フィルタ名」フィールドに、「Application Server」と入力します。
    2. 「実行ファイル」フィールドに、「C:¥Inetpub¥wwwroot¥sun-passthrough¥sun-passthrough.dll」と入力します。
    3. 「了解」をクリックして、「プロパティ」ノートブックを閉じます。
  5. 新しい仮想ディレクトリを作成および設定します。
    1. デフォルトの Web サイト上で右クリックして「新規」を選択し、「仮想ディレクトリ」を選択します。
    2. 「仮想ディレクトリの作成ウィザード」が開きます。

    3. 「エイリアス」フィールドに、「sun-passthrough」と入力します。
    4. 「ディレクトリ」フィールドに、「C:¥Inetpub¥wwwroot¥sun-passthrough」と入力します。
    5. 「実行パーミッション」チェックボックスにチェックマークを付けます。ほかのすべてのパーミッション関連のチェックボックスは、チェックしないでおきます。
    6. 「完了」をクリックします。
  6. システムの Path 環境変数に、sun-passthrough.dll ファイル および application_server_install_dir/bin のパスを追加します。マシンを再起動します。
  7. Web サーバーを停止してから起動して、新しい設定を反映させます。
  8. Web サーバーを停止するには、Web サイト上で右クリックして「停止」を選択します。Web サーバーを起動するには、Web サイト上で右クリックして「起動」を選択します。

    次に、Web ブラウザに以下のように入力して Web アプリケーションのコンテキストルートにアクセスします。

    http://webserver_name/web_application

    webserver_name は Web サーバーのホスト名または IP アドレスで、/web_applicationC:¥Inetpub¥wwwroot¥sun-passthrough¥sun-passthrough.properties ファイルに一覧表示したコンテキストルートです。Web サーバー、ロードバランサプラグイン、および Application Server が正常に動作していることを確認します。

インストーラは、sun-passthrough.properties 内に次のプロパティを自動的に設定します。デフォルト値は変更可能です。

表 3-1 自動的に設定される Microsoft IIS の sun-passthrough プロパティ

プロパティ

定義

デフォルト値

lb-config-file

ロードバランサ設定ファイルへのパス

IIS_www_root¥sun-passthrough¥loadbalancer.xml

log-file

ロードバランサログファイルへのパス

IIS_www_root¥sun-passthrough¥lb.log

log-level

Web サーバーのログレベル

INFO

複数の Web サーバーインスタンスの設定

Sun Java System Application Server インストーラでは、1 台のマシンに複数のロードバランサプラグインをインストールできません。1 台のマシンの 1 つまたは複数のクラスタ内に、ロードバランサプラグインとともに複数の Web サーバーを置くには、いくつかの手順を手動で実行してロードバランサプラグインを設定する必要があります。

  1. 「Sun Java System Web Server に対する変更」「Apache Web サーバーに対する変更」、および「Microsoft IIS に対する変更」 で説明されている方法で、ロードバランサプラグインを使用する新しい Web サーバーインスタンスを設定します。
  2. 既存の Web サーバーインスタンスの config ディレクトリから、sun-loadbalancer_1_1.dtd ファイルを新しいインスタンスの config ディレクトリにコピーします。
  3. 同じロードバランサ設定を使用するために、既存の Web サーバーインスタンスの config ディレクトリから、loadbalancer.xml ファイルを新しいインスタンスの config ディレクトリにコピーします。
  4. 異なるロードバランサ設定を使用する場合は、次の手順に従います。
    1. asadmin create-http-lb-config を使用して、新しいロードバランサ設定を作成します。
    2. asadmin export http-lb-config を使用して、新しい設定を loadbalancer.xml ファイルにエクスポートします。
    3. loadbalancer.xml ファイルを、新しい Web サーバーの config ディレクトリにコピーします。
    4. ロードバランサ設定を作成し、loadbalancer.xml ファイルにエクスポートすることについて詳しくは、「HTTP ロードバランサ設定タスク」を参照してください。


HTTP ロードバランサ設定タスク

HTTP ロードバランサ設定の作成

ロードバランサ設定は、ロードバランサを定義する domain.xml ファイル内で名前を付けられている設定です。

ロードバランス設定は非常に柔軟性があります。

asadmin コマンド create-http-lb-config を使用して、設定を作成します。次のパラメータを指定します。

詳細については、create-http-lb-configdelete-http-lb-config、および list-http-lb-configs のドキュメントを参照してください。

HTTP ロードバランサ参照の作成

ロードバランサでスタンドアロンのサーバーまたはクラスタに対する参照を作成する場合、ロードバランサが制御するターゲットサーバーまたはクラスタの一覧に、参照先のサーバーおよびクラスタが追加されます。この場合でも、参照先のサーバーまたはクラスタに対する要求を負荷分散するには、enable-http-lb-server を使用してそのサーバーまたはクラスタを有効化する必要があります。ターゲットを指定してロードバランサ設定を作成した場合、そのターゲットはすでに参照として追加されています。

create-http-lb-ref を使用して参照を作成します。ロードバランサ設定名と、ターゲットサーバーインスタンスまたはクラスタを指定する必要があります。

参照を削除するには、delete-http-lb-ref を使用します。参照を削除する前に、disable-http-lb-server を使用して参照先のサーバーまたはクラスタを無効にする必要があります。

詳細については、create-http-lb-ref および delete-http-lb-ref のドキュメントを参照してください。

ロードバランスのためのサーバーインスタンスの有効化

サーバーインスタンスまたはクラスタへの参照を作成したら、enable-http-lb-server を使用してサーバーインスタンスまたはクラスタを有効にします。ロードバランサ設定の作成時にサーバーインスタンスまたはクラスタをターゲットとして使用した場合は、それを有効にする必要があります。

詳細については、enable-http-lb-server のドキュメントを参照してください。

ロードバランスのためのアプリケーションの有効化

ロードバランサによって管理されるすべてのサーバーは、アプリケーションの同じセットが配備されているなど、同一の設定である必要があります。アプリケーションが配備されてアクセス可能になると (配備手順の実行中または完了後)、ロードバランスを有効にする必要があります。アプリケーションでロードバランスが有効化されていない場合、そのアプリケーションが配備されているサーバーへの要求が負荷分散およびフェイルオーバーされていても、アプリケーションへの要求は負荷分散およびフェイルオーバーされません。

アプリケーションを有効にする際に、アプリケーション名とターゲットを指定します。ロードバランサが複数のターゲット (2 つのクラスタなど) を管理している場合は、すべてのターゲットでアプリケーションを有効にしてください。

詳細については、enable-http-lb-application のオンラインヘルプを参照してください。

新しいアプリケーションを配備する場合にも、アプリケーションでロードバランスを有効にして、再度ロードバランサ設定をエクスポートする必要があります。

HTTP 診断プログラムの作成

ロードバランサの診断プログラムは、設定されているApplication Serverインスタンスで正常ではないとしてマークされているものをすべて、定期的にチェックします。診断プログラムは必須ではありませんが、このプログラムが存在しない場合、または無効になっている場合は、正常でないインスタンスの定期的な診断プログラムは実行されません。

ロードバランサの診断プログラムメカニズムは、HTTP を使用してアプリケーションサーバーと通信します。診断プログラムは、指定された URL に HTTP 要求を送信し、応答を待ちます。HTTP 応答ヘッダー内の状態コードが 100 〜 500 の間であれば、インスタンスが正常であることを示します。

診断プログラムの作成

診断プログラムを作成するには、asadmin create-http-health-checker コマンドを使用します。次のパラメータを指定します。

アプリケーションサーバーインスタンスが正常でないとマークされている場合、診断プログラムが正常ではないインスタンスをポーリングして、インスタンスが正常になったかどうかを判断します。診断プログラムは、指定された URL を使用して正常でないアプリケーションサーバーインスタンスをすべてチェックし、それらが正常な状態に戻っているかどうかを判断します。

診断プログラムにより、正常ではないインスタンスが正常になったことが確認されると、そのインスタンスが正常なインスタンスのリストに加えられます。

詳細については、create-http-health-checker および delete-http-health-checker のドキュメントを参照してください。

正常なインスタンス用診断プログラムの追加プロパティ

create-http-health-checkerによって作成された診断プログラムは、正常ではないインスタンスのみをチェックします。正常なインスタンスを定期的にチェックするには、エクスポートした loadbalancer.xml ファイルに追加のプロパティをいくつか設定します。


これらのプロパティは、loadbalancer.xml ファイルをエクスポート後に手動で編集することによってのみ設定できます。同機能を持つ asadmin コマンドはありません。


正常なインスタンスをチェックするには、次のプロパティを設定します。

表 3-2 診断プログラムのプロパティ

プロパティ

定義

active-healthcheck-enabled

サーバーインスタンスが正常であるかどうかを調べるために、それらに対して Ping を実行するかどうかを示す true/false フラグ。サーバーインスタンスに対して Ping を実行するには、このフラグを true に設定します。

number-healthcheck-retries

ロードバランサの診断プログラムが、応答しないサーバーインスタンスを正常でないとマークするまでに、それらに対して Ping を実行する回数を指定します。有効な範囲は 1 〜 1000 です。デフォルト値は 3 に設定します。

loadbalancer.xml ファイルを編集して、プロパティを設定します。次に例を示します。

<property name="active-healthcheck-enabled" value="true"/> <property name="active-healthcheck-retries" value="3"/>

これらのプロパティを追加し、続いて loadbalancer.xml ファイルをふたたび編集およびエクスポートする場合、新しくエクスポートされた設定には追加のプロパティが含まれないため、これらを再度ファイルに追加する必要があります。

ロードバランサ設定ファイルのエクスポート

Sun Java System Application Server に同梱されているロードバランスプラグインは、loadbalancer.xml という設定ファイルを使用します。asadmin ツールを使用して、domain.xml ファイルにロードバランサ設定を作成します。ロードバランス環境を設定したら、その環境をファイルにエクスポートします。

  1. asadmin コマンド export-http-lb-config を使用して、loadbalancer.xml ファイルをエクスポートします。
  2. 特定のロードバランサ設定の loadbalancer.xml ファイルをエクスポートします。パスまたは別のファイル名を指定できます。ファイル名を指定しない場合、ファイルには loadbalancer.xml.load_balancer_config_name という名前が付けられます。パスを指定しない場合、ファイルは application_server_install_dir/domains/domain_name/generated ディレクトリに作成されます。

    Windowd でパスを指定する場合は、パスを引用符で囲みます。たとえば、"c:¥sun¥AppServer¥loadbalancer.xml" のように指定します。

  3. エクスポートしたロードバランサ設定ファイルを、Web サーバーの設定ディレクトリにコピーします。
  4. たとえば、Sun Java System Web Server の場合、コピー先は web_server_root/config となります。

    Web サーバーの設定ディレクトリ内のロードバランサ設定ファイルには、loadbalancer.xml という名前を付ける必要があります。loadbalancer.xml.load_balancer_config_name などの別の名前を付けた場合は、変更する必要があります。

HTTP ロードバランサ設定の変更

サーバーに対する参照の作成または削除、新しいアプリケーションの配備、サーバーまたはアプリケーションの有効化 / 無効化などによって HTTP ロードバランサ設定を変更する場合は、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーします。詳細については、「ロードバランサ設定ファイルのエクスポート」を参照してください。

ロードバランサプラグインは、ロードバランサ設定で指定した再読み込み間隔に従って、更新された設定を定期的にチェックします。指定した時間が経過して、ロードバランサが新しい設定ファイルを検出した場合は、その設定を使用して再読み込みが開始されます。

動的再設定の有効化

動的な再設定が有効になっている場合、ロードバランサプラグインは設定の更新を定期的にチェックします。動的再設定を有効にするには、次の手順に従います。

これらの設定を変更したら、ロードバランサ設定ファイルを再度エクスポートし、Web サーバーの config ディレクトリにコピーします。

以前は無効に設定されていた動的再設定を有効にするには、Web サーバーを再起動する必要があります。


  • ロードバランサがそれ自体の再設定を試みているときにハードディスク読み込みエラーが発生した場合、ロードバランサは現在メモリに格納されている設定を使用します。ロードバランサはまた、既存の設定を上書きする前に、変更された設定データが必ず DTD に準拠するようにします。

    ディスク読み込みエラーが発生すると、Web サーバーのエラーログファイルに警告メッセージが記録されます。

    Sun Java System Web Server のエラーログは、次の場所にあります。web_server_install_dir/webserver_instance/logs/

サーバーインスタンスまたはクラスタの無効化 (停止)

何らかの理由でアプリケーションサーバーを停止する前には、インスタンスが要求の処理を完了する必要があります。サーバーインスタンスまたはクラスタを正常に無効にするプロセスは、停止と呼ばれます。

ロードバランサは、アプリケーションサーバーインスタンスを停止するために、次のポリシーを使用します。

サーバーインスタンスまたはクラスタを無効にするには、次の手順に従います。

  1. asadmin disable-http-lb-server を実行して、タイムアウトを分単位で設定します。
  2. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  3. エクスポートした設定を Web サーバーの config ディレクトリにコピーします。
  4. サーバーインスタンスを停止します。

アプリケーションの無効化 (停止)

Web アプリケーションの配備を取り消す前に、アプリケーションが要求の処理を完了する必要があります。アプリケーションを正常に無効にするプロセスは、停止と呼ばれます。

ロードバランサは、アプリケーションを停止するために、次のポリシーを使用します。

ロードバランサが参照するすべてのサーバーインスタンスまたはクラスタから、あるアプリケーションを無効にする場合、無効化されたアプリケーションのユーザーは、アプリケーションが再度有効化されるまでサービスを受けられません。

1 つのサーバーインスタンスまたはクラスタからアプリケーションを無効にして、別のサーバーインスタンスまたはクラスタでは有効にする場合、ユーザーは引き続きアプリケーションにアクセスできます。

アプリケーションを無効にするには、次の手順に従います。

  1. asadmin disable-http-lb-application を実行して、タイムアウト (分単位)、無効にするアプリケーションの名前、および、無効化を実行するターゲットクラスタまたはインスタンスを指定します。
  2. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  3. エクスポートした設定を Web サーバーの config ディレクトリにコピーします。

HTTP および HTTPS セッションのフェイルオーバーの設定

HTTP/HTTPS セッションが接続されていた元のアプリケーションサーバーインスタンスが無効化された場合、ロードバランサプラグインは、そのセッションを別のアプリケーションサーバーインスタンスにフェイルオーバーします。この節では、HTTP/HTTPS ルーティングとセッションフェイルオーバーを有効にするようにロードバランサプラグインを設定する方法について説明します。

HTTP セッションの持続性の設定については、「可用性とセッション持続性の設定」を参照してください。

この節では、次の項目について説明します。

HTTPS ルーティングについて

HTTP または HTTPS のどちらでも、すべての着信要求は、ロードバランサプラグインによってアプリケーションサーバーインスタンスにルーティングされます。ただし、HTTPS ルーティングが有効になっている場合、ロードバランサプラグインは HTTPS ポートのみを使用して HTTPS 要求をアプリケーションサーバーに転送します。HTTPS ルーティングは、新しい要求とスティッキ要求の両方について実行されます。

HTTPS 要求が受信され、処理中のセッションがない場合、ロードバランサプラグインは設定されている HTTPS ポートを使用して使用可能なアプリケーションサーバーインスタンスを選択し、要求をそのインスタンスに転送します。

処理中の HTTP セッションで、同じセッションに対して新しい HTTPS 要求が受信された場合、HTTP セッション中に保存されたセッションおよびスティッキ情報を使用して HTTPS 要求がルーティングされます。新しい HTTPS 要求は、最後の HTTP 要求が処理された同じサーバーにルーティングされます。ただし、HTTPS ポートが使用されます。

HTTPS ルーティングの設定

create-http-lb-config コマンドの httpsrouting オプションは、ロードバランスに関わるすべてのアプリケーションサーバーに対して HTTPS ルーティングが有効か無効かを制御します。このオプションが false に設定されている場合、すべての HTTP および HTTPS 要求は HTTP として転送されます。新しいロードバランサ設定を作成する場合、または、作成後に asadmin set コマンドを使用して変更する場合には、このオプションを true に設定してください。


  • HTTPS ルーティングを動作させるには、1 つまたは複数の HTTPS リスナーを設定する必要があります。
  • https-routingtrue に設定されていて、クラスタ内に正常な HTTPS リスナーが存在していない状態で新しい要求またはスティッキ要求が着信した場合、その要求はエラーを生成します。

HTTP/HTTPS 要求のロードバランスにおける既知の問題

次のリストでは、HTTP/HTTPS 要求の処理に関するロードバランサの制限について説明します。

べき等 URL の設定

配備されたアプリケーションの可用性を強化するには、ロードバランサによって処理されたすべてのアプリケーションサーバーインスタンスに、失敗したべき等の HTTP 要求を再試行する環境を設定します。このオプションは、検索要求の再試行など、読み取り専用の要求に使用されます。

べき等要求とは再試行時にアプリケーションに変更や不整合をもたらさないタイプの要求です。HTTP の場合、GET などの一部のメソッドはべき等的ですが、POST などその他のメソッドはそうではありません。べき等 URL の再試行では、サーバーまたはデータベースの値が変更されてはいけません。ユーザーが受信する応答が変更されるだけです。

べき等要求の例としては、検索エンジンクエリーやデータベースクエリーがあります。基礎となる原則は、再試行によってデータの更新や変更が発生しないことです。

sun-web.xml ファイルに、べき等 URL を設定します。ロードバランサ設定をエクスポートする場合、べき等 URL の情報は自動的に loadbalancer.xml ファイルに追加されます。

べき等 URL の設定の詳細については、『Developer's Guide』を参照してください。

HTML エラーページの設定

独自のエラーページやエラーページへの URL を指定して、それらをエンドユーザーに対して表示することができます。エラーページを指定すると、エラー報告に関して設定されているその他のメカニズムはすべて無効になります。

sun-web.xml ファイルに、HTML エラーページを設定します。ロードバランサ設定をエクスポートする場合、HTML エラーページの情報は自動的に sun-web.xml ファイルから loadbalancer.xml ファイルに追加されます。

HTML エラーページの設定の詳細については、『Developer's Guide』を参照してください。


HTTP ロードバランサプラグインの監視

ログメッセージの設定

ロードバランサプラグインは、Web サーバーのログメカニズムを使用してログメッセージを記録します。Application Server のデフォルトのログレベルは、Sun Java System Web Server (INFO)、Apache Web Server (WARN)、および Microsoft IIS (INFO) のデフォルトのログレベルに設定されています。アプリケーションサーバーのログレベル - FINEFINER、および FINEST は、Web サーバーの DEBUG レベルに対応します。

これらのログメッセージは Web サーバーのログファイルに書き込まれます。これらは raw データ形式で、スクリプトを使用して解析されるかまたは表計算ドキュメントにインポートされて、必要なメトリックスを計算します。

ログメッセージのタイプ

ロードバランサプラグインは、次の 3 種類のログメッセージセットを生成します。

ロードバランサコンフィギュレータログメッセージ

これらのメッセージは、べき等 URL とエラーページ設定を使用している場合に記録されます。

べき等 URL のパターン設定の出力には、次の情報が含まれます。

エラーページの URL 設定の出力には、次の情報が含まれます (ログレベルが WARN に設定されている場合)。

CONFxxxx: Web モジュール <web-module> の error-url が無効です

要求ディスパッチおよび実行時ログメッセージ

これらのログメッセージは、要求が負荷分散およびディスパッチされている間に生成されます。

コンフィギュレータエラーメッセージ

これらのエラーは、参照先のカスタムエラーページがなくなっているなど、設定上の問題がある場合に表示されます。

監視の設定

次の手順を実行して、ロードバランサプラグインログメッセージを有効にします。

  1. Web サーバーのログオプションを設定します。
    1. Sun Java System Web Server の管理コンソールで、「Magnus Editor」タブを表示します。
    2. Log Verbose」オプションを 「On」 に設定します。

    3. Apache Web Server の場合は、ログレベルを DEBUG に設定します。
    4. Microsoft IIS の場合は、sun-passthrough.properties ファイルでログレベルを FINE に設定します。
  2. ロードバランサ設定の「監視」オプションを true に設定します。
  3. asadmin create-http-lb-config コマンドを使用して最初にロードバランサ設定を作成する際に監視を true に設定するか、asadmin set コマンドを使用して後から true に設定します。デフォルトでは、監視は無効になっています。

ロードバランサプラグインは、次の情報をログに記録します。

メッセージの監視について

ロードバランサプラグインのログメッセージの形式は、次のとおりです。


アプリケーションのアップグレード

段階的アップグレードについて

ユーザーへのサービスを停止することなくアプリケーションをアップグレードするには、1 つのサーバーまたはクラスタ上にあるアプリケーションを一度にアップグレードします。クラスタはバージョンが混在している環境を透過的に維持しますが、ユーザーはアップグレードが行われていることに気づきません。このタイプのアップグレードを段階的アップグレードと呼びます。

段階的アップグレードは、旧新バージョンのアプリケーションに互換性があり、両方を同時に実行できる場合のみ可能です。セッション情報には互換性が必要です。混在モードの段階的アップグレードを、単一のスタンドアロンクラスタまたは複数のクラスタで実行します。

混在モードの環境での段階的アップグレードは、データベーススキーマの変更など、アプリケーションに大きな変更がある場合は、実行できません。そのような場合は、アップグレード中にアプリケーションを停止してください。アプリケーションの配備を取り消して、アップグレードしたアプリケーションを同じ名前で再配備します。

単一のスタンドアロンクラスタでのアップグレード

ほかのクラスタと設定を共有しないクラスタである単一のスタンドアロンクラスタでアプリケーションをアップグレードするには、次のようにします。

  1. 旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
  2. ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。

  3. クラスタの動的再設定が有効の場合はオフにします。
  4. 管理コンソールで、次の手順を実行します。

    1. 「設定」ノードを開きます。
    2. クラスタの設定の名前をクリックします。
    3. 「システムプロパティの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。
    4. 「保存」をクリックします。
    5. asadmin と同機能を持つコマンドは、asadmin set です。構文は次のとおりです。

      asadmin set --user user --passwordfile password_file cluster_name-config.dynamic-reconfiguration-enabled=false

  5. ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
  6. asadmin enable-http-lb-application を使用して、インスタンスに対して再配備アプリケーションを有効にします。
  7. asadmin disable-http-lb-server を使用して、1 つのサーバーインスタンスを無効にします。
  8. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  9. エクスポートした設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。たとえば、Sun Java System Web Server の場合、コピー先は web_server_install_dir/https-host-name/config/loadbalancer.xml となります。
  10. タイムアウトが終了するまで、待機します。ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。
  11. クラスタ内のほかのインスタンスが実行中の間に、無効になっていたサーバーインスタンスを再起動します。再起動により、サーバーはドメインと同期し、アプリケーションを更新します。
  12. 再起動したサーバー上でアプリケーションをテストし、正しく動作していることを確認します。
  13. asadmin enable-http-lb-server を使用して、サーバーインスタンスを有効にします。
  14. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  15. 設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。
  16. クラスタ内の各インスタンスに対して、手順 5手順 13 を繰り返します。
  17. すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合、再びクラスタに対して動的再設定を有効にします。

2 つのクラスタのアップグレード

  1. 旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
  2. ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。

  3. 両方のクラスタの動的再設定が有効の場合はオフにします。
  4. 管理コンソールで、次の手順を実行します。

    1. 「設定」ノードを開きます。
    2. 1 つのクラスタの設定の名前をクリックします。
    3. 「システムプロパティの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。
    4. 「保存」をクリックします。
    5. 2 番目のクラスタに対して上記手順を繰り返します。
    6. asadmin と同機能を持つコマンドは、asadmin set です。構文は次のとおりです。

      asadmin set --user user --passwordfile password_file cluster_name-config.dynamic-reconfiguration-enabled=false

  5. ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
  6. asadmin enable-http-lb-application を使用して、クラスタに対して再配備したアプリケーションを有効にします。
  7. asadmin disable-http-lb-server を使用して、ロードバランサから 1 つのクラスタを無効にします。
  8. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  9. エクスポートした設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。たとえば、Sun Java System Web Server の場合、コピー先は web_server_install_dir/https-host-name/config/loadbalancer.xml となります。
  10. タイムアウトが終了するまで、待機します。ロードバランサのログファイルを監視して、クラスタがオフラインであることを確認します。
  11. ほかのクラスタが実行中の間に、無効となっていたクラスタを再起動します。再起動により、クラスタはドメインと同期し、アプリケーションを更新します。
  12. 再起動したクラスタ上でアプリケーションをテストし、正しく動作していることを確認します。
  13. asadmin enable-http-lb-server を使用して、クラスタを有効にします。
  14. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
  15. 設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。
  16. ほかのクラスタ内に対して、手順 5手順 13 を繰り返します。
  17. すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合、再び両方のクラスタに対して動的再設定を有効にします。


RMI-IIOP ロードバランスとフェイルオーバーについて

RMI-IIOP ロードバランスとフェイルオーバーに対する要件

Sun Javaa System Application Server は、RMI-IIOP を使用して、リモート EJB 参照とネームサービスオブジェクトの高可用性を提供します。これらの機能を使用する前に、環境が次の要件を満たす必要があります。

RMI-IIOP ロードバランスおよびフェイルオーバーアルゴリズムについて

Sun Java System Application Server は、RMI-IIOP パス上のリモート EJB 参照およびネームサービスオブジェクトのロードバランスに、ランダム化およびラウンドロビンアルゴリズムを採用します。

RMI-IIOP クライアントは最初に新しい InitialContext オブジェクトを作成すると、そのクライアントで利用可能な Application Server IIOP エンドポイントのリストが、ランダムに選ばれます。その InitialContext オブジェクトに対して、ロードバランサは、検索要求とほかの InitialContext 操作を、リストの最初のエンドポイントに命令します。最初のエンドポイントが利用できない場合、リストの 2 番目のエンドポイントが使用され、以下同様です。

クライアントが続けて新しい InitialContext オブジェクトを作成するたびに、エンドポイントリストがローテーションし、異なる IIOP エンドポイントが InitialContext 操作で使われます。

InitialContext オブジェクトによって確保される参照から Beans を入手または作成する場合、それらの Beans は、InitialContext オブジェクトに割り当てられた IIOP エンドポイントを処理する Application Server インスタンスで作成されます。それらの Beans に対する参照には、クラスタ内のすべての Application Server インスタンスの IIOP エンドポイントアドレスが含まれます。

プライマリエンドポイントは、Bean を検索または作成するのに使用される InitialContext エンドポイントに対応する Bean エンドポイントです。クラスタ内のほかの IIOP エンドポイントは、代替エンドポイントとして指定されています。Bean のプライマリエンドポイントが利用できなくなると、その Bean での追加の要求は、代替エンドポイントの 1 つにフェイルオーバーされます。

RMI-IIOP のサンプルアプリケーション

次のディレクトリには、ACC とともに、または ACC なしで RMI-IIOP フェイルオーバーを使用する方法を示すサンプルアプリケーションが含まれています。

install_dir/samples/ee-samples/failover/apps/sfsbfailover

ACC とともに、または ACC なしでアプリケーションを実行する方法については、このサンプルに付属している index.html ファイルを参照してください。ee-samples ディレクトリには、サンプルを実行するための環境の設定方法に関する情報も含まれます。



前へ      目次      次へ     


Copyright 2004 - 2005 Sun Microsystems, Inc. All rights reserved.