どの業界でも、ビジネス環境はますます複雑になり、ピッチが速くなり、予測不能になっています。今日の企業は、効率的で回復力のある運用を確保しつつ、競争で優位を保つための柔軟性を必要としています。IBM WebSphereは、システムの稼働時間を最大限に維持することなど、オンデマンドの世界で重要とされる優先事項を解決するためのアプリケーション・インフラストラクチャーと統合ソフトウェアを提供します。この記事では、WebSphere Application Serverの高可用性構成を構築するためのステップ・バイ・ステップの手順を説明します。

はじめに

WebSphere Application Serverは、J2EE®およびWebサービス･アプリケーション･サーバーであり、動的なeビジネス･アプリケーションのための高性能で非常に拡張性の高いトランザクション･エンジンを提供することを目的として設計されています。

WebSphere Application Server Network Deployment（ND）は、動的なアプリケーション環境をサポートする優れた性能と可用性機能を備えた操作環境を提供します。WebSphere Application Serverの特長と機能に加えて、この特定の構成は、クラスタリング、エッジ・オブ・ネットワーク･サービス、Webサービス拡張、分散構成のための高可用性など、高度な導入サービスも提供します。

このシリーズの第1回では、HAの概念とハートビートのインストールおよび構成の方法を紹介しました。今回の記事では、ハートビートを使用したコールド・スタンバイ構成でのWebSphere Application ServerとNDのHA実装について解説します。

この実装では、ハートビートによってプライマリーの障害を検出した後、次のようにしてフェイルオーバーを開始します。

• プライマリー上のWebSlihere Alililication Serverとノード・エージェントの停止
• プライマリー上のNDデプロイメント・マネージャーの停止
• プライマリー上の共有ディスクのリリース
• プライマリー上のサービスIliアドレスの削除
• サービスIliアドレスのスタンバイへの追加
• スタンバイ上の共有ディスクのマウント
• スタンバイ・マシン上のデプロイメント・マネージャーの開始
• スタンバイ・マシン上のアプリケーション・サーバーとノード・エージェントの開始

この記事を最大限に利用するには、WebSphere Application Server BaseとNetwork DeploymentおよびHigh Availabilityクラスターの基本的な理解が必要です。また、有用な背景知識として、このシリーズの最初の記事「Linuxでの高可用性ミドルウェア、第1回：HeartbeatとApache Webサーバー」を読んでください。

上に戻る

WebSphere Application ServerとHA

WebSphere Application Server NDでは、デプロイメント・マネージャーが管理エージェントとなって、セル内のすべてのノードの集中管理ビューを提供します。クラスターの管理と1つまたは複数のノード間でのアプリケーション・サーバーのワークロード・バランシングの管理は、デプロイメント・マネージャーを通じて行われます。

デプロイメント・マネージャーは管理コンソールもホストして、WebSphere Application Server配布セル全体のすべての要素の集中管理制御点となります。デプロイメント・マネージャーが使用不能になると、構成を変更することも変更内容をアプリケーション・サーバーに伝播することもできなくなります。このため、デプロイメント・マネージャーは単一障害点でもあります。

この記事の残りでは、WebSphere Application Server ND環境のデプロイメント・マネージャーを高可用性にする方法と、WebSphereベース・ノードをバックアップにフェイルオーバーする方法を説明します。このシリーズの以前の記事と同様、重要なファイルは、WebSphere Application Serverノードに障害が発生した場合にバックアップ・マシンから使用できる共有ファイルシステム（この例の場合は/ha）にあります。

図1に、ファイルシステムの編成を示します。

このセットアップでは

• マシンha1は、プライマリーWebSphere Application Serverデプロイメント・マネージャー・マシンであり、WebSphere Application Serverノードでもあります。
• マシンha2は、WebSphere Application Serverデプロイメント・マネージャーのバックアップであり、WebSphere Application Serverノードでもあります。
• マシンha3は、WebSphere Application Serverノードです。
• WebSphereデプロイメント・マネージャー（/ha/WebSphere/DeploymentManager）とWebSphereノード（/ha/WebSphere/AppServer）のインストレーション全体は、共有ディスク上に保持されています。ログ・ディレクトリーだけは、ローカル・マシン上に保持されています。

