WebSphere Application Server V8public.dhe.ibm.com/software/dw/jp/websphere/was/was8_ws/was_v… ·...

03.システム管理

WAS V8.0 アナウンスメント・ワークショップ 1

WebSphereWebSphere Application Server V8.0Application Server V8.0

アナウンスメント・ワークショップアナウンスメント・ワークショップ

© 2011 IBM Corporation

1 WAS V8.0 アナウンスメント・ワークショップWAS V8.0 アナウンスメント・ワークショップ

03.03.システム管理システム管理

®

システム管理システム管理





01. WAS V8.0 01. WAS V8.0 概要概要

Disclaimer

この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2011年7月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。

今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。

IBM、IBMロゴ、ibm.com、AIX、Rational、およびWebSphere は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの商標リストについては、http://www.ibm.com/legal/copytrade.shtmlをご覧ください。

JavaおよびすべてのJava関連の商標は Oracleやその関連会社の米国およびその他の国における商標または登録商標です。

Windows は、Microsoft Corporationの米国およびその他の国における商標です。

Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。

UNIXはThe Open Groupの米国およびその他の国における登録商標です。






Agenda

はじめに

– システム管理基本トポロジー

製品のインストール

– IBM Installation Manager(IIM)– 集中インストール・マネージャー(CIM)

構成情報の管理

– WebSphere構成情報

– 「asExistingNode」を使ったノードのリカバリー、セルの複製

– プロパティー・ファイル・ベース構成ツール（PFBCT）

問題判別、パフォーマンス・チューニング

– High Performance Extensible Logging(HPEL)– Javaコア、ヒープ・ダンプ、システム・ダンプの取得

– Tivoli Performance Viewer– IBM Support Assistant（ISA）

まとめ

本日ご紹介する内容のアジェンダです。

まずはじめに、システム管理構成全体像として、WAS V8のシステム管理基本トポロジーをご紹介します。

次に、システム管理者が日々行う主なタスクの内容を軸にして、WAS V8の新しい管理機能を中心に、システム管理の内容を説明します。






はじめに






V8システム管理基本トポロジー

プロファイル

プロファイル

プロファイル

AS

AS

DM

シングル･サーバー･ノード(WAS Base / Express)

セル構成（WAS ND)

wsadmin

構成ファイル

アプリケーション

構成ファイル


構成ファイル


セル

クラスター

ノード

ノード

ノード

ノード

管理コンソール

wsadmin

構成ファイル


Web Server

Plugin構成ファイル

NA

Webサーバー･ノード

プロファイル

ノード

Job Managerプロファイル

ノード構成ファイル

AdminAgentプロファイル

AS

NA

NA


wsadmin


wsadmin管理コンソール

ノード･グループ

凡例：AS Application ServerNA Node AgentDM Deployment Manager

WAS V8システム管理の新機能の紹介に入る前に、まずWAS V8システム管理構成の全体像、管理トポロジーをご紹介します。

WAS V8の管理トポロジーは基本的にWAS V7を踏襲します。管理構成としてWAS BaseもしくはExpress版を使用したシングル･サーバー･ノードと、WAS ND (Network Deployment)版を使用したセル構成の2パターンがあります。

シングル･サーバー･ノードでは、管理は個々のノードに対して行います。管理コンソール自体もアプリケーション･サーバー上にインストールされるエンタープライズ･アプリケーションなので、ノード内の一つのアプリケーション･サーバー上に自動的にインストールされます。

セル構成ではセル内のマシンを個別に管理していては負荷がかかりますので、管理ポイントを集約しています。これがデプロイメント･マネージャー（DM）というプロセスです。セルに参加するアプリケーション･サーバーノードは、addNodeというコマンド（もしくは管理コンソールの『ノードの追加』オペレーション）でデプロイメント･マネージャー管理下に配置されます。これはノード内にノード･エージェント（NA）というプロセスを起動し、デプロイメント･マネージャーとの構成情報やアプリケーションの同期を取ることが出来る構成です。ノード･エージェントには自ノードで稼動するアプリケーション･サーバーを定期的に監視し、異常停止の場合再起動するという機能もあります。

WAS Base構成/Express構成を集中管理するコンポーネントとしてAdminAgentがあります。また、複数のNDセルやシングル･サーバー･ノードを統一的に運用管理するコンポーネントとしてJob Managerがあります。AdminAgentとJob Managerはプロファイルを使用して作成されます。また、この二つの管理コンポーネントによってFlexible Managementという概念が実現されます。

重要な管理対象としては大まかに分けて二つ、configディレクトリ配下に置かれるXMLで記載された構成ファイル（JVMプロセスの定義情報やJDBCデータソースといったリソース情報など）と、installedAppsディレクトリ配下に置かれるアプリケーション･サーバー（AS）上で稼動するエンタープライズ･アプリケーションです。これらを管理するオペレーションは、管理コンソールと言うブラウザー･インターフェースのツールと、wsadminというコマンドラインツールによって行うことが可能です。






前バージョンまでの管理概念を踏襲

トポロジー・管理プロセスなどの概念に変更はなし

– 既存の環境の構築にかかった投資を保護

V7.0の設計・パラメーター・運用手順などをそのまま使用可能

V8とV7.0/6.xの混合セル環境をサポート

– 段階的な移行も可能

セル

DM

ND V6.1 ノード

NA

App ServerV6.1

App ServerV6.1

ND V7.0 ノード

NA

App ServerV7.0

App ServerV7.0

ND V8.0 ノード

NA

App ServerV8.0

App ServerV8.0

ND V6.0 ノード（End of Service）

App ServerV6.0

App ServerV6.0

NA

DMノード

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

管理者

システム管理者にとって、WAS V8の管理構成や管理プロセス、管理ツール、ログ出力などの基本管理概念はWAS V8はV7からほどんど変わりありません。

WAS V7の設計書、運用手順は継続的に使用可能です。

WAS V8は混合セル環境をサポートします。 WAS V8でのセルは、前バージョンのV7.0/V6.xのノードを統合管理することが可能です。これにより、前バージョンからの段階的な移行が可能です。






システム管理者の４つのタスク

構成情報の変更、トポロジーの管理◆WebSphereプロセス（DM、AS、NA）の作成・管理◆WebSphereリソース、プロパティの管理

◆アプリケーションの管理（インストール、更新、アンインストール、構成情報の管理）

オペレーションの変更◆プロセス、アプリケーション、サービスの起動終了

問題判別、パフォーマンスチューニング◆ツールを使用した問題判別◆パフォーマンス関連パラメーターの調整

製品のインストール、環境・トポロジーの構成製品のフル・ライフサイクル管理機能・IIM・CIM

ノードの管理機能・ノードのリカバリー・セルの複製

PFBCT・セル範囲を超えて、構成情報を適用

HPEL・ログ取得の高速化、トレース負荷の軽減

New

New

New

WASのシステム管理者の行うべきタスクは大きく分けて上記の四つになります。

『製品のインストール、環境・トポロジーの構成』に関しては基本的にシステム構築時に一度のみ行うタスクです。『環境・トポロジーの構成』に関しては当システム管理ではなく、「システム構成」のセッションでカバーされています。

このタスクに関連して、WAS V8では製品のフル・ライフサイクル管理機能を持つインストール・保守用ツールIBM Installation Manager（IIM）が新たに追加されました。またWAS V7からあった集中インストール・マネージャー（CIM）機能は拡張されています。

以降のタスクは日常運用の中で繰り返し実施するタスクになります。『構成情報の変更、トポロジーの管理』とはシングル･サーバー･ノード／ND環境のそれぞれでプロセスやクラスターを管理することや、リソース、プロパティなどの構成情報の管理を行うこと、さらにアプリケーションをインストール･更新するような管理も含んでいます。

このタスクに関連して、WAS V8では、ノードの管理機能が強化され、ノードのリカバリーやセルの複製は以前より簡単に実施できるようになりました。

『オペレーションの変更』とは、プロセスやアプリケーションなどの起動終了を行うタスクです。『問題判別、パフォーマンスチューニング』は問題発生時の解析および回復、パフォーマンス低下の際のチューニングを行うタスクになります。

WAS V8では、ログやトレースの取得負荷が大幅に軽減し、従来のログ機能に加え、新たなログ機能High Performance Extensible Logging(HPEL)が追加されました。

これらのタスクは基本的にはWebブラウザーベースの管理ツールである「管理コンソール」、コマンドラインツールである「wsadmin」、プロセスの起動終了など繰り返し実行するオペレーションをコマンドライン実行できる「WebSphereコマンド」、プロパティー･ファイル･ベース構成ツール（PFBCT）の４種類のうちのいずれかで行います。追加でプロファイル管理ツールなど特定の操作を行うために提供されるツールもあります。












従来のWASインストール

複数台環境の場合、筐体ごとに製品メディアによるインストール作業が必要

製品の更新は別途Update Installerのインストールが必要

応答ファイルを手動作成が必要

インストール

メンテナンス

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

対象はセルの範囲内に限定

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

・従来のWASをインストールする際、通常筐体ごとに製品メディアによるインストール作業が必要です。

・Fixを適用する時は別途Update Installerのインストールが必要になります。

・サイレント・インストールの際、応答ファイルを手動で作成する必要があります。

・WAS V7より、デプロイメント・マネージャーからリモートホストにWAS製品、更新を一元的にインストールすることができるようになりましたが、対象範囲はセルの中のノードに限定されます。

上記従来のWASインストールにまつわる課題に対し、WAS V8では新たなソリューションとして、インストールと保守機能を統合した管理ツールIBM Installation Managerが登場しました。






IBM Installation Manager

WAS V8より、IIMを使用してWAS製品をインストール

– IBMソフトウェア・パッケージをインストールする共通ツール

– リポジトリー経由で製品および更新を検索し、ダウンロード

– GUIモードやサイレント・モードで製品をインストール

従来は、インストーラーと製品コードが製品メディアの中で一体化

IIM

製品バイナリー

WAS V8以降、インストーラーと製品コードが分離される

IIMのインストール

製品バイナリーをダウンロード

IIMによるWASのインストール

New

インストールの基本流れ

※ 新版はv1.4.4（2011年7月時点）

•製品を自動検索

•１度に複数製品をｲﾝｽﾄｰﾙ

•Fixを自動検索、適用

•フィーチャーの追加、削除

•前バージョンに戻す

•１度に複数製品をアンインストール

・WAS V7までは、インストーラーは製品そのもの一部として捉えます。インストーラーは製品イメージに組み込まれ、製品リリースごとに、その製品固有なインストーラーを使用して、製品のインストールを行ってきました。製品やプラットフォームによって、インストーラーもそれぞれ異なります。

・WAS V8より、すべてのWAS製品のインストールは単一なツールであるIBM Installation Manager（IIM）によって行うようになりました。

・もともとIIMはIBM Rational Desktop製品をインストールするためのツールですが、近はWASを始め、IBMの複数の製品のインストールおよび保守用に使用されるようになりました。

・IIMは、リモートまたはローカルのリポジトリーを使用して、WAS製品をインストール、変更、更新、ロールバック、アンインストールすることができる単一のインストール・プログラムです。

