WebSphere Application Server Network Deployment...

1

© 2007 IBM Corporation

®

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

WebSphere Application Server V6.1 Network Deployment, Core Administration

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

試験対策テキスト

2007年9月第1.1版発行

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

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

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

たします。

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

2

IBM Software Group | WebSphere software

2

目次

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

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

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

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

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

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

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

7. 問題判別 ………………………………………………… 92

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

<memo>

3


3

認定試験概要

<memo>

4


4

試験概要

【認定資格】WebSphere Application Server Network Deployment V6.1認定システムアドミニストレーター

【試験名称】WebSphere Application Server Network Deployment V6.1Core Administration

【試験時間】90分

【試験料金】18,900円

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

【出題数】54問

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

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

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

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

5


5

出題範囲

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

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

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

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

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

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

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

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

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

・WebSphereリソースの保護

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・WASのSIP(Session Initiation Protocol)、ポートレット・コンテナーサポートについて理解できる

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

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

主な内容章タイトル

<memo>

6


6

出題範囲（続き）

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

・ASTのログ・アナライザーを利用して問題の特定ができる / トレース機能を利用できる

・FFDCツールを利用できる

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

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

・IBM Support Assistantを利用できる

7．問題判別(13％)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主な内容章タイトル

<memo>

7


7

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

<memo>

8


8

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

負荷分散サーバー：クライアントからの要求を受けつけ、Webサーバへ転送。ロードバランサーとも呼ぶ

Webサーバー

– 静的ページの要求であればクライアントに転送

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

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

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

負荷分散サーバー

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

DBサーバーFWFW

DMZ（非武装地帯）

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

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

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

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

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

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

ントに返します。

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

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

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

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

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

よって異なります。

9


9

WASV6.1のエディション

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®® ®® ®® ®® ®® ®®

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

・WebSphere Application Server V6.1 - Express

・WebSphere Application Server V6.1 (以降Base)

・WebSphere Application Server V6.1 - Network Deployment (以降ND)

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

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

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

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

10


10

各パッケージの比較

○○○SI Bus機能

○○○プログラミング・モデル拡張※

○××HA機能

○××クラスター構成

○××Edgeコンポーネント同梱

○○×64bit対応予定

○○○J2EE1.4サポート(Servlet 2.4/JSP 2.0/EJB 2.1)

無制限無制限2CPUまで導入可能CPU数

WAS NDWAS (Base)WAS Express内容

プログラミング拡張の種類についてはインフォセンターの下記項目をご覧下さい

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_appsvcs.html

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

WAS V6.1では、J2EE1.4をサポートします。J2EE 1.4はServlet 2.4、JSP 2.0、EJB 2.1をサポートします。

WASV5ではEnterprise Editionにしか含まれなかったプログラミング・モデル拡張（非同期BeanやスタートアップBean,ス

ケジューラー・サービスなど）はExpressからサポートされるようになりました。

11


11

WASの基本構成要素

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

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

– J2EEアプリケーション実行環境（以下の機能）を提供

• Webコンテナー– SIPコンテナー

– Portletコンテナー

• EJBコンテナー

• JCAサービス

• Webサービスエンジン

• セキュリティ

• ネーミング・サービス

• トランザクション

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

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

• 動的キャッシュ

Webサーバー上の構成要素

• Webサーバー

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

クライアント

Application Server

Webサーバー

Webコンテナー

Webサーバー

プラグイン

HTTPトランス

ポート・チェーン

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

JCAサービス

Portletコンテナー

Webサービスエンジン

セキュリティ

ネーミングサービス

トランザクションパフォーマンス

インフラストラクチャー

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

動的キャッシュ

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

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

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

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

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

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

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

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

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

します。

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

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

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

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

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

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

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

Webサーバー上の構成要素

○Webサーバー：HTTPのリクエストを受け付けます。

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

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

12


12

WAS Network Deploymentの管理トポロジー

アプリケーション

サーバーD

ノード B ノード C

ノード・エージェント

ノード A マスター

セル・構成情報

ノードB・構成情報

サーバーA・構成情報

ローカルローカル

EARファイルアプリケー

ションサーバーC


サーバーB

EARファイルアプリケーション

サーバーA



セル


サーバーB・構成情報

ノードC・構成情報

サーバーC・構成情報

サーバーD・構成情報

サーバーA・構成情報

サーバーB・構成情報

サーバーC・構成情報

サーバーD・構成情報

ノードB・構成情報

ノードC・構成情報

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

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

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

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

構成情報を保管します。

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

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

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

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

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

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

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

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

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

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

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

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

13


13

管理トポロジー用語解説

セル (Cell)– ノードの集まりで論理的な管理の単位

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

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

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

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

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

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

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

– 管理用のエージェント

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

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

・セル(Cell)

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

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

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

・ノード (Node)

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

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

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

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

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

14


14

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

3段階でのWLMを提供

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

– Edge ComponentsのLoad Balancer（負荷分散サーバー）によるWebサーバーへの負荷分散

Load Balancer(Primary)

Load Balancer(Backup)

プラグイン

HTTPサーバー

プラグイン

HTTPサーバー

ApplicationServer

Webコンテナー

ApplicationServer

Webコンテナー

ApplicationServer

EJBコンテナー

ApplicationServer

EJBコンテナー

① Load BalancerによるHTTPサーバーへのWLM ② Webサーバー・プラグ

インによるWebコンテナーへのWLM

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

DB

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コンテナーに対して分散をおこないます。

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

15


15

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

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






コア・グループ

障害検知

HAマネージャー






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

の引継ぎ情報の共有

(EJB WLM情報の引継ぎ)

構成情報の作成・変更

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

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

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

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

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

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

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

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

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

16


16

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は、アプリケーション・サーバーの

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

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

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

この構成において、リカバリーに要する時間は数秒ですが、トランザクションログを保管する共有ディスクが必要になり

ます。

17


17

JMSプロバイダー機能

WAS V6 で利用可能なJMSプロバイダー

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

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

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

• WMQとリンク可能

– WebSphere MQ

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

• 実績が豊富

• 高い信頼性

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

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

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

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

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

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

JMSプロバイダー

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

SIBus

JMSClient

WMQ

他社メッセージング製品

JMS

ClientJMS JMS

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

「デフォルト・メッセージング」は、WAS V6からの新機能である、SIBus (Service Integration Bus：サービス統合バス)の

メッセージング機能を利用したJMSプロバイダーです（SIBusについては後述）。WAS V6.1はJ2EE 1.4を実装しているの

で、J2EE 1.4に含まれるJMS1.1を利用可能です。

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

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

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

します。

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

18


18

SIBus(サービス統合バス）

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

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

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

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

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

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

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

SI-Bus

JMSJMS

リンク

WebSphereMQ

WebSphereV6セル

Webｻｰﾋﾞｽ

SI-Bus

JMSJMSWebｻｰﾋﾞｽ

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

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

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

19


19

（参考）SIBusのメッセージング機能（デフォルト・メッセージング）

V6から新しいJavaベースのメッセージング・エンジンを搭載。

– Pure Java JMS 1.1 provider• V5では、インストール時のオプションにより、WebSphere MQをインストール。

• V6では、WASの標準のインストールに含まれる。

– アプリケーション・サーバーJVMの一部として稼働する。

– MQと同等の機能を提供するが、MQに依存するコード体系ではなくなった

– パーシスタンス・メッセージは、Cloudscapeデータベースか、DB2/Oracle等の外部DBに保管する。

– HA機能の対象であり、メッセージングエンジンもフェイルオーバーされる。

ESB (WASV6ではサービス統合バス）のエンジンとして使用される。

WASV5.ｘWASV5.ｘ

EventBroker

MQ

JMS(MA88)

複数のメッセージングプロセス

CとJavaコード

WAS V6統合された

メッセージング

WAS V6統合された

メッセージング

パーシスタント・メッセージの格納用DB

WAS V5では組み込みメッセージング（Embedded Messaging)が同梱されていましたが、V6ではSIBusが提供するメッセー

ジング・エンジンが提供されたことで、アプリケーション・サーバーの一部としてインストールされます。そのため別途組み

込みメッセージングの機能をインストールする必要はなくなりました。

さらに組み込みメッセージングはMQのサブセットとしてMQアプリケーションに依存するコード体系でしたが、その依存性

もなくなりました。WebSphere MQ およびデフォルト・メッセージングは独立した機能であり、共有しているモジュールや構

成データはありません。

機能もアップグレードされ、キューのブラウンジングが行えるようになったなど管理機能も充実してきています。

さらにWebSphereMQネットワークを接続することにより、SIBusを経由してMQキュー・マネージャー間とのメッセージ送受

信ができるようになりました。

なお、サービス統合バス（SIBus）が提供するメッセージング・エンジンはJMS1.1に準拠しています。そのため、アプリケー

ションを開発する際はJMS1.1を利用するようにしてください。

20


20

バス

SIBusの高可用性構成

メッセージング・エンジン（ME)の高可用性とワークロード共用

高可用性(High Availability)– HAマネージャーを使用し、サーバーから別のサーバーへのMEをフェールオーバー

ワークロード共用(Workload Sharing)– 複数のメッセージング・エンジン間でワークロードの共用

– 宛先の区画化(パーティショニング)とも言われる

バス

FailOver

高可用性(High Availability)

宛先アプリケーション

ワークロード共用

Load Balancing

Cluster

Cluster Member

Cluster Member

ME

ME

サーバー障害

Cluster Member

Cluster Member

ME

Cluster Member

ME

