Sun Java System Application Server Enterprise Edition 8.1 2005Q2 高可用性 (HA) 管理ガイド

- Previous: 第 3 章 高可用性データベースの管理
- Next: 第 5 章 Application Server クラスタの使用

# 第 4 章 負荷分散とフェイルオーバーの設定

この節では、HTTP ロードバランサプラグインについて説明します。ここで説明する内容は次のとおりです。

- 「ロードバランサの動作」

- 「HTTP 負荷分散の設定」

- 「負荷分散のための Web Server の設定」

- 「ロードバランサの設定」

- 「HTTP および HTTPS のフェイルオーバーの設定」

- 「可用性を低下させないアプリケーションのアップグレード」

# ロードバランサの動作

ロードバランサの目的は、スタンドアロンまたはクラスタ化された複数の Application Server インスタンスの間でワークロードを均等に分散させ、それにより、システムの全体的なスループットを向上させることです。

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

負荷分散の設定に関する完全な手順については、『Sun Java System Application Server 高可用性 (HA) 管理ガイド』を参照してください。

管理コンソールではなく、asadmin ツールを使用して、HTTP 負荷分散を設定します。

- 「割り当て要求と非割り当て要求」

- 「HTTP 負荷分散アルゴリズム」

- 「サンプルアプリケーション」

関連項目

- 「負荷分散を設定するための前提条件」

- 「割り当て要求と非割り当て要求」

- 「HTTP 負荷分散アルゴリズム」

- 「負荷分散を設定するための手順」

## 割り当て要求と非割り当て要求

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

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

## HTTP 負荷分散アルゴリズム

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

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

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

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

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

- Cookie に基づいた方法: ロードバランサプラグインは、個別の Cookie を使用してルート情報を記録します。Cookie に基づいた方法を使用するには、HTTP クライアントが Cookie をサポートしている必要があります。

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

## サンプルアプリケーション

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

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

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

# HTTP 負荷分散の設定

この節では、ロードバランサプラグインを設定する方法について説明します。次の項目が含まれています。

- 「負荷分散を設定するための前提条件」

- 「HTTP ロードバランサの配備」

- 「負荷分散を設定するための手順」

## 負荷分散を設定するための前提条件

ロードバランサを設定する前に、次の手順を実行する必要があります。

- Web サーバーをインストールします。

- ロードバランサプラグインをインストールします。

  インストール手順については、『Sun Java System Application Server インストールガイド』(スタンドアロンの Application Server を使用している場合)、または『Sun Java Enterprise System インストールガイド』(Java Enterprise System を使用している場合) を参照してください。

- Web サーバーを設定します。詳細については、「負荷分散のための Web Server の設定」を参照してください。

- 負荷分散に参加する Application Server クラスタまたはサーバーインスタンスを作成します。

- これらのクラスタまたはインスタンスに対するアプリケーションを配備します。

## HTTP ロードバランサの配備

ロードバランサは、目標や環境に応じて、以下の節で説明している各種の方法で設定できます。

- 「クラスタ化されたサーバーインスタンスの使用」

- 「ロードバランサをリバースプロキシプラグインとして使用する単一のスタンドアロンインスタンスの使用」

- 「複数のスタンドアロンインスタンスの使用」

### クラスタ化されたサーバーインスタンスの使用

ロードバランサを配備するためのもっとも一般的な方法は、サーバーインスタンスのクラスタを使用する方法です。デフォルトでは、クラスタ内のすべてのインスタンスが同じように設定され、同じアプリケーションが配備されています。ロードバランサは、サーバーインスタンスの間でワークロードを分散させ、正常でないインスタンスから正常なインスタンスへのフェイルオーバーを要求します。HTTP セッション持続性を設定している場合は、要求が処理を引き継がれるとセッション情報は保持されます。

複数のクラスタがある場合、要求は、単一のクラスタ内のインスタンス間でのみ負荷分散およびフェイルオーバーされます。ロードバランサで複数のクラスタを使用すると、アプリケーションの順次アップグレードが容易に可能になります。詳細については、「可用性を低下させないアプリケーションのアップグレード」を参照してください。

### ロードバランサをリバースプロキシプラグインとして使用する単一のスタンドアロンインスタンスの使用

クラスタの代わりにスタンドアロンサーバーインスタンスを使用するように、ロードバランサを設定することもできます。この設定を行うと、ロードバランサプラグインがリバースプロキシプラグイン (パススループラグインとも呼ばれる) として機能するようになります。Web サーバーは、ロードバランサで有効になっているアプリケーションへの要求を受信すると、その要求を直接 Application Server に転送します。

ロードバランサをパススループラグイン用に設定する場合は、サーバーインスタンスのクラスタ用に設定する場合と同じ手順を使用します。

### 複数のスタンドアロンインスタンスの使用

複数のスタンドアロンインスタンスを使用するようにロードバランサを設定し、要求をそれらのインスタンス間で負荷分散したり処理の継続をしたりすることも可能です。ただし、この設定では、それぞれのスタンドアロンインスタンスに同種の環境が確保され、同じアプリケーションが配備されていることを手動で確認する必要があります。クラスタでは自動的に同種の環境が維持されるため、ほとんどの状況では、クラスタの使用がより適切で、より容易な方法です。

## 負荷分散を設定するための手順

`asadmin` ツールを使用して、環境内に負荷分散を設定します。これらの手順で使用されている `asadmin` コマンドの詳細については、「ロードバランサの設定」を参照してください。

### 負荷分散を設定するには

1. `asadmin` コマンドの `create-http-lb-config` を使用して、ロードバランサ設定を作成します。

