websphere application server network deployment...

1

®

IBM Software Group

© 2005 IBM Corporation

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

WebSphere Application Server V6.0 Network Deployment, Core Administration

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

試験対策試験対策試験対策試験対策テキストテキストテキストテキスト

2005年10月第1.1版発行

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

©Copyright IBM Japan, Ltd. 2005

All Rights Reserved. Printed in Japan.

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

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

2

IBM Software Group | WebSphere software

2

目次

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

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

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

3. アプリケーション・アセンブリーとデプロイメントおよびサーバー・リソース

の構成 ………………………………………………… 34

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

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

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

7. 問題判別 ………………………………………………… 75

8. システム管理 ………………………………………………… 87

9. 練習問題回答 ………………………………………………… 97

<memo>

3


3

認定試験概要

<memo>

4


4

試験概要

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

【試験名称】WebSphere Application Server V6.0,

Network Deployment, Core Administration

【試験時間】90分

【試験料金】18,900円

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

【出題数】約54問

【合格ライン】64 - 66%以上の正解で合格

WebSphere Application Server Network Deployment V6.0 認定システムアドミニストレーターはワールドワイドで共通の、システム管理者向けの資格となります。WebSphere Application Serverの管理について、幅広く出題されます。（詳細は次ページ参照）

WebSphereの認定資格としては、その他にも、WebSphere Application Server アドバイザー試験があります。こちらはエントリー向けの試験で、日本IBM国内認定の資格となります。

5


5

出題範囲

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

・WebSphereリソースの保護

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

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

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

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

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

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

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

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

3.アプリケーション・アセンブリーとデプロイメントおよびサーバー・リソースの構成(11％)

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

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

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

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

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

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

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

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

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

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

主な内容章タイトル

<memo>

6


6

出題範囲（続き）

・セルの管理を実行できる(デプロイメント・マネージャー / ノードの統合 / クラスター作成）

・管理コンソールとwsadminについて理解している

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

8．システム管理(7％）

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

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

・コンソール・メッセージのフィルターと調査

・FFDCツールを利用できる

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

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

7．問題判別(15％)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主な内容章タイトル

<memo>

7


7

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

<memo>

8


8

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

負荷分散サーバー

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

DBサーバーFWFW

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

Webサーバー

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

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

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

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

DMZ（非武装地帯）

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

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

インターネットやイントラネットを経由してのクライアントからのリクエストをまず受け付けるのが負荷分散サーバーです。負荷分散サーバーではWebサーバーへの負荷分散及び障害検知を行います。Webサーバーが受け付けたリクエストに動的ページの要求があった場合、その処理をアプリケーション・サーバーに依頼します。アプリケーション・サーバーは処理の内容に応じてデータベースのデータを更新・検索などの処理を行い、動的ページの生成を行い、結果をクライアントに返します。

また、FWとはファイアウォールを指します。ファイアウォールを導入することにより、外部の攻撃から社内ネットワークを守り、セキュリティを大幅に高めることが可能となります。インターネットの場合には必須となるコンポーネントになります。

この図では、負荷分散サーバー、Webサーバー、アプリケーション・サーバー、データベース・サーバーが全て複数サーバーで描かれています。全てのサーバーを複数台用意することにより、可用性、耐障害性を高め負荷を分散させることが可能となりますが、これは一例なので、FWの配置箇所やWebサーバーの配置箇所、サーバーの台数などは要件によって異なります。

9


9

WASV6.0のエディション

WebSphere Application Server-Express

ISVソリューション

の基盤

WebSphere Application Server(Base)

WebSphere Application Server Network Deployment (ND)

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

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

管理機能を提供

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

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

・WebSphere Application Server V6 - Express

・WebSphere Application Server V6 (以降Base)

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

Express、Base はスタンドアロンで稼動します。NDは複数サーバーによるクラスタ機能をサポートするパッケージで、負荷分散、可用性のための様々な機能を提供します。NDにはロードバランサーおよびキャッシングプロキシー機能を提供するEdge Componentsが同梱されています。

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

10


10

各パッケージの比較

○○○SI Bus機能

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

○××HA機能

○××クラスター構成

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

○○×64bit対応予定

○○○J2EE1.4サポート

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

WAS NDWAS (Base)WAS Express内容

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

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

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

WASV5ではEnterprise Editionにしか含まれなかったプログラミング・モデル拡張（非同期BeanやスタートアップBean,スケジューラー・サービスなど）はExpressからサポートされるようになりました。

11


11

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

J2EE1.4完全準拠のアプリケーション

一つのJavaプロセス

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

HTTPトランスポート

– Embedded HTTP Serverとも呼ばれる

– アプリケーション・サーバーごとに存在

Webコンテナー

– サーブレット,JSPなどのWebアプリケーションの実行環境

EJBコンテナー

– EJBの実行環境

ネーミングサービス

– 名前をもとにオブジェクトを検索するためのサービス

JMSプロバイダー

– JMSインターフェイスを備えた

メッセージングシステムをJ2EE上での実装

Webサーバー上の構成要素

Webサーバー

HTTPリクエストを受け付ける

Webサーバー・プラグイン

Webサーバーのプロセス内で稼働し、アプリケーション・サーバーへの要求をフォワード

WASの基本構成要素

クライアント

Application Server

Webサーバー

Webコンテナー

Webサーバー

プラグイン

HTTPトラン

スポート


EJBコンテナー


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

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

○HTTPトランスポート

Webサーバープラグインから送られてくるHTTP通信の受け口です。問題切り分けのために直接アクセスすることもできます。

○Webコンテナー

サーブレットやJSPの実行環境を提供します。サーブレット・インスタンスの作成、サーブレットのロードとアンロード、Requestオブジェクト・インスタンスとResponseオブジェクト・インスタンスの作成と管理、ならびにサーブレットを効率的に管理するためのタスクを実行します。

○EJBコンテナー

EJBの実行環境を提供します。EJBコンポーネントのトランザクション管理を提供します。EJBコンテナが提供する機能を使用することにより、ユーザープログラムにおけるシステム関連のコードの開発量を削減し、シンプルなコンポーネントとしてのBeanが作成できます。

○ネーミング・サービス

オブジェクト（データソース、EJBホーム・インターフェースなど）と名前とを関連づけ、その名前をキーとしてオブジェクトを検索するためのサービスです。

○JMSプロバイダー

JMSとはJava Message Serviceの略で、J2EE標準のメッセージング・インターフェースです。JMSプロバイダーはJ2EEサーバー上でJMSの実行環境を提供します。

○Webサーバー

HTTPのリクエストを受け付けます。

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

受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへリクエストを転送します。HTTPプラグインとも呼ばれます

12


12

アプリケーション

サーバーD

WAS Network Deploymentの管理トポロジー

ノードノードノードノード BBBB ノードノードノードノード CCCC

ノード・エージェント

ノードノードノードノード AAAA マスターマスターマスターマスター

セル・構成情報

ノードB・構成情報

サーバーA・構成情報

ローカルローカルローカルローカルローカルローカルローカルローカル

EARファイルアプリケー

ションサーバーC

アプリケーション

サーバーB

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

サーバーA



セルセルセルセル


サーバーB・構成情報

ノードC・構成情報

サーバーC・構成情報

サーバーD・構成情報

サーバーA・構成情報

サーバーB・構成情報

サーバーC・構成情報

サーバーD・構成情報

ノードB・構成情報

ノードC・構成情報

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

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

WAS NDの管理単位をセルと呼んでいます。セル内には一つのデプロイメント・マネージャーが存在し、管理下全ての構成情報のマスターを管理します。各マシンごとにノード・エージェントとよばれる管理エージェントが存在し、ローカルにも構成情報を保管します。

構成情報のなかにはセル全体の情報、ノードごとの情報、サーバーごとの情報が含まれます。EARファイルとはJ2EEアプリケーションファイルです。これもノード単位の管理と、セル全体ではデプロイメント・マネージャーが管理します。

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

NDでサーバーを起動するには、デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーの3つを起動する必要があります。

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

13


13

管理トポロジー用語解説

セル

ノードの集まりで論理的な管理の単位

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

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

セル内のノードを一括管理

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

ノード

通常は物理的な一つのマシンに対応

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

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


一つの管理ノードに一つ存在

管理用のエージェント

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


Web／EJBコンテナー、ネーミング・サービス、リソース管理、JMSプロバイダーなどが含まれる

・セル

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

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

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

・ノード

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

・ノード・エージェント

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

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

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

14


14

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

3段階でのWLMを提供

WebSphere Application Serverクラスター構成によるWLMEdge 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

高可用性のためのHigh Availability機能

ミッションクリティカルなアプリケーションの連続した稼動を可能にするHA機能を標準搭載特長

HACMPなどOSのHA機能と異なり、サーバー・ダウン時にアプリケーション・サーバー・レベルでのトランザクションのリカバリーが可能

仕組みHAマネージャーが実装され、利用可能なサーバー上でフェィルオーバーなどの主要な

サービスを実行NAS(ネットワーク接続記憶装置)のフォールト・トレラント・ストレージ技術の活用

サーバー3

HAマネージャー

サーバー2


サーバー1


NAS

HAマネージャーは

どこで何が実行されているかをコーディネートしフェィルオーバーを処理

サーバーJVM

サーバーのログを格納。全てのサーバーから全てのログを見ることが可能。

V6 New

WAS V6では、High Availability機能が標準搭載されました。HACMPなどのHA機能ではなく、WASに組み込まれた機能を使用しますので、一部のサーバーがダウンした時に、アプリケーションのレベルで、高速な引継ぎが可能となります。各アプリケーション・サーバーごとに、HAマネージャーが実装され、どのサーバーでどのようなサービスが実行されているかを監視し、問題発生時には、フェイルオーバーの処理を行います。サーバーのログは、NAS(ネットワーク接続記憶装置)に置かれ、サーバー間で共有されます。

16


16

High Availability機能～詳細～

引継引継引継引継ぎのぎのぎのぎの対象対象対象対象となるとなるとなるとなるサービスサービスサービスサービス

トランザクショントランザクショントランザクショントランザクション・・・・マネージャーマネージャーマネージャーマネージャー

NAS経由のトランザクション・ログを別のWASが引き継いでトランザクションを完結

障害機上のWASの再立ち上げは不要

DBロック早期解放／データ整合性保証

クラスタークラスタークラスタークラスター構成構成構成構成においてにおいてにおいてにおいて重要度重要度重要度重要度のののの高高高高いいいいWAS機能機能機能機能

メッセージング・エンジン

–JMS機能を提供

WLM制御機能

–EJB負荷分散制御機能

ハードウェアなどの障害を検出秒単位でWebベースの

トランザクションをオートノミック（自律的）に復旧

ハードウェアなどの障害を検出秒単位でWebベースの

トランザクションをオートノミック（自律的）に復旧

具体的に、引継ぎの対象となるサービスとしては、トランザクション・マネージャーと、メッセージング・エンジン、WLM機能があります。

まず、トランザクション・ログをNASに置くことにより、障害発生時はこれを別のWASが引き継いでトランザクションを実行します。従来は、障害が発生したWASの再起動をして、DBのロックを開放する必要がありましたが、WAS V6ではこれらの対応は必要ありません。データの整合性が保証されます。

次に、WebSphereのクラスター構成を支える重要度の高い機能も、HA機能により復旧されます。

EJBの負荷分散制御を行うWLM (Work Load Management)機能もフェイル・オーバーの対象です。

17


17

メッセージング（JMS)

WASV5.ｘWASV5.ｘ

EventBroker

MQ

JMS(MA88)

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

CとJavaコード

WAS V6統合された

メッセージング

WAS V6統合された

メッセージング

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

V6 New

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

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

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

アプリケーション・サーバーＪＶＭの一部として稼働する。->それぞれのアプリケーション・サーバーが

メッセージングエンジンを持つ。

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

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

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

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

WAS V5では組み込みメッセージング（Embedded Messaging)が同梱されていましたが、V6ではアプリケーション・サーバーの一部としてインストールされます。そのため別途組み込みメッセージングの機能をインストールする必要はなくなりました。さらに組み込みメッセージングはMQのサブセットとしてMQアプリケーションに依存するコード体系でしたが、その依存性もなくなりました。

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

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

尚サービス統合バス（SIBus）が提供するメッセージング・エンジンはJMS1.1に準拠しています。そのため、アプリケーションを開発する際はJMS1.1を利用するようにしてください。

18


18

JMSプロバイダー機能


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

SIBus

JMSClient

WMQ

他社メッセージング製品

JMS

ClientJMS JMS

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

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

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

WAS V6の新機能であるSIBusのメッセージング機能を利用

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

WMQとリンク可能

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

実績が豊富

高い信頼性

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

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

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

その他のJMSプロバイダー

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

WMQ以外のJMSプロバイダー

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

・SIBus (Service Integration Bus：サービス統合バス)のメッセージング機能

「デフォルトのメッセージング」は、WAS V6の新機能である、SIBusのメッセージング機能を利用します（SIBusについては後述）。WAS V6はJ2EE 1.4を実装しているので、J2EE 1.4に含まれるJMS1.1を利用可能です。

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

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

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

19


19