Cluster

SIBusのメッセージング・エンジン(ME)では、高可用性と拡張性（ワークロード共用）の機能を提供します。

バスのバスメンバーとして、「サーバー」を指定すると、単一のMEが作成されます。この構成では、MEはSingle Point of

Failureとなり、ワークロードを共用、つまり複数MEでの処理をすることはできません。WAS V6のMEでは、HAマネー

ジャーを使用したMEのフェールオーバーの機能を提供しています。また、複数のMEでのワークロード共用が可能です。

この2つの機能を組み合わせて、高可用性と拡張性を備えたサービス統合バスを構築することが可能です。これらの構

成では、バスのバス・メンバーとして「クラスター」を指定します。

○高可用性

バスメンバーに「クラスター」を指定することによって提供されます。バスメンバーに「クラスター」を指定することによって、

クラスター内のひとつのアプリケーション・サーバー上でMEが起動します。そのMEが稼働するアプリケーション・サー

バーに障害が発生すると、HA Managerが検知し、別のアプリケーション・サーバーでME機能が引き継がれます。

○ワークロード共用

デフォルトではバスメンバーに「クラスター」を指定するとクラスター内のひとつのアプリケーション・サーバー上でひとつ

のMEが起動します。ワークロード共用機能では、クラスター内に複数のMEを稼働することができます。これによりMEの

拡張性を提供します。ワークロード共用は「宛先の区画化」「宛先のパーティショニング」とも呼ばれます。

21


21

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

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

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

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

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

WAS V6.1 実行環境サポート

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

– SIPコンテナーの提供

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

– SIP Proxyの提供

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

WAS V6.1 開発サポート

– WAS6.1同梱のAST (Application Server Toolkit) がSIPアプリケーションの開発をサポート

• SIP サーブレットのスケルトンをウィザードで生成doInvite, doByeなどSIPサーブレットのメソッド選択可能

• SAR(SIP Application Archive)ファイルをエクスポートし、WASにインストール

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

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

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

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

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

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

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

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

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

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

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

こともできます。

SIPアプリケーションはSAR(SIP Application Archive)ファイル形式で作成され、WASにインストールされます。

22


22

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

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

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

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

WAS V6.1のポートレットサポート

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

• 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を

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

23


23

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

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、HIS、Webコンテナー、EJBコンテナーにおいてキャッシュが可

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

・Caching Proxy

Caching ProxyはLoad BalancerとWebサーバーの間に配置し、静的コンテンツのキャッシュ、照会応答キャッシュ（動的コ

ンテンツのキャッシュ）をします。

WAS V6では、WebSphere Edge ComponentがProxy Serverを提供しており、リバース・プロキシーやコンテンツ・ベース

のルーティング、サーブレット/キャッシングとの統合機能があります。（ただし、V6.1よりEdge ComponentのCaching

Proxyの機能は非推奨機能となりました。）

・WAS Dynamic Cache

WASの動的キャッシュでは、サーブレット・キャッシュ、コマンド・キャッシュ、オブジェクト・キャッシュの３つの種類があり

ます。

・外部キャッシュ

サーブレット・キャッシュを前段のコンポーネントに配置します。外部キャッシュ先にはWebServer Plugin上のESIキャッ

シュなどがあります。

24


24

練習問題

1. ND環境でアプリケーション・サーバー・プロセスを始動する際に、稼働していなければならないプロセスを次の中から1つ選択してください。

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

B) デプロイメント・マネージャーとノードエージェント

C) ノード・エージェント

2. SARファイルが使用されるWASのコンポーネントを次の中から1つ選択してください。

A) SIPコンテナー

B) Session管理機能

C) Portletコンテナー

3. リバース・プロキシーおよびコンテンツ・ベースのルーティングを提供するコンポーネントを次の中から1つ選択してください

A) Edgeコンポーネント－ロードバランサー

B) Edgeコンポーネント－キャッシング・プロキシー

C) Webサーバープラグイン

<memo>

25


25

2章 WASの導入と構成

<memo>

26


26

WASの導入にあたって

110MBIBM HTTP Server

25MBC:¥Program Files¥ibm¥gsk7

200MBWebサーバープラグイン

100MBC:¥temp

10MBApplication Server プロファイル用

200MBSampleアプリケーションのApplicationServerプロファイル用

30MBDeployment manager プロファイル用

730MBWAS-ND C:¥Program Files¥IBM¥WebSphere¥AppServer

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

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

– ハードウェアおよびソフトウェア前提条件

• http://www-06.ibm.com/software/webservers/appserv/doc/latest/prereq.htmlにて確認できます

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

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

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

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

– ディスクに十分な空き容量があること（以下、Windowsの例）

<memo>

27


27

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コマンドでノードを統合

8. インストールの確認http://<ホスト名>:9080/snoop へアクセス。

結果が正常に表示されれば、アプリケーション・サーバーの起動は正常Installverコマンド

インストールファイルのチェック・比較、構成ファイルのインベントリー作成が行われる

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

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

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

インストールの詳細については、http://www.ibm.com/jp/software/websphere/developer/was/wv6/install/ も参照くだ

さい。

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

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

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

28


28

WebSphereプロファイルとは？

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

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

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

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

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

利点

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

作成可能。

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

プロファイルの種類

– デプロイメント・マネージャー、アプリケーション・サーバー、カスタム、セルの4種類。

製品バイナリー

+

+

ノードWebSphereプロファイル

WebSphereプロファイル

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

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

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

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

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

た。

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

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

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

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

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

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

できません。

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

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

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

プロファイルの種類としては、デプロイメント・マネージャー、アプリケーション・サーバー、カスタム、セルの4種類があり

ます。

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

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

要ありません。

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

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

ます。

29


29

プロファイルの作成と操作プロファイルは導入されたWASの製品コードを使用して、WebSphereのランタイム環境を提供

するための構成ファイル群

①WASインストーラーで導入②プロファイル管理ツール／manageprofilesで作成

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

WAS製品コード

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

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

③manageprofilesで操作

<WAS_root>/WebSphere/AppServer

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

ASプロファイル DM

DMプロファイル AS

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

セル・プロファイル DMAS NA

◆プロファイル管理ツール(Profile Management Tool : PMT)

◆manageprofilesコマンド

プロファイル･タイプの選択画面セルプロファイルDMプロファイルASプロファイルカスタム･プロファイル

プロファイル･タイプの選択画面セルプロファイルDMプロファイルASプロファイルカスタム･プロファイル

ASプロファイル作成ASプロファイル作成

プロファイル削除ヘルププロファイル削除ヘルプ

ASプロファイル作成ヘルプASプロファイル作成ヘルプ

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

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

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

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

行います。

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

validateAndUpdateRegistry］

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

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

・ DMプロファイル <WAS_root>/profileTemplates/dmgr

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

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

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

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

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

30


30

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

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

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

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

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

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

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

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

– 本番での使用は非推奨

ポート番号のアサイン

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

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

updatePorts.antスクリプトも提供

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

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

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

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

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

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

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

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

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

奨されません。

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

ているWAS V6.0以上が使用しているポート番号を確認し、競合しないポート番号をアサインします。この時、他のユー

ザー名でインストールしたWASは確認対象とはなりませんので、V6.1からサポートされた非Root権限でのインストールを

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

了すると、現在使用されていないポートのみが｢ポートの割り当て｣一覧に表示されます。PMTではさらに「デフォルトの

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

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

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

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

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

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

html

31


31

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

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

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

標準プロファイル作成

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

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

拡張プロファイル作成

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

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

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

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

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

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

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

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

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

32


32

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

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

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

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

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

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

実行方法

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

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

す。

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

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

何台ものサーバーにインストールを行いたいときなど便利です。

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

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

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_runSilent.ht

ml

33


33

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

-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の操作

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

34


34

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の導入のトラブルシューティングの詳細については、下記 Info Center をご参照ください。

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

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

35


35

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

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

– 「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 ファイ

ルを探します。

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

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

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tins_tr

oubleplugin.html

36


36

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の作成（ビルド定義を作成後に自動生成される）

インストールを行う上で便利なツールとして、WASV6.1ではInstallation Factory V6.1が同梱されています。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に組み

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

37


37

練習問題

4. カスタマイズ・インストール・パッケージ（CIP）とそのビルド定義ファイルを生成するツールを次の中から1つ選択してください。

A) Installation FactoryB) Customize Installation FactoryC) Customize Installation Tool

5. システム管理者が応答ファイルを使用してWASのサイレントインストールを予定しています。WASの導入ディレクトリを変更するために、修正が必要な応答ファイルオプションを次の中から1つ選択してください。

A) installLocationB) installDirectotyC) feature

6. プロファイル管理ツール（PMT）の拡張プロファイル設定で、実施できないものを次の中から1つ選択してください。

A) 管理コンソールの導入設定

B) プロファイルをデフォルト・プロファイルに設定

C) ユーザー・アプリケーションの初期導入

<memo>

38


38

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

<memo>

39


39

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

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

にインストール必要があります。

AST (Application Server Toolkit)やRational Application Developerなどのツールがパッケージ

ング機能を提供します。

EJBコンポーネント

WARWAR

JARJAR

EAREAR

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

WebDD

EJBDDApplication

DD

WASサーバー

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

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

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

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

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にインストールします。管理コンソールから

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

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

成情報を反映させます。

40


40

AST (Application Server Toolkit)の機能

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

– Eclipse 3.1Web Tools Platform (WTP) 1.0 ベース

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

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

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

– ポートレット(JSR168)開発