・IIM は、使用可能なパッケージ (製品、FixPack、iFixなど) の判別および表示、前提条件、相互依存性をチェックし、選択されたパッケージのインストールを行います。また、IIM を使用して、インストールされたパッケージを容易にアンインストールすることもできます。

・WAS V8より、WAS関連製品のインストールには必ずIIMを使用することになります。

・IIMは、集中インストール・マネージャー（CIM）や、IBM Packaging Utility と併用することで、複数台環境など企業向け大規模インストールを可能にした基本ツールとなります。

・IIMの大な特徴は、インストールとメンテナンスの統合です。

・IMの入手先

-製品メディア

-Webからダウンロード：http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24023498

IIMの使用してインストール可能なWAS製品例：

Application Client for IBM WebSphere Application Server、 Edge Components、 IBM HTTP Server V8.0、 Pluggable Application Client for IBM WebSphere Application Server、 WebSphereCustomization Toolbox、

WebSphere DMZ Secure Proxy Server、 Web Server Plug-ins






IIMによる製品インストール

333

製品メディアによるローカル・インストール製品メディアによるローカル・インストール

IBMサイトよりWeb ベースでインストールIBMサイトよりWeb ベースでインストール

•IIM

•製品パッケージ①製品メディアよりIIMをインストール②IIMを使用してメディア上の製品リポジトリーから製品をインストール

①IBM Passport Advantage サイトから IIMと必要な製品パッケージをダウンロード②IIMをインストールし、そのIIMを使用してローカル・リポジトリーから製

品をインストール

①IIMのイメージ・ファイルを Web サイトからダウンロード②IIMをインストールし、そのIIMを使用してWeb ベースのリポジトリーか

ら製品をインストール

IBM PassportAdvantage

•IIM

•製品パッケージ

IBMドメイン

222IBM Passport Advantageサイトからファイルをダウンロードした上、ローカル・インストール

IBM Passport Advantageサイトからファイルをダウンロードした上、ローカル・インストール

製品パッケージ

•IIM

111

IBM Installation Manager の Web サイト：

http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24023498

Webベース・インストール時製品パッケージのダウンロード先（ Passport Advantage 認証が必要）

http://www.ibm.com/software/repositorymanager/com.ibm.websphere.ND.v80






GUIモードによるインストール時の環境設定

リポジトリーとは

– 製品パッケージを格納する場所• ローカル・リポジトリー：IIMと同一マシーン上にある

• リモート・リポジトリー：ネットワーク上識別可能なディレクトリー／Webサイト、FTPサイト

• サービス・リポジトリー：IBMサイトにあるリモート・リポジトリー

リポジトリーの設定

②製品パッケージにあるdiskTag.infもしくは repository.configを指定

④チェックをオンにすると、IIMはサービス・リポジトリーでインストール済みパッケージの更新を自動検索

③新規追加されるリポジトリーはリストに表示される

①リポジトリーを選択

リポジトリー

IIM

・IIMを使用してインストールできる各ソフトウェア製品は、「パッケージ」と呼んでいます。

・リポジトリーとは、パッケージのインストール、変更、ロールバック、更新、またはアンインストールを行う場合のデータの格納場所です。

・リポジトリーに格納されているパッケージは単なるフラット・ファイルですが、製品バイナリーとパッケージ構造を表すメタデータ情報の両方が含まれています。

・パッケージをIIMと同一マシーン上に格納したロケーションはローカル・リポジトリーです。

・パッケージをネットワーク上識別可能なリモート・ディレクトリーやWebサイト／FTPサイトに格納した場合、リモート・リポジトリーと呼んでいます。

・IBMドメインにあるリモート・リポジトリーはサービス・リポジトリーと呼んでいます。

・サービス・リポジトリーは IBMドメインにあるリポジトリーで、製品の更新が含まれています。各IBM 製品には、製品に固有のサービス・リポジトリーへのリンクが組み込まれています。IBM Installation Manager は、サービス・リポジトリーと、リポジトリー設定ウィンドウのリポジトリー・テーブルにリストされたリポジトリーの両方を検索します。

サービス・リポジトリーのリンクを表示したり、変更したりすることはできません。設定「インストール中および更新中にサービス・リポジトリーの検索」をオンにすると、Installation Manager は、IBMドメインにアクセスし、インストール済みの製品について使用可能な更新を検索します。この設定はデフォルトで選択されています。

・リポジトリーの設定ウィンドウでリポジトリーを追加する場合には、diskTag.inf、repository.configのいずれかを選択することができます。

※diskTag.inf は、リポジトリー・ファイルがディスク・イメージからのものであることを示します。






GUIモードによるインストール

<インストール・ロケーション設定例 >

•AIX：/usr/IBM/WebSphere/AppServer

•Linux/Unix： /opt/IBM/WebSphere/AppServer

•Windows：C: ¥IBM¥WebSphere¥AppServer

GUI画面上「インス

トール」をクリック

インストールするパッケージ名にチェックを入れる

「インストール・ディレクトリー」で製品のインストール先を指定

フィーチャーの選択画面で、機能を選択してインストール

リポジトリーを設定後、以下の手順でGUIモードによるインストール作業を行います。

１．IBM Installation Manager を開始します。

２．「インストール」をクリックします。

３．インストール対象のパッケージを選択します。一度に複数のパッケージを選べます。

４．使用条件の条項に同意し、「次へ」をクリックします。

５．製品バイナリーのインストール・ルート・ディレクトリーを指定します。

６．インストールするフィーチャーを選択します。

７．要約情報を検討して、「インストール」をクリックします。






【デモ】Fixの自動検索、更新






サイレント・モードによるインストール（1）

IIMのGUI操作で応答ファイルの記録が可能

インストール用応答ファイル作成コマンド発行

# cd 〈Installation Managerのインストールディレクトリ〉/eclipse # ./IBMIM -record responseFile -skipInstall agentDataLocation

Unix・Linuxの場合

>cd 〈Installation Managerのインストールディレクトリ〉¥eclipse>IBMIM.exe -record responseFile -skipInstall agentDataLocation

Windowsの場合

>cd C:¥Program Files¥IBM¥Installation¥eclipse>IBMIM.exe -record C:¥temp¥responsefiles¥install_was.xml -skipInstall C:¥temp¥agent¥was

コマンドの発行例（Windows）

IIMが起動され、ウィザード形式でインストール手順を進め、完了後IIMを終了させ、指定したロケーションにXML応答ファイルが作成される(実際の製品はインストールされない)

install_was.xml

New

•agentDataLocationには、インストールに必要な作業用ファイルが生成される

•responseFileには、応答ファイルが生成されます

IIMのGUIモードで、サイレント・インストールに必要な応答ファイルを作成できます。

１．コマンド行で、IIMをインストールしたディレクトリーの Eclipse サブディレクトリーに移動します。

２．-record オプションを使用して、コマンド行から IIMを開始します。

３．GUI画面が立ち上がり、適切なリポジトリーを IIM設定に追加します。

４．「インストール」をクリックします。

５．以降はGUIモードによるインストール手順と同様になります。

・-skipInstall パラメーターを指定することにより、実際に製品をインストールせず、応答ファイルのみ生成します。

・agentDataLocationには、インストールに必要な作業用ファイルが生成されます。

・responseFileには、応答ファイルが生成されます。






サイレント・モードによるインストール（2）

記録した応答ファイルを利用し、サイレント・モードでIIMを実行し製品パッケージをインストールサイレント・モードでインストール・コマンド発行

# cd 〈Installation Managerのインストール・ディレクトリ〉/eclipse/tools# ./imcl input responseFile -log logFile -acceptLicense

Unix・Linuxの場合

>cd 〈Installation Managerのインストール・ディレクトリ〉¥eclipse/tools>imcl.exe input responseFile -log logFile -acceptLicense

Windowsの場合

>cd C:¥Program Files¥IBM¥Installation¥eclipse/tools>imcl.exe input C:¥temp¥responsefiles¥install_ihs.xml -log C:¥temp¥logs¥ihs -acceptLicense

コマンドの発行例（Windows）

インストールが正常に終了すると、指定されたログファイルは空になる

<?xml version="1.0" encoding="UTF-8"?>

<result>

</result>正常完了しなかった場合、ログファイルにエラー・メッセージが記録される

記録した応答ファイルを指定し、サイレント・モードで製品パッケージをインストールします。






企業ドメイン

リポジトリーを使った複数台のインストール

IBM Packaging Utility– リポジトリーと製品パッケージを一元管理

• 共有リポジトリー（共有ディレクトリー）を簡単に作成

• 製品CDイメージやダウンロードしたパッケージをリポジトリーにコピー

• 複数のパッケージをリポジトリーにコピー

• パッケージの削除

IBMドメイン

サービス・リポジトリー

IIMIIM

IBM Packaging Utility

IIM

インターネット

共有

リポジトリー

– 複数台マシーンのインストール

• 製品パッケージをダウンロード、解凍

• IBM Packaging Utilityを使用し、パッケージ

を共有リポジトリーへコピー

• 各マシーンはIIMを利用して製品をインストー

ル

IBM Packaging Utilityはリポジトリーとパッケージを一元管理できるツールです。別途入手する必要があります。

入手先：https://www-304.ibm.com/support/docview.wss?uid=swg24029225

※ 新版はv1.4.4（2011年7月時点）

IBM Packaging Utility では、以下の作業を実行することができます。

・パッケージ用の新規リポジトリーを生成する。

・複数のパッケージを 1 つのリポジトリーにコピーする。

・複数のバージョンの製品を 1 つのリポジトリーにコピーする。ユーザーは、同じリポジトリーを指定して、インストール済みの製品を更新します。

・コンポーネントを共有している複数のパッケージが 1 つのリポジトリーに追加された場合に、ディスク・スペースを節約する。リポジトリーに保持されるのは、共有コンポーネントのコピーのうちいずれか 1 つのみです。

・不要なパッケージを削除する。

・HTTP を介してパッケージをインストールするためのリポジトリーを作成する。

・CD インストール・イメージまたは IBM リポジトリーから、内部サーバーまたはローカル・マシンにあるリポジトリーに、パッケージをコピーする。

企業レベルでリポジトリーを一元管理するメリット

・企業の全ユーザーに提供する製品コンテンツを一箇所で集中管理できる

・セキュリティーをかけやすい






WAS V8のインストール

複数台環境の場合、筐体ごとに製品メディアによるインストール作業が必要

製品の更新は別途Update Installerのイ

ンストールが必要

応答ファイルを手動作成が必要

インストール

メンテナンス

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

リポジトリーから製品パッケージをダウンロードしてインストール

Before

インストール、更新、変更、アンインストールは１つのツールで実現可能

IIMのGUI操作で応答ファイルを簡

単に作成

After

対象はセルの範囲内に限定

集中インストール

次ページ以降にてご説明

・従来のWASをインストールする際、通常筐体ごとに製品メディアによるインストール作業が必要ですが、IIMを使ったインストールでは、リポジトリーから製品パッケージをダウンロードしてインストールするスタイルが可能になり、複数台環境の場合でもインストール、更新作業がより効率的に行うことは可能です。

・従来、Fixを適用する時は別途Update Installerのインストールが必要になりますが、インストール、更新、変更、アンインストールは１つのツールに統合されるようになりました。