2. 作成したロードバランサのクラスタまたはスタンドアロンサーバーインスタンスへの参照を追加し、`asadmin` `create-http-lb-ref` を使用して管理するようにします。

   ターゲットを指定してロードバランサ設定を作成しており、そのターゲットが、ロードバランサが参照する唯一のクラスタまたはスタンドアロンサーバーインスタンスである場合は、この手順を飛ばしてください。

3. `asadmin enable-http-lb-server` を使用して、ロードバランサによるクラスタまたはスタンドアロンサーバーインスタンスの参照を有効にします。

4. `asadmin enable-http-lb-application` を使用して、負荷分散するアプリケーションを有効にします。

   これらのアプリケーションは、ロードバランサが参照するクラスタまたはスタンドアロンインスタンスで使用するために、事前に配備および有効にしておく必要があります。負荷分散を有効にする手順は、使用可能にする手順とは別です。

5. `asadmin` `create-health-checker` を使用して、診断プログラムを作成します。

   診断プログラムは、正常でないサーバーインスタンスを監視し、それらが正常に戻ったときにロードバランサが新しい要求を送信できるようにします。

6. `asadmin` `export-http-lb-config` を使用して、ロードバランサ設定ファイルを生成します。

   このコマンドは、Sun Java System Application Server に同梱されているロードバランサプラグインとともに使用する設定ファイルを生成します。

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

# 負荷分散のための Web Server の設定

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

注 –

ロードバランサプラグインは、サポートされている Web サーバーを実行するマシン上に、Sun Java System Application Server Enterprise Edition とともにインストールすることも、または個別にインストールすることもできます。インストール手順の詳細については、『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Installation Guide』の第 1 章「Installing Application Server Software」(スタンドアロンの Application Server を使用している場合)、または『Sun Java Enterprise System 2005Q5 インストールガイド』(Java Enterprise System を使用している場合) を参照してください。

- 「Sun Java System Web Server に対する変更」

- 「Apache Web Server の使用」

- 「インストール」

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

## Sun Java System Web Server に対する変更

インストールプログラムは、Sun Java System Web Server の設定ファイルに次のエントリを追加します。

Web サーバーインスタンスの `magnus.conf` ファイルに、次のエントリを追加します。

    ##EE lb-pluginInit
    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

Web サーバーインスタンスの `obj.conf` ファイルに、次のエントリを追加します。

    <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 Server の使用

Apache Web Server を使用するには、ロードバランサプラグインをインストールする前に、特定の設定手順を実行する必要があります。また、ロードバランサプラグインのインストールによっても、Apache Web Server に追加の変更が加えられます。プラグインをインストールしてから、追加の設定手順を実行する必要があります。

注 –

Apache 1.3 で、複数の Apache の子プロセスが動作している場合、各プロセスは固有の負荷分散ラウンドロビンシーケンスを使用しています。たとえば、Apache の子プロセスが 2 つ動作していて、ロードバランサプラグインが 2 つのアプリケーションサーバーインスタンスに対して負荷分散する場合、最初の要求はインスタンス #1 に送信され、2 番目の要求もインスタンス #1 に送信されます。3 番目の要求はインスタンス #2 に送信され、4 番目の要求も同じくインスタンス #2 に送信されます。instance1、instance1、instance2、instance2 (以下も同じ) という、このパターンが繰り返されます。この動作は、通常予測される順序、つまり、instance1、instance2、instance1、instance2 (以下も同じ) とは異なります。Sun Java System Application Server では、Apache 用のロードバランサプラグインは Apache プロセスごとにロードバランサインスタンスをインスタンス化して、独立した負荷分散シーケンスを作成します。

`--with-mpm=worker` オプションを使用してコンパイルした場合、Apache 2.0 は動作をマルチスレッド化します。

- 「Apache Web Server を使用するための要件」

- 「ロードバランサプラグインをインストールする前の設定」

- 「Application Server インストーラによって加えられる変更」

- 「Apache セキュリティーファイルをロードバランサで動作するように設定する」

### Apache Web Server を使用するための要件

Apache Web Server の場合は、Apache のバージョンに応じて、インストールが最小要件を満たす必要があります。

#### Apache 1.3 の要件

Apache 1.3 では、ロードバランサプラグインに次のものが必要です

- `openssl-0.9.7e` (ソース)

- `mod_ssl-2.8.16-1.3.`x (ソース)。この x は Apache のバージョンを表します。mod_ssl バージョンは、Apache のバージョンに一致している必要があります。

- `gcc-3.3-sol9-sparc-local` パッケージ (Solaris SPARC の場合)

- `gcc-3.3-sol9-intel-local` パッケージ (Solaris x86 の場合)

- `flex-2.5.4a-sol9-sparc-local` パッケージ (Solaris SPARC の場合)

- `flex-2.5.4a-sol9-intel-local` パッケージ (Solaris x86 の場合)

  ソフトウェアソースは、`http://www.sunfreeware.com` で入手できます。

  さらに、Apache をコンパイルする前に、次の操作をしてください。

- Linux プラットフォームでは、同じマシンに Sun Java System Application Server をインストールします。

- Solaris オペレーティングシステムでは、`gcc` バージョン 3.3 と `make` が `PATH` に含まれており、`flex` がインストールされていることを確認してください。

- Solaris 10 オペレーティングシステムでは、OpenSSL 用の `make` を実行する前に、Solaris SPARC の場合は `/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3/install-tools` に、Solaris x86 の場合は `/usr/local/lib/gcc-lib/i386-pc-solaris2.9/3.3/install-tools` に格納されている `mkheaders` を実行します。

- Red Hat Enterprise Linux Advanced Server 2.1 上で `gcc` を使用する場合、そのバージョンは `gcc` 3.0 以降である必要があります。

注 –

