websphere application server network deployment v7.0 認定...

1

© 2010 IBM Corporation

®

WebSphere Application Server Network Deployment V7.0認定システムアドミニストレーター試験対策テキスト

WebSphere Application Server V7.0 Network Deployment, Core Administration

WebSphere Application Server Network Deployment V7.0 認定システムアドミニストレーター

試験対策テキスト

2010年9月第1.0版発行



編集・発行日本アイ･ビー･エム株式会社ソフトウエア事業

©Copyright IBM Japan, Ltd. 2010All Rights Reserved. Printed in Japan.

日本アイ･ビー･エム株式会社の文書による同意なく本製品およびテキストの一部または全部の無断転載、無断複写することを禁止い

たします。

本テキストの内容は予告なく変更されることがあります。

2

IBM Software Group | WebSphere software

2

目次

0. 認定試験概要 ………………………………………………… 3

1. アーキテクチャー概要 ……………………………………………… 7

2. WASの導入と構成 ………………………………………………… 28

3. アプリケーション・アセンブリーとデプロイメント …….……………. 43

4. セキュリティ ………………………………………………… 58

5. ワークロード管理 ………………………………………………… 73

6. 保守とパフォーマンス・チューニング ……………………………… 101

7. 問題判別 ………………………………………………… 130

8. 練習問題回答 ………………………………………………… 147

3


3

認定試験概要

4


4

試験概要

【認定資格】WebSphere Application Server Network Deployment V7.0 認定システムアドミニストレーター（000-377）

【試験名称】WebSphere Application Server Network Deployment V7.0Core Administration (000-377)

【試験時間】90分

【試験料金】18,900円

【出題形式】コンピューターでの出題、全て選択問題

【出題数】56問

【合格ライン】58%以上の正解で合格

WebSphere Application Server Network Deployment V7.0 認定システムアドミニストレーターはワールドワイドで

共通の、システム管理者向けの資格となります。WebSphere Application Serverの管理について、幅広く出題さ

れます。（詳細は次ページ参照）

5


5

出題範囲

・WASのネームサービス（JNDI)について説明できる

・RAD ADを使ってEnhancedEARファイルを含むJava EEアプリケーションをパッケージングできる

・セキュリティーロール（ex.Java EEセキュリティ）の定義とマッピングができる

・JDBCプロバイダーとデータソースの設定ができる

・JCAリソースアダプター、コネクションファクトリー、MDBアクティベーションスペックを構成できる

・WebSphere JMSプロバイダーを構成できる

・スクリプトを使用してデプロイメントを実行できる

3.アプリケーション・アセンブリーとデプロイメント(21％)

・セキュリティー・ポリシーの実装

・WebSphereリソースの保護

・WebSphere管理に関するセキュリティの定義と実装

・SSLを使用する場合のプラグイン構成

・VMMを使用した統合リポジトリーの理解と実装

4．セキュリティー(16％)

・導入時のオプションと構成方法について理解している

・WASをインストールして、プロファイルを作成できる

・インストールの妥当性を検証できる

・Installation Factoryの利用し、CIP(Customized Installation Package)を作成できる

・インストール時の問題判別ができる

2．WASの導入と構成（9％）

・WASとその他のアプリケーション・コンポーネント(ブラウザ、HTTPサーバー、プラグイン、Firewall、データベース・サーバー、WebSphere MQ、ロードバランサー、IPスプレイヤーなど）の関係について理解できる

・企業のシステム構築において適なWASのパッケージを選択し導入することができる

・WAS NDの様々なコンポーネントについて理解できる

・WASを利用した場合のワークロード管理とフェイルオーバーについて説明できる

・WAS NDセル・モデルとフレキシブル・マネジメント・モデルの違いについて理解できる

・WebSphere 動的キャッシュについて説明できる

1.アーキテクチャー(13％）

主な内容章タイトル

6


6

出題範囲（続き）

・WebサーバーやWASのログを調べて分析する

・トレース機能を利用できる

・FFDCツールを利用できる

・JNDI dumpNameSpaceユーティリティーを利用できる

・問題判別の様々な課題を実行できる(スレッドダンプ、JVMコアダンプ、リモートデバッグなど）

・IBM Support Assistantを利用できる

7．問題判別

・アプリケーションの構成を管理できる（アプリケーション・バインディング、タイムアウト値のようなHTTPセッ

ション構成パラメーターの調整）

・バックアップ、リストアの実行と構成タスクのアーカイブ

・ログやファイルのサイズを監視し、必要に応じてバックアップ/消去できる

・プラグイン構成ファイルを管理できる

・パフォーマンスチューニングができる（キャッシュの構成、キューイングやプーリング・パラメーター構成、JVMヒープサイズ調整など）

・Tivoli Performance ViewerやRuntime Advisorを使って情報を収集し、結果を分析する

・データソースの構成を調整できる（コネクションプール、タイムアウトなど）

・クラス・ローダーのパラメーターを構成できる

6．保守とパフォーマンス・チューニング(14％）

・ノードを統合する（カスタム・プロファイルを含む）

・クラスターとクラスター・メンバーを作成する

・セッション・パーシステンスの方法を理解している（Memory to Memory, データベースによる保持）

・DRS (Data Replication Service) ドメインを作成、構成できる

・管理対象ノード, 非管理対象ノードのWebサーバーの管理

5．ワークロード管理 / スケーラビリティー / フェイルオーバー(14％)

主な内容章タイトル

7


7

1章アーキテクチャー概要

8


8

堅牢なWebシステム構成に必要なコンポーネント

負荷分散サーバー：クライアントからの要求を受けつけ、Webサーバへ転送。Edgeコンポーネントのロードバランサーなどが使用される

Webサーバー

– 静的ページの要求であればクライアントに応答を返す

– 動的コンテンツの要求にはリクエストをアプリケーション・サーバーへ転送

アプリケーション・サーバー： Webサーバーから転送されたリクエストを受付け、動的コンテンツを生成

DBサーバー：アプリケーションに必要なデータやセッション情報などを保存し、一元管理

負荷分散サーバー

Webサーバーアプリケーションサーバー

DBサーバーFWFW

DMZ（非武装地帯）

ハイ・アベイラビリティー&フェイルオーバーを実現

Webシステムを構成する上で必要となるコンポーネントについてご説明します。

インターネットやイントラネットを経由してのクライアントからのリクエストをまず受け付けるのが負荷分散サーバーです。

負荷分散サーバーではWebサーバーへの負荷分散及び障害検知を行います。Webサーバーが受け付けたリクエストに

動的ページの要求があった場合、その処理をアプリケーション・サーバーに依頼します。アプリケーション・サーバーは

処理の内容に応じてデータベースのデータを更新・検索などの処理を行い、動的ページの生成を行い、結果をクライア

ントに返します。

また、FWとはファイアウォールを指します。ファイアウォールを導入することにより、外部の攻撃から社内ネットワークを

守り、セキュリティを大幅に高めることが可能となります。インターネットの場合には必須となるコンポーネントになります。

上図でFWに囲まれた区域を、非武装地帯（DMZ : DeMilitarized Zone）と呼びます。セキュリティーレベルを分離するた

め、非管理対象のWebサーバーをDMZに配置することが推奨されます。

この図では、負荷分散サーバー、Webサーバー、アプリケーション・サーバー、データベース・サーバーが全て複数サー

バーで描かれています。全てのサーバーを複数台用意することにより、可用性、耐障害性を高め負荷を分散させること

が可能となりますが、これは一例なので、FWの配置箇所やWebサーバーの配置箇所、サーバーの台数などは要件に

よって異なります。

9


9

WASV7.0のエディション

WebSphere Application Server-Express

ISVソリューション

の基盤

WebSphere Application Server(Base)

WebSphere Application Server Network Deployment (ND)

シングルサーバーの実行環境を提供

分散環境で、新のクラスタリング、HA(高可用性)機能、

管理機能を提供

WindowsWindows LinuxLinux AIXAIX SolarisSolaris HP-UXHP-UX OS/400OS/400 z/OSz/OS®® ®® ®® ®® ®® ®®

WebSphere Application Server for Developers

開発者向けのエディション

WAS V7.0では以下のパッケージが提供されます。

・WebSphere Application Server V7.0 - Express

・WebSphere Application Server V7.0 (以降Base)

・WebSphere Application Server V7.0 - Network Deployment (以降ND)

・WebSphere Application Server V7.0 for Developers

Express、Base はスタンドアロンで稼動します。NDは複数サーバーによるクラスタ機能をサポートするパッケージで、負

荷分散、可用性のための様々な機能を提供します。NDにはロードバランサーおよびキャッシングプロキシー機能を提供

するEdge Componentsが同梱されています。

WebSphere Application Server V7.0 for Developers はテスト環境として利用可能な開発者向けのWASのエディションで

す。

全パッケージにEJBの実行環境がつき、Java EE 5をフル・サポートします。

10


10

各パッケージの比較

RAD AD : IBM Rational Application Developer Assembly and Deploy Features for WebSphere Software V7.5 (Eclipseベースの開発ツール）注1 : 2台までのセッション・フェイルオーバーのみ、WAS Express, WAS (Base)でもサポートされます。詳細についてはライセンス証書をご確認ください。注2 : 2009年2月に追加となりました。対象プラットフォームに制限がありますので、詳細はこちらをご参照ください。 http://www.ibm.com/jp/domino01/mkt/websphere.nsf/doc/0042B032注3 : x86 Quad Core で1Core=70PVU のマシンに限定されます。CPU タイプによって利用可能な最大PVU数が異なりますので、ご注意ください。注4 : WAS for Developers は開発のためのライセンスであり、ユーザー単位に課金。サポートのない無償版も提供中。プラットフォームや同梱物に制限があります。詳細についてはこちらを

ご参照ください。http://www.ibm.com/software/jp/websphere/evaluate/wasdevelopers/

×○××複数サーバーの集中管理

○○○○Webサービスサポート

○

DB2（使用に制限あり）

RAD AD

○

○

○

○

○

○

○

○

○

無制限

WAS ND

×××Job Manager

○○○Web 2.0 Feature Pack サポート

○○○SIP / Portlet サポート

×××Edgeコンポーネント

RAD ADRAD ADRAD AD同梱開発ツール

××注1×注1クラスター構成(フェイルオーバー、ワークロードバランス)




同梱データベース

○○○IBM HTTP Serverと

Web Server plug-inの同梱

×○×64bit対応

×××Proxy Server / Secure Proxy Server

○○○Java EE 5サポート (EJB 3.0含む)ユーザー課金注4無制限PVU 280まで注3導入可能プロセッサー数

×

WAS Express WAS for DevelopersWAS (Base)内容

×○注2Tivoli Directory Server (LDAP server) とTivoli Access Managerの同梱

この表は各パッケージを比較したものです。

WAS V7.0では、すべてのエディションでJava EE 5 をサポートします。Java EE 5 にはEJB 3.0、JPAが含まれます。

コア・アプリケーション・サーバー、IBM HTTP Server、Web サーバー・プラグイン、アプリケーション・クライアント、およ

びダイレクト JDBC ドライバーは、すべてのバージョンに付属しています。

V6.x 以前に提供されていた同梱開発ツールのApplication Server Toolkit (AST) の後継として、V7.0ではRational Application Developer Asssembly and Deploy Features for WebSphere Software V7.5 (以降RAD AD) が提供さ

れます。RAD ADについては3章で詳しく説明します。

11


11

WASの基本構成要素

アプリケーションサーバー

– Java EE 5 完全準拠のアプリケーション、一つのJavaプロセス

– Java EE 5 / J2EE (1.4、1.3) アプリケーション実行環境（以下の機能）を提供

• Webコンテナー– HTTPトランスポート・チェーン

– SIPコンテナー

– Portletコンテナー

• EJBコンテナー

• JCAサービス

• Webサービスエンジン

• セキュリティ

• ネーミング・サービス

• トランザクション

• パフォーマンス・インフラストラクチャー

• WLM/HA• メッセージング・エンジン

• 動的キャッシュ

Webサーバー上の構成要素

• Webサーバー

• Webサーバー・プラグイン

クライアント

Application Server

Webサーバー

Webコンテナー

Webサーバー

プラグイン

HTTPトランス

ポート・チェーン

SIPコンテナー EJBコンテナー

JCAサービス

Portletコンテナー

Webサービスエンジン

セキュリティ

ネーミングサービス

トランザクションパフォーマンス・モニタリング・

インフラストラクチャー

WLM/HA メッセージングエンジン

動的キャッシュ

アプリケーション・サーバー

Java EE5準拠のアプリケーション・サーバーで、一つのJavaプロセスとして稼動します。以下の機能を提供します。

○Webコンテナー：サーブレットやJSPの実行環境を提供します。

○HTTPトランスポート・チェーン：Webサーバー・プラグインから送られたリクエストを、Webコンテナーに渡します。

○SIPコンテナー：SIPアプリケーション・サーブレットを呼び出し、SIP要求を処理します。

○Portletコンテナー：ポートレットAPIを使用するポートレットの実行環境を提供します。

○EJBコンテナー： EJBの実行環境を提供します。EJBコンポーネントのトランザクション管理を提供します。

○JCAサービス：EIS (Enterprise Information System) へのアクセスの接続管理サービスを提供します。

○Webサービスエンジン：Webサービスの実行環境を提供します。

○セキュリティ：Java EEセキュリティ、WebSphereセキュリティ機能を提供し、認証/認可/データ保全性/機密性などに対

応します。

○ネーミング・サービス：オブジェクト（データソース、EJBホーム・インターフェースなど）と名前とを関連づけ、その名前を

キーとしてオブジェクトを検索するためのサービスです。

○トランザクション：リソースマネージャーの調整をサポートするトランザクション・マネージャー機能を提供します。

○パフォーマンス・モニタリング・インフラストラクチャー：WASのパフォーマンスに関するデータを収集、分析をします。

○WLM/HA：負荷分散、高可用性の機能を提供します。

○メッセージング・エンジン：JMSをサポートする非同期メッセージング・インフラストラクチャーを提供します。

○動的キャッシュ：サーブレット、コマンド、JSPの出力をキャッシングし、パフォーマンスを改善します。

Webサーバー上の構成要素

○Webサーバー：HTTPのリクエストを受け付けます。WASプロセス内でHTTPを受け付けるHTTPトランスポートを内部

HTTPサーバーと呼び、それに対してWebサーバーを外部HTTPサーバーと呼ぶことがあります。

○Webサーバー・プラグイン：受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへ

リクエストを転送します。HTTPプラグインとも呼ばれます。

12


12

WAS Network Deploymentの管理トポロジー

ノード B ノード C

ノード A マスター

セル・構成情報

ノードB・構成情報

サーバーA・構成情報

ローカルローカル

EARファイル EARファイル



セル

サーバーB・構成情報

ノードC・構成情報

サーバーC・構成情報

サーバーD・構成情報

サーバーA・構成情報

サーバーB・構成情報

サーバーC・構成情報

サーバーD・構成情報

ノードB・構成情報

ノードC・構成情報

AS : アプリケーション・

サーバーA

DM : デプロイメント・マネージャー

NA : ノード・エージェント

NA : ノード・エージェント


サーバーB


サーバーC


サーバーD

WAS NDにおける管理トポロジーを表した図です。

WAS NDの管理単位をセルと呼んでいます。セル内には一つのデプロイメント・マネージャーが存在し、管理下全ての構

成情報のマスターを管理します。各マシンごとにノード・エージェントとよばれる管理エージェントが存在し、ローカルにも

構成情報を保管します。

構成情報のなかにはセル全体の情報、ノードごとの情報、サーバーごとの情報が含まれます。EARファイルとはJava EE

(J2EE) アプリケーションファイルです。これもノード単位の管理と、セル全体ではデプロイメント・マネージャーが管理しま

す。また、ノード・エージェントは各アプリケーション・サーバーの障害の監視も行います。

セル構成でアプリケーション・サーバー間で管理情報やセキュリティ情報などを通信する際には、RMI/IIOPやSOAPのプ

ロトコルが使用されます。

ND環境では、デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーの3つを起動します。アプリ

ケーション・サーバーを始動するには、アプリケーション・サーバーが配置されているノードのノード・エージェントがあら

かじめ実行されている必要があります。

WAS V7ではひとつのセルにV6とV7のノードを混在させることができます。ただしこの場合、デプロイメント・マネージャー

はV7である必要があります。

デプロイメント・マネージャーはセル内に一つしか存在しないため、Single Point of Failureとなりえます。管理コマンドを

デプロイメント・マネージャー経由で定期的に実行している場合は影響があります。

13


13

フレキシブル・マネジメント

AS

ノード

ノード

ノードノード

ノードノードノード

Base/Expressサーバー

Base/Expressサーバー

DM

NA AS AS

JM :ジョブ・マネージャー

AA:管理エージェント

AS

ノード

AS

ノード

NA

AS

ノード

ノード

DM

NA

NDセル NDセル

運用、管理などの処理をジョブとして一箇所にキューイングし、複数サーバーに対して非同期に実行

複数のNDデプロイメント・マネージャーにまたがった、

管理アクションの統合、一元管理が可能

複数Base/Express環境の統一的な運用が可能

– Job ManagerのみWAS NDライセンスが必要

地理的に拡散されたサーバー管理にも適した仕組み

分散環境の管理にかかる負荷を削減WAS単体で管理ジョブの非同期実行の仕組みを提供

AA:管理エージェント

従来、スタンドアロン環境では各サーバーを個々に管理し、またセル環境ではデプロイメント･マネージャーがノード･

エージェントを通じてノード内のサーバーを管理していました。管理対象は個々のサーバーレベルのため、複数スタンド

アロン環境や複数セル環境が存在する場合には、それぞれの環境を個別に管理する必要があり、大規模環境での運

用性には限界がありました。

そこで登場したフレキシブル・マネジメントを使用することにより、複数セル環境が存在する場合には、複数のデプロイメ

ント･マネージャーの一元管理や管理アクションの統合が可能になりました。複数のスタンドアロン環境が存在する場合

には、統一的な運用が可能になりました。また、管理対象のノードは、地理的に拡散されていても非同期でジョブを実行

するため、ネットワーク負荷を軽減することができます。

ただし、フレキシブル・マネジメントは、セルの管理モデルを置き換えるものではなく、セル管理モデルを拡張してより柔

軟な管理を実現するモデルといえます。

14


14

管理トポロジー用語解説セル (Cell)– ノードの集まりで論理的な管理の単位

– デプロイメント・マネージャーはセルを構成する

デプロイメント・マネージャー (DM/Deployment Manager)– セル内のノードを一括管理

– DMの管理コンソールにアクセスすることによりセル内の全てのリソースを管理

ノード (Node)– 通常は物理的な一つのマシンに対応

– 一つのマシン上に複数のノードを構成することも可能

– アプリケーション・サーバーの集まり

ノード・エージェント (NA/Node Agent)– 一つの管理ノードに一つ存在

– 管理用のエージェント

– ノード配下のアプリケーション・サーバーやWebサーバーを管理

ノード・グループ (Node Group)– セル内のノードを管理することを目的として定義

– 異なる機能を持つノードごとにグループを作成し、クラスター作成のためのポリシーを確立する

・セル(Cell)

論理的な管理の単位です。

・デプロイメント・マネージャー (DM/Deployment Manager)

セル内のコンポーネントを一括管理し、セルに必ず一つ存在します。

・ノード (Node)

物理マシンの単位で、アプリケーション・サーバーの集まりです。

・ノード・エージェント(NA/Node Agent)

ノード内を管理する管理用のエージェントです。一つのノードに必ず一つ存在します。

・ノード・グループ (Node Group)

クラスターのようにワークロード管理のためではなく、管理上の目的で、同一セル内の異なる機能を持つノードを組み

合わせてグループを作成します。

デフォルトでは、すべてのノードはDefaultNodeGroup ノード・グループのメンバーになっています。

15


15

管理トポロジー用語解説

アプリケーション・サーバー (AS/Application Server)– Web／EJBコンテナー、ネーミング・サービス、リソース管理、JMSプロバイダーなどが含まれる

アプリケーション･サーバー・クラスター

– ワークロード管理のために、複数のアプリケーション・サーバーを論理的にグループ化する

– 水平または、垂直にメンバー・サーバーの数を拡大することが可能

管理エージェント (Admin Agent)– セルに統合されていないアプリケーション・サーバー・ノードを管理するための単一インターフェースを提供

ジョブ・マネージャー (Job Manager)– 複数セルのデプロイメント・マネージャーや管理エージェントに登録されたアプリケーション・サーバー・ノード

の管理ジョブを非同期に実行

・アプリケーション・サーバー(AS/Application Server)

Webコンテナー、EJBコンテナー、ネーミング・サービス、リソース管理、JMSプロバイダーなどを提供します。

・アプリケーション・サーバー・クラスター

ワークロード管理のために、同じアプリケーションがインストールされた複数のアプリケーション･サーバーを論理的に

グループ化し、リクエストを分散して処理することができます。別筐体の複数アプリケーション･サーバーをグループ化す

る水平クラスターと、同一筐体の複数アプリケーション・サーバーをグループ化する垂直クラスターを作成することができ

ます。

・管理エージェント (Admin Agent)

セル内で管理されていないスタンドアロンのアプリケーション・サーバー・ノードの管理ジョブを実行するためのエージェ

ントです。

・ジョブ・マネージャー (Job Manager)

ジョブ・マネージャーでフレキシブル・マネジメントを実現することで、複数セルのデプロイメント・マネージャーや管理

エージェントに登録されたアプリケーション・サーバー・ノードの管理ジョブを非同期に実行することができます。

16


16

ジョブ・マネージャーの機能

ジョブ・マネージャーはジョブの非同期実行をサポート

– 管理機能のスケジューリング、無効化の時間設定

– 特定の時間間隔での繰り返し実行

– ジョブの完了通知の送信（e-mail）

以下のジョブに関して柔軟な管理機能を提供

– アプリケーション・サーバー / クラスターの始動 / 停止 / 作成 / 削除

– アプリケーションのインストール / アンインストール/ 更新 / 始動 / 停止

– ファイルの配布 / 収集 / 除去

– wsadminスクリプトの実行

– プロキシー･サーバーの作成 / 削除

– プロパティーの構成

– インベントリー

状況

– ステータスの確認機能

– ジョブ実行の成功 / 失敗 / 未完了など、それぞれのステータスのノード数などの表示

アプリケーション･サーバー管理機能

ND構成(DM+NA)

Base構成(JM+AA)

リモート管理 √ √コンソール経由でのFine-grained管理

√ X

管理用プロセスが停止した場合の管理(ローカル接続) √ X

クラスタリング(ワークロード管理) √ △

クラスタリング(Failover) √ △

プラグインに基づくHTTPリクエス

トのルーティング√ △

データ複製(メモリーベースのセッションレプリケーション) √ X

構成のバックアップ/リストアの集

中化√ X

パフォーマンス・モニタリング √ △

管理機能のスケジュール化 X √

ND構成とBase構成(Job Manager、管理エージェント)の比較→ジョブ・マネージャーはNDセルにおけるDMとは異なるため、

Base構成では一部制限あり

ジョブ・マネージャーとは、運用、管理などの処理をジョブとして一箇所にキューイングし、複数サーバー(Base/Expressサーバー)とNetwork Deploymentセルに対して非同期で実行する仕組みを提供します。

ジョブ・マネージャーにて実行できるジョブとして、以下があります。

- アプリケーションのインストール

-アプリケーション・サーバーの作成/起動/停止

-wsadminスクリプト

-ファイルの収集/配布/除去等

また、Network Deploymentのデプロイメント・マネージャー・セル環境と比較して、フレキシブル・マネジメントでは実現

できない管理機能がありますので、ご注意下さい。フレキシブル・マネジメントは運用上、必須の機能ではなく、またデプ

ロイメント・マネージャー・セルの管理モデルと置き換わるものでもありません。状況によって使いわけることができ、デプ

ロイメント・マネージャー・セルと共存することも可能です。

17


17

管理エージェント

WAS Base構成とExpress構成のための集中管理エージェント

– 管理エージェントは、シングル･サーバー・ノードの代理としてジョブ･マネージャーからのジョブを取得する

– シングル・サーバー・ノードを管理エージェントにRegister（登録）して管理

セルに管理エージェントが登録されると、“管理対象ノード”として扱われる

– 管理機能を管理エージェントに移行させることで、アプリケーション･サーバーのフットプリントの縮小と起動時間の短縮を実現

• 構成管理/アプリケーション管理/コマンド･マネージャー/ファイル転送/管理コンソールの機能を移行

– 管理対象ノードは管理コンソールから複数サーバーを構成することが可能

– ノードを管理エージェントの管理対象外にすることも可能

AS

アプリケーション

管理エージェントシングル

･サーバー構成情報

管理エージェント管理

コンソール

wsadmin

従来の構成管理（BASE）管理エージェントにプロファイル登録後の構成管理

管理サービス/JMX 構成サービス

アプリケーション管理

管理コンソール･アプリケーション

管理サービス/JMX 構成サービス

アプリケーション管理

管理コンソール･アプリケーション

管理コンソール

wsadmin

ノード

管理対象ノード

ノード

AS 管理サービス/JMX

アプリケーション管理エージェントと管理対象ノードは同一筐体に配置

管理エージェントと管理対象ノードは同一筐体に配置

シングル･サーバー構成情報

管理エージェントとはWAS Base構成とExpress構成を管理するためにV7で新しく加わった管理コンポーネントです。管

理エージェントにより複数のBase構成とExpress構成を集中管理することが可能になりました。

シングル・サーバー・ノードが登録されるとそのノードは管理対象ノードとして扱われます。管理エージェントの管理対象ノードになると構成管理/アプリケーション管理/コマンド･マネージャー/ファイル転送/管理コンソールの機能が管理エー

ジェントに移行され、アプリケーション･サーバーのフットプリントを縮小させ起動時間を短縮させることができます。また、

管理エージェントは管理エージェントの管理対象ノードであるシングル･サーバー･ノードの代理としてジョブ・マネー

ジャーからのジョブを取得し、各シングル･サーバー･ノードに対してジョブを実行させることが可能です。そのためには管

理エージェントの管理対象ノードをジョブ・マネージャーに登録する必要があります。

18


18

高可用性・負荷分散のための機能ワークロードマネージメント(WLM)

3段階でのWLMを提供

– WebSphere Application Serverクラスター構成によるWLM

– Edgeコンポーネントのロードバランサー（負荷分散サーバー）によるWebサーバーへの負荷分散

ロード・バランサー

(Primary)

ロード・バランサー

(Backup)

プラグイン

Webサーバー

プラグイン

Webサーバー

ApplicationServer

Webコンテナー

ApplicationServer

Webコンテナー

ApplicationServer

EJBコンテナー

ApplicationServer

EJBコンテナー

① ロード･バランサーによるHTTPサーバーへのWLM

② Webサーバー・プラグインによるWebコンテナーへのWLM

③EJBクライアントのWLMプラグインによるEJBコンテナーへのWLM

DB

NDでは3つのリクエスト・タイプ（HTTPリクエスト, Servletリクエスト, EJB リクエスト）毎にワークロード管理（WLM）を行な

うことが可能です。

1. HTTPリクエスト

複数Webサーバーへの負荷分散は負荷分散サーバーが行います。負荷分散サーバーにはハードウェア・タイプとソフト

ウェア・タイプがありますが、NDにはソフトウェア・タイプのEdge Components (ロード・バランサー) が同梱されています。

2. Servletリクエスト

Webサーバー上のWebサーバー・プラグインが Webコンテナーへリクエストの分散を行います。

3. EJBリクエスト

EJBリクエストは、ORB（Object Request Broker）のWLMプラグインが複数EJBコンテナーに対して分散をおこないます。

また、複数マシン構成では、稼働システムの大負荷を処理できるマシン数を準備します。

19


19

WAS 可用性の向上 HA Managerミッションクリティカルなアプリケーションの連続した稼動を可能にするHA機能を提供

デプロイメント・マネージャー

ノード・エージェント


ノード・エージェント



コア・グループ

障害検知

HAマネージャー






シングルトンサービス(TM,ME)

の引継ぎ情報の共有

(EJB WLM情報の引継ぎ)

構成情報の作成・変更

•構成情報の同期•アプリケーション・サーバーへのPing、再起動

アプリケーション・サービスの実行

WAS V6より、ミッションクリティカルなアプリケーションの連続した稼動を可能にするHA機能を標準搭載されました。

HACMPなどのHA機能ではなく、WASに組み込まれた機能を使用しますので、一部のサーバーがダウンした時に、アプ

リケーションのレベルで、高速な引継ぎが可能となります。

WASのセル内のJavaプロセス上で、HA Managerが稼働します。HA Managerは、どのサーバーでどのようなサービスが

実行されているかを監視し、問題発生時には、サーバーで稼働するシングルトン・サービスのフェイルオーバー処理を行

います。フェイルオーバー対象のサービスはトランザクション・マネージャー機能とメッセージング・エンジン機能です。ま

た、アプリケーションに関する動的な情報をお互いにやりとりしています。

20


20

HA Managerによるトランザクションの回復方法

HA Managerによる自動リカバリーを実行（ユーザーの介入は不要）

– HA Managerがアプリケーション・サーバーの障害を検知

– 別のアプリケーション・サーバーがトランザクションログを引継ぎ、処理途中のトランザクションをリカバリー

NDクラスター

AS1

TM1

TM1 log共用ディスク

AS2TM2

TM2 log

共用ディスク

データベース

2PC中にLockを取得したままサーバーダウン

AS1

TM1TM1 log

共用ディスク

AS2

TM2TM2 log

共用ディスク

データベースAS1のTran logにアクセスし、トランザクションを完了

障害発生

ロックされているので他のアプリケーションから

アクセスできない！

トランザクション・サービスの自動移行により、

ロックの早期開放が可能

TM1の

リカバリ Lockの解放自動で、TM1のリカバリ・プロセスが開始

HA Managerのフェイルオーバー機能の対象サービスとしてトランザクション・マネージャーがあります。

2フェーズ・コミット処理実行中にアプリケーション・サーバーに障害が発生した場合、インダウト・トランザクションが残り、

リソースに対してロックを保持したままになってしまう可能性があります。HA Managerは、アプリケーション・サーバーの

障害を検知し、即座にトランザクション・マネージャー機能を、稼働している別のアプリケーション・サーバーにフェイル

オーバーします。トランザクション・マネージャー機能を引き継いだアプリケーション・サーバーは、障害サーバーのトラン

ザクションログにアクセスし、インダウト・トランザクションのリカバリー処理を開始します。

この構成において、リカバリーに要する時間は数秒ですが、トランザクションログを保管する共有ディスクが必要になります。共有ディスクは，リースベースの排他ロックに対応したNFS V4やSANなどを使用する必要があります。

21


21

JMSプロバイダー機能

WAS V7.0 で利用可能なJMSプロバイダー

– サービス統合バス（SIBus）のメッセージング機能

• 「デフォルト・メッセージング」として使用できる

• Pure Javaで書かれたWMQライクなメッセージング・エンジン

• WMQとリンク可能

– WebSphere MQ

• 多くのプラットフォームをサポート

• 実績が豊富

• 高い信頼性

– WAS5の組み込みメッセージング・サービス

• 「V5 デフォルトのメッセージング」として使用可能

• WAS5.xからマイグレーションした場合に利用

– その他のJMSプロバイダー

• 「汎用」として使用できる

• WMQ以外のJMSプロバイダー

JMSプロバイダー

メッセージング・サービス

SIBus

JMSClient

WMQ

他社メッセージング製品

JMS

ClientJMS JMS

WAS V7.0で利用可能なJMSプロバイダーです。

「デフォルト・メッセージング」は、WAS V7.0で利用可能なSIBus (Service Integration Bus：サービス統合バス)のメッセー

ジング機能を利用します（SIBusについては後述）。WAS V7.0はJava EE 5を実装しているので、Java EE 5に含まれる

JMS1.1を利用可能です。

WebSphere MQ(以下WMQ、またはMQ)は、多くのプラットフォームをサポートするIBM製品です。豊富な実績と、高い信

頼性が評価されています。

V5 デフォルト・メッセージングは、WAS5.xの組み込みメッセージングです。WAS5.xからマイグレーションした場合に利用

します。

それ以外のJMSプロバイダーも、汎用JMSプロバイダーとして利用可能です。

22


22

SIBus(サービス統合バス）

サービス統合をサポートするための通信基盤の提供– Webサービス、JMSなどJava EEの標準をサポート

– 非同期インフラとして「メッセージング・エンジン」が稼働

以下の機能を提供– メッセージのルーティング及びフォーマット変換機能

– 通信の複雑性を隠蔽し新規アプリケーション、システムの変更に柔軟に対応可能

– メッセージ転送の信頼性、高可用性、ワークロード・マネジメント及びセキュリティ機能を提供

– プロトコル変換機能を提供

– MQリンク経由でWebSphere MQと接続可能

SI-Bus

JMSJMS

リンク

WebSphereMQ

WebSphereV7セル

Webｻｰﾋﾞｽ

SI-Bus

JMSJMSWebｻｰﾋﾞｽ

SIBusはWASV6.0から追加されたコンポーネントで、Webサービス連携に必要な通信インフラストラクチャーを提供します。

Webサービス、JMSなどの通信プロトコルをサポートし、非同期通信インフラとして「メッセージング・エンジン」が稼働しま

す。メッセージの操作やWMQ接続機能などESB (Enterprise Service Bus)を構成できる機能を提供します。

23


23

SIBusのトポロジー構成

ポリシー・タイプは4種類を提供

– 高可用性ポリシー

– スケーラビリティー・ポリシー

– 高可用性を備えたスケーラビリティー・ポリシー

– カスタム・ポリシー

バス

FailOver

高可用性ポリシースケーラビリティー・ポリシー

Cluster

Cluster Member

Cluster Member

ME

ME

高可用性を備えたスケーラビリティー・ポリシー

バス

FailOver

Cluster

Cluster Member

Cluster Member

ME

ME ME

ME

FailOver

コア・グループ・ポリシー

サーバー障害

コア・グループ・ポリシーコア・グループ・ポリシー

バス

FailOver

Cluster

Cluster Member

Cluster Member

ME

ME ME

ME

FailOver

コア・グループ・ポリシーコア・グループ・ポリシー

WAS V7のSIBusのメッセージング・エンジン(ME)では、以下の4種類のメッセージングポリシーを提供します。

・高可用性ポリシー

・スケーラビリティー・ポリシー

・高可用性を備えたスケーラビリティー・ポリシー

・カスタム・ポリシー

詳細は5章のワークロード管理で説明します。

24


24

SIP(Session Initiation Protocol)SIP (Session Initiation Protocol) はエンドポイント間でのリアルタイム通信のネゴシエーションや

制御を行うためのプロトコル

– リアルタイム通信：テキスト、音声、映像などの大量データの迅速な通信

– SIPの基本メソッドを順に呼出し、セッションの開始・終了も行う

• INVITE, ACK, CANCEL, BYE, REGISTER）など

WAS V7.0 による実行環境サポート

– SIP の標準仕様をサポート

– SIP コンテナーの提供

• SIPリクエスト/リプライが送受信される媒体となるネットワーク・サービスを提供

– SIP Proxyの提供

• SIPリクエストのロード・バランシング、リクエストの種類などに応じた割り振りを提供

WAS V7.0 Feature Pack for Communication Enabled Application (CEA)– WASの無償追加パッケージFeature Pack for CEAではSIP Servlet V1.1 (JSR 289) をサポート

– リモートSIPセッションにアクセスするための非同期呼び出しAPI

SIP (Session Initiation Protocol) は、エンドポイント間で通信を開始するためのプロトコルです。主な目的としては、各種

のメディアのセッションのネゴシエーションやセッションの変更などがあります。開始するメディアの種類は問いません。

ネゴシエーションとメディアの通信は別の経路を通ります。セッションは継続して存在し、変更も可能です。SIPを使用す

るときにクライアントは以下のような基本メソッドを順に送信し、セッションの確立・終了などを行います。

・ INVITE・・・セッションを開始する一番初に送信されるメソッドです。

・ ACK・・・INVITEに対する終レスポンスを受信した事を知らせるメソッドです。

・ CANCEL・・・INVITE処理を中止するメソッドです。セッション確立後はCANCELすることはできません。

・ BYE・・・セッションを中断するためのメソッドです。

・ REGISTER・・・ユーザーが自分のロケーションをサーバー（レジストラ）に通知するためのメソッドです。

SIPコンテナーはSIPリクエスト/リプライ送受信のためのネットワーク・サービスを提供します。

また、SIPコンテナーは、SIPプロキシー・サーバーを使用してSIPリクエストのルーティングやロード・バランシングを行う

こともできます。

WebSphere Applciation Server V7.0では新の機能をFeature Packという無償追加パッケージという形で提供しており、

SIP Servlet V1.1をサポートするFeature Pack for Communication Enabled Application (CEA) が利用可能です。Feature

Pack for CEAでは、Click to Call、共有ブラウジングといったマルチモーダル通信を実現可能にし、Webサービス、REST

サービス・ベースのAPIを提供することでより豊富なユーザー・エクスペリエンスを提供します。

詳しくは以下のWebページを参考にしてください。

http://www-06.ibm.com/software/jp/websphere/apptransaction/was/featurepacks/cea/features.html

25


25

ポートレット (Portlet)ポートレット (Portlet) とは

• 再使用可能な Web モジュールで、Web ベースのコンテンツ、アプリケーション、およびそ

の他のリソースへのアクセスを提供

• ユーザーの側から見れば、ポートレットはポータル・サイト上のウィンドウ

WAS V7.0のポートレットサポート

– ポートレット・コンテナーの提供

• JSR168に準拠するポートレットのインストールおよびデプロイメントをサポート

ポートレットのアクセス

– 2つの方法を提供

1. PortletServingServlet経由の呼出

– 単一のポートレットへのアクセス

> ポートレットの名前を含む URL を使用して、ポートレットを直接呼出

– ibm-portlet-ext.xmiでポートレット・サービス提供を使用可能に設定

2. JSPによる集約

– 複数のポートレットを集約したポータル・ページへのアクセス

– ポートレット・JSPタグ・ライブラリーを提供

ポートレット(Portlet)とは、再使用可能な Web モジュールで、Web ベースのコンテンツ、アプリケーション、およびその他

のリソースへのアクセスを提供します。ユーザーの側から見れば、ポートレットはポータル・サイト上のウィンドウで、例え

ばカレンダーやニュース送信など、特定のサービスや情報を提供します。

WebSphere Application Serverでは、JSR168 に準拠したポートレットの稼働をサポートするために、組み込みのポート

レット・コンテナーを稼働できます。

作成したポートレットにブラウザーからアクセスするには、2つの方法があります。

○PortletServingServlet経由の呼出

PortletServingServlet サーブレットによって、ポータル・フレームワークが提供されます。 PortletServingServlet サーブ

レットを使用して、ポートレットを直接URLリクエストによって完全なブラウザー・ページにレンダリングし、各ポートレットを、

そのコンテキスト・ルートとポートレット名で呼び出すことができます。

○JSPによる集約

複数のポートレットを集約したページからポートレットにアクセスするには、JSPの集約タグ・ライブラリーを使用しJSPを

作成する必要があります。

26


26

キャッシングを行うコンポーネント

Caching Proxy– 静的コンテンツのキャッシュ

– 照会応答キャッシュ（動的コンテンツのキャッシュ）

WAS Dynamic Cache （動的キャッシュ）

– サーブレット/JSP・キャッシュ

– コマンド・キャッシュ

– オブジェクト・キャッシュ

外部キャッシュ

– サーブレット・キャッシュを前段のコンポーネントに配置する機能

Proxy Tier Web Server Tier Presentation Tier Business Logic TierLoadBalancerTier

CommandCache

ServletCache

CommandCache

LoadBalancer

CachingProxy

IHS/Plug-in

WebContainer

EJBContainer

ObjectCache

ObjectCache

Servlet Cacheの外部Cache

Caching ProxyのCache

Servlet Cacheの外部Cache

IHSのAFPA Cache

Plug-inESI Cache

クライアント

WASを使用したWebシステムにおいては、Caching Proxy、IHS、Webコンテナー、EJBコンテナーにおいてキャッシュが可

能です。基本的には、よりクライアント側に近いコンポーネントにキャッシュさせることで、レスポンスタイムが向上します。

また、キャッシュをする上で、オリジナルのデータとキャッシュが同一のものでないと意味がありません。オリジナルの

データが更新された時に、一度キャッシュを無効化し、再度更新されたデータを

キャッシュすることを考慮して下さい。

27


27

練習問題

1. WASの基本構成要素の説明について正しいものを選びなさい

A) クライアントからのHTTPリクエストは，Webサーバーで受け付けられ，WebサーバープラグインによってアプリケーションサーバーのHTTPトランスポートチェーンに送られ，Webコンテナ上のServlet/JSPで処理される

B) EJBコンテナ上ではトランザクションサービス・JCAサービス・ネーミングサービスなどが実行される

C) Webコンテナ上で実行されるSIPコンテナは，ネットワークを経由したサーバーの管理機能を提供する

D) アプリケーションサーバーは，データベース上に格納された構成情報にしたがってサービスを提供する

2. ジョブ・マネージャーについて説明した以下の文のから正しいものを一つ選びなさい

A) ジョブ・マネージャーは管理エージェントを経由して複数のBase/Express環境を統合管理することができる

B) ジョブ･マネージャーは，デプロイメント・マネージャーとノード・エージェントから構成されたセルを管理することができない