・WAS V8では、サイレント・インストールの際応答ファイルをIIMのGUIモードで容易に作成することができます。

・集中インストールの課題に対するソリューションは次ページで以降で説明します。






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

リモートのノードに対して、WAS関連製品、修正モジュール等を一元的にインストール可能な機能（Centralized Installation Manager）

V8ではJob ManagerからCIMを使用可能

– V7では、CIM機能の利用範囲はセル内

– V8では、Job Managerが複数のセルを跨って集中インストールが可能になった

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

ノードA

ノードB

ノードC

セル

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


ノードA

ノードB

ノードC

セル1

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

セル2セル3

リポジトリー

WAS V7 WAS V8

CIM

CIM

Job Manager

CIM

Update

集中インストール・マネージャー（CIM）はV7ではND環境でサポートされ、インストール先はセル内のノードになります。インストール対象は、WAS V7 NDモジュール、WAS V7のFix、WAS V7のUpdate Installer、WAS V6.1のFix（V6.1は混合セル環境のみ）になります。インストール時はセル内のノード全てを選択することも、個別にノードを選択することもできます。インストール先ノードにエージェントは不要であり、複数台同時にFixを適用する際などは大変便利な機能になります。

V8では、CIM機能が拡張され、Job ManagerからCIM機能を実行できるようになり、セルを跨いて複数のリモート・ノードに対してインストール作業が可能になります。






CIM新機能の特徴

複数セルを跨るセル範囲内対象ノード

Job Manager／デプロイメント・マネージャーデプロイメント・マネージャー管理コンソール

IIMのリポジトリーDM配下のCIMリポジトリーリポジトリー

WASのインストール、更新

V7

IIM でインストール可能な全製品のインストール、更新インストール製品

V8機能

インストール対象ノードがセル範囲を超えインストール対象ノードがセル範囲を超え

インストール可能対象製品範囲が拡大インストール可能対象製品範囲が拡大

CIM新・旧機能比較

Update

インストールのスケジューリングが可能インストールのスケジューリングが可能

Job Manager

CIM

ノード

IIM

リポジトリー

IIM

インストールイメージ

1

2

Job Managerによる集中インストールの流れ

WAS

製品バイナリー

バージョン 8.0 CIM では、以前のバージョンに比べ以下の改善が行われています。

・z/OS オペレーティング・システム・ターゲットのサポート

・セル境界の制限の除去。ターゲットを、セルの外部に追加できるようになりました。

・ジョブのスケジューリング

CIMを使用して、ジョブ１つを定義してリモートの複数台のマシーンにIIMやWASをインストールすることは可能になりました。

Job ManagerによるCIMを介してのWASインストールは、以下の流れになります。

①リモート・マシーンにIIMをインストール

・Job Managerの管理コンソールを使用して、ターゲット・マシーンを登録します。

・「IBM Installation Manager のインストール」ジョブを選択し、ターゲットを指定し、ジョブをスケジュールに入れます。

・ジョブをサブミットします。

※IIM V1.4.3以降が必須

②リモート・マシーンにWASをインストール

・ Job Managerの管理コンソールを使用して、「オファリングの管理」ジョブを選択し、ターゲットを指定し、ジョブをスケジュールに入れます。

・ジョブをサブミットします。

WebSphere Application Server をインストールする場合は、管理コンソールを使用してターゲット・マシンを登録し、 IBM Installation Manager をインストールして、WebSphere Application Server または Installation Manager と互換性のあるその他の製品オファリングをインストールします。管理コンソールを使用して、ターゲット・マシン上の製品のインストール先ディレクトリーに対するパラメーターを設定し、ターゲット・マシン上の製品データの保管場所を指定し、製品のダウンロード元リポジトリーの URL を指定することができます。






CIMよりIIMをインストール（1/4）

事前準備– IIMインストール・イメージを事前に入手

Job Managerの管理コンソールからリモート・ホストを登録

– 管理コンソールのナビゲーション・ツリーから、「ジョブ」 > 「ターゲット」の順でクリック

– 「新規ホスト」をクリックし、リモート・ホストの情報を入力し、リモート・ホストをJob Manager配下

に登録

Job Managerに登録

•インストール対象のノード名、ユーザ名、パスワードを入力

・前述の方法で事前に製品メディアかWebサイトよりIIMのインストール・イメージを入手し、Job Managerから認識可能なリポジトリーに格納します。

・Job Managerを開始し、インストール対象のリモート・ホストをJob Managerのターゲットに設定します。Job Managerのコンソールで、「ジョブ」 > 「ターゲット」 > 「新規ホスト」をクリックして、「新規ターゲット」ページのフィールドにリモート・ホストの情報を入力します。







管理コンソールのナビゲーション・ツリーから、「ジョブ」 > 「サブミット」の順でクリック

「IBM Installation Manager のインストール」ジョブを選択して、「次へ」をクリック

ジョブ・ターゲットを選択し、「ターゲット名」を選択した後は、ターゲット名を指定して「追加」をクリックするか、「検索」をクリックして、「ターゲットの検索」ページで選択したターゲットを指定

– ※WASV7に比べ、インストール関連のジョブ・タイプが追加されました

ジョブ・タイプの選択

•ジョブタイプから「IIMのインストール」を選択

ｲﾝｽﾄｰﾙ先の選択

•ターゲットのホスト名を選択

・管理コンソールのナビゲーション・ツリーから、「ジョブ」 > 「サブミット」の順でクリックします。

・「IBM Installation Manager のインストール」ジョブを選択して、「次へ」をクリックします。

・インストール対象ターゲットを選択します。

－「ターゲット名」を選択した後は、ターゲット名を指定して「追加」をクリックするか、「検索」をクリックして、「ターゲットの検索」ページで選択したターゲットを指定します。

－ユーザー認証が必要な場合は、ユーザー名、パスワード、または必要に応じて他の認証の値を指定します。







「ジョブ・パラメーターの指定」ページで、以下を指定– IIMのイメージを格納したロケーション

– インストール作業用ディレクトリー

– リモート・ホストのIIMインストール・ディレクトリー・IIMインストール・イメージの場所

•インストール作業用ディレクトリー

•IIMインストール・ディレクトリー

「ジョブ・パラメーターの指定」ページで、以下を指定します。

・Job Managerから認識可能なIIMインストール・イメージのパス

・インストール対象ターゲットにおけるインストール作業用ディレクトリー

・インストール対象ターゲットにおけるIIMインストール・ディレクトリー







ジョブ・スケジュールを設定し、ジョブを実行

ジョブ・ステータスに「成功」したメッセージが表示されたことを確認

ジョブの実行と確認

•ジョブをジョブ・スケジュールに登録•ジョブを実行し、実行結果を確認

・ジョブをスケジュールに入れ、ジョブをサブミットします。

・ジョブが実行されて、選択したターゲット上に IIM がインストールされます。






CIMよりWASをインストール（1/3）

事前準備：応答ファイルの準備

管理コンソールのナビゲーション・ツリーから、「ジョブ」 > 「サブミット」の順でクリック

「オファリングの管理」ジョブを選択して、「次へ」をクリック

ジョブ・ターゲットを選択し、「ターゲット名」を選択した後は、ターゲット名を指定して「追加」をクリックするか、「検索」をクリックして、「ターゲットの検索」ページで選択したターゲットを指定

ジョブ・タイプの選択

•「オファリングの管理」を選択

・事前にIIMのGUIモードか手動作成により応答ファイルを準備します。

・ Job Managerの管理コンソールで、「ジョブ」>「サブミット」と選択します。

・ジョブ・タイプ・ドロップダウン・メニューで「オファリングの管理」を選択します。

・インストール対象ターゲットを選択します。







ジョブ・パラーメーターの指定では、以下を指定

– 応答ファイルを格納したロケーション

– インストール済みIIMのインストール・ディレクトリー

– インストール作業用ディレクトリー

・応答ファイルの格納ロケーション

•インストール済みIIMのインストール・ディレクトリー

•インストール作業用ディレクトリー

「ジョブ・パラメーターの指定」ページで、以下を指定します。

・Job Managerマシン上の応答ファイルへの絶対パス名

・リモート・マシン上の IIMインストール・ディレクトリー

・インストール作業用ディレクトリー







ジョブ・スケジュールを設定し、ジョブを実行

ジョブ・ステータスに「成功」したメッセージが表示されたことを確認

ジョブの実行と確認

•ジョブをジョブ・スケジュールに登録•ジョブを実行し、実行結果を確認

・ジョブをスケジュールに入れ、ジョブをサブミットします。

・ジョブが実行されて、選択したターゲット上に WASがインストールされます。






まとめ製品のインストール

インストール・保守の簡素化–IBM Installation Manager(IIM)

• 製品ライフ・サイクル管理の単一化

• GUI操作による応答ファイルの作成

• IBM Packaging Utilityによるリポジトリーの一元管理

–集中インストール・マネージャー(CIM)• Job Managerによるセル境界を超えてのインストールが可能

• CIMによるIIMおよびWAS製品のインストールが可能

→複数台環境を迅速にインストールが可能

Before After

対象はセルの範囲内に限定 IIMとCIMを利用して分散環境

インストールのスケーラビリティー向上






構成情報の変更・トポロジー管理






【参考】WebSphere構成情報（スタンドアローン構成）

シングル・サーバー・ノードでは<WAS_PROFILE_ROOT>/config下に全ての

構成ファイルを配置

Node


wsadminアプリケーション

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

アプリケーション管理

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

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

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

シングル・サーバー・ノード（Base構成）

サーバーの構成ファイル

セルの構成ファイル

BLAの構成ファイル


ノードの構成ファイル

シングル・サーバー・ノード（Express版、Base版など）の構成情報のディレクトリー構造は上記のとおりです。シングル・サーバー・ノードでは、 <WAS_PROFILE_ROOT>/config下に全ての構成ファイルが配置されます。セルレベル、ノードレベル、サーバーレベルといった階層構造があり、それぞれの構成がXMLファイルで配置されています。






【参考】 WebSphere構成情報（セル構成）(1/2)

セル環境ではデプロイメント・マネージャーがセル内のノードの全ての構成ファイルを<WAS_DM_PROFILE_ROOT>/config下に保管し、ノード・エージェントを経由して各ノードに構成ファイルを配布(同期化)

Node

Node

ND環境

デプロイメント・マネージャー管理サービス/JMX 構成サービス



ノード・エージェント




管理サービス/JMX



wsadmin

セルの構成ファイル

クラスターレベルの構成ファイル


ノードレベルの構成ファイル

サーバーレベルの構成ファイル

BLAの構成ファイル

マスター構成情報

ノード構成情報

セル環境では、デプロイメント・マネージャーがセル内のノード全ての構成ファイルを<WAS_DM_PROFILE_ROOT>/config下に保管します。ディレクトリー構造は上記のようにシングル・サーバー・ノードと同様にセルレベル、ノードレベル、サーバーレベルといった階層構造になっており、それぞれの構成がXMLファイルで配置されています。各ノードの構成情報はデプロイメント・マネージャーが保有している構成ファイルをマスター構成として、デプロイメント・マネージャーから各ノードのノード・エージェントを経由して配布されます。この構成ファイルの配布を同期と呼びます。






