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