C) ジョブ・マネージャーは，デプロイメント・マネージャーと同様に複数サーバーのインタラクティブな管理ができる

D) ジョブ・マネージャーでは，全ての管理操作は同期的に行われる。

3. 動的キャッシュを使用したときの効果として正しいもの全て選びなさい

A) ServletやJSPなどWebアプリケーションの応答時間を短縮する

B) サーバーに障害が発生したときの可用性を高める

C) 負荷に応じたサーバーのリソース利用の適化を行う

D) WASやバックエンドシステムの負荷を低減する

28


28

2章 WASの導入と構成

29


29

WASの導入にあたって

その他、インストール前に必要な事項はhttp://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_prepare.htmlに記載されていますので、ご参照下さい。

WAS V7.0の導入にあたっては、前提条件が満たされているか必ず確認してください

– ハードウェアおよびソフトウェア前提条件 (Network Deployment)• http://www-01.ibm.com/software/webservers/appserv/was/network/requirements/にて確認できます

– インストール開始前に確認しておくこと

• インストールに必要な権限をもったユーザーでログインしていること

• TCP/IP ネットワークの設定が正しく行われていること

– IP アドレス、ネットマスク、デフォルト・ゲートウェイ、ホスト名(インストール後の変更はできません)– DNS を使用する場合は名前解決を適切に行えること

• ディスクに十分な空き容量があること

– 製品をインストール・ウィザードを使用してインストールする場合、「インストールの要約」パネルに、選択したフィーチャーおよび製品に基づいて、必要なディスク・スペース量の概算値が表示されます。集中インストール・マネージャー (CIM) を含むすべてのフィーチャーおよび製品をインストールする場合、約3 GB のディスク・スペースが必要です。CIM 以外のすべてのフィーチャーおよび製品をインストールする場合は、約 2 GB のディスク・スペースが必要です。ディスク・スペースの見積もりには、製品、コンポーネント、およびフィーチャーが含まれます。

導入前にハードウェアおよびソフトウェアの前提条件を確認してください。

適切なユーザーか、ネットワークの設定が正しく行われているか、ディスク容量に十分な空きがあるかを確認してくださ

い。製品をインストール・ウィザードを使用してインストールする場合、「インストールの要約」パネルに、選択したフィーチャーおよび製品に基づいて、必要なディスク・スペース量の概算値が表示されます。集中インストール・マネージャー

(CIM) を含むすべてのフィーチャーおよび製品をインストールする場合、約 3 GB のディスク・スペースが必要です。

CIM 以外のすべてのフィーチャーおよび製品をインストールする場合は、約 2 GB のディスク・スペースが必要です。

ディスク・スペースの見積もりには、下記の製品、コンポーネント、およびフィーチャーが含まれます。

・メイン・アプリケーション・サーバー製品のインストール

・プロファイル

・サンプル・アプリケーション

・IBM HTTP Server ・Web server plug-in ・Application Client for WebSphere Application Server ・IBM Update Installer for WebSphere Software

30


30

WAS ND導入の手順（ランチパッドよりウィザードで導入の場合）

1. 製品コンポーネントと衝突するパッケージのアンインストール（IISやApacheなど）

2. CD-ROMを挿入、ランチパッドを起動（コマンドの場合:CDROMドライブ名:¥launchpad)3. WAS本体を導入

「WebSphere Application Server のインストール・ウィザードの起動」をクリックし,ウィザードに従って導入※インストール完了後、プロファイル作成ウィザードを起動するかどうか聞かれますが、ここでは起動せずあとでプロファイル作成ウィザードを使うやり方を記載しています。勿論ここで作成しても構いません。

4. IHSを導入

ランチパッド画面に戻り「IBM HTTP Server のインストール・ウィザードの起動」をクリックしウィザードに従い導入※HTTPデフォルトポートは80番、HTTP管理デフォルトポートは8008番

5. Webサーバー・プラグインを導入

ランチパッド画面に戻り「「Web サーバー・プラグインのインストール・ウィザードの起動」をクリックし、ウィザードに従い導入

6. プロファイルの作成プロファイル作成ウィザードを使用します

「ジョブ・マネージャー」、「管理エージェント」、「セル」、「デプロイメント・マネージャー」、「アプリケーション・サーバー」、「セキュア・プロキシー」、「カスタム」のいずれかのプロファイルを作成

7. ノードの統合（フェデレート）

デプロイメント・マネージャーにアプリケーション・サーバー・ノードを統合

管理コンソールあるいはaddNodeコマンドでノードを統合インストールファイルのチェック・比較、構成ファイルのインベントリー作成が行われる

WAS NDのインストールの手順です。3つのコンポーネント（WAS、IHS、Webサーバープラグイン）をインストールした後、

プロファイルを作成します。必要に応じてノードをデプロイメント・マネージャーに追加します。インストール終了後は、

Snoopやinstallverコマンドを利用しインストールの確認を実施できます。

インストールの詳細については、http://www.ibm.com/developerworks/jp/websphere/library/was/was7_install/も参

照ください。

また、インストールされたプログラム・コンポーネントの情報はvpd.propertiesファイルに記録されます。このファイルは、

既存WebSphere Application Serverの検知などに利用されます。このファイルは、通常、Unixの場合はrootディレクトリー、

Windowsの場合はOSのインストールディレクトリ（C:¥windows ディレクトリーなど)に保管されます。

31


31

インストールの確認

インストールを検査する2つのツール

– インストール検査テストツール (IVTツール)• IVTツールは製品のログ・ファイルをスキャンしてエラーの有無を確認し、インストールした製

品のコア機能を検証します

• ファースト･ステップ･コンソールから「インストール検査」を選択して実行

– installver コマンド行ツール (IVUツール)• インストールされたファイルセットのチェックサムを計算し、製品出荷時の部品表と比較して

検証します

• チェックサムが一致している場合、製品は正しくインストールされています

インストール検査が終了したら管理コンソールにアクセスできることを確認してください

– http://<hostname>:9060/ibm/console

製品が正常にインストールされたことを確認するツールとして、以下の2つのツールが提供されています。

・インストール検査テストツール（IVTツール）

・installverツール（IVUツール）

インストール検査テストツールは、インストール後にランチパッドから実行でき、サーバーを起動させます。製品のログ･

ファイルをスキャンし、エラーの有無をチェックします。正常にインストールが完了している場合には、

「INSTCONFSUCCESS」というメッセージが出力されます。

installverツールは、インストールされたファイルのチェックサムを計算し、製品の部品表と比較してファイルに変更がな

いかをチェックします。

これらのツールを実行した後は、管理コンソールにアクセスできることを確認してください。

32


32

WebSphereプロファイルとは？

インストール・イメージに対して複数の構成が可能

– WAS V7は2つのコンポーネントから構成される

• インストール時にコピーされる製品ファイル。アプリケーション・サーバー・インスタンスにより共通で使用

• カストマイズされた構成ファイル群 (WebSphere構成ファイル、アプリケーション、プロパティなど）→ WebSphereプロファイル

– WAS V7ではプロファイルの作成が必須

利点

– 1つの共通コードから、デプロイメント・マネージャーやアプリケーション・サーバー等の異なるプロファイルを作成可能。

– 修正は単一の製品バイナリーに適用すればよい。

プロファイルの種類

– デプロイメント・マネージャー、ジョブ・マネージャー、管理エージェント、アプリケーション・サーバー、カスタム、セキュア・プロキシー、セルの7種類。

製品バイナリー

+

+

ノードWebSphereプロファイル

WebSphereプロファイル

プロファイルを削除するだけで初期状態に

binの下のファイルやログ、configなどもプロファイルごとの

ディレクトリーの下に存在する

WebSphereプロファイルは、V6から導入された管理の仕組みです。インストールした製品のバイナリーファイルとは別に、

プロファイルごとに、構成ファイルを作成します。このことにより、構成・管理をより柔軟に行うことができるようになりまし

た。

WebSphere Application Server は、大きく分けて二つのコンポーネントから構成されているといえます。

1つは、インストール時にコピーされる、製品のバイナリイメージです。これは読み取り専用であり、システムごとにカスタ

マイズされることはありません。アプリケーション・サーバーインスタンスによって共通に使用されます。もう1つは、カスタ

マイズされた構成ファイルです。構成を保管するファイルや、アプリケーション、各種のプロパティなどであり、これらをま

とめて、WebSphereプロファイルと呼びます。

WAS ではプロファイルの作成が必須となります。すなわち、製品ファイルをインストールしただけでは、動かすことはでき

ません。

WebSphereプロファイルという機能を利用することにより、一つの共通コードから、デプロイメント・マネージャーやアプリ

ケーション・サーバーなどの異なるプロファイルを作成することができます。製品に対する修正は、インストールした1つ

の製品ファイルに適用するだけで良いです。

プロファイルの種類としては、デプロイメント・マネージャー、ジョブ・マネージャー、管理エージェント、アプリケーション・

サーバー、カスタム、セキュア・プロキシー、セルの7種類があります。

プロファイルの便利な点として、例えば、テスト環境などで、構成を初めからやり直したい場合など、プロファイルを削除

するだけで初期状態に戻すことができるということが上げられます。製品のアンインストール、再インストールなどは必

要ありません。

プロファイルごとに、ディレクトリーが作成され、使用するコマンド(binの下のファイル)や、ログ、config等もすべてその中

に存在する形となります。デフォルトでは、<WAS_INSTALL_ROOT>/profiles/<profile_name>/ディレクトリ配下に作成され

ます。

33


33

プロファイルの作成と操作

プロファイルの管理

– プロファイル管理ツール (PMT : Profile Management Tool)• GUIの画面でプロファイルの作成、拡張を行う

– manageprofilesコマンド

• コマンド行のツールで、作成、削除、リストなどの操作を実行する

WASインストーラーで導入

プロファイル管理ツール／manageprofilesで作成

ASプロファイル･テンプレート

WAS製品コード管理プロファイル･テンプレート

カスタム・プロファイル･テンプレート

ASプロファイル AS NA

DMプロファイル DM

カスタム･プロファイル NA

manageprofilesで操作

<WAS_root>/WebSphere/AppServer

ジョブ・マネージャープロファイル

Job Manager

管理エージェントプロファイル

AdminAgent

セキュア・プロキシー・プロファイル･テンプレート

セル・プロファイル･テンプレート

セル・プロファイル

セキュア・プロキシー･プロファイル

AS NADM

PS

プロファイルを管理するためにはGUIの『プロファイル管理ツール（PMT）』とCUIの『manageprofilesコマンド』の二種類の

管理ツールが提供されます。使用目的に応じて使い分けてください。

プロファイル管理ツールは『<WAS_root>/bin/ProfileManagement/pmt.sh(bat)』コマンドで起動します。manageprofilesコ

マンドは『<WAS_root>/bin/manageprofiles.sh(bat)』で呼び出すコマンドラインツールです。以下の引数でプロファイル操

作を行います。

［-create、-delete、-deleteAll、-augment、-unaugment、listProfiles、getName、getPath、-validateRegistry、-

validateAndUpdateRegistry］

manageprofilesコマンドで上記プロファイル作成ウィザードの画面コピーのようにプロファイル･タイプを指定するには-

templatePathで指定します。それぞれのパスは以下の通りです。

・セルプロファイル <WAS_root>/profileTemplates/cell

・管理プロファイル（ジョブ･マネージャー、管理エージェント、デプロイメント・マネージャー）

<WAS_root>/profileTemplates/management –serverType <profile_type>

・ ASプロファイル <WAS_root>/profileTemplates/default

・カスタムプロファイル <WAS_root>/profileTemplates/managed

・セキュア・プロキシープロファイル <WAS_root>/profileTemplates/secureproxy

セルプロファイルはWAS V6.1から追加されたプロファイルで、デプロイメント・マネージャーとアプリケーションサーバー/

ノードエージェントが稼働するプロファイルを作成できます。

管理プロファイルはWAS V7.0から追加されたプロファイルです。WAS NDでは、デプロイメント･マネージャー、ジョブ･マ

ネージャー、管理エージェントを作成することができます。Baseの場合には、デプロイメント・マネージャーとジョブ･マ

ネージャーは作成できません。

カスタム・プロファイルもNDのみで提供されるプロファイルで、アプリケーション・サーバーを含まず、ノード・エージェント

のみを含むノードを作成します。

プロファイルの削除は、プロファイル管理ツールでは実行できず、manageprofilesのコマンドで –delete オプションを使用

してのみ削除することができます。

34


34

プロファイル作成・設定(1)管理セキュリティーの設定

– 管理セキュリティーON/OFFをプロファイル作成時に設定可能（アプリケーションセキュリティーは設定できない）

– ユーザー名とパスワードを設定

• デフォルト設定では統合リポジトリを使用

– プロファイル作成後、管理コンソール、管理コマンドに対するセキュリティーが有効化される

開発テンプレートを使用するサーバーの作成

– アプリケーション・サーバー・プロファイルにのみ選択可能

– 開発環境に適化された設定でサーバーを構成

– 本番での使用は非推奨

ポート番号のアサイン

– 全ポート番号をデフォルト・ポートへリセットするオプションを提供（デフォルトのポート値ボタン）

プロファイル作成後に、ポートの競合を解消するための

updatePorts.antスクリプトも提供

プロファイル管理ツールのオプションです。中にはWAS V6.1から追加・拡張されたものもあります。

プロファイル管理ツールでは、プロファイル作成時に管理セキュリティーの設定を行うオプションがあります。ユーザー名

とパスワードを設定すると、管理セキュリティーが有効化されます。なお、この設定はアプリケーションのセキュリティーと

は分離されているため、アプリケーションのセキュリティーは有効化されません。また、デフォルトの管理セキュリティー

では、ユーザー・レジストリーとしてV6.1から提供された統合リポジトリーが使用されます。

続いて、開発環境向けのプロファイル作成オプションについてです。プロファイル作成時に環境のタイプとして「アプリ

ケーション・サーバー」を選択すると、その後の選択肢に「開発テンプレートを使用するサーバーの作成」チェックボックス

が表示されます。このチェックボックスを選択すると、サーバーの起動時間を速める設定など、開発環境用に適化さ

れた設定を持つサーバーが構成されます。なお、開発環境向けの設定となっているので、本番サーバーへの適用は推

奨されません。

ポート番号のアサインについてのオプションがあります。PMTは同じユーザーがownerで、すでにインストール/構成され

ているWAS のプロファイルが使用しているポート番号を確認し、競合しないポート番号をアサインします。この時、他の

ユーザー名でインストールしたWASは確認対象とはなりませんので、非Root権限でのインストールを行っている場合に

は注意が必要です。アサインしようとしているポートが実際に現在使われていないかのチェックが完了すると、現在使用

されていないポートのみが｢ポートの割り当て｣一覧に表示されます。PMTではさらに「デフォルトのポート値」というボタン

を用意し、簡単に全ポートをデフォルトのポート番号（9060, 9080など）に変更することができます。

また、プロファイル作成後にポートの競合発生がわかった場合のために、ポートの競合を解消するための

updatePorts.antスクリプトも提供されています。

updatePorts.antスクリプトの詳細については、下記 InfoCenter をご参照ください。

「既存プロファイル内のポートの更新」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_updatePorts.html

35


35

プロファイル作成・設定(2)Webサーバー定義の作成

– プロファイル作成時にWebサーバー定義を作成

– サーバータイプ、OS、サーバー名、ホスト名（IPアドレス）、ポート番号、インストール・パスを設定

標準プロファイル作成

– 重複しない値を自動で設定（プロファイル名、ノード名、セル名、ポート番号）

– 管理セキュリティのON・OFFを指定可能

拡張プロファイル作成

– プロファイル作成のオプション設定が可能（管理コンソールの導入、サンプルアプリ導入、プロファイルをデフォルト・プロファイルに設定、など）

Webサーバー定義の作成のオプションがあります。プロファイル作成時に、Webサーバー定義情報を与えることで、

WebSphereプロファイルを作成するのと同時にWebサーバー定義を作ることができます。このステップはスキップして、別

途Webサーバーの定義を行うことも引き続き可能です。

さらに、標準/拡張プロファイル作成のサポートを提供します。標準プロファイル作成を選択すると、プロファイル名、ノー

ド名、セル名、ポート番号などに自動でデフォルトの値をセットし、プロファイルを作成します。拡張プロファイル作成を選

択するとプロファイル作成時のオプションとして上記の各値の他、サンプルアプリケーションのインストール有無、管理コ

ンソールのインストール有無、プロファイルをデフォルト/プロファイルに設定する、などを選択する事が出来ます。管理

コンソールのインストールはプロファイル作成後、wsadminコマンドで別途行うことも可能です。

36


36

サイレント・インストール

インストール・ウィザードの使用時に、グラフィカル・ユーザー・インターフェースを使用せずに、サイレント・モードでの製品インストールが可能

– サイレント・インストールでは、ウィザード・インターフェースを表示する代わりに、ユーザーが提供するファイル（応答ファイル）からユーザーの応答をすべて読み取る

– 製品CDのWASディレクトリまたはマニュアル（インフォセンター）にて、サンプルの応答ファイル

を提供。これを環境にあわせてカスタマイズ。

• ND版のサンプル応答ファイル名： responsefile.nd.txt• ND版の場合はプロファイルを作成して、作動環境を作成する必要あり

実行方法

[ドライブ名]:¥WAS¥install" -options "C:¥temp¥WAS¥myoptionsfile.txt" -silent カスタマイズした応答ファイルを指定

WASではウィザードによるGUIを使用したインストール方法とは別にサイレント・モードでインストールを自動実行できま

す。

サイレント・インストールではあらかじめ設定しておかなければならないパラメーターや設定項目を応答ファイルに記述し

ておき、インストールプログラムはそのファイルの中身を読み取りながらインストールを実行します。

同じ環境の複数サーバーに繰り返しインストールを行いたいときなど便利です。

サイレント・インストールの詳細については、下記 InfoCenter をご参照ください。

「サイレント・インストール」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_runSilent.html

37


37

（参考）サイレント・インストール応答ファイル例アプリケーション・プロファイル作成時の応答ファイル設定例

-OPT allowNonRootSilentInstall="false"-OPT feature=“samplesSelected” → サンプルのインストールの有無-OPT installLocation=“/opt/IBM/WebSphere/AppServer” → インストールディレクトリ-OPT createProfile=“true” →プロファイル作成の有無-OPT profileType=“standAlone“ → 作成するプロファイルのタイプ-OPT silentInstallLicenseAcceptance="true"-OPT traceFormat=ALL-OPT traceLevel=INFO-OPT PROF_cellName= →セル名の指定-OPT PROF_defaultPorts=-OPT PROF_enableAdminSecurity=“false” →管理セキュリティの有効/無効-OPT PROF_hostName= →ホスト名の指定-OPT PROF_isDefault= →デフォルト・プロファイルの指定-OPT PROF_nodeName= →ノード名の指定-OPT PROF_omitAction=-OPT PROF_portsFile= →ポート設定ファイルのファイルパス-OPT PROF_profileName= →プロファイル名の指定-OPT PROF_profilePath=-OPT PROF_serverName= →サーバー名の指定-OPT PROF_startingPort=-OPT PROF_validatePorts=-OPT PROF_webServerCheck= →Webサーバー定義の有無-OPT PROF_webServerHostname=-OPT PROF_webServerInstallPath= -OPT PROF_webServerName= -OPT PROF_webServerOS=-OPT PROF_webServerPluginPath=-OPT PROF_webServerPort= -OPT PROF_webServerType=-OPT PROF_winserviceAccountType=-OPT PROF_winserviceCheck=-OPT PROF_winservicePassword=-OPT PROF_winserviceStartupType=-OPT PROF_winserviceUserName=

-OPT allowNonRootSilentInstall="false"-OPT feature=“samplesSelected” → サンプルのインストールの有無-OPT installLocation=“/opt/IBM/WebSphere/AppServer” → インストールディレクトリ-OPT createProfile=“true” →プロファイル作成の有無-OPT profileType=“standAlone“ → 作成するプロファイルのタイプ-OPT silentInstallLicenseAcceptance="true"-OPT traceFormat=ALL-OPT traceLevel=INFO-OPT PROF_cellName= →セル名の指定-OPT PROF_defaultPorts=-OPT PROF_enableAdminSecurity=“false” →管理セキュリティの有効/無効-OPT PROF_hostName= →ホスト名の指定-OPT PROF_isDefault= →デフォルト・プロファイルの指定-OPT PROF_nodeName= →ノード名の指定-OPT PROF_omitAction=-OPT PROF_portsFile= →ポート設定ファイルのファイルパス-OPT PROF_profileName= →プロファイル名の指定-OPT PROF_profilePath=-OPT PROF_serverName= →サーバー名の指定-OPT PROF_startingPort=-OPT PROF_validatePorts=-OPT PROF_webServerCheck= →Webサーバー定義の有無-OPT PROF_webServerHostname=-OPT PROF_webServerInstallPath= -OPT PROF_webServerName= -OPT PROF_webServerOS=-OPT PROF_webServerPluginPath=-OPT PROF_webServerPort= -OPT PROF_webServerType=-OPT PROF_winserviceAccountType=-OPT PROF_winserviceCheck=-OPT PROF_winservicePassword=-OPT PROF_winserviceStartupType=-OPT PROF_winserviceUserName=

アプリケーション・プロファイル作成時の応答ファイルの例です。

サンプルのインストール、インストールディレクトリ、作成プロファイルの指定、管理セキュリティの有無など、GUIの操作

で必要となる情報と同じ情報を、応答ファイルの指定します。

38


38

WASの導入で問題が発生した場合は？

インストール・ログ・ファイルでエラーがないか調査。インストールおよびプロファイル作成状況は次のログファイルに記載されます

– 「 install_root/logs/log.txt 」ファイル

– 「 install_root/logs/manageprofiles/profile_name_create.log 」ファイル

– 「 profiles_root/logs/install/installconfig.log.gz」ファイル

構成アクションは失敗しました。

ANT スクリプト構成が失敗しました。

構成アクションが成功しました。

ANT スクリプト構成が成功しました。

インストール手順の後で実行される ANT 構成スクリプトのアクティビティーを記録します。（gzipファイル）

install_root/logs/install/installconfig.log.gz

INSTCONFFAIL すべてのプロファイル作成の失敗

INSTCONFSUCCESS プロファイル作成の成功

INSTCONFPARTIALSUCCESS プロファイル作成エラーが発生

しましたが、プロファイルは機能しています。追加情報でエラーを識別します

名前付きのプロファイルの作成中に発生するすべてのイベントをトレースします。

プロファイル作成ウィザードまたは manageprofiles コマンドを使

用した場合に作成されます

install_root/logs/manageprofiles/profile_name_create.log

戻りコード

0 正常

1 失敗

2 部分的な成功

全てのインストールイベントを記録

install_root/logs/install/log.txtインディケーター内容ログ名称

※ インストールの初期にエラーが発生した場合は、システム一時領域の log.txt ファイルを参照 (Windowsでは %TEMP%¥log.txt）インストール・プログラムは、インストールの後に一時領域から logs ディレクトリーにログをコピー

WASの導入で問題が発生した場合には、必ずログ・ファイルを確認します。問題の原因を分析・除去してから、再度導入

手順を実行してください。また、ISMP（InstallShield for multiplatform) がインストール・ウィザードを開始できない場合が

あります。このような場合、インストール・ウィザードの起動に十分なディスク・スペースがないことなどが考えられます。

インストールが失敗し、インストール・ログに情報がない場合は、-log パラメーターを使用して、ISMP プログラムがインス

トール・ウィザードの開始に失敗する原因となるイベントのエントリーを記録することができます。このようなイベントを記

録するための install コマンドの構文は、以下のとおりです。

Install -options fully_qualified_options_response_file_name

-silent

-log # !fully_qualified_log_file_name @ALL

WASの導入のトラブルシューティングの詳細については、下記 InfoCenter をご参照ください。

「インストールのトラブルシューティング」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_trouble.html

39


39

プラグインの導入で問題が発生した場合は？

インストール・ログ・ファイルでエラーがないか調査。インストールおよびプロファイル作成状況は次のログファイルに記載されます

– 「plugins_install_root/logs/install/log.txt」ファイル

– 「plugins_install_root/logs/install/masterConfigurationLog.txt」ファイル

– 「plugins_install_root/logs/install/installGSKit.log」ファイル

– 「plugins_install_root/logs/install/Install<Webserver>Plugin.log」ファイル

– 「plugins_install_root/logs/install/configure_<Webserver>_webserver.log」ファイル

ログファイルのインディケーター

– INSTCONFFAIL すべてのインストールの失敗

– INSTCONFSUCCESS インストールの成功

– INSTCONFPARTIALSUCCESSインストール・エラーが発生しましたが、インストール・システムは使用することができます。追加情報でエラーを識別します

※ インストールの初期にエラーが発生した場合は、ユーザーの一時領域のtemporaryPluginInstallLog.txt ファイルを参照

プラグインの導入で問題が発生した場合にも、必ずログ・ファイルを確認します。

例えば、log.txtに以下のメッセージが出力されている場合は、インストール・イメージの JDK ディレクトリー内にある、正

しい Java 2 SDK を使用していません。

Plugin.Install, com.ibm.ws.install.ni.ismp.actions.

ISMPComponentizedFileRepositoryDeployAction, err,

Component not found: prereq.jdk

このような場合は、log.txt ファイル内の CURRENT_WORKING_DIRECTORY 値および JAVA_INSTALL_PATH 値などを

確認します。

また、JDK ディレクトリーはあるが GSKit ディレクトリーがない場合は、インストールは一部だけ正常に行われ、

INSTCONFPARTIALSUCCESS インディケーターがログに出力されます。このとき、masterConfigurationLog.txt ログ・

ファイルは、99SGSKitInstall.ant スクリプトが実行に失敗したことが表示されます。

このような場合は、手動で GSKit をインストールして、フルインストールを完了します。

インストールの初期にエラーが発生した場合は、ユーザーの一時ディレクトリーで temporaryPluginInstallLog.txt ファイ

ルを探します。

プラグインの導入のトラブルシューティングの詳細については、下記 InfoCenter をご参照ください。

「Web サーバー・プラグインのインストールおよび除去のトラブルシューティング」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tins_troubleplugin.html

40


40

Installation FactoryCustom Install Package (CIP)の作成ツール

– EclipseベースのGUIツール・CLIツール

Custom Install Package (CIP)– Fixの適用、プロファイルの作成や構成、アプリケーションデプロイ、スクリプトの実行などインストール時

に行う作業の全てを含むWASの導入イメージ

– セットアップするマシン台数が多い場合に、1つのインストール・イメージにまとめてそれを適用することで

複数の手順を短縮する事が可能

CIP（カスタマイズ・インストール・パッケージ）の作成方法

1. Installation Factoryの導入（初の1回のみ）

2. WASの保守パッケージを準備

3. GUIモードまたはCLIモードでウィザードを起動し、

ビルド定義を作成

– GUIモード：binディレクトリーにあるifgui.batコマンドで起動

– CLIモード：binディレクトリーにあるifcli.bat コマンドで起動

4. CIPの作成（ビルド定義を作成後に自動生成される）

インストールを行う上で便利なツールとして、WAS V7.0ではInstallation Factory V7.0が同梱されています。Installation

Factoryは製品バイナリ導入、Fixの適用、プロファイルの作成や構成、アプリケーションデプロイ、スクリプトの実行など

インストール時に行う作業の全てを含むカスタマイズ・パッケージ（CIP）を作成するためのツールです。セットアップする

マシン台数が多い場合に、1つのインストール・イメージにまとめてそれを適用することで複数の手順を短縮する事が出

来ます。

Installation FactoryはGUI、CUIツールをそれぞれ提供しています。アウトプットは、ビルド定義ファイルと、Custom Install

Package (CIP)の2つになります。CIPは、特定の保守レベルを導入可能な、WASのインストール・イメージです。ビルド定

義ファイルは、特定のCIPに何を組み込むか、を表すXMLファイルです。既に作成されたビルド定義ファイルを用いれば、

いつでも同じCIPを作成する事が可能です。

CIPは製品バイナリに加えて各種FixPack、ファイル、スクリプトなどを1つのパッケージにまとめているため、このCIPの

みを配布し適用するだけで、複数のサーバーに同じ環境を構築する事が可能です。例えば製品バイナリをインストール

すると同時に複数のFixをあて、独自で開発した運用ガイド・ヘルプファイルを配置するといった一連の動作もCIPに組み

込む事が出来ます。サーバー数十台から成るお客様環境では非常に有用であると言えます。

41


41

集中インストール・マネージャー

DM : デプロイメント・マネージャー

インストール

インストール

インストール

集中インストール・マネージャー・リポジトリー

デプロイメント・マネージャーが、セル内のノードに対して修正モジュール等を一元的にインストール可能な機能

– Centralized Installation Manager => 略してCIM

– ND環境のみでサポートされ、インストールはセル内のノードを選択することも、全てに対して

実施することも可能

• 配布対象のノードをインストール・ターゲットとして構成する

– エージェントは不要、目的のホストに対しPush形式でインストール

– インストール対象

• WAS V7 NDモジュール、WAS V7 RefreshPack/FixPack/iFix、Update Installer• WAS V6.1 RefreshPack/FixPack/iFix(混合セル環境のみ)

セル

インストール・ターゲット

WAS V7ではインストールおよびFix適用作業がより簡単になる機能として、集中インストール・マネージャーが追加され

ました。集中インストール・マネージャーはこれまでWebSphere XDで利用可能でしたが、WAS V7からWASの基本機

能として追加されました。この集中インストール・マネージャーはND環境のみでサポートされ、デプロイメント・マネー

ジャーからセル内のリモートホストにインストールすることが可能になります。インストール対象は、WAS V7 NDモ

ジュール、WAS V7のFix、WAS V7のUpdate Installer、WAS V6.1のFix（V6.1は混合セル環境のみ）になります。イン

ストール時はセル内のノード全てを選択することも、個別にノードを選択することもできます。インストール先ノードにエージェントは不要であり、複数台同時にFixを適用する際などは大変便利な機能になります。

CIMはWAS製品インストールの際のオプションとして、作成することができます。WASインストール時にCIMを導入しな

くても、後からInstallation Factoryを使用して導入することもできます。

42


42

練習問題

4. 製品インストールが正常に行われたかを確認する方法として適切でないものを次の中から1つ選

択してください。

A) プロファイル管理ツールを起動する