【参考】 WebSphere構成情報（セル構成）(2/2)

各ノードの<WAS_PROFILE_ROOT>/config下には、デプロイメント・マネー

ジャーが保有しているマスター構成ファイルから自ノードに関係のあるファイルのみが同期化され保管される(下記は同期対象ファイルの一例)


ノード

セルレベルの構成ファイル

クラスタールの構成ファイル


ノードレベルの構成ファイル

サーバーレベルの構成ファイル

デプロイメント・マネージャーからノード・エージェントを経由して配布されるファイルは、自ノードが使用する構成ファイルのみになります。上記はデプロイメント・マネージャーからWASNode01ノードへの構成ファイルの配布例になります。ノードレベルの構成ファイルの配布の場合、WASNode01下の構成ファイルは配布されますが、WASNode02下の構成ファイルはWASNode01には配布されません。






【参考】 Job Managerの構成情報

Job Managerは<WAS_PROFILE_ROOT>/config下にJob Manager自身の

構成ファイルを保管

Job Managerは配下のノードの構成情報を持たない

– Job Managerは内部データベースに配下のノードの管理情報を保有

– 配下のノードはJob Managerへの接続情報を保有

Job Manager配下のノードの構成変更をおこなう場合は、各ノード(デプロイメント・マネージャー、AdminAgent)に対し直接管理コンソール、wsadminで変更

をおこなう

wsadmin

Job Manager

Job Managerセルの構成ファイル

Job Managerノードの構成ファイル

Job Managerサーバーの構成ファイル

NodeJob Manager



Job Manager構成情報

Job Managerは<WAS_PROFILE_ROOT>/config下にJob Manager自身の構成ファイルを保管します。Job Managerに統合しているND環境ノード、シングル・サーバー・ノードの構成情報は持ちません。Job Managerは配下のノードの管理情報のみを内部データベースに保管しています。この内部データベースは<WAS_PROFILE_ROOT>/OTiS下に配置されています。また、配下のノードは定期的にJob Managerに対しジョブの有無を確認するので、Job Managerに統合した際にJob Managerへの接続情報を保有します。

Job Managerに統合しているノードの構成変更をおこなう際は、ND環境ノードの場合はデプロイメント・マネージャーに、シングル・サーバー・ノードの場合はAdminAgentに管理コンソールもしくはwsadminコマンドで接続し、構成変更をおこないます。






【参考】 AdminAgentの構成情報

AdminAgentは<WAS_PROFILE_ROOT>/config下にAdminAgent自身の構

成ファイルを保管

AdminAgentは配下のノードの構成情報を持たない

– AdminAgentが保有するノード情報は管理情報のみ(WAS_PROFILE_ROOTやセル名、ノード名情報など)

NodeAdminAgent

wsadmin

AdminAgent

管理対象ノード




AdminAgentセルの構成ファイル

AdminAgent配下のノードの管理情報

AdminAgentノードの構成ファイル

AdminAgentサーバーの構成ファイル








AdminAgent構成情報



AdminAgentは<WAS_PROFILE_ROOT>/config下にAdminAgent自身の構成ファイルを保管します。AdminAgentに統合しているシングル・サーバー・ノードの構成情報は持ちません。AdminAgentが保有するシングル・サーバー・ノード情報は管理情報のみになります。AdminAgent管理コンソールを使用して配下のシングル・サーバー・ノードの構成を変更した際は、シングル・サーバー・ノードの構成ファイルが直接変更されます。






【参考】管理ツール

WAS構成情報変更、起動･停止などのオペレーションを行うツールには以下の

ものがある

– 管理コンソール

– wsadmin– コマンド行ツール

– JMXプログラム

ノード

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



ノード



NA

マスター構成情報

AS 管理サービス/JMX


ノード構成情報

Job Managerノード

管理サービス/ JMX 管理コンソール･アプリケーション

Job Manager構成情報

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



ノード


AS 管理サービス/JMX


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



wsadmin wsadmin

コマンド行ツールコマンド行ツール


wsadmin

コマンド行ツール

WASの構成情報の変更や、起動・停止などのオペレーションを行うツールには、上記4つがあります。

・管理コンソールはisclite.earというJ2EEエンタープライズ･アプリケーションです。

・wsadminは<WAS_PROFILE_ROOT>/binに実行可能ファイルとして用意されています。wsadminはアプリケーション・サーバーやデプロイメント・マネージャーなどのプロセスに対しSOAP/http、RMI/IIOP、JSR160RMI、IPC経由でアクセスします。デフォルトの接続タイプはSOAPです。

バッチプログラムなど運用スクリプトに管理系オペレーションを組み込むにはこのwsadminを使用します。セル環境では管理コンソールはデプロイメント・マネージャー上で稼動するのでデプロイメント・マネージャーに対してのみ操作を行えますが、wsadminに関してはホスト名、ポート番号を指定すればアプリケーション・サーバーやノード・エージェントなど各プロセスに対して実行可能です。






管理コンソールhttp://<hostname>:9060/ibm/consolehttp://<hostname>:9060/ibm/console

http://<hostname>:9043/ibm/consolehttp://<hostname>:9043/ibm/console管理セキュリティーOFF

管理セキュリティーON

New

New

管理コンソールはGUIベースのWAS管理ツールです。管理コンソールから、アプリケーション・サーバーやアプリケーションの構成情報の変更や、アプリケーション・サーバーの起動・停止などの状態の変更を行うことができます。ほとんどのWAS構成情報の変更は管理コンソールから行うことができます。上記画面はデプロイメント･マネージャーの管理コンソールです。この管理コンソールを使用するには、http://<hostname>:<ポート番号>/ibm/consoleにアクセスして下さい。この時のポート番号は、該当のデプロイメント･マネージャーのWC_adminhost（デフォルト9060）を指定してください。管理セキュリティを設定している場合はWC_adminhost_secure（デフォルト9043）を指定して下さい。

HTTPサーバーがセルの管理対象となっているため管理コンソールからの管理が可能になっています、また別ツールであったTivoli Performance Viewerが管理コンソールの一メニューとして統合されています。

WAS V8では、デプロイメント・マネージャーの管理コンソールからいつかのJob Manager機能を利用できるようになりました。

また、管理コンソール上からJavaダンプや、Javaコアファイルを取得できるようになりました。






【参考】管理ツール-wsadmin

wsadmin

AdminControl

AdminConfig

AdminApp

Help

AdminTask

構成データの操作

WASプロセス内で稼動するMBeanの操作

エンタープライズ･アプリケーションの操作

管理コマンドの実行

ヘルプ、MBean情報の表示

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

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

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

コマンド実行スクリプト実行

構成情報に対する操作構成情報に対する操作

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

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

> wsadmin –lang jython –f list.py> wsadmin –lang jython –f list.py

wsadminは管理用スクリプト･インターフェースです。 WAS関連の構成変更はすべてwsadminから実行することができます。wsadminを実行するには、接続先のプロセスが起動している必要があります。また、JaclとJythonの2種類のスクリプト言語がサポートされます。wsadminコマンド実行時のデフォルトはJaclであり、Jythonを用いる場合は-langオプションの指定が必要です。

wsadminには、インタラクティブ・モード、コマンド実行モード、スクリプト実行モードの3つの実行モードがあります。インタラクティブ・モードは対話形式で、順にコマンドの入力、実行を繰り返します。コマンド実行モードでは、実行したい処理内容を引数で渡します。1回の実行につき、1処理のみの実行になります。スクリプト実行モードでは、処理内容をあらかじめ記述したスクリプトファイルを引数に渡して実行します。運用局面での、実行コマンドが複数に及ぶ場合には、コマンド実行モードでは毎回JVMが起動され、スクリプト実行モードで同じ処理を実施するよりマシンへの負荷が高くなりますので、スクリプト実行モードがお勧めです。

WASの構成可能なオブジェクトは全てJMXのMBean (Management Bean)と関連付けられています。MBeanはJMX APIを使用して管理するユーザーのための属性のgetter、setterやstart、stopなどを持ちます。管理コンソールもwsadminもいずれもこのMBeanを操作してWASの管理を行います。

wsadminコマンドの基本シンタックスは、上記のように管理オブジェクトを指定し、その管理オブジェクトに対して実行できるコマンドに必要に応じてパラメーターを指定します。管理オブジェクトは管理対象のMBeanをカテゴライズしたもので、構成データの操作を行う『AdminConfig』、エンタープライズ･アプリケーション関連操作をまとめた『AdminApp』、管理コマンドを実行するための『AdminTask』、スタート/ストップなどオペレーション操作『AdminControl』、ヘルプおよびMBean情報の表示を行う『Help』の計5種類があります。






【参考】管理ツール-コマンド行ツール

WAS関連のオペレーションの一部をシェル(バッチ)スクリプト化したツール

– 起動・停止など

– Job Managerの起動･停止

– AdminAgentの起動･停止

wsadminとの相違点

– ローカルでのみ実行可能

– 各コマンドの実行ログが取得される

コマンド行ツールのセキュリティー– コマンドによって、ユーザーID/

パスワードの認証が必要

• stopServer, serverStatusなど

start(stop)Server.sh(bat) jobmgr

start(stop)Server.sh(bat) adminagent

manageprofilesstartServerstopServerstartManagerstopManagerstartNodestopNodeaddNodeserverStatuscleanupNodesyncNodebackupConfigrestoreConfigEARExpanderGenPluginCfgversionInfogenVersionReporthistoryInfogenHistoryReport …etc


コマンド行ツールは、WAS関連のオペレーションの一部をシェル(バッチ)スクリプト化したツールです。アプリケーション・サーバーの起動・停止などのコマンドが準備されています。

wsadminとは異なり、ローカルのプロファイル上のアプリケーション・サーバーなどのプロセスに対して、操作を実行することができます。また、プロセスが必ずしも起動している必要はありません。

コマンド行ツールのコマンドは、<WAS_ROOT>/binまたは<WAS_PROFILE_ROOT>/bin以下に配置されています。各コマンドは、実行のたびに、下記のファイルにログが記録されます。

<WAS_PROFILE_ROOT>/logs/<command_name>.log

<WAS_PROFILE_ROOT>/logs/<SERVER_NAME>/<command_name>.log

尚、このログは、追記形式であるため、少しづつですがサイズが大きくなりますので、ご注意ください。

また、管理セキュリティーをONにしている場合は、wsadminのときと同様に、ユーザーIDとパスワードによる認証が必要なコマンドがあります。引数に-username、 -passwordオプションを指定するか、soap.client.propsプロパティーファイルに、セキュリティーONの設定とユーザーID、パスワードを指定する必要があります。

各コマンド行ツールの詳細は下記のInfoCenterの記載を参照ください。






ノード管理機能の拡張

addNodeに「asExistingNode」オプションが新規追加

New

ノードのリカバリーはより迅速ノードのリカバリーはより迅速

ノードを別ホスト、別OSへの移動も可能ノードを別ホスト、別OSへの移動も可能

セルの複製はより便利セルの複製はより便利



asExistingNode

asExistingNode

asExistingNode

コマンド行ツールのaddNodeコマンドに新たに「asExistingNode」オプションが追加され、ノードのリカバリーや移動などのノード管理機能が拡張されました。