– SIPサーブレット(JSR116)開発

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

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

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

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

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

デプロイメント・テスト

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

– Enhanced EAR

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

Windows、Linuxをサポート

Application Server Toolkit V6.0 は、 HTML や JSP、サーブレット、JavaBeans 、EJBなど個々の J2EE 成果物をアセン

ブルし、デプロイメント・ディスクリプター(配置記述子)の編集を行うことができました。しかし、開発作業そのもの、つまり

コーディングを行うことを目的としておらず、WAS V6.0へのアセンブルとデプロイ専用のツールでした。

Application Server Toolkit V6.1 から大幅に機能が拡張され、HTML や JSP、サーブレット、JavaBeans、EJB の開発も

行うことができます。また、ポートレット(JSR168)開発、SIPサーブレット(JSR116)開発もサポートします。Automation Tool

では、WAS のスクリプト・ベース・管理ツールである wsadmin 用のJythonを開発、テスト、デバッグすることができます。

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

WebSphere Application Server V6.1 と同梱の AST だけで行うことも可能になりました。

注意点としては、ASTはWASテスト環境を含んでおりません。アプリケーションのテスト・実行のためには別途WAS V6.1

が必要となります。

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

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

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

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

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

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

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

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

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

41


41

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

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

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

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

Servlet 1

Servlet 2Aさん

Bさん

Cさん

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

勤務記録承認

交通費承認

契約書承認

制約

人事部門の役割

各部門長の役割

営業部門長の役割

役割

A1/A2/A3

B1/B2

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

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

EJB 1

EJB 2

設定

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

• アプリケーション開発時にAST（あるいはRational Application Developer)を使用

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

• アプリケーション開発時にAST（あるいはRational Application Developer)を使用

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

Servlet 1

Servlet 2

EJB 1

EJB 2

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

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

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

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

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

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

42


42

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

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

セル

クラスター

ノード

サーバー

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

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

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

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

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

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

できないことになります。『有効範囲』はセル、クラスター、ノード、サーバーが指定できます。

43


43

ネーミングサービス（Naming Service）

ネーミングサービスとは

– オブジェクトと名前を関連づけ、その名前をキーとしてオブジェクトを検索するためのサービス

ネームスペース（Name Space/名前空間）

– ネーミングサービスにおいて、オブジェクトが格納されている空間

– ネーミングサービスから検索されるオブジェクトはネームスペースに階層的に格納される

J2EEにおけるネーミング・サービス

– アプリケーションコードから外部リソースへの統一されたアクセス環境を提供

– 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」にバインドする

ネーミング・サービスとはオブジェクトと名前を関連づけ、その名前とキーとしてオブジェクトを検索するためのサービス

です。ネーミング・サービスにおいて、オブジェクトが格納されている空間をネーム・スペース（名前空間）といいます。

J2EEにおけるネーミング・サービスは、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/.

44


44

（参考）ネーミング・サービス詳細

構成済み名前バインディング

– 以下のネーム・スペース・バインディングを管理者が定義可能

• EJB : セル内の一部のサーバーにインストールされているEJBホーム

• CORBA : CosNamingネーム・サーバーから使用可能なCORBAオブジェクト

• 間接 : JNDIによりアクセス可能なWASネーム・スペースでバインドされているオブジェクト

• ストリング : ストリング定義

ネーム・スペースの論理ビュー

– セル全体のネーム・スペースを統合した論理的ビュー

– 以下の4つのネーム・スペース区画で構成される

• システム・ネーム・スペース区画

• サーバー・ルート区画

• セル永続区画

• ノード永続区画

構成済み名前バインディング

WASでは、ネーム・スペース・バインディングを管理者が定義することができます。

例えば、セル外の既存アプリケーションから、そのアプリケーションの変更なく、セル内のJNDIで定義されているリソース

へのアクセスするときなどに使用できます。

構成済み名前バインディングの詳細については、下記 Info Center をご参照ください。

「構成済み名前バインディング」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cnam_

configured_bindings.html

ネーム・スペースの論理ビュー

セル全体のネーム・スペースは、セル内の全てのサーバー間で統合されています。各サーバープロセスには、ネーム

サーバーがあります。全てのネーム・サーバーは、セル・ネーム・スペースの論理ビューを提供します。

ネーム・スペースには、4つのネーム・スペース区画があり、それぞれがリンクして構成されています。

EJBホームおよびリソースなどのシステムにバインドされた定義は、サーバー・ルート区画にバインドされます。CORBA

や間接名前参照などの構成バインディング定義は、セル永続区画やノード永続区画にバインドされます。

ネーム・スペースの論理ビューの詳細については、下記 Info Center をご参照ください。

「ネーム・スペースの論理ビュー」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cnam_

name_space_partitions.html

45


45

ネームスペースとデータソース

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環境変数のデータベース・ドライバー・ファイルの配置場所を指定している変数の有効

範囲をノード毎に設定することにより、ノード毎の差異を保守しやすくすることができます。

46


46

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 リカバリーの認証エイリアスなどを設定します。

47


47

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名、バス名、（バス上の）キュー名、

デリバリー・モード、存続時間、優先順位を設定します。

48


48

システム管理ツール

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)を使用して独自の管理機能を開発可能

49


49

システム管理ツール (wsadmin)

wsadmin

AdminControl

AdminConfig

AdminApp

Help

構成データの操作(例) DataSourceの作成

WASプロセス内で稼動するMBeanの操作(例) アプリケーション･サーバーの始動/停止

稼動中アプリケーションリストの取得

エンタープライズ･アプリケーションの操作(例) EARの追加・更新

管理コマンドの実行(例) アプリケーション・サーバーの作成

ヘルプ、MBean情報の表示

> wsadminwsadmin> $AdminApp list> wsadminwsadmin> $AdminApp list

インタラクティブ･モード

> wsadmin –c “$AdminApp list”> wsadmin –c “$AdminApp list”

コマンド実行

> wsadmin –f list.jacl> wsadmin –f list.jacl

スクリプト実行

<管理オブジェクト> <コマンド> （<コマンド･パラメーター>）<管理オブジェクト> <コマンド> （<コマンド･パラメーター>）基本コマンドシンタックス

構成情報に対する操作

稼働オブジェクトに対する操作

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オプションで、使用するスクリプト言語の指定

をします。

50


50

(参考) 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() ←構成変更内容の保管

<memo>

51


51

練習問題

7. J2EEセキュリティ役割が設定されたアプリケーションをWASにインストールしようとしている。しかし、ユーザー/グループ定義がまだ決定していないため、セキュリティ役割マッピング設定は後で変更が必要である。以下の中から正しい記述を1つ選択してください。

A) 役割マッピング設定を変更するには、アプリケーションの再インストールが必要である

B) アプリケーション・インストール後も、管理コンソールから役割マッピング設定を変更可能

C) アプリケーション・インストール後に役割マッピング設定を変更するにはwsadminを使用する必要がある

8. WASのスクリプトツールwsadminの-langオプションで指定できる設定を次の中から1つ選択してください。

A) スクリプト言語の指定（Jython, Jacl）B) プロファイルスクリプトの指定（sample.py, sample.jacl)C) ログメッセージの言語指定（ja, en)

9. 様々なディレクトリ構造を使用している複数ノード構成のマシンでデータ・ソースを定義する際に、有効範囲をノードに設定するのが適しているパラメータを、次の中から1つ選択してください

A) JDBCプロバイダー

B) データ・ソース定義

C) WebSphere環境変数

<memo>

52


52

4章セキュリティー

<memo>

53


53

WebSphereセキュリティー

WebSphereで提供されるセキュリティーは、階層構造の上に成り立っています。

・OS、ネットワークレベル

ファイルやプログラムの実行権限やネットワークの暗号化(SSL)などのセキュリティー機能。

・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セキュリティー・サービスは各WebSphereプロセス（デプロイメント・マネージャー、ノード・エージェント、アプリ

ケーション・サーバー）上で稼働します。

54


54

管理セキュリティー

管理セキュリティー

– WASの管理をセキュアーにするための機能

管理セキュリティーの特徴

– 統合リポジトリーを使用することにより簡単にユーザ・レジストリーを構築できる

– WAS管理のみセキュアーにできる

– ウィザードにより簡単に構成できる

– セキュリティー構成を確認できる

– WAS導入時に簡単に構成できる

管理セキュリティーをONにすると

– 管理コンソールログイン時にユーザーID、パスワード認証が必要

– wsadminコマンド実行時にユーザーID、パスワード認証が必要

– WAS（DM、NAを含む）停止時にユーザーIDとパスワードが必要

– コンポーネント間の通信が自動的にSSL化

– LTPAを使用して認証を行う

プロファイル作成時/WAS導入時、あるいはプロファイル作成後に設定が可能

管理セキュリティーはWASの管理をセキュアーにするための機能です。 WAS V6.1では、WAS V6.0までのグローバル・

セキュリティーの機能が管理セキュリティーとアプリケーション・セキュリティーに分離されました。管理セキュリティーが

設定されるとWAS管理ツールを使用するのにユーザー認証が必要となります

管理セキュリティーには以下の様な特徴があります。

・ WAS V6.1の新機能である統合リポジトリーを使用されることによって、LDAPサーバーがなくてもユーザー・リポジト

リーを簡単に作成することが可能となりました。

・アプリケーション・セキュリティーと分離されたため、WASの管理のみをセキュアーにすることが可能となりました。アプ

リケーション・セキュリティーを必要としない場合は、アプリケーション・セキュリティーを設定する必要がなくなりました。

