新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

WAS虎の巻(運用管理編) 第2回「不定期運用」

今回は、「運用管理編 第2回」として、前回に引き続き、WebSphere Application Server (WAS) を利用したWebシステム基盤の運用管理を取り上げます。

テーマは、「不定期運用」です。Webシステム基盤を運用する上で不定期のタイミングで必要となる運用管理作業に焦点をあてます。取り上げる内容は以下の3項目です。

  • 構成変更・管理
  • アプリケーション・リリース
  • 修正プログラム適用

では、項目ごとに詳細を説明します。

1

構成変更・管理

WASの設定のほとんどは、xml形式のファイルに記述されます。このxmlファイルは、数が多くパラメータ名が複雑なこともあり、直接これらのファイルを開いての変更作業はサポートされていません。そこで、WASでは、このファイル群を一括して管理できるように管理専用のツールが用意されています。

この章では、それらのツールを使用したWAS構成の変更・管理について説明します。

1.1 構成変更方法

WAS虎の巻:第2回「WebSphere Application Server(WAS)の複数台構成」で説明しましたが、WASの構成情報のファイル保持方法は、WAS BaseとWAS NDで異なっています。 WAS Baseでは通常1つのノードのみが存在し、そのノードが全体の構成情報を保持します。一方、WAS NDではデプロイメント・マネージャー (DM) が全体の構成を保持し、DM以外のノードは、自ノードの情報のみを保持します。このため、構成変更をする際には、WAS Baseでは各ノードに保持された構成情報の変更のみを行いますが、WAS NDでは、DMにあるマスター情報を変更してから、各ノード上にあるコピーの情報に変更を反映する必要があります。 この反映作業は同期化と呼ばれます。同期化については、「1-2 構成同期方法」で説明します。

alt

ここでは、同期化作業を除いたWAS Baseの全体情報、WAS NDのマスター情報を変更する方法について説明します。変更作業に用いる管理ツールはいくつかありますが、使用頻度の高い管理コンソールとwsadminツールを取り上げます。

管理コンソール:

構成変更をする際に最もよく使用されるのは管理コンソールと呼ばれるWebブラウザベースのツールです。このツールの実体は、デプロイされたEARアプリケーションです。このアプリケーションは、WAS Baseの場合はアプリケーション・サーバー・プロセスに、WAS NDの場合は、DMプロセスにインストールされています。(以下、管理コンソール・アプリケーションがインストールされているプロセスを管理プロセスと呼びます。) 使用方法は、管理プロセスを起動した後(プロセスの起動方法は、「運用管理編: 第1回 定常運用」を参照してください。)、Webブラウザから以下のURLを入力してアクセスします。なお、管理セキュリティーが有効になっている場合は、httpsでのアクセスとなりますが、以下のURLでアクセスした場合でも、httpsへ自動的にリダイレクトされます。

http://<管理サーバーホスト名>:<ポート番号>/ibm/console/

※管理サーバーホスト名:管理プロセスが起動しているサーバーのホスト名またはIPアドレス。 ※ポート番号:管理プロセスのWC_adminhostポート。デフォルトは9060です。

起動直後の画面は以下のようになります。(WAS V7の画面。管理セキュリティー有効。)

alt

ログイン画面は、管理セキュリティーの有無によって変わってきます。 管理セキュリティーが有効になっている場合は、WASのリポジトリーに登録されたユーザーID/パスワードを指定してログインする必要があります。無効の場合は、任意のユーザー名でログイン可能です。 ログインすると、画面左側にサーバー、アプリケーションなどのメニューが一覧で表示され、右側にメニューで選択した内容やパラメータの設定画面が表示されます。

alt

ここで、「初期ヒープ・サイズ」、「最大ヒープ・サイズ」という項目があるので、どちらも1024という値を入力します。入力後、下方にある「適用」または「OK」のボタンをクリックします。すると画面の上方に以下のようなボックスが表示されます。

alt

先ほどの「適用」または「OK」をクリックした段階では、ヒープ・サイズを1024MBに変更したという情報は一時領域に保管されているだけです。一時領域から実際の設定ファイルへの反映は、この「保存」を実行することによって初めて反映されます。 また、「検討」を選択すると、ヒープ・サイズ変更の破棄をすることも可能です。

管理コンソールを使った設定変更の流れは以上のようになります。 WAS NDの場合は、この作業によってDMのマスター情報が変更されるだけですので、続いて各ノードへの変更同期化作業が必要になります。WAS Baseの場合は、これで変更作業は終了です。