B) IVTツールを起動する

C) 管理コンソールにアクセスする

D) installconfig.logを確認する

5. プロファイル管理ツール（PMT）で実行することができない操作を次の中から1つ選択してくださ

い。

A) プロファイルの作成

B) プロファイルの拡張

C) プロファイルの削除

6. 集中インストール･マネージャーに関する以下の説明のうち、正しいものを1つ選んでください。

A) 適用できる製品モジュールおよびFixPackは、WAS V7のみである。

B) リモートのホストにインストールする場合には、インストール･ターゲットとしてホストを設定しなくてはならない。

C) WAS製品インストール時にしか集中インストール・マネージャー・リポジトリーを作成することができない。

D) 集中インストール・マネージャーは、ND環境だけでなく、Base、Express環境でも利用できる。

43


43

3章アプリケーション・アセンブリーとデプロイメント

44


44

アプリケーションのアセンブルとインストール

作成したプログラムはJavaEE (J2EE) アプリケーションにパッケージングしてからアプリケーショ

ン・サーバーにインストールする必要があります。

Rational Application Developer (RAD) やRational Application Developer Assembly and Deploy Features (RAD AD) などのツールがパッケージング機能を提供します。

EJBコンポーネント

WARWAR

JARJAR

EAREAR

JAR:Java ARchive FileWAR:Web ARchive FileEAR:Enterprise ARchive File

WebDD

EJBDDApplication

DD

WASサーバー

Webコンポーネント(Servlet,JSP,HTMLなど)

JavaEEで作成したモジュールを実際にJavaEEアプリケーションとしてWebSphere Application Serverに導入する方法に

は大きく分けて二つのプロセスがあります。ひとつは作成したモジュールのJavaEE形式でのパッケージング、そしてもう

ひとつはパッケージングされたモジュールのインストールです。JSPやServlet、HTMLや画像ファイルなどのWebモジュー

ルはWebARchiveファイル（WAR）形式でパッケージングします。EJBモジュールはJavaARchiveファイル（JAR）形式で

パッケージングします。これらのファイルをEnterpriseARchiveファイル（EAR）形式にまとめます。

これでJavaEEアプリケーションとしてインストールできる形になります。ここまでのプロセスは開発ツールであるRational

Web DeveloperおよびRational Application Developerで行うこともできますし、WebSphere Application Serverに付随の

Rational Application Developer Assembly and Deploy Features (RAD AD)で行うことも可能です。

次のプロセスはEARファイルのインストールです。WebSphere Application Serverではブラウザー形式の管理コンソール

がついています。

この管理コンソールを用いて、EARファイルをWebSphere Application Serverにインストールします。管理コンソールから

「アプリケーション」→「新規アプリケーションのインストール」を選択し、ステップに沿って順に設定していくと容易にイン

ストールすることができます。ステップの後には要約画面が出てきますので内容を確認し問題がなければ保管して構

成情報を反映させます。

45


45

RAD AD (Rational Application Developer Assembly and Deploy Features) の機能

アプリケーションの開発・アセンブル

– Eclipse 3.4 Web Tools Platform (WTP) ベース

– *.war, *.jar, *.ear の開発・作成

– JavaEE & WebSphere拡張デプロイメント・

ディスクリプター（配置記述子）の編集

– JPA、EJB3.0の開発サポート

Automation Tool– Jython エディターおよびソース・デバッガー

※RAD AD はWASテスト環境を含みませんので、ご注意ください。

WASではJava EE を拡張した機能がサポートされており、RAD ADでは設定画面が提供されています。これら

の機能は追加の構成情報として次のデプロイメント・ディスクリプタ・ファイルに記載されます。Webモジュール、EJBモジュール、アプリケーションクライアント、Webサービスなどの追加機能用にファイルが

提供されています。IBMバインディング・ファイル(ibm-xxx-bnd.xml)IBM拡張・ファイル（ibm-xxx-ext.xml)

デプロイメント・テスト

– WebSphere Rapid Deployment (WRD)• WAS V7.0 ランタイムへのデプロイメント

– Enhanced EAR

• データソースなどのリソース定義まで含めたEARファイルの作成

Windows、Linuxをサポート

RAD Assembly and Deploy Features (RAD AD) は、過去のWAS V6.1 に同梱されていたApplication Server Toolkit (AST) と同様の位置づけにあるツールです。RAD AD はWASライセンスの一部として提供されます。

RAD AD はオープンソースのEclipse WTP (Web Tools Platform) として提供されているJava EE アプリケーション開

発機能をベースとし、その上に、WebSphere Application Server V7.0 サーバーに対する管理スクリプトの作成、デ

バッグおよびJava EE アプリケーションをWAS V7.0 へとデプロイするために必要なデプロイメント定義 (IBM拡張) を構

成する機能を含みます。JPA、EJB3.0を含むWAS V7.0 上で動作するJava EE 5 アプリケーションは、アノテーションを

使用することでPOJOとして開発できるため、RAD ADのみで開発可能です。

Automation Toolでは、WAS のスクリプト・ベース・管理ツールである wsadmin 用のJythonを開発、テスト、デバッグする

ことができます。このことにより、J2EEアプリケーション開発から、アプリケーション・アーカイブのアセンブル、配置、実行

までを、WebSphere Application Server V7.0 と同梱の RAD AD だけで行うことも可能です。注意点としては、RAD ADは

WASテスト環境を含んでおりません。アプリケーションのテスト・実行のためには別途WASが必要となります。

Enhanced EARは、アプリケーション特有の情報（リソース定義など）をEARファイルに含められる機能です。これによりア

プリケーション・サーバーインストール時の、デプロイ作業が軽減されます。RAD ADではEnhancedEARをサポートするた

めにこれらのリソース情報を定義するページが提供されています。

Enhanced EARでは、JDBCプロバイダー、データ・ソース、JMSリソース、リソース・アダプター、置換変数（WebSphere変

数）共用ライブラリー、クラス・ローダー・ポリシー、JAAS認証別名、仮想ホスト情報の設定を追加できます。アプリケー

ション・レベルのリソース情報はMETA－INF/ibmconfigディレクトリーの下のdeployment.xmlに構成されます。

WASではJava EEを拡張した機能がサポートされており、RAD ADでは設定画面が提供されています。これらの機能は

追加の構成情報としてWebSphere拡張機能用のデプロイメント記述子ファイルに記載されます。IBMバインディングファ

イル(ibm-xxx-bnd.xml)、IBM拡張ファイル（ibm-xxx-ext.xml)以外には、EJB CMP エンティティーBeanのマッピングに使

用されるibm-ejb-access-bean.xmlなどもあります。

46


46

モジュールへのセキュリティー役割（ロール）マッピング

Java EEセキュリティー役割（ロール）

– Web/EJBのメソッドのようなオペレーションへのアクセス認可対象をグループ化したもの

なぜセキュリティー役割（ロール）が必要か？

Servlet 1

Servlet 2Aさん

Bさん

Cさん

個々のユーザー単位でアプリケーションに対するアクセス認可情報を設定していては人事異動の際など膨大なワークとなる

勤務記録承認

交通費承認

契約書承認

制約

人事部門の役割

各部門長の役割

営業部門長の役割

役割

A1/A2/A3

B1/B2

C1/C2アクセス可能なパターン

(役割マッピング）役割という一種のグループを決めておくことでメンテナンスが楽になる

EJB 1

EJB 2

設定

– アプリケーションのセキュリティー役割の定義

• アプリケーション開発時に RAD AD （あるいはRAD) を使用

– ユーザー/グループのセキュリティー役割へマッピング

• アプリケーション開発時に RAD AD （あるいはRAD) を使用

• WAS管理コンソールから設定（アプリケーションのインストール時、あるいはインストール後）

Servlet 1

Servlet 2

EJB 1

EJB 2

WebSphereでは、Java EEセキュリティに基づき、モジュールにセキュリティー役割（ロール）を割り当てる機能を提供しま

す。

セキュリティー・ロールとはモジュールに使用権限を与える単位を個人ではなくグループで与えるといったものと考えて

いただいてもよいでしょう。こうしておけば上記図の例のように人事異動の際にも権限の変更作業を削減することができ

ます。

セキュリティー役割はアプリケーション開発時に定義します。そのセキュリティー役割とレジストリー上のユーザー/グ

ループとのマッピングは、通常アプリケーションインストール時に実施しますが、アプリケーション開発時に定義、アプリ

ケーションインストール後にも実施することができます。

Webアプリケーションの場合、「セキュリティー制約」を作成し、セキュリティー・ロールとマッピングを行います。EJBアプリ

ケーションの場合には、「メソッド許可」を作成し、1つ以上のセキュリティー・ロールとマップします。

47


47

リソース定義、WebSphere環境変数の有効範囲（スコープ）

リソース定義、WebSphere環境変数設定が利用できる範囲を指定

セル

クラスター

ノード

サーバー

リソース：JDBCプロバイダー定義画面 WebSphere環境変数定義画面

セル、クラスター、ノード、サーバーの中から指定

有効範囲を指定有効範囲を指定

JDBCプロバイダーなどのリソース設定や、WebSphere環境変数（WASセルの管理範囲で定義・利用できる環境変数）で

は、有効範囲（スコープ）を指定します。例えばセル･レベルのスコープでリソースを定義するとそのリソースは全てのプ

ロセスから使用可能ですが、ノード･レベルでリソースを定義するとそのリソースは定義したノード以外のノードでは使用

できないことになります。『有効範囲』はセル、クラスター、ノード、サーバーが指定でき、複数定義されている場合にはよ

り細かい有効範囲での設定でオーバーライドされます。

48


48

プラグイン構成ファイルの生成・伝搬

Webサーバーは、Web サーバー・プラグインを使用して、アプリケーション・サーバーとのHTTP(S) 接続を確立、ルーティング情報を保存

ルーティングに影響する構成情報に変更があった場合、プラグイン構成ファイル plugin-cfg.xml を生成し、伝搬する必要がある（デフォルトでは自動で再生成）

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

– クラスターメンバーの追加

– 新しい仮想ホストの追加

– etc

プラグイン構成ファイル内の要素でマッピング情報を確認できる

– ServerCluster同じタイプの要求を実行するように構成されるサーバーのグループ

– Serverリクエストの処理に関連するアプリケーション・サーバー

– UriGroupHTTPリクエスト行で指定されるURIのグループ

– VirtualHostHTTPホストヘッダーで指定され、WASがリクエストを実行するか決定する仮想マシン名

管理コンソールでのplugin-cfg.xml ファイルの表示

アプリケーション・サーバーは、Webサーバーと連携して、Webアプリケーションからの動的コンテンツに対するリクエスト

を処理します。Webサーバーには、リクエストの割り振りやアプリケーション・サーバーのマッピングを行うためのWeb

サーバー・プラグインが必要となります。Webサーバー・プラグインは、プラグイン構成ファイル plugin-cfg.xml を参照して、

ルーティングを行います。

アプリケーションを新たにデプロイした場合や、リクエストを処理するサーバー・メンバーが追加された場合には、プラグ

イン構成ファイルを再生成し、Webサーバーに伝搬する必要があります。デフォルトでは自動で再生成し、伝搬されるよ

うになっています。

プラグイン構成ファイルは、管理コンソールで表示、編集することが可能です。管理コンソール左側のナビゲーション

バーから「サーバー」‐「webサーバー」‐「サーバー名」をクリックし、「プラグイン・プロパティー」をクリックします。プラグイ

ン構成ファイル名が表示されるのでplugin-cfg.xmlの横の「表示」をクリックするとプラグイン構成ファイルが表示されます。

新たにアプリケーション・サーバーが追加された場合は、Server 要素が追加され、アプリケーションが追加された場合に

は、アプリケーションのコンテキストルートと同じName属性を持つ Uri 要素が追加されます。

Web サーバー・プラグイン構成ファイルの詳細については、下記 InfoCenter をご参照ください。

「plugin-cfg.xml」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rwsv_plugincfg.html

49


49

ネーミングサービス（Naming Service）

ネーミングサービスとは

– オブジェクトと名前を関連づけ、その名前をキーとしてオブジェクトを検索するためのサービス

ネームスペース（Name Space/名前空間）

– ネーミングサービスにおいて、オブジェクトが格納されている空間

– ネーミングサービスから検索されるオブジェクトはネームスペースに階層的に格納される

Java EEにおけるネーミング・サービス

– アプリケーションコードから外部リソースへの統一されたアクセス環境を提供

– JNDI（Java Naming and Directory Interface）を使用する

DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/DataSource1");

データソースを使用するアプリケーションのコードの一部Naming Service

DataSource

JNDI名: jdbc/Sample “Sample”Database

ディプロイメントディスクリプターでリソース参照「jdbc/DataSoruce1」を作成し、これを実際のJNDI名「jdbc/Sample」にバインドする

ネーミング・サービスとはオブジェクトと名前を関連づけ、その名前とキーとしてオブジェクトを検索するためのサービス

です。ネーミング・サービスにおいて、オブジェクトが格納されている空間をネーム・スペース（名前空間）といいます。

Java EEにおけるネーミング・サービスは、JNDI（Java Naming and Directory Interface）を使用して、アプリケーション・

コードから外部リソースへの統一されたアクセス環境を提供しています。

アプリケーションには、参照（リソース参照、EJB参照、UserTransaction参照）を定義することができ、これを実際のJNDI

名にバインディングすることができます。

・「参照」の使用

JNDIクライアントにおいてlookup を行う際は、lookupするオブジェクトの名前の記述フォーマットとして[ java:comp/env/ ]

コンテキストを先頭につけた形とすることが原則です。デプロイ時に、「参照」を実際のJNDI名にバインドします。

・「参照」の例

EJB参照：java:comp/env/ejb/…

リソース参照（JDBC DataSourceへの参照）：java:comp/env/jdbc/.

50


50

（参考）ネーミング・サービス詳細

構成済み名前バインディング

– 以下の名前空間バインディングを管理者が定義可能

• EJB : セル内の一部のサーバーにインストールされているEJBホーム

• CORBA : CosNamingネーム・サーバーから使用可能なCORBAオブジェクト

• 間接 : JNDIによりアクセス可能なWASネーム・スペースでバインドされているオブジェクト

• ストリング : ストリング定義

名前空間の論理ビュー

– セル全体の名前空間を統合した論理的ビュー

– 以下の4つの名前空間区画で構成される

• システム名前空間区画

• サーバー・ルート区画

• セル永続区画

• ノード永続区画

構成済み名前バインディング

WASでは、名前空間バインディングを管理者が定義することができます。

例えば、セル外の既存アプリケーションから、そのアプリケーションの変更なく、セル内のJNDIで定義されているリソース

へのアクセスするときなどに使用できます。

構成済み名前バインディングの詳細については、下記 InfoCenter をご参照ください。

「構成済み名前バインディング」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cnam_configured_bindings.html

名前空間の論理ビュー

セル全体の名前空間は、セル内の全てのサーバー間で統合されています。各サーバープロセスには、ネームサーバー

があります。全てのネーム・サーバーは、セル・名前空間の論理ビューを提供します。

名前空間には、4つの名前空間区画があり、それぞれがリンクして構成されています。

EJBホームおよびリソースなどのシステムにバインドされた定義は、サーバー・ルート区画にバインドされます。CORBA

や間接名前参照などの構成バインディング定義は、セル永続区画やノード永続区画にバインドされます。

名前空間の論理ビューの詳細については、下記 InfoCenter をご参照ください。

「名前空間の論理ビュー」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cnam_name_space_partitions.html

51


51

ネームスペースとデータソース

nodeagent

dmgrserver1 server2

Bootstrap Port 2809 98099810 9811

物理ノード(ホスト名: gonta)

論理ノード(ノード名: sample1Node)

論理ノード(ノード名: sampleManager)

Deployment Manager (dmgr) は同じ物理ノードにあっても他のプロセスとは別論理ノード扱いになる。

DS1 DS1ノードレベル (sampleNode)

サーバーレベル (server1) DS1

DS1DS1DS1

DS1

セルレベル

ノードレベル(sampleManager)

データソース「DS1」を定義するJDBCプロバイダーの有効範囲設定

プロセス名

クラスターレベル (ClusterA) DS1 DS1

ClusterA

プロセスごとにネームスペースを持つ

有効範囲の選択と、作成されるデータソースの関係を図にしたものです。

管理コンソールで、「リソース > JDBCプロバイダー」を作成するときに指定する有効範囲(セル・ノード・クラスター・サー

バー)によって、データソースが登録されるネームスペースのプロセスが異なります。

データソース「DS1」を定義するJDBCプロバイダーの有効範囲が

「セルレベル」のときDS1はserver1, server2, dmgrのネームスペースに登録される

「ノードレベル(gontaManager)」のときDS1はdmgrのネームスペースに登録される

「ノードレベル(gontaNode)」のときDS1はserver1, server2のネームスペースに登録される

「クラスターレベル（ClusterA)」のときDS1はserver1、server2のネームスペースに登録される

「サーバーレベル (server1)」のときDS1はserver1のネームスペースに登録される

また、JDBCプロバイダーの作成におけるデフォルトの有効範囲はDMのノードになっているので注意が必要となります。

セル全体で同じJDBC Provider定義を利用するが、サーバー毎に異なるデータソース定義を別にしたい場合は、データ・

ソースの有効範囲をサーバー・レベルに設定します。

セル上の全サーバーで同一のデータ・ソース定義を利用する場合は、そのデータ・ソース、JDBCプロバイダー設定の有

効範囲をセル・レベルで定義します。また、この場合、各ノード毎に、データベース・ドライバー・ファイルの場所が異なっ

ているようなときは、WebSphere環境変数のデータベース・ドライバー・ファイルの配置場所を指定している変数の有効

範囲をノード毎に設定することにより、ノード毎の差異を保守しやすくすることができます。

52


52

J2C:J2EE Connector ArchitectureJ2Cの目的

– J2EE1.3～の構成要素

– EIS接続のための統一インターフェイス

– 接続先エンタープライズシステムの違いを吸収し、同一の手法でアクセスを実現

リソース・アダプター(RA:Resource Adapter)– J2C接続のキー・コンポーネント

– RAR（Resource Adapter Archive)ファイルの形態で提供

WAS側の設定

– J2Cリソース・アダプター

– J2C接続ファクトリー

– J2Cアクティベーション・スペック

J2CとはCICSやIMSといったいわゆるEnterprise Information Systemに接続するための統一化されたインターフェイスに

なります。J2EE1.3からサポートされています。

J2Cがあることにより、接続先のEISが何であろうと意識せずに統一した手法（API）を使ってアクセスすることが可能です。