ただし、アプリケーション・セキュリティーを使用する場合には管理セキュリティーを設定する必要があります。

・セキュリティー構成ウィザードを使用することにより、低限の情報を順番に入力するだけで簡単に設定することが可

能となりました。これにより、サーバー･ユーザーIDやLTPAの設定は、ウィザードが自動的に設定してくれるようになりま

した。

・セキュリティー構成報告書により、現在のセキュリティー設定情報を一覧として表示することが可能となりました。

・管理セキュリティーはWAS導入時にも設定可能となったので、初めからセキュアーな環境を構築可能となりました。

（導入後の設定変更も可能です。）

・ WAS V6.1では、統合リポジトリーを使用することによって、LDAPサーバーが必須ではなくなりました。その為、管理セ

キュリティーだけを簡単に構築できるようになったので、WAS V6.0までのグローバル・セキュリティーよりも敷居が低くな

り、利用しやすくなりました。

55


55

管理ロール

7つの管理ロールでWAS管理機能の実行権限を定義

– モニター

• WASの構成およびランタイム状態を見るだけの権限

– オペレーター

• モニターに与えられる権限＋アプリケーションの開始/停止などランタイム状態を変更する権限（構成変更はできない）

– コンフィギュレーター

• モニターに与えられる権限＋WASの構成を変更する権限（ランタイム状況は変更できない）

– 管理者

• コンフィギュレーター、オペレーターに与えられる権限＋サーバー・パスワード、LTPAパスワード、鍵などセキュリティ設定を変更する権限

– iscadmins• 管理コンソール内のみユーザーとグループを管理する権限

– AdminSecurityManager• ユーザーを管理ロールにマップする権限

• wsadminでのみ使用可能

– デプロイヤー

• アプリケーションに対し、構成とランタイム操作が可能（ノードやサーバーなどに対する操作はできない）

• wsadminでのみ使用可能

WAS V6.1には、モニター、オペレーター、コンフィギュレーター、管理者、iscadmins、 AdminSecurityManager、デプロ

イヤーの7種類の管理ロールがあり、それぞれの管理ロールによってWASの管理機能に対する実行権限が定義されて

います。

モニターは、も権限のない管理ロールです。WASに関する構成やランタイム状態を見るだけの権限があり、構成変更

などの操作は一切することができません。

オペレーターには、モニターに与えられる権限がある上に、WASのサービス開始/停止などといったランタイム状態を変

更する権限があります。

コンフィギュレーターには、モニターに与えられる権限がある上に、WASに関する構成を変更する権限があります。

管理者は、も権限のある管理ロールです。コンフィギュレーター、オペレーター、モニターに与えられている権限がある上に、サーバー・パスワード、LTPAパスワード、鍵などといった重要なデータへアクセスする権限があります。

iscadmins、 AdminSecurityManager、デプロイヤーはWAS V6.1から追加された管理ロールです。

Iscadminsは、管理コンソール内のみユーザーとグループを管理する権限があります。

AdminSecurityManagerは、ロールは管理セキュリティーとアプリケーション管理をわけるために登場しました。fine-grained 管理セキュリティーが使用される場合、このロールを与えられたユーザーだけが許可グループを管理すること

ができます。このロールを与えられたユーザーだけが管理ロールにユーザーをマップできます。

デプロイヤーは、コンフィギュレーターとオペレーター両方の一部の権限をもった管理ロールです。このロールはアプリ

ケーションに対する構成とランタイム操作が可能です。他のリソース、たとえばノードやサーバーなどを操作する権限は

デプロイヤーにはありません。

56


56

統合リポジトリー

統合機能は、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 V6.1の新機能でユーザー情報をローカルのファイルに保存する機能です。この

ファイルは、WASの構成リポジトリー内に作成され、他のWAS構成情報と同じ扱いを受けます。管理コンソールから登録

された内容は、デプロイメント・マネージャー内の構成リポジトリー内に登録され、同期を実行すると各ノードに配布され

ます。

ファイルベース・リポジトリーの情報は、構成リポジトリー内の以下のファイルに登録されます。

<PROFILE_ROOT>/config/cells/<cell_name>/fileRegistry.xml

上記ファイルに登録される内容は、ユーザー情報とグループ情報になります。

ユーザー／グループ情報の管理は、管理コンソールやwsadminコマンドで行います。大量ユーザー登録や定期更新の

機能はないので、大量のユーザー管理を行うのにはあまり向いていません。

57


57

統合リポジトリー: アーキテクチャー概要

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レジストリー

・スタンドアロン・カスタム・レジストリー

しかし、これらのリポジトリーでは、統合リポジトリーが提供するユーザーやグループの管理、同時に複数のレジストリー

をサポートするといったWAS V6.1からの新機能は利用できません。

58


58

WAS上の各リソースのアクセス制御

J2EE 役割（ロール）ベースのアクセス制御

– Servlet, JSP, Enterprise Bean, EJBなどのリソースへのアクセスは役割（ロール）によってコン

トロールされる

– ロールと各リソースのメソッドの組合せ（制約）によりアクセス権を設定

– ロールと実際のユーザーID, グループIDをマップ（役割マッピング）

– 運用上変更が頻繁におきるユーザー管理、セキュリティー管理とプログラムを分離する。

Webリソース

一般ユーザー

プレミアユーザー

GET

Servlet,jsp,html

GETPOST

ロール

実際のユーザー

グループ

J2EE

web.xml

ユーザー認証を検討した後には、そのユーザーがどのリソースを触ることができるかというアクセス制御(認可）を考える

必要があります。

3章でもセキュリティ役割（ロール）マッピングについて記載いたしておりますが、WAS上のリソースへのアクセス制御は

J2EE Authorizationモデルに基づいて行われます。

ServletやJSP、静的コンテンツなどのWebリソースへのアクセス制御はというアプリケーションの中での概念に基づいて

制御されます。

アクセス権限は、それぞれのリソース(servletなど）に対し、どの役割に、どのようなアクセスを許す、という組合せで設定

されます。たとえば、AというServlet は一般ユーザーであればアクセス可能で、Bというservletはプレミアユーザーのみ

アクセス可能としたいとします。この時の設定のイメージは次のようになります。

servletA allusers GET, POST

servletB premium GET,POST

役割と実際のユーザーの関連付け（マッピング）は別に行います。

このように実際のユーザー環境とアプリケーションを分離することにより、ユーザー環境の変化にプログラムが影響を受

けることがないような構造となっています。これらの設定はアプリケーションをビルドする際にデプロイメント記述子に組

み込まれますが、インストール後に変更することも可能です。Webリソースの場合、セキュリティー制約という概念があり、

Web コンテンツの保護方法を決定します。制約は、Web リソース・コレクション、許可制約、およびユーザー・データ制約

で構成されます。

制約の詳細については、下記 Info Center をご参照ください。

「セキュリティー制約」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/csec_

secc.html

EJBの場合も基本的にWebモジュールの場合と同様です。

59


59

SSL暗号化の流れ

Client Server

クライアント証明書

サーバー証明書

暗号化仕様交渉

鍵生成の元データ交換共通鍵生成

暗号化データ通信開始

クライアント証明書検証情報送付

サーバー証明書送付サーバー認証

クライアント認証

FW

SSLとはSecure Sockets Layerの略で、Netscape Communications社により開発されたプロトコルです。もともとSSLは、

ソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではありません。しかし、

現状はWebにおける認証および通信の暗号化にも多く使用されています。SSLはTCP/IPの上で実現され、その上で

HTTPやLDAPなどのアプリケーションプロトコルが動いています。

クライアント＊にとサーバー間の認証はサーバー認証とクライアント認証があります。

＊クライアントとはユーザー（Webブラウザ）だけでなく、サーバーもなりえます。例えば、クライアント：Webサーバー・

サーバー：WASも考えられます。

サーバー認証

サーバーが信頼されたものであることを証明するために使用します。（ウェブサイトの運営主体である法人組織の実在

性を証明）

通常、外部 CA プロバイダーから証明書を購入します。

ウェブサイトと証明書のサーバ名（コモンネーム）が一致、証明書のステータスがValid（有効）となっていれば、サーバ証

明書によって該当ページが認証されているといえます。

クライアントは、ブラウザにインストールされているルート証明書で署名を確認し、サーバ認証を行います。（成りすまし

防止）

クライアント認証

Web サイトの閲覧者が自分のアイデンティティを証明するために使用します。クライアントは、クライアント証明書をサー

バへ送信します。

<クライアント証明書>

ユーザーが使用しているコンピュータ上のファイルに格納されている暗号化された情報。利用者名や利用者が所属する

組織など個人を証明する情報が格納されています。

証明書はさまざまな認証局から入手することができます。サーバ側が信頼していない認証局から発行された証明書を

持っていても、そのサーバにはアクセスできません。

60


60

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コンテナー)の鍵を作成

・公開証明書の交換

・プラグイン構成ファイル、WAS設定の変更

61


61

管理コンソールからikeyman機能を使用

ユーザーはWASの管理コンソールから証明書や鍵の管理が可能

– 鍵データベース、公開鍵と秘密鍵の作成、証明書要求の作成、自己署名証明書の作成など

従来のIBM 鍵管理ユーティリティ (ikeyman)も引き続き使用可

個人証明書と署名者証明書の管理はikeyman、管理コンソールのどちらで行なっても同等

証明書要求は生成したツールを使用して受信する必要がある

ikeyman 管理コンソール

同じ機能の提供

WAS V6.1から、管理ユーザーは従来のikeymanと同等の機能を管理コンソールから行うことが可能です。ただし、個人

証明書と署名者証明書の管理はikeyman、管理コンソールのどちらで行なっても可能ですが、証明書要求は生成した

ツールを使用して受信する必要があります。これは、証明書要求をikeymanで作成された場合はikeymanで受信する、と

いうことになります。

62


62

練習問題

10. 管理コンソールを使用して、WASの構成変更を行うために小限の管理役割を次の中から1つ

選択してください。

A) オペレーター