`gcc` 以外の C 言語のコンパイラを使用するには、その C 言語のコンパイラのパスを設定して、PATH 環境変数のユーティリティーを使用可能にします。たとえば、`sh` シェルでは次のようになります。`export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:appserver_installdir/lib`

#### Apache 2 の最小要件

Apache 2.0 では、ロードバランサプラグインに次のものが必要です

- `openssl-0.9.7e (ソース)`

- `httpd-2.0.49 (ソース)`

- `gcc-3.3-sol9-sparc-local` パッケージ (Solaris SPARC の場合)。

- `gcc-3.3-sol9-intel-local` パッケージ (Solaris x86 の場合)

- `flex-2.5.4a-sol9-sparc-local` パッケージ (Solaris SPARC の場合)

- `flex-2.5.4a-sol9-intel-local` パッケージ (Solaris x86 の場合)

ソフトウェアソースは、`http://www.sunfreeware.com` で入手できます。

さらに、Apache をコンパイルする前に、次の操作をしてください。

- Linux プラットフォームでは、同じマシンに Sun Java System Application Server をインストールします。

- Solaris オペレーティングシステムでは、`gcc` バージョン 3.3 と `make` が `PATH` に含まれており、`flex` がインストールされていることを確認してください。

- Solaris 10 オペレーティングシステムでは、OpenSSL 用の `make` を実行する前に、Solaris SPARC の場合は `/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3/install-tools` に、Solaris x86 の場合は `/usr/local/lib/gcc-lib/i386-pc-solaris2.9/3.3/install-tools` に格納されている `mkheaders` を実行します。

- Red Hat Enterprise Linux Advanced Server 2.1 上で `gcc` を使用する場合、そのバージョンは `gcc` 3.0 以降である必要があります。

注 –

`gcc` 以外の C 言語のコンパイラを使用するには、その C 言語のコンパイラのパスを設定して、PATH 環境変数のユーティリティーを使用可能にします。たとえば、`sh` シェルでは次のようになります。`export LD_LIBRARY_PATH=` app_server_install_dir`/lib:$LD_LIBRARY_PATH`.

### ロードバランサプラグインをインストールする前の設定

Apache 用のロードバランサプラグインをインストールする前に、Apache Web Server をインストールします。Apache ソースをコンパイルし、SSL で動作するようにビルドする必要があります。この節では、ロードバランサプラグインが実行されるように Apache Web Server を正常にコンパイルするために必要な最小要件と高レベルの手順について説明します。これらの要件と手順は、ソフトウェアの Solaris および Linux バージョンにのみ適用されます。Apache の Windows バージョンについては、Apache の Web サイトを参照してください。

#### SSL 対応の Apache をインストールするには

##### 始める前に

Apache ソフトウェアがすでにダウンロードされ、圧縮解除されている必要があります。

1. OpenSSL ソースをダウンロードし、展開します。

2. OpenSSL をコンパイルしてビルドします。

   OpenSSL 0.9.7.e がインストールされている場合、Linux プラットフォームではこの手順は必要ありません。

   次のコマンドを入力します。

       cd openssl-0.9.7e
       make
       make install

   OpenSSL の詳細については、`http://www.openssl.org/`を参照してください。

3. Apache のバージョンに応じて、次のいずれかの手順に従います。

   - Apache 1.3 の場合は、次の手順に従い、`mod_ssl` を使用して Apache を設定します。

     1. `mod_ssl` ソースを展開します。

     2. `cd mod_ssl-2.8.14–1.3.x`

     3. `./configure –with-apache=../apache_1.3. x --with-ssl=../openssl-0.9.7e --prefix=install_path --enable-module=ssl --enable-shared=ssl --enable-rule=SHARED_CORE --enable-module=so`

     このコマンドの中で、x は Apache のバージョン番号、install_path は Apache をインストールするディレクトリです。

     `mod_ssl` の詳細については、`http://www.modssl.org`を参照してください。

   - Apache 2.0 の場合は、ソースツリーを設定します。

     1. `cd http-2.0_` x.

     2. `./configure --with-ssl=` open_ssl_install_path `--prefix=` install_path `--enable-ssl --enable-so` を実行します。

        このコマンドの中で、x は Apache のバージョン番号、open_ssl_install_path は OpenSSL がインストールされているディレクトリ、および install_path は Apache をインストールするディレクトリです。

4. Linux 2.1 上の Apache の場合は、コンパイルの前に次の手順を実行します。

   1. `src/MakeFile` を開き、自動的に生成されるセクションの最後を見つけます。

   2. 自動的に生成されるセクションのあとの最初の 4 行のあとに、次の行を追加します。

          LIBS+= -licuuc -licui18n -lnspr4 -lpthread -lxerces-c
          -lsupport -lnsprwrap -lns-httpd40
          LDFLAGS+= -L/appserver_installdir/lib -L/opt/sun/private/lib

      `-L/opt/sun/private/lib` は、Application Server を Java Enterprise System インストールの一部としてインストールした場合にのみ必要であることに注意してください。

      次に例を示します。

          ## (End of automatically generated section)
          ##
          CFLAGS=$(OPTIM) $(CFLAGS1) $(EXTRA_CFLAGS)
          LIBS=$(EXTRA_LIBS) $(LIBS1)
          INCLUDES=$(INCLUDES1) $(INCLUDES0) $(EXTRA_INCLUDES)
          LDFLAGS=$(LDFLAGS1) $(EXTRA_LDFLAGS)
          "LIBS+= -licuuc -licui18n -lnspr4 -lpthread
          -lxerces-c -lsupport -lnsprwrap -lns-httpd40
          LDFLAGS+= -L/appserver_installdir /lib -L/opt/sun/private/lib

   3. 環境変数 LD_LIBRARY_PATH を設定します。

      すべてのインストールで、次のように設定します。`appserver_install_dir/lib`

      Java Enterprise System インストールでは、`appserver_install_dir/lib:opt/sun/private/lib` に設定します。