ハードウェア障害発生した場合、「asExistingNode」オプションを利用して、ノードのリカバリー手順はより簡単になりました。

リカバリー先は別ホスト、別ＯＳでも可能です。

また、このオプションを利用してセルを複製することもより容易になりました。






AS

NA

/node1

DM

従来のノード・リカバリー

従来、WASノードにハードウェア障害発生時、以下のリカバ

リー手順を踏む必要があった

Config.zip

Config.zip

1．backupConfig

2．removeNode

4．manageprofiles（新規作成)

5．addNode

6．restoreConfig

7．syncNode

12

4

6

3

3．manageprofiles（削除)

/DMNode/node1

AS

NA

/node1

7 5

WASV8以前、ノード障害発生した際、ノードの一般的なリカバリー手順は以下の通りです。

１．ノード情報を含むデプロイメント・マネージャーの構成情報をバックアップ（backupConfigコマンド）

２．デプロイメント・マネージャーから障害ノードを除去（removeNodeコマンド）

３．障害ノードのプロファイルを削除

４．新規プロファイルを作成

５．addNodeコマンドで新規ノードをデプロイメント・マネージャー管理配下に統合

６．バックアップからデプロイメント・マネージャーの構成情報をリストアー（restoreConfigコマンド）

７．ノードの同期化（syncNodeコマンド）






AS

NA

AS

NA

DM/DMNode/node1

asExistingNodeを使ったノードのリカバリー（１）

ハードウェア障害発生時、ノードを迅速にリカバリー– WAS V8では、addNodeコマンドに新たに「asExistingNode」オプションが

追加された

– ノード・リカバリーの手順が大幅に簡略化

1

New

＜同ネーミング＞

•ﾌﾟﾛﾌｧｲﾙ名

•ﾌﾟﾛﾌｧｲﾙ・ﾃﾞｨﾚｸﾄﾘｰ

•ノード名

•ホスト名

＜同ネーミング＞



•ノード名

•ホスト名

addNode.sh(bat) <DM_host> <DM_port> -asExistingNode

2

backupConfig

removeNode


4．syncNode

1．manageprofiles（削除)

3．addNode -asExistingNode

restoreConfig/node1 /node1

34

WAS V8では、addNodeコマンドに新たに「asExistingNode」オプションが追加ました。ノード障害が発生した際、以下の手順でノード・リカバリーを行うことができます。（前提：ノード構成情報はデプロイメント・マネージャーに保存されている）

１．障害ノードのプロファイルを削除

２．新規プロファイルを作成

３．新規プロファイル配下の「bin」ディレクトリーで、addNodeコマンドを「asExistingNode」オプション付きで発行し、新規ノードをデプロイメント・マネージャー管理配下に統合

４．ノードの同期化（syncNodeコマンド）






ホストＢホストＢ

AS

NA

/node1

ホストＡホストＡ

AS

NA

/node1

DM/DMNode/node1

wsadmin -lang jython -userName <user_name> -password <password>AdminTask.changeHostName('[-hostName <new_host_name> -nodeName <node_name>]')AdminConfig.save()

asExistingNodeを使ったノードのリカバリー（２）

ハードウェア障害発生時、ノードを別ホストに移動する場合– 前提：移動先ホストは同一OS、同一インストール・ディレクトリー

– 手順はノードのリカバリーのプロセスと類似

– ホスト名の変更が必要

2

1．changeHostName


3． addNode -asExistingNode

4．syncNode1

＜同ネーミング＞：

•WASｲﾝｽﾄｰﾙ・ルート



•ノード名


•WASｲﾝｽﾄｰﾙ・ルート



•ノード名

New

34

ノードを別ホストに移動する場合の手順は前述ノードのリカバリー手順と類似します。

ノード・エージェントとアプリケーション・サーバーのプロセスを停止してから、以下の手順を実施します。

１．デプロイメント・マネージャーからAdminTask.changeHostNameコマンドを実行し、ノードのホスト名を変更

２．新しいホストにWASをインストールし、新規プロファイルを作成。WASインストール・ディレクトリー、プロファイル名、プロファイル・ディレクトリー名、ノード名は、もとのノードと同様にする。

３．新規プロファイル配下の「bin」ディレクトリーで、addNodeコマンドを「asExistingNode」オプション付きで発行し、新規ノードをデプロイメント・マネージャー管理配下に統合

４．ノードの同期化（syncNodeコマンド）







AS

NA

/node1


AS

NA

/node1

DM/DMNode/node1

asExistingNodeを使ったノードのリカバリー（３）

OSやインストール・ディレクトリーが異なってもノードの移動が可能

– 前提：移動先ホストは別OS／別インストール・ディレクトリー

– WebSphere変数の値変更が必要

• WAS_INSTALL_ROOT • USER_INSTALL_ROOT

– 制約

• ジョブ・スケジューラーを利用するアプリケーションは、ホスト名が異なる場合は無効

• z/OSと非z/OS間のノード移動は不可

3

New

2．changeHostName



5．syncNode

1



•ノード名



•ノード名

1．WAS変数の変更

2

45

OSやWASのインストール・ディレクトリーが障害ノードと異なっていても、ノードの移動が可能です。

ノード・エージェントとアプリケーション・サーバーのプロセスを停止してから、以下の手順を実施します。

１．管理コンソールから「環境」＞「WebSphere変数」の順にクリックし、「 WAS_INSTALL_ROOT 」と「 USER_INSTALL_ROOT 」の値を変更。

２．デプロイメント・マネージャーからAdminTask.changeHostNameコマンドを実行し、ノードのホスト名を変更。

３．新しいホストにWASをインストールし、新規プロファイルを作成。WASインストール・ディレクトリー、プロファイル名、プロファイル・ディレクトリー名、ノード名は、もとのノードと同様にする。

４．新規プロファイル配下の「bin」ディレクトリーで、addNodeコマンドを「asExistingNode」オプション付きで発行し、新規ノードをデプロイメント・マネージャー管理配下に統合

５．ノードの同期化（syncNodeコマンド）






セル

【参考】ノードのリカバリー(1)

検証シナリオ

検証手順

WAS01Node01

WAS01Node02のプロ

ファイルCustom02を

削除

プロファイル1:：Custom01プロファイル２：Custom02ノード１： WAS01Node01ノード２： WAS01Node02ホスト名： localhost

プロファイル1:：Custom01プロファイル２：Custom02ノード１： WAS01Node01ノード２： WAS01Node02ホスト名： localhost

新規にCustom02プロファイル

を作成

「asExistingNode」オプ

ション付きでaddNodeを

発行

WAS01Node02が正常に

復元されたことを確認

DM

AppServer1

WAS01Node02

AppServer2

セル

WAS01Node01

DM

AppServer1

WAS01Node02

AppServer2







リカバリー手順– ①障害が発生した「WAS01Node02」ノードのプロファイルを削除

– ②WAS01Node02上、新規カスタム・プロファイルを作成

プロファイル名とパス名は障害ノードと同様にする

・プロファイル名：Custom02

・パス：<profile_Root>¥Custom02

ノード名、サーバ名、ホスト名は障害ノードと同様にする

・ノード名：WAS01Node02

・サーバ名：AppServer02

・ホスト名：localhost

「後でこのノードを統合する」を選択

{WAS_INSTALL_ROOT}¥bin>manageprofiles.bat –delete –profileName Custom02







リカバリー手順

– ③デプロイメント・マネージャーを開始

– ④新規作成されたプロファイルの配下よりaddNode –asExistingNodeコマンドを発行

– ⑤管理コンソール上、ノードが正常に追加されたことを確認

{WAS_INSTALL_ROOT}¥profiles¥Custom02¥bin>addNode.bat localhost 8879 -asExistingNode







AS

NA/node1

DM


AS

NA/node1

DM

DM /DMNode/node1

asExistingNodeを使ったセルの複製

WAS構成情報のバックアップ機能（backupConfig/restoreConfig）と組み合わ

せて、セルを複製することが可能

– セル名の変更は不可

New


3．restoreConfig


7．syncNode

1．backupConfig

Template.zip

Template.zip

6

1

6

2 24．WAS変数の変更

4,5 4,5

5. changeHostName

7 7

/DMNode/node1

/DMNode/node1

3

asExistingNodeオプションのもう１つの使い方は、セルの複製です。

セルの複製は以下の手順で実施可能です。

１．複製元のセル情報をbackupConfigコマンドを使用してバックアップを取得。

２．複製先のマシーンにWASをインストールし、新規プロファイル（デプロイメント・マネージャー、アプリケーション・サーバー・ノード）を作成。

３．バックアップから複製先のデプロイメント・マネージャーの構成情報をリストアー（restoreConfigコマンド）

４．管理コンソールから「 WAS_INSTALL_ROOT 」と「 USER_INSTALL_ROOT 」の値を変更。

５．デプロイメント・マネージャーからAdminTask.changeHostNameコマンドを実行し、ノードのホスト名を変更。

６．新規プロファイル配下の「bin」ディレクトリーで、addNodeコマンドを「asExistingNode」オプション付きで発行し、新規ノードをデプロイメント・マネージャー管理配下に統合

７．ノードの同期化（syncNodeコマンド）






プロパティー･ファイル･ベース構成ツール（PFBCT）（1/5）

構成リポジトリー内に分散されている構成ファイル群から名前/値が対になったプロパ

ティー･ファイルを作成

– プロパティー・ファイルを作成するため、リポジトリーからデータ（プロパティー名と値）を抽出

– プロパティー・ファイルのデータをターゲット・リポジトリーに適用

構成プロパティー･ファイル

Property_name = “foo”

Scope = Server

Name = “server1”

maximumHeapSize= 1024

requestTimeout=180

# ---------------------------

# comment line

# ---------------------------

構成リポジトリー

Properties File BasedConfiguration Tool

ユーザーにとって現行の構成ファイルよりもわかりやすい

ユーザーにとって現行の構成ファイルよりもわかりやすい

構成ファイルではないので、プロパティー･ファイルを変更しただけ

では構成変更はできない

構成ファイルではないので、プロパティー･ファイルを変更しただけ

では構成変更はできない

プロパティー･ファイル･ベース構成ツール(PFBCT)はV7から登場した管理ツールです。WASの構成ファイルは構成リポジトリー内の複数のサブ･ディレクトリーにXMLとして分散されて配置されており、特定のプロパティー値を構成ファイル群から見つけ出すのは容易なことではありません。PFBCTは構成ファイル群からプロパティー名と値が対になった、ユーザーにとって現行の構成ファイルよりもわかりやすいプロパティー･ファイルを作成します。ただし、このプロパティー･ファイルは構成ファイルではないため、プロパティー･ファイル内のプロパティー値を変更しただけでは構成変更に反映されません。プロパティー値を変更後にプロパティー･ファイルを構成に適用する、という手順が必要になります。






PFBCTはAdminTaskオブジェクトのコマンド群

– 以下のコマンド･オプションを使用してプロパティー・ファイルで構成を実施する

– extractConfigProperties• 構成データをプロパティー・ファイルの形式で抽出する

– createPropertiesFileTemplates• 特定のオブジェクトの作成・削除に使用するテンプレート・プロパティー・ファイルを作成する

– applyConfigProperties• あるプロパティー・ファイルのプロパティーを構成に適用する