B) 管理者

C) コンフィギュレーター

D) モニター

11. WebSphereのVirtual Member Manager(VMM)が統合できるリポジトリーを次の中から1つ選

択してください。

A) ファイルベース、データベース、カスタム

B) ローカルOS、LDAP、データベース

C) ファイルベース、LDAP、ローカルOS

<memo>

63


63

5章ワークロード管理

<memo>

64


64

WAS ND環境でのノードの統合

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

– 管理コンソール

– addNodeコマンド

– wsadmin

作業の順序(管理コンソールの場合）

– デプロイメント・マネージャーの起動

– アプリケーション・サーバーの起動

– デプロイメント・マネージャー管理コンソール上でノードを統合する

• 管理対象ノード・接続はSOAP通信

– 追加されたノードの確認

– アプリケーション・サーバーの始動と稼動確認

デプロイメント・マネージャープロファイルとアプリケーション・サーバーした後、デプロイメント・マネージャーにアプリケー

ション・サーバーノードを統合します。

<作業の順序（管理コンソールの場合）>

1.デプロイメント・マネージャーの起動

2. アプリケーション・サーバーの起動

3. デプロイメント・マネージャー管理コンソール上でノードを統合する

「ホスト」にアプリケーション・サーバーの稼動しているホスト名、「JMXコネクター・ポート」に77で定義した「SOAPコネク

ター・ポート」の番号を入力します。

「アプリケーションを組み込む」をチェックして「OK」をクリックします。

4. 追加されたノードの確認

5. アプリケーション・サーバーの始動と稼動確認

アプリケーション・サーバーは停止していますので、始動します。server1の左のチェックボックスをチェックし、始動ボタ

ンを押します。

別のWebブラウザから http://<ホスト名>:xxxx/snoop へアクセスします。結果が正常に表示されれば、アプリケー

ション・サーバーの起動は成功です。

65


65

addNodeコマンド

コマンドベースのノード追加

– 実行前にデプロイメント・マネージャーが稼働していなければならない

– 実行方法： addNode <DMホスト名> <DMポート名>– addNode コマンドは、デフォルトでは、アプリケーションとバスはセルに引き継がない。

引き継がせたい場合は、”-includeapps”、”-includebuses”オプションを指定する。

c:¥WebSphere¥AppServer¥profiles¥app01-1¥bin>addNode dmhost 8889 ADMU0128I: app01-1 プロファイルを使用してツールを開始していますADMU0001I: GONTA:8879 で、ノード GONTANode01 とデプロイメント・マネージャーの統合を開始します。(中略）ADMU0300I: ノード GONTANode01 が正常に GONTACell01 セルに追加されました。(中略）ADMU0306I: 注:ADMU0304I: -includeapps が指定されなかったため、スタンドアロン・ノードでインストールされたアプリケーションが新しいセルにインストールされませんでした。ADMU0307I: 以下をすることもできます:ADMU0305I: wsadmin $AdminApp または管理コンソールを使ってアプリケーションを GONTACell01 セル上にインストールしてください。ADMU9990I: ADMU0003I: ノード GONTANode01 は正常に統合されました。

c:¥WebSphere¥AppServer¥profiles¥app01-1¥bin>addNode dmhost 8889 ADMU0128I: app01-1 プロファイルを使用してツールを開始していますADMU0001I: GONTA:8879 で、ノード GONTANode01 とデプロイメント・マネージャーの統合を開始します。(中略）ADMU0300I: ノード GONTANode01 が正常に GONTACell01 セルに追加されました。(中略）ADMU0306I: 注:ADMU0304I: -includeapps が指定されなかったため、スタンドアロン・ノードでインストールされたアプリケーションが新しいセルにインストールされませんでした。ADMU0307I: 以下をすることもできます:ADMU0305I: wsadmin $AdminApp または管理コンソールを使ってアプリケーションを GONTACell01 セル上にインストールしてください。ADMU9990I: ADMU0003I: ノード GONTANode01 は正常に統合されました。

※addNode実行結果例

addNodeコマンドは、 “<profile_root>/bin”ディレクトリーから実行する必要があります。セルに取り込む新規ノードのサイ

ズと場所によっては、このコマンドが完了するまでに数分かかることがあります。ノードの統合と共に、ノード・エージェン

トが定義され、ノード・エージェント・サーバーは、addNode コマンドの一部として自動的に開始されます。

# addNode <deploymgr host> <deployment port>

<deploymgr host> でDMのホスト名を指定します。<deployment port>でDMのJMXポート番号を指定します。これらの引

き数は必須です。このコマンドのデフォルトの Java Management Extensions (JMX) コネクターは、 Simple Object

Access Protocol (SOAP)です。オプションとして”-includeapps”を使用すると、ノードの統合時にアプリケーションをセル

に引き継ぐことができます。

# addNode <deploymgr host> -includeapps

また、同様にバスもセルに引き継ぐことができません。” –includebuses”オプションを使用すると、ノード統合時にバスを

セルに引き継ぐことができます。

# addNode <deploymgr host> -includebuses

※DMは、セル内で高のFix Packレベルになっている必要があります。例えば、addNodeコマンドを使用してWAS V6.1

のノードを DM V6.0.2のセルに追加することはできませんので注意してください。

addNodeコマンドのオプション機能の詳細については、下記 Info Center をご参照ください。

「addNode コマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_a

ddnode.html

66


66

クラスター / クラスター・メンバー

クラスター・メンバーと呼ばれるアプリケーション・サーバーのグループ

クラスター・メンバー上では同じJ2EEアプリ

ケーションを実行

クラスターを作成することにより、負荷分散・スケーラビリティ・フェイルオーバーが可能

１つのセル上では複数のクラスターを作成することが可能

同一マシンで複数のメンバーが可能（垂直クラスター）

複数マシンにまたがったメンバーが可能（水平クラスター）

異なるOSにおけるクラスターも可能（z/OS除く）

WAS V6.1とV6.0 ノードの複合クラスターも

可能

DeploymentManager

Cell

ApplicationServer

ApplicationServer

Node

ClusterMember

ClusterMember

NodeAgent

ClusterMember

ClusterMember Cluster

Member

ClusterMember

Node

ClusterMember

ClusterMember

NodeAgent

ApplicationServer

ApplicationServer

Cluster

WAS NDでサポートされるクラスターは、クラスター・メンバーと呼ばれるアプリケーション・サーバーのグループです。ク

ラスターを構成することで同じJ2EEアプリケーションが稼動するアプリケーション・サーバーを容易に構成することが可

能となります。

同じクラスターのメンバー間では、負荷分散・フェイルオーバーがサポートされますので、クライアントから見ると１つのア

プリケーションに対するパフォーマンス・可用性が向上します。また、クラスター・メンバーの追加構成により必要なときに

システムを容易に拡張することができます。

クラスターは１つのセル内に複数構成可能であり、用途によって様々なクラスターを構成することができます。同一マシ

ン内で複数のメンバーを作成し、プロセス障害に対応するための垂直クラスターや、複数マシンにまたがったメンバーを

作成することでパフォーマンス・可用性を高める水平クラスターというのが考えられ、垂直クラスター、水平クラスターを

組み合わせるなど自由に構成できます。

また、クラスターは異なるOSにまたがったクラスターや、V6.1とV6.0を組み合わせるということも可能となります。

67


67

クラスター設定

WEBコンテナー・EJBコンテナーWLMの際の割り振りの重み付け

クラスターメンバーへの固有ポートの割り当て

EJBコンテナーWLMの際のローカルノード優先設定

HTTPセッションのメモリー間複製の構成

新規にクラスターを作成し、そのクラスターにクラスター・メンバーとしてアプリケーション・サーバーを追加します。

クラスター設定では、EJBコンテナーへの負荷分散への際にEJBクライアントと同じノード上のEJBコンテナーへの負荷

分散を優先させるという設定を行えます。また、HAマネージャーによるトランザクションログのフェイルオーバーの設定も

クラスターメンバーでの引き継ぎとなりますので、クラスター設定において設定します。

クラスターの各メンバー設定では負荷分散の際の割り振りの重み付けを設定することができます。この数字が高いほど

よりリクエストが割振られるということになります。

クラスターの各メンバーには「ウェイト（重み）」を設定することができ、クライアント要求の数の割り振りを調整することが

できます。

クラスター・メンバー作成時には、他のサーバーとポートの競合が発生するのを回避できるように、「固有のHTTPポート

を生成する」というオプションが指定できます。

68


68

クラスターによるワークロード管理(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コンテナー・サービスを実行するア

プリケーション・サーバーをクラスター化することにより実現できます。

69


69

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ではV5、V6.0と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエスト

はセッションIDが作成されたサーバーにリクエストを続けることが可能です。

70


70

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コンテナーに割り振られた際のセッション情報再作成の発生が低くなります。

71


71

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ではV5と同様にTransactionAffinityにより、トランザクション中のリクエストは必ず前回と同じEJBコン

テナーへリクエストを割振られます。

72


72

HTTPセッション・パーシスタンス

セッション情報を別の場所へ避難させることでセッションを維持する

アプリケーション・サーバー自身が提供する機能

アプリケーション・サーバー障害時にもセッション維持可能

セッションオブジェクトｖ

セッション

DB

セッションオブジェクトｖ

セッション

セッション

メモリー間複製セッションDB

• 他のAppServerのメモリー上に

セッションオブジェクトのコピーを作成

• セッションオブジェクトをDBに保管(データベース・セッション・パーシスタンス）

HTTPセッション・パーシスタンスです。これはセッション情報を別の場所へと退避させることでアプリケーション・サー

バー障害時にもセッションの維持を行なう方法で、アプリケーション・サーバー自身が提供する機能です。WAS V6.1では

他のアプリケーション・サーバーのメモリー上にセッション情報を複製するメモリー間複製(Memory to Memory)と、セッ

ション情報をDBに保管する方法の2つがサポートされています。実績はDBの方が多くあります。（特に大規模な構成ほ

ど）

重要なのは、セッション・オブジェクトの大きさで、大きな情報を入れるとパフォーマンスに悪影響します。また書き込む

頻度も関係します。

アプリケーションではサイズの小さいセッション・オブジェクトを保存するようにすることが非常に重要です。

73


73

セッション・パーシスタンス構成手順概要

メモリー間複製構成

① メモリー間複製を有効化

• クラスター作成時に「HTTP セッションのメモ

リー間の複製の構成」を選択– 自動的にデータ複製サービス(DRS)がデフォルト

設定で構成される

• クラスター作成後、クラスター・メンバー毎の「セッション管理」の「分散環境設定」画面で、「メモリー間の複製」を選択

② メモリー間構成モードなど、必要に応じてパラメーターを変更

セッション・データベース構成

① セッション保管用のデータベースを作成

② データベースにアクセスするためのJDBC プロ

バイダーとデータ・ソースを構成

③ セッション管理の「分散環境設定」画面で、「データ・ベース」を選択

④ 詳細パラメータを必要に応じて変更

メモリー間の複製

データベース

[Webコンテナー]-[セッション管理]-[分散環境設定]

セッション・パーシスタンス構成手順の概要です。

メモリー間複製の構成では、データ複製サービス(DRS)が使用されます。（クラスター作成時に、「HTTPセッションのメモ

リー間の複製構成」を選択した場合は、自動的にデータ複製サービスが構成されます。）

セッション・データベースの構成では、DBの準備とDBアクセスの設定が必要となります。

74


74

（参考）セッション管理構成画面

分散環境設定セッション・パーシスタンスを設定

セッション・トラッキング・メカニズム• SSL IDトラッキング

Secure Sockets Layer (SSL) のセッション ID を使用してセッション管理を行う場合に指定

• Cookieを使用可能セッション管理にCookieを使用する場合に指定

• URL再書き込みを使用可能URL 再書き込み（URLの後ろにセッションIDを付加して送信する方法）を使用する場合に指定

メモリー内の大セッション・カウントセッションが未使用状態のものを無効化するまでのタイムアウト値（分）

セッション・タイムアウトメモリーに保持するセッションの大数を指定

セッション・アクセスのシリアライズ並行セッション・アクセスを禁止するかを指定• 大待機時間

セッションアクセス終了を待機する大時間（秒）

セッション管理の構成画面です。

○セッション・トラッキング・メカニズム

SSL ID、Cookie、URL再書き込みを指定できます。SSL IDを使用する場合は、CookieやURL再書き込みと併用すること

をお勧めしています。

○メモリー内の大セッション・カウント

メモリー内に保持できるセッションの大数を指定します。オーバーフローを許可している場合、大数を超えるとメモ

リー内に新たにセッションを格納する領域がとられます。この場合、無限にセッションが作成されます。

○セッション・タイムアウト

セッションが使用されなくなってから無効にするまでの時間を設定します。

○セッション・アクセスのシリアライズ

並行セッション・アクセスを禁止するかどうか指定します。

○分散環境設定

セッション・パーシスタンスの設定を行います。

75


75

DRS（データ複製サービス）

DRS : Data Replication Service– クラスター下の複数のアプリケーションサーバー間におけるデータの複製を提供するWAS内部

コンポーネント

– アプリケーションサーバー毎に１つ

WAS V6.1ではDRSを使用して以下の機能を提供

– HTTPセッション・メモリー間複製

– HTTPセッション情報を複数のアプリケーションサーバーに持つことで障害時のセッション処理に対する

フェイルオーバーが可能

– ステートフル・セッションビーン・ステートの複製

– ステートフル・セッションビーン情報を複数のアプリケーションサーバーに持つことで障害時のステートフル・セッションビーン処理に対するフェイルオーバーが可能

– 動的キャッシュの複製

– キャッシュデータを複数のアプリケーションサーバーに持つことでパフォーマンスの向上が見込める

DRS（Data Replication Service）は、クラスター配下のアプリケーションサーバー間におけるデータ複製を提供します。

DRS機能はアプリケーションサーバー毎に稼動し、お互い連携することにより、データ複製を可能にします。

V6.1では、DRSを使用して以下の機能を提供します。

•HTTPセッション・メモリー間複製

HTTPセッションオブジェクト生成を実施するWebコンテナー稼動のアプリケーションサーバーをクラスター化した際に、ア

プリケーションサーバー間でセッション情報のフェイルオーバーを実施します。HTTPセッションのフェイルオーバーはセッ

ション情報をデータベースに格納することでも実現できますが、DRSでは全てメモリー間での複製となります。

•ステートフル・セッションビーン複製

ステートフルセッション・ビーンを使用するEJBコンテナ稼動のアプリケーションサーバーをクラスター化した際に、アプリ

ケーションサーバー間でステートフル・セッション・ビーン情報のフェイルオーバーを実施します。

•動的キャッシュの複製

動的キャッシュを生成・保持するWebコンテナー稼動のアプリケーションサーバーをクラスター化した際に、アプリケー

ションサーバー間でキャッシュ情報の共有を実施します。１つのキャッシュを複数のサーバーに保持することで、パ

フォーマンスの向上が見込めます。

76


76

複製ドメイン

DRSを使用するアプリケーションサーバーの集合

同一ドメイン内でDRS同士のデータのやり取りは発生

１つのアプリケーションサーバーがいくつのデータ・レプリカを別のアプリケーションサーバーに作成するかを指定

– 単一レプリカ（デフォルト）

• デフォルト。ドメイン内に１つのDRSに対するレプリカは１つ

– 全グループ・レプリカ

• ドメイン内の全てのサーバーが全てのレプリカを保持

– 特定のレプリカ数

• ドメイン内に指定された数のレプリカを保持

AppServer 1AppServer 1



DRS

DRS

DRS

AppServer 4AppServer 4DRS

複製ドメインとは、DRSを使用するアプリケーションサーバーの集合です。この複製ドメイン内のDRS同士でデータの複

製は実行されます。複製ドメイン設定では、１つのアプリケーションサーバーがいくつのデータ・レプリカを別のアプリ

ケーションサーバーに作成するかを指定します。

次の３つの指定が可能です。

・単一レプリカ（デフォルト）

デフォルトで使用されます。１つのデータに対して複製ドメイン内に１つのデータ・レプリカを保持します。

・全グループ・レプリカ

複製ドメイン内の全てのサーバーが1つのデータに対するレプリカを保持します。

・特定のレプリカ数

１つのデータに対していくつレプリカを持つかというのを数で指定可能です。

77


77

HTTPセッション・メモリー間複製

HTTPセッション情報を複数のアプリケーション・サーバーに持つことで障害時のセッション処理に

対するフェイルオーバーが可能

データ複製ドメイン設定でのレプリカの数と、アプリケーション・サーバー毎に設定するメモリー間複製設定で動作環境が決まる

ドメイン指定はアプリケーション・サーバー単位

アプリケーション・サーバー毎のメモリー間複製モード設定

– クライアントのみ – ローカルで作成・更新されたセッション情報をサーバーに送信

– サーバーのみ - 他のアプリケーション・サーバーのセッション情報を受信

– クライアントとサーバー両方 – クライアント・サーバー両方の動きをする

基本的に次の２つの動作環境がある

– Peer to Peer– 各々のアプリケーション・サーバーが自分および他のアプリケーション・サーバーのセッション情報を保持する

– アプリケーション・サーバー障害時、ホット・フェイルオーバーによりプラグインはレプリカを持っているサーバーに割り振る

– Client/Server– クライアントのアプリケーション・サーバーは自分のセッション情報を保持し、他クライアントのアプリケーション・サーバー

のセッション情報はサーバーのアプリケーション・サーバーに保持される

– アプリケーション・サーバー障害時、障害サーバーのセッション・リクエストを受けたアプリケーション・サーバーは、サーバー指定されたアプリケーション・サーバーから該当セッション情報を取得する

DRSを使用して、HTTPセッション情報を複数のアプリケーション・サーバーに持つことで、障害時のセッション処理に対するフェイルオーバーが可能となります。この機能を使用するために、アプリケーション・サーバーごとにメモリー間複製設定を行う必要があります。

メモリー間複製設定では、そのアプリケーション・サーバーがデータレプリカを送信するのみか、受信するのみか、またその両方かというのを指定します。また、メモリー間複製設定ではどの複製ドメインを使用するかというのを指定します。

ドメインに指定しているレプリカの数と、各アプリケーション複製モードによってDRSの動作環境が決まります。動作環境には大きく分けて次の２つがあります。

・ Peer to Peer各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報を保持します。V6ではアプリケーション・サーバーの障害が発生すると、プラグインはレプリカのあるサーバーにリクエストを割り振る、ホット・フェイルオーバーが提供されます。

・ Client/Serverデータレプリカの送信のみに指定されたクライアントと、受信のみに指定されたサーバーによってこの構成はとられます。

アプリケーション・サーバー障害時に、セッションリクエストを受け取ったクライアントは、サーバーからセッション情報を取得しサービスを行います。

78


78

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 6 ND では、IBM HTTP Server 6をWebSphere セルに含めて管理可能です。

IBM HTTP Server 6の起動や停止、設定をWebSphere 管理コンソールから行うことができます。

また、アプリケーション・サーバーとIBM HTTP Server が別のマシンにインストールされている場合、WAS V5.x では手動で行わなくてはならなかったプラグイン構成ファイルのコピーも、自動で行わせることができるようになりました。

◆IBM HTTP Server とWebSphere Application Serverを同じノード（マシン）に導入した場合◆→Webサーバーを管理対象ノードに定義

WASV6からはWebサーバーをデプロイメント・マネージャーの管理対象サーバーに含めることができるようになりました。

これにより、 WebサーバーはNode Agent経由で管理され、管理コンソールから以下の操作が可能になります。

①Web サーバーの状況の検査

②プラグイン構成の生成・伝搬

WebサーバーがIBM HTTP Server(IHS)の場合は、以下の操作も可能です。

③Webサーバーの開始・停止

④ログファイル（error.log, access.log)の表示

⑤構成ファイル(httpd.conf)の表示・編集

79


79

リモートの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サーバーはHIS管理プロセス経由で管理され、以下の操作も可能

③プラグインの伝搬

④Webサーバーの開始・停止

⑤ログファイルの表示

⑥構成ファイル(httpd.conf)の表示・編集※マシンBにNode Agentを導入し、前ケースと同様にNode Agent経由の管理を行うこともできます。ただしその場合は、マシンBにもWebSphere Application Serverのラインセンスが必要となります

リモートのWebサーバーマシンを非管理ノードとしてデプロイメント・マネージャー経由で管理することも可能です。これに

より管理コンソールより以下のことが実施可能です。


②プラグイン構成の生成

WebサーバーがIBM HTTP Server(IHS)の場合は、WebサーバーはIHS管理プロセス経由で管理され、以下の操作も可

能dです。

③プラグインの伝搬

④Webサーバーの開始・停止

⑤ログファイル（error.log, access.log)の表示

80


80

練習問題

12. データ複製サービス(DRS)の複製ドメインで、使用できるレプリカ設定を次の中から1つ選択して

ください。

A) 全グループ・レプリカ

B) クライアント・レプリカ

C) サーバー・レプリカ

13. addNodeコマンドでアプリケーションを組み込むオプションを次の中から1つ選択してください。

A) -includesamples

B) -includefeatures