5. 使用しているバージョンのインストール手順で説明されている方法で、Apache をコンパイルします。

   詳細については、`http://httpd.apache.org/`を参照してください。

   一般的な手順は次のとおりです。

   1. `make`

   2. `make certificate` (Apache 1.3 のみ)

   3. `make install`

      `make certificate` コマンドは、セキュリティー保護されたパスワードを要求します。このパスワードは、セキュリティー保護された Apache を起動するために必要です。忘れないようにしてください。

6. 環境に応じて Apache を設定します。

### Application Server インストーラによって加えられる変更

ロードバランサプラグインのインストールプログラムは、必要なファイルを、Web サーバーのルートディレクトリ内のディレクトリに展開します。

- Apache 1.3 の場合、このディレクトリは `libexec` です。

- Apache 2.0 の場合、このディレクトリは `modules` です。

インストールプログラムは、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 セキュリティーファイルをロードバランサで動作するように設定する

Apache Web Server は、ロードバランサプラグインとの適切な動作のために、正しいセキュリティーファイルを保持している必要があります。

1. apache_install_dir の下に `sec_db_files` という名前のディレクトリを作成します。

2. application_server_domain_dir`/config/`*.db を apache_install_dir`/sec_db_files` にコピーします。

3. プラットフォームに応じて、追加の設定を実行します。

   - Solaris プラットフォームの場合:

     apache_install_dir`/bin/apachectl` スクリプト内の LD_LIBRARY_PATH に、パス `/usr/lib/mps/secv1` を追加します。このパスは、`/usr/lib/mps` の前に追加する必要があります。

   - Linux の場合:

     apache_install_dir`/bin/apachectl` スクリプト内の LD_LIBRARY_PATH に、パス `/opt/sun/private/lib` を追加します。このパスは、`/usr/lib` の前に追加する必要があります。

   - Microsoft Windows の場合:

     1. Path 環境変数に新しいパスを追加します。

        「スタート」->「設定」->「コントロール パネル」->「システム」->「詳細設定」->「環境変数」->「システム環境変数」の順にクリック します。

        Path 環境変数に application_server_install_dir`/bin` を追加します。

     2. 環境変数 NSPR_NATIVE_THREADS_ONLY を 1 に設定します。

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

     3. マシンを再起動します。

## Microsoft IIS に対する変更

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

これらの変更は、Sun Java System Application Server をインストールしてから行います。

### ロードバランサプラグインを使用するように Microsoft IIS を設定するには

1. Internet Services Manager を開きます。

2. プラグインを有効にする Web サイトを選択します。

   この Web サイトは通常、デフォルトの Web サイトと名付けられます。

3. この Web サイト上で右クリックして「プロパティー」を選択し、「プロパティー」ノートブックを開きます。

4. 次の手順に従って、新しい ISAPI フィルタを追加します。

   1. 「ISAPI フィルタ」タブを開きます。

   2. 「追加」をクリックします。

   3. 「フィルタ名」フィールドに、「`Application Server`」と入力します。

   4. 「実行ファイル」フィールドに、「`C:\Inetpub\wwwroot\sun-passthrough\sun-passthrough.dll`」と入力します。

   5. 「了解」をクリックして、「プロパティー」ノートブックを閉じます。

5. 新しい仮想ディレクトリを作成および設定します。

   1. デフォルトの Web サイト上で右クリックして「新規」を選択し、「仮想ディレクトリ」を選択します。

      「仮想ディレクトリの作成ウィザード」が開きます。

   2. 「エイリアス」フィールドに、「`sun-passthrough`」と入力します。

   3. 「ディレクトリ」フィールドに、「`C:\Inetpub\wwwroot\sun-passthrough`」と入力します。

   4. 「実行パーミッション」チェックボックスにチェックマークを付けます。

      ほかのすべてのパーミッション関連のチェックボックスは、チェックしないでおきます。

   5. 「完了」をクリックします。

6. システムの `PATH` 環境変数に、`sun-passthrough.dll` ファイルのパスおよび application_server_install_dir`/bin` を追加します。

7. マシンを再起動します。

8. Web サーバーを停止してから起動して、新しい設定を反映させます。

   Web サーバーを停止するには、Web サイト上で右クリックして「`停止`」を選択します。Web サーバーを起動するには、Web サイト上で右クリックして「`起動`」を選択します。

9. Web サーバー、ロードバランサプラグイン、および Application Server が正常に動作していることを確認します。

   Web ブラウザに以下のように入力して Web アプリケーションのコンテキストルートにアクセスします。`http://webserver_name/ web_application`。ここで、webserver_name は Web サーバーのホスト名または IP アドレスであり、web_application は `C:\Inetpub\wwwroot\sun-passthrough\sun-passthrough.properties` ファイルに一覧表示したコンテキストルートです。

### 自動的に設定される sun-passthrough プロパティー

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

プロパティー | 定義 | デフォルト値
--- | --- | ---
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 サーバーを置くには、いくつかの手順を手動で実行してロードバランサプラグインを設定する必要があります。

### 複数の Web サーバーインスタンスを設定するには

1. ロードバランサプラグインを使用するように新しい Web サーバーインスタンスを設定します。

   「Sun Java System Web Server に対する変更」、「Apache Web Server の使用」、または 「インストール」の手順に従います。

2. DTD ファイルをコピーします。

   既存の Web サーバーインスタンスの `config` ディレクトリから、`sun-loadbalancer_1_1.dtd` を新しいインスタンスの `config` ディレクトリにコピーします。