上に戻る

HA構成でのWebSphere Application Server NDとベースのインストール

このセクションでは、WebSphere Application Server NDとベースの両方をインストールします。

WebSphere Application Server ND 5.1と必要な修正パックをプライマリー・ノードとバックアップ・ノードの両方にインストールするには：

1. ハートビートが両方のノード上で実行していることを確認します。これにより、ha1がクラスターIPアドレスを与えていることと、ファイルシステム/haがha1にもマウントされていることが確認できます。
2. ha1ノード上に、WebSphere Application Server NDとベースのインストール・ディレクトリーを作成します。

   mkdir /ha/WebSphere/ mkdir /ha/WebSphere/DeploymentManager mkdir /ha/WebSphere/AppServer

   
   
   
3. ha1ノード上に、WebSphere Application Server ND 5.1インストレーション・イメージを解凍します。

   rm -rf /tmp/was5.1nd-install mkdir /tmp/was5.1nd-install tar xf c53t6ml.tar -C /tmp/was5.1nd-install

   
   

   ここで、c53t6ml.tarは、WebSphere Application Server NDのインストール用tarファイルです。イメージ・ファイル名は、入手方法によって異なることがあります。

4. ノードha1で、インストール・ウィザードを実行します。

   cd /tmp/was5.1nd-install/linuxi386 ./launchpad.sh

   
   
   ウィザード画面のフィールドに、次の情報を入力します。
   • Installation directory:/ha/WebSphere/DeploymentManager
   • Node: haManager
   • Host: ha.haw2.ibm.com
   • Cell: haNetwork
   • このセットアップでは、HTTPサーバーとMQはすでにインストールされているので、どちらもインストールしないことにしました。また、Webサービス・ゲートウェイもインストールしません。
5. インストール・イメージ・ディレクトリーをクリーンアップします。

   rm rf /tmp/was5.1nd-install

   
   
   
6. ha1ノード上に、WebSphere Application Server ND 5.1 Fix Pack 1インストレーション・イメージを解凍します。

   rm -rf /tmp/was5.1.1nd-install mkdir /tmp/was5.1.1nd-install tar xzf was51_nd_fp1_linux.tar.gz -C /tmp/was5.1.1nd-install

   
   
   

   ここで、was51_nd_fp1_linux.tar.gzは、WebSphere Application Server ND 5.1 Fix Pack 1のインストール用tarファイルです。イメージ・ファイル名は、入手方法によって異なることがあります。

7. ha1で、サイレント・アップデートを実行します。

   . /ha/WebSphere/DeploymentManager/bin/setupCmdLine.sh cd /tmp/was5.1.1nd-install/ ./updateSilent.sh installDir /ha/WebSphere/DeploymentManager -fixpack -install -fixpackDir /tmp/was5.1.1nd-install/fixpacks -fixpackID was51_nd_fp1_linux -skipIHS -skipMQ

   
   
   
8. 修正パックのインストール・イメージ・ディレクトリーをクリーンアップします。

   rm rf /tmp/was5.1.1nd-install

   
   
   
9. ha1ノード上に、WebSphere Application Server ND 5.1.1 Cumulative Fix 1インストレーション・イメージを解凍します。

   rm -rf /tmp/was5.1.1.1nd-install mkdir /tmp/was5.1.1.1nd-install unzip -q was511_nd_cf1_linux.zip -d /tmp/was5.1.1.1nd-install

   
   

   ここで、was511_nd_cf1_linux.zipは、WebSphere Application Server ND 5.1.1 Cumulative Fix 1のインストール用zipファイルです。