C) -includeapps

14. IHSではないWebサーバーをセルに含めて管理したいと考えています。Webサーバーがリモート

サーバー上にあり非管理対象ノードで定義した場合、管理できない項目を次の中から選択してください。

A) Web サーバーの状況の検査

B) プラグイン構成の生成

C) プラグインの伝搬

<memo>

81


81

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

<memo>

82


82

クラス・ローダーの設定

クラス・ローダーはクラスを検索し、ロードするための仕組み

– 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)…クラス・ローダーが、クラスのロードをその親に委任する前に、クラスをそのローカル・クラスパスからロードしようとします。

クラス･ローダーは、J2EE対応のJVMが共通して提供するJVMクラス・ローダーとWASが提供するクラス･ローダーの2種類に大別されます。V6.0.xではWebSphere拡張クラス・ローダーがロードするランタイムのクラスはアプリケーションから直接参照出来る構造になっていましたが、V6.1ではOSGiフレームワークを採用した事でWASが内部的に使用する実行クラスの不可視性が高まり、アプリケーションから直接参照出来ない構造になりました。

クラス・ローダーの詳細については、下記 Info Center をご参照ください。「クラス・ローダー」http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/crun_classload.html

83


83

システムのバックアップ方法

バックアップの取得が必要と考えられるタイミング