3. ロードバランサ設定ファイルを設定します。次のいずれかを実行します。

   - 既存のロードバランサ設定をコピーします。

     既存のロードバランサ設定を使用して、既存の Web サーバーインスタンスの `config` ディレクトリから、`loadbalancer.xml` ファイルを新しいインスタンスの `config` ディレクトリにコピーします。

   - 新しいロードバランサ設定を作成します。

     1. `asadmin create-http-lb-config` を使用して、新しいロードバランサ設定を作成します。

     2. `asadmin export http-lb-config` を使用して、新しい設定を `loadbalancer.xml` ファイルにエクスポートします。

     3. `loadbalancer.xml` ファイルを、新しい Web サーバーの `config` ディレクトリにコピーします。

        ロードバランサ設定を作成し、それを `loadbalancer.xml` ファイルにエクスポートする方法については、「HTTP ロードバランサ設定の作成」を参照してください。

# ロードバランサの設定

ロードバランサ設定は、`domain.xml` ファイル内で名前を付けられている設定です。ロードバランサ設定は非常に柔軟性があります。

- 各ロードバランサ設定は、関連する複数のロードバランサを持つことができます。ただし、1 つのロードバランサには、1 つのロードバランサ設定しかできません。

- ロードバランサがサービスを提供するドメインは 1 つだけですが、ドメインは関連する複数のロードバランサを持つことができます。

この節では、ロードバランサ設定を作成、変更、および使用する方法について説明します。ここで説明する内容は次のとおりです。

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

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

- 「負荷分散のためのサーバーインスタンスの有効化」

- 「負荷分散のためのアプリケーションの有効化」

- 「HTTP 診断プログラムの作成」

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

- 「ロードバランサ設定の変更」

- 「動的再設定の有効化」

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

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

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

`asadmin` コマンドの `create-http-lb-config` を使用して、ロードバランサ設定を作成します。パラメータについては、「HTTP ロードバランサ設定の作成」で説明されています。詳細については、`create-http-lb-config`、`delete-http-lb-config`、および `list-http-lb-configs` のドキュメントを参照してください。

表 4–1 ロードバランサ設定のパラメータ

パラメータ | 説明
--- | ---
応答タイムアウト | サーバーインスタンスが応答を返すまでの秒単位のタイムアウト。タイムアウト時間内に応答が着信しない場合、サーバーが正常でないと判断されます。デフォルトは 60 です。
HTTPS ルーティング | ロードバランサに対する HTTPS 要求の結果が、サーバーインスタンスに対する HTTPS または HTTP 要求となるかどうかを指定します。詳細については、「HTTPS ルーティングの設定」を参照してください。
再読み込み間隔 | ロードバランサ設定ファイル `loadbalancer.xml` に対する変更をチェックする間隔。チェックによって変更が検出されると、設定ファイルが再読み込みされます。この値が 0 の場合は、再読み込みが無効になります。詳細については、「動的再設定の有効化」を参照してください。
監視 | ロードバランサで監視が有効かどうかを指定します。
ルート Cookie | ロードバランサプラグインがルート情報を記録するために使用する Cookie の名前を指定します。HTTP クライアントは Cookie をサポートする必要があります。Cookie を格納する前にブラウザが確認してくるように設定すると、Cookie の名前は「JROUTE」となります。
ターゲット | ロードバランサ設定のターゲットを指定します。ターゲットを指定すると、設定に参照を追加した場合と同じ結果になります。ターゲットは、クラスタまたはスタンドアロンインスタンスです。

## 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` コマンドを使用します。次のパラメータを指定します。

表 4–2 診断プログラムのパラメータ

パラメータ | 説明 | デフォルト
--- | --- | ---
url | ロードバランサが健康状態を判断するためにチェックするリスナーの URL を指定します。 | “/”
interval | インスタンスの診断プログラムを実行する間隔を秒単位で指定します。0 を指定すると、診断プログラムが無効になります。 | 30 秒
timeout | 正常だとみなされるリスナーが応答を受け取るまでのタイムアウトを秒単位で指定します。 | 10 秒

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

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

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

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

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

注 –

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

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

表 4–3 診断プログラムの手動のプロパティー

プロパティー | 定義
--- | ---
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="number-healthcheck-retries" value="3"/>

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

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

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

### ロードバランサ設定をエクスポートするには

1. `asadmin` コマンドの `export-http-lb-config` を使用して、`loadbalancer.xml` ファイルをエクスポートします。

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

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