J2Cを利用するためには接続先のEISに対応したリソースアダプター(ランタイム）が必要です。これはRARファイルの形

でEISから提供されています。これをJ2EEサーバーに組み込んで使用します。

WASでは、J2Cがサポートできるように、J2Cリソース・アダプター、J2C接続ファクトリー、J2Cアクティベーションスペック

の定義ができます。J2Cリソース・アダプターではRARファイルをインストールします。J2C接続ファクトリーでは、JNDI名、

有効範囲（スコープ）、コンポーネント管理認証別名、XA リカバリーの認証エイリアスなどを設定します。

53


53

Default Messaging Providerの設定

Default Messaging Provider– アプリケーション・サーバー上で稼働するメッ

セージング・エンジンへのアクセスを提供

– JMS 1.1をサポート

主な設定手順

1. サービス統合バスの作成

2. サービス統合バスにバス・メンバー（アプリケーション・サーバーあるいはクラスター）を追加

3. サービス統合バス上に、宛先（キューあるいはトピック）を定義

4. Default Messaging Providerを構成し、JMSリソース（接続ファクトリー、宛先（キュー、トピック）、アクティベーション・スペックなど）を定義

JMSリソース：キュー定義画面

有効範囲

JMSプロバイダー

名前

JNDI名

バス名

（バス上の）キュー名

デリバリー・モード

存続時間

優先順位

Default Messaging Provider（デフォルト・メッセージング・プロバイダー）は、JMS1.1をサポートし、アプリケーション・サー

バー上で稼働するメッセージング・エンジンへのアクセスを提供します。JMS 1.1をサポートします。

サービス統合バス(SIBus)を構成した後、接続ファクトリー、宛先（キュー、トピック）、アクティベーション・スペックなどの

JMSリソース定義を行います。

例えば、JMSリソースのキュー定義では、有効範囲、JMSプロバイダー、名前、JNDI名、バス名、（バス上の）キュー名、

デリバリー・モード、存続時間、優先順位を設定します。

54


54

システム管理ツール

WASでは以下のシステム管理ツールを提供– 管理コンソール：ブラウザーベースのGUIシステム管理

– wsadmin ：スクリプト言語でシステム管理(管理コンソールと同等機能を保持)– コマンド：一般的に使用頻度の高い機能のみ

– JMXプログラミング：独自の管理機能を開発可能

構成レポジトリー

DM

XML構成ファイル

アプリケーション

Webコンテナーembedded http

adminconsole

管理サービス / JMX

HTTP (9060)

管理コンソール

wsadminSOAP (8880)or RMI (9100)

ランタイム･サービス

オペレーション変更オペレーション変更

構成

変更

構成

変更

User application

ノード

JMXプログラミング

SOAP (8880)

or RMI (9100)

WASでは以下の４つのシステム管理ツールを提供しています。

・管理コンソール

－システム管理機能を提供するグラフィカル・インターフェース

－実体はエンタープライズ・アプリケーションでデプロイメント・マネージャー(DM)上で稼動

－ブラウザーからのアクセスが可能でリモート環境から構成管理を行いたい場合に便利

・wsadmin

－スクリプト言語で管理操作を実行

－管理コンソールで可能な処理を全てカバー

－シェル化して運用を自動化したい場合に有用

－通信プロトコルはSOAPかRMI（デフォルトではSOAPが使用される）

・コマンド

－アプリケーション・サーバーの起動/停止、バックアップ/リストアなど、使用頻度の高い特定の機能を提供

－特化した機能のみ使用したい場合に便利

・JMXプログラミング

－Javaの標準であるシステム管理API(JMX)を使用して独自の管理機能を開発可能

55


55

システム管理ツール (wsadmin)

wsadmin

AdminControl

AdminConfig

AdminApp

Help

構成データの操作(例) DataSourceの作成

WASプロセス内で稼動するMBeanの操作(例) アプリケーション･サーバーの始動/停止

稼動中アプリケーションリストの取得

エンタープライズ･アプリケーションの操作(例) アプリケーションのデプロイ・更新

管理コマンドの実行(例) アプリケーション・サーバーの作成

ヘルプ、MBean情報の表示

# wsadminwsadmin> $AdminApp list# wsadminwsadmin> $AdminApp list

インタラクティブ･モード

# wsadmin –c “$AdminApp list”# wsadmin –c “$AdminApp list”

コマンド実行

# wsadmin –lang jython -f list.py# wsadmin –lang jython -f list.py

スクリプト実行

<管理オブジェクト> <コマンド> （<コマンド･パラメーター>）<管理オブジェクト> <コマンド> （<コマンド･パラメーター>）基本コマンドシンタックス

構成情報に対する操作

稼働オブジェクトに対する操作

AdminTask

wsadminはV5から導入された管理用スクリプト･インターフェースです。wsadminはJakartaのBSF（Bean Scripting

Framework）というフレームワークに準拠しています。BSFではNetREXXやJava Scriptなどもサポートしていますが、WAS

でテストされサンプルが提供されるなど正式サポート対象のスクリプト言語は「JACL」および「Jython」の2つです。

WASの構成可能なオブジェクトは全てJMXのMBean (Management Bean)と関連付けられています。MBeanはJMX APIを

使用して管理するユーザーのための属性のgetter、setterメソッドやstart、stopメソッドなどを持ちます。管理コンソール

もwsadminもいずれもこのMBeanを操作してWASの管理を行います。

wsadminコマンドの基本シンタックスは、上記のように管理オブジェクトを指定し、その管理オブジェクトに対して実行でき

るコマンドに必要に応じてパラメーターを指定します。管理オブジェクトは管理対象のMBeanをカテゴライズしたもので、

構成データの操作を行う『AdminConfig』、エンタープライズ･アプリケーション関連操作をまとめた『AdminApp』、V6で追

加された管理コマンドを実行するための『AdminTask』、スタート/ストップなどオペレーション操作『AdminControl』、ヘル

プおよびMBean情報の表示を行う『Help』の計5種類があります。

コマンドはwsadminのインタラクティブモードでの実行、-cオプションによるコマンドモードでの実行、-fでスクリプトファイ

ルを呼び出すスクリプトモードでの実行がそれぞれ可能です。また、-langオプションで、使用するスクリプト言語の指定

をします。

56


56

(参考) wsadmin スクリプト例

トレースの設定

– Jaclスクリプト例

– Jythonスクリプト例

set server [$AdminConfig getid /Cell:mycell/Node:mynode/Server:server1/] ←構成対象のサーバーの特定set tc [$AdminConfig list TraceService $server] ←トレースサービスの特定$AdminConfig modify $tc {{startupTraceSpecification com.ibm.websphere.management.*=all=enabled}}

←トレース詳細レベルの変更$AdminConfig save ←構成変更内容の保管

set server [$AdminConfig getid /Cell:mycell/Node:mynode/Server:server1/] ←構成対象のサーバーの特定set tc [$AdminConfig list TraceService $server] ←トレースサービスの特定$AdminConfig modify $tc {{startupTraceSpecification com.ibm.websphere.management.*=all=enabled}}

←トレース詳細レベルの変更$AdminConfig save ←構成変更内容の保管

server = AdminConfig.getid('/Cell:mycell/Node:mynode/Server:server1/') ←構成対象のサーバーの特定print servertc = AdminConfig.list('TraceService', server) ←トレースサービスの特定print tcAdminConfig.modify(tc, [['startupTraceSpecification', 'com.ibm.websphere.management.*=all=enabled']]) ←トレース詳細レベルの変更AdminConfig.save() ←構成変更内容の保管

server = AdminConfig.getid('/Cell:mycell/Node:mynode/Server:server1/') ←構成対象のサーバーの特定print servertc = AdminConfig.list('TraceService', server) ←トレースサービスの特定print tcAdminConfig.modify(tc, [['startupTraceSpecification', 'com.ibm.websphere.management.*=all=enabled']]) ←トレース詳細レベルの変更AdminConfig.save() ←構成変更内容の保管

57


57

練習問題

7. 特定のグループのメンバーだけにサーブレットの実行を許可したい場合の手順として正しいものは以下のどれでしょうか

A) Java EEセキュリティ制約とセキュリティー役割（ロール）を定義し，制約を役割にマップする

B) リソース定義の有効範囲をグループに制限する

C) プラグイン構成ファイルにUriGourpを定義して，属性として実行を許可するグループを指定する

D) ネーミングサービスに，サーブレットの実行を許可するユーザーの名前を登録する

8. 以下のプラグイン構成ファイル（plugin-cfg.xml）の説明で正しいものはどれですか？

A) プラグイン構成ファイルはEJBのWLMのために利用される

B) プラグイン構成ファイルは管理者がXMLエディタなどで作成する

C) サーバーのグループを定義するServetClusterは子要素としてServerを持つ

D) VirtualHost要素は，WASが仮想化環境で実行されていることを意味する

9. wsadmin管理スクリプトにおいて，管理コマンドによりアプリケーションサーバーを追加する際に使用されるオブジェクトは次のどれですか？

A) HelpB) AdminAppC) AdminTaskD) AdminScriptE) AdminControl

58


58

4章セキュリティー

59


59

WebSphereセキュリティー

WebSphereで提供されるセキュリティーは、階層構造の上に成り立っています。

・OS、ネットワークレベル

ファイルやプログラムの実行権限やネットワークの暗号化(SSL)などのセキュリティー機能。

・JVM

JVMで提供されるセキュリティー機能

・Java2セキュリティー

スレッド、ソケット、ファイルなどのJava2レベルで提供されるシステムリソースへのアクセス制御。WAS自体Javaプ

ログラムなので、Java2のセキュリティー制限下で動作します。

・CORBA Security

Java EEは分散環境を前提にしており、分散オブジェクト間のトランスポート、メッセージ層のセキュリティーは

CORBA/CSIv2で提供されるセキュリティー機能を前提にしています。

・Java EE Security API

WASのセキュリティー機能はJAASなどのJava EE APIをベースにしています。

ポリシー、ロール（役割）ベースのWASセキュリティー機能はこれらのセキュリティー機能の上で動作しています。

・WebSphereセキュリティー

WebリソースやEJBにアクセスするために、ポリシーやサービスを提供します。通常、WASのセキュリティーと言っ

た場合、この層を表します。

WASの設定でグローバル・セキュリティーをオンにすることで、セキュリティー・ドメイン全体で有効なセキュリ

ティーを設定できます。

WebSphereセキュリティー・サービスは各WebSphereプロセス（デプロイメント・マネージャー、ノード・エージェント、アプリ

ケーション・サーバー）上で稼働します。

60


60

管理セキュリティー

管理セキュリティー

– WASシステムの管理をセキュアーにするための機能

管理セキュリティーの特徴

– 統合リポジトリーを使用することにより簡単にユーザ・レジストリーを構築できる

– WAS管理のみセキュアーにできる

– ウィザードにより簡単に構成できる

– セキュリティー構成を確認できる

– WAS導入時に簡単に構成できる

管理セキュリティーをONにすると

– 管理コンソールログイン時にユーザーID、パスワード認証が必要

– wsadminコマンド実行時にユーザーID、パスワード認証が必要

– WAS（DM、NAを含む）停止時にユーザーIDとパスワードが必要

– コンポーネント間の通信が自動的にSSL化

– LTPAを使用して認証を行う

プロファイル作成時/WAS導入時、あるいはプロファイル作成後に設定が可能

管理セキュリティーはWASの管理をセキュアーにするための機能です。管理セキュリティーが設定されるとWAS管理

ツールを使用するのにユーザー認証が必要となります。管理セキュリティーは、アプリケーション・セキュリティーやJava

2 セキュリティーを使用するための前提機能となっています。

管理セキュリティーには以下の様な特徴があります。

・統合リポジトリーを使用されることによって、LDAPサーバーがなくてもユーザー・リポジトリーを簡単に作成することが

可能です。

・アプリケーション・セキュリティーと分離されたため、WASの管理のみをセキュアーにすることが可能です。ただし、アプ

リケーション・セキュリティーを使用する場合には管理セキュリティーを設定する必要があります。

・セキュリティー構成ウィザードを使用することにより、低限の情報を順番に入力するだけで簡単に設定することが可

能です。

・セキュリティー構成報告書により、現在のセキュリティー設定情報を一覧として表示することが可能です。

・管理セキュリティーはWAS導入時に設定可能で、初めからセキュアーな環境を構築可能です。（導入後の設定変更も

可能です。）

・統合リポジトリーを使用する場合には、LDAPサーバーは必須ではありません。

・サービス統合バスへのアクセス保護を提供するバス･セキュリティーも管理セキュリティーが有効である必要がありま

す。

61


61

管理ロール8つの管理ロールでWAS管理機能の実行権限を定義

– モニター

• WASの構成およびランタイム状態を見るだけの権限

– オペレーター

• モニターに与えられる権限＋アプリケーションの開始/停止などランタイム状態を変更する権限（構成変更はできない）

– コンフィギュレーター

• モニターに与えられる権限＋WASの構成を変更する権限（ランタイム状況は変更できない）

– 管理者

• コンフィギュレーター、オペレーターに与えられる権限＋サーバー・パスワード、LTPAパスワード、鍵などセキュリティ設定を変更する権限

– ISC 管理

• 管理コンソール内のみユーザーとグループを管理する権限

– セキュリティー・マネージャーの管理

• ユーザーを管理ロールにマップする権限

– デプロイヤー

• アプリケーションに対し、構成とランタイム操作が可能（ノードやサーバーなどに対する操作はできない）

– 監査員

• セキュリティー監査の構成を表示および変更する権限（モニター権限のみ含み、セキュリティー構成の変更はできない）

WAS V7.0 には、モニター、オペレーター、コンフィギュレーター、管理者、ISC管理、セキュリティー･マネージャーの管

理、デプロイヤー、監査員の8 種類の管理ロールがあり、それぞれの管理ロールによってWASの管理機能に対する実

行権限が定義されています。

モニターは、も権限のない管理ロールです。WASに関する構成やランタイム状態を見るだけの権限があり、構成変更

などの操作は一切することができません。

オペレーターには、モニターに与えられる権限がある上に、WASのサービス開始/停止などといったランタイム状態を変

更する権限があります。

コンフィギュレーターには、モニターに与えられる権限がある上に、WASに関する構成を変更する権限があります。

管理者は、も権限のある管理ロールです。コンフィギュレーター、オペレーター、モニターに与えられている権限がある上に、サーバー・パスワード、LTPAパスワード、鍵などといった重要なデータへアクセスする権限があります。

ISC管理は、管理コンソール内のみユーザーとグループを管理する権限があります。

セキュリティー･マネージャーの管理は、ロールは管理セキュリティーとアプリケーション管理をわけるために登場しまし

た。このロールを与えられたユーザーだけが管理ロールにユーザーをマップできます。

デプロイヤーは、コンフィギュレーターとオペレーター両方の一部の権限をもった管理ロールです。このロールはアプリ

ケーションに対する構成とランタイム操作が可能です。他のリソース、たとえばノードやサーバーなどを操作する権限は

デプロイヤーにはありません。

監査員はV7.0 で追加された新しい管理ロールです。セキュリティー監査機能を使用する場合には、この監査員ロール

が必要となります。

62


62

統合リポジトリー

統合機能は、Virtual Member Manager (VMM) コンポーネントによって提供される

以下の管理ユーティリティによりユーザーとグループを管理

– 管理コンソール、コマンドライン・ユーティリティ、公開されたAPI

WASのセキュリティーと統合

– ユーザー・リポジトリーの新しいオプションを提供

– JAASフレームワークとともに認証をサポート

– JACC拡張プロバイダーとともにアクセス制御をサポート

ユーザー・レジストリーとして、同時に複数のリポジトリーを使用可能

– ファイルベース、LDAP、データベース、カスタム

論理的な単一リポジトリー・ビューを提供

– ユーザーとグループ管理のAPIとスキーマを提供

デフォルトでは、ファイルベースのユーザー・リポジトリーを使用

– ファイルベース・リポジトリー

• WASの構成リポジトリー内にファイルとして管理– <PROFILE_ROOT>/config/cells/<cell_name>/fileRegistry.xml

• WASの構成情報と同様にDMから各ノードに同期で配布

• ユーザー／グループの管理はWASの管理コンソールから実施

統合リポジトリーは、WAS V6.1からの機能で認証を行うためのユーザー・リポジトリーです。複数のユーザー・リポジト

リーを論理的に１つのユーザー・リポジトリーとして使用することが可能になります。統合機能は、VMM(Virtual Member

Manager)というコンポーネントによって提供されます。

統合リポジトリーでは、複数のリポジトリーを同時に使用しながら、リポジトリーに依存しないプログラム/インターフェー

スを提供し、論理的な単一リポジトリーのビューを提供します。統合リポジトリーでは、以下の４つのリポジトリーを利用

できます。

・ファイルベース

・ LDAP（またはLDAPのサブツリー）

・データベース

・カスタム（拡張プログラミングによってリレーショナル・データベース、フラット・ファイルのデータを取り込めるようにした

もの）

デフォルトでは、ファイルベース・リポジトリーがユーザー・リポジトリーとして設定されています。

ファイルベース・リポジトリーは、ユーザー情報をローカルのファイルに保存する機能です。このファイルは、WASの構成

リポジトリー内に作成され、他のWAS構成情報と同じ扱いを受けます。管理コンソールから登録された内容は、デプロイ

メント・マネージャー内の構成リポジトリー内に登録され、同期を実行すると各ノードに配布されます。

ファイルベース・リポジトリーの情報は、構成リポジトリー内の以下のファイルに登録されます。

<PROFILE_ROOT>/config/cells/<cell_name>/fileRegistry.xml

上記ファイルに登録される内容は、ユーザー情報とグループ情報になります。

ユーザー／グループ情報の管理は、管理コンソールやwsadminコマンドで行います。大量ユーザー登録や定期更新の

機能はないので、大量のユーザー管理を行うのにはあまり向いていません。

63


63

統合リポジトリー: アーキテクチャー概要

Application wsadmin

Local OS

CUR VMM

LDAP

User RegistriesLDAP DBFile Custom

Adaptor Adaptor Adaptor Adaptor

Authentication(JAAS)

Administrative Console

VMMRuntime

APIs

VMMConfiguration

APIs

Administrative Command Framework

Repository SPI Property Ext SPI

Adaptor

DB

Application ServerSecurityVMM User

ManagementVMM Configuration

Management

VMM = Virtual Member Manager

上記は、アプリケーション・サーバーのセキュリティー・アーキテクチャーにVMMがどの様に適合しているかを表していま

す

また、WASでは、統合リポジトリーの代わりに、今までのリリースでサポートされていたユーザー・レジストリーも使用でき

ます。以下のオプションがサポートされています。

・ローカルOS

・スタンドアロンLDAPレジストリー

・スタンドアロン・カスタム・レジストリー

しかし、これらのリポジトリーでは、統合リポジトリーが提供するユーザーやグループの管理、同時に複数のレジストリー

をサポートするといった機能は利用できません。

64


64

WAS上の各リソースのアクセス制御

Java EE 役割（ロール）ベースのアクセス制御

– Servlet, JSP, Enterprise Bean, EJBなどのリソースへのアクセスは役割（ロール）によってコン

トロールされる

– ロールと各リソースのメソッドの組合せ（制約）によりアクセス権を設定

– ロールと実際のユーザーID, グループIDをマップ（役割マッピング）

– 運用上変更が頻繁におきるユーザー管理、セキュリティー管理とプログラムを分離する。

Webリソース

一般ユーザー

プレミアユーザー

GET

Servlet,jsp,html

GETPOST

ロール

実際のユーザー

グループ

Java EE

web.xml

ユーザー認証を検討した後には、そのユーザーがどのリソースを触ることができるかというアクセス制御（認可）を考え

る必要があります。

3章でもセキュリティー役割（ロール）マッピングについて記載いたしておりますが、WAS上のリソースへのアクセス制御

はJava EE Authorizationモデルに基づいて行われます。

ServletやJSP、静的コンテンツなどのWebリソースへのアクセス制御はロール（役割）というアプリケーションの中での概

念に基づいて制御されます。

アクセス権限は、それぞれのリソース(servletなど）に対し、どの役割に、どのようなアクセスを許す、という組合せで設定

されます。たとえば、AというServlet は一般ユーザーであればアクセス可能で、Bというservletはプレミアユーザーのみ

アクセス可能としたいとします。この時の設定のイメージは次のようになります。

servletA allusers GET, POST

servletB premium GET,POST

役割と実際のユーザーの関連付け（マッピング）は別に行います。

このように実際のユーザー環境とアプリケーションを分離することにより、ユーザー環境の変化にプログラムが影響を受

けることがないような構造となっています。これらの設定はアプリケーションをビルドする際にデプロイメント記述子に組

み込まれますが、インストール後に変更することも可能です。Webリソースの場合、セキュリティー制約という概念があり、

Web コンテンツの保護方法を決定します。制約は、Web リソース・コレクション、許可制約、およびユーザー・データ制約

で構成されます。

制約の詳細については、下記 InfoCenter をご参照ください。

「Web アプリケーションにおけるセキュリティー制約」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/csec_secc.html

EJBの場合も基本的にWebモジュールの場合と同様です。セキュリティー・ロールを定義し、その後、メソッド許可と関連

付けることでEJBコンテンツの保護を構成します。

65


65

セキュリティードメイン

WAS V6.1での課題

– セルで設定可能なセキュリティー構成は1つのみ

– 異なる認証リポジトリーを使用する場合は、セルを分割する

WAS V7.0での拡張

– セル内にセキュリティー・ドメインを複数定義し、グローバル・セキュリティー構成を上書きすることが可能

– グローバル・セキュリティー構成は、管理セキュリティーおよびデフォルト・セキュリティー構成に適用

• 例1) Cluster_mem1とserver1上のアプリケーションが使用する認証リポジトリーを別レジストリーとする

• 例2) 管理セキュリティーは統合リポジトリーを、アプリケーション・セキュリティーはLDAPレジストリーを使用

ノード1


ノード3ノード2

アプリケーション・サーバーserver1

アプリ1


Cluster_mem1

アプリ2


Cluster_mem2

アプリ2

クラスターCluster1

レジストリー構成



グローバル・セキュリティー構成

Server1ドメイン構成

Cluster1ドメイン構成

凡例

WAS V6.1までは1つのセルでは1つのセキュリティー構成しか有効にできませんでした。WAS V7ではセル内にセキュ

リティー・ドメインを複数定義することができるようになり、これらセキュリティー・ドメインに対し個別にセキュリティー構成

を設定できるようなりました。これにより、管理セキュリティーとアプリケーション・セキュリティーで使用する認証リポジト

リーを変更するといったことが可能になっています。

セキュリティー・ドメインの作成は、管理コンソールもしくは、スクリプト・コマンドから行うことができます。

管理コンソールの場合、「セキュリティー」‐「セキュリティー・ドメイン」をクリックし、セキュリティー・ドメインに対して構成するセキュリティー属性、およびセキュリティー・ドメインを使用する必要がある有効範囲 (サーバー、クラスター、サービ

ス統合バス、またはセル) を指定します。構成が完了したら、セキュリティー・ドメインを使用するサーバーを再始動する

ことで、それらの有効範囲にあるユーザー・アプリケーションが、セキュリティー・ドメインで定義されている属性を使用し

ます。ドメイン・レベルで構成されていない属性は、グローバル・セキュリティー構成から取得されます。

66


66

Fine-grained 管理セキュリティー

管理セキュリティーに、より詳細なアクセス制御機能を提供

– 管理ロールはセル内のリソースすべてに対する権限付与だが、Fine-grained管理セキュリ

ティーはセル内のリソースに個別に権限付与が可能

– WAS V6.1ではwsadminコマンドで設定していたが、V7では管理コンソールから設定が可能

に

– リソース・タイプとして、セル、ノード・グループ、ノード、クラスター、サーバー、アプリケーションを対象とした管理ロールを割り当てることが可能

– リソース・タイプには親子関係があり、上位のリソースに対して権限を付与するとその下のリソースに対する権限が与えられる

セル

サーバー

ノードクラスターアプリケーション

ノード・グループ

許可グループとは同じ権限を持つリソースを1つにまとめたもの

許可グループ

Fine-grained管理セキュリティーを使用することにより、管理セキュリティーに対してさらに詳細な認可を設定することが

できます。管理ロールのみの認可設定の場合は、セルレベルに対する権限付与でしたが、Fine-grained管理セキュリ

ティーではセル内のリソースレベルで権限を付与することができます。また、WAS V6.1まではFine-grained管理セキュ

リティーの設定はwsadminコマンドで実施していましたが、V7では管理コンソールからも設定することができるようになり

ました。

Fine-grained管理セキュリティーを設定可能なリソース・タイプは以下の6種類になります。

・セル

・ノード・グループ

・ノード

・クラスター

・サーバー

・アプリケーション

※SIBusはFine-grained 管理セキュリティー対象外となりますので、ご注意ください。

67


67

SSL暗号化の流れ

Client Server

クライアント証明書

サーバー証明書

暗号化仕様交渉

鍵生成の元データ交換共通鍵生成

暗号化データ通信開始

クライアント証明書検証情報送付

サーバー証明書送付サーバー認証

クライアント認証

FW

SSLとはSecure Sockets Layerの略で、Netscape Communications社により開発されたプロトコルです。もともとSSLは、

ソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではありません。しかし、

現状はWebにおける認証および通信の暗号化にも多く使用されています。SSLはTCP/IPの上で実現され、その上で

HTTPやLDAPなどのアプリケーションプロトコルが動いています。

クライアント＊とサーバー間の認証はサーバー認証とクライアント認証があります。

＊クライアントとはユーザー（Webブラウザ）だけでなく、サーバーもなりえます。例えば、クライアント：Webサーバー・

サーバー：WASも考えられます。

サーバー認証

サーバーが信頼されたものであることを証明するために使用します。（ウェブサイトの運営主体である法人組織の実在

性を証明）

通常、外部 CA プロバイダーから証明書を購入します。

ウェブサイトと証明書のサーバ名（コモンネーム）が一致、証明書のステータスがValid（有効）となっていれば、サーバ証

明書によって該当ページが認証されているといえます。

クライアントは、ブラウザにインストールされているルート証明書で署名を確認し、サーバ認証を行います。（成りすまし

防止）

クライアント認証

Web サイトの閲覧者が自分のアイデンティティを証明するために使用します。クライアントは、クライアント証明書をサー

バへ送信します。

<クライアント証明書>

ユーザーが使用しているコンピュータ上のファイルに格納されている暗号化された情報。利用者名や利用者が所属する

組織など個人を証明する情報が格納されています。

証明書はさまざまな認証局から入手することができます。サーバ側が信頼していない認証局から発行された証明書を

持っていても、そのサーバにはアクセスできません。

68


68

IHS-WAS間で行うSSL通信

Webサーバープラグイン

– Webサーバーのプロセス内で稼働し、アプリ

ケーション・サーバーへの要求をフォワード

WebサーバープラグインとHTTPトランスポート・チェーン間でSSLの設定も可能

– Webコンテナー・トランスポート・チェーンでは、デフォルトでSSLインバウンド・チャネルが構成

される

• Webサーバープラグインには、plugin-key.kdbがあり、WASから抽出した証明書を追加することで、SSL通信を行うことも可能

• 本番環境でSSL通信をする場合は、鍵管理

（有効期限など）を行うこと

クライアント

ApplicationServerWeb

サーバー Webコンテナー

Webサーバープラグイン

HTTPトランス

ポート・チェーン

Webコンテナー・トランスポート・チェーン

WebコンテナーのHTTPトランスポート・チェーンはHTTP通信の受け口です。Webコンテナープラグインはこのトランス

ポート・チェーンにリクエストを転送します。このWebサーバープラグインとトランスポート・チェーンのHTTP通信はSSLの

設定が可能です。

また、WebコンテナーのHTTPトランスポート・チェーンは、デフォルトでSSL使用可能なトランスポートが構成されます。デ

フォルトでは、Webサーバープラグインには、plugin-key.kdbがあり、WASから抽出した証明書を追加することで、SSL通

信を行うことも可能です。

通常、IHS-WAS間でSSL通信を行う場合、以下の作業が必要となります。

・ Webサーバープラグインの鍵 (証明書) を作成

・ WAS (Webコンテナー) の鍵 (証明書) を作成

・ SSLの構成、公開証明書の交換

・プラグイン鍵ストア・ファイルをWebサーバーにコピー

・プラグイン構成ファイル、WAS設定の確認・変更

69


69

証明書と鍵の管理

証明書有効期限の管理

– WASによって管理されるキー・ストアに格納された証明書の期限を監視、期限切れ前に警告

を出す

• 自己署名証明書を自動更新することも可能

IBM 鍵管理ユーティリティ (iKeyman)と同等の機能が、管理コンソールから使用可能に

– ikeymanは引き続き利用可能

– 証明書要求は生成したツールを使用して受信する必要がある

・ikeyman・新しいキー・データベースを作成する・新しい鍵のペアと認証要求の作成・自己署名付き証明書の作成・認証要求の再作成・CA署名付き証明書をキー・データベースに受け取る・CAのルート証明書を保管する

・キー・データベースをオープンする・鍵を別のデータベースまたはPKCS12ファイルにエクスポー

ト・インポートする・キーの抽出・削除・認証局（CA）と認証要求をリストする

・キー・データベースのデフォルト鍵を作成する・暗号化されたデータベース・パスワードをstashファイルに保

管する同じ機能が提供

・管理コンソール

WASの管理下にある鍵ストアに含まれる証明書に関しては、証明書の期限を監視し、期限切れ前に警告を出すことも

可能です。管理コンソールから、有効期限の閾値の設定と、期限切れ通知先のeメールアドレスを登録します。また、期

限が切れる証明書を自動的に更新するオプションもあります。管理コンソールから証明書と鍵の管理が可能です。ikeymanと同等の操作を管理コンソールから行うことができるようになります。

セキュア・ネットワーク接続を行うには、セキュア・ネットワーク通信のための鍵を作成し、ご使用のサーバーでトラステッドCA として指定された認証局 (CA) から証明書を受信します。 IBM鍵管理ユーティリティ(iKeyman) を使用すると鍵

データベース、公開鍵と秘密鍵のペアおよび認証要求を作成することができます。ユーザーが自分自身のCA として機

能する場合は、iKeymanを使用して自己署名証明書を作成することもできます。

WAS V6.1から、管理ユーザーは従来のikeymanと同等の機能を管理コンソールから行うことが可能になりました。ただし、

個人証明書と署名者証明書の管理はikeyman、管理コンソールのどちらで行なっても可能ですが、証明書要求は生成し

たツールを使用して受信する必要があります。これは、証明書要求をikeymanで作成された場合はikeymanで受信する、

ということになります。

70


70

証明書の管理

WAS V7.0では，WASのコンポーネント間の通信で使用する証明書に、自己署名証明書ではなく

階層付き証明書（チェーン証明書）を使用できるようになった

– セルのルート証明書により各サーバーが使用するチェーン証明書が署名されている

– ルート証明書の有効期限はデフォルトで15年に設定されており，チェーン証明書が更新されても署名に称し

たルート証明書の有効期限内であれば検証が可能

鍵ストア key.p12 には秘密鍵・公開鍵・署名が格納される

トラストストア trust.p12 には公開鍵・署名が格納される

– 各ノード内のプロセスはtrust.p12に格納された公開鍵・署名を検証に使用することでSSL通信が可能

証明書C１ R１

秘密鍵C１公開鍵C１

署名R１

key.p12trust.p12

管理コンソールでの鍵ストアの表示

WAS V6.1では、自己署名証明書の有効期限がデフォルトで1年であり、有効期限が切れるとデプロイメント・マネー

ジャーとの通信に失敗したり、プロセスの起動に失敗する事象が発生していました (WAS V6.1 FP7では発生しません) 。これは、WASV6.1では証明書の署名に自己署名証明書を使用していたことが起因致します。WAS V7.0では証明書の

署名をルート証明書を使用しており、有効期限が切れない限りは、WAS V6.1の課題は発生致しません(だたし、自動更

新する際には、NodeAgentが稼動している必要があります。NodeAgentが稼動していない時に自動更新されてしまっ

た場合には、syncNodeコマンドを実行して構成情報を同期させて下さい) 。