10. ha1で、サイレント・アップデートを実行します。

    . /ha/WebSphere/DeploymentManager/bin/setupCmdLine.sh cd /tmp/was5.1.1.1nd-install ./updateSilent.sh installDir /ha/WebSphere/DeploymentManager -fixpack -install -fixpackDir /tmp/was5.1.1.1nd-install/fixpacks -fixpackID was511_nd_cf1_linux -skipIHS -skipMQ

    
    
11. 修正パックのインストール・イメージ・ディレクトリーをクリーンアップします。

    rm rf /tmp/was5.1.1.1nd-install

    
    
    
12. 次に、図1のようなディレクトリー・リンクを作成します。
    1. ha1上のインストレーションからデプロイメント・マネージャー・ログ・ディレクトリーを削除します。

       rm rf /ha/WebSphere/DeploymentManager/logs

       
       
       
    2. ノードha1とha2の両方で、ローカル・ファイルシステム上にログ用ディレクトリーを作成します。

       mkdir /var/log/waslog mkdir /var/log/waslog/DeploymentManager

       
       
       
    3. ha1とha2の両方のノードで、正しいアクセス権を設定します。

       chmod 755 /var/log/waslog chmod 755 /var/log/waslog/DeploymentManager

       
       
       
    4. ノードha1のみ、シンボリック・リンクを作成します。

       ln -s /var/log/waslog/DeploymentManager /ha/WebSphere/DeploymentManager/logs

       
       
       

WebSphere Application Server 5.1 Baseと必要な修正パックをプライマリー・ノードとバックアップ・ノードの両方にインストールするには：

1. ha1ノード上に、WAS Base 5.1インストレーション・イメージを解凍します。

   rm -rf /tmp/was5.1base-install mkdir /tmp/was5.1base-install tar xf c53ipml.tar -C /tmp/was5.1base-install

   
   
   

   ここで、c53ipml.tarは、WAS Base 5.1のインストール用tarファイルです。イメージ・ファイル名は、入手方法によって異なることがあります。

2. ノードha1で、インストール・ウィザードを実行します。

   cd /tmp/was5.1base-install/linuxi386 ./launchpad.sh

   
   
   

   ウィザード画面のフィールドに、次の情報を入力します。

   • Installation directory:/ha/WebSphere/AppServer
   • Node: ha
   • Host: ha.haw2.ibm.com
   • このセットアップでは、HTTPサーバーとMQはすでにインストールされているので、どちらもインストールしないことにしました。これらの機能のインストールを無効にするには、Custom Setupオプションを選択します。

3. 次のコマンドを使用して、インストール・イメージ・ディレクトリーをクリーンアップします。

   rm rf /tmp/was5.1base-install

   
   
   
4. ha1ノード上で下記のコマンドを使用して、WAS Base 5.1 Fix Pack 1インストール・イメージを解凍します。

   rm -rf /tmp/was5.1.1base-install mkdir /tmp/was5.1.1base-install tar xzf was51_fp1_linux.tar.gz -C /tmp/was5.1.1base-install

   
   

   ここで、was51_fp1_linux.tar.gzは、WAS Base 5.1修正パック1のインストール用tarファイルです。イメージ・ファイル名は、入手方法によって異なることがあります。

5. ha1で、下記のコマンドを使用してサイレント・アップデートを実行します。

   . /ha/WebSphere/AppServer/bin/setupCmdLine.sh cd /tmp/was5.1.1base-install ./updateSilent.sh installDir /ha/WebSphere/AppServer -fixpack -install -fixpackDir /tmp/was5.1.1base-install/fixpacks -fixpackID was51_fp1_linux -skipIHS -skipMQ

   
   
   
6. ノードha1で、次のコマンドを使用して修正パックのインストール・イメージ・ディレクトリーをクリーンアップします。

   rm rf /tmp/was5.1.1base-install

   
   
   
7. ha1ノードで、下記のコマンドを使用してWAS Base 5.1 Cumulative Fix 1インストール・イメージを解凍します。

   rm -rf /tmp/was5.1.1.1base-install mkdir /tmp/was5.1.1.1base-install unzip -q was511_cf1_linux.zip -d /tmp/was5.1.1.1base-install

   
   

   ここで、was511_cf1_linux.zipは、WAS Base 5.1.1 Cumulative Fix 1のインストール用zipファイルです。