SIBus(サービス統合バス）

サービス統合に必要な通信インフラストラクチャーを提供

二つの役割


メッセージのルーティング及びフォーマット変換機能

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

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

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

JMS1.1サポート

Webサービスルーティング

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

WebSphereV6でのESB(Enterprise Service Bus)機能の実装

SI-Bus

JMSJMS

リンク

WebSphereMQ

WebSphereV6セル

Webｻｰﾋﾞｽ

SI-Bus

JMSJMSWebｻｰﾋﾞｽ

V6 New

SIBusはサービス統合に必要な通信インフラストラクチャーを提供し、二つの役割を持っています。

1.JMSプロバイダー機能

・メッセージのルーティング及びフォーマット変換機能を提供します。

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

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

・WebSphere MQ製品と接続可能です。

・JMS1.1をサポートしています。

2.Webサービスルーティング機能

・SIBus上の既に定義してある宛先をWebサービスとして外部からアクセスできるようにします。（インバウンド・サービス）

・SIBus上のアプリケーションからWebサービスをコールできるようにします。（アウトバウンド・サービス）

・Webサービスのプロバイダーとリクエスターの間にSIBusを配置しWebサービスのGatewayとして機能させられるようにします.この機能はND環境下でのみ使用可能です。（ゲートウェイ・サービス/プロキシー・サービス）

ESBとは複数のサービスを繋ぎあわせるためのバスです。サービス間のメッセージのプロトコル変換、ルーティング、ロギング、セキュリティ等の機能を持ちます。ESBはSOA(Service Oriented Architecture)の通信基盤となるとされています。

SOAとは各種のプログラムを「サービス」として位置づけ、記述言語を通じて呼び出し利用するアーキテクチャです。SOAは、多数のサービスを組み合わせ新しい価値を持つサービスを作り出すことを目的としています。

20


20

練習問題

1. Webブラウザーブラウザーブラウザーブラウザーからからからからサーブレットサーブレットサーブレットサーブレットをををを呼呼呼呼びびびび出出出出してしてしてして利用利用利用利用するするするする場合場合場合場合、、、、一般一般一般一般ににににブラウザーブラウザーブラウザーブラウザーからのからのからのからの要求要求要求要求はどのはどのはどのはどの順番順番順番順番でででで流流流流れるでしょうかれるでしょうかれるでしょうかれるでしょうか

A. LDAPサーバー、JMSサーバー、WebコンテナーB. 外部HTTPサーバー、HTTPサーバー・プラグイン、WebコンテナーC. 組み込みHTTPサーバー、Webコンテナー、EJBコンテナー

2. 新機能新機能新機能新機能であるであるであるであるHA Managerについてについてについてについて正正正正しいものをひとつしいものをひとつしいものをひとつしいものをひとつ選択選択選択選択してくださいしてくださいしてくださいしてください

A. サーバー障害時に、アプリケーション・サーバー・レベルでのトランザクションのリカバリーが可能B. HA Manager は各アプリケーション・サーバーのプロセス内のエンタープライズアプリケーション

として実行され、クラスターの正常性を監視するC. HA Manager は、トランザクション・サービス、JMSメッセージ・サービス、サービス統合バス・

サービスなどの可用性を高める

<memo>

21


21

2章導入と構成

<memo>

22


22

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

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

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

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

・インストールするマシンにAdministrator 権限をもったユーザーでログインしていること

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

-IP アドレス、ネットマスク、デフォルト・ゲートウェイ、ホスト名(インストール後の変更はできません)

-DNS を使用する場合は名前解決を適切に行えること

-ディスクが以下に示す以上の空き容量を持つこと

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/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_winsetup.htmlに記載されていますので、ご参照下さい。

<memo>

23


23

WAS導入の手順（ランチパッドよりウィザードで導入の場合）1.製品コンポーネントと衝突するパッケージのアンインストール（IISやApacheなど）

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

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

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

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

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

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

8. ノードノードノードノードのののの統合統合統合統合Deployment Manager にApplication Server ノードを統合。Deployment Manager 起動→Application Server 起動→Deployment Manager管理コンソール上でノードを統合

9．インストールインストールインストールインストールのののの確認確認確認確認：：：：http://<ホストホストホストホスト名名名名>:9080/snoop へアクセス。結果が正常に表示されれば、アプリケーション・サーバーの起動は正常

インストールの詳細についてはhttp://www-6.ibm.com/jp/software/websphere/developer/was/wv6/nd/ を参照下さい

<memo>

24


24

WebSphereプロファイルとは？インストール・イメージに対して複数の構成が可能

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

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

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

WebSphereプロファイルプロファイルプロファイルプロファイル

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

利点

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

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

プロファイルの種類

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

V6 New

製品バイナリー

+

+

ノードWebSphereプロファイル

WebSphereプロファイル

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

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

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

WebSphereプロファイルは、V6からの新しい管理の仕組みです。インストールした製品のバイナリーファイルとは別に、プロファイルごとに、構成ファイルを作成します。このことにより、構成・管理をより柔軟に行うことができるようになりました。

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

1つは、インストール時にコピーされる、製品のバイナリイメージです。これは読み取り専用であり、システムごとにカスタマイズされることはありません。アプリケーション・サーバーインスタンスによって共通に使用されます。

もう1つは、カスタマイズされた構成ファイルです。構成を保管するファイルや、アプリケーション、各種のプロパティなどであり、これらをまとめて、WebSphereプロファイルと呼びます。

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

WebSphereプロファイルという機能を利用することにより、一つの共通コードから、デプロイメント・マネージャーやアプリケーション・サーバーなどの異なるプロファイルを作成することができます。製品に対する修正は、インストールした1つの製品ファイルに適用するだけで良いです。

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

プロファイルの便利な点として、例えば、テスト環境などで、構成を初めからやり直したい場合など、プロファイルを削除するだけで初期状態に戻すことができるということが上げられます。製品のアンインストール、再インストールなどは必要ありません。

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

プロファイルには作成するプロファイルのタイプに応じたプロファイル･テンプレートが準備されています。アプリケーション・サーバー・プロファイル･テンプレートはアプリケーション・サーバーのプロファイルを作成し、その上に”server1”というアプリケーション・サーバーを作成します。アプリケーション・サーバー・テンプレートはスタンドアローン･ノードとして作成することも、作成後にセル環境に統合することも可能です。セル環境に統合した場合、そのタイミングで”nodeagent”という名称のノード・エージェントを作成します。デプロイメント・マネージャープロファイル･テンプレートはデプロイメント・マネージャーのプロファイルを作成し、その上に”dmgr”という名称のデプロイメント・マネージャーを作成します。最初からセル環境に統合した管理ノードを作成したい場合、カスタム･プロファイル･テンプレートを使用します。カスタム･プロファイルはセルに統合されたノード・エージェントのみを持つノードです。必要に応じてここにアプリケーション・サーバーを作成していきます。デプロイメント・マネージャー・プロファイル･テンプレートと、カスタム･プロファイル･テンプレートはWAS ND版でのみ提供されます。

25


25

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

①WASインストーラーで導入 ②プロファイル作成ウィザード／wasprofileで作成

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

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

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

ASプロファイル AS NA

DMプロファイル DM

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

③wasprofileで操作

<WAS_root>/WebSphere/AppServer

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

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

◆プロファイル作成ウィザード（作成） ◆wasprofileコマンド（作成、削除、検査、）

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

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

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

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

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

プロファイルを管理するためにはGUIの『プロファイル作成ウィザード』とCUIの『wasprofileコマンド』の二種類の管理ツールが提供されます。使用目的に応じて使い分けてください。

プロファイル作成ウィザードはプロファイルの作成にのみ使用できるウィザードで、『<WAS_root>/bin/pct<プラットフォーム>.<実行ファイル拡張子>』コマンドで起動します。ファイル名はたとえばWindows環境ではpctWindows.exe、Linux環境ではpctLinux.binです。プロファイル作成ウィザードはその名の通りプロファイルの作成しか行えません。プロファイルの削除などはwasprofileコマンドで行います。

wasprofileコマンドは『<WAS_root>/bin/wasprofile.<実行ファイル拡張子>』で呼び出すコマンドラインツールです。以下の引数でプロファイル操作を行います。

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

オプションで名前から推察しづらいもののみここで解説します。augmentはWASの基盤の上にWBISFのような拡張製品を導入した際にプロファイルを拡張するために使用されるオプションです。validateRegistryはプロファイル情報を保持するXML（<WAS_root>/properties/profileRegistry.xml）とprofiles以下のファイルシステムの整合をチェックするものです。profilesディレクトリ以下のファイルを誤って消した場合、validateAndUpdateRegistryをかけるとprofileRegistry.xmlを更新してプロファイル情報を消しこみます。

wasprofileコマンドで上記プロファイル作成ウィザードの画面コピーのようにプロファイル･タイプを指定するには-templatePathで指定します。それぞれのパスは以下の通りです。

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

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

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

プロファイル作成ウィザード、wasprofileコマンドの双方とも、ログを<WAS_root>/logs/wasprofileに書き出します。ファイル名のネーミングルールは『wasprofile_<オペレーション>_<プロファイル名>.log』です。たとえば上のwasprofileの例では、ログの名称は『wasprofile_create_AppSrv02.log』になります。コマンドの失敗の際などは標準出力にあまり有用な情報が記載されないので、このログを参照するようにしてください。ログはXML形式で記載されます。（さらに詳細のログが<WAS_root>/profiles/<プロファイル名>/logsに記載され、上記ログからポイントされている場合もあります。）

26


26

wasprofileコマンド使用例（参考）

wasprofile.sh -delete -profileName プロファイルの名前

プロファイルを削除したいとき

定義済みのポート番号をプロファイルで使用したいとき

/profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props ファイルを使用して初期ポートを設定します

WC_defaulthost=39080WC_adminhost=39060WC_defaulthost_secure=39443WC_adminhost_secure=39043BOOTSTRAP_ADDRESS=32809SOAP_CONNECTOR_ADDRESS=38880SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=39401CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=39403CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=39402ORB_LISTENER_ADDRESS=39100DCS_UNICAST_ADDRESS=39353SIB_ENDPOINT_ADDRESS=37276SIB_ENDPOINT_SECURE_ADDRESS=37286SIB_MQ_ENDPOINT_ADDRESS=35558SIB_MQ_ENDPOINT_SECURE_ADDRESS=35578

portdef.propsファイルの例

wasprofile.sh -portsFile C:¥temp¥ports¥portdef.props

※Windowsの場合はwasprofile.bat

portdef.propsファイルの場所を指定

wasprofileコマンドは『<WAS_root>/bin/wasprofile.<実行ファイル拡張子>』で呼び出すコマンドラインツールです。

ここではよく利用される一例をあげましたが、詳細はマニュアル「インフォセンター」の下記を参照ください

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rxml_wasprofile.html

27


27

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

サイレント・インストールでは、インストール・ウィザードの使用時に、グラフィカル・ユーザー・インターフェースを使用せずに、サイレント・モードで製品をインストールできます。サイレント・インストールによって、インストール・プログラムは、ウィザード・インターフェースを表示する代わりに、ユーザーが提供するファイルからユーザーの応答をすべて読み取ることができます。

製品CDのWASディレクトリまたはマニュアル（インフォセンター）のサイレント・インストールの章にサンプルの応答ファイルが用意されています。このファイルの中のパラメーターを、環境にあわせて変更して利用します。

[ドライブドライブドライブドライブ名名名名]:¥WAS¥install" -options "C:¥temp¥WAS¥myoptionsfile.txt" -silent 作成した応答ファイルを指定します

詳細については、下記 Info Center をご参照ください。「サイレント・インストール」http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_runSilent.html

Network Deployment の場合はプロファイルを作成して、作動環境を作成する必要があります。

作成する予定のプロファイルのプロファイル・オプション応答ファイルをカスタマイズすることにより、プロファイルをサイレントに作成することができます。オリジナル・プロファイル応答ファイルの名前は以下のとおりです。

Deployment Manager プロファイル: responsefile.pct.NDdmgrProfile.txt アプリケーション・サーバー・プロファイル: responsefile.pct.NDstandAloneProfile.txt カスタム・プロファイル: responsefile.pct.NDmanagedProfile.txt

これらをコピーしてパラメーターを環境にあわせて変更し利用する

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

サイレント・インストールではあらかじめ設定しておかなければならないパラメーターや設定項目を応答ファイルに記述しておき、インストールプログラムはそのファイルの中身を読み取りながらインストールを実行します。

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

28


28

Webサーバーをセルで管理可能WAS 6.0 ND では新機能として、IBM HTTP Server 6.0 をWebSphere セルに含めて管理可能になりました。

IBM HTTP Server 6.0 の起動や停止、設定をWebSphere 管理コンソールから行うことができます。

また、アプリケーション・サーバーとIBM HTTP Server が別のマシンにインストールされている場合、WAS V5.x では手動で行わなくてはならなかったプラグイン構成ファイルのコピーも、自動で行わせることができるようになりました。

V6 New

Node

ApplicationServer

ApplicationServer

NodeAgent

DeploymentManager

Cell

WebServerWebServerPlug-inConfig

XML filePlug-in Module

HTTP(S)HTTP(S)

◆IBM HTTP Server とWebSphere Application Serverを同じノード（マシン）に導入した場合◆

WebサーバーはNode Agent 経由で管理され、管理コンソールから次の操作が可能

①プラグイン構成の生成・伝搬②Webサーバーの開始・停止③ログファイルの表示④構成ファイル(httpd.conf)の編集

WASV6.0からはWebサーバーをデプロイメント・マネージャーの管理対象サーバーに含めることができるようになりました。

これにより、管理コンソールから以下の操作が可能になります。

・Webサーバーの稼動状況の確認

・プラグイン構成ファイルの生成・更新、伝搬

・Webサーバーの始動/停止、終了

・Webログファイルの表示

・構成ファイル（httpd.conf)の編集

29


29

IHS管理管理管理管理

Process

マシン B

ApplicationServer

ApplicationServer

Node

Node Agent

DeploymentManager

Web ServerWeb ServerPlug-inConfig

XML filePlug-in Module

HTTPコマンドコマンドコマンドコマンド

HTTP(S) HTTP(S)

マシンAマシンB

WebサーバーはIHS 管理プロセス経由で管理され、次の操作が管理コンソールから可能①プラグイン構成の生成・伝搬②Webサーバーの開始・停止

Node Agent経由と比べて、IHSログファイルの表示や構成ファイルの編集はできません。※マシンBにNode Agentを導入し、ケース1と同様にNode Agent経由の管理を行うこともできます。ただしその場合は、マシンBにもWebSphere Application Serverのラインセンスが必要となります

◆IBM HTTP Server とWebSphere Application Serverを別マシンに導入した場合◆

リモートのWebサーバーを管理する場合 V6 New

リモートのWebサーバーマシン上にノード・エージェントを作成することで、Webサーバーマシンを管理ノードとしてデプロイメント・マネージャー経由で管理することが可能です。デプロイメント・マネージャーからHTTPコマンドが発行され、Webサーバー上のHIS管理プロセスを通してWebサーバーを管理します。

これにより以下のことが実施可能です。

・プラグイン構成の生成

・プラグイン構成の伝播

・Webサーバーの開始・停止、ログファイルの表示、構成ファイルの編集

30


30

Webサーバープラグインについてプラグインプラグインプラグインプラグイン構成構成構成構成ファイルファイルファイルファイル(plugin-cfg.xml)にはプラグインがWASへのリクエストの割り振りを決定する情報が記述されている

プラグインがリクエストの割り振りを正しく行うには、正しいプラグイン構成ファイルを参照

WASのアプリケーション情報がプラグイン構成ファイルに反映されている必要がある


Webサーバー

プラグインプラグイン

プラグイン構成ファイル（plugin-cfg.xml）

------------------

プラグイン構成ファイルを参照してリクエストの割り振りを決定する



Webサーバー

プラグインプラグイン

プラグイン構成ファイル（plugin-cfg.xml）

------------------

ローカル Webサーバー構成

リモートWebサーバー構成

プラグイン構成ファイルの生成・更新

プラグイン構成ファイルの伝搬

ノード

ノードノード

WebサーバーはユーザーからのリクエストをWASに送信しているのですが、この割り振りを担っているのがプラグイン（Webサーバー・プラグイン）です。WAS上で稼動するアプリケーションとサーバーの情報はプラグイン構成ファイル(plugin-cfg.xml)というXMLファイル記述されており、プラグインはWASが生成するプラグイン構成ファイルを参照してリクエストをどのサーバーに割り振るのかを決定します。したがって、リクエストの割り振りを正しく行うには、プラグインが正しいプラグイン構成ファイルを参照する必要があり、またWASが正しいアプリケーションの情報をプラグイン構成ファイルに反映させる必要があります。

プラグインがどのプラグイン構成ファイルを参照するのかはWebサーバーの持つ構成ファイル（IHSではhttpd.confファイル）に記述されます。

WASに新規エンタープライズ・アプリケーションをインストールした場合には、プラグイン構成ファイルの更新を実施する必要があります。ローカルWebサーバー構成の場合にはプラグイン構成ファイルの生成・更新になりますが、WebサーバーがWASとは別のマシン上にあるリモートWebサーバー構成の場合には、加えてプラグイン構成ファイルの伝搬を実施してプラグイン構成ファイルをWebサーバーにコピーする必要があります。

31


31

導入で問題が発生した場合は？◆インストール・ログ・ファイルでエラーがないか調査。インストールおよびプロファイル作成状況は次のログファイルに記載されます

「「「「 install_root/logs/log.txt 」」」」ファイル「「「「 install_root/logs/wasprofile/wasprofile_create_profile_name.log 」」」」ファイル「「「「 profiles_root/profile_name/logs/pctLog.txt 」」」」ファイル

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

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

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

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

プロファイル作成ウィザードの使用時に発生するすべてのプロファイル作成イベントを記録します

install_root/profiles/profile_name/logs/pctLog.txt

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

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

INSTCONFPARTIALSUCCESS

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

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

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

合に作成されます

install_root/logs/wasprofile/wasprofile_create_profile_name.log

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

INSTCONFSUCCESS インストールの成功

INSTCONFPARTIALSUCCESS

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

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

install_root/logs/log.txt

インディケーター内容ログ名称

導入で問題が発生した場合には、必ずログ・ファイルを確認します。問題の原因を分析・除去してから、再度導入手順を実行してください。また、ISMP（InstallShield for multiplatform) がインストール・ウィザードを開始できない場合があります。このような場合、インストール・ウィザードの起動に十分なディスク・スペースがないことなどが考えられます。インストールが失敗し、インストール・ログに情報がない場合は、-log パラメーターを使用して、ISMP プログラムがインストール・ウィザードの開始に失敗する原因となるイベントのエントリーを記録することができます。このようなイベントを記録するための install コマンドの構文は、以下のとおりです。

install -options fully_qualified_options_response_file_name

-silent

-log # !fully_qualified_log_file_name @ALL

32


32

導入・構成における主要ログ

ノード単位JVMログに詳細を追加したログ。ログアナライザーを用いて読み取るactivity.log

プロセス単位JVMの標準エラー出力/ ログ解析の基本SystemErr.log

プロセス単位JVMの標準出力/ ログ解析の基本SystemOut.log

プロセス単位停止サーバー・イベントのログstopServer.log

プロセス単位開始サーバー・イベントのログstartServer.log

内容ログ名称

InfoCenterInfoCenter（マニュアル）（マニュアル） http://www-3.ibm.com/software/webservers/appserv/infocenter.htmlトラブルシューティング」＞「タスクの概説」＞「タスクごとのトラブルシューティング」も参照ください

JVMログ

開始・停止ログ

プロファイル単位の/logsディレクトリ

IBM保守ログ

/logs以下にサーバー単位のディレクトリ

上記は、導入･構成における主要なログの場所と名前です。

特にWASV6からはプロファイルという概念が登場したため、ログディレクトリーの構成がWASV5とは異なっていることに注意してください。例えばアプリケーションサーバーが正常にスタートしたかどうかをチェックするための開始・停止ログやJVMログは<WASインストールルート>/profiles/<プロファイル名>ディレクトリの下のlogsディレクトリに保管されるようになります。

ログの詳細については、7章の問題分析もご参照ください。

33


33

練習問題3. Webサーバーサーバーサーバーサーバー(IHS) ををををセルセルセルセルにににに含含含含めてめてめてめて管理管理管理管理したいとしたいとしたいとしたいと考考考考えていますえていますえていますえています。。。。Webサーバーサーバーサーバーサーバーががががリモートサーリモートサーリモートサーリモートサー

バーバーバーバー上上上上にあったにあったにあったにあった場合場合場合場合、、、、管理管理管理管理できないできないできないできない項目項目項目項目はははは次次次次のうちどれでしょうかのうちどれでしょうかのうちどれでしょうかのうちどれでしょうか

A. Webサーバーの開始・停止B. プラグイン構成の生成・伝搬C. 構成ファイル（httpd.conf)の編集

4. ウィザードウィザードウィザードウィザードをををを使用使用使用使用してしてしてして、、、、WASV6.0のののの製品製品製品製品バイナリファイルバイナリファイルバイナリファイルバイナリファイルををををインストールインストールインストールインストールしましたしましたしましたしました。。。。インストールインストールインストールインストールがががが完了完了完了完了したしたしたした直後直後直後直後ののののアクションアクションアクションアクションとしてとしてとしてとして適切適切適切適切なものをなものをなものをなものを選択選択選択選択してくださいしてくださいしてくださいしてください

A. プロファイルを作成するかどうか選択する画面が表示されるので、ここで作成するか後で作成するかを決定するB. デフォルトでプロファイルが作成されるのでしばらく待つC. IHSの導入を促す画面が表示されるので、IHSのインストールを行う

5. インストールインストールインストールインストール中中中中にににに、、、、前提条件前提条件前提条件前提条件をををを満満満満たしていないというたしていないというたしていないというたしていないという理由理由理由理由ででででインストールインストールインストールインストールがががが失敗失敗失敗失敗しましたしましたしましたしました。。。。次次次次のうちどののうちどののうちどののうちどのログファイルログファイルログファイルログファイルをををを調調調調べればよいでしょうかべればよいでしょうかべればよいでしょうかべればよいでしょうか

A. install_root/logs/log.txtB. install_root/logs/wasprofile/wasprofile_create_profile_name.logC. %TEMP%¥log.txt

<memo>

34


34

3章アプリケーション・アセンブリーとデプロイメントおよびサーバー・リソースの構成

<memo>

35


35

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

EJBコンポーネ

ント

WARWAR

JARJAR

EAREAR

※EARへのパッケージングはRational Application Developerでも可能

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

WebDD

EJBDDApplication

DD

WASサーバーサーバーサーバーサーバー

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

AST（（（（Application Server Toolkit)をををを利用利用利用利用するするするする部分部分部分部分

作成したプログラムはJ2EEアプリケーションにパッケージングしてからアプリケーションサーバーにインストール必要があります。ASTはパッケージングの部分を行うツールキットです。

J2EEで作成したモジュールを実際にJ2EEアプリケーションとしてWebSphere Application Serverに導入する方法には大きく分けて二つのプロセスがあります。ひとつは作成したモジュールのJ2EE形式でのパッケージング、そしてもうひとつはパッケージングされたモジュールのインストールです。JSPやServlet、HTMLや画像ファイルなどはWebARchiveファイル（WAR）形式でパッケージングします。EJBモジュールはJavaARchiveファイル（JAR)形式でパッケージングします。これらのファイルをEnterpriseARchiveファイル（EAR)形式にまとめます。

これでJ2EEアプリケーションとしてインストールできる形になります。ここまでのプロセスは開発ツールであるRational Web DeveloperおよびRational Application Developerで行うこともできますし、WebSphere Application Serverに付随のAST (Application Server Toolkit)で行うことも可能です。

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

この管理コンソールを用いて、EARファイルをWebSphere Application Serverにインストールします。管理コンソールから「アプリケーション」→「新規アプリケーションのインストール」を選択し、ステップに沿って順に設定していくと容易にインストールすることができます。ステップの最後には要約画面が出てきますので内容を確認し問題がなければ保管して構成情報を反映させます。

36


36

AST(Application Server Toolkit)の機能

J2EEモジュールのアセンブリーEJBモジュール(.jar)Webモジュール(.war)アプリケーション・クライアント・モジュール(.jar)リソース・アダプター(.rar)

J2EEアプリケーションのパッケージング

デプロイメント・ディスクリプター(DDファイル）の編集

IBMバインディング情報(ibm-xxx-bnd.xmi)の編集

IBM拡張(ibm-xxx-ext.xmi)の編集

WASではJ2EEを拡張した機能がサポートされています。これらの機能は追加の構成情報として次のファイルに記載されます

IBMバインディング・ファイル(ibm-xxx-bnd.xmi)ibm-application-bnd.xmi・ibm-ejb-jar-bnd.xmi・ibm-web-bnd.xmi・ibm-application-client-bnd.xmi

IBM拡張・ファイル（ibm-xxx-ext.xmi)ibm-application-ext.xmi・ibm-ejb-jar-ext.xmi・ibm-web-ext.xmi・ibm-application-client-ext.xmi

Enhanced EAR機能機能機能機能

EARファイルの中に、データソースなどのリソース定義まで含める

ことにより、デプロイメントの際に必要になる情報を削減します。

ASTではEnhanced EAR をサポートするため、エンタープライズ・

アプリケーションのデプロイメント記述子エディターに新規ページが

追加されました。このページでサーバー構成を指定することにより

その情報がアプリケーションそのものの内部に組み込まれます。

V6 New

ASTは作成したモジュールをアプリケーション・サーバーにインストールできる形式、いわゆるエンタープライズアプリケーション形式（EARファイル）にパッケージングするためのものです。

パッケージングにはモジュールのほかにディプロイメント・ディスクリプターファイル（DDファイル）が必要ですがこれらを編集することも可能です。

またWASV6ではEnhancedEARという機能が新規に追加されました。これはEARファイルにデータソースなどのリソース定義を含めることができるというものです。これによりアプリケーション・サーバーインストール時の、デプロイ作業が軽減されます。

ASTではEnhancedEARをサポートするためにこれらのリソース情報を定義するページができました。これはアプリケーション・デプロイメント記述子エディターに新規ページとして追加されています。

37


37

ASTによるモジュールへのセキュリティロール割り当て

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

Servlet 1

Servlet 2

Servlet 3

Servlet 4

Aさん

Bさん

Cさん

個々のユーザー単位で設定していては人事異動の際など膨大なワークとなる

Servlet 1

Servlet 2

Servlet 3

Servlet 4

勤務記録承認

交通費承認

契約書承認

制約制約制約制約

人事部門の役割

各部門長の役割

営業部門長の役割

役割役割役割役割

A1/A2/A3

B1/B2

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

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

ASTでは役割と必要とするモジュールに役割を定義することが可能

ASTではモジュールにセキュリティロール(役割）を割り当てることができます。

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

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

38


38

①ユーザーは、エンタープライズ・アプリケーション (EAR ファイル)アプリケーション・モジュール (WAR ファイル、EJB JAR ファイル)Javaソース・ファイル、Java クラス・ファイル、イメージ、XML または HTMLファイルをモニター対象ディレクトリーと呼ばれるユーザーディレクトリに置いておきます。

②高速デプロイメント・ツールは、これら J2EE 成果物の追加部分または変更部分を自動的に検出し、サーバーで実行できるアプリケーションを作成し、ターゲット・サーバーにデプロイします。

WebSphere Rapid Deployment Tool (WRD) V6 New

Deployment Automationを使うと、ユーザーが定義したディレクトリにあるファイルやモジュールに変更を加えると、それを自動検知し、稼動中のアプリケーション・サーバーにデプロイして変更内容を反映してくれます

このツールではAutomatic installation(自動インストール）とFree Formの2つのスタイルが指定できます。

Automatic installation ⇒EAR単位やWAR,JARといったモジュール単位で変更を加える場合に使います。Free Form ⇒クラスファイルやHTMLファイルなど個々のファイル単位で変更を加える場合に利用します

詳細はInfocenterのこちらをご覧下さい

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.etools.wrd.freeform.doc/topics/rwrdconfbat.html

アプリケーションの開発とデプロイメントを効率化する機能

Annotation-based programmingプログラミングの簡略化

Deployment Automationアプリケーションのデプロイメントや更新の自動化

WebSphere Rapid Deploymentは、アプリケーションの開発とデプロイメントを効率化する機能です。Annotation-based programmingは、プログラミングを簡略化するための機能です。Annotation-based programmingの機能を詳しく説明します。まず、開発者は、1つのJavaソースファイルに、必要な情報をannotation(注釈)として記述します。WebSphere Rapid Deployment機能は、これを受け、アプリケーションの稼動に必要な他のJavaソースファイルを自動生成します。基のソースファイルに変更が加わると同期的に反映させる機能も含まれています。この機能により、開発者が作成・保守しなければならないソースファイルの数を削減することが可能となります。

Deployment automationは、アプリケーションのデプロイメントや更新を自動化することができます。これは指定されたディレクトリに変更があったファイルやモジュールをおいておくと自動的に検知し、アプリケーション・サーバーにデプロイしてくれるというものです。モジュール単位とファイル単位の変更の両方がサポートされています。

39


39

リソース定義スコープ

セルセルセルセル

クラスタークラスタークラスタークラスター

ノードノードノードノード

サーバーサーバーサーバーサーバー

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

スコープのオーバーライド階層

リソース：JDBCプロバイダー定義画面

セルセル

クラスタークラスター

サーバーサーバー

ノードノード

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

Enhanced EAR

エンタープライズ･アプリケーション画面

リソースのJDBCプロバイダー設定の有効範囲として『スコープ』を指定します。例えばセル･レベルのスコープでリソースを定義するとそのリソースは全てのプロセスから使用可能ですが、ノード･レベルでリソースを定義するとそのリソースは定義したノード以外のノードでは使用できないことになります。『スコープ』はセル、クラスター、ノード、サーバー、アプリケーションの五階層となります。

中央の画面コピーで見て取れるように、管理コンソールから定義可能な階層はクラスターを含めた4つです（先にクラスターを定義しないと三階層しか現れません）。ではアプリケーション･スコープのリソース定義とはどのように定義するのでしょうか？これはEnhanced EARというEARの中にリソース構成情報なども含んだ拡張エンタープライズ･アプリケーションで定義します。Enhanced EARを作成するのはRational Application Developerですが、ターゲット･サーバーをWAS V6とするとデフォルトでEnhanced EARを作成するので、DDにテスト用のリソース定義などを入れ込んでいる場合にはデプロイ時に注意が必要です。管理コンソールではアプリケーション･スコープの定義情報を作成・変更することは出来ないのでApplication Server Toolkitやwsadminを使用して変更を行うことになります。右下の画面コピーは導入されたEnhanced EARを参照した際に出るメッセージで、「このアプリケーションにはひとつ以上のアプリケーション有効範囲リソースが含まれている」旨の記載がされています。

同名のリソースを定義した場合はアプリケーションに近いほうの定義が使用されます。

つまり同じWebSphere変数”DB2_JDBC_DRIVER_PATH”をスコープ：セルとスコープ：ノードの双方で定義した場合、ノードの定義が優先して使用されます。これをスコープのオーバーライド階層と言います。

40


40

ネーミングサービス（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）を使用して、アプリケーション・コードから外部リソースへの統一されたアクセス環境を提供しています。

JNDIで取得する対象としては、リソース参照、EJB参照、UserTransaction参照があります。

「参照」の使用

JNDIクライアントにおいてlookup を行う際は、lookupするオブジェクトの名前の記述フォーマットとして[ java:comp/env/ ]コンテキストを先頭につけた形とすることが原則です。デプロイ時に、「参照」を実際のJNDI名にバインドします。

「参照」の例

EJB参照：java:comp/env/ejb/…リソース参照：

－JDBC DataSourceへの参照：java:comp/env/jdbc/.

41


41

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

nodeagent

dmgrserver1 server2

Bootstrap Port 2809 98099810 9811

物理ノード(ホスト名: gonta)

論理ノード(ノード名: gontaNode)

論理ノード(ノード名: gontaManager)

Deployment Manager (dmgr) は同じ物理ノードにあっても他のプロセスとは別論理ノード扱いになる。

DS1 DS1ノードレベル (gontaNode)

サーバーレベル (server1) DS1

DS1DS1DS1

DS1

セルレベル

ノードレベル(gontaManager)

データソース「DS1」を定義するJDBCプロバイダーの有効範囲設定

プロセス名

クラスターレベル (ClusterA) DS1 DS1

ClusterA

プロセスごとにネームスペースを持つ

有効範囲の選択と、作成されるデータソースの関係を図にしたものです。

JDBCプロバイダー作成時の有効範囲

管理コンソールで、「リソース > JDBCプロバイダー」を作成するときに指定する有効範囲(セル・ノード・クラスター・サーバー)によって、データソースが登録されるネームスペースのプロセスが異なります。

データソース「DS1」を定義するJDBCプロバイダーの有効範囲が

「セルレベル」のときDS1はserver1, server2, dmgrのネームスペースに登録される

「ノードレベル(gontaManager)」のときDS1はdmgrのネームスペースに登録される

「ノードレベル(gontaNode)」のときDS1はserver1, server2のネームスペースに登録される

「クラスターレベル（ClusterA)」のときDS1はserver1、server2のネームスペースに登録される

「サーバーレベル (server1)」のときDS1はserver1のネームスペースに登録される

JDBCプロバイダーの作成におけるデフォルトの有効範囲はDMのノードになっているので注意が必要となります。

「有効範囲」はどのプロセスに対してデータソースを定義するか、の選択

有効範囲の違いによって、あるプロセスがもつネームスペース内の登録のされ方が変わるわけではない（階層構造は決められている）。

例えば、server1に登録されるデータソース「DS1」は「セルレベル」「ノードレベル(gontaNode)」「サーバーレベル (server1)」いずれの有効範囲を選択したときも、「 (最上位)/nodes/gontaNode/servers/server1/jdbc/DS1 」となる。

また、最大接続数が10と指定されているデータソースの場合、各アプリケーション・サーバー単位で最大10接続が有効になります。このデータソースの有効範囲がセルレベルで定義されていた場合でも、各サーバー毎に最大10接続有効であり、セル全体で10接続に限定されるわけではありません。

42


42

J2Cのののの目的目的目的目的

J2EE1.3～の構成要素

EIS接続のための統一インターフェイス

接続先エンタープライズシステムの違いを吸収し、同一の手法でアクセスを実現

リソースリソースリソースリソース・・・・アダプターアダプターアダプターアダプター(RA:Resource Adapter)J2C接続のキー・コンポーネント

RAR（Resource Adapter Archive)ファイルの形態で提供

共通共通共通共通プロパティプロパティプロパティプロパティ – Common Client Interface(CCI)Connection FactoryConnection SpecInteractionSpecRecord

System Contractセキュリティ管理

トランザクション管理

コネクション管理

J2C:J2EE Connector Architecture

※EIS: Enterprise Information System

J2CとはCICSやIMSといったいわゆるEnterprise Information Systemに接続するための統一化されたインターフェイスになります。

J2EE1.3からサポートされています。

J2Cがあることにより、接続先のEISが何であろうと意識せずに統一した手法（API）を使ってアクセスすることが可能です。

J2Cを利用するためには接続先のEISに対応したリソースアダプター(ランタイム）が必要です。これはRARファイルの形でEISから提供されています。これをJ2EEサーバーに組み込んで使用します。

43


43

練習問題6. ASTをををを利用利用利用利用してしてしてして作成作成作成作成したしたしたしたモジュールモジュールモジュールモジュールををををパッケージングパッケージングパッケージングパッケージングしようとしていますしようとしていますしようとしていますしようとしています。。。。リソースリソースリソースリソース定義定義定義定義もももも含含含含めためためためた

拡張拡張拡張拡張EARファイルファイルファイルファイル（（（（Enhance EAR形式形式形式形式））））をををを作成作成作成作成したいのですがしたいのですがしたいのですがしたいのですが、、、、次次次次のうちのうちのうちのうち正正正正しいしいしいしい手順手順手順手順はどれではどれではどれではどれでしょうかしょうかしょうかしょうか

A. 管理コンソールを利用してリソース定義をしてから、ASTを起動しパッケージング作業終了後、拡張EAR形式にてエキスポートする

B. ASTで作業中にアプリケーションデプロイメント記述子エディターを開き、デプロイメントページでリソース定義をし、拡張EAR形式でエキスポートする

C. ASTで各モジュール（WARファイル,JARファイル）を開き必要なリソースを定義し、それぞれ構成情報が含まれた状態のモジュールをEARに含めて、拡張EAR形式でエキスポートする

7. JDBCプロバイダープロバイダープロバイダープロバイダーががががセルセルセルセルととととノードノードノードノード両方両方両方両方ののののスコープスコープスコープスコープでででで定義定義定義定義されておりされておりされておりされており、、、、重複重複重複重複するするするするデータデータデータデータ・・・・ソースソースソースソースがががが両方両方両方両方にににに定義定義定義定義されていますされていますされていますされています。。。。さらにさらにさらにさらに拡張拡張拡張拡張EARファイルファイルファイルファイルでもでもでもでも同同同同じじじじデータソースデータソースデータソースデータソースがががが定義定義定義定義されていまされていまされていまされていますすすす。。。。このこのこのこの場合場合場合場合、、、、優先優先優先優先してしてしてして使用使用使用使用されるされるされるされるデータソースデータソースデータソースデータソースはどれになりますかはどれになりますかはどれになりますかはどれになりますか？？？？

8. WASをあるをあるをあるをあるEIS（（（（Enterprise Information System)ににににJ2Cでででで接続接続接続接続しようとしようとしようとしようと考考考考えていますえていますえていますえています。。。。EISベンダーベンダーベンダーベンダーからはからはからはからはリソースアダプターリソースアダプターリソースアダプターリソースアダプターもももも入手入手入手入手してしてしてしてJ2EEサーバーサーバーサーバーサーバーにににに組組組組みみみみ込込込込みみみみ使用使用使用使用しようとしていしようとしていしようとしていしようとしていますますますます。。。。次次次次のうちのうちのうちのうち、、、、実現実現実現実現できないできないできないできない機能機能機能機能はどれですかはどれですかはどれですかはどれですか？？？？

A. セルで定義されたデータ・ソースB. ノードで定義されたデータソースC. 拡張EARファイルで定義されたデータソース

A. J2EEコンポーネントからEISへ統一化された手法で接続できる機能B. 共通クライアント・インターフェイス（CCI)を実装するための機能C. WASとともにトランザクション管理やメッセージングなどのサービスを提供する機能

<memo>

44


44

4章セキュリティー

<memo>

45


45

WASセキュリティー

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

・OSレベル

ファイルやプログラムの実行権限などのセキュリティー機能。WASはOS上の１プロセスとしてのアクセス制限を受けます。

・JVM

JVMで提供されるセキュリティー機能

・Java2セキュリティー

スレッド、ソケット、ファイルなどのJava2レベルで提供されるシステムリソースへのアクセス制御。WAS自体Javaプログラムなので、Java2のセキュリティー制限下で動作します。

・CORBA Security

J2EEは分散環境を前提にしており、分散オブジェクト間のトランスポート、メッセージ層のセキュリティーはCORBA/CSIv2で提供されるセキュリティー機能を前提にしています。

・J2EE Security API

WASのセキュリティー機能はJAASなどのJ2EE APIをベースにしています。

ポリシー、ロール（役割）ベースのWASセキュリティー機能はこれらのセキュリティー機能の上で動作しています。

・WebSphereセキュリティー

WebリソースやEJBにアクセスするために、ポリシーやサービスを提供します。通常、WASのセキュリティーと言った場合、この層を表します。

WASの設定でグローバル・セキュリティーをオンにすることで、セキュリティー・ドメイン全体で有効なセキュリティーを設定できます。

この資料ではWebSphereセキュリティーとWASセキュリティーを同じ意味で扱います。以後WASセキュリティーと記載します。

46


46

WASセキュリティーの設定

グローバルセキュリティーを使用可能にします。

設定を変更した際には、各実行環境の再始動が必要になる。

アクティブ・プロトコル

Common Secure Interoperability Version 2 (CSIv2)Security Authentication Service (SAS)

アクティブな認証メカニズム

Simple WebSphere Authentication Mechanism (SWAM)Lightweight Third Party Authentication (LTPA)

アクティブなユーザー・レジストリー

ローカル OSLDAP ユーザー・レジストリー

カスタム・ユーザー・レジストリー

WASセキュリティーを使用するには、 WASの設定でグローバル・セキュリティーを使用可能にする必要があります。

またセキュリティーに関する設定を変えた場合には、その設定を有効にするために、セキュリティー・ドメイン全体＊を再始動させる必要があります。（＊アプリケーション・サーバー、ノード・エージェント、およびデプロイメント・マネージャー）

アクティブアクティブアクティブアクティブななななプロトコルプロトコルプロトコルプロトコル

セキュリティーが使用可能になっている場合の、Remote Method Invocation over the Internet Inter-ORB Protocol (RMI IIOP) 要求のためのアクティブな認証プロトコルを指定します。

Common Secure Interoperability Version 2 (CSIv2) と呼ばれるオブジェクト管理グループ (OMG) はさらなるベンダー・インターオペラビリティーおよび追加機能をサポートします。

セキュリティー・ドメインに含まれるすべてのサーバーがバージョン 5.x のサーバーの場合、プロトコルとして CSI を指定します。

バージョン 3.x またはバージョン 4.x のサーバーが存在する場合には、「CSI および SAS」を指定してください

アクティブアクティブアクティブアクティブなななな認証認証認証認証メカニズムメカニズムメカニズムメカニズム

セキュリティーが使用可能になっている場合のアクティブな認証メカニズムを指定します。

WebSphere Application Server および WebSphere Application Server Express バージョン 6.0.x では、Simple WebSphere Authentication Mechanism (SWAM) および Lightweight Third Party Authentication (LTPA) という認証メカニズムがサポートされています。

アクティブアクティブアクティブアクティブななななユーザーユーザーユーザーユーザー・・・・レジストリーレジストリーレジストリーレジストリー

セキュリティーが使用可能になっている場合のアクティブなユーザー・レジストリーを指定します。UNIX 非ルート・ユーザーとして実行する場合や、マルチノード環境で実行する場合は、LDAP またはカスタム・ユーザー・レジストリーが必要です。以下のユーザー・レジストリーのうちの 1 つのみ設定し、構成することができます。

・ローカル OSUNIX プラットフォームでグローバル・セキュリティーを使用可能にし、さらにユーザー・レジストリーがローカル OS である場合は、サーバーをrootとして実行する必要があります。ローカル OS のユーザー・レジストリーは、UNIX プラットフォーム上の非ルート・ユーザーに対してはサポートされていません。またWAS ND環境の場合には、複数サーバーでセキュリティー・ドメインを形成するので、ローカルOSは使用できません。

・LDAP ユーザー・レジストリー

ユーザーおよびグループが外部 LDAP ディレクトリーに置かれている場合には、LDAP ユーザー・レジストリーの設定値が使用されます。

.・カスタム・ユーザー・レジストリー

詳しくはInfoCenterをご参照ください。http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/usec_rgsp.html

47


47

WAS運用管理セキュリティー

管理コンソールのセキュリティー

デフォルトではセキュリティーなし

グローバルセキュリティーにより、ログインが必要になる

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

管理者

コンフィギュレーター、オペレーター、モニターに与えられる権限

サーバー・パスワード、LTPAパスワード、鍵など重要データへアクセスする権限

コンフィギュレーター

モニターに与えられる権限

WASの構成を変更する権限

オペレーター

モニターに与えられる権限

アプリケーションの開始/停止などランタイム状態を変更する権限

モニター

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

管理コンソールやwsadminスクリプトのツールを使用して、WASを管理するための、特定の権限をユーザーに与えることが出来ます。この権限はグローバルセキュリティーを使用可能することにより、有効になります。

管理ロールには、管理者、コンフィギュレーター、オペレーター、モニターの4種類あり、それぞれの管理ロールによってWASの管理機能に対する実行権限が定義されています。

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

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

オペレーターオペレーターオペレーターオペレーターには、モニターに与えられる権限がある上に、WASのアプリケーションの開始/停止などといったランタイム状態を変更する権限があります。

モニターモニターモニターモニターは、最も権限のない管理ロールです。WASに関する構成やランタイム状態を見るだけの権限があり、構成変更などの操作は一切することができません。

48


48

WASセキュリティ:ユーザー認証

Web ClientWeb Client は次のうちどれかのメカニズムを使用してユーザー認証できる。

基本(Basic)認証

クライアント認証（クライアント証明書）

Form認証

Application Clientクライアント・コンテナ内で実行されるJavaアプリケーション

直接EJBとやりとりするServletメッセージ層(CSIv2/SAS)の認証情報

ユーザーID/パスワード(GSSUP(Generic Security Service) Username Password )アイデンティティ情報

アクセス許可情報

クライアント証明書(SSL)WebコンテナからのEJB呼び出しの場合、Webコンテナの認証はWASによって内部的に行われる。

システムユーザーID, パスワードが付加されて送られる。

WAS上の2種類のリソース、WebモジュールとEJBモジュールはそれぞれWebクライアント、Applicationクライアントからアクセスされますが、

それぞれについての認証方式は、Webコンテナーの場合、

①基本(Basic)認証

②クライアント認証(クライアント証明書）

③Form認証

がサポートされます。

EJBの場合も、クライアントを認証する仕組みをもっており、正しいユーザーID・パスワードをもつものしかアクセスできないようにすることができます。

これはCSIv2プロトコルのなかでセキュリティー情報を伝達する仕組みの上で実現されています。

使用されるユーザーIDやパスワードなどは、WASの管理コンソースやWebデプロイメント・ディプロィメントディスクリプタやアプリケーションのディプロイメント・ディスクリプタのなかに設定されたり、Webクライアントから入力された情報がEJBまで伝達される仕組みになっています。

49


49

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

J2EE ロールベースのアクセス制御

Servlet, JSP, Enterprise Beanなどのリソースへのアクセスはロール（役割）によってコントロールされる（EJBもほぼ同様）

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

ロールと実際のユーザーID, グループIDをマップ

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

Webリソース

一般ユーザー

プレミアユーザー

GET

Servlet,jsp,html

GETPOST

ロール

実際のユーザー

グループ

J2EE

web.xml

ユーザー認証を検討した後には、そのユーザーがどのリソースを触ることができるかというアクセス制御を考える必要があります。

WAS上のリソースへのアクセス制御はJ2EE Authorizationモデルに基づいて行われます。

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

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

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

この時の設定のイメージは次のようになります。

servletA allusers GET, POST

servletB premium GET,POST

ロールと実際のユーザーの関連付けは別に行います。

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

これらの設定はアプリケーションをビルドする際にデプロイメント記述子に組み込まれますが、インストール後に変更することも可能です。

Webリソースの場合、セキュリティー制約という概念があり、Web コンテンツの保護方法を決定します。

制約は、Web リソース・コレクション、許可制約、およびユーザー・データ制約で構成されます。

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

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

コンテナレベルで提供されるセキュリティーは、XMLベースで記述されたセキュリティーポリシーにしたがって提供されます。

アプリケーションは変更を行うことなく、これらの設定にしたがってコンテナレベルの保護を受けます。

セキュリティー関連の設定は上記ファイルに反映されています。

web.xml

認証方式(Basic/Form/クライアント証明書)

セキュリティー制約(Security Constraint)

リソースコレクション --- URLとメソッドのセット

アクセスできるロール

RunAs設定

ejb-jar.xml

ロールと許可されているEJB, メソッド

RunAs設定

ibm_application_bind.xml

ロールとuser、groupのバインデング情報

50


50

SSL暗号化の流れ

暗号化仕様交渉

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

暗号化データ通信開始

this day o f , 199 ,

by

AA WARDWARD CC ERTIFICATEERTIFICATE

PPRESENT ED TO :

RESEN TED TO:

We a ppre ciate your contributions to our organiza tion. In re cogniti on of valuable achievements a nd ha rd work,

we gladly present thi s certificate of award.

CA's Signature

Type na me here

クライアントクライアントクライアントクライアント証明書証明書証明書証明書

サーバサーバサーバサーバ認証認証認証認証

クライアントクライアントクライアントクライアント認証認証認証認証

サーバ証明書送付

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

Client Server

FW

FW

SSLとはSecure Sockets Layerの略で、Netscape Communications社により開発されたプロトコルです。もともとSSLは、ソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではありません。しかし、現状はWebにおける認証および通信の暗号化に最も多く使用されています。SSLはTCP/IPの上で実現され、その上でHTTPやLDAPなどのアプリケーションプロトコルが動いています。

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

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

サーバーサーバーサーバーサーバー認証認証認証認証

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

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

ウェブサイトと証明書のサーバ名（コモンネーム）が一致、証明書のステータスがValid（有効）となっていれば、サーバ証明書によって該当ページが認証されているといえます。

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

クライアントクライアントクライアントクライアント認証認証認証認証

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

<クライアント証明書>

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

証明書はさまざまな認証局から入手することができます。サーバ側が信頼していない認証局から発行された証明書を持っていても、そのサーバにはアクセスできません。

51

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

受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへリクエストを転送します。

HTTPプラグインとも呼ばれます

○HTTPトランスポート

Webサーバープラグインから送られてくるHTTP通信の受け口です。問題切り分けのために直接アクセスすることもあります。

WebサーバープラグインとHTTPトランスポート間でSSLの設定が可能です。

例えば、サーバー認証をする場合を考えて見ましょう。

① WAS 用のサーバー・キーファイル（例 ServerKey.jks）を作成して証明書をファイル（例 ServerKeyCert.arm）に抽出します。

② IHS プラグイン用のキーファイル（plugin-key.kdb）がデフォルトではありますので、サーバー・キーファイルから抽出した証明書「ServerKeyCert.arm」を追加します。

＊IHSのプラグインキーファイルは新規に作成することも出来ます。その際は、plugin-cfg.xmlを変更する必要があります。


51

IHS-WAS間で行うSSL通信

Application Server

Webサーバー

Webコンテナー

Webサーバー

プラグイン

HTTPトラン

スポート


EJBコンテナー


Webサーバープラグイン

Webサーバーのプロセス内で稼働し、アプリケーション・サーバーへの要求をフォワード

WebサーバープラグインとHTTPトランス

ポート間でSSLの設定も可能

Webサーバープラグインには

plugin-key.kdbというキーファイルがあり、

WASから抽出した証明書を追加することで、

SSL通信を行うことができます。

pluginKey.kdb

サーバーサーバーサーバーサーバー証明書証明書証明書証明書

追加

52


52

練習問題

9. 管理管理管理管理コンソールコンソールコンソールコンソールをををを使用使用使用使用してしてしてして、、、、WASのののの構成変更構成変更構成変更構成変更、、、、アプリケーションアプリケーションアプリケーションアプリケーションのののの起動起動起動起動/停止停止停止停止をををを行行行行うううう必要必要必要必要がありますがありますがありますがあります。。。。必要必要必要必要なななな管理役割管理役割管理役割管理役割はははは次次次次のうちどれですかのうちどれですかのうちどれですかのうちどれですか？？？？

A. モニターB. コンフィギュレーターC. 管理者D. オペレーター

10. 複数複数複数複数サーバーサーバーサーバーサーバーででででセキュリティーセキュリティーセキュリティーセキュリティー・・・・ドメインドメインドメインドメインをををを形成形成形成形成しているしているしているしている場合場合場合場合、、、、使用使用使用使用できないできないできないできないユーザーユーザーユーザーユーザー・・・・レジストリーレジストリーレジストリーレジストリーはははは次次次次のうちどれですかのうちどれですかのうちどれですかのうちどれですか？？？？

A. ローカルOSB. LDAP ユーザー・レジストリーC. カスタム・ユーザー・レジストリー

<momo>

53


53

5章ワークロード管理

<memo>

54


54

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

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

管理コンソール

addNodeコマンド

wsadmin

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

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

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

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

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

追加されたノードの確認

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

デプロイメント・マネージャープロファイルとアプリケーション・サーバーした後、デプロイメント・マネージャーにアプリケーション・サーバーノードを統合します。

<作業の順序>

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

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

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

「ホスト」にアプリケーション・サーバーの稼動しているホスト名、「JMXコネクター・ポート」に77で定義した「SOAPコネクター・ポート」の番号を入力します。「アプリケーションを組み込む」をチェックして「OK」をクリックします。

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

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

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

別のWebブラウザから

http://<ホスト名>:xxxx/snoop

へアクセスします。結果が正常に表示されれば、アプリケーション・サーバーの起動は成功です。

55


55

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

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

クラスター・メンバー上では同じJ2EEアプリケーションを実行

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

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

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

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

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

WAS V6とV5 ノードの複合クラスターも可能

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とV5を組み合わせるということも可能となります。

56


56

クラスター設定

EJBコンテナーコンテナーコンテナーコンテナーWLMのののの際際際際のののの

ローカルノードローカルノードローカルノードローカルノード優先設定優先設定優先設定優先設定

HAマネージャーマネージャーマネージャーマネージャーにおけるにおけるにおけるにおける

パーシスタントパーシスタントパーシスタントパーシスタント・・・・サービスサービスサービスサービスののののフェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー設定設定設定設定（（（（トランログフェイルオーバートランログフェイルオーバートランログフェイルオーバートランログフェイルオーバー））））

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

新規にクラスターを作成し、そのクラスターにクラスター・メンバーとしてアプリケーション・サーバーを追加します。

クラスター設定では、EJBコンテナーへの負荷分散への際にEJBクライアントと同じノード上のEJBコンテナーへの負荷分散を優先させるという設定を行えます。また、HAマネージャーによるトランザクションログのフェイルオーバーの設定もクラスターメンバーでの引き継ぎとなりますので、クラスター設定において設定します。

クラスターの各メンバー設定では負荷分散の際の割り振りの重み付けを設定することができます。この数字が高いほどよりリクエストが割振られるということになります。

クラスターの構成方法については、8章のシステム管理もご参照ください。

57


57

クラスターによるワークロード管理(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のクラスター・メンバ

◆ 2種類のWLM ◆

WebコンテナーWLM：Webコンテナーへのリクエストに対するWLM

EJBコンテナーWLM：EJBコンテナーへのリクエストに対するWLM

クラスターを作成することによりクラスターメンバー間でのWorkLoadManagement(WLM)が有効になります。WLMによりクラスターメンバー間での負荷分散・障害時のフェイルオーバーが可能になります。

Webコンテナーへのリクエストに対するWLMをWebコンテナーWLMといいます。WebコンテナーWLMはWebコンテナー・サービスを実行するアプリケーション・サーバーをクラスター化することにより実現できます。また、EJBコンテナーへのリクエストに対するWLMをEJBコンテナーWLMといいます。 EJBコンテナーWLMはEJBコンテナー・サービスを実行するアプリケーション・サーバーをクラスター化することにより実現できます。

58


58

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と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエストはセッションIDが作成されたサーバーにリクエストを続けることが可能です。

59


59

SessionAffinity

ND構成では、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 V6 NDによるシステム構成をとることにより、WebコンテナーはHTTPセッションを作成したリクエストに対して、セッションIDと共にクローンIDを付与することになります。プラグインはクローンIDが付与されたリクエストを受け取ると、クローンID に紐付けられたアプリケーション・サーバーへ割り振りを行います。

この仕組みによりセッション情報をもつリクエストは、セッションオブジェクトの存在するサーバーへ続けてアクセスできます。この機能をSessionAffinityといいます。

60


60

EJBコンテナー WLM

EJBクライアントからの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コンテナーへリクエストを割振られます。

61


61

コア・グループ

セル内のJVMをグループピング

DM/ノード・エージェント/アプリケーション・サーバー

HA機能はコア・グループ単位で設定・実行

WLM情報等はコア・グループ内で共有される

シングルトン・サービスは同じコア・グループ内のメンバーへフェイルオーバーされる

コア・グループ作成ルール

セル内のJVMコンポーネントはいずれかのコア・グループに所属しなければならない

セル内のJVMコンポーネントは複数のコア・グループの所属できない

１つのセル内で複数のコア・グループを作成可能

セルをまたがったコア・グループの作成は不可

クラスター・メンバーは同じ１つのコア・グループにしか所属できない

１つのコア・グループに複数のクラスターは参加可能

同一または異なるセルのコア・グループ間でHA情報の共有は、コア・グループ・ブリッジ・サービスを使用する

セル内のJVM（DM・ノード・エージェント・アプリケーション・サーバー）をグルーピングするコア・グループを作成すると、HA機能はコア・グループ内で実施されます。

障害検知・情報共有/更新・シングルトンサービスの引継ぎはコア・グループメンバー間で実施されます。V6で提供されるシングルトンサービスの引継ぎはトランザクションログの引継ぎ・JMSメッセージの引継ぎの２つがサポートされています。これは同じコア・グループのメンバーであると共に、同じクラスターメンバーであるサーバーが引き継ぐことになります。

コア・グループを作成するために、次のようなルールがあります。

・セル内のJVMコンポーネントはいずれかのコア・グループに所属しなければならない

・セル内のJVMコンポーネントは複数のコア・グループの所属できない

・１つのセル内で複数のコア・グループを作成可能

・セルをまたがったコア・グループの作成は不可

・クラスター・メンバーは同じ１つのコア・グループにしか所属できない

・１つのコア・グループに複数のクラスターは参加可能

HAマネージャーは２つのコア・グループの連携を可能にします。同一もしくは異なるセルのコア・グループ間でHA情報の共有が可能となります。コア・グループ間のアクセスポイントとして特定のIP・Portを指定しますので、コア・グループ間にプロキシー・ファイアーウォールがある場合にも有効となります。

62


62

HTTPセッション・パーシスタンス

セッション情報を別の場所へ避難させることでセッションを維持する

アプリケーション・サーバー自身が提供する機能

アプリケーション・サーバー障害時にもセッション維持可能

メモリー間複製セッションDB

セッションオブジェクトｖ

セッション

DB

セッションオブジェクトｖ

セッション

セッション

他のAppServerのメモリー上にセッションオブジェクトのコピーを作成

セッションオブジェクトをDBに保管

(データベース・セッション・パーシスタンス）

HTTPセッション・パーシスタンスです。これはセッション情報を別の場所へと退避させることでアプリケーション・サーバー障害時にもセッションの維持を行なう方法で、アプリケーション・サーバー自身が提供する機能でした。WAS V6では他のアプリケーション・サーバーのメモリー上にセッション情報を複製するメモリー間複製(Memory to Memory)と、セッション情報をDBに保管する方法の2つがサポートされています。実績はDBの方が多くあります。（特に大規模な構成ほど）

重要なのは、セッション・オブジェクトの大きさで、大きな情報を入れるとパフォーマンスに悪影響します。また書き込む頻度も関係します。

アプリケーションではサイズの小さいセッション・オブジェクトを保存するようにすることが非常に重要です。（数10kもあると、パフォーマンスへの影響は大です）

63


63

HTTPセッション・メモリー間複製

HTTPセッション情報を複数のアプリケーション・サーバーに持つことで障害時のセッション処理に対するフェイルオーバーが可能

複製ドメイン設定でのレプリカの数と、アプリケーション・サーバー毎に設定するメモリー間複製設定で動作環境が決まる

ドメイン指定はアプリケーション・サーバー単位

アプリケーション・サーバー毎の複製モード設定

クライアントのみ – ローカルで作成・更新されたセッション情報をサーバーに送信

サーバーのみ - 他のアプリケーション・サーバーのセッション情報を受信

クライアントとサーバー両方 – クライアント・サーバー両方の動きをする

基本的に次の２つの動作環境がある

Peer to Peer各々のアプリケーション・サーバーが自分および他のアプリケーション・サーバーのセッション情報を保持する

アプリケーション・サーバー障害時、ホット・フェイルオーバーによりプラグインはレプリカを持っているサーバーに割り振る

Client/Serverクライアントのアプリケーション・サーバーは自分のセッション情報を保持し、他クライアントのアプリケーション・サーバーのセッション情報はサーバーのアプリケーション・サーバーに保持される

アプリケーション・サーバー障害時、障害サーバーのセッション・リクエストを受けたアプリケーション・サーバーは、サーバー指定されたアプリケーション・サーバーから該当セッション情報を取得する

DRS（Data Replication Service）は、クラスター配下のアプリケーション・サーバー間におけるデータ複製を提供します。DRS機能はアプリケーション・サーバー毎に稼動し、お互い連携することにより、データ複製を可能にします。複製ドメインとは、DRSを使用するアプリケーション・サーバーの集合です。この複製ドメイン内のDRS同士でデータの複製は実行されます。複製ドメイン設定では、１つのアプリケーション・サーバーがいくつのデータ・レプリカを別のアプリケーション・サーバーに作成するかを指定します。

次の３つの指定が可能です。

・単一レプリカ

デフォルトで使用されます。１つのデータに対して複製ドメイン内に１つのデータ・レプリカを保持します。

・ドメイン全体

複製ドメイン内の全てのサーバーが1つのデータに対するレプリカを保持します。

・指定

１つのデータに対していくつレプリカを持つかというのを数で指定可能です。

DRSを使用して、HTTPセッション情報を複数のアプリケーション・サーバーに持つことで、障害時のセッション処理に対するフェイルオーバーが可能となります。この機能を使用するために、アプリケーション・サーバーごとにメモリー間複製設定を行う必要があります。

メモリー間複製設定では、そのアプリケーション・サーバーがデータレプリカを送信するのみか、受信するのみか、またその両方かというのを指定します。また、メモリー間複製設定ではどの複製ドメインを使用するかというのを指定します。

ドメインに指定しているレプリカの数と、各アプリケーションの役割によってDRSの動作環境が決まります。動作環境には大きく分けて次の２つがあります。

・・・・Peer to PeerPeer to PeerPeer to PeerPeer to Peer

各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報を保持します。V6ではアプリケーション・サーバーの障害が発生すると、プラグインはレプリカのあるサーバーにリクエストを割り振る、ホット・フェイルオーバーが提供されます。

・・・・Client/ServerClient/ServerClient/ServerClient/Server

データレプリカの送信のみに指定されたクライアントと、受信のみに指定されたサーバーによってこの構成はとられます。アプリケーション・サーバー障害時に、セッションリクエストを受け取ったクライアントは、サーバーからセッション情報を取得しサービスを行います。

64


64

練習問題

11. 管理管理管理管理コンソールコンソールコンソールコンソールででででデプロイメントデプロイメントデプロイメントデプロイメント・・・・マネージャーマネージャーマネージャーマネージャーににににアプリケーションアプリケーションアプリケーションアプリケーション・・・・サーバーサーバーサーバーサーバー・・・・ノードノードノードノードをををを統合統合統合統合するするするする際際際際にににに必要必要必要必要のないのないのないのない作業作業作業作業をををを選択選択選択選択してくださいしてくださいしてくださいしてください。。。。

A. デプロイメント・マネージャーの起動B. Webサーバーの始動C.アプリケーション・サーバーの始動

12. HTTPセッションセッションセッションセッション・・・・メモリーメモリーメモリーメモリー間複製間複製間複製間複製でででで使用使用使用使用できるできるできるできる複製複製複製複製モードモードモードモード設定設定設定設定でででで指定指定指定指定できないものはできないものはできないものはできないものは次次次次のうちどれですかのうちどれですかのうちどれですかのうちどれですか？？？？

A. クライアントのみB. サーバーのみC. クラスターのみ

<memo>

65


65

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

<memo>

66


66

クラス・ローダーはクラスを検索し、ロードするための仕組み

WASでは階層構造をとる複数のクラス･ローダーを使用

この設定によりモジュールおよびクラスの可視性が決定される

クラス・ローダー分離ポリシー

アプリケーション・クラス・ローダー・ポリシー：アプリケーションの分離を制御

単一 (Single)複数 (Multiple)

WAR クラス・ローダー・ポリシー：Web モジュールの分離を制御

アプリケーション (Application)モジュール (Module)

クラス・ローダー・モード親が最初 (Parent First )親が最後 (Parent Last)

クラス・ローダーの設定

クラス・ローダーは、クラス・ファイルを検出し、ロードします。クラス・ローダーにより、サーバーにデプロイされたアプリケーションが、使用可能なクラスおよびリソースのリポジトリーにアクセスできるようになります。

WebSphere Application Server のクラス・ローダーは以下の階層構造となっています。1．Java 仮想マシンで作成される、ブートストラップ、拡張、および CLASSPATH のクラス・ローダー。2．WebSphere 拡張クラス・ローダー3．アプリケーション・モジュール・クラス・ローダー4．Web モジュール・クラス・ローダー（各クラス・ローダーは、直前のクラス・ローダーの子になっています。）

また、アプリケーションとモジュールの分離を制御するための設定が、アプリケーション・クラス・ローダー・ポリシーと、WAR クラス・ローダー・ポリシーになります。アプケーションアプケーションアプケーションアプケーション・・・・クラスクラスクラスクラス・・・・ローダーローダーローダーローダー・・・・ポリシーポリシーポリシーポリシー（アプリケーション・サーバー単位に設定）・単一(Single)…アプリケーション・クラス・ローダーを複数のアプリケーションで共用する（アプリケーションは分離されない）・複数(Multiple)…アプリケーション・クラス・ローダーをアプリケーションごとに固有にする（アプリケーションは互いに分離される）WAR WAR WAR WAR クラスクラスクラスクラス・・・・ローダーローダーローダーローダー・・・・ポリシーポリシーポリシーポリシー（エンタープライズ・アプリケーション単位に設定）・アプリケーション(Application)…Webモジュールの内容も、アプリケーション・クラス・ローダーによってロードされる・モジュール(Module) …各Webモジュールは、アプリケーション・クラス・ローダーを親に持つ独自のクラス・ローダーを持つ

また次のクラスクラスクラスクラス・・・・ローダーローダーローダーローダー・・・・モードモードモードモードが提供されています。・親が最初(Parent First)…クラス・ローダーは、ローカル・クラス・パスからクラスのロードを試行する前に、親クラス・ローダーにクラスのロードを委任します。（デフォルト）・親が最後(Parent Last)…クラス・ローダーが、クラスのロードをその親に委任する前に、クラスをそのローカル・クラスパスからロードしようとします。

クラス・ローダーの詳細については、InfoCenterのクラス・ロードの章をご参照ください。http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/trun_classload.html

67


67

システムのバックアップ方法

バックアップの取得が必要と考えられるタイミングインストール直後

Fix Pack適用前・後

構成情報の変更前・後

バックアップ方法backupConfigコマンドを使用

コマンドを実行するプロファイルの構成ファイルである<Profile_root>¥configディレクトリー配下をzipファイルにアーカイブ

使用方法：backupConfig <backup_file> [options]

[options]

----nostopnostopnostopnostop ：：：：構成のバックアップ前にサーバーを停止しないように指示

----quiet quiet quiet quiet ：：：：通常モードで出力される進行情報を抑止

----logfilelogfilelogfilelogfile <<<<fileNamefileNamefileNamefileName> > > > ：：：：情報を書き込むログ・ファイルのロケーションを指定

----profileNameprofileNameprofileNameprofileName <<<<profileNameprofileNameprofileNameprofileName>>>> ：：：：マルチプロファイル・システムで、プロセスを指定

----replacelogreplacelogreplacelogreplacelog ：：：：現行ログに追加する代わりに、ログ・ファイルを置き換える

----trace trace trace trace ：：：：デバッグのために、ログ・ファイルにトレース情報を生成する

ディレクトリーのコピー<WAS_root>ディレクトリー配下のすべてのファイルをzipなどでバックアップする

バックアップの取得が必要と考えられるタイミングは以下のようなときです。WASのインストール直後、Fix Pack適用前・後、管理コンソールやwsadminによる構成情報の変更前・後

アプリケーション・サーバーの作成、データ・ソースの設定などのパラメータ変更、アプリケーションのインストールなどを実施し、管理コンソールでマスター構成リポジトリーの保管を実施するとき、また、Webサーバー定義の作成・削除を行うときにはバックアップを取得します。

WASの構成情報のバックアップを行うには、backupConfigコマンドを使用します。このコマンドを実行することにより、構成リポジトリー情報である<Profile_root>¥configディレクトリ配下のサブフォルダ、ファイルをzipファイルにアーカイブします。backupConfigコマンド実行時にバックアップファイル名を指定することも可能です。バックアップファイル名を指定しない場合はコマンドを実行したディレクトリーに「WebSphereConfig_yyyy-mm-dd.zip」という名前で作成されます。backupConfigコマンドのその他のオプションの詳細についてはInfoCenterの「backupConfigコマンド」を参照ください。http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_backupconfig.html

backupConfigコマンドの使用における注意点として、以下のような点があります。・構成リポジトリー以外にもバックアップが必要なファイルがあります。・DMとそれぞれのノードで個々にバックアップが必要です。backupConfigコマンドで取得したバックアップ情報はホスト名/IPアドレスが異なるマシンではリストアできませんので、複数マシン構成の場合、それぞれのノードでバックアップを行う必要があります。また、DMとノード・エージェントが1台のマシンに同居している場合でも、DMの構成リポジトリーのバックアップとノードの構成リポジトリーのバックアップをそれぞれ行う必要があります。・バックアップ取得時には、自動的に各ノードのDM、ノード・エージェント、アプリケーション・サーバーのプロセスが停止されます。backupConfigコマンドの-nostopオプションを使用して、プロセスを停止せずにバックアップを取得することもできますが、バックアップ取得時にマスター構成リポジトリーが変更されると不整合が発生し、リストアできませんので、注意が必要です。・バックアップ取得時に停止されたプロセスは自動的には起動しませんので、バックアップ終了後、手動で起動する必要があります。

backupConfigコマンドを使用する以外にも、WASが導入されているディレクトリーをZIPなどで全てバックアップする方法もあります。

68


68

リストア方法

restoreConfigコマンドを使用

backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元

使用方法：restoreConfig <backup_file> [options]例： <Profile_root>¥bin¥restoreConfig myBackup.zip

注意点

構成リポジトリー以外のバックアップファイルの復元も必要

同一ホスト名のマシンに対してのみリストア可能

BackupFile(.zip)

hostA

backupConfig

restoreConfigホスト名の異なるマシンにはリストア不可能！

hostB

WASの構成情報のリストアを行うには、restoreConfigコマンドを使用します。このコマンドを実行することにより、backupConfigコマンドで取得したzipファイルから各ノードの構成リポジトリーを復元します。リストア時には、リストア対象ファイルを必ず指定してください。restoreConfigコマンドのオプションの詳細についてはInfoCenterの「restoreConfigコマンド」を参照ください。http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_restoreconfig.html

restoreConfigコマンドの使用における注意点として、以下のような点があります。・構成リポジトリー以外のバックアップファイルの復元も必要です。・リストアは同一ホスト名のマシンにおいてのみ可能です。

既存の構成ディレクトリが存在している場合、既存のディレクトリの名前が変更されてから復元が開始されます。実行例では既存の<Profile_root>¥configディレクトリが<Profile_root>¥config.old_1に変更されてから復元が始まっています。

69


69

キューイング・ネットワーク

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシス

テムで相互関連するコンポーネントをキューイング･ネットワークと呼ぶ

キューイング･ネットワークに関連するパラメーターを調整し、最大スループットを達成することがパフォーマンスチューニングの第一歩

それぞれの入り口で待ち処理が発生するように絞り込むように調整

DB

ブラウザー

Webコンテナスレッドプールサイズ

ORBスレッドプール･サイズ

Webサーバー MaxClients / ThreadPerChild

データソース最大接続数

WebコンテナASWebサーバー

EJBコンテナAS

それぞれの入り口で待ち処理が発生するように絞り込むように調整

Webサーバーからデータベースなどのリソース･アクセスまで含めたエンド･トゥー･エンドのシステムで相互関連するコンポーネントをキューイング･ネットワークと呼びます。キューイング･ネットワークに関連するパラメーターを調整し、最大スループットを達成することがパフォーマンスチューニングの第一歩になります。

キューイング･ネットワークでは原則クライアントに近い側の同時接続パラメーターを大きく、リソース･マネージャーに近い側を小さく設定します。これによりシステムが過負荷にならない、かつ各コンポーネントは適量の待ち処理を継続処理できるようにしてスループットを最大化することが出来ます。

70


70

EJB Persistence

H TTPC lient

JSP s

DatabaseS ession

E JB

serv le ts

Session Entity

EJBs

HTTPSession

JVM

CM P

-Servlet/JSP平均応答時間

-Servlet/JSPリクエスト数

：

WebWebWebWebアプリケーションアプリケーションアプリケーションアプリケーション

セッションセッションセッションセッション・・・・マネージャーマネージャーマネージャーマネージャー

-アクティブ・セッション数

-セッション・サイズ

-無効セッション数

：

EJB ModuleEJB ModuleEJB ModuleEJB Module

-EJB応答時間

-EJBリクエスト数

：

DBDBDBDB接続接続接続接続プールプールプールプール

-使用ﾌﾟｰﾙ%

-平均待ち時間

：

JVM ModuleJVM ModuleJVM ModuleJVM Module

-ヒープサイズ

-GC統計情報

：

スレッドスレッドスレッドスレッド・・・・プールプールプールプール

-プール・サイズ

-アクティブ・スレッド数

：

Transaction ModuleTransaction ModuleTransaction ModuleTransaction Module

-アクティブ・トランザクション数

-トランザクション・タイムアウト

：

モニタリング・ツール : Tivoli Performance ViewerWASが提供するパフォーマンス・モニタリングの仕組み

各種のシステム測定値を取得し、管理コンソールに結果を表示

ユーザーが取得するコンポーネントおよびレベルを選択可能

WASではアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークとしてPMI（Performance Monitoring Infrastructure）を提供しています。WASでは各リソースの様々なパフォーマンスデータをMBeanに格納しており、PMIはこのMBeanと通信して必要なパフォーマンスデータを取得します。パフォーマンス・データを格納しているMBeanは複数あり、それぞれ固有のデータを持っています。Tivoli Performance Viewer (TPV)はこのPMIを介して、WASの各リソースのパフォーマンス・データを取得しています。

TPVは管理コンソールの一メニューとして使用可能で、ブラウザー・アクセスが可能なクライアントであればアクセスできるようになっています。

TPVにアクセスするためには「モニターおよびチューニング」→「Performance Viewer」からアクセスします。TPVには［現行アクティビティ］と［ログの表示］の二つのモードがあります。どちらかを選択した上で、TPVとしてモニターするプロセスを選択します。この際にチェックを付けることで複数のプロセスの情報を取得開始することも可能ですが表示は一プロセス単位になります。管理コンソールからログオフするとモニターは停止します。

71


71

JVMの役割-メモリ管理

ガーベージガーベージガーベージガーベージ・・・・コレクションコレクションコレクションコレクション（（（（GC））））

JavaではJVMがメモリ管理を実施

不要になったオブジェクトをメモリ領域から開放

アプリケーション開発者のメモリ管理作業を軽減、ソフトウェア品質の向上

参照されないオブジェクトが残ってしまうことによるメモリリークの回避

まだ参照されているオブジェクトを消去してしまうランタイムエラーの回避

GC処理中は全てのアプリケーション・スレッドは停止

GCはアプリケーションのパフォーマンスに影響

JVMが適切にGCを実施するよう調整が重要

メモリー空間

必要なｵﾌﾞｼﾞｪｸﾄ必要な

ｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

必要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

不要なｵﾌﾞｼﾞｪｸﾄ

Merit

重要

JVMの重要な役割として、メモリ管理があります。Javaでは、一般にガーベッジ・コレクション (GC) と呼ばれる、不要になったオブジェクトをメモリ領域から開放する作業をJVMが行っています。

これにより、アプリケーション開発者は煩雑なメモリ管理のコードをプログラム中に記述する必要がなくなります。また、参照されないオブジェクトがメモリ内に残ってしまうことによるメモリリークや、逆にまだ参照されているオブジェクトを消去してしまうことにより発生するランタイムエラーなどのバグを回避することができますので、ソフトウェア品質の向上するという利点があります。

GCはアプリケーションのパフォーマンスに影響を与えますので、JVMが適切にGCを処理を行うように設定することが重要です。

72


72

JVM ヒープサイズの調整JVMが使用するメモリ領域

Java heapクラスやインスタンスのオブジェクトが格納

Garbage Collectionの対象エリア

WASでは、デフォルトで最小50MB、最大256MBに設

定されている

Native heapJVMの起動時に常に参照される、システムや共有プロ

グラムのクラスオブジェクトが格納

ヒープサイズの設定値によって、GCの

処理時間や間隔を調整

ヒープサイズの設定値によって、GCの

処理時間や間隔を調整

Heapとは、JVM、つまりJavaアプリケーションが使用できるメモリ領域です。HeapはJava heapとNative heapの2種類の領域に分かれます。

Java heapはオブジェクトが格納されるメモリ領域であり、GCの対象エリアになります。

Native heapはJVMの起動時に常に参照される、システムや共有プログラムのクラスオブジェクトが格納されるメモリ領域であり、GCの対象になりません。

Java heapの最小サイズ・最大サイズは、JVM引数 (WASでは、管理コンソール上の設定)で、設定することができます。WASのデフォルト値はプラットフォームによらず最小50MB、最大256MBとなります。管理コンソールで「アプリケーション・サーバー」＞（サーバー）＞「プロセス定義」＞「Java仮想マシン」から設定することが可能です。

実際のWASの環境においては、各アプリケーション・サーバーがそれぞれ異なるJVMを起動していますので、それぞれ別々のheap領域を確保する必要があります。また、各JVMは明示的に設定できるJava heapに加えて、Native heapが必要になりますので、注意が必要です。

このヒープサイズの最小・最大サイズによってGCの間隔や処理時間を調整し、GCがパフォーマンスに与える影響を少なくします。

一般に、ヒープを大きく設定すると、GCが発生するまでの間隔は長くなりますが、GCにかかる時間が長くなりますので、環境に合わせて調整が必要となります。

73


73

プラグインの管理

Webサーバー・プラグインは、次のような場合、更新が必要

新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合

サーブレットに対するURLマッピングの定義など、URIに変更があった場合

新しいクラスターが追加され、ルーティング方法が変更になった場合

ポート番号が変更になった場合

仮想ホストの追加や修正があった場合、など。

正しくリクエストが割り振れない場合のチェック項目

Web サーバー・プラグイン構成の更新をしているか

Web サーバー構成ファイルの設定は正しいか

Webサーバー構成ファイルの中に記述されているplugin-cfg.xmlの位置が正

しく設定されているかどうかを確認する

編集したplugin-cfg.xmlが変更されていないか

plugin-cfg.xmlを手で書き換えている場合、同期により修正が失われる

最新のFixが当たっているか

次のような場合は、プラグイン構成ファイルの更新と伝搬が必要となります。!新しいWebアプリケーションの導入など、コンテキストルートに変更があった場合!サーブレットに対するURLマッピングの定義など、URIに変更があった場合!新しいクラスターが追加され、ルーティング方法が変更になった場合!ポート番号が変更になった場合!仮想ホストの追加や修正があった場合、など。

プラグイン構成ファイルの伝搬方法については、2章をご参照ください。

正しくリクエストが割り振られていない場合のチェック項目として、いくつか挙げます。

・上記の修正が入った場合に、正しくプラグイン構成ファイルが更新、伝搬されているかどうかを確認します。

・Webサーバーの構成ファイルhttpd.confの中に記述されているプラグイン構成ファイルplugin-cfg.xmlの位置は正しく設定されているかどうかを確認します。

・plugin-cfg.xmlファイルを手で書き換えている場合、デプロイメント・マネージャーの構成ファイル同期サービスにより、Webサーバー・プラグイン構成の更新で生成された状態に戻ってしまうことがあります。

・製品の障害などを修正するためのFixなどもありますので、最新版があたっているかどうかも確認します。

74


74

練習問題13. アプリケーションアプリケーションアプリケーションアプリケーション・・・・クラスクラスクラスクラス・・・・ローダーローダーローダーローダーとととと、、、、WARののののクラスクラスクラスクラス・・・・ローダーローダーローダーローダーをををを分離分離分離分離するためのするためのするためのするための設定設定設定設定はどこではどこではどこではどこで

行行行行いますかいますかいますかいますか。。。。

A. アプリケーション・クラス・ローダー・ポリシー設定（単一/複数）B. WAR クラス・ローダー・ポリシー設定（アプリケーション/モジュール）C. クラス・ローダー・モード設定（親が最初/親が最後）

14. Tivoli Performance Viewerにおいてにおいてにおいてにおいて、、、、Webアプリケーションアプリケーションアプリケーションアプリケーションののののパフォーマンスパフォーマンスパフォーマンスパフォーマンスををををモニモニモニモニターターターターするためにするためにするためにするために有効有効有効有効なななな項目項目項目項目をををを次次次次のののの中中中中からからからから１１１１つつつつ選選選選びなさいびなさいびなさいびなさい。。。。

A. サーブレットの平均応答時間B. JVMの使用メモリーC. 平均CPU使用率

15. Webサーバーサーバーサーバーサーバー・・・・プラグインプラグインプラグインプラグイン構成構成構成構成ファイルファイルファイルファイル(plugin-cfg.xml)のののの再生成再生成再生成再生成がががが必要必要必要必要になるになるになるになるケースケースケースケースをををを、、、、次次次次のののの中中中中からからからから１１１１つつつつ選選選選びなさいびなさいびなさいびなさい。。。。

A. Webアプリケーションが追加された場合B. Webコンテナのスレッドプール・サイズが変更になった場合C. Webコンテナで設定するHTTPセッションのタイムアウト値が変更になった場合

<memo>

75


75

7章問題判別

<memo>

76


76

ログの種類 (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とはエラー情報を発生時に自動記録する機能。サポートセンター、開発部門が障害対応時に見るログ。

循環ログ

構成不可

アナライザー

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ログに詳細情報を追加したログで、ログ・アナライザーというGUIツールを使用して読み取ります。（ログ・アナライザーが使用できない場合は、showLogコマンドを使用します。）

77


77

プロファイル単位の/logsディレクトリ

WAS関連

/logs以下に/ffdcディレクトリ

IBM保守ログ

JVMログ

プロセス・ログ

/logs以下にサーバー単位のディレクトリ

HTTPトランスポートログ

FFDCログ

ログのロケーション (1) WAS関連

前項で解説したログの実際のロケーションを表したチャートです。

78


78

ログの種類 (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ファイル内で指定されてます。管理コンソールのプラグイン・プロパティの設定でプラグイン・ログのレベルや出力先を変更することができます。当資料の37ページを参照してください。

WebサーバーとしてIHSを使用している場合、IHSの構成ファイルhttpd.confの中のWebSpherePluginConfigディレクティブでplugin-cfg.xmlファイルの位置が指定されており、plugin-cfg.xmlファイルでプラグイン・ログファイルの位置が指定されています。

ブラウザーから実行されるリクエストはIHSログ、プラグインログ、HTTPトランスポートログ、JVMログ・・・という順に記載されていきます。

79


79

ログのロケーション (2)IHS、プラグイン関連

Pluginの/logsディレクトリにWebサーバー単位のディレクトリ

IHSの/logsディレクトリ

httpアクセス・ログ

httpエラー・ログ

プラグイン・ログ

IHS導入ディレクトリ

プラグイン導入ディレクトリ

前項で解説したログの実際のロケーションを表したチャートです。

80


80

ログの管理ログ管理機能

管理コンソールの「トラブルシューティング」→「ログおよびトレース」からサーバーを指定して、各ログの循環設定、ファイル最大サイズなどを設定可能

JVMログでは世代管理も可能

使用中ファイル…SystemOut.log

一世代前………. SystemOut_03_01.15_17.38.19.log

(SystemOut_yy_MM.dd_HH.mm.ss.log)

世代管理は一定時間、一定サイズで行う

考慮点

本番稼働環境では、ファイルの最大サイズや世代交代などの設定、

さらに運用により、WAS停止のタイミングでログを待避させる

基本的に、WASが出力するログは問題判別用長期的にわたって保存しておく必要はない

逆に、ログファイルが大きすぎると問題判別の際見づらくなるので、適切な最大サイズ設定やこまめに待避させる運用を心がける

WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）から各ログの循環設定やファイル最大サイズの指定などを行うことができます。ログの世代管理も可能で、一定時間と一定サイズのどちらか、または両方を選択することができます。両方を選択した場合は、両方のタイミングで循環が実行されます。また、ヒストリー・ログ・ファイルの最大数として、残しておく過去のログの数を指定することもできます。また、「インストール済みアプリケーション出力」の設定によって、アプリケーションから出力されるSystem.outおよびSystem.errのメッセージを抑制することも可能です。

システム管理者が考慮すべきログ管理としては、本番稼動環境におけるファイルの最大サイズや世代交代の設定があります。基本的にはWASが出力するログは問題判別用なので、長期的にわたって保存しておく必要がありません。適切な最大サイズ設定やこまめに退避させる運用を心がける必要があります。WASの稼動中にログを退避させることはできませんので、循環されないログについてはWAS停止のタイミングでログを退避させる運用とします。

81


81

トレース(trace.log)<Profile_root>¥logs¥<server_name>¥trace.log

WASのコンポーネントの詳細な実行内容を追跡可能

基本的にWASの開発部門の指示で問題の再現時に有効にする

世代管理可能世代管理可能

コンポーネントとトレースの詳細レベルを指定コンポーネントとトレースの詳細レベルを指定

WASではコンポーネントの詳細な実行内容をサーバーごとにトレースファイルに出力させることができます。<Profile_root>¥logs¥<server_name>¥trace.logファイルに出力されます。コードを実行するたびに対象コンポーネントがトレースに情報を出力するため、問題判別のためのイベントの追跡ができます。基本的に、トレースを出力させるのはWASの開発部門の指示で問題の再現時であり、トレース内容はWASのテクニカルサポートの助けがないと内容を調査することは難しいです。コンポーネントのソースコードをもとにトレースを分析すれば、問題がどのコンポーネントのどの部分にあるかを絞り込むことができます。デフォルトでトレースは使用可能になっています。

WASの管理コンソール「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「診断トレース」からトレースの循環設定やファイル最大サイズの指定などを行うことができます。トレース出力フォーマットは、「基本（互換）」「拡張」「ログ・アナライザー」の3種類が選択できます。また上記管理コンソール画面の「ログを使用可能にする」のチェックをはずすとトレースは出力されなくなります。アプリケーション・サーバーが稼動中であってもこの設定を変更することが可能です。「診断トレース・サービス」ページのランタイム・タブでの変更はアプリケーション・サーバーが稼動中であっても可能で、「OK」ボタンによって反映されます。「トラブルシューティング」＞「ログおよびトレース」＞（サーバー名）＞「ログ詳細レベルの変更」からトレースの設定として取得したいコンポーネントとイベントの種類を選択して設定することができます。設定方法の詳細についてはInfoCenterの「ログ・レベル設定」をご参照ください。http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.nd.doc/info/ae/ae/utrb_loglevel.html

82


82

ログ / トレースのフォーマット

基本フォーマット日付，時刻，タイムゾーンメッセージを出力したスレッドの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文字の英字で表記され、起こったイベントのタイプを表します。メッセージ・タイプは大文字で表記され、トレース・タイプは小文字で表記されます。

83


83

FFDC

FFDC（First Failure Data Capture)すべてのシステムエラー情報を発生時点で自動的に記録する機能

<プロファイル>/logs/ffdcに存在

FFDCにより生成される2種類のファイル

Exception.log（サーバーごとの例外情報の統計）

<ServerName>_exception.logServer1_exception.log .etc

インシデントストリーム（例外発生時点で取られる）

<ServerName>_<thread id>_<timeStamp>_<SequenceNumber>.txtserver1_7412857d_05.10.10_13.08.16_0.txt .etc

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 製品のパフォーマンスには影響を与えません。

84


84

javacore（スレッド・ダンプ）の取得方法javacore

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には、native stack、java stack、環境情報などがテキストファイルで出力されます。synchronizedなどの排他制御で使用されるJavaのモニター情報も取得できますので、デッドロックの調査に有効です。

javacoreは、プロセスが異常終了したときに自動生成されるだけではなく、外部からの指示による強制取得もできます。WebSphereのjavaプロセスの場合は、wsadminで取得することができます。Unixでは、”kill –QUIT <PID>”コマンドまたは”kill -3 <PID>”コマンドでも取得することができます。

通常、クラッシュの場合はIBMサポート部門にCoreを送付して解析してもらうことになりますが、javacore.txtを参照することによって、現場担当者がその問題判別をすることもできる場合があります。

85


85

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 ] ネームスペースのダンプの開始点

dumpNameSpaceとは、ネームサーバーを介してアクセスしたネームスペースの内容をダンプするユーティリティ・ツールであり、<プロファイル名>/bin/dumpNameSpace.bat(sh)から実行することができます。NamingExceptionが発生したときに実行して確認します。

各プロセスは個別にネームスペースを持っており、それぞれのネームスペースをdumpNameSpaceコマンドでダンプさせるときは、ネームスペースを出力したいプロセスのブートストラップ・ポートを指定します。リソースは、そのリソースを使用するアプリケーションが稼動するプロセスのネームスペースに登録します。例えば、DS1というデータソースを登録する際、そのDS1を使用するアプリケーションがserver1で稼動する場合は、server1のネームスペースにDS1を登録する必要があります。そしてその場合、dumpNameSpaceコマンドでserver1のブートストラップポートを指定した結果でDS1が見つからなければなりません。

dumpNameSpaceコマンドのオプションとして、接続先ホスト名やネームスペースを出力したいプロセスのブートストラップ・ポート、ネームスペースのダンプの開始点などを指定することができます。

86


86

練習問題16. 次次次次ののののログログログログ・・・・ファイルファイルファイルファイルのののの中中中中でででで、、、、管理管理管理管理コンソールコンソールコンソールコンソールからからからからヒストリーヒストリーヒストリーヒストリー・・・・ログログログログ・・・・ファイルファイルファイルファイル数数数数をををを指定指定指定指定しししし、、、、世代管世代管世代管世代管

理理理理ができるものをができるものをができるものをができるものを１１１１つつつつ選選選選びなさいびなさいびなさいびなさい。。。。

A. プロセス・ログB. JVMログC. IBM保守ログ

17. activity.logファイルファイルファイルファイルをををを調調調調べるためにべるためにべるためにべるために使用使用使用使用するするするするツールツールツールツールのうちのうちのうちのうち、、、、間違間違間違間違っているものをっているものをっているものをっているものを１１１１つつつつ選選選選びびびびなさいなさいなさいなさい。。。。

A. ログ・アナライザーB. showlogコマンドC. Tivoli Performance Viewer

18. javacore（（（（スレッドダンプスレッドダンプスレッドダンプスレッドダンプ））））のののの取得方法取得方法取得方法取得方法についてについてについてについて、、、、正正正正しいものをしいものをしいものをしいものを1つつつつ選選選選びなさいびなさいびなさいびなさい。。。。

A. 管理コンソールから診断トレースを設定するB. wsadminから$AdminControl invoke dumpThreadsを実行するC. FFDC(First Failure Data Capture)ツールを使用する

<memo>

87


87

8章システム管理

<memo>

88


88

クラスターの作成と設定

管理コンソールにてクラスターを新規に作成して設定を行うには以下の3ステップが必要

Step 1．基本クラスター情報の入力

Step 2．クラスター・メンバーの作成

Step 3．要約の確認と保管

◆V6新機能であるクラスターの作成と設定を行う際の手順と概要◆

クラスター名の入力クラスター名の入力

クラスターを既存サーバーで構成するかどうか

クラスターを既存サーバーで構成するかどうか

アプリケーションアプリケーションアプリケーションアプリケーション・・・・サーバーサーバーサーバーサーバー毎毎毎毎にににに重重重重みみみみ付付付付けのけのけのけの値値値値をををを設定設定設定設定：：：： 0～～～～20アプリケーションアプリケーションアプリケーションアプリケーション・・・・サーバーサーバーサーバーサーバー毎毎毎毎にににに重重重重みみみみ付付付付けのけのけのけの値値値値をををを設定設定設定設定：：：： 0～～～～20 「server2」がクラスター・メン

バーに追加された状態

「server2」がクラスター・メン

バーに追加された状態

Step 1 Step 3Step 2

要約を確認して終了ボタンを押下このあと「保管」を実施

要約を確認して終了ボタンを押下このあと「保管」を実施

管理コンソールから新規クラスターを作成する操作は、「サーバー・クラスター」ページで「新規作成」ボタンを押してから３ステップで行います。

Step1.Step1.Step1.Step1.基本クラスター情報の入力として以下を設定します。

・クラスター名：新規クラスターの名前を入力します。

・ローカルを優先：EJB WLMにおいて、EJBクライアントからのリクエストが同一プロセスで稼動するEJBコンテナーに優先して割り振られるかどうかの設定です。ローカルを優先することによって、パフォーマンスが向上します。

・複製ドメインを作成するかどうか設定します。

・既存サーバー：空のクラスターを作成するか、既存のアプリケーション・サーバーをクラスターに追加するかを指定します。既存のアプリケーション・サーバーをクラスターに追加する場合、そのアプリケーション・サーバーは他のクラスター・メンバーのテンプレートとなります。アプリケーション・サーバーをクラスターに追加した場合、クラスターから除去するためにはアプリケーション・サーバーを削除することになるので注意してください。

・ウェイト：クラスターに対するWLMにおける、サーバーのウェイト値を指定します。値は0から20まで設定可能です。0に設定した場合、割り振り可能な唯一のアプリケーション・サーバーにならない限りは割り振られません。

Step2.Step2.Step2.Step2. クラスター・メンバーを追加します。新規クラスター・メンバーの追加ごとに以下の設定を行います。

・メンバー名：クラスターに追加する新規クラスター・メンバー（アプリケーション・サーバー）の名前を入力します。

・ノードの選択：サーバーを配置するノードを選択します。

・ウェイト：サーバーのウェイトを指定します。

・固有HTTPポートそ生成するかどうかを指定します。

Step3.Step3.Step3.Step3. 要約が表示されるので、内容を確認して、「終了」ボタンを押します。構成の保管も実行します。

「サーバー・クラスター」ページ（「サーバー」＞「クラスター」）ではセル内のクラスターとその稼動状況を確認することができ、クラスターに対して、始動/停止、ripple始動、強制停止が可能です。クラスターに対するこれらの操作はクラスターのメンバーであるすべてのサーバーに対しての操作となります。ripple始動は、各クラスター・メンバーを停止した後に再始動を行います。

「クラスター・メンバー」ページ（「<Clusters_name>」＞「クラスター・メンバー」）では、クラスター・メンバーであるアプリケーション・サーバーの稼動状況を確認でき、メンバーごとに始動/停止の操作が可能です。また、クラスターに新規メンバーを追加したい場合は、「新規作成」ボタンから追加することができます。

89


89

WLM (Webコンテナー /EJBコンテナー)◆Webサーバー・プラグインを経由するWebコンテナーへのリクエストに対して提供

◆Webコンテナーのクラスター化により実現

◆Webコンテナーへのルーティングテーブルは「「「「plugin-cfg.xml」」」」が提供◆割り振りの手法は ”重重重重みみみみ付付付付けけけけラウンドロビンラウンドロビンラウンドロビンラウンドロビン”を使用

-アプリケーション・サーバーに重み付けをし、それに基づいて割り振る

◆プライマリー/バックアップサーバー・リスト-アプリケーション・サーバーに対しプライマリーとバックアップの指定-プライマリー指定のアプリケーション・サーバー障害時にバックアップサー

バーに割り振る

◆セッションIDを持つリクエストに対しては”SessionAffinity機能機能機能機能”により同一サーバーに割り振る⇒クラスター・メンバーには”Clone ID”がアサインされる。

WebServerWebServerPlug-in

WebContainer

WebContainer

WebContainer

WebContainer

WebContainer

WebContainer

Cluster

◆ EJBクライアントからのEJBコンテナーへのリクエストに対して提供

◆ EJBコンテナーのクラスター化により実現

◆ EJBクライアントとEJBコンテナーは別プロセスでなければならない-同一プロセスの場合、”Server Affinity機能機能機能機能”により別プロセスのEJBコ

ンテナーへは割り振られない

◆割り振りの手法は”重重重重みみみみ付付付付けけけけラウンドロビンラウンドロビンラウンドロビンラウンドロビン”を使用-アプリケーション・サーバーに重み付けをし、それに基づいて割り振る

◆「ローカルを優先」設定により、同一ノードのEJBコンテナーを優先することも可能

◆ “Transaction Affinity”により同じトランザクション内のリクエストは同じサーバーに割り振る

EJBClientEJBClientORBWLM

Plug-in

EJBContainer

EJBContainer

EJBContainer

EJBContainer

EJBContainer

EJBContainer

Cluster

WebコンテナーWLMはクラスターメンバーがWebコンテナーサービスが稼動することで実現します。Webサーバー・プラグインを経由するWebコンテナーへのリクエストに対して負荷分散、フェイルオーバーの機能を実施します。Webコンテナーがリクエストをどのサーバーにどのように割振るかというルーティングテーブルはplugin-cfg.xmlに記述されます。Webサーバープラグインはそのファイルを見てリクエストを割り振ります。

負荷分散のロジックはクラスターメンバー設定におけるウェイトに従った重み付けラウンドロビンを使用しています。また、クラスターメンバーとなるアプリケーション・サーバーに対しプライマリーかバックアップの指定をすることが可能です。バックアップ指定のサーバーはプライマリーサーバー障害時にのみサービスを提供することになります。

WebコンテナーWLMではV5と同様にSessionAffinityの機能を提供します。これによりセッションIDを持つリクエストはセッションIDが作成されたサーバーにリクエストを続けることが可能です。

EJBコンテナーWLMはクラスターメンバーがEJBコンテナーサービスが稼動することで実現します。EJBコンテナーWLMを使用するEJBクライアントはEJBクラスターメンバーとは別プロセスで稼動する必要があります。EJB WLMはEJBクラスターメンバーと別プロセスで稼動するEJBクライアントに対して、負荷分散・フェイルオーバーの機能を提供します。

EJBクライアントとEJBコンテナーが同一プロセス上で稼動する場合、ServerAffinity機能により、全てのEJBクライアントのリクエストは同一プロセスのEJBコンテナーへとルーティングされます。この場合、WLMは機能しないので障害が発生しても別のEJBコンテナーへリクエストは送信されません。

EJBコンテナーWLMはWebコンテナーWLMと同様に、クラスターメンバー設定におけるウェイトに基づいた重み付けラウンドロビンでリクエストを割り振ります。

クラスター設定で可能な「ローカルを優先」を選択することで、EJBクライアントは基本的に同じノード上のEJBコンテナーへWLMルーティングされます。

EJBコンテナーWLMではV5と同様にTransactionAffinityにより、トランザクション中のリクエストは必ず前回と同じEJBコンテナーへリクエストを割振られます。

90


90

システム管理ツール

◆ 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

－スクリプト言語で管理操作を実行

－管理コンソールで可能な処理を全てカバー

－シェル化して運用を自動化したい場合に有用

・JMXプログラミング

－Javaの標準であるシステム管理API(JMX)を使用して独自の管理機能を開発可能

91


91

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

wsadmin

AdminControl

AdminConfig

AdminApp

Help

AdminTask

構成データの操作(例) 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

スクリプト実行

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

Newv6

構成情報に対する操作

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

wsadminはV5から導入された管理用スクリプト･インターフェースです。wsadminはJakartaのBSF（Bean Scripting Framework）というフレームワークに準拠しています。BSFではNetREXXやJava Scriptなどもサポートしていますが、WASでテストされサンプルが提供されるなど正式サポート対象のスクリプト言語は「JACL」および「Jython」の二つです。（※この資料でのサンプルはいずれもJACLで記載しています。）V5で使用していたスクリプトは原則V6で引き継げますが、トランザクションログの操作など若干の変更が必要なものもあります。詳細はInfoCenterの” Migrating administrative scripts from 5.x to 6.0”をご参照ください。

WASの構成可能なオブジェクトは全てJMXのMBean (Management Bean)と関連付けられています。MBeanはJMX APIを使用して管理するユーザーのための属性のgetter、setterやstart、stopなどを持ちます。管理コンソールもwsadminもいずれもこのMBeanを操作してWASの管理を行います。

wsadminコマンドの基本シンタックスは、上記のように管理オブジェクトを指定し、その管理オブジェクトに対して実行できるコマンドに必要に応じてパラメーターを指定します。管理オブジェクトは管理対象のMBeanをカテゴライズしたもので、構成データの操作を行う『AdminConfig』、エンタープライズ･アプリケーション関連操作をまとめた『AdminApp』、V6で追加された管理コマンドを実行するための『AdminTask』、スタート/ストップなどオペレーション操作『AdminControl』、ヘルプおよびMBean情報の表示を行う『Help』の計5種類があります。

コマンドはwsadminのインタラクティブモードでの実行、-cオプションによるコマンドモードでの実行、-fでスクリプトファイルを呼び出すスクリプトモードでの実行がそれぞれ可能です。

92


92

システム管理ツール (コマンド)◆ startManager コマンドによるDMの起動◆

①startManager コマンドの実行 : <Profile_root>/bin/startManager

◆ stopManager コマンドによるDMの停止◆

①stopManager コマンドの実行 : <Profile_root>/bin/stopManager

◆ addNodeコマンドによるセルへのノードの追加 ◆

①DMの起動

②addNode コマンドの実行 : <Profile_root>/bin/addNode <dmｇｒ_host>オプション

”-includeapps” : 追加時にアプリケーションをセルに引き継ぐことが可能

“-includebuses” : 追加時にセルに統合されるノードからバスをコピーしてセルに引き継ぐことが可能

“-trace” : デバッグのためにログファイルに追加のトレース情報を生成

“-logfile <filename> : ログファイルのロケーションを指定。

デフォルトではaddNode.logという名前で、追加されるノードのプロファイ

ルのlogsディレクトリーに作成される

セル環境を構成する際の、ノードをセル環境に追加する方法について説明します。

セルへのノードの追加はaddNodeコマンドと管理コンソールからの２つの方法があります。

addNodeコマンドを実行してセルへのノードの追加を行う場合、まずDMを起動させ追加するノードのプロファイル・ディレクトリ下で以下のコマンドを実行します。ノードの追加と共に、ノード・エージェントが定義され、ノード・エージェントは、addNode コマンドの一部として自動的に開始されます。

<Profile_root>/bin/addNode <dmgr_host> <dmgr_port>

<dmgr_host>はDMの稼動しているホスト名でこの引数は必須で、これ以外はすべてオプションとなります。

このコマンドのデフォルトの Java Management Extensions (JMX) コネクターは、 Simple Object Access Protocol (SOAP)です。<dmgr_port>でDMのJMXポート番号を指定します。DM のデフォルトのSOAPのポート番号は、“8879”です。オプションとして”-includeapps”を使用すると、ノードの統合時にアプリケーションをセルに引き継ぐことができます。

<Profile_root>/bin/addNode <dmgr_host> -includeapps

addNodeコマンドのオプション機能についての詳細は以下リンクのInfoCenter「addNodeコマンド」をご参照ください。

http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_addnode.html

管理コンソールからノードの追加を行う場合、該当ノードでサーバーが稼動している必要があります。カスタム・プロファイルの場合は、アプリケーション・サーバーが存在していないので管理コンソールからのノードの追加はできません。カスタム・プロファイルで作成した空のノードはaddNodeコマンドでセルへ追加します。

93


93

システム管理ツール（管理コンソール）

前の変更を回復

保管の矛盾

ログインの競合

①変更、ログアウト①変更、ログアウト

user A

②再ログオン②再ログオン

user A

server.xml

user A

①保管①保管 ②保管②保管

user B

③無効なユーザー

へのメッセージ

①ログイン①ログイン

user A

③無効なユーザー③無効なユーザー

user Auser B

②ログイン②ログイン

WAS v6のシステム管理においては、ユーザーごとにテンポラリー･ワークスペースを持つため、上記のような状態になる場合があります。

前の変更を回復：

①で管理コンソールで処理を行った後保管せずにログアウトもしくはブラウザーを終了した場合、変更はワークスペースにのみ書き込まれていることになるので、②で再ログオンした際に前セッションの変更をリカバリーするか、変更を破棄してマスターリポジトリーを元に管理操作を継続するかを問い合わせられます。

保管の矛盾：

もし同じ構成情報を複数のユーザーが参照・更新を行おうとした場合、そのままでは後者の情報のみが反映される後勝ちとなってしまうのですが、同じ構成情報を別ユーザーが変更した場合②で「保管」時に警告されますので必要に応じ行った変更を破棄するか、上書き保存を行うかを選択してください。

ログインの競合／無効なセッション：

別ブラウザー画面から同じユーザーでログオンを行おうとすると、ログインの競合が検知されます。②で後からログオンした方は先にログオンしているユーザーをログアウトすることも出来ます。その場合先にログオンしているユーザーが継続処理を行おうとした際に③の無効なセッションの画面が表示されます。

94


94

◆ Message Driven Bean (MDB)で処理をロールバックした際の動き ◆

- MDBが関連付いている宛先の「最大デリバリー失敗数」に達するまで、メッセージの受信 → ロールバックを繰り返す

- 最大デリバリー失敗数に達すると、「例外宛先」にメッセージを退避する

- 例外宛先への送信が失敗した場合や、例外宛先を「なし」に指定した場合は、ループに

陥るので注意

⇒⇒⇒⇒ アプリケーション・ハンドリングや運用による回避策が必要

メッセージング (JMSプロバイダー機能)

public void onMessage( ){

ejbctx.setRollbackOnly();}

MDBアプリケーション

例外発生!

receive

例外宛先

①

②

例外宛先へ退避

rollback

③

繰り返し

メッセージの内容やフォーマットが不正などの理由で、何度処理を繰り返してもエラーになってしまい、バックアウト処理がループしてしまう場合があります。このようなメッセージをポイズン・メッセージと呼びます。バックアウト処理のループにより後続メッセージの処理が止まることを避けるために、MDBはポイズン・メッセージを別のキュー（例外宛先）に退避させる仕組みを提供します。

メッセージの退避を行うには、宛先の「最大デリバリー失敗数」と「例外宛先」プロパティーを指定します。

•MDB内でメッセージのロールバックが行われると、メッセージの「再デリバリー回数」が１つインクリメントされます。

•ロールバックの回数が宛先の「最大デリバリー失敗数」に達すると、メッセージを「例外宛先」に指定したキューに退避します。

例外宛先は、SIBus全体で同じ宛先を例外宛先として使用することも可能ですし（「システム」を指定）、宛先ごとに固有の例外宛先を指定する(「指定」)ことも可能です。

例外宛先に何らかの理由でメッセージの送信が失敗した場合、あるいはメッセージの順序性を保つ等の理由で例外宛先を指定しない（「なし」に指定）場合には、MDBはループに陥ります。この場合、CPUなどのリソースを大量に消費するほか、WASのスレッド・ハング検知機能でも検知することができません。現状ではアプリケーション・ロジックと運用で回避する必要があります。

95


95

メッセージング (Network Deployment Cellでの構成)セル内でのSIBusの構成 ⇒ SIBus間でSIBusリンク接続

セルを跨るSIBusの構成 ⇒ SIBusの管理がセル単位, 他セルのSIBusにSIBusリンクで接続可能

MQネットワークにMQリンクで接続可能

JMS Client = JSMを介してメッセージング・サービスを利用するアプリケーション

Cell 1

SIBusリンクリンクリンクリンク

SIB 1

Server AME

SIB 2

JMS Client

Server BME

JMS Client

Server CME

JMS Client

Server DME

JMS Client

Server EME

JMS Client

Server FME

JMS Client SIBus リンクリンクリンクリンク

MQリンクリンクリンクリンク

WebSphere MQQueue

Manager

SIB 1Cell 2

Server AME

JMS Client

Server BME

JMS Client

これは大規模な組織向きのSIBusの構成です。部門によってWASのセルを分けることができます。また既存のWebSphere MQネットワークとも接続しています。セル内およびセル間のSIBusもSIBusリンクにより接続できます。

96


96

練習問題

19. WebコンテナーコンテナーコンテナーコンテナーWLMをををを実現実現実現実現するためするためするためするため、、、、システムシステムシステムシステム管理者管理者管理者管理者ははははクラスタークラスタークラスタークラスターをををを作成作成作成作成したしたしたした後後後後、、、、クラスクラスクラスクラスターターターター・・・・メンバーメンバーメンバーメンバーにににに対対対対しししし、、、、それぞれのそれぞれのそれぞれのそれぞれのサーバーサーバーサーバーサーバーへのへのへのへの割割割割りりりり振振振振りのりのりのりの重重重重みみみみ付付付付けをけをけをけを設定設定設定設定なければなりませなければなりませなければなりませなければなりませんんんん。。。。正正正正しいものはしいものはしいものはしいものは次次次次のうちどれですかのうちどれですかのうちどれですかのうちどれですか？？？？

A. 各事業所に配置されたサーバーはすべて性能が同じであるため、どのサーバーにも均等に”0”を設定する。B. SessionAffinityの機能を使用したいので、ラウンドロビンで割り振りしないよう設定はしない。C. サーバーAはサーバーBの2倍の性能を保持するので、サーバーAは”100”、サーバーBは”50”を設定する。D. “0”を設定したサーバーには、割り振り可能な唯一のアプリケーション・サーバーにならない限りは割り振られ

ない。

20. wsadminスクリプトスクリプトスクリプトスクリプトをををを使用使用使用使用してしてしてしてアプリケーションアプリケーションアプリケーションアプリケーション・・・・サーバーサーバーサーバーサーバーををををSIBusにににに追加追加追加追加するというするというするというするという管理作業管理作業管理作業管理作業をををを行行行行うううう必要必要必要必要がありますがありますがありますがあります。。。。システムシステムシステムシステム管理者管理者管理者管理者はははは次次次次のうちどののうちどののうちどののうちどのwsadminスクリプトスクリプトスクリプトスクリプト・・・・オブジェクトオブジェクトオブジェクトオブジェクトをををを使使使使用用用用するするするする必要必要必要必要がありますかがありますかがありますかがありますか？？？？

A. AdminManagementB. AdminControlC. AdminTaskD. AdminJMS

<memo>

97


97

練習問題回答

① B② A③ C④ A⑤ C⑥ B⑦ C⑧ C⑨ C⑩ A

お疲れ様でした。WebSphere 認定試験がんばってください。

⑪ B⑫ C⑬ B⑭ A⑮ A⑯ B⑰ C⑱ B⑲ D⑳ C

<memo>

websphere application server network deployment...

Documents