また、各コンポーネント内の証明書の関係についてご説明致します。

デフォルトで、WASは、ノードごとに、固有のチェーン証明書を作成します。チェーン証明書は、ルートで署名された、

DmgrDefaultRootStore または NodeDefaultRootStore に保管された証明書です。デフォルトの鍵ストア key.p12 およ

びトラストストア trust.p12 は、ノード・ディレクトリー内の構成リポジトリーに保管されます。デフォルトのルート証明書は、

ノード・ディレクトリーの下の構成リポジトリーにある root-key.p12 に保管されています。

すべてのノードでは、この共通トラストストア(trust.p12)に、デフォルトのルート証明書が置かれます。さらに、ノードを統

合した後で、共通トラストストア(セル・ディレクトリーにあります)を指すように、デフォルトの SSL 構成が自動的に変更さ

れます。これで、ノードはセル内のすべての他のサーバーと通信できるようになります。

サーバーのコンポーネント間の通信障害が発生した場合には， trust.p12に正しい証明書が格納されているか，

trust.p12が適切に各ノードに配布されているかを確認します。

71


71

セキュリティー監査

セキュアーIT環境の統制に利用できる監査記録を提供

– WAS管理操作、アプリケーションでの認証・認可やその他セキュリティーイベントをモニ

ター

– ｢いつ｣、｢誰が｣、｢何をおこなったのか｣を監査ログに記録

– 法令遵守を証明するための仕組みや脆弱性分析に利用可能

WAS V7.0セキュリティー監査機能の特徴

– 前提：グローバル・セキュリティーを有効にする

– 監査ログファイルはバイナリー保存(可読性あり)• JVM単位で出力 (ファイル名: BinaryAudit_<cell_name>_<node_name>_<server_name>.log)• 監査ログデータをHTML形式のレポートに変換するAudit Readerが提供されている

• ログはデータの暗号化、署名による保護が可能

– 管理者(Administrator)と監査員(Auditor)の権限を分離

• 管理者権限では監査記録やポリシーの表示および変更ができない

• 監査員権限ではWASの構成やランライムの変更ができない

– サード・パーティー製セキュリティー監査サービスとの統合も可能

WAS V7の新機能として、セキュリティー監査が追加されました。セキュリティー監査機能を有効にすることで、WASシステムインフラやアプリケーションでの認証・認可、その他のセキュリティーイベントを監査ログから詳細にモニターすることができるようになります。このセキュリティー監査機能を使用するためには、グローバル・セキュリティーを有効にすることが前提になります。

監査ログのデータは、暗号化することが可能です。暗号化の手順としては、監査データの暗号用の鍵ストアと証明書を作成し、暗号化

構成と署名構成を設定し、サーバーを再起動することで暗号化が有効となります。監査ログの暗号化を行うと、鍵ストアとそのパスワードがないとログの参照ができなくなります。

監査ログファイルはバイナリーで保存され、監査リーダー (Audit Reader) がバイナリー監査ログを解析し、HTML形式のレポートを生成し、表示させます。監査リーダーを利用するには、wsadminのコマンドでAdminTaskオブジェクトのbinaryAuditLogReaderメソッドを実行します。管理コンソールからはHTMLレポートを生成することはできません。

このセキュリティー監査機能は、サード・パーティー製品セキュリティー監査サービスをプラグインすることもできます。現在、z/OSのSMF(System Management Facility)へ監査データを記録するプロバイダー・プラグインが提供されています。

72


72

練習問題

10. 管理セキュリティが有効になっているセルで，特定のノードがデプロイメント・マネージャーと通信できなくなっています。この問題を解決するための措置として適切なものを選びなさい。

A) ノードに正しい鍵ストアが配布されているか確認し，syncNodeで鍵ストアを更新する

B) ノードエージェントが一般ユーザーで起動されていないか確認し，rootユーザーで起動するようにする

C) LDAPサーバーが正常に稼働しているか確認し，必要に応じてLDAPサーバーの再起動を行う

D) 管理コンソールにログインし，管理ユーザーがノードのアクセス権を持っているか確認する

11. 管理ロールの1つ「セキュリティー・マネージャーの管理」が持つ権限として、正しいものを次の中

から１つ選択してください。

A) ユーザーを管理ロールにマップすることができる

B) アプリケーションに対して構成・変更を行うことができる

C) セキュリティー監査機能を実行するために構成を表示、変更することができる

D) WASの構成を変更することができる

12. セキュリティー･ドメインに関する以下の説明のうち正しいものを1つ選んでください。

A) セキュリティー構成は、1つのセルに対して1つしか構成することができない。

B) セキュリティー･ドメインは、スクリプトコマンドでのみ作成することができる。

C) セキュリティー･ドメインを複数構成することで、1つのセル内にLDAPレジストリーとファイル･ベース・レジスト

リーを構成するといった柔軟なセキュリティー設定が可能になる。

D) セキュリティー・ドメインはアプリケーション単位で紐付けることができる。

73


73

5章ワークロード管理

74


74

WAS ND環境でのノードの統合

デプロイメント・マネージャーにアプリケーション・サーバー・ノードを統合

– 管理コンソール

– addNodeコマンド

– wsadmin

作業の順序(管理コンソールの場合）

– デプロイメント・マネージャーの起動

– アプリケーション・サーバーの起動

– デプロイメント・マネージャー管理コンソール上でノードを統合する

• 管理対象ノード・接続はSOAP通信

– 追加されたノードの確認

– アプリケーション・サーバーの始動と稼動確認

デプロイメント・マネージャープロファイルとアプリケーション・サーバーした後、デプロイメント・マネージャーにアプリケー

ション・サーバーノードを統合します。

<作業の順序（管理コンソールの場合）>

1.デプロイメント・マネージャーの起動

2. アプリケーション・サーバーの起動

3. デプロイメント・マネージャー管理コンソール上でノードを統合する

「ホスト」にアプリケーション・サーバーの稼動しているホスト名、「JMXコネクター・ポート」に77で定義した「SOAPコネク

ター・ポート」の番号を入力します。

「アプリケーションを組み込む」をチェックして「OK」をクリックします。

4. 追加されたノードの確認

5. アプリケーション・サーバーの始動と稼動確認

アプリケーション・サーバーは停止していますので、始動します。server1の左のチェックボックスをチェックし、始動ボタ

ンを押します。

別のWebブラウザから http://<ホスト名>:xxxx/snoop へアクセスします。結果が正常に表示されれば、アプリケー

ション・サーバーの起動は成功です。

75


75

addNodeコマンド

コマンドベースのノード追加

– 実行前にデプロイメント・マネージャーが稼働していなければならない

– 実行方法： addNode <DMホスト名> <DMポート名>– addNode コマンドは、デフォルトでは、アプリケーションとバスはセルに引き継がない。

引き継がせたい場合は、”-includeapps”、”-includebuses”オプションを指定する。

– デプロイメント・マネージャにセキュリティをかけている場合は、そこで使用しているユーザーIDとパスワードをオプションに使用します。[-username uid] [-password pwd]

addNode dmgr_host [dmgr_port] [-profileName profilename] [-conntype type] [-excludesecuritydomainstrue | false] [-includeapps] [-startingport portnumber] [-portprops qualified_filename] [-nodeagentshortname name] [-nodegroupname name] [-includebuses] [-registerservice] [-serviceusername name] [-servicepassword password] [-coregroupname name] [-noagent] [-statusport1231] [-quiet] [-nowait] [-logfile filename] [-replacelog] [-trace] [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd] [-help]

addNode dmgr_host [dmgr_port] [-profileName profilename] [-conntype type] [-excludesecuritydomainstrue | false] [-includeapps] [-startingport portnumber] [-portprops qualified_filename] [-nodeagentshortname name] [-nodegroupname name] [-includebuses] [-registerservice] [-serviceusername name] [-servicepassword password] [-coregroupname name] [-noagent] [-statusport1231] [-quiet] [-nowait] [-logfile filename] [-replacelog] [-trace] [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd] [-help]

※addNode構文例

addNodeコマンドは、 “<profile_root>/bin”ディレクトリーから実行する必要があります。セルに取り込む新規ノードのサイ

ズと場所によっては、このコマンドが完了するまでに数分かかることがあります。ノードの統合と共に、ノード・エージェン

トが定義され、ノード・エージェント・サーバーは、addNode コマンドの一部として自動的に開始されます。

# addNode <deploymgr host> <deployment port>

<deploymgr host> でDMのホスト名を指定します。<deployment port>でDMのJMXポート番号を指定します。これらの引

き数は必須です。このコマンドのデフォルトの Java Management Extensions (JMX) コネクターはSOAPです。オプション

として”-includeapps”を使用すると、ノードの統合時にアプリケーションをセルに引き継ぐことができます。

# addNode <deploymgr host> -includeapps

また、同様にバスもセルに引き継ぐことができません。” –includebuses”オプションを使用すると、ノード統合時にバスを

セルに引き継ぐことができます。

# addNode <deploymgr host> -includebuses

※DMは、セル内で高のFix Packレベルになっている必要があります。例えば、addNodeコマンドを使用してWAS V7.0

のノードを DM V6.1のセルに追加することはできませんので注意してください。

addNodeコマンドのオプション機能の詳細については、下記 InfoCenter をご参照ください。

「addNode コマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_addnode.html

76


76

クラスター / クラスター・メンバー

クラスター・メンバーと呼ばれるアプリケーション・サーバーのグループ

クラスター・メンバー上では同じJava EEアプ

リケーションを実行

クラスターを作成することにより、負荷分散・スケーラビリティ・フェイルオーバーが可能

１つのセル上では複数のクラスターを作成することが可能

同一マシンで複数のメンバーが可能（垂直クラスター）

複数マシンにまたがったメンバーが可能（水平クラスター）

異なるOSにおけるクラスターも可能（z/OS除く）

WAS V7.0とV6.1ノードの複合クラスターも

可能

DeploymentManager

Cell

ApplicationServer

ApplicationServer

Node

ClusterMember

ClusterMember

NodeAgent

ClusterMember

ClusterMember Cluster

Member

ClusterMember

Node

ClusterMember

ClusterMember

NodeAgent

ApplicationServer

ApplicationServer

Cluster

WAS NDでサポートされるクラスターは、クラスター・メンバーと呼ばれるアプリケーション・サーバーのグループです。ク

ラスターを構成することで同じJava EEアプリケーションが稼動するアプリケーション・サーバーを容易に構成することが

可能となります。

同じクラスターのメンバー間では、負荷分散・フェイルオーバーがサポートされますので、クライアントから見ると１つのア

プリケーションに対するパフォーマンス・可用性が向上します。また、クラスター・メンバーの追加構成により必要なときに

システムを容易に拡張することができます。

クラスターは１つのセル内に複数構成可能であり、用途によって様々なクラスターを構成することができます。同一マシ

ン内で複数のメンバーを作成し、プロセス障害に対応するための垂直クラスターや、複数マシンにまたがったメンバーを

作成することでパフォーマンス・可用性を高める水平クラスターというのが考えられ、垂直クラスター、水平クラスターを

組み合わせるなど自由に構成できます。

また、クラスターは異なるOSにまたがったクラスターや、 V7.0とV6.1を組み合わせるということも可能となります。

77


77

クラスター設定

WEBコンテナー・EJBコンテナーWLMの際の割り振りの重み付け

クラスターメンバーへの固有ポートの割り当て

EJBコンテナーWLMの際のローカルノード優先設定

HTTPセッションのメモリー間複製の構成

新規にクラスターを作成し、そのクラスターにクラスター・メンバーとしてアプリケーション・サーバーを追加します。

クラスター設定では、EJBコンテナーへの負荷分散への際にEJBクライアントと同じノード上のEJBコンテナーへの負荷

分散を優先させるという設定を行えます。また、HAマネージャーによるトランザクションログのフェイルオーバーの設定も

クラスターメンバーでの引き継ぎとなりますので、クラスター設定において設定します。

クラスターの各メンバー設定では負荷分散の際の割り振りの重み付けを設定することができます。この数字が高いほど

よりリクエストが割振られるということになります。

クラスターの各メンバーには「ウェイト（重み）」を設定することができ、クライアント要求の数の割り振りを調整することが

できます。

クラスター・メンバー作成時には、他のサーバーとポートの競合が発生するのを回避できるように、「固有のHTTPポート

を生成する」というオプションが指定できます。

78


78

重み付けラウンドロビン・ルーティング

– アプリケーションサーバーごとに設定した重みに従ってリクエストを割り振る

– Webサーバー・プラグインはクラスター単位のルーティング・テーブルを持つ

– 新規リクエストを割り振るたびに、アプリケーションサーバーの重みを減算する

– Affinityをもつリクエストは重みが０でも割り振られる（重みにマイナスを許す）

– 重みが0以下になったアプリケーションサーバーには割り振りを行わない

– すべてのアプリケーションサーバーが0以下になったとき、テーブルをリセットする

-10リクエスト 6

-11リクエスト 5

04Reset

01リクエスト 4

02リクエスト 3

03リクエスト 2

13リクエスト 1

14リクエスト 0

Web

Container2

Web

Container １

WebServerWebServer

Plug-in

WebContainer1Weight = 4




ルーティングテーブル

4 1WebContainer1 WebContainer2

WebコンテナーWLMではリクエストの割り振りのロジックとして、重み付けラウンドロビン・ルーティングを使用します。

クラスターメンバー設定にてアプリケーションサーバーごとに設定したウェイトに従ってリクエストを割り振ります。

Webサーバープラグインはクラスター単位にルーティング・テーブルを持ちウェイトに従ってリクエストを割り振ります。

新規リクエストを受けるとウェイトの値を減算し、リクエストをWebコンテナーへと割り振ります。ウエイトが０のサー

バーへの割り振りは停止され、終的にすべてのサーバーのウェイトが０以下になるとテーブルはリセットされます。

SessionAffinityを使用するリクエストに関してはウエイトが0であってもきちんと該当サーバーへと割り振りを行われ

ます。0の状態でSessionAffinityリクエストを受け取ると値は-1になります。V6からはこのマイナスの値を使用できる

ことにより、一層フェアなバランシングが可能となっています。

79


79

クラスターによるワークロード管理(WLM）

2種類のWLM– WebコンテナーWLM ：

Webコンテナーへのリクエストに対するWLM

– EJBコンテナーWLM ：EJBコンテナーへのリクエストに対するWLM

WebServerWebServer

WebServerPlug-in

Application Server（WebContainer）


WLMPlug-in

WebServerWebServer

WebServerPlug-in



WLMPlug-in

Application Server（EJBContainer）




ClusterA ClusterB

WebコンテナーWLM

EJBコンテナーWLM

Cluster Aのクラスター・メンバ

Cluster Bのクラスター・メンバ

クラスターを作成することによりクラスターメンバー間でのWorkLoad Management(WLM)が有効になります。WLMによりク

ラスターメンバー間での負荷分散・障害時のフェイルオーバーが可能になります。

Webコンテナーへのリクエストに対するWLMをWebコンテナーWLMといいます。WebコンテナーWLMはWebコンテナー・

サービスを実行するアプリケーション・サーバーをクラスター化することにより実現できます。また、EJBコンテナーへのリ

クエストに対するWLMをEJBコンテナーWLMといいます。 EJBコンテナーWLMはEJBコンテナー・サービスを実行するア

プリケーション・サーバーをクラスター化することにより実現できます。

80


80

Webコンテナー WLMWebサーバー・プラグインを経由するWebコンテナーへ

のリクエストに対して提供

Webコンテナーのクラスター化により実現

Webコンテナーへのルーティングテーブルはplugin-cfg.xmlが提供

割り振りの手法は重み付けラウンドロビンを使用

アプリケーション・サーバーに重み付けをし、それに基づいて割り振る

プライマリー/バックアップサーバー・リスト

アプリケーション・サーバーに対しプライマリーとバックアップの指定

プライマリー指定のアプリケーション・サーバー障害時にバックアップサーバーに割り振る

セッションIDを持つリクエストに対してはSessionAffinity機能により同一サーバーに割り振る

WebServerWebServer

Plug-in

WebContainer

WebContainer

WebContainer

WebContainer

WebContainer

WebContainer

Cluster

WebコンテナーWLMはクラスターメンバーがWebコンテナーサービスが稼動することで実現します。Webサーバー・プラグ

インを経由するWebコンテナーへのリクエストに対して負荷分散、フェイルオーバーの機能を実施します。Webコンテナー

がリクエストをどのサーバーにどのように割振るかというルーティングテーブルはplugin-cfg.xmlに記述されます。Web

サーバープラグインはそのファイルを見てリクエストを割り振ります。

負荷分散のロジックはクラスターメンバー設定におけるウェイト（重み）に従った重み付けラウンドロビンを使用していま

す。また、クラスターメンバーとなるアプリケーション・サーバーに対しプライマリーかバックアップの指定をすることが可

能です。バックアップ指定のサーバーはプライマリーサーバー障害時にのみサービスを提供することになります。

WebコンテナーWLMではV6.1と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエストは

セッションIDが作成されたサーバーにリクエストを続けることが可能です。

81


81

SessionAffinityND構成では、Webサーバー・プラグインはデフォルトでSession Affinityを行ないます。

JSESSIONIDに付加されるクローンIDを利用します。

– JSESSIONID=0000JOet7zg74ZUbmHz9cqIR7HI:1010uipbp

CloneID=101fovh46

CloneID=1010uipbp

1. 初回リクエスト

2. Plug-inによる割り振り

3. AppServerからのレスポンス

（CookieにJSESSIONID=XXX:1010uipbpが付加）

4.レスポンス

5. 2度目のリクエスト 6. Cookieを検証し、同一サーバーへ

7. サーバーからのレスポンス

8. 2度目のレスポンス

WebServerWebServer

WebContainer1

WebContainer1

Plug-in WebContainer2

WebContainer2

WAS NDによるシステム構成をとることにより、WebコンテナーはHTTPセッションを作成したリクエストに対して、セッショ

ンIDと共にクローンIDを付与します。プラグインはクローンIDが付与されたリクエストを受け取ると、クローンID に紐付け

られたアプリケーション・サーバーへ割り振りを行います。

この仕組みによりセッション情報をもつリクエストは、セッションオブジェクトの存在するサーバーへ続けてアクセスできま

す。この機能をSessionAffinityといいます。

SessionAffinityによって、別のWebコンテナーに割り振られた際の共有セッション情報の復元の頻度を小限にとどめ

、パフォーマンスの低下を防ぐことができます

82


82

EJBコンテナー WLMEJBクライアントからのEJBコンテナーへのリクエ

ストに対して提供

EJBコンテナーのクラスター化により実現

EJBクライアントとEJBコンテナーは別プロセスで

なければならない

– 同一プロセスの場合、Server Affinityにより別プロセスのEJBコンテナーへは割り振られない

割り振りの手法は重み付けラウンドロビンを使用

– アプリケーション・サーバーに重み付けをし、それに基づいて割り振る

「ローカルを優先」設定により、同一ノードのEJBコンテナーを優先することも可能

Transaction Affinityにより同じトランザクション内

のリクエストは同じサーバーに割り振る

EJBClientEJBClient

ORB

WLMPlug-in

EJBContainer

EJBContainer

EJBContainer

EJBContainer

EJBContainer

EJBContainer

Cluster

EJBコンテナーWLMはクラスターメンバーがEJBコンテナーサービスが稼動することで実現します。EJBコンテナーWLMを

使用するEJBクライアントはEJBクラスターメンバーとは別プロセスで稼動する必要があります。EJB WLMはEJBクラス

ターメンバーと別プロセスで稼動するEJBクライアントに対して、負荷分散・フェイルオーバーの機能を提供します。

EJBクライアントとEJBコンテナーが同一プロセス上で稼動する場合、ServerAffinity機能により、全てのEJBクライアント

のリクエストは同一プロセスのEJBコンテナーへとルーティングされます。この場合、WLMは機能しないので障害が発生

しても別のEJBコンテナーへリクエストは送信されません。

EJBコンテナーWLMはWebコンテナーWLMと同様に、クラスターメンバー設定におけるウェイトに基づいた重み付けラウ

ンドロビンでリクエストを割り振ります。

クラスター設定で可能な「ローカルを優先」を選択することで、EJBクライアントは基本的に同じノード上のEJBコンテナー

へWLMルーティングされます。

EJBコンテナーWLMではV6.1と同様にTransactionAffinityにより、トランザクション中のリクエストは必ず前回と同じEJBコ

ンテナーへリクエストを割振られます。

83


83

HTTPセッション・パーシスタンス

セッション情報を別の場所へ避難させることでセッションを維持する

アプリケーション・サーバー自身が提供する機能

アプリケーション・サーバー障害時にもセッション維持可能

セッションオブジェクトｖ

セッション

DB

セッションオブジェクトｖ

セッション

セッション

メモリー間複製セッションDB

• 他のAppServerのメモリー上に

セッションオブジェクトのコピーを作成

• セッションオブジェクトをDBに保管(データベース・セッション・パーシスタンス）

HTTPセッション・パーシスタンスです。これはセッション情報を別の場所へと退避させることでアプリケーション・サー

バー障害時にもセッションの維持を行なう方法で、アプリケーション・サーバー自身が提供する機能です。WAS V6.1と同

様に他のアプリケーション・サーバーのメモリー上にセッション情報を複製するメモリー間複製(Memory to Memory)と、セッション情報をDBに保管する方法の2つがサポートされています。DBの方が大規模な構成をふくむ実績が多数あり，

特に信頼性が要求されるアプリケーションに適しています。メモリー間複製はDBが不要なためセットアップが容易です。

重要なのは、セッション・オブジェクトの大きさで、大きな情報を入れるとパフォーマンスに悪影響します。また書き込む

頻度も関係します。

アプリケーションではサイズの小さいセッション・オブジェクトを保存するようにすることが非常に重要です。

84


84

セッション・パーシスタンス方法の比較

不要

(client-serverの場合、別AppServが必要)

必要

(業務DBと共用可)不要DBの使用

易やや複雑-セットアップ容易性

△

(レプリカ数分増加)(client-serverの場合は増加しない)

○

(パーシスタンスなしと同じ)○メモリー使用量

○△○△◎パフォーマンス

○

サーブレット・サービスの終了

SessionDB

△

(一部ロスト)

時間基準

○

サーブレット・サービスの終了

メモリー間複製

(peer to peer)

×

セッション・

パーシスタンス

を使用しない

△

(一部ロスト)障害時のセッションの復旧

時間基準

メモリー間複製とSessionDBでは、パフォーマンスの明確な相違はないので、・業務アプリケーションでDBを使用する場合には、メモリー使用量からDBの使用を推奨・業務アプリケーションでDBを使用しない場合は、メモリー間複製も選択肢

セッション・パーシスタンスを設定しない場合と設定した場合(データベース、メモリー間複製)を項目毎にまとめまし

た。データベースとメモリー間複製の選択指針は以下になります。

・ Session DBとメモリー間複製では、パフォーマンスの明確な相違はない

業務アプリケーションでDBを使用する場合には、メモリー使用量観点からDBの使用を推奨

業務アプリケーションでDBを使用しない場合は、メモリー間複製も選択肢となる

セッション・パーシスタンスを設定しない場合と設定した場合(データベース、メモリー間複製)を項目毎にまとめまし

た。データベースとメモリー間複製の選択指針は以下になります。

・ Session DBとメモリー間複製では、パフォーマンスの明確な相違はない

業務アプリケーションでDBを使用する場合には、メモリー使用量観点からDBの使用を推奨

業務アプリケーションでDBを使用しない場合は、メモリー間複製も選択肢となる

85


85

セッション・パーシスタンス構成手順概要

メモリー間複製構成

① メモリー間複製を有効化

• クラスター作成時に「HTTP セッションのメモ

リー間の複製の構成」を選択– 自動的にデータ複製サービス(DRS)がデフォルト

設定で構成される

• クラスター作成後、クラスター・メンバー毎の「セッション管理」の「分散環境設定」画面で、「メモリー間の複製」を選択

② メモリー間構成モードなど、必要に応じてパラメーターを変更

セッション・データベース構成

① セッション保管用のデータベースを作成

② データベースにアクセスするためのJDBC プロ

バイダーとデータ・ソースを構成

③ セッション管理の「分散環境設定」画面で、「データ・ベース」を選択

④ 詳細パラメータを必要に応じて変更

メモリー間の複製

データベース

[Webコンテナー]-[セッション管理]-[分散環境設定]

セッション・パーシスタンス構成手順の概要です。

メモリー間複製の構成では、データ複製サービス(DRS)が使用されます。（クラスター作成時に、「HTTPセッションのメモ

リー間の複製構成」を選択した場合は、自動的にデータ複製サービスが構成されます。）

セッション・データベースの構成では、DBの準備とDBアクセスの設定が必要となります。

86


86

（参考）セッション管理構成画面

分散環境設定セッション・パーシスタンスを設定

セッション・トラッキング・メカニズム• SSL IDトラッキング

Secure Sockets Layer (SSL) のセッション ID を使用してセッション管理を行う場合に指定

• Cookieを使用可能セッション管理にCookieを使用する場合に指定

• URL再書き込みを使用可能URL 再書き込み（URLの後ろにセッションIDを付加して送信する方法）を使用する場合に指定

メモリー内の大セッション・カウントセッションが未使用状態のものを無効化するまでのタイムアウト値（分）

セッション・タイムアウトメモリーに保持するセッションの大数を指定

セッション・アクセスのシリアライズ並行セッション・アクセスを禁止するかを指定• 大待機時間

セッションアクセス終了を待機する大時間（秒）

セッション管理の構成画面です。

○セッション・トラッキング・メカニズム

SSL ID、Cookie、URL再書き込みを指定できます。SSL IDを使用する場合は、CookieやURL再書き込みと併用すること

をお勧めしています。

○メモリー内の大セッション・カウント

メモリー内に保持できるセッションの大数を指定します。オーバーフローを許可している場合、大数を超えるとメモ

リー内に新たにセッションを格納する領域がとられます。この場合、無限にセッションが作成されます。

○セッション・タイムアウト

セッションが使用されなくなってから無効にするまでの時間を設定します。

○セッション・アクセスのシリアライズ

並行セッション・アクセスを禁止するかどうか指定します。

○分散環境設定

セッション・パーシスタンスの設定を行います。

87


87

DRS（データ複製サービス）

DRS : Data Replication Service– クラスター下の複数のアプリケーションサーバー間におけるデータの複製を提供するWAS内部

コンポーネント

– アプリケーションサーバー毎に１つ

WAS V7.0ではDRSを使用して以下の機能を提供

– HTTPセッション・メモリー間複製

– HTTPセッション情報を複数のアプリケーションサーバーに持つことで障害時のセッション処理に対する

フェイルオーバーが可能

– ステートフル・セッションビーン・ステートの複製

– ステートフル・セッションビーン情報を複数のアプリケーションサーバーに持つことで障害時のステートフル・セッションビーン処理に対するフェイルオーバーが可能

– 動的キャッシュの複製

– キャッシュデータを複数のアプリケーションサーバーに持つことでパフォーマンスの向上が見込める

DRS（Data Replication Service）は、クラスター配下のアプリケーションサーバー間におけるデータ複製を提供します。

DRS機能はアプリケーションサーバー毎に稼動し、お互い連携することにより、データ複製を可能にします。

V6.1と同様にV7.0では、DRSを使用して以下の機能を提供します。

•HTTPセッション・メモリー間複製

HTTPセッションオブジェクト生成を実施するWebコンテナー稼動のアプリケーションサーバーをクラスター化した際に、ア

プリケーションサーバー間でセッション情報のフェイルオーバーを実施します。HTTPセッションのフェイルオーバーはセッ

ション情報をデータベースに格納することでも実現できますが、DRSでは全てメモリー間での複製となります。

•ステートフル・セッションビーン複製

ステートフルセッション・ビーンを使用するEJBコンテナ稼動のアプリケーションサーバーをクラスター化した際に、アプリ

ケーションサーバー間でステートフル・セッション・ビーン情報のフェイルオーバーを実施します。

•動的キャッシュの複製

動的キャッシュを生成・保持するWebコンテナー稼動のアプリケーションサーバーをクラスター化した際に、アプリケー

ションサーバー間でキャッシュ情報の共有を実施します。１つのキャッシュを複数のサーバーに保持することで、パ

フォーマンスの向上が見込めます。

88


88

複製ドメイン

DRSを使用するアプリケーションサーバーの集合

同一ドメイン内でDRS同士のデータのやり取りは発生

１つのアプリケーションサーバーがいくつのデータ・レプリカを別のアプリケーションサーバーに作成するかを指定

– 単一レプリカ（デフォルト）

• レプリカの数をデフォルトの1にした場合。ドメイン内に１つのDRSに対するレプリカは１つ

– 全グループ・レプリカ

• レプリカの数を「ドメイン全体」に指定すると、ドメイン内の全てのサーバーが全てのレプリカを保持します

– 特定のレプリカ数

• ドメイン内に指定された数のレプリカを保持

AppServer 1AppServer 1



DRS

DRS

DRS

AppServer 4AppServer 4DRS

複製ドメインとは、DRSを使用するアプリケーションサーバーの集合です。この複製ドメイン内のDRS同士でデータの複

製は実行されます。複製ドメイン設定では、１つのアプリケーションサーバーがいくつのデータ・レプリカを別のアプリ

ケーションサーバーに作成するかを指定します。

次の３つの指定が可能です。

・単一レプリカ（デフォルト）

デフォルトで使用されます。１つのデータに対して複製ドメイン内に１つのデータ・レプリカを保持します。

・全グループ・レプリカ

複製ドメイン内の全てのサーバーが1つのデータに対するレプリカを保持します。

・特定のレプリカ数

１つのデータに対していくつレプリカを持つかというのを数で指定可能です。

89


89

HTTPセッション・メモリー間複製

HTTPセッション情報を複数のアプリケーション・サーバーに持つことで障害時のセッション処理に

対するフェイルオーバーが可能

データ複製ドメイン設定でのレプリカの数と、アプリケーション・サーバー毎に設定するメモリー間複製設定で動作環境が決まる

ドメイン指定はアプリケーション・サーバー単位

アプリケーション・サーバー毎のメモリー間複製モード設定

– クライアントのみ – ローカルで作成・更新されたセッション情報をサーバーに送信

– サーバーのみ - 他のアプリケーション・サーバーのセッション情報を受信

– クライアントとサーバー両方 – クライアント・サーバー両方の動きをする

基本的に次の２つの動作環境がある

– Peer to Peer– 各々のアプリケーション・サーバーが自分および他のアプリケーション・サーバーのセッション情報を保持する

– アプリケーション・サーバー障害時、ホット・フェイルオーバーによりプラグインはレプリカを持っているサーバーに割り振る

– Client/Server– クライアントのアプリケーション・サーバーは自分のセッション情報を保持し、他クライアントのアプリケーション・サーバー

のセッション情報はサーバーのアプリケーション・サーバーに保持される

– アプリケーション・サーバー障害時、障害サーバーのセッション・リクエストを受けたアプリケーション・サーバーは、サーバー指定されたアプリケーション・サーバーから該当セッション情報を取得する

DRSを使用して、HTTPセッション情報を複数のアプリケーション・サーバーに持つことで、障害時のセッション処理に対するフェイルオーバーが可能となります。この機能を使用するために、アプリケーション・サーバーごとにメモリー間複製設定を行う必要があります。

メモリー間複製設定では、そのアプリケーション・サーバーがデータレプリカを送信するのみか、受信するのみか、またその両方かというのを指定します。また、メモリー間複製設定ではどの複製ドメインを使用するかというのを指定します。

ドメインに指定しているレプリカの数と、各アプリケーション複製モードによってDRSの動作環境が決まります。動作環境には大きく分けて次の２つがあります。

・ Peer to Peer各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報を保持します。V7ではアプリケーション・サーバーの障害が発生すると、プラグインはレプリカのあるサーバーにリクエストを割り振る、ホット・フェイルオーバーが提供されます。

・ Client/Serverデータレプリカの送信のみに指定されたクライアントと、受信のみに指定されたサーバーによってこの構成はとられます。

アプリケーション・サーバー障害時に、セッションリクエストを受け取ったクライアントは、サーバーからセッション情報を取得しサービスを行います。

90


90

Webサーバーをセルで管理

Node

ApplicationServer

ApplicationServer

NodeAgent

DeploymentManager

Cell

WebServerWebServerPlug-inConfig

XML filePlug-in Module

HTTP(S)HTTP(S)

WebサーバーはNode Agent経由で管理され、管理コンソールから次の操作が可能

①Web サーバーの状況の検査②プラグイン構成の生成・伝搬

WebサーバーがIBM HTTP Server(IHS)の場合は、以下の操作も可能

③Webサーバーの開始・停止④ログファイルの表示⑤構成ファイル(httpd.conf)の表示・編集

WAS 7 ND では、IBM HTTP Server 7をWebSphere セルに含めて管理可能です。

IBM HTTP Server の起動や停止、設定をWebSphere 管理コンソールから行うことができます。

また、アプリケーション・サーバーとIBM HTTP Server が別のマシンにインストールされている場合、プラグイン構成ファイルのコピーを自動で行わせることができます。

◆IBM HTTP Server とWebSphere Application Serverを同じノード（マシン）に導入した場合◆→Webサーバーを管理対象ノードに定義

WAS V6からはWebサーバーをデプロイメント・マネージャーの管理対象サーバーに含めることができるようになりました。

これにより、 WebサーバーはNode Agent経由で管理され、管理コンソールから以下の操作が可能になります。

①Web サーバーの状況の検査

②プラグイン構成の生成・伝搬

WebサーバーがIBM HTTP Server(IHS)の場合は、以下の操作も可能です。

③Webサーバーの開始・停止

④ログファイル（error.log, access.log)の表示

⑤構成ファイル(httpd.conf)の表示・編集

91


91

リモートのWebサーバーを管理する場合

◆ IBM HTTP Server とWebSphere Application Serverを別マシンに導入した場合◆→Webサーバーを非管理対象ノードに定義

IHS管理

Process

ApplicationServer

ApplicationServer

Node

Node Agent

DeploymentManager

Web ServerWeb ServerPlug-inConfig

XML filePlug-in Module

HTTPコマンド

HTTP(S)

HTTP(S)

マシンAマシンB

Webサーバーは、次の操作が管理コンソールから可能。


②プラグイン構成の生成

WebサーバーがIBM HTTP Server(IHS)の場合は、WebサーバーはIHS管理プロセス経由で管理され、以下の操作も可能

③プラグインを手動（管理外Webサーバーの場合）で伝搬

④Webサーバーの開始・停止

⑤ログファイルの表示

⑥構成ファイル(httpd.conf)の表示・編集

リモートのWebサーバーマシンを非管理ノードとしてデプロイメント・マネージャー経由で管理することも可能です。これに

より管理コンソールより以下のことが実施可能です。


②プラグイン構成の生成

WebサーバーがIBM HTTP Server(IHS)の場合は、WebサーバーはIHS管理プロセス経由で管理され、以下の操作も可

能です。

③プラグインを手動（管理外Webサーバーの場合）で伝搬

④Webサーバーの開始・停止

⑤ログファイル（error.log, access.log)の表示⑥構成ファイル(httpd.conf)の表示・編集

92


92

SIBusとメッセージング・エンジン

SIBusBus Member Bus Member

Destination Destination Destination Destination

Application Server

Messaging EngineMessage Point Message Point

Application Server Cluster

Clustered Messaging Engine

Message Point Message Point

システム統合バス(SIBus）とは・・・

– WASのデフォルト・メッセージング・プロバイダー機能を論理的に定義したもの

– 管理コンソールでメッセージング関連リソースをまとめて設定することで定義します

– 実行時には、アプリケーションに対してメッセージング処理を隠蔽し、一つのJMSプロバイダーとしてサービスを提供する

メッセージング・エンジン（ME)とは・・・

– SIBusのメッセージング機能を実現するための主要コンポーネント

– バス・メンバー（アプリケーション・サーバーまたはクラスター）上で稼働する（セルをまたがっては構成できない）

– バス中に複数のMEがある場合には相互に連携してメッセージング機能を実現することで、ワークロードの分散の効果が期待できる

SIBus (System Integration Bus)は、メッセージング・プロバイダーを論理的に定義したもの (Logical Entity)であり、

実体としてのメッセージング・プロバイダー機能はMEにより提供されています。

別の言い方をすると、SIBusは仮想的なメッセージング・プロバイダーで、機能の実装はMEにより提供されています。

アプリケーションは、表面的には、SIBusのインスタンスであるバスに接続し、宛先を介してメッセージのやり取りを

行います。ただし、内部的には、アプリケーションはMEに接続して、メッセージ・ポイントを介してメッセージのやり取

りを行っています。

メッセージング・プロバイダーを利用するために、WAS管理者はバスを作成し、バス・メンバーを登録して、そのバ

ス・メンバー上に宛先を作成します。これにより、バス・メンバーとして登録したアプリケーション・サーバーあるいはクラスターにはMEが生成され、宛先に関連付けられたバス・メンバーのMEにはメッセージ・ポイントが生成されます。

アプリケーション・サーバーとMEは、同一プロセス内で動作します。

WAS管理者は抽象化されたバスや宛先だけでなく、実体であるMEやメッセージ・ポイントを意識しなくてはなりませ

んが、アプリケーションを開発する上では、バスに接続し宛先にメッセージを送信する、という考え方に基づいてコー

ディングできます。

93


93

メッセージング・エンジン・ポリシー・アシスタンス

ポリシー・アシスタンス

– SIBusにバス・メンバーとしてクラスターを登録するときに呼ばれ、以下の機能を提供します

• コア・グループ・ポリシーの自動設定

• タイプに従って、アドバイスを提供する

• ME環境のグラフィカルに表示する

ポリシー・タイプは４種類を提供

– 高可用性ポリシー（後述）

– スケーラビリティー・ポリシー（後述）

– 高可用性を備えたスケーラビリティー

ポリシー（後述）

– カスタム・ポリシー

MEポリシー・アシスタンスは、WAS V7.0で追加された機能です。

これはSIBusにバス・メンバーとしてクラスターを登録するときに呼ばれ、コア・グループ・ポリシーの自動設定や、設

定に必要なアドバイスを提供したり、ME環境をグラフィカルに表示するなどの機能を持っています。

ポリシー・タイプとして4種類のポリシーを提供していて、それぞれのトポロジーを効率よく構成することが可能です。

以下のページで、これらのトポロジーについて解説していきます。

94


94

SI Bus

Node 1 Application Server 1

単体構成のトポロジー

単体構成

– 1つのアプリケーション・サーバーのみをバス・メンバーとして持つ状態

– 1つのMEのみしか稼働しないので高可用性やスケーラビリティーは持たない

– 1つのMEのみしか稼働しないのでSPOF（Single Point of Failure）となりうる

（注意）メッセージング・エンジン・ポリシー・アシスタンスの対象外

Messaging Engine ①稼働中のME（優先順位①）

待機中のME（優先順位②・・・）

稼働しないME

ME凡例

このページでは、単体構成のトポロジーについて説明します。

これは1つのアプリケーション・サーバーのみをバス・メンバーとして登録した状態で、１つのMEのみしか存在しませ

ん。したがって、高可用性やスケーラビリティーは持ちません。SPOF (Single Point of Failure) となり得ます。

この場合にはメッセージング・エンジン・ポリシー・アシスタンスの対象外です。

95


95

SI Bus

Cluster


高可用性のトポロジー

高可用性メッセージング・エンジン・ポリシー

– ポリシー・アシスタンスにより提供されるポリシーの１つ

– 複数のノード上の複数アプリケーション・サーバーにより構成されるクラスターが必要

– メッセージング・エンジンは複数アプリケーション・サーバーのうち１つで稼働（1ofNポリシー）

– フェイル・オーバー後、障害サーバーが復活してもフェイル・バックは行わない

Messaging Engine ①


Messaging Engine ②

フェイルオーバーフェイル

バック○ ×

Core Group Policy A

稼働中のME（優先順位①）


稼働しないME

ME凡例

このページでは、高可用性のトポロジーについて説明します。

メッセージング・エンジン・ポリシー・アシスタンスで提供する選択肢のひとつに「高可用性メッセージング・エンジン・

ポリシー」があります。

このポリシーで作成されるトポロジーを構成するには、複数のノード上の複数アプリケーション・サーバーにより構成されるクラスターが必要です。メッセージング・エンジンは複数アプリケーション・サーバーのうち１つで稼働（1ofNポ

リシー）します。フェイル・オーバー後、障害サーバーが復活してもフェイル・バックは行われません。

96


96

SI Bus

Cluster


スケーラビリティーのトポロジー

スケーラビリティー・メッセージング・エンジン・ポリシー


– １つのノード上の複数のアプリケーション・サーバーにより構成されるクラスターが必要


– メッセージング・エンジンは優先サーバーのみで稼働（フェイル・オーバーしない）

Messaging Engine A

Application Server 2

Messaging Engine B

Messaging Engine B

Core Group Policy A Core Group Policy B

Messaging Engine A

フェイルオーバー

フェイルオーバー× ×



稼働しないME

ME凡例

このページでは、スケーラビリティーのトポロジーについて説明します。

メッセージング・エンジン・ポリシー・アシスタンスで提供する選択肢のひとつに「スケーラビリティー・メッセージング・

エンジン・ポリシー」があります。

このポリシーで作成されるトポロジーを構成するには、１つ以上のノード上の複数アプリケーション・サーバーにより

構成されるクラスターが必要です。メッセージング・エンジンは複数アプリケーション・サーバーのうち１つで稼働（1ofNポリシー）します。メッセージング・エンジンは優先サーバーのみで稼働し、フェイル・オーバーはしません。

97


97

Node 2

SI Bus

Cluster


高可用性を備えたスケーラビリティーのトポロジー

高可用性を備えたスケーラビリティー・メッセージング・エンジン・ポリシー


– 複数のノード上の複数アプリケーション・サーバーにより構成されるクラスターが必要


– メッセージング・エンジンはフェイル・オーバー／フェイル・バック共に可能

Application Server 2

Core Group Policy A Core Group Policy B

Messaging Engine A ②

Messaging Engine A ① Messaging Engine B ②

Messaging Engine B ①

フェイル・オーバーフェイル・バック

フェイル・オーバーフェイル・バック○○



稼働しないME

ME凡例

このページでは、高可用性を備えたスケーラビリティーのトポロジーについて説明します。

メッセージング・エンジン・ポリシー・アシスタンスで提供する選択肢のひとつに「高可用性を備えたスケーラビリ

ティー・メッセージング・エンジン・ポリシー」があります。

このポリシーで作成されるトポロジーを構成するには、複数のノード上の複数アプリケーション・サーバーにより構成されるクラスターが必要です。メッセージング・エンジンは複数アプリケーション・サーバーのうち１つで稼働（1ofNポ

リシー）しますが、メッセージング・エンジンが複数セット稼働していますので、スケーラビリティーが実現されています。

メッセージング・エンジンはフェイル・オーバー／フェイル・バック共に可能です。

98


98

全てのアプリケーション・サーバーのMDBからアクティブなMEへの接続が可能

– WASV6.1以前では、アクティブなMEが稼動しているアプリケーション・サー

バーからのみ接続が可能

• V6.xでは、MDB用とSIBus用を別クラスターとして登録

SIBus-MDBのトポロジー（1/2）

WAS V6.xにおけるトポロジー

（WAS V7.0におけるデフォルト・トポロジー）

WAS V7.0で可能になったトポロジー「常にすべてのサーバーでMDBを活動化する」を選択した

場合

SI Bus

Cluster

ApplicationServer 1

ApplicationServer 2

ME

Cluster

ApplicationServer 3

ApplicationServer 4

MDB

MDBME

SI Bus

Cluster

ApplicationServer 1

ApplicationServer 2

ME MDB

MDBME

WASの以前のバージョンでは、アプリケーション・サーバー1上のME1がアクティブな場合、アプリケーション・サー

バー2からME1に接続することが出来ませんでした。この制約により、MDBが稼動しているアプリケーション・サー

バーとMEが稼動しているアプリケーション・サーバーを別クラスターに構成するというような対応が必要でした。

WAS V7.0ではこの制約がなくなり、全てのアプリケーション・サーバーのMDB (Message Driven Bean)からのア

クティブなMEへの接続が可能になりました。この構成とする場合には、管理コンソールより、「リソース > JMS > アクティベーション・スペック」を選択し、“常にすべてのサーバーでMDBを活動化する”のチェックボックスをONにして

下さい。(デフォルト値はOFFです。)

・InfoCenter - 「JMS activation specification [Settings] 」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.multiplatform.doc/sibjmsresources/SIBJMSActivationSpec_DetailForm.html

・InfoCenter - 「How a message-driven bean connects in a cluster 」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.multiplatform.doc/concepts/cjn_mdb_endpt_overview.html

99


99

外部クラスター上のMDBからの接続

– デフォルトの設定では、外部クラスター上のMDBから接続する場合は、全てのアプリケーション・サーバー上のMDBが稼働し、アクティブなMEに接続します。

• 宛先上で「排他的受信」を設定することで、一つのアプリケーション・サーバー上のMDBの

みがメッセージを受信可能とすることが可能です。

• 「排他的受信」は、MDBでのメッセージの順次処理をする上での前提になります。

SIBus-MDBのトポロジー（2/2）

複数MDBが受信可能（デフォルト設定）単一MDBが受信可能（「排他的受信」の場合）

SI Bus

Cluster

ApplicationServer 1

ApplicationServer 2

ME

Cluster

ApplicationServer 3

ApplicationServer 4

MDB

MDBME

SI Bus

Cluster

ApplicationServer 1

ApplicationServer 2

ME

Cluster

ApplicationServer 3

ApplicationServer 4

MDB

MDBME

メッセージング・エンジンが稼働するアプリケーション・サーバー・クラスターとは別のクラスター上で稼働するMDBの受信方法を設定する場合の注意点です。

デフォルトの設定では、複数のアプリケーション・サーバーで稼働する複数のMDBがアクティブなMEに接続します

ので、メッセージは複数のMDB上で処理されることになります。

単一のMDBでメッセージの処理を行いたい場合には、宛先の設定で「排他的受信」を有効にして、一つのMDBの

みがメッセージを受信するように設定します。これは、MDBでメッセージの順次処理を行う場合の前提となる設定で

す。確実に順次処理を行うための方法については、以下のリンク先「メッセージ配列」を参照してください。

・InfoCenter - 「メッセージ・ドリブン Bean がクラスター内で接続する方法」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/concepts/cjn_mdb_endpt_overview.html

・InfoCenter - 「メッセージ配列」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/concepts/cjj8000_.html

100


100

練習問題

13. DRS（データ複製サービス）で共有される情報のうち，障害が発生した際のフェールオーバーを

目的に共有されるものを選びなさい

A) HTTPセッション

