WebSphere Application Server Network Deployment V6.0 認定

®
IBM Software Group
WebSphere Application Server Network Deployment V6.0
認定システムアドミニストレーター 試験対策テキスト
WebSphere Application Server V6.0 Network Deployment, Core Administration
© 2005 IBM Corporation
WebSphere Application Server Network Deployment V6.0 認定システムアドミニストレーター
認定システムアドミニストレーター
試験対策テキスト
試験対策テキスト
2005年10月
編集・発行
第1.1版発行
日本アイ･ビー･エム株式会社 ソフトウエア事業
©Copyright IBM Japan, Ltd. 2005
All Rights Reserved. Printed in Japan.
日本アイ･ビー･エム株式会社の文書による同意なく本製品およびテキストの一部または全部の無断転載、無断複写することを禁止い
たします。
本テキストの内容は予告なく変更されることがあります。
1
IBM Software Group | WebSphere software
目次
0. 認定試験概要
………………………………………………… 3
1. アーキテクチャー
………………………………………………… 7
2. WASの導入と構成
………………………………………………… 21
3. アプリケーション・アセンブリーとデプロイメントおよびサーバー・ リソース
の構成
………………………………………………… 34
4. セキュリティ
………………………………………………… 44
5. ワークロード管理
………………………………………………… 53
6. 保守とパフォーマンス・チューニング
……………………………… 65
7. 問題判別
………………………………………………… 75
8. システム管理
………………………………………………… 87
9. 練習問題回答
………………………………………………… 97
2
<memo>
2
IBM Software Group | WebSphere software
認定試験概要
3
<memo>
3
IBM Software Group | WebSphere software
試験概要
【認定資格】WebSphere Application Server Network Deployment V6.0
認定システムアドミニストレーター
【試験名称】WebSphere Application Server V6.0,
Network Deployment, Core Administration
【試験時間】90分
【試験料金】18,900円
【出題形式】コンピューターでの出題、全て選択問題
【出題数】 約54問
【合格ライン】64 - 66%以上の正解で合格
4
WebSphere Application Server Network Deployment V6.0 認定システムアドミニストレーターはワー
ルドワイドで共通の、システム管理者向けの資格となります。WebSphere Application Serverの管理
について、幅広く出題されます。（詳細は次ページ参照）
WebSphereの認定資格としては、その他にも、WebSphere Application Server アドバイザー試験があ
ります。こちらはエントリー向けの試験で、日本IBM国内認定の資格となります。
4
IBM Software Group | WebSphere software
出題範囲
章タイトル
主な内容
1.アーキテクチャー(11％）
・WASとその他のアプリケーション・コンポーネント(ブラウザ、HTTPサーバー、プラグイン、
Firewall、データベース・サーバー、MQ、ロードバランサー、IPスプレイヤーなど）の関係につい
て理解できる
・企業のシステム構築において最適なWASのパッケージを選択し導入することができる
・WAS NDの様々なコンポーネントについて理解できる
・WASを利用した場合のワークロード管理とフェイルオーバーについて説明できる。またWAS V6
のHAManagerについて理解している
2．WASの導入と構成（13％）
・導入時のオプションと構成方法について理解している
・WASをインストールして、プロファイルを作成できる
・インストールの妥当性を検証できる
・インストール時の問題判別ができる
3.アプリケーション・アセンブ
リーとデプロイメントおよび
サーバー・リソースの構成
(11％)
・WASのネームサービス（JNDI)について説明できる
・ASTを使ってEnhancedEARファイルを含むJ2EEアプリケーションをパッケージングできる
・セキュリティーロール（ex.J2EEセキュリティ）の定義とマッピングができる
・JDBCプロバイダーとデータソースの設定ができる
・J2Cリソースアダプター、コネクションファクトリー、MDBアクティベーションスペックを構成できる
4．セキュリティー(11％)
・セキュリティー・ポリシーの実装
・WebSphereリソースの保護
・WebSphere管理に関するセキュリティの定義と実装
・SSLを使用する場合のプラグイン構成
5
<memo>
5
IBM Software Group | WebSphere software
出題範囲（続き）
章タイトル
主な内容
5．ワークロード管理 / スケーラ
ビリティー / フェイルオー
バー(13％)
・ノードを統合する（カスタム・プロファイルを含む）
・クラスターとクラスター・メンバーを作成する
・セッション・パーシステンスの方法を理解している（Memory to Memory, データベースによる保持）
・DRS (Data Replication Service) ドメインを作成、構成できる
6．保守とパフォーマンス・
チューニング(19％）
・アプリケーションの構成を管理できる（アプリケーション・バインディング、タイムアウト値のような
HTTPセッション構成パラメーターの調整）
・バックアップ、リストアの実行と構成タスクのアーカイブ
・ログやファイルのサイズを監視し、必要に応じてバックアップ/消去できる
・プラグイン構成ファイルを管理できる
・パフォーマンスチューニングができる（キャッシュの構成、キューイングやプーリング・パラメーター構
成、JVMヒープサイズ調整など）
・Tivoli Performance Viewerを使って情報を収集し、結果を分析する
・データソースの構成を調整できる（コネクションプール、タイムアウト・・）
・クラス・ローダーのパラメーターを構成できる
7．問題判別(15％)
・WebサーバーやWASのログを調べて分析する
・ログ・アナライザーを利用して問題の特定ができる / トレース機能を利用できる
・コンソール・メッセージのフィルターと調査
・FFDCツールを利用できる
・JNDI dumpNameSpaceユーティリティーを利用できる
・問題判別の様々な課題を実行できる(スレッドダンプ、JVMコアダンプ、リモートデバッグなど）
8．システム管理(7％）
・セルの管理を実行できる(デプロイメント・マネージャー / ノードの統合 / クラスター作成）
・管理コンソールとwsadminについて理解している
・JMSプロバイダーを構成できる
6
<memo>
6
IBM Software Group | WebSphere software
1章 アーキテクチャー概要
7
<memo>
7
IBM Software Group | WebSphere software
堅牢なWebシステム構成に必要なコンポーネント
DMZ（非武装地帯）
負荷分散
サーバー
Webサーバー
FW
FW
アプリケーション
サーバー
DBサーバー
ハイ・アベイラビリティー&フェイルオーバーを実現
負荷分散サーバー： クライアントからの要求を受けつけ、Webサーバへ転送。ロードバランサーとも呼ぶ
Webサーバー
ƒ 静的ページの要求であればクライアントに転送
ƒ 動的コンテンツの要求にはリクエストをアプリケーション・サーバーへ転送
アプリケーション・サーバー： Webサーバーから転送されたリクエストを受付け、動的コンテンツを生成
DBサーバー： アプリケーションに必要なデータやセッション情報などを保存し、一元管理
8
Webシステムを構成する上で必要となるコンポーネントについてご説明します。
インターネットやイントラネットを経由してのクライアントからのリクエストをまず受け付けるのが負荷分散サーバーで
す。負荷分散サーバーではWebサーバーへの負荷分散及び障害検知を行います。Webサーバーが受け付けたリク
エストに動的ページの要求があった場合、その処理をアプリケーション・サーバーに依頼します。アプリケーション・
サーバーは処理の内容に応じてデータベースのデータを更新・検索などの処理を行い、動的ページの生成を行い、
結果をクライアントに返します。
また、FWとはファイアウォールを指します。ファイアウォールを導入することにより、外部の攻撃から社内ネットワーク
を守り、セキュリティを大幅に高めることが可能となります。インターネットの場合には必須となるコンポーネントにな
ります。
この図では、負荷分散サーバー、Webサーバー、アプリケーション・サーバー、データベース・サーバーが全て複数
サーバーで描かれています。全てのサーバーを複数台用意することにより、可用性、耐障害性を高め負荷を分散さ
せることが可能となりますが、これは一例なので、FWの配置箇所やWebサーバーの配置箇所、サーバーの台数など
は要件によって異なります。
8
IBM Software Group | WebSphere software
WASV6.0のエディション
WebSphere Application Server Network Deployment (ND)
WebSphere Application Server(Base)
WebSphere
Application Server
-Express
シングルサーバー
の実行環境を提供
分散環境で、最新
のクラスタリング、
HA(高可用性)機能、
管理機能を提供
ISVソリューション
の基盤
®
®
®
®
Windows
Windows Linux
Linux AIX
AIX Solaris
Solaris HP-UX
HP-UX
®
OS/400
OS/400
®
z/OS
z/OS
9
WAS V6では以下のパッケージが提供されます。
・WebSphere Application Server V6 - Express
・WebSphere Application Server V6 (以降Base)
・WebSphere Application Server V6 - Network Deployment (以降ND)
Express、Base はスタンドアロンで稼動します。NDは複数サーバーによるクラスタ機能をサポートするパッケージで、
負荷分散、可用性のための様々な機能を提供します。NDにはロードバランサーおよびキャッシングプロキシー機能
を提供するEdge Componentsが同梱されています。
全パッケージにEJBの実行環境がつき、J2EE 1.4をフル・サポートします。
9
IBM Software Group | WebSphere software
各パッケージの比較
内容
WAS Express
WAS (Base)
WAS ND
導入可能CPU数
2CPUまで
無制限
無制限
J2EE1.4サポート
○
○
○
64bit対応予定
×
○
○
Edgeコンポーネント同梱
×
×
○
クラスター構成
×
×
○
HA機能
×
×
○
SI Bus機能
○
○
○
プログラミング・モデル拡張※
○
○
○
プログラミング拡張の種類についてはインフォセンターの下記項目をご覧下さい
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_appsvcs.html
10
これは各パッケージを比較したものです。
WASV5ではEnterprise Editionにしか含まれなかったプログラミング・モデル拡張（非同期BeanやスタートアップBean,ス
ケジューラー・サービスなど）はExpressからサポートされるようになりました。
10
IBM Software Group | WebSphere software
WASの基本構成要素
ƒ
アプリケーション・サーバー
J2EE1.4完全準拠のアプリケーション
一つのJavaプロセス
J2EEアプリケーション実行環境（以下の機能）を提供
ƒ HTTPトランスポート
– Embedded HTTP Serverとも呼ばれる
– アプリケーション・サーバーごとに存在
ƒ Webコンテナー
– サーブレット,JSPなどの
Webアプリケーションの実行環境
ƒ EJBコンテナー
– EJBの実行環境
ƒ ネーミングサービス
クライアント
– 名前をもとにオブジェクトを
検索するためのサービス
ƒ JMSプロバイダー
– JMSインターフェイスを備えた
メッセージングシステムをJ2EE上での実装
ƒ
Application Server
Web
サーバー
Webサーバー
プラグイン
ネーミングサービス
Web
コンテナー
HTTPトラン
スポート
EJB
コンテナー
JMS
プロバイダー
Webサーバー上の構成要素
Webサーバー
ƒ HTTPリクエストを受け付ける
Webサーバー・プラグイン
ƒ Webサーバーのプロセス内で稼働し、アプリケーション・サーバーへの要求をフォワード
11
○アプリケーション・サーバー
J2EE1.4準拠のアプリケーション・サーバーで、一つのJavaプロセスとして稼動します。以下の機能を提供します。
○HTTPトランスポート
Webサーバープラグインから送られてくるHTTP通信の受け口です。問題切り分けのために直接アクセスするこ
ともできます。
○Webコンテナー
サーブレットやJSPの実行環境を提供します。サーブレット・インスタンスの作成、サーブレットのロードとアン
ロード、Requestオブジェクト・インスタンスとResponseオブジェクト・インスタンスの作成と管理、ならびにサーブ
レットを効率的に管理するためのタスクを実行します。
○EJBコンテナー
EJBの実行環境を提供します。EJBコンポーネントのトランザクション管理を提供します。EJBコンテナが提供す
る機能を使用することにより、ユーザープログラムにおけるシステム関連のコードの開発量を削減し、シンプル
なコンポーネントとしてのBeanが作成できます。
○ネーミング・サービス
オブジェクト（データソース、EJBホーム・インターフェースなど）と名前とを関連づけ、その名前をキーとしてオ
ブジェクトを検索するためのサービスです。
○JMSプロバイダー
JMSとはJava Message Serviceの略で、J2EE標準のメッセージング・インターフェースです。JMSプロバイダー
はJ2EEサーバー上でJMSの実行環境を提供します。
○Webサーバー
HTTPのリクエストを受け付けます。
○Webサーバー・プラグイン
受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへリクエストを転送します。
HTTPプラグインとも呼ばれます
11
IBM Software Group | WebSphere software
WAS Network Deploymentの管理トポロジー
セル
ノード A
デプロイメント・
マネージャー
セル・構成情報
サーバーA・構成情報
ノードB・構成情報
サーバーB・構成情報
ノードC・構成情報
サーバーC・構成情報
マスター
サーバーD・構成情報
ノード B
セル・構成情報
ノード C
セル・構成情報
ノードB・構成情報
ノード・
エージェント
サーバーA・構成情報
ノードC・構成情報
ノード・
エージェント
サーバーB・構成情報
サーバーC・構成情報
サーバーD・構成情報
ローカル
ローカル
アプリケー
ション
サーバーA
アプリケー
ション
サーバーB
EARファイル
アプリケー
ション
サーバーC
アプリケー
ション
サーバーD
EARファイル
12
NDにおける管理トポロジーを表した図です。
WAS NDの管理単位をセルと呼んでいます。セル内には一つのデプロイメント・マネージャーが存在し、管理下全て
の構成情報のマスターを管理します。各マシンごとにノード・エージェントとよばれる管理エージェントが存在し、
ローカルにも構成情報を保管します。
構成情報のなかにはセル全体の情報、ノードごとの情報、サーバーごとの情報が含まれます。EARファイルとは
J2EEアプリケーションファイルです。これもノード単位の管理と、セル全体ではデプロイメント・マネージャーが管理
します。
また、ノード・エージェントは各アプリケーション・サーバーの障害の監視も行います。
NDでサーバーを起動するには、デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーの3
つを起動する必要があります。
WAS V6ではひとつのセルにV5とV6のノードを混在させることができます。ただしこの場合、デプロイメント・マネー
ジャーはV6である必要があります。
12
IBM Software Group | WebSphere software
管理トポロジー用語解説
ƒ セル
ノードの集まりで論理的な管理の単位
デプロイメント・マネージャーはセルを構成する
ƒ デプロイメント・マネージャー（DM）
セル内のノードを一括管理
DMの管理コンソールにアクセスすることによりセル内の全てのリソースを管理
ƒ ノード
通常は物理的な一つのマシンに対応
一つのマシン上に複数のノードを構成することも可能
アプリケーション・サーバーの集まり
ƒ ノード・エージェント
一つの管理ノードに一つ存在
管理用のエージェント
ノード配下のアプリケーション・サーバーやWebサーバーを管理
ƒ アプリケーション・サーバー
Web／EJBコンテナー、ネーミング・サービス、リソース管理、JMSプロバイダーなどが含ま
れる
13
・セル
論理的な管理の単位です。
・デプロイメント・マネージャー（DM）
セル内のコンポーネントを一括管理し、セルに必ず一つ存在します。
・ノード
物理マシンの単位で、アプリケーション・サーバーの集まりです。
・ノード・エージェント
ノード内を管理する管理用のエージェントです。一つのノードに必ず一つ存在します。
・アプリケーション・サーバー
Webコンテナー、EJBコンテナー、ネーミング・サービス、リソース管理、JMSプロバイダーなどを提供します。
13
IBM Software Group | WebSphere software
高可用性・負荷分散のための機能
ワークロードマネージメント(WLM)
ƒ 3段階でのWLMを提供
WebSphere Application Serverクラスター構成によるWLM
Edge ComponentsのLoad Balancer（負荷分散サーバー）によるWebサーバーへ
の負荷分散
Load Balancer
(Primary)
Load Balancer
(Backup)
① Load Balancerによる
HTTPサーバーへのWLM
HTTP
サーバー
プラグイン
HTTP
サーバー
プラグイン
Web
コンテナー
EJB
コンテナー
Application
Server
Application
Server
Web
コンテナー
EJB
コンテナー
Application
Server
Application
Server
② Webサーバー・ プラグ
インによるWebコンテナー
へのWLM
DB
③EJBクライアントの
WLMプラグインによる
EJBコンテナーへのWLM
14
NDでは3つのリクエスト・タイプ（HTTPリクエスト, Servletリクエスト, EJB リクエスト）毎にワークロード管理（WLM）を行
なうことが可能です。
1.HTTPリクエスト
複数Webサーバーへの負荷分散は負荷分散サーバーが行います。 負荷分散サーバーにはハードウェア・タイ
プとソフトウェア・タイプがありますが、NDにはソフトウェア・タイプのEdge Components (Load Balancer)が同梱
されています。
2.Servletリクエスト
Webサーバー上のWebサーバー・プラグイン・モジュールが Webコンテナーへリクエストの分散を行います。
3.EJBリクエスト
EJBリクエストは、ORB（Object Request Broker）のWLMプラグインが複数EJBコンテナーに対して分散をおこな
います。
14
IBM Software Group | WebSphere software
高可用性のためのHigh Availability機能
„
„
V6 New
ミッションクリティカルなアプリケーションの連続した稼動を可能にするHA機能を
標準搭載
特長
¾HACMPなどOSのHA機能と異なり、サーバー・ダウン時にアプリケーション・サーバー・
レベルでのトランザクションのリカバリーが可能
„
仕組み
¾HAマネージャーが実装され、利用可能なサーバー上でフェィルオーバーなどの主要な
サービスを実行
¾NAS(ネットワーク接続記憶装置)のフォールト・トレラント・ストレージ技術の活用
HAマネージャー
HAマネージャーは
どこで何が実行さ
れているかをコー
ディネートしフェィル
オーバーを処理
サーバーJVM
サーバー1
サーバーのログを
格納。
全てのサーバーか
ら全てのログを見
ることが可能。
HAマネージャー
サーバー2
HAマネージャー
NAS
サーバー3
15
WAS V6では、High Availability機能が標準搭載されました。HACMPなどのHA機能ではなく、WASに組み込まれた機能を
使用しますので、一部のサーバーがダウンした時に、アプリケーションのレベルで、高速な引継ぎが可能となります。各
アプリケーション・サーバーごとに、HAマネージャーが実装され、どのサーバーでどのようなサービスが実行されている
かを監視し、問題発生時には、フェイルオーバーの処理を行います。サーバーのログは、NAS(ネットワーク接続記憶装
置)に置かれ、サーバー間で共有されます。
15
IBM Software Group | WebSphere software
High Availability機能～詳細～
ƒ 引継ぎの
引継ぎの対象
ぎの対象となる
対象となるサービス
となるサービス
トランザクション・
トランザクション・マネージャー
ƒ NAS経由のトランザクション・ログを別のWASが引き継いでトランザクションを完結
ƒ 障害機上のWASの再立ち上げは不要
ƒ DBロック早期解放／データ整合性保証
クラスター構成
機能
クラスター構成において
構成において重要度
において重要度の
重要度の高いWAS機能
ƒ メッセージング・エンジン
–JMS機能を提供
ƒ WLM制御機能
–EJB負荷分散制御機能
ハードウェアなどの障害を検出
ハードウェアなどの障害を検出
秒単位でWebベースの
秒単位でWebベースの
トランザクションを
トランザクションを
オートノミック（自律的）に復旧
オートノミック（自律的）に復旧
16
具体的に、引継ぎの対象となるサービスとしては、トランザクション・マネージャーと、メッセージング・エンジン、WLM
機能があります。
まず、トランザクション・ログをNASに置くことにより、障害発生時はこれを別のWASが引き継いでトランザクションを実
行します。従来は、障害が発生したWASの再起動をして、DBのロックを開放する必要がありましたが、WAS V6では
これらの対応は必要ありません。データの整合性が保証されます。
次に、WebSphereのクラスター構成を支える重要度の高い機能も、HA機能により復旧されます。
EJBの負荷分散制御を行うWLM (Work Load Management)機能もフェイル・オーバーの対象です。
16
IBM Software Group | WebSphere software
メッセージング（JMS)
V6 New
CとJavaコード
Event
Broker
JMS
(MA88)
WASV5.ｘ
WASV5.ｘ
MQ
WAS
WASV6
V6
統合された
統合された
メッセージング
メッセージング
パーシスタント・
メッセージの
格納用DB
複数のメッセージングプロセス
ƒ
V6では新しいJavaベースのメッセージング・エンジンを搭載。
Pure Java JMS 1.1 provider
ƒ V5では、インストール時のオプションにより、WebSphere MQをインストール。
ƒ V6では、WASの標準のインストールに含まれる。
アプリケーション・サーバーＪＶＭの一部として稼働する。->それぞれのアプリケーション・サーバーが
メッセージングエンジンを持つ。
MQと同等の機能を提供するが、MQに依存するコード体系ではなくなった
パーシスタンス・メッセージは、Cloudscapeデータベースか、DB2/Oracle等の外部DBに保管する。
HA機能の対象であり、メッセージングエンジンもフェイルオーバーされる。
ƒ
ESB (WASV6ではサービス統合バス）のエンジンとして使用される。
17
WAS V5では組み込みメッセージング（Embedded Messaging)が同梱されていましたが、V6ではアプリケーション・
サーバーの一部としてインストールされます。そのため別途組み込みメッセージングの機能をインストールする必要
はなくなりました。さらに組み込みメッセージングはMQのサブセットとしてMQアプリケーションに依存するコード体系
でしたが、その依存性もなくなりました。
機能もアップグレードされ、キューのブラウンジングが行えるようになったなど管理機能も充実してきています。
さらにWebSphereMQネットワークを接続することにより、SIBusを経由してMQキュー・マネージャー間とのメッセージ
送受信ができるようになりました。
尚サービス統合バス（SIBus）が提供するメッセージング・エンジンはJMS1.1に準拠しています。そのため、アプリケー
ションを開発する際はJMS1.1を利用するようにしてください。
17
IBM Software Group | WebSphere software
JMSプロバイダー機能
ƒ
WAS V6 で利用可能なJMSプロバイダー
サービス統合バス（SIBus）のメッセージング機能
ƒ 「デフォルトのメッセージング」として使用できる
ƒ WAS V6の新機能であるSIBusのメッセージング機能を利用
ƒ Pure Javaで書かれたWMQライクなメッセージング・エンジン
ƒ WMQとリンク可能
WebSphere MQ
ƒ 多くのプラットフォームをサポート
ƒ 実績が豊富
ƒ 高い信頼性
WAS5の組み込みメッセージング・サービス
ƒ 「V5 デフォルトのメッセージング」として使用可能
ƒ WAS5.xからマイグレーションした場合に利用
その他のJMSプロバイダー
JMS
Client
ƒ 「汎用」として使用できる
ƒ WMQ以外のJMSプロバイダー
JMSプロバイダー
SIBus
JMS
WMQ
JMS
JMS
Client
他社メッセージ
ング製品
メッセージング・
メッセージング・サービス
18
WAS V6で利用可能なJMSプロバイダーです。
・SIBus (Service Integration Bus：サービス統合バス)のメッセージング機能
「デフォルトのメッセージング」は、WAS V6の新機能である、SIBusのメッセージング機能を利用します（SIBusについて
は後述）。WAS V6はJ2EE 1.4を実装しているので、J2EE 1.4に含まれるJMS1.1を利用可能です。
WebSphere MQ(以下WMQ、またはMQ)は、多くのプラットフォームをサポートするIBM製品です。豊富な実績と、高い
信頼性が評価されています。
V5 デフォルト・メッセージングは、WAS5.xの組み込みメッセージングです。WAS5.xからマイグレーションした場合に利
用します。
それ以外のJMSプロバイダーも、汎用JMSプロバイダーとして利用可能です。
18
IBM Software Group | WebSphere software
SIBus(サービス統合バス）
V6 New
ƒ
サービス統合に必要な通信インフラストラクチャーを提供
ƒ
二つの役割
JMSプロバイダー
ƒ メッセージのルーティング及びフォーマット変換機能
ƒ 通信の複雑性を隠蔽し新規アプリケーション、システムの変更に柔軟に対応可能
ƒ メッセージ転送の信頼性、高可用性、ワークロード・マネジメント及びセキュリティ機能を提供
ƒ MQリンク経由でWebSphere MQと接続可能
ƒ JMS1.1サポート
Webサービスルーティング
ƒ プロトコル変換機能を提供
ƒ
WebSphereV6でのESB(Enterprise Service Bus)機能の実装
WebSphereMQ
WebSphereV6セル
SI-Bus
Web
ｻｰﾋﾞｽ
リンク
JMS
JMS
SI-Bus
Web
ｻｰﾋﾞｽ
JMS
JMS
19
SIBusはサービス統合に必要な通信インフラストラクチャーを提供し、二つの役割を持っています。
1.JMSプロバイダー機能
・メッセージのルーティング及びフォーマット変換機能を提供します。
・通信の複雑性を隠蔽し新規アプリケーション、システムの変更に柔軟に対応可能します。
・メッセージ転送の信頼性、高可用性、ワークロード・マネジメント及びセキュリティ機能を提供します。
・WebSphere MQ製品と接続可能です。
・JMS1.1をサポートしています。
2.Webサービスルーティング機能
・SIBus上の既に定義してある宛先をWebサービスとして外部からアクセスできるようにします。（インバウン
ド・サービス）
・SIBus上のアプリケーションからWebサービスをコールできるようにします。 （アウトバウンド・サービス）
・Webサービスのプロバイダーとリクエスターの間にSIBusを配置しWebサービスのGatewayとして機能させら
れるようにします.この機能はND環境下でのみ使用可能です。（ゲートウェイ・サービス/プロキシー・サー
ビス）
ESBとは複数のサービスを繋ぎあわせるためのバスです。サービス間のメッセージのプロトコル変換、ルーティング、
ロギング、セキュリティ等の機能を持ちます。ESBはSOA(Service Oriented Architecture)の通信基盤となるとされて
います。
SOAとは各種のプログラムを「サービス」として位置づけ、記述言語を通じて呼び出し利用するアーキテクチャです。
SOAは、多数のサービスを組み合わせ新しい価値を持つサービスを作り出すことを目的としています。
19
IBM Software Group | WebSphere software
練習問題
1. Webブラウザー
ブラウザーから
ブラウザーからサーブレット
からサーブレットを
サーブレットを呼び出して利用
して利用する
利用する場合
する場合、
場合、一般に
一般にブラウザー
からの要求
からの要求はどの
要求はどの順番
はどの順番で
順番で流れるでしょうか
A. LDAPサーバー、JMSサーバー、Webコンテナー
B. 外部HTTPサーバー、HTTPサーバー・プラグイン、Webコンテナー
C. 組み込みHTTPサーバー、Webコンテナー、EJBコンテナー
2. 新機能である
Managerについて
について正
新機能であるHA
である
について正しいものをひとつ選択
しいものをひとつ選択してください
選択してください
A. サーバー障害時に、アプリケーション・サーバー・レベルでのトランザクションのリカバリーが可能
B. HA Manager は各アプリケーション・サーバーのプロセス内のエンタープライズアプリケーション
として実行され、クラスターの正常性を監視する
C. HA Manager は、トランザクション・サービス、JMSメッセージ・サービス、サービス統合バス・
サービスなどの可用性を高める
20
<memo>
20
IBM Software Group | WebSphere software
2章 導入と構成
21
<memo>
21
IBM Software Group | WebSphere software
WASの導入にあたって
WAS V6.0の導入にあたっては、前提条件が満たされているか必ず確認してください
◆ハードウェアおよびソフトウェア前提条件
・http://www-06.ibm.com/software/webservers/appserv/doc/latest/prereq.htmlにて確認できます
◆インストール開始前に確認しておくこと
・インストールするマシンにAdministrator 権限をもったユーザーでログインしていること
・TCP/IP ネットワークの設定が正しく行われていること
-IP アドレス、ネットマスク、デフォルト・ゲートウェイ、ホスト名(インストール後の変更はできません)
-DNS を使用する場合は名前解決を適切に行えること
-ディスクが以下に示す以上の空き容量を持つこと
WAS-ND
C:¥Program Files¥IBM¥WebSphere¥AppServer
730MB
Deployment manager プロファイル用
30MB
SampleアプリケーションのApplicationServerプロファイル用
200MB
Application Server プロファイル用
10MB
C:¥temp
100MB
IBM HTTP Server
110MB
Webサーバープラグイン
200MB
C:¥Program Files¥ibm¥gsk7
25MB
その他、インストール前に必要な事項は
http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_winsetup.html
に記載されていますので、ご参照下さい。
22
<memo>
22
IBM Software Group | WebSphere software
WAS導入の手順（ランチパッドよりウィザードで導入の場合）
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.Deployment Managerプロファイル
プロファイルの
プロファイルの作成 プロファイル作成ウィザードを使用します
7.Application Server プロファイルの
プロファイルの作成 プロファイル作成ウィザードを使用します
8. ノードの
ノードの統合
Deployment Manager にApplication Server ノードを統合。
Deployment Manager 起動→Application Server 起動→Deployment Manager管理コンソール上でノードを統合
9．インストール
インストールの
ホスト名
インストールの確認：
確認：http://<ホスト
ホスト名>:9080/snoop へアクセス。
結果が正常に表示されれば、アプリケーション・サーバーの起動は正常
インストールの詳細についてはhttp://www-6.ibm.com/jp/software/websphere/developer/was/wv6/nd/ を参照下さい
23
<memo>
23
IBM Software Group | WebSphere software
WebSphereプロファイルとは？
V6 New
インストール・イメージに対して複数の構成が可能
ƒWAS V6は2つのコンポーネントから構成される
インストール時にコピーされる製品ファイル。アプリケーション・サーバー・インスタンスにより共通で使用
カストマイズされた構成ファイル群 (WebSphere構成ファイル、アプリケーション、プロパティなど）
WebSphereプロファイル
プロファイル
ではプロファイル
ƒ WAS V6では
ではプロファイルの
プロファイルの作成が
作成が必須
ƒ利点
1つの共通コードから、デプロイメント・マネージャーやアプリケーション・サーバー等の異なるプロファイルを作成可能。
修正は単一の製品バイナリーに適用すればよい。
ƒプロファイルの種類
デプロイメント・マネージャー、アプリケーション・サーバー、 カスタムの3種類。
製品
バイナリー
+
WebSphere
プロファイル
+
WebSphere
プロファイル
ノード
プロファイルを削除する
だけで初期状態に
binの下のファイルやログ、config
などもプロファイルごとの
ディレクトリーの下に存在する
24
WebSphereプロファイルは、V6からの新しい管理の仕組みです。インストールした製品のバイナリーファイルとは別に、プロファイ
ルごとに、構成ファイルを作成します。このことにより、構成・管理をより柔軟に行うことができるようになりました。
WAS V6は、大きく分けて二つのコンポーネントから構成されているといえます。
1つは、インストール時にコピーされる、製品のバイナリイメージです。これは読み取り専用であり、システムごとにカスタマイズさ
れることはありません。アプリケーション・サーバーインスタンスによって共通に使用されます。
もう1つは、カスタマイズされた構成ファイルです。構成を保管するファイルや、アプリケーション、各種のプロパティなどであり、こ
れらをまとめて、WebSphereプロファイルと呼びます。
WAS V6ではプロファイルの作成が必須となります。すなわち、製品ファイルをインストールしただけでは、動かすことはできません。
WebSphereプロファイルという機能を利用することにより、一つの共通コードから、デプロイメント・マネージャーやアプリケーショ
ン・サーバーなどの異なるプロファイルを作成することができます。製品に対する修正は、インストールした1つの製品ファイルに適
用するだけで良いです。
プロファイルの種類としては、デプロイメント・マネージャー、アプリケーション・サーバー、カスタムの3種類があります。
プロファイルの便利な点として、例えば、テスト環境などで、構成を初めからやり直したい場合など、プロファイルを削除するだけ
で初期状態に戻すことができるということが上げられます。製品のアンインストール、再インストールなどは必要ありません。
プロファイルごとに、ディレクトリーが作成され、使用するコマンド(binの下のファイル)や、ログ、config等もすべてその中に存在す
る形となります。
プロファイルには作成するプロファイルのタイプに応じたプロファイル･テンプレートが準備されています。アプリケーション・サー
バー・プロファイル･テンプレートはアプリケーション・サーバーのプロファイルを作成し、その上に”server1”というアプリケーション・
サーバーを作成します。アプリケーション・サーバー・テンプレートはスタンドアローン･ノードとして作成することも、作成後にセル
環境に統合することも可能です。セル環境に統合した場合、そのタイミングで”nodeagent”という名称のノード・エージェントを作成
します。デプロイメント・マネージャープロファイル･テンプレートはデプロイメント・マネージャーのプロファイルを作成し、その上
に”dmgr”という名称のデプロイメント・マネージャーを作成します。最初からセル環境に統合した管理ノードを作成したい場合、カ
スタム･プロファイル･テンプレートを使用します。カスタム･プロファイルはセルに統合されたノード・エージェントのみを持つノードで
す。必要に応じてここにアプリケーション・サーバーを作成していきます。デプロイメント・マネージャー・プロファイル･テンプレートと、
カスタム･プロファイル･テンプレートはWAS ND版でのみ提供されます。
24
IBM Software Group | WebSphere software
プロファイルの作成と操作
①WASインストーラーで導入
WAS製品コード
<WAS_root>
/WebSphere/AppServer
プロファイルは導入されたWASの製品コード
を使用して、WebSphereのランタイム環境を
提供するための構成ファイル群
②プロファイル作成ウィザード／wasprofileで作成
③wasprofileで操作
ASプロファイル･テンプレート
ASプロファイル
AS
DMプロファイル･テンプレート
DMプロファイル
DM
カスタム・プロファイル･
テンプレート
◆プロファイル作成ウィザード（作成）
カスタム･プロファイル
NA
NA
◆wasprofileコマンド（作成、削除、検査、）
ASプロファイル作成
ASプロファイル作成
プロファイル削除ヘルプ
プロファイル削除ヘルプ
プロファイル･タイプの選択画面
プロファイル･タイプの選択画面
z
z DMプロファイル
DMプロファイル
z
z ASプロファイル
ASプロファイル
z
z カスタム･プロファイル
カスタム･プロファイル
ASプロファイル作成ヘルプ
ASプロファイル作成ヘルプ
25
プロファイルを管理するためにはGUIの『プロファイル作成ウィザード』とCUIの『wasprofileコマンド』の二種類の管理
ツールが提供されます。使用目的に応じて使い分けてください。
プロファイル作成ウィザードはプロファイルの作成にのみ使用できるウィザードで、『<WAS_root>/bin/pct<プラット
フォーム>.<実行ファイル拡張子>』コマンドで起動します。ファイル名はたとえばWindows環境ではpctWindows.exe、
Linux環境ではpctLinux.binです。プロファイル作成ウィザードはその名の通りプロファイルの作成しか行えません。プ
ロファイルの削除などはwasprofileコマンドで行います。
wasprofileコマンドは『<WAS_root>/bin/wasprofile.<実行ファイル拡張子>』で呼び出すコマンドラインツールです。以下
の引数でプロファイル操作を行います。
［-create、-delete、-deleteAll、-augment、-unaugment、listProfiles、getName、getPath、-validateRegistry、validateAndUpdateRegistry］
オプションで名前から推察しづらいもののみここで解説します。augmentはWASの基盤の上にWBISFのような拡張製
品を導入した際にプロファイルを拡張するために使用されるオプションです。validateRegistryはプロファイル情報を保
持するXML（<WAS_root>/properties/profileRegistry.xml）とprofiles以下のファイルシステムの整合をチェックするもの
です。profilesディレクトリ以下のファイルを誤って消した場合、validateAndUpdateRegistryをかけると
profileRegistry.xmlを更新してプロファイル情報を消しこみます。
wasprofileコマンドで上記プロファイル作成ウィザードの画面コピーのようにプロファイル･タイプを指定するにはtemplatePathで指定します。それぞれのパスは以下の通りです。
DMプロファイル
<WAS_root>/profileTemplates/dmgr
ASプロファイル
<WAS_root>/profileTemplates/default
カスタムプロファイル
<WAS_root>/profileTemplates/managed
プロファイル作成ウィザード、wasprofileコマンドの双方とも、ログを<WAS_root>/logs/wasprofileに書き出します。ファ
イル名のネーミングルールは『wasprofile_<オペレーション>_<プロファイル名>.log』です。たとえば上のwasprofileの例
では、ログの名称は『wasprofile_create_AppSrv02.log』になります。コマンドの失敗の際などは標準出力にあまり有用
な情報が記載されないので、このログを参照するようにしてください。ログはXML形式で記載されます。（さらに詳細の
ログが<WAS_root>/profiles/<プロファイル名>/logsに記載され、上記ログからポイントされている場合もあります。）
25
IBM Software Group | WebSphere software
wasprofileコマンド使用例（参考）
‹プロファイルを削除したいとき
wasprofile.sh -delete -profileName プロファイルの名前
‹定義済みのポート番号をプロファイルで使用したいとき
/profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props ファイルを使用して初期ポートを設定します
ƒportdef.propsファイルの例
WC_defaulthost=39080
WC_adminhost=39060
WC_defaulthost_secure=39443
WC_adminhost_secure=39043
BOOTSTRAP_ADDRESS=32809
SOAP_CONNECTOR_ADDRESS=38880
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=39401
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=39403
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=39402
ORB_LISTENER_ADDRESS=39100
DCS_UNICAST_ADDRESS=39353
SIB_ENDPOINT_ADDRESS=37276
SIB_ENDPOINT_SECURE_ADDRESS=37286
SIB_MQ_ENDPOINT_ADDRESS=35558
SIB_MQ_ENDPOINT_SECURE_ADDRESS=35578
※Windowsの場合はwasprofile.bat
wasprofile.sh -portsFile C:¥temp¥ports¥portdef.props
portdef.propsファイルの場所を指定
26
wasprofileコマンドは『<WAS_root>/bin/wasprofile.<実行ファイル拡張子>』で呼び出すコマンドラインツールです。
ここではよく利用される一例をあげましたが、詳細はマニュアル「インフォセンター」の下記を参照ください
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/
ae/rxml_wasprofile.html
26
IBM Software Group | WebSphere software
サイレント・インストール
サイレント・インストールでは、インストール・ウィザードの使用時に、グラフィカル・ユーザー・インターフェースを
使用せずに、サイレント・モードで製品をインストールできます。
サイレント・インストールによって、インストール・プログラムは、ウィザード・インターフェースを表示する代わりに、
ユーザーが提供するファイルからユーザーの応答をすべて読み取ることができます。
製品CDのWASディレクトリまたはマニュアル（インフォセンター）のサイレント・インストールの章にサンプルの
応答ファイルが用意されています。このファイルの中のパラメーターを、環境にあわせて変更して利用します。
[ドライブ
ドライブ名
ドライブ名]:¥WAS¥install" -options "C:¥temp¥WAS¥myoptionsfile.txt" -silent
作成した応答ファイルを指定します
Network Deployment の場合はプロファイルを作成して、作動環境を作成する必要があります。
作成する予定のプロファイルのプロファイル・オプション応答ファイルをカスタマイズすることにより、プロファイルをサイレントに作成する
ことができます。オリジナル・プロファイル応答ファイルの名前は以下のとおりです。
ƒDeployment Manager プロファイル: responsefile.pct.NDdmgrProfile.txt
ƒアプリケーション・サーバー・プロファイル: responsefile.pct.NDstandAloneProfile.txt
ƒカスタム・プロファイル: responsefile.pct.NDmanagedProfile.txt
これらをコピーしてパラメーターを
環境にあわせて変更し利用する
詳細については、下記 Info Center をご参照ください。
「サイレント・インストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_runSilent.html
27
WASではウィザードによるGUIを使用したインストール方法とは別にサイレント・モードでインストールを自動実行でき
ます。
サイレント・インストールではあらかじめ設定しておかなければならないパラメーターや設定項目を応答ファイルに記
述しておき、インストールプログラムはそのファイルの中身を読み取りながらインストールを実行します。
何台ものサーバーにインストールを行いたいときなど便利です。
27
IBM Software Group | WebSphere software
V6 New
Webサーバーをセルで管理可能
WAS 6.0 ND では新機能として、IBM HTTP Server 6.0 をWebSphere セルに含めて管理可能に
なりました。
IBM HTTP Server 6.0 の起動や停止、設定をWebSphere 管理コンソールから行うことができます。
また、アプリケーション・サーバーとIBM HTTP Server が別のマシンにインストールされている場合、
WAS V5.x では手動で行わなくてはならなかったプラグイン構成ファイルのコピーも、自動で行わせ
ることができるようになりました。
◆IBM HTTP Server とWebSphere Application Serverを同じノード（マシン）に導入した場合◆
WebサーバーはNode Agent 経由で管理され、管
理コンソールから次の操作が可能
Deployment
Manager
①プラグイン構成の生成・伝搬
②Webサーバーの開始・停止
③ログファイルの表示
④構成ファイル(httpd.conf)の編集
NodeAgent
HTTP(S)
WebServer
WebServer
Plug-in
Module
HTTP(S)
Plug-in
Config
XML file
Application
Application
Server
Server
Node
Cell
28
WASV6.0からはWebサーバーをデプロイメント・マネージャーの管理対象サーバーに含めることができるようになりまし
た。
これにより、管理コンソールから以下の操作が可能になります。
・Webサーバーの稼動状況の確認
・プラグイン構成ファイルの生成・更新、伝搬
・Webサーバーの始動/停止、終了
・Webログファイルの表示
・構成ファイル（httpd.conf)の編集
28
IBM Software Group | WebSphere software
リモートのWebサーバーを管理する場合
V6 New
◆IBM HTTP Server とWebSphere Application Serverを別マシンに導入した場合◆
WebサーバーはIHS 管理プロセス経由で管理され、次の操作が管理コンソールから可能
①プラグイン構成の生成・伝搬
②Webサーバーの開始・停止
Node Agent経由と比べて、IHSログファイルの表示や構成ファイルの編集はできません。
※マシンBにNode Agentを導入し、ケース1と同様にNode Agent経由の管理を行うこともできます。ただしその場合は、マシ
ンBにもWebSphere Application Serverのラインセンスが必要となります
HTTPコマンド
コマンド
IHS
管理
Process
Node
Agent
HTTP(S)
HTTP(S)
Web
WebServer
Server
Plug-in
Module
Deployment
Manager
Plug-in
Config
XML file
マシンB
Application
Application
Server
Server
Node
マシン B
マシンA
29
リモートのWebサーバーマシン上にノード・エージェントを作成することで、Webサーバーマシンを管理ノードとしてデ
プロイメント・マネージャー経由で管理することが可能です。デプロイメント・マネージャーからHTTPコマンドが発行さ
れ、Webサーバー上のHIS管理プロセスを通してWebサーバーを管理します。
これにより以下のことが実施可能です。
・プラグイン構成の生成
・プラグイン構成の伝播
・Webサーバーの開始・停止、ログファイルの表示、構成ファイルの編集
29
IBM Software Group | WebSphere software
Webサーバープラグインについて
ƒプラグイン
プラグイン構成
プラグイン構成ファイル
構成ファイル(plugin-cfg.xml)にはプラグインがWASへのリクエストの割り振りを決定する情報が記
ファイル
述されている
ƒプラグインがリクエストの割り振りを正しく行うには、正しいプラグイン構成ファイルを参照
ƒWASのアプリケーション情報がプラグイン構成ファイルに反映されている必要がある
ローカル Webサーバー構成
ノード
プラグイン構成ファイ
ルの生成・更新
アプリケーション
・サーバー
Webサーバー
----------------
プラグイン
プラグイン
プラグイン構成ファイルを参照し
てリクエストの割り振りを決定する
プラグイン構成ファイル
（plugin-cfg.xml）
リモートWebサーバー構成
ノード
アプリケーション
アプリケーション
・サーバー
・サーバー
Webサーバー
プラグイン
プラグイン
ノード
----------------
プラグイン構成ファイル
（plugin-cfg.xml）
プラグイン構成
ファイルの伝搬
30
WebサーバーはユーザーからのリクエストをWASに送信しているのですが、この割り振りを担っているのがプラグイン
（Webサーバー・プラグイン）です。WAS上で稼動するアプリケーションとサーバーの情報はプラグイン構成ファイル
(plugin-cfg.xml)というXMLファイル記述されており、プラグインはWASが生成するプラグイン構成ファイルを参照して
リクエストをどのサーバーに割り振るのかを決定します。したがって、リクエストの割り振りを正しく行うには、プラグイ
ンが正しいプラグイン構成ファイルを参照する必要があり、またWASが正しいアプリケーションの情報をプラグイン構
成ファイルに反映させる必要があります。
プラグインがどのプラグイン構成ファイルを参照するのかはWebサーバーの持つ構成ファイル（IHSではhttpd.conf
ファイル）に記述されます。
WASに新規エンタープライズ・アプリケーションをインストールした場合には、プラグイン構成ファイルの更新を実施す
る必要があります。ローカルWebサーバー構成の場合にはプラグイン構成ファイルの生成・更新になりますが、Web
サーバーがWASとは別のマシン上にあるリモートWebサーバー構成の場合には、加えてプラグイン構成ファイルの伝
搬を実施してプラグイン構成ファイルをWebサーバーにコピーする必要があります。
30
IBM Software Group | WebSphere software
導入で問題が発生した場合は？
◆インストール・ログ・ファイルでエラーがないか調査。インストールおよびプロファイル作成状況は次のログファイルに記載されます
「 install_root/logs/log.txt 」ファイル
「 install_root/logs/wasprofile/wasprofile_create_profile_name.log 」 ファイル
「 profiles_root/profile_name/logs/pctLog.txt 」 ファイル
※インストールの初期にエラーが発生した場合は、システム一時領域の log.txt ファイルを参照 (Windowsでは %TEMP%¥log.txt）
インストール・プログラムは、インストールの最後に一時領域から logs ディレクトリーにログをコピー
ログ名称
内容
インディケーター
install_root/logs/log.txt
全てのインストールイベントを記
録
INSTCONFFAIL すべてのインストールの失敗
INSTCONFSUCCESS インストールの成功
INSTCONFPARTIALSUCCESS
インストール・エラーが発生しましたが、インストール・システムは使用す
ることができます。追加情報でエラーを識別します
install_root/logs/wasprofile/waspr
ofile_create_profile_name.log
名前付きのプロファイルの作成中
に発生するすべてのイベントをト
レースします。
プロファイル作成ウィザードまたは
wasprofile コマンドを使用した場
合に作成されます
install_root/profiles/profile_name/
logs/pctLog.txt
プロファイル作成ウィザードの使
用時に発生するすべてのプロファ
イル作成イベントを記録します
INSTCONFFAIL すべてのプロファイル作成の失敗
INSTCONFSUCCESS プロファイル作成の成功
INSTCONFPARTIALSUCCESS
プロファイル作成エラーが発生しましたが、プロファイルは機能していま
す。追加情報でエラーを識別します
INSTCONFFAIL すべてのプロファイル作成の失敗
INSTCONFSUCCESS プロファイル作成の成功
INSTCONFPARTIALSUCCESS
プロファイル作成エラーが発生しましたが、プロファイルは機能していま
す。追加情報でエラーを識別します
31
導入で問題が発生した場合には、必ずログ・ファイルを確認します。問題の原因を分析・除去してから、再度導入
手順を実行してください。また、ISMP（InstallShield for multiplatform) がインストール・ウィザードを開始できない場
合があります。このような場合、インストール・ウィザードの起動に十分なディスク・スペースがないことなどが考え
られます。インストールが失敗し、インストール・ログに情報がない場合は、-log パラメーターを使用して、ISMP プ
ログラムがインストール・ウィザードの開始に失敗する原因となるイベントのエントリーを記録することができます。
このようなイベントを記録するための install コマンドの構文は、以下のとおりです。
install -options fully_qualified_options_response_file_name
-silent
-log # !fully_qualified_log_file_name @ALL
31
IBM Software Group | WebSphere software
導入・構成における主要ログ
ログ名称
内容
startServer.log
開始サーバー・イベントのログ
プロセス単位
stopServer.log
停止サーバー・イベントのログ
プロセス単位
SystemOut.log
JVMの標準出力/ ログ解析の基本
プロセス単位
SystemErr.log
JVMの標準エラー出力/ ログ解析の基本
プロセス単位
activity.log
JVMログに詳細を追加したログ。ログアナライザーを用いて読み取る
ノード単位
プロファイル単位の/logsディレクトリ
IBM保守ログ
/logs以下にサーバー単位のディレクトリ
開始・停止ログ
JVMログ
InfoCenter（マニュアル）
InfoCenter（マニュアル） http://www-3.ibm.com/software/webservers/appserv/infocenter.html
トラブルシューティング」＞「タスクの概説」＞「タスクごとのトラブルシューティング」も参照ください
32
上記は、導入･構成における主要なログの場所と名前です。
特にWASV6からはプロファイルという概念が登場したため、ログディレクトリーの構成がWASV5とは異なっている
ことに注意してください。例えばアプリケーションサーバーが正常にスタートしたかどうかをチェックするための開
始・停止ログやJVMログは<WASインストールルート>/profiles/<プロファイル名>ディレクトリの下のlogsディレクトリ
に保管されるようになります。
ログの詳細については、7章の問題分析もご参照ください。
32
IBM Software Group | WebSphere software
練習問題
3. Webサーバー
サーバー(IHS)
をセルに
サーバーが
サーバー
セルに含めて管理
めて管理したいと
管理したいと考
したいと考えています。
えています。Webサーバー
サーバーがリモートサー
バー上
バー上にあった場合
にあった場合、
場合、管理できない
管理できない項目
できない項目は
項目は次のうちどれでしょうか
A. Webサーバーの開始・停止
B. プラグイン構成の生成・伝搬
C. 構成ファイル（httpd.conf)の編集
4. ウィザードを
の製品バイナリファイル
ウィザードを使用して
使用して、
して、WASV6.0の
製品バイナリファイルを
バイナリファイルをインストールしました
インストールしました。
しました。インストール
が完了した
完了した直後
した直後の
直後のアクションとして
アクションとして適切
として適切なものを
適切なものを選択
なものを選択してください
選択してください
A. プロファイルを作成するかどうか選択する画面が表示されるので、ここで作成するか後で作成するかを決定する
B. デフォルトでプロファイルが作成されるのでしばらく待つ
C. IHSの導入を促す画面が表示されるので、IHSのインストールを行う
5. インストール中
インストール中に、前提条件を
前提条件を満たしていないという理由
たしていないという理由で
理由でインストールが
インストールが失敗しました
失敗しました。
しました。次
のうちどのログファイル
のうちどのログファイルを
ログファイルを調べればよいでしょうか
A. install_root/logs/log.txt
B. install_root/logs/wasprofile/wasprofile_create_profile_name.log
C. %TEMP%¥log.txt
33
<memo>
33
IBM Software Group | WebSphere software
3章 アプリケーション・アセンブリーとデプロイメ
ントおよびサーバー・リソースの構成
34
<memo>
34
IBM Software Group | WebSphere software
アプリケーションのアセンブルとインストール
Webコンポーネント
(Servlet,JSP,
HTMLなど)
※EARへのパッケージングは
Rational Application Developer
でも可能
WAR
WAR
WebDD
EAR
EAR
EJBコンポーネ
ント
EJBDD
„JAR:Java ARchive File
„WAR:Web ARchive File
„EAR:Enterprise ARchive File
WAS
サーバー
JAR
JAR
Application
DD
AST（
（Application Server Toolkit)
を利用する
利用する部分
する部分
作成したプログラムはJ2EEアプリケーションにパッケージングしてからアプリケーション
サーバーにインストール必要があります。
ASTはパッケージングの部分を行うツールキットです。
35
J2EEで作成したモジュールを実際にJ2EEアプリケーションとしてWebSphere Application Serverに導入する方法には大
きく分けて二つのプロセスがあります。ひとつは作成したモジュールのJ2EE形式でのパッケージング、そしてもうひとつ
はパッケージングされたモジュールのインストールです。JSPやServlet、HTMLや画像ファイルなどはWebARchiveファイ
ル（WAR）形式でパッケージングします。EJBモジュールはJavaARchiveファイル（JAR)形式でパッケージングします。こ
れらのファイルをEnterpriseARchiveファイル（EAR)形式にまとめます。
これでJ2EEアプリケーションとしてインストールできる形になります。ここまでのプロセスは開発ツールであるRational
Web DeveloperおよびRational Application Developerで行うこともできますし、WebSphere Application Serverに付随の
AST (Application Server Toolkit)で行うことも可能です。
次のプロセスはEARファイルのインストールです。WebSphere Application Serverではブラウザー形式の管理コンソール
がついています。
この管理コンソールを用いて、EARファイルをWebSphere Application Serverにインストールします。管理コンソールから
「アプリケーション」→「新規アプリケーションのインストール」を選択し、ステップに沿って順に設定していくと容易にイン
ストールすることができます。ステップの最後には要約画面が出てきますので内容を確認し問題がなければ保管して
構成情報を反映させます。
35
IBM Software Group | WebSphere software
AST(Application Server Toolkit)の機能
J2EEモジュールのアセンブリー
ƒEJBモジュール(.jar)
ƒWebモジュール(.war)
ƒアプリケーション・クライアント・モジュール(.jar)
ƒリソース・アダプター(.rar)
J2EEアプリケーションのパッケージング
Enhanced EAR機能
機能
V6 New
EARファイルの中に、データソースなどのリソース定義まで含める
ことにより、デプロイメントの際に必要になる情報を削減します。
ASTではEnhanced EAR をサポートするため、エンタープライズ・
アプリケーションのデプロイメント記述子エディターに新規ページが
追加されました。このページでサーバー構成を指定することにより
その情報がアプリケーションそのものの内部に組み込まれます。
デプロイメント・ディスクリプター(DDファイル）の編集
IBMバインディング情報(ibm-xxx-bnd.xmi)の編集
IBM拡張(ibm-xxx-ext.xmi)の編集
WASではJ2EEを拡張した機能がサポートされています。これらの機能は追加の構成情報として次のファイルに
記載されます
¾IBMバインディング・ファイル(ibm-xxx-bnd.xmi)
ibm-application-bnd.xmi・ibm-ejb-jar-bnd.xmi・ibm-web-bnd.xmi・ibm-application-client-bnd.xmi
¾IBM拡張・ファイル（ibm-xxx-ext.xmi)
ibm-application-ext.xmi・ibm-ejb-jar-ext.xmi・ibm-web-ext.xmi・ibm-application-client-ext.xmi
36
ASTは作成したモジュールをアプリケーション・サーバーにインストールできる形式、いわゆるエンタープライズアプリ
ケーション形式（EARファイル）にパッケージングするためのものです。
パッケージングにはモジュールのほかにディプロイメント・ディスクリプターファイル（DDファイル）が必要ですがこれら
を編集することも可能です。
またWASV6ではEnhancedEARという機能が新規に追加されました。これはEARファイルにデータソースなどのリソー
ス定義を含めることができるというものです。これによりアプリケーション・サーバーインストール時の、デプロイ作業
が軽減されます。
ASTではEnhancedEARをサポートするためにこれらのリソース情報を定義するページができました。これはアプリ
ケーション・デプロイメント記述子エディターに新規ページとして追加されています。
36
IBM Software Group | WebSphere software
ASTによるモジュールへのセキュリティロール割り当て
zなぜセキュリティロール（役割）が必要か？
Servlet 1
Aさん
個々のユーザー単位で設定していては
人事異動の際など膨大なワークとなる
Servlet 2
Bさん
Cさん
Servlet 3
Servlet 4
ASTでは役割と必要とするモジュールに役割を定義することが可能
役割
A1/A2/A3
制約
人事部門の役割
勤務記録承認
各部門長の役割
交通費承認
営業部門長の役割
契約書承認
B1/B2
Servlet 1
Servlet 2
Servlet 3
Servlet 4
C1/C2
アクセス可能なパターン
(役割マッピング）
役割という
役割という一種
という一種の
一種のグループを
グループを決めておくことでメンテナンス
めておくことでメンテナンスが
メンテナンスが楽になる
37
ASTではモジュールにセキュリティロール(役割）を割り当てることができます。
セキュリティロールとはモジュールに使用権限を与える単位を個人ではなくグループで与えるといったものと考えて
いただいてもよいでしょう。
こうしておけば人事異動の際にも権限の変更作業を削減することができます。
37
IBM Software Group | WebSphere software
WebSphere Rapid Deployment Tool (WRD)
V6 New
ƒ アプリケーションの開発とデプロイメントを効率化する機能
Annotation-based programming
ƒ プログラミングの簡略化
Deployment Automation
ƒ アプリケーションのデプロイメントや更新の自動化
Deployment Automationを使うと、ユーザーが定義したディレクトリにあるファイルやモジュールに変更を加えると、それを自動検知
し、稼動中のアプリケーション・サーバーにデプロイして変更内容を反映してくれます
①ユーザーは、
ƒエンタープライズ・アプリケーション (EAR ファイル)
ƒアプリケーション・モジュール (WAR ファイル、EJB JAR ファイル)
ƒJavaソース・ファイル、Java クラス・ファイル、イメージ、XML または HTMLファイル
をモニター対象 ディレクトリーと呼ばれるユーザーディレクトリに置いておきます。
②高速デプロイメント・ツールは、これら J2EE 成果物の追加部分または変更部分を自動的に検出し、サーバーで
実行できるアプリケーションを作成し、ターゲット・サーバーにデプロイします。
このツールではAutomatic installation(自動インストール）とFree Formの2つのスタイルが指定できます。
Automatic installation ⇒EAR単位やWAR,JARといったモジュール単位で変更を加える場合に使います。
Free Form ⇒クラスファイルやHTMLファイルなど個々のファイル単位で変更を加える場合に利用します
詳細はInfocenterのこちらをご覧下さい
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.etools.wrd.freeform.doc/topics/rwrdconfbat.html
38
WebSphere Rapid Deploymentは、アプリケーションの開発とデプロイメントを効率化する機能です。Annotation-based
programmingは、プログラミングを簡略化するための機能です。Annotation-based programmingの機能を詳しく説明し
ます。まず、開発者は、1つのJavaソースファイルに、必要な情報をannotation(注釈)として記述します。WebSphere
Rapid Deployment機能は、これを受け、アプリケーションの稼動に必要な他のJavaソースファイルを自動生成します。
基のソースファイルに変更が加わると同期的に反映させる機能も含まれています。この機能により、開発者が作成・
保守しなければならないソースファイルの数を削減することが可能となります。
Deployment automationは、アプリケーションのデプロイメントや更新を自動化することができます。これは指定された
ディレクトリに変更があったファイルやモジュールをおいておくと自動的に検知し、アプリケーション・サーバーにデプ
ロイしてくれるというものです。モジュール単位とファイル単位の変更の両方がサポートされています。
38
IBM Software Group | WebSphere software
リソース定義スコープ
セル
クラスター
ノード
スコープのオーバーライド階層
サーバー
アプリケーション
リソース：JDBCプロバイダー定義画面
セル
セル
ノード
ノード
クラスター
クラスター
サーバー
サーバー
エンタープライズ･アプリケーション画面
Enhanced
EAR
アプリケーション
アプリケーション
39
リソースのJDBCプロバイダー設定の有効範囲として『スコープ』を指定します。例えばセル･レベルのスコープでリソー
スを定義するとそのリソースは全てのプロセスから使用可能ですが、ノード･レベルでリソースを定義するとそのリソー
スは定義したノード以外のノードでは使用できないことになります。『スコープ』はセル、クラスター、ノード、サーバー、
アプリケーションの五階層となります。
中央の画面コピーで見て取れるように、管理コンソールから定義可能な階層はクラスターを含めた4つです（先にクラス
ターを定義しないと三階層しか現れません）。ではアプリケーション･スコープのリソース定義とはどのように定義するの
でしょうか？これはEnhanced EARというEARの中にリソース構成情報なども含んだ拡張エンタープライズ･アプリケー
ションで定義します。Enhanced EARを作成するのはRational Application Developerですが、ターゲット･サーバーを
WAS V6とするとデフォルトでEnhanced EARを作成するので、DDにテスト用のリソース定義などを入れ込んでいる場合
にはデプロイ時に注意が必要です。管理コンソールではアプリケーション･スコープの定義情報を作成・変更することは
出来ないのでApplication Server Toolkitやwsadminを使用して変更を行うことになります。右下の画面コピーは導入さ
れたEnhanced EARを参照した際に出るメッセージで、「このアプリケーションにはひとつ以上のアプリケーション有効範
囲リソースが含まれている」旨の記載がされています。
同名のリソースを定義した場合はアプリケーションに近いほうの定義が使用されます。
つまり同じWebSphere変数”DB2_JDBC_DRIVER_PATH”をスコープ：セルとスコープ：ノードの双方で定義した場合、ノー
ドの定義が優先して使用されます。これをスコープのオーバーライド階層と言います。
39
IBM Software Group | WebSphere software
ネーミングサービス（Naming Service）
ƒ
ネーミングサービスとは
オブジェクトと名前を関連づけ、その名前をキーとしてオブジェクトを検索するためのサービス
ƒ
ネームスペース（Name Space/名前空間）
ネーミングサービスにおいて、オブジェクトが格納されている空間
ネーミングサービスから検索されるオブジェクトはネームスペースに階層的に格納される
ƒ
J2EEにおけるネーミング・サービス
アプリケーションコードから外部リソースへの統一されたアクセス環境を提供
JNDI（Java Naming and Directory Interface）を使用する
データソースを使用するアプリケーションのコードの一部
DataSource ds =
(DataSource)ctx.lookup("java:comp/env/jdbc/DataSource1");
ディプロイメントディスクリプターでリソース参照「jdbc/DataSoruce1」を作
成し、これを実際のJNDI名「jdbc/Sample」にバインドする
Naming Service
DataSource
JNDI名: jdbc/Sample
“Sample”
Database
40
ネーミング・サービスとはオブジェクトと名前を関連づけ、その名前とキーとしてオブジェクトを検索するためのサービ
スです。ネーミング・サービスにおいて、オブジェクトが格納されている空間をネーム・スペース（名前空間）といいます。
J2EEにおけるネーミング・サービスは、JNDI（Java Naming and Directory Interface）を使用して、アプリケーション・
コードから外部リソースへの統一されたアクセス環境を提供しています。
JNDIで取得する対象としては、リソース参照、EJB参照、UserTransaction参照があります。
「参照」の使用
JNDIクライアントにおいてlookup を行う際は、lookupするオブジェクトの名前の記述フォーマットとして
[ java:comp/env/ ]コンテキストを先頭につけた形とすることが原則です。デプロイ時に、「参照」を実際のJNDI名にバ
インドします。
「参照」の例
EJB参照：java:comp/env/ejb/…
リソース参照：
－JDBC DataSourceへの参照：java:comp/env/jdbc/.
40
IBM Software Group | WebSphere software
ネームスペースとデータソース
Deployment Manager (dmgr) は同じ物理ノードに
あっても他のプロセスとは別論理ノード扱いになる。
物理ノード(ホスト名: gonta)
プロセスごとにネームスペースを持つ
論理ノード
(ノード名: gontaNode)
プロセス名
node
agent
server1
Bootstrap Port
2809
9810
論理ノード
(ノード名: gontaManager)
server2
dmgr
9811
9809
DS1
DS1
データソース「DS1」を定義するJDBCプロバイダーの有効範囲設定
セルレベル
DS1
DS1
ノードレベル(gontaManager)
ノードレベル (gontaNode)
DS1
DS1
クラスターレベル (ClusterA)
DS1
DS1
サーバーレベル (server1)
DS1
ClusterA
41
有効範囲の選択と、作成されるデータソースの関係を図にしたものです。
JDBCプロバイダー作成時の有効範囲
管理コンソールで、「リソース > JDBCプロバイダー」を作成するときに指定する有効範囲(セル・ノード・クラス
ター・サーバー)によって、データソースが登録されるネームスペースのプロセスが異なります。
データソース「DS1」を定義するJDBCプロバイダーの有効範囲が
「セルレベル」のときDS1はserver1, server2, dmgrのネームスペースに登録される
「ノードレベル(gontaManager)」のときDS1はdmgrのネームスペースに登録される
「ノードレベル(gontaNode)」のときDS1はserver1, server2のネームスペースに登録される
「クラスターレベル（ClusterA)」のときDS1はserver1、server2のネームスペースに登録される
「サーバーレベル (server1)」のときDS1はserver1のネームスペースに登録される
JDBCプロバイダーの作成におけるデフォルトの有効範囲はDMのノードになっているので注意が必要となりま
す。
「有効範囲」はどのプロセスに対してデータソースを定義するか、の選択
有効範囲の違いによって、あるプロセスがもつネームスペース内の登録のされ方が変わるわけではない
（階層構造は決められている）。
例えば、server1に登録されるデータソース「DS1」は 「セルレベル」 「ノードレベル(gontaNode)」 「サー
バーレベル (server1)」いずれの有効範囲を選択したときも、「 (最上
位)/nodes/gontaNode/servers/server1/jdbc/DS1 」となる。
また、最大接続数が10と指定されているデータソースの場合、各アプリケーション・サーバー単位で最大10接続が有
効になります。このデータソースの有効範囲がセルレベルで定義されていた場合でも、各サーバー毎に最大10接続
有効であり、セル全体で10接続に限定されるわけではありません。
41
IBM Software Group | WebSphere software
J2C:J2EE Connector Architecture
ƒ J2Cの
の目的
J2EE1.3～の構成要素
EIS接続のための統一インターフェイス
接続先エンタープライズシステムの違いを吸収し、同一の手法でアクセスを実現
ƒ リソース・
Adapter)
リソース・アダプター(RA:Resource
アダプター
J2C接続のキー・コンポーネント
RAR（Resource Adapter Archive)ファイルの形態で提供
ƒ 共通プロパティ
共通プロパティ – Common Client Interface(CCI)
Connection Factory
Connection Spec
InteractionSpec
Record
ƒ System Contract
セキュリティ管理
トランザクション管理
コネクション管理
※EIS: Enterprise Information System
42
J2CとはCICSやIMSといったいわゆるEnterprise Information Systemに接続するための統一化されたインターフェイ
スになります。
J2EE1.3からサポートされています。
J2Cがあることにより、接続先のEISが何であろうと意識せずに統一した手法（API）を使ってアクセスすることが可能
です。
J2Cを利用するためには接続先のEISに対応したリソースアダプター(ランタイム）が必要です。これはRARファイル
の形でEISから提供されています。これをJ2EEサーバーに組み込んで使用します。
42
IBM Software Group | WebSphere software
練習問題
6. ASTを
を利用して
利用して作成
して作成した
作成したモジュール
したモジュールを
モジュールをパッケージングしようとしています
パッケージングしようとしています。
しようとしています。リソース定義
リソース定義も
定義も含めた
拡張EARファイル
ファイル（
形式）
拡張
ファイル（Enhance EAR形式
形式）を作成したいのですが
作成したいのですが、
したいのですが、次のうち正
のうち正しい手順
しい手順はどれで
手順はどれで
しょうか
A. 管理コンソールを利用してリソース定義をしてから、ASTを起動しパッケージング作業終了後、拡張EAR形式
にてエキスポートする
B. ASTで作業中にアプリケーションデプロイメント記述子エディターを開き、デプロイメントページでリソース定義
をし、拡張EAR形式でエキスポートする
C. ASTで各モジュール（WARファイル,JARファイル）を開き必要なリソースを定義し、それぞれ構成情報が含ま
れた状態のモジュールをEARに含めて、拡張EAR形式でエキスポートする
7. JDBCプロバイダー
プロバイダーが
プロバイダーがセルと
セルとノード両方
ノード両方の
両方のスコープで
スコープで定義されており
定義されており、
されており、重複する
重複するデータ
するデータ・
データ・ソース
が両方に
ファイルでも
両方に定義されています
定義されています。
されています。さらに拡張
さらに拡張EARファイル
拡張
ファイルでも同
でも同じデータソースが
データソースが定義されていま
定義されていま
す。この場合
この場合、
場合、優先して
優先して使用
して使用される
使用されるデータソース
されるデータソースはどれになりますか
データソースはどれになりますか？
はどれになりますか？
A. セルで定義されたデータ・ソース
B. ノードで定義されたデータソース
C. 拡張EARファイルで定義されたデータソース
8. WASをある
をあるEIS（
（Enterprise Information System)に
にJ2Cで
で接続しようと
をある
接続しようと考
しようと考えています。
えています。EIS
ベンダーからは
サーバーに
ベンダーからはリソースアダプター
からはリソースアダプターも
リソースアダプターも入手して
入手してJ2EEサーバー
して
サーバーに組み込み使用しようとしてい
使用しようとしてい
ます。
ます。次のうち、
のうち、実現できない
実現できない機能
できない機能はどれですか
機能はどれですか？
はどれですか？
A. J2EEコンポーネントからEISへ統一化された手法で接続できる機能
B. 共通クライアント・インターフェイス（CCI)を実装するための機能
C. WASとともにトランザクション管理やメッセージングなどのサービスを提供する機能
43
<memo>
43
IBM Software Group | WebSphere software
4章 セキュリティー
44
<memo>
44
IBM Software Group | WebSphere software
WASセキュリティー
45
WebSphereで提供されるセキュリティーは、階層構造の上に成り立っています。
・OSレベル
ファイルやプログラムの実行権限などのセキュリティー機能。WASはOS上の１プロセスとしてのアクセス制限を
受けます。
・JVM
JVMで提供されるセキュリティー機能
・Java2セキュリティー
スレッド、ソケット、ファイルなどのJava2レベルで提供されるシステムリソースへのアクセス制御。WAS自体Java
プログラムなので、Java2のセキュリティー制限下で動作します。
・CORBA Security
J2EEは分散環境を前提にしており、分散オブジェクト間のトランスポート、メッセージ層のセキュリティーは
CORBA/CSIv2で提供されるセキュリティー機能を前提にしています。
・J2EE Security API
WASのセキュリティー機能はJAASなどのJ2EE APIをベースにしています。
ポリシー、ロール（役割）ベースのWASセキュリティー機能はこれらのセキュリティー機能の上で動作しています。
・WebSphereセキュリティー
WebリソースやEJBにアクセスするために、ポリシーやサービスを提供します。通常、WASのセキュリティーと
言った場合、この層を表します。
WASの設定でグローバル・セキュリティーをオンにすることで、 セキュリティー・ドメイン全体で有効なセキュリ
ティーを設定できます。
この資料ではWebSphereセキュリティーとWASセキュリティーを同じ意味で扱います。以後WASセキュリティーと
記載します。
45
IBM Software Group | WebSphere software
WASセキュリティーの設定
ƒ
グローバルセキュリティーを使用可能にします。
ƒ
設定を変更した際には、各実行環境の再始動が必要になる。
ƒ
アクティブ・プロトコル
Common Secure Interoperability Version 2 (CSIv2)
Security Authentication Service (SAS)
ƒ
アクティブな認証メカニズム
Simple WebSphere Authentication Mechanism (SWAM)
Lightweight Third Party Authentication (LTPA)
ƒ
アクティブなユーザー・レジストリー
ローカル OS
LDAP ユーザー・レジストリー
カスタム・ユーザー・レジストリー
46
WASセキュリティーを使用するには、 WASの設定でグローバル・セキュリティーを使用可能にする必要があります。
またセキュリティーに関する設定を変えた場合には、その設定を有効にするために、セキュリティー・ドメイン全体＊を再始動させる必要
があります。（＊アプリケーション・サーバー、ノード・エージェント、および デプロイメント・マネージャー）
アクティブな
アクティブなプロトコル
セキュリティーが使用可能になっている場合の、Remote Method Invocation over the Internet Inter-ORB Protocol (RMI IIOP) 要求の
ためのアクティブな認証プロトコルを指定します。
Common Secure Interoperability Version 2 (CSIv2) と呼ばれるオブジェクト管理グループ (OMG) はさらなるベンダー・インターオペラビ
リティーおよび追加機能をサポートします。
セキュリティー・ドメインに含まれるすべてのサーバーがバージョン 5.x のサーバーの場合、プロトコルとして CSI を指定します。
バージョン 3.x またはバージョン 4.x のサーバーが存在する場合には、「CSI および SAS」を指定してください
アクティブな
アクティブな認証メカニズム
認証メカニズム
セキュリティーが使用可能になっている場合のアクティブな認証メカニズムを指定します。
WebSphere Application Server および WebSphere Application Server Express バージョン 6.0.x では、Simple WebSphere
Authentication Mechanism (SWAM) および Lightweight Third Party Authentication (LTPA) という認証メカニズムがサポートされていま
す。
アクティブな
アクティブなユーザー・
ユーザー・レジストリー
セキュリティーが使用可能になっている場合のアクティブなユーザー・レジストリーを指定します。UNIX 非ルート・ユーザーとして実行す
る場合や、マルチノード環境で実行する場合は、LDAP またはカスタム・ユーザー・レジストリーが必要です。以下のユーザー・レジスト
リーのうちの 1 つのみ設定し、構成することができます。
・ローカル OS
UNIX プラットフォームでグローバル・セキュリティーを使用可能にし、さらにユーザー・レジストリーがローカル OS である場合は、サー
バーをrootとして実行する必要があります。ローカル OS のユーザー・レジストリーは、UNIX プラットフォーム上の非ルート・ユーザーに
対してはサポートされていません。 またWAS ND環境の場合には、複数サーバーでセキュリティー・ドメインを形成するので、ローカル
OSは使用できません。
・LDAP ユーザー・レジストリー
ユーザーおよびグループが外部 LDAP ディレクトリーに置かれている場合には、LDAP ユーザー・レジストリーの設定値が使用されま
す。
.・カスタム・ユーザー・レジストリー
詳しくはInfoCenterをご参照ください。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/usec_rgsp.html
46
IBM Software Group | WebSphere software
WAS運用管理セキュリティー
ƒ
管理コンソールのセキュリティー
デフォルトではセキュリティーなし
グローバルセキュリティーにより、ログインが必要になる
ƒ
4つの管理ロールでWAS管理機能の実行権限を定義
管理者
ƒ
ƒ
コンフィギュレーター、オペレーター、モニターに与えられる権限
サーバー・パスワード、LTPAパスワード、鍵など重要データへアクセスする権限
コンフィギュレーター
ƒ
モニターに与えられる権限
ƒ
WASの構成を変更する権限
オペレーター
ƒ
ƒ
モニターに与えられる権限
アプリケーションの開始/停止などランタイム状態を変更する権限
モニター
ƒ
WASの構成およびランタイム状態を見るだけの権限
47
管理コンソールやwsadminスクリプトのツールを使用して、WASを管理するための、特定の権限をユーザーに与えることが出来ます。
この権限はグローバルセキュリティーを使用可能することにより、有効になります。
管理ロールには、管理者、コンフィギュレーター、オペレーター、モニターの4種類あり、それぞれの管理ロールによってWASの管理
機能に対する実行権限が定義されています。
管理者は、最も権限のある管理ロールです。コンフィギュレーター、オペレーター、モニターに与えられている権限がある上に、サー
管理者
バー・パスワード、LTPAパスワード、鍵などといった重要なデータへアクセスする権限があります。
コンフィギュレーターには、モニターに与えられる権限がある上に、WASに関する構成を変更する権限があります。
コンフィギュレーター
オペレーターには、モニターに与えられる権限がある上に、WASのアプリケーションの開始/停止などといったランタイム状態を変
オペレーター
更する権限があります。
モニターは、最も権限のない管理ロールです。WASに関する構成やランタイム状態を見るだけの権限があり、構成変更などの操作
モニター
は一切することができません。
47
IBM Software Group | WebSphere software
WASセキュリティ:ユーザー認証
ƒ
Web Client
Web Client は次のうちどれかのメカニズムを使用してユーザー認証できる。
ƒ 基本(Basic)認証
ƒ
ƒ
ƒ
クライアント認証（クライアント証明書）
Form認証
Application Client
クライアント・コンテナ内で実行されるJavaアプリケーション
直接EJBとやりとりするServlet
メッセージ層(CSIv2/SAS)の認証情報
ƒ ユーザーID/パスワード(GSSUP(Generic Security Service) Username Password )
ƒ アイデンティティ情報
ƒ アクセス許可情報
ƒ クライアント証明書(SSL)
WebコンテナからのEJB呼び出しの場合、Webコンテナの認証はWASによって内部的に行わ
れる。
ƒ システムユーザーID, パスワードが付加されて送られる。
48
WAS上の2種類のリソース、WebモジュールとEJBモジュールはそれぞれWebクライアント、Applicationクライアントから
アクセスされますが、
それぞれについての認証方式は、Webコンテナーの場合、
①基本(Basic)認証
②クライアント認証(クライアント証明書）
③Form認証
がサポートされます。
EJBの場合も、クライアントを認証する仕組みをもっており、正しいユーザーID・パスワードをもつものしかアクセスでき
ないようにすることができます。
これはCSIv2プロトコルのなかでセキュリティー情報を伝達する仕組みの上で実現されています。
使用されるユーザーIDやパスワードなどは、WASの管理コンソースやWebデプロイメント・ディプロィメントディスクリプ
タやアプリケーションのディプロイメント・ディスクリプタのなかに設定されたり、Webクライアントから入力された情報が
EJBまで伝達される仕組みになっています。
48
IBM Software Group | WebSphere software
WAS上の各リソースのアクセス制御
ƒ
J2EE ロールベースのアクセス制御
Servlet, JSP, Enterprise Beanなどのリソースへのアクセスはロール（役割）によってコン
トロールされる（EJBもほぼ同様）
ロールと各リソースのメソッドの組合せによりアクセス権を設定
ロールと実際のユーザーID, グループIDをマップ
運用上変更が頻繁におきるユーザー管理、セキュリティー管理とプログラムを分離する。
J2EE
GET
一般ユーザー
Webリソース
Servlet,jsp,html
web.xml
GET
POST
実際の
ユーザー
ロール
グループ
プレミアユーザー
49
ユーザー認証を検討した後には、そのユーザーがどのリソースを触ることができるかというアクセス制御を考える必要があります。
WAS上のリソースへのアクセス制御はJ2EE Authorizationモデルに基づいて行われます。
ServletやJSP、静的コンテンツなどのWebリソースへのアクセス制御はというアプリケーションの中での概念に基づいて制御されます。
アクセス権限は、それぞれのリソース(servletなど）に対し、どのロールに、どのようなアクセスを許す、という組合せで設定されます。
たとえば、AというServlet は一般ユーザーであればアクセス可能で、Bというservletはプレミアユーザーのみアクセス可能としたいとします。
この時の設定のイメージは次のようになります。
servletA allusers GET, POST
servletB premium GET,POST
ロールと実際のユーザーの関連付けは別に行います。
このように実際のユーザー環境とアプリケーションを分離することにより、ユーザー環境の変化にプログラムが影響を受けることがないような構造となっ
ています。
これらの設定はアプリケーションをビルドする際にデプロイメント記述子に組み込まれますが、インストール後に変更することも可能です。
Webリソースの場合、セキュリティー制約という概念があり、Web コンテンツの保護方法を決定します。
制約は、Web リソース・コレクション、許可制約、およびユーザー・データ制約で構成されます。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/csec_secc.html
EJBの場合も基本的にWebモジュールの場合と同様です。
コンテナレベルで提供されるセキュリティーは、XMLベースで記述されたセキュリティーポリシーにしたがって提供されます。
アプリケーションは変更を行うことなく、これらの設定にしたがってコンテナレベルの保護を受けます。
セキュリティー関連の設定は上記ファイルに反映されています。
web.xml
認証方式(Basic/Form/クライアント証明書)
セキュリティー制約(Security Constraint)
リソースコレクション --- URLとメソッドのセット
アクセスできるロール
RunAs設定
ejb-jar.xml
ロールと許可されているEJB, メソッド
RunAs設定
ibm_application_bind.xml
ロールとuser、groupのバインデング情報
49
IBM Software Group | WebSphere software
SSL暗号化の流れ
Client
暗号化仕様交渉
サーバ認証
サーバ
認証
サーバ証明書送付
Server
AAWWARD
ARD C
CERTIFICATE
ERTIFICATE
We a ppre ciate your contributions to our organiza tion.
In re cogniti on of valuable achievements a nd ha rd work,
we gladly present thi s certific ate of award.
TED TO:
PRESEN
PRESENT
ED TO :
CA's Signature
this
by
FW
クライアント
証明書
d ay o f
, 199 ,
Type na me here
鍵生成の元データ交換
共通鍵生成
クライアント証明書
検証情報送付
クライアント認証
クライアント
認証
暗号化データ通信開
始
FW
50
SSLとはSecure Sockets Layerの略で、Netscape Communications社により開発されたプロトコルです。もともとSSL
は、ソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではありません。
しかし、現状はWebにおける認証および通信の暗号化に最も多く使用されています。SSLはTCP/IPの上で実現され、
その上でHTTPやLDAPなどのアプリケーションプロトコルが動いています。
クライアント＊にとサーバー間の認証はサーバー認証とクライアント認証があります。
＊クライアントとはユーザー（Webブラウザ）だけでなく、サーバーもなりえます。例えば、クライアント：Webサーバー・
サーバー：WASも考えられます。
サーバー認証
サーバー認証
サーバーが信頼されたものであることを証明するために使用します。（ウェブサイトの運営主体である法人組織の実
在性を証明）
通常、外部 CA プロバイダーから証明書を購入します。
ウェブサイトと証明書のサーバ名（コモンネーム）が一致、証明書のステータスがValid（有効）となっていれば、サー
バ証明書によって該当ページが認証されているといえます 。
クライアントは、ブラウザにインストールされているルート証明書で署名を確認し、サーバ認証を行います。（成りすま
し防止）
クライアント認証
クライアント認証
Web サイトの閲覧者が自分のアイデンティティを証明するために使用します。クライアントは、クライアント証明書を
サーバへ送信します。
<クライアント証明書>
ユーザーが使用しているコンピュータ上のファイルに格納されている暗号化された情報。利用者名や利用者が所属
する組織など個人を証明する情報が格納されています。
証明書はさまざまな認証局から入手することができます。サーバ側が信頼していない認証局から発行された証明書
を持っていても、そのサーバにはアクセスできません。
50
IBM Software Group | WebSphere software
IHS-WAS間で行うSSL通信
ƒ
Webサーバープラグイン
Webサーバーのプロセス内で稼働し、アプリケーション・サーバーへの要求をフォワード
ƒ
WebサーバープラグインとHTTPトランス
ポート間でSSLの設定も可能
ƒ
Webサーバープラグインには
Application Server
plugin-key.kdbというキーファイルがあり、
WASから抽出した証明書を追加することで、
SSL通信を行うことができます。
Web
サーバー
Webサーバー
プラグイン
ネーミングサービス
Web
コンテナー
HTTPトラン
スポート
pluginKey.kdb
EJB
コンテナー
JMS
プロバイダー
サーバー証明書
サーバー証明書
追加
51
○Webサーバー・プラグイン
受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへリクエストを転送します。
HTTPプラグインとも呼ばれます
○HTTPトランスポート
Webサーバープラグインから送られてくるHTTP通信の受け口です。問題切り分けのために直接アクセスすることもあり
ます。
WebサーバープラグインとHTTPトランスポート間でSSLの設定が可能です。
例えば、サーバー認証をする場合を考えて見ましょう。
① WAS 用のサーバー・キーファイル（例 ServerKey.jks） を作成して証明書をファイル（例 ServerKeyCert.arm）に抽出し
ます。
② IHS プラグイン用のキーファイル（plugin-key.kdb）がデフォルトではありますので、サーバー・キーファイルから抽出し
た証明書「ServerKeyCert.arm」を追加します。
＊IHSのプラグインキーファイルは新規に作成することも出来ます。その際は、plugin-cfg.xmlを変更する必要があります。
51
IBM Software Group | WebSphere software
練習問題
9. 管理コンソール
の構成変更、
管理コンソールを
コンソールを使用して
使用して、
して、WASの
構成変更、アプリケーションの
アプリケーションの起動/停止
起動 停止を
停止を行
う必要があります
必要があります。
があります。必要な
必要な管理役割は
管理役割は次のうちどれですか？
のうちどれですか？
A. モニター
B. コンフィギュレーター
C. 管理者
D. オペレーター
10. 複数サーバー
複数サーバーで
サーバーでセキュリティー・
セキュリティー・ドメインを
ドメインを形成している
形成している場合
している場合、
場合、使用できない
使用できない
ユーザー・
ユーザー・レジストリーは
レジストリーは次のうちどれですか？
のうちどれですか？
A. ローカルOS
B. LDAP ユーザー・レジストリー
C. カスタム・ユーザー・レジストリー
52
<momo>
52
IBM Software Group | WebSphere software
5章 ワークロード管理
53
<memo>
53
IBM Software Group | WebSphere software
WAS ND環境でのノードの統合
ƒ
デプロイメント・マネージャーにアプリケーション・サーバー・ノードを統合
管理コンソール
addNodeコマンド
wsadmin
ƒ
作業の順序(管理コンソールの場合）
デプロイメント・マネージャーの起動
アプリケーション・サーバーの起動
デプロイメント・マネージャー管理コンソール上でノードを統合する
ƒ 管理対象ノード・接続はSOAP通信
追加されたノードの確認
アプリケーション・サーバーの始動と稼動確認
54
デプロイメント・マネージャープロファイルとアプリケーション・サーバーした後、デプロイメント・マネージャーにアプリケー
ション・サーバーノードを統合します。
<作業の順序>
1．デプロイメント・マネージャーの起動
2．アプリケーション・サーバーの起動
3．デプロイメント・マネージャー管理コンソール上でノードを統合する
「ホスト」にアプリケーション・サーバーの稼動しているホスト名、「JMXコネクター・ポート」に77で定義した「SOAPコネク
ター・ポート」の番号を入力します。「アプリケーション を組み込む」をチェックして「OK」をクリックします。
4． 追加されたノードの確認
5． アプリケーション・サーバーの始動と稼動確認
アプリケーション・サーバーは停止していますので、始動します。server1の左のチェックボックスをチェックし、始動ボタン
を押します。
別のWebブラウザから
http://<ホスト名>:xxxx/snoop
へアクセスします。結果が正常に表示されれば、アプリケーション・サーバーの起動は成功です。
54
IBM Software Group | WebSphere software
クラスター / クラスター・メンバー
クラスター・メンバーと呼ばれるアプ
リケーション・サーバーのグループ
クラスター・メンバー上では同じ
J2EEアプリケーションを実行
クラスターを作成することにより、負
荷分散・スケーラビリティ・フェイル
オーバーが可能
１つのセル上では複数のクラスター
を作成することが可能
同一マシンで複数のメンバーが可能
（垂直クラスター）
複数マシンにまたがったメンバーが
可能（水平クラスター）
異なるOSにおけるクラスターも可能
（z/OS除く）
WAS V6とV5 ノードの複合クラス
ターも可能
Deployment
Manager
NodeAgent
NodeAgent
Cluster
Application
Application
Server
Server
Cluster
Cluster
Member
Member
Cluster
Cluster
Member
Member
Cluster
Cluster
Member
Member
Node
Cluster
Cluster
Member
Member
Application
Application
Server
Server
Node
Cell
55
WAS NDでサポートされるクラスターは、クラスター・メンバーと呼ばれるアプリケーション・サーバーのグループです。ク
ラスターを構成することで同じJ2EEアプリケーションが稼動するアプリケーション・サーバーを容易に構成することが可
能となります。
同じクラスターのメンバー間では、負荷分散・フェイルオーバーがサポートされますので、クライアントから見ると１つの
アプリケーションに対するパフォーマンス・可用性が向上します。また、クラスター・メンバーの追加構成により必要なと
きにシステムを容易に拡張することができます。
クラスターは１つのセル内に複数構成可能であり、用途によって様々なクラスターを構成することができます。同一マ
シン内で複数のメンバーを作成し、プロセス障害に対応するための垂直クラスターや、複数マシンにまたがったメン
バーを作成することでパフォーマンス・可用性を高める水平クラスターというのが考えられ、垂直クラスター、水平クラ
スターを組み合わせるなど自由に構成できます。
また、クラスターは異なるOSにまたがったクラスターや、V6とV5を組み合わせるということも可能となります。
55
IBM Software Group | WebSphere software
クラスター設定
EJBコンテナー
コンテナーWLMの
の際の
コンテナー
ローカルノード優先設定
優先設定
ローカルノード
HAマネージャー
マネージャーにおける
マネージャーにおける
パーシスタント・
・サービス
パーシスタント
のフェイルオーバー設定
フェイルオーバー設定
（トランログフェイルオーバー）
トランログフェイルオーバー）
WEBコンテナー
コンテナー・
コンテナーWLM
コンテナー・EJBコンテナー
コンテナー
の際の割り振りの重
りの重み付け
56
新規にクラスターを作成し、そのクラスターにクラスター・メンバーとしてアプリケーション・サーバーを追加します。
クラスター設定では、EJBコンテナーへの負荷分散への際にEJBクライアントと同じノード上のEJBコンテナーへの負
荷分散を優先させるという設定を行えます。また、HAマネージャーによるトランザクションログのフェイルオーバーの
設定もクラスターメンバーでの引き継ぎとなりますので、クラスター設定において設定します。
クラスターの各メンバー設定では負荷分散の際の割り振りの重み付けを設定することができます。この数字が高い
ほどよりリクエストが割振られるということになります。
クラスターの構成方法については、8章のシステム管理もご参照ください。
56
IBM Software Group | WebSphere software
クラスターによるワークロード管理(WLM）
◆ 2種類のWLM ◆
WebコンテナーWLM：
Webコンテナーへのリクエストに対するWLM
EJBコンテナーWLM：
EJBコンテナーへのリクエストに対するWLM
WebServer
WebServer
WebServer
Plug-in
Cluster Aの
クラスター・メンバ
Application
ApplicationServer
Server
（WebContainer）
（WebContainer）
WLM
Plug-in
WebServer
Plug-in
Application
ApplicationServer
Server
（EJBContainer）
（EJBContainer）
EJBコンテナー
コンテナー
WLM
Webコンテナー
コンテナー
WLM
WebServer
WebServer
Cluster Bの
クラスター・メンバ
Application
ApplicationServer
Server
（WebContainer）
（WebContainer）
WLM
Plug-in
ClusterA
Application
ApplicationServer
Server
（EJBContainer）
（EJBContainer）
ClusterB
57
クラスターを作成することによりクラスターメンバー間でのWorkLoadManagement(WLM)が有効になります。WLMによりク
ラスターメンバー間での負荷分散・障害時のフェイルオーバーが可能になります。
Webコンテナーへのリクエストに対するWLMをWebコンテナーWLMといいます。WebコンテナーWLMはWebコンテナー・
サービスを実行するアプリケーション・サーバーをクラスター化することにより実現できます。また、EJBコンテナーへのリ
クエストに対するWLMをEJBコンテナーWLMといいます。 EJBコンテナーWLMはEJBコンテナー・サービスを実行するア
プリケーション・サーバーをクラスター化することにより実現できます。
57
IBM Software Group | WebSphere software
Webコンテナー WLM
Webサーバー・プラグインを経由するWebコンテナー
へのリクエストに対して提供
WebServer
WebServer
Plug-in
Webコンテナーのクラスター化により実現
Webコンテナーへのルーティングテーブルはplugincfg.xmlが提供
割り振りの手法は重み付けラウンドロビンを使用
ƒ
アプリケーション・サーバーに重み付けをし、それ
に基づいて割り振る
プライマリー/バックアップサーバー・リスト
ƒ
Web
Web
Container
Container
Web
Web
Container
Container
Web
Web
Container
Container
Cluster
アプリケーション・サーバーに対しプライマリーと
バックアップの指定
ƒ
プライマリー指定のアプリケーション・サーバー障
害時にバックアップサーバーに割り振る
セッションIDを持つリクエストに対しては
SessionAffinity機能により同一サーバーに割り振る
58
WebコンテナーWLMはクラスターメンバーがWebコンテナーサービスが稼動することで実現します。Webサーバー・プ
ラグインを経由するWebコンテナーへのリクエストに対して負荷分散、フェイルオーバーの機能を実施します。Webコ
ンテナーがリクエストをどのサーバーにどのように割振るかというルーティングテーブルはplugin-cfg.xmlに記述され
ます。Webサーバープラグインはそのファイルを見てリクエストを割り振ります。
負荷分散のロジックはクラスターメンバー設定におけるウェイトに従った重み付けラウンドロビンを使用しています。
また、クラスターメンバーとなるアプリケーション・サーバーに対しプライマリーかバックアップの指定をすることが可
能です。バックアップ指定のサーバーはプライマリーサーバー障害時にのみサービスを提供することになります。
WebコンテナーWLMではV5と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエストは
セッションIDが作成されたサーバーにリクエストを続けることが可能です。
58
IBM Software Group | WebSphere software
SessionAffinity
ƒ
ND構成では、Webサーバー・プラグインはデフォルトでSession Affinityを行
ないます。
ƒ
JSESSIONIDに付加されるクローンIDを利用します。
ƒ
JSESSIONID=0000JOet7zg74ZUbmHz9cqIR7HI:1010uipbp
CloneID=1010uipbp
1. 初回リクエスト
4.レスポンス
5. 2度目のリクエスト
8. 2度目のレスポンス
WebServer
WebServer
Plug-in
り振り
よる割
加）
g-inに
ス
ポン bpが付
2. Plu
レス
ip
らの :1010u
か
r
e
XX
erv
D=X
ppS
3. A SIONI
ーへ
S
サーバ
JS E
一
に
、同
okie
検証し
（ Co
を
ie
k
o
ス
6. Co
スポン
ら のレ
バーか
ー
7. サ
Web
Web
Container1
Container1
Web
Web
Container2
Container2
CloneID=101fovh46
59
WAS V6 NDによるシステム構成をとることにより、WebコンテナーはHTTPセッションを作成したリクエストに対して、
セッションIDと共にクローンIDを付与することになります。プラグインはクローンIDが付与されたリクエストを受け取る
と、クローンID に紐付けられたアプリケーション・サーバーへ割り振りを行います。
この仕組みによりセッション情報をもつリクエストは、セッションオブジェクトの存在するサーバーへ続けてアクセスで
きます。この機能をSessionAffinityといいます。
59
IBM Software Group | WebSphere software
EJBコンテナー WLM
EJBClient
EJBClient
ORB
EJBクライアントからのEJBコンテナーへのリク
エストに対して提供
WLM
Plug-in
EJBコンテナーのクラスター化により実現
EJBクライアントとEJBコンテナーは別プロセスで
なければならない
ƒ
同一プロセスの場合、Server Affinityにより
別プロセスのEJBコンテナーへは割り振ら
れない
割り振りの手法は重み付けラウンドロビンを使
用
EJB
EJB
Container
Container
EJB
EJB
Container
Container
EJB
EJB
Container
Container
Cluster
ƒ
アプリケーション・サーバーに重み付けをし、
それに基づいて割り振る
「ローカルを優先」設定により、同一ノードのEJB
コンテナーを優先することも可能
Transaction Affinityにより同じトランザクション
内のリクエストは同じサーバーに割り振る
60
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ではV5と同様にTransactionAffinityにより、トランザクション中のリクエストは必ず前回と同じEJBコ
ンテナーへリクエストを割振られます。
60
IBM Software Group | WebSphere software
コア・グループ
ƒ
セル内のJVMをグループピング
DM/ノード・エージェント/アプリケーション・サーバー
ƒ
HA機能はコア・グループ単位で設定・実行
ƒ
WLM情報等はコア・グループ内で共有される
ƒ
シングルトン・サービスは同じコア・グループ内のメンバーへフェイルオーバーされ
る
ƒ
コア・グループ作成ルール
セル内のJVMコンポーネントはいずれかのコア・グループに所属しなければならない
セル内のJVMコンポーネントは複数のコア・グループの所属できない
ƒ
１つのセル内で複数のコア・グループを作成可能
セルをまたがったコア・グループの作成は不可
クラスター・メンバーは同じ１つのコア・グループにしか所属できない
１つのコア・グループに複数のクラスターは参加可能
同一または異なるセルのコア・グループ間でHA情報の共有は、コア・グループ・ブ
リッジ・サービスを使用する
61
セル内のJVM（DM・ノード・エージェント・アプリケーション・サーバー）をグルーピングするコア・グループを作成する
と、HA機能はコア・グループ内で実施されます。
障害検知・情報共有/更新・シングルトンサービスの引継ぎはコア・グループメンバー間で実施されます。V6で提供さ
れるシングルトンサービスの引継ぎはトランザクションログの引継ぎ・JMSメッセージの引継ぎの２つがサポートされ
ています。これは同じコア・グループのメンバーであると共に、同じクラスターメンバーであるサーバーが引き継ぐこと
になります。
コア・グループを作成するために、次のようなルールがあります。
・セル内のJVMコンポーネントはいずれかのコア・グループに所属しなければならない
・セル内のJVMコンポーネントは複数のコア・グループの所属できない
・１つのセル内で複数のコア・グループを作成可能
・セルをまたがったコア・グループの作成は不可
・クラスター・メンバーは同じ１つのコア・グループにしか所属できない
・１つのコア・グループに複数のクラスターは参加可能
HAマネージャーは２つのコア・グループの連携を可能にします。同一もしくは異なるセルのコア・グループ間でHA情
報の共有が可能となります。コア・グループ間のアクセスポイントとして特定のIP・Portを指定しますので、コア・グ
ループ間にプロキシー・ファイアーウォールがある場合にも有効となります。
61
IBM Software Group | WebSphere software
HTTPセッション・パーシスタンス
ƒ
セッション情報を別の場所へ避難させることでセッションを維持する
ƒ
アプリケーション・サーバー自身が提供する機能
ƒ
アプリケーション・サーバー障害時にもセッション維持可能
セッションDB
メモリー間複製
‹
他のAppServerのメモリー上に
セッションオブジェクトのコピーを作成
セッション
オブジェクトｖ
セッション
‹
セッションオブジェクトをDBに保管
(データベース・セッション・パーシスタンス）
セッション
オブジェクトｖ
セッション
DB
セッション
62
HTTPセッション・パーシスタンスです。これはセッション情報を別の場所へと退避させることでアプリケーション・サー
バー障害時にもセッションの維持を行なう方法で、アプリケーション・サーバー自身が提供する機能でした。WAS V6
では他のアプリケーション・サーバーのメモリー上にセッション情報を複製するメモリー間複製(Memory to Memory)と、
セッション情報をDBに保管する方法の2つがサポートされています。実績はDBの方が多くあります。（特に大規模な
構成ほど）
重要なのは、セッション・オブジェクトの大きさで、大きな情報を入れるとパフォーマンスに悪影響します。また書き込
む頻度も関係します。
アプリケーションではサイズの小さいセッション・オブジェクトを保存するようにすることが非常に重要です。（数10kも
あると、パフォーマンスへの影響は大です）
62
IBM Software Group | WebSphere software
HTTPセッション・メモリー間複製
ƒ
HTTPセッション情報を複数のアプリケーション・サーバーに持つことで障害時のセッション処
理に対するフェイルオーバーが可能
ƒ
複製ドメイン設定でのレプリカの数と、アプリケーション・サーバー毎に設定するメモリー間複
製設定で動作環境が決まる
ƒ
ドメイン指定はアプリケーション・サーバー単位
ƒ
アプリケーション・サーバー毎の複製モード設定
ƒ
クライアントのみ – ローカルで作成・更新されたセッション情報をサーバーに送信
サーバーのみ - 他のアプリケーション・サーバーのセッション情報を受信
クライアントとサーバー両方 – クライアント・サーバー両方の動きをする
基本的に次の２つの動作環境がある
Peer to Peer
ƒ
各々のアプリケーション・サーバーが自分および他のアプリケーション・サーバーのセッション情報
を保持する
ƒ
アプリケーション・サーバー障害時、ホット・フェイルオーバーによりプラグインはレプリカを持って
いるサーバーに割り振る
Client/Server
ƒ
クライアントのアプリケーション・サーバーは自分のセッション情報を保持し、他クライアントのアプ
リケーション・サーバーのセッション情報はサーバーのアプリケーション・サーバーに保持される
ƒ
アプリケーション・サーバー障害時、障害サーバーのセッション・リクエストを受けたアプリケーショ
ン・サーバーは、サーバー指定されたアプリケーション・サーバーから該当セッション情報を取得
する
63
DRS（Data Replication Service）は、クラスター配下のアプリケーション・サーバー間におけるデータ複製を提供しま
す。DRS機能はアプリケーション・サーバー毎に稼動し、お互い連携することにより、データ複製を可能にします。複
製ドメインとは、DRSを使用するアプリケーション・サーバーの集合です。この複製ドメイン内のDRS同士でデータの
複製は実行されます。複製ドメイン設定では、１つのアプリケーション・サーバーがいくつのデータ・レプリカを別のア
プリケーション・サーバーに作成するかを指定します。
次の３つの指定が可能です。
・単一レプリカ
デフォルトで使用されます。１つのデータに対して複製ドメイン内に１つのデータ・レプリカを保持します。
・ドメイン全体
複製ドメイン内の全てのサーバーが1つのデータに対するレプリカを保持します。
・指定
１つのデータに対していくつレプリカを持つかというのを数で指定可能です。
DRSを使用して、HTTPセッション情報を複数のアプリケーション・サーバーに持つことで、障害時のセッション処理に
対するフェイルオーバーが可能となります。この機能を使用するために、アプリケーション・サーバーごとにメモリー
間複製設定を行う必要があります。
メモリー間複製設定では、そのアプリケーション・サーバーがデータレプリカを送信するのみか、受信するのみか、ま
たその両方かというのを指定します。また、メモリー間複製設定ではどの複製ドメインを使用するかというのを指定し
ます。
ドメインに指定しているレプリカの数と、各アプリケーションの役割によってDRSの動作環境が決まります。動作環境
には大きく分けて次の２つがあります。
・Peer to Peer
各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報を保持します。
V6ではアプリケーション・サーバーの障害が発生すると、プラグインはレプリカのあるサーバーにリクエストを割り振
る、ホット・フェイルオーバーが提供されます。
・Client/Server
データレプリカの送信のみに指定されたクライアントと、受信のみに指定されたサーバーによってこの構成はとられ
ます。アプリケーション・サーバー障害時に、セッションリクエストを受け取ったクライアントは、サーバーからセッショ
ン情報を取得しサービスを行います。
63
IBM Software Group | WebSphere software
練習問題
11. 管理コンソール
管理コンソールで
コンソールでデプロイメント・
デプロイメント・マネージャーに
マネージャーにアプリケーション・
アプリケーション・サーバー・
サーバー・ノード
を統合する
統合する際
する際に必要のない
必要のない作業
のない作業を
作業を選択してください
選択してください。
してください。
A. デプロイメント・マネージャーの起動
B. Webサーバーの始動
C.アプリケーション・サーバーの始動
12. HTTPセッション
セッション・
セッション・メモリー間複製
メモリー間複製で
間複製で使用できる
使用できる複製
できる複製モード
複製モード設定
モード設定で
設定で指定できないものは
指定できないものは
次のうちどれですか？
のうちどれですか？
A. クライアントのみ
B. サーバーのみ
C. クラスターのみ
64
<memo>
64
IBM Software Group | WebSphere software
6章 保守とパフォーマンス・チューニング
65
<memo>
65
IBM Software Group | WebSphere software
クラス・ローダーの設定
ƒ
ƒ
ƒ
クラス・ローダーはクラスを検索し、ロードするための仕組み
WASでは階層構造をとる複数のクラス･ローダーを使用
この設定によりモジュールおよびクラスの可視性が決定される
ƒ
クラス・ローダー分離ポリシー
アプリケーション・クラス・ローダー・ポリシー：アプリケーションの分離を制御
ƒ 単一 (Single)
ƒ 複数 (Multiple)
WAR クラス・ローダー・ポリシー：Web モジュールの分離を制御
ƒ アプリケーション (Application)
ƒ モジュール (Module)
ƒ
クラス・ローダー・モード
親が最初 (Parent First )
親が最後 (Parent Last)
66
クラス・ローダーは、クラス・ファイルを検出し、ロードします。クラス・ローダーにより、サーバーにデプロイされたアプリ
ケーションが、使用可能なクラスおよびリソースのリポジトリーにアクセスできるようになります。
WebSphere Application Server のクラス・ローダーは以下の階層構造となっています。
1．Java 仮想マシンで作成される、ブートストラップ、拡張、および CLASSPATH のクラス・ローダー。
2．WebSphere 拡張クラス・ローダー
3．アプリケーション・モジュール・クラス・ローダー
4．Web モジュール・クラス・ローダー
（各クラス・ローダーは、直前のクラス・ローダーの子になっています。）
また、アプリケーションとモジュールの分離を制御するための設定が、アプリケーション・クラス・ローダー・ポリシーと、
WAR クラス・ローダー・ポリシーになります。
アプケーション・
アプケーション・クラス・
クラス・ローダー・
ローダー・ポリシー（アプリケーション・サーバー単位に設定）
ポリシー
・単一(Single)…アプリケーション・クラス・ローダーを複数のアプリケーションで共用する（アプリケーションは分離され
ない）
・複数(Multiple)…アプリケーション・クラス・ローダーをアプリケーションごとに固有にする（アプリケーションは互いに分
離される）
WAR クラス・
クラス・ローダー・
ローダー・ポリシー（エンタープライズ・アプリケーション単位に設定）
ポリシー
・アプリケーション(Application)…Webモジュールの内容も、アプリケーション・クラス・ローダーによってロードされる
・モジュール(Module) …各Webモジュールは、アプリケーション・クラス・ローダーを親に持つ独自のクラス・ローダーを
持つ
また次のクラス
クラス・
クラス・ローダー・
ローダー・モードが提供されています。
モード
・親が最初(Parent First)…クラス・ローダーは、ローカル・クラス・パスからクラスのロードを試行する前に、親クラス・
ローダーにクラスのロードを委任します。（デフォルト）
・親が最後(Parent Last)…クラス・ローダーが、クラスのロードをその親に委任する前に、クラスをそのローカル・クラス
パスからロードしようとします。
クラス・ローダーの詳細については、InfoCenterのクラス・ロードの章をご参照ください。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/trun_classload.
html
66
IBM Software Group | WebSphere software
システムのバックアップ方法
ƒ
バックアップの取得が必要と考えられるタイミング
インストール直後
Fix Pack適用前・後
構成情報の変更前・後
ƒ
バックアップ方法
backupConfigコマンドを使用
ƒ コマンドを実行するプロファイルの構成ファイルである<Profile_root>¥configディレクト
リー配下をzipファイルにアーカイブ
ƒ 使用方法：backupConfig <backup_file> [options]
ƒ [options]
-nostop ：構成のバックアップ前にサーバーを停止しないように指示
-quiet ：通常モードで出力される進行情報を抑止
-logfile <fileName>
fileName> ：情報を書き込むログ・ファイルのロケーションを指定
-profileName <profileName>
profileName> ：マルチプロファイル・システムで、プロセスを指定
-replacelog ：現行ログに追加する代わりに、ログ・ファイルを置き換える
-trace ：デバッグのために、ログ・ファイルにトレース情報を生成する
ディレクトリーのコピー
ƒ
<WAS_root>ディレクトリー配下のすべてのファイルをzipなどでバックアップする
67
バックアップの取得が必要と考えられるタイミングは以下のようなときです。
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/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_backupconfig.
html
backupConfigコマンドの使用における注意点として、以下のような点があります。
・構成リポジトリー以外にもバックアップが必要なファイルがあります。
・DMとそれぞれのノードで個々にバックアップが必要です。backupConfigコマンドで取得したバックアップ情報はホスト
名/IPアドレスが異なるマシンではリストアできませんので、複数マシン構成の場合、それぞれのノードでバックアップ
を行う必要があります。また、DMとノード・エージェントが1台のマシンに同居している場合でも、DMの構成リポジト
リーのバックアップとノードの構成リポジトリーのバックアップをそれぞれ行う必要があります。
・バックアップ取得時には、自動的に各ノードのDM、ノード・エージェント、アプリケーション・サーバーのプロセスが停
止されます。backupConfigコマンドの-nostopオプションを使用して、プロセスを停止せずにバックアップを取得すること
もできますが、バックアップ取得時にマスター構成リポジトリーが変更されると不整合が発生し、リストアできませんの
で、注意が必要です。
・バックアップ取得時に停止されたプロセスは自動的には起動しませんので、バックアップ終了後、手動で起動する必
要があります。
backupConfigコマンドを使用する以外にも、WASが導入されているディレクトリーをZIPなどで全てバックアップする方
法もあります。
67
IBM Software Group | WebSphere software
リストア方法
ƒ
restoreConfigコマンドを使用
backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元
使用方法：restoreConfig <backup_file> [options]
ƒ
例： <Profile_root>¥bin¥restoreConfig myBackup.zip
注意点
ƒ
構成リポジトリー以外のバックアップファイルの復元も必要
ƒ
同一ホスト名のマシンに対してのみリストア可能
backupConfig
BackupFile
(.zip)
restoreConfig
ホスト名の異なるマシン
にはリストア不可能！
hostA
hostB
68
WASの構成情報のリストアを行うには、restoreConfigコマンドを使用します。このコマンドを実行することにより、backupConfig
コマンドで取得したzipファイルから各ノードの構成リポジトリーを復元します。リストア時には、リストア対象ファイルを必ず指定
してください。restoreConfigコマンドのオプションの詳細についてはInfoCenterの「restoreConfigコマンド」を参照ください。
http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_restoreconfig.html
restoreConfigコマンドの使用における注意点として、以下のような点があります。
・構成リポジトリー以外のバックアップファイルの復元も必要です。
・リストアは同一ホスト名のマシンにおいてのみ可能です。
既存の構成ディレクトリが存在している場合、既存のディレクトリの名前が変更されてから復元が開始されます。実行例では既
存の<Profile_root>¥configディレクトリが<Profile_root>¥config.old_1に変更されてから復元が始まっています。
68
IBM Software Group | WebSphere software
キューイング・ネットワーク
ƒ
Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシス
テムで相互関連するコンポーネントをキューイング･ネットワークと呼ぶ
ƒ
キューイング･ネットワークに関連するパラメーターを調整し、最大スループットを達成することが
パフォーマンスチューニングの第一歩
それぞれの入り口で待ち処理が発生
するように絞り込むように調整
Webサーバー
ブラウザー
Webコンテナ
AS
EJBコンテナ
AS
DB
データソース最大接続数
ORBスレッドプール･サイズ
Webコンテナスレッドプールサイズ
Webサーバー MaxClients / ThreadPerChild
69
Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連するコン
ポーネントをキューイング･ネットワークと呼びます。キューイング･ネットワークに関連するパラメーターを調整し、最大ス
ループットを達成することがパフォーマンスチューニングの第一歩になります。
キューイング･ネットワークでは原則クライアントに近い側の同時接続パラメーターを大きく、リソース･マネージャーに近い
側を小さく設定します。これによりシステムが過負荷にならない、かつ各コンポーネントは適量の待ち処理を継続処理でき
るようにしてスループットを最大化することが出来ます。
69
IBM Software Group | WebSphere software
モニタリング・ツール : Tivoli Performance Viewer
ƒ
ƒ
ƒ
WASが提供するパフォーマンス・モニタリングの仕組み
各種のシステム測定値を取得し、管理コンソールに結果を表示
ユーザーが取得するコンポーネントおよびレベルを選択可能
セッション・
セッション・マネージャー
Webアプリケーション
Webアプリケーション
-Servlet/JSP平均応答時間
-Servlet/JSPリクエスト数
：
-アクティブ・セッション数
-セッション・サイズ
-無効セッション数
：
EJB Module
-EJB応答時間
-EJBリクエスト数
：
DB接続
DB接続プール
接続プール
-使用ﾌﾟｰﾙ%
-平均待ち時間
：
HTTP
Session
H TT P
C lien t
serv le ts
S essio n
E JB
CMP
Session
JSP s
D ataba se
Entity
EJBs
E JB
P ersistence
JV M
JVM Module
-ヒープサイズ
-GC統計情報
：
スレッド・
スレッド・プール
-プール・サイズ
-アクティブ・スレッド数
：
Transaction Module
-アクティブ・トランザクション数
-トランザクション・タイムアウト
：
70
WASではアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークとしてPMI（Performance Monitoring
Infrastructure）を提供しています。WASでは各リソースの様々なパフォーマンスデータをMBeanに格納しており、PMIはこの
MBeanと通信して必要なパフォーマンスデータを取得します。パフォーマンス・データを格納しているMBeanは複数あり、それ
ぞれ固有のデータを持っています。Tivoli Performance Viewer (TPV)はこのPMIを介して、WASの各リソースのパフォーマン
ス・データを取得しています。
TPVは管理コンソールの一メニューとして使用可能で、ブラウザー・アクセスが可能なクライアントであればアクセスできるよう
になっています。
TPVにアクセスするためには「モニターおよびチューニング」→「Performance Viewer」からアクセスします。TPVには［現行ア
クティビティ］と［ログの表示］の二つのモードがあります。どちらかを選択した上で、TPVとしてモニターするプロセスを選択し
ます。この際にチェックを付けることで複数のプロセスの情報を取得開始することも可能ですが表示は一プロセス単位になり
ます。管理コンソールからログオフするとモニターは停止します。
70
IBM Software Group | WebSphere software
JVMの役割-メモリ管理
ƒ
JavaではJVMがメモリ管理を実施
不要になったオブジェクトをメモリ領域から開放
ガーベージ・
）
ガーベージ・コレクション（
コレクション（GC）
Merit アプリケーション開発者のメモリ管理作業を軽減、ソフトウェア品質の向上
ƒ
参照されないオブジェクトが残ってしまうことによるメモリリークの回避
ƒ
まだ参照されているオブジェクトを消去してしまうランタイムエラーの回避
重要
GC処理中は全てのアプリケーション・スレッドは停止
GCはアプリケーションのパフォーマンスに影響
JVMが適切にGCを実施するよう調整が重要
メモリー空間
不要な
ｵﾌﾞｼﾞｪｸﾄ
不要な
ｵﾌﾞｼﾞｪｸﾄ
必要な
ｵﾌﾞｼﾞｪｸﾄ
必要な
ｵﾌﾞｼﾞｪｸﾄ
必要な
ｵﾌﾞｼﾞｪｸﾄ
必要な
ｵﾌﾞｼﾞｪｸﾄ
71
JVMの重要な役割として、メモリ管理があります。Javaでは、一般にガーベッジ・コレクション (GC) と呼ばれる、不要になった
オブジェクトをメモリ領域から開放する作業をJVMが行っています。
これにより、アプリケーション開発者は煩雑なメモリ管理のコードをプログラム中に記述する必要がなくなります。また、参照
されないオブジェクトがメモリ内に残ってしまうことによるメモリリークや、逆にまだ参照されているオブジェクトを消去してしま
うことにより発生するランタイムエラーなどのバグを回避することができますので、ソフトウェア品質の向上するという利点が
あります。
GCはアプリケーションのパフォーマンスに影響を与えますので、JVMが適切にGCを処理を行うように設定することが重要で
す。
71
IBM Software Group | WebSphere software
JVM ヒープサイズの調整
ƒ
JVMが使用するメモリ領域
Java heap
ƒ
ƒ
クラスやインスタンスのオブジェクトが格納
Garbage Collectionの対象エリア
ƒ
WASでは、デフォルトで最小50MB、最大256MBに設
定されている
Native heap
ƒ
JVMの起動時に常に参照される、システムや共有プロ
グラムのクラスオブジェクトが格納
ヒープサイズの設定値によって、GCの
ヒープサイズの設定値によって、GCの
処理時間や間隔を調整
処理時間や間隔を調整
72
Heapとは、JVM、つまりJavaアプリケーションが使用できるメモリ領域です。HeapはJava heapとNative heapの2種類の領域に
分かれます。
Java heapはオブジェクトが格納されるメモリ領域であり、GCの対象エリアになります。
Native heapはJVMの起動時に常に参照される、システムや共有プログラムのクラスオブジェクトが格納されるメモリ領域であ
り、GCの対象になりません。
Java heapの最小サイズ・最大サイズは、JVM引数 (WASでは、管理コンソール上の設定)で、設定することができます。WASの
デフォルト値はプラットフォームによらず最小50MB、最大256MBとなります。管理コンソールで「アプリケーション・サーバー」＞
（サーバー）＞「プロセス定義」＞「Java仮想マシン」から設定することが可能です。
実際のWASの環境においては、各アプリケーション・サーバーがそれぞれ異なるJVMを起動していますので、それぞれ別々の
heap領域を確保する必要があります。また、各JVMは明示的に設定できるJava heapに加えて、Native heapが必要になります
ので、注意が必要です。
このヒープサイズの最小・最大サイズによってGCの間隔や処理時間を調整し、GCがパフォーマンスに与える影響を少なくしま
す。
一般に、ヒープを大きく設定すると、GCが発生するまでの間隔は長くなりますが、GCにかかる時間が長くなりますので、環境
に合わせて調整が必要となります。
72
IBM Software Group | WebSphere software
プラグインの管理
ƒ
Webサーバー・プラグインは、次のような場合、更新が必要
ƒ
新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合
サーブレットに対するURLマッピングの定義など、URIに変更があった場合
新しいクラスターが追加され、ルーティング方法が変更になった場合
ポート番号が変更になった場合
仮想ホストの追加や修正があった場合、など。
正しくリクエストが割り振れない場合のチェック項目
Web サーバー・プラグイン構成の更新をしているか
Web サーバー構成ファイルの設定は正しいか
ƒ
Webサーバー構成ファイルの中に記述されているplugin-cfg.xmlの位置が正
しく設定されているかどうかを確認する
編集したplugin-cfg.xmlが変更されていないか
ƒ
plugin-cfg.xmlを手で書き換えている場合、同期により修正が失われる
最新のFixが当たっているか
73
次のような場合は、プラグイン構成ファイルの更新と伝搬が必要となります。
!新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合
!サーブレットに対するURLマッピングの定義など、URIに変更があった場合
!新しいクラスターが追加され、ルーティング方法が変更になった場合
!ポート番号が変更になった場合
!仮想ホストの追加や修正があった場合、など。
プラグイン構成ファイルの伝搬方法については、2章をご参照ください。
正しくリクエストが割り振られていない場合のチェック項目として、いくつか挙げます。
・上記の修正が入った場合に、正しくプラグイン構成ファイルが更新、伝搬されているかどうかを確認します。
・Webサーバーの構成ファイルhttpd.confの中に記述されているプラグイン構成ファイルplugin-cfg.xmlの位置は正し
く設定されているかどうかを確認します。
・plugin-cfg.xmlファイルを手で書き換えている場合、デプロイメント・マネージャーの構成ファイル同期サービスにより、
Webサーバー・プラグイン構成の更新で生成された状態に戻ってしまうことがあります。
・製品の障害などを修正するためのFixなどもありますので、最新版があたっているかどうかも確認します。
73
IBM Software Group | WebSphere software
練習問題
13. アプリケーション・
のクラス・
アプリケーション・クラス・
クラス・ローダーと
ローダーと、WARの
クラス・ローダーを
ローダーを分離するための
分離するための設定
するための設定はどこで
設定はどこで
行いますか。
いますか。
A. アプリケーション・クラス・ローダー・ポリシー設定 （単一/複数）
B. WAR クラス・ローダー・ポリシー設定 （アプリケーション/モジュール）
C. クラス・ローダー・モード設定 （親が最初/親が最後）
14. Tivoli Performance Viewerにおいて
において、
アプリケーションの
において、Webアプリケーション
アプリケーションのパフォーマンスを
パフォーマンスをモニ
ターするために
ターするために有効
するために有効な
有効な項目を
項目を次の中から１
から１つ選びなさい。
びなさい。
A. サーブレットの平均応答時間
B. JVMの使用メモリー
C. 平均CPU使用率
15. Webサーバー
サーバー・
の再生成が
サーバー・プラグイン構成
プラグイン構成ファイル
構成ファイル(plugin-cfg.xml)の
ファイル
再生成が必要になる
必要になるケース
になるケースを
ケースを、
次の中から１
から１つ選びなさい。
びなさい。
A. Webアプリケーションが追加された場合
B. Webコンテナのスレッドプール・サイズが変更になった場合
C. Webコンテナで設定するHTTPセッションのタイムアウト値が変更になった場合
74
<memo>
74
IBM Software Group | WebSphere software
7章 問題判別
75
<memo>
75
IBM Software Group | WebSphere software
ログの種類 (1)
WASログ
ログ
ノード単位
ノード単位の
単位のログ
IBM保守ログ(activity.log)
‹
‹
アナライザー
JVMログに詳細な情報を追加したログ。
ログ・アナライザーを用いて読み取る。
プロセス（
）単位の
プロセス（AS/DM/NA）
単位のログ
JVMログ (SystemOut.log / SystemErr.log)
循環ログ
JVMの標準出力および標準エラー出力。
‹ ログ解析の基本。
‹
プロセスログ (native_stdout.log / native_stderr.log)
‹
‹
ネイティブ・コードやJVM自身の出力が書き込む情報の出力先
JVMのverboseGC出力はnative_stderr.logに記録される。
FFDCログ (<process_name>_<timestamps>.log)
構成不可
First Failure Data Captureとはエラー情報を発生時に自動記録する機能。
‹ サポートセンター、開発部門が障害対応時に見るログ。
‹
HTTPトランスポートログ (http_access.log / http_error.log)
‹
‹
ASのWebコンテナのHTTPトランスポートに対するアクセスを記録するログ。
管理ポートに対しても記録が可能。
76
問題解析の基本となるログは出力する製品および階層に応じて複数の種類があります。ここでは各ログの解説を行います。
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ログに詳細情報を追加したログで、ログ・アナライザーというGUIツールを使用して読み
取ります。（ログ・アナライザーが使用できない場合は、showLogコマンドを使用します。）
76
IBM Software Group | WebSphere software
ログのロケーション (1) WAS関連
WAS関連
プロファイル単位の/logsディレクトリ
IBM保守ログ
/logs以下に/ffdcディレクトリ
FFDCログ
/logs以下にサーバー単位のディレクトリ
HTTPトランスポートログ
プロセス・ログ
JVMログ
77
前項で解説したログの実際のロケーションを表したチャートです。
77
IBM Software Group | WebSphere software
ログの種類 (2)
IHSログ
ログ
IHSログ (access.log / error.log)
‹
‹
クライアントがIHSにアクセスしたリクエストおよびリプライをaccess.logに記載。
エラー情報はerror.logに記載。
プラグインログ
プラグイン・ログ (http_plugin.log)
‹
‹
Webサーバープラグイン・コンポーネントが記載するログ。
WebサーバーとWAS間の通信に問題がある場合に参照。
78
『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ファイル内で指定されてます。管理コンソールのプラグイン・プロパティの設定でプラグイン・ログのレベルや
出力先を変更することができます。当資料の37ページを参照してください。
WebサーバーとしてIHSを使用している場合、IHSの構成ファイルhttpd.confの中のWebSpherePluginConfigディレクティブで
plugin-cfg.xmlファイルの位置が指定されており、plugin-cfg.xmlファイルでプラグイン・ログファイルの位置が指定されていま
す。
ブラウザーから実行されるリクエストはIHSログ、プラグインログ、HTTPトランスポートログ、JVMログ・・・という順に記載され
ていきます。
78
IBM Software Group | WebSphere software
ログのロケーション (2)
IHS、プラグイン関連
IHS導入ディレクトリ
IHSの/logsディレクトリ
httpアクセス・ログ
httpエラー・ログ
プラグイン導入ディレクトリ
Pluginの/logsディレクトリにWebサーバー単位のディレクトリ
プラグイン・ログ
79
前項で解説したログの実際のロケーションを表したチャートです。
79
IBM Software Group | WebSphere software
ログの管理
ƒ ログ管理機能
管理コンソールの「トラブルシューティング」→「ログおよびトレース」からサーバーを指定して、各ログの循
環設定、ファイル最大サイズなどを設定可能
JVMログでは世代管理も可能
ƒ 使用中ファイル…SystemOut.log
ƒ 一世代前………. SystemOut_03_01.15_17.38.19.log
(SystemOut_yy_MM.dd_HH.mm.ss.log)
世代管理は一定時間、一定サイズで行う
ƒ 考慮点
本番稼働環境では、ファイルの最大サイズや世代交代などの設定、
さらに運用により、WAS停止のタイミングでログを待避させる
基本的に、WASが出力するログは問題判別用
長期的にわたって保存しておく必要はない
ƒ 逆に、ログファイルが大きすぎると問題判別の際見づらくなるので、
適切な最大サイズ設定やこまめに待避させる運用を心がける
80
WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）から各ログの循環設定やファイル
最大サイズの指定などを行うことができます。
ログの世代管理も可能で、一定時間と一定サイズのどちらか、または両方を選択することができます。両方を選択した場合
は、両方のタイミングで循環が実行されます。また、ヒストリー・ログ・ファイルの最大数として、残しておく過去のログの数を
指定することもできます。
また、「インストール済みアプリケーション出力」の設定によって、アプリケーションから出力されるSystem.outおよび
System.errのメッセージを抑制することも可能です。
システム管理者が考慮すべきログ管理としては、本番稼動環境におけるファイルの最大サイズや世代交代の設定がありま
す。基本的にはWASが出力するログは問題判別用なので、長期的にわたって保存しておく必要がありません。適切な最大
サイズ設定やこまめに退避させる運用を心がける必要があります。WASの稼動中にログを退避させることはできませんので、
循環されないログについてはWAS停止のタイミングでログを退避させる運用とします。
80
IBM Software Group | WebSphere software
トレース(trace.log)
ƒ
<Profile_root>¥logs¥<server_name>¥trace.log
ƒ
WASのコンポーネントの詳細な実行内容を追跡可能
ƒ
基本的にWASの開発部門の指示で問題の再現時に有効にする
コンポーネントとトレースの詳細レベルを指定
コンポーネントとトレースの詳細レベルを指定
世代管理可能
世代管理可能
81
WASではコンポーネントの詳細な実行内容をサーバーごとにトレースファイルに出力させることができます。
<Profile_root>¥logs¥<server_name>¥trace.logファイルに出力されます。コードを実行するたびに対象コンポーネントがト
レースに情報を出力するため、問題判別のためのイベントの追跡ができます。基本的に、トレースを出力させるのはWAS
の開発部門の指示で問題の再現時であり、トレース内容はWASのテクニカルサポートの助けがないと内容を調査するこ
とは難しいです。コンポーネントのソースコードをもとにトレースを分析すれば、問題がどのコンポーネントのどの部分に
あるかを絞り込むことができます。デフォルトでトレースは使用可能になっています。
WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「診断トレース」からトレース
の循環設定やファイル最大サイズの指定などを行うことができます。
トレース出力フォーマットは、「基本（互換）」「拡張」「ログ・アナライザー」の3種類が選択できます。また上記管理コンソー
ル画面の「ログを使用可能にする」のチェックをはずすとトレースは出力されなくなります。アプリケーション・サーバーが
稼動中であってもこの設定を変更することが可能です。「診断トレース・サービス」ページのランタイム・タブでの変更はア
プリケーション・サーバーが稼動中であっても可能で、「OK」ボタンによって反映されます。
「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「ログ詳細レベルの変更」からトレースの設定として
取得したいコンポーネントとイベントの種類を選択して設定することができます。
設定方法の詳細についてはInfoCenterの「ログ・レベル設定」をご参照ください。
http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/utrb_loglevel.html
81
IBM Software Group | WebSphere software
ログ / トレースのフォーマット
ƒ
基本フォーマット
日付，時刻，タイムゾーン
メッセージを出力したスレッドのID
[05/10/10 16:26:53:785 JST] 0000000a WsServerImpl A WSVR0001I: e-business の
ためにサーバー server1 がオープンされました。
コンポーネントの短縮名
ƒ
イベントタイプ
メッセージID
メッセージ
イベントタイプ
A：監視メッセージ
I：通知メッセージ。
W：警告メッセージ。
E：エラーメッセージ。
F：致命的メッセージ。
O：ユーザー・アプリケーションまたは内部コンポーネントによりSystem.outに直接書き込まれたメッセージ。
R：ユーザー・アプリケーションまたは内部コンポーネントによりSystem.errに直接書き込まれたメッセージ。
<：メソッドの開始
>：メソッドの終了
e：イベントのトレース項目
d：デバッグのトレース項目
m：ダンプのトレース項目
u：ASランタイムのメッセージ・ロギング・コンポーネントで使用される、特殊なメッセージまたはトレース
Z：認識不能
82
ログやトレースのフォーマットには、「基本フォーマット」と「拡張フォーマット」の2種類があり、どちらかを選択して設定するこ
とができます。
基本フォーマットでは、ログに日付や時刻、メッセージを出力したスレッドID、コンポーネントの短縮名、イベントタイプ、メッ
セージID、メッセージ内容が記録されます。拡張フォーマットでは、基本フォーマットで記録される内容に加えて、組織名、製
品名、コンポーネントの種類、UOW(作業単位)、コンポーネントの完全名が記録されます。
基本フォーマットのログにも拡張フォーマットのログにも、イベントタイプが記録されます。イベントタイプは1文字の英字で表
記され、起こったイベントのタイプを表します。メッセージ・タイプは大文字で表記され、トレース・タイプは小文字で表記され
ます。
82
IBM Software Group | WebSphere software
FFDC
ƒ FFDC（First Failure Data Capture)
すべてのシステムエラー情報を発生時点で自動的に記録する機能
<プロファイル>/logs/ffdcに存在
ƒ FFDCにより生成される2種類のファイル
Exception.log（サーバーごとの例外情報の統計）
ƒ <ServerName>_exception.log
Server1_exception.log .etc
インシデントストリーム（例外発生時点で取られる）
ƒ <ServerName>_<thread id>_<timeStamp>_<SequenceNumber>.txt
server1_7412857d_05.10.10_13.08.16_0.txt .etc
83
First Failure Data Capture (FFDC) フィーチャーは、処理の失敗によって生成された情報を保存し、それによって影響を
受けるエンジンに制御を戻します。取り込まれたデータは、問題の分析用にログ・ファイルに保管されます。
FFDC は、主として IBM サービスが使用するためのものです。 FFDC は、WebSphere Application Server のランタイム
時に発生するイベントおよびエラーを即時に収集します。この情報は、IBM サービス技術員により分析することができま
す。
FFDC 構成プロパティー・ファイルは、 WebSphere Application Server 製品インストールの下のプロパティー・ディレクト
リーにあります。 3 つのプロパティー・ファイルがありますが、ffdcRun.properties ファイルのみを変更します。
ExceptionFileMaximumAge プロパティーは、削除される前に、消去の間の日数を構成するために使用できるプロパ
ティーです。 （その他、ffdcStart.propertiesファイルとffdcStop.propertiesファイルが存在します。）
FFDC フィーチャーは、WebSphere Application Server 製品のパフォーマンスには影響を与えません。
83
IBM Software Group | WebSphere software
javacore（スレッド・ダンプ）の取得方法
ƒ javacore
native stack、java stack、環境情報などをテキストファイルで出力
Javaのモニター（synchronizedなどの排他制御で使われる）情報も取得可能
→デッドロックの調査に有効
ƒ 外部からの指示による強制取得も可能
WebSphereのjavaプロセスの場合、wsadminで取得可能
Unixでは、”kill –QUIT <PID>”または”kill –3 <PID>”でも取得可能
C:¥WebSphere¥AppServer¥profiles¥Server01¥bin>wsadmin
WASX7209I: ノード vinusCellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7029I: ヘルプを表示する場合は、「$Help help」と入力してください。
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=Server1,*]
WebSphere:name=JVM,process=Server1,platform=dynamicproxy,node=vinusNode01,j2eeTy
pe=JVM,J2EEServer=Server1,version=6.0.2.0,type=JVM,mbeanIdentifier=JVM,cell=vinu
sCell01
wsadmin>$AdminControl invoke $jvm dumpThreads
84
プロセスが異常終了した場合、javacoreが生成されます。javacoreには、native stack、java stack、環境情報などがテキスト
ファイルで出力されます。synchronizedなどの排他制御で使用されるJavaのモニター情報も取得できますので、デッドロック
の調査に有効です。
javacoreは、プロセスが異常終了したときに自動生成されるだけではなく、外部からの指示による強制取得もできます。
WebSphereのjavaプロセスの場合は、wsadminで取得することができます。Unixでは、”kill –QUIT <PID>”コマンドまたは”kill 3 <PID>”コマンドでも取得することができます。
通常、クラッシュの場合はIBMサポート部門にCoreを送付して解析してもらうことになりますが、javacore.txtを参照することに
よって、現場担当者がその問題判別をすることもできる場合があります。
84
IBM Software Group | WebSphere software
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 ]
ネームスペースのダンプの開始点
85
dumpNameSpaceとは、ネームサーバーを介してアクセスしたネームスペースの内容をダンプするユーティリティ・ツー
ルであり、<プロファイル名>/bin/dumpNameSpace.bat(sh)から実行することができます。NamingExceptionが発生した
ときに実行して確認します。
各プロセスは個別にネームスペースを持っており、それぞれのネームスペースをdumpNameSpaceコマンドでダンプさ
せるときは、ネームスペースを出力したいプロセスのブートストラップ・ポートを指定します。リソースは、そのリソース
を使用するアプリケーションが稼動するプロセスのネームスペースに登録します。例えば、DS1というデータソースを登
録する際、そのDS1を使用するアプリケーションがserver1で稼動する場合は、server1のネームスペースにDS1を登録
する必要があります。そしてその場合、dumpNameSpaceコマンドでserver1のブートストラップポートを指定した結果で
DS1が見つからなければなりません。
dumpNameSpaceコマンドのオプションとして、接続先ホスト名やネームスペースを出力したいプロセスのブートストラッ
プ・ポート、ネームスペースのダンプの開始点などを指定することができます。
85
IBM Software Group | WebSphere software
練習問題
16. 次のログ・
ログ・ファイルの
ファイルの中で、管理コンソール
管理コンソールから
コンソールからヒストリー
からヒストリー・
ヒストリー・ログ・
ログ・ファイル数
ファイル数を指定し
指定し、世代管
理ができるものを１
ができるものを１つ選びなさい。
びなさい。
A. プロセス・ログ
B. JVMログ
C. IBM保守ログ
17. activity.logファイル
ファイルを
ファイルを調べるために使用
べるために使用する
使用するツール
するツールのうち
ツールのうち、
のうち、間違っているものを
間違っているものを１
っているものを１つ選び
なさい。
なさい。
A. ログ・アナライザー
B. showlogコマンド
C. Tivoli Performance Viewer
18. javacore（
（スレッドダンプ）
スレッドダンプ）の取得方法について
取得方法について、
について、正しいものを1つ
しいものを つ選びなさい。
びなさい。
A. 管理コンソールから診断トレースを設定する
B. wsadminから$AdminControl invoke dumpThreadsを実行する
C. FFDC(First Failure Data Capture)ツールを使用する
86
<memo>
86
IBM Software Group | WebSphere software
8章 システム管理
87
<memo>
87
IBM Software Group | WebSphere software
クラスターの作成と設定
◆V6新機能であるクラスターの作成と設定を行う際の手順と概要◆
管理コンソールにてクラスターを新規に作成して設定を行うには以下の3ステップが必要
Step 1．基本クラスター情報の入力
Step 2．クラスター・メンバーの作成
Step 3．要約の確認と保管
Step 1
Step 2
Step 3
クラスター名の入力
クラスター名の入力
クラスターを既存サーバー
クラスターを既存サーバー
で構成するかどうか
で構成するかどうか
アプリケーション・
アプリケーション
サーバー
アプリケーション・
サーバー毎
毎に
に
アプリケーション・・サーバー毎
サーバー毎
重
～
けの
設定
重み
み付
付けの値
けの値
値を
を設定：
設定：
0～
～20
20
けの値
設定：： 0～
「server2」がクラスター・メン
「server2」がクラスター・メン
バーに追加された状態
バーに追加された状態
要約を確認して終了ボタン
要約を確認して終了ボタン
を押下
を押下
このあと「保管」を実施
このあと「保管」を実施
88
管理コンソールから新規クラスターを作成する操作は、「サーバー・クラスター」ページで「新規作成」ボタンを押してから
３ステップで行います。
Step1.基本クラスター情報の入力として以下を設定します。
Step1.
・クラスター名：新規クラスターの名前を入力します。
・ローカルを優先：EJB WLMにおいて、EJBクライアントからのリクエストが同一プロセスで稼動するEJBコンテナーに優
先して割り振られるかどうかの設定です。ローカルを優先することによって、パフォーマンスが向上します。
・複製ドメインを作成するかどうか設定します。
・既存サーバー：空のクラスターを作成するか、既存のアプリケーション・サーバーをクラスターに追加するかを指定しま
す。既存のアプリケーション・サーバーをクラスターに追加する場合、そのアプリケーション・サーバーは他のクラスター・
メンバーのテンプレートとなります。アプリケーション・サーバーをクラスターに追加した場合、クラスターから除去するた
めにはアプリケーション・サーバーを削除することになるので注意してください。
・ウェイト：クラスターに対するWLMにおける、サーバーのウェイト値を指定します。値は0から20まで設定可能です。0に
設定した場合、割り振り可能な唯一のアプリケーション・サーバーにならない限りは割り振られません。
Step2. クラスター・メンバーを追加します。新規クラスター・メンバーの追加ごとに以下の設定を行います。
・メンバー名：クラスターに追加する新規クラスター・メンバー（アプリケーション・サーバー）の名前を入力します。
・ノードの選択：サーバーを配置するノードを選択します。
・ウェイト：サーバーのウェイトを指定します。
・固有HTTPポートそ生成するかどうかを指定します。
Step3. 要約が表示されるので、内容を確認して、「終了」ボタンを押します。構成の保管も実行します。
「サーバー・クラスター」ページ（「サーバー」＞「クラスター」）ではセル内のクラスターとその稼動状況を確認することがで
き、クラスターに対して、始動/停止、ripple始動、強制停止が可能です。クラスターに対するこれらの操作はクラスターの
メンバーであるすべてのサーバーに対しての操作となります。ripple始動は、各クラスター・メンバーを停止した後に再始
動を行います。
「クラスター・メンバー」ページ（「<Clusters_name>」＞「クラスター・メンバー」）では、クラスター・メンバーであるアプリケー
ション・サーバーの稼動状況を確認でき、メンバーごとに始動/停止の操作が可能です。また、クラスターに新規メンバー
を追加したい場合は、「新規作成」ボタンから追加することができます。
88
IBM Software Group | WebSphere software
WLM (Webコンテナー /EJBコンテナー)
◆ Webサーバー・プラグインを経由するWebコンテナーへのリクエストに対して提供
◆ Webコンテナーのクラスター化により実現
WebServer
WebServer
Plug-in
◆ Webコンテナーへのルーティングテーブルは「
「 plugin-cfg.xml」
」が提供
◆割り振りの手法は ”重
重み付けラウンドロビン”
ラウンドロビン を使用
- アプリケーション・サーバーに重み付けをし、それに基づいて割り振る
◆プライマリー/バックアップサーバー・リスト
Web
Web
Container
Container
Web
Web
Container
Container
Web
Web
Container
Container
- アプリケーション・サーバーに対しプライマリーとバックアップの指定
- プライマリー指定のアプリケーション・サーバー障害時にバックアップサー
バーに割り振る
◆セッションIDを持つリクエストに対しては”SessionAffinity 機能”により同一サー
機能
バーに割り振る⇒クラスター・メンバーには”Clone ID”がアサインされる。
Cluster
◆ EJBクライアントからのEJBコンテナーへのリクエストに対して提供
EJBClient
EJBClient
◆ EJBコンテナーのクラスター化により実現
ORB
WLM
Plug-in
◆ EJBクライアントとEJBコンテナーは別プロセスでなければならない
- 同一プロセスの場合、”Server Affinity機能
機能”により別プロセスのEJBコ
機能
ンテナーへは割り振られない
◆割り振りの手法は”重
重み付けラウンドロビン”を使用
ラウンドロビン
EJB
EJB
Container
Container
EJB
EJB
Container
Container
Cluster
EJB
EJB
Container
Container
- アプリケーション・サーバーに重み付けをし、それに基づいて割り振る
◆ 「ローカルを優先」設定により、同一ノードのEJBコンテナーを優先すること
も可能
◆ “Transaction Affinity”により同じトランザクション内のリクエストは同じ
サーバーに割り振る
89
WebコンテナーWLMはクラスターメンバーがWebコンテナーサービスが稼動することで実現します。Webサーバー・プラグ
インを経由するWebコンテナーへのリクエストに対して負荷分散、フェイルオーバーの機能を実施します。Webコンテナー
がリクエストをどのサーバーにどのように割振るかというルーティングテーブルはplugin-cfg.xmlに記述されます。Web
サーバープラグインはそのファイルを見てリクエストを割り振ります。
負荷分散のロジックはクラスターメンバー設定におけるウェイトに従った重み付けラウンドロビンを使用しています。また、
クラスターメンバーとなるアプリケーション・サーバーに対しプライマリーかバックアップの指定をすることが可能です。
バックアップ指定のサーバーはプライマリーサーバー障害時にのみサービスを提供することになります。
WebコンテナーWLMではV5と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエストはセッ
ションIDが作成されたサーバーにリクエストを続けることが可能です。
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ではV5と同様にTransactionAffinityにより、トランザクション中のリクエストは必ず前回と同じEJBコン
テナーへリクエストを割振られます。
89
IBM Software Group | WebSphere software
システム管理ツール
◆ WASでは以下のシステム管理ツールを提供 ◆
- 管理コンソール – ブラウザーベースのGUIシステム管理
- wsadmin – スクリプト言語でシステム管理(管理コンソールと同等機能を保持)
- コマンド – 一般的に使用頻度の高い機能のみ
- JMXプログラミング – 独自の管理機能を開発可能
管理コンソール
管理コンソール
ノード
DM
adminconsole
User application
wsadmin
SOAP (8880)
or RMI (9100)
JMXプログ
プログ
ラミング
80)
(88 100)
P
A
SO MI (9
R
r
o
管理サービス
管理サービス / JMX
構成変更
構成変更
embedded http
HTTP
(9060)
Webコンテナー
コンテナー
構成レポジトリー
構成レポジトリー
XML構成
構成ファイル
構成ファイル
アプリケーション
オペレーション変更
オペレーション
オペレーション変更
変更
オペレーション変更
ランタイム･
ランタイム･サービス
90
WASでは以下の４つのシステム管理ツールを提供しています。
・管理コンソール
－システム管理機能を提供するグラフィカル・インターフェース
－実体はエンタープライズ・アプリケーションでデプロイメント・マネージャー(DM)上で稼動
－ブラウザーからのアクセスが可能でリモート環境から構成管理を行いたい場合に便利
・コマンド
－アプリケーション・サーバーの起動/停止、バックアップ/リストアなど、使用頻度の高い特定の機能を提供
－特化した機能のみ使用したい場合に便利
・wsadmin
－スクリプト言語で管理操作を実行
－管理コンソールで可能な処理を全てカバー
－シェル化して運用を自動化したい場合に有用
・JMXプログラミング
－Javaの標準であるシステム管理API(JMX)を使用して独自の管理機能を開発可能
90
IBM Software Group | WebSphere software
システム管理ツール (wsadmin)
構成情報に対する操作
AdminConfig
AdminApp
wsadmin
New
v6
AdminTask
構成データの操作
(例) DataSourceの作成
エンタープライズ･アプリケーションの操作
(例) EARの追加・更新
管理コマンドの実行
(例) アプリケーション・サーバーの作成
稼働オブジェクトに対する操作
AdminControl
Help
基本コマンドシンタックス
インタラクティブ･モード
>> wsadmin
wsadmin
wsadmin>
wsadmin> $AdminApp
$AdminApp list
list
WASプロセス内で稼動するMBeanの操作
(例) アプリケーション･サーバーの始動/停止
稼動中アプリケーションリストの取得
ヘルプ、MBean情報の表示
<<管理オブジェクト
管理オブジェクト>> <<コマンド
コマンド>> （<
（<コマンド･パラメーター
コマンド･パラメーター>）
>）
コマンド実行
>> wsadmin
wsadmin –c
–c “$AdminApp
“$AdminApp list”
list”
スクリプト実行
>> wsadmin
wsadmin –f
–f list.jacl
list.jacl
91
wsadminはV5から導入された管理用スクリプト･インターフェースです。wsadminはJakartaのBSF（Bean Scripting
Framework）というフレームワークに準拠しています。BSFではNetREXXやJava Scriptなどもサポートしていますが、WAS
でテストされサンプルが提供されるなど正式サポート対象のスクリプト言語は「JACL」および「Jython」の二つです。（※
この資料でのサンプルはいずれもJACLで記載しています。）V5で使用していたスクリプトは原則V6で引き継げますが、
トランザクションログの操作など若干の変更が必要なものもあります。詳細はInfoCenterの” Migrating administrative
scripts from 5.x to 6.0”をご参照ください。
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でスクリプトファイ
ルを呼び出すスクリプトモードでの実行がそれぞれ可能です。
91
IBM Software Group | WebSphere software
システム管理ツール (コマンド)
◆ startManager
コマンドによるDMの起動 ◆
①startManager コマンドの実行 : <Profile_root>/bin/startManager
◆ stopManager
コマンドによるDMの停止 ◆
①stopManager コマンドの実行 : <Profile_root>/bin/stopManager
◆ addNodeコマンドによるセルへのノードの追加 ◆
①DMの起動
②addNode コマンドの実行 : <Profile_root>/bin/addNode <dmｇｒ_host>
オプション
”-includeapps” : 追加時にアプリケーションをセルに引き継ぐことが可能
“-includebuses” : 追加時にセルに統合されるノードからバスをコピーしてセルに引き継ぐことが可能
“-trace” : デバッグのためにログファイルに追加のトレース情報を生成
“-logfile <filename> : ログファイルのロケーションを指定。
デフォルトではaddNode.logという名前で、追加されるノードのプロファイ
ルのlogsディレクトリーに作成される
92
セル環境を構成する際の、ノードをセル環境に追加する方法について説明します。
セルへのノードの追加はaddNodeコマンドと管理コンソールからの２つの方法があります。
addNodeコマンドを実行してセルへのノードの追加を行う場合、まずDMを起動させ追加するノードのプロファイル・ディレ
クトリ下で以下のコマンドを実行します。ノードの追加と共に、ノード・エージェントが定義され、ノード・エージェントは、
addNode コマンドの一部として自動的に開始されます。
<Profile_root>/bin/addNode <dmgr_host> <dmgr_port>
<dmgr_host>はDMの稼動しているホスト名でこの引数は必須で、これ以外はすべてオプションとなります。
このコマンドのデフォルトの Java Management Extensions (JMX) コネクターは、 Simple Object Access Protocol
(SOAP)です。<dmgr_port>でDMのJMXポート番号を指定します。DM のデフォルトのSOAPのポート番号は、“8879”です。
オプションとして”-includeapps”を使用すると、ノードの統合時にアプリケーションをセルに引き継ぐことができます。
<Profile_root>/bin/addNode <dmgr_host> -includeapps
addNodeコマンドのオプション機能についての詳細は以下リンクのInfoCenter「addNodeコマンド」をご参照ください。
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_addn
ode.html
管理コンソールからノードの追加を行う場合、該当ノードでサーバーが稼動している必要があります。カスタム・プロファ
イルの場合は、アプリケーション・サーバーが存在していないので管理コンソールからのノードの追加はできません。カ
スタム・プロファイルで作成した空のノードはaddNodeコマンドでセルへ追加します。
92
IBM Software Group | WebSphere software
システム管理ツール（管理コンソール）
前の変更を回復
user A
user A
①変更、ログアウト
①変更、ログアウト
②再ログオン
②再ログオン
server.xml
保管の矛盾
③無効なユーザー
へのメッセージ
ログインの競合
user A
①ログイン
①ログイン
user A
user B
①保管
①保管
②保管
②保管
user B
②ログイン
②ログイン
user A
③無効なユーザー
③無効なユーザー
93
WAS v6のシステム管理においては、ユーザーごとにテンポラリー･ワークスペースを持つため、上記のような状態になる
場合があります。
前の変更を回復：
①で管理コンソールで処理を行った後保管せずにログアウトもしくはブラウザーを終了した場合、変更はワークスペース
にのみ書き込まれていることになるので、②で再ログオンした際に前セッションの変更をリカバリーするか、変更を破棄
してマスターリポジトリーを元に管理操作を継続するかを問い合わせられます。
保管の矛盾：
もし同じ構成情報を複数のユーザーが参照・更新を行おうとした場合、そのままでは後者の情報のみが反映される後勝
ちとなってしまうのですが、同じ構成情報を別ユーザーが変更した場合②で「保管」時に警告されますので必要に応じ
行った変更を破棄するか、上書き保存を行うかを選択してください。
ログインの競合／無効なセッション：
別ブラウザー画面から同じユーザーでログオンを行おうとすると、ログインの競合が検知されます。②で後からログオン
した方は先にログオンしているユーザーをログアウトすることも出来ます。その場合先にログオンしているユーザーが継
続処理を行おうとした際に③の無効なセッションの画面が表示されます。
93
IBM Software Group | WebSphere software
メッセージング (JMSプロバイダー機能)
◆ Message
Driven Bean (MDB)で処理をロールバックした際の動き ◆
- MDBが関連付いている宛先の「最大デリバリー失敗数」に達するまで、メッセージの受
信 → ロールバック を繰り返す
- 最大デリバリー失敗数に達すると、「例外宛先」にメッセージを退避する
- 例外宛先への送信が失敗した場合や、例外宛先を「なし」に指定した場合は、ループに
陥るので注意
⇒ アプリケーション・ハンドリングや運用による回避策が必要
①
MDBアプリケーション
receive
public void onMessage( ){
例外発生!
繰り返し
②
rollback
③
}
ejbctx.setRollbackOnly();
例外宛先へ退避
例外宛先
94
メッセージの内容やフォーマットが不正などの理由で、何度処理を繰り返してもエラーになってしまい、バックアウト処理
がループしてしまう場合があります。このようなメッセージをポイズン・メッセージと呼びます。バックアウト処理のループ
により後続メッセージの処理が止まることを避けるために、MDBはポイズン・メッセージを別のキュー（例外宛先）に退避
させる仕組みを提供します。
メッセージの退避を行うには、宛先の「最大デリバリー失敗数」と「例外宛先」プロパティーを指定します。
•MDB内でメッセージのロールバックが行われると、メッセージの「再デリバリー回数」が１つインクリメントされます。
•ロールバックの回数が宛先の「最大デリバリー失敗数」に達すると、メッセージを「例外宛先」に指定したキューに
退避します。
例外宛先は、SIBus全体で同じ宛先を例外宛先として使用することも可能ですし（「システム」 を指定）、宛先ごとに固有
の例外宛先を指定する(「指定」)ことも可能です。
例外宛先に何らかの理由でメッセージの送信が失敗した場合、あるいはメッセージの順序性を保つ等の理由で例外宛
先を指定しない（「なし」に指定）場合には、MDBはループに陥ります。この場合、CPUなどのリソースを大量に消費する
ほか、WASのスレッド・ハング検知機能でも検知することができません。現状ではアプリケーション・ロジックと運用で回
避する必要があります。
94
IBM Software Group | WebSphere software
メッセージング (Network Deployment Cellでの構成)
セル内でのSIBusの構成 ⇒ SIBus間でSIBusリンク接続
セルを跨るSIBusの構成 ⇒ SIBusの管理がセル単位, 他セルのSIBusにSIBusリンクで接続可能
MQネットワークにMQリンクで接続可能
Cell 1
WebSphere MQ
Queue
Manager
SIB 1
JMS Client
ME
Server A
JMS Client
ME
Server B
JMS Client
MQリンク
リンク
ME
Server C
Cell 2
SIB 1
SIBusリンク
リンク
JMS Client
SIB 2
JMS Client
ME
Server D
JMS Client
ME
Server E
JMS Client
ME
SIBus リンク
ME
Server A
JMS Client
ME
Server B
Server F
JMS Client = JSMを介してメッセージング・サービスを利用するアプリケーション
95
これは大規模な組織向きのSIBusの構成です。部門によってWASのセルを分けることができます。また既存の
WebSphere MQネットワークとも接続しています。セル内およびセル間のSIBusもSIBusリンクにより接続できます。
95
IBM Software Group | WebSphere software
練習問題
19. Webコンテナー
コンテナーWLMを
を実現するため
コンテナー
実現するため、
するため、システム管理者
システム管理者は
管理者はクラスターを
クラスターを作成した
作成した後
した後、クラス
ター・
ター・メンバーに
メンバーに対し、それぞれのサーバー
それぞれのサーバーへの
サーバーへの割
への割り振りの重
りの重み付けを設定
けを設定なければなりませ
設定なければなりませ
ん。正しいものは次
しいものは次のうちどれですか？
のうちどれですか？
各事業所に配置されたサーバーはすべて性能が同じであるため、どのサーバーにも均等に”0”を設定する。
SessionAffinityの機能を使用したいので、ラウンドロビンで割り振りしないよう設定はしない。
サーバーAはサーバーBの2倍の性能を保持するので、サーバーAは”100”、サーバーBは”50”を設定する。
“0”を設定したサーバーには、割り振り可能な唯一のアプリケーション・サーバーにならない限りは割り振られ
ない。
A.
B.
C.
D.
20. wsadminスクリプト
スクリプトを
に追加するという
スクリプトを使用して
使用してアプリケーション
してアプリケーション・
アプリケーション・サーバーを
サーバーをSIBusに
追加するという管理作業
するという管理作業
を行う必要があります
スクリプト・
必要があります。
があります。システム管理者
システム管理者は
管理者は次のうちどのwsadminスクリプト
のうちどの
スクリプト・オブジェクトを
オブジェクトを使
用する必要
する必要がありますか
必要がありますか？
がありますか？
A.
B.
C.
D.
AdminManagement
AdminControl
AdminTask
AdminJMS
96
<memo>
96
IBM Software Group | WebSphere software
練習問題回答
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
B
A
C
A
C
B
C
C
C
A
⑪
⑫
⑬
⑭
⑮
⑯
⑰
⑱
⑲
⑳
B
C
B
A
A
B
C
B
D
C
お疲れ様でした。
WebSphere 認定試験がんばってください。
97
<memo>
97