Comments
Description
Transcript
2 2-1
2 サーバー管理・基本設定
この章では、プロセスの起動・停止方法などのサーバー管理と仮想ホスト、データベース接続、セッシ
ョン管理などの基本設定について説明します。
2-1 管理コンソール
管理コンソールは WAS を管理するためのグラフィカルな Web ブラウザベースのツールです。管理コ
ンソール用のアプリケーションは、EAR ファイル（adminconsole.ear）の形式で用意されています。ただし
システム・アプリケーションですので、管理コンソール上には表示されず、また設定変更を行うこともでき
ません。
管理サーバー下の全トポロジーについて定義／参照を含むすべての操作が可能です。
Web ブラウザベースのため、サポートされるブラウザが導入されていれさえすれば、特に制約なくリモー
ト環境からも管理可能です。ブラウザを起動して、URL［http://<host_name>:9060/ibm/console］でアクセ
ス可能です。SSL を利用する場合のポート番号は 9043 です。ここで、<host_name>は、WAS Base を使
用している場合は、WAS Base を導入したサーバーのホスト名で、WAS ND を使用している場合は、デ
プロイメント・マネージャーが稼動するホスト名になります。
なお、以後表示する画面例は、主に WAS ND 構成の管理コンソール画面を用いています。
-1-
2-1-1 起動手順
管理コンソールの起動手順を説明します。
1). 前提として、以下のサーバー・プロセスが起動していることが必要です。
WAS Base 構成の場合は、アプリケーション・サーバー(デフォルトは server1)
WAS ND 構成の場合は、デプロイメント・マネージャー(dmgr)
2). Web ブラウザを起動し、管理コンソール用ポート(デフォルトは 9061)を以下のように URL 指定し
ます。
http://<host_name>:9061/ibm/console
SSL を設定し HTTPS 通信を行っている場合は、ポート 9044 で接続します。
https://<host_name>:9044/ibm/console
また、Windows 環境ではスタートから起動することも可能です。スタート・メニューから下記の項
目を選択します。
［スタート］→［プログラム］→［IBM WebSphere］→［Application Server Network
Deployment V6.1］→［プロファイル］→［<Dmgr プロファイル名>］→［管理コンソール］
3). 管理コンソールが起動するとログイン画面（エラー! 参照元が見つかりません。参照）が表示さ
れますので、任意のユーザーID を指定します。グローバル・セキュリティーを設定してない場合
には、このユーザーID は構成情報の変更内容のトラッキングを行うために使用されます。作業
中の情報は、<DM_Profile_root>/wstemp/<各ユーザーのユニークな ID>/workspace 以下に
保管されます。
-2-
図 2-1 管理コンソール：ログイン画面
2-1-2 ログイン･ユーザー
管理コンソールは作業中の情報をユーザーごとにテンポラリー・ワークスペースに保管します。ログイ
ン画面で入力されたユーザーID は、セキュリティーを設定していない場合、構成データに対するユーザ
ー特有の変更をトラッキングする目的でのみ使用されます。このため次回ログイン時に、以下の「ログイ
ンの競合」、「前の変更を回復」のようなメッセージが出力されることがあります。
2-1-2-1 ログインの競合
同一ユーザーID での複数ログインは不可能です。既に使用されているユーザーID でログインしようと
すると競合が発生し、以下のメッセージが表示されるので、いずれかを選択してください。下記メッセー
ジは、ログアウトせずに(前のセッションが残った状態で)、再ログインする場合にも表示されます。
図 2-2 ログインの競合
-3-
2-1-2-2 前の変更を回復
セッション・タイムアウトや変更内容を保存する前にブラウザを閉じてしまった場合などのそれまでの設
定内容をリカバリーするために、再度ログインを行うとき以下のメッセージが表示されます。
図 2-3 前のセッションで行なわれた変更の回復
［マスター構成での作業］を選んだ場合には、最後に保管された構成情報が有効になり、保管を行わ
なかった変更内容は破棄されます。［前のセッションで行われた変更をリカバリーする］を選んだ場合に
は、変更項目の内容を確認してリカバリーすることが可能です。
-4-
2-1-3 使用方法および説明
ここでは、管理コンソールの画面と各メニューについて説明します。
2-1-3-1 起動画面
ログイン後表示される管理コンソールのインターフェースは以下の通りです。
タスクバー
メッセージ
ヘルプ・エリア
ナビゲーション・
ツリー
ワーク・スペース
図 2-4 管理コンソールのインターフェース
•
タスクバー
タスクバーにより、コンソールのログアウト、WAS 製品情報とサポートページへのアクセスおよびヘル
プが提供されます。
•
ナビゲーション・ツリー
コンソールの左側にあるナビゲーション・ツリーは、 WAS 管理セル内でコンポーネントを作成および
管理するために使用する、コンソール・ページへのリンクを提供します。
ツリー・フォルダーまたはアイテムの横にある正符号 (+) をクリックすると、フォルダーまたはアイテムの
ツリーが展開されます。負符号 (-) をクリックすると、フォルダーまたはアイテムのツリーが縮小されま
す。ツリー・ビューでアイテムをクリックすると、展開と縮小の状態が切り替わります。
•
ワークスペース
コンソールの右側のワークスペースには、サーバーやリソースなどの構成オブジェクトの作成と管理に
使用するページがあります。さまざまなタイプの構成済みオブジェクトを表示するには、ナビゲーション・
ツリー内のリンクをクリックします。ワークスペース内で、構成済みオブジェクトの構成、ランタイムの状
-5-
態、およびオプションを表示するには、その構成オブジェクトをクリックします。ワークスペースの「ホー
ム」ページを表示するには、ナビゲーション・ツリーの「ようこそ」をクリックします。このページには、WAS
製品の使用に関する情報へのリンクと製品情報として WAS のバージョンがビルド番号レベルで表示さ
れます。
•
メッセージ
構成情報の変更などが行なわれた場合などに、ワークスペースの上部にメッセージが適宜表示され
ます。
•
ヘルプエリア
コンソールの右側にあるヘルプエリアでは、管理コンソールの各画面についてのヘルプ情報につい
て表示されるほか、コマンド・アシスタンス機能による Jython ベースの管理コマンドを表示する画面を呼
び出すことができます。コマンド・アシスタンスについては「システム運用」の資料を参照ください。
2-1-3-2 メニュー
ナビゲーション・ツリーには、１１個の大メニューが表示されます。ツリーを使用するには、主なトピック
を展開し、展開したリストから項目を選択して、管理タスクを実行するページを表示します。以下各メニュ
ーについての概要と、それぞれのメニューの中での設定項目について一覧表示をします。
表 2-1 管理コンソール： メニュー一覧
メニュー
ガイド付きアクティビティー
サーバー
アプリケーション
リソース
セキュリティー
環境
システム管理
ユーザーおよびグループ
モニターおよびチューニング
トラブルシューティング
サービス統合
UDDI
概要
グローバル・セキュリティーの使用可能化、Web サーバーによるアプリケ
ーション・サーバーへの要求送付、データベースへの接続方法がガイ
ド付きで設定できます。
アプリケーション・サーバー、クラスター、汎用サーバー、Web サーバ
ー、およびコア・グループを構成します。
アプリケーションをサーバーにインストールし、インストールしたアプリケ
ーションを管理します。
データベース接続や JMS キュー接続などのリソースを構成して、管理
セルに存在するリソースに関する情報を表示します。
アプリケーションおよびサーバーを保護するために使用するセキュリテ
ィーを構成します。
仮想ホスト、WebSphere 変数、およびその他のコンポーネントを構成し
ます。
コンソール設定を構成し、デプロイメント・マネージャーやノード・エージ
ェントなど WAS ND 製品のコンポーネントとユーザーを管理します。
ユーザー、グループ、およびそれらに紐付く管理者ロールの作成や変
更を行ないます。
アプリケーション・サーバーのパフォーマンスをモニターして調整し、パ
フォーマンス・データを分析します。
構成エラーおよび問題を検査し、ログ・ファイルを表示して、分散プラッ
トフォーム上でトレースを使用可能および使用不可を構成します。
メッセージ指向およびサービス指向のアプリケーションをインプリメントし
ます。
Web サービスに関する情報を公開し、発見します。
-6-
各メニューの詳細項目の概要を表に示します。
【ガイド付きアクティビティー】
メニュー
内容
データベースへの接続
データベース・アクセスを構成するための一連のステップを説明す
る
Web サーバーからアプリケーショ Web サーバー・プラグインを構成し、動的コンテンツに対する要求
ン・サーバーへの要求送付
をアプリケーション・サーバーに送付する操作を説明する
クラスターの構成とアプリケーショ サーバー・クラスターを作成し、クラスター上のアプリケーションの
ンの高可用性化
可用性を高めるための一連のステップを説明する
【サーバー】
メニュー
アプリケーション・サーバー
汎用サーバー
プロキシー・サーバー
バージョン 5 JMS サーバー
Web サーバー
クラスター
クラスター・トポロジー
汎用サーバー・クラスター
Websphere MQ サーバー
コア・グループ
コア・グループ設定
コア・グループ・ブリッジ設定
【アプリケーション】
メニュー
エンタープライズ・アプリケーション
新規アプリケーションのインストール
内容
アプリケーション・サーバーの新規作成/削除/始動/停止/強制停止
を行う
WAS が提供しているサーバー以外の、java サーバー、CORBA サ
ーバーなどを汎用サーバーとして登録し、汎用サーバーの新規作
成/削除/始動/停止を行う
プロキシー・サーバーの新規作成/削除/始動/停止を行う
JMS サーバーの始動/停止/構成プロパティーの変更を行う
Web サーバーの新規作成/削除/始動/停止、およびプラグインの生
成、プラグインの伝搬を行なう
クラスターの始動/停止/ripple 始動/強制停止/新規作成/削除を行う
クラスター・トポロジーに関する設定を行う
汎用サーバーのクラスターの構成/削除/始動/停止を行なう。
Websphere MQ サーバーの新規作成/削除/始動/停止を行なう
コア・グループの新規作成/削除を行なう
コア・グループ間の通信の構成に関する設定を行なう。
内容
インストール済みアプリケーションに対し、始動/停止/イ
ンストール/アンインストール/更新/更新のロールアウト/フ
ァイルの除去/エクスポート/DDL のエクスポートを行う
新規アプリケーション(EAR/WAR/JAR)をインストールす
る
-7-
【リソース】
メニュー
スケジューラー
オブジェクト・プール・マネージャー
JMS
JMS プロバイダー
接続ファクトリー
キュー接続ファクトリー
トピック接続ファクトリー
キュー
トピック
アクティベーション・スペック
JDBC
JDBC プロバイダー
データ・ソース
デ ー タ ・ ソ ー ス (WebSphere Application
Server V4)
リソース・アダプター
リソース・アダプター
J2C 接続ファクトリー
J2C アクティベーション・スペック
J2C 管理対象オブジェクト
非同期 Bean
タイマー・マネージャー
作業マネージャー
キャッシュ・インスタンス
オブジェクト・キャッシュ・インスタンス
サーブレット・キャッシュ・インスタンス
メール・プロバイダー
メール・プロバイダー
メール・セッション
URL
URL プロバイダー
URL
リソース環境
リソース環境プロバイダー
リソース環境エントリー
内容
スケジューラーの新規作成/削除/テーブルの検査/テー
ブルの作成/テーブルの除去を行う
オブジェクト・プール・マネージャーの新規作成/削除を
行う
JMS プロバイダーの管理を行なう
接続ファクトリーの管理を行なう
キュー接続ファクトリーの管理を行なう
トピック接続ファクトリーの管理を行なう
JMS キューの管理を行なう
JMS トピックの管理を行なう
JMS アクティベーション・スペックの管理を行なう
JDBC プロバイダーの新規作成/削除を行う
データ・ソースの構成/管理を行なう
WebSphere(R) Application Server バージョン 4 の接続
マネージャー・アーキテクチャーを使用するデータ・ソー
スの構成/管理を行なう。
リソース・アダプターの構成/管理を行なう
J2C 接続ファクトリーの構成/管理を行なう
J2C アクティベーション・スペックの構成/管理を行なう
J2C 管理対象オブジェクトの構成/管理を行なう
タイマー・マネージャーの新規作成/削除を行う
作業マネージャーの新規作成/削除を行う
オブジェクト・キャッシュ・インスタンスの新規作成/削除
を行う
サーブレット・キャッシュ・インスタンスの新規作成/削除
を行う
メール・プロバイダーの構成/管理を行なう
メール・セッションの構成/管理を行なう
URL プロバイダーの構成/管理を行なう
URL の構成/管理を行なう
リソース環境プロバイダーの新規登録/削除を行なう
リソース環境エントリーの新規登録/削除を行なう
-8-
【セキュリティー】
メニュー
管理、アプリケーション、および
インフラストラクチャーの保護
SSL 証明書および鍵管理
バス・セキュリティー
Web サービス
内容
管理セキュリティーおよびアプリケーション・セキュリティーの構成を行
なう
SSL 証明書および鍵の管理を行う
SIBus のセキュリティー構成を行なう
Ｗｅｂサービス・セキュリティーのデフォルト・バインディングの構成を
行う
【環境】
メニュー
仮想ホスト
グローバル Web サーバー・プラグイン構成の
更新
WebSphere 変数
共用ライブラリー
複製ドメイン
URI グループ
ネーミング
ネーム・スペース・バインディング
外部セル・バインディング
CORBA ネーミング・サービス・ユーザー
CORBA ネーミング・サービス・グループ
【システム管理】
メニュー
セル
変更をマスター・リポジトリーに保管
デプロイメント・マネージャー
ノード
ノード･エージェント
ノード・グループ
コンソール設定
内容
仮想ホストの新規作成/削除を行う
セルのグローバル・プラグイン構成ファイルを作成/更
新を行なう
WebSphere 変数の新規作成/削除を行う
デプロイされたアプリケーションから共通で使用される
共有ライブラリーの設定を行う
セッション・マネージャー、動的キャッシュ・サービスお
よび Stateful Session Bean フェイルオーバー・コンポ
ーネントの複製に使用する複製ドメインの設定を行う
URI パターンのグループを作成と削除を行なう
ネーム・バインディングの新規作成/削除を行う
外部セル内のセル・ルート・ネーミング・コンテキストに
解決されるバインディングを管理する
CORBA ネーミング・サービス・ユーザーの追加/除去
を行う
CORBA ネーミング・サービス・グループの追加、除去
を行う
内容
全ノードの論理グループであるセルの設定を行う
ワークスペースの変更をマスター構成に保管するほか、変更の
破棄やキャンセルを行う
デプロイメント・マネージャーの構成を設定する
ノードの追加/除去/強制削除/同期化/完全な再同期/停止を実
行する
ノード・エージェントの停止/再始動、ノード配下の全サーバー
の再始動を行う
ノードの集合であるノード・グループの新規作成/削除を行う
管理コンソールのワークスペースのユーザー設定を行なう
-9-
【ユーザーおよびグループ】
メニュー
内容
管理ユーザー・ロール
ユーザーに管理ロールを追加、更新または除去する
管理グループ・ロール
グループに管理ロールを追加、更新または除去する
ユーザーの管理
ユーザーの検索および管理を行なう。
グループの管理
グループの検索および管理を行なう。
【モニターおよびチューニング】
メニュー
Performance Monitoring Infrastructure(PMI)
要求メトリック
Performance Viewer
現行アクティビティー
ログの表示
【トラブルシューティング】
メニュー
ログおよびトレース
構成上の問題一覧
クラス・ローダー・ビュー
アー
構成の妥当性検査
構成エラー
構成警告
構成情報
診断プロバイダー
テスト
状態データ
構成データ
ランタイム・メッセージ
ランタイム・エラー
ランタイム警告
ランタイム情報
内容
PMI の構成とランタイム設定を行う
WAS 内のトランザクションを追跡し主要コンポーネント
の応答時間を記録する構成を行う
Tivoli Performance Viewer に対するサーバーの選択
を行い、モニターの開始、停止を行う
Tivoli Performance Viewer のログ・ファイルを選択し、
ログの表示を行う
内容
サーバー単位に、各種ログおよびトレースの設定を行なったり、内容を表示
する
管理コンソール上で設定した構成内容について、構成上の問題がある場合
には一覧表示する
アプリケーションに対して可視のクラス・ローダーを表示します。
現在の構成に存在する問題のエラー・メッセージを表示する
現在の構成に存在する問題の警告メッセージを表示する
現在の構成に存在する問題の情報メッセージを表示する
定義済み診断テストの構成/管理を行なう
サーバー・ランタイム・コンポーネントの状態データおよびサーバーについ
て収集されている状態データの管理を行なう
サーバー・ランタイム・コンポーネントの構成データの管理を行なう
サーバーから伝搬するランタイム・イベントのエラー・メッセージを表示する
サーバーから伝搬するランタイム・イベントの警告メッセージを表示する
サーバーから伝搬するランタイム・イベントの通知メッセージを表示する
- 10 -
【サービス統合】
メニュー
バス
Web services
JAX-RPC ハンドラー
内容
サービス統合バスの新規作成/削除を行う
JAX-RPC ハンドラー・リ
スト
WS-Security バインディ
ング
WS-Security 構成
UDDI 参照
WS-Notification サービ
ス
【UDDI】
メニュー
UDDI ノード
構成エラー
構成警告
構成情報
要求および応答に対して起動される JAX-RPC ハンドラーの新規作成/削
除を行う
JAX-RPC ハンドラーの順序リストの新規作成/削除を行う
要求および応答の受信と返信のための WS-Security バインディングの新
規作成/削除を行う
インバウンドおよびアウトバウンド・サービスの WS-Security 構成の新規作
成/削除を行う
UDDI 参照の新規作成/削除を行う
WS-Notification サービスの新規作成/削除を行う
内容
このセル内で管理できる UDDI ノードの活動化/非活動化を行う
現在の構成に存在する問題のエラー・メッセージを表示する
現在の構成に存在する問題の警告メッセージを表示する
現在の構成に存在する問題の情報メッセージを表示する
- 11 -
2-1-3-3 管理コンソールの使用例
管理コンソールの使用例として、セル内に配置されているクラスターのクラスター・メンバーのページ
を表示します。
ナビゲーション・ツリーから［サーバー］→［クラスター］→［<Cluster-name>］→［追加プロパティ］→［ク
ラスター・メンバー］を選択すると、ワークスペースにクラスター・メンバー・ページが表示されます。このペ
ージは個々のクラスター・メンバーの稼動状況の確認、始動、停止、新規作成を行うことができます。
なお、管理コンソールではブラウザの［戻る］や［進む］を使用せず、ワークスペース上部の階層を示
すリンクやナビゲーション・ツリーをクリックし、表示を行うことが推奨されています。
図 2-5 管理コンソール： クラスター・メンバー
- 12 -
2-2 サーバー管理
この節では、WAS 環境におけるサーバー管理について説明します。WAS 環境ではプロセスとしてデ
プロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーが稼動しています。各々の
プロセスの総称を管理プロセスと言いますが、ここではこの管理プロセスの起動・停止方法や作成方法
などについて説明します。
2-2-1 デプロイメント・マネージャーの管理
デプロイメント・マネージャーの起動・停止、ポート番号の確認方法を説明します。
2-2-1-1 デプロイメント・マネージャーの起動
デプロイメント・マネージャーの起動方法を以下に示します。
コマンドによる起動
<DM_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startManager.sh (startManager.bat) または # ./startServer.sh(startServer.bat) dmgr
【確認方法】
コマンド画面上に、以下のメッセージが出力されることで起動が確認できます。
ADMU3000I: サーバー dmgr が e-business 用にオープンされました。
プロセス ID は 4000 です。
上記メッセージは<DM_Profile_root>/logs/dmgr/startServer.log および SystemOut.log にもログとして出
力されます。
Windowsサービスとして実行
Windows 環境では、プロファイル作成時に、デプロイメント・マネージャーを Windows サービスとして
実行することが可能です。 その場合は、関連した Windows サービスを開始し、 デプロイメント・マネ
ージャーの起動を行います。
Windows サービスに定義している場合も、コマンドからの起動は可能です。コマンド画面には
Windows サービスから起動されるメッセージが表示されます。
Windows サービスからデプロイメント・マネージャーを起動するには次ページの手順で行います。
- 13 -
1). [スタート]→［コントロールパネル］→［管理ツール］→［サービス］を開きます。
2). デ プ ロ イ メ ン ト ・ マ ネ ー ジ ャ ー の サ ー ビ ス [IBM WebSphere Application Server V6 –
DeploymentManager_Node_name]を選択し、サービスを開始するため
ボタンをクリック
します。
3). 開始中のウィンドウが表示されます。
4). ［状態］に［開始］が表示されたことを確認します。
管理コンソールからの起動
管理コンソール起動の前提が、デプロイメント・マネージャーであるため、管理コンソールから始動す
ることはできません。停止はできます。
- 14 -
2-2-1-2 デプロイメント・マネージャーの停止
デプロイメント・マネージャーの停止方法を以下に示します。
コマンドによる停止
<DM_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場合)。
# ./stopManager.sh (stopManager.bat) または # ./stopServer.sh(stopManager.bat) dmgr
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
＞ADMU4000I: サーバー dmgr の停止が完了しました。
上記メッセージは<DM_Profile_root>/logs/dmgr/stopServer.log および SystemOut.log にもログとして
出力されます。
Windowsサービスとして実行
デプロイメント・マネージャー・プロファイル作成時に、デプロイメント・マネージャーを Windows サー
ビスとして定義している場合は、 関連した Windows サービスを停止し、デプロイメント・マネージャー
の停止を行います。、
Windows サービスに定義している場合も、コマンドからの停止は可能です。コマンド画面には Windows
サービスから停止されるメッセージが表示されます。
Windows サービスからデプロイメント・マネージャーを起動するには次ページの手順で行います。
- 15 -
1). サービスからデプロイメント・マネージャーを起動するときと同様に、Windows サービス管理画
面を開き、デプロイメント・マネージャーのサービスを選択し
ボタンをクリックします。
2). 停止中のウィンドウが表示されます。
3). ［状態］に［開始］が消え何も表示されないことを確認します。
管理コンソールからの停止
管理コンソールのナビゲーション・ツリーから、[システム管理]→[Deployment Manager]を開き、構成
タブの[停止]ボタンを押すことで停止します。
- 16 -
2-2-1-3 デプロイメント・マネージャーの使用ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートの表示および管理方
法を示します。
1). 管理コンソールから、［システム管理］→［Deployment Manager］→［追加プロパティー］の［ポ
ート］を選択し、リンクの左横にある「+」を展開します。
図 2-6 デプロイメント・マネージャー： 構成画面
- 17 -
2). ポートのリンクを開くと各ポート情報の詳細を示す以下の画面が表示されます。
図 2-7 デプロイメント・マネージャー： ポート番号の確認
各項目について以下に説明します。
ポート名 ：ポートの名前を指定します。名前はすべてサーバー内で固有でなければなりま
せん。
ホスト ：クライアントがリソース (ネーミング・サービス、管理サービス、 JMS ブローカー
など) を要求するために使用する IP アドレス、ドメイン・ネーム・サフィックスの付いた
DNS ホスト名、またはサフィックスの付かない DNS ホスト名を指定します。ポートのホス
ト名は、解決可能な名前または IP アドレスです。
ポート ：クライアント要求を受け入れるようにサービスが構成されているポートを指定しま
す。ポート値は、ホスト名とともに使用します。
関連トランスポート ：指定したポートに紐づいたトランスポート設定の表示と管理を行なう
画面に遷移します。
- 18 -
3). ポート名にある［port_name］リンクをクリックすると、そのポート名に対するポートを設定するこ
とができます。
図 2-8 デプロイメント・マネージャー： ポートの設定
- 19 -
2-2-2 ノード・エージェントの管理
ノード・エージェントの起動・停止、ポート番号の確認方法を説明します。
2-2-2-1 ノード・エージェントの起動
ノード・エージェントの起動方法を示します。
コマンドによる起動
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startNode.sh (startNode.bat) または # ./startServer.sh(startServer.bat) nodeagent
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー nodeagent が e-business 用にオープンされました。
プロセス ID は 7096 です。
上記メッセージは<WAS_root>/profiles/Custom01/logs/nodeagent/startServer.log および
SystemOut.log にも出力されます。
Windowsサービスとして実行
ノード・エージェントはプロファイル作成時に Windows サービス を作成することができませんが、
WASService コマンドを使用することにより、ノード・エージェント・プロセス用の Windows サービス
を作成することができます。ただし、WASService コマンドによって作成した Windows サービス は、
アンインストーラーによって除去できません。必要なくなった場合は作成者の責任において除去してく
ださい。WASService コマンドの詳細については下記の InfoCenter の記載を参照してください。
InfoCenter「WASService コマンド」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/rins_wasservice.html
ノード・エージェント の開始は[スタート]→[コントロールパネル]→[管理ツール]→[サービス]を開き、
以下のとおり行います。
1). サービスを開始するため
ボタンをクリックします。
2). 開始中のウィンドウが表示されます。
3). ［状態］に［開始］が表示されることを確認します。
- 20 -
管理コンソールからの起動
ノード・エージェントについては、メニューより再始動(一旦停止し、始動する)することができます。ただ
し、管理コンソールから起動はできません。
ノード・エージェントの再起動を行うには、メニューより、[システム管理]→[ノード・エージェント]を選択
し、該当ノード・エージェントのチェックボックスにチェックをして、［再始動］を実行します。
図 2-9 ノード・エージェントの始動： 再始動ボタン
実行すると、以下のメッセージがコンソールに表示されます。
図 2-10 ノード･エージェント：始動メッセージ
ノード・エージェントは停止した後に自動的に再始動を行います。
図 2-11 ノード・エージェントの始動： 再起動確認
- 21 -
2-2-2-2 ノード・エージェントの停止
ノード・エージェントの停止方法を示します。
コマンドによる停止
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./stopNode.sh(stopNode.bat) または # ./stopServer.sh(stopNode.bat) nodeagent
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー nodeagent の停止が完了しました。
上記メッセージは<WAS_root>/profiles/Custom01/logs/nodeagent/stopServer.log および SystemOut.log
にも出力されます。
管理コンソールからの停止
管理コンソールのナビゲーション・ツリーから、[システム管理]→[ノード・エージェント]を開き、該当ノー
ド・エージェントのチェックボックスにチェックをして、［停止］を実行します。
図 2-12 ノード・エージェントの停止： 停止ボタン
停止が完了すると、以下のメッセージがコンソールに表示されます。
図 2-13 ノード・エージェントの停止： 停止メッセージ
- 22 -
2-2-2-3 ノード・エージェントのポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートを表示および管理し
ます。
1). ［システム管理］→［ノード・エージェント］→［nodeagent_name］をクリックします。
2). ［追加プロパティー］→［ポート］をクリックします。
図 2-14 ノード･エージェント： ポートの確認
3). ポートの詳細画面が開きます。ポート名の［port_name］リンクをクリックすると、ポートを設定す
ることができます。
- 23 -
2-2-3 アプリケーション・サーバーの管理
ここでは、アプリケーション・サーバーの起動・停止、新規作成、設定方法を説明します。
2-2-3-1 アプリケーション・サーバーの起動
WAS ND構成の場合は、所属するノードのノード・エージェントが起動されていることが各アプリケーシ
ョン・サーバーの起動の前提条件となります。そのため「2-2-2-1 ノード・エージェントの起動」のステップ
が前提になります。
コマンドによる起動
<Profile_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startServer.sh(startServer.bat) ApplicationServer_name
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー server1 が e-business 用にオープンされました。
プロセス ID は 4352 です。
上記メッセージは<WAS_root>/profiles/Custom01/logs/server1/startServer.log および SystemOut.log
にも出力されます。
- 24 -
管理コンソールからの起動
WAS Base を使用の場合は、アプリケーション・サーバーの起動が管理コンソールの起動の前提にな
りますので、管理コンソールからアプリケーション・サーバーを起動することはできません。コマンドによる
起動、または Windows サービスでの起動を使用します。
WAS ND を使用の場合は、管理コンソールで、［サーバー］→［アプリケーション・サーバー］を選択
し、起動したいアプリケーション・サーバーのチェックボックスをチェックし、［始動］ボタンを押します。
図 2-15 アプリケーション・サーバーの起動： 始動ボタン
以下のメッセージが表示され、始動が成功すると状況が開始済みマークに変わります。
図 2-16 アプリケーション・サーバーの起動：始動メッセージ
図 2-17 アプリケーション・サーバーの起動： 起動の確認
- 25 -
Windowsサービスとして実行
管理コンソールから作成するアプリケーション・サーバーのWindowsサービス を作成するには、
WASService コマンドを使用します。詳しくは「2-2-2-1ノード・エージェントの起動(p.20)」をご参照くださ
い。
2-2-3-2 アプリケーション・サーバーの停止
アプリケーション・サーバーの停止方法を説明します。
コマンドによる停止
<WAS_root>/bin 以下で、コマンドを実行します。
# ./stopServer.sh(.bat) ApplicationServer_name
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー nodeagent の停止が完了しました。
上記メッセージは<WAS_root> profiles/Custom01/logs/ server1/stopServer.log および SystemOut.log に
も出力されます。
管理コンソールからの停止
メニューより、［サーバー］→［アプリケーション・サーバー］を選択し、停止したいアプリケーション・サー
バーのチェックボックスをチェックし、［停止］ボタンを押します。
図 2-18 アプリケーション・サーバーの停止： 停止ボタン
- 26 -
サーバー停止を実施するかを確認する画面が表示されます。問題がなければ［OK］をクリックします。な
お、「このメッセージは再度表示しない」にチェックを入れるとこの確認画面は以降の停止作業では表示
されません。
図 2-19 アプリケーション・サーバーの停止： 実施の事前確認
サーバー状況をフィードバックする画面に遷移します。ここでは停止プロセスの詳細が出力されます。停
止処理が正常に終了すると「<servername>は正常に停止されました。詳しくは、JVM ログを確認してくだ
さい。」というメッセージが表示されます。
図 2-20 アプリケーション・サーバーの停止： 停止メッセージ
- 27 -
強制停止
強制停止はいかなる状態でも即座に実行されます。そのため、現在稼動中のプロセスは、進行中の
作業を正常に処理することはできません。一方、正常な停止は即座に実行されないので進行中の作業
を正常に処理し停止します。終了は、これらで停止できないプロセスを削除します。終了は必ず強制終
了を試行したのち使用してください。
強制停止を行うには、管理コンソールで、［サーバー］→［アプリケーション・サーバー］を選択し、強制
停止したいアプリケーション・サーバーのチェックボックスをチェックし、［強制停止］ボタンを押します。
図 2-21 アプリケーション･サーバーの強制停止： 強制停止ボタン
サーバーを即座に停止するかを確認する画面が表示されます。問題がなければ［OK］をクリックしま
す。なお、「このメッセージは再度表示しない」にチェックを入れるとこの確認画面は以降の停止作業で
は表示されません
図 2-22 アプリケーション・サーバーの強制停止： 実施の事前確認
- 28 -
サーバーの停止処理が終了すると以下のメッセージが表示されます。
図 2-23 アプリケーション・サーバーの強制停止： 完了メッセージ
2-2-3-3 アプリケーション・サーバーの作成
WAS の管理コンソールからアプリケーション・サーバーの作成方法を説明します。
1). 管理コンソールで[サーバー]→[アプリケーション・サーバー]をクリックします。
図 2-24 アプリケーション・サーバーの作成： アプリケーション・サーバー・リンクの選択
2). [新規作成]ボタンをクリックします。
図 2-25 アプリケーション・サーバーの作成： 新規作成ボタン
- 29 -
3). ［サーバー名］を指定します。作成するサーバーを配置するノードを選択した後、サーバー名を
入力して[次へ]をクリックします。サーバー名はノード内で固有である必要があります。
図 2-26 アプリケーション･サーバーの作成： ノードの選択
4). サーバー・テンプレートの選択画面では、作成するアプリケーション・サーバーのテンプレートを
選択します。デフォルトのテンプレートと DeveloperServer のテンプレートが事前に用意されて
います。通常のアプリケーション・サーバーを作成する場合には[default]を選択し、［次へ］をクリ
ックします。また、事前に特定のアプリケーション・サーバーのテンプレートを作成している場合
はそのテンプレートも使用できます。サーバーのテンプレートを作成する方法の詳細は下記の
InfoCenter の記載を参照ください。また、DeveloperServer テンプレートを使用すると、開発環
境用に調整されたサーバーが作成されます。DeveloperServer テンプレートについての詳細は
Redbook 「WebSphere Application Server V6.1 System Management and Configuration
(sg247304) 」の 3.3.6 “Creating a new application server on existing node”に説明がありま
すので参照してください。
InfoCenter 「サーバー・テンプレートの作成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/
ae/ae/trun_create_templates.html
図 2-27 アプリケーション･サーバーの作成： サーバー・テンプレートの選択
- 30 -
5). サーバー固有プロパティーの指定画面では、通常は既存のアプリケーション・サーバーと HTTP
ポートが重複しないように、チェックボックスを有効にしたまま［次へ］をクリックします。
図 2-28 アプリケーション･サーバーの作成： サーバー固有プロパティの設定
6). 新規アプリケーション・サーバーの情報が表示されます。確認をして[終了]をクリックします。
図 2-29 アプリケーション･サーバーの作成： 新規サーバーの確認
7). サーバーを作成したことによりローカル構成が変更されたので変更をマスターに適用します。
[保管]をクリックします。保管を行わないとマスター構成情報には反映されません。
- 31 -
図 2-30 アプリケーション・サーバーの作成： マスター構成に保管
8). 新規アプリケーション・サーバーが、サーバーのリストに追加されたことを確認してください。
図 2-31 アプリケーション・サーバーの作成： 新規アプリケーション・サーバーの確認
- 32 -
2-2-3-4 アプリケーション・サーバーの削除
WAS の管理コンソールからアプリケーション・サーバーの削除方法を説明します。
1). 管理コンソールの[サーバー]を展開して[アプリケーション・サーバー]をクリックします。
2). 削除するアプリケーション・サーバーのチェックボックスを ON にして[削除]ボタンをクリックしま
す。
図 2-32 アプリケーション・サーバーの削除： 削除ボタン
3). 確認画面が表示されますので、[OK]ボタンをクリックします。
図 2-33 アプリケーション・サーバーの削除： 削除実施の事前確認
ローカル構成が変更されたので変更をマスター構成に保管します。保管を行わないとマスター構成情
報には反映されません。
4). 新規アプリケーション・サーバーが、リストから削除されたことを［サーバー］→［アプリケーショ
ン・サーバー］を開いて確認してください。
図 2-34 アプリケーション・サーバーの削除： 削除の確認
- 33 -
2-2-3-5 アプリケーション・サーバーの設定
アプリケーション・サーバーの設定の一例として、ポートの確認とモニター・ポリシーの設定を説明しま
す。
ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートを表示および管理しま
す。
1). ［サーバー］→［アプリケーション・サーバー］→［ApplicationServer_name］をクリックします。
2). ［通信］→［ポート］のリンクを展開します。
3). [port_name］をクリックすると、ポートを設定することができます。
モニター・ポリシー
ノード・エージェントはノード内のアプリケーション・サーバーの稼動状況をモニターしており、アプリケ
ーション・サーバーが障害で停止しているときには再始動を試みます。（管理ツールを使用して明示的
に停止させた場合は再始動は行いません）
ここではその再始動する方法を制御する設定を表示、または変更します。
管理コンソールから、［サーバー］→［アプリケーション・サーバー］→［ApplicationServer_name］をク
リックします。 ［サーバー・インフラストラクチャー］→［Java およびプロセス管理］→［モニター・ポリシ
ー］をクリックします。
図 2-35 モニター・ポリシーの設定： モニター・ポリシー・リンクの選択
- 34 -
下記のモニター・ポリシーの設定画面が開きます。
図 2-36 モニター・ポリシーの設定： プロパティーの設定
ノード・エージェントのアプリケーション・サーバーに対するモニター設定では以下の設定が可能です。
•
始動の最大試行回数
ノード・エージェントがアプリケーション・サーバーの始動を試みる最大回数です。
•
Ping 間隔
ノード・エージェントが Ping によってアプリケーション・サーバーの稼動状況を確認する間隔です。
•
Ping タイムアウト
アプリケーション・サーバーの起動時に、ノード・エージェントがアプリケーション・サーバーの起動
に失敗したと判断する時間です。
•
自動再始動
ノード・エージェントがアプリケーションの再始動を試みるかどうかを設定します。
•
ノードの再始動状態
ノードが完全にシャットダウンして再始動した後の、プロセスの本来あるべき状態を指定します。
デフォルトの設定は、STOPPED でノードの再起動時に、アプリケーション・サーバーは起動しま
せん。自動的に起動するには RUNNING に設定し、ノード停止時の状態を復帰させるには、
PREVIOUS を設定します。
- 35 -
2-2-4 クラスターの管理
管理コンソールの「サーバー・クラスター」ページ（［サーバー］→［クラスター］）ではセル内のクラスタ
ーとその稼動状況を確認することができ、クラスターに対して、始動/停止、ripple 始動、強制停止が可能
です。クラスターに対するこれらの操作はクラスター・メンバーであるすべてのアプリケーション・サーバ
ーに対しての操作となります。ripple 始動は、各クラスター・メンバーを停止した後に起動します。つまり、
再始動を行います。
図 2-37 サーバー・クラスター画面
「サーバー・クラスター」ページにてクラスター名をクリックし、「構成」タブの中の追加プロパティ「クラス
ター・メンバー」をクリックすると、「クラスター・メンバー」ページに移ります。この画面ではクラスター・メン
バーであるアプリケーション・サーバーの稼動状況を確認でき、メンバーごとに始動/停止の操作が可能
です。また、クラスターに新規クラスター･メンバーを追加したい場合は、［新規作成］ボタンから追加する
ことができます。
図 2-38 サーバー・クラスター： クラスター・メンバー画面
- 36 -
2-2-4-1 クラスターの起動
WAS の管理コンソールからクラスターを起動する方法を説明します。
始動
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。始動するクラスターのチェック
ボックスを ON にし、［始動］ボタンをクリックします。
図 2-39 クラスターの始動： 始動ボタン
2). 以下のメッセージが表示され、クラスターが始動されます。
図 2-40 クラスターの始動： 始動開始
- 37 -
3). 「状況」を示すアイコンをクリックし、以下のように開始済みマークになったらクラスターの始動処
理は完了です。
図 2-41 クラスターの始動： クラスター起動完了
ripple始動
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。再始動するサーバーを選びチ
ェックボックスを ON にします。［ripple 始動］ボタンをクリックします。
図 2-42 クラスターの ripple 始動： ripple 始動ボタン
2). 以下のメッセージが表示され、クラスター・メンバーが順次停止した後に再始動が行なわれま
す。
図 2-43 クラスターの ripple 始動： ripple 始動開始
- 38 -
2-2-4-2 クラスターの停止
WAS の管理コンソールからクラスターを停止する方法を説明します。
停止
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。停止するクラスターを選択しチ
ェックボックスを ON にします。［停止］ボタンをクリックします。
図 2-44 クラスターの停止： 停止ボタン
2). メッセージが表示され、クラスターの停止処理が開始されます。
図 2-45 クラスターの停止： 停止処理開始メッセージ
- 39 -
3). 「状況」を示すアイコンをクリックし、以下のように停止済みマークになったらクラスターの停止処
理は完了です。
図 2-46 クラスターの停止： クラスター停止完了
強制停止
強制停止の説明については、「2-2-3-2 アプリケーション・サーバーの停止（p.26）」の「強制停止」に
詳細が載っていますので、そちらをご参照ください。
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。［強制停止］ボタンをクリックし
ます。
図 2-47 クラスターの強制停止： 強制停止ボタン
2). 以下のメッセージが表示され部分停止の状態になりしばらくして完全に停止します。
図 2-48 クラスターの強制停止： 強制停止オペレーション開始メッセージ
- 40 -
2-2-4-3 クラスターの作成
管理コンソールから新規クラスターを作成する操作は、ナビゲーション・ツリーから［サーバー］→［クラ
スター］の順に展開し、［新規作成］ボタンを押します
図 2-49 クラスターの作成： 新規作成ボタン
新規作成するためには以下に挙げる 4 つステップを実施します。
1). Step1.基本クラスター情報を設定します。
図 2-50 クラスターの作成： 基本クラスター情報の入力
基本クラスターとして以下の項目を入力します
クラスター名：新規クラスターの名前を入力します。
ローカルを優先：EJB WLM において、EJB クライアントからのリクエストが同一ノードで稼
動する EJB コンテナーに優先して割り振られるかどうかの設定です。ローカルを優先する
ことによって、パフォーマンスが向上します。
HTTP セッションのメモリー間の複製の構成：クラスター作成時にメモリー間コピーでのセッ
ション・パーシスタンスなどを構成する場合にチェックを入れます。
- 41 -
図 2-51 クラスターの作成： 最初のクラスター・メンバーの作成
2). Step2.最初のクラスター・メンバーを作成します。
新規クラスター・メンバーの設定を行います。設定後、［適用］ボタンを押すと、新規クラスター・メンバー
が追加されます。
この画面における設定として以下の項目があります。
メンバー名：クラスターに追加する新規クラスター・メンバー（アプリケーション・サーバー）
の名前を入力します。
ノードの選択：サーバーを配置するノードを選択します。
ウェイト：サーバーのウェイトを指定します。
固有 HTTP ポートの生成：固有の HTTP ポートを作成するかどうかを指定します。
また、最初のクラスターメンバーをどのように生成するかを以下の項目からひとつ選択します。
「アプリケーション・サーバー・テンプレートを使用してメンバーを作成します」：
既存のアプリケーション・サーバー・テンプレートを利用して最初のクラスターメンバーを作
成します。登録済みのテンプレートから適切なものを選びます。
「既存のアプリケーション・サーバーをテンプレートとしてメンバーを作成します」：
すでに作成済みのサーバーの設定を利用して最初のクラスター・メンバーを作成します。
既存のアプリケーション・サーバーをリストから選択します。
「既存のアプリケーション・サーバーを変換してメンバーを作成します」：
すでに作成済みのサーバーを新規クラスター・メンバーとして利用します。既存のアプリケ
ーション・サーバーをリストから選択します。
「なし」：クラスター・メンバーを含まない空のクラスターを作成します。
新規クラスター・メンバーの設定を終えたら、［次へ］ボタンを押し、Step3 へ進みます。
- 42 -
3). Step3.追加クラスター・メンバーを作成します。
ここで残りのクラスター・メンバーの作成を行ないます。Step2.で作成した最初のクラスター・メンバーが保
管されていますので、これをテンプレートとして追加のクラスター・メンバーを作成します。設定項目は
Step2.と同じです（テンプレートの選択は除く）。個々のクラスター・メンバーの設定を終えたら［メンバー
の追加］をクリックします。これにより、メンバー・リスト表にクラスター・メンバーが登録されます。
残りのクラスター・メンバーの設定を終えたら、［次へ］ボタンを押し、Step4 へ進みます。
図 2-52 クラスターの作成： 追加クラスター・メンバーの作成
- 43 -
4). Step4.要約を表示します。
図 2-53 クラスターの作成： 要約の確認
設定内容を確認して、［終了］ボタンを押すと、クラスターが作成されます。
- 44 -
5). クラスターが追加されたことを確認してください。確認ができたら構成の保管を実施してクラスタ
ーの作成は完了です。メッセージ・ボックス内にある［保管］のリンクをクリックし変更を構成情報
に保管します。
図 2-54 クラスターの作成： マスター構成に保管
6). クラスターがリストに追加されたことを確認してください。
図 2-55 クラスターの作成： クラスターの確認
- 45 -
2-2-5 Webサーバーの管理
WAS のシステムにおける Web サーバーの構成として以下の 2 つのケースに分類できます。
1). アプリケーション・サーバー（つまりは、ノード・エージェント）と Web サーバーが同一筐体に存在
するローカル Web サーバー構成
2). Web サーバーの稼動する筐体とアプリケーション・サーバー（つまりは、ノード・エージェント）が
稼動する筐体が分離しているリモート Web サーバー構成
WAS V5.1 までの時と同様にセルの管理対象に Web サーバーを含めないこともできますが、この場合
はプラグイン構成ファイルを管理コンソールで生成することができませんので、コマンドでプラグイン構成
ファイルを生成し、手動で適切な筐体の適切なディレクトリーに伝搬する必要があります。
また、管理コンソールから実行できる機能は、WebサーバーとしてIBM HTTP Serverを使用した場合
と、それ以外のWebサーバーを使用した場合で異なります。リモート構成のWebサーバーとして、IBM
HTTP Server以外のWebサーバーを使用する場合には、手動でプラグイン構成ファイルの伝搬を行う必
要があります。各構成で管理コンソールから実行できる機能をまとめると表 2-2のようになります。
表 2-2 Web サーバーの構成の違いによる管理コンソールから実行可能な操作の違い
○
○
ローカル/IHS
以外
○
○
○
○
○
○
○
×
○
×
○
×
○
×
○
×
○
×
ローカル/IHS
プラグインの生成
プラグインの伝搬
Web サーバー稼動状
況の確認
Web サーバーの
起動・停止
Web サーバー構成
（httpd.conf）の編集
error.log と
access.log の表示
- 46 -
リモート/IHS
リモート/IHS 以外
○
○
○
×
2-2-5-1 Webサーバーのローカル構成
Web サーバーが稼動するマシンと同一ノード上で、ノード・エージェントが稼動する場合には、デプロ
イメント・マネージャーから Web サーバーの管理が可能です。ただし、Web サーバーの種類として IBM
HTTP Server を用いる場合とその他の Web サーバーを使用する場合では、管理できるレベルが異なりま
す。すべての Web サーバーにおいて、プラグイン構成ファイルの生成、編集を行うことはできますが、
Web サーバーの起動・停止・Web サーバー構成ファイルの編集は IBM HTTP Server のみ行うことができ
ます。この機能を利用することにより、Web サーバーノードにノード・エージェントを配置することによっ
て、WAS からの管理が可能になります。
構成手順の詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「同一マシン上の Web サーバーおよびカスタム・プロファイルの構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_localr.html
2-2-5-2 IBM HTTP ServerのリモートWebサーバー構成
リモート Web サーバー構成において、Web サーバーが IBM HTTP Server の場合、IBM HTTP
Server の管理サーバーがデプロイメント・マネージャーと通信を行うことによって、WAS が IBM HTTP
Server を管理しています。WAS の管理下にある IBM HTTP Server は、管理コンソールから稼動状況
の確認やプラグイン構成ファイルの伝搬、Web サーバーの起動・停止が可能です。
構成手順の詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「別個のマシン上での Web サーバーおよびアプリケーション・サーバーの構成 (リモート)」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_remotesa.html
- 47 -
2-2-5-3 IBM HTTP Serverを使用したWebサーバー構成例
管理コンソールから Web サーバー定義を作成する方法について Windows 環境を例に説明します。
前提として IBM HTTP Server を管理するためのノードが作成されていることとします。
1). 管理コンソールで、［システム管理］→［ノード・エージェント］を開き、管理用のノード・エージェン
トが始動していることを確認します。
2). ［サーバー］→［Web サーバー］をクリックし、［新規作成］ボタンを押します。Web サーバーのノ
ードを選択し、Web サーバー名と Web サーバーのタイプを入力します。［次へ］ボタンを押しま
す。ローカル Web サーバー構成ではここで選択したノードに Web サーバーは配置されます。
図 2-56 Web サーバー構成： Web サーバーの配置ノードおよびタイプの選択
3). Web サーバー・テンプレートを選択します。通常はデフォルトのテンプレートを使用します。
図 2-57
Web サーバー構成： Web サーバー・テンプレートの選択
- 48 -
4). Web サーバーのプロパティーを入力します。下記の項目を入力し、［次へ］をクリックします。
図 2-58
Web サーバー構成： Web サーバーのプロパティの入力
ポートは、Web サーバーの listen ポート番号（ 例：80 ）を入力します。IBM HTTP Server 使用の場合、
インストール・パスは必須です。Web サーバーのインストール・パス（ 例：C:¥WebSphere¥HTTPServer ）
を入力します。サービス名は、Windows 環境でのサービス名を入力します。このサービス名とは表示名
ではなく実際のサービス名、つまりコントロールパネルの［サービス］にリストされている IBM HTTP
Server のプロパティー中の全般タグの［サービス名］を指します（例：IBMHTTPServer6.1）。尚、Web サ
ーバーの稼動ノードが Windows 環境ではない場合には、サービス名の入力欄は表示されず、入力の
必要はありません。プラグインのインストール場所には、プラグインのインストール・パス（例：
C:¥WebSphere¥HTTPServer¥Plugins）を入力します。
- 49 -
図 2-59 Web サーバーのサービス名
5). 内容を確認し、［終了］ボタンを押します。
図 2-60 Web サーバー構成： 新規 Web サーバーの確認
6). 以上のステップで Web サーバーが作成されました。これにより［プラグインの生成］、［始動］、
［停止］が可能になります。
- 50 -
2-2-5-4 IBM HTTP Server以外のリモートWebサーバー構成
Web サーバーが IBM HTTP Server 以外でノード・エージェントを配置しない場合、Web サーバー構成
ファイルの伝搬はデプロイメント・マネージャーの管理外となります。管理コンソールから Web サーバー
の稼動状況を確認することはできますが、プラグイン構成ファイルは Web サーバーのマシンへと手動で
コピーする必要があります。
構成手順の詳細は Web サーバーとして IBM HTTP Server を使用する場合と同様に下記の
InfoCenter の記載を参照ください。
InfoCenter「別個のマシン上での Web サーバーおよびアプリケーション・サーバーの構成 (リモート)」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_remotesa.html
マシンB
マシンB
マシンA
マシンA
ノード
DM
Webサーバー
Plugin構成ファイル
Plugin構成ファイル
構成
リポジトリー
管理コンソール
セル
Webサーバー･ノード
＊IHS以外
プラグインの生成
手動コピーが必要
図 2-61 IBM HTTP Server 以外のリモート Web サーバー構成
1). マシンＢの<Plugin_root>/bin ディレクトリー下の configure<WebServer_name>.bat スクリプト
ファイルをマシン A の<WAS_root>/bin ディレクトリー下に手動でコピーして、実行します。
2). 管理コンソールから、［サーバー］→［Web サーバー］を開くと、スクリプトファイルを実行したこと
によって Web サーバーが作成されていることが確認できます。
3). ［プラグインの生成］ボタンを押し、プラグイン構成ファイルを更新します。ただし、プラグイン構成
ファイルの伝搬は手動で行う必要があります。
- 51 -
2-3 仮想ホスト
仮想ホストは 1 台の物理マシンを論理的に複数のホストマシン（仮想ホスト）として使用する環境を提
供しています。仮想ホストを使用することにより、異なるアプリケーションを１つのセルに統合し、かつあた
かも別のシステム上で動作しているかのような環境を構築することができます。
WASの各ノードにあるWebアプリケーションは、いずれかの仮想ホストと関連づけられ、このWebアプリ
ケーション中のサーブレット、JSPファイル、静的コンテンツの相対パスは、アプリケーションに関連付けら
れる形で仮想ホストに所属しています(図 2-62)。
仮想ホストはクライアントからの要求パケットのHTTPヘッダー中のHost:に含まれるホスト名およびポー
ト番号(指定されている場合)に対応します。Webアプリケーションは呼び出された仮想ホストに応じて厳
密に区別されます。たとえ物理的に同一のマシン上にあっても、異なる仮想ホストに所属するアプリケー
ションを呼び出すことはできません(図 2-63)。
仮想ホスト①
www.abc.com 80
intra.abc.co.jp
www.abc.com
ノード
Webブラウザ
HTTP
サーバー
HTTP
プラグイン
HTTP
トランスポート
Web
アプリケーション
Webコンテナー
アプリケーション・サーバー
図 2-62 １ノード・１仮想ホスト
仮想ホスト②
仮想ホスト①
www.abc.com 80
intra.abc.co.jp 80
www.abc.com
ノード
Webブラウザ
HTTP
トランスポート
HTTP
サーバー
HTTP
プラグイン
Webコンテナー
Web
アプリケーション
Web
アプリケーション
アプリケーション・サーバー
図 2-63 １ノード・複数仮想ホスト
- 52 -
仮想ホストは論理名をもっており、それぞれにホストエイリアスと呼ばれる DNS エイリアスとポート番号
の組み合わせのリストを持っています。
仮想ホストの呼び出しに使用されるホスト名とポート番号の組み合わせを、仮想ホストのエイリアスと呼
びます。たとえば、要求 http://localhost:80/myServletでは、localhost:80 がエイリアスに相当します。1 つ
の仮想ホストに対して、複数のエイリアスを定義できます。
仮想ホストは、特定のノードに関連付けられるのでなくではなく、セル内の環境として定義されます。
同一のセル内では、複数のノードで仮想ホストを共有し、アプリケーション単位で各仮想ホストと関連付
けられます(図 2-64)。Webサーバー・プラグインでは、仮想ホストとURIの組み合わせによりアプリケーシ
ョンを識別し、それぞれにマップされたアプリケーション・サーバーにリクエストを転送します。
仮想ホスト②
仮想ホスト①
www.abc.com 80
intra.abc.co.jp 80
www.abc.com
Webブラウザ
HTTP
トランスポート
HTTP
サーバー
HTTP
プラグイン
Webコンテナー
Web
アプリケーション
Web
アプリケーション
アプリケーション・サーバー
アプリケーション・サーバー
HTTP
トランスポート
Web
アプリケーション
Webコンテナー
ノード
仮想ホスト③
store.abc.com 80
security.abc.com 443
セル
図 2-64 複数ノードと複数仮想ホスト
WAS V6 ではデフォルトで以下の２つの仮想ホストが定義されています。
•
default_host
そのサーバーでもつすべてのアドレスの、ポート 80, 9443, 9080 に対して定義されています。
すべてのアプリケーションで利用することができます。
•
admin_host
WAS V6 管理コンソール用に使用されます。他のアプリケーションからは使用できません。ポ
ート 9090、9043 に対して定義されています。
仮想ホストを追加する必要があるのは、例えば通常の HTTP リクエストと SSL でのリクエストでアクセス
されるリソースを分けたい場合などで、そういったときには仮想ホストを分けてリソースを配置します。しか
したいていのユーザーにとっては仮想ホストをあえて作成する必要はなく、デフォルトで提供される
default_host を使用することができます。
- 53 -
2-3-1 仮想ホスト作成
仮想ホストの作成方法を説明します。
1). ナビゲーション・ツリーから[環境]を展開して[仮想ホスト]をクリックします。
2). [新規作成]をクリックします。
図 2-65 仮想ホストの作成： 新規作成ボタン
3). 一般プロパティーの［名前］に仮想ホストの名前を入力して[適用]をクリックします。
図 2-66 仮想ホストの作成： 仮想ホスト名の設定
- 54 -
4). 追加プロパティーの[ホスト別名]をクリックします。
5). [新規作成]をクリックします。
図 2-67 ホスト別名の作成： 新規作成ボタン
6). この仮想ホストにひもつくホスト名とポート番号の組を、［ホスト名］と［ポート］を入力して[適用]を
クリックします。この仮想ホストの設定と一致するユーザーからのリクエストだけが、この仮想ホ
ストにマップされたアプリケーションで処理されます。ホスト名は任意の値を許可する * 、または
特定のホスト名を入力します。ポート番号のデフォルト値は HTTP で使用される 80 です。
図 2-68 ホスト別名の作成： 別名の設定
- 55 -
7). ホスト別名が追加されたことを確認してください。確認ができたら構成の保管を実施して仮想ホ
ストとホスト別名の作成は完了です。メッセージ・ボックス内にある［保管］のリンクをクリックし変
更を構成情報に保管します。
図 2-69 ホスト別名の作成： マスター構成へ保管
図 2-70 ホスト別名の作成： ホスト別名の確認
- 56 -
2-4 データベース接続設定
J2EE アプリケーションの中にはデータベース・アクセスがビジネスロジックの処理の中核となるものも
少なくありません。ここでは、WAS におけるデータベース・アクセスの概念と構成について解説します。
2-4-1 データベース接続の概説
J2EE アプリケーションからのデータベースへの接続の概要は下記の図のようになります。
各データベース･ベンダーが提供
するJDBCドライバーをWebSphere AS
上に設定
・JDBCドライバーのクラスパス
・データソースの実装クラス
・ネイティブ・ライブラリー・パス
WebSphere AS
JDBC
Application
JDBC
Provider
Database
DataSource
・JNDI名（jdbc/SampleDS）
・データーベース名
・データ･ソース・ヘルパーの型
・ユーザーID
・パスワード
データソースをlookupするコードの一部
try{
Context ctx = new InitialContext();
ds1 = (DataSource)initialcontext.lookup(“java:comp/env/jdbc/SampleDS”);
conn = ds.getConnection();
・・・
} catch (NamingException ne) {
ne.printStackTrace();
}
図 2-71 J2EE アプリケーションからのデータベース接続の概要図
図中のコードでは、lookup というメソッドにより、データ・ソース・オブジェクトを取得しています。使用す
るデータ・ソース名が、lookup メソッドの引数となります。この lookup メソッドの戻り値として返されたデー
タ・ソース・オブジェクトに対し、接続・切断・データ・アクセスを行います。
- 57 -
2-4-1-1 データベース接続設定のキーワード
•
JDBC ドライバー
JDBC ドライバーは JDBC の API と各データベース製品を結びつけます。JDBC ドライバーは各デー
タベース･ベンダーによって提供してされています。例えば、IBM の DB2 V8.1 または V8.2 では、「DB2
Universal JDBC ドライバー（ファイル：db2jcc.jar）」などが提供されます。同じデータベース製品でも、接
続の種類（ローカル接続かネットワーク接続か）や 2 フェーズ・コミットをサポートするか否かなどにより、
いくつかの種類があります。
•
JDBC プロバイダー
JDBC ドライバーのパス、この JDBC プロバイダーの元で作成されるデータ・ソースの型、ネイティブ・ラ
イブラリー・クラス等を指定するための定義情報です。
•
データ・ソース
データベースに接続するために必要な情報(データベース名、JNDI 名、データ・ソース・ヘルパーの
型、ユーザーID、パスワード)を指定するための定義情報です。
•
JNDI とデータ・ソース
WAS V6 では、JDBC2.0 標準拡張 API の一部として提供されている JNDI （Java Naming and
Directory Interface）を使用することによって、システムの物理的な構成や実装に依存しない形でデータ
ベースにアクセスすることが可能となっています。
JNDI を使用したプログラム中では、データベースは「論理名」を持つ「データ・ソース」オブジェクトとし
て表現されます。Java オブジェクトとして実装された「ネーミング・サービス」に対してデータ・ソースの論
理名を指定して検索を依頼すると、現実のデータベースと紐付けされたデータ・ソース・オブジェクトが
返されます。データベースへの接続や切断もこのデータ・ソース・オブジェクトに対して行うことになりま
す。
データ・ソースの論理名とデータベースの物理名との紐付けや、データベースのアクセスに必要とな
る JDBC ドライバーの管理は、すべて WAS システムの内部で処理されます。このため、データベースの
構成に変更があった場合も WAS の設定の変更のみで対応でき、プログラムの変更は必要なくなりま
す。
•
接続プーリング
通常のアプリケーションにおいてもデータベースの接続と切断は負荷の高い処理ですが、特に Web ア
プリケーションの場合はそのシステム上の特性からデータベース接続と切断が高頻度で繰り返されるこ
とになりがちであり、ユーザーへの応答時間に与える影響も無視できません。この負荷を軽減するため
にデータベース接続を共用する機能が接続プーリングです。
接続プーリングを使用すると、プールからの接続の取得と返却の処理はデータ・ソースの内部で行わ
れるため、アプリケーション側では通常の接続／切断と同様の処理を行えばよく、特殊なコーディングは
必要ありません。
接続プーリングを使用したシステムでは、個々のユーザー・プログラム（サーブレット、EJB）がデータ
ベースの接続要求を出すと、実際にその時点でデータベースに接続を行うのではなく、すでに接続され
プールされていた接続が渡されます。データベースの切断要求時には、実際の切断処理は行われず
に、接続は接続された状態のままプールに戻される処理が行われます。これによってデータベース接続
の負荷は最初の１回のみにかかり、２回目以降のユーザーからの接続要求に対するオーバーヘッドは
わずかなものですみます。
- 58 -
2-4-2 JDBCドライバー
JDBC ドライバーには、データベース接続形態と 2 フェーズ・コミットをサポートするか否かに応じて複数
の種類が存在します。
データベースの接続形態の違いにより、4 種類の JDBC ドライバーがあり、Type1～Type4 の JDBC ドラ
イバーと呼ばれています。各データベース･ベンダーが 1 つまたは複数の種類のドライバーを提供して
います。必ずしも全ての種類のドライバーを提供しているわけではありません。
Type1 の JDBC-ODBC ブリッジ・ドライバーは既存の ODBC ドライバーを利用してデータベース・アク
セスを行います。この JDBC ドライバーは SDK に同梱されています。しかし、Type1 のドライバーを使用
するのはデータベース･ベンダーから Type2～4 のドライバー（Java 用のドライバー）が提供されていない
場合のみであり、すでに主要なデータベース･ベンダーから各データベース用の JDBC ドライバーが提
供されているため、Type1 のドライバーを使用する必要はほとんどありません。
Type2 のネィティブ・ブリッジ・ドライバーはローカル・システムに導入されたデータベース固有のドライ
バー（ネイティブ DBMS ドライバー：DB2 の場合は DB2 クライアント）を呼び出すことにより、データベー
ス・アクセスを行います。特長としては、WAS 導入マシン側にデータベースのクライアント・ソフトウェアが
必要となります。
Type3 のネット・ドライバーはリモート・システムに導入された専用プログラム（JDBC アプレットサーバ
ー）とネットワーク接続するので、WAS 導入マシン側にはデータベース固有のドライバーを必要としませ
ん。
Type4 のダイレクト・ドライバーは、純粋な Java プログラムだけで、直接データベース・アクセスを行いま
す。Type3 および Type4 のドライバーは元来アプレットが Web サーバーからダウンロードして使用するこ
とを想定して提供されていました。
また、Type2～4 の JDBC ドライバーにおいては、それぞれ 2 フェーズ・コミットをサポートするものとしな
いものがあります。
サーブレット、EJBなどのJavaプログラム
JDBC API (java.sql , javax.sqlパッケージ)
JDBCドライバーマネージャー
Type1
JDBC-ODBC
ブリッジ・ドライバー
Type2
ネイティブ・ブリッジ
・ドライバー
ODBC
ドライバーマネージャ
ネイティブDBMS
ドライバー
（DB2ｸﾗｲｱﾝﾄ等）
Type3
ネット・ドライバー
Type4
ダイレクト・ドライバー
WebSphere AS 導入マシン側
DB導入マシン側
JDBC
アプレットサーバー
凡例
ネイティブ
ODBCドライバー
ネイティブDBMS
ドライバー
DBMS
開発者提供
SDK提供
DBベンダー提供
図 2-72 JDBC ドライバー
- 59 -
UNIX または Windows 上で稼動する DB2 の提供する JDBC のドライバーは下記表の 4 種類です。
なお、「DB2 Legacy CLI-based Type2 Driver」は WAS V6.1 から非推奨となっています。また、「DB2
Universal JDBC Driver Provider」は Type2 と Type4 が設定可能となっています。
XA と non-XA のドライバーの違いですが、XA のドライバーは 2 フェーズ・コミットをサポートし、
non-XA のドライバーは 2 フェーズ・コミットをサポートしません。プログラムで 2 フェーズ・コミットを使用す
る場合は XA ドライバーを使用します。2 フェーズ・コミットを使用しない場合は、パフォーマンスのよい
non-XA ドライバーを使用します。
表 2-3 WAS がサポートする DB2 のドライバー
WAS JDBC Provider Name
DB2 Universal JDBC Driver Provider
Type
2/4
zip/jar
db2jcc.jar
DB2 Universal JDBC Driver Provider (XA)
2/4
db2jcc.jar
DB2 Legacy CLI-based Type2 Driver
2
db2java.zip
DB2 Legacy CLI-based Type2 Driver (XA)
2
db2java.zip
Implementation Class
com.ibm.db2.jcc.
DB2ConnectionPoolDataSource
com.ibm.db2.jcc.
DB2XADataSource
COM.ibm.db2.jdbc.
DB2ConnectionPoolDataSource
COM.ibm.db2.jdbc.
DB2XADataSource
2-4-3 JDBCプロバイダー設定
ここでは、JDBC プロバイダーの有効範囲の設定や作成方法を説明します。
2-4-3-1 JDBCプロバイダーの有効範囲の設定
有効範囲とは、リソースを定義するレベル(セル/ノード/クラスター/サーバー)を示します。
リソースは、セル、ノード、クラスター、サーバー(アプリケーション・サーバー)の各レベルにおいて定義
することができます。
JDBC プロバイダーを作成する前に、どの有効範囲で JDBC プロバイダーを作成するかを検討する必
要があります。
あるリソースをサーバー・レベルで定義した場合は、そのリソースは、そのサーバーからのみ使用可能
です。ノード・レベルで定義されたリソースは、そのノード上で稼動する全てのサーバーから使用すること
ができます。クラスター・レベルで定義されたリソースは、そのクラスター上で稼動する全てのサーバーか
ら使用することができます。セル・レベルで定義されているリソースは、そのセルに含まれるノード上で稼
動する全てのサーバーから使用可能になります。
また、複数のレベルで同じリソースに関する定義がなされている場合は、より広い範囲のレベルの定
義に、より限定的な範囲での定義が上書きされます。
•
アプリケーションの有効範囲はすべての有効範囲より優先されます。しかし、この有効範囲を管理
コンソールから構成することはできませんのでご注意ください。
•
サーバーの有効範囲は、ノード、セル、およびクラスターの有効範囲より優先されます。
•
ノードの有効範囲はクラスター、およびセルの有効範囲より優先されます。
•
クラスターの優先範囲はセルの有効範囲より優先されます。
また、リソースはさまざまなレベル(有効範囲)において作成することができますが、そのリソースのプロ
パティーは、個々のサーバー・レベルでのみ適用されます。例えば、あるデータ・ソースをセル・レベル
- 60 -
で定義する場合、そのセルのすべてのユーザー(サーブレット、EJB 等)が、そのデータ・ソースをルック
アップし、使用することができます。そして、このデータ・ソースの最大接続数 を 10 に設定する場合、そ
のセル内の各サーバーは 10 個の接続を使用できることになります。
管理コンソールにおいて、リソースに関する定義を行う際には、セル、ノード、クラスター、サーバーの
どのレベルにおいて、そのリソースを作成するのかを意識する必要があります。
Cell
Resource7
Node A
AppServer X
EA-1
Resource1
Resource3
AppServer Y
Node B
Cluster
Resource2
図 2-73 ND 構成
Resource6
Resource6
Resource5
AppServer Z
EA-2
Resource4
※EA＝エンタープライズ・アプリケーション
AppServer X 上で稼動するエンタープライズ・アプリケーション[EA-1]では、Resource1、Resource3、
Resource7 を使用することができます。
AppServer Z 上で稼動するエンタープライズ・アプリケーション[EA-2]では、Resource4、Resource5、
Resource6、Resource7 を使用することができます。
Resource2, Resource3、Resource6、Resource７が同一のリソースに関する定義である場合、Resource7
の定義は Resource6 の定義に上書きされ、Resource7、Resource6 の定義は Resource3 の定義に上書き
され、Resource7、Resource6、Resource3 の定義は Resoruce2 の定義に上書きされることとなります。
また、Resource7 を[EA-1]と[EA-2]とが使用することができますが、リソースのプロパティーは、サーバ
ー毎に有効であり、例えば最大接続数が 10 と設定されていた場合、ランタイムでは AppServerX におい
て 10 個、AppServerZ において 10 個、計 20 個(※)の接続が作成されることとなります。
(※AppServerY においても 10 個まで接続を作成することができますが、この図では AppServerY には
アプリケーションがインストールされていないので、接続が作成されることはありません。)
- 61 -
2-4-3-2 JDBCプロバイダー作成
JDBC プロバイダーの作成方法を説明します。
1). 管理コンソールのナビゲーション・ツリーから、[リソース] → [JDBC] → [JDBC プロバイダー]
を選択します。
2). 適切な有効範囲を選択した後、[新規作成]ボタンをクリックします。
図 2-74 JDBC プロバイダーの作成： 有効範囲の設定と新規作成ボタン
- 62 -
•
3). 新規 JDBC プロバイダー作成の画面に移ります。作成は以下の三つのステップからなります。
ステップ１ DB2 や Oracle などのサポートされるデータベース・タイプを選択します。
サポートされるデータベース・タイプのリストに、使用するタイプが含まれていない場合は、［ユー
ザー定義］を選択します。プロバイダー・タイプ、実装タイプを選択した後 JDBC プロバイダー名を
入力して［次へ］をクリックします。
図 2-75
JDBC プロバイダーの作成： データベースタイプ、プロバイダータイプの設定
- 63 -
•
ステップ２ 必要に応じてデータベース・クラスパス情報を入力します。また、JDBC プロバイダー
の設定時に必要となる WebSpehre 変数をここで設定することも可能です。
図 2-76
•
JDBC プロバイダーの作成： データベース・クラスパス情報の設定
ステップ３ 設定項目を確認して［終了］をクリックします。
図 2-77
JDBC プロバイダーの作成： 要約の確認
- 64 -
4). JDBC プロバイダーが追加されたことを確認してください。確認ができたら構成の保管を実施し
て作成は完了です。メッセージ・ボックス内にある［保管］のリンクをクリックし変更を構成情報に
保管します。
図 2-78
JDBC プロバイダーの作成： マスター構成へ保管
図 2-79
JDBC プロバイダーの作成： JDBC プロバイダーの確認
- 65 -
2-4-4 J2C認証データ設定
Java プログラムのコーディングにおいて、getConnection( )メソッドの引数としてユーザーID/パスワード
を渡す場合には、データ・ソースの定義情報中にユーザーID/パスワードを含める必要はありません。
しかし、getConnection( )メソッドにおいて引数を渡さない場合や、WAS のアプリケーション・セキュリテ
ィー機能を採用する場合には、データ・ソース側に認証情報(ユーザーID/パスワード)を定義しておく必
要があります。WAS では、リソース接続時の認証情報の参照先として、｢J2C 認証エイリアス｣を使用しま
す。
J2C 認証エイリアスとは、あるリソースに対して接続を行うユーザーの、ユーザーID およびパスワード
を定義するためのスペースです。WAS では、あるリソースに接続する際、このエイリアス経由で、接続ユ
ーザーの情報を取得する仕組みをとっています。
リソースに接続するユーザーの ID／パスワードを指定するための｢エイリアス｣をあらかじめ作成してお
き、リソースの定義時には、認証のためのユーザー情報としてこのエイリアスを指定します。実行時、リソ
ースへの接続のための認証が発生した際は、このエイリアスに定義されているユーザーID／パスワード
が参照されます。
ここでは、J2C 認証エイリアスを作成するためのステップを説明します。
1). 管理コンソールのツリー・ビュー上で、［セキュリティー］→［管理、アプリケーション、およびインフ
ラストラクチャーの保護］をクリックします。
2). ［認証］の下の、［Java 認証・承認サービス］→［J2C 認証データ］をクリックします。
図 2-80 J2C 認証データの設定： J2C 認証データへのリンク
- 66 -
3). [新規作成]をクリックし、一般プロパティーを編集します。終了したら［OK］をクリックします。
図 2-81
J2C 認証データの設定： プロパティの編集
別名：別名の表示名。データ・ソースからエイリアスを指定する際にこのフィールド名を指定
します。
ユーザーID：データベースの接続ユーザー名
パスワード：上記ユーザーID のパスワード
説明：このエイリアスについての説明を記述します。
4). リストに新規作成した別名が追加されていることを確認したら、メッセージ内の［保管］のリンクを
クリックします。
- 67 -
2-4-5 データ・ソース設定
JDBC プロバイダーを作成したら、次に、バックエンド・データ・ストアにアクセスするデータ・ソースを作
成する必要があります。データ・ソースは、アプリケーションとデータベース間のトランザクションを実行す
るのに必要な、プールされた接続セットと考えてください。
2-4-5-1 データ・ソースの種類
WAS V6.1 では、V6.1 標準のデータ・ソースと、WAS V4 のデータ・ソースの二種類をサポートしていま
す。これら 2 つのデータ・ソースでは、それぞれサポートする EJB のバージョンが異なります。
Enterprise JavaBean (EJB) 1.0 仕様または Java Servlet 2.2 仕様を使用している場合は、バージョン
4 データ・ソースが必要です。V4 のデータ・ソースが現行のバージョンでも引き続き残されている理由
は、前のバージョンの J2EE アプリケーションの移行を前提とした互換性のためです。これにより前のバ
ージョンの WAS 上で稼動させている既存 EJB がある場合には、コード変更／再デプロイをせずに再利
用することができます。
2-4-5-2 データ・ソース作成
1). 管理コンソールで、[リソース]→[JDBC] →[データソース]を選択します。
2). データ・ソースの有効範囲を選択した後、［新規作成］をクリックします。
図 2-82 データ･ソースの作成： 有効範囲の設定と新規作成ボタン
- 68 -
•
3). 新規データ・ソース作成の画面に移ります。作成は以下の四つのステップからなります。
ステップ 1 基本データ・ソース情報を入力します。具体的にはデータ・ソース名と JNDI 名です。
J2C 認証データの設定を行なっていない場合は、データ・ソース作成ウィザードを中途で破棄して
認証データ設定画面に移ることもできます。
図 2-83 データ･ソースの作成： 基本データ・ソース情報の入力
•
ステップ 2 JDBC プロバイダーを選択します。ここから新規に作成することも可能です。
図 2-84 データ･ソースの作成： JDBC プロバイダーの選択
- 69 -
•
ステップ 3 データ・ソースのプロパティを入力します。
まず、[データベース名]欄にこのデータ･ソースと紐づけるデータベース名を入力します。[ドライバー・
タイプ]欄に JDBC ドライバーの Type を指定します。[サーバー名]欄は、ドライバー・タイプが 4 のときの
み指定します。データベース・サーバーの TCP/IP アドレスまたはホスト名を入力します。[ポート番号]欄
は、データベース接続で使用するポート番号を指定します。
図 2-85 データ･ソースの作成： プロパティの入力
•
ステップ 4 要約が表示されますので、設定を確認のうえ[終了]をクリックします。
図 2-86 データ･ソースの作成： 要約の確認
- 70 -
2-4-6 テスト接続
作成した JDBC プロバイダー、データ・ソースを使用してデータベースに接続できることを確認します。
本テストの実施前に、データベースの起動が必要です。DB2 のサービスが稼動していることを確認して
ください。テスト接続は管理コンソールからボタン操作だけで行うことができます。［リソース］→［JDBC］
→［データ・ソース］→［DataSource_name］を開きます。データ・ソースを定義し保管をした後、デー
タ・ソース横のチェックボックスをチェックします。［テスト接続］ボタンをクリックします。これにより、デー
タ・ソース定義のパラメーターが正しいかどうかを確認できます。
図 2-87 テスト接続： テスト接続ボタン（データソース画面）
テスト接続が成功した場合、以下の出力メッセージが表示されます。
図 2-88 データ･ソースの作成： 接続成功メッセージ
- 71 -
なお、［リソース］→［JDBC］→［データ・ソース］にもテスト接続ボタンがあります。
図 2-89 テスト接続： テスト接続ボタン（データ・ソース一覧画面）
- 72 -
2-4-7 UNIX、Linux環境での設定
DB2 UDB に接続するためには、DB2 独自の環境変数を設定する必要があります。
2-4-7-1 setupCmdLine.shの編集
WAS において提供される、環境変数を設定するためのシェル［setupCmdLine.sh］に以下の行を追
加します。DB2 を使用している場合は、db2profile スクリプトを実行する必要があります。 この
setupCmdLine.sh スクリプトは、<Profile_root>/bin ディレクトリーにあり、次のように入力して呼び出しま
す。
if [ -f /home/〈db2_instance_owner〉/sqllib/db2profile ]; then
. /home/〈db2_instance_owner〉/sqllib/db2profile
if
その他、各 DB ベンダー固有の設定については、下記の InfoCenter の記載を参照ください。
InfoCenter「ベンダー固有データ・ソースで最低限必要な設定」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/a
e/rdat_minreq.html
- 73 -
2-4-8 接続プール
アプリケーション・サーバー上で、アプリケーション間で共用が可能なデータベース接続のプールを
作成することができます。接続プールを利用すると、次回のリクエストが来た時にプールされた接続を再
利用することができるため、データベースへの接続／切断にかかるオーバーヘッドを減らすことができま
す。接続プールは、データ・ソースまたは接続ファクトリーに個々に作成され、これを利用することで、デ
ータベース接続を行う Web アプリケーションの応答時間を改善することができます。データベースの接
続を効率よく使用する上で、接続プールの各プロパティーの値を適切な値に設定することがきわめて重
要になります。
2-4-8-1 接続プールの管理
WAS では、指定された設定に従って、以下のように接続プールの管理が行われます。
ユーザー(サーブレット／EJB)からの接続要求（getConnection）に対して、
プール内に現在使用されていない接続が存在していればこれを渡します。
(要求が共用可能接続に対するものである場合、同じ共用プロパティーを持つ接続がすで
に他ユーザーにより使用されていれば、その接続を共用します。)
プール内に現在使用されていない接続がなく、かつプール内の接続が最大接続プール・サ
イズ以下であれば新規の接続を作成し、これを渡します。
(要求が共用可能接続に対するものであり、同じ共用プロパティーを持つ、すでに使用中の
共用可能接続がない場合、または、要求が共用不可能接続に対するものである場合も、
新規の接続が作成されます)
プール内に現在使用されていない接続がなく、かつプール内の接続が最大接続数に達し
ていれば、ユーザーの要求は待機させられます（最大で[接続タイムアウト]で指定された秒
数まで）。
•
ユーザーからの接続終了(close)の要求に対して、
接続をプールに戻します（この時点では切断はしません）。
(その時点で接続が共用されている場合、接続はプールに戻されません。接続がプールに
戻されるのは、接続への最後の参照がアプリケーションによって close され、トランザクショ
ンが終了した後だけです。)
トランザクション終了後、接続が閉じてプールへの接続の戻りが無視されることがありま
す。この状態は、プール内の接続の 1 つが失効したと見なされた場合に起こります。接続
は、データ・ストアへの接続に使用できなくなると、失効したと見なされます。例えば、デー
タ・ストア・サーバーがシャットダウンされると、その接続は失効したとマークされます。接続
が失効とマークされると、デフォルトの設定ではプール全体が空にされます (あるいは、失
敗した接続のみを消去するように構成を設定できます。)。
•
- 74 -
プール維持スレッドは、定期的に接続の状態をチェックし、プール内の接続数を下記のタイムアウト値に
したがって管理しています。
•
未使用タイムアウトの管理。
最小接続数以上に作られた接続オブジェクトのうち、一定時間使用されていないものに対して
行われます。一定時間使用されずにいたコネクション・オブジェクトは、｢未使用タイムアウト値｣を
過ぎると消却されます。ただし、プール内の接続が最小接続数以下となる場合、接続は保持され
ます。未使用タイムアウトを小さくしすぎると、頻繁にコネクション・オブジェクトの破棄と生成を繰
り返す可能性がありますので、ある程度の時間を確保します。
•
経過タイムアウトの管理。
｢経過タイムアウト値｣を過ぎると、最小接続数の設定値にかかわらず、すべての接続が破棄さ
れます。
Servlet/EJB
Servlet/EJB
接続タイムアウト
Servlet/EJB
Servlet/EJB
(割り当て可能な接続が無く、
アプリケーションが待ち状態に
なったまま、接続タイムアウト値
に設定した時間が経過すると、
Exceptionがスローされる)
Servlet/EJB
Servlet/EJB
接続
getConnection()
未使用タイムアウト
最大接続数
(最大接続数の値が 0
の場合は、接続は無限
に作成される)
接続
経過タイムアウト
接続
最小接続数
接続プール
接続
図 2-90 プール維持スレッドの接続管理
プール維持スレッドの実行時間の間隔は、「リープ時間｣というプロパティーに設定します。この値は、
｢未使用タイムアウト｣や｢経過タイムアウト｣の値より短く設定してください。リープ時間の間隔は、短けれ
ば短いほど｢未使用タイムアウト｣と｢経過タイムアウト｣の設定値の精度は高くなりますが、あまり間隔が短
いと、プール維持スレッドの実行回数が増え、パフォーマンスを低下させることになります。
- 75 -
2-4-8-2 接続プールの設定値の変更
接続プールの設定値の変更方法は以下のとおりです。ここでは標準のデータ・ソースについての設
定を見ていくことにします。
1). 管理コンソールで、[リソース]→[JDBC] →[データ・ソース]を選択します。
2). 追加プロパティーの [接続プール・プロパティー]を選択します。
図 2-91 接続プールの設定： 接続プール・プロパティ画面へのリンク
- 76 -
3). 一般プロパティーを必要に応じて編集します。ここでは、接続プール内のコネクションに関する設
定を行います。編集が終了したら、[OK]をクリックします。
図 2-92 接続プールの設定： 接続プールのプロパティ設定
項目
接続タイムアウト
内容
使用中の接続が最大接続数に達しているところに新規接続要求がきた
際、待機する時間
最大接続数
プールに維持できる物理接続の最大数
最小接続数
プールに維持できる物理接続の最小数
リープ時間
プール維持スレッドの実行間隔
未使用タイムアウト
未使用、またはアイドルの接続が破棄されるまでの時間の間隔
経過タイムアウト
物理接続が破棄されるまでの時間の間隔
パージ・ポリシー
不整合な接続や致命的エラーが検出された際に接続をパージする方法
で、値は「EntirePool」または「FailingConnectionOnly」が選択可能
最大接続数を 0 に設定した場合、物理接続は無制限となり接続タイムアウトを設定しても無効となりま
す。また、未使用タイムアウトを設定した場合未使用接続は最小接続数になるまで破棄されます。ただ
し、経過タイムアウトを設定している場合は未使用タイムアウトにかかわらず、経過タイムアウトを経過し
た接続が破棄されます。パフォーマンス向上の面から、未使用タイムアウト値はリープ時間より長く設定
します。プール維持スレッドを使用不可にするにはこのリープ時間に０を設定してください。
- 77 -
2-5 セッション管理
ここでは、セッションとは何か、またセッション・トラッキングにはどういったものがあるかや、セッション・パ
ーシスタンスの設定について説明します。
2-5-1 セッション
セッションとは、同じブラウザを使って、同じユーザーからサーブレットに対して出される一連の要求の
ことです。ブラウザとサーブレット間の通信は HTTP で行われますが、HTTP プロトコルはステートレスな
プロトコルですので、クライアントから Web サーバーへのリクエストがあるたびに、クライアントとサーバー
間でコネクションを確立し、リクエストに対するレスポンスが行われるとコネクションが切断されます。この
ため、通常は Web サーバーに対する複数のリクエストが同一クライアントから送信されたものであるかど
うかをサーバー側で判断することができません。そこで、同一ブラウザ、同一ユーザーからの複数のリク
エストを関連付けて管理する仕組みが必要となります。この仕組みがセッションです。Web コンテナー
内で稼働するアプリケーションは、セッションを利用して個々のユーザーを管理します。
セッションはセッション ID を利用して管理されます。セッション ID は各ユーザーを一意に識別できるよ
うに割り振られます。ユーザーから初めのリクエストが来たときに、サーバー側はレスポンスにセッション
ID をセットして返します。ユーザーは次のリクエストではそのセッション ID を一緒に送り返します。アプリ
ケーション・サーバーはユーザーからの送られたセッション ID をサーバー内に保持されているセッショ
ン・オブジェクトと照合して、ユーザーを識別します。
セッション・オブジェクトはセッション ID ごとにサーバー側で作成、保管、破棄され、その中にはユー
ザーごとの情報が格納されています。
セッション・オブジェクト
のライフサイクル
作成
最初のリクエスト
セッションID:
ABCD
セッションID
＝ABCD
セッションID
情報追加
＝ABCD
情報入力
セッションID
ユーザーA
＝ABCD
WAS
破棄
セッション終了
またはタイムアウト
図 2-93 セッションの仕組み
- 78 -
セッションID:
ABCD
ユーザーA
の情報
セッションID:
ABCD
ユーザーA
の情報
2-5-2 セッション・トラッキングの種類
ユーザーとサーバー間でセッション ID の受け渡しを行うセッション・トラッキングには、Cookie、URL 再
書き込み、SSL ID という方法があります。セッション ID のトラッキングは主に Cookie を使用して行いま
す。Cookie が使用不可能な場合(たとえば携帯電話など)に URL 再書き込み、または SSL ID を使用し
ます。優先順位は高いほうから、SSL ID、Cookie、URL 再書き込みです。
•
Cookie
Cookie とはブラウザ側でデータを保管する仕組みであり、ブラウザは HTTP リクエストを送信す
る際には毎回 Cookie も一緒に送信します。サーバーはこの Cookie にセッション ID を格納しま
す。 Cookie には「キーワード＝値」の形でデータが保管されます。複数のキーワードを設定する
ことが可能です。J2EE アプリケーションではセッション・トラッキング用のキーワードはサーブレッ
トの仕様で JSESSIONID と決められています。Cookie によるセッション・トラッキングを有効にす
るには、管理コンソールで［サーバー］→［アプリケーション・サーバー］→
［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッション管理］
を開き、「Cookie を使用可能にする」にチェックをつけ保管します。
•
URL 再書き込み
リクエストの際 URL の後にセッション ID を付加して送信する方法です。Cookie が使用できないと
きに有効な手段ですが、URL の後ろにセッション ID が見えてしまうという欠点があります。また、
Cookie を使用したアプリケーションからはアプリケーションの修正が必要です。クライアントが
Cookie を受け入れることができない場合、Cookie をセッション・トラッキング・メカニズムとして使
用できないので、かわりに使用されます。URL 再書き込みによるセッション・トラッキングを有効に
するには、管理コンソールで、［サーバー］→［アプリケーション・サーバー］→
［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッション管理］
を開き、「URL 再書き込みを使用可能にする」にチェックをつけ保管します。
•
SSL（Secure Sockets Layer） ID
SSL 情報をセッション ID として使用します。ただし、サポートされているのは IBM HTTP Server
および iPlanet Web サーバーのみです。アプリケーションの修正は必要ありません。SSL ID によ
るセッション・トラッキングを有効にするには、管理コンソールで、［サーバー］→［アプリケーション・
サーバー］→［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セ
ッション管理］を開き、「SSL ID トラッキングを使用可能にする」にチェックをつけ保管します。
WAS のセッション管理に関する構成は、管理コンソールのセッション管理で行います。セッション管理
設定は、アプリケーション・サーバー（Web コンテナー）、エンタープライズ・アプリケーション、Web モジュ
ールの 3 つのレベルで設定できます。デフォルトでは各レベルの設定は上位レベルの設定を引き継ぎ
ます。例えば、Web コンテナー内のアプリケーションおよびその Web モジュールは各レベルで変更を加
えない限り、Web コンテナーの設定を引き継ぎます。
WebSphere Application Server
（Web コンテナー）
エンタープライズ・アプリケーション
Web モジュール
図 2-94 セッション管理設定の有効範囲
- 79 -
設定するレベルを選択してから、管理コンソールを使用してセッション管理画面を開きます。
アプリケーション・サーバー（Web コンテナー）を選択した場合
［サーバー］→［アプリケーション・サーバー］→［ApplicationServer_name］→［Web コンテナ
ー設定］→［Web コンテナー］→［セッション管理］
エンタープライズ・アプリケーションを選択した場合
[アプリケーション]→[エンタープライズ・アプリケーション]→[Application_name]→[Web モジ
ュール・プロパティ]→[セッション管理]
Weｂモジュールを選択した場合
[アプリケーション]→[エンタープライズ・アプリケーション]→[Application_name]→[関連項目]
→[Weｂモジュール]→[Webmodule_name]→[追加プロパティー]→[セッション管理]
セッション管理をクリックすると以下のセッション管理画面が表示されます。ここでは、セッション・トラッキ
ング・メカニズムの指定、最大セッション・カウントの設定、オーバーフローの許可、セッション・タイムアウ
トのなどがあります。
図 2-95 セッション管理設定画面
- 80 -
セッション管理のオーバーライド
エンタープライズ・アプリケーションと Web モジュールのレベルの場合のみ表示されます。この
欄にチェックをつけると上位レベルの設定が上書きされ、有効になります。
セッション・トラッキング・メカニズム
SSL ID、Cookie、URL 再書き込みのうちどれを使用してセッション・トラッキングを行うか指定し
ます。デフォルトは Cookie です。複数指定も可能でその際の優先順位は、SSL ID、Cookie、
URL 再書き込みです。URL 再書き込みを選択した場合は該当するアプリケーションのコードが
URL 再書き込みに対応していることが前提です。
オーバーフローの許可
メモリー内の最大セッション・カウント
メモリー内に保持できるセッションの最大数を指定します。オーバーフローを許可している場合、
最大数を超えるとメモリー内に新たにセッションを格納する領域がとられます。この場合、無限
にセッションが作成されます。オーバーフローの許可を適用しない場合は最大数を超えてセッシ
ョンを張ろうとするとアプリケーションにエラーが返ります。ただし、これらはパーシスタンスを使
用した場合は異なる意味になるので、詳しくは infocenter をご参照ください。
InfoCenter「セッション管理設定」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/inf
o/ae/ae/uprs_rsession_manager.html
セッション・タイムアウト
セッションが使用されなくなってから無効になるまでの時間を設定します。セッションが
タイムアウトになるとサーバーが保持していたセッション・オブジェクトが破棄され、メ
モリが解放されます。「セッション・タイムアウト｣の項目はパフォーマンス・チューニ
ングの観点からも重要な項目です。
セキュリティー統合
セキュリティー統合を使用可能にするかどうかを指定します。セキュリティー統合が使用
可能な場合、セッション・マネージャーはユーザーの ID を HTTP セッションに関連付け
ます。
セッション・アクセスのシリアライズ
並行セッション・アクセスを禁止するかどうかを指定します。
- 81 -
2-5-3 セッション・マネージャー
セッション・マネージャーは Web モジュール単位、またはエンタープライズ・アプリケーション単位で設
定され、セッション情報の管理作業を行うコンポーネントです。Servler2.4 の仕様ではセッション・スコー
プは Web モジュール単位です。WAS では独自の機能としてエンタープライズ・アプリケーション単位で
のセッション情報の共有をサポートしています。ただしエンタープライズ・アプリケーション単位でのセッ
ション情報の共有を行う場合には、Web モジュール単位でのセッション・マネージャーの設定は行えませ
ん。
セッション・マネージャーの行うセッション管理作業には、セッション ID(String)とセッション・オブジェクト
(HttpSession)との紐付けやセッション・オブジェクトの外部 DB や他の JVM へのコピーなどが含まれま
す。また WAS のセキュリティー機能を使用している場合は、認証されたユーザーID とセッション ID との
間の紐付けも行います。
2-5-4 セッション・パーシスタンス設定
セッション情報を共有する機能として、データベースにセッション情報を格納して共有する「データベ
ース」とアプリケーション・サーバーにセッション情報を格納して共有する「メモリー間複製」があります。メ
モリー間複製は JVM 上に格納されているセッション情報をほかの JVM 上にコピーすることによりセッショ
ン情報を共有します。この機能は WAS ND 構成 のみ使用可能で、WAS Base 構成では使用できませ
ん。WAS Base ( ND の Base プロファイルを含む) を使用したセッション・データベースはサポート対象で
すが、これは、同じ JVM からのセッション情報の引継ぎを目的とした場合です。セッション・クラスタリング
(他の JVM でセッションを引き継ぐ) をする場合は、WAS Base ではサポートされませんのでご注意くださ
い。WAS ND 版 (Express/Base 版を除く) でのみサポートとなります。
データベースによるセッション・パーシスタンスはWAS V4以前から提供されています。メモリー間コピ
ーは、WAS V5からの登場した機能で、WAS V6.1では設定方法やデフォルト値が改善されています。
以下の表に、セッション・パーシスタンスの有無とセッション・パーシスタンスの方法の違いによるメリット・
デメリットをまとめます。また、セッション・パーシスタンスを行う場合、セッション情報をコピーするタイミン
グの設定として、定期的にコピーを行う時間基準の設定とサーブレット・サービスの終了ごとにコピーを
行う設定を選択することが可能です。
セッション・パーシスタンスを行う場合、データをセッション DB や JVM に格納するのでセッション・オブ
ジェクトはシリアライズ可能でなければなりません。セッション・パーシスタンスを行う場合にセッション・オ
ブジェクトをシリアライズ可能にしないと”java.io.NotSerializableException”が発生します。
表 2-4 セッション・パーシスタンスの方法別機能マトリクス
セッション・パー
シスタンス設定
なしの場合
障害時セッショ
ン情報の復旧
パフォーマンス
メモリー使用量
DB の使用
セットアップ容
易性
データベース
サーブレット・サ
時間基準
ービスの終了
メモリー間の複製
サーブレット・サ
時間基準
ービスの終了
×
△
◎
△
◎
◎
○
－
○
○
必要
△
○
必要
○
△
不要
△
△
不要
－
△
△
○
○
- 82 -
セッション・パーシスタンスの設定は、デフォルトで使用可能になっていません。分散環境設定で分散
セッションを「データベース」または「メモリー間複製」に設定し、さらに各設定画面で必要な項目を設定
します。
2-5-4-1 DBによるセッション・パーシスタンス
デフォルトではセッション・データは JVM のヒープ内に格納されて管理が行なわれます。データベー
スによるセッション・パーシスタンス設定を行うことで、セッションをセッション管理用のデータベースに格
納することが可能になり、データベースによるセッション管理が行われます。セッション管理方法をデー
タベースとすると、指定先のデータベースにデータ保管用の「Sessions」というテーブルが自動的に作成
されます。
セッション・パーシスタンスを設定することにより、WAS の計画的なシャットダウン時や障害時でも、セッ
ション・オブジェクトを保持することができるため、セッション情報を他のアプリケーション・サーバーへ引
き継ぐことが可能です。セッション・パーシスタンスはこの機能を使用することでアプリケーション・サーバ
ーの障害時においても処理中のサービスを続行することを可能にするというメリットがあります。
その他、チューニング考慮点としてセッション・データベースを使用する場合も SQL 文を発行してデ
ータベースからデータを取ってくるという点では、一般的なデータ・アクセスの考慮点もチューニング・パ
ラメーターとして考える必要がでてきます。WAS の観点からすると、データ・アクセスのチューニング・パ
ラメーターで重要なのは、データ・ソースの接続数設定と preparedStatementCache の設定です。このう
ち、データ・ソースの最大・最小接続数の設定は接続の確立のオーバーヘッドがパフォーマンスに影響
を及ぼすことがありますので必要十分な接続数を確保する必要があります。preparedStatementCache サ
イズの設定に関しては、パフォーマンスの観点から見るとキャッシュの破棄が頻繁に発生していなけれ
ば基本的に変更する必要はありません。変更する場合は発行されると考えれらる SQL の数を見積もり、
それとデータ・ソースの最大接続数とから計算することになります。
データベース・セッション・パーシスタンスのセッション管理機能を構成する手順を以下に示します。手
順内では、アプリケーション・サーバー（Web コンテナー）のレベルを選択しています。
1). 管 理 コ ン ソ ー ル か ら 、 ［ サ ー バ ー ］ → ［ ア プ リ ケ ー シ ョ ン ・ サ ー バ ー ］ →
［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］を開きます。追加
プロパティーの［セッション管理］をクリックしセッション管理のワークスペース内の[追加プロパテ
ィー]→［分散環境設定］を開きます。
2). 分散セッションから［データベース］のリンクをクリックします。
- 83 -
図 2-96 DB によるセッション・パーシスタンス設定： 分散セッションの実現方法の指定
3).
「データ・ソース JNDI 名」やそれに接続するための「ユーザーID」「パスワード」などを指定し、
入力を終えたら ［OK］ボタンを押します。 以上を、セッション共有する全クラスター・メンバーに
設定します。
図 2-97 DB によるセッション・パーシスタンス設定： データベース・プロパティの設定
データ・ソースの JNDI 名
既存のデータベースを指定するデータ・ソースの JNDI 名を指定します。この JNDI 名は新規で
データ・ソースを作成した際に指定したものを使用します。
ユーザーID
データベースにアクセスするためのデータベースのユーザーID を指定します。
パスワード
データベースにアクセスするためのデータベースのパスワードを指定します。
DB2 行サイズ
データベースに DB2 を使用した場合のセッション・パーシスタンス設定に特有なパラメーターと
して、データベースのバッファ･プールの設定があります。
データベースに書き込みを行なうとき、いきなりディスクにデータを書き込むことはありません。
その前にバッファ･プールと呼ばれるメモリー上にキャッシュされ、そのあと実際にディスクへの書
き込みが行なわれます。バッファ・プールにキャッシュされている間は、外部（ここでは WAS）から
- 84 -
データの要求でキャッシュ・ヒットしたものは、このバッファ･プールからデータが返されるため、本
来発生するはずだったディスク I/O の時間だけパフォーマンスが向上します。
DB2 UDB において、バッファ･プールのバッファ･サイズはデフォルトで 4KB ですが、設定によ
り 8KB,16KB,32KB から選択することが可能になっています。大量のデータをデータベースに書
き込むようなケースでは適切なバッファ・プール・サイズを設定することでパフォーマンスを最適
化することが可能になります。UDB のページ・サイズの変更方法については InfoCenter を参照
下さい。パフォーマンスの向上は、セッション・オブジェクトの大きさに合わせて DB2 側のページ・
サイズを変更することで図ることが可能です。(セッション・オブジェクト大きさ) ≦ (ページサイズ)
とすればパフォーマンスが向上します。
InfoCenter「DB2 セッション・データベースの表スペースおよびページ・サイズの構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/tprs_db2t.html
複数行スキーマを使用する
セッション・データをデータベースで管理するとき、データベースのテーブルにデータをどのよ
うに書き込むかの設定を行います。単一行スキーマでは、セッション・オブジェクトに格納されて
いる属性の数に関係なくひとつの「データ」として扱われますが、複数行スキーマは属性ごとに
分割してオブジェクトを複数の「データ」として扱います。デフォルトでは、アプリケーション・デー
タのインスタンスはデータベース表内の単一行にマップされますが、この欄にチェックをつけるこ
とによって、アプリケーション・データの各インスタンスをデータベース内の別々の行に置き、各
セッション当たりの保管データ量を増やすことができます。
下表に単一行スキーマ / 複数行スキーマを選択した時の利点･欠点についてまとめます。
図 2-98 DB によるセッション・パーシスタンス： 単一行スキーマと複数行スキーマとの比較
単一行スキーマの利点
・一度のレコードの読み・書きだけですべての値を読み･書きでき
ます。
・セッション・データによって占有されるデータベースのスペースを
小さくできます。
単一行スキーマの欠点
複数行スキーマの利点
・2MB を超えるセッション・データを扱うことができません（1 行あ
たり保管できるデータは 2MB です）。
・2MB 以上のセッション・データを扱えます（ただし、保管する各セ
ッション属性は 2MB 以内にする必要があります）。
・セッション内の属性を個別に読み・書きを行なうことができるよう
になるためデータの直列化処理を減らすことができます。
複数行スキーマの欠点
・複数行読み取りによるオーバーヘッドが単一行スキーマの場合
より大きくなります（よって、セッション・データのサイズが小さい場
合は単一行スキーマを選択）。
単一行スキーマと複数行スキーマの選択のポイントはデータの直列化処理と、DB の読み取
り･書き込み処理のどちらがシステムのパフォーマンスに影響を及ぼすかという点です。
その他にセッション・オブジェクトの大きさも選択ポイントとなります。セッション・データが２MB
を超える場合は複数行スキーマを選ばなくてはいけませんが、それ以外の場合ではどちらが最
- 85 -
適かはアプリケーションがどのようにセッション・オブジェクトを使用するかに依存します。以下に
例を挙げます。
全体のセッション・サイズが小さいケースでは：
単一行スキーマを選択することで DB 側の複数行処理によるパフォーマンス低下を回避できま
す。
セッション内の一部のデータにのみアクセスが必要なケースでは：
複数行スキーマを選択し、かつ「書き込み内容」を「更新されたデータのみ」に指定しておけば必
要なデータのみ直列化が行なわれますので、無駄な直列化処理を行なわない分パフォーマンス
の向上が期待できます。
4). チューニング・パラメーターを変更する場合は、「分散環境設定」の［カスタム・チューニング・パラ
メーター］をクリックし、設定を選択するか、設定をカスタマイズします。詳しくは、2-5-4-3 チュー
ニング・パラメーター設定）」をご参照ください。
5). ［適用］をクリックします。
6). ［保管］をクリックし変更を保管します。 次画面では［ノードと変更を同期化］にチェックがついて
いることを確認して［保管］ボタンを押します。同期化が完了のメッセージが出力されたら［OK］
ボタンを押します。
2-5-4-2 メモリー間複製
メモリー間複製は JVM 上に格納されているセッション情報を他の JVM 上にコピーすることによりセッシ
ョン情報を共有します。メモリー間複製の構成にはピアツーピアとクライアント/サーバーの２つの構成が
可能です。以下にそれぞれの構成について説明します。
メモリー間トポロジー
ピアツーピア
各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報
を保持します。アプリケーション・サーバーに障害が発生すると、プラグインはレプリカのあるサーバーに
リクエストを割り振る、ホット・フェイルオーバーが提供されます。
全てのサーバー
のモード設定は
「クライアントと
サーバー両方」
ApplicationServer1
ApplicationServer1
ApplicationServer1
ApplicationServer1
Localの
セッション情報
全部の AppServerの
セッション情報
AppServer2
のセッション情報
ApplicationServer2
ApplicationServer2
ApplicationServer2
ApplicationServer2
Localの
セッション情報
全部の AppServerの
セッション情報
AppServer3
のセッション情報
ApplicationServer3
ApplicationServer3
ApplicationServer3
ApplicationServer3
Localの
セッション情報
全部の AppServerの
セッション情報
AppServer 1
のセッション情報
Replication Domain 1
( 単一レプリカ)
-
Replication Domain 2
86 - ( ドメイン全体)
全てのサーバー
のモード設定は
「クライアントと
サーバー両方」
図 2-99 HTTP セッションメモリー間複製におけるピアツーピアトポロジー
ピアツーピアトポロジーは、全てのアプリケーション・サーバーのモードを「クライアントとサーバー両
方」とすることで実現できます。
左の図は複製ドメイン設定において、「単一レプリカ」を設定しています。この場合、図のようなセッショ
ン情報の保持の仕方になり、１つのセッション・データに関するレプリカが他サーバー上に 1 つ存在しま
す。
レプリカを受ける予定のサーバーに障害が発生すると、正常なサーバーがその役割を引き継ぎます。
障害サーバーが復活した場合、これまで作られたレプリカはそのまま引き継いだサーバーが保持します
が、新たなセッション情報に関しては最初の予定通り復活したサーバーにデータは複製されます。
本来のセッション・データを保持するサーバーに障害が発生すると、その役割はレプリカサーバーに引
き継がれますが、引き継がれたあとレプリカサーバーに障害が発生すると（2 重障害）そのデータは失わ
れます。
右の図は複製ドメイン設定において、「ドメイン全体」を設定しています。この場合、図のようなセッショ
ン情報の保持の仕方になり、１つのセッション・データに関するレプリカが他全てのサーバー上に存在し
ます。この場合、2 重障害にも対応できますが、メモリーリソースを多く取られることになります。
メモリー間トポロジー
クライアント/サーバー
クライアント/サーバーの構成ではすべてのアプリケーション・サーバーのセッション情報を持つアプリ
ケーション・サーバーとセッション情報の保持のみを専門に行うアプリケーション・サーバーに役割を分
離します。データベース構成のデータベースをアプリケーション・サーバーに置き換えたイメージとなりま
す。この構成の場合、クライアントにサービスを提供するサーバーだけを同一のクラスター・メンバーに登
録すればよいことになります。これによりセッション情報の保持を専用に行うアプリケーション・サーバー
がクライアントに対してサービスを提供することはなくなります。またこれらのアプリケーション・サーバー
はセッション情報を共有するため、同一の内部複製ドメインに属している必要があります。複製モードは
クライアントにサービスを提供するアプリケーション・サーバーは「クライアントのみ」とし、セッション情報
の格納のみを行うアプリケーション・サーバーは「サーバーのみ」を設定します。このような構成を組むこ
とによりアプリケーションの処理（サービス）を実行するサーバーから、セッション複製による負荷を軽減
することができます。
ApplicationServer 1
ApplicationServer 1
モード設定は
「クライアントのみ」
Localの
セッション情報
ApplicationServer 2
ApplicationServer 2
モード設定は
「クライアントのみ」
Localの
セッション情報
ApplicationServer 4
ApplicationServer 4
全部のAppServerの
セッション情報
ApplicationServer 3
ApplicationServer 3
モード設定は
「クライアントのみ」
Localの
セッション情報
Replication Domain 1
(単一レプリカ)
- 87 -
モード設定は
「サーバーのみ」
図 2-100 複製ドメイン設定における単一レプリカ
上図は複製ドメイン設定において、「単一レプリカ」を設定しています。クライアント上のレプリカはサー
バー上に全て保持されます。サーバーの障害に対応するためには、レプリカの数を 2 とし、サーバーを
もう 1 台作成することで SPOF は回避されます。
メモリー間複製の前提
メモリー間複製の設定を行う前提として、クラスターと内部複製ドメインの構成が必要となります。クラス
ターと内部複製ドメインに関しては以下の様な観点で設定を行います。
•
•
メモリー間複製を行うサーバーは必ず同じ内部複製ドメインに属している必要があります
クライアントに対して同一のセッション情報を提供する複数のアプリケーション・サーバーは同一ク
ラスターに属している必要がありますが、メモリー間複製を行う為だけの観点では、特に同じクラ
スターであることは必須条件ではありません（例：クライアント/サーバー構成のとき）
複製ドメイン
複製ドメインとは、クラスター配下のアプリケーション・サーバー間でデータ複製を行うアプリケーショ
ン・サーバーの集合です。情報を共用する必要のあるすべてのアプリケーション・サーバーは、同じ複製
ドメインに存在する必要があります。複製ドメイン内のアプリケーション・サーバー間でデータを複製する
機能をデータ複製サービスと言い、HTTP セッションのメモリー間複製もデータ複製サービスを使用しま
す。
複製ドメインの設定では、1 つのアプリケーション・サーバーがいくつのデータ複製を別のアプリケー
ション・サーバーに作成するかを指定します。以下の 3 つの指定から選択できます。
•
単一レプリカ
1 つのデータに対して、複製ドメイン内に 1 つのデータ複製を保持します。WAS V6 のデフォルト
で使用されます。
•
ドメイン全体
1 つのデータに対して、複製ドメイン内のすべてのサーバーがデータの複製を保持します。
•
指定
1 つのデータに対して、複製ドメイン内に保持するデータ複製の数を指定します。
単一レプリカとドメイン全体のデータ複製の概要は下記の図のようになります。
単一レプリカ
ドメイン全体
複製ドメイン
複製ドメイン
アプリケーション・
サーバー1
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー2
アプリケーション・
サーバー4
データ複製
サービス
アプリケーション・
サーバー1
データ複製
サービス
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー3
アプリケーション・
サーバー2
- 88 -
アプリケーション・
サーバー4
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー3
図 2-101 複製ドメイン
複製ドメインの作成・設定変更は管理コンソールで、[環境]→[複製ドメイン]→
[ReplicationDomain_name]または[新規作成]を選択します。
図 2-102 複製ドメインの設定
レプリカの数以外に、複製ドメインの設定では、以下の設定を変更することが可能です。
•
要求タイムアウト
別のアプリケーション・サーバーの情報を要求する際に、その情報が存在しないものと見なして要
求を断念するまでの待機時間です。デフォルト値は 5 秒です。
•
暗号化タイプ
複製したデータを別のネットワーク領域に転送する際に使用する暗号化のタイプを指定します。オ
プションには、[なし]、[DES（Data Encryption Standard）]、および[3DES]があります。デフォル
トは[なし]です。[DES]オプションと[3DES]オプションは、アプリケーション・サーバー・プロセス間
で送信されるデータを暗号化し、プロセス同士を結合するネットワークをより確実に保護します。
ただし、パフォーマンスに影響します。
- 89 -
複製ドメインの設定では、レプリカの数の設定が重要です。HTTP セッションのメモリー間複製を構成
し、[単一レプリカ]を選択した場合には、HTTP セッションのデータが占有するメモリー領域は、メモリー
間複製を構成しない場合の 2 倍占有することになります。[ドメイン全体]または[指定]を選択した場合に
は、複製ドメインに参加するアプリケーション・サーバーの数または指定した数倍のメモリー領域を占有
することになります。また、パフォーマンスの観点からもできる限り、少ない複製の数を指定することが推
奨されます。逆に、[ドメイン全体]または[指定]を選択した場合には、複数のアプリケーション・サーバー
がダウンした場合にも、HTTP セッション・データをリカバリーすることが可能です。
また、垂直クラスターと水平クラスターを合わせて構築するような場合（2 つのアプリケーション・サーバ
ーを起動する筐体を 2 つで、計 4 つのアプリケーション・サーバーでクラスター構成を構築する場合）は
複製ドメインの設定に注意が必要です。全クラスター・メンバーが[単一レプリカ]の複製ドメインを使用す
ると、同一筐体のアプリケーション・サーバーにデータの複製を保持することもあります。この構成で、筐
体障害が発生した場合、セッションのデータが失われてしまうことがあります。これを避けるためには、レ
プリカの数を複数に設定するか、複数の複製ドメインを作成し、同一筐体上で稼動するアプリケーショ
ン・サーバーは異なる複製ドメインを使用するように設定します。
データ複製サービス（Data Replication Service）
データ複製サービスは、DRS（Data Replication Service）とも呼ばれる WAS の内部コンポーネントで
す。データ複製サービス機能は、アプリケーション・サーバー毎に稼動し、お互いに連携することにより、
クラスター配下の複数のアプリケーション・サーバー間におけるデータ複製を可能にします。WAS V6 で
は、データ複製サービスを使用して以下の機能を提供します。
•
HTTP セッションのメモリー間複製
HTTP セッションオブジェクト生成を実施する Web コンテナー稼動のアプリケーション・サーバーを
クラスター化した際に、アプリケーション・サーバー間でセッション情報のフェイルオーバーを実施
します。HTTP セッションのフェイルオーバーはセッション情報をデータベースに格納することでも
実現できますが、データ複製サービスではすべてメモリー間での複製となります。
•
ステートフル・セッションビーン複製
ステートフル・セッションビーンを使用する EJB コンテナ稼動のアプリケーション・サーバーをクラス
ター化した際に、アプリケーション・サーバー間でステートフル・セッションビーン情報のフェイルオ
ーバーを実施します。詳細は第 1 部 4 章「ワークロード管理、高可用性構成」の章を参照ください。
•
動的キャッシュの複製
動的キャッシュを生成・保持する Web コンテナー稼動のアプリケーション・サーバーをクラスター
化した際に、アプリケーション・サーバー間でキャッシュ情報の共有を実施します。1 つのキャッシ
ュを複数のアプリケーション・サーバーに保持することで、パフォーマンスの向上が見込めます。
尚、動的キャッシュの複製を行う場合は、使用する複製ドメインのレプリカの数の設定は[ドメイン
全体]を指定してください。詳細は第 2 部 3 章「パフォーマンス管理」の章を参照ください。
基本的には、各複製の種類に応じて、それぞれ異なる複製ドメインで構成する必要があります。例え
ば、HTTP セッションの複製と、動的キャッシュの複製は別の複製ドメインを使用します。しかし、同一の
クラスターで、HTTP セッションのメモリー間複製とステートフル・セッションビーンの複製を構成する場
合は、同じ複製ドメインを使用します。この場合は、同じ複製ドメインを使用することにより、HTTP セッシ
ョンおよびステートフル・セッションビーンの複製されたデータが、確実に同じアプリケーション・サーバー
上に置かれるようにします。
- 90 -
メモリー間複製の設定
メモリー間複製を構成する手順を以下に示します
1). メモリー間複製の設定画面を表示するには［サーバー］→［アプリケーション・サーバー］→
［Application Server_name］→［Web コンテナー設定］→［Web コンテナー］→［セッション管
理］→［分散環境設定］を開きます。
2). ［メモリー間の複製］のリンクをクリックします。
図 2-103
メモリー間複製によるセッション・パーシスタンス設定： 分散セッション実現方法の選択
3). 「構成」タブの項目を設定し、[OK]ボタンを押します。分散環境画面にもどります。
図 2-104 メモリー間複製によるセッション・パーシスタンス設定： 複製モードの選択
- 91 -
複製ドメイン
HTTP セッションが複製される複製ドメインを指定します。
複製モード
このサーバーを実行する必要があるモード (両方、クライアント、およびサーバー) を選択しま
す。モードは、データが送信専用 (クライアント)、受信専用 (サーバー)、またはその両方のいず
れであるかを暗黙的に指定するものです。デフォルトは両方です。
4). チューニング・パラメーターを変更する場合は、追加プロパティーの［カスタム・チューニング・パ
ラメーター］をクリックし、設定を選択するか、設定をカスタマイズします。詳しくは、2-5-4-3 チュ
ーニング・パラメーター設定 92）をご参照ください。
5). [メモリー間複製]のラジオボタンを選択し、[OK]ボタンを押します。
2-5-4-3 チューニング・パラメーター設定
分散セッションのチューニング・パラメーターを設定します。
1). チューニング・パラメーターを変更する場合は、「分散環境設定」の追加プロパティーにある［カス
タム・チューニング・パラメーター］をクリックし、チューニング・パラメータ設定画面に遷移します。
図 2-105 分散セッションのチューニング・パラメータ設定画面
- 92 -
2). チューニング・レベルを選択します。設定をカスタマイズする場合は、必要とする設定に最も近い
定義済み設定のいずれかを選択し、［カスタム設定］をクリックします。
図 2-106
分散セッションのカストマイズ
「書き込み頻度」で設定したタイミングで WAS はセッションオブジェクトを直列化してバイトコードの
データに変換し、データベースまたは、異なる JVM にコピーします。逆にセッション･データを読み込
む際には直列化処理されたデータを WAS が復元する作業が発生します。
「書き込み頻度」には、時間基準とサーブレット・サービスの終了の二種類があります。定期的設定
の場合は時間基準を使用し、時間間隔（たとえば 60 秒など）で設定可能です。ユーザーリクエストの
サーブレット処理の終了毎に書き込みを行う場合はサーブレット・サービスの終了での設定可能で
す。定期的設定を使用した場合には、障害時には最新のセッション・データについては失われる可能
性がありますが、通常時のパフォーマンスは、サーブレット処理毎よりも良いです。
書き込み頻度には、どこまで最新のセッション情報をコピーするかとパフォーマンスのトレードオフ
の関係が成り立ちます。カスタム設定のデフォルトは 10 秒間隔で、更新のあったセッション情報をデ
ータベースまたは異なるメモリーにコピーします。
- 93 -
2-6 トランザクション・サービス
WAS ではトランザクション・マネージャーによってトランザクション・サービスが提供されています。トラ
ンザクション・マネージャーはエンタープライズ Bean(EJB)で設定するトランザクション属性に従って、トラ
ンザクションの有効範囲を管理します。また、トランザクションに対してタイムアウトを設定することで、タイ
ムアウトを迎えたトランザクションをロールバックすることが可能です。この節では、EJB でのトランザクショ
ン属性の設定方法と WAS で設定可能なトランザクション・サービスの各パラメーターについて説明しま
す。
2-6-1 トランザクション属性
EJB では、トランザクション管理を EJB コンテナーに任せる場合（ Container Managed Transaction
(=CMT) ）、コード中にはトランザクション区切りを指定せず、「トランザクション属性」を指定することによ
ってトランザクションの有効範囲を管理します。トランザクション属性は 6 種類あります。ランタイムでは
EJB コンテナーが指定されたトランザクション属性に従い、メソッド呼び出し時点で「トランザクションの開
始」や「メソッド呼び出し元のトランザクション・スコープの引継ぎ」等のトランザクション管理を行います。ト
ランザクション属性はデプロイメント・ディスクリプターに記述します。
2-6-2 デプロイメント記述子への設定
EJB モジュールのデプロイメント記述子でトランザクション属性を設定します。デプロイメント記述子の
設定は、Application Server Toolkit (AST) などのアセンブリー・ツール、または RAD などの開発ツール
を使用して構成します。以下に、RAD を使用したトランザクション属性の設定方法を示します。
1). ［EJB デプロイメント・ディスクリプター］の［Bean］タブを開きます。セッション Bean の場合、トラ
ンザクション・タイプの属性に、［コンテナー］と［Bean］が選択できます。コンテナー管理トランザ
クション（CMT）を使用する場合は、［コンテナー］に、Bean 管理トランザクション（BMT）を使用す
る場合は、［Bean］を設定します。
- 94 -
2). コンテナー管理トランザクションについては、エンタープライズ Bean のビジネス・メソッドにメソッ
ド起動を委任する場合に、コンテナーによるトランザクション有効範囲をどのように管理するかを
構成します。
3). ［アセンブリー］タブを選択し、［コンテナー・トランザクション］のボックスの下にある［追加］ボタン
を押すします。
4). エンタープライズ Bean 選択ウィザードが表示されるので該当する Bean を選び［次へ］を選択し
ます。
- 95 -
5). Bean またはメソッドのリストが表示されますから、それぞれのメソッドに［コンテナー・トランザク
ション・タイプ］を設定し［終了］ボタンを押します。これにより、コンテナー・トランザクションが定義
されます。
- 96 -
2-6-3 トランザクション・サービス設定
トランザクション・サービスは、複数のリソース・マネージャーに対する更新を調整して、データ・トラン
ザクションのアトミック更新（不可分の作業単位として更新）がアプリケーションまたはそのアプリケーショ
ンがデプロイされているコンテナーによって始動および終了されることを保証できるサーバーのランタイ
ム・コンポーネントです。トランザクションは、永続的な更新か、永続的な更新がまったく行われないかの
どちらかです。WAS は、リソース・マネージャーの調整をサポートするトランザクション・マネージャーで
あり、分散グローバル・トランザクションに参加します。
トランザクション・サービスのプロパティーを確認・変更する場合は、管理コンソールから、［サーバー］
→［アプリケーション・サーバー］→［ApplicationServer_name］→［コンテナー・サービス］→［トランザ
クション・サービス］をクリックします。
図 2-107 トランザクション・サービスの設定： トランザクション・サービス設定画面へのリンク
- 97 -
下記のトランザクション・サービスのプロパティー画面が表示されます。
図 2-108 トランザクション・サービスの設定： プロパティ画面
トランザクション・ログ・ディレクトリー
トランザクション・ログのロケーションを指定します。これは、アプリケーションが分散リソースまたは XA
トランザクションを使用する場合の構成にのみ該当します。デフォルトは、
<Profile_root>/tranlog/Cell_name/Node_name/ApplicationServer_name/です。
合計トランザクション存続時間タイムアウト
トランザクションの最大存続時間 (秒単位) を指定します。
明示的に設定されたタイムアウトがないコンポーネント管理トランザクションには、この値が割り当てられ
ます。
クライアント非活動タイムアウト
リモート・クライアントからの各トランザクション要求間の最大所要時間 (秒単位) を指定します。
最大トランザクション・タイムアウト
このアプリケーション・サーバーにより開始された、またはこのアプリケーション・サーバーに伝搬されたト
ランザクションを実行できる最大存続時間 (秒単位) を指定します。
- 98 -