レベル: 初級 山口 崇, ワークプレース, ISE
2009年 5月 26日 WebSphere Application Serverがミドルウェアとしてコモディティ化する中、システムの導入･構成、Fix適用などの作業に対しては最低限のコストおよびワークロードでの実施が求められている。そうした状況に対し、製品機能を有効活用し、作業負荷を軽減させるためのアイデアを提示する。
はじめに
WebSphere Application Server Network Deployment (WAS ND)を導入する際、特に複数台のノードでセルを組みクラスター環境を構築する場合、個々のインストールは単純作業であるとはいえ、導入･構成作業量は台数に比例して多くなり、多大な時間がかかります。また、現行稼動中のセルに対して物理ノード追加を行う場合、新規構築と同様な導入･構成作業を行うとしても、一度同等作業実施済みであるため新規サーバー構築と同様のコストをかるのは非効率です。
システム運用開始後も、障害対応などでパッチ、暫定フィックス（iFix）や保守パッケージ（Fix Pack）の適用作業が必要になる場合があります。これも複数台環境の各ノードに対して適用する必要があるため、作業量はサーバー数に比例して増えていき、その時間はサービスを停止する必要があります。
当文書ではこうした課題に対し、WAS V7.0およびWebSphere Virtual Enterprise (WVE) V6.1で提供されている集中インストレーション・マネージャー機能など、複数台WASの導入およびFix適用作業の際に役立つ製品機能および運用手順を整理し、作業量軽減・時間短縮につながる方策をご紹介します。
WASシステム導入・運用の課題点
ここではWASシステムの導入およびFix適用作業に対し、実システムでありがちな課題点を整理していきます。
導入時
WASシステム導入時には、製品のインストールから始まり、最新Fix Pack・必要iFixの適用、プロファイルの作成、セル統合、サーバーおよびクラスター作成、Webサーバー構成、アプリケーション導入、パラメーター･チューニングと言った作業を行います。こうした作業量も単体ノード構成の場合それほど問題とはなりません。しかしエンタープライズ･システムでは一般的にWAS Network Deployment (ND)版を使用し、数台～数十台に上る環境でスケール･アウト構成を採るケースがあり、こうした場合の作業量・作業時間は構成するノード数にほぼ正比例で増えていきます。これは一システムで数十台規模のクラスターを構成する大規模システムに限った話ではなく、数台規模の環境でも開発環境・テスト環境・本番環境など複数環境作る場合など、ノードの絶対数が増えてくれば同じ課題に直面します。例えば10台のノード上にWASを構成する場合、10台それぞれに対しインストーラーによる導入、Fix適用、プロファイル作成、セルに対するノード統合・・・といった作業を繰り返し実施しなくてはなりません。繰り返す作業内容はほぼ同じながら、インストールCD一枚だけで並行処理を行えず時間がかかるといった課題や、単純な反復作業ゆえにミスが出やすいと言った弊害があります。
パッチ適用時
WASシステムは稼動を開始した後も、定期的にパッチの適用を行うことが推奨されています。システムによっては変更の影響を極小化するために、いわゆる「塩漬け」にすることもありますが、障害時の対処やセキュリティ系の緊急パッチなどでiFixを当てるなどの作業は発生する可能性があります。WASに対するパッチ適用の作業は、更新インストーラー（Update Installer）というGUIツールを導入し、製品導入と同様個々のノードで適用作業を行う必要があります。順序としてはまずDeployment Manager (DM)ノードに対するFix適用を行い、その後各ノードに対するパッチ適用を行っていきます。導入に比べれば適用するファイルサイズが小さいため適用の時間は長くはありませんが、サービスを提供しているクラスターの個々のノードを停止して行わねばならず、原則としてサービスを全停止して行っているのが実情です。
WAS/WVE機能を使用した解決策
導入時
多数のサーバーに対する導入・構成作業を段階的に簡略化することを検討してみます。
(1) GUIのインストーラーで個別導入
一番基礎となるのは前述したGUIのインストーラーを使用した個別導入です。ウィザード形式で画面に指示されるパラメーターを埋めることで導入が可能なので、初心者でも比較的簡単に導入作業を行うことができます。
(2) スクリプトを使用したサイレント導入
第一の作業量軽減策はGUIを使用しないサイレント導入です。これはインストーラーで指定するパラメーターを事前に「レスポンス・ファイル」と呼ばれる定型ファイルに書き出しておき、そのファイルを入力としてスクリプトで導入する方法です。複数台環境ではほぼ共通のパラメーターで導入することが多いため、一台に行った作業内容をレスポンス･ファイルのコピー・一部改変で他のノードに適用でき、全体的な作業量軽減に貢献します。
製品インストールだけではなく、Fix Packの導入に使用する更新インストーラーもサイレント･インストールに対応しています。また、プロファイル作成用のプロファイル管理ツール、通常管理コンソールで行うクラスター作成やアプリケーション導入などの構成作業なども全てCUIコマンドやスクリプトで実行することができます。
(3) カスタマイズ・インストール・パッケージ／統合インストール･パッケージの使用
少し前のバージョンから提供はされているのですが、意外と活用されていない機能にカスタマイズ・インストール・パッケージ（Customized Installation Package : CIP）、および統合インストール･パッケージ（Integrated Installation Package : IIP）という機能があります。これは、お客様環境に応じ導入イメージだけでなく、保守パッケージ/パッチまでまとまった環境をアーカイブ・ファイルにパッケージし、一括導入するための仕組みです。例えばWASの7.0の製品導入イメージに対し、Fix Pack 1、さらに必要なiFix 10個まとめて一つの導入モジュールにするといったことが可能です。これまで製品インストール、Fix Pack適用、iFix適用×10の合計12ステップの作業が、一度で完了するため作業量削減効果は大きくなります。CIPとIIPの差異はCIPが製品およびパッチをパッケージするものに対し、IIPはFeature Packやシェル/wsadminスクリプトなどのユーザー･ファイルなどを含むことができます。さらにWAS7.0.0.1+iFixのCIPとWVE6.1.0.5のCIPをまとめて一つにするなど、複数のCIPをまとめたIIPを作成することも出来ます（図1）。
図1 CIP/IIPによる導入
CIP/IIPを作成するにはInstallation FactoryというEclipseベースのツールを別途導入する必要がありますが、一度作成したCIP/IIPの導入にはInstallation Factoryは必要ないため、他のマシンにコピーすれば導入が可能です。CIP/IIPの作成およびインストールに関しても、コマンドライン･ベースでサイレント導入できます。CIP/IIPでのWAS導入を行うことで、特にFixの数が多い環境などでは作業量軽減が見込めます。
(4) リモート環境の一括導入
これはWAS/WVE機能ではありませんが、(2)(3)で紹介したサイレント導入のステップを、sshやscpを使用し一台のマシンから集約して導入する方法です。個別のサーバーに物理的に移動するのではなく、リモートからのログオンで必要ファイルの配布、導入を行います。実際に行う場合は統合的に管理するインターフェースが提供されないので、コピーミスや実施漏れなどが発生しやすいと言う弊害があります。
(5) 集中インストール・マネージャーの使用
集中インストール･マネージャー（Centralized Installation Manager : CIM）とは、DM上の管理コンソールから統合的にリモートのサーバーに対し製品およびFix Pack、iFixの導入を行うための仕組みです（図2）。内部的にはssh等を使用したアクセスになりますので、(2)サイレント導入と(4)リモート導入の仕組みをWAS管理コンソール上で提供するイメージになります。各サーバーへの導入をDMから並行一括実行できる点だけでなく、実行中のステータス、結果のヒストリーも表示できるので、状況の把握が容易になります。これはもともとWVE V6.1で提供を開始した機能でしたが、WAS V7.0からWAS NDでも同じ機能を提供できるようになりました。
図2 CIMによるFix適用のイメージ
CIMではCIP/IIPを導入することも可能です。またこれまでの機能と同様、CIMもコマンドラインからの実行も可能です。
パッチ適用時
パッチ適用時にも導入時と同様、複数台マシンに対する作業量増大に配慮しなくてはなりませんが、これは「導入時」に記載したソリューションにて解決が可能です。もうひとつ考慮点として挙げたサービス停止の必要性に関しては、CIMを有効活用することで回避できます。
CIMで製品イメージやCIP/IIPを導入する際には、対象サーバーすべてを選択し、並行での導入を行うことが可能でした。この並行導入を行わず、クラスター環境のサーバーを一部停止→パッチ適用を繰り返すことで全体のサービスを止めることなくFix適用の擬似「ロールアウト」が可能になります（図3）。サーバーの順次停止およびCIM適用のタイミングは手動制御の必要がありますが、これもスクリプト化するなどで自動化に近い対処とすることも可能です。
図3 CIMを使用したFix適用のロールアウト
ただし、注意しなければならない点は適用するパッチの影響範囲で、セッションオブジェクト関連やHAマネージャー関連等、複数台のサーバーに関わる修正が含まれるパッチの場合、クラスター環境の一部が異なるパッチレベルの場合に不整合を起こす可能性があります。このような場合はクラスター全体をAグループ・Bグループの半分に分け、Aグループ停止・パッチ適用→Bグループ停止（全体停止）→Aグループ起動と言う形でロールアウトします。このケースでは全体停止時間は発生してしまいますが、グルーピングによる停止時間の極小化運用で対処することになります。
WAS/WVE導入関連機能詳細
ここからはこれまでのソリューションで紹介した各機能を、実際に使用する際の参考となるよう詳細に解説します。
サイレントインストール
WAS/WVEのインストーラーはコマンド引数-silentを指定することによってGUIインストーラーを使用しないサイレント導入が可能です。GUIインストーラーで指定する導入パスなどの各種パラメーター類は、レスポンス・ファイルと呼ばれるテキストファイルを事前に作成しておき、コマンド引数で指定します。レスポンス･ファイルはインストーラーのあるディレクトリに解説（英語）付きのサンプル･ファイル（WAS ND版の場合responsefile.nd.txt）が配置されているので、それを参考に編集すると比較的容易に作成できます。
WAS NDレスポンス・ファイルの例
##########################################################
Installation options and values
##########################################################
-OPT silentInstallLicenseAcceptance="true"
-OPT disableOSPrereqChecking="true"
##########################################################
-OPT installType="installNew"
-OPT profileType="none"
-OPT feature="samplesSelected"
-OPT feature="languagepack.console.all"
-OPT feature="languagepack.server.all"
##########################################################
-OPT PROF_enableAdminSecurity="true"
-OPT PROF_adminUserName="wasadmin"
-OPT PROF_adminPassword="wasadmin"
-OPT PROF_samplesPassword="wasadmin"
##########################################################
-OPT installLocation="/opt/IBM/WebSphere/AppServer"
##########################################################
-OPT cimSelected="true"
-OPT cimRepositoryLocation="/opt/IBM/WebSphere/cimrepos"
-OPT overwriteRepository="true"
##########################################################
-OPT traceFormat=ALL
-OPT traceLevel=INFO
##########################################################
|
サイレントインストールのコマンドは以下のようになります。
./install -options <responsefile> –silent |
GUIインストーラーでは導入状況がプログレスバーで表示されるので進捗が分かりやすいのですが、サイレントインストール時は経過状況の判別が難しくなります。その場合はログ・ファイルがWAS導入先ディレクトリの<WAS_install_dir>/logs/install/log.txtに作成されるので、tailしながら見ていると経過状況が分かります。最終行に<INSTCONFSUCCESS>と表示されれば導入成功です。
サイレントアンインストール
インストール同様アンインストールの場合も、コマンドからサイレントで実行することが可能です。アンインストールは導入先のディレクトリ下の<WAS_install_dir>/uninstallに作成されるuninstallコマンドを指定して実行します。アンインストールではパラメーターも多くないためレスポンス・ファイルは指定しません。通常指定するのは作成済みプロファイルを同時に削除するか否かのパラメーター、removeProfilesOnUninstallのみです。プロファイルを削除する場合ここに「true」を指定します。
./uninstall -silent -OPT removeProfilesOnUninstall="true" |
アンインストールもログにより進捗を監視します。ログは<WAS_install_dir>/logs/manageprofiles/deleteAll.log、<WAS_install_dir>/logs/uninstall/uninstallconfig.logなどに出力されます。
製品のアンインストールを実行する場合、事前に製品上に導入されたFix PackやiFixを抜いておく必要がありますので注意して下さい。
Update Installerサイレントパッチ適用
Update InstallerでGUIを起動せずサイレント・モードでパッチを適用する場合もインストールと同様レスポンス・ファイルが必要です。Update Installerコマンドで以下のコマンドを実行します。
./update.sh –options <responsefile> -silent
|
レスポンス・ファイルのサンプルは<UPDI_install_dir>/responsefiles/install.txtにあります。指定すべき項目は三つで、導入するパッチ･ファイルのフルパスのロケーションをmaintenance.packageに、product.locationにWAS導入パスを、update.typeにinstallを指定します。
install.txtサンプル
-W maintenance.package="/tmp/was_ifix/7.0.0-WS-WAS-LinuxX32-FP0000001.pak"
-W product.location="/opt/IBM/WebSphere/AppServer"
-W update.type="install"
|
Update Installerサイレントパッチ削除
パッチのアンインストールはインストールと同様Update Installerコマンドでレスポンス・ファイルを指定します。
./update.sh –options <responsefile> -silent
|
レスポンス・ファイルのサンプルは<UPDI_install_dir>/responsefiles/uninstall.txtにあります。指定すべき項目は三つですが、install.txtとの違いはupdate.typeにuninstallを、削除すべきパッチをbackup.packageに指定する点です。
uninstall.txtサンプル
-W backup.package="7.0.0-WS-WAS-LinuxX32-FP0000001.pak"
-W product.location="/opt/IBM/WebSphere/AppServer"
-W update.type="uninstall"
|
backup.packageに指定すべき文字列は、<WAS_install_dir>/properties/version/nif/backupディレクトリにある.pak拡張子のファイル名から指定します。一つのレスポンス・ファイルでは一つのbackup.packageしか指定できないため、複数Fixを削除する場合はコピーして複数個のレスポンス・ファイルを作成するか、「#」でコメントアウトしたbackup.packageの複数列を準備し、実行時に一つずつ「#」を付け替えてアンインストールを行ってください。複数のパッチを抜く場合、導入順序の新しいものから順に削除する必要があります。上記backupディレクトリのタイムスタンプなどを参考にして削除の順番を決めて下さい。
Installation Factory
Installation FactoryはCIP/IIPを作成するためのEclipseベースのツールで、（Linux版の場合）以下のURIからダウンロード可能です。
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24020537
.zipや.gzで固められているので、任意のディレクトリに解凍することで使用できます。Installation Factoryを起動する際には<IF_install_dir>/bin/ifgui.shを実行します。CIP/IIPはInstallation Factoryで指定するディレクトリに作成されます。一時的にインストーラー、CIPなど大量のディスクを使用することになるので注意してください。一度CIP/IIPを作成してしまえば、その中にインストーラーなどが含まれるので、作成元ファイルは不要になります。
上記URIでダウンロードできるInstallation FactoryのモジュールではWVEを使用したCIP/IIPの作成はできません。WVEを使用したCIP/IIPを作成したい場合、WVE用のEclipseプラグインを追加導入する必要があります。以下のURIからプラグインをダウンロードし、Installation Factoryと同じディレクトリに展開してください。
http://www-01.ibm.com/support/docview.wss?rs=3023&uid=swg24015697
WVE用プラグインはプラットフォーム共通です。
CIP/IIPの作成
CIP/IIPの作成は、Installation Factoryを起動し、導入イメージのロケーションなどの情報を「ビルドファイル」と呼ばれるXMLファイルに指定することで行います。Linuxで稼動するInstallation FactoryでWindows用のCIP/IIPを作成するといった、別のプラットフォーム用のCIP/IIPを作成することも可能です。
ここでは例として、WAS7.0.0.1用のCIPを作成する際のステップを解説します。Installation Factoryを起動すると以下のような画面になります。
CIP作成なので「カスタマイズ・インストール・パッケージの新規作成」のボタンをクリックします。製品・バージョン・エディションの選択画面になるので、WAS NDの7.0を選択します。
作成するCIPのプラットフォームなどを選択した後、CIPにユニークなID（UUID）を付けます。デフォルトではInstallation Factory導入マシンのホスト名などを使用してユニークなIDを付けようとするので、適宜変更してください。CIPで指定した情報はビルドファイルと呼ばれるファイルに保管されますが、それは指定したUUIDを使用したファイル名（<IF_install_dir>/builddefs/<UUID>_<バージョン番号>.xml）となります。次の画面のように指定してください。下にあるCIPディレクトリー・パスはCIPのファイルの生成先です。
先に進んだ画面でWAS製品のインストール・イメージを指定します。インストール・モジュールのあるディレクトリを指定し、続く画面でCIPに含みたいFix Pack（Application Server用とJava SDK用）やiFixを指定します。この例ではWAS7.0用のFP1と、WVE導入に必要な十数個のiFixを指定しています。CIPではFix PackやiFixはUpdate Installerを使用せずに適用されるので、Update Installerのモジュールを含んでおく必要はありません。
一通りの準備が完了すると、作成されるCIPの定義情報だけを作成するのか、インストール・イメージを含む実CIPファイルを作成するのかを選択します。CIPを作成する場合、画面から必要なファイルサイズの見積もりも行えるので「推定サイズとスペースの表示」をクリックしてください。作成可能なスペースが確認され、「終了」をクリックするとCIPの作成が開始されます。
CIPの作成経過は<IF_install_dir>/logs/log.txtに記載されます。作成開始から数分後に「正常にビルドされました」のメッセージとともに、CIPの作成が完了します。CIP作成時に指定した<IF_install_dir>/ifpackageにWAS導入イメージと類似のディレクトリ構造を持つCIPのイメージが作成されているので確認してみてください。
IIPの作成の際も、最初の画面で「統合インストール・パッケージの新規作成」を選択し、同じような画面操作を行います。相違点は途中でインストール・イメージを指定するのではなく、作成済みのCIPのパスを指定して複数のCIPを統合できる点です。
CIP/IIPの導入（GUI）
CIP/IIPの導入は製品インストーラーとほぼ同様です。作成したCIPの<CIP_dir>/WASディレクトリがあり、その下にinstallスクリプトがあるので、そのまま実行すればインストール用ウィザードが起動します。通常のインストール同様のパラメーターを指定すれば、CIPに含まれるFix Packなども含めたインストールは一括で完了します。
CIP/IIPの利点として、一部導入済みの環境にも適用できると言うものがあります。これは「スリップ･インストール」と呼ばれ、例えば前出のWAS7+FP1+iFix群のCIPを、WAS7までが既に導入済みの環境に対して適用すると、既存WAS7環境に差分のFP1+iFix群の適用のみを行ってくれます。CIPのインストレーション・ウィザードが既存WASの導入ディレクトリを検知した場合に選択できる、「既存のインストールにフィーチャーを追加」を選択してください。
CIP/IIPの導入では<CIP_dir>/logs/log.txtなどにログが書き出されますが、通常のインストールと同様、製品導入やパッチ適用で作成されるログなどを逐次tailするなどして経過状況を確認してください。CIP適用が成功したか否かは、最終的にWAS導入ディレクトリよりversionInfo.shコマンドを-maintenancePackagesオプションで実行することで、CIP内に指定した製品リリースでiFixが導入されているか確認できます。
CIP/IIPの導入（CUI）
CIP/IIPをサイレントインストールすることも可能です。製品イメージのサイレントインストールとほぼ同様のレスポンス・ファイルを指定します。実行コマンドは以下のとおりです。
./install -options <responsefile> –silent
|
レスポンス・ファイルの作成方法は以下を参考にして下さい。
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.factory.doc/info/ae/ae/rins_customize_responsefile_cip.html
CIMレポジトリー構造
CIMを使用して、リモートのマシンに導入することが可能なモジュールは、CIMレポジトリーに登録されます。CIMレポジトリーとはCIMで適用可能な導入イメージの入ったディレクトリであり、デフォルトで<WAS_install_root>の上位ディレクトリ下のcimreposディレクトリ（Linuxなら/opt/IBM/WebSphere/cimrepos）となります。ここにWAS7のFix Packであれば<cimrepos>/WAS70FPn、iFixならば<cimrepos>/WAS70Updates、Update Installerならば<cimrepos>/UPDI70などのディレクトリが作成され、CIMレポジトリー用.pakファイルなどが保管されます。
CIMレポジトリーにファイルを追加する場合、いくつかの方法があります。製品導入イメージなどはインストーラーで「CIMレポジトリーに追加」を選択しておくことが一番簡単な方法です。DMマシンがインターネットに接続可能であれば、Fix PackやUpdate InstallerなどをCIMメニュー→「インストール・パッケージ」画面からファイルのダウンロード、およびレポジトリーへの追加が一括でできます。インターネットに接続できない場合は上記cimreposディレクトリ下に別途取得したファイルをコピーしてください。CIP/IIPは作成時にCIMレポジトリーに追加するよう指定するか、作成後Installation Factoryを使用してCIMレポジトリーに追加することが出来ます。
WVEの製品コード（XDに含まれるCompute Grid、WebSphere eXtreme Scale:WXSも同様）もインストーラーで「CIMレポジトリーに追加」が指定できますが、後からCIMに追加するための専用コマンドも提供されています。<WAS_install_dir>/bin/xd_cimgrrepositpry.shというコマンドを実行すると以下のようなGUIが起動するので、導入イメージが入ったディレクトリを指定してください。
XD製品のCIMレポジトリーは<cimrepos>/WXD61ディレクトリに配置されます。XDの場合注意点として、必要なバージョンが特定OS分のみであったとしても、全体で一つのCIMレポジトリーイメージとなるため、製品CDにある全てのプラットフォーム分の導入スクリプト（install.linux.ia32、install.AIX.ppc32など）を導入しておく必要があります。xd_cimgrrepository.shを使用する場合は必ずXD製品CDのルート･ディレクトリを指定するようにしてください。XDのCIMでのインストールが「必要なバイナリーが見つからない」というエラーで失敗する場合、インストール・パッケージを確認してください。
CIMでCIP導入
CIPも作成の際にチェックするか、Installation Factoryで後から指定することでCIMレポジトリーに追加が可能です。CIMでCIPを導入する場合は、製品パッケージと同様プルダウンからCIPを選択可能となるので、ターゲットを選択した後「インストール」を実行するだけです。ただしCIPで既存環境に追加パッチのみの適用を行うスリップ･インストールの場合、「インストール」ではCIM導入が失敗するため、予め応答ファイルを作った上で「応答ファイルを使用したインストール」を選択するようにしてください。CIP用のレスポンス・ファイルは「CIP/IIPの導入（CUI）」の節を参考に作成して下さい。
CIMでのロールアウト詳細
前節で紹介した、CIMを使用したパッチ適用のロールアウト方法の詳細を、検証例を元に解説します。検証したシステム構成は図3と同様の構成をイメージしてもらえばよいですが、こちらではDM(wpsrv18)とリモート･ノード2台(wpsrv11とwpsrv14)の計3台構成でロールアウトを行っています。適用するiFixはPK76513という複数台環境でもあまり影響のなさそうなものを選びました。
http://www-01.ibm.com/support/docview.wss?rs=180&context=SSEQTP&dc=D400&uid=swg24021807&loc=en_US&cs=utf-8=en
まず準備作業としてDMへのiFix適用が必要です。さらにiFixとUpdate InstallerのCIMレポジトリーへの追加を行います。iFixは<cimrepos>/WAS70Updatesに7.0.0.1-WS-WAS-IFPK76513.pakファイルをコピーします。Update InstallerをCIMレポジトリーに追加していない場合、<cimrepos>/UPDI70に7.0.0.1-WS-UPDI-LinuxIA32.zipをコピーして配置します。（Update InstallerはWebSphereサポートサイトに.gzと.zipの二種類が置いてありますが、CIMで適用する場合必ず.zip版を使用してください。）
ロールアウト適用の手順は以下のようになります。
1. CIM「使用可能なインストール」メニューより、wpsrv11を選択しiFixを導入。
「使用可能なインストール」より、パッケージ･タイプとして「暫定修正」、インストール･パッケージとして「Maintenance for WebSphere Application Server Network Deployment - 7.0」を選択すると、CIMレポジトリーに配置されたiFix「7.0.0.1-WS-WAS-IFPK76513.pak」が表示されるので、これを選択した上で「インストール･ターゲットの表示」ボタンをクリックします。
候補として出てくるノードのうちの一つ、ここではwpsrv11というノードを選択し、「インストール」をクリックします。
インストール依頼が実行されます。左メニューより「進行中のインストール」を選択すると、経過状況が確認できます。
iFix適用の際、CIMにより自動的に対象ノードのASおよびNAが停止され、NAのみ後再起動されます。この間クラスターが受領しているリクエストはwpsrv14上のASがレスポンスを返しています。
インストールが終了すると、「進行中のインストール」からはアイテムが消え、代わりに「インストール･ヒストリー」に結果が表示されます。完了状況が「成功」であることを確認してください。
2. wpsrv11上のASを起動
管理コンソールの「アプリケーション･サーバー」メニューやstartServerのコマンドを使用し、停止されているwpsrv11上のサーバーを起動します。
3. CIM「使用可能なインストール」メニューより、wpsrv14を選択しiFixを導入
1と同様の手順で、wpsrv14に対しiFixを導入します。
4. wpserv14上のASを起動
2と同様の手順でwpsrv14上のASを起動します。
もし2台以上のサーバーがクラスター上に存在する場合、同じ手順を全てのノードに対して繰り返します。
以上の手順でサービスを停止することなく、パッチの適用が行えます。検証環境ではjmeterを使用し、WAS提供のサンプル･アプリケーションにリクエストを継続実行したまま上記手順を実行しましたが、問題なくリクエストは継続処理されていました。
CIMでのパッチ適用ロールアウト用スクリプト
上記手順はしかし、管理コンソールを前にした待ち時間が長く、効率的とは言えません。より効率的に運用する場合、スクリプトにより自動化することが望ましいです。ここでは上記手順をwsadminのスクリプト化したものを紹介します。
（あくまでサンプルとしての提供ですので、各自の環境で流用する場合、ホスト名やiFixの番号などを変えてください。またエラー処理や正常導入のチェック等は実装していませんので注意してください。）
print "### iFix rollout script started.###"
AdminTask.installMaintenance('[-packageName
ND70Maintenance -fileList "7.0.0.1-WS-WAS-IFPK76513.pak" -
hostName wpsrv11.roppongi.japan.ibm.com -installLocation
/opt/IBM/WebSphere/AppServer -adminName root -
adminPassword ***** -acceptLicense true]')
print "### AdminTask.installMaintenancefpr wpsrv11 has
been invoked.###"
print "### Sleep for a while. ###"
sleep(10)
print "### Check whether pending request exists.###"
ongoing = AdminTask.listInProgressRequests()
while len(ongoing) > 0:
print "### Installation ongoing.###"
sleep (30)
ongoing = AdminTask.listInProgressRequests()
print "### Start server01@wpsrv11. ###"
AdminControl.startServer('server01','wpsrv11Node01')
print "### server01@wpsrv11 started. ###"
AdminTask.installMaintenance('[-packageName
ND70Maintenance -fileList "7.0.0.1-WS-WAS-IFPK76513.pak" -
hostName wpsrv14.roppongi.japan.ibm.com -installLocation
/opt/IBM/WebSphere/AppServer -adminName root -
adminPassword passw0rd -acceptLicense true]')
print "### AdminTask.installMaintenancefpr wpsrv14 has
been invoked.###"
print "### Sleep for a while. ###"
sleep(10)
print "### Check whether pending request exists.###"
ongoing = AdminTask.listInProgressRequests()
while len(ongoing) > 0:
print "### Installation ongoing.###"
sleep (30)
ongoing = AdminTask.listInProgressRequests()
print "### Start server02@wpsrv14. ###"
AdminControl.startServer('server02','wpsrv14Node01')
print "### server02@wpsrv14 started. ###"
print "### iFix rollout script ended. ###"
|
スクリプトは管理コンソールで行ったものと同じ処理を行っているので特に複雑な処理は行っていません。CIMインストールはAdminTaskのinstallMaintenance()を使用し、インストールを実行かけた後の完了までの待ち時間はAdminTaskのlistInProgressRequests()で結果が返ってくる間待機しています。
wsadminは上記スクリプトをiFixRollout.pyとして保管した後、以下のコマンドで実行します。
/wsadmin.sh -user <username> -password <password> -lang
jython -f <script_path>/iFixRollout.py
|
正常時の実行ログは以下のように表示されます。
### iFix rollout script started.###
### AdminTask.installMaintenancefpr wpsrv11 has been invoked.###
### Check whether pending request exists.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Start server01@wpsrv11. ###
### server01@wpsrv11 started. ###
### AdminTask.installMaintenancefpr wpsrv14 has been invoked.###
### Check whether pending request exists.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Installation ongoing.###
### Start server02@wpsrv14. ###
### server02@wpsrv14 started. ###
### iFix rollout script ended. ###
|
CIM経過確認方法
CIMでロールアウトを開始すると、CIMレポジトリーからssh/scpを使用してターゲット･ノードのテンポラリー・ディレクトリーに（Linuxの場合/tmp/~CSRIxといった名称で）導入するモジュールや.pakファイルのコピーが作成されます。これらのファイルは正常導入後は自動的に削除されます。
CIMの実行中の状況は管理コンソールの集中インストレーション･マネージャーのメニューより「進行中のインストール」、実行完了後の履歴情報は「インストール･ヒストリー」を参照することで確認することが出来ます。
これらの画面で確認できる項目を除き、CIMには特有のログ情報というものは出力されません。DMではなく適用先のノードでのインストール･ログやUpdate Installerのパッチ適用のログがそれぞれ出力されるので、「インストール･ヒストリー」の詳細の画面からファイル名などを確認して参照するようにしてください。
まとめ
ここまで、WAS/WVEが提供するサイレントインストール、Installation FactoryによるCIP/IIP、CIMによるリモート導入といった機能を活用し、導入・構成作業を効率化する手法を紹介してきました。これら機能は実際の導入ではあまり活用されていない場合が多いのですが、使用してみると便利さが実感できるかと思いますので、導入作業の効率化のためにぜひ採用してみてください。導入するFixレベルのCIPを事前作成しておき、スクリプトで導入やCIMでリモート導入することでかなり作業時間が軽減されるかと思います。
またiFixのロールアウトも、WAS ND/WVEがアプリケーション更新をサービス無停止で行うロールアウト機能を提供している延長で、必ずと言っていいほどお客様から問い合わせを受ける課題に対するソリューションです。現時点では製品機能として充足されているとは言いがたいのですが、既存機能の組み合わせにより必要な要件を満たしうるレベルの運用が可能になるので、こちらもぜひ検討いただければと思います。
著者について  | | | 著者は日本アイ・ビー・エム・システムズ･エンジニアリング（株）(ISE)所属で、IBM社内外に対しWebSphere Application Server、WebSphere Virtual Enterpriseなどの技術サポートを行っています。 |
記事の評価
| 