8. ha1で、下記のコマンドを使用してサイレント・アップデートを実行します。

   . /ha/WebSphere/AppServer/bin/setupCmdLine.sh cd /tmp/was5.1.1.1base-install ./updateSilent.sh installDir /ha/WebSphere/AppServer -fixpack -install -fixpackDir /tmp/was5.1.1.1base-install/fixpacks -fixpackID was511_cf1_linux -skipIHS -skipMQ

   
   
9. ノードha1で、次のコマンドを使用して修正パックのインストール・イメージ・ディレクトリーをクリーンアップします。

   rm rf /tmp/was5.1.1.1base-install

   
   
10. 次に、図1のようなディレクトリー・リンクを作成します。
    1. ha1上のインストレーションからWebSphereログ・ディレクトリーを削除します。

       rm rf /ha/WebSphere/AppServer/logs

       
       
    2. ノードha1とha2の両方で、ローカル・ファイルシステム上にログ用ディレクトリーを作成します。

       chmod 755 /var/log/waslog/AppServer

       
       
    3. ha1とha2の両方のノードで、正しいアクセス権を設定します。

       chmod 755 /var/log/waslog/AppServer

       
       
    4. ノードha1のみ、シンボリック・リンクを作成します。

       ln -s /var/log/waslog/AppServer /ha/WebSphere/AppServer/logs

       
       
11. 次の情報を使用して、ノードha3にWebSphere Application Serverベースをインストールします（上記のステップ1～9のみ）。
    • Installation directory:/opt/WebSphere/AppServer
    • Node: ha3
    • Host: ha3.haw2.ibm.com
    • このセットアップでは、HTTPサーバーとMQはすでにインストールされているので、どちらもインストールしないことにしました。
12. デプロイメント・マネージャー・インストレーションのbinディレクトリーからstartManager.shを実行して、ha1上でデプロイメント・マネージャーを開始します。
13. 各ノードで（アプリケーション・サーバーのbinディレクトリーから）次のコマンドを実行して、WASノードhaおよびha3（上記のWebSphere Application Serverベースのインストール時に作成された）をセルhaNetwork（WebSphere Application Server NDのインストールのステップ4で作成された）に追加します。

    addnode.sh ha

    
    
14. 管理コンソールから、セルが正しく表示されることを確認します。コンソール（http://ha.haw2.ibm.com:9090/admin）を開いて、Application Serverのすべてのノードが表示されることを確認します。
15. すべてを停止します。これは、デプロイメント・マネージャーとそれぞれのWASノード上のノード・エージェントを停止することを意味します。次のコマンドを使用します。
    1. ノード・エージェント：stopNode.sh（Application Serverのbinディレクトリーから）
    2. デプロイメント・マネージャー：stopManager.sh（デプロイメント・マネージャーのbinディレクトリーから）

上に戻る

デプロイメント・マネージャーを管理するためのハートビートの構成