– インストール直後

– 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コマンドのオプション機能の詳細については、下記 Info Center をご参照ください。

「backupConfig コマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_b

ackupconfig.html

backupConfigコマンドの使用における注意点として、以下のような点があります。

・構成リポジトリー以外にもバックアップが必要なファイルがあります。

・ DMとそれぞれのノードで個々にバックアップが必要です。backupConfigコマンドで取得したバックアップ情報はホスト

名/IPアドレスが異なるマシンではリストアできませんので、複数マシン構成の場合、それぞれのノードでバックアップを

行う必要があります。また、DMとノード・エージェントが1台のマシンに同居している場合でも、DMの構成リポジトリーの

バックアップとノードの構成リポジトリーのバックアップをそれぞれ行う必要があります。

・バックアップ取得時には、自動的に各ノードのDM、ノード・エージェント、アプリケーション・サーバーのプロセスが停止

されます。backupConfigコマンドの-nostopオプションを使用して、プロセスを停止せずにバックアップを取得することもで

きますが、バックアップ取得時にマスター構成リポジトリーが変更されると不整合が発生し、リストアできませんので、注

意が必要です。

・バックアップ取得時に停止されたプロセスは自動的には起動しませんので、バックアップ終了後、手動で起動する必

要があります。

・セキュリティが有効な場合は、-user/-passwordオプションを使って認証を行います。

backupConfigコマンドを使用する以外にも、WASが導入されているディレクトリーをZIPなどで全てバックアップする方法

もあります。

84


84

リストア方法

restoreConfigコマンドを使用

– backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元

– 使用方法： restoreConfig <backup_file> [options]• 例： <profile_root>¥bin¥restoreConfig myBackup.zip

– 注意点

• 構成リポジトリー以外のバックアップファイルの復元も必要

• 同一ホスト名のマシンに対してのみリストア可能

BackupFile(.zip)

hostA

backupConfig

restoreConfigホスト名の異なるマシンにはリストア不可能！

hostB

WASの構成情報のリストアを行うには、restoreConfigコマンドを使用します。このコマンドを実行することにより、

backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元します。リストア時には、リストア対象

ファイルを必ず指定してください。

restoreConfigコマンドのオプション機能の詳細については、下記 Info Center をご参照ください。

「 restoreConfigコマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_r

estoreconfig.html

restoreConfigコマンドの使用における注意点として、以下のような点があります。

・構成リポジトリー以外のバックアップファイルの復元も必要です。

・リストアは同一ホスト名のマシンにおいてのみ可能です。

既存の構成ディレクトリが存在している場合、既存のディレクトリの名前が変更されてから復元が開始されます。実行例

では既存の<profile_root>¥configディレクトリが<profile_root>¥config.old_1に変更されてから復元が始まっています。

85


85

キューイング・ネットワーク

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連

するコンポーネントをキューイング･ネットワークと呼ぶ

キューイング･ネットワークに関連するパラメーターを調整し、大スループットを達成することがパフォーマンスチューニングの第一歩

DB

ブラウザー

Webコンテナスレッドプールサイズ

ORBスレッドプール･サイズ

Webサーバー MaxClients / ThreadPerChild

データソース大接続数

WebコンテナASWebサーバー

EJBコンテナAS

それぞれの入り口で待ち処理が発生するように絞り込むように調整

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連するコン

ポーネントをキューイング･ネットワークと呼びます。キューイング･ネットワークに関連するパラメーターを調整し、大ス

ループットを達成することがパフォーマンスチューニングの第一歩になります。

キューイング･ネットワークでは原則クライアントに近い側の同時接続パラメーターを大きく、リソース･マネージャーに近

い側を小さく設定します。これによりシステムが過負荷にならない、かつ各コンポーネントは適量の待ち処理を継続処理

できるようにしてスループットを大化することが出来ます。

86


86

モニタリング・ツール : 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としてモニターするプロセス

を選択します。この際にチェックを付けることで複数のプロセスの情報を取得開始することも可能ですが表示は一プロセ

ス単位になります。管理コンソールからログオフするとモニターは停止します。

87


87

JVMの役割-メモリ管理

JavaではJVMがメモリ管理を実施

– 不要になったオブジェクトをメモリ領域から開放

– アプリケーション開発者のメモリ管理作業を軽減、ソフトウェア品質の向上

• 参照されないオブジェクトが残ってしまうことによるメモリリークの回避

• まだ参照されているオブジェクトを消去してしまうランタイムエラーの回避

– GC処理中は全てのアプリケーション・スレッドは停止

– GCはアプリケーションのパフォーマンスに影響

• JVMが適切にGCを実施するよう調整が重要

ガーベージ・コレクション（GC）

重要

Merit

メモリー空間

必要なｵﾌﾞｼﾞｪｸﾄ必要な

ｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

JVMの重要な役割として、メモリ管理があります。Javaでは、一般にガーベッジ・コレクション (GC) と呼ばれる、不要に

なったオブジェクトをメモリ領域から開放する作業をJVMが行っています。

これにより、アプリケーション開発者は煩雑なメモリ管理のコードをプログラム中に記述する必要がなくなります。また、

参照されないオブジェクトがメモリ内に残ってしまうことによるメモリリークや、逆にまだ参照されているオブジェクトを消

去してしまうことにより発生するランタイムエラーなどのバグを回避することができますので、ソフトウェア品質の向上す