2. エクスポートしたロードバランサ設定ファイルを、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-config` で `--reloadinterval` オプションを使用します。

  このオプションは、ロードバランサ設定ファイル `loadbalancer.xml` に対する変更のチェックの間隔を設定します。この値が 0 の場合は、動的再設定が無効になります。デフォルトでは、動的再設定が有効になり、再読み込み間隔は 60 秒に設定されます。

- 以前に動的再設定を無効にしていた場合、または再読み込み間隔を変更する場合は、`asadmin set` コマンドを使用します。

  再読み込み間隔を変更したら、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの `config` ディレクトリにコピーしたあと、Web サーバーを再起動します。

注 –

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

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

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

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

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

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

- あるインスタンス (スタンドアロンまたはクラスタの 1 部分) が削除され、タイムアウトが経過していない場合、スティッキ要求はインスタンスに配信され続けます。ただし、新しい要求は無効化されたインスタンスに送信されません。

- タイムアウトを経過すると、インスタンスは無効化されます。ロードバランサからインスタンスへのすべてのオープン接続が閉じられます。このインスタンスに固定されている一部のセッションが無効化されなかった場合でも、ロードバランサはこのインスタンスに要求を送りません。ロードバランサはスティッキ要求を別の正常なインスタンスにフェイルオーバーします。

### サーバーインスタンスまたはクラスタを無効にするには

1. `asadmin disable-http-lb-server` を実行して、タイムアウトを分単位で設定します。

2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

3. エクスポートした設定を Web サーバーの `config` ディレクトリにコピーします。

4. サーバーインスタンスを停止します。

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

Web アプリケーションの配備を取り消す前に、アプリケーションで要求の処理が完了される必要があります。アプリケーションを正常に無効にするプロセスは、停止と呼ばれます。アプリケーションを停止する場合は、タイムアウトピリオドを指定します。ロードバランサは、指定されたタイムアウトピリオドに基づいて、アプリケーションを停止するために次のポリシーを使用します。

- タイムアウトピリオドが経過していない場合、ロードバランサは新しい要求をアプリケーションには転送せずに、Web サーバーに返します。ただし、タイムアウトピリオドが経過するまで、スティッキ要求の転送は引き続き行います。

- タイムアウトピリオドを経過すると、ロードバランサは、スティッキ要求を含むアプリケーションへのすべての要求を受け付けなくなります。

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

### アプリケーションを無効にするには

1. `asadmin disable-http-lb-application` を使用して、次のパラメータを指定します。

   - タイムアウト (分単位)

   - 無効にするアプリケーションの名前

   - 無効化を実行するターゲットクラスタまたはインスタンス

2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

3. エクスポートした設定を Web サーバーの `config` ディレクトリにコピーします。

## HTTP および HTTPS のフェイルオーバーの設定

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

ここで説明する内容は次のとおりです。

- 「HTTPS ルーティング」

- 「べき等 URL の設定」

### HTTPS ルーティング

HTTPS (HTTP Secure) プロトコルは、SSL (Secure Socket Layer) を使用して、セキュリティー保護された通信のための HTTP 要求の暗号化および復号化を実現します。HTTPS ルーティングを動作させるには、1 つまたは複数の 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-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 の設定

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

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

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

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

べき等 URL の設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の「Configuring Idempotent URL Requests」を参照してください。

# 可用性を低下させないアプリケーションのアップグレード

ユーザーへの可用性を低下させることなくアプリケーションを新しいバージョンにアップグレードする方法は、順次アップグレードと呼ばれます。アップグレードの前後で 2 つのバージョンのアプリケーションを慎重に管理することによって、アプリケーションの現在のユーザーが中断されることなくタスクを完了できる一方で、新しいユーザーが新しいバージョンのアプリケーションを透過的に取得できるようになります。順次アップグレードの場合、ユーザーはアップグレードが行われたことに気付きません。

## アプリケーションの互換性

順次アップグレードでは、2 つのアプリケーションバージョン間の変更の大きさに応じて、さまざまなレベルの困難が発生します。

変更が、たとえば、静的なテキストやイメージへの変更のような表面的なものであれば、2 つのバージョンのアプリケーションには互換性があり、同じクラスタ内で両方のバージョンを一度に実行することができます。互換性のあるアプリケーションは、次の条件を備えている必要があります。

- 同じセッション情報を使用している。

- 互換性のあるデータベーススキーマを使用している。

- 一般に互換性のあるアプリケーションレベルのビジネスロジックを採用している。

- 同じ物理データソースを使用している。

互換性のあるアプリケーションの順次アップグレードは、単一のクラスタまたは複数のクラスタのどちらでも実行できます。詳細については、「単一クラスタでのアップグレード」を参照してください。

2 つのバージョンのアプリケーションが上の一部の条件を満たしていない場合、これらのアプリケーションは互換性がないと見なされます。互換性のないバージョンのアプリケーションを同じクラスタ内で実行すると、アプリケーションデータが破壊され、セッションフェイルオーバーが発生して正しく機能しなくなる場合があります。発生する問題は、非互換性の種類や程度によって異なります。新しいバージョンを配備して古いクラスタやアプリケーションを徐々に停止する「シャドウクラスタ」を作成して、互換性のないアプリケーションをアップグレードすることをお勧めします。詳細については、「互換性のないアプリケーションのアップグレード」を参照してください。

アプリケーション開発者および管理者は、アプリケーションのバージョンに互換性があるかどうかを判断できる最適な人びとです。不明な場合は、バージョンには互換性がないと仮定してください。これがもっとも安全な方法です。

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

単一のクラスタに配備されたアプリケーションの順次アップグレードは、そのクラスタの設定がほかのどのクラスタとも共有されていないと仮定して行うことができます。

### 単一のクラスタでアプリケーションをアップグレードするには

1. 旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。

   ドメインをバックアップするには、`asadmin backup-domain` コマンドを使用します。

2. クラスタの動的再設定を無効にします (有効になっている場合)。

   管理コンソールを使用してこれを行うには、次の手順に従います。

   1. 「設定」ノードを開きます。

   2. クラスタの設定の名前をクリックします。

   3. 「システムプロパティーの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。

   4. 「保存」をクリックします。

   あるいは、次のコマンドを使用します。

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

3. ターゲットの `domain` に対して、アップグレードしたアプリケーションを再配備します。

   管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。`asadmin` を使用している場合は、ターゲットの`ドメイン`を指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。

4. `asadmin enable-http-lb-application` を使用して、インスタンスに対して再配備アプリケーションを有効にします。

5. ロードバランサから、クラスタ内の 1 つのサーバーインスタンスを停止します。

   次の手順に従います。

   1. `asadmin disable-http-lb-server` を使用して、サーバーインスタンスを無効にします。

   2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

   3. エクスポートした設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。

      たとえば、Sun Java System Web Server の場合、コピー先は web_server_install_dir/`https-`host-name`/config/loadbalancer.xml` となります。確実にロードバランサに新しい設定ファイルをロードさせるために、ロードバランサ設定の `reloadinterval` を設定して、動的再設定が有効であることを確認します。

   4. タイムアウトが終了するまで、待機します。

      ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。

6. クラスタ内のほかのインスタンスが実行中の間に、無効になっていたサーバーインスタンスを再起動します。

   再起動すると、サーバーはドメインと同期し、アプリケーションを更新します。

7. 再起動したサーバー上でアプリケーションをテストし、正しく動作していることを確認します。

8. ロードバランサで、サーバーインスタンスをふたたび有効にします。

   次の手順に従います。

   1. `asadmin enable-http-lb-server` を使用して、サーバーインスタンスを有効にします。

   2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

   3. 「単一クラスタでのアップグレード」の 「単一クラスタでのアップグレード」の説明に従って、設定ファイルを Web サーバーの設定ディレクトリにコピーします。

9. クラスタ内の各インスタンスに対して、手順 5 〜 8 を繰り返します。

10. すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、そのクラスタに対して動的再設定を再度有効にすることができます。

## 複数のクラスタでのアップグレード

### 2 つ以上のクラスタで、互換性のあるアプリケーションをアップグレードするには

1. 旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。

   ドメインをバックアップするには、`asadmin backup-domain` コマンドを使用します。

2. すべてのクラスタの動的再設定を無効にします (有効になっている場合)。

   管理コンソールを使用してこれを行うには、次の手順に従います。

   1. 「設定」ノードを開きます。

   2. 1 つのクラスタの設定の名前をクリックします。

   3. 「システムプロパティーの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。

   4. 「保存」をクリックします。

   5. ほかのクラスタに対して上記手順を繰り返します

   あるいは、次のコマンドを使用します。

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

3. ターゲットの `domain` に対して、アップグレードしたアプリケーションを再配備します。

   管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。`asadmin` を使用している場合は、ターゲットの`ドメイン`を指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。

4. `asadmin enable-http-lb-application` を使用して、クラスタに対して再配備したアプリケーションを有効にします。

5. ロードバランサから 1 つのクラスタを停止します

   1. `asadmin disable-http-lb-server` を使用して、クラスタを無効にします。

   2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

   3. エクスポートした設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。

      たとえば、Sun Java System Web Server の場合、コピー先は web_server_install_dir/`https-`host-name`/config/loadbalancer.xml` となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の `reloadinterval` を設定して、ロードバランサの動的再設定を有効にする必要があります。

   4. タイムアウトが終了するまで、待機します。

      ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。

6. ほかのクラスタが実行中の間に、無効となっていたクラスタを再起動します。

   再起動すると、クラスタはドメインと同期し、アプリケーションを更新します。

7. 再起動したクラスタ上でアプリケーションをテストし、正しく動作していることを確認します。

8. ロードバランサでクラスタをふたたび有効にします。

   1. `asadmin enable-http-lb-server` を使用して、クラスタを有効にします。

   2. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

   3. 設定ファイルを Web サーバーの設定ディレクトリにコピーします。

9. ほかのクラスタに対して、手順 5 〜 8 を繰り返します。

10. すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、すべてのクラスタに対して動的再設定を再度有効にすることができます。

## 互換性のないアプリケーションのアップグレード

アプリケーションの互換性に必要な条件については、「アプリケーションの互換性」を参照してください。アプリケーションの新しいバージョンは、古いバージョンとは互換性がありません。互換性のないアプリケーションも、2 つ以上のクラスタでアップグレードする必要があります。クラスタが 1 つしかない場合は、後述の説明に従って、アップグレードのための「シャドウクラスタ」を作成します。

互換性のないアプリケーションをアップグレードする場合は、次の手順を実行します。

- 新しいバージョンのアプリケーションに、古いバージョンのアプリケーションとは別の名前を付けます。このあとの手順は、アプリケーションの名前が変更されていることを前提にしています。

- データスキーマに互換性がない場合は、データの移行を計画したあとに、別の物理データソースを使用します。

- 新しいバージョンを、古いバージョンが配備されているクラスタとは別のクラスタに配備します。

- アプリケーションへの要求は新しいクラスタに処理を引き継がないため、クラスタをオフラインにする前に、古いアプリケーションを実行しているクラスタには適切な長いタイムアウトを設定します。これらのユーザーセッションは、単純に失敗します。

### 2 番目のクラスタを作成することにより互換性のないアプリケーションをアップグレードするには

1. 旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。

   ドメインをバックアップするには、`asadmin backup-domain` コマンドを使用します。

2. 同じマシンセットまたは別のマシンセットに、既存のクラスタとして「シャドウクラスタ」を作成します。

   1. 管理コンソールを使用して、既存のクラスタで名前を付けられている設定から新しいクラスタと参照を作成します。

      既存のアクティブポートとの競合を回避するために、各マシンで新しいインスタンスのポートをカスタマイズします。

   2. `asadmin create-resource-ref` を使用して、クラスタに関連付けられたすべてのリソースについて、新しく作成されたクラスタにリソース参照を追加します。

   3. `asadmin create-application-ref` を使用して、新しく作成されたクラスタから、クラスタに配備されているほかのすべてのアプリケーション (現在再配備されているアプリケーションを除く) への参照を作成します。

   4. `asadmin configure-ha-cluster` を使用して、クラスタを高可用性に設定します。

   5. `asadmin create-http-lb-ref` を使用して、ロードバランサ設定ファイル内の新しく作成されたクラスタへの参照を作成します。

3. 新しいバージョンのアプリケーションに、古いバージョンとは別の名前を付けます。

4. 新しいクラスタをターゲットとして、新しいアプリケーションを配備します。別のコンテキストルートを使用します。

5. `asadmin enable-http-lb-application` を使用して、クラスタに対して配備した新しいアプリケーションを有効にします。

6. ほかのクラスタが実行している間に、新しいクラスタを起動します。

   起動すると、クラスタはドメインと同期し、新しいアプリケーションで更新されます。

7. 新しいクラスタ上でアプリケーションをテストして、正しく動作していることを確認します。

8. `asadmin disable-http-lb-server` を使用して、ロードバランサから古いクラスタを無効にします。

9. 無応答のセッションに対するタイムアウト時間を設定します。

10. `asadmin enable-http-lb-server` を使用して、ロードバランサから新しいクラスタを有効にします。

11. `asadmin export-http-lb-config` を使用して、ロードバランサ設定ファイルをエクスポートします。

12. エクスポートした設定ファイルを Web サーバーインスタンスの設定ディレクトリにコピーします。

    たとえば、Sun Java System Web Server の場合、コピー先は web_server_install_dir/`https-`host-name`/config/loadbalancer.xml` となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の `reloadinterval` を設定して、ロードバランサの動的再設定を有効にする必要があります。

13. タイムアウトピリオドが経過するか、または古いアプリケーションのすべてのユーザーが終了したら、古いクラスタを停止し、古いアプリケーションを削除します。

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

- 「ログメッセージの設定」

- 「ログメッセージのタイプ」

- 「ロードバランサのログの有効化」

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

## ログメッセージの設定

ロードバランサプラグインは、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 によって、Web モジュール <web-module> に対する <url-pattern> <no-of-retries> が設定されました`