– deleteConfigProperties• プロパティー・ファイルに指定したように構成からプロパティーを削除する

– validateConfigProperties• プロパティー・ファイルのプロパティーが有効で構成に安全に適用可能か検証する


PFBCTはAdminTaskオブジェクトのコマンド群であり、上記のコマンド・オプションを使用してプロパティー・ファイルでの構成を実施します。







V7.0.0.9 で追加された機能

– 構成可能なオブジェクト・プロパティーの種類が増加

• 以下のいずれかで構成する

- extractConfigPropertiesコマンドでオブジェクトを抽出

- InformationCenter にあるテンプレートを修正し、適用する

– プロパティー・ファイル内で、wsadmin 管理コマンドを指定可能

• wsadminのコマンドをプロパティー・ファイルで指定し実行させることが可能に

– 別環境への複製のためのオプションが追加

→環境のコピー、マイグレーション・シナリオへの適用（次ページ）

Update

# CreateDeleteCommandProperties=true #SKIP=true commandName=createSIBus# # #Properties # busSecurity=false #Boolean …

wsadmin> AdminTask.createPropertiesFileTemplates('[-propertiesFileName createSIBus.props-configType GenericType -options [[commandName createSIBus]] ]')

プロパティー・ファイル・ベース構成ツール（PFBCT）はWAS V7のFixPack 9で機能拡張され、WASの構成において適用範囲が広がりました。

FixPack 9以前は、抽出したプロパティー・ファイルに含まれていたのは、各オブジェクトの主要なプロパティーのみでした。しかし、FixPack 9以降、WASの構成オブジェクトのすべてのプロパティーを抽出し、変更後に適用できるようになりました。既存の構成からプロパティーを抽出する方法の他に、InformationCenter に各種構成オブジェクトのプロパティー・ファイルのテンプレートが追加されていますので、それをテキスト・エディターにコピーし必要箇所を修正の上、システム構成に適用することができます。

PFBCTで新規にオブジェクトを作成する場合、createPropertiesFileTemplate コマンドを使用することでテンプレート・ファイルが作成され、そのファイルを修正・適用することで作成することができましたが、-configType に指定できるのは、Server、ServerCluster、Application、AuthorizationGroupに限られていました。FixPack 9からは、-configTypeに GenericTypeを指定し、-optionsで管理コマンドを指定できるようになりました。この機能によりこれまで管理コマンドで作成するしかなかったオブジェクトもPFBCTで作成、変更することができるようになります。

もう1つの機能追加はプロパティー・ファイルを別環境へ移植することができるようになった点です。次ページ以降で詳しくご説明します。







別環境への複製– V7.0.0.9 まではプロパティー・ファイルの環境固有のIDが含まれており再利用できなかった

– V7.0.0.9 から環境固有のIDを含めないオプションが追加 →PortablePropertiesFile

wsadmin>AdminTask.extractConfigProperties('[-propertiesFileName appserver1.props -configDataServer=appserver1]')

wsadmin>AdminTask.extractConfigProperties('[-propertiesFileName appserver1.props2 -configDataServer=appserver1 -options [[PortablePropertiesFiletrue]] ]')

## SubSection 1.0.1 # StateManageable Section#ResourceType=StateManageableImplementingResourceType=ServerResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:StateManageable=

AttributeInfo=stateManagement#・・・

## SubSection 1.0.1 # StateManageable Section#ResourceType=StateManageableImplementingResourceType=ServerResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:StateManageable=ID#StateManageable_1309842541718AttributeInfo=stateManagement#・・・

環境固有のIDが含まれていた

環境固有のIDが無く、他の環境でも使用可能

extractConfigProperties の実行例

WAS V7リリース当初は、PFBCTは同一セル・同一環境での構成管理を前提としていたため、抽出したプロパティー・ファイルには、環境固有のXMI IDが含まれていました。

そのため、特定のセルの構成を他の環境へ適用するといった再利用ができませんでした。

WAS V7のFixPack 9からは、extractConfigProperties コマンドを実行する際に、環境固有のIDを含めないための PortablePropertiesFile オプションが追加されました。

このオプションにより、アプリケーション・サーバーやそれより細かいレベルで構成を複製することができます。

また、複製先のセルに対象のサーバーやクラスターなどのオブジェクトがない場合は、GenerateTemplates オプションを ture に指定して抽出することで適用時に新規にサーバーを作成することもできます。

InformationCenter 「複数の環境にわたる移植可能なプロパティー・ファイルの適用」

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






WAS V8.0WAS V8.0

DM /DMNode/node1/node2/node3/node4

WAS V8.0WAS V8.0

DM/DMNode/node1/node2

～WAS 7.0


別環境への複製– シナリオ1

• WAS V8の構成をセル構成の異なる新たなセルにコピーしたい→セル構成が異なれば backupConfig/restoreConfig でのコピーができない→PFBCTではプロパティー・ファイルの編集により必要な構成情報を繰り返し実行可能

– シナリオ2• マイグレーションに使用し、新環境への段階移行を行う

→マイグレーション・ツールを使う場合、環境をそのまま一度に全て引き継ぐことになる→そこから構成情報のみを抽出して、新規作成したWAS8セルに適用する

きめ細かく柔軟な構成が可能

新規作成したWAS8環境に対して、段階的に旧環境の構成情報の適用が可能

プロパティー・ファイルMigration

Toolでの移行

プロパティー・ファイルの移植が可能になったことにより、新たにPFBCTを使用したシステム管理のシナリオが検討可能になりました。

■シナリオ1

作成済みのWAS V8環境から、類似のWAS V8環境を構築する場合に、PFBCTの適用が考えられます。

セル構成やノードの構成を丸ごと複製する場合には、WAS V8の新機能の addNode の -asExistingNode オプションと backupConfig/restoreConfig を組み合わせることで実現できるようになりました。

構成を全て複製するのではなく、例えば、JVMの設定のみ、JDBC関連の構成のみをコピーしたいといった要件がある場合には、PFBCTによって必要なプロパティーのみ抽出し、必要箇所を修正後に適用可能ですので、有用な手段となります。一度抽出したファイルは、パラメーターを適宜修正すれば、他の環境で適用できるため、アセットとして残しておくことができますし、変更管理も容易になります。

■シナリオ2

マイグレーションの際にも、PFBCTを活用することで柔軟な構成管理を行うことができます。

WASに付属されるマイグレーション・ツールを使用すると、旧バージョンのWASから構成が全て引き継がれ、WAS V8のセルに移行されます。引き継ぎたくないパラメーターや修正箇所が多くなる場合には、手作業での修正や削除が必要となり工数がかかってしまうことが考えられます。

段階的かつ効率的な移行を行うために次のようなシナリオが考えられます。

まず、一時的にマイグレーション・ツールを使用してWAS V8への移行を実施し、そのセル内で必要なプロパティー・ファイルを抽出します。別途、WAS V8のセルを新規に作成し、抽出したプロパティー・ファイルを必要に応じて修正し、適用することで任意のパラメーターのみを引き継ぐことが可能です。






プロパティー･ファイル･ベース構成ツールの使用例①

server1の構成をカスタマイズする

①server1の既存構成からプロパティー・ファイル(config.props)を作成

②テキスト・エディターを使ってプロパティーを変更

③変更したプロパティーをserver1の構成に適用

④構成の保管