wsadmin:

wsadminは管理用スクリプト・インターフェースです。 WASの構成変更はすべてwsadminを用いて実施することが可能です。wsadminは、通常、DMなどの管理プロセスに接続して、動作します。 言語仕様として、JaclとJythonの2種類がサポートされています。 wsadminには、インタラクティブ・モード、コマンド実行モード、スクリプト実行モードの3つの実行モードがあります。インタラクティブ・モードは対話形式で、一つずつコマンドの入力、実行を繰り返します。コマンド実行モードでは、実行したい処理コマンドをwsadminの引数として渡します。1回の実行につき、1処理のみの実行になります。スクリプト実行モードでは、処理内容をあらかじめ記述したスクリプト・ファイルを引数に渡して実行します。

ここでは、インタラクティブ・モードを使って、先ほど管理コンソールで実施したヒープ・サイズの変更を実施してみましょう。

① wsadminの起動

wsadminツールは、ルートディレクトリ(AppServerディレクトリ)と各プロファイル中のbinディレクトリごとに存在しますが、通常はDMなど管理プロセスのプロファイルにあるものを使用します。起動時に管理プロセスのホスト名とポートを指定して接続しますので、wsadmin起動前に管理プロセスは起動させた状態にしておいてください。さらに下記例では、使用言語としてJythonを指定しています。

> cd "C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin"
> wsadmin.bat -lang jython -host localhost -port 8879
WASX7209I: ノード TestHostCellManager01 のプロセス "dmgr" に、SOAP コネクターを使用し
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7031I: ヘルプを表示するには、"print Help.help()" と入力してください。
wsadmin>

※AIX、LinuxなどUnixの場合は、”wsadmin.bat”ではなく”wsadmin.sh”です。 起動が終了すると、「wsadmin>」のプロンプトが返されます。このプロンプトにコマンドを入力します。

② コマンドの入力

wsadminコマンドによる管理操作は、オブジェクトという単位を通じて行います。オブジェクトには以下の5種類があります。

  • AdminControl: 操作コマンドの実行に使用します。
  • AdminConfig: WAS構成の作成または変更に使用します。
  • AdminApp: アプリケーションの管理に使用します。
  • AdminTask: 管理コマンドの実行に使用します。
  • Help: 一般ヘルプを得るために使用します。

このオブジェクトを使用したJython言語でのコマンド実行は、以下のような書式になります。

wsadmin> [オブジェクト].[コマンド] [引数]

初期ヒープ・サイズの変更には、AdminTaskオブジェクトのsetJVMInitialHeapSizeコマンドが使用できます。上記書式に沿ってコマンドを実行すると以下のようになります。(対象サーバー:clustermember02 / ヒープ・サイズ:1024MB)

wsadmin>AdminTask.setJVMInitialHeapSize('[-serverName clustermember02 -nodeName
 TestHostNode03 -initialHeapSize 1024]')
'true'

成功すると‘true’の文字列が返されます。

同様に最大ヒープ・サイズを設定します。最大ヒープ・サイズは、setJVMMaxHeapSizeコマンドを使って設定します。

wsadmin>AdminTask.setJVMMaxHeapSize('[-serverName clustermember02 -nodeName
 TestHostNode03 -maximumHeapSize 1024]')
'true'

③ 設定の保存

上記で実行したwsadminコマンドの内容を保存します。上記2つのコマンド実行時点では、まだ構成が保存されていませんので、必ず保存をおこなってください。変更の保存は、AdminConfigオブジェクトのsaveコマンドを使用します。

wsadmin>AdminConfig.save()
‘’
wsadmin>

この後、WAS NDでは、各ノードとの同期化作業が必要となります。設定に引き続き、同期化作業にもwsadminを使用することが可能です。詳細については、「1-2 構成同期方法」を参照してください。

以上、インタラクティブ・モードでコマンドを実行しましたが、これらの内容を一つのファイルにまとめて一挙に実行することも可能です。これは、先ほど触れたスクリプト実行モードと呼ばれる実行方法でシェル・スクリプトなどを作成する際には有用です。実行方法は以下のように-fオプションでスクリプト・ファイルを指定して実行します。

実行コマンド:

> cd "C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin"
> wsadmin.bat -lang jython -host localhost -port 8879 -f C:\test\heapchange.py

C:\test\heapchange.pyの中身:

# ヒープ・サイズの変更
AdminTask.setJVMInitialHeapSize('[-serverName clustermember02 -nodeName TestHostNode03
 -initialHeapSize 1024]')
AdminTask.setJVMMaxHeapSize('[-serverName clustermember02 -nodeName TestHostNode03
 -maximumHeapSize 1024]')

# 変更を保存
AdminConfig.save()

その他、様々な構成変更をwsadminコマンドを使用して実施することが可能です。詳しくは以下の資料を参照してください。

1.2 構成同期方法

ここでは、変更内容を同期化する方法について説明します。 「1-1 構成変更方法」の冒頭でも述べましたが、同期化の必要があるのは、WAS NDのみです。WAS Baseの場合は、構成変更しても同期化の必要はありません。

同期化とは、DMが持っているマスター構成情報を各ノードの構成リポジトリーに反映することです。同期化を行うと、必ずDM情報がノード上の情報を上書きます。手作業で直接、ノード上のxmlファイルを変更した場合などは、同期化を実行すると、その変更内容がDMのマスター情報に上書きされてしまうことに注意してください。

それでは、同期化方法について説明します。 同期化の方法も構成変更と同様、いくつかあります。ここでは、以下の3つの方法を取り上げます。

  • 管理コンソールでの同期化
  • wsadminでの同期化
  • syncNodeコマンドでの同期化

通常、構成時や運用時に同期化を実行する場合は、管理コンソールおよびwsadminを使用します。一方、syncNodeコマンドはこれらの方法を使っても同期化が失敗する場合など一般的に異常時に使用します。

管理コンソールでの同期化

管理コンソールで構成情報を同期化する場合は、DMプロセスと同期先のノード・エージェントとの間で構成情報のやり取りが行われます。したがって、同期前に、DMプロセスとノード・エージェント・プロセスを起動させてください。(プロセスの起動方法は、「運用管理編: 第1回 定常運用」を参照してください。)以下は、DM、ノード・エージェントの各プロセスが起動していることを前提に話を進めます。

管理コンソールにログイン後、左のメニューから「システム管理 > ノード」を選択します。