B) ステートフル・セッションBeanのステート情報

C) 動的キャッシュ

14. addNodeコマンドでアプリケーションを組み込むオプションを次の中から1つ選択してください。

A) -includesamplesB) -includefeaturesC) -includeapps

15. 以下のEJBコンテナーWLMの説明の中から正しいものを選びなさい

A) EJBクライアントと同一のJVM内のEJBコンテナでEJBが実行されている場合でも，WLMにより，他のJVMで実行されているEJBが呼び出されることがある

B) 「ローカルを優先」オプションを指定すると，可能な限り，EJBクライアントと同一のノードで実行されているEJBが呼び出される

C) EJBのWLMでは，全てのEJBコンテナのリクエスト数が同程度になるように割り振りが行われる

D) Transaction Affinityは，同じテーブルにアクセスするアプリケーションを同じEJBコンテナに割り振る機能で

ある

101


101

6章保守とパフォーマンス・チューニング

102


102

クラス・ローダーの設定

クラス・ローダーはクラスを検索し、ロードするための仕組み

– WASでは階層構造をとる複数のクラス･ローダーを使用

– この設定によりモジュールおよびクラスの可視性が決定される

クラス・ローダー分離ポリシー

– アプリケーション・クラス・ローダー・ポリシー：アプリケーションの分離を制御

• 単一 (Single)• 複数 (Multiple)

– WAR クラス・ローダー・ポリシー：Web モジュールの分離を制御

• アプリケーション (Application)• モジュール (Module)

クラス・ローダー・モード

– 親が初 (Parent First )

– 親が後 (Parent Last)

クラス・ローダーは、クラス・ファイルを検出し、ロードします。クラス・ローダーにより、サーバーにデプロイされたアプリケーションが、使用可能なクラスおよびリソースのリポジトリーにアクセスできるようになります。

WebSphere Application Server のクラス・ローダーは以下の階層構造となっています。1.Java 仮想マシンで作成される、ブートストラップ、拡張、および CLASSPATH のクラス・ローダー2. WebSphere 拡張クラス・ローダー3. アプリケーション・モジュール・クラス・ローダー4. WAR モジュール・クラス・ローダー（各クラス・ローダーは、直前のクラス・ローダーの子になっています。）

また、アプリケーションとモジュールの分離を制御するための設定が、アプリケーション・クラス・ローダー・ポリシーと、WAR クラス・ローダー・ポリシーになります。アプケーション・クラス・ローダー・ポリシー（アプリケーション・サーバー単位に設定）・単一(Single)…アプリケーション・クラス・ローダーを複数のアプリケーションで共用する（アプリケーションは分離されない）・複数(Multiple)…アプリケーション・クラス・ローダーをアプリケーションごとに固有にする（アプリケーションは互いに分離される）WAR クラス・ローダー・ポリシー（エンタープライズ・アプリケーション単位に設定）・アプリケーション(Application)…Webモジュールの内容も、アプリケーション・クラス・ローダーによってロードされる・モジュール(Module) …各Webモジュールは、アプリケーション・クラス・ローダーを親に持つ独自のクラス・ローダーを持つ

また次のクラス・ローダー・モードが提供されています。・親が初(Parent First)…クラス・ローダーは、ローカル・クラス・パスからクラスのロードを試行する前に、親クラス・ローダーにクラスのロードを委任します。（デフォルト）・親が後(Parent Last)…クラス・ローダーが、クラスのロードをその親に委任する前に、クラスをそのローカル・クラスパスからロードしようとします。

クラス･ローダーは、JavaEE対応のJVMが共通して提供するJVMクラス・ローダーとWASが提供するクラス･ローダーの2種類に大別されます。V6.0.xではWebSphere拡張クラス・ローダーがロードするランタイムのクラスはアプリケーションから直接参照出来る構造になっていましたが、V6.1以降ではOSGiフレームワークを採用した事でWASが内部的に使用する実行クラスの不可視性が高まり、アプリケーションから直接参照出来ない構造になりました。

クラス・ローダーの詳細については、下記 InfoCenter をご参照ください。「クラス・ローダー」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/crun_classload.html

103


103

クラスローダー階層に関する考慮点

WASではクラスローダーが階層化されているため

その優先順位の設定に注意が必要

– 「親が初（Parent First）」WASのクラスがアプリのクラスより優先

– 「親が後（Parent Last）」アプリのクラスがWASのクラスより優先

「親が初」で動いているアプリケーションは，意図せずWASのもつライブラリに依存している

可能性がある

– その場合，WASのバージョンアップの際に

問題が発生する可能性がある

– 可能な限り「親が後」で使用する

クラスローダーの詳細については以下の文章を参照「クラスローダーとJ2EEパッケージング戦略を理解する」http://www.ibm.com/developerworks/jp/websphere/library/java/j2ee_classloader/

WASではクラスローダーが階層化されているためその優先順位の設定に注意が必要

•「親が初（Parent First）」

WASのクラスがアプリのクラスより優先

•「親が後（Parent Last）」

アプリのクラスがWASのクラスより優先

「親が初」で動いているアプリケーションは，意図せずWASのもつライブラリに依存している可能性がある

•その場合，WASのバージョンアップの際に問題が発生する可能性がある

•可能な限り「親が後」で使用する

104


104

バックアップ・リストアの基本方針

バックアップ取得のタイミング

– インストール直後

• 製品バイナリも含めたバックアップ取得

– 修正モジュール適用前後

– 構成変更の前後

リストアのタイミング

– 不慮の問題発生によりシステムが動作しない状態になった場合

• HW障害、人為的障害、自然災害、など

障害など不慮の問題が発生した時に迅速な復旧が行えるように、普段からバックアップを取得しておくことが重要で

す。

バックアップ取得は、システム要件やお客様要件にもよりますが、一般的には、製品インストール直後や修正モ

ジュール適用前後、構成変更の前後などに行います。製品バイナリーは、製品再インストールにより復元できるため

対象外と考えて良いですが、修正モジュールの再適用や適用後の検証にかかる時間が大きくなることから、製品バ

イナリーや構成ファイルを併せてバックアップ取得しておく方法も考えられます。

リストアは、不慮の問題発生によりシステムが正常動作しない状態になった場合に行います。不慮の問題は、HW障害や人為的障害、自然災害など、予知不可能なさまざまな原因によって発生するため、想定されるケースに応じ

て事前にバックアップやリストアの対象を検討しておく必要があります。

105


105

WASのバックアップリストア

も確実な方法

– <WAS_ROOT>ディレクトリ以下を丸ごとアーカイブ化

WAS構成情報バックアップ・リストアのツール

– backupConfig.sh(bat) / restoreConfig.sh(bat)• <RROFILE_ROOT>/config ディレクトリ以下をアーカイブ/リストアするツール

• バックアップファイル(zip形式)の名称は指定可能– （デフォルト）<PROFILE_ROOT>/bin/WebSphereConfig_YYYY-MM-DD.zip– ND構成の場合はセル内の全ノード分の構成情報を保持しているDMプロファイル分の

み取得

• 使用時の考慮点– ホット・デプロイメントによるアプリケーション更新を行っている場合はinstalledAppsディ

レクトリのバックアップも取得

– WebSphereセキュリティ/SSL通信を構成している場合はetcディレクトリのバックアップも取得

– 各種プロパティファイルを編集している場合はwsadminやffdc などはプロパティファイルにより動作のカスタマイズが可能なのでpropertiesディレクトリのバックアップも取得

– manageprofiles.sh(bat) -backupProfile／-restoreProfile• 対象は<Profile_root> ディレクトリ以下の全てのディレクトリとファイル

• バックアップ時には対象プロファイルに関連するプロセスを停止

WASのバックアップ方法としては、<WAS_ROOT>以下をまとめてバックアップ取得しておく方法が、も確実な方

法です。 WASには、構成情報バックアップ・リストアのためのツールが提供されていますが、これらのツールでは一

部のディレクトリ配下しかバックアップ取得されないため、構成によっては、アプリケーションのインストール先やログ

出力先といった他のディレクトリをバックアップ取得する仕組みが必要となります。

WASの構成情報のバックアップ取得ツールとして、backupConfigコマンドが準備されています。バックアップ・リスト

アのためのコマンドとしては、backupConfig.sh(bat)、restoreConfig.sh(bat)の2種類のコマンドがあります。このコ

マンドでは、バックアップ・リストアの対象が<Profile_root>/configディレクトリ以下に限られるため、ホットデプロイメ

ントを使用している場合には、installedApps以下のアプリケーション・ファイルのバックアップまたは稼動しているア

プリケーションのファイルを別途管理する必要があります。また、プロパティー・ファイルを変更している場合やSSLの鍵情報などは、必要に応じて手動で別途バックアップを取得する必要があります。

WASV6.1からは、wasprofileコマンドの拡張版としてmanageprofilesコマンドが提供されており、以下の2つのオプ

ションがあります。

・ –backupProfile・ –restoreProfile

manageprofilesコマンドのプロファイルのバックアップ・リストアオプションは、 <Profile_root>ディレクトリ以下の全

てのディレクトリとファイルを対象としています。そのため、バックアップ取得作業を短縮する事が出来るようになりました。但し、 backupConfig.sh(bat)やrestoreConfig.sh(bat)がプロセスを止めずに行えるオプション（-nostop）を備

えているのに対して、プロファイルのバックアップ・リストアは必ず関連するプロセスを停止しなければなりません。状

況に応じて、それぞれのコマンド、オプションを使い分ける事が推奨されます。

106


106

システムのバックアップ方法

バックアップの取得が必要と考えられるタイミング

– インストール直後

– Fix Pack適用前・後

– 構成情報の変更前・後

バックアップ方法– backupConfigコマンドを使用

• コマンドを実行するプロファイルの構成ファイルである<profile_root>¥configディレクトリー配下をzipファイ

ルにアーカイブ

• 使用方法： backupConfig <backup_file> [options]• [options]

-nostop ：構成のバックアップ前にサーバーを停止しないように指示-quiet ：通常モードで出力される進行情報を抑止-logfile <fileName> ：情報を書き込むログ・ファイルのロケーションを指定-profileName <profileName> ：マルチプロファイル・システムで、プロセスを指定-replacelog ：現行ログに追加する代わりに、ログ・ファイルを置き換える-trace ：デバッグのために、ログ・ファイルにトレース情報を生成する

セキュリティが使用可能の場合-user : ユーザー名-passwrd : パスワード

– ディレクトリーのコピー

• <WAS_root>ディレクトリー配下のすべてのファイルをzipなどでバックアップする

バックアップの取得が必要と考えられるタイミングは以下のようなときです。

WASのインストール直後、Fix Pack適用前・後、管理コンソールやwsadminによる構成情報の変更前・後

アプリケーション・サーバーの作成、データ・ソースの設定などのパラメータ変更、アプリケーションのインストールなどを

実施し、管理コンソールでマスター構成リポジトリーの保管を実施するとき、また、Webサーバー定義の作成・削除を行う

ときにはバックアップを取得します。

WASの構成情報のバックアップを行うには、backupConfigコマンドを使用します。このコマンドを実行することにより、構

成リポジトリー情報である<profile_root>¥configディレクトリ配下のサブフォルダ、ファイルをzipファイルにアーカイブしま

す。backupConfigコマンド実行時にバックアップファイル名を指定することも可能です。バックアップファイル名を指定しな

い場合はコマンドを実行したディレクトリーに「WebSphereConfig_yyyy-mm-dd.zip」という名前で作成されます。

backupConfigコマンドのオプション機能の詳細については、下記 InfoCenter をご参照ください。

「backupConfig コマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rxml_backupconfig.html

backupConfigコマンドの使用における注意点として、以下のような点があります。

・構成リポジトリー以外にもバックアップが必要なファイルがあります。

・ DMとそれぞれのノードで個々にバックアップが必要です。backupConfigコマンドで取得したバックアップ情報はホスト

名/IPアドレスが異なるマシンではリストアできませんので、複数マシン構成の場合、それぞれのノードでバックアップを

行う必要があります。また、DMとノード・エージェントが1台のマシンに同居している場合でも、DMの構成リポジトリーの

バックアップとノードの構成リポジトリーのバックアップをそれぞれ行う必要があります。

・バックアップ取得時には、自動的に各ノードのDM、ノード・エージェント、アプリケーション・サーバーのプロセスが停止

されます。backupConfigコマンドの-nostopオプションを使用して、プロセスを停止せずにバックアップを取得することもで

きますが、バックアップ取得時にマスター構成リポジトリーが変更されると不整合が発生し、リストアできませんので、注

意が必要です。

・バックアップ取得時に停止されたプロセスは自動的には起動しませんので、バックアップ終了後、手動で起動する必

要があります。

・セキュリティが有効な場合は、-user/-passwordオプションを使って認証を行います。

backupConfigコマンドを使用する以外にも、WASが導入されているディレクトリーをZIPなどで全てバックアップする方法

もあります。

107


107

リストア方法

restoreConfigコマンドを使用

– backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元

– 使用方法： restoreConfig <backup_file> [options]• 例： <profile_root>¥bin¥restoreConfig myBackup.zip

– 注意点

• 構成リポジトリー以外のバックアップファイルの復元も必要

• 同一ホスト名のマシンに対してのみリストア可能

BackupFile(.zip)

hostA

backupConfig

restoreConfigホスト名の異なるマシンにはリストア不可能！

hostB

WASの構成情報のリストアを行うには、restoreConfigコマンドを使用します。このコマンドを実行することにより、

backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元します。リストア時には、リストア対象

ファイルを必ず指定してください。

restoreConfigコマンドのオプション機能の詳細については、下記 InfoCenter をご参照ください。

「 restoreConfigコマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_restoreconfig.html

restoreConfigコマンドの使用における注意点として、以下のような点があります。

・構成リポジトリー以外のバックアップファイルの復元も必要です。

・リストアは同一ホスト名のマシンにおいてのみ可能です。

既存の構成ディレクトリが存在している場合、既存のディレクトリの名前が変更されてから復元が開始されます。実行例

では既存の<profile_root>¥configディレクトリが<profile_root>¥config.old_1に変更されてから復元が始まっています。

108


108

予防保守：FixPackの適用

予防保守の観点から、WAS関連のコンポーネントを新レベルにすることをお勧めし

ます。

以下の4つのコンポーネントに対して、忘れずにFix Packを適用してください。

– WebSphere Application Server （WAS）

– JDK

– IBM HTTP Server

– Webサーバー・プラグイン忘れがちなので注意！

IBM HTTP Server (IHS)

プラグイン

WebSphere Application

Server (WAS)