るという利点があります。

GCはアプリケーションのパフォーマンスに影響を与えますので、JVMが適切にGCを処理を行うように設定することが重

要です。

88


88

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に設定することが推奨されます。

89


89

プラグインの管理

プラグイン構成ファイルの更新/生成

– Webサーバー・プラグインは、構成変更が発生した場合、更新が必要

– 更新/生成方法

• 管理コンソール– Webサーバーの「プラグインの生成」ボタンをクリック

• wsadmin• コマンド行ツール(GenPluginCfg.sh)

– DMノードで実行 →セル内の全ノード分の情報を含むプラグイン構成ファイルが生成

– ASノードで実行 →そのノードのみの情報を含むプラグイン構成ファイルが生成

管理コンソールを使用したプラグイン構成ファイルのプロパティー値設定

– [サーバー]-[Webサーバー]-[web_server_name]-[プラグイン・プロパティー]• 構成新表示間隔、プラグイン構成ファイルの自動生成/自動伝搬、プラグイン鍵ストア・ファイル名、プラ

グイン・ロギング、ロード・バランシング、再試行間隔、などを設定可能

– [サーバー]-[アプリケーション・サーバー]-[application_server_name]-[Webサーバーのプラグイン・プロパティー]• 接続タイムアウト、読み取り/書き込みタイムアウト、接続大数の使用、などを設定可能

次のような場合は、プラグイン構成ファイルの更新と伝搬が必要となります。

・新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合

・サーブレットに対するURLマッピングの定義など、URIに変更があった場合

・新しいクラスターが追加され、ルーティング方法が変更になった場合

・ポート番号が変更になった場合

・仮想ホストの追加や修正があった場合、など。

プラグイン構成ファイルの更新/生成方法は管理コンソールとコマンド（GenPluginCfgコマンド）の2つの方法があります。

GenPluginCfgコマンドによる更新/生成は、実行するノードによって出力が異なるので注意ください。

プラグイン構成ファイルの伝搬方法などについては、「 5章ワークロード管理」も参照してください。

正しくリクエストが割り振られていない場合のチェック項目として、いくつか挙げます。

・上記の修正が入った場合に、正しくプラグイン構成ファイルが更新、伝搬されているかどうかを確認します。

・ Webサーバーの構成ファイルhttpd.confの中に記述されているプラグイン構成ファイルplugin-cfg.xmlの位置は正しく設

定されているかどうかを確認します。

・ plugin-cfg.xmlファイルを手で書き換えている場合、デプロイメント・マネージャーの構成ファイル同期サービスにより、

Webサーバー・プラグイン構成の更新で生成された状態に戻ってしまうことがあります。

・製品の障害などを修正するためのFixなどもありますので、新版があたっているかどうかも確認します。

またプラグインに関連するパラメーターは管理コンソールから設定可能です。プラグイン側の設定とWAS側の設定の2つ

の設定箇所があります。

90


90

パフォーマンス・チューニングのヒント

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にし、出力ログをモニタリングしながら決定して

いくことをお勧めします。

ヒープを大きく割り当てることによって、スループット向上の効果も考えられますが、その一方、ガーベッジ・コレクション

による停止時間が長くなることにより大レスポンスタイムが増加する可能性もあります。

91


91

練習問題

15. ユーティリティJARとWARが同じクラス・ローダーで読み込まれるようにするために設定する項目を次の中から1つ選択してください。

A) アプリケーション・クラス・ローダー・ポリシー設定（単一/複数）

B) WAR クラス・ローダー・ポリシー設定（アプリケーション/モジュール）

C) クラス・ローダー・モード設定（親が初/親が後）

16. 管理コンソールから設定できないWebサーバー・プラグイン設定項目を次の中から1つ選択して

ください。

A) ロード・バランシング・オプション、再試行間隔

B) 小接続数、大接続数

C) 接続タイムアウト、読み取り/書き込みタイムアウト

17. ガーベッジ・コレクション（GC）の状況をモニタリングしたところ、GC処理時間が他システムに比

べ長いことに気づきました。システム管理者が検討すべき項目として不適切と考えられるものを次の中から1つ選択してください。

A) ヒープサイズを小さくしてみる

B) GC発生間隔も調査する

C) ガーベッジ・コレクションのモニタリング機能をOFFにする

<memo>

92


92

7章問題判別

<memo>

93


93

ログの種類 (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とはエラー情報を発生時に自動記録する機能。サポートセンター、開発部門が障害対応時に見るログ。

循環ログ

構成不可

AST

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ログに詳細情報を追加したログです。

94


94

ログのロケーション (1) WAS関連

プロファイル単位の/logsディレクトリ

WAS関連

/logs以下に/ffdcディレクトリ

IBM保守ログ

JVMログ

プロセス・ログ

/logs以下にサーバー単位のディレクトリ

HTTPトランスポートログ

FFDCログ

前項で解説したログの実際のロケーションを表したチャートです。

95


95

ログの種類 (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ファイルでプラグイン・ログファイルの位置が指定され

ています。

96


96

ログのロケーション (2)IHS、プラグイン関連

Pluginの/logsディレクトリにWebサーバー単位のディレクトリ

IHSの/logsディレクトリ

httpアクセス・ログ

httpエラー・ログ

プラグイン・ログ

IHS導入ディレクトリ

プラグイン導入ディレクトリ

前項で解説したログの実際のロケーションを表したチャートです。

97


97

ログの管理

ログ管理機能

– 管理コンソールの「トラブルシューティング」→「ログおよびトレース」からサーバーを指定して、各ログの循環設定、ファイル大サイズなどを設定可能

– 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停止のタイミングでログを退避させる運用とします。

98


98

トレース(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)」になっています。

トレース設定の詳細については、下記 Info Center をご参照ください。

「ログ・レベル設定」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/utrb_l

oglevel.html

99


99

ログ / トレースのフォーマット

基本フォーマット

イベントタイプ

日付，時刻，タイムゾーンメッセージを出力したスレッドの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文字の英字

で表記され、起こったイベントのタイプを表します。メッセージ・タイプは大文字で表記され、トレース・タイプは小文字で表

記されます。

100


100

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）」の両方のメッセージを表示するフィルターを作成）

101


101

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 製品インストールの下のプロパティー・ディレクト

リーにあります。 3 つのプロパティー・ファイルがありますが、ffdcRun.properties ファイルのみを変更します。

ExceptionFileMaximumAge プロパティーは、削除される前に、消去の間の日数を構成するために使用できるプロパ

ティーです。（その他、ffdcStart.propertiesファイルとffdcStop.propertiesファイルが存在します。）

FFDC フィーチャーは、WebSphere Application Server 製品のパフォーマンスには影響を与えません。

102


102

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>set jvm [$AdminControl completeObjectName type=JVM,process=Server1,*]WebSphere:name=JVM,process=Server1,platform=dynamicproxy,node=vinusNode01,j2eeType=JVM,J2EEServer=Server1,version=6.0.2.0,type=JVM,mbeanIdentifier=JVM,cell=vinusCell01

wsadmin>$AdminControl invoke $jvm dumpThreads

プロセスが異常終了した場合、javacoreが生成されます。javacoreには、JVMのnative stack、java stack、環境情報など

がテキストファイルで出力されます。synchronizedなどの排他制御で使用されるJavaのモニター情報も取得できますの

で、デッドロックの調査に有効です。

javacoreは、プロセスが異常終了したときに自動生成されるだけではなく、外部からの指示による強制取得もできます。

WebSphereのjavaプロセスの場合は、wsadminで取得することができます。Unixでは、”kill –QUIT <PID>”コマンドまた

は”kill -3 <PID>”コマンドでも取得することができます。

通常、クラッシュの場合はIBMサポート部門にCoreを送付して解析してもらうことになりますが、javacore.txtを参照するこ

とによって、現場担当者がその問題判別をすることもできる場合があります。

103


103

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用ヒープ・ダンプ診断ツールを使用し

て解析も可能です。

104


104

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に

問い合わせ、サーバー・ルートが開始点です。

105


105

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等）のサポートも行える

ようにカスタマイズすることが可能です。他製品のプラグインのインストールにより、「検索」「製品情報」「ツール」コン

ポーネントに新しい情報が追加されます。

106


106

練習問題

18. IBM保守ログ（activity.log）の内容を確認するためのツールとして正しくないものを次の中から1つ選択してください。

A) Application Servet Toolkit(AST)

B) showlog

C) Tivoli Performance Viewer

19. 次のログ・ファイルの中で、管理コンソールからヒストリー・ログ・ファイル数を指定し、ログ切り替え（世代管理）ができるものを次の中から1つ選択してください。

A) プロセス・ログ

B) JVMログ

C) IBM保守ログ

20. トレースログの出力レベルを低いものから高い順番にならべたものを次の中から1つ選択してく

ださい。

A) 「警告(warning)」→ 「重大(severe)」 →「情報(info)」

B) 「情報(info)」→「構成(config)」→「詳細-低(detail)」

C) 「構成(config)」→ 「情報(info)」 →「詳細-中(fine)」

<memo>

107


107

練習問題回答

① C② A③ B④ A⑤ A⑥ C⑦ B⑧ A⑨ C⑩ C

お疲れ様でした。WebSphere 認定試験がんばってください。

⑪ A⑫ A⑬ C⑭ C⑮ B⑯ B⑰ C⑱ C⑲ B⑳ B

<memo>

WebSphere Application Server Network Deployment...

Documents

Transcript of WebSphere Application Server Network Deployment...