altWAS V7.0 Information Center – ノードの追加、管理、および除去

  • WAS V8.0 Information Center – ノードの追加、管理、および除去
  • wsadminでの同期化

    「1-1 構成変更方法」でwsadminコマンドでの設定方法を説明しましたが、同期化もwsadminを使用して実行することができます。ここでは、同期化の実行例として、「1-1 構成変更方法」にてwsadminで設定した内容を同期化する場合を考えます。 同期化は、AdminControlオブジェクトのinvokeコマンドを使用します。ただ、ここで1つ注意点があります。invokeコマンド実行時には、同期先のノードを指定する必要がありますが、ノード指定の際には、通常の管理コンソールなどで見られるノード名が使用できず、オブジェクト名と呼ばれる値を取得しなければなりません。 オブジェクト名はAdminControlオブジェクトのcompleteObjectNameコマンドで取得できます。下記では、ノード名「TestHostNode03」に対応するオブジェクト名を取得し、その値を「Sync1」という変数に代入しています。

    Sync1 = AdminControl.completeObjectName('type=NodeSync,node=TestHostNode03,*')
    

    ちなみにSync1の値はprintコマンドで確認できます。

    wsadmin>print Sync1
    WebSphere:name=nodeSync,process=nodeagent,platform=common,node=TestHostNode03,
    diagnosticProvider=true,version=7.0.0.15,type=NodeSync,mbeanIdentifier=nodeSync,cell
    =TestHostCell01,spec=1.0
    

    このSync1に対して同期化コマンドを実行します。同期化が成功すると’true’の文字列が返ってきます。

    wsadmin>AdminControl.invoke(Sync1, 'sync')
    'true'
    

    これで同期化が完了です。

    なお、以下のように「1-1 構成変更方法」のスクリプト・ファイルに同期化の内容をつけ加えると、ヒープ・サイズ設定・設定保存・同期化の一連の流れを自動化することも可能です。

    同期化実行を含めたスクリプト・ファイルC:\test\heapchange.py

    # ヒープ・サイズの変更
    AdminTask.setJVMInitialHeapSize('[-serverName clustermember02 -nodeName TestHostNode03
     -initialHeapSize 1024]')
    AdminTask.setJVMMaxHeapSize('[-serverName clustermember02 -nodeName TestHostNode03
     -maximumHeapSize 1024]')
    
    # 変更を保存
    AdminConfig.save()
    
    # 同期化実行
    Sync1 = AdminControl.completeObjectName('type=NodeSync,node=TestHostNode03,*')
    AdminControl.invoke(Sync1, 'sync')
    

    ※「#」から始まる行はコメントです。

    syncNodeコマンドでの同期化

    証明書やセキュリティ設定などをDMのみで更新した後、各ノードへの同期化を長く行わなかった場合などに、DMとノード・エージェントの通信自体がうまくいかなくなることがあります。この状態では、管理コンソールやwsadminを使用した同期化は失敗します。 この場合、同期化するにはノード・エージェントを経由せずにノード上にある構成情報をDMのマスター情報と同期させる必要がありますが、これを実現するのがsyncNodeコマンドです。

    syncNodeコマンドはノード側から、ノード・エージェントを停止させた状態で実行します。 コマンドの基本的な書式は以下になります。

    syncNode <DMホスト名> <DM接続ポート>は、通常DMのSOAP_CONNECTOR_ADDRESS。デフォルトは8879。

    syncNodeコマンドには、他にも多数のオプションがあります。詳しくは以下のリンクを参照ください。

    実行例を参考までに以下に添付します。

    コマンド実行例:

    C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\bin>syncNode.bat TestHost 8879
    ADMU0116I: ツール情報は次のファイルに記録されています: C:\Program
               Files\IBM\WebSphere\AppServer\profiles\Custom01\logs\syncNode.log
    ADMU0128I: Custom01 プロファイルを使用してツールを開始しています
    ADMU0401I: Deployment Manager TestHost とノード TestHostNode03 の syncNode
               オペレーションを開始します: 8879
    ADMU0016I: ノードとセルの間で構成を同期中です。
    ADMU0402I: ノード TestHostNode03 の構成が Deployment Manager TestHost と同期化
    されました:
               8879
    

    同期化設定について

    ここまで手動で同期化を実行する方法について述べましたが、ここでは、DMとノード・エージェントの自動同期化設定について説明します。 デフォルトでは、DMとノード・エージェントは1分間隔で自動的に同期するように構成されています。この同期間隔はデフォルトの1分から変更すことが可能です。また、自動同期を無効化することもできます。設定は、管理コンソールにて、「システム管理 > ノード・エージェント > nodeagent > ファイル同期化サービス」の画面で変更します。

    alt

    但し、管理セキュリティーが有効になっている状態で、自動同期の無効化や同期間隔を延ばす場合は、注意が必要です。デフォルト設定で、DMが証明書を1年間隔で更新しますが、この更新時に自動同期が無効あるいは、同期間隔が長くなっていると、更新した証明書が各ノードに同期されず、DMとノード・エージェント間の通信が不可能になることがあります。この状態から復旧させるには、syncNodeコマンドを実行する必要があります。詳細は以下の資料を参照ください。

    【考慮事項】WAS ND V7.0 証明書自動更新機能について (WAS-09-024)

    2

    アプリケーション・リリース

    WASでアプリケーションに関連する作業が発生するのは、大きく分けると、新規に作ったアプリケーションを最初に導入する際と、プロジェクトサービスイン後にアプリケーションを更新・メンテナンスする際です。この章では、それぞれの作業に対応して、以下2つの観点から説明します。

    • アプリケーション導入(新規アプリケーションのインストール)
    • アプリケーション更新(導入後メンテナンス)

    2.1 アプリケーション導入

    Java EE仕様では、WASのようなアプリケーション・サーバーは、EARファイルという単位でパッケージングされたアプリケーションを導入(デプロイとも呼ばれます)することによって、はじめてWebシステムとして動作するように定義されています。 ここでは、ブラウザからIBM HTTP Server (IHS) を経由してWASクラスターにアクセスする環境を前提とし、アプリケーション(EARファイル)が完成して初めてWASに導入するという状況を考えます。

    アプリケーションのデプロイに関連して必要となる作業は、主に以下の2つとなります。

    alt

    ①アプリケーションのデプロイ ②プラグイン構成ファイルの作成

    各々の具体的な内容を以下、説明します。

    ① アプリケーションのデプロイ

    新規アプリケーションのデプロイは、管理コンソールから行われるのが一般的です。デプロイ作業は、ウィザード形式で実行できるようになっており、各ステップでパラメーターを指定することで、完了できるようになっています。ウィザードは管理コンソールの「新規アプリケーション」メニューの「新規エンタープライズ・アプリケーション」または「WebSphereエンタープライズ・アプリケーション」メニューの「インストール」ボタンを実行することによって起動します。

    alt

    デプロイできる単位は、クラスター、アプリケーション・サーバー、Webサーバーです。ちなみにクラスター・メンバーになっているアプリケーション・サーバーの場合、そのアプリケーション・サーバー単体をマッピングすることはできません。クラスター・メンバーになっているアプリケーション・サーバーへ割り振りを行いたい場合は、必ずそのメンバーが所属するクラスターをマッピングする必要があります。 また、Webサーバー・プラグインが利用するプラグイン構成ファイル作成には、この設定を元に割り振り先アプリケーション・サーバーと割り振り担当Webサーバーが決定されます。割り振りを実行するWebサーバーも、このマップ対象のサーバーに含めてください。 なお、アプリケーション・デプロイ後も構成変更と同じく、保存およびノードとの同期化作業が必要ですので、忘れずに実行してください。

    アプリケーション・デプロイ時には、その他さまざまな設定をすることが可能です。詳しくは以下を参照してください。

    ② プラグイン構成ファイルの作成

    WebブラウザからIHSを経由してアプリケーションにアクセスする際には、IHSにロードされるプラグイン・モジュールがIHSで受け取ったリクエストをアプリケーション・サーバーへ割り振る仲介役を担当します。このとき、プラグイン・モジュールに、割り振り先のアプリケーションやサーバーの情報を教えてあげる必要があります。その情報が記載されたファイルが、プラグイン構成ファイル(plugin-cfg.xml)と呼ばれるファイルです。プラグイン構成ファイルには、割り振り先のアプリケーション・サーバーのホスト名やポート番号、アプリケーションのURL(コンテキストルートと呼ばれます)などが記載されています。

    例:プラグイン構成ファイル(plugin-cfg.xml)の一部(太字は、ホスト名、ポート、コンテキストルート)

       <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false"
     IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="TestCluster"
     PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
          <Server CloneID="16gqslpgd" ConnectTimeout="5" ExtendedHandshake="false"
     LoadBalanceWeight="2" MaxConnections="-1" Name="TestHostNode03_clustermember01"
     ServerIOTimeout="60" WaitForContinue="false">
             <Transport Hostname="TestHost" Port="9086" Protocol="http"/><Transport Hostname="TestHost" Port="9449" Protocol="https">
                <Property Name="keyring" Value="c:\Program
     Files\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.kdb"/>
                <Property Name="stashfile" Value="c:\Program
     Files\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.sth"/>
             </Transport>
          </Server>
          <Server CloneID="16gqsm86k" ConnectTimeout="5" ExtendedHandshake="false"
     LoadBalanceWeight="2" MaxConnections="-1" Name="TestHostNode03_clustermember02"
     ServerIOTimeout="60" WaitForContinue="false">
             <Transport Hostname="TestHost" Port="9087" Protocol="http"/><Transport Hostname="TestHost" Port="9450" Protocol="https">
                <Property Name="keyring" Value="c:\Program
     Files\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.kdb"/>
                <Property Name="stashfile" Value="c:\Program
     Files\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.sth"/>
             </Transport>
          </Server>
          <PrimaryServers>
             <Server Name="TestHostNode03_clustermember01"/>
             <Server Name="TestHostNode03_clustermember02"/>
          </PrimaryServers>
       </ServerCluster>
       <UriGroup Name="default_host_TestCluster_URIs">
          <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
     Name="/SampleWeb/*"/>
       </UriGroup>
       <Route ServerCluster="TestCluster" UriGroup="default_host_TestCluster_URIs"
     VirtualHostGroup="default_host"/>
    

    ミドルウェアの起動順序・停止順序は、ミドルウェア間やプロセス間の依存関係に基づいて決定します。連携している一連のミドルウェアの起動作業は、バックエンド・システムから実施することが一般的です。

    割り振り先情報以外に、アプリケーション・サーバーへの接続時タイムアウトやログ・レベルなどのプラグインの動作設定に関する内容も、このファイルに記述されます。他の設定内容については、以下の資料およびそのサブトピック・関連資料のリンクを参照してください。

    プラグイン構成ファイルの作成は、管理コンソールで実施することが可能です。以下の図は、管理コンソールの「Webサーバー」のメニューです。Webサーバー(webserver1)の左横のチェックボックスにチェックすることにより、「プラグインの生成」および「プラグインの伝搬」のボタンが表示されます。「プラグインの生成」を実行すると、デプロイメント・マネージャー・プロファイル内にファイルが作成されます。この作成されたファイルは「プラグインの伝搬」によって、Webサーバーに定義されたプラグイン構成ファイルのパスに転送されます。

    alt

    転送終了後、新しく伝搬されたファイルは、デフォルトで60秒経過すると、反映されます(「構成リフレッシュ間隔」の設定値)。伝搬後、すぐに反映したい場合は、IHSを再起動してください。

    また、管理コンソール以外にGenPluginCfgというコマンドベースのプラグイン構成ファイル作成ツールがあります。 EARをクラスターにデプロイした場合、管理コンソールを使用してプラグイン構成ファイルを作成すると、IHSからの割り振り先はクラスターに所属する全てのアプリケーション・サーバーになってしまいます(これを1:N構成と呼びます)。割り振り先を全てではなく、特定のアプリケーション・サーバーに固定したい場合(1:1構成)、このGenPluginCfgコマンドが使用されます。 1:1構成の構成方法およびGenPluginCfgコマンドの詳細については以下の資料を参照してください。

    WebSphere Application Server V7.0によるWebシステム基盤設計ワークショップ資料 – 運用設計/運用設計 -参考-

    2.2 アプリケーション更新

    アプリケーションをインストールした後、機能追加や不具合修正などで、WASにインストールしたアプリケーションを修正後のアプリケーションに更新したいという状況は多々発生します。 このときのアプリケーション更新手段として、WASはいくつかの方法を提供しています。ここでは、管理コンソールとwsadminを使った更新方法について説明します。

    管理コンソール:

    まず、管理コンソールによるアプリケーション更新です。 更新作業は管理コンソールの「WebSphereエンタープライズ・アプリケーション」メニューを選択して、表示される画面の「更新」ボタンによって行います。(更新したいアプリケーションにチェックしてから「更新」ボタンをクリックします。)

    altWAS V7.0 Information Center – コンソールを使用したエンタープライズ・アプリケーションの更新

  • WAS V8.0 Information Center -コンソールを使用したエンタープライズ・アプリケーションの更新
  • wsadmin:

    デプロイしたアプリケーションを何度も更新する場合、そのたびに管理コンソールにログインして同じ操作を実行するのは、手間がかかる作業です。この場合、wsadminのスクリプト実行モードを使ってシェル・スクリプト等を作ることによって更新作業の効率化を図ることができます。スクリプト実行モードでの実行方法は、「1-1 構成変更方法」を参照してください。

    アプリケーションの更新には、AdminAppオブジェクトのupdateコマンドを使用します。これを使用し、「Sample」という名前でデプロイされているアプリケーションを、「C:\test\Sample.ear」のEARファイルに更新するスクリプト・ファイルの例を以下に示します。構成変更の場合と同様に、変更の保存、同期化実行が必要です。(同期化実行はNDの場合のみ)

    # アプリケーションの更新
    AdminApp.update('Sample','app','[-operation update -contents C:/test/Sample.ear]')
    
    # 変更を保存
    AdminConfig.save()
    
    # 同期化実行
    Sync1 = AdminControl.completeObjectName('type=NodeSync,node=TestHostNode03,*')
    AdminControl.invoke(Sync1, 'sync')
    

    アプリケーションのデプロイ直後に、続けてアプリケーションを起動する場合は、注意が必要です。 デプロイ・プロセスとしてEARファイルの置き換え後、バイナリー・ファイルの解凍プロセスが続きますが、その解凍プロセスが終了するまでは、アプリケーションを起動することはできません。 上記スクリプト・ファイルを実行すると、デプロイ・プロセスとしては終了とWASに認識されますが、解凍プロセスは終了していません。そのため、AdminAppオブジェクトのisAppReady、getDeployStatusコマンドを使用して、アプリケーションの処理状況を確認して、全て終了してからアプリケーション起動を実行してください。 起動時の注意事項およびAdminAppオブジェクトによる更新作業の詳細は以下の資料を参照ください。

    その他更新方法

    いままで述べた管理コンソールおよびwsadminコマンドによる更新方法は、ともにDM上にあるアプリケーションの情報を更新し、ノードに配布するという手順をきちんと踏まえた方法になります。 WASでは、それ以外にも一部のjspだけをアプリケーションが稼働しているアプリケーション・サーバーでのみ置き換えるホットデプロイメントという機能や、特定のディレクトリーを指定し、そこにEARファイルをドラッグアンドドロップすることによってアプリケーションを更新できるモニター対象ディレクトリという機能があります。詳細は以下の資料を参照してください。

    WebSphere Application Server V8 アナウンスメント・ワークショップ資料 – アプリケーション管理

    これらの機能は、WASのデプロイ作業を軽減してくれる便利な機能ですが、DMのマスター情報と各ノード上のアプリケーションの情報が異なったり、予期せぬ更新を引き起こしたりする可能性がありますので、実際に使用する際には、本番環境ではなく開発環境の使用にとどめておくことをお勧めします。

    3

    修正プログラム適用

    WASを導入した後、不具合修正やセキュリティ脆弱性対応などで、修正プログラムがIBMから提供されることがあります。これらの情報はIBMのWebSphereサポート・サイトに公開されています。 また、この修正プログラムを一つ一つ選択して、適用することも煩雑であることから、定期的にこれらの修正プログラムを集めたFix Packと呼ばれる修正プログラム・パッケージがIBMから提供されています。 システムの使用状況等で、停止するのが困難であったり、再びテストが必要になったりなどの事情で、適用するのが困難な場合もあると思いますが、可能ならばなるべく最新のFix Packを適用してください。

    適用に当たっては、以下の点に注意して下さい。

    • 適用前には必ずプロセスを停止してください。プロセス停止の具体的な手順は「運用管理編: 第1回 定常運用」を参照してください。
    • 適用作業を実施する前に、以前の状態に戻せるようにバックアップを取得することをお勧めします。バックアップ取得については以下の資料を参照してください。
    • WebSphere Application Server V7.0によるWebシステム基盤設計ワークショップ資料 – 運用設計
    • WAS NDのみの注意点となりますが、DMのFixレベルは必ずセル内の他ノードよりも新しく(高く)なっている必要があります。WAS NDをご使用の場合は、DMがインストールされているノードから適用作業を実施してください。

    では以下、修正プログラムの適用方法について説明します。

    3.1 Fix Pack適用

    まずは、Fix Packの適用方法についてです。 適用の流れは以下のようになります。

    alt

    WASのFix PackはIBMのWebサイトで提供されているため、まずは、必要なFixをダウンロードします。次に、V7、V8共にFix Packを適用するためのツールが存在し、これらの更新も必要になる場合があります。各Fix Packには、適用ツールの前提バージョンがあり、そのバージョンに満たない場合は、適用作業ができません。Fix Pack適用の際には、合わせてツールのバージョンも最新に更新しておけばいいでしょう。 上図にもあります通り、V8とV7以前とでは使用ツールが異なっているため、適用方法は、V8とそれ以前で、大きく異なっています。以降、V8とV7以前に分けて、説明します。

    WAS V8の場合

    ① 必要モジュールのダウンロード:

    必要モジュールの準備ですが、WAS V8では適用対象マシンがインターネット環境に接続できる場合、適用作業中に自動的にモジュールをダウンロードしてくれるため、事前の準備は必要ありません。インターネット環境に接続できない場合には、事前にモジュールをダウンロードしておかなくてはなりません。ダウンロードすべきモジュールは、以下になります。

    • IBM Installation ManagerのFix
    • WAS関連Fix Pack

    WAS V8でFix Pack適用に使用するツールは、IBM Installation Manager (以下、IIM)と呼ばれます。 このツールは、WAS V8のインストールにも使用されます。このツールのFixは下記サイトからダウンロードすることができます。

    IBM Support Portal: Download

    ※アクセスするにはIBM IDの登録が必要です。

    上記サイトにある「View IBM Installation Manager fixes」のリンクをクリックすると、ウィザード形式で必要なFixのダウンロードが可能になります。

    次に、WASのFix Packをダウンロードします。ダウンロード・サイトは下記になります。

    上記いずれかのサイトにアクセスすると、WASのバージョンごとにFix Packダウンロード・ページへのリンクがあります。V8のリンクからダウンロード・サイトに移動し、適用したいFix Packレベルのページへと移動します。WAS本体以外にもIHS、プラグイン、JDKなどのFix Packがダウンロードできますので、ご使用の環境に合わせて必要なモジュールをダウンロードしてください。 また、ダウンロードしたモジュールはzip形式になっています。適用前に全て解凍してください。 zipファイルがpart1、part2に分かれている場合は、両者を解凍した後、part2のフォルダの中身をpart1の同名フォルダの中身へとコピーしてください。Fix適用にあたっては両者の中身が必要になります。

    ② Fix適用ツールのアップデート:

    IIMのアップデートは、IIM自身が持つ更新機能を使用します。更新自体は、WASのFix Pack適用時に行われますが、その際にIIMのFixがどこにあるかを指定しておく必要があります。 IIMがインストールされたマシンがインターネット環境に接続されている場合は、WASのFix Pack適用時に必要なFixをインターネット経由で検索に行くため、このステップは飛ばしてください。 インターネットに接続されていないオフライン環境では、IIMにFix内のファイル(repository.config)のパスをリポジトリーという形で設定する必要があります。

    設定方法は、以下の資料を参照してください。

    WebSphere Application Server V8.0 Fix 適用手順書

    ③ Fix Pack適用作業:

    WASのFix Pack適用もIIM更新と同じく、インターネット環境かオフライン環境かで作業内容が異なります。オフライン環境の場合は、Fix Packの場所をIIMに設定する必要があり、「②Fix適用ツールのアップデート」と同様にダウロードしたFix Pack内にあるファイル(repository.config)のパスをIIMに設定します。インターネット環境の場合は、追加の必要はありません。

    上記の準備が済んだ後、Fix Pack適用作業に移ります。適用作業はIIMのウィザードに従って実施します。詳細な手順は、下記サイトに資料がありますので、そちらを参照してください。

    WebSphere Application Server V8.0 Fix 適用手順書

    WAS V7以前の場合

    ① 必要モジュールのダウンロード:

    WAS V7では、更新ツールとしてUpdate Installerというツールを用いますので、Fix Pack適用にあたっては以下のモジュールが必要になります。

    • Update InstallerのFix
    • WAS関連Fix Pack

    Update InstallerにはIIMのようにインターネットに接続して自動的にFixをダウンロードする機能はありませんので、インターネット接続環境であっても、新しいバージョンがWebサイトにある場合は必ずダウンロードしてください。

    Update Installer、WAS関連Fix Packのダウンロード・サイトは、共に下記サイトから移動できます。下記サイトにある対象バージョンのリンク先に移動してから、適用したいFix Packのレベルのページへと移動します。

    ダウンロードしたファイルは、Update Installerがzipなどの圧縮ファイル、Fix Packは.pakという拡張子付きのファイルになっています。更新前にUpdate Installerは解凍してください。Fix Packはそのままで構いません。

    ② Fix適用ツールのアップデート:

    Update Installerは、IIMのように自分自身を更新する機能をもっていません。以前のバージョンのUpdate Installerが既にインストールされている場合は、アンインストールする必要があります。 アンインストールするには「〈Update Installerのインストール・ディレクトリー〉/uninstall」ディレクトリにあるuninstallまたはuninstall.exeを実行してください。 アンインストール後、ダウンロードしたUpdate Installerをインストールします。解凍したディレクトリの中にある「UpdateInstaller/install (またはinstall.exe)」を実行してください。 アンイントール、インストールともにコマンド実行後、ウィザードが起動しますので、それに沿って実行してください。

    ③ Fix Pack適用作業:

    Fix Pack適用はUpdate Installer経由で実施します。Update InstallerもIIMと同じくウィザード形式で更新作業を実施するようになっています。こちらも詳細な手順が下記サイトにありますので、そちらを参照してください。

    WebSphere Application Server V7.0 Fix適用ガイド

    3.2 緊急Fix適用

    不具合が原因で障害が発生し、その対応としてサポート部門から個別Fixという形で修正プログラムが送付されてくる場合や、緊急度の高いFixがリリースされた場合など、Fix Packという形ではなく、個別のFixを適用する必要に迫られることがあります。 個別Fixの一部は以下のWebサイトにあるバージョンごとのリンク先から入手できますが(Fix Packではなく、個別の問題解決策情報が記載されているAPARリンクから)、基本的にはWASサポート部門からの送付となります。以下のサイトに必要なFixが見つからない場合は、IBM ソフトウェア・メンテナンス テクニカル・サポートに問い合わせて、Fixを入手してください。

    Fixes by version for WebSphere Application Server

    個別Fixの適用方法は、Fix Packと同様です。使用するツールも同様のため、「3-1 Fix Pack適用」の手順に沿って適用してください。

    WAS虎の巻 第6回 運用管理編 その2では「不定期運用」についてご説明しました。次回、運用管理編 その3では「障害時運用」についてご説明します。