WebSphere Application

Server (WAS)

JDK

クライアント

Update Installerというツールを

使用してFixを適用します。

Update Installerも新のもの

をダウンロードしてご利用くださ

い。

Feature Packが適用されている場合，別途対応したFixpackを適用する必要がある場合があります。

EdgeコンポーネントやアプリケーションクライアントのFixpackも別途配布されています。

109


109

キューイング・ネットワーク

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連

するコンポーネントをキューイング･ネットワークと呼ぶ

キューイング･ネットワークに関連するパラメーターを調整し、大スループットを達成することがパフォーマンスチューニングの第一歩

DB

ブラウザー

Webコンテナスレッドプールサイズ

ORBスレッドプール･サイズ

Webサーバー MaxClients / ThreadPerChild

データソース大接続数

WebコンテナASWebサーバー

EJBコンテナAS

それぞれの入り口で待ち処理が発生するように絞り込むように調整

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連するコン

ポーネントをキューイング･ネットワークと呼びます。キューイング･ネットワークに関連するパラメーターを調整し、大ス

ループットを達成することがパフォーマンスチューニングの第一歩になります。

キューイング･ネットワークでは原則クライアントに近い側の同時接続パラメーターを大きく、リソース･マネージャーに近

い側を小さく設定します。これによりシステムが過負荷にならない、かつ各コンポーネントは適量の待ち処理を継続処理

できるようにしてスループットを大化することが出来ます。

110


110

要求メトリックからレスポンスタイムの取得要求メトリック

– 要求メトリックをONに設定すると各コンポーネントのレスポンスタイム・処理時間がログに出力

– どのコンポーネントの処理で遅延が発生しているかを判断

[09/03/15 14:19:07:266 JST] 00000030 PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=1,event=1 -current:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=2,event=1 type=JDBC detail=SELECT * from staff elapsed=3125[09/03/15 14:19:07:469 JST] 00000030 ServletWrappe A SRVE0242I: [JvmHandsOn] [/JVM] [/output.jsp]: 初期化が正常に行われました。[09/03/15 14:19:08:172 JST] 00000030 PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.170.251.57,time=1129785472812,pid=2968,reqid=0,event=1 -current:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=1,event=1 type=URI detail=/JVM/TableViewer elapsed=14313

SystemOut.log

各コンポーネントのレスポンスタイムが記録されるので、その差に注目差が大きいところに多くの時間を取られていることになる

リクエスト全てに書き込みを行うと、要求メトリックによる出力自体がパフォーマンスに影響を与える可能性があるので、フィルターにより対象となるリクエストのみ出力させる

DB接続のレスポンスタイム

Webコンテナーでのレスポンスタイム

WASの要求メトリックの機能を使用すると、各々のコンポーネントでのレスポンスタイムがログに出力されるため、レ

スポンスタイムで多くの時間を取られているリクエストがどのコンポーネントで遅くなっているのかを判断することができます。出力先に関して、プラグインはhttp_plugin.logに出力され、その他はSystemOut.logに出力されます。

ここではレスポンスタイムの差に注目します。その差が大きいところで遅延が発生していることがわかります。ただし、

リクエスト全てに書き込みを実行すると、ログへの書き込み自身がパフォーマンスに影響を与える可能性があるので、

本番環境で取得が必要な場合は、必ずフィルターにより取得対象を絞って出力させるようにします。

要求メトリックを有効にしている場合、それ自体がパフォーマンスに影響を与える可能性があるので、基本的に、パ

フォーマンステストの際は使用せず、パフォーマンステストで問題があった場合にボトルネックを見つけるための手

段として使用します。また、フィルターにより対象となるリクエストを絞ることもできます。

111


111

要求メトリックで出力される項目

Webサーバー・プラグインがクライアントに送信されたレスポンスのバイト数bytesOut

Webサーバー・プラグインが受け取ったリクエストのバイト数bytesIn

トータルの経過時間（ミリ秒）で、子の経過時間を全て含んだ時間elapsed

リクエストの詳細データで、URIのフルパス、SQLステートメント、EJBメソッド名などdetail

リクエストのタイプ

HTTP、URI、EJB、JDBC、JMS、非同期ビーン（COMMONJ_WORK_POOLED、COMMONJ_TIMER）、Webサービスがサポ

ート

type

実際のトレースを区別するために割り当てられるイベントIDevent

要求メトリックがリクエストに割り当てるIDreqid

アプリケーション・サーバーのプロセス開始時刻time

アプリケーション・サーバーのプロセスIDpid

アプリケーション・サーバーがあるノードのIPアドレスip

親と子の相関関係のバージョン、親子の両者は同じ数字になりますver

呼び出された側(子)の識別子current

呼び出し側（親）の識別子parent

説明フィールド

要求メトリックの機能でログに出力される項目です。

112


112

モニタリング・ツール : Tivoli Performance ViewerWASが提供するパフォーマンス・モニタリングの仕組み

各種のシステム測定値を取得し、管理コンソールに結果を表示

ユーザーが取得するコンポーネントおよびレベルを選択可能

• Servlet/JSP平均応答時間

• Servlet/JSPリクエスト数

：

Webアプリケーションセッション・マネージャー

• アクティブ・セッション数

• セッション・サイズ

• 無効セッション数

：

EJB Module• EJB応答時間

• EJBリクエスト数

：

DB接続プール

• 使用ﾌﾟｰﾙ%• 平均待ち時間

：

JVM Module• ヒープサイズ

• GC統計情報

：

スレッド・プール

• プール・サイズ

• アクティブ・スレッド数

：

Transaction Module• アクティブ・トランザクション数

• トランザクション・タイムアウト

：

servlets

JSPs

HTTPClient

HTTPSession

SessionEJB CMP Database

EntitySession

EJBsJVM

WASではアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークとしてPMI（Performance

Monitoring Infrastructure）を提供しています。WASでは各リソースの様々なパフォーマンスデータをMBeanに格納してお

り、PMIはこのMBeanと通信して必要なパフォーマンスデータを取得します。パフォーマンス・データを格納している

MBeanは複数あり、それぞれ固有のデータを持っています。Tivoli Performance Viewer (TPV)はこのPMIを介して、WAS

の各リソースのパフォーマンス・データを取得しています。

また、TPVはScalable Vector Graphics (SVG) を使用してグラフィックなデータを表示します。（ブラウザーにScalable

Vector Graphics (SVG) プラグインがされている必要があります。）

TPVは管理コンソールの一メニューとして使用可能で、ブラウザー・アクセスが可能なクライアントであればアクセスでき

るようになっています。

TPVにアクセスするためには「モニターおよびチューニング」→「Performance Viewer」からアクセスします。TPVには［現

行アクティビティ］と［ログの表示］の二つのモードがあります。どちらかを選択した上で、TPVとしてモニターするプロセス

を選択します。この際にチェックを付けることで複数のプロセスの情報を取得開始することも可能ですが表示は一プロセ

ス単位になります。管理コンソールからログオフするとモニターは停止します。

113


113

Tivoli Performance Viewer で取得できるデータ

ポートレット・アプリケーションに関する情報ポートレット・アプリケーション

アプリケーション・サーバーのSIPContainerni関する情報SipContainerModule

SIBサービスに関する情報SIBサービス

DCSスタックを使用した送信メッセージ数など、DCSに関する情報DCS統計

HAマネージャーに関する情報HA マネージャー

スケジューラーサービスに関する情報スケジューラー

オブジェクトプールに関する情報オブジェクト・プール

アラームに関する情報アラーム・マネージャー

CPU使用率など、マシン(ノード)に関する情報（複数のサーバー・バージョンのノード・エージェントでのみ使用可能）システム・データ

同期要求の数など、Webサービスゲートウェイに関する情報Webサービスゲートウェイ

ロードされたWebサービスの数など、Webサービスに関する情報Webサービス

メモリ内のキャッシュサイズなど、動的キャッシュサービスに関する情報動的キャッシング

IIOP要求の数など、クライアントとサーバーのワークロード管理に間する情報ワークロード管理

オブジェクト参照ルックアップ時間などORBに関する情報ORB

ロードされたサーブレットの数、サーブレット要求の応答時間など、選択されたサーバーの情報Webアプリケーション

アクティブ・トランザクションの平均数など、トランザクションマネージャーのパフォーマンス情報トランザクション・マネージャー

オブジェクトリクエストブローカー (ORB) スレッドのスレッドプール、HTTP要求を処理するWebコンテナープールについての情報スレッドプール

アクティブなセッションの平均数など、HTTP セッションの使用状況サーブレット・セッション・マネージャー

使用メモリなどJVMに関する情報JVMランタイム

JCAについての使用情報JCA接続プール

新規に作成された接続数など、データソースの接続プールについての使用情報JDBC接続プール

応答時間やライフサイクルのアクティビティ、Enterprise BeanメソッドおよびEnterprise Beanによって使用されるリモートインターフェー

スの情報

エンタープライズBean

取得情報カテゴリ

こちらはTPVで取得可能な情報の一覧です。PMIで取得可能なデータはカテゴリで分類されており、そのカテゴリと

取得できる情報の例を示しています。またカテゴリはその中でさらにサブカテゴリに分類されるものもあります。取得

データ一つ一つについての詳細な情報は、統計セットから「カスタム」を選択すると参照することが可能です。

114


114

アドバイザー

アドバイザー

– アドバイザーを利用することでアプリケーション・サーバーのパフォーマンスを改善するための様々なヒントを取得可能

– 二つのアドバイザー機能は共にPMIから元データを収集

• ランタイム・パフォーマンス・アドバイザー（Performance and Diagnostic Advisor）

• Tivoli Performance Viewer アドバイザー

– 目的に応じてどちらのアドバイザーを使用するかを選択

これまでのアドバイザーより有用なアドバイスを行なってくれます。ただし、“大きなお世話”と思うようなアドバイスもあるかもしれません。

PMIという情報収集基盤から取得するデータを元にして、WASの運用に関するアドバイスを行なう機能が二つあり

ます。以前からアドバイザー機能はありましたが、バージョンがあがってくるにつれて、製品としてこれまで培ったベ

スト・プラクティスを反映してきたことで段々と的確なアドバイスを提供するようになって来たと言われています。

115


115

JVMの役割-メモリ管理

JavaではJVMがメモリ管理を実施

– 不要になったオブジェクトをメモリ領域から開放

– アプリケーション開発者のメモリ管理作業を軽減、ソフトウェア品質の向上

• 参照されないオブジェクトが残ってしまうことによるメモリリークの回避

• まだ参照されているオブジェクトを消去してしまうランタイムエラーの回避

– GC処理中は全てのアプリケーション・スレッドは停止

– GCはアプリケーションのパフォーマンスに影響

• JVMが適切にGCを実施するよう調整が重要

ガーベージ・コレクション（GC）

重要

Merit

メモリー空間

必要なｵﾌﾞｼﾞｪｸﾄ必要な

ｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

JVMの重要な役割として、メモリ管理があります。Javaでは、一般にガーベッジ・コレクション (GC) と呼ばれる、不要に

なったオブジェクトをメモリ領域から開放する作業をJVMが行っています。

これにより、アプリケーション開発者は煩雑なメモリ管理のコードをプログラム中に記述する必要がなくなります。また、

参照されないオブジェクトがメモリ内に残ってしまうことによるメモリリークや、逆にまだ参照されているオブジェクトを消

去してしまうことにより発生するランタイムエラーなどのバグを回避することができますので、ソフトウェア品質の向上す

るという利点があります。

GCはアプリケーションのパフォーマンスに影響を与えますので、JVMが適切にGCを処理を行うように設定することが重

要です。

116


116

JVM ヒープサイズの調整

JVMが使用するメモリ領域

– Java heap• クラスやインスタンスのオブジェクトが格納

• Garbage Collectionの対象エリア

– Native heap• JVMの起動時に常に参照される、システムや共有プログラムのクラス

オブジェクトが格納

– アプリケーションサーバーの「初期ヒープ・サイズ」「大ヒープ・サイズ」などを調整

Garbage Collection実行状況のロギング

– 「冗長ガーベッジ・コレクション」オプションをチェックするあるいは、JVM引数に–verbose:gcを指定することによって出力される

– native_stderr.logに出力される

– ヒープ使用状況把握に有用

• 出力ONに設定することを推奨

ヒープサイズの設定値によってGCの処理時間や間隔を調整ヒープサイズの設定値によってGCの処理時間や間隔を調整

Heapとは、JVM、つまりJavaアプリケーションが使用できるメモリ領域です。HeapはJava heapとNative heapの2種類の

領域に分かれます。

Java heapはオブジェクトが格納されるメモリ領域であり、GCの対象エリアになります。

Native heapはJVMの起動時に常に参照される、システムや共有プログラムのクラスオブジェクトが格納されるメモリ領

域であり、GCの対象になりません。

Java heapの小サイズ・大サイズは、JVM引数 (WASでは、管理コンソール上の設定)で、設定することができます。

管理コンソールで「アプリケーション・サーバー」＞（サーバー）＞「プロセス定義」＞「Java仮想マシン」から設定すること

が可能です。

実際のWASの環境においては、各アプリケーション・サーバーがそれぞれ異なるJVMを起動していますので、それぞれ

別々のheap領域を確保する必要があります。

このヒープサイズの小・大サイズによってGCの間隔や処理時間を調整し、GCがパフォーマンスに与える影響を少

なくします。

一般に、ヒープを大きく設定すると、GCが発生するまでの間隔は長くなりますが、GCにかかる時間が長くなりますので、

環境に合わせて調整が必要となります。

GC状況をモニタリングするには、同じく「Java仮想マシン」の画面で、「冗長ガーベッジ・コレクション」オプションをチェック

します。あるいはJVM引数に-verbose:gcを指定します。GC状況ははJVMのプロセスログのエラー出力

（native_sderr.log）にロギングされます。「冗長ガーベッジ・コレクション」はデフォルトでOFF（チェックなし）になっています

が、ヒープの使用状況を把握するためにONに設定することが推奨されます。

コマンドラインオプションが長くなる場合は、別ファイルにオプションを記述し、-Xoptionsfileで指定することもできます。

117


117

プラグインの管理

プラグイン構成ファイルの更新/生成

– Webサーバー・プラグインは、構成変更が発生した場合、更新が必要

– 更新/生成方法

• 管理コンソール– Webサーバーの「プラグインの生成」ボタンをクリック

• wsadmin• コマンド行ツール(GenPluginCfg.sh)

– DMノードで実行 →セル内の全ノード分の情報を含むプラグイン構成ファイルが生成

– ASノードで実行 →そのノードのみの情報を含むプラグイン構成ファイルが生成

管理コンソールを使用したプラグイン構成ファイルのプロパティー値設定

– [サーバー]-[Webサーバー]-[web_server_name]-[プラグイン・プロパティー]• 構成新表示間隔、プラグイン構成ファイルの自動生成/自動伝搬、プラグイン鍵ストア・ファイル名、プラ

グイン・ロギング、ロード・バランシング、再試行間隔、などを設定可能

– [サーバー]-[アプリケーション・サーバー]-[application_server_name]-[Webサーバーのプラグイン・プロパティー]• 接続タイムアウト、読み取り/書き込みタイムアウト、接続大数の使用、などを設定可能

次のような場合は、プラグイン構成ファイルの更新と伝搬が必要となります。

・新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合

・サーブレットに対するURLマッピングの定義など、URIに変更があった場合

・新しいクラスターが追加され、ルーティング方法が変更になった場合

・ポート番号が変更になった場合

・仮想ホストの追加や修正があった場合、など。

プラグイン構成ファイルの更新/生成方法は管理コンソールとwsadminとコマンド（GenPluginCfgコマンド）の3つの方法が

あります。

GenPluginCfgコマンドによる更新/生成は、実行するノードによって出力が異なるので注意ください。

プラグイン構成ファイルの伝搬方法などについては、「 5章ワークロード管理」も参照してください。

正しくリクエストが割り振られていない場合のチェック項目として、いくつか挙げます。

・上記の修正が入った場合に、正しくプラグイン構成ファイルが更新、伝搬されているかどうかを確認します。

・ Webサーバーの構成ファイルhttpd.confの中に記述されているプラグイン構成ファイルplugin-cfg.xmlの位置は正しく設

定されているかどうかを確認します。

・ plugin-cfg.xmlファイルを手で書き換えている場合、デプロイメント・マネージャーの構成ファイル同期サービスにより、

Webサーバー・プラグイン構成の更新で生成された状態に戻ってしまうことがあります。

・製品の障害などを修正するためのFixなどもありますので、新版があたっているかどうかも確認します。

またプラグインに関連するパラメーターは管理コンソールから設定可能です。プラグイン側の設定とWAS側の設定の2つ

の設定箇所があります。

118


118

パフォーマンス・チューニングのヒント

TPVや要求メトリックなどのパフォーマンス・モニタリングツールを活用し、ボトルネックとなってい

るコンポーネントを特定

– 要求メトリック：コンポーネント毎の処理時間をログ出力する機能

ボトルネックとなっているコンポーネントのチューニング

Webコンテナー

– スレッドプール

– セッションオブジェクト

• 大セッションカウント、オーバーフロー許可

• 書き込み頻度（セッション・パーシスタンス）

– モジュール設定

• プリコンパイルJSPオプション

EJBコンテナー

– Pass by reference

– ORBスレッドプール

– MDBの同時並行数（JMSアクティベーションスペック）

データベース接続

– 接続プール

• 大・小接続数、各タイムアウト値

– PreparedStatementキャッシュサイズ

JVM– JVMの初期ヒープサイズ・大ヒープサイズ

– GCポリシー

各コンポーネントのチューニングポイント各コンポーネントのチューニングポイント

パフォーマンス・チューニングを行う場合は、TPV(Tivoli Performance Viewer)や要求メトリック（コンポーネント毎の処理

時間をロギングするWASの機能）などのモニタリングツールを活用し、ボトルネックとなっているコンポーネントを特定し

ます。そして、そのコンポーネントのチューニングを検討します。場合によっては、特にデータベース接続処理がボトル

ネックの場合は、WASだけではなく、DBMSやWAS上のアプリケーションを含めて精査する必要もでてきます。（接続プー

ルの増加は、多くの場合、プログラムが正常に終了処理を行っていないことが原因のことが多いです。）

○Webコンテナー

スレッド・プール数は多すぎても少なすぎてもパフォーマンスに悪影響を与えますので、適切な値に近づけられるよう検

討します。またセッションオブジェクトはメモリー上に格納されるため、ヒープに影響を与えうるので調整が必要です。

また、モジュールに設定するプリコンパイルJSPオプションのように、事前にJSPコンパイル処理を行い、初回のリクエス

トから応答時間の短縮を図るようなパラメータ設定もあります。

○EJBコンテナー

EJBクライアントとEJBが同一のクラス・ローダーから読み込まれる場合（つまり同一EAR内にパッケージされている場

合）は参照渡しを行なうことでパフォーマンスを向上できるPass by referenceの設定があります。Webサーバーと同様に、

処理スレッドであるORBスレッドプールの調整も必要です。また、MDBを稼働する場合は、同時並行処理数を調整しま

す。

○データベース接続

接続プール数は、通常時は小接続数で対応し、ピーク時に大接続数で対応するように設定できるのがよいです。

プール内のコネクションオブジェクトの使用率が100％の状態が続き、接続待ちや、接続タイムアウトによるエラーとなっ

たリクエストが多い場合は、アプリケーションプログラムの見直し、DBMSのパフォーマンスの確認とともに、接続プール

の大接続数の増加を検討します。

PreparedStatementキャッシュを利用することで、 PreparedStatementを再利用することができます。例えば、DB接続

プール・サイズが5で、各アプリケーションで2つのPreparedStatementを使用する場合は、 PreparedStatementキャッシュ

を10などにして変化をモニタリングしてみます。

○JVM

JVMヒープ使用状況は「冗長ガーベッジ・コレクション」（verbose:gc）をONにし、出力ログをモニタリングしながら決定して

いくことをお勧めします。

ヒープを大きく割り当てることによって、スループット向上の効果も考えられますが、その一方、ガーベッジ・コレクション

による停止時間が長くなることにより大レスポンスタイムが増加する可能性もあります。

119


119

ランタイム・プロビジョニング

起動時はアプリケーション・サーバー上のアプリケーションが必要とする小限のコンポーネントのみをロード

アプリケーション・サーバーの起動時間の短縮

アプリケーション・サーバーのHeap使用footprintを削減

例) サーバー上の全てのアプリケーションはServlet、JSPのみを使用

Webコンテナー

EJBコンテナー

Web Services

SIPコンテナー

セキュリティー


その他．．．

WAS V6.1

全てロード

Webコンテナー

EJBコンテナー

Web Services

SIPコンテナー

セキュリティー


その他．．．

WAS V7.0

必要なものをロード

WASランタイムのパフォーマンスを向上させる機能として、V7からランタイム・プロビジョニングという機能が追加されました。V6.1まではアプリケーション・サーバーが起動する際、WebコンテナーやEJBコンテナーなど全てのWAS内部コンポーネントを起動して

いました。V7ではランタイム・プロビジョニング機能をONにすると、対象アプリケーション・サーバー上のアプリケーションや設定か

ら必要なWAS内部コンポーネントのみを起動するようになりました。例として、アプリケーション・サーバー上にデプロイしている全

てのアプリケーションがServlet、JSPのみで構成されている場合、EJBコンテナーやWeb Serviceコンポーネントなどは起動されま

せん。これにより、平均して10%程度アプリケーション・サーバーの起動時間が短縮され、Heap使用量も減少させることができます。

このランタイム・プロビジョニングはデフォルトOFFで、デプロイメント・マネージャーやノード・エージェント、AdminAgent、Job Managerといった全てのJVMで設定できます。

120


120

ランタイム・プロビジョニング設定詳細

管理コンソールで下記項目を選択

– サーバー -> サーバー・タイプ -> アプリケーション・サーバー -> [サーバー名]

｢必要に応じてコンポーネントを開始｣にチェックしてアプリケーション・

サーバーを再起動

– デフォルト設定ではOFF

ランタイム・プロビジョニングの設定手順を紹介します。対象サーバーの設定画面で、｢必要に応じてコンポーネントを開始｣オプ

ションにチェックを入れ、対象サーバーの再起動をおこないます。

121


121

参照の圧縮 (Compressed references)

WAS V6.1では64bit版が32bit版と比較してヒープ使用量が60%程度増加

– 64bit版ではオブジェクト参照のポインターが8バイト（32bit版の倍）

WAS V7.0 64bit版ではポインターを圧縮することによって必要なヒープ使用量を削減す

る機能を実装

– ランタイムは内部で 32bit 参照と 64bit ポインタを変換

– 64bit IBM JDK において、ヒープサイズが約29GB以下（プラットフォームごとに異な

る）の場合に利用可能

• Solaris 64bit JVM、HP-UX 64bit JVM、iSeries Classic 64bit JVMではサ

ポートされない

デフォルトは使用不可

– 有効化するには –Xcompressedrefs オプションを使用

V6.1では64bit版が32bit版と比較してヒープ使用量が多く、比較すると60％程度増加する傾向にありました。これはオブジェクト

参照のポインターサイズは32bit版が4バイトであるのに対して64bit版では8バイトであるのが大きな原因でした。

V7でもV6.1と同じく64bit版のヒープ使用量の方が32bit版よりも同程度大きくなりますが、これに対する機能として参照の圧縮

(Compressed references)が導入されています。これは文字通り64bit版の8バイトの参照を4バイトに圧縮する機能でヒープ使用

量の削減に効果があります。

ただし、ヒープサイズが29GB以下(サイズはプラットフォーム依存)の場合に限られ、Soraris 64bit JVMなどサポートされないプ

ラットフォームもあります。

この機能はデフォルトでは使用不可となっており、JVM汎用引数に-Xcompressedrefsを指定することによって有効化できます。

WAS V7 InfoCenter - Tuning the IBM virtual machine for Javahttp://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html

122


122

32bit版 vs 64bit版大きなヒープを確保する必要があるときは64bit版を使用

– 32bit版では使用できるヒープ容量に限界がある。

• AIXの場合は3.2GB。これ以上のヒープを使用する場合は64bit版を選択する必要がある。

ヒープ消費量の観点では32bitの方が有利

– 同一アプリケーションのヒープ使用量を見た場合、64bit版は32bit版と比較して使

用量が増える傾向にある

• 約60%程度増加する傾向にある– 参照の圧縮(Compressed references)の使用

• この機能を用いることによって64bit版のヒープ消費量を

軽減することが可能

• ただしCPU使用率は若干増加

32bit版と64bit版の選択ポイントです。

まず一つ目のポイントは大ヒープサイズです。32bit版では使用できる大ヒープサイズが64bit版と比較するとかなり小さくな

ります（32bit版 AIXの場合は3.2GB）。32bit版の大値を越えるヒープを使用したいときには64bit版の選択を考える必要があり

ます。

次のポイントはヒープ使用量です。ヒープ使用量の観点では32bit版の方が有利です。物理メモリが少なく、なるべくヒープ使用

量を抑えたい場合などは32bit版の使用を考えてください。またV7になって64bit版に参照の圧縮機能が追加されています。こちら

も使用ヒープ量を抑えることが可能ですが、有効にすると若干CPU使用率が増えることになりますので、ご注意ください。

123


123

共有クラスキャッシュ

共有クラスキャッシュとは

– 複数のJVM間で共通して使用するクラスを共有できるようにする仕組み

– JVMの起動時間の縮小と使用メモリのフットプリント減少に効果

– IBM SDK for Java 5 (WAS V6.1) で導入

– デフォルトでは有効

• JVM引数に-Xshareclasses:noneを指定することで無効にできる

Class Memory Segments

JVM 1

ディスク上のクラス

Heap領域

JITコードキャッシュ

Class Memory Segments

JVM 2 Heap領域

JITコードキャッシュ

JVMの使用するメモリ

重複するクラスを共有

124


124

WAS V7の共有クラスキャッシュ機能強化

共有キャッシュの永続化

– IBM SDK for Java 6ではOS再起動をまたいで共有クラスキャッシュの情報を保持することが可能

• IBM SDK for Java 5ではOS再起動の際にキャッシュ情報は消去されていた

– JVM汎用引数で設定

• 有効 -Xshareclasses:persistent• 無効 -Xshareclasses:nonpersistent

（プラットフォームによってデフォルト値は異なります）

アプリケーション・サーバーの起動時間の短縮使用メモリのフットプリントの削減

AOT (Ahead of Time) によるコードの保管

– AOTコンパイル技術による、共有クラス・キャッシュに保管できるネイティブ・コードの作成機能

– AOTコードはネイティブ・コードであるため、一般には実行に要する時間が短縮

– JVM汎用引数で設定

• デフォルトは有効– 共有クラスキャッシュにAOTコードを保管する領域のサイズをJVM汎用引数で調節可能

• 無効 –Xnoaot

AOT : JITコンパイルコードよりは実行時間は短縮されません.

125


125

構成ファイル群

プロパティー・ファイル・ベース構成ツール

プロパティー・ファイル・ベース構成ツール

– Property File Based Configuration Tool ⇒ 略して「PFBCT」

– 構成ファイルから名前/値が対になったプロパティー・ファイルを抽出

– プロパティー・ファイルの値を変更して構成ファイルに適用

– PFBCTはAdminTaskオブジェクトのコマンド群

– プロパティー・ファイルの一部を変数化して変更後の値を記入したVariableMapを使用して適用することも可能

Property_name = “foo”

Scope = Server

Name = “server1”

maximumHeapSize=128

requestTimeout=!{requestTimeout}

# ---------------------------

# comment line

# ---------------------------

requestTimeout=100

構成ファイル群変更 / 変数化したプロパティー・ファイル

VariableMap

Property_name = “foo”

Scope = Server

Name = “server1”

maximumHeapSize=128

requestTimeout=180

# ---------------------------

# comment line

# ---------------------------

PFBCT

抽出されたプロパティー・ファイル

PFBCT

WASV7の新機能として、プロパティー･ファイル･ベース構成ツール(PFBCT) という管理ツールが提供されています。

WASの構成ファイルは構成リポジトリー内の複数のサブ･ディレクトリーにXMLとして分散されて配置されており、特

定のプロパティー値を構成ファイル群から見つけ出すのは容易なことではありません。PFBCTは、構成ファイル群

からプロパティー名と値が対になった、ユーザーにとって現行の構成ファイルよりも分かりやすいプロパティー･ファイ

ルを作成します。ただし、このプロパティー･ファイルは構成ファイルではないため、プロパティー･ファイル内のプロパ

ティー値を変更しただけでは構成変更に反映されません。プロパティー値を変更後にプロパティー･ファイルを構成に

適用する、という手順が必要になります。

プロパティー・ファイルの一部のプロパティー値を変数化して変更後の値を記入したVariableMapを使用して構成に

適用することもできます。変数は、「!{プロパティー名}」の形で記述します。複数のプロパティー値を調整しながら何

度も変更するパフォーマンス・チューニングなどの場合は、VariableMapのプロパティー値を変更して構成に適用す

ることで、毎回プロパティー･ファイルの中から該当のプロパティー値を探し出す必要がないので便利です。

PFBCTはAdminTaskオブジェクトのコマンド群であり、以下の4種類が提供されています。

・extractConfigProperties・・・構成データをプロパティー・ファイルの形式で抽出します。

・applyConfigProperties・・・あるプロパティー・ファイルのプロパティーを構成に適用します。

・deleteConfigProperties・・・プロパティー・ファイルに指定したように構成からプロパティーを削除すします。

・validateConfigProperties・・・プロパティー・ファイルのプロパティーが有効で構成に安全に適用可能か検証します。

プロパティー･ファイルには指定したオブジェクトおよびそのオブジェクトにネストされたオブジェクトのすべてのプロパ

ティーが抽出されます。例えばサーバーのプロパティーが抽出される際には、サーバー、アプリケーション･サーバー、Webコンテナー、EJBコンテナーなどのオブジェクトのプロパティーも含まれます。

PFBCTでサポートされるプロパティーの詳細に関しては、「運用設計-別紙-」のP.6をご参照ください。

126


126

PFBCTはAdminTaskオブジェクトのコマンド群

–コマンド･オプションとして以下の4種類を提供

• extractConfigProperties – 構成データをプロパティー・ファイルの形式で抽出

する

• applyConfigProperties – あるプロパティー・ファイルのプロパティーを構成

に適用する

• deleteConfigProperties – プロパティー・ファイルに指定したように構成から

プロパティーを削除する

• validateConfigProperties – プロパティー・ファイルのプロパティーが有効で構

成に安全に適用可能か検証する

プロパティー･ファイル･ベース構成ツール

PFBCTはAdminTaskオブジェクトのコマンド群であり、上記の4種類が提供されています。