これで、ハートビートを構成して、WebSphere Application Server NDデプロイメント・マネージャーを管理することができます。まず、デプロイメント・マネージャー・プロセスの開始と停止を行うスクリプトを作成します。基本的なスクリプト（wasdmgr）をリスト1に示します。セットアップに応じて、さらにカスタマイズすることができます。このスクリプトを/etc/rc.d/init.dディレクトリーに入れます。

                
#!/bin/bash
#
#	/etc/rc.d/init.d/wasdmgr
#
# Starts the WebSphere Deployment Manager
#
# chkconfig: 345 88 57
# description: Runs  WAS DMGR

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/DeploymentManager/bin
#==============================================================================
SU="sh"
#======================================================================
start() {
	echo "$0: starting websphere deployment manager"
	$SU -c "startManager.sh"
}
#======================================================================
stop() {
	echo "$0: stopping websphere deployment manager"
	$SU -c "stopManager.sh"
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

次に、ノードha1とha2の両方の/etc/ha.d/haresourcesファイルを構成して、wasdmgrスクリプトを含めます。変更済みのファイルの該当部分を以下に示します。

ha1.haw2.ibm.com 9.22.7.46 Filesystem::hanfs.haw2.ibm.com:/ha::/ha::nfs::rw,hard wasdmgr

この行は、ハートビートの開始時に、ha1がクラスターIPアドレスを与え、共有ファイルシステムをマウントし、WebSphere Application Serverデプロイメント・マネージャーを開始することを指定しています。シャットダウン時には、ハートビートは、まず、デプロイメント・マネージャーを停止した後、共有ファイルシステムをアンマウントして、最後にIPをギブアップします。

上に戻る

WebSphere Application Serverノードを管理するためのハートビートの構成

次に、WebSphere Application Serverノード・エージェントとアプリケーション・サーバー・プロセスを管理するためのハートビートを構成します。まず、ノード・エージェントとアプリケーション・サーバー・プロセスの開始と停止を行う2つのスクリプトを作成します。ノード・エージェントを開始するための基本スクリプト（wasnode）をリスト2に、ノード上のアプリケーション・サーバーを開始するためのスクリプト（wasserver）をリスト3に示します。セットアップに応じて、さらにカスタマイズすることができます。これらのスクリプトを/etc/rc.d/init.dディレクトリーに入れます。

                
#!/bin/bash
#
#	/etc/rc.d/init.d/wasnode
#
# Starts the WebSphere Node Agent
#
# chkconfig: 345 88 57
# description: Runs  WAS NODE

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/AppServer/bin
#======================================================================
SU="sh"
#======================================================================
start() {
	echo "$0: starting websphere node agent"
	$SU -c "startNode.sh"
}
#==============================================================================
stop() {
	echo "$0: stopping websphere node agent"
	$SU -c "stopNode.sh"
        #sleep 30
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

                
#!/bin/bash
#
#	/etc/rc.d/init.d/wasserver
#
# Starts the WebSphere Application Server
#
# chkconfig: 345 88 57
# description: Runs  WAS Server

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/AppServer/bin
WASSERVERS="server1"
#======================================================================
SU="sh"
#======================================================================
start() {
    for wasserver in $WASSERVERS ; do
        export wasserver
	echo "$0: starting websphere application server $wasserver"
	$SU -c "startServer.sh $wasserver"
    done
}
#==============================================================================
stop() {
    for wasserver in $WASSERVERS ; do
        export wasserver
	echo "$0: stopping websphere application server $wasserver"
	$SU -c "stopServer.sh $wasserver"
    done
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

次に、ノードha1とha2の両方の/etc/ha.d/haresourcesファイルを構成して、wasnodeおよびwasserverスクリプトを含めます。変更済みのファイルの該当部分を以下に示します。

ha1.haw2.ibm.com 9.22.7.46 Filesystem::hanfs.ibm.com:/ha::/ha::nfs::rw,hard 
wasdmgr wasnode wasserver

この行は、ハートビートの開始時に、ha1がクラスターIPアドレスを与え、共有ファイルシステムをマウントし、WebSphere Application Serverデプロイメント・マネージャー、ノード・エージェント、およびアプリケーション・サーバーを開始することを指定しています。シャットダウン時には、ハートビートは、まず、アプリケーション・サーバーを停止した後、ノード・エージェントを停止し、次にデプロイメント・マネージャーを停止し、共有ファイルシステムをアンマウントして、最後にIPをギブアップします。

上に戻る

デプロイメント・マネージャーのフェイルオーバーのテスト

このセクションでは、デプロイメント・マネージャーの高可用性をテストする方法を説明します。

1. /etc/rc.d/init.d/heartbeat startコマンドを使用して、プライマリー・ノード上でハートビート・サービスを開始し、次にバックアップ・ノード上で開始します。ハートビートが正常に開始されると、ha.cfファイルで構成したIPアドレスを持つ新しいインターフェースが表示されます。ハートビートを開始した後、プライマリー上のログ・ファイル（デフォルトは/var/log/ha-log）を見て、IPのテイクオーバーが行われ、dmgr、ノード・エージェント、アプリケーション・サーバー、およびその他のリソースが開始されていることを確認してください。ハートビートは、バックアップ上のリソースは開始しません。これは、プライマリーに障害が発生しなければ行われません。
2. ha3ノード上のWebSphereノード・エージェントとWebSphere Application Serverを開始します。
3. adminコンソール（http://ha.haw2.ibm.com:9090/admin）から、両方のマシン（ha1とha3）のアプリケーション・サーバーが実行していることを確認します。実行していない場合は、それらを開始します。
4. adminコンソールを使用して、サンプルのエンタープライズ・アプリケーションTestWebSphereHA.ear（下記の「ダウンロード」セクションを参照）をwas\sample_ver_1ディレクトリーに展開します。haとha3の両方のWASノードに展開してください。コンソールを使用して、アプリケーションを起動します。
5. ブラウザで次のURLを指定して、両方のノードでアプリケーションが実行していることを確認します。

   http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Test
   http://ha3.haw2.ibm.com:9080/TestWebSphereHAWeb/Test

   どちらのURLについても、ブラウザに次のようなテキストが表示されるはずです。Test:doGet() Invoked the HA Test Servlet

この時点で、ha1で実行しているデプロイメント・マネージャーによって管理されている2つのWebSphere Application Serverノードにアプリケーションを正常に展開できました。次に、バックアップへのフェイルオーバー後も、この構成情報が保持されるかどうかを確認します。

6. /etc/rc.d/init.d/heartbeat stopコマンドを使用して、プライマリー・システム上のハートビートを停止して、フェイルオーバーをシミュレートします。すべてのサービスがバックアップ・マシン上に表示されるはずです。/var/log/ha-logファイルをチェックして、デプロイメント・マネージャーがバックアップ上で実行していることを確認します。バックアップが制御を引き継いだら、adminコンソールを再び開始してください。2つのアプリケーション・サーバーとエンタープライズ・アプリケーションTestWebSphereHAを確認できるはずです。これは、構成情報が障害を生き延びたことを示します。また、ステップ5を繰り消して、両方のノードでアプリケーションが動作していることを確認してください。
7. adminコンソールを使用して、エンタープライズ・アプリケーションをwas\sample_ver_2ディレクトリーにある新しいバージョンのTestWebSphereHA.earにアップデートします。アップデート時には、haとha3の両方のWASノードを選択してください。
8. アップデート後、マスター構成を保存してください。また、Synchronize changes with Nodesオプションが選択されていることを確認してください。アプリケーションを正常にアップデートできるはずです。ステップ5を再び繰り返します。
9. URL http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Testに対して、ブラウザはTest:doGet() Invoked the HA Test Servlet on remote host : ha2.haw2.ibm.comと表示します。マシンのホスト名も表示されます。これによって、クラスターIP ha.haw2.ibm.comがバックアップ・マシン（ha2.haw2.ibm.com）によってサービスされていることが確認できます。
10. URL http://ha3.haw2.ibm.com:9080/TestWebSphereHAWeb/Testに対して、ブラウザはTest:doGet() Invoked the HA Test Servlet on remote host : ha3.haw2.ibm.comと表示します。
11. 再び、プライマリー上でハートビート・サービスを開始します。これにより、セカンダリ上のWebSphere Application Serverプロセスは停止し、プライマリー上で開始されます。プライマリーはクラスターIPも引き継ぎます。/etc/rc.d/init.d/heartbeat startコマンドを使用します。
12. adminコンソールを再び開始します。2つのアプリケーション・サーバーとアプリケーションTestWebSphereHAを確認できるはずです。これは、アップデートされた構成情報が、プライマリーへのフェイルオーバー後も保持されていることを示します。また、ステップ5を繰り消して、両方のノードでアプリケーションが動作していることを確認してください。

これで、デプロイメント・マネージャーの構成情報がプライマリー・マシンからスタンバイ・マシンへのフェイルオーバー後も維持されることが確認できました。

上に戻る

WebSphere Application Serverノードのフェイルオーバーのテスト

ノードのフェイルオーバーをテストするために、私は持続型カウンター（count）を維持することによって起動回数を追跡するようにサンプル・テスト・アプリケーションを変更しました。この際、カウンターを持続させるメカニズムとしてファイルシステムを選びました。アプリケーションのフェイルオーバーが機能するためには、このデータは共有ディスク上で保持されなければなりません。

WebSphereノードとアプリケーションの高可用性をテストするには、

1. /etc/rc.d/init.d/heartbeat startコマンドを使用して、プライマリー・ノード上でハートビート・サービスを開始し、次にバックアップ・ノード上で開始します。
2. ha3ノード上のWebSphereノード・エージェントとWebSphere Application Serverを開始します。
3. adminコンソール（http://ha.haw2.ibm.com:9090/admin）から、両方のマシン（ha1とha3）のアプリケーション・サーバーが実行していることを確認します。実行していない場合は、それらを開始します。アプリケーションTestWebSphereHAも表示されるはずです。
4. adminコンソールを使用して、エンタープライズ・アプリケーションをwas\sample_ver_3ディレクトリーにある新しいバージョンのTestWebSphereHA.earにアップデートします。アップデート時には、haとha3の両方のWASノードを選択してください。アップデート後、マスター構成を保存してください。また、オプションが選択されていることを確認してください。アプリケーションを正常にアップデートできるはSynchronize changes with Nodesずです。
5. ブラウザでURL http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Testを指定して、ha WebShpereノードでアプリケーションが実行していることを確認します。ブラウザの出力は次のようになるはずです。

   Test:doGet() Invoked the HA Test Servlet on remote host : ha1.haw2.ibm.com Test:doGet() This servlet has been invoked 1 times Test:doGet() Count data file : /ha/WebSphere/AppServer/installedApps/haNetwork /TestWebSphereHA.ear/TestWebSphereHAWeb.war /WEB-INF/count.dat

   
   

   この出力は、アプリケーションがWASノードha上で正常に実行していて、haはプライマリー・ノードha1上で実行していることを示しています。また、count.datファイルが共有ファイルシステム/ha上にあることにも注目してください。このステップをもう一度繰り返すと、カウントは2になります。

6. /etc/rc.d/init.d/heartbeat stopコマンドを使用して、プライマリー・システム上のハートビートを停止して、フェイルオーバーをシミュレートします。バックアップが制御を引き継いだら、adminコンソールを再び開始してください。2つのアプリケーション・サーバーとアプリケーションTestWebSphereHAを確認できるはずです。

   ブラウザで、URL http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Testを指定します。今回のブラウザの出力は、次のようになるはずです。

   Test:doGet() Invoked the HA Test Servlet on remote host : ha2.haw2.ibm.com Test:doGet() This servlet has been invoked 3 times Test:doGet() Count data file : /ha/WebSphere/AppServer/installedApps/haNetwork /TestWebSphereHA.ear/TestWebSphereHAWeb.war /WEB-INF/count.dat

   
   

   この出力は、アプリケーションがWASノードha上で正常に実行していて、haはバックアップ・ノードha2上で実行していることを示しています。また、アプリケーション・データ（countの値）は共有ディスク上にあるので、フェイルオーバー後も維持されています。

これは、アプリケーション・データのフェイルオーバーの簡単な例にすぎません。より現実的な例としては、データベースを使用することになるでしょう。その場合、データベースのHAも実装されなければならず、これについては、このシリーズの次回の記事で説明します。

7. 再び、プライマリー上でハートビート・サービスを開始します。これにより、セカンダリ上のWebSphere Application Serverプロセスは停止し、プライマリー上で開始されます。プライマリーはクラスターIPも引き継ぎます。/etc/rc.d/init.d/heartbeat startコマンドを使用します。

上に戻る

まとめ

可用性は、ITシステムが1日24時間、1週7日間動作し続けるオンデマンド操作環境を構築するための主要な要件です。この記事では、Linux™オペレーティング・システム上でオープン・ソース・ソフトウェアを使用してWebSphere Application Serverの高可用性を実装することによって、ダウンタイムによるビジネスへの影響を軽減する方法を説明しました。このシリーズで概説されているアプローチを使用することによって、予定および予定外の機能停止を大幅に削減して、運用を中断することなく、クラスターのアップグレードやシステム保守を行うことができます。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

• Read the other articles in this series:
  
  
• このシリーズの他の記事も読んでください。
  • 「Linuxでの高可用性ミドルウェア、第1回: HeartbeatとApache Webサーバー」
  • 「Linuxでの高可用性ミドルウェア、第2回: WebSphere MQ」
  • 「Linuxでの高可用性ミドルウェア、第3回: IBM LoadLeveler」
  
  
  
• WebSphere Application ServerのNetwork Deploymentコンフィギュレーションに関する詳細が、WebSphere Application Server Network Deploymentのページに提供されています。
  
  
• High-Availability Linux project Web siteには、Heartbeat success storiesを含めてハートビートに関する情報が提供されています。
  
  
• このシリーズの記事で必要なソフトウェアの大部分は下記からダウンロードすることができます（全てのダウンロードが無料ではありませんので、注意してください）。
  • Red Hat Enterprise Linux 3.0 (2.4.21-15.EL)
  • Heartbeat 1.2.3
  • IBM Java™ 2 SDK 1.4.2
  • IBM WebSphere® MQ for Linux 5.3.0.2 with Fix Pack 7
  • IBM WebSphere Base Edition 5.1.1 for Linux with Cumulative Fix 1
  • IBM DB2® Universal Database™ Enterprise Server Edition V8.1 for Linux
  
  
  
• 可用性に関する詳細な議論と、エンタープライズ・ミドルウェア環境における可用性の計画と維持管理について知るために、「Planning for Availability in the Enterprise」（developerWorks, 2003年12月）を読んでください。
  
  
• クラスターの高可用性機能はよく知られています。「coLinuxとopenMosixで異機種混合のクラスターを構成する」（developerWorks, 2005年2月）や「Linux clustering cornucopia」（developerWorks, 2000年5月）を読むと、クラスターに関する知識をさらに深めることができるでしょう。
  
  
• IBMのWebSphere Application Server support pageには、Fix Packsや製品に関するドキュメンテーションへのリンクが用意されています。
  
  
• IBMでは、HAクラスター実装やWebSphere MQ、マルチベンダー・ネットワーキング・サービス、スモール・ビジネス用のサービス見積もりなどを含めて、豊富な高可用性サービスを提供しています。
  
  
• そのサイトを訪ねる際には、クラスターやHAに関するソリューションもご覧ください。
  
  
• developerWorksのLinuxゾーンには、Linux開発者向けの資料が他にも豊富に用意されています。
  
  
• developerWorks blogsに参加して、developerWorksコミュニティーに加わってください。
  
  
• Linux関連の書籍や他の技術的なトピックをご覧ください。
  
  
• 無料の2枚組DVDセット、SEK for Linuxをご注文ください。DB2®やLotus®、Rational®、Tivoli®、WebSphere® など、Linux用の最新IBMソフトウェアの試用版が含まれています。
  
  
• 皆さんの次期Linux開発プロジェクトを、IBM trial softwareを使って革新してください。developerWorksから直接ダウンロードすることができます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• WebSphere Application ServerとHA
• HA構成でのWebSphere Application Server NDとベースのインストール
• デプロイメント・マネージャーを管理するためのハートビートの構成
• WebSphere Application Serverノードを管理するためのハートビートの構成
• デプロイメント・マネージャーのフェイルオーバーのテスト
• WebSphere Application Serverノードのフェイルオーバーのテスト
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント