Cosminexus V11 アプリケーションサーバ 機能解説 運用／監視／連携編

解説書

3021-3-J10-40

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DABroker，HAモニタ，HiRDB，JP1，OpenTP1，TPBroker，uCosminexusは，株式会社 日立製作所の商標または登録商標です。

AIXは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

DB2は，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

EclipseおよびJakartaは，Eclipse Foundation, Inc.の商標です。

IBMは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

Intelは，Intel Corporation またはその子会社の商標です。

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

Microsoft，Active Directory，Excel，Internet Explorer，SQL Server，Windows，Windows Server は，マイクロソフト 企業グループの商標です。

Oracle(R)，Java及びMySQLは，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.

Red Hatは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。

Red Hat Enterprise Linux is a registered trademark of Red Hat, Inc. in the United States and other countries.

Red Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

マイクロソフト製品のスクリーンショットの使用について

マイクロソフトの許可を得て使用しています。

発行

2023年 6月 3021-3-J10-40

著作権

All Rights Reserved. Copyright (C) 2020, 2023, Hitachi, Ltd.

変更内容

変更内容(3021-3-J10-40) uCosminexus Application Server 11-30，uCosminexus Client 11-30，uCosminexus Developer 11-30，uCosminexus Service Architect 11-30，uCosminexus Service Platform 11-30

追加・変更内容

変更個所

機能の分類と機能解説のマニュアルの対応を示す表に，パッケージ名変換機能を追加した。

1.1.3

アプリケーションサーバ11-30での主な機能変更についての説明を追加した。

1.5

マニュアル訂正の内容を反映した。

−

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

第1編　概要

1　アプリケーションサーバの機能

この章では，アプリケーションサーバの機能の分類と目的，および機能とマニュアルの対応について説明します。また，このバージョンで変更した機能についても説明しています。

1.1　機能の分類

アプリケーションサーバは，Java EE 8に対応したJ2EEサーバを中心としたアプリケーションの実行環境を構築したり，実行環境上で動作するアプリケーションを開発したりするための製品です。Java EEの標準仕様に準拠した機能や，アプリケーションサーバで独自に拡張された機能など，多様な機能を使用できます。目的や用途に応じた機能を選択して使用することで，信頼性の高いシステムや，処理性能に優れたシステムを構築・運用できます。

アプリケーションサーバの機能は，大きく分けて，次の二つに分類できます。

アプリケーションの実行基盤としての機能

アプリケーションの実行基盤を運用・保守するための機能

二つの分類は，機能の位置づけや用途によって，さらに詳細に分類できます。アプリケーションサーバのマニュアルは，機能の分類に合わせて提供しています。

アプリケーションサーバの機能の分類と対応するマニュアルについて，次の図に示します。

図1‒1　アプリケーションサーバの機能の分類と対応するマニュアル

注※1

マニュアル名称の「アプリケーションサーバ」を省略しています。

注※2

アプリケーションサーバでは，SOAP WebサービスとRESTful Webサービスを実行できます。目的によっては，マニュアル「アプリケーションサーバ Webサービス開発ガイド」以外の次のマニュアルも参照してください。

SOAPアプリケーションを開発・実行する場合

アプリケーションサーバ SOAPアプリケーション開発の手引

SOAP WebサービスやSOAPアプリケーションのセキュリティを確保する場合

XML Security - Core ユーザーズガイド

アプリケーションサーバ Webサービスセキュリティ構築ガイド

XMLの処理について詳細を知りたい場合

XML Processor ユーザーズガイド

ここでは，機能の分類について，マニュアルとの対応と併せて説明します。

1.1.1　アプリケーションの実行基盤としての機能

アプリケーションとして実装されたオンライン業務やバッチ業務を実行する基盤となる機能です。システムの用途や求められる要件に応じて，使用する機能を選択します。

アプリケーションの実行基盤としての機能を使用するかどうかは，システム構築やアプリケーション開発よりも前に検討する必要があります。

アプリケーションの実行基盤としての機能について，分類ごとに説明します。

(1)　アプリケーションを動作させるための基本的な機能（基本・開発機能）

アプリケーション（J2EEアプリケーション）を動作させるための基本的な機能が該当します。主にJ2EEサーバの機能が該当します。

アプリケーションサーバでは，Java EE 8に対応したJ2EEサーバを提供しています。J2EEサーバでは，標準仕様に準拠した機能のほか，アプリケーションサーバ独自の機能も提供しています。

基本・開発機能は，機能を使用するJ2EEアプリケーションの形態に応じて，さらに三つに分類できます。アプリケーションサーバの機能解説のマニュアルは，この分類に応じて分冊されています。

それぞれの分類の概要を説明します。

Webアプリケーションを実行するための機能（Webコンテナ）

Webアプリケーションの実行基盤であるWebコンテナの機能，およびWebコンテナとWebサーバが連携して実現する機能が該当します。

Enterprise Beanを実行するための機能（EJBコンテナ）

Enterprise Beanの実行基盤であるEJBコンテナの機能が該当します。また，Enterprise Beanを呼び出すEJBクライアントの機能も該当します。

WebアプリケーションとEnterprise Beanの両方で使用する機能（コンテナ共通機能）

Webコンテナ上で動作するWebアプリケーションおよびEJBコンテナ上で動作するEnterprise Beanの両方で使用できる機能が該当します。

(2)　Webサービスを開発するための機能

Webサービスの実行環境および開発環境としての機能が該当します。

アプリケーションサーバでは，次のエンジンを提供しています。

JAX-WS仕様に従ったSOAPメッセージのバインディングを実現するJAX-WSエンジン

JAX-RS仕様に従ったRESTful HTTPメッセージのバインディングを実現するJAX-RSエンジン

(3)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

アプリケーションサーバで独自に拡張された機能が該当します。バッチサーバ，CTM，データベースなど，J2EEサーバ以外のプロセスを使用して実現する機能も含まれます。

アプリケーションサーバでは，システムの信頼性を高め，安定稼働を実現するための多様な機能が拡張されています。また，J2EEアプリケーション以外のアプリケーション（バッチアプリケーション）をJavaの環境で動作させる機能も拡張しています。

(4)　システムのセキュリティを確保するための機能（セキュリティ管理機能）

アプリケーションサーバを中心としたシステムのセキュリティを確保するための機能が該当します。不正なユーザからのアクセスを防止するための認証機能や，通信路での情報漏えいを防止するための暗号化機能などがあります。

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

アプリケーションの実行基盤を効率良く運用したり，保守したりするための機能です。システムの運用開始後に，必要に応じて使用します。ただし，機能によっては，あらかじめ設定やアプリケーションの実装が必要なものがあります。

アプリケーションの実行基盤を運用・保守するための機能について，分類ごとに説明します。

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

システムの起動や停止，アプリケーションの開始や停止，入れ替えなどの，日常運用で使用する機能が該当します。

(2)　システムの利用状況を監視するための機能（監視機能）

システムの稼働状態や，リソースの枯渇状態などを監視するための機能が該当します。また，システムの操作履歴など，監査で使用する情報を出力する機能も該当します。

(3)　ほかの製品と連携して運用するための機能（連携機能）

JP1やクラスタソフトウェアなど，ほかの製品と連携して実現する機能が該当します。

(4)　トラブル発生時などに対処するための機能（保守機能）

トラブルシューティングのための機能が該当します。トラブルシューティング時に参照する情報を出力するための機能も含みます。

(5)　旧バージョンの製品から移行するための機能（移行機能）

旧バージョンのアプリケーションサーバから新しいバージョンのアプリケーションサーバに移行するための機能が該当します。

(6)　旧バージョンの製品との互換のための機能（互換機能）

旧バージョンのアプリケーションサーバとの互換用の機能が該当します。なお，互換機能については，対応する推奨機能に移行することをお勧めします。

1.1.3　機能とマニュアルの対応

アプリケーションサーバの機能解説のマニュアルは，機能の分類に合わせて分冊されています。

機能の分類と，それぞれの機能について説明しているマニュアルとの対応を次の表に示します。

表1‒1　機能の分類と機能解説のマニュアルの対応

分類

機能

マニュアル※1

基本・開発機能

Webコンテナ

基本・開発編(Webコンテナ)

JSFおよびJSTLの利用

JAX-RS 2.1の利用

WebSocket

NIO HTTPサーバ

サーブレットおよびJSPの実装

セッションマネージャの指定機能

EJBコンテナ

基本・開発編(EJBコンテナ)

EJBクライアント

Enterprise Bean実装時の注意事項

ネーミング管理

基本・開発編(コンテナ共通機能)

リソース接続とトランザクション管理

OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）

JPA 2.2の利用

CJMSプロバイダ

JavaMailの利用

アプリケーションサーバでのCDIの利用

アプリケーションサーバでのBean Validationの利用

Java Batch

JSON-P

JSON-B

Concurrency Utilities

アプリケーションの属性管理

アノテーションの使用

J2EEアプリケーションの形式とデプロイ

コンテナ拡張ライブラリ

ライブラリ競合回避機能

パッケージ名変換機能

拡張機能

バッチサーバによるアプリケーションの実行

拡張編

CTMによるリクエストのスケジューリングと負荷分散

バッチアプリケーションのスケジューリング

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）

データベースセッションフェイルオーバ機能

明示管理ヒープ機能を使用したFullGCの抑止

アプリケーションのユーザログ出力

セキュリティ管理機能

統合ユーザ管理による認証

セキュリティ管理機能編

アプリケーションの設定による認証

SSL/TLS通信でのTLSv1.2の使用

APIによる直接接続を使用する負荷分散機の運用管理機能からの制御

運用機能

システムの起動と停止

運用／監視／連携編※2

J2EEアプリケーションの運用

監視機能

稼働情報の監視（稼働情報収集機能）

リソースの枯渇監視

監査ログ出力機能

データベース監査証跡連携機能

運用管理コマンドによる稼働情報の出力

Managementイベントの通知とManagementアクションによる処理の自動実行

CTMの稼働統計情報の収集

コンソールログの出力

連携機能

JP1と連携したシステムの運用

システムの集中監視（JP1/IMとの連携）

ジョブによるシステムの自動運転（JP1/AJSとの連携）

クラスタソフトウェアとの連携

1:1系切り替えシステム（クラスタソフトウェアとの連携）

相互系切り替えシステム（クラスタソフトウェアとの連携）

N:1リカバリシステム（クラスタソフトウェアとの連携）

ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）

保守機能

トラブルシューティング関連機能

保守／移行編

性能解析トレースを使用した性能解析

製品のJavaVM（以降，JavaVMと略す場合があります）の機能

移行機能

旧バージョンのアプリケーションサーバからの移行

推奨機能への移行

互換機能

基本・開発機能の互換機能

互換編

拡張機能の互換機能

注※1　マニュアル名称の「アプリケーションサーバ 機能解説」を省略しています。

注※2　このマニュアルです。

1.2　システムの目的と機能の対応

アプリケーションサーバでは，構築・運用するシステムの目的に合わせて，適用する機能を選択する必要があります。

この節では，このマニュアルで説明している次の機能をどのような場合に使用するとよいかを説明します。なお，これらの機能は，アプリケーションサーバが独自に拡張した機能です。

システムの日常運用を支援する機能

システムの保守を支援する機能

J2EEアプリケーションの運用機能

システムの監査を支援する機能

JP1連携による運用管理機能

クラスタソフトウェアとの連携による系切り替え機能

機能ごとに，次の項目への対応を示しています。

信頼性

性能を重視したシステムの場合に使用するとよい機能です。

システムのパフォーマンスチューニングで使用する機能などが該当します。

運用・保守

効率の良い運用・保守をしたい場合に使用するとよい機能です。

1.2.1　システムの日常運用を支援する機能

システムの日常運用を支援する機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒2　システムの日常運用を支援する機能の目的

機能名

目的

参照先

信頼性

運用・

保守

システムの起動と停止

−

○

2章

稼働情報の監視（稼働情報収集機能）

−

○

3章

リソースの枯渇監視

−

○

4章

運用管理コマンドによる稼働情報の出力

−

○

8章

Managementイベントの通知とManagementアクションによる処理の自動実行

−

○

9章

CTMの稼働統計情報の収集※

−

○

10章

（凡例）　○：対応する。　　−：対応しない。

注※

J2EEアプリケーションの実行環境での日常運用を支援する機能です。バッチアプリケーションの実行環境では提供していません。

1.2.2　システムの保守を支援する機能

システムの保守を支援する機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒3　システムの保守を支援する機能の目的

機能名

目的

参照先

信頼性

運用・

保守

コンソールログの出力

−

○

11章

（凡例）　○：対応する。　　−：対応しない。

1.2.3　J2EEアプリケーションの運用機能

J2EEアプリケーションの運用機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒4　J2EEアプリケーションの運用機能の目的

機能名

目的

参照先

信頼性

運用・

保守

J2EEアプリケーションの実行時間の監視とキャンセル

−

○

5.3

J2EEアプリケーションのサービスの閉塞

−

○

5.4

J2EEアプリケーションの停止

−

○

5.5

J2EEアプリケーションの入れ替え

−

○

5.6

J2EEアプリケーションからのネットワークリソースへのアクセス

−

○

5.7

（凡例）　○：対応する。　　−：対応しない。

1.2.4　システムの監査を支援する機能

システムの監査を支援する機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒5　システムの監査を支援する機能の目的

機能名

目的

参照先

信頼性

運用・

保守

監査ログ出力機能

○

○

6章

データベース監査証跡連携機能

○

○

7章

（凡例）　○：対応する。

1.2.5　JP1連携による運用管理機能

JP1連携による運用管理機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒6　JP1連携による運用管理機能の目的

機能名

目的

参照先

信頼性

運用・

保守

JP1と連携したシステムの運用

−

○

12章

システムの集中監視（JP1/IMとの連携）

−

○

13章

ジョブによるシステムの自動運転（JP1/AJSとの連携）

−

○

14章

（凡例）　○：対応する。　　−：対応しない。

1.2.6　クラスタソフトウェアとの連携による系切り替え機能

クラスタソフトウェアとの連携による系切り替え機能の目的を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒7　クラスタソフトウェアとの連携による系切り替え機能の目的

機能名

目的

参照先

信頼性

運用・

保守

クラスタソフトウェアとの連携

○

○

15章

ホスト単位管理モデルを対象にした系切り替えシステム

○

○

16章

1:1系切り替えシステム

○

○

17章

相互系切り替えシステム

○

○

18章

N:1リカバリシステム

○

○

19章

（凡例）　○：対応する。

1.3　このマニュアルに記載している機能の説明

ここでは，このマニュアルで機能を説明するときの分類の意味と，分類を示す表の例について説明します。

1.3.1　分類の意味

このマニュアルでは，各機能の説明について，次の五つに分類して説明しています。マニュアルを参照する目的によって，必要な個所を選択して読むことができます。

解説

機能の解説です。機能の目的，特長，仕組みなどについて説明しています。機能の概要について知りたい場合にお読みください。

実装

コーディングの方法やDDの記載方法などについて説明しています。アプリケーションを開発する場合にお読みください。

設定

システム構築時に必要となるプロパティなどの設定方法について説明しています。システムを構築する場合にお読みください。

運用

運用方法の説明です。運用時の手順や使用するコマンドの実行例などについて説明しています。システムを運用する場合にお読みください。

注意事項

機能を使用するときの全般的な注意事項について説明しています。注意事項の説明は必ずお読みください。

1.3.2　分類を示す表の例

機能説明の分類については，表で説明しています。表のタイトルは，「この章の構成」または「この節の構成」となっています。

次に，機能説明の分類を示す表の例を示します。

機能説明の分類を示す表の例

表X-1　この章の構成（○○機能）

分類

タイトル

参照先

解説

○○機能とは

X.1

実装

アプリケーションの実装

X.2

DDおよびcosminexus.xml※での定義

X.3

設定

実行環境での設定

X.4

運用

○○機能を使用した運用

X.5

注意事項

○○機能使用時の注意事項

X.6

注※

cosminexus.xmlについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「16.　アプリケーションの属性管理」を参照してください。

ポイント

cosminexus.xmlを含まないアプリケーションのプロパティ設定

cosminexus.xmlを含まないアプリケーションでは，実行環境へのインポート後にプロパティを設定，または変更します。設定済みのプロパティも実行環境で変更できます。

実行環境でのアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。サーバ管理コマンドおよび属性ファイルでのアプリケーションの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.5.2　J2EEアプリケーションのプロパティの設定手順」を参照してください。

属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DDまたはcosminexus.xmlと属性ファイルのタグの対応については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「3.　J2EEアプリケーションの設定で使用する属性ファイル」を参照してください。

なお，各属性ファイルで設定するプロパティは，アプリケーション統合属性ファイルでも設定できます。

1.4　Component Container管理者によるシステムの運用（UNIXの場合）

UNIXの場合，J2EEサーバやバッチサーバのセットアップ，起動・停止などはスーパーユーザで実施しますが，スーパーユーザ以外の一般ユーザでも権限を与えることでこれらの操作ができるようになります。このユーザをComponent Container管理者といいます。Component Container管理者を設定することで，スーパーユーザ以外のユーザを運用管理者にできます。

Component Container管理者の設定は，アプリケーションサーバの構成ソフトウェアであるComponent Containerをインストールしたあとに実施します。なお，Component Container管理者の設定後，Component Container管理者ができる操作は，一部の操作を除き，スーパーユーザでは操作できなくなるので注意してください。

Component Container管理者を設定した場合に，スーパーユーザおよびComponent Container管理者が実施できる操作について，次の表に示します。

表1‒8　スーパーユーザおよびComponent Container管理者が実施できる操作

操作

スーパーユーザ

Component Container管理者

Component Containerのインストール

○

×

Component Container管理者のセットアップ（cjenvsetupコマンド）

○

×

作業ディレクトリおよびユーザ定義ファイルの移行（cjenvupdateコマンド）

×

○

J2EEサーバまたはバッチサーバのセットアップ／アンセットアップ（cjsetupコマンド）

×

○

リバースプロキシの設定

×

○

J2EEサーバまたはバッチサーバの起動／停止

（cjstartsvコマンド，cjstopsvコマンド）

×

○

サーバ管理コマンドの実行

○

○

スレッドダンプの取得（cjdumpsvコマンド）

○

○

OS状態情報の取得（cjgetsysinfoコマンド）

○

○

バッチ実行コマンド（cjexecjobコマンド）※

○

○

バッチ強制停止コマンド（cjkilljobコマンド）※

○

○

バッチ一覧表示コマンド（cjlistjobコマンド）※

○

○

（凡例）　○：できる。　　×：できない。

注※　バッチアプリケーションの場合に使用できるコマンドです。

参考

Component Container管理者を設定しない場合は，スーパーユーザが運用管理者となるため，表中のComponent Container管理者の操作はスーパーユーザが実施します。

1.5　アプリケーションサーバ 11-30での主な機能変更

この節では，アプリケーションサーバ 11-30での主な機能の変更について，変更目的ごとに説明します。

説明内容は次のとおりです。

アプリケーションサーバ 11-30で変更になった主な機能と，その概要を説明しています。機能の詳細については参照先の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「アプリケーションサーバ」は省略しています。

1.5.1　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表1‒9　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC4.3への対応

JDBC4.3に対応しました。

アプリケーションサーバ & BPM/ESB基盤 概説

4.6.2

接続できるデータベースにMySQL，PostgreSQLを追加

DB Connectorを使用して接続できるデータベースに，MySQL，PostgreSQLを追加しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6

パッケージ名変換機能の追加

jakartaパッケージ名を前提とするアプリケーションをアプリケーションサーバで動作させる機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

20章

第2編　運用・監視機能

2　システムの起動と停止

この章では，日常運用で行うシステムの起動・停止，および障害発生時の自動再起動について説明します。

2.1　この章の構成

この章では，日常運用で行うシステムの起動と停止や，障害発生時の自動再起動の仕組み，およびシステムの稼働監視について説明します。

この章の構成を次の表に示します。

表2‒1　この章の構成（システムの起動と停止）

分類

タイトル

参照先

解説

日常運用での起動と停止

2.2

論理サーバの起動・停止の仕組み

2.3

障害発生時の自動再起動

2.4

システムの稼働監視

2.5

設定

システムの起動と停止の設定

2.6

注　「実装」，「運用」，「注意事項」について，この機能固有の説明はありません。

2.2　日常運用での起動と停止

アプリケーションサーバで構築したシステムを運用するためには，アプリケーションサーバの構成ソフトウェアの複数のサーバプロセスを適切な順序で起動する必要があります。システムの構成によっては，同じ種類のサーバプロセスを複数起動することもあります。また，サービスを開始するためには，J2EEアプリケーションの開始も必要です。

アプリケーションサーバのシステムでは，J2EEサーバやWebサーバで構成される業務サービスを提供する，閉じた部分系をサービスユニットとして管理します。Smart Composer機能のコマンドを使用すると，論理サーバをサービスユニット単位で，またはすべてのサービスユニットを一括で起動・停止できます。また，Webシステム内のすべてのサービスユニットを一括で起動・停止することもできます。

Smart Composer機能では，運用管理にManagement Serverを使用するため，次の流れでシステムを起動します。停止の場合は，起動と逆の流れになります。論理サーバの起動と停止の仕組みについては，「2.3　論理サーバの起動・停止の仕組み」を参照してください。また，システムの起動・停止の設定については，「2.6　システムの起動と停止の設定」を参照してください。

運用管理エージェントの起動

Management Serverの起動

サービスユニット（論理サーバ）の起動（Smart Composer機能のコマンド）

リソースアダプタの開始（サーバ管理コマンド）

J2EEアプリケーションの開始（サーバ管理コマンド）

Smart Composer機能を使用したシステムの起動・停止方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の次の個所を参照してください。

4.1.24　システムを起動する（CUI利用時）

4.1.34　システムを停止する（CUI利用時）

2.3　論理サーバの起動・停止の仕組み

アプリケーションサーバでは，Management Serverを利用して論理サーバを起動・停止，および稼働確認を行います。

ここでは，Management Serverを利用した論理サーバの起動と稼働確認の仕組み，および停止の仕組みについて説明します。

2.3.1　論理サーバの起動と稼働確認

論理サーバの起動と稼働確認について次の図に示します。

図2‒1　論理サーバの起動と稼働確認

Management Serverは運用管理エージェントに論理サーバの起動要求を出します。

運用管理エージェントは，論理サーバの起動コマンドを実行して，要求された論理サーバを起動します。

運用管理エージェントで論理サーバプロセスのプロセスIDを取得します。

運用管理エージェントは，Management Serverに論理サーバの起動完了を通知します。

運用管理エージェントは，論理サーバのプロセス監視および動作確認を実施します。

論理サーバプロセスのプロセスIDを使用してプロセスがあるかどうかを確認し，プロセスの存在が確認できると，論理サーバの動作確認を実施します。

運用管理エージェントは，論理サーバのステータスをManagement Serverに通知します。

論理サーバの種類ごとのプロセス確認および動作確認の内容を，次の表に示します。なお，表中の動作確認の項目がない論理サーバについては，プロセスの存在確認だけが実施されます。

表2‒2　論理サーバの稼働確認方法

論理サーバの種類

プロセスの起動方法※

論理サーバの稼働確認方法

プロセス存在確認

動作確認

論理パフォーマンストレーサ

間接起動

パフォーマンストレーサの提供コマンドから取得したプロセスIDでプロセスの存在を確認する。

−

論理スマートエージェント

直接起動

起動コマンドのプロセスIDでプロセスの存在を確認する。

−

論理ネーミングサービス

直接起動

起動コマンドのプロセスIDでプロセスの存在を確認する。

ルートコンテキストを取得できることを確認する。

論理CTMドメインマネジャ

間接起動

CTMドメインマネジャの提供コマンドで取得したプロセスIDでプロセスの存在を確認する。

−

論理CTM

ネーミングサービス

直接起動

起動コマンドのプロセスIDでプロセスの存在を確認する。

ルートコンテキストを取得できることを確認する。

CTMデーモン

間接起動

CTMデーモンの提供コマンドで取得したプロセスIDでプロセスの存在を確認する。

−

論理J2EEサーバ

直接起動

起動コマンドのプロセスIDでプロセスの存在を確認する。

RMIによる呼び出しに応答することを確認する。

論理Webサーバ

間接起動

Webサーバが生成するhttpd.pidファイルから取得した制御プロセスのプロセスIDでプロセスの存在を確認する。

HTTP Server動作確認用URLに対してHTTPアクセスで正しいレスポンスが受信できるかどうかを確認する。応答はWebサーバのサーバプロセスが行う。

論理ユーザサーバ

直接起動

起動コマンドのプロセスIDでプロセスの存在を確認する。

論理ユーザサーバ定義ファイルにisAliveコマンドが定義されている場合は，isAliveコマンドを使用してプロセスが稼働しているかを確認する。定義されていない場合は，動作確認は成功したものと見なす。

間接起動

getProcessIDコマンドで取得したプロセスIDでプロセスの存在を確認する。

論理ユーザサーバ定義ファイルにisAliveコマンドが定義されている場合は，isAliveコマンドを使用する。定義されていない場合は，動作確認は成功したものと見なす。

（凡例）　−：なし

注※　直接起動では，実行したコマンドそのものが監視対象となります。間接起動では，コマンドが起動したサービスやプロセスが監視対象となります。コマンドを実行して監視対象のサービスやプロセスが起動されると，コマンドは終了します。

2.3.2　論理サーバの停止

論理サーバの停止について次の図に示します。

図2‒2　論理サーバの停止

Management Serverは運用管理エージェントに論理サーバの停止要求を出します。

運用管理エージェントは，論理サーバの停止コマンドを実行して，要求された論理サーバを停止します。

運用管理エージェントはManagement Serverに論理サーバの停止完了を通知します。

2.4　障害発生時の自動再起動

障害が発生した場合に，Management Server，運用管理エージェント，および論理サーバを自動再起動できます。ここでは，プロセスごとに自動再起動について説明します。

2.4.1　Management Serverの自動再起動

ここでは，障害が発生した場合のManagement Serverの自動再起動について説明します。

障害が発生した場合に，停止したManagement Serverを自動再起動できます。Management Serverのプロセスが障害によってダウンした場合などに自動再起動されるため，運用を継続できるようになります。また，自動再起動を設定すると，ホストの起動と同時にManagement Serverも自動起動するようになります。自動再起動の設定には，mngautorunコマンドを使用します。自動再起動の設定方法については，「2.6.4　自動再起動の設定」を参照してください。

注意事項

Management Serverが停止している場合で，稼働中の論理サーバのプロセスが異常終了またはハングアップを検知すると，そのあとManagement Serverが起動しても，自動停止処理や自動再起動処理は実行されません。

2.4.2　運用管理エージェントの自動再起動

ここでは，障害が発生した場合の運用管理エージェントの自動再起動について説明します。

障害が発生した場合に，停止した運用管理エージェントを自動再起動できます。運用管理エージェントのプロセスが障害によってダウンした場合などに自動再起動されるため，運用を継続できるようになります。また，自動再起動を設定すると，ホストの起動と同時に運用管理エージェントも自動起動するようになります。自動再起動の設定には，mngautorunコマンドを使用します。自動再起動の設定方法については，「2.6.4　自動再起動の設定」を参照してください。

2.4.3　論理サーバの自動再起動

ここでは，障害が発生した場合の論理サーバの自動再起動について説明します。

障害が発生した場合，Management Serverを使用して，停止した論理サーバを自動再起動できます。

自動再起動は，Management Serverによって正しく起動された論理サーバから，起動後の状態として「障害」が検出された場合に実行されます。「障害」とは，停止要求を受け付けていないのに論理サーバが停止したことが検出された状態です。

運用管理エージェントでは，論理サーバに対してプロセス監視および動作確認をしています。プロセスのダウン，およびハングアップなどの論理サーバの障害を検出すると，運用管理エージェントは異常を検知し，Management Serverに通知します。Management Serverは，障害検知時コマンドおよびsnapshotログ収集を実行してトラブルシューティング用の資料を収集したあとで，論理サーバを自動再起動します。

ユーザからの起動要求に対する起動処理の途中で障害が発生した場合は，自動再起動をしないでユーザに起動の失敗が通知されます。

自動再起動は，システムの構築時に設定した，自動再起動回数および自動再起動リトライ間隔に従って実行されます。なお，自動再起動回数として「0回」を設定している場合，自動再起動は実行されません。

自動再起動回数を超えたときに，<Managerのログ出力ディレクトリ>/mngsvr<ファイル面数>.logにメッセージが出力され，論理サーバのステータスは障害状態になります。

mserver.properties（Management Server環境設定ファイル）のcom.cosminexus.mngsvr.logical_server_abnormal_stop.exitキーにtrueを設定している場合，論理サーバのステータスが異常停止状態に遷移したタイミングでManagement Serverは停止します。異常停止状態とは自動再起動回数を超えたとき，または自動再起動回数の設定が0で障害を検知したとき，論理サーバが停止した状態です。

障害発生時の自動再起動の流れと論理サーバのステータスについて次の図に示します。

図2‒3　障害発生時の自動再起動

なお，前提となる論理サーバで自動再起動をした場合には，前提となる論理サーバの自動再起動の完了後に，該当する論理サーバを前提として設定している論理サーバも再起動されます。

ポイント

障害検出について

論理サーバの稼働状態の確認は，運用管理エージェントでの論理サーバのプロセス監視および動作確認で実施しています。例えば，プロセス監視では，論理サーバプロセスのプロセスIDが存在するかどうかを確認します。プロセスIDが存在しない場合は，運用管理エージェントはプロセスダウンを検知し，Management Serverに異常を通知します。

なお，プロセス監視および動作確認の内容は，論理サーバの種類によって異なります。詳細については，「2.3　論理サーバの起動・停止の仕組み」を参照してください。

注意事項

論理サーバの起動に成功した直後に論理サーバのプロセスが終了すると，障害検出と自動再起動が繰り返し実行されることがあります。この場合，adminagent.propertiesのadminagent.<サーバ種別>.watch.start_timeキー（論理サーバの起動コマンドを実行してから動作確認を開始するまでの時間）に，論理サーバのプロセスが起動されてから終了するまでの時間以上の値を設定することで回避できます。

論理J2EEサーバは，J2EEアプリケーションの起動時間を考慮してJ2EEサーバの起動監視時間を設定してください。論理サーバの自動再起動時にJ2EEアプリケーションの起動に時間が掛かり，自動再起動に失敗するおそれがあります。J2EEサーバ起動後にJ2EEアプリケーションを起動する運用であっても，論理サーバの自動再起動前にJ2EEアプリケーションが開始されていた場合，自動再起動時にJ2EEサーバの起動と同時にJ2EEアプリケーションが開始されます。ただし，論理J2EEサーバの環境設定で「コマンドオプションの追加」※に-nostartappを指定して運用している場合は，論理サーバの自動再起動時にJ2EEサーバの起動と同時にJ2EEアプリケーションが開始されません。

注※　SmartComposerの場合，additional.startcmdパラメタで指定します。

2.5　システムの稼働監視

この節では，システム運用時に必要な，論理サーバのステータスの監視やシステムの稼働情報の監視について説明します。

2.5.1　システムの運用状況の監視

システムの運用を開始したら，論理サーバのステータスやシステムの稼働情報を適宜確認して，安定した稼働状態を保っていくことが必要です。稼働情報に出力されたシステム性能を基に，チューニングが必要かどうかも判断する必要があります。

ここでは，システムの運用状況を監視する作業について説明します。システムの運用監視について次の表に示します。

表2‒3　システムの運用監視

作業内容

手段

作業概要

参照先マニュアル

参照個所

サービスユニットのステータス監視

Smart Composer機能のコマンド（cmx_list_statusコマンド）

Webシステム中のサービスユニットのステータスを確認して，システムが正常に稼働しているかどうかを監視できます。

このマニュアル

2.5.2(1)

論理サーバのステータス監視

運用管理コマンド（mngsvrutil）

システムを構成するホストおよびサーバのステータスを確認して，システムが正常に稼働しているかどうかを監視できます。この情報を基に，必要に応じて起動，停止，再起動ができます。

論理サーバのステータスは，次の単位で確認できます。

運用管理ドメイン単位

ホスト単位

論理サーバ単位

2.5.2(2)

システムの稼働監視

稼働情報収集機能※1※2

J2EEサーバまたはバッチサーバの稼働状態を監視して，稼働情報ファイルに出力できます。

システムの性能を監視することで，システム内の問題個所を発見したり，パフォーマンスチューニングに役立てたりすることができます。

3.2

運用管理コマンド（mngsvrutil）

J2EEサーバまたはバッチサーバの稼働状態を監視して，CSV形式またはSNMP連携用形式のファイルに出力できます。

システムの性能を監視することで，システム内の問題個所を発見したり，パフォーマンスチューニングに役立てたりすることができます。

8.2

リソース枯渇監視機能※1※3

リソースの使用率または使用数の推移を監視して，使用率または使用数がしきい値を超えた場合，メッセージを出力できます。リソースの使用率または使用数の推移は，リソース枯渇監視情報として定期的に出力できます。しきい値を超えた場合，出力されているリソース枯渇監視情報を基に原因を分析して適切に対処することで，トラブルの発生を未然に防げます。また，リソース枯渇監視情報は，トラブル発生後の要因の解析にも役立ちます。

4.2

運用管理コマンド（mngsvrutil）

運用管理ドメイン内のCTM※4の稼働統計情報を確認します。次の単位で確認できます。

運用管理ドメイン内のすべてのCTM

運用管理ドメイン内の指定したCTM，または指定したホスト内のCTM

10.2

トランザクション情報の確認

サーバ管理コマンド（cjlisttrn）

稼働中のJ2EEサーバでのトランザクションの状態や，停止中のJ2EEサーバでの未決着のトランザクションの有無などの情報を確認します。

機能解説 基本・開発編(コンテナ共通機能)

3.15.9

注※1　システム構築時に設定した一定の間隔ごとにファイルが出力されるため，サーバ管理コマンドや運用管理コマンドなどのツールを使用して出力する必要はありません。

注※2　稼働情報ファイルに出力されるFullGC回数，またはURLグループ単位の実行待ちリクエスト数がしきい値を超えたときに，メッセージが出力されます（しきい値イベント）。このメッセージを利用してManagementイベントを発行し，対処をManagementアクションとして自動化できます。しきい値イベントの設定については，「3.4.4　実行環境での設定（J2EEサーバの設定）」を参照してください。また，Managementイベントによる処理の自動実行の設定については，「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

注※3　リソースの使用状況がしきい値を超えた場合，Managementイベントを発行できます。Managementイベントを利用すると，対処をManagementアクションとして自動化できます。Managementイベントによる処理の自動実行の設定については，「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

注※4　CTMは，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2.1　製品と構成ソフトウェアの対応」を参照してください。

2.5.2　ステータスの監視

アプリケーションサーバでは，ステータス監視によって，システムが正常に稼働しているかどうかを監視できます。ステータス監視には次の2種類があります。

サービスユニットのステータス監視

サービスユニットのステータスを監視できます。

論理サーバのステータス監視

論理サーバのステータスを監視できます。

参考

サーバ管理コマンドを使用して，サーバ上で動作するアプリケーションのステータス監視，および稼働中のJ2EEサーバやバッチサーバのトランザクション情報の表示などができます。

(1)　サービスユニットのステータス監視

Smart Composer機能のコマンド（cmx_list_statusコマンド）を使用して，サービスユニットの稼働状態（ステータス）を監視できます。cmx_list_statusコマンドの使用方法については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cmx_list_status（サービスユニット状況の表示）」を参照してください。サービスユニットのステータス監視では，特定のユニット，またはWebシステム中のすべてのユニットの稼働状態をCSV形式にファイル出力できます。

(2)　論理サーバのステータス監視

論理サーバのステータス監視では，運用管理コマンド（mngsvrutil）を使用して論理サーバの稼働状態（ステータス）を監視できます。ステータス情報は標準出力に出力したり，CSV形式またはSNMP連携様式にファイル出力したりできます。

ここでは，論理サーバの稼働状態（ステータス）の監視方法と，監視できる項目について説明します。

参考

Management Serverおよび運用管理エージェントのステータスを確認するには，次の方法があります。

運用管理コマンド（mngsvrutil）のサブコマンド「check」

adminagentcheckコマンド

運用管理コマンド，およびadminagentcheckコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」およびマニュアル「アプリケーションサーバ リファレンス コマンド編」の「adminagentcheck（運用管理エージェントの稼働確認）」を参照してください。

(a)　ステータスの監視方法

論理サーバのステータスは，運用管理コマンド（mngsvrutil）で監視できます。

論理サーバのステータスを監視するには，運用管理コマンド（mngsvrutil）にサブコマンド「list」を指定して実行します。これによって，論理サーバのステータス情報を標準出力に出力したり，CSV形式またはSNMP連携用形式にファイル出力したりできます。

「list」の引数に指定する値によって，ステータスを出力する対象を指定できます。

運用管理コマンドおよびそのサブコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「7.3　mngsvrutilコマンドのサブコマンドの詳細」を参照してください。

次に，実行形式と実行例を示します。

運用管理ドメイン内の論理サーバ名とステータス情報を出力する場合

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> list status

実行例

mngsvrutil -m mnghost -u user01 -p pw1 list status

指定した論理サーバにインポートされているJ2EEアプリケーション名とステータス情報を出力する場合

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <論理サーバ名> list appStatus

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t J2EEserver1 list appStatus

(b)　ステータス監視で確認できる項目

ステータス監視では，論理サーバの起動／停止状態が確認できます。ステータスは，すべての論理サーバで確認できます。

ステータスは，次の単位で確認できます。

運用管理ドメイン単位

運用管理ドメインに含まれるすべての論理サーバのステータスをまとめて確認できます。

ホスト単位

選択したホスト内のすべての論理サーバのステータスをまとめて確認できます。

論理サーバ単位

選択した論理サーバのステータスを確認できます。種類ごとに確認することも，個々の論理サーバだけを確認することもできます。

確認できるステータスの種類と意味を次に示します。

表2‒4　稼働状況のステータスの種類と意味

稼働状況の

ステータス

説明

停止

初期状態および停止要求を受け付け停止処理が完了したあとの，論理サーバが停止した状態です。または，通信障害の回復後に運用管理エージェントが停止状態であることを確認できた状態です。

起動中

起動要求を受け付けてから論理サーバが稼働状態になるまでの起動処理中の状態です。

稼働中

起動要求を受け付け起動処理が完了したあとの，論理サーバが稼働している状態です。または，通信障害の回復後に運用管理エージェントが稼働状態であることを確認できた状態です。

停止中

停止要求を受け付けてから論理サーバが停止状態になるまでの停止処理中の状態です。

強制停止中

強制停止要求を受け付けてから論理サーバが停止状態になるまでの強制停止処理中の状態です。

異常停止

停止要求を受け付けていない状態で，論理サーバの停止を検出した状態です。

回復中

異常停止状態で起動要求を受け付けてから稼働状態になるまでの，論理サーバの起動処理中の状態です。

通信障害

運用管理エージェントとの通信で障害が発生し，ステータスの表示ができない状態です。

自動停止中

運用管理エージェントから論理サーバの異常通知（プロセスはあるが動作していない状態の通知）を受けて論理サーバの強制停止中の状態です。

自動再起動中

自動再起動指定ありの論理サーバで，稼働中状態に運用管理エージェントから論理サーバの停止通知を受けて自動再起動処理中の状態です。

計画停止中

計画停止要求を受け付けてから，論理Webサーバが停止状態になるまでの計画停止処理中の状態です。このステータスに遷移するのは，論理Webサーバの場合だけです。

2.6　システムの起動と停止の設定

この節では，構築したシステムを起動，停止する手順と，自動で起動，停止する場合の設定について説明します。

構築したシステムのプログラムやサーバは，次の図に示す手順で起動，停止します。

図2‒4　システムの起動と停止の手順

プログラムや，Webシステム内のサーバは，自動または手動で起動，停止できます。システムの運用方法に合わせて起動，停止の方法を検討し，必要な設定をしてください。

2.6.1　システムの起動

通常の運用では，運用管理エージェントとManagement Serverは自動起動する方法をお勧めします。運用管理エージェントとManagement Serverに自動起動を設定すると，運用管理エージェントの起動からManagement Serverの起動までの一連の操作を，ホスト起動と同時に処理できるようになります。自動起動の設定方法については，「2.6.3　自動起動の設定」を参照してください。

プログラムやサーバの起動手順を次に示します。

運用管理エージェントの起動

Management Serverの起動

システムの起動

プログラムやサーバの起動方法を次に示します。

(1)　運用管理エージェントの起動

手動起動する場合は，アプリケーションサーバのホストごとに，adminagentctlコマンドを使用して運用管理エージェントを起動します。

コマンドの処理と運用管理エージェントの起動処理の状態は，同期させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，コマンドの処理が終了した時点で運用管理エージェントは稼働状態となります。また，同期実行時には，コマンドを実行してから運用管理エージェントが稼働状態となるまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

起動方法を，OSごとに示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥bin¥adminagentctl start -sync -timeout <同期実行のタイムアウト時間>

参考

Windowsの場合はサービスからも起動できます。

UNIXの場合

# /opt/Cosminexus/manager/bin/adminagentctl start -sync -timeout <同期実行のタイムアウト時間>

参考

UNIXの場合，adminagentctlコマンドで-daemonオプションを指定，またはdaemonコマンドを使用すると，運用管理エージェントをデーモンプロセスとして起動できます。daemonコマンドを使用した場合，コマンドの処理と運用管理エージェントの起動処理の状態は同期できません。

(2)　Management Serverの起動

手動起動する場合は，Management Serverをセットアップしたホストで，mngsvrctlコマンドに，引数「start」を指定してManagement Serverを起動します。

注意事項

名前解決のできないホスト名または存在しないIPアドレスを指定してホストを定義した場合，Management Serverの起動に時間が掛かることがあります。

コマンドの処理とManagement Serverの起動処理の状態は，同期させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，コマンドの処理が終了した時点でManagement Serverは稼働状態となります。また，同期実行時には，コマンドを実行してからManagement Serverが稼働状態となるまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

起動方法を，OSごとに示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥bin¥mngsvrctl start -sync -timeout <同期実行のタイムアウト時間>

参考

Windowsの場合はサービスからも起動できます。

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl start -sync -timeout <同期実行のタイムアウト時間>

参考

UNIXの場合，mngsvrctlコマンドで-daemonオプションを指定，またはdaemonコマンドを使用すると，Management Serverをデーモンプロセスとして起動できます。daemonコマンドを使用した場合，コマンドの処理とManagement Serverの起動処理の状態は同期できません。

(3)　システムの起動

Smart Composer機能のコマンドで，Webシステムまたはサービスユニット単位に一括起動します。Webシステム単位で起動すると，Webシステム内にあるすべてのサービスユニット中の全論理サーバを起動します。

参考

論理サーバの起動順序は，デフォルトの設定を使用することをお勧めします。なお，論理サーバの起動順序は，簡易構築定義ファイルで各論理サーバの<configuration>タグ内にmstartup.noパラメタで設定できます。

2.6.2　システムの停止

プログラムやサーバの停止手順と停止方法を次に示します。なお，UNIXの場合は，運用管理エージェントとManagement Serverを自動停止できます。自動停止する場合は，ホストと同時に停止するようにします。自動停止の設定方法については，「2.6.5　自動停止の設定」を参照してください。

プログラムやサーバの停止手順を次に示します。

システムの停止

Management Serverの停止

運用管理エージェントの停止

プログラムやサーバの停止方法を次に示します。

(1)　システムの停止

Smart Composer機能のコマンドで，Webシステムまたはサービスユニット単位に一括停止します。

(2)　Management Serverの停止

手動停止する場合は，Management Serverをセットアップしたホストで，mngsvrctlコマンドに，引数「stop」を指定してManagement Serverを停止します。

コマンドの処理とManagement Serverの停止処理の状態は，同期させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，コマンドの処理が終了した時点でManagement Serverは停止状態となります。また，同期実行時には，コマンドを実行してからManagement Serverが停止状態となるまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

停止方法を，OSごとに示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥bin¥mngsvrctl stop -sync -timeout <同期実行のタイムアウト時間>

参考

Windowsの場合はサービスからも停止できます。

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl stop -sync -timeout <同期実行のタイムアウト時間>

(3)　運用管理エージェントの停止

手動停止する場合は，アプリケーションサーバのホストごとに，adminagentctlコマンドを使用して運用管理エージェントを停止します。

コマンドの処理と運用管理エージェントの停止処理の状態は，同期させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，コマンドの処理が終了した時点で運用管理エージェントは停止状態となります。また，同期実行時には，コマンドを実行してから運用管理エージェントが停止状態となるまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

停止方法を，OSごとに示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥bin¥adminagentctl stop -sync -timeout <同期実行のタイムアウト時間>

参考

Windowsの場合はサービスからも停止できます。

UNIXの場合

# /opt/Cosminexus/manager/bin/adminagentctl stop -sync -timeout <同期実行のタイムアウト時間>

2.6.3　自動起動の設定

ホストの起動と同時に，Management Serverおよび運用管理エージェントを自動起動できます。Management Serverおよび運用管理エージェントの自動起動の設定には，mngautorunコマンドを使用します。mngautorunコマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「mngautorun（自動起動および自動再起動の設定／設定解除）」を参照してください。

mngautorunコマンドで設定する，Management Serverおよび運用管理エージェントの自動起動処理は，同期実行させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，自動起動時に，Management Serverおよび運用管理エージェントの起動を同期実行します。また，自動起動時に，Management Serverおよび運用管理エージェントの起動を同期実行するまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

注意事項

09-00より前に自動起動を設定して運用している場合に，ここで説明する設定を有効にするときは，09-00より前の自動起動の設定を解除する必要があります。設定変更手順については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.3　旧バージョンから11-30までの仕様変更の確認」を参照してください。

UNIXの場合，09-00より前に自動起動を設定して運用しているときは，同期実行を有効にできません。09-00より前の自動起動の設定を解除し，mngautorunコマンドを使用して自動起動を設定する際に，同期実行を有効にしてください。

mngautorunコマンドの実行形式と実行例を次に示します。

実行形式

mngautorun [once] {server|agent|both} [-runlevel <ランレベル>]※ [-sync [-timeout <同期実行のタイムアウト時間>]]

注※　ランレベルは，UNIXの場合に指定できます。Windowsの場合は指定できません。

実行例

Management Serverをホスト起動時に自動起動する場合

mngautorun once server

運用管理エージェントをホスト起動時に自動起動する場合

mngautorun once agent

Management Serverおよび運用管理エージェントをホスト起動時に自動起動する場合

mngautorun once both

Management Serverおよび運用管理エージェントをホスト起動時に同期実行で自動起動する場合

mngautorun once both -sync

mngautorunコマンドの実行時に，Management Serverおよび運用管理エージェントに設定される自動起動の内容を次に示します。

(1)　Management Serverに設定される自動起動の内容

mngautorunコマンドの実行時に，Management Serverに設定される自動起動の内容をOSごとに説明します。

Windowsの場合

Management Serverのサービスで，ホスト起動時にサービスを起動するように次の内容が設定されます。

スタートアップの種類：自動

また，同一ホスト上でManagement Serverおよび運用管理エージェントの両方が起動する場合には，運用管理エージェントが先に起動するように依存関係が設定されます。

UNIXの場合

mngautorunコマンドのonceオプションを使用して（onceオプションおよびrespawnオプションの両方を省略した場合も含む）自動起動を設定※し，OSを起動や再起動することで，Management Serverを自動起動することができます。

注※　/etc/inittabファイルにManagement Serverの起動コマンドをonceオプションを指定して登録します。ただし，Linuxの場合は，/etc/systemd/system下のディレクトリにCoMS.service（Management Serverを自動起動，自動停止するサービス）を登録します。

(2)　運用管理エージェントに設定される自動起動の内容

mngautorunコマンドの実行時に，運用管理エージェントに設定される自動起動の内容をOSごとに説明します。

参考

自動起動処理では，運用管理エージェントを起動する前に，運用管理エージェント自動起動用設定ファイル（/opt/Cosminexus/manager/config/AdminAgentrc）を読み込みます。このファイルに次の設定を記述することで，運用管理エージェントから起動する論理サーバに設定を引き継ぐことができます。

リソースの制御設定（ulimit）

ファイル作成時のパーミッション（umask）

環境変数

運用管理エージェント自動起動用設定ファイルにはこれらの設定以外を記述しないでください。運用管理エージェント自動起動用設定ファイルにこれらの設定以外を記述した場合の動作は保証しません。

運用管理エージェント自動起動用設定ファイルはシェルスクリプトとして実行されます。このため，運用管理エージェント自動起動用設定ファイルの記載内容を変更する場合は十分な動作確認を実施してください。

Windowsの場合

運用管理エージェントのサービスで，ホスト起動時にサービスを起動するように次の内容が設定されます。

スタートアップの種類：自動

また，同一ホスト上でManagement Serverおよび運用管理エージェントの両方が起動する場合には，運用管理エージェントが先に起動するように依存関係が設定されます。

UNIXの場合

mngautorunコマンドのonceオプションを使用して（onceオプションおよびrespawnオプションの両方を省略した場合も含む）自動起動を設定※し，OSを起動や再起動することで，運用管理エージェントを自動起動することができます。

注※　/etc/inittabファイルに運用管理エージェントの起動コマンドをonceオプションを指定して登録します。ただし，Linuxの場合は，/etc/systemd/system下のディレクトリにCoAA.service（運用管理エージェントを自動起動，自動停止するサービス）を登録します。

2.6.4　自動再起動の設定

障害が発生した場合に，停止したManagement Serverおよび運用管理エージェントを自動再起動できます。自動再起動を設定すると，自動起動の設定も有効になります。Management Serverおよび運用管理エージェントの自動再起動の設定には，mngautorunコマンドを使用します。mngautorunコマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「mngautorun（自動起動および自動再起動の設定／設定解除）」を参照してください。

Windowsの場合，mngautorunコマンドで設定する，Management Serverおよび運用管理エージェントの自動再起動処理は，同期実行させることをお勧めします。この場合，コマンド実行時に同期実行オプション（-syncオプション）を指定します。このオプションを指定すると，自動再起動時に，Management Serverおよび運用管理エージェントの起動を同期実行します。また，自動再起動時に，Management Serverおよび運用管理エージェントの起動を同期実行するまでの待ち時間（同期実行のタイムアウト時間）を，-timeoutオプションで指定できます。

UNIXの場合，自動再起動処理に対して同期実行オプションを指定できません。

注意事項

09-00より前に自動起動を設定して運用している場合

ここで説明する設定を有効にするときは，09-00より前の自動起動の設定を解除する必要があります。設定変更手順については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.3　旧バージョンから11-30までの仕様変更の確認」を参照してください。

JavaVMの異常終了時に自動再起動するための設定

JavaVMの異常終了時にユーザダンプを取得したあと，アプリケーションサーバの自動再起動を正しく動作させるには，次のどちらかのレジストリキーにレジストリ値（DontShowUI ： 1）を設定して，ユーザダンプ取得時の応答要求を抑止することをお勧めします。

「¥¥HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Windows¥Windows Error Reporting」

「¥¥HKEY_CURRENT_USER¥SOFTWARE¥Microsoft¥Windows¥Windows Error Reporting」（上記のレジストリキーがない場合に使用します）

mngautorunコマンドの実行形式と実行例を次に示します。

実行形式

mngautorun respawn {server|agent|both} [-runlevel <ランレベル>]※1 [-sync※2 [-timeout <同期実行のタイムアウト時間>※2]]

注※1　ランレベルは，UNIXの場合に指定できます。Windowsの場合は指定できません。

注※2　同期実行オプションおよび同期実行のタイムアウト時間は，Windowsの場合に指定できます。UNIXの場合は指定できません。

実行例

Management Serverを自動再起動する場合

mngautorun respawn server

運用管理エージェントを自動再起動する場合

mngautorun respawn agent

Management Serverおよび運用管理エージェントを自動再起動する場合

mngautorun respawn both

Management Serverおよび運用管理エージェントの自動再起動を同期実行する場合※

mngautorun respawn both -sync

注※　Windowsの場合に指定できます。UNIXの場合は指定できません。

mngautorunコマンドの実行時に，Management Serverおよび運用管理エージェントに設定される自動再起動の内容を次に示します。

(1)　Management Serverに設定される自動再起動の内容

mngautorunコマンドの実行時に，Management Serverに設定される自動再起動の内容をOSごとに説明します。

Windowsの場合

Management Serverのサービスで，サービスの回復機能にエラー発生時にサービスを再起動するように次の内容が設定されます。

最初のエラー：サービスを再起動する

エラーカウントのリセット：0（エラーカウントをリセットしません）

サービスの再起動：0（異常終了後に即時に再起動を実行します）

なお，「エラーカウントのリセット」，「サービスの再起動」の値は，手動で設定を変更できます。

UNIXの場合

mngautorunコマンドのrespawnオプションを使用して自動再起動を設定※し，OSを起動や再起動することでManagement Serverを自動再起動することができます。

Management Serverのサービスを監視し，サービス終了時に再起動するように設定されます。

注※　/etc/inittabファイルにManagement Serverの起動コマンドをrespawnオプションを指定して登録します。ただし，Linuxの場合は，/etc/systemd/system下のディレクトリにCoMS.service（Management Serverを自動起動，自動停止，自動再起動するサービス）を登録します。

注意事項

UNIXの場合は，Management Serverのサービスで障害が発生しているかどうかに関係なく，mngsvrctlコマンドなどでManagement Serverのサービスを停止した場合も自動再起動されます。

(2)　運用管理エージェントに設定される自動再起動の内容

mngautorunコマンドの実行時に，運用管理エージェントに設定される自動再起動の内容をOSごとに説明します。

参考

自動再起動処理では，運用管理エージェントを起動する前に，運用管理エージェント自動起動用設定ファイル（/opt/Cosminexus/manager/config/AdminAgentrc）を読み込みます。このファイルに次の設定を記述することで，運用管理エージェントから起動する論理サーバに設定を引き継ぐことができます。

リソースの制御設定（ulimit）

ファイル作成時のパーミッション（umask）

環境変数

運用管理エージェント自動起動用設定ファイルにはこれらの設定以外を記述しないでください。運用管理エージェント自動起動用設定ファイルにこれらの設定以外を記述した場合の動作は保証しません。

運用管理エージェント自動起動用設定ファイルはシェルスクリプトとして実行されます。このため，運用管理エージェント自動起動用設定ファイルの記載内容を変更する場合は十分な動作確認を実施してください。

Windowsの場合

運用管理エージェントのサービスで，サービスの回復機能にエラー発生時にサービスを再起動するように次の内容が設定されます。

最初のエラー：サービスを再起動する

エラーカウントのリセット：0（エラーカウントをリセットしません）

サービスの再起動：0（異常終了後に即時に再起動を実行します）

なお，「エラーカウントのリセット」，「サービスの再起動」の値は，手動で設定を変更できます。

注意事項

親プロセスであるadminagentsvプロセスがダウンして自動再起動されたあと，サービスまたはコマンドから運用管理エージェントを停止しても，次のキーの設定は有効ならないため，論理サーバは停止されません。

＜Application Serverのインストールディレクトリ＞¥manager¥config¥adminagent.propertiesのadminagent.finalization.stop_serversキー

UNIXの場合

mngautorunコマンドのrespawnオプションを使用して自動再起動を設定※し，OSを起動や再起動することで運用管理エージェントを自動再起動することができます。

運用管理エージェントのサービスを監視し，サービス終了時に再起動するように設定されます。

注※　/etc/inittabファイルに運用管理エージェントの起動コマンドをrespawnオプションを指定して登録します。ただし，Linuxの場合は，/etc/systemd/system下のディレクトリにCoAA.service（運用管理エージェントを自動起動，自動停止，自動再起動するサービス）を登録します。

注意事項

UNIXの場合は，運用管理エージェントのサービスで障害が発生しているかどうかに関係なく，adminagentctlコマンドなどで運用管理エージェントのサービスを停止した場合も自動再起動されます。

2.6.5　自動停止の設定

UNIXの場合は，ホストの停止と同時にManagement Serverおよび運用管理エージェントを自動停止できます。

(1)　Management Serverの自動停止の設定

Management Serverの自動停止を設定する手順をOSごとに次に示します。

注意事項

Management Serverを自動再起動するように設定している場合は，この手順では停止できません。各論理サーバを停止してからホストを停止してください。ただし，Red Hat Enterprise Linux Server 7以降は，Management Serverを自動再起動するように設定している場合でも，この手順で停止できます。

(a)　AIXの停止手順

ホスト停止時にManagement Serverを自動停止させるためには，次に示す作業が必要です。

Management Serverを停止させるスクリプトファイルを作成します。

/etc/rc.shutdownスクリプトに，Management Serverを停止させるための処理を追加します。

ここでは，Management Serverを停止させるスクリプトファイルの作成方法と，/etc/rc.shutdownスクリプトへのManagement Serverの停止処理の追加方法について説明します。

Management Serverを停止させるスクリプトファイルの作成

Management Serverを停止させるスクリプトファイルを，/etc/下に任意のファイル名で作成します（例：/etc/MngSvrStop）。なお，スクリプトファイルの権限は「755」に設定してください。

スクリプトファイルの例を次に示します。

#!/bin/sh
BIN_PATH=/opt/Cosminexus/manager/bin
# Management Server停止
if [ -x $BIN_PATH/mngsvrctl ] ; then
  $BIN_PATH/mngsvrctl stop
fi
exit 0

この例では，最後の"exit 0"で停止処理に失敗した場合でもシャットダウン処理が中断されないようにしています。エラー発生時にシャットダウンを中断する場合は，それぞれのコマンド実行後にリターンコードをチェックして0以外のリターンコードを返すようにしてください。

なお，ホスト停止時に論理サーバを停止させるには，論理サーバを停止させるスクリプトを，Management Serverを停止させるスクリプトの前に追加してください。

スクリプトファイルの例を次に示します。

#!/bin/sh
BIN_PATH=/opt/Cosminexus/manager/bin
#論理サーバ停止
if [ -x $BIN_PATH/mngsvrutil ] ; then
  $BIN_PATH/mngsvrutil -m mnghost:28080 -u user1 -p user1 -t mnghost -k host -s stop server
fi
# Management Server停止
if [ -x $BIN_PATH/mngsvrctl ] ; then
  $BIN_PATH/mngsvrctl stop
fi
exit 0

mngsvrutilコマンドの各種オプションは，運用環境に合わせて指定してください。

/etc/rc.shutdownスクリプトへのManagement Serverの停止処理の追加

/etc/rc.shutdownスクリプトで実行する処理として，/etc/rc.shutdownスクリプトにManagement Serverを停止させるためのスクリプトファイルを追加します。同一ホスト上でManagement Serverと運用管理エージェントを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

/etc/rc.shutdownスクリプトへのManagement Serverの停止処理の追加例を次に示します。なお，この例は，Management Serverを停止させるためのスクリプトファイルを/etc/MngSvrStopに保存した場合の例です。

if [ -x /etc/MngSvrStop ]; then
  /etc/MngSvrStop
fi

(b)　Linuxの停止手順

ホスト停止時にManagement Serverを自動停止させるための設定手順について説明します。また，ホスト停止時に論理サーバを自動停止させるための設定手順についても説明します。

ホスト停止時にManagement Serverを自動停止させるための設定手順

Management Serverを自動起動設定（mngautorunコマンド）すれば，自動停止も行われます。

mngautorunコマンドで「-sync」指定した場合，Management Serverの自動停止のタイムアウト時間はデフォルトで120秒となります。Management Serverの自動停止のタイムアウト時間（-timeout）を設定する場合は次の手順で設定してください。

/etc/systemd/systemディレクトリに格納されているCoMS.serviceファイルを開き，ExecStop=オプションの指定にタイムアウト時間を追加します。

指定例を次に示します。

（例）

CoMS.serviceの変更前

ExecStop= /opt/Cosminexus/manager/bin/mngsvrctl stop -sync

CoMS.serviceの変更後

ExecStop= /opt/Cosminexus/manager/bin/mngsvrctl stop -sync -timeout 120

注　背景色付きの太字個所が編集個所になります。また，斜体個所は運用環境に合わせて設定してください。

1.で変更したCoMS.serviceファイルを適用するために，次のコマンドを実行します。

# systemctl reenable CoMS.service

注意事項

mngautorunコマンドを再度実行すると，この手順でCoMS.serviceに設定した内容はリセットされます。その場合は再度この手順を実施してください。

また，同一ホスト上で運用管理エージェントとManagement Serverを停止する場合は，両方を自動起動設定（mngautorunコマンドのboth指定）します。このとき同期起動（mngautorunコマンドの-sync指定）するように設定した場合は，ホスト停止時またはホスト再起動時にManagement Serverが運用管理エージェントより先に停止します。

ホスト停止時に論理サーバを自動停止させるための設定手順

ホスト停止時に論理サーバを自動停止させるための設定手順を次に示します。なお，この手順は，Management Serverを停止するホストだけで運用管理ドメインを構成していることを前提とした手順です。

/etc/systemd/systemディレクトリに格納されているCoMS.serviceファイルをテキストエディタで開き，ExecStop=オプションに設定されているコマンド構文をコピーして控えます。

任意の場所およびファイル名で論理サーバとManagement Serverを停止させるためのスクリプトファイルを作成します（例：/opt/Cosminexus/manager/bin/LS_MNG_stop）。スクリプトファイルの作成例を次に示します。

#!/bin/sh

ret=0

/opt/Cosminexus/manager/bin/mngsvrutil -m mnghost:28080 -u user1 -p user1 -t mnghost -
k host -s stop server
ERROR=$?
if [ $ERROR -ne 0 ] ; then
    ret=1
fi

/opt/Cosminexus/manager/bin/mngsvrctl stop -sync
ERROR=$?
if [ $ERROR -ne 0 ] ; then
    ret=1
fi

exit $ret

なお，mngsvrutilコマンドの各種オプションは，運用環境に合わせて指定してください。また，Management Serverの停止コマンド構文は，1.で控えたコマンド構文を指定してください。

作成した論理サーバおよびManagement Server停止スクリプトの権限を変更します。

# chmod 755 /opt/Cosminexus/manager/bin/LS_MNG_stop

/etc/systemd/systemディレクトリに格納されているCoMS.serviceファイルをテキストエディタで再度開き，ExecStop=オプションの指定を，2.で作成したスクリプトのパスに変更します。

CoMS.serviceファイルの変更例を次に示します。

変更前（mngautorun -sync指定ありの場合の内容）

ExecStop=/opt/Cosminexus/manager/bin/mngsvrctl stop -sync

変更後（2.で作成したスクリプト場合）

ExecStop=/opt/Cosminexus/manager/bin/LS_MNG_stop

運用管理エージェントとManagement Serverを非同期起動（mngautorun both指定あり，-sync指定なし）で設定している場合は，CoMS.serviceファイルのAfter=オプションに”CoAA.service”を追加します。

CoMS.serviceファイルの変更例を次に示します。

CoMS.serviceの変更前（mngautorun -sync指定なしの場合の内容）

After=network.target multi-user.target

変更後

After=CoAA.service network.target multi-user.target

変更したCoMS.serviceファイルを適用するために，次のコマンドを実行します。

# systemctl reenable CoMS.service

注意事項

mngautorunコマンドを再度実行すると，この手順でCoMS.serviceに設定した内容はリセットされます。その場合は再度この手順を実施してください。

ホスト停止時の論理サーバの自動停止を解除する手順

上記で設定したホスト停止時の論理サーバの停止を解除する場合は，次の手順を実施してください。

上記で作成した論理サーバとManagement Serverを停止するスクリプトファイル（例：/opt/Cosminexus/manager/bin/LS_MNG_stop）をテキストエディタで開き，Management Serverの停止コマンド構文をコピーして控えます。

/etc/systemd/systemディレクトリに格納されているCoMS.serviceファイルを開き，ExecStop=オプションの指定を，1.で控えたコマンド構文に変更します。

CoMS.serviceファイルの変更例を次に示します。

変更前

ExecStop=/opt/Cosminexus/manager/bin/LS_MNG_stop

変更後

ExecStop=/opt/Cosminexus/manager/bin/mngsvrctl stop -sync

運用管理エージェントとManagement Serverを非同期起動（mngautorun both指定あり，-sync指定なし）で設定している場合は， CoMS.serviceファイルのAfter=オプションの”CoAA.service”を削除します。

CoMS.serviceファイルの変更例を次に示します。

変更前

After=CoAA.service network.target multi-user.target

変更後

After=network.target multi-user.target

変更したCoMS.serviceファイルを適用するために，次のコマンドを実行します。

# systemctl reenable CoMS.service

論理サーバとManagement Serverを停止するスクリプトファイル（例：/opt/Cosminexus/manager/bin/LS_MNG_stop）を削除してください。

(2)　運用管理エージェントの自動停止の設定

運用管理エージェントの自動停止を設定する手順をOSごとに次に示します。

注意事項

運用管理エージェントを自動再起動するように設定している場合は，この手順では停止できません。各論理サーバを停止してからホストを停止してください。ただし，Red Hat Enterprise Linux Server 7以降は，運用管理エージェントを自動再起動するように設定している場合でも，この手順で停止できます。

(a)　AIXの停止手順

ホスト停止時に運用管理エージェントを自動停止させるためには，次に示す作業が必要です。

運用管理エージェントを停止させるスクリプトファイルを作成します。

/etc/rc.shutdownスクリプトに，運用管理エージェントを停止させるための処理を追加します。

ここでは，運用管理エージェントを停止させるスクリプトファイルの作成方法と，/etc/rc.shutdownスクリプトへの運用管理エージェントの停止処理の追加方法について説明します。

運用管理エージェントを停止させるスクリプトファイルの作成

運用管理エージェントを停止させるスクリプトファイルを，/etc/下に任意のファイル名で作成します（例：/etc/AdminAgentStop）。なお，スクリプトファイルの権限は「755」に設定してください。

スクリプトファイルの例を次に示します。

#!/bin/sh
BIN_PATH=/opt/Cosminexus/manager/bin
# 運用管理エージェント停止
if [ -x $BIN_PATH/adminagentctl ] ; then
  $BIN_PATH/adminagentctl stop
fi
exit 0

なお，この例では，最後の"exit 0"で停止処理に失敗した場合でもシャットダウン処理が中断されないようにしています。エラー発生時にシャットダウンを中断する場合は，それぞれのコマンド実行後にリターンコードをチェックして0以外のリターンコードを返すようにしてください。

/etc/rc.shutdownスクリプトへの運用管理エージェントの停止処理の追加

/etc/rc.shutdownスクリプトで実行する処理として，/etc/rc.shutdownスクリプトに運用管理エージェントを停止させるためのスクリプトファイルを追加します。

/etc/rc.shutdownスクリプトへの運用管理エージェントの停止処理の追加例を次に示します。なお，この例は，運用管理エージェントを停止させるためのスクリプトファイルを/etc/AdminAgentStopに保存した場合の例です。

if [ -x /etc/AdminAgentStop ]; then
  /etc/AdminAgentStop
fi

(b)　Linuxの停止手順

運用管理エージェントを自動起動設定（mngautorunコマンド）すれば，自動停止も行われます。

mngautorunコマンドで「-sync」指定した場合，運用管理エージェントの自動停止のタイムアウト時間はデフォルトで120秒となります。運用管理エージェントの自動停止のタイムアウト時間（-timeout）を設定する場合は次の手順で設定してください。

/etc/systemd/systemディレクトリに格納されているCoAA.serviceファイルを開き，ExecStop=オプションの指定にタイムアウト時間を追加します。

指定例を次に示します。

（例）

CoAA.serviceの変更前

ExecStop=/opt/Cosminexus/manager/bin/adminagentctl stop -sync

CoAA.serviceの変更後

ExecStop=/opt/Cosminexus/manager/bin/adminagentctl stop -sync -timeout 120

注　背景色付きの太字個所が編集個所になります。また，斜体個所は運用環境に合わせて設定してください。

1.で変更したCoAA.serviceファイルを適用するために，次のコマンドを実行します。

# systemctl reenable CoAA.service

注意事項

mngautorunコマンドを再度実行すると，この手順でCoAA.serviceに設定した内容はリセットされます。その場合は再度この手順を実施してください。

また，同一ホスト上で運用管理エージェントとManagement Serverを停止する場合は，両方を自動起動設定（mngautorunコマンドのboth指定）します。このとき同期起動（mngautorunコマンドの-sync指定）するように設定した場合は，ホスト停止時またはホスト再起動時に運用管理エージェントがManagement Serverより後に停止します。

3　稼働情報の監視（稼働情報収集機能）

この章では，サーバ性能やリソースの情報などの稼働情報を収集する機能について説明します。稼働情報収集機能を利用した稼働情報の監視では，稼働情報を稼働情報ファイルに出力できます。また，稼働情報収集機能およびイベントの発行機能を利用することで，監視対象の稼働状態の異常を検知できます。

3.1　この章の構成

稼働情報収集機能と参照先を次の表に示します。

表3‒1　稼働情報収集機能と参照先

機能

参照先

稼働情報収集機能の概要

3.2

稼働情報ファイルの出力機能

3.3

イベントの発行機能

3.4

3.2　稼働情報収集機能の概要

この節では，稼働情報ファイルを使用した，J2EEサーバ，およびバッチサーバの稼働情報の監視について説明します。

稼働情報収集機能では，J2EEサーバやバッチサーバの稼働状態を定期的に監視して，サーバ性能やリソースの情報などの稼働情報を稼働情報ファイルとして取得できます。稼働情報ファイルとは，J2EEサーバ，およびバッチサーバ内の稼働情報が，定期的に出力されるファイルです。稼働情報ファイルは，J2EEサーバの機能ごとに出力されます。稼働情報は，J2EEサーバ，およびバッチサーバの稼働状態を確認したり，稼働実績を統計情報として参照したり，J2EEサーバ，およびバッチサーバの設定パラメタをチューニングしたりするのに利用できます。

なお，稼働情報ファイルに出力されるFullGC回数，またはURLグループ単位の実行待ちリクエスト数を監視して，しきい値を超えた場合にメッセージを出力できます（しきい値イベント）。また，出力されたメッセージを利用してManagementイベントを発行し，このアラートに対応して必要な処理を自動実行するように設定できます。Managementイベントによる処理の自動実行の設定については，「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

稼働情報を監視することで，次の機能を使用できます。

稼働情報ファイルの出力

取得した稼働情報を稼働情報ファイルとして出力できます。稼働情報ファイルの出力については，「3.3　稼働情報ファイルの出力機能」を参照してください。

イベントの発行

監視対象にしきい値を設定し，監視対象がしきい値を超えた時にイベントを発行できます。イベントの発行については，「3.4　イベントの発行機能」を参照してください。

なお，稼働情報を監視する場合，通常の運用では，ここで説明している稼働情報ファイルを使用した稼働監視を行ってください。稼働情報ファイルで取得できる情報より詳細な情報を取得したい場合だけ，運用管理コマンドを使用した稼働情報の監視を行ってください。運用管理コマンドを使用した稼働情報の監視は，「8.2　運用管理コマンドによる稼働情報の出力の概要」を参照してください。

3.3　稼働情報ファイルの出力機能

この節では，取得した稼働情報を稼働情報ファイルとして出力する機能について説明します。

この節の構成を次の表に示します。

表3‒2　この節の構成（稼働情報ファイルの出力機能）

分類

タイトル

参照先

解説

稼働情報ファイルで収集できる情報の種類

3.3.1

稼働情報ファイルで収集できる情報

3.3.2

稼働情報ファイルの出力先とファイル面数

3.3.3

設定

実行環境での設定（J2EEサーバの設定）

3.3.4

運用

稼働情報ファイルの出力形式と出力内容

3.3.5

注　「実装」，「注意事項」について，この機能固有の説明はありません。

稼働情報ファイルの出力機能では，J2EEサーバやバッチサーバの各機能単位で出力される稼働情報を指定された稼働情報収集間隔ごとに収集し，テキストファイルに出力します。

稼働情報を出力する機能を次の図に示します。

図3‒1　稼働情報の種類と稼働情報を出力するJ2EEサーバの機能

稼働情報を出力する機能を次に示します。なお，各機能の番号は，図中の数字と対応しています。

JavaVM

プロセスリソース

Stateful Session Bean※

Stateless Session Bean※

Message-driven Bean※

DB Connector

JCAリソース

トランザクションサービス

Webアプリケーション※

Webコンテナ※

URLグループ※

注※　バッチサーバの場合は該当しません。

出力される稼働情報を次の表に示します。

表3‒3　出力される稼働情報

稼働情報

稼働情報を出力する機能単位

分類

種別

情報

サーバ性能

実行結果情報

受け付けリクエスト数※

Webアプリケーション

URLグループ

応答済みリクエスト数※

Webアプリケーション

URLグループ

セッション数※

Webアプリケーション

実行待ちリクエスト数の上限からあふれたリクエスト数※

Webコンテナ

Webアプリケーション

URLグループ

受け付けメッセージ数※

Message-driven Bean

決着済みトランザクション数

トランザクションサービス

トランザクションロールバック数

トランザクションサービス

コネクション取得失敗数

JCAリソース

プールされたPreparedStatement数

DBConnector

プールされたCallableStatement数

DBConnector

PrepareStatementメソッドが呼び出された回数

DBConnector

PrepareCallメソッドが呼び出された回数

DBConnector

プール内PreparedStatementヒット回数

DBConnector

プール内CallableStatementヒット回数

DBConnector

サーバリソース

流量制御リソース情報

同時実行スレッド数※

Webコンテナ

Webアプリケーション

URLグループ

実行待ちリクエスト数※

Webコンテナ

Webアプリケーション

URLグループ

全体実行待ちリクエスト数※

Webコンテナ

Webアプリケーション

プールされたインスタンス数※

Stateless Session Bean

プール内の使用中インスタンス数※

Stateless Session Bean

実行待ちリクエスト数※

Stateless Session Bean

接続セッション数※

Stateful Session Bean

プールされたインスタンス数※

Message-driven Bean

プール内の使用中インスタンス数※

Message-driven Bean

プールされたコネクション数

JCAリソース

プール内の使用中コネクション数

JCAリソース

コネクション取得待ちスレッド数

JCAリソース

OSリソース情報

JavaVMヒープサイズ

JavaVM

CopyGC回数

JavaVM

FullGC回数

JavaVM

ロードされているクラス数

JavaVM

JavaVMの稼働中のスレッド数

JavaVM

モニタロックのためにブロック状態であるスレッド数

JavaVM

Explicitヒープサイズ

JavaVM

Explicitヒープ領域のExplicitメモリブロックの個数

JavaVM

Explicitメモリブロックの最大サイズ

JavaVM

HTTPセッションで取得したExplicitメモリブロックの最大サイズ

JavaVM

HTTPセッションで取得したExplicitメモリブロックの個数

JavaVM

HTTPセッションで取得したExplicitヒープ領域を除いたコンテナが管理しているExplicitヒープサイズ

JavaVM

ユーザアプリケーションおよびJavaVMが管理しているExplicitヒープサイズ

JavaVM

スレッド数

プロセスリソース

ファイルディスクリプタ数

プロセスリソース

注※　バッチサーバの場合は該当しません。

3.3.1　稼働情報ファイルで収集できる情報の種類

稼働情報ファイルを使用すると，J2EEサーバ，およびバッチサーバの機能ごとの稼働情報を収集できます。稼働情報ファイルには，稼働情報として，サーバ性能，およびサーバリソースに関する情報が出力されます。稼働情報ファイルの対象となるJ2EEサーバ，およびバッチサーバの機能，およびそれぞれの機能で取得できる稼働情報の種類を次に示します。

表3‒4　機能ごとに取得できる稼働情報の種類

機能

機能の説明

稼働情報の種類

JavaVM

J2EEサーバが使用するJavaVM

JavaVMヒープサイズ

CopyGC回数

FullGC回数

ロードされているクラス数

稼働中のスレッド数

モニタロックのためにブロック状態であるスレッド数

Explicitヒープサイズ

Explicitヒープ領域のExplicitメモリブロックの個数

Explicitメモリブロックの最大サイズ

HTTPセッションで取得したExplicitメモリブロックの最大サイズ

HTTPセッションで取得したExplicitメモリブロックの個数

HTTPセッションで取得したExplicitヒープ領域を除いたコンテナが管理しているExplicitヒープサイズ

ユーザアプリケーションおよびJavaVMが管理しているExplicitヒープサイズ

プロセスリソース

J2EEサーバが使用するプロセスリソース

スレッド数

ファイルディスクリプタ数

Stateful Session Bean

J2EEサーバ上で動作するStateful Session Bean

接続セッション数

Stateless Session Bean

J2EEサーバ上で動作するStateless Session Bean

プールされたインスタンス数

プール内の使用中インスタンス数

実行待ちリクエスト数

Message-driven Bean

J2EEサーバ上で動作するMessage-driven Bean

プールされたインスタンス数

プール内の使用中インスタンス数

受け付けメッセージ数

DB Connector

J2EEサーバ上で動作するDB Connector

プールされたPreparedStatement数

プールされたCallableStatement数

PrepareStatementメソッドが呼び出された回数

PrepareCallメソッドが呼び出された回数

プール内PreparedStatementヒット回数

プール内CallableStatementヒット回数

JCAリソース

リソースアダプタが使用するJCAリソース

プールされたコネクション数

プール内の使用中コネクション数

コネクション取得待ちスレッド数

コネクション取得失敗数

トランザクションサービス

J2EEサーバで使用されるトランザクションサービス

決着済みトランザクション数

トランザクションロールバック数

Webアプリケーション

J2EEサーバ上で動作するWebアプリケーション

同時実行スレッド数

Webアプリケーション単位の実行待ちリクエスト数

Webアプリケーション単位の全体実行待ちリクエスト数

Webアプリケーション単位の実行待ちリクエスト数の上限からあふれたリクエスト数

受け付けリクエスト数

応答済みリクエスト数

セッション数

Webコンテナ

J2EEサーバ上で動作するWebコンテナ

同時実行スレッド数

Webコンテナ単位またはデフォルトの実行待ちリクエスト数

Webコンテナ単位の全体実行待ちリクエスト数

Webコンテナ単位の実行待ちリクエスト数の上限からあふれたリクエスト数

URLグループ

Webアプリケーションに定義されたURLグループ単位の同時実行数制御

同時実行スレッド数

URLグループ単位の実行待ちリクエスト数

URLグループ単位の実行待ちリクエスト数の上限からあふれたリクエスト数

受け付けリクエスト数

応答済みリクエスト数

ポイント

Webアプリケーション，WebコンテナおよびURLグループ単位のそれぞれの実行待ちリクエスト数の関係を次の表に示します。

対象

項目

説明

Webアプリケーション

Webアプリケーション単位の実行待ちリクエスト数

Webコンテナで実行するリクエストのうち，Webアプリケーション単位の同時実行スレッド数制御をしているWebアプリケーションに対する実行待ちリクエスト数です。

URLグループ単位の実行待ちリクエスト数は含まれません。

Webアプリケーション単位の全体実行待ちリクエスト数

Webコンテナで実行するリクエストのうち，Webアプリケーション単位の同時実行スレッド数制御をしているWebアプリケーションに対する実行待ちリクエスト数です。

URLグループ単位の実行待ちリクエスト数も含まれます。

Webコンテナ

Webコンテナ単位またはデフォルトの実行待ちリクエスト数

Webコンテナで実行するリクエストのうち，Webアプリケーション単位の同時実行スレッド数制御をしていないWebアプリケーションに対する実行待ちリクエスト数です。

Webコンテナ単位の全体実行待ちリクエスト数

Webコンテナ単位の実行待ちリクエスト数と，すべてのWebアプリケーション単位の全体実行待ちリクエスト数の和です。

URLグループ

URLグループ単位の実行待ちリクエスト数

Webコンテナで実行するリクエストのうち，Webアプリケーション単位の同時実行スレッド数制御をしているWebアプリケーション内でURLグループ単位の同時実行スレッド数制御している，特定のURLグループの実行待ちリクエスト数です。

3.3.2　稼働情報ファイルで収集できる情報

稼働情報ファイルを調査するためには，ヘッダファイルと組み合わせて参照する必要があります。ヘッダファイルは，稼働情報ファイルの対象となるJ2EEサーバの機能と1対1の関係で出力されて，稼働情報ファイルに出力される情報に対応する項目名が出力されます。そのため，ヘッダファイルと稼働情報ファイルを対応させながら，稼働情報を調査する必要があります。

ヘッダファイルと稼働情報ファイルの対応の例を次に示します。

図3‒2　ヘッダファイルと稼働情報ファイルの対応

稼働情報ファイルを調査する場合，まずファイル名に表示される日付などを参考にして，調査したい稼働情報ファイルを選択してください。次に，選択した稼働情報ファイルと，それに対応するヘッダファイルを一つのファイルに編集して，Excelなどのアプリケーションプログラムで参照してください。その場合，グラフや表などの形式に変換して参照することをお勧めします。また，時刻を表す項目をExcelなどのアプリケーションプログラムで参照する場合，セルの表示設定を，時刻を表示する形式に設定することをお勧めします。例えばExcelを使用している場合は，セルの表示形式を「時刻」に設定してください。

ヘッダファイルは，J2EEサーバの起動時に次のフォルダに作成されます。

Windowsの場合

<作業ディレクトリ>※¥ejb¥<J2EEサーバ名>¥stats

UNIXの場合

<作業ディレクトリ>※/ejb/<J2EEサーバ名>/stats

注※　<作業ディレクトリ>は，J2EEサーバのユーザ定義（usrconf.cfgファイル中のejb.public.directory）で指定されたディレクトリを指します。デフォルト値は，Windowsの場合，「<Application Serverのインストールディレクトリ>¥CC¥server¥public」，UNIXの場合，「/opt/Cosminexus/CC/server/public」です。

稼働情報ファイルとヘッダファイルは，すべての稼働情報ファイルに共通の項目と，個別の項目で構成されます。個別の項目は，対象となる機能ごとに異なります。稼働情報ファイルの出力形式と出力内容については，「3.3.5　稼働情報ファイルの出力形式と出力内容」を参照してください。

3.3.3　稼働情報ファイルの出力先とファイル面数

ここでは，稼働情報ファイルの出力先，ファイル面数，面の切り替え間隔，およびファイル名について説明します。

(1)　稼働情報ファイルの出力先

デフォルトの設定の場合，稼働情報ファイルは，J2EEサーバの起動時に次のフォルダに作成されます。

Windowsの場合

<作業ディレクトリ>※¥ejb¥<J2EEサーバ名>¥stats

UNIXの場合

<作業ディレクトリ>※/ejb/<J2EEサーバ名>/stats

注※　<作業ディレクトリ>は，J2EEサーバのユーザ定義（usrconf.cfgファイル中のejb.public.directory）で指定されたディレクトリを指します。デフォルト値は，Windowsの場合，「<Application Serverのインストールディレクトリ>¥CC¥server¥public」，UNIXの場合，「/opt/Cosminexus/CC/server/public」です。

また，稼働情報ファイルは，出力先を変更することもできます。

稼働情報ファイルの出力先の設定については，「3.3.4　実行環境での設定（J2EEサーバの設定）」を参照してください。

(2)　稼働情報ファイルのファイル面数と面の切り替え間隔

稼働情報ファイルは，出力先に保存するファイルの面数とファイルの面を切り替える時間間隔を設定できます。例えば，保存するファイル面数を「7」，ファイルの面を切り替える時間間隔を「24（時間）」と設定した場合，稼働情報ファイルは1日に1回面が切り替わり，最新の1週間分（7日分）のファイルを保存できることになります。

稼働情報ファイルの面数と面を切り替える時間間隔の設定については，「3.3.4　実行環境での設定（J2EEサーバの設定）」を参照してください。

(3)　稼働情報ファイルのファイル名

稼働情報ファイルのファイル名は，稼働情報を収集する機能ごとに異なります。機能ごとの稼働情報ファイルのファイル名を次の表に示します。

表3‒5　稼働情報ファイルのファイル名

機能

ファイル名

JavaVM

HJVMStats_<YYYYMMDDhhmm><TZ>.csv

プロセスリソース

HOSStats_<YYYYMMDDhhmm><TZ>.csv

Stateful Session Bean

HStatefulSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv

Stateless Session Bean

HStatelessSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv

Message-driven Bean

HMessageDrivenBeanStats_<YYYYMMDDhhmm><TZ>.csv

DB Connector

HDBConnectorStats_<YYYYMMDDhhmm><TZ>.csv

JCAリソース

HJCAConnectionPoolStats_<YYYYMMDDhhmm><TZ>.csv

トランザクションサービス

HJTAStats_<YYYYMMDDhhmm><TZ>.csv

Webアプリケーション

HWebModuleStats_<YYYYMMDDhhmm><TZ>.csv

Webコンテナ

HWebContainerStats_<YYYYMMDDhhmm><TZ>.csv

URLグループ

HWebURLGroupStats_<YYYYMMDDhhmm><TZ>.csv

注

<YYYYMMDDhhmm>には，ファイルが出力された時刻を表す次の値が表示されます。

YYYY：西暦年，MM：月，DD：日，hh：時，mm：分

<TZ>には，タイムゾーンが，GMT（グリニッジ標準時）からの時差で表示されます。日本の場合，「+0900」が表示されます。

3.3.4　実行環境での設定（J2EEサーバの設定）

稼働情報ファイルを収集する場合，J2EEサーバの設定が必要です。J2EEサーバの設定は，簡易構築定義ファイルで実施します。稼働情報ファイルの収集の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

稼働情報ファイルを出力する場合のデフォルトの出力先を次に示します。なお，作業ディレクトリは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.public.directoryパラメタで指定します。

Windowsの場合

<作業ディレクトリ>¥ejb¥<サーバ名称>¥stats

UNIXの場合

<作業ディレクトリ>/ejb/<サーバ名称>/stats

デフォルトの設定では，J2EEサーバまたはバッチサーバが出力した稼働情報が収集されて，稼働情報ファイルに出力されます。また，稼働情報の監視対象がしきい値を超えたときにイベントが発行されます。稼働情報ファイルの出力先や面数を変更したい場合や，稼働情報のしきい値や監視間隔を変更したい場合には，簡易構築定義ファイルで設定を変更してください。

簡易構築定義ファイルでの稼働情報ファイルの収集の定義について次の表に示します。なお，バッチサーバの場合は，簡易構築定義ファイルの，バッチサーバ用のユーザプロパティに設定します。

表3‒6　簡易構築定義ファイルでの稼働情報ファイルの収集に必要な定義

項目

指定するパラメタ

設定内容

稼働情報収集間隔

ejbserver.management.statistics.interval

稼働情報を取得する間隔（秒）を指定します。

稼働情報ファイルの出力

ejbserver.management.stats_file.enabled

稼働情報ファイルを出力するかどうかを指定します。デフォルトはtrueです。

ejbserver.management.stats_file.dir

稼働情報ファイルの出力先ディレクトリを指定します。

ejbserver.management.stats_file.num

稼働情報ファイルの面数を指定します。

ejbserver.management.stats_file.period

稼働情報ファイルの面を切り替える時間間隔（時間）を指定します。

ejbserver.management.stats_file.base_time

稼働情報ファイルの面を切り替える基点の時間を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

3.3.5　稼働情報ファイルの出力形式と出力内容

稼働情報ファイルとヘッダファイルは，すべての稼働情報ファイルに共通の項目と，個別の項目で構成されます。個別の項目は，対象となる機能ごとに異なります。ヘッダファイルの構成は，次のようになります。

すべての稼働情報ファイルに共通の項目の見方を次の表に示します。

表3‒7　すべての稼働情報ファイルに共通の項目の見方

項目（ヘッダファイルに出力される文字列）

説明

Date※

稼働情報ファイルを収集した時刻が，「YYYY/MM/DD hh:mm:ss.nnn」で表示されます。

YYYY：西暦年，MM：月，DD：日，hh：時，mm：分，ss：秒，nnn：ミリ秒

ObjectName

稼働情報ファイルごとに同じ形式の情報が表示されます。

StatsPath

稼働情報ファイルごとに固有の情報が出力されます。

＜稼働情報の種類を表す文字列＞.StartTime※

稼働情報の種類ごとに，稼働情報の収集対象が稼働中になった時刻が表示されます。時刻は，1970年1月1日午前0時から経過した時間がミリ秒単位で表示されます。

注※　ヘッダファイルにはこの情報に加えて，タイムゾーンがGMT（グリニッジ標準時）からの時差で表示されます。

例（日本の場合）：「Date(+0900)」，「HeapSize.StartTime(+0900)」

ただし，リロードによるJ2EEアプリケーションの入れ替えを実行した場合，リロードを実行した時刻が表示されます。

なお，「ObjectName」には，稼働情報ファイルごとに次の形式で情報が出力されます。

表3‒8　ObjectNameの形式

稼働情報ファイル（ファイル名）

ObjectNameの形式

JavaVM（HJVMStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEServer=<J2EEサーバ名>,j2eeType=JVM,name=jvm

プロセスリソース（HOSStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEServer=<J2EEサーバ名>,j2eeType=OSResource,name=os

Stateful Session Bean（HStatefulSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:EJBModule=<EJBアプリケーション表示名>,J2EEApplication=<J2EEアプリケーション表示名>,J2EEServer=<J2EEサーバ名>,j2eeType=StatefulSessionBean,mode=<アプリケーションの動作モード>※1,name=<Stateful Session Bean名>

Stateless Session Bean（HStatelessSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:EJBModule=<EJBアプリケーション表示名>,J2EEApplication=<J2EEアプリケーション表示名>,J2EEServer=<J2EEサーバ名>,j2eeType=StatelessSessionBean,mode=<アプリケーションの動作モード>※1,name=<Stateless Session Bean名>

Message-driven Bean（HMessageDrivenBeanStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:EJBModule=<EJBアプリケーション表示名>,J2EEApplication=<J2EEアプリケーション表示名>,J2EEServer=<J2EEサーバ名>,j2eeType=MessageDrivenBean,mode=<アプリケーションの動作モード>※1,name=<Message-driven Bean名>

DB Connector（HDBConnectorStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEApplication=<J2EEアプリケーション表示名>※2,J2EEServer=<J2EEサーバ名>,ResourceAdapterModule=<リソースアダプタ表示名>,j2eeType=ResourceAdapter,mode=<アプリケーションの動作モード>※1,name=<リソースアダプタ表示名>

JCAリソース（HJCAConnectionPoolStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEServer=<J2EEサーバ名>,ResourceAdapter=<リソースアダプタ表示名>,j2eeType=JCAResource,mode=<アプリケーションの動作モード>※1,app=<J2EEアプリケーションの表示名>※3,name=<リソースアダプタ表示名>

トランザクションサービス（HJTAStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEServer=<J2EEサーバ名>,j2eeType=JTAResource,name=JTAResource

Webアプリケーション（HWebModuleStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEApplication=<J2EEアプリケーション表示名>,J2EEServer=<J2EEサーバ名>,j2eeType=WebModule,mode=<アプリケーションの動作モード>※1,name=<Webアプリケーション表示名>

Webコンテナ（HWebContainerStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEServer=<J2EEサーバ名>,j2eeType=WebContainer,name=WebContainer

URLグループ（HWebURLGroupStats_<YYYYMMDDhhmm><TZ>.csv）

com.cosminexus.management.j2ee:J2EEApplication=<J2EEアプリケーション表示名>,J2EEServer=<J2EEサーバ名>,WebModule=<Webアプリケーション名>,j2eeType=WebURLGroup,mode=<アプリケーションの動作モード>※1,name=<URLグループ単位の同時実行スレッド数制御の定義名>

注※1　<アプリケーションの動作モード>には，次の値が出力されます。

test：アプリケーションの動作モードがテストモードの場合

normal：アプリケーションの動作モードが通常モードの場合

注※2　<J2EEアプリケーション表示名>は，リソースアダプタがJ2EEアプリケーションに含まれてデプロイされている場合にだけ出力されます。直接J2EEサーバにデプロイされたリソースアダプタの場合は，「null」が出力されます。

注※3　「app=<J2EEアプリケーションの表示名>」は，リソースアダプタがJ2EEアプリケーションに含まれてデプロイされている場合にだけ出力されます。

次に，それぞれの稼働情報ファイル個別の項目の見方について説明します。個別の項目は，ヘッダファイルに次の形式で表示されます。

＜稼働情報の種類を表す文字列＞.＜項目名＞

各項目は稼働情報の種類を表す文字列のあとに，「.」で区切られて出力されます。稼働情報の種類を表す文字列，および項目名について次の表に示します。

表3‒9　稼働情報の種類を表す文字列

稼働情報の種類

稼働情報の種類を表す文字列

JavaVMヒープサイズ

HeapSize

CopyGC回数

CopyGCCount

FullGC回数

FullGCCount

ロードされているクラス数

LoadedClassCount

モニタロックのためにブロック状態であるスレッド数

ThreadBlockedCount

Explicitヒープサイズ

EHeapSize

Explicitヒープ領域のExplicitメモリブロックの個数

EMemoryBlockCount

Explicitメモリブロックの最大サイズ

EMemoryBlockMaxSize

HTTPセッションで取得したExplicitメモリブロックの最大サイズ

HTTPSessionEMemoryBlockMaxSize

HTTPセッションで取得したExplicitメモリブロックの個数

HTTPSessionEMemoryBlockCount

HTTPセッションで取得したExplicitヒープ領域を除いたコンテナが管理しているExplicitヒープサイズ

ContainerEHeapSize

ユーザアプリケーションおよびJavaVMが管理しているExplicitヒープサイズ

ApplicationEHeapSize

スレッド数

ThreadCount

ファイルディスクリプタ数

FileDescriptorCount

接続セッション数

ActiveSessionCount

プールされたインスタンス数

PooledInstanceCount

プール内の使用中インスタンス数

ActivePooledInstanceCount

受け付けメッセージ数

MessageCount

実行待ちリクエスト数

WaitingRequestCount

プールされたPreparedStatement数

PooledPreparedStatementCount

プールされたCallableStatement数

PooledCallableStatementCount

PrepareStatementメソッドが呼び出された回数

InvokedPrepareStatementMethodCount

prepareCallメソッドが呼び出された回数

InvokedPrepareCallMethodCount

プール内PreparedStatementヒット回数

PooledPreparedStatementHitCount

プール内CallableStatementヒット回数

PooledCallableStatementHitCount

プールされたコネクション数

PoolSize

プール内の使用中コネクション数

ActivePoolSize

コネクション取得待ちスレッド数

WaitingThreadCount

コネクション取得失敗数

FailedRequestCount

決着済みトランザクション数

CompletionCount

トランザクションロールバック数

RolledbackCount

応答済みリクエスト数

ResponseCount

同時実行スレッド数

ActiveThreadCount

実行待ちリクエスト数の上限からあふれたリクエスト数

OverflowRequestCount

受け付けリクエスト数

RequestCount

セッション数

SessionCount

表3‒10　稼働統計情報ファイルの項目名

項目名（ヘッダファイルに出力される文字列）

説明

Count

オブジェクトの起動など稼働情報の取得を開始した時点からの累積回数，または累積個数

HighWaterMark

前回の稼働情報ファイルの出力時からの最大値

LowWaterMark

前回の稼働情報ファイルの出力時からの最小値

Current

現在値

UpperBound

上限値

LowerBound

下限値

次に，個別に出力される項目について，稼働情報ファイルごとに説明します。

(1)　JavaVMの稼働情報ファイルに出力される情報

JavaVMの稼働情報ファイルに出力される情報について説明します。JavaVMの稼働情報ファイルでは，J2EEサーバが使用するJavaVMの稼働情報を調査できます。

稼働情報ファイル名

HJVMStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HJVMStats.txt

出力される稼働情報

JavaVMの稼働情報ファイルに出力される内容を次に示します。

表3‒11　JavaVMの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

JavaVMヒープサイズ

HeapSize.UpperBound

HeapSize.LowerBound

HeapSize.HighWaterMark

HeapSize.LowWaterMark

HeapSize.Current

CopyGC回数※1※2

CopyGCCount.Count

FullGC回数※2※3

FullGCCount.Count

ロードされているクラス数

LoadedClassCount.HighWaterMark

LoadedClassCount.LowWaterMark

LoadedClassCount.Current

稼働中のスレッド数

ThreadCount.HighWaterMark

ThreadCount.LowWaterMark

ThreadCount.Current

モニタロックのためにブロック状態であるスレッド数

ThreadBlockedCount.HighWaterMark

ThreadBlockedCount.LowWaterMark

ThreadBlockedCount.Current

Explicitヒープサイズ

EHeapSize UpperBound

EHeapSize LowerBound

EHeapSize HighWaterMark

EHeapSize LowWaterMark

EHeapSize Current

Explicitヒープ領域のExplicitメモリブロックの個数

EMemoryBlockCount HighWaterMark

EMemoryBlockCount LowWaterMark

EMemoryBlockCount Current

Explicitメモリブロックの最大サイズ

EMemoryBlockMaxSize HighWaterMark

EMemoryBlockMaxSize LowWaterMark

EMemoryBlockMaxSize Current

HTTPセッションで取得したExplicitメモリブロックの最大サイズ※4

HTTPSessionEMemoryBlockMaxSize.HighWaterMark

HTTPSessionEMemoryBlockMaxSize.LowWaterMark

HTTPSessionEMemoryBlockMaxSize.Current

HTTPセッションで取得したExplicitメモリブロックの個数

HTTPSessionEMemoryBlockCount.HighWaterMark

HTTPSessionEMemoryBlockCount.LowWaterMark

HTTPSessionEMemoryBlockCount.Current

HTTPセッションで取得したExplicitヒープ領域を除いたコンテナが管理しているExplicitヒープサイズ

ContainerEHeapSize.HighWaterMark

ContainerEHeapSize.LowWaterMark

ContainerEHeapSize.Current

ユーザアプリケーションおよびJavaVMが管理しているExplicitヒープサイズ※4

ApplicationEHeapSize.HighWaterMark

ApplicationEHeapSize.LowWaterMark

ApplicationEHeapSize.Current

注※1

SerialGCが有効な場合，CopyGCの回数が出力されます。

G1GCが有効な場合，Young GCとMixed GCの合計回数が出力されます。

注※2

JavaVMの稼働情報であるCopyGC回数とFullGC回数には，J2EEサーバプロセスが次のどれかのタイミングで明示的に発行するGCの発生回数も含まれます。

J2EEアプリケーションのリロードで，Webアプリケーションを単体でリロードした場合

J2EEアプリケーションのリロードで，EJBアプリケーションをリロードした場合

J2EEアプリケーションを停止した場合

J2EEアプリケーションの開始で，スタブを生成した場合

J2EEアプリケーションの開始に失敗した場合

J2EEアプリケーションを削除した場合

FullGC回数のしきい値監視を有効にする場合，これらのタイミングでカウントされる回数を考慮する必要があります。

注※3

JavaVMの稼働情報であるFullGC回数には，バッチサーバプロセスが次のどちらかのタイミングで明示的に発行するGCの発生回数も含まれます。

GC制御機能で，メモリ使用量のしきい値を超えた場合

バッチアプリケーションを停止した場合

FullGCの発生回数を監視する場合，これらのタイミングでカウントされる回数を考慮する必要があります。

注※4

HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用している場合，出力内容が異なります。詳細は，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「7.11.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項」を参照してください。

(2)　プロセスリソースの稼働情報ファイルに出力される情報

プロセスリソースの稼働情報ファイルに出力される情報について説明します。プロセスリソースの稼働情報ファイルでは，J2EEサーバプロセスが使用するOSリソースの稼働情報を調査できます。

稼働情報ファイル名

HOSStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HOSStats.txt

出力される稼働情報

プロセスリソースの稼働情報ファイルに出力される内容を次に示します。

表3‒12　プロセスリソースの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

J2EEサーバプロセスが生成したスレッド数

ThreadCount.UpperBound※1

ThreadCount.LowerBound※2

ThreadCount.HighWaterMark※2

ThreadCount.LowWaterMark※2

ThreadCount.Current※2

J2EEサーバプロセスが使用するファイルディスクリプタ数

FileDescriptorCount.UpperBound※3

FileDescriptorCount.LowerBound※3

FileDescriptorCount.HighWaterMark※4

FileDescriptorCount.LowWaterMark※4

FileDescriptorCount.Current※4

注※1　Windows，またはLinuxの場合は無効になり，「-1」が出力されます。

注※2　Linuxの場合は無効になり，「-1」が出力されます。

注※3　Windowsの場合は無効になり，「-1」が出力されます。

注※4　Windows，またはAIXの場合は無効になり，「-1」が出力されます。

(3)　Stateful Session Beanの稼働情報ファイルに出力される情報

Stateful Session Beanの稼働情報ファイルに出力される情報について説明します。Stateful Session Beanの稼働情報ファイルでは，Stateful Session Beanの稼働情報を調査できます。

稼働情報ファイル名

HStatefulSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HStatefulSessionBeanStats.txt

出力される稼働情報

Stateful Session Beanの稼働情報ファイルに出力される内容を次に示します。

表3‒13　Stateful Session Beanの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

接続中のセッション数

ActiveSessionCount.UpperBound

Stateful Session Beanのアクティブ・セッションの最大数が無制限のとき，「0」が出力されます。

ActiveSessionCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

ActiveSessionCount.HighWaterMark

−

ActiveSessionCount.LowWaterMark

−

ActiveSessionCount.Current

−

（凡例）　−：該当なし

(4)　Stateless Session Beanの稼働情報ファイルに出力される情報

Stateless Session Beanの稼働情報ファイルに出力される情報について説明します。Stateless Session Beanの稼働情報ファイルでは，Stateless Session Beanの稼働情報を調査できます。

稼働情報ファイル名

HStatelessSessionBeanStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HStatelessSessionBeanStats.txt

出力される稼働情報

Stateless Session Beanの稼働情報ファイルに出力される内容を次に示します。

表3‒14　Stateless Session Beanの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

プールされたインスタンス数

PooledInstanceCount.UpperBound

Stateless Session Beanのプール内インスタンスの最大数が無制限のとき，「0」が出力されます。

PooledInstanceCount.LowerBound

−

PooledInstanceCount.HighWaterMark

−

PooledInstanceCount.LowWaterMark

−

PooledInstanceCount.Current

−

プール内の使用中インスタンス数

ActivePooledInstanceCount.UpperBound

Stateless Session Beanのプール内インスタンスの最大数が無制限のとき，「0」が出力されます。

ActivePooledInstanceCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

ActivePooledInstanceCount.HighWaterMark

−

ActivePooledInstanceCount.LowWaterMark

−

ActivePooledInstanceCount.Current

−

実行待ちリクエスト数

WaitingRequestCount.HighWaterMark

−

WaitingRequestCount.LowWaterMark

−

WaitingRequestCount.Current

−

（凡例）　−：該当なし

(5)　Message-driven Beanの稼働情報ファイルに出力される情報

Message-driven Beanの稼働情報ファイルに出力される情報について説明します。Message-driven Beanの稼働情報ファイルでは，Message-driven Beanの稼働情報を調査できます。

稼働情報ファイル名

HMessageDrivenBeanStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HMessageDrivenBeanStats.txt

出力される稼働情報

Message-driven Beanの稼働情報ファイルに出力される内容を次に示します。

表3‒15　Message-driven Beanの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

プールされたインスタンス数

PooledInstanceCount.UpperBound

Message-driven Beanのプール内インスタンスの最大数が無制限のとき，「0」が出力されます。

PooledInstanceCount.LowerBound

−

PooledInstanceCount.HighWaterMark

−

PooledInstanceCount.LowWaterMark

−

PooledInstanceCount.Current

−

プール内の使用中インスタンス数

ActivePooledInstanceCount.UpperBound

Message-driven Beanのプール内インスタンスの最大数が無制限のとき，「0」が出力されます。

ActivePooledInstanceCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

ActivePooledInstanceCount.HighWaterMark

−

ActivePooledInstanceCount.LowWaterMark

−

ActivePooledInstanceCount.Current

−

受け付けメッセージ数

MessageCount.Count

−

（凡例）　−：該当なし

(6)　DB Connectorの稼働情報ファイルに出力される情報

DB Connectorの稼働情報ファイルに出力される情報について説明します。DB Connectorの稼働情報ファイルでは，DB Connectorの稼働情報を調査できます。

ただし，コネクションプーリング機能を使用していない場合，prepareStatementメソッドが呼び出された回数（InvokedPrepareStatementMethodCount.Count），およびPrepareCallメソッドが呼び出された回数（InvokedPrepareCallMethodCount.Count）以外の値は無効になり，「-1」が出力されます。

稼働情報ファイル名

HDBConnectorStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HDBConnectorStats.txt

出力される稼働情報

DB Connectorの稼働情報ファイルに出力される内容を次に示します。

表3‒16　DB Connectorの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

ステートメントプーリング機能によってキャッシュされたPreparedStatement数

PooledPreparedStatementCount.UpperBound※1

次の値が出力されます。

「出力値＝DB Connectorに設定したコネクションごとのPreparedStatementサイズ×コネクションプールの上限値」

コネクションプールの上限値を無制限にしたときは，無効になり「-1」が出力されます。

PooledPreparedStatementCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

PooledPreparedStatementCount.HighWaterMark※1※2

−

PooledPreparedStatementCount.LowWaterMark※1※2

−

PooledPreparedStatementCount.Current※1※2

−

PooledPreparedStatementCount.Current※1※2※4

−

ステートメントプーリング機能によってキャッシュされたCallableStatement数

PooledCallableStatementCount.UpperBound※3

次の値が出力されます。

「出力値＝DB Connectorに設定したコネクションごとのPooledCallableStatementサイズ×コネクションプールの上限値」

コネクションプールの上限値を無制限にしたときは，無効になり「-1」が出力されます。

PooledCallableStatementCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

PooledCallableStatementCount.HighWaterMark※2※3

−

PooledCallableStatementCount.LowWaterMark※2※3

−

PooledCallableStatementCount.Current※2※3

−

PooledCallableStatementCount.Current※2※3※4

−

PrepareStatementメソッドが呼び出された回数

InvokedPrepareStatementMethodCount.Count※2

−

PrepareCallメソッドが呼び出された回数

InvokedPrepareCallMethodCount.Count※2

−

ステートメントプーリング機能によってキャッシュされたPreparedStatementがヒットした回数

PooledPreparedStatementHitCount.Count※1※2

−

ステートメントプーリング機能によってキャッシュされたCallableStatementがヒットした回数

PooledCallableStatementHitCount.Count※2※3

−

（凡例）　−：該当なし

注※1　DB Connectorの設定であるコネクションごとのPreparedStatementのプールサイズに「0」を設定した場合，PreparedStatementがプールされなくなるため，無効になり「-1」が出力されます。

注※2　接続先データベースにOracleを使用している場合，または接続先データベースにHiRDB以外を使用してコネクションの障害検知を行った場合，ステートメントオブジェクトを作成していなくても，1以上の値が出力されます。

注※3　DB Connectorの設定であるコネクションごとのCallableStatementのプールサイズに0を設定した場合，CallableStatementがプールされなくなるため，無効になり「-1」が出力されます。

注※4　コネクション数調整機能またはコネクション障害検知と併用した場合，コネクションプールから取り除かれた未使用コネクションはコネクションプール内のコネクション数としてカウントされないため，プールされているPreparedStatement数およびCallableStatement数は次の値を一時的に超える場合があります。

PreparedStatement数

コネクションプールの最大値×PreparedStatementPoolSize

CallableStatement数

コネクションプールの最大値×CallableStatementPoolSize

(7)　JCAリソースの稼働情報ファイルに出力される情報

JCAリソースの稼働情報ファイルに出力される情報について説明します。JCAリソースの稼働情報ファイルでは，JCAリソースの稼働情報を調査できます。ただし，コネクションプールが無効の場合，コネクション取得失敗数だけが出力されます。DB Connector for Reliable Messagingを使用している場合，稼働情報はReliable Messaging側に出力されます。DB Connector for Reliable Messaging側には出力されません。

Connector 1.5仕様に準拠したリソースアダプタを使用した場合は，一つ目のコネクション定義（ra.xml内でいちばん先頭の定義）に対応する稼働情報が出力されます。Outboundのコネクション定義がない場合は，HJCAConnectionPoolStatsの稼働情報は出力されません。

稼働情報ファイル名

HJCAConnectionPoolStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HJCAConnectionPoolStats.txt

出力される稼働情報

JCAリソースの稼働情報ファイルに出力される内容を次に示します。

表3‒17　JCAリソースの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

プールされたコネクション数

PoolSize.UpperBound

−

PoolSize.LowerBound

−

PoolSize.HighWaterMark

−

PoolSize.LowWaterMark

−

PoolSize.Current

−

プール内の使用中コネクション数

ActivePoolSize.UpperBound

−

ActivePoolSize.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

ActivePoolSize.HighWaterMark

コマンドの実行やコネクション数自動調節機能によって，値が一時的に変動する場合があります。

ActivePoolSize.LowWaterMark

ActivePoolSize.Current

コネクション取得待ちスレッド数

WaitingThreadCount.UpperBound

上限値を設定できないため，無効になり「-1」が出力されます。

WaitingThreadCount.LowerBound

下限値を設定できないため，無効になり「-1」が出力されます。

WaitingThreadCount.HighWaterMark

−

WaitingThreadCount.LowWaterMark

−

WaitingThreadCount.Current

−

コネクション取得失敗数

FailedRequestCount.Count

DB Connector for Reliable Messagingを使用している場合，Reliable Messaging側に出力されます。DB Connector for Reliable Messaging側には常に「0」が出力されます。

（凡例）　−：該当なし

(8)　トランザクションサービスの稼働情報ファイルに出力される情報

トランザクションサービスの稼働情報ファイルに出力される情報について説明します。トランザクションサービスの稼働情報ファイルでは，トランザクションサービスの稼働情報を調査できます。

稼働情報ファイル名

HJTAStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HJTAStats.txt

出力される稼働情報

トランザクションサービスの稼働情報ファイルに出力される内容を次に示します。

表3‒18　トランザクションサービスの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

決着したトランザクション数

CompletionCount.Count

ロールバックしたトランザクション数

RolledbackCount.Count

(9)　Webアプリケーションの稼働情報ファイルに出力される情報

Webアプリケーションの稼働情報ファイルに出力される情報について説明します。Webアプリケーションの稼働情報ファイルでは，対象のWebアプリケーション全体の稼働情報を調査できます。

稼働情報ファイル名

HWebModuleStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HWebModuleStats.txt

出力される稼働情報

Webアプリケーションの稼働情報ファイルに出力される内容を次に示します。

表3‒19　Webアプリケーションの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

備考

最大同時実行スレッド数

ActiveThreadCount.UpperBound※1※2

−

ActiveThreadCount.LowerBound※3

−

ActiveThreadCount.HighWaterMark※1

−

ActiveThreadCount.LowWaterMark※1

−

ActiveThreadCount.Current※1

−

Webアプリケーション単位の実行待ちリクエスト数

WaitingRequestCount.UpperBound※1※2※4

−

WaitingRequestCount.LowerBound※3※4

−

WaitingRequestCount.HighWaterMark※1※4

−

WaitingRequestCount.LowWaterMark※1※4

−

WaitingRequestCount.Current※1※4

−

Webアプリケーション単位の全体実行待ちリクエスト数

WholeWaitingRequestCount.UpperBound※1※4

−

WholeWaitingRequestCount.LowerBound※1※4

−

WholeWaitingRequestCount.HighWaterMark※1※4

−

WholeWaitingRequestCount.LowWaterMark※1※4

−

WholeWaitingRequestCount.Current※1※4

−

Webアプリケーション単位の実行待ちリクエスト数の上限からあふれたリクエスト数

OverflowRequestCount.Count※1

−

受け付けリクエスト数

RequestCount.Count※4

Webコンテナが受け付けたWebアプリケーション単位のリクエスト数が出力されます。Webアプリケーション単位の実行待ちリクエスト数もカウントされます。Webサーバでは受信されていても，Webコンテナに転送されていないリクエスト数はカウントされません。

応答済みリクエスト数

ResponseCount.Count

−

セッション数

SessionCount.UpperBound

セッション数の上限を設定していない場合，無効になり「-1」が出力されます。

SessionCount.LowerBound※3

−

SessionCount.HighWaterMark

−

SessionCount.LowWaterMark

−

SessionCount.Current

−

（凡例）　−：該当なし

注※1　Webアプリケーション単位の同時実行数制御機能を使用していない場合，または対象となるWebアプリケーションに，同時実行数制御機能を使用していない場合，無効になり，「-1」が出力されます。

注※2　対象となるWebアプリケーションに最大同時実行スレッド数制御が設定されている場合，Webアプリケーション単位の最大同時実行スレッド数が出力されます。最大同時実行スレッド数を動的に変更した場合，変更後の値が出力されます。

注※3　無効になり「-1」が出力されます。

注※4　リロード機能による入れ替え処理中の場合，Webアプリケーションが受け付けた実行待ちリクエスト数はカウントされません。リロード処理の完了後にカウントされます。

(10)　Webコンテナの稼働情報ファイルに出力される情報

Webコンテナの稼働情報ファイルに出力される情報について説明します。Webコンテナの稼働情報ファイルでは，開始しているWebアプリケーションの稼働情報を調査できます。

稼働情報ファイル名

HWebContainerStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HWebContainerStats.txt

出力される稼働情報

Webコンテナの稼働情報ファイルに出力される内容を次に示します。

表3‒20　Webコンテナの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

NIO HTTPサーバの実行中スレッド数（同期，非同期，WebSocketすべての総数）

WorkerThreadCount.UpperBound

WorkerThreadCount.LowerBound※1

WorkerThreadCount.HighWaterMark※2※6

WorkerThreadCount.LowWaterMark※2

WorkerThreadCount.Current※2

同時実行スレッド数（同期だけ）

ActiveThreadCount.UpperBound

ActiveThreadCount.LowerBound※1

ActiveThreadCount.HighWaterMark※2

ActiveThreadCount.LowWaterMark※2

ActiveThreadCount.Current※2

NIO HTTPサーバの実行待ちスレッド数（同期，非同期，WebSocketすべての総数）

WaitingWorkerThreadCount.UpperBound※3

WaitingWorkerThreadCount.LowerBound※1※3

WaitingWorkerThreadCount.HighWaterMark※4

WaitingWorkerThreadCount.LowWaterMark※4

WaitingWorkerThreadCount.Current※4

Webコンテナ単位またはデフォルトの実行待ちリクエスト数（同期だけ）

WaitingRequestCount.UpperBound※3

WaitingRequestCount.LowerBound※1※3

WaitingRequestCount.HighWaterMark※4

WaitingRequestCount.LowWaterMark※4

WaitingRequestCount.Current※4

Webコンテナ単位の全体実行待ちリクエスト数

WholeWaitingRequestCount.UpperBound※5

WholeWaitingRequestCount.LowerBound※5

WholeWaitingRequestCount.HighWaterMark※5

WholeWaitingRequestCount.LowWaterMark※5

WholeWaitingRequestCount.Current※5

Webコンテナ単位の実行待ちリクエスト数の上限からあふれたリクエスト数

OverflowRequestCount.Count※3

注※1　無効になり「-1」が出力されます。

注※2　Webアプリケーション単位の最大同時実行スレッド数制御を無効に設定している場合，J2EEアプリケーションのリロード中に実行待ちになった新しいリクエストは，稼働中のスレッドとしてカウントされます。

注※3　Webアプリケーション単位の最大同時実行スレッド数制御を設定していない場合，無効になり「-1」が出力されます。Webアプリケーション単位の最大同時実行スレッド数制御を設定している場合，デフォルトの実行待ちキューの情報が出力されます。

注※4　Webアプリケーション単位の最大同時実行スレッド数制御を設定していない場合，Webコンテナ単位の実行待ちキューの情報が出力されます。Webアプリケーション単位の最大同時実行スレッド数制御を設定している場合，デフォルトの実行待ちキューの情報が出力されます。

注※5　リロード機能による入れ替え処理中の場合，Webコンテナが受け付けた実行待ちリクエスト数はカウントされません。リロード処理の完了後にカウントされます。

注※6　高負荷時は一時的にWorkerThreadCount.UpperBoundの値を超える場合があります。このとき，WorkerThreadCount.HighWaterMarkの実際の値は，WorkerThreadCount.UpperBoundの値と一致します。

(11)　URLグループの稼働情報ファイルに出力される情報

URLグループの稼働情報ファイルに出力される情報について説明します。URLグループの稼働情報ファイルでは，URLグループの稼働情報を調査できます。

稼働情報ファイル名

HWebURLGroupStats_<YYYYMMDDhhmm><TZ>.csv

対応するヘッダファイル名

HWebURLGroupStats.txt

出力される稼働情報

URLグループの稼働情報ファイルに出力される内容を次に示します。

表3‒21　URLグループの稼働情報ファイルの出力内容

稼働情報の種類

項目（ヘッダファイルに出力される文字列）

同時実行スレッド数

ActiveThreadCount.UpperBound※1

ActiveThreadCount.LowerBound※2

ActiveThreadCount.HighWaterMark

ActiveThreadCount.LowWaterMark

ActiveThreadCount.Current

URLグループ単位の実行待ちリクエスト数

WaitingRequestCount.UpperBound※3

WaitingRequestCount.LowerBound※2※3

WaitingRequestCount.HighWaterMark※3

WaitingRequestCount.LowWaterMark※3

WaitingRequestCount.Current※3

URLグループ単位の実行待ちリクエスト数の上限からあふれたリクエスト数

OverflowRequestCount.Count

受け付けリクエスト数

RequestCount.Count※4

応答済みリクエスト数

ResponseCount.Count

注※1　Webアプリケーション単位の最大同時実行スレッド数を動的に変更した場合，設定値ではなく変更後の情報が出力されます。

注※2　無効になり「-1」が出力されます。

注※3　リロード機能による入れ替え処理中の場合，Webアプリケーションが受け付けたURLグループ単位の実行待ちリクエスト数はカウントされません。リロード処理の完了後にカウントされます。

注※4　Webコンテナが受け付けたURLグループ単位のリクエスト数が出力されます。URLグループ単位の実行待ちリクエスト数もカウントされます。Webサーバでは受信されていても，Webコンテナに転送されていないリクエスト数はカウントされません。

3.4　イベントの発行機能

この節では，監視対象にしきい値を設定し，監視対象がしきい値を超えた時にイベントを発行する機能について説明します。

この節の構成を次の表に示します。

表3‒22　この節の構成（イベントの発行機能）

分類

タイトル

参照先

解説

しきい値を設定できる監視対象

3.4.1

イベントの発行方法

3.4.2

実装

cosminexus.xmlでの定義

3.4.3

設定

実行環境での設定（J2EEサーバの設定）

3.4.4

注　「運用」，「注意事項」について，この機能固有の説明はありません。

イベントの発行機能は，稼働情報の監視対象が，設定したしきい値を超えた時に，イベントを発行する機能です。イベントが発行されることで，稼働状態の異常を検知できます。

なお，イベント発行時にはメッセージが出力されます。このメッセージを利用してManagementイベントを発行できます。Managementイベントの詳細については，「9.　Managementイベントの通知とManagementアクションによる処理の自動実行」を参照してください。

3.4.1　しきい値を設定できる監視対象

しきい値を設定できる稼働情報の監視対象を次に示します。

FullGC回数

FullGCの回数を監視します。FullGCが頻発する異常状態を検知できます。しきい値には，FullGCの回数を設定します。

J2EEアプリケーションの実行環境およびバッチアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53850-Wです。

Webコンテナ単位の全体実行待ちリクエスト数

Webコンテナ単位の全体実行待ちリクエスト数を監視します。Webコンテナ単位の全体実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，Webコンテナ単位の全体実行待ちリクエスト数の実行待ちリクエストキューサイズに対するWebコンテナ単位の全体実行待ちリクエスト数の割合を設定します。

J2EEアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53862-W（上限しきい値），KDJE53863-I（下限しきい値）です。

Webコンテナ単位の実行待ちリクエスト数

Webコンテナ単位の実行待ちリクエスト数を監視します。Webコンテナ単位の実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，Webコンテナ単位の実行待ちリクエスト数の実行待ちリクエストキューサイズに対するWebコンテナ単位の実行待ちリクエスト数の割合を設定します。

J2EEアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53864-W（上限しきい値），KDJE53865-I（下限しきい値）です。

Webアプリケーション単位の全体実行待ちリクエスト数

Webアプリケーション単位の全体実行待ちリクエスト数を監視します。Webアプリケーション単位の全体実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，Webアプリケーション単位の全体実行待ちリクエスト数の実行待ちリクエストキューサイズに対するWebアプリケーション単位の全体実行待ちリクエスト数の割合を設定します。

J2EEアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53866-W（上限しきい値），KDJE53867-I（下限しきい値）です。

Webアプリケーション単位の実行待ちリクエスト数

Webアプリケーション単位の実行待ちリクエスト数を監視します。Webアプリケーション単位の実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，Webアプリケーション単位の実行待ちリクエスト数の実行待ちリクエストキューサイズに対するWebアプリケーション単位の実行待ちリクエスト数の割合を設定します。

J2EEアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53868-W（上限しきい値），KDJE53869-I（下限しきい値）です。

URLグループ単位の実行待ちリクエスト数

URLグループ単位の実行待ちリクエストキューにあるリクエスト数を監視します。URLグループ単位の実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，URLグループ単位の実行待ちリクエストキューサイズに対するURLグループ単位の実行待ちリクエスト数の割合を設定します。

J2EEアプリケーションの実行環境で監視できます。

Managementイベントとして通知するメッセージIDは，KDJE53860-W（上限しきい値），KDJE53861-I（下限しきい値）です。

なお，Webコンテナのデフォルトの実行待ちキュー，およびWebアプリケーション単位の実行待ちキューにあるリクエスト数に対して，しきい値を設定して監視する場合は，リソース枯渇監視機能を使用してください。リソース枯渇監視機能については，「4.3　リソース枯渇監視機能とリソース枯渇監視情報の出力」を参照してください。

3.4.2　イベントの発行方法

イベントの発行方法は，しきい値を設定する監視対象によって，回数型と増減型の2種類があります。イベント発行方法と監視対象の対応を次の表に示します。

表3‒23　イベント発行方法と監視対象の対応

イベント発行方法

監視対象

回数型

FullGC回数

増減型

Webコンテナ単位の全体実行待ちリクエスト数

Webコンテナ単位の実行待ちリクエスト数

Webアプリケーション単位の全体実行待ちリクエスト数

Webアプリケーション単位の実行待ちリクエスト数

URLグループ単位の実行待ちリクエスト数

(1)　FullGC回数の場合（回数型）

設定した監視時間（しきい値監視間隔）単位で発生したFullGC回数をカウントし，しきい値に達した場合にイベントを発行します。

FullGC回数の場合の，しきい値のイベント発行について次の図に示します。

図3‒3　しきい値のイベント発行（FullGC回数の場合）

この図の場合，FullGC回数のしきい値が10，しきい値監視間隔が5分です。稼働情報の監視を開始した時点からしきい値監視間隔ごとにFullGCの回数をカウントし，一回のしきい値監視間隔でFullGCが10回を超えるとイベントを発行します。

(2)　URLグループ単位の実行待ちリクエスト数の場合（増減型）

上限しきい値および下限しきい値を設定し，URLグループ単位の実行待ちリクエスト数が，それぞれのしきい値に達した時にイベントを発行します。上限しきい値のイベント，および下限しきい値のイベントは次のタイミングで発行されます。なお，上限しきい値は下限しきい値より大きく設定する必要があります。

URLグループ単位の実行待ちリクエスト数が上限しきい値（警告域）に達した時に，上限しきい値のイベントが発行されます。

上限しきい値のイベントが発行されたあと，URLグループ単位の実行待ちリクエスト数が下限しきい値以下になった時に，正常域に戻ったことを示す下限しきい値のイベントが発行されます。

上限しきい値のイベントが発行されてから，URLグループ単位の実行待ちリクエスト数がいったん下限しきい値以下になってから再度上限しきい値に達した時に，上限しきい値のイベントが発行されます。上限しきい値のイベントが発行されたあと，下限しきい値に達しないで，再度上限しきい値に達した場合は，上限しきい値のイベントは発行されません。

下限しきい値のイベントが発行されてから，URLグループ単位の実行待ちリクエスト数がいったん上限しきい値以上になってから再度下限しきい値に達した時に，下限しきい値のイベントが発行されます。下限しきい値のイベントが発行されたあと，上限しきい値に達しないで，再度下限しきい値に達した場合は，下限しきい値のイベントは発行されません。

URLグループ単位の実行待ちリクエスト数の場合の，しきい値のイベント発行について次の図に示します。

図3‒4　しきい値のイベント発行（URLグループ単位の実行待ちリクエスト数の場合）

この図の場合，正常域から上限しきい値に達した時に，上限しきい値のイベントが発行されます。その後，上限しきい値以下になってから，再度上限しきい値に達しますが，この時には上限しきい値のイベントは発行されません。これ以降，下限しきい値に達した時に下限しきい値のイベントが，上限しきい値に達した時に上限しきい値のイベントが発行されます。

3.4.3　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

イベントの発行機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのイベントの発行機能の定義について次の表に示します。

表3‒24　cosminexus.xmlでのイベントの発行機能の定義

監視対象

指定するタグ

設定内容

Webアプリケーション単位の全体実行待ちリクエスト数

<thread-control>-<thread-control-stats-monitor>-<whole-waiting-request-count>-<enabled>

Webアプリケーション単位の全体実行待ちリクエスト数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

<thread-control>-<thread-control-stats-monitor>-<whole-waiting-request-count>-<high-threshold>

Webアプリケーション単位の全体実行待ちリクエスト数の上限しきい値を指定します。値は，Webアプリケーション単位の全体実行待ちリクエストが格納された割合（%）で指定します。

<thread-control>-<thread-control-stats-monitor>-<whole-waiting-request-count>-<low-threshold>

Webアプリケーション単位の全体実行待ちリクエスト数の下限しきい値を指定します。値は，Webアプリケーション単位の全体実行待ちリクエストが格納された割合（%）で指定します。

Webアプリケーション単位の実行待ちリクエスト数

<thread-control>-<thread-control-stats-monitor>-<waiting-request-count>-<enabled>

Webアプリケーション単位の実行待ちリクエスト数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

<thread-control>-<thread-control-stats-monitor>-<waiting-request-count>-<high-threshold>

Webアプリケーション単位の実行待ちリクエスト数の上限しきい値を指定します。値は，Webアプリケーション単位の実行待ちリクエストが格納された割合（%）で指定します。

<thread-control>-<thread-control-stats-monitor>-<waiting-request-count>-<low-threshold>

Webアプリケーション単位の実行待ちリクエスト数の下限しきい値を指定します。値は，Webアプリケーション単位の実行待ちリクエストが格納された割合（%）で指定します。

URLグループ単位の実行待ちリクエスト数

<thread-control>-<urlgroup-thread-control>-<stats-monitor>-<waiting-request-count>-<enabled>

URLグループ単位の実行待ちリクエスト数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

<thread-control>-<urlgroup-thread-control>-<stats-monitor>-<waiting-request-count>-<high-threshold>

URLグループ単位の実行待ちリクエスト数の上限しきい値を指定します。値は，URLグループ単位の実行待ちリクエストが格納された割合（%）で指定します。

<thread-control>-<urlgroup-thread-control>-<stats-monitor>-<waiting-request-count>-<low-threshold>

URLグループ単位の実行待ちリクエスト数の下限しきい値を指定します。値は，URLグループ単位の実行待ちリクエストが格納された割合（%）で指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

3.4.4　実行環境での設定（J2EEサーバの設定）

稼働情報ファイルを使用したイベントの発行には，J2EEサーバおよびJ2EEアプリケーションの設定が必要です。なお，J2EEアプリケーションの設定については，cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。イベント発行の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのイベント発行の定義について次の表に示します。

表3‒25　簡易構築定義ファイルでのイベントの発行の定義

指定するパラメタ

設定内容

ejbserver.management.JVM.stats_monitor.FullGCCount.enabled

FullGC回数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

ejbserver.management.JVM.stats_monitor.FullGCCount.threshold

FullGC回数の監視でのしきい値を指定します。

ejbserver.management.JVM.stats_monitor.FullGCCount.interval

FullGC回数の監視でのしきい値監視の間隔を指定します。

ejbserver.management.webcontainer.stats_monitor.whole_waiting_request_count.enabled

Webコンテナ単位の全体実行待ちリクエスト数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

ejbserver.management.webcontainer.stats_monitor.whole_waiting_request_count.high_threshold

Webコンテナ単位の全体実行待ちリクエスト数の上限しきい値を指定します。

ejbserver.management.webcontainer.stats_monitor.whole_waiting_request_count.low_threshold

Webコンテナ単位の全体実行待ちリクエスト数の下限しきい値を指定します。

ejbserver.management.webcontainer.stats_monitor.waiting_request_count.enabled

Webコンテナ単位の実行待ちリクエスト数の監視を有効にするかどうかを指定します。デフォルトはtrueです。

ejbserver.management.webcontainer.stats_monitor.waiting_request_count.high_threshold

Webコンテナ単位の実行待ちリクエスト数の上限しきい値を指定します。

ejbserver.management.webcontainer.stats_monitor.waiting_request_count.low_threshold

Webコンテナ単位の実行待ちリクエスト数の下限しきい値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。イベント発行の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「3.4.3　cosminexus.xmlでの定義」を参照してください。

4　リソースの枯渇監視

この章では，アプリケーションサーバのシステムで提供するリソース枯渇監視機能について説明します。この機能は，Managementイベントと組み合わせて利用することもできます。

4.1　この章の構成

リソース枯渇監視機能と参照先を次の表に示します。

表4‒1　リソース枯渇監視機能と参照先

機能

参照先

リソース枯渇監視機能の概要

4.2

リソース枯渇監視機能とリソース枯渇監視情報の出力

4.3

4.2　リソース枯渇監視機能の概要

この節では，J2EEサーバのリソースの使用率または使用数の推移を基に，リソース枯渇を監視する方法について説明します。

リソース枯渇監視機能で監視できるリソースは全部で7種類あります。すべてのリソースを監視することもできますが，監視するリソースを選択することもできます。リソース枯渇監視機能では，監視するリソースや，各リソースのしきい値などを設定します。なお，リソース枯渇監視で対象となるのは，J2EEサーバ，またはバッチサーバのリソースです。

J2EEサーバ，またはバッチサーバのリソース枯渇を監視する設定にしている場合，監視対象のリソースについての情報が，一定間隔でファイルに出力されます。この情報をリソース枯渇監視情報といいます。リソース枯渇監視情報は，監視するリソースの種類ごとに出力するかどうかを選択できます。なお，リソース枯渇監視情報を出力したファイルを，リソース枯渇監視ログファイルといいます。

リソース枯渇監視情報を利用すると，リソースの使用率または使用数の変化のしかたを確認できます。また，この情報は，リソースの使用率または使用数がしきい値を超えた場合に，その原因を調査するためにも使用できます。

リソースの使用率または使用数が設定したしきい値を超えた場合，アラートが発生します。Management Serverを使用している場合，アラートが発生すると，メッセージを出力し，Management Serverに対してイベントを通知できます。このイベントを，Managementイベントといいます。また，Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。このアクションを，Managementアクションといいます。リソース枯渇監視機能とManagementイベントを組み合わせて使用することによって，リソースを効率良く確実に監視できます。ManagementイベントとManagementアクションの詳細については，「9.3　Managementアクションの実行制御とは」を参照してください。

Managementイベントによる処理の自動実行の設定の詳細については，「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

リソース枯渇監視ログファイルの出力先については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.3.1　Component Containerのログの取得」を参照してください。

リソース枯渇監視の設定については，「4.3.3　実行環境での設定」を参照してください。

参考

リソース枯渇監視では，スレッドダンプの出力先のファイルを確認します。スレッドダンプ出力先（デフォルトは，<作業ディレクトリ>/ejb/<J2EEサーバ名>)に多数のファイルがある場合，チェック処理にシステムリソース(CPUなど)を多く消費します。

4.3　リソース枯渇監視機能とリソース枯渇監視情報の出力

この節では，リソース枯渇監視機能で監視できるリソースの種類と，ログファイルに出力される情報について説明します。

この節の構成を次の表に示します。

表4‒2　この節の構成（ソース枯渇監視ログファイルの出力機能）

分類

タイトル

参照先

解説

監視できるリソースの種類

4.3.1

実装

cosminexus.xmlでの定義

4.3.2

設定

実行環境での設定

4.3.3

運用

リソース枯渇監視情報ファイルの出力先と出力情報の種類

4.3.4

出力形式と出力内容

4.3.5

注　「注意事項」について，この機能固有の説明はありません。

4.3.1　監視できるリソースの種類

リソース枯渇監視機能では，7種類のリソースを監視できます。7種類すべてのリソースを監視することも，必要なリソースだけ監視することもできます。ただし，使用しているOSによっては，監視できないリソースがあります。また，バッチサーバの場合，HTTPリクエスト実行待ちキュー監視およびセッション数監視はできません。

各リソースの詳細について次に説明します。

メモリ監視

メモリ監視では，JavaVMでのヒープ・メモリ領域を監視します。メモリの使用状況を監視することで，FullGCの予兆を検知できるので，監視結果をヒープサイズおよびメモリサイズのチューニングに利用できます。

設定したしきい値を超えた場合は，KDJE34500-Wが出力されます。

ポイント

この機能で監視しているメモリ使用率が100%に近づいた場合に必ずFullGCが発生するわけではありません。監視した値は，FullGCが発生する可能性が高いという予兆を検知するために使用されます。

ファイルディスクリプタ監視

ファイルディスクリプタ監視では，サーバのプロセス内で開いているファイルディスクリプタを監視します。ファイルディスクリプタの数を監視することで，システムに割り当てられている，サーバのプロセスで使用できるファイルディスクリプタの枯渇を検知したり，見積もりで求めたファイルディスクリプタの数に到達する前に検知したりできます。

設定したしきい値に達した場合は，KDJE34520-Wが出力されます。

なお，ファイルディスクリプタ監視は，Windowsの場合，およびAIXの場合は使用できません。

スレッド監視

スレッド監視では，サーバのプロセス内で生成するスレッド数を監視します。生成されたスレッド数を監視することで，システムに割り当てられている，サーバのプロセス内で生成できるスレッド数を超えたり，見積もりで求めたスレッド数に到達する前に検知したりできます。

設定したしきい値に達した場合は，KDJE34540-Wが出力されます。

なお，スレッド監視は，Linuxの場合は使用できません。

スレッドダンプ監視

スレッドダンプ監視では，cjdumpsvコマンドやJ2EEアプリケーション実行時間の監視で出力されたスレッドダンプのファイル数を，サーバ単位で監視します。スレッドダンプのファイル数を監視することで，ファイル数が上限に達する前に検知できます。

なお，環境変数JAVACOREDIRを指定している場合，環境変数JAVACOREDIRで指定したディレクトリとデフォルトの出力先ディレクトリ（Windowsの場合：<作業ディレクトリ>¥ejb¥<サーバ名称>，UNIXの場合：<作業ディレクトリ>/ejb/<サーバ名称>）の両方のスレッドダンプのファイルの個数の合計を監視します。環境変数JAVACOREDIRで指定したパスがディレクトリでないなど，ファイルのリストが取得できない場合は，デフォルトの出力先のファイル数だけを監視します。

設定したしきい値に達した場合は，KDJE34580-Wが出力されます。最大値に達した場合は，KDJE34581-Eが出力されます。

J2EEアプリケーション実行時間の監視については，「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。

注意事項

スレッドダンプ監視の処理は，環境変数JAVACOREDIRで指定されたディレクトリおよびデフォルトの出力先ディレクトリの，ファイルとディレクトリの数に比例して負荷が掛かります。そのため，それらのディレクトリに不要なファイルを配置しないか，スレッドダンプの監視間隔を長めに設定してください。

HTTPリクエスト実行待ちキュー監視

HTTPリクエスト実行待ちキュー監視では，Webアプリケーション単位の同時実行スレッド数の制御で実行待ちキューにあるリクエストの数を監視します。監視する実行待ちキューは，Webアプリケーションごとの実行待ちキューと，デフォルトの実行待ちキューです。監視は，J2EEサーバ単位，またはWebアプリケーション単位でできます。HTTPリクエストのWebアプリケーション単位およびデフォルトの実行待ちキューを監視することで，リクエストがそれらの実行待ちキューからあふれる前の状態を検知できます。

ただし，Webアプリケーション単位およびデフォルトの実行待ちキューサイズに「0」が指定されている場合は監視しません。

なお，Webアプリケーション単位の実行待ちキューサイズが動的に変更された場合でも，しきい値は最初に設定した値から変更されることはありません。

設定したしきい値に達した場合は，KDJE34621-Wが出力されます。

同時実行スレッド数については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.15　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

なお，URLグループ単位の実行待ちキューにあるリクエストの数を監視する場合は，稼働情報収集機能を使用してください。稼働情報収集機能を使用したしきい値の設定方法については，「3.4.1　しきい値を設定できる監視対象」を参照してください。

セッション数監視

セッション数監視では，Webアプリケーション上で生成されるセッション数を監視します。セッション数を監視することで，セッション数の増加を検知できます。

ただし，セッション数の設定で作成できるセッション数に「0」が指定されている場合は，監視しません。

設定したしきい値に達した場合は，KDJE34640-Wが出力されます。

コネクションプール監視

コネクションプール監視では，コネクションプールの使用状態を監視します。コネクションプールの使用状態を監視することで，コネクションの枯渇を事前に検知できるので，コネクションプールのチューニングに利用できます。

ただし，コネクションプールが無効となっている場合は，監視できません。また，コネクションプールの最大値が無制限の場合は，監視はしますが，Managementイベントは通知されません。

設定したしきい値を超えた場合は，KDJE34660-Wが出力されます。最大数に達した場合は，KDJE34661-Wが出力されます。

コネクションプールについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.1　コネクションプーリング」を参照してください。

4.3.2　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

リソース枯渇監視機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのリソース枯渇監視機能の定義について次の表に示します。

表4‒3　cosminexus.xmlでのリソース枯渇監視機能の定義

リソース種別

指定するタグ

設定内容

HTTPリクエスト実行待ちキュー

<war>−<thread-control>−<resource-watcher>タグ下次のタグ

<watcher-enabled>タグ

<watcher-threshold>タグ

<watcher-interval>タグ

<watcher-writefile-enabled>タグ

J2EEアプリケーション単位で，Webアプリケーションごとの実行待ちキューの場合のHTTPリクエスト実行待ちキュー監視の次の設定をします。

HTTPリクエスト実行待ちキュー監視によるアラート出力の有無

監視のしきい値

監視の間隔

リソース枯渇監視ログファイルの出力の有無

セッション数

<http-session>−<resource-watcher>タグ下の次のタグ

<watcher-enabled>タグ

<watcher-threshold>タグ

<watcher-interval>タグ

<watcher-writefile-enabled>タグ

J2EEアプリケーション単位でセッション数監視の次の設定をします。

セッション数監視によるアラート出力の有無

監視のしきい値

監視の間隔

リソース枯渇監視ログファイルの出力の有無

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

4.3.3　実行環境での設定

リソース枯渇監視機能を使用できるのは，J2EEサーバ，またはバッチサーバです。J2EEサーバの場合，監視対象にできるリソースは，メモリ，ファイルディスクリプタ，スレッド数，スレッドダンプ，HTTPリクエスト実行待ちキュー，セッション数，およびコネクションプールです。バッチサーバの場合，監視対象にできるリソースは，メモリ，ファイルディスクリプタ，スレッド数，スレッドダンプ，およびコネクションプールです。なお，Windows，AIXでは，ファイルディスクリプタは監視できません。また，Linuxではスレッド数を監視できません。

リソース枯渇監視機能を使用する場合，次の設定が必要です。

J2EEサーバ

Connector属性ファイル

J2EEアプリケーション

cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築ファイルで実施します。リソース枯渇監視機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。なお，バッチサーバ単位での設定の場合，簡易構築定義ファイルのバッチサーバ用のユーザプロパティに設定します。

簡易構築定義ファイルでのリソース枯渇監視機能の定義には，次の二つがあります。

リソース枯渇監視機能の有効化

リソース種別ごとの監視の設定

(a)　リソース枯渇監視機能の有効化

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.watch.enabledパラメタでリソース枯渇監視機能を使用するかどうかを指定します。デフォルトの設定では，リソース枯渇監視機能の使用が有効になっていて，すべてのリソースが監視されるようになっています。なお，リソース枯渇監視機能を無効にしたい場合には，ejbserver.watch.enabledパラメタにfalse（リソース枯渇監視機能を無効にする）を指定してください。

(b)　リソース種別ごとの監視の設定

簡易構築定義ファイルでのリソース種別ごとの監視の定義について次の表に示します。

表4‒4　簡易構築定義ファイルでのリソース枯渇監視機能の定義

リソース種別

指定するパラメタ

設定内容

メモリ

ejbserver.watch.memory.enabled

ejbserver.watch.memory.threshold

ejbserver.watch.memory.interval

ejbserver.watch.memory.writefile.enabled

J2EEサーバ単位，またはバッチサーバ単位で，メモリ監視の設定をします。

メモリ監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

また，リソース枯渇監視ログファイルの面数，サイズを指定します。※1※2

ファイルディスクリプタ

ejbserver.watch.fileDescriptor.enabled

ejbserver.watch.fileDescriptor.threshold

ejbserver.watch.fileDescriptor.interval

ejbserver.watch.fileDescriptor.writefile.enabled

J2EEサーバ単位，またはバッチサーバ単位で，ファイルディスクリプタ監視の設定をします。

ファイルディスクリプタ監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

また，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

スレッド数

ejbserver.watch.thread.enabled

ejbserver.watch.thread.threshold

ejbserver.watch.thread.interval

ejbserver.watch.thread.writefile.enabled

J2EEサーバ単位で，スレッド数監視の設定をします。

スレッド数監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

また，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

スレッドダンプ

ejbserver.watch.threaddump.enabled

ejbserver.watch.threaddump.threshold

ejbserver.watch.threaddump.interval

ejbserver.watch.threaddump.writefile.enabled

ejbserver.server.threaddump.filenum

J2EEサーバ単位，またはバッチサーバ単位で，スレッドダンプ監視の設定をします。

スレッドダンプ監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

また，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

HTTPリクエスト実行待ちキュー

ejbserver.watch.defaultRequestQueue.enabled

ejbserver.watch.defaultRequestQueue.threshold

ejbserver.watch.defaultRequestQueue.interval

ejbserver.watch.defaultRequestQueue.writefile.enabled

J2EEサーバ単位で，デフォルトの実行待ちキューの場合のHTTPリクエスト実行待ちキュー監視の設定をします。

HTTPリクエスト実行待ちキュー監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

また，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

セッション数

−

J2EEサーバ単位で，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

コネクションプール

−

J2EEサーバ単位，またはバッチサーバ単位で，リソース枯渇監視ログファイルの面数，サイズを指定します。※2

（凡例）　−：なし

注※1　メモリ監視する場合は，論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，JavaVM起動パラメタを定義します。JavaVM起動パラメタには，-XX:MetaspaceSizeと-XX:MaxMetaspaceSizeを指定し，メモリサイズは同じ値にしてください。メモリサイズに異なる値を指定した場合，アラートが出力されずにFullGCが発生することがあります。JavaVM起動パラメタの指定内容を次に示します。

<param-name>タグ

add.jvm.arg

<param-value>タグ

-XX:MetaspaceSiz=（設定値）

-XX:MaxMetaspaceSize=（設定値）

また，FullGCの予兆を検知するためには，JavaVMのOld領域，New領域のサイズをチューニングする必要があります。

注※2　リソース枯渇監視ログファイルのファイルの面数，サイズは，簡易構築定義ファイルの次に示すパラメタで指定します。

ejbserver.logger.channels.define.<監視リソース名>WatchLogFile.filenum

リソース種別ごとにリソース枯渇監視ログファイルのファイル数を指定します。

ejbserver.logger.channels.define.<監視リソース名>WatchLogFile.filesize

リソース種別ごとにリソース枯渇監視ログファイルのファイルサイズを指定します。

これらのパラメタの監視リソース名には，リソース種別ごとのチャネル名を指定します。

メモリの場合：MemoryWatchLogFile

ファイルディスクリプタの場合：FileDescriptorWatchLogFile

スレッド数の場合：ThreadWatchLogFile

スレッドダンプの場合：ThreaddumpWatchLogFile

HTTPリクエスト実行待ちキューの場合：RequestQueueWatchLogFile

セッション数の場合：HttpSessionWatchLogFile

コネクションプールの場合：ConnectionPoolWatchLogFile

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　Connector属性ファイルの設定

リソースアダプタ単位でコネクションプール監視の設定をします。リソースアダプタのプロパティ設定は，サーバ管理コマンドおよびConnector属性ファイルで実施します。

Connector属性ファイルの<property-name>タグとして指定する<WatchEnabled>，<WatchThreshold>，<WatchInterval>，<WatchWriteFileEnabled>タグで，コネクションプール監視によるアラート出力の有無，監視のしきい値，監視の間隔，リソース枯渇監視ログファイルの出力の有無を指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

サーバ管理コマンドおよびConnector属性ファイルでのリソースアダプタのプロパティの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.5.1　J2EEリソースのプロパティの設定手順」を参照してください。

(3)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リソース枯渇監視機能の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「4.3.2　cosminexus.xmlでの定義」を参照してください。

4.3.4　リソース枯渇監視情報ファイルの出力先と出力情報の種類

(1)　リソース枯渇監視情報の出力先

デフォルトの設定の場合，リソース枯渇監視情報ファイルは，J2EEサーバの起動時に次のフォルダに作成されます。

Windowsの場合

<ejb.server.log.directory>¥watch¥以下に出力されます。

UNIXの場合

<ejb.server.log.directory>/watch/以下に出力されます。

注意事項

<ejb.server.log.directory>は，J2EEサーバのユーザ定義（usrconf.cfgファイル中のejb.server.log.directory）で指定されたディレクトリを指します。デフォルト値は，Windowsの場合，「<Application Serverのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs」，UNIXの場合，「/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs」です。

<ejb.server.log.directory>を変更することで，リソース枯渇監視情報の出力先も変更されます。

(2)　出力情報の種類

リソース枯渇監視情報には，次の表に示す情報が出力されます。なお，Windows，またはAIXの場合，ファイルディスクリプタの数は監視できません。また，Linuxの場合，スレッド監視は使用できません。

表4‒5　リソース枯渇監視情報に出力される情報

情報の種類

ファイル名

情報の概要

メモリ枯渇監視情報

cjmemorywatch

JavaVMのヒープおよびメモリ領域の使用状況の監視結果が出力されます。

この情報は，usrconf.propertiesのejbserver.watch.memory.writefile.enabledキーにtrueが設定されている場合に出力されます。

ファイルディスクリプタ枯渇監視情報

cjfiledescriptorwatch

J2EEサーバプロセスが使用しているファイルディスクリプタの数の監視結果が出力されます。

この情報は，usrconf.propertiesのejbserver.watch.fileDescriptor.writefile.enabledキーにtrueが設定されている場合に出力されます。

スレッド枯渇監視情報

cjthreadwatch

J2EEサーバプロセスが生成したスレッド数の監視結果が出力されます。

この情報は，usrconf.propertiesのejbserver.watch.thread.writefile.enabledキーにtrueが設定されている場合に出力されます。

スレッドダンプ枯渇監視情報

cjthreaddumpwatch

出力されたスレッドダンプのファイル数の監視結果が出力されます。

この情報は，usrconf.propertiesのejbserver.watch.threaddump.writefile.enabledキーにtrueが設定されている場合に出力されます。

HTTPリクエスト実行待ちキュー枯渇監視情報

cjrequestqueuewatch

HTTPリクエスト実行待ちキューの監視結果として，次の2種類の実行待ちキューが監視され，結果が出力されます。

Webアプリケーション単位の最大同時実行スレッド数が設定されていないWebアプリケーションの実行待ちキューが監視されて，リクエスト格納数の監視結果が出力されます。

この情報は，usrconf.propertiesのejbserver.watch.defaultRequestQueue.writefile.enabledキーにtrueが設定されている場合に出力されます。

Webアプリケーション単位の最大同時実行スレッド数が設定されているWebアプリケーションの実行待ちキューが監視されて，リクエスト格納数の監視結果が出力されます。

この情報は，アプリケーションの属性として，<war><hitachi-war-property><thread-control><resource-watcher>タグ下の<watcher-writefile-enabled>タグにtrueが設定されている場合に出力されます。

なお，Webアプリケーション単位の最大同時実行スレッド数の制御が有効な場合に，これらの監視が実行されます。

URLグループ単位の実行待ちキューの情報については，HTTPリクエスト実行待ちキュー枯渇監視情報には出力されません。URLグループ単位の実行待ちキューの稼働情報については，稼働情報収集機能を使用して監視してください。稼働情報収集機能については，「3.　稼働情報の監視（稼働情報収集機能）」を参照してください。

セッション数枯渇監視情報

cjhttpsessionwatch

Webアプリケーション単位のセッション数の監視結果が出力されます。

この情報は，アプリケーションの属性として，<war><hitachi-war-property><http-session><resource-watcher>タグ下の<watcher-writefile-enabled>タグにtrueが設定されている場合に出力されます。

コネクションプール枯渇監視情報

cjconnectionpoolwatch

リソースアダプタ単位のコネクションプール数の監視結果が出力されます。

この情報は，リソースアダプタのプロパティとして，WatchWriteFileEnabledプロパティにtrueが設定されている場合に出力されます。

4.3.5　出力形式と出力内容

リソース枯渇監視情報は，出力レコードがCSV形式ファイルで出力されます。

出力形式を次の図に示します。

図4‒1　リソース枯渇監視情報の出力形式

出力形式について説明します。

それぞれのカラムの出力内容がわかるように，タイトル行が，100行ごとに出力されます。

タイトルには，リソース共通の情報として，次の項目が出力されます。これらの項目は，図中の，"Title1"，"Title2"，"Title3"…の個所に出力されます。

Rate：割合（使用率）

Current：現在値

Max：最大値

Threshold：しきい値

このほか，リソースによって，必要な情報が出力されます。詳細は，それぞれのリソースの出力内容を参照してください。

しきい値判定の計算結果，現在値情報，設定したしきい値の順で出力されます。しきい値判定の結果が複数ある場合は，複数出力されます。

しきい値が%で設定されている場合，しきい値の計算結果も%で出力されます。例えば，計算結果が0.752であった場合，しきい値が%で指定されているときには，75.2と出力されます。

しきい値が絶対値の場合は，しきい値の計算結果は出力されません。

しきい値として上限が設定されていない場合，しきい値の計算結果は，「-」と出力されます。

値が小数になる場合は，小数点以下第2位が四捨五入され，小数点以下第1位までが出力されます。なお，しきい値判定にも，小数点以下第2位が四捨五入され，小数点以下第1位までにした値が利用されます。

なお，ファイルに出力される内容については，usrconf.properties，アプリケーションの属性，またはリソースアダプタの属性の設定内容に従います。

それぞれの出力情報について説明します。

(1)　メモリ枯渇監視情報

メモリ枯渇監視情報には，次の表に示す情報が出力されます。

表4‒6　メモリ枯渇監視情報の出力内容

出力タイトル文字列

出力内容

Rate1

SerialGCが有効な場合：

Old領域のメモリ使用率が出力されます。

単位は%です。

Old領域のメモリ使用率は，次の計算式で算出されます。

Old領域のメモリ使用率 = Old領域消費サイズ / Old領域合計サイズ×100

（Rate1 = (Total [Old] - Free [Old]) / Total [Old]×100）

G1GCが有効な場合：

Javaヒープ領域メモリ使用率が出力されます。

単位は%です。

Javaヒープ領域のメモリ使用率は，次の計算式で算出されます。

Javaヒープ領域メモリ使用率[%]

＝ Javaヒープ領域消費サイズ／Javaヒープ領域サイズ ×100

Rate2

SerialGCが有効な場合：

Old領域最大空きメモリに対するNew領域の合計メモリ率が出力されます。

単位は%です。

Old領域最大空きメモリに対するNew領域の合計メモリ率は，次の計算式で算出されます。

Old領域最大空きメモリに対するNew領域の合計メモリ率 = New領域合計サイズ / Old領域最大空きサイズ×100

（Rate2 = Total [New] / (Max [Old] - (Total [Old] - Free [Old]))×100）

なお，この値は100を超える場合があります。

G1GCが有効な場合：

この情報は使用しません。常に-1が出力されます。

Rate3

Metaspace領域のメモリ使用率が出力されます。

単位は%です。

Metaspace領域のメモリ使用率は，次の計算式で算出されます。

Metaspace領域のメモリ使用率 = Metaspace領域消費サイズ / Metaspace領域最大サイズ×100

（Rate3 = (Total [Permanent] - Free [Permanent]) / Total [Permanent]×100）

Free [New]

New領域の空きメモリサイズが出力されます。

単位はバイトです。

Total [New]

New領域の合計メモリサイズが出力されます。

単位はバイトです。

Max [New]

SerialGCが有効な場合：

New領域の最大メモリサイズが出力されます。

単位はバイトです。

G1GCが有効な場合：

この情報は使用しません。常に-1が出力されます。

Free [Old]

Old領域の空きメモリサイズが出力されます。

単位はバイトです。

Total [Old]

Old領域の合計メモリサイズが出力されます。

単位はバイトです。

Max [Old]

SerialGCが有効な場合：

Old領域の最大メモリサイズが出力されます。

単位はバイトです。

G1GCが有効な場合：

Javaヒープ領域の最大メモリサイズが出力されます。

Free [Permanent]

Metaspace領域の空きメモリサイズが出力されます。

単位はバイトです。

Total [Permanent]

Metaspace領域の合計メモリサイズが出力されます。

単位はバイトです。

Max [Permanent]

Metaspace領域の最大メモリサイズが出力されます。

単位はバイトです。

Threshold

しきい値が出力されます。

単位は%です。

注意事項

メモリ枯渇監視機能は，十分にメモリ設計をして，FullGCが起こりにくいようにチューニングされたシステムを前提としています。メモリ枯渇監視機能は，このようにチューニングされたシステムであっても，FullGCが発生してアプリケーションが一時的に停止する予兆を検知することを目的としています。したがって，メモリチューニングが十分でない場合は，不要なアラートが出力されることがありますので，ご注意ください。

メモリ枯渇監視する場合は，Metaspace領域の最大サイズと初期サイズに同じ値を設定する必要があります。具体的にはusrconf.cfgの-XX:MaxMetaspaceSizeと-XX:MetaspaceSizeを同じ値にします。異なる値を設定した場合，Metaspace領域の領域拡張でもアラートが出力される場合があります。そのほかのチューニングパラメタについては，OracleのWebサイトなどの情報を参照してください。

また，この機能で監視しているメモリ使用率が100%に近づいた場合に必ずFullGCが発生するわけではありません。監視した値は，FullGCが発生する可能性が高いという予兆を検知するために使用されます。

アプリケーションサーバ 09-00からFullGCが起こりにくいようにJavaヒープを有効活用するようになりました。これによって，Javaヒープの使用率が高いままシステムが稼働し続け，不要なアラートが出力されることがあります。Rate1のアラート出力を抑止したい場合，しきい値を調整してください。Rate2のアラート出力を抑止したい場合，usrconf.propertiesに，ejbserver.watch.memory.rate2alert.enabled=falseを指定してください。

参考

JavaVMでのヒープおよびメモリには，次の3種類の領域があります。

New領域

EdenとSurvivorに該当する領域です。新しいオブジェクトが格納されます。

Old領域

Tenuredに該当する領域です。長時間存在するオブジェクトが格納されます。

Metaspace領域

JavaVMにロードされたクラスが格納される領域です。

アプリケーションサーバ09-70以降，Metaspace領域となりました。

アプリケーションサーバ09-70より前はPermanent領域であったため，旧バージョンからの互換性を重視し，Metaspace領域のメモリサイズを出力するメモリ監視出力の出力タイトル文字列内の表記はPermanentとなっています。

メモリ監視結果情報には，これらの領域ごとに，その時点での空き領域，消費されている領域，および最大領域のサイズが出力されます。

メモリ監視を設定した場合，次の場合にメッセージが出力されます。

Old領域の合計サイズに対するOld領域の消費サイズがしきい値以上の場合（SerialGCが有効な場合）

「Old領域消費サイズ／Old領域合計サイズ×100≧しきい値（%）」の場合に出力されます。

Old領域の最大空きサイズに対するNew領域の合計サイズがしきい値以上の場合（SerialGCが有効な場合）

「New領域合計サイズ／Old領域最大空きサイズ×100≧しきい値（%）」の場合に出力されます。

Javaヒープ領域の合計サイズに対するJavaヒープ領域の消費サイズがしきい値以上の場合（G1GCが有効な場合）

「Javaヒープ領域消費サイズ／Javaヒープ領域合計サイズ×100≧しきい値（%）」の場合に出力されます。

Metaspace領域の最大サイズに対するMetaspace領域の消費サイズがしきい値以上の場合

「Metaspace領域消費サイズ／Metaspace領域最大サイズ×100≧しきい値（%）」の場合に出力されます。

(2)　ファイルディスクリプタ枯渇監視情報

ファイルディスクリプタ監視結果情報には，次の表に示す情報が出力されます。なお，Windows，またはAIXの場合，ファイルディスクリプタの数は監視できません。

表4‒7　ファイルディスクリプタ枯渇監視情報の出力内容

出力タイトル文字列

出力内容

Current

J2EEサーバプロセスが使用しているファイルディスクリプタ数が出力されます。

Max

プロセスに割り当て可能なファイルディスクリプタの数が出力されます。

Threshold

しきい値が出力されます。

(3)　スレッド枯渇監視情報

スレッド枯渇監視情報には，次の表に示す情報が出力されます。

表4‒8　スレッド枯渇監視情報の出力内容

出力タイトル文字列

出力内容

Current

自プロセスが使用しているスレッド数が出力されます。

Max

Windowsの場合

常に"-"が出力されます。

UNIXの場合

プロセスに生成できるスレッド数が出力されます。

Threshold

しきい値が出力されます。

(4)　スレッドダンプ枯渇監視情報

スレッドダンプ枯渇監視情報には，次の表に示す情報が出力されます。

表4‒9　スレッドダンプ枯渇監視情報の出力内容

出力タイトル文字列

出力内容

Rate

現在のスレッドダンプのファイル数が，最大値に占める割合が出力されます。

単位は%です。

Current

スレッドダンプのファイル数の現在値が出力されます。

Max

スレッドダンプのファイル数の上限値が出力されます。

Threshold

しきい値が出力されます。

単位は%です。

(5)　HTTPリクエスト実行待ちキュー枯渇監視情報

HTTPリクエスト実行待ちキューとは，Webアプリケーションの同時実行スレッドに対する，Webアプリケーション単位およびデフォルトの実行待ちキューのことです。

HTTPリクエスト実行待ちキュー枯渇監視情報には，次の表に示す情報が出力されます。なお，この枯渇監視情報には，次の2種類の情報が含まれます。

J2EEサーバ単位でデフォルトのリクエスト実行待ちキュー格納数の監視結果

Webアプリケーション単位のリクエスト実行待ちキュー格納数の監視結果

表4‒10　HTTPリクエスト実行待ちキュー枯渇監視情報の出力内容

出力タイトル文字列

出力内容

J2eeApplicationName

J2EEアプリケーション名が出力されます。

デフォルトのリクエスト実行待ちキューの監視結果の場合は，"-"が出力されます。

ContextRootName

コンテキストルート名が出力されます。

デフォルトのリクエスト実行待ちキューの監視結果の場合は，"-"が出力されます。

Rate

現在のキュー格納数の最大値に占める割合が出力されます。

単位は%です。

Current

キュー格納数の現在値が出力されます。

Max

Webアプリケーション単位またはデフォルトの実行待ちキューのリクエスト格納数の最大値が出力されます。

Threshold

しきい値が出力されます。

単位は%です。

(6)　セッション数枯渇監視情報

セッション数枯渇監視情報には，次の表に示す情報が出力されます。

表4‒11　セッション数枯渇監視情報の出力内容

出力タイトル文字列

出力内容

J2eeApplicationName

J2EEアプリケーション名が出力されます。

ContextRootName

コンテキストルート名が出力されます。

Rate

現在のセッション作成数の最大値に占める割合が出力されます。

単位は%です。

最大値が設定されていない場合は，"-"が出力されます。

Current

セッション数の現在値が出力されます。

Max

セッション数の最大値が出力されます。

設定されていない場合は"-"が出力されます。

Threshold

しきい値が出力されます。

単位は%です。

(7)　コネクションプール枯渇監視情報

コネクションプール枯渇監視情報には，次の表に示す情報が出力されます。

表4‒12　コネクションプール枯渇監視情報の出力内容

出力タイトル文字列

出力内容

ResourceName

ユーザが付けたリソースアダプタ名が次の形式で出力されます。

リソースアダプタを直接J2EEサーバにデプロイした場合

<リソースアダプタ名>

リソースアダプタをJ2EEアプリケーションに含めてデプロイした場合

<J2EEアプリケーション名>：<リソースアダプタ名>

リソースアダプタをJ2EEアプリケーションに含めてデプロイして，テストモードで開始した場合

TEST#<J2EEアプリケーション名>：<リソースアダプタ名>

Rate

コネクションプールの使用率が出力されます。

単位は%です。

コネクション数の最大値が無制限の場合，"-"が出力されます。

Active

使用中のコネクション数が出力されます。

Free

未使用のコネクション数が出力されます。

Current

コネクション数の現在値が出力されます※。

Min

コネクション数の最小値が出力されます。

Max

コネクション数の最大値が出力されます。

コネクションプールが無制限の場合，"-1"が出力されます。

Threshold

しきい値が出力されます。

単位は%です。

All

コネクションの総数（コネクションプール管理内のコネクションとコネクションプール管理外のコネクションの総数）が出力されます※。

注※　コネクションを接続するタイミングによっては，一時的にAllよりも多い値がCurrentに出力されることがあります。

5　J2EEアプリケーションの運用

この章では，J2EEアプリケーションの運用について説明します。

J2EEアプリケーションの運用では，J2EEアプリケーションの実行時間の監視，サービスの閉塞，停止，入れ替え，およびJ2EEアプリケーションからのネットワークリソースへのアクセスができます。

5.1　この章の構成

J2EEアプリケーションの運用と参照先を次の表に示します。

表5‒1　J2EEアプリケーションの運用と参照先

機能

参照先

J2EEアプリケーションの運用の概要

5.2

J2EEアプリケーションの実行時間の監視とキャンセル

5.3

J2EEアプリケーションのサービスの閉塞

5.4

J2EEアプリケーションの停止

5.5

J2EEアプリケーションの入れ替え

5.6

J2EEアプリケーションからのネットワークリソースへのアクセス

5.7

5.2　J2EEアプリケーションの運用の概要

J2EEアプリケーションの運用とは，J2EEサーバにデプロイしたJ2EEアプリケーションに対して，日常業務の中で定型的な運用を実施したり，業務状況の変化に応じて適切に設定を変更してチューニングを実施したりすることです。

ここでは，J2EEアプリケーションを運用する作業の概要を説明します。

5.2.1　タイムアウトしたリクエストをキャンセルする

J2EEアプリケーションで実行しているリクエストが無限ループなどの原因によって制御できなくなった場合，リクエストを強制的にキャンセルして，リソースを解放する必要があります。あらかじめJ2EEアプリケーション内のメソッドの実行状態を監視しておくことで，予定した時間内に完了しないリクエストに対して，キャンセルを実行できます。

5.2.2　J2EEアプリケーションを停止する

一日のうち特定の時間だけクライアントにサービスを提供するJ2EEアプリケーションでは，毎日決まった時間にJ2EEアプリケーションを停止して，次の日に再度開始する作業が必要です。また，24時間連続稼働させているサービスをメンテナンスする場合は，一度にすべてのJ2EEアプリケーションを停止するのではなく，一部ずつ停止させて，サービスを提供し続けられるような運用を検討する必要があります。J2EEアプリケーションを停止するとき，まず，リクエストの受け付けを停止して，すでに受け付けたリクエストについては処理を実行してからJ2EEアプリケーションを停止させる方法を，サービス閉塞といいます。日常運用の中でJ2EEアプリケーションを停止する場合，サービス閉塞を適切に実行することで，安全にサービスを停止できます。実行できるサービス閉塞の方法は，J2EEアプリケーションの構成やシステムの構成によって異なります。

5.2.3　J2EEアプリケーションを強制停止する

日常運用でJ2EEアプリケーションを停止する場合や，トラブルが発生して即座にJ2EEアプリケーションを停止したい場合などに，J2EEアプリケーション内のリクエストが完了していないことが原因で停止処理が完了しないことがあります。この場合，J2EEアプリケーションを強制的に停止する必要があります。

J2EEアプリケーションの強制停止では，完了しないリクエストを強制的に終了させます。これによって，J2EEアプリケーションを停止できる状態にできます。

5.2.4　J2EEアプリケーションを入れ替える

運用中のJ2EEアプリケーションをバージョンアップしたりメンテナンスしたりする場合，J2EEアプリケーションの入れ替え作業を実施します。

J2EEアプリケーションを入れ替える場合にサービスを停止したくないときは，適切なサービス閉塞をする必要があります。CTMを利用してJ2EEサーバへのクライアントからのリクエストを制御して，システム全体を停止させないでJ2EEアプリケーションを入れ替えられます。これによって，クライアントからのリクエストを受け付けながら，オンライン状態でJ2EEアプリケーションを入れ替えられます。なお，CTMで制御できるのは，RMI-IIOP通信を使用する，Stateless Session Beanに対するリモートインタフェース呼び出しのリクエストだけです。

なお，CTMは，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2.1　製品と構成ソフトウェアの対応」を参照してください。

5.2.5　J2EEアプリケーションからネットワークリソースにアクセスする

J2EEアプリケーションから，ネットワークリソースのパスをUNCまたはネットワークドライブを使用してアクセスできます。なお，この機能はWindowsの場合に使用します。UNIXの場合，特に設定をしなくても，J2EEアプリケーションからネットワークリソースにアクセスできます。

5.2.6　J2EEアプリケーションの運用の作業と参照先

J2EEアプリケーションの運用の作業と参照先を，表5-2から表5-5に示します。なお，J2EEアプリケーションからのネットワークリソースまたはネットワークドライブへのアクセスについては，事前に設定するだけで使用できるため，運用時の作業はありません。

表5‒2　J2EEアプリケーションの実行時間の監視とキャンセル

作業内容

手段

作業概要

参照先マニュアル

参照先

J2EEアプリケーションの実行状態の確認

サーバ管理コマンド（cjlistthread）

実行中のJ2EEアプリケーションの実行状態を確認します。

このマニュアル

5.3.11

タイムアウトが発生したリクエストのキャンセル

サーバ管理コマンド（cjstopthread）

J2EEアプリケーション内で実行されているリクエストのうち，終了しないリクエストをキャンセルします。

5.3.12

表5‒3　J2EEアプリケーションの閉塞

作業内容

手段

作業概要

参照先マニュアル

参照個所

負荷分散機を使用したサービス閉塞

負荷分散機の機能

Webフロントに負荷分散機を使用している場合に，次の方法でサービスを閉塞します。

負荷分散機のリクエストの振り分け先を変更する

負荷分散機を停止する

サービスを構成する一部のWebアプリケーションだけを停止する

このマニュアル

5.4.3

CTMを利用したサービス閉塞

運用管理コマンド（mngsvrutil）

CTMを使用しているバックシステムで，ホスト内のJ2EEアプリケーションを一度に停止したり，キューを共有するJ2EEアプリケーションを一度に停止したりする場合，J2EEアプリケーションのスケジュールキューに対して直接閉塞を実行します。

機能解説 拡張編

3.7.4

表5‒4　J2EEアプリケーションの停止

作業内容

手段

作業概要

参照先マニュアル

参照個所

J2EEアプリケーションの停止

サーバ管理コマンド（cjstopapp）

J2EEアプリケーションを通常停止，または強制停止します。通常停止にタイムアウトを設定して，強制停止を自動で実行することもできます。

このマニュアル

5.5.7

表5‒5　J2EEアプリケーションの入れ替えと保守

作業内容

手段

作業概要

参照先マニュアル

参照個所

J2EEアプリケーションの通常入れ替え

サーバ管理コマンド（cjstopapp，cjimportapp※）

J2EEアプリケーションを停止してから新しいアプリケーションに入れ替えます。入れ替え後，J2EEアプリケーションを再開始します。

このマニュアル

5.6.3(1)

リデプロイによるJ2EEアプリケーションの入れ替え

サーバ管理コマンド（cjreplaceapp）

リデプロイによってJ2EEアプリケーションを入れ替えます。アーカイブ形式のJ2EEアプリケーションを入れ替える場合に，少ない手順で入れ替えることができます。

5.6.3(2)

リロードによるJ2EEアプリケーションの入れ替え

サーバ管理コマンド（cjreloadapp）

リロードによってJ2EEアプリケーションを入れ替えます。展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に，少ない手順で入れ替えることができます。

5.6.3(3)

JSPを事前にコンパイルしてから実行するJ2EEアプリケーションの入れ替え

サーバ管理コマンド（cjstartapp）／cjjspcコマンド

JSP事前コンパイル機能を使用して，JSPを事前にコンパイルしてからJ2EEアプリケーションを入れ替えます。

5.6.3(4)

J2EEアプリケーションの名称変更

サーバ管理コマンド（cjrenameapp）

名称を変更して，入れ替え前や入れ替え後のJ2EEアプリケーションを管理しやすくします。

5.6.3(5)

CTMを利用したオンライン状態でのJ2EEアプリケーションの入れ替え

運用管理コマンド（mngsvrutil）

スケジュールキューの出口を閉じたあと，J2EEアプリケーションを入れ替えます。

機能解説 拡張編

3.7.2

注※　WARアプリケーションの場合，cjimportwarコマンドを使用します。

5.3　J2EEアプリケーションの実行時間の監視とキャンセル

この節では，J2EEアプリケーション実行時間の監視機能と，J2EEアプリケーション実行時間の監視機能で提供するメソッドタイムアウト機能，およびメソッドキャンセル機能について説明します。

注意事項

Javaの仕様やJavaVM実装上の制限によって，メソッドキャンセルができないことがあります。この場合，メソッドキャンセルができない領域は，クラス単位ではない特殊な保護区としています。Javaの仕様やJavaVM実装上の制限によって，メソッドキャンセルができなかった場合は，メッセージKDJE52718-Wの詳細情報で次に示すクラス名が表示されます。

JP.co.Hitachi.soft.jvm.CriticalClass.dummy(Native Method)

なお，保護区については，「5.3.4(1)　保護区と非保護区」を参照してください。

この節の構成を次の表に示します。

表5‒6　この節の構成（J2EEアプリケーションの実行時間の監視とキャンセル）

分類

タイトル

参照先

解説

J2EEアプリケーションの実行時間の監視とキャンセルの概要

5.3.1

J2EEアプリケーション実行時間の監視とは

5.3.2

メソッドタイムアウトとは

5.3.3

メソッドキャンセルとは

5.3.4

タイムアウト値の設定例と設定値の有効範囲

5.3.5

使用するスレッド数

5.3.6

実装

cosminexus.xmlでの定義

5.3.7

設定

実行環境での設定

5.3.9

運用

J2EEアプリケーションの実行時間の監視とキャンセルの流れ

5.3.10

J2EEアプリケーションの実行状態の確認

5.3.11

タイムアウトが発生したリクエストのキャンセル

5.3.12

J2EEアプリケーション実行時間監視で出力されるログ情報

5.3.13

注意事項

実装時の注意事項

5.3.8

5.3.1　J2EEアプリケーションの実行時間の監視とキャンセルの概要

J2EEアプリケーションの内部で無限ループなどが発生すると，J2EEアプリケーションの動作を制御できなくなります。このようなトラブルへの対策として，J2EEアプリケーションの実行時間にタイムアウト値を設定しておき，一定時間を過ぎたら処理が完了しなくても制御が戻るように設定する方法があります。

このような設定をするには，次の2種類の機能を使用できます。

メソッドタイムアウト機能

メソッドキャンセル機能

これらの機能では，J2EEアプリケーション内のメソッド単位にタイムアウト時間を設定して監視し，一定時間内に終了しなかったリクエストのタイムアウトを検知できます（メソッドタイムアウト機能）。また，タイムアウトが発生した場合，強制的にメソッドをキャンセルできます（メソッドキャンセル機能）。このとき，トランザクションも強制決着されます。メソッドキャンセルは，自動的に実行されるように設定できます。

5.3.2　J2EEアプリケーション実行時間の監視とは

J2EEアプリケーション実行時間の監視とは，EJBおよびWebアプリケーションのリクエスト実行時間を監視する機能です。J2EEアプリケーション実行時間の監視機能によって，J2EEアプリケーションで無限ループなどの障害発生を検知すると，一定時間内に終了しなかったメソッド処理をタイムアウトしてユーザに通知し，さらにメソッドキャンセル機能によって使用中のトランザクションの強制決着とメソッドのキャンセルを実施できます。

J2EEアプリケーション実行時間の監視機能には，メソッドタイムアウト機能と，メソッドキャンセル機能があります。

メソッドタイムアウト機能

監視基盤にあるリクエストのうち，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知する機能です。監視基盤とは，J2EEアプリケーション実行時間の監視機能を実現するために必要なインタフェースを提供し，監視情報を管理する領域です。

メソッドキャンセル機能

メソッドタイムアウト機能でタイムアウトが通知されたあと，メソッドのキャンセルを実施する機能です。キャンセル時にデータベースにアクセスしている場合は，トランザクションの強制決着もします。

なお，メソッドタイムアウト機能およびメソッドキャンセル機能では，ログ情報としてスレッドダンプを出力します。出力されたスレッドダンプのファイル数は，リソース枯渇監視機能で監視できます。リソース枯渇監視機能については，「4.　リソースの枯渇監視」を参照してください。

J2EEアプリケーション実行時間の監視機能について次の図に示します。

図5‒1　J2EEアプリケーション実行時間の監視機能の概要

図中のコマンドについて説明します。

一覧表示コマンド

メソッドキャンセルコマンドを実施する前に，メソッドキャンセルコマンドを実行できるかどうかを確認するときに使用します。一覧表示コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistthread（スレッド情報の表示）」を参照してください。

メソッドキャンセルコマンド

タイムアウトが検知された場合，またはスレッドの状態が不正な場合に使用します。メソッドキャンセルコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstopthread（スレッドの削除）」を参照してください。

アプリケーション強制停止コマンド

アプリケーションを強制停止するときに使用します。アプリケーションの強制停止については，「5.5　J2EEアプリケーションの停止」を参照してください。アプリケーション強制停止コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstopapp（J2EEアプリケーションの停止）」を参照してください。

5.3.3　メソッドタイムアウトとは

メソッドタイムアウトとは，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知する機能です。

(1)　タイムアウトの判定とタイムアウト後の動作

タイムアウトは，監視基盤で監視されるメソッドの呼び出しが，次の式を満たす場合に発生します。

タイムアウト判定時点の時刻−メソッド開始時刻 ＞ タイムアウトの時間

また，タイムアウト発生後は，次のどちらかの動作（メソッドキャンセルのモード）を選択できます。

KDJE52703-Wのメッセージを出力する

KDJE52703-Wのメッセージを出力して，メソッドキャンセル機能を実行する

どちらの動作を選択した場合も，タイムアウトした呼び出しが終了したときに，KDJE52716-Iのメッセージが出力されます。

(2)　メソッドタイムアウト機能の対象となる処理

メソッドタイムアウトの対象となる処理に，タイムアウトを設定します。設定する個所は次のとおりです。

Webアプリケーションのリクエスト処理

EJBのメソッド呼び出し処理

なお，メソッドタイムアウトの適用対象として，次の処理は含まれません。

J2EEアプリケーションのデプロイ時やアンデプロイ時に動作する処理

EJBコンテナの状態管理機能，およびアクティブセッションのタイムアウト機能で動作するEnterprise Beanの処理

Enterprise Beanのメソッド呼び出し処理とは別に，EJBコンテナが設定によって自動的に行う処理は，メソッドタイムアウトの適用対象に含まれません。

また，J2EEアプリケーションのデータ構造によっては，メソッドタイムアウトができない場合があります。詳細については，「5.3.8　実装時の注意事項」を参照してください。

(3)　タイムアウト検知間隔とメソッドタイムアウト時間

メソッドタイムアウト機能を使用する場合，次の設定が必要です。

タイムアウトを検知する時間の間隔

タイムアウトを検知するための時間間隔を設定します。

メソッドタイムアウトが発生しているかどうかの判定が，指定した間隔ごとにJ2EEサーバによって判定されます。これは，J2EEサーバ単位に設定します。

また，タイムアウトの検知は一定間隔で行われるため，検知までに最大で次の時間が掛かります。

タイムアウトの検知に掛かる時間の算出式

タイムアウトの検知に掛かる時間＝タイムアウトの時間+タイムアウトを検知する時間の間隔

J2EEアプリケーションごとのメソッドタイムアウト時間

メソッドタイムアウトにする時間を，J2EEアプリケーションに設定します。

設定は，J2EEアプリケーション内のEnterprise Bean単位，またはWebアプリケーション単位に設定します。

J2EEアプリケーションの実行時間監視の設定については，「5.3.9　実行環境での設定」を参照してください。

5.3.4　メソッドキャンセルとは

メソッドキャンセルとは，タイムアウトの原因となっている実行中の処理をキャンセルする処理です。メソッドキャンセル時には，現在実行されている処理がキャンセルできるかどうかを判断します。

ポイント

Connector 1.5仕様に準拠したリソースアダプタを使用している場合，次の処理はメソッドキャンセルの対象にできません。

リソースアダプタ独自のメソッド

ワーク管理で実行されているWork

ただし，Workによって呼び出されたMessage-driven Bean内の処理については，メソッドキャンセルの対象にできます。

(1)　保護区と非保護区

メソッドをキャンセルできる領域のことを非保護区，メソッドをキャンセルできない領域を保護区といいます。

保護区とは，メソッドキャンセルのできない領域です。保護区では，J2EEサーバの動作で共有されるデータや領域を保持したり，JavaVM内で行われる処理を保証したりするため，メソッドキャンセルができません。J2EEサービス，Webコンテナ，EJBコンテナが保護区に該当します。保護区として定義されている内容については，「付録C　保護区リストの内容」を参照してください。ここに記載されている保護区に該当するクラス以外で，保護区として扱いたいクラスがある場合は，保護区リストファイルに記述してください。

一方，非保護区は，メソッドキャンセルができる領域です。J2EEアプリケーションが非保護区になります。

保護区，非保護区の判定は，クラス単位で行われます。ただし，非保護区の場合は実行時の条件によって保護区として扱われることがあります。J2EEアプリケーションでも，ネイティブメソッドを呼び出している場合や，スタティックイニシャライザを実行している場合は，保護区と判定されます。また，java.lang.Objectクラスのwaitメソッドは，スタティックイニシャライザの延長での呼び出しではない場合だけ，例外的に非保護区と判定されます。※

注※　java.lang.Objectクラスのwaitメソッドは，指定時間の経過やnotify/notifyAllによって処理が再開される時に，スレッドのモニタ（ロック）を取得します。このモニタ取得待ちの間に保護区の判定を行った場合は，非保護区と判定されますが，実際にキャンセルが実行されるのはスレッドのモニタを取得した直後となります。

(2)　メソッドキャンセルの処理

メソッドキャンセルは，現在実行中の処理が非保護区の場合だけ実行されます。メソッドキャンセルができるかどうかを確認するため，保護区の判定では，キャンセル対象となるメソッドが非保護区で実行中かどうかを判定します。実行している処理が非保護区の場合は，メソッドキャンセルが行われます。保護区の場合は，一定間隔で保護区の判定をリトライします。判定処理で保護区と判定されるたびに，KDJE52718-Wのメッセージが出力されます。一定時間内に非保護区に制御が移らない場合は，メソッドキャンセルが失敗したと見なされ，メソッドキャンセルの処理が終了します。

保護区の判定処理の流れを次の図に示します。

図5‒2　保護区の判定処理の流れ

なお，メソッドキャンセル時には，次の処理が実施されます。

トランザクションを開始している場合は，トランザクションが強制的にタイムアウトされ，ロールバックにマークされます。

SQLを実行中でステートメントキャンセル機能が有効な場合は，SQLがキャンセルされます。

上記の処理は，保護区を実行中のためにメソッドキャンセルが行われない場合も実施されます。

トランザクションタイムアウトの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.8　トランザクションタイムアウトとステートメントキャンセル」を参照してください。

(3)　WebコンテナおよびEJBコンテナでのメソッドキャンセル時の動作

メソッドキャンセルを実行すると，キャンセル対象となるメソッドを実行中のスレッドで，ThreadDeathが発生します。WebコンテナおよびEJBコンテナでは，このThreadDeathをキャッチして必要な処理を実施します。

WebコンテナおよびEJBコンテナでのメソッドキャンセル時の動作について説明します。

(a)　Webコンテナでの動作

ThreadDeathがスローされるタイミングによって動作が異なります。

Webアプリケーションのフィルタ/サーブレット/JSPでのリクエスト処理中にThreadDeathがスローされた場合

呼び出し元となるフィルタ/サーブレット/JSPにjavax.servlet.ServletExceptionがスローされます。

例えば，フィルタからjavax.servlet.FilterChainのdoFilterメソッド呼び出しの延長でサーブレットが実行され，そのサーブレットの実行中にThreadDeathが発生した場合，doFilterメソッドの呼び出しで，javax.servlet.ServletExceptionがスローされます。

同様に，javax.servlet.RequestDispatcherのforwardメソッド，またはincludeメソッドを呼び出して，リクエストをサーブレット/JSPに転送した場合，javax.servlet.ServletExceptionのgetRootCauseメソッドでは，ThreadDeathオブジェクトを返します。

Webアプリケーションのリスナの処理中にThreadDeathがスローされた場合

WebコンテナはThreadDeathをキャッチしますが，リスナが呼び出される契機となったイベントの発生元となるユーザプログラム処理に対しては，例外はスローされません。

例えば，javax.servlet.http.HttpServletRequestのgetSessionメソッドの呼び出しによってHttpSessionを作成した場合，javax.servlet.http.HttpSessionListenerのsessionCreatedメソッドが呼び出されます。このsessionCreatedメソッドの実行中にThreadDeathがスローされた場合，WebコンテナはスローされたThreadDeathをキャッチしますが，HttpSession生成のイベントを発生させたgetSessionメソッド呼び出しには例外をスローしません。

(b)　EJBコンテナでの動作

EJBのメソッド呼び出し中にThreadDeathがスローされた場合は，EJB仕様で定められたシステム例外が発生した場合と同等の動作をします。呼び出し元に返る例外のgetCauseメソッドでは，ThreadDeathオブジェクトを返します。

(4)　メソッドキャンセル実行のタイミング

メソッドキャンセル実行のタイミング，およびメソッドキャンセル実行までに掛かる最大の時間について説明します。

タイムアウト発生時

メソッドタイムアウト時のメソッドキャンセルのモードとして，スレッドを停止することが設定されている場合，タイムアウト発生時にメソッドキャンセルが実行されます。メッセージを出力するだけの設定の場合は，タイムアウト時でもメソッドキャンセルは実行されません。

タイムアウトが発生したメソッドのキャンセル処理は，一定の間隔で実行されます。また，メソッドキャンセルの処理は，動作中のリクエスト処理がタイムアウトしていないかを調査する（タイムアウトを監視する）スレッドとは別のスレッドで，非同期で実行されます。そのため，タイムアウトの検知後にメソッドキャンセルが実行されるまでには，最大で，メソッドキャンセル処理の時間間隔分掛かります。

メソッドキャンセル処理の時間間隔は，タイムアウトを監視する時間間隔と同じです。メソッドキャンセル処理の時間間隔の設定については，「5.3.9　実行環境での設定」を参照してください。

メソッドキャンセルコマンドの実行時

運用中にメソッドキャンセルコマンドを実行すると，メソッドキャンセルが実行されます。

メソッドキャンセルコマンドは，タイムアウトが発生したメソッドを実行中のスレッドの状態を確認して，メソッドキャンセルが実行できることを確認してから，必要に応じて実行します。

メソッドキャンセルを実行するための手順については，「5.3.10　J2EEアプリケーションの実行時間の監視とキャンセルの流れ」を参照してください。

メソッドキャンセル処理は，コマンド実行後に非同期に実行されます。また，メソッドキャンセル処理は，メソッドキャンセル処理の時間間隔には影響されません。

J2EEアプリケーション強制停止の実行時

J2EEアプリケーションを強制停止した場合に，停止対象となるJ2EEアプリケーションで実行中のスレッドがあるときは，メソッドキャンセルが実施されます。

アプリケーションの強制停止については，「5.5.4　強制停止処理とは」を参照してください。

メソッドキャンセル処理は，コマンド実行後に非同期で実行されます。また，メソッドキャンセル処理は，メソッドキャンセル処理の時間間隔には影響されません。

(5)　メソッドキャンセル時の注意事項

メソッドキャンセル時，デフォルトではローカル変数情報がスタックトレースに出力されます。

性能への影響が出るおそれがあるため，メソッドキャンセル時にローカル変数情報をスタックトレースに出力しないように，JavaVM拡張オプションの「-XX:-HitachiLocalsInStackTrace」の設定を推奨します。

5.3.5　タイムアウト値の設定例と設定値の有効範囲

J2EEアプリケーション実行時間の監視機能を使用するときの，タイムアウト値の設定例と設定値の有効範囲について，Webアプリケーションの場合とEJBの場合に分けて説明します。

(1)　Webアプリケーションの場合

Webアプリケーションの場合のタイムアウト値の設定について説明します。

(a)　フィルタ/サーブレット/JSPへの呼び出し

フィルタ/サーブレット/JSP呼び出しのタイムアウト設定について，次の図に示します。

図5‒3　フィルタ/サーブレット/JSP呼び出しのタイムアウト設定

各場所のタイムアウト値は，呼び出しの順序を考慮して適切に設定する必要があります。例えば，図中Aの範囲のdoFilterメソッドのタイムアウト値は，メソッドの開始から終了までの処理時間の監視に適用されます。このため，BまたはCの処理時間がAのタイムアウト値に設定した時間に達してしまうと，その時点でタイムアウトされてしまいます。例を次に示します。

処理中にタイムアウトが発生する例

図中のA，B，Cのそれぞれのタイムアウト値として次の表に示す時間が設定されていることとします。

表5‒7　タイムアウト値の設定例1

場所

設定したタイムアウト値

図中A（フィルタのdoFilterメソッド）

240秒

図中B（サーブレット）

180秒

図中C（JSP）

120秒

このような設定の場合に，AからBへの処理，およびBからCの処理で次の時間が掛かったとします。

AからBへの処理：120秒

BからCへの処理：60秒

このとき，Cでの処理が60秒以上掛かると，図中Aのタイムアウト値の240秒に達してしまうため，処理が完了する前にタイムアウトが発生します。

設定時の注意事項

アップロード，ダウンロードを実施するサーブレット/JSP内の処理の延長では，クライアントとの通信が発生する場合があります。この場合，アップロード中，ダウンロード中はサーブレット/JSPの処理中として扱われるため，メソッドの実行時間が監視されます。

このため，アップロード，ダウンロードを実施するサーブレット/JSPは，クライアントとの通信遅延などを考慮してタイムアウトを設定する必要があります。特に，ダウンロードについては，ブラウザでダウンロード確認用のダイアログを表示して，クライアントに，ダウンロードの確認を求める場合があります。この場合，ダウンロードするデータ量によっては，クライアント上でユーザがダウンロード確認用のダイアログで操作をするまで，ダウンロードが完了しない（サーブレット/JSPの処理が完了しない）ことがあるので注意してください。

なお，フィルタを経由する場合は，該当するフィルタに関しても同様の注意が必要です。

(b)　サーブレットへの初回リクエスト

サーブレットへの初回アクセス時には，サーブレットのserviceメソッドに設定したタイムアウト値が有効になります。

ただし，DD（web.xml）の<load-on-startup>タグを設定していないサーブレット/JSPの場合，初回リクエスト時には，initメソッドが実行されます。このとき，initメソッドには，該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が有効になります。

また，サーブレット/JSPがserviceメソッドの処理で利用できないことを示す，javax.servlet.UnavailableExceptionをスローした場合に実行されるdestroyメソッドにも，該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が適用されます。

サーブレットへの初回リクエストのタイムアウト設定について，次の図に示します。

図5‒4　サーブレットへの初回リクエストのタイムアウト設定

(c)　フィルタを経由したサーブレット/JSPの初回リクエスト

フィルタを経由したサーブレットおよびJSPの初回リクエストのタイムアウト設定について，次の図に示します。

図5‒5　フィルタを経由したサーブレットの初回リクエストのタイムアウト設定

図5‒6　フィルタを経由したJSPの初回リクエストのタイムアウト設定

フィルタの処理の延長で，サーブレット/JSPが呼び出される場合のフィルタのタイムアウト値は，フィルタの延長で呼び出されるサーブレット/JSPのタイムアウト値を考慮して設定する必要があります。

例えば，図5-6の場合，図中Aの範囲のフィルタのタイムアウト値は，フィルタの処理時間に適用されます。このため，BまたはCの処理時間がAのタイムアウト値に設定した時間に達してしまうと，その時点でタイムアウトされてしまいます。図5-6の場合の例を次に示します。

処理中にタイムアウトが発生する例

図中のA，B，Cのそれぞれのタイムアウト値として次の表に示す時間が設定されていることとします。

表5‒8　タイムアウト値の設定例2

場所

設定したタイムアウト値

図中A（フィルタ）

240秒

図中BおよびC（サーブレット）

180秒

このような設定の場合に，フィルタでの処理，およびサーブレットでの処理で次の時間が掛かったとします。

フィルタでの処理：60秒

サーブレットのinitメソッドで処理：120秒

このとき，サーブレットのserviceメソッドでの処理が60秒以上掛かると，図中Aのタイムアウト値の240秒に達してしまうため，サーブレットのserviceメソッドの処理が完了する前にタイムアウトが発生します。

また，DD（web.xml）の<servlet>タグを定義していて，<load-on-startup>タグを設定していないサーブレット/JSPの場合で，初回リクエストをフィルタのdoFilterメソッドの延長で実行するとき，サーブレット/JSPのinitメソッドが実行されます。initメソッドが実行されるタイミングを次の表に示します。

表5‒9　initメソッドが実行されるタイミング

対象

<servlet>タグの定義

<load-on-startup>タグの定義

initメソッドの実行されるタイミング

サーブレット

あり

なし

doFilterメソッドが呼び出される前

なし

なし

doFilterメソッドの延長

JSP

あり

なし

doFilterメソッドの延長

なし

なし

doFilterメソッドの延長

このとき，initメソッドのタイムアウト値には，次のどちらかの値が適用されます。

フィルタのタイムアウト値≧Webアプリケーションのタイムアウト値の場合

該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が有効になります。

フィルタのタイムアウト値＜Webアプリケーションのタイムアウト値の場合

フィルタに設定したタイムアウト値が有効になります。

(2)　EJBの場合

Stateless Session Beanのビジネスメソッド呼び出しのタイムアウト設定について，次の図に説明します。なお，ほかのBeanの種類（Stateful Session Bean，Entity Bean，Message-driven Bean）についても同様に設定できます。

図5‒7　Stateless Session Beanのビジネスメソッド呼び出しのタイムアウト設定

ビジネスメソッドのタイムアウト値に設定した時間を超えると，タイムアウトが発生します。

なお，EJBのメソッド呼び出しの延長で呼び出されるコールバックは，業務処理の一部であるため，タイムアウト値を設定するときには，コールバックメソッドの実行時間を考慮してください。各メソッドで呼び出されるコールバックについては，「5.3.8(2)　Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法」を参照してください。

5.3.6　使用するスレッド数

J2EEアプリケーション実行時間の監視機能を使用する場合に，生成されるスレッドとスレッド数を次の表に示します。

表5‒10　生成されるスレッドとスレッド数

スレッド

スレッド数

メソッドタイムアウトの監視用スレッド※

1

タイムアウトによるメソッドキャンセル実行用スレッド

4

コマンドによるメソッドキャンセル実行用スレッド

4

現在時刻の取得用スレッド

1

注※　動作中のリクエスト処理がタイムアウトしていないかを調査するためのスレッドです。

なお，コマンドによるメソッドキャンセル実行用スレッドは，メソッドキャンセルコマンド，およびアプリケーション強制停止コマンドを実行した時に生成され，コマンドを終了した時に削除されます。そのほかのスレッドは，J2EEサーバを起動した時に生成され，J2EEサーバが終了するまで動作します。

5.3.7　cosminexus.xmlでの定義

J2EEアプリケーション実行時間の監視機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのJ2EEアプリケーション実行時間の監視機能の定義について次の表に示します。

表5‒11　cosminexus.xmlでのJ2EEアプリケーション実行時間の監視機能の定義

項目

指定するタグ

設定内容

メソッドタイムアウトの時間の設定

EJB単位での設定

<session>，<entity>または<message>タグ下の<ejb-method-observation-timeout>−<method-observation-timeout>タグ

メソッドタイムアウトの時間を指定します。

Webアプリケーション単位での設定

<war>−<servlet>−<method-observation-timeout>タグ，または<war>−<filter>−<method-observation-timeout>タグ

サーブレット内のメソッド共通のメソッドタイムアウトの時間を指定します。

メソッドキャンセルのモードの設定

<cosminexus-app>−<method-observation-recovery-mode>タグ

メソッドキャンセルのモードを指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

5.3.8　実装時の注意事項

ここでは，メソッドタイムアウト機能，およびメソッドキャンセル機能を実装する場合の設定や注意事項について説明します。

(1)　Webアプリケーションのリクエスト処理でのタイムアウト値の設定方法

Webアプリケーションのリクエスト処理では，次の表に示すメソッドにタイムアウト値を設定できます。各メソッドのタイムアウト値の有効範囲については，「5.3.5　タイムアウト値の設定例と設定値の有効範囲」を参照してください。

なお，タイムアウトを利用するサーブレットおよびJSPは，DD（web.xml）の<servlet>タグで定義します。

表5‒12　メソッドタイムアウトの適用対象（Webアプリケーションのリクエスト処理）

ケース

メソッド

条件

サーブレット，JSP

service

条件はありません。

init

DD（web.xml）に<load-on-startup>タグを定義していないサーブレット（JSP利用時は，JSP）に対して，初回リクエストで実行される場合だけ，メソッドタイムアウトの適用対象となります。

destroy

serviceメソッドを呼び出した時に，永久に利用できないことを示すjavax.servlet.UnavailableException例外をスローしたことで実行される場合だけ，メソッドタイムアウトの適用対象となります。

フィルタ

doFilter

条件はありません。

javax.servlet.http.HttpServletクラスのサブクラスとしてサーブレットを実装し，javax.servlet.http.HttpServletクラスのserviceメソッドから呼び出されるdoXXXメソッド（doGetメソッド,doPostメソッドなど）をオーバーライドする場合，オーバーライドしたdoXXXメソッドがタイムアウトの適用対象となります。

JSPのserviceメソッドとは，JSPから生成されたjavax.servlet.jsp.JspPageインタフェースを実装したクラスのserviceメソッドを指します。

JSP内に定義する_jspServiceメソッドは，JspPageインタフェースの実装クラスから，JspPageのserviceメソッドの延長で実行されます。JSPでJspPageを指定しない場合，Webコンテナが提供するJspPageインタフェースの実装クラスが使用されます。

(2)　Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法

Enterprise Beanのメソッド呼び出し処理では，メソッド単位にタイムアウト値を設定できます。Enterprise Bean単位にタイムアウト値を設定できません。

J2EEアプリケーションのメソッドを呼び出す側でのメソッドタイムアウト適用対象メソッドを表5-13に，J2EEアプリケーションに実装されるコールバックメソッド側でのメソッドタイムアウトの適用対象メソッドを表5-14にそれぞれ示します。

CMP2.0のfindメソッド／selectメソッド，およびCMP1.0のfindメソッドのように，Javaプログラムに実装されていないメソッドは，メソッドタイムアウトの適用対象外となります。また，メソッドが呼び出しされたときの状態によって，呼び出されるかどうかが決定するコールバックメソッド（ejbActivate，ejbLoadなど）についても，適用対象外となります。

表5‒13　メソッドタイムアウトの適用対象（Enterprise Bean呼び出し側）

インタフェース

メソッド

Stateless

Session

Bean

Stateful

Session

Bean

Singleton

Session

Bean

Entity

Bean

(BMP)

Entity

Bean

(CMP2.0)

Entity

Bean

(CMP1.1)

Message

-driven

Bean

ホームインタフェース

create

×

○

−

○

○

○

×

finder

−

−

−

○

×

×

−

select

−

−

−

−

×

−

−

home

−

−

−

○

○

−

−

コンポーネントインタフェース

remove

×

○

−

○

○

○

×

ビジネスメソッド

○

○

−

○

○

○

−

ビジネスインタフェース

ビジネスメソッド

○

○

△

−

−

−

−

ビジネスメソッド（非同期）

△

×

△

−

−

−

−

javax.jms.MessageListener

onMessage

−

−

−

−

−

−

○

任意のメッセージリスナインタフェース（EJB 2.1以降）

任意のメッセージリスナメソッド

−

−

−

−

−

−

○

（凡例）

○：適用されます。

×：適用されません。

△：メソッドタイムアウトは適用されますが，メソッドキャンセルは適用されません。

−：該当しません。

表5‒14　メソッドタイムアウトの適用対象（コールバックメソッド側）

メソッド

Stateless

Session

Bean

Stateful

Session

Bean

Singleton

Session

Bean

Entity

Bean

(BMP)

Entity

Bean

(CMP2.0)

Entity

Bean

(CMP1.1)

Message

-driven

Bean

コンストラクタ

×

×

×

×

×

×

×

setSessionContext／setEntityContext／setMessageDrivenContext

×

×

×

×

×

×

×

unsetSessionContext／unsetEntityContext

×

×

×

×

×

×

−

ejbCreate<Method>

×

○

−

○

○

○

×

ejbPostCreate<Method>

−

−

−

×

×

×

−

ejbRemove※

×

○

−

○

○

○

×

ejbActivate

×

×

−

×

×

×

−

ejbPassivate

×

×

−

×

×

×

−

ejbLoad

−

−

−

×

×

×

−

ejbStore

−

−

−

×

×

×

−

ejbfind<Method>

−

−

−

○

−

−

−

ejbSelect<Method>

−

−

−

−

−

−

−

@PostConstruct

×

○

△

−

−

−

−

@PreDestroy

×

○

△

−

−

−

−

homeメソッド

−

−

−

○

○

−

−

ビジネスメソッド

○

○

△

○

○

○

−

onMessage

−

−

−

−

−

−

○

任意のメッセージリスナメソッド（EJB 2.1以降）

−

−

−

−

−

−

○

（凡例）

○：適用されます。

×：適用されません。

△：メソッドタイムアウトは適用されますが，メソッドキャンセルは適用されません。

−：該当しません。

注※

タイムアウト機能などのコンテナの処理で呼び出された場合は対象外です。

(3)　メソッドタイムアウト発生時のオプションメッセージの設定

メソッドタイムアウトが発生した場合，オプションを設定しておくことによって，タイムアウトを通知するメッセージの詳細部分に任意の文字列を追加することができます。実装例を次に示します。

    // ユーザの処理
....
    // メッセージの追加
RequestMonitorMessage.setMessage("メッセージを追加します。");
....
// ユーザの処理

次のような監視対象ではないアプリケーションでは，このメソッドは使用できません。

EJBクライアントアプリケーション

J2EEアプリケーションが生成，起動したスレッドで動作するアプリケーション

(4)　メソッドキャンセルを利用するアプリケーション開発時の注意事項

メソッドキャンセルを使用する場合，アプリケーションを開発するときに，アプリケーションのデータ構造について注意する必要があります。

メソッドキャンセルを実行すると，スレッドの実行が予期しない場所で中断されます。そのため，メソッドキャンセルの対象スレッドとほかのスレッドで，更新または削除を実行する共有データがある場合，メソッドキャンセルを使用しないでください。共有データが破壊され，ほかのリクエストの処理に影響を及ぼすことがあります。

例えば，あるEnterprise Beanに共有の領域（変数A=1，B=2）を設けて，複数スレッド（スレッド1とスレッド2）でアクセスした場合に，スレッド1が共有の領域を更新中（A=10，B=20）にThreadDeath例外が発生すると，更新が中途半端のまま（A=10，B=2）スレッド1が終了します。このとき，スレッド1が更新途中のデータをスレッド2で参照して，A*Bを計算すると，演算結果が不正になります（正：200，誤：20）。そのため，このような例では，メソッドキャンセルは使用できません。

また，ローカル呼び出し最適化機能を使用している場合は，アプリケーション内で，またはアプリケーションをわたって，複数スレッドで更新や削除を実行するようなデータ構造がないか確認する必要もあります。

5.3.9　実行環境での設定

J2EEアプリケーション実行時間の監視機能を使用する場合，J2EEサーバおよびJ2EEアプリケーションの設定が必要です。

なお，J2EEアプリケーションの設定については，cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。J2EEアプリケーション実行時間の監視機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.ext.method_observation.intervalパラメタで，J2EEアプリケーション実行時間の監視機能を使用するかどうかを指定します。0を指定すると，J2EEアプリケーションの実行時間の監視機能が無効になります。1以上の有効値を指定すると，J2EEアプリケーションの実行時間の監視機能が有効になり，その値が次の二つの時間間隔として使用されます。

動作中のリクエスト処理がタイムアウトしていないかを調査する時間間隔

タイムアウトしたリクエスト（メソッド）をキャンセルする時間間隔

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。J2EEアプリケーション実行時間の監視機能の定義では，次の属性ファイルを使用します。

メソッドタイムアウトの時間の設定

EJB単位での設定

SessionBean属性ファイル，EntityBean属性ファイル，またはMessageDrivenBean属性ファイル

Webアプリケーション単位での設定

サーブレット属性ファイル，またはフィルタ属性ファイル

メソッドキャンセルモードの設定

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

各属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「5.3.7　cosminexus.xmlでの定義」を参照してください。

5.3.10　J2EEアプリケーションの実行時間の監視とキャンセルの流れ

J2EEアプリケーションの実行時間を監視してタイムアウトが発生したリクエストを自動的にキャンセルするための設定は，サーバ管理コマンドを使用して実行します。また，J2EEアプリケーションの実行時間を監視するかどうか，および監視時間間隔は，J2EEサーバの動作設定のカスタマイズで設定します。J2EEアプリケーション実行時間の監視の設定については，「5.3.9　実行環境での設定」を参照してください。

また，J2EEアプリケーションでメソッドタイムアウトが発生した場合や，メソッドキャンセルに失敗したスレッドが存在する場合は，サーバ管理コマンドを使用して，手動でメソッドキャンセルを実行（再実行）する必要があります。

サーバ管理コマンドによってメソッドキャンセルを実行する手順を次に示します。

手順

タイムアウトが発生したことを示すメッセージ，またはスレッドの状態が不正なことを示すメッセージを受け取ったあとで，次の手順で実行します。

J2EEアプリケーションの実行状態を確認する（5.3.11参照）

サーバ管理コマンドを使用して実行します。

タイムアウトが発生している場合，J2EEアプリケーションで実行しているリクエストをキャンセルする（5.3.12参照）

サーバ管理コマンドを使用して実行します。

なお，J2EEアプリケーションを強制的に停止した場合も，メソッドはキャンセルされます。J2EEアプリケーションの強制停止についての詳細は，「5.5.7　J2EEアプリケーションの停止」を参照してください。

5.3.11　J2EEアプリケーションの実行状態の確認

J2EEアプリケーション内のメソッドでタイムアウトが発生したことを示すメッセージが出力された場合，またはメソッドキャンセルに失敗したことによってスレッドの状態が不正になったことを示すメッセージが出力された場合に，実行中のJ2EEアプリケーションの実行状態を確認します。確認結果によって，メソッドキャンセルを実行できるかどうかを判断します。

実行状態の確認には，サーバ管理コマンド（cjlistthread）を使用します。

なお，このコマンドは，スレッドの状態が遷移した時に取得したスタックトレースを確認する場合にも使用できます。ただし，スレッドの状態が「running」の場合は，スタックトレースは出力されません。また，スレッドの状態が「stopping」の場合は，複数回スタックトレースが出力されるため，遷移した時点のスタックトレースではなく，最新のスタックトレースが出力されます。

また，Webコンテナで設定している最大同時実行数を上回る数のスレッドが一覧に表示される事があります。

実行形式と実行例を次に示します。なお，cjlistthreadコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistthread（スレッド情報の表示）」を参照してください。

実行形式

cjlistthread <J2EEサーバ名>

-detailオプションを指定すると，動作中のスレッド情報の詳細として，スタックトレースも出力できます。

cjlistthread <J2EEサーバ名> -detail

実行例

cjlistthread MyServer -detail

-detailオプションを指定した場合の実行結果の形式を次に示します。

実行結果

Current Time=HH:MM:SS
ThreadID=11111,RootApInfo=RootAP1,Status=timeout,AppName=AP1,StartTime=HH:MM:SS,TimeOut=60
    com.hitachi.XXXX
     at com.hitachi.YYYY
     at user.code.UserClass1
     at com.hitachi.ZZZZ
              .
              .
              .
ThreadID=22222,RootApInfo=RootAP2,Status=stopping,AppName=AP2,StartTime=HH:MM:SS,TimeOut=60
    com.hitachi.xxxx
     at com.hitachi.yyyy
     at user.code.UserClass2
     at com.hitachi.zzzz

実行結果の，「Status=」の後ろに出力されているのが，スレッドの状態です。

スレッドの状態とメソッドキャンセルの実行可否を，次の表に示します。

表5‒15　スレッドの状態とメソッドキャンセルの実行可否

スレッドの状態

意味

メソッドキャンセルの実行可否

running

実行時間が監視されている状態です。正常に動作しています。

実行できます。

timeout

メソッドタイムアウトによって，タイムアウトが検知された状態です。

実行できます。

stopping

メソッドキャンセル処理が実行されている状態です。

実行できません。

stopped

メソッドキャンセル処理の完了待ちの状態です。

実行できません。

failed

メソッドキャンセル処理が失敗した状態です。

実行できます。

ただし，スレッドの状態がメソッドキャンセルを実行できる状態の場合でも，そのメソッドが保護区で実行されている場合は，メソッドはキャンセルできません。保護区については，「5.3.4　メソッドキャンセルとは」を参照してください。

ポイント

このコマンドで出力されるスレッドの情報は，cjlistthreadコマンドを実行した時点でのスナップショットです。このため，刻々と変化します。正確なスレッドの状態を取得するためには，複数回コマンドを実行して確認することをお勧めします。

また，-detailオプションを指定すると，実行結果の出力量が多くなります。-datailオプションを指定する場合は，出力先をファイルにすることをお勧めします。

5.3.12　タイムアウトが発生したリクエストのキャンセル

J2EEアプリケーションでタイムアウトが発生したリクエストをキャンセルします。この処理をメソッドキャンセルといいます。メソッドキャンセルは，「5.3.11　J2EEアプリケーションの実行状態の確認」の内容に従ってcjlistthreadコマンドを実行してスレッドの実行状態を確認した結果，メソッドキャンセルが可能な状態（running，timeoutまたはfailed）だった場合に実行してください。

メソッドキャンセルには，サーバ管理コマンド（cjstopthread）を使用します。一度のコマンド実行で，複数のスレッドのメソッドをキャンセルできます。

実行形式と実行例を次に示します。なお，cjstopthreadコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstopthread（スレッドの削除）」を参照してください。

実行形式

cjstopthread <J2EEサーバ名> -tid <スレッドID> [-tid <スレッドID>…]

実行例

cjstopthread MyServer -tid 11111

-tidオプションのオプション引数の<スレッドID>には，タイムアウトが発生したことを示すメッセージ，またはスレッドの状態が不正なことを示すメッセージに出力されていたスレッドIDを指定してください。

なお，このコマンドを実行したときに，すでにメソッドキャンセルが実行中の場合，またはメソッドキャンセルの対象に指定したスレッドが存在しない場合は，メソッドキャンセルは実行されないで，コマンドは正常終了します。コマンド実行後のスレッドの状態は，cjlistthreadコマンドで確認できます。「5.3.11　J2EEアプリケーションの実行状態の確認」に示した手順で確認してください。

5.3.13　J2EEアプリケーション実行時間監視で出力されるログ情報

ここでは，J2EEアプリケーションの実行時間監視機能で出力されるログ情報について説明します。

(1)　J2EEサーバ起動時に出力されるログ情報

J2EEサーバ起動時には，プロパティの読み込み，JavaVMのバージョンチェック，保護区リストファイルの読み込みが実行されます。

このときに出力されるログ情報を次の図に示します。

図5‒8　J2EEサーバ起動時に出力されるログ情報

(2)　タイムアウトの延長でメソッドキャンセルを実行した場合に出力されるログ情報

タイムアウトが発生して，その処理の延長でメソッドキャンセルが実行された場合に出力されるログ情報を次の図に示します。どのメッセージが出力された場合も，処理は続行されます。なお，メソッドキャンセルモードが有効か無効かによって，スレッドダンプの出力回数が異なります。

メソッドキャンセルモードが有効の場合

タイムアウト発生時と，メソッドキャンセルの成功時または失敗時に，2回出力されます。

メソッドキャンセルモードが無効の場合

タイムアウト発生時に1回だけ出力されます。

また，タイムアウトを検知したメソッドが終了した場合には，KDJE52716-Iが出力されます。これは，メソッドキャンセルの実行が成功したかどうかとは関係ありません。また，実行しないで終了した場合にも出力されます。つまり，一つのメソッドの実行についてKDJE52703-WとKDJE52716-Iは，1対1で出力されます。

図5‒9　タイムアウトの延長でメソッドキャンセルを実行した場合に出力されるログ情報

(3)　コマンドによってメソッドキャンセルを実行した場合に出力されるログ情報

タイムアウトが発生したメソッドを，J2EEアプリケーションの強制停止またはメソッドキャンセルコマンド（cjstopthread）を実行してキャンセルする場合に出力されるログ情報を次の図に示します。どのメッセージが出力された場合も，処理は続行されます。

なお，スレッドダンプはメソッドキャンセルが失敗した場合に1回だけ出力されます。また，メソッドキャンセルコマンドの実行に失敗した場合は，メッセージKDJE52713-Eが出力されます。

図5‒10　コマンドによってメソッドキャンセルを実行した場合に出力されるログ情報

(4)　注意事項

J2EEサーバでのスレッドダンプファイル数の上限チェック後，スレッドダンプ出力要求とJavaVMでのスレッドダンプ出力処理は非同期に実行されるため，タイムラグが発生することがあります。このため，スレッドダンプファイルが上限値を超えて出力されることがあります。

スレッドダンプの出力数の上限値は，「設定したスレッドダンプの上限値+9」になります。

また，JavaVMのスレッドダンプ出力処理では，同時に複数の出力要求があった場合，スレッドダンプを出力できないことがあります。この場合には，スレッドダンプの数が，実際に出力しようとした数よりも少なくなります。

5.4　J2EEアプリケーションのサービスの閉塞

この節では，Webアプリケーションのサービスの閉塞と，CTMのスケジュールキューの閉塞について説明します。

この節の構成を次の表に示します。

表5‒16　この節の構成（J2EEアプリケーションのサービスの閉塞）

分類

タイトル

参照先

解説

Webアプリケーションのサービスの閉塞と閉塞解除とは

5.4.1

運用

システムごとに実行できるサービスの閉塞方法およびJ2EEアプリケーションの停止方法

5.4.2

負荷分散機を利用したサービス閉塞

5.4.3

注　「実装」，「設定」，「注意事項」について，この機能固有の説明はありません。

サービスとは，J2EEアプリケーションで提供される業務を指します。新しいリクエストについてはエラーを返したり，実行中のリクエストについては処理を続行してエラーを返さないようにしたりして，サービスを閉塞できます。

5.4.1　Webアプリケーションのサービスの閉塞と閉塞解除とは

Webアプリケーションのサービスの閉塞とは，WebアプリケーションをフロントとするJ2EEアプリケーションのサービスを閉塞することを指します。Webアプリケーションのサービスの閉塞は，例えば，業務時間外やシステムのメンテナンス時に，サービスを停止するときに実施します。

(1)　サービス閉塞の方法

Webアプリケーションのサービスを閉塞する方法には，次の五つがあります。

負荷分散機でリクエストの振り分け先を変更する方法※1

負荷分散機を停止する方法※2

Webサーバを停止する方法※3

J2EEサーバを停止する方法

アプリケーションを停止する方法

注※1

負荷分散機でリクエストの振り分け先を変更する方法の場合，実行中のリクエストの処理を，エラーを返さないで続行させるため，負荷分散機の次の機能を使用します。

リクエスト振り分け先の変更時に，変更前の負荷分散機とWebサーバ間の接続を，リクエスト処理が完了するまで保持する機能

注※2

負荷分散機を停止する方法の場合，負荷分散機の停止中に，実行中のリクエストの処理を，エラーを返さないで続行させるため，負荷分散機の次の機能を使用します。

負荷分散機の停止時に，負荷分散機とWebサーバ間の接続を，リクエスト処理が完了するまで保持する機能

注※3

Webサーバを停止する方法は，WebサーバにHTTP Serverを使用している場合だけできます。Microsoft IISを使用している場合は，実行中のリクエストにエラーを返すため，使用できません。

(2)　負荷分散機を使用したシステム構成でのサービス閉塞

サービス閉塞の方法には，負荷分散機を使用する場合と使用しない場合で手順が異なります。ここでは，負荷分散機でリクエストの振り分け先を変更することによって，サービスを閉塞する場合を例に，サービスの閉塞について説明します。

負荷分散機を使用してリクエストの振り分け先を変更する場合，サービス閉塞用のWebサーバを配置する必要があります。稼働中のWebアプリケーションの閉塞後は，サービス閉塞用のWebサーバにリクエストを転送するよう，負荷分散機を設定します。

サービス閉塞前とサービス閉塞後のリクエストの振り分けについて，次の図に示します。

図5‒11　サービス閉塞前とサービス閉塞後のリクエストの振り分け

なお，サービス閉塞用のWebサーバでは，Webアプリケーションのサービス閉塞後，リクエストが来たときには，エラーページを返すようにします。

表示させるエラーページはカスタマイズすることもできます。表示されるエラーページについては，「5.4.1(3)　エラーページの表示」を参照してください。

(3)　エラーページの表示

閉塞したWebアプリケーションのサービスにアクセスした場合，クライアントにはエラーページが表示されます。表示されるエラーページは，次のどれかとなります。

Webサーバのデフォルトのエラーページ，またはユーザが作成したエラーページ

接続エラーのページ※

エラーステータスコードの表示されたエラーページ

注※

接続先のHTTPポートが閉じられている場合に表示されます。

(a)　サービス閉塞の方法と表示されるエラーページ

表示されるエラーページは，Webアプリケーションのサービス閉塞の方法によって異なります。サービス閉塞の方法と，表示されるエラーページを次の表に示します。

表5‒17　サービス閉塞の方法と表示されるエラーページ

サービス閉塞の方法

表示されるエラーページ

負荷分散機でリクエストの振り分け先を変更する方法

サービス閉塞用のWebサーバで設定したエラーページ

負荷分散機を停止する方法

接続エラーのページ

Webサーバを停止する方法

接続エラーのページ※1

J2EEサーバを停止する方法

次のエラーステータスコードが表示されたページ

404エラー※2

500エラー※3

503エラー※4

アプリケーションを停止する方法

次のエラーステータスコードが表示されたページ

404エラー※5

503エラー※4

注※1

ただし，負荷分散機を使用している場合は，使用している負荷分散機の仕様に依存します。

注※2

J2EEサーバを停止したときの404エラーは，アプリケーションの停止時に，J2EEサーバにはリクエストが到達していて，Webアプリケーションへの実行待ちキューには到達していないリクエストに対して返されます。

注※3

500エラーは，アプリケーションの停止時に，J2EEサーバに到達していないリクエストに対して返されます。

注※4

503エラーは，アプリケーションの停止時に，Webアプリケーションの実行待ちキューにあるリクエストに対して返されます。

注※5

アプリケーションを停止したときの404エラーは，アプリケーションの停止時に，Webアプリケーションへの実行待ちキューに到達していないリクエストに対して返されます。

(b)　ユーザ作成のエラーページの使用

表示されるエラーページは，ユーザ作成のエラーページにカスタマイズできます。ただし，カスタマイズはサービス閉塞の方法によって，できる場合とできない場合があります。サービス閉塞の方法と，エラーページのカスタマイズについて次の表に示します。

表5‒18　サービス閉塞の方法とエラーページのカスタマイズ

サービス閉塞の方法

エラーページのカスタマイズ

負荷分散機でリクエストの振り分け先を変更する方法

○

負荷分散機を停止する方法

×

Webサーバを停止する方法

×

J2EEサーバを停止する方法

　○※

アプリケーションを停止する方法

　○※

（凡例）　○：できる　　×：できない

注※

エラーページのカスタマイズをするときのWebサーバの設定で，httpsd.confファイルのErrorDocumentディレクティブでフルURL（http://で始まるURLを記述し，他サイトのコンテンツを指定したURL）を指定しているときには，302エラーが返ります。

エラーページのカスタマイズの設定については，マニュアル「HTTP Server」を参照してください。エラーページのカスタマイズは，WebサーバにHTTP Serverを使用している場合だけできます。

(4)　サービス閉塞の解除

Webアプリケーションのサービス閉塞の解除は，サービス閉塞の方法によって異なります。サービス閉塞の方法ごとに，サービス閉塞の解除の方法を示します。

負荷分散機でリクエストの振り分け先を変更する方法の場合

J2EEサーバへリクエストが転送されるように，負荷分散機のリクエスト振り分け先を変更します。

負荷分散機を停止する方法の場合

負荷分散機を起動します。

Webサーバを停止する方法の場合

Webサーバを起動します。

J2EEサーバを停止する方法の場合

J2EEサーバを起動します。

アプリケーションを停止する方法の場合

アプリケーションを開始します。

5.4.2　システムごとに実行できるサービスの閉塞方法およびJ2EEアプリケーションの停止方法

サービス閉塞は，クライアントから見てリクエストの受け口になる要素（フロント）に対して実行します。フロントを閉塞すると，クライアントから新しいリクエストを受け付けることなく，すでに受け付けたJ2EEアプリケーション内のリクエストを継続実行できます。

Webフロントシステムの場合やCTMを使用したバックシステムの場合，J2EEアプリケーションのフロントに，負荷分散機，WebサーバまたはCTMなどがあります。J2EEアプリケーションを直接停止する前にこれのフロントに当たる要素を閉塞すると，確実なサービス閉塞が実行できます。

なお，サービス閉塞後に実行するJ2EEアプリケーションは，運用管理コマンド（mngsvrutil）で停止してください。

Webフロントシステム，バックシステムなどのシステムの種類の意味については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.1.1　システムの目的と構成」を参照してください。

(1)　Webフロントシステムでのサービス閉塞

Webフロントシステムとは，フロントエンドであるWebブラウザから送信されるリクエストを受け付けて，そのリクエストを処理するシステムです。

サービス閉塞の対象は，J2EEアプリケーション内のWebアプリケーションです。

このシステムでは，次の表に示す方法でサービス閉塞を実行できます。J2EEアプリケーションの停止を実行する前にほかの方法でサービス閉塞を実行することで，サービスを確実に閉塞できます。

表5‒19　Webフロントシステムで実行できるサービス閉塞

サービスの閉塞方法

説明

手段

参照先

負荷分散機のリクエストの振り分け先を変更する※

負荷分散機の設定を変えて，J2EEアプリケーションを停止するJ2EEサーバにリクエストを振り分けないようにします。これによって，J2EEサーバはリクエストを受け付けなくなります。

負荷分散機の機能

5.4.3

負荷分散機を停止する※

負荷分散機を停止して，J2EEサーバへのリクエストの転送を停止します。これによって，J2EEサーバはリクエストを受け付けなくなります。

負荷分散機の機能

5.4.3

J2EEアプリケーションを通常停止する

J2EEアプリケーションを通常停止すると，そのJ2EEアプリケーションは新たなリクエストを受け付けなくなります。ただし，実行中の処理が終了するまで，停止は完了しません。

サーバ管理コマンド

5.5.7

注※

負荷分散機を使用したシステムの場合に実行できます。

(2)　バックシステムでのサービス閉塞（CTMを使用しているシステムの場合）

バックシステムとは，Webフロントシステムの背後などで動作する，複数の業務システムに共通な業務サービスを実行するためのシステムです。

CTMを使用しているシステムの場合，CTMのスケジュールキューを対象にしたサービス閉塞を実行できます。

このシステムでは，次の表に示す方法でサービス閉塞を実行できます。J2EEアプリケーションの停止を実行する前に，ほかの方法でサービス閉塞を実行することで，サービスを確実に閉塞できます。

表5‒20　バックシステム（CTMを使用している場合）で実行できるサービス閉塞

サービスの閉塞方法

説明

手段

参照先マニュアル

参照個所

CTMの機能を使用してサービス閉塞を実行する

CTMの機能を使用してスケジュールキューを閉塞して，J2EEサーバへのリクエストの転送を停止します。これによって，J2EEサーバはリクエストを受け付けなくなります。

運用管理コマンド

機能解説 拡張編

3.7.4

J2EEアプリケーションを通常停止する

J2EEアプリケーションを通常停止すると，そのJ2EEアプリケーションは新たなリクエストを受け付けなくなります。ただし，実行中の処理が終了するまで，停止は完了しません。

サーバ管理コマンド

このマニュアル

5.5.7

(3)　バックシステムでのサービス閉塞（CTMを使用していないシステムの場合）

CTMを使用していないバックシステムの場合，サービス閉塞の対象は，J2EEアプリケーション内のフロントのEnterprise Bean（フロントEJB）です。

このシステムでは，次の方法でサービス閉塞を実行できます。

表5‒21　バックシステム（CTMを使用していない場合）で実行できるサービス閉塞

サービスの閉塞方法

説明

手段

参照先

J2EEアプリケーションを通常停止する

J2EEアプリケーションを通常停止すると，そのJ2EEアプリケーションは新たなリクエストを受け付けなくなります。ただし，実行中の処理が終了するまで，停止は完了しません。

サーバ管理コマンド

5.5.7

なお，システム構築時にあらかじめフロントEJBを定義しておく必要があります。

5.4.3　負荷分散機を利用したサービス閉塞

ここでは，負荷分散機を利用したサービス閉塞の実行方法について説明します。負荷分散機を利用したサービス閉塞は，Webフロントシステムの場合に，負荷分散機を利用しているときに実行できます。負荷分散機を利用したサービスの閉塞には，次の二つの方法があります。

通常のサービス閉塞

サービス部分閉塞

ぞれぞれの実行方法について説明します。

ポイント

負荷分散機を利用したサービス閉塞は，Smart Composer機能で負荷分散機を管理していない場合に使用します。Smart Composer機能で負荷分散機を管理している場合のサービス閉塞は，cmx_stop_targetコマンドを使用します。cmx_stop_targetコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

(1)　通常のサービス閉塞

負荷分散機を利用した通常のサービス閉塞は，次のどちらかの方法で実行します。

負荷分散機のリクエストの振り分け先を変更する

通常使用するWebサーバのほかにサービス閉塞用のWebサーバを用意しておいて，サービス閉塞するタイミングでリクエストの振り分け先をサービス閉塞用のWebサーバに切り替える方法です。サービス閉塞用のWebサーバには，エラーページ表示の設定などをしておきます。

負荷分散機を停止する

負荷分散機を停止して，リクエストの受け付けを停止する方法です。すでにWebサーバに送られたリクエストはそのまま実行されます。

なお，サービス閉塞を解除する場合は，リクエストの振り分け先を再度変更するか，または負荷分散機を起動します。

手順については，ご使用の負荷分散機の使用方法に従ってください。

(2)　負荷分散機を利用したサービス部分閉塞

リクエストを受け付けるWebサーバ，およびリクエストを実行するJ2EEサーバを負荷分散機を使用して冗長化している構成の場合，サービス全体を停止させないで，サービスを構成する一部のWebアプリケーションだけを停止できます。この閉塞方法を，サービス部分閉塞といいます。

なお，Webアプリケーションのサービス部分閉塞ができるのは，次のような構成のシステムです。

負荷分散機を使用したシステム

WebサーバとJ2EEサーバが冗長化されていて，WebサーバとJ2EEサーバが1:1または1:Nの構成であること（Nは1以上の整数）

Webアプリケーションのサービス部分閉塞は，負荷分散機によるリクエストの振り分け先を変更して，サービスを閉塞する系にリクエストを振り分けないことで実現できます。実行方法については，負荷分散機の使用方法を確認してください。

ポイント

負荷分散機によってサービス部分閉塞を実行する場合，停止するWebサーバに対して作成されたセッションを使用したリクエストについては，セッションが切断されます。この場合，稼働中のWebサーバに対してセッションを接続し直す必要があります。ただし，セッションフェイルオーバ機能を使用している場合は，セッションの一部の情報を引き継げます。セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

5.5　J2EEアプリケーションの停止

この節では，通常停止と強制停止の概要や，処理の流れについて説明します。

この節の構成を次の表に示します。

表5‒22　この節の構成（J2EEアプリケーションの停止）

分類

タイトル

参照先

解説

J2EEアプリケーションの停止とは

5.5.1

閉塞処理とは

5.5.2

停止処理とは

5.5.3

強制停止処理とは

5.5.4

実装

cosminexus.xmlでの定義

5.5.5

設定

実行環境での設定

5.5.6

運用

J2EEアプリケーションの停止

5.5.7

注　「注意事項」について，この機能固有の説明はありません。

5.5.1　J2EEアプリケーションの停止とは

J2EEアプリケーションの停止とは，J2EEアプリケーションを構成するWebアプリケーションやEnterprise Beanの終了処理を実行して，J2EEアプリケーションをクライアントからのリクエストを受け付けない状態にすることです。この状態を，停止状態といいます。そのあとで，J2EEアプリケーション自体を停止します。

ここでは，J2EEアプリケーション停止の種類，停止のしかたについて説明します。

(1)　J2EEアプリケーション停止の種類

J2EEアプリケーション停止の種類には，次の二つがあります。

通常停止

日常運用の中で，J2EEアプリケーションを停止するときの停止方法です。J2EEアプリケーション内のWebアプリケーションやEnterprise Beanを順番に停止して，サービスを安全に停止させます。なお，J2EEアプリケーション内でリクエストが実行されている場合，リクエストが終了するまでJ2EEアプリケーションは停止しません。ただし，通常停止を実行するときには，タイムアウトを設定できます。タイムアウトを設定しておくと，J2EEアプリケーションが停止していない場合でも，一定時間が経過したらクライアントに制御が戻ります。

通常停止では，まず，サービスを閉塞してリクエストの受け付けを中止してから，J2EEアプリケーションを停止します。サービス閉塞とは，新しいリクエストを受け付けない状態で，すでに受け付けたリクエストを実行することです。

例えば，次のような場合に計画的にJ2EEアプリケーションを停止するときには，まず，サービス閉塞を実行してから，J2EEアプリケーションを停止します。

一日のうち特定の時間内にだけサービスを提供する場合

システムをメンテナンスする場合

強制停止

J2EEアプリケーションで処理中のリクエストが完了するのを待たないで，リクエストを強制的に停止する方法です。強制停止によって，使用されていたリソースは解放されます。

J2EEアプリケーションでトラブルが発生した場合など，クライアントに制御が戻らないときには，強制停止によってサービスが迅速に停止できるようになります。

ポイント

次の場合にはJ2EEアプリケーションの強制停止を実行できません。

ステートメントキャンセルが実行できない場合

データベースを操作している場合に実行中のSQLの処理が戻らなくなったとき，ステートメントキャンセルが実行されます。ステートメントキャンセルは，実行中のSQLの処理を取り消す処理のことです。

ただし，リソースアダプタの設定，システム構成，使用しているトランザクションの種類などによっては，ステートメントキャンセルができない場合があります。ステートメントキャンセルができない場合，SQLを実行中のトランザクションのタイムアウト，およびSQLの処理が戻らないJ2EEアプリケーションの強制停止は実行できません。

ステートメントキャンセルについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.8　トランザクションタイムアウトとステートメントキャンセル」を参照してください。

メソッドキャンセルが実行できない場合

強制停止を実行すると，実行中のスレッドは，メソッドキャンセルによって予期しない場所で中断されます。このため，メソッドキャンセルの対象スレッドとほかのスレッドで更新または削除を実行する共有データがあるJ2EEアプリケーションの場合，メソッドキャンセルを使用できません。

メソッドキャンセルが実行できないJ2EEアプリケーションの構成については，「5.3.4　メソッドキャンセルとは」を参照してください。

CTMを使用する環境で，J2EEアプリケーションのアンデプロイ時のスケジュールキューを非活性にするための設定に，タイムアウト時間として0（ゼロ）を設定した場合

CTMのスケジュールキューを非活性にするための処理のタイムアウト時間として0を設定した場合，リクエストが終了するまでCTMによる閉塞が完了しません。このため，J2EEアプリケーションを停止できなくなります。

詳細は，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「3.7.4　スケジュールキューの閉塞制御」を参照してください。

(2)　停止のしかた

通常停止，および強制停止は，サーバ管理コマンドで実行します。J2EEアプリケーションの停止については，「5.5　J2EEアプリケーションの停止」を参照してください。

(3)　J2EEアプリケーション停止処理の流れ

ここでは，J2EEアプリケーション停止処理の流れについて説明します。通常停止と強制停止の処理の流れを次の図に示します。

図5‒12　J2EEアプリケーション停止処理の流れ

通常停止処理では，閉塞処理と停止処理が実施されます。

閉塞処理，停止処理，および強制停止処理について，次項以降で説明します。

5.5.2　閉塞処理とは

閉塞処理では，閉塞対象のJ2EEアプリケーションを構成する要素のうち，リクエストの受け口となるフロント部分を閉塞し，新規リクエストの受け付けを終了します。

なお，処理中のリクエストは，引き続き処理されます。

(1)　閉塞順序と処理内容

閉塞順序を次に示します。

Webアプリケーションの閉塞処理

CTMのスケジュールキューの閉塞処理※

フロントEJBの閉塞処理

注※

CTM連携なしの場合は，CTMのスケジュールキューの閉塞処理はありません。

それぞれの閉塞処理での処理内容について説明します。

(a)　Webアプリケーションの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

処理中のリクエストは引き続き処理します。

Webアプリケーションの同時実行数制御のキューにあるリクエストのうち，Webコンテナで処理を開始していないリクエストについては，処理しません。すべて503エラーをクライアントに返します。

(b)　CTMのスケジュールキューの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

CTMのスケジュールキューに投入されたリクエストのうち，J2EEサーバに振り分けられていないリクエストについては，処理しません。java.rmi.RemoteExceptionをクライアントに返します。

CTMのスケジュールキューに投入されたリクエストのうち，すでにJ2EEサーバで処理が開始しているリクエストについては，引き続き処理します。

(c)　フロントEJBの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

処理中のリクエストは，引き続き処理します。

(2)　J2EEアプリケーションの構成パターンと閉塞方法

J2EEアプリケーションの構成パターン別の閉塞方法について，J2EEアプリケーションの形態を図に示し，それぞれの閉塞方法を説明します。

図5‒13　J2EEアプリケーションの構成パターン

J2EEアプリケーション1の閉塞方法

J2EEアプリケーション1は，Webアプリケーションを含みます。

この場合，フロントは通常，Webアプリケーションとなります。J2EEアプリケーション1では，Webアプリケーションを閉塞します。

J2EEアプリケーション2の閉塞方法

J2EEアプリケーション2は，EJBをCTM連携で呼び出します。

この場合，クライアントからの呼び出しが必ずCTMになるので，CTMがフロントとなります。J2EEアプリケーション2では，CTMを閉塞します。

J2EEアプリケーション3の閉塞方法

J2EEアプリケーション3は，CTMを使用しないでEJBを呼び出します。

この場合，どのEJBがフロントとなるのかJ2EEアプリケーション構成からは判断できません。フロントとなるEJB（フロントEJB）は，ユーザが指定します。J2EEアプリケーション3では，ユーザが指定したフロントEJBを閉塞します。

J2EEアプリケーション4の閉塞方法

J2EEアプリケーション4は，Webアプリケーションが単独であるJ2EEアプリケーションです。

この場合，Webアプリケーションがフロントとなります。J2EEアプリケーション4では，Webアプリケーションを閉塞します。

J2EEアプリケーション5の閉塞方法

J2EEアプリケーション5は，EJBが単独であるJ2EEアプリケーションです。

この場合，EJBがフロントとなります。フロントとなるEJB（フロントEJB）は，ユーザが指定します。J2EEアプリケーション5では，ユーザが指定したフロントEJBを閉塞します。

なお，フロントEJBの指定については，「5.5.6　実行環境での設定」を参照してください。

(3)　閉塞処理を実行する場合の注意事項

閉塞処理を実行する場合は，次の点に注意する必要があります。

(a)　CTM使用時の注意

CTM使用時に閉塞処理を実行する場合の注意事項を次に示します。

WebアプリケーションまたはEJBが，CTMを使用して同一J2EEアプリケーション内にあるEJBにアクセスする場合

閉塞処理が終了した時点で，処理中のリクエストもクライアントに例外を返します。このような形態の場合，該当するWebアプリケーションまたはEJBを呼び出すクライアントの処理を停止したあとに，J2EEアプリケーションを停止してください。

CTMから呼び出されているEJBに対して，閉塞処理後にCTMを使用しないでリクエストが投入された場合

EJBの閉塞処理が実施されていないため，新規リクエストが受け付けられます。このような形態の場合，該当するEJBを呼び出すクライアントの処理を停止したあとに，J2EEアプリケーションを停止してください。

usrconf.propertiesのejbserver.ctm.DeactivateTimeOutキーに0を指定している場合

usrconf.propertiesでは，ejbserver.ctm.DeactivateTimeOutキーには0を指定しないでください。

0を指定している場合，CTM経由で仕掛り中のリクエストがある状態でアプリケーションを停止しようとすると，リクエストが終了するまで閉塞が完了しません。このため，リクエストが障害などの理由で終了しない場合，強制停止ができなくなります。

(b)　J2EEアプリケーションをわたったWebアプリケーション呼び出しの注意

Webアプリケーションでは，javax.servlet.ServletContextのgetContextを使用して，同じWebコンテナ上のWebアプリケーションに対してアクセスできます。アクセスするWebアプリケーションが，別のJ2EEアプリケーションに配置されている場合，呼び出し元になるフロントのWebアプリケーションを含むJ2EEアプリケーションを最初に停止してください。

5.5.3　停止処理とは

停止処理では，J2EEアプリケーションのストップ処理，アンデプロイ処理の順に実施されます。それぞれの処理について説明します。

(1)　ストップ処理

ストップ処理は，次の順で実施されます。なお，処理完了後は，J2EEアプリケーションは実行できなくなります。

Webアプリケーションのストップ処理

EJBのストップ処理

J2EEアプリケーションのストップ処理

それぞれの処理について説明します。

(a)　Webアプリケーションのストップ処理

Webアプリケーションのストップ処理は，次の順序で実施されます。

サーブレット/JSPの終了処理

サーブレットのdestroy，JSPのjspDestroyが実施されます。

HTTPセッションの破棄

HTTPセッションの属性の削除および無効化が実施されます。

フィルタの終了処理

フィルタのdestroyが実施されます。

サーブレットコンテキストの破棄

サーブレットコンテキストの属性の破棄および無効化が実施されます。

名前空間からWebアプリケーションの実行環境の削除

名前空間から，ejb-ref，ejb-local-ref，resource-ref，env-entityなどが削除されます。

(b)　EJBのストップ処理

EJBのストップ処理は，次の順序で実施されます。

名前空間からEJBの実行環境の削除

名前空間から，ejb-ref，ejb-local-ref，resource-ref，env-entityなどが削除されます。

名前空間からのEJBホームオブジェクトまたはEJBローカルホームオブジェクトの削除

名前空間から，EJBホームオブジェクトまたはEJBローカルホームオブジェクトが削除されます。

プールの削除

Session Bean，およびMessage-driven Beanの場合は，method-readyプールが削除されます。

Entity Beanの場合は，poolプールとreadyプールが削除されます。

(c)　J2EEアプリケーションのストップ処理

J2EEアプリケーションのストップ処理では，名前空間からJ2EEアプリケーションのエントリが削除されます。

(2)　アンデプロイ処理

アンデプロイ処理は，次の順で実施されます。なお，処理完了後は，J2EEアプリケーションはJ2EEサーバから削除されます。

Webアプリケーションのアンデプロイ処理

EJBのアンデプロイ処理

J2EEアプリケーションのアンデプロイ処理

それぞれの処理について説明します。

(a)　Webアプリケーションのアンデプロイ処理

JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを削除します。なお，JSPのコンパイル結果については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.5.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果」を参照してください。

(b)　EJBのアンデプロイ処理

EJBのアンデプロイ処理は，次の順序で実施されます。

リモートアダプタの削除（リモートインタフェースサポート時だけ）

CMR使用時に作成したテーブルの削除

(c)　J2EEアプリケーションのアンデプロイ処理

J2EEアプリケーションのアンデプロイ処理では，ユーザが手動でダウンロードしたファイルを削除します。

5.5.4　強制停止処理とは

強制停止処理では，通常停止のときの閉塞処理や停止処理は実行されません。J2EEアプリケーションで処理中のリクエストがある場合でも，強制的に処理が中止されます。なお，実行中のメソッドについてはメソッドキャンセルが実行されます。

J2EEアプリケーションを強制停止したときのトランザクションの扱い

J2EEアプリケーションの強制停止を実行すると，仕掛かり中のトランザクションは強制的にタイムアウトされます。このため，J2EEアプリケーションを強制停止したあとにトランザクションを開始しようとすると，例外が発生してトランザクションを開始できません。

ただし，インプロセスOTSが複数のJavaVMにわたって動作しているときには，J2EEアプリケーションを強制停止しても，トランザクションは強制的にタイムアウトされません。

また，J2EEアプリケーションの強制停止時に，Statement，CallableStatement，またはPreparedStatementでSQLが実行されている場合，実行は取り消され，制御をJ2EEアプリケーションに戻そうとします。J2EEアプリケーションで使用していたコネクションは破棄され，プールには戻りません。

トランザクションタイムアウトの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.8　トランザクションタイムアウトとステートメントキャンセル」を参照してください。

5.5.5　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

J2EEアプリケーションの強制停止の機能を使用するための定義は，cosminexus.xmlの<session>，<entity>，または<message>タグ下の<front-ejb>タグ内に指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

5.5.6　実行環境での設定

J2EEアプリケーションの運用機能を使用する場合，J2EEサーバおよびJ2EEアプリケーションの設定が必要です。

(1)　J2EEサーバの設定

J2EEアプリケーションの運用機能を使用する場合，J2EEサーバの設定が必要です。J2EEサーバの設定は，簡易構築定義ファイルで実施します。J2EEアプリケーションの運用機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

表5‒23　J2EEアプリケーションの運用機能に必要な定義

項目

指定するパラメタ

設定内容

J2EEアプリケーションの強制停止

ejbserver.deploy.app.stopforcibly.disabled※1

J2EEアプリケーションの強制停止機能を使用するかどうかを指定します。

なお，J2EEアプリケーションのフロント（クライアントから見てリクエストの受け口になる要素）がEnterprise Beanの場合には，サーバ管理コマンドを使用してフロントとなるEnterprise Bean（フロントEJB）を指定する必要があります。サーバ管理コマンドを使用したJ2EEアプリケーションの強制停止の設定については，「5.5.6(2)　J2EEアプリケーションの設定」を参照してください。

J2EEアプリケーション実行時間の監視

ejbserver.ext.method_observation.interval※2

J2EEアプリケーション実行時間の監視機能を使用するかどうか，動作中のリクエスト処理がタイムアウトしていないかを調査する時間間隔，およびタイムアウトしたリクエスト（メソッド）をキャンセルする時間間隔を指定します。

なお，J2EEアプリケーション実行時間の監視機能で使用するメソッドタイムアウトの時間，メソッドキャンセルのモードは，サーバ管理コマンドで指定します。

設定方法については，「5.3.9(2)　J2EEアプリケーションの設定」を参照してください。

注※1　簡易構築定義ファイルの，J2EEサーバのJavaVMのシステムプロパティに設定します。

注※2　簡易構築定義ファイルの，J2EEサーバ用のユーザプロパティに設定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。J2EEアプリケーションの強制停止の定義には，SessionBean属性ファイル，EntityBean属性ファイル，またはMessageDrivenBean属性ファイルを使用します。

各属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「5.5.5　cosminexus.xmlでの定義」を参照してください。

5.5.7　J2EEアプリケーションの停止

ここでは，サーバ管理コマンドを使用してJ2EEアプリケーションを停止する方法について説明します。

サーバ管理コマンドを使用したJ2EEアプリケーションの停止には，次の五つの方法があります。

デフォルトのタイムアウト時間で通常停止を実行する

任意のタイムアウト時間を設定して通常停止を実行する

デフォルトのタイムアウト時間で通常停止を実行して，停止しなかった場合に強制停止を実行する

任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に強制停止を実行する

任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に自動的に強制停止を実行する

これらの方法以外の順序でコマンドを実行した場合，コマンドが異常終了します。例えば，通常停止をしない状態では，強制停止の形式でコマンドを実行できません。

また，1.，2.，または5.の処理は，一つのJ2EEアプリケーションに対してどれか1回だけ実行できます。

ただし，強制停止は，J2EEサーバの動作設定をカスタマイズして，強制停止が有効になるように設定されているシステムだけで実行できます。J2EEサーバの強制停止の設定については，「5.5.6　実行環境での設定」を参照してください。

J2EEアプリケーションの停止処理では，次の処理が実行されます。

J2EEアプリケーションのフロントがWebアプリケーションの場合

新規リクエストを受け付けなくなります。

処理中のリクエストは引き続き処理されます。

Webアプリケーションの同時実行数制御のキューに格納されているリクエストのうち，Webコンテナでの処理が開始されていないものに対して，HTTP503エラーが返却されます。

J2EEアプリケーションのフロントがEnterprise Beanの場合

新規リクエストを受け付けなくなります。

処理中のリクエストは引き続き処理されます。

停止後のアプリケーションに含まれているEnterprise Beanのメソッドの呼び出しはできません。停止後のアプリケーションに含まれているEnterprise Beanのメソッドを呼び出そうとすると，「stop could not lock <文字列>」というメッセージがJ2EEサーバの標準エラー出力に出力されることがありますが，問題ありません。

次に，それぞれのパターンについて，サーバ管理コマンドの実行手順を説明します。

(1)　デフォルトのタイムアウト時間で通常停止を実行する

コマンドの実行手順，実行形式および実行例を次に示します。

J2EEアプリケーションを通常停止します。

cjstopappコマンドを実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstopapp Myserver -name App1

なお，デフォルトのタイムアウト時間でコマンドを実行した場合，停止処理が完了しなくても60秒後にコマンドの制御が戻ります。

コマンドの制御がタイムアウトによって戻った場合は，J2EEアプリケーションの停止状態を確認します。

タイムアウトによってコマンドの制御が戻った場合，J2EEアプリケーションの停止処理は完了していないことがあります。このため，タイムアウトが発生した場合は，J2EEアプリケーションの状態を確認してください。

J2EEアプリケーションの状態は，サーバ管理コマンドのcjlistappコマンドを実行して確認します。

実行形式

cjlistapp <サーバ名称>

実行例

cjlistapp MyServer

J2EEアプリケーションの状態として，次のどれかの状態が出力されます。

表5‒24　J2EEアプリケーションの状態

出力される文字列

状態の意味

running

開始状態

stopped

停止状態

stopFailure

通常停止失敗状態

forceStopFailure

強制停止失敗状態

blockadeFailure

閉塞失敗状態

blockading

閉塞中

blockaded

閉塞状態

stopping

通常停止中

forceStopping

強制停止中

なお，手順の実行後，J2EEサーバの状態を確認してください。次の状態の場合は，J2EEサーバを再起動する必要があります。

閉塞失敗

通常停止失敗

(2)　任意のタイムアウト時間を設定して通常停止を実行する

コマンドの実行手順，実行形式および実行例を次に示します。

J2EEアプリケーションを通常停止します。このとき，コマンドのオプションに，コマンドの制御を戻すためのタイムアウト時間を設定します。

cjstopappコマンドに，-tオプションを指定して実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名> -t <タイムアウト時間>

実行例

cjstopapp MyServer -name App1 -t 120

この実行例を実行した場合，停止処理が完了しなくても120秒後にコマンドの制御が戻ります。

タイムアウトによってコマンドの制御が戻った場合は，J2EEアプリケーションの停止状態を確認します。

コマンドの制御がタイムアウトによって戻った場合，J2EEアプリケーションの停止処理は完了していないことがあります。このため，タイムアウトが発生した場合は，J2EEアプリケーションの状態を確認してください。

J2EEアプリケーションの状態は，cjlistappコマンドを実行して確認します。

実行形式

cjlistapp <J2EEサーバ名>

実行例

cjlistapp MyServer

J2EEアプリケーションの状態として出力される内容については，「5.5.7(1)　デフォルトのタイムアウト時間で通常停止を実行する」の手順2.を参照してください。

なお，手順の実行後，J2EEサーバの状態を確認してください。次の状態の場合は，J2EEサーバを再起動する必要があります。

閉塞失敗

通常停止失敗

(3)　デフォルトのタイムアウト時間で通常停止を実行して，停止しなかった場合に強制停止を実行する

コマンドの実行手順，実行形式および実行例を次に示します。

J2EEアプリケーションを通常停止します。

cjstopappコマンドを実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstopapp MyServer -name App1

なお，デフォルトのタイムアウト時間でコマンドを実行した場合，停止処理が完了しなくても60秒後にコマンドの制御が戻ります。

タイムアウトによってコマンドの制御が戻った場合は，J2EEアプリケーションの停止状態を確認します。

コマンドの制御がタイムアウトによって戻った場合，J2EEアプリケーションの停止処理は完了していないことがあります。このため，タイムアウトが発生した場合は，J2EEアプリケーションの状態を確認してください。

J2EEアプリケーションの状態は，cjlistappコマンドを実行して確認します。

実行形式

cjlistapp <J2EEサーバ名>

実行例

cjlistapp MyServer

J2EEアプリケーションの状態として出力される内容については，「5.5.7(1)　デフォルトのタイムアウト時間で通常停止を実行する」の手順2.を参照してください。

J2EEアプリケーションの強制停止を実行します。

J2EEアプリケーションが通常停止で停止しなかった場合，強制停止を実行します。

cjstopappコマンドに，-cancelオプションを指定して実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名> -cancel

実行例

cjstopapp MyServer -name App1 -cancel

強制停止が成功すると，J2EEアプリケーションで処理中のリクエストが中止されて，先に実行していた通常停止が終了します。

なお，手順の実行後，J2EEサーバの状態を確認してください。次の状態の場合は，J2EEサーバを再起動する必要があります。

強制停止失敗

閉塞失敗

通常停止失敗

(4)　任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に強制停止を実行する

コマンドの実行手順，実行形式および実行例を次に示します。

J2EEアプリケーションを通常停止します。このとき，コマンドのオプションに，コマンドの制御を戻すためのタイムアウト時間を設定します。

cjstopappコマンドに，-tオプションを指定して実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名> -t <タイムアウト時間>

実行例

cjstopapp MyServer -name App1 -t 120

この実行例を実行した場合，停止処理が完了しなくても120秒後にコマンドの制御が戻ります。

タイムアウトによってコマンドの制御が戻った場合は，J2EEアプリケーションの停止状態を確認します。

コマンドの制御がタイムアウトによって戻った場合，J2EEアプリケーションの停止処理は完了していないことがあります。このため，タイムアウトが発生した場合は，J2EEアプリケーションの状態を確認してください。

J2EEアプリケーションの状態は，cjlistappコマンドを実行して，確認します。

実行形式

cjlistapp <J2EEサーバ名>

実行例

cjlistapp MyServer

J2EEアプリケーションの状態として出力される内容については，「5.5.7(1)　デフォルトのタイムアウト時間で通常停止を実行する」の手順2.を参照してください。

J2EEアプリケーションの強制停止を実行します。

J2EEアプリケーションが通常停止で停止しなかった場合，強制停止を実行します。

cjstopappコマンドに，-cancelオプションを指定して実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名> -cancel

実行例

cjstopapp Myserver -name App1 -cancel

強制停止が成功すると，J2EEアプリケーションで処理中のリクエストが中止されて，先に実行していた通常停止が終了します。

なお，手順の実行後，J2EEサーバの状態を確認してください。次の状態の場合は，J2EEサーバを再起動する必要があります。

強制停止失敗

閉塞失敗

通常停止失敗

(5)　任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に自動的に強制停止を実行する

コマンドの実行手順，実行形式および実行例を次に示します。

タイムアウト時間後に強制停止を実行する形式で，J2EEアプリケーションを停止します。

この形式では，J2EEアプリケーションをまず通常停止で停止して，指定したタイムアウト時間内に停止しなかった場合に，強制停止を実行します。

cjstopappコマンドに，-tオプションと-forceオプションを指定して実行します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名> -t <タイムアウト時間> -force

実行例

cjstopapp MyServer -name App1 -t 120 -force

なお，手順の実行後，J2EEサーバの状態を確認してください。次の状態の場合は，J2EEサーバを再起動する必要があります。

強制停止失敗

閉塞失敗

通常停止失敗

5.6　J2EEアプリケーションの入れ替え

この節では，J2EEアプリケーションの入れ替えについて，入れ替えの概要や入れ替え方法について説明します。

この節の構成を次の表に示します。

表5‒25　この節の構成（J2EEアプリケーションの入れ替え）

分類

タイトル

参照先

解説

J2EEアプリケーションの入れ替えとは

5.6.1

Webアプリケーションのサービスの部分閉塞による入れ替え

5.6.2

運用

J2EEアプリケーションの入れ替えと保守

5.6.3

注　「実装」，「設定」，「注意事項」について，この機能固有の説明はありません。

5.6.1　J2EEアプリケーションの入れ替えとは

システムの運用を開始したあとで，J2EEアプリケーションのバージョンアップやメンテナンスを実施するために，J2EEアプリケーションを入れ替えることがあります。

通常，J2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し，新しいJ2EEアプリケーションをインポート，デプロイする必要があります。通常のJ2EEアプリケーションの入れ替えの手順を次の図に示します。

図5‒14　通常のJ2EEアプリケーションの入れ替えの手順

通常のJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションを入れ替える間，サービスを停止する必要がありますが，サービスの部分閉塞を使用すると，サービスを停止することなくJ2EEアプリケーションを入れ替えることができます。また，リデプロイ機能やリロード機能を使用すると，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。

J2EEアプリケーションの入れ替え方法を次の表に示します。

表5‒26　J2EEアプリケーションの入れ替え方法

入れ替え方法

対象のJ2EEアプリケーション

アーカイブ形式

展開ディレクトリ形式

サービスの部分閉塞による入れ替え

○

○

リデプロイ機能による入れ替え

○

−

リロード機能による入れ替え

−

○

（凡例）　○：入れ替えできる　−：入れ替えできない

それぞれの入れ替え方法について説明します。なお，入れ替え方法の詳細については，「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。

また，J2EEアプリケーションを入れ替えるときに，既存のJ2EEアプリケーションの名前を変更することによって，J2EEアプリケーションの世代も管理できます。

24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合には，Webアプリケーションのサービスの部分閉塞やCTMの使用によって，サービスを停止しないでJ2EEアプリケーションを入れ替えることもできます。

(1)　サービスの部分閉塞による入れ替え

部分的なサービスの閉塞です。サービスを停止することなく，システムをメンテナンスしたいときに使用します。24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合などには，サービスの部分閉塞によって，サービスを停止することなく，システムをメンテナンスできるようになります。

サービス部分閉塞の実行方法は，J2EEアプリケーションの形態によって異なります。例えば，Webアプリケーションの場合には，入れ替え対象のJ2EEアプリケーションが動作するJ2EEサーバに対して負荷分散機からのリクエストの振り分けを停止し，J2EEアプリケーションを入れ替えます。入れ替えている間は，ほかのJ2EEサーバでリクエストを処理することで，サービスを停止することなくJ2EEアプリケーションを入れ替えられます。

J2EEアプリケーションがWebアプリケーションの場合に，サービス部分閉塞を使用してJ2EEアプリケーションを入れ替える方法については，「5.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え」を参照してください。

参考

サービス部分閉塞は，CTMを利用して実行することもできます。CTMのスケジュールキューの閉塞を利用してJ2EEアプリケーションを入れ替える方法については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「3.7　リクエストの閉塞制御」を参照してください。

(2)　リデプロイ機能による入れ替え

アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リデプロイ機能を使用した入れ替えができます。リデプロイとは，少ない手順で高速にJ2EEアプリケーションを入れ替えられるデプロイ方法です。ロジックだけを変更したJ2EEアプリケーションを入れ替えたい場合などに利用できます。ただし，リデプロイ機能を実行できる条件に合わない場合は，通常の手順で入れ替える必要があります。リデプロイ機能を実行できる条件については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「18.7　J2EEアプリケーションのリデプロイ」を参照してください。

リデプロイ機能は，アーカイブ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リデプロイ機能による入れ替え手順を次に示します。

図5‒15　リデプロイ機能による入れ替え手順

リデプロイ機能を使用する場合には，通常のアーカイブ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。

参考

リデプロイを実行する前に，JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は，Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし，クラスファイルを生成する機能です。あらかじめ，クラスファイルの生成までを実施しておくので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

リデプロイ機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.7　J2EEアプリケーションのリデプロイ」を参照してください。

(3)　リロード機能による入れ替え

アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。

リロード機能による入れ替えは，展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リロード機能による入れ替え手順を次に示します。

図5‒16　リロード機能による入れ替え手順

リロード機能を使用する場合には，通常の展開ディレクトリ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。

リロード機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8　J2EEアプリケーションの更新検知とリロード」を参照してください。

J2EEアプリケーションの入れ替えと保守については，「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。サーバ管理コマンドの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

5.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え

Webアプリケーションのサービス閉塞では，部分的にサービスを閉塞することもできます。Webアプリケーションのサービスの部分閉塞によって，サービスを停止することなく，J2EEアプリケーションの入れ替えができ，システムをメンテナンスできます。

(1)　サービスの部分閉塞ができるシステム構成

サービスの部分閉塞ができるシステム構成を次に示します。

負荷分散機を使用して，複数のWebサーバにリクエストを振り分けていること

WebサーバとJ2EEサーバは，1:1または1:nの構成になっていること

なお，セッションを使用するアプリケーションの場合，同一セッションのリクエストは同一のJ2EEサーバで処理する必要がありますが，Webアプリケーションのサービスの部分閉塞をすると，リクエストは，閉塞されたWebアプリケーションがあるJ2EEサーバとは別のJ2EEサーバで処理されます。セッション情報を引き継ぐためには，セッションフェイルオーバ機能を使用してください。セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

(2)　サービスの部分閉塞の方法

Webアプリケーションのサービスの部分閉塞をするには，負荷分散機のリクエスト振り分け先を変更して，閉塞したいWebアプリケーションにリクエストが転送されないようにします。

このとき，リクエストにエラーが返されないようにするため，J2EEサーバで実行されるリクエストがないことを確認します。使用しているWebサーバによって，次のことを実施してください。

WebサーバにHTTP Serverを使用している場合

HTTP Serverを停止してください。HTTP Serverを停止すると，J2EEサーバにリクエストは転送されません。

WebサーバにMicrosoft IISを使用している場合

該当するJ2EEサーバで実行中のリクエストがないことを確認してください。J2EEサーバで実行中のリクエスト数を確認するには，Management Serverのmngsvrutilコマンドによって稼働情報を取得してください。詳細は，マニュアル「アプリケーションサーバリファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

なお，負荷分散機には，リクエストの振り分け先を変更したときに，変更前にあった負荷分散機とWebサーバの接続を，リクエスト処理が完了するまで保持する機能が必要です。この機能のない負荷分散機を使用すると，実行中のリクエストにエラーを返すので注意してください。

5.6.3　J2EEアプリケーションの入れ替えと保守

ここでは，J2EEアプリケーションの入れ替えと保守について説明します。

J2EEアプリケーションのバージョンアップやメンテナンスを実施する場合，J2EEアプリケーションを入れ替えることがあります。

また，24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合，CTMを使用したオンライン状態でのJ2EEアプリケーションの入れ替えの方法を使用すると，サービスを停止しないでJ2EEアプリケーションを入れ替えられます。

(1)　J2EEアプリケーションの入れ替え

ここでは，サーバ管理コマンドを使用してJ2EEアプリケーションを入れ替える手順を説明します。J2EEアプリケーションは，停止して，削除してから新しいアプリケーションに入れ替えます。入れ替え後，J2EEアプリケーションを再開始します。

なお，ここでは，cosminexus.xmlを含むアプリケーションを入れ替える手順について説明します。J2EEアプリケーションに必要な情報はすべてcosminexus.xmlで定義されているものとします。

入れ替えは，次の手順で実行します。

入れ替えるJ2EEアプリケーションを停止します。

cjstopappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstopapp MyServer -name App1

J2EEアプリケーションを削除します。

cjdeleteappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjdeleteapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjdeleteapp MyServer -name App1

入れ替え後のJ2EEアプリケーションをインポートします。

サーバ管理コマンドを使用する場合，cjimportappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjimportapp <J2EEサーバ名> -f <EARファイルのパス>

実行例

cjimportapp MyServer -f App1.ear

なお，WARアプリケーションの場合，cjimportwarコマンドを実行します。

J2EEアプリケーションを開始します。

サーバ管理コマンドを使用する場合，cjstartappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjstartapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstartapp MyServer -name App1

参考

必要な情報を定義したcosminexus.xmlを含むアプリケーションの場合，アプリケーションをインポートしたあとの属性ファイルの取得および変更は必要ありません。サーバ管理コマンドによる属性ファイルの取得および変更の手順については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「3.5　属性ファイルによるプロパティの設定」を参照してください。

(2)　リデプロイによるJ2EEアプリケーションの入れ替え

ここでは，リデプロイによるJ2EEアプリケーションの入れ替えについて説明します。

リデプロイとは，アーカイブ形式のJ2EEアプリケーションを入れ替える場合に，少ない手順で高速に入れ替えられるデプロイ方法です。ロジックだけを変更したJ2EEアプリケーションを入れ替えたい場合などに利用できます。リデプロイは，サーバ管理コマンドを使用して実行できます。

リデプロイを実行できる条件を次に示します。

リデプロイを実行できる条件

入れ替えられるのは，実行時情報を含まないJ2EEアプリケーションだけです。実行時情報を含むJ2EEアプリケーション（ZIPファイル）はリデプロイできません。

入れ替え前と入れ替え後のJ2EEアプリケーションの構成が同じである必要があります。J2EEアプリケーションに含まれるEJB-JAR，リソースアダプタおよびWARの数が異なったり，それらのファイル名称が異なったりする場合は，リデプロイはできません。また，J2EEアプリケーションの名称も同じである必要があります。

入れ替え前と入れ替え後のJ2EEアプリケーションに含まれるEJB-JAR内のホームインタフェース（ローカル，リモート），コンポーネントインタフェース（ローカル，リモート），ビジネスインタフェース（ローカル，リモート）のメソッド定義，およびアノテーションの値が同じである必要があります。

ランタイム属性だけを引き継ぐ設定をしている場合に，アプリケーション開発環境で設定済みのDDファイル（application.xml，ejb-jar.xml，ra.xmlおよびweb.xml）の定義内容が同じである必要があります。

また，J2EEアプリケーションを入れ替える時に，入れ替え前のJ2EEアプリケーションを別な名称に変更して退避しておくと，名称によるJ2EEアプリケーションの世代管理が実現できます。ここでは，J2EEアプリケーションの名称変更についてもあわせて説明します。

リデプロイでは，入れ替え前のJ2EEアプリケーションの情報を，入れ替え後のJ2EEアプリケーションに引き継げます。デフォルトの設定の場合，入れ替え後のJ2EEアプリケーションには，入れ替え前のJ2EEアプリケーションのすべての属性が引き継がれます。ランタイム属性※だけを引き継ぎたい場合は，オプションを指定してcjreplaceappコマンドを実行する必要があります。コマンドの詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreplaceapp（アプリケーションの入れ替え）」を参照してください。

注※

属性ファイルには，DD(application.xml，ejb-jar.xml，ra.xml，web.xml)の定義と属性ファイル独自の定義が設定できます。属性ファイル独自の定義のことを，ランタイム属性といいます。

リデプロイを実行するとき，J2EEアプリケーションは開始，停止どちらの状態でもかまいません。開始状態のJ2EEアプリケーションを入れ替えた場合，J2EEアプリケーションは入れ替え後に自動的に開始されます。ただし，プールやキャッシュに格納されていたJ2EEアプリケーション関連のオブジェクトは破棄されます。停止状態のJ2EEアプリケーションを入れ替えた場合は，入れ替え後のJ2EEアプリケーションも停止した状態になります。

ポイント

J2EEアプリケーションが開始されている状態でリデプロイを実行した場合，リデプロイ処理の中でJ2EEアプリケーションは停止され，入れ替え後に再開始されます。このとき，停止処理の実行時間がサーバ管理コマンド（cjreplaceapp）で設定したタイムアウト時間を超過した場合，J2EEアプリケーションの強制停止が実行されます。タイムアウト時間を指定しなかった場合は，デフォルトのタイムアウト時間である60秒を超過すると，強制停止が実行されます。強制停止実行後にさらにタイムアウト時間を超過した場合は，コマンドが異常終了します。

また，入れ替え後にJ2EEアプリケーションを再開始するとき，開始処理の実行時間がサーバ管理コマンド用のusrconf.propertiesのejbserver.rmi.request.timeoutキーに指定したタイムアウト時間を超過した場合も，コマンドが異常終了します。

入れ替え作業の実行形式と実行例を次に示します。

実行形式

cjreplaceapp <J2EEサーバ名> -name <J2EEアプリケーション名> -f <入れ替えるアプリケーションのファイルパス>

実行例

cjreplaceapp MyServer -name App1 -f App1.ear

注意事項

cosminexus.xmlを含むアプリケーションをリデプロイする場合，cosminexus.xmlに定義したアプリケーションサーバ独自の情報は入れ替え後のcosminexus.xmlに定義した情報に上書きされます。そのほかのJ2EEアプリケーションを構成する要素（EJB-JARファイル，リソースアダプタなど）やDDなどの定義情報は，入れ替え前の情報を引き継ぎます。

WARアプリケーションをリデプロイで入れ替える場合，cosminexus.xmlファイルの再読み込みはできません。WARアプリケーションのアプリケーション属性を変更する場合は，サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使用してください。

(3)　リロードによるJ2EEアプリケーションの入れ替え

ここでは，リロードによるJ2EEアプリケーションの入れ替え方法について説明します。

なお，cosminexus.xmlを含むアプリケーションをリロードした場合，cosminexus.xmlに定義されたアプリケーションサーバ独自の情報はリロードされません。cosminexus.xmlを含むアプリケーションの形式が展開ディレクトリ形式の場合の入れ替えについては，「5.6.3(1)　J2EEアプリケーションの入れ替え」の手順を参照してください。

リロードとは，少ない手順で展開ディレクトリ形式のJ2EEアプリケーションの入れ替えを実行できる機能です。リロードによるJ2EEアプリケーションの入れ替えでは，既存のJ2EEアプリケーションの停止，削除，入れ替え後のJ2EEアプリケーションのアーカイブ，インポート，再開などの作業が不要です。クラスファイルを更新してリロードを実行するだけでJ2EEアプリケーションを更新できるため，メンテナンスが頻繁に発生するシステムの運用などで特に有効な機能です。

なお，リロードによるJ2EEアプリケーションの入れ替えを実行するには，事前に設定が必要です。設定方法の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8.12　J2EEアプリケーションの更新検知とリロードの設定」を参照してください。

リロードによるJ2EEアプリケーションの入れ替えは，サーバ管理コマンド（cjreloadappコマンド）を使用して実行できます。cjreloadappコマンドの詳細についてはマニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreloadapp（アプリケーションのリロード）」を参照してください。

リロードは，次の手順で実行します。

メンテナンスの内容に従ってJavaソースファイルを編集，または作成して，クラスファイルにコンパイルします。

J2EEアプリケーションのリロードを実行します。

cjreloadappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjreloadapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjreloadapp MyServer -name App1

注意事項

リロードに失敗したアプリケーションを削除するには，リロードの成功後，アプリケーションを停止，削除するか，J2EEサーバを再起動したあとにアプリケーションを削除してください。

(4)　入れ替えるJ2EEアプリケーション内のJSPの事前コンパイル

J2EEアプリケーションのメンテナンスでJSPを編集した場合，通常，入れ替え後のJ2EEアプリケーションに最初のリクエストがあったときに，JSPのコンパイルが実行されます。 JSP事前コンパイル機能を使用すると，デプロイ前のJ2EEアプリケーションに対してJSPのコンパイルを実行しておけるため，最初のリクエストに対するレスポンスの時間を短縮することができます。

JSP事前コンパイル機能を実行するには，サーバ管理コマンド，または cjjspcコマンドを使用します。ここでは，JSP事前コンパイル機能の実行タイミングと実行方法について説明します。

システム運用時にJSP事前コンパイル機能を実行するタイミングを次に示します。

J2EEアプリケーション開始時（サーバ管理コマンド）

リロードによるJ2EEアプリケーションの入れ替え時（cjjspcコマンド）

リデプロイによるJ2EEアプリケーションの入れ替え時（cjjspcコマンド）

それぞれのタイミングでの，JSP事前コンパイル機能の実行方法について説明します。

(a)　J2EEアプリケーションを開始するときのJSPの事前コンパイル

J2EEアプリケーションを開始するときにJSP事前コンパイル機能を実行します。この場合，cjstartappコマンドを，-jspcオプションを指定して実行します。

実行形式と実行例を次に示します。

実行形式

cjstartapp ＜サーバ名称＞ -name ＜J2EEアプリケーション名＞ -jspc

実行例

cjstartapp MyServer -name account -jspc

cjstartappコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstartapp（J2EEアプリケーションの開始）」を参照してください。

(b)　リロードによってJ2EEアプリケーションを入れ替えるときのJSPの事前コンパイル

リロードによってJ2EEアプリケーションを入れ替える場合，cjreloadappコマンドを実行する前にJSP事前コンパイル機能を実行します。この場合，cjjspcコマンドを実行します。

実行形式と実行例を次に示します。

実行形式

cjjspc -root <Webアプリケーションのルートディレクトリ>

実行例（Windowsの場合）

cjjspc -root d:¥app¥webapp1

実行例（UNIXの場合）

cjjspc -root /tmp/app/webapp1

cjjspcコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

(c)　リデプロイによってJ2EEアプリケーションを入れ替えるときのJSPの事前コンパイル

リデプロイによってJ2EEアプリケーションを入れ替える場合，cjreplaceappコマンドを実行する前にJSP事前コンパイル機能を実行します。この場合，cjjspcコマンドを実行します。

実行形式と実行例を次に示します。

実行形式

cjjspc -root <Webアプリケーションのルートディレクトリ>

実行例（Windowsの場合）

cjjspc -root d:¥app¥webapp1

実行例（UNIXの場合）

cjjspc -root /tmp/app/webapp1

cjjspcコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

注意事項

リデプロイによって入れ替えるJ2EEアプリケーションに事前コンパイル機能を使用する場合，入れ替えるJ2EEアプリケーションにJSPコンパイル結果が含まれていないとJSP事前コンパイル機能は実行されません。入れ替え後もJSP事前コンパイル機能を使用する場合は，Webアプリケーション単位のJSP事前コンパイルを実行して，入れ替えるJ2EEアプリケーションにJSPコンパイル結果を含めるようにしてください。

タグファイル，静的インクルードされたファイル，またはTLDファイルを更新した場合，更新したファイルを参照するすべてのJSPファイルをコンパイルしてください。

JSP事前コンパイル機能を使用した展開ディレクトリ形式のアプリケーションに，JSPファイル，またはタグファイルを追加した場合，JSP事前コンパイルを再度実施して，JSPファイル，またはタグファイルを参照するすべてのJSPファイルをコンパイルしてください。

展開ディレクトリ形式のアプリケーションのJSPワークディレクトリに含まれるクラスファイルを，開発環境からコピーして更新する場合は，開発環境でJSP事前コンパイルを実施したすべてのクラスファイルをコピーしてください。

cjjspcコマンドを使用してJSPの事前コンパイルを実施した場合，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージがコンソールに出力されます。また，cjstartappコマンドを使用してJSPの事前コンパイルを実施した場合，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージがサーブレットログに出力されます。

(5)　J2EEアプリケーションの名称変更

J2EEアプリケーションを入れ替える時，既存のJ2EEアプリケーションの名称を変更して退避しておくと，J2EEアプリケーションの世代管理ができます。また，入れ替え前のJ2EEアプリケーションに戻したい場合などにもスムーズに対処できます。

J2EEアプリケーションの名称変更は，サーバ管理コマンドで実行します。すでに変更後の名称と同じ名称のJ2EEアプリケーションがある場合，その名称には変更できません。大文字，小文字の違いによる区別はできません。

なお，名称を変更すると，ルックアップ名称の変更も必要になります。J2EEアプリケーションの構成要素に，リモート呼び出しをするホームインタフェースまたはコンポーネントインタフェースを使用したEnterprise Beanが含まれている場合，RMI-IIOPスタブおよびインタフェースを取得し直してください。

RMI-IIOPスタブおよびインタフェースの取得は，サーバ管理コマンド（cjgetstubsjar）を使用して実行します。J2EEアプリケーションを一度も実行していない状態では取得できません。また，次の場合，RMI-IIOPスタブおよびインタフェースの取得はエラーになります。

J2EEアプリケーションにWARしか含まれない場合

Enterprise Beanで使用されているホームインタフェースおよびコンポーネントインタフェースがすべてローカル呼び出しの場合

Enterprise BeanがMessage-driven Beanだけの場合

名称変更は，次の手順で実行します。

名称を変更するJ2EEアプリケーションを停止します。

サーバ管理コマンド（cjstopapp）を実行します。

J2EEアプリケーションの名称を変更します。

サーバ管理コマンド（cjrenameapp）を実行します。

実行形式と実行例を次に示します。

実行形式

cjrenameapp <J2EEサーバ名> -name <変更前のJ2EEアプリケーションの名称> -newname <変更後のJ2EEアプリケーションの名称>

実行例

cjrenameapp MyServer -name App1 -newname App1bak

J2EEアプリケーションを開始します。

サーバ管理コマンド（cjstartapp）を実行します。

J2EEアプリケーションに含まれるEnterprise Bean内のホームインタフェースまたはコンポーネントインタフェースがリモート呼び出しを実行するように定義されている場合，RMI-IIOPスタブおよびインタフェースを取得します。

サーバ管理コマンド（cjgetstubsjar）を実行します。

実行形式と実行例を次に示します。

実行形式

cjgetstubsjar <J2EEサーバ名> -name <変更後のJ2EEアプリケーションの名称> -d <RMI-IIOPスタブおよびインタフェースを格納するディレクトリのパス>

実行例

cjgetstubsjar MyServer -name App1bak -d temp

5.7　J2EEアプリケーションからのネットワークリソースへのアクセス

Windowsの場合で，ネットワークリソースのパスをUNCで指定したり，ネットワークドライブで指定したりしたJ2EEアプリケーションから他ホストにアクセスするには設定が必要になります。この節では，J2EEアプリケーションからのネットワークリソースへのアクセスについて説明します。なお，UNIXの場合，この節で説明する機能を使用しなくても，ネットワークリソースにアクセスできます。

この節の構成を次の表に示します。

表5‒27　この節の構成（J2EEアプリケーションからのネットワークリソースへのアクセス）

分類

タイトル

参照先

解説

ネットワークリソースへのアクセスの概要

5.7.1

設定

ネットワークリソースにアクセスするための設定

5.7.2

注意事項

運用時のトラブルについて

5.7.3

注　「実装」，「運用」について，この機能固有の説明はありません。

5.7.1　ネットワークリソースへのアクセスの概要

ネットワークリソースへのアクセス機能とは，Windowsで動作するJ2EEサーバ上のJ2EEアプリケーションから，他ホストのリソースにアクセスするための機能です。この機能を使用することで，J2EEアプリケーションから他ホストへのリソースのパスをUNCまたはネットワークドライブを指定してアクセスできるようになります。ネットワークリソースへのアクセスの概要を次の図に示します。

図5‒17　ネットワークリソースへのアクセスの概要

この図では，HostAのXドライブにHostBの共有ディレクトリが割り当てられているとします。ネットワークリソースへのアクセス機能を使用することで，HostAのJ2EEアプリケーションから，Xドライブに割り当てられたHostBの共有ディレクトリにアクセスできます。なお，この機能を使用するためには，J2EEアプリケーションが動作するHostA上の運用管理エージェントをAdministratorsグループに所属するアカウントで起動する必要があります。

5.7.2　ネットワークリソースにアクセスするための設定

ネットワークリソースにアクセスするためには，次に示す手順で設定します。なお，ここでは，Windows Server 2019の場合を例に説明します。

「コントロールパネル」から［管理ツール］−［サービス］を開く。

運用管理エージェントのログオンアカウントをAdministratorsグループに所属するアカウントに変更する。

［Cosminexus Management Server - Administration Agent］のログオンアカウントをローカルホストのAdministratorsグループに所属するアカウントに変更します。

adminagentuser.cfgに，J2EEアプリケーションで使用するネットワークドライブを設定する。

<Application Serverのインストールディレクトリ>¥manager¥config¥adminagentuser.cfgに，次の記述を追加してください。この例は，Xドライブに¥¥host¥dirを割り当てる場合です。

add.network.drive=X=¥¥host¥dir

なお，この設定は，ネットワークドライブを使用してネットワークリソースにアクセスする場合だけ実施します。UNCでアクセスする場合は設定不要です。

ポイント

手順3.のネットワークドライブの割り当ての設定について

この設定は，運用管理エージェントを起動する前に実施します。設定したネットワークドライブは，運用管理エージェント起動時に割り当てられます。ただし，運用管理エージェントのログオンアカウントがローカルシステムアカウントの場合は割り当てられません。手順3.で設定する内容について詳細を説明します。

使用するファイル

<Application Serverのインストールディレクトリ>¥manager¥config¥adminagentuser.cfg

設定内容

add.network.driveキーに，ネットワークドライブとして割り当てるドライブの名前と割り当て先のディレクトリパスを指定します。

指定例：X=¥¥host¥dir

なお，この設定をUNIXの環境で設定した場合は，<Managerのログ出力ディレクトリ>/adminagent.errにKEOS21401-Eメッセージが出力され，終了コード1で運用管理エージェントが終了されます。

また，ネットワークドライブの割り当ては複数，指定できます。

add.network.driveキーの設定例と動作について次の表に示します。

表5‒28　add.network.driveキーの設定例と動作内容

指定値

設定例

動作内容

キーなし

(add.network.driveの定義なし)

ネットワークドライブの割り当てをしない。

値なし

add.network.drive=

一つのネットワークドライブを指定

add.network.drive=X=¥¥host¥dir

KEOS21304-Iメッセージを出力して，Xドライブに¥¥host¥dirを割り当てる。

複数のネットワークドライブを指定

add.network.drive=X=¥¥host¥dir

add.network.drive=Y=¥¥host¥dir2

KEOS21304-Iメッセージを出力して，Xドライブに¥¥host¥dirを，Yドライブに¥¥host¥dir2を割り当てる※1。

複数のネットワークドライブを指定（ドライブ名が同じ場合）

add.network.drive=X=¥¥host¥dir

add.network.drive=X=¥¥host¥dir2

KEOS21304-Iメッセージを出力して，Xドライブに¥¥host¥dirを割り当てる※1。

KEOS21305-Wメッセージを出力して，二つ目の¥¥host¥dir2の割り当てには失敗する※2。

注　運用管理エージェントのログオンアカウントがローカルシステムアカウントの場合は，<Managerのログ出力ディレクトリ>¥adminagent.errにKEOS21307-Wメッセージを出力して，ネットワークドライブを割り当てないで処理を続行します。

注※1　指定したネットワークドライブの割り当てに成功した場合は，<Managerのログ出力ディレクトリ>¥adminagent.errにKEOS21304-Iメッセージを出力して，処理を続行します。

注※2　指定したネットワークドライブの割り当てに失敗した場合は，<Managerのログ出力ディレクトリ>¥adminagent.errにKEOS21305-Wメッセージを出力して，処理を続行します。

「コントロールパネル」から，［ユーザアカウント］−［ネットワークパスワードの管理］を開く。

ログオンアカウントがドメインユーザの場合は「パスワードの管理」を開いてください。ここで，ネットワークリソースへアクセスする際にアクセス認証処理を省略するための設定をします。この設定は運用管理エージェントを起動するログオンアカウントのデスクトップ上から実施してください。

［ユーザ名およびパスワードの保存］ダイアログでアクセス先のホスト名，ユーザ名，パスワードを設定する。

ただし，設定するユーザは共有ディレクトリへのアクセスが許可されている必要があります。

ポイント

手順5.のアクセス先ホスト名の指定について

手順5.で設定するアクセス先のホスト名には，IPアドレスではなくホスト名を指定してください。手順5.のネットワークドライブの設定でホスト名に<IPアドレス>を指定している場合で，手順3.で割り当てるホストが<ホスト名>のときは，Windowsの仕様によってアクセス先のホストにログインができないため，割り当てに失敗します。

ホスト名「host」(IP=10.10.10.10)を割り当てる場合を例に，手順3.で指定するホスト名と手順5.で指定するホスト名の組み合わせごとに，割り当てができるかどうかを次の表に示します。

表5‒29　ネットワークの割り当ての可否

手順5.で指定するホスト名

手順3.で指定するホスト名

割り当て

「host」

add.network.drive=X=¥¥host¥dir

○

add.network.drive=X=¥¥10.10.10.10¥dir

○

「10.10.10.10」

add.network.drive=X=¥¥host¥dir

×

add.network.drive=X=¥¥10.10.10.10¥dir

○

（凡例）○：割り当てできる　×：割り当てできない

5.7.3　運用時のトラブルについて

Administratorsグループに所属していないアカウントで運用管理エージェントを起動すると，次のような現象が起こります。

発生するタイミング

Windowsのサービスから［Cosminexus Management Server - Administration Agent］を起動したとき，またはadminagentctl startコマンドを実行したとき

現象

運用管理エージェントの起動に失敗します。また，イベントログに，「KEOS21108-E The administration agent could not be started.(detail = The logon user is not using a local system account, or does not belong to the Administrators group)」が出力されます。

対処方法は，Windowsのサービスから［Cosminexus Management Server - Administration Agent］にログオンするアカウントをローカルシステムアカウントにするか，またはAdministratorsグループに所属するアカウントに変更してください。

5.8　J2EEアプリケーション運用時の注意事項

AIXで，J2EEアプリケーションのデプロイ中に，「exec error: パラメータ・リストまたは環境リストが長すぎます。」（日本語環境以外の場合：「exec error: Arg list too long」）というエラーが発生した場合，java2iiopコマンドの引数の長さが，OSのカーネルパラメタであるARG/ENVリストの設定値を超えています。デフォルトでは，デプロイ対象のアプリケーションが持つ，EnterpriseBeanのホームインタフェースおよびコンポーネントインタフェースの数が，およそ570個以上のとき（パッケージ名を含めたインタフェース名の平均を40文字と仮定）に発生します。このエラーが発生した場合は，次の対処を実施してください。

次のコマンドを実行して，ARG/ENVリストの値を確認します。

lsattr -E -l sys0 -a ncargs

なお，デフォルト値は，6（単位：4キロバイトブロック）です。

次のコマンドを実行して，ARG/ENVリストの値を算出した値以上に変更します。

chdev -l sys0 -a ncargs=<変更後のARG/ENVリストの値>

<変更後のARG/ENVリストの値>は，6〜128の範囲で指定します。次の式で算出した値以上を指定してください。

変更後のARG/ENVリストの値≧（（A＋（B×C））※＋4,095）/4,096

A：約1,600バイト（vbjコマンドに渡すパラメタを除いたコマンドのバイト数）

B：パッケージ名を含めたクラス名の長さの平均（単位：バイト）

C：ホームインタフェースおよびコンポーネントインタフェースの数

注※　「A＋（B×C）」では，実行するコマンドの長さがバイト単位で算出できます。

J2EEアプリケーションを再デプロイします。

6　監査ログ出力機能

この章では，システムの監査を行うための監査ログ出力機能について説明します。

6.1　この章の構成

この章の構成を次の表に示します。

表6‒1　この章の構成（監査ログ出力機能）

分類

機能名

参照先

解説

監査ログ出力機能の概要

6.2

監査ログとは

6.3

監査ログの出力

6.4

監査ログの保存

6.5

監査ログを出力するコマンド・操作一覧

6.6

監査ログの出力ポイント

6.7

実装

アプリケーションの監査ログを出力するための実装

6.8

設定

監査ログ出力の設定

6.9

注　「運用」，「注意事項」について，この機能固有の説明はありません。

6.2　監査ログ出力機能の概要

近年，組織の健全な運営の保障や，複雑化・多様化するITシステムの安全な構築・運用の観点から，組織の内部統制の重要性が高まっています。内部統制の目的は，いつ，だれが，どんな業務を実行したかを把握することで，業務が各種法規制に準拠して遂行されているかを検証することです。そのために，インフラの面では，システムに対して正当な権限を持つ者が正当な操作を行ったことを監査するための仕組みが必要です。

アプリケーションサーバでは，システムの監査を支援する機能として，システムやアプリケーションに対する操作履歴など，監査の観点で必要な情報を記録する次の機能を提供しています。

監査ログ出力機能

データベース監査証跡連携機能

なお，システムの監査を支援する機能は，J2EEアプリケーションの実行環境，およびバッチアプリケーションの実行環境で使用できます。

ここでは，監査ログ出力機能を使用してシステムを監査する作業について説明します。データベース監査証跡連携機能については，「7.　データベース監査証跡連携機能」を参照してください。

監査ログ出力機能は，システムの構築者や運用者がアプリケーションサーバのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴を監査ログとして出力します。また，アプリケーションサーバが提供している監査ログ出力用のAPIを使用して，システムで動作するJ2EEアプリケーションやバッチアプリケーションの監査ログを出力する機能を実装できます。

6.3　監査ログとは

この節では，監査ログを使用したシステムの監査の概要について説明します。

監査ログとは，システム構築者やシステム運用者がアプリケーションサーバのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」「だれが」「何をしたか」を知ることができて，システムの運用が法規制，セキュリティ評価基準，または業界ごとの各種の基準に準拠していることを証明できます。

監査ログには，コマンドなどによる操作を実行したユーザに関する情報や，その操作に伴う処理が成功したか失敗したかなどの監査事象に関する情報，操作や処理の対象に関する情報などが出力されます。これらの情報をシステムの監査に役立てることができます。監査ログに出力される情報の詳細については，「6.4　監査ログの出力」を参照してください。

6.3.1　監査ログが出力される流れと主な出力情報

監査ログが出力される流れと主な出力情報を次の図に示します。

図6‒1　監査ログが出力される流れと主な出力情報

6.3.2　監査事象の定義

監査ログが出力される契機になるのは，コマンドの実行など，アプリケーションサーバのプログラムに対する操作です。この操作は，システム管理者，システム運用者など，その作業に応じたユーザが実行します。また，監査ログは，アプリケーションサーバの各プロセスで監査事象が発生したタイミングで出力されます。監査事象とは，アプリケーションサーバのプログラムに対して実行した操作，およびその操作に伴うプログラムの処理のうち，システムの構築や運用の正当性を証明するために記録する必要がある事象のことです。アプリケーションサーバでは，監査事象を次のとおり分類して定義しています。

表6‒2　監査事象の定義

監査事象

説明

StartStop

ソフトウェアの起動と終了を示す事象です。次の操作が該当します。

各プロセスの起動・停止

J2EEアプリケーションの開始・停止

J2EEリソースの開始・停止

Authentication

システム管理者やシステム運用者が実行した，Management Serverの管理者IDと管理者パスワードによる認証を伴う操作が，成功または失敗したことを示す事象です。

ConfigurationAccess

システム管理者が実行した操作が正常終了または失敗したことを示す事象です。次の操作が該当します。

設定変更

構成変更

構成情報の参照

アプリケーションサーバで定義している監査事象の例を次に示します。

Smart Composer機能のコマンドの実行，およびSmart Composer機能のコマンドの実行に伴う処理

サーバ管理コマンドの実行，およびサーバ管理コマンドの実行に伴う処理

Management Serverを仲介した，管理者IDやパスワードの作成・変更

運用管理エージェントを仲介した，定義ファイルの編集

監査事象は，コマンドごとに定義されています。監査事象となるコマンドの一覧については，「6.6.1　J2EEサーバで使用するコマンド一覧」を参照してください。コマンドごとの監査ログの出力ポイントについては，「6.7　監査ログの出力ポイント」を参照してください。

また，アプリケーションサーバでは，J2EEアプリケーションまたはバッチアプリケーションに使用する監査ログ出力用のAPIを提供します。監査ログ出力用のAPIを使用すると，監査事象のタイミング以外にも，アプリケーションへの操作の実行や，アプリケーションによる処理のタイミングで監査ログを出力することもできます。監査ログ出力用のAPIを使用したJ2EEアプリケーションまたはバッチアプリケーションの実装については，「6.8　アプリケーションの監査ログを出力するための実装」を参照してください。

6.3.3　監査ログ出力機能を使用するシステムで必要な作業と参照先

監査ログを使用したシステムの監査で必要な作業と参照先を次の表に示します。

表6‒3　システムの監査で必要な作業と参照先

作業

参照先マニュアル

参照個所

記載内容

監査を実施するセキュアなシステムの構成を検討する

機能解説 セキュリティ管理機能編

4章

監査ログを使用してセキュアなシステムを構成するための考え方

監査ログを取得するための設定をする

このマニュアル

6.9

監査ログ取得の設定方法

監査ログを収集する

6.4.1

監査ログの出力方式

監査ログの収集方法

監査ログを調査する

6.3

監査ログの調査方法

6.6

監査ログが出力されるコマンド一覧

6.7

監査ログの出力ポイント

アプリケーションサーバ メッセージ(監査者用)

全体

監査ログに出力されるメッセージの見方

アプリケーションに監査ログ出力用のAPIを実装する

このマニュアル

6.8

監査ログ出力用のAPIの実装例

監査ログ出力用のAPIを実装するときの注意事項

リファレンス API編

8章

監査ログ出力用のAPIの詳細

6.4　監査ログの出力

この節では，システムが出力する監査ログの出力先，出力形式，および出力項目の詳細について説明します。

6.4.1　監査ログの出力方式

監査ログは，監査ログを出力したサーバのローカルファイルに，ラップアラウンド方式で出力されます。監査ログが出力されるファイルの面数が切り替わるタイミングで，面数が切り替わったことを通知するメッセージが出力されます。また，障害が発生して，監査ログの出力に失敗すると，監査ログの出力でエラーが発生したことを通知するメッセージが出力されます。

6.4.2　監査ログの出力先

デフォルトの場合の監査ログの出力先を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥auditlog¥audit[n]※.log

UNIXの場合

/opt/Cosminexus/auditlog/audit[n]※.log

注※　[n]の部分には，面の番号が付きます。

デフォルトでは，監査ログの最大ファイルサイズは「32MB」，ファイル面数は「4」に設定されています。最大ファイルサイズ，ファイル面数，および出力先は，監査ログの定義ファイル（auditlog.properties）で変更できます。監査ログの設定については，「6.9　監査ログ出力の設定」を参照してください。

6.4.3　監査ログの出力形式

監査ログは，メッセージとして出力されます。監査ログのメッセージは，次の形式で出力されます。

CALFHM 1.0,出力項目1=値1,出力項目2=値2,出力項目3=値3,・・・出力項目n=値n

先頭の「CALFHM 1.0」は，ヘッダ情報です。監査ログに，共通で出力されます。

システムの監査で使用するメッセージの出力例を次に示します。

出力例

CALFHM 1.0,seqnum=1,msgid=KDJE54400-I,date= 2007-01-22T16:09:59.884+09:00,
progid=Cosminexus,compid=CCC,pid=00EB7859,ocp:host=host01,
ctgry=ConfigurationAccess,result=Occurrence,subj:euid=account01,
obj="Server01",op="Add",to:host=host02,to:port=28080,
msg="account01 executes the request (cjimportapp Server01 -f App1.ear)."

注　実際に出力されるメッセージは，1行で表示されます。この例のように改行されません。

このメッセージは，「2007年1月22日16時9分59.884秒」に，「ホスト01」というホストで，cjimportappコマンドが実行されたことを示しています。また，コマンドを実行したアカウントは「account01」，「Server01」というサーバに対してコマンド実行されたことを示しています。メッセージ内容の詳細については，「6.4.4　監査ログの出力項目」を参照してください。

6.4.4　監査ログの出力項目

監査で使用するメッセージの出力項目には，すべてのメッセージで共通の項目，およびメッセージごとに固有の項目があります。それぞれの項目の意味を次に示します。

すべてのメッセージで共通の項目

すべてのメッセージで同じ意味の可変値が出力されたり，共通の文字列が出力されたりする項目が該当します。

メッセージごとに固有の項目

メッセージごとに固有の意味を持つ可変値が出力されたり，メッセージごとに出力される文字列が決まっていたりする項目が該当します。

監査で使用するメッセージの出力項目の詳細について，次の表に示します。

表6‒4　監査で使用するメッセージの出力項目

出力項目名

出力項目の意味

詳細

共通／固有

seqnum

通番

監査ログの通番が出力されます。

出力される値は，1から9999999999までの整数です。

共通

msgid

メッセージID

メッセージIDが出力されます。

固有

date

日付・時刻

メッセージが出力された日時が，次の形式で出力されます。

YYYY-MM-DDThh:mm:ss.sssTZD

YYYY：西暦年

MM：月

DD：日

T：日付と時間の区切り

hh：時

mm：分

ss：秒

sss：マイクロ秒

TZD：タイムゾーン※1

共通

progid

発生プログラム名

監査事象が発生したプログラムの名称が出力されます。アプリケーションサーバの場合，「Cosminexus」という文字列が出力されます。

共通

compid

発生構成ソフトウェア名

監査事象が発生した構成ソフトウェアの略称が，次の形式で出力されます。

CCC：Component Container

CTM：Component Transaction Monitor

HWS：HTTP Server

MNG：Management Server

PRF：Performance Tracer

UAP_<任意の名称>※2：ユーザがJ2EEアプリケーション，またはバッチアプリケーション実装時に指定した任意の名称

固有

pid

発生プロセスID

監査事象が発生したプロセスのプロセスIDが出力されます。

共通

ocp:host

発生場所

監査事象が発生したホストの名称が出力されます。ただし，発生場所の情報が取得できなかった場合，「(null)」が出力されます。

共通

ctgry

監査事象の種別

監査事象の種別が，次のとおり分類されて出力されます。

StartStop

サーバ，プロセス，サービスなどの起動・終了を示す事象です。

Authentication

ログイン，ログアウトなど，Management Serverへの管理者IDと管理者パスワードによる認証が実行されたことを示す事象です。

ConfigurationAccess

設定および構成の変更，構成情報の参照を示す事象です。

AccessControl※2

管理者またはエンドユーザが管理リソース，およびセキュリティリソースへのアクセスを試みて，成功または失敗したことを示す事象です。

Failure

ソフトウェアの異常を示す事象です。

LinkStatus※2

機器間のリング状態を示す事象です。

ExternalService※2

外部サービスとの通信結果を示す事象です。

ContentAccess※2

ユーザの重要なデータへのアクセスを試みて，成功または失敗したことを示す事象です。

Maintenance※2

保守作業を実行して，操作が正常終了または失敗したことを示す事象です。

AnomalyEvent※2

しきい値のオーバなどの異常が発生したこと，または異常な通信の発生を示す事象です。

ManagementAction※2

プログラムの重要なアクションが実行されたことを示す事象，またはほかの監査事象を契機として実行されるアクションを示す事象です。

固有

result

監査事象の結果

監査事象の結果（成功・失敗・発生）が，次の形式で出力されます。

Success

監査事象の成功を示します。

Failure

監査事象の失敗を示します。

Occurrence

成功および失敗の区別がない事象の発生を示します。

固有

subj:uid

サブジェクト識別情報（アカウント識別子の場合）

監査事象を発生させたものがアカウント情報に割り付けられている場合，アカウント識別子（ユーザIDなど）が出力されます。

固有

subj:euid

サブジェクト識別情報（OSのアカウントの場合）

監査事象を発生させたものがOSが提供するアカウント情報に割り付けられている場合，OSのアカウント※3が出力されます。ただし，サブジェクト識別情報が取得できなかった場合，「(null)」が出力されます。

固有

obj

オブジェクト情報

監査事象となった操作の対象の情報が，「"」で囲まれた形式で出力されます。

固有

op

動作情報

監査事象となった操作の種別が，「"」で囲まれた次の形式で出力されます。

Start

起動を示します。

Stop

停止を示します。

Login

ログインを示します。

Logout

ログアウトを示します。

Logon

ログオンを示します。

Logoff

ログオフを示します。

Refer

設定情報の参照を示します。

Add

設定情報の追加を示します。

Update

設定情報の更新を示します。

Delete

設定情報の削除を示します。

Occur

障害などの発生を示します。

Enforce※2

処理の実施を示します。

Up※2

リンクの活性を示します。

Down※2

リンクの非活性を示します。

Request※2

要求を示します。

Response※2

応答を示します。

Send※2

発信を示します。

Receive※2

受信を示します。

Install※2

インストールを示します。

Uninstall※2

アンインストールを示します。

Backup※2

バックアップを示します。

Maintain※2

保守作業を示します。

Invoke※2

管理者などの呼び出しを示します。

Notify※2

管理者などへの通知を示します。

固有

objloc

オブジェクトロケーション情報

オブジェクトロケーション情報が出力されます。

固有

to:host

リクエスト送信先ホスト

監査事象が複数のプログラム間で連携して動作するリクエストに関連する場合に，リクエストの送信先のホストの情報が出力されます。

固有

to:port

リクエスト送信先ポート番号

監査事象が複数のプログラム間で連携して動作するリクエストに関連する場合に，リクエストの送信先のポート番号が出力されます。

固有

msg

自由記述

監査事象の内容を示す文章が出力されます。

固有

before※2

変更前情報

変更前の情報が出力されます。

固有

after※2

変更後情報

変更後の情報が出力されます。

固有

auth※2

権限情報

監査事象を発生させたときのサブジェクトの権限が出力されます。

固有

sins※2

サービスインスタンス名

サービスの利用者の識別子が出力されます。

固有

haid※2

冗長化識別情報

監査事象の発生場所が冗長化構成の場合，発生場所の系を表す情報が出力されます。

固有

from:host※2

リクエスト送信元ホスト

監査事象が複数のプログラム間で連携して動作するリクエストに関連する場合に，リクエストの送信元の場所情報が出力されます。

固有

from:port※2

リクエスト送信元ポート番号

監査事象が複数のプログラム間で連携して動作するリクエストに関連する場合に，リクエストの送信元のポート番号が出力されます。

固有

outp:host※2（ホスト名で出力する場合）

出力元の場所

出力元が動作している場所情報が出力されます。

固有

subjp:host※2（ホスト名で出力する場合）

指示元の場所

サブジェクトが指示を出した場所情報が出力されます。

固有

dtp:host※2（ホスト名で出力する場合）

検出場所

検出エンティティが動作している場所情報が出力されます。

固有

loc※2

ロケーション情報

ユーザが設定したロケーション識別情報が出力されます。ユーザが設定しなかった場合は，ルートアプリケーション情報が，「"」で囲まれた形式で出力されます。ただし，ルートアプリケーション情報が取得できなかった場合，「null」が「"」で囲まれた形式で出力されます。

固有

（凡例）

共通：すべてのメッセージで共通の項目であることを示します。

固有：メッセージごとに固有の項目であることを示します。メッセージごとに固有の項目の詳細については，マニュアル「アプリケーションサーバ メッセージ(監査者用)」のそれぞれのメッセージの説明を参照してください。

注※1　タイムゾーンは，UTCからの時差で表示されます。表示形式を次に示します。

+hh:mm：UTCからhh時間mm分進んでいる

-hh:mm：UTCからhh時間mm分遅れている

Z：UTCと同じ

（例）日本の場合：+09:00

注※2　監査ログ出力用のAPIを使用して，J2EEアプリケーション，またはバッチアプリケーションから出力するように実装した場合にだけ出力される情報です。

注※3　OSのアカウントには，Windowsの場合はユーザ名が，UNIXの場合は実行ユーザIDが出力されます。

6.5　監査ログの保存

監査ログを使用して監査を実施するシステムでは，監査ログをすべて保存しておくことが求められるため，監査ログの出力に失敗した場合は，システムを停止する必要があります。また，ラップアラウンドによって削除される監査ログを，アーカイブする必要があります。これらの処理は，JP1などの運用管理プログラムを使用して，自動実行することをお勧めします。JP1などの運用管理プログラムを使用して，監査ログの出力に失敗した場合にシステムを自動で停止する例と，監査ログを自動でアーカイブする例について説明します。

6.5.1　監査ログの出力に失敗した場合にシステムを自動で停止する流れ

監査ログの出力に失敗すると，監査ログの出力に失敗したことを通知するメッセージが，メッセージログに出力されます。JP1などの運用管理プログラムを使用すると，監査ログの出力に失敗したことを通知するメッセージログを監視して，システムを自動で停止することができます。

JP1などの運用管理プログラムを使用して，監査ログの出力に失敗した場合にシステムを自動で停止する流れを次に示します。

図6‒2　JP1などの運用管理プログラムを使用して監査ログの出力に失敗した場合にシステムを自動で停止する流れ

障害によってアプリケーションサーバが監査ログの出力に失敗します。

アプリケーションサーバが，監査ログの出力に失敗したことを通知するメッセージログを出力します。

JP1などの運用管理プログラムが，メッセージログが出力されたことを検知します。

JP1などの運用管理プログラムがアプリケーションサーバを停止します。

6.5.2　監査ログを自動でアーカイブする流れ

監査ログの面数が切り替わると，面数が切り替わったことを通知するメッセージが，メッセージログに出力されます。JP1などの運用管理プログラムを使用すると，面数が切り替わったことを通知するメッセージログを監視して，自動でアーカイブすることができます。アーカイブする必要があるファイルを次に示します。

表6‒5　アーカイブする必要があるファイル

アーカイブに含める必要があるファイル

パス

監査ログ

<監査ログの出力ディレクトリ>audit[n].log

監査ログのメッセージログ

<監査ログの出力ディレクトリ>¥rasmessage[n].log

JP1などの運用管理プログラムを使用して，監査ログを自動でアーカイブする流れを次に示します。

図6‒3　JP1などの運用管理プログラムを使用して監査ログを自動でアーカイブする流れ

監査ログを出力するファイルの面数が切り替わります。

ファイルの面数が切り替わったことを通知するメッセージログを，アプリケーションサーバが出力します。

JP1などの運用管理プログラムが，メッセージログが出力されたことを検知します。

JP1などの運用管理プログラムが，古い監査ログファイルを取得します。

6.6　監査ログを出力するコマンド・操作一覧

この節では，監査ログを出力するコマンドおよび操作について説明します。監査ログは，ここで説明するコマンドと操作を実行したタイミング，およびそのコマンドと操作による処理が実行されたタイミングで出力されます。

ここでは，コマンドと操作を次の分類に分けて，それぞれの分類で監査ログを出力するコマンドおよび操作の一覧を示します。

J2EEサーバで使用するコマンド

性能解析トレース・CTMで使用するコマンド

Management Serverで使用するコマンド

EJBクライアントアプリケーションで使用するコマンド

HTTP Serverで使用するコマンド・操作

6.6.1　J2EEサーバで使用するコマンド一覧

J2EEサーバで使用するコマンドのうち，監査ログを出力するコマンドの一覧を次の表に示します。

表6‒6　監査ログを出力するコマンドの一覧（J2EEサーバで使用するコマンド）

コマンド名

監査ログ出力ポイントの参照先※

cjaddapp

6.7.1(3)

cjaddsec

6.7.1(3)

cjchmodapp

6.7.1(3)

cjclearpool

6.7.1(3)

cjclosecn

6.7.1(3)

cjcommittrn

6.7.1(3)

cjcopyres

6.7.1(3)

cjdeleteapp

6.7.1(3)

cjdeletejb

6.7.1(3)

cjdeletelibjar

6.7.1(3)

cjdeleteres

6.7.1(3)

cjdeletesec

6.7.1(3)

cjdeployrar

6.7.1(3)

cjdumpsv

6.7.1(2)

cjenvsetup

6.7.1(2)

cjenvupdate

6.7.1(2)

cjexportapp

6.7.1(3)

cjexportrar

6.7.1(3)

cjforgettrn

6.7.1(3)

cjgencmpsql

6.7.1(3)

cjgetappprop

6.7.1(3)

cjgetjbprop

6.7.1(3)

cjgetrarprop

6.7.1(3)

cjgetresprop

6.7.1(3)

cjgetstubsjar

6.7.1(3)

cjimportapp

6.7.1(3)

cjimportjb

6.7.1(3)

cjimportlibjar

6.7.1(3)

cjimportres

6.7.1(3)

cjimportwar

6.7.1(3)

cjlistapp

6.7.1(3)

cjlistjb

6.7.1(3)

cjlistlibjar

6.7.1(3)

cjlistpool

6.7.1(3)

cjlistrar

6.7.1(3)

cjlistres

6.7.1(3)

cjlistsec

6.7.1(3)

cjlistthread

6.7.1(3)

cjlisttrn

6.7.1(3)

cjlisttrnfile

6.7.1(3)

cjmapsec

6.7.1(3)

cjrarupdate

6.7.1(2)

cjreloadapp

6.7.1(3)

cjrenameapp

6.7.1(3)

cjreplaceapp

6.7.1(3)

cjresetsv

6.7.1(4)

cjresumepool

6.7.1(3)

cjrollbacktrn

6.7.1(3)

cjsetappprop

6.7.1(3)

cjsetjbprop

6.7.1(3)

cjsetrarprop

6.7.1(3)

cjsetresprop

6.7.1(3)

cjsetup

6.7.1(2)

cjstartapp

6.7.1(3)

cjstartjb

6.7.1(3)

cjstartrar

6.7.1(3)

cjstartrecover

6.7.1(2)

cjstartsv

6.7.1(1)

cjstopapp

6.7.1(3)

cjstopjb

6.7.1(3)

cjstoprar

6.7.1(3)

cjstopsv

6.7.1(1)

cjstopthread

6.7.1(3)

cjsuspendpool

6.7.1(3)

cjtestres

6.7.1(3)

cjundeployrar

6.7.1(3)

cjunmapsec

6.7.1(3)

注※　監査ログが出力されるタイミングについての情報の参照先を示します。

6.6.2　バッチサーバで使用するコマンド一覧

バッチサーバで使用するコマンドのうち，監査ログを出力するコマンドの一覧を次の表に示します。

表6‒7　監査ログを出力するコマンドの一覧（バッチサーバで使用するコマンド）

コマンド名

監査ログ出力ポイントの参照先※

cjclearpool

6.7.1(3)

cjcopyres

6.7.1(3)

cjdeleteres

6.7.1(3)

cjdeployrar

6.7.1(3)

cjdumpsv

6.7.1(2)

cjenvsetup

6.7.1(2)

cjenvupdate

6.7.1(2)

cjexecjob

6.7.2

cjexportrar

6.7.1(3)

cjgetrarprop

6.7.1(3)

cjgetresprop

6.7.1(3)

cjimportres

6.7.1(3)

cjkilljob

6.7.2

cjlistjob

6.7.2

cjlistpool

6.7.1(3)

cjlistrar

6.7.1(3)

cjlistres

6.7.1(3)

cjlistthread

6.7.1(3)

cjrarupdate

6.7.1(2)

cjresetsv

6.7.1(4)

cjresumepool

6.7.1(3)

cjsetrarprop

6.7.1(3)

cjsetresprop

6.7.1(3)

cjsetup

6.7.1(2)

cjstartrar

6.7.1(3)

cjstartrecover

6.7.1(2)

cjstartsv

6.7.1(1)

cjstoprar

6.7.1(3)

cjstopsv

6.7.1(1)

cjstopthread

6.7.1(3)

cjsuspendpool

6.7.1(3)

cjtestres

6.7.1(3)

cjundeployrar

6.7.1(3)

注※　監査ログが出力されるタイミングについての情報の参照先を示します。

6.6.3　性能解析トレース・CTMで使用するコマンド一覧

性能解析トレース，およびCTMで使用するコマンドのうち，監査ログを出力するコマンドの一覧を次の表に示します。

表6‒8　監査ログを出力するコマンドの一覧（性能解析トレース・CTMで使用するコマンド）

コマンド名

監査ログ出力ポイントの参照先※

cprfgetpid

6.7.3(3)

cprfstart

6.7.3(1)

cprfstop

6.7.3(1)

ctmdmstart

6.7.3(1)

ctmdmstop

6.7.3(1)

ctmgetpid

6.7.3(3)

ctmstart

6.7.3(1)

ctmstop

6.7.3(1)

ctmstsstart

6.7.3(2)

ctmstsstop

6.7.3(2)

注※　監査ログが出力されるタイミングについての情報の参照先を示します。

6.6.4　Management Serverで使用するコマンド一覧

Management Serverで使用するコマンドうち，監査ログを出力するコマンドの一覧を次の表に示します。

表6‒9　監査ログを出力するコマンドの一覧（Management Serverで使用するコマンド）

コマンド名（サブコマンド）

監査ログ出力ポイントの参照先※1

adminagentctl（start）

6.7.4(3)

adminagentctl（stop）

6.7.4(3)

cmx_admin_passwd

6.7.4(5)

cmx_build_model

6.7.4(5)

cmx_build_system※2

6.7.4(6)

cmx_change_model

6.7.4(5)

cmx_delete_system※2

6.7.4(5)

cmx_export_model

6.7.4(4)

cmx_list_model

6.7.4(4)

cmx_list_status

6.7.4(4)

cmx_resume_lb

6.7.4(5)

cmx_scaleout_host

6.7.4(5)

cmx_start_target※2

6.7.4(5)

cmx_stop_target※2

6.7.4(5)

cmx_test_lb※2

6.7.4(4)

cmx_undefined_application

6.7.4(5)

mngsvrctl（setup）

6.7.4(1)，6.7.4(5)

mngsvrctl（start）※2

6.7.4(2)

mngsvrctl（stop）

6.7.4(2)

HTTP Serverを操作するコマンド

6.7.4(7)

注※1　監査ログが出力されるタイミングについての情報の参照先を示します。

注※2　これらのコマンドを実行すると，内部処理のために複数のコマンドが自動で実行される場合があります。監査ログを調査して監査を実施するには，内部処理のために実行されるそれぞれのコマンドが出力する監査ログも調査してください。内部処理のために複数のコマンドが自動で実行されるコマンドと，実行されるコマンドごとの監査ログの出力の可否を次の表に示します。

表6‒10　内部処理のために複数のコマンドが自動で実行されるコマンドと実行されるコマンドごとの監査ログの出力の可否

実行するコマンド（サブコマンドまたは引数）

内部処理で実行されるコマンド（引数）

監査ログの出力可否

cmx_build_system

mstartupwebsetup

×

mngsvrssh

×

mngsvrsetsid※

×

cjsetup

○

hwsserveredit

○

hwsconfigedit

○

cmx_delete_system

mngsvrssh

×

mngsvrsetsid※

×

cmx_start_target

prfinit

×

mstartupwebinit

×

mstartupwebstart

×

ctdminit

×

mngsvrssh

×

mngsvrsetsid※

×

cprfstart

○

cprfgetpid

○

cjstartsv

○

httpsd

○

osagent

×

nameserv

×

ctmdmstart

○

ctmgetpid

○

ctmstart

○

cmx_stop_target

mstartupwebstop

×

mngsvrssh

×

mngsvrsetsid※

×

cprfstop

○

cjstopsv

○

httpsd

○

ctmdmstop

○

ctmstop

○

ctmstsstop

○

cmx_test_lb

mngsvrssh

×

mngsvrsetsid※

×

mngsvrctl（start）

mngsvrctl（setup）

○

（凡例）　○：出力される。　×：出力されない。

注※　UNIXの場合にだけ，内部処理のために実行されるコマンドです。

6.6.5　EJBクライアントアプリケーションで使用するコマンド一覧

EJBクライアントアプリケーションで使用するコマンドのうち，監査ログを出力するコマンドの一覧を次の表に示します。

表6‒11　監査ログを出力するコマンドの一覧（EJBクライアントアプリケーションで使用するコマンド）

コマンド名

監査ログ出力ポイントの参照先※

cjcldellog

6.7.5

cjcldumpap

6.7.5

cjclstartap

6.7.5

注※　監査ログが出力されるタイミングについての情報の参照先を示します。

6.6.6　HTTP Serverで使用するコマンド・操作一覧（Windowsの場合）

Windowsの場合のHTTP Serverで使用するコマンドおよび操作のうち，監査ログを出力するコマンドおよび操作の一覧を次の表に示します。

表6‒12　監査ログを出力するコマンド・操作の一覧（Windowsの場合のHTTP Serverで使用するコマンド・操作）

コマンド名（オプション），操作

監査ログ出力ポイントの参照先※

httpsd（-k gracefulstop）

6.7.6(1)

httpsd（-k restart）

6.7.6(1)

httpsd（-k start）

6.7.6(1)

httpsd（-k stop）

6.7.6(1)

コントロールパネルによる操作

6.7.6(2)

注※　監査ログが出力されるタイミングについての情報の参照先を示します。

6.6.7　HTTP Serverで使用するコマンド・操作一覧（UNIXの場合）

UNIXの場合のHTTP Serverで使用するコマンドおよび操作のうち，監査ログを出力するコマンドおよび操作の一覧を次の表に示します。

表6‒13　監査ログを出力するコマンド・操作の一覧（UNIXの場合のHTTP Serverで使用するコマンド・操作）

コマンド名，操作

監査ログ出力ポイントの参照先※1

httpsd※2

6.7.7(2)

httpsdctlによる操作

6.7.7(1)

シグナル送信による操作

6.7.7(3)

注※1　監査ログが出力されるタイミングについての情報の参照先を示します。

注※2　コマンドを直接実行した場合です。

6.7　監査ログの出力ポイント

この節では，監査ログを出力するコマンド・操作を実行したとき，およびそのコマンド・操作による処理が実行されたときの，監査ログが出力されるポイントについて説明します。

ここでは，コマンドおよび操作を次の分類に分けて，それぞれのコマンドで監査ログを出力するポイントについて説明します。

J2EEサーバで使用するコマンド

バッチサーバで使用するコマンド

性能解析トレース・CTMで使用するコマンド

Management Serverで使用するコマンド

EJBクライアントアプリケーションで使用するコマンド

HTTP Serverで使用するコマンド

6.7.1　J2EEサーバで使用するコマンドの監査ログの出力ポイント

J2EEサーバで使用するコマンドの監査ログの出力ポイントについて説明します。

(1)　サーバプロセスを起動・停止するコマンド（サーバ管理コマンド以外）

サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンドの監査ログの出力ポイントを次の図に示します。

図6‒4　監査ログの出力ポイント（サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒14　監査ログの出力ポイントとメッセージIDの対応（サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンド）

コマンド（オプション）

図中の番号

出力される監査ログのメッセージID

cjstartsv

1

KDJE54112-I

2

KDJE54113-I

7

KDJE54126-I

KDJE54127-E

8

KDJE54114-I

KDJE54115-E

cjstopsv（-wait）

3

KDJE54116-I

6

KDJE54117-I

KDJE54118-E

9

KDJE54119-W

cjstopsv（-f，または-fd）

3

KDJE54116-I

6

KDJE54117-I

KDJE54118-E

cjstopsv（-wait -f，または-wait -fd）

3

KDJE54116-I

6

KDJE54117-I

KDJE54118-E

9

KDJE54119-W

10

KDJE54117-I

KDJE54118-E

cjstopsv（-wait，-f，-fd，-wait -f，および-wait -fd以外のオプション）

3

KDJE54116-I

6

KDJE54117-I

KDJE54118-E

−※1

4

KDJE54138-I

5

KDJE54139-I

KDJE54140-E

−※2

KDJE54155-E

注※1　この表で示しているすべてのコマンドに共通で出力されるメッセージです。ただし，-f，および-fd以外のオプションを指定してコマンドを実行した場合に限ります。

注※2　この表で示しているコマンドを実行して，メモリ不足が発生した場合に出力されることがあります。

(2)　サーバプロセスを起動・停止するコマンド以外のコマンド（サーバ管理コマンド以外）

サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンドの監査ログの出力ポイントを次の図に示します。

図6‒5　監査ログの出力ポイント（サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒15　監査ログの出力ポイントとメッセージIDの対応（サーバプロセスを起動・停止する，サーバ管理コマンド以外のコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjsetup

1

KDJE54100-I

2

KDJE54101-I

KDJE54102-E

cjenvsetup

1

KDJE54103-I

2

KDJE54104-I

KDJE54105-E

cjenvupdate

1

KDJE54106-I

2

KDJE54107-I

KDJE54108-E

cjrarupdate

1

KDJE54109-I

2

KDJE54110-I

KDJE54111-E

cjstartrecover※1

1

KDJE54120-I

2

KDJE54121-I

KDJE54122-E

cjdumpsv

1

KDJE54123-I

2

KDJE54124-I

KDJE54125-E

−

−※2

KDJE54155-E

注※1　cjstartrecoverコマンドは，内部処理でcjstartsvコマンドを実行します。そのため，cjstartrecoverコマンド実行時にはcjstartsvコマンドの監査ログも出力されます。

注※2　この表で示しているコマンドを実行して，メモリ不足が発生した場合に出力されることがあります。

(3)　サーバ管理コマンド（cjresetsv以外のサーバ管理コマンド）

サーバ管理コマンド（cjresetsv以外のサーバ管理コマンド）の監査ログの出力ポイントを次の図に示します。

図6‒6　監査ログの出力ポイント（cjresetsv以外のサーバ管理コマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒16　監査ログの出力ポイントとメッセージIDの対応（cjresetsv以外のサーバ管理コマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

動作情報

cjaddapp

3

KDJE54424-I

Add

4

KDJE54425-I

KDJE54426-E

5

KDJE54427-E

cjaddsec

3

KDJE54576-I

4

KDJE54577-I

KDJE54578-E

5

KDJE54579-E

cjchmodapp

3

KDJE54608-I

Update

4

KDJE54609-I

KDJE54610-E

5

KDJE54611-E

cjclearpool

3

KDJE54600-I

Delete

4

KDJE54601-I

KDJE54602-E

5

KDJE54603-E

cjclosecn

3

KDJE54604-I

4

KDJE54605-I

KDJE54606-E

5

KDJE54607-E

cjcommittrn

3

KDJE54645-I

Update

4

KDJE54646-I

KDJE54647-E

5

KDJE54648-E

cjcopyres

3

KDJE54476-I

Add

4

KDJE54477-I

KDJE54478-E

5

KDJE54479-E

cjdeleteapp

3

KDJE54428-I

Delete

4

KDJE54429-I

KDJE54430-E

5

KDJE54431-E

cjdeletejb

3

KDJE54440-I

4

KDJE54441-I

KDJE54442-E

5

KDJE54443-E

cjdeletelibjar

3

KDJE54436-I

4

KDJE54437-I

KDJE54438-E

5

KDJE54439-E

cjdeleteres

3

KDJE54432-I

4

KDJE54433-I

KDJE54434-E

5

KDJE54435-E

cjdeletesec

3

KDJE54580-I

4

KDJE54581-I

KDJE54582-E

5

KDJE54583-E

cjdeployrar

3

KDJE54568-I

Update

4

KDJE54569-I

KDJE54570-E

5

KDJE54571-E

cjexportapp

3

KDJE54416-I

Refer

4

KDJE54417-I

KDJE54418-E

5

KDJE54419-E

cjexportrar

3

KDJE54420-I

4

KDJE54421-I

KDJE54422-E

5

KDJE54423-E

cjforgettrn

3

KDJE54653-I

Delete

4

KDJE54654-I

KDJE54655-E

5

KDJE54656-E

cjgencmpsql

3

KDJE54620-I

Update

4

KDJE54621-I

KDJE54622-E

5

KDJE54623-E

cjgetappprop

3

KDJE54444-I

Refer

4

KDJE54445-I

KDJE54446-E

5

KDJE54447-E

cjgetjbprop

3

KDJE54456-I

4

KDJE54457-I

KDJE54458-E

5

KDJE54459-E

cjgetrarprop

3

KDJE54452-I

4

KDJE54453-I

KDJE54454-E

5

KDJE54455-E

cjgetresprop

3

KDJE54448-I

4

KDJE54449-I

KDJE54450-E

5

KDJE54451-E

cjgetstubsjar

3

KDJE54612-I

4

KDJE54613-I

KDJE54614-E

5

KDJE54615-E

cjimportapp

3

KDJE54400-I

Add

4

KDJE54401-I

KDJE54402-E

5

KDJE54403-E

cjimportjb

3

KDJE54412-I

4

KDJE54413-I

KDJE54414-E

5

KDJE54415-E

cjimportlibjar

3

KDJE54408-I

4

KDJE54409-I

KDJE54410-E

5

KDJE54411-E

cjimportres

3

KDJE54404-I

4

KDJE54405-I

KDJE54406-E

5

KDJE54407-E

cjimportwar

3

KDJE54661-I

4

KDJE54662-I

KDJE54663-E

5

KDJE54664-E

cjlistapp

3

KDJE54480-I

Refer

4

KDJE54481-I

KDJE54482-E

5

KDJE54483-E

cjlistjb

3

KDJE54512-I

4

KDJE54513-I

KDJE54514-E

5

KDJE54515-E

cjlistlibjar

3

KDJE54492-I

4

KDJE54493-I

KDJE54494-E

5

KDJE54495-E

cjlistpool

3

KDJE54508-I

4

KDJE54509-I

KDJE54510-E

5

KDJE54511-E

cjlistrar

3

KDJE54488-I

4

KDJE54489-I

KDJE54490-E

5

KDJE54491-E

cjlistres

3

KDJE54484-I

4

KDJE54485-I

KDJE54486-E

5

KDJE54487-E

cjlistsec

3

KDJE54584-I

4

KDJE54585-I

KDJE54586-E

5

KDJE54587-E

cjlistthread

3

KDJE54496-I

4

KDJE54497-I

KDJE54498-E

5

KDJE54499-E

cjlisttrn

3

KDJE54500-I

4

KDJE54501-I

KDJE54502-E

5

KDJE54503-E

cjlisttrnfile

3

KDJE54504-I

4

KDJE54505-I

KDJE54506-E

5

KDJE54507-E

cjmapsec

3

KDJE54588-I

Update

4

KDJE54589-I

KDJE54590-E

5

KDJE54591-E

cjreloadapp

3

KDJE54556-I

4

KDJE54557-I

KDJE54558-E

5

KDJE54559-E

cjrenameapp

3

KDJE54616-I

4

KDJE54617-I

KDJE54618-E

5

KDJE54619-E

cjreplaceapp

3

KDJE54536-I

4

KDJE54537-I

KDJE54538-E

5

KDJE54539-E

cjresumepool

3

KDJE54564-I

Start

4

KDJE54565-I

KDJE54566-E

5

KDJE54567-E

cjrollbacktrn

3

KDJE54649-I

Update

4

KDJE54650-I

KDJE54651-E

5

KDJE54652-E

cjsetappprop

3

KDJE54460-I

4

KDJE54461-I

KDJE54462-E

5

KDJE54463-E

cjsetjbprop

3

KDJE54472-I

4

KDJE54473-I

KDJE54474-E

5

KDJE54475-E

cjsetrarprop

3

KDJE54468-I

4

KDJE54469-I

KDJE54470-E

5

KDJE54471-E

cjsetresprop

3

KDJE54464-I

4

KDJE54465-I

KDJE54466-E

5

KDJE54467-E

cjstartapp

3

KDJE54520-I

Start

4

KDJE54521-I

KDJE54522-E

5

KDJE54523-E

cjstartjb

3

KDJE54548-I

4

KDJE54549-I

KDJE54550-E

5

KDJE54551-E

cjstartrar

3

KDJE54528-I

4

KDJE54529-I

KDJE54530-E

5

KDJE54531-E

cjstopapp

3

KDJE54524-I

Stop

4

KDJE54525-I

KDJE54526-E

5

KDJE54527-E

cjstopjb

3

KDJE54552-I

4

KDJE54553-I

KDJE54554-E

5

KDJE54555-E

cjstoprar

3

KDJE54532-I

4

KDJE54533-I

KDJE54534-E

5

KDJE54535-E

cjstopthread

3

KDJE54544-I

4

KDJE54545-I

KDJE54546-E

5

KDJE54547-E

cjsuspendpool

3

KDJE54560-I

4

KDJE54561-I

KDJE54562-E

5

KDJE54563-E

cjtestres

3

KDJE54516-I

Refer

4

KDJE54517-I

KDJE54518-E

5

KDJE54519-E

cjundeployrar

3

KDJE54572-I

Update

4

KDJE54573-I

KDJE54574-E

5

KDJE54575-E

cjunmapsec

3

KDJE54592-I

4

KDJE54593-I

KDJE54594-E

5

KDJE54595-E

なお，それぞれのコマンドが出力する監査ログの動作情報ごとに，図中の「1」，「2」，「6」および「7」で出力されるメッセージが異なります。動作情報と図中の「1」，「2」，「6」および「7」で出力されるメッセージIDの対応を次の表に示します。

表6‒17　動作情報とメッセージIDの対応（cjresetsv以外のサーバ管理コマンド）

動作情報

図中の番号

メッセージID

Start

1

KDJE54624-I

2

KDJE54141-I

6

KDJE54142-I

7

KDJE54625-I

KDJE54626-E

Stop

1

KDJE54627-I

2

KDJE54143-I

6

KDJE54144-I

7

KDJE54628-I

KDJE54629-E

Refer

1

KDJE54630-I

2

KDJE54145-I

6

KDJE54146-I

7

KDJE54631-I

KDJE54632-E

Add

1

KDJE54633-I

2

KDJE54147-I

6

KDJE54148-I

7

KDJE54634-I

KDJE54635-E

Update

1

KDJE54636-I

2

KDJE54149-I

6

KDJE54150-I

7

KDJE54637-I

KDJE54638-E

Delete

1

KDJE54639-I

2

KDJE54151-I

6

KDJE54152-I

7

KDJE54640-I

KDJE54641-E

(4)　サーバ管理コマンド（cjresetsv）

サーバ管理コマンド（cjresetsv）の監査ログの出力ポイントを次の図に示します。

図6‒7　監査ログの出力ポイント（cjresetsv）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒18　監査ログの出力ポイントとメッセージIDの対応（cjresetsv）

コマンド

図中の番号

出力される監査ログのメッセージID

cjresetsv

1

KDJE54642-I

2

KDJE54596-I

3

KDJE54153-I

4

KDJE54154-I

5

KDJE54597-I

KDJE54598-E

6

KDJE54599-E

7

KDJE54643-I

KDJE54644-E

6.7.2　バッチサーバで使用するコマンドの監査ログの出力ポイント

バッチサーバで使用するコマンドの監査ログの出力ポイントについて説明します。

ここでは，バッチサーバで使用するコマンドのうち，cjexecjobコマンド，cjkilljobコマンド，およびcjlistjobコマンドの監査ログの出力ポイントについて説明します。

バッチサーバで使用するそのほかのコマンドについては，「6.7.1　J2EEサーバで使用するコマンドの監査ログの出力ポイント」の次の表に示した個所を参照してください。

表6‒19　バッチサーバで使用するそのほかのコマンドの参照先

バッチサーバで使用するコマンド

参照先

サーバプロセスを起動・停止するコマンド（サーバ管理コマンド以外）

6.7.1(1)

サーバプロセスを起動・停止するコマンド以外のコマンド（サーバ管理コマンド以外）

6.7.1(2)

サーバ管理コマンド（cjresetsv以外のサーバ管理コマンド）※

6.7.1(3)

サーバ管理コマンド（cjresetsv）

6.7.1(4)

注※　「6.7.1(3)　サーバ管理コマンド（cjresetsv以外のサーバ管理コマンド）」で説明しているコマンドのうち，バッチサーバで使用できるのは次のコマンドだけです。

cjclearpool，cjcopyres，cjdeleteres，cjdeployrar，cjexportapp，cjexportrar，cjgetrarprop，cjgetresprop，cjimportres，cjlistpool，cjlistrar，cjlistres，cjlistthread，cjresumepool，cjsetrarprop，cjsetresprop，cjstartrar，cjstoprar，cjstopthread，cjsuspendpool，cjtestres，cjundeployrar，cjunmapsec

(1)　バッチアプリケーションのスケジューリング機能を使用しない場合

バッチアプリケーションのスケジューリング機能を使用しない場合の監査ログの出力ポイントについて説明します。

cjexecjobコマンド，cjkilljobコマンド，およびcjlistjobコマンドの監査ログの出力ポイントを次の図に示します。

図6‒8　監査ログの出力ポイント（cjexecjobコマンド，cjkilljobコマンド，およびcjlistjobコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒20　監査ログの出力ポイントとメッセージIDの対応（cjexecjobコマンド，cjkilljobコマンド，およびcjlistjobコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjexecjob

1

KDJE54156-I

4

KDJE54157-I

KDJE54158-E※1

cjkilljob

1

KDJE54162-I

4

KDJE54163-I

KDJE54164-W

cjlistjob

1

KDJE54170-I

4

KDJE54171-I

KDJE54172-E※2

cjstartsv（cjexecjobコマンド実行時）

2

KDJE54159-I

3

KDJE54160-I

KDJE54161-E※3

cjstartsv（cjkilljobコマンド実行時）

2

KDJE54165-I

3

KDJE54166-I

KDJE54167-E

cjstartsv（cjlistjobコマンド実行時）

2

KDJE54174-I

3

KDJE54175-I

KDJE54176-E

注※1　KDJE54158-Eは次の場合に出力されます。

指定したサーバが見つからないなどの原因でバッチの実行に失敗した場合

バッチの実行時，0以外の終了コード，またはJavaVM終了メソッドに指定した引数以外が出力された場合

注※2　KDJE54172-Eは次の場合に出力されます。

mainメソッドが見つからないなどの原因でバッチの実行に失敗した場合

注※3　KDJE54161-Eは次の場合に出力されます。

mainメソッドが見つからないなどの原因でバッチの実行に失敗した場合

バッチの実行時，0以外の終了コード，またはJavaVM終了メソッドに指定した引数以外が出力された場合

(2)　バッチアプリケーションのスケジューリング機能を使用する場合

バッチアプリケーションのスケジューリング機能を使用する場合の監査ログの出力ポイントについて説明します。

(a)　cjexecjobコマンドの監査ログの出力ポイント

cjexecjobコマンドの監査ログの出力ポイントを次の図に示します。

図6‒9　監査ログの出力ポイント（cjexecjobコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒21　監査ログの出力ポイントとメッセージIDの対応（cjexecjobコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjexecjob

1

KDJE54156-I

3

KDJE54168-W

5

KDJE54157-I

KDJE54158-E※1

cjstartsv（cjexecjobコマンド実行時）

2

KDJE54159-I

4

KDJE54160-I

KDJE54161-E※2

注※1　KDJE54158-Eは次の場合に出力されます。

指定したサーバが見つからないなどの原因でバッチの実行に失敗した場合

バッチの実行時，0以外の終了コード，またはJavaVM終了メソッドに指定した引数以外が出力された場合

注※2　KDJE54161-Eは次の場合に出力されます。

mainメソッドが見つからないなどの原因でバッチの実行に失敗した場合

バッチの実行時，0以外の終了コード，またはJavaVM終了メソッドに指定した引数以外が出力された場合

(b)　cjkilljobコマンドの監査ログの出力ポイント

cjkilljobコマンドの監査ログの出力ポイントを次の図に示します。

図6‒10　監査ログの出力ポイント（cjkilljobコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒22　監査ログの出力ポイントとメッセージIDの対応（cjkilljobコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjkilljob

1

KDJE54162-I

4

KDJE54169-W

5

KDJE54163-I

KDJE54164-W

cjstartsv（cjkilljobコマンド実行時）

2

KDJE54165-I

3

KDJE54166-I

KDJE54167-E

(c)　cjlistjobコマンドの監査ログの出力ポイント

cjlistjobコマンドの監査ログの出力ポイントを次の図に示します。

図6‒11　監査ログの出力ポイント（cjlistjobコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒23　監査ログの出力ポイントとメッセージIDの対応（cjlistjobコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjlistjob

1

KDJE54170-I

2

KDJE54173-W

3

KDJE54171-I

KDJE54172-E※

注※　KDJE54172-Eは次の場合に出力されます。

mainメソッドが見つからないなどの原因でバッチの実行に失敗した場合

6.7.3　性能解析トレース・CTMで使用するコマンドの監査ログの出力ポイント

性能解析トレース・CTMで使用するコマンドの監査ログの出力ポイントについて説明します。

(1)　サーバプロセスを起動・停止するコマンド

サーバプロセス(デーモン)を起動・停止するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒12　監査ログの出力ポイント（サーバプロセスを起動・停止するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒24　監査ログの出力ポイントとメッセージIDの対応（サーバプロセスを起動・停止するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cprfstart

1

KFCT81000-I

4

KFCT81001-I

KFCT81002-E

cprfstop

1

KFCT81020-I

4

KFCT81021-I

KFCT81022-E

ctmdmstart

1

KFCT91000-I

4

KFCT91001-I

KFCT91002-E

ctmdmstop

1

KFCT91020-I

4

KFCT91021-I

KFCT91022-E

ctmstart

1

KFCT91040-I

4

KFCT91041-I

KFCT91042-E

ctmstop

1

KFCT91060-I

4

KFCT91061-I

KFCT91062-E

なお，それぞれのコマンドがリクエストを送信するサーバプロセス（デーモン）ごとに，図中の「2」および「3」で出力されるメッセージが異なります。サーバプロセスの種類と図中の「2」および「3」で出力されるメッセージIDの対応を次の表に示します。

表6‒25　サーバプロセス（デーモン）の種類とメッセージIDの対応（サーバプロセスを起動・停止するコマンド）

サーバプロセス（デーモン）

図中の番号

メッセージID

PRFデーモン

2

KFCT81010-I

KFCT81030-I

3

KFCT81011-I

KFCT81012-E

KFCT81031-I

KFCT81032-E

CTMドメインマネジャ

2

KFCT91010-I

KFCT91030-I

3

KFCT91011-I

KFCT91012-E

KFCT91031-I

KFCT91032-E

CTMデーモン

2

KFCT91050-I

KFCT91070-I

3

KFCT91051-I

KFCT91052-E

KFCT91071-I

KFCT91072-E

(2)　プロセスへの通信・共有メモリへのアクセスを実行するコマンド

プロセスへの通信・共有メモリへのアクセスを実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒13　監査ログの出力ポイント（プロセスへの通信・共有メモリへのアクセスを実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒26　監査ログの出力ポイントとメッセージIDの対応（プロセスへの通信・共有メモリへのアクセスを実行するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

ctmstsstart

1

KFCT91080-I

3

KFCT91081-I

KFCT91082-E

ctmstsstop

1

KFCT91100-I

3

KFCT91101-I

KFCT91102-E

−※

2

KFCT91091-I

KFCT91111-I

注※　この表で示しているすべてのコマンドに共通で出力されるメッセージです。

(3)　情報を参照するコマンド

情報を参照するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒14　監査ログの出力ポイント（情報を参照するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒27　監査ログの出力ポイントとメッセージIDの対応（情報を参照するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cprfgetpid

1

KFCT84000-I

2

KFCT84001-I

KFCT84002-E

ctmgetpid

1

KFCT94000-I

2

KFCT94001-I

KFCT94002-E

6.7.4　Management Serverで使用するコマンドの監査ログの出力ポイント

Management Serverで使用するコマンドの監査ログの出力ポイントについて説明します。

(1)　Management Serverのセットアップコマンド

Management Serverのセットアップコマンドの監査ログの出力ポイントを次の図に示します。

図6‒15　監査ログの出力ポイント（Management Serverのセットアップコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒28　監査ログの出力ポイントとメッセージIDの対応（Management Serverのセットアップコマンド）

コマンド（オプション）

図中の番号

出力される監査ログのメッセージID

mngsvrctl（setup）

1

KEOS80006-I

2

KEOS80007-I

KEOS80008-E

(2)　Management Serverを起動・停止するコマンド

Management Serverを起動・停止するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒16　監査ログの出力ポイント（Management Serverを起動・停止するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒29　監査ログの出力ポイントとメッセージIDの対応（Management Serverを起動・停止するコマンド）

コマンド（サブコマンド）

図中の番号

出力される監査ログのメッセージID

mngsvrctl（start）

1

KEOS80000-I

2

KEOS80108-I

3

KEOS80109-I

KEOS80110-E

4

KEOS80001-I

KEOS80002-E

mngsvrctl（stop）

1

KEOS80003-I

2

KEOS80111-I

3

KEOS80112-I

KEOS80113-E

4

KEOS80004-I

KEOS80005-E

(3)　運用管理エージェントの起動・停止を実行するコマンド

運用管理エージェントの起動・停止の監査ログの出力ポイントを次の図に示します。

図6‒17　監査ログの出力ポイント（運用管理エージェントの起動・停止）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒30　監査ログの出力ポイントとメッセージIDの対応（運用管理エージェントの起動・停止）

コマンド（サブコマンド）

図中の番号

出力される監査ログのメッセージID

adminagentctl（start）

1

KEOS80009-I

2

KEOS80114-I

3

KEOS80115-I

KEOS80116-E

4

KEOS80010-I

KEOS80011-E

adminagentctl（stop）

1

KEOS80012-I

2

KEOS80117-I

3

KEOS80118-I

KEOS80119-E

4

KEOS80013-I

KEOS80014-E

(4)　Management Serverによる承認処理を実行するコマンド

Management Serverによる承認処理を実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒18　監査ログの出力ポイント（Management Serverによる承認処理を実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒31　監査ログの出力ポイントとメッセージIDの対応（Management Serverによる承認処理を実行するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cmx_test_lb

1

KEOS80036-I

4

KEOS80037-I

KEOS80038-E

cmx_list_status

1

KEOS80045-I

4

KEOS80046-I

KEOS80047-E

cmx_list_model

1

KEOS80102-I

4

KEOS80103-I

KEOS80104-E

cmx_export_model

1

KEOS80105-I

4

KEOS80106-I

KEOS80107-E

−※

2

KEOS80120-I

3

KEOS80121-I

KEOS80122-E

注※　この表で示しているすべてのコマンドに共通で出力されるメッセージです。

(5)　Management Serverによるファイル操作を実行するコマンド

Management Serverによるファイル操作を実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒19　監査ログの出力ポイント（Management Serverによるファイル操作を実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒32　監査ログの出力ポイントとメッセージIDの対応（Management Serverによるファイル操作を実行するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

mngsvrctl setup

1

KEOS80006-I

6

KEOS80007-I

KEOS80008-E

cmx_admin_passwd

1

KEOS80015-I

6

KEOS80016-I

KEOS80017-E

cmx_build_model

1

KEOS80018-I

6

KEOS80019-I

KEOS80020-E

cmx_change_model

1

KEOS80024-I

6

KEOS80025-I

KEOS80026-E

cmx_delete_system

1

KEOS80027-I

6

KEOS80028-I

KEOS80029-E

cmx_resume_lb

1

KEOS80030-I

6

KEOS80031-I

KEOS80032-E

cmx_scaleout_host

1

KEOS80033-I

6

KEOS80034-I

KEOS80035-E

cmx_start_target

1

KEOS80048-I

6

KEOS80049-I

KEOS80050-E

cmx_stop_target

1

KEOS80051-I

6

KEOS80052-I

KEOS80053-E

cmx_undefined_application

1

KEOS80093-I

6

KEOS80094-I

KEOS80095-E

−※

2

KEOS80120-I

3

KEOS80121-I

KEOS80122-E

4

KEOS80123-I

5

KEOS80124-I

KEOS80125-E

注※　この表で示しているすべてのコマンドに共通で出力されるメッセージです。

(6)　Management Server・運用管理エージェントによるファイル操作を実行するコマンド

Management Server・運用管理エージェントによるファイル操作を実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒20　監査ログの出力ポイント（Management Server・運用管理エージェントによるファイル操作を実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒33　監査ログの出力ポイントとメッセージIDの対応（Management Server・運用管理エージェントによるファイル操作を実行するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cmx_build_system

1

KEOS80021-I

2

KEOS80120-I

3

KEOS80121-I

KEOS80122-E

4

KEOS80123-I

6

KEOS80124-I

KEOS80125-E

8

KEOS80022-I

KEOS80023-E

なお，それぞれのコマンドが操作を実行するファイルごとに，図中の「5」および「7」で出力されるメッセージが異なります。操作を実行するファイルと図中の「5」および「7」で出力されるメッセージIDの対応を次の表に示します。

表6‒34　操作を実行するファイルと出力されるメッセージIDの対応

操作を実行するファイル

図中の番号

出力される監査ログのメッセージID

運用監視エージェントの設定ファイル

5

KEOS80126-I

7

KEOS80127-I

KEOS80128-E

J2EEサーバ用JP1イベント発行用プロパティファイル

5

KEOS80129-I

7

KEOS80130-I

KEOS80131-E

Managementイベント発行用プロパティファイル

5

KEOS80132-I

7

KEOS80133-I

KEOS80134-E

J2EEサーバ用ユーザプロパティファイル

5

KEOS80135-I

7

KEOS80136-I

KEOS80137-E

J2EEサーバ用オプション定義ファイル

5

KEOS80138-I

7

KEOS80139-I

KEOS80140-E

HTTP Server用リダイレクタ動作定義ファイル

5

KEOS80144-I

7

KEOS80145-I

KEOS80146-E

ワーカ定義ファイル

5

KEOS80147-I

7

KEOS80148-I

KEOS80149-E

(7)　HTTP Serverを操作するコマンド

HTTP Serverを操作するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒21　監査ログの出力ポイント（HTTP Serverを操作するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒35　監査ログの出力ポイントとメッセージIDの対応（HTTP Serverを操作するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

設定ファイル編集コマンド

1

KAWS10501-I

2

KAWS10502-I

KAWS10503-E

1

KAWS10504-I

2

KAWS10505-I

KAWS10506-E

hwsserveredit

1

KAWS10601-I

2

KAWS10602-I

KAWS10603-E

1

KAWS10604-I

2

KAWS10605-I

KAWS10606-E

1

KAWS10607-I

2

KAWS10608-I

KAWS10609-E

6.7.5　EJBクライアントアプリケーションで使用するコマンドの監査ログの出力ポイント

EJBクライアントアプリケーションで使用するコマンドの監査ログの出力ポイントについて説明します。

図6‒22　監査ログの出力ポイント（EJBクライアントアプリケーションで使用するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒36　監査ログの出力ポイントとメッセージIDの対応（EJBクライアントアプリケーションで使用するコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

cjclstartap

1

KDJE54129-I

2

KDJE54130-I

KDJE54131-E※

cjcldumpap

1

KDJE54132-I

2

KDJE54133-I

KDJE54134-E

cjcldellog

1

KDJE54135-I

2

KDJE54136-I

KDJE54137-E

注※　KDJE54131-Eは次の場合に出力されます。

JavaVMの初期化など，コマンドの内部処理が失敗した場合

Javaアプリケーションの実行後に終了コードが0以外の場合

6.7.6　HTTP Serverで使用するコマンド，およびHTTP Serverに対する操作の監査ログの出力ポイント（Windowsの場合）

Windowsの場合のHTTP Serverで使用するコマンドおよびHTTP Serverに対する操作の監査ログの出力ポイントについて説明します。

(1)　HTTP Serverの起動・停止を実行するコマンド

HTTP Serverの起動・停止を実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒23　監査ログの出力ポイント（HTTP Serverの起動・停止を実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒37　監査ログの出力ポイントとメッセージIDの対応（HTTP Serverの起動・停止を実行するコマンド）

コマンド（オプション）

図中の番号

出力される監査ログのメッセージID

httpsd（-k start）

1

KAWS10001-I

2

KAWS10004-I

3

KAWS10005-I

KAWS10006-E

4

KAWS10002-I

KAWS10003-E

httpsd（-k stop）

1

KAWS10010-I

2

KAWS10013-I

3

KAWS10014-I

KAWS10015-E

4

KAWS10011-I

KAWS10012-E

httpsd（-k restart）

1

KAWS10019-I

2

KAWS10022-I

3

KAWS10023-I

KAWS10024-E

4

KAWS10020-I

KAWS10021-E

httpsd（-k gracefulstop）

1

KAWS10025-I

2

KAWS10028-I

3

KAWS10029-I

KAWS10030-E

4

KAWS10026-I

KAWS10027-E

(2)　HTTP Serverの起動・停止を実行する操作（コントロールパネルから）

コントロールパネルからHTTP Serverの起動・停止を実行する操作の監査ログの出力ポイントを次の図に示します。

図6‒24　監査ログの出力ポイント（コントロールパネルからHTTP Serverの起動・停止を実行する操作）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒38　監査ログの出力ポイントとメッセージIDの対応（コントロールパネルからHTTP Serverの起動・停止を実行する操作）

図中の番号

出力される監査ログのメッセージID

1

KAWS10004-I

KAWS10007-I

KAWS10013-I

KAWS10016-I

2

KAWS10005-I

KAWS10006-E

KAWS10008-I

KAWS10009-E

KAWS10014-I

KAWS10015-E

KAWS10017-I

KAWS10018-E

6.7.7　HTTP Serverで使用するコマンド，およびHTTP Serverに対する操作の監査ログの出力ポイント（UNIXの場合）

UNIXの場合のHTTP Serverで使用するコマンドおよびHTTP Serverに対する操作の監査ログの出力ポイントについて説明します。

(1)　HTTP Serverの起動・停止を実行するコマンド（httpsdctlユティリティから）

httpsdctlユティリティからHTTP Serverの起動・停止を実行するコマンドの監査ログの出力ポイントを次の図に示します。

図6‒25　監査ログの出力ポイント（httpsdctlユティリティからHTTP Serverの起動・停止を実行するコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒39　監査ログの出力ポイントとメッセージIDの対応（httpsdctlユティリティからHTTP Serverの起動・停止を実行するコマンド）

コマンド（httpsdctlユティリティの操作）

図中の番号

出力される監査ログのメッセージID

httpsd（httpsdctl start）

1

KAWS10101-I

2

KAWS10102-I

KAWS10103-E

3

KAWS10151-I

4

KAWS10152-I

KAWS10153-E

httpsd（httpsdctl restart）

1

KAWS10104-I

2

KAWS10105-I

KAWS10106-E

KAWS10116-I

KAWS10117-E

3

KAWS10154-I

4

KAWS10155-I

KAWS10156-E

httpsd（httpsdctl graceful）

1

KAWS10107-I

2

KAWS10108-I

KAWS10109-E

KAWS10118-I

KAWS10119-E

3

KAWS10157-I

4

KAWS10158-I

KAWS10159-E

httpsd（httpsdctl stop）

1

KAWS10110-I

2

KAWS10111-I

KAWS10112-E

3

KAWS10160-I

4

KAWS10161-I

KAWS10162-E

httpsd（httpsdctl gracefulstop）

1

KAWS10113-I

2

KAWS10114-I

KAWS10115-E

3

KAWS10163-I

4

KAWS10164-I

KAWS10165-E

(2)　httpsdコマンド（コマンドの直接実行）

httpsdコマンドを直接実行する場合の監査ログの出力ポイントを次の図に示します。

図6‒26　監査ログの出力ポイント（直接実行するhttpsdコマンド）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒40　監査ログの出力ポイントとメッセージIDの対応（直接実行するhttpsdコマンド）

コマンド

図中の番号

出力される監査ログのメッセージID

httpsd

1

KAWS10101-I

2

KAWS10102-I

KAWS10103-E

3

KAWS10151-I

4

KAWS10152-I

KAWS10153-E

(3)　シグナル送信によるデーモンプロセスの操作

シグナル送信によってデーモンプロセスを操作するときの監査ログの出力ポイントを次の図に示します。

図6‒27　監査ログの出力ポイント（シグナル送信によるデーモンプロセスの操作）

この図に示した監査ログの出力ポイントと出力される監査ログのメッセージIDの対応を次の表に示します。

表6‒41　監査ログの出力ポイントとメッセージIDの対応（シグナル送信によるデーモンプロセスの操作）

シグナル送信による操作

図中の番号

出力される監査ログのメッセージID

再起動（SIGHUP）

1

KAWS10154-I

2

KAWS10155-I

KAWS10156-E

再起動（SIGUSR1）

1

KAWS10157-I

2

KAWS10158-I

KAWS10159-E

停止（SIGTERM）

1

KAWS10160-I

2

KAWS10161-I

KAWS10162-E

計画停止（SIGUSR2）

1

KAWS10163-I

2

KAWS10164-I

KAWS10165-E

6.8　アプリケーションの監査ログを出力するための実装

アプリケーションサーバでは，J2EEアプリケーションまたはバッチアプリケーションに実装できる監査ログ出力用のAPIを提供しています。監査ログ出力用のAPIを使用することで，アプリケーションに対する操作，およびアプリケーションによる処理が実行されたタイミングで，操作および処理の履歴を監査ログに出力させることができます。ここでは，監査ログ出力用のAPIの実装例と実装時の注意事項について説明します。

なお，監査ログ出力用のAPIの詳細については，マニュアル「アプリケーションサーバ リファレンス API編」の「8.　監査ログ出力で使用するAPI」を参照してください。

6.8.1　監査ログ出力用のAPIの実装例

監査ログ出力用のAPIの実装例を次に示します。

if (UserAuditLogger.isEnabled())
{
    try
    {
        UserAuditLogger logger = UserAuditLogger.getLogger("UserComponent");
        if (logger.isLoggable("Message1"))
        {
            AuditLogRecord record = new AuditLogRecord();
            record.setMessageId("Message1");
            record.setCategory(AuditLogRecord.CATEGORY_CONFIGURATION_ACCESS);
            record.setResult(AuditLogRecord.RESULT_SUCCESS);
            record.setObjectInfo("Object");
            record.setOperation(AuditLogRecord.OPERATION_REFER);
            record.setMessage("Message");
            logger.log(record);
        }
    }
    catch (AuditLogException e)
    {
        // 監査ログの出力に失敗したときの処理
    }
}

このように実装した場合の監査ログの出力例を次に示します。なお，この例はWindowsの場合です。

CALFHM 1.0, seqnum=2, msgid=Message1, date=2007-05-31T19:12:53.788+09:00, progid=Cosminexus, compid=UAP_UserComponent, pid=3984, ocp:host=hostname, ctgry=ConfigurationAccess, result=Success, subj:euid=username, obj="Object", op="Refer", loc="10.209.15.130/1234/0x0000000000000001", msg="Message"

6.8.2　監査ログ出力用のAPI実装時の注意事項

監査ログ出力用のAPIを実装するときの注意事項について説明します。

システムの管理・運用に関する情報について

システム管理や運用に関する情報のうち，監査を実行するユーザなどに参照させてはいけない情報を監査ログに出力しないようにしてください。監査ログに出力してはいけない情報の例を次に示します。

データベースにアクセスするユーザのユーザ名，およびパスワード

監査ログファイルや監査ログの設定ファイルに対して書き込み権限を所有するユーザのユーザ名，およびパスワード

複数マシン間での時刻の設定について

複数のマシンにわたって監査ログを出力する場合は，それぞれのマシンに同じ時刻を設定しておいてください。

監査ログに出力する項目について

J2EEアプリケーションまたはバッチアプリケーションが出力する監査ログには，次の項目が必ず出力されるように実装してください。

メッセージID

発生コンポーネント名

監査事象の種別

監査事象の結果

6.9　監査ログ出力の設定

この節では，監査ログを出力するために必要な設定について説明します。監査ログを出力する機能については，「6.3　監査ログとは」を参照してください。

また，ここでは，監査ログの動作に関する情報が出力される，監査ログのメッセージログ，および監査ログの例外情報の出力に関する設定についても説明します。監査ログのメッセージログ，および監査ログの例外情報の詳細については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「4.3.4　監査ログで出力するログの取得」を参照してください。

監査ログ，監査ログのメッセージログ，および監査ログの例外情報の出力についての設定は，製品のインストール単位に設定します。

なお，監査ログの格納場所を変更したい場合は，それぞれのログの設定をする前に，次の環境変数をシステム環境変数に設定しておいてください。

COSMINEXUS_AUDITLOG_CONF=”<監査ログ定義ファイルの格納場所のパス>”

また，監査ログを出力する場合は，この節で説明している手順を必ず実施してください。この節で説明している手順を実施しなかった場合，監査ログ定義ファイルに設定した，出力ディレクトリや監査ログファイルに対するアクセス権が適用されません。監査ログ定義ファイルの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「11.2.1　監査ログ定義ファイル」を参照してください。それぞれのログの設定手順を次に示します。

監査ログ定義ファイルを編集します。

監査ログ，監査ログのメッセージログ，および監査ログの例外情報について，出力の有無やそれぞれのログの出力先などを，監査ログ定義ファイルのプロパティに設定します。

監査ログ定義ファイルに設定できるプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「11.2.1　監査ログ定義ファイル」を参照してください。

監査ログセットアップコマンド（auditsetupコマンド）を実行します。

監査ログセットアップコマンドを実行すると，監査ログ，監査ログのメッセージログ，および監査ログの例外情報に必要なアクセス権限が自動で設定されます。監査ログセットアップコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「12.2　監査ログの設定で使用するコマンドの詳細」を参照してください。

監査ログセットアップコマンドの実行例を次に示します。

Windowsの場合

C:¥Program Files¥Hitachi¥Cosminexus¥common¥bin¥auditsetup.exe

UNIXの場合

/opt/Cosminexus/common/bin/auditsetup

7　データベース監査証跡連携機能

この章では，データベースが提供するデータベース監査証跡の機能と連携する機能，およびアプリケーションサーバのシステムでできることについて説明します。

7.1　この章の構成

この章の構成を次の表に示します。

表7‒1　この章の構成（データベース監査証跡連携機能）

分類

タイトル

参照先

解説

データベース監査証跡連携機能の概要

7.2

データベース監査証跡との連携

7.3

データベース監査証跡への情報の出力

7.4

設定

データベース監査証跡との連携機能の設定

7.5

運用

データベース監査証跡と連携した運用例

7.6

注意事項

ルートアプリケーション情報をデータベースに設定する場合の注意事項

7.7

注「実装」について，この機能固有の説明はありません。

7.2　データベース監査証跡連携機能の概要

ここでは，データベース監査証跡と連携した運用の作業について説明します。

データベース監査証跡連携機能は，データベースが提供するデータベース監査証跡の機能と連携する機能です。アプリケーションサーバ上のアプリケーション※1またはサーバ内※2からデータベースにアクセスした際に，アプリケーションサーバのシステムが持つ情報をデータベース監査証跡に出力できます。

注※1　J2EEアプリケーションまたはバッチアプリケーションが対象となります。

注※2　J2EEサーバ内またはバッチサーバ内が対象となります。

なお，データベース監査証跡と連携した運用では，データベース監査証跡，性能解析トレースおよびアプリケーションのユーザログを利用して，データベースの監査対象のテーブルにアクセスしたリクエストを特定できます。

7.3　データベース監査証跡との連携

この節では，データベースが提供するデータベース監査証跡の機能と連携する機能，およびアプリケーションサーバのシステムでできることについて説明します。

7.3.1　データベース監査証跡とは

データベース監査証跡とは，データベースに対する操作を記録したものです。監査者がデータベース監査証跡を調査することによって，監査対象のテーブルに決められた操作権限どおりに運用が行われているか，不正なアクセスがないかをチェックできます。データベース監査証跡の出力，取得，参照などをするための機能は，データベースが提供しています。データベース監査証跡の詳細については，データベースのマニュアルを参照してください。

7.3.2　データベース監査証跡と連携して取得できる情報

アプリケーションサーバのシステムでは，データベースが提供するデータベース監査証跡の機能と連携できます。この機能をデータベース監査証跡連携機能といいます。この機能によって，次に示すアプリケーションまたはサーバ内からデータベースにアクセスした際に，アプリケーションサーバのシステムが持つ情報をデータベース監査証跡の情報の一部として出力させることができます。

J2EEアプリケーションまたはJ2EEサーバ内からデータベースにアクセスした際

バッチアプリケーションまたはバッチサーバ内からデータベースにアクセスした際

データベース監査証跡に出力できるアプリケーションサーバのシステムの情報は，クライアントからのリクエストごとに割り振られるルートアプリケーション情報です。

データベース監査証跡，アプリケーションのユーザログ，および性能解析トレースを組み合わせて，データベースの監査対象のテーブルにアクセスしたリクエストのセッションID，ログイン名を特定できます。

7.4　データベース監査証跡への情報の出力

この節では，データベース監査証跡連携機能を使用して，データベース監査証跡に出力する情報について説明します。

7.4.1　データベース監査証跡への出力の流れ

データベース監査証跡連携機能を使用して，データベース監査証跡にアプリケーションサーバのシステムの情報を出力する処理の流れを次の図に示します。この図では，J2EEアプリケーションからデータベースにアクセスした場合について示します。

図7‒1　データベース監査証跡への情報の出力の流れ

J2EEアプリケーションからDBConnectorを経由してデータベースにアクセスする処理を実行します。

データベース監査証跡連携機能がルートアプリケーション情報をパフォーマンストレーサから取得します。

取得したルートアプリケーション情報を，コネクションを通じてデータベースに渡します。

データベースで情報を処理し，データベース監査証跡の情報としてルートアプリケーション情報を出力します。

7.4.2　前提条件

データベース監査証跡連携機能を使用してデータベース監査証跡にアプリケーションサーバのシステムの情報を出力するには，次の表に示すデータベース，およびDBConnectorを使用している必要があります。

表7‒2　データベース監査証跡連携機能を使用できるデータベースとDBConnector

データベース

使用するDBConnector

HiRDB（バージョン08-02以降）

HiRDB Type4 JDBC Driverに対応した次のDB Connector

DBConnector_HiRDB_Type4_CP.rar

DBConnector_HiRDB_Type4_XA.rar

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

J2EEアプリケーションで，DBConnectorからデータベースへのアクセスを実装している場合に，そのアクセスがJava EEおよびアプリケーションサーバの仕様でDBConnectorからのアクセスが許可されているメソッドまたはその延長の処理内であれば，データベース監査証跡連携機能が動作します。データベース監査証跡連携機能が動作することで，アプリケーションサーバのシステムの情報をデータベース監査証跡に出力できます。

次の場合はデータベース監査証跡連携機能が動作しないため，データベース監査証跡にアプリケーションサーバのシステムの情報は出力されません。

表7-2以外のDBConnectorを使用した場合

データベースが提供しているJDBCドライバから直接コネクションを取得してデータベースにアクセスした場合

データベースが提供しているデータベース監査証跡機能のAPIを使用した場合

7.4.3　データベース監査証跡に出力する情報

データベース監査証跡連携機能を使用して，データベース監査証跡に出力できるアプリケーションサーバのシステムの情報は，ルートアプリケーション情報です。ルートアプリケーション情報以外にデータベース監査証跡に出力されている情報は，データベースが出力した情報です。

データベース監査証跡に出力されるルートアプリケーション情報は，データベースにアクセスしたリクエストのルートアプリケーション情報です。

また，リクエストの延長でJ2EEサーバがデータベースにアクセスする次のような場合には，リクエストのルートアプリケーション情報が出力されます。

Entity BeanのCMPを使用し，EJBコンテナ内からデータベースにアクセスした場合

コネクションの自動クローズが実行された場合

ただし，リクエストと異なるルートアプリケーション情報が出力される場合，およびルートアプリケーション情報が出力されない場合もあります。それぞれの場合について説明します。

リクエストとは異なるルートアプリケーション情報が出力される場合

リクエストの延長ではないところでデータベースにアクセスした次のような場合，リクエストとは異なるルートアプリケーション情報が出力されます。

Message-driven Beanのメッセージ受信側でデータベースにアクセスした場合

ただし，Reliable Messagingの場合，メッセージ送信元のルートアプリケーション情報と関連づけることもできます。詳細については，マニュアル「Reliable Messaging」の「2.6.3　Message-driven Beanとの連携」を参照してください。

Timer Serviceのコールバックメソッド内でデータベースにアクセスした場合

ルートアプリケーション情報が出力されない場合

次の場合，ルートアプリケーション情報は出力されません。

コネクション取得前にデータベースにアクセスした場合

コネクションプールのウォーミングアップのコネクションを取得した場合

リソースの接続テストをした場合

7.4.4　データベース監査証跡の出力個所

HiRDBのデータベース監査証跡表の次の列に情報が出力されます。

出力する列名称

PRODUCT_INFO_1

列の型

VARCHAR(255)

出力される情報

ルートアプリケーション情報

7.5　データベース監査証跡との連携機能の設定

データベース監査証跡連携機能を使用するには，次の設定が必要です。

実行環境での設定

データベースサーバの設定

それぞれの設定について説明します。

7.5.1　実行環境での設定

データベース監査証跡との連携機能を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。データベース監査証跡との連携機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのデータベース監査証跡との連携機能の定義について次の表に示します。

表7‒3　簡易構築定義ファイルでのデータベース監査証跡との連携機能の定義

項目

指定するパラメタ

設定内容

データベース監査証跡機能に対応したJDBCドライバのJARファイルのパスの設定

add.class.path

JDBCドライバのJARファイル※1をJ2EEサーバのユーザクラスパスに追加します。

パラメタの設定値には，JARファイルのパスを指定します。add.class.pathは，簡易構築定義ファイルの，J2EEサーバの拡張パラメタに設定します。

データベース監査証跡連携機能の設定※2

ejbserver.container.audit_trail.enabled

データベース監査証跡連携機能を使用するかどうかを指定します。プロパティを省略した場合，データベース監査証跡連携機能は無効になります。

パラメタは，J2EEサーバのJavaVMのシステムプロパティで定義します。

注※1

HiRDBと連携する場合に使用するJDBCドライバは，HiRDB Type4 JDBC Driverです。

なお，データベース監査証跡連携機能の設定のパラメタで機能を使用する設定をした場合でも，データベース監査証跡連携機能に対応したJDBCドライバのJARファイルがJ2EEサーバのユーザクラスパスに追加されていないときは，KDJE54001-Wのメッセージが出力され，データベース監査証跡連携機能は無効になります。この場合，J2EEサーバ起動時にKDJE54000-Iは出力されません。

注※2

データベース監査証跡連携機能が有効かどうかは，J2EEサーバ起動時に確認できます。データベース監査証跡連携機能が有効な場合，J2EEサーバ起動時にKDJE54000-Iのメッセージが出力され，無効な場合，メッセージは出力されません。このデータベース監査証跡連携機能の有効・無効を通知するメッセージは，J2EEサーバ起動後には出力されません。そのため，データベース監査証跡連携機能を使用する場合は，J2EEサーバ起動時にKDJE54000-Iのメッセージが出力されることを確認してください。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

注意事項

データベース監査証跡連携機能を使用して，監査証跡にアプリケーションサーバのシステムの情報を出力できるデータベース以外のデータベースと接続する場合は，この機能を使用する設定にしないでください。アプリケーションサーバからJDBCドライバに監査証跡を出力しようとする不要な処理が行われる場合があります。この場合，KDJE54000-Iのメッセージが出力されても，データベース監査証跡連携機能は使用できません。

7.5.2　データベースサーバでの設定

データベース監査証跡連携機能を使用するには，データベースサーバでデータベース監査証跡の機能を有効にする必要があります。データベース監査証跡の機能を設定する際には，監査対象とするテーブルや操作を検討してください。なお，アプリケーションサーバのシステムでは，Component Containerやそのほかの構成ソフトウェアで使用する独自のテーブルを生成しています。これらのテーブルを監査対象にするかどうかも検討してください。

データベースサーバの監査証跡の機能の設定方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

7.6　データベース監査証跡と連携した運用例

この節では，データベース監査証跡と連携した運用例について説明します。この運用例では，アプリケーションのユーザログ，データベース監査証跡，および性能解析トレースに出力されたルートアプリケーション情報を利用して，データベースの監査対象のテーブルにアクセスしたアプリケーションのログイン名やセッションIDを特定します。この場合，次の作業を実行します。

アプリケーションのユーザログを取得する

データベースの監査証跡情報を取得する

性能解析トレースを取得する

1.〜3.で取得した情報を突き合わせて，ログイン名，セッションIDを特定する

それぞれの出力例や作業について説明します。

7.6.1　アプリケーションのユーザログの取得

あらかじめJ2EEアプリケーションやバッチアプリケーションでユーザログを取得するための実装をしておくと，次の情報がユーザログに出力されます。

アプリケーションのログイン名

ルートアプリケーション情報

セッションID

ここでは，J2EEアプリケーションのユーザログの実装例および出力例を示します。

実装例

ログイン名，ルートアプリケーション情報，およびセッションIDをJ2EEアプリケーションのユーザログに出力する場合の実装例を示します。なお，ログイン名はWebコンテナのBasic認証またはForm認証でログインしたユーザIDを取得して出力します。

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import com.hitachi.software.ejb.application.prf.CprfTrace;

(中略)
public void doGet (HttpServletRequest req, HttpServletResponse res)
              throws ServletException, IOException {

　HttpSession ses = req.getSession();
　String sessionID = (ses != null) ? ses.getId() : null;　// セッションIDを取得
　String rootAPInfo = CprfTrace.getRootApInfo(); // ルートアプリケーション情報を取得
　String userID = req.getRemoteUser(); // J2EEアプリケーションのログイン名を取得

　ユーザログ出力メソッド(sessionID,rootAPInfo,userID);
　　：

出力例

J2EEアプリケーションのユーザログの出力例を示します。この例では，「セッションID」，「ルートアプリケーション情報」，「ログイン名」の順で出力されています。

7.6.2　データベースの監査証跡情報の取得

データベースが保持する監査証跡の情報を取得します。データベースの監査証跡表にデータ登録（監査証跡表へのデータロード）を行い，監査証跡表の「PRODUCT_INFO_1」列で監査対象のテーブルのルートアプリケーション情報を取得します。データベースの監査証跡の情報の取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。監査証跡表の出力例を次に示します。

出力例

HiRDBの監査証跡表の出力例を示します。

この例で出力されている「SQL_SOURCE」列は，オプションを指定することで出力できます。オプションを指定して出力する列については，使用するシステムの要件に合わせて設定してください。オプションの設定方法，および監査証跡表の詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。

7.6.3　性能解析トレースの取得

性能解析トレースファイルを取得します。性能解析トレースの収集方法，および出力内容の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.3.1　性能解析トレースファイルの収集方法」を参照してください。性能解析トレースの出力例を次に示します。

出力例

この例では，性能解析トレースのトレース取得レベル（PRFトレース取得レベル）を「詳細レベル」にしてセッションIDを出力しています。PRFトレース取得レベルについては，使用するシステムの要件に合わせて設定してください。また，PRFトレースレベルの変更方法については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cprflevel（PRFトレース取得レベルの表示と変更）」を参照してください。

7.6.4　情報の特定

アプリケーションのユーザログ，データベースの監査証跡表，および性能解析トレースの情報を突き合わせて，監査対象のテーブルにアクセスしたアプリケーションのログイン名，およびセッションIDを特定します。

データベースの監査証跡表に出力されている実行日時「EXEC_DATE,EXEC_TIME,EXEC_TIME_MICRO」の列の時間と，性能解析トレースの実行時間とを突き合せて，監査対象のテーブルにアクセスしたリクエストのルートアプリケーション情報を特定します。

1.で特定したルートアプリケーション情報と，アプリケーションのユーザログに出力されたルートアプリケーション情報とを突き合わせて，リクエストを実行したアプリケーションのログイン名およびセッションIDを特定します。

7.6.1，7.6.2，7.6.3の例では，セッションID「010D7AE670AEB55C022B6A4DA1C1E8B1CtEPmR9H」のリクエスト「10.209.15.130/1234/0x0000000000000001」（ルートアプリケーション情報）から，ユーザID「USER1」（ログイン名）でBeanの実行中（0x8405〜0x8406）に，データベースのテーブル「Table1」にINSERT文を実行したことが確認できます。

7.7　ルートアプリケーション情報をデータベースに設定する場合の注意事項

ルートアプリケーション情報をデータベースに設定するときに，データベースからエラーが返ってきた場合，KDJE54051-Eのメッセージが出力されます。この場合，リクエストの処理は続行されますが，データベース監査証跡にルートアプリケーション情報は出力されません。

KDJE54051-Eのメッセージが出力された場合は，Component Containerおよびデータベースの保守情報を取得して，保守員に連絡してください。また，KDJE54051-Eのメッセージはデータベースから初めてエラーが返ってきた時だけ出力され，それ以降はエラーが発生しても出力されません。そのため，ログを調査する場合などには注意してください。

8　運用管理コマンドによる稼働情報の出力

この章では，運用管理コマンドによる稼働情報の出力について説明します。

8.1　この章の構成

この章の構成を次の表に示します。

表8‒1　この章の構成（運用管理コマンドによる稼働情報の出力）

分類

タイトル

参照先

解説

運用管理コマンドによる稼働情報の出力の概要

8.2

サーバの稼働情報の出力方法

8.3

稼働情報監視で確認できる項目

8.4

注　「実装」，「運用」，「設定」，「注意事項」について，この機能固有の説明はありません。

8.2　運用管理コマンドによる稼働情報の出力の概要

Management Serverの運用管理コマンド（mngsvrutil）を使用して稼働情報を出力できます。稼働情報は，運用管理ドメイン単位でファイルに出力して確認できます。ファイルの形式は，CSV形式またはSNMP連携用形式です。

SNMP連携用形式のファイルは，SNMP Manager製品と連携する場合に使用できます。これらの製品で使用する場合は，SNMP連携用形式のファイルを，JP1/Cm2/ESA※などを使用してMIBオブジェクトに変換して使用します。

注※

JP1/Cm2/ESAはUNIXの場合に使用します。

稼働情報のファイルへの出力の流れを次の図に示します。なお，稼働情報をMIBオブジェクトに変換する場合は，アプリケーションサーバで提供する拡張MIBオブジェクト定義ファイルを使用します。

図8‒1　稼働情報のファイルへの出力の流れ

参考

なお，運用管理エージェントおよびManagement Serverの稼働状況については，運用管理コマンドまたはadminagentcheckコマンドを使用して確認できます。

ポイント

稼働情報の監視を行う場合，通常の運用では，稼働情報ファイルを使用した稼働監視を行ってください。稼働情報ファイルで取得できる情報より詳細な情報を取得したい場合だけ，運用管理コマンドを使用した稼働情報の監視を行ってください。稼働情報ファイルを使用した稼働情報の監視は，「3.2　稼働情報収集機能の概要」を参照してください。

8.3　サーバの稼働情報の出力方法

J2EEサーバ，またはバッチサーバの稼働情報は，運用管理コマンド（mngsvrutil）で監視できます。

稼働情報を監視するには，運用管理コマンド（mngsvrutil）にサブコマンド「get」を指定して実行します。これによって，J2EEサーバの稼働情報を標準出力に出力したり，CSV形式またはSNMP連携用形式のファイルに出力したりできます。

「get」の引数に稼働情報を出力する対象を指定できます。

J2EEサーバの稼働情報を取得する場合の実行形式と実行例を次に示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <J2EEサーバ名> get <ドメイン名または取得するカテゴリ>

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t J2EEServer1 get j2eeContainer

mngsvrutilコマンド，そのサブコマンド，および取得できる情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」およびマニュアル「アプリケーションサーバ リファレンス コマンド編」の「7.3　mngsvrutilコマンドのサブコマンドの詳細」を参照してください。

8.4　稼働情報監視で確認できる項目

稼働情報監視では，J2EEサーバ，およびバッチサーバの稼働状況が確認できます。

稼働情報として監視できる項目を次の表に示します。

表8‒2　稼働情報監視で表示できる項目（J2EEサーバの場合）

監視の対象

監視できる項目

J2EEサーバ

J2EEコンテナ

J2EEサーバ名

Naming Serviceホスト

Naming Serviceポート番号

コンテナ起動時刻

EJBコンテナ

コンテナ名

Webコンテナ

基本情報

コンテナ名

Webコンテナ起動時刻

管理用サーバのポート番号

Webサーバとの通信に使用するポート番号

Webサーバとの通信ソケットのバックログ設定上限値

稼働中（リクエスト処理の実行中）スレッド数設定上限値

最大同時実行スレッド数

デフォルトの実行待ちキューサイズ

稼働情報

WebサーバとWebコンテナとのコネクション数

稼働中スレッド数（HTTPサーバコネクタ）

Webコンテナ単位の実行待ちしているリクエスト数

同時実行可能スレッド数上限値

稼働スレッド数

デフォルトの実行待ちリクエスト数

デフォルトの実行待ちキューからあふれたリクエスト数

稼働中スレッド数（HTTPサーバ）

JavaVM

基本情報

JavaVM名

JavaVMバージョン

JavaVMの最大メモリ使用量

稼働情報

JavaVMの空きメモリ量

JavaVMの総メモリ容量

アプリケーション

J2EEアプリケーション

アプリケーション名（display name）

説明

デプロイされた時刻

EJBアプリケーション

EJB-JAR名

説明

Enterprise Bean（Stateful Session Bean）

基本情報

Enterprise Bean名

説明

Bean名（内部識別用）

Homeインタフェース名

Local Homeインタフェース名

Componentインタフェース名

Local Componentインタフェース名

EJBクラス名

トランザクションタイプ

同時接続最大値

同時実行最大値

非活性セッションのタイムアウト

実行中セッションのタイムアウト

稼働情報

現在の接続セッション数

実行中のセッション数

非活性セッション数

接続待ちセッション数

Homeインタフェース

Homeインタフェース名

レスポンス

EJBメソッド実行時間

Local Homeインタフェース

Homeインタフェース名

レスポンス

EJBメソッド実行時間

Componentインタフェース

Componentインタフェース名

レスポンス

EJBメソッド実行時間

Local Componentインタフェース

Componentインタフェース名

レスポンス

EJBメソッド実行時間

Enterprise Bean（Stateless Session Bean）

基本情報

Enterprise Bean名

説明

Bean名（内部識別用）

Homeインタフェース名

Local Homeインタフェース名

Componentインタフェース名

Local Componentインタフェース名

EJBクラス名

トランザクションタイプ

Beanインスタンスプール

稼働情報

接続待ちセッション数

Beanインスタンスプール現在値

使用中のSession Bean数

未使用のSession Bean数

Homeインタフェース

Stateful Session Beanと同じ

Local Homeインタフェース

Stateful Session Beanと同じ

Componentインタフェース

Stateful Session Beanと同じ

Local Componentインタフェース

Stateful Session Beanと同じ

Enterprise Bean（Entity Bean）

基本情報

Enterprise Bean名

説明

Bean名（内部識別用）

Homeインタフェース名

Local Homeインタフェース名

Componentインタフェース名

Local Componentインタフェース名

EJBクラス名

EntityBeanの永続化タイプ

EntityBeanのキャッシュモデル

同時接続最大値

Beanインスタンスプール

接続タイムアウト

稼働情報

現在の接続セッション数

接続待ちセッション数

Beanインスタンスプール現在値

使用中のEntity Bean数

未使用のEntity Bean数

Homeインタフェース

Stateful Session Beanと同じ

Local Homeインタフェース

Stateful Session Beanと同じ

Componentインタフェース

Stateful Session Beanと同じ

Local Componentインタフェース

Stateful Session Beanと同じ

Enterprise Bean（Message-driven Bean）

基本情報

Enterprise Bean名

説明

Bean名（内部識別用）

EJBクラス名

トランザクションタイプ

デスティネーションタイプ※1

Beanインスタンスプール

稼働情報

現在の接続セッション数

Beanインスタンスプール現在値

EJBメソッド実行時間

Webアプリケーション

基本情報

コンテキストルート

占有スレッド数

最大同時実行スレッド数

Webアプリケーション単位の実行待ちキューサイズ

稼働情報

有効なセッション数

同時実行可能スレッド数上限値

稼働スレッド数

Webアプリケーション単位の実行待ちリクエスト数

Webアプリケーション単位の実行待ちキューからあふれたリクエスト数

サーブレット

サーブレット名

サーブレットの実装クラス名

サーブレット実行回数

サーブレット失敗回数

サーブレット実行時間

出力データサイズ

URL

URL

URL呼び出し回数

URL呼び出し失敗回数

URL実行時間

出力データサイズ

リソース

データソース（SimpleJTA）

基本情報

リソース名

リソースタイプ

説明

認証タイプ

ログインタイムアウト

ユーザID

コネクションプール

稼働情報

リソース名

プール現在値（総数）

使用中のコネクション数

未使用のコネクション数

データソース（FullJTA）

基本情報

リソース名

リソースタイプ

説明

ログインタイムアウト

ユーザID

コネクションプール

稼働情報

リソース名

プール現在値

使用中のコネクション数

未使用のコネクション数

getConnection()メソッドの実行時間

getXAConnection()メソッドの実行時間

getConnection()メソッドの失敗回数

ConnectionでFATALエラーが発生した回数

リソースアダプタ

基本情報

リソース名

リソースタイプ

説明

リソースアダプタ提供ベンダ名

準拠するJCA仕様のバージョン

リソースアダプタのバージョン

接続先EISのタイプ

ConnectionFactoryのインタフェース名

ConnectionFactoryの実装クラス名

ManagedConnectionFactoryの実装クラス名

Connectionのインタフェース名

Connectionの実装クラス名

トランザクションサポートモデル

設定プロパティ情報

ユーザID

コネクションプール※2

稼働情報

リソース名

プール現在値（総数）※2

使用中のコネクション数※2

未使用のコネクション数※2

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行回数※2

ManagedConnectionのgetConnection()メソッドの実行回数※2

ManagedConnectionのcleanup()メソッドの実行回数※2

ManagedConnectionのdestroy()メソッドの実行回数※2

ConnectionManagerのallocateConnection()メソッドの実行時間※2

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行時間※2

ConnectionManagerのallocateConnection()メソッドの失敗回数※2

ManagedConnectionでFATALエラーが発生した回数※2

サービス

トランザクション

基本情報

サービス名

サービスタイプ

トランザクションタイムアウトデフォルト値

稼働情報

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

平均トランザクション時間

注　使用する機能（最大同時実行スレッド数制御機能を使用するかどうか），オプションの設定，使用するリソースの違いなどによっては表示されない項目があります。

注※1　Connector 1.5仕様に準拠したリソースアダプタを使用した場合は，「Other」が出力されます。

注※2　Reliable Messagingを使用している場合，これらの項目はReliable Messaging側の稼働情報として出力されます。Management Serverの稼働情報監視では確認できません。

表8‒3　稼働情報監視で表示できる項目（バッチサーバの場合）

監視の対象

監視できる項目

バッチサーバ

J2EEコンテナ

バッチサーバ名

Naming Serviceホスト

Naming Serviceポート番号

コンテナ起動時刻

JavaVM

基本情報

JavaVM名

JavaVMバージョン

JavaVMの最大メモリ使用量

稼働情報

JavaVMの空きメモリ量

JavaVMの総メモリ容量

リソース

データソース（SimpleJTA）

基本情報

リソース名

リソースタイプ

説明

認証タイプ

ログインタイムアウト

ユーザID

コネクションプール

稼働情報

リソース名

プール現在値（総数）

使用中のコネクション数

未使用のコネクション数

データソース（FullJTA）

基本情報

リソース名

リソースタイプ

説明

ログインタイムアウト

ユーザID

コネクションプール

稼働情報

リソース名

プール現在値

使用中のコネクション数

未使用のコネクション数

getConnection()メソッドの実行時間

getXAConnection()メソッドの実行時間

getConnection()メソッドの失敗回数

ConnectionでFATALエラーが発生した回数

リソースアダプタ

基本情報

リソース名

リソースタイプ

説明

リソースアダプタ提供ベンダ名

準拠するJCA仕様のバージョン

リソースアダプタのバージョン

接続先EISのタイプ

ConnectionFactoryのインタフェース名

ConnectionFactoryの実装クラス名

ManagedConnectionFactoryの実装クラス名

Connectionのインタフェース名

Connectionの実装クラス名

トランザクションサポートモデル

設定プロパティ情報

ユーザID

コネクションプール※

稼働情報

リソース名

プール現在値（総数）※

使用中のコネクション数※

未使用のコネクション数※

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行回数※

ManagedConnectionのgetConnection()メソッドの実行回数※

ManagedConnectionのcleanup()メソッドの実行回数※

ManagedConnectionのdestroy()メソッドの実行回数※

ConnectionManagerのallocateConnection()メソッドの実行時間※

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行時間※

ConnectionManagerのallocateConnection()メソッドの失敗回数※

ManagedConnectionでFATALエラーが発生した回数※

サービス

トランザクション

基本情報

サービス名

サービスタイプ

トランザクションタイムアウトデフォルト値

稼働情報

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

平均トランザクション時間

注　使用する機能（最大同時実行スレッド数制御機能を使用するかどうか），オプションの設定，使用するリソースの違いなどによっては表示されない項目があります。

注※　Reliable Messagingを使用している場合，これらの項目はReliable Messaging側の稼働情報として出力されます。Management Serverの稼働情報監視では確認できません。

ポイント

統計情報のサンプリング時間の設定

稼働情報を表示する場合，統計情報のサンプリング時間を指定してください。

サンプリング時間を指定すると，画面を表示した時刻または更新した時刻からさかのぼって，サンプリング時間（これをN秒といいます）に指定した時間内のデータを統計情報として表示できます。「N秒ピーク」や「N秒平均値」とはこの統計情報です。また，最大値，最小値などは，サンプリングを開始した以降のデータの中から値が抽出されます。

運用管理コマンド（mngsvrutil）にサブコマンド「set」を指定してサンプリング時間を設定できます。詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「7.3　mngsvrutilコマンドのサブコマンドの詳細」を参照してください。

9　Managementイベントの通知とManagementアクションによる処理の自動実行

この章では，Managementイベントによる処理の自動実行について説明します。

9.1　この章の構成

この章の構成を次の表に示します。

表9‒1　この章の構成（Managementイベントの通知とManagementアクションによる処理の自動実行）

分類

タイトル

参照先

解説

Managementイベントの通知とManagementアクションの概要

9.2

Managementアクションの実行制御とは

9.3

設定

Managementイベントによる処理の自動実行の設定

9.4

注　「実装」，「運用」，「注意事項」について，この機能固有の説明はありません。

9.2　Managementイベントの通知とManagementアクションの概要

Managementイベントとは，運用管理ドメイン内のJ2EEサーバ，またはバッチサーバで発生する障害やリソース枯渇などの事象をManagement Serverに通知するためのイベントです。J2EEサーバ，またはバッチサーバが稼働中に出力するメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。このアクションをManagementアクションといいます。

注意事項

J2EEサーバ，およびバッチサーバが出力するメッセージのうち，次に示すメッセージはManagementイベントの発行対象外となります。

KDJE90001-E

KDJE90002-E

KDJE90003-E

KDJE90005-W

KDJE90006-W

KDJE90009-W

メッセージの詳細については，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」を参照してください。

Managementイベントが発行されてから，Management ServerでManagementアクションが実行されるまでの流れを次の図に示します。

図9‒1　ManagementイベントとManagementアクション

この例では，リソース枯渇監視機能で設定したしきい値を超えた場合に出力されるメッセージを契機に，Managementイベントを実行しています。図中の処理の流れについて説明します。

監視しているリソースで設定しているしきい値を超えると，Managementイベントが発行されます。

Mnagementイベントは，Management Serverに通知されます。

Management Server内で定義されたManagementアクションの定義に従って，処理が自動的に実行されます。

Managementアクションの定義では，J2EEサーバまたはバッチサーバから挙がるManagementイベントに対応したアクションを定義します。Managementアクションはあらかじめ定義しておく必要があります。

なお，リソース枯渇監視機能を使用してメモリ監視をしている場合，FullGCの予兆検知ができます。メモリ監視中に，FullGCの予兆を検知すると，その情報はManagementイベントとしてManagement Serverに通知されます。このとき，ManagementイベントでFullGCが通知されたときの動作として，J2EEサーバまたはバッチサーバでサービスを閉塞して再起動するアクションが定義されていると，J2EEサーバまたはバッチサーバに対してこのアクションが自動的に実行されます。これによって，リクエスト処理の停止を回避できるようになります。

9.3　Managementアクションの実行制御とは

ここでは，Managementアクションの実行制御について説明します。

同一のManagementアクションの実行を一定時間抑止したり，同時実行数の上限を設定したりすることによって，Managementアクションの実行を制御できます。これによって，同一のManagementアクションが重複して実行されたり，Managementアクションの実行が集中したりすることを防ぎます。

なお，Managementアクションの実行とは，Managementアクションとして指定されたコマンドを実行してから，コマンドが終了またはタイムアウトするまでのことを指します。

Managementアクションの実行制御方式を次の表に示します。

表9‒2　Managementアクションの実行制御方式

制御方式

説明

抑止時間制御

Managementアクションの実行後に，同一のManagementアクションが実行されるのを一定時間抑止します。これによって，一定時間内に発生するManagementイベントに対して実行される，Managementアクションが集約されます。

同時実行数制御

同一のManagementアクションの同時実行数を制限します。これによって，Managementアクション実行中に，同一のManagementアクションが過度に重複して実行されることを防ぎます。同時実行数はManagementアクションIDごとに適用されます。

なお，上記二つの方式を同時に指定した場合，同時実行数の上限値に達していないときでも，抑止時間内のManagementアクションの実行は抑止されます。

Managementアクションの制御方式について例を使って説明します。

設定例1

次の内容が設定されていることとします。

Managementアクションの実行時間：5秒

抑止時間：10秒

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図9‒2　Managementアクションの制御例1

この図の例では，アクション1のあと，10秒間は同一アクションの実行を抑止するため，アクション2およびアクション3の実行は抑止されます。抑止時間が過ぎたあと，アクション4が実行できるようになります。

設定例2

次の内容が設定されていることとします。

Managementアクションの実行時間：5秒

抑止時間：0秒（抑止しない）

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図9‒3　Managementアクションの制御例2

この図の例では，抑止時間の制限がないため，アクション1の実行後に，アクション2が実行されます。ただし，この時点で同一Managementアクションの同時実行数の上限値に達しているため，アクション3の実行は抑止されます。アクション1の実行が終了したあと，アクション4を実行できるようになります。アクション5，6については，アクション2，3と同様になります。

設定例3

次の内容が設定されていることとします。

Managementアクションの実行時間：12秒

抑止時間：3秒

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図9‒4　Managementアクションの制御例3

この図の例では，アクション1の実行後，3秒間は同一のManagementアクションの実行が抑止されるため，アクション2の実行は抑止されます。アクション3の実行後，同一Managementアクションの同時実行数の上限値に達したため，アクション4の実行が抑止されます。アクション1の実行終了後，アクション5を実行できようになります。

9.4　Managementイベントによる処理の自動実行の設定

この節では，Managementイベントによる処理の自動実行を行うための設定方法について説明します。

Managementイベントは，運用管理ドメイン内のJ2EEサーバ，またはバッチサーバで発生する障害やリソース枯渇などの事象をManagement Serverに通知するためのイベントです。J2EEサーバ，およびバッチサーバが稼働中に出力するすべてのメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。このアクションをManagementアクションといいます。

例えば，リソース枯渇監視機能を使用してメモリの使用状態を監視している場合に，しきい値を超えたらアラートを発生させてメッセージを出力し，FullGCが発生する前に，Managementイベントを通知するようにします。また，J2EEサーバまたはバッチサーバでサービスを閉塞して再起動するというManagementアクションを定義しておくことで，FullGCの予兆を検知し，自動的にアクションが実行されて，リクエスト処理の停止を回避できるようになります。

Managementイベントを使用して障害などの事象を検知し，Managementイベントに対応する動作をManagementアクションとして定義しておくことで，障害を回避するための対処など，発生した事象に対する処理を自動的に実行できるようになります。

9.4.1　Managementイベントによる処理の自動実行の設定手順

Managementイベントによる処理の自動実行の設定手順を次の図に示します。

図9‒5　Managementイベントによる処理の自動実行の設定手順

図中の1.〜5.について説明します。

実行環境でManagementイベント発行の設定をします。

Managementイベントの発行を有効にして，Managementイベント発行時の動作を設定します。詳細については，「9.4.2　実行環境での設定」を参照してください。

Managementイベント発行用メッセージIDリストファイルを設定します。

リストファイルで，Managementイベント発行対象となるメッセージを指定します。詳細については，「9.4.3　Managementイベント発行用メッセージIDリストファイルの設定」を参照してください。

Managementイベント発行機能を利用する各機能の設定をします。

Managementイベント発行機能を利用して，Management ServerにManagementイベントを通知する機能の設定をします。

次に，設定したManagementイベントに対応するManagementアクションを実行するための設定をします。詳細については，「9.4.4　Managementイベント発行機能を利用する各機能の設定」を参照してください。

Managementアクション実行用プロパティファイルを設定します。

プロパティファイルで，Managementアクションの定義，メッセージIDとManagementアクションとのマッピングなどをします。詳細については，「9.4.5　Managementアクション実行用プロパティファイルの設定」を参照してください。

Managementアクション実行コマンドの設定をします。

Managementアクションとして実行するコマンドを記述するコマンドファイル（バッチファイルまたはシェルスクリプトファイル）を作成します。詳細については，「9.4.6　Managementアクション実行コマンドの設定」を参照してください。

9.4.2　実行環境での設定

Managementイベントを発行する場合，J2EEサーバの設定が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Managementイベントの発行の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのManagementイベントの発行の定義について次の表に示します。

表9‒3　簡易構築定義ファイルでのManagementイベントの発行の定義（J2EEサーバ）

項目

指定するパラメタ

設定内容

Managementイベント発行の有効化

ejbserver.manager.agent.MEventAgent.enabled

Managementイベントの発行を有効にするかどうかを指定します。Managementイベントを発行するには，「true」を指定します。

Managementイベント発行時の動作の設定

manager.mevent.send.timeout

Managementイベントの送信タイムアウトの時間（秒）を指定します。

manager.mevent.retry.limit

Managementイベントの再送期限を指定します。

manager.mevent.retry.interval

Managementイベントの再送間隔（秒）を指定します。

manager.mevent.send.max

Managementイベントの同時発行最大数を指定します。

manager.mevent.message_id.list

メッセージIDリストファイルのパスを指定します。

manager.mevent.sender.bind.host

ローカルアドレスの固定の有無を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

9.4.3　Managementイベント発行用メッセージIDリストファイルの設定

Managementイベントを発行したいメッセージのメッセージIDは，Managementイベント発行用メッセージIDリストファイルに記述します。Managementイベント発行用メッセージIDリストファイルの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.12　Managementイベント発行用メッセージIDリストファイル」を参照してください。

(1)　ファイルの指定内容

Managementイベント発行用メッセージIDリストファイルに，Managementイベントを発行したいメッセージのメッセージIDを記述してください。

なお，Managementイベントを発行できるのは，J2EEサーバ，およびバッチサーバが稼働中に出力するメッセージです。起動処理中，停止処理中のメッセージおよびユーザログは，Managementイベント発行の対象外です。

Managementイベント発行用メッセージIDリストファイルの設定を省略すると，デフォルトのメッセージIDでManagementイベントを発行します。デフォルトの設定のままで利用する場合には，Managementイベント発行用メッセージIDリストファイルは設定不要です。デフォルトのメッセージIDについては，Managementイベント発行用メッセージIDリストファイルの説明を参照してください。Managementイベント発行用メッセージIDリストファイルについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.12　Managementイベント発行用メッセージIDリストファイル」を参照してください。

(2)　ファイルの格納場所

Managementイベント発行用メッセージIDリストファイルのサンプルは，次の場所に格納されています。サンプルのファイルをコピーして，リストファイルを作成してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥config¥templates¥mevent.midlist.conf

UNIXの場合

/opt/Cosminexus/manager/config/templates/mevent.midlist.conf

作成したリストファイルのパスは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，manager.mevent.message_id.listパラメタでリストファイルのパスを指定してください。

(3)　ファイルの作成例

Managementイベント発行用メッセージIDリストファイルの作成例を次に示します。

# Monitoring of resources
# : Status of memory(Java Heap)
KDJE34500-W

# : Number of file descriptors
KDJE34520-W

# : Number of threads
KDJE34540-W
# : Number of thread dump files
-KDJE34580-W
KDJE34581-E

# : Number of HTTP requests in queue
-KDJE34621-W

# : Number of HTTP sessions
KDJE34640-W

# : Status of connection pool
-KDJE34660-W
KDJE34661-W

# Monitoring of execution time of user program
KDJE52702-W
KDJE52703-W
KDJE52705-W
KDJE52713-E

メッセージIDの前に「+」を記述した場合，そのメッセージはManagementイベントを発行します。「-」を記述した場合，そのメッセージはManagementイベントを発行しません。「+」または「-」を省略した場合，そのメッセージはManagementイベントを発行します。

9.4.4　Managementイベント発行機能を利用する各機能の設定

Managementイベントを発行する機能の設定をしてください。

ここでは，例として，次の機能でManagementイベントを発行させるために必要な設定について説明します。

リソース枯渇監視機能

J2EEアプリケーション実行時間の監視機能

(1)　リソース枯渇監視の設定

リソースの監視間隔やしきい値を指定してリソースを監視し，しきい値を超えた場合にManagementイベントが発行されるように設定します。

リソース枯渇監視の機能および設定については，「4.3　リソース枯渇監視機能とリソース枯渇監視情報の出力」を参照してください。

(2)　J2EEアプリケーション実行時間の監視の設定

リクエストの実行時間を監視して，無限ループなどの障害が発生した場合にManagementイベントが発行されるようにします。J2EEアプリケーションの実行時間の監視機能および設定については，「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。

なお，メソッドタイムアウト機能の対象となる，Webアプリケーションのリクエスト処理やEJBのメソッド呼び出し処理にもタイムアウトを設定します。設定方法については，「5.3.8　実装時の注意事項」を参照してください。

9.4.5　Managementアクション実行用プロパティファイルの設定

Managementアクションの定義，メッセージIDとManagementアクションとのマッピングなどは，Managementアクション実行用プロパティファイル（maction.properties）に定義します。maction.propertiesについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.10　maction.properties（Managementアクション実行用プロパティファイル）」を参照してください。

(1)　ファイルの格納場所

maction.propertiesの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥config¥maction.properties

UNIXの場合

/opt/Cosminexus/manager/config/maction.properties

(2)　ファイルの設定例

Windowsの場合のManagementアクション実行用プロパティファイルの設定例を次に示します。

# Managementアクションの定義
maction.restart.command=c¥:¥¥tmp¥¥command1.bat
maction.restart.timeout=12
maction.restart.timeout.forced_stop=true
maction.restart.exclusive_time=60
maction.restart.max_executable_actions=1

# メッセージIDとManagementアクションのマッピング
maction.message.KDJE11111-E.mactions=restart
maction.message.KDJE22222-E.mactions=restart

# 論理サーバとManagementアクションのマッピング
maction.server.j2ee1.mactions=restart
maction.server.j2ee2.mactions=restart
maction.server.j2eeClstr1.mactions=restart

この設定例では，Managementアクションを識別するID（ManagementアクションID）として，「restart」を定義しています。「restart」のManagementアクションの動作および設定について説明します。

Managementアクション実行コマンドとして「command1.bat」というコマンドファイルを実行します。

Managementアクション実行コマンドのタイムアウトは，「12」秒とします。

Managementアクション実行コマンドのタイムアウトが発生すると，コマンドを強制終了します。

Managementアクションの抑止時間は「60」秒，Managementアクションの同時実行数は，「1」とします。※

J2EEサーバ「j2ee1」，「j2ee2」および「j2eeClstr1」から，メッセージ「KDJE11111-E」と「KDJE22222-E」が出力された場合に，このManagementアクションを実行します。

注※

Managementアクションは，ManagementアクションIDで区別され，複数のサーバや異なるメッセージIDに対して同一のManagementアクションを実行できます。抑止時間や同時実行数を設定してManagementアクションの実行を制御することで，Managementアクションの集約や重複実行の抑止ができます。実行制御については，「9.3　Managementアクションの実行制御とは」を参照してください。

(3)　注意事項

Managementアクション実行用プロパティファイルに関する注意事項を次に示します。

プロパティの優先順位

次に示すキーで指定する論理サーバやクラスタには，「J2EEサーバ ＜ J2EEサーバクラスタ ＜ サービスユニット ＜ 物理ティア」という包含関係があります。

maction.server.<論理サーバ名>.mactions

maction.unit.<Webシステム名>.<サービスユニット名>.mactions

maction.tier.<Webシステム名>.<物理ティア種別名>.mactions

このため，J2EEサーバクラスタとそのJ2EEサーバクラスタの構成要素となるJ2EEサーバのように，包含関係を持つ論理サーバそれぞれに対して別々のManagementアクションを定義した場合，次に示す優先順位で，どれか一つのManagementアクションを実行します。

Managementイベントを発行したJ2EEサーバ

Managementイベントを発行したJ2EEサーバを含むJ2EEサーバクラスタ

Managementイベントを発行したJ2EEサーバを含むサービスユニット

Managementイベントを発行したJ2EEサーバを含む物理ティア

なお，Webシステム，サービスユニットや物理ティアは，Smart Composer機能を使用してシステムを構築する場合の概念です。Smart Composer機能については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「1.1.3　Smart Composer機能とは」を参照してください。

Managementアクションの指定順序

次に示す二つのキーでManagementアクションの指定順序が異なる場合は，maction.message.<メッセージID>.mactionsキーでの指定順序を優先します。

maction.message.<メッセージID>.mactions

メッセージIDとManagementアクションとをマッピングするキーです。

maction.server.<論理サーバ名>.mactions

論理サーバとManagementアクションとをマッピングするキーです。

（例）

この例では，「act1」が優先されます。

maction.message.KDJE99999-E.mactions=act1,act2

maction.server.J2EE01.mactions=act3,act2,act1

9.4.6　Managementアクション実行コマンドの設定

Managementアクションとして実行するコマンドは，コマンドファイル（バッチファイルまたはシェルスクリプトファイル）に記述できます。必要に応じて，コマンドファイルを作成してください。なお，バッチサーバの場合，CTMによるリクエストのスケジューリングは使用できないため，CTMに関する記述は該当しません。

ここでは，コマンドファイルで使用できる環境変数と，コマンドファイルのサンプルについて説明します。

(1)　コマンドファイルで使用できる環境変数

コマンドファイルでは，次の表に示す環境変数を使用できます。

表9‒4　Managementアクション実行コマンドのコマンドファイルで使用できる環境変数

環境変数

説明

COSMI_MNG_MACT_LSNAME

Managementイベントを発行した論理サーバ名。

COSMI_MNG_MACT_HOST

Managementイベントを発行した論理サーバのホスト名。

COSMI_MNG_MACT_MSG_ID

Managementイベントで通知されたメッセージID。

COSMI_MNG_MACT_MSG_TEXT

Managementイベントで通知されたメッセージテキスト。

COSMI_MNG_MACT_CTM

Managementイベントを発行した論理サーバに設定された論理CTM名。

COSMI_MNG_MACT_WEBSYSTEM

Managementイベントを発行した論理サーバが所属するWebシステム名。

COSMI_MNG_MACT_UNIT

Managementイベントを発行した論理サーバが所属するサービスユニット名。

COSMI_MNG_MACT_TIER

Managementイベントを発行した論理サーバが所属する物理ティア種別。

COSMI_MNG_MACT_OPT<N>

Managementイベントで通知されたオプション文字列。オプション文字列としてメッセージの埋め字が使用されます。Nは，0以上の整数であり，オプション文字列の1番目を表す環境変数は「COSMI_MNG_MACT_OPT0」となります。

設定される文字列の詳細については，Managementイベント発行の対象となるメッセージのメッセージテキスト中の可変値に表示される情報を参照してください。

COSMI_MNG_MACT_MNGSVR_PORT

Management ServerのHTTPポート番号。

COSMI_MNG_MACT_RNAME

Managementイベントを発行した論理サーバの実サーバ名。

COSMI_MNG_MACT_NS_HOSTPORT

Managementイベントを発行した論理サーバが使用するネーミングサービスのホスト名とポート番号。例えば，ホスト名が「HostA」でポート番号が「900」の場合には，「HostA:900」となります。

(2)　コマンドファイルのサンプル

コマンドファイルのサンプルが提供されていますので，サンプルを参考にしてコマンドファイルを作成してください。サンプルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥examples¥maction

UNIXの場合

/opt/Cosminexus/manager/examples/maction

なお，サンプルを使用する場合は，mngsvrutilコマンドの引数（-m，-u，-pオプションなど）やログファイルの格納先を環境に合わせて適宜変更してください。

(a)　Managementイベント発行サーバを再起動するサンプル

サンプルのファイル名

Windowsの場合：mActionSample_restartServer.bat

UNIXの場合：mActionSample_restartServer.sh

サンプルの動作

Managementイベントを発行した論理サーバを再起動します。

このサンプルは，リソース枯渇監視機能でManagementイベントを発行する場合に使用できます。

リソース枯渇監視機能では，JavaVMでのメモリの使用状況を監視し，設定されているしきい値を超えて，FullGCが発生しそうな場合にメッセージを出力します。

Managementイベント発行機能は，出力されたメッセージに対応したManagementイベントを発行したあとManagementアクションを実行し，Managementイベントを発行したJ2EEサーバを再起動します。

Managementイベントを発行したJ2EEサーバを停止することで，J2EEアプリケーションを閉塞できます。また，J2EEサーバがCTMによってリクエストを負荷分散させている場合は，J2EEサーバを停止することで，新規リクエストをほかのJ2EEサーバに分散できます。

Managementイベント発行サーバを再起動するサンプルを次に示します。

Windowsの場合

　　　（省略）
　　　　：
rem Management action sample for restart server.

setlocal

set LSNAME=%COSMI_MNG_MACT_LSNAME%
set MSGID=%COSMI_MNG_MACT_MSG_ID%

set CJCLDELLOG=%COSMINEXUS_HOME%¥CC¥client¥bin¥cjcldellog.bat
set LOG_ROOT_DIR=%SystemDrive%¥<MyLogDir>
if not exist "%LOG_ROOT_DIR%" mkdir "%LOG_ROOT_DIR%"
call "%CJCLDELLOG%" -t 30d -f "%LOG_ROOT_DIR%"
set LOG_DIR=%LOG_ROOT_DIR%¥%date:/=%
if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"
set LOG=%LOG_DIR%¥%time::=%_%LSNAME%_%MSGID%.txt

echo %0 > "%LOG%"

set MNGSVR=localhost:%COSMI_MNG_MACT_MNGSVR_PORT%
set UID=<User-id>
set PWD=<Password>

echo mngsvrutil.exe -m %MNGSVR% -u %UID% -p %PWD% -t %LSNAME% -s stop server >> "%LOG%" 2>&1
mngsvrutil.exe -m %MNGSVR% -u %UID% -p %PWD% -t %LSNAME% -s stop server >> "%LOG%" 2>&1
set RET=%ERRORLEVEL%
echo %RET% >> "%LOG%"

if not %RET% == 0 goto END
echo mngsvrutil.exe -m %MNGSVR% -u %UID% -p %PWD% -t %LSNAME% -s start server >> "%LOG%" 2>&1
mngsvrutil.exe -m %MNGSVR% -u %UID% -p %PWD% -t %LSNAME% -s start server >> "%LOG%" 2>&1
set RET=%ERRORLEVEL%
echo %RET% >> "%LOG%"

:END
exit %RET%

UNIXの場合

　　　（省略）
　　　　：
# Management action sample for restart server.

LSNAME=${COSMI_MNG_MACT_LSNAME}
MSGID=${COSMI_MNG_MACT_MSG_ID}

LOG_ROOT_DIR=/tmp/<MyLogDir>
if [ ! -d ${LOG_ROOT_DIR} ]; then
  /bin/mkdir ${LOG_ROOT_DIR}
fi
/usr/bin/find ${LOG_ROOT_DIR}/* -depth -mtime +30 | /usr/bin/xargs /bin/rm -fr
LOG_DIR=${LOG_ROOT_DIR}/`/bin/date +%y%m%d`
if [ ! -d ${LOG_DIR} ]; then
  /bin/mkdir ${LOG_DIR}
fi
LOG=${LOG_DIR}/`/bin/date +%H%M%S`_${LSNAME}_${MSGID}.txt

echo $0 > "${LOG}"

MNGSVR=localhost:${COSMI_MNG_MACT_MNGSVR_PORT}
USERID=<User-id>
PASSWD=<Password>

echo ./mngsvrutil -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -t ${LSNAME} -s stop server >> "${LOG}" 2>&1
./mngsvrutil -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -t ${LSNAME} -s stop server >> "${LOG}" 2>&1
RET=$?
echo ${RET} >> "${LOG}"

if [ $RET -eq 0 ]; then
  echo ./mngsvrutil -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -t ${LSNAME} -s start server >> "${LOG}" 2>&1
  ./mngsvrutil -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -t ${LSNAME} -s start server >> "${LOG}" 2>&1
  RET=$?
  echo ${RET} >> "${LOG}"
fi

exit ${RET}

(b)　Managementイベント発行サーバの所属サービスユニットを閉塞するサンプル

Managementイベント発行サーバの所属サービスユニットを閉塞するサンプルが提供されていますので，サンプルを参考にして作成してください。サンプルのファイル名と動作を次に示します。

サンプルのファイル名

Windowsの場合：mActionSample_closeUnit.bat

UNIXの場合：mActionSample_closeUnit.sh

サンプルの動作

サービスユニットに所属するJ2EEサーバにリソース枯渇などの障害が発生した場合に，Managementイベントを発行したサーバを閉塞します。

Managementイベント発行サーバの所属サービスユニットを閉塞するサンプルを次に示します。

Windowsの場合

　　　（省略）
　　　　：
rem Management action sample for close unit.

setlocal

set LSNAME=%COSMI_MNG_MACT_LSNAME%
set MSGID=%COSMI_MNG_MACT_MSG_ID%
set WEBSYSTEM=%COSMI_MNG_MACT_WEBSYSTEM%
set UNIT=%COSMI_MNG_MACT_UNIT%

set CJCLDELLOG=%COSMINEXUS_HOME%¥CC¥client¥bin¥cjcldellog.bat
set LOG_ROOT_DIR=%SystemDrive%¥<MyLogDir>
if not exist "%LOG_ROOT_DIR%" mkdir "%LOG_ROOT_DIR%"
call "%CJCLDELLOG%" -t 30d -f "%LOG_ROOT_DIR%"
set LOG_DIR=%LOG_ROOT_DIR%¥%date:/=%
if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"
set LOG=%LOG_DIR%¥%time::=%_%LSNAME%_%MSGID%.txt

echo %0 > "%LOG%"

if "%WEBSYSTEM%" == "" goto :ERR
if "%UNIT%" == "" goto :ERR

set MNGSVR=localhost:%COSMI_MNG_MACT_MNGSVR_PORT%
set UID=<User-id>
set PWD=<Password>

echo cmx_stop_target.exe -m %MNGSVR% -u %UID% -p %PWD% -mode ALL -s %WEBSYSTEM% -unit %UNIT% >> "%LOG%" 2>&1
cmx_stop_target.exe -m %MNGSVR% -u %UID% -p %PWD% -mode ALL -s %WEBSYSTEM% -unit %UNIT% >> "%LOG%" 2>&1
set RET=%ERRORLEVEL%
echo %RET% >> "%LOG%"
goto :END

:ERR
set RET=2

:END
exit %RET%

UNIXの場合

　　　（省略）
　　　　：
# Management action sample for close unit.

LSNAME=${COSMI_MNG_MACT_LSNAME}
MSGID=${COSMI_MNG_MACT_MSG_ID}
WEBSYSTEM=${COSMI_MNG_MACT_WEBSYSTEM}
UNIT=${COSMI_MNG_MACT_UNIT}

LOG_ROOT_DIR=/tmp/<MyLogDir>
if [ ! -d ${LOG_ROOT_DIR} ]; then
  /bin/mkdir ${LOG_ROOT_DIR}
fi
/usr/bin/find ${LOG_ROOT_DIR} -depth -mtime +30 -mindepth 1 -exec /bin/rm -fr {} ¥;
LOG_DIR=${LOG_ROOT_DIR}/`/bin/date +%y%m%d`
if [ ! -d ${LOG_DIR} ]; then
  /bin/mkdir ${LOG_DIR}
fi
LOG=${LOG_DIR}/`/bin/date +%H%M%S`_${LSNAME}_${MSGID}.txt

echo $0 > "${LOG}"

if [ "${WEBSYSTEM}" = "" -o "${UNIT}" = "" ]; then
  exit 2
fi

MNGSVR=localhost:${COSMI_MNG_MACT_MNGSVR_PORT}
USERID=<User-id>
PASSWD=<Password>

echo ./cmx_stop_target -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -mode ALL -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
./cmx_stop_target -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -mode ALL -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
RET=$?
echo ${RET} >> "${LOG}"

exit ${RET}

(3)　Managementアクション実行コマンドの動作

Managementアクション実行コマンドの動作を次に示します。

Managementアクション実行コマンドから出力される標準出力，標準エラー出力は，Management Serverでは取得しません。このため，コマンドの標準出力，標準エラー出力を取得する場合は，コマンドの中でファイルに出力する必要があります。

Managementアクション実行コマンドはManagement Serverによって実行されます。実行ユーザは，Management Serverの実行ユーザになります。また，環境変数はManagement Serverに設定された環境変数を引き継ぎます。

Managementアクション実行コマンドのワーキングディレクトリは，<Application Serverのインストールディレクトリ>¥manager¥bin（Windowsの場合），または/opt/Cosminexus/manager/bin（UNIXの場合）です。

10　CTMの稼働統計情報の収集

この章では，CTMが提供するプロセス群（CTMデーモンやCTMレギュレータなど）が出力する稼働統計情報を使用した，CTMの処理性能の監視について説明します。

10.1　この章の構成

この章の構成を次の表に示します。

表10‒1　この章の構成（CTMの稼働統計情報の収集）

分類

タイトル

参照先

解説

CTMの稼働統計情報の概要

10.2

稼働統計情報ファイルの利用方法

10.3

注　「実装」，「設定」，「運用」，「注意事項」について，この機能固有の説明はありません。

10.2　CTMの稼働統計情報の概要

CTMが提供するCTMデーモンやCTMレギュレータなどのプロセス群では，リクエストを処理する過程で稼働統計情報をバッファに出力します。

このバッファの情報は，CTM単位にホスト上のファイル（稼働統計情報ファイル）に一定間隔で出力されます。バイナリ形式の稼働統計情報ファイルから，CSV形式などのテキストファイル（稼働統計出力ファイル）に変換したファイルを使用して，CTMの処理性能を解析します。

CTMでは，CTMでリクエストを受け付けてからJ2EEサーバにリクエストを送信するまで，およびその処理結果がCTMに返却されるまでの一連の処理の過程で稼働統計情報を出力します。稼働統計情報を基に，CTMが提供するプロセス群の性能処理性能を解析したり，稼働状態を確認したりしてシステムの安定化を図ることができます。

CTMの稼働統計情報の収集の概要を次の図に示します。

図10‒1　CTMの稼働統計情報の収集の概要

性能に関する処理のCTMの稼働統計情報は，CTMが提供するプロセス群によって，CTM単位に，ホスト上のファイル（稼働統計情報ファイル）に出力されます。

Management Serverを利用して運用している場合，各ホストに出力された稼働統計情報ファイルの内容は，Management Serverのコマンドによって，運用管理サーバに一括収集できます。なお，CTMが出力した稼働統計情報ファイルは，バイナリ形式のファイルです。Management Serverでは，運用管理エージェントに指示を出し，稼働統計情報ファイルをテキスト（CSV）形式のファイルに編集して，それを圧縮したものを収集します。テキスト形式に編集した稼働統計情報ファイルを稼働統計出力ファイルといいます。

運用管理者は，収集した稼働統計出力ファイルを基に，運用管理ドメイン内のCTMに関する性能解析およびボトルネックの分析ができるようになります。

なお，Management Serverで収集できるのは，運用管理ドメイン内のホストで出力された稼働統計情報ファイルです。

以降で，運用管理コマンド（mngsvrutil）を使用して，CTMの稼働統計情報を収集する方法について説明します。また，収集した情報を確認する方法についても説明します。

次の単位でCTMの稼働統計情報を収集できます。

運用管理ドメイン内のすべてのCTM

運用管理ドメイン内の指定したCTM

運用管理ドメイン内の指定したホスト内のCTM

なお，CTMは，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2.1　製品と構成ソフトウェアの対応」を参照してください。

10.2.1　CTMの稼働統計情報の収集方法

CTMの稼働統計情報の出力と収集は，mngsvrutilコマンドにサブコマンド「collect」を指定して実行します。

CTMの稼働統計情報は，次のどれかの単位で収集できます。

運用管理ドメイン内のすべてのCTM

運用管理ドメイン内の指定したCTM

運用管理ドメイン内の指定したホスト内のCTM

なお，収集対象になるのは稼働中のCTMだけです。

CTMの稼働統計情報を出力，収集する場合のmngsvrutilコマンドの実行形式と実行例を次に示します。

運用管理ドメイン内のすべてのCTMを対象にする場合

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> collect allCtmStatistics

実行例

mngsvrutil -m mnghost -u user01 -p pw1 collect allCtmStatistics

運用管理ドメイン内の指定したCTM，または指定したホスト内のCTMを対象にする場合

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <論理CTM名またはホスト名> [-k host] collect ctmStatistics

実行例

指定したCTMの稼働統計情報を収集する場合

mngsvrutil -m mnghost -u user01 -p pw1 -t ctm01 collect ctmStatistics

指定したホスト内のCTMの稼働統計情報を収集する場合

mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host collect ctmStatistics

コマンドの実行結果は，標準出力またはファイルに出力されます。

mngsvrutilコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

10.2.2　CTMの稼働統計情報の出力先と出力情報

収集した稼働統計情報はCSV形式で出力されて，ZIP形式で圧縮されます。稼働統計情報が出力されるCSVファイルを，稼働統計出力ファイルといいます。

収集した稼働統計出力ファイルの出力先と出力情報について説明します。

収集した稼働統計出力ファイルの出力先

Windowsの場合

<Managerのログ出力ディレクトリ>¥ctm

UNIXの場合

<Managerのログ出力ディレクトリ>/ctm

なお，稼働統計出力ファイルは，稼働統計情報を収集する対象ごとに次の表に示すファイル名で出力されます。

表10‒2　収集対象ごとの稼働統計出力ファイル名

稼働統計情報の収集対象

ファイル名

運用管理ドメイン内のすべてのCTM

<ドメイン名>-<日時>.zip

運用管理ドメイン内の指定したCTM

<論理サーバ名>-<日時>.zip

指定したホスト内のCTM

<ホスト名>-<日時>.zip

注　出力された稼働統計出力ファイル（CSV形式）は，ZIP形式で圧縮されます。

また，CSV形式に出力される稼働統計情報は，CTMノード単位，キュー単位，およびメソッド単位でそれぞれ異なるファイルで出力されます。出力単位ごとの稼働統計情報のファイル名を次に示します。

表10‒3　出力単位ごとの稼働統計出力ファイル名

出力単位

ファイル名

CTMノード単位

noddata.csv

キュー単位

quedata.csv

メソッド単位

mtddata.csv

稼働統計情報の出力情報

稼働統計出力ファイルに出力される情報を次の表に示します。

表10‒4　稼働統計出力ファイルに出力される情報

統計情報種別

情報

説明

リクエスト情報

CTMレギュレータレスポンス時間

TPBrokerクライアント，およびEJBクライアントからの要求を受信したCTMレギュレータが，J2EEサーバに対してリクエストを送信してから応答を受信するまでの時間の差です※1。

CTMレギュレータで出力されます。

発生件数，および最大値・最小値・平均値がマイクロ秒単位で出力されます。

CTMレギュレータリクエストタイムアウト

CTMレギュレータがリクエストを送信してから応答が返されるまでの間に発生したタイムアウト障害の発生件数です。CTMレギュレータで出力されます。

CTMレギュレータリクエスト障害

CTMレギュレータがリクエストを送信してからその応答が返されるまでの処理で発生した障害の発生件数です。CTMレギュレータで出力されます。

OTMゲートウェイレスポンス時間

TPBroker OTMクライアントからの要求を受信したOTMゲートウェイが，J2EEサーバに対してリクエストを送信してから，応答を受信するまでの時間の差です。OTMゲートウェイで出力されます。

発生件数，および最大値・最小値・平均値がマイクロ秒単位で出力されます。

OTMゲートウェイリクエストタイムアウト

OTMゲートウェイでのリクエストの応答待ちで発生したタイムアウト障害の件数です。OTMゲートウェイで出力されます。

OTMゲートウェイリクエスト障害

OTMゲートウェイがリクエストを送信してからその応答が返されるまでの処理で発生した障害の件数です。OTMゲートウェイで取得します。

スケジュール情報

スケジュール待ち件数

スケジュールキューに滞留したリクエストの数です。

発生件数，および最大値・最小値・平均値が出力されます。

スケジュール待ち時間

リクエストがスケジュールキューに登録されてから取り出されるまでの滞留時間です。

発生件数，および最大値・最小値・平均値がマイクロ秒単位で出力されます。

スケジュールできなかったリクエスト数

スケジュールキューに同時に登録できる数を超えたため，スケジュールできなかったリクエストの数です。

プロセス情報

CTMレギュレータ異常終了件数

CTMレギュレータの異常終了が発生した件数です。

異常終了が発生するたびに，この情報が出力されます。

OTMゲートウェイ異常終了件数

OTMゲートウェイの異常終了が発生した件数です。

異常終了が発生するたびに，この情報を取得します。

コネクション情報

CTMレギュレータとクライアント間

CTMレギュレータとクライアントとのコネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した間隔で出力されます。

最大値・最小値・平均値がマイクロ秒単位で出力されます。

OTMゲートウェイとTPBroker OTMクライアント間

OTMゲートウェイとTPBroker OTMクライアントとのコネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した間隔でこの情報を取得します。

最大値・最小値・平均値がマイクロ秒単位で出力されます。

CTMデーモンとCTMレギュレータ間

CTMデーモンとCTMレギュレータとのコネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した間隔でこの情報を取得します。

最大値・最小値・平均値がマイクロ秒単位で出力されます。

CTMデーモンとOTMゲートウェイ間

CTMデーモンとOTMゲートウェイとのコネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した間隔でこの情報を取得します。

最大値・最小値・平均値がマイクロ秒単位で出力されます。

CTMデーモンとJ2EEサーバ※2間(制御用)

CTMデーモンとJ2EEサーバ※2間の制御用コネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した時間間隔でこの情報を取得します。

CTMデーモンとJ2EEサーバ※2間(リクエスト用)

CTMデーモンとJ2EEサーバ※2間のリクエスト要求用処理コネクション情報です。ctmstsstartコマンドの-CTMCheckIntervalオプションに指定した時間間隔でこの情報を取得します。

注※1

バッチアプリケーションを使用するシステムの場合は，cjexecjobコマンドからの要求を受信したCTMレギュレータが，バッチサーバに対して要求を送信してから応答を受信するまでの時間の差です。

注※2

バッチアプリケーションを実行するシステムでは，J2EEサーバはバッチサーバとなります。

10.2.3　CTMの稼働統計情報の出力例

運用管理コマンド（mngsvrutil）を利用して収集した稼働統計出力ファイルの出力例を次に示します。

CTMノード単位で出力した稼働統計情報の出力例

*** Statistics Information by CTMNode ***
CTMDomain, CTMID, start, end, Event, Count, Maximum, Minimum, Average, unit
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(Reg),      26525,      94000,          0,       9099,(usec)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(Reg),          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Error(Reg),          2,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(OTM),          0,          0,          0,          0,(usec)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(OTM),          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Error(OTM),          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Schedule Wait Count,      26526,          1,          1,          1,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Schedule Wait Time,      26526,    5688000,          0,        560,(usec)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Request Overflow,          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Regulator down,          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,OTMGateway down,          0,,,,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,Regulator-Client,,          2,          0,          1,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,OTMGateway-Client,,          0,          0,          0,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,CTMDaemon-J2EEServer(Ctr),,          2,          0,          1,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,CTMDaemon-J2EEServer(Req),,          1,          0,          1,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,CTMDaemon-Regulator,,          1,          1,          1,(count)
CTMDOMAIN,10.209.15.55,2004/11/05 09:57,2004/11/05 10:07,CTMDaemon-OTMGateway,,          5,          5,          5,(count)

キュー単位で出力した稼働統計情報の出力例

*** Statistics Information by Queue ***
CTMDomain, CTMID, QueueName, start, end, Event, Count, Maximum, Minimum, Average, unit
CTMDOMAIN,10.209.15.55,converter,2004/11/05 09:57,2004/11/05 10:07,Schedule Wait Count,      26526,          1,          1,          1,(count)
CTMDOMAIN,10.209.15.55,converter,2004/11/05 09:57,2004/11/05 10:07,Schedule Wait Time,      26526,    5688000,          0,        560,(usec)
CTMDOMAIN,10.209.15.55,converter,2004/11/05 09:57,2004/11/05 10:07,Request Overflow,          0,,,,(count)
CTMDOMAIN,10.209.15.55,converter,2004/11/05 09:57,2004/11/05 10:07,CTMDaemon-J2EEServer(Req),,          1,          1,          1,(count)

メソッド単位で出力した稼働統計情報の出力例

*** Statistics Information by Method ***
CTMDomain, CTMID, Interface, Method, start, end, Event, Count, Maximum, Minimum, Average, unit
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(Reg),      10393,      78000,          0,       9143,(usec)
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(Reg),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Error(Reg),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(OTM),          0,          0,          0,          0,(usec)
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(OTM),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,dollarToYen,2004/11/05 09:57,2004/11/05 10:07,Request Error(OTM),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(Reg),      10393,      94000,          0,       9119,(usec)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(Reg),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Error(Reg),          2,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Response Time(OTM),          0,          0,          0,          0,(usec)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Time Out(OTM),          0,,,,(count)
CTMDOMAIN,10.209.15.55,Converter,yenToEuro,2004/11/05 09:57,2004/11/05 10:07,Request Error(OTM),          0,,,,(count)

10.3　稼働統計情報ファイルの利用方法

CTMの稼働統計情報ファイルの利用方法について説明します。

CTMの稼働統計情報ファイルには，CTMが提供する次に示すプロセス群の処理の状態，処理の開始・終了時間や，処理の回数などの情報がバイナリ形式で自動的に出力されます。

CTMデーモン

CTMレギュレータ

OTMゲートウェイ

バイナリ形式で出力された稼働統計情報ファイルは，Management Serverの運用管理コマンド（mngsvrutil）を実行して編集します。編集した情報は，CSV形式のファイル，または標準出力に出力されます。

稼働統計出力ファイルの取得方法，および稼働統計出力ファイルの出力形式については，「10.2　CTMの稼働統計情報の概要」を参照してください。また，稼働統計出力ファイルの取得に使用するコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「ctmstsed（稼働統計情報の編集と出力）」を参照してください。

11　コンソールログの出力

この章では，運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などコンソールログの出力機能について説明します。

11.1　この章の構成

この章の構成を次の表に示します。

表11‒1　この章の構成（コンソールログの出力）

分類

タイトル

参照先

解説

コンソールログの出力対象

11.2

設定

コンソールログの取得の設定

11.3

注　「実装」，「運用」，「注意事項」について，この機能固有の説明はありません。

11.2　コンソールログの出力対象

この節では，コンソールログの出力対象について説明します。

Management Serverを利用して運用する場合，運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などを，コンソール出力情報として取得できます。コンソール出力情報の取得を次の図に示します。

図11‒1　コンソール出力情報の取得

運用管理エージェントが各プロセスから取得したコンソール出力情報は，ログファイル（コンソールログ）に出力されます。

また，Management Serverを利用するEclipseプラグインを使用している場合，コンソール出力情報は，Management Serverを経由してEclipseのコンソールにも表示されます。コンソール出力情報は，イベントとしてManagement Serverに通知されます。イベントはイベントキューに滞留され，順次イベントキューからイベントが取り出されてManagement Serverに通知されます。Management Serverが起動していないなどの理由でイベントを通知できない場合には，通知できるまでイベントが再送されます。イベントキュー内に滞留しているイベントがキューのサイズを超えた場合には，古いイベントから破棄されます。

11.2.1　コンソールログの出力対象となる操作

次の方法で論理サーバ，J2EEアプリケーション，リソースを操作する場合には，運用管理エージェントがプロセスを起動および停止するため，コンソールログを取得できます。

Smart Composer機能のコマンドを使用する場合

Management Serverの運用管理コマンド（mngsvrutil）を使用する場合

Management Serverを利用するEclipseプラグインを使用する場合

11.2.2　コンソールログの出力対象となるプロセス

コンソールログの出力対象となるのは，次のプロセスです。

論理サーバを構成するプロセス

J2EEアプリケーションやリソースを操作するプロセス

ただし，Windowsの場合には，間接起動のプロセスからはコンソールログを取得できません。間接起動される論理サーバについては，「2.3　論理サーバの起動・停止の仕組み」を参照してください。

注意事項

運用管理エージェントが起動したプロセスが一度に大量の文字列を出力する場合，運用管理エージェントのGCなどのタイミングによっては，対象となるプロセスが一時停止することがあります。

11.3　コンソールログの取得の設定

Management Serverを利用している場合には，運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などを，コンソール出力情報として取得できます。この節では，コンソールログを取得するための設定の変更について説明します。コンソール出力情報のログファイル（コンソールログ）への出力の設定を変更する場合は，adminagent.propertiesで次のキーを設定してください。

adminagent.process.consolelog.enabled

コンソール出力情報を出力するかどうかを指定します。デフォルトの設定では，trueが指定されていて，出力するようになっています。

adminagent.j2ee.process.console_log.enabled

論理J2EEサーバのコンソール出力情報をコンソールログに出力するかどうかを指定します。デフォルトの設定では，falseが指定されていて，出力されないようになっています。

また，adminagent.j2ee.process.console_log.enabledキーにtrueを指定する場合，adminagent.process.consolelog.enabledキーにもtrueを指定する必要があります。

adminagent.userserver.process.console_log.enabled

論理ユーザサーバのコンソール出力情報をコンソールログに出力するかどうかを指定します。デフォルトの設定では，falseが指定されていて，出力されないようになっています。

また，adminagent.userserver.process.console_log.enabledキーにtrueを指定する場合，adminagent.process.consolelog.enabledキーにもtrueを指定する必要があります。

adminagent.j2ee.process.console_event.enabled

論理J2EEサーバのコンソール出力情報を，Management Serverを利用するEclipseプラグインで表示するかどうかを指定します。デフォルトの設定では，falseが指定されていて，表示されないようになっています。

また，adminagent.j2ee.process.console_event.enabledキーにtrueを指定する場合，adminagent.process.consolelog.enabledキーにもtrueを指定する必要があります。

adminagent.process.consolelog.filenum

コンソールログの面数を指定します。

adminagent.process.consolelog.filesize

コンソールログの1面当たりの最大サイズを指定します。

第3編　連携機能

12　JP1と連携したシステムの運用

この章では，JP1と連携したシステムの運用について説明します。

JP1と連携してアプリケーションサーバのシステムを運用することで，アプリケーションサーバのシステムを含んだ業務システム全体の監視から問題の検知，調査対策までの一連の運用を，一貫した操作で効率良くできるようになります。また，サーバやアプリケーションの起動・停止を自動化することで，システムの日常運用の効率化を図れるほか，システムリソースの有効活用もできるようになります。

なお，この章で説明するJP1との連携機能は，Management Serverを利用して運用することが前提になります。

12.1　この章の構成

この章の構成を次の表に示します。

表12‒1　この章の構成（JP1と連携したシステムの運用）

分類

タイトル

参照先

解説

JP1との連携

12.2

JP1と連携するシステムでできること

12.3

注　「実装」，「設定」，「運用」，「注意事項」について，この機能固有の説明はありません。

12.2　JP1との連携

業務システムは，アプリケーションサーバ以外にも，サーバ，ネットワーク，ストレージなどのハードウェアや，Webサーバ，メールサーバ，データベースなどのソフトウェアなど，さまざまなリソースによって構成されます。業務システムの運用管理では，これら全体をできるだけ効率良く確実に運用する方法が求められます。

JP1は，このような複合的な業務システムの統合運用管理を実現する，ミドルウェアです。JP1と連携して実現できる運用を次に示します。これらは，業務システムの運用形態に応じて，組み合わせて運用できます。なお，JP1との連携は，J2EEアプリケーションの実行環境，およびバッチアプリケーションの実行環境で使用できます。

システム全体を対象に，障害を調査して対策できます（システムの集中監視）。

Smart Composer機能でのシステム構築時にシステムの構成情報を定義したり，定義したシステムの構成情報を収集したりできます（システムの構成定義および管理）※。

アプリケーションサーバで管理しているサーバやプロセスの起動／停止を，ジョブを使用して自動化できます（ジョブによるシステムの自動運転）。

Smart Composer機能で構築したシステムを，シナリオを使用して自動運転できます（シナリオによるシステムの自動運転）※。

システムの監査ログを自動で収集して一元管理できます（監査ログの収集／一元管理）。

注※

システムの構成定義・管理，およびシナリオを使用した自動運転は，Smart Composer機能を使用して構築したシステムが前提となります。Smart Composer機能を使用したシステム構築方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」を参照してください。

また，アプリケーションサーバでは，Management Serverの機能として，JP1と連携する環境の構築を支援したり，JP1と運用管理ポータルを一連の流れの中でスムーズに運用したりするための，次の機能を提供しています。

JP1/IMの統合スコープに表示する監視ツリーの自動生成

JP1/IMの統合コンソールまたは統合スコープからのManagement Serverの運用管理ポータルの直接起動（Windowsの場合）

JP1/AJSでジョブを定義するときに使用するカスタムジョブ（Windowsの場合）

12.3　JP1と連携するシステムでできること

この節では，JP1との連携の設定の概要について説明します。

Management Serverを利用してJP1と連携することで，JP1の集中監視，システム構成の定義・管理，運用の自動化，稼働状況の分析などの機能を使用して，アプリケーションサーバ以外で構築されたシステムも含めた業務システム全体を一括管理できるようになります。JP1との連携では，業務システムの運用形態に応じて，次の設定を組み合わせて環境を構築してください。

システムの集中監視および構成情報の定義・管理の設定（JP1/IMとの連携）

システムの自動運転の設定（JP1/AJSとの連携）

12.3.1　システムの集中監視

JP1/IMと連携することで，システムの集中監視の定義・管理ができます。

システムの集中監視は，業務システム全体のリソースの状態を監視することで，障害の発生を検知し，原因を究明して対策したりします。なお，JP1/IMと連携したシステムの運用の詳細については，「13.2　システムの集中監視（JP1/IMとの連携）の概要」を参照してください。

JP1/IMと連携してシステムを集中監視する場合の設定内容を次に示します。

監視ツリーの自動生成の設定

JP1/IMでアプリケーションサーバの障害を監視するために必要な設定をして，JP1/IM - Managerの統合スコープに表示するアプリケーションサーバ用の監視ツリーを自動生成します。設定方法については，「13.4.1　監視ツリーの自動生成の設定」を参照してください。

障害監視の設定

JP1/IM - Managerの統合コンソールまたは統合スコープから，アプリケーションサーバのシステムで発生した障害を監視するための設定をします。設定方法については，「13.4.2　障害監視の設定」を参照してください。

参考

JP1/Baseのログファイルトラップを使用すると，アプリケーションサーバのログファイルに出力される情報をJP1イベントに変換して，JP1/IMに通知できます。この場合，JP1/Baseのログファイルトラップで監視するログファイルの設定が必要になります。詳細は，「13.4.3　監視するログファイルの設定」を参照してください。

12.3.2　システムの自動運転

システムの自動運転は，サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図る運用方法です。アプリケーションサーバでは，JP1/AJSと連携して，自動運転をジョブに定義します。Windowsの場合には，アプリケーションサーバ用のカスタムジョブを利用してジョブを定義できます。カスタムジョブは，JP1/AJS以外のプログラムとJP1/AJSが連携するジョブを定義する場合に，目的のジョブを容易に作成するために使用できるジョブのテンプレートです。

JP1/AJSと連携したシステムの運用の詳細については，「14.2　ジョブによるシステムの自動運転（JP1/AJSとの連携）の概要」を参照してください。JP1/AJSと連携してシステムを自動運転化するための設定方法については，「14.3　ジョブによるシステムの自動運転の設定」を参照してください。

12.3.3　JP1で監視できるアプリケーションサーバのプロセス

この節では，JP1との連携で稼働情報などを監視できるアプリケーションサーバのプロセスについて，OSごとに説明します。

JP1/IMと連携して，障害検知や対策を実施するシステムの集中監視については，「13.　システムの集中監視（JP1/IMとの連携）」を参照してください。

Windowsの場合

アプリケーションサーバのプロセスについて次の表に示します。

表12‒2　アプリケーションサーバのプロセス（Windowsの場合）

項番

プロセス

起動するプロセスの名称

（上位プロセス←─→下位プロセス）

ユーザの権限

プロセスの説明

1

J2EEサーバ

adminagentsv

adminagent

aapgw

cjstartsv

SYSTEM

業務プログラムを実行します。

停止が要求されるまで常に存在します。

2

Webサーバ

httpsd

SYSTEM

HTTP Serverを制御します。

3

httpsd

httpsd

SYSTEM

HTTP Serverのサーバとして機能します。

4

rotatelogs

SYSTEM

HTTP Serverのログをラップアラウンドで取得します。

httpsd.confで指定した数だけ起動します。

5

rotatelogs2

SYSTEM

6

Management

Server

mngsvr.exe

cjstartsv.exe

SYSTEM

運用管理エージェントに指示を出して，運用管理ドメイン全体を運用管理します。

停止が要求されるまで常に存在します。

なお，cjstartsv.exeの引数に指定したサーバが監視対象となります。デフォルトのサーバ名は「cosmi_m」です。mngsvrctl setupコマンドでサーバ名を指定している場合，指定したサーバ名を指定します。

7

運用管理エージェント

adminagentsv.exe

adminagent.exe

SYSTEM

運用管理者の代わりに，論理サーバの起動・停止，および設定ファイルの更新を実行します。

停止が要求されるまで常に存在します。

8

サーバ通信エージェント

sinaviagentsv.exe

sinaviagent.exe

SYSTEM

仮想サーバ上のアプリケーションサーバをセットアップします。

停止が要求されるまで常に存在します。

9

ネーミングサービス

nameserv

＜OSのアカウント＞

ネーミングサービスをアウトプロセスで起動する場合に実行します。

10

CORBAクライアントアプリケーション

vbj

＜OSのアカウント＞

TPBrokerが提供するCORBAアプリケーションを実行します。

11

スマートエージェント

osagent

＜OSのアカウント＞

CTMを使用する場合にスマートエージェントを実行します。

12

CJMSプロバイダ

java.exe

＜OSのアカウント＞

CJMSPブローカーを実行します。

停止が要求されるまで常に存在します。

13

Javaアプリケーション

cjclstartap

＜OSのアカウント＞

cjclstartapコマンドを実行してJavaアプリケーションを開始します。アプリケーションを終了するまで存在します。

14

PRF

cprfd.exe

SYSTEM

パフォーマンストレーサ（PRFデーモン）のトレースファイルを出力します。

15

CTM

ctmdmd.exe

SYSTEM

CTMデーモンの情報を管理します。

16

ctmd.exe

SYSTEM

リクエストをスケジューリングします。

17

ctmd.exe

ctmregltd.exe

SYSTEM

CTMデーモンへのリクエストを集約します。

18

ctmtscgwd.exe

SYSTEM

TPBroker，OTMクライアントのリクエストを受け付けるゲートウェイとして機能します。

UNIXの場合

アプリケーションサーバのプロセスについて次の表に示します。

表12‒3　アプリケーションサーバのプロセス（UNIXの場合）

項番

プロセス

起動するプロセスの名称

（上位プロセス←─→下位プロセス）

ユーザの権限

プロセスの説明

1

J2EEサーバ

cjstartsv

＜OSのアカウント＞

業務プログラムを実行します。

停止が要求されるまで常に存在します。

2

Webサーバ

httpsd

root

HTTP Serverを制御します。

3

httpsd

httpsd

各ディレクティブの指定値

HTTP Serverのサーバとして機能します。

prefork MPMモジュールの場合，最大でMaxClientsに指定した数だけ起動します。

worker MPMモジュールの場合，最大でServerLimitに指定した数だけ起動します。

4

rotatelogs

root

HTTP Serverのログをラップアラウンドで取得します。

httpsd.confで指定した数だけ起動します。

5

rotatelogs2

root

6

Management

Server

cjstartsv

root

運用管理エージェントに指示を出して，運用管理ドメイン全体を運用管理します。

なお，cjstartsvの引数に指定したサーバが監視対象となります。デフォルトのサーバ名は「cosmi_m」です。mngsvrctl setupコマンドでサーバ名を指定している場合，指定したサーバ名を指定します。

7

運用管理エージェント

adminagent

root

運用管理者の代わりに，論理サーバの起動・停止，および設定ファイルの更新を実行します。

停止が要求されるまで常に存在します。

8

サーバ通信エージェント

sinaviagent

root

仮想サーバ上のアプリケーションサーバをセットアップします。

停止が要求されるまで常に存在します。

9

ネーミングサービス

nameserv

＜OSのアカウント＞

ネーミングサービスをアウトプロセスで起動する場合に実行します。

10

CORBAクライアントアプリケーション

vbj

＜OSのアカウント＞

TPBrokerが提供するCORBAアプリケーションを実行します。

11

スマートエージェント

osagent

＜OSのアカウント＞

CTMを使用する場合にスマートエージェントを実行します。

12

CJMSプロバイダ

java

＜OSのアカウント＞

CJMSPブローカーを実行します。

停止が要求されるまで常に存在します。

13

Javaアプリケーション

cjclstartap

＜OSのアカウント＞

cjclstartapコマンドを実行してJavaアプリケーションを開始します。アプリケーションを終了するまで存在します。

14

PRF

cprfd

root

パフォーマンストレーサ（PRFデーモン）のトレースファイルを出力します。

15

CTM

ctmdmd

root

CTMデーモンの情報を管理します。

16

ctmd

root

リクエストをスケジューリングします。

17

ctmd

ctmregltd

root

CTMデーモンへのリクエストを集約します。

18

ctmtscgwd

root

TPBroker，OTMクライアントのリクエストを受け付けるゲートウェイとして機能します。

13　システムの集中監視（JP1/IMとの連携）

この章では，JP1/IMと連携したシステムの集中監視の運用について説明します。システムの集中監視では，システム全体を対象に，障害を調査して対策できます。システムの集中監視の運用に必要な機能の設定についても説明します。

なお，この章で説明するJP1との連携機能は，Management Serverを利用して運用することが前提になります。

13.1　この章の構成

この章の構成を次の表に示します。

表13‒1　この章の構成（システムの集中監視（JP1/IMとの連携））

分類

タイトル

参照先

解説

システムの集中監視（JP1/IMとの連携）の概要

13.2

システムの集中監視の仕組み

13.3

設定

システムの集中監視のための設定

13.4

運用

Webフロントシステムでの運用例

13.5.1

注　「実装」，「注意事項」について，この機能固有の説明はありません。

13.2　システムの集中監視（JP1/IMとの連携）の概要

Management Serverを利用してJP1/IMと連携することで，JP1の集中監視ができます。

この節では，システムの集中監視の概要について説明します。

システムの集中監視は，業務システム全体のリソースの状態を監視することで，障害の発生を検知して原因を究明，対策したりできる運用方法です。JP1/IMと連携することで実現できます。JP1/IMは，企業情報システム全体を統合管理する基盤になるプログラム群です。JP1/IMでシステムの集中監視をする場合は，次のプログラムを利用します。

JP1/IM - Manager

統合コンソール

システムで発生した事象をJP1イベントによって集中管理することで，システムの統合管理を実現するプログラムです。JP1イベントとは，システムで発生した事象に，JP1で管理するための属性を付与された情報です。

JP1/IM - Managerでは，発生した事象に関連するエラーメッセージなどが表示されるので，事象の詳細を確認できます。

統合スコープ

システムを監視するための画面を，管理者の目的に合わせて表示できるようにすることで，目的指向型のシステム監視を実現するプログラムです。

発生した事象の影響範囲が業務単位またはサーバ単位のツリー形式で確認できるので，影響範囲の切り分けや特定ができます。

JP1/IM - View（ビューアー）

JP1/IMでシステム運用管理をするときに使用する，監視・操作画面を提供するプログラムです。

統合コンソールおよび統合スコープの操作画面を表示するホストに必要です。

JP1/IMのシステムの集中監視の詳細については，マニュアル「JP1/Integrated Management - Manager 運用ガイド」を参照してください。

13.3　システムの集中監視の仕組み

JP1/IMと連携してシステムを集中監視すると，システムの次の事象を統合コンソールと統合スコープのビューアーで監視できるようになります。

J2EEアプリケーションが開始，停止または実行されたことの通知や，J2EEアプリケーション内で発生した障害を監視できます。J2EEアプリケーションの監視をするには，監視ツリーの自動生成で取得する内容にアプリケーション情報を含めるかどうかの設定が必要です。詳細については，「13.3.2(1)　業務指向ツリー」のJ2EEアプリケーション監視の説明を参照してください。

論理サーバが開始，停止されたことの通知や，論理サーバで発生した障害を監視できます。

J2EEアプリケーションやバッチアプリケーション内で出力されたユーザログの情報を監視できます。

JP1/IMを使用したシステムの集中監視の概要を次に示します。

図13‒1　JP1/IMを使用したシステムの集中監視の概要

J2EEサーバ／Webサーバで障害が発生した場合，その事象が，JP1統合運用管理サーバに通知されます。

JP1統合運用管理サーバから，業務システムの運用管理者に事象が通知されます。

通知方法としては，事象を選別して携帯電話に自動的に通知する設定などができます。このような設定をしておくと，運用管理者自身が常にコンソールを監視している必要がなくなります。

通知を受けた運用管理者が，JP1/IMの統合スコープのビューアーを参照して，事象を確認します。

統合スコープのビューアーでは，監視ツリーを使用して障害などの影響範囲を確認できます。例えば，特定のJ2EEサーバで障害が発生している場合，監視ツリーでは，ツリーのルートノードから該当するJ2EEサーバまでのノードが，障害を表す色で表示されます。このツリーをルートノードからたどれば，障害が発生しているJ2EEサーバとその影響範囲をすぐに確認できます。また，その障害によって業務が完全に停止してしまうのか，またはクラスタ構成によってシステムの停止にはなっていないのかなどを確認して，緊急性の有無を判断できます。

なお，アプリケーションサーバでは，業務指向ツリーとサーバ指向ツリーの2種類の監視ツリーを作成する機能を提供しています。詳細については，「13.3.2　監視ツリーの自動生成」を参照してください。

障害が発生した個所を特定したら，該当するノードから統合コンソールを表示して，エラー情報などを確認します。

障害の原因がアプリケーションサーバシステムの設定にあった場合は，統合コンソールからアプリケーションサーバシステムの運用管理ポータルを表示して，障害の原因に対処します※。

運用管理ポータルが表示される場合は，統合コンソールで選択したイベントに応じて，その事象に対処するための画面が直接表示されます。

注※

運用管理ポータルの表示は，Windowsの場合だけできます。

アプリケーションサーバシステムでは，このような運用を実現するために，次の機能を提供しています。

JP1/IMで使用するアプリケーションサーバ用の監視ツリーを自動生成する機能（アダプタコマンド）

アプリケーションサーバシステムで発生したトラブルをJP1/IMに通知するためのJP1イベントを発行する機能

JP1/IMからManagement Serverの運用管理ポータルを表示する機能（モニタ起動コマンド）※

注※

モニタ起動コマンドはWindowsの場合だけ使用できます。

13.3.1　システムの集中監視に必要なプログラム

システムの集中監視は，JP1/IMを中心としたJP1のプログラム群と，アプリケーションサーバの運用管理機能を組み合わせて実現します。

JP1/IMと連携してシステムの集中監視をする場合のシステム構成例を次の図に示します。

図13‒2　JP1/IMと連携してシステムの集中監視をする場合のシステム構成例

JP1の各プログラムの主な機能を次に示します。なお，アプリケーションサーバの運用管理機能については，「1.2　システムの目的と機能の対応」を参照してください。

表13‒2　システムの集中監視をするために使用するJP1プログラムの機能

JP1プログラム

機能

配置するサーバ／

クライアント

JP1/Base

JP1/IMの基盤機能を提供します。JP1イベントの送受信などをするほか，JP1/IMシステムのエージェントとして機能します。

J2EEサーバ

アプリケーションサーバの運用管理サーバ

JP1統合運用管理サーバ

JP1/IM - Manager

統合コンソール機能を提供します。

JP1統合運用管理サーバ

統合スコープ機能を提供します。

JP1/IM - View

ビューアーです。

運用管理クライアント

13.3.2　監視ツリーの自動生成

JP1/IMの統合スコープでは，監視ツリーを使用してシステムを監視します。監視ツリーは，JP1/IMの機能を使用して，自動生成できます。

アプリケーションサーバシステムを集中監視する場合，次の2種類の監視ツリーが自動生成できます。これによって，JP1/IMと連携したアプリケーションサーバシステムを含んだシステム全体の障害監視が容易に実現できるようになります。

業務指向ツリー

サーバ指向ツリー

なお，監視ツリーは，運用開始前にあらかじめ自動生成しておきます。

監視ツリーの自動生成の設定については，「13.4.1　監視ツリーの自動生成の設定」を参照してください。

(1)　業務指向ツリー

業務指向ツリーとは，アプリケーションサーバシステム上で稼働しているJ2EEアプリケーションを主体に構成されている監視ツリーです。どの業務で問題が発生しているのか，業務の視点で障害が監視できるようになります。

業務指向ツリーの構成を次に示します。初期表示は，「運用管理グループ」ノードまでが展開された状態になります。

図13‒3　業務指向ツリーの構成

業務指向ツリーの各ノードについて説明します。

表13‒3　業務指向ツリーのノード

ノード名※1※2

説明

業務

業務指向ツリーのルートノードです。

AJS3マネージャグループ

JP1/AJS用のルートノードです。

運用管理グループ

アプリケーションサーバ用のルートノードです。

運用管理ホスト<運用管理ホスト名>

運用管理ホストの監視グループです。運用管理ホストの名称が表示されます。

<運用管理ドメイン名>

運用管理ドメインの監視グループです。運用管理ドメインの名称が表示されます。

<業務J2EEアプリケーション名>※3

業務に対応する監視グループです。J2EEアプリケーション（EAR）のプロパティであるDisplay Nameプロパティの値が表示されます。統合スコープから，わかりやすい業務名に必要に応じて変更できます。

<運用管理エージェントホスト名>

論理サーバが稼働するホストの監視グループです。アプリケーションサーバの運用管理エージェントが配置されているホストのホスト名が表示されます。

業務サービス

JP1/IMで管理しているほかの業務指向ツリーと階層を合わせるためのノードです。

アプリケーションサーバ業務サービス

サーバ指向ツリーを使用する場合にJP1/AJSの監視ノードと区別するためのノードです。

論理サーバ監視

論理サーバに対応する監視グループです。論理サーバを監視するWebサーバ，およびAPサーバの監視グループは，このノードの下に配置されます。

Webサーバ※3

Webサーバに対応する監視グループです。Webサーバを監視するオブジェクトは，このノード下に配置されます。

<Webサーバ名>監視※3

Webサーバの障害監視オブジェクトです。

該当するWebサーバに障害が発生すると，この監視オブジェクトの状態が変わります。

APサーバ

アプリケーションサーバの監視グループです。Webサーバ以外を監視するオブジェクトは，このノード下に配置されます。

J2EEサーバ<論理サーバ名>監視

J2EEサーバまたはバッチサーバの障害監視オブジェクトです（バッチサーバの場合も「J2EEサーバ」と表示されます）。

J2EEアプリケーションが稼働しているJ2EEサーバの表示名，またはバッチサーバの表示名が表示されます。

該当するJ2EEサーバまたはバッチサーバで障害が発生すると，この監視オブジェクトの状態が変わります。なお，J2EEサーバの場合，該当するJ2EEアプリケーションが1ホスト内の複数のJ2EEサーバに配置されている場合，この監視オブジェクトは複数生成されます。

ネーミングサービス<論理サーバ名>監視※3

ネーミングサービスの障害監視オブジェクトです。J2EEサーバに関連するネーミングサービスの表示名が表示されます。

該当するネーミングサービスに障害が発生すると，この監視オブジェクトの状態が変わります。

スマートエージェント<論理サーバ名>監視※3

スマートエージェントの障害監視オブジェクトです。同じ監視グループ内のOTSやCTMに関連するスマートエージェントの表示名が表示されます。

該当するスマートエージェントに障害が発生すると，この監視オブジェクトの状態が変わります。

CTMドメインマネジャ名<論理サーバ名>監視※3

CTMドメインマネジャの障害監視オブジェクトです。J2EEサーバに関連するCTMドメインマネジャの表示名が表示されます。

該当するCTMドメインマネジャに障害が発生すると，この監視オブジェクトの状態が変わります。

CTM<論理サーバ名>監視※3

CTMの障害監視オブジェクトです。J2EEサーバに関連するCTMの表示名が表示されます。

該当するCTMに障害が発生すると，この監視オブジェクトの状態が変わります。

パフォーマンストレーサ<論理サーバ名>監視

パフォーマンストレーサの障害監視オブジェクトです。J2EEサーバに関連するパフォーマンストレーサの表示名が表示されます。

該当するパフォーマンストレーサに障害が発生すると，この監視オブジェクトの状態が変わります。

J2EEアプリケーション監視※3※4

J2EEアプリケーションの監視グループです。J2EEアプリケーションを監視するオブジェクトはこのノードの下に配置されます。

<論理サーバ名><J2EEアプリケーション名>監視※3

J2EEサーバ内のJ2EEアプリケーション監視オブジェクトです。J2EEサーバのサーバ名とJ2EEアプリケーション名が表示されます。

該当するJ2EEサーバ内のJ2EEアプリケーションで障害が発生すると，この監視オブジェクトの状態が変わります。なお，この監視オブジェクトは，各J2EEサーバ内のJ2EEアプリケーションの数だけ生成されます。

ミドル

ミドル製品用の監視グループです。ミドル製品のリソースを監視するオブジェクトです。

注※1　<　>で囲まれている名称は，環境に応じて設定される名称です。

注※2　各ノードの名称は，統合スコープ上で任意の名称に変更できます。

注※3　バッチサーバの場合，該当しません。

注※4　J2EEアプリケーション監視をするには，監視ツリーの自動生成で取得する内容にアプリケーション情報を含めるかどうかの設定（mngsvrutil.compat.monitoring_tree）が必要です。また，J2EEサーバが起動されていることが前提となります。

(2)　サーバ指向ツリー

サーバ指向ツリーとは，サーバマシン（ホスト）を主体に構成されている監視ツリーです。どのホストで問題が発生しているのか，ホストの視点で障害が監視できるようになります。

サーバ指向ツリーの構成を次に示します。初期表示は，「管理ホスト<IMマネージャ>」ノードまでが展開された状態になります。なお，IM構成ホストとは，JP1/IMマネジャホストまたはエージェントホストのことです。

図13‒4　サーバ指向ツリーの構成

(3)　監視ツリー自動生成の処理の流れ

監視ツリーの自動生成処理の流れについて説明します。

JP1/IM - Viewで表示した統合スコープのビューアーから監視ツリーの自動生成を実行すると，JP1/IMからJP1/Baseを介してアダプタコマンドが実行されます。アダプタコマンドとは，監視ツリーの自動生成に使用する定義情報を収集するために，JP1/Baseによって実行されるコマンドです。あらかじめJP1/Baseに登録しておく必要があります。

アプリケーションサーバシステムに対してアダプタコマンドが実行されると，運用管理コマンド（mngsvrutil）が実行されます。J2EEアプリケーションを実行しているシステムでは，J2EEアプリケーションやJ2EEサーバ，Webサーバなどの構成情報が取得されます。バッチアプリケーションを実行しているシステムでは，バッチサーバ，パフォーマンストレーサなどの構成情報が取得されます。

JP1/IMでは，それぞれのアダプタコマンドによって取得された情報を基に，監視ツリーの自動生成が実行されます。

13.3.3　統合機能メニューからの運用管理ポータルの表示（Windowsの場合）

この機能はWindowsの場合だけ使用できます。

JP1/IMでは「統合機能メニュー」画面を提供しています。この画面には，JP1/IMと連携するプログラムの一覧が表示されます。それぞれのプログラムは，「統合機能メニュー」から起動できます。

JP1/IMと連携すると，アプリケーションサーバの運用管理ポータル画面が「統合機能メニュー」画面から表示できるようになります。運用管理ポータル画面は，自動ログインを設定しているかによって，次のどちらかの画面が表示されます。

運用管理ポータルへのログイン画面

自動ログインを設定していない場合に表示されます。

運用管理ポータル

自動ログインを設定している場合に表示されます。

自動ログインの設定は，JP1/IM連携用モニタ起動設定ファイル（.mngsvrmonitorrc）で設定します。モニタ起動コマンドのセットアップについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「付録E.1　モニタ起動コマンドのセットアップ」を参照してください。また，統合機能メニューの詳細については，マニュアル「JP1/Integrated Management - Manager 運用ガイド」を参照してください。

13.3.4　障害の監視の仕組み

JP1/IMの統合コンソールと統合スコープを使用して，アプリケーションサーバシステムで発生した障害を監視します。

(1)　障害の監視の仕組み

統合コンソールおよび統合スコープを使用することで，アプリケーションサーバシステム以外の要因で発生した障害も同じ画面で確認できるようになり，障害の影響範囲も特定しやすくなります。さらに，Windowsの場合は，アプリケーションサーバシステムで発生した障害の，調査および対処をするとき，障害の内容に応じたアプリケーションサーバの運用管理ポータル画面を，統合コンソールまたは統合スコープから直接表示できます。

JP1/IMと連携して障害を監視する場合は，次の準備が必要です。

JP1/IMと連携して障害監視をするために必要な準備

アプリケーションサーバシステムで発生する，どのようなエラーやインフォメーション情報をJP1/IMで監視したいのかを決めて，アプリケーションサーバの運用管理ポータル（「JP1連携の設定」画面）から定義しておきます（JP1イベントのフィルタリング設定）。

アプリケーションサーバシステムが出力するどのメッセージをJP1イベント発行対象にするかを運用方法に合わせて決定して，メッセージマッピング定義ファイルで設定，編集します。メッセージマッピング定義ファイルでの設定については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.3　JP1/IM連携用システムログメッセージマッピングファイル」を参照してください。

アプリケーションサーバシステムが出力するメッセージごとの重要度を運用方法に合わせて決定して，運用管理ポータル（論理サーバの環境設定）で設定，編集します。設定，編集は任意です。運用管理ポータル（論理サーバの環境設定）での設定については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「8.2.7　JP1連携の設定（Management Serverの設定）」，および「10.8.25　JP1連携の設定（J2EEサーバ）」を参照してください。

JP1イベント発行対象のメッセージ，およびメッセージごとの重要度の両方を設定したい場合，メッセージマッピング定義ファイルと運用管理ポータルの両方で設定が必要です。

統合スコープを使用した障害監視をする場合は，監視ツリーを生成しておきます。JP1/IMの統合スコープに表示する監視ツリーは，各ホストのJP1/Baseによって収集されてJP1統合運用管理サーバに集められた情報を基に自動生成されます。

なお，統合コンソールだけを使用する場合は，監視ツリーの生成は不要です。

JP1/IMと連携した障害監視処理の流れを次の図に示します。

図13‒5　JP1/IMと連携した障害監視処理の流れ

アプリケーションサーバシステムで発生したトラブルに関する障害情報は，JP1/Baseを経由して，JP1イベントとしてJP1統合運用管理サーバのJP1/IMに通知されます。

J2EEサーバで発生したトラブルに関する障害情報は，J2EEサーバホスト内のJP1/Baseを経由してJP1統合運用管理サーバに発行されます。

J2EEサーバ以外の論理サーバ（Webサーバやネーミングサービスなど）で発生したトラブルに関する障害情報は，運用管理エージェントによってアプリケーションサーバの運用管理サーバに収集されます。その後，運用管理サーバのJP1/Baseを経由して，JP1統合運用管理サーバに発行されます。

なお，障害情報には，通知メッセージやJ2EEアプリケーションで出力されたユーザログのメッセージなども含まれます。

J2EEサーバ，バッチサーバ，またはアプリケーションサーバの運用管理サーバからJP1イベントを受け取ったJP1統合運用管理サーバのJP1/IMによって，次のような処理が実行されます。

JP1/IMの自動アクション機能を使って運用管理者への通知を設定している場合は，トラブルが発生したことが運用管理者に通知されます。

統合スコープの監視ツリーの状態が変化します。例えば，WebサーバやJ2EEサーバなど，業務に依存しない論理サーバレベルの障害の場合はすべての業務を対象にする該当論理サーバオブジェクトの状態が変化します。また，業務レベルの障害の場合は，該当するJ2EEアプリケーションの監視オブジェクトの状態が変化します。

通知を受け取った運用管理者は，統合コンソールや統合スコープから障害に対処します。

障害の影響範囲を特定したい場合は，統合スコープを確認します。統合スコープには，障害の影響範囲が明示された監視ツリーが表示されます。また，詳細な障害の内容を知りたい場合は，統合コンソールを確認します。統合コンソールには，エラーメッセージなどが表示されます。さらに，Windowsの場合，アプリケーションサーバシステムで障害の原因究明や対策が必要なときは，Management Serverの運用管理ポータルの該当画面を表示して，調査や対策を実施します。

JP1イベントとして発行されるアプリケーションサーバシステムの障害情報を次に示します。

表13‒4　JP1イベントとして発行されるアプリケーションサーバシステムの障害情報

イベントの種類

説明

運用管理システム JP1イベント

Management Serverが出力した通知・障害メッセージをJP1イベントに変換したものです。変換は，メッセージマッピングファイルで指定したルールに従って実行されます。

主な内容は，J2EEサーバ，バッチサーバ，Webサーバ，ネーミングサービス，CTMなどの論理サーバでプロセス停止レベルの障害が発生した時や，各サーバが起動または停止した時の通知メッセージです。

発行されるJP1イベントのIDは，00012000〜0001207F（未割当てのIDあり）です。詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.3.4　JP1イベントへの変換」を参照してください。

なお，Management Serverの起動中に出力されるメッセージについては，JP1イベントが発行されない場合があります。

J2EEサーバシステム JP1イベント

J2EEサーバまたはバッチサーバが出力した通知・障害メッセージをJP1イベントに変換したものです。変換は，メッセージマッピングファイルで指定したルールに従って実行されます。

発行されるJP1イベントのIDは，00012080〜000120CF（未割当てのIDあり）です。詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.3.4　JP1イベントへの変換」を参照してください。

なお，Management Serverの起動中に出力されるメッセージについては，JP1イベントが発行されない場合があります。

J2EEサーバユーザ JP1イベント

J2EEアプリケーションが，ユーザログ出力機能※によって出力した通知・障害メッセージをJP1イベントに変換したものです。

注　JP1/Baseのログファイルトラップを使用すると，アプリケーションサーバのログファイルに出力される情報をJP1イベントに変換できます。この場合，JP1/Baseのログファイルトラップで監視するログファイルの設定が必要になります。詳細は，「13.4.3　監視するログファイルの設定」を参照してください。

注※　ユーザログ出力機能については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.　アプリケーションのユーザログ出力」を参照してください。

(2)　運用管理ポータルの表示のされ方（Windowsの場合）

統合コンソールまたは統合スコープからは，次のようにして運用管理ポータルの画面が表示されます。なお，統合コンソールまたは統合スコープからの，運用管理ポータル画面の表示はWindowsの場合だけできます。

ログイン方法の設定

統合コンソールまたは統合スコープから運用管理ポータルを表示する場合，自動ログインするか，ログイン画面を表示して手動ログインするかを選択できます。自動ログインをするためには，あらかじめ設定ファイル（.mngsvrmonitorrc）に管理ユーザのユーザIDとパスワードを指定しておく必要があります。ファイルの指定方法については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.17　.mngsvrmonitorrc（JP1/IM連携用モニタ起動コマンドの設定ファイル）」を参照してください。

論理サーバに障害が発生した場合に表示される画面

J2EEサーバ，バッチサーバ，Webサーバなどの論理サーバレベルの障害が発生した場合は，次に示す状態の「論理サーバの稼働状況」画面が表示されます。

ツリーペインには，サーバビューが表示されます。ツリーは，障害が発生した論理サーバまで展開された状態で表示されます。ただし，論理サーバを特定できない障害（一括起動操作に関する障害など）が発生している場合は，ツリーは展開されません。

ボディペインには，ツリーペインのドメインを選択した場合に表示される「論理サーバの稼働状況」画面が表示されます。

J2EEアプリケーションに障害が発生した場合に表示される画面

J2EEアプリケーションで障害が発生した場合は，次に示す状態の「論理サーバのアプリケーション管理」画面が表示されます。

ツリーペインのツリーは，障害が発生したJ2EEアプリケーションが稼働しているJ2EEサーバまで展開された状態で表示されます。

ボディペインには，J2EEサーバ下のアプリケーションを選択した場合に表示される「J2EEアプリケーションの開始／停止」画面が表示されます。

そのほかの障害が発生した場合に表示される画面

Management Serverの障害など，サーバやJ2EEアプリケーション以外の障害が発生した場合は，「運用管理ポータル」画面が表示されます。

13.4　システムの集中監視のための設定

この節では，JP1/IMと連携してシステムを集中監視するための設定について説明します。

JP1/IMと連携することで，システムの集中監視ができます。システムの集中監視は，業務システム全体のリソースの状態を監視することで，障害の発生を検知し，原因を究明して対策したりします。

JP1/IMと連携してシステムを集中監視する場合の設定内容を次に示します。

監視ツリーの自動生成の設定

JP1/IMでアプリケーションサーバの障害を監視するために必要な設定をして，JP1/IM - Managerの統合スコープに表示するアプリケーションサーバ用の監視ツリーを自動生成します。設定方法については，「13.4.1　監視ツリーの自動生成の設定」を参照してください。

障害監視の設定

JP1/IM - Managerの統合コンソール，または統合スコープから，アプリケーションサーバシステムで発生した障害を監視するための設定をします。設定方法については，「13.4.2　障害監視の設定」を参照してください。

なお，JP1/Baseのログファイルトラップを使用して，アプリケーションサーバのログファイルに出力される情報をJP1イベントに変換する場合は，監視するログファイルを設定します。監視できるログファイルについては，「13.4.3　監視するログファイルの設定」を参照してください。

13.4.1　監視ツリーの自動生成の設定

この節では，JP1/IMの統合スコープに表示するアプリケーションサーバ用の監視ツリーを自動生成するための設定について説明します。

まず，次の表に示すサーバおよびクライアントに，監視ツリーの自動生成に必要なJP1の製品またはアプリケーションサーバの製品の構成ソフトウェアをインストール，セットアップしておいてください。なお，JP1/IMと連携する場合のシステム構成については，「13.3.1　システムの集中監視に必要なプログラム」を参照してください。

表13‒5　監視ツリーの自動生成に必要な製品または構成ソフトウェア

サーバ／クライアント

製品／構成ソフトウェア

J2EEサーバ

Component Container

Manager

アプリケーションサーバの運用管理サーバ

Manager

JP1/Base

JP1統合運用管理サーバ

JP1/Base

JP1/IM - Manager

運用管理クライアント

JP1/IM - View

アプリケーションサーバ用の監視ツリーを自動生成するための手順を次に示します。

アプリケーションサーバの運用管理サーバで，次の作業を実施します。

アダプタコマンドのセットアップ（(1)参照）

アダプタコマンドの実行環境の設定（(2)参照）

Management Serverでの環境設定（(3)参照）

JP1統合運用管理サーバで，次の作業を実施します。

JP1/Baseの構成定義の作成（(4)参照）

運用管理クライアントで，次の作業を実施します。

監視ツリーの自動生成（(5)参照）

(1)　アダプタコマンドのセットアップ

監視ツリーの自動生成に使用する定義情報を収集するために，JP1/Baseによって実行されるアダプタコマンドをJP1/Baseに登録します。

アプリケーションサーバの運用管理サーバでmngsvr_adapter_setupコマンドを実行して，JP1/Baseの環境にアプリケーションサーバ用のアダプタコマンド設定ファイルを追加します。なお，mngsvr_adapter_setupコマンドを実行するユーザにはAdministrator権限（UNIXの場合は，root権限）が必要です。mngsvr_adapter_setupコマンドの実行例を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥bin¥mngsvr_adapter_setup -i -t IM_CS

UNIXの場合

/opt/Cosminexus/manager/bin/mngsvr_adapter_setup -i -t IM_CS

mngsvr_adapter_setupコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvr_adapter_setup（アダプタコマンドのセットアップとアンセットアップ）」を参照してください。

(2)　アダプタコマンドの実行環境の設定

アダプタコマンドを実行するための環境は，Management Serverの運用管理コマンドであるmngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）に設定します。

アプリケーションサーバの運用管理サーバで，OSユーザ（SYSTEMユーザ）のホームディレクトリ（UNIXの場合は，JP1/Baseを起動したOSユーザのホームディレクトリ）に，クライアント側定義ファイルを作成して，次のパラメタを指定します。

mngsvrutil.connect.host

Management Serverのホスト名とポート番号を指定します。

mngsvrutil.connect.userid

Management Serverのmngsvrctl setupコマンドで設定した管理ユーザIDを指定します。

mngsvrutil.connect.password

Management Serverのmngsvrctl setupコマンドで設定したパスワードを指定します。パスワードを設定していない場合，このパラメタの指定は省略できます。

クライアント側定義ファイルは，mngsvrutilコマンドのオプションのデフォルト値を設定するファイルです。なお，mngsvrutilコマンドの実行環境を変更したい場合は，Management Serverの運用管理コマンドであるmngsvrutilコマンドのサーバ側定義ファイル（mngsvrutil.properties）で変更します。

mngsvrutilコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。クライアント側定義ファイル（.mngsvrutilrc）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.14　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）」を参照してください。サーバ側定義ファイル（mngsvrutil.properties）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.15　mngsvrutil.properties（mngsvrutilコマンドのサーバ側定義ファイル）」を参照してください。

参考

クライアント側定義ファイルはクライアントごとに個別のデフォルト値を設定する場合に使用します。すべてのクライアント共通のデフォルト値を設定したい場合は，クライアント側共通設定ファイル（mngsvrutilcl.properties）を使用してください。なお，両方のファイルを使用している場合は，クライアント側定義ファイルが適用されます。クライアント側共通設定ファイルは読み込まれません。

(3)　Management Serverでの環境設定

監視ツリーを自動生成する前に，Management Serverで次の設定をしてください。

Webシステムの構成定義

決定したシステム構成パターンで，Webシステムを構築してください。Webシステムの構築には，Smart Composer機能のファイルとコマンドを使用します。

Smart Composer機能の簡易構築定義ファイルで，Webシステムの構成や，Webシステム内の論理サーバの環境を定義し，Smart Composer機能のコマンドで，定義したファイルを基にWebシステムを構築します。詳細については，マニュアル「アプリケーションサーバシステム構築・運用ガイド」の「4.6　バッチアプリケーションを実行するシステムの構築」を参照してください。

J2EEサーバへのJ2EEアプリケーションのインポート

J2EEアプリケーションのインポートの詳細については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」を参照してください。

運用管理エージェントとManagement Serverの起動および停止については，「2.6　システムの起動と停止の設定」を参照してください。

なお，論理サーバの構成やJ2EEアプリケーションの数を変更した場合は，もう一度監視ツリーを自動生成する必要があります。

(4)　JP1/Baseの構成定義の作成

JP1/IMが管理するシステムの構成を定義するJP1/Baseの構成定義ファイルを作成します。また，JP1/Baseの構成定義ファイルに定義したホストへ，定義情報を配布します。

JP1/Baseの構成定義の作成手順を次に示します。なお，詳細については，マニュアル「JP1/Integrated Management - Manager 構築ガイド」のシステムの構成定義情報の設定に関する説明を参照してください。

JP1/Baseの構成定義ファイルを作成して，システムの構成を定義します。

構成定義ファイル（jbs_route.confファイル）は次の場所にインストールされています。

Windowsの場合

<JP1/Baseのインストールディレクトリ>¥jp1base¥conf¥route¥jbs_route.conf

UNIXの場合

/etc/opt/jp1base/conf/route/jbs_route.conf

構成定義ファイルの内容を次に示します。

構成定義ファイルの内容

［JP1統合運用管理サーバマシンのホスト名］

J2EEサーバマシンのホスト名

アプリケーションサーバの運用管理サーバマシンのホスト名

jbsrt_distribコマンドを実行して，構成定義情報を配布します。

(5)　監視ツリーの自動生成

運用管理クライアントにあるJP1/IM - Viewで，監視ツリーを自動生成します。

監視ツリーを自動生成するための手順を次に示します。監視ツリーの自動生成は，JP1/IM - Viewがインストールされた運用管理クライアント（Windows）で実施してください。JP1/IMの起動と停止，ログインとログアウトなどの操作については，マニュアル「JP1/Integrated Management - Manager 運用ガイド」を参照してください。

Windowsの［スタート］メニューから［JP1_Integrated Manager - View］-［監視ツリー編集］を選択します。

JP1/IM - Viewの［監視ツリー（編集中）］画面が起動されます。

［オプション］−［ツリーの自動生成］を選択します。

統合スコープにログインするための［ログイン］画面が表示されるため，ログイン処理をすると，［自動生成-構成選択］画面が表示されます。

自動生成する監視ツリーのモデルとして［業務指向ツリー］または［サーバ指向ツリー］を選択して，［生成］ボタンをクリックします。

監視ツリーが自動生成されます。

［監視ツリー(編集中)］画面で，［ファイル］−［サーバのツリーを更新］を選択します。

確認ダイアログが表示されるので，［はい］ボタンをクリックすると，生成された監視ツリーの情報がJP1統合運用管理サーバに反映されます。

JP1/IM - Viewでアプリケーションサーバの業務指向ツリーを生成および編集した場合の例を次の図に示します。

図13‒6　アプリケーションサーバの業務指向ツリーの生成，編集例

13.4.2　障害監視の設定

ここでは，JP1/IMの統合コンソールまたは統合スコープから，アプリケーションサーバシステムで発生した障害を監視するための設定について説明します。

まず，次の表に示すサーバおよびクライアントに，障害監視に必要なJP1の製品またはアプリケーションサーバの製品の構成ソフトウェアをインストール，セットアップしておいてください。なお，JP1/IMと連携する場合のシステム構成については，「13.3.1　システムの集中監視に必要なプログラム」を参照してください。

表13‒6　障害監視に必要な製品または構成ソフトウェア

サーバ／クライアント

製品／構成ソフトウェア

J2EEサーバ

Component Container

JP1/Base

アプリケーションサーバの運用管理サーバ

JP1/Base

JP1統合運用管理サーバ

JP1/Base

JP1/IM - Manager

運用管理クライアント

JP1/IM - View

障害監視の設定手順を次に示します。

アプリケーションサーバの運用管理サーバで，次の作業を実施します。

アプリケーションサーバのJP1イベント発行の設定（(1)参照）

JP1/Baseのイベントサーバ名の設定（(2)参照）

J2EEサーバで，次の作業を実施します。

JP1/Baseのイベントサーバ名の設定（(2)参照）

JP1統合運用管理サーバで，次の作業を実施します。

JP1/Baseの構成定義の作成（(3)参照）

(1)　アプリケーションサーバのJP1イベント発行の設定

アプリケーションサーバシステムで発生するエラーやインフォメーション情報のうち，どのようなエラーやインフォメーション情報をJP1イベントとして発行するかを設定します。

Management Server用JP1イベントの設定

J2EEサーバ用JP1イベントの設定

J2EEユーザ用JP1イベントの設定

それぞれの設定方法について説明します。また，ユーザJP1イベントの推奨設定についても説明します。簡易構築定義ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(a)　Management Server用JP1イベントの設定

Management Server用JP1イベントの設定手順を次に示します。

システムJP1イベント発行の設定をします。

mserver.propertiesで，com.cosminexus.mngsvr.jp1event.enabledキーで，Management Serverが検知した障害や通知をJP1イベントとして発行するかどうかを指定します。また，JP1イベントの重大度ごとに，JP1イベントを発行するかどうかを指定します。mserver.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

メッセージマッピングファイルを設定します。

Management Serverが検知した障害や通知を，メッセージマッピングファイルで，メッセージごとにどの重大度のJP1イベントに変換するかを定義します。なお，マッピング定義がなくJP1イベントの重大度を割り当てられないメッセージは，JP1イベントとして発行されません。

ファイル名は「mserver.jp1event.system.mapping.properties」です。マッピング関係を定めた標準的なファイルを提供しているので，必要に応じて，テキストエディタなどで編集してください。ファイルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥manager¥config

UNIXの場合

/opt/Cosminexus/manager/config

Management Server用メッセージマッピングファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.3.1　mserver.jp1event.system.mapping.properties（Management Server用メッセージマッピングファイル）」を参照してください。

Management Serverを再起動します。

再起動後に，設定した情報が有効になります。

(b)　J2EEサーバ用JP1イベントの設定

J2EEサーバ用JP1イベントの設定手順を次に示します。

システムJP1イベント発行の設定をします。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.manager.agent.JP1EventAgent.enabledパラメタで「true」を指定します。デフォルトでは，「false」が指定されています。また，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタでJP1イベントの重大度ごとに，JP1イベントを発行するかどうかを指定します。

manager.jp1event.system.filtering.severity.emergency

manager.jp1event.system.filtering.severity.alert

manager.jp1event.system.filtering.severity.critical

manager.jp1event.system.filtering.severity.error

manager.jp1event.system.filtering.severity.warning

manager.jp1event.system.filtering.severity.notice

manager.jp1event.system.filtering.severity.information

Management Serverおよび運用管理エージェントを再起動します。

再起動後に，設定した情報が有効になります。

メッセージマッピングファイルを設定します。

J2EEサーバが検知した障害や通知を，メッセージマッピングファイルで，メッセージごとにどの重大度のJP1イベントに変換するかを定義します。なお，マッピング定義がなくJP1イベントの重大度を割り当てられないメッセージは，JP1イベントとして発行されません。メッセージマッピングファイルには，J2EEサーバ共通用とJ2EEサーバ個別用があります。

J2EEサーバ共通用メッセージマッピングファイル

マシン内のJ2EEサーバ共通用で，J2EEサーバが検知した障害や通知をJP1イベントに変換するときに使用するファイルです。ファイル名は「manager.jp1event.system.mapping.properties」です。マッピング関係を定めた標準的なファイルを提供しているので，必要に応じて，テキストエディタなどで編集してください。ファイルの格納場所を次に示します。

Windowsの場合

　　<Application Serverのインストールディレクトリ>¥manager¥config

UNIXの場合

　　/opt/Cosminexus/manager/config

J2EEサーバ個別用メッセージマッピングファイル

J2EEサーバごとに，J2EEサーバが検知した障害や通知をJP1イベントに変換したいときに使用するファイルです。このファイルとJ2EEサーバ共通用メッセージマッピングファイルが作成されている場合は，このファイルでの指定が優先されます。

ファイル名は「manager.<論理サーバ名>.jp1event.system.mapping.properties」です。このファイルは，テキストエディタなどを使用してユーザが作成してください。パラメタの記述形式は，J2EEサーバ共通用メッセージマッピングファイルと同じです。

メッセージマッピングファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.3　JP1/IM連携用システムログメッセージマッピングファイル」を参照してください。

J2EEサーバを再起動します。

再起動後に，設定した情報が有効になります。

(c)　J2EEユーザ用JP1イベントの設定

J2EEユーザ用JP1イベントの設定手順を次に示します。

ユーザJP1イベント発行の設定をします。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタでJ2EEアプリケーションのユーザログをJP1イベントとして発行するかどうかを指定します。マッピングの設定で，ユーザログのログレベルにJP1イベントの重大度を割り当てたログがJP1イベントの発行対象になります。

manager.jp1event.user.mapping.level.severe

manager.jp1event.user.mapping.level.warning

manager.jp1event.user.mapping.level.info

manager.jp1event.user.mapping.level.config

manager.jp1event.user.mapping.level.fine

manager.jp1event.user.mapping.level.finer

manager.jp1event.user.mapping.level.finest

また，出力するユーザログをメッセージIDなどでフィルタリングできます。フィルタリングは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタで指定します。

manager.jp1event.user.filtering.enabled

manager.jp1event.user.filtering.filter

なお，ユーザJP1イベントの推奨設定については，「13.4.2(1)(d)　ユーザJP1イベントの推奨設定」を参照してください。

ロガーおよびハンドラを設定します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタでJ2EEアプリケーションのユーザログで使用するロガーおよびハンドラを指定します。ハンドラにはJP1イベント用のハンドラ（com.cosminexus.mngsvr.externals.jp1event.JP1EventHandler）を指定してください。

ejbserver.application.userlog.loggers

ejbserver.application.userlog.Logger.<ロガー名称>.level

ejbserver.application.userlog.Logger.<ロガー名称>.useParentHandlers

ejbserver.application.userlog.Logger.<ロガー名称>.filter

ejbserver.application.userlog.menu.handlers.

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.path

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.limit

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.count

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.level

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.appname

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.msgid

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.separator

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.formatter

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.filter

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.encoding

ejbserver.application.userlog.Logger.<ロガー名称>.handlers

Management Serverおよび運用管理エージェントを再起動します。

再起動後に，設定した情報が有効になります。

J2EEサーバを再起動します。

再起動後に，設定した情報が有効になります。

(d)　ユーザJP1イベントの推奨設定

「13.4.2(1)(c)　J2EEユーザ用JP1イベントの設定」で設定するユーザJP1イベントの推奨設定について説明します。なお，J2EEアプリケーションのユーザログ出力の詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.8　J2EEアプリケーションのユーザログ出力の設定」を参照してください。

ユーザJP1イベントのマッピングの設定

マッピングは次のように設定します。

ログレベル

JP1イベント重大度

SEVERE

Error

WARNING

Warning

INFO

Information

CONFIG

Notice

FINE

なし

FINER

なし

FINEST

なし

ユーザJP1イベントのフィルタリングの設定

ログを取得するときにメッセージIDを付けて，「MESSAGE_ID」でフィルタリングします。JP1イベントを発行させたいメッセージIDに対して「MESSAGE_ID EQU <メッセージID>」をORで接続して記述します。

また，J2EEアプリケーションごとにJP1イベントの発行をフィルタリングしたい場合は，ログを取得するときにJ2EEアプリケーション名を付けるか，デフォルトのJ2EEアプリケーション名を設定して，「APPLICATION」でフィルタリングします。

(2)　JP1/Baseのイベントサーバ名の設定

Windows Server Failover ClusterまたはHAモニタを使用したクラスタ構成の場合で，論理ホストのJP1/Baseのイベントサーバを使用してJP1イベントを発行するとき，アプリケーションサーバの運用管理サーバ，およびJ2EEサーバでイベントサーバ名を設定します。

(a)　運用管理サーバ用イベントサーバ名の設定

アプリケーションサーバの運用管理サーバでイベントサーバ名を設定するには，Management Server環境設定ファイル（mserver.properties）のmngsvr.jp1event.event_server_nameキーに，論理ホスト名または論理IPアドレスを指定します。なお，設定した情報を有効にするために，設定後は，Management Serverを再起動してください。

Management Server環境設定ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

(b)　J2EEサーバ用イベントサーバ名の設定

J2EEサーバでイベントサーバ名を設定する場合，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.manager.jp1event.event_server_nameパラメタで指定します。

(3)　JP1/Baseの構成定義の作成

JP1/IMが管理するシステムの構成を定義するJP1/Baseの構成定義ファイルを作成します。また，JP1/Baseの構成定義ファイルに定義したホストへ，定義情報を配布します。

JP1/Baseの構成定義の作成手順を次に示します。なお，詳細については，マニュアル「JP1/Integrated Management - Manager 構築ガイド」のシステムの構成定義情報の設定に関する説明を参照してください。

JP1/Baseの構成定義ファイルを作成して，システムの構成を定義します。

構成定義ファイル（jbs_route.conf）は次の場所にインストールされています。

Windowsの場合

<JP1/Baseのインストールディレクトリ>¥jp1base¥conf¥route¥jbs_route.conf

UNIXの場合

/etc/opt/jp1base/conf/route/jbs_route.conf

構成定義ファイルの内容を次に示します。

構成定義ファイルの内容

［JP1統合運用管理サーバマシンのホスト名］

J2EEサーバマシンのホスト名

アプリケーションサーバの運用管理サーバマシンのホスト名

jbsrt_distribコマンドを実行して，構成定義情報を配布します。

13.4.3　監視するログファイルの設定

JP1/Baseのログファイルトラップを使用して監視できる，アプリケーションサーバのログファイルについて説明します。JP1/Baseのログファイルトラップでは，アプリケーションサーバのログファイルに出力される情報をJP1イベントに変換します。JP1/Baseのログファイルトラップの設定については，マニュアル「JP1/Base 運用ガイド」を参照してください。

アプリケーションサーバが出力するログのうち，JP1イベントに変換できるログファイルと，そのファイルの内容を次の表に示します。

表13‒7　JP1/Baseで監視できるログファイルとファイルの内容

プロセス

ログ出力先およびログファイル名※1

ファイル形式※2

改行コード

説明

J2EEサーバ

Windowsの場合

<ejb.server.log.directory>※3¥cjmessage[n].log

UNIXの場合

<ejb.server.log.directory>※3/cjmessage[n].log

WRAP2

新規出現タイプ

CR+LF

J2EEサーバの稼働ログ

Windowsの場合

（Connector 1.0仕様のリソースアダプタ）

<ejb.server.log.directory>※3¥connectors¥<リソースアダプタの表示名>[n].log

（Connector 1.5仕様のリソースアダプタ）

<ejb.server.log.directory>※3¥connectors¥<リソースアダプタの表示名>_<コネクション定義の並び順>_[n].log

UNIXの場合

（Connector 1.0仕様のリソースアダプタ）

<ejb.server.log.directory>※3/connectors/<リソースアダプタの表示名>[n].log

（Connector 1.5仕様のリソースアダプタ）

<ejb.server.log.directory>※3/connectors/<リソースアダプタの表示名>_<コネクション定義の並び順>_[n].log

WRAP2

新規出現タイプ

CR+LF

J2EEリソースアダプタとしてデプロイして使用するリソースアダプタの稼働ログ

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥logs¥cjmessage[n].log※4

UNIXの場合

<Application Serverのインストールディレクトリ>/CC/admin/logs/cjmessage[n].log※4

WRAP2

新規出現タイプ

CR+LF

サーバ管理コマンドの稼働ログ

PRF

Windowsの場合

Eventlog

UNIXの場合

syslog

−

−

OSのログ

Management

Server※7

<Managerのログ出力ディレクトリ>※6¥mngsvr.exe.[n].log

WRAP2

新規出現タイプ

CR+LF

Management Serverサービス（mngsvrコマンド）のログ（Windowsだけ）

Windowsの場合

<Managerのログ出力ディレクトリ>※6¥mngsvr[n].log

UNIXの場合

<Managerのログ出力ディレクトリ>※6/mngsvr[n].log

WRAP2

新規出現タイプ

CR+LF

Management Serverのログ

運用管理エージェント※8

<Managerのログ出力ディレクトリ>※6¥adminagentsv.exe.[n].log

WRAP2

新規出現タイプ

CR+LF

運用管理エージェントサービス（adminagentsvコマンド）のログ（Windowsだけ）

Windowsの場合

<Managerのログ出力ディレクトリ>※6¥adminagent[n].log

UNIXの場合

<Managerのログ出力ディレクトリ>※6/adminagent[n].log

WRAP2

新規出現タイプ

CR+LF

運用管理エージェントのログ

CTM

Windowsの場合

Eventlog

UNIXの場合

syslog

−

−

OSのログ

ネーミングサービス

Windowsの場合

<ejb.server.log.directory>※3¥ejb¥<J2EEサーバ名>¥logs¥TPB¥logj¥hvimsgj[n].txt

UNIXの場合

<ejb.server.log.directory>※3/ejb/<J2EEサーバ名>/logs/TPB/logj/hvimsgj[n].txt

WRAP1

新規出現タイプ

CR+LF

ネーミングサービスのメッセージログ

（ネーミングサービスをインプロセスで起動した場合）

Windowsの場合

<VBROKER_ADMディレクトリ(vbroker_adm)>※5¥..¥logj¥hvimsgj[n].txt

UNIXの場合

<VBROKER_ADMディレクトリ(vbroker_adm)>※5/../logj/hvimsgj[n].txt

WRAP1

新規出現タイプ

CR+LF

ネーミングサービスのメッセージログ

（ネーミングサービスをアウトプロセスで起動した場合）

CORBAクライアントアプリケーション

Windowsの場合

<VBROKER_ADMディレクトリ(vbroker_adm)>※5¥..¥logj¥hvimsgj[n].txt

UNIXの場合

<VBROKER_ADMディレクトリ(vbroker_adm)>※5/../logj/hvimsgj[n].txt

WRAP1

新規出現タイプ

CR+LF

CORBAクライアントアプリケーションのメッセージログ

JavaVM

Windowsの場合

<ejb.server.log.directory>※3¥javalog[nn].log

UNIXの場合

<ejb.server.log.directory>※3/javalog[nn].log

WRAP2

新規出現タイプ

CR+LF

JavaVMの保守情報およびGCのログ

Windowsの場合

<ejb.server.log.directory>※3¥ehjavalog[nn].log

UNIXの場合

<ejb.server.log.directory>※3/ehjavalog[nn].log

WRAP2

新規出現タイプ

CR+LF

明示管理ヒープ機能のイベントログ

CJMSプロバイダ

Windowsの場合

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定しない場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥instances¥<インスタンス名>¥log¥cjmsbroker_msg[n].log

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定する場合

<-varhomeオプションの設定値>¥instances¥<インスタンス名>¥log¥cjmsbroker_msg[n].log

UNIXの場合

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定しない場合

<Application Serverのインストールディレクトリ>/CC/cjmsp/var/instances/<インスタンス名>/log/cjmsbroker_msg[n].log

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定する場合

<-varhomeオプションの設定値>/instances/<インスタンス名>/log/cjmsbroker_msg[n].log

WRAP1

新規出現タイプ

CR+LF

CJMSPブローカーのメッセージログ

Windowsの場合

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定しない場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥instances¥<インスタンス名>¥log¥cjmsbroker_err[n].log

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定する場合

<-varhomeオプションの設定値>¥instances¥<インスタンス名>¥log¥cjmsbroker_err[n].log

UNIXの場合

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定しない場合

<Application Serverのインストールディレクトリ>/CC/cjmsp/var/instances/<インスタンス名>/log/cjmsbroker_err[n].log

CJMSPブローカーの起動コマンド（cjmsbrokerコマンド）で-varhomeオプションを指定する場合

<-varhomeオプションの設定値>/instances/<インスタンス名>/log/cjmsbroker_err[n].log

WRAP1

新規出現タイプ

CR+LF

CJMSPブローカーのエラーログ

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥admin¥log¥cjmsadmin_msg[n].log

UNIXの場合

<Application Serverのインストールディレクトリ>/CC/cjmsp/var/admin/log/cjmsadmin_msg[n].log

WRAP1

新規出現タイプ

CR+LF

サーバ管理コマンド（cjmsicmd）のメッセージログ

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥admin¥log¥cjmsadmin_err[n].log

UNIXの場合

<Application Serverのインストールディレクトリ>/CC/cjmsp/var/admin/log/cjmsadmin_err[n].log

WRAP1

新規出現タイプ

CR+LF

サーバ管理コマンド（cjmsicmd）のエラーログ

Windowsの場合

<ejb.server.log.directory>※3¥cjms¥Cosminexus_JMS_Provider_RA¥cjmsra_msg[n].log

UNIXの場合

<ejb.server.log.directory>※3/cjms/Cosminexus_JMS_Provider_RA/cjmsra_msg[n].log

WRAP1

新規出現タイプ

CR+LF

CJMSPリソースアダプタのメッセージログ

Windowsの場合

<ejb.server.log.directory>※3¥cjms¥Cosminexus_JMS_Provider_RA¥cjmsra_err[n].log

UNIXの場合

<ejb.server.log.directory>※3/cjms/Cosminexus_JMS_Provider_RA/cjmsra_err[n].log

WRAP1

新規出現タイプ

CR+LF

CJMSPリソースアダプタのエラーログ

Management Serverおよび運用管理エージェント※7※8

Windowsの場合

<Managerのログ出力ディレクトリ>※6¥message¥mngmessage[n].log

UNIXの場合

<Managerのログ出力ディレクトリ>※6/ message/mngmessage[n].log

WRAP2

新規出現タイプ

CR+LF

Management Serverと運用管理エージェントの統合メッセージログ

（凡例）−：なし

注※1

ログファイル名の[n]の部分には，面の番号（1から各ログの最大面数まで）が付きます。

また，[nn]の部分には，01〜99の通し番号が付きます。

注※2

読み込むログファイルのレコード形式です。

WRAP1：ラップラウンドファイル（ラップラウンドして，再び先頭からデータを上書きするファイル）

WRAP2：ラップラウンドファイル（ラップラウンドするとき，データを削除して再び先頭からデータを書き込むファイル）

HTRACE：マルチプロセス対応トレースファイル（複数のプロセスが一組のトレースファイルを共有し，メモリマップドファイルを使用した固定サイズのファイル）。ログファイルへの書き込み方法はWRAP1と同じです。

新規出現タイプ：ログファイルが通番に従い出現します。通番は[1]から始まり，順に[2]，[3]…とファイルが作成されます。なお，一度出現すれば，ファイル自体は削除されません。

全ファイル既出タイプ：定義したログファイル面数分のファイルがすべて作成されているタイプです。

注※3

<ejb.server.log.directory>は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.server.log.directoryパラメタで指定したディレクトリを指します。デフォルト値をOSごとに次に示します。

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs

UNIXの場合：<Application Serverのインストールディレクトリ>/CC/server/public/ejb/<サーバ名称>/logs

注※4

ログファイルの出力先は，サーバ管理コマンド用オプション定義ファイルのusrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）のejbserver.log.directoryキーで変更できます。

注※5

<VBROKER_ADMディレクトリ(vbroker_adm)>は，環境変数VBROKER_ADMに指定したディレクトリを指します。

注※6

<Managerのログ出力ディレクトリ>は，manager.cfg（Managerログ設定ファイル）で指定されたディレクトリを指します。デフォルト値をOSごとに次に示します。

Windowsの場合：¥opt¥Cosminexus¥manager¥logです。

UNIXの場合：/opt/Cosminexus/manager/logです。

注※7

Management Serverのログ，または統合メッセージログのどちらか一方を監視するようにしてください。

注※8

運用管理エージェントのログ，または統合メッセージログのどちらか一方を監視するようにしてください。

13.5　運用例

13.5.1　Webフロントシステムでの運用例

ここでは，WebフロントシステムでJP1/IMと連携し，アプリケーションサーバのログファイルを監視して，システムの集中監視をする運用例について説明します。

(1)　システム構成と運用例

JP1/IMと連携してシステムを集中監視すると，アプリケーションサーバのプロセスで発生した事象（エラーメッセージ）は，JP1イベントに変換されてJP1総合運用管理サーバへ転送され，システム運用者に通知されます。

この場合，アプリケーションサーバにはJP1/Base，JP1/統合運用管理サーバにはJP1/Base，JP1/IM - Manager，JP1/IM - Viewなどを利用します。

Webフロントシステムでのシステム構成と運用例を次の図に示します。

図13‒7　Webフロントシステムでのシステム構成と運用例（JP1/IMを使用したシステムの集中監視）

アプリケーションサーバのプロセスで発生した事象（エラーメッセージ）が出力されたログファイルは，JP1/Baseのログファイルトラップによって定期的に監視されます。

ログファイルトラップ動作定義ファイルの監視条件と一致すると，JP1/BaseのログファイルトラップによってそのエラーメッセージはJP1イベントに変換され，JP1/Baseのイベントサービスによってイベントデータベースに蓄積されます。

JP1イベントは，JP1/BaseのイベントサービスによってJP1統合運用管理サーバへ転送されます。

通知を受けたシステム運用者は，JP1/IM - Viewを使って発生した事象を確認します。

このシステム構成を例にして，監視するログとメッセージ，および各ログを監視するためのログファイルトラップ動作定義ファイルの設定例を説明します。ここでは，代表的なOSの設定例について説明します。

(2)　Windowsの場合の設定例

Windowsの場合に監視するログファイルと，ログファイルトラップ動作定義ファイルの設定内容を次の表に示します。なお，ここで説明するログファイルの出力先はデフォルトになります。

表13‒8　監視するログファイルとログファイルトラップ動作定義ファイルの設定内容（Windowsの場合）

項番

プロセス名

監視するログファイル名

ログファイルトラップ動作定義ファイルの設定内容

説明

FILETYPE※1の指定値

ACTDEF※2の指定値

MARKSTR※3の指定値

1

Webサーバ（HTTP Serverの場合）

<HWSのインストールディレクトリ>¥servers¥HWS_<サーバ名称>¥logs¥error.[n]

WRAP2

新規出現タイプ

"emerg"

"alert"

"crit"

"error"

"File does not exist"

[n]は001から005まで作成されます。すべてのファイルを監視します。

<アプリケーションサーバのインストールディレクトリ>¥CC¥web¥redirector¥logs¥hws_redirect[n].log

WRAP2

新規出現タイプ

"-E"

"KDJE39188-E"

"KDJE41010-E"

[n]は1から8まで作成されます。すべてのファイルを監視します。

2

J2EEサーバ

<アプリケーションサーバのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs¥cjmessage[n].log

WRAP2

新規出現タイプ

"-E"

"KDJE52703-W"

"KDJE31002-W"

"KDJE34500-W"

"KDJE39022-E"

"KDJE39051-E"

"KDJE39057-E"

[n]は1から2まで作成されます。すべてのファイルを監視します。

Oracleの場合

<アプリケーションサーバのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs¥connectors¥DB_Connector_for_Oracle[n].log

HiRDBの場合

<アプリケーションサーバのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs¥connectors¥DB_Connector_for_HiRDB_Type4[n].log

SQL Serverの場合

<アプリケーションサーバのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名称>¥logs¥connectors¥DB_Connector_for_SQLServer2005[n].log

WRAP2

新規出現タイプ

"-E"

−

[n]は1から4まで作成されます。すべてのファイルを監視します。

3

Management Server

<アプリケーションサーバのインストールディレクトリ>¥manager¥log¥message¥mngmessage[n].log

WRAP2

新規出現タイプ

"-E"

−

[n]は1から4まで作成されます。すべてのファイルを監視します。

4

運用管理エージェント

（凡例）−：指定値がないことを示します。

注※1　読み込むログファイルのレコード形式を指定します。

WRAP2：ラップラウンドファイル（ラップラウンドするとき，データを削除して再び先頭からデータを書き込むファイル）

新規出現タイプ：ログファイルが通番に従い出現します。通番は[1]から始まり，順に[2]，[3]…とファイルが作成されます。なお，一度出現すれば，ファイル自体は削除されません。

注※2　JP1イベントに変換するログデータを指定します。

注※3　存在しないURLへのアクセス，リクエストの中断など，ブラウザの操作で簡単に発生するエラーメッセージ（監視の対象外にしたいデータ）を指定します。

JP1/Baseのログファイルトラップの起動コマンド（jevlogstartコマンド）に，引数として設定するログファイルトラップ動作定義ファイルの作成例を次に示します。ログファイルトラップ動作定義ファイルは，監視するログファイルごとに作成します。

error.[n]を監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
MARKSTR="File does not exist"
ACTDEF=<Emergency>111A "emerg"
ACTDEF=<Alert>111B "alert"
ACTDEF=<Critical>111C "crit"
ACTDEF=<Error>111D "error"

hws_redirect[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
MARKSTR="KDJE39188-E"
MARKSTR="KDJE41010-E"
ACTDEF=<Error>112A "-E"

cjmessage[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
MARKSTR="KDJE39022-E"
MARKSTR="KDJE39051-E"
MARKSTR="KDJE39057-E"
ACTDEF=<Error>113A "-E"
ACTDEF=<Warning>113B "KDJE52703-W"
ACTDEF=<Warning>113C "KDJE31002-W"
ACTDEF=<Warning>113D "KDJE53850-W"

DB_Connector_for_Oracle[n].log，DB_Connector_for_HiRDB_Type4[n].log，またはDB_Connector_for_SQLServer2005[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
ACTDEF=<Error>114A "-E"

mngmessage[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
ACTDEF=<Error>115A "-E"

(3)　Linux（AMD64 & Intel EM64T）の場合の設定例

Linux（AMD64 & Intel EM64T）の場合に監視するログファイルと，ログファイルトラップ動作定義ファイルの設定内容を次の表に示します。なお，ここで説明するログファイルの出力先はデフォルトになります。

表13‒9　監視するログファイルとログファイルトラップ動作定義ファイルの設定内容（Linux（AMD64 & Intel EM64T）の場合）

項番

プロセス名

監視するログファイル名

ログファイルトラップ動作定義ファイルの設定内容

説明

FILETYPE※1の指定値

ACTDEF※2の指定値

MARKSTR※3の指定値

1

Webサーバ（HTTP Serverの場合）

<HWSのインストールディレクトリ>/servers/HWS_<サーバ名称>/logs/error.[n]

WRAP2

新規出現タイプ

"emerg"

"alert"

"crit"

"error"

"File does not exist"

[n]は001から005まで作成されます。すべてのファイルを監視します。

/opt/Cosminexus/CC/web/redirector/logs/hws_redirect[n].log

HTRACE

新規出現タイプ

"-E"

"KDJE39188-E"

"KDJE41010-E"

[n]は1から8まで作成されます。すべてのファイルを監視します。

2

J2EEサーバ

/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs/cjmessage[n].log

WRAP2

新規出現タイプ

"-E"

"KDJE52703-W"

"KDJE31002-W"

"KDJE34500-W"

"KDJE39022-E"

"KDJE39051-E"

"KDJE39057-E"

[n]は1から2まで作成されます。すべてのファイルを監視します。

Oracleの場合

/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs/connectors/DB_Connector_for_Oracle[n].log

HiRDBの場合

/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs/connectors/DB_Connector_for_HiRDB_Type4[n].log

SQL Serverの場合

/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs/connectors/DB_Connector_for_SQLServer2005[n].log

WRAP2

新規出現タイプ

"-E"

−

[n]は1から4まで作成されます。すべてのファイルを監視します。

3

Management Server

/opt/Cosminexus/manager/log/message/mngmessage[n].log

WRAP2

新規出現タイプ

"-E"

−

[n]は1から4まで作成されます。すべてのファイルを監視します。

4

運用管理エージェント

（凡例）−：指定値がないことを示します。

注※1　読み込むログファイルのレコード形式を指定します。

WRAP2：ラップラウンドファイル（ラップラウンドするとき，データを削除して再び先頭からデータを書き込むファイル）

HTRACE：マルチプロセス対応トレースファイル（複数のプロセスが一組のトレースファイルを共有し，メモリマップドファイルを使用した固定サイズのファイル）。ログファイルへの書き込み方法はWRAP1と同じです。

新規出現タイプ：ログファイルが通番に従い出現します。通番は[1]から始まり，順に[2]，[3]…とファイルが作成されます。なお，一度出現すれば，ファイル自体は削除されません。

注※2　JP1イベントに変換するログデータを指定します。

注※3　存在しないURLへのアクセス，リクエストの中断など，ブラウザの操作で簡単に発生するエラーメッセージ（監視の対象外にしたいデータ）を指定します。

JP1/Baseのログファイルトラップの起動コマンド（jevlogstartコマンド）に，引数として設定するログファイルトラップ動作定義ファイルの作成例を次に示します。ログファイルトラップ動作定義ファイルは，監視するログファイルごとに作成します。

error.[n]を監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
MARKSTR="File does not exist"
ACTDEF=<Emergency>111A "emerg"
ACTDEF=<Alert>111B "alert"
ACTDEF=<Critical>111C "crit"
ACTDEF=<Error>111D "error"

hws_redirect[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=HTRACE
MARKSTR="KDJE39188-E"
MARKSTR="KDJE41010-E"
ACTDEF=<Error>112A "-E"

cjmessage[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
MARKSTR="KDJE39022-E"
MARKSTR="KDJE39051-E"
MARKSTR="KDJE39057-E"
ACTDEF=<Error>113A "-E"
ACTDEF=<Warning>113B "KDJE52703-W"
ACTDEF=<Warning>113C "KDJE31002-W"
ACTDEF=<Warning>1130 "KDJE34500-W"

DB_Connector_for_Oracle[n].log，DB_Connector_for_HiRDB_Type4[n].log，またはDB_Connector_for_SQLServer2005[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
ACTDEF=<Error>114A "-E"

mngmessage[n].logを監視するためのログファイルトラップ動作定義ファイルの作成例

FILETYPE=WRAP2
ACTDEF=<Error>115A "-E"

14　ジョブによるシステムの自動運転（JP1/AJSとの連携）

この章では，JP1/AJSと連携したシステムの自動運転の運用および設定について説明します。システムの自動運転では，サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図れます。ジョブによるシステムの自動運転の運用に必要な機能の設定についても説明します。

なお，この章で説明するJP1との連携機能は，Management Serverを利用して運用することが前提になります。

14.1　この章の構成

この章の構成を次の表に示します。

表14‒1　この章の構成（ジョブによるシステムの自動運転（JP1/AJSとの連携））

分類

タイトル

参照先

解説

ジョブによるシステムの自動運転（JP1/AJSとの連携）の概要

14.2

設定

ジョブによるシステムの自動運転の設定

14.3

注　「実装」，「運用」，「注意事項」について，この機能固有の説明はありません。

14.2　ジョブによるシステムの自動運転（JP1/AJSとの連携）の概要

システムの自動運転は，サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図る運用方法です。JP1/AJSと連携することでジョブによるシステムの自動運転が実現できます。

JP1/AJSは，日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するためのプログラム群です。JP1/AJSでは，システム運用の各作業を，ジョブとして扱います。ジョブは，コマンド，シェルスクリプト，バッチファイルなどの集まりに対応します。また，ジョブの実行順序を関連づけたものを，ジョブネットといいます。

JP1/AJSは，次の3種類のプログラムで構成されています。

JP1/AJS - Manager

ジョブネットやスケジュールの定義を保存して，ジョブネットの実行を管理するプログラムです。ジョブの実行時には，実行するジョブをJP1/AJS - Agentに転送し，実行状況，実行結果の情報を受け取ります。エージェントとしてジョブの実行もできます。

JP1/AJS - Agent

ジョブを実行するためのプログラムです。JP1/AJS - Managerから転送されたジョブを実行します。

JP1/AJS - View

GUIを使ってJP1/AJSを操作するためのプログラムです。JP1/AJS - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

JP1/AJSの詳細については，マニュアル「JP1/Automatic Job Management System 導入ガイド」を参照してください。

14.2.1　ジョブによるシステムの自動運転の仕組み

JP1/AJSと連携してシステムを自動運転にすると，アプリケーションサーバシステム内の論理サーバおよびJ2EEアプリケーションの計画的な一括開始や一括停止ができるようになります。夜間に実行するバッチ処理，曜日によって異なる業務の切り替え，月末だけに実行する業務などをあらかじめスケジュール定義しておくことで，システムリソースを計画的に確保して，有効活用できるようになります。

(1)　JP1/AJSを使用したシステムの自動運転

JP1/AJSを使用したシステムの自動運転を次に示します。

図14‒1　JP1/AJSを使用したシステムの自動運転の概要

アプリケーションサーバシステムの運用を自動化するためには，まず，J2EEアプリケーションの開始や停止などの処理の一つ一つをジョブとして定義して，それらの実行順序をジョブネットとして定義します。アプリケーションサーバシステムの場合，ジョブとして，Management Serverのコマンドであるmngsvrutilコマンドを1実行単位で定義します。次に，運用計画に従って，ジョブネットごとに開始曜日や時刻などのスケジュールを設定して，JP1ジョブ運用管理サーバのJP1/AJSに登録します。例えば，WebサーバとJ2EEアプリケーション「AP1」「AP2」の起動と停止を，それぞれAM8:00とPM5:00に定義します。設定した時刻になると，JP1/AJSによって，ジョブとして定義したmngsvrutilコマンドが実行されます。

また，JP1/IMと連携しておけば，JP1/AJSによって自動実行されたジョブに異常が発生した場合に，運用管理者の携帯電話などに通知する運用もできます。

なお，Windowsの場合，アプリケーションサーバでは，このような運用を実現するために，カスタムジョブの提供による，ジョブ定義支援機能を提供しています。

(2)　JP1/AJSを使用したバッチアプリケーションの自動実行

バッチアプリケーションは，アプリケーションサーバで構築するバッチサーバ上でも実行できます。バッチサーバで動作するバッチアプリケーションは，アプリケーションサーバで提供するバッチ実行コマンドで開始します。バッチ実行コマンドをJP1/AJSのジョブとして定義することで，バッチアプリケーションの自動実行が実現します。

JP1/AJSを使用したバッチアプリケーションの自動実行を次の図に示します。

図14‒2　JP1/AJSを使用したバッチアプリケーションの自動実行の概要

また，JP1/AJSでは，BJEXまたはJP1/Advanced Shellと連携することもできます。BJEXまたはJP1/Advanced Shellと連携する場合は，JP1/AJSのジョブとして，BJEXまたはJP1/Advanced Shellのバッチジョブの実行コマンドを定義する必要があります。ジョブの定義については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「2.3.2　バッチアプリケーションの実行」を参照してください。

14.2.2　ジョブによるシステムの自動運転に必要なプログラム

システムの自動運転は，JP1/AJSを中心としたJP1のプログラム群と，アプリケーションサーバの運用管理機能を組み合わせて実現します。

JP1/AJSと連携してシステムの自動運転をする場合のシステム構築例を，J2EEサーバの場合とバッチサーバの場合に分けて説明します。

(1)　J2EEサーバの場合

J2EEアプリケーション実行環境で，システムを自動運転する場合のシステムの構成例を次の図に示します。

図14‒3　JP1/AJSと連携してシステムの自動運転をする場合のシステム構築例（J2EEサーバの場合）

それぞれの図中のJP1の各プログラムの主な機能を次に示します。なお，アプリケーションサーバの管理機能については，「1.2　システムの目的と機能の対応」を参照してください。

表14‒2　システムの自動運転をするために使用するJP1プログラムの機能（J2EEサーバの場合）

JP1プログラム

機能

配置するサーバ／

クライアント

JP1/Base

JP1/AJSの基盤機能を提供します。ユーザ権限の管理やJP1イベントの送受信をします。

アプリケーションサーバの運用管理サーバ

JP1ジョブ運用管理サーバ

JP1/AJS - Agent

JP1/AJSのエージェントです。JP1/AJS - Managerから転送されたジョブを実行します。

アプリケーションサーバの運用管理サーバ

JP1/AJS - Manager

JP1/AJSのマネジャです。

JP1ジョブ運用管理サーバ

JP1/AJS - View

GUIを使ってJP1/AJSを操作するための画面を提供します。JP1/AJS - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

運用管理クライアント

(2)　バッチサーバの場合

バッチアプリケーション実行環境で，システムを自動運転する場合のシステムの構成例を次の図に示します。

図14‒4　JP1/AJSと連携してシステムの自動運転をする場合のシステム構築例（バッチサーバの場合）

それぞれの図中のJP1の各プログラムの主な機能を次に示します。なお，アプリケーションサーバの管理機能については，「1.2　システムの目的と機能の対応」を参照してください。

表14‒3　システムの自動運転をするために使用するJP1プログラムの機能（バッチサーバの場合）

JP1プログラム

機能

配置するサーバ／

クライアント

JP1/Base

JP1/AJSの基盤機能を提供します。ユーザ権限の管理やJP1イベントの送受信をします。

バッチサーバ

JP1ジョブ運用管理サーバ

JP1/AJS - Agent

JP1/AJSのエージェントです。JP1/AJS - Managerから転送されたジョブを実行します。

バッチサーバ

JP1/AJS - Manager

JP1/AJSのマネジャです。

JP1ジョブ運用管理サーバ

JP1/AJS - View

GUIを使ってJP1/AJSを操作するための画面を提供します。JP1/AJS - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

運用管理クライアント

BJEXと連携する場合は，BJEXをバッチサーバに配置してください。また，JP1/Advanced Shellと連携する場合は，JP1/Advanced Shellをバッチサーバに配置してください。

14.2.3　カスタムジョブによるジョブの定義（Windowsの場合）

JP1/AJSでは，運用に使用するコマンド，バッチファイルなどをジョブとして定義して，それぞれのジョブの実行順序を関連づけることで，システム運用を自動化します。

Windowsの場合，ジョブを定義する際にカスタムジョブを使用すると，直接コマンドやバッチファイルをジョブに指定するのに比べて，容易，かつ間違いなく定義できます。

カスタムジョブとは，JP1/AJS以外のプログラムとJP1/AJSが連携するジョブを定義する場合に，目的のジョブを容易に作成するために使用できるジョブのテンプレートです。

アプリケーションサーバでは，次の2種類のカスタムジョブを提供しています。

論理サーバ制御用カスタムジョブ

アプリケーション制御用カスタムジョブ

これらのカスタムジョブを使用すると，GUI操作でアプリケーションサーバ用のジョブが定義できます。

アプリケーションサーバが提供するカスタムジョブによるシステムの自動運転の設定については，「14.3　ジョブによるシステムの自動運転の設定」を参照してください。また，カスタムジョブを定義する場合のJP1/AJS - Viewの操作方法については，マニュアル「JP1/Automatic Job Management System 操作ガイド」を参照してください。

なお，カスタムジョブはWindowsの場合だけ使用できます。このため，UNIXの場合は，JP1/AJS - Viewで，運用に使用するコマンドやバッチファイルなどを，ジョブとして定義する必要があります。ジョブの定義方法については，「14.3.5　ジョブの定義」を参照してください。

(1)　論理サーバ制御用カスタムジョブ

論理サーバの起動，停止を制御するジョブを定義するためのカスタムジョブです。監視時間の設定もできます。起動できる論理サーバは，次のとおりです。

パフォーマンストレーサ

スマートエージェント

ネーミングサービス

CTMドメインマネジャ

CTM

J2EEサーバ

バッチサーバ

Webサーバ

(2)　アプリケーション制御用カスタムジョブ

J2EEアプリケーション，バッチアプリケーション，およびJ2EEリソースアダプタの起動，停止を制御するジョブを定義するためのカスタムジョブです。監視時間の設定もできます。

14.2.4　論理サーバおよびJ2EEアプリケーションの起動と停止の自動化の仕組み

JP1/AJSで定義したジョブおよびジョブネットを使用して，論理サーバとJ2EEアプリケーションの起動と停止の運用を自動化します。

自動化した場合の処理の流れを次の図に示します。

図14‒5　論理サーバおよびJ2EEアプリケーションの起動と停止を自動化した場合の処理の流れ

ジョブネットで設定した時間になると，ジョブに定義した論理サーバやJ2EEアプリケーションの起動または停止を実行するためのコマンドとパラメタが，JP1/AJS - Managerから各ホストのJP1/AJS - Agentに送信されます。

ジョブの実行指示を受け取ったJP1/AJS - Agentは，ジョブに定義されていたアプリケーションサーバの運用管理コマンド（mngsvrutil）を実行して，Management Serverに処理を要求します。なお，JP1/AJS - Agentの処理は，要求が完了したところで終了します。

Management Serverは，各ホストの運用管理エージェントに対して，処理の実行を要求します。

運用管理エージェントによって，要求された処理が実行されます。

運用管理コマンド（mngsvrutil）の機能については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

14.3　ジョブによるシステムの自動運転の設定

この節では，JP1/AJSと連携して，ジョブによってアプリケーションサーバシステムの運用を自動化するための設定について説明します。

まず，次の表に示すサーバおよびクライアントに，システムの自動運転に必要なJP1の製品またはApplication Serverの製品の構成ソフトウェアをインストール，セットアップしておいてください。なお，JP1/AJSと連携する場合のシステム構成については，「14.2.2　ジョブによるシステムの自動運転に必要なプログラム」のジョブによるシステムの自動運転に必要なプログラムに関する説明を参照してください。

表14‒4　ジョブによるシステムの自動運転に必要な製品または構成ソフトウェア

サーバ／クライアント

製品／構成ソフトウェア

J2EEサーバ

Component Container

アプリケーションサーバの運用管理サーバ

JP1/Base

JP1/AJS - Agent

JP1ジョブ運用管理サーバ

JP1/Base

JP1/AJS - Manager

運用管理クライアント

JP1/AJS - View

ジョブを使用して，システムを自動運転化するための手順を次に示します。

アプリケーションサーバの運用管理サーバで，次の作業を実施します。

mngsvrutilコマンドの実行環境の設定（14.3.1参照）

J2EEサーバの運用監視の設定（14.3.2参照）

運用管理クライアントで，次の作業を実施します。

アプリケーションサーバのJP1/AJS定義プログラムのインストール（14.3.3参照）※

アプリケーションサーバのカスタムジョブの登録（14.3.4参照）※

ジョブの定義（14.3.5参照）

スケジュールの定義（14.3.6参照）

注※　Windowsの場合だけ実施してください。

14.3.1　mngsvrutilコマンドの実行環境の設定

JP1/AJSと連携してアプリケーションサーバシステムの運用を自動化する場合，論理サーバやJ2EEアプリケーションの実行には，Management Serverの運用管理コマンドであるmngsvrutilコマンドを利用します。mngsvrutilコマンドの実行環境は，mngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）に設定します。

アプリケーションサーバの運用管理サーバで，JP1/Baseのユーザマッピングで設定したOSユーザ（JP1/AJSがmngsvrutilコマンドを起動するときのOSユーザ）のホームディレクトリに，クライアント側定義ファイルを作成して，次のパラメタを指定します。

mngsvrutil.connect.host

Management Serverのホスト名とポート番号を指定します。

mngsvrutil.connect.userid

Management Serverのmngsvrctl setupコマンドで設定した管理ユーザIDを指定します。

mngsvrutil.connect.password

Management Serverのmngsvrctl setupコマンドで設定したパスワードを指定します。パスワードを設定していない場合，このパラメタの指定は省略できます。

Windowsの場合，アプリケーションサーバのカスタムジョブを利用して，論理サーバやJ2EEアプリケーションを実行する場合は，これら以外のパラメタの指定は無効になります。

クライアント側定義ファイルは，mngsvrutilコマンドのオプションのデフォルト値を設定するファイルです。

なお，mngsvrutilコマンドの実行環境を変更したい場合は，Management Serverの運用管理コマンドであるmngsvrutilコマンドのサーバ側定義ファイル（mngsvrutil.properties）で変更します。

ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.15　mngsvrutil.properties（mngsvrutilコマンドのサーバ側定義ファイル）」を参照してください。

参考

クライアント側定義ファイルはクライアントごとに個別のデフォルト値を設定する場合に使用します。すべてのクライアント共通のデフォルト値を設定したい場合は，クライアント側共通設定ファイル（mngsvrutilcl.properties）を使用してください。なお，両方のファイルを使用している場合は，クライアント側定義ファイルが適用されます。クライアント側共通設定ファイルは読み込まれません。

14.3.2　J2EEサーバの運用監視の設定

J2EEサーバの運用監視の設定手順を次に示します。

J2EEサーバの運用監視エージェントで運用監視をする設定をします。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.instrumentation.enabledパラメタで「true」を指定します。デフォルトの設定では，運用監視エージェントで運用監視をする設定になっています。

Management Serverおよび運用管理エージェントを再起動します。

再起動後に，設定した情報が有効になります。

運用管理エージェントとManagement Serverの起動および停止については，「2.6　システムの起動と停止の設定」を参照してください。

14.3.3　アプリケーションサーバのJP1/AJS定義プログラムのインストール（Windowsの場合）

JP1/AJS定義プログラムをJP1/AJS - View稼働マシンに格納します。

アプリケーションサーバが提供する次のファイルをJP1/AJS - View稼働マシンの任意のディレクトリにコピーしてください。

論理サーバ起動／停止ジョブ定義用の定義プログラム

<Application Serverのインストールディレクトリ>¥manager¥externals¥jp1¥ajs3_custom_jobs¥cmsvcjdf.exe

J2EEアプリケーション起動／停止ジョブ定義用の定義プログラム

<Application Serverのインストールディレクトリ>¥manager¥externals¥jp1¥ajs3_custom_jobs¥cmapcjdf.exe

14.3.4　アプリケーションサーバのカスタムジョブの登録（Windowsの場合）

次の2種類のカスタムジョブをJP1/AJS - Viewに登録します。

論理サーバ制御用カスタムジョブ

アプリケーション制御用カスタムジョブ

カスタムジョブの登録手順を次に示します。詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」を参照してください。

Windowsの［スタート］メニューから，［JP1_Automatic Job Management System 3 - View］−［カスタムジョブ登録］を選択します。

［カスタムジョブの登録］ダイアログが表示されます。

［新規登録］ボタンをクリックします。

［カスタムジョブ登録情報］ダイアログが表示されます。

論理サーバ制御用カスタムジョブおよびアプリケーション制御用カスタムジョブの情報を登録します。

名前

カスタムジョブ名を任意の1〜8バイトで指定します。

コメント

コメントを1〜40バイトで任意の文字列で指定します。この指定は省略できます。

定義プログラム

JP1/AJS - View稼働マシンにコピーしたアプリケーションサーバのカスタムジョブの定義プログラムを絶対パスで指定します。論理サーバ制御用カスタムジョブの場合は「cmsvcjdf.exe」，アプリケーション制御用カスタムジョブの場合は「cmapcjdf.exe」を指定してください。

実行プログラム

mngsvrutil.コマンドを指定します。次のパスを指定してください。

<Application Serverのインストールディレクトリ>¥manager¥bin¥mngsvrutil.exe

バージョン

「0600」を指定します。

バージョンはアプリケーションサーバのバージョンではなく，JP1/AJS - Viewのカスタムジョブのインタフェースのバージョンです。

クラス名

論理サーバ制御用カスタムジョブの場合は「COSMNGSV」，アプリケーション制御用カスタムジョブの場合は「COSMNGAP」を指定してください。

ジョブ種別

「PCジョブ」を選択してください。

［OK］ボタンをクリックします。

アプリケーションサーバのカスタムジョブがJP1/AJS - Viewに登録されます。

14.3.5　ジョブの定義

ジョブの定義についてOSごとに説明します。

(1)　Windowsの場合

カスタムジョブを登録すると，JP1/AJS - Viewでジョブネット中のジョブを定義するときにカスタムジョブが利用できるようになります。

アプリケーションサーバのカスタムジョブを使用したジョブの定義手順を次に示します。詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」のジョブの定義に関する説明を参照してください。

Windowsの［スタート］メニューから，［JP1_Automatic Job Management System 3 - View］−［ジョブシステム運用］を選択します。

［ログイン］画面が表示されるので，ユーザ名，パスワード，および接続ホスト名を指定してログインすると，［JP1/AJS3 - View］ウィンドウが表示されます。

［編集］−［新規作成］−［ジョブネット］を選択します。

［詳細定義−［ジョブネット］］ダイアログが表示されます。

ジョブネットに属性などを定義して，［OK］ボタンをクリックします。

ジョブネットが作成され，リストエリアに表示されます。

作成したジョブネットをダブルクリックします。

［ジョブネットエディタ］ウィンドウが表示されます。

ジョブを定義したり関連づけたりするときにほかのユーザがアクセスできないように，［排他編集］をチェックします。

アイコンリストから必要なカスタムジョブのアイコンをマップエリアへドラッグします。

［詳細定義−［Custom Job］］ダイアログが表示されます。

ジョブに属性などを定義します。

ユニット名

ユニット名を30バイト以内の文字列で指定します。デフォルトは，カスタムジョブを登録したときのコメントが表示されます。

コメント

ユニットのコメントを80バイト以内の文字列で指定します。

実行ホスト

mngsvrutilコマンドを実行させるJP1/AJS - Manager，またはJP1/AJS - Agentホスト名を255バイト以内の文字列で指定します。

終了判定

正常終了と異常終了の判定基準とする値を定義します。mngsvrutilコマンドは終了コードが０以外は異常終了となるので次のようにデフォルトの値を指定してください。

判定結果：「しきい値による判定」

警告しきい値：空白

異常しきい値：「０」

［詳細］ボタンをクリックします。

［詳細］ボタンをクリックすると，アプリケーションサーバの［論理サーバの制御］ダイアログが表示されます。

論理サーバ制御用カスタムジョブの場合は，アプリケーションサーバの［論理サーバの制御］ダイアログで，次の内容を指定します。

論理サーバの指定

起動／停止の対象となる論理サーバ名（クラスタを含む）を指定します。すべての論理サーバを対象にしたいときは「全て」を選択します。

監視時間間隔

論理サーバの起動／停止の完了を監視する際の監視時間間隔を，「3秒」，「10秒」，「30秒」，「1分」から選択します。デフォルトでは，「3秒」が選択されています。なお，起動／停止で障害が発生した場合，障害回復のためにリトライ処理が行われます。この監視時間間隔は，障害回復時のリトライ処理間隔としても利用されます。

最大監視時間

論理サーバの起動／停止の完了を監視する際の最大監視時間を，「監視しない」，「1分」，「5分」，「10分」，「60分」，「120分」から選択します。デフォルトでは，「1分」が選択されています。

起動／停止

論理サーバの起動／停止を指定します。

アプリケーション制御用カスタムジョブの場合は，アプリケーションサーバの［アプリケーションの制御］ダイアログで次の内容を指定します。

論理J2EEサーバ名

J2EEアプリケーションまたはリソースアダプタがインポートされている論理J2EEサーバ名またはJ2EEサーバクラスタ名を指定します。

J2EEアプリケーション／リソースアダプタの指定

起動／停止の対象となるJ2EEアプリケーション名またはリソースアダプタ名を指定します。「種別」でJ2EEアプリケーションまたはリソースアダプタを選択してから，「名前」にJ2EEアプリケーションまたはリソースアダプタ名を指定します。

監視時間間隔

J2EEアプリケーションまたはリソースアダプタの起動／停止の完了を監視する際の監視時間間隔を，「3秒」，「10秒」，「30秒」，「1分」から選択します。デフォルトでは，「3秒」が選択されています。なお，起動／停止で障害が発生した場合，障害回復のためにリトライ処理が行われます。この監視時間間隔は，障害回復時のリトライ処理間隔としても利用されます。

最大監視時間

J2EEアプリケーションまたはリソースアダプタの起動／停止の完了を監視する際の最大監視時間を，「監視しない」，「1分」，「5分」，「10分」，「60分」から選択します。デフォルトでは，「1分」が選択されています。

起動／停止

J2EEアプリケーションまたはリソースアダプタの起動／停止を指定します。

［OK］ボタンをクリックします。

ジョブネットにジョブが定義されます。必要に応じて，同様の手順で，ジョブを定義してください。

ジョブ同士を実行順序に従って関連づけます。

ジョブを関連づけたら，ジョブの定義は完了です。

JP1/AJS - Viewでのジョブの定義例を次の図に示します。

図14‒6　ジョブの定義例

(2)　UNIXの場合

UNIXジョブを使用したジョブの定義手順を次に示します。

UNIXジョブを使用したジョブの定義には，JP1/AJS - Viewを使用します。JP1/AJS - Viewがインストールされた運用管理クライアント（Windows）で実施してください。詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」のジョブの定義に関する説明を参照してください。

Windowsの［スタート］メニューから，［JP1_Automatic Job Management System 3 - View］−［ジョブシステム運用］を選択します。

［ログイン］画面が表示されるので，ユーザ名，パスワード，および接続ホスト名を指定してログインすると，［JP1/AJS3 - View］ウィンドウが表示されます。

［編集］−［新規作成］−［ジョブネット］を選択します。

［詳細定義−［ジョブネット］］ダイアログが表示されます。

ジョブネットに属性などを定義して，［OK］ボタンをクリックします。

ジョブネットが作成され，リストエリアに表示されます。

作成したジョブネットをダブルクリックします。

［ジョブネットエディタ］ウィンドウが表示されます。

ジョブを定義したり関連づけたりするときにほかのユーザがアクセスできないように，［排他編集］をチェックします。

アイコンリストから必要なUNIXジョブのアイコンをマップエリアへドラッグします。

［詳細定義−［UNIX Job］］ダイアログが表示されます。

ジョブに属性などを定義します。

ユニット名

ユニット名を30バイト以内の文字列で指定します。

コメント

ユニットのコメントを80バイト以内の文字列で指定します。

実行ホスト

mngsvrutilコマンドを実行させるJP1/AJS - Manager，またはJP1/AJS - Agentのホスト名を255バイト以内の文字列で指定します。

スクリプトファイル名

mngsvrutilコマンドを指定します。

パラメーター

論理サーバの開始／停止やアプリケーションの開始／停止などを行うためのmngsvrutilコマンドの引数を指定します。

終了判定

正常終了と異常終了の判定基準とする値を定義します。mngsvrutilコマンドは終了コードが０以外は異常終了となるので次のようにデフォルトの値を指定してください。

判定結果：「しきい値による判定」

警告しきい値：空白

異常しきい値：「０」

［OK］ボタンをクリックします。

ジョブネットにジョブが定義されます。必要に応じて，同様の手順で，ジョブを定義してください。

ジョブ同士を実行順序に従って関連づけます。

ジョブを関連づけたら，ジョブの定義は完了です。

JP1/AJS - Viewでのジョブの定義例を次の図に示します。

図14‒7　ジョブの定義例

14.3.6　スケジュールの定義

JP1/AJS - Viewでジョブネットにスケジュールを定義します。スケジュールの定義では，業務の運用日・休業日を設定したカレンダー，実行を開始する日時や実行間隔などを定義します。ジョブネットにスケジュールを定義しておくと，決められた日時にジョブネットを自動的に開始できるようになります。

スケジュールの定義に必要な作業について説明します。

ジョブグループにカレンダー情報を定義します。

JP1/AJS - View の［月間カレンダー編集］ウィンドウ，または［年間カレンダー編集］ウィンドウでジョブグループにカレンダー情報（運用日と休業日）を定義します。

カレンダー情報は，ジョブグループ単位で定義します。定義したカレンダー情報は，そのジョブグループ中のすべてのジョブネットに有効です。ただし，各ジョブネットにスケジュールを定義する際，ほかのジョブグループのカレンダー情報を使用するように指定することもできます。ネストしたジョブグループの場合，上位のジョブグループのカレンダー情報を引き継げるので，カレンダー情報の定義は任意です。

ジョブネットにスケジュールを定義します。

JP1/AJS - View の［スケジュールの設定］ダイアログ，および［スケジュールルール］ダイアログで，ジョブネットにスケジュールを定義します。スケジュールとして定義するのは，スケジュールの有効期限や，ジョブネットの実行開始日時，実行処理サイクル，使用するカレンダー情報などです。

スケジュールはジョブネット単位で定義します。ただし，ネストジョブネットの場合，上位のジョブネットのスケジュールルールを引き継ぐこともできるので，スケジュールルールの定義は任意です。

なお，詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」のスケジュール定義に必要な作業に関する説明を参照してください。

15　クラスタソフトウェアとの連携

この章では，クラスタソフトウェアと連携したシステムの運用について説明します。

15.1　この章の構成

この章の構成を次の表に示します。

表15‒1　この章の構成（クラスタソフトウェアとの連携）

分類

タイトル

参照先

解説

クラスタソフトウェアと連携して実現できる運用

15.2

クラスタソフトウェアと連携するための前提条件

15.3

注　「実装」，「設定」，「運用」，「注意事項」について，この機能固有の説明はありません。

15.2　クラスタソフトウェアと連携して実現できる運用

この節では，クラスタソフトウェアと連携するための設定の概要について説明します。

クラスタソフトウェアとは，システムの信頼性および稼働率の向上を目的とした，サーバプログラムを含めたシステムの切り替えを実現するプログラムです。アプリケーションサーバでは，次に示すクラスタソフトウェアと連携できます。

Windows Server Failover Cluster

Windows Serverの場合に使用するクラスタソフトウェアです。詳細は，使用するクラスタソフトウェア/OSのマニュアルを参照してください。

ご使用のOSに合わせて，次のように用語を読み替えてください。

マニュアルに記載の用語

Windows Server 2012以降の用語

クラスタアドミニストレータ

フェールオーバー クラスター マネージャー

グループ，またはリソースグループ

クラスター化された役割

HAモニタ

AIXまたはLinuxの場合に使用するクラスタソフトウェアです。

クラスタソフトウェアと連携してシステムを運用することで，アプリケーションサーバに障害が発生した場合に，直ちに自動でアプリケーションサーバを切り替えたり，待機しているリカバリサーバで，障害が発生したアプリケーションサーバのリカバリ処理をしたりできます。また，運用管理サーバに障害が発生した場合にも，待機させておいた運用管理サーバに切り替えることができます。これによって，システムの不稼働時間を短縮でき，信頼性や稼働率を高めることができます。

注意事項

運用管理エージェントとManagement Serverの障害を監視して，クラスタソフトウェアと連携してシステムを切り替える場合は，運用管理エージェントとManagement Serverに自動再起動を設定しないでください。

アプリケーションサーバのシステムでは，クラスタソフトウェアと連携して運用することで，障害によるシステムの不稼働時間を短縮したり，障害発生時でも業務の継続を可能にしたりできます。アプリケーションサーバでは，次に示すクラスタソフトウェアとの連携による系切り替え機能を使用します。

1:1系切り替えシステム

アプリケーションサーバの1:1系切り替え

実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1にした構成とすることで，実行系のアプリケーションサーバに障害が発生したときに系を切り替えて，業務を続行できます。

運用管理サーバの1:1系切り替え

実行系の運用管理サーバと待機系の運用管理サーバを1:1にした構成とすることで，実行系の運用管理サーバに障害が発生したときに系を切り替えて，業務を続行できます。

相互系切り替え

実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1にして，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能するシステムです。少ない台数のアプリケーションサーバマシンで，むだの少ない運用ができるようになります。

N:1リカバリシステム

N台の実行系のアプリケーションサーバに対して，1台のリカバリ専用の待機系のアプリケーションサーバを配置するシステムです。J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したとき，リカバリ専用サーバでトランザクションを決着できるようになります。

ホスト単位管理モデルを対象にした系切り替えシステム

アプリケーションサーバマシン（ホスト）の実行系複数（1〜N台）と待機系1台を配置し，それぞれにManagement Serverおよび運用管理エージェントを配置するシステムです。実行系のアプリケーションサーバマシンに障害が発生したときに待機系のアプリケーションサーバマシンに系を切り替えて，業務を続行できます。

参考

アプリケーションサーバで1:1系切り替えシステム，N:1リカバリシステムおよびホスト単位管理モデルを対象にした系切り替えシステムを構築，および運用するためには，次のクラスタソフトウェアを使用します。

Windows Server Failover Cluster（Windowsの場合）

HAモニタ（AIXまたはLinuxの場合）

なお，クラスタソフトウェアと連携する場合には，次の用語を理解しておいてください。

クラスタソフトウェアでは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器を含めたシステム全体の総称を系といいます。システムで動作中の系を区別する呼び方に，実行系・待機系があります。

実行系

現在実行中のサーバがある系のことです。系切り替えが発生すると，待機系になります。

待機系

現在待機中のサーバがある系のことです。系切り替えが発生すると，実行系になります。

また，システムの設定などで，システムが動作していないときの系を区別する呼び方に，現用系・予備系があります。

現用系

起動したときに，最初に実行系として起動される系のことです。

予備系

起動したときに，最初に待機系として起動される系のことです。

アプリケーションサーバではクラスタソフトウェアと連携することによって，J2EEアプリケーションの実行環境の系切り替え構成でシステムを運用できます。

クラスタソフトウェアとの連携による系切り替え機能の参照先を次に示します。

表15‒2　クラスタソフトウェアとの連携による系切り替え機能

機能

参照先

1:1系切り替えシステム

アプリケーションサーバの1:1系切り替え※

17.2

運用管理サーバの1:1系切り替え

17.2

相互系切り替え

18.2

N:1リカバリシステム※

19.2

ホスト単位管理モデルを対象とした系切り替えシステム

16.2

注※　これらのシステムは，Smart Composer機能では構築できません。運用管理ポータルを使用して，システムを構築してください。

15.2.1　実行系と待機系を1:1で運用するシステムとは（1:1系切り替えシステム）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，アプリケーションサーバの1:1系切り替えシステムでの運用と，運用管理サーバの1:1系切り替えシステムでの運用をサポートしています。ただし，バッチアプリケーションの実行環境では，運用管理サーバを配置しないため，運用管理サーバの1:1系切り替えシステムの運用はできません。

1:1系切り替えシステムでは，実行系に何らかの障害が発生すると，クラスタソフトウェアがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守，その他必要があるときには，オペレータの操作によって待機している系に計画的に切り替えることができます。

1:1系切り替えシステムの詳細については，「17.　1:1系切り替えシステム（クラスタソフトウェアとの連携）」を参照してください。

15.2.2　相互スタンバイで運用するシステムとは（相互系切り替えシステム）

相互系切り替えシステムとは，1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。アプリケーションサーバでは，アプリケーションサーバの相互切り替えシステムでの運用をサポートしています。

相互系切り替えシステムでは，各サーバでそれぞれJ2EEアプリケーションまたはバッチアプリケーションを動作させて，障害が発生した場合は自動的に相互の待機している系に切り替えて業務を続行します。また，1:1系切り替えシステムの場合と同様に，障害が発生しなくても実行中のシステムに予防保守，その他必要があるときには，オペレータの操作によって待機している系に計画的に切り替えることができます。

相互系切り替えシステムの詳細については，「18.　相互系切り替えシステム（クラスタソフトウェアとの連携）」を参照してください。

15.2.3　待機系をリカバリ専用サーバとして運用するシステムとは（N:1リカバリシステム）

N:1リカバリシステムとは，クラスタ構成になっている実行系の複数（N台）のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。

業務は，実行系のアプリケーションサーバで実行します。業務実行中のアプリケーションサーバに障害が発生すると，リカバリ専用サーバで，障害が発生したアプリケーションサーバの仕掛かり中のトランザクションを決着します。

なお，バッチサーバの場合，N:1リカバリシステムは使用できません。

N:1リカバリシステムの詳細については，「19.　N:1リカバリシステム（クラスタソフトウェアとの連携）」を参照してください。

15.2.4　実行系と待機系のアプリケーションサーバマシン（ホスト）をN:1で運用するシステムとは（ホスト単位管理モデルを対象にした系切り替えシステム）

ホスト単位管理モデルを対象にした系切り替えシステムとは，実行系のアプリケーションサーバN台と待機系のアプリケーション1台のそれぞれにManagement Serverおよび運用管理エージェントを配置する構成で，ホスト単位管理モデルを対象にした系切り替えシステムでの運用をサポートしています。

ホスト単位管理モデルを対象にした系切り替えシステムでは，実行系のManagement Serverや運用管理エージェントに障害が発生すると，クラスタソフトウェアがこれを検知して，待機している系に切り替えて業務を続行します。

ホスト単位管理モデルを対象にした系切り替えシステムの詳細については，「16.　ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）」を参照してください。

15.3　クラスタソフトウェアと連携するための前提条件

クラスタソフトウェアと連携してシステムを運用するための前提条件について説明します。

15.3.1　系切り替えの管理対象となるサーバ

クラスタソフトウェアと連携してシステムを運用する場合に，系切り替えの管理対象となるサーバを次の表に示します。

表15‒3　系切り替えの管理対象となるサーバ

系切り替えの種類

系切り替えの管理対象となるサーバ

クラスタソフトウェアと連携してシステムを運用する場合のシステム構成例

1:1系切り替えシステム

運用管理サーバモデルのアプリケーションサーバ，運用管理サーバ

「17.3.1　1:1系切り替えシステムのシステム構成例」を参照。

相互系切り替えシステム

運用管理サーバモデルのアプリケーションサーバ

「18.3.1　相互系切り替えシステムのシステム構成例」を参照。

N:1系切り替えシステム

運用管理サーバモデルのアプリケーションサーバ

「19.3.1　N:1リカバリシステムのシステム構成例」を参照。

ホスト単位管理モデルを対象にした系切り替えシステム

ホスト単位管理モデルのアプリケーションサーバ

「16.2.1　ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成例」を参照。

15.3.2　ライトトランザクション機能の利用

クラスタソフトウェアと連携する場合，ライトトランザクション機能を有効にしているかどうかによって，使用できる系切り替えの種類が異なります。系切り替えの種類とライトトランザクション機能の利用について次の表に示します。なお，実行系と待機系は，同じ動作モードにすることが前提となります。

表15‒4　系切り替えの種類とライトトランザクション機能の利用

系切り替えの種類

ライトトランザクション

有効

無効

1:1系切り替えシステム

○

○

相互系切り替えシステム

○

○

N:1系切り替えシステム

×

○

ホスト単位管理モデルを対象にした系切り替えシステム

○

○

（凡例）　○：使用できる　　×：使用できない

なお，バッチアプリケーション実行環境の場合，ライトトランザクション機能を有効にするため，N:1系切り替えシステムは使用できません。

15.3.3　システムの運用方法

クラスタソフトウェアと連携する場合，系切り替えの種類にかかわらず，Management Serverを利用してシステムを運用することが前提となります。

クラスタソフトウェアと連携する場合の設定については，「15.2　クラスタソフトウェアと連携して実現できる運用」を参照してください。

参考

アプリケーションサーバの1:1系切り替えシステムの場合，クラスタソフトウェアは，運用管理エージェント（アプリケーションサーバシステムを管理するプロセス）を監視します。

運用管理サーバの1:1系切り替えシステムの場合，クラスタソフトウェアは，Management Serverを監視します。

Management Serverまたは運用管理エージェントを含む系の切り替えの場合，システム起動時は，Management Serverおよび運用管理エージェントの起動完了後に，システムを起動してください。

設定方法については，「2.6　システムの起動と停止の設定」を参照してください。

15.3.4　実行系の前提条件

N:1系切り替えシステムの場合，実行系アプリケーションサーバは次に示す前提条件を満たしている必要があります。なお，1:1系切り替えシステム，および相互系切り替えシステムの場合，実行系に前提条件はありません。

グローバルトランザクションを使用します。

CORBAネーミングサービスおよびトランザクションサービスは，インプロセスで使用します。

トランザクションサービスのステータスファイルは共有ディスク装置のディレクトリに格納します。

15.3.5　待機系の前提条件

待機系の前提条件を次に示します。

なお，クラスタソフトウェアと連携してシステムを運用する場合，待機系はコールドスタンバイで系切り替えを待ちます。コールドスタンバイとは，系切り替えが発生したあとに待機系のサーバが起動する方法です。

(1)　1:1系切り替えシステム，相互系切り替えシステムおよびホスト単位管理モデルを対象にした系切り替えシステムの場合

1:1系切り替えシステム，相互系切り替えシステム，およびホスト単位管理モデルを対象にした系切り替えシステムの場合，待機系のアプリケーションサーバではアプリケーションサーバ関連のプロセスは起動できません。このため，次の操作ができないので注意してください。

J2EEサーバへのアプリケーションのデプロイおよびアンデプロイ

J2EEアプリケーションの入れ替えも含みます。

Management Serverおよび運用管理エージェントによる管理操作

また，待機系のアプリケーションサーバからは共有ディスク装置へのアクセスはできません。J2EEサーバを使用している場合でグローバルトランザクションのとき，共有ディスク装置にはトランザクションサービスなどの定義情報が保持されます。ただし，待機系のアプリケーションサーバからこの定義情報を変更することはできません。

(2)　N:1系切り替えシステムの場合

N:1リカバリシステムの場合，待機系はリカバリ専用サーバとなります。待機系のリカバリ専用サーバの前提条件を次に示します。

グローバルトランザクションを使用します。

CORBAネーミングサービスおよびトランザクションサービスはインプロセスで動作させます。

実行系のアプリケーションサーバ上のJ2EEサーバと同じ名称のJ2EEサーバが，待機系のリカバリ専用サーバ上で動作している必要があります。

実行系のアプリケーションサーバで使用しているリソースアダプタと同じ設定のリソースアダプタをインポートし，デプロイ，開始しておきます。なお，リカバリ専用サーバには実行系で使用しているリソースアダプタをすべてインポートする必要があります。

リカバリ専用サーバは，障害が発生したアプリケーションサーバのトランザクションを決着するために使用するサーバであるため，J2EEアプリケーションをデプロイする必要はありません。

バッチアプリケーションの実行環境では使用できません。

なお，待機系であるリカバリ専用サーバマシンには，リカバリ処理をするリソースアダプタを，あらかじめ設定しておく必要があります。また，N:1リカバリが有効に動作するためには，次の二つの条件を満たしている必要があります。

実行系のアプリケーションサーバで起動しているJ2EEサーバと同じ名称のJ2EEサーバが，待機系のリカバリ専用サーバにあること。

実行系のJ2EEサーバでスタート状態にあるリソースアダプタの設定とまったく同じ設定のリソースアダプタが，待機系のJ2EEサーバに常に存在すること。

16　ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）

この章では，ホスト単位管理モデルを対象にした系切り替えシステムで運用するシステムについて説明します。

16.1　この章の構成

この章の構成を次の表に示します。

表16‒1　この章の構成（ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携））

分類

タイトル

参照先

解説

ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成と動作

16.2

設定

ホスト単位管理モデルを対象にした系切り替えシステムの設定

16.3

運用

ホスト単位管理モデルを対象にした系切り替えシステムの起動と停止

16.4

注　「実装」，「注意事項」について，この機能固有の説明はありません。

ホスト単位管理モデルを対象にした系切り替えシステムとは，複数（1〜N台）の実行系アプリケーションサーバマシン（ホスト）と1台の待機系アプリケーションサーバマシン（ホスト）を配置し，それぞれにManagement Serverおよび運用管理エージェントを配置するシステムです。

16.2　ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成と動作

ここでは，ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成例と系切り替え処理の流れについて説明します。

16.2.1　ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成例

実行系N台のホスト単位管理モデルを対象にした系切り替えシステムの構成例を次の図に示します。

図16‒1　ホスト単位管理モデルを対象にした系切り替えシステムのシステム構成例

図のホスト単位管理モデルを対象にした系切り替えシステムについて説明します。

アプリケーションサーバマシン（ホスト）の実行系N台と待機系1台を配置し，それぞれにManagement Serverおよび運用管理エージェントを配置するクラスタ構成のシステムです。実行系のアプリケーションサーバごとに仮想ホストが定義されたサーバが1台または複数台あります。これに対して，1台の待機系アプリケーションサーバに複数の仮想ホストが定義されています。仮想ホストの説明については，「18.3.1　相互系切り替えシステムのシステム構成例」を参照してください。

実行系のアプリケーションサーバで障害が発生すると待機系に切り替えられます。例えば，図中の実行系の仮想ホスト1のManagement Serverで障害が発生した場合，待機系の仮想ホスト1に系が切り替えられます。

実行系および待機系のそれぞれのアプリケーションサーバの運用に使用するIPアドレスは，クラスタソフトウェアによって割り当てられる仮想IPアドレスを使用します。

2台以上の実行系を1台の待機系に対応させる場合は，Management Server，運用管理エージェントのIPアドレスには，系切り替えによって他系へ移動しない実IPアドレスを使用します。1台の実行系を1台の待機系に対応させる場合は，Management Server，運用管理エージェントのIPアドレスは，仮想IPアドレス／実IPアドレスのどちらでも指定可能です。

なお，ホスト単位管理モデルを対象にした系切り替えシステムでは次のような運用ができます。

共有ディスク装置の使用

共有ディスク装置は，系切り替え時にOTSのステータスなどのトランザクション情報を引き継ぐために使用します。なお，クラスタソフトウェアがHAモニタの場合，ローカルトランザクションを使用するときは不要となります。

16.2.2　系切り替えのタイミング

系切り替えは次のタイミングで実施されます。

運用管理エージェントまたはManagement Serverがダウンしたとき※1。

論理サーバの自動再起動回数がシステム構築時に設定した自動再起動回数を超えたとき※2。

系のハードウェアやクラスタソフトウェアで障害が発生したとき。

注※1

運用管理エージェントとManagement Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実施されません。このタイミングで系切り替えを実施する場合は，運用管理エージェントとManagement Serverに自動再起動を設定しないでください。

注※2

mserver.properties（Management Server 環境設定ファイル）のcom.cosminexus.mngsvr.logical_server_abnormal_stop.exitキーに論理サーバの稼働状況を示すステータスが異常停止状態（自動再起動回数を超えた状態，または自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系を切り替える設定（true）が必要です。mserver.properties（Management Server 環境設定ファイル）の設定については，「16.3.3　設定ファイルの編集」を参照してください。Management Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実行されません。このタイミングで系切り替えを実行する場合は，Management Serverに自動再起動を設定しないでください。自動再起動を設定している場合は，mngautorunコマンドで設定を解除してください。mngautorunコマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「mngautorun（自動起動および自動再起動の設定／設定解除）」を参照してください。

ただし，実行系が2台以上ある場合は，待機系で複数の実行系のシステムが稼働する可能性があるため，com.cosminexus.mngsvr.logical_server_abnormal_stop.exitキーにtrueを指定しないでください。

16.2.3　系切り替え処理の流れ

ホスト単位管理モデルを対象にした系切り替え処理の流れを次の図に示します。

図16‒2　系切り替え処理の流れ

障害を検知します。

実行系2の運用管理エージェントで障害が発生し，ダウンすると，待機系のクラスタソフトウェアは実行系2の運用管理エージェントの障害を検知します。

系の切り替えを実施します。

待機系のクラスタソフトウェアは，実行系2の仮想ホスト2を待機系の仮想ホスト2に切り替えます。このとき，共有ディスク装置の切り替え，および仮想ホストのIPアドレスの引き継ぎをします。

待機系の運用管理エージェントを起動します。

運用管理エージェントに仮想IPアドレスを使用している場合だけ，待機系のクラスタソフトウェアが運用管理エージェントを起動します。

待機系のManagement Serverを起動します。

Management Serverに仮想IPアドレスを使用している場合だけ，待機系のクラスタソフトウェアがManagement Serverを起動します。

論理サーバを起動します。

運用管理エージェントが待機系の仮想ホスト2の論理サーバを起動します。

運用管理エージェント，Management Serverおよび論理サーバの起動はクラスタシステムに登録するサーバ起動スクリプトで実施されます。サーバ起動スクリプトについては，使用するOSのマニュアルを参照してください。

16.3　ホスト単位管理モデルを対象にした系切り替えシステムの設定

ホスト単位管理モデルを対象にした系切り替えシステムは，アプリケーションサーバマシン（ホスト）の実行系複数（1〜N台）と待機系1台の，それぞれにManagement Serverおよび運用管理エージェントを配置するシステムです。

この節では，ホスト単位管理モデルを対象にした系切り替えシステムの設定について説明します。

16.3.1　ホスト単位管理モデルを対象にした系切り替えシステムの設定手順

ホスト単位管理モデルを対象にした系切り替えシステムの設定手順を次の図に示します。

図16‒3　ホスト単位管理モデルを対象にした系切り替えシステムの設定手順

図中の1.〜6.について説明します。

共有ディスクにパーティションを作成して，ファイルシステムを構築します。

グローバルトランザクションを使用する場合には，トランザクション情報の格納場所を作成します。なお，HAモニタを使用している場合，ローカルトランザクションを使用するときは不要となります。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系1の仮想ホスト1と予備系の仮想ホスト1，現用系2の仮想ホスト2と予備系の仮想ホスト2で，同じドライブ文字を割り当ててください。

Management Serverでクラスタサーバの環境を設定します。

Management ServerのSmart Composer機能の簡易構築定義ファイルで，クラスタサーバの環境（論理サーバを設置するホストおよび各論理サーバ）を設定します。詳細については，「16.3.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

運用管理エージェントやManagement Serverで使用する各種定義ファイルを設定します。詳細については，「16.3.3　設定ファイルの編集」を参照してください。

クラスタの設定をします。

クラスタソフトウェアの環境設定やManagement Severと運用管理エージェントを監視するスクリプトファイルを作成します。詳細については，「16.3.4　クラスタの設定」を参照してください。

アプリケーションサーバを設定します。

アプリケーションサーバをクラスタ構成に配置して，J2EEアプリケーションはリソースアダプタを設定します。詳細については，「16.3.5　アプリケーションサーバの設定」を参照してください。

現用系および予備系の両方に対して，上記の手順を実施します。

参考

論理サーバは別々のホスト内に配置されているが，外部からは同じ論理サーバとして動作するのに対し，Management Serverは別々のホスト内で別々に動作し，それぞれ運用管理ドメインを持ちます。一つの運用管理ドメイン内に一つの仮想ホストを定義し，それぞれを現用系アプリケーションサーバのホスト，予備系アプリケーションサーバのホストとして構築します。仮想ホストとは，運用管理エージェントによってアプリケーションサーバの起動，停止を制御しますが，運用に使用するIPアドレスと同じIPアドレスを割り当て，見かけ上同じホストであるかのように定義したものです。

16.3.2　クラスタサーバの環境設定

クラスタソフトウェアと連携する場合の，クラスタサーバの環境設定時のManagement Serverでの留意点について説明します。

参考

Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。Management Serverのセットアップについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.14　運用管理機能を構築する」を参照してください。

(1)　簡易構築定義ファイルでの設定

Management ServerのSmart Composer機能の簡易構築定義ファイルで，論理サーバを設置するホストおよび各論理サーバを定義します。

なお，クラスタサーバの環境設定は運用管理ポータルを使用しても設定できます。運用管理ポータルでの操作については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

(a)　ホストの定義

運用管理ドメイン内のホストを定義します。現用系および予備系の仮想ホストで，<host-name>タグにそれぞれのサーバの運用に使用する仮想IPアドレスを設定します。

(b)　論理サーバの設定

論理J2EEサーバ（j2ee-server）および論理Webサーバ（web-server）設定時の留意点を次に示します。

論理J2EEサーバ（j2ee-server）の設定

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のパラメタに，必要に応じて仮想IPアドレスおよび実IPアドレスを設定してください。

論理J2EEサーバ（j2ee-server）の<configuration>タグ内で設定するパラメタを次の表に示します。

表16‒2　論理J2EEサーバ（j2ee-server）の<configuration>タグ内で設定するパラメタ

パラメタ名

内容

設定するIPアドレス

vbroker.se.iiop_tp.host

J2EEサーバ単位でEJBコンテナのホスト名またはIPアドレス

仮想IPアドレス

webserver.connector.http.bind_host

Webコンテナの管理用サーバで使用するローカルIPアドレス，または解決できるローカルホスト名称

仮想IPアドレス

webserver.connector.nio_http.bind_host

NIO HTTPサーバで使用するIPアドレスまたはホスト名

仮想IPアドレス

webserver.connector.http.permitted.hosts

Webコンテナの管理用サーバへのアクセスを許可するホストのIPアドレスまたはホスト名

実IPアドレス，仮想IPアドレス，

localhost※1

add.jvm.arg

JavaVMの起動パラメタ※2

-Djava.rmi.server.hostname=<仮想IPアドレス>

注※1　ここで示している設定は，論理J2EEサーバと同じホストからのアクセスを許可するものです。運用上，ほかのホストからのアクセスを受け付ける場合は，そのホストのIPアドレスまたはホスト名を追加してください。

注※2　予備系のすべてのJ2EEサーバに対して設定してください。予備系で設定しない場合，J2EEサーバの稼働監視が失敗して，J2EEサーバの稼働状況が異常停止になることがあります。現用系での設定は不要です。また，1：1系切り替えシステムでは，現用系および予備系のどちらの設定も不要です。

論理Webサーバの設定

論理Webサーバ（web-server）の<configuration>タグ内の次のパラメタを設定して，ホストを固定してください。なお，IPアドレスには仮想IPアドレスを設定してください。

Listenパラメタ（リクエストを受け付けるIPアドレスまたはホスト名）

16.3.3　設定ファイルの編集

クラスタソフトウェアと連携する場合の，Management Serverで使用する設定ファイルを編集するときの留意点について説明します。なお，adminagent.propertiesファイルについては，マニュアル「アプリケーションサーバ リファレンス定義編(サーバ定義)」の「8.2.1　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

(1)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）に設定する項目のうち，クラスタソフトウェアと連携する場合に留意する設定項目について説明します。

adminagent.adapter.bind_host

2台以上の実行系を1台の待機系に対応させる場合は，adminagent.adapter.bind_hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，adminagent.adapter.bind_hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

(2)　Management Serverの設定

mserver.properties（Management Server環境設定ファイル）に設定する項目のうち，クラスタソフトウェアと連携する場合に留意する設定項目について説明します。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit

論理サーバの稼働状況を示すステータスが異常停止状態（自動再起動回数を超えた状態，または自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系を切り替えるための設定（true）をします。

設定例を次に示します。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit=true

注意事項

Management Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実行されません。このタイミングで系切り替えを実行する場合は，Management Serverに自動再起動を設定しないでください。

また，実行系が2台以上ある場合は，待機系で複数の実行系のシステムが稼働する可能性があるため，com.cosminexus.mngsvr.logical_server_abnormal_stop.exit=trueを指定しないでください。

webserver.connector.http.bind_host

2台以上の実行系を1台の待機系に対応させる場合は，webserver.connector.http.bind_hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，webserver.connector.http.bind_hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

mngsvr.myhost.name

2台以上の実行系を1台の待機系に対応させる場合は，mngsvr.myhost.nameキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，mngsvr.myhost.nameキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

(3)　Managementイベント発行用プロパティファイルの設定

mevent.<論理サーバ名>.properties（Managementイベント発行用プロパティファイル）はJ2EEサーバに関連する設定ファイルのため，Smart Composer機能でシステムを構築したあとに作成されます。システム構築後に，次のキーを設定してください。

manager.mevent.send.host

2台以上の実行系を1台の待機系に対応させる場合は，manager.mevent.send.hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，manager.mevent.send.hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

(4)　Management Serverの運用管理コマンド（mngsvrutil）の設定

Management Serverの運用管理コマンド（mngsvrutil）のクライアント側定義ファイル（.mngsvrutilrc）またはクライアント側共通定義ファイル（mngsvrutilcl.properties）に次のキーを設定してください。

mngsvrutil.connect.host

2台以上の実行系を1台の待機系に対応させる場合は，mngsvrutil.connect.hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，mngsvrutil.connect.hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

mngsvrutil.target_name

mngsvrutil.target_nameキーに仮想IPアドレスを指定します。なお，このキーはホスト名を指定するときだけ設定してください。

参考

.mngsvrutilrcファイルはクライアントごとに個別のデフォルト値を設定する場合に使用します。すべてのクライアント共通のデフォルト値を設定したい場合は，mngsvrutilcl.propertiesファイルを使用してください。なお，両方のファイルを使用している場合は，.mngsvrutilrcファイルが適用されます。mngsvrutilcl.propertiesファイルは読み込まれません。

このファイルは，Management Serverを監視，起動，および停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

(5)　Smart Composer機能で提供するコマンドの設定

クライアント設定プロパティファイル（.cmxrc）またはクライアント共通設定プロパティファイル（cmxclient.properties）に次のキーを設定してください。

cmx.connect.host

2台以上の実行系を1台の待機系に対応させる場合は，cmx.connect.hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，cmx.connect.hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

参考

.cmxrcファイルはクライアントごとに個別のデフォルト値を設定する場合に使用します。すべてのクライアント共通のデフォルト値を設定したい場合は， cmxclient.propertiesファイルを使用してください。なお，両方のファイルを使用している場合は，.cmxrcファイルが適用されます。cmxclient.propertiesファイルは読み込まれません。

(6)　モニタ起動コマンドの設定（Windowsの場合）

モニタ起動コマンドはWindowsの場合だけ使用できます。

.mngsvrmonitorrc（JP1/IM連携用モニタ起動設定ファイル）に次のキーを設定してください。なお，.mngsvrmonitorrcファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.17　.mngsvrmonitorrc（JP1/IM連携用モニタ起動コマンドの設定ファイル）」を参照してください。

mngsvrmonitor.connect.host

2台以上の実行系を1台の待機系に対応させる場合は，mngsvrmonitor.connect.hostキーに実IPアドレスを指定します。

1台の実行系を1台の待機系に対応させる場合は，mngsvrmonitor.connect.hostキーに仮想IPアドレス／実IPアドレスのどちらでも指定できます。

16.3.4　クラスタの設定

クラスタに対して，次の設定を実施します。

スクリプトファイルの作成

クラスタソフトウェアの環境設定

(1)　スクリプトファイルの作成

Management Server，運用管理エージェント，およびアプリケーションサーバを起動・停止するためのスクリプトファイルを作成します。また，スクリプトファイルでクラスタの監視方法を決めておく必要があります。スクリプトファイルの作成については，使用するOSのマニュアルを参照してください。

ここでは，ホスト単位管理モデルを対象にした系切り替えの監視対象および監視方法について説明します。

(a)　監視対象

Management Server

運用管理エージェント

論理サーバ※

注※

論理サーバが異常停止状態（自動再起動回数を超えた状態，自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系切り替えが実行されます。mserver.properties（Management Server環境設定ファイル）の次のキーを設定してください。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit=true

Management Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実行されません。このタイミングで系切り替えを実行する場合は，Management Serverに自動再起動を設定しないでください。

ただし，実行系が2台以上ある場合は，待機系で複数の実行系のシステムが稼働する可能性があるため，com.cosminexus.mngsvr.logical_server_abnormal_stop.exitキーにtrueを指定しないでください。

(b)　監視方法

ホスト単位管理モデルを対象にした系切り替えで実施する監視方法を次に示します。

使用する運用または環境に合わせて，次のどちらかの方法を使用してください。

プロセス監視

監視処理にあまり負荷はかかりません。

プロセス監視とヘルスチェック

プロセス監視だけの場合より監視する精度は高くなりますが，監視処理に多少負荷が掛かります。

なお，論理サーバを監視対象とする場合は，「(a)　監視対象」の注意事項を参照してください。

プロセス監視

Management Serverのプロセスの有無を監視します。監視するプロセス名を次に示します。

表16‒3　監視するプロセス

監視対象

プロセス名

Windowsの場合

UNIXの場合

Management Server

mngsvr.exe

cjstartsv※1，※2

運用管理エージェント

adminagent.exe

adminagent

論理サーバ

mngsvr.exe

cjstartsv※1

注※1　cjstartsvプロセスはJ2EEサーバのプロセス名と同一です。

サーバ名でManagement Serverのプロセスを識別してください。

注※2　Management Serverのコマンドライン名は次の文字列で始まります。

/opt/Cosminexus/CC/server/bin/cjstartsv　cosmi_m

cosmi_mはデフォルトのサーバ名です。Management Serverをcosmi_m以外のサーバ名でセットアップした場合はサーバ名を変更してください。

ヘルスチェック

Management Serverのプロセスの有無および存在しているプロセスが稼働しているかどうかを監視します。Management Serverで次のコマンドを実行して確認します。

Management Serverおよび論理サーバを監視する場合

mngsvrutilコマンド

運用管理エージェントを監視する場合

adminagentcheckコマンド

(2)　クラスタソフトウェアの環境設定

クラスタソフトウェアの環境設定については，使用するクラスタソフトウェアのマニュアルを参照してください。

16.3.5　アプリケーションサーバの設定

アプリケーションサーバの設定をするためには，現用系と予備系それぞれの運用管理エージェントとManagement Serverを起動します。起動後，論理サーバのセットアップを実施して設定ファイルを配布し，J2EEサーバにアプリケーションとリソースアダプタをインポートします。現用系2台（Node1，Node2），予備系1台（Node3）の場合のアプリケーションサーバの設定手順を次に示します。

Node1とNode2でクラスタソフトウェアから系を起動します。

現用系のアプリケーションサーバ（Node1の仮想ホスト1およびNode2の仮想ホスト2）が起動されて，予備系のアプリケーションサーバ（Node3の仮想ホスト1および仮想ホスト2）が待機状態になっている，通常の運用状態になります。

現用系のアプリケーションサーバ（Node1の仮想ホスト1およびNode2の仮想ホスト2）に対して，Smart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

クラスタソフトウェアから仮想ホスト1の系を切り替えます。

現用系のアプリケーションサーバ（Node1の仮想ホスト1）の系を切り替えて，予備系のアプリケーションサーバ（Node3の仮想ホスト1）を起動します。

予備系のアプリケーションサーバ（Node3の仮想ホスト1）に対して手順2.を実施します。

クラスタソフトウェアから仮想ホスト1の系を戻します。

予備系のアプリケーションサーバ（Node3の仮想ホスト1）の系を切り替えて，現用系のアプリケーションサーバ（Node1の仮想ホスト1）を起動し，通常の運用状態に戻します。

クラスタソフトウェアから仮想ホスト2の系を切り替えます。

現用系のアプリケーションサーバ（Node2の仮想ホスト2）の系を切り替えて，予備系のアプリケーションサーバ（Node3の仮想ホスト2）を起動します。

予備系のアプリケーションサーバ（Node3の仮想ホスト2）に対して手順2.を実施します。

クラスタソフトウェアから仮想ホスト2の系を戻します。

予備系のアプリケーションサーバ（Node3の仮想ホスト2）の系を切り替えて，現用系のアプリケーションサーバ（Node2の仮想ホスト2）を起動し，通常の運用状態に戻します。

Node1とNode2で，クラスタソフトウェアから系を停止します。

現用系のアプリケーションサーバ（Node1の仮想ホスト1およびNode2の仮想ホスト2）を停止し，休止状態にします。

16.4　ホスト単位管理モデルを対象にした系切り替えシステムの起動と停止

ホスト単位管理モデルを対象にした系切り替えシステムを利用して運用する場合は，あらかじめ現用系N台と予備系1台のホストの用意やクラスタソフトウェアの監視対象となるManagement Serverや運用管理エージェントを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については「16.3.1　ホスト単位管理モデルを対象にした系切り替えシステムの設定手順」を参照にしてください。

ここでは，現用系のアプリケーションサーバ（Node1の現用系1およびNode2の現用系2）と予備系のアプリケーションサーバ（Node3の予備系1および予備系2）のクラスタ構成の起動と停止の留意事項について説明します。

運用を開始する場合は，現用系のアプリケーションサーバ（Node1の現用系1およびNode2の現用系2）を起動して，予備系のアプリケーションサーバ（Node3の予備系1および予備系2）を待機状態にしてください。

現用系，予備系のアプリケーションサーバを同時に起動することはできません。J2EEアプリケーションの入れ替えが必要な場合は，サービスを停止して，現用系，予備系の系を切り替えてください。順次J2EEアプリケーションを停止してJ2EEアプリケーションを入れ替えて，必要に応じてセットアップ，配布を実行してください。

17　1:1系切り替えシステム（クラスタソフトウェアとの連携）

この章では，実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）について説明します。

17.1　この章の構成

この章の構成を次の表に示します。

表17‒1　この章の構成（1:1系切り替えシステム（クラスタソフトウェアとの連携））

分類

タイトル

参照先

解説

1:1系切り替えシステムの概要

17.2

1:1系切り替えシステムのシステム構成と動作

17.3

設定

アプリケーションサーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）

17.4

運用管理サーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）

17.5

アプリケーションサーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）

17.6

運用管理サーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）

17.7

運用

アプリケーションサーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）

17.8

運用管理サーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）

17.9

1:1系切り替えシステムの起動と停止（UNIXの場合）

17.10

設定の確認

系切り替えシステムの設定内容の確認方法

17.11

注　「実装」，「注意事項」について，この機能固有の説明はありません。

17.2　1:1系切り替えシステムの概要

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，アプリケーションサーバの1:1系切り替えシステムと，運用管理サーバの1:1系切り替えシステムをサポートしています。ただし，バッチアプリケーションの実行環境では，運用管理サーバの1:1系切り替えシステムは使用できません。

アプリケーションサーバの1:1系切り替えシステム

実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成です。実行系のアプリケーションサーバマシンにトラブルが発生してマシンが終了した場合，または運用管理エージェントが終了した場合に，クラスタソフトウェアによって待機系のアプリケーションサーバマシンを起動して処理を切り替えます。

運用管理サーバの1:1系切り替えシステム

実行系の運用管理サーバマシン1台に対して待機系の運用管理サーバマシンを1台用意しておく構成です。実行系の運用管理サーバマシンにトラブルが発生してマシンが終了した場合，またはManagement Serverのプロセスが終了した場合に，クラスタソフトウェアによって待機系の運用管理サーバマシンを起動して処理を切り替えます。

17.3　1:1系切り替えシステムのシステム構成と動作

この節では，1:1系切り替えシステムのシステムの構成例，系切り替え処理の流れなどについて説明します。

17.3.1　1:1系切り替えシステムのシステム構成例

クラスタソフトウェアと連携して，アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例と，運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例について説明します。

アプリケーションサーバを1:1系切り替えシステムで運用する場合

アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例を次の図に示します。系切り替え時，Webサーバや運用管理サーバからは，同じ論理アドレスでアプリケーションサーバが再起動したように見えます。

図17‒1　アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例

運用管理サーバを1:1系切り替えシステムで運用する場合

運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例を次の図に示します。系切り替え時，Webサーバやアプリケーションサーバからは，同じ論理アドレスで運用管理サーバが再起動したように見えます。

図17‒2　運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例

参考

Management Serverでは，運用管理ドメインの構成情報などのManagement Serverに関する設定情報をファイル中に保持しています。運用管理サーバの1:1系切り替えシステムでは，運用管理ドメインの構成に変更がある場合，実行系の情報を待機系に引き継ぐために，システムの起動前に実行系で定義した情報（Management Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなど）を待機系にコピーする必要があります。Management Serverに関する設定情報のコピーの手順については，「17.5.4　現用系から予備系へのManagement Serverの設定情報のコピー」を参照してください。

なお，1:1系切り替えシステムでは次のような運用ができます。

共有ディスク装置の使用

アプリケーションサーバを1:1系切り替えシステムで運用する場合，共有ディスク装置の使用については，ローカルトランザクションの場合とグローバルトランザクションの場合とで異なります。

ローカルトランザクションの場合

共有ディスク装置は不要です。ローカルトランザクションでは，実行系と待機系との間で引き継ぐセッション情報がないため，共有ディスク装置を使用しません。

グローバルトランザクションの場合

共有ディスク装置が必要になります。共有ディスク装置は，系切り替え時に，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。

JP1連携をする場合

クラスタソフトウェアを使用した構成では，JP1とも連携できます。

JP1と連携する場合，アプリケーションサーバには，JP1/Baseなども必要になります。クラスタソフトウェアでのJP1の管理は，アプリケーションサーバとは別に行う必要があります。

データベースサーバでのクラスタソフトウェアとの連携

データベースサーバでもクラスタソフトウェアを使用した構成にすることもできます。この場合，アプリケーションサーバ側では，仮想アドレス（論理アドレス）だけを認識していれば，特にデータベースサーバがクラスタソフトウェアを使用していることを意識する必要はありません。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

なお，アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成の詳細については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）」またはマニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）」を参照してください。運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成の詳細については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

17.3.2　系切り替えのタイミング

系切り替えは次のタイミングで実施されます。

クラスタソフトウェアがハード障害などの系障害※を検知したとき

監視対象プロセス（運用管理エージェントまたはManagement Server）がダウンしたとき

クラスタソフトウェアの系切り替えコマンドを使用したとき

そのほかの，クラスタソフトウェアが系を切り替える事象が発生したとき

注※

サーバを除いた系に発生する障害を指します。系のハードウェア障害やクラスタソフトウェアの障害などがあります。

17.3.3　1:1系切り替えシステムでの系切り替え処理の流れ

1:1系切り替えシステムでの系切り替え時の動作と，処理の流れについて説明します。

(1)　系切り替えの動作

1:1系切り替えシステムでの系切り替えは次の図のようにして行われます。この図では，系Aに障害が発生し，系Bに切り替える場合の例を示します。

図17‒3　1:1系切り替えシステムでの系切り替えの動作

(2)　系切り替えの処理の流れ

1:1系切り替えシステムで適用できる系切り替えには，自動系切り替えと計画系切り替えの二つがあります。自動系切り替えとは，クラスタソフトウェアが自動的に系を切り替える方法です。実行系に障害が発生したときは，自動系切り替えになります。一方，計画系切り替えとは，オペレータが系を保守する際に，計画的に系を切り替える方法です。実行系からクラスタソフトウェアのコマンドを使用して切り替えます。

ここでは，系切り替え処理の流れについて，自動系切り替えの場合と計画系切り替えの場合に分けて説明します。

(a)　自動系切り替えの処理の流れ

1:1系切り替えシステムでの自動系切り替えの処理の流れについて説明します。ここでは，実行系である系Aに障害が発生し，待機系である系Bに切り替えるときの流れについて説明します。

アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。

図17‒4　アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。

図17‒5　運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

(b)　計画系切り替えの処理の流れ

1:1系切り替えシステムでの計画系切り替えの処理の流れについて説明します。ここでは，クラスタソフトウェアのコマンドを使用して，実行系である系Aを待機系に，待機系である系Bを実行系に切り替えるときの流れについて説明します。

アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。

図17‒6　アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。

図17‒7　運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

17.3.4　系切り替え時のシステムの動作

系切り替え時のシステムの動作について説明します。

(1)　HTTPのセッション情報の引き継ぎ

セッションフェイルオーバ機能を使用しない場合，Webコンテナが管理しているHTTPのセッション情報※1およびServletContextに設定したアトリビュート情報※2は，J2EEサーバのメモリ中にしかなく，これらの情報は，実行系と待機系との間で共有されません。系の切り替え実施後，HTTPのセッション情報は失われます。このため，すでにセッションを開始していたWebアプリケーションおよびWebクライアントでは，不正な動作をするおそれがあります。これを防止するため，アプリケーションで，セッション情報に矛盾が発生した場合に適切に対処できるようにしておく必要があります。

セッションフェイルオーバ機能を使用する場合，系切り替え後もHTTPセッション情報を維持できます。ただし，維持できるのはセッションフェイルオーバ機能で引き継ぎの対象としたセッション情報だけです。

なお，系切り替え後もセッションを維持するためには，セッションをDBMSなどで管理するようにアプリケーション側で独自に設定し，実行系および待機系の両方から参照できるようにする必要があります。

注※1

javax.servlet.http.HttpServletRequest#getSessionメソッドで取得した，javax.servlet.http.HttpSessionオブジェクトに格納している情報を指します。

注※2

javax.servlet.ServletContext#getServletContextメソッドで取得した，javax.servlet.ServletContextオブジェクトに格納している情報を指します。

(2)　EJBのセッション情報の引き継ぎ

EJBコンテナが管理しているセッション情報※は，J2EEサーバのメモリ中にしかないため，系の切り替え実施後はセッション情報が失われます（実行系と待機系の間で，セッション情報は共有されません）。このため，すでにセッションを開始していたEJBクライアントでは，正常に動作を継続できないおそれがあります。セッション情報が失われた場合は，Homeのlookupからやり直すように，EJBクライアントを設計する必要があります。

なお，CTM環境でも同様の問題が起こります。

注※

ホームインタフェース，およびコンポーネントインタフェースのオブジェクト情報を指します。

(3)　トランザクション情報の引き継ぎ

トランザクション情報の引き継ぎはトランザクションの種類によって異なります。トランザクション情報の引き継ぎについて，ローカルトランザクションの場合とグローバルトランザクションの場合を説明します。

(a)　ローカルトランザクションの場合

ローカルトランザクションの場合，系の切り替え時にはトランザクション情報は引き継がれません。

システムの障害によってダウンした場合や，J2EEサーバのプロセスダウンによって系の切り替えが発生した場合は，開始中のトランザクションは，コミットおよびロールバックのどちらも実施されません。

なお，計画系切り替えのように，J2EEサーバが正常に終了する場合は，トランザクションが開始中の状態で残ることはありません。

(b)　グローバルトランザクションの場合

グローバルトランザクションの場合，系切り替え後に引き継いだトランザクションを使用して，J2EEサーバの起動時に，トランザクションの回復処理をします。これによって，コミットまたはロールバックのどちらかの適切な処理が実施されます。

(4)　運用管理エージェントの動作

運用管理エージェントでは，実行系と待機系の間で直接情報を引き継ぐことはありません。系切り替え後には，運用管理エージェントの起動スクリプト中に記述した論理サーバが起動されます。なお，運用管理エージェントの起動スクリプトについては，「17.6.5　シェルスクリプトファイルの作成」を参照してください。

(5)　性能解析トレースで出力するキー情報

性能解析トレースの出力する情報には，一連の処理を識別するためのキー情報が付与されています。このキー情報には，作成時のIPアドレスが含まれます。IPアドレスを複数持つホストの場合，キー情報には，そのホストの持つIPアドレスのどれか一つが含まれます。このため，実行系のホストで出力された性能解析トレースには，キー情報として，ステーショナリIPアドレス（系切り替えによって他系へ移動しないIPアドレス）が含まれたり，エイリアスIPアドレス（クラスタソフトウェアによって動的に割り当てられるIPアドレス）が含まれたりする場合があります。これによって，系の切り替え前と切り替え後とで，キー情報に含まれるIPアドレスが変わる可能性があることに留意してください。

なお，性能解析トレースで出力するキー情報については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.2　性能解析トレースの概要」を参照してください。

17.3.5　系切り替え時の情報の引き継ぎ

系切り替え時に，待機系に引き継がれる情報と，引き継がれない情報について説明します。

引き継がれる情報

OTSトランザクション情報（グローバルトランザクションの場合）

実行系から待機系のへの系切り替え後，OTSトランザクション情報を引き継ぎ，トランザクションの回復処理をします。

引き継がれない情報

系切り替えが発生したとき，次に示す情報は切り替え後の系に引き継がれないので注意してください。

Webコンテナが管理するアプリケーションのHTTPセッション情報※

WebコンテナのServletContextに設定したアトリビュート情報

ホームインタフェースとコンポーネントインタフェースのBeanのセッション情報

アプリケーションの稼働状態，JNDIのキャッシュ，コネクションプール，CTMのキューなどの状態に関する情報

注※

セッションフェイルオーバ機能を使用する場合，引き継ぎの対象としたセッション情報だけ引き継げます。

17.4　アプリケーションサーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置するシステムと，実行系の運用管理サーバと待機系の運用管理サーバを1:1に配置するシステムを構築・運用できます。アプリケーションサーバを1:1に配置するシステムは，運用管理ポータルを使用して構築します。運用管理ポータルについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。この節では，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置して系を切り替えるシステムの設定について説明します。

アプリケーションサーバの実行系と待機系を1:1に配置して系を切り替えるシステムでは，実行系のアプリケーションサーバでマシンの障害や運用管理エージェントの終了などの障害が発生すると，クラスタソフトウェアがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守などが必要な場合には，オペレータの操作によって待機している系に計画的に切り替えることができます。

なお，アプリケーションサーバの1:1系切り替えシステムの詳細については，「17.2　1:1系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）」またはマニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）」を参照してください。

17.4.1　アプリケーションサーバを対象にした1:1系切り替えシステムの設定手順

ここでは，アプリケーションサーバの1:1系切り替えシステムの構築例とシステムの設定手順について説明します。

(1)　システムの構成例

アプリケーションサーバの1:1系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図17‒8　アプリケーションサーバを対象にした1:1系切り替えシステムの構成例（Windowsの場合）

この例では，アプリケーションサーバの実行系（現用系）とアプリケーションサーバの待機系（予備系）を1:1で配置しています。また，Management Serverは，運用管理サーバとして，アプリケーションサーバとは別のマシンに配置しています。

アプリケーションサーバの1:1系切り替えシステムでは，まずクラスタを構築して，アプリケーションサーバをクラスタ（例ではAPS）内に現用系ノード（例ではNode1）と予備系ノード（例ではNode2）として定義します。また，現用系ノードと予備系ノードは，「物理ディスクリソース」，「IPアドレスリソース」，「ネットワーク名リソース」，および「汎用スクリプトリソース」を含めた，一つのリソースグループ（例ではClusterA）として定義します。

なお，アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。1:1系切り替えシステムの場合，エイリアスIPアドレスは，Windows Server Failover Clusterによって動的に割り当てられるアドレス（クラスタIPアドレス）となります。

(2)　システムの設定手順

Windows Server Failover Clusterと連携する場合には，運用管理ポータルやクラスタアドミニストレータの設定などが必要になります。アプリケーションサーバの1:1系切り替えシステムの設定手順を次の図に示します。

図17‒9　アプリケーションサーバを対象にした1:1系切り替えシステムの設定手順（Windowsの場合）

図中の1.〜6.について説明します。

共有ディスクにパーティションを作成して，ファイルシステムを構築します。

Windows Server Failover Clusterのクラスタ管理用ファイルの格納場所を作成します。また，グローバルトランザクションを使用する場合には，トランザクション情報の格納場所を作成します。なお，クラスタ管理用ファイルの格納場所とトランザクション情報の格納場所は，同じパーティションでもかまいません。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系と予備系で，同じドライブ文字を割り当ててください。

運用管理ポータルでクラスタサーバの環境を設定します。

運用管理ポータルの「運用管理ドメインの構成定義」，および「論理サーバの環境設定」で，Windows Server Failover Clusterを使用する場合の設定をします。詳細は，「17.4.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「17.4.3　設定ファイルの編集」を参照してください。

クラスタを設定します。

クラスタソフトウェアの環境設定や運用管理エージェントを監視するスクリプトファイルを作成します。詳細については，「17.4.4　クラスタの設定」を参照してください。

運用管理ポータル，クラスタアドミニストレータなどで，アプリケーションサーバの設定をします。

運用管理ポータル，クラスタアドミニストレータなどを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「17.4.5　アプリケーションサーバの設定」を参照してください。

17.4.2　クラスタサーバの環境設定

ここでは，Windows Server Failover Clusterと連携する場合の，運用管理ポータルでの設定の留意点について説明します。

参考

運用管理ポータルでシステムの動作環境を設定するには，あらかじめ，Management Serverの起動などが必要です。また，Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。運用管理ポータルでの動作環境の設定や，操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

(1)　「運用管理ドメインの構成定義」での設定

論理サーバを設置するホストおよび各論理サーバの構成を定義します。このとき，［ホストの定義］画面で，「ホスト名」にクラスタIPアドレスを設定します。

(2)　「論理サーバの環境設定」での設定

論理J2EEサーバ，論理Webサーバ，および論理ネーミングサービスの設定での留意点を次に示します。

(a)　論理J2EEサーバの設定

ホストの固定の設定

次の個所では，「ホストの固定」に「する」を設定してください。

［J2EEコンテナの設定］画面にある「運用監視エージェントの設定」の「ホストの固定」

［EJBコンテナの設定］画面にある「ホストの固定」

［Webコンテナの設定］画面にある「Webサーバとの接続」および「管理用サーバの設定」の「ホストの固定」

ホストを固定すると，運用管理ポータルの「運用管理ドメインの構成定義」で定義したホスト名が使用されます。

グローバルトランザクションの設定

グローバルトランザクションを使用する場合は，次の設定をしてください。

［トランザクションの設定］画面にある「ライトトランザクション機能」を「無効」にします。

［トランザクションの設定］画面にある「インプロセスOTSのステータスファイル格納先」に，共有ディスク装置のディレクトリを設定します。

設定例

L:¥Group1¥otsstatus

(b)　論理Webサーバの設定

［Webサーバの設定］画面で，「ホストの固定」に「する」を設定してください。

(c)　論理ネーミングサービスの設定

［ネーミングサービスの設定］画面で，「ホストの固定」に「する」を設定してください。このとき，J2EEサーバが使用するネーミングサービス（アウトプロセスでの起動）を設定する場合は，「運用管理エージェントのホストで固定」のチェックボックスをチェックしないでください。このように設定することで，「運用管理ドメインの構成定義」の［ネーミングサービスの追加］画面で指定したホスト名が使用されます。

17.4.3　設定ファイルの編集

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。ここでは，Windows Server Failover Clusterと連携する場合に注意が必要なファイルの設定について説明します。

(1)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）に設定する項目のうち，Windows Server Failover Clusterと連携する場合に留意する設定項目について説明します。なお，adminagent.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.1　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

adminagent.adapter.bind_hostキー

adminagent.adapter.bind_hostキーでクラスタIPアドレスを指定します。管理用のリクエストは，クラスタIPアドレスだけで受け付けます。例では，次のように設定します。

adminagent.adapter.bind_host=172.16.12.30

adminagent.cluster.localaddress.checkキー

アプリケーションサーバの系切り替え時に，障害などの原因で停止しなかった待機系の論理サーバ，または運用管理エージェントを停止するための設定をします。

adminagent.cluster.localaddress.check=true

(2)　HTTP Serverの設定（Webサーバと連携する場合）

httpsd.conf（HTTP Server定義ファイル）に設定する項目のうち，Windows Server Failover Clusterと連携する場合に留意する設定項目について説明します。なお，httpsd.confファイルの各ディレクティブについては，マニュアル「HTTP Server」を参照してください。

Listenディレクティブ，BindAddressディレクティブなど

Listenディレクティブ，BindAddressディレクティブなどには，クラスタIPアドレスを指定します。クライアントへのサービス提供は，クラスタIPアドレスで実施します。

ProxyPassディレクティブ，ProxyPassReverseディレクティブ

転送先アドレスには，クラスタIPアドレス，クラスタIPアドレスに名前を解決できるホスト名，または"localhost"を指定します。

ServerNameディレクティブ

ServerNameディレクティブには，クラスタIPアドレス，またはクラスタIPアドレスに名前を解決できるホスト名を指定します。

(3)　スマートエージェントの設定（CTMを利用する場合）

Management Serverとの連携でCTMを利用する場合には，次のファイルを編集する必要があります。

localaddr

localaddrを作成します。localaddrでは，ステーショナリIPアドレスとクラスタIPアドレスを設定し，スマートエージェントがステーショナリIPアドレスとエイリアスIPアドレスを通信に使用できるようにします。localaddrの設定については，「付録A　クラスタソフトウェア連携時のTPBrokerの設定（Windowsの場合）」を参照してください。

17.4.4　クラスタの設定

クラスタに対して，次の設定を実施します。

スクリプトファイルの作成

クラスタソフトウェアの環境設定

(1)　スクリプトファイルの作成

監視対象を起動・停止するためのスクリプトファイルを作成します。また，スクリプトファイルでクラスタの監視方法を決めておく必要があります。スクリプトファイルの作成については，使用するOSのマニュアルを参照してください。

ここでは，アプリケーションサーバの1:1系切り替えシステムの監視対象および監視方法について説明します。

(a)　監視対象

アプリケーションサーバの1:1系切り替えシステムの監視対象を次に示します。

運用管理エージェント

運用管理エージェントが終了したタイミングで系切り替えが実行されます。

(b)　監視方法

運用管理エージェントのプロセスの有無を監視します。監視するプロセスを次に示します。

adminagent.exe

(2)　Windows Server Failover Clusterの環境設定

Windows Server Failover Clusterの環境設定については，使用するクラスタソフトウェアのマニュアルを参照してください。

17.4.5　アプリケーションサーバの設定

アプリケーションサーバの設定では，運用管理ポータル，クラスタアドミニストレータなどを使用してアプリケーションサーバをクラスタ構成に配置します。また，論理サーバをセットアップして設定情報を配布し，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。アプリケーションサーバの設定手順を次に示します。

運用管理サーバを起動します。

運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

Node1で，リソースグループClusterAをオンラインにします。

運用管理ポータルで，J2EEサーバをセットアップします。

「運用管理ドメインの構成定義」の［セットアップ］画面で，J2EEサーバをセットアップします。運用管理ポータルでの操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルで，J2EEサーバに設定した情報をNode1に配布します。

「論理サーバの環境設定」の［設定情報の配布］画面で，J2EEサーバに設定した情報をNode1に配布します。

サーバ管理コマンドを使用して，Node1のJ2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。また，インポートしたJ2EEアプリケーションとリソースアダプタを設定および開始します。

J2EEアプリケーションの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」，リソースアダプタの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の次の個所を参照してください。

4.1.26　DB Connectorを設定する（CUI利用時）

4.1.27　DB Connector以外のリソースアダプタを設定する（CUI利用時）

4.1.28　リソースアダプタを開始する（CUI利用時）

また，サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

なお，J2EEサーバおよびその前提プロセスを起動してからサーバ管理コマンドを実行してください。また，サーバ管理コマンドでの操作が終わったら，サーバ管理コマンドを停止させてください。

クラスタアドミニストレータで，リソースグループClusterAに対して「グループの移動」を実行して系を切り替え，リソースの所有者をNode2に変更します。

Node2で，手順3.〜手順5.を実施します。

クラスタアドミニストレータで，リソースグループClusterAに対して「グループの移動」を実行して系を切り替え，リソースの所有者をNode1に戻します。

17.5　運用管理サーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置するシステムと，実行系の運用管理サーバと待機系の運用管理サーバを1:1で配置するシステムを構築・運用できます。運用管理サーバを1:1に配置して系を切り替えるシステムは，Smart Composer機能を使用して構築します。この節では，実行系の運用管理サーバと待機系の運用管理サーバを1:1に配置して系を切り替えるシステムの設定について説明します。

運用管理サーバを1:1に配置して系を切り替えるシステムでは，実行系の運用管理サーバでマシンの障害やManagement Serverのプロセスの終了が発生すると，クラスタソフトウェアがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守などが必要な場合には，オペレータの操作によって待機している系に計画的に切り替えることができます。

なお，運用管理サーバの1:1系切り替えシステムの詳細については，「17.2　1:1系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

17.5.1　運用管理サーバを対象にした1:1系切り替えシステムの設定手順

ここでは，運用管理サーバの1:1系切り替えシステムの構成例とシステムの設定手順について説明します。

(1)　システムの構成例

運用管理サーバの1:1系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図17‒10　運用管理サーバを対象にした1:1系切り替えシステムの構成例（Windowsの場合）

運用管理サーバの実行系（現用系）と運用管理サーバの待機系（予備系）を1:1で配置しています。

運用管理サーバの1:1系切り替えシステムでは，まずクラスタを構築して，運用管理サーバをクラスタ（例ではAPS）内に現用系ノード（例ではNode1）と予備系ノード（例ではNode2）として定義します。また，現用系ノードと予備系ノードは，「物理ディスクリソース」，「IPアドレスリソース」，「ネットワーク名リソース」，および「汎用スクリプトリソース」を含めた，一つのリソースグループ（例ではGroup）として定義します。

なお，アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。1:1系切り替えシステムの場合，エイリアスIPアドレスは，Windows Server Failover Clusterによって動的に割り当てられるアドレス（クラスタIPアドレス）となります。

(2)　システムの設定手順

Windows Server Failover Clusterと連携する場合には，Management Serverやクラスタアドミニストレータの設定などが必要になります。運用管理サーバの1:1系切り替えシステムの設定手順を次の図に示します。

図17‒11　運用管理サーバを対象にした1:1系切り替えシステムの設定手順（Windowsの場合）

図中の1.〜6.について説明します。

共有ディスクにパーティションを作成して，ファイルシステムを構築します。

Windows Server Failover Clusterのクラスタ管理用ファイルの格納場所を作成します。また，グローバルトランザクションを使用する場合には，トランザクション情報の格納場所を作成します。なお，クラスタ管理用ファイルの格納場所とトランザクション情報の格納場所は，同じパーティションでもかまいません。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系と予備系で，同じドライブ文字を割り当ててください。

Management Serverでクラスタサーバの環境を設定します。

Management ServerのSmart Composer機能の簡易構築定義ファイルで，Windows Server Failover Clusterを使用する場合の設定をします。詳細は，「17.5.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

簡易構築定義ファイルでは設定できない，Management Serverなどの各種定義ファイルを設定します。詳細は，「17.5.3　設定ファイルの編集」を参照してください。

現用系から予備系にManagement Serverの設定情報をコピーします。

現用系と予備系を同じ環境にするために，現用系でのManagement Serverに関する設定内容を予備系にコピーします。詳細は，「17.5.4　現用系から予備系へのManagement Serverの設定情報のコピー」を参照してください。

クラスタを設定します。

クラスタソフトウェアの環境設定やManagement Severを監視するスクリプトファイルを作成します。詳細については，「17.5.5　クラスタの設定」を参照してください。

17.5.2　クラスタサーバの環境設定

ここでは，Windows Server Failover Clusterと連携する場合の，Management Serverでの設定時の留意点について説明します。

参考

Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。Management Serverのセットアップについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.14　運用管理機能を構築する」を参照してください。

(1)　簡易構築定義ファイルでの設定

Management ServerのSmart Composer機能の簡易構築定義ファイルで，論理サーバを設置するホストおよび各論理サーバの構成を定義します。また，必要に応じて，各論理サーバの<configuration>タグ内に，論理サーバの環境や起動／停止の動作などを設定します。設定済みの簡易構築定義ファイルを基に，Smart Composer機能のコマンドを使用して，Webシステムをセットアップします。

必要に応じて，サーバ管理コマンドを使用して，J2EEアプリケーション，リソースアダプタをインポートして，開始します。

17.5.3　設定ファイルの編集

設定ファイルを編集します。ここでは，Windows Server Failover Clusterと連携する場合に注意が必要な設定ファイルについて説明します。なお，現用系と予備系で必要となる設定が異なります。

Management Serverの設定

Management Serverの運用管理コマンド（mngsvrutil）の設定

現用系では，1.と2.を設定してください。

予備系では，2.だけ設定してください。1.については，現用系からManagement Serverの設定情報をコピーすることで設定できるため，ここでは設定不要です。

(1)　Management Serverの設定

Management Server環境設定ファイル（mserver.properties）に設定する項目のうち，Windows Server Failover Clusterと連携する場合に留意する設定項目について説明します。なお，mserver.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

mngsvr.myhost.name

mngsvr.myhost.nameキーでクラスタIPアドレスを指定します。例では，次のように設定します。

mngsvr.myhost.name=192.168.255.111

(2)　Management Serverの運用管理コマンド（mngsvrutil）の設定

ローカルシステムアカウントのホームディレクトリに，Management Serverの運用管理コマンド（mngsvrutil）のクライアント側定義ファイル（.mngsvrutilrc）を用意し，Management Serverの管理ユーザのユーザIDとパスワードを設定してください。また，クライアント側定義ファイルには適切なアクセス権限を設定してください。

このファイルは，Management Serverを監視，起動，および停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

なお，mngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.14　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）」を参照してください。

17.5.4　現用系から予備系へのManagement Serverの設定情報のコピー

現用系と予備系を同じ環境にするために，現用系でのManagement Serverに関する設定情報を予備系にコピーします。Management Serverの設定情報の退避／回復コマンドを使用して，現用系で設定したManagement Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなどを，現用系から予備系にコピーしてください。

(1)　Management Serverの設定情報のコピー手順

Management Serverの設定情報のコピー手順を次に示します。

現用系で，mstrexportコマンドを実行します。

mstrexportコマンドでは，mstrexportコマンドの実行対象となる現用系のManagement Serverの設定情報を収集し，収集した情報をZIP形式のファイルに保存します。mstrexportコマンドの引数には，保存するZIP形式のファイルのファイル名を指定してください。

コマンドの格納場所

<Application Serverのインストールディレクトリ>¥manager¥bin

実行例

mstrexport C:¥work¥mstruct.zip

なお，mstrexportコマンドは，mstrexportコマンドの実行対象となるManagement Serverの起動，停止に関係なく実行できます。

手順1.で保存されたZIP形式のファイルを，現用系から予備系にコピーします。

予備系で，mstrimportコマンドを実行します。

mstrimportコマンドでは，コピーしてきたZIP形式のファイルを，コマンドの実行対象となる予備系のManagement Serverに展開します。これによって，現用系のManagement Serverと予備系のManagement Serverを同じ設定にできます。

mstrimportコマンドの引数には，コピーしてきたZIP形式のファイルのファイル名を指定してください。

コマンドの格納場所

<Application Serverのインストールディレクトリ>¥manager¥bin

実行例

mstrimport D:¥recovery¥mstruct.zip

なお，mstrimportコマンドは，mstrimportコマンドの実行対象のManagement Serverが停止している場合だけ実行できます。

コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mstrexport（Management Server管理ファイルの退避）」およびマニュアル「アプリケーションサーバ リファレンス コマンド編」の「mstrimport（Management Server管理ファイルの回復）」を参照してください。

(2)　収集対象のファイルの定義

mstrexportコマンドの引数として，mstrexportコマンドの収集対象を記述するファイル（Management Server管理ファイル用退避対象定義ファイル）を指定できます。

実行例

mstrexport c:¥work¥mstruct.zip "C:¥Documents and Settings¥MyUser¥filelist.txt"

mstrexportコマンドでは，デフォルトの状態で，Management Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなど，Management Serverでのシステム構築・運用に必要な情報が収集できます。これらの情報に加えて，ユーザ作成のコマンドなどもmstrexportコマンドでの収集対象に追加したい場合には，収集対象とするファイルの絶対パスをManagement Server管理ファイル用退避対象定義ファイルに記述してください。

ファイルの記述例

${cosminexus.home}/manager/apps/MyApp.ear

D:/home/confdir/message1.conf

ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.13　Management Server管理ファイル用退避対象定義ファイル」を参照してください。

17.5.5　クラスタの設定

クラスタに対して，次の設定を実施します。

スクリプトファイルの作成

クラスタソフトウェアの環境設定

(1)　スクリプトファイルの作成

ここでは，運用管理サーバの1:1系切り替えシステムの監視対象および監視方法について説明します

監視対象を起動・停止するためのスクリプトファイルを作成します。また，スクリプトファイルでクラスタの監視方法を決めておく必要があります。スクリプトファイルの作成については，使用するOSのマニュアルを参照してください。

(a)　監視対象

運用管理サーバの1:1系切り替えシステムの監視対象を次に示します。

Management Server

Management Serverが終了したタイミングで系切り替えが実行されます。

(b)　監視方法

Management Serverのプロセスの有無を監視します。監視するプロセスを次に示します。

mngsvr.exe

(2)　Windows Server Failover Clusterの環境設定

Windows Server Failover Clusterの環境設定については，使用するクラスタソフトウェアのマニュアルを参照してください。

17.6　アプリケーションサーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置するシステムと，実行系の運用管理サーバと待機系の運用管理サーバを1:1に配置するシステムを構築・運用できます。アプリケーションサーバを1:1に配置するシステムは，運用管理ポータルを使用して構築します。運用管理ポータルについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。この節では，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置して系を切り替えるシステムの設定について説明します。

アプリケーションサーバの実行系と待機系を1:1に配置して系を切り替えるシステムでは，実行系のアプリケーションサーバでマシンの障害や運用管理エージェントの終了などの障害が発生すると，HAモニタがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守などが必要な場合には，オペレータの操作によって待機している系に計画的に切り替えることができます。

なお，アプリケーションサーバの1:1系切り替えシステムの運用は，AIXまたはLinuxの場合だけ使用できます。

機能の詳細については，「17.2　1:1系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）」またはマニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）」を参照してください。また，HAモニタについては，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.6.1　アプリケーションサーバを対象にした1:1系切り替えシステムの設定手順

ここでは，システムの構築例とシステムの設定手順について説明します。

(1)　システムの構成例

アプリケーションサーバの1:1系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図17‒12　アプリケーションサーバを対象にした1:1系切り替えシステムの構成例（UNIXの場合）

この例では，アプリケーションサーバの実行系（現用系）とアプリケーションサーバの待機系（予備系）を1:1で配置しています。また，Management Serverは，運用管理サーバとして，アプリケーションサーバとは別のマシンに配置しています。

アプリケーションサーバの1:1系切り替えシステムでは，まずクラスタを構築して，アプリケーションサーバをクラスタ内に現用系と予備系として定義します。また，HAモニタで使用するコマンドや出力するメッセージのための，サーバの識別名（サーバの別名）を指定します。現用系と予備系とで同じ名称（例ではCAP）を指定します。

なお，アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。1:1系切り替えシステムの場合，エイリアスIPアドレスは，HAモニタによって動的に割り当てられるアドレスとなります。

(2)　システムの設定手順

HAモニタと連携する場合には，運用管理ポータルやHAモニタのファイルの設定などが必要になります。アプリケーションサーバの1:1系切り替えシステムの設定手順を次の図に示します。

図17‒13　アプリケーションサーバを対象にした1:1系切り替えシステムの設定手順（UNIXの場合）

図中の1.〜9.について説明します。

グローバルトランザクションを使用する場合は，共有ディスクにパーティションを作成して，ファイルシステムを構築します。

グローバルトランザクションを使用するためには，トランザクション情報の格納場所を作成します。

グローバルトランザクションを使用する場合は，システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系と予備系で，同じマウント先ディレクトリにしてください。

運用管理ポータルでクラスタサーバの環境を設定します。

運用管理ポータルの「運用管理ドメインの構成定義」，および「論理サーバの環境設定」で，HAモニタを使用する場合の設定をします。詳細は，「17.6.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「17.6.3　設定ファイルの編集」を参照してください。

HAモニタの環境を設定します。

HAモニタのsysdefファイルで，HAモニタの環境を定義します。詳細は，「17.6.4　HAモニタの環境設定」を参照してください。

シェルスクリプトファイルを作成します。

運用管理エージェントを監視，運用管理エージェントと論理サーバを起動および停止するためのシェルスクリプトファイルを作成します。詳細は，「17.6.5　シェルスクリプトファイルの作成」を参照してください。

サーバ対応の環境を設定します。

HAモニタのserversファイルで，系で稼働させる現用系サーバや予備系サーバの環境を定義します。詳細は，「17.6.6　サーバ対応の環境設定」を参照してください。

LANの状態を設定します。

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。詳細は，「17.6.7　LANの状態設定」を参照してください。

運用管理ポータルとHAモニタのコマンドで，アプリケーションサーバの設定をします。

運用管理ポータル，HAモニタのコマンドを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「17.6.8　アプリケーションサーバの設定」を参照してください。

注意事項

HAモニタと連携する場合のシステム設定時の注意について，次に示します。

HAモニタ連携のアプリケーションサーバに接続するクライアントの設定

HAモニタ連携のアプリケーションサーバに接続するクライアントでは，EJBのルックアップなどで，HAモニタと連携しているアプリケーションサーバを呼び出す場合，エイリアスIPアドレスでアプリケーションサーバを指定してください。

17.6.2　クラスタサーバの環境設定

ここでは，HAモニタと連携する場合の，運用管理ポータルでの設定の留意点について説明します。

参考

運用管理ポータルでシステムの動作環境を設定するには，あらかじめ，Management Serverの起動などが必要です。また，Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。運用管理ポータルでの動作環境の設定や，操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

(1)　「運用管理ドメインの構成定義」での設定

論理サーバを設置するホストおよび各論理サーバの構成を定義します。このとき，［ホストの定義］画面で，「ホスト名」にエイリアスIPアドレスを設定します。

(2)　「論理サーバの環境設定」での設定

論理J2EEサーバ，論理Webサーバ，および論理ネーミングサービスの設定での留意点を次に示します。

(a)　論理J2EEサーバの設定

ホストの固定の設定

次の個所では，「ホストの固定」に「する」を設定してください。

［J2EEコンテナの設定］画面にある「運用監視エージェントの設定」の「ホストの固定」

［EJBコンテナの設定］画面にある「ホストの固定」

［Webコンテナの設定］画面にある「Webサーバとの接続」および「管理用サーバの設定」の「ホストの固定」

ホストを固定すると，運用管理ポータルの「運用管理ドメインの構成定義」で定義したホスト名が使用されます。

グローバルトランザクションの設定

グローバルトランザクションを使用する場合は，次の設定をしてください。

［トランザクションの設定］画面にある「ライトトランザクション機能」を「無効」にします。

［トランザクションの設定］画面にある「インプロセスOTSのステータスファイル格納先」に，共有ディスク装置のディレクトリを設定します。

設定例

/hamon

(b)　論理Webサーバの設定

［Webサーバの設定］画面で，「ホストの固定」に「する」を設定してください。

(c)　論理ネーミングサービスの設定

［ネーミングサービスの設定］画面で，「ホストの固定」に「する」を設定してください。このとき，J2EEサーバが使用するネーミングサービス（アウトプロセスでの起動）を設定する場合は，「運用管理エージェントのホストで固定」のチェックボックスをチェックしないでください。このように設定することで，「運用管理ドメインの構成定義」の［ネーミングサービスの追加］画面で指定したホスト名が使用されます。

17.6.3　設定ファイルの編集

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。ここでは，HAモニタと連携する場合に注意が必要なファイルの設定について説明します。

(1)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）に設定する項目のうち，HAモニタと連携する場合に留意する設定項目について説明します。なお，adminagent.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.1　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

adminagent.adapter.bind_hostキー

adminagent.adapter.bind_hostキーでエイリアスIPアドレスを指定します。管理用のリクエストは，エイリアスIPアドレスだけで受け付けます。例では，次のように設定します。

adminagent.adapter.bind_host=172.16.12.30

adminagent.cluster.localaddress.checkキー

アプリケーションサーバの系切り替え時に，障害などの原因で停止しなかった待機系の論理サーバ，または運用管理エージェントを停止するための設定をします。

adminagent.cluster.localaddress.check=true

(2)　HTTP Serverの設定（Webサーバと連携する場合）

httpsd.conf（HTTP Server定義ファイル）に設定する項目のうち，HAモニタと連携する場合に留意する設定項目について説明します。なお，httpsd.confファイルの各ディレクティブについては，マニュアル「HTTP Server」を参照してください。

Listenディレクティブ，BindAddressディレクティブなど

Listenディレクティブ，BindAddressディレクティブなどには，エイリアスIPアドレスを指定します。クライアントへのサービス提供は，エイリアスIPアドレスだけで実施します。

ProxyPassディレクティブ，ProxyPassReverseディレクティブ

転送先アドレスには，クラスタIPアドレス，クラスタIPアドレスに名前を解決できるホスト名，または"localhost"を指定します。

ServerNameディレクティブ

ServerNameディレクティブには，エイリアスIPアドレス，またはエイリアスIPアドレスに名前を解決できるホスト名を指定します。

(3)　スマートエージェントの設定（CTMを利用する場合）

Management Serverとの連携でCTMを利用する場合には，次のファイルを編集する必要があります。

localaddr

localaddrを作成します。localaddrでは，ステーショナリIPアドレスとエイリアスIPアドレスを設定し，スマートエージェントがステーショナリIPアドレスとエイリアスIPアドレスを通信に使用できるようにします。localaddrの設定については，「付録B　クラスタソフトウェア連携時のTPBrokerの設定（UNIXの場合）」を参照してください。

(4)　Management Serverの運用管理コマンド（mngsvrutil）の設定

現用系と予備系のrootのホームディレクトリに，Management Serverの運用管理コマンド（mngsvrutil）のクライアント側定義ファイル（.mngsvrutilrc）を用意し，Management Serverの管理ユーザのユーザIDとパスワードを設定してください。また，クライアント側定義ファイルには適切なアクセス権限を設定してください。

このファイルは，運用管理エージェントのプロセスを監視するスクリプト，運用管理エージェントと論理サーバを起動および停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

なお，mngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.14　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）」を参照してください。

17.6.4　HAモニタの環境設定

使用しているシステムに従って，sysdefという定義ファイルにHAモニタの環境を定義してください。

HAモニタの環境設定については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.6.5　シェルスクリプトファイルの作成

運用管理エージェントのプロセスを監視し，運用管理エージェントと論理サーバを起動および停止するために，次のシェルスクリプトファイルを作成します。

運用管理エージェントのプロセスを監視するシェルスクリプトファイル

運用管理エージェントと論理サーバを起動するシェルスクリプトファイル

運用管理エージェントと論理サーバを停止するシェルスクリプトファイル

現用系のアプリケーションサーバと予備系のアプリケーションサーバで同一のシェルスクリプトファイルを使用し，同一のパスに配置してください。

(1)　運用管理エージェントのプロセスを監視するシェルスクリプトファイル

運用管理エージェントのプロセスを監視するシェルスクリプトファイルの例（manager_adminagent_monitor.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
AA=/opt/Cosminexus/manager/bin/adminagent

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

logg "### $0: started. ###"
while true
do
    CHECK=`ps -ef | grep $AA | grep -v grep`

    if [ "$CHECK" = "" ]
    then
        logg "### $0: stop. ###"
        exit 0
    fi
    sleep 10
done

(2)　運用管理エージェントと論理サーバを起動するシェルスクリプトファイル

運用管理エージェントと論理サーバを起動するシェルスクリプトファイルの例（manager_adminagent_start.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
SCRIPTDIR=/home/manager/hamon/bin
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

# make adminagent.access.info
logg "### $0: make adminagent.access.info ###"
echo 172.16.12.30:28080,hostA:20295 > $MNGDIR/tmp/adminagent.access.info

# start Administration Agent
logg "### $0: starting Administration Agent. ###"
$MNGDIR/bin/adminagentctl start
if [ $? -eq 0 ] ; then
  logg "### $0: Administration Agent start normally. ###"
else
  logg "### $0: Administration Agent cannot start. ###"
  exit 1
fi

sleep 10

# start logical server
logg "### $0: starting logical servers. ###"
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver1 -s start server
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver2 -s start server
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver3 -s start server

exit 0

このシェルスクリプトファイルでは，アクセス情報ファイル（/opt/Cosminexus/manager/tmp/adminagent.access.info）※の作成，運用管理エージェントの起動，論理サーバの起動をします。

注※

アクセス情報ファイルは，運用管理エージェントの起動後に削除され，Management Serverからアクセスがあった場合に再度作成されます。

ここでは，Management Serverからアクセスがあった場合に再度作成される内容と同じになるように設定してください。このファイルによって，系障害発生時に切り替わった場合に各論理サーバが再起動されます。

シェルスクリプトファイルでの設定内容のポイントを次に示します。

アクセス情報ファイルの作成

例のシェルスクリプトファイルで該当する記述

echo 172.16.12.30:28080,hostA:20295
                           > $MNGDIR/tmp/adminagent.access.info

フォーマット

<Mng_ip>:<Mng_port>,<AA_host>:<AA_port>

設定する内容について次に示します。

Mng_ip

Management ServerのあるホストのIPアドレスを指定します。

Mng_port

Management Server接続HTTPポート番号を指定します。

AA_host

運用管理エージェントのホスト名を指定します。Management Serverの運用管理ポータルの「運用管理ドメインの構成定義」のホストに指定した値を指定してください。

AA_port

運用管理エージェントのポート番号を指定します。Management Serverの運用管理ポータルの「運用管理ドメインの構成定義」の運用管理エージェントのポート番号に指定した値を指定してください。

論理サーバの起動

論理サーバを起動するように設定します。

論理サーバの起動にはmngsvrutilコマンドを使用します。mngsvrutilコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

(3)　運用管理エージェントと論理サーバを停止するシェルスクリプトファイル

運用管理エージェントと論理サーバを停止するシェルスクリプトファイルの例（manager_adminagent_stop.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

# stop logical server
logg "### $0: stop logical servers. ###"
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver3 -s stop server
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver2 -s stop server
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -t lserver1 -s stop server

# stop Administration Agent
logg "### $0: stopping Administration Agent. ###"
$MNGDIR/bin/adminagentctl stop

17.6.6　サーバ対応の環境設定

HAモニタでのサーバ対応の環境設定では，系で稼働させる実行サーバや待機サーバの環境を定義します。

serversという定義ファイルに，アプリケーションサーバの1:1系切り替え用のサーバ対応の環境を定義してください。サーバ対応の環境設定での設定内容を次の表に示します。

表17‒2　サーバ対応の環境設定での設定内容（アプリケーションサーバの1:1系切り替えの場合）

オペランド

設定内容

name

運用管理エージェントと論理サーバを起動するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_adminagent_start.sh

alias

サーバの識別名を指定します。現用系と予備系で同じ名称を指定します。

指定例：CAP

acttype

サーバの起動方法を指定します。ここでは，HAモニタのコマンドでサーバを起動するため，「monitor」を指定します。

termcommand

運用管理エージェントと論理サーバを停止するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_adminagent_stop.sh

initial

サーバ起動時の状態を指定します。

現用系の場合

「online」を指定します。

予備系の場合

「standby」を指定します。

disk

共有ディスク装置のキャラクタ型スペシャルファイル名を指定します。

指定例：/dev/vg00

lan_updown

LANの状態設定ファイルを使用するかどうかを指定します。ここでは，LANの状態設定ファイルを使用するため，「use」を指定します。

fs_name

切り替えるファイルシステムに対応する論理ボリュームの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/dev/rdisk0

fs_mount_dir

切り替えるファイルシステムのマウント先ディレクトリの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/hamon

patrolcommand

運用管理エージェントのプロセスを監視するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_adminagent_monitor.sh

servexec_retry

障害を検出した場合の再起動の回数を指定します。ここでは，障害を検出した場合に再起動をしないで系を切り替えるため，「0」を指定します。

waitserv_exec

運用管理エージェントと論理サーバの起動完了処理を実行するときに起動コマンドの実行完了を待つかどうかを指定します。ここでは，実行完了を待つため，「yes」を指定します。

サーバ対応の環境設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.6.7　LANの状態設定

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。

次のファイルにエイリアスIPアドレスを設定してください。

<サーバ識別名>.upファイル

LANを接続する場合に使用します。LANアダプタに追加するエイリアスIPアドレスを指定します。

<サーバ識別名>.downファイル

LANを切り離す場合に使用します。LANアダプタから削除するエイリアスIPアドレスを指定します。

<サーバ識別名>には，サーバ対応の環境設定（serversファイル）のaliasの値を指定してください。

LANの状態設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.6.8　アプリケーションサーバの設定

アプリケーションサーバの設定では，運用管理ポータル，HAモニタのコマンドを使用してアプリケーションサーバをクラスタ構成に配置します。また，論理サーバをセットアップして設定情報を配布し，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。アプリケーションサーバの設定手順を次に示します。

運用管理サーバを起動します。

運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

Node1およびNode2でHAモニタのmonbeginコマンドを実行して，現用系のアプリケーションサーバを実行系として起動し，予備系のアプリケーションサーバを待機状態にします。

Node1でのコマンドの実行例

「# monbegin CAP」を実行して，Node1の現用系を起動します。

Node2でのコマンドの実行例

「# monbegin CAP」を実行して，Node2の予備系を待機状態にします。

運用管理ポータルで，Node1の現用系のJ2EEサーバをセットアップします。

「運用管理ドメインの構成定義」の［セットアップ］画面で，J2EEサーバをセットアップします。運用管理ポータルでの操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルで，J2EEサーバに設定した情報をNode1の現用系に配布します。

「論理サーバの環境設定」の［設定情報の配布］画面で，J2EEサーバに設定した情報をNode1の現用系に配布します。

サーバ管理コマンドを使用して，Node1の現用系のJ2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。また，インポートしたJ2EEアプリケーションとリソースアダプタを設定および開始します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

なお，J2EEサーバおよびその前提プロセスを起動してからサーバ管理コマンドを実行してください。また，サーバ管理コマンドでの操作が終わったら，サーバ管理コマンドを停止させてください。

Node1でHAモニタのmonswapコマンドを実行して，系を切り替えます。

Node1でのコマンドの実行例

「# monswap CAP」を実行して，サーバ識別名「CAP」で系を切り替えます。Node2の予備系が起動され，Node1の現用系が待機状態になります。

Node2の予備系で，手順3.〜手順5.を実施します。

予備系には，現用系とまったく同じ設定をするため，設定手順や内容については，現用系と同じです。

Node2でHAモニタのmonswapコマンドを実行して，系を切り替えて通常の運用状態に戻します。

Node2でのコマンドの実行例

「# monswap CAP」を実行して，サーバ識別名「CAP」で系を切り替えます。Node1の現用系が起動され，Node2の予備系が待機状態になります。

17.7　運用管理サーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。アプリケーションサーバでは，実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1に配置するシステムと，実行系の運用管理サーバと待機系の運用管理サーバを1:1で配置するシステムを構築・運用できます。運用管理サーバを1:1に配置して系を切り替えるシステムは，Smart Composer機能を使用して構築します。この節では，実行系の運用管理サーバと待機系の運用管理サーバを1:1に配置して系を切り替えるシステムの設定について説明します。

運用管理サーバを1:1に配置して系を切り替えるシステムでは，実行系の運用管理サーバでマシンの障害やManagement Serverのプロセスの終了が発生すると，HAモニタがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守などが必要な場合には，オペレータの操作によって待機している系に計画的に切り替えることができます。

なお，運用管理サーバの1:1系切り替えシステムの運用は，AIXまたはLinuxの場合だけ使用できます。

機能の詳細については，「17.2　1:1系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。また，HAモニタについては，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.7.1　運用管理サーバを対象にした1:1系切り替えシステムの設定手順

ここでは，システムの構築例とシステムの設定手順について説明します。

(1)　システムの構成例

運用管理サーバの1:1系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの設定例を示します。

図17‒14　運用管理サーバを対象にした1:1系切り替えシステムの構成例（UNIXの場合）

運用管理サーバの実行系（現用系）と運用管理サーバの待機系（予備系）を1:1で配置しています。

運用管理サーバの1:1系切り替えシステムでは，まずクラスタを構築して，運用管理サーバをクラスタ内に現用系と予備系として定義します。また，HAモニタで使用するコマンドや出力するメッセージのための，サーバの識別名（サーバの別名）を指定します。現用系と予備系とで同じ名称（例ではCMS）を指定します。

なお，アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。1:1系切り替えシステムの場合，エイリアスIPアドレスは，HAモニタによって動的に割り当てられるアドレスとなります。

(2)　システムの設定手順

HAモニタと連携する場合には，Management ServerやHAモニタのファイルの設定などが必要になります。運用管理サーバの1:1系切り替えシステムの設定手順を次の図に示します。

図17‒15　運用管理サーバを対象にした1:1系切り替えシステムの設定手順（UNIXの場合）

図中の1.〜9.について説明します。

グローバルトランザクションを使用する場合は，共有ディスクにパーティションを作成して，ファイルシステムを構築します。

グローバルトランザクションを使用するためには，トランザクション情報の格納場所を作成します。

グローバルトランザクションを使用する場合は，システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系と予備系で，同じマウント先ディレクトリにしてください。

Management Serverでクラスタサーバの環境を設定します。

Management ServerのSmart Composer機能の簡易構築定義ファイルで，HAモニタを使用する場合の設定をします。詳細は，「17.7.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

簡易構築定義ファイルでは設定できない，Management Serverなどの各種定義ファイルを設定します。詳細は，「17.7.3　設定ファイルの編集」を参照してください。

現用系から予備系にManagement Serverの設定情報をコピーします。

現用系と予備系を同じ環境にするために，現用系でのManagement Serverに関する設定内容を予備系にコピーします。詳細は，「17.7.4　現用系から予備系へのManagement Serverの設定情報のコピー」を参照してください。

HAモニタの環境を設定します。

HAモニタのsysdefファイルで，HAモニタの環境を定義します。詳細は，「17.7.5　HAモニタの環境設定」を参照してください。

シェルスクリプトファイルを作成します。

Management Serverを監視，運用管理サーバを起動および停止するためのシェルスクリプトファイルを作成します。詳細は，「17.7.6　シェルスクリプトファイルの作成」を参照してください。

サーバ対応の環境を設定します。

HAモニタのserversファイルで，系で稼働させる現用系サーバや予備系サーバの環境を定義します。詳細は，「17.7.7　サーバ対応の環境設定」を参照してください。

LANの状態を設定します。

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。詳細は，「17.7.8　LANの状態設定」を参照してください。

17.7.2　クラスタサーバの環境設定

ここでは，HAモニタと連携する場合の，Management Serverでの設定時の留意点について説明します。

参考

Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。Management Serverのセットアップについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.14　運用管理機能を構築する」を参照してください。

(1)　簡易構築定義ファイルでの設定

Management ServerのSmart Composer機能の簡易構築定義ファイルで，論理サーバを設置するホストおよび各論理サーバの構成を定義します。また，必要に応じて，各論理サーバの<configuration>タグ内に，論理サーバの環境や起動／停止の動作などを設定します。設定済みの簡易構築定義ファイルを基に，Smart Composer機能のコマンドを使用して，Webシステムをセットアップします。

セットアップしたWebシステムをSmart Composer機能のコマンドで起動したあと，必要に応じて，サーバ管理コマンドを使用して，J2EEアプリケーション，リソースアダプタをインポートして，開始します。

17.7.3　設定ファイルの編集

設定ファイルを編集します。ここでは，HAモニタと連携する場合に注意が必要な設定ファイルについて説明します。なお，現用系と予備系で必要となる設定が異なります。

Management Serverの設定

Management Serverの運用管理コマンド（mngsvrutil）の設定

現用系では，1.と2.を設定してください。

予備系では，2.だけ設定してください。1.については，現用系からManagement Serverの設定情報をコピーすることで設定できるため，ここでは設定不要です。

(1)　Management Serverの設定

Management Server環境設定ファイル（mserver.properties）に設定する項目のうち，HAモニタと連携する場合に留意する設定項目について説明します。なお，mserver.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

mngsvr.myhost.name

mngsvr.myhost.nameキーでエイリアスIPアドレスを指定します。例では，次のように設定します。

mngsvr.myhost.name=192.168.255.111

(2)　Management Serverの運用管理コマンド（mngsvrutil）の設定

ローカルシステムアカウントのホームディレクトリに，Management Serverの運用管理コマンド（mngsvrutil）のクライアント側定義ファイル（.mngsvrutilrc）を用意し，Management Serverの管理ユーザのユーザIDとパスワードを設定してください。また，クライアント側定義ファイルには適切なアクセス権限を設定してください。

このファイルは，Management Serverのプロセスを監視するスクリプト，運用管理サーバを起動および停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

なお，mngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.14　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）」を参照してください。

17.7.4　現用系から予備系へのManagement Serverの設定情報のコピー

現用系と予備系を同じ環境にするために，現用系でのManagement Serverに関する設定情報を予備系にコピーします。Management Serverの設定情報の退避／回復コマンドを使用して，現用系で設定したManagement Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなどを，現用系から予備系にコピーしてください。

(1)　Management Serverの設定情報のコピー手順

Management Serverの設定情報のコピー手順を次に示します。

現用系で，mstrexportコマンドを実行します。

mstrexportコマンドでは，mstrexportコマンドの実行対象となる現用系のManagement Serverの設定情報を収集し，収集した情報をZIP形式のファイルに保存します。mstrexportコマンドの引数には，保存するZIP形式のファイルのファイル名を指定してください。

コマンドの格納場所

/opt/Cosminexus/manager/bin

実行例

mstrexport /tmp/work/mstruct.zip

なお，mstrexportコマンドは，mstrexportコマンドの実行対象となるManagement Serverの起動，停止に関係なく実行できます。

手順1.で保存されたZIP形式のファイルを，現用系から予備系にコピーします。

予備系で，mstrimportコマンドを実行します。

mstrimportコマンドでは，コピーしてきたZIP形式のファイルを，コマンドの実行対象となる予備系のManagement Serverに展開します。これによって，現用系のManagement Serverと予備系のManagement Serverを同じ設定にできます。

mstrimportコマンドの引数には，コピーしてきたZIP形式のファイルのファイル名を指定してください。

コマンドの格納場所

/opt/Cosminexus/manager/bin

実行例

mstrimport /tmp/recovery/mstruct.zip

なお，mstrimportコマンドは，mstrimportコマンドの実行対象のManagement Serverが停止している場合だけ実行できます。

コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mstrexport（Management Server管理ファイルの退避）」およびマニュアル「アプリケーションサーバ リファレンス コマンド編」の「mstrimport（Management Server管理ファイルの回復）」を参照してください。

(2)　収集対象のファイルの定義

mstrexportコマンドの引数として，mstrexportコマンドの収集対象を記述するファイル（Management Server管理ファイル用退避対象定義ファイル）を指定できます。

実行例

mstrexport /tmp/work/mstruct.zip "/work/filelist.txt"

mstrexportコマンドでは，デフォルトの状態で，Management Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなど，Management Serverでのシステム構築・運用に必要な情報が収集できます。これらの情報に加えて，ユーザ作成のコマンドなどもmstrexportコマンドでの収集対象に追加したい場合には，収集対象とするファイルの絶対パスをManagement Server管理ファイル用退避対象定義ファイルに記述してください。

ファイルの記述例

${cosminexus.home}/manager/apps/MyApp.ear

/home/confdir/message1.conf

ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.13　Management Server管理ファイル用退避対象定義ファイル」を参照してください。

17.7.5　HAモニタの環境設定

使用しているシステムに従って，sysdefという定義ファイルにHAモニタの環境を定義してください。

HAモニタの環境設定については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.7.6　シェルスクリプトファイルの作成

Management Serverのプロセスを監視し，運用管理サーバを起動および停止するために，次のシェルスクリプトファイルを作成します。

Management Serverのプロセスを監視するシェルスクリプトファイル

運用管理サーバを起動するシェルスクリプトファイル

運用管理サーバを停止するシェルスクリプトファイル

現用系の運用管理サーバと予備系の運用管理サーバで同一のシェルスクリプトファイルを使用し，同一のパスに配置してください。

(1)　Management Serverのプロセスを監視するシェルスクリプトファイル

Management Serverのプロセスを監視するシェルスクリプトファイルの例（manager_mngsvr_monitor.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/mngsvr.log 2>&1
}

logg "### $0: started. ###"
while true
do
$MNGDIR/bin/mngsvrutil -m 192.168.255.111:28080 check mngsvr
    if [ $? -ne 0 ]
    then
        logg "### $0: stop. ###"
        exit 0
    fi
    sleep 10
done

このシェルスクリプトファイルでは，mngsvrutilのcheckコマンドでManagement Serverの稼働状況を確認します。なお，mngsvrutilコマンドの-mオプションの引数のホスト名にはエイリアスIPアドレスを指定します。

(2)　運用管理サーバを起動するシェルスクリプトファイル

運用管理サーバを起動するシェルスクリプトファイルの例（manager_mngsvr_start.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager
RETRY_COUNT=20
RETRY_INTERVAL=10

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/mngsvr.log 2>&1
}
# start Management Server
logg "### $0: starting Management Server. ###"
$MNGDIR/bin/mngsvrctl start &

I=0
while [ $I -lt $RETRY_COUNT ] ; do
  $MNGDIR/bin/mngsvrutil -m 192.168.255.111:28080 check mngsvr
  if [ $? -eq 0 ] ; then
    break
  fi
  sleep $RETRY_INTERVAL
  I=`expr $I + 1`
done
exit 0

(3)　運用管理サーバを停止するシェルスクリプトファイル

運用管理サーバを停止するシェルスクリプトファイルの例（manager_mngsvr_stop.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager
logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/mngsvr.log 2>&1
}
# stop Management Server
logg "### $0: stop Management Server. ###"
$MNGDIR/bin/mngsvrctl stop
exit 0

17.7.7　サーバ対応の環境設定

HAモニタでのサーバ対応の環境設定では，系で稼働させる実行サーバや待機サーバの環境を定義します。

serversという定義ファイルに，運用管理サーバの1:1系切り替え用のサーバ対応の環境を定義してください。サーバ対応の環境設定での設定内容を次の表に示します。

表17‒3　サーバ対応の環境設定での設定内容（運用管理サーバの1:1系切り替えの場合）

オペランド

設定内容

name

運用管理サーバを起動するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_mngsvr_start.sh

alias

サーバの識別名を指定します。現用系と予備系で同じ名称を指定します。

指定例：CMS

acttype

サーバの起動方法を指定します。ここでは，HAモニタのコマンドでサーバを起動するため，「monitor」を指定します。

termcommand

運用管理サーバを停止するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_mngsvr_stop.sh

initial

サーバ起動時の状態を指定します。

現用系の場合

「online」を指定します。

予備系の場合

「standby」を指定します。

disk

共有ディスク装置のキャラクタ型スペシャルファイル名を指定します。

指定例：/dev/vg00

lan_updown

LANの状態設定ファイルを使用するかどうかを指定します。ここでは，LANの状態設定ファイルを使用するため，「use」を指定します。

fs_name

切り替えるファイルシステムに対応する論理ボリュームの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/dev/rdisk0

fs_mount_dir

切り替えるファイルシステムのマウント先ディレクトリの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/hamon

patrolcommand

Management Serverのプロセスを監視するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_mngsvr_monitor.sh

servexec_retry

障害を検出した場合の再起動の回数を指定します。ここでは，障害が発生した場合に再起動しないで系を切り替えるため，「0」を指定します。

waitserv_exec

運用管理サーバの起動完了処理を実行するときに起動コマンドの実行完了を待つかどうかを指定します。ここでは，実行完了を待つため，「yes」を指定します。

serversファイルの例を次に示します。

serversファイルの例（現用系の場合）

現用系の場合のserversファイルの例を次に示します。

server  name           /home/manager/hamon/bin/manager_mngsvr_start.sh,
        alias          CMS,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_mngsvr_stop.sh,
        initial        online,
        disk           /dev/vg00,
        lan_updown     use,
        fs_name        /dev/rdisk0,
        fs_mount_dir   /hamon,
        patrolcommand  /home/manager/hamon/bin/manager_mngsvr_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

serversファイルの例（予備系の場合）

予備系の場合のserversファイルの例を次に示します。

server  name           /home/manager/hamon/bin/manager_mngsvr_start.sh,
        alias          CMS,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_mngsvr_stop.sh,
        initial        standby,
        disk           /dev/vg00,
        lan_updown     use,
        fs_name        /dev/rdisk0,
        fs_mount_dir   /hamon,
        patrolcommand  /home/manager/hamon/bin/manager_mngsvr_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

サーバ対応の環境設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.7.8　LANの状態設定

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。

次のファイルにエイリアスIPアドレスを設定してください。

<サーバ識別名>.upファイル

LANを接続する場合に使用します。LANアダプタに追加するエイリアスIPアドレスを指定します。

<サーバ識別名>.downファイル

LANを切り離す場合に使用します。LANアダプタから削除するエイリアスIPアドレスを指定します。

<サーバ識別名>には，サーバ対応の環境設定（serversファイル）のaliasの値を指定してください。

LANの状態設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

17.8　アプリケーションサーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）

この節では，アプリケーションサーバを対象にした1:1系切り替えシステムを利用する場合の，システムの起動と停止の手順について説明します。稼働開始後にJ2EEサーバ，またはバッチサーバをメンテナンスするときの，起動と停止の手順についても説明します。

アプリケーションサーバを対象にした1:1系切り替えシステムでは，クラスタサービスを使用します。クラスタサービスの詳細については，OSのマニュアルを参照してください。

1:1系切り替えシステムを利用して運用する場合は，あらかじめ現用系と予備系の2種類のホストの用意や，クラスタサービスの対象となる運用管理エージェントを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「17.4　アプリケーションサーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）」を参照してください。

なお，この節では，手順内で計画的な系切り替えを実行する前には，現用系ホストが実行系ホストとして起動されていることを前提にして説明します。

注意事項

運用管理エージェントのダウンによって系切り替えが発生した場合，運用管理エージェントのダウンしたホストには各論理サーバのプロセスが残っている場合があります。プロセスが残っていると系の切り戻しが発生した時に，論理サーバの起動ができなくなってしまうため，系の切り戻しが発生する前にすべてのプロセスを停止させる必要があります。また，そのほかに，業務が正しく開始されるための作業をあらかじめ実施しておいてください。

ポイント

1:1系切り替えシステムを利用する場合，Management Serverは運用管理サーバで起動します。なお，個々のアプリケーションサーバのホストでは，運用管理エージェントをOS起動と同時に起動する設定にしないでください。

17.8.1　アプリケーションサーバを対象にした1:1系切り替えシステムの起動

ここでは，アプリケーションサーバを対象にした1:1系切り替えシステムの起動方法について説明します。

アプリケーションサーバを対象にした1:1系切り替えシステムを起動するには，あらかじめ運用管理サーバを起動しておくことが必要です。運用管理サーバを起動していない場合には，運用管理サーバを先に起動しておいてください。運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

アプリケーションサーバを対象にした1:1系切り替えシステムの起動手順を次に示します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

現用系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

予備系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オンラインにする］を選択します。

1:1系切り替えシステムが起動します。

17.8.2　アプリケーションサーバを対象にした1:1系切り替えシステムの停止

ここでは，アプリケーションサーバを対象にした1:1系切り替えシステムの停止方法について説明します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オフラインにする］を選択します。

実行系ノードおよび待機系ノードが含まれているリソースグループがオフラインになります。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

予備系ノードのクラスタサービスが停止します。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

現用系ノードのクラスタサービスが停止します。

なお，運用管理サーバは最後に手動で停止します。運用管理サーバの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

17.8.3　アプリケーションサーバを対象にした1:1系切り替えシステムで計画的に系を切り替えるときの起動と停止

トラブル発生時以外で，アプリケーションサーバを対象にした1:1系切り替えシステムの実行系と待機系を切り替える手順を次に示します。系を切り替えるときは，待機系のホストでアプリケーションサーバが待機状態になっている必要があります。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

系が切り替わります。

17.8.4　アプリケーションサーバを対象にした1:1系切り替えシステムをメンテナンスする場合の起動と停止

アプリケーションサーバを対象にした1:1系切り替えシステムをメンテナンスする場合の，起動と停止の手順を次に示します。

なお，これらの手順は，すでに実行系のホストでアプリケーションサーバが起動している場合の手順です。

(1)　再起動が不要なメンテナンスの場合の手順

実行系のホストで，動作中のJ2EEアプリケーションとリソースアダプタを停止します。

バッチサーバの場合は，バッチアプリケーションが実行中でないことを確認してからリソースアダプタを停止してください。

停止方法については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録F.4　システムの停止方法」を参照してください。

サーバ管理コマンドを使用してメンテナンス処理を実行します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

手順1.で停止したJ2EEアプリケーションとリソースアダプタを開始します。

J2EEサーバの場合はJ2EEアプリケーションとリソースアダプタを開始します。また，バッチサーバの場合はリソースアダプタを開始します。

開始方法については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録C.2　システムの起動方法」を参照してください。

必要に応じてJ2EEアプリケーションとリソースアダプタの動作確認をします。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

系が切り替わります。

切り替え後の実行系のホストで手順1.〜手順6.を実行します。

切り替え後の実行系のホストを実行系に戻す場合，コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

メンテナンスが完了します。

(2)　再起動が必要なメンテナンスの場合（両方の系を同時に停止する方法）

論理サーバを一括停止する設定にしていない場合は，実行系のホストで各論理サーバを停止します。

Management Serverによって一括停止する設定の場合は，不要な手順です。停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オフラインにする］を選択します。

実行系ノードおよび待機系ノードが含まれているリソースグループがオフラインになります。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

予備系ノードのクラスタサービスが停止します。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

現用系ノードのクラスタサービスが停止します。

現用系と予備系の両方のホストで，定義ファイルの変更など，メンテナンス作業を実行します。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

現用系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

予備系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で現用系ノードおよび予備系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オンラインにする］を選択します。

1:1系切り替えシステムが再起動します。

論理サーバを一括起動する設定にしていない場合は，実行系のホストで各論理サーバを起動します。

Management Serverによって一括起動する設定の場合は，不要な手順です。起動方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.2　システムの起動方法」を参照してください。

実行系のホストで，必要に応じて，定義の変更に関連した動作確認を実行します。

メンテナンスが完了します。

(3)　再起動が必要なメンテナンスの場合（両方の系を同時に停止しない方法）

待機系のホストで，定義ファイルの変更など，メンテナンス作業を実行します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

実行系のホストのアプリケーションサーバが停止してから，今まで待機していた系でアプリケーションサーバが起動します。これによって，メンテナンス済みのホストが実行系ホストになります。

切り替え後の実行系のホストで，必要に応じて，定義の変更に関連した動作確認を実行します。

切り替え後の待機系のホストで定義ファイルの編集など，メンテナンス作業を実行します。

切り替え後の実行系のホストを実行系に戻す場合，コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

切り替え後の実行系のホストで，必要に応じて，定義の変更に関連した動作確認を実行します。

メンテナンスが完了します。

17.9　運用管理サーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）

この節では，運用管理サーバを対象にした1:1系切り替えシステムを利用する場合の，システムの起動と停止の方法について説明します。

運用管理サーバを対象にした1:1系切り替えシステムでは，クラスタサービスを使用します。クラスタサービスの詳細については，OSのマニュアルを参照してください。

運用管理サーバを対象にした1:1系切り替えシステムを利用するには，あらかじめ現用系と予備系の2種類のホストの用意や，クラスタサービスの対象となるManagement Serverを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「17.5　運用管理サーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）」を参照してください。現用系と予備系の詳細については，「15.2　クラスタソフトウェアと連携して実現できる運用」を参照してください。

17.9.1　運用管理サーバを対象にした1:1系切り替えシステムの起動

ここでは，運用管理サーバを対象にした1:1系切り替えシステムの起動方法について説明します。

運用管理サーバを対象にした1:1系切り替えシステムを起動するには，あらかじめ起動するアプリケーションサーバの運用管理エージェントを起動しておくことが必要です。運用管理エージェントを起動していない場合には，運用管理エージェントを先に起動しておいてください。運用管理エージェントの起動方法については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

運用管理サーバを対象にした1:1系切り替えシステムの起動手順を次に示します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で運用管理サーバの現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

現用系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で運用管理サーバの予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

予備系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で運用管理サーバの現用系ノードおよび予備系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オンラインにする］を選択します。

運用管理サーバを対象にした1:1系切り替えシステムが起動します。

17.9.2　運用管理サーバを対象にした1:1系切り替えシステムの停止

ここでは，運用管理サーバを対象にした1:1系切り替えシステムの停止方法について説明します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で運用管理サーバの実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オフラインにする］を選択します。

運用管理サーバの実行系ノードおよび待機系ノードが含まれているリソースグループがオフラインになります。

コンソールツリー（左ペイン）で運用管理サーバの予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

運用管理サーバの予備系ノードのクラスタサービスが停止します。

コンソールツリー（左ペイン）で運用管理サーバの現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

運用管理サーバの現用系ノードのクラスタサービスが停止します。

アプリケーションサーバの運用管理エージェントを停止します。

運用管理エージェントの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

17.9.3　運用管理サーバを対象にした1:1系切り替えシステムで計画的に系を切り替えるときの起動と停止

トラブル発生時以外で，運用管理サーバを対象にした1:1系切り替えシステムの実行系と待機系を切り替える手順を次に示します。系を切り替えるときは，待機系のホストでアプリケーションサーバが待機状態になっている必要があります。

システムの運用中にManagement Serverの設定情報を変更した場合，実行系のManagement Serverの設定情報を収集して，実行系から待機系へコピーします。また，mstrimportコマンドを実行して，コピーしたManagement Serverの設定情報を待機系に適用します。

実行系のManagement Serverと待機系のManagement Serverが同じ設定になります。

Management Serverの設定情報を実行系から待機系へコピーして，待機系に適用する方法については，「17.7.4　現用系から予備系へのManagement Serverの設定情報のコピー」の1:1系切り替えシステムの設定に関する説明を参照してください。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［グループの移動］を選択します。

系が切り替わります。

17.10　1:1系切り替えシステムの起動と停止（UNIXの場合）

この節では，HAモニタによる1:1系切り替えシステムを利用する場合の，システムの起動と停止の手順について説明します。稼働開始後にJ2EEサーバ，バッチサーバ，Management Serverなどをメンテナンスする場合の，起動と停止の手順についても説明します。なお，HAモニタを利用できるのは，AIXまたはLinuxの場合だけです。

1:1系切り替えシステムを利用して運用する場合は，あらかじめ現用系と予備系の2種類のホストの用意や，HAモニタの監視の対象となる運用管理エージェント（アプリケーションサーバの1:1系切り替えシステムの場合）またはManagement Server（運用管理サーバの1:1系切り替えシステムの場合）を監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「17.6　アプリケーションサーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）」および「17.7　運用管理サーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）」を参照してください。

アプリケーションサーバの1:1系切り替えシステムと，運用管理サーバの1:1系切り替えシステムで実行できる運用操作およびその参照先を次の表に示します。

表17‒4　1:1系切り替えシステムで実行できる運用操作

運用操作

アプリケーションサーバの1:1系切り替えシステム

運用管理サーバの1:1系切り替えシステム

システムの起動

17.10.1参照

17.10.1参照

システムの停止

17.10.2参照

17.10.2参照

実行系と待機系を計画的に系切り替えする場合のシステムの起動と停止

17.10.3参照

17.10.3参照

メンテナンスする場合のシステムの起動と停止

17.10.4参照

17.10.5参照

また，次のコマンドは，HAモニタが提供しているコマンドです。詳細は，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

monbegin（HAモニタとのインタフェースを持たないサーバを起動）

monend（HAモニタとのインタフェースを持たない実行サーバの停止連絡）

monsbystp（待機サーバの停止）

monswap（計画系切り替え）

17.10.1　1:1系切り替えシステムの起動

1:1系切り替えシステムを利用する場合のシステム起動時の留意事項，およびシステムの起動手順について説明します。

(1)　システム起動時の留意事項

1:1系切り替えシステムを利用する場合のシステム起動時の留意事項を次に示します。

現用系と予備系のホストに配置されたHAモニタは，OSの起動と同時に起動されています。

アプリケーションサーバの1:1系切り替えシステムを起動する場合，運用管理サーバを使用するときは，運用管理サーバをあらかじめ起動しておいてください。運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

運用管理サーバの1:1系切り替えシステムを起動する場合，アプリケーションサーバを別ホストに配置しているときは，運用管理ドメイン内のアプリケーションサーバの運用管理エージェントをあらかじめ起動しておいてください。運用管理エージェントの起動方法については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

(2)　システムの起動手順

1:1系切り替えシステムを利用する場合のシステムの起動手順を次に示します。

現用系のホストでmonbeginコマンドを実行して，現用系のホストを実行系として起動します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，運用管理エージェントを起動するスクリプトファイルに定義されている処理が実行されて，現用系のホストが実行系として起動します。

予備系のホストでmonbeginコマンドを実行して，予備系のホストを待機系として起動します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，予備系のホストが待機系となり，実行系の障害に備えます。

注意事項

Management Server起動時に運用管理ドメイン内の論理サーバを一括起動する設定にしていない場合は，現用系のホストの各論理サーバを起動してください。なお，Management Server起動時に運用管理ドメイン内の論理サーバを一括起動するように設定にしている場合，論理サーバの手動起動は不要です。起動方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.2　システムの起動方法」を参照してください。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.6.6　サーバ対応の環境設定」，または「17.7.7　サーバ対応の環境設定」を参照してください。

17.10.2　1:1系切り替えシステムの停止

1:1系切り替えシステムの停止手順について説明します。

ここでは，次の二つの場合の停止手順について説明します。

実行系と待機系の両方のホストを停止する場合

待機系のホストだけ停止する場合

(1)　実行系と待機系の両方のホストを停止する場合

実行系と待機系の両方のホストを停止する場合の手順を次に示します。

運用管理エージェントを停止するスクリプトで，運用管理ドメイン内の論理サーバを一括停止する設定にしていない場合は，実行系のホストの各論理サーバを停止します。

運用管理エージェントを停止するスクリプトで論理サーバを停止する設定にしている場合は，不要な手順です。論理サーバの停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

実行系のホストでmonendコマンドを実行して，実行系のホストの運用管理エージェントを停止します。

# monend サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，実行系のホストの運用管理エージェントが停止します。また，HAモニタによって待機系に自動的に停止指示が出され，待機系のホストの運用管理エージェントも停止します。

なお，アプリケーションサーバの1:1系切り替えシステムの場合，運用管理サーバを使用しているときは，運用管理サーバは最後に手動で停止します。運用管理サーバの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.6.6　サーバ対応の環境設定」，または「17.7.7　サーバ対応の環境設定」を参照してください。

(2)　待機系のホストだけ停止する場合

実行系は停止しないで待機系で待機状態をやめる場合は，待機系のホストで次のコマンドを実行します。

# monsbystp サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

17.10.3　1:1系切り替えシステムで計画的に系を切り替える場合の起動と停止

1:1系切り替えシステムでトラブル発生時以外の場合に，実行系と待機系を計画的に切り替えるときの手順について説明します。系を切り替えるときには，待機系のホストでアプリケーションサーバが待機状態になっている必要があります。

1:1系切り替えシステムで実行系と待機系を計画的に切り替えるときの手順を次に示します。なお，現用系のホストが実行系として起動されていることを前提としています。

運用管理エージェントを停止するスクリプトで，運用管理ドメイン内の論理サーバを一括停止する設定にしていない場合は，実行系のホストで各論理サーバを停止します。

運用管理エージェントを停止するスクリプトで論理サーバを停止する設定にしている場合は，不要な手順です。論理サーバの停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

実行系のホストでmonswapコマンドを実行して，系を切り替えます。

# monswap サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

運用管理エージェントを停止するスクリプトに定義されている処理が実行されて，実行系のホストのアプリケーションサーバが停止します。そのあと，今まで待機していた系でアプリケーションサーバが起動します。これで，計画的な系切り替えの手順は完了です。

参考

1:1系切り替えシステムをメンテナンスする場合の起動と停止の手順については，「17.10.4　アプリケーションサーバの1:1系切り替えシステムをメンテナンスする場合の起動と停止」または「17.10.5　運用管理サーバの1:1系切り替えシステムをメンテナンスする場合の起動と停止」を参照してください。

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.6.6　サーバ対応の環境設定」，または「17.7.7　サーバ対応の環境設定」を参照してください。

17.10.4　アプリケーションサーバの1:1系切り替えシステムをメンテナンスする場合の起動と停止

アプリケーションサーバの1:1系切り替えシステムをメンテナンスする場合の，起動と停止の手順について説明します。

ここでは，次の三つの場合の停止手順について説明します。

再起動が不要なメンテナンスの場合

再起動が必要なメンテナンスの場合（両方の系を同時に停止する方法）

再起動が必要なメンテナンスの場合（両方の系を同時に停止しない方法）

なお，これらの手順は，すでに実行系のホストでアプリケーションサーバが起動している場合の手順です。

注意事項

運用管理エージェントのダウンによって系切り替えが発生した場合，運用管理エージェントのダウンしたホストには各論理サーバのプロセスが残っている場合があります。プロセスが残っていると系の切り戻しが発生した時に，論理サーバの起動ができなくなってしまうため，系の切り戻しが発生する前にすべてのプロセスを停止させる必要があります。また，そのほかに，業務が正しく開始されるための作業をあらかじめ実施しておいてください。

(1)　再起動が不要なメンテナンスの場合

再起動が不要なメンテナンスをする場合の起動と停止の手順を次に示します。

実行系のホストで，動作中のJ2EEアプリケーションとリソースアダプタを停止します。

バッチサーバの場合は，バッチアプリケーションが実行中でないことを確認してからリソースアダプタを停止してください。

停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

サーバ管理コマンドを使用してメンテナンス処理を実行します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

手順1.で停止したJ2EEアプリケーションとリソースアダプタを開始します。

J2EEサーバの場合はJ2EEアプリケーションとリソースアダプタを開始します。また，バッチサーバの場合はリソースアダプタを開始します。

開始方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.2　システムの起動方法」を参照してください。

必要に応じてJ2EEアプリケーションとリソースアダプタの動作確認をします。

実行系のホスト（現用系のホスト）で，monswapコマンドを実行して，系を切り替えます。

実行系のホスト（現用系ホスト）が待機系のホストに切り替わり，待機系だったホスト（予備系ホスト）が実行系ホストになります。

切り替え後の実行系のホスト（予備系のホスト）で手順1.〜手順4.を実行します。

切り替え後の実行系のホスト（予備系のホスト）で，必要に応じて，再度monswapコマンドを実行します。

現用系のホストを実行系に戻す場合に実行してください。

これで，メンテナンス時の起動と停止の手順は完了です。

(2)　再起動が必要なメンテナンスの場合（両方の系を同時に停止する方法）

再起動が必要なメンテナンスをする場合に，両方の系を同時に停止するときの起動と停止の手順を次に示します。

運用管理エージェントを停止するスクリプトで，運用管理ドメイン内の論理サーバを一括停止する設定にしていない場合は，実行系のホストで各論理サーバを停止します。

運用管理エージェントを停止するスクリプトで論理サーバを停止する設定にしている場合は，不要な手順です。論理サーバの停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

実行系のホストでmonendコマンドを実行して，システムを停止します。

# monend サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

実行系のホストが停止します。また，HAモニタによって待機系に自動的に停止指示が出され，待機系のホストも停止します。

現用系と予備系の両方のホストで，定義ファイルの変更など，メンテナンス作業を実行します。

現用系のホストでmonbeginコマンドを実行して，現用系のホストの運用管理エージェントを起動します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，現用系のホストが，実行系として起動します。

予備系のホストでmonbeginコマンドを実行します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，予備系のホストが，待機系として起動します。

運用管理エージェントを起動するスクリプトで運用管理ドメイン内の論理サーバを一括起動する設定にしていない場合は，実行系のホストの各論理サーバを起動します。

運用管理エージェントを起動するスクリプトで論理サーバを起動する設定にしている場合は，不要な手順です。論理サーバの起動方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.2　システムの起動方法」を参照してください。

実行系のホストで，必要に応じて，定義の変更に関連した動作確認を実行します。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.6.6　サーバ対応の環境設定」を参照してください。

(3)　再起動が必要なメンテナンスの場合（両方の系を同時に停止しない方法）

再起動が必要なメンテナンスをする場合に，両方の系を同時に停止しないときの起動と停止の手順を次に示します。

待機系のホストで，定義ファイルの変更など，メンテナンス作業を実行します。

実行系のホストでmonswapコマンドを実行して，系を切り替えます。

# monswap サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

実行系のホストのアプリケーションサーバが停止してから，今まで待機していた系でアプリケーションサーバが起動します。これによって，メンテナンス済みのホストが実行系ホストになります。

切り替え後の実行系のホスト（予備系のホスト）で，必要に応じて，定義の変更に関連した動作確認を実行します。

切り替え後の待機系のホスト（現用系のホスト）で定義ファイルの編集など，メンテナンス作業を実行します。

切り替え後の実行系のホスト（予備系のホスト）で，必要に応じて，再度monswapコマンドを実行します。

現用系のホストを実行系に戻す場合に実行してください。

切り替え後の実行系のホスト（現用系のホスト）で，必要に応じて，定義の変更に関連した動作確認を実行します。

これで，メンテナンス時の起動と停止の手順は完了です。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.6.6　サーバ対応の環境設定」を参照してください。

17.10.5　運用管理サーバの1:1系切り替えシステムをメンテナンスする場合の起動と停止

Management Serverの設定を変更するために，運用管理サーバの1:1系切り替えシステムをメンテナンスする場合の起動と停止の手順について説明します。

なお，これらの手順は，すでに実行系のホストでManagement Serverが起動している場合の手順です。

実行系のホスト（現用系のホスト）で，mstrexportコマンドを実行します。

# mstrexport mstruct.zip

現用系のホストのManagement Serverの設定情報が自動収集されて，収集された情報がZIP形式のファイルに保存されます。

下線部分には，自動収集された設定情報を保存するZIP形式のファイルのパスを指定します。

手順1.で保存されたZIP形式のファイルを，実行系から待機系にコピーします。

待機系のホスト（予備系のホスト）で，mstrimportコマンドを実行します。

# mstrimport mstruct.zip

下線部分には，手順2でコピーしたZIP形式のファイルのパスを指定します。

これによって，手順2.でコピーしたManagement Serverの設定情報が待機系のホストに展開されて，実行系のManagement Serverと待機系のManagement Serverが同じ設定になります。

実行系のホストでmonswapコマンドを実行して，系を切り替えます。

# monswap サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

実行系のホストのManagement Serverが停止してから，今まで待機していた系でManagement Serverが起動します。Management Serverの起動時に実行系の設定情報がシステムに反映されます。

切り替え後の実行系のホスト（予備系のホスト）で，必要に応じて，定義の変更に関連した動作確認を実行します。

切り替え後の実行系のホスト（予備系のホスト）で，必要に応じて，再度monswapコマンドを実行します。

現用系のホストを実行系に戻す場合に実行してください。

切り替え後の実行系のホスト（現用系のホスト）で，必要に応じて，定義の変更に関連した動作確認を実行します。

これで，メンテナンス時の起動と停止の手順は完了です。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「17.7.7　サーバ対応の環境設定」を参照してください。

17.11　系切り替えシステムの設定内容の確認方法

現用系と予備系のJ2EEサーバおよびHTTP Serverの設定内容は，基本的に同一の設定内容になります。現用系と予備系の次に示す設定ファイルを比較して確認してください。

注意事項

J2EEサーバは，使用するコンポーネントによって定義が異なる場合がありますので，それらのプロパティの設定内容は各コンポーネントの仕様に従ってください。

17.11.1　J2EEサーバの設定

表17‒5　J2EEサーバの設定ファイル

項番

設定ファイル

ファイル格納先

1

usrconf.cfg

（J2EEサーバ用オプション定義ファイル）

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥

UNIXの場合

/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/

2

usrconf.properties※1

（J2EEサーバ用ユーザプロパティファイル）

3

server.policy

（J2EEサーバ用セキュリティポリシーファイル）

4

Connector属性ファイル

cjgetrarprop（RARファイルの属性の取得）コマンドで取得する。※2

注※1　「webserver.connector.http.permitted.hosts」は異なっていても問題ありません。

注※2　ユーザ名とパスワードは取得できないため，設定の内容は確認できません。

17.11.2　HTTP Serverの設定

表17‒6　HTTP Serverの設定ファイル

項番

設定ファイル

ファイル格納先

1

httpsd.conf

Windowsの場合

<HTTP Serverインストールディレクトリ>¥servers¥HWS_<論理サーバ名>¥conf¥

UNIXの場合

/opt/hitachi/httpsd/servers/HWS_<論理サーバ名>/conf/

2

mime.types

17.11.3　運用管理サーバの設定

運用管理サーバの設定ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.1　Managerで使用するファイルの一覧」を参照してください。

18　相互系切り替えシステム（クラスタソフトウェアとの連携）

この章では，クラスタソフトウェアと連携して，相互系切り替えシステムで運用するシステムについて説明します。

18.1　この章の構成

この章の構成を次の表に示します。

表18‒1　この章の構成（相互系切り替えシステム（クラスタソフトウェアとの連携））

分類

タイトル

参照先

解説

相互系切り替えシステムの概要

18.2

相互系切り替えシステムのシステム構成と動作

18.3

設定

相互系切り替えシステムの設定（Windowsの場合）

18.4

相互系切り替えシステムの設定（UNIXの場合）

18.5

運用

相互系切り替えシステムの起動と停止（Windowsの場合）

18.6

相互系切り替えシステムの起動と停止（UNIXの場合）

18.7

注　「実装」，「注意事項」について，この機能固有の説明はありません。

18.2　相互系切り替えシステムの概要

相互系切り替えシステムとは，1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。

この節では，相互スタンバイシステムのシステムの構成例と系切り替え処理の流れについて説明します。系切り替えのタイミングや系切り替え時のシステムの動作などは1:1系切り替え構成の場合と同じです。参照先を次の表に示します。

表18‒2　系切り替え時の動作と参照先

系切り替え時の動作

参照先

系切り替えのタイミング

17.3.2

系切り替え時のシステムの動作

17.3.4

系切り替え時の情報の引き継ぎ

17.3.5

18.3　相互系切り替えシステムのシステム構成と動作

この節では，相互系切り替えシステムのシステムの構成例，系切り替え処理の流れなどについて説明します。

18.3.1　相互系切り替えシステムのシステム構成例

クラスタソフトウェアと連携した相互系切り替えシステムの構成例を次の図に示します。系切り替え時，クライアントやデータベースなどサーバの外からは，同じ論理アドレスでアプリケーションサーバが再起動したように見えます。

図18‒1　相互系切り替えシステムの構成例

図に示す，相互系切り替えシステムについて説明します。

実行系1（待機系2）および待機系1（実行系2）の各アプリケーションサーバは，異なる運用管理ドメインで管理されています。

それぞれの運用管理ドメイン内に，現用系および予備系の二つの仮想ホストを定義しています。現用系および予備系の仮想ホストは，それぞれ実行系アプリケーションサーバ，待機系アプリケーションサーバとして使用します。

障害発生時は，相互の運用管理ドメイン内の仮想ホストが切り替えられます。例えば，図中のサーバ1の現用系仮想ホストで障害が発生した場合，サーバ1の予備系仮想ホストに系が切り替えられます。

各サーバの運用に使用するIPアドレスは，クラスタソフトウェアによって動的に割り当てられるIPアドレス（エイリアスIPアドレス）を使用します。図中の相互系切り替えシステムの場合，「xxx.xxx.1.111」および「xxx.xxx.2.222」がエイリアスIPアドレスとなります。なお，クラスタソフトウェアはIPアドレス単位にLANを切り替えるため，サーバ1およびサーバ2のクラスタIPアドレスには一意となる値が割り当てられます。系切り替え時は，現用系仮想ホストでエイリアスIPアドレスが削除され，予備系仮想ホストでエイリアスIPアドレスが追加されることで処理が引き継がれます。

Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系へ移動しないIPアドレス（ステーショナリIPアドレス）を使用します。図中の相互系切り替えシステムの場合，現用系1の「xxx.xxx.0.11」，および予備系1の「xxx.xxx.0.22」がステーショナリIPアドレスとなります。

参考

仮想ホストとは，一つのマシンに複数の異なるIPアドレスを割り当てて，複数の物理ホストとして使用できる構成です。同一運用管理ドメイン内の仮想ホストは，一つの運用管理エージェントによってアプリケーションサーバの起動や停止などの運用操作を制御できますが，運用に使用するIPアドレスは異なるため，見かけ上は異なる物理ホストとして扱われます。

なお，相互系切り替えシステムでは次のような運用ができます。

共有ディスク装置の使用

共有ディスク装置の使用については，ローカルトランザクションの場合とグローバルトランザクションの場合とで異なります。

ローカルトランザクションの場合

共有ディスク装置は不要です。ローカルトランザクションでは，実行系と待機系との間で引き継ぐセッション情報がないため，共有ディスク装置を使用しません。

グローバルトランザクションの場合

共有ディスク装置が必要になります。共有ディスク装置は，系切り替え時に，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。

JP1との連携

クラスタソフトウェアを使用した構成では，JP1とも連携できます。

JP1と連携する場合，アプリケーションサーバには，JP1/Baseなども必要になります。クラスタソフトウェアでのJP1の管理は，アプリケーションサーバとは別に行う必要があります。

データベースサーバでのクラスタソフトウェアとの連携

データベースサーバでもクラスタソフトウェアを使用した構成にすることもできます。この場合，アプリケーションサーバ側では，仮想アドレス（論理アドレス）だけを認識していれば，特にデータベースサーバがクラスタソフトウェアを使用していることを意識する必要はありません。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

相互系切り替えシステムのシステム構成の詳細については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成」を参照してください。

18.3.2　相互系切り替えシステムでの系切り替え処理の流れ

相互系切り替えシステムでの系切り替え時の動作と，処理の流れについて説明します。

(1)　系切り替えの動作

相互系切り替えシステムでの系切り替えは次の図のようにして行われます。この図では，実行系1（待機系2）の現用系仮想ホストに障害が発生し，待機系1（実行系2）の予備系仮想ホストに系を切り替える場合の例を示します。

図18‒2　相互系切り替えシステムでの系切り替えの動作

(2)　系切り替えの処理の流れ

相互系切り替えシステムに適用できる系切り替えには，自動系切り替えと計画系切り替えの二つがあります。自動系切り替えとは，クラスタソフトウェアが自動的に系を切り替える方法です。実行系に障害が発生したときは，自動系切り替えになります。一方，計画系切り替えとは，オペレータが系を保守する際に，計画的に系を切り替える方法です。実行系からクラスタソフトウェアのコマンドを使用して切り替えます。

ここでは，系切り替え処理の流れについて，自動系切り替えの場合と計画系切り替えの場合に分けて説明します。

(a)　自動系切り替えの処理の流れ

相互系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。この図では，実行系1（待機系2）の現用系仮想ホストに障害が発生して，待機系1（実行系2）の予備系仮想ホストに系を切り替えるときの処理の流れを示します。

図18‒3　相互系切り替えシステムでの自動系切り替えの処理の流れ

(b)　計画系切り替えの処理の流れ

相互系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。この図では，クラスタソフトウェアのコマンドを使用して，実行系1（待機系2）の現用系仮想ホストを予備系仮想ホストに，待機系1（実行系2）の予備系仮想ホストを現用系仮想ホストに切り替えるときの流れについて示します。

図18‒4　相互系切り替えシステムでの計画系切り替えの処理の流れ

18.4　相互系切り替えシステムの設定（Windowsの場合）

相互系切り替えシステムは，アプリケーションサーバの実行系と待機系を1:1にする構成の一つで，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にする構成（相互スタンバイ構成）のシステムです。それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能します。どちらか一方の系に障害が発生すると，もう一方の系に切り替えられます。これによって，少ない台数のアプリケーションサーバマシンで，むだの少ない運用ができるようになります。このシステムは，Smart Composer機能を使用して構築します。この節では，相互系切り替えシステムの設定について説明します。

なお，相互系切り替えシステムの詳細については，「18.2　相互系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成」を参照してください。

18.4.1　相互系切り替えシステムの設定手順

ここでは，Windows Server Failover Clusterと連携する場合の，システムの構成例とシステムの設定手順について説明します。

(1)　システムの構成例

相互系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図18‒5　相互系切り替えシステムの構成例（Windowsの場合）

この例では，2種類のアプリケーションサーバ（アプリケーションサーバ1，アプリケーションサーバ2とします）を使用しています。アプリケーションサーバ1の実行系（現用系1）と待機系（予備系2），アプリケーションサーバ2の実行系（現用系2）と待機系（予備系1）をそれぞれ1:1で配置しています。それぞれ別の運用管理ドメインを持つManagement Serverを配置し，両方のマシンでManagement Serverを起動させています。

相互系切り替えシステムでは，一つの運用管理ドメイン内に二つの仮想ホストを定義し，それぞれを現用系アプリケーションサーバのホスト，予備系アプリケーションサーバのホストとして構築します。この例では，次のような組み合わせになります。

Node1の現用系1（仮想ホスト1）とNode2の予備系1（仮想ホスト1）

Node2の現用系2（仮想ホスト2）とNode1の予備系2（仮想ホスト2）

仮想ホストでは，一つの運用管理エージェントによってアプリケーションサーバの起動，停止を制御しますが，運用で使用するIPアドレスには異なるIPアドレスを割り当てて，見かけ上は異なるホストであるように定義しています。

アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。相互系切り替えシステムの場合，エイリアスIPアドレスは，クラスタソフトウェアによって動的に割り当てられるアドレス（クラスタIPアドレス）となります。アプリケーションサーバの運用に使用するIPアドレスには，クラスタIPアドレスを使用し，Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系に移動しないIPアドレス（ステーショナリIPアドレス）を使用します。

(2)　システムの設定手順

Windows Server Failover Clusterと連携する場合には，Management Serverやクラスタアドミニストレータの設定などが必要になります。相互系切り替えシステムの設定手順を次の図に示します。

図18‒6　相互系切り替えシステムの設定手順（Windowsの場合）

図中の1.〜6.について説明します。

共有ディスクにパーティションを作成して，ファイルシステムを構築します。

Windows Server Failover Clusterのクラスタ管理用ファイルの格納場所を作成します。また，グローバルトランザクションを使用する場合には，トランザクション情報の格納場所を作成します。なお，クラスタ管理用ファイルの格納場所とトランザクション情報の格納場所は，同じパーティションでもかまいません。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系1と予備系1，現用系2と予備系2で，同じドライブ文字を割り当ててください。

Management Serverでクラスタサーバの環境を設定します。

Management ServerのSmart Composer機能の簡易構築定義ファイルで，Windows Server Failover Clusterを使用する場合の設定をします。詳細は，「18.4.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

簡易構築定義ファイルでは設定できない，運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「18.4.3　設定ファイルの編集」を参照してください。

クラスタを設定します。

クラスタソフトウェアの環境設定やManagement Severと運用管理エージェントを監視するスクリプトファイルを作成します。詳細については，「18.4.4　クラスタの設定」を参照してください。

Management Serverとクラスタアドミニストレータで，アプリケーションサーバの設定をします。

Management Serverとクラスタアドミニストレータを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「18.4.5　アプリケーションサーバの設定」を参照してください。

18.4.2　クラスタサーバの環境設定

ここでは，Windows Server Failover Clusterと連携する場合の，Management Serverでの設定時の留意点について説明します。

参考

Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。Management Serverのセットアップについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.14　運用管理機能を構築する」を参照してください。

(1)　簡易構築定義ファイルでの設定

Management ServerのSmart Composer機能の簡易構築定義ファイルで，Webシステムおよびホストの定義をします。論理サーバを設置するホストおよび各論理サーバの構成を定義するときの留意点を次に示します。

Webシステムの定義

Smart Composer機能で用いるWebシステムの定義をします。仮想ホストごとに，異なるWebシステムを設定します。

ホストの定義

運用管理ドメイン内のホストを定義します。現用系および予備系の仮想ホストで，<host-name>タグにそれぞれのサーバの運用に使用するクラスタIPアドレスを設定します。例では，次のように設定します。

Node1の現用系1とNode2の予備系1の場合：192.168.1.111

Node2の現用系2とNode1の予備系2の場合：192.168.2.222

また，<agent-host>タグには，自ホストのステーショナリIPアドレスを設定します。例では，次のように設定します。

Node1の場合：192.168.0.11

Node2の場合：192.168.0.22

また，論理J2EEサーバ（j2ee-server），論理Webサーバ（web-server）の<configuration>タグの設定での留意点を次に示します。

(a)　論理J2EEサーバの設定

ホストの固定の設定

論理J2EEサーバ（j2ee-server）の<configuration>タグ内の次のパラメタに，任意の値を設定して，管理用ホストおよび運用用ホストを固定してください。

mngagent.connector.hostパラメタ※（運用管理エージェントのホスト名またはIPアドレス）

vbroker.se.iiop_tp.hostパラメタ（J2EEサーバ単位でEJBコンテナのホスト名またはIPアドレス）

webserver.connector.nio_http.bind_hostパラメタ（NIO HTTPサーバで使用するホスト名またはIPアドレス）

注※　mngagent.connector.hostパラメタとあわせて，mngagent.connector.portパラメタを指定する場合は，仮想ホストごとに異なるポート番号を指定してください。

グローバルトランザクションの設定

グローバルトランザクションを使用する場合は，論理J2EEサーバ（j2ee-server）の<configuration>タグ内の次のパラメタに，次の設定をしてください。

ejbserver.distributedtx.XATransaction.enabledパラメタ（ライトトランザクション機能の有効または無効の設定）に「false」を設定します。デフォルトでは「false」が設定されています。

ejbserver.distributedtx.ots.status.directory1パラメタ（インプロセスOTSのステータスファイルのバックアップの格納先）に，共有ディスク装置のディレクトリを設定します。デフォルトでは「otsstatus」が設定されています。

設定例

L:¥Group1¥otsstatus

(b)　論理Webサーバの設定

論理Webサーバ（web-server）の<configuration>タグ内に，次の設定が必要です。

ホストの固定の設定

Listenパラメタで，リクエストを受け付けるIPアドレスまたはホスト名を設定して，Webサーバのホストを固定してください。

18.4.3　設定ファイルの編集

設定ファイルを編集します。ここでは，Windows Server Failover Clusterと連携する場合に注意が必要な設定ファイルについて説明します。

(1)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）に設定する項目のうち，Windows Server Failover Clusterと連携する場合に留意する設定項目について説明します。なお，adminagent.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.1　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

adminagent.adapter.bind_hostキー

adminagent.adapter.bind_hostキーでステーショナリIPアドレス（例では，192.168.0.11，または192.168.0.22）を指定します。管理用のリクエストは，ステーショナリIPアドレスだけで受け付けます。

(2)　Management Serverの運用管理コマンド（mngsvrutil）の設定

<Application Serverのインストールディレクトリ>¥manager¥configディレクトリ下に，Management Serverの運用管理コマンド（mngsvrutil）のクライアント側共通定義ファイル（mngsvrutilcl.properties）を用意し，Management Serverの管理ユーザのユーザIDとパスワードを設定してください。また，クライアント側共通定義ファイルには適切なアクセス権限を設定してください。

このファイルは，運用管理エージェントを監視するスクリプト，および論理サーバを起動，停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

なお，mngsvrutilコマンドのクライアント側共通定義ファイル（mngsvrutilcl.properties）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.16　mngsvrutilcl.properties（mngsvrutilコマンドのクライアント側共通定義ファイル）」を参照してください。

(3)　Management Serverの設定

mserver.properties（Management Server環境設定ファイル）に設定する項目のうち，Windows Server Failover Clusterと連携する場合に留意する設定項目について説明します。なお，mserver.propertiesファイルについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit

論理サーバの稼働状況を示すステータスが異常停止状態（自動再起動回数を超えた状態，または自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系を切り替えるための設定をします。

設定例を次に示します。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit=true

注意事項

Management Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実行されません。このタイミングで系切り替えを実行する場合は，Management Serverに自動再起動を設定しないでください。

また，次の項目を必要に応じて設定してください。

webserver.connector.http.bind_host

webserver.connector.http.bind_hostキーに実IPアドレスを指定します。

mngsvr.myhost.name

mngsvr.myhost.nameキーに実IPアドレスを指定します。

com.cosminexus.mngsvr.management.host

com.cosminexus.mngsvr.management.hostキーに仮想IPアドレスを指定します。

18.4.4　クラスタの設定

クラスタに対して，次の設定を実施します。

スクリプトファイルの作成

クラスタソフトウェアの環境設定

(1)　スクリプトファイルの作成

監視対象を起動・停止するためのスクリプトファイルを作成します。また，スクリプトファイルでクラスタの監視方法を決めておく必要があります。スクリプトファイルの作成については，使用するOSのマニュアルを参照してください。

ここでは，相互系切り替えシステムの監視対象および監視方法について説明します

(a)　監視対象

相互系切り替えシステムの監視対象を次に示します。

Management Server

運用管理エージェント

Management Serverが終了したタイミング，または運用管理エージェントが終了したタイミングで系切り替えが実行されます。

(b)　監視方法

監視対象のプロセスの有無を監視します。監視するプロセスを次に示します。

表18‒3　監視するプロセス

監視対象

プロセス名

Management Server

mngsvr.exe

運用管理エージェント

adminagent.exe

(2)　Windows Server Failover Clusterの環境設定

Windows Server Failover Clusterの環境設定については，使用するクラスタソフトウェアのマニュアルを参照してください。

18.4.5　アプリケーションサーバの設定

アプリケーションサーバの設定では，Management Serverとクラスタアドミニストレータを使用してアプリケーションサーバをクラスタ構成に配置します。また，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポート，および開始します。アプリケーションサーバの設定手順を次に示します。

Node1およびNode2で，それぞれ運用管理エージェント，およびManagement Serverを起動します。

運用管理エージェント，およびManagement Serverの起動方法については，「2.6　システムの起動と停止の設定」を参照してください。

クラスタサービスを開始して，リソースグループGroupAとGroupBをそれぞれオンラインにします。

現用系のアプリケーションサーバ（Node1の現用系1とNode2の現用系2）が起動されて，予備系のアプリケーションサーバ（Node2の予備系1とNode1の予備系2）が待機状態になっている，通常の運用状態になります。

現用系のアプリケーションサーバ（Node1の現用系1とNode2の現用系2）に対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

J2EEアプリケーションの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」，リソースアダプタの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の次の個所を参照してください。

4.1.26　DB Connectorを設定する（CUI利用時）

4.1.27　DB Connector以外のリソースアダプタを設定する（CUI利用時）

4.1.28　リソースアダプタを開始する（CUI利用時）

また，サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

クラスタアドミニストレータで，リソースグループGroupBに対して「グループの移動」を実行して系を切り替え，Node1の予備系2のアプリケーションサーバを起動します。

Node1の予備系2のアプリケーションサーバに対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

Node1の予備系2には，Node2の現用系2と同じJ2EEアプリケーションとリソースアダプタをインポートします。

クラスタアドミニストレータで，リソースグループGroupBに対して「グループの移動」を実行して系を切り替え，Node2の現用系2のアプリケーションサーバを起動し，通常の運用状態に戻します。

リソースグループGroupAに対して「グループの移動」を実行して系を切り替え，Node2の予備系1のアプリケーションサーバを起動します。

Node2の予備系1のアプリケーションサーバに対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

Node2の予備系1には，Node1の現用系1と同じJ2EEアプリケーションとリソースアダプタをインポートします。

リソースグループGroupAに対して「グループの移動」を実行して系を切り替え，Node1の現用系1のアプリケーションサーバを起動し，通常の運用状態に戻します。

18.5　相互系切り替えシステムの設定（UNIXの場合）

相互系切り替えシステムは，アプリケーションサーバの実行系と待機系を1:1にする構成の一つで，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にする構成（相互スタンバイ構成）のシステムです。それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能します。どちらか一方の系に障害が発生すると，もう一方の系に切り替えられます。これによって，少ない台数のアプリケーションサーバマシンで，むだの少ない運用ができるようになります。このシステムは，Smart Composer機能を使用して構築します。この節では，相互系切り替えシステムの設定について説明します。

なお，相互系切り替えシステムの運用は，AIXまたはLinuxの場合だけ使用できます。

機能の詳細については，「18.2　相互系切り替えシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成」を参照してください。また，HAモニタについては，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

18.5.1　相互系切り替えシステムの設定手順

ここでは，システムの構成例とシステムの設定手順について説明します。

(1)　システムの構成例

相互系切り替えシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの設定例を示します。

図18‒7　相互系切り替えシステムの構成例（UNIXの場合）

この例では，2種類のアプリケーションサーバ（アプリケーションサーバ1，アプリケーションサーバ2とします）を使用しています。アプリケーションサーバ1の実行系（現用系1）と待機系（予備系2），アプリケーションサーバ2の実行系（現用系2）と待機系（予備系1）をそれぞれ1:1で配置しています。それぞれ別の運用管理ドメインを持つManagement Serverを配置し，両方のマシンでManagement Serverを起動させています。

相互系切り替えシステムでは，一つの運用管理ドメイン内に二つの仮想ホストを定義し，それぞれを現用系アプリケーションサーバのホスト，予備系アプリケーションサーバのホストとして構築します。この例では，次のような組み合わせになります。

Node1の現用系1（仮想ホスト1）とNode2の予備系1（仮想ホスト1）

Node2の現用系2（仮想ホスト2）とNode1の予備系2（仮想ホスト2）

仮想ホストでは，一つの運用管理エージェントによってアプリケーションサーバの起動，停止を制御しますが，運用で使用するIPアドレスには異なるIPアドレスを割り当てて，見かけ上は異なるホストであるように定義しています。

アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。相互系切り替えシステムの場合，エイリアスIPアドレスは，HAモニタによって動的に割り当てられるアドレスとなります。アプリケーションサーバの運用に使用するIPアドレスには，エイリアスIPアドレスを使用し，Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系に移動しないIPアドレス（ステーショナリIPアドレス）を使用します。

(2)　システムの設定手順

HAモニタと連携する場合には，Management ServerやHAモニタのファイルの設定などが必要になります。相互系切り替えシステムの設定手順を次の図に示します。

図18‒8　相互系切り替えシステムの設定手順（UNIXの場合）

図中の1.〜9.について説明します。

グローバルトランザクションを使用する場合は，共有ディスクにパーティションを作成して，ファイルシステムを構築します。

グローバルトランザクションを使用するためには，トランザクション情報の格納場所を作成します。

グローバルトランザクションを使用する場合は，システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系1と予備系1，現用系2と予備系2で，同じマウント先ディレクトリにしてください。

Management Serverでクラスタサーバの環境を設定します。

Management ServerのSmart Composer機能の簡易構築定義ファイルで，HAモニタを使用する場合の設定をします。詳細は，「18.5.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

簡易構築定義ファイルでは設定できない，運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「18.5.3　設定ファイルの編集」を参照してください。

HAモニタの環境を設定します。

HAモニタのsysdefファイルで，HAモニタの環境を定義します。詳細は，「18.5.4　HAモニタの環境設定」を参照してください。

シェルスクリプトファイルを作成します。

運用管理エージェントを監視，論理サーバを起動および停止するためのシェルスクリプトファイルを作成します。詳細は，「18.5.5　シェルスクリプトファイルの作成」を参照してください。

サーバ対応の環境を設定します。

HAモニタのserversファイルで，系で稼働させる現用系サーバや予備系サーバの環境を定義します。詳細は，「18.5.6　サーバ対応の環境設定」を参照してください。

LANの状態を設定します。

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。詳細は，「18.5.7　LANの状態設定」を参照してください。

Management ServerとHAモニタのコマンドで，アプリケーションサーバの設定をします。

Management ServerとHAモニタのコマンドを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「18.5.8　アプリケーションサーバの設定」を参照してください。

18.5.2　クラスタサーバの環境設定

ここでは，HAモニタと連携する場合の，Management Serverでの設定時の留意点について説明します。

参考

Management Serverを初めて使用するホストでは，Management Serverをセットアップする必要があります。Management Serverのセットアップについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.14　運用管理機能を構築する」を参照してください。

(1)　簡易構築定義ファイルでの設定

Management ServerのSmart Composer機能の簡易構築定義ファイルで，Webシステムおよびホストの定義をします。論理サーバを設置するホストおよび各論理サーバの構成を定義するときの留意点を次に示します。

Webシステムの定義

Smart Composer機能で用いるWebシステムの定義をします。仮想ホストごとに，異なるWebシステムを設定します。

ホストの定義

運用管理ドメイン内のホストを定義します。現用系および予備系の仮想ホストで，<host-name>タグにそれぞれのサーバの運用に使用するエイリアスIPアドレスを設定します。例では，次のように設定します。

Node1の現用系1とNode2の予備系1の場合：192.168.1.111

Node2の現用系2とNode1の予備系2の場合：192.168.2.222

また，<agent-host>タグには，自ホストのステーショナリIPアドレスを設定します。例では，次のように設定します。

Node1の場合：192.168.0.11

Node2の場合：192.168.0.22

また，論理J2EEサーバ（j2ee-server），論理Webサーバ（web-server）の<configuration>タグの設定での留意点を次に示します。

(a)　論理J2EEサーバの設定

ホストの固定の設定

論理J2EEサーバ（j2ee-server）の<configuration>タグ内の次のパラメタに，任意の値を設定して，管理用ホストおよび運用用ホストを固定してください。

mngagent.connector.hostパラメタ※（運用管理エージェントのホスト名またはIPアドレス）

vbroker.se.iiop_tp.hostパラメタ（J2EEサーバ単位でEJBコンテナのホスト名またはIPアドレス）

webserver.connector.nio_http.bind_hostパラメタ（NIO HTTPサーバで使用するホスト名またはIPアドレス）

注※　mngagent.connector.hostパラメタとあわせて，mngagent.connector.portパラメタを指定する場合は，仮想ホストごとに異なるポート番号を指定してください。

グローバルトランザクションの設定

グローバルトランザクションを使用する場合は，論理J2EEサーバ（j2ee-server）の<configuration>タグ内の次のパラメタに，次の設定をしてください。

ejbserver.distributedtx.XATransaction.enabledパラメタ（ライトトランザクション機能の有効または無効の設定）に「true」を設定します。デフォルトでは「false」が設定されています。

ejbserver.distributedtx.ots.status.directory1パラメタ（インプロセスOTSのステータスファイルのバックアップの格納先）に，共有ディスク装置のディレクトリを設定します。デフォルトでは「otsstatus」が設定されています。

設定例

/hamon

(b)　論理Webサーバの設定

論理Webサーバ（web-server）の<configuration>タグ内に，次の設定が必要です。

ホストの固定の設定

Listenパラメタで，リクエストを受け付けるIPアドレスまたはホスト名を設定して，Webサーバのホストを固定してください。

18.5.3　設定ファイルの編集

設定ファイルを編集します。ここでは，HAモニタと連携する場合に注意が必要な設定ファイルについて説明します。

(1)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）に設定する項目のうち，HAモニタと連携する場合に留意する設定項目について説明します。なお，adminagent.propertiesについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.1　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

adminagent.adapter.bind_hostキー

adminagent.adapter.bind_hostキーでステーショナリIPアドレス（例では，192.168.0.11，または192.168.0.22）を指定します。管理用のリクエストは，ステーショナリIPアドレスだけで受け付けます。

(2)　Management Serverの運用管理コマンド（mngsvrutil）の設定

/opt/Cosminexus/manager/configディレクトリ下に，Management Serverの運用管理コマンド（mngsvrutil）のクライアント側共通定義ファイル（mngsvrutilcl.properties）を用意し，Management Serverの管理ユーザのユーザIDとパスワードを設定してください。また，クライアント側共通定義ファイルには適切なアクセス権限を設定してください。

このファイルは，運用管理エージェントのプロセスを監視するスクリプト，論理サーバを起動および停止するスクリプトで，mngsvrutilコマンドを実行する際に使用します。

なお，mngsvrutilコマンドのクライアント側共通定義ファイル（mngsvrutilcl.properties）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.16　mngsvrutilcl.properties（mngsvrutilコマンドのクライアント側共通定義ファイル）」を参照してください。

(3)　Management Serverの設定

mserver.properties（Management Server環境設定ファイル）に設定する項目のうち，HAモニタと連携する場合に留意する設定項目について説明します。なお，mserver.propertiesファイルについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「8.2.6　mserver.properties（Management Server環境設定ファイル）」を参照してください。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit

論理サーバの稼働状況を示すステータスが異常停止状態（自動再起動回数を超えた状態，または自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系を切り替えるための設定をします。

設定例を次に示します。

com.cosminexus.mngsvr.logical_server_abnormal_stop.exit=true

注意事項

Management Serverに自動再起動を設定している場合，このタイミングでは系切り替えが実行されません。このタイミングで系切り替えを実行する場合は，Management Serverに自動再起動を設定しないでください。

また，次の項目を必要に応じて設定してください。

webserver.connector.http.bind_host

webserver.connector.http.bind_hostキーに実IPアドレスを指定します。

mngsvr.myhost.name

mngsvr.myhost.nameキーに実IPアドレスを指定します。

com.cosminexus.mngsvr.management.host

com.cosminexus.mngsvr.management.hostキーに仮想IPアドレスを指定します。

18.5.4　HAモニタの環境設定

使用しているシステムに従って，sysdefという定義ファイルにHAモニタの環境を定義してください。

HAモニタの環境設定については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

18.5.5　シェルスクリプトファイルの作成

運用管理エージェントのプロセスを監視し，論理サーバを起動および停止するために，次のシェルスクリプトファイルを作成します。

運用管理エージェントのプロセスを監視するシェルスクリプトファイル

論理サーバを起動するシェルスクリプトファイル

論理サーバを停止するシェルスクリプトファイル

なお，論理サーバの稼働状況を示すステータスが異常停止状態（自動再起動回数を超えた状態，または自動再起動回数の設定が0の場合で障害を検知した状態）になったタイミングで系を切り替えるための設定のとき，シェルスクリプトファイルにManagement Serverの監視処理を追加してください。

(1)　運用管理エージェントのプロセスを監視するシェルスクリプトファイル

運用管理エージェントのプロセスを監視するシェルスクリプトファイルの例（manager_adminagent_monitor.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
AA=/opt/Cosminexus/manager/bin/adminagent
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

logg "### $0: started. ###"
while true
do
    $MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t 192.168.1.111 check adminAgent
    if [ $? -ne 0 ]
    then
        logg "### $0: stop. ###"
        exit 0
    fi
    sleep 10
done

このシェルスクリプトファイルでは，mngsvrutilのcheckコマンドで運用管理エージェントの稼働状況を確認します。mngsvrutilコマンドの-mオプションの引数のホスト名には自ホストのステーショナリIPアドレスを指定し，-tオプションの引数には現用系の仮想ホストのエイリアスIPアドレスを指定します。

なお，このシェルスクリプトファイルは，Node1の現用系1（予備系2）で稼働する運用管理エージェントを監視する場合の例です。Node2の予備系1（現用系2）で使用する場合には，-mオプションの引数のホスト名をNode2のステーショナリIPアドレス（192.168.0.22）に，-tオプションの引数を現用系の仮想ホストのエイリアスIPアドレス（192.168.2.222）に置き換えます。

(2)　論理サーバを起動するシェルスクリプトファイル

論理サーバを起動するシェルスクリプトファイルの例（manager_apserver1_start.sh）を次に示します。

#!/bin/sh

MNGDIR=/opt/Cosminexus/manager
logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}
# start logical server
logg "### $0: starting logical servers. ###"
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <パフォーマンストレーサ> -s start server
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <J2EEサーバ1> -s start server
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <Webサーバ1> -s start server
exit 0

このシェルスクリプトファイルでは，論理サーバを起動します。mngsvrutilコマンドの-mオプションの引数のホスト名には自ホストのステーショナリIPアドレスを指定し，-tオプションの引数には起動する論理サーバ名を指定します。

なお，このシェルスクリプトファイルは，Node1の現用系1で論理サーバを起動する場合の例です。

(3)　論理サーバを停止するシェルスクリプトファイル

論理サーバを停止するシェルスクリプトファイルの例（manager_apserver1_stop.sh）を次に示します。

#!/bin/sh

MNGDIR=/opt/Cosminexus/manager
logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}
# stop logical server
logg "### $0: stop logical servers. ###"
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <Webサーバ1> -s stop server graceful:300
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <J2EEサーバ1> -s stop server
$MNGDIR/bin/mngsvrutil -m 192.168.0.11:28080 -t <パフォーマンストレーサ> -s stop server

このシェルスクリプトファイルでは，論理サーバを停止します。mngsvrutilコマンドの-mオプションの引数のホスト名には自ホストのステーショナリIPアドレスを指定し，-tオプションの引数には停止する論理サーバ名を指定します。

なお，このシェルスクリプトファイルは，Node1の現用系1で論理サーバを停止する場合の例です。

18.5.6　サーバ対応の環境設定

HAモニタでのサーバ対応の環境設定では，系で稼働させる実行サーバや待機サーバの環境を定義します。

serversという定義ファイルに，相互系切り替えシステム用のサーバ対応の環境を定義してください。サーバ対応の環境設定での設定内容を次の表に示します。

表18‒4　サーバ対応の環境設定での設定内容（相互系切り替えシステムの場合）

オペランド

設定内容

name

論理サーバを起動するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_apserver1_start.sh

alias

サーバの識別名を指定します。対応する現用系と予備系で同じ名称を指定します。

指定例：AP1（現用系1と予備系1の場合），AP2（現用系2と予備系2の場合）

acttype

サーバの起動方法を指定します。ここでは，HAモニタのコマンドでサーバを起動するため，「monitor」を指定します。

termcommand

論理サーバを停止するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_apserver1_stop.sh

initial

サーバ起動時の状態を指定します。

現用系の場合

「online」を指定します。

予備系の場合

「standby」を指定します。

disk

共有ディスク装置のキャラクタ型スペシャルファイル名を指定します。

指定例：/dev/vg00（現用系1と予備系1の場合），/dev/vg01（現用系2と予備系2の場合）

lan_updown

LANの状態設定ファイルを使用するかどうかを指定します。ここでは，LANの状態設定ファイルを使用するため，「use」を指定します。

fs_name

切り替えるファイルシステムに対応する論理ボリュームの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/dev/rdisk0

fs_mount_dir

切り替えるファイルシステムのマウント先ディレクトリの絶対パス名を指定します。なお，この設定は，$TPFSをUNIXファイルで使用する場合だけ必要です。

指定例：/hamon

patrolcommand

運用管理エージェントのプロセスを監視するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/manager_adminagent_monitor.sh

servexec_retry

障害を検出した場合の再起動の回数を指定します。ここでは，障害が発生した場合に再起動しないで系を切り替えるため，「0」を指定します。

waitserv_exec

論理サーバの起動完了処理を実行するときに起動コマンドの実行完了を待つかどうかを指定します。ここでは，実行完了を待つため，「yes」を指定します。

serversファイルの例を次に示します。

serversファイルの例（Node1の現用系1（予備系2）の場合）

Node1の現用系1（予備系2）の場合のserversファイルの例を次に示します。

server  name           /home/manager/hamon/bin/manager_apserver1_start.sh,
        alias          AP1,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_apserver1_stop.sh,
        initial        online,
        disk           /dev/vg00,
        lan_updown     use,
        fs_name        /dev/rdisk0,
        fs_mount_dir   /hamon,
        patrolcommand  /home/manager/hamon/bin/manager_adminagent_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

server  name           /home/manager/hamon/bin/manager_apserver2_start.sh,
        alias          AP2,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_apserver2_stop.sh,
        initial        standby,
        disk           /dev/vg01,
        lan_updown     use,
        fs_name        /dev/rdisk1,
        fs_mount_dir   /hamon1,
        patrolcommand  /home/manager/hamon/bin/manager_adminagent_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

serversファイルの例（Node2の予備系1（現用系2）の場合）

Node2の予備系1（現用系2）の場合のserversファイルの例を次に示します。

server  name           /home/manager/hamon/bin/manager_apserver1_start.sh,
        alias          AP1,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_apserver1_stop.sh,
        initial        standby,
        disk           /dev/vg00,
        lan_updown     use,
        fs_name        /dev/rdisk0,
        fs_mount_dir   /hamon,
        patrolcommand  /home/manager/hamon/bin/manager_adminagent_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

server  name           /home/manager/hamon/bin/manager_apserver2_start.sh,
        alias          AP2,
        acttype        monitor,
        termcommand    /home/manager/hamon/bin/manager_apserver2_stop.sh,
        initial        online,
        disk           /dev/vg01,
        lan_updown     use,
        fs_name        /dev/rdisk1,
        fs_mount_dir   /hamon1,
        patrolcommand  /home/manager/hamon/bin/manager_adminagent_monitor.sh,
        servexec_retry 0,
        waitserv_exec  yes;

この設定例では，インプロセストランザクションサービスのステータスファイル格納先に，共有ディスク上のディレクトリを指定しています。なお，インプロセストランザクションサービスのステータスファイル格納先は，Management ServerのSmart Composer機能の簡易構築定義ファイルで，論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.distributedtx.ots.status.directory1パラメタで指定します。

18.5.7　LANの状態設定

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。

次のファイルにエイリアスIPアドレスを設定してください。

<サーバ識別名>.upファイル

LANを接続する場合に使用します。LANアダプタに追加するエイリアスIPアドレスを指定します。

<サーバ識別名>.downファイル

LANを切り離す場合に使用します。LANアダプタから削除するエイリアスIPアドレスを指定します。

<サーバ識別名>には，サーバ対応の環境設定（serversファイル）のaliasの値を指定してください。

LANの状態設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

18.5.8　アプリケーションサーバの設定

アプリケーションサーバの設定では，Management ServerとHAモニタのコマンドを使用してアプリケーションサーバをクラスタ構成に配置します。また，論理サーバをセットアップして設定情報を配布し，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポート，および開始します。アプリケーションサーバの設定手順を次に示します。

Node1およびNode2で，それぞれ運用管理エージェント，およびManagement Serverを起動します。

運用管理エージェント，およびManagement Serverの起動方法については，「2.6　システムの起動と停止の設定」を参照してください。

Node1およびNode2でHAモニタのmonbeginコマンドを実行して，現用系のアプリケーションサーバを実行系として起動し，予備系のアプリケーションサーバを待機状態にします。

Node1でのコマンドの実行例

「# monbegin AP1」を実行して，Node1の現用系1を起動します。

「# monbegin AP2」を実行して，Node1の予備系2を待機状態にします。

Node2でのコマンドの実行例

「# monbegin AP1」を実行して，Node2の予備系1を待機状態にします。

「# monbegin AP2」を実行して，Node2の現用系2を起動します。

現用系のアプリケーションサーバ（Node1の現用系1とNode2の現用系2）が起動されて，予備系のアプリケーションサーバ（Node2の予備系1とNode1の予備系2）が待機状態になっている，通常の運用状態になります。

現用系のアプリケーションサーバ（Node1の現用系1とNode2の現用系2）に対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして，起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

J2EEアプリケーションの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」，リソースアダプタの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の次の個所を参照してください。

4.1.26　DB Connectorを設定する（CUI利用時）

4.1.27　DB Connector以外のリソースアダプタを設定する（CUI利用時）

4.1.28　リソースアダプタを開始する（CUI利用時）

また，サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

Node2でHAモニタのmonswapコマンドを実行して，系を切り替えます。

Node2でのコマンドの実行例

「# monswap AP2」を実行して，サーバ識別名「AP2」で系を切り替えます。Node1の予備系2が起動され，Node2の現用系2が待機状態になります。

Node1の予備系2のアプリケーションサーバに対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

Node1の予備系2には，Node2の現用系2と同じJ2EEアプリケーションとリソースアダプタをインポートします。

Node1でHAモニタのmonswapコマンドを実行して，系を切り替えて通常の運用状態に戻します。

Node1でのコマンドの実行例

「# monswap AP2」を実行して，サーバ識別名「AP2」で系を切り替えます。Node2の現用系2が起動され，Node1の予備系2が待機状態になります。

Node1でHAモニタのmonswapコマンドを実行して，系を切り替えます。

Node1でのコマンドの実行例

「# monswap AP1」を実行して，サーバ識別名「AP1」で系を切り替えます。Node2の予備1が起動され，Node1の現用系1が待機状態になります。

Node2の予備系1のアプリケーションサーバに対して，Management ServerのSmart Composer機能のコマンドで，設定済みの簡易構築定義ファイルを基に，Webシステムをセットアップして起動します。また，サーバ管理コマンドを使用して，J2EEアプリケーションとリソースアダプタをインポートして，インポートしたJ2EEアプリケーションとリソースアダプタを開始します。

Node2の予備系1には，Node1の現用系1と同じJ2EEアプリケーションとリソースアダプタをインポートします。

Node2でHAモニタのmonswapコマンドを実行して，系を切り替えて通常の運用状態に戻します。

Node2でのコマンドの実行例

「# monswap AP1」を実行して，サーバ識別名「AP1」で系を切り替えます。Node1の現用系1が起動され，Node2の予備1が待機状態になります。

18.6　相互系切り替えシステムの起動と停止（Windowsの場合）

この節では，相互系切り替えシステムを利用する場合の，システムの起動と停止方法について説明します。

相互系切り替えシステムは，アプリケーションサーバの実行系と待機系を1:1にする構成の一つです。それぞれのアプリケーションサーバを実行系として稼働させながら，同時にお互いの待機系として構成します。実行系と待機系の詳細については，「15.2　クラスタソフトウェアと連携して実現できる運用」を参照してください。

ここでは，それぞれのアプリケーションサーバを，アプリケーションサーバ1，アプリケーションサーバ2として，アプリケーションサーバ1には，J2EEサーバAの実行系とJ2EEサーバBの待機系を，アプリケーションサーバBにはJ2EEサーバAの待機系とJ2EEサーバBの実行系を配置する構成を例にして説明します。例にする構成を次の図に示します。この例では，J2EEサーバAの実行系とJ2EEサーバAの待機系をリソースグループA，J2EEサーバBの実行系とJ2EEサーバBの待機系をリソースグループBと設定しています。

図18‒9　相互スタンバイシステムの構成例

注意事項

Management Serverまたは運用管理エージェントのダウンによって系切り替えが発生した場合，ダウンしたホストには各論理サーバのプロセスが残っている場合があります。プロセスが残っていると系の切り戻しが発生した時に論理サーバの起動ができなくなってしまうため，系の切り戻しが発生する前にすべてのプロセスを停止させる必要があります。また，そのほかに，業務が正しく開始されるための作業はあらかじめ実施しておいてください。

18.6.1　相互系切り替えシステムの起動

ここでは，相互系切り替えシステムを利用する場合のシステムの起動手順について説明します。

相互系切り替えシステムを起動するには，あらかじめManagement Server，および運用管理エージェントを起動しておくことが必要です。Management Server，および運用管理エージェントを起動していない場合には，これらを先に起動しておいてください。

相互系切り替えシステムの起動手順を次に示します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）でアプリケーションサーバ1のノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

アプリケーションサーバ1のノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）でアプリケーションサーバ2のノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

アプリケーションサーバ2のノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）でリソースグループAを選択して，［ファイル］メニューの［オンラインにする］を選択します。

実行系（アプリケーションサーバＡ）がオンラインになります。

コンソールツリー（左ペイン）でリソースグループBを選択して，［ファイル］メニューの［オンラインにする］を選択します。

実行系（アプリケーションサーバＢ）がオンラインになります。

18.6.2　相互系切り替えシステムの停止

ここでは，相互系切り替えシステムの停止方法について説明します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）でリソースグループＢを選択して，［ファイル］メニューの［オフラインにする］を選択します。

リソースグループＢがオフラインになります。

コンソールツリー（左ペイン）でリソースグループＡを選択して，［ファイル］メニューの［オフラインにする］を選択します。

リソースグループＡがオフラインになります。

コンソールツリー（左ペイン）でアプリケーションサーバ2のノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

アプリケーションサーバ2のノードのクラスタサービスが停止します。

コンソールツリー（左ペイン）でアプリケーションサーバ1のノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

アプリケーションサーバ1のノードのクラスタサービスが停止します。

なお，Management Server，および運用管理エージェントは最後に手動で停止します。これらの停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

18.6.3　相互系切り替えシステムで計画的に系を切り替える場合の起動と停止

トラブル発生時以外で，相互系切り替えシステムの実行系と待機系を切り替える手順を次に示します。系を切り替えるときは，待機系のホストでアプリケーションサーバが待機状態になっている必要があります。

ここでは，J2EEサーバAの系を切り替える場合について説明します。J2EEサーバBの場合も同じ手順で系を切り替えることができます。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）でリソースグループAを選択して，［ファイル］メニューの［グループの移動］を選択します。

系が切り替わります。

18.7　相互系切り替えシステムの起動と停止（UNIXの場合）

この節では，HAモニタによる相互系切り替えシステムを利用する場合の，システムの起動と停止の手順について説明します。稼働開始後にJ2EEサーバ，およびバッチサーバをメンテナンスする場合の起動と停止の手順についても説明します。なお，HAモニタが利用できるのは，AIXまたはLinuxの場合だけです。

相互系切り替えシステムを利用して運用する場合は，あらかじめ現用系と予備系の2種類のホストの用意や，HAモニタの監視の対象となる運用管理エージェントを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「18.5.4　HAモニタの環境設定」のHAモニタの設定に関する説明を参照してください。

相互系切り替えシステムのシステム構成例を次の図に示します。この節では，このシステム構成例を基に，相互系切り替えシステムの起動および停止の手順について説明します。

図18‒10　相互系切り替えシステムのシステム構成例

図中の各アプリケーションサーバでのserversファイルの定義（HAモニタでのサーバの環境設定）のうち，起動・停止に関連する定義項目を次の表に示します。

表18‒5　アプリケーションサーバ1のserversファイルの定義

オペランド

説明

指定値

現用系1

（仮想ホスト1）

予備系2

（仮想ホスト2）

alias

サーバの識別名

AP1

AP2

initial

HAモニタでのサーバの起動方法

online

standby

表18‒6　アプリケーションサーバ2のserversファイルの定義

オペランド

説明

指定値

予備系1

（仮想ホスト1）

現用系2

（仮想ホスト2）

alias

サーバの識別名

AP1

AP2

initial

HAモニタでのサーバの起動方法

standby

online

なお，serversファイルの定義の詳細については，「18.5.6　サーバ対応の環境設定」を参照してください。

また，次のコマンドは，HAモニタが提供しているコマンドです。詳細は，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

monbegin（HAモニタとのインタフェースを持たないサーバを起動）

monend（HAモニタとのインタフェースを持たない実行サーバの停止連絡）

monsbystp（待機サーバの停止）

monswap（計画系切り替え）

注意事項

Management Serverまたは運用管理エージェントのダウンによって系切り替えが発生した場合，ダウンしたホストには各論理サーバのプロセスが残っている場合があります。プロセスが残っていると系の切り戻しが発生した時に論理サーバの起動ができなくなってしまうため，系の切り戻しが発生する前にすべてのプロセスを停止させる必要があります。また，そのほかに，業務が正しく開始されるための作業はあらかじめ実施しておいてください。

18.7.1　相互系切り替えシステムの起動

相互系切り替えシステムを利用する場合のシステム起動時の留意事項，およびシステムの起動手順について説明します。

(1)　システム起動時の留意事項

相互系切り替えシステムを利用する場合のシステム起動時の留意事項を次に示します。

アプリケーションサーバ1とアプリケーションサーバ2のホストに配置されたHAモニタは，OSの起動と同時に起動されています。

アプリケーションサーバ1およびアプリケーションサーバ2の各ホストで仮想ホストを起動する前に，Management Serverをあらかじめ起動しておいてください。

(2)　システムの起動手順

相互系切り替えシステムの起動の流れを次の図に示します。

アプリケーションサーバ1およびアプリケーションサーバ2の各ホストで次の図に示す流れでシステムを起動してください。

図18‒11　相互系切り替えシステムの起動の流れ

参考

アプリケーションサーバ1およびアプリケーションサーバ2の各ホストでの仮想ホストの起動順序は任意です。現用系仮想ホストまたは予備系仮想ホストのどちらから起動してもかまいません。なお，このマニュアルでは，仮想ホスト1，仮想ホスト2の順序で起動する場合の手順について説明します。

図中のManagement Serverの起動の手順1.〜手順2.については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.1　システムの起動手順」を参照してください。

なお，自動起動の設定をしている場合，ホストの起動時に，運用管理エージェント，Management Serverも起動されるため，手順1.〜手順2.は省略できます。システムの起動方法の設定については，「2.6　システムの起動と停止の設定」を参照してください。

ここでは，図中の仮想ホストの起動手順について説明します。アプリケーションサーバ1およびアプリケーションサーバ2の各ホストでの起動手順を次に示します。

アプリケーションサーバ1での起動手順

現用系1（仮想ホスト1）の起動

monbeginコマンドを実行して，現用系1（仮想ホスト1）を実行系として起動します。

# monbegin AP1

これによって，現用系の仮想ホストを起動するスクリプトファイルに定義されている処理が実行されて，現用系の仮想ホストが実行系として起動されます。

予備系2（仮想ホスト2）の起動

monbeginコマンドを実行して，予備系2（仮想ホスト2）を待機系として起動します。

# monbegin AP2

これによって，予備系の仮想ホストが待機系となり，実行系の障害に備えます。

アプリケーションサーバ2での起動手順

予備系1（仮想ホスト1）の起動

monbeginコマンドを実行して，予備系1（仮想ホスト1）を待機系として起動します。

# monbegin AP1

これによって，予備系の仮想ホストが待機系となり，実行系の障害に備えます。

現用系2（仮想ホスト2）の起動

monbeginコマンドを実行して，現用系2（仮想ホスト2）を実行系として起動します。

# monbegin AP2

これによって，現用系の仮想ホストを起動するスクリプトファイルに定義されている処理が実行されて，現用系の仮想ホストが実行系として起動されます。

18.7.2　相互系切り替えシステムの停止

相互系切り替えシステムの停止手順について説明します。

ここでは，次の二つの場合の停止手順について説明します。

実行系と待機系の両方の仮想ホストを停止する場合

待機系の仮想ホストだけ停止する場合

(1)　実行系と待機系の両方の仮想ホストを停止する場合

実行系と待機系の両方の仮想ホストを停止する場合の手順について説明します。

実行系と待機系の両方の仮想ホストを停止する場合の，相互系切り替えシステムの停止の流れを次の図に示します。

図18‒12　相互系切り替えシステムの停止の流れ

参考

仮想ホスト1および仮想ホスト2の停止順序は任意です。このマニュアルでは，仮想ホスト1，仮想ホスト2の順序で停止する場合の手順について説明します。

すべての仮想ホストを停止したあと，アプリケーションサーバ1およびアプリケーションサーバ2の各ホストのManagement Serverを停止します。

図中のManagement Serverの停止の手順1.〜手順2.については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.3　システムの停止手順」を参照してください。

なお，自動停止の設定をしている場合，ホストの停止時に，Management Server，および運用管理エージェントも停止されるため，手順1.〜手順2.は省略できます。システムの停止方法の設定については，「2.6　システムの起動と停止の設定」を参照してください。

ここでは，図中の仮想ホストの停止手順について説明します。アプリケーションサーバ1およびアプリケーションサーバ2の各ホストでの停止手順を次に示します。

アプリケーションサーバ1での停止手順

アプリケーションサーバ1でmonendコマンドを実行して，実行系の仮想ホスト1を停止します。

# monend AP1

これによって，アプリケーションサーバ1の実行系1（仮想ホスト1）が停止します。また，HAモニタによって待機系に自動的に停止指示が出され，アプリケーションサーバ2の待機系1（仮想ホスト1）も停止します。

アプリケーションサーバ2での停止手順

アプリケーションサーバ2でmonendコマンドを実行して，実行系の仮想ホスト2を停止します。

# monend AP2

これによって，アプリケーションサーバ2の実行系2（仮想ホスト2）が停止します。また，HAモニタによって待機系に自動的に停止指示が出され，アプリケーションサーバ1の待機系2（仮想ホスト2）も停止します。

(2)　待機系の仮想ホストだけ停止する場合

実行系の仮想ホストを停止しないで待機系の仮想ホストで待機状態をやめる場合の手順について説明します。

アプリケーションサーバ1の待機系2（仮想ホスト2）で待機状態をやめる場合

アプリケーションサーバ1のホストで次のコマンドを実行します。

# monsbystp AP2

アプリケーションサーバ2の待機系1（仮想ホスト1）で待機状態をやめる場合

アプリケーションサーバ2のホストで次のコマンドを実行します。

# monsbystp AP1

18.7.3　相互系切り替えシステムで計画的に系を切り替える場合の起動と停止

相互系切り替えシステムでトラブル発生時以外の場合に，実行系と待機系を計画的に切り替えるときの手順について説明します。系を切り替えるときには，待機系の仮想ホストが待機状態になっている必要があります。

ここでは，仮想ホスト1および仮想ホスト2の実行系と待機系を計画的に切り替える場合の手順について説明します。なお，現用系のホストが実行系として起動されていることを前提にして説明します。

参考

相互系切り替えシステムをメンテナンスする場合の起動と停止の手順については，「18.7.4　相互系切り替えシステムをメンテナンスする場合の起動と停止」を参照してください。

(1)　仮想ホスト1を計画的に系切り替えする場合

仮想ホスト1を計画的に系切り替えする場合の手順を次に示します。

アプリケーションサーバ1でmonswapコマンドを実行して，系を切り替えます。

# monswap AP1

これによって，次の図に示すように，アプリケーションサーバ1の実行系1（仮想ホスト1）が待機系の仮想ホストに切り替わり，アプリケーションサーバ2の待機系1（仮想ホスト1）が実行系の仮想ホストに切り替わります。

通常運用の実行系と待機系の状態に戻す場合，アプリケーションサーバ2でmonswapコマンドを実行して，系を切り替えます。

# monswap AP1

これによって，次の図に示すように，アプリケーションサーバ2の実行系1（仮想ホスト1）が待機系の仮想ホストに切り替わり，アプリケーションサーバ1の待機系1（仮想ホスト1）が実行系の仮想ホストに切り替わります。これで，通常運用の実行系と待機系の状態に戻ります。

(2)　仮想ホスト2を計画的に系切り替えする場合

仮想ホスト2を計画的に系切り替えする場合の手順を次に示します。

アプリケーションサーバ2でmonswapコマンドを実行して，系を切り替えます。

# monswap AP2

これによって，次の図に示すように，アプリケーションサーバ2の実行系2（仮想ホスト2）が待機系の仮想ホストに切り替わり，アプリケーションサーバ1の待機系2（仮想ホスト2）が実行系の仮想ホストに切り替わります。

通常運用の実行系と待機系の状態に戻す場合，アプリケーションサーバ1でmonswapコマンドを実行して，系を切り替えます。

# monswap AP2

これによって，次の図に示すように，アプリケーションサーバ1の実行系2（仮想ホスト2）が待機系の仮想ホストに切り替わり，アプリケーションサーバ2の待機系2（仮想ホスト2）が実行系の仮想ホストに切り替わります。これで，通常運用の実行系と待機系の状態に戻ります。

18.7.4　相互系切り替えシステムをメンテナンスする場合の起動と停止

相互系切り替えシステムをメンテナンスする場合の，起動と停止の手順を次に示します。

ここでは，次の三つの場合の停止手順について説明します。

再起動が不要なメンテナンスの場合

再起動が必要なメンテナンスの場合（両方の系を同時に停止する方法）

再起動が必要なメンテナンスの場合（両方の系を同時に停止しない方法）

なお，これらの手順は，すでに実行系の仮想ホストが両方とも起動している場合の手順です。

(1)　再起動が不要なメンテナンスの場合

再起動が不要なメンテナンスの場合の起動と停止の手順を次に示します。

実行系の仮想ホスト（現用系の仮想ホスト）で，動作中のJ2EEアプリケーションとリソースアダプタを停止します。

バッチサーバの場合は，バッチアプリケーションが実行中でないことを確認してからリソースアダプタを停止してください。

停止方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.4　システムの停止方法」を参照してください。

サーバ管理コマンドを使用してメンテナンス処理を実行します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

手順1.で停止したJ2EEアプリケーションとリソースアダプタを開始します。

J2EEサーバの場合はJ2EEアプリケーションとリソースアダプタを開始します。また，バッチサーバの場合はリソースアダプタを開始します。

開始方法については，次のマニュアルを参照してください。

J2EEアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

バッチアプリケーションを実行するシステムの場合

マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1.2　システムの起動方法」を参照してください。

必要に応じてJ2EEアプリケーションとリソースアダプタの動作確認をします。

実行系の仮想ホスト（現用系の仮想ホスト）に対して，monswapコマンドを実行して，系を切り替えます。

# monswap サーバの識別名

下線部分には，実行系の仮想ホストが配置されているアプリケーションサーバの，serversファイルのオペランド「alias」に指定されている実行系の仮想ホストのサーバの識別名を指定します。

実行系の仮想ホスト（現用系の仮想ホスト）が待機系の仮想ホストに切り替わり，待機系だった仮想ホスト（予備系の仮想ホスト）が実行系の仮想ホストになります。

切り替え後の実行系の仮想ホスト（予備系の仮想ホスト）で手順1.〜手順4.を実行します。

切り替え後の実行系のホスト（予備系の仮想ホスト）で，必要に応じて，再度monswapコマンドを実行します。

# monswap サーバの識別名

下線部分には，手順5.でmonswapコマンドの引数に指定したサーバの識別名と同じサーバの識別名を指定します。

現用系の仮想ホストを実行系に戻す場合に実行してください。

これで，メンテナンス時の起動と停止の手順は完了です。

(2)　再起動が必要なメンテナンスの場合（両方の系を同時に停止する方法）

再起動が必要なメンテナンスの場合の起動と停止の手順を次に示します。

実行系の仮想ホストに対してmonendコマンドを実行して，システムを停止します。

# monend サーバの識別名

下線部分には，実行系の仮想ホストが配置されているアプリケーションサーバの，serversファイルのオペランド「alias」に指定されている実行系の仮想ホストのサーバの識別名を指定します。

実行系の仮想ホストが停止します。また，HAモニタによって待機系に自動的に停止指示が出され，待機系の仮想ホストも停止します。

現用系と予備系の両方の仮想ホストに対して，定義ファイルの変更など，メンテナンス作業を実行します。

現用系の仮想ホストに対して，monbeginコマンドを実行します。

# monbegin サーバの識別名

下線部分には，手順1.でmonendコマンドの引数に指定したサーバの識別名と同じサーバの識別名を指定します。

これによって，現用系の仮想ホストが，実行系として起動します。

予備系の仮想ホストに対して，monbeginコマンドを実行します。

# monbegin サーバの識別名

下線部分には，手順1.でmonendコマンドの引数に指定したサーバの識別名と同じサーバの識別名を指定します。

これによって，予備系の仮想ホストが，待機系として起動します。

実行系の仮想ホストで，必要に応じて，定義の変更に関連した動作確認を実行します。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「18.5.6　サーバ対応の環境設定」を参照してください。

(3)　再起動が必要なメンテナンスの場合（両方の系を同時に停止しない方法）

再起動が必要なメンテナンスの場合の起動と停止の手順を次に示します。

待機系の仮想ホストで，定義ファイルの変更など，メンテナンス作業を実行します。

実行系の仮想ホストに対してmonswapコマンドを実行して，系を切り替えます。

# monswap サーバの識別名

下線部分には，実行系の仮想ホストが配置されているアプリケーションサーバの，serversファイルのオペランド「alias」に指定されている実行系の仮想ホストのサーバの識別名を指定します。

実行系の仮想ホストが停止してから，待機していた系が起動します。これによって，メンテナンス済みの仮想ホストが実行系の仮想ホストになります。

切り替え後の実行系のホスト（予備系の仮想ホスト）に対して，必要に応じて，定義の変更に関連した動作確認を実行します。

切り替え後の待機系のホスト（現用系の仮想ホスト）で定義ファイルの編集など，メンテナンス作業を実行します。

切り替え後の実行系の仮想ホスト（予備系のホスト）に対して，必要に応じて，再度monswapコマンドを実行します。

# monswap サーバの識別名

下線部分には，手順2.でmonswapコマンドの引数に指定したサーバの識別名と同じサーバの識別名を指定します。

現用系の仮想ホストを実行系に戻す場合に実行してください。

切り替え後の実行系の仮想ホスト（現用系の仮想ホスト）で，必要に応じて，定義の変更に関連した動作確認を実行します。

これで，メンテナンス時の起動と停止の手順は完了です。

19　N:1リカバリシステム（クラスタソフトウェアとの連携）

この章では，クラスタソフトウェアと連携したN:1リカバリシステムで運用するシステムについて説明します。

19.1　この章の構成

この章の構成を次の表に示します。

表19‒1　この章の構成（N:1リカバリシステム（クラスタソフトウェアとの連携））

分類

タイトル

参照先

解説

N:1リカバリシステムの概要

19.2

N:1リカバリシステムのシステム構成と動作

19.3

設定

N:1リカバリシステムの設定（Windowsの場合）

19.4

N:1リカバリシステムの設定（UNIXの場合）

19.5

運用

N:1リカバリシステムの起動と停止（Windowsの場合）

19.6

N:1リカバリシステムの起動と停止（UNIXの場合）

19.7

注　「実装」，「注意事項」について，この機能固有の説明はありません。

19.2　N:1リカバリシステムの概要

N:1リカバリシステムとは，クラスタ構成になっている実行系の複数（N台）のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。ただし，バッチアプリケーションの実行環境の場合，N:1リカバリシステムは使用できません。

19.3　N:1リカバリシステムのシステム構成と動作

ここでは，システムの構成例，リカバリ処理の流れについて説明します。

19.3.1　N:1リカバリシステムのシステム構成例

クラスタソフトウェアと連携したN:1リカバリシステムのシステム構成例を次の図に示します。クラスタ構成で実行中のアプリケーションサーバに障害が発生すると，待機系のリカバリ専用サーバが起動し，障害が発生した実行系のトランザクションを決着します。

待機系であるリカバリ専用サーバのJ2EEサーバには，実行系にインポートされているリソースアダプタをすべてインポートします。なお，リカバリ専用サーバは障害が発生した実行系のアプリケーションサーバのリカバリを実施するだけなので，アプリケーションをデプロイする必要はありません。

図19‒1　N:1リカバリシステムのシステム構成例

N:1リカバリシステムでは次のような運用ができます。

共有ディスク装置の使用

共有ディスク装置が必要になります。共有ディスク装置は，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。トランザクション情報は，実行系のそれぞれのアプリケーションサーバと，待機系のリカバリ専用サーバとの間で引き継ぎします。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

なお，N:1リカバリシステムのシステム構成の詳細については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）」を参照してください。

19.3.2　リカバリ処理の流れ

クラスタ構成の実行系と，リカバリ専用サーバである1台の待機系で稼働します。実行系の複数のアプリケーションサーバのうち一つでも障害が発生すると，クラスタソフトウェアで障害を検出し，待機系であるリカバリ専用サーバに切り替えられます。待機系では，ダウンした実行系のアプリケーションサーバのトランザクションを決着します。

リカバリ処理の流れについて次の図に示します。

図19‒2　リカバリ処理の流れ

リカバリ専用サーバのクラスタソフトウェアが障害を検知します。

実行系のアプリケーションサーバCで障害が発生し，ダウンすると，待機系のリカバリ専用サーバのクラスタソフトウェアはアプリケーションサーバCのダウンを検知します。

リカバリ専用サーバのクラスタソフトウェアで系切り替えを実施します。

待機系のリカバリ専用サーバに切り替えます。このとき，共有ディスク装置の切り替え，共有ディスク装置のマウント，および仮想ホストのIPアドレスの設定をします。

リカバリ専用サーバをロックします。

リカバリ専用サーバでは，順次，リカバリ処理を実施します。このため，リカバリ処理を実施する前に，リカバリ専用サーバをロックします。

リカバリ専用サーバのクラスタソフトウェアでリカバリコマンドを実行し，リカバリ専用サーバのアプリケーションサーバをリカバリモードで起動します。

ダウンしたアプリケーションサーバCで仕掛かり中だったトランザクションのリカバリ処理を，リカバリ専用サーバで実施します。

リカバリ専用サーバでは，トランザクションのリカバリ処理だけが実施されます。リカバリ処理終了後，リカバリ専用サーバのアプリケーションサーバは終了します。

リカバリ専用サーバのロックを解除します。

リカバリ専用サーバのクラスタソフトウェアでアプリケーションサーバ終了後の処理を実施します。

共有ディスク装置の切り替え，共有ディスク装置のアンマウント，および仮想ホストのIPアドレスの削除をします。

ほかの実行系のアプリケーションサーバに障害が発生している場合は，リカバリ処理をします。なお，実行系のアプリケーションサーバAおよびBについては，アプリケーションサーバCのダウンの影響を受けず，アプリケーション処理を実行します。

注意事項

複数の実行系で障害が発生し，アプリケーションサーバがダウンした場合は，リカバリ専用サーバ（待機系）では，排他で順次リカバリ処理をします。

リカバリ専用サーバでのリカバリ処理中は，リカバリ専用サーバのサービスポートが閉塞されるため，処理の受け付けはされません。

リカバリ専用サーバでは，リカバリ処理が終了しない場合に備えて，タイムアウト監視が実施されます。

データベースのダウンによってタイムアウトした場合は，手動でリカバリ処理をしてください。詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「2.5.8　N:1リカバリシステムでトラブルが発生した場合」を参照してください。

リカバリ専用サーバがダウンした場合などの二重障害については，対応していません。

19.3.3　系切り替え時の情報の引き継ぎ

系切り替え時に，待機系に引き継がれる情報と，引き継がれない情報について説明します。

引き継がれる情報

OTSトランザクション情報の引き継ぎ（グローバルトランザクションの場合）

実行系から待機系のへの系切り替え後，OTSトランザクション情報を引き継ぎ，トランザクションの回復処理をします。

引き継がれない情報

系切り替えが発生したとき，次に示す情報は切り替え後の系に引き継がれないので注意してください。

Webコンテナが管理するアプリケーションのHTTPセッション情報

WebコンテナのServletContextに設定したアトリビュート情報

ホームインタフェースとコンポーネントインタフェースのBeanのセッション情報

アプリケーションの稼働状態，JNDIのキャッシュ，コネクションプール，CTMのキューなどの状態に関する情報

19.4　N:1リカバリシステムの設定（Windowsの場合）

N:1リカバリシステムは，N台の実行系に対して1台の待機系（リカバリ専用サーバ）を用意する構成のシステムです。J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したとき，トランザクションを決着するために使用します。このシステムは，運用管理ポータルを使用して構築します。運用管理ポータルについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。この節では，N:1リカバリシステムの設定について説明します。

業務は，N台の実行系のアプリケーションサーバで実行します。業務実行中のアプリケーションサーバに障害が発生すると，クラスタソフトウェアがこれを検知して，リカバリ専用サーバで，障害が発生したアプリケーションサーバの仕掛かり中のトランザクションを決着します。その後，残りの稼働中の実行系のアプリケーションサーバで業務を続行します。

なお，N:1リカバリシステムの詳細については，「19.2　N:1リカバリシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）」を参照してください。

19.4.1　N:1リカバリシステムの設定手順

ここでは，Windows Server Failover Clusterと連携する場合の，システムの構成例とシステムの設定手順について説明します。

(1)　システムの構成例

N:1リカバリシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図19‒3　システムの構成例（N:1リカバリシステムの場合）

この例では，4台の実行系サーバと1台のリカバリ専用サーバを配置しています。4台の実行系のうち，3台の実行系では，同じJ2EEサーバ名で同じJ2EEアプリケーションとリソースアダプタがデプロイされている「MyServer」というJ2EEサーバを配置しています。残りの1台の実行系では，J2EEサーバ名や，デプロイされているJ2EEアプリケーションとリソースアダプタが異なる「MyServer2」というJ2EEサーバを配置しています。

N:1リカバリ構成の場合，一つのクラスタ内に複数の仮想ホストを構築します。仮想ホストは実行系ノードとリカバリ専用ノードの組で構成し，J2EEサーバをクラスタ構成で配置します。N:1リカバリ構成の場合，J2EEサーバはクラスタ内ではなく，仮想ホスト内で動作します。このため，仮想ホストのIPアドレスおよびホスト名を設定してください。

仮想ホストは一つのリソースグループとして定義され，「物理ディスクリソース」，「IPアドレスリソース」，「ネットワークリソース名」，「汎用スクリプトリソース」が仮想ホストに含まれます。ここでのリソースグループの例を次の図に示します。

図19‒4　リソースグループの例

アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。N:1リカバリ構成の場合，エイリアスIPアドレスは，仮想ホストのIPアドレスとなります。

待機系のJ2EEサーバには，実行系のJ2EEサーバで使用しているすべてのリソースアダプタと同じ設定のリソースアダプタをインポート，およびデプロイしてください。

(2)　システムの設定手順

Windows Server Failover Clusterと連携する場合には，運用管理ポータルやクラスタアドミニストレータの設定などが必要になります。N:1リカバリシステムの設定手順を次の図に示します。

図19‒5　N:1リカバリシステムの設定手順（Windowsの場合）

図中の1.〜6.について説明します。

共有ディスクにN台分のパーティションを作成して，ファイルシステムを構築します。

Windows Server Failover Clusterのクラスタ管理用ファイルの格納場所を作成します。また，N:1リカバリシステムではグローバルトランザクションを使用するため，トランザクション情報の格納場所を作成します。なお，クラスタ管理用ファイルの格納場所とトランザクション情報の格納場所は，同じパーティションでもかまいません。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，実行系と待機系で，同じドライブ文字を割り当ててください。

運用管理ポータルでクラスタサーバの環境を設定します。

運用管理ポータルの「運用管理ドメインの構成定義」，および「論理サーバの環境設定」で，Windows Server Failover Clusterを使用する場合の設定をします。詳細は，「19.4.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「19.4.3　設定ファイルの編集」を参照してください。

クラスタを設定します。

クラスタソフトウェアの環境を設定します。詳細については，「19.4.4　クラスタの設定」を参照してください。

運用管理ポータル，クラスタアドミニストレータなどで，アプリケーションサーバの設定をします。

運用管理ポータル，クラスタアドミニストレータなどを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「19.4.5　アプリケーションサーバの設定」を参照してください。

19.4.2　クラスタサーバの環境設定

Windows Server Failover Clusterと連携する場合の，運用管理ポータルでの設定の留意点については，「17.4.2　クラスタサーバの環境設定」を参照してください。

なお，N:1リカバリ構成の場合，ホスト名には，クラスタIPアドレスではなく，仮想ホストのIPアドレスを設定してください。

19.4.3　設定ファイルの編集

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。ここでは，Windows Server Failover Clusterと連携する場合に注意が必要なファイルの設定について説明します。

(1)　設定が必要なファイル

設定が必要なファイルは実行系と待機系で異なります。

実行系の場合

実行系の場合に注意が必要な設定を次に示します。

運用管理エージェントの設定

HTTP Serverの設定

ワーカの設定

スマートエージェントの設定

これらのファイルの設定については，「17.4.3　設定ファイルの編集」を参照してください。なお，N:1リカバリ構成の場合には，クラスタIPアドレスではなく，仮想ホストのIPアドレスを設定してください。

待機系（リカバリ専用）の場合

待機系（リカバリ専用）の場合に注意が必要な設定を次に示します。

J2EEサーバのプロパティの設定

この設定について，次に説明します。

(2)　待機系でのJ2EEサーバのプロパティの設定

待機系のJ2EEサーバでusrconf.propertiesにプロパティを設定するときに注意が必要なキーを次に示します。

ejbserver.distributedtx.XATransaction.enabled

ライトトランザクションを無効にするため「true」を設定してください。

19.4.4　クラスタの設定

クラスタに対して，次の設定を実施します。

スクリプトファイルの作成

クラスタソフトウェアの環境設定

(1)　スクリプトファイルの作成

実行系のアプリケーションサーバを起動，停止するためのスクリプトファイルをVBScriptで記述します。実行系の各ノードで同一のスクリプトファイルを使用し，同一のパスに配置してください。

スクリプトファイルは汎用スクリプトをそのまま使用します。汎用スクリプトファイルの例については，「(2)　実行系の汎用スクリプトファイルの例」を参照してください。

ここでは，N:1リカバリシステムのシステムの監視対象および監視方法について説明します。

(a)　監視対象

アプリケーションサーバの1:1系切り替えシステムの監視対象を次に示します。

運用管理エージェント

運用管理エージェントが終了したタイミングで系切り替えが実行されます。

(b)　監視方法

運用管理エージェントのプロセスの有無を監視します。監視するプロセスを次に示します。

adminagent.exe

(2)　実行系の汎用スクリプトファイルの例

N:1リカバリシステムの実行系で使用する汎用スクリプトファイルの例を次に示します。

Dim WshShell, fso, AccessInfoFile, oExec, oRun, oCosmiHome, oAdmin, oMngsvut, oCjsleep
Dim oMngHost, oUser, oPass
Set WshShell = CreateObject("WScript.Shell")

oCosmiHome = WshShell.ExpandEnvironmentStrings("%COSMINEXUS_HOME%")
oAdminac = """" & oCosmiHome & "¥manager¥bin¥adminagentctl"""
oMngsvut = """" & oCosmiHome & "¥manager¥bin¥mngsvrutil"""
oCjsleep = """" & oCosmiHome & "¥CC¥server¥bin¥cjsleep"""

oMngHost = "172.16.12.39" '--- Management Server
oUser = "admin" ' --- Management Server's userid
oPass = "admin" ' --- Management Server's password

'==== Open ====
Function Open( )
    Resource.LogInformation "======== Entering Open. ========"
    ' --- J2EE Server Name ---
    If Resource.PropertyExists("ServerName") = False Then
        Resource.LogInformation "### Private property ServerName is not set. ###"
    End If
    ' --- Inprocess OTS Status Path ---
    If Resource.PropertyExists("StatusPath") = False Then
        Resource.LogInformation "### Private property StatusPath is not set. ###"
    End If
    ' --- Cluster IP Address ---
    If Resource.PropertyExists("IPAddress") = False Then
        Resource.LogInformation "### Private property IPAddress is not set. ###"
    End If
    ' --- Cluster Host Name ---
    If Resource.PropertyExists("HostName") = False Then
        Resource.LogInformation "### Private property HostName is not set. ###"
    End If
    Open = True
End Function

'==== Online ====
Function Online( )
    Resource.LogInformation "======== Entering Online. ========"

    '--- private properties ---
    If Resource.PropertyExists("ServerName") = False Or _
       Resource.PropertyExists("StatusPath") = False Or _
       Resource.PropertyExists("IPAddress") = False Or _
       Resource.PropertyExists("HostName") = False Then
         Resource.LogInformation "### Private property is not set. ###"
         Online = False
         Exit Function
    End If

    '--- adminagentctl ---
    Set oExec = WshShell.Exec(oAdminac & " start")
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop
    If oExec.ExitCode <> 0 Then
        Resource.LogInformation "### Administration Agent cannot start. ### rtn=" & oResult
        Resource.LogInformation oExec.StdErr.ReadAll
        Online = False
        Exit Function
    End If

    '--- mngsvrutil ---
    oRun = oMngsvut & " -m "& oMngHost &":28080 -u " & oUser & " -p " & oPass & _
                      " -t " & Resource.HostName & " -k host -s start server"
    Set oExec = WshShell.Exec(oRun)
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop
    If oExec.ExitCode <> 0 Then
        Resource.LogInformation "### Logical Servers start failed. ### rtn=" & oResult
        Resource.LogInformation oExec.StdErr.ReadAll
        Online = False
        Exit Function
    End If
    Online = True
End Function

'==== LooksAlive ====
Function LooksAlive( )
    Resource.LogInformation "======== Entering LooksAlive. ========"

    '--- tasklist ---
    Set oExec = WshShell.Exec("tasklist /NH /FI ""IMAGENAME eq adminagent.exe""")
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop

    If InStr(1, oExec.StdOut.ReadAll, "adminagent.exe", 1) <> 0 Then
        LooksAlive = True
    Else
        LooksAlive = False
    End If
End Function

'==== IsAlive ====
Function IsAlive( )
    Resource.LogInformation "======== Entering IsAlive. ========"

    '--- mngsvrutil ---
    oRun = oMngsvut & " -m " & oMngHost & ":28080 -u " & oUser & " -p " & oPass & _
                      " -t " & Resource.HostName & " -k host check adminAgent"
    Set oExec = WshShell.Exec(oRun)
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop
    If oExec.ExitCode <> 0 Then
        Resource.LogInformation "### Administration Agent command failed. ### rtn=" & oExec.ExitCode
        Resource.LogInformation oExec.StdErr.ReadAll
        IsAlive = False
    Else
        IsAlive = True
    End If
End Function

'==== Offline ====
Function Offline( )
    Resource.LogInformation "======== Entering Offline. ========"

    '--- mngsvrutil ---
    oRun = oMngsvut & " -m " & oMngHost & ":28080 -u " & oUser & " -p " & oPass & _
                      " -t " & Resource.HostName & " -k host -s stop server"
    Set oExec = WshShell.Exec(oRun)
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop
    If oExec.ExitCode <> 0 Then
        Resource.LogInformation "### Logical Server stopping failed. ### rtn=" & oResult
        Resource.LogInformation oExec.StdErr.ReadAll
        Offline = False
        Exit Function
    End If

    '--- adminagentctl ---
    Set oExec = WshShell.Exec(oAdminac & " stop")
    Do While oExec.Status = 0
        WshShell.Run oCjsleep & " 1", 0, True
    Loop
    If oExec.ExitCode <> 0 Then
        Resource.LogInformation "### Administration Agent stopping failed. ### rtn=" & oResult
        Resource.LogInformation oExec.StdErr.ReadAll
        Offline = False
        Exit Function
    End If
    Offline = True
End Function

'==== Close ====
Function Close( )
    Resource.LogInformation "======== Entering Close. ========"
    Close = True
End Function

'==== Terminate ====
Function Terminate( )
    Resource.LogInformation "======== Entering Terminate. ========"
    Terminate = True
End Function

実行系の汎用スクリプトファイルでは，必要に応じて変数の値を変更してください。汎用スクリプトファイルで定義する変数については，「(a)　汎用スクリプトファイルの変数」を参照してください。

また，N:1リカバリシステムの汎用スクリプトファイルでは，一つのスクリプトファイルを複数の仮想サーバから参照します。このため，汎用スクリプトファイルがサーバごとの設定を参照できるように，プライベートプロパティを使用します。仮想サーバごとに設定するプライベートプロパティについては，「(3)　プライベートプロパティの設定」を参照してください。

(a)　汎用スクリプトファイルの変数

実行系の汎用スクリプトファイルでは，必要に応じて変数の値を変更してください。次の表に示す変数の値を変更してください。

表19‒2　実行系の汎用スクリプトファイルの変数（N:1リカバリシステムの場合）

変数名

内容

oMngHost

Management Serverが稼働しているホスト

oUser

Management ServerにログインするためのログインID

oPass

Management Serverにログインするためのパスワード

(3)　プライベートプロパティの設定

仮想サーバごとにプライベートプロパティを設定してください。汎用スクリプトファイルに必要なプライベートプロパティを次の表に示します。

表19‒3　汎用スクリプトファイルに必要なプライベートプロパティ

プライベートプロパティ

内容（例）

ServerName

J2EEサーバ名

指定例：MyServer

StatusPath

インプロセスOTSのステータスパス

指定例：I:¥otsstatus

IPAddress

仮想サーバのIPアドレス

指定例：172.16.12.31

HostName

仮想サーバ名

指定例：Server1

プライベートプロパティはclusterコマンドで設定します。clusterコマンドについては，使用しているOSのマニュアルを参照してください。次にclusterコマンドを使用したプライベートプロパティの設定例を示します。

cluster res Script1 /priv ServerName=MyServer
cluster res Script1 /priv StatusPath="I:¥otsstatus"
cluster res Script1 /priv IPAddress=172.16.12.31
cluster res Script1 /priv HostName=Server1

cluster res Script2 /priv ServerName=MyServer
cluster res Script2 /priv StatusPath="J:¥otsstatus"
cluster res Script2 /priv IPAddress=172.16.12.32
cluster res Script2 /priv HostName=Server2

cluster res Script3 /priv ServerName=MyServer
cluster res Script3 /priv StatusPath="K:¥otsstatus"
cluster res Script3 /priv IPAddress=172.16.12.33
cluster res Script3 /priv HostName=Server3

cluster res Script4 /priv ServerName=MyServer2
cluster res Script4 /priv StatusPath="L:¥otsstatus"
cluster res Script4 /priv IPAddress=172.16.12.34
cluster res Script4 /priv HostName=Server4

(4)　クラスタソフトウェアの環境設定

Windows Server Failover Clusterの環境設定については，使用するクラスタソフトウェアのマニュアルを参照してください。

19.4.5　アプリケーションサーバの設定

アプリケーションサーバの設定では，運用管理ポータル，クラスタアドミニストレータなどを使用してアプリケーションサーバをクラスタ構成に配置します。また，論理サーバをセットアップして設定情報を配布し，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。アプリケーションサーバの設定手順を次に示します。

各実行系ノードで，各リソースグループをオンラインにします。

Node1のGroup1，Node2のGroup2，Node3のGroup3，およびNode4のGroup4をオンラインにします。

運用管理ポータルで，各実行系のJ2EEサーバをセットアップします。

「運用管理ドメインの構成定義」の［セットアップ］画面で，J2EEサーバをセットアップします。運用管理ポータルでの操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルで，J2EEサーバに設定した情報を実行系ノードに配布します。

「論理サーバの環境設定」の［設定情報の配布］画面で，J2EEサーバに設定した情報を各実行系に配布します。

サーバ管理コマンドを使用して，各実行系のアプリケーションサーバのJ2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。また，インポートしたJ2EEアプリケーションとリソースアダプタを設定および開始します。

J2EEアプリケーションの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」，リソースアダプタの設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の次の個所を参照してください。

4.1.26　DB Connectorを設定する（CUI利用時）

4.1.27　DB Connector以外のリソースアダプタを設定する（CUI利用時）

4.1.28　リソースアダプタを開始する（CUI利用時）

また，サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

なお，J2EEサーバおよびその前提プロセスを起動してからサーバ管理コマンドを実行してください。また，サーバ管理コマンドでの操作が終わったら，サーバ管理コマンドを停止してください。

クラスタアドミニストレータで，各リソースグループに対して「グループの移動」を実行して系を切り替え，リソースの所有者を待機系ノード（NodeR）に変更します。

サーバ管理コマンドを使用して，待機系のアプリケーションサーバにリソースアダプタをインポートします。

待機系のJ2EEサーバには，実行系の各J2EEサーバで使用しているリソースアダプタと同じ設定のリソースアダプタをインポートしてください。

ただし，待機系のJ2EEサーバに定義するリソースアダプタでは，コネクションプーリング機能を使用する必要はありません。サーバ管理コマンドで設定するコネクションの最小値と最大値には0を指定してください。

クラスタアドミニストレータで，各リソースグループに対して「グループの移動」を実行して系を切り替え，リソースの所有者を各実行系ノードに戻します。

19.5　N:1リカバリシステムの設定（UNIXの場合）

N:1リカバリシステムは，N台の実行系に対して1台の待機系（リカバリ専用サーバ）を用意する構成のシステムです。J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したとき，トランザクションを決着するために使用します。このシステムは，運用管理ポータルを使用して構築します。運用管理ポータルについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。この節では，N:1リカバリシステムの設定について説明します。

業務は，N台の実行系のアプリケーションサーバで実行します。業務実行中のアプリケーションサーバに障害が発生すると，HAモニタがこれを検知して，リカバリ専用サーバで，障害が発生したアプリケーションサーバの仕掛かり中のトランザクションを決着します。その後，残りの稼働中の実行系のアプリケーションサーバで業務を続行します。

なお，N:1リカバリシステムの運用は，AIXまたはLinuxの場合だけ使用できます。

機能の詳細については，「19.2　N:1リカバリシステムの概要」を参照してください。システム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）」を参照してください。また，HAモニタについては，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

19.5.1　N:1リカバリシステムの設定手順

ここでは，システムの構成例とシステムの設定手順について説明します。また，実行系を追加または削除する場合の設定手順についても説明します。

(1)　システムの構成例

N:1リカバリシステムの構成例を次の図に示します。なお，以降の項では，このシステムの構成例を使用したシステムの構築例を示します。

図19‒6　N:1リカバリシステムの構成例（UNIXの場合）

この例の概要を次に示します。

4台の実行系サーバと1台のリカバリ専用サーバを配置しています。4台の実行系のJ2EEサーバの構成はJ2EEアプリケーションとリソースアダプタの設定が均質な構成とします。違いはエイリアスIPアドレスとマウントする共有ディスクデバイスです。

実行系と待機系で，J2EEサーバは同じ名称にします。ここでは，実行系で「MyServer」というJ2EEサーバを配置しているため，待機系にも「MyServer」というJ2EEサーバを配置します。

Management Serverの運用管理ポータルを利用してシステムを構築，運用管理します。

実行系では運用管理エージェントを動作させます。待機系では運用管理エージェントを動作させません。

なお，N:1リカバリシステムを運用する場合は，次の条件を満たすアプリケーションサーバを構築してください。

OTSを使用したグローバルトランザクションを使用します。トランザクションのステータスファイルは共有ディスク装置に格納します。

ネーミングサービスはインプロセスで動作させます。

待機系のJ2EEサーバには，実行系のJ2EEサーバで使用しているすべてのリソースアダプタと同じ設定のリソースアダプタをインポート，およびデプロイします。

N:1リカバリ構成の場合，一つのクラスタ内に複数の仮想ホストを構築します。仮想ホストは実行系とリカバリ専用サーバの組で構成し，J2EEサーバをクラスタ構成で配置します。N:1リカバリ構成の場合，J2EEサーバはクラスタ内ではなく，仮想ホスト内で動作します。このため，仮想ホストのIPアドレスおよびホスト名を設定してください。

アプリケーションサーバをクラスタ構成に配置するためには，エイリアスIPアドレスを設けて，稼働中のノードがエイリアスIPアドレスを引き継ぐことで，クライアントがクラスタ内のノードを意識しないようにします。N:1リカバリ構成の場合，エイリアスIPアドレスは，仮想ホストのIPアドレスとなります。N:1リカバリ構成での仮想ホストの構成例を次に示します。

図19‒7　N:1リカバリ構成での仮想ホストの構成例

(2)　システムの設定手順

HAモニタと連携する場合には，運用管理ポータルやHAモニタのファイルの設定などが必要になります。N:1リカバリシステムの設定手順を次の図に示します。

図19‒8　N:1リカバリシステムの設定手順（UNIXの場合）

図中の1.〜9.について説明します。

共有ディスクにN個のパーティションを作成して，ファイルシステムを構築します。

システムに共有ディスクを割り当てます。

システムに共有ディスクを割り当てる際は，現用系と予備系で，同じマウント先ディレクトリにしてください。

運用管理ポータルでクラスタサーバの環境を設定します。

運用管理ポータルの「Cosminexus Management Serverの設定」，「運用管理ドメインの構成定義」，および「論理サーバの環境設定」で，HAモニタを使用する場合の設定をします。詳細は，「19.5.2　クラスタサーバの環境設定」を参照してください。

設定ファイルを編集します。

運用管理エージェントやManagement Server，HTTP Serverなどの各種定義ファイルを設定します。詳細は，「19.5.3　設定ファイルの編集」を参照してください。

HAモニタの環境を設定します。

HAモニタのsysdefファイルで，HAモニタの環境を定義します。詳細は，「19.5.4　HAモニタの環境設定」を参照してください。

シェルスクリプトファイルを作成します。

運用管理エージェントを監視，アプリケーションサーバ上の論理サーバを起動，停止するためのシェルスクリプトファイルを作成します。詳細は，「19.5.5　シェルスクリプトファイルの作成」を参照してください。

サーバ対応の環境を設定します。

HAモニタのserversファイルで，系で稼働させる現用系サーバや予備系サーバの環境を定義します。詳細は，「19.5.6　サーバ対応の環境設定」を参照してください。

LANの状態を設定します。

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。詳細は，「19.5.7　LANの状態設定」を参照してください。

運用管理ポータルとHAモニタのコマンドで，アプリケーションサーバの設定をします。

運用管理ポータル，HAモニタのコマンドを使用して，アプリケーションサーバをクラスタ構成に配置し，J2EEアプリケーションやリソースアダプタを設定します。詳細は，「19.5.8　アプリケーションサーバの設定」を参照してください。

参考

N:1リカバリシステムで，待機系でのリカバリ処理がデータベースサーバの障害（サーバダウンやデッドロックなど）によってタイムアウトした場合は，手動でリカバリを実行する必要があります。

タイムアウトの原因を解消したあと，待機系のホストで，停止した実行系のホストに対応するmonbeginコマンドを実行し，停止した実行系のホストに対応するmonactコマンドを実行します。

N:1リカバリシステムでトラブルが発生した場合については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「2.5.8　N:1リカバリシステムでトラブルが発生した場合」を参照してください。

N:1リカバリシステムで設定が必要なファイルは，実行系と待機系で異なります。N:1リカバリシステムでのファイルの設定の要否を次の表に示します。

表19‒4　N:1リカバリシステムでのファイルの設定の要否

分類

ファイルの種類

ファイルの設定の要否

参照先

実行系（N台）

待機系（リカバリ専用1台）

アプリケーションサーバの設定

運用管理エージェントの設定

adminagent.properties

必要（N台で個別の設定）

−

19.5.3

スマートエージェントの設定

localaddr

HTTP Serverの設定

httpsd.conf※

J2EEサーバのプロパティの設定

usrconf.properties※

必要（N台で共通の設定）

必要（エイリアスIPアドレス以外は実行系とほとんど同じ）

HAモニタの設定

HAモニタの環境設定

sysdef

必要（各ホストで個別の設定）

必要（N台分の設定）

19.5.4

シェルスクリプトファイルの作成

monitor.sh

start.sh

stop.sh

必要（N台で共通のコマンドを使用）

−

19.5.5

サーバ対応の環境設定

servers

必要（N台で個別の設定）

必要（N台分の設定）

19.5.6

recover.sh

−

必要（N台の実行系に対して共通のコマンドを使用。差異は引数で渡す）

LANの状態設定

<サーバの識別名>.up

<サーバ識別名>.down

必要（各ホストで個別の設定）

必要（実行系の設定ファイルのコピー）

19.5.7

（凡例）　−：不要。

注※　運用管理ポータルを利用してアプリケーションサーバの実行環境を構築するときに，これらのファイルを設定できます。

(3)　実行系を追加または削除する場合の設定手順

N:1リカバリシステムで，1台の実行系を追加または削除（縮退）する場合の設定手順を次に示します。

1台の実行系を追加する場合

追加する実行系で，マウントディレクトリを作成します。

待機系のserversファイルに追加する実行系に対応したエントリを追加します。

なお，追加する実行系に対応したエントリがすでに存在する場合はこの手順は不要です。

待機系で，追加した実行系に対応するmonbeginコマンドを実行します。

実行系で，monbeginコマンドを実行します。

運用管理ポータルを利用して，追加する実行系にアプリケーションサーバの実行環境を構築します。

運用管理ポータルを使用して，一括起動で実行系のアプリケーションサーバを起動します。

1台の実行系を削除する場合

実行系で，monendコマンドを実行します。

19.5.2　クラスタサーバの環境設定

HAモニタと連携する場合の，運用管理ポータルでの設定の留意点については，「17.6.2　クラスタサーバの環境設定」を参照してください。なお，N:1リカバリ構成の場合，ホスト名には，エイリアスIPアドレスではなく，仮想ホストのIPアドレスを設定してください。

19.5.3　設定ファイルの編集

運用管理エージェントやManagement Server，HTTP Serverなどの各種設定ファイルを編集します。ここでは，HAモニタと連携する場合に注意が必要なファイルの設定について説明します。

(1)　設定が必要なファイル

設定が必要なファイルは実行系と待機系で異なります。

実行系（N台）の場合

実行系（N台）の場合に注意が必要な設定ファイルについて説明します。

ファイルを直接編集して設定できるファイル

次のファイルは，ファイルを直接編集して設定できます。

運用管理エージェントの設定（adminagent.properties）

スマートエージェントの設定（localaddr）

運用管理ポータルで設定できるファイル

次のファイルは，運用管理ポータルを利用してアプリケーションサーバの実行環境を構築するときに設定できます。

HTTP Serverの設定（httpsd.conf）

J2EEサーバのプロパティの設定（usrconf.properties）

これらのファイルの設定については，「17.6.3　設定ファイルの編集」を参照してください。なお，N:1リカバリ構成の場合，ホスト名には，エイリアスIPアドレスではなく，仮想ホストのIPアドレスを設定してください。

待機系（リカバリ専用1台）の場合

待機系（リカバリ専用1台）の場合に注意が必要な設定ファイルを次に示します。なお，このファイルは，ファイルを直接編集して設定できます。

J2EEサーバのプロパティの設定（usrconf.properties）

(2)　待機系でのJ2EEサーバのプロパティの設定

待機系のJ2EEサーバでusrconf.propertiesにプロパティを設定するときに注意が必要なキーを次に示します。

ejbserver.distributedtx.XATransaction.enabled

ライトトランザクションを無効にするため「true」を設定してください。

19.5.4　HAモニタの環境設定

使用しているシステムに従って，sysdefという定義ファイルにHAモニタの環境を定義してください。N台の実行系とリカバリ専用の1台の待機系を含めて各ホストで個別の設定が必要です。

name（HAモニタのホスト名），address（CPUリセット用のユニークな値），lan（LANのホスト名）をホスト環境に合わせて一意に設定してください。なお，N台の実行系とリカバリ専用の1台の待機系を含めて一意の値を設定する必要があります。また，lanport（lanオペランドで指定したホスト名に対応するサービス名）は，N台の実行系とリカバリ専用の1台の待機系を含めて同じ値を設定する必要があります。

sysdefファイルの例を次に示します。なお，サンプル中の「N」は，N番目の値であることを意味します。

environment name     $host_N,    #自系のホスト名
            address  $uniq_N,    #CPUリセット用のユニークな値
            patrol   5,          #系障害と判断する時間
            lan      $host_N     #LANのホスト名
            lanport  $service_N  #lanオペランドのホスト名に対応するサービス名

HAモニタの環境設定については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

19.5.5　シェルスクリプトファイルの作成

運用管理エージェントのプロセスを監視し，運用管理エージェントと論理サーバを起動および停止するために，次のシェルスクリプトファイルを作成します。

実行系（N台）の場合

実行系で設定が必要なシェルスクリプトファイルを次に示します。なお，N台で共通のコマンドを使用します。

運用管理エージェントのプロセスを監視するシェルスクリプトファイル

運用管理エージェントを起動するシェルスクリプトファイル

運用管理エージェントと論理サーバを停止するシェルスクリプトファイル

待機系（リカバリ専用1台）の場合

待機系で設定が必要なシェルスクリプトファイルを次に示します。なお，N台の実行系に対して共通のコマンドを使用し，差異はコマンドの引数で渡すようにします。

リカバリ処理を実行するシェルスクリプトファイル

各スクリプトについて説明します。

(1)　運用管理エージェントのプロセスを監視するシェルスクリプトファイル

運用管理エージェントのプロセスを監視するシェルスクリプトファイルの例（monitor.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
AA=/opt/Cosminexus/manager/bin/adminagent

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

logg "### $0: started. ###"
while true
do
    CHECK=`ps -ef | grep $AA | grep -v grep`

    if [ "$CHECK" = "" ]
    then
        logg "### $0: stop. ###"
        exit 0
    fi
    sleep 10
done

この例では，運用管理エージェントのプロセスが存在しているかどうかを10秒おきに監視しています。

(2)　運用管理エージェントを起動するシェルスクリプトファイル

運用管理エージェントを起動するためのシェルスクリプトファイルの例（start.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

# start Administration Agent
logg "### $0: starting Administration Agent. ###"
$MNGDIR/bin/adminagentctl start
if [ $? -eq 0 ] ; then
  logg "### $0: Administration Agent start normally. ###"
else
  logg "### $0: Administration Agent cannot start. ###"
  exit 1
fi

exit 0

(3)　運用管理エージェントと論理サーバを停止するシェルスクリプトファイル

運用管理エージェントと論理サーバを停止するためのシェルスクリプトファイルの例（stop.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
MNGDIR=/opt/Cosminexus/manager

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

# stop logical server
logg "### $0: stop logical servers. ###"
$MNGDIR/bin/mngsvrutil -m mnghost:28080 -u admin -p admin ¥
                            -t 172.16.12.31 -k host -s stop server

# stop Administration Agent
logg "### $0: stopping Administration Agent. ###"
$MNGDIR/bin/adminagentctl stop

exit 0

シェルスクリプトファイルでの設定内容のポイントを説明します。

論理サーバの停止

同一ホスト上の論理サーバを一括停止するように設定します。論理サーバの一括停止にはmngsvrutilコマンドを使用します。

ユーザ名とパスワードは引数として渡しています。これらの値は，mngsvrutilコマンドのクライアント側定義ファイル（.mngsvrutilrc）に記述して，適切なアクセス権を設定して管理するようにしてください。

また，mngsvrutilコマンドの-tオプションにはエイリアスIPアドレスを指定してください。

なお，mngsvrutilコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。また，クライアント側定義ファイル（.mngsvrutilrc）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「8.2.14　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）」を参照してください。

運用管理エージェントの停止

運用管理エージェントを停止するように設定します。運用管理エージェントの停止には，adminagentctl stopを使用します。

なお，adminagentctlコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「adminagentctl（運用管理エージェントの起動と停止）」を参照してください。

(4)　リカバリ処理を実行するシェルスクリプトファイル

各J2EEサーバに対してリカバリ処理を実行するためのシェルスクリプトファイルの例（recover.sh）を次に示します。

#!/bin/sh

LOGDIR=/home/manager/hamon/log
PATH=/opt/Cosminexus/CC/server/bin:/bin:/usr/bin:/home/manager/hamon/bin
LD_LIBRARY_PATH=/opt/DABroker/lib:/opt/Cosminexus/jdk/lib:/opt/Cosminexus/TPB/lib:/opt/Cosminexus/PRF/lib:/opt/Cosminexus/CTM/lib:/bin:/opt/HiRDB/client/lib:/opt/oracle/app/oracle/product/10.1.0/client_1/lib:/opt/oracle/app/oracle/product/10.1.0/client_1/lib/libclntsh.so.10.1:/opt/oracle/app/oracle/product/10.1.0/client_1/lib/libclntsh.so
export LD_LIBRARY_PATH

LOCKFILE=/var/lock/kosmi_recover.lock
SLEEP_TIME=60
RETRIES=30
STATUS_PATH=$3/otsstatus

cjlockfile()
{
    counter=$2
    TMP_LOCK_FILE=`dirname $3`/$$.lock
    echo $$ > $TMP_LOCK_FILE

    if [ -f $3 ]
    then
        kill -0 `cat $3` 2>/dev/null || rm -f $3
    fi

    until ln $TMP_LOCK_FILE $3 2>/dev/null
    do
        counter=`expr $counter - 1`
        if [ $counter -le 0 ]
        then
            rm -f $TMP_LOCK_FILE
            return 1
        fi
        sleep $1
    done

    rm -f $TMP_LOCK_FILE
    return 0
}

logg()
{
    echo `date '+[%Y/%m/%d %H:%M:%S]'`"[$$]: $1" ¥
        >> ${LOGDIR}/adminagent.log 2>&1
}

if cjlockfile ${SLEEP_TIME} ${RETRIES} ${LOCKFILE}
then
    logg "### $0: started for $1 ###"
    cjstartrecover MyServer -p vbroker.se.iiop_tp.host=$2 ¥
                  -p ejbserver.distributedtx.ots.status.directory1=$STATUS_PATH ¥
                  -t 600
    logg "### $0: ended. $? ###"
fi

rm -f $LOCKFILE

exit 0

シェルスクリプトファイルでの設定内容のポイントを説明します。

リカバリ処理に必要で，実行系ごとに異なる情報（エイリアス名，エイリアスIPアドレス，マウントディレクトリ）は，serversファイルの待機系のactcommandで，コマンドの引数として渡します。

LD_LIBRARY_PATHなどの環境変数を明示的に指定する必要があります。環境変数については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.10　環境変数とは」を参照してください。

cjlockfile関数を利用して，リカバリ処理が排他的に実行されるようにしています。この関数は，ファイルロックによるセマフォを提供しています。第1引数にスリープ時間（秒単位），第2引数にリトライ回数，第3引数にロックファイルを指定します。この関数では，第3引数で指定されたファイルがロックされている場合には，第1引数で指定した時間だけ待って再度ファイルロックの取得を試みます。第2引数に指定した回数分リトライしてもファイルロックが取得できない場合には，リカバリ処理に失敗します。ファイルをロックしているプロセスが存在しない場合は，ロックを横取りします。

J2EEサーバ（MyServer）に対してcjstartrecoverでリカバリ処理を実行します。

このサンプルでは，タイムアウト時間は600秒にしています。

cjstartrecover コマンドの-pオプションで，ejbserver.distributedtx.ots.status.directory1キーに停止した実行系のステータスファイルディレクトリが指定されるようにしています。

cjstartrecover コマンドの-pオプションで，vbroker.se.iiop_tp.hostキーに系切り替え後のエイリアスIPアドレスが指定されるようにしています。

停止した実行系ごとに異なるプロパティをcjstartrecover コマンドの-pオプションで上書き指定しています。

J2EEサーバが複数の構成の場合には，cjstartrecoverコマンドをJ2EEサーバの数だけ実行します。その際，J2EEサーバ名（MyServer）とOTSのステータスファイルディレクトリのパスは適宜修正してください。

なお，cjstartrecoverコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstartrecover（J2EEサーバのトランザクション回復）」を参照してください。ejbserver.distributedtx.ots.status.directory1キーおよびvbroker.se.iiop_tp.hostキーについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

19.5.6　サーバ対応の環境設定

HAモニタでのサーバ対応の環境設定では，系で稼働させる実行サーバや待機サーバの環境を定義します。

実行系（N台）の場合

N台で個別の設定が必要です。

待機系（リカバリ専用1台）の場合

N台分の実行系の設定が必要です。

serversという定義ファイルに，N:1リカバリシステム用のサーバ対応の環境を定義してください。サーバ対応の環境設定での設定内容を次の表に示します。

表19‒5　サーバ対応の環境設定での設定内容（N:1リカバリシステムの場合）

オペランド

設定内容

name

実行系の場合

起動コマンドをN台で共通化するため，nameにはユニークな名前を指定し，actcommandに運用管理エージェントを起動するシェルスクリプトファイルを記述します。

待機系の場合

対応する実行系と同じ値を指定します。

alias

実行系の場合

サーバの識別名を指定します。

指定例：AP1

待機系の場合

対応する実行系と同じ値を指定します。

acttype

サーバの起動方法を指定します。ここでは，HAモニタのコマンドでサーバを起動するため，「monitor」を指定します。

termcommand

実行系の場合

実行系の運用管理エージェントと論理サーバを停止するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/stop.sh

待機系の場合

待機系の運用管理エージェントと論理サーバを停止するシェルスクリプトファイルを指定します。

initial

サーバ起動時の状態を指定します。

実行系の場合

「online」を指定します。

待機系の場合

「standby」を指定します。

disk

共有ディスク装置のキャラクタ型スペシャルファイル名を指定します。

実行系の場合

割り当てられた共有ディスクに合わせて指定します。

待機系の場合

対応する実行系と同じ値を指定します。

lan_updown

LANの状態設定ファイルを使用するかどうかを指定します。ここでは，LANの状態設定ファイルを使用するため，「use」を指定します。

fs_name

切り替えるファイルシステムに対応する論理ボリュームの絶対パス名を指定します。

実行系の場合

割り当てられた共有ディスクに合わせて指定します。

待機系の場合

対応する実行系と同じ値を指定します。

fs_mount_dir

切り替えるファイルシステムのマウント先ディレクトリの絶対パス名を指定します。

実行系の場合

割り当てられた共有ディスクに合わせて指定します。

待機系の場合

対応する実行系ごとに異なるマウントディレクトリとします。存在するディレクトリでなくてはならないので，待機系の構築時にあらかじめ作成しておく必要があります。

patrolcommand

実行系の場合

運用管理エージェントのプロセスを監視するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/monitor.sh

待機系の場合

monendコマンドを指定して，actcommandでリカバリが終了したらHAモニタを終了させるようにします。

servexec_retry

実行系で障害を検出した場合の再起動の回数を指定します。実行系および待機系で同じ値を指定してください。

waitserv_exec

実行系および待機系で，起動完了処理を実行するときに起動コマンドの実行完了を待つようにするため，「yes」を指定します。

actcommand

実行系の場合

運用管理エージェントを起動するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/start.sh

待機系の場合

リカバリ処理を実行するシェルスクリプトファイルを指定します。

指定例：/home/manager/hamon/bin/recover.sh

serversファイルのサンプルを次に示します。なお，サンプル中の「N」や「N+1」は，N番目またはN+1番目の値であることを意味します。

serversファイルのサンプル（実行系の場合）

このサンプル中で下線の引いてある個所は，実行系ごとに内容が異なる個所であることを示します。

server name            $name_N,
       alias           $alias_N,
       acttype         monitor,
       initial         online,
       termcommand     /home/manager/hamon/bin/stop.sh,
       disk            $disk_N,
       lan_updown      use,
       fs_name         $fs_name_N,
       fs_mount_dir    /hamon,
       patrolcommand   /home/manager/hamon/bin/monitor.sh,
       servexec_retry  3,
       waitserv_exec   yes,
       actcommand      /home/manager/hamon/bin/start.sh;

serversファイルのサンプル（待機系の場合）

このサンプル中では，リカバリ処理を実行するコマンドを一つにするため，実行系ごとに異なる情報（エイリアス名，エイリアスIPアドレス，マウントディレクトリ）は引数として渡しています。また，このサンプル中で下線の引いてある個所は，実行系のserversファイルと内容が異なる個所であることを示します。

server name             $name_N,
       alias            $alias_N,
       acttype          monitor,
       initial          standby,
       termcommand      /home/manager/hamon/bin/stop.sh,
       disk             $disk_N,
       lan_updown       use,
       fs_name          $fs_name_N,
       fs_mount_dir     $mnt_N,
       patrolcommand    "/opt/hitachi/HAmon/bin/monend $alias_N",
       servexec_retry   3,
       waitserv_exec    yes,
       actcommand       "/home/manager/hamon/bin/recover.sh $alias_N $ip_N $mnt_N";

server name             $name_N+1,
       alias            $alias_N+1,
       acttype          monitor,
       initial          standby,
       termcommand      /home/manager/hamon/bin/stop.sh,
       lan_updown       use,
       disk             $disk_N+1,
       fs_name          $fs_name_N+1,
       fs_mount_dir     $mnt_N+1,
       patrolcommand    "/opt/hitachi/HAmon/bin/monend $alias_N+1",
       servexec_retry   3,
       waitserv_exec    yes,
       actcommand       "/home/manager/hamon/bin/recover.sh $alias_N+1 $ip_N+1 $mnt_N+1";

待機系のserversファイルの設定内容のポイントについて説明します。

待機系のserversファイルには，N台分の実行系の設定を記述してください。また，実行系に対応したエントリを記述してください。

リカバリ処理を実行するコマンドを一つにするため，実行系ごとに異なる情報（エイリアス名，エイリアスIPアドレス，マウントディレクトリ）は引数として渡すことをお勧めします。

19.5.7　LANの状態設定

HAモニタのLANの状態設定ファイルで，LANアダプタのIPアドレスなどを指定してHAモニタでのLANの切り替えについて定義します。

次のファイルにエイリアスIPアドレスを設定してください。

<サーバ識別名>.upファイル

LANを接続する場合に使用します。LANアダプタに追加するエイリアスIPアドレスを指定します。

<サーバ識別名>.downファイル

LANを切り離す場合に使用します。LANアダプタから削除するエイリアスIPアドレスを指定します。

<サーバ識別名>には，サーバ対応の環境設定（serversファイル）のaliasの値を指定してください。

実行系および待機系で，それぞれLANの状態設定ファイルを作成してください。

実行系（N台）

エイリアスIPアドレスを設定・削除するスクリプトを作成します。ホストごとにエイリアスIPアドレスに合わせて設定してください。

待機系（リカバリ専用1台）

N台の実行系ホストの.upファイルと.downファイルを用意します。論理ネットワークデバイスは，N台の実行系ホストごとにユニークな値を指定してください。

LANの状態設定の詳細については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

Linuxの場合のファイルの作成例を次に示します。このほかのOSの場合の作成例については，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

<サーバの識別名>.upファイルの例

#!/bin/sh
/sbin/ifconfig eth0:1 inet 172.16.12.31 ¥
                          netmask 255.255.255.0 broadcast 10.209.112.255 up
/sbin/arping -U -c 2 -I eth0 172.16.12.31

<サーバの識別名>.downファイルの例

#!/bin/sh
/sbin/ifconfig eth0:1 down

19.5.8　アプリケーションサーバの設定

アプリケーションサーバの設定では，運用管理ポータルとHAモニタのコマンドを使用してアプリケーションサーバをクラスタ構成に配置します。また，論理サーバをセットアップして設定情報を配布し，J2EEサーバにJ2EEアプリケーションとリソースアダプタをインポート，および開始します。アプリケーションサーバの設定手順を次に示します。

待機系ノードで，リカバリ用のJ2EEサーバを起動します。

cjstartsvコマンドを使用して，待機系（NodeR）のリカバリ用のJ2EEサーバを起動します。

待機系ノードのリカバリ用のJ2EEサーバで，リソースアダプタを設定します。

待機系では，実行系で使用しているすべてのリソースアダプタと同じ設定のリソースアダプタをインポート，デプロイ，および開始状態にしてください。ただし，待機系のJ2EEサーバに定義するリソースアダプタでは，コネクションプーリング機能を使用する必要はありません。サーバ管理コマンドで設定するコネクションの最小値と最大値は0を指定してください。

リソースアダプタのインポート，デプロイ，および開始には，サーバ管理コマンドを使用します。サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

リソースアダプタの設定が完了したら，待機系ノードのリカバリ用のJ2EEサーバを停止します。

cjstopsvコマンドを使用して，待機系（NodeR）のリカバリ用のJ2EEサーバを停止します。

待機系ノードでHAモニタのmonbeginコマンドを実行して，待機系のアプリケーションサーバを待機状態にします。

待機系ノードでのコマンドの実行例

待機系（NodeR）で，N台の実行系（Node1〜Node4）に対応する「# monbegin <サーバ識別名>」を実行して，N台の実行系に対応する待機系を待機状態にします。

運用管理サーバを起動します。

運用管理サーバを起動して，運用管理サーバ上の運用管理エージェント，Management Server，および論理サーバ（監視用CORBAネーミングサービス）を起動します。運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

実行系ノード（Node1〜Node4）でHAモニタのmonbeginコマンドを実行して，実行系のアプリケーションサーバを実行系として起動します。

実行系ノードでのコマンドの実行例

Node1〜Node4で「# monbegin <サーバ識別名>」を実行して，各ノードの実行系を起動します。この例では，シェルスクリプトファイル（start.sh）が実行されて，Node1〜Node4の各実行系の運用管理エージェントが起動されます。

運用管理ポータルで，Node1〜Node4の各実行系のJ2EEサーバをセットアップします。

「運用管理ドメインの構成定義」の［セットアップ］画面で，J2EEサーバをセットアップします。運用管理ポータルでの操作手順および画面の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルで，J2EEサーバに設定した情報をNode1〜Node4の各実行系に配布します。

「論理サーバの環境設定」の［設定情報の配布］画面で，J2EEサーバに設定した情報をNode1〜Node4の各実行系に配布します。

運用管理ポータルで，各実行系の論理サーバを起動します。

この例では，シェルスクリプトファイル（start.sh）の中で実行系の論理サーバを起動しないため，運用管理ポータルを使用して論理サーバを起動してください。

サーバ管理コマンドを使用して，Node1〜Node4の各実行系のJ2EEサーバにJ2EEアプリケーションとリソースアダプタをインポートします。また，インポートしたJ2EEアプリケーションとリソースアダプタを設定および開始します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

なお，J2EEサーバおよびその前提プロセスを起動してからサーバ管理コマンドを実行してください。また，サーバ管理コマンドでの操作が終わったら，サーバ管理コマンドを停止させてください。

19.6　N:1リカバリシステムの起動と停止（Windowsの場合）

この節では，N:1リカバリシステムを利用する場合の，システムの起動と停止の手順について説明します。

N:1リカバリシステムを利用して運用する場合は，あらかじめ現用系と予備系の2種類のホストの用意や，クラスタサービスの対象となる運用管理エージェントを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「19.4　N:1リカバリシステムの設定（Windowsの場合）」を参照してください。

ポイント

N:1リカバリシステムを利用する場合，Management Serverは運用管理サーバで起動します。なお，個々のアプリケーションサーバのホストでは，運用管理エージェントをOS起動と同時に起動する設定にしないでください。

参考

動作中の系を区別する場合，「実行系」と「待機系」の2種類の系に分けられます。

実行系

業務処理を実行するN台のアプリケーションサーバがある系のことです。

待機系

1台のリカバリ専用サーバがある系のことです。

19.6.1　N:1リカバリシステムの起動

ここではN:1リカバリシステムを利用する場合のシステムの起動手順について説明します。

Ｎ:1リカバリシステムを利用するには，あらかじめ運用管理サーバを起動しておくことが必要です。運用管理サーバを起動していない場合には，運用管理サーバを先に起動しておいてください。運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

また，N:1リカバリシステムでは，先に起動したノードが実行系ノードとして，あとに起動したノードが待機系ノードとして動作します。必ず現用系ノードを予備系ノードよりも先に起動してください。

N:1リカバリシステムの起動手順を次に示します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

選択した現用系ノードのクラスタサービスが開始されます。すべての現用行系ノードに対して実行してください。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの開始］を選択します。

予備系ノードのクラスタサービスが開始されます。

コンソールツリー（左ペイン）で現用系ノードおよび予備系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オンラインにする］を選択します。

選択したリソースグループがオンラインになります。すべてのリソースグループに対して実行してください。

実行系のホストの各論理サーバを起動します。

起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

19.6.2　N:1リカバリシステムの停止

ここでは，N:1リカバリシステムの停止方法について説明します。

［スタート］メニューの［コントロールパネル］−［パフォーマンスとメンテナンス］−［管理ツール］から，［クラスタ アドミニストレータ］を選択します。

クラスタアドミニストレータが開始されます。

コンソールツリー（左ペイン）で実行系ノードおよび待機系ノードが含まれているリソースグループを選択して，［ファイル］メニューの［オフラインにする］を選択します。

選択したリソースグループがオフラインになります。すべてのリソースグループに対して実行してください。

コンソールツリー（左ペイン）で予備系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

予備系ノードのクラスタサービスが停止します。

コンソールツリー（左ペイン）で現用系ノードを選択し，［ファイル］メニューの［クラスタサービスの停止］を選択します。

選択した現用系ノードのクラスタサービスが停止します。すべての現用系ノードに対して実行してください。

なお，運用管理サーバは最後に手動で停止します。運用管理サーバの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

19.7　N:1リカバリシステムの起動と停止（UNIXの場合）

この節では，HAモニタによるN:1リカバリシステムを利用する場合の，システムの起動と停止の手順について説明します。なお，HAモニタが利用できるのは，AIXまたはLinuxの場合だけです。

HAモニタによるN:1リカバリシステムを利用して運用する場合は，あらかじめ実行系と待機系の2種類のホストの用意や，HAモニタの監視の対象となる運用管理エージェントを監視・起動・停止するスクリプトの登録など，必要な環境設定をしておく必要があります。設定方法については，「19.5　N:1リカバリシステムの設定（UNIXの場合）」を参照してください。

ポイント

HAモニタによるN:1リカバリシステムを利用する場合，Management Serverは運用管理サーバで起動して，個々のアプリケーションサーバのホストでは，運用管理エージェントだけを起動します。なお，個々のアプリケーションサーバのホストでは，運用管理エージェントをOS起動と同時に起動する設定にしないでください。

また，次のコマンドは，HAモニタが提供しているコマンドです。詳細は，マニュアル「高信頼化システム監視機能　HAモニタ」を参照してください。

monbegin（HAモニタとのインタフェースを持たないサーバを起動）

monend（HAモニタとのインタフェースを持たない実行サーバの停止連絡）

参考

HAモニタの動作中の系を区別する場合，「実行系」と「待機系」の2種類の系に分けられます。

実行系

業務処理を実行するN台のアプリケーションサーバがある系のことです。

待機系

1台のリカバリ専用サーバがある系のことです。

19.7.1　N:1リカバリシステムの起動

HAモニタによるN:1リカバリシステムを利用する場合のシステム起動時の留意事項，およびシステムの起動手順について説明します。

(1)　システム起動時の留意事項

HAモニタによるN:1リカバリシステムを利用する場合のシステム起動時の留意事項を次に示します。

実行系と待機系のホストに配置されたHAモニタは，OSの起動と同時に起動されています。

運用管理サーバを起動していない場合は，運用管理サーバをあらかじめ起動しておいてください。運用管理サーバの起動方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

(2)　システムの起動手順

HAモニタによるN:1リカバリシステムを利用する場合のシステムの起動手順を次に示します。

待機系のホストで，各実行系に対応するmonbeginコマンドをN回実行します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されている実行系のサーバの識別名を指定します。

これによって，待機系のリカバリ専用サーバが実行系の監視を開始します。

実行系の各ホスト（N台）でmonbeginコマンドを実行して，実行系の各ホストの運用管理エージェントを起動します。

# monbegin サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，実行系の各ホストの運用管理エージェントが起動します。

注意事項

Management Server起動時に運用管理ドメイン内の論理サーバを一括起動する設定にしていない場合は，実行系のホストの論理サーバを起動してください。なお，Management Server起動時に運用管理ドメイン内の論理サーバを一括起動するように設定にしている場合，論理サーバの手動起動は不要です。起動方法については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「4.1.2　システムの起動方法」を参照してください。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「19.5.6　サーバ対応の環境設定」を参照してください。

19.7.2　N:1リカバリシステムの停止

HAモニタによるN:1リカバリシステムを利用する場合のシステムの停止手順を次に示します。

運用管理エージェントを停止するスクリプトで，運用管理ドメイン内の論理サーバを停止する設定にしていない場合は，実行系のホストで各論理サーバを停止します。

運用管理エージェントを停止するスクリプトで論理サーバを停止する設定にしている場合は，不要な手順です。論理サーバの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

実行系の各ホスト（N台）でmonendコマンドを実行して，実行系のホストの運用管理エージェントを停止します。

# monend サーバの識別名

下線部分には，serversファイルのオペランド「alias」に指定されているサーバの識別名を指定します。

これによって，実行系の各ホストの運用管理エージェントが停止します。

参考

serversファイルの定義（HAモニタでのサーバの環境設定）については，「19.5.6　サーバ対応の環境設定」を参照してください。

なお，運用管理サーバは最後に手動で停止します。運用管理サーバの停止方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」およびマニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.4　システムの停止方法」を参照してください。

付録

付録A　クラスタソフトウェア連携時のTPBrokerの設定（Windowsの場合）

クラスタソフトウェア（Windows Server Failover Cluster）を使用して，TPBrokerをクラスタ構成で運用することができます。

TPBrokerでは，系切り替えの要因として次のものに対応します。

ハードウェア障害などクラスタサービスによるシステム障害の検出

ユーザによる計画的な系切り替え

付録A.1　システムの起動と停止

システムの要求事項によって，系切り替えの構築に必要なTPBrokerの機能と環境設定項目を決定します。

まず，次の機能を使用するかどうかを決定してください。

ORB機能

OTS機能

また，OTS機能を使用する場合，共有ディスクを使用します。

(1)　ORB機能

スマートエージェントやスマートエージェントに接続するプロセスをクラスタソフトウェア（Windows Server Failover Cluster）で運用する場合は，ORB機能に関する各種IPアドレスを設定する必要があります。詳細については，「付録A.2　ORB機能使用時の設定」を参照してください。

なお，スマートエージェントに接続するプロセスとは，CORBAネーミングサービス，CTMデーモンおよびスマートエージェントを使用するJ2EEサーバ※のことです。

注※

usrconf.propertiesファイルのvbroker.agent.enableLocatorキーにtrueを指定してJ2EEサーバを起動している場合を指します。

(2)　OTS機能

トランザクションサービスはインプロセスで起動してください。

付録A.2　ORB機能使用時の設定

ここでは，ORB機能を使用する場合の設定について説明します。

この設定は，Windows Server Failover Clusterを起動するホスト上で次のプロセスを起動する場合に設定してください。

スマートエージェント

CORBAネーミングサービス

また，スマートエージェントをフェイルオーバの対象とする場合は，Windows Server Failover Clusterに「汎用アプリケーション」として登録してください。

(1)　スマートエージェントのlocaladdrファイルおよびhtc.clienthandleraddrファイルの設定

クラスタソフトウェア上でスマートエージェントを起動する場合，各ノードのlocaladdrファイルおよびhtc.clienthandleraddrファイルを設定してください。なお，設定内容は，マルチホームドホスト環境の場合とそれ以外の場合で異なります。

マルチホームドホスト環境，またはマルチホームドホストでないホスト環境上でクラスタ環境を構築する場合の，スマートエージェントのlocaladdrファイルの設定内容を次の表に示します。

表A‒1　スマートエージェントのlocaladdrファイルの設定内容

クラスタサービスおよびスマートエージェントを起動するホスト環境

スマートエージェントのlocaladdrファイルの設定内容

スマートエージェントをフェイルオーバの対象にする場合

スマートエージェントをフェイルオーバの対象にしない場合

マルチホームドホスト環境

ステーショナリIPアドレス（プライマリIPアドレス）

スマートエージェントに明示的に指定したいIPアドレス

クラスタIPアドレス

ステーショナリIPアドレス（プライマリIPアドレス）

スマートエージェントに明示的に指定したいIPアドレス

マルチホームドホストではないホスト環境

ステーショナリIPアドレス（プライマリIPアドレス）

クラスタIPアドレス

ステーショナリIPアドレス（プライマリIPアドレス）

次に，環境ごとの設定内容の詳細について説明します。また，htc.clienthandleraddrファイルについても説明します。

(a)　マルチホームドホスト環境

スマートエージェントをフェイルオーバの対象にする場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス），スマートエージェントに明示的に指定したいIPアドレス※，およびスマートエージェントが使用するクラスタIPアドレスを必ず設定してください。

また，スマートエージェントに接続するプロセスに対して，クラスタIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

スマートエージェントをフェイルオーバの対象にしない場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス），およびスマートエージェントに明示的に指定したいIPアドレス※を必ず設定してください。クラスタIPアドレスは設定しないでください。

また，スマートエージェントに接続するプロセスに対して，ステーショナリIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

注※

localaddrファイルを設定すると，スマートエージェントは，localaddrファイルに設定されたIPアドレスだけを認識します。localaddrファイルを設定しない場合，スマートエージェントはデフォルトでgethostbyname()から取得できるIPアドレスを認識します。

(b)　マルチホームドホストではないホスト環境

スマートエージェントをフェイルオーバの対象にする場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス）およびスマートエージェントが使用するクラスタIPアドレスを必ず設定してください。

また，スマートエージェントに接続するプロセスに対して，クラスタIPアドレスを返却するようにhtc.clienthandleraddrを定義してください。

スマートエージェントをフェイルオーバの対象にしない場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス）を必ず設定してください。クラスタIPアドレスは設定しないでください。

また，スマートエージェントに接続するプロセスに対して，ステーショナリIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

(2)　スマートエージェントまたはスマートエージェントに接続するプロセスのagentaddrファイル，vbroker.agent.addrプロパティ，および環境変数「OSAGENT_ADDR」の設定

異なるネットワークドメイン上にあるスマートエージェント間で通信をする場合，または異なるネットワークドメイン上にあるスマートエージェントとスマートエージェントに接続するプロセス間の通信をする場合は，スマートエージェントまたはスマートエージェントに接続するプロセスの設定が必要です。設定は，各ノードのagentaddrファイル，vbroker.agent.addrプロパティ，環境変数「OSAGENT_ADDR」に設定します。

(a)　スマートエージェントへの設定

異なるネットワークドメイン上のスマートエージェント間で通信していて，スマートエージェントをフェイルオーバの対象とする場合，対象のスマートエージェントと通信をするスマートエージェントのagentaddrファイルに，クラスタIPアドレスを必ず設定してください。

(b)　スマートエージェントに接続するプロセスへの設定

スマートエージェントとスマートエージェントに接続するプロセスとを異なるネットワークドメイン上で起動し，かつスマートエージェントをフェイルオーバの対象とする場合，スマートエージェントに接続するプロセスのagentaddrファイル，vbroker.agent.addrプロパティ，環境変数「OSAGENT_ADDR」のどれかに，フェイルオーバの対象となるスマートエージェントのクラスタIPアドレスを必ず設定してください。

(3)　CORBAネーミングサービスの設定

CORBAネーミングサービスをフェイルオーバの対象とする場合は，CORBAネーミングサービスの起動プロパティを設定します。

nameservコマンドに次の起動プロパティを設定してCORBAネーミングサービスを起動してください。

-J-Dvbroker.se.iiop_tp.host=クラスタIPアドレスまたはクラスタのネットワーク名

また，このプロパティに設定したクラスタIPアドレスまたはクラスタのネットワークを，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）の次のキーの設定内容に反映してください。

ejbserver.naming.hostキーに設定するIPアドレスまたはホスト名称

ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキーに設定するプロバイダURL

usrconf.propertiesの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。nameservコマンドを使用したCORBAネーミングサービスの起動については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録C.2　システムの起動方法」を参照してください。

(4)　J2EEサーバのvbroker.se.iiop_tp.hostキー，およびvbroker.se.iiop_tp.scm.iiop_tp.listener.portキーの設定

J2EEサーバをフェイルオーバの対象とする場合は，vbroker.se.iiop_tp.hostキーには，クラスタIPアドレスを指定してJ2EEサーバを起動してください。また，J2EEサーバが使用するポート番号は，すべての系で同じポート番号が使用できるように，usrconf.propertiesファイルのvbroker.se.iiop_tp.scm.iiop_tp.listener.portキーを使用して管理してください。

(5)　環境変数およびオプションの設定

クラスタ環境でスマートエージェントを起動する場合，スマートエージェントに次の環境変数およびオプションの設定が必要です。

オプションは，スマートエージェントをフェイルオーバの対象とする場合だけ指定してください。

環境変数名：OSAGENT_CLIENT_HANDLER_PORT

オプション：-m

なお，環境変数の設定方法については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」のVisiBroker ORBドメイン内の作業についての説明を参照してください。

(6)　設定例

IPアドレスの設定例を次に示します。

設定例1

図A‒1　スマートエージェントをフェイルオーバの対象にする場合のIPアドレスの設定例

図中の1.〜5.について説明します。

hostAのlocaladdrファイルに「hostAのステーショナリIPアドレス（A.A.A.A） subnet broadcast」，「クラスタIPアドレス（C.C.C.C） subnet broadcast」を記述します。

hostBのlocaladdrファイルに「hostBのステーショナリIPアドレス（B.B.B.B） subnet broadcast」，「クラスタIPアドレス（C.C.C.C） subnet broadcast」を記述します。

hostA，hostBのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet クラスタIPアドレス（C.C.C.C）」を記述します。

hostAおよびhostBで起動するスマートエージェントに環境変数「OSAGENT_CLIENT_HANDLER_PORT」および-mオプションを設定します。

hostCのagentaddrファイルにクラスタIPアドレス（C.C.C.C）を記述します。

設定例2

図A‒2　スマートエージェントをフェイルオーバの対象にしない場合のIPアドレスの設定例

図中の1.〜6.について説明します。

hostAのlocaladdrファイルに「hostAのステーショナリIPアドレス（A.A.A.A） subnet broadcast」を記述します。

hostBのlocaladdrファイルに「hostBのステーショナリIPアドレス（B.B.B.B） subnet broadcast」を記述します。

hostAのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet hostAのステーショナリIPアドレス（A.A.A.A）」を記述します。

hostBのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet hostBのステーショナリIPアドレス（B.B.B.B）」を記述します。

hostCのagentaddrファイルにA.A.A.AおよびB.B.B.Bを記述します。

hostAおよびhostBで起動するスマートエージェントに環境変数「OSAGENT_CLIENT_HANDLER_PORT」を設定します。

付録B　クラスタソフトウェア連携時のTPBrokerの設定（UNIXの場合）

クラスタソフトウェア（HAモニタ）を使用して，TPBrokerをクラスタ構成で運用することができます。

TPBrokerでは，系切り替えの要因として次のものに対応します。

ハードウェア障害などクラスタサービスによるシステム障害の検出

ユーザによる計画的な系切り替え

付録B.1　システムの起動と停止

システムの要求事項によって，系切り替えの構築に必要なTPBrokerの機能と環境設定項目を決定します。

まず，次の機能を使用するかどうかを決定してください。

ORB機能

OTS機能

また，OTS機能を使用する場合，共有ディスクを使用します。

(1)　ORB機能

スマートエージェントやスマートエージェントに接続するプロセスをクラスタソフトウェア（HAモニタ）で運用する場合は，ORB機能に関する各種IPアドレスを設定する必要があります。詳細については，「付録B.2　ORB機能使用時の設定」を参照してください。

なお，スマートエージェントに接続するプロセスとは，CORBAネーミングサービス，CTMデーモンおよびスマートエージェントを使用するJ2EEサーバ※のことです。

注※

usrconf.propertiesのvbroker.agent.enableLocatorキーにtrueを指定してJ2EEサーバを起動している場合を指します。

(2)　OTS機能

トランザクションサービスはインプロセスで起動してください。

(3)　クラスタ構成で運用するための留意点

TPBrokerをクラスタ構成で運用する場合，次の点に留意してください。

TPBrokerを含むプログラム群は各系のローカルディスクに格納してください。

すべての系のTPBrokerのバージョンを統一してください。

すべての系のTPBrokerのシステム環境定義を統一してください。

J2EEアプリケーションで使用するポート番号が固定の場合，すべての系で同じポート番号が使用できるように管理してください。

付録B.2　ORB機能使用時の設定

ここでは，ORB機能を使用する場合の設定について説明します。

この設定は，HAモニタを起動するホスト上で次のプロセスを起動する場合に設定してください。

スマートエージェント

CORBAネーミングサービス

(1)　スマートエージェントのlocaladdrファイルおよびhtc.clienthandleraddrファイルの設定

クラスタソフトウェア上でスマートエージェントを起動する場合，各ノードのlocaladdrファイルおよびhtc.clienthandleraddrファイルを設定してください。なお，設定内容は，マルチホームドホスト環境の場合とそれ以外の場合で異なります。

マルチホームドホスト環境，またはマルチホームドホストでないホスト環境上でクラスタ環境を構築する場合の，スマートエージェントのlocaladdrファイルの設定内容を次の表に示します。

表B‒1　スマートエージェントのlocaladdrファイルの設定内容

クラスタサービスおよびスマートエージェントを起動するホスト環境

スマートエージェントのlocaladdrファイルの設定内容

スマートエージェントを系切り替えの対象にする場合

スマートエージェントを系切り替えの対象にしない場合

マルチホームドホスト環境

ステーショナリIPアドレス（プライマリIPアドレス）

スマートエージェントに明示的に指定したいIPアドレス

エイリアスIPアドレス

ステーショナリIPアドレス（プライマリIPアドレス）

スマートエージェントに明示的に指定したいIPアドレス

マルチホームドホストではないホスト環境

ステーショナリIPアドレス（プライマリIPアドレス）

エイリアスIPアドレス

ステーショナリIPアドレス（プライマリIPアドレス）

次に，環境ごとの設定内容の詳細について説明します。また，htc.clienthandleraddrファイルについても説明します。

(a)　マルチホームドホスト環境

スマートエージェントを系切り替えの対象にする場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス），スマートエージェントに明示的に指定したいIPアドレス※，およびスマートエージェントが使用するエイリアスIPアドレスを必ず設定してください。

また，スマートエージェントに接続するプロセスに対して，エイリアスIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

スマートエージェントを系切り替えの対象にしない場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス），およびスマートエージェントに明示的に指定したいIPアドレス※を必ず設定してください。エイリアスIPアドレスは設定しないでください。

また，スマートエージェントに接続するプロセスに対して，ステーショナリIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

注※

localaddrファイルを設定すると，スマートエージェントは，localaddrファイルに設定されたIPアドレスだけを認識します。localaddrファイルを設定しない場合，スマートエージェントはデフォルトでgethostbyname()から取得できるIPアドレスを認識します。なお，スマートエージェントで認識するIPアドレスは，スマートエージェント起動時に，osagentコマンドに-vオプションを指定して，バーボースモードをオンにして起動することで確認できます。

(b)　マルチホームドホストではないホスト環境

スマートエージェントを系切り替えの対象にする場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス）およびスマートエージェントが使用するエイリアスIPアドレスを必ず設定してください。

また，スマートエージェントに接続するプロセスに対して，エイリアスIPアドレスを返却するようにhtc.clienthandleraddrを定義してください。

スマートエージェントを系切り替えの対象にしない場合

localaddrファイルには，ステーショナリIPアドレス（プライマリIPアドレス）を必ず設定してください。エイリアスIPアドレスは設定しないでください。

また，スマートエージェントに接続するプロセスに対して，ステーショナリIPアドレスを返却するようにhtc.clienthandleraddrファイルを定義してください。

(2)　スマートエージェントまたはスマートエージェントに接続するプロセスのagentaddrファイル，vbroker.agent.addrプロパティ，および環境変数「OSAGENT_ADDR」の設定

異なるネットワークドメイン上にあるスマートエージェント間で通信をする場合，または異なるネットワークドメイン上にあるスマートエージェントとスマートエージェントに接続するプロセス間の通信をする場合は，スマートエージェントまたはスマートエージェントに接続するプロセスの設定が必要です。設定は，各ノードのagentaddrファイル，vbroker.agent.addrプロパティ，環境変数「OSAGENT_ADDR」に設定します。

(a)　スマートエージェントへの設定

異なるネットワークドメイン上のスマートエージェント間通信で，スマートエージェントを系切り替えの対象とする場合，対象のスマートエージェントと通信をするスマートエージェントのagentaddrファイルに，エイリアスIPアドレスを必ず設定してください。

(b)　スマートエージェントに接続するプロセスへの設定

スマートエージェントとスマートエージェントに接続するプロセスとを異なるネットワークドメイン上で起動し，かつスマートエージェントを系切り替えの対象とする場合，スマートエージェントに接続するプロセスのagentaddrファイル，vbroker.agent.addrプロパティ，環境変数「OSAGENT_ADDR」のどれかに，系切り替えの対象となるスマートエージェントのエイリアスIPアドレスを必ず設定してください。

(3)　CORBAネーミングサービスの設定

CORBAネーミングサービスを系切り替えの対象とする場合は，CORBAネーミングサービスの起動プロパティを設定します。

nameservコマンドに次の起動プロパティを設定してCORBAネーミングサービスを起動してください。

-J-Dvbroker.se.iiop_tp.host=エイリアスIPアドレスまたはエイリアスホスト名

また，このプロパティに設定したエイリアスIPアドレスまたはエイリアスホスト名を，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）の次のキーの設定内容に反映してください。

ejbserver.naming.hostキーに設定するIPアドレスまたはホスト名称

ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキーに設定するプロバイダURL

usrconf.propertiesの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。nameservコマンドを使用したCORBAネーミングサービスの起動については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録C.2　システムの起動方法」を参照してください。

(4)　J2EEサーバのvbroker.se.iiop_tp.hostキー，およびvbroker.se.iiop_tp.scm.iiop_tp.listener.portキーの設定

J2EEサーバをフェイルオーバの対象とする場合は，vbroker.se.iiop_tp.hostキーには，クラスタIPアドレスを指定してJ2EEサーバを起動してください。また，J2EEサーバが使用するポート番号は，すべての系で同じポート番号が使用できるように，usrconf.propertiesファイルのvbroker.se.iiop_tp.scm.iiop_tp.listener.portキーを使用して管理してください。

(5)　環境変数の設定

クラスタ環境でスマートエージェントを起動する場合，スマートエージェントに次の環境変数の設定が必要です。

環境変数名：OSAGENT_CLIENT_HANDLER_PORT

なお，環境変数の設定方法については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」のVisiBroker ORBドメイン内の作業についての説明を参照してください。

(6)　設定例

IPアドレスの設定例を次に示します。

設定例1

図B‒1　スマートエージェントを系切り替えの対象にする場合のIPアドレスの設定例

図中の1.〜5.について説明します。

hostAのlocaladdrファイルに「hostAのステーショナリIPアドレス（A.A.A.A） subnet broadcast」，「エイリアスIPアドレス（C.C.C.C） subnet broadcast」を記述します。

hostBのlocaladdrファイルに「hostBのステーショナリIPアドレス（B.B.B.B） subnet broadcast」，「エイリアスIPアドレス（C.C.C.C） subnet broadcast」を記述します。

hostA，hostBのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet エイリアスIPアドレス（C.C.C.C）」を記述します。

hostAおよびhostBで起動するスマートエージェントに環境変数「OSAGENT_CLIENT_HANDLER_PORT」を設定します。

hostCのagentaddrファイルにエイリアスIPアドレス（C.C.C.C）を記述します。

設定例2

図B‒2　スマートエージェントを系切り替えの対象にしない場合のIPアドレスの設定例

図中の1.〜6.について説明します。

hostAのlocaladdrファイルに「hostAのステーショナリIPアドレス（A.A.A.A） subnet broadcast」を記述します。

hostBのlocaladdrファイルに「hostBのステーショナリIPアドレス（B.B.B.B） subnet broadcast」を記述します。

hostAのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet hostAのステーショナリIPアドレス（A.A.A.A）」を記述します。

hostBのhtc.clienthandleraddrファイルに「クライアントのステーショナリIPアドレス（F.F.F.F） subnet hostBのステーショナリIPアドレス（B.B.B.B）」を記述します。

hostCのagentaddrファイルにA.A.A.AおよびB.B.B.Bを記述します。

hostAおよびhostBで起動するスマートエージェントに環境変数「OSAGENT_CLIENT_HANDLER_PORT」を設定します。

付録C　保護区リストの内容

保護区リストの内容を次に示します。

#
# DO NOT EDIT THIS FILE.
#
# All Rights Reserved. Copyright (C) 2004, 2015, Hitachi, Ltd.

#---------------------------------------------------------------------
# Cosminexus Component Container
#---------------------------------------------------------------------
com.hitachi.software.auditlog.*
com.hitachi.software.ejb.*
com.hitachi.software.jpa.*
com.sun.ejb.*
com.sun.enterprise.*
com.sun.web.*
com.sun.activation.*
com.sun.mail.*

com.hitachi.software.javamail.*
com.hitachi.software.web.*
com.hitachi.software.was.logger.*
com.hitachi.software.was.tracer.*
com.hitachi.software.was.web.*
com.hitachi.software.was.sfo.*
org.apache.ajp.*
org.apache.catalina.*
org.apache.coyote.*
org.apache.jasper.*
org.apache.jk.*
org.apache.naming.*
org.apache.tomcat.*

com.cosminexus.cc.lib.*

#---------------------------------------------------------------------
# HiRDB Type4 JDBC Driver
#---------------------------------------------------------------------
JP.co.Hitachi.soft.HiRDB.JDBC.*

#---------------------------------------------------------------------
# Oracle JDBC Thin Driver
#---------------------------------------------------------------------
oracle.*

#---------------------------------------------------------------------
# DB2 Universal JDBC Driver
#---------------------------------------------------------------------
com.ibm.db2.*
COM.ibm.db2.*
COM.ibm.db2os390.*
sqlj.runtime.*

#---------------------------------------------------------------------
# Microsoft SQL Server JDBC Driver
#---------------------------------------------------------------------
com.microsoft.sqlserver.jdbc.*
microsoft.sql.*

#---------------------------------------------------------------------
# PostgreSQL JDBC Driver
#---------------------------------------------------------------------
org.postgresql.*

#---------------------------------------------------------------------
# MySQL Connector/J
#---------------------------------------------------------------------
com.mysql.*
org.gjt.mm.mysql.*

#---------------------------------------------------------------------
# HNTRLib
#---------------------------------------------------------------------
jp.co.hitachi.soft.hntrlib2.*
jp.co.hitachi.soft.hntrlibM.*

#---------------------------------------------------------------------
# Cosminexus TPBroker(ORB)
#---------------------------------------------------------------------
com.inprise.vbroker.*
com.borland.security.*
com.borland.vbroker.*
org.omg.BiDirPolicy.*
org.omg.CORBA.*
org.omg.CORBA_2_3.*
org.omg.CosEventChannelAdmin.*
org.omg.CosEventComm.*
org.omg.CosNaming.*
org.omg.CosNotification.*
org.omg.CosNotifyChannelAdmin.*
org.omg.CosNotifyComm.*
org.omg.CosNotifyFilter.*
org.omg.CosTransactions.*
org.omg.CosTypedEventChannelAdmin.*
org.omg.CosTypedEventComm.*
org.omg.CosTypedNotifyChannelAdmin.*
org.omg.CosTypedNotifyComm.*
org.omg.Dynamic.*
org.omg.DynamicAny.*
org.omg.Firewall.*
org.omg.IOP.*
org.omg.MessageRouting.*
org.omg.Messaging.*
org.omg.PortableInterceptor.*
org.omg.PortableServer.*
org.omg.SendingContext.*
org.omg.TimeBase.*
javax.rmi.*

#---------------------------------------------------------------------
# Cosminexus TPBroker(OTS)
#---------------------------------------------------------------------
COM.Hitachi.software.TPBroker.OTS.*
COM.Hitachi.software.TPBroker.otsinprocess.*
org.omg.CosTransactions.*
org.omg.CosTSInteroperation.*

#---------------------------------------------------------------------
# Cosminexus Performance Tracer
#---------------------------------------------------------------------
com.hitachi.software.ejb.prf.*
com.hitachi.software.ejb.ctm.*
JP.co.Hitachi.soft.CPRF.*

#---------------------------------------------------------------------
# Cosminexus Manager
#---------------------------------------------------------------------
com.cosminexus.mngsvr.*
com.cosminexus.admin.*
com.cosminexus.manager.*

#---------------------------------------------------------------------
# Cosminexus DABroker Library
#---------------------------------------------------------------------
JP.co.Hitachi.soft.DBPSV_Driver.*

#---------------------------------------------------------------------
# Cosminexus Component Library
#---------------------------------------------------------------------
com.cosminexus.cwc.*

#---------------------------------------------------------------------
# TP1/Message Queue - Access
#---------------------------------------------------------------------
jp.co.Hitachi.soft.mqadaptor.*

#---------------------------------------------------------------------
# Cosminexus Reliable Messaging
#---------------------------------------------------------------------
jp.co.Hitachi.soft.reliablemessaging.*
jp.co.Hitachi.soft.reliablemessaging_np.*

#---------------------------------------------------------------------
# Cosminexus TP1 Connector
#---------------------------------------------------------------------
jp.co.hitachi_system.tp1connector.*
JP.co.Hitachi.soft.OpenTP1.*

#---------------------------------------------------------------------
# Cosminexus Service Coordinator
#---------------------------------------------------------------------
jp.co.Hitachi.soft.csc.*
jp.co.Hitachi.soft.csciw.*
com.cosminexus.ftp.*
com.cosminexus.csc.monitor.*

#---------------------------------------------------------------------
# Cosminexus SOAP
#---------------------------------------------------------------------
com.cosminexus.cws.*
com.cosminexus.c4web.*
org.apache.axis.types.*
org.apache.commons.discovery.tools.*
javax.xml.soap.*
javax.xml.rpc.*

#---------------------------------------------------------------------
# Cosminexus Web Services - Security
#---------------------------------------------------------------------
com.cosminexus.wss.*

#---------------------------------------------------------------------
# Cosminexus JAX-WS(CJW)
#---------------------------------------------------------------------
com.cosminexus.xml.ws.*
com.cosminexus.tools.ws.*
com.cosminexus.istack.ws.*
com.cosminexus.org.jvnet.fastinfoset.*
com.cosminexus.xml.fastinfoset.*
com.cosminexus.org.apache.xml.internal.resolver.*
com.cosminexus.xml.messaging.saaj.*
com.cosminexus.xml.stream.buffer.*
org.jvnet.mimepull.*
com.cosminexus.org.glassfish.external.*
com.cosminexus.org.glassfish.gmbal.*
javax.xml.ws.*
com.sun.xml.ws.*
com.cosminexus.wsrm.*
com.cosminexus.wsit.*

#---------------------------------------------------------------------
# Cosminexus JAX-RS(CJR)
#---------------------------------------------------------------------
com.cosminexus.jersey.*
com.cosminexus.ws.rs.*
com.sun.research.ws.wadl.*
com.cosminexus.org.codehaus.jackson.*
com.cosminexus.org.codehaus.jettison.*
javax.ws.rs.*

#---------------------------------------------------------------------
# uCosminexus Hitachi Code Conversion
#---------------------------------------------------------------------
JP.co.Hitachi.soft.codeconv.*

#---------------------------------------------------------------------
# Cosminexus JMS Provider
#---------------------------------------------------------------------
com.cosminexus.jmsprovider.*

#---------------------------------------------------------------------
# Cosminexus JSF/JSTL/BV
#---------------------------------------------------------------------
javax.faces.*
com.sun.faces.*
com.hitachi.software.faces.*
org.apache.taglibs.*
org.hibernate.validator.*

#---------------------------------------------------------------------
# uCosminexus Elastic Application Data Store
#---------------------------------------------------------------------
com.hitachi.software.eads.*

#---------------------------------------------------------------------
# Cosminexus CDI
#---------------------------------------------------------------------
com.hitachi.software.cdi.*

#---------------------------------------------------------------------
# J2SE
#---------------------------------------------------------------------
JP.co.Hitachi.soft.jvm.*
com.sun.corba.se.*
com.sun.crypto.provider.*
com.sun.image.*
com.sun.imageio.*
com.sun.inputmethods.internal.indicim.DevanagariInputMethodDescriptor
com.sun.inputmethods.internal.thaiim.ThaiInputMethodDescriptor
com.sun.java.browser.dom.DOMService
com.sun.java.swing.*
com.sun.java.util.jar.pack.Attribute
com.sun.java.util.jar.pack.Coding
com.sun.java.util.jar.pack.ConstantPool
com.sun.java.util.jar.pack.Constants
com.sun.java.util.jar.pack.Instruction
com.sun.java.util.jar.pack.NativeUnpack
com.sun.jdi.Bootstrap
com.sun.jlex.internal.Main
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor
com.sun.jmx.mbeanserver.BaseMetaDataImpl
com.sun.jmx.mbeanserver.ClassLoaderRepositorySupport
com.sun.jmx.mbeanserver.DynamicMetaDataImpl
com.sun.jmx.mbeanserver.JmxMBeanServer
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl
com.sun.jmx.mbeanserver.MetaDataImpl
com.sun.jmx.mbeanserver.RepositorySupport
com.sun.jmx.mbeanserver.StandardMBeanMetaDataImpl
com.sun.jmx.mbeanserver.StandardMetaDataImpl
com.sun.jmx.remote.internal.ArrayNotificationBuffer
com.sun.jmx.remote.internal.ClientCommunicatorAdmin
com.sun.jmx.remote.internal.ClientCommunicatorAdmin$Checker
com.sun.jmx.remote.internal.ClientNotifForwarder
com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor
com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher
com.sun.jmx.remote.internal.ServerCommunicatorAdmin
com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout
com.sun.jmx.remote.internal.ServerNotifForwarder
com.sun.jmx.remote.security.MBeanServerFileAccessController
com.sun.jmx.remote.security.SubjectDelegator
com.sun.jmx.remote.util.ClassLogger
com.sun.jmx.remote.util.EnvHelp
com.sun.jmx.snmp.IPAcl.ASCII_CharStream
com.sun.jmx.snmp.IPAcl.Parser
com.sun.jmx.snmp.IPAcl.SnmpAcl
com.sun.jmx.snmp.SnmpCounter64
com.sun.jmx.snmp.SnmpInt
com.sun.jmx.snmp.SnmpNull
com.sun.jmx.snmp.SnmpOid
com.sun.jmx.snmp.SnmpOidTableSupport
com.sun.jmx.snmp.SnmpParameters
com.sun.jmx.snmp.SnmpPeer
com.sun.jmx.snmp.SnmpString
com.sun.jmx.snmp.SnmpVarBind
com.sun.jmx.snmp.SnmpVarBindList
com.sun.jmx.snmp.Timestamp
com.sun.jmx.snmp.agent.SnmpMibTable
com.sun.jmx.snmp.agent.SnmpTableSupport
com.sun.jmx.snmp.daemon.CommunicatorServer
com.sun.jmx.snmp.daemon.SendQ
com.sun.jmx.snmp.daemon.SnmpAdaptorServer
com.sun.jmx.snmp.daemon.SnmpInformRequest
com.sun.jmx.snmp.daemon.SnmpRequestCounter
com.sun.jmx.snmp.daemon.SnmpResponseHandler
com.sun.jmx.snmp.daemon.SnmpSendServer
com.sun.jmx.snmp.daemon.SnmpSession
com.sun.jmx.snmp.daemon.SnmpSocket
com.sun.jmx.snmp.daemon.SnmpTimerServer
com.sun.jmx.snmp.daemon.WaitQ
com.sun.jmx.snmp.internal.SnmpEngineImpl
com.sun.jmx.snmp.tasks.ThreadService
com.sun.jmx.snmp.tasks.ThreadService$ExecutorThread
com.sun.jmx.trace.Trace
com.sun.jndi.dns.DnsClient
com.sun.jndi.dns.DnsContext
com.sun.jndi.dns.ZoneNode
com.sun.jndi.ldap.Connection
com.sun.jndi.ldap.EventQueue
com.sun.jndi.ldap.EventSupport
com.sun.jndi.ldap.LdapClient
com.sun.jndi.ldap.LdapCtx
com.sun.jndi.ldap.LdapRequest
com.sun.jndi.ldap.LdapSchemaCtx$SchemaInfo
com.sun.jndi.ldap.pool.ConnectionDesc
com.sun.jndi.ldap.pool.Connections
com.sun.jndi.ldap.pool.Pool
com.sun.jndi.ldap.pool.PoolCleaner
com.sun.jndi.toolkit.corba.CorbaUtils
com.sun.management.OSMBeanFactory
com.sun.management.OperatingSystem
com.sun.management.jmx.Introspector
com.sun.media.*
com.sun.naming.internal.FactoryEnumeration
com.sun.naming.internal.ResourceManager
com.sun.org.apache.bcel.internal.Constants
com.sun.org.apache.bcel.internal.util.ClassLoader
com.sun.org.apache.bcel.internal.util.InstructionFinder
com.sun.org.apache.bcel.internal.verifier.NativeVerifier
com.sun.org.apache.bcel.internal.verifier.VerifierAppFrame
com.sun.org.apache.bcel.internal.verifier.VerifierFactoryListModel
com.sun.org.apache.bcel.internal.verifier.VerifyDialog
com.sun.org.apache.bcel.internal.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor
com.sun.org.apache.html.internal.dom.HTMLBuilder
com.sun.org.apache.html.internal.dom.HTMLCollectionImpl
com.sun.org.apache.html.internal.dom.HTMLDocumentImpl
com.sun.org.apache.html.internal.dom.HTMLTableElementImpl
com.sun.org.apache.html.internal.dom.ObjectFactory
com.sun.org.apache.regexp.internal.REDemo
com.sun.org.apache.regexp.internal.RETest
com.sun.org.apache.regexp.internal.recompile
com.sun.org.apache.xalan.internal.client.XSLTProcessorApplet
com.sun.org.apache.xalan.internal.client.XSLTProcessorApplet$TrustedAgent
com.sun.org.apache.xalan.internal.lib.ExsltStrings
com.sun.org.apache.xalan.internal.lib.Extensions
com.sun.org.apache.xalan.internal.lib.ObjectFactory
com.sun.org.apache.xalan.internal.xslt.ObjectFactory
com.sun.org.apache.xalan.internal.xslt.Process
com.sun.org.apache.xalan.internal.xsltc.cmdline.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.compiler.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC
com.sun.org.apache.xalan.internal.xsltc.compiler.util.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.dom.DocumentCache
com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.runtime.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.trax.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesHandlerImpl
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
com.sun.org.apache.xerces.internal.dom.CoreDOMImplementationImpl
com.sun.org.apache.xerces.internal.dom.ObjectFactory
com.sun.org.apache.xerces.internal.impl.XMLEntityManager
com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory
com.sun.org.apache.xerces.internal.impl.dv.ObjectFactory
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory
com.sun.org.apache.xerces.internal.impl.dv.xs.AbstractDateTimeDV$DateTimeData
com.sun.org.apache.xerces.internal.impl.dv.xs.Base64BinaryDV$XBase64
com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV$XDecimal
com.sun.org.apache.xerces.internal.impl.dv.xs.DoubleDV$XDouble
com.sun.org.apache.xerces.internal.impl.dv.xs.FloatDV$XFloat
com.sun.org.apache.xerces.internal.impl.dv.xs.HexBinaryDV$XHex
com.sun.org.apache.xerces.internal.impl.dv.xs.ListDV$ListData
com.sun.org.apache.xerces.internal.impl.dv.xs.QNameDV$XQName
com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl
com.sun.org.apache.xerces.internal.impl.xpath.regex.Match
com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema
com.sun.org.apache.xerces.internal.impl.xpath.regex.REUtil
com.sun.org.apache.xerces.internal.impl.xpath.regex.RangeToken
com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser
com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression
com.sun.org.apache.xerces.internal.impl.xpath.regex.Token
com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar
com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$BuiltinSchemaGrammar
com.sun.org.apache.xerces.internal.impl.xs.XSAnnotationImpl
com.sun.org.apache.xerces.internal.impl.xs.XSComplexTypeDecl
com.sun.org.apache.xerces.internal.impl.xs.XSModelImpl
com.sun.org.apache.xerces.internal.impl.xs.util.XSNamedMap4Types
com.sun.org.apache.xerces.internal.impl.xs.util.XSNamedMapImpl
com.sun.org.apache.xerces.internal.parsers.CachingParserPool$SynchronizedGrammarPool
com.sun.org.apache.xerces.internal.parsers.JAXPConfiguration
com.sun.org.apache.xerces.internal.parsers.ObjectFactory
com.sun.org.apache.xerces.internal.util.SynchronizedSymbolTable
com.sun.org.apache.xerces.internal.util.XMLGrammarPoolImpl
com.sun.org.apache.xerces.internal.xinclude.ObjectFactory
com.sun.org.apache.xml.internal.dtm.DTMException
com.sun.org.apache.xml.internal.dtm.DTMManager
com.sun.org.apache.xml.internal.dtm.FactoryFinder
com.sun.org.apache.xml.internal.dtm.ObjectFactory
com.sun.org.apache.xml.internal.dtm.ref.CoroutineManager
com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault
com.sun.org.apache.xml.internal.dtm.ref.DTMSafeStringPool
com.sun.org.apache.xml.internal.dtm.ref.ObjectFactory
com.sun.org.apache.xml.internal.serialize.ObjectFactory
com.sun.org.apache.xml.internal.serialize.OutputFormat
com.sun.org.apache.xml.internal.serialize.SerializerFactory
com.sun.org.apache.xml.internal.serializer.CharInfo
com.sun.org.apache.xml.internal.serializer.ObjectFactory
com.sun.org.apache.xml.internal.serializer.OutputPropertiesFactory
com.sun.org.apache.xml.internal.serializer.ToHTMLStream
com.sun.org.apache.xml.internal.serializer.ToStream
com.sun.org.apache.xml.internal.utils.ObjectFactory
com.sun.org.apache.xml.internal.utils.ObjectPool
com.sun.org.apache.xml.internal.utils.StringBufferPool
com.sun.org.apache.xml.internal.utils.XMLReaderManager
com.sun.org.apache.xpath.internal.VariableStack
com.sun.org.apache.xpath.internal.axes.IteratorPool
com.sun.org.apache.xpath.internal.compiler.Compiler
com.sun.org.apache.xpath.internal.compiler.ObjectFactory
com.sun.org.apache.xpath.internal.functions.ObjectFactory
com.sun.org.omg.CORBA.AttrDescriptionSeqHelper
com.sun.org.omg.CORBA.AttributeDescriptionHelper
com.sun.org.omg.CORBA.AttributeModeHelper
com.sun.org.omg.CORBA.ContextIdSeqHelper
com.sun.org.omg.CORBA.ContextIdentifierHelper
com.sun.org.omg.CORBA.DefinitionKindHelper
com.sun.org.omg.CORBA.ExcDescriptionSeqHelper
com.sun.org.omg.CORBA.ExceptionDescriptionHelper
com.sun.org.omg.CORBA.IDLTypeHelper
com.sun.org.omg.CORBA.IdentifierHelper
com.sun.org.omg.CORBA.InitializerHelper
com.sun.org.omg.CORBA.InitializerSeqHelper
com.sun.org.omg.CORBA.OpDescriptionSeqHelper
com.sun.org.omg.CORBA.OperationDescriptionHelper
com.sun.org.omg.CORBA.OperationModeHelper
com.sun.org.omg.CORBA.ParDescriptionSeqHelper
com.sun.org.omg.CORBA.ParameterDescriptionHelper
com.sun.org.omg.CORBA.ParameterModeHelper
com.sun.org.omg.CORBA.RepositoryHelper
com.sun.org.omg.CORBA.RepositoryIdHelper
com.sun.org.omg.CORBA.RepositoryIdSeqHelper
com.sun.org.omg.CORBA.StructMemberHelper
com.sun.org.omg.CORBA.StructMemberSeqHelper
com.sun.org.omg.CORBA.ValueDefPackage.FullValueDescriptionHelper
com.sun.org.omg.CORBA.ValueMemberHelper
com.sun.org.omg.CORBA.ValueMemberSeqHelper
com.sun.org.omg.CORBA.VersionSpecHelper
com.sun.org.omg.CORBA.VisibilityHelper
com.sun.org.omg.SendingContext.CodeBaseHelper
com.sun.org.omg.SendingContext.CodeBasePackage.URLHelper
com.sun.org.omg.SendingContext.CodeBasePackage.URLSeqHelper
com.sun.org.omg.SendingContext.CodeBasePackage.ValueDescSeqHelper
com.sun.rmi.rmid.ExecOptionPermission
com.sun.rmi.rmid.ExecPermission
com.sun.rowset.JdbcRowSetImpl
com.sun.rowset.JdbcRowSetResourceBundle
com.sun.rowset.internal.WebRowSetXmlReader
com.sun.security.*
com.sun.swing.*
com.sun.tools.apt.comp.Apt
com.sun.tools.apt.main.Main
com.sun.tools.corba.se.idl.som.cff.Messages
com.sun.tools.corba.se.idl.toJavaPortable.Factories
com.sun.tools.corba.se.idl.toJavaPortable.Helper
com.sun.tools.doclets.internal.toolkit.builders.LayoutParser
com.sun.tools.doclets.internal.toolkit.util.Util
com.sun.tools.example.debug.expr.ASCII_UCodeESC_CharStream
com.sun.tools.example.debug.expr.ExpressionParserConstants
com.sun.tools.example.debug.expr.ExpressionParserTokenManager
com.sun.tools.example.debug.expr.LValue
com.sun.tools.example.debug.tty.Commands
com.sun.tools.example.debug.tty.Env
com.sun.tools.example.debug.tty.EventHandler
com.sun.tools.example.debug.tty.EventRequestSpec
com.sun.tools.example.debug.tty.EventRequestSpecList
com.sun.tools.example.debug.tty.MessageOutput
com.sun.tools.example.debug.tty.TTYResources
com.sun.tools.example.debug.tty.TTYResources_ja
com.sun.tools.example.debug.tty.TTYResources_zh_CN
com.sun.tools.example.debug.tty.ThreadInfo
com.sun.tools.example.debug.tty.VMConnection
com.sun.tools.javac.code.Flags
com.sun.tools.javac.jvm.ByteCodes
com.sun.tools.javac.jvm.Code$Mneumonics
com.sun.tools.javac.main.Main
com.sun.tools.javac.parser.Tokens
com.sun.tools.javac.resources.compiler
com.sun.tools.javac.resources.compiler_ja
com.sun.tools.javac.tree.Pretty
com.sun.tools.javac.util.Name$Table
com.sun.tools.javadoc.Start
com.sun.tools.jdi.AbstractLauncher$Helper
com.sun.tools.jdi.EventQueueImpl
com.sun.tools.jdi.EventQueueImpl$TimerThread
com.sun.tools.jdi.EventRequestManagerImpl
com.sun.tools.jdi.EventRequestManagerImpl$ClassVisibleEventRequestImpl
com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl
com.sun.tools.jdi.EventRequestManagerImpl$ThreadVisibleEventRequestImpl
com.sun.tools.jdi.EventSetImpl
com.sun.tools.jdi.JNITypeParser
com.sun.tools.jdi.ObjectReferenceImpl
com.sun.tools.jdi.Packet
com.sun.tools.jdi.ReferenceTypeImpl
com.sun.tools.jdi.SharedMemoryConnection
com.sun.tools.jdi.SharedMemoryTransportService
com.sun.tools.jdi.SocketConnection
com.sun.tools.jdi.SocketTransportService
com.sun.tools.jdi.StackFrameImpl
com.sun.tools.jdi.TargetVM
com.sun.tools.jdi.TargetVM$EventController
com.sun.tools.jdi.ThreadReferenceImpl
com.sun.tools.jdi.VMState
com.sun.tools.jdi.VirtualMachineImpl
com.sun.tools.jdi.VirtualMachineManagerImpl
java.applet.*
java.awt.*
java.beans.BeansAppletContext
java.beans.DefaultPersistenceDelegate
java.beans.EventHandler
java.beans.EventSetDescriptor
java.beans.IndexedPropertyDescriptor
java.beans.Introspector
java.beans.MetaData
java.beans.MethodDescriptor
java.beans.PropertyChangeSupport
java.beans.PropertyDescriptor
java.beans.PropertyEditorManager
java.beans.PropertyEditorSupport
java.beans.ReflectionUtils
java.beans.VetoableChangeSupport
java.beans.beancontext.BeanContextChildSupport
java.beans.beancontext.BeanContextEvent
java.beans.beancontext.BeanContextServicesSupport
java.beans.beancontext.BeanContextServicesSupport$BCSSChild
java.beans.beancontext.BeanContextSupport
java.io.BufferedInputStream
java.io.BufferedOutputStream
java.io.BufferedReader
java.io.BufferedWriter
java.io.ByteArrayInputStream
java.io.ByteArrayOutputStream
java.io.CharArrayReader
java.io.CharArrayWriter
java.io.DataOutputStream
java.io.ExpiringCache
java.io.File
java.io.FileDescriptor
java.io.FileInputStream
java.io.FileOutputStream
java.io.FilePermissionCollection
java.io.FileSystem
java.io.FilterInputStream
java.io.IOException
java.io.InputStream
java.io.LineNumberReader
java.io.ObjectInputStream
java.io.ObjectInputStream$Caches
java.io.ObjectInputStream$CallbackContext
java.io.ObjectOutputStream
java.io.ObjectOutputStream$Caches
java.io.ObjectStreamClass
java.io.ObjectStreamClass$Caches
java.io.ObjectStreamClass$EntryFuture
java.io.OutputStream
java.io.PipedInputStream
java.io.PipedOutputStream
java.io.PipedReader
java.io.PipedWriter
java.io.PrintStream
java.io.PrintWriter
java.io.PushbackInputStream
java.io.PushbackReader
java.io.RandomAccessFile
java.io.Reader
java.io.Serializable
java.io.StringBufferInputStream
java.io.StringReader
java.io.Win32FileSystem
java.io.WinNTFileSystem
java.io.Writer
java.lang.AbstractMethodError
java.lang.ArithmeticException
java.lang.ArrayIndexOutOfBoundsException
java.lang.ArrayStoreException
java.lang.AssertionStatusDirectives
java.lang.Boolean
java.lang.Byte
java.lang.CharSequence
java.lang.Character
java.lang.Class
java.lang.ClassCastException
java.lang.ClassCircularityError
java.lang.ClassFormatError
java.lang.ClassLoader
java.lang.ClassLoader$NativeLibrary
java.lang.ClassNotFoundException
java.lang.CloneNotSupportedException
java.lang.Cloneable
java.lang.Compiler
java.lang.Double
java.lang.Error
java.lang.Exception
java.lang.ExceptionInInitializerError
java.lang.Float
java.lang.IllegalAccessError
java.lang.IllegalAccessException
java.lang.IllegalArgumentException
java.lang.IllegalMonitorStateException
java.lang.IllegalThreadStateException
java.lang.IncompatibleClassChangeError
java.lang.IndexOutOfBoundsException
java.lang.InstantiationError
java.lang.InstantiationException
java.lang.Integer
java.lang.InternalError
java.lang.InterruptedException
java.lang.InvalidClassException
java.lang.LinkageError
java.lang.Long
java.lang.Math
java.lang.NegativeArraySizeException
java.lang.NoClassDefFoundError
java.lang.NoSuchFieldError
java.lang.NoSuchFieldException
java.lang.NoSuchMethodError
java.lang.NoSuchMethodException
java.lang.NullPointerException
java.lang.Object
java.lang.OutOfMemoryError
java.lang.Package
java.lang.ProcessEnvironment
java.lang.ProcessImpl
java.lang.Runtime
java.lang.RuntimeException
java.lang.SecurityManager
java.lang.Short
java.lang.Shutdown
java.lang.StackOverflowError
java.lang.StackTraceElement
java.lang.StrictMath
java.lang.String
java.lang.StringBuffer
java.lang.StringIndexOutOfBoundsException
java.lang.System
java.lang.Thread
java.lang.ThreadDeath
java.lang.ThreadGroup
java.lang.ThreadLocal
java.lang.Throwable
java.lang.UnsatisfiedLinkError
java.lang.UnsupportedClassVersionError
java.lang.VerifyError
java.lang.management.ManagementFactory
java.lang.ref.FinalReference
java.lang.ref.Finalizer
java.lang.ref.Finalizer$3
java.lang.ref.PhantomReference
java.lang.ref.Reference
java.lang.ref.Reference$ReferenceHandler
java.lang.ref.ReferenceQueue
java.lang.ref.SoftReference
java.lang.ref.WeakReference
java.lang.reflect.AccessibleObject
java.lang.reflect.Array
java.lang.reflect.Constructor
java.lang.reflect.Field
java.lang.reflect.InvocationTargetException
java.lang.reflect.Method
java.lang.reflect.Modifier
java.lang.reflect.Proxy
java.math.BigDecimal
java.math.MathContext
java.net.Authenticator
java.net.CookieHandler
java.net.DatagramPacket
java.net.DatagramSocket
java.net.FactoryURLClassLoader
java.net.Inet4Address
java.net.Inet4AddressImpl
java.net.Inet6Address
java.net.Inet6AddressImpl
java.net.InetAddress
java.net.InetAddressImplFactory
java.net.MulticastSocket
java.net.NetworkInterface
java.net.PlainDatagramSocketImpl
java.net.PlainSocketImpl
java.net.ResponseCache
java.net.ServerSocket
java.net.Socket
java.net.SocketInputStream
java.net.SocketOutputStream
java.net.SocketPermission
java.net.SocketPermissionCollection
java.net.SocksSocketImpl
java.net.URL
java.net.URLConnection
java.net.URLStreamHandler
java.nio.Bits
java.nio.MappedByteBuffer
java.nio.channels.Channels
java.nio.channels.Channels$1
java.nio.channels.Channels$ReadableByteChannelImpl
java.nio.channels.Channels$WritableByteChannelImpl
java.nio.channels.spi.AbstractInterruptibleChannel
java.nio.channels.spi.AbstractInterruptibleChannel$1
java.nio.channels.spi.AbstractSelectableChannel
java.nio.channels.spi.AbstractSelectionKey
java.nio.channels.spi.AbstractSelector
java.nio.channels.spi.SelectorProvider
java.nio.charset.Charset
java.nio.charset.CoderResult$Cache
java.rmi.activation.ActivationGroup
java.rmi.server.LogStream
java.rmi.server.ObjID$InsecureRandom
java.rmi.server.RMISocketFactory
java.rmi.server.RemoteObjectInvocationHandler$MethodToHash_Maps$1
java.rmi.server.UID
java.security.*
java.sql.DriverManager
java.sql.SQLException
java.sql.Date
java.sql.Time
java.sql.Timestamp
java.sql.BatchUpdateException
java.sql.SQLWarning
java.text.AttributedString
java.text.AttributedString$AttributeMap
java.text.AttributedString$AttributedStringIterator
java.text.Bidi
java.text.BreakIterator
java.text.Collator
java.text.DecimalFormat
java.text.RuleBasedCollator
java.util.AbstractList
java.util.Calendar
java.util.Collections
java.util.Collections$SynchronizedCollection
java.util.Collections$SynchronizedList
java.util.Collections$SynchronizedMap
java.util.Collections$SynchronizedRandomAccessList
java.util.Collections$SynchronizedSet
java.util.Collections$SynchronizedSortedMap
java.util.Collections$SynchronizedSortedSet
java.util.Currency
java.util.Date
java.util.GregorianCalendar
java.util.Hashtable
java.util.Hashtable$Enumerator
java.util.ListResourceBundle
java.util.Locale
java.util.Observable
java.util.Properties
java.util.PropertyPermission
java.util.PropertyPermissionCollection
java.util.Random
java.util.ResourceBundle
java.util.SimpleTimeZone
java.util.Stack
java.util.TimeZone
java.util.TimeZone$DisplayNames
java.util.Timer
java.util.Timer$1
java.util.TimerTask
java.util.TimerThread
java.util.Vector
java.util.Vector$1
java.util.concurrent.*
java.util.jar.JarFile
java.util.jar.JarVerifier
java.util.jar.Pack200
java.util.logging.ErrorManager
java.util.logging.FileHandler
java.util.logging.Formatter
java.util.logging.Handler
java.util.logging.Level
java.util.logging.LogManager
java.util.logging.LogManager$Cleaner
java.util.logging.LogRecord
java.util.logging.Logger
java.util.logging.MemoryHandler
java.util.logging.SimpleFormatter
java.util.logging.SocketHandler
java.util.logging.StreamHandler
java.util.prefs.AbstractPreferences
java.util.prefs.AbstractPreferences$EventDispatchThread
java.util.prefs.WindowsPreferences
java.util.prefs.XmlSupport
java.util.regex.Pattern
java.util.zip.*
javax.imageio.*
javax.management.AttributeChangeNotificationFilter
javax.management.MBeanInfo
javax.management.MBeanServerDelegate
javax.management.MBeanServerFactory
javax.management.MBeanServerPermission
javax.management.MBeanServerPermissionCollection
javax.management.NotificationBroadcasterSupport
javax.management.NotificationFilterSupport
javax.management.ObjectName
javax.management.StandardMBean
javax.management.loading.MLet
javax.management.modelmbean.DescriptorSupport
javax.management.modelmbean.RequiredModelMBean
javax.management.monitor.CounterMonitor
javax.management.monitor.GaugeMonitor
javax.management.monitor.Monitor
javax.management.monitor.StringMonitor
javax.management.relation.MBeanServerNotificationFilter
javax.management.relation.RelationService
javax.management.relation.RelationSupport
javax.management.remote.JMXConnectorServer
javax.management.remote.rmi.RMIConnectionImpl
javax.management.remote.rmi.RMIConnector
javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin
javax.management.remote.rmi.RMIConnectorServer
javax.management.remote.rmi.RMIServerImpl
javax.management.timer.Timer
javax.naming.spi.NamingManager
javax.print.*
javax.rmi.ssl.SslRMIClientSocketFactory
javax.rmi.ssl.SslRMIServerSocketFactory
javax.security.*
javax.sound.*
javax.sql.ConnectionEvent
javax.sql.rowset.spi.SyncFactory
javax.swing.*
javax.xml.datatype.FactoryFinder
javax.xml.parsers.FactoryFinder
javax.xml.transform.FactoryFinder
javax.xml.transform.TransformerException
javax.xml.validation.SchemaFactoryFinder
javax.xml.xpath.XPathFactoryFinder
org.omg.CORBA.AnySeqHelper
org.omg.CORBA.BooleanSeqHelper
org.omg.CORBA.CharSeqHelper
org.omg.CORBA.CompletionStatusHelper
org.omg.CORBA.CurrentHelper
org.omg.CORBA.DefinitionKindHelper
org.omg.CORBA.DoubleSeqHelper
org.omg.CORBA.FieldNameHelper
org.omg.CORBA.FloatSeqHelper
org.omg.CORBA.IDLTypeHelper
org.omg.CORBA.IdentifierHelper
org.omg.CORBA.LongLongSeqHelper
org.omg.CORBA.LongSeqHelper
org.omg.CORBA.NameValuePairHelper
org.omg.CORBA.ORB
org.omg.CORBA.ObjectHelper
org.omg.CORBA.OctetSeqHelper
org.omg.CORBA.ParameterModeHelper
org.omg.CORBA.PolicyErrorCodeHelper
org.omg.CORBA.PolicyErrorHelper
org.omg.CORBA.PolicyHelper
org.omg.CORBA.PolicyListHelper
org.omg.CORBA.PolicyTypeHelper
org.omg.CORBA.RepositoryIdHelper
org.omg.CORBA.ServiceDetailHelper
org.omg.CORBA.ServiceInformationHelper
org.omg.CORBA.SetOverrideTypeHelper
org.omg.CORBA.ShortSeqHelper
org.omg.CORBA.StringSeqHelper
org.omg.CORBA.StringValueHelper
org.omg.CORBA.StructMemberHelper
org.omg.CORBA.ULongLongSeqHelper
org.omg.CORBA.ULongSeqHelper
org.omg.CORBA.UShortSeqHelper
org.omg.CORBA.UnionMemberHelper
org.omg.CORBA.UnknownUserExceptionHelper
org.omg.CORBA.ValueBaseHelper
org.omg.CORBA.ValueMemberHelper
org.omg.CORBA.VersionSpecHelper
org.omg.CORBA.VisibilityHelper
org.omg.CORBA.WCharSeqHelper
org.omg.CORBA.WStringSeqHelper
org.omg.CORBA.WStringValueHelper
org.omg.CORBA.WrongTransactionHelper
org.omg.CosNaming.BindingHelper
org.omg.CosNaming.BindingIteratorHelper
org.omg.CosNaming.BindingListHelper
org.omg.CosNaming.BindingTypeHelper
org.omg.CosNaming.IstringHelper
org.omg.CosNaming.NameComponentHelper
org.omg.CosNaming.NameHelper
org.omg.CosNaming.NamingContextExtHelper
org.omg.CosNaming.NamingContextExtPackage.AddressHelper
org.omg.CosNaming.NamingContextExtPackage.InvalidAddressHelper
org.omg.CosNaming.NamingContextExtPackage.StringNameHelper
org.omg.CosNaming.NamingContextExtPackage.URLStringHelper
org.omg.CosNaming.NamingContextHelper
org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper
org.omg.CosNaming.NamingContextPackage.CannotProceedHelper
org.omg.CosNaming.NamingContextPackage.InvalidNameHelper
org.omg.CosNaming.NamingContextPackage.NotEmptyHelper
org.omg.CosNaming.NamingContextPackage.NotFoundHelper
org.omg.CosNaming.NamingContextPackage.NotFoundReasonHelper
org.omg.DynamicAny.AnySeqHelper
org.omg.DynamicAny.DynAnyFactoryHelper
org.omg.DynamicAny.DynAnyFactoryPackage.InconsistentTypeCodeHelper
org.omg.DynamicAny.DynAnyHelper
org.omg.DynamicAny.DynAnyPackage.InvalidValueHelper
org.omg.DynamicAny.DynAnyPackage.TypeMismatchHelper
org.omg.DynamicAny.DynAnySeqHelper
org.omg.DynamicAny.DynArrayHelper
org.omg.DynamicAny.DynEnumHelper
org.omg.DynamicAny.DynFixedHelper
org.omg.DynamicAny.DynSequenceHelper
org.omg.DynamicAny.DynStructHelper
org.omg.DynamicAny.DynUnionHelper
org.omg.DynamicAny.DynValueHelper
org.omg.DynamicAny.FieldNameHelper
org.omg.DynamicAny.NameDynAnyPairHelper
org.omg.DynamicAny.NameDynAnyPairSeqHelper
org.omg.DynamicAny.NameValuePairHelper
org.omg.DynamicAny.NameValuePairSeqHelper
org.omg.IOP.CodecFactoryHelper
org.omg.IOP.CodecFactoryPackage.UnknownEncodingHelper
org.omg.IOP.CodecPackage.FormatMismatchHelper
org.omg.IOP.CodecPackage.InvalidTypeForEncodingHelper
org.omg.IOP.CodecPackage.TypeMismatchHelper
org.omg.IOP.ComponentIdHelper
org.omg.IOP.IORHelper
org.omg.IOP.MultipleComponentProfileHelper
org.omg.IOP.ProfileIdHelper
org.omg.IOP.ServiceContextHelper
org.omg.IOP.ServiceContextListHelper
org.omg.IOP.ServiceIdHelper
org.omg.IOP.TaggedComponentHelper
org.omg.IOP.TaggedProfileHelper
org.omg.Messaging.SyncScopeHelper
org.omg.PortableInterceptor.AdapterManagerIdHelper
org.omg.PortableInterceptor.AdapterNameHelper
org.omg.PortableInterceptor.AdapterStateHelper
org.omg.PortableInterceptor.CurrentHelper
org.omg.PortableInterceptor.ForwardRequestHelper
org.omg.PortableInterceptor.IORInterceptor_3_0Helper
org.omg.PortableInterceptor.InvalidSlotHelper
org.omg.PortableInterceptor.ORBIdHelper
org.omg.PortableInterceptor.ORBInitInfoPackage.DuplicateNameHelper
org.omg.PortableInterceptor.ORBInitInfoPackage.InvalidNameHelper
org.omg.PortableInterceptor.ORBInitInfoPackage.ObjectIdHelper
org.omg.PortableInterceptor.ObjectIdHelper
org.omg.PortableInterceptor.ObjectReferenceFactoryHelper
org.omg.PortableInterceptor.ObjectReferenceTemplateHelper
org.omg.PortableInterceptor.ObjectReferenceTemplateSeqHelper
org.omg.PortableInterceptor.ServerIdHelper
org.omg.PortableServer.CurrentHelper
org.omg.PortableServer.CurrentPackage.NoContextHelper
org.omg.PortableServer.ForwardRequestHelper
org.omg.PortableServer.POAHelper
org.omg.PortableServer.POAManagerPackage.AdapterInactiveHelper
org.omg.PortableServer.POAPackage.AdapterAlreadyExistsHelper
org.omg.PortableServer.POAPackage.AdapterNonExistentHelper
org.omg.PortableServer.POAPackage.InvalidPolicyHelper
org.omg.PortableServer.POAPackage.NoServantHelper
org.omg.PortableServer.POAPackage.ObjectAlreadyActiveHelper
org.omg.PortableServer.POAPackage.ObjectNotActiveHelper
org.omg.PortableServer.POAPackage.ServantAlreadyActiveHelper
org.omg.PortableServer.POAPackage.ServantNotActiveHelper
org.omg.PortableServer.POAPackage.WrongAdapterHelper
org.omg.PortableServer.POAPackage.WrongPolicyHelper
org.omg.PortableServer.ServantActivatorHelper
org.omg.PortableServer.ServantLocatorHelper
org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie
org.omg.stub.javax.management.remote.rmi._RMIConnection_Stub
org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie
org.omg.stub.javax.management.remote.rmi._RMIServer_Stub
sun.applet.*
sun.audio.*
sun.awt.*
sun.corba.Bridge
sun.dc.pr.*
sun.font.AdvanceCache
sun.font.CompositeFont
sun.font.FileFont
sun.font.FileFont$FileFontDisposer
sun.font.FileFontStrike
sun.font.Font2D
sun.font.FontFamily
sun.font.FontManager
sun.font.FontStrikeDisposer
sun.font.GlyphLayout
sun.font.GlyphList
sun.font.PhysicalStrike
sun.font.StrikeCache
sun.font.SunLayoutEngine
sun.font.TrueTypeFont
sun.font.TrueTypeFont$TTDisposerRecord
sun.font.Type1Font
sun.instrument.InstrumentationImpl
sun.instrument.TransformerManager
sun.io.CharacterEncoding
sun.io.Converters
sun.java2d.*
sun.jdbc.*
sun.jvmstat.monitor.MonitoredHost
sun.jvmstat.perfdata.monitor.PerfDataBufferImpl
sun.jvmstat.perfdata.monitor.protocol.local.LocalEventTimer
sun.jvmstat.perfdata.monitor.protocol.local.LocalMonitoredVm
sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager
sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider
sun.jvmstat.perfdata.monitor.protocol.rmi.MonitoredHostProvider
sun.jvmstat.perfdata.monitor.protocol.rmi.PerfDataBuffer
sun.jvmstat.perfdata.monitor.protocol.rmi.RemoteMonitoredVm
sun.management.Agent
sun.management.ClassLoadingImpl
sun.management.FileSystem
sun.management.FileSystemImpl
sun.management.GarbageCollectorImpl
sun.management.GcInfoBuilder
sun.management.GcInfoCompositeData
sun.management.HotspotRuntime
sun.management.HotspotThread
sun.management.LazyCompositeData
sun.management.MXBeanSupport
sun.management.ManagementFactory
sun.management.MappedMXBeanType
sun.management.MemoryImpl
sun.management.MemoryManagerImpl
sun.management.MemoryPoolImpl
sun.management.NotificationEmitterSupport
sun.management.Sensor
sun.management.ThreadImpl
sun.management.VMManagementImpl
sun.management.counter.perf.PerfInstrumentation
sun.management.jmxremote.ConnectorBootstrap
sun.management.jmxremote.ConnectorBootstrap$PermanentExporter
sun.management.snmp.AdaptorBootstrap
sun.management.snmp.jvminstr.JVM_MANAGEMENT_MIB_IMPL
sun.management.snmp.jvminstr.JvmMemPoolEntryImpl
sun.management.snmp.jvminstr.JvmThreadingImpl
sun.management.snmp.jvmmib.JvmMemGCTableMeta
sun.management.snmp.jvmmib.JvmMemManagerTableMeta
sun.management.snmp.jvmmib.JvmMemMgrPoolRelTableMeta
sun.management.snmp.jvmmib.JvmMemPoolTableMeta
sun.management.snmp.jvmmib.JvmRTBootClassPathTableMeta
sun.management.snmp.jvmmib.JvmRTClassPathTableMeta
sun.management.snmp.jvmmib.JvmRTInputArgsTableMeta
sun.management.snmp.jvmmib.JvmRTLibraryPathTableMeta
sun.management.snmp.jvmmib.JvmThreadInstanceTableMeta
sun.management.snmp.util.JvmContextFactory
sun.management.snmp.util.SnmpTableCache
sun.misc.AtomicLong
sun.misc.AtomicLongCSImpl
sun.misc.AtomicLongLockImpl
sun.misc.Cache
sun.misc.ClassFileTransformer
sun.misc.Cleaner
sun.misc.ConditionLock
sun.misc.ExtensionDependency
sun.misc.FIFOQueueEnumerator
sun.misc.FloatingDecimal
sun.misc.FloatingDecimal$1
sun.misc.FormattedFloatingDecimal
sun.misc.FormattedFloatingDecimal$1
sun.misc.GC
sun.misc.GC$Daemon
sun.misc.GC$LatencyRequest
sun.misc.LIFOQueueEnumerator
sun.misc.Launcher$AppClassLoader
sun.misc.Lock
sun.misc.MessageUtils
sun.misc.NativeSignalHandler
sun.misc.PathPermissions
sun.misc.Perf
sun.misc.Perf$1
sun.misc.PerformanceLogger
sun.misc.Queue
sun.misc.Ref
sun.misc.RequestProcessor
sun.misc.Resource
sun.misc.Signal
sun.misc.Timer
sun.misc.TimerThread
sun.misc.TimerTickThread
sun.misc.URLClassPath
sun.misc.Unsafe
sun.misc.VM
sun.net.InetAddressCachePolicy
sun.net.ProgressMonitor
sun.net.dns.ResolverConfiguration
sun.net.dns.ResolverConfigurationImpl
sun.net.dns.ResolverConfigurationImpl$AddressChangeListener
sun.net.ftp.FtpClient
sun.net.spi.DefaultProxySelector
sun.net.spi.DefaultProxySelector$2
sun.net.www.HeaderParser
sun.net.www.MessageHeader
sun.net.www.MessageHeader$HeaderIterator
sun.net.www.MeteredStream
sun.net.www.MimeEntry
sun.net.www.MimeTable
sun.net.www.http.ChunkedInputStream
sun.net.www.http.ChunkedOutputStream
sun.net.www.http.ClientVector
sun.net.www.http.HttpClient
sun.net.www.http.KeepAliveCache
sun.net.www.http.KeepAliveStream
sun.net.www.http.PosterOutputStream
sun.net.www.protocol.doc.DocURLConnection
sun.net.www.protocol.doc.Handler
sun.net.www.protocol.file.FileURLConnection
sun.net.www.protocol.file.Handler
sun.net.www.protocol.ftp.FtpURLConnection
sun.net.www.protocol.http.AuthCacheImpl
sun.net.www.protocol.http.AuthenticationInfo
sun.net.www.protocol.http.DigestAuthentication$Parameters
sun.net.www.protocol.http.HttpURLConnection
sun.net.www.protocol.http.NTLMAuthSequence
sun.net.www.protocol.http.NTLMAuthentication
sun.net.www.protocol.jar.JarFileFactory
sun.net.www.protocol.jar.URLJarFile
sun.net.www.protocol.mailto.Handler
sun.net.www.protocol.mailto.MailToURLConnection
sun.net.www.protocol.netdoc.Handler
sun.nio.ch.AllocatedNativeObject
sun.nio.ch.ChannelInputStream
sun.nio.ch.DatagramChannelImpl
sun.nio.ch.DatagramDispatcher
sun.nio.ch.DatagramSocketAdaptor
sun.nio.ch.FileChannelImpl
sun.nio.ch.FileDispatcher
sun.nio.ch.FileLockImpl
sun.nio.ch.IOUtil
sun.nio.ch.NativeThreadSet
sun.nio.ch.Net
sun.nio.ch.SelectorImpl
sun.nio.ch.ServerSocketAdaptor
sun.nio.ch.ServerSocketChannelImpl
sun.nio.ch.SocketAdaptor
sun.nio.ch.SocketAdaptor$SocketInputStream
sun.nio.ch.SocketChannelImpl
sun.nio.ch.SocketDispatcher
sun.nio.ch.Util
sun.nio.ch.Util$SelectorWrapper$Closer
sun.nio.ch.WindowsSelectorImpl
sun.nio.ch.WindowsSelectorImpl$FinishLock
sun.nio.ch.WindowsSelectorImpl$StartLock
sun.nio.ch.WindowsSelectorImpl$SubSelector
sun.nio.cs.AbstractCharsetProvider
sun.nio.cs.FastCharsetProvider
sun.nio.cs.StreamDecoder
sun.nio.cs.StreamEncoder
sun.print.*
sun.reflect.ConstantPool
sun.reflect.MethodAccessorGenerator
sun.reflect.NativeConstructorAccessorImpl
sun.reflect.NativeMethodAccessorImpl
sun.reflect.Reflection
sun.reflect.annotation.AnnotationType
sun.reflect.misc.MethodUtil
sun.rmi.log.ReliableLog
sun.rmi.registry.RegistryImpl
sun.rmi.rmic.BatchEnvironment
sun.rmi.rmic.Main
sun.rmi.rmic.iiop.DirectoryLoader
sun.rmi.rmic.iiop.NameContext
sun.rmi.rmic.newrmic.Main
sun.rmi.runtime.Log$LogStreamLog
sun.rmi.runtime.Log$LoggerLog
sun.rmi.runtime.ThreadPool
sun.rmi.runtime.ThreadPool$Worker
sun.rmi.server.ActivatableRef
sun.rmi.server.Activation
sun.rmi.server.Activation$ActivationSystemImpl
sun.rmi.server.Activation$DelayedAcceptServerSocket
sun.rmi.server.Activation$GroupEntry
sun.rmi.server.Activation$GroupEntry$Watchdog
sun.rmi.server.Activation$ObjectEntry
sun.rmi.server.Activation$Shutdown
sun.rmi.server.Activation$ShutdownHook
sun.rmi.server.ActivationGroupImpl
sun.rmi.server.LoaderHandler
sun.rmi.server.MarshalInputStream
sun.rmi.server.PipeWriter
sun.rmi.server.UnicastRef
sun.rmi.server.UnicastServerRef
sun.rmi.server.Util
sun.rmi.server.WeakClassHashMap
sun.rmi.transport.DGCAckHandler
sun.rmi.transport.DGCClient
sun.rmi.transport.DGCClient$EndpointEntry
sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread
sun.rmi.transport.DGCImpl
sun.rmi.transport.DGCImpl$LeaseInfo
sun.rmi.transport.ObjectTable
sun.rmi.transport.ObjectTable$Reaper
sun.rmi.transport.Target
sun.rmi.transport.WeakRef
sun.rmi.transport.proxy.HttpOutputStream
sun.rmi.transport.proxy.HttpReceiveSocket
sun.rmi.transport.proxy.HttpSendInputStream
sun.rmi.transport.proxy.HttpSendSocket
sun.rmi.transport.proxy.RMIMasterSocketFactory
sun.rmi.transport.proxy.RMIMasterSocketFactory$AsyncConnector
sun.rmi.transport.proxy.WrappedSocket
sun.rmi.transport.tcp.ConnectionAcceptor
sun.rmi.transport.tcp.ConnectionMultiplexer
sun.rmi.transport.tcp.MultiplexInputStream
sun.rmi.transport.tcp.MultiplexOutputStream
sun.rmi.transport.tcp.TCPChannel
sun.rmi.transport.tcp.TCPEndpoint
sun.rmi.transport.tcp.TCPEndpoint$FQDN
sun.rmi.transport.tcp.TCPTransport
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler
sun.security.*
sun.swing.*
sun.text.resources.DateFormatZoneData
sun.text.resources.LocaleData
sun.tools.asm.SwitchData
sun.tools.hprof.Tracker
sun.tools.jar.JarVerifierStream
sun.tools.jar.Main
sun.tools.java.Constants
sun.tools.java.Identifier
sun.tools.java.Imports
sun.tools.java.MemberDefinition
sun.tools.java.RuntimeConstants
sun.tools.java.Type
sun.tools.javac.Main
sun.tools.javac.SourceClass
sun.tools.javap.ClassData
sun.tools.javap.Constants
sun.tools.javap.MethodData
sun.tools.javap.RuntimeConstants
sun.tools.javap.Tables
sun.tools.jstat.JStatLogger
sun.tools.jstat.Jstat$2
sun.tools.jstatd.RemoteHostImpl
sun.tools.native2ascii.Main
sun.tools.serialver.SerialVer
sun.tools.tree.SynchronizedStatement
sun.util.calendar.CalendarSystem
sun.util.calendar.ZoneInfo
sun.util.calendar.ZoneInfoFile
javax.crypto.*
javax.net.ServerSocketFactory
javax.net.DefaultServerSocketFactory
javax.net.SocketFactory
javax.net.DefaultSocketFactory
javax.net.ssl.*
sun.net.www.protocol.https.*
com.sun.net.ssl.*
com.sun.management.UnixOperatingSystem
java.io.UnixFileSystem
java.lang.UNIXProcess
java.lang.UNIXProcess$1$1
java.lang.UNIXProcess$2$1
java.lang.UNIXProcess$DeferredCloseInputStream
java.lang.UNIXProcess$Gate
java.util.prefs.FileSystemPreferences
sun.font.NativeStrikeDisposer
sun.font.XMap
sun.io.CharToByteCOMPOUND_TEXT
sun.nio.ch.DevPollArrayWrapper
sun.nio.ch.DevPollSelectorImpl
sun.nio.ch.InheritedChannel
sun.nio.ch.PollSelectorImpl
com.sun.java.util.jar.pack.PropMap
com.sun.java.util.jar.pack.UnpackerImpl
com.sun.org.apache.bcel.internal.verifier.statics.Pass2Verifier$CPESSC_Visitor
com.sun.tools.corba.se.idl.Token
com.sun.tools.javac.comp.Attr
com.sun.tools.javac.resources.compiler_zh_CN
com.sun.tools.javah.oldjavah.OldHeaders
sun.font.NativeFont
sun.font.NativeStrike
sun.font.X11TextRenderer
sun.jvm.hotspot.HotSpotAgent
sun.jvm.hotspot.HotSpotAgent$1
sun.jvm.hotspot.bugspot.BugSpotAgent
sun.jvm.hotspot.bugspot.BugSpotAgent$1
sun.jvm.hotspot.debugger.PageCache
sun.jvm.hotspot.debugger.dbx.DbxDebuggerLocal
sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal
sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread
sun.jvm.hotspot.debugger.proc.ProcDebuggerLocal
sun.jvm.hotspot.debugger.win32.Win32DebuggerLocal
sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal
sun.jvm.hotspot.interpreter.Bytecodes
sun.jvm.hotspot.interpreter.OopMapCacheEntry
sun.jvm.hotspot.interpreter.OopMapForCacheEntry
sun.jvm.hotspot.jdi.SAJDIClassLoader
sun.jvm.hotspot.jdi.VirtualMachineImpl
sun.jvm.hotspot.oops.AccessFlags
sun.jvm.hotspot.tools.JStack
sun.jvm.hotspot.utilities.HeapGXLWriter
sun.jvm.hotspot.utilities.HeapHprofBinWriter
sun.jvm.hotspot.utilities.MessageQueueBackend$MessageQueueImpl
sun.jvm.hotspot.utilities.StreamMonitor
sun.jvm.hotspot.utilities.SystemDictionaryHelper
sun.nio.ch.NativeThread
sun.nio.ch.SinkChannelImpl
sun.nio.ch.SourceChannelImpl
sun.rmi.rmic.iiop.Constants
sun.tools.jconsole.ConnectDialog$ManagedVmTableModel
sun.tools.jconsole.ProxyClient
sun.tools.jconsole.Resources
sun.tools.jconsole.Tab
sun.tools.jconsole.VMPanel
sun.tools.jconsole.Worker
sun.tools.jconsole.inspector.Utils
sun.tools.jconsole.inspector.XMBeanAttributes
sun.tools.jconsole.inspector.XMBeanAttributes$AttributesListener$1
sun.tools.jconsole.inspector.XMBeanNotifications
sun.tools.jconsole.inspector.XMBeanNotifications$XMBeanNotificationsListener
sun.tools.jconsole.inspector.XMBeanTree
sun.tools.jconsole.inspector.XObject
sun.tools.jconsole.inspector.XOperations
sun.tools.jconsole.inspector.XOperations$1
sun.tools.jconsole.inspector.XSheet
sun.tools.jconsole.inspector.XSheet$1
sun.tools.jconsole.inspector.XSheet$3
sun.tools.jconsole.inspector.XSheet$4
sun.tools.jconsole.inspector.XSheet$XMBeanPane
sun.tools.jconsole.inspector.XTree
com.sun.jndi.cosnaming.CNCtx
com.sun.jndi.cosnaming.OrbReuseTracker
com.sun.org.apache.xml.internal.utils.ThreadControllerWrapper$ThreadController$SafeThread
com.sun.servicetag.Installer
com.sun.servicetag.RegistrationData
com.sun.servicetag.SystemEnvironment
com.sun.servicetag.Util
sun.font.CreatedFontTracker
sun.font.Type1Font$T1DisposerRecord
sun.management.ConnectorAddressLink
sun.net.www.URLConnection
sun.nio.ch.EPollArrayWrapper
sun.nio.ch.EPollSelectorImpl
sun.net.ResourceManager

#---------------------------------------------------------------------
# J2SE (JDK6 以降)
#---------------------------------------------------------------------
com.sun.activation.registries.LogSupport
com.sun.activation.registries.MailcapFile
com.sun.codemodel.internal.CodeWriter
com.sun.codemodel.internal.util.EncoderFactory
com.sun.istack.internal.Pool$Impl
com.sun.istack.internal.tools.MaskingClassLoader
com.sun.jmx.mbeanserver.Introspector
com.sun.jmx.mbeanserver.MBeanInstantiator
com.sun.jmx.mbeanserver.MBeanIntrospector
com.sun.jmx.mbeanserver.MXBeanLookup
com.sun.jmx.mbeanserver.MXBeanSupport
com.sun.jmx.mbeanserver.OpenConverter
com.sun.jmx.mbeanserver.Repository
com.sun.jmx.mbeanserver.StandardMBeanIntrospector
com.sun.jmx.mbeanserver.Util
com.sun.jmx.remote.internal.ServerNotifForwarder$2
com.sun.net.httpserver.spi.HttpServerProvider
com.sun.org.apache.regexp.internal.RECompiler
com.sun.org.apache.regexp.internal.RETestCase
com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM
com.sun.org.apache.xerces.internal.impl.dv.xs.PrecisionDecimalDV$XPrecisionDecimal
com.sun.org.apache.xerces.internal.impl.xs.ElementPSVImpl
com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$Schema4Annotations
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser
com.sun.org.apache.xerces.internal.jaxp.validation.SoftReferenceGrammarPool
com.sun.org.apache.xerces.internal.jaxp.validation.WeakReferenceXMLSchema
com.sun.org.apache.xerces.internal.util.XMLCatalogResolver
com.sun.org.apache.xml.internal.resolver.Catalog
com.sun.org.apache.xml.internal.security.Init
com.sun.org.apache.xml.internal.security.exceptions.XMLSecurityException
com.sun.org.apache.xml.internal.security.exceptions.XMLSecurityRuntimeException
com.sun.org.apache.xml.internal.security.keys.content.x509.XMLX509SKI
com.sun.org.apache.xml.internal.security.utils.I18n
com.sun.org.apache.xml.internal.security.utils.IdResolver
com.sun.tools.attach.spi.AttachProvider
com.sun.tools.hat.internal.model.Snapshot
com.sun.tools.hat.internal.oql.OQLEngine
com.sun.tools.hat.internal.parser.FileReadBuffer
com.sun.tools.hat.internal.parser.MappedReadBuffer
com.sun.tools.hat.internal.server.PlatformClasses
com.sun.tools.internal.ws.processor.model.AsyncOperation
com.sun.tools.internal.ws.processor.util.IndentingWriter
com.sun.tools.internal.ws.wscompile.Options
com.sun.tools.internal.ws.wsdl.framework.TWSDLParserContextImpl
com.sun.tools.internal.xjc.Driver$1
com.sun.tools.internal.xjc.SchemaCache
com.sun.tools.internal.xjc.addon.sync.SynchronizedMethodAddOn
com.sun.tools.internal.xjc.api.impl.s2j.SchemaCompilerImpl
com.sun.tools.internal.xjc.reader.xmlschema.bindinfo.BindInfo
com.sun.tools.javac.api.JavacTaskImpl
com.sun.tools.javac.api.JavacTaskImpl$1
com.sun.tools.javac.code.Symbol$VarSymbol
com.sun.tools.javac.processing.JavacFiler
com.sun.tools.javac.processing.JavacFiler$FilerOutputFileObject
com.sun.tools.javac.processing.JavacFiler$FilerOutputStream
com.sun.tools.javac.processing.JavacFiler$FilerWriter
com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator
com.sun.tools.javac.processing.JavacProcessingEnvironment$NameProcessIterator
com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState
com.sun.tools.javac.sym.CreateSymbols
com.sun.tools.javac.util.DefaultFileManager
com.sun.tools.javac.util.Log
com.sun.tools.javac.util.Paths
com.sun.tools.javac.zip.ZipFileIndex
com.sun.tools.jconsole.JConsolePlugin
com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl
com.sun.tools.jdi.MonitorInfoImpl
com.sun.xml.internal.bind.AccessorFactoryImpl
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl
com.sun.xml.internal.bind.v2.runtime.MarshallerImpl
com.sun.xml.internal.bind.v2.runtime.reflect.Lister
com.sun.xml.internal.bind.v2.runtime.reflect.Lister$IDREFS$Pack
com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$IDREFTransducedAccessorImpl
com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$IDREFTransducedAccessorImpl$1
com.sun.xml.internal.bind.v2.runtime.reflect.opt.Injector
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext
com.sun.xml.internal.fastinfoset.AbstractResourceBundle
com.sun.xml.internal.fastinfoset.CommonResourceBundle
com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl
com.sun.xml.internal.messaging.saaj.packaging.mime.MessagingException
com.sun.xml.internal.messaging.saaj.packaging.mime.internet.MimeMultipart
com.sun.xml.internal.messaging.saaj.soap.AttachmentPartImpl
com.sun.xml.internal.messaging.saaj.soap.MessageImpl
com.sun.xml.internal.messaging.saaj.util.ParserPool
com.sun.xml.internal.messaging.saaj.util.TeeInputStream
com.sun.xml.internal.rngom.parse.compact.JavaCharStream
com.sun.xml.internal.ws.api.pipe.Engine
com.sun.xml.internal.ws.api.pipe.Engine$DaemonThreadFactory
com.sun.xml.internal.ws.api.pipe.Fiber
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory$Default
com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory$Default
com.sun.xml.internal.ws.client.AsyncResponseImpl
com.sun.xml.internal.ws.client.ResponseImpl
com.sun.xml.internal.ws.client.Stub
com.sun.xml.internal.ws.client.WSServiceDelegate
com.sun.xml.internal.ws.client.dispatch.DispatchImpl
com.sun.xml.internal.ws.client.dispatch.DispatchImpl$DispatchAsyncInvoker$1
com.sun.xml.internal.ws.client.sei.AsyncMethodHandler
com.sun.xml.internal.ws.client.sei.AsyncMethodHandler$Invoker
com.sun.xml.internal.ws.client.sei.CallbackMethodHandler
com.sun.xml.internal.ws.server.StatefulInstanceResolver
com.sun.xml.internal.ws.server.StatefulInstanceResolver$Instance
com.sun.xml.internal.ws.server.StatefulInstanceResolver$Instance$1
com.sun.xml.internal.ws.server.WSEndpointImpl
com.sun.xml.internal.ws.transport.http.HttpAdapter
com.sun.xml.internal.ws.transport.http.client.CookieJar
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe
com.sun.xml.internal.ws.transport.http.server.EndpointImpl
com.sun.xml.internal.ws.transport.http.server.HttpEndpoint
com.sun.xml.internal.ws.transport.http.server.ServerMgr
com.sun.xml.internal.ws.transport.http.server.WSHttpHandler
com.sun.xml.internal.ws.transport.http.server.WSHttpHandler$HttpHandlerRunnable
com.sun.xml.internal.ws.util.CompletedFuture
com.sun.xml.internal.ws.util.DOMUtil
com.sun.xml.internal.ws.util.Pool
com.sun.xml.internal.ws.util.pipe.StandalonePipeAssembler
com.sun.xml.internal.ws.util.pipe.StandaloneTubeAssembler
com.sun.xml.internal.xsom.impl.scd.SimpleCharStream
java.beans.java_util_Collections$SynchronizedCollection_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedList_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedMap_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedRandomAccessList_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedSet_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedSortedMap_PersistenceDelegate
java.beans.java_util_Collections$SynchronizedSortedSet_PersistenceDelegate
java.io.Console
java.io.Console$LineReader
java.io.DeleteOnExitHook
java.lang.ApplicationShutdownHooks
java.lang.Byte$ByteCache
java.lang.Character$CharacterCache
java.lang.Integer$IntegerCache
java.lang.Long$LongCache
java.lang.SecurityException
java.lang.Short$ShortCache
java.lang.VirtualMachineError
java.lang.management.GarbageCollectorMXBean
java.lang.management.MemoryManagerMXBean
java.lang.management.MemoryPoolMXBean
java.rmi.server.ObjID
java.sql.DriverService
java.text.NumberFormat
java.util.Arrays
java.util.ServiceLoader$LazyIterator
javax.activation.DataHandler
javax.activation.MailcapCommandMap
javax.activation.MimetypesFileTypeMap
javax.activation.ObjectDataContentHandler
javax.annotation.processing.AbstractProcessor
javax.management.monitor.CounterMonitor$CounterMonitorObservedObject
javax.management.monitor.GaugeMonitor$GaugeMonitorObservedObject
javax.management.monitor.Monitor$DaemonThreadFactory
javax.management.monitor.Monitor$MonitorTask
javax.management.monitor.Monitor$ObservedObject
javax.management.monitor.Monitor$SchedulerTask
javax.management.monitor.StringMonitor$StringMonitorObservedObject
javax.management.openmbean.OpenType
javax.management.remote.rmi._RMIConnectionImpl_Tie
javax.management.remote.rmi._RMIConnection_Stub
javax.management.remote.rmi._RMIServerImpl_Tie
javax.management.remote.rmi._RMIServer_Stub
javax.tools.DiagnosticCollector
javax.tools.StandardLocation
javax.tools.ToolProvider
javax.tools.ToolProvider$Lazy
javax.xml.bind.ContextFinder
javax.xml.bind.JAXBException
javax.xml.bind.TypeConstraintException
javax.xml.soap.SOAPException
javax.xml.stream.FactoryFinder
javax.xml.ws.Service
sun.font.FontDesignMetrics
sun.font.FontDesignMetrics$KeyReference
sun.font.GlyphLayout$SDCache
sun.jkernel.BackgroundDownloader
sun.jkernel.Bundle
sun.jkernel.DownloadManager
sun.jkernel.Mutex
sun.management.Flag
sun.management.HotSpotDiagnostic
sun.misc.ClassLoaderUtil
sun.misc.Launcher
sun.misc.MetaIndex
sun.misc.VMSupport
sun.misc.Version
sun.net.httpserver.ContextList
sun.net.httpserver.HttpConnection
sun.net.httpserver.HttpServerImpl
sun.net.httpserver.HttpsServerImpl
sun.net.httpserver.LeftOverInputStream
sun.net.httpserver.Request$ReadStream
sun.net.httpserver.Request$WriteStream
sun.net.httpserver.SSLStreams
sun.net.httpserver.SSLStreams$EngineWrapper
sun.net.httpserver.SelectorCache
sun.net.httpserver.SelectorCache$CacheCleaner
sun.net.httpserver.ServerImpl
sun.net.httpserver.ServerImpl$Dispatcher
sun.net.httpserver.ServerImpl$ServerTimerTask
sun.net.www.http.KeepAliveStreamCleaner
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
sun.net.www.protocol.http.InMemoryCookieStore
sun.net.www.protocol.http.NegotiateAuthentication
sun.nio.ch.FileChannelImpl$SharedFileLockTable
sun.nio.ch.FileChannelImpl$SimpleFileLockTable
sun.rmi.runtime.RuntimeUtil
sun.rmi.runtime.RuntimeUtil$1
sun.tools.attach.HotSpotAttachProvider
sun.tools.attach.HotSpotVirtualMachine
sun.tools.attach.WindowsVirtualMachine
sun.tools.attach.WindowsVirtualMachine$PipedInputStream
sun.tools.jconsole.ClassTab$2
sun.tools.jconsole.HTMLPane
sun.tools.jconsole.InternalDialog$MastheadIcon
sun.tools.jconsole.JConsole
sun.tools.jconsole.MemoryTab$4
sun.tools.jconsole.Plotter
sun.tools.jconsole.ProxyClient$SnapshotInvocationHandler
sun.tools.jconsole.SummaryTab
sun.tools.jconsole.SummaryTab$1
sun.tools.jconsole.ThreadTab$1
sun.tools.jconsole.inspector.XMBean
sun.tools.jconsole.inspector.XMBeanNotifications$XMBeanNotificationsListener$1
sun.tools.jconsole.resources.JConsoleResources
sun.tools.jconsole.resources.JConsoleResources_ja
sun.tools.jconsole.resources.JConsoleResources_zh_CN
sun.util.LocaleServiceProviderPool
sun.util.TimeZoneNameUtility
com.sun.codemodel.internal.JJavaName
com.sun.codemodel.internal.JMods
com.sun.tools.hat.internal.model.StackFrame
com.sun.tools.internal.ws.processor.generator.Names
com.sun.tools.javac.parser.Token
com.sun.xml.internal.bind.api.impl.NameUtil
java.lang.management.ThreadInfo
javax.lang.model.SourceVersion
sun.jvm.hotspot.memory.SystemDictionary
sun.nio.cs.ext.COMPOUND_TEXT_Encoder
sun.nio.cs.ext.CompoundTextSupport
sun.tools.attach.LinuxVirtualMachine
sun.tools.attach.LinuxVirtualMachine$SocketInputStream
com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary
com.sun.xml.internal.org.jvnet.mimepull.DataFile
com.sun.xml.internal.org.jvnet.mimepull.DataHead
com.sun.xml.internal.org.jvnet.mimepull.DataHead$ReadOnceStream
com.sun.xml.internal.org.jvnet.mimepull.MIMEMessage
com.sun.xml.internal.org.jvnet.mimepull.WeakDataFile
com.sun.xml.internal.ws.api.server.HttpEndpoint
com.sun.xml.internal.ws.client.AsyncInvoker
com.sun.xml.internal.ws.client.sei.AsyncMethodHandler$SEIAsyncInvoker$1
com.sun.xml.internal.ws.encoding.MimeCodec
com.sun.xml.internal.ws.model.WrapperBeanGenerator
com.sun.xml.internal.ws.server.JMXAgent
sun.jvm.hotspot.CommandProcessor$9
sun.jvm.hotspot.CommandProcessor$9$1
sun.jvm.hotspot.SALauncherLoader
sun.jvm.hotspot.ui.AnnotatedMemoryPanel
sun.jvm.hotspot.ui.classbrowser.HTMLGenerator
sun.jvm.hotspot.ui.FindInCodeCachePanel$Visitor$1
sun.jvm.hotspot.ui.ProcessListPanel
sun.jvm.hotspot.utilities.soql.SOQLEngine
sun.net.spi.DefaultProxySelector$3

#---------------------------------------------------------------------
# "J2SE"に追加するパッケージ, クラス
# ( JDK5またはJDK6の0870に存在しなかったが, 0900に含まれるようになったもの)
#---------------------------------------------------------------------
com.rsa.*
com.sun.tools.javac.util.CloseableURLClassLoader
java.text.DateFormatSymbols
java.text.SimpleDateFormat
sun.nio.cs.ext.Big5
sun.nio.cs.ext.Big5_Solaris
sun.nio.cs.ext.MS950

#---------------------------------------------------------------------
# "J2SE"に追加するパッケージ, クラス
# ( 0900に存在しなかったが, 0950に含まれるようになったもの)
#---------------------------------------------------------------------
com.sun.beans.AppContext
com.sun.org.apache.xalan.internal.utils.ObjectFactory

#---------------------------------------------------------------------
# J2SE (JDK7 以降)
#---------------------------------------------------------------------
com.sun.beans.editors.EnumEditor
com.sun.beans.finder.PersistenceDelegateFinder
com.sun.beans.finder.PropertyEditorFinder
com.sun.beans.TypeResolver
com.sun.istack.internal.tools.ParallelWorldClassLoader
com.sun.java.accessibility.AccessBridge
com.sun.java.accessibility.util.AccessibilityListenerList
com.sun.java.accessibility.util.AWTEventMonitor
com.sun.java.accessibility.util.AWTEventMonitor$AWTEventsListener
com.sun.java.accessibility.util.ComponentEvtDispatchThread
com.sun.java.accessibility.util.EventQueueMonitor
com.sun.java.accessibility.util.GUIInitializedListener
com.sun.java.accessibility.util.GUIInitializedMulticaster
com.sun.java.accessibility.util.java.awt.ButtonTranslator
com.sun.java.accessibility.util.java.awt.CheckboxTranslator
com.sun.java.accessibility.util.java.awt.LabelTranslator
com.sun.java.accessibility.util.java.awt.ListTranslator
com.sun.java.accessibility.util.java.awt.TextComponentTranslator
com.sun.java.accessibility.util.SwingEventMonitor
com.sun.java.accessibility.util.SwingEventMonitor$SwingEventListener
com.sun.java.accessibility.util.TopLevelWindowListener
com.sun.java.accessibility.util.TopLevelWindowMulticaster
com.sun.java.accessibility.util.Translator
com.sun.java.util.jar.pack.Driver
com.sun.java.util.jar.pack.PackageReader
com.sun.java.util.jar.pack.PackageWriter
com.sun.java.util.jar.pack.PackerImpl
com.sun.java.util.jar.pack.Utils
com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory
com.sun.jmx.remote.internal.ServerNotifForwarder$NotifForwarderBufferFilter
com.sun.naming.internal.ResourceManager$AppletParameter
com.sun.nio.zipfs.ZipCoder
com.sun.nio.zipfs.ZipDirectoryStream
com.sun.nio.zipfs.ZipDirectoryStream$1
com.sun.nio.zipfs.ZipFileSystem
com.sun.nio.zipfs.ZipFileSystem$EntryInputStream
com.sun.nio.zipfs.ZipFileSystemProvider
com.sun.nio.zipfs.ZipUtils
com.sun.org.apache.xalan.internal.utils.SecuritySupport
com.sun.org.apache.xalan.internal.utils.XMLSecurityPropertyManager
com.sun.org.apache.xalan.internal.utils.XMLSecurityPropertyManager$Property
com.sun.org.apache.xalan.internal.utils.XMLSecurityPropertyManager$State
com.sun.org.apache.xerces.internal.impl.xpath.regex.CaseInsensitiveMap
com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression$Context
com.sun.org.apache.xerces.internal.utils.SecuritySupport
com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager
com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$Property
com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$State
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$1
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$2
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$3
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$4
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$5
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$6
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$7
com.sun.org.apache.xerces.internal.xinclude.SecuritySupport$8
com.sun.org.apache.xml.internal.security.algorithms.JCEMapper
com.sun.org.apache.xml.internal.security.algorithms.SignatureAlgorithm
com.sun.org.apache.xml.internal.security.c14n.Canonicalizer
com.sun.org.apache.xml.internal.security.keys.keyresolver.KeyResolver
com.sun.org.apache.xml.internal.security.transforms.Transform
com.sun.org.apache.xml.internal.security.utils.ElementProxy
com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolver
com.sun.org.apache.xml.internal.security.utils.UnsyncBufferedOutputStream$1
com.sun.org.apache.xml.internal.security.utils.UnsyncByteArrayOutputStream$1
com.sun.org.apache.xml.internal.serialize.SecuritySupport
com.sun.org.apache.xml.internal.serialize.SecuritySupport$1
com.sun.org.apache.xml.internal.serialize.SecuritySupport$2
com.sun.org.apache.xml.internal.serialize.SecuritySupport$3
com.sun.org.apache.xml.internal.serialize.SecuritySupport$4
com.sun.org.apache.xml.internal.serialize.SecuritySupport$5
com.sun.org.apache.xml.internal.serialize.SecuritySupport$6
com.sun.org.apache.xml.internal.serialize.SecuritySupport$7
com.sun.org.apache.xml.internal.serialize.SecuritySupport$8
com.sun.org.glassfish.external.amx.AMXGlassfish$BootAMXCallback
com.sun.org.glassfish.external.amx.AMXGlassfish$WaitForDomainRootListenerCallback
com.sun.org.glassfish.external.amx.MBeanListener$CallbackImpl
com.sun.org.glassfish.external.statistics.impl.AverageRangeStatisticImpl
com.sun.org.glassfish.external.statistics.impl.BoundaryStatisticImpl
com.sun.org.glassfish.external.statistics.impl.BoundedRangeStatisticImpl
com.sun.org.glassfish.external.statistics.impl.CountStatisticImpl
com.sun.org.glassfish.external.statistics.impl.RangeStatisticImpl
com.sun.org.glassfish.external.statistics.impl.StatisticImpl
com.sun.org.glassfish.external.statistics.impl.StatsImpl
com.sun.org.glassfish.external.statistics.impl.StringStatisticImpl
com.sun.org.glassfish.external.statistics.impl.TimeStatisticImpl
com.sun.org.glassfish.gmbal.util.GenericConstructor
com.sun.org.glassfish.gmbal.util.GenericConstructor$1
com.sun.tools.classfile.Attribute$Factory
com.sun.tools.internal.xjc.reader.Ring
com.sun.tools.javac.api.ClientCodeWrapper$WrappedDiagnosticListener
com.sun.tools.javac.api.ClientCodeWrapper$WrappedFileObject
com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager
com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileObject
com.sun.tools.javac.api.ClientCodeWrapper$WrappedTaskListener
com.sun.tools.javac.code.Flags$Flag
com.sun.tools.javac.file.CacheFSInfo
com.sun.tools.javac.file.ZipFileIndex
com.sun.tools.javac.file.ZipFileIndexCache
com.sun.tools.javac.processing.JavacProcessingEnvironment$ServiceIterator
com.sun.tools.javac.Server
com.sun.tools.javac.util.BaseFileManager
com.sun.tools.javac.util.SharedNameTable
com.sun.tools.javap.JavapTask
com.sun.xml.internal.bind.v2.runtime.reflect.opt.AccessorInjector
com.sun.xml.internal.ws.model.AbstractWrapperBeanGenerator
com.sun.xml.internal.ws.model.Injector
com.sun.xml.internal.ws.policy.sourcemodel.AssertionData
com.sun.xml.internal.ws.policy.sourcemodel.PolicySourceModel
com.sun.xml.internal.ws.transport.http.server.PortableHttpHandler
com.sun.xml.internal.ws.transport.http.server.PortableHttpHandler$HttpHandlerRunnable
java.beans.ChangeListenerMap
java.beans.MetaData$java_awt_AWTKeyStroke_PersistenceDelegate
java.beans.MetaData$java_awt_BorderLayout_PersistenceDelegate
java.beans.MetaData$java_awt_CardLayout_PersistenceDelegate
java.beans.MetaData$java_awt_Choice_PersistenceDelegate
java.beans.MetaData$java_awt_Component_PersistenceDelegate
java.beans.MetaData$java_awt_Container_PersistenceDelegate
java.beans.MetaData$java_awt_Font_PersistenceDelegate
java.beans.MetaData$java_awt_font_TextAttribute_PersistenceDelegate
java.beans.MetaData$java_awt_GridBagLayout_PersistenceDelegate
java.beans.MetaData$java_awt_Insets_PersistenceDelegate
java.beans.MetaData$java_awt_List_PersistenceDelegate
java.beans.MetaData$java_awt_Menu_PersistenceDelegate
java.beans.MetaData$java_awt_MenuBar_PersistenceDelegate
java.beans.MetaData$java_awt_MenuShortcut_PersistenceDelegate
java.beans.MetaData$java_awt_SystemColor_PersistenceDelegate
java.beans.MetaData$javax_swing_border_MatteBorder_PersistenceDelegate
java.beans.MetaData$javax_swing_Box_PersistenceDelegate
java.beans.MetaData$javax_swing_DefaultComboBoxModel_PersistenceDelegate
java.beans.MetaData$javax_swing_DefaultListModel_PersistenceDelegate
java.beans.MetaData$javax_swing_JFrame_PersistenceDelegate
java.beans.MetaData$javax_swing_JMenu_PersistenceDelegate
java.beans.MetaData$javax_swing_JTabbedPane_PersistenceDelegate
java.beans.MetaData$javax_swing_ToolTipManager_PersistenceDelegate
java.beans.MetaData$javax_swing_tree_DefaultMutableTreeNode_PersistenceDelegate
java.beans.MetaData$sun_swing_PrintColorUIResource_PersistenceDelegate
java.beans.ThreadGroupContext
java.lang.BootstrapMethodError
java.lang.ClassLoader$ParallelLoaders
java.lang.ClassValue
java.lang.ClassValue$ClassValueMap
java.lang.IllegalStateException
java.lang.invoke.BoundMethodHandle
java.lang.invoke.BoundMethodHandle$SpeciesData
java.lang.invoke.CallSite
java.lang.invoke.LambdaForm
java.lang.invoke.LambdaForm$NamedFunction
java.lang.invoke.MethodHandle
java.lang.invoke.MethodHandleImpl$BindCaller
java.lang.invoke.MethodHandleImpl$BindCaller$2
java.lang.invoke.MethodHandleNatives
java.lang.invoke.MethodType$WeakInternSet
java.lang.invoke.MutableCallSite
java.lang.StringBuilder
java.lang.StringValue
java.lang.StringValue$StringCache
java.lang.Thread$Caches
java.lang.UNIXProcess$1
java.lang.UNIXProcess$ProcessPipeInputStream
java.lang.UNIXProcess$ProcessPipeOutputStream
java.lang.UnsupportedOperationException
java.net.AbstractPlainDatagramSocketImpl
java.net.AbstractPlainSocketImpl
java.net.DualStackPlainDatagramSocketImpl
java.net.DualStackPlainSocketImpl
java.net.InMemoryCookieStore
java.net.TwoStacksPlainDatagramSocketImpl
java.net.TwoStacksPlainSocketImpl
java.net.URLClassLoader
java.nio.channels.AsynchronousChannelGroup
java.nio.channels.AsynchronousFileChannel
java.nio.channels.AsynchronousSocketChannel
java.nio.channels.Channels$2
java.nio.channels.Channels$3
java.nio.channels.SelectionKey
java.nio.channels.SocketChannel
java.nio.file.attribute.AclEntry
java.nio.file.attribute.AclEntry$1
java.nio.file.attribute.AclEntry$Builder
java.nio.file.attribute.AclEntryFlag
java.nio.file.attribute.AclEntryPermission
java.nio.file.attribute.AclEntryType
java.nio.file.attribute.AclFileAttributeView
java.nio.file.attribute.AttributeView
java.nio.file.attribute.BasicFileAttributes
java.nio.file.attribute.BasicFileAttributeView
java.nio.file.attribute.DosFileAttributes
java.nio.file.attribute.DosFileAttributeView
java.nio.file.attribute.FileAttribute
java.nio.file.attribute.FileAttributeView
java.nio.file.attribute.FileOwnerAttributeView
java.nio.file.attribute.FileStoreAttributeView
java.nio.file.attribute.FileTime
java.nio.file.attribute.FileTime$1
java.nio.file.attribute.FileTime$DaysAndNanos
java.nio.file.attribute.GroupPrincipal
java.nio.file.attribute.PosixFileAttributes
java.nio.file.attribute.PosixFileAttributeView
java.nio.file.attribute.PosixFilePermission
java.nio.file.attribute.PosixFilePermissions
java.nio.file.attribute.PosixFilePermissions$1
java.nio.file.attribute.UserDefinedFileAttributeView
java.nio.file.attribute.UserPrincipal
java.nio.file.attribute.UserPrincipalLookupService
java.nio.file.attribute.UserPrincipalNotFoundException
java.nio.file.CopyMoveHelper
java.nio.file.Files
java.nio.file.SecureDirectoryStream
java.nio.file.spi.FileSystemProvider
java.sql.DriverManager$2
java.text.DecimalFormatSymbols
java.util.Currency$1
java.util.HashMap
java.util.logging.Level$KnownLevel
java.util.logging.LogManager$LoggerContext
java.util.prefs.FileSystemPreferences$6
java.util.prefs.FileSystemPreferences$7
java.util.Vector$Itr
java.util.Vector$ListItr
java.util.XMLUtils
javax.sql.rowset.serial.SerialClob
sun.dc.DuctusRenderingEngine
sun.dc.DuctusRenderingEngine$FillAdapter
sun.font.CreatedFontTracker$TempFileDeletionHook
sun.font.FcFontConfiguration
sun.font.FontAccess
sun.font.FontConfigManager
sun.font.FontConfigManager$FcCompFont
sun.font.FontConfigManager$FontConfigFont
sun.font.FontConfigManager$FontConfigInfo
sun.font.FontManagerFactory
sun.font.FontManagerFactory$1
sun.font.FontManagerForSGE
sun.font.FontManagerNativeLibrary
sun.font.FontManagerNativeLibrary$1
sun.font.FontScaler
sun.font.FontScalerException
sun.font.FontUtilities
sun.font.FontUtilities$1
sun.font.FreetypeFontScaler
sun.font.GlyphDisposedListener
sun.font.NullFontScaler
sun.font.SunFontManager
sun.font.SunFontManager$1
sun.font.SunFontManager$10
sun.font.SunFontManager$11
sun.font.SunFontManager$12
sun.font.SunFontManager$13
sun.font.SunFontManager$14
sun.font.SunFontManager$2
sun.font.SunFontManager$3
sun.font.SunFontManager$4
sun.font.SunFontManager$5
sun.font.SunFontManager$6
sun.font.SunFontManager$7
sun.font.SunFontManager$8
sun.font.SunFontManager$8$1
sun.font.SunFontManager$9
sun.font.SunFontManager$FamilyDescription
sun.font.SunFontManager$FontRegistrationInfo
sun.font.SunFontManager$T1Filter
sun.font.SunFontManager$TTFilter
sun.font.SunFontManager$TTorT1Filter
sun.font.T2KFontScaler
sun.font.T2KFontScaler$1
sun.font.Underline
sun.font.XRGlyphCache
sun.font.XRGlyphCache$1
sun.font.XRGlyphCacheEntry
sun.font.XRTextRenderer
sun.invoke.util.ValueConversions
sun.jvm.hotspot.CommandProcessor$12
sun.jvm.hotspot.CommandProcessor$12$1
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$BsdDebuggerLocalWorkerThread
sun.jvm.hotspot.runtime.CompilerThread
sun.launcher.LauncherHelper
sun.launcher.resources.launcher
sun.management.jdp.JdpController
sun.management.ManagementFactoryHelper
sun.management.ManagementFactoryHelper$1
sun.management.ManagementFactoryHelper$PlatformLoggingImpl
sun.misc.Hashing
sun.misc.JavaxSecurityAuthKerberosAccess
sun.misc.Launcher$ExtClassLoader
sun.misc.PerfCounter
sun.misc.PostVMInitHook
sun.misc.Service$LazyIterator
sun.net.ftp.FtpClientProvider
sun.net.httpserver.ServerImpl$ServerTimerTask1
sun.net.www.http.HttpCapture
sun.net.www.protocol.http.ntlm.NTLMAuthentication
sun.net.www.protocol.jar.URLJarFile$1
sun.nio.ch.AbstractPollSelectorImpl
sun.nio.ch.AsynchronousChannelGroupImpl
sun.nio.ch.AsynchronousChannelGroupImpl$2
sun.nio.ch.AsynchronousChannelGroupImpl$3
sun.nio.ch.AsynchronousFileChannelImpl
sun.nio.ch.AsynchronousServerSocketChannelImpl
sun.nio.ch.AsynchronousSocketChannelImpl
sun.nio.ch.BsdAsynchronousChannelProvider
sun.nio.ch.CompletedFuture
sun.nio.ch.EPoll
sun.nio.ch.EPollPort
sun.nio.ch.EPollPort$EventHandlerTask
sun.nio.ch.FileChannelImpl$Unmapper
sun.nio.ch.FileDispatcherImpl
sun.nio.ch.Invoker
sun.nio.ch.Iocp
sun.nio.ch.Iocp$EventHandlerTask
sun.nio.ch.KQueue
sun.nio.ch.KQueuePort
sun.nio.ch.KQueuePort$EventHandlerTask
sun.nio.ch.LinuxAsynchronousChannelProvider
sun.nio.ch.MembershipKeyImpl
sun.nio.ch.PendingFuture
sun.nio.ch.PendingIoCache
sun.nio.ch.Port
sun.nio.ch.SctpChannelImpl
sun.nio.ch.SctpMultiChannelImpl
sun.nio.ch.SctpNet
sun.nio.ch.SctpServerChannelImpl
sun.nio.ch.SharedFileLockTable
sun.nio.ch.SimpleAsynchronousFileChannelImpl
sun.nio.ch.SimpleAsynchronousFileChannelImpl$DefaultExecutorHolder
sun.nio.ch.SolarisAsynchronousChannelProvider
sun.nio.ch.SolarisEventPort
sun.nio.ch.SolarisEventPort$EventHandlerTask
sun.nio.ch.ThreadPool
sun.nio.ch.UnixAsynchronousServerSocketChannelImpl
sun.nio.ch.UnixAsynchronousSocketChannelImpl
sun.nio.ch.UnixAsynchronousSocketChannelImpl$1
sun.nio.ch.UnixAsynchronousSocketChannelImpl$2
sun.nio.ch.WindowsAsynchronousChannelProvider
sun.nio.ch.WindowsAsynchronousFileChannelImpl
sun.nio.ch.WindowsAsynchronousFileChannelImpl$LockTask
sun.nio.ch.WindowsAsynchronousFileChannelImpl$ReadTask
sun.nio.ch.WindowsAsynchronousFileChannelImpl$WriteTask
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl$AcceptTask
sun.nio.ch.WindowsAsynchronousSocketChannelImpl
sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ConnectTask
sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask
sun.nio.ch.WindowsAsynchronousSocketChannelImpl$WriteTask
sun.nio.cs.AbstractCharsetProvider$1
sun.nio.cs.ext.EUC_CN
sun.nio.cs.ext.EUC_KR
sun.nio.cs.ext.GBK
sun.nio.cs.ext.IBM1364
sun.nio.cs.ext.IBM1381
sun.nio.cs.ext.IBM1383
sun.nio.cs.ext.IBM930
sun.nio.cs.ext.IBM933
sun.nio.cs.ext.IBM935
sun.nio.cs.ext.IBM937
sun.nio.cs.ext.IBM939
sun.nio.cs.ext.IBM942
sun.nio.cs.ext.IBM943
sun.nio.cs.ext.IBM948
sun.nio.cs.ext.IBM949
sun.nio.cs.ext.IBM950
sun.nio.cs.ext.IBM970
sun.nio.cs.ext.Johab
sun.nio.cs.ext.MS932
sun.nio.cs.ext.MS936
sun.nio.cs.ext.MS949
sun.nio.fs.AbstractPoller
sun.nio.fs.AbstractPoller$Request
sun.nio.fs.AbstractWatchKey
sun.nio.fs.AbstractWatchService
sun.nio.fs.Cancellable
sun.nio.fs.LinuxNativeDispatcher
sun.nio.fs.PollingWatchService
sun.nio.fs.PollingWatchService$3
sun.nio.fs.PollingWatchService$PollingWatchKey
sun.nio.fs.UnixCopyFile
sun.nio.fs.UnixDirectoryStream
sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator
sun.nio.fs.UnixFileAttributes
sun.nio.fs.UnixFileAttributeViews$Basic
sun.nio.fs.UnixFileStore
sun.nio.fs.UnixFileSystem$FileStoreIterator
sun.nio.fs.UnixFileSystemProvider
sun.nio.fs.UnixNativeDispatcher
sun.nio.fs.UnixSecureDirectoryStream
sun.nio.fs.UnixSecureDirectoryStream$BasicFileAttributeViewImpl
sun.nio.fs.UnixSecureDirectoryStream$PosixFileAttributeViewImpl
sun.nio.fs.WindowsDirectoryStream
sun.nio.fs.WindowsDirectoryStream$WindowsDirectoryIterator
sun.nio.fs.WindowsFileAttributes
sun.nio.fs.WindowsFileCopy
sun.nio.fs.WindowsFileSystem$FileStoreIterator
sun.nio.fs.WindowsFileSystemProvider
sun.nio.fs.WindowsNativeDispatcher
sun.nio.fs.WindowsPath
sun.nio.fs.WindowsSecurity
sun.nio.fs.WindowsSecurity$1
sun.nio.fs.WindowsSecurity$Privilege
sun.nio.fs.WindowsSecurityDescriptor
sun.text.normalizer.UBiDiProps
sun.tools.jconsole.inspector.XMBeanAttributes$1
sun.tools.jconsole.inspector.XMBeanAttributes$2
sun.tools.jconsole.inspector.XMBeanAttributes$AttributesListener
sun.util.calendar.LocalGregorianCalendar$1
sun.util.locale.LocaleObjectCache
sun.util.logging.PlatformLogger

#---------------------------------------------------------------------
# J2SE (JDK8 以降)
#---------------------------------------------------------------------
com.sun.beans.util.Cache
com.sun.istack.internal.tools.DefaultAuthenticator
com.sun.java.accessibility.AccessBridge$102
com.sun.java.accessibility.AccessBridge$152
com.sun.java.accessibility.AccessBridge$DefaultNativeWindowHandler
com.sun.java.accessibility.AccessBridge$InvocationUtils
com.sun.java.accessibility.AccessBridge$InvocationUtils$1
com.sun.java.accessibility.AccessBridge$InvocationUtils$CallableWrapper
com.sun.java.accessibility.AccessBridge$ObjectReferences
com.sun.org.apache.xalan.internal.utils.XMLSecurityManager
com.sun.org.apache.xalan.internal.utils.XMLSecurityManager$Limit
com.sun.org.apache.xalan.internal.utils.XMLSecurityManager$NameMap
com.sun.org.apache.xalan.internal.utils.XMLSecurityManager$State
com.sun.org.apache.xerces.internal.utils.XMLSecurityManager
com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$Limit
com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$NameMap
com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$State
com.sun.org.apache.xml.internal.security.algorithms.implementations.SignatureECDSA$SignatureECDSASHA256
com.sun.org.apache.xml.internal.security.algorithms.implementations.SignatureECDSA$SignatureECDSASHA384
com.sun.org.apache.xml.internal.security.algorithms.implementations.SignatureECDSA$SignatureECDSASHA512
com.sun.org.apache.xml.internal.security.c14n.implementations.Canonicalizer11$1
com.sun.org.apache.xml.internal.security.c14n.implementations.Canonicalizer20010315$1
com.sun.org.apache.xml.internal.security.c14n.implementations.CanonicalizerPhysical
com.sun.org.apache.xml.internal.security.encryption.AbstractSerializer
com.sun.org.apache.xml.internal.security.encryption.DocumentSerializer
com.sun.org.apache.xml.internal.security.encryption.Serializer
com.sun.org.apache.xml.internal.security.keys.content.DEREncodedKeyValue
com.sun.org.apache.xml.internal.security.keys.content.KeyInfoReference
com.sun.org.apache.xml.internal.security.keys.content.x509.XMLX509Digest
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.DEREncodedKeyValueResolver
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.KeyInfoReferenceResolver
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.PrivateKeyResolver
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.SecretKeyResolver
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.SingleKeyResolver
com.sun.org.apache.xml.internal.security.keys.keyresolver.implementations.X509DigestResolver
com.sun.org.apache.xml.internal.security.keys.storage.implementations.KeyStoreResolver$KeyStoreIterator$1
com.sun.org.apache.xml.internal.security.signature.Reference$2
com.sun.org.apache.xml.internal.security.signature.Reference$2$1
com.sun.org.apache.xml.internal.security.signature.reference.ReferenceData
com.sun.org.apache.xml.internal.security.signature.reference.ReferenceNodeSetData
com.sun.org.apache.xml.internal.security.signature.reference.ReferenceOctetStreamData
com.sun.org.apache.xml.internal.security.signature.reference.ReferenceSubTreeData
com.sun.org.apache.xml.internal.security.signature.reference.ReferenceSubTreeData$DelayedNodeIterator
com.sun.org.apache.xml.internal.security.utils.ClassLoaderUtils
com.sun.org.apache.xml.internal.security.utils.ClassLoaderUtils$1
com.sun.org.apache.xml.internal.security.utils.DOMNamespaceContext
com.sun.org.apache.xml.internal.security.utils.JDKXPathAPI
com.sun.org.apache.xml.internal.security.utils.JDKXPathFactory
com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverContext
com.sun.org.apache.xml.internal.security.utils.Signature11ElementProxy
com.sun.org.apache.xml.internal.security.utils.XalanXPathAPI
com.sun.org.apache.xml.internal.security.utils.XalanXPathFactory
com.sun.org.apache.xml.internal.security.utils.XPathAPI
com.sun.org.apache.xml.internal.security.utils.XPathFactory
com.sun.org.apache.xml.internal.serializer.utils.SerializerMessages_pt_BR
com.sun.source.util.Trees
com.sun.tools.classfile.ClassFile
com.sun.tools.doclets.internal.toolkit.util.DocFileFactory
com.sun.tools.doclets.internal.toolkit.util.PathDocFileFactory$StandardDocFile
com.sun.tools.internal.ws.processor.modeler.annotation.WebServiceAp
com.sun.tools.internal.ws.wscompile.WsimportOptions$RereadInputStream
com.sun.tools.javac.code.Lint
com.sun.tools.javac.jvm.Gen
com.sun.tools.javac.parser.Tokens$TokenKind
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round
com.sun.tools.javac.resources.javac
com.sun.tools.javac.util.ServiceLoader$LazyIterator
com.sun.tools.javadoc.api.JavadocTaskImpl
com.sun.xml.internal.bind.DatatypeConverterImpl
com.sun.xml.internal.ws.api.message.Packet
com.sun.xml.internal.ws.api.server.Container
com.sun.xml.internal.ws.api.server.MethodUtil
com.sun.xml.internal.ws.api.server.ThreadLocalContainerResolver
com.sun.xml.internal.ws.api.server.ThreadLocalContainerResolver$2
com.sun.xml.internal.ws.api.WSService
com.sun.xml.internal.ws.binding.BindingImpl
com.sun.xml.internal.ws.client.sei.MethodUtil
com.sun.xml.internal.ws.commons.xmlutil.Converter
com.sun.xml.internal.ws.db.DatabindingImpl
com.sun.xml.internal.ws.dump.LoggingDumpTube
com.sun.xml.internal.ws.dump.MessageDumpingFeature
com.sun.xml.internal.ws.dump.MessageDumpingTube
com.sun.xml.internal.ws.policy.privateutil.MethodUtil
com.sun.xml.internal.ws.server.provider.AsyncProviderInvokerTube
com.sun.xml.internal.ws.server.provider.AsyncProviderInvokerTube$AsyncProviderCallbackImpl
com.sun.xml.internal.ws.server.WSEndpointMOMProxy
com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit
com.sun.xml.internal.ws.util.InjectionPlan
com.sun.xml.internal.ws.util.InjectionPlan$Compositor
com.sun.xml.internal.ws.util.ServiceFinder$LazyIterator
java.beans.WeakIdentityMap
java.io.FilterOutputStream
java.lang.invoke.InnerClassLambdaMetafactory
java.lang.invoke.MemberName
java.lang.invoke.MethodHandleImpl
java.lang.invoke.MethodHandles$Lookup
java.lang.invoke.MethodType$ConcurrentWeakInternSet
java.lang.invoke.MethodTypeForm
java.lang.Process
java.lang.reflect.Executable
java.lang.reflect.Parameter
java.lang.reflect.Proxy$ProxyClassFactory
java.lang.reflect.WeakCache
java.lang.reflect.WeakCache$CacheKey
java.lang.reflect.WeakCache$Factory
java.lang.UNIXProcess$2
java.net.URLPermission
java.net.URLPermission$Authority
java.sql.DriverAction
java.sql.JDBCType
java.sql.SQLType
java.time.chrono.AbstractChronology
java.time.format.DateTimeFormatterBuilder$LocalizedPrinterParser
java.time.format.DateTimeFormatterBuilder$ZoneIdPrinterParser
java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser
java.time.format.DateTimeTextProvider
java.time.format.DecimalStyle
java.time.temporal.WeekFields
java.time.zone.TzdbZoneRulesProvider
java.time.zone.ZoneRules
java.time.zone.ZoneRulesProvider
java.time.ZoneOffset
java.util.ArrayPrefixHelpers$CumulateTask
java.util.ArrayPrefixHelpers$DoubleCumulateTask
java.util.ArrayPrefixHelpers$IntCumulateTask
java.util.ArrayPrefixHelpers$LongCumulateTask
java.util.ArraysParallelSortHelpers$EmptyCompleter
java.util.ArraysParallelSortHelpers$FJByte$Merger
java.util.ArraysParallelSortHelpers$FJByte$Sorter
java.util.ArraysParallelSortHelpers$FJChar$Merger
java.util.ArraysParallelSortHelpers$FJChar$Sorter
java.util.ArraysParallelSortHelpers$FJDouble$Merger
java.util.ArraysParallelSortHelpers$FJDouble$Sorter
java.util.ArraysParallelSortHelpers$FJFloat$Merger
java.util.ArraysParallelSortHelpers$FJFloat$Sorter
java.util.ArraysParallelSortHelpers$FJInt$Merger
java.util.ArraysParallelSortHelpers$FJInt$Sorter
java.util.ArraysParallelSortHelpers$FJLong$Merger
java.util.ArraysParallelSortHelpers$FJLong$Sorter
java.util.ArraysParallelSortHelpers$FJObject$Merger
java.util.ArraysParallelSortHelpers$FJObject$Sorter
java.util.ArraysParallelSortHelpers$FJShort$Merger
java.util.ArraysParallelSortHelpers$FJShort$Sorter
java.util.ArraysParallelSortHelpers$Relay
java.util.Collections$SynchronizedNavigableMap
java.util.Collections$SynchronizedNavigableSet
java.util.logging.LogManager$LoggerWeakRef
java.util.SplittableRandom
java.util.stream.AbstractShortCircuitTask
java.util.stream.AbstractTask
java.util.stream.DistinctOps$1
java.util.stream.DoublePipeline$5$1
java.util.stream.FindOps$FindTask
java.util.stream.ForEachOps$ForEachOrderedTask
java.util.stream.ForEachOps$ForEachTask
java.util.stream.IntPipeline$7$1
java.util.stream.LongPipeline$6$1
java.util.stream.Nodes$CollectorTask
java.util.stream.Nodes$SizedCollectorTask
java.util.stream.Nodes$ToArrayTask
java.util.stream.ReduceOps$ReduceTask
java.util.stream.ReferencePipeline$10$1
java.util.stream.ReferencePipeline$7$1
java.util.stream.ReferencePipeline$8$1
java.util.stream.ReferencePipeline$9$1
java.util.stream.SliceOps$SliceTask
java.util.stream.Streams$1
java.util.stream.Streams$2
java.util.stream.StreamSpliterators$DistinctSpliterator
java.util.stream.StreamSpliterators$UnorderedSliceSpliterator
java.util.Vector$VectorSpliterator
javax.activation.CommandMap
javax.activation.FileTypeMap
javax.sql.rowset.spi.SyncFactory$2
jdk.internal.dynalink.beans.OverloadedMethod
jdk.internal.dynalink.ChainedCallSite
jdk.internal.dynalink.support.CallSiteDescriptorFactory
jdk.internal.dynalink.support.ClassMap
jdk.internal.org.objectweb.asm.commons.InstructionAdapter
jdk.internal.org.objectweb.asm.commons.SerialVersionUIDAdder
jdk.internal.org.objectweb.asm.util.Textifier
jdk.internal.util.xml.PropertiesDefaultHandler
jdk.nashorn.api.scripting.ScriptObjectMirror
jdk.nashorn.api.scripting.ScriptUtils
jdk.nashorn.internal.codegen.ClassEmitter
jdk.nashorn.internal.codegen.CodeGenerator
jdk.nashorn.internal.codegen.CompilationPhase$8
jdk.nashorn.internal.codegen.types.Type
jdk.nashorn.internal.ir.debug.ObjectSizeCalculator
jdk.nashorn.internal.objects.Global
jdk.nashorn.internal.objects.NativeArray
jdk.nashorn.internal.objects.NativeArray$6
jdk.nashorn.internal.objects.NativeDate
jdk.nashorn.internal.objects.NativeObject
jdk.nashorn.internal.runtime.AccessorProperty
jdk.nashorn.internal.runtime.arrays.ArrayData
jdk.nashorn.internal.runtime.arrays.IteratorAction
jdk.nashorn.internal.runtime.CodeStore$2
jdk.nashorn.internal.runtime.CodeStore$3
jdk.nashorn.internal.runtime.Context
jdk.nashorn.internal.runtime.DebuggerSupport
jdk.nashorn.internal.runtime.JSType
jdk.nashorn.internal.runtime.linker.JavaAdapterFactory$AdapterInfo
jdk.nashorn.internal.runtime.linker.LinkerCallSite
jdk.nashorn.internal.runtime.linker.LinkerCallSite$1
jdk.nashorn.internal.runtime.linker.NashornCallSiteDescriptor$1
jdk.nashorn.internal.runtime.ListAdapter
jdk.nashorn.internal.runtime.PropertyListeners
jdk.nashorn.internal.runtime.PropertyMap
jdk.nashorn.internal.runtime.RecompilableScriptFunctionData
jdk.nashorn.internal.runtime.regexp.joni.Regex
jdk.nashorn.internal.runtime.ScriptFunctionData
jdk.nashorn.internal.runtime.ScriptingFunctions
jdk.nashorn.internal.runtime.ScriptingFunctions$1
jdk.nashorn.internal.runtime.ScriptingFunctions$2
jdk.nashorn.internal.runtime.ScriptLoader
jdk.nashorn.internal.runtime.ScriptObject
jdk.nashorn.internal.runtime.ScriptRuntime
jdk.nashorn.internal.runtime.Source
jdk.nashorn.internal.runtime.Source$URLData
jdk.nashorn.internal.runtime.UserAccessorProperty
sun.jvm.hotspot.CommandProcessor$17
sun.jvm.hotspot.CommandProcessor$17$1
sun.management.DiagnosticCommandImpl
sun.management.OperatingSystemImpl
sun.misc.GThreadHelper
sun.net.ExtendedOptionsImpl
sun.net.PortConfig
sun.nio.ch.sctp.SctpChannelImpl
sun.nio.ch.sctp.SctpMultiChannelImpl
sun.nio.ch.sctp.SctpNet
sun.nio.ch.sctp.SctpServerChannelImpl
sun.nio.cs.ext.IBM300
sun.nio.cs.ext.JIS_X_0208
sun.nio.cs.ext.JIS_X_0208_MS5022X
sun.nio.cs.ext.JIS_X_0208_MS932
sun.nio.cs.ext.JIS_X_0208_Solaris
sun.nio.cs.ext.JIS_X_0212
sun.nio.cs.ext.JIS_X_0212_MS5022X
sun.nio.cs.ext.JIS_X_0212_Solaris
sun.nio.cs.ext.PCK
sun.nio.cs.ext.SJIS
sun.util.calendar.CalendarSystem$1
sun.util.calendar.ZoneInfoFile$1
sun.util.locale.provider.AuxLocaleProviderAdapter
sun.util.locale.provider.HostLocaleProviderAdapterImpl$2
sun.util.locale.provider.HostLocaleProviderAdapterImpl$3
sun.util.locale.provider.HostLocaleProviderAdapterImpl$4
sun.util.locale.provider.JRELocaleProviderAdapter
sun.util.locale.provider.LocaleProviderAdapter
sun.util.locale.provider.LocaleResources
sun.util.locale.provider.LocaleServiceProviderPool
sun.util.locale.provider.SPILocaleProviderAdapter$BreakIteratorProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$CalendarDataProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$CalendarNameProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$CollatorProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$CurrencyNameProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$DateFormatProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$DateFormatSymbolsProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$DecimalFormatSymbolsProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$LocaleNameProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$NumberFormatProviderDelegate
sun.util.locale.provider.SPILocaleProviderAdapter$TimeZoneNameProviderDelegate
sun.util.locale.provider.TimeZoneNameUtility
sun.util.resources.OpenListResourceBundle
sun.util.resources.ParallelListResourceBundle
sun.util.xml.PlatformXmlPropertiesProvider

#---------------------------------------------------------------------
# J2EE
#---------------------------------------------------------------------
javax.activation.*
javax.annotation.*
javax.ejb.*
javax.el.*
javax.jms.*
javax.mail.*
javax.management.*
javax.persistence.*
javax.resource.*
javax.servlet.*
javax.transaction.*

付録D　各バージョンでの主な機能変更

ここでは，11-30よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-30での主な機能変更については，「1.5　アプリケーションサーバ 11-30での主な機能変更」を参照してください。

説明内容は次のとおりです。

アプリケーションサーバの各バージョンで変更になった主な機能と，その概要を説明しています。機能の詳細については，「参照先マニュアル」の「参照個所」の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての11-30のマニュアルでの主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「アプリケーションサーバ」は省略しています。

付録D.1　11-20での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒1　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSF 2.3への対応

JSF 2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

3章

JAX-RS 2.1への対応

JAX-RS 2.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

4章

WebSocket 1.1への対応

WebSocket 1.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

5章

Servlet 4.0への対応

Servlet 4.0に対応しました。これに伴い，NIO HTTPサーバでHTTP/2に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

CDI Managed BeanでのJPA利用

CDI Managed BeanでのJPA利用に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

JPA 2.2への対応

JPA 2.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 2.0への対応

CDI 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

WEB-INF/lib内のCDIへの対応

WARファイルのWEB-INF/lib以下のJARファイルからCDIを利用できるようにしました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 2.0への対応

BV 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JSON-P 1.1への対応

JSON-P 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

JSON-B 1.0への対応

JSON-B 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

13章

付録D.2　11-10での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒2　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

付録B.4

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒3　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSP2.3への対応

JSP2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

15章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒4　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッションマネージャの指定機能の追加

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

機能解説 基本・開発編(Web コンテナ)

2.22

付録D.3　11-00での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒5　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

（凡例）−：マニュアル全体を参照する

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒6　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0/3.1への対応

Servlet 3.0の非同期サーブレット，およびServlet 3.1の非同期I/O系APIに対応しました。

機能解説 基本・開発編(Webコンテナ)

8.1

EL 3.0への対応

EL 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.3

JSF 2.2への対応

JSF 2.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JAX-RS 2.0への対応

JAX-RS 2.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

4章

WebSocket 1.0への対応

WebSocket 1.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

5章

NIO HTTPサーバ機能の追加

従来のリダイレクタ機能やインプロセスHTTPサーバ機能に代わり，非同期サーブレットやWebSocketなどのノンブロッキングI/O処理に対応したインプロセスのHTTPサーバとして，NIO HTTPサーバ機能を追加しました。

機能解説 基本・開発編(Webコンテナ)

7章

JPA 2.1への対応

JPA 2.1に対応し，JPA 2.1対応のJPAプロバイダを利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 1.2への対応

CDI 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 1.1への対応

Bean Validation 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

Java Batch 1.0への対応

Batch Applications for the Java Platform （Java Batch） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

11章

JSON-P 1.0への対応

Java API for JSON Processing（JSON-P） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

Concurrency Utilities 1.0への対応

Concurrency Utilities for Java EE 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

14章

WebSocket通信への対応

HTTP ServerからJ2EEサーバにWebSocket通信を中継する機能を追加しました。

HTTP Server

4.15

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒7　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録D

(4)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒8　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録D.4　09-87での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒9　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

Java SE 11の機能が使用できるようになりました。

機能解説 保守／移行編

9章

付録D.5　09-80での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒10　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能におけるラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

Java SE 9の機能が使用できるようになりました。

機能解説 保守／移行編

9章

(2)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒11　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録C

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録C

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録C

付録D.6　09-70での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒12　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのJSPコンパイルバージョンの追加

J2EEサーバでのJSPから生成されたサーブレットのコンパイル方法に「JDK1.7の仕様に従ったコンパイル」と「JDK7の仕様に従ったコンパイル」を追加する。

運用管理ポータル操作ガイド

10.8.4

リファレンス 定義編(サーバ定義)

4.11.2

JDK8でのメタスペース対応

JavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する。

システム構築・運用ガイド

付録A.2

運用管理ポータル操作ガイド

10.8.7

リファレンス 定義編(サーバ定義)

5.2.1，5.2.2，8.2.3

統合ユーザ管理でのユーザ認証のSHA-2対応

統合ユーザ管理でのユーザ認証のハッシュアルゴリズムとしてSHA-224，SHA-256，SHA-384，SHA-512を追加する。

機能解説 セキュリティ管理機能編

5.3.1，5.3.9，5.10.7，11.4.3，12.4.3，12.5.3，13.2，14.2.2

Red Hat Enterprise Linux Server 7での自動起動と自動再起動および自動停止の追加

Red Hat Enterprise Linux Server 7でのManagement Serverと運用管理エージェントの自動起動と自動再起動および自動停止方法を追加する。

このマニュアル

2.6.3，2.6.4，2.6.5

リファレンス コマンド編

7.2

(2)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒13　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒14　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録D.7　09-60での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒15　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

リファレンス 定義編（サーバ定義）

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.16

(2)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒16　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.17

(3)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒17　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

リファレンス 定義編（サーバ定義）

14.2

付録D.8　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表D‒18　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

(2)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒19　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

仮想化システム構築・運用ガイド

1.1.2

(3)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒20　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC 4.0仕様への対応

DB ConnectorでJDBC 4.0仕様のHiRDB Type4 JDBC Driver，およびSQL ServerのJDBCドライバに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6.3

Portable Global JNDI名での命名規則の緩和

Portable Global JNDI名に使用できる文字を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

2.4.3

Servlet 3.0仕様への対応

Servlet 3.0のHTTP Cookieの名称，およびURLのパスパラメタ名の変更が，Servlet 2.5以前のバージョンでも使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7

Bean Validationと連携できるアプリケーションの適用拡大

CDIやユーザアプリケーションでもBean Validationを使って検証できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JavaMailへの対応

JavaMail 1.4に準拠したAPIを使用したメール送受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

javacoreコマンドが使用できるOSの適用拡大

javacoreコマンドを使って，Windowsのスレッドダンプを取得できるようになりました。

リファレンス コマンド編

javacore（スレッドダンプの取得／Windowsの場合）

(4)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒21　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

機能解説 保守／移行編

5.7.2，5.7.3

リファレンス 定義編(サーバ定義)

14.1，14.2，14.4

明示管理ヒープ機能の効率的な適用への対応

自動解放処理時間を短縮し，明示管理ヒープ機能を効率的に適用するための機能として，Explicitヒープに移動するオブジェクトを制御できる機能を追加しました。

Explicitメモリブロックへのオブジェクト移動制御機能

明示管理ヒープ機能適用除外クラス

機能解説 拡張編

7.2.2，7.6.5，7.10，7.13.1，7.13.3

機能解説 保守／移行編

5.5

クラス別統計情報の出力範囲拡大

クラス別統計情報を含んだ拡張スレッドダンプに，staticフィールドを基点とした参照関係を出力できるようになりました。

機能解説 保守／移行編

9.6

(5)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒22　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

EADsセッションフェイルオーバ機能のサポート

EADsと連携してセッションフェイルオーバ機能を実現するEADsセッションフェイルオーバ機能をサポートしました。

機能解説 拡張編

5章

WARによる運用

WARファイルだけで構成されたWARアプリケーションをJ2EEサーバにデプロイできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.2.1

機能解説 基本・開発編(コンテナ共通機能)

18.9

リファレンス コマンド編

cjimportwar（WARアプリケーションのインポート）

運用管理機能の同期実行による起動と停止

運用管理機能（Management Serverおよび運用管理エージェント）の起動および停止を，同期実行するオプションを追加しました。

このマニュアル

2.6.1，2.6.2，2.6.3，2.6.4

リファレンス コマンド編

adminagentctl（運用管理エージェントの起動と停止），mngautorun（自動起動および自動再起動の設定／設定解除），mngsvrctl（Management Serverの起動／停止／セットアップ）

明示管理ヒープ機能でのExplicitメモリブロックの強制解放

javagcコマンドで，Explicitメモリブロックの解放処理を任意のタイミングで実行できるようになりました。

機能解説 拡張編

7.6.1，7.9

リファレンス コマンド編

javagc（GCの強制発生）

(6)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒23　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

snapshotlog（snapshotログの収集）コマンドで定義ファイルだけを収集できるようになりました。

機能解説 保守／移行編

2.3

リファレンス コマンド編

snapshotlog（snapshotログの収集）

cjenvsetupコマンドのログ出力

Component Container管理者のセットアップ（cjenvsetupコマンド）の実行情報がメッセージログに出力されるようになりました。

システム構築・運用ガイド

4.1.4

機能解説 保守／移行編

4.20

リファレンス コマンド編

cjenvsetup（Component Container管理者のセットアップ）

BIG-IP v11のサポート

使用できる負荷分散機の種類にBIG-IP v11が追加になりました。

システム構築・運用ガイド

4.7.2

仮想化システム構築・運用ガイド

2.1

明示管理ヒープ機能のイベントログへのCPU時間の出力

Explicitメモリブロック解放処理に掛かったCPU時間が，明示管理ヒープ機能のイベントログに出力されるようになりました。

機能解説 保守／移行編

5.11.3

ユーザ拡張性能解析トレースの機能拡張

ユーザ拡張性能解析トレースで，次の機能を追加しました。

トレース対象の指定方法を通常のメソッド単位の指定方法に加えて，パッケージ単位またはクラス単位で指定できるようになりました。

使用できるイベントIDの範囲を拡張しました。

ユーザ拡張性能解析トレース設定ファイルに指定できる行数の制限を緩和しました。

ユーザ拡張性能解析トレース設定ファイルでトレース取得レベルを指定できるようになりました。

機能解説 保守／移行編

7.5.2，7.5.3，8.25.1

Session Beanの非同期呼び出し使用時の情報解析向上

PRFトレースのルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.17.3

付録D.9　09-00での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒24　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

仮想化システム構築・運用ガイド

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

運用管理ポータル操作ガイド

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒25　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0への対応

Servlet 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

8章

EJB 3.1への対応

EJB 3.1に対応しました。

機能解説 基本・開発編(EJBコンテナ)

2章

JSF 2.1への対応

JSF 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JSTL 1.2への対応

JSTL 1.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

CDI 1.0への対応

CDI 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

Portable Global JNDI名の利用

Portable Global JNDI名を利用したオブジェクトのルックアップができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.4

JAX-WS 2.2への対応

JAX-WS 2.2に対応しました。

Webサービス開発ガイド

1.1，16.1.5，16.1.7，16.2.1，16.2.6，16.2.10，16.2.12，16.2.13，16.2.14，16.2.16，16.2.17，16.2.18，16.2.20，16.2.22，19.1，19.2.3，37.2，37.6.1，37.6.2，37.6.3

JAX-RS 1.1への対応

JAX-RS 1.1に対応しました。

Webサービス開発ガイド

1.1，1.2.2，1.3.2，1.4.2，1.5.1，1.6，2.3，11章，12章，13章，17章，24章，39章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒26　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

SSL/TLS通信でのTLSv1.2の使用

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒27　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webコンテナ全体の実行待ちキューの総和の監視

Webコンテナ全体の実行待ちキューの総和を稼働情報に出力して監視できるようになりました。

このマニュアル

3章

アプリケーションの性能解析トレース（ユーザ拡張トレース）の出力

ユーザが開発したアプリケーションの処理性能を解析するための性能解析トレースを，アプリケーションの変更をしないで出力できるようになりました。

機能解説 保守／移行編

7章

仮想化環境でのユーザスクリプトを使用した運用

任意のタイミングでユーザ作成のスクリプト（ユーザスクリプト）を仮想サーバ上で実行できるようになりました。

仮想化システム構築・運用ガイド

7.8

運用管理ポータル改善

運用管理ポータルの次の画面で，手順を示すメッセージを画面に表示するように変更しました。

［設定情報の配布］画面

Webサーバ，J2EEサーバおよびSFOサーバの起動画面

WebサーバクラスタとJ2EEサーバクラスタの一括起動，一括再起動および起動画面

運用管理ポータル操作ガイド

10.10.1，11.9.2，11.10.2，11.10.4，11.10.6，11.11.2，11.12.2，11.12.4，11.12.6

運用管理機能の再起動機能の追加

運用管理機能（Management Serverおよび運用管理エージェント）で自動再起動が設定できるようになり，運用管理機能で障害が発生した場合でも運用が継続できるようになりました。また，自動起動の設定方法も変更になりました。

このマニュアル

2.4.1，2.4.2，2.6.3，2.6.4

リファレンス コマンド編

mngautorun（自動起動および自動再起動の設定／設定解除）

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒28　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

3.2.1

Webサーバの名称の変更

アプリケーションサーバに含まれるWebサーバの名称をHTTP Serverに変更しました。

HTTP Server

−

BIG-IPのAPI（SOAPアーキテクチャ）を使用した直接接続への対応

BIG-IP（負荷分散機）でAPI（SOAPアーキテクチャ）を使用した直接接続に対応しました。

また，APIを使用した直接接続を使用する場合に，負荷分散機の接続環境を設定する方法が変更になりました。

システム構築・運用ガイド

4.7.3，付録J

仮想化システム構築・運用ガイド

2.1，付録C

機能解説 セキュリティ管理機能編

8.2，8.4，8.5，8.6，18.2.1，18.2.2，18.2.3

（凡例）−：マニュアル全体を参照する

付録D.10　08-70での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒29　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（Connector属性ファイルの設定内容）の設定，および接続テストができるようになりました。また，運用管理ポータルの画面で，J2EEアプリケーション（earファイルおよびzipファイル）をManagement Serverにアップロードできるようになりました。

ファーストステップガイド

3.5

運用管理ポータル操作ガイド

−

page/tagディレクティブのimport属性暗黙インポート機能の追加

page/tagディレクティブのimport属性暗黙インポート機能を使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応

仮想サーバへのアプリケーションサーバ構築時に，仮想サーバに対するJP1製品の環境設定を，フックスクリプトで自動的に設定できるようになりました。

仮想化システム構築・運用ガイド

7.7.2

統合ユーザ管理機能の改善

ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。

簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。

また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。

機能解説 セキュリティ管理機能編

5章，14.2.2

運用管理ポータル操作ガイド

3.5，10.8.1

HTTP Server設定項目の拡充

簡易構築定義ファイルおよび運用管理ポータルの画面で，HTTP Serverの動作環境を定義するディレクティブ（httpsd.confの設定内容）を直接設定できるようになりました。

システム構築・運用ガイド

4.1.21

運用管理ポータル操作ガイド

10.9.1

リファレンス 定義編(サーバ定義)

4.10

（凡例）−：マニュアル全体を参照する

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒30　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ejb-jar.xmlの指定項目の追加

ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.15

パラレルコピーガーベージコレクションへの対応

パラレルコピーガーベージコレクションを選択できるようになりました。

リファレンス 定義編(サーバ定義)

14.5

Connector 1.5仕様に準拠したInboundリソースアダプタのグローバルトランザクションへの対応

Connector 1.5仕様に準拠したリソースアダプタでTransacted Deliveryを使用できるようにしました。これによって，Message-driven Beanを呼び出すEISがグローバルトランザクションに参加できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3.16.3

TP1インバウンドアダプタのMHPへの対応

TP1インバウンドアダプタを使用してアプリケーションサーバを呼び出すOpenTP1のクライアントとして，MHPを使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

cjrarupdateコマンドのFTPインバウンドアダプタへの対応

cjrarupdateコマンドでバージョンアップできるリソースアダプタにFTPインバウンドアダプタを追加しました。

リファレンス コマンド編

2.2

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒31　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

データベースセッションフェイルオーバ機能の改善

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

機能解説 拡張編

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

リファレンス 定義編(サーバ定義)

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加しました。

機能解説 拡張編

7.11

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒32　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

仮想化システム構築・運用ガイド

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒33　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

仮想化システム構築・運用ガイド

2.1

リファレンス 定義編(サーバ定義)

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

付録D.11　08-53での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒34　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

仮想化システム構築・運用ガイド

2章，3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒35　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒36　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，9章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒37　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

仮想化システム構築・運用ガイド

1.3，2.1

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒38　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Microsoft IIS 7.0およびMicrosoft IIS 7.5への対応

WebサーバとしてMicrosoft IIS 7.0およびMicrosoft IIS 7.5に対応しました。

−

−

HiRDB Version 9およびSQL Server 2008への対応

データベースとして次の製品に対応しました。

HiRDB Server Version 9

HiRDB/Developer's Kit Version 9

HiRDB/Run Time Version 9

SQL Server 2008

また，SQL Server 2008に対応するJDBCドライバとして，SQL Server JDBC Driverに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

3章

（凡例）−：該当なし。

付録D.12　08-50での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表D‒39　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更

Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグおよびservlet-mappingタグの指定を必須から任意に変更しました。

リファレンス 定義編(サーバ定義)

2.2.3

論理サーバのネットワークリソース使用

J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。

このマニュアル

1.2.3，5.2，5.7

サンプルプログラムの実行手順の簡略化

一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。

ファーストステップガイド

3.5

システム構築・運用ガイド

付録L

運用管理ポータルの画面の動作の改善

画面の更新間隔のデフォルトを「更新しない」から「3秒」に変更しました。

運用管理ポータル操作ガイド

7.4.1

セットアップウィザードの完了画面の改善

セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。

システム構築・運用ガイド

2.2.6

仮想化環境の構築

ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。

仮想化システム構築・運用ガイド

3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表D‒40　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

OpenTP1からの呼び出しへの対応

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JMSへの対応

JMS 1.1仕様に対応したCJMSプロバイダ機能を使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

7章

Java SE 6への対応

Java SE 6の機能が使用できるようになりました。

機能解説 保守／移行編

5.5，5.8.1

ジェネリクスの使用への対応

EJBでジェネリクスを使用できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

4.2.18

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒41　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

機能解説 拡張編

7章

データベースセッションフェイルオーバ機能のURI単位での抑止

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

機能解説 拡張編

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。

仮想化システム構築・運用ガイド

−

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒42　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，Management Serverのコマンド，またはSmart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。

システム構築・運用ガイド

4.1.15

運用管理ポータル操作ガイド

2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録E.2

リファレンス コマンド編

1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）

仮想化環境の運用

仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。

仮想化システム構築・運用ガイド

4章，6章

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒43　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。

機能解説 保守／移行編

9.8

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。

9.9

クラス別統計情報解析機能

クラス別統計情報をCSV形式で出力できるようになりました。

9.10

論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え

Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。

このマニュアル

18.4.3，18.5.3，16.2.2，16.3.3，16.3.4

ホスト単位管理モデルを対象とした系切り替えシステム

クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。

16章

ACOS（AX2000，BS320）のサポート

使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3，4.7.5，4.7.6，付録J，付録J.2

リファレンス 定義編(サーバ定義)

4.2.4，4.3.2，4.3.4，4.7.1

CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加

CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.7.3

OutOfMemoryError発生時の運用管理エージェントの強制終了

JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。

機能解説 保守／移行編

2.5.5

スレッドの非同期並行処理

TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

機能解説 拡張編

−

付録D.13　08-00での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表D‒44　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.3

(2)　標準機能への対応

標準機能への対応を目的として変更した項目を次の表に示します。

表D‒45　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 2.5への対応

Servlet 2.5に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.2，2.5.4，2.6，8章

JSP 2.1への対応

JSP 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.1，2.3.3，2.5，2.6，8章

JSPデバッグ

MyEclipseを使用した開発環境でJSPデバッグができるようになりました。※

機能解説 基本・開発編(Webコンテナ)

2.4

タグライブラリのライブラリJARへの格納とTLDのマッピング

タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.4

application.xmlの省略

J2EEアプリケーションでapplication.xmlが省略できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

アノテーションとDDの併用

アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.5

アノテーションのJava EE 5標準準拠（デフォルトインターセプタ）

デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

@Resourceの参照解決

@Resourceでリソースの参照解決ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.4

JPAへの対応

JPA仕様に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

注※　09-00以降では，WTPを使用した開発環境でJSPデバッグ機能を使用できます。

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表D‒46　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

機能解説 拡張編

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，FullGC発生を抑止できるようになりました。

機能解説 拡張編

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表D‒47　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

運用管理ポータル操作ガイド

1.1.3

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表D‒48　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効なHTTP Cookieの削除

無効なHTTP Cookieを削除できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7.4

ネーミングサービスの障害検知

ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.9

コネクション障害検知タイムアウト

コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3.15.1

Oracle11gへの対応

データベースとしてOracle11gが使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3章

バッチ処理のスケジューリング

バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。

機能解説 拡張編

4章

バッチ処理のログ

バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時のリトライ回数とリトライ間隔を指定できるようになりました。

リファレンス 定義編(サーバ定義)

3.2.5

snapshotログ

snapshotログの収集内容が変更されました。

機能解説 保守／移行編

付録A.1，付録A.2

メソッドキャンセルの保護区公開

メソッドキャンセルの対象外となる保護区リストの内容を公開しました。

このマニュアル

付録C

統計前のGC選択機能

クラス別統計情報を出力する前に，GCを実行するかどうかを選択できるようになりました。

機能解説 保守／移行編

9.7

Survivor領域の年齢分布情報出力機能

Survivor領域のJavaオブジェクトの年齢分布情報をJavaVMログファイルに出力できるようになりました。

機能解説 保守／移行編

9.11

ファイナライズ滞留解消機能

JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。

−

−

サーバ管理コマンドの最大ヒープサイズの変更

サーバ管理コマンドが使用する最大ヒープサイズが変更されました。

リファレンス 定義編(サーバ定義)

5.2.1，5.2.2

推奨しない表示名を指定された場合の対応

J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。

メッセージ(構築／運用／開発用)

KDJE42374-W

（凡例）−：09-00で削除された機能です。

付録E　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

.mngsvrmonitorrc[1]、[2]

.mngsvrutilrc[1]、[2]

数字

09-70での主な機能変更[1]

09-80での主な機能変更[1]

09-87での主な機能変更[1]

1:1系切り替えシステム[1]、[2]

1:1系切り替えシステムで実行できる運用操作[1]

1:1系切り替えシステムでの系切り替え処理の流れ[1]

1:1系切り替えシステムでの系切り替えの動作[1]

1:1系切り替えシステムの起動と停止（UNIXの場合）[1]

1:1系切り替えシステムのシステム構成例[1]

11-00での主な機能変更[1]

11-10での主な機能変更[1]

11-20での主な機能変更[1]

A

actcommand[1]

adminagent.adapter.bind_host[1]、[2]、[3]、[4]

adminagent.cluster.localaddress.check[1]、[2]

adminagent.j2ee.process.console_event.enabled[1]

adminagent.j2ee.process.console_log.enabled[1]

adminagent.process.consolelog.enabled[1]

adminagent.process.consolelog.filenum[1]

adminagent.process.consolelog.filesize[1]

adminagent.properties[1]、[2]、[3]

adminagent.userserver.process.console_log.enabled[1]

adminagentcheck[1]

agentaddr[1]、[2]

auditsetup[1]

C

cjjspc[1]

cjlistthread[1]

cjstopthread[1]

cluster[1]

cmx_stop_targetコマンド[1]

com.cosminexus.mngsvr.externals.jp1event.JP1EventHandler[1]

com.cosminexus.mngsvr.jp1event.enabled[1]

Component Container管理者[1]

Connector属性ファイルの設定[1]

cosminexus.xmlでのイベントの発行機能の定義[1]

cosminexus.xmlでのリソース枯渇監視機能の定義[1]

CTMの稼働統計情報の収集方法[1]

CTMの稼働統計情報の出力先と出力情報[1]

CTMの稼働統計情報の出力例[1]

CTMのスケジュールキューの閉塞処理[1]

D

DB Connectorの稼働情報ファイルに出力される情報[1]

E

ejbserver.distributedtx.ots.status.directory1[1]、[2]、[3]

ejbserver.distributedtx.XATransaction.enabled[1]、[2]、[3]

ejbserver.instrumentation.enabled[1]

ejbserver.manager.agent.JP1EventAgent.enabled[1]

ejbserver.manager.agent.MEventAgent.enabled[1]

EJBクライアントアプリケーションで使用するコマンドの監査ログの出力ポイント[1]

Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法[1]

Enterprise Beanを実行するための機能（EJBコンテナ）[1]

F

FullGC回数[1]

H

HAモニタ[1]

HAモニタによる1:1系切り替えシステム[1]

HAモニタの環境設定[1]

htc.clienthandleraddr[1]、[2]

HTTP Serverで使用するコマンド，およびHTTP Serverに対する操作の監査ログの出力ポイント（UNIXの場合）[1]

HTTP Serverで使用するコマンド，およびHTTP Serverに対する操作の監査ログの出力ポイント（Windowsの場合）[1]

HTTPリクエスト実行待ちキュー監視[1]

HTTPリクエスト実行待ちキュー枯渇監視情報[1]

I

IM構成ホスト[1]

J

J2EEアプリケーションからネットワークリソースにアクセスする[1]

J2EEアプリケーションからのネットワークリソースへのアクセス[1]

J2EEアプリケーション起動／停止ジョブ定義用の定義プログラム[1]

J2EEアプリケーションごとのメソッドタイムアウト時間[1]

J2EEアプリケーション実行時間監視で出力されるログ情報[1]

J2EEアプリケーション実行時間の監視[1]

J2EEアプリケーション実行時間の監視とは[1]

J2EEアプリケーション実行時間の監視の設定[1]

J2EEアプリケーション停止処理の流れ[1]

J2EEアプリケーション停止の種類[1]

J2EEアプリケーションの入れ替え[1]、[2]

J2EEアプリケーションの入れ替えと保守[1]、[2]

J2EEアプリケーションの入れ替え方法[1]

J2EEアプリケーションの運用[1]

J2EEアプリケーションの運用機能[1]

J2EEアプリケーションの運用機能に必要な定義[1]

J2EEアプリケーションの強制停止[1]

J2EEアプリケーションの構成パターンと閉塞方法[1]

J2EEアプリケーションの実行時間の監視とキャンセル[1]、[2]

J2EEアプリケーションの実行時間の監視とキャンセルの流れ[1]

J2EEアプリケーションの実行状態の確認[1]

J2EEアプリケーションの状態[1]

J2EEアプリケーションの世代管理[1]

J2EEアプリケーションの停止[1]、[2]

J2EEアプリケーションの閉塞[1]

J2EEアプリケーションの名称変更[1]

J2EEアプリケーションを入れ替える[1]

J2EEアプリケーションを開始するときのJSPの事前コンパイル[1]

J2EEアプリケーションを強制停止する[1]

J2EEアプリケーションを停止する[1]

J2EEサーバ起動時に出力されるログ情報[1]

J2EEサーバ共通用メッセージマッピングファイル[1]

J2EEサーバ個別用メッセージマッピングファイル[1]

J2EEサーバで使用するコマンドの監査ログの出力ポイント[1]

J2EEサーバの運用監視の設定[1]

J2EEサーバの機能[1]

J2EEサーバ用JP1イベントの設定[1]

J2EEユーザ用JP1イベントの設定[1]

JavaVMの稼働情報ファイルに出力される情報[1]

jbs_route.conf[1]

jbs_route.confファイル[1]

jbsrt_distrib[1]、[2]

JCAリソースの稼働情報ファイルに出力される情報[1]

JP1[1]

JP1/AJSと連携してシステムの自動運転をする場合のシステム構築例（J2EEサーバの場合）[1]

JP1/AJSを使用したシステムの自動運転[1]

JP1/AJSを使用したバッチアプリケーションの自動実行[1]

JP1/AJS - Agent[1]

JP1/AJS - Manager[1]

JP1/AJS - View[1]

JP1/Baseのイベントサーバ名の設定[1]

JP1/Baseの構成定義の作成[1]、[2]

JP1/Baseの構成定義ファイル[1]

JP1/IM[1]

JP1/IMと連携した障害監視処理の流れ[1]

JP1/IM連携用モニタ起動設定ファイル[1]

JP1/IM - View[1]

JP1イベント[1]

JP1イベントとして発行されるアプリケーションサーバシステムの障害情報[1]

JP1イベントのフィルタリング設定[1]

JP1連携による運用管理機能[1]

JSP事前コンパイル機能[1]、[2]

jstartrecover[1]

K

KDJE54000-I[1]

KDJE54001-I[1]

KDJE54051-E[1]

L

LANの状態設定[1]

localaddr[1]、[2]、[3]、[4]

M

maction.properties[1]

Management Serverで使用するコマンドの監査ログの出力ポイント[1]

Management Serverの自動再起動[1]

Management Serverの設定情報のコピー手順[1]

Management Server用JP1イベントの設定[1]

Managementアクション[1]、[2]、[3]

Managementアクション実行コマンド[1]

Managementアクション実行コマンドのコマンドファイルで使用できる環境変数[1]

Managementアクション実行コマンドの設定[1]

Managementアクション実行コマンドの動作[1]

Managementアクション実行コマンドのワーキングディレクトリ[1]

Managementアクション実行用プロパティファイル[1]、[2]

Managementアクション実行用プロパティファイルの設定[1]

Managementアクションの実行制御[1]

Managementアクションの実行制御方式[1]

Managementイベント[1]、[2]、[3]

Managementイベントによる処理の自動実行の設定[1]

Managementイベントによる処理の自動実行の設定手順[1]

Managementイベント発行機能を利用する各機能の設定[1]

Managementイベント発行サーバを再起動するサンプル[1]

Managementイベント発行時の動作の設定[1]

Managementイベント発行の有効化[1]

Managementイベント発行用メッセージIDリストファイル[1]

Managementイベント発行用メッセージIDリストファイルの設定[1]

manager.jp1event.system.filtering.severity.alert[1]

manager.jp1event.system.filtering.severity.critical[1]

manager.jp1event.system.filtering.severity.emergency[1]

manager.jp1event.system.filtering.severity.error[1]

manager.jp1event.system.filtering.severity.information[1]

manager.jp1event.system.filtering.severity.notice[1]

manager.jp1event.system.filtering.severity.warning[1]

manager.jp1event.user.filtering.enabled[1]

manager.jp1event.user.filtering.filter[1]

manager.jp1event.user.mapping.level.config[1]

manager.jp1event.user.mapping.level.fine[1]

manager.jp1event.user.mapping.level.finer[1]

manager.jp1event.user.mapping.level.finest[1]

manager.jp1event.user.mapping.level.info[1]

manager.jp1event.user.mapping.level.severe[1]

manager.jp1event.user.mapping.level.warning[1]

manager.mevent.message_id.list[1]

manager.mevent.retry.interval[1]

manager.mevent.retry.limit[1]

manager.mevent.send.max[1]

manager.mevent.send.timeout[1]

manager.mevent.sender.bind.host[1]

Message-driven Beanの稼働情報ファイルに出力される情報[1]

MIBオブジェクト[1]

mngagent.connector.host[1]、[2]

mngsvr_adapter_setup[1]

mngsvr.jp1event.event_server_name[1]

mngsvr.myhost.name[1]、[2]

mngsvrctl setup[1]、[2]

mngsvrutil.connect.host[1]、[2]

mngsvrutil.connect.password[1]、[2]

mngsvrutil.connect.userid[1]、[2]

mngsvrutil.properties[1]

mngsvrutilcl.properties[1]

mngsvrutilコマンドの実行環境の設定[1]

monbegin[1]、[2]、[3]

monend[1]、[2]、[3]

monsbystp[1]、[2]

monswap[1]、[2]

mserver.jp1event.system.mapping.properties[1]

mserver.properties[1]、[2]

mstrexport[1]、[2]、[3]

mstrimport[1]

N

N:1リカバリ構成での仮想ホストの構成例[1]

N:1リカバリシステム[1]、[2]

N:1リカバリシステムでのファイルの設定の要否[1]

N:1リカバリシステムの起動と停止（UNIXの場合）[1]

N:1リカバリシステムの起動と停止（Windowsの場合）[1]

N:1リカバリシステムの構成例（UNIXの場合）[1]

N:1リカバリシステムのシステム構成例[1]

N:1リカバリシステムの設定（UNIXの場合）[1]

N:1リカバリシステムの設定（Windowsの場合）[1]

N秒[1]

O

ORB機能[1]、[2]

ORB機能使用時の設定[1]、[2]

OTS機能[1]、[2]

S

SNMP連携用形式[1]

Stateful Session Beanの稼働情報ファイルに出力される情報[1]

Stateless Session Beanの稼働情報ファイルに出力される情報[1]

sysdef[1]、[2]、[3]

U

URLグループ単位の実行待ちリクエスト数[1]

URLグループの稼働情報ファイルに出力される情報[1]

V

vbroker.agent.addr[1]、[2]

vbroker.agent.enableLocator[1]

vbroker.se.iiop_tp.host[1]、[2]、[3]

W

webserver.connector.nio_http.bind_host[1]、[2]

Webアプリケーション単位の実行待ちリクエスト数[1]

Webアプリケーション単位の全体実行待ちリクエスト数[1]

WebアプリケーションとEnterprise Beanの両方で使用する機能（コンテナ共通機能）[1]

Webアプリケーションの稼働情報ファイルに出力される情報[1]

Webアプリケーションのサービスの部分閉塞による入れ替え[1]

Webアプリケーションのサービスの閉塞と閉塞解除とは[1]

Webアプリケーションの閉塞処理[1]

Webアプリケーションのリクエスト処理でのタイムアウト値の設定方法[1]

Webアプリケーションを実行するための機能（Webコンテナ）[1]

Webコンテナ単位の実行待ちリクエスト数[1]

Webコンテナ単位の全体実行待ちリクエスト数[1]

Webコンテナの稼働情報ファイルに出力される情報[1]

Webフロントシステムで実行できるサービス閉塞[1]

Webフロントシステムでのサービス閉塞[1]

Windows Server Failover Cluster[1]

あ

アーカイブ形式[1]

アダプタコマンド[1]

アダプタコマンドの実行環境の設定[1]

アダプタコマンドのセットアップ[1]

アプリケーション強制停止コマンド[1]

アプリケーションサーバ[1]

アプリケーションサーバ 11-30での主な機能変更[1]

アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ[1]

アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ[1]

アプリケーションサーバのJP1イベント発行の設定[1]

アプリケーションサーバのカスタムジョブの登録（Windowsの場合）[1]

アプリケーションサーバの機能[1]

アプリケーションサーバの機能の分類と対応するマニュアル[1]

アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例[1]

アプリケーションサーバを対象にした1:1系切り替えシステム[1]

アプリケーションサーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）[1]

アプリケーションサーバを対象にした1:1系切り替えシステムの構成例（UNIXの場合）[1]

アプリケーションサーバを対象にした1:1系切り替えシステムの構成例（Windowsの場合）[1]

アプリケーションサーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）[1]

アプリケーションサーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）[1]

アプリケーション制御用カスタムジョブ[1]

アプリケーションの監査ログを出力するための実装[1]

アプリケーションのユーザログの取得[1]

アンデプロイ処理[1]

い

一覧表示コマンド[1]

イベントの発行機能[1]

イベントの発行方法[1]

う

運用管理エージェントの自動再起動[1]

運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ[1]

運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ[1]

運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例[1]

運用管理サーバを対象にした1:1系切り替えシステム[1]

運用管理サーバを対象にした1:1系切り替えシステムの起動と停止（Windowsの場合）[1]

運用管理サーバを対象にした1:1系切り替えシステムの構成例（UNIXの場合）[1]

運用管理サーバを対象にした1:1系切り替えシステムの構成例（Windowsの場合）[1]

運用管理サーバを対象にした1:1系切り替えシステムの設定（UNIXの場合）[1]

運用管理サーバを対象にした1:1系切り替えシステムの設定（Windowsの場合）[1]

運用時のトラブルについて[1]

え

エイリアスIPアドレス[1]、[2]、[3]

か

拡張MIBオブジェクト定義ファイル[1]

カスタムジョブ[1]、[2]

カスタムジョブによるジョブの定義（Windowsの場合）[1]

稼働状況のステータスの種類と意味[1]

稼働情報監視で表示できる項目（J2EEサーバの場合）[1]

稼働情報監視で表示できる項目（バッチサーバの場合）[1]

稼働情報収集機能[1]

稼働情報として監視できる項目[1]

稼働情報の種類と稼働情報を出力するJ2EEサーバの機能[1]

稼働情報ファイル[1]

稼働情報ファイルで収集できる情報[1]

稼働情報ファイルで収集できる情報の種類[1]

稼働情報ファイルの出力機能[1]

稼働情報ファイルの出力形式と出力内容[1]

稼働情報ファイルの出力先[1]

稼働情報ファイルの出力先とファイル面数[1]

稼働情報ファイルのファイル名[1]

稼働情報ファイルのファイル面数と面の切り替え間隔[1]

稼働統計出力ファイル[1]

稼働統計出力ファイルに出力される情報[1]

稼働統計出力ファイルの出力先[1]

稼働統計出力ファイル名[1]、[2]

稼働統計情報の出力情報[1]

稼働統計情報ファイル[1]

稼働統計情報ファイルの利用方法[1]

簡易構築定義ファイルでのManagementイベントの発行の定義（J2EEサーバ）[1]

簡易構築定義ファイルでのイベントの発行の定義[1]

簡易構築定義ファイルでの稼働情報ファイルの収集に必要な定義[1]

簡易構築定義ファイルでのデータベース監査証跡との連携機能の定義[1]

簡易構築定義ファイルでのリソース枯渇監視機能の定義[1]

監査事象[1]

監査事象の定義[1]

監査で使用するメッセージの出力項目[1]

監査ログ[1]

監査ログが出力される流れと主な出力情報[1]

監査ログ出力機能を使用するシステムで必要な作業と参照先[1]

監査ログ出力の設定[1]

監査ログ出力用のAPIの実装例[1]

監査ログとは[1]

監査ログの出力形式[1]

監査ログの出力項目[1]

監査ログの出力先[1]

監査ログの出力に失敗した場合にシステムを自動で停止する流れ[1]

監査ログの出力方式[1]

監査ログの保存[1]

監査ログを自動でアーカイブする流れ[1]

監査ログを出力するコマンドの一覧（EJBクライアントアプリケーションで使用するコマンド）[1]

監査ログを出力するコマンドの一覧（J2EEサーバで使用するコマンド）[1]

監査ログを出力するコマンドの一覧（Management Serverで使用するコマンド）[1]

監査ログを出力するコマンドの一覧（性能解析トレース・CTMで使用するコマンド）[1]

監査ログを出力するコマンドの一覧（バッチサーバで使用するコマンド）[1]

監査ログを出力するコマンド・操作の一覧（UNIXの場合のHTTP Serverで使用するコマンド・操作）[1]

監査ログを出力するコマンド・操作の一覧（Windowsの場合のHTTP Serverで使用するコマンド・操作）[1]

監視基盤[1]

監視ツリー自動生成の処理の流れ[1]

監視ツリーの自動生成[1]、[2]

監視ツリーの自動生成に必要な製品または構成ソフトウェア[1]

監視ツリーの自動生成の設定[1]

監視できるリソースの種類[1]

き

機能ごとに取得できる稼働情報の種類[1]

機能の分類と機能解説のマニュアルの対応[1]

旧バージョンの製品から移行するための機能（移行機能）[1]

旧バージョンの製品との互換のための機能（互換機能）[1]

強制停止[1]

強制停止処理[1]

業務指向ツリー[1]

業務指向ツリーの構成[1]

業務指向ツリーのノード[1]

く

クライアント側共通設定ファイル[1]

クライアント側定義ファイル[1]、[2]

クラスタIPアドレス[1]

クラスタソフトウェアとの連携による系切り替え機能[1]、[2]

クラスタソフトウェア連携時のTPBrokerの設定（UNIXの場合）[1]

クラスタソフトウェア連携時のTPBrokerの設定（Windowsの場合）[1]

け

系[1]

計画系切り替え[1]、[2]

計画系切り替えの処理の流れ[1]、[2]

系切り替えシステムの設定内容の確認方法[1]

系切り替え時の情報の引き継ぎ[1]、[2]

系切り替えの管理対象となるサーバ[1]

系切り替えの処理の流れ[1]

系切り替えのタイミング[1]

系切り替えの動作[1]

現用系[1]

現用系から予備系へのManagement Serverの設定情報のコピー[1]、[2]

こ

コールドスタンバイ[1]

コネクションプール監視[1]

コネクションプール枯渇監視情報[1]

コマンドによってメソッドキャンセルを実行した場合に出力されるログ情報[1]

コンソール出力情報[1]

コンソールログ[1]

コンソールログの出力対象[1]

コンソールログの出力対象となる操作[1]

コンソールログの出力対象となるプロセス[1]

コンソールログの取得の設定[1]

さ

サーバ側定義ファイル[1]

サーバ指向ツリー[1]

サーバ指向ツリーの構成[1]

サーバ対応の環境設定での設定内容（N:1リカバリシステムの場合）[1]

サーバ対応の環境設定での設定内容（アプリケーションサーバの1:1系切り替えの場合）[1]

サーバ対応の環境設定での設定内容（運用管理サーバの1:1系切り替えの場合）[1]

サーバ対応の環境設定での設定内容（相互系切り替えシステムの場合）[1]

サーバの稼働情報の出力方法[1]

サービスの部分閉塞ができるシステム構成[1]

サービスの部分閉塞による入れ替え[1]

サービスの部分閉塞の方法[1]

サービス部分閉塞[1]

サービス閉塞[1]、[2]

サービス閉塞の解除[1]

サービス閉塞の方法[1]

サービス閉塞の方法と表示されるエラーページ[1]

サービスユニット[1]

サービスユニットのステータス監視[1]

サンプリング時間[1]

し

しきい値イベント[1]

しきい値を設定できる監視対象[1]

システムの運用監視[1]

システムの運用状況の監視[1]

システムの稼働監視[1]

システムの監査を支援する機能[1]

システムの起動[1]

システムの起動と停止の設定[1]

システムの起動と停止の手順[1]

システムの起動・停止など日常的な運用をするための機能（運用機能）[1]

システムの構成例（N:1リカバリシステムの場合）[1]

システムの自動運転[1]

システムの自動運転をするために使用するJP1プログラムの機能（J2EEサーバの場合）[1]

システムの自動運転をするために使用するJP1プログラムの機能（バッチサーバの場合）[1]

システムの集中監視[1]

システムの集中監視に必要なプログラム[1]

システムの集中監視の仕組み[1]

システムの集中監視をするために使用するJP1プログラムの機能[1]

システムの停止[1]

システムの日常運用を支援する機能[1]

システムの保守を支援する機能[1]

システムの利用状況を監視するための機能（監視機能）[1]

実行系[1]、[2]、[3]

実行系の前提条件[1]

自動起動の設定[1]

自動系切り替え[1]、[2]

自動系切り替えの処理の流れ[1]、[2]

自動再起動の設定[1]

自動停止の設定[1]

出力される稼働情報[1]

障害監視に必要な製品または構成ソフトウェア[1]

障害監視の設定[1]

障害の監視の仕組み[1]

障害発生時の自動再起[1]

ジョブ[1]

ジョブによるシステムの自動運転に必要な製品または構成ソフトウェア[1]

ジョブによるシステムの自動運転に必要なプログラム[1]

ジョブによるシステムの自動運転の仕組み[1]

ジョブによるシステムの自動運転の設定[1]

ジョブネット[1]

ジョブの定義[1]

す

スケジュールの定義[1]

ステーショナリIPアドレス[1]、[2]

ステータス監視で確認できる項目[1]

ステータスの監視方法[1]

ステートメントキャンセル[1]

スマートエージェントのlocaladdrファイルの設定内容[1]、[2]

スマートエージェントを系切り替えの対象にしない場合のIPアドレスの設定例[1]

スマートエージェントを系切り替えの対象にする場合のIPアドレスの設定例[1]

スマートエージェントをフェイルオーバの対象にしない場合のIPアドレスの設定例[1]

スマートエージェントをフェイルオーバの対象にする場合のIPアドレスの設定例[1]

スレッド監視[1]

スレッド枯渇監視情報[1]

スレッドダンプ監視[1]

スレッドダンプ枯渇監視情報[1]

スレッドの状態とメソッドキャンセルの実行可否[1]

せ

性能解析トレースの取得[1]

性能解析トレース・CTMで使用するコマンドの監査ログの出力ポイント[1]

セッション数監視[1]

セッション数枯渇監視情報[1]

そ

相互系切り替えシステム[1]

相互系切り替えシステムでの計画系切り替えの処理の流れ[1]

相互系切り替えシステムでの系切り替え処理の流れ[1]

相互系切り替えシステムでの系切り替えの動作[1]

相互系切り替えシステムでの自動系切り替えの処理の流れ[1]

相互系切り替えシステムの起動と停止（UNIXの場合）[1]

相互系切り替えシステムの起動と停止（Windowsの場合）[1]

相互系切り替えシステムの起動の流れ[1]

相互系切り替えシステムの構成例[1]

相互系切り替えシステムの構成例（UNIXの場合）[1]

相互系切り替えシステムの構成例（Windowsの場合）[1]

相互系切り替えシステムのシステム構成例[1]、[2]

相互系切り替えシステムの設定（UNIXの場合）[1]

相互系切り替えシステムの設定（Windowsの場合）[1]

相互系切り替えシステムの停止の流れ[1]

相互系切り替えシステムをメンテナンスする場合の起動と停止[1]

相互スタンバイ構成[1]、[2]

相互スタンバイシステムの構成例[1]

た

待機系[1]、[2]、[3]

待機系の前提条件[1]

タイムアウトが発生したリクエストのキャンセル[1]

タイムアウト検知間隔とメソッドタイムアウト時間[1]

タイムアウトしたリクエストをキャンセルする[1]

タイムアウト値の設定例と設定値の有効範囲[1]

タイムアウトの延長でメソッドキャンセルを実行した場合に出力されるログ情報[1]

タイムアウトの判定とタイムアウト後の動作[1]

タイムアウトを検知する時間の間隔[1]

つ

通常停止[1]

通常のJ2EEアプリケーションの入れ替えの手順[1]

通常のサービス閉塞[1]

て

停止処理[1]

データベース監査証跡[1]

データベース監査証跡と連携した運用例[1]

データベース監査証跡に出力する情報[1]

データベース監査証跡の出力個所[1]

データベース監査証跡への出力の流れ[1]

データベース監査証跡への情報の出力[1]

データベース監査証跡連携機能[1]

データベース監査証跡連携機能を使用できるデータベースとDBConnector[1]

データベースの監査証跡情報の取得[1]

デフォルトのタイムアウト時間で通常停止を実行して，停止しなかった場合に強制停止を実行する[1]

デフォルトのタイムアウト時間で通常停止を実行する[1]

展開ディレクトリ形式[1]

と

統合機能メニュー[1]

統合コンソール[1]

統合スコープ[1]

トラブル発生時などに対処するための機能（保守機能）[1]

トランザクションサービスの稼働情報ファイルに出力される情報[1]

に

日常運用での起動と停止[1]

任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に強制停止を実行する[1]

任意のタイムアウト時間を設定して通常停止を実行して，停止しなかった場合に自動的に強制停止を実行する[1]

任意のタイムアウト時間を設定して通常停止を実行する[1]

ね

ネットワークリソースにアクセスするための設定[1]

ネットワークリソースへのアクセスの概要[1]

は

バックシステム（CTMを使用していない場合）で実行できるサービス閉塞[1]

バックシステム（CTMを使用している場合）で実行できるサービス閉塞[1]

バックシステムでのサービス閉塞（CTMを使用しているシステムの場合）[1]

バッチサーバで使用するコマンドの監査ログの出力ポイント[1]

ひ

非保護区[1]

ビューアー[1]、[2]

ふ

ファイルディスクリプタ監視[1]

ファイルディスクリプタ枯渇監視情報[1]

負荷分散機を使用したシステム構成でのサービス閉塞[1]

負荷分散機を利用したサービス部分閉塞[1]

負荷分散機を利用したサービス閉塞[1]

プライベートプロパティの設定[1]

プロセスリソースの稼働情報ファイルに出力される情報[1]

フロント[1]

フロントEJB[1]、[2]

フロントEJBの閉塞処理[1]

へ

閉塞処理[1]

ヘッダファイル[1]

ヘッダファイルと稼働情報ファイルの対応[1]

ほ

ほかの製品と連携して運用するための機能（連携機能）[1]

保護区[1]、[2]、[3]

保護区リストファイル[1]

め

メソッドキャンセル機能[1]

メソッドキャンセルコマンド[1]

メソッドキャンセル実行のタイミング[1]

メソッドキャンセル時の動作[1]

メソッドキャンセルとは[1]

メソッドキャンセルの処理[1]

メソッドキャンセルを利用するアプリケーション開発時の注意事項[1]

メソッドタイムアウト機能[1]

メソッドタイムアウト機能の対象となる処理[1]

メソッドタイムアウトとは[1]

メソッドタイムアウトの適用対象（Enterprise Bean呼び出し側）[1]

メソッドタイムアウトの適用対象（Webアプリケーションのリクエスト処理）[1]

メソッドタイムアウトの適用対象（コールバックメソッド側）[1]

メソッドタイムアウト発生時のオプションメッセージの設定[1]

メモリ監視[1]

メモリ枯渇監視情報[1]

も

モニタ起動コマンド[1]

ゆ

ユーザJP1イベントの推奨設定[1]

ユーザログ出力機能[1]

よ

予備系[1]

ら

ライトトランザクション機能の利用[1]

ランタイム属性[1]

り

リカバリ処理の流れ[1]

リカバリ専用サーバ[1]、[2]

リソース枯渇監視機能とリソース枯渇監視情報の出力[1]

リソース枯渇監視機能の有効化[1]

リソース枯渇監視情報[1]

リソース枯渇監視情報に出力される情報[1]

リソース枯渇監視情報の出力形式[1]

リソース枯渇監視の設定[1]

リソース枯渇監視ログファイル[1]

リソース種別ごとの監視の設定[1]

リデプロイ[1]、[2]

リデプロイ機能による入れ替え[1]

リデプロイ機能による入れ替え手順[1]

リデプロイによってJ2EEアプリケーションを入れ替えるときのJSPの事前コンパイル[1]

リデプロイによるJ2EEアプリケーションの入れ替え[1]

リロード[1]、[2]

リロード機能による入れ替え[1]

リロードによってJ2EEアプリケーションを入れ替えるときのJSPの事前コンパイル[1]

リロードによるJ2EEアプリケーションの入れ替え[1]

る

ルートアプリケーション情報[1]、[2]

ろ

ログイン方法の設定 〔JP1/IM連携〕[1]

論理サーバおよびJ2EEアプリケーションの起動と停止の自動化の仕組み[1]

論理サーバ起動／停止ジョブ定義用の定義プログラム[1]

論理サーバ制御用カスタムジョブ[1]

論理サーバの稼働確認方法[1]

論理サーバの起動と稼働確認[1]

論理サーバの起動・停止の仕組み[1]

論理サーバの自動再起動[1]

論理サーバのステータス監視[1]

論理サーバの停止[1]