- ログレベルが SEVERE に設定されている場合:

  `CONFxxxx: loadbalancer.xml の Web モジュール <web-module> に対するべき等 URL 要素 <url-pattern> のエントリが重複しています`

- ログレベルが WARN に設定されている場合:

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

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

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

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

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

- 各メソッドの起動の標準的なログの出力には、次の情報が含まれます (ログレベルが FINE に設定されている場合)。

  `ROUTxxxx: ルーターメソッド <method_name> を実行しています`

- 各メソッドの起動のルーターログの出力には、次の情報が含まれます (ログレベルが INFO に設定されている場合)。

  `ROUTxxxx: べき等要求 <Request-URL> に対する別の ServerInstance の選択に成功しました`

- 実行時ログの出力には、次の情報が含まれます (ログレベルが INFO に設定されている場合)。

  `RNTMxxxx: べき等の <GET/POST/HEAD> 要求 <Request-URL> を再試行しています`

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

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

- ログレベルが INFO に設定されている場合:

  `ROUTxxxx: 非べき等要求 <Request-URL> は、再試行されません`

  次に例を示します。`ROUTxxxx: 非べき等要求 http://sun.com/addToDB?x=11&abc=2 は、再試行されません`

- ログレベルが FINE に設定されている場合:

  `RNTMxxxx: Web モジュール <web-module> に対するカスタムエラー URL またはページ <error-url> が、無効または不明です`

  次に例を示します。`RNTMxxxx: Web モジュール test に対するカスタムエラー URL またはページ myerror1xyz が、無効または不明です`

## ロードバランサのログの有効化

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

- すべての要求の開始 / 停止情報。

- 要求が正常ではないインスタンスから正常なインスタンスにフェイルオーバーする際の、フェイルオーバー要求の情報。

- すべての診断プログラムサイクルの最後にある正常ではないインスタンスのリスト。

注 –

ロードバランサのログが有効になっていて、Web サーバーのログレベルが `DEBUG` かまたは verbose メッセージを出力するように設定されている場合、ロードバランサは Web サーバーのログファイルに HTTP セッション ID を記録します。したがって、ロードバランサプラグインをホストしている Web サーバーが DMZ 内にある場合、本稼動環境では `DEBUG` または同等のログレベルを使用しないでください。

ログレベル `DEBUG` を使用する必要がある場合は、`loadbalancer.xml` で `require-monitor-data` プロパティーを `false` に設定して、ロードバランサのログを無効にしてください。

### ロードバランサのログを有効にするには

1. Web サーバーのログオプションを設定します。この手順は、Web サーバーによって異なります。

   - Sun Java System Web Server の場合

     サーバーの管理コンソールで、「`Magnus Editor`」タブを表示し、「`Log Verbose`」オプションを「`On`」に設定します。

   - Apache Web Server の場合は、ログレベルを `DEBUG` に設定します。

   - Microsoft IIS の場合は、`sun-passthrough.properties` ファイルのログレベルを `FINE` に設定します。

2. ロードバランサ設定の「`監視`」オプションを true に設定します。

   `asadmin create-http-lb-config` コマンドを使用して最初にロードバランサ設定を作成する際に監視を true に設定するか、`asadmin set` コマンドを使用してあとから true に設定します。デフォルトでは、監視は無効になっています。

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

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

- HTTP 要求の開始時には、次の情報が含まれます。

  `RequestStart Sticky(New) <req-id> <time-stamp> <URL>`

  タイムスタンプ値には、1970 年 1 月 1 日からの時間をミリ秒単位で指定します。

  `RequestStart 新規 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 メッセージでは、<応答時間> は、要求の合計ターンアラウンドタイムをロードバランサプラグインの側からミリ秒単位で表します。

- 正常ではないインスタンスのリストは、次のとおりです。

  `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`

- Previous: 第 3 章 高可用性データベースの管理
- Next: 第 5 章 Application Server クラスタの使用

- © 2010, Oracle Corporation and/or its affiliates