wsadmin> AdminTask.extractConfigProperties(‘[-propertiesFileName config.props-configData Server=server1‘ -options [[PortablePropertiesFile true]] ]')

wsadmin> AdminTask.applyConfigProperties(‘[-propertiesFileName config.props]’)

wsadmin> AdminConfig.save()

こちらはも基本的なPFBCTの使い方です。初めにAdminTask.extractConfigPropertiesを使用してserver1の構成からプロパティー値を抽出し、config.propsという名前のプロパティー･ファイルを作成します。他のセル環境への適用を行うためには、オプションで PortablePropertiesFile true を指定します。プロパティー･ファイルを作成したらテキスト･エディターで該当のプロパティー値を変更します。そしてAdminTask.applyConfigPropertiesを使用してプロパティー･ファイルをserver1に適用します。後に構成を保管すると、server1の構成ファイルにプロパティー値の変更が反映されます。






プロパティー･ファイル･ベース構成ツールの使用例②

VariableMapを使用してserver1の構成をカスタマイズする

– server1の既存構成からプロパティー・ファイル(config.props)を作成

– ファイル内の変更するプロパティー値を変数に変更

– （例）

– VariableMap（variableMap.vars）を作成し、変更後のプロパティー値を記入

– (例)

– プロパティー･ファイルをVariableMapを使用してserver1の構成に適用、構成の保管

initialHeapSize=64

maximumHeapSize=128

変更前プロパティー･ファイル

･･････

initialHeapSize=!{initialHeapSize}

maximumHeapSize=!{maximumHeapSize}

･･････

initialHeapSize=128maximumHeapSize=256

VariableMap

wsadmin> AdminTask.applyConfigProperties(‘[-propertiesFileName config.props -variablesMapFileName variableMap.vars]‘）

wsadmin> AdminConfig.save()

こちらはserver1のプロパティー･ファイルのプロパティー値を直接変更するのではなく、VariableMapというものを使用して変更する手順です。VariableMapとは変更後のプロパティー値を記述したテキスト･ファイルです。VariableMapを使用する場合、プロパティー･ファイル内で変更するプロパティー値を変数に変えておく必要があります。変数は!{プロパティー名}の形で記述します。

複数のプロパティー値を調整しながら何度も変更する場合などは、VariableMapのプロパティー値を変更して構成に適用することで、毎回プロパティー･ファイルの中から該当のプロパティー値を探し出す必要がないので便利です。






WAS V8のJava SE 環境

JDKのバージョンはV7と同じくJava SE 6.0

GCのデフォルトがoptthruputからgenconに変更– 大きなヒープサイズのGCに対応

balanced GCポリシーが追加

C:¥IBM¥WebSphere¥AppServer80¥java¥bin>java -version

java version "1.6.0"

Java(TM) SE Runtime Environment (build pwi3260_26fp1-20110419_01)

IBM J9 VM (build 2.6, JRE 1.6.0 Windows XP x86-32 20110418_80450 (JIT enabled, AOT enabled)

New

重要

C:¥IBM¥WebSphere¥AppServer80¥java¥bin>java –fullversion

java full version "JRE 1.6.0 IBM Windows 32 build pwi3260_26fp1-20110419_01 (FP1)"

WAS V8のGCは「Java EE 6 パート1」のセッションにて詳しくご説明致します

WAS V8ではJDKのバージョンはWAS V7と同じくJava SE 6.0を使用します。

Java関連での変更は、GC(Garbage Collection)のデフォルトが、optthruputからgenconに変更になった点と、新しいGCの仕組みとしてbalanced GCが追加になった点です。

これらの変更点に関しては、「Java EE 6 パート1」で詳しくご説明いたします。






問題判別・パフォーマンスチューニング






各コンポーネントで取得する主なログ

出力する製品や階層に応じてさまざまなログが出力される

Edge/Secure Proxy

Edge/Secure Proxy

ApplicationServer

ApplicationServerWebServerWebServer HTTP(S)HTTP(S) DBJDBCHTTP(S)

activity.logSystemOut.logSystemErr.lognative_stdout.lognative_stderr.logtrace.logFFDChttp_access.loghttp_error.log

access.logerror.loghttp_plugin.log

server.logmanager.logproxy.logcache.log

WASおよびIHS、Edgeといった製品同梱のコンポーネントや階層ごとに出力されるログをまとめています。

WAS V8で出力されるログはWAS V7と変わっていません。






ログ一覧(1/3)

WASで取得されるログ

– IBM保守ログ(activity.log)• ノード単位に出力され、JVMログより詳細な情報を記録

• Log and Trace Analyzer ToolもしくはShowlogコマンドで確認

– JVMログ(SystemOut.log、SystemErr.log)• JVMの標準出力、標準エラー出力を記録し、問題判別でも重要

• アプリケーション･サーバー、ノード･エージェント、デプロイメント･マネージャーといったJVM単位に出力

され、アプリケーションの挙動やプロセスの稼動状況を記録

– プロセスログ(native_stdout.log、native_stderr.log)• JVM単位に出力され、JVM自身を含むネイティブ･コードの標準出力、標準エラー出力を記録

– 診断トレース(trace.log)• JVM単位に出力され、WASコンポーネントの処理の詳細を記録

– FFDCログ(<process_name>_<timestamp>.txt)• JVM単位に出力され、システムエラーが発生した時点で記録される(first failure data capture)• 主にIBMサポート部門、開発部門が問題発生時に参照

問題判別をおこなう際、ログファイルは重要な情報源となります。WAS、IHS、Plugin、Secure Proxyで取得可能なログをまとめています。






ログ一覧(2/3)

WASで取得されるログ(続き)– HTTPトランスポートログ(http_access.log / http_error.log)

• JVM単位に出力され、WebコンテナーのHTTPトランスポートに対するアクセスを記録

– セキュリティー監査ログ(BinaryAudit_<cell_name>_<node_name>_<server_name>.log)• JVM単位に出力され、管理オペレーションに対する監査情報を記録

IHSで取得されるログ

– アクセスログ(access.log)• IHSに届いたリクエストの処理を記録

– エラーログ(error.log)• IHSのリクエスト、もしくは処理中に発生したエラーやワーニングを記録

Pluginで取得されるログ

– Pluginログ(http_plugin.log)• Pluginの処理内容を記録

• Webサーバー(IHS)とWAS間の通信に問題があるときに参照






ログ一覧(3/3)

Secure Proxyで取得されるログ

– プロキシー・アクセス・ログ(proxy.log)• Proxy Serverに届いたリクエストの転送処理を記録

– ローカル・アクセス・ログ(local.log)• 転送対象でないリクエストに対するProxy Serverの処理を記録

– キャッシュ・アクセス・ログ(cache.log)• キャッシュにヒットした際に、そのアクセス情報を記録

– JVMログ(SystemOut.log、SystemErr.log)• JVMの標準出力、標準エラー出力を記録し、問題判別でも重要

– プロセスログ(native_stdout.log、native_stderr.log)• JVM単位に出力され、JVM自身を含むネイティブ･コードの標準出力、標準エラー出力を記録

– 診断トレース(trace.log)• JVM単位に出力され、Secure Proxyコンポーネントの処理の詳細を記録






High Performance Extensible Logging (HPEL) (1/4)

V8ではロギングのモードを選択することが可能に

– 通常モード

– HPELモード→従来のファイル形式の出力ではなく、ログ・データをバイナリー形式でリポジトリーに蓄積するログ方式→必要なデータをフィルタリング、整形してログ分析を実施（管理コンソール、logViewer コマンド）

Java ログ

システム出力

システムエラー

Java トレース logdatatracedata

テキスト形式フィルタリング整形、可読化蓄積

ログ・リポジトリートレース・リポジトリーログ・データ

テキスト形式

テキストモード

バイナリーモード

HPELの構成

–HPEL ロギング

–HPEL トレース

–HPEL テキスト・ログ（オプションでの設定）

New

従来のロギングモードに比べてパフォーマンスが向上、V8ではHPELを推奨

WAS V8では、新機能として High Performance Extensible Logging (HPEL) というロギングのモードを選択することができるようになりました。

HPEL モードとは、従来のファイル形式の出力とは異なり、生成されるログ・データをバイナリー形式でリポジトリーと呼ばれるディレクトリーに蓄積していくログ方式です。

HPEL モードでは、バイナリー形式でファイルに出力されるため、ログを閲覧する場合にはlogViewer ツールもしくは管理コンソールで表示させます。

従来のログ方式が置き換わるわけではなく、通常モードとHPELモードを選択することができます。デフォルトは従来の通常モードとなっています。

HPEL モードは、HPELロギング、HPELトレース、HPELテキスト・ログを構成します。HPEL ロギングでは、システム出力、システム・エラーといったログ・データをログ・リポジトリーにバイナリー形式で蓄積します。同様にHPEL トレースでは、トレースのデータをトレース・リポジトリーに蓄積します。

HPEL モードにすると必ずバイナリー・モードで出力されますが、オプションでテキスト・モードで出力させることも可能です。







tracedata /*.wbl

logdata /*.wbl

logdata /*.wbl

HPELモード

（バイナリー・モード）

logdata /*.wblTextLog_<timestamp>.log

SystemOut.logtrace.log

診断トレース（詳細とその上位レベル）

tracedata /*.wblTextLog_<timestamp>.log

trace.log診断トレース（詳細より下位レベル）

logdata /*.wblTextLog_<timestamp>.log

SystemOut.logSystemErr.log

システム出力

システムエラー

HPELモード

（バイナリー・モード＋テキスト・モード）

通常モード（～V7と同様）

※デフォルトの出力先ディレクトリーは、全て ${SERVER_LOG_ROOT} 以下

通常モードとHPELモードの相違点

– 通常モードはテキスト形式でのログ書き出し。HPELモードではバイナリー形式（※ただし、HPELでもテキスト・モードでのファイル出力が可能）

– 提供されるログ・データ（ファイル）の循環方式• HPELではパージの仕組みあり

– ログ閲覧方法（HPELではlogViewer経由でログ閲覧）

ログおよびトレースの出力先

通常モードとHPELモードの相違点をまとめています。通常モードはテキスト形式のファイルへの出力、HPELモードではバイナリー形式でlogdataディレクトリーもしくはtracedataディレクトリーへログ出力されます。HPELモードでは、テキスト・モードを有効にすることでテキスト・ファイル形式での出力も可能ですが、システム出力、システム・エラー、トレースデータすべて1つのファイルへ書き出されます。

循環方式について、従来のロギング・モードではファイルベースの循環方式でしたが、HPELでは古いデータがパージされる仕組みとなっています。設定項目、方法については後で詳しく紹介します。

また、閲覧方法も異なります。HPEL モードのバイナリー形式のログはテキスト・エディター等で開けないため、ツールを使用して閲覧する必要があります。






0

5000

10000

15000

20000

25000

30000

35000

40000

45000

スル

ープ

ット

( /

min

)

0

50

100

150

200

250

300

350

400

平均

応答

時間

(m

s)

これまでは、トレースの負荷が大きかったため本番環境ではトレースをONにできなかった

HPELによるパフォーマンス改善により本番環境でのトレース ON が現実的に

通常モードトレース無し

通常モードcom.ibm.ws.session.*=all

ISE 検証環境における簡易パフォーマンス･テストの結果

約14% のスループット・ダウン

応答時間の増大は軽微


HPELモードcom.ibm.ws.session.*=all

スループット

平均応答時間

これまでは負荷が大きいために本番環境ではトレースをONにすることができませんでした。

HPELではログ書き込み時のパフォーマンスが従来のロギング（通常モード）に比べて向上するため、本番環境でもトレースの取得を検討できます。

ここでは、HPELモードのロギングを行う際のパフォーマンスについて検証した結果を掲示しています。ISE 環境での簡易パフォーマンス・テスト結果であり、製品のパフォーマンスを保証するものではありませんので参考としてご覧ください。

トレースを取得しない通常モードのロギング時に比べて、トレースを有効にしている(com.ibm.ws.session.*=all) HPELモードのロギングでは約14%のスループットダウンとなりました。応答時間を比較してもそれほど大きな増加はないといえます。一方、通常モードでトレースを取得する (com.ibm.ws.session.*=all) 場合は、スループットは半分以下、応答時間も2倍以上となります。十数パーセントのパフォーマンス低下を許容できるのであれば、本番環境でもHPELモードでのトレースONにすることが可能です。

ただしトレースレベルを (*=all) などとするとHPELモードでもパフォーマンスは顕著に低下しますので、モニターが必要なコンポーネントを絞ってトレースを取得することが重要です。

また、HPELモードでも、バイナリー・モードに加えて、テキスト・モードを有効にしている場合、トレース取得時のパフォーマンスは低下します。






HPEL設定方法

– 管理コンソール• 「トラブルシューティング」>「ログおよびトレース」

>「アプリケーション・サーバー名」

• 「HPELモードに切り替え」をクリック後、サーバーを再起動

– wsadmin

HPELロギングのパージ・ポリシー

– 以下の条件でのパージが可能

• ログ・サイズが大に近づいたとき

• も古いログが存続期限に達したとき

• 期限またはサイズのいずれかの制約に該当したとき

– ファイルシステムの容量不足時にもアクションを指定可能

• サーバーの停止

• 古いレコードのパージ

• ロギングの停止


HPELを設定する方法は、管理コンソールから設定する方法とwsadminコマンドを使用して設定する方法があります。

管理コンソールから有効化するには、「トラブルシューティング」>「ログおよびトレース」>「アプリケーション・サーバー名」をクリックし、「HPELモードに切り替え」ボタンをクリックします。wsadminで有効化する場合、HighPerformanceExtensibleLogging オブジェクトを有効に設定します。コマンドの実行例はInformationCenterを参照してください。

Information Center 「Changing from basic mode to HPEL logging and tracing」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.express.doc/info/exp/ae/ttrb_compToHPEL.html

ログ・レコードのパージはデフォルトで有効になっています。パージ・ポリシーは、「ログ・サイズが大に近づいたとき」、「も古いレコードが存続期限に達したとき」、「期限またはサイズのいずれかの制約に該当したとき」から選択します。スペース不足時のアクションとして、「サーバーの停止」、「古いレコードのパージ」、「ロギングの停止」から選択できます。

「サーバーの停止」を選択している際に、ファイルシステムの使用率が100%に達すると、リクエストを処理できなくなり、数分後にサーバー・インスタンスが停止します。

HPEL ログ構成のデフォルトは「ログ・サイズが大に近づいたとき」で大ログ・サイズのデフォルトは50メガバイトです。

スペース不足時のアクションはデフォルトで「ロギングの停止」が選択されています。

HPEL トレース構成のパージ・ポリシーのデフォルトはHPEL ログ構成と同じく「ログ・サイズが大に近づいたとき」で、スペース不足時のアクションは、「古いレコードのパージ」になっています。






HPEL の読み方 (1/3)


サーバーの開始時間ごとにログをフィルタリングし

て表示可能

時刻を指定してイベントを特定することも可能

表示させる内容とレベルでフィルタリングすることが可能

ロガーや文字列で検索、絞りこみが可能

HPELのログ・レコードを閲覧する方法は、管理コンソールで表示させる方法とlogViewerコマンドで出力させる方法の2通りあります。

管理コンソールでは、ナビゲーション・ツリーから「トラブル・シューティング」‐「ログおよびトレース」をクリックし、対象のサーバー名を選択します。関連項目から「HPEL ログおよびトレースの表示」をクリックするとログ・ビューアーの画面になります。「内容およびフィルターの詳細」を展開すると、表示させるログの絞り込みのオプションを選択できます。








管理コンソールからログ・ファイルのエクスポートが可能

右クリック

表示させたログ・レコードの任意の行で右クリックすると、いくつかのオプションを選択できます。特定のログのメッセージやロガーを「内容およびフィルターの詳細」に追加することが可能です。

また、管理コンソールからログ・ファイルをエクスポートすることも可能です。ログ形式の選択で「バイナリー形式」、「基本形式」、「拡張形式」から、ログ内容の選択で「現行のビューのみ」、「リポジトリー全体」から選択します。







logViewer コマンド

–構文

–実行例

logViewer.sh (bat) [options]

以下のオプションを使用して出力ファイルの指定やフィルタリングを行う

-repositoryDir -minLevel -extractToNewRepository

-format -listInstaces -outLog

-startDate -thread -instance

-stopDate -includeLoggers -latestInstance

-level -excludeLoggers -message

-maxLevel -monitor

logViewer.sh (bat) -outLog /work/waslog/server1_20110711.log –startDate 11/7/10 -stopDate 11/7/11

logViewer.sh (bat) -monitor -includeLoggers SystemErr

-monitor オプションによりリアルタイムのモニタリングも可能

テキストファイルとして出力させることができる

HPELログを閲覧するための管理コマンドのlogViewerの使用方法です。

logViewerコマンドではオプションを使用してフィルタリングやテキストファイル出力など、自在にログを扱うことができます。上記の各オプションについては、InformationCenterもしくはコマンドのhelpオプションを使用して確認してください。

InformationCenter 「LogViewer command-line tool」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rtrb_logviewer.html






ヒープ・ダンプ、Java コア、システム・ダンプ

管理コンソールからヒープ・ダンプ、Javaコア、システム・ダンプを出力可能

New

WAS V8から、ヒープ・ダンプ、Java コア、システム・ダンプを管理コンソールから出力することが可能になりました。

Java関連の問題判別や製品サポート問い合わせ時のデータ収集を容易に行うことができます。






PMI（Performance Monitoring Infrastructure）

– WASのコンポーネントのデータをモニターするインターフェース

– パフォーマンスをモニターするツールはPMIを介してデータを取得して表示

PMI

TPVJVMヒープ使用率、JDBC接続プール内のオブジェクト数、スレッドプール内のスレッド数、セッション作成数・・・・などの情報

PMIを介してデータを取得、表示

デフォルトでOn

「＋」をクリックすると、そのレベルで取得できる情報の一覧が表示される

PMIで取得する情報のレベル（統計セット）を「基本」、「拡張」、「すべて」、「カスタム」から選択

ＤＢサーバー

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

（Webコンテナー）


（Webコンテナー）


（ＥＪＢコンテナー）


（ＥＪＢコンテナー）

PMIはWASにおけるパフォーマンス・データ管理を行なう仕組みであり、デフォルトで使用可能になっています。PMIの設定画面からは、取得する情報のレベルを基本、拡張、全て、カスタムから選択します。そのレベルで取得できる情報の一覧を見ることも可能です。またカスタムについては、データ項目一つ一つに対してモニターの有無を指定することも可能です。






Tivoli Performance Viewer

– WASが提供しているパフォーマンス・モニター・ツール

– 管理コンソールに統合• [モニターおよびチューニング]→[Performance Viewer]

– リアルタイムでデータを表示

– ログの取得と再生が可能

該当サーバーをチェックしモニターの開始をクリックモニターする項目を選択し、モジュールの表示をクリック

WASではパフォーマンス・モニター・ツールが基本機能として提供されています。Tivoli Performance Viewerは管理コンソールに統合されたモニタリング・ツールでリアルタイムにパフォーマンス・データを表示したり、それらのデータをロギングしておくことで後から確認することも可能です。

Tivoli Performance Viewerは、Performance Monitoring Infrastructure（PMI）からパフォーマンス・データを取得します。PMIはアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークで、PMIが取得するデータレベルはカスタマイズ可能です。

Tivoli Performance Viewerを使用することで、アプリケーション・サーバー上の様々なリソース使用状況を確認することができます。そのため、Tivoli Performance Viewerはパフォーマンス・チューニングや問題判別をおこなう際に非常に役に立ちます。Tivoli Performance Viewerを使用する際は、対象のサーバーで｢モニターを開始｣の設定をおこない、モニターする項目を選択し｢モジュールの表示｣をクリックします。リソースの使用状況は、グラフもしくは表形式で確認することができます。






WAS V8.0WAS V8.0

ITCAM for WAS

– IBM Tivoli Composite Application Manager for WebSphere Application Server– WASベースのアプリケーションのパフォーマンス、リソースの消費状況を監視し、リ

アル・タイムにパフォーマンス・データを収集・分析

– ITCAM for WASの「Data Collector」コンポーネントはWASのオプションとして導入

可能

• Data Collector：管理対象のアプリケーション・サーバー上に構成可能なデータ収集エー

ジェント

AS

NA

ＤＢサーバー

DC

Data Collector測定エージェント。WASサーバーのインスタンス毎に導入

WebサーバWebサーバブラウザーブラウザー

PMITivoli Performance Viewer

新たなPMIモジュールを

追加

PMIを介して、新たなパフォーマ

ンス・データ項目を取得、表示

ITCAM for WAS (IBM Tivoli Composite Application Manager for WebSphere Application Server) はWASに同梱されている無償ツールで、WASに追加インストールすることができます。

ITCAM for WAS ではTPVでモニタリングできる項目に加えてアプリケーション・サーバーおよびアプリケーション・サーバー上で実行されているアプリケーションのパフォーマンス、リソースの消費状況に関する情報の収集・分析に役立ちます。ITCAM for WAS をインストールするとWASにData CollectorというITCAMのデータ収集エージェントが組み込まれPMI経由でデータを取得します。ITCAM for WASで取得したデータは他のTPVの項目と同様に管理コンソールから表示させることができます。






ITCAM for WASによって追加されたパフォーマンス・データ項目

説明パフォーマンス・データ項目

要求の総数。RequestCount

応答時間を収集してから、小応答時間をミリ秒単位で計算します。MinimumResponseTime

CPU 使用量を収集してから、小 CPU 使用量をミリ秒単位で計算します。MinimumCPUUsage

応答時間を収集してから、大応答時間をミリ秒単位で計算します。MaximumResponseTime

CPU 使用量を収集してから、大 CPU 使用量をミリ秒単位で計算します。MaximumCPUUsage

終段階の応答時間を収集してから、平均応答時間をミリ秒単位で計算します。LastMinuteAverageResponseTime

終段階の CPU 使用量を収集してから、平均 CPU 使用量をミリ秒単位で計算します。

LastMinuteAverageCPUUsage

応答時間を収集してから、平均応答時間をミリ秒単位で計算します。AverageResponseTime

CPU 使用量を収集してから、平均 CPU 使用量をミリ秒単位で計算します。AverageCPUUsage

応答時間を収集してから、90% メディアンの時間をミリ秒単位で計算します。90%ResponseTime

CPU 使用量を収集してから、90% メディアンの CPU 使用量をミリ秒単位で計算します。

90%CPUUsage

ITCAM for WASを使用することで追加で取得できるデータ項目です。






ITCAM for WASの利用手順(1/2)

ITCAM for WASの開始

– ITCAM for WAS（Data Collector）を導入、構成後、PMIコン

ソール画面上、対象となるアプリケーション・サーバー上に「追加プロパティー」が表示される

– 該当プロパティーをクリックし、ランタイム・タブにて、「Start Monitoring」ボタンを押下

ITCAM for WASのパフォーマンス項目の有効化

– PMIコンソール画面で、「カスタム」の統計セットを選択

– 「ITCAM Application Performance」を展開し、モニターする

データ項目を選択し、使用可能にする

ITCAM for WAS を導入するとPMI コンソール上で追加プロパティーに「ITCAM for WebSphereApplication Server」という項目が追加されます。

「Start Monitoring」をクリックするとITCAM for WASが開始されます。

必要に応じてITCAM for WASのパフォーマンス項目を選択して使用可能にします。






ITCAM for WASの利用手順(2/2)

ITCAM for WASパフォーマンス・データのモニ

タリング

– Tivoli Perfomance Viewを通して、事前選択され

たパフォーマンス・データ項目をリアルタイムでデータを表示






IBM Support Assistant（ISA）

IBMソフトウェアの保守サービスを向上するための無償ツール

– IBM製品に対する技術情報を検索可能

– トラブルシューティングガイド、問題判別ツールを提供

情報検索・IBM ソフトウェア・サポート資料・IBM developerWorks・IBM ニュースグループ / フォーラム・Google・製品のInformationCenter

データ解析・Health Center・Dump Analyzer・Memory Analyzer・Garbage Collection and Memory Visualyzer(GCMV) Analyzer

・・・

データ収集・Health Centerのエージェントを対象のサーバーに導入するとWAS(Java)の多種データを取得可能






ISAを使用したWASのリソース解析

ISAにデータ解析のためのツールをアドオンで追加

– 以下にツールの一部を紹介

Health Center Dump Analyzer

WASのGC（Garbage Collection）の発生状況、停止時間をグラフ表示

ファイルI/Oやクラスに関する情報なども出力可能

V1.3 からはJavaコアも取得可能

システム・ダンプの解析ツール

クラッシュしたJVMやネイティブ・インターフェースの解析に有用






まとめ






まとめ


構成情報の管理

問題判別、パフォーマンス・チューニング

HPEL モードによる、本番環境でのトレース取得が現実的に

ヒープダンプ、Javaコア、システムダンプ等、データ収集方法の簡便化

IIM によるIBMミドルウェア製品全般のインストール基盤の共通化

IIM + CIMによるJobManager 経由での複数台への一括導入

新機能を活用することで効率的に運用・管理タスクを実施することが可能

「asExistingNode」によるノードのリカバリー手順の簡素化

backupConfig / restoreConfig と「asExistingNode」の組み合わせによるセルの複製

プロパティ・ファイル・ベース・構成ツール（PFBCT）を使用した柔軟な構成情報の管理・複製






参考文献

WebSphere Application Server Version 8.0 Information Centerhttp://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp

IBM Installation Manager Version 1.4.4 Information Centerhttp://publib.boulder.ibm.com/infocenter/install/v1r4/index.jsp

WS資料「 WebSphere Application Server V7 アナウンスメント・ワーク

ショップ」

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_ws/index.html

WS資料「 WebSphere Application Server V7.0によるWebシステム基盤

設計ワークショップ」

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_guide/index.html

Date post:	30-May-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

WebSphere Application Server V8public.dhe.ibm.com/software/dw/jp/websphere/was/was8_ws/was_v… ·...

Documents