各コマンド･オプションの詳細は以下のInfoCenterの記載をご参照ください。

WAS V7 InfoCenter「PropertiesBasedConfiguration command group for the AdminTask object」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rxml_7propbasedconfig.html

.

127


127

プロパティー･ファイル･ベース構成ツールサポートされるプロパティー

これらの構成タイプのプロパティーが抽出される際は、そのオブジェクトおよびネストされたオブジェクトのすべての属性が抽出され、プロパティー・ファイルに書き出される。

プロパティー・ファイルにはセクションがあり、各セクションが一つのオブジェクトのプロパティー群を保持する。ネストされたオブジェクトのプロパティーはサブ・セクションにリストされる。

SIPContainerSchedulerProviderSecurityServerServerClusterTPVServiceTimerManagerProviderTransactionServiceURLProviderVariableMapVirtualHostWebContainerWebserverPluginSettingsWorkManagerProvider

JDBCProviderJMSProviderJavaVirtualMachineLibraryMailProviderNameServerNodeNodeGroupObjectPoolProviderObjectRequestBrokerPMEServerExtensionPMIModulePMIServicePortletContainer

AdminServiceApplicationApplicationServerAuthorizationGroupAuthorizationTableExtCellCoreGroupCoreGroupBridgeServiceDynamicCacheEJBContainerEventInfrastructureProviderEventInfrastructureServiceHAManagerServiceJ2CResourceAdapter

プロパティー･ファイルには指定したオブジェクトおよびそのオブジェクトにネストされたオブジェクトのすべてのプロパティーが抽出されます。例えばサーバーのプロパティーが抽出される際には、サーバー、アプリケーション･サーバー、Webコンテナー、EJBコン

テナーなどのオブジェクトのプロパティーも含まれます。

128


128

集中インストール・マネージャー（CIM）

デプロイメント・マネージャーが、セル内のノードに対して修正モジュール等を一元的にインストール可能な機能

– Centralized Installation Manager => 略してCIM

– ND環境のみでサポートされ、インストールはセル内のノードを選択することも、全てに対して実

施することも可能

– エージェントは不要、目的のホストに対しPush形式でインストール

– インストール対象

• WAS V7 NDモジュール、WAS V7 RefreshPack/FixPack/iFix、Update Installer• WAS V6.1 RefreshPack/FixPack/iFix(混合セル環境のみ)


ノードA

ノードB

ノードC

インストール

セル

管理者インストール

インストール

集中インストール・マネージャー・リポジトリー

WAS V7ではインストールおよびFix適用作業がより簡単になる機能として、集中インストール・マネージャーが追加されました。

集中インストール・マネージャーはこれまでWebSphere XDで利用可能でしたが、WAS V7からWASの基本機能として追加されま

した。この集中インストール・マネージャーはND環境のみでサポートされ、インストール先はセル内のノードになります。インストー

ル対象は、WAS V7 NDモジュール、WAS V7のFix、WAS V7のUpdate Installer、WAS V6.1のFix（V6.1は混合セル環境のみ）

になります。インストール時はセル内のノード全てを選択することも、個別にノードを選択することもできます。インストール先ノードにエージェントは不要であり、複数台同時にFixを適用する際などは大変便利な機能になります。

129


129

練習問題

16. 集中インストール・マネージャー（CIM）を使用してインストールできるものは次のどれですか（複数）。

A) WAS NDモジュール

B) IBM HTTP Serverモジュール

C) FixPack

D) IBM HTTP Server プラグイン

17. WASのパフォーマンス・チューニングの観点から、各コンポーネントのうちWebコンテナーを確認するとき見る

べき項目は次のうちどれですか。

A) スレッドプール

B) ORBスレッドプール

C) GCポリシー

D) 接続プール

18. wsadminスクリプトでできることは以下のうちどれですか。

A) 冗長ガーベッジ・コレクションを実行可能にする

B) Javaコアの取得

C) アプリケーション・サーバーの作成

D) 上記全て

130


130

7章問題判別

131


131

ログの種類 (1)

JVMログ (SystemOut.log / SystemErr.log)

WASログ

プロセス（AS/DM/NA）単位のログ

プロセスログ (native_stdout.log / native_stderr.log)

IBM保守ログ(activity.log)

FFDCログ (<process_name>_<timestamps>.log)

ノード単位のログ

JVMログに詳細な情報を追加したログ。

JVMの標準出力および標準エラー出力。ログ解析の基本。

ネイティブ・コードやJVM自身の出力が書き込む情報の出力先JVMのverboseGC出力はnative_stderr.logに記録される。

First Failure Data Captureとはエラー情報を発生時に自動記録する機能。サポートセンター、開発部門が障害対応時に見るログ。

循環ログ

構成不可

RAD AD

HTTPトランスポートログ (http_access.log / http_error.log)ASのWebコンテナのHTTPトランスポートに対するアクセスを記録するログ。管理ポートに対しても記録が可能。

問題解析の基本となるログは出力する製品および階層に応じて複数の種類があります。ここでは各ログの解説を行い

ます。WASのログにはノード単位およびプロセス単位のログがありますが、先にプロセス単位のログから解説します。

『JVMログ』はアプリケーションの挙動やプロセスの稼動状況を記載した解析の際にも参照する頻度の高いログファイ

ルで、ファイル名はSystemOut.logおよびSystemErr.logとなります。JVMログは各プロセス単位で存在し、それぞれのプ

ロセスの名前が付けられたディレクトリ（<Profile_root>¥logs¥<server_name>）に出力されます。JVMログには、それぞれ

のサーバーにおけるSystem.out.print()の実行結果である標準出力や標準エラー出力が記録されます。JVMログはサイ

ズもしくは時間で新規のファイルを自動作成する循環ログです。

『プロセス・ログ』はネイティブ・コードやJVM自身の出力が記録されます。ファイル名はnative_stdout.logおよび

native_stderr.logです。これらプロセスログはJVMログと同じディレクトリに出力されます。JVMのverboseGCを設定した場

合、その出力はnative_stderr.logに記録されます。プロセス・ログは循環しませんので運用の場合は注意が必要ですが、

JVMログに比べてファイルの増加率は小さいです。

『FFDCログ』のFFDCとはFirst Failure Data Captureの略で、全てのシステムエラー情報を発生時点で自動的に記録す

るツールです。このツールによって作成されたFFDCログは、サポートセンターや開発部門が障害時に見て分析を行うた

めのものです。ログはプロセス単位のディレクトリではなく、 <Profile_root>¥logs¥ffdcというディレクトリに出力されます。

ファイル名は<server_name>_<timestamps>.log（例：server1_5c655712_04.11.18.2327.48_0.txt）となります。サーバー起動

中に発生した例外情報の統計を管理する<server_name>_exception.logというログファイルも/ffdcディレクトリに作成され

ます。

『HTTPトランスポート・ログ』はアプリケーション・サーバーのWebコンテナーのHTTPトランスポート（ポート9080）に対する

アクセスを記録するログで、Webサーバーログと同等のものです。ファイル名はhttp_access.logおよびhttp_error.logです。

これらプロセスログはJVMログと同じディレクトリに出力されます。ログは管理ポート（ポート9060）に対しても取得するこ

とが出来ます。このログはデフォルトでは取得されないので、取得には設定が必要です。

プロファイル単位に作成される『IBM保守ログ』のファイル名はactivity.logです。これは<Profile_root>¥logsディレクトリに

出力されます。このIBM保守ログはJVMログに詳細情報を追加したログです。

132


132

ログのロケーション (1) WAS関連

プロファイル単位の/logsディレクトリ

WAS関連

/logs以下に/ffdcディレクトリ

IBM保守ログ

JVMログ

プロセス・ログ

/logs以下にサーバー単位のディレクトリ

HTTPトランスポートログ

FFDCログ

前項で解説したログの実際のロケーションを表したチャートです。

133


133

ログの種類 (2)

プラグイン・ログ (http_plugin.log)

IHSログ (access.log / error.log)

IHSログ

プラグインログ

クライアントがIHSにアクセスしたリクエストおよびリプライをaccess.logに記載。エラー情報はerror.logに記載。

Webサーバープラグイン・コンポーネントが記載するログ。WebサーバーとWAS間の通信に問題がある場合に参照。

『IHSログ』はWebサーバーをIHSとした場合に出力されるログです。ログには二種類あり、access.logはブラウザー・クラ

イアントなどがhttp/httpsでIHSにリクエストしてきたものに対し、IHSのリプライコードなどを記載します。これはヒットカウ

ントの集計などによく使用されるログです。error.logはリクエストのエラー情報、およびIHS自身のエラー情報を記載しま

す。これらのログはデフォルトで<IHS_root>¥logsに記載されますが、httpd.confの編集によりログのフォーマットやロケー

ション、レベル、ログ退避指定などを変更可能です。

『プラグイン・ログ』はWASプラグイン・コンポーネントが出力するログで、WebサーバーとWAS間の通信に問題があると思

われるときに参照して問題の解析を行うためのものです。ファイル名はhttp_plugin.logです。プラグイン・ログはプラグイン

の導入ディレクトリ下（<Plugin_root>¥logs¥<webserver_name>）に作成されます。プラグイン・ログは、プラグインの構成

情報を持つplugin-cfg.xmlファイル内で指定されてます。管理コンソールのプラグイン・プロパティの設定でプラグイン・ロ

グのレベルや出力先を変更することができます。

WebサーバーとしてIHSを使用している場合、IHSの構成ファイルhttpd.confの中のWebSpherePluginConfigディレクティブ

でplugin-cfg.xmlファイルの位置が指定されており、plugin-cfg.xmlファイルでプラグイン・ログファイルの位置が指定され

ています。

134


134

ログのロケーション (2)IHS、プラグイン関連

Pluginの/logsディレクトリにWebサーバー単位のディレクトリ

IHSの/logsディレクトリ

httpアクセス・ログ

httpエラー・ログ

プラグイン・ログ

IHS導入ディレクトリ

プラグイン導入ディレクトリ

前項で解説したログの実際のロケーションを表したチャートです。

135


135

ログの管理

ログ管理機能

– 管理コンソールの「トラブルシューティング」→「ログおよびトレース」からサーバーを指定して、各ログの循環設定、ファイル大サイズなどを設定可能

– JVMログでは切り替え（世代管理）も可能

• 使用中ファイル…SystemOut.log• 一世代前………. SystemOut_03_01.15_17.38.19.log

(SystemOut_yy_MM.dd_HH.mm.ss.log)• ログ切り替えは一定時間、一定サイズで行う

考慮点

– 本番稼働環境では、ファイルの大サイズやログ切り替え（世代交代）などの設定、さらに運用により、WAS停止の

タイミングでログを待避させる

– ログファイルが大きすぎると問題判別の際見づらくなるので、適切な大サイズ設定やこまめに待避させる運用を心がける

WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）から各ログの循環設定やファ

イル大サイズの指定などを行うことができます。

ログの世代管理も可能で、一定時間と一定サイズのどちらか、または両方を選択することができます。両方を選択した

場合は、両方のタイミングで循環が実行されます。また、ヒストリー・ログ・ファイルの大数として、残しておく過去のロ

グの数を指定することもできます。

また、「インストール済みアプリケーション出力」の設定によって、アプリケーションから出力されるSystem.outおよび

System.errのメッセージを抑制することも可能です。

システム管理者が考慮すべきログ管理としては、本番稼動環境におけるファイルの大サイズや世代交代の設定があ

ります。適切な大サイズ設定やこまめに退避させる運用を心がける必要があります。WASの稼動中にログを退避させ

ることはできませんので、循環されないログについてはWAS停止のタイミングでログを退避させる運用とします。

136


136

トレース(trace.log)<profile_root>¥logs¥<server_name>¥trace.log

WASのコンポーネントの詳細な実行内容を追跡可能

基本的にWASの開発部門の指示で問題の再現時に有効にする

コンポーネントとトレースの詳細レベルを指定

コンポーネントとトレースの詳細レベルを指定

ログの切り替え（世代管理）が可能

ログの切り替え（世代管理）が可能

WASではコンポーネントの詳細な実行内容をサーバーごとにトレースファイルに出力させることができます。

<Profile_root>¥logs¥<server_name>¥trace.logファイルに出力されます。コードを実行するたびに対象コンポーネントがト

レースに情報を出力するため、問題判別のためのイベントの追跡ができます。基本的に、トレースを出力させるのは

WASの開発部門の指示で問題の再現時であり、トレース内容はWASのテクニカルサポートの助けがないと内容を調査

することは難しいです。コンポーネントのソースコードをもとにトレースを分析すれば、問題がどのコンポーネントのどの

部分にあるかを絞り込むことができます。デフォルトでトレースは使用可能になっています。

WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「診断トレース」からトレー

ス・ログの切り替え設定（循環設定、世代管理）やファイル大サイズの指定などを行うことができます。

トレース出力フォーマットは、「基本（互換）」「拡張」「ログ・アナライザー」の3種類が選択できます。また上記管理コン

ソール画面の「ログを使用可能にする」のチェックをはずすとトレースは出力されなくなります。アプリケーション・サー

バーが稼動中であってもこの設定を変更することが可能です。「診断トレース・サービス」ページのランタイム・タブでの

変更はアプリケーション・サーバーが稼動中であっても可能で、「OK」ボタンによって反映されます。

「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「ログ詳細レベルの変更」からトレースの設定として

取得したいコンポーネントとイベントの種類を選択して設定することができます。

ログの詳細レベルは、「致命的(fatal)」「重大(severe)」「警告(warning)」「監査(audit)」「情報(info)」「構成(config)」「詳細-

低(detail)」「詳細-中(fine)」「詳細-高(finer)」「詳細- 高(finest)」の順に、出力レベルが詳細になります。デフォルトでは

「情報(info)」になっています。

トレース設定の詳細については、下記 InfoCenter をご参照ください。

「ログ・レベル設定」

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/utrb_l

oglevel.html

137


137

ログ / トレースのフォーマット

基本フォーマット

イベントタイプ

日付，時刻，タイムゾーンメッセージを出力したスレッドのID

イベントタイプメッセージIDコンポーネントの短縮名メッセージ

[05/10/10 16:26:53:785 JST] 0000000a WsServerImpl A WSVR0001I: e-business のためにサーバー server1 がオープンされました。

A：監視メッセージ

I：通知メッセージ

W：警告メッセージ

E：エラーメッセージ

F：致命的メッセージ

O：ユーザー・アプリケーションまたは内部コンポーネントによりSystem.outに直接書き込まれたメッセージ

R：ユーザー・アプリケーションまたは内部コンポーネントによりSystem.errに直接書き込まれたメッセージ

<：メソッドの開始

>：メソッドの終了

e：イベントのトレース項目

d：デバッグのトレース項目

m：ダンプのトレース項目

u：ASランタイムのメッセージ・ロギング・コンポーネントで使用される、特殊なメッセージまたはトレース

Z：認識不能

ログやトレースのフォーマットには、「基本フォーマット」と「拡張フォーマット」の2種類があり、どちらかを選択して設定す

ることができます。

基本フォーマットでは、ログに日付や時刻、メッセージを出力したスレッドID、コンポーネントの短縮名、イベントタイプ、

メッセージID、メッセージ内容が記録されます。拡張フォーマットでは、基本フォーマットで記録される内容に加えて、組

織名、製品名、コンポーネントの種類、UOW(作業単位)、コンポーネントの完全名が記録されます。

基本フォーマットのログにも拡張フォーマットのログにも、イベントタイプが記録されます。イベントタイプは1文字の英字

で表記され、起こったイベントのタイプを表します。メッセージ・タイプは大文字で表記され、トレース・タイプは小文字で表

記されます。

138


138

IBM保守ログ(activity.log)<profile_root>¥logs¥<server_name>¥activity.log

JVMログに詳細情報を追加したログ（バイナリ・ファイル）

– 大サイズを設定可能（デフォルト2MB)

以下のツールで閲覧可能

– showlog.bat(sh) コマンド

– Application Server Toolkit (AST)

• 「プロファイルおよびロギング」パースペクティブ

# <WAS_PROFILE_ROOT>/bin/showlog.bat(sh) <WAS_PROFILE_ROOT>/log/activity.logComponentId: Application Server(省略)TimeStamp: 2007-06-08 17:58:30.968000000UnitOfWork:重大度: 3カテゴリー: INFOPrimaryMessage: CWPKI0002I: SSL サービスの初期化が正常に完了しました。ExtendedMessage:

IBM保守ログのファイル名はactivity.logという名前でノード単位に作成されます。これは<PROFILE_ROOT>/logsディレク

トリに出力されます。このIBM保守ログはJVMログに詳細情報を追加したログで、showlog.bat(sh)コマンドやASTの「プロ

ファイルおよびロギング」パースペクティブを使って内容を確認する事が出来ます。

ASTの場合は、ソート機能やフィルター機能があります。フィルター機能はデフォルトで「情報（Info）」メッセージ用フィル

ター、「警告（Warning）」メッセージ用フィルターがありますが、カスタマイズすることもできます。（例：「エラー（Error）」と

「警告（Warning）」の両方のメッセージを表示するフィルターを作成）

139


139

FFDCFFDC（First Failure Data Capture)– すべてのシステムエラー情報を発生時点で自動的に記録する機能

– <プロファイル>/logs/ffdcに存在

FFDCにより生成される2種類のファイル

– Exception.log（サーバーごとの例外情報の統計）

• <ServerName>_exception.log （例： Server1_exception.log）

– インシデントストリーム（例外発生時点で取られる）

• <ServerName>_<thread id>_<timeStamp>_<SequenceNumber>.txt（例： server1_7412857d_05.10.10_13.08.16_0.txt）

FFDCの設定ファイル

• ffdcRun.properties、ffdcStart.properties、ffdcStop.properties

First Failure Data Capture (FFDC) フィーチャーは、処理の失敗によって生成された情報を保存し、それによって影響を

受けるエンジンに制御を戻します。取り込まれたデータは、問題の分析用にログ・ファイルに保管されます。

FFDC は、主として IBM サービスが使用するためのものです。 FFDC は、WebSphere Application Server のランタイム

時に発生するイベントおよびエラーを即時に収集します。この情報は、IBM サービス技術員により分析することができま

す。

FFDC 構成プロパティー・ファイルは、 WebSphere Application Server 製品インストールの下のプロパティー・ディレクトリーにあります。３つのプロパティー・ファイルがありますが、基本的にはffdcRun.propertiesファイルを変更します。そ

の他のファイルについては必要に応じて変更します。ExceptionFileMaximumAge プロパティーは、削除される前に、消去

の間の日数を構成するために使用できるプロパティーです。（その他、ffdcStart.propertiesファイルと

ffdcStop.propertiesファイルが存在します。）

FFDC フィーチャーは、WebSphere Application Server 製品のパフォーマンスには影響を与えません。

140


140

javacore（スレッド・ダンプ）

javacore– JVMのnative stack、java stack、環境情報などをテキストファイルで出力

– Javaのモニター（synchronizedなどの排他制御で使われる）情報も取得可能→デッドロックの調査に有効

外部からの指示による強制取得も可能

– WebSphereのjavaプロセスの場合、wsadminで取得可能

– Unixでは、”kill –QUIT <PID>”または”kill –3 <PID>”でも取得可能

C:¥WebSphere¥AppServer¥profiles¥Server01¥bin>wsadminWASX7209I: ノード vinusCellManager01 のプロセス "dmgr" に、SOAP コネクターを使って接続しました。プロセスのタイプは DeploymentManager です。WASX7029I: ヘルプを表示する場合は、「$Help help」と入力してください。

wsadmin>jvm = AdminControl.completeServerNameList("type=JVM,process=server1,*") wsadmin>AdminControl.invoke(jvm, "dumpAllThreads")

プロセスが異常終了した場合、javacoreが生成されます。javacoreには、JVMのnative stack、java stack、環境情報など

がテキストファイルで出力されます。synchronizedなどの排他制御で使用されるJavaのモニター情報も取得できますの

で、デッドロックの調査に有効です。

javacoreは、プロセスが異常終了したときに自動生成されるだけではなく、外部からの指示による強制取得もできます。

WebSphereのjavaプロセスの場合は、wsadminで取得することができます。Unixでは、”kill –QUIT <PID>”コマンドまた

は”kill -3 <PID>”コマンドでも取得することができます。

通常、クラッシュの場合はIBMサポート部門にCoreを送付して解析してもらうことになりますが、javacore.txtを参照するこ

とによって、現場担当者がその問題判別をすることもできる場合があります。

141


141

heapdumpheapdump– JVMヒープ内に割り当てられているすべての到達可能（live）オブジェクトの状態を記録

– ある時点のヒープの状態を示すスナップショット→アプリケーションのオブジェクトによるヒープの利用状況（分断化の度合い、

オブジェクトのロード状況）の調査に有効

heapdumpファイル生成のタイミング

– JVMがHeapを使い切ったときに生成

– 環境変数IBM_HEAPDUMPをtrueに設定することで、外部からの指示による強制取得も可能

– heapdumpの生成先

– デフォルトではＪＶＭプロセスのカレント・ワーキング・ディレクトリ（デフォルトはUSER_INSTALL_ROOT ）

– 環境変数IBM_HEAPDUMPDIRで生成先を指定可能

Heaprootsツール、 Heap Analyzer ツールやISAのJava用ヒープ・ダンプ診断ツール

を使用して解析可能

heapdumpは、JVMがheapを使いきったときに生成されます。また、IBM_HEAPDUMP環境変数を設定することで、ユー

ザーが明示的に命令を送ったときに生成することもできます。HeapdumpファイルはデフォルトではJVMプロセスのカレン

ト・ワーキング・ディレクトリに生成されますが、IBM_HEAPDUMPDIR環境変数に生成ディレクトリを指定することも可能で

す。

heapdumpファイルは、命令が送られた瞬間のheap上のすべてのJavaオブジェクト情報を記録します。heapdumpファイル

はheap上のすべてのオブジェクトについての詳細情報を提供しますので、特にメモリー関連の問題判別に有用です。一

般的には、プロジェクトのメンバーがheapdumpを見て、問題判別を行うと言うわけではなく、障害発生時に取得し、専門

家が解析を行うファイルとなります。

heapdumpファイルはheaprootsツール、 Heap Analyzer ツールやISA(後述）のJava用ヒープ・ダンプ診断ツールを使用し

て解析も可能です。

142


142

dumpNameSpace<プロファイル名>/bin/dumpNameSpace.bat(sh)– ネームスペースの内容をダンプするユーティリティ・ツール

– リソースアクセス時などにNamingExceptionが発生した時に実行して確認

ネームスペース（名前空間）

– 各プロセスは個別にネームスペースを持つ。

– それぞれのネームスペースをdumpNameSpaceコマンドでダンプさせるときは、ネームスペースを出力した

いプロセスのブートストラップ・ポートを指定

• 使用するアプリケーションが稼働するプロセスのネームスペースにリソースを登録

• 例. データソース「DS1」を使用するアプリケーションが「server1」で稼働する場合

– server1のネームスペースに「DS1」を登録する必要がある

– dumpNameSpace –port <server1のブートストラップ・ポート>の結果で、「DS1」が見つからなければならない

dumpNameSpace.sh –host <hostname> -port 9810 -root server主なオプション-host <hostname> 接続先ホスト名、ローカルの場合は省略可-port <port> ネームペースを出力したいプロセスのブートストラップ・ポートを指定

（指定しない場合は2809）-root [ cell | node | server ] ネームスペースのダンプのルート（開始点）

（指定しない場合はserver）

dumpNameSpaceとは、ネームサーバーを介してアクセスしたネームスペースの内容をダンプするユーティリティ・ツール

であり、 <profile_root>/bin/dumpNameSpace.bat(sh)から実行することができます。NamingExceptionが発生したときに実

行して確認します。

各プロセスは個別にネームスペースを持っており、それぞれのネームスペースをdumpNameSpaceコマンドでダンプさせ

るときは、ネームスペースを出力したいプロセスのブートストラップ・ポートを指定します。リソースは、そのリソースを使

用するアプリケーションが稼動するプロセスのネームスペースに登録します。例えば、DS1というデータソースを登録す

る際、そのDS1を使用するアプリケーションがserver1で稼動する場合は、server1のネームスペースにDS1を登録する必

要があります。そしてその場合、dumpNameSpaceコマンドでserver1のブートストラップポートを指定した結果でDS1が見

つからなければなりません。

dumpNameSpaceコマンドのオプションとして、接続先ホスト名やネームスペースを出力したいプロセスのブートストラッ

プ・ポート、ネームスペースのダンプの開始点などを指定することができます。デフォルトでは、ローカルのポート2809に

問い合わせ、サーバー・ルートが開始点です。

143


143

IBM Support Assistant (ISA)IBM Support Assistant (ISA) は、製品の問題をより容易に早く解決するためのローカ

ルなワークベンチ

– AIX®, Linux® (Intel), HP-UX, Solaris®, Windows™で稼動

便利なコンポーネント

– 検索

• 複数の検索ロケーション（IBM以外のサイトも含む）を

まとめて検索可能

– 製品情報

• 導入されているコンポーネントの製品ドキュメントへのリンクを提供

– ツール

• IBM 分析ツール（Java用ヒープ・ダンプ診断ツールなど）を

使用して問題判別作業を支援

– サービス

• 問題タイプ毎に診断データを自動収集、問題管理レポート (PMR) を IBM サポートに電子的に送信

問題判別のためのツールとしてWASV6.1からISA（IBMサポート・アシスタント）が同梱されています。他ツールと同じく

EclipseベースのGUIツールとなっています。IBM Support Assistant (ISA)は、WebSphere Application Server V6.1

Suppliments CDで提供されます。（または、IBM Software Support のWebサイト http://www-

306.ibm.com/software/support/isa/ からダウンロードすることも可能です）

製品のバージョンごとにサポート情報や製品情報の検索・収集、Java用メモリー･ダンプ診断ツール（MDD4J）で単一ダ

ンプ分析や2つのダンプの比較分析、IBMソフトウェア製品用のプラグインの追加インストール・カスタマイズを行う事が

出来ます。

ISAは、以下のコンポーネント機能を提供します。

○検索コンポーネント

一つの画面から複数の検索ロケーション（IBM以外のサイト：Googleも含まれる）を選択して、一度に検索することができ

ます。

○製品情報コンポーネント

導入されている製品に関する情報源（製品のホーム・ページ、サポート・ページ、フォーラム、フィックス（修正）、トラブル

シューティング情報）への、リンクを提供します。

○ツール・コンポーネント

IBM 分析ツール（Java用メモリー診断ツール）を使用して問題判別作業を支援します。

○サービス・コンポーネント

ESR（Electronic Service Requests ）にログインして、問題管理レポート (PMR) を IBM サポートに電子的に送信し、PMR

の状況を確認する。問題タイプ（例：データベース接続プールの問題、プロセスハングの問題、など）を指定すると、必要

な診断データを自動収集。

また対応するプラグインをインストールすることで、WAS以外のIBMソフトウェア製品（UDB, Tivoli等）のサポートも行える

ようにカスタマイズすることが可能です。他製品のプラグインのインストールにより、「検索」「製品情報」「ツール」コン

ポーネントに新しい情報が追加されます。

144


144

IBM Health Center 1.0オーバーヘッドの少ないJavaモニタリング・ツール。2009年6月10日にV1.0を発表。

ISAから起動可能

– Health Center ClientはISAに組み込まれているが、Health Center Agentは JVM側に導入が必要

– IBM Java 5 （SR8以上） or IBM Java 6 （SR1以上）をサポート

– 7月提供予定のJava5 SR10 および Java 6 SR5には、Agentがビルト・インされる予定

詳細情報

– http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/index.html

機能

– パフォーマンス

• メソッド・プロファイル• ロック分析• gc visualizationと推奨オプション

– メモリー

• メモリーリーク検出• ヒープサイズのガイド

– 環境

• システム・プロパティ• 環境変数

– クラスロード情報

• いつロードされたか• キャッシュされたかどうか

145


145

問題判別ツール一覧

代表的な解析対象資料に対する問題判別ツール一覧

– 利用可能なツールは随時追加・更新されます

– 多くのツールがWAS V5.x, V6.x, V7.0で利用可能です

○IBM Trace and Request AnalyzerWASとプラグイン

の実行時の詳細な記録

WAS：管理コンソール、プラグイン：コンソール or 構成ファイルで

設定する

トレース

○ThreadAnalyzer (非推奨のため今後のUpdateは無し)

×

×

○

○

○

×

○

○

ISAから

起動

HeapRoots

HeapAnalyzer

Memory Dump Diagnostic for Java (MDD4J) ※2

IBM Thread and Monitor Dump Analyzer ※2

IBM Monitoring and Diagnostic Tools for Java™ - Dump Analyzer ※1

Diagnostic Tool for Java Garbage Collector

IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)

IBM Monitoring and Diagnostic Tools for Java™ - Garbage Collection and Memory Visualizer

解析ツール

JVMに関するダンプ情報。OS情

報、環境変数、稼動する全スレッドのダンプ情報など

デフォルトで、JVMのクラッシュ時やQUIT(kill -3)シグナルを受け

取ったときに生成する

JavaDump(javacore)

デフォルトでOutOfMemory発生

時に自動生成する

(クラッシュ時にも生成するように環境変数で設定変更可能)

管理コンソール、または、JVM引

数で設定する

設定方法

JVMが使用する

ヒープ上に存在する全liveオブジェ

クトのダンプ情報

HeapDump

GC状況のトレー

ス冗長ガーベッジ

コレクション

(verbose:gcログ)

説明解析対象資料

※1 1600MBのメモリーが必要※2 Solaris, HP-UXも対象

146


146

練習問題

19. アプリケーションの挙動やプロセスの稼動状況を解析する際に初に確認するログは次のどれですか。

A) SystemOut/SystemErr.log

B) native_stdout.log/native_stderr.log

C) trace.log

D) FFDCログ

20. スレッドダンプを複数回取ることによる効果を以下から選びなさい。

A) サーバーでハングしたスレッドを調査することができる

B) スレッドダンプの取得の失敗を未然に防止するため

C) サーバーの負荷を下げるため

D) 上記の全て

21. IBM Support Assistant（ISA)を使ってリモート・デバッグ、データ収集するには次のどれを使いますか。

A) ISAエージェント

B) Health Center

C) コレクター・ツール

D) wsadminスクリプト

147


147

練習問題回答

お疲れ様でした。WebSphere 認定試験がんばってください。

10. A11. A12. C13. A,B14. C15. B

16. A,C17. A18. D19. A20. A21. A

1. A 2. A3. A,D4. A5. C6. B7. A8. C9. C

websphere application server network deployment v7.0 認定...

Documents