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

システム構築・運用ガイド

手引・文法・操作書

3020-3-U04-40

目　　次

前書き

変更内容

はじめに

第1編　システム構築の概要

1.　アプリケーションサーバでのシステム構築の概要

1.1　構築するシステムの概要

1.2　J2EEアプリケーションを実行するシステムの構築

1.2.1　システムの構築方法の種類（J2EEアプリケーションを実行するシステム）

1.2.2　リソースおよびJ2EEアプリケーションの設定で使用できる機能（J2EEアプリケーションを実行するシステム）

1.3　バッチアプリケーションを実行するシステムの構築

1.3.1　システムの構築方法の種類（バッチアプリケーションを実行するシステム）

1.3.2　リソースの設定で使用できる機能（バッチアプリケーションを実行するシステム）

1.4　セットアップウィザードの概要

1.4.1　セットアップウィザードの目的

1.4.2　セットアップウィザードの利点

1.5　Smart Composer機能の概要

1.5.1　Smart Composer機能の目的

1.5.2　Smart Composer機能の利点

1.6　運用管理ポータルの概要

1.6.1　運用管理ポータルの目的

1.6.2　運用管理ポータルの利点

1.7　ほかのプログラムとの連携

1.8　アプリケーションサーバで構築するシステムで使用できるオプション製品

1.9　Windows Server 2008，Windows 7，またはWindows Vista使用時の注意事項

1.9.1　管理者特権で実行する必要がある操作

1.9.2　JIS X0213:2004に含まれるUnicodeの補助文字を使用する場合の注意事項

第2編　セットアップウィザードを使用したシステムのセットアップと運用

2.　セットアップウィザードを使用したシステムのセットアップ

2.1　システムをセットアップする前に

2.1.1　セットアップウィザードを使用したシステムのセットアップの流れ

2.1.2　システム構成とセットアップ方法の決定

2.1.3　インストール

2.1.4　セットアップウィザードを使用する前に

2.2　システムのセットアップ

2.2.1　システムのセットアップの流れ

2.2.2　セットアップウィザードの起動

2.2.3　セットアップの開始

2.2.4　セットアップ方法の選択

2.2.5　運用管理ユーザの設定

2.2.6　運用管理機能の設定

2.2.7　J2EEサーバの起動ユーザの設定

2.2.8　システム構成の選択

2.2.9　システム環境の設定

2.2.10　データベース接続環境の設定

2.2.11　セットアップ情報の確認

2.2.12　セットアップの実行

2.2.13　セットアップウィザードの終了

2.2.14　J2EEアプリケーションのインポートと開始

2.2.15　セットアップ情報ファイルを使用した一括セットアップ

2.2.16　アンセットアップ要求

2.2.17　セットアップウィザードで設定できる項目

2.3　システムの運用

2.3.1　セットアップウィザードでセットアップしたシステムの起動と停止

2.3.2　チューニング

2.3.3　パラメタチューニングしたシステムの複製

2.3.4　システムのアンセットアップ

2.4　セットアップまたはアンセットアップ失敗時の対処

3.　セットアップウィザードで使用するコマンドとファイル

3.1　セットアップウィザードで使用するコマンド

3.2　setupwizardコマンドの詳細

setupwizardコマンド（システムのセットアップ，アンセットアップと複製）

3.3　セットアップウィザードで使用するファイル

3.4　setup.cfg（セットアップウィザード用設定ファイル）

第3編　Smart Composer機能を使用したシステムを構築・運用するための準備

4.　システムを構築・運用する前に

4.1　J2EEアプリケーションを実行するシステムの構築に必要な作業の流れ

4.2　J2EEアプリケーションを実行するシステムを構成する要素

4.2.1　物理ティアとは

4.2.2　サービスユニットとは

4.2.3　プロセスの種類と論理サーバとの対応

4.3　J2EEアプリケーションを実行するシステムで使用するマシンの種類

4.3.1　負荷分散機

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

4.3.3　データベースサーバマシン

4.3.4　運用管理サーバマシン

4.3.5　セッションフェイルオーバサーバマシン

4.3.6　統合ネーミングスケジューラサーバマシン

4.4　バッチアプリケーションを実行するシステムの構築に必要な作業の流れ

4.5　バッチアプリケーションを実行するシステムを構成する要素

4.5.1　物理ティアとは

4.5.2　サービスユニットとは

4.5.3　プロセスの種類と論理サーバとの対応

4.6　バッチアプリケーションを実行するシステムで使用するマシンの種類

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

4.6.2　データベースサーバマシン

4.7　JP1/SC/DPMの利用

4.8　Management Serverが自動で設定する内容

4.8.1　Management Serverが自動で生成するユーザ定義ファイル

4.8.2　Management ServerがCTMドメインマネジャに自動で設定する内容

4.8.3　Management ServerがCTMに自動で設定する内容

4.8.4　Management ServerがSFOサーバに自動で設定する内容

4.8.5　Management ServerがJ2EEサーバに自動で設定する内容

4.8.6　Management Serverがバッチサーバに自動で設定する内容

4.8.7　Management ServerがWebサーバに自動で設定する内容

4.8.8　Management Serverが自動で設定する論理サーバの環境変数

5.　システム構成に合わせた構成定義パターンの選定

5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定

5.1.1　構成定義パターン選定の考え方

5.1.2　システム構成ごとに選択できる構成定義パターン

5.2　バッチアプリケーションを実行するシステムでの構成定義パターンの選定

5.2.1　構成定義パターン選定の考え方

5.2.2　システム構成ごとに選択できる構成定義パターン

6.　運用・障害設計

6.1　J2EEアプリケーションを実行するシステムの運用・障害設計

6.1.1　運用設計

6.1.2　障害設計

6.2　バッチアプリケーションを実行するシステムの運用・障害設計

6.2.1　運用設計

6.2.2　障害設計

7.　インストールと初期設定

7.1　インストールと初期設定の概要

7.2　インストールとアンインストール

7.2.1　インストール方法

7.2.2　アンインストール方法

7.2.3　Component Container管理者の設定（UNIXの場合）

7.2.4　C++ライブラリのバージョン指定（Linuxの場合）

7.2.5　アプリケーションサーバでサポートしているシンボリックリンク（UNIXの場合）

7.3　環境変数の設定

7.3.1　環境変数の設定の要否

7.3.2　環境変数の詳細

7.3.3　論理サーバの環境変数

7.4　使用リソースの設定

7.5　データベースを使用するための設定

7.5.1　HiRDBの設定（HiRDB Type4 JDBC Driverの場合）

7.5.2　Oracleの設定（Oracle JDBC Thin Driverの場合）

7.6　Management Serverのセットアップと環境設定

7.6.1　Management Serverのセットアップ

7.6.2　Management Serverの環境設定

7.6.3　Management Serverの動作環境の設定

7.6.4　運用管理エージェントによる論理サーバの監視に関する設定

7.6.5　管理ユーザアカウントを設定しない場合の設定

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

7.7.1　運用管理エージェントの起動／停止と設定

7.7.2　Management Serverの起動／停止と設定

7.8　Server Plug-inの設定

7.8.1　Java実行環境の指定

7.8.2　Server Plug-inの組み込み手順

7.8.3　Server Plug-inを使用するためのManagement Serverの設定

7.9　インストール後のディレクトリ構成

7.10　J2EEサーバの作業ディレクトリ

7.10.1　J2EEサーバの作業ディレクトリの構成

7.10.2　作業ディレクトリのパス長の見積もり式

7.11　バッチサーバの作業ディレクトリ

7.11.1　バッチサーバの作業ディレクトリの構成

7.11.2　作業ディレクトリのパス長の見積もり式

第4編　Smart Composer機能を使用したシステムの構築と運用

8.　J2EEアプリケーションを実行するシステムの構築

8.1　システム構築の概要

8.1.1　コマンドとシステム構築の関係

8.1.2　システム構築で使用するファイル

8.1.3　システム構築の流れ

8.2　負荷分散機の設定

8.2.1　BIG-IPでの負荷分散機の設定

8.2.2　ACOS（AX2500）での負荷分散機の設定

8.3　アプリケーションサーバから負荷分散機を制御するための設定

8.4　システムの構成定義

8.4.1　簡易構築定義ファイルの作成手順

8.4.2　テンプレートファイル

8.4.3　簡易構築定義ファイルの設定内容

8.4.4　簡易構築定義ファイルの作成

8.5　DB ConnectorのConnector属性ファイルの編集

8.6　システムの一括構築

8.7　システムの一括起動（READY）

8.8　リソースとJ2EEアプリケーションの設定

8.8.1　リソースとJ2EEアプリケーションの設定の前に

8.8.2　リソースとJ2EEアプリケーションのプロパティ定義を設定するための前提

8.8.3　リソースアダプタのインポートと開始

8.8.4　J2EEアプリケーションのインポートと開始

8.9　システムの一括起動（サービスユニットの開始）

8.10　チューニング

8.10.1　簡易構築定義ファイルのパラメタだけを編集する場合のチューニング

8.10.2　リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニング

8.11　構成定義パターンごとの簡易構築定義ファイルの作成

8.11.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルの作成

8.11.2　WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の簡易構築定義ファイルの作成

8.11.3　インプロセスHTTPサーバを使用するパターン（j2ee-tier）の簡易構築定義ファイルの作成

8.11.4　SFOサーバを使用するパターン（sfo-tier）の簡易構築定義ファイルの作成

8.11.5　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

8.12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

8.13　障害に対応したシステムの構築

8.13.1　障害発生時にサービスユニットを自動閉塞するための設定

8.13.2　サービスユニットを自動再起動するための設定

9.　J2EEアプリケーションを実行するシステムの運用

9.1　システムの運用の概要

9.1.1　システムの運用で使用する機能

9.1.2　アプリケーションサーバで実行できる運用作業

9.1.3　Smart Composer機能を使用した運用作業

9.2　システムの運用を始める前に

9.2.1　Component Container管理者による運用に関する留意事項

9.2.2　運用管理コマンド（mngsvrutil）を利用する場合の留意事項

9.2.3　サーバ管理コマンドを利用する場合の留意事項

9.2.4　作業ディレクトリに関する注意事項

9.2.5　RMIレジストリに関する注意事項

9.2.6　コマンド実行時に指定するWebシステム名，サービスユニット名，およびサーバ名に関する注意事項

9.3　日常運用の操作

9.3.1　すべてのサービスユニットの一括起動と一括停止

9.3.2　サービスユニット単位の一括起動と一括停止

9.4　システムのメンテナンス

9.4.1　サービスユニットの閉塞によるシステムの部分メンテナンス

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

9.5　システムの設定変更

9.5.1　システムの設定の一括変更

9.5.2　システムの設定変更時の注意事項

9.6　システムのスケールアウト

9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト

9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト

9.6.3　CTMを使用するパターン（ctm-tier）のシステムのスケールアウト

9.7　システムのスケールイン

9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン

9.7.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールイン

9.8　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

9.8.1　運用管理サーバモデルでのシステムのスケールアウト

9.8.2　ホスト単位管理モデルでのシステムのスケールアウト

9.8.3　JP1/SC/DPMを利用して構築したシステムのスケールイン

9.9　構築済みのシステムの移行

9.9.1　構築済みのシステムの移行手順

9.9.2　構築済みのシステムの移行時に出力する簡易構築定義ファイルの内容

9.9.3　構築済みのシステムを移行するときの注意事項

9.10　トラブルへの対処

9.10.1　トラブルの種別と対処

9.10.2　負荷分散機の冗長化構成でトラブルが発生した場合の対処

9.11　システムの削除

10.　バッチアプリケーションを実行するシステムの構築

10.1　システム構築の概要

10.1.1　コマンドとシステム構築の関係

10.1.2　システム構築で使用するファイル

10.1.3　システム構築の流れ

10.2　システムの構成定義

10.2.1　簡易構築定義ファイルの作成手順

10.2.2　テンプレートファイル

10.2.3　簡易構築定義ファイルの設定内容

10.2.4　簡易構築定義ファイルの作成

10.3　DB ConnectorのConnector属性ファイルの編集

10.4　システムの一括構築

10.5　システムの一括起動

10.6　リソースの設定

10.6.1　リソースの設定の前に

10.6.2　リソースアダプタのインポートと開始

10.7　チューニング

10.8　構成定義パターンごとの簡易構築定義ファイルの作成

10.8.1　バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルの作成

10.8.2　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

10.9　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

10.10　障害に対応したシステムの構築

10.10.1　サービスユニットを自動再起動するための設定

11.　バッチアプリケーションを実行するシステムの運用

11.1　システムの運用の概要

11.1.1　システムの運用で使用する機能

11.1.2　アプリケーションサーバで実行できる運用作業

11.1.3　Smart Composer機能を使用した運用作業

11.1.4　システムの運用を始める前に

11.2　日常運用の操作

11.2.1　すべてのサービスユニットの一括起動と一括停止

11.2.2　サービスユニット単位の一括起動と一括停止

11.3　システムの設定変更

11.3.1　システムの設定の一括変更

11.4　システムのスケールアウトとスケールイン

11.4.1　システムのスケールアウト

11.4.2　システムのスケールイン

11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

11.6　構築済みのシステムの移行

11.7　トラブルへの対処

11.8　システムの削除

付録

付録A　Smart Composer機能が実行する負荷分散機のCLIコマンドまたはAPI

付録A.1　Smart Composer機能が実行するBIG-IPのCLIコマンド

付録A.2　Smart Composer機能が実行するACOSのCLIコマンド

付録A.3　Smart Composer機能が実行する負荷分散機のAPI

付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル

付録C　データベース（XDM/RD E2・SQL Server）の設定

付録C.1　XDM/RD E2の設定

付録C.2　SQL Serverの設定

付録D　セットアップウィザードで設定されるパラメタ

付録D.1　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理Webサーバ）

付録D.2　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理J2EEサーバ）

付録D.3　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理パフォーマンストレーサ）

付録E　代替手段で実行できる運用作業

付録E.1　システムの起動と停止

付録E.2　システムの運用監視

付録E.3　システムの処理性能解析

付録E.4　統合ユーザ管理のリソースの監視

付録E.5　J2EEアプリケーションとリソースの管理

付録E.6　システムの監査

付録E.7　トラブルシューティング

付録F　アプリケーションサーバが提供するサンプルプログラム

付録F.1　サーバ管理コマンドによるサンプル実行環境の構築，運用手順

付録F.2　Enterprise Bean（EJB2.0）のサンプルプログラム

付録F.3　Enterprise Bean（アノテーション）のサンプルプログラム

付録F.4　Enterprise Bean（Timer Service）のサンプルプログラム

付録F.5　JPAのサンプルプログラム

付録F.6　JavaBeansリソースのサンプルプログラム

付録F.7　ユーザログ機能のサンプルプログラム

付録F.8　Webアプリケーションのサンプルプログラム

付録F.9　TP1インバウンド連携機能のサンプルプログラム

付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）

付録G.1　インストール手順（uCosminexus Operator）

付録G.2　環境変数の設定（uCosminexus Operator）

付録G.3　uCosminexus Operatorのディレクトリ構成

付録H　このマニュアルの参考情報

付録H.1　関連マニュアル

付録H.2　マニュアル体系の変更について

付録H.3　このマニュアルでの表記

付録H.4　英略語

付録H.5　KB（キロバイト）などの単位表記について

付録I　用語解説

索引

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

前書き

■ 対象製品

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹

P-2443-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2443-7D84　 uCosminexus Application Server Standard　 08-70
P-2443-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2443-7M84　 uCosminexus Web Redirector　 08-70
P-2443-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7E84　 uCosminexus Developer Standard　 08-70
P-2443-7F84　 uCosminexus Developer Professional　 08-70
P-2443-7T84　 uCosminexus Service Architect　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7H84　 uCosminexus Client　 08-70

●適用OS：Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Server 2008 x64，Windows Server 2008 R2

P-2943-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2943-7D84　 uCosminexus Application Server Standard　 08-70
P-2943-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2943-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：AIX 5L V5.3，AIX V6.1，AIX V7.1

P-1M43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-1M43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-1M43-7S81　 uCosminexus Service Platform　 08-70※2

●適用OS：HP-UX 11i V2（IPF），HP-UX 11i V3（IPF）

P-1J43-7D81　 uCosminexus Application Server Standard　 08-70
P-1J43-7K81　 uCosminexus Application Server Enterprise　 08-70
P-1J43-7S81　 uCosminexus Service Platform　 08-70※2

●適用OS：Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），Red Hat Enterprise Linux 5（AMD/Intel 64），Red Hat Enterprise Linux Server 6（32-bit x86），Red Hat Enterprise Linux Server 6（64-bit x86_64）

P-9S43-7B81　 uCosminexus Application Server Standard-R　 08-70※2
P-9S43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-9S43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-9S43-7M81　 uCosminexus Web Redirector　 08-70※2
P-9S43-7S81　 uCosminexus Service Platform　 08-70※2

注※1　WOW64（Windows On Windows 64）環境だけで使用できます。
注※2　この製品については，サポート時期をご確認ください。
これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
本製品では日立トレース共通ライブラリをインストールします。

■ 輸出時の注意

本製品を輸出される場合には，外国為替および外国貿易法ならびに米国の輸出管理関連法規などの規制をご確認の上，必要な手続きをお取りください。
なお，ご不明な場合は，弊社担当営業にお問い合わせください。

■ 商標類

AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
BIG-IP，3-DNS，iControl Services Manager，FirePass　および F5 は F5 Networks Inc の商標，または登録商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Internet Explorerは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSTLは，The Jakarta Projectのタグライブラリ名称です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle9iは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
SQL Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
PuTTYは，Simon Tatham氏が提供するオープンソースソフトウェア(フリーソフトウェア)です。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

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

Microsoft Corporationのガイドラインに従って画面写真を使用しています。

■ マイクロソフト製品の表記について

このマニュアルでは，マイクロソフト製品の名称を次のように表記しています。

製品名 | 表記
Microsoft(R) Cluster Service | Microsoft Cluster Service
Microsoft(R) Internet Information Services 6.0 | Microsoft IIS 6.0 | Microsoft IIS
Microsoft(R) Internet Information Services 7.0 | Microsoft IIS 7.0
Microsoft(R) Internet Information Services 7.5 | Microsoft IIS 7.5
Microsoft(R) SQL Server 2000 | SQL Server 2000 | SQL Server
Microsoft(R) SQL Server 2005 | SQL Server 2005
Microsoft(R) SQL Server 2008 | SQL Server 2008
Microsoft(R) SQL Server 2000 Driver for JDBC | SQL Server 2000 Driver for JDBC | SQL ServerのJDBCドライバ
Microsoft(R) SQL Server 2005 JDBC Driver | SQL Server 2005 JDBC Driver
Microsoft(R) SQL Server JDBC Driver 2.0 | SQL Server JDBC Driver
Microsoft(R) SQL Server JDBC Driver 3.0
Microsoft(R) Windows(R) 7 Enterprise（32bit） | Windows 7（32bit） | Windows 7 | Windows
Microsoft(R) Windows(R) 7 Professional（32bit）
Microsoft(R) Windows(R) 7 Ultimate（32bit）
Microsoft(R) Windows(R) 7 Enterprise（x64） | Windows 7（x64）
Microsoft(R) Windows(R) 7 Professional（x64）
Microsoft(R) Windows(R) 7 Ultimate（x64）
Microsoft(R) Windows Server(R) 2003，Enterprise Edition 日本語版 | Windows Server 2003 Enterprise Edition | Windows Server 2003
Microsoft(R) Windows Server(R) 2003，Standard Edition 日本語版 | Windows Server 2003 Standard Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise Edition 日本語版 | Windows Server 2003 R2 Enterprise Edition | Windows Server 2003 R2
Microsoft(R) Windows Server(R) 2003 R2，Standard Edition 日本語版 | Windows Server 2003 R2 Standard Edition
Microsoft(R) Windows Server(R) 2003，Enterprise x64 Edition 日本語版 | Windows Server 2003 Enterprise x64 Edition | Windows Server 2003（x64）
Microsoft(R) Windows Server(R) 2003，Standard x64 Edition 日本語版 | Windows Server 2003 Standard x64 Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise x64 Edition 日本語版 | Windows Server 2003 R2 Enterprise x64 Edition | Windows Server 2003 R2（x64）
Microsoft(R) Windows Server(R) 2003 R2，Standard x64 Edition 日本語版 | Windows Server 2003 R2 Standard x64 Edition
Microsoft(R) Windows Server(R) 2008 Enterprise 32-bit 日本語版 | Windows Server 2008 x86 | Windows Server 2008
Microsoft(R) Windows Server(R) 2008 Standard 32-bit 日本語版
Microsoft(R) Windows Server(R) 2008 Enterprise 日本語版 | Windows Server 2008 x64
Microsoft(R) Windows Server(R) 2008 Standard 日本語版
Microsoft(R) Windows Server(R) 2008 R2 Enterprise 日本語版 | Windows Server 2008 R2
Microsoft(R) Windows Server(R) 2008 R2 Standard 日本語版
Microsoft(R) Windows Vista(R) Business | Windows Vista Business | Windows Vista
Microsoft(R) Windows Vista(R) Enterprise | Windows Vista Enterprise
Microsoft(R) Windows Vista(R) Ultimate | Windows Vista Ultimate
Microsoft(R) Windows(R) XP Professional Operating System | Windows XP
Windows(R) Internet Explorer(R) | Internet Explorer
Windows Server(R) Failover Cluster | Windows Server Failover Cluster

■ 発行

2011年 7月 3020-3-U04-40

■ 著作権

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

変更内容

変更内容（3020-3-U04-40）uCosminexus Application Server Enterprise 08-70，uCosminexus Application Server Standard 08-70，uCosminexus Application Server Standard-R 08-70，uCosminexus Client 08-70，uCosminexus Developer Professional 08-70，uCosminexus Developer Standard 08-70，uCosminexus Service Architect 08-70，uCosminexus Service Platform 08-70，uCosminexus Web Redirector 08-70

追加・変更内容
変更個所

セットアップウィザードを使用したシステムのセットアップで，Webサーバのサーバ名を設定できるように変更した。これに伴い，次の画面を変更した。

［システム環境の設定］画面

［セットアップ情報］画面

［セットアップ完了］画面

［一括セットアップ］画面

［セットアップ情報ファイルの内容表示］画面

2.2.9，2.2.11，2.2.12，2.2.15，3.1

［データベース接続環境の設定］画面で，セットアップウィザードで設定できるデータベースのバージョンに関する記述を削除した。
2.2.10

Oracle11gの場合に使用するJDBCドライバを，JDKのバージョンごとの説明に変更した。
2.2.10，7.5.2

セットアップウィザードでのセットアップの完了または失敗時に表示される内容について説明を追加した。
2.2.12

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応した。負荷分散機としてAX2500を追加した。
4.3.1，8.2，8.2.2，8.3，付録A，付録A.3

Hitachi Web Serverの動作環境を定義するディレクティブ（httpsd.conf（Hitachi Web Server定義ファイル）の設定内容）を，項目またはファイル単位で，簡易構築定義ファイルおよび運用管理ポータルに設定できる機能を追加した。
4.8.7，7.2.1，7.6.4，8.1.2，8.4.3

次の製品の適用OSにRed Hat Enterprise Linux Server 6（32-bit x86），Red Hat Enterprise Linux Server 6（64-bit x86_64）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Service Platform

uCosminexus Web Redirector

7.2.4

論理サーバの環境変数に関する説明を追加した。
7.3，7.3.3

セットアップウィザードで省略値と異なる値が設定されるパラメタに，cpp.library.versionパラメタを追加した。
付録D.2

運用管理ポータルでのリソースアダプタの接続テストの追加に伴い，説明を追加した。
付録E.5

次の製品の適用OSにAIX，HP-UX（IPF）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

－

負荷分散機として，BIG-IP 1000，Loadflowbalをサポート外とした。
－

uCosminexus Application Server Enterprise 08-53，uCosminexus Application Server Standard 08-53，uCosminexus Application Server Standard-R 08-53，uCosminexus Client 08-53，uCosminexus Developer Professional 08-53，uCosminexus Developer Standard 08-53，uCosminexus Service Architect 08-53，uCosminexus Service Platform 08-53，uCosminexus Web Redirector 08-53

追加・変更内容
変更個所

Smart Composer機能で対応しているスイッチングモードをインサートモードに変更した。負荷分散機としてBIG-IP v10.1，BIG-IP v10.2を追加した。
4.3.1，8.2，8.2.1，8.3，8.4.4，8.11.6，9.8.2，付録A，付録A.1，付録A.2

HiRDB Version 9に対応した。
7.5.1

SQL Server 2008に対応した。これに伴い，使用できるJDBCドライバにSQL Server JDBC Driver 2.0，およびSQL Server JDBC Driver 3.0を追加した。
付録C.2

TP1インバウンド連携機能のサンプルプログラムの実行手順から，コネクションの設定およびトランザクションの設定を削除した。
付録F.9

Microsoft IIS 7.0およびMicrosoft IIS 7.5に対応した。
－

対象製品としてuCosminexus Application Server Standard-Rを追加した。
－

次の製品の適用OSからAIX，HP-UX，Linux（IPF）を削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Service Platform

－

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

変更内容（3020-3-U04-20）uCosminexus Application Server Enterprise 08-50，uCosminexus Application Server Standard 08-50，uCosminexus Client 08-50，uCosminexus Developer Professional 08-50，uCosminexus Developer Standard 08-50，uCosminexus Service Architect 08-50，uCosminexus Service Platform 08-50，uCosminexus Web Redirector 08-50

追加・変更内容

ホスト単位管理モデルの系切り替えシステムを追加した。

JP1 Version 9製品に対応した。また，JP1 Version 7製品をサポート外とした。

Windows Server Failover Clusterに対応した。

次の製品の適用OSにWindows Server 2008 R2を追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

uCosminexus Service Platform

uCosminexus Client

次の製品の適用OSにWindows 7を追加した。

uCosminexus Developer Standard

uCosminexus Developer Professional

uCosminexus Service Architect

uCosminexus Client

セットアップウィザードでのシステムセットアップ完了時に，セットアップで使用した簡易構築定義ファイルおよびDB ConnectorのConnector属性ファイルが出力されるよう変更した。

使用できる負荷分散機としてACOSを追加した。

管理ユーザアカウントの設定を省略する機能を追加した。

Server Plug-inの組み込み手順を変更した。

Cosminexus JMSプロバイダの機能を追加した。

仮想サーバマネージャの機能を追加した。

OpenTP1からアプリケーションサーバを呼び出す機能（TP1インバウンド連携機能）を追加した。

スレッドの非同期並行処理を追加した。

Server Plug-inの記述を削除し，代わりに運用管理ポータルを使用する方法に変更した。

jsptagサンプルをコンパイルおよびアーカイブしたファイルであるconverter.earを追加した。

次の製品の適用OSからSolarisを削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

はじめに

このマニュアルは，セットアップウィザードおよびSmart Composer機能を使用して，システムを構築・運用する手順について説明したものです。Cosminexus（コズミネクサス）のアプリケーションサーバが提供する構築・運用手段についても説明しています。

アプリケーションサーバでは，次に示すプログラムプロダクトを使用してシステムを構築，運用します。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

このマニュアルでは，これらのプログラムプロダクトの構成ソフトウェアのうち，次に示す構成ソフトウェアについて説明しています。

Cosminexus Component Container

Cosminexus Component Container - Client

Cosminexus Component Container - Redirector

Cosminexus Component Transaction Monitor

Cosminexus Developer's Kit for Java

Cosminexus Performance Tracer

Cosminexus Server Plug-in

Cosminexus TPBroker

なお，オペレーティングシステム（OS）の種類によって，機能が異なる場合があります。

対象読者

このマニュアルは，セットアップウィザードおよびSmart Composer機能を使用して，Java EEに準拠したアプリケーションを実行するためのシステムを構築または運用する方を対象としています。

次の内容を理解されていることを前提としています。

Windowsまたはご使用のUNIXのシステム構築および運用に関する知識

Java EEに関する知識

SQLおよびリレーショナルデータベースに関する基本的な知識

CORBAに関する基本的な知識

ご利用製品ごとの用語の読み替えについて

ご利用の製品によっては，マニュアルで使用している用語を，ご利用の製品名に読み替える必要があります。

次の表に従って，マニュアルで使用している用語をご利用の製品名に読み替えてください。

ご利用の製品名 | マニュアルで使用している用語
uCosminexus Application Server Standard-R | Application Server
uCosminexus Developer Professional※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Developer Standard※1，※2 | Application Server
uCosminexus Service Architect※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Service Platform

注※1　テスト環境で使用している場合にだけ読み替えが必要です。

注※2　uCosminexus Developer StandardとApplication Serverには一部機能差があります。機能差については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「付録D　Developer Standard使用時の注意事項」を参照してください。

図中で使用している記号

このマニュアルの図中で使用している記号について次に示します。

文法で使用している記号

このマニュアルの文法で使用している記号について次に示します。

記号
意　味

　｜
横に並べられた複数の項目に対する項目間の区切りを示し，「または」を意味します。
（例）　A｜B
　AまたはBを指定することを示します。

［　］
この記号で囲まれている項目は省略してもよいことを示します。複数の項目が横に並べて記述されている場合には，すべてを省略するか，記号｛ ｝と同じくどれか一つを選択します。
（例１）　［A］
　「何も指定しない」か「Aを指定する」ことを示します。
（例２）　［B｜C］
　「何も指定しない」か「BまたはCを指定する」ことを示します。

<　>
この記号で囲まれている項目は，該当する要素やファイルなどを指定したり，該当する要素が表示されたりすることを示します。
（例1）　<プロパティ>
　プロパティを記述します。またはプロパティが表示されます。
（例2）　<ファイル名>
　ファイル名を指定します。

CUIおよびGUIの説明で使用している記号

このマニュアルのCUIおよびGUIの説明で使用している記号について次に示します。

記号
意味

　｜
横に並べられた複数の項目に対する項目間の区切りを示し，「または」を意味します。
（例）　A｜B
　AまたはBを指定することを示します。

{ 　 }
この記号で囲まれている複数の項目のうちから一つを選択することを示します。項目が横に並べられ，記号｜で区切られている場合は，そのうちの一つを選択します。
（例）　｛A｜B｜C｝
　A，BまたはCのどれかを指定することを示します。

［　］
この記号で囲まれている項目は画面名または画面に表示されている項目であることを表します。

<　>
<　>内の名称がユーザの環境によって異なることを表します。

1.　アプリケーションサーバでのシステム構築の概要

アプリケーションサーバで構築するシステムには，J2EEアプリケーションを実行するシステムと，バッチアプリケーションを実行するシステムがあります。アプリケーションサーバでシステムを構築するには，セットアップウィザード，Smart Composer機能，および運用管理ポータルを使用する方法があります。

この章では，システムごとに使用できる構築方法の種類と，構築方法の概要について説明します。

＜この章の構成＞

1.1　構築するシステムの概要

1.2　J2EEアプリケーションを実行するシステムの構築

1.3　バッチアプリケーションを実行するシステムの構築

1.4　セットアップウィザードの概要

1.5　Smart Composer機能の概要

1.6　運用管理ポータルの概要

1.7　ほかのプログラムとの連携

1.8　アプリケーションサーバで構築するシステムで使用できるオプション製品

1.9　Windows Server 2008，Windows 7，またはWindows Vista使用時の注意事項

1.1　構築するシステムの概要

ここでは，アプリケーションサーバで構築できるシステムの種類と構築方法の概要について説明します。

アプリケーションサーバで構築できるシステムには，次の2種類があります。どちらのシステムを構築するかは，目的とする業務に応じて決定します。

J2EEアプリケーションを実行するシステム

ネットワーク経由などで送信されるクライアントからのリクエストを処理するオンライン業務を実行できるシステムです。J2EEアプリケーションは，オンライン業務を実行するためのアプリケーションです。

バッチアプリケーションを実行するシステム

定型的または定期的な作業をまとめて処理するバッチ業務を実行できるシステムです。バッチアプリケーションは，バッチ業務を実行するためのアプリケーションです。

J2EEアプリケーションおよびバッチアプリケーションを実行するシステムは，アプリケーションサーバが提供する構築支援機能（Management Server）を使用して構築します。Management Serverを使用する構築方法には，次の3種類があります。

セットアップウィザードを実行する

Smart Composer機能を使用する

運用管理ポータルを使用する

J2EEアプリケーションを実行するシステムの場合に使用できる構築方法については，「1.2.1　システムの構築方法の種類（J2EEアプリケーションを実行するシステム）」を参照してください。

バッチアプリケーションを実行するシステムの場合に使用できる構築方法については，「1.3.1　システムの構築方法の種類（バッチアプリケーションを実行するシステム）」を参照してください。

各アプリケーションとシステム構成の関係については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」または「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

参考

アプリケーションは，目的とする業務内容に合わせて開発してください。

J2EEアプリケーションの開発については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「1.5　J2EEアプリケーション開発の流れ」を参照してください。

バッチアプリケーションの開発については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.　バッチサーバによるアプリケーションの実行」，およびマニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「13.　バッチアプリケーションの開発」を参照してください。

1.2　J2EEアプリケーションを実行するシステムの構築

ここでは，J2EEアプリケーションを実行するシステムの構築方法の概要と，リソースとJ2EEアプリケーションの設定の概要について説明します。

＜この節の構成＞

1.2.1　システムの構築方法の種類（J2EEアプリケーションを実行するシステム）

1.2.2　リソースおよびJ2EEアプリケーションの設定で使用できる機能（J2EEアプリケーションを実行するシステム）

1.2.1　システムの構築方法の種類（J2EEアプリケーションを実行するシステム）

J2EEアプリケーションを実行するシステムの構築には，Management Serverが提供する次の3種類の機能を使用する方法があります。

セットアップウィザード
ウィザードプログラムを使用して，対話形式でシステムを構築できます。最小限の手順で実運用を開始できます。

Smart Composer機能
定義ファイルおよびコマンドによってシステムを一括構築できます。Webサーバ，J2EEサーバ，負荷分散機などのシステムを構成する複数のプロセスに対する操作を一括して実行できます。

運用管理ポータル
Webブラウザ（GUI画面）から，Management Serverを使用して構築したシステムをチューニングしたり，複数のマシンに対してリモート操作でシステムを構築したりできます。

参考

Management Serverを使用して構築する方法以外に，ファイル編集とコマンド実行でシステムを構築する方法があります。WebサーバやJ2EEサーバの定義ファイルを編集したり，プロセスごとに提供されているコマンドを実行したりして，システムを構築します。アプリケーションサーバが提供する定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」，およびマニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」を参照してください。プロセスごとに提供されているコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を参照してください。

それぞれの機能を使用して構築できるシステムの概要について説明します。

＜この項の構成＞

(1)　セットアップウィザードを使用したシステム構築の概要

(2)　Smart Composer機能を使用したシステム構築の概要

(3)　運用管理ポータルを使用したシステム構築の概要

(1)　セットアップウィザードを使用したシステム構築の概要

セットアップウィザードで構築できるのは，1台のマシンで構成されるJ2EEアプリケーションの実行環境です。Webブラウザからリクエストを受け付けて，そのリクエストを処理するWebフロントシステムを構築できます。

セットアップウィザードで構築できるシステム構成の例を次の図に示します。

図1-1　セットアップウィザードで構築できるシステム構成の例

この図のように，セットアップウィザードで構築したシステムでは，必要なプロセスがすべて1台のサーバに含まれます。

構築作業は，対話形式のプログラムで必要な情報を入力しながら進めます。事前に定義ファイルを用意したり，幾つものコマンドを実行したりする必要がなく，スムーズな環境構築を実現できます。

セットアップウィザードを使用して構築したシステムでは，Management Serverを利用した一括運用を実現できます。例えば，システムの起動や，システムの設定変更などを一括で実施できます。実行できる運用作業については，「9.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。なお，セットアップウィザードで実行できるのは，実行環境の構築と，リソースの設定，開始までです。J2EEアプリケーションの設定，開始，停止などの操作にはサーバ管理コマンドを使用します。セットアップウィザードの利点やシステム構築の作業については，「1.4　セットアップウィザードの概要」を参照してください。

(2)　Smart Composer機能を使用したシステム構築の概要

Smart Composer機能では，1台または複数台のマシンで構成されるJ2EEアプリケーションの実行環境を構築できます。Smart Composer機能を使用すると，事前に作成した定義ファイルの内容に従って，複数台のマシンで構成されるシステムをコマンドで一括構築できます。

Smart Composer機能で構築できるシステムを次に示します。

Webブラウザからリクエストを受け付けて，そのリクエストを処理するWebフロントシステム

SFOサーバやデータベースを使用してセッション情報の引き継ぎを実現するシステム

CTMを利用してリクエストを制御するシステム

Smart Composer機能で構築できるシステム構成の例を次の図に示します。

図1-2　Smart Composer機能で構築できるシステム構成の例（J2EEアプリケーションの実行環境）

Smart Composer機能は，次のようなシステムを一括構築する場合に適しています。

規模が大きく，一つの業務を複数のアプリケーションサーバで分散して実行するシステム

使用する機能やプロセス構成がパターン化されたアプリケーションサーバを複数配置するシステム

注意

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

Smart Composer機能を使用して構築したシステムでは，Management Serverを利用した一括運用を実現できます。例えば，システムの起動や，システムの設定変更などを一括で実施できます。また，日常運用では，J2EEアプリケーションを停止させることなく，J2EEアプリケーションを入れ替えたりすることもできます。実行できる運用作業については，「9.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。なお，J2EEアプリケーションおよびリソースの設定，開始，停止などの操作には，サーバ管理コマンドを使用します。Smart Composer機能の利点やシステム構築の作業については，「1.5　Smart Composer機能の概要」を参照してください。

(3)　運用管理ポータルを使用したシステム構築の概要

運用管理ポータルでは，1台または複数台のマシンで構成されるJ2EEアプリケーションの実行環境を構築できます。運用管理ポータルを使用すると，Webブラウザ上のGUI画面で，J2EEサーバ，Webサーバなどのサーバの構成や，個別のサーバの環境を設定して構築できます。

運用管理ポータルで構築できるシステムを次に示します。

Webブラウザからリクエストを受け付けて，そのリクエストを処理するWebフロントシステム

SFOサーバやデータベースを使用してセッション情報の引き継ぎを実現するシステム

CTMを利用してリクエストを制御するシステム

運用管理ポータルで構築できるシステム構成の例を次の図に示します。

図1-3　運用管理ポータルで構築できるシステム構成の例（J2EEアプリケーションの実行環境）

運用管理ポータルは，マシンやサーバを個別に設定できます。このため，マシンごとに異なる構成でサーバを配置するシステムを構築する場合に適しています。また，サーバの環境設定などをGUI画面の項目で設定できるので，構築済みシステムのチューニングにも適しています。

注意

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

運用管理ポータルを使用して構築したシステムでは，Management Serverを利用した一括運用を実現できます。運用管理ポータルを使用すると，論理サーバ単位，ホスト単位，または運用管理ドメイン単位で操作できます。例えば，論理サーバの起動，停止，運用監視などを論理サーバ単位，ホスト単位，または運用管理ドメイン単位で実施できます。また，GUI画面でJ2EEアプリケーションおよびリソースのインポート，開始，停止などの操作や，統合ユーザ管理のリソース使用状況の監視などを実施できます。

運用管理ポータルの操作方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルの利点やシステム構築の作業については，「1.6　運用管理ポータルの概要」を参照してください。

1.2.2　リソースおよびJ2EEアプリケーションの設定で使用できる機能（J2EEアプリケーションを実行するシステム）

J2EEアプリケーションを実行するシステムでは，リソースとして，データベース，OpenTP1，SMTPサーバ，JavaBeansリソースなどを利用できます。これらのリソースおよびJ2EEアプリケーションは，J2EEサーバ上で動作します。リソースおよびJ2EEアプリケーションの設定には，アプリケーションサーバが提供する次に示す機能を使用する方法があります。

サーバ管理コマンド
サーバ管理コマンドは，リソースとJ2EEアプリケーションのプロパティを定義し，リソースとJ2EEアプリケーションの開始／停止を実行するためのコマンド群（CUI）です。GUIでの対話処理が不要な場合などの運用環境の操作に適しています。

運用管理ポータル
運用管理ポータルでは，リソースおよびJ2EEアプリケーションのインポート，開始／停止などの操作をWebブラウザから実行できます。これらの操作は，サーバ単位だけでなく，Management Serverが管理しているすべてのサーバに対しても実施できます。なお，運用管理ポータルでは，リソースとJ2EEアプリケーションのプロパティは定義できません。リソースとJ2EEアプリケーションのプロパティを定義する場合は，サーバ管理コマンドを使用します。

サーバ管理コマンドでの設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。運用管理ポータルでの設定については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

1.3　バッチアプリケーションを実行するシステムの構築

ここでは，バッチアプリケーションを実行するシステムの構築方法の概要と，リソースの設定の概要について説明します。

＜この節の構成＞

1.3.1　システムの構築方法の種類（バッチアプリケーションを実行するシステム）

1.3.2　リソースの設定で使用できる機能（バッチアプリケーションを実行するシステム）

1.3.1　システムの構築方法の種類（バッチアプリケーションを実行するシステム）

バッチアプリケーションを実行するシステムは，次の2種類の機能を使用して構築できます。

Smart Composer機能
定義ファイルおよびコマンドによってシステムを一括構築できます。バッチサーバ，PRFデーモンなどのシステムを構成する複数のプロセスに対する操作を一括して実行できます。

運用管理ポータル
Webブラウザ（GUI画面）から，Management Serverを使用して構築したシステムをチューニングしたり，複数のマシンに対してリモート操作でシステムを構築したりできます。

参考

Management Serverを使用して構築する方法以外に，ファイル編集とコマンド実行でシステムを構築する方法があります。バッチサーバの定義ファイルを編集したり，プロセスごとに提供されているコマンドを実行したりして，システムを構築します。アプリケーションサーバが提供する定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」，およびマニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」を参照してください。プロセスごとに提供されているコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を参照してください。

それぞれの機能を使用して構築できるシステムの概要について説明します。

＜この項の構成＞

(1)　Smart Composer機能を使用したシステム構築の概要

(2)　運用管理ポータルを使用したシステム構築の概要

(1)　Smart Composer機能を使用したシステム構築の概要

Smart Composer機能では，1台または複数台のマシンで構成されるバッチアプリケーションの実行環境を構築できます。Smart Composer機能を使用すると，事前に作成した定義ファイルの内容に従って，複数台のマシンで構成されるシステムをコマンドで一括構築できます。なお，バッチアプリケーションを実行するタイミングは，JP1/AJS2などの関連プログラムでスケジューリングできます。

Smart Composer機能で構築できるシステムを次に示します。

JP1/AJS2などの関連プログラムで定義したジョブスケジューリングに従って，バッチアプリケーションを実行するシステム

CTMのスケジューリング機能を利用して，バッチアプリケーションの実行を制御するシステム

Smart Composer機能で構築できるシステム構成の例を次の図に示します。次の図は，関連プログラムとしてJP1/AJS2を使用する例です。

図1-4　Smart Composer機能で構築できるシステム構成の例（バッチアプリケーションの実行環境）

Smart Composer機能を使用して構築したシステムでは，Management Serverを利用した一括運用を実現できます。例えば，システムの起動や，システムの設定変更などを一括で実施できます。実行できる運用作業については，「11.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。なお，リソースの設定，開始，停止などの操作には，サーバ管理コマンドを使用します。Smart Composer機能の利点やシステム構築の作業については，「1.5　Smart Composer機能の概要」を参照してください。

(2)　運用管理ポータルを使用したシステム構築の概要

運用管理ポータルでは，1台または複数台のマシンで構成されるバッチアプリケーションの実行環境を構築できます。運用管理ポータルを使用すると，Webブラウザ上のGUI画面で，バッチサーバの構成や個別の環境を設定して構築できます。なお，バッチアプリケーションを実行するタイミングは，JP1/AJS2などの関連プログラムでスケジューリングできます。

運用管理ポータルで構築できるシステムを次に示します。

JP1/AJS2などの関連プログラムで定義したジョブスケジューリングに従って，バッチアプリケーションを実行するシステム

CTMのスケジューリング機能を利用して，バッチアプリケーションの実行を制御するシステム

運用管理ポータルで構築できるシステム構成の例を次の図に示します。次の図は，関連プログラムとしてJP1/AJS2を使用する例です。

図1-5　運用管理ポータルで構築できるシステム構成の例（バッチアプリケーションの実行環境）

運用管理ポータルは，マシンやサーバを個別に設定できます。このため，マシンごとに異なる構成でサーバを配置するシステムを構築する場合に適しています。また，サーバの環境設定などをGUI画面の項目で設定できるので，構築済みシステムのチューニングにも適しています。

運用管理ポータルを使用して構築したシステムでは，Management Serverを利用した一括運用を実現できます。運用管理ポータルを使用すると，論理サーバ単位，ホスト単位，または運用管理ドメイン単位で操作できます。例えば，論理サーバの起動，停止，運用監視などを論理サーバ単位，ホスト単位，または運用管理ドメイン単位で実施できます。また，GUI画面でリソースのインポート，開始，停止などの操作を実施できます。

運用管理ポータルの操作方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

運用管理ポータルの利点やシステム構築の作業については，「1.6　運用管理ポータルの概要」を参照してください。

1.3.2　リソースの設定で使用できる機能（バッチアプリケーションを実行するシステム）

バッチアプリケーションを実行するシステムでは，リソースとして，データベースを利用できます。リソースはバッチサーバ上で動作します。リソースの設定には，アプリケーションサーバが提供する次に示す機能を使用する方法があります。

サーバ管理コマンド
サーバ管理コマンドは，リソースのプロパティを定義し，リソースの開始／停止を実行するためのコマンド群（CUI）です。GUIでの対話処理が不要な場合などの運用環境の操作に適しています。

運用管理ポータル
運用管理ポータルでは，リソースのインポート，開始／停止などの操作をWebブラウザから実行できます。これらの操作は，サーバ単位だけでなく，Management Serverが管理しているすべてのサーバに対しても実施できます。なお，運用管理ポータルでは，リソースのプロパティは定義できません。リソースのプロパティを定義する場合は，サーバ管理コマンドを使用します。

サーバ管理コマンドでの設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。運用管理ポータルでの設定については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

1.4　セットアップウィザードの概要

セットアップウィザードは，ウィザードに従って対話形式で操作を進めることで，J2EEアプリケーションの実行環境を構築できる機能です。必要な設定を画面で選択しながら作業を進められるので，事前に複雑なパラメタの検討や定義ファイルの編集をしないで済みます。

ここでは，セットアップウィザードの目的と利点について説明します。

＜この節の構成＞

1.4.1　セットアップウィザードの目的

1.4.2　セットアップウィザードの利点

1.4.1　セットアップウィザードの目的

セットアップウィザードの目的は，製品を導入してから実際のシステム運用を開始するまでに掛かる時間を短縮し，運用をスムーズに開始することです。

セットアップウィザードでは，1台のマシンで構成される基本的なシステムを，最小限の手順で構築できるようにしています。構築作業では，J2EEアプリケーションを動作させる環境に最小限必要な項目だけを設定します。構築前に複雑な機能について検討しなくても，速やかに運用を開始できます。なお，セットアップウィザードで構築したシステムは，必要に応じてチューニングできます。

まずは最小限の設定でシステムの運用を開始して，稼働状況に応じてシステム設定を最適化する，という運用ができるようになります。

1.4.2　セットアップウィザードの利点

セットアップウィザードを使用すると，次のような利点があります。

＜この項の構成＞

(1)　対話形式のプログラムによる構築手順の簡略化

(2)　デフォルト設定によるシステム構築作業時間の短縮化

(1)　対話形式のプログラムによる構築手順の簡略化

セットアップウィザードを使用すると，対話形式でシステムを構築できます。事前に詳細なパラメタ設計や定義ファイルの作成をしたり，構築中に幾つものコマンドを実行したりする必要がありません。セットアップウィザードでは，画面に表示される内容を確認しながら，必要な項目を入力することで作業を進められます。このため，迷うことなく，システムの構築を進められます。セットアップウィザードによるシステム構築の例を次の図に示します。

図1-6　セットアップウィザードによるシステム構築の例

セットアップウィザードでは，システムに必要なサーバプロセスの構築と，リソースアダプタの設定までを一括で実行できます。J2EEアプリケーションのインポート，設定，開始については，セットアップウィザード実行後にサーバ管理コマンドを使用して実行します。

また，セットアップウィザードでは，構築済みシステムを複製元としたファイルを準備してコマンドを入力するだけで，ほかのマシンに複製できます。システム構築後にチューニングして変更したパラメタの情報も複製できるため，複製先のシステムのセットアップに掛かる時間を短縮できます。

(2)　デフォルト設定によるシステム構築作業時間の短縮化

セットアップウィザードには，標準セットアップとカスタムセットアップという2種類のセットアップ方法があります。

標準セットアップを選択した場合，WebサーバとJ2EEサーバで構成されるシステムをすべてデフォルト値で構築できます。データベースに接続するシステムの場合は，データベース接続環境についてだけ設定すれば，それ以外の項目はすべてデフォルト値を使用して構築できます。設定項目について細かく検討したり，設定したりする必要がありません。このため，システム構築作業時間を短縮できます。なお，一度設定した内容は，システム構築完了後に必要に応じてチューニングすることもできます。

システム構成，ユーザ名，使用するポート番号などを変更したい場合は，カスタムセットアップを選択できます。カスタムセットアップでは，それぞれの設定項目に任意の値を設定できます。なお，カスタムセットアップを選択した場合も，必要な項目だけをカスタマイズできます。それ以外の項目は，デフォルト値を使用してシステムを構築できます。この場合，デフォルト値は，「セットアップウィザードのデフォルト値」となります。このデフォルト値は，「簡易構築定義ファイルに指定できるパラメタの省略値」と異なることがあります。パラメタの省略値と異なるデフォルト値については，「付録D　セットアップウィザードで設定されるパラメタ」を参照してください。

1.5　Smart Composer機能の概要

Smart Composer機能とは，一般的な3階層モデルのアプリケーションサーバのシステムを，簡単に構築および運用できるよう支援するための機能です。Smart Composer機能の利用によってシステム設計の定型化・簡易化が実現するので，簡単に，そして迅速にシステム構築ができます。ここでは，Smart Composer機能の目的と利点について説明します。

＜この節の構成＞

1.5.1　Smart Composer機能の目的

1.5.2　Smart Composer機能の利点

1.5.1　Smart Composer機能の目的

システムは，負荷分散機，アプリケーションサーバ，データベース，運用管理サーバ，障害性能監視サービスやトランザクショントレースサービスなどの付加サービスといった多くの機能コンポーネントで構成されています。これらを業務要件に合わせて適切にシステム設計，定義設計，運用設計，障害設計，および構築することは，多大なノウハウと時間を必要としました。Smart Composer機能は，運用設計・障害設計がビルトインされた，高信頼でスケーラブルな実績のある推奨構成のシステムを，迅速に構築することを目的としています。

また，従来は，システムを構成する細かいプロセスを意識して，設定したり，運用操作をしたりする必要がありました。このため，プロセスの数だけ同じ設定をしたり，運用操作をしたりする必要がありました。Smart Composer機能では，プロセスを抽象的なモデルで表し，細かいプロセス単位の操作を排除できるので，操作性が飛躍的に向上し，運用コストの低減が図れます。

1.5.2　Smart Composer機能の利点

Smart Composer機能を使用すると，次のような利点があります。

＜この項の構成＞

(1)　システム構成のパターン化による一括構築

(2)　システムの構成変更や障害に対応した高度な運用

(3)　ほかのプログラムと連携したシステム構築・運用

(1)　システム構成のパターン化による一括構築

Smart Composer機能は，同じ機能やプロセスでパターン化された構成でシステムを構築する場合に向いています。Smart Composer機能では，業務サービスを提供する同じ構成のサーバの集合をサービスユニットといいます。このサービスユニットを複数のホストに対して配置して一括構築します。

サービスユニットの定義は，あらかじめファイルに必要最小限の設定内容を記述します。このファイルを使用して，複数のホストに対して一括構築したり，各サーバの環境を一括設定したりできます。

Smart Composer機能による一括構築の例を次の図に示します。

図1-7　Smart Composer機能による一括構築の例

Smart Composer機能では，サービスユニットの設定情報をまとめた定義ファイルを基に，Management Server上にWebシステムの情報モデルを生成します。生成した情報モデルを基にして，各サービスユニットに対して一括して情報を設定します。この図の場合，アプリケーションサーバマシンAとBのサービスユニット内にある，Webサーバ，PRFデーモン，およびJ2EEサーバの設定が一括でできます。

(2)　システムの構成変更や障害に対応した高度な運用

Smart Composer機能では，次の操作ができます。

サービスユニット単位でのシステムの開始・停止

負荷分散機の閉塞（負荷分散機による振り分け停止）

システムの一括設定変更・スケールアウト・スケールイン

これらによって，業務を停止しないで日常の運用メンテナンスができます。

また，サービスユニット単位でスケールアウトやスケールインが実施でき，容易にシステムを拡張したり縮小したりできます。

さらに，障害検知時コマンドを利用したり，リソース枯渇監視機能やJ2EEアプリケーションの実行時間監視機能と組み合わせたりして，問題発生時にサービスユニットを自動部分閉塞したり，自動部分再起動したりするような高度な運用ができます。

(3)　ほかのプログラムと連携したシステム構築・運用

Smart Composer機能を使用してシステムを構築・運用する際に，JP1やクラスタソフトウェアと連携することもできます。JP1と連携すると，アプリケーションサーバで構築したシステム以外のさまざまなハードウェア，ソフトウェア，ネットワークなどを含む業務システム全体をまとめて統合管理できます。クラスタソフトウェアと連携することで，障害発生時にシステムの切り替えができるので，システムの信頼性および稼働率を向上できます。Smart Composer機能使用時に連携できるプログラムについては，「1.7　ほかのプログラムとの連携」を参照してください。

1.6　運用管理ポータルの概要

運用管理ポータルは，Webブラウザ上でサーバの情報を設定し，それぞれのホストに配布して，システムを構築します。また，運用管理ポータルで構築したシステムは，システムの一括管理・運用ができます。ここでは，運用管理ポータルの目的と利点について説明します。

＜この節の構成＞

1.6.1　運用管理ポータルの目的

1.6.2　運用管理ポータルの利点

1.6.1　運用管理ポータルの目的

運用管理ポータルでは，Webブラウザ上に表示されるGUI画面を操作するだけで，システムを簡単に構築できることを目的としています。運用管理ポータルを使用すると，システム構築に必要な設定項目は画面に表示されるため，アプリケーションサーバ固有のファイルやコマンドの定義を覚える必要がありません。サーバプロセス単位のきめ細やかな設定も画面を使用することで操作性が向上し，システム構築に掛かるコストを削減できます。

また，運用管理ポータルでは，設定情報をホストごとに配布するため，ホストごとに異なる機能構成やプロセス構成を持つような，自由な構成のシステムも容易に構築できます。システム単位およびホスト単位のサーバ構成や，各サーバの設定情報を画面で確認しながら設定できるので，システムの部分的なチューニングや構成変更にも簡単に対応できます。

1.6.2　運用管理ポータルの利点

運用管理ポータルを使用すると，次のような利点があります。

＜この項の構成＞

(1)　Webブラウザを使用したシステム構築

(2)　Webブラウザを使用した運用操作

(3)　ほかのプログラムと連携したシステム構築・運用

(1)　Webブラウザを使用したシステム構築

Webブラウザ上に表示される［運用管理ポータル］画面を使用して，リモート操作でシステムを構築できます。Management Serverでは，運用管理ドメインという概念で，複数のマシン上のサーバプロセスを管理します。Management Serverで管理する対象となるWebサーバやJ2EEサーバなどのサーバプロセスを，論理サーバといいます。［運用管理ポータル］画面では，論理サーバの構成や設定を定義し，設定した情報を各サーバに配布してシステムを構築します。サーバの設定情報を読み込んで，ほかのサーバに設定することもできます。

運用管理ポータルによるシステム構築の例を次の図に示します。

図1-8　運用管理ポータルによるシステム構築の例

Webブラウザ（［運用管理ポータル］画面）から，それぞれのホストで動作させる論理サーバの構成を定義し，各論理サーバの設定情報を一括配布します。この図の場合，アプリケーションサーバマシンAではWebサーバおよびJ2EEサーバを定義し，アプリケーションサーバBではJ2EEサーバを定義して，それぞれの論理サーバに設定情報を配布しています。

運用管理ポータルを使用したシステムの構築については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の次の個所を参照してください。

3.　J2EEアプリケーションを実行するシステムの構築と削除

5.　バッチアプリケーションを実行するシステムの構築と削除

(2)　Webブラウザを使用した運用操作

運用管理ポータルでシステムを構築すると，Webブラウザからリモート操作で次の運用が実施できます。

論理サーバの起動と停止

リソースアダプタやJ2EEアプリケーションの開始と停止

論理サーバのステータス監視と稼働監視

統合ユーザ管理のリソース監視

また，マシンやサーバの追加，削除などによるシステム構成の変更もWebブラウザから実施できます。構築済みのサーバと情報が同じであれば，追加するサーバに読み込ませることで，設定手順を簡略化できます。ただし，個別に定義が必要なため，Smart Composer機能を使用する場合に比べると作業が煩雑になります。

なお，運用管理ポータルでもアプリケーションサーバの機能を使用したさまざまな運用が実施できます。運用管理ポータルを使用したシステムの運用については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の次の個所を参照してください。

4.　J2EEアプリケーションを実行するシステムの運用

6.　バッチアプリケーションを実行するシステムの運用

(3)　ほかのプログラムと連携したシステム構築・運用

運用管理ポータルを使用してシステムを構築・運用する際に，JP1やクラスタソフトウェアと連携することもできます。JP1と連携すると，アプリケーションサーバで構築したシステム以外のさまざまなハードウェア，ソフトウェア，ネットワークなどを含む業務システム全体をまとめて統合管理できます。クラスタソフトウェアと連携することで，障害発生時にシステムの切り替えができるので，システムの信頼性および稼働率を向上できます。運用管理ポータル使用時に連携できるプログラムについては，「1.7　ほかのプログラムとの連携」を参照してください。

1.7　ほかのプログラムとの連携

Smart Composer機能および運用管理ポータルを使用して構築するシステムでは，JP1やクラスタソフトウェアと連携することもできます。

＜この節の構成＞

(1)　JP1との連携

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

(1)　JP1との連携

Smart Composer機能および運用管理ポータルを使用して構築するシステムは，日立の統合システム運用管理製品であるJP1と連携して運用できます。JP1と連携すると，アプリケーションサーバ以外のホストやサーバプロセスを含めた業務システム全体の状況を集中監視したり，システム上のサーバの起動や停止を自動化したりできるようになります。また，JP1のUNIXジョブまたはPCジョブとしてバッチアプリケーションの実行コマンドを定義しておくと，バッチアプリケーションの自動実行ができます。

JP1と連携する場合，次に示す製品を使用した機能を利用できます。

JP1/IMとの連携（システムの集中監視）
アプリケーションサーバで構築したシステムを含めたシステム全体の監視ができるようになります。集中監視では，障害が発生した場合や，あらかじめ指定しておいたしきい値を超える事象が発生した場合などに，運用管理者に自動アクションで通知するように設定できます。この機能は，Smart Composer機能および運用管理ポータルで構築するシステムで利用できます。

JP1/IM - CMとの連携（システムの構成定義および管理）
業務システムをユーザの視点で，システム構成を定義したり，定義した構成情報を管理したりできます。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。この機能は，Smart Composer機能で構築するシステムで利用できます。

JP1/AJSとの連携（カスタムジョブによるシステムの自動運転）
アプリケーションサーバで構築したシステムの論理サーバやJ2EEアプリケーションの起動や停止のスケジュールをカスタムジョブに定義することで，システムの運用を自動化できます。
また，アプリケーションサーバで構築したシステムの論理サーバやバッチアプリケーションの起動や停止のスケジュールをカスタムジョブに定義することで，バッチアプリケーションの自動実行ができます。この機能は，Smart Composer機能および運用管理ポータルで構築するシステムで利用できます。

JP1/AJS2 - SOとの連携（シナリオによるシステムの自動運転）
アプリケーションサーバで構築したシステムの論理サーバやJ2EEアプリケーションの起動や停止のスケジュールをシナリオに定義することで，システムの運用を自動化できます。この機能は，Smart Composer機能で構築するシステムで利用できます。
アプリケーションサーバが提供するシナリオテンプレートを使用することで，Smart Composer機能を使用して構築したシステムの自動運転の定義が容易にできるようになります。

JP1/NETM/Auditとの連携（監査ログの収集と一元管理）
アプリケーションサーバが出力する監査ログを自動で収集，および一元管理できます。この機能は，Smart Composer機能および運用管理ポータルで構築するシステムで利用できます。

JP1と連携する場合には，Smart Composer機能または運用管理ポータルを使用した環境構築に加えて，JP1と連携するための設定をする必要があります。JP1と連携するためには，Management ServerでのJP1連携の設定，定義ファイルの作成，JP1との連携で使用するファイルのJP1への登録などが必要です。なお，アプリケーションサーバでは，JP1と連携するための環境構築や運用支援機能として，JP1で使用するツリーやジョブの作成支援機能，およびJP1が扱う形式のデータ出力機能を提供しています。各JP1製品と連携する場合の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「12.　JP1と連携したシステムの運用」を参照してください。

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

Smart Composer機能および運用管理ポータルを使用して構築するシステムは，クラスタソフトウェアと連携して運用できます。連携できるクラスタソフトウェアを次に示します。

Microsoft Cluster ServiceまたはWindows Server Failover Cluster（Windowsの場合）
Microsoft Cluster ServiceまたはWindows Server Failover Clusterは，高い可用性を実現するために提供されているクラスタサービスのサーバクラスタ機能です。Microsoft Cluster ServiceはWindows Server 2003に，Windows Server Failover ClusterはWindows Server 2008に含まれています。

HAモニタ（AIX，HP-UXまたはLinuxの場合）
HAモニタは，システムの信頼性および稼働率の向上を目的とした，サーバプログラムを含めたシステムの切り替えを実現する日立のクラスタソフトウェアです。

クラスタソフトウェアと連携してシステムを運用することで，アプリケーションサーバに障害が発生した場合に，直ちに自動でアプリケーションサーバを切り替えたり，待機しているリカバリサーバで，障害が発生したアプリケーションサーバのリカバリ処理をしたりできます。これによって，システムの不稼働時間を短縮でき，信頼性や稼働率を高めることができます。

クラスタソフトウェアと連携する場合には，Smart Composer機能または運用管理ポータルを使用した環境構築に加えて，クラスタソフトウェアと連携するための設定をする必要があります。Microsoft Cluster Serviceと連携する場合には，クラスタアドミニストレータの設定，汎用スクリプトファイルの設定などが必要です。HAモニタと連携する場合には，HAモニタの設定，各論理サーバの設定などが必要です。

クラスタソフトウェアと連携する場合，次に示す系切り替え機能を利用できます。

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

アプリケーションサーバの1:1系切り替え
実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1にした構成とすることで，実行系のアプリケーションサーバに障害が発生したときに系を切り替えて，業務を続行できます。この機能は，運用管理ポータルで構築するシステムで利用できます。

運用管理サーバの1:1系切り替え
実行系の運用管理サーバと待機系の運用管理サーバを1:1にした構成とすることで，実行系の運用管理サーバに障害が発生したときに系を切り替えて，業務を続行できます。この機能は，Smart Composer機能および運用管理ポータルで構築するシステムで利用できます。ただし，バッチアプリケーションを実行するシステムでは利用できません。

相互系切り替え
実行系のアプリケーションサーバと待機系のアプリケーションサーバを1:1にして，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能するシステムです。少ない台数のアプリケーションサーバマシンで，むだの少ない運用ができるようになります。この機能は，Smart Composer機能および運用管理ポータルで構築するシステムで利用できます。

N:1リカバリシステム
N台の実行系のアプリケーションサーバに対して，1台のリカバリ専用の待機系のアプリケーションサーバを配置するシステムです。J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したとき，リカバリ専用サーバでトランザクションを決着できるようになります。この機能は，運用管理ポータルで構築するシステムで利用できます。ただし，バッチアプリケーションを実行するシステムでは利用できません。

ホスト単位管理モデルを対象とした系切り替えシステム
ホスト単位管理モデル構成の実行系N台と予備系1台を配置するシステムです。実行系のManagement Serverや運用管理エージェントに障害が発生したときに系を切り替えて，業務を続行できます。

クラスタソフトウェアと連携する場合のシステムの構築については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「18.　クラスタソフトウェアとの連携」を参照してください。

1.8　アプリケーションサーバで構築するシステムで使用できるオプション製品

アプリケーションサーバでは，オプション製品として，uCosminexus Client，Web RedirectorおよびuCosminexus Operatorを提供しています。これらのオプション製品を使用して，次のような環境と組み合わせたシステムを構築することもできます。

EJBクライアント環境
EJBクライアントアプリケーションを実行する環境です。EJBクライアント環境は，uCosminexus Clientで構築します。システムの構築方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「付録A　uCosminexus Client」を参照してください。

Webリダイレクタ環境
WebサーバとWebコンテナを別のサーバマシンで運用するシステムで，WebサーバとWebコンテナを連携させるための環境です。Webリダイレクタ環境は，Web Redirectorで構築します。システムの構築方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「付録D　Web Redirector」を参照してください。

実行環境に対するGUI操作環境
アプリケーションサーバをインストールしたマシンとは別のマシンから，GUI（Eclipseプラグイン）画面を使用して運用操作を実行する環境です。実行環境に対するGUI操作環境は，uCosminexus Operatorで構築します。システムの構築方法については，「付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）」を参照してください。

なお，システム構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

参考

J2EEアプリケーションの開発環境は，Developerで構築します。Developerでのシステム構築については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「2.　インストールとセットアップ」を参照してください。

Webアプリケーションだけを動作させる（Enterprise Beanを使用しない）実行環境を構築することもできます。Webアプリケーションだけを動作させる場合，サーバの動作モードとしてサーブレットエンジンモードを使用できます。サーブレットエンジンとは，サーブレット実行機能，JSP実行機能を持つサーバのことです。なお，この機能は，旧バージョンとの互換用の機能です。サーブレットエンジンモードで動作するシステムの構築については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「10.6.1　サーブレットエンジンモードでのシステム構築」を参照してください。

1.9　Windows Server 2008，Windows 7，またはWindows Vista使用時の注意事項

ここでは，Windows Server 2008，Windows 7，またはWindows Vistaで，アプリケーションサーバを使用したシステムを構築，運用する場合の注意事項について説明します。

＜この節の構成＞

1.9.1　管理者特権で実行する必要がある操作

1.9.2　JIS X0213:2004に含まれるUnicodeの補助文字を使用する場合の注意事項

1.9.1　管理者特権で実行する必要がある操作

ここでは，Windows Server 2008，Windows 7，またはWindows Vistaを使用している場合で，管理者特権で実行する必要がある操作について説明します。なお，システムドライブをCドライブとして説明します。

＜この項の構成＞

(1)　プログラムのインストール

(2)　アプリケーションサーバが提供するコマンドの使用

(3)　アプリケーションサーバが提供する定義ファイルの更新

(4)　Eclipseでの操作

(5)　サンプルプログラムの使用

(1)　プログラムのインストール

アプリケーションサーバの製品や構成ソフトウェア，Eclipseなどのプログラムを，C:¥Program Files以下のディレクトリにインストールする場合，管理者特権で実行する必要があります。インストール時に，［UAC］ダイアログが表示される場合は，［UAC］ダイアログで管理者アカウントのパスワードを入力してください。

(2)　アプリケーションサーバが提供するコマンドの使用

アプリケーションサーバが提供するコマンドは，管理者特権で実行する必要があります。アプリケーションサーバが提供するコマンドは，「管理者：コマンドプロンプト」で実行してください。

「管理者：コマンドプロンプト」は，Windows Server 2008，Windows 7，またはWindows Vistaで提供されている機能を使用して起動してください。起動方法の例を次に示します。

［スタート］ボタンをクリックします。

［すべてのプログラム］－［アクセサリ］を選択します。

［コマンド プロンプト］を右クリックして，［管理者として実行］をクリックします。
管理者のパスワードまたは確認を求められた場合は，画面の指示に従って，パスワードを入力するか，または確認情報を提供してください。

(3)　アプリケーションサーバが提供する定義ファイルの更新

アプリケーションサーバが提供する定義ファイルは，管理者特権で更新する必要があります。管理者特権のないユーザが定義ファイルを更新しても，C:¥Program Files以下のディレクトリにある定義ファイルは更新されません。管理者特権のないユーザが更新したファイルは，次に示すディレクトリ以下に保存されます。

C:¥Users¥<ユーザ名>¥AppData¥Local¥VirtualStore

なお，アプリケーションサーバは管理者特権で起動されるため，管理者特権のないユーザが更新した定義ファイルの内容は無視されます。

(4)　Eclipseでの操作

C:¥Program Files以下のディレクトリまたはC:¥windows以下のディレクトリに対する操作には制限があります。これらの制限されたディレクトリに対して，Eclipseのワークスペースを保存すると，リダイレクション機能によって，操作対象のファイルはリダイレクトされ，次の場所に格納されます。

C:¥Users¥<ユーザ名>¥AppData¥Local¥VirtualStore¥Program Files

保存したファイルの実体は上記の場所に格納されていますが，Eclipse上からはC:¥Program Files以下に実ファイルがあるかのように，ファイルを読み込んだり，書き込んだりできます。

(5)　サンプルプログラムの使用

アプリケーションサーバが提供するサンプルプログラムを実行する場合は，書き込み権限のある別のディレクトリへサンプルプログラムをコピーして使用することをお勧めします。

アプリケーションサーバの製品をデフォルトでインストールした場合，サンプルプログラムは，C:¥Program Files以下のディレクトリに格納されます。管理者特権のないユーザがサンプルプログラムを実行すると，サンプルプログラムで出力されるログファイルなどが，次に示すディレクトリ以下に保存されます。

C:¥Users¥<ユーザ名>¥AppData¥Local¥VirtualStore

このため，アプリケーションサーバの製品をデフォルトでインストールしたディレクトリのまま，サンプルプログラムを使用する場合は，管理者特権で実行してください。サンプルプログラムを管理者特権で使用する場合は，「管理者：コマンドプロンプト」で実行する必要があります。エクスプローラからバッチファイルを右クリックして，［管理者として実行］をクリックした場合，正しく動作しません。

なお，アプリケーションサーバが提供するサンプルプログラムについては，「付録F　アプリケーションサーバが提供するサンプルプログラム」を参照してください。

1.9.2　JIS X0213:2004に含まれるUnicodeの補助文字を使用する場合の注意事項

Windows Server 2008，Windows 7，またはWindows VistaでサポートされたJIS X0213:2004の第三水準および第四水準の文字の一部には，Unicodeの補助文字が含まれます。Unicodeの補助文字とは，基本多言語面以外の文字（UnicodeのコードポイントがU+10000～U+10FFFFの範囲の文字）のことです。UTF-16エンコーディングでは，サロゲートペアとして表されます。

Unicodeの補助文字を使用する場合の注意事項を次に示します。

＜この項の構成＞

(1)　リクエストで使用する場合の注意事項

(2)　環境構築／運用時の注意事項

(1)　リクエストで使用する場合の注意事項

アプリケーションサーバに対して，Internet ExplorerなどのクライアントからUnicodeの補助文字を含むリクエストを送信した場合，Unicodeの補助文字は，ログやPRFトレースに正しく出力されません。ただし，その場合も，Unicodeの補助文字以外の文字は，ログやPRFトレースに正しく出力されます。

また，リクエストにUnicodeの補助文字が含まれる場合も，アプリケーションは正しく動作します。

リクエストでのUnicodeの補助文字の使用を制限したい場合には，アプリケーションでの対応などを検討してください。

(2)　環境構築／運用時の注意事項

アプリケーションサーバを構築，運用する場合，およびアプリケーションやリソースをデプロイする場合に使用する定義に，Unicodeの補助文字は使用できません。

Unicodeの補助文字を使用できない定義の例を示します。

EAR，WAR，JAR，EJB-JAR，サーブレット，JSP，クラス，メソッド，引数，または変数の名称

DD内の各種定義

システムのインストール先の指定値

そのほか，各種定義ファイルの設定値

2.　セットアップウィザードを使用したシステムのセットアップ

この章では，セットアップウィザードを使用したシステムのセットアップについて説明します。なお，セットアップウィザードで使用するコマンドやファイルについては，「3.　セットアップウィザードで使用するコマンドとファイル」を参照してください。

＜この章の構成＞

2.1　システムをセットアップする前に

2.2　システムのセットアップ

2.3　システムの運用

2.4　セットアップまたはアンセットアップ失敗時の対処

2.1　システムをセットアップする前に

ここでは，セットアップウィザードでシステムをセットアップする前に必要な次のことについて説明しています。

セットアップウィザードを使用したシステムのセットアップの流れ

システム構成とセットアップ方法の決定

インストール

セットアップウィザードを使用するための準備

また，セットアップウィザードを使用する場合の注意事項についても説明しています。

＜この節の構成＞

2.1.1　セットアップウィザードを使用したシステムのセットアップの流れ

2.1.2　システム構成とセットアップ方法の決定

2.1.3　インストール

2.1.4　セットアップウィザードを使用する前に

2.1.1　セットアップウィザードを使用したシステムのセットアップの流れ

セットアップウィザードを使用したシステムのセットアップに必要な作業の流れについて説明します。また，システム構築に必要な作業が，どのマニュアルに記載されているかについても説明します。システム構築に必要な作業と，マニュアルとの対応を次の図に示します。なお，図中の参照先マニュアルについては，表2-1を参照してください。

図2-1　セットアップウィザードを使用したシステム構築に必要な作業とマニュアルとの対応

図中の参照先マニュアルの一覧を次の表に示します。

表2-1　参照先マニュアルの一覧

項目 | 参照先マニュアル名
設計 | Cosminexus アプリケーションサーバ システム設計ガイド
構築運用 | Cosminexus アプリケーションサーバ システム構築・運用ガイド
機能解説※ | Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編

注※　記載内容については，各マニュアルの機能の分類，およびシステムの目的と機能の対応に関する説明を参照してください。

図中の1.～5.について説明します。

システムの設計
ここでは，構築しようとしているシステムの構成が，セットアップウィザードで構築できる構成かどうかを確認してください。セットアップウィザードでは，次に示すサーバ構成のマシンで構成されるシステムを構築できます。

WebサーバとJ2EEサーバが一つずつ含まれるアプリケーションサーバマシン

Webサーバをインプロセスで動作させるJ2EEサーバが一つ含まれるアプリケーションサーバマシン

システム構成については，「2.1.2　システム構成とセットアップ方法の決定」を参照してください。
なお，これら以外の構成は，セットアップウィザードでは構築できません。Smart Composer機能または運用管理ポータルを使用してください。

インストールと初期設定
必要な製品をインストールします。インストールについては，「2.1.3　インストール」を参照してください。
インストール後，セットアップウィザードを開始して，Management Server（運用管理機能）の設定などの初期設定を実施します。

システムの構築
次の作業を実行します。

セットアップウィザードによるシステムのセットアップ
セットアップウィザードでシステムの構成定義から構築までを実行します。
セットアップウィザードでは，デフォルトの設定でシステムを構築できる標準セットアップと，ユーザ任意の設定でシステムを構築できるカスタムセットアップが選択できます。
また，データベースと接続する場合は，データベース接続環境の設定として，リソースアダプタの設定をします。

J2EEアプリケーションの設定
サーバ管理コマンドを使用して，J2EEアプリケーションをインポートしてプロパティを定義します。

チューニング
必要に応じてアプリケーションサーバのパフォーマンスをチューニングします。チューニングは，セットアップウィザードによる初期構築後，実際にJ2EEアプリケーションに負荷を掛けながら実施します。設定したパラメタが適切かどうかを検証し，検証結果に基づいて設定を変更することで，パフォーマンスを向上させます。パラメタの設定変更は，次のどちらかの機能で実行します。

Smart Composer機能のファイルおよびコマンド

運用管理ポータル

チューニングについては，「2.3.2　チューニング」を参照してください。

システムの運用
構築したシステムを運用します。システムの日常運用，システムのメンテナンス，システム構成の変更などを，必要に応じて実施します。
システムの運用については「9.　J2EEアプリケーションを実行するシステムの運用」を参照してください。

2.1.2　システム構成とセットアップ方法の決定

ここでは，セットアップするシステム構成と，セットアップ方法を決定します。

セットアップしたいシステム構成によって選択できるセットアップ方法が異なります。そのため，システム構成を決定してからセットアップ方法を決定します。

＜この項の構成＞

(1)　システム構成の決定

(2)　セットアップ方法の決定

(1)　システム構成の決定

セットアップウィザードを使用してセットアップできるシステム構成には，次の2種類があります。

WebサーバとJ2EEサーバを配置するシステム

J2EEサーバだけを配置するシステム

セットアップウィザードを使用する前に，どちらのシステム構成でセットアップするか決定します。また，データベースに接続するかどうかも決定します。

それぞれのシステムの概要について説明します。

●WebサーバとJ2EEサーバを配置するシステム

WebサーバとJ2EEサーバを別々のプロセスで運用する場合のシステム構成です。アプリケーションサーバマシンの中に，Webサーバ，J2EEサーバ，およびPRFデーモンの三つのサーバプロセスを配置します。また，運用管理プロセスであるManagement Serverと運用管理エージェントを配置します。データベースへ接続する場合は，データベースを配置したデータベースサーバマシンが必要です。

WebサーバとJ2EEサーバを配置するシステムの構成例を次の図に示します。

図2-2　WebサーバとJ2EEサーバを配置するシステムの構成例

アプリケーションサーバ上に配置されたサーバプロセスの構成は，Webシステムという概念で管理されます。

●J2EEサーバだけを配置するシステム

Webサーバを配置しないでクライアントからのリクエストを受け付けたい場合のシステム構成です。クライアントからのリクエストはJ2EEサーバで受け付けます。アプリケーションサーバマシンの中にWebサーバをインプロセスで動作させるJ2EEサーバおよびPRFデーモンの二つのサーバプロセスを配置します。また，運用管理プロセスであるManagement Serverと運用管理エージェントを配置します。データベースへ接続する場合は，データベースを配置したデータベースサーバマシンが必要です。

J2EEサーバだけを配置するシステムの構成例を次の図に示します。

図2-3　J2EEサーバだけを配置するシステムの構成例

(2)　セットアップ方法の決定

セットアップウィザードを使用したセットアップには，標準セットアップとカスタムセットアップの2種類の方法があります。

どちらのセットアップ方法でシステムをセットアップするかは，セットアップするシステム構成によって異なります。「(1)　システム構成の決定」で決定したシステム構成から，セットアップ方法を選択します。セットアップするシステム構成と選択できるセットアップ方法の関係について，次の表に示します。

表2-2　セットアップするシステム構成と選択できるセットアップ方法

システム構成 | セットアップ方法
標準セットアップ | カスタムセットアップ
WebサーバとJ2EEサーバを配置するシステム | ○ | ○
J2EEサーバだけを配置するシステム | × | ○

（凡例）○：セットアップできます。　×：セットアップできません。

それぞれのセットアップ方法について説明します。

標準セットアップ
すべての設定項目にデフォルト値を自動的に設定するセットアップ方法です。WebサーバとJ2EEサーバを配置するシステムをセットアップできます。ただし，データベース接続環境については設定が必要です。

カスタムセットアップ
運用管理ユーザのユーザIDおよびパスワード，Webサーバのポート番号などの設定値を変更できるセットアップ方法です。WebサーバとJ2EEサーバを配置するシステムとJ2EEサーバだけを配置するシステムの両方をセットアップできます。システム構成を選択したい場合，および設定値を変更したい場合はこちらのセットアップ方法を選択してください。なお，設定値を変更しない項目については，デフォルト値のままセットアップできます。

セットアップウィザードで設定できる項目，および設定項目に対するデフォルト値については，「2.2.17　セットアップウィザードで設定できる項目」を参照してください。

2.1.3　インストール

製品をインストールします。各サーバマシンにそれぞれ必要なソフトウェア製品をインストールしてください。アプリケーションサーバおよびデータベースサーバそれぞれについてインストールする製品を説明します。

なお，アプリケーションサーバのインストール方法についてはリリースノートを参照してください。HiRDBのインストール方法については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。Oracleのインストール方法については，Oracleのマニュアルを参照してください。

＜この項の構成＞

(1)　アプリケーションサーバマシンにインストールする製品

(2)　データベースサーバマシンにインストールする製品

(1)　アプリケーションサーバマシンにインストールする製品

アプリケーションサーバマシンにインストールする製品について次に示します。

Application ServerまたはDeveloper

HiRDB Run TimeまたはOracle JDBC Thin Driver※
注※　データベースを使用する場合だけインストールします。

(2)　データベースサーバマシンにインストールする製品

データベースサーバマシンにインストールする製品について次に示します。データベースを使用しない場合は，データベースサーバマシンは不要です。

HiRDBまたはOracle※1，※2

注※1

データベースサーバの初期設定については，HiRDBの場合は，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。Oracleの場合は，Oracleのドキュメントを参照してください。

注※2

セットアップウィザードでセットアップするシステムから接続できるデータベースのバージョンは限られています。接続できるデータベースのバージョンは次のとおりです。

HiRDBの場合

HiRDB/Parallel Server Version 8以降およびHiRDB/Single Server Version 8以降

Oracleの場合

Oracle9i以降

2.1.4　セットアップウィザードを使用する前に

ここでは，セットアップウィザードを使用するための準備と，セットアップウィザードを使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　セットアップウィザードを使用するための準備

(2)　セットアップウィザードを使用する場合の注意事項

(1)　セットアップウィザードを使用するための準備

セットアップウィザードを使用するための準備について次に示します。

セットアップ済みのシステムが存在する場合，セットアップウィザードは使用できません。セットアップした方法ごとに次の対処を実施してください。

セットアップウィザードでセットアップしたシステムが存在する場合
セットアップウィザードを使用してアンセットアップしてください。

セットアップウィザード以外の方法でセットアップしたシステムが存在する場合
アプリケーションサーバをアンインストールして，再度インストールしてください。

使用するOSがUNIXの場合，次に示すユーザとグループをOSに登録してください。OSに登録されていないユーザまたはグループを指定した場合は，セットアップ実行時にエラーとなります。

Management Serverグループ

J2EEサーバを起動するユーザおよびグループ

Management Serverグループの設定については「2.2.6　運用管理機能の設定」を参照してください。J2EEサーバを起動するユーザについては「2.2.7　J2EEサーバの起動ユーザの設定」を参照してください。

(2)　セットアップウィザードを使用する場合の注意事項

セットアップウィザードを使用する場合の注意事項について次に示します。

セットアップウィザードを実行できるユーザは次のとおりです。次に示すユーザ以外がセットアップウィザードを実行した場合，エラーとなります。

Windowsの場合
Windows Server 2008，Windows 7，またはWindows Vistaのときは，管理者特権のあるユーザがコマンドを実行できます。それ以外のWindowsのOSのときは，Administrator権限のあるユーザがコマンドを実行できます。

UNIXの場合
root権限のあるユーザがコマンドを実行できます。

コマンドを実行している間は，Ctrl+Cキーなどで外部から停止しないでください。

セットアップ処理の途中でエラーが発生した場合は，セットアップ処理は停止され，セットアップ失敗の画面が表示されます。この場合，セットアップ中のシステムを削除してから再度セットアップを実行してください。セットアップ中のシステムを削除するには，セットアップウィザードでアンセットアップを実行します。アンセットアップについては「2.3.4　システムのアンセットアップ」を参照してください。

セットアップウィザード操作時に，設定値の入力を求められている場合に何も入力しないでEnterキーを押すと，設定項目にデフォルト値が適用されます。なお，デフォルト値がない設定項目もあります。デフォルト値がない設定項目でEnterキーを押すとエラーとなり，再度設定値の入力が求められます。

設定値の入力を求められている場合に，設定できない値を入力してEnterキーを押すとエラーとなり，次の画面が表示されます。

図2-4　設定できない値を入力した場合の画面

設定できる値が「0文字以上」の設定項目について設定値の入力を求められている場合に何も入力しないでEnterキーを押すと，空文字が適用されます。
なお，一度値を設定した項目について値を再入力する場合は次の画面が表示されます。

図2-5　設定できる値が「0文字以上」の設定項目について値を再入力する場合の画面

この画面が表示された場合に何も入力しないでEnterキーを押すと，設定済みの値は適用されないで，空文字が適用されます。

セットアップウィザードでは，セットアップウィザードを実行するホスト上にだけシステムをセットアップできます。ほかのホスト上にはシステムをセットアップできません。

セットアップウィザードを起動するために必要な環境変数はありません。ただし，セットアップ完了後は，運用作業で必要となる環境変数を設定してください。設定については，「7.3　環境変数の設定」を参照してください。

2.2　システムのセットアップ

セットアップウィザードを起動して，システムのセットアップをします。

ここでは，セットアップウィザードを使用したシステムのセットアップの流れを説明します。また，サーバ管理コマンドを使用したアプリケーションのインポートと開始の方法や，セットアップ情報ファイルを使用した一括セットアップについても説明します。セットアップ情報ファイルを使用した一括セットアップの詳細については，「2.2.15　セットアップ情報ファイルを使用した一括セットアップ」を参照してください。

＜この節の構成＞

2.2.1　システムのセットアップの流れ

2.2.2　セットアップウィザードの起動

2.2.3　セットアップの開始

2.2.4　セットアップ方法の選択

2.2.5　運用管理ユーザの設定

2.2.6　運用管理機能の設定

2.2.7　J2EEサーバの起動ユーザの設定

2.2.8　システム構成の選択

2.2.9　システム環境の設定

2.2.10　データベース接続環境の設定

2.2.11　セットアップ情報の確認

2.2.12　セットアップの実行

2.2.13　セットアップウィザードの終了

2.2.14　J2EEアプリケーションのインポートと開始

2.2.15　セットアップ情報ファイルを使用した一括セットアップ

2.2.16　アンセットアップ要求

2.2.17　セットアップウィザードで設定できる項目

2.2.1　システムのセットアップの流れ

システムのセットアップの流れについて次の図に示します。

図2-6　システムのセットアップの流れ

図中の1.～13.について，次の表で説明します。それぞれの手順の詳細については，表中の参照先を参照してください。

表2-3　システムのセットアップの流れ

項番
実施項目
説明
参照先

1
セットアップウィザードの起動
セットアップウィザードを起動します。
2.2.2

2
セットアップの開始
セットアップを開始します。
2.2.3

3
セットアップ方法の選択
次のどちらかのセットアップ方法を選択します。

標準セットアップ

カスタムセットアップ

2.2.4

4
運用管理ユーザの設定
運用管理ユーザのユーザIDとパスワードを設定します。運用管理ユーザをManagement Serverの管理ユーザと呼びます。
2.2.5

5
運用管理機能の設定
運用管理機能を使用する場合に必要なポート番号や管理グループを設定します。
2.2.6

6
J2EEサーバの起動ユーザの設定※
J2EEサーバのセットアップ・運用に関する操作を実行できる権限を持つJ2EEサーバの起動ユーザと，J2EEサーバの起動ユーザのグループを設定します。J2EEサーバの起動ユーザをComponent Container管理者と呼びます。
2.2.7

7
システム構成の選択
システム構成を選択します。WebサーバとJ2EEサーバを配置するシステムにするか，J2EEサーバだけを配置するシステムにするかを選択します。
2.2.8

8
システム環境の設定
システム名やポート番号を設定します。
2.2.9

9
データベース接続環境の設定
データベース接続環境を設定します。使用するデータベースをHiRDBとOracleのどちらにするかもここで設定します。
2.2.10

10
セットアップ情報の確認
3.～9.までに設定したセットアップ情報を確認します。
標準セットアップの場合，設定値はすべてデフォルト値となっています。
設定値を変更する場合は3.へ戻って設定をし直すことができます。
2.2.11

11
セットアップの実行
セットアップを実行します。
2.2.12

12
セットアップウィザードの終了
セットアップウィザードを終了します。
2.2.13

13
J2EEアプリケーションのインポートと開始
セットアップしたシステムに，J2EEアプリケーションをインポートします。J2EEアプリケーションのインポートと開始には，サーバ管理コマンドを使用します。
2.2.14

注※　UNIXの場合にだけ設定が必要です。

2.2.2　セットアップウィザードの起動

セットアップウィザードを起動します。

セットアップウィザードの起動方法はOSによって異なります。OSごとのセットアップウィザードの起動方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard

なお，セットアップウィザードは起動後もコマンドプロンプト上で動作します。

2.2.3　セットアップの開始

セットアップウィザードを起動すると，［ようこそ］画面が表示されます。ここでは，セットアップの開始を選択します。

参考

セットアップウィザードでセットアップ済みのシステムがある場合は，［アンセットアップ要求］画面（［ようこそ］画面）が表示されます。セットアップ済みのシステムを削除してからセットアップを開始します。アンセットアップ要求については「2.2.16　アンセットアップ要求」を参照してください。

セットアップウィザード以外でセットアップ済みのシステムがある場合は，次の画面が表示されます。

図2-7　［セットアップ失敗］画面（セットアップウィザード以外でセットアップ済みのシステムがある場合）

この画面が表示された場合は，アプリケーションサーバをアンインストールして，再度インストールしてから，セットアップを開始してください。

［ようこそ］画面では，次のように画面が遷移します。

図2-8　［ようこそ］画面での画面遷移

操作の流れ

［ようこそ］画面での操作の流れを次に示します。

システムをセットアップするかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，［セットアップ方法の選択］画面が表示されます。
9を選択した場合，［終了確認］画面が表示されます。

［ようこそ］画面を次に示します。

図2-9　［ようこそ］画面

設定項目

［ようこそ］画面で設定する項目を次の表に示します。

表2-4　［ようこそ］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップの実行 | システムをセットアップします。 | 1 | ［セットアップ方法の選択］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

2.2.4　セットアップ方法の選択

ここでは，「2.1.2(2)　セットアップ方法の決定」で決定したシステムのセットアップ方法を指定します。

［セットアップ方法の選択］画面では，操作の流れに従って次のように画面が遷移します。

図2-10　［セットアップ方法の選択］画面での画面遷移

操作の流れ

［セットアップ方法の選択］画面での操作の流れを次に示します。

システムのセットアップ方法を数字で入力します。

Enterキーを押します。
1を選択した場合，［データベース接続環境の設定］画面が表示されます。
2を選択した場合，［運用管理ユーザの設定］画面が表示されます。

［セットアップ方法の選択］画面を次に示します。

図2-11　［セットアップ方法の選択］画面

設定項目

［セットアップ方法の選択］画面で設定する項目を次の表に示します。

表2-5　［セットアップ方法の選択］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップ方法の選択 | 標準セットアップでシステムをセットアップします。すべての設定項目にデフォルト値※が適用されます。 | 1 | ［データベース接続環境の設定］画面
カスタムセットアップでシステムをセットアップします。設定項目にはそれぞれ任意の値を指定できます。 | 2 | ［運用管理ユーザの設定］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

注※　設定できる項目とデフォルト値の一覧については，「2.2.17　セットアップウィザードで設定できる項目」を参照してください。

2.2.5　運用管理ユーザの設定

カスタムセットアップの場合，ここで運用管理ユーザのアカウント（Management Serverの管理ユーザアカウント）を設定します。

［運用管理ユーザの設定］画面では，操作の流れに従って次のように画面が遷移します。

図2-12　［運用管理ユーザの設定］画面での画面遷移

操作の流れ

［運用管理ユーザの設定］画面での操作の流れを次に示します。

Management Serverの管理ユーザアカウントの設定が現在の設定でよいかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，［運用管理機能の設定］画面が表示されます。
2を選択した場合，［運用管理ユーザの設定］画面（設定内容変更）が表示されます。

手順2.で2を選択した場合，［運用管理ユーザの設定］画面（設定内容変更）で必要な項目に適切な値を入力します。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［運用管理ユーザの設定］画面が表示されます。

＜この項の構成＞

(1)　［運用管理ユーザの設定］画面

(2)　［運用管理ユーザの設定］画面（設定内容変更）

(1)　［運用管理ユーザの設定］画面

［運用管理ユーザの設定］画面を次に示します。

図2-13　［運用管理ユーザの設定］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-6　［運用管理ユーザの設定］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | －
カスタムセットアップ | Windows | 1/5
UNIX | 1/6

（凡例）－：該当しません。

設定項目

［運用管理ユーザの設定］画面で設定する項目を次の表に示します。

表2-7　［運用管理ユーザの設定］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
運用管理ユーザの設定 | 運用管理ユーザアカウントについて，現在の設定を適用します。 | 1 | ［運用管理機能の設定］画面
設定内容を変更します。 | 2 | ［運用管理ユーザの設定］画面（設定内容変更）
前の画面に戻ります。 | 0 | ［セットアップ方法の選択］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

(2)　［運用管理ユーザの設定］画面（設定内容変更）

［運用管理ユーザの設定］画面（設定内容変更）を次に示します。

図2-14　［運用管理ユーザの設定］画面（設定内容変更）

設定項目

［運用管理ユーザの設定］画面（設定内容変更）で設定する項目を次の表に示します。

表2-8　［運用管理ユーザの設定］画面（設定内容変更）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
運用管理ユーザアカウントのユーザID | Management Serverの管理ユーザアカウントのユーザIDを指定します。 | 半角英数字，一部の半角特殊文字※1，および半角スペース1文字以上 | －
管理ユーザアカウントのパスワード | Management Serverの管理ユーザアカウントのパスワードを指定します。 | 半角英数字，一部の半角特殊文字※1，および半角スペース0文字以上※2 | ［運用管理ユーザの設定］画面

（凡例）－：表示される画面がないことを示します。

注※1

入力できる半角特殊文字について次に示します。

! # $ & ' ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

注※2

空文字も入力値となります。

2.2.6　運用管理機能の設定

カスタムセットアップの場合，ここで運用管理機能（Management Server）の設定をします。

［運用管理機能の設定］画面では，操作の流れに従って次のように画面が遷移します。

図2-15　［運用管理機能の設定］画面での画面遷移

操作の流れ

［運用管理機能の設定］画面での操作の流れを次に示します。

Management Serverの設定が現在の設定でよいかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，使用しているOSによって表示される画面が異なります。
Windowsの場合は［システム構成の選択］画面が表示されます。
UNIXの場合は［J2EEサーバの起動ユーザの設定］画面が表示されます。
2を選択した場合，［運用管理機能の設定］画面（設定内容変更）が表示されます。

手順2.で2を選択した場合，［運用管理機能の設定］画面（設定内容変更）で必要な項目に適切な値を入力します。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［運用管理機能の設定］画面が表示されます。

＜この項の構成＞

(1)　［運用管理機能の設定］画面

(2)　［運用管理機能の設定］画面（設定内容変更）

(1)　［運用管理機能の設定］画面

［運用管理機能の設定］画面を次に示します。

図2-16　［運用管理機能の設定］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-9　［運用管理機能の設定］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | －
カスタムセットアップ | Windows | 2/5
UNIX | 2/6

（凡例）－：該当しません。

設定項目

［運用管理機能の設定］画面で設定する項目を次の表に示します。

表2-10　［運用管理機能の設定］画面で設定する項目

設定項目
設定内容
入力値
設定後に表示される画面

運用管理機能の設定
Management Serverについて，現在の設定を適用します。
1

Windowsの場合
［システム構成の選択］画面

UNIXの場合
［J2EEサーバの起動ユーザの設定］画面

設定内容を変更します。
2
［運用管理機能の設定］画面（設定内容変更）

前の画面に戻ります。
0
［運用管理ユーザの設定］画面

セットアップウィザードを終了します。
9
［終了確認］画面

(2)　［運用管理機能の設定］画面（設定内容変更）

［運用管理機能の設定］画面（設定内容変更）の図を次に示します。

図2-17　［運用管理機能の設定］画面（設定内容変更）

設定項目

［運用管理機能の設定］画面（設定内容変更）で設定する項目を次の表に示します。

表2-11　［運用管理機能の設定］画面（設定内容変更）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
Management Server接続HTTPポート番号 | Management Server接続HTTPポート番号を指定します。 | 1-65535の整数値 | －
Management Server終了要求受信ポート番号 | Management Server終了要求受信ポート番号を指定します。 | 1-65535の整数値 | －
Management Server内部通信用ポート番号 | Management Server内部通信用ポート番号を指定します。 | 1-65535の整数値 | －
運用管理エージェントのポート番号 | 運用管理エージェントのポート番号を指定します。 | 1-65535の整数値 | ［運用管理機能の設定］画面※1
Management Server管理グループに設定するグループ※2 | Management Server管理グループに設定するグループを指定します。 | 1文字以上 | ［運用管理機能の設定］画面

（凡例）－：表示される画面がないことを示します。

注※1　Windowsの場合だけ表示されます。

注※2　UNIXの場合だけ表示されます。

2.2.7　J2EEサーバの起動ユーザの設定

カスタムセットアップの場合，ここでJ2EEサーバの起動ユーザ（Component Container管理者）を設定します。J2EEサーバの起動ユーザは，UNIXの場合にだけ設定します。

［J2EEサーバの起動ユーザの設定］画面では，操作の流れに従って次のように画面が遷移します。

図2-18　［J2EEサーバの起動ユーザの設定］画面での画面遷移

操作の流れ

［J2EEサーバの起動ユーザの設定］画面での操作の流れを次に示します。

J2EEサーバの起動ユーザの設定が現在の設定でよいかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，［システム構成の選択］画面が表示されます。
2を選択した場合，［J2EEサーバの起動ユーザの設定］画面（設定内容変更）が表示されます。

手順2.で2を選択した場合，［J2EEサーバの起動ユーザの設定］画面（設定内容変更）で必要な項目に適切な値を入力します。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［J2EEサーバの起動ユーザの設定］画面が表示されます。

＜この項の構成＞

(1)　［J2EEサーバの起動ユーザの設定］画面

(2)　［J2EEサーバの起動ユーザの設定］画面（設定内容変更）

(1)　［J2EEサーバの起動ユーザの設定］画面

［J2EEサーバの起動ユーザの設定］画面を次に示します。

図2-19　［J2EEサーバの起動ユーザの設定］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-12　［J2EEサーバの起動ユーザの設定］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | －
カスタムセットアップ | Windows | －
UNIX | 3/6

（凡例）－：該当しません。

設定項目

［J2EEサーバの起動ユーザの設定］画面で設定する項目を次の表に示します。

表2-13　［J2EEサーバの起動ユーザの設定］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
J2EEサーバの起動ユーザの設定 | Component Container管理者について，現在の設定を適用します。 | 1 | ［システム構成の選択］画面
設定内容を変更します。 | 2 | ［J2EEサーバの起動ユーザの設定］画面（設定内容変更）
前の画面に戻ります。 | 0 | ［運用管理機能の設定］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

(2)　［J2EEサーバの起動ユーザの設定］画面（設定内容変更）

［J2EEサーバの起動ユーザの設定］画面（設定内容変更）の図を次に示します。

図2-20　［J2EEサーバの起動ユーザの設定］画面（設定内容変更）

設定項目

［J2EEサーバの起動ユーザの設定］画面（設定内容変更）で設定する項目を次の表に示します。

表2-14　［J2EEサーバの起動ユーザの設定］画面（設定内容変更）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
Component Container管理者 | Component Container管理者を指定します。 | 1文字以上 | －
Component Container管理者グループ | Component Container管理者グループを指定します。 | 1文字以上 | ［J2EEサーバの起動ユーザの設定］画面

（凡例）－：表示される画面がないことを示します。

2.2.8　システム構成の選択

カスタムセットアップの場合，ここでシステム構成を選択します。

［システム構成の選択］画面では，操作の流れに従って次のように画面が遷移します。

図2-21　［システム構成の選択］画面での画面遷移

操作の流れ

［システム構成の選択］画面での操作の流れを次に示します。

システム構成が現在の設定でよいかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，［システム環境の設定］画面が表示されます。
2を選択した場合，［システム構成の選択］画面（設定内容変更）が表示されます。

手順2.で2を選択した場合，［システム構成の選択］画面（設定内容変更）で必要な項目に適切な値を入力します。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［システム構成の選択］画面が表示されます。

＜この項の構成＞

(1)　［システム構成の選択］画面

(2)　［システム構成の選択］画面（設定内容変更）

(1)　［システム構成の選択］画面

［システム構成の選択］画面を次に示します。

図2-22　［システム構成の選択］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-15　［システム構成の選択］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | －
カスタムセットアップ | Windows | 3/5
UNIX | 4/6

（凡例）－：該当しません。

設定項目

［システム構成の選択］画面で設定する項目を次の表に示します。

表2-16　［システム構成の選択］画面で設定する項目

設定項目
設定内容
入力値
設定後に表示される画面

システム構成の選択（システム構成の確認）
システム構成について，現在の設定を適用します。
1
［システム環境の設定］画面

設定内容を変更します。
2
［システム構成の選択］画面（設定内容変更）

前の画面に戻ります。
0

Windowsの場合
［運用管理機能の設定］画面

UNIXの場合
［J2EEサーバの起動ユーザの設定］画面

セットアップウィザードを終了します。
9
［終了確認］画面

(2)　［システム構成の選択］画面（設定内容変更）

［システム構成の選択］画面（設定内容変更）の図を次に示します。

図2-23　［システム構成の選択］画面（設定内容変更）

設定項目

［システム構成の選択］画面（設定内容変更）で設定する項目を次の表に示します。

表2-17　［システム構成の選択］画面（設定内容変更）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
システム構成の選択 | WebサーバとJ2EEサーバを配置するシステム構成を選択します。 | 1 | ［システム構成の選択］画面
Webサーバをインプロセスで動作させるJ2EEサーバだけを配置するシステム構成を選択します。 | 2 | ［システム構成の選択］画面

2.2.9　システム環境の設定

カスタムセットアップの場合，ここでシステム環境を設定します。

［システム環境の設定］画面では，操作の流れに従って次のように画面が遷移します。

図2-24　［システム環境の設定］画面での画面遷移

操作の流れ

［システム環境の設定］画面での操作の流れを次に示します。

システム環境の設定が現在の設定でよいかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合，［データベース接続環境の設定］画面が表示されます。
2を選択した場合，［システム環境の設定］画面（設定内容変更）が表示されます。

手順2.で2を選択した場合，［システム環境の設定］画面（設定内容変更）で必要な項目に適切な値を入力します。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［システム環境の設定］画面が表示されます。

＜この項の構成＞

(1)　［システム環境の設定］画面

(2)　［システム環境の設定］画面（設定内容変更）

(1)　［システム環境の設定］画面

［システム環境の設定］画面を次に示します。

図2-25　［システム環境の設定］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-18　［システム環境の設定］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | －
カスタムセットアップ | Windows | 4/5
UNIX | 5/6

（凡例）－：該当しません。

設定項目

［システム環境の設定］画面で設定する項目を次の表に示します。

表2-19　［システム環境の設定］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
システム環境の確認 | システム環境について，現在の設定を適用します。 | 1 | ［データベース接続環境の設定］画面
設定内容を変更します。 | 2 | ［システム環境の設定］画面（設定内容変更）
前の画面に戻ります。 | 0 | ［システム構成の選択］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

(2)　［システム環境の設定］画面（設定内容変更）

［システム環境の設定］画面（設定内容変更）の図を次に示します。

図2-26　［システム環境の設定］画面（設定内容変更）

設定項目

［システム環境の設定］画面（設定内容変更）で設定する項目を次の表に示します。

表2-20　［システム環境の設定］画面（設定内容変更）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
Webシステム名 | Webシステム名を指定します。 | 半角英数字，記号（アンダースコア，ハイフン）32文字以内 | －
Webサーバの設定 | Webサーバのサーバ名※1 | Webサーバのサーバ名を指定します。 | 1文字以上 | －
Webサーバのポート番号※1 | Webサーバのポート番号を指定します。 | 1-65535の整数値 | －
J2EEサーバの設定 | httpのポート番号※2 | J2EEサーバのhttpのポート番号を指定します。 | 1-65535の整数値※3 | －
管理用サーバのポート番号 | J2EEサーバの管理用サーバのポート番号を指定します。 | 1-65535の整数値※3 | －
ajp13のポート番号※1 | J2EEサーバのajp13のポート番号を指定します。 | 1-65535の整数値※3 | －
インプロセスのネーミングサービスのポート番号 | J2EEサーバで使用するインプロセスのネーミングサービスのポート番号を指定します。 | 1-65535の整数値※3 | －
RMIレジストリのポート番号 | J2EEサーバのRMIレジストリのポート番号を指定します。 | 1-65535の整数値※3 | ［システム環境の設定］画面

（凡例）－：表示される画面がないことを示します。

注※1　

システム構成がWebサーバとJ2EEサーバを配置する構成（combined-tier）のときだけ表示されます。

注※2　

システム構成がJ2EEサーバだけを配置する構成（j2ee-tier）のときだけ表示されます。

注※3　

［J2EEサーバの起動ユーザの設定］画面（設定内容変更）でComponent Container管理者を設定済みの場合，1024-65535の整数値で指定します。［J2EEサーバの起動ユーザの設定］画面（設定内容変更）については，「2.2.7　J2EEサーバの起動ユーザの設定」を参照してください。

2.2.10　データベース接続環境の設定

ここでは，データベース接続環境を設定します。

［データベース接続環境の設定］画面では，操作の流れに従って次のように画面が遷移します。

図2-27　［データベース接続環境の設定］画面での画面遷移

操作の流れ

［データベース接続環境の設定］画面での操作の流れを次に示します。

データベースの接続環境を設定するかどうか英字で入力します。

Enterキーを押します。
yを選択した場合，［データベース接続環境の設定］画面（使用するデータベースの決定）が表示されます。
nを選択した場合，［データベース接続環境の設定］画面（設定内容確認）が表示されます。

手順2.でyを選択した場合，［データベース接続環境の設定］画面（使用するデータベースの決定）で使用するデータベースを選択します。
1を選択した場合，［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）が表示されます。
2を選択した場合，［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）が表示されます。

値を入力するごとにEnterキーを押します。
すべての設定項目に値を入力すると，［データベース接続環境の設定］画面（設定内容確認）が表示されます。

［データベース接続環境の設定］画面（設定内容確認）で現在の設定でよいかどうか数字で入力します。
1を選択した場合，［セットアップ情報］画面が表示されます。
2を選択した場合，［データベース接続環境の設定］画面が表示されます。

＜この項の構成＞

(1)　［データベース接続環境の設定］画面

(2)　［データベース接続環境の設定］画面（使用するデータベースの決定）

(3)　［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）

(4)　［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）

(5)　［データベース接続環境の設定］画面（設定内容確認）

(1)　［データベース接続環境の設定］画面

データベースの接続環境を設定するかどうかを決定します。

［データベース接続環境の設定］画面を次に示します。

図2-28　［データベース接続環境の設定］画面

図中の（n/m）は，セットアップの進行状況を表す数字です。セットアップ方法および使用するOSによって表示される数字が異なります。表示される数字について，次の表に示します。

表2-21　［データベース接続環境の設定］画面に表示される数字

セットアップ方法 | 使用するOS | 表示される数字
標準セットアップ | Windows/UNIX | 1/1
カスタムセットアップ | Windows | 5/5
UNIX | 6/6

設定項目

［データベース接続環境の設定］画面で設定する項目について次の表に示します。

表2-22　［データベース接続環境の設定］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
データベース接続環境の設定 | データベース接続環境の設定をします。 | y | ［データベース接続環境の設定］画面（使用するデータベースの決定）
データベース接続環境の設定をしません。 | n | ［データベース接続環境の設定］画面（設定内容確認）

(2)　［データベース接続環境の設定］画面（使用するデータベースの決定）

使用するデータベースを決定します。

［データベース接続環境の設定］画面（使用するデータベースの決定）を次に示します。

図2-29　［データベース接続環境の設定］画面（使用するデータベースの決定）

設定項目

［データベース接続環境の設定］画面（使用するデータベースの決定）で設定する項目について次の表に示します。

表2-23　［データベース接続環境の設定］画面（使用するデータベースの決定）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
使用するデータベース | HiRDBを使用します。 | 1 | ［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）
Oracleを使用します。 | 2 | ［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）

(3)　［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）

データベース（HiRDB）への接続設定をします。

［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）を次に示します。

図2-30　［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）

設定項目

［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）で設定する項目について次の表に示します。

表2-24　［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
データベースのホスト名 | データベースのホスト名を指定します。 | 1文字以上 | －
データベースのポート番号 | データベースのポート番号を指定します。 | 1-65535の整数値 | －
データベースのアクセスユーザ | データベースのアクセスユーザを指定します。 | 0文字以上 | －
アクセスユーザのパスワード | アクセスユーザのパスワードを指定します。 | 0文字以上 | －
JDBCドライバのパス | HiRDBが提供するJDBCドライバのパスを絶対パスで指定します。 | 1文字以上-OSの最大パス長※以下 | ［データベース接続環境の設定］画面（設定内容確認）

（凡例）－：表示される画面がないことを示します。

注※　「最大パス長」とは，OSで規定されているパス長の制限のことです。OSのパス長の制限については，ご使用のOSのドキュメントなどで確認してください。ただし，使用するOSがWindowsの場合，最大パス長は259です。

(4)　［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）

データベース（Oracle）への接続設定をします。

［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）を次に示します。

図2-31　［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）

設定項目

［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）で設定する項目について次の表に示します。

表2-25　［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
データベース名（SID） | データベース名（SID）を指定します。 | 1文字以上 | －
データベースのホスト名 | データベースのホスト名を指定します。 | 1文字以上 | －
データベースのポート番号 | データベースのポート番号を指定します。 | 1-65535の整数値 | －
データベースのアクセスユーザ | データベースのアクセスユーザを指定します。 | 0文字以上 | －
アクセスユーザのパスワード | アクセスユーザのパスワードを指定します。 | 0文字以上 | －
JDBCドライバのパス | Oracleが提供するJDBCドライバのパスを絶対パスで指定します。 | 1文字以上-OSの最大パス長※以下 | ［データベース接続環境の設定］画面（設定内容確認）

（凡例）－：表示される画面がないことを示します。

注※　「最大パス長」とは，OSで規定されているパス長の制限のことです。OSのパス長の制限については，ご使用のOSのドキュメントなどで確認してください。ただし，使用するOSがWindowsの場合，最大パス長は259です。

(5)　［データベース接続環境の設定］画面（設定内容確認）

［データベース接続環境の設定］画面（設定内容確認）の図を次に示します。

図2-32　［データベース接続環境の設定］画面（設定内容確認）

設定項目

［データベース接続環境の設定］画面（設定内容確認）で設定する項目を次の表に示します。

表2-26　［データベース接続環境の設定］画面（設定内容確認）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
データベース接続環境の設定（設定内容確認） | データベース接続環境について，現在の設定を適用します。 | 1 | ［セットアップ情報］画面
設定内容を変更します。 | 2 | ［データベース接続環境の設定］画面
前の画面に戻ります。 | 0 | ［システム環境の設定］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

2.2.11　セットアップ情報の確認

ここでは，セットアップ情報を確認して，セットアップの実行の決定をします。

［セットアップ情報］画面では，操作の流れに従って次のように画面が遷移します。

図2-33　［セットアップ情報］画面での画面遷移

操作の流れ

［セットアップ情報］画面での操作の流れを次に示します。

現在設定されているセットアップ情報でセットアップを開始するかどうかを数字で入力します。

Enterキーを押します。

1を選択した場合，［セットアップの実行］画面が表示されます。
ポート番号の指定値に不正があった場合はエラーとなり，［セットアップ情報］画面（ポート番号エラー）が表示されます。［セットアップ情報］画面（ポート番号エラー）でエラーの原因を確認し，Enterキーを押すと［セットアップ情報］画面に戻ります。

2を選択した場合，［セットアップ情報］画面（セットアップ情報の再設定）が表示されます。
yを選択すると［セットアップ方法の選択］画面が表示されます。
nを選択すると［セットアップ情報］画面に戻ります。

3を選択した場合，［セットアップ情報］画面（セットアップ情報ファイルの保存）が表示されます。
セットアップ情報ファイルがある場合，［セットアップ情報］画面（セットアップ情報ファイルの上書き）画面が表示されます。
yを選択すると［セットアップ情報］画面（セットアップ情報ファイルの保存）が表示されます。
nを選択すると［セットアップ情報］画面に戻ります。
セットアップ情報ファイルがない場合，［セットアップ情報］画面（セットアップ情報ファイルの保存）が表示されます。

＜この項の構成＞

(1)　［セットアップ情報］画面

(2)　［セットアップ情報］画面（セットアップ情報の再設定）

(3)　［セットアップ情報］画面（セットアップ情報の保存）

(1)　［セットアップ情報］画面

［セットアップ情報］画面の図を次に示します。

図2-34　［セットアップ情報］画面

設定項目

［セットアップ情報］画面で設定する項目を次の表に示します。

表2-27　［セットアップ情報］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップ情報の確認 | 現在設定されているセットアップ情報でセットアップを開始します。 | 1 | ［セットアップの実行］画面※
セットアップ情報を再設定します。現在の設定は保持されます。 | 2 | ［セットアップ情報］画面（セットアップ情報の再設定）
セットアップ情報をファイルに保存します。 | 3 | ［セットアップ情報］画面（セットアップ情報ファイルの保存）
前の画面に戻ります。 | 0 | ［データベース接続環境の設定］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

注※　セットアップ開始後に，ポート番号の指定値に不正があった場合は，エラーとなり，［セットアップ情報］画面（ポート番号エラー）が表示されます。［セットアップ情報］画面（ポート番号エラー）の例を次に示します。

図2-35　［セットアップ情報］画面（ポート番号エラー）

この画面でEnterキーを押すと，［セットアップ情報］画面に戻ります。

(2)　［セットアップ情報］画面（セットアップ情報の再設定）

［セットアップ情報］画面（セットアップ情報の再設定）の図を次に示します。

図2-36　［セットアップ情報］画面（セットアップ情報の再設定）

設定項目

［セットアップ情報］画面（セットアップ情報の再設定）で設定する項目を次の表に示します。

表2-28　［セットアップ情報］画面（セットアップ情報の再設定）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップ情報（セットアップ情報の再設定） | セットアップ情報を再設定します。現在の設定は保持されます。 | y | ［セットアップ方法の選択］画面
セットアップ情報を再設定しないで，前の画面に戻ります。 | n | ［セットアップ情報］画面

［セットアップ情報］画面（セットアップ情報の再設定）から［セットアップ方法の選択］画面に戻って1（標準セットアップ）を指定した場合，すべての設定項目にデフォルト値が適用されます。そのため，［セットアップ方法の選択］画面（設定値確認）が表示されます。［セットアップ方法の選択］画面（設定値確認）を次に示します。

図2-37　［セットアップ方法の選択］画面（設定値確認）

設定項目

［セットアップ方法の選択］画面（設定値確認）で設定する項目を次の表に示します。

表2-29　［セットアップ方法の選択］画面（設定値確認）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
［セットアップ方法の選択］画面（設定値確認） | 標準セットアップでシステムをセットアップします。すべての設定項目にデフォルト値※が適用されます。設定済みの値は破棄されます。 | y | ［データベース接続環境の設定］画面
標準セットアップを中止して，［セットアップ方法の選択］画面に戻ります。 | n | ［セットアップ方法の選択］画面

注※　設定できる項目とデフォルト値の一覧については，「2.2.17　セットアップウィザードで設定できる項目」を参照してください。

(3)　［セットアップ情報］画面（セットアップ情報の保存）

［セットアップ情報］画面で3を設定したあとに表示される画面はセットアップ情報ファイルがあるかどうかによって異なります。セットアップ情報の保存を選択したあとに表示される画面について次の表に示します。

表2-30　セットアップ情報の保存を選択したあとに表示される画面

セットアップ情報ファイルの有無 | 実行後に表示される画面
あり | ［セットアップ情報］画面（セットアップ情報ファイルの上書き）
なし | ［セットアップ情報］画面（セットアップ情報ファイルの保存）

(a)　［セットアップ情報］画面（セットアップ情報ファイルの上書き）

図2-38　［セットアップ情報］画面（セットアップ情報ファイルの上書き）

設定項目

［セットアップ情報］画面（セットアップ情報ファイルの上書き）で設定する項目を次の表に示します。

表2-31　［セットアップ情報］画面（セットアップ情報ファイルの上書き）画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップ情報（セットアップ情報ファイルの上書き） | セットアップ情報ファイルを上書きします。 | y | ［セットアップ情報］画面（セットアップ情報ファイルの保存）
セットアップ情報ファイルを作成しないで，前の画面に戻ります。 | n | ［セットアップ情報］画面

(b)　［セットアップ情報］画面（セットアップ情報ファイルの保存）

［セットアップ情報］画面（セットアップ情報ファイルの保存）の図を次に示します。

図2-39　［セットアップ情報］画面（セットアップ情報ファイルの保存）

この画面でEnterキーを押すと，［セットアップ情報］画面に戻ります。

2.2.12　セットアップの実行

ここではセットアップの実行について説明します。

［セットアップの実行］画面は，セットアップの実行結果および操作に従って次のように画面が遷移します。

図2-40　［セットアップの実行］画面での画面遷移

操作の流れ

［セットアップの実行］画面でセットアップが失敗した場合の操作の流れを次に示します。なお，セットアップが成功した場合の操作はありません。

障害時のログを採取するかどうかを英字で入力します。

Enterキーを押します。
yを選択した場合，［セットアップ失敗］画面（障害時のログを採取する場合）が表示されます。
nを選択した場合，［セットアップ失敗］画面（障害時のログを採取しない場合）が表示されます。
それぞれ画面が表示されたあと，セットアップウィザードは終了します。
セットアップに失敗した場合の対処については，「2.4　セットアップまたはアンセットアップ失敗時の対処」を参照してください。

＜この項の構成＞

(1)　［セットアップの実行］画面

(2)　［セットアップ完了］画面

(3)　［セットアップ失敗］画面

(1)　［セットアップの実行］画面

［セットアップの実行］画面を次に示します。

図2-41　［セットアップの実行］画面

セットアップの実行後，表示される画面はセットアップの実行結果によって異なります。セットアップ実行後に表示される画面について次の表に示します。

表2-32　セットアップ実行後に表示される画面

セットアップの実行結果 | 実行後に表示される画面
完了 | ［セットアップ完了］画面
失敗 | ［セットアップ失敗］画面

(2)　［セットアップ完了］画面

［セットアップ完了］画面を次に示します。

図2-42　［セットアップ完了］画面

セットアップ完了のメッセージのあとに，セットアップ情報ファイル，セットアップ情報リストの出力先が表示されます。さらに，セットアップ実行時に使用した，簡易構築定義ファイルと，DBConnectorのConnector属性ファイルの出力先，およびリソースアダプタの格納先が表示されます。

(3)　［セットアップ失敗］画面

［セットアップ失敗］画面を次に示します。

図2-43　［セットアップ失敗］画面

セットアップ失敗に関する詳細メッセージのあとに，セットアップ情報ファイルの出力先が表示されます。

設定項目

［セットアップ失敗］画面で設定する項目を次の表に示します。

表2-33　［セットアップ失敗］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
資料の採取 | 障害時の資料（snapshotログ）を採取して，セットアップウィザードを終了します。 | y | ［セットアップ失敗］画面（障害時のログを採取する場合）
障害時の資料（snapshotログ）を採取しないで，セットアップウィザードを終了します。 | n | ［セットアップ失敗］画面（障害時のログを採取しない場合）

［セットアップ失敗］画面（障害時のログを採取する場合）を次に示します。

図2-44　［セットアップ失敗］画面（障害時のログを採取する場合）

［セットアップ失敗］画面（障害時のログを採取しない場合）を次に示します。

図2-45　［セットアップ失敗］画面（障害時のログを採取しない場合）

2.2.13　セットアップウィザードの終了

セットアップウィザードを終了すると，［終了確認］画面が表示されます。［終了確認］画面での操作を次に示します。

操作の流れ

セットアップウィザードを終了するかどうかを英字で入力します。

Enterキーを押します。

［終了確認］画面を次に示します。

図2-46　［終了確認］画面

設定項目

［終了確認］画面で設定する項目を次の表に示します。

表2-34　［終了確認］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップの終了 | セットアップウィザードを終了します。 | y | －
セットアップウィザードを終了しないで，直前の画面に戻ります。 | n | 直前の画面

（凡例）－：表示される画面がないことを示します。

2.2.14　J2EEアプリケーションのインポートと開始

J2EEアプリケーションのインポートと開始の手順について説明します。

J2EEアプリケーションのインポートと開始には，サーバ管理コマンドを使用します。

サーバ管理コマンドの詳細についてはマニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」，サーバ管理コマンドでのJ2EEアプリケーションの操作の詳細についてはマニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。

なお，ここで説明するJ2EEアプリケーションは作成済みであることを前提としています。また，cosminexus.xmlを含むアプリケーションであることを前提としています。J2EEアプリケーションは，アプリケーション開発時に作成しておいてください。アプリケーションの作成については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」を参照してください。

ここでは，次のJ2EEアプリケーションをインポートして開始する手順を例にして説明します。

表2-35　J2EEアプリケーションのファイル名と表示名

種別 | 名前
ファイル名 | MyApp.ear
表示名 | MyApp

J2EEアプリケーションをインポートします。
サーバ管理コマンドを使用して，J2EEアプリケーションをJ2EEサーバへインポートします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp MyJ2EEServer -f MyApp.ear

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp MyJ2EEServer -f MyApp.ear

J2EEアプリケーションを開始します。
サーバ管理コマンドを使用して，J2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp MyJ2EEServer -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartapp MyJ2EEServer -name MyApp

注意

システムをセットアップしているホストと別のホストからサーバ管理コマンドを実行する場合は，-nameserverオプションを指定する必要があります。-nameserverオプションの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjimportapp（J2EEアプリケーションのインポート）」および「cjstartapp（J2EEアプリケーションの開始）」を参照してください。

参考

次に示す場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

インポート済みのJ2EEアプリケーションのプロパティを編集する場合

cosminexus.xmlを含まないアプリケーションの場合

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

2.2.15　セットアップ情報ファイルを使用した一括セットアップ

setupwizardコマンドを使用するとセットアップ情報ファイルを使用した一括セットアップができます。ここでは，セットアップ情報ファイルを使用した一括セットアップについて説明します。

セットアップ情報ファイルは，セットアップ情報の確認時に保存しているか，一度セットアップを実行している場合に保存されるファイルです。セットアップ情報ファイルには，設定済みのシステムの情報が保存されています。セットアップ情報ファイルを使用すると，設定済みの情報を適用してシステムのセットアップができます。一括セットアップで使用できるセットアップ情報ファイルの種類，および出力先については「3.3　セットアップウィザードで使用するファイル」を参照してください。セットアップ情報ファイルの作成については「2.2.11(3)　［セットアップ情報］画面（セットアップ情報の保存）」を参照してください。

一括セットアップには，セットアップ情報ファイルの内容を確認してからセットアップを開始する方法（通常開始）と，セットアップ情報ファイルの内容を確認しないで直ちにセットアップを開始する方法（強制開始）があります。

参考

セットアップ情報ファイルの内容は，setupwizardコマンドを使用すると画面に表示できます。一括セットアップを開始する前に，セットアップ情報ファイルの内容を確認したい場合に使用してください。セットアップ情報ファイルの内容表示については，「3.1(2)　セットアップ情報ファイルの内容表示」を参照してください。

＜この項の構成＞

(1)　一括セットアップ（通常開始）

(2)　一括セットアップ（強制開始）

(1)　一括セットアップ（通常開始）

一括セットアップ（通常開始）の操作の流れについて説明します。

操作の流れ

［一括セットアップ］画面（通常開始）での操作を次に示します。

setupwizardコマンドを実行します。
［一括セットアップ］画面（通常開始）が表示されます。

システムを一括セットアップするかどうかを数字で入力します。

Enterキーを押します。
1を選択した場合は［セットアップの実行］画面が表示されます。
2を選択した場合は［セットアップ方法の選択］画面が表示されます。

(a)　一括セットアップ（通常開始）の開始

一括セットアップ（通常開始）の開始方法はOSによって異なります。OSごとの一括セットアップの開始方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -f <セットアップ情報ファイル>

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -f <セットアップ情報ファイル>

一括セットアップ（通常開始）を開始すると，［一括セットアップ］画面（通常開始）が表示されます。なお，セットアップ済みのシステムがある場合は，［アンセットアップ要求］画面（［一括セットアップ］画面）が表示されます。

(b)　［一括セットアップ］画面（通常開始）

［一括セットアップ］画面（通常開始）を次に示します。

図2-47　［一括セットアップ］画面（通常開始）

設定項目

［一括セットアップ］画面（通常開始）で設定する項目を次の表に示します。

表2-36　［一括セットアップ］画面（通常開始）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップの実行 | システムをセットアップします。 | 1 | ［セットアップの実行］画面
セットアップ情報を再設定します。セットアップ情報ファイルに保存されている設定は保持されます。 | 2 | ［セットアップ方法の選択］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

(2)　一括セットアップ（強制開始）

一括セットアップ（強制開始）の操作の流れについて説明します。

操作の流れ

［一括セットアップ］画面（強制開始）での操作を次に示します。

setupwizardコマンドに-forceオプションを指定して実行します。

(a)　一括セットアップ（強制開始）の開始

一括セットアップ（強制開始）の開始方法はOSによって異なります。OSごとの一括セットアップの開始方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -f <セットアップ情報ファイル> -force

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -f <セットアップ情報ファイル> -force

コマンドを実行すると，一括セットアップ（強制開始）が開始されます。一括セットアップ（強制開始）開始後に表示される画面は一括セットアップ（強制開始）の実行結果によって異なります。一括セットアップ（強制開始）実行後に表示される画面については表2-37を参照してください。なお，セットアップ済みのシステムがある場合，［一括セットアップ］画面（アンセットアップ実行中）が表示されます。

(b)　［一括セットアップ］画面（強制開始）

一括セットアップ（強制開始）の実行後，表示される画面は一括セットアップ（強制開始）の実行結果によって異なります。一括セットアップ（強制開始）実行後に表示される画面について次の表に示します。

表2-37　一括セットアップ（強制開始）実行後に表示される画面

一括セットアップ（強制開始）の実行結果 | 実行後に表示される画面
完了 | ［一括セットアップ完了］画面（強制開始）
失敗 | ［一括セットアップ失敗］画面（強制開始）

参考

なお，一括セットアップ（強制開始）実行時に，セットアップ済みのシステムがある場合，次の画面が表示されます。

図2-48　［一括セットアップ］画面（アンセットアップ実行中）

この画面が表示されたあと，一括セットアップ（強制開始）の実行結果に従って，［一括セットアップ完了］画面（強制開始）または［一括セットアップ失敗］画面（強制開始）が表示されます。

●［一括セットアップ完了］画面（強制開始）

［一括セットアップ完了］画面（強制開始）を次に示します。

図2-49　［一括セットアップ完了］画面（強制開始）

●［一括セットアップ失敗］画面（強制開始）

［一括セットアップ失敗］画面（強制開始）を次に示します。

図2-50　［一括セットアップ失敗］画面（強制開始）

一括セットアップ（強制開始）が失敗した場合，セットアップ情報ファイルとsnapshotログが自動で保存されます。

2.2.16　アンセットアップ要求

セットアップウィザードでセットアップ済みのシステムが存在する状態でセットアップウィザードを起動すると，［アンセットアップ要求］画面が表示されます。ここでは，セットアップ済みのシステムをアンセットアップするかどうかを決定します。

［アンセットアップ要求］画面では，操作の流れに従って次のように画面が遷移します。なお，［ようこそ］画面でアンセットアップ要求があったか，［一括セットアップ］画面でアンセットアップ要求があったかによって表示される画面が異なります。

図2-51　［アンセットアップ要求］画面での画面遷移

操作の流れ

［アンセットアップ要求］画面での操作の流れを次に示します。

システムをアンセットアップするかどうかを英字で入力します。

Enterキーを押します。
yを選択すると［アンセットアップ要求］画面（アンセットアップの実施確認）が表示されます。
nを選択するとセットアップウィザードを終了します。

［アンセットアップ要求］画面（アンセットアップの実施確認）で，セットアップ済みのシステムをすべてアンセットアップするかどうかを英字で入力します。

Enterキーを押します。
yを選択すると［アンセットアップ完了］画面が表示されます。
nを選択するとセットアップウィザードを終了します。

システムをセットアップするかどうかを数字で入力します（［ようこそ］画面の場合だけ）。

Enterキーを押します。
1を選択すると［セットアップ方法の選択］画面が表示されます。
9を選択すると［終了確認］画面が表示されます。

＜この項の構成＞

(1)　［アンセットアップ要求］画面

(2)　［アンセットアップ要求］画面（アンセットアップの実施確認）

(3)　［アンセットアップ完了］画面

(1)　［アンセットアップ要求］画面

［アンセットアップ要求］画面は，［一括セットアップ］画面で表示されるか，［ようこそ］画面で表示されるかによって異なります。それぞれの［アンセットアップ要求］画面を次に示します。

［アンセットアップ要求］画面（［ようこそ］画面）
［アンセットアップ要求］画面（［ようこそ］画面）を次に示します。

図2-52　［アンセットアップ要求］画面（［ようこそ］画面）

［アンセットアップ要求］画面（［一括セットアップ］画面）
［アンセットアップ要求］画面（［一括セットアップ］画面）を次に示します。

図2-53　［アンセットアップ要求］画面（［一括セットアップ］画面）

設定項目

［アンセットアップ要求］画面で設定する項目を次の表に示します。

表2-38　［アンセットアップ要求］画面で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
アンセットアップの実行 | システムをアンセットアップします。 | y | ［アンセットアップ要求］画面（アンセットアップの実施確認）
セットアップウィザードを終了します。 | n | －

（凡例）－：表示される画面がないことを示します。

(2)　［アンセットアップ要求］画面（アンセットアップの実施確認）

［アンセットアップ要求］画面でyを入力すると，［アンセットアップ要求］画面（アンセットアップの実施確認）が表示されます。

［アンセットアップ要求］画面（アンセットアップの実施確認）を次に示します。

図2-54　［アンセットアップ要求］画面（アンセットアップの実施確認）

設定項目

［アンセットアップ要求］画面（アンセットアップの実施確認）で設定する項目を次の表に示します。

表2-39　［アンセットアップ要求］画面（アンセットアップの実施確認）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
アンセットアップの実行 | システムをアンセットアップします。 | y | ［アンセットアップ完了］画面
セットアップウィザードを終了します。 | n | －

（凡例）－：表示される画面がないことを示します。

(3)　［アンセットアップ完了］画面

［アンセットアップ要求］画面（アンセットアップの実施確認）でyを入力すると，［アンセットアップ完了］画面が表示されます。

［アンセットアップ完了］画面は，［一括セットアップ］画面で表示されるか，［ようこそ］画面で表示されるかによって異なります。それぞれの［アンセットアップ完了］画面を次に示します。

［アンセットアップ完了］画面（［ようこそ］画面）
［アンセットアップ完了］画面（［ようこそ］画面）を次に示します。

図2-55　［アンセットアップ完了］画面（［ようこそ］画面）

設定項目

［アンセットアップ完了］画面（［ようこそ］画面）で設定する項目を次の表に示します。

表2-40　［アンセットアップ完了］画面（［ようこそ］画面）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップの実行 | システムをセットアップします。 | 1 | ［セットアップ方法の選択］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

［アンセットアップ完了］画面（［一括セットアップ］画面）
［アンセットアップ完了］画面（［一括セットアップ］画面）を次に示します。

図2-56　［アンセットアップ完了］画面（［一括セットアップ］画面）

アンセットアップが完了すると，［一括セットアップ］画面（通常開始）が表示されます。なお，アンセットアップでエラーが発生した場合は，セットアップウィザードを終了します。

2.2.17　セットアップウィザードで設定できる項目

セットアップウィザードで設定できる項目について，画面ごとに説明します。

＜この項の構成＞

(1)　［ようこそ］画面で設定できる項目

(2)　［セットアップ方法の選択］画面で設定できる項目

(3)　［運用管理ユーザの設定］画面で設定できる項目

(4)　［運用管理機能の設定］画面で設定できる項目

(5)　［J2EEサーバの起動ユーザの設定］画面で設定できる項目

(6)　［システム構成の選択］画面で設定できる項目

(7)　［システム環境の設定］画面で設定できる項目

(8)　［データベース接続環境の設定］画面で設定できる項目

(9)　［セットアップ情報］画面で設定できる項目

(10)　［終了確認］画面で設定できる項目

(11)　［一括セットアップ］画面で設定できる項目

(1)　［ようこそ］画面で設定できる項目

［ようこそ］画面で設定できる項目について次の表に示します。［ようこそ］画面については，「2.2.3　セットアップの開始」を参照してください。

表2-41　［ようこそ］画面で設定できる項目

設定項目
設定内容
デフォルト値

セットアップの実行
システムのセットアップを実施するかどうかを設定します。次のどちらかを指定します。

1：

システムをセットアップします。

9：

セットアップウィザードを終了します。

1

アンセットアップの実行
システムのアンセットアップを実施するかどうかを設定します。次のどちらかを指定します。

y：

システムをアンセットアップします。

n：

セットアップウィザードを終了します。

なし

(2)　［セットアップ方法の選択］画面で設定できる項目

［セットアップ方法の選択］画面で設定できる項目について次の表に示します。［セットアップ方法の選択］画面については，「2.2.4　セットアップ方法の選択」を参照してください。

表2-42　［セットアップ方法の選択］画面で設定できる項目

設定項目
設定内容
デフォルト値

セットアップ方法の選択
セットアップ方法を選択します。次のどれかを指定します。

1：

標準セットアップでシステムをセットアップします。

2：

カスタムセットアップでシステムをセットアップします。

9：

セットアップウィザードを終了します。

1

(3)　［運用管理ユーザの設定］画面で設定できる項目

［運用管理ユーザの設定］画面で設定できる項目について次の表に示します。［運用管理ユーザの設定］画面については，「2.2.5　運用管理ユーザの設定」を参照してください。

表2-43　［運用管理ユーザの設定］画面で設定できる項目

設定項目
設定内容
デフォルト値

運用管理ユーザアカウントのユーザIDの設定
Management Serverの管理ユーザアカウントのユーザIDが現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在設定されているユーザIDをManagement Serverの管理ユーザアカウントのユーザIDとして設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

運用管理ユーザアカウントのユーザID
Management Serverの管理ユーザアカウントのユーザIDを半角英数字，一部の半角特殊文字※，および半角スペース1文字以上で指定します。
admin

運用管理ユーザアカウントのパスワード
Management Serverの管理ユーザアカウントのパスワードを半角英数字，一部の半角特殊文字※，および半角スペース0文字以上で指定します。空文字も入力値となります。
なし

注※

入力できる半角特殊文字について次に示します。

! # $ & ' ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

(4)　［運用管理機能の設定］画面で設定できる項目

［運用管理機能の設定］画面で設定できる項目について次の表に示します。［運用管理機能の設定］画面については，「2.2.6　運用管理機能の設定」を参照してください。

表2-44　［運用管理機能の設定］画面で設定できる項目

設定項目
設定内容
デフォルト値

運用管理機能の設定
Management Serverの設定が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在の設定値をManagement Serverの設定値として設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

Management Server接続HTTPポート番号
Management Server接続HTTPポート番号を1-65535の整数値で指定します。
28080

Management Server終了要求受信ポート番号
Management Server終了要求受信ポート番号を1-65535の整数値で指定します。
28005

Management Server内部通信用ポート番号
Management Server内部通信用ポート番号を1-65535の整数値で指定します。
28009

運用管理エージェントのポート番号
運用管理エージェントのポート番号を1-65535の整数値で指定します。
20295

Management Server管理グループに設定するグループ※
Management Server管理グループに設定するグループを1文字以上で指定します。

AIXの場合
system

HP-UXの場合
sys

Linuxの場合
root

Solarisの場合
sys

注※

UNIXの場合だけ設定できます。

(5)　［J2EEサーバの起動ユーザの設定］画面で設定できる項目

［J2EEサーバの起動ユーザの設定］画面で設定できる項目について次の表に示します。［J2EEサーバの起動ユーザの設定］画面については，「2.2.7　J2EEサーバの起動ユーザの設定」を参照してください。

表2-45　［J2EEサーバの起動ユーザの設定］画面で設定できる項目

設定項目
設定内容
デフォルト値

J2EEサーバの起動ユーザの設定
Component Container管理者の設定が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在の設定値をComponent Container管理者の設定値として設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

Component Container管理者
Component Container管理者を1文字以上で指定します。
root

Component Container管理者グループ
Component Container管理者グループを1文字以上で指定します。

AIXの場合
system

HP-UXの場合
sys

Linuxの場合
root

Solarisの場合
sys

(6)　［システム構成の選択］画面で設定できる項目

［システム構成の選択］画面で設定できる項目について次の表に示します。［システム構成の選択］画面については，「2.2.8　システム構成の選択」を参照してください。

表2-46　［システム構成の選択］画面で設定できる項目

設定項目
設定内容
デフォルト値

システム構成の選択（システム構成の確認）
システム構成が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在設定されている構成をシステム構成として設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

システム構成の選択
システム構成を選択します。次のどちらかを指定します。

1：

WebサーバとJ2EEサーバを配置するシステム構成を選択します。

2：

Webサーバ機能を持つJ2EEサーバだけを配置するシステム構成を選択します。

1

(7)　［システム環境の設定］画面で設定できる項目

［システム環境の設定］画面で設定できる項目について次の表に示します。［システム環境の設定］画面については，「2.2.9　システム環境の設定」を参照してください。

表2-47　［システム環境の設定］画面で設定できる項目

設定項目
設定内容
デフォルト値

システム環境の設定（システム環境の確認）
システム環境が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在設定されている環境をシステム環境として設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

Webシステム名
Webシステム名を半角英数字，記号（アンダースコア，ハイフン）32文字以内で指定します。
MyWebSystem

Webサーバの設定
Webサーバのポート番号※1
Webサーバのポート番号を1-65535の整数値で指定します。
80

J2EEサーバの設定
httpのポート番号※2
J2EEサーバのhttpのポート番号を1-65535の整数値で指定します。※3
80

管理用サーバのポート番号
J2EEサーバの管理用サーバのポート番号を1-65535の整数値で指定します。※3
8080

ajp13のポート番号※1
J2EEサーバのajp13のポート番号を1-65535の整数値で指定します。※3
8007

インプロセスのネーミングサービスのポート番号
J2EEサーバで使用するインプロセスのネーミングサービスのポート番号を1-65535の整数値で指定します。※3
900

RMIレジストリのポート番号
J2EEサーバのRMIレジストリのポート番号を1-65535の整数値で指定します。※3
23152

注※1

システム構成がWebサーバとJ2EEサーバを配置する構成（combined-tier）のときだけ設定できます。

注※2

システム構成がJ2EEサーバだけを配置する構成（j2ee-tier）のときだけ設定できます。

注※3　

［J2EEサーバの起動ユーザの設定］画面（設定内容変更）でComponent Container管理者を設定済みの場合，1024-65535の整数値で指定します。

(8)　［データベース接続環境の設定］画面で設定できる項目

［データベース接続環境の設定］画面で設定できる項目について次の表に示します。［データベース接続環境の設定］画面については，「2.2.10　データベース接続環境の設定」を参照してください。

表2-48　［データベース接続環境の設定］画面で設定できる項目

設定項目
設定内容
デフォルト値

データベースの接続設定
データベースの接続を設定するかどうかを指定します。次のどちらかを指定します。

y：

設定します。

n：

設定しません。

y

使用するデータベースの選択
使用するデータベースを設定します。次のどちらかを指定します。

1：

HiRDB（バージョン8以降）を使用します。

2：

Oracle（バージョン9i以降）を使用します。

1

データベース名（SID）※1
データベース名（SID）を1文字以上で指定します。
なし

データベースのホスト名
データベースのホスト名を1文字以上で指定します。
なし

データベースのポート番号
データベースのポート番号を1-65535の整数値で指定します。

HiRDBの場合
22200

Oracleの場合
1521

データベースのアクセスユーザ
データベースのアクセスユーザを0文字以上で指定します。
なし

アクセスユーザのパスワード
アクセスユーザのパスワードを0文字以上で指定します。
なし

JDBCドライバのパス
JDBCドライバのパスを1文字以上-OSの最大パス長※2以下の絶対パスで指定します。
なし

データベース接続環境の設定（データベース接続環境の確認）
データベース接続環境が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在設定されているデータベース接続環境をデータベース接続環境として設定します。

2：

設定内容を変更します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

1

注※1

使用するデータベースがOracleのときだけ設定できます。

注※2

「最大パス長」とは，OSで規定されているパス長の制限のことです。OSのパス長の制限については，ご使用のOSのドキュメントなどで確認してください。ただし，使用するOSがWindowsの場合，最大パス長は259です。

(9)　［セットアップ情報］画面で設定できる項目

［セットアップ情報］画面で設定できる項目について次の表に示します。［セットアップ情報］画面については，「2.2.11　セットアップ情報の確認」を参照してください。

表2-49　［セットアップ情報］画面で設定できる項目

設定項目
設定内容
デフォルト値

セットアップ情報の確認
セットアップ情報が現在の設定でよいかどうかを設定します。次のどれかを指定します。

1：

現在設定されているセットアップ情報でセットアップを開始します。

2：

セットアップ情報を再設定します。現在の設定は保持されます。

3：

セットアップ情報をファイルに保存します。

0：

前の画面に戻ります。

9：

セットアップウィザードを終了します。

なし

セットアップ情報（セットアップ情報の再設定）
セットアップ情報を再設定するかどうかを設定します。次のどちらかを指定します。

y：

セットアップ情報を再設定します。現在の設定は保持されます。

n：

セットアップ情報を再設定しないで，前の画面に戻ります。

なし

セットアップ情報（セットアップ情報ファイルの上書き）
セットアップ情報ファイルを上書きするかどうかを設定します。次のどちらかを指定します。

y：

セットアップ情報ファイルを上書きします。

n：

セットアップ情報ファイルを作成しないで，前の画面に戻ります。

なし

(10)　［終了確認］画面で設定できる項目

［終了確認］画面で設定できる項目について次の表に示します。［終了確認］画面については，「2.2.13　セットアップウィザードの終了」を参照してください。

表2-50　［終了確認］画面で設定できる項目

設定項目
設定内容
デフォルト値

セットアップの終了
セットアップを終了するかどうかを設定します。次のどちらかを指定します。

y：

セットアップウィザードを終了します。

n：

セットアップウィザードを終了しないで，前の画面に戻ります。

なし

(11)　［一括セットアップ］画面で設定できる項目

［一括セットアップ］画面で設定できる項目について次の表に示します。［一括セットアップ］画面については，「2.2.15　セットアップ情報ファイルを使用した一括セットアップ」を参照してください。

表2-51　［一括セットアップ］画面で設定できる項目

設定項目
設定内容
デフォルト値

セットアップの実行
システムのセットアップを実行するかどうかを設定します。次のどれかを指定します。

1：

システムをセットアップします。

2：

セットアップ情報を再設定します。セットアップ情報ファイルに保存されている設定は保持されます。

9：

セットアップウィザードを終了します。

なし

アンセットアップの実行
アンセットアップを実行するかどうかを設定します。次のどちらかを指定します。

y：

システムをアンセットアップします。

n：

セットアップウィザードを終了します。

なし

2.3　システムの運用

セットアップウィザードでセットアップしたシステムの次の運用項目について説明します。

セットアップウィザードでセットアップしたシステムの起動と停止

チューニング

パラメタチューニングしたシステムの複製

システムのアンセットアップ

なお，システムを運用する前に，運用管理エージェントおよびManagement Serverの自動起動の設定をする必要があります。運用管理エージェントの自動起動の設定については，「7.7.1(2)　運用管理エージェントの自動起動の設定」を参照してください。Management Serverの自動起動の設定については，「7.7.2(2)　Management Serverの自動起動の設定」を参照してください。

＜この節の構成＞

2.3.1　セットアップウィザードでセットアップしたシステムの起動と停止

2.3.2　チューニング

2.3.3　パラメタチューニングしたシステムの複製

2.3.4　システムのアンセットアップ

2.3.1　セットアップウィザードでセットアップしたシステムの起動と停止

セットアップウィザードでセットアップしたシステムの起動と停止には，Smart Composer機能のコマンドを使用します。

Smart Composer機能のコマンドを使用する場合，事前に環境変数の設定が必要です。環境変数の設定については，「7.3　環境変数の設定」を参照してください。

システムを起動する前に，運用管理エージェントおよびManagement Serverが起動していない場合は運用管理エージェントおよびManagement Serverを起動してください。運用管理エージェントの起動については，「7.7.1(1)　運用管理エージェントの起動」を参照してください。Management Serverの起動については，「7.7.2(1)　Management Serverの起動」を参照してください。

システムの起動方法と停止方法について説明します。

●システムの起動

cmx_start_targetコマンドを使用して，システムを起動します。cmx_start_targetコマンドのオプションに指定する値については表2-52を参照してください。

ここでは，cmx_start_targetコマンドのオプションに指定する値がすべてデフォルト値である場合の実行例を説明します。

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

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m localhost:28080 -u admin -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m localhost:28080 -u admin -s MyWebSystem -mode ALL

cmx_start_targetコマンドのオプションに指定する値について，次の表に示します。

表2-52　cmx_start_targetコマンドのオプションに指定する値

オプション | 指定する値 | 設定内容 | 参照先
-m | localhost:<ポート番号> | <ポート番号>にManagement Server接続HTTPポート番号を指定します。 | 「2.2.6　運用管理機能の設定」
-u | <管理ユーザID> | Management Serverの管理ユーザIDを指定します。 | 「2.2.5　運用管理ユーザの設定」
-p※1 | <管理パスワード> | Management Serverの管理ユーザIDのパスワードを指定します。
-s | <Webシステム名> | Webシステム名を指定します。 | 「2.2.9　システム環境の設定」
-mode | ALL※2 | － | －

（凡例）－：該当しません。

注※1

指定を省略できます。

注※2

必ずこの値を指定してください。

cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

●システムの停止

cmx_stop_targetコマンドを使用して，システムを停止します。cmx_stop_targetコマンドのオプションに指定する値については表2-52を参照してください。

ここでは，cmx_stop_targetコマンドのオプションに指定する値がすべてデフォルト値である場合の実行例を説明します。

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

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m localhost:28080 -u admin -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m localhost:28080 -u admin -s MyWebSystem -mode ALL

cmx_stop_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

2.3.2　チューニング

セットアップウィザードでセットアップしたシステムのチューニングには，Smart Composer機能または運用管理ポータルを使用します。

チューニングする項目については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」を参照してください。

Smart Composer機能を使用したシステムのチューニングの方法については，「8.10　チューニング」を参照してください。運用管理ポータルを使用したシステムのチューニングの方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

また，セットアップウィザードでは，setupwizardコマンドを使用すると，チューニングが完了したシステムを複製できます。複製できるチューニングの範囲を使用する構築方法ごとに示します。

Smart Composer機能を使用する場合
Smart Composer機能を使用する場合は，簡易構築定義ファイルで，論理サーバのパラメタの設定を変更できます。簡易構築定義ファイルでのチューニング範囲を次の表に示します。

表2-53　簡易構築定義ファイルでのチューニング範囲

チューニング項目
簡易構築定義ファイルのタグ
設定範囲

XMLスキーマのバージョン
<model-definition>
2.5以上

Webシステムの属性定義
Webシステムの定義
<web-system>
一つ

負荷分散機の定義
<load-balancer>
設定できません。

物理ティアの定義
物理ティアの定義
<tier>
一つ

物理ティアの種類
<tier-type>
combined-tier，j2ee-tier

J2EEサーバの数
<j2ee-server count>
1または指定なし

サービスユニットの定義
サービスユニットの定義
<unit>
一つ

ホスト名
<host-ref>
@myhost
（複数ホストは指定できません）

論理サーバの名称
<logical-server-name>
省略できません。

論理サーバの種類
<logical-server-type>
web-server，j2ee-server，performance-tracer

ホストの定義
ホスト名
<host-name>
@myhost
（複数ホストは指定できません）

運用管理エージェントのホスト名
<agent-host>
@myhost
（複数ホストは指定できません）

運用管理エージェントのポート番号
<agent-port>
セットアップ情報ファイルと同じ値（セットアップ情報ファイルの値が「20295」の場合は省略できます）

運用管理ポータルを使用する場合
運用管理ポータルを使用する場合，次の運用管理ポータルのアンカーで設定を変更できます。

「論理サーバの環境設定」（運用管理ポータルまたはmngsvrutil reloadコマンドを使用した，論理サーバの設定読み込みを含みます）

「論理サーバの起動／停止」

なお，複製元のシステムで複製できないチューニングを実施していると，複製元または複製先のシステムで，次の動作が発生して複製できない場合があります。

複製元のシステムで，簡易構築定義ファイルのエクスポートでエラーが発生します。

複製先のシステムが，複製できないチューニング情報を無視して複製されます。この場合，複製先のシステムには，複製元のシステムのセットアップ時の設定が適用されます。

複製できないチューニング項目については，「2.3.3(3)　複製できないチューニングが実施されている場合の動作」を参照してください。

システムの複製については，「2.3.3　パラメタチューニングしたシステムの複製」を参照してください。

2.3.3　パラメタチューニングしたシステムの複製

setupwizardコマンドを使用すると，Smart Composer機能または運用管理ポータルでチューニングが完了したシステムを複製できます。システムの複製を利用すると，構築済みのシステムと同じ構成で，パラメタのチューニング情報が反映されたシステムを簡単に複数作成できます。複製できるチューニングの範囲については，「2.3.2　チューニング」を参照してください。ここでは，setupwizardコマンドを使用したシステムの複製について説明します。setupwizardコマンドの詳細については，「3.2　setupwizardコマンドの詳細」を参照してください。

システムの複製では，次のファイルを使用します。

セットアップ情報ファイル
設定済みのシステムの情報が保存されているファイルです。ファイルの内容は，setupwizardコマンドで画面に表示できます。システムを複製する場合は，セットアップ処理完了（成功）後に自動的に出力されるファイル（setupwizard_success.dat）を使用します。setupwizard_success.datの出力先については，「3.3　セットアップウィザードで使用するファイル」を参照してください。また，ファイルの内容の表示方法については，「3.1(2)　セットアップ情報ファイルの内容表示」を参照してください。

簡易構築定義ファイル
チューニング情報（Webシステムの設定など）が保存されているファイルです。システムを複製する場合は，セットアップウィザードを使用したシステムで，setupwizardコマンドを使用してエクスポートしたファイルを使用します。簡易構築定義ファイルのファイル名は，エクスポート時に設定する名称になります。簡易構築定義ファイルの出力先については，「3.3　セットアップウィザードで使用するファイル」を参照してください。

システムの複製の流れを次の図に示します。

図2-57　システムの複製の流れ

図中の1.～4.について説明します。

1台目のマシンで，セットアップウィザードを使用して，新規にセットアップを実施します。
システムのセットアップ完了後に，セットアップ情報ファイルが出力されます。

1台目のマシンで，パラメタチューニングを実施します。
チューニングについては，「2.3.2　チューニング」を参照してください。

1台目のマシンで，setupwizardコマンドを使用して，簡易構築定義ファイルをエクスポートします。
簡易構築定義ファイルがエクスポートされます。エクスポートした簡易構築定義ファイルには，手順2.で実施したパラメタのチューニング情報が出力されます。簡易構築定義ファイルのエクスポートについては，「(1)　簡易構築定義ファイルのエクスポート」を参照してください。

2台目のマシンで，setupwizardコマンドを使用して，システムの複製を開始します。
手順1.で出力されたセットアップ情報ファイルと，手順3.でエクスポートした簡易構築定義ファイルを入力元にして，システムが複製されます。セットアップ情報ファイルおよび簡易構築定義ファイルは，あらかじめ2台目のマシンにコピーしておいてください。システムの複製については，「(2)　システムの複製」を参照してください。

注意

複製先のシステムの前提条件を次に示します。

システムの複製を実行するプラットフォームは，複製元と同じにしてください。複製先が，複製元と異なるプラットフォームの場合，システムの複製に失敗するときがあります。

セットアップ済みのシステムが存在する場合，セットアップウィザードは使用できません。セットアップした方法ごとに次の対処を実施してください。
セットアップウィザードでセットアップしたシステムが存在する場合は，セットアップウィザードを使用してアンセットアップしてください。
セットアップウィザード以外の方法でセットアップしたシステムが存在する場合は，アプリケーションサーバをアンインストールして，再度インストールしてください。

複製先のシステムでは，複製元のシステムで使用しているポート番号と同じポート番号は使用できません。

＜この項の構成＞

(1)　簡易構築定義ファイルのエクスポート

(2)　システムの複製

(3)　複製できないチューニングが実施されている場合の動作

(1)　簡易構築定義ファイルのエクスポート

簡易構築定義ファイルのエクスポートは，setupwizardコマンドで実行します。setupwizardコマンドの詳細については，「3.2　setupwizardコマンドの詳細」を参照してください。

注意

セットアップウィザード以外の方法でセットアップしていた場合，簡易構築定義ファイルをエクスポートできません。

簡易構築定義ファイルをエクスポートするシステムでは，Management Serverを起動しておいてください。

複製できないチューニングが実施されているシステムの場合，エクスポートできないときがあります。

(a)　簡易構築定義ファイルのエクスポートの実行

簡易構築定義ファイルのエクスポートの実行方法はOSによって異なります。OSごとに，簡易構築定義ファイルのエクスポートの実行方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -export -omd <簡易構築定義ファイル>

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -export -omd <簡易構築定義ファイル>

簡易構築定義ファイルをエクスポートすると，［簡易構築定義ファイルのエクスポート］画面が表示されます。

(b)　［簡易構築定義ファイルのエクスポート］画面

簡易構築定義ファイルのエクスポート実行後に表示される画面は，エクスポートの実行結果によって異なります。エクスポートの実行結果と表示される画面を次に示します。

エクスポートが成功した場合
［簡易構築定義ファイルのエクスポート完了］画面が表示されます。

図2-58　［簡易構築定義ファイルのエクスポート完了］画面

エクスポートが失敗した場合
エクスポートが失敗した要因によって，表示される画面が異なります。

Management Serverが起動していないとき
［簡易構築定義ファイルのエクスポート失敗］画面（Management Serverが起動していない場合）が表示されます。

図2-59　［簡易構築定義ファイルのエクスポート失敗］画面（Management Serverが起動していない場合）

エクスポートできない変更をしているとき
［簡易構築定義ファイルのエクスポート失敗］画面（エクスポートできない変更をしている場合）が表示されます。

図2-60　［簡易構築定義ファイルのエクスポート失敗］画面（エクスポートできない変更をしている場合）

(2)　システムの複製

システムの複製の操作の流れについて説明します。

操作の流れ

［一括セットアップ］画面（システムの複製）での操作を次に示します。

setupwizardコマンドに-fオプションおよび-mdオプションを指定して実行します。

システムを複製するかどうかを数字で入力します。

Enterキーを押します。
1を選択すると［セットアップの実行］画面が表示され，システムの複製が開始されます。
9を選択すると［終了確認］画面が表示されます。

注意

システムの複製時に使用する簡易構築定義ファイルは，setupwizardコマンドでエクスポートした簡易構築定義ファイルを使用してください。setupwizardコマンド以外の方法でエクスポートした簡易構築定義ファイルを使用した場合，システムの複製に失敗するときがあります。

複製元のシステムで複製できないチューニングが実施されている場合，システムを複製できないときがあります。

(a)　システムの複製の開始

システムの複製の開始方法はOSによって異なります。OSごとに，システムの複製方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -f <セットアップ情報ファイル> -md <簡易構築定義ファイル>

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -f <セットアップ情報ファイル> -md <簡易構築定義ファイル>

システムの複製を開始すると，［一括セットアップ］画面（システムの複製）が表示されます。

(b)　［一括セットアップ］画面（システムの複製）

［一括セットアップ］画面（システムの複製）を次に示します。

図2-61　［一括セットアップ］画面（システムの複製）

設定項目

［一括セットアップ］画面（システムの複製）で設定する項目を次の表に示します。

表2-54　［一括セットアップ］画面（システムの複製）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
セットアップの実行 | システムをセットアップします。 | 1 | ［セットアップの実行］画面
セットアップウィザードを終了します。 | 9 | ［終了確認］画面

参考

セットアップ済みのシステムがある場合は，［アンセットアップ要求］画面（［一括セットアップ］画面）が表示されます。なお，-forceオプションを指定して，システムの複製を強制開始している場合は，［一括セットアップ］画面（アンセットアップ実行中）が表示されます。

(3)　複製できないチューニングが実施されている場合の動作

複製元のシステムで，複製できないチューニングが実施されている場合，複製元または複製先のシステムで次の動作が発生して，複製できないときがあります。

複製元のシステムで，簡易構築定義ファイルのエクスポートでエラーが発生します。

複製先のシステムが，複製できないチューニング情報を無視して複製されます。この場合，複製先のシステムには，複製元のシステムのセットアップ時の設定が適用されます。

複製できないチューニング項目とシステムの動作を次の表に示します。

表2-55　複製できないチューニング項目とシステムの動作

項番
チューニング項目
システムの動作

1
Management Serverの設定
Management Serverの設定情報のうち，次の項目に変更があると，エクスポートでエラーが発生します。この場合，システムの複製は実施できません。

管理ユーザアカウントの設定の「管理ユーザID」および「パスワード」

ネットワークの設定の「Management Server接続HTTPポート番号」

ホストの定義の「運用管理エージェントのポート番号」

なお，上記以外のManagement Serverの設定情報を変更しても，エクスポートではエラーになりません。ただし，複製先のシステムには，複製元のシステムのセットアップ時の設定が適用されます。

2
Component Container管理者の設定
Component Container管理者の設定を変更しても，エクスポートではエラーになりません。ただし，複製先のシステムには，複製元のシステムのセットアップ時の設定が適用されます。

3
Webシステムの設定
Webシステムの設定情報のうち，次の項目以外に変更があると，エクスポートでエラーが発生します。この場合，システムの複製は実施できません。

Smart Composer機能の簡易構築定義ファイルを使用した，論理サーバのパラメタの設定

運用管理ポータルを使用した，「論理サーバの環境設定」および「論理サーバの起動／停止」の設定

4
データベースの接続設定
データベースの接続設定のうち，JDBCドライバの設定については，複製できます。JDBCドライバ以外の設定項目を変更しても，エクスポートではエラーになりません。ただし，複製先のシステムには，複製元のシステムのセットアップ時の設定が適用されます。

2.3.4　システムのアンセットアップ

setupwizardコマンドを使用するとシステムのアンセットアップができます。ここでは，setupwizardコマンドを使用したアンセットアップについて説明します。setupwizardコマンドの詳細については，「3.2　setupwizardコマンドの詳細」を参照してください。

注意

セットアップウィザードでセットアップしていないシステムはアンセットアップできません。

セットアップしたシステムに対して，セットアップウィザード以外の方法でシステムの設定変更やファイルの追加などを実施している場合，設定情報やファイルが削除されるときがあります。

UNIX環境の場合，セットアップウィザードでアンセットアップするときは，Webサーバのサーバ環境の削除について注意事項があります。詳細については，マニュアル「Hitachi Web Server」のhwsservereditユティリティを参照してください。

＜この項の構成＞

(1)　アンセットアップの開始

(2)　［アンセットアップ］画面（アンセットアップの実施決定）

(3)　［アンセットアップ］画面

(1)　アンセットアップの開始

アンセットアップには，アンセットアップするかどうかを確認してからアンセットアップを開始する方法（通常開始）と，アンセットアップするかどうかを確認しないで直ちにアンセットアップを開始する方法（強制開始）があります。それぞれについて説明します。

(a)　アンセットアップ（通常開始）

アンセットアップ（通常開始）の開始方法はOSによって異なります。OSごとのアンセットアップの開始方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -clean

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -clean

アンセットアップ（通常開始）を開始すると，［アンセットアップ］画面（アンセットアップの実施決定）が表示されます。

(b)　アンセットアップ（強制開始）

アンセットアップ（強制開始）の開始方法はOSによって異なります。OSごとのアンセットアップの開始方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -clean -force

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -clean -force

-forceを指定してアンセットアップ（強制開始）を開始すると，［アンセットアップ］画面が表示されます。

(2)　［アンセットアップ］画面（アンセットアップの実施決定）

アンセットアップを開始すると，［アンセットアップ］画面（アンセットアップの実施決定）が表示されます。ここでは，アンセットアップを実施するかどうかを決定します。

［アンセットアップ］画面（アンセットアップの実施決定）の図を次に示します。

図2-62　［アンセットアップ］画面（アンセットアップの実施決定）

(a)　操作の流れ

［アンセットアップ］画面（アンセットアップの実施決定）での操作を次に示します。

システムをアンセットアップするかどうかを英字で入力します。

Enterキーを押します。

(b)　設定項目

［アンセットアップ］画面（アンセットアップの実施決定）で設定する項目を次の表に示します。

表2-56　［アンセットアップ］画面（アンセットアップの実施決定）で設定する項目

設定項目 | 設定内容 | 入力値 | 設定後に表示される画面
アンセットアップの実行 | システムをアンセットアップします。 | y | ［アンセットアップ］画面
セットアップウィザードを終了します。 | n | －

（凡例）－：表示される画面がないことを示します。

(3)　［アンセットアップ］画面

アンセットアップ（通常開始）およびアンセットアップ（強制開始）の実行後，表示される画面はアンセットアップの実行結果によって異なります。アンセットアップの実行結果と表示される画面を次に示します。

アンセットアップが成功した場合
［アンセットアップ完了］画面が表示されます。

図2-63　［アンセットアップ完了］画面

アンセットアップが失敗した場合
アンセットアップが失敗した要因によって，表示される画面が異なります。

エラーが発生したとき
［アンセットアップ失敗］画面（エラーが発生した場合）が表示されます。

図2-64　［アンセットアップ失敗］画面（エラーが発生した場合）

この画面が表示されてアンセットアップに失敗した場合の対処については，「2.4　セットアップまたはアンセットアップ失敗時の対処」を参照してください。

アンセットアップできないシステムのとき
［アンセットアップ失敗］画面（アンセットアップできないシステムの場合）が表示されます。

図2-65　［アンセットアップ失敗］画面（アンセットアップできないシステムの場合）

この画面が表示されてアンセットアップに失敗した場合は，メッセージKEOS28039-Eを参照して，対処してください。

2.4　セットアップまたはアンセットアップ失敗時の対処

ここでは，セットアップまたはアンセットアップ実行時に障害が発生して，失敗した場合の対処について説明します。

＜この節の構成＞

(1)　snapshotログの収集

(2)　セットアップ実行中に障害が発生した場合の対処

(3)　アンセットアップ実行中に障害が発生した場合の対処

(1)　snapshotログの収集

セットアップまたはアンセットアップに失敗した場合，障害に対処するための資料として，snapshotログを収集する必要があります。snapshotログとは，システムの障害発生時の状態を出力したログのことで，システム全体の情報が一括収集されてZIP形式のログファイル（snapshot.zip）で出力されます。

snapshotログは，自動または任意のタイミングで収集できます。snapshotログの収集のタイミングを次の表に示します。

表2-57　snapshotログの収集のタイミング

分類 | 収集のタイミング
自動的に収集する※ | ［セットアップ失敗］画面でyを入力した場合
setupwizardコマンドに-forceオプションを指定して実行した場合※
任意のタイミングで収集する | snapshotlogコマンドを実行した場合

注※　アンセットアップ実行時には，snapshotログを自動的に収集できません。任意のタイミングで収集してください。

(a)　自動収集でのsnapshotログの格納先と内容

自動的に収集した場合の，snapshotログの格納先と内容を次に示します。

snapshotログの格納先

<セットアップウィザードのログの出力先>/snapshot.zip

snapshotログの内容

<Cosminexusのインストールディレクトリ>/manager/config/snapshotlog.confで示す範囲

<セットアップウィザードのログの出力先>/setupwizard<ファイル面数>.log

<セットアップウィザードのログの出力先>/maintenance/setupwizard<ファイル面数>.log

<Cosminexusのインストールディレクトリ>/manager/setup/config/

<Cosminexusのインストールディレクトリ>/manager/setup/tmp/

<セットアップウィザードのログの出力先>は，setup.cfgのsetup.log.dirで指定した出力先です。setup.cfgについては，「3.4　setup.cfg（セットアップウィザード用設定ファイル）」を参照してください。

(b)　snapshotlogコマンドによるsnapshotログの収集

snapshotログを任意のタイミングで収集する方法について説明します。任意のタイミングで収集する場合は，snapshotlogコマンドを使用します。OSごとに，snapshotlogコマンドの実行方法を次に示します。snapshotlogコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「snapshotlog（snapshotログの収集）」を参照してください。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥bin¥snapshotlog snapshot.zip

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/bin/snapshotlog snapshot.zip

なお，snapshotログをsnapshotlogコマンドで収集した場合には，次の資料も収集してください。

<セットアップウィザードのログの出力先>/setupwizard<ファイル面数>.log

<セットアップウィザードのログの出力先>/maintenance/setupwizard<ファイル面数>.log

<Cosminexusのインストールディレクトリ>/manager/setup/config/

<Cosminexusのインストールディレクトリ>/manager/setup/tmp/

<セットアップウィザードのログの出力先>は，setup.cfgのsetup.log.dirで指定した出力先です。setup.cfgについては，「3.4　setup.cfg（セットアップウィザード用設定ファイル）」を参照してください。

(2)　セットアップ実行中に障害が発生した場合の対処

セットアップ実行中に障害が発生した場合の対処の流れを次の図に示します。

図2-66　セットアップ実行中に障害が発生した場合の対処の流れ

図中の番号について説明します。

セットアップウィザードを起動してセットアップを開始します。セットアップウィザードの起動については，「2.2.2　セットアップウィザードの起動」を参照してください。

［セットアップ失敗］画面とログに出力されたエラーメッセージの詳細情報を参照して，エラーの原因を取り除きます。

障害発生時に，［セットアップ失敗］画面でyを選択していた場合は，snapshotログ（<セットアップウィザードのログの出力先>/snapshot.zip）を収集します。snapshotログの収集後，保守員に連絡してください。

障害発生時に，［セットアップ失敗］画面でnを選択していた場合は，snapshotlogコマンドを実行してsnapshotログを収集してください。収集方法については，「(1)(b)　snapshotlogコマンドによるsnapshotログの収集」を参照してください。snapshotログおよび資料を収集したあと，保守員に連絡してください。

(3)　アンセットアップ実行中に障害が発生した場合の対処

アンセットアップ実行中に障害が発生した場合の対処の流れを次の図に示します。

図2-67　アンセットアップ実行中に障害が発生した場合の対処の流れ

図中の番号について説明します。

setupwizardコマンドに-cleanを指定して，アンセットアップを開始します。アンセットアップの開始については，「2.3.4　システムのアンセットアップ」を参照してください。

［アンセットアップ失敗］画面とログに出力されたエラーメッセージの詳細情報を参照して，エラーの原因を取り除きます。

構築済みの環境を削除できる場合は，アプリケーションサーバのアンインストールを実行し，<Cosminexusのインストールディレクトリ>を削除したあとで，アプリケーションサーバを再インストールします。

構築済みの環境を削除できない場合は，snapshotlogコマンドを実行してsnapshotログを収集してください。収集方法については，「(1)(b)　snapshotlogコマンドによるsnapshotログの収集」を参照してください。snapshotログおよび資料を収集したあと，保守員に連絡してください。

3.　セットアップウィザードで使用するコマンドとファイル

セットアップウィザードでは，システムのセットアップや複製ができます。システムのセットアップや複製をする場合にはコマンドとファイルを使用します。この章では，セットアップウィザードで使用するコマンドやファイルについて説明します。

＜この章の構成＞

3.1　セットアップウィザードで使用するコマンド

3.2　setupwizardコマンドの詳細

3.3　セットアップウィザードで使用するファイル

3.4　setup.cfg（セットアップウィザード用設定ファイル）

3.1　セットアップウィザードで使用するコマンド

セットアップウィザードで使用するコマンドは，setupwizardコマンドです。

ここでは，setupwizardコマンドでできる操作について説明します。

＜この節の構成＞

(1)　setupwizardコマンドでできる操作

(2)　セットアップ情報ファイルの内容表示

(3)　setupwizardコマンドの使用方法の表示

(1)　setupwizardコマンドでできる操作

setupwizardコマンドでできる操作の一覧を次の表に示します。

表3-1　setupwizardコマンドでできる操作の一覧

操作
内容

セットアップウィザードの起動
セットアップウィザードを起動します。セットアップウィザードを使用してシステムを構築する場合に使用します。詳細については，「2.2.2　セットアップウィザードの起動」を参照してください。

セットアップ情報ファイルを使用した一括セットアップ
セットアップ情報ファイルから一括セットアップします。
セットアップ済みのシステムと同じシステムを構築する場合に使用します。詳細については，「2.2.15　セットアップ情報ファイルを使用した一括セットアップ」を参照してください。なお，チューニング済みのシステムをセットアップする場合は，一括セットアップではなく，システムの複製で実施します。

簡易構築定義ファイルのエクスポート
簡易構築定義ファイルをエクスポートします。簡易構築定義ファイルには，パラメタのチューニング情報が出力されます。エクスポートした簡易構築定義ファイルは，システムの複製時に使用します。詳細については，「2.3.3(1)　簡易構築定義ファイルのエクスポート」を参照してください。

システムの複製
セットアップ情報ファイルと，エクスポートした簡易構築定義ファイルから，システムを複製します。チューニング済みのシステムと同じシステムを構築する場合に使用します。詳細については，「2.3.3(2)　システムの複製」を参照してください。

アンセットアップ
セットアップ済みのシステムをアンセットアップします。セットアップウィザードで構築したシステムを削除する場合に使用します。詳細については，「2.3.4　システムのアンセットアップ」を参照してください。

セットアップ情報ファイルの内容表示
セットアップ情報ファイルの内容を表示します。セットアップ情報ファイルの内容を確認する場合に使用します。詳細については，「(2)　セットアップ情報ファイルの内容表示」を参照してください。

コマンドの使用方法の表示
setupwizardコマンドの使用方法を表示します。setupwizardコマンドのオプションの指定方法を知りたい場合に使用します。詳細については，「(3)　setupwizardコマンドの使用方法の表示」を参照してください。

(2)　セットアップ情報ファイルの内容表示

setupwizardコマンドに，-viewオプションおよび-fオプションを指定して実行すると，セットアップ情報ファイルの内容を表示できます。

セットアップ情報ファイルの内容表示の実行方法はOSによって異なります。OSごとに，セットアップ情報ファイルの内容表示の実行方法について説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -view -f <セットアップ情報ファイル>

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -view -f <セットアップ情報ファイル>

セットアップ情報ファイルの内容表示を実行すると，［セットアップ情報ファイルの内容表示］画面が表示されます。［セットアップ情報ファイルの内容表示］画面を次に示します。

図3-1　［セットアップ情報ファイルの内容表示］画面

セットアップ情報ファイルの内容表示に失敗すると，エラーメッセージが出力され，コマンドは終了します。出力されるエラーメッセージを次の表に示します。

表3-2　内容表示の実行時に出力されるエラーメッセージ

出力されるメッセージ | 内容
KEOS28029-E | -fオプションに指定したセットアップ情報ファイルが存在しない。
KEOS28030-E | -fオプションに指定したセットアップ情報ファイルが不正である。

(3)　setupwizardコマンドの使用方法の表示

setupwizardコマンドに-hオプションまたは-helpオプションを指定して実行すると，setupwizardコマンドの使用方法を表示できます。

実行方法はOSによって異なります。OSごとに，実行方法について説明します。ここでは，-hオプションを使用する例で説明します。

Windowsの場合

次のコマンドをコマンドプロンプトで実行します。

<Cosminexusのインストールディレクトリ>¥manager¥setup¥bin¥setupwizard -h

UNIXの場合

次のコマンドをコマンドプロンプトで実行します。

# /opt/Cosminexus/manager/setup/bin/setupwizard -h

setupwizardコマンドの使用方法の表示を実行すると，［setupwizardコマンドの形式の表示］画面が表示されます。［setupwizardコマンドの形式の表示］画面を次に示します。

図3-2　［setupwizardコマンドの形式の表示］画面

3.2　setupwizardコマンドの詳細

ここでは，setupwizardコマンドの形式，入力例および注意事項について説明します。

＜この節の構成＞

setupwizardコマンド（システムのセットアップ，アンセットアップと複製）

setupwizardコマンド（システムのセットアップ，アンセットアップと複製）

形式

セットアップウィザードの起動
setupwizard

セットアップ情報ファイルを使用した一括セットアップ
setupwizard -f <セットアップ情報ファイル> [-force]

簡易構築定義ファイルのエクスポート
setupwizard -export -omd <簡易構築定義ファイル>

システムの複製
setupwizard -f <セットアップ情報ファイル> -md <簡易構築定義ファイル> [-force]

アンセットアップ
setupwizard -clean [-force]

セットアップ情報ファイルの内容表示
setupwizard -view -f <セットアップ情報ファイル>

コマンドの使用方法の表示
setupwizard -h｜-help

機能

セットアップウィザードの起動
セットアップウィザードを起動します。

セットアップ情報ファイルを使用した一括セットアップ
-fオプションに指定したセットアップ情報ファイルの情報に従って，一括セットアップをします。-forceオプションを指定すると，セットアップ情報ファイルの内容を確認しないで一括セットアップをします。

簡易構築定義ファイルのエクスポート
簡易構築定義ファイルをエクスポートします。-omdオプションには，簡易構築定義ファイルの出力先とファイル名を指定します。エクスポートした簡易構築定義ファイルは，システムの複製時の入力ファイルとなります。

システムの複製
次のファイルの情報に従って，システムを複製します。

-fオプションに指定したセットアップ情報ファイル

-mdオプションに指定した簡易構築定義ファイル

-forceオプションを指定すると，セットアップ情報ファイルの内容を確認しないで，システムを複製します。
なお，次の情報は，セットアップ情報ファイルの内容ではなく，簡易構築定義ファイルの内容に従います。

Webシステムの設定

JDBCドライバの設定（データベースの設定を「する」を選択している場合）

アンセットアップ
セットアップウィザードでセットアップしたシステムのアンセットアップをします。-forceオプションを指定すると，アンセットアップをするかどうか確認しないでアンセットアップをします。

セットアップ情報ファイルの内容表示
-fオプションに指定したセットアップ情報ファイルの内容を表示します。

コマンドの使用方法の表示
setupwizardコマンドの使用方法を表示します。

引数

-f <セットアップ情報ファイル>

セットアップ情報ファイルのパスを指定します。

-export

簡易構築定義ファイルをエクスポートする場合に指定します。

-omd <簡易構築定義ファイル>

エクスポートする簡易構築定義ファイルのパスを指定します。

-md <簡易構築定義ファイル>

システムの複製で使用する簡易構築定義ファイルのパスを指定します。

-clean

システムのアンセットアップをする場合に指定します。

-force

次の操作を処理の実施確認をしないで実施するときに指定します。

セットアップ情報ファイルを使用した一括セットアップ

アンセットアップ

システムの複製

-view

セットアップ情報ファイルの内容を表示する場合に指定します。

-h｜-help

setupwizardコマンドの使用方法を表示する場合に指定します。

入力例

セットアップウィザードの起動
setupwizard

セットアップ情報ファイルを使用した一括セットアップ
setupwizard -f <Cosminexusのインストールディレクトリ>/manager/setup/config/setupwizard.dat -force

簡易構築定義ファイルのエクスポート
setupwizard -export -omd <任意のディレクトリ>/<簡易構築定義ファイルのファイル名>

システムの複製
setupwizard -f <Cosminexusのインストールディレクトリ>/manager/setup/config/setupwizard_success.dat -md <任意のディレクトリ>/<簡易構築定義ファイルのファイル名>

実施確認をしないアンセットアップ
setupwizard -clean -force

セットアップ情報ファイルの内容表示
setupwizard -view -f <Cosminexusのインストールディレクトリ>/manager/setup/config/setupwizard.dat

コマンドの使用方法の表示
setupwizard -h

戻り値

0：

正常終了しました。

1：

実行時エラーが発生しました。

2：

シンタックスエラーが発生しました。

注意事項

コマンドを実行できるユーザは次のとおりです。次に示すユーザ以外がコマンドを実行した場合，エラーとなります。

Windowsの場合

Windows Server 2008，Windows 7，またはWindows Vistaのときは，管理者特権のあるユーザがコマンドを実行できます。それ以外のWindowsのOSのときは，Administrator権限のあるユーザがコマンドを実行できます。

UNIXの場合

root権限のあるユーザがコマンドを実行できます。

-mdオプションに指定する簡易構築定義ファイルは，-exportオプションでエクスポートした簡易構築定義ファイルを指定してください。ほかの簡易構築定義ファイルを指定すると，システムの複製に失敗することがあります。

-exportオプションを指定してコマンドを実行する場合は，Management Serverが起動している必要があります。Management Serverが起動していない場合，コマンドの実行に失敗します。

コマンドを実行している間は，Ctrl+Cキーなどで外部から停止しないでください。停止した場合は再度セットアップウィザードを実行してください。再度セットアップウィザードを実行してもエラーが発生する場合は，OSを再起動してください。

3.3　セットアップウィザードで使用するファイル

セットアップウィザードで使用するファイルの一覧を，次の表に示します。

表3-3　セットアップウィザードで使用するファイルの一覧

分類
ファイル名称
概要
出力先

セットアップ情報リスト
setupwizardlist.txt
セットアップ処理完了（成功）後出力されます。
セットアップウィザードで構築した環境を確認するためのファイルです。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥setup¥config

UNIXの場合
/opt/Cosminexus/manager/setup/config

セットアップ情報ファイル
setupwizard.dat
［セットアップ情報］画面で「セットアップ情報を保存する」を選択した場合に出力されます。
一括セットアップで使用できます。

setupwizard_success.dat
セットアップ処理完了（成功）後に自動的に出力されます。
一括セットアップまたはシステムの複製で使用できます。

setupwizard_failed.dat
セットアップ処理完了（失敗）後に自動的に出力されます。
一括セットアップで使用できます。
ただし，このファイルを使用して一括セットアップをする場合は，セットアップ処理失敗の原因を取り除く必要があります。

ログファイル
setupwizard<ファイル面数>.log
セットアップウィザードのログが出力されます。
最大ファイルサイズ，最大ファイル面数などのログファイルの設定は，setup.cfg（セットアップウィザード用設定ファイル）で指定できます。
任意（setup.cfgのsetup.log.dirで指定した出力先）

簡易構築定義ファイル
cmxsetupwz.xml
セットアップ処理完了（成功）後出力されます。
セットアップウィザードで構築した環境の定義内容を確認するためのファイルです。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥setup¥config

UNIXの場合
/opt/Cosminexus/manager/setup/config

DB ConnectorのConnector属性ファイル
DBConnector_HiRDB_Type4_CP_cfg.xml
または
DBConnector_Oracle_CP_cfg.xml
セットアップ処理完了（成功）後出力されます。
セットアップウィザードで構築した環境で使用するDB Connectorの定義内容を確認するためのファイルです。

セットアップウィザード用設定ファイル
setup.cfg
セットアップウィザードのログファイルの出力先，最大ファイルサイズ，最大ファイル面数などを指定するファイルです。

3.4　setup.cfg（セットアップウィザード用設定ファイル）

ここでは，setup.cfg（セットアップウィザード用設定ファイル）の形式，格納先，機能，指定できるキー，および注意事項について説明します。

＜この節の構成＞

(1)　形式

(2)　ファイルの格納先

(3)　機能

(4)　指定できるキー

(5)　注意事項

(1)　形式

次のようにキーを指定します。

<キー名称>=<値>

指定方法

#で始まる行はコメントとみなされ，その行は無視されます。

値が存在しない行を定義した場合，その行は無視されます。

行頭および行末の空白文字や空行は無視されます。

キーと値の間のセパレータには「=」を使用します。「=」前後の空白は無視されます。

改行までが値になります。

同じキーを複数指定した場合は，最後のキーの値を有効とします。

1行は64KB未満とします。

ASCII文字だけ使用できます。

(2)　ファイルの格納先

ファイルの格納先をOSごとに説明します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥setup¥config

UNIXの場合
/opt/Cosminexus/manager/setup/config

(3)　機能

セットアップウィザードのログファイルの出力先，最大ファイルサイズ，最大ファイル面数などを指定します。

(4)　指定できるキー

指定できるキーとデフォルト値を次に示します。

キー名称
内容
デフォルト値

setup.log.dir
ログファイルの出力先ディレクトリを指定します。ファイルセパレータには「/」を使用してください。範囲外の値を指定した場合は，デフォルト値が仮定されます。
UNIXの場合，指定した出力先ディレクトリの上位のディレクトリが存在している必要があります。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥setup¥log

UNIXの場合
/opt/Cosminexus/manager/setup/log

setup.log.filenum
ログファイル面数を1～16の整数で指定します。範囲外の値を指定した場合は，デフォルト値が仮定されます。
4

setup.log.filesize
ログファイル一つ当たりの上限サイズ（単位：バイト）を，4096～2147483647の数値で指定します。範囲外の値を指定した場合は，デフォルト値が仮定されます。
262144

setup.maintenance.log.filenum
保守ログのファイル面数を1～16の整数で指定します。範囲外の値を指定した場合は，デフォルト値が仮定されます。
4

setup.maintenance.log.filesize
保守ログのファイル一つ当たりの上限サイズ（単位：バイト）を，4096～2147483647の整数で指定します。範囲外の値を指定した場合は，デフォルト値が仮定されます。
16777216

(5)　注意事項

セットアップウィザード実行時に，setup.cfgファイルの読み込みに失敗した場合は，メッセージKEOS28056-Eが出力され，セットアップウィザードは終了します。

4.　システムを構築・運用する前に

この章では，Smart Composer機能を使用したシステム構築の作業の流れについて説明します。また，システムを構成する要素，プロセス，製品などについても説明します。

＜この章の構成＞

4.1　J2EEアプリケーションを実行するシステムの構築に必要な作業の流れ

4.2　J2EEアプリケーションを実行するシステムを構成する要素

4.3　J2EEアプリケーションを実行するシステムで使用するマシンの種類

4.4　バッチアプリケーションを実行するシステムの構築に必要な作業の流れ

4.5　バッチアプリケーションを実行するシステムを構成する要素

4.6　バッチアプリケーションを実行するシステムで使用するマシンの種類

4.7　JP1/SC/DPMの利用

4.8　Management Serverが自動で設定する内容

4.1　J2EEアプリケーションを実行するシステムの構築に必要な作業の流れ

J2EEアプリケーションを実行するシステムの構築に必要な作業の流れについて説明します。また，システム構築に必要な作業が，どのマニュアルに記載されているかについても説明します。システム構築に必要な作業と，マニュアルとの対応を次の図に示します。なお，図中の参照先マニュアルについては，表4-1を参照してください。

図4-1　Smart Composer機能を使用したシステム構築に必要な作業とマニュアルとの対応（J2EEアプリケーションを実行するシステム）

図中の参照先マニュアルの一覧を次の表に示します。

表4-1　参照先マニュアルの一覧

項目 | 参照先マニュアル名
設計 | Cosminexus アプリケーションサーバ システム設計ガイド
構築運用 | Cosminexus アプリケーションサーバ システム構築・運用ガイド
機能解説※ | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)
Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)
Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)
Cosminexus アプリケーションサーバ 機能解説 拡張編
Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編

注※　記載内容については，各マニュアルの機能の分類，およびシステムの目的と機能の対応に関する説明を参照してください。

図中の1.～5.について説明します。

システムの設計
構築するシステムの構成や，使用する機能などをあらかじめ決定し，システムを動作させるために必要なリソースやメモリの見積もりを実施します。
ここでは，次の作業を実施します。

システム構成の検討
J2EEアプリケーションで使用する機能に応じて，機能の実現に必要なプロセスやサーバの配置，マシンの台数などを検討します。システム全体の構成は，システムの特性や要件を考慮して決定しておいてください。システムの構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。
決定したシステム構成を基に，Smart Composer機能でのシステムの構築時に使用する構成定義パターンを選定します。構成定義パターンの選定については，「5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定」を参照してください。

使用リソースおよびメモリの見積もり
システムを動作させるために必要なリソースや，メモリを見積もります。また，オプション製品を使用した環境での見積もりや，プロセス単位の見積もりなども実施します。リソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

運用・障害設計
システムの日常運用や保守，障害発生時のシステムの対応などを設計します。運用・障害設計については，「6.1　J2EEアプリケーションを実行するシステムの運用・障害設計」を参照してください。

インストールと初期設定
構築するシステムに合わせて，各サーバマシンにそれぞれ必要な製品をインストールします。Application Serverのインストール方法については，「7.2.1　インストール方法」を参照してください。そのほかの製品のインストール方法については，各製品のマニュアルを参照してください。

参考

アプリケーションサーバのオプション製品を使用する場合，各オプション製品の導入手順やインストールについては，次のマニュアルまたは個所を参照してください。

uCosminexus Client（マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「付録A　uCosminexus Client」参照）

Web Redirector（マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「付録D　Web Redirector」参照）

uCosminexus Operator（「付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）」参照）

製品のインストール後，次の作業を実施して初期設定をします。

環境変数の設定
使用する製品，機能に必要な環境変数を設定します。設定については，「7.3　環境変数の設定」を参照してください。

使用リソースの設定
手順1.の「使用リソースおよびメモリの見積もり」で見積もった値を設定します。設定方法については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

データベースを使用するための設定
必要に応じて，データベースに接続する場合の設定をします。データベースを使用しない場合は設定不要です。設定については，「7.5　データベースを使用するための設定」を参照してください。

Management Serverのセットアップと設定
Smart Composer機能で構築するシステムは，Management Serverを使用します。Management Serverを初めて使用するホストでは，Management Serverをセットアップしてください。セットアップと設定については，「7.6　Management Serverのセットアップと環境設定」を参照してください。

Server Plug-inの設定
必要に応じて，Server Plug-inを使用するための設定をします。リソースやJ2EEアプリケーションの設定でServer Plug-inを使用する場合には設定が必要です。Server Plug-inの設定については，「7.8　Server Plug-inの設定」を参照してください。

システムの構築
決定した構成に基づいて，システムを定義して構築します。また，構築するシステムで動作するリソースアダプタやJ2EEアプリケーションを設定します。システムを構築するために，次の作業を実施します。
なお，各作業の詳細については，「8.　J2EEアプリケーションを実行するシステムの構築」を参照してください。

システムの構成定義
Smart Composer機能のファイルを使用して，決定したシステム構成を定義します。

使用する機能を有効にするための設定
デフォルトの設定では，無効となる機能があります。使用する機能は，Smart Composer機能のファイルなどを使用して，有効にする設定をしてください。Smart Composer機能で使用できるアプリケーションサーバの機能については，「8.12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先」を参照してください。

システムの構築
Smart Composer機能のコマンドを使用して，システムを構築します。

リソースアダプタの設定
リソースを利用する場合，必要に応じてリソースと接続するリソースアダプタを設定します。リソースアダプタは，サーバ管理コマンドを使用して，プロパティを設定したり，インポートしたりします。
リソースアダプタの種類や設定手順については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。また，リソースとしてJavaBeansリソースを利用する場合の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.12　JavaBeansリソースの利用」を参照してください。

J2EEアプリケーションの設定
サーバ管理コマンドを使用して，J2EEアプリケーションをインポートします。J2EEアプリケーションのプロパティは，アプリケーション開発時にcosminexus.xmlで定義しておいてください。

ほかのプログラムと連携するための設定
JP1やクラスタソフトウェアと連携するために必要な設定をします。連携に必要な設定は，連携するプログラムによって異なります。必要な設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を参照してください。

システムの開始
Smart Composer機能のコマンドを使用して，システムを開始します。

チューニング
構築したシステムで，アプリケーションサーバのパフォーマンスをチューニングします。初期構築後，構築したシステム環境で，実際にJ2EEアプリケーションに負荷を掛けながら，設定したパラメタが適切かどうかを検証し，検証結果に基づいて設定を変更することで，パフォーマンスを向上させます。パラメタの設定変更は，Smart Composer機能のファイルおよびコマンドを使用します。チューニングについては，「8.10　チューニング」を参照してください。

システムの運用
構築したシステムを運用します。システムの日常運用，システムのメンテナンス，システム構成の変更などを，必要に応じて実施します。
システムの運用については「9.　J2EEアプリケーションを実行するシステムの運用」を参照してください。

参考

Smart Composer機能のコマンド以外に，運用管理コマンド（mngsvrutil）などを使用して運用できます。代替手段については，「付録E　代替手段で実行できる運用作業」を参照してください。

4.2　J2EEアプリケーションを実行するシステムを構成する要素

ここでは，Smart Composer機能で構築，運用するJ2EEアプリケーションを実行するシステムの概要や，システムを構成する要素について説明します。

Smart Composer機能で構築，運用する場合，J2EEアプリケーションを実行するシステムは，次のマシンなどで構成されます。

負荷分散機

J2EEサーバなどが動作するアプリケーションサーバマシン

データベースが構築されているデータベースサーバマシン

アプリケーションサーバ全体を運用管理するための機能を集約したサーバである運用管理サーバマシン

J2EEアプリケーションを実行するシステムの概要を次の図に示します。

図4-2　J2EEアプリケーションを実行するシステムの概要

Smart Composer機能では，システム内のサーバやサービスユニットの構成をWebシステムという概念で管理します。Webシステムは，人事システムや給与システムなどの一つの業務システムに対応し，Management Serverが管理，運用する運用管理ドメイン内に複数配置できます。異なるWebシステム間でも，同じ負荷分散機や，同じアプリケーションサーバマシン（ホスト）を共有できます。異なるWebシステム間で同じ負荷分散機を共有する場合の設定については，「8.11.6(3)　異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成」を参照してください。また，同じアプリケーションサーバマシンを共有する場合の設定については，「8.11.6(2)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成」を参照してください。

運用管理ドメイン内では，Webシステムおよびアプリケーションサーバマシン（ホスト）をIDで識別して管理しています。このため，Webシステムおよびアプリケーションサーバマシン（ホスト）のIDは，運用管理ドメイン内で一意になるように設定してください。

参考

Smart Composer機能では，Management Serverを運用管理サーバマシンに配置する運用管理サーバモデルでシステムを構築します。ただし，JP1/SC/DPMを利用すると，Management Serverをアプリケーションサーバマシン（ホスト）ごとに配置するホスト単位管理モデルでもシステムを構築できます。JP1/SC/DPMを利用したシステムについては，「4.7　JP1/SC/DPMの利用」を参照してください。

また，Smart Composer機能では，Webシステム内のアプリケーションサーバマシンの集合や，サーバの集合を，それぞれ物理ティア，サービスユニットという論理的なまとまりで扱っています。各サーバは，Management Serverで論理サーバとして管理，運用されます。サービスユニット内に配置する論理サーバの構成は，物理ティアの種類によって決まります。

＜この節の構成＞

4.2.1　物理ティアとは

4.2.2　サービスユニットとは

4.2.3　プロセスの種類と論理サーバとの対応

4.2.1　物理ティアとは

同一のデプロイメント（プロセスの配置，J2EEアプリケーションやリソースアダプタのデプロイ，定義設定）を適用するサーバマシンの集合を物理ティアといいます。J2EEアプリケーションを実行するシステムで使用できる物理ティアには，combined-tier，http-tier，j2ee-tier，sfo-tier，ctm-tier，およびfree-tierの6種類があります。物理ティアの種類によって，サービスユニットに配置する論理サーバの構成が異なり，システムの構成定義が決まります。

Smart Composer機能で構築する場合，決定したシステム構成に合わせて，物理ティア（構成定義パターン）を選択する必要があります。システム構成と指定できる物理ティアの関係については，「5.　システム構成に合わせた構成定義パターンの選定」を参照してください。

●combined-tier

combined-tierは，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターンのことです。業務サービス用の物理ティアで，アプリケーションサーバマシンの中に，Webサーバ，J2EEサーバ，およびパフォーマンストレーサ（PRFデーモン）の三つの論理サーバを配置します。

combined-tierの概要を次の図に示します。

図4-3　combined-tierの概要

この図に示すように，combined-tierでは，WebサーバとJ2EEサーバを同じアプリケーションサーバマシンに配置します。シンプルな構成のため，日常のメンテナンスやシステムの拡張が容易です。

●http-tier

http-tierは，WebサーバとJ2EEサーバを別のサーバマシンに配置するパターンのことです。業務サービス用の物理ティアで，Webサーバ側のマシンの集合です。Webサーバマシンの中に，Webサーバ，およびパフォーマンストレーサ（PRFデーモン）の二つの論理サーバを配置します。http-tierは，WebサーバとJ2EEサーバを配置するマシンを分けたい場合に，j2ee-tierと組み合わせて利用します。

http-tierの概要を次の図に示します。

図4-4　http-tierの概要

この図に示すように，http-tierに属するWebサーバマシンにWebサーバを配置し，j2ee-tierに属するアプリケーションサーバマシンにJ2EEサーバを配置します。この場合，サービスユニットは，http-tierとj2ee-tierに属するサーバマシンに配置する論理サーバの組み合わせで構成されます。

●j2ee-tier

j2ee-tierは，WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン，およびインプロセスHTTPサーバを使用するパターンのことです。業務サービス用の物理ティアで，J2EEサーバ側のマシンの集合です。アプリケーションサーバマシンの中に，J2EEサーバ，およびパフォーマンストレーサ（PRFデーモン）の二つの論理サーバを配置します。

j2ee-tierは，http-tierと組み合わせて利用する場合と，j2ee-tierだけで利用する場合があります。

http-tierと組み合わせて利用する場合

Webサーバを使用してクライアントからのリクエストを受け付けたい場合は，http-tierと組み合わせて利用します。

http-tierと組み合わせて利用するj2ee-tierの概要を次の図に示します。

図4-5　j2ee-tierの概要（http-tierと組み合わせて利用する場合）

この図に示すように，http-tierに属するWebサーバマシンにWebサーバを配置し，j2ee-tierに属するアプリケーションサーバマシンにJ2EEサーバを配置します。この場合，サービスユニットは，http-tierとj2ee-tierに属するサーバマシンに配置する論理サーバの組み合わせで構成されます。

j2ee-tierだけで利用する場合

Webサーバを配置しないで，J2EEサーバでクライアントからのリクエストを受け付けたい場合は，インプロセスHTTPサーバを利用します。インプロセスHTTPサーバを利用する場合は，j2ee-tierを使用します。

j2ee-tierだけで利用するj2ee-tierの概要を次の図に示します。

図4-6　j2ee-tierの概要（j2ee-tierだけで利用する場合）

この図のように，j2ee-tierに属するアプリケーションサーバマシンにはJ2EEサーバを配置します。クライアントからのリクエストの受け付けには，J2EEサーバのプロセス内で提供されるWebサーバ機能であるインプロセスHTTPサーバを使用します。インプロセスHTTPサーバを使用する場合，負荷分散機は使用できません。インプロセスHTTPサーバについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「4.　インプロセスHTTPサーバ」を参照してください。

●sfo-tier

sfo-tierは，SFOサーバを使用するパターンのことです。メモリセッションフェイルオーバ用の物理ティアで，セッションフェイルオーバサーバマシンの中に，セッションフェイルオーバサーバ（SFOサーバ），およびパフォーマンストレーサ（PRFデーモン）の二つの論理サーバを配置します。sfo-tierは，メモリセッションフェイルオーバ機能を利用する場合に使用します。

sfo-tierの概要を次の図に示します。

図4-7　sfo-tierの概要

この図に示すように，sfo-tierには，セッション情報を管理するセッションフェイルオーバサーバ（SFOサーバ）が必要です。sfo-tierは，J2EEサーバなどを配置したほかの物理ティアと組み合わせて使用します。

メモリセッションフェイルオーバ機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「7.　メモリセッションフェイルオーバ機能」を参照してください。

●ctm-tier

ctm-tierは，CTMを使用するパターンのことです。CTM用の物理ティアで，次に示すマシンの中に，CTM関連の論理サーバや，J2EEサーバなどを配置します。

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

CTMドメインマネジャ，CTM，スマートエージェント，J2EEサーバ，およびパフォーマンストレーサ（PRFデーモン）の五つの論理サーバを配置します。

統合ネーミングスケジューラサーバマシン

CTMドメインマネジャ，CTM，スマートエージェント，およびパフォーマンストレーサ（PRFデーモン）の四つの論理サーバを配置します。

参考

CTM関連のプロセスには，リクエストを振り分けてスケジューリングするCTM，同じCTMドメイン内のCTMの情報を管理するCTMドメインマネジャ，異なるネットワークセグメントにあるCTMに情報を配布するスマートエージェントがあります。

Smart Composer機能の場合，CTMを使用したシステムは，統合ネーミングスケジューラサーバを使用した統合ネーミングスケジューラサーバモデルで構築することを前提としています。ctm-tierは，CTMによるスケジューリングを利用する場合に使用します。CTMによるスケジューリングについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

ctm-tierの概要を次の図に示します。

図4-8　ctm-tierの概要

この図に示すように，ctm-tierでは，CTM関連のプロセスおよびJ2EEサーバを配置するアプリケーションサーバと，グローバルCORBAネーミングサービスを独立したマシンに配置する統合ネーミングスケジューラサーバが必要になります。それぞれのサーバは，別のWebシステムに属します。アプリケーションサーバには，一つのCTMに対して，J2EEアプリケーションや環境設定などの構成が同じJ2EEサーバを複数配置できます。ctm-tierは，ほかの物理ティアとは別のWebシステムに属しているため，バックシステムとして単独で利用できます。

また，CTMにリクエストを送信できるクライアントは，EJBクライアントおよびWebクライアントです。WebクライアントのリクエストをCTMに送信するWebフロントシステムには，Smart Composer機能以外で構築したユーザ独自のシステムも使用できます。

●free-tier

ほかのどの物理ティアの構成にも当てはまらない構成です。ほかの物理ティアとは異なり，システムを構築する場合には使用しないで，運用管理ポータルなどで構築したシステムをほかの環境に移行する場合に使用します。運用管理ポータルなどを使用して構築したシステムの内容を簡易構築定義ファイルに出力する場合，ほかのどの物理ティアの構成にも当てはまらない構成が含まれていると，その構成がfree-tier構成として出力されます。

free-tier構成には，Webシステム名，およびサービスユニット名がありません。そのため，free-tier構成を含むシステムに対して，Smart Composer機能のコマンドでできる操作は，システムの構築，起動および停止です。そのほかの操作は，Smart Composer機能のコマンドでは実施できません。

参考

サーバの構成を限定しないfree-tier構成は，Smart Composer機能以外の方法で構築したシステムをエクスポートした時に出力されます。

4.2.2　サービスユニットとは

業務サービスを提供する，閉じた部分系などのサーバの集合をサービスユニットといいます。サービスユニットは，サーバの起動・停止，J2EEアプリケーションの入れ替え時の閉塞処理，スケールアウトなどの単位となります。

参考

サービスユニットを配置するサーバマシンには，構築済みのWebシステムなどで使用しているマシンを指定することもできます。

＜この項の構成＞

(1)　サービスユニットの種類と配置できるプロセス

(2)　サービスユニットの複数配置

(1)　サービスユニットの種類と配置できるプロセス

サービスユニットの種類には，サービスユニットを配置するサーバマシンが属する物理ティアによって，業務サービスを提供するものや，セッション情報を管理するものなどがあります。また，サービスユニットに配置するプロセスも，物理ティアによって異なります。サービスユニットの種類とサービスユニットに配置するプロセスを次の表に示します。

表4-2　サービスユニットの種類とサービスユニットに配置するプロセス

物理ティアの種類 | サービスユニットの種類 | サービスユニットに配置するプロセス | 1サービスユニットに配置できる数
combined-tier | 業務サービス用のサービスユニット | J2EEサーバ | 1
Webサーバ | 1
PRFデーモン | 1
ユーザサーバ | 0～n
http-tier※1 | 業務サービス用のサービスユニット | Webサーバ | 1
PRFデーモン | 1
ユーザサーバ | 0～n
j2ee-tier | 業務サービス用のサービスユニット | J2EEサーバ | 1
PRFデーモン | 1
ユーザサーバ | 0～n
sfo-tier | メモリセッションフェイルオーバ用のサービスユニット | SFOサーバ | 1
PRFデーモン | 1
ユーザサーバ | 0～n
ctm-tier | CTM用のサービスユニット | CTMドメインマネジャ | 1
CTM※2 | 1
スマートエージェント | 1
J2EEサーバ | 1～32
PRFデーモン | 1
ユーザサーバ | 0～n
統合ネーミングスケジューラサーバ用のサービスユニット | CTMドメインマネジャ | 1
CTM※2 | 1
スマートエージェント | 1
PRFデーモン | 1
ユーザサーバ | 0～n

（凡例）n：n個配置できます。配置できる個数に制限はありません。

注※1　http-tierはj2ee-tierと組み合わせて使用します。サービスユニットは，http-tierとj2ee-tierに属するサーバマシンに配置するサーバの組み合わせで構成されます。

注※2　CTMは，CTMデーモン，CTMレギュレータおよびグローバルCORBAネーミングサービスから構成されるプロセス群です。

なお，システム構成ごとに配置するプロセスについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

(2)　サービスユニットの複数配置

サービスユニットは，1台のサーバマシンに複数配置できます。サーバマシン内のサーバは，サービスユニット単位で増やすことができます。また，異なるWebシステムのサービスユニットを，1台のサーバマシンに配置して，複数の業務を1台のマシンで運用することもできます。

1台のサーバマシンには，同じWebシステムのサービスユニットも，異なるWebシステムのサービスユニットも配置できます。なお，1台のサーバマシン内の異なるWebシステムで，1台の負荷分散機を共有する場合は，それぞれのWebシステムで使用する負荷分散機の仮想サーバを分ける必要があります。サーバマシン内に複数のサービスユニットを配置する場合の設定については，「8.11.6(2)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成」を参照してください。

注意

CTMを使用するパターンでは，同じCTMドメインのサービスユニットは，サーバマシン内に複数配置できません。

4.2.3　プロセスの種類と論理サーバとの対応

Management Serverでは，各プロセスを論理サーバとして管理，運用します。ここでは，サービスユニットに配置できるプロセスの種類と，Management Serverで管理する論理サーバとの対応について説明します。プロセスの種類と論理サーバとの対応を次の表に示します。

表4-3　プロセスの種類と論理サーバとの対応

プロセスの種類
説明
対応する論理サーバ

J2EEサーバ
J2EEアプリケーションの実行基盤となるプロセスです。
論理J2EEサーバ

Webサーバ※1
Webブラウザからのリクエスト受信，およびWebブラウザへのデータ送信に関連する処理を実行するプロセスです。
論理Webサーバ

PRFデーモン
（パフォーマンストレーサ）
アプリケーションサーバは，リクエストを処理するときにトレース情報をバッファへ出力します。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。
論理パフォーマンストレーサ

ユーザサーバ
ユーザが定義する任意のプロセスです。
論理ユーザサーバ

SFOサーバ
（セッションフェイルオーバサーバ）
メモリセッションフェイルオーバ機能を使用する場合に，J2EEサーバ間のセッション情報を管理するためのプロセスです。
論理SFOサーバ

CTMドメインマネジャ
同じCTMドメイン内のCTMデーモンの情報を管理するプロセスです。CTMデーモンを配置したホスト上に一つずつ配置します。CTMドメインは，複数のCTMデーモン間で，それぞれに登録された業務処理プログラムの情報やスケジュールキューの負荷情報を交換して，情報共有と負荷分散をする範囲のことで，ドメイン名称で識別されます。
論理CTMドメインマネジャ

CTMデーモン※2
クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。
論理CTM※2

CTMレギュレータ※2
CTMデーモンに集中するリクエストを，分散集約するためのプロセスです。

グローバルCORBAネーミングサービス※2
同じCTMドメイン内に含まれるホスト上の業務処理プログラムの情報を共有管理しているネーミングサービスです。

スマートエージェント
Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスを提供するプロセスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。
論理スマートエージェント

注※1　Management Serverを使用してシステムを構築する場合，使用するWebサーバはHitachi Web Serverです。

注※2　CTMデーモン，CTMレギュレータおよびグローバルCORBAネーミングサービスから構成されるプロセス群をCTMといいます。

参考

ユーザサーバについて

ユーザサーバは，論理ユーザサーバとして定義することで，Management Serverで運用・管理できるようになります。論理ユーザサーバを特定のサービスユニットに関連づけると，サービスユニットの起動／停止と同時に，ユーザサーバも起動したり，停止したりできます。複数のユーザサーバを，一つのサービスユニットに関連づけることができますが，一つのユーザサーバを，複数のサービスユニットに関連づけることはできません。

また，ユーザサーバは，アプリケーションサーバ上で動作します。アプリケーションサーバマシン以外にも，アプリケーションサーバをインストールしているマシンであれば，ユーザサーバを配置できます。その場合，これらのマシンには，運用管理エージェントも配置する必要があります。

論理ネーミングサービスについて

Management Serverが管理できる論理サーバには，表4-3以外に，論理ネーミングサービスがあります。論理ネーミングサービスは，CORBAネーミングサービスの機能を提供し，J2EEサーバで使用します。デフォルトでは，CORBAネーミングサービスをインプロセスで起動します。

インプロセスで起動する場合，およびCTMを使用する場合は，論理ネーミングサービスを定義する必要はありません。

4.3　J2EEアプリケーションを実行するシステムで使用するマシンの種類

ここでは，Smart Composer機能で構築するシステムに配置する各マシンについて説明します。

＜この節の構成＞

4.3.1　負荷分散機

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

4.3.3　データベースサーバマシン

4.3.4　運用管理サーバマシン

4.3.5　セッションフェイルオーバサーバマシン

4.3.6　統合ネーミングスケジューラサーバマシン

4.3.1　負荷分散機

負荷分散機は，ロードバランシング機能を持つ製品を配置するマシンです。負荷分散機を使用すると，一つの仮想IPアドレスで複数のサーバを管理するロードバランシング機能によって，トラフィックを効率的に分散し，処理性能を向上できます。負荷分散機は，Smart Composer機能から制御できます。Smart Composer機能では，負荷分散機としてBIG-IP（BIG-IP v9，BIG-IP v10.1，BIG-IP v10.2）またはACOS（AX2000，AX2500，BS320）が使用できます。

Smart Composer機能で構築したシステムは，負荷分散機のCookieスイッチング機能を使用して運用することもできます。Cookieスイッチング機能とは，Cookieを利用してセッションを維持する機能です。プロキシ経由などで要求元IPアドレスからクライアントが特定できない場合でも，同じクライアントからの一連のHTTPリクエストを同じサービスユニットに振り分けることができます。

参考

スイッチングモードについて

08-53以降では，BIG-IPのCookieスイッチング機能のうち，Smart Composer機能で対応しているスイッチングモードはインサートモードだけです。

ACOSの場合，サーバからのレスポンスに対してACOSがcookieを設定します。設定するcookieの形式は次のとおりです。
Set-Cookie:<cookie名>-<仮想ポート>=<実サーバIPアドレス>_<実ポート>

また，Smart Composer機能で構築したシステムでは，異なるWebシステム間や，異なる運用管理ドメインの同じWebシステム間で同じ負荷分散機を共有したり，一つのWebシステム内で負荷分散機を冗長化構成で配置したりできます。

注意

インプロセスHTTPサーバ機能を使用するパターン（j2ee-tier），およびfree-tierの場合，負荷分散機を配置できません。

＜この項の構成＞

(1)　負荷分散機の制御方法

(2)　Webシステム間での負荷分散機の共有

(3)　負荷分散機の冗長化

(1)　負荷分散機の制御方法

アプリケーションサーバから負荷分散機を制御するには，sshコマンドを使用します。この場合，lb.properties（負荷分散機プロパティファイル）で，負荷分散機への接続情報を設定します。設定方法については，「8.3　アプリケーションサーバから負荷分散機を制御するための設定」を参照してください。また，lb.properties（負荷分散機定義プロパティファイル）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.5　lb.properties（負荷分散機定義プロパティファイル）」を参照してください。

(2)　Webシステム間での負荷分散機の共有

Smart Composer機能で構築するWebシステムでは，異なるWebシステム間で，同じ（1台の）負荷分散機を共有できます。なお，1台のサーバマシン内の異なるWebシステムで，1台の負荷分散機を共有する場合は，それぞれのWebシステムで使用する負荷分散機の仮想サーバを分ける必要があります。負荷分散機を共有する場合の設定については，「8.11.6(3)　異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成」を参照してください。

また，JP1/SC/DPMを利用して構築するホスト単位管理モデルの場合，異なる運用管理ドメイン（サーバマシン）の同じWebシステム間でも，同じ（1台の）負荷分散機を共有できます。JP1/SC/DPMを利用したシステムについては，「4.7　JP1/SC/DPMの利用」を参照してください。

(3)　負荷分散機の冗長化

Smart Composer機能で構築するWebシステムでは，一つのWebシステム内に，負荷分散機を冗長化構成（アクティブ・スタンバイ構成）で配置できます。配置できる負荷分散機の台数は，2台です。負荷分散機を冗長化構成で配置すると，実行系（アクティブ）の負荷分散機で障害が発生した場合に，リクエストの振り分け処理が自動的に待機系（スタンバイ）の負荷分散機に切り替わって，業務を続行できます。負荷分散機を冗長化する場合の設定については，「8.11.6(1)　負荷分散機を冗長化する場合の簡易構築定義ファイルの作成」を参照してください。

参考

既存のWebシステムの負荷分散機を冗長化構成に変更したい場合は，既存のWebシステムを削除してから，負荷分散機を冗長化したWebシステムを再構築してください。

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

アプリケーションサーバを配置したマシンをアプリケーションサーバマシンといいます。アプリケーションサーバマシン上では，J2EEサーバなどが動作します。Smart Composer機能を使用するシステム構成では，アプリケーションサーバマシンはクラスタ構成になっており，それぞれをサービスユニットという単位で扱います。

アプリケーションサーバマシンに必要なプロセスと，インストールする製品は，システム構成によって異なります。アプリケーションサーバマシンに必要なプロセスと，インストールする製品については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

参考

JP1/SC/DPMを使用して，OSやアプリケーションの一括インストールをする場合，アプリケーションサーバマシンには，JP1/SC/DPMをインストールする必要があります。JP1/SC/DPMでは，プロセスとしてクライアントサービス for DPMが動作します。JP1/SC/DPMを利用するシステムについては，「4.7　JP1/SC/DPMの利用」を参照してください。

4.3.3　データベースサーバマシン

データベースが構築されているマシンをデータベースサーバマシンといいます。使用できるデータベースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.3　接続できるデータベース」を参照してください。

4.3.4　運用管理サーバマシン

Management Serverを配置したマシンを，運用管理サーバマシンといいます。運用管理サーバとは，すべてのサービスユニットを運用管理するための機能を集約したサーバで，Management Serverで運用管理します。運用管理ドメイン（Management Serverが管理する論理サーバの集合）内の各ホストに配置されている運用管理エージェントに対して，管理操作を指示します。運用管理サーバマシンに必要なプロセスと，インストールする製品については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.9.1　運用管理サーバにManagement Serverを配置する構成」を参照してください。

4.3.5　セッションフェイルオーバサーバマシン

SFOサーバを配置したマシンをセッションフェイルオーバサーバマシンといいます。セッションフェイルオーバサーバマシンに必要なプロセスと，インストールする製品については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の次の個所を参照してください。

3.10.2　SFOサーバがシステムに複数存在する構成（メモリセッションフェイルオーバ機能）

3.10.3　SFOサーバがシステムに一つだけ存在する構成（メモリセッションフェイルオーバ機能）

注意

セッションフェイルオーバサーバマシンではJP1/SC/DPMを利用できません。

4.3.6　統合ネーミングスケジューラサーバマシン

統合ネーミングスケジューラサーバを配置したマシンを統合ネーミングスケジューラサーバマシンといいます。統合ネーミングスケジューラサーバマシン上では，CTMドメインマネジャ，CTMなどが動作します。統合ネーミングスケジューラサーバマシンに必要なプロセスと，インストールする製品については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）」を参照してください。

Smart Composer機能で，CTMを使用するシステムを構築する場合は，統合ネーミングスケジューラサーバの使用を前提とした統合ネーミングスケジューラサーバモデルを使用します。統合ネーミングスケジューラサーバモデルは，グローバルCORBAネーミングサービスを独立したサーバマシン（ホスト）に配置する構成です。統合ネーミングスケジューラサーバモデルについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「3.3.2　プロセス配置の指針」を参照してください。

参考

JP1/SC/DPMを使用して，OSやアプリケーションの一括インストールをする場合，統合ネーミングスケジューラサーバマシンには，JP1/SC/DPMをインストールする必要があります。JP1/SC/DPMでは，プロセスとしてクライアントサービス for DPMが動作します。JP1/SC/DPMを利用するシステムについては，「4.7　JP1/SC/DPMの利用」を参照してください。

4.4　バッチアプリケーションを実行するシステムの構築に必要な作業の流れ

バッチアプリケーションを実行するシステムの構築に必要な作業の流れについて説明します。また，システム構築に必要な作業が，どのマニュアルに記載されているかについても説明します。システム構築に必要な作業と，マニュアルとの対応を次の図に示します。なお，図中の参照先マニュアルについては，表4-4を参照してください。

図4-9　Smart Composer機能を使用したシステム構築に必要な作業とマニュアルとの対応（バッチアプリケーションを実行するシステム）

図中の参照先マニュアルの一覧を次の表に示します。

表4-4　参照先マニュアルの一覧

項目 | 参照先マニュアル名
設計 | Cosminexus アプリケーションサーバ システム設計ガイド
構築運用 | Cosminexus アプリケーションサーバ システム構築・運用ガイド
機能解説※ | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)
Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)
Cosminexus アプリケーションサーバ 機能解説 拡張編
Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編

注※　記載内容については，各マニュアルの機能の分類，およびシステムの目的と機能の対応に関する説明を参照してください。

図中の1.～5.について説明します。

システムの設計
構築するシステムの構成や，使用する機能などをあらかじめ決定し，システムを動作させるために必要なリソースやメモリの見積もりを実施します。
ここでは，次の作業を実施します。

システム構成の検討
バッチアプリケーションで使用する機能に応じて，機能の実現に必要なプロセスやサーバの配置，マシンの台数などを検討します。システム全体の構成は，システムの特性や要件を考慮して決定しておいてください。システムの構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。
決定したシステム構成を基に，Smart Composer機能でのシステムの構築時に使用する構成定義パターンを選定します。構成定義パターンの選定については，「5.2　バッチアプリケーションを実行するシステムでの構成定義パターンの選定」を参照してください。

使用リソースおよびメモリの見積もり
システムを動作させるために必要なリソースや，メモリを見積もります。また，オプション製品を使用した環境での見積もりや，プロセス単位の見積もりなども実施します。リソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

運用・障害設計
システムの日常運用や保守，障害発生時のシステムの対応などを設計します。運用・障害設計については，「6.2　バッチアプリケーションを実行するシステムの運用・障害設計」を参照してください。

インストールと初期設定
構築するシステムに合わせて，各サーバマシンにそれぞれ必要な製品をインストールします。Application Serverのインストール方法については，「7.2.1　インストール方法」を参照してください。そのほかの製品のインストール方法については，各製品のマニュアルを参照してください。
製品のインストール後，次の作業を実施して初期設定をします。

環境変数の設定
使用する製品，機能に必要な環境変数を設定します。設定については，「7.3　環境変数の設定」を参照してください。

使用リソースの設定
手順1.の「使用リソースおよびメモリの見積もり」で見積もった値を設定します。設定方法については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

データベースを使用するための設定
必要に応じて，データベースに接続する場合の設定をします。データベースを使用しない場合は設定不要です。設定については，「7.5　データベースを使用するための設定」を参照してください。

Management Serverのセットアップと設定
Smart Composer機能で構築するシステムは，Management Serverを使用します。Management Serverを初めて使用するホストでは，Management Serverをセットアップしてください。セットアップと設定については，「7.6　Management Serverのセットアップと環境設定」を参照してください。

Server Plug-inの設定
必要に応じて，Server Plug-inを使用するための設定をします。リソースの設定でServer Plug-inを使用する場合には設定が必要です。Server Plug-inの設定については，「7.8　Server Plug-inの設定」を参照してください。

システムの構築
決定した構成に基づいて，システムを定義して構築します。また，構築するシステムで動作するリソースアダプタを設定します。システムを構築するために，次の作業を実施します。
なお，各作業の詳細については，「10.　バッチアプリケーションを実行するシステムの構築」を参照してください。

システムの構成定義
Smart Composer機能のファイルを使用して，決定したシステム構成を定義します。

使用する機能を有効にするための設定
バッチサーバの場合，必ず指定する項目があります。また，それ以外の項目については，デフォルトの設定で無効となる機能があります。使用する機能は，Smart Composer機能のファイルなどを使用して，有効にする設定をしてください。Smart Composer機能で使用できるアプリケーションサーバの機能については，「10.9　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先」を参照してください。

システムの構築
Smart Composer機能のコマンドを使用して，システムを構築します。

リソースアダプタの設定
リソースを利用する場合，必要に応じてリソースと接続するリソースアダプタを設定します。リソースアダプタは，サーバ管理コマンドを使用して，プロパティを設定したり，インポートしたりします。
リソースアダプタの種類や設定手順については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

ほかのプログラムと連携するための設定
JP1やクラスタソフトウェアと連携するために必要な設定をします。連携に必要な設定は，連携するプログラムによって異なります。必要な設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を参照してください。

システムの開始
Smart Composer機能のコマンドを使用して，システムを開始します。

チューニング
構築したシステムで，アプリケーションサーバのパフォーマンスをチューニングします。初期構築後，構築したシステム環境で，設定したパラメタが適切かどうかを検証し，検証結果に基づいて設定を変更することで，パフォーマンスを向上させます。パラメタの設定変更は，Smart Composer機能のファイルおよびコマンドを使用します。チューニングについては，「10.7　チューニング」を参照してください。

システムの運用
構築したシステムを運用します。システムの日常運用，システムのメンテナンス，システム構成の変更などを，必要に応じて実施します。
システムの運用については「11.　バッチアプリケーションを実行するシステムの運用」を参照してください。

参考

Smart Composer機能のコマンド以外に，運用管理コマンド（mngsvrutil）などを使用して運用できます。代替手段については，「付録E　代替手段で実行できる運用作業」を参照してください。

4.5　バッチアプリケーションを実行するシステムを構成する要素

ここでは，Smart Composer機能で構築，運用するバッチアプリケーションを実行するシステムの概要や，システムを構成する要素について説明します。

Smart Composer機能で構築，運用する場合，バッチアプリケーションを実行するシステムは，次のマシンなどで構成されます。

バッチサーバ，Management Serverなどが動作するアプリケーションサーバマシン

データベースが構築されているデータベースサーバマシン

バッチアプリケーションを実行するシステムの概要を次の図に示します。

図4-10　バッチアプリケーションを実行するシステムの概要

Smart Composer機能では，システム内のサーバやサービスユニットの構成をWebシステムという概念で管理します。Webシステムは一つの業務システムに対応し，Management Serverが管理，運用する運用管理ドメイン内に複数配置できます。バッチアプリケーションを実行するシステムの場合，一つの業務につき，一つのWebシステムを定義します。なお，Management Serverはアプリケーションサーバに配置します。異なるWebシステム間で同じアプリケーションサーバマシン（ホスト）を共有できます。同じアプリケーションサーバマシンを共有する場合の設定については，「10.8.3(1)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成」を参照してください。

運用管理ドメイン内では，Webシステムおよびアプリケーションサーバマシン（ホスト）をIDで識別して管理しています。このため，Webシステムおよびアプリケーションサーバマシン（ホスト）のIDは，運用管理ドメイン内で一意になるように設定してください。

また，Smart Composer機能では，Webシステム内のアプリケーションサーバマシンの集合や，サーバの集合を，それぞれ物理ティア，サービスユニットという論理的なまとまりで扱っています。各サーバは，Management Serverで論理サーバとして管理，運用されます。サービスユニット内に配置する論理サーバの構成は，物理ティアの種類によって決まります。

＜この節の構成＞

4.5.1　物理ティアとは

4.5.2　サービスユニットとは

4.5.3　プロセスの種類と論理サーバとの対応

4.5.1　物理ティアとは

同一のデプロイメント（プロセスの配置，リソースアダプタのデプロイ，定義設定）を適用するサーバマシンの集合を物理ティアといいます。バッチアプリケーションを実行するシステムで使用する物理ティアはj2ee-tier，ctm-tierおよびfree-tierです。物理ティアの種類によって，サービスユニットに配置する論理サーバの構成が異なり，システムの構成定義が決まります。

Smart Composer機能で構築する場合，決定したシステム構成に合わせて，物理ティア（構成定義パターン）を選択する必要があります。システム構成と指定できる物理ティアの関係については，「5.　システム構成に合わせた構成定義パターンの選定」を参照してください。

●j2ee-tier

j2ee-tierは，バッチサーバを配置するパターンのことです。アプリケーションサーバマシンの中に，バッチサーバ，およびパフォーマンストレーサ（PRFデーモン）の二つの論理サーバを配置します。

j2ee-tierの概要を次の図に示します。

図4-11　j2ee-tierの概要

図に示すように，j2ee-tierでは，バッチサーバをアプリケーションサーバマシンに配置します。シンプルな構成のため，日常のメンテナンスやシステムの拡張が容易です。

なお，一つのバッチサーバ上で実行できるバッチアプリケーションは一つです。複数のバッチアプリケーションを並行して実行したい場合は，次のように配置する必要があります。

サーバマシンを複数用意し，各サーバマシンにバッチサーバを一つ配置する

1台のサーバマシン内に複数のバッチサーバを配置する

●ctm-tier

ctm-tierは，CTMを使用するパターンのことです。アプリケーションサーバマシンの中に，CTMドメインマネジャ，CTM，スマートエージェント，バッチサーバ，およびパフォーマンストレーサ（PRFデーモン）の五つの論理サーバを配置します。ctm-tierは，CTMを使用したバッチアプリケーションのスケジューリング機能を利用する場合に使用します。CTMを使用したバッチアプリケーションのスケジューリング機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「4.　バッチアプリケーションのスケジューリング」を参照してください。

ctm-tierの概要を次の図に示します。

図4-12　ctm-tierの概要

この図に示すように，ctm-tierでは，CTM関連のプロセスおよびバッチサーバをアプリケーションサーバマシンに配置します。アプリケーションサーバマシンには，一つのCTMに対して，環境設定などの構成が同じバッチサーバを複数配置できます。

なお，一つのバッチサーバ上で実行できるバッチアプリケーションは一つです。CTMを使用すると，CTMでバッチアプリケーションの実行をスケジューリングするため，複数のバッチアプリケーションを並行して実行できます。

●free-tier

ほかのどの物理ティアの構成にも当てはまらない構成です。ほかの物理ティアとは異なり，システムを構築する場合には使用しないで，運用管理ポータルなどで構築したシステムをほかの環境に移行する場合に使用します。運用管理ポータルなどを使用して構築したシステムの内容を簡易構築定義ファイルに出力する場合，ほかのどの物理ティアの構成にも当てはまらない構成が含まれていると，その構成がfree-tier構成として出力されます。

free-tier構成には，Webシステム名，およびサービスユニット名がありません。そのため，free-tier構成を含むシステムに対して，Smart Composer機能のコマンドでできる操作は，システムの構築，起動および停止です。そのほかの操作は，Smart Composer機能のコマンドでは実施できません。

参考

サーバの構成を限定しないfree-tier構成は，Smart Composer機能以外の方法で構築したシステムをエクスポートした時に出力されます。

4.5.2　サービスユニットとは

業務サービスを提供する，閉じた部分系などのサーバの集合をサービスユニットといいます。サービスユニットは，サーバの起動・停止や，スケールアウトをするための単位となります。

参考

サービスユニットを配置するサーバマシンには，構築済みのWebシステムなどで使用しているマシンを指定することもできます。

＜この項の構成＞

(1)　サービスユニットの種類と配置できるプロセス

(2)　サービスユニットの複数配置

(1)　サービスユニットの種類と配置できるプロセス

サービスユニットは，サービスユニットを配置するサーバマシンが属する物理ティアによって異なります。また，サービスユニットに配置するプロセスも，物理ティアによって異なります。サービスユニットの種類とサービスユニットに配置するプロセスを次の表に示します。

表4-5　サービスユニットの種類とサービスユニットに配置するプロセス

物理ティアの種類 | サービスユニットの種類 | サービスユニットに配置するプロセス | 1サービスユニットに配置できる数
j2ee-tier | バッチサーバ用のサービスユニット | バッチサーバ | 1
PRFデーモン | 1
ユーザサーバ | 0～n
ctm-tier | CTM・バッチサーバ用のサービスユニット | CTMドメインマネジャ | 1
CTM※ | 1
スマートエージェント | 1
バッチサーバ | 1～32
PRFデーモン | 1
ユーザサーバ | 0～n

（凡例）n：n個配置できます。配置できる個数に制限はありません。

注※　CTMは，CTMデーモン，CTMレギュレータおよびグローバルCORBAネーミングサービスから構成されるプロセス群です。

なお，構築するシステムごとに配置するプロセスについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

(2)　サービスユニットの複数配置

サービスユニットは，1台のサーバマシンに複数配置できます。サーバマシン内のサーバは，サービスユニット単位で増やすことができます。サーバマシン内に複数のサービスユニットを配置する場合の設定については，「10.8.3(1)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成」を参照してください。

4.5.3　プロセスの種類と論理サーバとの対応

Management Serverでは，各プロセスを論理サーバとして管理，運用します。ここでは，サービスユニットに配置できるプロセスの種類と，Management Serverで管理できる論理サーバとの対応について説明します。プロセスの種類と論理サーバとの対応を次の表に示します。

表4-6　プロセスの種類と論理サーバとの対応

プロセスの種類 | プロセスの説明 | 対応する論理サーバ
バッチサーバ | バッチアプリケーションの実行基盤となるプロセスです。 | 論理J2EEサーバ
PRFデーモン（パフォーマンストレーサ） | アプリケーションサーバは，バッチアプリケーションの実行リクエストを処理するときにトレース情報をバッファへ出力します。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。 | 論理パフォーマンストレーサ
CTMドメインマネジャ | 同じCTMドメイン内のCTMデーモンの情報を管理するプロセスです。CTMデーモンを配置したホスト上に一つずつ配置します。CTMドメインは，複数のCTMデーモン間で，それぞれに登録されたスケジュールグループの情報やスケジュールキューの負荷情報を交換して，情報共有と負荷分散をする範囲のことです。ドメイン名称で識別されます。 | 論理CTMドメインマネジャ
CTMデーモン※ | バッチアプリケーションの実行リクエストを制御するスケジュールキューを管理するプロセスです。 | 論理CTM※
CTMレギュレータ※ | CTMデーモンに集中するバッチアプリケーションの実行リクエストを，分散集約するためのプロセスです。
グローバルCORBAネーミングサービス※ | 同じCTMドメイン内に含まれるホスト上のバッチアプリケーションの情報を共有管理しているネーミングサービスです。
スマートエージェント | Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスを提供するプロセスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。 | 論理スマートエージェント

注※　CTMデーモン，CTMレギュレータおよびグローバルCORBAネーミングサービスから構成されるプロセス群をCTMといいます。

参考

ユーザサーバについて

ユーザサーバは，論理ユーザサーバとして定義することで，Management Serverで運用・管理できるようになります。論理ユーザサーバを特定のサービスユニットに関連づけると，サービスユニットの起動／停止と同時に，ユーザサーバも起動したり，停止したりできます。複数のユーザサーバを，一つのサービスユニットに関連づけることができますが，一つのユーザサーバを，複数のサービスユニットに関連づけることはできません。

また，ユーザサーバは，アプリケーションサーバ上で動作します。アプリケーションサーバマシン以外にも，アプリケーションサーバをインストールしているマシンであれば，ユーザサーバを配置できます。その場合，これらのマシンには，運用管理エージェントも配置する必要があります。

4.6　バッチアプリケーションを実行するシステムで使用するマシンの種類

ここでは，Smart Composer機能で構築するシステムに配置する各マシンについて説明します。

＜この節の構成＞

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

4.6.2　データベースサーバマシン

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

アプリケーションサーバを配置したマシンをアプリケーションサーバマシンといいます。アプリケーションサーバマシン上では，バッチサーバが動作します。Smart Composer機能を使用するシステム構成では，アプリケーションサーバマシンはクラスタ構成になっており，それぞれをサービスユニットという単位で扱います。

アプリケーションサーバマシンに必要なプロセスと，インストールする製品は，システム構成によって異なります。アプリケーションサーバマシンに必要なプロセスと，インストールする製品については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

参考

JP1/SC/DPMを使用して，OSやアプリケーションの一括インストールをする場合，アプリケーションサーバマシンには，JP1/SC/DPMをインストールする必要があります。JP1/SC/DPMでは，プロセスとしてクライアントサービス for DPMが動作します。JP1/SC/DPMを利用するシステムについては，「4.7　JP1/SC/DPMの利用」を参照してください。

4.6.2　データベースサーバマシン

データベースが構築されているマシンをデータベースサーバマシンといいます。使用できるデータベースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.7.1　接続できるデータベース」を参照してください。

4.7　JP1/SC/DPMの利用

JP1/SC/DPMは，Smart Composer機能を使用したシステムの初期構築や，スケールアウトをする場合に利用できます。

JP1/SC/DPMでは，構築したシステムのディスクイメージ（OSとアプリケーション）を複製できます。Smart Composer機能でのシステムの構築が完了したあと，構築したサービスユニットまたは運用管理ドメインのディスクイメージをJP1/SC/DPMを使用して複製しておきます。スケールアウトが必要になった場合に，複製しておいたディスクイメージを基にして，追加するサービスユニットにOSやアプリケーションの一括インストールができるので，スケールアウトするサーバのセットアップが簡単になります。これによって，1台ずつインストールする場合と比較して，セットアップ時間を大幅に短縮できます。

ここでは，Smart Composer機能でJP1/SC/DPMを利用する場合に，システム構築で考慮する点について説明します。

＜この節の構成＞

(1)　JP1/SC/DPMを利用できる構成定義パターン

(2)　運用管理プロセス（Management Server）の配置

(3)　JP1/SC/DPM管理サーバマシンの配置

(4)　サーバマシンへのJP1/SC/DPMのインストール

(1)　JP1/SC/DPMを利用できる構成定義パターン

システムごとに，JP1/SC/DPMを利用できる構成定義パターンを示します。

J2EEアプリケーションを実行するシステムの場合

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）

インプロセスHTTPサーバを使用するパターン（j2ee-tier）

CTMを使用するパターン（ctm-tier）

JP1/SC/DPMを利用したスケールアウトおよびスケールインの手順については，「9.8　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン」を参照してください。

注意

SFOサーバを使用するパターン（sfo-tier）の場合，JP1/SC/DPMによるスケールアウトは，アプリケーションサーバでは利用できますが，セッションフェイルオーバサーバマシンでは利用できません。

バッチアプリケーションを実行するシステムの場合

バッチサーバを配置するパターン（j2ee-tier）

JP1/SC/DPMを利用したスケールアウトおよびスケールインの手順については，「11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン」を参照してください。

なお，JP1/SC/DPMを利用してスケールアウトできるOSは，WindowsおよびLinuxです。詳細については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。

(2)　運用管理プロセス（Management Server）の配置

JP1/SC/DPMを利用する場合，運用管理プロセス（Management Server）をどこに配置するかによって，次に示すモデルのシステムが構築できます。

運用管理サーバモデル
Management Serverを運用管理サーバマシンに配置する構成です。Management Serverが管理する運用管理ドメイン内のマシンを，一括して運用管理，監視するシステムを構築する場合に適しています。サービスユニット単位にスケールアウトできるので，システム内を容易に拡張できます。

ホスト単位管理モデル
Management Serverをアプリケーションサーバマシンに配置する構成です。この場合，運用管理サーバマシンは不要です。マシン（運用管理ドメイン）単位にスケールアウトできるので，同じ構成のWebシステムを持つマシンを複数台配置するシステムを構築する場合に適しています。スケールアウト時には，Management Serverも複製されます。

(3)　JP1/SC/DPM管理サーバマシンの配置

JP1/SC/DPMのうち，管理サーバfor DPMおよびWebサーバfor DPMがインストールされたマシンを，JP1/SC/DPM管理サーバマシンといいます。JP1/SC/DPM管理サーバマシンは必要に応じて用意してください。

JP1/SC/DPM管理サーバマシンにインストールする製品と，JP1/SC/DPM管理サーバマシン上で動作するプロセスを次の表に示します。

表4-7　JP1/SC/DPM管理サーバマシンにインストールする製品と動作するプロセス

インストールする製品 | 動作するプロセス
JP1/SC/DPM | 管理サーバ for DPM
Webサーバ for DPM

(4)　サーバマシンへのJP1/SC/DPMのインストール

JP1/SC/DPMを利用する場合，次のサーバマシンにJP1/SC/DPMをインストールする必要があります。JP1/SC/DPMのプロセスとして，クライアントサービス for DPMが動作します。

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

統合スケジューラサーバマシン※

注※　J2EEアプリケーションを実行するシステムで，CTMを使用するパターン（ctm-tier）の場合に配置するマシンです。

4.8　Management Serverが自動で設定する内容

Management Serverの機能を使用して，論理サーバのコンフィグレーション定義または環境設定で設定した内容は，自動的にCTMデーモンの起動コマンドのオプション，またはユーザ定義ファイルに反映されます。

＜この節の構成＞

4.8.1　Management Serverが自動で生成するユーザ定義ファイル

4.8.2　Management ServerがCTMドメインマネジャに自動で設定する内容

4.8.3　Management ServerがCTMに自動で設定する内容

4.8.4　Management ServerがSFOサーバに自動で設定する内容

4.8.5　Management ServerがJ2EEサーバに自動で設定する内容

4.8.6　Management Serverがバッチサーバに自動で設定する内容

4.8.7　Management ServerがWebサーバに自動で設定する内容

4.8.8　Management Serverが自動で設定する論理サーバの環境変数

4.8.1　Management Serverが自動で生成するユーザ定義ファイル

Management Serverの機能を使用して，論理サーバのコンフィグレーション定義または環境設定で設定した内容から生成されるユーザ定義ファイルについて，J2EEアプリケーションを実行するシステムの場合とバッチアプリケーションを実行するシステムの場合に分けて説明します。なお，ユーザ定義ファイルは，システムを構築する対象のホストに生成されます。

注意

システムの一貫性を保つため，細かい設定を変更する場合でも，構築時に使用したManagement Serverの機能（Smart Composer機能，運用管理ポータルなど）から実行するようにしてください。テキストエディタなどで個別にファイルを直接編集する場合には，スペルミスなどに十分注意してください。

●J2EEアプリケーションを実行するシステムの場合

論理サーバのコンフィグレーション定義または環境設定で設定した内容から生成されるユーザ定義ファイルを次の表に示します。

表4-8　論理サーバのコンフィグレーション定義または環境設定で設定した内容から生成されるユーザ定義ファイル（J2EEアプリケーションを実行するシステムの場合）

論理
サーバ
生成されるユーザ定義ファイル名
ファイルの概要
ファイルの格納先

SFOサーバ
usrconf.properties
SFOサーバを実行するために必要なJavaVMのシステムプロパティを指定するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名>¥

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名>/

mngagent.<実サーバ名>.properties
SFOサーバで運用監視するために必要な運用監視エージェントを設定するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

mevent.<実サーバ名>.properties
SFOサーバでManagementイベントを発行するために必要なプロパティを指定するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

manager.<論理サーバ名>.properties
SFOサーバでJP1イベントを発行するために必要なプロパティを指定するファイル。

J2EEサーバ
usrconf.cfg
J2EEサーバの起動オプションが定義されたファイル。
このファイルでJavaVMの起動オプションも定義します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名>¥

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名>/

usrconf.properties
J2EEサーバを実行するために必要なJavaVMのシステムプロパティを指定するファイル。

mngagent.<実サーバ名>.properties
J2EEサーバで運用監視するために必要な運用監視エージェントを設定するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

mevent.<実サーバ名>.properties
J2EEサーバでManagementイベントを発行するために必要なプロパティを指定するファイル。

manager.<論理サーバ名>.properties
J2EEサーバでJP1イベントを発行するために必要なプロパティを指定するファイル。

Webサーバ
httpsd.conf
Webサーバを稼働させるために必要な情報が定義されているファイル。

Windowsの場合
<Hitachi Web Serverのインストールディレクトリ>¥servers¥HWS_<サーバ名>¥conf¥または<Hitachi Web Serverのインストールディレクトリ>¥conf¥

UNIXの場合
/opt/hitachi/httpsd/servers/HWS_<サーバ名>/conf/または/opt/hitachi/httpsd/conf/

mod_jk.conf
Hitachi Web Server用のリダイレクタ定義（ログレベルなど）やURLマッピングを定義するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥servers¥<サーバ名>¥または<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥

UNIXの場合
/opt/Cosminexus/CC/web/redirector/servers/<サーバ名>/または/opt/Cosminexus/CC/web/redirector/

workers.properties
ワーカの定義およびワーカごとの各パラメタを定義するファイル。

●バッチアプリケーションを実行するシステムの場合

論理サーバのコンフィグレーション定義または環境設定で設定した内容から生成されるユーザ定義ファイルを次の表に示します。

表4-9　論理サーバのコンフィグレーション定義または環境設定で設定した内容から生成されるユーザ定義ファイル（バッチアプリケーションを実行するシステムの場合）

論理
サーバ
生成されるユーザ定義ファイル名
ファイルの概要
ファイルの格納先

バッチサーバ
usrconf.cfg
バッチサーバの起動オプションが定義されたファイル。
このファイルでJavaVMの起動オプションも定義します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名>¥

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名>/

usrconf.properties
バッチサーバを実行するために必要なJavaVMのシステムプロパティを指定するファイル。

mngagent.<実サーバ名>.properties
バッチサーバで運用監視するために必要な運用監視エージェントを設定するファイル。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

mevent.<実サーバ名>.properties
バッチサーバでManagementイベントを発行するために必要なプロパティを指定するファイル。

manager.<論理サーバ名>.properties
バッチサーバでJP1イベントを発行するために必要なプロパティを指定するファイル。

4.8.2　Management ServerがCTMドメインマネジャに自動で設定する内容

CTMデーモンの起動コマンド（ctmstart）の，CTMドメインマネジャの設定に関するオプションに，Management Serverが自動的に設定する内容を次の表に示します。

表4-10　Management Serverが自動的に設定する内容（CTMドメインマネジャの場合）

起動コマンド | オプション
ctmstart | -CTMMyHost <「論理サーバの構成定義」でCTMドメインマネジャを定義したホストのIPアドレス>
-CTMAutoForce

4.8.3　Management ServerがCTMに自動で設定する内容

CTMデーモンの起動コマンド（ctmstart）の，CTMの設定に関するオプションに，Management Serverが自動的に設定する内容を次の表に示します。

表4-11　Management Serverが自動的に設定する内容（CTMの場合）

起動コマンド | オプション
ctmstart | -CTMMyHost <「論理サーバの構成定義」でCTMを定義したホストのIPアドレス>
-CTMClientConnectCount<CTMレギュレータプロセス数＋OTMゲートウェイプロセス数>※

注※

CTMレギュレータプロセス数とOTMゲートウェイプロセス数の合計が256未満の場合には，-CTMClientConnectCountオプションの設定値は256になります。

実際のCTMレギュレータプロセス数とOTMゲートウェイプロセス数の合計より大きい値が設定されるため，CTM起動時に確保される共用メモリのサイズは，06-00から移行した場合は，デフォルトで303,808バイト増加します。また，06-50および06-51から移行した場合は，デフォルトで359,040バイト増加します。なお，06-70以降から移行した場合は，共用メモリのサイズに増加はありません。

4.8.4　Management ServerがSFOサーバに自動で設定する内容

SFOサーバに関連するユーザ定義ファイルに，Management Serverが自動的に設定する内容を次の表に示します。

表4-12　Management Serverが自動的に設定する内容（SFOサーバの場合）

ユーザ定義ファイル | 設定される内容
usrconf.properties | ejbserver.manager.agent.Agent.conf=<環境設定で作成されるmngagent.<実サーバ名>.propertiesファイルの位置>
ejbserver.manager.agent.Agent.enabled=true
ejbserver.ctm.enabled=false
ejbserver.instrumentation.enabled=true
webserver.connector.ajp13.max_threads=1
ejbserver.watch.defaultRequestQueue.enabled=false
ejbserver.watch.defaultRequestQueue.writefile.enabled=false
mngagent.<実サーバ名>.properties | mngagent.domain_name=<運用管理ドメイン名（内部名）>
mngagent.agent_name=<該当ノードの論理サーバ名>
mevent.<実サーバ名>.properties | manager.mevent.send.host=<Management Serverのホスト名またはIPアドレス>
manager.mevent.send.port=<Management ServerのHTTPポート番号>
manager.mevent.logical_server_name=<論理サーバ名>
manager.<論理サーバ名>.properties | manager.jp1event.logical_server_name=<論理サーバ名>
manager.jp1event.domain_name=<運用管理ドメイン名>

4.8.5　Management ServerがJ2EEサーバに自動で設定する内容

J2EEサーバに関連するユーザ定義ファイルに，Management Serverが自動的に設定する内容を次の表に示します。

表4-13　Management Serverが自動的に設定する内容（J2EEサーバの場合）

ユーザ定義ファイル | 設定される内容
usrconf.properties | ejbserver.manager.agent.Agent.conf=<環境設定で作成されるmngagent.<実サーバ名>.propertiesファイルの位置>
ejbserver.manager.agent.Agent.enabled=true
ejbserver.ctm.CTMMyHost=<「運用管理ドメインの構成定義」で定義したホスト名>
mngagent.<実サーバ名>.properties | mngagent.domain_name=<運用管理ドメイン名（内部名）>
mngagent.agent_name=<該当ノードの論理サーバ名>
mevent.<実サーバ名>.properties | manager.mevent.send.host=<Management Serverのホスト名またはIPアドレス>
manager.mevent.send.port=<Management ServerのHTTPポート番号>
manager.mevent.logical_server_name=<論理サーバ名>
manager.<論理サーバ名>.properties | manager.jp1event.logical_server_name=<論理サーバ名>
manager.jp1event.domain_name=<運用管理ドメイン名>

4.8.6　Management Serverがバッチサーバに自動で設定する内容

バッチサーバに関連するユーザ定義ファイルに，Management Serverが自動的に設定する内容を次の表に示します。

表4-14　Management Serverが自動的に設定する内容（バッチサーバの場合）

ユーザ定義ファイル | 設定される内容
usrconf.properties | ejbserver.manager.agent.Agent.conf=<環境設定で作成されるmngagent.<実サーバ名>.propertiesファイルの位置>
ejbserver.manager.agent.Agent.enabled=true
ejbserver.ctm.CTMMyHost=<「運用管理ドメインの構成定義」で定義したホスト名>
mngagent.<実サーバ名>.properties | mngagent.domain_name=<運用管理ドメイン名（内部名）>
mngagent.agent_name=<該当ノードの論理サーバ名>
mevent.<実サーバ名>.properties | manager.mevent.send.host=<Management Serverのホスト名またはIPアドレス>
manager.mevent.send.port=<Management ServerのHTTPポート番号>
manager.mevent.logical_server_name=<論理サーバ名>
manager.<論理サーバ名>.properties | manager.jp1event.logical_server_name=<論理サーバ名>
manager.jp1event.domain_name=<運用管理ドメイン名>

4.8.7　Management ServerがWebサーバに自動で設定する内容

Webサーバに関連するユーザ定義ファイルに，Management Serverが自動的に設定する内容を次の表に示します。

表4-15　Management Serverが自動的に設定する内容（Webサーバの場合）

ユーザ定義ファイル | 設定される内容
httpsd.conf※1 | Windowsの場合 | Include <Cosminexusのインストールディレクトリ>/CC/web/redirector/servers/<論理サーバ名>/mod_jk.conf
Include <Hitachi Web Serverのインストールディレクトリ>/servers/HWS_<論理Webサーバの実サーバ名>/httpsd_manager.conf※2
UNIXの場合 | Include /opt/Cosminexus/CC/web/redirector/servers/<論理サーバ名>/mod_jk.conf
Include <Hitachi Web Serverのインストールディレクトリ>/servers/HWS_<論理Webサーバの実サーバ名>/httpsd_manager.conf※2
mod_jk.conf | Windowsの場合 | LoadModule jk_module <Cosminexusのインストールディレクトリ>/CC/web/redirector/<mod_jkファイル名>※3
JkWorkersFile <Cosminexusのインストールディレクトリ>/CC/web/redirector/servers/<論理サーバ名>/workers.properties
UNIXの場合 | LoadModule jk_module /opt/Cosminexus/CC/web/redirector/<mod_jkファイル名>※3
JkWorkersFile /opt/Cosminexus/CC/web/redirector/servers/<論理サーバ名>/workers.properties

注※1

Webサーバの運用時には，httpsd.confファイルの内容を運用環境に合わせて適切に設定する必要があります。設定する内容や方法については，マニュアル「Hitachi Web Server」を参照してください。

注※2

簡易構築定義ファイルで論理Webサーバ（web-server）のAppendDirectivesパラメタ，または運用管理ポータルの［Webサーバの設定］画面で「項目ごとに設定します。」の「追加ディレクティブ」に値を指定した場合に設定されます。

注※3

<mod_jkファイル名>は，OSによって異なります。

4.8.8　Management Serverが自動で設定する論理サーバの環境変数

Management Serverが自動で設定する論理サーバの環境変数を，OSごとに次の表に示します。

表4-16　Management Serverが自動で設定する論理サーバの環境変数（Windowsの場合）

論理サーバ | 環境変数 | 設定値
論理パフォーマンストレーサ | Path | ${cosminexus.home}¥PRF¥bin;%{Path}
論理スマートエージェント | Path | ${cosminexus.home}¥TPB¥bin;%{Path}
TPDIR | ${cosminexus.home}¥TPB
VBROKER_ADM | ${cosminexus.home}¥TPB¥adm
論理ネーミングサービス | CLASSPATH | 設定されません。
Path | ${cosminexus.home}¥jdk¥bin;${cosminexus.home}¥TPB¥bin;%{Path}
TPDIR | ${cosminexus.home}¥TPB
TPJDIR | ${cosminexus.home}¥TPB
VBROKER_ADM | ${cosminexus.home}¥TPB¥adm
論理CTMドメインマネジャ | CTMDIR | ${cosminexus.home}¥CTM
Path | ${cosminexus.home}¥CTM¥bin;${cosminexus.home}¥TPB¥bin;%{Path}
TPDIR | ${cosminexus.home}¥TPB
VBROKER_ADM | ${cosminexus.home}¥TPB¥adm
論理CTM | CTMDIR | ${cosminexus.home}¥CTM
Path | ${cosminexus.home}¥CTM¥bin;${cosminexus.home}¥TPB¥bin;%{Path}
TPDIR | ${cosminexus.home}¥TPB
VBROKER_ADM | ${cosminexus.home}¥TPB¥adm
論理SFOサーバ | CSCCFJ_SERVER_HOME | ${cosminexus.home}¥CC
Path | ${cosminexus.home}¥CTM¥bin;%{Path}
論理J2EEサーバ | CSCCFJ_SERVER_HOME | ${cosminexus.home}¥CC
Path | ${cosminexus.home}¥CTM¥bin;%{Path}

表4-17　Management Serverが自動で設定する論理サーバの環境変数（UNIXの場合）

論理サーバ
環境変数
設定値

論理パフォーマンストレーサ
PATH
${cosminexus.home}/PRF/bin:%{PATH}

ライブラリパス※1
${cosminexus.home}/PRF/lib:%{ライブラリパス※1}

EXTSHM※2
ON

LDR_CNTRL※2
MAXDATA=0x40000000

NODISCLAIM※2
true

PSALLOC※2
early

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

AIXの場合
${cosminexus.home}/TPB/bin:/bin:${PATH}

HP-UX，Linux，およびSolarisの場合
${cosminexus.home}/TPB/bin:/bin:/usr/bin:${PATH}

TPDIR
${cosminexus.home}/TPB

VBROKER_ADM
${cosminexus.home}/TPB/adm

AIXTHREAD_COND_DEBUG※2
設定されません。

AIXTHREAD_MUTEX_DEBUG※2
設定されません。

AIXTHREAD_RWLOCK_DEBUG※2
設定されません。

AIXTHREAD_SCOPE※2
設定されません。

NODISCLAIM※2
true

PSALLOC※2
early

論理ネーミングサービス
CLASSPATH
設定されません。

PATH

AIXの場合
${cosminexus.home}/jdk/bin:${cosminexus.home}/TPB/bin:/bin:${PATH}

HP-UX，Linux，およびSolarisの場合
${cosminexus.home}/jdk/bin:${cosminexus.home}/TPB/bin:/bin:/usr/bin:${PATH}

TPDIR
${cosminexus.home}/TPB

VBROKER_ADM
${cosminexus.home}/TPB/adm

ライブラリパス※1
${cosminexus.home}/TPB/lib:${ライブラリパス※1}

AIXTHREAD_COND_DEBUG※2
OFF

AIXTHREAD_MUTEX_DEBUG※2
OFF

AIXTHREAD_RWLOCK_DEBUG※2
OFF

AIXTHREAD_SCOPE※2
S

NODISCLAIM※2
true

PSALLOC※2
early

論理CTMドメインマネジャ
CTMDIR
${cosminexus.home}/CTM

PATH
${cosminexus.home}/CTM/bin:${cosminexus.home}/TPB/bin:%{PATH}

TPDIR
${cosminexus.home}/TPB

VBROKER_ADM
${cosminexus.home}/TPB/adm

ライブラリパス※1
${cosminexus.home}/CTM/lib:${cosminexus.home}/TPB/lib:${ライブラリパス※1}

EXTSHM※2
ON

LDR_CNTRL※2
MAXDATA=0x40000000

PSALLOC※2
early

NODISCLAIM※2
true

論理CTM
CTMDIR
${cosminexus.home}/CTM

PATH
${cosminexus.home}/CTM/bin:${cosminexus.home}/TPB/bin:%{PATH}

TPDIR
${cosminexus.home}/TPB

VBROKER_ADM
${cosminexus.home}/TPB/adm

ライブラリパス※1
${cosminexus.home}/CTM/lib:${cosminexus.home}/TPB/lib:${ライブラリパス※1}

EXTSHM※2
ON

LDR_CNTRL※2
MAXDATA=0x40000000

PSALLOC※2
early

NODISCLAIM※2
true

論理SFOサーバ
CSCCFJ_SERVER_HOME
${cosminexus.home}/CC

ライブラリパス※1
/opt/DABroker/lib:${cosminexus.home}/manager/bin:${ライブラリパス※1}

AIXTHREAD_COND_DEBUG※2
OFF

AIXTHREAD_MUTEX_DEBUG※2
OFF

AIXTHREAD_RWLOCK_DEBUG※2
OFF

AIXTHREAD_SCOPE※2
S

EXTSHM※2
ON

NODISCLAIM※2
true

PSALLOC※2
early

論理J2EEサーバ
CSCCFJ_SERVER_HOME
${cosminexus.home}/CC

ライブラリパス※1
/opt/DABroker/lib:${cosminexus.home}/manager/bin:${ライブラリパス※1}

AIXTHREAD_COND_DEBUG※2
OFF

AIXTHREAD_MUTEX_DEBUG※2
OFF

AIXTHREAD_RWLOCK_DEBUG※2
OFF

AIXTHREAD_SCOPE※2
S

EXTSHM※2
ON

NODISCLAIM※2
true

PSALLOC※2
early

論理Webサーバ
PATH
${cosminexus.home}/PRF/bin

ライブラリパス※1
${cosminexus.home}/PRF/lib:${ライブラリパス※1}

LDR_CNTRL※2
MAXDATA=0x40000000

EXTSHM※2
ON

NODISCLAIM※2
true

PSALLOC※2
early

注※1　ライブラリパスに指定する環境変数名は，OSごとに異なります。

AIXの場合：LIBPATH

HP-UX，Linux，およびSolarisの場合：LD_LIBRARY_PATH

注※2　AIX固有の環境変数です。AIX以外のOSには該当しません。

5.　システム構成に合わせた構成定義パターンの選定

この章では，Smart Composer機能で使用する構成定義パターンを選定するための考え方について説明します。また，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」または「4.　システム構成の検討（バッチアプリケーション実行基盤）」で決定したシステム構成で構築するためには，どの構成定義パターンを選択すればよいかについても説明します。

＜この章の構成＞

5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定

5.2　バッチアプリケーションを実行するシステムでの構成定義パターンの選定

5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定

ここでは，J2EEアプリケーションを実行するシステムで，構築時に使用する構成定義パターンの選択方法と種類について説明します。

＜この節の構成＞

5.1.1　構成定義パターン選定の考え方

5.1.2　システム構成ごとに選択できる構成定義パターン

5.1.1　構成定義パターン選定の考え方

Smart Composer機能で構築するシステムでは，システムの構成定義を簡易構築定義ファイルで定義します。簡易構築定義ファイルでは，各マシンに配置するサーバの構成を物理ティア（構成定義パターン）で定義します。簡易構築定義ファイルでの定義については，「8.4　システムの構成定義」を参照してください。

ここでは，構成定義パターンの種類と，構成定義パターンを選定するための考え方について説明します。なお，システム構成は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照して，あらかじめ決定しておいてください。

＜この項の構成＞

(1)　構成定義パターンの種類

(2)　構成定義パターンの選定方法

(1)　構成定義パターンの種類

Smart Composer機能では，システム内のサーバやサービスユニットの構成をWebシステムという概念で管理します。また，Webシステム内のサーバマシンの集合や，サーバの集合を，それぞれ物理ティア，サービスユニットという論理的なまとまりで扱っています。Smart Composer機能で使用する概念の詳細については，「4.2　J2EEアプリケーションを実行するシステムを構成する要素」を参照してください。

構成定義パターンは，サーバマシンに配置するプロセスや，使用する機能によって異なります。サーバマシンに配置するプロセスは，Management Serverで論理サーバとして管理されます。プロセスと論理サーバの対応については，「4.2.3　プロセスの種類と論理サーバとの対応」を参照してください。

J2EEアプリケーションを実行するシステムでは，表5-1に示す構成定義パターンを定義できます。構成定義パターンとSmart Composer機能の物理ティアとの対応を次の表に示します。

表5-1　構成定義パターンとSmart Composer機能の物理ティアとの対応（J2EEアプリケーションを実行するシステム）

構成定義パターンの種類
配置できる論理サーバ
対応する物理ティア

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン

Webサーバ

J2EEサーバ

パフォーマンストレーサ

combined-tier

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン

Webサーバ

J2EEサーバ

パフォーマンストレーサ

http-tierとj2ee-tierとの組み合わせ

インプロセスHTTPサーバを使用するパターン

J2EEサーバ

パフォーマンストレーサ

j2ee-tier

SFOサーバを使用するパターン

SFOサーバ

パフォーマンストレーサ

sfo-tier

CTMを使用するパターン

CTMドメインマネジャ

CTM

スマートエージェント

J2EEサーバ

パフォーマンストレーサ

ctm-tier

各物理ティアの詳細については，「4.2.1　物理ティアとは」を参照してください。

(2)　構成定義パターンの選定方法

J2EEアプリケーションを実行するシステムの場合，構成定義パターンは，使用する機能，およびプロセスの配置から選択します。

●使用する機能から構成定義パターンを選択する

アプリケーションサーバの機能のうち，次の機能を使用する場合は，使用できる構成定義パターンが限定されます。

インプロセスHTTPサーバ

メモリセッションフェイルオーバ機能

CTMを使用したスケジューリング機能

これらの機能を使用する場合は，それぞれ次の構成定義パターンを選択してください。

インプロセスHTTPサーバを使用する場合

インプロセスHTTPサーバを使用するパターン（j2ee-tier）を選択してください。

Smart Composer機能を使用して構築する場合，インプロセスHTTPサーバを使用するパターンでは負荷分散機が使用できません。負荷分散機を使用する場合は，運用管理ポータルを使用して構築してください。

メモリセッションフェイルオーバ機能を使用する場合

SFOサーバを使用するパターン（sfo-tier）を選択してください。

SFOサーバを使用するパターンを構築する場合には，同じWebシステム内に，次のどれかの構成定義パターンで，J2EEサーバを配置するサービスユニットおよびマシンを定義してください。

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン

インプロセスHTTPサーバを使用するパターン

CTMを使用したスケジューリング機能を使用する場合

CTMを使用するパターン（ctm-tier）を選択してください。

この場合，統合ネーミングスケジューラサーバを使用した統合ネーミングスケジューラサーバモデルで構築することを前提としています。統合ネーミングスケジューラサーバモデルについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「3.3.2　プロセス配置の指針」を参照してください。

CTMを使用するパターンで構築する場合には，CTMにリクエストを送信するクライアントの定義が必要です。クライアントとして，Smart Composer機能や運用管理ポータルを使用して構築したWebフロントシステム以外にも，EJBクライアントやユーザが独自に定義するWebフロントシステムが利用できます。

●プロセスの配置から構成定義パターンを選択する

プロセスをどのサーバマシンに配置するかによって，構成定義パターンが限定されます。例えば，Webフロントシステムに必要なプロセスであるWebサーバは，J2EEサーバと同じサーバマシンにも，別のサーバマシンにも配置できます。

J2EEサーバと同じサーバマシンに配置する場合

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）を選択してください。

J2EEサーバと別のサーバマシンに配置する場合

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）を選択してください。

また，配置するプロセスは，使用する機能によっても限定されます。この場合は，使用する機能に合わせて構成定義パターンを選択してください。

5.1.2　システム構成ごとに選択できる構成定義パターン

ここでは，システム構成ごとに選択できる構成定義パターンについて説明します。ここで説明するシステム構成は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.　システム構成の検討（J2EEアプリケーション実行基盤）」で説明しているシステム構成に対応しています。

システム構成と構成定義パターンの対応を次の表に示します。

表5-2　システム構成と構成定義パターンの対応（J2EEアプリケーションを実行するシステム）

項番
システム構成
構成定義パターンごとの対応
配置できる論理サーバ※1
「システム設計ガイド」の参照個所※1

A
B
C
D
E

1
サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）
○
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.4.1

2
サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）
×
×
○
－
×

論理J2EEサーバ

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

3.4.2

3
Session BeanとEntity Beanをアクセスポイントに使用する構成
×
×
×
－
×

論理J2EEサーバ

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

3.4.3

4
CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成
×
×
×
－
○

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.4.4

5
Session BeanとEntity Beanを呼び出すサーバ間連携
×
×
×
－
×

論理J2EEサーバ

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

3.5.1

6
CTM経由でStateless Session Beanを呼び出すサーバ間連携
×
×
×
－
○

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.5.2

7
ローカルトランザクションを使用する場合の構成
○
○
○
－
×

論理Webサーバ

論理J2EEサーバ

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

3.6.1

8
グローバルトランザクションを使用する場合の構成
○
○
○
－
○

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.6.2

9
トランザクションコンテキストのプロパゲーションを使用する場合の構成
×
×
×
－
×

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.6.3

10
Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）
○
○
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.7.1

11
インプロセスHTTPサーバ使用時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）
×
×
×
－
×

論理J2EEサーバ

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

3.7.2

12
CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合）
×
×
×
－
×

論理J2EEサーバ

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

3.7.3

13
CTMを利用した負荷分散（Stateless Session Beanの場合）
×
×
×
－
○

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.7.4

14
Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus JMSプロバイダを使用する場合）
×
×
×
－
×

論理J2EEサーバ

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

3.8.1

15
Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）
×
×
×
－
×

論理J2EEサーバ

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

3.8.2

16
Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus RMを使用する場合）
×
×
×
－
×

論理J2EEサーバ

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

3.8.3

17
Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）
×
×
×
－
×

論理J2EEサーバ

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

3.8.4

18
運用管理サーバにManagement Serverを配置する構成
○
○
○
－
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.9.1

19
マシン単位にManagement Serverを配置する構成
○
○
○
－
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.9.2

20
コマンドで運用する場合の構成※2
×
×
×
－
×
－
3.9.3

21
データベースセッションフェイルオーバ機能を使用する構成
○
○
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.10.1

22
メモリセッションフェイルオーバ機能を使用する構成（SFOサーバがシステムに複数存在する場合）
△
△
×
○
×

論理Webサーバ

論理J2EEサーバ

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

論理SFOサーバ

3.10.2

23
メモリセッションフェイルオーバ機能を使用する構成（SFOサーバがシステムに一つだけ存在する場合）
△
△
×
○
×

論理Webサーバ

論理J2EEサーバ

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

論理SFOサーバ

3.10.3

24
アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.11.1

25
アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.11.2

26
運用管理サーバの実行系と待機系を1:1にする構成
○
○
○
－
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.11.3

27
アプリケーションサーバの実行系と待機系を相互スタンバイにする構成
○
○
○
－
×

論理Webサーバ

論理J2EEサーバ

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

3.11.4

28
リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.11.5

29
ホスト単位管理モデルの実行系と予備系をN：1にする構成
○
○
○
－
×

論理Webサーバ

論理J2EEサーバ

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

3.11.6

30
サーブレットとJSPに対するファイアウォールの配置
○
○
○
－
×

論理Webサーバ

論理J2EEサーバ

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

3.12.1

31
Session BeanとEntity Beanに対するファイアウォールの配置
×
×
×
－
×

論理J2EEサーバ

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

3.12.2

32
リソースマネジャに対するファイアウォールの配置
○
○
○
－
×

論理Webサーバ

論理J2EEサーバ

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

3.12.3

33
Webサーバ連携時のリバースプロキシの配置
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.13.1

34
インプロセスHTTPサーバ使用時のリバースプロキシの配置
×
×
×
－
×

論理J2EEサーバ

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

3.13.2

35
性能解析トレースファイルを出力するプロセスを配置する
○
○
○
○
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.14

36
JP1を使用して運用する場合の構成
○
○
○
－
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.15.1

37
TP1インバウンド連携機能を使用してOpenTP1のSUPからMessage-driven Beanを呼び出す場合の構成
×
×
×
－
×

論理J2EEサーバ

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

3.15.2

38
CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成
×
×
×
－
○

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

3.15.3

39
任意のプロセスを運用管理の対象にする
○
○
○
○
○

論理Webサーバ

論理J2EEサーバ

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

論理CTMドメインマネジャ

論理CTM

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

論理ユーザサーバ

3.16

40
Webサーバとアプリケーションサーバを異なるマシンに配置する構成
×
○
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.17.1

41
リダイレクタを利用して負荷分散する構成
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

3.17.2

42
CORBAネーミングサービスをアウトプロセスで起動する構成
×
×
×
－
×

論理Webサーバ

論理J2EEサーバ

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

論理ネーミングサービス

3.17.3

（凡例）

○：対応しています。

△：対応している構成定義パターンと組み合わせて使用します。

×：対応していません。

－：該当しません。

A：WebサーバとJ2EEサーバを同じサーバマシンに配置するパターンを示します。

B：WebサーバとJ2EEサーバを別のサーバマシンに配置するパターンを示します。

C：インプロセスHTTPサーバを使用するパターンを示します。

D：SFOサーバを使用するパターンを示します。

E：CTMを使用するパターンを示します。

注※1

「システム設計ガイド」の参照個所は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の参照先を示します。この参照個所で説明しているシステム構成図で，論理サーバをどのサーバマシンに配置するかを確認してください。

注※2

Management Serverを使用しないシステム構成のため，配置できる論理サーバはありません。このシステム構成は，Smart Composer機能でも運用管理ポータルでも構築できません。このシステム構成を構築する場合は，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「付録C　J2EEアプリケーションを実行するシステムの構築と削除」を参照してください。

参考

ここで説明しているコマンドで運用する場合の構成以外のシステム構成は，運用管理ポータルでも構築できます。運用管理ポータルでの構築方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.　J2EEアプリケーションを実行するシステムの構築と削除」を参照してください。

表5-2でどの構成定義パターンにも対応していないシステム構成は，Smart Composer機能で初期構築できません。ただし，Smart Composer機能で初期構築できないシステム構成でも，Smart Composer機能のfree-tierに対応している構成があります。free-tierについては，「4.2.1　物理ティアとは」を参照してください。Smart Composer機能で初期構築できないシステム構成は，運用管理ポータルを使用して構築してください。Smart Composer機能で初期構築できないシステム構成とfree-tierとの対応を次の表に示します。

表5-3　Smart Composer機能で初期構築できないシステム構成とfree-tierとの対応

項番 | 初期構築できないシステム構成 | free-tierとの対応
1 | Session BeanとEntity Beanをアクセスポイントに使用する構成 | ○
2 | Session BeanとEntity Beanを呼び出すサーバ間連携 | ○
3 | トランザクションコンテキストのプロパゲーションを使用する場合の構成 | ○
4 | インプロセスHTTPサーバ使用時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合） | ○
5 | CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合） | ○
6 | Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus JMSプロバイダを使用する場合） | ○
7 | Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合） | ○
8 | Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus RMを使用する場合） | ○
9 | Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合） | ○
10 | アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合） | ×
11 | アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合） | ×
12 | リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム） | ×
13 | Session BeanとEntity Beanに対するファイアウォールの配置 | ○
14 | Webサーバ連携時のリバースプロキシの配置 | ○
15 | インプロセスHTTPサーバ使用時のリバースプロキシの配置 | ○
16 | TP1インバウンド連携機能を使用してOpenTP1のSUPからMessage-driven Beanを呼び出す場合の構成 | ○
17 | リダイレクタを利用して負荷分散する構成 | ○
18 | CORBAネーミングサービスをアウトプロセスで起動する構成 | ○

（凡例）

○：対応しています。

×：対応していません。

5.2　バッチアプリケーションを実行するシステムでの構成定義パターンの選定

ここでは，バッチアプリケーションを実行するシステムで，構築時に使用する構成定義パターンの選択方法と種類について説明します。

＜この節の構成＞

5.2.1　構成定義パターン選定の考え方

5.2.2　システム構成ごとに選択できる構成定義パターン

5.2.1　構成定義パターン選定の考え方

Smart Composer機能を使用したシステムでは，システムの構成定義を簡易構築定義ファイルで定義します。簡易構築定義ファイルでは，各マシンに配置するサーバの構成を物理ティア（構成定義パターン）で定義します。簡易構築定義ファイルでの定義については，「10.2　システムの構成定義」を参照してください。

ここでは，構成定義パターンの種類と，構成定義パターンを選定するための考え方について説明します。なお，システム構成は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照して，あらかじめ決定しておいてください。

＜この項の構成＞

(1)　構成定義パターンの種類

(2)　構成定義パターンの選定方法

(1)　構成定義パターンの種類

Smart Composer機能では，システム内のサーバやサービスユニットの構成をWebシステムという概念で管理します。また，Webシステム内のサーバマシンの集合や，サーバの集合を，それぞれ物理ティア，サービスユニットという論理的なまとまりで扱っています。Smart Composer機能で使用する概念の詳細については，「4.5　バッチアプリケーションを実行するシステムを構成する要素」を参照してください。

構成定義パターンは，サーバマシンに配置するプロセスや，使用する機能によって異なります。サーバマシンに配置するプロセスは，Management Serverで論理サーバとして管理されます。プロセスと論理サーバの対応については，「4.5.3　プロセスの種類と論理サーバとの対応」を参照してください。

バッチアプリケーションを実行するシステムでは，表5-4に示す構成定義パターンを定義できます。構成定義パターンとSmart Composer機能の物理ティアとの対応を次の表に示します。

表5-4　構成定義パターンとSmart Composer機能の物理ティアとの対応（バッチアプリケーションを実行するシステム）

構成定義パターンの種類
配置できる論理サーバ
対応する物理ティア

バッチサーバを配置するパターン

バッチサーバ

パフォーマンストレーサ

j2ee-tier

CTMを使用するパターン

CTMドメインマネジャ

CTM

スマートエージェント

バッチサーバ

パフォーマンストレーサ

ctm-tier

各物理ティアの詳細については，「4.5.1　物理ティアとは」を参照してください。

(2)　構成定義パターンの選定方法

バッチアプリケーションを実行するシステムの場合，構成定義パターンは，使用する機能から選択します。アプリケーションサーバの機能のうち，バッチアプリケーションのスケジューリング機能を使用する場合は，使用できる構成パターンがCTMを使用するパターン（ctm-tier）に限定されます。

5.2.2　システム構成ごとに選択できる構成定義パターン

ここでは，決定したシステム構成から，簡易構築定義ファイルでどの構成定義パターンを定義すればよいかについて説明します。ここで説明するシステム構成は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「4.　システム構成の検討（バッチアプリケーション実行基盤）」で説明しているシステム構成に対応しています。

システム構成と構成定義パターンの対応を次の表に示します。

表5-5　システム構成と構成定義パターンの対応（バッチアプリケーションを実行するシステム）

項番
システム構成
構成定義パターンごとの対応
配置できる論理サーバ※1
「システム設計ガイド」の参照個所※1

A
B

1
バッチアプリケーションのスケジューリング機能を使用しないシステムのシステム構成
○
－

論理J2EEサーバ※2

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

4.2.1

2
バッチアプリケーションのスケジューリング機能を使用するシステムのシステム構成
－
○

論理J2EEサーバ※2

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

論理CTMドメインマネジャ

論理CTM

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

4.2.2

（凡例）

○：対応しています。

－：該当しません。

A：バッチサーバを配置するパターンを示します。

B：CTMを使用するパターンを示します。

注※1

「システム設計ガイド」の参照個所は，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の参照先を示します。この参照個所で説明しているシステム構成図で，論理サーバをどのサーバマシンに配置するかを確認してください。

注※2

バッチサーバとして作成した論理J2EEサーバです。

参考

ここで説明しているシステム構成は，運用管理ポータルでも構築できます。運用管理ポータルでの構築方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「5.　バッチアプリケーションを実行するシステムの構築と削除」を参照してください。

6.　運用・障害設計

システム構築を開始する前に，構築するシステムでの日常運用の操作，メンテナンス，運用スケジュールなどの運用設計，および障害発生時のシステム運用の障害設計についてあらかじめ検討します。この章では，システムごとに，実施できる運用設計，障害設計について説明します。

＜この章の構成＞

6.1　J2EEアプリケーションを実行するシステムの運用・障害設計

6.2　バッチアプリケーションを実行するシステムの運用・障害設計

6.1　J2EEアプリケーションを実行するシステムの運用・障害設計

ここでは，J2EEアプリケーションを実行するシステムを構築する前に検討しておく運用設計，および障害設計について説明します。

＜この節の構成＞

6.1.1　運用設計

6.1.2　障害設計

6.1.1　運用設計

システムの運用設計として，システムの起動や停止などの日常運用操作，OSパッチや予防保守・点検のための部分閉塞・再開，J2EEアプリケーション入れ替えなどのメンテナンス，運用スケジュール，運用スケジュールの自動化，監視，稼働性能統計などを検討します。

ここでは，次に示すSmart Composer機能を使用した運用作業について説明します。

日常運用

サービスユニットの一括起動

サービスユニットの一括停止

メンテナンス

システムの部分メンテナンス

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

システムの設定変更

システムの構成変更

システムのスケールアウト

システムのスケールイン

構築済みのシステムの移行

システムの削除

これらの運用方法については，「9.　J2EEアプリケーションを実行するシステムの運用」を参照してください。

なお，ここでは，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）で構築したシステムを例に説明しています。ここで説明している運用は，次の構成定義パターンで構築したシステムでも操作できます。

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）

インプロセスHTTPサーバを使用するパターン（j2ee-tier）

SFOサーバを使用するパターン（sfo-tier）

CTMを使用するパターン（ctm-tier）

ここで説明している以外の運用については，「9.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。なお，運用作業には，運用を開始する前に設定が必要なものもあります。システムで実施する運用作業を検討し，必要に応じて構築時に設定をしてください。

＜この項の構成＞

(1)　日常運用

(2)　メンテナンス

(3)　システムの設定変更

(4)　システムの構成変更

(5)　構築済みのシステムの移行

(6)　システムの削除

(1)　日常運用

Smart Composer機能で構築したシステムでは，日常運用の操作としてサービスユニットの一括起動と一括停止ができます。一括起動および一括停止は，Webシステム内のすべてのサービスユニットに対して実施したり，特定のサービスユニットに対して実施したりできます。

一括起動および一括停止の範囲を次の図に示します。

図6-1　一括起動および一括停止の範囲

特定のサービスユニットに対して起動または停止できるので，例えば，サービスユニット1だけを停止させるという操作もできます。

参考

メモリセッションフェイルオーバ機能を使用したシステムの場合，業務用のサービスユニットとメモリセッションフェイルオーバ用のサービスユニットとの間で依存関係はありません。このため，特定のサービスユニットに対して起動／停止を実施する場合，起動／停止順序に優先順位はありません。なお，通常の場合，起動時はメモリセッションフェイルオーバ用のサービスユニットを先に起動し，停止時はメモリセッションフェイルオーバ用のサービスユニットをあとで停止します。

次に，一括起動と一括停止の処理について説明します。

(a)　サービスユニットの一括起動処理

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。Smart Composer機能では，一括起動処理中に論理サーバの起動に失敗しても，そのまま処理を続行します。ただし，Webシステムに関連づいていない論理サーバを含むシステムの場合は，論理サーバの起動に失敗すると一括起動処理を中断します。

論理サーバの起動に失敗していると，リクエストの受け付けを開始できない，受け付けたリクエストを処理できないなどの障害が発生します。

一括起動時に-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。

次に示す起動順序で論理J2EEサーバの起動に失敗した場合を例に，それぞれのシステムの処理について説明します。

論理サーバの起動順序

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

論理J2EEサーバ

論理Webサーバ

一括起動を続行したときのシステムの処理
論理Webサーバを起動してリクエストを受け付けます。論理J2EEサーバの起動に失敗しているため，受け付けたリクエストを処理できません。

一括起動を中断したときのシステムの処理
論理Webサーバを起動しません。このため，リクエストを受け付けません。

(b)　サービスユニットの一括停止処理

サービスユニットを一括停止すると，停止対象のサービスユニットを負荷分散機から切り離し，実行中のリクエストを処理したあとに，サービスユニット内のすべての論理サーバを停止します。論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

一括停止の場合，停止対象のシステムによって，論理サーバの停止に失敗したときの動作が異なります。

Webシステムの場合
論理Webサーバの停止に失敗すると，一括停止処理を中断します。そのほかの論理サーバの停止に失敗しても処理を続行します。

Webシステムに関連づいていない論理サーバを含むシステムの場合
論理サーバの停止に失敗しても処理を続行します。論理Webサーバの停止に失敗すると，リクエストの受け付けは継続されます。
この場合，一括停止時に-modeオプションを指定して，停止対象のシステムをいったん閉塞状態にしてから，停止状態にします。

(2)　メンテナンス

Smart Composer機能で構築したシステムで実施できる，メンテナンス時の操作を説明します。

(a)　システムの部分メンテナンス

サービスユニット単位での一括停止および一括起動のコマンドを使用して，サービスユニットを閉塞・再開できます。これを利用して，OSのパッチ適用や予防保守・点検などのシステムの部分メンテナンスを，業務を停止しないで実施できます。

システムの部分メンテナンス（サービスユニット1をメンテナンスする場合）について，次の図に示します。

図6-2　システムの部分メンテナンス（サービスユニット1をメンテナンスする場合）

サービスユニットをメンテナンスする場合の流れは次のとおりです。

一括停止のコマンドを使用して，サービスユニット1だけを閉塞します。

サービスユニット1に対してメンテナンスを実施したあと，一括開始コマンドを使用して，サービスユニット1を再開します。
サービスユニット2はこの間，業務を続行しています。

これらの操作は，Smart Composer機能のコマンドを使用して実施します。

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

J2EEアプリケーションを修正した場合などに，J2EEアプリケーションを入れ替えられます。J2EEアプリケーションの入れ替えには，リデプロイによる入れ替えと，通常の入れ替えがあります。

J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替えについて，次の図にそれぞれ示します。

図6-3　J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替え

J2EEアプリケーションのリデプロイによる入れ替えの流れと，通常の入れ替えの流れは，それぞれ次のとおりです。

リデプロイによる入れ替え

入れ替えるEARファイルのパスを指定して，リデプロイします。

この操作は，サーバ管理コマンドを使用して実施します。

通常の入れ替え

システムを閉塞します。

J2EEアプリケーションを停止します。

入れ替え前のJ2EEアプリケーションを削除します。

入れ替え後のJ2EEアプリケーションをインポートします。

J2EEアプリケーションに必要な情報を設定，およびカスタマイズします。

J2EEアプリケーションを開始します。

システムを再開します。

これらの操作は，Smart Composer機能のコマンドおよびサーバ管理コマンドを使用して実施します。

(3)　システムの設定変更

Smart Composer機能で構築したシステムでは，システム全体の設定を一括で変更できます。システム全体の設定の一括変更について次の図に示します。

図6-4　システム全体の設定の一括変更

システム全体の設定の一括変更の流れは次のとおりです。

システムを停止します。

変更後の設定をシステムに反映させます。
システム内のすべての設定を一度に変更できます。

システムを起動します。

これらの操作はすべてSmart Composer機能のコマンドを使用して実施します。なお，それぞれの操作は，システム内のすべてのサービスユニットに対して一括で実施できます。

(4)　システムの構成変更

Smart Composer機能で構築したシステムで実施できる，システムの構成変更について説明します。

(a)　システムのスケールアウトおよびスケールイン

システムのスケールアウトおよびスケールインができます。スケールアウトとは，システム全体の処理性能を向上させることを目的として，サーバの台数を増やすことをいいます。また，スケールインとは，システムの規模を縮小する場合などに，サーバの台数を減らすことをいいます。

スケールアウトおよびスケールインは，サービスユニット単位またはWebシステム単位で実施できます。なお，スケールアウトおよびスケールインは，業務全体を停止することなく実施できます。

スケールアウトおよびスケールインについて次の図に示します。

図6-5　スケールアウトおよびスケールイン

この図では，サービスユニット3をシステムに追加（スケールアウト），またはシステムから削除（スケールイン）しています。サービスユニット3のスケールアウトおよびスケールインに際しては，稼働中のサービスユニット1およびサービスユニット2には影響はないため，業務全体を停止することなく，スケールアウトおよびスケールインができます。

(b)　JP1/SC/DPMと連携したスケールアウト

Smart Composer機能でシステムをスケールアウトする際に，JP1/SC/DPMと連携できます。

JP1/SC/DPMでは，システムのディスクイメージを複製し，複製したデータを基にして，OSやアプリケーションを一括でサーバにインストールできます（ディスク複製OSインストール機能）。Smart Composer機能でシステムをスケールアウトするときにJP1/SC/DPMと連携すると，構築済みのシステムの複製した情報を使用して，追加するアプリケーションサーバにOSやアプリケーションを一括インストールできます。

ただし，セッションフェイルオーバ機能を使用するシステムの場合，セッションフェイルオーバサーバマシンでは，JP1/SC/DPMと連携したスケールアウトを利用できません。

JP1/SC/DPMと連携してスケールアウトをするときの流れを次の図に示します。ここでは，サービスユニット1が構築済みの場合に，JP1/SC/DPMを使用して，サービスユニット2をシステムに追加（スケールアウト）することを例にしています。

図6-6　JP1/SC/DPMと連携したスケールアウト

JP1/SC/DPMと連携したスケールアウトの流れは次のとおりです。

Smart Composer機能で構築済みのサービスユニット1のディスクイメージを，JP1/SC/DPMを使用して複製します。

手順1.で複製したディスクイメージに従って，追加するサービスユニット2にOSやアプリケーションをインストールします。

Smart Composer機能のコマンドを使用して，サービスユニット2をシステムに追加（スケールアウト）します。

参考

JP1/SC/DPMと連携すると，ホスト単位管理モデルのシステムも構築できます。ホスト単位管理モデルのシステムでは，マシン（運用管理ドメイン）単位に，スケールアウトしてサーバの台数を増やしたり，またはスケールインしてサーバの台数を減らしたりできます。ホスト単位管理モデルでのスケールアウトおよびスケールインについては，「9.8.2　ホスト単位管理モデルでのシステムのスケールアウト」，および「9.8.3(2)　ホスト単位管理モデルでのシステムのスケールイン」を参照してください。

(5)　構築済みのシステムの移行

テスト環境で構築したシステムを本番環境に移行する場合などに，構築済みのシステムを移行できます。

構築済みのシステムの移行について次の図に示します。

図6-7　構築済みのシステムの移行

構築済みのシステムの移行の流れは次のとおりです。

移行元の環境で，システムの設定内容を簡易構築定義ファイルの形式で出力します。

移行先の環境で，出力した簡易構築定義ファイルを使用して，システムを構築します。移行先の環境では，移行元の環境のシステムと同じ設定内容のシステムが構築されます。

これらの操作はSmart Composer機能のコマンドを使用して実施します。なお，構築済みのシステムを移行するためには，移行先のシステムで，Management Serverが動作している必要があります。構築済みのシステムを移行する前に，移行先のシステムでインストールと初期設定を済ませておいてください。

(6)　システムの削除

不要になったシステムは，Smart Composer機能で提供するコマンドで削除できます。システムを削除する手順については，「9.11　システムの削除」を参照してください。

6.1.2　障害設計

障害設計では，障害発生時の対応に関して，障害部分の切り離し，障害からの復旧，障害時の取得資料，障害原因の切り分け，障害調査などについて設計します。

Smart Composer機能では，障害発生時の資料取得に加えて，問題発生時にサービスユニットを自動部分閉塞したり，自動部分再起動したりするような高度な運用ができます。これには，障害検知時コマンドを利用したり，リソース枯渇監視機能やJ2EEアプリケーションの実行時間監視機能を利用したりします。

ここでは，Smart Composer機能で実施できる障害発生時の運用について説明します。

参考

そのほかの障害時の対応については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

2.　トラブルシューティング（資料取得と対処の概要）

3.　トラブルシューティング（資料取得の設定）

4.　トラブルシューティング（資料の出力先と出力方法）

5.　トラブルシューティング（資料の出力内容）

障害発生時の資料取得

障害発生時のサービスユニットの自動閉塞
障害が発生したサービスユニットの自動閉塞（障害発生時のシステムの自動部分閉塞）

障害発生時のサービスユニットの自動再起動
障害が発生したサービスユニットの自動再起動（障害発生時のシステムの自動部分再起動）

これらの運用をする場合は，システム構築時に設定をしておく必要があります。設定手順については，「8.13　障害に対応したシステムの構築」を参照してください。

なお，ここでは，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）で構築したシステムを例に説明しています。ここで説明している運用は，次のパターンで構築したシステムでも操作できます。

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）

インプロセスHTTPサーバを使用するパターン（j2ee-tier）

＜この項の構成＞

(1)　障害発生時の資料取得

(2)　障害発生時のサービスユニットの自動閉塞

(3)　障害発生時のサービスユニットの自動再起動

(1)　障害発生時の資料取得

システムで障害が発生した場合，トラブルシューティングに必要な資料が収集できます。トラブルシューティングに必要な資料は，個別に取得したり，snapshotログとして一括して取得したりできます。snapshotログは，システムの構成ソフトウェアが障害発生時にそのときの状態を出力したログで，各種構成ソフトウェアのログのほかに，スレッドダンプ（ハングアップの場合だけ），性能解析トレースなどが含まれます。

障害発生時のタイムリーな情報をsnapshotログとして収集するためには，障害検知時コマンドを利用します。障害検知時コマンドは，Management Serverが論理サーバの障害を検知したときに，システムによって実行されるコマンドです。障害検知時コマンドを利用して，トラブル発生時のスレッドダンプやユーザダンプの取得などの処理を実行することで，障害発生時のタイムリーな資料を取得できるようになります。障害検知時コマンドには，システム提供の障害検知時コマンドとユーザ作成の障害検知時コマンドの2種類があります。

システム提供の障害検知時コマンド
障害の発生したJ2EEサーバのスレッドダンプ（ハングアップの場合だけ）および性能解析トレースなどを取得します。

ユーザ作成の障害検知時コマンド
障害発生時に実行する処理をユーザが定義します。

障害検知時コマンドの実行とsnapshotログの収集によって，トラブルシューティングに必要な情報を取得できます。障害検知時コマンドの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「2.3.2　障害検知時コマンドによる資料取得」を参照してください。

また，資料によっては，事前に取得のための設定をしておく必要があります。例えば，OSの統計情報，ユーザダンプなどは，システム構築時に取得のための設定をしておかないと取得できません。これらの資料はトラブルシューティングで必要となるため，取得することをお勧めします。デフォルトの設定ではsnapshotログとして収集できない資料でも，その資料の取得先をsnapshotログの収集対象として定義することで，snapshotログとして一括収集できるようになります。

取得できる資料およびsnapshotログ収集の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.3　snapshotログ収集の設定（J2EEアプリケーションを実行するシステム）」を参照してください。

参考

ユーザ作成の障害検知時コマンドには，Smart Composer機能のコマンドを定義しておくこともできます。例えば，致命的な障害が発生したサービスユニットを自動閉塞するコマンドを，障害検知時コマンドとして設定しておくことができます。障害検知時コマンドを利用したサービスユニットの自動閉塞については，「(2)　障害発生時のサービスユニットの自動閉塞」を，障害検知時コマンドを利用して自動閉塞する場合の設定については，「8.13.1　障害発生時にサービスユニットを自動閉塞するための設定」を参照してください。

(2)　障害発生時のサービスユニットの自動閉塞

システムで障害が発生した場合に，Management Serverが障害を検知すると，システムによって障害検知時コマンドが実行されます。Smart Composer機能では，この障害検知時コマンドを利用して，致命的な障害が発生したサービスユニットを自動閉塞できます。

障害発生時のサービスユニットの自動閉塞を次の図に示します。

図6-8　障害発生時のサービスユニットの自動閉塞

障害発生時のサービスユニット自動閉塞の仕組みについて説明します。

サービスユニット内の論理サーバで障害が発生すると，アプリケーションサーバ内の運用管理エージェントは障害発生を検知し，Management Serverに障害発生を通知します。Management Serverでは，障害発生を検知すると，自動的にコマンドを実行できます。このコマンドを障害検知時コマンドといいます。障害検知時コマンドには，システム提供の障害検知時コマンドと，ユーザ作成の障害検知時コマンドの2種類があり，ユーザ作成の障害検知時コマンドでは，障害が発生したときに呼び出すコマンドを定義できます。

ユーザ作成の障害検知時コマンドとして，Smart Composer機能のコマンドを定義することで，障害が発生したサービスユニットを自動閉塞できます。障害検知時コマンドのファイル作成については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.1　障害検知時コマンドによる資料取得の設定（J2EEアプリケーションを実行するシステム）」を参照してください。

(3)　障害発生時のサービスユニットの自動再起動

JavaVMのフルガーベージコレクションやスレッド数などのリソース枯渇を事前に検知したり，J2EEアプリケーションの実行時間監視タイムアウトを検知したりすると，問題が発生したサービスユニットを自動再起動します。サービスユニットの自動再起動には，リソース枯渇監視機能や，J2EEアプリケーションの実行時間監視機能を利用します。

障害発生時のサービスユニットを自動再起動する図を次に示します。

図6-9　障害発生時のサービスユニットの自動再起動

障害発生時のサービスユニット自動再起動の仕組みについて説明します。

サービスユニットの自動再起動では，リソース枯渇監視機能，およびJ2EEアプリケーションの実行時間監視機能を利用します。リソース枯渇監視機能でリソース枯渇を事前に検知したり，J2EEアプリケーションの実行時間監視でタイムアウトを検知したりすると，これらの情報がManagementイベントとして，運用管理サーバに通知されます。Managementイベントが通知されると，Management ServerではManagementアクションが実行されます。Managementアクションでは，ユーザがあらかじめ定義しておいた処理を実施します。

Managementアクションとして，サービスユニットを再起動するSmart Composer機能のコマンドを定義することで，障害の発生したサービスユニットを自動再起動できます。

ManagementイベントおよびManagementアクションについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.　Managementイベントの通知とManagementアクションによる処理の自動実行」を参照してください。リソース枯渇機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.　リソースの枯渇監視」を参照してください。J2EEアプリケーションの実行時間監視機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。

6.2　バッチアプリケーションを実行するシステムの運用・障害設計

ここでは，バッチアプリケーションを実行するシステムを構築する前に検討しておく運用設計，および障害設計について説明します。

＜この節の構成＞

6.2.1　運用設計

6.2.2　障害設計

6.2.1　運用設計

システムの運用設計として，システムの起動や停止などの日常運用操作，運用スケジュール，運用スケジュールの自動化，監視，稼働性能統計などを設計します。

ここでは，次に示すSmart Composer機能を使用した運用作業について説明します。

日常運用

サービスユニットの一括起動

サービスユニットの一括停止

システムの設定変更

システムの構成変更

システムのスケールアウト

システムのスケールイン

構築済みのシステムの移行

システムの削除

これらの運用方法については，「11.　バッチアプリケーションを実行するシステムの運用」を参照してください。

なお，ここでは，バッチサーバを配置するパターン（j2ee-tier）で構築したシステムを例に説明しています。ここで説明している運用のうち，システムのスケールアウトおよびシステムのスケールイン以外は，CTMを使用するパターン（ctm-tier）で構築したシステムでも操作できます。

ここで説明している以外の運用については，「11.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。なお，運用作業には，運用を開始する前に設定が必要なものもあります。システムで実施する運用作業を検討し，必要に応じて構築時に設定をしてください。

＜この項の構成＞

(1)　日常運用

(2)　システムの設定変更

(3)　システムの構成変更

(4)　構築済みのシステムの移行

(5)　システムの削除

(1)　日常運用

Smart Composer機能で構築したシステムでは，日常運用の操作としてサービスユニットの一括起動と一括停止ができます。一括起動および一括停止は，システム内のすべてのサービスユニットに対して実施したり，特定のサービスユニットに対して実施したりできます。

一括起動および一括停止の範囲を次の図に示します。

図6-10　一括起動および一括停止の範囲

特定のサービスユニットに対して起動または停止できるので，例えば，サービスユニット1だけを停止させるという操作もできます。

次に，一括起動と一括停止の処理について説明します。

(a)　サービスユニットの一括起動処理

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。

一括起動時に-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。

(b)　サービスユニットの一括停止処理

サービスユニットを一括停止すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

(2)　システムの設定変更

Smart Composer機能で構築したシステムでは，システム全体の設定を一括で変更できます。システム全体の設定の一括変更について次の図に示します。

図6-11　システム全体の設定の一括変更

システム全体の設定の一括変更の流れは次のとおりです。

システムを停止します。

変更後の設定をシステムに反映させます。
システム内のすべての設定を一度に変更できます。

システムを起動します。

これらの操作はすべてSmart Composer機能のコマンドを使用して実施します。なお，それぞれの操作は，システム内のすべてのサービスユニットに対して一括で実施できます。

(3)　システムの構成変更

Smart Composer機能で構築したシステムで実施できる，システムの構成変更について説明します。

注意

CTMを使用するパターン（ctm-tier）で構築したシステムの場合，システムのスケールアウトおよびスケールインによるシステムの構成変更は実施できません。

(a)　システムのスケールアウトおよびスケールイン

システムのスケールアウトおよびスケールインができます。スケールアウトとは，システム全体の処理性能を向上させることを目的として，サーバの台数を増やすことをいいます。また，スケールインとは，システムの規模を縮小する場合などに，サーバの台数を減らすことをいいます。

スケールアウトおよびスケールインは，サービスユニット単位またはWebシステム単位で実施できます。なお，スケールアウトおよびスケールインは，業務全体を停止することなく実施できます。

スケールアウトおよびスケールインについて次の図に示します。

図6-12　スケールアウトおよびスケールイン

この図では，サービスユニット3をシステムに追加（スケールアウト），またはシステムから削除（スケールイン）しています。サービスユニット3のスケールアウトおよびスケールインに際しては，稼働中のサービスユニット1およびサービスユニット2には影響はないため，業務全体を停止することなく，スケールアウトおよびスケールインができます。

(b)　JP1/SC/DPMと連携したスケールアウト

Smart Composer機能でシステムをスケールアウトする際に，JP1/SC/DPMと連携できます。

JP1/SC/DPMでは，システムのディスクイメージを複製し，複製したデータを基にして，OSやアプリケーションを一括でサーバにインストールできます（ディスク複製OSインストール機能）。Smart Composer機能でシステムをスケールアウトするときにJP1/SC/DPMと連携すると，構築済みのシステムの複製した情報を使用して，追加するアプリケーションサーバにOSやアプリケーションを一括インストールできます。

JP1/SC/DPMと連携してスケールアウトをするときの流れを次の図に示します。ここでは，サービスユニット1が構築済みの場合に，JP1/SC/DPMを使用して，サービスユニット2をシステムに追加（スケールアウト）することを例にしています。

図6-13　JP1/SC/DPMと連携したスケールアウト

JP1/SC/DPMと連携したスケールアウトの流れは次のとおりです。

Smart Composer機能で構築済みのサービスユニット1のディスクイメージを，JP1/SC/DPMを使用して複製します。

手順1.で複製したディスクイメージに従って，追加するサービスユニット2にOSやアプリケーションをインストールします。

Smart Composer機能のコマンドを使用して，サービスユニット2をシステムに追加（スケールアウト）します。

参考

JP1/SC/DPMと連携すると，マシン（運用管理ドメイン）単位にスケールアウトしてサーバの台数を増やしたり，またはスケールインしてサーバの台数を減らしたりできます。JP1/SC/DPMでのスケールアウトおよびスケールインについては，「11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン」を参照してください。

(4)　構築済みのシステムの移行

テスト環境で構築したシステムを本番環境に移行する場合などに，構築済みのシステムを移行できます。

構築済みのシステムの移行について次の図に示します。

図6-14　構築済みのシステムの移行

構築済みのシステムの移行の流れは次のとおりです。

移行元の環境で，システムの設定内容を簡易構築定義ファイルの形式で出力します。

移行先の環境で，出力した簡易構築定義ファイルを使用して，システムを構築します。移行先の環境では，移行元の環境のシステムと同じ設定内容のシステムが構築されます。

これらの操作はSmart Composer機能のコマンドを使用して実施します。なお，構築済みのシステムを移行するためには，移行先のシステムで，Management Serverが動作している必要があります。構築済みのシステムを移行する前に，移行先のシステムでインストールと初期設定を済ませておいてください。

(5)　システムの削除

不要になったシステムは，Smart Composer機能で提供するコマンドで削除できます。システムを削除する手順については，「11.8　システムの削除」を参照してください。

6.2.2　障害設計

障害設計では，障害発生時の対応に関して，障害部分の切り離し，障害からの復旧，障害時の取得資料，障害原因の切り分け，障害調査などについて設計します。

Smart Composer機能では，障害発生時の資料取得に加えて，問題発生時にサービスユニットを自動部分閉塞したり，自動部分再起動したりするような高度な運用ができます。これには，障害検知時コマンドを利用したり，リソース枯渇監視機能を利用したりします。

ここでは，Smart Composer機能で実施できる障害発生時の運用について説明します。

参考

そのほかの障害時の対応については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

2.　トラブルシューティング（資料取得と対処の概要）

3.　トラブルシューティング（資料取得の設定）

4.　トラブルシューティング（資料の出力先と出力方法）

5.　トラブルシューティング（資料の出力内容）

障害発生時の資料取得

障害発生時のサービスユニットの自動再起動
障害が発生したサービスユニットの自動再起動（障害発生時のシステムの自動部分再起動）

この運用をする場合は，システム構築時に設定をしておく必要があります。設定手順については，「10.10　障害に対応したシステムの構築」を参照してください。

なお，ここでは，バッチサーバを配置するパターン（j2ee-tier）で構築したシステムを例に説明しています。ここで説明している運用は，CTMを使用するパターン（ctm-tier）で構築したシステムでも操作できます。

＜この項の構成＞

(1)　障害発生時の資料取得

(2)　障害発生時のサービスユニットの自動再起動

(1)　障害発生時の資料取得

システムで障害が発生した場合，トラブルシューティングに必要な資料が収集できます。トラブルシューティングに必要な資料は，個別に取得したり，snapshotログとして一括して取得したりできます。snapshotログは，システムの構成ソフトウェアが障害発生時にそのときの状態を出力したログで，各種構成ソフトウェアのログのほかに，スレッドダンプ（ハングアップの場合だけ），性能解析トレースなどが含まれます。

障害発生時のタイムリーな情報をsnapshotログとして収集するためには，障害検知時コマンドを利用します。障害検知時コマンドは，Management Serverが論理サーバの障害を検知したときに，システムによって実行されるコマンドです。障害検知時コマンドを利用して，トラブル発生時のスレッドダンプやユーザダンプの取得などの処理を実行することで，障害発生時のタイムリーな資料を取得できるようになります。障害検知時コマンドには，システム提供の障害検知時コマンドとユーザ作成の障害検知時コマンドの2種類があります。

システム提供の障害検知時コマンド
障害の発生したバッチサーバのスレッドダンプ（ハングアップの場合だけ）および性能解析トレースなどを取得します。

ユーザ作成の障害検知時コマンド
障害発生時に実行する処理をユーザが定義します。

障害検知時コマンドの実行とsnapshotログの収集によって，トラブルシューティングに必要な情報を取得できます。障害検知時コマンドの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「2.3.2　障害検知時コマンドによる資料取得」を参照してください。

また，資料によっては，事前に取得のための設定をしておく必要があります。例えば，OSの統計情報，ユーザダンプなどは，システム構築時に取得のための設定をしておかないと取得できません。これらの資料はトラブルシューティングで必要となるため，取得することをお勧めします。デフォルトの設定ではsnapshotログとして収集できない資料でも，その資料の取得先をsnapshotログの収集対象として定義することで，snapshotログとして一括収集できるようになります。

取得できる資料およびsnapshotログ収集の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.4　snapshotログ収集の設定（バッチアプリケーションを実行するシステム）」を参照してください。

参考

ユーザ作成の障害検知時コマンドには，Smart Composer機能のコマンドを定義しておくこともできます。例えば，致命的な障害が発生したサービスユニットを自動閉塞するコマンドを，障害検知時コマンドとして設定しておくことができます。

(2)　障害発生時のサービスユニットの自動再起動

JavaVMのフルガーベージコレクションやスレッド数などのリソース枯渇を事前に検知すると，問題が発生したサービスユニットを自動再起動します。サービスユニットの自動再起動には，リソース枯渇監視機能を利用します。

障害発生時のサービスユニットを自動再起動する図を次に示します。

図6-15　障害発生時のサービスユニットの自動再起動

障害発生時のサービスユニット自動再起動の仕組みについて説明します。

サービスユニットの自動再起動では，リソース枯渇監視機能を利用します。リソース枯渇監視機能でリソース枯渇を事前に検知すると，これらの情報がManagementイベントとして，Management Serverに通知されます。Managementイベントが通知されると，Management ServerではManagementアクションが実行されます。Managementアクションでは，ユーザがあらかじめ定義しておいた処理を実施します。

Managementアクションとして，サービスユニットを再起動するSmart Composer機能のコマンドを定義することで，障害の発生したサービスユニットを自動再起動できます。

なお，ManagementイベントおよびManagementアクションについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.　Managementイベントの通知とManagementアクションによる処理の自動実行」を参照してください。リソース枯渇機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.　リソースの枯渇監視」を参照してください。

7.　インストールと初期設定

この章では，アプリケーションサーバの製品のインストールとアンインストール，および初期設定について説明します。

＜この章の構成＞

7.1　インストールと初期設定の概要

7.2　インストールとアンインストール

7.3　環境変数の設定

7.4　使用リソースの設定

7.5　データベースを使用するための設定

7.6　Management Serverのセットアップと環境設定

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

7.8　Server Plug-inの設定

7.9　インストール後のディレクトリ構成

7.10　J2EEサーバの作業ディレクトリ

7.11　バッチサーバの作業ディレクトリ

7.1　インストールと初期設定の概要

ここでは，Application Serverをインストールして初期設定する操作の概要について説明します。Application Serverは，業務システムの実行環境となるアプリケーションサーバを構築するための製品で，Application Server StandardとApplication Server Enterpriseという2種類のエディションがあります。なお，エディションによって提供される構成ソフトウェアが異なります。それぞれのエディションで提供する構成ソフトウェアについては，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

なお，このマニュアルではDeveloperのインストールや環境設定については説明しません。Developerのインストールや初期設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「2.2.1　Developerのインストール」を参照してください。

インストールと初期設定の流れを次の図に示します。

図7-1　インストールと初期設定の流れ

参考

アプリケーションサーバの場合，構築済みの環境を1台のマシンに複数共存でき，それらを切り替えて使用できます。詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「11.　複数の構築済み実行環境の切り替え」を参照してください。

図中の1.～7.について説明します。

Application Serverをインストールします。
「7.2.1　インストール方法」を参照してください。なお，インストールする製品のエディションは，構築するシステムの構成によって異なります。また，構築する環境に応じて，アプリケーションサーバのオプション製品をインストールしてください。マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.2　製品の概要」で確認してからインストールしてください。
Application Serverのインストール後，必要に応じて次の内容を設定してください。

Component Container管理者の設定

UNIXでシステムを構築および運用する場合は，構成ソフトウェアであるCosminexus Component Containerのインストール後に，Component Container管理者を設定できます。Component Container管理者を設定すると，スーパーユーザ以外でもサーバの起動・停止などの操作が実施できるようになります。Component Container管理者の設定については，「7.2.3　Component Container管理者の設定（UNIXの場合）」を参照してください。

C++ライブラリのバージョン設定

Linuxの場合，プロセス内で使用するC++ライブラリのバージョンを指定します。C++ライブラリのバージョン設定については，「7.2.4　C++ライブラリのバージョン指定（Linuxの場合）」を参照してください。

環境変数を設定します。
インストールした製品の種類，使用する機能に応じて，必要な環境変数を設定します。環境変数の設定については，「7.3　環境変数の設定」を参照してください。

リソースおよびメモリ所要量を設定します。
Application Serverをインストールしたマシンで使用するリソースおよびメモリ所要量を設定します。リソースおよびメモリ所要量の見積もりと設定方法については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」または「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

必要に応じて，データベースの設定をします。
データベースとして，HiRDB，Oracle，またはXDM/RD E2を使用する場合，環境変数や権限の設定などが必要です。データベースの設定については，「7.5　データベースを使用するための設定」を参照してください。

Management Serverのセットアップと環境設定をします。
アプリケーションサーバを利用したシステム構築では，Management Serverを使用します。Management Serverを初めて使用するホストでは，Management Serverをセットアップして環境設定をしてください。セットアップおよび設定については，「7.6　Management Serverのセットアップと環境設定」を参照してください。

必要に応じて，システムの起動と停止の設定をします。
Management Serverや運用管理エージェントを自動で起動または停止する場合には，設定が必要です。設定方法については，「7.7　システムの起動と停止の設定」を参照してください。

必要に応じて，Server Plug-inの設定をします。
Server Plug-inを使用してリソースやJ2EEアプリケーションを設定する場合には，Server Plug-inのEclipseへの組み込みやServer Plug-inの環境設定などが必要です。Server Plug-inの設定については，「7.8　Server Plug-inの設定」を参照してください。

インストールと初期設定が完了したら，システムを構築します。構築方法は，システムごとに次の章を参照してください。

J2EEアプリケーションを実行するシステムの場合
「8.　J2EEアプリケーションを実行するシステムの構築」

バッチアプリケーションを実行するシステムの場合
「10.　バッチアプリケーションを実行するシステムの構築」

なお，ここでは，Application Serverとその構成ソフトウェアに関連した初期設定だけを説明しています。LDAPディレクトリサーバ，EISなど，ほかの製品を使用している場合は，必要に応じて各製品のマニュアルを参照して環境を設定してください。

参考

JP1/SC/DPMのディスク複製OSインストール機能を使用する場合は，アプリケーションサーバおよびJP1/SC/DPM管理サーバに，JP1/SC/DPMをインストールする必要があります。JP1/SC/DPMについては，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。

Application Serverのインストール後のディレクトリ構成については，「7.9　インストール後のディレクトリ構成」を参照してください。J2EEサーバおよびバッチサーバの作業ディレクトリについては，「7.10　J2EEサーバの作業ディレクトリ」または「7.11　バッチサーバの作業ディレクトリ」を参照してください。

7.2　インストールとアンインストール

ここでは，Application Serverのインストールとアンインストールについて説明します。

参考

アプリケーションサーバのオプション製品のインストールとアンインストールについては，次のマニュアルまたは個所を参照してください。

uCosminexus Clientの場合
マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「付録A　uCosminexus Client」

Web Redirectorの場合
マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「付録D　Web Redirector」

uCosminexus Operatorの場合
「付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）」

＜この節の構成＞

7.2.1　インストール方法

7.2.2　アンインストール方法

7.2.3　Component Container管理者の設定（UNIXの場合）

7.2.4　C++ライブラリのバージョン指定（Linuxの場合）

7.2.5　アプリケーションサーバでサポートしているシンボリックリンク（UNIXの場合）

7.2.1　インストール方法

製品のインストールには，日立総合インストーラを使用します。

インストールを実行する前に，構成ソフトウェアのすべてのプロセスが実行中でないことを確認してください。実行中の場合は，構成ソフトウェアのすべてのプロセスを停止してから，インストールを実行してください。

インストール作業には，Windowsの場合はAdministrator権限が，UNIXの場合はroot権限が必要です。なお，製品のインストールについては，各製品のリリースノートを参照してください。

ここでは，製品の構成ソフトウェアのインストールについて説明します。

Cosminexus Component Containerのインストール

ほかの構成ソフトウェアのインストール

なお，製品と構成ソフトウェアの対応については，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

＜この項の構成＞

(1)　Cosminexus Component Containerのインストール

(2)　ほかの構成ソフトウェアのインストール

(1)　Cosminexus Component Containerのインストール

Cosminexus Component Containerは，Application Serverの構成ソフトウェアです。

新規インストール，上書きインストール，アップグレードインストールの場合のインストール方法についてそれぞれ説明します。上書きインストールおよびアップグレードインストールの場合，インストール時に注意が必要です。インストール時の注意事項については，「(d)　インストール時の注意事項」を参照してください。

なお，インストールに失敗した場合は，次の点を確認してください。

起動しているサービスやアクセス中のファイル，ディレクトリがないか

ファイル，ディレクトリのアクセス権が拒否されていないか

また，J2EEサーバまたはバッチサーバでの，インストール方法ごとのユーザ環境の扱いを次の表に示します。

表7-1　インストール方法ごとのユーザ環境の扱い

インストール方法
サーバのユーザ定義
サーバ管理コマンドのユーザ定義
サーバの作業ディレクトリ※

新規インストール
インストーラが，デフォルトのサーバをセットアップし，ユーザ定義を作成します。
インストーラが，デフォルトのユーザ定義を作成します。
サーバが，初回起動時に作成します。

上書きインストール
引き継ぎます。
引き継ぎます。
引き継ぎます。

アップグレードインストール
引き継ぎます。
引き継ぎます。
インストール後，cjenvupdateコマンドを実行して移行してください。
移行情報は，既存のディレクトリに格納され，そのまま利用されます。

注※　サーバの作業ディレクトリは，J2EEサーバとバッチサーバの場合で異なります。J2EEサーバの作業ディレクトリについては，「7.10　J2EEサーバの作業ディレクトリ」を参照してください。バッチサーバの作業ディレクトリについては，「7.11　バッチサーバの作業ディレクトリ」を参照してください。

(a)　新規インストールの場合

新規インストールとは，インストール先のマシンにCosminexus Component Containerがインストールされていない場合のインストールです。新規インストールの場合の手順について，OSごとに説明します。

●Windowsの場合

インストールディレクトリにファイルがないことを確認します。
インストールディレクトリが作成されていない場合は問題ありません。
インストールディレクトリが作成されている場合は，インストールディレクトリにファイルがないことを確認してください。
デフォルトでは，次のディレクトリ群にインストールされます。

<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus¥CC

<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus¥manager

<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus¥c4web

<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus¥CWC

<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus¥plugins

インストール先に同名のファイルがあり，保護されていない場合は，上書きするおそれがあります。ファイルを別の場所に移動するか，またはインストール先を変更してください。

Cosminexus Component Containerをインストールします。

●UNIXの場合

新規インストールの場合の手順を次の図に示します。なお，Component Container管理者を設定する場合と，Component Container管理者を設定しない場合では，手順が異なります。

図7-2　Cosminexus Component Containerの新規インストールの手順

図中の1.～6.について説明します。なお，グループと管理者の登録，ディレクトリの所有者とグループの変更については，ご使用のOS付属のマニュアルなどを参照してください。

Component Container管理者を登録するグループを登録します。
ここで登録するグループをComponent Container管理者グループと呼びます。

手順1.で登録したグループに，Component Container管理者を登録します。
このときComponent Container管理者グループをComponent Container管理者のプライマリグループにしてください。

Cosminexus Component Containerのインストールディレクトリ下に，ファイルまたはディレクトリがないことを確認します。
インストールディレクトリが作成されていない場合は問題ありません。
インストールディレクトリがある場合，インストールディレクトリにファイルがないことを確認してください。製品がインストールするファイルまたはディレクトリと同名のファイルまたはディレクトリがある場合は，ファイルまたはディレクトリが上書きされます。必要に応じて，ディレクトリやファイルの移動，またはバックアップの作成をしてください。

Cosminexus Component Containerをインストールします。
サーバが自動的にセットアップされます。デフォルトのサーバ名称はホスト名称です。

Cosminexus Component Containerのインストールディレクトリの所有者とグループを，手順1.および手順2.で登録したComponent Container管理者とComponent Container管理者グループに変更します。

cjenvsetupコマンドを実行して，Component Container管理者をセットアップします。
cjenvsetupコマンドでのComponent Container管理者の設定後，Component Container管理者が実施できる操作は，一部の操作を除き，スーパーユーザでは操作できなくなります。詳細については，「7.2.3　Component Container管理者の設定（UNIXの場合）」を参照してください。

(b)　上書きインストールの場合

Cosminexus Component Containerの上書きインストールとは，Cosminexus Component Container 08-50がインストールされたマシンにCosminexus Component Containerをインストールすることです。上書きインストールの場合の手順を次に示します。

Cosminexus Component Containerをインストールします。
上書きインストールすると，前の設定が自動的に引き継がれます。
なお，デフォルトのサーバの定義ディレクトリがない場合には，次に示すように自動的にセットアップされます。

デフォルトのサーバ（ホスト名称のサーバ）の定義ディレクトリ（<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<ホスト名称>，または/opt/Cosminexus/CC/server/usrconf/ejb/<ホスト名称>）がない場合には，定義ファイルが自動的にセットアップされます。

なお，UNIXの場合，上書きインストールの操作はComponent Container管理者の設定の有無によって異なります。

Component Container管理者を設定していた場合
上書きインストール後も同じユーザがComponent Container管理者となります。上書きインストール後のサーバのセットアップ，起動と停止などの操作はComponent Container管理者が実施してください。
Component Container管理者を変更したい場合には，Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）の所有者およびグループを変更して，cjenvsetupコマンドでComponent Container管理者をセットアップしてください。

Component Container管理者を設定する場合
上書きインストール前にComponent Container管理者を設定していない状態で，上書きインストール後，新規にComponent Container管理者を設定する場合は，スーパーユーザで次の操作を実施してください。

Component Container管理者グループの登録

Component Container管理者の登録

上書きインストール

Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）の所有者およびグループの変更

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

Component Container管理者の設定方法については，「(a)　新規インストールの場合」を参照してください。
Component Container管理者の設定後，J2EEサーバやバッチサーバのセットアップ，起動と停止などの操作はComponent Container管理者が実施してください。

Component Container管理者を設定しない場合
上書きインストール前にComponent Container管理者を設定していない状態で，上書きインストール後もそのままComponent Container管理者を設定しない場合は，J2EEサーバやバッチサーバのセットアップ，起動と停止などの操作はスーパーユーザで実施できます。

(c)　アップグレードインストールの場合

Cosminexus Component Containerのアップグレードインストール時の注意事項を次に示します。

インストーラによるユーザデータの移行作業

以前のバージョンのCosminexus Component Containerがインストールされている場合，インストール時に，インストーラによるユーザデータの移行作業が行われます。インストーラでは完全に移行できないユーザデータについては，インストール後に移行作業用のコマンドを実行して，作業ディレクトリの移行やリソースアダプタのバージョンアップなどの移行作業をしてください。

アップグレードインストール時に削除されるディレクトリ

アップグレードインストール時には次のディレクトリが削除されます。必要なファイルがある場合は，アップグレードインストール前に退避してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥help

<Cosminexusのインストールディレクトリ>¥CC¥examples

<Cosminexusのインストールディレクトリ>¥CC¥gui

UNIXの場合

/opt/Cosminexus/CC/admin/help

/opt/Cosminexus/CC/examples

/opt/Cosminexus/CC/gui

Cosminexus Web Services - Baseをインストールしている場合のアップグレードインストール

Cosminexus Web Services - Baseはアプリケーションサーバ Version 6までで提供されている構成ソフトウェアです。UNIXの場合で，アプリケーションサーバ Version 8にアップグレードインストールするときは，動作モードの移行が実施されます。このため，マニュアル「Cosminexus アプリケーションサーバ SOAPアプリケーション開発の手引」の「付録A　SOAPアプリケーションの移行」を参照して，移行してください。

移行作業およびバージョン間の機能の差異については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「12.　旧バージョンのアプリケーションサーバからの移行」を参照してください。

なお，UNIXの場合，アップグレードインストールの操作はComponent Container管理者の設定の有無によって異なります。

Component Container管理者を設定していた場合
アップグレードインストール後も同じユーザがComponent Container管理者となります。
移行作業はComponent Container管理者が実施してください。また，その後のJ2EEサーバやバッチサーバのセットアップ，起動と停止などの操作もComponent Container管理者が実施してください。
Component Container管理者を変更したい場合には，Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）の所有者およびグループを変更して，cjenvsetupコマンドでComponent Container管理者をセットアップしてください。

Component Container管理者を設定する場合
アップグレードインストール前にComponent Container管理者を設定していない状態で，アップグレードインストール後，新規にComponent Container管理者を設定する場合は，次の手順でアップグレードインストールしてください。なお，これらの操作は，すべてスーパーユーザで実施してください。

Component Container管理者グループの登録

Component Container管理者の登録

Cosminexus Component Containerのインストール

移行作業

Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）の所有者およびグループの変更

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

Component Container管理者の設定方法については，「(a)　新規インストールの場合」を参照してください。
Component Container管理者の設定後，J2EEサーバやバッチサーバのセットアップ，起動と停止などの操作はComponent Container管理者が実施してください。

Component Container管理者を設定しない場合
アップグレードインストール前にComponent Container管理者を設定していない状態で，アップグレードインストール後もそのままComponent Container管理者を設定しない場合は，移行作業はスーパーユーザが実施してください。
また，その後のJ2EEサーバやバッチサーバのセットアップ，起動と停止などの操作もスーパーユーザが実施してください。

(d)　インストール時の注意事項

●Cosminexus Component Containerの新規インストール，上書きインストールおよびアップグレードインストール時の注意事項

新規インストール，上書きインストールおよびアップグレードインストール時の注意事項を次に示します。

Windowsの場合，Management Serverおよび運用管理エージェントのサービスのログオンアカウントには，デフォルトであるローカルシステムアカウント以外は指定しないでください。ただし，J2EEアプリケーションからネットワークリソースへアクセスする場合には，運用管理エージェントのサービスのログオンアカウントをローカルホストのAdministratorsグループに所属するように設定してください。

●Cosminexus Component Containerの上書きインストールおよびアップグレードインストール時の注意事項

Cosminexus Component Containerの上書きインストールおよびアップグレードインストール時の注意事項を次に示します。

旧バージョンからアップグレードインストールする場合，作業ディレクトリのディスク使用量の2倍以上の空き容量を確保してください。

UNIXの場合，旧バージョンのインストールディレクトリが変更されていたときは，新規インストールになります。

UNIXの場合，アプリケーションサーバ Version 6までで提供している構成ソフトウェアのうち，Cosminexus Component Library，Cosminexus Manager，およびCosminexus Web Services - Baseがインストールされている環境には，Cosminexus Component Containerをインストールできません。インストールされている場合は必ずアンインストールしてください。

旧バージョンからアップグレードインストールして環境を移行した場合，作業ディレクトリは旧バージョンで使用していたディレクトリを引き続き使用します。旧バージョンの作業ディレクトリを誤って削除しないようにしてください。

旧バージョンからアップグレードインストールした場合，運用管理ポータルの「論理サーバのアプリケーション管理」は，V7互換モードで動作します。V8モードで動作したい場合は，mserver.propertiesのcom.cosminexus.mngsvr.compat.operation_appキーに「false」を設定してください。

このバージョンの製品または試用版をインストールしてアンインストールしたあとに古いバージョンの製品をインストールする場合は，インストール先にこのバージョンで作成された環境（<Cosminexusのインストールディレクトリ>¥CC，または/opt/Cosminexus/CC）が残っていないことを確認してください。このバージョンで作成された環境が残っていると，古いバージョンへ移行されないため，製品の動作やそのあとのアップグレードインストールなどが保証されません。このバージョンで作成された環境が残っている場合は，インストール先を変更するか，このバージョンで作成された環境を削除または移動してからインストールしてください。

運用管理エージェントの設定ファイルであるadminagent.xmlは，インストール時に上書きされ，既存のファイルはadminagent.xml.bakとして退避されます。adminagent.xmlを編集して運用している場合は，新たにインストールされたファイルに，以前に編集した項目を再編集してください。

バージョン間の機能の差異については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「12.　旧バージョンのアプリケーションサーバからの移行」を参照してください。

snapshotログ収集先対象リストファイルであるsnapshotlog.conf，およびsnapshotlog.2.confは，インストール時に上書きされ，既存のファイルはsnapshotlog.conf.bak，およびsnapshotlog.2.conf.bakとして退避されます。snapshotログの収集対象を編集して運用している場合は，新たにインストールされたファイルに，以前に編集した項目を再編集してください。

Management Server上で論理Webサーバを削除しないで，Hitachi Web Serverをアンインストールして再インストールした場合，Management Serverで管理されている論理Webサーバは削除されませんが，実サーバ（Webサーバ（Hitachi Web Server））は削除されます。このため，再インストール後，Management Serverで該当する論理Webサーバを再セットアップする必要があります。この場合は，運用管理ポータルで再度論理Webサーバのセットアップと配布を実行してください。
また，httpsd.confファイルは，運用管理ポータルで論理Webサーバの設定情報を配布した時に新規作成または上書きされます。このため，手動でhttpsd.confファイルを修正していた場合は，運用管理ポータルで論理Webサーバの設定情報を配布したあとに，必要に応じて，再度httpsd.confファイルを修正してください。なお，運用管理ポータルの［Webサーバの設定］画面で，httpsd.confファイルの内容を編集して配布している場合は，修正不要です。

(2)　ほかの構成ソフトウェアのインストール

構成ソフトウェアのインストールディレクトリにファイルがないことを確認してください。インストール先に同名のファイルがあり，保護されていない場合は，上書きされて，元のファイルが失われるおそれがあります。ファイルを別の場所に移動するか，またはインストール先を変更してください。

7.2.2　アンインストール方法

製品と構成ソフトウェアのアンインストールについて説明します。

アンインストールを実行する前に，構成ソフトウェアのすべてのプロセスが実行中でないことを確認してください。実行中の場合は，構成ソフトウェアのすべてのプロセスを停止してから，アンインストールを実行してください。

製品および構成ソフトウェアのアンインストールについては，各製品のリリースノートを参照してください。

なお，UNIXの場合には，製品および構成ソフトウェアをアンインストールする時に次の点に注意してください。

UNIXの場合，製品のアンインストールは，日立PPインストーラを使用します。アンインストールにはroot権限が必要です。また，製品の構成ソフトウェアすべてを一度に削除できません。構成ソフトウェアごとに削除します。

ユーザ定義ファイルなど，カスタマイズ用のファイルが格納されたディレクトリ以外は，すべて削除されます。このため，製品のディレクトリ下に必要なファイルを格納しないでください。
削除対象となっているディレクトリは無条件に削除されます。このため，これらのディレクトリにユーザ固有のファイルなどを格納しないでください。

日立トレース共通ライブラリは，製品の構成ソフトウェアをアンインストールしたときに，必要に応じてアンインストールされます。ただし，日立トレース共通ライブラリのアンインストールに失敗してメッセージが表示された場合には，コマンドを実行して日立トレース共通ライブラリ単体でアンインストールすることもできます。
アンインストールするには，次のコマンドを実行します。

/opt/hitachi/HNTRLib2/etc/hntr2setup

メニューが表示されるので，通常アンインストールは「9」を，強制アンインストールは「0」を選択してください。

7.2.3　Component Container管理者の設定（UNIXの場合）

UNIXの場合，サーバのセットアップ，起動と停止などはスーパーユーザで実施しますが，スーパーユーザ以外の一般ユーザでも権限を与えることで実施できるようになります。このユーザをComponent Container管理者といいます。これによって，スーパーユーザ以外のユーザでもシステムを構築，運用できるようになります。

注意

Component Container管理者の設定後，Component Container管理者が実施できる操作は，一部の操作を除き，スーパーユーザでは操作できなくなるので注意してください。

Component Container管理者が実施できる操作，Component Container管理者の設定に関する注意事項について説明します。

＜この項の構成＞

(1)　Component Container管理者が実施できる操作

(2)　Component Container管理者の設定および運用に関する注意事項

(1)　Component Container管理者が実施できる操作

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

表7-2　Component Container管理者の設定がある場合に実施できる操作

操作
スーパーユーザ
Component Container管理者

Cosminexus Component Containerのインストール
○
×

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

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

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

リダイレクタの設定
×
○

J2EEサーバまたはバッチサーバの起動／停止
（cjstartsvコマンド，cjstopsvコマンド）
×
○

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

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

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

バッチアプリケーションの実行（cjexecjobコマンド）※
○
○

バッチアプリケーションの強制停止（cjkilljobコマンド）※
○
○

バッチアプリケーション情報の一覧表示（cjlistjobコマンド）※
○
○

（凡例）○：実行できます。　×：実行できません。

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

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

参考

Component Container管理者を設定していても，運用管理コマンドの実行には影響ありません。

Management Serverのセットアップ時に設定した管理ユーザIDで，システム運用時の操作およびコマンドを実行できます。

(2)　Component Container管理者の設定および運用に関する注意事項

Component Container管理者の設定，およびComponent Container管理者による運用に関する注意事項を次に示します。

Component Container管理者のアカウント
Component Container管理者のアカウントは，Cosminexus Component Containerをインストールするホストに一つだけしか登録できないため，複数のアカウントをComponent Container管理者として登録できません。なお，Component Container管理者として使用できるアカウントは，OSにログインできるアカウントに限定されます。

Component Container管理者の管理対象のサーバ
cjsetupコマンドでセットアップするJ2EEサーバやバッチサーバだけでなく，インストール時にデフォルトでセットアップされるホスト名のサーバについても，Component Container管理者が所有者となります。サーバごとに異なるComponent Container管理者を設定することはできません。

Component Container管理者で運用する場合のポート番号の変更
Component Container管理者でCORBAネーミングサービスを起動する場合（インプロセスで起動する場合も含みます）には，簡易構築定義ファイルでポート番号の設定を変更します。論理J2EEサーバ（j2ee-server）または論理SFOサーバ（sfo-server）の<configuration>タグ内に，ejbserver.naming.portパラメタで，ポート番号に1,024番以上を設定してください。CORBAネーミングサービスをデフォルトのポート番号（900番），または0～1,023番のポート番号で起動する場合には，スーパーユーザで手動起動してください。
なお，root権限を持たないComponent Container管理者では，0～1,023番のポート番号を開けません。このため，Component Container管理者を設定して運用する場合には，CORBAネーミングサービス以外のポート番号についても，1,024番以上に変更してください。

Component Container管理者の変更
Component Container管理者を設定していた場合は，上書きインストール後またはアップグレードインストール後も同じユーザがComponent Container管理者となります。Component Container管理者を変更したい場合には，Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）の所有者およびグループを変更して，Component Container管理者をセットアップしてください。
Component Container管理者をスーパーユーザに戻す場合も，同様の方法で変更できます。

ディレクトリおよびファイルの所有者の変更
簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内では，次に示すディレクトリを変更して使用できます。

変更できるディレクトリ
指定方法

日立JavaVMログ出力先ディレクトリ
JavaVM起動パラメタを指定します。
JavaVM起動パラメタの指定内容を次に示します。

<param-name>タグ

add.jvm.arg

<param-value>タグ

-XX:HitachiJavaLog:<ディレクトリ名>

J2EEサーバまたはバッチサーバのログ出力ディレクトリ
ejb.server.log.directoryパラメタで指定します。

JSP用一時ディレクトリ
webserver.work.directoryパラメタで指定します。

Cosminexus TPBrokerのトレース出力先ディレクトリ
vbroker.orb.htc.tracePathパラメタで指定します。

これらのディレクトリを変更して使用している場合には，Component Container管理者のセットアップ後に，次のどちらかを実行してください。

各ディレクトリおよびファイルの所有者をComponent Container管理者に変更する。

各ディレクトリおよびファイルに，Component Container管理者の書き込み権限を設定する。

Component Container管理者を設定している場合のディレクトリの属性
Component Container管理者を設定した場合，次に示すディレクトリ下のサブディレクトリおよびファイルの属性（所有者/グループ）が「Component Container管理者/Component Container管理者グループ」に変更されます。

/opt/Cosminexus/CC

<作業ディレクトリ>/ejb/

<作業ディレクトリ>/web/

ただし，/opt/Cosminexus/CC下の一部のファイル（/opt/Cosminexus/CC/server/bin/cjenvsetup，/opt/Cosminexus/CC/server/bin/cjgetsysinfoや，インストールログなど）の属性は変更されません。

EJBクライアントアプリケーションのログ出力先ディレクトリのアクセス権の設定
Component Container管理者を設定している場合，Cosminexus Component Containerのインストールディレクトリ（/opt/Cosminexus/CC）以下のファイルおよびディレクトリの属性（所有者／グループ）が「Component Container管理者／Component Container管理者グループ」に変更されます。このため，EJBクライアントアプリケーションのログ出力先にデフォルトの/opt/Cosminexus/CC/client/logsを使用していて，かつComponent Container管理者とEJBクライアントアプリケーションの実行ユーザのアカウントが異なる場合，EJBクライアントアプリケーションのログ出力時にエラーとなることがあります。この場合，ログ出力先ディレクトリに出力されたログファイルのモードを，グループやほかのすべてのユーザに対して書き込みを許可するように設定してください。アクセス権の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.8.6　ログ出力先ディレクトリのアクセス権の設定」を参照してください。

Component Container管理者を設定している場合のメッセージ
Component Container管理者を設定している場合，アプリケーションおよび各種リソースをインポートするときに，インポート対象ファイルの読み取り権限がないために次のメッセージが出力されることがあります。このような場合は，インポート対象ファイルのアクセス権を確認してください。
アクセス権の設定が不正な場合，メッセージに，KDJE37324-Eが出力されます。

7.2.4　C++ライブラリのバージョン指定（Linuxの場合）

Linuxの場合，プロセス内で使用するC++ライブラリのバージョンを指定します。使用できるC++ライブラリのバージョンは，Linuxのバージョンおよびx64ネイティブ版を使用するかどうかで異なります。

Red Hat Enterprise Linux 4またはRed Hat Enterprise Linux 5の場合

x64ネイティブ版を使用するとき
libstdc++.so.6を使用します。

x64ネイティブ版以外を使用するとき
libstdc++.so.5またはlibstdc++.so.6を使用します。

Red Hat Enterprise Linux Server 6の場合
libstdc++.so.6を使用します。

libstdc++ライブラリのバージョンは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，cpp.library.versionパラメタで指定します。

x64ネイティブ版以外を使用する場合，デフォルトでは，cpp.library.versionパラメタはlibstdc++.so.5を使用する設定になっています。このため，Red Hat Enterprise Linux 4またはRed Hat Enterprise Linux 5の場合に，x64ネイティブ版以外でlibstdc++.so.6を使用するときは，cpp.library.versionパラメタの設定を次のように変更する必要があります。また，Red Hat Enterprise Linux Server 6の場合は，使用できるC++ライブラリのバージョンがlibstdc++.so.6だけであるため，cpp.library.versionパラメタの設定を必ず次のように変更してください。

libstdc++.so.6を使用する場合の設定

<param>
 <param-name>cpp.library.version</param-name>
 <param-value>6</param-value>
</param>

なお，簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注意

cpp.library.versionキーに「5」または「6」以外の数字を指定した場合は，メッセージKDJE40056-Eが出力されます。

参考

アプリケーションサーバでは，次に示すプロセス内でC++ライブラリをロードします。

cjstartsvプロセス（J2EEサーバまたはバッチサーバの起動）

cjclstartapプロセス（EJBクライアントアプリケーションの開始）

cjstartwebプロセス（Webコンテナサーバの起動）

7.2.5　アプリケーションサーバでサポートしているシンボリックリンク（UNIXの場合）

UNIXの場合，次のディレクトリのシンボリックリンクをサポートしています。

/opt/Cosminexus/CC

/opt/Cosminexus/CCR

/opt/Cosminexus/manager

/opt/Cosminexus/c4web

/opt/Cosminexus/CWC

ただし，これらのディレクトリより下位のディレクトリのシンボリックリンクは未サポートとなります。

7.3　環境変数の設定

各サーバで設定する環境変数は，製品の種類によって異なります。ここでは，アプリケーションサーバ，運用管理サーバなどApplication Serverをインストールしたサーバマシンで設定する環境変数について説明します。また，論理サーバの環境変数についても説明します。

参考

アプリケーションサーバのオプション製品の環境変数については，次のマニュアルまたは個所を参照してください。

uCosminexus Clientの場合
マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「付録A.2　インストール手順」

Web Redirectorの場合
マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「付録D.2　環境変数の設定」

uCosminexus Operatorの場合
「付録G.2　環境変数の設定（uCosminexus Operator）」

＜この節の構成＞

7.3.1　環境変数の設定の要否

7.3.2　環境変数の詳細

7.3.3　論理サーバの環境変数

7.3.1　環境変数の設定の要否

ここでは，Application Serverの環境変数について，設定の要否を次のシステムごとに説明します。

J2EEアプリケーションを実行するシステム

バッチアプリケーションを実行するシステム

＜この項の構成＞

(1)　J2EEアプリケーションを実行するシステムで設定する環境変数

(2)　バッチアプリケーションを実行するシステムで設定する環境変数

(1)　J2EEアプリケーションを実行するシステムで設定する環境変数

J2EEアプリケーションを実行するシステムで設定する環境変数について，OSごとに説明します。設定する環境変数は，構築するシステムでCTMを使用するかどうかによって異なります。環境変数の設定方法については，OSのドキュメントを参照してください。

(a)　Windowsの場合

Windowsの場合に設定する環境変数と設定値を次の表に示します。環境変数の詳細については，「7.3.2　環境変数の詳細」を参照してください。

表7-3　設定する環境変数と設定値（Windowsの場合）

環境変数名 | 設定値 | 環境変数の設定要否
CTMを使用しない場合 | CTMを使用する場合
PATH | <Cosminexusのインストールディレクトリ>¥jdk¥bin※1 | ○ | ○
<Cosminexusのインストールディレクトリ>¥TPB¥bin | ○ | ○
<Cosminexusのインストールディレクトリ>¥PRF¥bin | ○ | ○
<ProgramFiles>¥Common Files¥Hitachi※2 | ▲ | ▲
<sshコマンドを格納したパス>※3 | △ | △
TPDIR | <Cosminexusのインストールディレクトリ>¥TPB | ○ | ○
VBROKER_ADM | <Cosminexusのインストールディレクトリ>¥TPB¥adm※4 | ○ | ○
PRFSPOOL | <Cosminexusのインストールディレクトリ>¥PRF¥spool | ▲ | ▲
OSAGENT_PORT | 14000※4 | － | △
CTMDIR | <Cosminexusのインストールディレクトリ>¥CTM | － | ○
CTMSPOOL | %CTMDIR%¥spool | － | △
TZ | JST-9※4 | ○ | ○

（凡例）

○：設定が必要です。

▲：インストーラによって設定されるため，設定は不要です。

△：システム環境に応じて設定が必要です。

－：設定は不要です。

注※1　CORBAネーミングサービスを手動起動する場合は，環境変数「PATH」の先頭に指定してください。

注※2　<ProgramFiles>¥Common Files¥Hitachiは，デフォルトではインストーラによってシステム環境変数に設定されます。なお，<ProgramFiles>は，通常，システム環境変数%ProgramFiles%に設定されているディレクトリのことです。

注※3　負荷分散機を使用する場合に，Management Serverが稼働するサーバマシンで設定します。

注※4　通常は，この値を設定してください。ほかの値も設定できます。

注意

CLASSPATHは無効です。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

(b)　UNIXの場合

UNIXの場合に設定する環境変数と設定値を次の表に示します。環境変数の詳細については，「7.3.2　環境変数の詳細」を参照してください。なお，AIXの場合は，ここで説明する環境変数のほかに，AIX固有の環境変数を設定する必要があります。AIX固有の環境変数については，「(1)(c)　AIXの場合」を参照してください。

表7-4　設定する環境変数と設定値（UNIXの場合）

環境変数名 | 設定値 | 環境変数の設定要否
CTMを使用しない場合 | CTMを使用する場合
LIBPATH，LD_LIBRARY_PATH※1 | /opt/Cosminexus/TPB/lib | ○ | ○
/opt/Cosminexus/PRF/lib | ○ | ○
/opt/Cosminexus/CTM/lib | － | ○
/opt/hitachi/common/lib | ○ | ○
CSCCFJ_SERVER_HOME | /opt/Cosminexus/CC | ○ | ○
PATH | /opt/Cosminexus/jdk/bin※2 | ○ | ○
/opt/Cosminexus/TPB/bin | ○ | ○
/opt/Cosminexus/PRF/bin | ○ | ○
/bin | ○ | ○
/usr/bin | ○ | ○
<sshコマンドを格納したパス>※3 | △ | △
TPDIR | /opt/Cosminexus/TPB | ○ | ○
VBROKER_ADM | /opt/Cosminexus/TPB/adm※4 | ○ | ○
PRFSPOOL | /opt/Cosminexus/PRF/spool | ○ | ○
OSAGENT_PORT | 14000※4 | － | △
CTMDIR | /opt/Cosminexus/CTM | － | ○
CTMSPOOL | /opt/Cosminexus/CTM/spool | － | △
TZ | JST-9※4 | ○ | ○

（凡例）

○：設定が必要です。

△：システム環境に応じて設定が必要です。

－：設定は不要です。

注※1　OSによって，使用する環境変数名が異なります。

LIBPATH：AIXの場合

LD_LIBRARY_PATH：HP-UX（IPF），Linux，またはSolarisの場合

注※2　CORBAネーミングサービスを手動起動する場合は，環境変数「PATH」の先頭に指定してください。

注※3　負荷分散機を使用する場合に，Management Serverが稼働するサーバマシンで設定します。

注※4　通常は，この値を設定してください。ほかの値も設定できます。

注意

CLASSPATHは無効です。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

(c)　AIXの場合

OSがAIXの場合は，「(1)(b)　UNIXの場合」で説明している環境変数のほかに，AIX固有の環境変数も設定する必要があります。AIX固有の環境変数を次の表に示します。UNIXの場合に設定する環境変数については，「(1)(b)　UNIXの場合」を参照してください。

表7-5　AIX固有の環境変数

環境変数名
設定値
説明

PSALLOC※1 ※2
early
メモリ確保時に必要なページングスペースをすぐに確保する設定にします。

NODISCLAIM※1 ※2
true
free()に対するコールの処理方法として，nodisclaim()の発行抑止をする設定にします。

AIXTHREAD_SCOPE※2
S
コンテンションの有効範囲として，システム・ベースのコンテンションの有効範囲（1:1）を設定します。

AIXTHREAD_MUTEX_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

AIXTHREAD_RWLOCK_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

AIXTHREAD_COND_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

EXTSHM
ON
プロセス空間の共有メモリ領域数の制限をなくす設定にします。

LDR_CNTRL（任意）
MAXDATA=0x40000000
カーネルの従来の区分化より大きいデータエリアを扱えるようにするための設定です。必要に応じて設定してください。
「0x40000000」は，未設定時のJ2EEサーバのmalloc領域サイズ（単位：バイト）です。mmap領域のJavaHeapや共用メモリなどを確保するためには，指定サイズを小さくするなど調整してください。

注※1　システム構築の初期段階でメモリの見積もりができていない場合は，Hitachi Web Serverに対してPSALLOCにearly，およびNODISCLAIMにtrueを設定しないでください。設定した場合，ページングスペースが十分に確保できなくなり，プロセスの起動に失敗することがあります。

注※2　Management Server利用時，これらの環境変数に対してユーザ側で値を設定していない場合には，運用管理エージェントに「設定値」に示した値が自動的に設定されます。なお，ユーザが値を設定している場合は，ユーザが設定した値が有効になります。

(2)　バッチアプリケーションを実行するシステムで設定する環境変数

バッチアプリケーションを実行するシステムで設定する環境変数について，OSごとに説明します。設定する環境変数は，構築するシステムでCTMを使用するかどうかによって異なります。環境変数の設定方法については，OSのドキュメントを参照してください。

(a)　Windowsの場合

Windowsの場合に設定する環境変数と設定値を次の表に示します。環境変数の詳細については，「7.3.2　環境変数の詳細」を参照してください。

表7-6　設定する環境変数と設定値（Windowsの場合）

環境変数名 | 設定値 | 環境変数の設定要否
CTMを使用しない場合 | CTMを使用する場合
PATH | <Cosminexusのインストールディレクトリ>¥jdk¥bin※1 | ○ | ○
<Cosminexusのインストールディレクトリ>¥TPB¥bin | ○ | ○
<Cosminexusのインストールディレクトリ>¥PRF¥bin | ○ | ○
<ProgramFiles>¥Common Files¥Hitachi※2 | ▲ | ▲
TPDIR | <Cosminexusのインストールディレクトリ>¥TPB | ○ | ○
VBROKER_ADM | <Cosminexusのインストールディレクトリ>¥TPB¥adm※3 | ○ | ○
PRFSPOOL | <Cosminexusのインストールディレクトリ>¥PRF¥spool | ▲ | ▲
OSAGENT_PORT | 14000※3 | － | △
CTMDIR | <Cosminexusのインストールディレクトリ>¥CTM | － | ○
CTMSPOOL | %CTMDIR%¥spool | － | △
TZ | JST-9※3 | ○ | ○

（凡例）

○：設定が必要です。

▲：インストーラによって設定されるため，設定は不要です。

△：システム環境に応じて設定が必要です。

－：設定は不要です。

注※1　CORBAネーミングサービスを手動起動する場合は，環境変数「PATH」の先頭に指定してください。

注※2　<ProgramFiles>¥Common Files¥Hitachiは，デフォルトではインストーラによってシステム環境変数に設定されます。なお，<ProgramFiles>は，通常，システム環境変数%ProgramFiles%に設定されているディレクトリのことです。

注※3　通常は，この値を設定してください。ほかの値も設定できます。

注意

CLASSPATHは無効です。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

(b)　UNIXの場合

UNIXの場合に設定する環境変数と設定値を次の表に示します。環境変数の詳細については，「7.3.2　環境変数の詳細」を参照してください。なお，AIXの場合は，ここで説明する環境変数のほかに，AIX固有の環境変数を設定する必要があります。AIX固有の環境変数については，「(2)(c)　AIXの場合」を参照してください。

表7-7　設定する環境変数と設定値（UNIXの場合）

環境変数名 | 設定値 | 環境変数の設定要否
CTMを使用しない場合 | CTMを使用する場合
LIBPATH，LD_LIBRARY_PATH※1 | /opt/Cosminexus/TPB/lib | ○ | ○
/opt/Cosminexus/PRF/lib | ○ | ○
/opt/Cosminexus/CTM/lib | － | ○
/opt/hitachi/common/lib | ○ | ○
CSCCFJ_SERVER_HOME | /opt/Cosminexus/CC | － | －
PATH | /opt/Cosminexus/jdk/bin※2 | ○ | ○
/opt/Cosminexus/TPB/bin | ○ | ○
/opt/Cosminexus/PRF/bin | ○ | ○
/bin | ○ | ○
TPDIR | /opt/Cosminexus/TPB | ○ | ○
VBROKER_ADM | /opt/Cosminexus/TPB/adm※3 | ○ | ○
PRFSPOOL | /opt/Cosminexus/PRF/spool | ○ | ○
OSAGENT_PORT | 14000※3 | － | △
CTMDIR | /opt/Cosminexus/CTM | － | ○
CTMSPOOL | /opt/Cosminexus/CTM/spool | － | △
TZ | JST-9※3 | ○ | ○

（凡例）

○：設定が必要です。

△：システム環境に応じて設定が必要です。

－：設定は不要です。

注※1　OSによって，使用する環境変数名が異なります。

LIBPATH：AIXの場合

LD_LIBRARY_PATH：HP-UX（IPF），Linux，またはSolarisの場合

注※2　CORBAネーミングサービスを手動起動する場合は，環境変数「PATH」の先頭に指定してください。

注※3　通常は，この値を設定してください。ほかの値も設定できます。

注意

CLASSPATHは無効です。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

(c)　AIXの場合

OSがAIXの場合は，「(2)(b)　UNIXの場合」で説明している環境変数のほかに，AIX固有の環境変数も設定する必要があります。AIX固有の環境変数を次の表に示します。UNIXの場合に設定する環境変数については，「(2)(b)　UNIXの場合」を参照してください。

表7-8　AIX固有の環境変数

環境変数名
設定値
説明

PSALLOC※1 ※2
early
メモリ確保時に必要なページングスペースをすぐに確保する設定にします。

NODISCLAIM※1 ※2
true
free()に対するコールの処理方法として，nodisclaim()の発行抑止をする設定にします。

AIXTHREAD_SCOPE※2
S
コンテンションの有効範囲として，システム・ベースのコンテンションの有効範囲（1:1）を設定します。

AIXTHREAD_MUTEX_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

AIXTHREAD_RWLOCK_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

AIXTHREAD_COND_DEBUG※2
OFF
デバッグリストを使用しない設定にします。

EXTSHM
ON
プロセス空間の共有メモリ領域数の制限をなくす設定にします。

LDR_CNTRL（任意）
MAXDATA=0x40000000
カーネルの従来の区分化より大きいデータエリアを扱えるようにするための設定です。必要に応じて設定してください。
「0x40000000」は，未設定時のJ2EEサーバのmalloc領域サイズ（単位：バイト）です。mmap領域のJavaHeapや共用メモリなどを確保するためには，指定サイズを小さくするなど調整してください。

注※1　システム構築の初期段階でメモリの見積もりができていない場合は，Hitachi Web Serverに対してPSALLOCにearly，およびNODISCLAIMにtrueを設定しないでください。設定した場合，ページングスペースが十分に確保できなくなり，プロセスの起動に失敗することがあります。

注※2　Management Server利用時，これらの環境変数に対してユーザ側で値を設定していない場合には，運用管理エージェントに「設定値」に示した値が自動的に設定されます。なお，ユーザが値を設定している場合は，ユーザが設定した値が有効になります。

7.3.2　環境変数の詳細

ここでは，各システムで設定する環境変数の詳細を説明します。

＜この項の構成＞

(1)　LIBPATH，またはLD_LIBRARY_PATH

(2)　CSCCFJ_SERVER_HOME

(3)　PATH

(4)　TPDIR

(5)　VBROKER_ADM

(6)　PRFSPOOL

(7)　OSAGENT_PORT

(8)　CTMDIR

(9)　CTMSPOOL

(10)　TZ

(1)　LIBPATH，またはLD_LIBRARY_PATH

指定する環境変数はOSごとに異なります。

LIBPATH
AIXを使用している場合は，LIBPATHに指定します。

LD_LIBRARY_PATH
HP-UX（IPF）を使用している場合，Linuxを使用している場合，およびSolarisを使用している場合は，LD_LIBRARY_PATHに指定します。

使用しているOSの環境変数に次のパスを指定してください。

/opt/Cosminexus/TPB/lib

/opt/Cosminexus/PRF/lib

/opt/Cosminexus/CTM/lib

/opt/hitachi/common/lib

なお，「/opt/Cosminexus/CTM/lib」は，「7.3.1(1)(b)　UNIXの場合」および「7.3.1(2)(b)　UNIXの場合」のCTMを使用する場合に必要です。

(2)　CSCCFJ_SERVER_HOME

Cosminexus Component Containerのインストールディレクトリとして，次の値を指定してください。

/opt/Cosminexus/CC

(3)　PATH

次のパスを指定してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥jdk¥bin※1

<Cosminexusのインストールディレクトリ>¥TPB¥bin

<Cosminexusのインストールディレクトリ>¥PRF¥bin

<ProgramFiles>¥Common Files¥Hitachi※2

UNIXの場合

/opt/Cosminexus/jdk/bin※1

/opt/Cosminexus/TPB/bin

/opt/Cosminexus/PRF/bin

/bin

注※1

CORBAネーミングサービスを手動起動する場合は，環境変数「PATH」の先頭に指定してください。

注※2

デフォルトではインストーラによってシステム環境変数に設定されます。なお，<ProgramFiles>は，通常，システム環境変数%ProgramFiles%に設定されているディレクトリのことです。

なお，CTMドメインマネジャやCTMを起動するときには，パフォーマンストレーサのパス（<Cosminexusのインストールディレクトリ>¥PRF¥bin）を同時に設定しないでください。パフォーマンストレーサのパスを同時に設定すると，CTMがパフォーマンストレーサのライブラリをロードした場合にエラーとなり，起動できません。

(4)　TPDIR

Cosminexus TPBrokerのインストールディレクトリとして，次の値を指定してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥TPB

UNIXの場合

/opt/Cosminexus/TPB

(5)　VBROKER_ADM

ログ出力先などの管理ディレクトリを指定してください。通常，次の値を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥TPB¥adm

UNIXの場合

/opt/Cosminexus/TPB/adm

(6)　PRFSPOOL

パフォーマンストレーサ（PRFデーモン）の実行環境ディレクトリを指定してください。デフォルトのディレクトリがインストーラによって作成されます。

デフォルトのディレクトリを次に示します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥PRF¥spool

UNIXの場合

/opt/Cosminexus/PRF/spool

デフォルトのディレクトリを変更する場合は，パフォーマンストレーサの実行環境ディレクトリを作成して，この環境変数に指定してください。なお，環境変数が指定されていない場合，パフォーマンストレーサは動作しません。

(7)　OSAGENT_PORT

スマートエージェント（osagent）が使用するポート番号を指定してください。5,001～65,535の整数で指定します。デフォルトは，「14000」です。

(8)　CTMDIR

CTMのインストールディレクトリとして，次の値を指定してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CTM

UNIXの場合

/opt/Cosminexus/CTM

(9)　CTMSPOOL

CTMの実行環境ディレクトリを指定してください。デフォルトのディレクトリがインストーラによって作成されます。

デフォルトのディレクトリを次に示します。

Windowsの場合

%CTMDIR%¥spool

UNIXの場合

/opt/Cosminexus/CTM/spool

デフォルトのディレクトリを変更する場合は，CTMの実行環境ディレクトリを作成して，この環境変数に指定してください。

(10)　TZ

タイムゾーンを設定してください。通常，「JST-9」を指定します。

7.3.3　論理サーバの環境変数

Management Serverを使用する場合には，次の定義個所で論理サーバに環境変数が設定できます。

簡易構築定義ファイルもしくは構成変更定義ファイルのuser.env.variableパラメタ，または運用管理ポータルの［環境変数の設定］画面

adminagent.xml（運用管理エージェント設定ファイル）

OSの環境変数（Windowsの場合はシステム環境変数，UNIXの場合は運用管理エージェントを起動するシェルでの環境変数）

同一の環境変数をそれぞれの定義個所で設定している場合は，1.，2.，3.の順序で設定値が優先され，論理サーバに設定されます。

2.（adminagent.xml）には，インストール時点で環境変数が設定されています。3.（OSの環境変数）で，2.（adminagent.xml）に設定されている環境変数を設定しても，設定は有効になりません。このため，論理サーバの環境変数は，1.（簡易構築定義ファイル，構成変更定義ファイル，運用管理ポータル），または2.（adminagent.xml）で設定することをお勧めします。インストール時点で2.（adminagent.xml）に設定されている環境変数については，「4.8.8　Management Serverが自動で設定する論理サーバの環境変数」を参照してください。

7.4　使用リソースの設定

構築されたシステムが動作するために，OSやデータベースなどのホスティング環境の設定が必要な場合があります。構築するシステムが使用するリソースと，各リソースの見積もりと設定については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」または「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

7.5　データベースを使用するための設定

データベースとして，HiRDB，またはOracleを使用する場合に必要な設定について説明します。ここでは，HiRDB Type4 JDBC Driverを使用してHiRDBに接続する場合，およびOracle JDBC Thin Driverを使用してOracleに接続する場合に必要な設定を，データベースごとに説明します。

注意

バッチサーバでは，グローバルトランザクションは使用できません。また，バッチアプリケーションを実行するシステムの場合は，記述中にある「J2EEサーバ」を「バッチサーバ」に置き換えてお読みください。

データベースにXDM/RD E2またはSQL Serverを使用する場合の設定については，「付録C　データベース（XDM/RD E2・SQL Server）の設定」を参照してください。

＜この節の構成＞

7.5.1　HiRDBの設定（HiRDB Type4 JDBC Driverの場合）

7.5.2　Oracleの設定（Oracle JDBC Thin Driverの場合）

7.5.1　HiRDBの設定（HiRDB Type4 JDBC Driverの場合）

HiRDB Type4 JDBC Driverを使用してHiRDBに接続する場合の設定について説明します。なお，データベースとしてHiRDBを使用する場合は，HiRDBをインストールして初期設定を済ませておいてください。詳細については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。

ここでは，HiRDB Type4 JDBC Driverを使用して，HiRDBでJ2EEリソースを扱う場合に必要な次の設定について説明します。

HiRDB Type4 JDBC Driverの準備

HiRDBクライアント環境変数グループ設定ファイルの作成

タイムアウトの設定

＜この項の構成＞

(1)　HiRDB Type4 JDBC Driverの準備

(2)　HiRDBクライアント環境変数グループ設定ファイルの作成

(3)　タイムアウトの設定

(1)　HiRDB Type4 JDBC Driverの準備

ここでは，HiRDB Type4 JDBC Driverの準備について説明します。

HiRDB Type4 JDBC DriverのJARファイル（pdjdbc2.jar）を用意します。pdjdbc2.jarは，次の製品に含まれています。

HiRDB Server Version 9

HiRDB Server with Additional Function Version 9

HiRDB/Run Time Version 9

HiRDB/Developer's Kit Version 9

HiRDB Developer's Suite Version 9

HiRDB/Parallel Server Version 8

HiRDB/Single Server Version 8

HiRDB/Run Time Version 8

HiRDB/Developer's Kit Version 8

これらの製品でのpdjdbc2.jarの格納場所は，マニュアル「HiRDB UAP開発ガイド」を参照してください。

簡易構築定義ファイルに，HiRDB Type4 JDBC DriverのJARファイル（pdjdbc2.jar）のパスを設定します。
簡易構築定義ファイルを作成するときに，物理ティアの定義（<tier>タグの定義）のJ2EEサーバの定義で，<configuration>タグに次の設定を追加してください。

<param-name>タグの指定値 | <param-value>タグの指定値
add.class.path | <pdjdbc2.jarのクラスパス>

簡易構築定義ファイルの作成については，「8.4　システムの構成定義」または「10.2　システムの構成定義」を参照してください。設定内容の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　HiRDBクライアント環境変数グループ設定ファイルの作成

HiRDBクライアント環境変数グループを使用するには，HiRDBのクライアント環境変数グループの設定ファイルを作成します。この場合，DB Connectorのプロパティ定義内のHiRDBクライアント環境変数グループ名を指定する部分には，ここで作成した設定ファイルのパスを指定してください。設定ファイルの作成方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

なお，グローバルトランザクションを使用する場合には，必ずHiRDBクライアント環境変数グループを設定する必要があります。グローバルトランザクションを使用しない場合には，HiRDBクライアント環境変数グループの使用は任意です。

(3)　タイムアウトの設定

HiRDBのタイムアウトは，次に示すHiRDBのクライアント環境変数を，DB ConnectorのenvironmentVariablesプロパティまたはHiRDBのクライアント環境変数グループの設定ファイルに追加することで設定します。

PDSWAITTIME

PDCWAITTIME

なお，コネクション確立時のタイムアウトは，DB ConnectorのloginTimeoutプロパティに設定します。ただし，HiRDB Type4 JDBC DriverのsetLoginTimeoutメソッドに値を設定した場合でも，ログイン時のタイムアウトができないことがあります。

DB Connectorのプロパティは，システム構築前，またはシステム構築後のリソースアダプタのデプロイ時に設定します。リソースアダプタのデプロイについては，「8.8.3　リソースアダプタのインポートと開始」または「10.6.2　リソースアダプタのインポートと開始」を参照してください。

また，タイムアウトの設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.6.5　データベースでのタイムアウトを設定する」を参照してください。DB Connectorのプロパティの設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。

7.5.2　Oracleの設定（Oracle JDBC Thin Driverの場合）

Oracle JDBC Thin Driverを使用してOracleに接続する場合の設定について説明します。なお，データベースとしてOracleを使用する場合は，Oracleをインストールして初期設定を済ませておいてください。詳細については，Oracleのマニュアルを参照してください。

ここでは，Oracle JDBC Thin Driverを使用して，OracleでJ2EEリソースを扱う場合に必要なデータベース側での設定と，J2EEサーバ側での設定について説明します。また，Oracleのタイムアウトの設定についても説明します。

＜この項の構成＞

(1)　データベース側での設定

(2)　J2EEサーバ側での設定

(3)　タイムアウトの設定

(4)　動的パフォーマンスビューの参照権の設定

(1)　データベース側での設定

ここでは，Oracle JDBC Thin Driverを使用する場合に，データベース側で必要な設定について説明します。詳細については，Oracleのマニュアルを参照してください。

Oracleへの接続でグローバルトランザクションを使用する場合には，Oracleの接続ユーザにトランザクションリカバリを行うための権限を付与する必要があります。

●付与する権限

SYS.DBA_PENDING_TRANSACTIONSのSELECT権限

FORCE_ANY_TRANSACTION権限

SYS.DBMS_SYSTEMをEXECUTEする権限（Oracle JDBC Thin Driver 9.2.0.6，10.1.0.3.0以降を使用する場合）

●権限の付与の方法

次のどちらかの方法で権限を付与します。

Oracle Enterprise Managerコンソールを使用する

sqlplusを使用する

次に，Oracle 9.2.0で権限を付与する場合の例を示します。なお，権限を付与する方法の詳細については，Oracleのマニュアルを参照してください。

Oracle Enterprise Managerコンソールを使用する場合の例
Oracle Enterprise Managerコンソールを使用して権限を付与する場合の手順を次に示します。

sysユーザでデータベースに接続します。

［セキュリティ］－［ユーザー］－［<権限を付与するユーザ名>］－［オブジェクト権限］を開きます。

［SYS］－［ビュー］－［DBA_PENDING_TRANSACTIONS］を選択して，SELECT権限を付与します。

sqlplusを使用する場合の例
sqlplusを使用して権限を付与する場合の手順を次に示します。

sysユーザでデータベースに接続します。

次のSQL文を発行します。
grant select on DBA_PENDING_TRANSACTIONS to <権限を付与するユーザ名>;
commit;

(2)　J2EEサーバ側での設定

ここでは，Oracle JDBC Thin Driverを使用する場合に，J2EEサーバ側で必要な設定について説明します。なお，Oracle JDBC Thin Driverを使用する場合，J2EEサーバに追加する環境変数はありません。

アプリケーションサーバがサポートするバージョンの，Oracle JDBC Thin DriverのJARファイルを入手してください。Oracleクライアントのインストールディレクトリ下の「jdbc/lib/ojdbc14.jar」，「jdbc/lib/ojdbc14_g.jar」，「jdbc/lib/ojdbc5.jar」，「jdbc/lib/ojdbc5_g.jar」，「jdbc/lib/ojdbc6.jar」および「jdbc/lib/ojdbc6_g.jar」が該当するJARファイルです。

このとき，Oracle JDBC Thin Driverのバージョンは，パッチレベル（パッチ番号）まで一致している必要があります。例えば，Oracle JDBC Thin Driverのバージョンが9.2.0.5の場合は，「9.2.0」がバージョン番号で，末尾の「5」がパッチ番号になります。

Oracle JDBC Thin Driverの入手方法の具体例としては，J2EEサーバを動作させるマシンにOracleクライアントをインストールする方法があります。Oracleクライアントのインストール手順の概略を次に示します。

J2EEサーバを動作させるマシンに，アプリケーションサーバがサポートするバージョン番号のOracleクライアントをインストールします。
このとき，Oracle JDBC Thin Driverもインストールされます。

アプリケーションサーバがサポートするパッチレベル（パッチ番号）のパッチを適用します。

簡易構築定義ファイルに，Oracle JDBC Thin DriverのJARファイルのパスを指定します。
簡易構築定義ファイルを作成するときに，物理ティアの定義（<tier>タグの定義）のJ2EEサーバの定義で，<configuration>タグに次の設定を追加してください。なお，設定する値はOracleのバージョンによって異なります。

Oracleのバージョン | <param-name>タグの指定値 | <param-value>タグの指定値
Oracle9i | add.class.path | <ojdbc14.jarのクラスパス>
Oracle10g
Oracle11g | JDK 5 | <ojdbc5.jarのクラスパス>
JDK 6 | <ojdbc6.jarのクラスパス>

注　add.class.pathに指定できるOracleのJDBCドライバは一つだけです。Oracle9iおよびOracle10gのJDBCドライバ（ojdbc14.jarまたはojdbc14_g.jar）と，Oracle11gのJDBCドライバ（ojdbc5.jarもしくはojdbc5_g.jar，またはojdbc6.jarもしくはojdbc6_g.jar）の両方は指定できません。なお，ojdbc14.jar，ojdbc5.jarおよびojdbc6.jarの代わりにojdbc14_g.jar，ojdbc5_g.jarまたはojdbc6_g.jarのクラスパスを指定すると，Oracle JDBC Thin Driverの内部トレースがDB Connectorのログファイルに出力されます。

簡易構築定義ファイルの作成については，「8.4　システムの構成定義」または「10.2　システムの構成定義」を参照してください。設定内容の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

J2EEサーバに，Oracle JDBC Thin Driver用のDB Connectorをインポートします。
DB Connectorのインポートについては，「8.8.3　リソースアダプタのインポートと開始」または「10.6.2　リソースアダプタのインポートと開始」を参照してください。
Oracle JDBC Thin Driver用のDB Connectorは，2種類あります。トランザクションの管理方法によって，次のどちらかのファイルを選択してください。

DBConnector_Oracle_CP.rar

ローカルトランザクション，またはトランザクション管理なしで使用する場合（トランザクションのサポートレベルにLocalTransactionまたはNoTransactionを指定する場合）に選択します。Oracle JDBC Thin DriverのConnectionPoolDataSourceを使用してデータベースに接続します。

DBConnector_Oracle_XA.rar

グローバルトランザクションを使用する場合（トランザクションのサポートレベルにXATransactionを指定する場合）に選択します。Oracle JDBC Thin DriverのXADataSourceを使用してデータベースに接続します。

トランザクションの管理方法の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4　トランザクション管理」を参照してください。

(3)　タイムアウトの設定

Oracleのサーバ定義のDISTRIBUTED_LOCK_TIMEOUTパラメタに設定します。

なお，このほかXAOpenStringのSesTmパラメタの設定がタイムアウトに影響しますが，このパラメタはチューニングできません。

詳細については，次の個所またはマニュアルを参照してください。

マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.6.5　データベースでのタイムアウトを設定する」

マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.6.7　タイムアウトを設定するチューニングパラメタ」

Oracleのマニュアル

(4)　動的パフォーマンスビューの参照権の設定

Oracleに接続するユーザは，動的パフォーマンスビューの参照権を持っている必要があります。次のどちらかの方法でOracleに接続するユーザに動的パフォーマンスビューの参照権を設定してください。

「GRANT SELECT_CATALOG_ROLE TO <ユーザ名>;」を実行する。

「GRANT SELECT ON V_$INSTANCE TO <ユーザ名>;」，「GRANT SELECT ON V_$PROCESS TO <ユーザ名>;」，および「GRANT SELECT ON V_$SESSION TO <ユーザ名>;」を実行する。

7.6　Management Serverのセットアップと環境設定

ここでは，Management Serverを使用するために必要な次の設定について説明します。

Management Serverのセットアップ

Management Serverの環境設定

Management Serverの動作環境の設定

運用管理エージェントによる論理サーバの監視に関する設定

管理ユーザアカウントを設定しない場合の設定

＜この節の構成＞

7.6.1　Management Serverのセットアップ

7.6.2　Management Serverの環境設定

7.6.3　Management Serverの動作環境の設定

7.6.4　運用管理エージェントによる論理サーバの監視に関する設定

7.6.5　管理ユーザアカウントを設定しない場合の設定

7.6.1　Management Serverのセットアップ

Management Serverを初めて使用するホストでは，まず，Management Serverをセットアップしてください。一度セットアップしたホストでは，この作業は不要です。

Management Serverのセットアップには，mngsvrctlコマンドの引数setupを使用します。Management Serverを利用するユーザのアカウント情報（管理ユーザアカウント）は，Management Serverのセットアップ時にも設定できます。なお，管理ユーザアカウントの設定は任意です。管理ユーザアカウントを設定しない場合については，「7.6.5　管理ユーザアカウントを設定しない場合の設定」を参照してください。

また，mngsvrctlコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrctl（Management Serverの起動／停止／セットアップ）」を参照してください。

Management Serverのセットアップ時に，管理ユーザアカウントを設定する場合
セットアップ時に管理ユーザアカウントを設定する場合は，-uオプションと-pオプションでユーザのアカウント情報を指定します。なお，セットアップ時に設定した管理ユーザアカウントは，mngsvrctlコマンドで変更できます。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl setup <サーバ名> -u 管理ユーザID -p 管理ユーザパスワード

UNIXの場合
/opt/Cosminexus/manager/bin/mngsvrctl setup <サーバ名> -u 管理ユーザID -p 管理ユーザパスワード

ユーザID（cosmi_admin），パスワード（cosmi_admin_passwd）を設定して，Management Serverを起動する場合の例を，OSごとに示します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl setup -u cosmi_admin -p cosmi_admin_passwd

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl setup -u cosmi_admin -p cosmi_admin_passwd

Management Serverのセットアップだけを実施する場合
Management Serverのセットアップだけを実施する場合は，管理ユーザアカウントを設定するオプションを省略します。この場合，セットアップ完了後に，管理ユーザアカウントを設定してください。管理ユーザアカウントの設定方法については，「7.6.3　Management Serverの動作環境の設定」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl setup

UNIXの場合
/opt/Cosminexus/manager/bin/mngsvrctl setup

参考

mngsvrctlコマンドの使用方法は，引数の指定を省略すると表示できます。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl

UNIXの場合
/opt/Cosminexus/manager/bin/mngsvrctl

7.6.2　Management Serverの環境設定

Management Serverや運用管理エージェントのプロパティで，Management Serverの環境を設定してください。

＜この項の構成＞

(1)　Management Serverのプロパティの設定

(2)　運用管理エージェントのプロパティの設定

(1)　Management Serverのプロパティの設定

Management Serverのプロパティファイル（mserver.properties）で，Management Serverが使用するポート番号や，Management Serverへのアクセスを許可するホストなどを指定できます。

mserver.propertiesに指定するキーを次に示します。キーの詳細，およびここで説明していないキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。

adminagent.connector.comm.state.cache_max_time
運用管理エージェントとの通信状態をキャッシュする最大時間を指定します。

webserver.connector.ajp13.port
Management Server内部通信用ポート番号を指定します。

webserver.connector.http.port
Management Server接続HTTPポート番号を指定します。

webserver.shutdown.port
Management Server終了要求受信ポート番号を指定します。

webserver.connector.http.permitted.hosts
Management Serverへのアクセスを許可するホストおよび運用管理エージェント稼働ホストの，IPアドレスまたはホスト名を指定します。

mngsvr.myhost.name
Management Serverが稼働するホストに，論理サーバを配置するホストからアクセス可能なIPアドレス，またはそのIPアドレスを示すホスト名を指定します。Management Serverが稼働するホストが複数個のIPアドレスを持っていて，ホスト名が意図するIPアドレスに変換されないおそれがある場合に，このキーを指定します。

これらのキーのほかに，mserver.propertiesでは次の設定ができます。

snapshotログ収集や障害検知時コマンドによる資料取得のためのキーを設定できます。snapshotログ収集の設定，および障害検知時コマンドによる資料取得のための設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

3.3.1　障害検知時コマンドによる資料取得の設定（J2EEアプリケーションを実行するシステム）

3.3.2　障害検知時コマンドによる資料取得の設定（バッチアプリケーションを実行するシステム）

3.3.3　snapshotログ収集の設定（J2EEアプリケーションを実行するシステム）

3.3.4　snapshotログ収集の設定（バッチアプリケーションを実行するシステム）

管理ユーザアカウントを設定しないでManagement Serverにログインすることもできます。この場合，管理ユーザアカウントの省略機能を有効にします。機能の設定については，「7.6.5　管理ユーザアカウントを設定しない場合の設定」を参照してください。

また，必要に応じて，cmxserver.properties（サーバ設定プロパティファイル）で，Smart Composer機能で使用するコマンドの実行環境を設定します。

cmxserver.propertiesに指定するキーを次に示します。キーの詳細，およびここで説明していないキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.2　cmxserver.properties（サーバ設定プロパティファイル）」を参照してください。

cmx.max_wait_time
共通オプション-waitを指定して実行したコマンドに有効で，すでに実行しているコマンドの完了を待つときの最大待ち時間を指定します。デフォルトで，180秒が設定されています。

(2)　運用管理エージェントのプロパティの設定

運用管理エージェントのプロパティファイル（adminagent.properties）で，運用管理エージェントが使用するポート番号などを指定できます。

adminagent.adapter.port
運用管理エージェントがManagement Serverとの通信に使用するポート番号を指定します。

これらのキーのほかに，adminagent.propertiesでは，論理サーバの動作確認やsnapshotログの収集先などを設定できます。論理サーバの動作確認の設定については，「7.6.4　運用管理エージェントによる論理サーバの監視に関する設定」を参照してください。snapshotログの収集先の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

3.3.3　snapshotログ収集の設定（J2EEアプリケーションを実行するシステム）

3.3.4　snapshotログ収集の設定（バッチアプリケーションを実行するシステム）

7.6.3　Management Serverの動作環境の設定

mngsvrctlコマンドやManagement Serverのプロパティで，Management Serverを利用するユーザのアカウント情報，Management Serverが出力するログ情報など，Management Serverの動作環境を設定してください。

Management Serverの動作環境の設定内容を次の表に示します。

表7-9　Management Serverの動作環境の設定内容

設定項目
設定内容
設定の要否

管理ユーザアカウントの設定
Management Serverのセットアップ時に管理ユーザアカウントを設定していない場合は，mngsvrctlコマンドで引数setupを指定して，Management Serverを利用するユーザのアカウント情報を設定します。mngsvrctlコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrctl（Management Serverの起動／停止／セットアップ）」を参照してください。
○※

ログの設定
mserver.propertiesで，Management Serverが出力するログのログレベル，ファイル数，サイズなどを設定します。
次のキーを指定します。

com.cosminexus.mngsvr.log.levelキーに，Management Serverのログの出力レベルを指定します。

com.cosminexus.mngsvr.log.rotateキーに，Management Serverのログのファイル面数を指定します。

com.cosminexus.mngsvr.log.sizeキーに，Management Serverのログのファイルサイズを指定します。

△

開始時の設定
mserver.propertiesで，Management Serverを起動するときに，論理サーバを一括起動するかどうかを設定します。一括起動する場合には，この設定が必要です。
一括起動する設定については，「7.7　システムの起動と停止の設定」を参照してください。
△

性能解析トレース収集の設定
mserver.propertiesで，com.cosminexus.mngsvr.traceキーに，Management Serverで保持する性能解析トレースファイルの面数を設定します。
△

JP1連携の設定
mserver.propertiesで，com.cosminexus.mngsvr.jp1event.enabledキーに，Management Serverの障害情報（検知した障害や論理サーバの起動の通知など）をJP1イベントとして発行するかどうかを指定します。このほかに，com.cosminexus.mngsvr.jp1eventから始まるキーで，Management Serverの障害情報をJP1へ通知するための設定をします。JP1と連携する機能を利用する場合には，この設定が必要です。JP1との連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「12.　JP1と連携したシステムの運用」を参照してください。
△

（凡例）

○：設定します。

△：デフォルトの設定を変更する場合，特定の機能を使用する場合に設定します。

注※

Management Serverのセットアップ時に，管理ユーザアカウントを設定している場合は，設定不要です。ただし，セットアップ時に設定した管理ユーザアカウントを変更したい場合は，mngsvrctlコマンドを使用して再設定してください。

7.6.4　運用管理エージェントによる論理サーバの監視に関する設定

システムを運用する場合には，Management Serverの運用管理コマンド（mngsvrutil）を使用して論理サーバのステータスを確認することで，論理サーバの起動／停止状態がわかります。Management Serverで論理サーバを管理する場合には，運用管理エージェントが定期的に論理サーバのプロセス監視および動作確認を実施し，論理サーバのステータスをManagement Serverに通知します。運用管理エージェントが論理サーバの動作確認をするときのレベルや間隔の設定は変更できます。必要に応じて，論理サーバの動作確認に関する次の項目を設定してください。

論理サーバの動作確認レベルの設定

論理サーバの動作確認間隔の設定

論理サーバの動作確認タイムアウトの設定

論理サーバの動作確認リトライの設定

論理サーバの動作確認の開始時間の設定

Hitachi Web Serverの動作確認の設定

これらの項目は，運用管理エージェントの動作を設定するadminagent.propertiesで設定します。adminagent.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.2　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

参考

Management ServerでWebサーバの動作確認をする場合，動作確認用のログを通常のログ（エラーログ，アクセスログ，リクエストログなど）と別に出力できます。設定方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.9　Webサーバのログ取得の設定」を参照してください。

＜この項の構成＞

(1)　論理サーバの動作確認レベルの設定

(2)　論理サーバの動作確認間隔の設定

(3)　論理サーバの動作確認タイムアウトの設定

(4)　論理サーバの動作確認リトライの設定

(5)　論理サーバの動作確認の開始時間の設定

(6)　Hitachi Web Serverの動作確認の設定

(1)　論理サーバの動作確認レベルの設定

運用管理エージェントでは，論理サーバが正常に動作しているかどうかを，プロセスの存在を確認したり，論理サーバにアクセスしたりすることで判断します。論理サーバの動作確認レベルは，adminagent.<論理サーバの種類>.watch.levelキーに指定します。必要に応じて，論理サーバの動作確認レベルを変更してください。指定できる値は「1」または「2」です。「1」はプロセスの存在を確認するだけで論理サーバの動作を確認します。また，「2」はプロセスの存在を確認し，実際に論理サーバにアクセスして動作を確認します。指定できる値は論理サーバの種類によって異なります。なお，WebサーバでSSL通信だけを有効にしている場合，論理Webサーバの動作確認レベルはプロセスの存在を確認するだけに変更（adminagent.hws.watch.level=1を設定）してください。

(2)　論理サーバの動作確認間隔の設定

論理サーバの動作確認の間隔（秒）は，adminagent.<論理サーバの種類>.watch.intervalキーに指定します。デフォルトは10秒です。必要に応じて，論理サーバの動作を確認するときの間隔を変更してください。

(3)　論理サーバの動作確認タイムアウトの設定

論理サーバの動作確認のタイムアウト時間（秒）は，adminagent.<論理サーバの種類>.watch.timeoutキーに指定します。デフォルトは60秒です。必要に応じて，論理サーバの動作を確認するときのタイムアウト時間を変更してください。

(4)　論理サーバの動作確認リトライの設定

論理サーバの動作確認のリトライ回数は，adminagent.<論理サーバの種類>.watch.retry_countキーに指定します。デフォルトは1回です。

また，adminagent.watch.retry_timeout.enabledキーでは，タイムアウトの発生をリトライの対象にするかどうかを指定できます。デフォルトはfalse（リトライの対象にしない）です。なお，新規インストール時はtrue（リトライの対象にする）が指定されています。

必要に応じて，論理サーバの動作を確認するときのリトライの設定を変更してください。

(5)　論理サーバの動作確認の開始時間の設定

論理サーバを起動してから動作確認（動作確認レベル2）を開始するまでの時間（秒）は，adminagent.<論理サーバの種類>.watch.start_timeキーに指定します。デフォルト値は論理サーバの種類によって異なります。必要に応じて，論理サーバの動作確認の開始時間を変更してください。

なお，論理サーバの動作確認の開始時間を変更する場合は，「論理サーバの動作確認の開始時間（秒） ＜ 論理サーバの起動監視時間（分）」となるように注意してください。論理サーバの起動監視時間は，運用管理ポータルの「論理サーバの起動／停止」の［起動／停止の設定］画面で設定できます。起動監視時間が動作確認の開始時間よりも小さい場合は，論理サーバの起動に失敗します。

(6)　Hitachi Web Serverの動作確認の設定

Management Serverでは，WebサーバとしてHitachi Web Serverを管理できます。ここでは，動作確認用HTTPメソッドの設定，およびHitachi Web Serverの動作確認用URLの設定について説明します。ただし，Hitachi Web Server動作確認用URLは，動作確認用HTTPメソッドの設定で「HEAD」を指定している場合にだけ設定できます。

(a)　動作確認用HTTPメソッドの設定

論理サーバの動作確認レベル（adminagent.<論理サーバの種類>.watch.levelキー）で，「2」を指定（プロセスの存在を確認し，実際に論理サーバにアクセスして動作を確認する）した場合のHitachi Web Serverの動作確認用HTTPメソッドを指定します。指定できる値は「HEAD」または「OPTIONS」です。「HEAD」を指定した場合は，Hitachi Web Server動作確認用URL（adminagent.hws.watch.urlキー）で指定されたURLにアクセスして応答が返ることを確認します。また，「OPTIONS」を指定した場合は，WebサーバがHTTPメソッドを受け付け可能な状態であるかを確認します。

なお，「OPTIONS」を指定した場合，Hitachi Web Serverの設定で，ルートディレクトリに対してすべてのホストからのアクセスを禁止していると，運用管理エージェントからの動作確認アクセスも拒否されてしまうため，正しく稼働判定できなくなり，Hitachi Web Serverの起動に失敗します。その場合，ループバックアドレス（ホストの固定をしている場合は固定したIPアドレス）からのアクセスを許可する必要があります。Basic認証の設定をしている場合など，アクセスを制限している場合も正しく稼働判定できなくなるので注意してください。

(b)　Hitachi Web Server動作確認用URLの設定

運用管理エージェントは，Hitachi Web Serverが正常に動作しているかどうかを，設定したURLに対して定期的にダミーアクセスをすることで判断します。ダミーアクセスのレスポンスが返らないような状態（無応答の状態）になると，Hitachi Web Serverが異常と判断し，障害を検出します。このため，Webサーバを使用する場合には，動作確認用URLとして実際にアクセスできるURLを設定してください。Hitachi Web Server動作確認用URLは，adminagent.hws.watch.urlキーに指定します。

URLには，httpで始まる絶対パス，またはルートコンテキストからの相対パスを指定してください。デフォルト値は，ルートコンテキスト（http://localhost:<ポート番号>/）です。同一のホストに複数のWebサーバを構築する場合は相対パスで指定してください。

（例）

動作確認用URLに「http://HostA:80/index.html」を指定する場合の例を次に示します。
adminagent.hws.watch.url=http://HostA:80/index.html

動作確認用URLに「http://localhost:<ポート番号>/index.html」を指定する場合（複数Webサーバ対応）の例を次に示します。
adminagent.hws.watch.url=index.html

なお，障害発生時の自動再起動については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.4　障害発生時の自動再起動」を参照してください。

7.6.5　管理ユーザアカウントを設定しない場合の設定

管理ユーザアカウントとは，運用管理ポータルにログインしたり，Management Serverに対してコマンド（例：mngsvrutilコマンド）を実行したりするときに使用するユーザ権限です。管理ユーザアカウントの設定はManagement Serverのセットアップ時などに実施しますが，管理ユーザアカウントを設定しないでManagement Serverを使用することもできます。管理ユーザアカウントを設定しない場合，運用管理ポータルの操作およびManagement Serverに対してコマンドを実行するときには次のようになります。

運用管理ポータルの［ログイン］画面が表示されません。URLを指定するとログインなしで運用管理ポータルを使用できます。

Management Serverに対するコマンドの実行時に，-u（管理ユーザID）および-p（管理ユーザパスワード）の指定が不要になります。これらのオプションを指定しなくても，コマンドを実行できます。詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「1.4　コマンド使用時の注意事項」を参照してください。

管理ユーザアカウントを設定しない場合は，mserver.propertiesのcom.cosminexus.mngsvr.management_user_account.enabledキーにfalseを設定します。設定方法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。

ただし，管理ユーザアカウントを設定していないと，だれでも運用管理ポータルやコマンドの実行を通してManagement Serverを操作できます。複数人でManagement Serverを操作するような運用環境の場合は，管理ユーザアカウントを設定することをお勧めします。

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

Smart Composer機能で構築したシステムを起動する前には，運用管理エージェントとManagement Serverが起動している必要があります。ここでは，運用管理エージェントおよびManagement Serverの起動と停止について説明します。また，運用管理エージェントおよびManagement Serverの自動起動の設定方法についても説明します。

Smart Composer機能で構築したシステムは，次に示す手順でシステムの起動と停止を実施します。

システムの起動手順

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

Management Serverの起動

システムの起動

システムの停止手順

システムの停止

Management Serverの停止

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

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

＜この節の構成＞

7.7.1　運用管理エージェントの起動／停止と設定

7.7.2　Management Serverの起動／停止と設定

7.7.1　運用管理エージェントの起動／停止と設定

通常の運用では，運用管理エージェントとManagement Serverは自動起動する方法をお勧めします。運用管理エージェントとManagement Serverに自動起動を設定すると，運用管理エージェントの起動からManagement Serverの起動までの一連の操作を，ホスト起動と同時に処理できるようになります。ここでは，手動による運用管理エージェントの起動／停止と，運用管理エージェントを自動起動するための設定について説明します。

＜この項の構成＞

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

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

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

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

アプリケーションサーバごとに，adminagentctlコマンドを使用して運用管理エージェントを起動します。起動方法を，OSごとに示します。なお，Windowsの場合はサービスからも起動できます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

UNIXの場合

# /opt/Cosminexus/manager/bin/adminagentctl start

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

運用管理エージェントを自動起動する場合は，ホストと同時に起動するようにします。自動起動するためにはあらかじめ設定が必要です。設定方法を，OSごとに示します。

Windowsの場合

mngautorunコマンドに引数「agent」を指定して実行します。

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngautorun agent

参考

ホスト単位管理モデルのように，同一マシン上でManagement Serverと運用管理エージェントを起動する場合には，mngautorunコマンドに引数「both」を指定して，運用管理エージェントが先に起動するように依存関係を設定してください。

AIXの場合

mkitabコマンドを使用して，運用管理エージェントの起動スクリプト（/opt/Cosminexus/manager/bin/adminagentctl start）を，/etc/inittabファイルに登録します。mkitabコマンドの詳細については，AIXのドキュメントを参照してください。

# mkitab "adminagentctl:2:once:/opt/Cosminexus/manager/bin/adminagentctl start # Cosminexus Management Server - Administration Agent Start"

HP-UXの場合

/sbin/rc<N>.dディレクトリに，/sbin/init.d/MngSvrおよび/sbin/init.d/AdminAgentへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /sbin/init.d/MngSvr /sbin/rc2.d/S900MngSvr
# chmod 755 /sbin/rc2.d/S900MngSvr
# ln -s /sbin/init.d/AdminAgent /sbin/rc2.d/S800AdminAgent
# chmod 755 /sbin/rc2.d/S800AdminAgent

Linuxの場合

/etc/rc.d/rc<N>.dディレクトリに，/etc/rc.d/init.d/AdminAgentへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /etc/rc.d/init.d/AdminAgent /etc/rc.d/rc2.d/S80AdminAgent
# chmod 755 /etc/rc.d/rc2.d/S80AdminAgent

参考

運用管理エージェント自動起動用設定ファイル（/opt/Cosminexus/manager/config/AdminAgentrc）にリソースの制御設定（ulimit）を記述することで，運用管理エージェントから起動する論理サーバに設定を引き継ぐことができます。運用管理エージェント自動起動用設定ファイルにはulimit以外を記述しないでください。運用管理エージェント自動起動用設定ファイルにulimit以外を記述した場合の動作は保証しません。

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

Solarisの場合

/etc/rc<N>.dディレクトリに，/etc/init.d/AdminAgentへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /etc/init.d/AdminAgent /etc/rc2.d/S80AdminAgent
# chmod 755 /etc/rc2.d/S80AdminAgent

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

手動停止する場合は，アプリケーションサーバごとにadminagentctlコマンドを使用して停止します。なお，Windowsの場合はサービスからも停止できます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl stop

UNIXの場合

# /opt/Cosminexus/manager/bin/adminagentctl stop

UNIXの場合，自動停止ができます。自動停止する場合は，ホストと同時に停止するようにします。運用管理エージェントを自動停止する場合の停止手順をOS別に次に示します。

●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

●HP-UXの場合の停止手順

ホスト停止時に運用管理エージェントを自動停止させるためには，/sbin/rc＜N＞.dディレクトリに/sbin/init.d/AdminAgentへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，運用管理エージェントの停止時の実行レベル，および運用管理エージェントを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上で運用管理エージェントとManagement Serverを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

運用管理エージェントを自動停止させる場合の実行例を次に示します。この例では，実行レベルが1から2になるときに運用管理エージェントを自動停止させることを前提としています。

# ln -s /sbin/init.d/AdminAgent /sbin/rc2.d/K900AdminAgent
# chmod 755 /sbin/rc2.d/K900AdminAgent

シンボリックリンクの名称は，「K＜NNN＞＜停止スクリプト名＞」の形式で指定してください。「＜NNN＞」には，同一実行レベル内での停止順序を示す3けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

●Linuxの場合の停止手順

ホスト停止時に運用管理エージェントを自動停止させるためには，/etc/rc.d/rc＜N＞.dディレクトリに/etc/rc.d/init.dへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，運用管理エージェントの停止時の実行レベル，および運用管理エージェントを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上で運用管理エージェントとManagement Serverを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

運用管理エージェントを自動停止させる場合の実行例を次に示します。この例では，実行レベルが3の場合に運用管理エージェントを自動停止させることを前提としています。

# ln -s /etc/rc.d/init.d/AdminAgent /etc/rc.d/rc3.d/K91AdminAgent
# chmod 755 /etc/rc.d/rc3.d/K91AdminAgent

シンボリックリンクの名称は，「K＜NN＞＜停止スクリプト名＞」の形式で指定してください。「＜NN＞」には，同一実行レベル内での停止順序を示す2けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

●Solarisの場合の停止手順

ホスト停止時に運用管理エージェントを自動停止させるためには，/etc/rc＜N＞.dディレクトリに/etc/init.dへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，運用管理エージェントの停止時の実行レベル，および運用管理エージェントを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上で運用管理エージェントとManagement Serverを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

運用管理エージェントを自動停止させる場合の実行例を次に示します。この例では，実行レベルが1から2になるときに運用管理エージェントを自動停止させることを前提としています。

# ln -s /etc/init.d/AdminAgent /etc/rc2.d/K91AdminAgent
# chmod 755 /etc/rc2.d/K91AdminAgent

シンボリックリンクの名称は，「K＜NN＞＜停止スクリプト名＞」の形式で指定してください。「＜NN＞」には，同一実行レベル内での停止順序を示す2けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

7.7.2　Management Serverの起動／停止と設定

通常の運用では，運用管理エージェントとManagement Serverは自動起動する方法をお勧めします。運用管理エージェントとManagement Serverに自動起動を設定すると，運用管理エージェントの起動からManagement Serverの起動までの一連の操作を，ホスト起動と同時に処理できるようになります。ここでは，手動によるManagement Serverの起動／停止と，Management Serverを自動起動するための設定について説明します。

＜この項の構成＞

(1)　Management Serverの起動

(2)　Management Serverの自動起動の設定

(3)　Management Serverの停止

(1)　Management Serverの起動

Management Serverをセットアップしたマシンで，mngsvrctlコマンドに，引数「start」を指定してManagement Serverを起動します。起動方法を，OSごとに示します。なお，Windowsの場合はサービスからも起動できます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl start

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl start

(2)　Management Serverの自動起動の設定

Management Serverを自動起動する場合は，ホストと同時に起動するようにします。自動起動するためにはあらかじめ設定が必要です。設定方法を，OSごとに示します。

Windowsの場合

mngautorunコマンドに引数「server」を指定して実行します。

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngautorun server

AIXの場合

mkitabコマンドを使用して，Management Serverの起動スクリプト（/opt/Cosminexus/manager/bin/mngsvrctl start）を，/etc/inittabファイルに登録します。mkitabコマンドの詳細については，AIXのドキュメントを参照してください。

# mkitab "mngsvrctl:2:once:/opt/Cosminexus/manager/bin/mngsvrctl start # Cosminexus Management Server Start"

HP-UXの場合

/sbin/rc<N>.dディレクトリに，/sbin/init.d/MngSvrへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /sbin/init.d/MngSvr /sbin/rc2.d/S900MngSvr
# chmod 755 /sbin/rc2.d/S900MngSvr

Linuxの場合

/etc/rc.d/rc<N>.dディレクトリに，/etc/rc.d/init.d/MngSvrへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /etc/rc.d/init.d/MngSvr /etc/rc.d/rc2.d/S90MngSvr
# chmod 755 /etc/rc.d/rc2.d/S90MngSvr

Solarisの場合

/etc/rc<N>.dディレクトリに /etc/init.d/MngSvrへのシンボリックリンクを作成します（<N>は起動時の実行レベルを表します）。

# ln -s /etc/init.d/MngSvr /etc/rc2.d/S90MngSvr
# chmod 755 /etc/rc2.d/S90MngSvr

(3)　Management Serverの停止

手動停止する場合は，Management Serverをセットアップしたマシンで，mngsvrctlコマンドに，引数「stop」を指定してManagement Serverを停止します。停止方法を，OSごとに示します。なお，Windowsの場合はサービスからも停止できます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl stop

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl stop

UNIXの場合は，自動停止ができます。自動停止する場合は，ホストと同時に停止するようにします。Management Serverを自動停止する場合の停止手順をOS別に次に示します。

●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

●HP-UXの場合の停止手順

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

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

ホスト停止時にManagement Serverを自動停止させるためには，/sbin/rc＜N＞.dディレクトリに/sbin/init.d/MngSvrへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，Management Serverの停止時の実行レベル，およびManagement Serverを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上でManagement Serverと運用管理エージェントを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

Management Serverを自動停止させる場合の実行例を次に示します。この例では，実行レベルが1から2になるときにManagement Serverを自動停止させることを前提としています。

# ln -s /sbin/init.d/MngSvr /sbin/rc2.d/K800MngSvr
# chmod 755 /sbin/rc2.d/K800MngSvr

シンボリックリンクの名称は，「K＜NNN＞＜停止スクリプト名＞」の形式で指定してください。「＜NNN＞」には，同一実行レベル内での停止順序を示す3けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

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

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

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

#!/bin/sh
/opt/Cosminexus/manager/bin/mngsvrutil -m mnghost:28080 -u user1 -p user1 -t mnghost -k host -s stop server
ERROR=$?
exit $ERROR

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

論理サーバを停止させるためのスクリプトファイルの権限を「755」に設定して，/opt/Cosminexus/manager/bin/MngSvr_LS_stopへのシンボリックリンクを作成します。
実行例を次に示します。

# chmod 755 /opt/Cosminexus/manager/bin/LS_stop
# ln -s /opt/Cosminexus/manager/bin/LS_stop /opt/Cosminexus/manager/bin/MngSvr_LS_stop

これで，ホスト停止時に論理サーバを自動停止させるための設定は完了です。

●Linuxの場合の停止手順

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

注意

Management Serverを停止するホストだけで運用管理ドメインを構成している場合は，ホスト停止時に論理サーバを自動停止させることができます。複数のホストで運用管理ドメインを構成している場合は，Management Server停止時に運用管理ドメイン内のすべての論理サーバを停止できないため，Management Serverを停止する前にあらかじめ論理サーバを停止しておく必要があります。

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

ホスト停止時にManagement Serverを自動停止させるためには，/etc/rc.d/rc＜N＞.dディレクトリに/etc/rc.d/init.d/MngSvrへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，Management Serverの停止時の実行レベル，およびManagement Serverを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上でManagement Serverと運用管理エージェントを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

Management Serverを自動停止させる場合の実行例を次に示します。この例では，実行レベルが3の場合にManagement Serverを自動停止させることを前提としています。

# ln -s /etc/rc.d/init.d/MngSvr /etc/rc.d/rc3.d/K90MngSvr
# chmod 755 /etc/rc.d/rc3.d/K90MngSvr

シンボリックリンクの名称は，「K＜NN＞＜停止スクリプト名＞」の形式で指定してください。「＜NN＞」には，同一実行レベル内での停止順序を示す2けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

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

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

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

#!/bin/sh
/opt/Cosminexus/manager/bin/mngsvrutil -m mnghost:28080 -u user1 -p user1 -t mnghost -k host -s stop server
ERROR=$?
exit $ERROR

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

論理サーバを停止させるためのスクリプトファイルの権限を「755」に設定して，/opt/Cosminexus/manager/bin/MngSvr_LS_stopへのシンボリックリンクを作成します。
実行例を次に示します。

# chmod 755 /opt/Cosminexus/manager/bin/LS_stop
# ln -s /opt/Cosminexus/manager/bin/LS_stop /opt/Cosminexus/manager/bin/MngSvr_LS_stop

なお，シンボリックリンクの作成先には，「/opt/Cosminexus/manager/bin/MngSvr_LS_stop」を必ず指定してください。
これで，ホスト停止時に論理サーバを自動停止させるための設定は完了です。

●Solarisの場合の停止手順

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

注意

Management Serverを停止するホストだけで運用管理ドメインを構成している場合は，Management Serverの停止時に論理サーバを自動停止させることができます。複数のホストで運用管理ドメインを構成している場合は，Management Server停止時に運用管理ドメイン内のすべての論理サーバを停止できないため，Management Serverを停止する前にあらかじめ論理サーバを停止しておく必要があります。

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

ホスト停止時にManagement Serverを自動停止させるためには，/etc/rc＜N＞.dディレクトリに/etc/init.d/MngSvrへのシンボリックリンクを作成します（＜N＞は停止時の実行レベルを表します）。なお，シンボリックリンクの作成は，root権限のあるユーザが実行してください。

シンボリックリンク作成時に指定する，Management Serverの停止時の実行レベル，およびManagement Serverを停止する順番は，運用環境に合わせて決めてください。ただし，同一ホスト上でManagement Serverと運用管理エージェントを停止する場合，Management Serverが運用管理エージェントよりも先に停止するように順番を設定してください。

Management Serverを自動停止させる場合の実行例を次に示します。この例では，実行レベルが1から2になるときにManagement Serverを自動停止させることを前提としています。

# ln -s /etc/init.d/MngSvr /etc/rc2.d/K90MngSvr
# chmod 755 /etc/rc2.d/K90MngSvr

シンボリックリンクの名称は，「K＜NN＞＜停止スクリプト名＞」の形式で指定してください。「＜NN＞」には，同一実行レベル内での停止順序を示す2けたの数字を指定してください。「＜停止スクリプト名＞」には，リンク先の停止スクリプトの名称と同じ名称を指定してください。なお，実行レベルとシンボリックリンクの指定規則の詳細については，OSのマニュアルを参照してください。

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

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

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

#!/bin/sh
/opt/Cosminexus/manager/bin/mngsvrutil -m mnghost:28080 -u user1 -p user1 -t mnghost -k host -s stop server
ERROR=$?
exit $ERROR

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

論理サーバを停止させるためのスクリプトファイルの権限を「755」に設定して，/opt/Cosminexus/manager/bin/MngSvr_LS_stopへのシンボリックリンクを作成します。
実行例を次に示します。

# chmod 755 /opt/Cosminexus/manager/bin/LS_stop
# ln -s /opt/Cosminexus/manager/bin/LS_stop /opt/Cosminexus/manager/bin/MngSvr_LS_stop

なお，シンボリックリンクの作成先には，「/opt/Cosminexus/manager/bin/MngSvr_LS_stop」を必ず指定してください。
これで，ホスト停止時に論理サーバを自動停止させるための設定は完了です。

7.8　Server Plug-inの設定

ここでは，Server Plug-inを使用するための設定について説明します。Server Plug-inを使用してリソースアダプタやJ2EEアプリケーションの設定をする場合，あらかじめ，Server Plug-inを使用するための設定をしておく必要があります。次にServer Plug-inの設定の手順を示します。

Eclipseをインストールします。
インストールの手順については，Eclipseのドキュメントを参照してください。

Java実行環境を指定します。
Eclipseを使用するにはJava実行環境が必要です。Java実行環境の指定については，「7.8.1　Java実行環境の指定」を参照してください。

Server Plug-inをEclipseに組み込みます。
Server Plug-inの組み込み手順については，「7.8.2　Server Plug-inの組み込み手順」を参照してください。

Management Serverで，Server Plug-inを使用するための設定をします。
Server Plug-inが接続するManagement Serverで，Server Plug-inを使用するための設定をします。Server Plug-inを使用するための設定については，「7.8.3　Server Plug-inを使用するためのManagement Serverの設定」を参照してください。

Server Plug-inの環境設定をします。
Server Plug-inの環境設定では，ホストへの接続情報を設定します。
Server Plug-inはManagement Serverに接続して，Management Serverが管理している運用管理ドメイン内の論理サーバの操作をします。このため，操作したい運用管理ドメインが定義されているホストへの接続について設定します。
uCosminexus Operatorの場合は，接続先のアプリケーションサーバマシンで定義されているホストについて，接続情報を設定します。
Server Plug-inの環境設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「11.1.1　Server Plug-inの環境設定」を参照してください。

また，必要に応じて，次の設定をしてください。

Server Plug-inの表示言語の変更
Server Plug-inの表示言語を変更できます。Server Plug-inの表示言語はOSのロケールに合わせて選択されますが，OSのロケールと異なる言語を表示させたい場合は，次のどちらかの方法で言語を指定してください。

Eclipseで提供されているeclipse.iniファイル内に次の行を追加する。
-vmargs
-Duser.language=en※

Eclipseの起動引数に次の内容を指定する。
eclipse.exe -vmargs -Duser.language=en※

注※

英語表示の場合は「en」，日本語表示の場合は「ja」を指定します。

コンテナ拡張ライブラリを使用するための設定
コンテナ拡張ライブラリを使用する場合は，運用管理エージェントのシステムクラスパスの設定が必要になります。さらに，コンテナ拡張ライブラリからJNI機能を使用する場合には，運用管理エージェントのライブラリパスの設定が必要になります。

システムクラスパスの設定
adminagentuser.cfgのadd.class.pathキーに，コンテナ拡張ライブラリ用のJARファイルのパスを指定します。

ライブラリパスの設定
adminagentuser.cfgのadd.library.pathキーに，JNI用ライブラリの検索パスを指定します。

ファイルおよびキーの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.4　adminagentuser.cfg（運用管理エージェント用オプション定義ファイル）」を参照してください。コンテナ拡張ライブラリの機能の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13.3　コンテナ拡張ライブラリの機能」を参照してください。

＜この節の構成＞

7.8.1　Java実行環境の指定

7.8.2　Server Plug-inの組み込み手順

7.8.3　Server Plug-inを使用するためのManagement Serverの設定

7.8.1　Java実行環境の指定

Eclipseを使用するにはJava実行環境が必要です。Eclipseをインストールしたあと，次のどちらかの方法でJava実行環境を指定してください。

環境変数PATHの指定
環境変数PATHに次のパスを指定してください。
<Cosminexusのインストールディレクトリ>¥jdk¥bin

Eclipseの起動引数の指定
Eclipseの起動引数にJava仮想マシンを指定して起動します。
Eclipse.exe -vm "<Cosminexusのインストールディレクトリ>¥jdk¥bin¥javaw.exe"

7.8.2　Server Plug-inの組み込み手順

Server Plug-inをEclipseに組み込みます。組み込み手順を次に示します。

リンクファイルをコピーして貼り付けます。
コピー元のファイルと，コピー先のディレクトリを次に示します。

コピー元のファイル
<Cosminexusのインストールディレクトリ>¥plugins¥dropins¥com.cosminexus.plugin.link

コピー先のディレクトリ
<Eclipseのインストールディレクトリ>¥dropins

-cleanオプションを指定してEclipseを起動します。
コマンドの実行例を次に示します。
<Eclipseのインストールディレクトリ>¥eclipse.exe -clean

Eclipseを再起動します。

以上でプラグインの組み込みが完了となります。

なお，Server Plug-inが正しく組み込まれたかどうかは，メニューから［ヘルプ］－［Eclipse Platform について］を選択して表示される，［Eclipse Platform について］ダイアログで確認してください。

アプリケーションサーバを再インストールしたときの注意事項

バージョンアップなどによってアプリケーションサーバを再インストールした場合，次に示す操作を行ってから，Server Plug-inをEclipseに組み込む必要があります。

拡張ロケーションの削除
拡張ロケーションを削除して再度プラグインを組み込みます。拡張ロケーションの削除はEclipseのインストール先（eclipse.exeがあるフォルダ）で次のコマンドを実行します。
"<Cosminexusのインストールディレクトリ>¥jdk¥bin¥java" -jar plugins/org.eclipse.equinox.launcher_<バージョン>.jar -application org.eclipse.update.core.standaloneUpdate -command removeSite -to "<Cosminexusのインストールディレクトリ>¥plugins¥eclipse"

Eclipseの起動引数の指定
Eclipseの起動引数に-cleanを指定して再起動します。
eclipse.exe -clean

7.8.3　Server Plug-inを使用するためのManagement Serverの設定

Server Plug-inを使用するための設定を，Server Plug-inの接続先となるManagement Serverで実施します。設定をするには，Management Serverが配置されているサーバにあるmserver.properties（Management Server環境設定ファイル）に，プロパティを追加します。なお，設定した情報をManagement Serverに反映させるためには，プロパティの追加後，必ず，Management Serverおよび運用管理エージェントを再起動してください。

次に，mserver.propertiesの格納先とmserver.propertiesに追加するプロパティを示します。

mserver.propertiesの格納先

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥mserver.properties

UNIXの場合

/opt/Cosminexus/manager/config/mserver.properties

注意

Server Plug-inがインストールされているマシンとManagement Serverが配置されているマシンが別の場合は，Management Serverが配置されているマシンにあるmserver.propertiesで設定します。

追加するプロパティ
com.cosminexus.mngsvr.management.enabled=true
com.cosminexus.mngsvr.management.connector.enabled=true
com.cosminexus.mngsvr.management.port=28099※

注※

設定を省略した場合，デフォルトで28099が設定されます。なお，このキーの値を28099以外に設定した場合は，Server Plug-inの「リモート管理機能に接続するための環境設定」の「接続ポート番号」の値を，com.cosminexus.mngsvr.management.portキーに設定した値に変更する必要があります。リモート管理機能に接続するための環境設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「11.1.1　Server Plug-inの環境設定」を参照してください。

また，Server Plug-inの画面上に，論理J2EEサーバおよび論理ユーザサーバのコンソール出力情報を表示させたい場合は，設定が必要になります。コンソール出力情報を表示するための設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「11.3　コンソールログの取得の設定」を参照してください。

7.9　インストール後のディレクトリ構成

ここでは，Application Serverのインストール後のディレクトリ構成について説明します。また，Application Serverの構成ソフトウェアのうち，Cosminexus Component Containerのディレクトリ構成について説明します。

このマニュアルでは，Application Serverのインストールディレクトリのことを，「Cosminexusのインストールディレクトリ」と表記します。インストールディレクトリを次に示します。

Windowsのインストールディレクトリ（デフォルト）
<OSインストールドライブ>:¥Program Files¥Hitachi¥Cosminexus

UNIXのインストールディレクトリ
/opt/Cosminexus

＜この節の構成＞

(1)　Application Serverのディレクトリ構成

(2)　Cosminexus Component Containerのディレクトリ構成

(1)　Application Serverのディレクトリ構成

Application Serverのディレクトリ構成をOSごとに説明します。

●Windowsの場合

Windowsの場合のApplication Serverのディレクトリ構成を次の図に示します。

図7-3　Application Serverのディレクトリ構成（Windowsの場合）

●UNIXの場合

UNIXの場合のApplication Serverのディレクトリ構成を次の図に示します。

図7-4　Application Serverのディレクトリ構成（UNIXの場合）

(2)　Cosminexus Component Containerのディレクトリ構成

(1)の図中にある，Cosminexus Component Containerのディレクトリの下位のディレクトリ構成をディレクトリごとに表に示します。

●CCディレクトリ

Cosminexus Component Containerの提供する機能のうち，コンテナなどの基盤部分の機能を提供するディレクトリです。<Cosminexusのインストールディレクトリ>¥CC（Windowsの場合），または/opt/Cosminexus/CC（UNIXの場合）です。

表7-10　Cosminexus Component Containerのディレクトリ構成（CCディレクトリ）

ディレクトリ | 説明
adapters | － | アダプタを格納するディレクトリです。
OpenTP1 | TP1インバウンドアダプタ格納用ディレクトリです。
admin | － | J2EEサーバ管理用ディレクトリです。
bin | サーバ管理コマンド格納用ディレクトリです。
dtds | CUI用のDTDファイル格納用ディレクトリです。
logs | サーバ管理コマンドのログ格納用ディレクトリです。
sysconf | サーバ管理コマンドのシステム定義ファイル格納用ディレクトリです。ただし，修正禁止です。
templates | 属性ファイルのテンプレート格納用ディレクトリです。
usrconf | サーバ管理コマンドのユーザ定義ファイル格納用ディレクトリです（カスタマイズ用）。
batch | － | バッチアプリケーション用のディレクトリです。
bin | バッチアプリケーションの実行ファイル格納用ディレクトリです。
logs | バッチアプリケーションのログ出力用ディレクトリです。
sysconf | バッチアプリケーションのシステム定義ファイル格納用ディレクトリです。ただし，修正禁止です。
templates | バッチアプリケーションのユーザ定義ファイルのひな型格納用ディレクトリです。
cjmsp | － | Cosminexus JMSプロバイダ用のディレクトリです。
bin | Cosminexus JMSプロバイダのコマンド格納用ディレクトリです。
lib | － | Cosminexus JMSプロバイダのライブラリファイルおよびRARファイル格納用ディレクトリです。
props | － | Cosminexus JMSプロバイダのプロパティファイル格納用ディレクトリです。
broker | Cosminexus JMSプロバイダのブローカプロパティファイル格納用ディレクトリです。
templates | CJMSPリソースアダプタのConnector属性ファイルのテンプレート格納用ディレクトリです。
var | － | Cosminexus JMSプロバイダのデフォルトディレクトリです。
admin | － | Cosminexus JMSプロバイダの管理コマンド用ディレクトリです。
config | Cosminexus JMSプロバイダの管理コマンドのプロパティ格納用ディレクトリです。
instances | Cosminexus JMSプロバイダのインスタンス格納用ディレクトリです。
client | － | EJBクライアントアプリケーション用のディレクトリです。
bin | EJBクライアントアプリケーションの実行ファイル格納用ディレクトリです。
lib | EJBクライアントアプリケーションのJARファイル格納用ディレクトリです。
logs | EJBクライアントアプリケーションのログ出力用ディレクトリです。
sysconf | EJBクライアントアプリケーションのシステム定義ファイル格納用ディレクトリです。ただし，修正禁止です。
templates | EJBクライアントアプリケーションのユーザ定義ファイルのひな型格納用ディレクトリです。
client_monitor | － | クライアント性能モニタのインストールディレクトリです。
lib | JARライブラリ格納ディレクトリです。
sample | － | サンプル格納ディレクトリです。
conf | サンプルDD格納ディレクトリです。
monitor_html | サンプルデータ送信ページ格納ディレクトリです。
log_receiver | サンプルデータ受信サーブレットのソースファイル格納ディレクトリです。
DBConnector | － | DB ConnectorのRARファイル格納用ディレクトリです。
ReliableMessaging | DB Connector for Cosminexus RMのRARファイル格納用ディレクトリです。
ClusterPool | コネクションプールのクラスタ化機能を使用する場合のRARファイル格納用ディレクトリです。
examples | サンプルプログラム格納用ディレクトリです。
lib | Cosminexus Component Container用クラスライブラリファイル格納用ディレクトリです。
logs | インストール時のログ格納用ディレクトリです。
server | － | －
bin | J2EEサーバ用コマンドツール格納用ディレクトリです。
lib | － | J2EEサーバ用ライブラリファイル格納用ディレクトリです。
dtds | Cosminexus Component Containerで使用するDTDファイル格納用ディレクトリです。ただし，修正禁止です。
schemas | DD用スキーマ定義ファイル格納用ディレクトリです。
public | J2EEサーバのデフォルトの作業用ディレクトリです。
repository | 一時作業用ディレクトリです。
sysconf | システム定義用ファイル格納用ディレクトリです。ただし，修正禁止です。
templates | コンフィグレーションファイルやプロパティファイルなどのひな型格納用ディレクトリです。
usrconf | － | －
ejb | － | －
<ローカルホスト名> | J2EEサーバのユーザ定義ファイルの格納用ディレクトリです（カスタマイズ用）。
sfo | － | セッションフェイルオーバ機能用ディレクトリです。
lib | セッションフェイルオーバ機能用ライブラリ格納用ディレクトリです。
sfo_server | SFOサーバアプリケーション格納用ディレクトリです。
sfo_war | セッションフェイルオーバ機能用のWebアプリケーションのDD（web.xml）格納用ディレクトリです。
spool | － | 一時ディレクトリです。
web | － | サーブレットエンジンモード用ルートディレクトリです。
bin | サーブレットエンジンモード用コマンドツール格納ディレクトリです。
containers | － | －
<ローカルホスト名> | － | －
usrconf | <ローカルホスト名>用のユーザ定義ファイル格納用ディレクトリです。
webapps | <ローカルホスト名>用のWebアプリケーション格納用ディレクトリです。
jdbc | サーブレットエンジンモード用コネクションプール機能管理ツール格納用ディレクトリです。
redirector | － | リダイレクタ本体／定義ファイル格納用ディレクトリです。
logs | リダイレクタのログ出力用ディレクトリです。
sysconf | システム定義ファイル格納用ディレクトリです。ただし，修正禁止です。
templates | ユーザ定義ファイルのひな型格納用ディレクトリです。ただし，修正禁止です。

（凡例）－：該当しません。

●managerディレクトリ

Cosminexus Component Containerの提供する機能のうち，アプリケーションサーバの運用管理機能を提供するディレクトリです。

表7-11　Cosminexus Component Containerのディレクトリ構成（managerディレクトリ）

ディレクトリ
説明

bin
運用管理機能で使用するコマンドなどの格納用ディレクトリです。

config
－
運用管理機能で使用するコマンドなどの格納用ディレクトリです。

templates
運用管理機能で使用する定義ファイルなどの格納用ディレクトリです。

containers
－
－

m
－
－

usrconf
ユーザ認証情報定義ファイル格納用ディレクトリです。

webapps
－
－

mngsvr
Management Serverの動作ファイル格納用ディレクトリです。

WEB-INF
web.xml格納用ディレクトリです。

vmxsvr
－
仮想サーバマネージャGUIログインJSPファイル格納用ディレクトリです。

image
仮想サーバマネージャのヘッダタイトルのロゴ格納用ディレクトリです。

WEB-INF
URLとサーブレットクラスの対応付けを行うファイルなどの格納用ディレクトリです。

examples
ユーザ管理のサンプル格納用ディレクトリです。

lib
ライブラリファイル格納用ディレクトリです。

log
ログ出力先ディレクトリです。

modules
統合ユーザ管理フレームワークのカスタムログインモジュール格納用ディレクトリです。

spool
－
ログ収集先ディレクトリです。

mibs
MIB格納用ディレクトリです。

tmp
一時的なワークディレクトリです。

apps
デフォルトのアプリケーション登録用ディレクトリです。

externals
－
－

jp1
－
JP1連携用ファイル格納用ディレクトリです。
なお，このディレクトリはWindows用です。

ajs2_custom_jobs
カスタムジョブ格納用ディレクトリです。

mngsvrmonitor
モニタ起動コマンド格納用ディレクトリです。

ScenarioTemplate
シナリオテンプレート格納用ディレクトリです。

compat3
－
旧バージョンのManagement Serverの動作ファイル格納用ディレクトリです。
なお，このディレクトリはWindows，AIX，HP-UX，Solaris用です。

bin
運用管理機能で使用するコマンドなどの格納用ディレクトリです。

config
－
運用管理機能で使用する定義ファイルなどの格納用ディレクトリです。

Administrator
ユーザパスワードやユーザ登録情報などの格納用ディレクトリです。

fwj
業務ごとのプロパティファイル格納用ディレクトリです。

log
トレースファイル格納用ディレクトリです。

tmp
一時的なワークディレクトリです。

setup
－
セットアップウィザードディレクトリです。

bin
－

config
セットアップウィザード用設定ファイルやセットアップ情報を保持するファイルなどを格納するディレクトリです。

lib
－

log
セットアップウィザードのトレースファイル用ディレクトリです。

tmp
セットアップウィザードの一時的なワークディレクトリです。

vmx
－
08-50モードの仮想サーバマネージャで使用するファイル格納用ディレクトリです。
また，直下には，仮想サーバマネージャGUIへのログインURLのファイルも格納されています。

bin
08-50モードの仮想サーバマネージャで使用するコマンドなどの格納用ディレクトリです。

config
08-50モードの仮想サーバマネージャで使用する定義ファイルなどの格納用ディレクトリです。

log
08-50モードの仮想サーバマネージャのトレースファイル格納用ディレクトリです。

spool
08-50モードの仮想サーバマネージャの処理データ格納用ディレクトリです。

templates
08-50モードの仮想サーバマネージャで使用する定義ファイルのテンプレート格納用ディレクトリです。

vmi
－
仮想サーバマネージャで使用するファイル格納用ディレクトリです。

bin
仮想サーバマネージャで使用するコマンドなどの格納用ディレクトリです。

config
－
仮想サーバマネージャで使用する定義ファイルなどの格納用ディレクトリです。

lb
仮想サーバマネージャで使用する負荷分散機接続設定プロパティファイルの格納用ディレクトリです。

spool
仮想サーバマネージャの処理データ格納用ディレクトリです。

templates
仮想サーバマネージャで使用する定義ファイルのテンプレート格納用ディレクトリです。

（凡例）－：該当しません。

●c4webディレクトリ

Cosminexus Component Containerの提供する機能のうち，SOAPアプリケーション実行基盤の機能を提供するディレクトリです。

●jaxwsディレクトリ

Cosminexus Component Containerの提供する機能のうち，JAX-WSエンジンの機能を提供するディレクトリです。

●CWCディレクトリ

Cosminexus Component Containerの提供する機能のうち，Webアプリケーション開発に利用する機能を提供するディレクトリです。

●pluginsディレクトリ

Cosminexus Component Containerの提供する機能のうち，Server Plug-inの機能を提供するディレクトリです。なお，このディレクトリはWindows用です。

下位にeclipseフォルダを持ちます。このフォルダは，Eclipseへ組み込み時に指定するフォルダです。

●sinagentディレクトリ

Cosminexus Component Containerの提供する機能のうち，サーバ通信エージェントの機能を提供するディレクトリです。

7.10　J2EEサーバの作業ディレクトリ

J2EEサーバは作業ディレクトリ中にサーバ名やアプリケーションの表示名，EARファイル中のファイルなどを用いてディレクトリやファイルを生成します。ディレクトリ名やファイル名，パス全体の長さには上限があり，作業ディレクトリ全体がパス全体の上限に収まらないとJ2EEサーバは正常に動作できません。ここでは，作業ディレクトリの構成と作業ディレクトリのパス長の見積もり式について説明します。

＜この節の構成＞

7.10.1　J2EEサーバの作業ディレクトリの構成

7.10.2　作業ディレクトリのパス長の見積もり式

7.10.1　J2EEサーバの作業ディレクトリの構成

J2EEサーバの作業ディレクトリは，J2EEサーバが動作する上で必要な作業領域です。この領域には，ユーザのパスワード情報，インポートされたリソースアダプタ，EARファイル，EJB-JARファイル，WARファイル，作成されたJ2EEアプリケーションなどの情報が格納されます。

J2EEサーバは，作業ディレクトリ以下にJ2EEサーバごとの専用ディレクトリ構造を持ちます。このため，複数のJ2EEサーバで共通のディレクトリを指定できます。

作業ディレクトリを変更してJ2EEサーバを開始すると，既存のJ2EEアプリケーションなどは利用できません。

作業ディレクトリを別のマシンに移動した場合，別のマシン上のJ2EEサーバでは認識できません。

作業ディレクトリでは，2バイトコードを含むパス名称を利用できません。

作業ディレクトリのデフォルトを次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥public

UNIXの場合
/opt/Cosminexus/CC/server/public

作業ディレクトリは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.public.directoryパラメタで変更できます。

J2EEサーバには，次の作業ディレクトリがあります。

J2EEアプリケーション（コンフィグレーション関連）

J2EEアプリケーション（デプロイ関連）

J2EEリソース

J2EEリソースアダプタ（コンフィグレーション関連）

J2EEリソースアダプタ（デプロイ関連）

Webアプリケーション（JSP関連）

Webアプリケーション（その他）

上記の作業ディレクトリの構成についてそれぞれ説明します。また，移行コマンド実行後のディレクトリ構成についても説明します。

ディレクトリ構成を図で示したあと，各ディレクトリを説明します。なお，図中の番号と説明の番号は対応しています。また，図中では，同一ディレクトリに複数の種類のファイルが入る場合は，いちばん長いファイル名だけを記載しています。

＜この項の構成＞

(1)　J2EEアプリケーション（コンフィグレーション関連）

(2)　J2EEアプリケーション（デプロイ関連）

(3)　J2EEリソース

(4)　J2EEリソースアダプタ（コンフィグレーション関連）

(5)　J2EEリソースアダプタ（デプロイ関連）

(6)　Webアプリケーション（JSP関連）

(7)　Webアプリケーション（その他）

(8)　J2EEサーバ，またはWebコンテナサーバの移行コマンド実行後のディレクトリ構成

(9)　リソースアダプタの移行コマンド実行後のディレクトリ構成

(1)　J2EEアプリケーション（コンフィグレーション関連）

J2EEアプリケーション（コンフィグレーション関連）のディレクトリ構成を次の図に示します。

図7-5　J2EEアプリケーション（コンフィグレーション関連）のディレクトリ構成

J2EEアプリケーションごとに作られるディレクトリです。

EARファイルをインポートした場合に作られるディレクトリです。ディレクトリ名はEARファイル名を基に付けられます。

EARファイルは，17けたの数字.earの名前でここに格納されます。

EJB-JARファイルごとに作られるディレクトリです。ディレクトリ名はEJB-JARファイル名を基に付けられます。

EJB-JARファイルは，17けたの数字.jarの名前でここに格納されます。

ライブラリJARファイルごとに作られるディレクトリです。ディレクトリ名はライブラリJARファイル名を基に付けられます。

ライブラリJARファイルは，17けたの数字.jarの名前でここに格納されます。

RARファイルごとに作られるディレクトリです。ディレクトリ名はRARファイル名を基に付けられます。

RARファイルは，17けたの数字.rarの名前でここに格納されます。

WARファイルごとに作られるディレクトリです。ディレクトリ名はWARファイル名を基に付けられます。

WARファイルは，17けたの数字.jarの名前でここに格納されます。

(2)　J2EEアプリケーション（デプロイ関連）

J2EEアプリケーション（デプロイ関連）のディレクトリ構成を次の図に示します。

図7-6　J2EEアプリケーション（デプロイ関連）のディレクトリ構成

J2EEアプリケーションごとに作られるディレクトリです。

J2EEアプリケーションの開始時に作られるファイルです。J2EEアプリケーション中にホーム，リモートインタフェース，java.rmi.Remoteを実装したインタフェースがあると，それらのパッケージ名やクラス名を基にファイルが作られます。

J2EEアプリケーションの開始時に作られるファイルです。J2EEアプリケーション中にホーム，リモート，ローカル，ローカルホームインタフェースがあると，それらのパッケージ名やクラス名を基にファイルが作られます。

(3)　J2EEリソース

J2EEリソースのディレクトリ構成を次の図に示します。

図7-7　J2EEリソースのディレクトリ構成

EJB-JARファイルごとに作られるディレクトリです。ディレクトリ名はEJB-JARファイル名を基に付けられます。

EJB-JARファイルは，17けたの数字.jarの名前でここに格納されます。

データソースごとに作られるディレクトリです。ディレクトリ名はJDBCドライバのファイル名を基に付けられます。

JDBCドライバのファイルは，17けたの数字.jarの名前でここに格納されます。

JavaMailの設定ごとに作られるディレクトリです。ディレクトリ名はejbmailを基に付けられます。

JavaMailの設定を保存したファイルがここに保存されます。

RARファイルごとに作られるディレクトリです。ディレクトリ名はRARファイル名を基に付けられます。

RARファイルは，17けたの数字.rarの名前でここに格納されます。

WARファイルごとに作られるディレクトリです。ディレクトリ名はWARファイル名を基に付けられます。

WARファイルは，17けたの数字.jarの名前でここに格納されます。

(4)　J2EEリソースアダプタ（コンフィグレーション関連）

J2EEリソースアダプタ（コンフィグレーション関連）のディレクトリ構成を次の図に示します。

図7-8　J2EEリソースアダプタ（コンフィグレーション関連）のディレクトリ構成

RARファイルごとに作られるディレクトリです。ディレクトリ名はRARファイル名を基に付けられます。

RARファイルは，17けたの数字.rarの名前でここに格納されます。

(5)　J2EEリソースアダプタ（デプロイ関連）

J2EEリソースアダプタ（デプロイ関連）のディレクトリ構成を次の図に示します。なお，図中では，同一ディレクトリに複数の種類のファイルが入る場合は，いちばん長いファイル名だけを記載しています。

図7-9　J2EEリソースアダプタ（デプロイ関連）のディレクトリ構成

RARファイル内のJARファイルは，17けたの数字.jarの名前でここに格納されます。

RARファイル内のネイティブライブラリファイルは，ここに格納されます。

(6)　Webアプリケーション（JSP関連）

Webアプリケーション（JSP関連）のディレクトリ構成を次の図に示します。

図7-10　Webアプリケーション（JSP関連）のディレクトリ構成

コンテキストルートに指定した名前でディレクトリが作られます。/が含まれている場合は3文字の文字列に置き換えられます。

JSPをコンパイルしてできたクラスファイルが格納されます。JSPのファイル名に英数字以外の文字が含まれている場合は，それぞれ6文字の文字列に置き換えられます。また，ファイル名が数字で始まる場合は1文字付加されます。

(7)　Webアプリケーション（その他）

Webアプリケーション（その他）のディレクトリ構成を次の図に示します。

図7-11　Webアプリケーション（その他）のディレクトリ構成

コンテキストルートに指定した名前でディレクトリが作られます。/が含まれている場合は3文字の文字列に置き換えられます。

WARファイルに含まれているファイルがここに解凍されます。

(8)　J2EEサーバ，またはWebコンテナサーバの移行コマンド実行後のディレクトリ構成

J2EEサーバ，またはWebコンテナサーバの移行コマンド実行時，作業ディレクトリの下に作業ディレクトリ_oldの名前でディレクトリを作成し，そこに旧バージョンの作業ディレクトリ下のファイルを退避します。将来，アップグレードインストールをするためには，パス長に作業ディレクトリ_old分の余裕が必要です。J2EEサーバ，またはWebコンテナサーバの移行コマンド実行後のディレクトリ構成を次の図に示します。

図7-12　J2EEサーバ，またはWebコンテナサーバの移行コマンド実行後のディレクトリ構成

(9)　リソースアダプタの移行コマンド実行後のディレクトリ構成

リソースアダプタの移行コマンド実行時，rarupdate_bkの名前でディレクトリを作成し，各J2EEサーバのリソースアダプタのファイルを退避します。作業ディレクトリが「・・・¥<ディレクトリ名>，または・・・/<ディレクトリ名>」の場合，バックアップRARディレクトリは，「・・・¥<ディレクトリ名>¥rarupdate_bk，または・・・/<ディレクトリ名>/rarupdate_bk」になります。リソースアダプタの移行コマンド実行後のディレクトリ構成を次の図に示します。

図7-13　リソースアダプタの移行コマンド実行後のディレクトリ構成

作業ディレクトリの下にrarupdate_bkのパス長を追加する余裕がない場合は，移行コマンド実行時に-backuptoオプションでバックアップ先ディレクトリを指定し，パス長に余裕がある領域にファイルを退避できます。-backuptoオプションを使用する場合のリソースアダプタの移行コマンド実行後のディレクトリ構成を次の図に示します。

図7-14　リソースアダプタの移行コマンド実行後のディレクトリ構成（-backuptoオプションでバックアップ先ディレクトリを指定する場合）

7.10.2　作業ディレクトリのパス長の見積もり式

作業ディレクトリのパス長の見積もり式は次のようになります（単位：バイト）。これらの式がすべて満たされるように，各種パラメタを調整してください。なお，見積もり式中の「最大パス長」とは，OSで規定されているパス長の制限のことです。OSのパス長の制限については，ご使用のOSのドキュメントなどで確認してください。

A+2×B+C+D+E+58≦最大パス長

A+2×B+C+E'+61≦最大パス長

A+2×B+C+E''+50≦最大パス長

A+2×B+C+D+（F+37またはM+68のどちらか大きい方の値）+23≦最大パス長（F≦35の場合は35で換算）

A+2×B+C+G+22≦最大パス長（G≦18の場合は18で換算）

A+B+C+H+I+8≦最大パス長

A+2×B+C+J+34≦最大パス長

J+K+18≦最大パス長

A+2×B+C+L+43≦最大パス長（Cosminexus RM使用時）

K+L+27≦最大パス長（Cosminexus RM使用時）

A+2×B+C+H+L+I+N+22≦最大パス長

A+2×B+C+H+L+O+N+39≦最大パス長

P+H+I+N+3≦最大パス長

O+H+M+N+20≦最大パス長

（凡例）

A：作業ディレクトリまでのパスの長さ

B：作業ディレクトリ名の長さ

C：最も長いサーバ名の長さ

D：最も長いJ2EEアプリケーション名の長さ

E：インポートしたときのEJB-JARファイル，WARファイル，RARファイル，ライブラリJAR，EARのファイル名のうち，最も長いファイル名（EARファイルに含まれているファイルも含む）の長さ

E'：インポートしたときのEJB-JARファイル，WARファイル，RARファイル，JDBCドライバ，メールのファイル名のうち，最も長いファイル名（EARファイルに含まれているファイルも含む）の長さ（メールは7で換算）

E''：インポートしたときのRARファイル名のうち，最も長いファイル名の長さ

F：J2EEアプリケーションに含まれるEJBのインタフェースクラス，java.rmi.Remoteを実装したインタフェースやクラス，EJBのコンポーネントクラスのうち，最も長いファイル名（パッケージ名も含む）の長さ

G：ネイティブライブラリファイルのうち，最も長いファイル名の長さ

H：最も長いコンテキストルートの長さ（/を含む場合は/×3で換算）

I：WARファイル内で最も長いパスの長さ

J：最も長いリソースアダプタ表示名の長さ

K：ログファイル出力先ディレクトリのパスの長さ（簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.server.log.directoryパラメタで指定する値）

L：最も長いCosminexus RMの表示名の長さ

M：J2EEアプリケーションに含まれるEJBのBeanクラスのうち，最も長いクラス名（パッケージ名を含まない）の長さ

N：最も長いJSP／タグファイルコンパイル結果のクラス名の長さ

O：最も長いタグファイルのパッケージ名の長さ

P：JSP用テンポラリディレクトリまでのパスの長さ

7.11　バッチサーバの作業ディレクトリ

バッチサーバは作業ディレクトリ中にサーバ名などを用いてディレクトリやファイルを生成します。ディレクトリ名やファイル名，パス全体の長さには上限があり，作業ディレクトリ全体がパス全体の上限に収まらないとバッチサーバは正常に動作できません。ここでは，作業ディレクトリの構成と作業ディレクトリのパス長の見積もり式について説明します。

＜この節の構成＞

7.11.1　バッチサーバの作業ディレクトリの構成

7.11.2　作業ディレクトリのパス長の見積もり式

7.11.1　バッチサーバの作業ディレクトリの構成

バッチサーバの作業ディレクトリは，バッチサーバが動作する上で必要な作業領域です。この領域には，ユーザのパスワード情報，インポートされたリソースアダプタなどの情報が格納されます。

バッチサーバは，作業ディレクトリ以下にバッチサーバごとの専用ディレクトリ構造を持ちます。このため，複数のバッチサーバで共通のディレクトリを指定できます。

作業ディレクトリを別のマシンに移動した場合，別のマシン上のバッチサーバでは認識できません。

作業ディレクトリでは，2バイトコードを含むパス名称を利用できません。

作業ディレクトリのデフォルトを次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥public

UNIXの場合
/opt/Cosminexus/CC/server/public

作業ディレクトリは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.public.directoryパラメタで変更できます。

バッチサーバには，次の作業ディレクトリがあります。

J2EEリソース

J2EEリソースアダプタ（コンフィグレーション関連）

J2EEリソースアダプタ（デプロイ関連）

なお，2.および3.はJ2EEサーバの場合と同じです。詳細は，「7.10.1(4)　J2EEリソースアダプタ（コンフィグレーション関連）」および「7.10.1(5)　J2EEリソースアダプタ（デプロイ関連）」を参照してください。

ここでは，J2EEリソースの作業ディレクトリの構成について説明します。また，移行コマンド実行後のディレクトリ構成についても説明します。

＜この項の構成＞

(1)　J2EEリソース

(2)　バッチサーバの移行コマンド実行後のディレクトリ構成

(3)　リソースアダプタの移行コマンド実行後のディレクトリ構成

(1)　J2EEリソース

J2EEリソースのディレクトリ構成を図で示したあと，各ディレクトリを説明します。なお，図中の番号と説明の番号は対応しています。また，図中では，同一ディレクトリに複数の種類のファイルが入る場合は，いちばん長いファイル名だけを記載しています。

図7-15　J2EEリソースのディレクトリ構成

RARファイルごとに作られるディレクトリです。ディレクトリ名はRARファイル名を基に付けられます。

RARファイルは，17けたの数字.rarの名前でここに格納されます。

(2)　バッチサーバの移行コマンド実行後のディレクトリ構成

バッチサーバの移行コマンド実行時，作業ディレクトリの下に作業ディレクトリ_oldの名前でディレクトリを作成し，そこに旧バージョンの作業ディレクトリ下のファイルを退避します。バッチサーバの移行コマンド実行後のディレクトリ構成は，J2EEサーバの場合と同じです。詳細は，「7.10.1(8)　J2EEサーバ，またはWebコンテナサーバの移行コマンド実行後のディレクトリ構成」を参照してください。この際，「J2EEサーバ」を「バッチサーバ」に置き換えてお読みください。

(3)　リソースアダプタの移行コマンド実行後のディレクトリ構成

リソースアダプタの移行コマンド実行時，rarupdate_bkの名前でディレクトリを作成し，各バッチサーバのリソースアダプタのファイルを退避します。リソースアダプタの移行コマンド実行後のディレクトリ構成については，「7.10.1(9)　リソースアダプタの移行コマンド実行後のディレクトリ構成」を参照してください。

7.11.2　作業ディレクトリのパス長の見積もり式

作業ディレクトリのパス長の見積もり式は次のようになります（単位：バイト）。これらの式がすべて満たされるように，各種パラメタを調整してください。なお，見積もり式中の「最大パス長」とは，OSで規定されているパス長の制限のことです。OSのパス長の制限については，ご使用のOSのドキュメントなどで確認してください。

A+2×B+C+D+61≦最大パス長

A+2×B+C+E+34≦最大パス長

E+F+18≦最大パス長

（凡例）

A：作業ディレクトリまでのパスの長さ

B：作業ディレクトリ名の長さ

C：最も長いサーバ名の長さ

D：インポートしたときのRARファイル名のうち，最も長いファイル名の長さ

E：最も長いリソースアダプタ表示名の長さ

F：ログファイル出力先ディレクトリのパスの長さ（簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejb.server.log.directoryパラメタで指定する値）

8.　J2EEアプリケーションを実行するシステムの構築

この章では，Smart Composer機能を使用した，J2EEアプリケーションを実行するシステムの構築について説明します。

＜この章の構成＞

8.1　システム構築の概要

8.2　負荷分散機の設定

8.3　アプリケーションサーバから負荷分散機を制御するための設定

8.4　システムの構成定義

8.5　DB ConnectorのConnector属性ファイルの編集

8.6　システムの一括構築

8.7　システムの一括起動（READY）

8.8　リソースとJ2EEアプリケーションの設定

8.9　システムの一括起動（サービスユニットの開始）

8.10　チューニング

8.11　構成定義パターンごとの簡易構築定義ファイルの作成

8.12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

8.13　障害に対応したシステムの構築

8.1　システム構築の概要

各サーバの初期設定が終わったら，システムの一括構築，リソースアダプタのインポートと開始，J2EEアプリケーションのインポートと開始の順に操作してシステムを構築していきます。

ここでは，Smart Composer機能を使用したシステム構築の概要を説明します。なお，JP1やクラスタソフトウェアと連携するシステムを構築する場合は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の次の個所もあわせて参照してください。

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

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

＜この節の構成＞

8.1.1　コマンドとシステム構築の関係

8.1.2　システム構築で使用するファイル

8.1.3　システム構築の流れ

8.1.1　コマンドとシステム構築の関係

Smart Composer機能を使用してシステムを構築する場合，システムの構築にはSmart Composer機能で提供するコマンドを使用します。また，リソースアダプタとアプリケーションの設定には，サーバ管理コマンドを使用します。Smart Composer機能のコマンドは運用管理サーバ上で実行し，サーバ管理コマンドはアプリケーションサーバ上で実行します。

ここでは，Smart Composer機能のコマンドとシステム構築の関係，およびサーバ管理コマンドとシステム構築の関係について説明します。

●システムの一括構築で使用するコマンド

J2EEアプリケーションを実行するシステムの一括構築では，Smart Composer機能のコマンドを使用します。Smart Composer機能のコマンドとシステム構築の関係を次の図に示します。Smart Composer機能のコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「8.　Smart Composer機能で使用するコマンド」を参照してください。

図8-1　Smart Composer機能のコマンドとシステム構築の関係（J2EEアプリケーションを実行するシステムの一括構築）

図中の記号（A-1～A-2）について説明します。

操作 | 図中の記号 | 操作の詳細 | 使用するコマンド
システムの一括構築 | A-1 | 簡易構築定義ファイルの情報を基にして，Management Server上にシステムの情報モデルを生成します。 | cmx_build_system
A-2 | 生成した情報モデルに従って，すべてのアプリケーションサーバ上にシステムを構築します。

参考

cmx_から始まるSmart Composer機能のコマンドには共通引数（-m，-u，-p，-waitまたは-nowait，-verboseまたは-noverbose）があります。共通引数を省略したときのデフォルト値を，.cmxrcまたはcmxclient.propertiesに設定できます。

省略時のデフォルト値を，クライアントごとに設定する場合は.cmxrcに，すべてのクライアント共通で設定する場合はcmxclient.propertiesに設定します。

.cmxrcについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　.cmxrc（クライアント設定プロパティファイル）」を参照してください。cmxclient.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.4　cmxclient.properties（クライアント共通設定プロパティファイル）」を参照してください。

●リソースアダプタとJ2EEアプリケーションのインポートと開始で使用するコマンド

リソースアダプタおよびJ2EEアプリケーションのインポートと開始では，サーバ管理コマンドを使用します。サーバ管理コマンドとシステム構築の関係を次の図に示します。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

2.3　J2EEアプリケーションで使用するコマンド

2.4　J2EEサーバで使用するリソース操作コマンド

図8-2　サーバ管理コマンドとシステム構築の関係（リソースアダプタおよびJ2EEアプリケーションのインポートと開始）

図中の記号（B-1～C-3）について説明します。

操作 | 図中の記号 | 操作の詳細 | 使用するコマンド
リソースアダプタのインポートと開始 | B-1 | リソースアダプタをJ2EEサーバにインポートします。 | cjimportres
B-2 | J2EEサーバにリソースアダプタをデプロイします。 | cjdeployrar
B-3 | Connector属性ファイルをリソースアダプタに反映します。 | cjsetrarprop
B-4 | リソースアダプタの接続テストをします。 | cjtestres
B-5 | J2EEサーバでリソースアダプタを開始します。 | cjstartrar
J2EEアプリケーションのインポートと開始 | C-1 | J2EEアプリケーションをJ2EEサーバにインポートします。 | cjimportapp
C-2 | J2EEサーバでJ2EEアプリケーションを開始します。 | cjstartapp

リソースアダプタおよびJ2EEアプリケーションのインポートと開始は，J2EEサーバごとに実施してください。

参考

サーバ管理コマンドを実行する際には-nameserverオプションにプロバイダURLを指定する必要があります。-nameserverオプションに指定するプロバイダURLは，usrconf.properties（サーバ管理コマンド用システムプロパティファイル）に幾つかの設定をすることで省略できます。プロバイダURLを省略するための設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.4　サーバ管理コマンドで指定するプロバイダURL」を参照してください。

●コマンドを実行するサーバ

コマンドの種類によって，コマンドを実行するサーバが異なります。コマンドの種類ごとに，コマンドを実行するサーバを次に示します。

Smart Composer機能のコマンドを使用する場合
運用管理サーバでコマンドを実行します。

サーバ管理コマンドを使用する場合
各アプリケーションサーバで，それぞれコマンドを実行します。

コマンドの種類と，コマンドを実行するサーバの関係を次の図に示します。ここでは，アプリケーションサーバマシンが2台ある構成を例に説明しています。

図8-3　コマンドを実行するサーバ

8.1.2　システム構築で使用するファイル

ここでは，システムの構築で使用するファイルのうち，主なファイルについて説明します。ここで説明していないファイルについては，システム構築の手順の中で適宜説明します。

注意

ファイルを変更する場合は，J2EEサーバを停止してください。J2EEサーバの稼働中にファイルの内容を変更した場合の動作は保証されません。

＜この項の構成＞

(1)　Management Serverのファイル

(2)　Smart Composer機能のファイル

(3)　J2EEサーバのファイル

(4)　Webサーバ連携で使用するファイル

(1)　Management Serverのファイル

adminagent.xml（運用管理エージェント設定ファイル）
運用管理エージェントが論理サーバを起動，停止するときに使用する環境変数を指定するファイルです。
ファイルの格納場所を次に示します。adminagent.xmlについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.5　adminagent.xml（運用管理エージェント設定ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥adminagent.xml

UNIXの場合
/opt/Cosminexus/manager/config/adminagent.xml

adminagent.properties（運用管理エージェントプロパティファイル）
運用管理エージェントのプロパティを指定するファイルです。論理サーバの動作確認レベルやsnapshotログの収集先の設定などで使用します。
ファイルの格納場所を次に示します。adminagent.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.2　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥adminagent.properties

UNIXの場合
/opt/Cosminexus/manager/config/adminagent.properties

mserver.properties（Management Server環境設定ファイル）
Management Serverのプロパティを指定するファイルです。Management Serverの環境設定や障害検知時コマンドの動作の設定などで使用します。
ファイルの格納場所を次に示します。mserver.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥mserver.properties

UNIXの場合
/opt/Cosminexus/manager/config/mserver.properties

(2)　Smart Composer機能のファイル

簡易構築定義ファイル
Smart Composer機能のコマンドで構築するWebシステムを定義するファイルです。また，リダイレクタ，Webコンテナ間のリクエスト送受信時や，レスポンス送受信時の通信タイムアウトも設定します。
任意の場所に格納できます。簡易構築定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxdefcombinedmodel.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxdefcombinedmodel.xml

参考

システム運用中は，簡易構築定義ファイルをシステムの資産として保持し，設定情報を常に管理することを推奨します。

システムを構築したあとに，システムの設定内容を変更する場合は，システム構築時に使用した簡易構築定義ファイルをメンテナンスします。メンテナンスした簡易構築定義ファイルを基にシステムを再構築すると，メンテナンス結果がシステムに反映されます。

システムを構築したあとにシステムの構成変更をする場合は，構成変更定義ファイルを使用してください。簡易構築定義ファイルの編集で，システムの構成変更はできません。

構成変更定義ファイル
Smart Composer機能のコマンドで構築したWebシステムの構成を変更する内容（サービスユニットの追加，ホストの追加など）を定義します。
任意の場所に格納できます。構成変更定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。構成変更定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.7　構成変更定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxaddcombinedmodel.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxaddcombinedmodel.xml

参考

論理サーバのパラメタを変更する場合は，システムの構築時に使用した簡易構築定義ファイルをメンテナンスしてください。

スケールアウト用ホスト定義ファイル
Smart Composer機能のコマンドで構築した，ホスト単位管理モデルのWebシステムをスケールアウトする場合に，複製先のWebシステムの構成内容を定義します。
任意の場所に格納できます。スケールアウト用ホスト定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。スケールアウト用ホスト定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.9　スケールアウト用ホスト定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxscaleouthostdef.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxscaleouthostdef.xml

cmxserver.properties（サーバ設定プロパティファイル）
Smart Composer機能のコマンドの実行環境を設定します。
ファイルの格納場所を次に示します。cmxserver.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.2　cmxserver.properties（サーバ設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

.cmxrc（クライアント設定プロパティファイル）
Smart Composer機能のコマンドの共通引数のデフォルト値を設定できます。クライアントごとに，異なるデフォルト値を設定したい場合に使用します。
コマンドを実行するOSユーザのホームディレクトリに格納します。.cmxrcのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。.cmxrcについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　.cmxrc（クライアント設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥.cmxrc

UNIXの場合
/opt/Cosminexus/manager/config/templates/.cmxrc

cmxclient.properties（クライアント共通設定プロパティファイル）
Smart Composer機能のコマンドの共通引数のデフォルト値を設定できます。すべてのクライアントに，共通のデフォルト値を設定したい場合に使用します。
ファイルの格納場所を次に示します。cmxclient.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.4　cmxclient.properties（クライアント共通設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

lb.properties（負荷分散機定義プロパティファイル）
負荷分散機へのアクセスに必要な接続情報を設定します。
ファイルの格納場所を次に示します。lb.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.5　lb.properties（負荷分散機定義プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

(3)　J2EEサーバのファイル

server.policy（J2EEサーバ用セキュリティポリシーファイル）
J2EEサーバを実行するJavaVMのセキュリティポリシーを指定するファイルです。
ファイルの格納場所を次に示します。セキュリティポリシーファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.5　server.policy（J2EEサーバ用セキュリティポリシーファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥server.policy

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/server.policy

hitachi_web.properties（J2EEサーバ用Webアプリケーションプロパティファイル）
Webアプリケーション個別のプロパティを指定するファイルです。なお，J2EEサーバ全体でのプロパティは，簡易構築定義ファイルで指定します。
ファイルの格納場所を次に示します。Webアプリケーションプロパティファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2　hitachi_web.properties（J2EEサーバ用Webアプリケーションプロパティファイル）」を参照してください。

Windowsの場合
<WebアプリケーションのWEB-INFディレクトリ>¥hitachi_web.properties

UNIXの場合
<WebアプリケーションのWEB-INFディレクトリ>/hitachi_web.properties

hitachi_web.propertiesを変更した場合，WARファイルを作成，インポートし直してください。

参考

J2EEサーバのファイルには，このほかに次のファイルがあります。Smart Composer機能を使用してシステムを構築する場合，これらのファイルで設定する内容（キー）は，簡易構築定義ファイルのパラメタで設定します。

usrconf.properties（J2EEサーバ用ユーザプロパティファイル）

J2EEサーバのユーザプロパティを指定するファイルです。J2EEサーバが使用するネーミングサービス，トランザクション，コネクション，コンテナ，ログ，セキュリティなどを指定します。

ファイルの格納場所を次に示します。usrconf.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.4　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties

usrconf.cfg（J2EEサーバ用オプション定義ファイル）

J2EEサーバのJavaVMの起動オプションを指定するファイルです。

ファイルの格納場所を次に示します。usrconf.cfgについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.3　usrconf.cfg（J2EEサーバ用オプション定義ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.cfg

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.cfg

usrconf.propertiesおよびusrconf.cfgは，Smart Composer機能を使用しないで，ファイル編集やコマンド実行でシステムを構築する場合などに使用します。

(4)　Webサーバ連携で使用するファイル

workers.properties（ワーカ定義ファイル）
ワーカの定義，およびワーカごとのパラメタを設定します。
ファイルの格納場所を次に示します。workers.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.5　workers.properties（ワーカ定義ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥workers.properties

UNIXの場合
/opt/Cosminexus/CC/web/redirector/workers.properties

mod_jk.conf（Hitachi Web Server用リダイレクタ動作定義ファイル）
Hitachi Web Serverでのリダイレクタの動作を設定します。mod_jk.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.3　mod_jk.conf（Hitachi Web Server用リダイレクタ動作定義ファイル）」を参照してください。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥mod_jk.conf

UNIXの場合
/opt/Cosminexus/CC/web/redirector/mod_jk.conf

httpsd.conf（Hitachi Web Server定義ファイル）
Hitachi Web Serverの動作環境を定義するディレクティブ（Webサーバの実行環境を定義するパラメタ）を設定します。httpsd.confについては，マニュアル「Hitachi Web Server」を参照してください。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥httpsd¥conf¥httpsd.conf

UNIXの場合
/opt/hitachi/httpsd/conf/httpsd.conf

httpsd.confに設定するディレクティブは，簡易構築定義ファイルでも定義できます。論理Webサーバ（web-server）の<configuration>タグ内でAppendDirectivesパラメタまたはAllTextパラメタで定義してください。

注意

システムの一貫性を保つため，細かい設定を変更する場合でも，構築時に使用したファイル（簡易構築定義ファイルまたはhttpsd.conf）を編集して再構築してください。

参考

Webサーバ連携で使用するファイルには，このほかに次のファイルがあります。

uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）

Microsoft IISでのURLパターンとワーカのマッピングを設定します。

ファイルの格納場所を次に示します。

<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥uriworkermap.properties

isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）

Microsoft IISでのリダイレクタの動作を設定します。

ファイルの格納場所を次に示します。

<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.conf

uriworkermap.propertiesおよびisapi_redirect.confは，Webサーバ連携でMicrosoft IISを利用する場合に使用します。Microsoft IISによるWebサーバ連携は，Webリダイレクタ環境構築時や，Smart Composer機能を使用しないでアプリケーションの実行環境を構築する場合に使用します。uriworkermap.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.4　uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）」を参照してください。isapi_redirect.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.2　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

注意

ユーザ定義ファイルに関する注意事項を次に示します。

上書きインストールの場合，ユーザ定義ファイルは上書きされません。

アップグレードインストールの場合のワーカ定義ファイル，およびWebサーバ定義ファイルの処理については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「12.　旧バージョンのアプリケーションサーバからの移行」を参照してください。

リダイレクタ動作定義ファイルの1行の最大文字数は，1,023文字です。この文字数内で定義してください。

ワーカ定義ファイル，およびリダイレクタ動作定義ファイルの場合，キーの一部を簡易構築定義ファイルのパラメタで定義できます。簡易構築定義ファイルで設定した内容は，テキストエディタなどで直接編集しなくても，ワーカ定義ファイルと，リダイレクタ動作定義ファイルに反映されます。なお，Smart Composer機能でシステムを構築する場合は，システムの一貫性を保つため，細かい設定を変更する場合でも，簡易構築定義ファイルを編集するようにしてください。テキストエディタなどで個別にファイルを直接編集する場合には，スペルミスなどに十分注意してください。

次のユーザ定義ファイルで，同じ名称のパラメタが複数指定されている場合は，最初に指定されたパラメタの値を使用して動作します。
・isapi_redirect.conf
・workers.properties
・uriworkermap.properties

8.1.3　システム構築の流れ

ここでは，J2EEアプリケーションを実行するシステムでの，Smart Composer機能を使用したシステム構築の流れについて説明します。なお，システム構築を開始する前に，各サーバのインストールと初期設定が完了している必要があります。

システム構築の流れを次の図に示します。

図8-4　システム構築の流れ（J2EEアプリケーションを実行するシステムの場合）

図中の1.～7.について説明します。

インストールと初期設定
システム構成に合わせて，アプリケーションサーバ，運用管理サーバ，データベースサーバなどにそれぞれ必要な製品をインストールします。必要に応じて，OSやデータベースなどのホスティング環境を設定します。
また，各サーバでの環境変数の設定，Management Serverのセットアップと設定などを実施します。初期設定で実施する作業については，「7.1　インストールと初期設定の概要」を参照してください。

負荷分散機の設定

負荷分散機の設定
負荷分散機を使用するために，sshコマンドの実行環境を設定します。負荷分散機を使用する構成定義パターンの場合にだけ必要な作業です。詳細については，「8.2　負荷分散機の設定」を参照してください。

アプリケーションサーバから負荷分散機を制御するための設定
lb.propertiesで，負荷分散機へのアクセスに必要な接続情報を設定します。負荷分散機を使用する構成定義パターンの場合にだけ必要な作業です。詳細については，「8.3　アプリケーションサーバから負荷分散機を制御するための設定」を参照してください。

システムの構成定義
簡易構築定義ファイルで，システムの構成を定義します。簡易構築定義ファイルはエディタを使用して作成しますが，テンプレートファイルが用意されているので，構成の基本情報を設定するだけで運用できます。詳細については，「8.4　システムの構成定義」を参照してください。

DB ConnectorのConnector属性ファイルの編集
DB Connectorを使用する場合，Connector属性ファイルのテンプレートを取得して，編集します。リソースを利用する場合に，DB Connectorを使用して接続するときに必要な作業です。詳細については，「8.5　DB ConnectorのConnector属性ファイルの編集」を参照してください。

システムの構築

システムの一括構築
システムの一括構築では，次の二つの内容を実施します。
・構成定義で作成した簡易構築定義ファイルの情報を基に，Management Server上にシステムの情報モデルを生成する
・システムの情報モデルからシステムを構築する
システムの構築では，システムの情報モデルの生成から，システムの構築まで，一つのコマンドを使用して一括で実行できます。システムの構成として定義されている，すべてのアプリケーションサーバ上にWebサーバ，J2EEサーバなどのサーバをセットアップし，各論理サーバの環境を設定します。
詳細については，「8.6　システムの一括構築」を参照してください。

システムの一括起動（READY）
リソースアダプタとJ2EEアプリケーションをインポートしたり，開始したりする場合，システムが起動している必要があります。Smart Composer機能のコマンドを使用して，システム内のすべてのサービスユニットを準備状態で開始します。詳細については，「8.7　システムの一括起動（READY）」を参照してください。

リソースアダプタのインポートと開始
リソースを利用する場合に，リソースアダプタのプロパティの設定，インポートおよび開始を実施します。なお，プロパティの設定は，DB Connectorを使用して接続する場合に，Connector属性ファイルを編集済み（4.で実施済み）のときは，作業を省略できます。詳細については，「8.8.3　リソースアダプタのインポートと開始」を参照してください。

J2EEアプリケーションのインポートと開始
J2EEアプリケーションのインポートと開始を実施します。なお，J2EEアプリケーションは，開発環境で作成済みであることが前提になります。詳細については，「8.8.4　J2EEアプリケーションのインポートと開始」を参照してください。

システムの開始
システム内のすべてのサービスユニットを稼働状態にします。詳細については，「8.9　システムの一括起動（サービスユニットの開始）」を参照してください。

チューニング
構築したシステムについて，スループット，レスポンス時間，CPU時間などの性能メトリックの相関が適切かどうか多角的に検証し，必要に応じてシステムの構成を変更します。詳細については，「8.10　チューニング」を参照してください。

また，「6.1.2　障害設計」で説明した運用をするためには，システムを構築したあとで設定が必要です。設定方法については，それぞれ次の個所を参照してください。

障害発生時にサービスユニットを自動閉塞するための設定（8.13.1参照）

サービスユニットを自動再起動するための設定（8.13.2参照）

8.2　負荷分散機の設定

ここでは，負荷分散機の設定について説明します。Smart Composer機能では，負荷分散機としてBIG-IPまたはACOSが使用できます。BIG-IPの場合はBIG-IP v9，BIG-IP v10.1またはBIG-IP v10.2，ACOSの場合はAX2000，AX2500またはBS320が使用できます。

アプリケーションサーバは，使用する負荷分散機によって接続方法が異なります。

BIG-IP（BIG-IP v9，BIG-IP v10.1またはBIG-IP v10.2）の場合
接続方法は，sshプロトコルを使用した直接接続です。運用管理サーバ（Management Serverが稼働するサーバマシン）で，sshのクライアント環境を設定する必要があります。

ACOS（AX2000またはBS320）の場合
接続方法は，telnetプロトコルを使用した直接接続です。

ACOS（AX2500）の場合
接続方法は，API（RESTアーキテクチャ）を使用した直接接続です。運用管理サーバ（Management Serverが稼働するサーバマシン）でアクセスリスト（ACL）を作成する必要があります。また，cookieを利用してセッションを維持する場合には，仮想化システム管理用サーバマシンでcookieパーシステンステンプレートを作成する必要があります。

＜この節の構成＞

8.2.1　BIG-IPでの負荷分散機の設定

8.2.2　ACOS（AX2500）での負荷分散機の設定

8.2.1　BIG-IPでの負荷分散機の設定

BIG-IP（BIG-IP v9，BIG-IP v10.1またはBIG-IP v10.2）の場合，負荷分散機の設定は，使用するOSによって異なります。Windowsの場合とUNIXの場合について説明します。

＜この項の構成＞

(1)　Windowsの場合

(2)　UNIXの場合

(1)　Windowsの場合

運用管理サーバ（Management Serverが稼働するサーバマシン）にsshクライアントプログラムが必要です。使用できるsshクライアントプログラムは，PuTTYのCLIコマンドです。事前にPuTTYを入手し，インストールします。また，PuTTYのインストールフォルダ以下にあるplinkコマンドが格納されたフォルダを，システム環境変数Pathに追加します。環境変数については，「7.3.1　環境変数の設定の要否」を参照してください。なお，Windowsの場合，以降に記述しているsshコマンドは，PuTTYのCLIコマンドを指します。

(2)　UNIXの場合

sshコマンドは，初めて使用する際に接続確認の問い合わせ要求を実行します。負荷分散機を使用する場合は，この問い合わせを抑止する必要があります。Management Serverを起動する前に，運用管理サーバ（Management Serverが稼働するサーバマシン）で次に示す設定をして，問い合わせを抑止してください。

root権限のあるユーザでsshコマンドを実行して負荷分散機と接続し，接続確認の問い合わせ要求（Are you sure you want to continue connecting (yes/no)?）に対して「yes」を応答してください。「yes」を応答したあと，sshコマンドは接続確認の問い合わせ要求を実行しなくなります。

8.2.2　ACOS（AX2500）での負荷分散機の設定

ACOS（AX2500）の場合，運用管理サーバ（Management Serverが稼働するサーバマシン）でアクセスリスト（ACL）を作成する必要があります。また，cookieを利用してセッションを維持する場合には，仮想化システム管理用サーバマシンでcookieパーシステンステンプレートを作成する必要があります。それぞれの設定内容を次に示します。なお，作成方法の詳細は，ACOSのドキュメントを参照してください。

アクセスリスト（ACL）の設定内容
IDに「1」，アクションに「許可」，送信元アドレスに「複数」を設定してください。ただし，負荷分散機に対して接続制限をする場合は，アクションおよび送信元アドレスに任意の値を設定してください。

cookieパーシステンステンプレートの設定内容
cookie名に「任意の値」，expireに「0」を設定してください。expireに0を指定すると，現在のセッションだけが保持されます。

注意

IDに「1」以外を設定してACLを作成した場合，API（RESTアーキテクチャ）を使用した直接接続が使用できません。

8.3　アプリケーションサーバから負荷分散機を制御するための設定

アプリケーションサーバから負荷分散機を制御する場合は，負荷分散機への接続の設定をする必要があります。ここでは，負荷分散機への接続設定について説明します。Smart Composer機能では，負荷分散機としてBIG-IPまたはACOSが使用できます。

負荷分散機への接続の設定は，lb.properties（負荷分散機定義プロパティファイル）で実施します。lb.propertiesには，負荷分散機へのアクセスに必要な接続情報を設定します。

●lb.propertiesの格納場所

lb.propertiesは，次の場所に格納されています。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合

/opt/Cosminexus/manager/config/

●lb.propertiesで設定するキー

設定するキーを次に示します。なお，キーには負荷分散機独自のものと，共通のものがあります。

BIG-IPおよびACOS共通で使用するキー

lb.list
負荷分散機の管理IPアドレスを設定します。負荷分散機が複数ある場合はコンマで区切って指定します。

lb.connect_type.<負荷分散機の管理IPアドレス>
負荷分散機への接続方式を設定します。BIG-IPの場合は「ssh」，ACOS（AX2000またはBS320）の場合は「telnet」，ACOS（AX2500）の場合は「API」を設定してください。

BIG-IPで使用するキー

lb.ssh.port.<負荷分散機の管理IPアドレス>
負荷分散機のsshサーバのポート番号を設定します。

lb.ssh.user.<負荷分散機の管理IPアドレス>
負荷分散機にsshで接続するときのユーザ名を設定します。

lb.ssh.passwd.<負荷分散機の管理IPアドレス>
負荷分散機にsshで接続するときのパスワードを設定します。

lb.ssh.timeout.<負荷分散機の管理IPアドレス>
負荷分散機へのsshコマンド実行（接続処理）時のタイムアウト時間（秒）を設定します。

ACOS（AX2000またはBS320）で使用するキー

lb.telnet.port.<負荷分散機の管理IPアドレス>
負荷分散機のtelnetサーバのポート番号を設定します。

lb.telnet.user.<負荷分散機の管理IPアドレス>
負荷分散機にtelnetで接続するときのユーザ名を設定します。

lb.telnet.passwd.<負荷分散機の管理IPアドレス>
負荷分散機にtelnetで接続するときのパスワードを設定します。

lb.telnet.login_timeout.<負荷分散機の管理IPアドレス>
負荷分散機へのtelnetコマンド実行（接続処理）時のタイムアウト時間（秒）を設定します。

lb.telnet.command_timeout.<負荷分散機の管理IPアドレス>
負荷分散機へのコマンド送信時のタイムアウト時間(秒)を設定します。

lb.telnet.user_prompt.<負荷分散機の管理IPアドレス>
負荷分散機への接続時の，ユーザ名入力プロンプトに表示される文字列を設定します。

lb.telnet.passwd_prompt.<負荷分散機の管理IPアドレス>
負荷分散機への接続時の，パスワード入力プロンプトに表示される文字列を設定します。

lb.telnet.login_prompt.<負荷分散機の管理IPアドレス>
負荷分散機への接続時の，ログイン完了後のプロンプトに表示される文字列を設定します。

ACOS（AX2500）で使用するキー

lb.API.user.<負荷分散機の管理IPアドレス>
負荷分散機にAPIで接続するときのユーザ名を設定します。

lb.API.passwd.<負荷分散機の管理IPアドレス>
負荷分散機にAPIで接続するときのユーザのパスワードを設定します。

lb.API.port.<負荷分散機の管理IPアドレス>
負荷分散機のポート番号を設定します。

lb.API.cookie_persistence_template.<Webシステム名>.<負荷分散機のIPアドレス>
負荷分散機で作成したcookieパーシステンステンプレート名を設定します。

lb.API.timeout.<負荷分散機のIPアドレス>
負荷分散機へのAPIメソッド実行（接続処理）時のタイムアウト時間（秒数）を設定します。

javax.net.ssl.trustStore
トラストストアを設定します。

javax.net.ssl.trustStorePassword
トラストストアのパスワードを設定します。

なお，設定するキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.5　lb.properties（負荷分散機定義プロパティファイル）」を参照してください。

●lb.propertiesの設定例

lb.propertiesの設定例を負荷分散機の種類ごとに示します。

BIG-IP v9，BIG-IP v10.1，BIG-IP v10.2の場合

lb.list=192.168.100.10

lb.connect_type.192.168.100.10=ssh
#lb.ssh.port.192.168.100.10=22
lb.ssh.user.192.168.100.10=user01
lb.ssh.passwd.192.168.100.10=user01pw
#lb.ssh.timeout.192.168.100.10=10

AX2000，BS320の場合

lb.list=192.168.1.100
lb.enable_passwd.192.168.1.100=adminpw

lb.connect_type.192.168.1.100=telnet
#lb.telnet.port.192.168.1.100=23
lb.telnet.user.192.168.1.100=user01
lb.telnet.passwd.192.168.1.100=user01pw
lb.telnet.user_prompt.192.168.1.100="AX login: "
lb.telnet.passwd_prompt.192.168.1.100="Password: "
lb.telnet.login_prompt.192.168.1.100=>
#lb.telnet.login_timeout.192.168.1.100=10
#lb.telnet.command_timeout.192.168.1.100=10

AX2500の場合

lb.list=192.168.10.100
lb.enable_passwd.192.168.10.100=adminpw

lb.connect_type.192.168.10.100=API
lb.API.user.192.168.10.100=user01
lb.API.passwd.192.168.10.100=user01pw
#lb.API.port.192.168.10.100=443
#lb.API.cookie_persistence_template.MyWebSystem.192.168.10.100=SC_COOKIE_TEMPNAME
#lb.API.API.timeout.192.168.10.100=10
javax.net.ssl.trustStore=C:¥¥work¥¥ACOS.keystore
javax.net.ssl.trustStorePassword=keystore_pass

注意

lb.propertiesには，負荷分散機の接続ユーザ名，および接続ユーザのパスワードを記述するため，これらの情報が漏洩しないように適切にファイルのアクセス権を設定してください。

●負荷分散機を冗長化する場合の注意事項

負荷分散機を冗長化する場合は，それぞれの負荷分散機への接続の設定をする必要があります。lb.propertiesには，2台分の負荷分散機へのアクセスに必要な接続情報を設定します。この場合，それぞれの負荷分散機の接続方式（lb.connect_type）には，同じ値を設定してください。

冗長化する場合のlb.propertiesの設定例を負荷分散機の種類ごとに示します。

BIG-IP v9，BIG-IP v10.1，BIG-IP v10.2の場合

ここでは，負荷分散機LB1とLB2を配置した場合で，LB1の管理IPアドレスを「192.168.100.10」，LB2の管理IPアドレスを「192.168.100.20」として説明します。

lb.list=192.168.100.10,192.168.100.20

#冗長化構成の負荷分散機LB1の設定
lb.connect_type.192.168.100.10=ssh
#lb.ssh.port.192.168.100.10=22
lb.ssh.user.192.168.100.10=user01
lb.ssh.passwd.192.168.100.10=user01pw
#lb.ssh.timeout.192.168.100.10=10

#冗長化構成の負荷分散機LB2の設定
lb.connect_type.192.168.100.20=ssh
#lb.ssh.port.192.168.100.20=22
lb.ssh.user.192.168.100.20=user01
lb.ssh.passwd.192.168.100.20=user01pw
#lb.ssh.timeout.192.168.100.20=10

注　太字の部分は同じ値を設定してください。

AX2000，BS320の場合

ここでは，負荷分散機LB1とLB2を配置した場合で，LB1の管理IPアドレスを「192.168.1.100」，LB2の管理IPアドレスを「192.168.1.101」として説明します。

lb.list=192.168.1.100,192.168.1.101

#冗長構成の負荷分散機LB1の設定
lb.enable_passwd.192.168.1.100=adminpw
lb.connect_type.192.168.1.100=telnet
lb.telnet.user.192.168.1.100=user01
lb.telnet.passwd.192.168.1.100=user01pw
lb.telnet.user_prompt.192.168.1.100="AX login: "
lb.telnet.passwd_prompt.192.168.1.100="Password: "
lb.telnet.login_prompt.192.168.1.100=>

#冗長構成の負荷分散機LB2の設定
lb.enable_passwd.192.168.1.101=adminpw
lb.connect_type.192.168.1.101=telnet
lb.telnet.user.192.168.1.101=user01
lb.telnet.passwd.192.168.1.101=user01pw
lb.telnet.user_prompt.192.168.1.101="AX login: "
lb.telnet.passwd_prompt.192.168.1.101="Password: "
lb.telnet.login_prompt.192.168.1.101=>

注　太字の部分は同じ値を設定してください。

AX2500の場合

ここでは，負荷分散機LB1とLB2を配置した場合で，LB1の管理IPアドレスを「192.168.10.100」，LB2の管理IPアドレスを「192.168.10.101」として説明します。

lb.list=192.168.10.100,192.168.10.101

#冗長構成の負荷分散機LB1の設定
lb.enable_passwd.192.168.10.100=adminpw
lb.connect_type.192.168.10.100=API
lb.API.user.192.168.10.100=user01
lb.API.passwd.192.168.10.100=user01pw

#冗長構成の負荷分散機LB2の設定
lb.enable_passwd.192.168.10.101=adminpw
lb.connect_type.192.168.10.101=API
lb.API.user.192.168.10.101=user01
lb.API.passwd.192.168.10.101=user01pw

注　太字の部分は同じ値を設定してください。

なお，設定するキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.5　lb.properties（負荷分散機定義プロパティファイル）」を参照してください。

8.4　システムの構成定義

Smart Composer機能でシステムを構築する場合，簡易構築定義ファイルにシステムの構成定義や論理サーバの環境設定などを定義します。ここでは，簡易構築定義ファイルの作成手順および作成方法について説明します。

＜この節の構成＞

8.4.1　簡易構築定義ファイルの作成手順

8.4.2　テンプレートファイル

8.4.3　簡易構築定義ファイルの設定内容

8.4.4　簡易構築定義ファイルの作成

8.4.1　簡易構築定義ファイルの作成手順

簡易構築定義ファイルはテキストエディタを使用して作成します。テンプレートファイルが用意されているので，構成の基本情報を設定するだけで運用できます。

簡易構築定義ファイルの作成手順を次に示します。

簡易構築定義ファイルのテンプレートファイルを任意の場所にコピーします。
テンプレートファイルについては，「8.4.2　テンプレートファイル」を参照してください。

簡易構築定義ファイルのテンプレートファイルを任意の名称に変更します。
テキストエディタなどを利用して，簡易構築定義ファイルに手順3.～手順7.の情報を定義します。

Management Serverで運用するWebシステム名，Webシステムの表示名などを定義します。
1Webシステムは，<web-system>タグから</web-system>タグまでの範囲に定義します。

負荷分散機を使用する場合は，使用する負荷分散機の種類や，管理用のIPアドレスなどを定義します。
負荷分散機を使用しないシステムの場合，負荷分散機の定義は不要です。負荷分散機は，<load-balancer>タグから</load-balancer>タグまでの範囲に定義します。

システム構成やJ2EEアプリケーションで使用する機能に応じて，物理ティアを定義します。必要に応じて，論理サーバ全体で共通のコンフィグレーションを定義します。
システム構成やJ2EEアプリケーションで使用する機能に応じて，その機能を実現するために必要な論理サーバが決定されます。Smart Composer機能では，同一のデプロイメント（論理サーバの配置，定義設定など）を適用するホスト（サーバマシン）の集合を物理ティアという単位で定義します。物理ティアは，<tier>タグから</tier>タグまでの範囲に，物理ティアの種類や，論理サーバ全体で共通のコンフィグレーションなどを定義します。

論理サーバ（サービスユニット）を配置するホストを定義します。必要に応じて，論理サーバごとのコンフィグレーションを定義します。
Smart Composer機能では，論理サーバの集合をサービスユニットという単位で定義します。サービスユニットは，<unit>タグから</unit>タグまでの範囲に，サービスユニットを配置するホストや，そのホストが属する物理ティア，論理サーバごとのコンフィグレーションなどを定義します。

ホストを定義します。
物理ティアに属するホストのホスト名や，運用管理エージェントのホスト名などを定義します。ホストは，Webシステムに依存しません。Management Serverで定義済みのホストを利用する場合は，ホストの定義を省略できます。ホストは，<host>タグから</host>タグまでの範囲に定義します。

手順3.～手順7.で定義した情報を反映します。

簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。また，Webシステム，物理ティアおよびサービスユニットの概要については，「4.2　J2EEアプリケーションを実行するシステムを構成する要素」を参照してください。

8.4.2　テンプレートファイル

簡易構築定義ファイルのテンプレートファイル（cmxdefcombinedmodel.xml）は，次の場所に提供されています。テンプレートファイルを任意の場所にコピーして，簡易構築定義ファイルを作成してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合

/opt/Cosminexus/manager/config/templates/

参考

テンプレートファイルの文字エンコーディングは，UTF-8です。

8.4.3　簡易構築定義ファイルの設定内容

ここでは，簡易構築定義ファイルの構成と，構築するシステムの構成情報と簡易構築定義ファイルの定義項目の対応について説明します。また，簡易構築定義ファイルで定義できるアプリケーションサーバの機能についても説明します。

＜この項の構成＞

(1)　簡易構築定義ファイルの構成

(2)　コンフィグレーション定義で使用するタグと適用範囲

(3)　アプリケーションサーバの機能を有効にするための設定

(4)　簡易構築定義ファイル作成時の注意事項

(1)　簡易構築定義ファイルの構成

簡易構築定義ファイルでは，Webシステムの次の構成について設定します。

Webシステムの属性定義（<web-system>タグの定義）

負荷分散機の定義（<load-balancer>タグの定義）※1

cookieスイッチングの定義（<load-balancer>タグの<cookie-switching>タグの定義）※2

仮想サーバの定義（<load-balancer>タグの<virtual-server>タグの定義）

物理ティアの定義（<tier>タグの定義）

物理ティアに属する論理サーバの種類ごとの定義（<tier>タグの<configuration>タグの定義）

データベースを使用するための設定の定義（<tier>タグの<configuration>タグの定義）※3

サービスユニットの定義（<unit>タグの定義）

サービスユニットを構成するホストの定義（<unit>タグの<allocation-host>タグの定義）

ホストが属する物理ティアの論理サーバごとの定義（<unit>タグの<allocation-host>タグの<define-server>タグの定義）

ホストの定義（<host>タグの定義）

注※1　Smart Composer機能で負荷分散機の設定，および実サーバポートの開始・閉塞をしない場合は，負荷分散機の定義（<load-balancer>タグの定義）を記述する必要はありません。

注※2　負荷分散機のCookieスイッチング機能を使用する場合に必要です。この設定によって，一連のHTTPリクエストが一つのWebサーバまたはJ2EEサーバで処理されます。また，負荷分散機のCookieスイッチング機能を使用する場合は，物理ティアの定義（<tier>タグ）で，J2EEサーバのWebコンテナの設定に「webserver.container.server_id.enabled=true」を指定してください。

注※3　データベースを使用するための設定の定義については，「7.5　データベースを使用するための設定」を参照してください。

物理ティアおよびサービスユニットのコンフィグレーション定義で，同じパラメタを指定した場合は，サービスユニットの定義，物理ティアの定義の順に優先して適用されます。

J2EEアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応を次の図に示します。

図8-5　J2EEアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応

この図に示すように，簡易構築定義ファイルでは，論理サーバの構成や環境設定だけでなく，負荷分散機やホストも定義できます。なお，構築済みのWebシステムなどで使用しているホストを使用する場合には，ホストの定義を省略することもできます。

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

(2)　コンフィグレーション定義で使用するタグと適用範囲

論理サーバの動作設定や，機能を使用するための設定などは，論理サーバのコンフィグレーションで定義します。論理サーバのコンフィグレーションは，論理サーバ全体，および論理サーバごとに定義できます。論理サーバ全体で共通の定義を設定する場合は物理ティアで，論理サーバごとの定義を設定する場合はサービスユニットで定義します。物理ティアで定義すると，その物理ティアに属するホストに配置する論理サーバ全体で共通のコンフィグレーションが設定されます。なお，Management Serverが自動設定する内容については，「4.8　Management Serverが自動で設定する内容」を参照してください。

論理サーバのコンフィグレーション定義の適用範囲を次の図に示します。

図8-6　論理サーバのコンフィグレーション定義の適用範囲

コンフィグレーション定義時に使用する簡易構築定義ファイルの主なタグを次の表に示します。

表8-1　論理サーバのコンフィグレーション定義時に使用する簡易構築定義ファイルの主なタグ

タグ名称
説明

<configuration>
論理サーバの動作環境を設定します。動作環境を設定する論理サーバの種類は，<logical-server-type>タグで指定します。
<configuration>タグは，物理ティアの定義（<tier>タグ内），およびサービスユニットの定義（<unit>タグ内）に設定できます。<tier>タグ内または<unit>タグ内のどちらの<configuration>タグに設定するかによって，設定内容を適用する論理サーバの範囲が異なります。論理サーバ全体で共通の設定を変更したい場合は，<tier>タグ内の<configuration>タグを編集し，特定の論理サーバの設定を変更したい場合は，<unit>タグ内の<configuration>タグを編集します。

<logical-server-type>
<configuration>タグで動作環境を設定する論理サーバの種類を定義します。論理サーバの種類を次に示します。

論理Webサーバ：web-server

論理J2EEサーバ：j2ee-server

論理SFOサーバ：sfo-server

論理パフォーマンストレーサ：performance-tracer

論理CTMドメインマネジャ：ctm-domain-manager

論理CTM：component-transaction-monitor

論理スマートエージェント：smart-agent

論理ユーザサーバ：user-server（<tier>タグ内には定義できません）

<param>
論理サーバの動作環境を設定するパラメタ（パラメタ名と値の組み合わせ）を定義します。1種類のパラメタごとに<param>タグで囲んで定義します。

<param-name>
論理サーバの動作環境を設定するパラメタの名称を定義します。

<param-value>
<param-name>タグで指定したパラメタの設定値を定義します。

注　各論理サーバの<configuration>タグ内で，パラメタ名（<param-name>タグ）と値（<param-value>タグ）の設定を省略すると，論理サーバの動作環境にはデフォルトの値が設定されます。デフォルトの設定のままで利用する場合は，定義不要です。デフォルトで設定されている動作を変更したい場合や，アプリケーションサーバの機能を有効にしたい場合は，パラメタと値の設定を追加または変更してください。アプリケーションサーバの機能を有効にするための設定については，「(3)　アプリケーションサーバの機能を有効にするための設定」を参照してください。

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

(3)　アプリケーションサーバの機能を有効にするための設定

簡易構築定義ファイルのコンフィグレーション定義では，デフォルトが設定されています。使用するアプリケーションサーバの機能によっては，デフォルトの設定では無効なものもあります。この場合は，簡易構築定義ファイルのパラメタと値を追加または変更して，機能を有効にする設定をします。なお，機能を使用するために設定する項目のうち，一部の設定項目は，簡易構築定義ファイルで定義できません。簡易構築定義ファイルで設定できない項目は，ほかのユーザ定義ファイルを使用して定義します。

例えば，J2EEサーバが使用するネーミングサービス，トランザクション，コネクション，コンテナ，ログ，セキュリティの設定を変更したい場合，J2EEサーバのJavaVMの起動オプションなどを変更したい場合などには，簡易構築定義ファイルで設定を変更します。簡易構築定義ファイルに，テキストエディタなどを使用して，変更対象のパラメタ名と変更後の値を設定します。ただし，J2EEサーバのセキュリティポリシーとWebアプリケーションのプロパティを変更したい場合には，Management Serverでは設定できません。簡易構築定義ファイル以外のユーザ定義ファイル（server.policy，hitachi_web.properties）をテキストエディタなどで編集して，動作設定を変更してください。

注意

server.policyまたはhitachi_web.propertiesを編集する場合は，編集対象のJ2EEサーバのセットアップが完了していることが前提になります。また，UNIXの場合，動作設定を変更するときには，root権限（Component Container管理者を設定していない場合），またはComponent Container管理者の権限（Component Container管理者を設定している場合）が必要です。

Smart Composer機能で使用できるアプリケーションサーバの機能については，「8.12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先」を参照してください。

(4)　簡易構築定義ファイル作成時の注意事項

簡易構築定義ファイル作成時に，論理Webサーバ（web-server）の<configuration>タグ内のSetByパラメタで「text」を指定した場合に，AllTextパラメタでhttpsd.confを直接設定するときの注意事項について説明します。

次のパラメタの指定を有効にするには，「Include "<Cosminexusのインストールディレクトリ>/CC/web/redirector/servers/<論理Webサーバの実サーバ名>/mod_jk.conf"」をAllTextパラメタ内に追記してください。

Hitachi Web Server用リダイレクタ動作定義を設定するパラメタ（マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.13.2　Hitachi Web Server用リダイレクタ動作定義を設定するパラメタ」参照）

ワーカ定義を設定するパラメタ（マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.13.3　ワーカ定義を設定するパラメタ」参照）

Management Serverは，httpsd.confの最後に記述されたListenディレクティブの値で，Webサーバの動作確認をします。AllTextパラメタ内にListenディレクティブを複数記述するときには，動作確認で使用する値を最後に記述してください。

HWSGracefulStopTimeoutディレクティブの値には必ず「0」を設定してください。このパラメタに「0」以外を設定して，cmx_stop_targetコマンドを実行すると，論理Webサーバ（web-server）の<configuration>タグ内のmstartup.force.watchtimeパラメタで設定した強制停止監視時間より前に，Hitachi Web Serverが強制停止されることがあります。

Webサーバのsnapshotログの収集対象を変更するときは，AllTextパラメタではなく，snapshotログ収集対象定義ファイルで編集してください。なお，デフォルトの収集対象は，<Hitachi Web Serverのインストールディレクトリ>/servers/HWS_<論理Webサーバの実サーバ名>/logsです。snapshotログ収集対象定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2　snapshotログ収集対象定義ファイル」を参照してください。

AllTextパラメタ内に次のIncludeディレクティブの指定があると，Webシステムの構築時に警告メッセージが出力されます。SetByパラメタで「text」を指定した場合には，次のIncludeディレクティブを指定しないでください。

Include <Hitachi Web Serverのインストールディレクトリ>/servers/HWS_<論理Webサーバの実サーバ名>/httpsd_manager.conf

8.4.4　簡易構築定義ファイルの作成

ここでは，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）を簡易構築定義ファイルで作成する例について説明します。

簡易構築定義ファイルは，選定した構成定義パターンに合わせて作成します。WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）以外の構成定義パターンと，簡易構築定義ファイルの作成方法の参照先を次の表に示します。

表8-2　構成定義パターンと簡易構築定義ファイルの作成方法の参照先

構成定義パターン | 作成方法の参照先
WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ） | 8.11.2
インプロセスHTTPサーバを使用するパターン（j2ee-tier） | 8.11.3
SFOサーバを使用するパターン（sfo-tier） | 8.11.4
CTMを使用するパターン（ctm-tier） | 8.11.5

なお，JP1/SC/DPMの利用，負荷分散機の冗長化，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。

物理ティアの定義
物理ティアの種類にはcombined-tierを定義します。combined-tierでは，Webサーバ，J2EEサーバおよびパフォーマンストレーサのコンフィグレーションを設定できます。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の構成情報の例を次の図に示します。

図8-7　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図8-7の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，テンプレートファイルをコピーし，ファイル名を「MyWebSystemDef.xml」に変更して作成します。

MyWebSystemDef.xmlの作成例を次に示します。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     <name>MyBIGIPv9</name>
     <load-balancer-type>BIG-IPv9</load-balancer-type>
     <!-- cookieスイッチングの定義 -->
     <cookie-switching>
       <cookie-switching-enabled>true</cookie-switching-enabled>
       <cookie-name>CMX_SERVER_ID</cookie-name>
     </cookie-switching>
     <management-host>192.168.100.10</management-host>
     <!-- 仮想サーバの定義 -->
     <virtual-server>
       <virtual-server-name>www.sample.com</virtual-server-name>
       <ip-address>192.168.1.10</ip-address>
       <http-port>80</http-port>
     </virtual-server>
   </load-balancer>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.container.server_id.enabled</param-name>
          <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
 <host>
   <host-name>apsv2</host-name>
   <agent-host>192.168.100.12</agent-host>
 </host>
</model-definition>

注　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

8.5　DB ConnectorのConnector属性ファイルの編集

DB Connectorを使用する場合，システムを起動する前にConnector属性ファイルを編集できます。なお，DB Connector以外のリソースアダプタを使用する場合は，システムを起動したあと，Connector属性ファイルを取得し，編集します。DB Connector以外のリソースアダプタを使用する場合のConnector属性ファイルの取得と編集については，「8.8.3(2)　DB Connector以外のリソースアダプタのインポートと開始」を参照してください。

ここでは，DBConnector_HiRDB_Type4_CP.rarを使用した場合の，DB ConnectorのConnector属性ファイルの取得，および編集手順を例に使用して説明します。DBConnector_HiRDB_Type4_CP.rar以外のRARファイルを使用する場合は，利用するDB ConnectorのRARファイルに読み替えてください。なお，提供されるRARファイルの種類や使い分けについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.4　DB Connector（RARファイル）の種類」を参照してください。

Connector属性ファイルの編集手順について次に示します。

Connector属性ファイルを取得します。
アプリケーションサーバでは，DB ConnectorのConnector属性ファイルのテンプレートファイルを提供しています。テンプレートファイルの格納先を次に示します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥templates

UNIXの場合

/opt/Cosminexus/CC/admin/templates

DBConnector_HiRDB_Type4_CP.rarを使用する場合，DBConnector_HiRDB_Type4_CP_cfg.xmlを取得します。
Connector属性ファイルのテンプレート，およびテンプレートファイルに関する注意事項については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

Connector属性ファイルを編集します。
取得したConnector属性ファイルを任意の場所に保存します。ここでは，Connector属性ファイルの名称をMyDBConnectorAttr.xmlとして保存します。
保存したConnector属性ファイルにデータベースへの接続の設定などの必要な項目を定義してください。

Connector属性ファイルを編集したあとのDB Connectorのデプロイ手順については，「8.8.3(1)　DB Connectorのインポートと開始」を参照してください。

8.6　システムの一括構築

システムの一括構築では，情報モデルの生成，その情報モデルを基にしたWebサーバおよびJ2EEサーバのセットアップ，および各論理サーバの環境設定を一つのコマンドを使用して一括で実施します。

また，必要に応じて負荷分散機に仮想サーバや実サーバを作成します。

システムを一括構築する手順を次に示します。

運用管理サーバでcmx_build_systemコマンドを使用してシステムを一括構築します。cmx_build_systemコマンドの-fオプションには，簡易構築定義ファイルを指定します。説明では，簡易構築定義ファイルの名称をMyWebSystemDef.xmlとしています。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml

注意

Smart Composer機能では，負荷分散機の基本的な情報（仮想サーバや実サーバの定義，仮想サーバポートと実サーバポートとのバインドなど）だけ設定します。特定のネットワーク構成をサポートするためなどの設定はシステムの一括構築後，手動で設定してください。

Smart Composer機能が実行する負荷分散機のCLIコマンドについては，「付録A　Smart Composer機能が実行する負荷分散機のCLIコマンドまたはAPI」を参照してください。

参考

cmx_から始まるSmart Composer機能のコマンドには共通引数（-m，-u，-p，-waitまたは-nowait，-verboseまたは-noverbose）があります。共通引数を省略したときのデフォルト値を，.cmxrcまたはcmxclient.propertiesに設定できます。

省略時のデフォルト値を，クライアントごとに設定する場合は.cmxrcに，すべてのクライアント共通で設定する場合はcmxclient.propertiesに設定します。

.cmxrcについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　.cmxrc（クライアント設定プロパティファイル）」を参照してください。cmxclient.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.4　cmxclient.properties（クライアント共通設定プロパティファイル）」を参照してください。

8.7　システムの一括起動（READY）

Smart Composer機能のコマンド（cmx_build_systemコマンド）で構築したシステムを，負荷分散機からのリクエストの振り分けを抑止した状態（準備状態）で一括起動します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。

システムを準備状態で一括起動する手順を次に示します。

システムを準備状態で開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを準備状態で起動します。準備状態にするには，-modeオプションに「READY」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

cmx_list_statusコマンドを使用して，システム内のすべてのサービスユニットが準備状態（READY）であることを確認してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_list_status -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem
unit1,MyWebSystem,done,ready
unit2,MyWebSystem,done,ready

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_list_status -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem
unit1,MyWebSystem,done,ready
unit2,MyWebSystem,done,ready

cmx_start_targetコマンドおよびcmx_list_statusコマンドの-sオプションには，簡易構築定義ファイルMyWebSystemDef.xmlの<web-system>タグの<name>タグで指定したWebシステム名を指定します。

8.8　リソースとJ2EEアプリケーションの設定

J2EEサーバは，リソースとして，データベース，OpenTP1，SMTPサーバ，JavaBeansリソースなどを利用できます。使用できるリソースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.1　リソースへの接続方法」を参照してください。ここでは，リソースとJ2EEアプリケーションの設定方法について説明します。また，設定する場合の注意事項についても説明します。

＜この節の構成＞

8.8.1　リソースとJ2EEアプリケーションの設定の前に

8.8.2　リソースとJ2EEアプリケーションのプロパティ定義を設定するための前提

8.8.3　リソースアダプタのインポートと開始

8.8.4　J2EEアプリケーションのインポートと開始

8.8.1　リソースとJ2EEアプリケーションの設定の前に

リソースやJ2EEアプリケーションの設定をする前に，リソースやJ2EEアプリケーションの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。ここでは，リソースやJ2EEアプリケーションの設定時の注意事項や，サーバ管理コマンドを使用するための動作設定について説明します。

＜この項の構成＞

(1)　リソースとJ2EEアプリケーションの設定の注意事項

(2)　サーバ管理コマンドの動作設定のカスタマイズ

(3)　サーバ管理コマンドのログ取得の設定

(1)　リソースとJ2EEアプリケーションの設定の注意事項

リソースとJ2EEアプリケーションの設定をする場合に知っておく必要がある，Server Plug-inを使用する前に必要な設定，サーバ管理コマンド実行時の動作方法，リソースとJ2EEアプリケーションの設定の制約事項などを次に示します。

サーバ管理コマンドとServer Plug-inでは，使用できる機能に差異があります。例えば，セキュリティアイデンティティの設定はサーバ管理コマンドでしか使用できません。サーバ管理コマンドで使用できる機能については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「2.2　サーバ管理コマンドの機能」を参照してください。Server Plug-inで使用できる機能については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「2.3　Server Plug-inの機能」を参照してください。

Server Plug-inを使用する場合には，Eclipseへの組み込みや環境設定などが必要です。Server Plug-inを使用するための設定については，「7.8　Server Plug-inの設定」を参照してください。

Server Plug-inを起動する前に，運用管理エージェントとManagement Serverを起動しておく必要があります。運用管理エージェントの起動，Management Serverの起動については，「7.7　システムの起動と停止の設定」を参照してください。

サーバ管理コマンドは，J2EEサーバが起動している状態で実行できるコマンドです。J2EEサーバおよびその前提プロセスを起動してからサーバ管理コマンドを実行してください。

サーバ管理コマンドでは，J2EEアプリケーションやリソースのプロパティを設定するときに，属性情報が出力されたファイル（属性ファイル）を取得して，テキストエディタなどで編集します。このとき，Connector属性ファイルなど固有の属性ファイルを取得するほかに，すべての属性情報を含んだアプリケーション統合属性ファイルを取得して，属性情報を一括して編集できます。

サーバ管理コマンドには，参照系コマンド，更新系コマンドおよび特権系コマンドがあります。これらは，組み合わせによって，同時に実行できるものと，排他処理されるものがあります。実行時には注意してください。参照系コマンドと更新系コマンドの分類については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

2.3　J2EEアプリケーションで使用するコマンド

2.4　J2EEサーバで使用するリソース操作コマンド

アクセス権やネットワークの設定をしておくことで，サーバ管理コマンド，J2EEサーバおよびCORBAネーミングサービスは，それぞれ別のホストで実行できます。別のホストで実行する場合には，次のことに注意してください。

J2EEサーバ間でCORBAネーミングサービスを共有している場合に，ほかのホスト上で実行されているJ2EEサーバの状態が表示されることがあります。誤操作に注意してください。

各ホストにインストールされているアプリケーションサーバのバージョンが異なると正常に実行できないことがあるので，同じバージョンの環境で使用してください。

(2)　サーバ管理コマンドの動作設定のカスタマイズ

ユーザ定義ファイルを編集すると，サーバ管理コマンドの動作設定をカスタマイズできます。必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。なお，UNIXの場合，カスタマイズにはroot権限，またはComponent Container管理者の権限が必要です。

次のディレクトリにあるコマンドがサーバ管理コマンドのコマンドになります。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin

UNIXの場合
/opt/Cosminexus/CC/admin/bin

コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を参照してください。

(a)　カスタマイズ対象のユーザ定義ファイル

サーバ管理コマンドの動作設定をカスタマイズするには，次のユーザ定義ファイルをテキストエディタなどで編集します。

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）
サーバ管理コマンドのプロパティを指定するファイルです。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥admin¥usrconf¥usrconf.properties

UNIXの場合
/opt/Cosminexus/CC/admin/usrconf/usrconf.properties

詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.4　usrconf.properties（サーバ管理コマンド用システムプロパティファイル）」を参照してください。

usrconf.bat（サーバ管理コマンド用オプション定義ファイル）
Windowsの場合にサーバ管理コマンドのJavaVMの起動オプションを指定するファイルです。
ファイルの格納場所を次に示します。
<Cosminexusのインストールディレクトリ>¥CC¥admin¥usrconf¥usrconf.bat
詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.3　usrconf.bat（サーバ管理コマンド用オプション定義ファイル）」を参照してください。

usrconf（サーバ管理コマンド用オプション定義ファイル）
UNIXの場合にサーバ管理コマンドのJavaVMの起動オプションを指定するファイルです。
ファイルの格納場所を次に示します。
/opt/Cosminexus/CC/admin/usrconf/usrconf
詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.2　usrconf（サーバ管理コマンド用オプション定義ファイル）」を参照してください。

(b)　サーバ管理コマンドのカスタマイズで設定できる主な項目

サーバ管理コマンドのカスタマイズでユーザ定義ファイルを編集して設定できる項目のうち，主な項目とその項目を設定するユーザ定義ファイルおよびキーを次の表に示します。キーの詳細，およびここで説明していないキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.　サーバ管理コマンドで使用するファイル」を参照してください。

表8-3　サーバ管理コマンドのカスタマイズで設定できる主な項目

分類
項目
設定ファイル
設定方法

JavaVM
JavaVMのヒープサイズ
usrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）
add.jvm.argキーに，JavaVMのヒープサイズを指定します。

スマートエージェント
－
usrconf.properties
vbroker.agent.portキーに，サーバ管理コマンドが使用するスマートエージェントのポート番号を指定します。

ログ
Cosminexus TPBrokerのトレースファイル
usrconf.properties
vbroker.orb.htc.tracePathキーに，Cosminexus TPBrokerのトレースファイル出力先のパスを指定します。

サーバ管理コマンドのログ

usrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）

usrconf.properties

サーバ管理コマンドのログは，ログの出力先，ログレベルを変更できます。
詳細は，「(3)　サーバ管理コマンドのログ取得の設定」を参照してください。

（凡例）－：該当しません。

注　ネーミング管理の機能を使用する場合にもサーバ管理コマンドのカスタマイズが必要です。詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.3.6　実行環境での設定」を参照してください。

(3)　サーバ管理コマンドのログ取得の設定

サーバ管理コマンドのログは，ログの出力先，ログレベルを変更できます。変更できる項目と，項目に対応するユーザ定義ファイルとキーを次に示します。

項目 | 対応するユーザ定義ファイルとキー
ログの出力先 | usrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）のUSRCONF_JVM_ARGSキーの-Dejbserver.log.directoryオプション
ログレベル | usrconf.propertiesのejbserver.logger.enabled.*キー

ファイルおよびキーの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.　サーバ管理コマンドで使用するファイル」を参照してください。

(a)　ログの出力先の変更

サーバ管理コマンドのログの出力先を変更する場合は，サーバ管理コマンド用のusrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）でログの出力先ディレクトリを指定します。

ログの出力先の変更

デフォルトのログ出力先を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥admin¥logs

UNIXの場合
/opt/Cosminexus/CC/admin/logs/

サーバ管理コマンドのログの出力先は，usrconf.bat（Windowsの場合），またはusrconf（UNIXの場合）のUSRCONF_JVM_ARGSキーの-Dejbserver.log.directoryオプションで変更できます。

設定例

Windowsの場合
set USRCONF_JVM_ARGS="-Dejbserver.log.directory=C:¥CClogs¥admin"

UNIXの場合
set USRCONF_JVM_ARGS="-Dejbserver.log.directory=/CClogs/admin"

カレントディレクトリ

ログ出力先を相対パスで指定する場合のカレントディレクトリは，サーバ管理コマンドを実行したときのカレントディレクトリです。

例えば，ユーザIDが「user1」でユーザのホームディレクトリが「C:¥Documents and Settings¥user1」の場合に，このユーザIDでログインすると，ログイン直後のカレントディレクトリは「C:¥Documents and Settings¥user1」になります。ここで，サーバ管理コマンドを実行すると，カレントディレクトリは「C:¥Documents and Settings¥user1」になります。

注意

ログの出力先を変更した場合は，J2EEサーバを起動する前に，変更後のログの出力先ディレクトリを作成しておいてください。
変更後のログの出力先ディレクトリがない場合は，サーバ管理コマンドの実行時にKDJE37209-E，KDJE37210-E，KDJE37211-Eのメッセージが出力されて異常終了します。

同一ホスト内で複数のJ2EEサーバを起動させている場合は，ログ出力先が同じディレクトリにならないように，ディレクトリにサーバ名称を含めるなど，サーバごとにユニークなディレクトリ名になるようにしてください。なお，キーの値に同じディレクトリを指定した場合は，動作の保証はしません。

ログの出力先を変更して作業ディレクトリ以外にログを出力する場合，ログファイルはサーバのアンセットアップ時に削除されません。ログファイルを削除したい場合には，手動で削除してください。

JavaVMの保守情報およびガーベージコレクションのログの出力先は，ユーザ定義ファイルで設定しても，usrconf.cfgのadd.jvm.arg=-XX:HitachiJavaLog:<ログ出力先>に設定されている値が優先されます。JavaVMの保守情報およびガーベージコレクションのログの出力先を設定する場合は，注意してください。

Management Serverリモート管理機能から操作した場合，サーバ管理コマンドのログ出力先は変更できません。

(b)　ログレベルの変更

サーバ管理コマンドのログレベルは，ログの重要度を表します。ログレベルには，「Error」，「Warning」，「Information」，「Debug」の四つがあります。ログレベルを設定すると，設定したレベルのログが出力されます。デフォルトでは，Errorレベルのログだけが取得されます。通常はデフォルトのまま利用してください。

ログレベルは，サーバ管理コマンド用のusrconf.propertiesの次のキーで設定します。

ejbserver.logger.enabled.*=<レベル名>

レベル名には，「Error」，「Warning」，「Information」，「Debug」の文字列を一つ，または複数設定します。複数設定する場合には，レベル名の文字列の間をコンマ（,）で区切ります。

記述例

ejbserver.logger.enabled.*=Error

ejbserver.logger.enabled.*=Error,Warning

ejbserver.logger.enabled.*=Error,Warning,Information

ejbserver.logger.enabled.*=Error,Warning,Information,Debug

注意

記述例の1.，2.，3.，4.の順に，取得できるログの件数が増加していきます。複数のログレベルを設定してログを取得すると，性能が劣化し，ログファイルの面の切り替えが頻繁に起こるようになります。

レベル名に「Error」，「Warning」，「Information」，「Debug」以外の文字列，または空の値を設定した場合は，KDJE90009-Wのメッセージが出力されます。Errorレベルのログは取得されます。

8.8.2　リソースとJ2EEアプリケーションのプロパティ定義を設定するための前提

ここでは，リソースとJ2EEアプリケーションのプロパティ定義を設定するための前提について説明します。

＜この項の構成＞

(1)　リソースアダプタのプロパティ定義を設定するための前提

(2)　JavaBeansリソースのプロパティ定義を設定するための前提

(3)　J2EEアプリケーションのプロパティ定義を設定するための前提

(1)　リソースアダプタのプロパティ定義を設定するための前提

リソースアダプタのプロパティは，サーバ管理コマンドを使用して定義します。
cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させてください。なお，リソースアダプタをデプロイする前にプロパティを定義する場合は，cjgetrespropコマンドとcjsetrespropコマンドを使用してください。

項目を設定するConnector属性ファイルのタグの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。サーバ管理コマンドでの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.3.1　J2EEリソースのプロパティの設定手順」を参照してください。

(2)　JavaBeansリソースのプロパティ定義を設定するための前提

JavaBeansリソースのプロパティを新規に設定する場合は，JavaBeansリソース属性ファイルのテンプレートを使用してJavaBeansリソース属性ファイルを作成して，プロパティを定義します。
設定変更の場合は，サーバ管理コマンドでJavaBeansリソース属性ファイルを取得して，プロパティを定義します。cjgetjbpropコマンドでJavaBeansリソース属性ファイルを取得して，ファイル編集後に，cjsetjbpropコマンドで編集内容を反映させてください。

(3)　J2EEアプリケーションのプロパティ定義を設定するための前提

J2EEアプリケーションのプロパティは，cosminexus.xmlで定義します。cosminexus.xmlについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.3.1　cosminexus.xmlとは」を参照してください。
次の場合，サーバ管理コマンドを使用して定義できます。

インポート済みのアプリケーションのプロパティを編集する場合

cosminexus.xmlを含まないアプリケーションの場合

なお，cosminexus.xmlを含むアプリケーションをインポート後に編集する場合は，cosminexus.xmlを編集して，再度アプリケーションを作成し直すことをお勧めします。

サーバ管理コマンドを使用して定義する場合は，cjgetapppropコマンドで属性ファイルを取得し，属性ファイル編集後に，cjsetapppropコマンドで編集内容を反映させてください。なお，ここで示した属性ファイル以外に，J2EEアプリケーションのすべての属性情報が含まれているアプリケーション統合属性ファイルも使用できます。

項目を設定する属性ファイルとタグについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　Cosminexusアプリケーション属性ファイル（cosminexus.xml）」を参照してください。サーバ管理コマンドでの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.3.2　J2EEアプリケーションのプロパティの設定手順」を参照してください。

8.8.3　リソースアダプタのインポートと開始

DB Connectorを使用する場合と，ほかのリソースアダプタを使用する場合で，Connector属性ファイルの取得方法が異なります。使用するリソースアダプタごとにインポートと開始について説明します。リソースアダプタのインポートと開始には，サーバ管理コマンドを使用します。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「2.4　J2EEサーバで使用するリソース操作コマンド」を参照してください。サーバ管理コマンドでのリソースアダプタの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.　リソースアダプタの設定」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表8-4　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。サービスユニット2に対しても，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

J2EEサーバ名：cmx_MyWebSystem_unit2_J2EE_01

-nameserver指定値：corbaname::192.168.1.12:900

＜この項の構成＞

(1)　DB Connectorのインポートと開始

(2)　DB Connector以外のリソースアダプタのインポートと開始

(1)　DB Connectorのインポートと開始

DB Connectorを使用する場合のインポートと開始について説明します。ここでは，次に示すリソースアダプタをインポートして開始する手順を例にして説明します。

表8-5　例で使用するリソースアダプタのファイル名と表示名

種別 | 名前
ファイル名 | DBConnector_HiRDB_Type4_CP.rar※
表示名 | DB_Connector_for_HiRDB_Type4
Connector属性ファイルのファイル名 | MyDBConnectorAttr.xml

注※　HiRDB Type4 JDBC Driverを使用して，ローカルトランザクションまたはトランザクション管理なしでHiRDBに接続する場合に使用するRARファイルです。

なお，「8.5　DB ConnectorのConnector属性ファイルの編集」でConnector属性ファイルの取得と編集が済んでいることを前提にしています。

DB Connectorを使用する場合のリソースアダプタのインポートと開始の手順を次に示します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。

リソースアダプタをインポートします。
サーバ管理コマンドを使用して，リソースアダプタをJ2EEサーバへインポートします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -type rar -f /opt/Cosminexus/CC/DBConnector/DBConnector_HiRDB_Type4_CP.rar

リソースアダプタをデプロイします。
サーバ管理コマンドを使用して，J2EEサーバにリソースアダプタをデプロイします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjdeployrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

編集したConnector属性ファイルをリソースアダプタに反映します。
サーバ管理コマンドを使用して，Connector属性ファイルをリソースアダプタに反映します。-cオプションには，「8.5　DB ConnectorのConnector属性ファイルの編集」で編集したConnector属性ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

リソースアダプタの接続を確認します。
サーバ管理コマンドを使用して，リソースアダプタの接続を確認します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjtestres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

リソースアダプタを開始します。
サーバ管理コマンドを使用して，リソースアダプタを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

(2)　DB Connector以外のリソースアダプタのインポートと開始

DB Connector以外のリソースアダプタを使用する場合のインポートと開始について説明します。

ここでは，次に示すリソースアダプタをインポートして開始する手順を例にして説明します。

表8-6　例で使用するリソースアダプタのファイル名と表示名

種別 | 名前
ファイル名 | MyResourceAdapter.rar
表示名 | MyResourceAdapter
Connector属性ファイルのファイル名 | MyResourceAdapter.xml

なお，提供されるRARファイルの種類や使い分けについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.2　リソースアダプタの種類」を参照してください。

DB Connector以外のリソースアダプタを使用する場合のリソースアダプタのインポートと開始の手順を次に示します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。

リソースアダプタをインポートします。
サーバ管理コマンドを使用して，リソースアダプタをJ2EEサーバへインポートします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -type rar -f <任意のディレクトリ>¥MyResourceAdapter.rar

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -type rar -f <任意のディレクトリ>/MyResourceAdapter.rar

リソースアダプタをデプロイします。
サーバ管理コマンドを使用して，J2EEサーバにリソースアダプタをデプロイします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjdeployrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

Connector属性ファイルを取得します。
サーバ管理コマンドを使用して，Connector属性ファイルを取得します。ここでは，Connector属性ファイルを，MyResourceAdapter.xmlの名前で出力します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjgetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter -c <任意のディレクトリ>¥MyResourceAdapter.xml

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjgetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900  -resname MyResourceAdapter -c <任意のディレクトリ>/MyResourceAdapter.xml

Connector属性ファイルを編集します。
取得したConnector属性ファイルで，データベースへの接続の設定など必要な項目を編集してください。Connector属性ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

編集したConnector属性ファイルをリソースアダプタに反映します。
サーバ管理コマンドを使用して，Connector属性ファイルを各リソースアダプタに反映します。-cオプションには，手順4で編集したConnector属性ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter -c <任意のディレクトリ>¥MyResourceAdapter.xml

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter -c <任意のディレクトリ>/MyResourceAdapter.xml

リソースアダプタの接続を確認します。
サーバ管理コマンドを使用して，リソースアダプタの接続を確認します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjtestres cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

リソースアダプタを開始します。
サーバ管理コマンドを使用して，リソースアダプタを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname MyResourceAdapter

8.8.4　J2EEアプリケーションのインポートと開始

J2EEアプリケーションのインポートと開始について説明します。J2EEアプリケーションのインポートと開始には，サーバ管理コマンドを使用します。サーバ管理コマンドの詳細についてはマニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「2.3　J2EEアプリケーションで使用するコマンド」，サーバ管理コマンドでのJ2EEアプリケーションの操作の詳細については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の次の個所を参照してください。

8.1　J2EEアプリケーションのインポート

10.2.1　J2EEアプリケーションの開始

また，Smart Composer機能のコマンドを使用したJ2EEアプリケーションのインポートと一括開始についても説明します。

ここで説明するJ2EEアプリケーションは作成済みであることを前提としています。また，cosminexus.xmlを含むアプリケーションであることを前提としています。J2EEアプリケーションは，アプリケーション開発時に作成しておいてください。アプリケーションの作成については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表8-7　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。サービスユニット2に対しても，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

J2EEサーバ名：cmx_MyWebSystem_unit2_J2EE_01

-nameserver指定値：corbaname::192.168.1.12:900

ここでは，次に示すJ2EEアプリケーションをインポートして開始する手順を例にして説明します。

表8-8　例で使用するJ2EEアプリケーションのファイル名と表示名

種別 | 名前
ファイル名 | MyApp.ear
表示名 | MyApp

J2EEアプリケーションのインポートと開始の手順を次に示します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。

J2EEアプリケーションをインポートします。
サーバ管理コマンドを使用して，J2EEアプリケーションをJ2EEサーバへインポートします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp.ear

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp.ear

J2EEアプリケーションを開始します。
サーバ管理コマンドを使用して，J2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

参考

次に示す場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

インポート済みのJ2EEアプリケーションのプロパティを編集する場合

cosminexus.xmlを含まないアプリケーションの場合

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

8.9　システムの一括起動（サービスユニットの開始）

ここでは，システムを稼働状態で開始する方法について説明します。システムが稼働状態になると，サービスユニット内の論理サーバが起動されて，リクエストの受け付けや処理が実施されるようになります。

参考

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

リソースとJ2EEアプリケーションの設定が完了したら，cmx_start_targetコマンドを使用して，Webシステム内のすべてのサービスユニットを稼働状態で起動します。稼働状態にするには，-modeオプションに「ALL」を指定します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

cmx_start_targetコマンドの-sオプションには，簡易構築定義ファイルMyWebSystemDef.xmlの<web-system>タグの<name>タグで指定したWebシステム名を指定します。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。Smart Composer機能では，一括起動処理中に論理サーバの起動に失敗しても，そのまま処理を続行します。論理サーバの起動に失敗していると，リクエストの受け付けを開始できない，受け付けたリクエストを処理できないなどの障害が発生します。

cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

8.10　チューニング

チューニングでは，システムのパフォーマンスを生かす最適の設定を見つける作業（パフォーマンスチューニング）を実施します。構築した環境で，実際にJ2EEアプリケーションに負荷を掛けながら，スループット，レスポンス時間，CPU時間などの性能メトリックの相関が適切かどうか多角的に検証し，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。パフォーマンスチューニングの詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」を参照してください。

ここでは，簡易構築定義ファイルのパラメタだけを編集する場合のチューニングの手順，およびリソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニングの手順について説明します。

なお，パラメタを変更するとシステムが動作するために必要なリソースも変更する必要があります。システムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

＜この節の構成＞

8.10.1　簡易構築定義ファイルのパラメタだけを編集する場合のチューニング

8.10.2　リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニング

8.10.1　簡易構築定義ファイルのパラメタだけを編集する場合のチューニング

簡易構築定義ファイルのパラメタだけを編集する場合のチューニングについて説明します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。簡易構築定義ファイルのパラメタだけを編集する場合のチューニングの流れを次の図に示します。

図8-8　簡易構築定義ファイルのパラメタだけを編集する場合のチューニングの流れ

＜この項の構成＞

(1)　パラメタの編集

(2)　システムの設定変更

(1)　パラメタの編集

簡易構築定義ファイル（MyWebSystemDef.xml）のパラメタの値を編集して，チューニングを実施します。チューニングできる項目，およびパフォーマンスチューニングの詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の次の個所を参照してください。

8.1.3　アプリケーションの種類ごとにチューニングできる項目

8.2　チューニングの方法

(2)　システムの設定変更

cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデルを変更します。変更した情報モデルを実システムに適用します。

システムの設定変更の手順を，次に示します。

システムが稼働している場合は，システムを停止します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを停止状態にします。停止状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

システムの情報モデルを変更して実システムに展開します。
cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデルを変更し，変更した情報モデルからシステムを構築します。-fオプションには，パフォーマンスチューニングを実施した簡易構築定義ファイルを指定します。-fオプションで指定したファイルの内容をシステムに反映するには，-changeオプションを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

構成を変更したシステムを開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを稼働状態にします。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

各コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cmx_build_system（Webシステムの構築）

cmx_start_target（Webシステムまたはサービスユニットの開始）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

8.10.2　リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニング

リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニングの手順について説明します。なお，説明では「8.6　システムの一括構築」で構築したシステムを使用します。リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニングの流れを次の図に示します。

図8-9　リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニングの流れ

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表8-9　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。サービスユニット2に対しても，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

J2EEサーバ名：cmx_MyWebSystem_unit2_J2EE_01

-nameserver指定値：corbaname::192.168.1.12:900

＜この項の構成＞

(1)　パラメタの編集

(2)　システム，リソースアダプタおよびJ2EEアプリケーションの設定変更

(1)　パラメタの編集

簡易構築定義ファイル（MyWebSystemDef.xml）のパラメタの値を編集して，チューニングを実施します。チューニングできる項目，およびパフォーマンスチューニングの詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の次の個所を参照してください。

8.1.3　アプリケーションの種類ごとにチューニングできる項目

8.2　チューニングの方法

(2)　システム，リソースアダプタおよびJ2EEアプリケーションの設定変更

cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデル，リソースアダプタの設定およびJ2EEアプリケーションの設定を変更します。変更した情報モデルを実システムに適用します。

システムが稼働している場合は，システム内のサービスユニットを閉塞します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを閉塞状態にして，サービスユニットを負荷分散機から切り離します。閉塞状態にするには，-modeオプションに「HOLD」を指定します。
なお，システムが停止している場合は手順1.から手順3.までの操作は不要です。システムが停止している場合は手順4.から実施してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode HOLD

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode HOLD

J2EEアプリケーションおよびリソースアダプタを停止します。

サーバ管理コマンドを使用して，J2EEアプリケーションを停止します。

サーバ管理コマンドを使用して，リソースアダプタを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

# /opt/Cosminexus/CC/admin/bin/cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

手順2.をサービスユニット1およびサービスユニット2で実施したあとで，システムを停止します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを停止状態にします。停止状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

システムの情報モデルを変更して実システムに展開します。
cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデルを変更し，変更した情報モデルからシステムを構築します。-fオプションには，パフォーマンスチューニングを実施した簡易構築定義ファイルを指定します。-fオプションで指定したファイルの内容をシステムに反映するには，-changeオプションを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

構成を変更したシステムを負荷分散機からのリクエストの振り分けを抑止した状態で一括起動します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを準備状態にします。準備状態にするには，-modeオプションに「READY」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

リソースアダプタのプロパティを変更します。
ここでは，サーバ管理コマンドを使用して，次の作業を実施しています。

Connector属性ファイルを取得します。
取得したConnector属性ファイルは必要に応じて編集します。

Connector属性ファイルをリソースアダプタに反映します。

リソースアダプタを開始します。

Connector属性ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjgetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjgetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

J2EEアプリケーションのプロパティを変更します。
cosminexus.xmlを編集してJ2EEアプリケーションを再作成します。再作成後，サーバ管理コマンドを使用して，次の作業を実施します。

再作成したJ2EEアプリケーションをリデプロイします。

J2EEアプリケーションを開始します。

cosminexus.xmlを含むアプリケーションについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.3　cosminexus.xmlを含むアプリケーション」を参照してください。cosminexus.xmlについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　Cosminexusアプリケーション属性ファイル（cosminexus.xml）」を参照してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjreplaceapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp -f <任意のディレクトリ>¥MyApp.ear

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjreplaceapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp -f <任意のディレクトリ>/MyApp.ear

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

参考

インポート済みのJ2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）でも変更できます。変更方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

手順6.から手順7.までをサービスユニット1およびサービスユニット2で実施したあとで，システムを開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを稼働状態にします。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

各コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cjgetrarprop（RARファイルの属性の取得）

cjreplaceapp（アプリケーションの入れ替え）

cjsetrarprop（RAR属性設定）

cjstartapp（J2EEアプリケーションの開始）

cjstartrar（リソースアダプタの開始）

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

cjstoprar（リソースアダプタの停止）

cmx_build_system（Webシステムの構築）

cmx_start_target（Webシステムまたはサービスユニットの開始）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

8.11　構成定義パターンごとの簡易構築定義ファイルの作成

ここでは，選定した構成定義パターンごとに簡易構築定義ファイルの作成方法について説明します。

構成定義パターンと簡易構築定義ファイルの作成方法の参照先を次の表に示します。

表8-10　構成定義パターンと簡易構築定義ファイルの作成方法の参照先

構成定義パターン | 作成方法の参照先
WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier） | 8.11.1
WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ） | 8.11.2
インプロセスHTTPサーバを使用するパターン（j2ee-tier） | 8.11.3
SFOサーバを使用するパターン（sfo-tier） | 8.11.4
CTMを使用するパターン（ctm-tier） | 8.11.5

なお，各構成定義パターンで使用できる設定と，簡易構築定義ファイルの作成方法については，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

＜この節の構成＞

8.11.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルの作成

8.11.2　WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の簡易構築定義ファイルの作成

8.11.3　インプロセスHTTPサーバを使用するパターン（j2ee-tier）の簡易構築定義ファイルの作成

8.11.4　SFOサーバを使用するパターン（sfo-tier）の簡易構築定義ファイルの作成

8.11.5　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

8.11.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルの作成

ここでは，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）を簡易構築定義ファイルで作成する方法について説明します。この構成定義パターンでの作成方法については，「8.4.4　簡易構築定義ファイルの作成」を参照してください。なお，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

8.11.2　WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の簡易構築定義ファイルの作成

ここでは，WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）を簡易構築定義ファイルで作成する方法について説明します。なお，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。

物理ティアの定義
物理ティアの種類にはhttp-tierとj2ee-tierを定義します。また，http-tierではWebサーバのコンフィグレーション，j2ee-tierではJ2EEサーバのコンフィグレーションを定義します。

サービスユニットの定義
WebサーバとJ2EEサーバの組み合わせごとにサービスユニットを定義します。

ホストの定義
Webサーバを配置するホストとJ2EEサーバを配置するホストを別々に定義します。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の構成情報の例を次の図に示します。

図8-10　WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の構成情報の例

●簡易構築定義ファイルの作成例

図8-10の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）を構築する場合に差異のある定義を追加，変更して作成しています。

MyWebSystemDef.xmlの作成例を次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     :
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>http-tier</tier-type>
   </tier>
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.container.server_id.enabled</param-name>
          <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>http-tier</hosts-for>
     </allocated-host>
     <allocated-host>
       <host-ref>apsv3</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>http-tier</hosts-for>
     </allocated-host>
     <allocated-host>
       <host-ref>apsv4</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
 <host>
   <host-name>apsv2</host-name>
   <agent-host>192.168.100.12</agent-host>
 </host>
 <host>
   <host-name>apsv3</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>
 <host>
   <host-name>apsv4</host-name>
   <agent-host>192.168.100.14</agent-host>
 </host>
</model-definition>

注　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

8.11.3　インプロセスHTTPサーバを使用するパターン（j2ee-tier）の簡易構築定義ファイルの作成

ここでは，インプロセスHTTPサーバを使用するパターン（j2ee-tier）を簡易構築定義ファイルで作成する方法について説明します。なお，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。なお，インプロセスHTTPサーバを使用するパターン（j2ee-tier）では負荷分散機が使用できないため，負荷分散機の定義は削除します。

物理ティアの定義
物理ティアの種類にはj2ee-tierを定義します。また，j2ee-tierで，インプロセスHTTPサーバ機能を使用するための設定を定義します。

サービスユニットの定義
インプロセスHTTPサーバ機能を使用するJ2EEサーバ用のサービスユニットを定義します。インプロセスHTTPサーバが使用するポート番号を定義します。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。インプロセスHTTPサーバを使用するパターン（j2ee-tier）の構成情報の例を次の図に示します。

図8-11　インプロセスHTTPサーバを使用するパターン（j2ee-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図8-11の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，インプロセスHTTPサーバを使用するパターン（j2ee-tier）を構築する場合に差異のある定義を追加，変更して作成しています。

MyWebSystemDef.xmlの作成例を次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.connector.inprocess_http.enabled</param-name>
          <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
       <define-server>
         <logical-server-type>j2ee-server</logical-server-type>
         <configuration>
           <param>
             <param-name>webserver.connector.inprocess_http.port</param-name>
             <param-value>8091</param-value>
           </param>
              ：
         </configuration>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
</model-definition>

注1　太字の部分が設定の異なる部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注2　インプロセスHTTPサーバ機能を使用する構成では，負荷分散機が使用できないため，負荷分散機の定義は削除します。

8.11.4　SFOサーバを使用するパターン（sfo-tier）の簡易構築定義ファイルの作成

ここでは，SFOサーバを使用するパターン（sfo-tier）を簡易構築定義ファイルで作成する方法について説明します。なお，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。

物理ティアの定義
物理ティアの種類にはsfo-tierを定義します。sfo-tierでは，SFOサーバおよびパフォーマンストレーサのコンフィグレーションを設定できます。
また，業務サービス用の物理ティア（combined-tierまたはj2ee-tier）で，SFOサーバとJ2EEサーバとを関連づける設定，およびJ2EEサーバで使用するセッションフェイルオーバ用フィルタの設定を定義します。

サービスユニットの定義
メモリセッションフェイルオーバ用のサービスユニットを定義します。J2EEサーバとの関係を定義するためのSFOサーバの論理サーバ名や，SFOサーバごとのコンフィグレーションを定義します。

ホストの定義
メモリセッションフェイルオーバ用のサービスユニットを構成するホストを定義します。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。SFOサーバを使用するパターン（sfo-tier）の構成情報の例を次の図に示します。ここでは，業務サービス用の物理ティアの例としてcombined-tierを使用します。

図8-12　SFOサーバを使用するパターン（sfo-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図8-12の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，SFOサーバを使用するパターン（sfo-tier）を構築する場合に差異のある定義を追加，変更して説明します。

MyWebSystemDef.xmlの作成例を次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     :
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.container.server_id.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>webserver.sfo.sfo_servers</param-name>
          <param-value>sfoserver1,sfoserver2</param-value>
       </param>
       <param>
          <param-name>webserver.sfo.sfo_server.sfoserver1.serverName</param-name>
          <param-value>sfo01</param-value>
       </param>
       <param>
          <param-name>webserver.sfo.sfo_server.sfoserver2.serverName</param-name>
          <param-value>sfo02</param-value>
       </param>
     </configuration>
   </tier>
   <tier>
     <tier-type>sfo-tier</tier-type>
     <configuration>
       <logical-server-type>sfo-server</logical-server-type>
       <param>
         :
     </configuration>
     <configuration>
       <logical-server-type>performance-tracer</logical-server-type>
       <param>
         :
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     :
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>sfosv1</host-ref>
       <hosts-for>sfo-tier</hosts-for>
       <define-server>
         <logical-server-name>sfo01</logical-server-name>
         <logical-server-type>sfo-server</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
   <unit>
     <name>unit4</name>
     <allocated-host>
       <host-ref>sfosv2</host-ref>
       <hosts-for>sfo-tier</hosts-for>
       <define-server>
         <logical-server-name>sfo02</logical-server-name>
         <logical-server-type>sfo-server</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
 <host>
   :
 <host>
   <host-name>sfosv1</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>
 <host>
   <host-name>sfosv2</host-name>
   <agent-host>192.168.100.14</agent-host>
 </host>
</model-definition>

注　太字の部分が設定の異なる部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

8.11.5　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

ここでは，CTMを使用するパターン（ctm-tier）を簡易構築定義ファイルで作成する方法について説明します。また，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，統合ネーミングスケジューラサーバと，アプリケーションサーバを定義する必要があります。統合ネーミングスケジューラサーバは，統合ネーミングスケジューラサーバ用のWebシステムで定義し，アプリケーションサーバは，CTM用のWebシステムで定義します。

参考

CTMにリクエストを送信するシステムとして，Smart Composer機能で構築するWebフロントシステムを使用する場合は，別のWebシステムで定義してください。

Webシステムごとに，簡易構築定義ファイルで必要な定義について説明します。

統合ネーミングスケジューラサーバ用のWebシステム

Webシステムの属性定義
統合ネーミングスケジューラサーバを構築するWebシステムを定義します。

負荷分散機の定義
負荷分散機は定義できません。負荷分散機を定義した場合は，エラーとなります。

物理ティアの定義
物理ティアの種類にはctm-tierを定義します。
統合ネーミングスケジューラサーバではJ2EEサーバを配置しないため，ctm-tierで，J2EEサーバの数に0を設定します。
ctm-tierでは，CTMドメインマネジャ，CTM，スマートエージェントおよびパフォーマンストレーサのコンフィグレーションを設定できます。

サービスユニットの定義
統合ネーミングスケジューラサーバ用のサービスユニットを定義します。

ホストの定義
統合ネーミングスケジューラサーバ用のサービスユニットを構成するホストを定義します。

CTM用のWebシステム

Webシステムの属性定義
アプリケーションサーバを構築するWebシステムを定義します。

負荷分散機の定義
負荷分散機は定義できません。負荷分散機を定義した場合は，エラーとなります。

物理ティアの定義
物理ティアの種類にはctm-tierを定義します。
アプリケーションサーバでは，複数のJ2EEサーバが配置できます。複数のJ2EEサーバを配置する場合は，物理ティアの定義で，1ホストに配置するJ2EEサーバの数を設定します。

参考

1ホストに配置するJ2EEサーバの数は，Webシステムの構成変更時に変更できません。

ctm-tierでは，CTMドメインマネジャ，CTM，スマートエージェントおよびパフォーマンストレーサのコンフィグレーションと，J2EEサーバ全体で共通のコンフィグレーションを設定できます。複数のJ2EEサーバを配置する場合は，同じ番号（<server-no>タグ）を持つJ2EEサーバで共通のコンフィグレーションも設定できます。

注意

統合ネーミングスケジューラサーバとの関係を定義するため，次に示すパラメタは，統合ネーミングスケジューラサーバと同じ値を設定してください。

CTMドメインマネジャが属するCTMドメイン名（論理CTMドメインマネジャのctmdomname）

CTMドメインマネジャで使用するポート番号（論理CTMドメインマネジャのcdm.port）

スマートエージェントで使用するポート番号（論理スマートエージェントのsmartagent.port）

サービスユニットの定義
CTM用のサービスユニットを定義します。
サービスユニットごとに，CTMドメインマネジャ，CTM，スマートエージェントおよびパフォーマンストレーサのコンフィグレーションと，特定のJ2EEサーバのコンフィグレーションを設定できます。複数のJ2EEサーバを配置する場合，サービスユニット内のJ2EEサーバは，番号（<server-no>タグ）で特定します。

注意

CTMを識別するCTM識別子（ctmid）は，運用管理ドメイン内でユニークな値を設定する必要があります。CTM識別子（ctmid）の設定は省略できます。

ホストの定義
CTM用のサービスユニットを構成するホストを定義します。

複数のJ2EEサーバを配置する場合も，物理ティアおよびサービスユニットの定義で，コンフィグレーションを定義できます。J2EEサーバのコンフィグレーション定義の適用範囲を次の図に示します。

図8-13　J2EEサーバのコンフィグレーション定義の適用範囲

この図の場合に，各サービスユニットのJ2EEサーバごとに適用されるコンフィグレーション定義を次の表に示します。

表8-11　各サービスユニットのJ2EEサーバごとに適用されるコンフィグレーション定義

サービスユニット
J2EEサーバ
適用されるコンフィグレーション定義

unit1
J2EEサーバ（1A）

サービスユニットの定義（特定のJ2EEサーバの定義）

物理ティアの定義（同じ番号を持つJ2EEサーバで共通の定義）

物理ティアの定義（J2EEサーバ全体で共通の定義）

J2EEサーバ（1B）
物理ティアの定義（J2EEサーバ全体で共通の定義）

unit2
J2EEサーバ（2A）

物理ティアの定義（同じ番号を持つJ2EEサーバで共通の定義）

物理ティアの定義（J2EEサーバ全体で共通の定義）

J2EEサーバ（2B）
物理ティアの定義（J2EEサーバ全体で共通の定義）

この表のように，J2EEサーバごとに適用されるコンフィグレーション定義が複数ある場合，各定義で同じパラメタを指定したときは，次の1.，2.，3.の順に優先して適用されます。

サービスユニットの定義（特定のJ2EEサーバの定義）

物理ティアの定義（同じ番号を持つJ2EEサーバで共通の定義）

物理ティアの定義（J2EEサーバ全体で共通の定義）

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。CTMを使用するパターン（ctm-tier）の構成情報の例を次の図に示します。ここでは，CTMにリクエストを送信するクライアントとしてEJBクライアントを使用し，アプリケーションサーバには，J2EEサーバを二つ配置する例を使用します。

図8-14　CTMを使用するパターン（ctm-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図8-14の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，テンプレートファイルをコピーし，ファイル名を「MyWebSystemDef.xml」に変更して作成します。なお，統合ネーミングスケジューラサーバ用のWebシステムは，Webシステム1の「MyNamingSystem」，CTM用のWebシステムは，Webシステム2の「MyBackSystem」に対応しています。

MyWebSystemDef.xmの作成例を次に示します。

MyBackSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステム(統合ネーミングスケジューラサーバ用のWebシステム)の属性定義 -->
 <web-system>
   <name>MyNamingSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>ctm-tier</tier-type>
     <j2ee-server-count>0</j2ee-server-count>
     <configuration>
       <logical-server-type>ctm-domain-manager</logical-server-type>
       <param>
          <param-name>ctmdomname</param-name>
          <param-value>CTMDOMAIN</param-value>
       </param>
       <param>
          <param-name>cdm.port</param-name>
          <param-value>20137</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>smart-agent</logical-server-type>
       <param>
          <param-name>smartagent.port</param-name>
          <param-value>14000</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>namsv1</host-ref>
       <hosts-for>ctm-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>namsv2</host-ref>
       <hosts-for>ctm-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <!-- Webシステム(CTM用のWebシステム)の属性定義 -->
 <web-system>
   <name>MyBackSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>ctm-tier</tier-type>
     <j2ee-server-count>2</j2ee-server-count>
     <configuration>
       <logical-server-type>ctm-domain-manager</logical-server-type>
       <param>
          <param-name>ctmdomname</param-name>
          <param-value>CTMDOMAIN</param-value>
       </param>
       <param>
          <param-name>cdm.port</param-name>
          <param-value>20137</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>smart-agent</logical-server-type>
       <param>
          <param-name>smartagent.port</param-name>
          <param-value>14000</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <server-no>2</server-no>
       <param>
          <param-name>ejbserver.http.port</param-name>
          <param-value>8081</param-value>
       </param>
       <param>
          <param-name>webserver.connector.ajp13.port</param-name>
          <param-value>8008</param-value>
       </param>
       <param>
          <param-name>ejbserver.naming.port</param-name>
          <param-value>901</param-value>
       </param>
       <param>
          <param-name>ejbserver.distributedtx.recovery.port</param-name>
          <param-value>20303</param-value>
       </param>
       <param>
          <param-name>ejbserver.rmi.naming.port</param-name>
          <param-value>23153</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>ctmsv1</host-ref>
       <hosts-for>ctm-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit4</name>
     <allocated-host>
       <host-ref>ctmsv2</host-ref>
       <hosts-for>ctm-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>namsv1</host-name>
   <agent-host>192.168.100.31</agent-host>
 </host>
 <host>
   <host-name>namsv2</host-name>
   <agent-host>192.168.100.32</agent-host>
 </host>
 <host>
   <host-name>ctmsv1</host-name>
   <agent-host>192.168.100.33</agent-host>
 </host>
 <host>
   <host-name>ctmsv2</host-name>
   <agent-host>192.168.100.34</agent-host>
 </host>
</model-definition>

注　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

8.11.6　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

Smart Composer機能を使用して構築するシステムでは，負荷分散機の冗長化や，複数サービスユニットの配置などの設定ができます。Smart Composer機能で構築するシステムで使用できる設定と構成定義パターンとの対応を次の表に示します。ここでは，表8-12に示す設定を定義した簡易構築定義ファイルの作成方法について説明します。

表8-12　Smart Composer機能で構築するシステムで使用できる設定と構成定義パターンとの対応

設定項目 | 説明 | 構成定義パターンごとの対応
A | B | C | D | E
負荷分散機の冗長化 | 一つのWebシステム内に負荷分散機をアクティブ・スタンバイ構成で2台配置できます。1台の負荷分散機で障害が発生した場合も業務を続行できます。 | ○ | ○ | － | － | －
サーバマシン内での複数サービスユニットの配置 | 1台のサーバマシンに複数のサービスユニットを配置できます。サーバマシン中のサーバをサービスユニット単位で増やしてシステムを拡張したり，複数の業務を1台のサーバマシンで運用したりできます。 | ○ | ○ | ○ | ○ | ○※1
異なるWebシステム間での負荷分散機の共有 | 異なるWebシステム間で，同じ（1台の）負荷分散機を共有できます。 | ○ | ○ | － | － | －
論理ユーザサーバの配置 | ユーザが定義したプロセスを論理ユーザサーバとして定義すると，Management Serverで運用管理できるようになります。 | ○ | ○ | ○ | ○ | ○
JP1/SC/DPMの利用 | JP1/SC/DPMでは，構築したシステムのディスクイメージ（OSとアプリケーション）を複製できます。Smart Composer機能を使用したシステムの初期構築や，スケールアウト時に利用できます。 | ○ | ○ | ○ | ×※2 | ○

（凡例）

○：対応しています。

×：対応していません。

－：該当しません。

A：WebサーバとJ2EEサーバを同じサーバマシンに配置するパターンを示します。

B：WebサーバとJ2EEサーバを別のサーバマシンに配置するパターンを示します。

C：インプロセスHTTPサーバを使用するパターンを示します。

D：SFOサーバを使用するパターンを示します。

E：CTMを使用するパターンを示します。

注※1　同じCTMドメインのサービスユニットは，1サーバマシン内に複数配置できません。

注※2　セッションフェイルオーバサーバマシンでは，JP1/SC/DPMと連携したスケールアウトを利用できません。

＜この項の構成＞

(1)　負荷分散機を冗長化する場合の簡易構築定義ファイルの作成

(2)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

(3)　異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成

(4)　論理ユーザサーバを配置する場合の簡易構築定義ファイルの作成

(5)　JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成

(1)　負荷分散機を冗長化する場合の簡易構築定義ファイルの作成

負荷分散機を冗長化するシステムを構築する場合は，簡易構築定義ファイルの負荷分散機の定義に，負荷分散機2台分（実行系および待機系）の管理IPアドレスを設定する必要があります。

負荷分散機を冗長化した場合の構成情報の例を次の図に示します。なお，ここでは，実行系の負荷分散機を負荷分散機1，待機系の負荷分散機を負荷分散機2として配置している場合を例として説明しています。

図8-15　負荷分散機を冗長化した場合の構成情報の例

図8-15の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，負荷分散機を冗長化した場合に差異のある定義について説明します。

MyWebSystemDef.xmlファイルの作成例を，次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     <name>MyBIGIPv9</name>
     <load-balancer-type>BIG-IPv9</load-balancer-type>
     <!-- cookieスイッチングの定義 -->
     <cookie-switching>
       <cookie-switching-enabled>true</cookie-switching-enabled>
       <cookie-name>CMX_SERVER_ID</cookie-name>
     </cookie-switching>
     <management-host>192.168.100.10</management-host>
     <redundant-management-host>192.168.100.20</redundant-management-host>
     <!-- 仮想サーバの定義 -->
     <virtual-server>
       <virtual-server-name>www.sample.com</virtual-server-name>
       <ip-address>192.168.1.10</ip-address>
       <http-port>80</http-port>
     </virtual-server>
   </load-balancer>
      :
</model-definition>

注　太字の部分が設定の異なる部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

参考

冗長化した負荷分散機を複数のWebシステムで共有する場合は，各Webシステムの負荷分散機の定義で，<management-host>タグおよび<redundant-management-host>タグに同じIPアドレスを設定してください。

(2)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

1台のサーバマシンに複数のサービスユニットを配置すると，1台のサーバマシン内に，同じ種類の論理サーバが複数存在することになります。このため，簡易構築定義ファイルを作成する際には，各論理サーバのコンフィグレーションで，次に示す項目の指定値を重複しないようにしてください。

表8-13　論理サーバごとに重複しないように設定する項目

論理サーバの種類 | 項目 | param-nameの指定値
Webサーバ | httpポート番号 | Listen
J2EEサーバ | 管理用サーバのポート番号 | ejbserver.http.port
ajp13のポート番号 | webserver.connector.ajp13.port
httpsのポート番号 | webserver.connector.redirect_https.port
インプロセスのネーミングサービス用のポート番号 | ejbserver.naming.port
インプロセスのHTTPサーバのポート番号 | webserver.connector.inprocess_http.port
JTAリカバリの固定ポート番号 | ejbserver.distributedtx.recovery.port
RMIレジストリのポート番号 | ejbserver.rmi.naming.port
パフォーマンストレーサ | PRF識別子 | PRFID
SFOサーバ | 管理用サーバのポート番号 | ejbserver.http.port
ajp13のポート番号 | webserver.connector.ajp13.port
インプロセスのネーミングサービス用のポート番号 | ejbserver.naming.port
RMIレジストリのポート番号 | ejbserver.rmi.naming.port
スマートエージェント | スマートエージェントが監視するポート番号 | smartagent.port
CTMドメインマネジャ | CTMドメインマネジャが属するCTMドメイン名 | ctmdomname
CTM実行環境ディレクトリ | ctmspool
CTMドメインマネジャがCTMドメイン構成情報を交換するために使用するポート番号 | cdm.port
CTM | CTMの識別子 | ctmid※
CTMが使用するポート番号 | ctm.port
CTMと対となるネーミングサービスのポート番号 | ctm.ns.port

注※　ctmidの設定は省略できます。省略時は，ホスト間で一意になるようにManagement Serverで自動的に設定されます。ctmidの省略値については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.18　論理CTMで指定できるパラメタ」を参照してください。

参考

1台のサーバマシン内にある複数のサービスユニットを同時に起動しない運用をする場合は，各サービスユニットの同じ種類の論理サーバに同じ値を設定できます。

サーバマシンに配置するサービスユニットが属するWebシステムによって，これらの設定項目をどの定義のコンフィグレーションで指定するかが異なります。

同じWebシステムのサービスユニットを1台のサーバマシンに配置する場合
各サービスユニットの論理サーバ定義（<define-server>タグ）内の<configuration>タグで指定します。

異なるWebシステムのサービスユニットを1台のサーバマシンに配置する場合
各Webシステムの物理ティア定義（<tier>タグ）内の<configuration>タグで指定します。なお，異なるWebシステムのサービスユニットを1台のサーバマシンに配置する場合の簡易構築定義ファイルの作成例については，「(3)　異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成」を参照してください。

同じWebシステムで，サーバマシン内に複数のサービスユニットを配置する場合の構成情報の例を，次の図に示します。

図8-16　サーバマシン内に複数のサービスユニットを配置する場合の構成情報の例（同一のWebシステムの場合）

図8-16の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，同じWebシステムで，サーバマシン内に複数のサービスユニットを配置する場合に差異のある定義について説明します。

MyWebSystemDef.xmlファイルの作成例を，次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     :
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       :
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>combined-tier</hosts-for>
       <!-- Webサーバのコンフィグレーション -->
       <define-server>
         <logical-server-type>web-server</logical-server-type>
         <configuration>
           <!-- httpポート番号 -->
           <param>
             <param-name>Listen</param-name>
             <param-value>81</param-value>
           </param>
         </configuration>
       </define-server>
       <!-- J2EEサーバのコンフィグレーション -->
       <define-server>
         <logical-server-type>j2ee-server</logical-server-type>
         <configuration>
           <!-- 管理用サーバのポート番号 -->
           <param>
             <param-name>ejbserver.http.port</param-name>
             <param-value>8081</param-value>
           </param>
           <!-- ajp13のポート番号 -->
           <param>
             <param-name>webserver.connector.ajp13.port</param-name>
             <param-value>8008</param-value>
           </param>
           <!-- インプロセスネーミングサービス用のポート番号 -->
           <param>
             <param-name>ejbserver.naming.port</param-name>
             <param-value>901</param-value>
           </param>
           <!-- JTAリカバリの固定ポート番号 -->
           <param>
             <param-name>ejbserver.distributedtx.recovery.port</param-name>
             <param-value>20303</param-value>
           </param>
           <!-- RMIレジストリのポート番号 -->
           <param>
             <param-name>ejbserver.rmi.naming.port</param-name>
             <param-value>23153</param-value>
           </param>
         </configuration>
       </define-server>
       <!-- パフォーマンストレーサのコンフィグレーション -->
       <define-server>
         <logical-server-type>performance-tracer</logical-server-type>
         <configuration>
           <!-- PRF識別子 -->
           <param>
             <param-name>PRFID</param-name>
             <param-value>PRF_ID2</param-value>
           </param>
         </configuration>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
 <host>
   <host-name>apsv2</host-name>
   <agent-host>192.168.100.12</agent-host>
 </host>
</model-definition>

注　太字の部分が設定の異なる部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(3)　異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成

異なるWebシステムのサービスユニットを1台のサーバマシンに配置する場合に，簡易構築定義ファイルで重複しないように設定する項目については，「(2)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成」を参照してください。

異なるWebシステム間で1台の負荷分散機を共有する場合は，それぞれのWebシステムで使用する負荷分散機の仮想サーバを分ける必要があります。

また，簡易構築定義ファイルでは，次の定義で注意が必要です。

負荷分散機の定義
各Webシステムの負荷分散機のIPアドレスに，同じ値を設定してください。

仮想サーバの定義（負荷分散機の定義）
各Webシステムの仮想サーバ名，仮想サーバのIPアドレスおよびポート番号が重複しないように設定してください。

異なるWebシステム間で負荷分散機を共有する場合の構成情報の例を，次の図に示します。

図8-17　異なるWebシステム間で負荷分散機を共有する場合の構成情報の例

図8-17の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，次の設定をする場合に差異のある定義について説明します。

異なるWebシステムのサービスユニットを1台のサーバマシンに配置する

異なるWebシステム間で負荷分散機を共有する

さらに，ACOSの場合は，次の1.または2.の条件を満たす構成のとき，自動的にポート変換する設定（オートトランスレーション機能の使用）が必要です。

仮想サーバまたは実サーバに設定したポート番号が1023より大きいとき（well-knownでないとき）

実サーバのポート番号とそれに対応する仮想サーバのポート番号が異なるとき
例：仮想サーバのポート番号は80だが，振り分け先のポート番号は8081にしたいとき

オートトランスレーション機能の設定は，あらかじめ負荷分散機に対して実施しておいてください。設定の詳細については，ACOSのドキュメントを参照してください。

MyWebSystemDef.xmlファイルの作成例を，次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステム1の属性定義 -->
 <web-system>
   <name>MyWebSystem1</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     <name>MyBIGIPv9</name>
     <load-balancer-type>BIG-IPv9</load-balancer-type>
     <!-- cookieスイッチングの定義 -->
     <cookie-switching>
       <cookie-switching-enabled>true</cookie-switching-enabled>
       <cookie-name>CMX_SERVER_ID</cookie-name>
     </cookie-switching>
     <management-host>192.168.100.10</management-host>
     <!-- 仮想サーバ1の定義 -->
     <virtual-server>
       <virtual-server-name>www.sample1.com</virtual-server-name>
       <ip-address>192.168.1.10</ip-address>
       <http-port>80</http-port>
     </virtual-server>
   </load-balancer>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.container.server_id.enabled</param-name>
          <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <!-- Webシステム2の属性定義 -->
 <web-system>
   <name>MyWebSystem2</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     <name>MyBIGIPv9</name>
     <load-balancer-type>BIG-IPv9</load-balancer-type>
     <!-- cookieスイッチングの定義 -->
     <cookie-switching>
       <cookie-switching-enabled>true</cookie-switching-enabled>
       <cookie-name>CMX_SERVER_ID</cookie-name>
     </cookie-switching>
     <management-host>192.168.100.10</management-host>
     <!-- 仮想サーバ2の定義 -->
     <virtual-server>
       <virtual-server-name>www.sample2.com</virtual-server-name>
       <ip-address>192.168.1.20</ip-address>
       <http-port>81</http-port>
     </virtual-server>
   </load-balancer>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>webserver.container.server_id.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <!-- 管理用サーバのポート番号 -->
       <param>
         <param-name>ejbserver.http.port</param-name>
         <param-value>8081</param-value>
       </param>
       <!-- ajp13のポート番号 -->
       <param>
         <param-name>webserver.connector.ajp13.port</param-name>
         <param-value>8008</param-value>
       </param>
       <!-- インプロセスネーミングサービス用のポート番号 -->
       <param>
         <param-name>ejbserver.naming.port</param-name>
         <param-value>901</param-value>
       </param>
       <!-- JTAリカバリの固定ポート番号 -->
       <param>
         <param-name>ejbserver.distributedtx.recovery.port</param-name>
         <param-value>20303</param-value>
       </param>
       <!-- RMIレジストリのポート番号 -->
       <param>
         <param-name>ejbserver.rmi.naming.port</param-name>
         <param-value>23153</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>web-server</logical-server-type>
       <!-- httpポート番号 -->
       <param>
         <param-name>Listen</param-name>
         <param-value>81</param-value>
      </param>
     </configuration>
     <configuration>
       <logical-server-type>performance-tracer</logical-server-type>
       <!-- PRF識別子 -->
       <param>
         <param-name>PRFID</param-name>
         <param-value>PRF_ID2</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv2</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
     :
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
 <host>
   <host-name>apsv2</host-name>
   <agent-host>192.168.100.12</agent-host>
 </host>
</model-definition>

注　太字の部分が設定の異なる部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(4)　論理ユーザサーバを配置する場合の簡易構築定義ファイルの作成

Smart Composer機能で構築するシステムの場合，簡易構築定義ファイルで論理ユーザサーバを設定できます。

論理ユーザサーバは，サービスユニットに対応づけて配置します。このため，簡易構築定義ファイルで論理ユーザサーバの環境設定を定義する場合は，サービスユニットの定義でパラメタを設定してください。

論理ユーザサーバを配置する場合の構成情報の例を，次の図に示します。

図8-18　論理ユーザサーバを配置する場合の構成情報

図8-18の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，「8.4.4　簡易構築定義ファイルの作成」で示す簡易構築定義ファイル（MyWebSystemDef.xml）を基に，論理ユーザサーバを配置する場合に差異のある定義について説明します。

MyWebSystemDef.xmlファイルの作成例を，次に示します（一部抜粋）。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
       ：
   </load-balancer>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>host1</host-ref>
       <hosts-for>combined-tier</hosts-for>
       <define-server>
       <logical-server-name>UserServer1</logical-server-name>
       <logical-server-type>user-server</logical-server-type>
         <configuration>
         <param>
         <!-- サーバ起動用コマンド -->
           <param-name>start.arg</param-name>
           <param-value>c:/test/start.exe</param-value>
         </param>
         </configuration>
       </define-server>
       <define-server>
       <logical-server-name>UserServer2</logical-server-name>
       <logical-server-type>user-server</logical-server-type>
         <configuration>
         <param>
         <!-- サーバ起動用コマンド -->
           <param-name>start.arg</param-name>
           <param-value>c:/test/start.exe</param-value>
         </param>
         </configuration>
       </define-server>
     </allocated-host>
   </unit>
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>host1</host-ref>
       <hosts-for>combined-tier</hosts-for>
       <define-server>
     <logical-server-name>UserServer3</logical-server-name>
     <logical-server-type>user-server</logical-server-type>
         <configuration>
         <param>
         <!-- サーバ起動用コマンド -->
           <param-name>start.arg</param-name>
           <param-value>c:/test/start.exe</param-value>
         </param>
         </configuration>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   :
 </host>
</model-definition>

注　論理ユーザサーバのパラメタは，物理ティアの定義には設定できません。論理ユーザサーバのパラメタを設定する場合は，サービスユニットの定義に設定してください。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

参考

論理ユーザサーバを配置するシステムをスケールアウトする場合は，構成変更定義ファイルのサービスユニットの定義で，追加する論理ユーザサーバを定義してください。構成変更定義ファイルのサービスユニットの定義例は，「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」を参照してください。

(5)　JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成

JP1/SC/DPMを利用してシステムを構築する場合は，簡易構築定義ファイルの物理ティアの定義で，WebサーバおよびJ2EEサーバのコンフィグレーション（<configuration>タグ）の設定が必要になります。

JP1/SC/DPMを利用してシステムを構築する場合に，物理ティアの定義で設定が必要なパラメタを次の表に示します。なお，この表に示すパラメタは，選定した構成定義パターンで定義する論理サーバで設定してください。

表8-14　JP1/SC/DPMを利用してシステムを構築する場合に，物理ティアの定義で設定が必要なパラメタ

論理サーバの種類（<tier>タグ配下の<logical-server-type>タグの指定値） | <param-name>タグの指定値 | <param-value>タグの指定値
web-server | realservername | 実サーバ名
Listen.host.value※ | true
j2ee-server | realservername | 実サーバ名
webserver.connector.http.bind_host.value※ | true
webserver.connector.ajp13.bind_host.value※ | true
manager.mevent.sender.bind.host.value※ | true
vbroker.se.iiop_tp.host.value※ | true
mngagent.connector.host.value※ | true
CTM | ctm.NsBindHost※ | true

注　CTMを使用するパターン（ctm-tier）を構築する場合に，ホスト単位管理モデルを使用するときは，ctmid（CTM識別子）の設定を省略することをお勧めします。ctmidの省略値については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.18　論理CTMで指定できるパラメタ」を参照してください。

注※　Management Serverが稼働するホスト（サーバマシン）が，複数個のIPアドレスを持っている構成の場合に設定が必要です。

8.12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

アプリケーションサーバの機能をSmart Composer機能で構築するシステムで使用する場合，機能を有効にするための設定が必要なときがあります。ここでは，Smart Composer機能で使用できるアプリケーションサーバの機能について説明します。なお，アプリケーションサーバで使用している機能の詳細や，機能を有効にするための設定については，参照先マニュアルを参照してください。

Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先（参照先マニュアルおよび参照個所）を次の表に示します。なお，参照先マニュアルでは，マニュアル名称の「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

表8-15　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先（J2EEアプリケーションを実行するシステム）

項番 | Smart Composer機能で使用できるアプリケーションサーバの機能 | 参照先マニュアル | 参照個所
1 | Webコンテナの機能 | Webアプリケーションの実行機能 | 基本・開発編(Webコンテナ) | 2.2
2 | JSPの実行機能 | 2.3
3 | JSPデバッグ機能 | 2.4
4 | JSPの事前コンパイルとコンパイル結果の保持 | 2.5
5 | デフォルトの文字エンコーディング設定機能 | 2.6
6 | セッション管理機能 | 2.7
7 | アプリケーションのイベントリスナ | 2.8
8 | リクエストおよびレスポンスのフィルタリング | 2.9
9 | HTTPレスポンス圧縮機能 | 2.10
10 | EJBコンテナとの連携 | 2.11
11 | データベースとの接続 | 2.12
12 | Webコンテナによるスレッドの作成 | 2.13
13 | ユーザスレッドの使用 | 2.14
14 | 同時実行スレッド数の制御 | 2.15
15 | エラーページのカスタマイズ | 2.20
16 | 静的コンテンツのキャッシュ | 2.21
17 | 簡易Webサーバ機能 | 2.22
18 | Webサーバ連携の機能 | Webサーバ（リダイレクタ）によるリクエストの振り分け | 3.2
19 | 通信タイムアウト（Webサーバ連携） | 3.6
20 | IPアドレス指定（Webサーバ連携） | 3.7
21 | エラーページのカスタマイズ（Webサーバ連携） | 3.8
22 | ドメイン名指定でのトップページの表示 | 3.9
23 | Webコンテナへのゲートウェイ情報の通知 | 3.10
24 | インプロセスHTTPサーバの機能 | Webクライアントからの接続数の制御 | 4.3
25 | リクエスト処理スレッド数の制御 | 4.4
26 | Webクライアントからの同時接続数の制御によるリクエストの流量制御 | 4.5
27 | 同時実行スレッド数の制御によるリクエストの流量制御 | 4.6
28 | リダイレクトによるリクエストの振り分け | 4.7
29 | Persistent ConnectionによるWebクライアントとの通信制御 | 4.8
30 | 通信タイムアウト（インプロセスHTTPサーバ） | 4.9
31 | IPアドレス指定（インプロセスHTTPサーバ） | 4.10
32 | アクセスを許可するホストの制限によるアクセス制御 | 4.11
33 | リクエストデータのサイズの制限によるアクセス制御 | 4.12
34 | 有効なHTTPメソッドの制限によるアクセス制御 | 4.13
35 | HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ | 4.14
36 | エラーページのカスタマイズ（インプロセスHTTPサーバ） | 4.15
37 | Webコンテナへのゲートウェイ情報の通知 | 4.16
38 | ログ・トレースの出力 | 4.17
39 | EJBコンテナの機能 | Enterprise Beanの実行 | 基本・開発編(EJBコンテナ) | 2.2
40 | EJB仕様準拠のチェック | 2.3
41 | CMPフィールドとデータ型のマッピング | 2.4
42 | EJBコンテナのJNDI名前空間へのリファレンス登録 | 2.5
43 | 外部リソースとの接続 | 2.6
44 | Enterprise Beanでのトランザクション管理 | 2.7
45 | Entity Beanのキャッシュモデル（コミットオプション指定） | 2.8
46 | Stateless Session Bean，Entity Beanのプールの管理 | 2.9
47 | Enterprise Beanへのアクセス制御 | 2.10
48 | EJBコンテナでのタイムアウトの設定 | 2.11
49 | Timer Serviceの機能 | 2.12
50 | EJBのリモートインタフェースの呼び出し | 2.13
51 | EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション） | 2.14
52 | インターセプタの使用 | 2.15
53 | EJBクライアントの機能 | EJBクライアントアプリケーションの開始 | 3.3
54 | Enterprise Beanの呼び出し | 3.4
55 | EJBクライアントアプリケーションでのトランザクションの実装 | 3.5
56 | EJBクライアントアプリケーションでのセキュリティの実装 | 3.6
57 | RMI-IIOPスタブ，インタフェースの取得 | 3.7
58 | EJBクライアントアプリケーションのシステムログ出力 | 3.8
59 | ネーミング管理の機能 | JNDI名前空間へのオブジェクトのバインドとルックアップ | 基本・開発編(コンテナ共通機能) | 2.3
60 | Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能） | 2.4
61 | ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | 2.5
62 | ネーミング管理機能でのキャッシング | 2.6
63 | CORBAネーミングサービスの切り替え | 2.8
64 | EJBホームオブジェクトリファレンスの再利用（EJBホームオブジェクトへの再接続機能） | 2.9
65 | リソース接続とトランザクション管理の機能 | コネクションプーリング | 3.14.1
66 | コネクションプールのウォーミングアップ | 3.14.2
67 | コネクションプール数調節機能 | 3.14.2
68 | コネクションシェアリング・アソシエーション | 3.14.3
69 | ステートメントプーリング | 3.14.4
70 | ライトトランザクション | 3.14.5
71 | インプロセストランザクションサービス | 3.14.6
72 | DataSourceオブジェクトのキャッシング | 3.14.7
73 | DB Connectorのコンテナ管理でのサインオンの最適化 | 3.14.8
74 | コネクションの障害検知 | 3.15.1
75 | コネクション枯渇時のコネクション取得待ち | 3.15.2
76 | コネクションの取得リトライ | 3.15.3
77 | コネクションプールの情報表示 | 3.15.4
78 | コネクションプールのクリア | 3.15.5
79 | コネクションの自動クローズ | 3.15.6
80 | コネクションスイーパ | 3.15.7
81 | トランザクションタイムアウトとステートメントキャンセル | 3.15.8
82 | トランザクションリカバリ | 3.15.9
83 | 障害調査用SQLの出力 | 3.15.10
84 | オブジェクトの自動クローズ | 3.15.11
85 | リソースアダプタのライフサイクル管理 | 3.16.1
86 | リソースアダプタのワーク管理 | 3.16.2
87 | メッセージインフロー | 3.16.3
88 | トランザクションインフロー | 3.16.4
89 | 管理対象オブジェクトのルックアップ | 3.16.5
90 | コネクション定義の複数指定 | 3.16.6
91 | コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示） | 3.17
92 | リソースへの接続テスト | 3.18
93 | アプリケーションサーバで使用するJPAの機能 | JPA | 5章
94 | OpenTP1からの呼び出し（TP1インバウンド連携） | コネクション管理機能 | 4.5
95 | RPC通信機能 | 4.6
96 | スケジュール機能 | 4.7
97 | トランザクション連携機能 | 4.8
98 | Cosminexus JPAプロバイダの機能 | Cosminexus JPAプロバイダとは | 6.2
99 | エンティティを使用したデータベースの更新 | 6.3
100 | EntityManagerによるエンティティの操作 | 6.4
101 | データベースとJavaオブジェクトとのマッピング情報の定義 | 6.5
102 | エンティティのリレーションシップ | 6.6
103 | エンティティオブジェクトのキャッシュ機能 | 6.7
104 | プライマリキー値の自動採番 | 6.8
105 | クエリ言語によるデータベース操作 | 6.9
106 | 楽観的ロック | 6.10
107 | JPQLでの悲観的ロック | 6.11
108 | セキュリティ管理の機能 | SSL使用による認証情報とデータの暗号化 | 9.2
109 | ロールに基づくWebコンテナのユーザ認証 | 9.3
110 | SecurityManagerによるWebコンテナの実行時の保護 | 9.4
111 | セキュリティアイデンティティを使用した認証 | 9.5
112 | アノテーションの機能 | アノテーション | 11章
113 | J2EEアプリケーションの形式とデプロイの機能 | アーカイブ形式によるJ2EEアプリケーションのデプロイ | 12.5.1
114 | 展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ | 12.5.2
115 | J2EEアプリケーションの入れ替え | 12.6
116 | J2EEアプリケーションのリデプロイ | 12.7
117 | J2EEアプリケーションの更新検知とリロード | 12.8
118 | コンテナ拡張ライブラリの機能 | コンテナ拡張ライブラリ | 13.3
119 | サーバ起動・停止フック機能 | 13.4
120 | スマートエージェント経由でのCORBAオブジェクトの呼び出し | 13.5
121 | CTMによるEnterprise Beanのスケジューリング機能 | リクエストの流量制御 | 拡張編 | 3.4
122 | リクエストの優先制御 | 3.5
123 | リクエストの同時実行数の動的変更 | 3.6
124 | リクエストの閉塞制御 | 3.7
125 | リクエストの負荷分散 | 3.8
126 | リクエストのキューの滞留監視 | 3.9
127 | CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続 | 3.10
128 | そのほかの拡張機能 | セッションフェイルオーバ機能（データベースセッションフェイルオーバ） | 5章，6章
129 | セッションフェイルオーバ機能（メモリセッションフェイルオーバ） | 5章，7章
130 | 明示管理ヒープ機能を使用したフルガーベージコレクションの抑止 | 8章
131 | クライアント性能の測定と分析 | 9章
132 | 統合ユーザ管理 | 10章
133 | 複数の構築済み実行環境の切り替え | 11章
134 | ユーザログ出力 | 12章
135 | スレッドの非同期並行処理 | 13章
136 | システムの日常運用を支援する機能 | システムの起動・停止 | 運用／監視／連携編 | 2章
137 | 稼働情報の監視（稼働情報収集機能） | 3章
138 | リソースの枯渇監視 | 4章
139 | 運用管理コマンドによる稼働情報の出力 | 8章
140 | Managementイベントの通知とManagementアクションによる処理の自動実行 | 9章
141 | CTMの稼働統計情報の収集 | 10章
142 | システムの保守を支援する機能 | コンソールログの出力 | 11章
143 | J2EEアプリケーションの運用機能 | J2EEアプリケーションの実行時間の監視とキャンセル | 5.3
144 | J2EEアプリケーションのサービスの閉塞 | 5.4
145 | J2EEアプリケーションの停止 | 5.5
146 | J2EEアプリケーションの入れ替え | 5.6
147 | J2EEアプリケーションのテスト機能 | 5.7
148 | J2EEアプリケーションからのネットワークリソースへのアクセス | 5.8
149 | システムの監査を支援する機能 | 監査ログの出力機能 | 6章
150 | データベース監査証跡連携機能 | 7章
151 | JP1連携による運用管理機能 | JP1と連携したシステムの運用 | 12章
152 | システムの構成定義および管理（JP1/IM - CMとの連携） | 13章
153 | システムの集中監視（JP1/IMとの連携） | 14章
154 | ジョブによるシステムの自動運転（JP1/AJSとの連携） | 15章
155 | シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携） | 16章
156 | 監査ログの収集および一元管理（JP1/NETM/Auditとの連携） | 17章
157 | クラスタソフトウェアとの連携による系切り替え機能 | 1:1系切り替えシステム | 19章
158 | 相互系切り替えシステム | 20章
159 | ホスト単位管理モデルを対象にした系切り替えシステム | 22章
160 | システムの保守のための機能 | トラブルシューティング | 保守／移行／互換編 | 2章，3章，4章，5章
161 | 性能解析トレースを使用したシステムの性能解析 | 6章，7章
162 | 日立固有のJavaVMの機能 | クラス別統計機能 | 8.3
163 | インスタンス統計機能 | 8.4
164 | STATICメンバ統計機能 | 8.5
165 | 参照関係情報出力機能 | 8.6
166 | 統計前のガーベージコレクション選択機能 | 8.7
167 | Tenured領域内不要オブジェクト統計機能 | 8.8
168 | Tenured増加要因の基点オブジェクトリスト出力機能 | 8.9
169 | クラス別統計情報解析機能 | 8.10
170 | Survivor領域の年齢分布情報出力機能 | 8.11
171 | ファイナライズ滞留解消機能 | 8.12
172 | hndlwrap機能 | 8.13
173 | JITコンパイル時のCヒープ確保量の上限値設定機能 | 8.14
174 | スレッド数の上限値設定機能 | 8.15
175 | 旧バージョンの製品から移行するための機能 | 旧バージョンのアプリケーションサーバからの移行 | 12章
176 | Microsoft IISからHitachi Web Serverへの移行 | 13.1
177 | インプロセストランザクションサービスへの移行 | 13.2
178 | 旧バージョンの製品との互換のための機能 | Cosminexus DABroker Libraryを使用したデータベース接続 | 11章

8.13　障害に対応したシステムの構築

ここでは，「6.1.2　障害設計」で説明した障害に対応した次のようなシステムを構築します。

障害発生時にサービスユニットを自動閉塞するシステム

障害発生時にサービスユニットを自動再起動するシステム

＜この節の構成＞

8.13.1　障害発生時にサービスユニットを自動閉塞するための設定

8.13.2　サービスユニットを自動再起動するための設定

8.13.1　障害発生時にサービスユニットを自動閉塞するための設定

アプリケーションサーバでは，システムに障害が発生した場合の動作を障害検知時コマンドで定義できます。ユーザ作成の障害検知時コマンドにSmart Composer機能のコマンドを定義しておくことで，システムの運用中に障害が発生した場合にサービスユニットを自動閉塞できるため，迅速な障害対応ができます。

J2EEサーバのハングアップなどシステムの一部で致命的な障害が発生した場合に，障害発生時の情報を収集し，障害の発生しているサービスユニットを自動的に閉塞します。障害検知時コマンドによるサービスユニットの自動閉塞処理を次の図に示します。

図8-19　障害検知時コマンドによるサービスユニットの自動閉塞処理

Smart Composer機能を使用すると，致命的な障害が発生した場合に，そのサービスユニットを自動閉塞できます。

ここでは例として，J2EEサーバがハングアップまたはプロセスダウンした場合，障害検知時コマンドを使用してサービスユニットを自動閉塞する方法について説明します。必要な操作は次のとおりです。

J2EEサーバの自動再起動設定の無効化

障害検知時コマンドの作成

Management Serverの設定

運用管理エージェントの設定

障害検知時コマンドの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「2.3.2　障害検知時コマンドによる資料取得」を，設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.1　障害検知時コマンドによる資料取得の設定（J2EEアプリケーションを実行するシステム）」を参照してください。

＜この項の構成＞

(1)　J2EEサーバの自動再起動設定の無効化

(2)　障害検知時コマンドの作成

(3)　Management Serverの設定

(4)　運用管理エージェントの設定

(1)　J2EEサーバの自動再起動設定の無効化

前準備として，J2EEサーバの自動再起動の設定を無効にする必要があります。この設定が有効になっている場合（デフォルトでは有効に設定されています）は，次の手順で設定を変更してください。

構築済みのシステムの構築時に使用した簡易構築定義ファイルを編集します。
物理ティアの定義（<tier>タグの定義）の<configuration>タグに，次の設定を追加します。

<logical-server-type>タグ：j2ee-server

<param-name>タグ：mstartup.restartcnt

<param-value>タグ：0

MyWebSystemDef.xmlファイルの設定例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">  <web-system>
 <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     :
   </load-balancer>
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- J2EEサーバの障害検知時自動再起動を無効にする設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>mstartup.restartcnt</param-name>
         <param-value>0</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     :
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   :
 </host>
</model-definition>

注　太字の部分が編集部分です。

変更した簡易構築定義ファイルの内容を実際のシステムに反映して，システムの設定を一括で変更します。
システムの設定を一括変更する方法については，「8.10.1(2)　システムの設定変更」を参照してください。

(2)　障害検知時コマンドの作成

障害検知時コマンドには，障害発生時に呼び出すコマンドを定義します。

システム提供の障害検知時コマンドについては，提供されているものを使用するため，ここで作成する必要はありません。

ここでは，J2EEサーバのハングアップまたはプロセスダウンを検知しときに障害の発生したJ2EEサーバを含むサービスユニットを閉塞する，ユーザ作成の障害検知時コマンドを作成します。ユーザ作成の障害検知時コマンドは，コマンドファイル（バッチファイルまたはシェルスクリプトファイル）に記述できます。コマンドファイルの作成例を次に示します。なお，コマンドファイルの作成例で使用している環境変数の詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.1　障害検知時コマンドによる資料取得の設定（J2EEアプリケーションを実行するシステム）」を参照してください。

Windowsの場合

バッチファイル（holdunit.bat）の作成例を示します。

@echo off

"<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target" -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s "%COSMI_MNG_WEB_SYSTEM%" -unit "%COSMI_MNG_UNIT%"

UNIXの場合

シェルスクリプトファイル（holdunit.sh）の作成例を示します。

#!/bin/sh

/opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s "${COSMI_MNG_WEB_SYSTEM}" -unit "${COSMI_MNG_UNIT}"

(3)　Management Serverの設定

mserver.properties（Management Server環境設定ファイル）で，ユーザ作成の障害検知時コマンドの動作を設定します。なお，システム提供の障害検知時コマンドについては，デフォルトで利用する設定になっているため，ここでの設定は必要ありません。

運用管理サーバでmserver.propertiesファイルを編集します。
次のプロパティを設定します。

com.cosminexus.mngsvr.usr_cmd.abnormal_end.enabled
ユーザ作成の障害検知時コマンドを利用する（true）に設定します。

com.cosminexus.mngsvr.usr_cmd.abnormal_end.timeout
ユーザ作成の障害検知時コマンドの終了を待つ時間を設定します。

なお，プロパティの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。
mserver.propertiesファイルの設定例を示します。

...
com.cosminexus.mngsvr.usr_cmd.abnormal_end.enabled=true
com.cosminexus.mngsvr.usr_cmd.abnormal_end.timeout=300
...

mserver.propertiesファイルは，次の場所に格納されています。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合

/opt/Cosminexus/manager/config/

Management Serverが稼働中の場合は，再起動します。

mngsvrctlコマンドに，引数「stop」を指定してManagement Serverを停止します。

mngsvrctlコマンドに，引数「start」を指定してManagement Serverを起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl stop
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl start

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl stop
# /opt/Cosminexus/manager/bin/mngsvrctl start

(4)　運用管理エージェントの設定

adminagent.properties（運用管理エージェントプロパティファイル）で，ユーザ作成の障害検知時コマンドを実行するための設定をします。

ユーザ作成の障害検知時コマンドを，各アプリケーションサーバに配置します。
ここでは，ユーザ作成の障害検知時コマンドを次の場所に格納します。

Windowsの場合

C:¥work¥holdunit.bat

UNIXの場合

/work/holdunit.sh

各アプリケーションサーバのadminagent.properties（運用管理エージェントプロパティファイル）を編集します。
ここでは，J2EEサーバ障害発生時に，ユーザ作成の障害検知時コマンドを実行する場合の例を示します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥adminagent.propertiesの設定例を，次に示します。

...
adminagent.j2ee.usr_cmd.abnormal_end=%{ComSpec} /c "C:/work/holdunit.bat"
...

UNIXの場合

/opt/Cosminexus/manager/config/adminagent.propertiesの設定例を，次に示します。

...
adminagent.j2ee.usr_cmd.abnormal_end=/bin/sh /work/holdunit.sh
...

運用管理エージェントが稼働中の場合は，再起動します。

adminagentctl コマンドに，引数「stop」を指定して運用管理エージェントを停止します。

adminagentctl コマンドに，引数「start」を指定して運用管理エージェントを起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl stop
<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

UNIXの場合

# /opt/Cosminexus/manager/bin/adminagentctl stop
# /opt/Cosminexus/manager/bin/adminagentctl start

8.13.2　サービスユニットを自動再起動するための設定

アプリケーションサーバでは，システムに障害が発生しそうな場合の動作をManagementアクションで定義できます。ManagementアクションにSmart Composer機能のコマンドを定義しておくことで，システムの運用中に障害が発生しそうな場合にサービスユニットを自動再起動できるため，迅速な障害対応ができます。

リソース枯渇監視機能でリソースの枯渇を事前に検知したり，J2EEアプリケーションの実行時間監視機能でJ2EEアプリケーションのタイムアウトを検知したりして，障害の発生しそうな状況になるとManagementイベントが発行されます。そのManagementイベントと対応づけたManagementアクションを実行し，障害が発生しそうなサービスユニットを自動的に再起動して，障害の発生を事前に回避します。Managementアクションによるサービスユニットの自動再起動処理を次の図に示します。

図8-20　Managementアクションによるサービスユニットの自動再起動処理

Smart Composer機能を使用すると，JavaVMのフルガーベージコレクションやスレッドなどのリソース枯渇を事前検知した場合，およびJ2EEアプリケーションの実行時間監視でタイムアウトなどが発生した場合に，問題の発生したサービスユニットを自動再起動できます。

ここでは例として，J2EEサーバのフルガーベージコレクションの予兆を検知した場合に，Managementアクションを使用してサービスユニットを自動再起動する方法について説明します。必要な操作は次のとおりです。

Managementアクション実行コマンドの作成

Managementイベントの発行の設定

Managementイベント発行用メッセージIDリストファイルおよびリソース監視機能の設定

Managementアクション実行用プロパティファイルの設定

なお，リソース枯渇監視機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.　リソースの枯渇監視」を参照してください。Managementアクションの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.2　Managementイベントの通知とManagementアクションの概要」を参照してください。設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

＜この項の構成＞

(1)　Managementアクション実行コマンドの作成

(2)　Managementイベントの発行の設定

(3)　Managementイベント発行用メッセージIDリストファイルおよびリソース枯渇監視機能の設定

(4)　Managementアクション実行用プロパティファイルの設定

(1)　Managementアクション実行コマンドの作成

JavaVMのフルガーベージコレクションやスレッドなどのリソース枯渇を事前検知した場合，J2EEアプリケーションの実行時間監視でタイムアウトが発生した場合などに発行されるManagementイベントを受信したときに，Management Serverが実行するManagementアクション実行コマンドを作成します。

ここでは，J2EEサーバのフルガーベージコレクションの予兆を検知した場合，次の順序でサービスユニットを再起動するManagementアクション実行コマンドを作成します。

障害の発生したJ2EEサーバを含むサービスユニットを自動閉塞します。

障害の発生したJ2EEサーバを再起動します。

サービスユニットを開始します。

Managementアクション実行コマンドのサンプルファイルをコピーして，Managementアクション実行コマンド（バッチファイルまたはシェルスクリプト）を作成してください。

(a)　Windowsの場合

サンプルファイル（<Cosminexusのインストールディレクトリ>¥manager¥examples¥maction¥mActionSample_closeUnit.bat）を，C:¥work ¥maction_restartunit.batにコピーして，次のようなバッチファイルを作成します。

maction_restartunit.batファイルの記述例（一部抜粋）

...
set CJCLDELLOG=<Cosminexusのインストールディレクトリ>¥CC¥client¥bin¥cjcldellog.bat
set LOG_ROOT_DIR=%SystemDrive%¥work
...
set MNGSVR=192.168.100.100:%COSMI_MNG_MACT_MNGSVR_PORT%
set UID=cosmi_admin
set PWD=cosmi_admin_passwd

echo cmx_stop_target.exe -m %MNGSVR% -u %UID% -p %PWD% -mode HOLD -s %WEBSYSTEM% -unit %UNIT% >> "%LOG%" 2>&1
cmx_stop_target.exe -m %MNGSVR% -u %UID% -p %PWD% -mode HOLD -s %WEBSYSTEM% -unit %UNIT% >> "%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 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 cmx_start_target.exe -m %MNGSVR% -u %UID% -p %PWD% -mode ALL -s %WEBSYSTEM% -unit %UNIT% >> "%LOG%" 2>&1
cmx_start_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%

(b)　UNIXの場合

サンプルファイル（/opt/Cosminexus/manager/examples/maction/mActionSample_closeUnit.sh）を，/work/maction_restartunit.shにコピーして，次のようなシェルスクリプトを作成します。

maction_restartunit.shファイルの記述例（一部抜粋）

...
LOG_ROOT_DIR=/work
if [ ! -d ${LOG_ROOT_DIR} ]; then
...
MNGSVR=192.168.100.100:${COSMI_MNG_MACT_MNGSVR_PORT}
USERID=cosmi_admin
PASSWD=cosmi_admin_passwd

echo ./cmx_stop_target -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -mode HOLD -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
./cmx_stop_target -m ${MNGSVR} -u ${USERID} -p ${PASSWD} -mode HOLD -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
RET=$?
echo ${RET} >> "${LOG}"

if [ $RET -eq 0 ]; then
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 ./cmx_start_target -m ${MNGSVR} -u ${USERID} -p {PASSWD} -mode ALL -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
./cmx_start_target -m ${MNGSVR} -u ${USERID} -p {PASSWD} -mode ALL -s ${WEBSYSTEM} -unit ${UNIT} >> "${LOG}" 2>&1
RET=$?
echo ${RET} >> "${LOG}"

exit ${RET}

(2)　Managementイベントの発行の設定

J2EEサーバのManagementイベントの発行が有効になっていない場合は，Managementイベントの発行を有効にします。Managementイベントの発行を有効にするには，次の手順で設定を変更してください。

構築済みのシステムの構築時に使用した簡易構築定義ファイルを編集します。
物理ティアの定義（<tier>タグの定義）の<configuration>タグに，次の設定を追加します。

<logical-server-type>タグ：j2ee-server

<param-name>タグ：ejbserver.manager.agent.MEventAgent.enabled

<param-value>タグ：true

MyWebSystemDef.xmlファイルの設定例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">    <web-system>
 <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
     :
   </load-balancer>
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- J2EEサーバのManagementイベントの発行を有効にする設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>ejbserver.manager.agent.MEventAgent.enabled</param-name>
         <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     :
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   :
 </host>
</model-definition>

注　太字の部分が編集部分です。

変更した簡易構築定義ファイルの内容を実際のシステムに反映して，システムの設定を一括で変更します。
システムの設定を一括変更する方法については，「8.10.1(2)　システムの設定変更」を参照してください。

(3)　Managementイベント発行用メッセージIDリストファイルおよびリソース枯渇監視機能の設定

Managementイベントを発行するために，Managementイベント発行用メッセージIDリストファイルの設定や，リソース枯渇監視機能の設定が必要な場合があります。

通常はデフォルトのまま使用するため，設定の必要はありません。必要に応じて設定してください。

(a)　Managementイベント発行用メッセージIDリストファイルの設定

Managementイベントを発行したいメッセージのメッセージIDを，Managementイベント発行用メッセージIDリストファイルに記述します。Managementイベント発行用メッセージIDリストファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.13　Managementイベント発行用メッセージIDリストファイル」を参照してください。

(b)　リソース枯渇監視機能の設定

リソースの監視間隔やしきい値を指定してリソースを監視し，しきい値を超えた場合にアラートを出力できます。また，リソース枯渇監視情報をファイルに出力できます。

リソース枯渇監視機能を使用するためには，次の二つの設定が必要です。

リソース枯渇監視機能の有効化

リソース種別ごとの監視の設定

デフォルトの設定では，リソース枯渇監視機能は有効になっています。リソース枯渇監視機能の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.　リソースの枯渇監視」を参照してください。

(4)　Managementアクション実行用プロパティファイルの設定

Managementアクションの定義，メッセージIDとManagementアクションとのマッピングなどは，Managementアクション実行用プロパティファイル（maction.properties）に定義します。maction.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.11　maction.properties（Managementアクション実行用プロパティファイル）」を参照してください。

運用管理サーバでManagementアクション実行用プロパティファイル（maction.properties）を編集します。
ここでは，メッセージKDJE34500-Wが発行された場合に，「8.13.2(1)　Managementアクション実行コマンドの作成」で作成したManagementアクション実行コマンドが実行される例を示します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥maction.propertiesファイルの設定例を，次に示します。

# Definition of Management action.
maction.restart_unit.command=C:/work/maction_restartunit.bat
maction.restart_unit.timeout=180
maction.restart_unit.timeout.forced_stop=false

# Mapping of Message ID and Management actions.
# KDJE34500-W: Alert - Memory(Java Heap)
maction.message.KDJE34500-W.mactions=restart_unit

# Mapping of Logical server and Management actions.
maction.tier.MyWebSystem.combined-tier.mactions=restart_unit

UNIXの場合

/opt/Cosminexus/manager/config/maction.propertiesファイルの設定例を，次に示します。

# Definition of Management action.
maction.restart_unit.command=/work/maction_restartunit.sh
maction.restart_unit.timeout=180
maction.restart_unit.timeout.forced_stop=false

# Mapping of Message ID and Management actions.
# KDJE34500-W: Alert - Memory(Java Heap)
maction.message.KDJE34500-W.mactions=restart_unit

# Mapping of Logical server and Management actions.
maction.tier.MyWebSystem.combined-tier.mactions=restart_unit

Management Serverが稼働中の場合は，再起動します。

mngsvrctlコマンドに，引数「stop」を指定してManagement Serverを停止します。

mngsvrctlコマンドに，引数「start」を指定してManagement Serverを起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl stop
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl start

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl stop
# /opt/Cosminexus/manager/bin/mngsvrctl start

9.　J2EEアプリケーションを実行するシステムの運用

この章では，J2EEアプリケーションを実行するシステムの運用について説明します。

＜この章の構成＞

9.1　システムの運用の概要

9.2　システムの運用を始める前に

9.3　日常運用の操作

9.4　システムのメンテナンス

9.5　システムの設定変更

9.6　システムのスケールアウト

9.7　システムのスケールイン

9.8　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

9.9　構築済みのシステムの移行

9.10　トラブルへの対処

9.11　システムの削除

9.1　システムの運用の概要

ここでは，システムの運用で使用する機能，アプリケーションサーバで実行できる運用作業について説明します。また，アプリケーションサーバで実行できる運用作業のうち，Smart Composer機能を使用して実行できる運用作業についても説明します。

＜この節の構成＞

9.1.1　システムの運用で使用する機能

9.1.2　アプリケーションサーバで実行できる運用作業

9.1.3　Smart Composer機能を使用した運用作業

9.1.1　システムの運用で使用する機能

ここでは，システムの運用で使用する機能の概要について説明します。システムの運用で使用する機能には，サーバプロセスを操作する機能と，アプリケーションおよびリソースを操作する機能の二つがあります。それぞれの機能の概要について次に説明します。

＜この項の構成＞

(1)　サーバプロセスを操作する機能

(2)　アプリケーションおよひリソースを操作する機能

(1)　サーバプロセスを操作する機能

サーバプロセスを操作する機能について説明します。

●Smart Composer機能のコマンド（cmx_で始まるコマンド）

Smart Composer機能で構築したシステムに対して，Webシステム単位，サービスユニット単位に運用操作を実行するコマンドです。

●運用管理コマンド（mngsvrutil）

Management Serverの運用管理の対象となる，論理サーバの運用操作を実行するコマンドです。

●運用管理ポータル

Webブラウザに表示されるポータル画面を通して，Management Serverの運用管理の対象となる論理サーバの運用操作を実行する機能です。

●J2EEサーバを操作するコマンド

J2EEサーバを起動，停止するためのコマンドです。cjstartsvコマンド，およびcjstopsvコマンドがあります。

●CTMのコマンド

リクエストのスケジューリングをするための機能を提供している，CTMを操作するためのコマンドです。CTMは，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

●PRFのコマンド

システムの処理性能を解析するときに使用する，性能解析トレース情報を編集してファイルに出力したり，PRFトレースファイルの取得レベルを設定したりするコマンドです。

(2)　アプリケーションおよひリソースを操作する機能

●サーバ管理コマンド

J2EEサーバで管理しているアプリケーションおよびリソースの設定をするためのコマンドです。

参考

運用管理ポータルを使用してもアプリケーションおよびリソースを操作できます。運用管理ポータルを使用したアプリケーションおよびリソースの操作については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

9.1.2　アプリケーションサーバで実行できる運用作業

J2EEアプリケーションを実行するシステムでは次に示す運用作業を実施できます。

システムの起動と停止

システムの運用監視

システムの処理性能解析

J2EEアプリケーションとリソースの管理

システムの監査

システムの変更

システム環境の移行

トラブルシューティング

これらの作業を実行するには，主に次の手段を使用します。

Smart Composer機能のコマンドを使用する

運用管理コマンド（mngsvrutil）を使用する

サーバ管理コマンドを使用する

ここでは，運用作業ごとに，アプリケーションサーバで推奨する手段について説明しています。ここで説明している手段以外で運用したい場合は，「付録E　代替手段で実行できる運用作業」を参照してください。

＜この項の構成＞

(1)　システムの起動と停止で実行できる作業

(2)　システムの運用監視で実行できる作業

(3)　システムの処理性能解析で実行できる作業

(4)　J2EEアプリケーションとリソースの管理で実行できる作業

(5)　システムの監査で実行できる運用作業

(6)　システムの変更で実行できる運用作業

(7)　システム環境の移行で実行できる運用作業

(8)　トラブルシューティングで実行できる作業

(1)　システムの起動と停止で実行できる作業

システムの起動と停止で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-1　システムの起動と停止で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
サービスユニットを一括起動します。 | 不要 | － | コマンド編 | cmx_start_target（Webシステムまたはサービスユニットの開始） | Smart Composer機能のコマンド（cmx_start_target）
サービスユニットを一括停止します。 | 不要 | － | コマンド編 | cmx_stop_target（Webシステムまたはサービスユニットの停止） | Smart Composer機能のコマンド（cmx_stop_target）
クラスタソフトウェアを使用したシステムを起動・停止します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 18章 | アプリケーションサーバのコマンド，クラスタソフトウェアの機能

（凡例）

必要：運用前の設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

(2)　システムの運用監視で実行できる作業

システムの運用監視で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-2　システムの運用監視で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
サービスユニットのステータス，およびWebシステムに関連づいていない論理サーバを確認します。 | 不要 | － | コマンド編 | cmx_list_status（サービスユニット状況の表示） | Smart Composer機能のコマンド（cmx_list_status）
論理サーバのステータスを確認します。 | 不要 | － | 運用／監視／連携編 | 2.5.2 | 運用管理コマンド（mngsvrutil）
Webシステム内のサービスユニットの構成，およびWebシステムに関連づいていない論理サーバの一覧を確認します。 | 不要 | － | コマンド編 | cmx_list_model（Webシステムの情報モデルの取得） | Smart Composer機能のコマンド（cmx_list_model）
稼働情報ファイルを参照して，J2EEサーバおよびSFOサーバの稼働情報を監視します。 | 省略可 | 運用／監視／連携編 | 運用／監視／連携編 | 3章 | －
運用管理コマンドを使用して，J2EEサーバおよびSFOサーバの稼働情報を監視します。 | 不要 | － | 運用／監視／連携編 | 8章 | 運用管理コマンド（mngsvrutil）
リソースの使用率や使用数を監視して，しきい値を超えた場合に原因を調査します。 | 省略可 | 運用／監視／連携編 | 運用／監視／連携編 | 4章 | －
稼働情報ファイルに出力される稼働情報，またはリソースの枯渇状況に応じてメッセージが出力された場合の処理を自動化します（Managementアクション）。 | 必要 | 6.1.2(3)，8.13.2，運用／監視／連携編 | 運用／監視／連携編 | 9章 | －
CTMの稼働統計情報を出力します。※ | 不要 | － | 運用／監視／連携編 | 10章 | 運用管理コマンド（mngsvrutil）
トランザクションの状態を確認します。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.15.9 | サーバ管理コマンド（cjlisttrn）

（凡例）

必要：運用前の設定が必要です。

省略可：デフォルトの設定で使用できるため，運用前の設定は省略できます。この動作をデフォルトから変更する場合は設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

基本・開発編(コンテナ共通機能)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を示します。

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

(3)　システムの処理性能解析で実行できる作業

システムの処理性能解析で実行できる作業について，次の表に示します。

表9-3　システムの処理性能解析で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
性能解析トレースファイルを収集します。 | 不要 | － | 保守／移行／互換編 | 6.3 | 運用管理コマンド（mngsvrutil）
収集した性能解析トレースファイルを利用してシステムの処理性能を解析します。 | 不要 | － | 保守／移行／互換編 | 6.6 | －

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

(4)　J2EEアプリケーションとリソースの管理で実行できる作業

J2EEアプリケーションとリソースの管理で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-4　J2EEアプリケーションとリソースの管理で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
Webアプリケーションの稼働状況を確認します。 | 不要 | － | 基本・開発編(Webコンテナ) | 2.19.2 | 運用管理コマンド（mngsvrutil）
アクセス状況に応じて，Webアプリケーションの同時実行スレッド数を動的に変更します。 | 不要 | － | 基本・開発編(Webコンテナ) | 2.19.2 | 運用管理コマンド（mngsvrutil）
CTMのスケジュールキューの稼働状況を確認して，同時実行数を動的に変更します。※1 | 不要 | － | 拡張編 | 3.6.3 | 確認：運用管理コマンド（mngsvrutil）
3.6.4 | 確認と変更：CTMのコマンド（ctmlsque，ctmchpara）
J2EEアプリケーションの実行状態を確認して，J2EEアプリケーションでタイムアウトが発生したリクエストをキャンセルします（J2EEアプリケーションの実行時間監視機能）。 | 必要 | 6.1.2(3)，8.13.2，運用／監視／連携編 | 運用／監視／連携編 | 5.3.11 | 確認：サーバ管理コマンド（cjlistthread）
5.3.12 | キャンセル：サーバ管理コマンド（cjstopthread）
J2EEアプリケーションを通常開始します。 | 不要 | － | コマンド編 | cjstartapp（J2EEアプリケーションの開始） | サーバ管理コマンド（cjstartapp）
J2EEアプリケーションを通常停止します。 | 不要 | － | 運用／監視／連携編 | 5.5.7 | サーバ管理コマンド（cjstopapp）
J2EEアプリケーションを強制停止します。 | 不要 | － | 運用／監視／連携編 | 5.5.7 | サーバ管理コマンド（cjstopapp）
負荷分散機を使用してサービスを閉塞します。※2 | － | － | 運用／監視／連携編 | 5.4.3 | 負荷分散機の機能
CTMを利用してサービスを閉塞します。※1 | 不要 | － | 拡張編 | 3.7.3 | 運用管理コマンド（mngsvrutil）
J2EEアプリケーションを入れ替えます。 | リデプロイによる入れ替え | 省略可 | 運用／監視／連携編 | このマニュアル | 9.4.2(1) | サーバ管理コマンド（cjreplaceapp）
運用／監視／連携編 | 5.6.3
通常の入れ替え | 不要 | － | このマニュアル | 9.4.2(2) | サーバ管理コマンド（cjstopapp，cjimportapp）
運用／監視／連携編 | 5.6.3
リロードによる入れ替え | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 5.6.3 | サーバ管理コマンド（cjreloadapp）
JSPを事前にコンパイルしてから，J2EEアプリケーションを入れ替えます。 | 省略可／不要 | 運用／監視／連携編 | 運用／監視／連携編 | 5.6.3 | cjjspcコマンド
J2EEアプリケーションの名称を変更します。 | 不要 | － | － | － | サーバ管理コマンド（cjrenameapp）
CTMを利用して，オンライン状態でJ2EEアプリケーションを入れ替えます。※1 | 不要 | － | 拡張編 | 3.7.2 | 運用管理コマンド（mngsvrutil）
J2EEアプリケーションを本番環境でテストしてから本番運用を開始します。 | 不要 | － | 運用／監視／連携編 | 5.7 | サーバ管理コマンド（cjimportapp，cjstartapp）
コネクションプールの情報を表示します。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.15.4 | サーバ管理コマンド（cjlistpool）
コネクションプールをクリアします。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.15.5 | サーバ管理コマンド（cjclearpool）
JavaBeansリソースを入れ替えます。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.12.5 | サーバ管理コマンド（cjdeletejb，cjimportjb）
クラスタ構成のデータベースをメンテナンスします。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.17.4 | サーバ管理コマンド（cjlistrar，cjsuspendpool，cjresumepool）
リソースの接続テストをします。 | 必要 | 基本・開発編(コンテナ共通機能) | 基本・開発編(コンテナ共通機能) | 3.18 | サーバ管理コマンド（cjtestres）

（凡例）

必要：運用前の設定が必要です。

省略可：デフォルトの設定で使用できるため，運用前の設定は省略できます。この動作をデフォルトから変更する場合は設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

基本・開発編(Webコンテナ)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」を示します。

拡張編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

基本・開発編(コンテナ共通機能)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を示します。

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

注※2　負荷分散機をSmart Composer機能で管理していない場合に実行します。負荷分散機をSmart Composer機能で管理している場合は，cmx_stop_targetコマンドを使用してサービスを閉塞してください。cmx_stop_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

(5)　システムの監査で実行できる運用作業

監査ログを使用したシステムの監査，およびデータベース監査証跡と連携した運用で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-5　システムの監査で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
監査ログを出力して，管理します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 6章 | －
監査ログを収集して調査します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 17章 | －
データベース監査証跡に出力された情報を基に，データベースにアクセスしたリクエストの情報を特定します。 | 不要 | － | 運用／監視／連携編 | 7章 | －

（凡例）

必要：運用前の設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

(6)　システムの変更で実行できる運用作業

システムの変更で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-6　システムの変更で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先 | 手段
設定変更 | システム全体の設定を一括で変更します。 | 不要 | － | 9.5 | －
構成変更 | システムをスケールアウトします。 | 不要 | － | 9.6，9.8 | －
システムをスケールインします。 | 不要 | － | 9.7，9.8 | －
削除 | システムを削除します。 | 不要 | － | 9.11 | －

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

(7)　システム環境の移行で実行できる運用作業

システム環境の移行で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-7　システム環境の移行で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先 | 手段
構築済みのシステムの環境を移行します。 | 不要 | － | 9.9 | Smart Composer機能のコマンド（cmx_export_model）

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

(8)　トラブルシューティングで実行できる作業

トラブルシューティングで実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表9-8　トラブルシューティングで実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照マニュアル | 参照個所 | 手段
トラブルシューティングに必要な資料を収集します。 | 必要／省略可 | 6.1.2(1)，保守／移行／互換編 | 保守／移行／互換編 | 2.3 | 運用管理コマンド（mngsvrutil）
論理サーバ（構成ソフトウェアのサーバプロセス）に異常が発生した場合の処理を自動化します。 | 省略可 | 保守／移行／互換編 | 保守／移行／互換編 | 2.2.2 | －
トラブルシューティングに必要な資料を調査します。 | 不要 | － | 保守／移行／互換編 | 5章 | －
負荷分散機を閉塞して，Webシステムの部分メンテナンスをします。 | 不要 | － | このマニュアル | 9.4.1 | －

（凡例）

必要：運用前の設定が必要です。

省略可：デフォルトの設定で使用できるため，運用前の設定は省略できます。この動作をデフォルトから変更する場合は設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

9.1.3　Smart Composer機能を使用した運用作業

ここでは，Smart Composer機能を使用した運用操作について説明します。そのほかの運用作業については，「9.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。

Smart Composer機能を使用した運用操作では，一括起動・一括停止の日常運用の操作，J2EEアプリケーションの入れ替えなどによるシステムのメンテナンス，スケールインやスケールアウト，環境の移行や削除などが実施できます。ここでは，次に示す運用操作の手順を説明しています。

日常運用（9.3参照）

サービスユニットの一括起動

サービスユニットの一括停止

メンテナンス

システムの部分メンテナンス（9.4.1参照）

J2EEアプリケーションの一括入れ替え（9.4.2参照）

システムの設定変更（9.5参照）

システムの構成変更

システムのスケールアウト（9.6，9.8.1および9.8.2参照）

システムのスケールイン（9.7および9.8.3参照）

構築済みのシステムの移行（9.9参照）

システムの削除（9.11参照）

それぞれの運用の概要については，「6.1.1　運用設計」を参照してください。また，Smart Composer機能のコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「8.　Smart Composer機能で使用するコマンド」を参照してください。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「2.　J2EEサーバで使用するコマンド」を参照してください。

9.2　システムの運用を始める前に

ここでは，システムの運用を始める前に確認，準備しておくことについて説明します。

＜この節の構成＞

9.2.1　Component Container管理者による運用に関する留意事項

9.2.2　運用管理コマンド（mngsvrutil）を利用する場合の留意事項

9.2.3　サーバ管理コマンドを利用する場合の留意事項

9.2.4　作業ディレクトリに関する注意事項

9.2.5　RMIレジストリに関する注意事項

9.2.6　コマンド実行時に指定するWebシステム名，サービスユニット名，およびサーバ名に関する注意事項

9.2.1　Component Container管理者による運用に関する留意事項

UNIXでComponent Container管理者を設定している場合の留意事項について説明します。Component Container管理者とは，UNIXを使用している場合に，J2EEサーバ，またはバッチサーバの構築・運用に関する操作を実行できる権限を持つユーザです。Component Container管理者を設定することで，root権限を持たないユーザでも，J2EEサーバ，またはバッチサーバの起動・停止やサーバ管理コマンドの実行など，システム運用時の操作を実行できるようになります。

注意

Component Container管理者を設定している場合，Component Container管理者が実行できる操作は，一部の操作を除き，スーパーユーザでは操作できなくなるので注意してください。詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.4　Component Container管理者によるシステムの運用（UNIXの場合）」を参照してください。

なお，Component Container管理者の設定，Component Container管理者が実施できる操作，およびパーミッションが変更されるディレクトリについては，「7.2.3　Component Container管理者の設定（UNIXの場合）」を参照してください。

9.2.2　運用管理コマンド（mngsvrutil）を利用する場合の留意事項

運用管理コマンド（mngsvrutil）は，運用操作を実行するコマンドです。

mngsvrutilコマンドは，運用管理エージェントおよびManagement Serverが起動している状態で実行できるコマンドです。運用管理エージェントおよびManagement Serverを起動してから実行してください。

なお，このマニュアルで説明する実行形式および実行例では，その操作に主に関連する引数だけを示して説明します。指定できる引数の詳細など，コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

9.2.3　サーバ管理コマンドを利用する場合の留意事項

サーバ管理コマンドは，J2EEアプリケーションやリソースの設定およびカスタマイズを実行するコマンドです。サーバ管理コマンドは，J2EEサーバが起動している状態で実行できるコマンドです。J2EEサーバおよびその前提プロセスを起動してから実行してください。

サーバ管理コマンドには，参照系コマンド，更新系コマンド，および特権系コマンドがあります。これらは，組み合わせによって，同時に実行できるものと，排他処理されるものがあります。実行時には注意してください。サーバ管理コマンドの同時実行についての制約に関しては，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.2.2　サーバ管理コマンドの排他制御」を参照してください。

なお，このマニュアルで説明する実行形式および実行例では，その操作に主に関連する引数だけを示して説明します。

サーバ管理コマンドの系統，指定できる引数など，コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

2.3　J2EEアプリケーションで使用するコマンド

2.4　J2EEサーバで使用するリソース操作コマンド

9.2.4　作業ディレクトリに関する注意事項

作業ディレクトリとは，usrconf.cfg（J2EEサーバ用オプション定義ファイル）のejb.public.directoryキーに指定したディレクトリです。usrconf.cfgについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.3　usrconf.cfg（J2EEサーバ用オプション定義ファイル）」を参照してください。

作業ディレクトリの運用では，次の点に注意してください。

Cosminexus Component Container以外のアプリケーションで，作業ディレクトリ以下のディレクトリおよびファイルを使用しないでください。J2EEサーバを起動した場合に，例外が発生することがあります。

作業ディレクトリ以下のディレクトリ構成を変更しないでください。また，ファイルを追加，または削除しないでください。なお，次の変更はできます。

J2EEサーバが稼働中の場合
Cosminexus Component ContainerのアプリケーションからJ2EEサーバのカレントディレクトリ※へのファイル入出力

J2EEサーバが稼働中，削除中のどちらでもない場合
Cosminexus Component ContainerのアプリケーションからJ2EEサーバのカレントディレクトリ※へのファイル入出力，またはそれ以外のアプリケーションからのJ2EEサーバのカレントディレクトリ※へのファイル入出力

注※　J2EEサーバのカレントディレクトリは，「＜作業ディレクトリ＞/ejb/＜J2EEサーバ名＞」です。

9.2.5　RMIレジストリに関する注意事項

Management Serverは，J2EEサーバの運用監視に，J2EEサーバ上で動作するRMIレジストリを使用します。そのため，Management Serverが管理しているRMIレジストリの情報と実際に動作しているJ2EEサーバのRMIレジストリの情報が一致していないと，運用監視に失敗する場合があります。Management Serverの管理しているRMIレジストリの情報は，次のタイミングで更新されます。J2EEサーバ上で動作するRMIレジストリと異ならないように注意してください。

運用管理ポータルの「Cosminexus Management Serverの設定」で構成情報の回復を実行した場合

運用管理ポータルの「論理サーバの環境設定」で「適用」ボタンを押した場合

運用管理ポータルの「論理サーバの環境設定」からサーバの設定の読み込みを実行した場合

cmx_build_model.exeコマンドを実行した場合

cmx_change_model.exeコマンドを実行した場合

運用管理ポータルの操作については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の次の個所を参照してください。

8.　Cosminexus Management Serverの設定

10.　論理サーバの環境設定

各コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cmx_build_model（Webシステムの情報モデルの生成）

cmx_change_model（Webシステムの情報モデルの変更）

9.2.6　コマンド実行時に指定するWebシステム名，サービスユニット名，およびサーバ名に関する注意事項

運用作業でコマンドを実行する際，コマンドによって次の四つの異なる名称を指定します。各名称の対応を確認するには，コマンドや簡易構築定義ファイルを使用する必要があります。

Webシステム名
Smart Composer機能のコマンドに指定します。
例：cmx_start_target -s <Webシステム名>

サービスユニット名
Smart Composer機能のコマンドに指定します。
例：cmx_start_target -s <Webシステム名> -unit <サービスユニット名>

論理サーバ名
運用管理コマンド（mngsvrutil）に指定します。
例：mngsvrutil start -t <論理サーバ名>

実サーバ名
サーバ管理コマンドに指定します。
例：cjstartsv <実サーバ名>

各名称の対応は，次の方法で確認してください。

cmx_list_modelコマンドを実行することで，次の名称の対応を確認します。

ホスト名

Webシステム名

サービスユニット名

論理サーバ名

実行例

cmx_list_model -m localhost:28080 -u admin -p admin -modeltype SERVEREX
cmx_sample-system_unit1_PRF_01,PerformanceTracer,host1,combined-tier,unit1,sample-system
cmx_sample-system_unit1_J2EE_01,J2EEServer,host1,combined-tier,unit1,sample-system
cmx_sample-system_unit1_HTTP_01,WebServer,host1,combined-tier,unit1,sample-system
cmx_sample-system_unit2_PRF_01,PerformanceTracer,host2,combined-tier,unit2,sample-system
cmx_sample-system_unit2_J2EE_01,J2EEServer,host2,combined-tier,unit2,sample-system
cmx_sample-system_unit2_HTTP_01,WebServer,host2,combined-tier,unit2,sample-system

簡易構築定義ファイルで，次の名称の対応を確認します。

論理サーバ名（logical-server-name）
論理サーバ名が定義されていない場合は，自動生成されます。

実サーバ名（realservername）
実サーバ名が定義されていない場合は，論理サーバ名と同じになります。

9.3　日常運用の操作

Smart Composer機能では，日常運用の操作として，システムの一括起動および一括停止がサービスユニット単位で実施できます。システム内のすべてのサービスユニットを一括で起動および停止することも，特定のサービスユニットだけを一括で起動および停止することもできます。

＜この節の構成＞

9.3.1　すべてのサービスユニットの一括起動と一括停止

9.3.2　サービスユニット単位の一括起動と一括停止

9.3.1　すべてのサービスユニットの一括起動と一括停止

一括起動をするにはcmx_start_targetコマンドを，一括停止をするには，cmx_stop_targetコマンドを使用します。システム内のすべてのサービスユニットを一括起動したり，一括停止したりするには，これらのコマンドを使用するときに，-unitオプションの指定を省略します。

ここでは，システム内のすべてのサービスユニットを，一括起動および一括停止する手順について説明します。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　一括起動

(2)　一括停止

(1)　一括起動

システム内のすべてのサービスユニットを一括で起動するときの手順を次に示します。システム内のすべてのサービスユニットを稼働状態にするには，-modeオプションに「ALL」を指定します。

Management Serverと運用管理エージェントが稼働しているかどうかを確認します。
mngsvrutilコマンドの引数checkを使用して，Management Serverと運用管理エージェントが稼働しているかどうかを確認します。Management Serverの稼働状態を確認する場合は「mngsvr」を，運用管理エージェントの稼働状態を確認する場合は「adminAgent」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv2 check adminAgent

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent
# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv2 check adminAgent

システム内のすべてのサービスユニットを一括起動します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを稼働状態で起動します。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

リソースアダプタおよびJ2EEアプリケーションが停止している場合は，サービスユニットを起動したあとで，開始する必要があります。リソースアダプタおよびJ2EEアプリケーションの開始については，「8.8.3　リソースアダプタのインポートと開始」および「8.8.4　J2EEアプリケーションのインポートと開始」を参照してください。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。

論理サーバの起動に失敗すると，リクエストの受け付けを開始できなかったり，受け付けたリクエストを処理できなかったりします。cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

(2)　一括停止

システム内のすべてのサービスユニットを一括で停止するときの手順を次に示します。システム内のすべてのサービスユニットを停止状態にするには，-modeオプションに「ALL」を指定します。

業務実行中の場合は，システム内のすべてのサービスユニットを閉塞状態にして負荷分散機から切り離します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを閉塞状態にします。このとき，コマンドの-modeオプションには「HOLD」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

負荷分散機からのリクエストの振り分けが抑止されている状態になり，論理Webサーバも停止されます。

実行中のリクエストの処理が完了したら，システム内のすべてのサービスユニットを一括停止します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを停止状態にします。このとき，コマンドの-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

サービスユニット内のすべての論理サーバが停止されます。

参考

サービスユニットを一括停止すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

Webシステムに関連づいていない論理サーバを含むシステムの場合，論理Webサーバの停止に失敗しても処理を続行します。論理Webサーバの停止に失敗すると，リクエストの受け付けは継続されます。この場合，cmx_stop_targetコマンドを次の順序で実行すると，論理Webサーバだけを停止してからサービスユニットを停止できます。

cmx_stop_targetコマンドに「HOLD」を指定して実行する。
サービスユニットを閉塞状態にできます。サービスユニットを閉塞状態にすると，論理Webサーバだけが停止状態になります。

cmx_stop_targetコマンドに「ALL」を指定して実行する。
サービスユニットを停止状態にできます。

cmx_stop_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

9.3.2　サービスユニット単位の一括起動と一括停止

一括起動をするにはcmx_start_targetコマンドを，一括停止をするにはcmx_stop_targetコマンドを使用します。特定のサービスユニットを一括起動したり，一括停止したりするには，これらのコマンドを使用するときに，-unitオプションにサービスユニット名を指定します。

ここでは，特定のサービスユニットだけを，一括起動および一括停止する手順について説明します。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　一括起動

(2)　一括停止

(1)　一括起動

特定のサービスユニットを一括で起動するときの手順を次に示します。特定のサービスユニットを稼働状態にするには，起動対象のサービスユニット名と，-modeオプションに「ALL」を指定します。

Management Serverと運用管理エージェントが稼働しているかどうかを確認します。
mngsvrutilコマンドの引数checkを使用して，Management Serverと運用管理エージェントが稼働しているかどうかを確認します。Management Serverの稼働状態を確認する場合は「mngsvr」を，運用管理エージェントの稼働状態を確認する場合は「adminAgent」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv2 check adminAgent

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent
# /opt/Cosminexus/manager/bin/mngsvrutil -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -t apsv2 check adminAgent

業務を開始したいサービスユニットを起動します。
cmx_start_targetコマンドを使用して，サービスユニット「unit1」を稼働状態で起動します。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

リソースアダプタおよびJ2EEアプリケーションが停止している場合は，サービスユニットを起動したあとで，開始する必要があります。リソースアダプタおよびJ2EEアプリケーションの開始については，「8.8.3　リソースアダプタのインポートと開始」および「8.8.4　J2EEアプリケーションのインポートと開始」を参照してください。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。

論理サーバの起動に失敗すると，リクエストの受け付けを開始できなかったり，受け付けたリクエストを処理できなかったりします。cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

(2)　一括停止

特定のサービスユニットを一括で停止するときの手順を次に示します。特定のサービスユニットを停止状態にするには，停止対象のサービスユニット名と，-modeオプションに「ALL」を指定します。

業務実行中の場合は，停止したいサービスユニットを閉塞状態にして負荷分散機から切り離します。
cmx_stop_targetコマンドを使用して，サービスユニット「unit1」を閉塞状態にします。このとき，コマンドの-modeオプションには「HOLD」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem -unit unit1

サービスユニット「unit1」は，負荷分散機からのリクエストの振り分けが抑止されている状態になり，論理Webサーバも停止されます。

実行中のリクエストの処理が完了したら，閉塞状態のサービスユニットを停止します。
cmx_stop_targetコマンドを使用して，サービスユニット「unit1」を停止状態にします。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

サービスユニット「unit1」内のすべての論理サーバが停止されます。

参考

サービスユニットを一括停止すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

Webシステムに関連づいていない論理サーバを含むシステムの場合，論理Web

サーバの停止に失敗しても処理を続行します。論理Webサーバの停止に失敗すると，リクエストの受け付けは継続されます。この場合，cmx_stop_targetコマンドを次の順序で実行すると，論理Webサーバだけを停止してからサービスユニットを停止できます。

cmx_stop_targetコマンドに「HOLD」を指定して実行する。
サービスユニットを閉塞状態にできます。サービスユニットを閉塞状態にすると，論理Webサーバだけが停止状態になります。

cmx_stop_targetコマンドに「ALL」を指定して実行する。
サービスユニットを停止状態にできます。

cmx_stop_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

9.4　システムのメンテナンス

Smart Composer機能で構築したシステムは，サービスユニットを閉塞することでシステムを部分的に点検したり，J2EEアプリケーションを入れ替えたりして，システムのメンテナンスができます。

ここでは，システムのメンテナンスについて説明します。

＜この節の構成＞

9.4.1　サービスユニットの閉塞によるシステムの部分メンテナンス

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

9.4.1　サービスユニットの閉塞によるシステムの部分メンテナンス

Smart Composer機能では，サービスユニット単位で一括起動および一括停止のコマンドを実行できるので，業務全体を停止することなく，特定のサービスユニットを閉塞したり，再開したりできます。これによって，OSのパッチ適用や予防保守・点検などのシステムの部分メンテナンスを，業務を停止しないで実施できます。

さらに，サービスユニットの閉塞・メンテナンス・再開の処理をサービスユニット単位に順次適用することで，業務全体を停止することなく，システム全体のメンテナンスも実施できます。

ここでは，サービスユニットを閉塞して，システムの部分メンテナンスをするときの手順について説明します。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

メンテナンスをしたいサービスユニットを閉塞します。
サービスユニットを閉塞するには，サービスユニットをWebシステムから切り離す方法と，サービスユニットをWebシステムから切り離して停止する方法の二つがあります。どちらの方法もcmx_stop_targetコマンドを使用しますが，コマンドの-modeオプションに指定する値が異なります。
アプリケーションの入れ替えなどの場合は「HOLD」を指定してサービスユニットをWebシステムから切り離します。OSのメンテナンスでマシンの再起動が必要な場合などの場合は「ALL」を指定して，サービスユニットをWebシステムから切り離して停止します。
なお，サービスユニットをWebシステムから切り離すだけの場合は，実行中のリクエストを処理したあとは，最終的にサービスユニット内の論理Webサーバだけが停止した状態になります。

サービスユニットをWebシステムから切り離す方法
-modeオプションに「HOLD」を指定します。サービスユニット「unit1」を閉塞状態にして，Webシステムから切り離します。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem -unit unit1

サービスユニットをWebシステムから切り離して，停止する方法
-modeオプションに「ALL」を指定します。サービスユニット「unit1」を停止状態にして，Webシステムから切り離します。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

閉塞したサービスユニットをメンテナンスします。
閉塞したサービスユニットに対して，OSのパッチ適用や予防保守・点検などのメンテナンスを実施します。

サービスユニットを再開します。
cmx_start_targetコマンドを使用してサービスユニット「unit1」を再開します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

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

J2EEアプリケーションを入れ替える手順には，リデプロイによる入れ替えと通常の入れ替えの2種類があります。ここでは，それぞれの手順について，次のJ2EEアプリケーションを使用する場合を例にして説明します。J2EEアプリケーションは，cosminexus.xmlを含むアプリケーションであることを前提としています。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

表9-9　例で使用するJ2EEアプリケーションのファイル名と表示名

種別 | 名前
入れ替え前のファイル名 | MyApp.ear
入れ替え後のファイル名 | MyApp-1_1.ear
表示名 | MyApp

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-10　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。サービスユニット2に対しても，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

J2EEサーバ名：cmx_MyWebSystem_unit2_J2EE_01

-nameserver指定値：corbaname::192.168.1.12:900

リロードによる入れ替え

入れ替えの対象となるJ2EEアプリケーションが展開ディレクトリ形式の場合，リロードによる入れ替えができます。

リロードによる入れ替えの方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。また，リロードによる入れ替えを実行するには，事前に設定が必要です。設定方法の詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.8.12　J2EEアプリケーションの更新検知とリロードの設定」を参照してください。

＜この項の構成＞

(1)　リデプロイによる入れ替え

(2)　通常の入れ替え

(1)　リデプロイによる入れ替え

アーカイブ形式のJ2EEアプリケーションを入れ替える場合には，リデプロイによる入れ替えが実行できます。リデプロイによる入れ替えを実行すると，少ない手順でJ2EEアプリケーションを入れ替えられます。

リデプロイによるJ2EEアプリケーションの入れ替えには，実施する際の注意事項や条件があります。条件および注意事項については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の次の個所を参照してください。

12.7.1　リデプロイによるJ2EEアプリケーションの入れ替え

12.7.3　リデプロイによるJ2EEアプリケーションの入れ替えの注意事項

J2EEアプリケーションのリデプロイによる入れ替えの手順を次に示します。

システムの状態に応じて，システムを起動または閉塞します。
システムが停止している場合は，システム全体を起動します。システムが稼働している場合はシステム全体を閉塞します。

システムが停止している場合
cmx_start_targetコマンドを使用して一括起動します。このとき，コマンドの-modeオプションに「READY」を指定して，サービスユニットを準備状態※にします。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

システムが稼働している場合
cmx_stop_targetコマンドを使用して一括停止します。このとき，コマンドの-modeオプションに「HOLD」を指定して，サービスユニットを閉塞状態※にします。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

注※　どちらも負荷分散機からのリクエストの振り分けが抑止されている状態になります。準備状態と閉塞状態の差異は，論理Webサーバが停止しているかどうかだけとなります。閉塞状態のときは論理Webサーバが停止しています。

入れ替えるEARファイルのパスを指定して，リデプロイします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjreplaceapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp -f MyApp-1_1.ear

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjreplaceapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp -f MyApp-1_1.ear

手順2.をサービスユニット1およびサービスユニット2で実施したあとで，システム全体を一括起動します。
cmx_start_targetコマンドを使用して，システムを一括起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

参考

CTMを使用する構成のシステムでは，システムを閉塞しないでバックシステムのアプリケーションを入れ替えることができます。そのため，CTMを使用する構成のシステムでは，手順1.と手順3.が不要です。

(2)　通常の入れ替え

J2EEアプリケーションの通常の入れ替えとは，変更前のJ2EEアプリケーションを削除し，変更後のJ2EEアプリケーションをインポートすることです。J2EEアプリケーションの通常の入れ替えの手順を次に示します。

システムの状態に応じて，システムを起動または閉塞します。
システムが停止している場合は，システム全体を起動します。システムが稼働している場合はシステム全体を閉塞します。

システムが停止している場合
cmx_start_targetコマンドを使用して一括起動します。このとき，コマンドの-modeオプションに「READY」を指定して，サービスユニットを準備状態※にします。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem

システムが稼働している場合
cmx_stop_targetコマンドを使用して一括停止します。このとき，コマンドの-modeオプションに「HOLD」を指定して，サービスユニットを閉塞状態※にします。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode HOLD -s MyWebSystem

注※　どちらも負荷分散機からのリクエストの振り分けが抑止されている状態になります。準備状態と閉塞状態の差異は，論理Webサーバが停止しているかどうかだけとなります。閉塞状態のときは論理Webサーバが停止しています。

J2EEアプリケーションを停止します。
サーバ管理コマンドを使用して，J2EEアプリケーションを停止します。-nameオプションには，J2EEアプリケーション名を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

入れ替え前のJ2EEアプリケーションを削除します。
サーバ管理コマンドを使用して，J2EEアプリケーションを削除します。-nameオプションには，削除するJ2EEアプリケーション名を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeleteapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjdeleteapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

入れ替え後のJ2EEアプリケーションをインポートします。
サーバ管理コマンドを使用して，入れ替え後のJ2EEアプリケーションをインポートします。-fオプションには，入れ替え後のJ2EEアプリケーションのパスを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp-1_1.ear

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp-1_1.ear

参考

次に示す場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

インポート済みのJ2EEアプリケーションのプロパティを編集する場合

cosminexus.xmlを含まないアプリケーションの場合

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

J2EEアプリケーションを開始します。
サーバ管理コマンドを使用して，J2EEアプリケーションを開始します。-nameオプションには，J2EEアプリケーション名を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

手順2.から5.までをサービスユニット1およびサービスユニット2で実施したあとで，システム全体を一括起動します。
cmx_start_targetコマンドを使用して，システムを一括起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

参考

CTMを使用する構成のシステムでは，システムを閉塞しないでバックシステムのアプリケーションを入れ替えることができます。そのため，CTMを使用する場合の構成のシステムでは，手順1.と手順6.は不要です。

9.5　システムの設定変更

Smart Composer機能では，システム全体の設定を変更できます。ここでは，システム全体の設定変更について説明します。

注意

システムを構築したあとにシステムを構成変更する場合は，構成変更定義ファイルを使用してください。簡易構築定義ファイルを編集しても，システムは構成変更できません。

＜この節の構成＞

9.5.1　システムの設定の一括変更

9.5.2　システムの設定変更時の注意事項

9.5.1　システムの設定の一括変更

Smart Composer機能を使用して，システムの設定を一括変更できます。設定を変更するには，次の内容を実施します。

簡易構築定義ファイルの編集

設定の一括変更

注意

変更する設定内容によっては，変更時に注意が必要です。設定変更時の注意事項については，「9.5.2　システムの設定変更時の注意事項」を参照してください。

システムの設定の一括変更の手順について，説明します。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　簡易構築定義ファイルの編集

(2)　設定の一括変更

(1)　簡易構築定義ファイルの編集

実際のシステムの構築に使用した簡易構築定義ファイルの内容を編集します。ここでは，MyWebSystemDef.xmlファイルを編集します。

実際のシステムの構築に使用した簡易構築定義ファイルを編集します。
ここでは，Webサーバの停止監視時間を5分に変更して，J2EEサーバの稼働性能を監視するように設定します。
設定後のMyWebSystemDef.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">    <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 負荷分散機の定義 -->
   <load-balancer>
       ：
   </load-balancer>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- Webサーバの停止監視時間を5分に設定 -->
     <configuration>
       <logical-server-type>web-server</logical-server-type>
       <param>
         <param-name>mstartup.watchtime</param-name>
         <param-value>300</param-value>
       </param>
     </configuration>
     <!-- J2EEサーバの稼働性能監視を行う設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>ejbserver.instrumentation.enabled</param-name>
         <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     ：
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   ：
 </host>
 </web-system>
</model-definition>

注　太字の部分が編集部分です。

なお，作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　設定の一括変更

変更した簡易構築定義ファイルの内容を基に，システムの設定を一括で変更します。

システムが稼働している場合は，システムを停止します（必要に応じて）。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを一括停止します。このとき，コマンドの-modeオプションに「ALL」を指定して，停止状態にします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

変更した簡易構築定義ファイルの内容を実際のシステムに展開します。
cmx_build_systemコマンドに-changeオプションを指定して，(1)で変更した簡易構築定義ファイルの内容を実際のシステムに適用します。-fオプションには，(1)で作成した簡易構築定義ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml -change

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml -change

システムを開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

9.5.2　システムの設定変更時の注意事項

Smart Composer機能を使用して，システム全体の設定を変更する場合の，注意事項について説明します。

＜この項の構成＞

(1)　Webサーバのポート番号変更時の注意事項

(1)　Webサーバのポート番号変更時の注意事項

サーバマシン内に複数のサービスユニットを配置する場合に，Webサーバのポート番号を変更するときは，次に示す制限事項があります。なお，複数のサービスユニットが，同一のWebシステム内にある場合も，異なるWebシステムにある場合も，この制限事項の対象となります。

(a)　複数のサービスユニットのWebサーバで同じポート番号を設定している場合

1台のサーバマシン内で，複数のサービスユニットを同時に起動しない運用をする場合は，各サービスユニットのWebサーバに同じポート番号を設定できます。

この場合は，次のどちらかの手順で変更してください。

すべてのサービスユニットのWebサーバのポート番号を同時に変更します。

一部のサービスユニットのWebサーバのポート番号を変更します。そのあと，ほかのサービスユニットのWebサーバのポート番号を変更します。

注意

一部のサービスユニットのWebサーバのポート番号を変更した場合，ほかのサービスユニットのWebサーバのポート番号は削除され，ポート番号を削除されたWebサーバは使用できなくなります。このため，必ず，あとからほかのサービスユニットのWebサーバのポート番号も変更してください。

(b)　複数のサービスユニットのWebサーバで異なるポート番号を設定している場合

ここでは，サービスユニット１（unit1）のWebサーバでポート番号に80，サービスユニット2（unit2）のWebサーバでポート番号に81を設定している場合を例に説明します。ポート番号の設定変更の方法と変更可否を次の表に示します。

表9-11　ポート番号の変更方法と変更可否

ポート番号の変更方法 | 論理サーバのパラメタ変更用の構成変更定義ファイルの設定方法 | 変更後のWebサーバのポート番号 | 変更可否
unit1 | unit2
各サービスユニットのWebサーバのポート番号を同じ番号へ変更 | サービスユニット1のWebサーバにポート番号81を設定します。 | 81 | 81 | ○
サービスユニット2のWebサーバにポート番号80を設定します。 | 80 | 80 | ○
各サービスユニットのWebサーバのポート番号の入れ替え | サービスユニット1のWebサーバにポート番号81を，サービスユニット2のWebサーバにポート番号80を設定します。 | 81 | 80 | ×
一方のサービスユニットのWebサーバを他方で設定済みのポート番号に変更して，他方のサービスユニットのWebサーバを未使用のポート番号（82とする）へ変更 | サービスユニット1のWebサーバにポート番号81を，サービスユニット2のWebサーバにポート番号82を設定します。 | 81 | 82 | ×
サービスユニット1のWebサーバにポート番号82を，サービスユニット2のWebサーバにポート番号80を設定します。 | 82 | 80 | ×
一方のサービスユニットのWebサーバを未使用のポート番号（82とする）へ変更 | サービスユニット1のWebサーバにポート番号82を設定します。 | 82 | 81 | ○
サービスユニット2のWebサーバにポート番号82を設定します。 | 80 | 82 | ○

（凡例）○：変更できます。　×：変更できません。

参考

設定済みのポート番号に変更する場合に，1回の操作で変更できない変更方法は，いったん未使用のポート番号を設定してから入れ替えたり，複数回に分けて変更したりするなどの，設定変更操作を実施すれば変更できます。

9.6　システムのスケールアウト

Smart Composer機能を使用すると，業務全体を停止することなく，システムの構成を変更できます。システムの規模を拡張する場合は，システムをスケールアウトします。

構成定義パターンと，システムのスケールアウト手順の参照先を次の表に示します。なお，構成定義パターンについては，「5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定」を参照してください。

表9-12　構成定義パターンとシステムのスケールアウト手順の参照先

構成定義パターン | システムのスケールアウト手順の参照先
WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier） | 「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」
WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ） | 「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」
インプロセスHTTPサーバを使用するパターン（j2ee-tier） | 「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」
SFOサーバを使用するパターン（sfo-tier） | 「9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト」
CTMを使用するパターン（ctm-tier） | 「9.6.3　CTMを使用するパターン（ctm-tier）のシステムのスケールアウト」

注　論理ユーザサーバを配置するシステムをスケールアウトする場合は，構成変更定義ファイルのサービスユニットの定義で，追加する論理ユーザサーバを定義してください。構成変更定義ファイルのサービスユニットの定義例は，「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」を参照してください。

なお，追加するアプリケーションサーバのセットアップに，JP1/SC/DPMのディスク複製OSインストール機能を利用することもできます。この機能を利用すると，すでに稼働しているホストの環境を複製して，新規に作成するホストに対してOSや必要なアプリケーションのインストール，および環境設定が一括で操作できます。JP1/SC/DPMを利用する場合の，システムのスケールアウトの手順については，「9.8　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン」を参照してください。

＜この節の構成＞

9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト

9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト

9.6.3　CTMを使用するパターン（ctm-tier）のシステムのスケールアウト

9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト

ここでは，システムをスケールアウトする手順について説明します。

システムをスケールアウトする前に，あらかじめ追加するアプリケーションサーバのOSやアプリケーションをセットアップしてください。システムをスケールアウトするには，次の内容を実施します。

構成変更定義ファイルの作成

システムの情報モデルの変更

サービスユニットの追加

システムのスケールアウトの手順について説明します。

ここでは，次に示すサービスユニットを追加する場合を例にして，説明しています。なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

ホスト名：apsv3

サービスユニット名：unit3

IPアドレス：192.168.1.13

管理IPアドレス：192.168.100.13

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。構成変更定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-13　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

＜この項の構成＞

(1)　構成変更定義ファイルの作成

(2)　システムの情報モデルの変更

(3)　サービスユニットの追加

(1)　構成変更定義ファイルの作成

サービスユニット・ホスト追加用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

構成変更定義ファイルを作成します。
サービスユニット・ホスト追加用の構成変更定義ファイル（cmxaddcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemAdd.xml」に変更しています。

コピーした構成変更定義ファイルを編集します。
MyWebSystemAdd.xmlファイルを編集します。ここでは，追加するサービスユニットの内容と，ホストの定義をします。
設定後のMyWebSystemAdd.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyWebSystem</name>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv3</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>

 </web-system>
 <!-- 追加するホストの定義 -->
 <host>
   <host-name>apsv3</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>

</unit-addition>

注　太字の部分が編集部分です。

参考

スケールアウトするサービスユニットに論理ユーザサーバを配置する場合は，サービスユニットの定義で論理ユーザサーバを定義してください。

論理ユーザサーバを配置するシステムのスケールアウトで使用する構成変更定義ファイルの例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyWebSystem</name>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv3</host-ref>
       <hosts-for>combined-tier</hosts-for>
       <define-server>
         <logical-server-name>UserServer4</logical-server-name>
         <logical-server-type>user-server</logical-server-type>
         <configuration>
           <param>
             <!-- サーバ起動用コマンド -->
             <param-name>start.arg</param-name>
             <param-value>c:/test/start.exe</param-value>
           </param>
         </configuration>
       </define-server>
     </allocated-host>
   </unit>

 </web-system>
 <!-- 追加するホストの定義 -->
 <host>
   <host-name>apsv3</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>

</unit-addition>

この例では，サービスユニットunit3に，論理ユーザサーバUserServer4を配置しています。

(2)　システムの情報モデルの変更

作成した構成変更定義ファイルの内容を，Management Serverのシステムの情報モデルに反映します。

システムの情報モデルを変更します。
cmx_change_modelコマンドに，(1)で作成した構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemAdd.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemAdd.xml

(3)　サービスユニットの追加

変更したシステムの情報モデルを実システムに適用して，サービスユニットを追加します。

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，(2)で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

負荷分散機からのリクエストの振り分けを抑止した状態で，追加したサービスユニットを一括起動します。
ここでは次の内容を実施しています。

cmx_start_targetコマンドを使用して，追加したサービスユニット「unit3」を準備状態で起動することで，負荷分散機からのリクエストの振り分けを抑止します。準備状態にするには，-modeオプションに「READY」を指定します。インプロセスHTTPサーバを使用するパターンの場合，負荷分散機を利用できません。-modeオプションに「ALL」を指定して，稼働状態で起動してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit3

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit3

追加したサービスユニットのリソースアダプタをインポートして開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。

リソースアダプタをインポートします。

J2EEサーバにリソースアダプタをデプロイします。

Connector属性ファイルをリソースアダプタに反映します。

リソースアダプタの接続を確認します。

リソースアダプタを開始します。

次に示すリソースアダプタをインポートして開始する手順を例にして説明します。

表9-14　例で使用するリソースアダプタのファイル名と表示名

種別 | 名前
ファイル名 | DBConnector_HiRDB_Type4_CP.rar
表示名 | DB_Connector_for_HiRDB_Type4
Connector属性ファイルのファイル名 | MyDBConnectorAttr.xml

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml※

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

# /opt/Cosminexus/CC/admin/bin/cjdeployrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml※

# /opt/Cosminexus/CC/admin/bin/cjtestres cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

注※　スケールアウトの対象とするサービスユニットのリソースアダプタに反映したConnector属性ファイルを使用します。Connector属性ファイルを保管していない場合は，スケールアウトの対象とするサービスユニットにデプロイしたリソースアダプタからサーバ管理コマンド（cjgetrarprop）を使用して取得します。取得したConnector属性ファイルは必要に応じて編集します。

J2EEアプリケーションをインポートして開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。

J2EEアプリケーションをJ2EEサーバへインポートします。

J2EEアプリケーションを開始します。

次に示すJ2EEアプリケーションをインポートして開始する手順を例にして説明します。J2EEアプリケーションは，cosminexus.xmlを含むアプリケーションであることを前提としています。

表9-15　例で使用するJ2EEアプリケーションのファイル名と表示名

種別 | 名前
ファイル名 | MyApp.ear
表示名 | MyApp

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -f MyApp.ear

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -f MyApp.ear

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

参考

cosminexus.xmlを含まないアプリケーションの場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

この場合，スケールアウトの対象とするサービスユニットのJ2EEアプリケーションに反映したアプリケーション統合属性ファイルを使用します。

アプリケーション統合属性ファイルを保管していない場合は，スケールアウトの対象とするサービスユニットにインポートしたJ2EEアプリケーションからサーバ管理コマンド（cjgetappprop）を使用して取得します。取得したアプリケーション統合属性ファイルは必要に応じて編集します。

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

追加したサービスユニットを起動します。
cmx_start_targetコマンドを使用して，追加したサービスユニット「unit3」を一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。インプロセスHTTPサーバを使用するパターンの場合，この操作は不要です。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト

SFOサーバを使用するパターン（sfo-tier）のシステムをスケールアウトする手順について説明します。

システムをスケールアウトする前に，あらかじめ追加するアプリケーションサーバのOSやアプリケーションをセットアップしてください。システムをスケールアウトするには，次の内容を実施します。

構成変更定義ファイルの作成

システムの情報モデルの変更

サービスユニットの追加

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

システムのスケールアウトの手順について説明します。

なお，ここでは，次に示すメモリセッションフェイルオーバ用のサービスユニットを追加する場合を例にして，説明しています。説明では，SFOサーバを使用するパターン（sfo-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

ホスト名：sfosv3

サービスユニット名：unit5

IPアドレス：192.168.1.15

管理IPアドレス：192.168.100.15

業務サービス用のサービスユニットを追加する場合の手順については，「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。構成変更定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-16　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。サービスユニット2に対しても，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

J2EEサーバ名：cmx_MyWebSystem_unit2_J2EE_01

-nameserver指定値：corbaname::192.168.1.12:900

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

＜この項の構成＞

(1)　構成変更定義ファイルの作成

(2)　システムの情報モデルの変更

(3)　サービスユニットの追加

(4)　J2EEアプリケーションのインポートと開始

(1)　構成変更定義ファイルの作成

メモリセッションフェイルオーバ用のサービスユニットを追加する場合，次の構成変更定義ファイルが必要になります。

サービスユニット・ホスト追加用の構成変更定義ファイル
追加するメモリセッションフェイルオーバ用のサービスユニットを定義します。

論理サーバのパラメタ変更用の構成変更定義ファイル
J2EEサーバで使用するセッションフェイルオーバ用フィルタを定義して，追加するSFOサーバとJ2EEサーバを関連づけます。

サービスユニット・ホスト追加用，および論理サーバのパラメタ変更用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

サービスユニット・ホスト追加用の構成変更定義ファイルを作成します。
サービスユニット・ホスト追加用の構成変更定義ファイル（cmxaddcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemAddSfo.xml」に変更しています。

コピーしたサービスユニット・ホスト追加用の構成変更定義ファイルを編集します。
MyWebSystemAddSfo.xmlファイルを編集します。ここでは，追加するサービスユニットの内容と，ホストの定義をします。
設定後のMyWebSystemAddSfo.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyWebSystem</name>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit5</name>
     <allocated-host>
       <host-ref>sfosv3</host-ref>
       <hosts-for>sfo-tier</hosts-for>
       <define-server>
         <logical-server-name>sfo03</logical-server-name>
         <logical-server-type>sfo-server</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>

 </web-system>
 <!-- 追加するホストの定義 -->
 <host>
   <host-name>sfosv3</host-name>
   <agent-host>192.168.100.15</agent-host>
 </host>

</unit-addition>

注　太字の部分が編集部分です。

論理サーバのパラメタ変更用の構成変更定義ファイルを作成します。
論理サーバのパラメタ変更用の構成変更定義ファイル（cmxmodcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemMod4.xml」に変更しています。

コピーした論理サーバのパラメタ変更用の構成変更定義ファイルを編集します。
MyWebSystemMod4.xmlファイルを編集します。ここでは，J2EEサーバで使用するセッションフェイルオーバ用フィルタの追加を定義します。
設定後のMyWebSystemMod4.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<model-modification xmlns="http://www.cosminexus.com/mngsvr/schema/ModelModification-2.5">
 <web-system>
 <name>MyWebSystem</name>
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- 追加するセッションフェイルオーバ用フィルタの定義 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>webserver.sfo.sfo_servers</param-name>
         <param-value>sfoserver1,sfoserver2,sfoserver3</param-value>
       </param>
       <param>
         <param-name>webserver.sfo.sfo_server.sfoserver3.serverName</param-name>
         <param-value>sfo03</param-value>
       </param>
     </configuration>
   </tier>
 </web-system>
</model-modification>

注　太字の部分が編集部分です。

(2)　システムの情報モデルの変更

作成した構成変更定義ファイルの内容を，Management Serverのシステムの情報モデルに反映します。メモリセッションフェイルオーバ用のサービスユニットを追加する場合，(1)で作成した2種類の構成変更定義ファイルごとに，システムの情報モデルに反映する必要があります。

サービスユニット・ホスト追加用の構成変更定義ファイルを指定して，システムの情報モデルを変更します。
cmx_change_modelコマンドに，(1)で作成したサービスユニット・ホスト追加用の構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemAddSfo.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemAddSfo.xml

論理サーバのパラメタ変更用の構成変更定義ファイルを指定して，システムの情報モデルを変更します。
cmx_change_modelコマンドに，(1)で作成した論理サーバのパラメタ変更用の構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemMod4.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemMod4.xml

(3)　サービスユニットの追加

変更したシステムの情報モデルを実システムに適用して，サービスユニットを追加します。

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，(2)で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

追加したメモリセッションフェイルオーバ用のサービスユニットを一括起動します。
ここでは次の内容を実施しています。

cmx_start_targetコマンドを使用して，追加したサービスユニット「unit5」を稼働状態で起動します。-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit5

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit5

業務サービス用のサービスユニットを停止して，起動します。システム内のすべての業務サービス用のサービスユニットに対して実施します。
ここでは次の内容を実施しています。

cmx_stop_targetコマンドを使用して，業務サービス用のサービスユニット「unit1」および「unit2」を停止状態にします。停止状態にするには，-modeオプションに「ALL」を指定します。

cmx_start_targetコマンドを使用して，業務サービス用のサービスユニット「unit1」および「unit2」を稼働状態にします。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

(4)　J2EEアプリケーションのインポートと開始

追加したメモリセッションフェイルオーバ用のサービスユニットを利用するJ2EEアプリケーションのインポートと開始をします。

次に示すJ2EEアプリケーションをインポートして開始する手順を例にして説明します。J2EEアプリケーションは，cosminexus.xmlを含むアプリケーションであることを前提としています。

表9-17　例で使用するJ2EEアプリケーションのファイル名と表示名

種別 | 名前
ファイル名 | MyApp2.ear
表示名 | MyApp2

追加したメモリセッションフェイルオーバ用のサービスユニットを利用するJ2EEアプリケーションをインポートして開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。

J2EEアプリケーションをJ2EEサーバへインポートします。

J2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp2.ear

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp2

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -f MyApp2.ear

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp2

参考

次に示す場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

インポート済みのJ2EEアプリケーションのプロパティを編集する場合

cosminexus.xmlを含まないアプリケーションの場合

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

9.6.3　CTMを使用するパターン（ctm-tier）のシステムのスケールアウト

CTMを使用したシステムをスケールアウトする手順について説明します。

システムをスケールアウトする前に，あらかじめ追加するアプリケーションサーバのOSやアプリケーションをセットアップしてください。システムをスケールアウトするには，次の内容を実施します。

構成変更定義ファイルの作成

システムの情報モデルの変更

サービスユニットの追加

システムのスケールアウトの手順について説明します。

なお，ここでは，CTM用のWebシステム（MyBackSystem）に，次に示すサービスユニットを追加する場合を例にして，説明しています。説明では，CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

ホスト名：ctmsv3

サービスユニット名：unit5

IPアドレス：192.168.1.35

管理IPアドレス：192.168.100.35

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。構成変更定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-18　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

＜この項の構成＞

(1)　構成変更定義ファイルの作成

(2)　システムの情報モデルの変更

(3)　サービスユニットの追加

(1)　構成変更定義ファイルの作成

サービスユニット・ホスト追加用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

構成変更定義ファイルを作成します。
サービスユニット・ホスト追加用の構成変更定義ファイル（cmxaddcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyBackSystemAdd.xml」に変更しています。

コピーした構成変更定義ファイルを編集します。
MyBackSystemAdd.xmlファイルを編集します。ここでは，追加するサービスユニットの内容と，ホストの定義をします。
設定後のMyBackSystemAdd.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyBackSystem</name>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit5</name>
     <allocated-host>
       <host-ref>ctmsv3</host-ref>
       <hosts-for>ctm-tier</hosts-for>
     </allocated-host>
   </unit>

 </web-system>
   <!-- 追加するホストの定義 -->
   <host>
     <host-name>ctmsv3</host-name>
     <agent-host>192.168.100.35</agent-host>
   </host>

</unit-addition>

注　太字の部分が編集部分です。

(2)　システムの情報モデルの変更

作成した構成変更定義ファイルの内容を，Management Serverのシステムの情報モデルに反映します。

システムの情報モデルを変更します。
cmx_change_modelコマンドに，(1)で作成した構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyBackSystemAdd.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyBackSystemAdd.xml

(3)　サービスユニットの追加

変更したシステムの情報モデルを実システムに適用して，サービスユニットを追加します。

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，(2)で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyBackSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyBackSystem

追加したサービスユニットを一括起動します。
ここでは次の内容を実施しています。

cmx_start_targetコマンドを使用して，追加したサービスユニット「unit5」を稼働状態で起動します。-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyBackSystem -unit unit5

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyBackSystem -unit unit5

追加したサービスユニットのリソースアダプタをインポートして開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。

リソースアダプタをインポートします。

J2EEサーバにリソースアダプタをデプロイします。

Connector属性ファイルをリソースアダプタに反映します。

リソースアダプタの接続を確認します。

リソースアダプタを開始します。

次に示すリソースアダプタをインポートして開始する手順を例にして説明します。

表9-19　例で使用するリソースアダプタのファイル名と表示名

種別 | 名前
ファイル名 | DBConnector_HiRDB_Type4_CP.rar
表示名 | DB_Connector_for_HiRDB_Type4
Connector属性ファイルのファイル名 | MyDBConnectorAttr.xml

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml※

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -type rar -f /opt/Cosminexus/CC/DBConnector/DBConnector_HiRDB_Type4_CP.rar

# /opt/Cosminexus/CC/admin/bin/cjdeployrar cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml※

# /opt/Cosminexus/CC/admin/bin/cjtestres cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900  -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -resname DB_Connector_for_HiRDB_Type4

注※　スケールアウトの対象とするサービスユニットのリソースアダプタに反映したConnector属性ファイルを使用します。Connector属性ファイルを保管していない場合は，スケールアウトの対象とするサービスユニットにデプロイしたリソースアダプタからサーバ管理コマンド（cjgetrarprop）を使用して取得します。取得したConnector属性ファイルは必要に応じて編集します。

J2EEアプリケーションをインポートして開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。

J2EEアプリケーションをJ2EEサーバへインポートします。

J2EEアプリケーションを開始します。

次に示すJ2EEアプリケーションをインポートして開始する手順を例にして説明します。J2EEアプリケーションは，cosminexus.xmlを含むアプリケーションであることを前提としています。

表9-20　例で使用するJ2EEアプリケーションのファイル名と表示名

種別 | 名前
ファイル名 | MyApp.ear
表示名 | MyApp

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -f MyApp.ear

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -name MyApp

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -f MyApp.ear

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.35:900 -name MyApp

参考

cosminexus.xmlを含まないアプリケーションの場合，J2EEアプリケーションのプロパティは，属性ファイル（アプリケーション統合属性ファイル）で設定できます。

この場合，スケールアウトの対象とするサービスユニットのJ2EEアプリケーションに反映したアプリケーション統合属性ファイルを使用します。

アプリケーション統合属性ファイルを保管していない場合は，スケールアウトの対象とするサービスユニットにインポートしたJ2EEアプリケーションからサーバ管理コマンド（cjgetappprop）を使用して取得します。取得したアプリケーション統合属性ファイルは必要に応じて編集します。

設定方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.2　アプリケーション統合属性ファイルによるプロパティ設定」を参照してください。

9.7　システムのスケールイン

Smart Composer機能を使用すると，業務全体を停止することなく，システムの構成を変更できます。システムの規模を縮小する場合は，システムをスケールインします。

構成定義パターンと，システムのスケールイン手順の参照先を次の表に示します。なお，構成定義パターンについては，「5.1　J2EEアプリケーションを実行するシステムでの構成定義パターンの選定」を参照してください。

表9-21　構成定義パターンとシステムのスケールイン手順の参照先

構成定義パターン | システムのスケールイン手順の参照先
WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier） | 「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」
WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ） | 「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」
インプロセスHTTPサーバを使用するパターン（j2ee-tier） | 「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」
SFOサーバを使用するパターン（sfo-tier） | 「9.7.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールイン」
CTMを使用するパターン（ctm-tier） | 「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」

＜この節の構成＞

9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン

9.7.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールイン

9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン

「9.6.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト」で追加したサービスユニットを削除する場合を例にして，説明しています。このため，削除するサービスユニット名は「unit3」となります。

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

サービスユニットを削除します。
削除するサービスユニットを停止して，システムの情報モデルから削除します。なお，削除するサービスユニットは実行中のリクエストの処理を完了してから停止します。
ここでは次の内容を実施しています。

cmx_stop_targetコマンドを使用して，削除するサービスユニット「unit3」を一括停止します。このとき，コマンドの-modeオプションで「ALL」を指定して，停止状態にします。

cmx_delete_systemコマンドを使用して，サービスユニット「unit3」を削除します。なお，このコマンドを実行すると，Management Serverに登録されたシステムの情報モデルと負荷分散機に設定した情報は削除されます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit3

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit3

cmx_delete_systemコマンドについて

J2EEサーバやWebサーバの環境削除などのアンセットアップを実行しません。cmx_delete_systemコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_delete_system（Webシステムの削除）」を参照してください。

参考

Webシステムを削除して，Webシステム単位でもスケールインできます。この場合は，cmx_stop_targetコマンドおよびcmx_delete_systemコマンドで，削除対象のWebシステムを指定します。各コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cmx_delete_system（Webシステムの削除）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

9.7.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールイン

メモリセッションフェイルオーバ機能を使用したシステムをスケールインする手順について説明します。システムをスケールインするには，次の内容を実施します。

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

構成変更定義ファイルの作成

システムの情報モデルの変更

サービスユニットの削除

システムのスケールインの手順について説明します。

なお，ここでは，「9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト」で追加した，メモリセッションフェイルオーバ用のサービスユニットを削除する場合を例にして，説明しています。このため，削除するサービスユニット名は「unit5」となります。業務サービス用のサービスユニットを削除する場合の手順については，「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。構成変更定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-22　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

＜この項の構成＞

(1)　J2EEアプリケーションのアンデプロイ

(2)　構成変更定義ファイルの作成

(3)　システムの情報モデルの変更

(4)　サービスユニットの削除

(1)　J2EEアプリケーションのアンデプロイ

削除するメモリセッションフェイルオーバ用のサービスユニットを利用しているJ2EEアプリケーションを，システムからアンデプロイします。ここでは，「9.6.2　SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト」でデプロイしたJ2EEアプリケーションをアンデプロイする場合を例にして，説明しています。このため，アンデプロイするJ2EEアプリケーションのファイル名は「MyApp2.ear」，表示名は「MyApp2」となります。

削除するメモリセッションフェイルオーバ用のサービスユニットを利用しているJ2EEアプリケーションを停止し，アンデプロイします。

ここでは次の内容を実施しています。

サーバ管理コマンドを使用して，J2EEアプリケーションが稼働している場合は停止します（必要に応じて）。

サーバ管理コマンドを使用して，J2EEアプリケーションを削除します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.15:900 -name MyApp2

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeleteapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.15:900 -name MyApp2

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstopapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.15:900 -name MyApp2

# /opt/Cosminexus/CC/admin/bin/cjdeleteapp cmx_MyWebSystem_unit5_J2EE_01 -nameserver corbaname::192.168.1.15:900 -name MyApp2

(2)　構成変更定義ファイルの作成

論理サーバのパラメタ変更用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

論理サーバのパラメタ変更用の構成変更定義ファイルを作成します。
論理サーバのパラメタ変更用の構成変更定義ファイル（cmxmodcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemMod5.xml」に変更しています。

コピーした論理サーバのパラメタ変更用の構成変更定義ファイルを編集します。
MyWebSystemMod5.xmlファイルを編集します。ここでは，J2EEサーバから削除するセッションフェイルオーバ用フィルタの定義をします。
設定後のMyWebSystemMod5.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<model-modification xmlns="http://www.cosminexus.com/mngsvr/schema/ModelModification-2.1">
 <web-system>
 <name>MyWebSystem</name>
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- 削除するセッションフェイルオーバ用フィルタの定義 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>webserver.sfo.sfo_servers</param-name>
         <param-value>sfoserver1,sfoserver2</param-value>
       </param>
       <param>
         <param-name>webserver.sfo.sfo_server.sfoserver3.serverName</param-name>
       </param>
     </configuration>
   </tier>
 </web-system>
</model-modification>

注　太字の部分が編集部分です。

(3)　システムの情報モデルの変更

作成した構成変更定義ファイルの内容を，Management Serverのシステムの情報モデルに反映します。

システムの情報モデルを変更します。
cmx_change_modelコマンドに，(2)で作成した論理サーバのパラメタ変更用の構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MMyWebSystemMod5.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemMod5.xml

変更したシステムの情報モデルを実システムに適用します。
cmx_build_systemコマンドを使用して，変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

(4)　サービスユニットの削除

メモリセッションフェイルオーバ用のサービスユニットを，システムから削除します。

業務サービス用のサービスユニットを停止して，起動します。Webシステム内のすべての業務サービス用のサービスユニットに対して実施します。
ここでは次の内容を実施しています。

cmx_stop_targetコマンドを使用して，業務サービス用のサービスユニット「unit1」および「unit2」を停止状態にします。停止状態にするには，-modeオプションに「ALL」を指定します。

cmx_start_targetコマンドを使用して，業務サービス用のサービスユニット「unit1」および「unit2」を稼働状態にします。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

<Cosminexusインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

<Cosminexusインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

<Cosminexusインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit2

メモリセッションフェイルオーバ用のサービスユニットを停止します。
cmx_stop_targetコマンドを使用して，サービスユニット「unit5」を停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit5

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit5

メモリセッションフェイルオーバ用のサービスユニットを削除します。
cmx_delete_systemコマンドを使用して，サービスユニット「unit5」を削除します。なお，このコマンドを実行すると，Management Serverに登録されたシステムの情報モデルに設定した情報は削除されます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit5

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit5

9.8　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

Smart Composer機能を使用してシステムをスケールアウトする場合に，追加するアプリケーションサーバのセットアップにJP1/SC/DPMのディスク複製OSインストール機能を利用できます。この場合，通常のシステムのスケールアウトの手順の前に，複製元のディスクイメージを作成する準備が必要です。JP1/SC/DPMを利用すると，運用管理サーバモデルおよびホスト単位管理モデルでシステムを構築できます。

ここでは，JP1/SC/DPMを利用してシステムをスケールアウトする手順を，モデルごとに説明します。また，JP1/SC/DPMを利用して構築したシステムをスケールインする手順を説明します。

注意

SFOサーバを使用するパターン（sfo-tier）のシステムの場合，セッションフェイルオーバサーバマシンでは，JP1/SC/DPMと連携したスケールアウトを利用できません。

＜この節の構成＞

9.8.1　運用管理サーバモデルでのシステムのスケールアウト

9.8.2　ホスト単位管理モデルでのシステムのスケールアウト

9.8.3　JP1/SC/DPMを利用して構築したシステムのスケールイン

9.8.1　運用管理サーバモデルでのシステムのスケールアウト

ここでは，運用管理サーバモデルでの，システムのスケールアウトの準備およびスケールアウトで実施する内容について説明します。

スケールアウトの準備

システムのスケールアウトの準備とは，複製元のディスクイメージを作成する作業です。システム構築が終わって，運用環境が整ったところで実施します。スケールアウトの準備では次の内容を実施します。

複製元アプリケーションサーバでの準備

スケールアウト用ディスクイメージの作成

スケールアウト

複製したディスクイメージを使用して，スケールアウトをします。スケールアウトでは，次の内容を実施します。

ディスクイメージのリストア

構成変更定義ファイルの作成

システムの情報モデルの変更（サービスユニットの追加）

注意

JP1/AJS2 - SOを使用してシステムのスケールアウトを自動化する場合

JP1/SC/DPMを使用したシステムのスケールアウトを，JP1/AJS2 - SOを使用して自動化する場合，ディスク複製インストール（リストア）が完了してから運用管理エージェントを自動起動するように設定する必要があります。設定方法については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。また，JP1/AJS2 - SOとの連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「16.　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）」を参照してください。

なお，説明では，WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルを使用して，「8.6　システムの一括構築」で構築したシステムを使用します。

JP1/SC/DPMを利用したスケールアウトの例を次の図に示します。

図9-1　JP1/SC/DPMを利用したスケールアウトの例（運用管理サーバモデルの場合）

この図では，JP1/SC/DPMを使用して，サービスユニット1を構成する複製元アプリケーションサーバのディスクイメージを複製し，そのディスクイメージに従って，新たなアプリケーションサーバにOSやアプリケーションをインストールします。次に，Smart Composer機能のコマンドを使用して，サービスユニット3をシステムにスケールアウトします。この例で使用するサービスユニットの設定例を次の表に示します。

表9-23　サービスユニットの設定例（運用管理サーバモデルの場合）

設定項目 | 複製元のサービスユニット | 追加するサービスユニット
ホスト名 | apsv1 | apsv3
サービスユニット名 | unit1 | unit3
IPアドレス | 192.168.1.11 | 192.168.1.13
管理IPアドレス | 192.168.100.11 | 192.168.100.13

なお，Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-24　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

＜この項の構成＞

(1)　複製元アプリケーションサーバでの準備

(2)　JP1/SC/DPMを使用したスケールアウト用ディスクイメージの作成

(3)　JP1/SC/DPMを使用したディスクイメージのリストア

(4)　構成変更定義ファイルの作成

(5)　システムの情報モデルの変更（サービスユニットの追加）

(1)　複製元アプリケーションサーバでの準備

複製元アプリケーションサーバで，JP1/SC/DPMによるディスクイメージ作成のための準備をします。

リソースアダプタおよびJ2EEアプリケーションを一括停止します（必要に応じて）。
複製先アプリケーションサーバで，リソースアダプタおよびJ2EEアプリケーションを自動で開始する場合には，この操作は不要です。
ここでは，次の内容を実施します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のJ2EEアプリケーションを停止します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のリソースアダプタを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

Linuxの場合

# /opt/Cosminexus/CC/admin/bin/cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

# /opt/Cosminexus/CC/admin/bin/cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

サービスユニット，および運用管理エージェントを停止します。
ここでは，次の内容を実施します。

cmx_stop_targetコマンドを使用して，サービスユニット「unit1」を停止します。

adminagentctlコマンドを使用して，運用管理エージェントを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl stop

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

# /opt/Cosminexus/manager/bin/adminagentctl stop

運用管理エージェントのサービスを手動起動に設定します。
ここでは，次の内容を実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngautorun -d

Linuxの場合

# rm /etc/rc.d/rc2.d/S80AdminAgent

デフォルトのJ2EEサーバをアンセットアップします。
インストール時にホスト名で作成されているデフォルトのJ2EEサーバをアンセットアップします。
ここでは，次の内容を実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥bin¥cjsetup -d apsv1

Linuxの場合

# /opt/Cosminexus/CC/server/bin/cjsetup -d apsv1

ログを削除します。
ログファイルを削除します。削除対象ログファイルが格納されているディレクトリについては，「付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル」を参照してください。

注意

JP1/SC/DPMを使用してスケールアウトする場合，複製先アプリケーションサーバマシンが複数のIPアドレスで構成されているときは，adminagent.properties（運用管理エージェントプロパティファイル）のadminagent.adapter.bind_hostキーに設定するIPアドレスを正規表現で指定する必要があります。これは，スケールアウトするマシンはIPアドレスが変わり，固定のIPアドレスが指定できないためです。なお，adminagent.properties（運用管理エージェントプロパティファイル）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.2　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

(2)　JP1/SC/DPMを使用したスケールアウト用ディスクイメージの作成

JP1/SC/DPMを使用して複製元アプリケーションサーバからディスクイメージを作成します。なお，複製元アプリケーションサーバは，ディスクイメージの作成後，業務を再開します。

スケールアウト用ディスクイメージを作成します。
複製元アプリケーションサーバから，スケールアウト用のディスクイメージを作成します。なお，詳細については，マニュアル「JP1/ServerConductor/Deployment Manager」のディスク複製OSインストール機能の説明を参照してください。

運用管理エージェントを開始します。
adminagentctlコマンドを使用して，運用管理エージェントを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

Linuxの場合

# /opt/Cosminexus/manager/bin/adminagentctl start

なお，必要に応じて，運用管理エージェントの自動起動を再設定してください。設定方法については，「7.7.1(2)　運用管理エージェントの自動起動の設定」を参照してください。

リソースアダプタおよびJ2EEアプリケーションを開始します（必要に応じて）。
リソースアダプタおよびJ2EEアプリケーションを自動で開始する場合，この操作は不要です。
ここでは，次の内容を実施します。

cmx_start_targetコマンドを使用して，サービスユニット「unit1」を準備状態で起動します。準備状態にするには，-modeオプションに「READY」を指定します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のリソースアダプタを開始します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のJ2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit1

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit1

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

サービスユニットを開始します。
cmx_start_targetコマンドを使用して，サービスユニット「unit1」を稼働状態で起動します。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

(3)　JP1/SC/DPMを使用したディスクイメージのリストア

作成したディスクイメージを，サービスユニットを追加するアプリケーションサーバにリストアします。なお，リストアの操作手順については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。

また，追加したアプリケーションサーバの運用管理エージェントを起動する場合は，ここで実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

Linuxの場合

# /opt/Cosminexus/manager/bin/adminagentctl start

なお，運用管理エージェントの自動起動の設定については，「7.7.1(2)　運用管理エージェントの自動起動の設定」を参照してください。

(4)　構成変更定義ファイルの作成

サービスユニット・ホスト追加用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

構成変更定義ファイルを作成します。
サービスユニット・ホスト追加用の構成変更定義ファイル（cmxaddcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

Linuxの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemAdd.xml」に変更しています。

コピーした構成変更定義ファイルを編集します。
MyWebSystemAdd.xmlファイルを編集します。ここでは，追加するサービスユニットの内容と，ホストの定義をします。また，<addition-mode>タグを追加し，「DEPLOYED」を指定してください。
設定後のMyWebSystemAdd.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyWebSystem</name>
   <addition-mode>DEPLOYED</addition-mode>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv3</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>

 </web-system>
 <!-- 追加するホストの定義 -->
 <host>
   <host-name>apsv3</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>

</unit-addition>

注　太字の部分が編集部分です。

(5)　システムの情報モデルの変更（サービスユニットの追加）

作成した構成変更定義ファイルの内容を，Management Serverのシステムの情報モデルに反映します。変更したシステムの情報モデルを実システムに適用して，サービスユニットを追加します。

システムの情報モデルを変更します。
cmx_change_modelコマンドに，(4)で作成した構成変更定義ファイルを指定して，Management Serverのシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemAdd.xml

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemAdd.xml

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，(5)で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

負荷分散機からのリクエストの振り分けを抑止した状態で，追加したサービスユニットを一括起動します。
ここでは次の内容を実施しています。

cmx_start_targetコマンドを使用して，追加したサービスユニット「unit3」を準備状態で起動することで，負荷分散機からのリクエストの振り分けを抑止します。準備状態にするには，-modeオプションに「READY」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit3

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem -unit unit3

リソースアダプタおよびJ2EEアプリケーションを開始します（必要に応じて）。
リソースアダプタおよびJ2EEアプリケーションが自動で開始しない場合は，最初に，リソースアダプタおよびJ2EEアプリケーションを一括開始します。JP1/SC/DPMを使用してディスクイメージを作成するときに，複製元アプリケーションサーバでリソースアダプタおよびJ2EEアプリケーションを一括停止しなかった場合，この操作は必要ありません。
ここでは次の内容を実施しています。

サーバ管理コマンドを使用して，サービスユニット「unit3」のリソースアダプタを開始します。

サーバ管理コマンドを使用して，サービスユニット「unit3」のJ2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

Linuxの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit3_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

追加したサービスユニットを一括起動します。
cmx_start_targetコマンドを使用して，追加したサービスユニット「unit3」を一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

9.8.2　ホスト単位管理モデルでのシステムのスケールアウト

ここでは，ホスト単位管理モデルでの，システムのスケールアウトの準備およびスケールアウトで実施する内容について説明します。

スケールアウトの準備

システムのスケールアウトの準備とは，複製元のディスクイメージを作成する作業です。システム構築が終わって，運用環境が整ったところで実施します。スケールアウトの準備では次の内容を実施します。

複製元アプリケーションサーバでの準備

スケールアウト用ディスクイメージの作成

スケールアウト

複製したディスクイメージを使用して，スケールアウトをします。スケールアウトでは，次の内容を実施します。

ディスクイメージのリストア

スケールアウト用ホスト定義ファイルの作成

システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

注意

JP1/AJS2 - SOを使用してシステムのスケールアウトを自動化する場合

JP1/SC/DPMを使用したシステムのスケールアウトを，JP1/AJS2 - SOを使用して自動化する場合，ディスク複製インストール（リストア）が完了してから運用管理エージェントを自動起動するように設定する必要があります。設定方法については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。また，JP1/AJS2 - SOとの連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「16.　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）」を参照してください。

ここで使用するJP1/SC/DPMを利用したスケールアウトの例を次の図に示します。

図9-2　JP1/SC/DPMを利用したスケールアウトの例（ホスト単位管理モデルの場合）

この図では，JP1/SC/DPMを使用して，アプリケーションサーバ1のディスクイメージを複製し，そのディスクイメージに従って，新たなアプリケーションサーバにOSやアプリケーションをインストールします。次に，Smart Composer機能のコマンドを使用して，複製先アプリケーションサーバの情報をシステムにスケールアウトします。この例で使用するアプリケーションサーバの設定例を次の表に示します。

表9-25　各アプリケーションサーバの設定例（ホスト単位管理モデルの場合）

設定項目 | 複製元アプリケーションサーバ | 複製先アプリケーションサーバ
Webシステム | Webシステム名 | MyWebSystem1 | MyWebSystem1※
サービスユニット | サービスユニット名 | unit1 | unit1※1
ホスト名 | apsv1 | apsv1※1
ホスト | ホスト名 | apsv1 | apsv1※1
IPアドレス | 192.168.1.11 | 192.168.1.13
管理IPアドレス | 192.168.100.11 | 192.168.100.13

注※

アプリケーションサーバ（運用管理ドメイン）ごと複製するため，複製先アプリケーションサーバのWebシステム，サービスユニット，ホストの名称は，複製元と同じになります。

なお，Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイル作成時に実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。論理サーバの種類と<種別>との対応を次の表に示します。

表9-26　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理Webサーバ | HTTP
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理SFOサーバ | SFO
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

＜この項の構成＞

(1)　複製元アプリケーションサーバでの準備

(2)　JP1/SC/DPMを使用したスケールアウト用ディスクイメージの作成

(3)　JP1/SC/DPMを使用したディスクイメージのリストア

(4)　スケールアウト用ホスト定義ファイルの作成

(5)　システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

(1)　複製元アプリケーションサーバでの準備

複製元アプリケーションサーバで，JP1/SC/DPMによるディスクイメージ作成のための準備をします。

リソースアダプタおよびJ2EEアプリケーションを停止します（必要に応じて）。
複製先アプリケーションサーバで，リソースアダプタおよびJ2EEアプリケーションを自動で開始する場合には，この操作は不要です。
ここでは，次の内容を実施します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のJ2EEアプリケーションを停止します。

サーバ管理コマンドを使用して，サービスユニット「unit1」のリソースアダプタを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

Linuxの場合

# /opt/Cosminexus/CC/admin/bin/cjstopapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

# /opt/Cosminexus/CC/admin/bin/cjstoprar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

サービスユニット，運用管理エージェント，およびManagement Serverを停止します。
ここでは，次の内容を実施します。

cmx_stop_targetコマンドを使用して，サービスユニット「unit1」を停止します。

adminagentctlコマンドを使用して，運用管理エージェントを停止します。

mngsvrctlコマンドを使用して，Management Serverを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl stop

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl stop

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

# /opt/Cosminexus/manager/bin/adminagentctl stop

# /opt/Cosminexus/manager/bin/mngsvrctl stop

運用管理エージェント，およびManagement Serverのサービスを手動起動に設定します。
ここでは，次の内容を実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngautorun -d

Linuxの場合

# rm /etc/rc.d/rc2.d/S80AdminAgent
# rm /etc/rc.d/rc2.d/S90MngSvr

デフォルトのJ2EEサーバをアンセットアップします。
インストール時にホスト名で作成されているデフォルトのJ2EEサーバをアンセットアップします。
ここでは，次の内容を実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥bin¥cjsetup -d apsv1

Linuxの場合

# /opt/Cosminexus/CC/server/bin/cjsetup -d apsv1

ログを削除します。
ログファイルを削除します。削除対象ログファイルが格納されているディレクトリについては，「付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル」を参照してください。

次のファイルを編集します。
編集対象のファイルおよびキーと，指定値を次の表に示します。

表9-27　編集対象のファイルおよびキーと，指定値

ファイル名称
キー名称
指定値

.cmxrc（クライアント設定プロパティファイル）
cmx.lb
keepvs

cmxclient.properties（クライアント共通設定プロパティファイル）
cmx.lb
keepvs

adminagent.properties（運用管理エージェントプロパティファイル）
adminagent.adapter.allowedHosts※
mserver.properties（Management Server環境設定ファイル）のmngsvr.myhost.nameキーを指定しているかどうかで指定値が異なります。

mngsvr.myhost.nameキーを指定している場合

mserver.properties（Management Server環境設定ファイル）のmngsvr.myhost.nameキーと同じ値を指定します。

mngsvr.myhost.nameキーを指定していない場合

複製元アプリケーションサーバマシンおよび複製先アプリケーションサーバマシンの管理IPアドレスの，両方にマッチする正規表現を指定します。

注※　adminagentcheckコマンドは，このキーで指定したIPアドレスのアプリケーションサーバマシン以外では実行できません。adminagentcheckコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「adminagentcheck（運用管理エージェントの稼働確認）」を参照してください。

また，次の表に示すキーに，ループバックアドレス以外を指定している場合は，複製元アプリケーションサーバマシンおよび複製先アプリケーションサーバマシンで，共通して使用できる管理IPアドレスとマッチする正規表現に変更してください。ループバックアドレス以外を指定している場合に，IPアドレスを正規表現に変更するキーを次の表に示します。

表9-28　ループバックアドレス以外を指定している場合に，IPアドレスを正規表現に変更するキー

ファイル名称 | キー名称
.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル） | mngsvrutil.connect.host
mngsvrutil.target_name
mngsvrutilcl.properties（mngsvrutilコマンドのクライアント側共通定義ファイル） | mngsvrutil.connect.host
mngsvrutil.target_name
.cmxrc（クライアント設定プロパティファイル） | cmx.connect.host
cmxclient.properties（クライアント共通設定プロパティファイル） | cmx.connect.host

各ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の次の個所を参照してください。

4.3　.cmxrc（クライアント設定プロパティファイル）

4.4　cmxclient.properties（クライアント共通設定プロパティファイル）

10.2　adminagent.properties（運用管理エージェントプロパティファイル）

10.15　.mngsvrutilrc（mngsvrutilコマンドのクライアント側定義ファイル）

10.17　mngsvrutilcl.properties（mngsvrutilコマンドのクライアント側共通定義ファイル）

注意

JP1/SC/DPMを使用してスケールアウトする場合，複製先アプリケーションサーバマシンが複数のIPアドレスで構成されているときは，次の表に示すキーに設定するIPアドレスを正規表現で指定する必要があります。これは，スケールアウトするマシンはIPアドレスが変わり，固定のIPアドレスが指定できないためです。

複数のIPアドレス構成時に，IPアドレスを正規表現で指定するキーを次の表に示します。

表9-29　複数のIPアドレス構成時に，IPアドレスを正規表現で指定するキー

ファイル名称 | キー名称
mserver.properties（Management Server環境設定ファイル） | mngsvr.myhost.name
webserver.connector.http.bind_host
adminagent.properties（運用管理エージェントプロパティファイル） | adminagent.adapter.bind_host

なお，mserver.properties（Management Server環境設定ファイル）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。adminagent.properties（運用管理エージェントプロパティファイル）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.2　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

(2)　JP1/SC/DPMを使用したスケールアウト用ディスクイメージの作成

JP1/SC/DPMを使用して複製元アプリケーションサーバからディスクイメージを作成します。なお，複製元アプリケーションサーバは，ディスクイメージの作成後，業務を再開します。

スケールアウト用ディスクイメージを作成します。
複製元アプリケーションサーバから，スケールアウト用のディスクイメージを作成します。なお，詳細については，マニュアル「JP1/ServerConductor/Deployment Manager」のディスク複製OSインストール機能の説明を参照してください。

複製元アプリケーションサーバの運用管理エージェント，およびManagement Serverを開始します。
ここでは，次の内容を実施します。

adminagentctlコマンドを使用して，複製元アプリケーションサーバの運用管理エージェントを開始します。

mngsvrctlコマンドを使用して，複製元アプリケーションサーバのManagement Serverを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl start

Linuxの場合

# /opt/Cosminexus/manager/bin/adminagentctl start

# /opt/Cosminexus/manager/bin/mngsvrctl start

なお，必要に応じて，運用管理エージェントおよびManagement Serverの自動起動を再設定してください。運用管理エージェントの設定方法については，「7.7.1(2)　運用管理エージェントの自動起動の設定」を，Management Serverの設定方法については，「7.7.2(2)　Management Serverの自動起動の設定」を参照してください。

複製元アプリケーションサーバのリソースアダプタおよびJ2EEアプリケーションを開始します（必要に応じて）。
リソースアダプタおよびJ2EEアプリケーションを自動で開始する場合，この操作は不要です。
ここでは，次の内容を実施します。

cmx_start_targetコマンドを使用して，複製元アプリケーションサーバのサービスユニット「unit1」を準備状態で起動します。準備状態にするには，-modeオプションに「READY」を指定します。

サーバ管理コマンドを使用して，複製元アプリケーションサーバのサービスユニット「unit1」のリソースアダプタを開始します。

サーバ管理コマンドを使用して，複製元アプリケーションサーバのサービスユニット「unit1」のJ2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem1 -unit unit1

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem1 -unit unit1

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.11:900 -name MyApp

複製元アプリケーションサーバのサービスユニットを開始します。
cmx_start_targetコマンドを使用して，複製元アプリケーションサーバのサービスユニット「unit1」を稼働状態で起動します。稼働状態にするには，-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

(3)　JP1/SC/DPMを使用したディスクイメージのリストア

作成したディスクイメージを，複製先アプリケーションサーバにリストアします。なお，リストアの操作手順については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。

また，複製先アプリケーションサーバの運用管理エージェント，およびManagement Serverを起動する場合は，ここで実施します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥adminagentctl start

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl start

Linuxの場合

# /opt/Cosminexus/manager/bin/adminagentctl start

# /opt/Cosminexus/manager/bin/mngsvrctl start

なお，必要に応じて，運用管理エージェントおよびManagement Serverの自動起動を再設定してください。運用管理エージェントの自動起動の設定については，「7.7.1(2)　運用管理エージェントの自動起動の設定」を，Management Serverの自動起動の設定については，「7.7.2(2)　Management Serverの自動起動の設定」を参照してください。

(4)　スケールアウト用ホスト定義ファイルの作成

スケールアウト用ホスト定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

スケールアウト用ホスト定義ファイルを作成します。
スケールアウト用ホスト定義ファイル（cmxscaleouthostdef.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

Linuxの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemHostScaleout.xml」に変更しています。

コピーしたスケールアウト用ホスト定義ファイルを編集します。
MyWebSystemHostScaleout.xmlファイルを編集します。ここでは，複製先アプリケーションサーバのWebシステムの内容と，ホストの定義をします。
設定後のMyWebSystemHostScaleout.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<host-scaleout xmlns="http://www.cosminexus.com/mngsvr/schema/HostScaleOut-2.5">
 <!-- 複製先のWebシステムの定義 -->
 <web-system>
   <name>MyWebSystem1</name>
 </web-system>
 <!-- 複製先のホストの定義 -->
 <host>
   <host-name>192.168.1.13</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>
</host-scaleout>

注　太字の部分が編集部分です。

(5)　システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

作成したスケールアウト用ホスト定義ファイルの内容を，複製先アプリケーションサーバのManagement Serverの，システムの情報モデルに反映します。また，変更したシステムの情報モデルを実システムに適用して，複製先アプリケーションサーバのホスト情報を変更します。

システムの情報モデルを変更します。
cmx_scaleout_hostコマンドに，(4)で作成したスケールアウト用ホスト定義ファイルを指定して，複製先アプリケーションサーバのManagement Serverの，システムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_scaleout_host -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemHostScaleout.xml

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_scaleout_host -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemHostScaleout.xml

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，手順1.で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1

負荷分散機からのリクエストの振り分けを抑止した状態で，複製先アプリケーションサーバのサービスユニットを一括起動します。
ここでは次の内容を実施しています。

cmx_start_targetコマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」を準備状態で起動することで，負荷分散機からのリクエストの振り分けを抑止します。準備状態にするには，-modeオプションに「READY」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem1 -unit unit1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode READY -s MyWebSystem1 -unit unit1

複製先アプリケーションサーバのリソースアダプタおよびJ2EEアプリケーションを開始します（必要に応じて）。
リソースアダプタおよびJ2EEアプリケーションが自動で開始しない場合は，最初に，リソースアダプタおよびJ2EEアプリケーションを開始します。JP1/SC/DPMを使用してディスクイメージを作成するときに，複製元アプリケーションサーバでリソースアダプタおよびJ2EEアプリケーションを一括停止しなかった場合，この操作は必要ありません。
ここでは次の内容を実施しています。

サーバ管理コマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」のリソースアダプタを開始します。

サーバ管理コマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」のJ2EEアプリケーションを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

Linuxの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartapp cmx_MyWebSystem_unit1_J2EE_01 -nameserver corbaname::192.168.1.13:900 -name MyApp

複製先アプリケーションサーバのサービスユニットを一括起動します。
cmx_start_targetコマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」を一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

9.8.3　JP1/SC/DPMを利用して構築したシステムのスケールイン

ここでは，JP1/SC/DPMを利用して構築したシステムをスケールインする手順を，モデルごとに説明します。

＜この項の構成＞

(1)　運用管理サーバモデルでのシステムのスケールイン

(2)　ホスト単位管理モデルでのシステムのスケールイン

(1)　運用管理サーバモデルでのシステムのスケールイン

運用管理サーバモデルで構築したシステムを縮小する場合は，サービスユニットまたはWebシステム単位にスケールインできます。

ここでは，「9.8.1　運用管理サーバモデルでのシステムのスケールアウト」で追加したサービスユニットを削除する場合を例にして，説明しています。このため，削除するサービスユニット名は「unit3」となります。

注意

Webシステムの構成を変更するとWebシステムが動作するために必要なリソースも変更する必要があります。Webシステムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

サービスユニットを削除します。
削除するサービスユニットを停止して，システムの情報モデルから削除します。なお，削除するサービスユニットは実行中のリクエストの処理を完了してから停止します。
ここでは次の内容を実施しています。

cmx_stop_targetコマンドを使用して，削除するサービスユニット「unit3」を一括停止します。このとき，コマンドの-modeオプションで「ALL」を指定して，停止状態にします。

cmx_delete_systemコマンドを使用して，サービスユニット「unit3」を削除します。なお，このコマンドを実行すると，Management Serverに登録されたシステムの情報モデルと負荷分散機に設定した情報は削除されます。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit3

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -unit unit3

cmx_delete_systemコマンドについて

J2EEサーバやWebサーバの環境削除などのアンセットアップを実行しません。cmx_delete_systemコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_delete_system（Webシステムの削除）」を参照してください。

参考

Webシステム単位でスケールインする場合は，cmx_stop_targetコマンドおよびcmx_delete_systemコマンドで，削除対象のWebシステムを指定します。各コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cmx_delete_system（Webシステムの削除）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

(2)　ホスト単位管理モデルでのシステムのスケールイン

ホスト単位管理モデルで構築したシステムを縮小する場合は，Webシステム単位にスケールインできます。ホスト単位管理モデルの場合，サービスユニット単位ではシステムをスケールインできません。

ここでは，「9.8.2　ホスト単位管理モデルでのシステムのスケールアウト」で追加したWebシステムを削除する場合を例にして，説明しています。このため，削除するWebシステム名は「MyWebSystem1」となります。この例では，複製元アプリケーションサーバと負荷分散機の仮想サーバを共有しているため，仮想サーバを削除しない設定をしてスケールインします。

システムを削除します。
削除するシステムを停止して，システムの情報モデルから削除します。なお，削除するシステムのサービスユニットは，実行中のリクエストの処理を完了してから停止します。
ここでは次の内容を実施しています。

cmx_stop_targetコマンドを使用して，削除するWebシステム「MyWebSystem1」を一括停止します。このとき，コマンドの-modeオプションで「ALL」を指定して，停止状態にします。

cmx_delete_systemコマンドを使用して，Webシステム「MyWebSystem1」を削除します。このコマンドを実行すると，Management Serverに登録されたシステムの情報モデルと負荷分散機に設定した情報は削除されます。この例では，負荷分散機の仮想サーバを複製元アプリケーションサーバと共有しているため，-lbオプションで「keepvs」（負荷分散機の仮想サーバを削除しない）を設定して，システムを削除します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1 -lb keepvs

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1 -lb keepvs

cmx_delete_systemコマンドについて

J2EEサーバやWebサーバの環境削除などのアンセットアップを実行しません。cmx_delete_systemコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_delete_system（Webシステムの削除）」を参照してください。

参考

cmx_delete_systemコマンドの-lbオプションは，.cmxrc（クライアント設定プロパティファイル）またはcmxclient.properties（クライアント共通設定プロパティファイル）のcmx.lbキーで，デフォルト値を設定しておくことができます。cmx.lbキーのデフォルト値に「keepvs」を設定しておくと，最後のホスト（アプリケーションサーバ）からシステムを削除する場合以外は，-lbオプションの指定を省略できます。最後のホスト（アプリケーションサーバ）からシステムを削除する場合は，-lbオプションに「deletevs」を指定してcmx_delete_systemコマンドを実行します。各ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の次の個所を参照してください。

4.3　.cmxrc（クライアント設定プロパティファイル）

4.4　cmxclient.properties（クライアント共通設定プロパティファイル）

9.9　構築済みのシステムの移行

Smart Composer機能を使用すると，構築済みのシステムの設定内容をほかの環境に移行できます。

ここでは，構築済みのシステムの移行について説明します。

＜この節の構成＞

9.9.1　構築済みのシステムの移行手順

9.9.2　構築済みのシステムの移行時に出力する簡易構築定義ファイルの内容

9.9.3　構築済みのシステムを移行するときの注意事項

9.9.1　構築済みのシステムの移行手順

ここでは，構築済みのシステムをほかの環境に移行する場合の手順について説明します。

構築済みのシステムを移行するためには，移行先のシステムで，Management Serverが動作している必要があります。構築済みのシステムを移行する前に，移行先のシステムでインストールと初期設定を済ませておいてください。

構築済みのシステムの移行の手順を次に示します。

移行元の環境で，構築済みのシステムの設定内容を簡易構築定義ファイルに出力します。
移行元の環境で，cmx_export_modelコマンドを使用して，構築済みのシステムの設定内容を簡易構築定義ファイルに出力します。cmx_export_modelコマンドの-oオプションには，出力先の簡易構築定義ファイルのパスを指定します。cmx_export_modelコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_export_model（簡易構築定義ファイルの出力）」を参照してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_export_model -o <任意のディレクトリ>¥MyWebSystemexport.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_export_model -o <任意のディレクトリ>/MyWebSystemexport.xml

移行先の環境で，構築済みのシステムと同じシステムを構築します。
移行先の環境で，cmx_build_systemコマンドを使用して，構築済みのシステムと同じシステムを構築します。cmx_build_systemコマンドの-fオプションには，手順1.で出力した簡易構築定義ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -f <任意のディレクトリ>¥MyWebSystemexport.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -f <任意のディレクトリ>/MyWebSystemexport.xml

なお，Webシステムに関連づいていない論理サーバを含むシステムを構築する場合は，次に示す手順で，移行先の環境に，構築済みのシステムと同じシステムを構築してください。

移行元の環境で，構築済みのシステムの設定内容を簡易構築定義ファイルに出力します。
移行元の環境で，cmx_export_modelコマンドを使用して，構築済みのシステムの設定内容を簡易構築定義ファイルに出力します。cmx_export_modelコマンドの-oオプションには，出力先の簡易構築定義ファイルのパスを指定します。
Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_export_model -o <任意のディレクトリ>¥MyWebSystemexport.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_export_model -o <任意のディレクトリ>/MyWebSystemexport.xml

出力した簡易構築定義ファイルを使用して，移行先の環境にシステムの情報モデルを構築します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_model -f <任意のディレクトリ>¥MyWebSystemexport.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_model -f <任意のディレクトリ>/MyWebSystemexport.xml

移行先の環境で，構築したシステムの情報モデルを基に，cmx_build_systemコマンドを使用してWebシステムに関連づいていない論理サーバを含むシステムを構築します。
構築するシステムにWebシステムに関連づいている論理サーバが含まれる場合，-sオプションにWebシステム名を指定して，再度cmx_build_systemコマンドを実行します。

構築するシステムにWebシステムに関連づいていない論理サーバだけ含まれる場合

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -ns

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -ns

構築するシステムにWebシステムに関連づいていない論理サーバおよびWebシステムに関連づいている論理サーバが含まれる場合

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -s <Webシステム名>

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -ns

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -s <Webシステム名>

# /opt/Cosminexus/manager/bin/cmx_build_system -ns

9.9.2　構築済みのシステムの移行時に出力する簡易構築定義ファイルの内容

ここでは，cmx_export_modelコマンドを使用して構築済みのシステムの設定内容を出力した場合の出力内容について説明します。

＜この項の構成＞

(1)　XMLスキーマのバージョン

(2)　物理ティアの構成

(3)　論理サーバのコンフィグレーションに設定しているパラメタ

(4)　出力例

(1)　XMLスキーマのバージョン

XMLスキーマのバージョンは，最新のバージョンで出力されます。旧バージョンの簡易構築定義ファイルを使用して構築したシステムに対して設定内容を出力した場合，最新のXMLスキーマのバージョンに従って，タグ名称が最新の名称に変換されます。

(2)　物理ティアの構成

「5.1.1　構成定義パターン選定の考え方」にある構成を，Smart Composer機能を使用して構築している場合は，簡易構築定義ファイルで定義した物理ティアの構成が出力されます。「5.1.1　構成定義パターン選定の考え方」にない構成で，Smart Composer機能を使用しないで構築したシステムの場合は，free-tier構成で出力されます。例えば，運用管理ポータルを使用して構築したシステムはfree-tier構成で出力されます。free-tier構成の場合，システムの構成に応じて，次に示す論理サーバが出力されます。

論理Webサーバ

論理J2EEサーバ

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

論理SFOサーバ

論理CTMドメインマネジャ

論理CTM

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

論理ユーザサーバ

論理ネーミングサービス

出力される論理サーバのパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.11.1　J2EEアプリケーションを実行するシステムを構築する場合」を参照してください。

(3)　論理サーバのコンフィグレーションに設定しているパラメタ

出力規則

非推奨のパラメタは，推奨のパラメタに変換されます。

値を指定しているパラメタは出力されます。値を省略しているパラメタは出力されません。

簡易構築定義ファイルでパラメタにデフォルト値を設定している場合，または運用管理ポータルでキーにデフォルト値を設定している場合，そのパラメタは出力されます。

出力順序

論理サーバの種類ごとに，パラメタの種類によって出力順序があります。また，同じパラメタの種類の中でのパラメタの出力順序は，パラメタ名称の昇順です。パラメタの出力順序を，次の表に示します。

表9-30　パラメタの出力順序

パラメタを設定するサーバ | 出力順序 | パラメタの種類
J2EEサーバ | 1 | 各論理サーバ共通で指定できるパラメタ
2 | J2EEサーバ用オプション定義のパラメタ
3 | J2EEサーバ用ユーザプロパティのパラメタ
Webサーバ | 1 | 各論理サーバ共通で指定できるパラメタ
2 | Hitachi Web Server定義のパラメタ
3 | Hitachi Web Server用リダイレクタ動作定義のパラメタ
4 | ワーカ定義のパラメタ
そのほかの論理サーバ | 1 | 各論理サーバ共通で指定できるパラメタ
2 | 該当する論理サーバのパラメタ

設定先

構築済みのシステムの論理サーバによってパラメタの設定先が異なります。パラメタの設定先を，次の表に示します。なお，free-tier構成では，物理ティアの定義にパラメタを設定できないため，サービスユニットの定義にすべてのパラメタが設定されます。

表9-31　パラメタの設定先

同じ種類の論理サーバの数 | パラメタに指定している値 | パラメタの設定先
1 | － | 物理ティアの定義
2～n | すべての論理サーバで同じ | 物理ティアの定義
論理サーバごとに異なる | サービスユニットの定義

（凡例）　－：なし

システムの中に同じ種類の論理サーバが一つしかない場合，すべてのパラメタが物理ティアの定義に設定されます。

システムの中に同じ種類の論理サーバが複数ある場合に，同じ種類の論理サーバで，同じパラメタに同じ値をそれぞれ指定していると，パラメタの値は，物理ティアの定義にそれぞれ設定されます。

システムの中に同じ種類の論理サーバが複数ある場合に，同じ種類の論理サーバで，同じパラメタに異なる値をそれぞれ指定していると，パラメタはサービスユニットの定義にそれぞれ設定されます。

(4)　出力例

簡易構築定義ファイルの出力例を次に示します。

ここでは，簡易構築定義ファイルを使用して構築したcombined-tier構成のシステムに，運用管理ポータルでホスト（host1），論理J2EEサーバ（j2ee01），および論理パフォーマンストレーサ（prf01）を追加したシステムの設定内容の出力例を示します。

簡易構築定義ファイルの出力例

<?xml version="1.0" encoding="UTF-8" ?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <web-system>
   <name>sample-system</name>
   <tier>
     <tier-type>combined-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
         <param-name>ejbserver.http.port</param-name>
         <param-value>8085</param-value>
       </param>
     </configuration>
   </tier>
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>combined-tier</hosts-for>
     </allocated-host>
   </unit>
 </web-system>
 <web-system>※1
   <tier>
     <tier-type>free-tier※2</tier-type>
   </tier>    
   <unit>※1
     <allocated-host>
       <host-ref>host1</host-ref>
       <hosts-for>free-tier</hosts-for>
       <define-server>
         <logical-server-name>prf01</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
       <define-server>
         <logical-server-name>j2ee01</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
         <configuration>
           <param>※3
             <param-name>ejbserver.server.prf.PRFID</param-name>
             <param-value>PRF_ID</param-value>
           </param>
         </configuration>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <host>
   <host-name>apsv1</host-name>
 </host>
 <host>
   <host-name>host1</host-name>
 </host>
</model-definition>

注※1　free-tier構成には，Webシステム名，およびサービスユニット名がありません。

注※2　ほかのどの物理ティアの構成にも当てはまらない構成が含まれていると，その構成がfree-tier構成として出力されます。

注※3　free-tier構成では，ティアの定義にパラメタを設定できないため，サービスユニットの定義にパラメタが設定されます。

9.9.3　構築済みのシステムを移行するときの注意事項

構築済みのシステムを移行するときの注意事項を次に示します。

移行後のシステム環境に，free-tier構成が含まれている場合，Smart Composer機能のコマンドで実施できる運用作業は次のとおりです。

システムの起動・停止

システム中の論理サーバのステータス監視

システム中の論理サーバのcmx_build_systemの実行状態の表示

free-tier構成を含むシステムについてほかの運用作業をする場合は，運用管理ポータル，またはサーバ管理コマンドを使用してください。

Smart Composer機能のコマンドで簡易構築定義ファイルに出力できるのは，システム環境の内容のうち，簡易構築定義ファイルで定義できる情報だけです。簡易構築定義ファイル以外のファイルを直接編集している場合，その編集内容は反映されません。

9.10　トラブルへの対処

ここでは，Smart Composer機能で構築したシステムの運用中に，トラブルが発生した場合の対処について説明します。

＜この節の構成＞

9.10.1　トラブルの種別と対処

9.10.2　負荷分散機の冗長化構成でトラブルが発生した場合の対処

9.10.1　トラブルの種別と対処

Smart Composer機能で構築したシステムで想定されるトラブルには，次に示す種別があります。

エラーメッセージ出力
エラーメッセージが出力されます。

システムダウン
アプリケーションサーバのサーバプロセスが異常終了します。

ハングアップ（無応答）
アプリケーション呼び出しの応答が返らなくなります。

スローダウン
アプリケーション呼び出しの応答は返りますが，応答時間が長くなります。

これらのトラブル種別ごとに，トラブルシューティングに必要な資料が取得できます。資料の取得方法と対処方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

2.　トラブルシューティング（資料取得と対処の概要）

3.　トラブルシューティング（資料取得の設定）

4.　トラブルシューティング（資料の出力先と出力方法）

5.　トラブルシューティング（資料の出力内容）

9.10.2　負荷分散機の冗長化構成でトラブルが発生した場合の対処

ここでは，Smart Composer機能を利用して，負荷分散機を冗長化構成で構築したシステムで，負荷分散機に障害が発生した場合の対処について説明します。

Smart Composer機能では，冗長化構成の負荷分散機に対して，同時に同じ設定処理を実行しています。一方の負荷分散機に障害が発生すると，障害が発生した負荷分散機を障害中の状態にして設定処理を抑止し，もう一方の負荷分散機だけに設定処理を続行します。

障害が発生した負荷分散機は，負荷分散機のコマンドを利用して復旧します。復旧が完了した負荷分散機は，次に示す手順で，冗長化構成での運用を再開してください。

cmx_test_lbコマンドを入力して，負荷分散機の状態を確認します。
障害から復旧した負荷分散機へ問題なくアクセスできることを確認します。

cmx_resume_lbコマンドを入力します。
障害が発生していた負荷分散機で休止中の状態が解除されて，冗長化構成の運用が再開されます。Smart Composer機能は，冗長化構成の負荷分散機に対して，同時に同じ設定処理を実行します。

また，冗長化構成の負荷分散機に障害が発生している場合に，負荷分散機を操作するコマンド（cmx_build_system，cmx_start_target，cmx_stop_target，cmx_delete_systemおよびcmx_test_lb）を入力すると，異常終了したり，警告終了したりします。その場合は，出力されるメッセージに従って対処してください。

参考

負荷分散機の障害は，負荷分散機のコマンドを利用して復旧してください。負荷分散機の復旧に関するコマンドの詳細については，各負荷分散機のドキュメントを参照してください。

9.11　システムの削除

不要になったシステムは削除できます。ここでは，不要になったシステムの削除の流れを説明します。

J2EEアプリケーションやリソースアダプタを停止します。
J2EEアプリケーションやリソースアダプタは，サーバ管理コマンドや運用管理ポータルを使用して停止します。

cmx_stop_targetコマンドを使用してシステムを停止します。
削除対象となるシステムを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

cmx_delete_systemコマンドを使用してManagement Server上からシステムを削除します。
Management Serverで管理されているシステムの情報モデルを削除します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.100 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

WebサーバまたはJ2EEサーバをアンセットアップします。
cmx_delete_systemコマンドでは，サーバの環境はアンセットアップされません。ホスト上のWebサーバまたはJ2EEサーバの環境は，それぞれ次の方法でアンセットアップします。

Webサーバの環境のアンセットアップ
Hitachi Web Serverのユティリティを使用して，Webサーバをアンセットアップします。Hitachi Web Serverのユティリティには，Webサーバの論理サーバ名を指定します。

J2EEサーバの環境のアンセットアップ
cjsetupコマンドを使用して，J2EEサーバをアンセットアップします。cjsetupコマンドには，J2EEサーバの論理サーバ名を指定します。

論理サーバ名はcmx_list_modelコマンドを使用して確認できます。cmx_delete_systemコマンドを実行する前に論理サーバ名を確認してください。
ただし，システム構築時に，WebサーバやJ2EEサーバの実サーバ名を指定している場合は，アンセットアップ時には実サーバ名を指定してください。実サーバ名の指定は，簡易構築定義ファイルの物理ティアのrealservernameパラメタに指定します。
アンセットアップ時に指定するサーバ名の詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。
次の実行例は，実サーバ名を指定していないJ2EEサーバをアンセットアップする場合の例です。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥bin¥cjsetup -d MyServer

UNIXの場合

# /opt/Cosminexus/CC/server/bin/cjsetup -d MyServer

10.　バッチアプリケーションを実行するシステムの構築

この章では，Smart Composer機能を使用した，バッチアプリケーションを実行するシステムの構築について説明します。

なお，J2EEアプリケーションを実行するシステムと共通する記述を参照している場合は，参照先の記述にある「J2EEサーバ」を「バッチサーバ」に置き換えてお読みください。

＜この章の構成＞

10.1　システム構築の概要

10.2　システムの構成定義

10.3　DB ConnectorのConnector属性ファイルの編集

10.4　システムの一括構築

10.5　システムの一括起動

10.6　リソースの設定

10.7　チューニング

10.8　構成定義パターンごとの簡易構築定義ファイルの作成

10.9　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

10.10　障害に対応したシステムの構築

10.1　システム構築の概要

各サーバの初期設定が終わったら，システムの一括構築，リソースアダプタのインポートと開始の順に操作してシステムを構築していきます。

ここでは，Smart Composer機能を使用したシステム構築の概要を説明します。なお，バッチアプリケーションの作成およびJP1/AJS2からのバッチアプリケーションの実行については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.3　バッチアプリケーション実行機能」を参照してください。また，JP1やクラスタソフトウェアと連携するシステムを構築する場合は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の次の個所もあわせて参照してください。

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

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

＜この節の構成＞

10.1.1　コマンドとシステム構築の関係

10.1.2　システム構築で使用するファイル

10.1.3　システム構築の流れ

10.1.1　コマンドとシステム構築の関係

Smart Composer機能を使用してシステムを構築する場合，システムの構築にはSmart Composer機能で提供するコマンドを使用します。また，リソースアダプタの設定には，サーバ管理コマンドを使用します。Smart Composer機能のコマンドおよびサーバ管理コマンドは，アプリケーションサーバ上で実行します。

ここでは，Smart Composer機能のコマンドとシステム構築の関係，およびサーバ管理コマンドとシステム構築の関係について説明します。

●システムの一括構築で使用するコマンド

バッチアプリケーションを実行するシステムの一括構築では，Smart Composer機能のコマンドを使用します。Smart Composer機能のコマンドとシステム構築の関係を次の図に示します。Smart Composer機能のコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「8.　Smart Composer機能で使用するコマンド」を参照してください。

図10-1　Smart Composer機能のコマンドとシステム構築の関係（バッチアプリケーションを実行するシステムの一括構築）

図中の項番について説明します。

操作
図中の項番
操作の詳細
使用するコマンド

システムの一括構築
1.
簡易構築定義ファイルの情報を基にして，Management Server上にシステムの情報モデルを生成します。
さらに，Management Server上の情報モデルに従って，すべてのアプリケーションサーバ上にシステムを構築します。
cmx_build_system

参考

cmx_から始まるSmart Composer機能のコマンドには共通引数（-m，-u，-p，-waitまたは-nowait，-verboseまたは-noverbose）があります。共通引数を省略したときのデフォルト値を，.cmxrcまたはcmxclient.propertiesに設定できます。

省略時のデフォルト値を，クライアントごとに設定する場合は.cmxrcに，すべてのクライアント共通で設定する場合はcmxclient.propertiesに設定します。

.cmxrcについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　.cmxrc（クライアント設定プロパティファイル）」を参照してください。cmxclient.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.4　cmxclient.properties（クライアント共通設定プロパティファイル）」を参照してください。

●リソースアダプタのインポートと開始で使用するコマンド

リソースアダプタおよびJ2EEアプリケーションのインポートと開始では，サーバ管理コマンドを使用します。サーバ管理コマンドとシステム構築の関係を次の図に示します。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「3.4　バッチサーバで使用するリソース操作コマンド」を参照してください。

図10-2　サーバ管理コマンドとシステム構築の関係（リソースアダプタのインポートと開始）

図中の項番について説明します。

操作 | 図中の項番 | 操作の詳細 | 使用するコマンド
リソースアダプタの操作 | 1. | リソースアダプタを各バッチサーバにインポートします。 | cjimportres
2. | 各バッチサーバにリソースアダプタをデプロイします。 | cjdeployrar
3. | Connector属性ファイルをリソースアダプタに反映します。 | cjsetrarprop
4. | リソースアダプタの接続テストをします。 | cjtestres
5. | 各バッチサーバでリソースアダプタを開始します。 | cjstartrar

なお，リソースアダプタの操作はバッチサーバごとに実行します。

参考

サーバ管理コマンドを実行する際には-nameserverオプションにプロバイダURLを指定する必要があります。-nameserverオプションに指定するプロバイダURLは，usrconf.properties（サーバ管理コマンド用システムプロパティファイル）に幾つかの設定をすることで省略できます。プロバイダURLを省略するための詳細については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.4　サーバ管理コマンドで指定するプロバイダURL」を参照してください。

10.1.2　システム構築で使用するファイル

ここでは，システムの構築で使用するファイルのうち，主なファイルについて説明します。ここで説明していないファイルについては，システム構築の手順の中で適宜説明します。

注意

ファイルを変更する場合は，バッチサーバを停止してください。バッチサーバの稼働中にファイルの内容を変更した場合の動作は保証されません。

＜この項の構成＞

(1)　Management Serverのファイル

(2)　Smart Composer機能のファイル

(3)　バッチサーバのファイル

(1)　Management Serverのファイル

adminagent.xml（運用管理エージェント設定ファイル）
運用管理エージェントが論理サーバを起動，停止するときに使用する環境変数を指定するファイルです。
ファイルの格納場所を次に示します。adminagent.xmlについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.5　adminagent.xml（運用管理エージェント設定ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥adminagent.xml

UNIXの場合
/opt/Cosminexus/manager/config/adminagent.xml

adminagent.properties（運用管理エージェントプロパティファイル）
運用管理エージェントのプロパティを指定するファイルです。論理サーバの動作確認レベルやsnapshotログの収集先の設定などで使用します。
ファイルの格納場所を次に示します。adminagent.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.2　adminagent.properties（運用管理エージェントプロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥adminagent.properties

UNIXの場合
/opt/Cosminexus/manager/config/adminagent.properties

mserver.properties（Management Server環境設定ファイル）
Management Serverのプロパティを指定するファイルです。Management Serverの環境設定や障害検知時コマンドの動作の設定などで使用します。
ファイルの格納場所を次に示します。mserver.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「10.7　mserver.properties（Management Server環境設定ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥mserver.properties

UNIXの場合
/opt/Cosminexus/manager/config/mserver.properties

(2)　Smart Composer機能のファイル

簡易構築定義ファイル
Smart Composer機能のコマンドで構築するシステムを定義するファイルです。
任意の場所に格納できます。簡易構築定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxdefcombinedmodel.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxdefcombinedmodel.xml

参考

システム運用中は，簡易構築定義ファイルをシステムの資産として保持し，設定情報を常に管理することを推奨します。

システムを構築したあとに，システムの設定内容を変更する場合は，システム構築時に使用した簡易構築定義ファイルをメンテナンスします。メンテナンスした簡易構築定義ファイルを基にシステムを再構築すると，メンテナンス結果がシステムに反映されます。

システムを構築したあとにシステムの構成変更をする場合は，構成変更定義ファイルを使用してください。簡易構築定義ファイルの編集で，システムの構成変更はできません。

構成変更定義ファイル
Smart Composer機能のコマンドで構築したWebシステムの構成を変更する内容（サービスユニットの追加，ホストの追加など）を定義します。
任意の場所に格納できます。構成変更定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。構成変更定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.7　構成変更定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxaddcombinedmodel.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxaddcombinedmodel.xml

参考

論理サーバのパラメタを変更する場合は，システムの構築時に使用した簡易構築定義ファイルをメンテナンスしてください。

スケールアウト用ホスト定義ファイル
Smart Composer機能のコマンドで構築した，ホスト単位管理モデルのWebシステムをスケールアウトする場合に，複製先のWebシステムの構成内容を定義します。
任意の場所に格納できます。スケールアウト用ホスト定義ファイルのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。スケールアウト用ホスト定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.9　スケールアウト用ホスト定義ファイル」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥cmxscaleouthostdef.xml

UNIXの場合
/opt/Cosminexus/manager/config/templates/cmxscaleouthostdef.xml

cmxserver.properties（サーバ設定プロパティファイル）
Smart Composer機能のコマンドの実行環境を設定します。
ファイルの格納場所を次に示します。cmxserver.propertiesの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.2　cmxserver.properties（サーバ設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

.cmxrc（クライアント設定プロパティファイル）
Smart Composer機能のコマンドの共通引数のデフォルト値を設定できます。クライアントごとに，異なるデフォルト値を設定したい場合に使用します。
コマンドを実行するOSユーザのホームディレクトリに格納します。.cmxrcのテンプレートファイルが提供されていますので，テンプレートファイルをコピーして利用してください。テンプレートファイルの格納場所を次に示します。.cmxrcの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　.cmxrc（クライアント設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥.cmxrc

UNIXの場合
/opt/Cosminexus/manager/config/templates/.cmxrc

cmxclient.properties（クライアント共通設定プロパティファイル）
Smart Composer機能のコマンドの共通引数のデフォルト値を設定できます。すべてのクライアントに，共通のデフォルト値を設定したい場合に使用します。
ファイルの格納場所を次に示します。cmxclient.propertiesの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.4　cmxclient.properties（クライアント共通設定プロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥

UNIXの場合
/opt/Cosminexus/manager/config/

(3)　バッチサーバのファイル

server.policy（バッチサーバ用セキュリティポリシーファイル）
バッチサーバを実行するJavaVMのセキュリティポリシーを指定するファイルです。
ファイルの格納場所を次に示します。セキュリティポリシーファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.4　server.policy（バッチサーバ用セキュリティポリシーファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥server.policy

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/server.policy

参考

バッチサーバのファイルには，このほかに次のファイルがあります。Smart Composer機能を使用してシステムを構築する場合，これらのファイルで設定する内容（キー）は，簡易構築定義ファイルのパラメタで設定します。

usrconf.properties（バッチサーバ用ユーザプロパティファイル）

バッチサーバのユーザプロパティを指定するファイルです。バッチサーバが使用するネーミングサービス，トランザクション，コネクション，ログ，セキュリティなどを指定します。

ファイルの格納場所を次に示します。usrconf.propertiesについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.3　usrconf.properties（バッチサーバ用ユーザプロパティファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties

usrconf.cfg（バッチサーバ用オプション定義ファイル）

バッチサーバのJavaVMの起動オプションを指定するファイルです。

ファイルの格納場所を次に示します。usrconf.cfgについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2　usrconf.cfg（バッチサーバ用オプション定義ファイル）」を参照してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.cfg

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.cfg

usrconf.propertiesおよびusrconf.cfgは，Smart Composer機能を使用しないで，ファイル編集やコマンド実行でシステムを構築する場合などに使用します。

10.1.3　システム構築の流れ

ここでは，バッチアプリケーションを実行するシステムでの，Smart Composer機能を使用したシステム構築の流れについて説明します。なお，システム構築を開始する前に，各サーバのインストールと初期設定が完了している必要があります。

システム構築の流れを次の図に示します。

図10-3　システム構築の流れ（バッチアプリケーションを実行するシステムの場合）

図中の1.～6.について説明します。

インストールと初期設定
システム構成に合わせて，アプリケーションサーバ，データベースサーバにそれぞれ必要な製品をインストールします。必要に応じて，OSやデータベースなどのホスティング環境を設定します。
また，各サーバでの環境変数の設定，Management Serverのセットアップと設定などを実施します。初期設定で実施する作業については，「7.1　インストールと初期設定の概要」を参照してください。

システムの構成定義
簡易構築定義ファイルで，システムの構成を定義します。簡易構築定義ファイルはエディタを使用して作成しますが，テンプレートファイルが用意されているので，構成の基本情報を設定するだけで運用できます。詳細については，「10.2　システムの構成定義」を参照してください。

DB ConnectorのConnector属性ファイルの編集
DB Connectorを使用する場合，Connector属性ファイルのテンプレートを取得して，編集します。詳細については，「10.3　DB ConnectorのConnector属性ファイルの編集」を参照してください。

システムの構築
システムの構築では，次の二つの内容を実施します。

構成定義で作成した簡易構築定義ファイルの情報を基に，Management Server上にシステムの情報モデルを生成する

システムの情報モデルからバッチアプリケーションを実行するシステムを構築する

システムの構築では，システムの情報モデルの生成から，システムの構築まで，一つのコマンドを使用して一括で実行できます。システムの構成として定義されている，すべてのアプリケーションサーバ上にバッチサーバなどをセットアップし，各論理サーバの環境を設定します。詳細については，「10.4　システムの一括構築」を参照してください。

システムの開始
システム内のすべてのサービスユニットを開始します。サービスユニット開始後，リソースアダプタをインポートし，リソースアダプタを開始します。システムの一括起動については，「10.5　システムの一括起動」を参照してください。リソースアダプタのインポートと開始については，「10.6.2　リソースアダプタのインポートと開始」を参照してください。

チューニング
構築したシステムについて，性能メトリックの相関が適切かどうか多角的に検証し，必要に応じてシステムの構成を変更します。詳細については，「10.7　チューニング」を参照してください。

また，「6.2.2　障害設計」で説明した運用をするためには，次の説明も参照してください。

サービスユニットを自動再起動するための設定（10.10.1参照）

10.2　システムの構成定義

Smart Composer機能でシステムを構築する場合，簡易構築定義ファイルにシステムの構成定義や論理サーバの環境設定などを定義します。ここでは，簡易構築定義ファイルの作成手順および作成方法について説明します。

＜この節の構成＞

10.2.1　簡易構築定義ファイルの作成手順

10.2.2　テンプレートファイル

10.2.3　簡易構築定義ファイルの設定内容

10.2.4　簡易構築定義ファイルの作成

10.2.1　簡易構築定義ファイルの作成手順

簡易構築定義ファイルはテキストエディタを使用して作成します。テンプレートファイルが用意されているので，構成の基本情報を設定するだけで作成できます。

簡易構築定義ファイルの作成手順を次に示します。

簡易構築定義ファイルのテンプレートファイルを任意の場所にコピーします。
テンプレートファイルについては，「10.2.2　テンプレートファイル」を参照してください。

簡易構築定義ファイルのテンプレートファイルを任意の名称に変更します。
テキストエディタなどを利用して，簡易構築定義ファイルに手順3.～手順6.の情報を定義します。

Management Serverで運用するWebシステム名，Webシステムの表示名などを定義します。
1Webシステムは，<web-system>タグから</web-system>タグまでの範囲に定義します。

システム構成に応じて，物理ティアを定義します。必要に応じて，論理サーバ全体で共通のコンフィグレーションを定義します。
システム構成に応じて，その機能を実現するために必要な論理サーバが決定されます。Smart Composer機能では，同一のデプロイメント（論理サーバの配置，定義設定など）を適用するホスト（サーバマシン）の集合を物理ティアという単位で定義します。バッチサーバの場合，物理ティアにはj2ee-tierを使用します。
物理ティアは，<tier>タグから</tier>タグまでの範囲に，物理ティアの種類や，論理サーバ全体で共通のコンフィグレーションなどを定義します。

論理サーバ（サービスユニット）を配置するホストを定義します。必要に応じて，論理サーバごとのコンフィグレーションを定義します。
Smart Composer機能では，論理サーバの集合をサービスユニットという単位で定義します。サービスユニットは，<unit>タグから</unit>タグまでの範囲に，サービスユニットを配置するホストや，そのホストが属する物理ティア，論理サーバごとのコンフィグレーションなどを定義します。

ホストを定義します。
物理ティアに属するホストのホスト名や，運用管理エージェントのホスト名などを定義します。ホストは，Webシステムに依存しません。Management Serverで定義済みのホストを利用する場合は，ホストの定義を省略できます。ホストは，<host>タグから</host>タグまでの範囲に定義します。

手順3.～手順6.で定義した情報を反映します。

簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。また，Webシステム，物理ティアおよびサービスユニットの概要については，「4.5　バッチアプリケーションを実行するシステムを構成する要素」を参照してください。

10.2.2　テンプレートファイル

簡易構築定義ファイルのテンプレートファイル（cmxdefcombinedmodel.xml）は，次の場所に提供されています。テンプレートファイルを任意の場所にコピーして，簡易構築定義ファイルを作成してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合

/opt/Cosminexus/manager/config/templates/

参考

テンプレートファイルの文字エンコーディングは，UTF-8です。

10.2.3　簡易構築定義ファイルの設定内容

ここでは，簡易構築定義ファイルの構成と，構築するシステムの構成情報と簡易構築定義ファイルの定義項目の対応について説明します。また，簡易構築定義ファイルで定義できるアプリケーションサーバの機能についても説明します。

＜この項の構成＞

(1)　簡易構築定義ファイルの構成

(2)　コンフィグレーション定義で使用するタグと適用範囲

(3)　バッチサーバとして動作するための設定

(4)　アプリケーションサーバの機能を有効にするための設定

(1)　簡易構築定義ファイルの構成

簡易構築定義ファイルでは，Webシステムの次の構成について設定します。

注意

バッチサーバは，論理J2EEサーバとして定義します。バッチサーバの動作設定を定義する場合，<logical-server-type>タグには「j2ee-server」を指定してください。

Webシステムの属性定義（<web-system>タグの定義）

物理ティアの定義（<tier>タグの定義）

物理ティアに属する論理サーバの種類ごとの定義（<tier>タグの<configuration>タグの定義）

データベースを使用するための設定の定義（<tier>タグの<configuration>タグの定義）※

サービスユニットの定義（<unit>タグの定義）

サービスユニットを構成するホストの定義（<unit>タグの<allocation-host>タグの定義）

ホストが属する物理ティアの論理サーバごとの定義（<unit>タグの<allocation-host>タグの<define-server>タグの定義）

ホストの定義（<host>タグの定義）

注※　データベースを使用するための設定の定義については，「7.5　データベースを使用するための設定」を参照してください。

物理ティアおよびサービスユニットのコンフィグレーション定義で，同じパラメタを指定した場合は，サービスユニットの定義，物理ティアの定義の順に優先して適用されます。

バッチアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応を次の図に示します。

図10-4　バッチアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応

この図に示すように，簡易構築定義ファイルでは，論理サーバの構成や環境設定だけでなく，ホストも定義できます。なお，構築済みのWebシステムなどで使用しているホストを使用する場合には，ホストの定義を省略することもできます。

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

(2)　コンフィグレーション定義で使用するタグと適用範囲

論理サーバの動作設定や，機能を使用するための設定などは，論理サーバのコンフィグレーションで定義します。論理サーバのコンフィグレーションは，論理サーバ全体，および論理サーバごとに定義できます。論理サーバ全体で共通の定義を設定する場合は物理ティアで，論理サーバごとの定義を設定する場合はサービスユニットで定義します。物理ティアで定義すると，その物理ティアに属するホストに配置する論理サーバ全体で共通のコンフィグレーションが設定されます。なお，Management Serverが自動設定する内容については，「4.8　Management Serverが自動で設定する内容」を参照してください。

論理サーバのコンフィグレーション定義の適用範囲を次の図に示します。

図10-5　論理サーバのコンフィグレーション定義の適用範囲

コンフィグレーション定義時に使用する簡易構築定義ファイルの主なタグを次の表に示します。

表10-1　論理サーバのコンフィグレーション定義時に使用する簡易構築定義ファイルの主なタグ

タグ名称
説明

<configuration>
論理サーバの動作環境を設定します。動作環境を設定する論理サーバの種類は，<logical-server-type>タグで指定します。
<configuration>タグは，物理ティアの定義（<tier>タグ内），およびサービスユニットの定義（<unit>タグ内）に設定できます。<tier>タグ内または<unit>タグ内のどちらの<configuration>タグに設定するかによって，設定内容を適用する論理サーバの範囲が異なります。論理サーバ全体で共通の設定を変更したい場合は，<tier>タグ内の<configuration>タグを編集し，特定の論理サーバの設定を変更したい場合は，<unit>タグ内の<configuration>タグを編集します。

<logical-server-type>
<configuration>タグで動作環境を設定する論理サーバの種類を定義します。定義できる論理サーバの種類を次に示します。

論理J2EEサーバ：j2ee-server※

論理パフォーマンストレーサ：performance-tracer

論理CTMドメインマネジャ：ctm-domain-manager

論理CTM：component-transaction-monitor

論理スマートエージェント：smart-agent

<param>
論理サーバの動作環境を設定するパラメタ（パラメタ名と値の組み合わせ）を定義します。1種類のパラメタごとに<param>タグで囲んで定義します。

<param-name>
論理サーバの動作環境を設定するパラメタの名称を定義します。

<param-value>
<param-name>タグで指定したパラメタの設定値を定義します。

注　各論理サーバの<configuration>タグ内で，パラメタ名（<param-name>タグ）と値（<param-value>タグ）の設定を省略すると，論理サーバの動作環境にはデフォルトの値が設定されます。デフォルトの設定のままで利用する場合は，定義不要です。デフォルトで設定されている動作を変更したい場合や，アプリケーションサーバの機能を有効にしたい場合は，パラメタと値の設定を追加または変更してください。アプリケーションサーバの機能を有効にするための設定については，「(4)　アプリケーションサーバの機能を有効にするための設定」を参照してください。

注※　バッチサーバは論理J2EEサーバとして定義します。このため，バッチサーバの動作設定を定義する場合，<logical-server-type>タグには「j2ee-server」を指定します。

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

参考

バッチアプリケーションを実行するシステムでもユーザサーバを配置できます。ユーザサーバを配置する場合の簡易構築定義ファイルの作成方法は，J2EEアプリケーションを実行するシステムと同じです。詳細は，「8.11.6(4)　論理ユーザサーバを配置する場合の簡易構築定義ファイルの作成」を参照してください。

(3)　バッチサーバとして動作するための設定

バッチサーバとして動作するためには，バッチサーバの設定が必要です。バッチサーバの設定は，論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。バッチサーバに関する定義を次の表に示します。

表10-2　バッチサーバに関する定義

項目
パラメタ
設定内容
必須または任意

バッチサーバとしてサーバを構築するための設定
batch.service.enabled
バッチサーバとして構築するかどうかを指定します。パラメタの値は必ずtrueを指定してください。
必須

SecurityManagerを使用しない設定
use.security
バッチサーバの起動時にSecurityManagerを使用するかどうかを指定します。パラメタの値は必ずfalseを指定してください。
必須

ライトトランザクション機能を有効にするための設定
ejbserver.distributedtx.XATransaction.enabled
グローバルトランザクションを使用するかどうかを指定します。バッチサーバの場合，グローバルトランザクションは使用できません。ローカルトランザクションを使用します。このため，ローカルトランザクションに最適化された環境を提供する，ライトトランザクション機能を使用します。パラメタの値は必ずfalseを指定してください。なお，このパラメタはデフォルトの設定がfalseのため，変更しないでください。
任意

明示管理ヒープ機能を無効にする設定
add.jvm.arg
明示管理ヒープ機能を使用するかどうかを指定します。
バッチサーバの場合，明示管理ヒープ機能を使用しないときは，明示管理ヒープ機能を無効にすることをお勧めします。明示管理ヒープ機能を無効にするには，パラメタの値に-XX:-HitachiUseExplicitMemoryを指定してください。デフォルトの設定の場合，明示管理ヒープ機能は有効（-XX:+HitachiUseExplicitMemory）です。
任意

実サーバ名の設定
realservername
バッチサーバの実サーバ名を指定します。省略した場合は，論理サーバ名が設定されます。
任意

JavaVM終了メソッド呼び出し時のJavaVMの動作設定
ejbserver.batch.application.exit.enabled
次のJavaVM終了メソッドをバッチアプリケーションで呼び出した時に，JavaVMを終了するかどうかを指定します。

java.lang.System.exit(int)

java.lang.Runtime.exit(int)

java.lang.Runtime.halt(int)

デフォルトは「true」（JavaVMを終了しないでバッチアプリケーションのスレッドを終了する）です。「false」を指定すると，JavaVM終了メソッドの呼び出し時に，バッチサーバごとJavaVMが終了されます。詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.3.7　バッチアプリケーションの実装（バッチアプリケーションの作成規則）」を参照してください。
任意

（凡例）必須：必ず指定してください。　任意：必要に応じて設定してください。

(4)　アプリケーションサーバの機能を有効にするための設定

簡易構築定義ファイルのコンフィグレーション定義では，デフォルトが設定されています。使用するアプリケーションサーバの機能によっては，デフォルトの設定では無効なものもあります。この場合は，簡易構築定義ファイルのパラメタと値を追加または変更して，機能を有効にする設定をします。なお，機能を使用するために設定する項目のうち，一部の設定項目は，簡易構築定義ファイルで定義できません。簡易構築定義ファイルで設定できない項目は，ほかのユーザ定義ファイルを使用して定義します。

例えば，バッチサーバが使用するネーミングサービス，トランザクション，コネクション，コンテナ，ログ，セキュリティの設定を変更したい場合，バッチサーバのJavaVMの起動オプションなどを変更したい場合などには，簡易構築定義ファイルで設定を変更します。簡易構築定義ファイルに，テキストエディタなどを使用して，変更対象のパラメタ名と変更後の値を設定します。ただし，バッチサーバのセキュリティポリシーとWebアプリケーションのプロパティを変更したい場合には，Management Serverでは設定できません。簡易構築定義ファイル以外のユーザ定義ファイル（server.policy，hitachi_web.properties）をテキストエディタなどで編集して，動作設定を変更してください。

注意

server.policyまたはhitachi_web.propertiesを編集する場合は，編集対象のバッチサーバのセットアップが完了していることが前提になります。また，UNIXの場合，動作設定を変更するときには，root権限（Component Container管理者を設定していない場合），またはComponent Container管理者の権限（Component Container管理者を設定している場合）が必要です。

Smart Composer機能で使用できるアプリケーションサーバの機能については，「10.9　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先」を参照してください。

10.2.4　簡易構築定義ファイルの作成

ここでは，バッチサーバを配置するパターン（j2ee-tier）を簡易構築定義ファイルで作成する例について説明します。

簡易構築定義ファイルは，選定した構成定義パターンに合わせて作成します。バッチサーバを配置するパターン（j2ee-tier）以外の構成定義パターンには，CTMを使用するパターン（ctm-tier）があります。CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成方法については，「10.8.2　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成」を参照してください。

なお，JP1/SC/DPMの利用，複数サービスユニットの配置を設定する場合は，「10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。

物理ティアの定義
物理ティアの種類にはj2ee-tierを定義します。j2ee-tierでは，バッチサーバおよびパフォーマンストレーサのコンフィグレーションを設定できます。
「10.2.3(3)　バッチサーバとして動作するための設定」を参照して，バッチサーバの設定をします。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。バッチサーバを配置するパターン（j2ee-tier）の構成情報の例を次の図に示します。

図10-6　バッチサーバを配置するパターン（j2ee-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図10-6の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，テンプレートファイルをコピーし，ファイル名を「MyWebSystemDef.xml」に変更して作成します。

MyWebSystemDef.xmlの作成例を次に示します。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>batch.service.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>use.security</param-name>
          <param-value>false</param-value>
       </param>
       <param>
          <param-name>add.jvm.arg</param-name>
          <param-value>-XX:-HitachiUseExplicitMemory</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
       <define-server>
         <logical-server-name>BatchServer</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
       </define-server>
       <define-server>
         <logical-server-name>PRF</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
</model-definition>

注1　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注2　バッチサーバの場合，負荷分散機を使用しません。このため，テンプレートにある<load-balancer>タグの記述は削除してください。

10.3　DB ConnectorのConnector属性ファイルの編集

DB Connectorを使用してデータベースに接続するバッチアプリケーションを開発している場合，バッチサーバでDB Connectorの設定が必要です。DB Connectorを使用するには，システムを起動する前にConnector属性ファイルを編集します。

ここでは，DBConnector_HiRDB_Type4_CP.rarを使用した場合の，DB ConnectorのConnector属性ファイルの取得，および編集手順を例に使用して説明します。DBConnector_HiRDB_Type4_CP.rar以外のRARファイルを使用する場合は，利用するDB ConnectorのRARファイルに読み替えてください。ただし，バッチサーバの場合，グローバルトランザクションは使用できないため，グローバルトランザクション用のRARファイルは使用できません。

Connector属性ファイルの編集手順について次に示します。

Connector属性ファイルを取得します。
DB Connectorについては，アプリケーションサーバがConnector属性ファイルのテンプレートファイルを提供しています。次の場所からテンプレートファイルを取得してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥templates

UNIXの場合

/opt/Cosminexus/CC/admin/templates

DBConnector_HiRDB_Type4_CP.rarを使用する場合，DBConnector_HiRDB_Type4_CP_cfg.xmlを取得します。
アプリケーションサーバが提供しているConnector属性ファイルのテンプレート，およびテンプレートファイルに関する注意事項については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

Connector属性ファイルを編集します。
取得したConnector属性ファイルを任意の場所に保存します。ここでは，Connector属性ファイルの名称をMyDBConnectorAttr.xmlとして保存します。
保存したConnector属性ファイルで，データベースへの接続の設定など必要な項目を編集してください。
なお，バッチサーバの場合，リソースへのルックアップには，ユーザ指定名前空間機能を使用してリソースアダプタをルックアップしてください。ユーザ指定名前空間機能での任意のルックアップ名称は，Connector属性ファイルで設定します。

Connector属性ファイルを編集したあとのDB Connectorのデプロイ手順については，「10.6.2　リソースアダプタのインポートと開始」を参照してください。

10.4　システムの一括構築

システムの一括構築では，情報モデルの生成，その情報モデルを基にしたバッチサーバのセットアップ，および各論理サーバの環境設定を一つのコマンドを使用して一括で実施します。

システムを一括構築する手順を次に示します。

アプリケーションサーバでcmx_build_systemコマンドを使用してシステムを一括構築します。cmx_build_systemコマンドの-fオプションには，簡易構築定義ファイルを指定します。説明では，簡易構築定義ファイルの名称をMyWebSystemDef.xmlとしています。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml

10.5　システムの一括起動

ここでは，システムを開始する方法について説明します。システムを開始するには，Smart Composer機能のコマンドを使用してシステムを一括起動します。なお，説明では，「10.4　システムの一括構築」で構築したシステムを一括起動します。

参考

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

システムの一括起動システムを一括起動する手順を，次に示します。

システムを開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

cmx_list_statusコマンドを使用して，システム内のすべてのサービスユニットが起動されていることを確認してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_list_status -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem
unit1,MyWebSystem,done,working

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_list_status -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem
unit1,MyWebSystem,done,working

cmx_start_targetコマンドおよびcmx_list_statusコマンドの-sオプションには，簡易構築定義ファイルMyWebSystemDef.xmlの<web-system>タグの<name>タグで指定したWebシステム名を指定します。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。Smart Composer機能では，一括起動処理中に論理サーバの起動に失敗しても，そのまま処理を続行します。

cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

10.6　リソースの設定

バッチサーバは，リソースとしてデータベースを利用できます。使用できるデータベースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.7.1　接続できるデータベース」を参照してください。ここでは，リソースの設定方法について説明します。また，設定する場合の注意事項についても説明します。

＜この節の構成＞

10.6.1　リソースの設定の前に

10.6.2　リソースアダプタのインポートと開始

10.6.1　リソースの設定の前に

リソースの設定をする前に，リソースの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。リソースの設定の注意事項およびサーバ管理コマンドを使用するための動作設定については，「8.8.1　リソースとJ2EEアプリケーションの設定の前に」を参照してください。

リソースに接続するバッチアプリケーションの場合，ユーザ指定名前空間機能を使用してリソースアダプタに別名を設定します。バッチアプリケーションからリソースアダプタをルックアップするには，ユーザ指定名前空間機能で設定した別名を使用します。ユーザ指定名前空間機能の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.3.8　バッチアプリケーションの実装（リソースに接続する場合）」を参照してください。

ここでは，リソースのプロパティ定義を設定するための前提について説明します。

リソースアダプタのプロパティは，サーバ管理コマンドを使用して定義します。
サーバ管理コマンドで定義する場合，cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させてください。なお，リソースアダプタをデプロイする前にプロパティを定義する場合は，cjgetrespropコマンドとcjsetrespropコマンドを使用してください。

項目を設定するConnector属性ファイルのタグの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。サーバ管理コマンドでの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.3.1　J2EEリソースのプロパティの設定手順」を参照してください。

10.6.2　リソースアダプタのインポートと開始

バッチアプリケーションからデータベースに接続するには，DB Connectorというリソースアダプタを使用します。リソースアダプタのインポートと開始には，サーバ管理コマンドを使用します。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「3.4　バッチサーバで使用するリソース操作コマンド」を参照してください。サーバ管理コマンドでのリソースアダプタの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.　リソースアダプタの設定」を参照してください。

ここでは，次に示すリソースアダプタをインポートして開始する手順を例にして説明します。

表10-3　例で使用するリソースアダプタのファイル名と表示名

種別 | 名前
ファイル名 | DBConnector_HiRDB_Type4_CP.rar※
表示名 | DB_Connector_for_HiRDB_Type4
Connector属性ファイルのファイル名 | MyDBConnectorAttr.xml

注※　HiRDB Type4 JDBC Driverを使用して，ローカルトランザクションまたはトランザクション管理なしでHiRDBに接続する場合に使用するRARファイルです。

DBConnector_HiRDB_Type4_CP.rar以外のRARファイルを使用する場合は，利用するDB ConnectorのRARファイルに読み替えてください。ただし，バッチサーバの場合，グローバルトランザクションは使用できないため，グローバルトランザクション用のRARファイルは使用できません。なお，「10.3　DB ConnectorのConnector属性ファイルの編集」でConnector属性ファイルの取得と編集が済んでいることを前提にしています。

DB Connectorを使用する場合のリソースアダプタのインポートと開始の手順を次に示します。なお，説明では「10.4　システムの一括構築」で構築したシステムを使用します。

リソースアダプタをインポートします。
サーバ管理コマンドを使用して，リソースアダプタをバッチサーバへインポートします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres BatchServer -nameserver corbaname::192.168.1.11:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres BatchServer -nameserver corbaname::192.168.1.11:900 -type rar -f /opt/Cosminexus/CC/DBConnector/DBConnector_HiRDB_Type4_CP.rar

リソースアダプタをデプロイします。
サーバ管理コマンドを使用して，バッチサーバにリソースアダプタをデプロイします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjdeployrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

編集したConnector属性ファイルをリソースアダプタに反映します。
サーバ管理コマンドを使用して，Connector属性ファイルをリソースアダプタに反映します。-cオプションには，「10.3　DB ConnectorのConnector属性ファイルの編集」で編集したConnector属性ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

リソースアダプタの接続を確認します。
サーバ管理コマンドを使用して，リソースアダプタの接続を確認します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjtestres BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

リソースアダプタを開始します。
サーバ管理コマンドを使用して，リソースアダプタを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイルに実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。論理サーバ名は，簡易構築定義ファイルのサービスユニットの定義内に，<logical-server-name>タグで指定している値です。

なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。バッチサーバの場合，<種別>には「J2EE」と表示されます。論理サーバの種類と<種別>との対応を次の表に示します。

表10-4　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。1台のサーバマシン内に複数のサービスユニットを配置している場合は，各サービスユニットに対してサーバ管理コマンドを実行します。その場合，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

BatchServer：簡易構築定義ファイルの<logical-server-name>タグの指定値

10.7　チューニング

チューニングでは，システムのパフォーマンスを生かす最適の設定を見つける作業（パフォーマンスチューニング）を実施します。構築した環境で性能メトリックの相関が適切かどうか多角的に検証し，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。パフォーマンスチューニングの詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「9.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

なお，パラメタを変更するとシステムが動作するために必要なリソースも変更する必要があります。システムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

チューニングの流れを次の図に示します。

図10-7　チューニングの流れ

システムの設定変更には，システムの情報モデルの変更とリソースアダプタの設定変更があります。(1)に従ってパラメタを変更してから，(2)に従ってシステムの設定を変更します。

＜この節の構成＞

(1)　パラメタの編集

(2)　システムの設定変更

(1)　パラメタの編集

簡易構築定義ファイル（MyWebSystemDef.xml）およびConnector属性ファイルについてパラメタの値を編集して，チューニングを実施します。チューニングできる項目，およびパフォーマンスチューニングの詳細については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の次の個所を参照してください。

9.1.3　チューニング項目

9.2　チューニングの方法

(2)　システムの設定変更

cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデルを変更します。変更した情報モデルを実システムに適用します。

なお，設定変更をする場合は，バッチアプリケーションが停止していることを確認してから実施してください。

リソースアダプタを停止します。
バッチアプリケーションからリソースに接続している場合は，サーバ管理コマンドを使用してリソースアダプタを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstoprar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjstoprar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

システム内のサービスユニットを停止します。
システムの情報モデルを変更する場合だけ停止します。システムの情報モデルを変更しない場合は，手順4.に進んでください。
システムの情報モデルを変更する場合は，cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを停止します。なお，システムが停止している場合はこの手順は不要です。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

システムの情報モデルを変更して実システムに展開し，システムを一括起動します。
システムの情報モデルを変更する場合だけ実施します。

cmx_build_systemコマンドを使用して，Management Server上のシステムの情報モデルを変更し，変更した情報モデルからシステムを構築します。-fオプションには，パフォーマンスチューニングを実施した簡易構築定義ファイルを指定します。-fオプションで指定したファイルの内容をシステムに反映するには，-changeオプションを指定します。

cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -f MyWebSystemDef.xml -change -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

リソースアダプタのプロパティを変更します。
リソースアダプタのプロパティを変更する場合だけ実施します。ここでは，サーバ管理コマンドを使用して，次の作業を実施しています。

Connector属性ファイルを取得します。

Connector属性ファイルのプロパティを編集します。

Connector属性ファイルをリソースアダプタに反映します。

リソースアダプタを開始します。

Connector属性ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjgetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjgetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml

# /opt/Cosminexus/CC/admin/bin/cjstartrar BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

各コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cjgetrarprop（RARファイルの属性の取得）

cjsetrarprop（RAR属性設定）

cjstartrar（リソースアダプタの開始）

cjstoprar（リソースアダプタの停止）

cmx_build_system（Webシステムの構築）

cmx_start_target（Webシステムまたはサービスユニットの開始）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。簡易構築定義ファイルに実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。論理サーバ名は，簡易構築定義ファイルのサービスユニットの定義内に，<logical-server-name>タグで指定している値です。

なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。バッチサーバの場合，<種別>には「J2EE」と表示されます。論理サーバの種類と<種別>との対応を次の表に示します。

表10-5　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

サーバ管理コマンドを使用する操作

ここで説明する操作のうち，サーバ管理コマンドを使用する操作は，サービスユニットごとに実行します。

なお，ここで示すサーバ管理コマンドの実行例は，すべてサービスユニット1を対象としています。1台のサーバマシン内に複数のサービスユニットを配置している場合は，各サービスユニットに対してサーバ管理コマンドを実行します。その場合，コマンド実行例中の値を次のように読み替えて同じ操作をしてください。

BatchServer：簡易構築定義ファイルの<logical-server-name>タグの指定値

10.8　構成定義パターンごとの簡易構築定義ファイルの作成

ここでは，選定した構成定義パターンごとに簡易構築定義ファイルの作成方法について説明します。

構成定義パターンと簡易構築定義ファイルの作成方法の参照先を次の表に示します。

表10-6　構成定義パターンと簡易構築定義ファイルの作成方法の参照先

構成定義パターン | 作成方法の参照先
バッチサーバを配置するパターン（j2ee-tier） | 10.8.1
CTMを使用するパターン（ctm-tier） | 10.8.2

なお，各構成定義パターンで使用できる設定と，簡易構築定義ファイルの作成方法については，「10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

＜この節の構成＞

10.8.1　バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルの作成

10.8.2　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

10.8.1　バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルの作成

ここでは，バッチサーバを配置するパターン（j2ee-tier）を簡易構築定義ファイルで作成する方法について説明します。この構成定義パターンでの作成方法については，「10.2.4　簡易構築定義ファイルの作成」を参照してください。なお，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

10.8.2　CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成

ここでは，CTMを使用するパターン（ctm-tier）を簡易構築定義ファイルで作成する方法について説明します。また，JP1/SC/DPMの利用，複数サービスユニットの配置などを設定する場合は，「10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成」を参照してください。

●簡易構築定義ファイルで必要な定義

簡易構築定義ファイルでは，次の定義が必要になります。

物理ティアの定義
物理ティアの種類にはctm-tierを定義します。
アプリケーションサーバでは，複数のバッチサーバが配置できます。複数のバッチサーバを配置する場合は，物理ティアの定義で，1ホストに配置するバッチサーバの数を設定します。

参考

1ホストに配置するバッチサーバの数は，Webシステムの構成変更時に変更できません。また，CTMを使用するパターンのシステムでは，スケールアウトおよびスケールインを実施できません。

ctm-tierでは，CTMドメインマネジャ，CTM，スマートエージェントおよびパフォーマンストレーサのコンフィグレーションと，バッチサーバ全体で共通のコンフィグレーションを設定できます。
表10-8を参照して，バッチサーバとバッチアプリケーションのスケジューリング機能の設定をします。

サービスユニットの定義
CTM・バッチサーバ用のサービスユニットを定義します。
CTMドメインマネジャ，CTM，スマートエージェントおよびパフォーマンストレーサのコンフィグレーションと，特定のバッチサーバのコンフィグレーションを設定できます。複数のバッチサーバを配置する場合，サービスユニット内のバッチサーバは，番号（<server-no>タグ）で特定します。

注意

CTMを識別するCTM識別子（ctmid）は，運用管理ドメイン内でユニークな値を設定する必要があります。CTM識別子（ctmid）の設定は省略できます。

ホストの定義
CTM・バッチサーバ用のサービスユニットを構成するホストを定義します。

複数のバッチサーバを配置する場合も，物理ティアおよびサービスユニットの定義で，コンフィグレーションを定義できます。バッチサーバのコンフィグレーション定義の適用範囲を次の図に示します。

図10-8　バッチサーバのコンフィグレーション定義の適用範囲

この図の場合に，各サービスユニットのバッチサーバごとに適用されるコンフィグレーション定義を次の表に示します。

表10-7　各サービスユニットのバッチサーバごとに適用されるコンフィグレーション定義

サービスユニット
バッチサーバ
適用されるコンフィグレーション定義

unit1
バッチサーバ（1A）

サービスユニットの定義（特定のバッチサーバの定義）

物理ティアの定義（バッチサーバ全体で共通の定義）

バッチサーバ（1B）
物理ティアの定義（バッチサーバ全体で共通の定義）

この表のように，バッチサーバごとに適用されるコンフィグレーション定義が複数ある場合，各定義で同じパラメタを指定したときは，次の1.，2.の順に優先して適用されます。

サービスユニットの定義（特定のバッチサーバの定義）

物理ティアの定義（バッチサーバ全体で共通の定義）

●バッチアプリケーションのスケジューリング機能を使用するための設定

バッチアプリケーションのスケジューリング機能を使用する場合には，次の設定が必要です。

バッチサーバの設定（「10.2.3(3)　バッチサーバとして動作するための設定」参照）

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

これらの設定は，各論理サーバの<configuration>タグ内に指定します。

バッチサーバとバッチアプリケーションのスケジューリング機能に関する定義を次の表に示します。

表10-8　バッチサーバとバッチアプリケーションのスケジューリング機能に関する定義

論理サーバの種類
項目
パラメタ
設定内容
必須または任意

論理CTM（component-transaction-monitor）
ORBゲートウェイ機能を使用する設定
ctm.Agent
CTMレギュレータのORBゲートウェイ機能を使用するかどうかを指定します。
スケジューリング機能を使用する場合，CTMレギュレータのORBゲートウェイ機能を使用します。パラメタの値は必ず1を指定してください。
必須

論理J2EEサーバ（j2ee-server）
バッチサーバとしてサーバを構築するための設定
batch.service.enabled
バッチサーバとして構築するかどうかを指定します。パラメタの値は必ずtrueを指定してください。
必須

SecurityManagerを使用しない設定
use.security
バッチサーバの起動時にSecurityManagerを使用するかどうかを指定します。パラメタの値は必ずfalseを指定してください。
必須

ライトトランザクション機能を有効にするための設定
ejbserver.distributedtx.XATransaction.enabled
グローバルトランザクションを使用するかどうかを指定します。バッチサーバの場合，グローバルトランザクションは使用できません。ローカルトランザクションを使用します。このため，ローカルトランザクションに最適化された環境を提供する，ライトトランザクション機能を使用します。パラメタの値は必ずfalseを指定してください。なお，このプロパティはデフォルトの設定がfalseのため，変更しないでください。
必須

スマートエージェントを使用する設定
vbroker.agent.enableLocator
スマートエージェントを使用するかどうかを指定します。
スケジューリング機能を使用する場合，スマートエージェントを使用します。パラメタの値は必ずtrueを指定してください。
必須

明示管理ヒープ機能を無効にする設定
add.jvm.arg
明示管理ヒープ機能を使用するかどうかを指定します。
バッチサーバの場合，明示管理ヒープ機能を使用しないときは，明示管理ヒープ機能を無効にすることをお勧めします。明示管理ヒープ機能を無効にするには，パラメタの値に-XX:-HitachiUseExplicitMemoryを指定してください。デフォルトの設定の場合，明示管理ヒープ機能は有効（-XX:+HitachiUseExplicitMemory）です。
任意

実サーバ名の設定
realservername
バッチサーバの実サーバ名を指定します。省略した場合は，論理サーバ名が設定されます。
任意

JavaVM終了メソッド呼び出し時のJavaVMの動作設定
ejbserver.batch.application.exit.enabled
次のJavaVM終了メソッドをバッチアプリケーションで呼び出した時に，JavaVMを終了するかどうかを指定します。

java.lang.System.exit(int)

java.lang.Runtime.exit(int)

java.lang.Runtime.halt(int)

デフォルトは「true」（JavaVMを終了しないでバッチアプリケーションのスレッドを終了する）です。「false」を指定すると，JavaVM終了メソッドの呼び出し時に，バッチサーバごとJavaVMが終了されます。詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「2.3.7　バッチアプリケーションの実装（バッチアプリケーションの作成規則）」を参照してください。
任意

スケジュールグループ名の設定
ejbserver.batch.schedule.group.name
CTMによって管理されるバッチサーバ群のスケジュールグループ名を指定します。デフォルトではJOBGROUPが設定されます。
CTMは，スケジュールグループごとにバッチアプリケーションの実行をスケジューリングします。
複数のスケジュールグループを使用してスケジュールキューを分ける場合には，バッチサーバごとにスケジュールグループ名を設定してください。
任意

スケジュールキューの長さの設定
ejbserver.batch.queue.length
CTMで作成されるスケジュールキューの長さを指定します。デフォルトでは50が設定されます。
任意

（凡例）必須：必ず指定してください。　任意：必要に応じて設定してください。

●構成情報の例

簡易構築定義ファイルの作成例で使用する構成情報について説明します。CTMを使用するパターン（ctm-tier）の構成情報の例を次の図に示します。ここでは，アプリケーションサーバには，バッチサーバを二つ配置する例を使用します。

図10-9　CTMを使用するパターン（ctm-tier）の構成情報の例

●簡易構築定義ファイルの作成例

図10-9の構成情報に従って，簡易構築定義ファイルを作成します。なお，この例では，テンプレートファイルをコピーし，ファイル名を「MyWebSystemDef.xml」に変更して作成します。

MyWebSystemDef.xmの作成例を次に示します。

MyWebSystemDef.xmlファイル

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>ctm-tier</tier-type>
     <j2ee-server-count>2</j2ee-server-count>
     <configuration>
       <logical-server-type>component-transaction-monitor</logical-server-type>
       <param>
          <param-name>ctm.Agent</param-name>
          <param-value>1</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>batch.service.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>use.security</param-name>
          <param-value>false</param-value>
       </param>
       <param>
          <param-name>add.jvm.arg</param-name>
          <param-value>-XX:-HitachiUseExplicitMemory</param-value>
       </param>
       <param>
          <param-name>vbroker.agent.enableLocator</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>ejbserver.batch.schedule.group.name</param-name>
          <param-value>JOBGROUP</param-value>
       </param>
       <param>
          <param-name>ejbserver.batch.queue.length</param-name>
          <param-value>50</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>ctm-tier</hosts-for>
       <define-server>
         <logical-server-name>BatchServer1</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
         <server-no>1</server-no>
         <configuration>
           <param>
             <param-name>ejbserver.http.port</param-name>
             <param-value>8081</param-value>
           </param>
           <param>
             <param-name>webserver.connector.ajp13.port</param-name>
             <param-value>8017</param-value>
           </param>
           <param>
             <param-name>ejbserver.rmi.naming.port</param-name>
             <param-value>23152</param-value>
           </param>
           <param>
             <param-name>ejbserver.naming.port</param-name>
             <param-value>901</param-value>
           </param>
           <param>
             <param-name>ejbserver.distributedtx.recovery.port</param-name>
             <param-value>20312</param-value>
           </param>
         </configuration>
       </define-server>
       <define-server>
         <logical-server-name>BatchServer2</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
         <server-no>2</server-no>
         <configuration>
           <param>
             <param-name>ejbserver.http.port</param-name>
             <param-value>8082</param-value>
           </param>
           <param>
             <param-name>webserver.connector.ajp13.port</param-name>
             <param-value>8027</param-value>
           </param>
           <param>
             <param-name>ejbserver.rmi.naming.port</param-name>
             <param-value>23252</param-value>
           </param>
           <param>
             <param-name>ejbserver.naming.port</param-name>
             <param-value>902</param-value>
           </param>
           <param>
             <param-name>ejbserver.distributedtx.recovery.port</param-name>
             <param-value>20322</param-value>
           </param>
         </configuration>
       </define-server>
       <define-server>
         <logical-server-name>PRF</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
</model-definition>

注1　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注2　バッチサーバの場合，負荷分散機を使用しません。このため，テンプレートにある<load-balancer>タグの記述は削除してください。

10.8.3　各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成

Smart Composer機能を使用して構築するシステムでは，複数サービスユニットの配置やJP1/SC/DPMの利用が設定できます。Smart Composer機能で構築するシステムで使用できる設定と構成定義パターンとの対応を次の表に示します。

表10-9　Smart Composer機能で構築するシステムで使用できる設定と構成定義パターンとの対応

設定項目 | 説明 | 構成定義パターンごとの対応
A | B
サーバマシン内での複数サービスユニットの配置 | 1台のサーバマシンに複数のサービスユニットを配置できます。サーバマシン中のサーバをサービスユニット単位で増やしてシステムを拡張したり，複数の業務を1台のサーバマシンで運用したりできます。 | ○ | ○
JP1/SC/DPMの利用 | JP1/SC/DPMでは，構築したシステムのディスクイメージ（OSとアプリケーション）を複製できます。Smart Composer機能を使用したシステムの初期構築や，スケールアウト時に利用できます。 | ○ | ×※

（凡例）

○：対応しています。

×：対応していません。

A：バッチサーバを配置するパターンを示します。

B：CTMを使用するパターンを示します。

注※　CTMを使用するパターンでは，システムの構成変更（スケールインまたはスケールアウト）はできません。

ここでは，Smart Composer機能を使用して構築するシステムで使用できる設定で，簡易構築定義ファイルを作成する方法について説明します。

＜この項の構成＞

(1)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

(2)　JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成

(1)　サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

1台のサーバマシンに複数のバッチサーバを配置すると，1台のサーバマシン内に，同じ種類の論理サーバが複数存在することになります。このため，簡易構築定義ファイルを作成する際には，各論理サーバのコンフィグレーションで，次に示す項目の指定値を重複しないようにしてください。

表10-10　論理サーバごとに重複しないように設定する項目

論理サーバの種類 | 項目 | param-nameの指定値
J2EEサーバ※1 | 管理用サーバのポート番号 | ejbserver.http.port
ajp13のポート番号 | webserver.connector.ajp13.port
RMIレジストリのポート番号 | ejbserver.rmi.naming.port
httpsのポート番号 | webserver.connector.redirect_https.port
インプロセスのネーミングサービス用のポート番号 | ejbserver.naming.port
インプロセスのHTTPサーバのポート番号 | webserver.connector.inprocess_http.port
JTAリカバリの固定ポート番号 | ejbserver.distributedtx.recovery.port
パフォーマンストレーサ | PRF識別子 | PRFID
スマートエージェント | スマートエージェントが監視するポート番号 | smartagent.port
CTMドメインマネジャ | CTMドメインマネジャが属するCTMドメイン名 | ctmdomname
CTM実行環境ディレクトリ | ctmspool
CTMドメインマネジャがCTMドメイン構成情報を交換するために使用するポート番号 | cdm.port
CTM | CTMの識別子 | ctmid※2
CTMが使用するポート番号 | ctm.port
CTMと対となるネーミングサービスのポート番号 | ctm.ns.port

注※1　バッチサーバは論理J2EEサーバとして定義します。

注※2　ctmidの設定は省略できます。省略時は，ホスト間で一意になるようにManagement Serverで自動的に設定されます。ctmidの省略値については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.18　論理CTMで指定できるパラメタ」を参照してください。

参考

1台のサーバマシン内にある複数のサービスユニットを同時に起動しない運用をする場合は，各サービスユニットの同じ種類の論理サーバに同じ値を設定できます。

サーバマシンに配置するサービスユニットが属するWebシステムによって，これらの設定項目をどの定義のコンフィグレーションで指定するかが異なります。

同じWebシステムのサービスユニットを1台のサーバマシンに配置する場合
各サービスユニットの論理サーバ定義（<define-server>タグ）内の<configuration>タグで指定します。

異なるWebシステムのサービスユニットを1台のサーバマシンに配置する場合
各Webシステムの物理ティア定義（<tier>タグ）内の<configuration>タグで指定します。

1台のサーバマシン内に複数のサービスユニットを配置する場合の構成情報の例を，次の図に示します。この例では，1台のサーバマシンにサービスユニット1とサービスユニット2を配置して，複数の業務をそれぞれサービスユニットに対応させています。

図10-10　1台のサーバマシン内に複数のサービスユニットを配置する場合の構成情報の例

図10-10の構成情報に従って，簡易構築定義ファイルを作成します。複数の業務をそれぞれサービスユニットに対応させているため，サービスユニット1およびサービスユニット2は別のWebシステムとして簡易構築定義ファイルに定義します。また，簡易構築定義ファイルで表10-10に示す項目が，サービスユニット1と定義が重複しないように，サービスユニット2の設定を変更してください。

MyWebSystemDef.xmlの作成例を次に示します。

MyWebSystemDef.xmlファイル

 <!-- Webシステム1の属性定義 -->
 <web-system>
   <name>MyWebSystem1</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>batch.service.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>use.security</param-name>
          <param-value>false</param-value>
       </param>
       <param>
          <param-name>add.jvm.arg</param-name>
          <param-value>-XX:-HitachiUseExplicitMemory</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit1</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
       <define-server>
         <logical-server-name>BatchServer01</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
       </define-server>
       <define-server>
         <logical-server-name>PRF01</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- Webシステム2の属性定義 -->
 <web-system>
   <name>MyWebSystem2</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>batch.service.enabled</param-name>
          <param-value>true</param-value>
       </param>
       <param>
          <param-name>use.security</param-name>
          <param-value>false</param-value>
       </param>
       <param>
          <param-name>add.jvm.arg</param-name>
          <param-value>-XX:-HitachiUseExplicitMemory</param-value>
       </param>
       <!-- 管理用サーバのポート番号 -->
       <param>
         <param-name>ejbserver.http.port</param-name>
         <param-value>8081</param-value>
       </param>
       <!-- ajp13のポート番号 -->
       <param>
         <param-name>webserver.connector.ajp13.port</param-name>
         <param-value>8008</param-value>
       </param>
       <!-- RMIレジストリのポート番号 -->
       <param>
         <param-name>ejbserver.rmi.naming.port</param-name>
         <param-value>23153</param-value>
       </param>
       <!-- インプロセスのネーミングサービス用のポート番号 -->
       <param>
         <param-name>ejbserver.naming.port</param-name>
         <param-value>901</param-value>
       </param>
       <!-- JTAリカバリの固定ポート番号 -->
       <param>
         <param-name>ejbserver.distributedtx.recovery.port</param-name>
         <param-value>20312</param-value>
       </param>
     </configuration>
     <configuration>
       <logical-server-type>performance-tracer</logical-server-type>
       <!-- PRF識別子 -->
       <param>
         <param-name>PRFID</param-name>
         <param-value>PRF_ID2</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     <name>unit2</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>
       <hosts-for>j2ee-tier</hosts-for>
       <define-server>
         <logical-server-name>BatchServer02</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
       </define-server>
       <define-server>
         <logical-server-name>PRF02</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   <host-name>apsv1</host-name>
   <agent-host>192.168.100.11</agent-host>
 </host>
</model-definition>

注1　太字の部分が編集部分です。作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注2　バッチサーバの場合，負荷分散機を使用しません。このため，テンプレートにある<load-balancer>タグの記述は削除してください。

(2)　JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成

JP1/SC/DPMを利用してシステムを構築する場合は，簡易構築定義ファイルの物理ティアの定義で，バッチサーバのコンフィグレーション（<configuration>タグ）の設定が必要になります。

JP1/SC/DPMを利用してシステムを構築する場合に，物理ティアの定義で設定が必要なパラメタを次の表に示します。なお，この表に示すパラメタは，選定した構成定義パターンで定義する論理サーバで設定してください。

表10-11　JP1/SC/DPMを利用してシステムを構築する場合に，物理ティアの定義で設定が必要なパラメタ

論理サーバの種類（<tier>タグ配下の<logical-server-type>タグの指定値） | <param-name>タグの指定値 | <param-value>タグの指定値
j2ee-server | realservername | 実サーバ名
webserver.connector.http.bind_host.value※ | true
webserver.connector.ajp13.bind_host.value※ | true
manager.mevent.sender.bind.host.value※ | true
vbroker.se.iiop_tp.host.value※ | true
mngagent.connector.host.value※ | true

注※　Management Serverが稼働するホスト（サーバマシン）が，複数個のIPアドレスを持っている構成の場合に設定が必要です。

10.9　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先

アプリケーションサーバの機能をSmart Composer機能で構築するシステムで使用する場合，機能を有効にするための設定が必要なときがあります。ここでは，Smart Composer機能で使用できるアプリケーションサーバの機能について説明します。なお，アプリケーションサーバで使用している機能の詳細や，機能を有効にするための設定については，参照先マニュアルを参照してください。

Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先（参照先マニュアルおよび参照個所）を次の表に示します。なお，参照先マニュアルでは，マニュアル名称の「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

表10-12　Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先（バッチアプリケーションを実行するシステム）

項番 | Smart Composer機能で使用できるアプリケーションサーバの機能 | 参照先マニュアル | 参照個所
1 | EJBコンテナの機能 | Enterprise Beanの実行 | 基本・開発編(EJBコンテナ) | 2.2
2 | EJB仕様準拠のチェック | 2.3
3 | CMPフィールドとデータ型のマッピング | 2.4
4 | EJBコンテナのJNDI名前空間へのリファレンス登録 | 2.5
5 | 外部リソースとの接続 | 2.6
6 | Enterprise Beanでのトランザクション管理 | 2.7
7 | Entity Beanのキャッシュモデル（コミットオプション指定） | 2.8
8 | Stateless Session Bean，Entity Beanのプールの管理 | 2.9
9 | Enterprise Beanへのアクセス制御 | 2.10
10 | EJBコンテナでのタイムアウトの設定※1 | 2.11
11 | EJBのリモートインタフェースの呼び出し | 2.13
12 | Enterprise Beanの呼び出し | 3.4
13 | EJBクライアントアプリケーションでのトランザクションの実装 | 3.5
14 | RMI-IIOPスタブ，インタフェースの取得 | 3.7
15 | ネーミング管理の機能 | JNDI名前空間へのオブジェクトのバインドとルックアップ | 基本・開発編(コンテナ共通機能) | 2.3
16 | Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）※2 | 2.4
17 | ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | 2.5
18 | ネーミング管理機能でのキャッシング | 2.6
19 | CORBAネーミングサービスの切り替え | 2.8
20 | リソース接続とトランザクション管理の機能 | コネクションプーリング | 3.14.1
21 | コネクションプールのウォーミングアップ | 3.14.2
22 | コネクションプール数調節機能 | 3.14.2
23 | コネクションシェアリング・アソシエーション※3 | 3.14.3
24 | ステートメントプーリング | 3.14.4
25 | ライトトランザクション | 3.14.5
26 | DataSourceオブジェクトのキャッシング | 3.14.7
27 | DB Connectorのコンテナ管理でのサインオンの最適化 | 3.14.8
28 | コネクションの障害検知 | 3.15.1
29 | コネクション枯渇時のコネクション取得待ち | 3.15.2
30 | コネクションの取得リトライ | 3.15.3
31 | コネクションプールの情報表示 | 3.15.4
32 | コネクションプールのクリア | 3.15.5
33 | トランザクションタイムアウトとステートメントキャンセル | 3.15.8
34 | 障害調査用SQLの出力 | 3.15.10
35 | オブジェクトの自動クローズ | 3.15.11
36 | コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示） | 3.17
37 | リソースへの接続テスト | 3.18
38 | コンテナ拡張ライブラリの機能 | コンテナ拡張ライブラリ | 13.3
39 | サーバ起動・停止フック機能 | 13.4
40 | スマートエージェント経由でのCORBAオブジェクトの呼び出し | 13.5
41 | バッチアプリケーション実行時に使用する機能 | バッチアプリケーション実行機能 | 拡張編 | 2.3
42 | ガーベージコレクション制御機能 | 2.9
43 | CTMによるEnterprise Beanのスケジューリング機能 | リクエストの流量制御 | 3.4
44 | リクエストの閉塞制御 | 3.7
45 | リクエストの負荷分散 | 3.8
46 | リクエストのキューの滞留監視 | 3.9
47 | そのほかの拡張機能 | バッチアプリケーションのスケジューリング | 4章
48 | 明示管理ヒープ機能を使用したフルガーベージコレクションの抑止 | 8章
49 | 複数の構築済み実行環境の切り替え | 11章
50 | ユーザログ出力 | 12章
51 | システムの日常運用を支援する機能 | システムの起動・停止 | 運用／監視／連携編 | 2章
52 | 稼働情報の監視（稼働情報収集機能） | 3章
53 | リソースの枯渇監視 | 4章
54 | 運用管理コマンドによる稼働情報の出力 | 8章
55 | Managementイベントの通知とManagementアクションによる処理の自動実行 | 9章
56 | CTMの稼働統計情報の収集 | 10章
57 | システムの保守を支援する機能 | コンソールログの出力 | 11章
58 | システムの監査を支援する機能 | 監査ログの出力機能 | 6章
59 | データベース監査証跡連携機能 | 7章
60 | JP1連携による運用管理機能 | JP1と連携したシステムの運用 | 12章
61 | システムの構成定義および管理（JP1/IM - CMとの連携） | 13章
62 | システムの集中監視（JP1/IMとの連携） | 14章
63 | ジョブによるシステムの自動運転（JP1/AJSとの連携） | 15章
64 | シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携） | 16章
65 | 監査ログの収集および一元管理（JP1/NETM/Auditとの連携） | 17章
66 | クラスタソフトウェアとの連携による系切り替え機能 | 相互系切り替えシステム | 20章
67 | ホスト単位管理モデルを対象にした系切り替えシステム | 22章
68 | システムの保守のための機能 | トラブルシューティング | 保守／移行／互換編 | 2章，3章，4章，5章
69 | 性能解析トレースを使用したシステムの性能解析 | 6章，7章
70 | 日立固有のJavaVMの機能 | クラス別統計機能 | 8.3
71 | インスタンス統計機能 | 8.4
72 | STATICメンバ統計機能 | 8.5
73 | 参照関係情報出力機能 | 8.6
74 | 統計前のガーベージコレクション選択機能 | 8.7
75 | Tenured領域内不要オブジェクト統計機能 | 8.8
76 | Tenured増加要因の基点オブジェクトリスト出力機能 | 8.9
77 | クラス別統計情報解析機能 | 8.10
78 | Survivor領域の年齢分布情報出力機能 | 8.11
79 | ファイナライズ滞留解消機能 | 8.12
80 | hndlwrap機能 | 8.13
81 | JITコンパイル時のCヒープ確保量の上限値設定機能 | 8.14
82 | スレッド数の上限値設定機能 | 8.15
83 | 旧バージョンの製品から移行するための機能 | 旧バージョンのアプリケーションサーバからの移行 | 12章
84 | 旧バージョンの製品との互換のための機能 | Cosminexus DABroker Libraryを使用したデータベース接続 | 11章

注※1　RMI-IIOP通信のタイムアウトだけ使用できます。

注※2　J2EEリソースへの別名付与が使用できます。Enterprise Beanへの別名付与は使用できません。

注※3　コネクションシェアリングが使用できます。コネクションアソシエーションは使用できません。

10.10　障害に対応したシステムの構築

障害に対応したシステムとして，ここでは，サービスユニットを自動再起動するシステムの構築について説明します。

＜この節の構成＞

10.10.1　サービスユニットを自動再起動するための設定

10.10.1　サービスユニットを自動再起動するための設定

アプリケーションサーバでは，システムに障害が発生しそうな場合の動作をManagementアクションで定義できます。ManagementアクションにSmart Composer機能のコマンドを定義しておくことで，システムの運用中に障害が発生しそうな場合にサービスユニットを自動再起動できるため，迅速な障害対応ができます。

障害の発生しそうな状況になるとManagementイベントが発行されます。障害の発生しそうな状況は，例えばリソース枯渇監視機能でリソースの枯渇を事前に検知できます。そのManagementイベントと対応づけたManagementアクションを実行し，障害が発生しそうなサービスユニットを自動的に再起動して，障害の発生を事前に回避します。Managementアクションによるサービスユニットの自動再起動処理を次の図に示します。

図10-11　Managementアクションによるサービスユニットの自動再起動処理

Smart Composer機能を使用すると，JavaVMのフルガーベージコレクションやスレッドなどのリソース枯渇を事前検知した場合，問題の発生したサービスユニットを自動再起動できます。

例として，バッチサーバのフルガーベージコレクションの予兆を検知した場合に，Managementアクションを使用してサービスユニットを自動再起動する方法について説明します。必要な操作は次のとおりです。

Managementアクション実行コマンドの作成

Managementイベントの発行の設定

Managementイベント発行用メッセージIDリストファイルおよびリソース監視機能の設定

Managementアクション実行用プロパティファイルの設定

それぞれの操作の概要を説明します。

なお，リソース枯渇監視機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.　リソースの枯渇監視」を参照してください。Managementアクションの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.2　Managementイベントの通知とManagementアクションの概要」を参照してください。設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.4　Managementイベントによる処理の自動実行の設定」を参照してください。

●Managementアクション実行コマンドの作成

JavaVMのフルガーベージコレクションやスレッドなどのリソース枯渇を事前検知した場合，Managementイベントが発行されます。ここでは，Managementイベントを受信したときにManagement Serverが実行するManagementアクション実行コマンドの作成について説明します。

バッチサーバでフルガーベージコレクションの予兆を検知した場合に，サービスユニットを再起動するManagementアクション実行コマンドを作成します。

障害の発生したバッチサーバを含むサービスユニットを自動閉塞します。

障害の発生したバッチサーバを再起動します。

サービスユニットを開始します。

Managementアクション実行コマンドのサンプルファイルをコピーして，Managementアクション実行コマンド（バッチファイルまたはシェルスクリプト）を作成してください。Managementアクション実行コマンドの作成方法はJ2EEサーバの場合と同じです。詳細は，「8.13.2(1)　Managementアクション実行コマンドの作成」を参照してください。

●Managementイベントの発行の設定

バッチサーバのManagementイベントの発行が有効になっていない場合は，Managementイベントの発行を有効にします。Managementイベントの発行を有効にするには，次の手順で設定を変更してください。

簡易構築定義ファイルの編集

システムの設定の一括変更

Managementイベントの発行の設定については，J2EEサーバの場合と同じです。設定方法については，「8.13.2(2)　Managementイベントの発行の設定」を参照してください。

●Managementイベント発行用メッセージIDリストファイルおよびリソース枯渇監視機能の設定

Managementイベントを発行するために，Managementイベント発行用メッセージIDリストファイルの設定や，リソース枯渇監視機能の設定が必要な場合があります。

通常はデフォルトのまま使用するため，設定の必要はありません。必要に応じて設定してください。

なお，Managementイベント発行用メッセージIDリストファイルやリソース枯渇監視機能の設定については，「8.13.2(3)　Managementイベント発行用メッセージIDリストファイルおよびリソース枯渇監視機能の設定」を参照してください。

●Managementアクション実行用プロパティファイルの設定

Managementアクションの定義，メッセージIDとManagementアクションとのマッピングなどは，Managementアクション実行用プロパティファイル（maction.properties）に定義します。maction.propertiesファイルの設定については，「8.13.2(4)　Managementアクション実行用プロパティファイルの設定」を参照してください。

ただし，バッチサーバの場合は，Managementアクション実行用プロパティファイル（maction.properties）の下記のプロパティ名について，下線部の「combined-tier」を「j2ee-tier」に置き換えてお読みください。

# Mapping of Logical server and Management actions.
maction.tier.MyWebSystem.combined-tier.mactions=restart_unit

11.　バッチアプリケーションを実行するシステムの運用

この章では，バッチアプリケーションを実行するシステムの運用について説明します。

なお，J2EEアプリケーションを実行するシステムと共通する記述を参照している場合は，参照先の記述にある「J2EEサーバ」を「バッチサーバ」に置き換えてお読みください。

＜この章の構成＞

11.1　システムの運用の概要

11.2　日常運用の操作

11.3　システムの設定変更

11.4　システムのスケールアウトとスケールイン

11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

11.6　構築済みのシステムの移行

11.7　トラブルへの対処

11.8　システムの削除

11.1　システムの運用の概要

ここでは，システムの運用で使用する機能，アプリケーションサーバで実行できる運用作業について説明します。また，アプリケーションサーバで実行できる運用作業のうち，Smart Composer機能を使用して実行できる運用作業についても説明します。

＜この節の構成＞

11.1.1　システムの運用で使用する機能

11.1.2　アプリケーションサーバで実行できる運用作業

11.1.3　Smart Composer機能を使用した運用作業

11.1.4　システムの運用を始める前に

11.1.1　システムの運用で使用する機能

ここでは，システムの運用で使用する機能の概要について説明します。システムの運用で使用する機能には，サーバプロセスを操作する機能と，リソースを操作する機能の二つがあります。それぞれの機能の概要について次に説明します。

＜この項の構成＞

(1)　サーバプロセスを操作する機能

(2)　リソースを操作する機能

(3)　バッチアプリケーションを操作する機能

(1)　サーバプロセスを操作する機能

サーバプロセスを操作する機能について説明します。

●Smart Composer機能のコマンド（cmx_で始まるコマンド）

Smart Composer機能で構築したシステムに対して，Webシステム単位，サービスユニット単位に運用操作を実行するコマンドです。

●運用管理コマンド（mngsvrutil）

Management Serverの運用管理の対象となる，論理サーバの運用操作を実行するコマンドです。

●運用管理ポータル

Webブラウザに表示されるポータル画面を通して，Management Serverの運用管理の対象となる論理サーバの運用操作を実行する機能です。

●バッチサーバを操作するコマンド

バッチサーバを起動，停止するためのコマンドです。cjstartsvコマンド，およびcjstopsvコマンドがあります。

●CTMのコマンド

バッチアプリケーションの実行をスケジューリングするための機能を提供している，CTMを操作するためのコマンドです。CTMは，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

●PRFのコマンド

システムの処理性能を解析するときに使用する，性能解析トレース情報を編集してファイルに出力したり，PRFトレースファイルの取得レベルを設定したりするコマンドです。

(2)　リソースを操作する機能

●サーバ管理コマンド

バッチサーバで管理しているリソースの設定をするためのコマンドです。

参考

運用管理ポータルを使用してもリソースを操作できます。運用管理ポータルを使用したリソースの操作については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「12.　論理サーバのアプリケーション管理」を参照してください。

(3)　バッチアプリケーションを操作する機能

●バッチアプリケーション実行機能のコマンド

バッチアプリケーションを開始，強制停止，一覧表示するためのコマンドです。cjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンドがあります。

11.1.2　アプリケーションサーバで実行できる運用作業

バッチアプリケーションを実行するシステムでは次に示す運用作業を実施できます。

システムの起動と停止

システムの運用監視

システムの処理性能解析

リソースの管理

システムの監査

システムの変更

システム環境の移行

トラブルシューティング

これらの作業を実行するには，主に次の手段を使用します。

Smart Composer機能のコマンドを使用する

運用管理コマンド（mngsvrutil）を使用する

サーバ管理コマンドを使用する

ここでは，運用作業ごとに，アプリケーションサーバで推奨する手段について説明しています。ここで説明している手段以外で運用したい場合は，「付録E　代替手段で実行できる運用作業」を参照してください。

＜この項の構成＞

(1)　システムの起動と停止で実行できる作業

(2)　システムの運用監視で実行できる作業

(3)　システムの処理性能解析で実行できる作業

(4)　リソースの管理で実行できる作業

(5)　システムの監査で実行できる運用作業

(6)　システムの変更で実行できる運用作業

(7)　システム環境の移行で実行できる運用作業

(8)　トラブルシューティングで実行できる作業

(1)　システムの起動と停止で実行できる作業

システムの起動と停止で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-1　システムの起動と停止で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
サービスユニットを一括起動します。 | 不要 | － | コマンド編 | cmx_start_target（Webシステムまたはサービスユニットの開始） | Smart Composer機能のコマンド（cmx_start_target）
サービスユニットを一括停止します。 | 不要 | － | コマンド編 | cmx_stop_target（Webシステムまたはサービスユニットの停止） | Smart Composer機能のコマンド（cmx_stop_target）
クラスタソフトウェアを使用したシステムを起動・停止します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 18章 | アプリケーションサーバのコマンド，クラスタソフトウェアの機能

（凡例）

必要：運用前の設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

(2)　システムの運用監視で実行できる作業

システムの運用監視で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-2　システムの運用監視で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
サービスユニットのステータス，およびWebシステムに関連づいていない論理サーバを確認します。 | 不要 | － | コマンド編 | cmx_list_status（サービスユニット状況の表示） | Smart Composer機能のコマンド（cmx_list_status）
論理サーバのステータスを確認します。 | 不要 | － | 運用／監視／連携編 | 2.5.2 | 運用管理コマンド（mngsvrutil）
Webシステム内のサービスユニットの構成，およびWebシステムに関連づいていない論理サーバの一覧を確認します。 | 不要 | － | コマンド編 | cmx_list_model（Webシステムの情報モデルの取得） | Smart Composer機能のコマンド（cmx_list_model）
稼働情報ファイルを参照して，バッチサーバの稼働情報を監視します。 | 省略可 | 運用／監視／連携編 | 運用／監視／連携編 | 3章 | －
運用管理コマンドを使用して，バッチサーバの稼働情報を監視します。 | 不要 | － | 運用／監視／連携編 | 8章 | 運用管理コマンド（mngsvrutil）
リソースの使用率や使用数を監視して，しきい値を超えた場合に原因を調査します。 | 省略可 | 運用／監視／連携編 | 運用／監視／連携編 | 4章 | －
稼働情報ファイルに出力される稼働情報，またはリソースの枯渇状況に応じてメッセージが出力された場合の処理を自動化します（Managementアクション）。 | 必要 | 6.2.2(2)，運用／監視／連携編 | 運用／監視／連携編 | 9章 | －
CTMの稼働統計情報を出力します。※ | 不要 | － | 運用／監視／連携編 | 10章 | 運用管理コマンド（mngsvrutil）
バッチサーバ上のバッチアプリケーション情報を一覧で出力します。 | 不要 | － | 拡張編 | 4.5.4 | バッチ一覧表示コマンド（cjlistjob）

（凡例）

必要：運用前の設定が必要です。

省略可：デフォルトの設定で使用できるため，運用前の設定は省略できます。この動作をデフォルトから変更する場合は設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

拡張編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」を示します。

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

(3)　システムの処理性能解析で実行できる作業

システムの処理性能解析で実行できる作業について，次の表に示します。

表11-3　システムの処理性能解析で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
性能解析トレースファイルを収集します。 | 不要 | － | 保守／移行／互換編 | 6.3 | 運用管理コマンド（mngsvrutil）
収集した性能解析トレースファイルを利用してシステムの処理性能を解析します。 | 不要 | － | 保守／移行／互換編 | 6.6 | －

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

(4)　リソースの管理で実行できる作業

リソースの管理で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-4　リソースの管理で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
コネクションプールの情報を表示します。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.15.4 | サーバ管理コマンド（cjlistpool）
コネクションプールをクリアします。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.15.5 | サーバ管理コマンド（cjclearpool）
クラスタ構成のデータベースをメンテナンスします。 | 不要 | － | 基本・開発編(コンテナ共通機能) | 3.17.4 | サーバ管理コマンド（cjlistrar，cjsuspendpool，cjresumepool）
リソースの接続テストをします。 | 必要 | 基本・開発編(コンテナ共通機能) | 基本・開発編(コンテナ共通機能) | 3.18 | サーバ管理コマンド（cjtestres）

（凡例）

必要：運用前の設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

基本・開発編(コンテナ共通機能)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を示します。

(5)　システムの監査で実行できる運用作業

監査ログを使用したシステムの監査，およびデータベース監査証跡と連携した運用で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-5　システムの監査で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
監査ログを出力して，管理します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 6章 | －
監査ログを収集して調査します。 | 必要 | 運用／監視／連携編 | 運用／監視／連携編 | 17章 | －
データベース監査証跡に出力された情報を基に，データベースにアクセスしたリクエストの情報を特定します。 | 不要 | － | 運用／監視／連携編 | 7章 | －

（凡例）

必要：運用前の設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

(6)　システムの変更で実行できる運用作業

システムの変更で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-6　システムの変更で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先 | 手段
設定変更 | システム全体の設定を一括で変更します。 | 不要 | － | 11.3 | －
構成変更 | システムをスケールアウトします。 | 不要 | － | 11.4.1，11.5 | －
システムをスケールインします。 | 不要 | － | 11.4.2，11.5 | －
削除 | システムを削除します。 | 不要 | － | 11.8 | －

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

(7)　システム環境の移行で実行できる運用作業

システム環境の移行で実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-7　システム環境の移行で実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先 | 手段
構築済みのシステムの環境を移行します。 | 不要 | － | 11.6 | Smart Composer機能のコマンド（cmx_export_model）

（凡例）

不要：運用前の設定は不要です。

－：該当しません。

(8)　トラブルシューティングで実行できる作業

トラブルシューティングで実行できる作業について，次の表に示します。なお，システムで実行できる運用作業には，運用前に設定が必要なものもあります。

表11-8　トラブルシューティングで実行できる作業

運用作業 | 運用前の設定の要否 | 運用前の設定方法の参照先 | 運用方法
参照先マニュアル | 参照個所 | 手段
トラブルシューティングに必要な資料を収集します。 | 必要／省略可 | 6.2.2(1)，保守／移行／互換編 | 保守／移行／互換編 | 2.3 | 運用管理コマンド（mngsvrutil）
論理サーバ（構成ソフトウェアのサーバプロセス）に異常が発生した場合の処理を自動化します。 | 省略可 | 保守／移行／互換編 | 保守／移行／互換編 | 2.2.2 | －
トラブルシューティングに必要な資料を調査します。 | 不要 | － | 保守／移行／互換編 | 5章 | －

（凡例）

必要：運用前の設定が必要です。

省略可：デフォルトの設定で使用できるため，運用前の設定は省略できます。この動作をデフォルトから変更する場合は設定が必要です。

不要：運用前の設定は不要です。

－：該当しません。

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

11.1.3　Smart Composer機能を使用した運用作業

ここでは，Smart Composer機能を使用した運用操作について説明します。そのほかの運用作業については，「11.1.2　アプリケーションサーバで実行できる運用作業」を参照してください。

Smart Composer機能を使用した運用操作では，一括起動・一括停止の日常運用の操作，スケールインやスケールアウト，環境の移行や削除などが実施できます。ここでは，次に示す運用操作の手順を説明しています。

日常運用（11.2参照）

サービスユニットの一括起動

サービスユニットの一括停止

システムの設定変更（11.3参照）

システムの構成変更

システムのスケールアウト（11.4.1，および11.5参照）

システムのスケールイン（11.4.2および11.5参照）

構築済みのシステムの移行（11.6参照）

システムの削除（11.8参照）

それぞれの運用の概要については，「6.2.1　運用設計」を参照してください。また，Smart Composer機能のコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「8.　Smart Composer機能で使用するコマンド」を参照してください。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「3.　バッチサーバで使用するコマンド」を参照してください。

11.1.4　システムの運用を始める前に

Component Container管理者による運用に関する留意事項や，各コマンドを利用する場合の留意事項など，システムの運用を始める前に確認，準備しておくことがあります。確認が必要な留意事項や注意事項などの詳細については，「9.2　システムの運用を始める前に」を参照してください。

11.2　日常運用の操作

Smart Composer機能では，日常運用の操作として，システムの一括起動および一括停止がサービスユニット単位で実施できます。システム内のすべてのサービスユニットを一括で起動および停止することも，特定のサービスユニットだけを一括で起動および停止することもできます。

＜この節の構成＞

11.2.1　すべてのサービスユニットの一括起動と一括停止

11.2.2　サービスユニット単位の一括起動と一括停止

11.2.1　すべてのサービスユニットの一括起動と一括停止

一括起動をするにはcmx_start_targetコマンドを，一括停止をするには，cmx_stop_targetコマンドを使用します。システム内のすべてのサービスユニットを一括起動したり，一括停止したりするには，これらのコマンドを使用するときに，-unitオプションの指定を省略します。

ここでは，システム内のすべてのサービスユニットを，一括起動および一括停止する手順について説明します。なお，説明では，バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルを使用して，「10.4　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　一括起動

(2)　一括停止

(1)　一括起動

システム内のすべてのサービスユニットを一括で起動するときの手順を次に示します。システム内のすべてのサービスユニットを稼働状態にするには，-modeオプションに「ALL」を指定します。

Management Serverと運用管理エージェントが稼働しているかどうかを確認します。
mngsvrctlコマンドの引数checkを使用して，Management Serverと運用管理エージェントが稼働しているかどうかを確認します。Management Serverの稼働状態を確認する場合は「mngsvr」を，運用管理エージェントの稼働状態を確認する場合は「adminAgent」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
# /opt/Cosminexus/manager/bin/mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent

システム内のすべてのサービスユニットを一括起動します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを稼働状態で起動します。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

リソースアダプタが停止している場合は，サービスユニットを起動したあとで開始する必要があります。リソースアダプタを開始するには，cjstartrarコマンドを使用します。リソースアダプタの開始については，「10.6.2　リソースアダプタのインポートと開始」を参照してください。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。

cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

(2)　一括停止

システム内のすべてのサービスユニットを一括で停止するときの手順を次に示します。システム内のすべてのサービスユニットを停止状態にするには，-modeオプションに「ALL」を指定します。

システム内のすべてのサービスユニットを一括停止します。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを停止状態にします。このとき，コマンドの-modeオプションに「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

参考

サービスユニットを一括停止すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

11.2.2　サービスユニット単位の一括起動と一括停止

一括起動をするにはcmx_start_targetコマンドを，一括停止をするにはcmx_stop_targetコマンドを使用します。特定のサービスユニットを一括起動したり，一括停止したりするには，これらのコマンドを使用するときに，-unitオプションにサービスユニット名を指定します。

ここでは，特定のサービスユニットだけを，一括起動および一括停止する手順について説明します。なお，説明では，バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルを使用して，「10.4　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　一括起動

(2)　一括停止

(1)　一括起動

特定のサービスユニットを一括で起動するときの手順を次に示します。特定のサービスユニットを稼働状態にするには，起動対象のサービスユニット名と，-modeオプションに「ALL」を指定します。

Management Serverと運用管理エージェントが稼働しているかどうかを確認します。
mngsvrctlコマンドの引数checkを使用して，Management Serverと運用管理エージェントが稼働しているかどうかを確認します。Management Serverの稼働状態を確認する場合は「mngsvr」を，運用管理エージェントの稼働状態を確認する場合は「adminAgent」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
<Cosminexusのインストールディレクトリ>¥manager¥bin¥mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent

UNIXの場合

# /opt/Cosminexus/manager/bin/mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd check mngsvr
# /opt/Cosminexus/manager/bin/mngsvrctl -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -t apsv1 check adminAgent

起動対象のサービスユニットを起動します。
cmx_start_targetコマンドを使用して，サービスユニット「unit1」を稼働状態で起動します。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

リソースアダプタが停止している場合は，サービスユニットを起動したあとで，開始する必要があります。リソースアダプタを開始するには，cjstartrarコマンドを使用します。リソースアダプタの開始については，「10.6.2　リソースアダプタのインポートと開始」を参照してください。

参考

サービスユニットを一括起動すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の昇順に従って起動されます。

cmx_start_targetコマンドに-strictオプションを指定すると，論理サーバの起動に失敗した場合に，サービスユニットの一括起動処理を中断できます。cmx_start_targetコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_start_target（Webシステムまたはサービスユニットの開始）」を参照してください。

(2)　一括停止

特定のサービスユニットを一括で停止するときの手順を次に示します。特定のサービスユニットを停止状態にするには，停止対象のサービスユニット名と，-modeオプションに「ALL」を指定します。

停止対象のサービスユニットを停止します。
cmx_stop_targetコマンドを使用して，サービスユニット「unit1」を停止状態にします。このとき，コマンドの-modeオプションには「ALL」を指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit1

サービスユニット「unit1」内のすべての論理サーバが停止されます。

参考

サービスユニットを一括停止すると，サービスユニットを構成する論理サーバは，論理サーバごとに設定した起動順序の降順に従って停止されます。

11.3　システムの設定変更

Smart Composer機能では，システム全体の設定を変更できます。ここでは，システム全体の設定変更について説明します。

注意

システムを構築したあとにシステムを構成変更する場合は，構成変更定義ファイルを使用してください。簡易構築定義ファイルを編集しても，システムは構成変更できません。

＜この節の構成＞

11.3.1　システムの設定の一括変更

11.3.1　システムの設定の一括変更

Smart Composer機能を使用して，システムの設定を一括変更できます。設定を変更するには，次の内容を実施します。

簡易構築定義ファイルの編集

設定の一括変更

注意

バッチアプリケーションを実行するシステムの設定を変更する場合，次のパラメタの値は変更しないでください。

batch.service.enabled（バッチサーバの拡張パラメタ）
詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.14.8　バッチサーバの拡張パラメタ」を参照してください。

use.security（SecurityManagerの使用を設定するパラメタ）
詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.14.12　SecurityManagerの使用を設定するパラメタ」を参照してください。

システムの設定の一括変更の手順について説明します。なお，説明では，バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルを使用して，「10.4　システムの一括構築」で構築したシステムを使用します。

＜この項の構成＞

(1)　簡易構築定義ファイルの編集

(2)　設定の一括変更

(1)　簡易構築定義ファイルの編集

システム構築で使用した簡易構築定義ファイルの内容を編集します。

システム構築で使用した簡易構築定義ファイルを編集します。
ここでは，サーバの稼働性能を監視するように設定します。
設定後のMyWebSystemDef.xmlファイルを次に示します。

<!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
   <!-- 物理ティアの定義 -->
   <tier>
     <tier-type>j2ee-tier</tier-type>
     <!-- バッチサーバの稼働性能監視を行う設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>batch.service.enabled</param-name>※
          <param-value>true</param-value>※
       </param>
       <param>
          <param-name>use.security</param-name>※
          <param-value>false</param-value>※
       </param>
       <param>
         <param-name>ejbserver.instrumentation.enabled</param-name>
         <param-value>true</param-value>
       </param>
     </configuration>
   </tier>
   <!-- サービスユニットの定義 -->
   <unit>
     ：
   </unit>
 </web-system>
 <!-- ホストの定義 -->
 <host>
   ：
 </host>
 </web-system>
</model-definition>

注　太字の部分が編集部分です。

注※　パラメタの値を変更しないでください。

なお，作成例で使用しているタグおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　設定の一括変更

変更した簡易構築定義ファイルの内容を基に，システムの設定を一括で変更します。

システムが稼働している場合は，システムを停止します（必要に応じて）。
cmx_stop_targetコマンドを使用して，システム内のすべてのサービスユニットを一括停止します。このとき，コマンドの-modeオプションに「ALL」を指定して，停止状態にします。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem -mode ALL

変更した簡易構築定義ファイルの内容を実際のシステムに展開します。
cmx_build_systemコマンドに-changeオプションを指定して，(1)で変更した簡易構築定義ファイルの内容をシステムに適用します。-fオプションには，(1)で作成した簡易構築定義ファイルを指定します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml -change

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f MyWebSystemDef.xml -change

システムを開始します。
cmx_start_targetコマンドを使用して，システム内のすべてのサービスユニットを一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

11.4　システムのスケールアウトとスケールイン

Smart Composer機能を使用すると，業務全体を停止することなく，システムの構成を変更できます。システムの規模を拡張する場合は，システムをスケールアウトします。また，システムの規模を縮小する場合は，システムをスケールインします。

注意

CTMを使用するパターン（ctm-tier）のシステムでは，スケールアウトおよびスケールインを実施できません。

なお，追加するアプリケーションサーバのセットアップに，JP1/SC/DPMのディスク複製OSインストール機能を利用することもできます。この機能を利用すると，すでに稼働しているホストの環境を複製して，新規に作成するホストに対してOSや必要なアプリケーションのインストール，および環境設定が一括で操作できます。JP1/SC/DPMを利用する場合の，システムのスケールアウトの手順については，「11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン」を参照してください。

＜この節の構成＞

11.4.1　システムのスケールアウト

11.4.2　システムのスケールイン

11.4.1　システムのスケールアウト

ここでは，システムをスケールアウトする手順について説明します。

システムをスケールアウトするには，次の内容を実施します。

構成変更定義ファイルの作成

システムの情報モデルの変更

サービスユニットの追加

システムのスケールアウトの手順について説明します。

ここでは，既存のサーバマシンに，次に示すサービスユニットを追加する場合を例にして，説明しています。なお，説明では，バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルを使用して，「10.4　システムの一括構築」で構築したシステムを使用します。

ホスト名：apsv1

サービスユニット名：unit3

バッチサーバの論理サーバ名：BatchServer03

パフォーマンストレーサの論理サーバ名：PRF03

参考

サーバ管理コマンドの指定値について

サーバ管理コマンドの引数に指定するサーバ名

サーバ管理コマンドの引数に指定するサーバ名は実サーバ名です。構成変更定義ファイルに実サーバ名を設定していない場合，実サーバ名は論理サーバ名と同じです。論理サーバ名は，構成変更定義ファイルのサービスユニットの定義内に，<logical-server-name>タグで指定している値です。

なお，論理サーバ名の設定を省略している場合，論理サーバ名は「cmx_<Webシステム名>_<サービスユニット名>_<種別>_<通番>」の形式で定義されます。バッチサーバの場合，<種別>には「J2EE」と表示されます。論理サーバの種類と<種別>との対応を次の表に示します。

表11-9　論理サーバの種類と<種別>との対応

論理サーバの種類 | <種別>
論理J2EEサーバ | J2EE
論理パフォーマンストレーサ | PRF
論理CTMドメインマネジャ | CTMDM
論理CTM | CTM
論理スマートエージェント | SA
論理ユーザサーバ | USER

なお，<通番>は，基本的に「01」が設定されます。ただし，CTMを使用するシステムのように論理サーバを複数配置する場合は，重複しない番号が割り振られます。

注意

システムの構成を変更するとシステムが動作するために必要なリソースも変更する必要があります。システムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

＜この項の構成＞

(1)　構成変更定義ファイルの作成

(2)　システムの情報モデルの変更

(3)　サービスユニットの追加

(1)　構成変更定義ファイルの作成

サービスユニット・ホスト追加用の構成変更定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

構成変更定義ファイルを作成します。
サービスユニット・ホスト追加用の構成変更定義ファイル（cmxaddcombinedmodel.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

UNIXの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemAdd.xml」に変更しています。

コピーした構成変更定義ファイルを編集します。
MyWebSystemAdd.xmlファイルを編集します。ここでは，追加するサービスユニットの内容と，ホストの定義をします。
設定後のMyWebSystemAdd.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<unit-addition xmlns="http://www.cosminexus.com/mngsvr/schema/UnitAddition-2.5">
 <web-system>
   <name>MyWebSystem</name>

   <!-- 追加するサービスユニットの定義 -->
   <unit>
     <name>unit3</name>
     <allocated-host>
       <host-ref>apsv1</host-ref>※
       <hosts-for>j2ee-tier</hosts-for>
       <define-server>
         <logical-server-name>BatchServer03</logical-server-name>
         <logical-server-type>j2ee-server</logical-server-type>
       </define-server>
       <define-server>
         <logical-server-name>PRF03</logical-server-name>
         <logical-server-type>performance-tracer</logical-server-type>
       </define-server>
     </allocated-host>
   </unit>

 </web-system>
</unit-addition>

注　太字の部分が編集部分です。

注※　サービスユニットを追加する既存のサーバマシンのホスト名を指定します。この場合，既存のサーバマシンを使用するため，ホストの定義は不要です。

(2)　システムの情報モデルの変更

作成した構成変更定義ファイルの内容を，Management Serverが保持するシステムの情報モデルに反映します。

システムの情報モデルを変更します。
cmx_change_modelコマンドに，(1)で作成した構成変更定義ファイルを指定して，Management Serverが保持するシステムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_change_model -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemAdd.xml

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_change_model -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemAdd.xml

(3)　サービスユニットの追加

変更したシステムの情報モデルを実システムに適用して，サービスユニットを追加します。

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，(2)で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

追加したサービスユニットを起動します。
cmx_start_targetコマンドを使用して，追加したサービスユニット「unit3」を一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem -unit unit3

追加したサービスユニットのリソースアダプタをインポートし，開始します。
ここでは，サーバ管理コマンドを使用して，次の内容を実施しています。ファイル名をDBConnector_HiRDB_Type4_CP.rar，表示名をDB_Connector_for_HiRDB_Type4，Connector属性ファイルのファイル名をMyDBConnectorAttr.xmlとした場合の手順を例にして説明します。DBConnector_HiRDB_Type4_CP.rar以外のRARファイルを使用する場合は，利用するDB ConnectorのRARファイルに読み替えてください。

リソースアダプタをインポートします。

バッチサーバにリソースアダプタをデプロイします。

Connector属性ファイルをリソースアダプタに反映します。

リソースアダプタの接続を確認します。

リソースアダプタを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres BatchServer03 -nameserver corbaname::192.168.1.11:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>¥MyDBConnectorAttr.xml※

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjtestres BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

UNIXの場合

# /opt/Cosminexus/CC/admin/bin/cjimportres BatchServer03 -nameserver corbaname::192.168.1.11:900 -type rar -f <Cosminexusのインストールディレクトリ>¥CC¥DBConnector¥DBConnector_HiRDB_Type4_CP.rar

# /opt/Cosminexus/CC/admin/bin/cjdeployrar BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjsetrarprop BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4 -c <任意のディレクトリ>/MyDBConnectorAttr.xml※

# /opt/Cosminexus/CC/admin/bin/cjtestres BatchServer -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

# /opt/Cosminexus/CC/admin/bin/cjstartrar BatchServer03 -nameserver corbaname::192.168.1.11:900 -resname DB_Connector_for_HiRDB_Type4

注※

サービスユニット1のリソースアダプタに反映したConnector属性ファイルを使用します。Connector属性ファイルを保管していない場合は，サービスユニット1にデプロイしたリソースアダプタからサーバ管理コマンド（cjgetrarprop）を使用して取得します。取得したConnector属性ファイルは必要に応じて編集します。

11.4.2　システムのスケールイン

Smart Composer機能を使用すると，業務全体を停止することなく，システムの構成を変更できます。システムの規模を縮小する場合は，システムをスケールインします。

なお，システムのスケールインについては，J2EEアプリケーションを実行するシステムと同じです。システムのスケールインについては，「9.7.1　WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン」を参照してください。参照の際には次の点に注意してください。

注意

システムの構成を変更するとシステムが動作するために必要なリソースも変更する必要があります。システムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

参考

システムを削除して，システム単位でもスケールインできます。この場合は，cmx_stop_targetコマンドおよびcmx_delete_systemコマンドで，削除対象のシステムを指定します。なお，cmx_delete_systemコマンドを実行しても，バッチサーバの環境削除などのアンセットアップを実行しません。各コマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の次の個所を参照してください。

cmx_delete_system（Webシステムの削除）

cmx_stop_target（Webシステムまたはサービスユニットの停止）

11.5　JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン

Smart Composer機能を使用してシステムをスケールアウトする場合に，追加するアプリケーションサーバのセットアップにJP1/SC/DPMのディスク複製OSインストール機能を利用できます。この場合，通常のシステムのスケールアウトの手順の前に，複製元のディスクイメージを作成する準備が必要です。

なお，JP1/SC/DPMを利用して構築したシステムのスケールインについては，「9.8.3　JP1/SC/DPMを利用して構築したシステムのスケールイン」を参照してください。参照の際には次の点に注意してください。

スケールインをする場合は，バッチアプリケーションの処理が完了してから実施してください。

バッチサーバでは負荷分散機を使用しないため，負荷分散機に関する記述は該当しません。

注意

CTMを使用するパターン（ctm-tier）のシステムでは，スケールアウトおよびスケールインを実施できません。

JP1/SC/DPMを使用して，アプリケーションサーバのディスクイメージを複製し，そのディスクイメージに従って，新たなアプリケーションサーバにOSやアプリケーションをインストールします。次に，Smart Composer機能のコマンドを使用して，複製先アプリケーションサーバの情報をシステムにスケールアウトします。スケールアウトの概要については，「9.8.2　ホスト単位管理モデルでのシステムのスケールアウト」を参照してください。

なお，スケールアウトの方法は，J2EEアプリケーションを実行するシステムと同じです。ここでは，システムのスケールアウトの準備およびスケールアウトで実施する内容と参照先について説明します。

スケールアウトの準備

システムのスケールアウトの準備とは，複製元のディスクイメージを作成する作業です。システム構築が終わって，運用環境が整ったところで実施します。スケールアウトの準備では次の内容を実施します。

複製元アプリケーションサーバでの準備
複製元アプリケーションサーバで，JP1/SC/DPMでのディスクイメージ作成のための準備をします。準備方法については，「9.8.2(1)　複製元アプリケーションサーバでの準備」を参照してください。※1※2

スケールアウト用ディスクイメージの作成
JP1/SC/DPMを使用して，複製元アプリケーションサーバからディスクイメージを作成します。作成方法については，「9.8.2(2)　JP1/SC/DPMを使用したスケールアウト用ディスクイメージの作成」を参照してください。※1

注※1　バッチサーバの場合，J2EEアプリケーションに関する記述は該当しません。

注※2　バッチサーバの場合，負荷分散機を使用しません。このため，参照先の手順6のcmx.lbキーの変更に関する記述は該当しません。

スケールアウト

複製したディスクイメージを使用して，スケールアウトをします。スケールアウトでは，次の内容を実施します。

ディスクイメージのリストア
作成したディスクイメージを，複製先アプリケーションサーバにリストアします。リストアの手順については，「9.8.2(3)　JP1/SC/DPMを使用したディスクイメージのリストア」を参照してください。

スケールアウト用ホスト定義ファイルの作成
スケールアウト用ホスト定義ファイルに複製先アプリケーションサーバを定義します。スケールアウト用ホスト定義ファイルの作成については，(1)を参照してください。

システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）
2.で作成したスケールアウト用ホスト定義ファイルを基に，Management Serverが保持するシステムの情報モデルを変更します。情報モデルの変更方法については，(2)を参照してください。

なお，システムの構成を変更するとシステムが動作するために必要なリソースも変更する必要があります。システムが動作するために必要なリソースの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

注意

アプリケーションサーバ（運用管理ドメイン）ごと複製するため，複製先アプリケーションサーバのサービスユニット，ホストの名称は，複製元と同じになります。

JP1/SC/DPMを使用したシステムのスケールアウトを，JP1/AJS2 - SOを使用して自動化する場合，ディスク複製インストール（リストア）が完了してから運用管理エージェントを自動起動するように設定する必要があります。設定方法については，マニュアル「JP1/ServerConductor/Deployment Manager」を参照してください。また，JP1/AJS2 - SOとの連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「16.　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）」を参照してください。

＜この節の構成＞

(1)　スケールアウト用ホスト定義ファイルの作成

(2)　システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

(1)　スケールアウト用ホスト定義ファイルの作成

スケールアウト用ホスト定義ファイルを任意の場所にコピーして，ファイルの内容を編集します。

スケールアウト用ホスト定義ファイルを作成します。
スケールアウト用ホスト定義ファイル（cmxscaleouthostdef.xmlファイル）は，次の場所に提供されています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥templates¥

Linuxの場合
/opt/Cosminexus/manager/config/templates/

このファイルをコピーし，名称を変更して，任意の場所に格納します。なお，ここではファイル名を「MyWebSystemHostScaleout.xml」に変更しています。

コピーしたスケールアウト用ホスト定義ファイルを編集します。
MyWebSystemHostScaleout.xmlファイルを編集します。ここでは，複製先アプリケーションサーバのシステムの内容と，ホストの定義をします。
設定後のMyWebSystemHostScaleout.xmlファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<host-scaleout xmlns="http://www.cosminexus.com/mngsvr/schema/HostScaleOut-2.5">
 <!-- 複製先のWebシステムの定義 -->
 <web-system>
   <name>MyWebSystem1</name>
 </web-system>
 <!-- 複製先のホストの定義 -->
 <host>
   <host-name>192.168.1.13</host-name>
   <agent-host>192.168.100.13</agent-host>
 </host>
</host-scaleout>

注　太字の部分が編集部分です。

(2)　システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

作成したスケールアウト用ホスト定義ファイルの内容を，複製先アプリケーションサーバのManagement Serverの，システムの情報モデルに反映します。また，変更したシステムの情報モデルを実システムに適用して，複製先アプリケーションサーバのホスト情報を変更します。

システムの情報モデルを変更します。
cmx_scaleout_hostコマンドに，(1)で作成したスケールアウト用ホスト定義ファイルを指定して，複製先アプリケーションサーバのManagement Serverの，システムの情報モデルを変更します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_scaleout_host -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>¥MyWebSystemHostScaleout.xml

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_scaleout_host -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -f <任意のディレクトリ>/MyWebSystemHostScaleout.xml

変更したシステムの情報モデルを実システムに展開します。
cmx_build_systemコマンドを使用して，1.で変更したシステムの情報モデルを実システムに適用します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_build_system -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_build_system -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem1

複製先アプリケーションサーバのサービスユニットを一括起動します。
cmx_start_targetコマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」を一括起動します。このとき，コマンドの-modeオプションに「ALL」を指定して，稼働状態で起動します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_start_target -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

Linuxの場合

# /opt/Cosminexus/manager/bin/cmx_start_target -m 192.168.100.13 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem1 -unit unit1

複製先アプリケーションサーバのリソースアダプタを開始します（必要に応じて）。
リソースアダプタが自動で開始しない場合は，最初に，リソースアダプタを開始します。JP1/SC/DPMを使用してディスクイメージを作成するときに，複製元アプリケーションサーバでリソースアダプタを一括停止しなかった場合，この操作は必要ありません。
ここでは次の内容を実施しています。

サーバ管理コマンドを使用して，複製先アプリケーションサーバのサービスユニット「unit1」のリソースアダプタを開始します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar BatchServer -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

Linuxの場合

# /opt/Cosminexus/CC/admin/bin/cjstartrar BatchServer -nameserver corbaname::192.168.1.13:900 -resname DB_Connector_for_HiRDB_Type4

11.6　構築済みのシステムの移行

Smart Composer機能を使用すると，構築済みのシステムの設定内容をほかの環境に移行できます。

●構築済みのシステムの移行手順

システムの移行手順は，J2EEアプリケーションを実行するシステムと同じです。手順の詳細については，「9.9.1　構築済みのシステムの移行手順」を参照してください。

●構築済みのシステムの移行時に出力する簡易構築定義ファイルの内容

cmx_export_modelコマンドを使用して構築済みのシステムの設定内容を出力した場合の出力内容について説明します。

XMLスキーマのバージョン

XMLスキーマのバージョンは，最新のバージョンで出力されます。旧バージョンの簡易構築定義ファイルを使用して構築したシステムに対して設定内容を出力した場合，最新のXMLスキーマのバージョンに従って，タグ名称が最新の名称に変換されます。

物理ティアの構成

「5.2.1　構成定義パターン選定の考え方」にある構成は，その構成に従った物理ティアの構成で出力されます。「5.2.1　構成定義パターン選定の考え方」にない構成は，free-tier構成で出力されます。

論理サーバのコンフィグレーションに設定しているパラメタ

出力規則

非推奨のパラメタは，推奨のパラメタに変換されます。

値を指定しているパラメタは出力されます。値を省略しているパラメタは出力されません。

簡易構築定義ファイルでパラメタにデフォルト値を設定している場合，または運用管理ポータルでキーにデフォルト値を設定している場合，そのパラメタは出力されます。

出力順序

論理サーバの種類ごとに，パラメタの種類によって出力順序があります。また，同じパラメタの種類の中でのパラメタの出力順序は，パラメタ名称の昇順です。パラメタの出力順序を，次の表に示します。

表11-10　パラメタの出力順序

パラメタを設定するサーバ | 出力順序 | パラメタの種類
バッチサーバ | 1 | 各論理サーバ共通で指定できるパラメタ
2 | バッチサーバ用オプション定義のパラメタ
3 | バッチサーバ用ユーザプロパティのパラメタ
そのほかの論理サーバ | 1 | 各論理サーバ共通で指定できるパラメタ
2 | 該当する論理サーバのパラメタ

設定先

構築済みのシステムの論理サーバによってパラメタの設定先が異なります。パラメタの設定先を，次の表に示します。なお，free-tier構成では，ティアの定義にパラメタを設定できないため，サービスユニットの定義にすべてのパラメタが設定されます。

表11-11　パラメタの設定先

同じ種類の論理サーバの数 | パラメタに指定している値 | パラメタの設定先
1 | － | ティアの定義
2～n | すべての論理サーバで同じ | ティアの定義
論理サーバごとに異なる | ユニットの定義

（凡例）　－：なし

システムの中に同じ種類の論理サーバが一つしかない場合，すべてのパラメタがティアの定義に設定されます。

システムの中に同じ種類の論理サーバが複数ある場合に，同じ種類の論理サーバで，同じパラメタに同じ値をそれぞれ指定していると，パラメタの値は，ティアの定義にそれぞれ設定されます。

システムの中に同じ種類の論理サーバが複数ある場合に，同じ種類の論理サーバで，同じパラメタに異なる値をそれぞれ指定していると，パラメタはユニットの定義にそれぞれ設定されます。

●構築済みのシステムを移行するときの注意事項

構築済みのシステムを移行するときの注意は，J2EEアプリケーションを実行するシステムと同じです。詳細については，「9.9.3　構築済みのシステムを移行するときの注意事項」を参照してください。

11.7　トラブルへの対処

Smart Composer機能で構築したシステムで想定されるトラブルには，次に示す種別があります。

エラーメッセージ出力
エラーメッセージが出力されます。

システムダウン
アプリケーションサーバのサーバプロセスが異常終了します。

ハングアップ（無応答）
アプリケーション呼び出しの応答が返らなくなります。

スローダウン
アプリケーション呼び出しの応答は返りますが，応答時間が長くなります。

これらのトラブル種別ごとに，トラブルシューティングに必要な資料が取得できます。資料の取得方法と対処方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の次の個所を参照してください。

2.　トラブルシューティング（資料取得と対処の概要）

3.　トラブルシューティング（資料取得の設定）

4.　トラブルシューティング（資料の出力先と出力方法）

5.　トラブルシューティング（資料の出力内容）

11.8　システムの削除

不要になったシステムは削除できます。ここでは，不要になったシステムの削除の流れを説明します。なお，システムを削除する際には，実行中のバッチアプリケーションがないことを確認してから実施してください。

リソースアダプタを停止します。
リソースアダプタは，サーバ管理コマンドや運用管理ポータルを使用して停止します。

cmx_stop_targetコマンドを使用してシステムを停止します。
削除対象となるシステムを停止します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_stop_target -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -mode ALL -s MyWebSystem

cmx_delete_systemコマンドを使用してManagement Server上からWebシステムを削除します。
Management Serverで管理されているWebシステムの情報モデルを削除します。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥manager¥bin¥cmx_delete_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

UNIXの場合

# /opt/Cosminexus/manager/bin/cmx_delete_system -m 192.168.100.11 -u cosmi_admin -p cosmi_admin_passwd -s MyWebSystem

cjsetupコマンドに-dオプションを指定して，バッチサーバをアンセットアップします。
cmx_delete_systemコマンドでは，サーバの環境はアンセットアップされません。cjsetupコマンドを使用して，ホスト上のバッチサーバの環境をアンセットアップします。cjsetupコマンドには，バッチサーバの論理サーバ名を指定します。
論理サーバ名はcmx_list_modelコマンドを使用して確認できます。cmx_delete_systemコマンドを実行する前に論理サーバ名を確認してください。
ただし，システム構築時に，バッチサーバの実サーバ名を指定している場合は，cjsetupコマンドには実サーバ名を指定してください。実サーバ名の指定は，簡易構築定義ファイルの物理ティアのrealservernameパラメタに指定します。
アンセットアップ時に指定するサーバ名の詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。
次の実行例は，実サーバ名を指定していないバッチサーバをアンセットアップする場合の例です。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥bin¥cjsetup -d BatchServer

UNIXの場合

# /opt/Cosminexus/CC/server/bin/cjsetup -d BatchServer

付録

＜この付録の構成＞

付録A　Smart Composer機能が実行する負荷分散機のCLIコマンドまたはAPI

付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル

付録C　データベース（XDM/RD E2・SQL Server）の設定

付録D　セットアップウィザードで設定されるパラメタ

付録E　代替手段で実行できる運用作業

付録F　アプリケーションサーバが提供するサンプルプログラム

付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）

付録H　このマニュアルの参考情報

付録I　用語解説

付録A　Smart Composer機能が実行する負荷分散機のCLIコマンドまたはAPI

Smart Composer機能で提供するコマンドを実行すると，Management Serverと接続して，負荷分散機の設定をします。負荷分散機の設定は，業務リクエストをWebサーバに振り分けるための設定で，仮想サーバや実サーバの作成，仮想サーバと実サーバの接続，および実サーバへのリクエスト振り分けの開始・停止などを設定します。ここでは，Smart Composer機能が実行する負荷分散機のCLIコマンドとAPIについて説明します。それぞれ使用する製品を次に示します。

負荷分散機のCLIコマンドを使用する製品
BIG-IP（BIG-IP v9，BIG-IP v10.1，BIG-IP v10.2），ACOS（AX2000，BS320）

負荷分散機のAPIを使用する製品
ACOS（AX2500）

＜この節の構成＞

付録A.1　Smart Composer機能が実行するBIG-IPのCLIコマンド

付録A.2　Smart Composer機能が実行するACOSのCLIコマンド

付録A.3　Smart Composer機能が実行する負荷分散機のAPI

付録A.1　Smart Composer機能が実行するBIG-IPのCLIコマンド

Smart Composer機能が実行するBIG-IPのCLIコマンドを製品ごとに説明します。BIG-IPのCLIコマンドの詳細については，使用する製品のドキュメントを参照してください。

＜この項の構成＞

(1)　BIG-IP v9またはBIG-IP v10.1の場合

(2)　BIG-IP v10.2の場合

(1)　BIG-IP v9またはBIG-IP v10.1の場合

負荷分散機としてBIG-IP v9またはBIG-IP v10.1を使用する場合に，Smart Composer機能が実行する負荷分散機のCLIコマンドを次の表に示します。

表A-1　Smart Composer機能が実行する負荷分散機のCLIコマンド（BIG-IP v9またはBIG-IP v10.1の場合）

Smart Composer機能のコマンド
実行する負荷分散機のCLIコマンド

共通
b save
b version

cmx_build_system（Webシステムを構築する場合）
cookieスイッチングの使用なし
b pool <仮想サーバ名> {member <実サーバIPアドレス>:<実ポート>}

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http enable}

cookieスイッチングの使用あり
b pool <仮想サーバ名> {member <実サーバIPアドレス>:<実ポート>}

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

b profile persist <仮想サーバ名> {mode cookie cookie mode insert cookie name <cookie名>}

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http persist <仮想サーバ名> enable}

cmx_build_system（スケールアウトする場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

cmx_build_system（実ポートを変更する場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<変更後の実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<変更後の実ポート> session disable

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> delete

cmx_build_system（負荷分散機の仮想サーバを初期化しないでWebシステムを構築する場合）
cookieスイッチングの使用なし
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

b virtual <仮想サーバ名> {destination
<仮想サーバIPアドレス>:<仮想ポート> pool
<仮想サーバ名> profile http enable}

cookieスイッチングの使用あり
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

b profile persist <仮想サーバ名> {mode cookie cookie mode insert cookie name <cookie名>}

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http persist <仮想サーバ名> enable}

cmx_delete_system（サービスユニットを削除，およびホスト単位管理モデルをスケールインする場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> delete

b node <実サーバIPアドレス> delete

cmx_delete_system（Webシステムを削除する場合）
cookieスイッチングの使用なし
b virtual <仮想サーバ名> delete

b pool <仮想サーバ名> delete

b node <実サーバIPアドレス> delete

cookieスイッチングの使用あり
b virtual <仮想サーバ名> delete

b pool <仮想サーバ名> delete

b node <実サーバIPアドレス> delete

b profile persist <仮想サーバ名> delete

cmx_start_target
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session enable

cmx_stop_target
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session disable

参考

BIG-IP v9，BIG-IP v10.1の場合，仮想サーバ名をプール名として使用します。

(2)　BIG-IP v10.2の場合

負荷分散機としてBIG-IP v10.2を使用する場合に，Smart Composer機能が実行する負荷分散機のCLIコマンドを次の表に示します。

表A-2　Smart Composer機能が実行する負荷分散機のCLIコマンド（BIG-IP v10.2の場合）

Smart Composer機能のコマンド
実行する負荷分散機のCLIコマンド

共通
b save
b version

cmx_build_system（Webシステムを構築する場合）
cookieスイッチングの使用なし
b pool <仮想サーバ名> {member <実サーバIPアドレス>:<実ポート>}

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http enable}

cookieスイッチングの使用あり
b pool <仮想サーバ名> {member <実サーバIPアドレス>:<実ポート>}

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

b profile persist <仮想サーバ名> {mode cookie cookie mode insert cookie name <cookie名>}

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http persist <仮想サーバ名> enable}

cmx_build_system（スケールアウトする場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

cmx_build_system（実ポートを変更する場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<変更後の実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<変更後の実ポート> session user disabled

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> delete

cmx_build_system（負荷分散機の仮想サーバを初期化しないでWebシステムを構築する場合）
cookieスイッチングの使用なし
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http enable}

cookieスイッチングの使用あり
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> add

b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

b profile persist <仮想サーバ名> {mode cookie cookie mode insert cookie name <cookie名>}

b virtual <仮想サーバ名> {destination <仮想サーバIPアドレス>:<仮想ポート> pool <仮想サーバ名> profile http persist <仮想サーバ名> enable}

cmx_delete_system（サービスユニットを削除，およびホスト単位管理モデルをスケールインする場合）
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> delete

b node <実サーバIPアドレス> delete

cmx_delete_system（Webシステムを削除する場合）
cookieスイッチングの使用なし
b virtual <仮想サーバ名> delete

b pool <仮想サーバ名> delete

b node <実サーバIPアドレス> delete

cookieスイッチングの使用あり
b virtual <仮想サーバ名> delete

b pool <仮想サーバ名> delete

b node <実サーバIPアドレス> delete

b profile persist <仮想サーバ名> delete

cmx_start_target
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user enabled

cmx_stop_target
b pool <仮想サーバ名> member <実サーバIPアドレス>:<実ポート> session user disabled

参考

BIG-IP v10.2の場合，仮想サーバ名をプール名として使用します。

付録A.2　Smart Composer機能が実行するACOSのCLIコマンド

負荷分散機としてACOS（AX2000またはBS320）を使用する場合に，Smart Composer機能が実行する負荷分散機のCLIコマンドを次の表に示します。ACOSのCLIコマンドの詳細は，使用する製品のドキュメントを参照してください。

表A-3　Smart Composer機能が実行する負荷分散機のCLIコマンド（AX2000またはBS320の場合）

Smart Composer機能のコマンド
実行する負荷分散機のCLIコマンド

共通
enable
config
show version
exit

cmx_build_system（Webシステムを構築する場合）
cookieスイッチングの使用なし※1
slb server <実サーバ名> <実サーバIPアドレス>
port <実ポート> tcp

slb service-group <仮想サーバ名> tcp
member <実サーバ名>:<実ポート> disable

slb virtual-server <仮想サーバ名> <仮想サーバIPアドレス>
port <仮想ポート> http
service-group <仮想サーバ名>

write memory

cookieスイッチングの使用あり※2
slb server <実サーバ名> <実サーバIPアドレス>
port <実ポート> tcp

slb service-group <仮想サーバ名> tcp

member <実サーバ名>:<実ポート> disable

slb template persist cookie <仮想サーバ名>
name <cookie名>
expire 0

slb virtual-server <仮想サーバ名> <仮想サーバIPアドレス>
port <仮想ポート> http
service-group <仮想サーバ名>
template persist cookie <仮想サーバ名>

write memory

cmx_build_system（スケールアウトする場合）
slb server <実サーバ名> <実サーバIPアドレス>
port <実ポート> tcp

slb service-group <仮想サーバ名> tcp
member <実サーバ名>:<実ポート> disable

write memory

cmx_build_system（実ポートを変更する場合）
slb server <実サーバ名> <実サーバIPアドレス>
port <変更後の実ポート> tcp
exit
no port <実ポート> tcp

slb service-group <仮想サーバ名> tcp
member <実サーバ名>:<変更後の実ポート> disable

write memory

cmx_delete_system（サービスユニットを削除する場合）※3
slb server <実サーバ名> <実サーバIPアドレス>
no port <実ポート> tcp

write memory

cmx_delete_system（ホスト単位モデルのスケールインを行う場合）※4
no slb server <実サーバ名>

write memory

cmx_delete_system（Webシステムを削除する場合）
cookieスイッチングの使用なし
no slb virtual-server <仮想サーバ名>

no slb service-group <仮想サーバ名>

no slb server <実サーバ名>

write memory

cookieスイッチングの使用あり
no slb virtual-server <仮想サーバ名>

no slb service-group <仮想サーバ名>

no slb server <実サーバ名>

no slb template persist cookie <仮想サーバ名>

write memory

cmx_start_target
slb service-group <仮想サーバ名> tcp
member <実サーバ名>:<実ポート> enable

write memory

cmx_stop_target
slb service-group <仮想サーバ名> tcp
member <実サーバ名>:<実ポート> disable

write memory

注※1　仮想サーバの初期化を実施しない場合（-lb keepvsを指定した場合）も実行するCLIコマンドは同じです。

注※2　仮想サーバの初期化を実施しない場合（-lb keepvsを指定した場合）も実行するCLIコマンドは同じです。

注※3　実サーバを共有するそのほかのサービスユニットがある場合は，サーバごとの削除はしません。

注※4　実サーバを共有するそのほかのサービスユニットがない場合は，サーバごと削除します。

参考

ACOSの場合，仮想サーバ名をサービスグループ名およびテンプレート名として使用します。

付録A.3　Smart Composer機能が実行する負荷分散機のAPI

Smart Composer機能が実行する負荷分散機のAPIについて説明します。

負荷分散機のAPIシーケンス図の例を次の図に示します。ここでは，cmx_build_system（Webシステムを構築する場合）で，cookieスイッチングを使用しているときの例を示します。

図A-1　負荷分散機のAPIシーケンス図の例（cmx_build_system（Webシステムを構築する場合））

VirtualServerは，負荷分散機上で，リクエストの受け口となる仮想的なサーバを表すオブジェクトです。管理ユニットごとに一つ作成されます。ServiceGroupは，負荷分散機上のVirtualServerで受けたリクエストのサービス管理を行うオブジェクトです。VirtualServerごとに一つ作成されます。RealServerは，負荷分散機上で，VirtualServerで受けたリクエストの振り分け先となる実際のサーバを表すオブジェクトです。管理ユニットに属する仮想サーバの数だけ作成されます。

ACOSでcookieパーシステンスを使用したAPIで接続する場合は，事前にCookiePersistence（cookieパーシステンス）を作成する必要があります。CookiePersistenceでは，cookieによるセッションの維持期間を設定します。なお，使用済みのCookiePersistenceは必要に応じて削除してください。CookiePersistenceの作成，削除方法の詳細は，使用する負荷分散機のドキュメントを参照してください。

参考

VirtualServer，ServiceGroup，RealServerおよびCookiePersistenceの名称は，負荷分散機の製品によって異なります。

付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル

JP1/SC/DPMを利用して，Webシステムをスケールアウトする際に，複製元アプリケーションサーバのログファイルを削除する必要があります。Smart Composer機能を使用して構築できるシステムごとに，削除が必要なログファイルが格納されているディレクトリの一覧を次に示します。

＜この節の構成＞

(1)　J2EEアプリケーションを実行するシステムの場合

(2)　バッチアプリケーションを実行するシステムの場合

(1)　J2EEアプリケーションを実行するシステムの場合

J2EEアプリケーションを実行するシステムの場合，複製元アプリケーションサーバで，次の表に示すディレクトリ下にログファイルがある場合は削除してください。なお，ログファイルが格納されているディレクトリは，削除対象外です。削除対象ログファイルが格納されているディレクトリパスを次の表に示します。

表B-1　削除対象ログファイルが格納されているディレクトリパス（Windowsの場合）

項番 | ディレクトリパス
1 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥*
2 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥maintenance¥*
3 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥maintenance¥mmap¥*
4 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥rmi¥*
5 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥rmi¥mmap¥*
6 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥mmap¥*
7 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥*
8 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥comtrc¥*
9 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥mdltrc¥*
10 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥*
11 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥mmap¥*
12 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥system¥ejbcl¥*
13 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥system¥ejbcl¥mmap¥*
14 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥system¥TPB¥logj¥*
15 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥system¥TPB¥logj¥comtrc¥*
16 | <Cosminexusのインストールディレクトリ>¥CC¥client¥logs¥system¥TPB¥logj¥mdltrc¥*
17 | <Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名>¥logs¥*
18 | <Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名>¥logs¥TPB¥logj¥*
19 | <Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名>¥logs¥TPB¥logj¥comtrc¥*
20 | <Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名>¥logs¥TPB¥logj¥mdltrc¥*
21 | <Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥logs¥*
22 | <Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥logs¥mmap¥*
23 | <Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥servers¥<サーバ名>¥logs¥*
24 | <Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥servers¥<サーバ名>¥logs¥mmap¥*
25 | <Cosminexusのインストールディレクトリ>¥manager¥spool¥default¥*
26 | <Cosminexusのインストールディレクトリ>¥manager¥spool¥lsinfo¥*
27 | <Cosminexusのインストールディレクトリ>¥manager¥tmp¥*
28 | <Cosminexusのインストールディレクトリ>¥manager¥setup¥log¥*
29 | <Cosminexusのインストールディレクトリ>¥manager¥setup¥log¥maintenance¥*
30 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥*
31 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥CC¥maintenance¥*
32 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥CC¥rmi¥*
33 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥connectors¥*
34 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥connectors¥<アプリケーション表示名>¥*
35 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥connectors¥TEST#¥<アプリケーション表示名>¥*
36 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥http¥*
37 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥http¥comm¥*
38 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥http¥thr¥*
39 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥*
40 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥comtrc¥*
41 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥mdltrc¥*
42 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥watch¥*
43 | <Managerのログ出力ディレクトリ>※2¥*
44 | <Managerのログ出力ディレクトリ>※2¥maintenance¥*
45 | <Managerのログ出力ディレクトリ>※2¥maintenance¥mmap¥*
46 | <Managerのログ出力ディレクトリ>※2¥message¥*
47 | <Managerのログ出力ディレクトリ>※2¥message¥mmap¥*
48 | <Managerのログ出力ディレクトリ>※2¥trace¥*
49 | <Managerのログ出力ディレクトリ>※2¥trace¥mmap¥*
50 | <snapshotログの出力先ディレクトリ>※3¥*
51 | <監査ログ出力ディレクトリ>※4¥*
52 | <監査ログのメッセージログ出力ディレクトリ>※5¥*
53 | <監査ログのメッセージログ出力ディレクトリ>※5¥mmap¥*
54 | <監査ログの例外情報ログ出力ディレクトリ>※6¥*
55 | <監査ログの例外情報ログ出力ディレクトリ>※6¥mmap¥*

注※1　<Cosminexusの作業ディレクトリ>は，usrconf.cfgのejb.public.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥CC¥server¥public」です。

注※2　<Managerのログ出力ディレクトリ>は，manager.cfg（Managerログ設定ファイル）のcom.cosminexus.manager.log.dirキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥manager¥log」です。

注※3　<snapshotログの出力先ディレクトリ>は，adminagent.properties（運用管理エージェントプロパティファイル）のadminagent.snapshotlog.log_dirキーに設定されているディレクトリです。デフォルト値は，「<Managerのログ出力ディレクトリ>¥snapshot」です。

注※4　<監査ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

注※5　<監査ログのメッセージログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.message.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

注※6　<監査ログの例外情報ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.exception.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

表B-2　削除対象ログファイルが格納されているディレクトリパス（Linuxの場合）

項番 | ディレクトリパス
1 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/*
2 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/maintenance/*
3 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/maintenance/mmap/*
4 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/rmi/*
5 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/rmi/mmap/*
6 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/mmap/*
7 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/*
8 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/comtrc/*
9 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/mdltrc/*
10 | <Cosminexusのインストールディレクトリ>/CC/client/logs/*
11 | <Cosminexusのインストールディレクトリ>/CC/client/logs/mmap/*
12 | <Cosminexusのインストールディレクトリ>/CC/client/logs/system/ejbcl/*
13 | <Cosminexusのインストールディレクトリ>/CC/client/logs/system/ejbcl/mmap/*
14 | <Cosminexusのインストールディレクトリ>/CC/client/logs/system/TPB/logj/*
15 | <Cosminexusのインストールディレクトリ>/CC/client/logs/system/TPB/logj/comtrc/*
16 | <Cosminexusのインストールディレクトリ>/CC/client/logs/system/TPB/logj/mdltrc/*
17 | <Cosminexusのインストールディレクトリ>/CC/web/containers/<サーバ名>/logs/*
18 | <Cosminexusのインストールディレクトリ>/CC/web/containers/<サーバ名>/logs/TPB/logj/*
19 | <Cosminexusのインストールディレクトリ>/CC/web/containers/<サーバ名>/logs/TPB/logj/comtrc/*
20 | <Cosminexusのインストールディレクトリ>/CC/web/containers/<サーバ名>/logs/TPB/logj/mdltrc/*
21 | <Cosminexusのインストールディレクトリ>/CC/web/redirector/logs/*
22 | <Cosminexusのインストールディレクトリ>/CC/web/redirector/logs/mmap/*
23 | <Cosminexusのインストールディレクトリ>/CC/web/redirector/servers/<サーバ名>/logs/*
24 | <Cosminexusのインストールディレクトリ>/CC/web/redirector/servers/<サーバ名>/logs/mmap/*
25 | <Cosminexusのインストールディレクトリ>/manager/spool/default/*
26 | <Cosminexusのインストールディレクトリ>/manager/spool/lsinfo/*
27 | <Cosminexusのインストールディレクトリ>/manager/tmp/*
28 | <Cosminexusのインストールディレクトリ>/manager/setup/log/*
29 | <Cosminexusのインストールディレクトリ>/manager/setup/log/maintenance/*
30 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/*
31 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/CC/maintenance/*
32 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/CC/rmi/*
33 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/connectors/*
34 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/connectors/<アプリケーション表示名>/*
35 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/connectors/TEST#/<アプリケーション表示名>/*
36 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/http/*
37 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/http/comm/*
38 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/http/thr/*
39 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/*
40 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/comtrc/*
41 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/mdltrc/*
42 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/watch/*
43 | <Managerのログ出力ディレクトリ>※2/*
44 | <Managerのログ出力ディレクトリ>※2/maintenance/*
45 | <Managerのログ出力ディレクトリ>※2/maintenance/mmap/*
46 | <Managerのログ出力ディレクトリ>※2/message/*
47 | <Managerのログ出力ディレクトリ>※2/message/mmap/*
48 | <Managerのログ出力ディレクトリ>※2/trace/*
49 | <Managerのログ出力ディレクトリ>※2/trace/mmap/*
50 | <snapshotログの出力先ディレクトリ>※3/*
51 | <監査ログ出力ディレクトリ>※4/*
52 | <監査ログのメッセージログ出力ディレクトリ>※5/*
53 | <監査ログのメッセージログ出力ディレクトリ>※5/mmap/*
54 | <監査ログの例外情報ログ出力ディレクトリ>※6/*
55 | <監査ログの例外情報ログ出力ディレクトリ>※6/mmap/*

注※1　<Cosminexusの作業ディレクトリ>は，usrconf.cfgのejb.public.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/CC/server/public」です。

注※2　<Managerのログ出力ディレクトリ>は，manager.cfg（Managerログ設定ファイル）のcom.cosminexus.manager.log.dirキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/manager/log」です。

注※3　<snapshotログの出力先ディレクトリ>は，adminagent.propertiesファイル（運用管理エージェントプロパティファイル）のadminagent.snapshotlog.log_dirキーに設定されているディレクトリです。デフォルト値は，「<Managerのログ出力ディレクトリ>/snapshot」です。

注※4　<監査ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

注※5　<監査ログのメッセージログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.message.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

注※6　<監査ログの例外情報ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.exception.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

(2)　バッチアプリケーションを実行するシステムの場合

バッチアプリケーションを実行するシステムの場合，複製元アプリケーションサーバで，次の表に示すディレクトリ下にログファイルがある場合は削除してください。なお，ログファイルが格納されているディレクトリは，削除対象外です。削除対象ログファイルが格納されているディレクトリパスを次の表に示します。

表B-3　削除対象ログファイルが格納されているディレクトリパス（Windowsの場合）

項番 | ディレクトリパス
1 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥*
2 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥maintenance¥*
3 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥maintenance¥mmap¥*
4 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥rmi¥*
5 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥CC¥rmi¥mmap¥*
6 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥mmap¥*
7 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥*
8 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥comtrc¥*
9 | <Cosminexusのインストールディレクトリ>¥CC¥admin¥logs¥TPB¥logj¥mdltrc¥*
10 | <Cosminexusのインストールディレクトリ>¥CC¥batch¥logs¥*
11 | <Cosminexusのインストールディレクトリ>¥CC¥batch¥logs¥mmap¥*
12 | <Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名>¥logs¥*
13 | <Cosminexusのインストールディレクトリ>¥manager¥spool¥default¥*
14 | <Cosminexusのインストールディレクトリ>¥manager¥spool¥lsinfo¥*
15 | <Cosminexusのインストールディレクトリ>¥manager¥tmp¥*
16 | <Cosminexusのインストールディレクトリ>¥manager¥setup¥log¥*
17 | <Cosminexusのインストールディレクトリ>¥manager¥setup¥log¥maintenance¥*
18 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥*
19 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥CC¥maintenance¥*
20 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥CC¥rmi¥*
21 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥connectors¥*
22 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥*
23 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥comtrc¥*
24 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥TPB¥logj¥mdltrc¥*
25 | <Cosminexusの作業ディレクトリ>※1¥ejb¥<サーバ名>¥logs¥watch¥*
26 | <Managerのログ出力ディレクトリ>※2¥*
27 | <Managerのログ出力ディレクトリ>※2¥maintenance¥*
28 | <Managerのログ出力ディレクトリ>※2¥maintenance¥mmap¥*
29 | <Managerのログ出力ディレクトリ>※2¥message¥*
30 | <Managerのログ出力ディレクトリ>※2¥message¥mmap¥*
31 | <Managerのログ出力ディレクトリ>※2¥trace¥*
32 | <Managerのログ出力ディレクトリ>※2¥trace¥mmap¥*
33 | <snapshotログの出力先ディレクトリ>※3¥*
34 | <監査ログ出力ディレクトリ>※4¥*
35 | <監査ログのメッセージログ出力ディレクトリ>※5¥*
36 | <監査ログのメッセージログ出力ディレクトリ>※5¥mmap¥*
37 | <監査ログの例外情報ログ出力ディレクトリ>※6¥*
38 | <監査ログの例外情報ログ出力ディレクトリ>※6¥mmap¥*

注※1　<Cosminexusの作業ディレクトリ>は，usrconf.cfgのejb.public.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥CC¥server¥public」です。

注※2　<Managerのログ出力ディレクトリ>は，manager.cfg（Managerログ設定ファイル）のcom.cosminexus.manager.log.dirキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥manager¥log」です。

注※3　<snapshotログの出力先ディレクトリ>は，adminagent.properties（運用管理エージェントプロパティファイル）のadminagent.snapshotlog.log_dirキーに設定されているディレクトリです。デフォルト値は，「<Managerのログ出力ディレクトリ>¥snapshot」です。

注※4　<監査ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

注※5　<監査ログのメッセージログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.message.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

注※6　<監査ログの例外情報ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.exception.directoryキーに設定されているディレクトリです。デフォルト値は，「<Cosminexusのインストールディレクトリ>¥auditlog」です。

表B-4　削除対象ログファイルが格納されているディレクトリパス（Linuxの場合）

項番 | ディレクトリパス
1 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/*
2 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/maintenance/*
3 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/maintenance/mmap/*
4 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/rmi/*
5 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/CC/rmi/mmap/*
6 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/mmap/*
7 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/*
8 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/comtrc/*
9 | <Cosminexusのインストールディレクトリ>/CC/admin/logs/TPB/logj/mdltrc/*
10 | <Cosminexusのインストールディレクトリ>/CC/batch/logs/*
11 | <Cosminexusのインストールディレクトリ>/CC/batch/logs/mmap/*
12 | <Cosminexusのインストールディレクトリ>/CC/web/containers/<サーバ名>/logs/*
13 | <Cosminexusのインストールディレクトリ>/manager/spool/default/*
14 | <Cosminexusのインストールディレクトリ>/manager/spool/lsinfo/*
15 | <Cosminexusのインストールディレクトリ>/manager/tmp/*
16 | <Cosminexusのインストールディレクトリ>/manager/setup/log/*
17 | <Cosminexusのインストールディレクトリ>/manager/setup/log/maintenance/*
18 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/*
19 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/CC/maintenance/*
20 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/CC/rmi/*
21 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/connectors/*
22 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/*
23 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/comtrc/*
24 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/TPB/logj/mdltrc/*
25 | <Cosminexusの作業ディレクトリ>※1/ejb/<サーバ名>/logs/watch/*
26 | <Managerのログ出力ディレクトリ>※2/*
27 | <Managerのログ出力ディレクトリ>※2/maintenance/*
28 | <Managerのログ出力ディレクトリ>※2/maintenance/mmap/*
29 | <Managerのログ出力ディレクトリ>※2/message/*
30 | <Managerのログ出力ディレクトリ>※2/message/mmap/*
31 | <Managerのログ出力ディレクトリ>※2/trace/*
32 | <Managerのログ出力ディレクトリ>※2/trace/mmap/*
33 | <snapshotログの出力先ディレクトリ>※3/*
34 | <監査ログ出力ディレクトリ>※4/*
35 | <監査ログのメッセージログ出力ディレクトリ>※5/*
36 | <監査ログのメッセージログ出力ディレクトリ>※5/mmap/*
37 | <監査ログの例外情報ログ出力ディレクトリ>※6/*
38 | <監査ログの例外情報ログ出力ディレクトリ>※6/mmap/*

注※1　<Cosminexusの作業ディレクトリ>は，usrconf.cfgのejb.public.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/CC/server/public」です。

注※2　<Managerのログ出力ディレクトリ>は，manager.cfg（Managerログ設定ファイル）のcom.cosminexus.manager.log.dirキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/manager/log」です。

注※3　<snapshotログの出力先ディレクトリ>は，adminagent.propertiesファイル（運用管理エージェントプロパティファイル）のadminagent.snapshotlog.log_dirキーに設定されているディレクトリです。デフォルト値は，「<Managerのログ出力ディレクトリ>/snapshot」です。

注※4　<監査ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

注※5　<監査ログのメッセージログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.message.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

注※6　<監査ログの例外情報ログ出力ディレクトリ>は，auditlog.properties（監査ログ定義ファイル）のauditlog.raslog.exception.directoryキーに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/auditlog」です。

付録C　データベース（XDM/RD E2・SQL Server）の設定

ここでは，データベースとして，XDM/RD E2またはSQL Serverを使用する場合に必要な設定について説明します。

参考

データベースとして，HiRDBまたはOracleを使用する場合の設定については，それぞれ次の個所を参照してください。

HiRDBの場合
HiRDB Type4 JDBC Driverを使用して接続する場合の設定については，「7.5　データベースを使用するための設定」を参照してください。

Oracleの場合
Oracle JDBC Thin Driverを使用して接続する場合の設定については，「7.5　データベースを使用するための設定」を参照してください。

＜この節の構成＞

付録C.1　XDM/RD E2の設定

付録C.2　SQL Serverの設定

付録C.1　XDM/RD E2の設定

HiRDB Type4 JDBC Driverを使用してXDM/RD E2に接続する場合の設定について説明します。なお，データベースとしてXDM/RD E2を使用する場合は，XDM/RD E2をインストールして初期設定を済ませておいてください。詳細については，マニュアル「HiRDB XDM/RD E2接続機能」を参照してください。

HiRDB Type4 JDBC Driverの設定については，「7.5.1　HiRDBの設定（HiRDB Type4 JDBC Driverの場合）」を参照してください。

ここでは，XDM/RD E2でJ2EEリソースを扱う場合に必要な次の設定について説明します。

環境変数の設定

環境変数のグループ登録

タイムアウトの設定

＜この項の構成＞

(1)　環境変数の設定

(2)　環境変数のグループ登録

(3)　タイムアウトの設定

(1)　環境変数の設定

次の環境変数を設定する必要があります。詳細については，マニュアル「HiRDB XDM/RD E2接続機能」，およびマニュアル「HiRDB UAP開発ガイド」を参照してください。

PDHOST

データベースのホスト名またはIPアドレスを指定します。

PDUSER

データベースのユーザ名およびデータベースのパスワードを指定します。

PDNAMEPORT

DBコネクションサーバのサーバスケジュール番号を指定します。

PDSRVTYPE

サーバの種別として，「VOS3」（固定値）を指定します。

PDCLTRDNODE

接続するXDM/RD E2のデータベース識別子として，RDノード名称（例：XRAA）を指定します。

PDXAMODE

トランザクションの移行機能は使用しないので，「0」（固定値）を指定します。

PDCWAITTIME

レスポンスタイムアウトとして，トランザクションタイムアウトの値よりも大きな値を指定します。

(2)　環境変数のグループ登録

環境変数のグループは，次の方法で登録します。

Windowsの場合
HiRDBのクライアント環境変数登録ツールで「システムグループ」を選択して，環境変数のグループを登録します。この場合，DB Connectorのプロパティ定義では，ここで登録したグループ名を指定してください。

UNIXの場合
HiRDBのクライアント環境変数グループの設定ファイルに登録します。この場合，DB Connectorのプロパティ定義では，ここで登録した環境変数グループの設定ファイルのパスを指定してください。

なお，環境変数のグループ登録の詳細については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(3)　タイムアウトの設定

XDM/RD E2のタイムアウトは，HiRDBのクライアント環境変数，またはDBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文に設定します。

XDM/RD E2のタイムアウトを設定するチューニングパラメタを次の表に示します。

表C-1　XDM/RD E2のタイムアウトを設定するチューニングパラメタ

タイムアウトの種類 | 設定個所 | 設定方法（パラメタ名） | 設定内容
レスポンスタイムアウト | HiRDBクライアント環境変数 | PDCWAITTIME | 任意の値を指定します。※1
SQL実行CPU時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SQLCTIME | 任意の値を指定します。※2
SQL実行経過時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SQLETIME | 任意の値を指定します。※2
トランザクション経過時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SVETIME | 任意の値を指定します。※2
サーバ処理要求の間隔時間 | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SVINTERVAL | コネクションプーリング機能を使用する場合は，「0」を指定してください。※2

注※1

詳細については，マニュアル「HiRDB XDM/RD E2接続機能」を参照してください。

注※2

詳細については，マニュアル「VOS3　Database Connection Server」を参照してください。

タイムアウトの設定については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.6.5　データベースでのタイムアウトを設定する」を参照してください。

付録C.2　SQL Serverの設定

SQL ServerのJDBCドライバを使用してSQL Serverに接続する場合の設定について説明します。なお，データベースとしてSQL Serverを使用する場合は，SQL Serverをインストールして初期設定を済ませておいてください。詳細については，SQL Serverのマニュアルを参照してください。

ここでは，SQL ServerのJDBCドライバを使用して，SQL ServerでJ2EEリソースを扱う場合に必要なデータベース側での設定，J2EEサーバ側での設定について説明します。また，SQL Serverのタイムアウトの設定についても説明します。

＜この項の構成＞

(1)　データベース側での設定

(2)　J2EEサーバ側での設定（SQL Server 2000 Driver for JDBCの場合）

(3)　J2EEサーバ側での設定（SQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverの場合）

(4)　タイムアウトの設定

(5)　コネクション障害検知を行うための設定

(1)　データベース側での設定

DB Connectorを使用してSQL Serverに接続する場合は，データベースのマシン上にSQL Serverをインストールして初期設定を済ませておいてください。また，SQL Serverに接続するためには，認証モードの設定が必要です。認証モードはインストール時に指定しますが，インストール後の変更もできます。

アプリケーションサーバで設定できるSQL Serverの認証モードは，設定できる認証方法によって，混合モードとWindows認証モードの2種類に分かれています。認証モード，および認証方法についてそれぞれ説明します。

認証モード

混合モード
Windows認証とSQL Server認証の両方の認証方法を使用できる認証モードです。

Windows認証モード
Windows認証を使用できる認証モードです。

認証方法

Windows 認証
SQL Serverのインスタンスへの接続の試行を検証するメカニズムの一つです。ユーザが，接続時にWindowsのユーザまたはグループによって識別されます。

SQL Server認証
SQL Serverのインスタンスへの接続の試行を検証するメカニズムの一つです。接続するには，SQL Server ログインIDおよびパスワードを指定する必要があります。SQL Serverインスタンスでは，ログインIDとパスワードの組み合わせが有効であることを確認してから接続します。

設定できる認証モード，および認証方法は，SQL ServerのJDBCドライバごとに異なります。設定できる認証モード，および認証方法について，使用するSQL ServerのJDBCドライバごとに次の表に示します。

表C-2　設定できる認証モード，および認証方法

使用するSQL ServerのJDBCドライバ | 設定できる認証モード | 設定できる認証方法
SQL Server認証 | Windows認証
SQL Server 2000 Driver for JDBC | 混合モード | ○ | ×※
SQL Server 2005 JDBC Driver（バージョン1.0） | 混合モード | ○ | ×※
SQL Server 2005 JDBC Driver（バージョン1.1） | 混合モード | ○ | ○
Windows認証モード | × | ○
SQL Server JDBC Driver | 混合モード | ○ | ○
Windows認証モード | × | ○

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

注※

SQL Server 2000 Driver for JDBC，およびSQL Server 2005 JDBC Driverのバージョン1.0を使用する場合には，混合モードを使用しますが，Windows認証は使用できません。

SQL Serverの認証モード，および認証方法の詳細については，SQL Serverのマニュアルを参照してください。

(2)　J2EEサーバ側での設定（SQL Server 2000 Driver for JDBCの場合）

アプリケーションサーバがサポートするバージョンの，SQL Server 2000 Driver for JDBCのJARファイルを入手して，J2EEサーバのクラスパスに指定してください。JARファイルの入手方法とクラスパスの指定方法について説明します。

Microsoft社のホームページからアプリケーションサーバがサポートするバージョン番号のSQL Server 2000 Driver for JDBCをダウンロードします。

J2EEサーバを動作させるマシンに，ダウンロードしたSQL Server 2000 Driver for JDBCをインストールします。

J2EEサーバのユーザクラスパスにJARファイルを指定します。
指定するJARファイルは，<SQL Server 2000 Driver for JDBCのインストールディレクトリ>¥libディレクトリ下にある次の三つのファイルです。

mssqlserver.jar

msbase.jar

msutil.jar

簡易構築定義ファイルでは，物理ティアの定義（<tier>タグの定義）のJ2EEサーバの定義で，<configuration>タグにJARファイルの設定を追加します。なお，指定するパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6.7　物理ティアの定義」を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
     :
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- SQLサーバを使用するための設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>add.class.path</param-name>
          <param-value><SQL Server Driver for JDBCのインストールディレクトリ>¥lib¥mssqlserver.jar</param-value>
          <param-name>add.class.path</param-name>
          <param-value><SQL Server Driver for JDBCのインストールディレクトリ>¥lib¥msbase.jar</param-value>
          <param-name>add.class.path</param-name>
          <param-value><SQL Server Driver for JDBCのインストールディレクトリ>¥lib¥msutil.jar</param-value>
       </param>
     </configuration>
   </tier>
     :
 </web-system>
 <host>
   :
</model-definition>

注　太字の部分が編集部分です。

J2EEサーバに，SQL Server用のDB Connector（DBConnector_SQLServer_CP.rar）をインポートします。
DB Connectorの詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6　データベースへの接続」を参照してください。
cjimportresコマンドを使用して，DBConnector_SQLServer_CP.rarをインポートしてください。

(3)　J2EEサーバ側での設定（SQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverの場合）

アプリケーションサーバがサポートするバージョンの，SQL Server 2005 JDBC DriverまたはSQL Server JDBC DriverのJARファイルを入手して，J2EEサーバのクラスパスに指定してください。JARファイルの入手方法とクラスパスの指定方法について説明します。

Microsoft社のホームページからアプリケーションサーバがサポートするバージョン番号のSQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverをダウンロードします。

J2EEサーバを動作させるマシンに，ダウンロードしたSQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverをインストールします。

J2EEサーバのユーザクラスパスにJARファイルを指定します。
指定するJARファイルは，<SQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverのインストールディレクトリ>¥sqljdbc_<バージョン>¥<language>ディレクトリ下にあるsqljdbc.jarです。
簡易構築定義ファイルでは，物理ティアの定義（<tier>タグの定義）のJ2EEサーバの定義で，<configuration>タグにJARファイルの設定を追加します。なお，指定内容については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<model-definition xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
 <!-- Webシステムの属性定義 -->
 <web-system>
   <name>MyWebSystem</name>
     :
   <!-- 物理ティア(combined-tier)の定義 -->
   <tier>
     <tier-type>combined-tier</tier-type>
     <!-- SQLサーバを使用するための設定 -->
     <configuration>
       <logical-server-type>j2ee-server</logical-server-type>
       <param>
          <param-name>add.class.path</param-name>
          <param-value><SQL Server Driver for JDBCのインストールディレクトリ>¥sqljdbc_<バージョン>¥<language>sqljdbc.jar</param-value>
     <!-- Windows認証を使用するための設定 -->
          <param-name>add.library.path</param-name>
          <param-value><SQL Server Driver for JDBCのインストールディレクトリ>¥sqljdbc_<バージョン>¥<language>¥auth¥<x86/x64/IA64></param-value>
       </param>
     </configuration>
   </tier>
     :
 </web-system>
 <host>
   :
</model-definition>

注　太字の部分が編集部分です。
Windows認証を使用する場合は，JARファイルの設定に加えて，次の設定も必要となります。なお，SQL Server 2005 JDBC Driverのバージョンが1.0の場合，Windows認証は使用できません。Windows認証を使用する場合に必要となる設定について説明します。

J2EEサーバのコンテナ拡張ライブラリのJNI用ライブラリの検索パスにdllファイルが格納されているディレクトリを指定します。
指定するディレクトリは，<SQL Server 2005 JDBC DriverまたはSQL Server JDBC Driverのインストールディレクトリ>¥sqljdbc_<バージョン>¥<language>¥auth¥<x86/x64/IA64>ディレクトリです。

J2EEサーバに，SQL Server用のDB Connector（DBConnector_SQLServer2005_CP.rar）をインポートします。
DB Connectorの詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6　データベースへの接続」を参照してください。
cjimportresコマンドを使用して，DBConnector_SQLServer2005_CP.rarをインポートしてください。

(4)　タイムアウトの設定

必要に応じて，SQL Serverのタイムアウトを設定してください。タイムアウトの設定については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.6.5　データベースでのタイムアウトを設定する」，およびSQL Serverのマニュアルを参照してください。

(5)　コネクション障害検知を行うための設定

コネクションの障害検知やリソースアダプタの接続テストのために，SQL Serverの接続ユーザには，sysobjectsオブジェクトのSELECT権限が必要です。sysobjectsオブジェクトのSELECT権限は，デフォルトで付いているので外さないでください。

付録D　セットアップウィザードで設定されるパラメタ

セットアップウィザードでシステムをセットアップした場合，システムの各パラメタには，次の値が使用されます。

画面で値を設定したパラメタ
設定した値が使用されます。

画面で値を設定していないパラメタ
簡易構築定義ファイルに指定できるパラメタの省略値が使用されます。
簡易構築定義ファイルに指定できるパラメタ，およびパラメタの省略値については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

ただし，2.のパラメタについては省略値と異なる値が設定されるものがあります。

ここでは，2.のパラメタのうち，省略値と異なる値が設定されるパラメタについて，設定される論理サーバごとに説明します。

＜この節の構成＞

付録D.1　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理Webサーバ）

付録D.2　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理J2EEサーバ）

付録D.3　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理パフォーマンストレーサ）

付録D.1　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理Webサーバ）

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタのうち，論理Webサーバに設定されるパラメタについて次の表に示します。パラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.13　論理Webサーバで指定できるパラメタ」を参照してください。

表D-1　パラメタの省略値と異なる値が設定されるパラメタ（論理Webサーバ）

パラメタ名
パラメタの省略値
セットアップウィザードで設定される値
説明

HWSKeepStartServers※1
Off
On
サーバプロセス稼働数が維持されます。

KeepAliveTimeout
15
3
KeepAlive接続時の要求待ち時間として3（単位：秒）を指定します。

Listen
－
80
リクエストを受け付けるポート番号として80を指定します。
「2.2.9　システム環境の設定」でWebサーバのポート番号を設定した場合，設定した値が有効になります。

MaxClients※1
150
20
同時に接続できるクライアントの最大数として20を指定します。

StartServers※1
5
20
Webサーバ起動時のサーバプロセス数として20を指定します。

ThreadsPerChild※2
50
20
サーバとして起動するスレッド数として20を指定します。なお，指定したスレッド数はサーバの最大同時接続数を示します。

JkMount
/* <J2EEサーバ名>
/* worker1
Hitachi Web Serverへのすべてのリクエストがworker1に転送されるようにします。

worker.<ワーカ名>※3.host
<ホスト名>※4
@myhost
ワーカのホスト名として@myhostを指定します。

worker.<ワーカ名>※3.port
<J2EEサーバのポート番号>※4
8007
ワーカのポート番号を8007にします。
「2.2.9　システム環境の設定」でajp13のポート番号を設定した場合，設定した値が有効になります。

worker.<ワーカ名>※3.receive_timeout
3600
120
通信タイムアウト値を120秒にします。

worker.list
<J2EEサーバ名>※4
worker1
ワーカ名としてworker1を指定します。

HttpsdCustomlogFormat
hws_std
"%h %l %u %t ¥"%r¥" %>s %b %T ¥"%{Referer}i¥" ¥"%{User-Agent}i¥" %P"
次の情報をHitachi Web Serverのカスタムログに出力します。

クライアントのホスト名

クライアントの識別情報

クライアントのユーザ名

リクエスト処理を開始した時刻

HTTP通信のリクエストの先頭行

最終ステータス

送信バイト数

リクエスト処理に掛かった時間

httpプロトコルヘッダのReferer値

httpプロトコルヘッダのUser-Agent値

HTTP通信のリクエストを処理するプロセスID

HttpsdErrorMethod
Div
Wrap
Hitachi Web Serverのエラーログをラップアラウンド方式で出力します。

（凡例）－：なし

注※1　使用するOSがUNIXの場合にだけ指定されます。

注※2　使用するOSがWindowsの場合にだけ指定されます。

注※3　<ワーカ名>はworker.listパラメタでworker1が指定されるため，worker1となります。

注※4　JKMountパラメタを省略すると指定されます。

付録D.2　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理J2EEサーバ）

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタのうち，論理J2EEサーバに設定されるパラメタについて次の表に示します。パラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.14　論理J2EEサーバで指定できるパラメタ」を参照してください。

表D-2　パラメタの省略値と異なる値が設定されるパラメタ（論理J2EEサーバ）

パラメタ名
パラメタの省略値
セットアップウィザードで設定される値
説明

ejbserver.connectionpool.applicationAuthentication.disabled
false
true
コンテナ管理のサインオンの最適化機能を有効にします。

ejbserver.ext.method_observation.interval
0
10
J2EEアプリケーション実行時間監視機能を使用します。また，タイムアウトとメソッドキャンセルを異なるスレッドで実行する時間間隔として10（単位：秒）を指定します。

ejbserver.jta.TransactionManager.defaultTimeOut
180
60
J2EEサーバ上で開始されるトランザクションのトランザクションタイムアウトの値として60（単位：秒）を指定します。

ejbserver.logger.channels.define.WebServletLogFile.filesize
4194304
16777216
Webサーブレットログのファイルサイズとして16777216（単位：バイト）を指定します。

webserver.connector.inprocess_http.enabled
false
true
インプロセスHTTPサーバ機能を有効にします。

add.jvm.arg
－
-Xms512m
Javaヒープメモリ領域の初期サイズとして512（単位：メガバイト）を指定します。

－
-Xmx512m
Javaヒープメモリ領域の最大サイズとして512（単位：メガバイト）を指定します。

－
-XX:PermSize=128m
Permanent領域の初期サイズとして128（単位：メガバイト）を指定します。

－
-XX:MaxPermSize=128m
Permanent領域の最大サイズとして128（単位：メガバイト）を指定します。

－
-XX:+HitachiVerboseGC
拡張verbosegc情報を出力します。

－
-XX:HitachiVerboseGCIntervalTime=0
拡張verbosegc情報を出力する時間の間隔として0（単位：秒）を指定します。

－
-XX:+HitachiVerboseGCPrintCause
ガーベージコレクションの要因内容を，拡張verbosegc情報の行末に出力します。

－
-XX:+HitachiOutputMilliTime
日立JavaVMログファイルに出力する日時に，ミリ秒まで出力します。

－
-XX:+HitachiCommaVerboseGC
拡張verbosegc情報の出力を，CSVファイルで取得できるようにコンマ形式で出力します。

－
-XX:HitachiJavaLogFileSize=4096k
JavaVMの作成するログファイルの最大サイズとして4096（単位：キロバイト）を指定します。

－
-XX:HitachiJavaLogNumberOfFile=4
JavaVMの作成するログファイルの最大数として4を指定します。

cpp.library.version

64ネイティブ版を使用する場合：6

それ以外を使用する場合：5

6
Linuxの場合に，プロセス内で使用するC++ライブラリのバージョンとして6を指定します。

ex.properties
－
sun.nio.cs.map=Windows-31J/Shift_JIS
JDK 5.0を使用する上での，Shift_JIS互換オプションを指定します。※

use.security
true
false
SecurityManagerを使用しません。

（凡例）－：なし

注※　Shift_JIS互換オプションを指定すると，エンコーディング名「Shift_JIS」が「MS932」の代替名として使用されます。

付録D.3　セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理パフォーマンストレーサ）

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタのうち，論理パフォーマンストレーサに設定されるパラメタについて次の表に示します。パラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.15　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

表D-3　パラメタの省略値と異なる値が設定されるパラメタ（論理パフォーマンストレーサ）

パラメタ名
パラメタの省略値
セットアップウィザードで設定される値
説明

mstartup.retrywait
0
60
自動再起動リトライ間隔として60（単位：秒）を指定します。

PrfTraceLevel
STANDARD
00140000
パフォーマンストレーサのトレース取得レベルを次のように指定します。

JCA/DB Connector
詳細

他機能レイヤ
標準

付録E　代替手段で実行できる運用作業

ここでは，アプリケーションサーバで実行できる運用作業を一覧で示します。実行できる運用作業には，システムで推奨する手段での作業，推奨外の作業および代替手段での作業を含みます。各運用作業の詳細やコマンドの使用方法については，参照先に示すマニュアルを確認してください。

＜この節の構成＞

付録E.1　システムの起動と停止

付録E.2　システムの運用監視

付録E.3　システムの処理性能解析

付録E.4　統合ユーザ管理のリソースの監視

付録E.5　J2EEアプリケーションとリソースの管理

付録E.6　システムの監査

付録E.7　トラブルシューティング

付録E.1　システムの起動と停止

システムの起動と停止で実行できる運用作業とその手段について，次の表に示します。

表E-1　システムの起動と停止で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
サービスユニットを一括起動する | cmx_start_targetコマンド | ◎ | コマンド編 | cmx_start_target（Webシステムまたはサービスユニットの開始）
サービスユニットを一括停止する | cmx_stop_targetコマンド | ◎ | コマンド編 | cmx_stop_target（Webシステムまたはサービスユニットの停止）
論理サーバを個別に，または一括で起動する | 運用管理ポータル | ○ | 運用管理ポータル | 11章
運用管理コマンド（mngsvrutil） | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
論理サーバを個別に，または一括で停止する | 運用管理ポータル | ○ | 運用管理ポータル | 11章
運用管理コマンド（mngsvrutil） | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
コマンドでサーバを起動する | サーバ管理コマンド（cjstartsv） | ○ | コマンド編 | cjstartsv（J2EEサーバの開始）
コマンドでサーバを停止する | サーバ管理コマンド（cjstopsv） | ○ | コマンド編 | cjstopsv（J2EEサーバの停止）
クラスタソフトウェアを使用したシステムを起動する | アプリケーションサーバのコマンド，クラスタソフトウェアの機能 | ◎ | 運用／監視／連携編 | 18章
クラスタソフトウェアを使用したシステムを停止する | アプリケーションサーバのコマンド，クラスタソフトウェアの機能 | ◎ | 運用／監視／連携編 | 18章

（凡例）

◎：推奨する作業

○：推奨外の作業，または代替手段での作業

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

付録E.2　システムの運用監視

システムの運用監視で実行できる運用作業とその手段について，次の表に示します。

表E-2　システムの運用監視で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
サービスユニットのステータスを確認する | cmx_list_statusコマンド | ○ | コマンド編 | cmx_list_status（サービスユニット状況の表示）
論理サーバのステータスを確認する | 運用管理コマンド（mngsvrutil） | ◎ | 運用／監視／連携編 | 2.5.2
運用管理ポータル | ○ | 運用管理ポータル | 13.4
Webシステム内のサービスユニットの構成を確認する | cmx_list_modelコマンド | ◎ | コマンド編 | cmx_list_model（Webシステムの情報モデルの取得）
稼働情報ファイルを参照して，J2EEサーバおよびSFOサーバの稼働情報を監視する | － | ◎ | 運用／監視／連携編 | 3章
J2EEサーバおよびSFOサーバの稼働情報を監視する※1 | 運用管理コマンド（mngsvrutil） | ○ | 運用／監視／連携編 | 8章
運用管理ポータル | ○ | 運用管理ポータル | 13.5
リソースの使用率や使用数を監視して，しきい値を超えた場合に原因を調査する | － | ◎ | 運用／監視／連携編 | 4章
稼働情報ファイルに出力される稼働情報，またはリソースの枯渇状況に応じてメッセージが出力された場合の処理を自動化する（Managementアクション） | － | ◎ | 運用／監視／連携編 | 9章
運用管理ドメイン内のCTMの稼働統計情報を確認する※2 | 運用管理コマンド（mngsvrutil） | ◎ | 運用／監視／連携編 | 10.2
CTMデーモン単位の稼働統計情報を確認する※2 | CTMのコマンド（ctmstsed） | ○ | コマンド編 | ctmstsed（稼働統計情報の編集と出力）
CTMのスケジュールキューの滞留状況を監視する※2，※3 | CTMのコマンド（ctmstart） | ○ | コマンド編 | ctmstart（CTMデーモンの開始）
トランザクションの状態を確認する | サーバ管理コマンド（cjlisttrn） | ◎ | 基本・開発編(コンテナ共通機能) | 3.15.9

（凡例）

◎：推奨する作業

○：推奨外の作業，または代替手段での作業

－：該当しない

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

基本・開発編(コンテナ共通機能)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を示します。

注※1　稼働情報ファイルを参照した稼働情報の監視で取得できる情報よりも詳細な情報を参照したい場合に，運用管理コマンドを使用した稼働情報の監視を行ってください。

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

注※3　Smart Composer機能を使用してCTMのスケジュールキューの滞留監視をする場合は，簡易構築定義ファイルで定義します。そのため，運用時の作業は必要ありません。

付録E.3　システムの処理性能解析

システムの処理性能解析で実行できる運用作業とその手段について，次の表に示します。

表E-3　システムの処理性能解析で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
性能解析トレースファイルを収集する | 運用管理コマンド（mngsvrutil） | ◎ | 保守／移行／互換編 | 6.3.1
PRFのコマンド（cprfed） | ○ | コマンド編 | cprfed（性能解析トレース情報の編集出力）
収集した性能解析トレースファイルを利用してシステムの処理性能を解析する | － | ◎ | 保守／移行／互換編 | 6.6
PRFトレース取得レベルを確認する | 運用管理ポータル | ○ | 運用管理ポータル | 10.3.1
PRFのコマンド（cprflevel） | ○ | コマンド編 | cprflevel（PRFトレース取得レベルの表示と変更）
PRFトレース取得レベルを変更する | 運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
運用管理ポータル | ○ | 運用管理ポータル | 10.3.1
PRFのコマンド（cprflevel） | ○ | コマンド編 | cprflevel（PRFトレース取得レベルの表示と変更）

（凡例）

◎：推奨する作業

○：推奨外の作業，または代替手段での作業

－：該当しない

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

付録E.4　統合ユーザ管理のリソースの監視

統合ユーザ管理のリソースの監視で実行できる運用作業とその手段について，次の表に示します。

表E-4　統合ユーザ管理のリソースの監視で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
統合ユーザ管理のリソースの使用状況を監視する | 運用管理ポータル | ○ | 運用管理ポータル | 15章

（凡例）

○：推奨外の作業，または代替手段での作業

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

付録E.5　J2EEアプリケーションとリソースの管理

J2EEアプリケーションとリソースの管理で実行できる運用作業とその手段について，次の表に示します。

表E-5　J2EEアプリケーションとリソースの管理で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
Webアプリケーションの稼働状況を確認する | 運用管理コマンド（mngsvrutil） | ◎ | 基本・開発編(Webコンテナ) | 2.19.2
運用管理ポータル | ○ | 運用管理ポータル | 13.14
アクセス状況に応じて，Webアプリケーションの同時実行スレッド数を動的に変更する | 運用管理コマンド（mngsvrutil） | ◎ | 基本・開発編(Webコンテナ) | 2.19.2
CTMのスケジュールキューの稼働状況を確認する※1 | 運用管理コマンド（mngsvrutil） | ◎ | 拡張編 | 3.6.3
CTMのコマンド（ctmlsque） | ○ | 拡張編 | 3.6.4
CTMのスケジュールキューの同時実行数を動的に変更する※1 | CTMのコマンド（ctmchpara） | ◎ | 拡張編 | 3.6.4
J2EEアプリケーションの実行状態を確認する | サーバ管理コマンド（cjlistthread） | ◎ | 運用／監視／連携編 | 5.3.11
J2EEアプリケーションでタイムアウトが発生したリクエストをキャンセルする | サーバ管理コマンド（cjstopthread） | ◎ | 運用／監視／連携編 | 5.3.12
J2EEアプリケーションを通常開始する | サーバ管理コマンド（cjstartapp） | ◎ | コマンド編 | cjstartapp（J2EEアプリケーションの開始）
運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
運用管理ポータル | ○ | 運用管理ポータル | 12.3.1
J2EEアプリケーションを通常停止する | サーバ管理コマンド（cjstopapp） | ◎ | コマンド編 | cjstopapp（J2EEアプリケーションの停止）
運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
運用管理ポータル | ○ | 運用管理ポータル | 12.3.2
J2EEアプリケーションを強制停止する | サーバ管理コマンド（cjstopapp） | ◎ | コマンド編 | cjstopapp（J2EEアプリケーションの停止）
運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
負荷分散機を使用してサービスを閉塞する※2 | 負荷分散機の機能 | ○ | 運用／監視／連携編 | 5.4.3
Webサーバのサービスを閉塞する | 運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
Hitachi Web Serverの機能 | ○ | Hitachi Web Server | －
CTMを利用してサービスを閉塞する※1 | 運用管理コマンド（mngsvrutil） | ○ | 拡張編 | 3.7.3
CTMのコマンド（ctmholdque） | ○ | コマンド編 | ctmholdque（スケジュールキューの閉塞）
J2EEサーバを停止してサービスを閉塞する | 運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
運用管理ポータル | ○ | 運用管理ポータル | 11.10.3
cjstopsvコマンド | ○ | コマンド編 | cjstopsv（J2EEサーバの停止）
J2EEアプリケーションの閉塞を解除する | サーバ管理コマンド（cjstartapp） | ○ | コマンド編 | cjstartapp（J2EEアプリケーションの開始）
運用管理コマンド（mngsvrutil） | ○ | コマンド編 | mngsvrutil（Management Serverの運用管理コマンド）
運用管理ポータル | ○ | 運用管理ポータル | 12.3.1
J2EEアプリケーションを入れ替える | 通常の入れ替え※3 | サーバ管理コマンド（cjstopapp，cjimportappなど） | ◎ | 運用／監視／連携編 | 5.6.3
運用管理ポータル | ○ | 運用管理ポータル | 4.3
リデプロイによる入れ替え | サーバ管理コマンド（cjreplaceapp） | ◎ | 運用／監視／連携編 | 5.6.3
リロードによる入れ替え | サーバ管理コマンド（cjreloadapp） | ◎ | 運用／監視／連携編 | 5.6.3
JSPを事前にコンパイルしてから，J2EEアプリケーションを入れ替える | cjjspcコマンド | ◎ | 運用／監視／連携編 | 5.6.3
J2EEアプリケーションの名称を変更する | サーバ管理コマンド（cjrenameapp） | ◎ | 運用／監視／連携編 | 5.6.3
Webアプリケーションのサービス部分閉塞を利用してJ2EEアプリケーションを入れ替える | 運用管理ポータル | ○ | 運用／監視／連携編 | 5.4
CTMを利用して，オンライン状態でJ2EEアプリケーションを入れ替える※1 | 運用管理コマンド（mngsvrutil） | ◎ | 拡張編 | 3.7.2
J2EEアプリケーションを本番環境でテストしてから本番運用を開始する | サーバ管理コマンド（cjimportapp，cjstartapp） | ◎ | 運用／監視／連携編 | 5.7.5，5.7.6
コネクションプールの情報を表示する | サーバ管理コマンド（cjlistpool） | ◎ | 基本・開発編(コンテナ共通機能) | 3.15.4
コマンド編 | cjlistpool（コネクションプールの一覧表示）
コネクションプールをクリアする | サーバ管理コマンド（cjclearpool） | ◎ | 基本・開発編(コンテナ共通機能) | 3.15.5
コマンド編 | cjclearpool（コネクションプール内のコネクション削除）
JavaBeansリソースを入れ替える | サーバ管理コマンド（cjdeletejb，cjimportjb） | ◎ | 基本・開発編(コンテナ共通機能) | 3.12.5
クラスタ構成のデータベースの場合に，コネクションプールの状態を表示する | サーバ管理コマンド（cjlistrar） | ◎ | 基本・開発編(コンテナ共通機能) | 3.17.4
クラスタ構成のデータベースの場合に，コネクションプールを一時停止する | サーバ管理コマンド（cjsuspendpool） | ◎ | 基本・開発編(コンテナ共通機能) | 3.17.4
クラスタ構成のデータベースの場合に，コネクションプールを再開する | サーバ管理コマンド（cjresumepool） | ◎ | 基本・開発編(コンテナ共通機能) | 3.17.4
リソースの接続テストをする | サーバ管理コマンド（cjtestres） | ◎ | 基本・開発編(コンテナ共通機能) | 3.18
コマンド編 | cjtestres（リソースの接続テスト）
運用管理ポータル | ○ | 運用管理ポータル | 12.4.3

（凡例）

◎：推奨する作業

○：推奨外の作業，または代替手段での作業

－：該当しない

基本・開発編(Webコンテナ)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」を示します。

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

拡張編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」を示します。

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

Hitachi Web Server：マニュアル「Hitachi Web Server」を示します。

アプリケーション設定：マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」を示します。

基本・開発編(コンテナ共通機能)：マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を示します。

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

注※2　負荷分散機をSmart Composer機能で管理していない場合に実行します。負荷分散機をSmart Composer機能で管理している場合は，cmx_stop_targetコマンドを使用してサービスを閉塞してください。cmx_stop_targetコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cmx_stop_target（Webシステムまたはサービスユニットの停止）」を参照してください。

注※3　J2EEアプリケーションの通常の入れ替えは，J2EEアプリケーションの停止，J2EEアプリケーションの削除，J2EEアプリケーションのインポートの順に実行してください。

付録E.6　システムの監査

システムの監査で実行できる運用作業とその手段について，次の表に示します。

表E-6　システムの監査で実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
監査ログを出力して，管理する | － | ◎ | 運用／監視／連携編 | 6章
監査ログを収集して調査する | － | ◎ | 運用／監視／連携編 | 17章
データベース監査証跡に出力された情報を基に，データベースにアクセスしたリクエストの情報を特定する | － | ◎ | 運用／監視／連携編 | 7章

（凡例）

◎：推奨する作業

－：該当しない

運用／監視／連携編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」を示します。

付録E.7　トラブルシューティング

トラブルシューティングで実行できる運用作業とその手段について，次の表に示します。

表E-7　トラブルシューティングで実行できる運用作業とその手段

運用作業 | 手段 | 推奨 | 参照先マニュアル | 参照個所
トラブルシューティングに必要な資料を収集する | 運用管理コマンド（mngsvrutil） | ◎ | 保守／移行／互換編 | 2.3.3
運用管理ポータル | ○ | 運用管理ポータル | 11.9.5，11.10.5，11.11.9
snapshotlogコマンド | ○ | コマンド編 | snapshotlog（snapshotログの収集）
論理サーバに異常が発生した場合の処理を自動化する | － | ◎ | 保守／移行／互換編 | 2.2.2
トラブルシューティングに必要な資料を調査する | － | ◎ | 保守／移行／互換編 | 5章

（凡例）

◎：推奨する作業

○：推奨外の作業，または代替手段での作業

－：該当しない

保守／移行／互換編：マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を示します。

運用管理ポータル：マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」を示します。

コマンド編：マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を示します。

付録F　アプリケーションサーバが提供するサンプルプログラム

アプリケーションサーバでは，次に示すサンプルプログラムを提供しています。

Enterprise Bean（EJB2.0）のサンプルプログラム

Enterprise Bean（アノテーション）のサンプルプログラム

Enterprise Bean（Timer Service）のサンプルプログラム

JPAのサンプルプログラム

Java Beansリソースのサンプルプログラム

ユーザログ機能のサンプルプログラム

Webアプリケーションのサンプルプログラム

TP1インバウンド連携機能のサンプルプログラム

注意

提供しているサンプルプログラムは，わかりやすさを優先するため，紹介している多くのコードで，エラー処理やセキュリティ脆弱性問題を回避するための処理などを省略しています。そのため，サンプルプログラムを悪意のある第三者から攻撃された場合は，重大な問題が発生するおそれがあります。本番環境ではサンプルプログラムを使用しないでください。サンプルプログラムを本番環境で使用して，サンプルプログラムを原因とする問題が発生しても保証しません。

ここでは，各サンプルの概要，サンプルの実行手順，およびサンプルの実行例を説明します。なお，サンプルプログラムは，サーバ管理コマンドを使用した実行手順と実行例について説明しています。

注意

UNIX環境で使用する場合は，本文を次のとおりに読み替えてください。

Windows用のディレクトリ（<Cosminexusのインストールディレクトリ>¥）を，UNIX用のディレクトリ（/opt/Cosminexus/）に読み替えてください。

Windows環境で使用するバッチファイルは，UNIX環境ではシェルスクリプトになります。拡張子を除いて読み替えてください。
（例）Windows環境：testClient.bat，UNIX環境：testClient

また，07-50以降は，EJBクライアントアプリケーションの開始に，cjclstartapコマンドを使用します。cjclstartapコマンドの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjclstartap（Javaアプリケーションの開始）」を参照してください。

なお，アプリケーションサーバが提供するサンプルプログラムを実行する場合は，書き込み権限のある別のディレクトリへサンプルプログラムをコピーして使用することをお勧めします。

＜この節の構成＞

付録F.1　サーバ管理コマンドによるサンプル実行環境の構築，運用手順

付録F.2　Enterprise Bean（EJB2.0）のサンプルプログラム

付録F.3　Enterprise Bean（アノテーション）のサンプルプログラム

付録F.4　Enterprise Bean（Timer Service）のサンプルプログラム

付録F.5　JPAのサンプルプログラム

付録F.6　JavaBeansリソースのサンプルプログラム

付録F.7　ユーザログ機能のサンプルプログラム

付録F.8　Webアプリケーションのサンプルプログラム

付録F.9　TP1インバウンド連携機能のサンプルプログラム

付録F.1　サーバ管理コマンドによるサンプル実行環境の構築，運用手順

ここでは，サーバ管理コマンドを使用してサンプルプログラムを実行する場合のJ2EEサーバの構築，運用手順を説明します。この手順は，付録F.2以降の各サンプルプログラムを実行するときに必要になります。

＜この項の構成＞

(1)　J2EEサーバのセットアップ

(2)　J2EEサーバのカスタマイズ

(3)　J2EEサーバの起動

(4)　リソースアダプタの設定

(5)　アプリケーションのインポート，設定，および開始

(6)　アプリケーションの停止，削除

(7)　J2EEサーバの終了

(1)　J2EEサーバのセットアップ

コマンドプロンプトでcjsetupコマンドを入力し，J2EEサーバをセットアップします。セットアップの実行例を次に示します。実行例では，「MyServer」という名称のJ2EEサーバをセットアップしています。

C:¥> cd Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>cjsetup MyServer
KDJE40001-I The setup for the J2EE server has finished successfully. Server name = MyServer
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>

(2)　J2EEサーバのカスタマイズ

アプリケーションにアクセスするための設定をします。アプリケーションにアクセスするには，次のどちらかの方法を使用します。

Webサーバと連携する。

J2EEサーバのインプロセスHTTPサーバ機能を使用する。

ここでは，設定や運用が容易なJ2EEサーバのインプロセスHTTPサーバ機能を使用する方法を説明します。

インプロセスHTTPサーバ機能を有効にするため，ユーザ定義ファイル（usrconf.properties）にプロパティキーを定義します。

ユーザ定義ファイルの格納先：

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥usrconf¥ejb¥MyServer¥usrconf.properties

定義するプロパティキー：

webserver.connector.inprocess_http.enabled=true

注意

インプロセスHTTPサーバでは，80番ポートをデフォルトで使用します。ポート番号を変更するには，ユーザ定義ファイル（usrconf.properties）に，webserver.connector.inprocess_http.portプロパティキーを定義します。

インプロセスHTTPサーバで使用するポート番号に8081番を定義する例を示します。

webserver.connector.inprocess_http.port=8081

(3)　J2EEサーバの起動

cjstartsvコマンドでセットアップ済みのJ2EEサーバを起動します。

C:¥> cd Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>cjstartsv MyServer
＜起動ログが出力される＞
 ：
KDJE30028-I The J2EE server has started. Server name = MyServer

(4)　リソースアダプタの設定

次の手順でリソースアダプタの設定をします。

cjimportresコマンドでリソースアダプタをインポートします。

cjdeployrarコマンドを使用して，リソースアダプタをデプロイします。

cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。

cjtestresコマンドを使用して，リソースアダプタのテストをします。

cjstartrarコマンドを使用して，リソースアダプタを開始します。

(5)　アプリケーションのインポート，設定，および開始

サンプルで提供するバッチファイル（deployApp.bat）を使用して，アプリケーションを操作します。このバッチファイルでは，アプリケーションのJ2EEサーバへのインポートから，設定，開始が実行されます。

このバッチファイルで実行される処理の内容を示します。

cjimportappコマンドが実行され，アプリケーションがJ2EEサーバにインポートされます。

cjstartappコマンドが実行され，アプリケーションが開始されます。

cjlistappコマンドが実行され，J2EEサーバ上のアプリケーションの状態が一覧表示されます。この一覧を確認することで，アプリケーションが稼働状態（running）になっていることを確認できます。

(6)　アプリケーションの停止，削除

サンプルで提供するバッチファイル（unDeployApp.bat）を使用して，アプリケーションを操作します。このバッチファイルでは，アプリケーションの停止とJ2EEサーバからの削除が実行されます。

このバッチファイルで実行される処理の内容を示します。

cjstopappコマンドが実行され，アプリケーションが停止します。

cjdeleteappコマンドが実行され，アプリケーションがJ2EEサーバから削除されます。

cjlistappコマンドが実行され，J2EEサーバ上のアプリケーションの状態が一覧表示されます。この一覧を確認することで，アプリケーションが削除されたことを確認できます。

(7)　J2EEサーバの終了

cjstopsvコマンドでJ2EEサーバを終了します。

cjstopsvコマンドのコンソール

> cd Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>cjstopsv MyServer
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>

J2EEサーバのコンソール

C:¥> cd Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>cjstartsv MyServer
＜起動ログが出力される＞
 ：
KDJE30028-I The J2EE server has started. Server name = MyServer
 ：
<終了ログが出力される>
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥server¥bin>

付録F.2　Enterprise Bean（EJB2.0）のサンプルプログラム

Enterprise Bean（EJB2.0）を使用したサンプルプログラムは，次に示すディレクトリに格納されています。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥ejb¥ejb20

ここでは，サンプルプログラムの一覧，実行例，および各サンプルプログラムの概要について説明します。

＜この項の構成＞

(1)　Enterprise Bean（EJB2.0）のサンプルプログラム一覧

(2)　Enterprise Bean（EJB2.0）のサンプル実行手順

(3)　Enterprise Bean（EJB2.0）のサンプルの概要

(1)　Enterprise Bean（EJB2.0）のサンプルプログラム一覧

サンプルプログラムの一覧およびサンプルプログラム実行時の注意事項を示します。サンプルプログラムの一覧は，Enterprise Beanの種類と動作概要をまとめた一覧と，利用する技術，リソース，および動作モードをまとめた一覧に分けて示します。

注意

Enterprise Beanのサンプルプログラムは，現在使用している製品のバージョン・リビジョンのものを使用してください。旧バージョン・リビジョンのサンプルプログラムの動作は保証されません。

(a)　サンプルプログラム一覧（Enterprise Beanの種類と動作内容）

表F-1　サンプルプログラムの一覧（Enterprise Beanの種類と動作内容）

サンプル名 | Enterprise Bean種別 | パーシスタンス | トランザクション | 動作概要
account | Entity Bean | BMP | － | 預金や払い戻しに応じて残高を計算し，データベースを更新します。
adder | Stateful Session Bean | － | CMT | 入力数値の合計を計算して，ブラウザ上に表示します。
bank | Stateful Session Bean | － | CMT | 当座預金口座から普通預金口座に資金を移動し，データベースを更新します。
cart | Stateful Session Bean | － | CMT | 購入する本をショッピングカートに入れます。カートにない本をカートから出そうとした場合は，例外を発生させます。
checker | Stateful Session Bean | － | CMT | 割引対象となる金額を超えた場合，割引率を基に割引後の金額を計算します。割引対象となる金額と割引率は，Enterprise Beanの環境エントリで指定します。
cmp20product | Entity Bean | CMP2.0 | － | 商品情報をデータベースに登録し，登録された商品情報を検索します。このサンプルは，CMP 2.0形式のEnterprise Beanを利用します。
confirmer | Stateless Session Bean | － | CMT | 商品の注文に対する確認メールを送信します。
converter | Stateless Session Bean | － | CMT | 通貨の種類をドルから円，円からユーロに変換します。
enroller | Stateless Session Bean | － | CMT | 学生と科目の追加，および受講登録をして，データベースを更新します。
Entity Bean | BMP | －
jsptag※ | Stateless Session Bean | － | CMT | 通貨の種類をドルから円，円からユーロに変換します。このサンプルは，JSPを利用してブラウザ上に表示します。
jsptobean | Entity Bean | BMP | － | 預金や払い戻しに応じて残高を計算し，データベースを更新します。残高は，JSPを利用してブラウザ上に表示します。
localadder | Stateful Session Bean | － | CMT | 入力数値の合計を計算して，ブラウザ上に表示します。このサンプルは，サーブレットからローカルインタフェースを利用してEnterprise Beanを呼び出します。
message | Stateless Session Bean | － | CMT | JMSのキューを利用して，メッセージを送受信します。
Message -driven Bean | － | CMT
order | Entity Bean | BMP | － | 注文番号と対応する商品情報を検索して表示します。注文番号と商品情報はデータベースで管理します。
product | Entity Bean | CMP | － | 商品情報をデータベースに登録し，登録された商品情報を検索します。
salesrep | Entity Bean | BMP | － | 顧客の追加と，担当する販売員の変更を行い，データベースを更新します。
shipper | Stateful Session Bean | － | CMT | 注文に対する商品在庫を計算し，データベースを更新します。在庫が一定の数量を下回った場合，引き当て処理を呼び出します。
Entity Bean | BMP | －
storagebin | Entity Bean | BMP | － | データベースの部品情報テーブルと部品在庫情報テーブルから，対応する部品の情報と在庫を検索します。
teller | Stateful Session Bean | － | BMT | 銀行用端末機から当座預金のお金を引き出し，残高を計算します。
warehouse | Stateless Session Bean | － | CMT | 注文を受けた商品の状態，および商品の在庫を更新します。

（凡例）

－：該当しないことを示します。

注※　jsptagサンプルをコンパイルおよびアーカイブしたEARファイル（converter.ear）も提供しています。

(b)　サンプルプログラムの一覧（接続するリソース，クライアントの種類，動作モード）

サンプルプログラムの一覧と，接続するリソース，クライアントの種類，動作モードを次の表に示します。

表F-2　サンプルプログラム一覧（接続するリソース，クライアントの種類，動作モード）

サンプル | 接続するリソース※1 | クライアントの種類※2 | 動作モード
データベース | メール | JMS | EJBクライアントアプリケーション | Webブラウザ | B | 1.4
account | ○ | － | － | ○ | － | ◎ | ◎
adder | － | － | － | － | ○ | ◎ | ◎
bank | ○ | － | － | ○ | － | ◎ | ◎
cart | － | － | － | ○ | － | ◎ | ◎
checker | － | － | － | ○ | － | ◎ | ◎
confirmer | － | ○ | － | ○ | － | ◎ | ◎
converter | － | － | － | ○ | － | ◎ | ◎
enroller | ○ | － | － | ○ | － | ◎ | ◎
jsptag | － | － | － | － | ○ | ◎ | ◎
jsptobean | ○ | － | － | － | ○ | ◎ | ◎
order | ○ | － | － | ○ | － | ◎ | ◎
product | ○ | － | － | ○ | － | ◎ | ◎
salesrep | ○ | － | － | ○ | － | ◎ | ◎
shipper | ○ | － | － | ○ | － | ◎ | ◎
storagebin | ○ | － | － | ○ | － | ◎ | ◎
teller | ○ | － | － | ○ | － | ◎ | ◎
warehouse | ○ | － | － | ○ | － | ◎ | ◎
message | － | － | ○ | ○ | － | × | ◎
cmp20product | ○ | － | － | ○ | － | × | ◎
localadder | － | － | － | － | ○ | × | ◎

（凡例）

B：ベーシックモードを意味します。

1.4：1.4モードを意味します。

○：該当することを示します。　－：該当しないことを示します。

◎：実行できることを示します。　×：実行できないことを示します。

注※1　接続するリソースごとに，必要な設定があります。接続するリソースに応じて，「付録F.2(1)(c)　サンプルプログラムで使用するデータベースの設定」，「付録F.2(1)(d)　サンプルプログラムで使用するメールの設定」または「付録F.2(1)(e)　サンプルプログラムで使用するJMSの設定」を参照してください。

注※2　クライアントの種類に応じて，実行方法などが異なります。詳細は，「付録F.2(1)(f)　サンプルプログラムのクライアントの種類」を参照してください。

(c)　サンプルプログラムで使用するデータベースの設定

ここでは，サンプルプログラムで使用するデータベースの設定について説明します。

表F-2の「データベース」列に「○」が付いているサンプルプログラムでは，リソースとしてデータベースを利用します。サンプルプログラムを実行する前に，データベースおよびデータベース接続関連の設定を適切にしてください。

なお，データベースとして利用できるのは，OracleまたはHiRDBです。

必要な設定を次に示します。

HiRDBを利用する場合は，HiRDB Version 8 08-01以降を利用してください。また，外部キーの指定（参照制約）を有効に設定してください。
設定方法については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。

利用するデータベース種別に従って，サンプルが提供する「createTable_Oracle.sql」（Oracleの場合）または「createTable_HiRDB.sql」（HiRDBの場合）を実行して，データベースのテーブルを初期化してください。なお，HiRDBを利用する場合，外部キーの指定（参照制約）が有効になっていないと，「createTable_HiRDB.sql」の実行に失敗します。

サーバ管理コマンドでDB Connectorまたはデータソースの設定をします。どちらを利用するかは，J2EEサーバの動作モードによって異なります。
J2EEサーバの動作モードが1.4モードの場合，DB Connectorを利用します。このとき，「DBConnector_DABJ_CP.rar」を利用することをお勧めします。「DBConnector_DABJ_XA.rar」を利用した場合は，ライトトランザクション機能が無効になるように設定してからJ2EEサーバを起動して，DB Connectorを設定します。ライトトランザクション機能は，usrconf.propertiesのejbserver.distributedtx.XATransaction.enabledキーにtrueを指定すると無効になります。
なお，J2EEサーバの動作モードがベーシックモードの場合は，データソースを利用してください。

必要に応じてリソースのリンクを解決します。DB Connectorとして「DBConnector_DABJ_XA.rar」を利用する場合，またはデータソースを利用する場合は，リンクの解決が必要です。なお，DB Connectorとして「DBConnector_DABJ_CP.rar」を利用する場合は，DB Connectorのデフォルトの表示名を変更したときだけリンクの解決が必要です。
リンクの解決には，サンプルで提供するCosminexusアプリケーション属性ファイル「cosminexus.xml」を利用します。「cosminexus.xml」の<resource-ref>タグにリソースの表示名を指定して，サーバ管理コマンドを利用して設定してください。リソースのリンク解決をしてから，アプリケーションのデプロイ操作をしてください。

サンプルプログラムのうち，「product」と「cmp20product」では，「cosminexus.xml」の<schema-name>タグに「user1」が設定されています。利用するデータベース環境に応じて，適切な値に変更してからアプリケーションのデプロイ操作を実行してください。

サンプルプログラムのうち，「teller」の実行にHiRDBを使用する場合，TellerEJB.javaファイル中の日付指定関数を指定している個所を，HiRDB用に書き換えてコンパイルしてください。

(d)　サンプルプログラムで使用するメールの設定

ここでは，サンプルプログラムで使用するメールの設定について説明します。

表F-2の「メール」列に「○」が付いているサンプルプログラムでは，リソースとしてメールを利用します。サンプルプログラムを実行する前に，メールサーバへの接続関連の設定を適切にしてください。

必要な設定を次に示します。

EJBクライアントアプリケーションのソースファイル（ConfirmerClient.java）に，受信メールアドレスがコーディングされています。この個所を適切な受信メールアドレスに書き換えてからコンパイルしてください。

サーバ管理コマンドでメールコンフィグレーションを設定する必要があります。サーバ管理コマンドの利用方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「6.3　メールコンフィグレーションの設定」を参照してください。

リソースのリンクを解決します。ただし，メールコンフィグレーションの表示名を「Cosminexus_SMTP_Server」と定義した場合は，リンクの解決は不要です。これ以外の表示名を定義した場合は，リンクを解決してください。
リンクの解決には，サンプルで提供するCosminexusアプリケーション属性ファイル「cosminexus.xml」を利用します。「cosminexus.xml」の<resource-ref>タグにリソースの表示名を指定して，サーバ管理コマンドで設定してください。リソースのリンク解決をしてから，アプリケーションのデプロイ操作をしてください。

(e)　サンプルプログラムで使用するJMSの設定

ここでは，サンプルプログラムで使用するJMSの設定について説明します。

表F-2の「JMS」列に「○」が付いているサンプルプログラムでは，リソースとしてJMSを利用します。サンプルプログラムを実行する前に，JMSへの接続関連の設定を適切にしてください。

必要な設定を次に示します。

JMSとしてTP1/Message Queue - Accessを使用するため，あらかじめTP1/Message Queue - Accessをインストールしておきます。また，OpenTP1および TP1/Message Queueのサーバ実行環境もあらかじめ準備しておきます。

サーバ管理コマンドによって，TP1/Message Queue - Accessの設定をします。
ライトトランザクション機能を無効にしてJ2EEサーバを起動してから，TP1/Message Queue - Accessの設定をします。なお，ライトトランザクション機能は，usrconf.propertiesのejbserver.distributedtx.XATransaction.enabledキーにtrueを指定すると無効になります。
また，TP1/Message Queue - Accessのトランザクションサポートレベルを，「XATransaction」にしてください。

リソースのリンクを解決します。ただし，TP1/Message Queue - Accessのデフォルトの表示名を変更しないで，かつ，キュー定義ファイルに表示名が「QUEUE1」となるキューを定義している場合，リンクの解決は不要です。TP1/Message Queue - Accessのデフォルトの表示名を変更した場合や，キュー定義ファイルに表示名が「QUEUE1」となるキューを定義していない場合は，リンクの解決が必要です。
リンクの解決には，サンプルで提供するCosminexusアプリケーション属性ファイル「cosminexus.xml」を利用します。「cosminexus.xml」の<resource-ref>タグ，<resource-env-ref>タグ，および<message-ref>タグにリソースの表示名を指定して，サーバ管理コマンドで設定してください。リソースのリンク解決をしてから，アプリケーションのデプロイ操作をしてください。

(f)　サンプルプログラムのクライアントの種類

サンプルプログラムのクライアントには，EJBクライアントアプリケーションと，Webブラウザで表示するアプリケーションの2種類があります。

表F-2の「EJBクライアントアプリケーション」列に「○」が付いているサンプルプログラムは，EJBクライアントアプリケーションです。サンプルとして提供されている「testClient.bat」を使用して，クライアントアプリケーションを開始してください。

表F-2の「Webブラウザ」列に「○」が付いているサンプルプログラムは，Webブラウザから操作するWebアプリケーションです。クライアントから操作する場合は，Webブラウザを起動して，次のURLを指定してください。

http://<マシン名>:<ポート番号>/<ContextRoot>/<ターゲットファイル>

例えば，ローカルホストで動作するサンプル「adder」の場合は，次のように指定します。

http://localhost/adder/adder_war/adder.html

(2)　Enterprise Bean（EJB2.0）のサンプル実行手順

converterを例に，サンプルの実行例を示します。converterは，クライアントのJavaアプリケーションからEnterprise Beanを呼び出すプログラムです。データベースなどのリソースは利用しません。リソースを利用する場合は，ここで示す手順に加え，リソースにアクセスできる環境を整える必要があります。リソースの設定方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3　リソース接続」を参照してください。

(a)　converterの概要

通貨の種類をドルから円，円からユーロに変換します。converterの構成を次に示します。

図F-1　converterの構成

(b)　コンパイル

サンプルで提供するバッチファイル（compileBean.batおよびcompileClient.bat）を使用して，Enterprise Beanとクライアントをコンパイルします。このバッチファイルで，アプリケーション（.earファイル）が作成されます。

C:¥>cd C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥converter
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥...¥converter>compileBean
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥...¥converter>
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥...¥converter>compileClient
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥...¥converter>

(c)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(d)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(e)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(f)　アプリケーションのデプロイ

サンプルで提供するバッチファイル（deployApp.bat）を使用して，アプリケーションをデプロイします。このバッチファイルでは，アプリケーションのJ2EEサーバへのインポートから，アプリケーションの設定，開始，EJBのスタブおよびインタフェースファイルの取得までが実行されます。

このバッチファイルで実行される処理の内容を示します。

アプリケーションのインポート，設定，開始，一覧表示
実行内容については，「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

Enterprise Beanのスタブ・インタフェースファイルの取得
cjgetsubsjarコマンドで，Enterprise Beanのスタブとインタフェースを取得します。

(g)　アプリケーションの実行

サンプルで提供するバッチファイル（testClient.bat）を使用して，アプリケーションを実行します。実行後，EJBクライアントアプリケーションの起動コンソール画面に次のように表示されれば成功です。

C:¥>cd C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ ejb¥ejb20¥converter
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ ejb¥ejb20¥converter>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥converter, PID = 3684)
12160.0
0.77
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ ejb¥ejb20¥converter>

(h)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(i)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

(3)　Enterprise Bean（EJB2.0）のサンプルの概要

Enterprise Bean（2.0）のサンプルの概要，構成，実行例を示します。なお，必要な設定については，「付録F.2(1)(b)　サンプルプログラムの一覧（接続するリソース，クライアントの種類，動作モード）」を参照してください。

(a)　accountの概要

預金や払い戻しに応じて残高を計算し，銀行口座テーブルを更新します。accountの構成を次に示します。

図F-2　accountの構成

accountの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥account>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥account, PID = 3684)
balance = 68.25
balance = 32.55
456: 44.77
730: 19.54
268: 100.07
456: 44.77
836: 32.55
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥account>

(b)　adderの概要

ブラウザから入力された数値の合計を計算します。adderの構成を次に示します。

図F-3　adderの構成

実行時には，ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/adder.html

インプロセスHTTPサーバが使用できる場合，デフォルトでは次のURLを指定します。

http://localhost/adder/adder_war/adder.html

adderの実行例を示します。

図F-4　adderの実行例

(c)　bankの概要

当座預金口座から普通預金口座に資金を移動します。資金はデータベースで管理し，資金移動時に，対応する当座預金口座テーブルと普通預金口座テーブルを更新します。bankの構成を次に示します。

図F-5　bankの構成

bankの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥bank>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥bank, PID = 3684)
checking: 60.0
saving: 540.0
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥bank>

(d)　cartの概要

本を購入するショッピングカートです。3冊の本をカートに入れ，カートにない本1冊をカートから出そうとして「BookException」を発生させます。cartの構成を次に示します。

図F-6　cartの構成

cartの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥cart>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥cart, PID = 3684)
The Martian Chronicles
2001 A Space Odyssey
The Left Hand of Darkness
Caught a BookException： Alice in Wonderland not in cart.
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥cart>

(e)　checkerの概要

割引対象となる金額を超えた場合，割引率を基に割引後の金額を計算します。割引対象となる金額と割引率は，Enterprise Beanの環境エントリで指定します。checkerの構成を次に示します。

図F-7　checkerの構成

checkerの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥checker>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥checker, PID = 3684)
discount = 4200.0
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥checker>

(f)　cmp20productの概要

商品情報をデータベースに登録し，登録された商品情報を検索します。このサンプルは，CMP 2.0形式のEnterprise Beanを利用します。cmp20productの構成を次に示します。

図F-8　cmp20productの構成

cmp20productの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥cmp20product>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥cmp20product, PID = 3684)
Ceramic Dog: 10.0
Ceramic Dog: 14.0
Chrome Fish: 22.0
999: Ivory Cat 19.0
789: Ivory Cat 33.0
123: 14.0
456: 13.0
999: 19.0
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥cmp20product>

(g)　confirmerの概要

商品の注文に対する確認メールを送信します。confirmerの構成を次に示します。

図F-9　confirmerの構成

confirmerのクライアント（メール送信側）の実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥confirmer>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥confirmer, PID = 3684)
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥confirmer>

クライアント実行後，ConfirmerClient.javaで指定したアドレスにメールが送信されます。受信されるメールの例を示します。

件名:"Test Message from ConfirmerEJB"
文面:
Thank you for your order.
We received your order on 2002/03/18 12:35.

(h)　converterの概要

converterについては，「付録F.2(2)　Enterprise Bean（EJB2.0）のサンプル実行手順」を参照してください。

(i)　enrollerの概要

学生と科目の追加，および受講登録をして，対応する学生情報テーブル，科目テーブル，受講登録情報テーブルを更新します。enrollerの構成を次に示します。

図F-10　enrollerの構成

enrollerの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥enroller>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥enroller, PID = 3684)
Denise Smith:
220 Power J2EE Programming
333 XML Made Easy
777 An Introduction to Java Programming

An Introduction to Java Programming:
823 Denise Smith
456 Joe Smith
388 Elizabeth Willis
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥enroller>

(j)　jsptagの概要

通貨の種類をドルから円，円からユーロに変換します。変換した結果は，JSPを利用して，ブラウザに表示します。jsptagの構成を次に示します。

図F-11　jsptagの構成

実行時には，ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/Converter.jsp

インプロセスHTTPサーバが使用できる場合，デフォルトでは次のURLを指定します。

http://localhost/jsptag/converter_war/Converter.jsp

jsptagの実行例を示します。

図F-12　jsptagの実行例

(k)　jsptobeanの概要

預金や払い戻しに応じて残高を計算し，データベースを更新します。残高は，JSPを利用してブラウザ上に表示します。jsptobeanの構成を次に示します。

図F-13　jsptobeanの構成

実行時には，ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/Account.jsp

インプロセスHTTPサーバが使用できる場合，デフォルトでは次のURLを指定します。

http://localhost/jsptobean/account_war/Account.jsp

jsptobeanの実行例を示します。

図F-14　jsptobeanの実行例

(l)　localadderの概要

入力数値の合計を計算して，ブラウザ上に表示します。このサンプルは，サーブレットからローカルインタフェースを利用してEnterprise Beanを呼び出します。localadderの構成を次に示します。

図F-15　localadderの構成

実行時には，ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/adder.html

インプロセスHTTPサーバが使用できる場合，デフォルトでは次のURLを指定します。

http://localhost/localadder/localadder_war/adder.html

localadderの実行例を示します。

図F-16　localadderの実行例

(m)　messageの概要

Session BeanからJMSのQueueへ送信したメッセージを，Message-driven Beanで受信します。messageの構成を次に示します。

図F-17　messageの構成

messageのクライアントの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥message>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥message, PID = 3684)
sending message=MY MESSAGE
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥message>

クライアント実行後，メッセージの送受信が正常に完了した場合は，J2EEサーバの起動コンソール上に次のように表示されます。

...
MessageBean: onMessage（）
MessageBean: received message=MY MESSAGE
...

(n)　orderの概要

注文番号と対応する商品情報を検索して表示します。注文番号と商品情報は，それぞれ注文情報テーブルと商品情報テーブルで管理します。orderの構成を次に示します。

図F-18　orderの構成

orderの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥order>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥order, PID = 3684)
about to create
123 1 p23 12.0
123 2 p67 89.0
123 3 p11 41.0

123
456
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥order>

(o)　productの概要

商品名や価格などの商品情報をデータベースに登録し，登録された商品情報を検索します。商品情報は，商品情報テーブルで管理します。productの構成を次に示します。

図F-19　productの構成

productの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥product>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥product, PID = 3684)
Ceramic Dog: 10.0
Ceramic Dog: 14.0
Chrome Fish: 22.0
999: Ivory Cat 19.0
789: Ivory Cat 33.0
123: 14.0
456: 13.0
999: 19.0
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥product>

(p)　salesrepの概要

顧客の追加と，担当する販売員の変更を行い，データベースを更新します。二つのEnterprise Beanを連携し，顧客テーブルと販売員テーブルへの検索と更新を行います。salesrepの構成を次に示します。

図F-20　salesrepの構成

salesrepの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥salesrep>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥salesrep, PID = 3684)
customerId = 221
customerId = 388
customerId = 456
customerId = 844

987: Mary Jackson
221: Alice Smith
388: Bill Williamson
456: Joe Smith
844: Buzz Murphy
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥salesrep>

(q)　shipperの概要

注文に対する商品在庫を計算し，データベースを更新します。在庫が一定の数量を下回った場合，引き当て処理を呼び出します。二つのEnterprise Beanを連携し，商品在庫情報テーブルへの検索と更新を行います。shipperの構成を次に示します。

図F-21　shipperの構成

shipperの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥shipper>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥shipper, PID = 3684)
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥shipper>

shipperの実行後，J2EEサーバの起動コンソール上に次のように表示されます。

...
ShipperEJB： ejbCreate()
ShipperEJB： shipItem()
StockEJB： updateOnHand()
StockEJB： reorderNeeded()
...

(r)　storagebinの概要

データベースから部品の情報と在庫を検索します。二つのEnterprise Beanを連携し,部品情報テーブルと部品在庫情報テーブルへの検索を行います。storagebinの構成を次に示します。

図F-22　storagebinの構成

storagebinの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥storagebin>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥storagebin, PID = 3684)
777 388 500 1.0 Duct Tape
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥storagebin>

(s)　tellerの概要

銀行用端末機から当座預金を引き出し，残高を計算します。データベースの（銀行用端末機の）入金情報テーブルと取引履歴情報テーブルに対し，取引内容を追加します。

tellerの構成を次に示します。

図F-23　tellerの構成

tellerの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥teller>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥teller, PID = 3684)
checking = 500.0
checking = 440.0
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥teller>

(t)　warehouseの概要

注文を受けた商品の状態，および商品の在庫を更新します。データベースの商品情報テーブルと在庫情報テーブルのそれぞれを更新します。warehouseの構成を次に示します。

図F-24　warehouseの構成

warehouseの実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥warehouse>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥HITACHI¥Cosminexus¥CC¥examples¥
ejb¥ejb20¥warehouse, PID = 3684)
status = shipped
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥ejb20¥warehouse>

付録F.3　Enterprise Bean（アノテーション）のサンプルプログラム

アノテーションに対応したEnterprise Beanのサンプルプログラムは，次の3種類を提供します。

アノテーション対応のEnterprise Bean（データベース接続なし）
格納場所は<Cosminexusのインストールディレクトリ>¥CC¥examples¥ejb¥annotation¥statelessです。

アノテーション対応のEnterprise Bean（データベース接続あり）
格納場所は<Cosminexusのインストールディレクトリ>¥CC¥examples¥ejb¥annotation¥statefulです。

Enterprise Bean（EJB2.0）から接続するアノテーション対応のEnterprise Bean
格納場所は<Cosminexusのインストールディレクトリ>¥CC¥examples¥ejb¥annotation¥homeです。

サンプルプログラムの概要と，実行手順を示します。

＜この項の構成＞

(1)　アノテーション対応のEnterprise Bean（データベース接続なし）の概要

(2)　アノテーション対応のEnterprise Bean（データベース接続あり）の概要

(3)　Enterprise Bean（EJB2.0）から接続するアノテーション対応のEnterprise Beanの概要

(4)　Enterprise Bean（アノテーション）のサンプルプログラムの実行手順

(1)　アノテーション対応のEnterprise Bean（データベース接続なし）の概要

データベースに接続しない場合のアノテーション対応のEnterprise Beanサンプルプログラム「annotation_stateless」の構成を次に示します。

図F-25　annotation_statelessの構成（アノテーション対応・データベース接続なし）

Webブラウザ経由でサーブレットにアクセスし，実行結果をブラウザ上に表示します。このサンプルプログラムでは，サーブレットからビジネスインタフェースを使用したEnterprise Beanを呼び出します。

アノテーション対応のEnterprise Beanの参照を取得するため，サーブレット側で@EJBアノテーションを使用します。

@EJB(beanName="MyConverter")
Converter converter;

実行例を次に示します。

図F-26　アノテーション対応Enterprise Beanのサンプルプログラム（データベース接続なし）の実行例

(2)　アノテーション対応のEnterprise Bean（データベース接続あり）の概要

データベースに接続する場合のアノテーション対応のEnterprise Beanサンプルプログラム「annotation_stateful」の構成を次に示します。

図F-27　annotation_statefulの構成（アノテーション対応・データベース接続あり）

このサンプルプログラムでは，アノテーションを使用してデータベースに接続します。アノテーション対応のEnterprise Beanで，@Resourceアノテーションを使用してリソースを取得します。

@Resource(mappedName="DB_Connector_for_Cosminexus_Driver")
private DataSource ds;

サーブレット側からビジネスインタフェースを使用したStateful Session Beanをlookupするには，JNDIを使用します。

Context initial = new InitialContext();
duke = (Bank)initial.lookup("java:comp/env/ejb/Bank");

実行例を次に示します。

図F-28　アノテーション対応Enterprise Beanのサンプルプログラム（データベース接続あり）の実行例

ユーザID，金額を入力して処理を実行します。指定できるユーザIDは001だけです。初期残高は10,000円です。

(3)　Enterprise Bean（EJB2.0）から接続するアノテーション対応のEnterprise Beanの概要

アノテーション対応のEnterprise Beanにホームインタフェースの定義を追加することで，EJB2.0からアノテーション対応のEnterprise Beanを呼び出せます。この処理を実行するサンプルプログラム「annotation_home」の構成を次に示します。

図F-29　annotation_homeの構成（アノテーション対応・EJB2.0からの接続）

このサンプルプログラムでは，EJB2.0のEnterprise Beanからローカルホームインタフェースが使用されているアノテーション対応のEnterprise Beanを呼び出します。EJB2.0のEnterprise Beanのコードでは，ローカルホームインタフェースをlookupします。

...
Context ctx = new InitialContext();
Converter2LocalHome home = (Converter2LocalHome)ctx.lookup("java:comp/env/ejb/Converter2");
...

アノテーション対応のEnterprise Beanのローカルホームインタフェースは，Enterprise Beanに@LocalHomeアノテーションを指定します。

@Stateless(name="MyConverter2")
@LocalHome(value=Converter2LocalHome.class)
public class Converter2EJB {
...
}

(4)　Enterprise Bean（アノテーション）のサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　サンプルプログラムのコンパイル

サンプルで提供するバッチファイルを使用して，サンプルプログラムをコンパイルします。

アノテーション対応のEnterprise Bean（データベース接続あり／なし）のサンプルプログラムは，「compile.bat」を実行します。

EJB2.0のEnterprise Beanからアノテーション対応のEnterprise Beanへ接続するサンプルは，「compileBean.bat」および「compileClient.bat」を実行します。

(b)　SQLの実行（アノテーション対応のEnterprise Bean（データベース接続ありの場合））

データベースに接続するサンプルプログラムの場合は，あらかじめSQLを実行してください。SQL文はサンプルで提供しています（createTable_Oracle.sql，createTable_HiRDB.sql）。

(c)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(d)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(e)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(f)　リソースアダプタの設定（アノテーション対応のEnterprise Bean（データベース接続ありの場合））

データベースに接続するサンプルプログラムの場合は，リソースアダプタの設定が必要です。「付録F.1(4)　リソースアダプタの設定」を参照してください。

(g)　アプリケーションのデプロイ

サンプルで提供するバッチファイル（deployApp.bat）を使用して，アプリケーションをデプロイします。このバッチファイルは，アプリケーションのインポート，開始，一覧表示，およびEnterprise Beanのスタブ・インタフェースの取得をします。

このバッチファイルで実行される処理の内容を示します。

アプリケーションのインポート，開始，一覧表示
実行内容については，「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

Enterprise Beanのスタブ・インタフェースファイルの取得
cjgetsubsjarコマンドで，Enterprise Beanのスタブとインタフェースを取得します。

(h)　アプリケーションの実行

アプリケーションごとに実行方法を示します。

アノテーション対応のEnterprise Bean（データベース接続なし）の場合
ブラウザを起動し，URLに次の文字列を指定します。
http://<マシン名>:<ポート番号>/<ContextRoot>/<ターゲットファイル>
インプロセスHTTPサーバが使用できる場合，デフォルトでは，次のURLを指定します。
http://localhost/annotation_stateless/servlet/ConverterServlet

アノテーション対応のEnterprise Bean（データベース接続あり）の場合
ブラウザを起動し，URLに次の文字列を指定します。
http://<マシン名>:<ポート番号>/<ContextRoot>/<ターゲットファイル>
インプロセスHTTPサーバが使用できる場合，デフォルトでは，次のURLを指定します。
http://localhost/annotation_stateful/bank.html

Enterprise Bean（EJB2.0）から接続するアノテーション対応のEnterprise Beanの場合
サンプルで提供するバッチファイル（testClient.bat）を使用してEJBクライアントアプリケーションを実行します。実行例を示します。

C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥ejb¥annotation¥home>testClient
KDJE40053-I The cjclstartap command will now start. (directory for the
user definition file = C:¥Program Files¥Hitachi¥Cosminexus¥CC¥examples¥
ejb¥annotation¥home, PID = 3684)
93.632
KDJE40054-I The cjclstartap command was stopped. (PID = 3684, exit status = 0)

(i)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(j)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

付録F.4　Enterprise Bean（Timer Service）のサンプルプログラム

Timer Serviceを実装するサンプルプログラムは，次のディレクトリに格納されます。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥ejb¥timerservice

サンプルの概要と実行手順を示します。

＜この項の構成＞

(1)　Enterprise Bean（Timer Service）のサンプルプログラムの概要

(2)　Enterprise Bean（Timer Service）のサンプルプログラムの実行手順

(1)　Enterprise Bean（Timer Service）のサンプルプログラムの概要

Timer Serviceのサンプルプログラム「TimerService」の構成を次に示します。

図F-30　TimerServiceの構成

このサンプルプログラムでは，Webブラウザ経由でEJBタイマの生成，一覧表示，キャンセルができます。EJBタイマがタイムアウトすると，ユーザログにメッセージを出力します。

実行例を次に示します。

図F-31　TimerServiceのサンプルプログラムの実行例

サンプルでは，次の機能を提供します。

EJBタイマの生成
アプリケーションの開始時に，EJBタイマが一つ生成されます。サーブレットに対してDDに<load-on-startup>タグを指定し，サーブレットのinitメソッドでEJBタイマを生成するStateless Session Beanのメソッドを呼び出します。
また，WebページEJBタイマ種別とタイムアウト時間と文字列情報を指定して［Create］ボタンをクリックすると，EJBタイマが生成されます。

EJBタイマ一覧の表示
WebページにEJBタイマの一覧が表示されます。［Refresh］ボタンをクリックすると，最新のEJBタイマ一覧が表示されます。

EJBタイマのキャンセル
Webページの［Cancel］ボタンをクリックすると，該当するEJBタイマがキャンセルされます。

ユーザログへの出力
EJBタイマがタイムアウト日時になると，タイムアウトメソッドが呼び出されユーザログにメッセージが出力されます。出力例を下記に示します。

The timeout method was invoked. (Information = MyTimer02)

(2)　Enterprise Bean（Timer Service）のサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　サンプルプログラムのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，サンプルプログラムをコンパイルします。このバッチファイルで，EJB-JARファイル（timerservice.jar）とWARファイル（timerservice.war）とEARファイル（timerservice.ear）が作成されます。

(b)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(c)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(d)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(e)　アプリケーションのデプロイ

「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(f)　アプリケーションの実行

ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/TimerServiceServlet

インプロセスHTTPサーバが使用できる場合，デフォルトでは，次のURLを指定します。

http://localhost/timerservice/TimerServiceServlet

(g)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(h)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

付録F.5　JPAのサンプルプログラム

JPAを使用するサンプルプログラムは，次のディレクトリに格納されます。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥jpa¥employeeinfo

サンプルの概要と実行手順を説明します。

参考

JPAのサンプルプログラムは，アノテーションを利用して，Cosminexus JPAプロバイダを使用するプログラムです。O/Rマッピングファイルを使用してマッピングする場合は，「(3)　O/Rマッピングファイルの使用方法」を参照してください。

＜この項の構成＞

(1)　JPAのサンプルプログラムの概要

(2)　JPAのサンプルプログラムの実行手順

(3)　O/Rマッピングファイルの使用方法

(1)　JPAのサンプルプログラムの概要

JPAのサンプルプログラムの構成を次に示します。このサンプルプログラムでは，従業員情報を取得してデータを更新します。なお，データベースのテーブルに対して，従業員情報の新規登録および削除は実行できません。また，［Update］ボタンを押したあとで実施されるfindメソッドからflushメソッド間の処理中に，ほかからデータベースが変更されると楽観的ロックを検出します。

図F-32　JPAのサンプルプログラムの構成

Webブラウザを使用してサーブレットにアクセスし，実行結果をWebブラウザ上に表示します。このサンプルプログラムでは，サーブレットからStateless Session Beanを呼び出し，Beanの中でJPAを利用してデータベースを操作します。

JPAのサンプルプログラムの構成内容を次の表に示します。

表F-3　JPAのサンプルプログラムの構成内容

項目 | 内容
Enterprise Bean種別 | Stateless Session Bean
トランザクション | CMT
Entity Manager | コンテナ管理
トランザクション種別 | JTA
永続化コンテキスト | トランザクションスコープ

サンプルプログラムのエンティティの構成を次に示します。

図F-33　エンティティの構成

図に示すように，サンプルプログラムでは，エンティティ間のリレーションに単方向のManyToOneを利用します。従業員エンティティクラスだけを具象化し，部門エンティティは従業員エンティティの内部の値として利用されます。どちらのエンティティにも，楽観的ロック機能を実装します。

実行例を次に示します。

図F-34　JPAのサンプルプログラムの実行例

この画面での操作を次に示します。

［ID］に従業員IDを入力して［Find］ボタンを押します。
従業員情報が表示されます。
従業員IDに指定できる値は，JPA_SAMPLE_EMPLOYEEテーブルのIDカラムに登録されているデータの1～5です。JPA_SAMPLE_EMPLOYEEテーブルの登録データについては，「(2)(h)　SQLの実行」を参照してください。なお，入力された値に該当する従業員IDがない場合は，画面にメッセージが表示されます。

［Salary］に表示されている従業員給与を変更して，［Update］ボタンを押します。
変更後の従業員給与がデータベースに登録されます。変更後の値が不正な場合や［Salary］に値がない場合は，次のように処理されます。

変更後の値が不正な場合
画面にメッセージが表示されます。

［Salary］に値がない場合
0が入力されたと見なして処理されます。

なお，［ID］に値を入力しない状態で，［Find］ボタンまたは［Update］ボタンを押しても，何も処理されません。

(2)　JPAのサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(b)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(c)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(d)　リソースアダプタの設定

このサンプルプログラムはデータベースに接続するため，リソースアダプタの設定が必要です。Connector属性ファイルで，トランザクションサポートレベルに「NoTransaction」以外を設定してJTAトランザクションが利用できるようにしてください。設定方法については，「付録F.1(4)　リソースアダプタの設定」を参照してください。

(e)　persistence.xmlの設定

サンプルで提供するpersistence.xmlの次に示すタグを変更してください。

<jta-data-source>タグ
リソースアダプタで設定したデータソースの参照を指定してください。

<property>タグ
cosminexus.jpa.target-databaseを動作環境に合わせて指定してください。サンプルでは「Oracle」が設定されています。

(f)　アプリケーションのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，サンプルプログラムをコンパイルします。このバッチファイルで，EJB-JARファイル（employeeinfo.jar）とWARファイル（employeeinfo.war）とEARファイル（employeeinfo.ear）が作成されます。

(g)　アプリケーションデプロイ

サンプルで提供するバッチファイル（deployApp.bat）を使用して，アプリケーションをデプロイします。「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(h)　SQLの実行

サンプルで提供するSQLファイル（createTable_Oracle.sql，createTable_HiRDB.sql）のSQLを実行してください。SQLを実行すると，JPA_SAMPLE_EMPLOYEEテーブル，およびJPA_SAMPLE_DEPARTMENTテーブルを削除，追加します。各テーブルの構成と登録データを次に示します。

JPA_SAMPLE_EMPLOYEEテーブル
JPA_SAMPLE_EMPLOYEEテーブルには，従業員情報が格納されています。JPA_SAMPLE_EMPLOYEEテーブルの構成と登録データを次に示します。

JPA_SAMPLE_EMPLOYEEテーブルの構成

列名 | 説明
ID※1 | 従業員ID
NAME | 従業員名
DEPARTMENT_ID※2 | 部門ID
SALARY | 従業員給料
EMPLOYEE_VERSION | 楽観的ロック機能で使用するためのカラム

注※1　PK（主キー）です。

注※2　FK（外部キー）です。

JPA_SAMPLE_EMPLOYEEテーブルの登録データ

ID | NAME | DEPARTMENT_ID | SALARY | EMPLOYEE_VERSION
1 | George | 1 | 100000 | 1
2 | John | 1 | 200000 | 1
3 | Thomas | 1 | 300000 | 1
4 | James | 2 | 400000 | 1
5 | Andrew | 2 | 500000 | 1

JPA_SAMPLE_DEPARTMENTテーブル
JPA_SAMPLE_DEPARTMENTテーブルには，部門情報が格納されています。JPA_SAMPLE_DEPARTMENTテーブルの構成と登録データを次に示します。

JPA_SAMPLE_DEPARTMENTテーブルの構成

列名 | 説明
DEPARTMENT_ID※ | 部門ID
DEPARTMENT_NAME | 部門名
DEPARTMENT_VERSION | 楽観的ロック機能で使用するためのカラム

注※　PK（主キー）です。

JPA_SAMPLE_DEPARTMENTテーブルの登録データ

DEPARTMENT_ID | DEPARTMENT_NAME | DEPARTMENT_VERSION
1 | Sales | 1
2 | Human resource | 1

(i)　アプリケーションの実行

ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/EmployeeInfo.html

インプロセスHTTPサーバが使用できる場合，デフォルトでは，次のURLを指定します。

http://localhost/employee_information/EmployeeInfo.html

(j)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(k)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

(3)　O/Rマッピングファイルの使用方法

このサンプルプログラムでは，O/Rマッピングファイル（orm.xml）も提供しています。このサンプルプログラムは，アノテーションを使用するプログラムであるため，O/Rマッピングファイルは利用しません。サンプルで提供するバッチファイルを使用して，サンプルプログラムをコンパイルしてもO/RマッピングファイルはJARファイルに格納されません。

O/Rマッピングファイルを利用する場合には，次のことに注意してください。

JARファイルのMETA-INF以下にO/Rマッピングファイルを格納する必要があります。サンプルで提供するバッチファイル（compile.bat）を使用して，O/RマッピングファイルをEJB-JARファイル（employeeinfo.jar）に格納するには，orm.xmlをDDディレクトリ下にあるMETA-INFディレクトリに格納して，コンパイルスクリプトを次のように変更してください。変更個所を太字で示します。

変更前

%JAR% cvf jar/EmployeeInfo.jar -C DD META-INF/persistence.xml -C classes employeeinfo

変更後

%JAR% cvf jar/EmployeeInfo.jar -C DD META-INF/persistence.xml -C DD META-INF/orm.xml -C classes employeeinfo

O/Rマッピングファイルは，アノテーションで指定された設定を上書きできます。また，部分的に指定して，マッピング情報を上書き，追加することもできます。

付録F.6　JavaBeansリソースのサンプルプログラム

JavaBeansリソースを使用するサンプルプログラムは，次のディレクトリに格納されます。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥javabeans

サンプルの概要と実行手順を説明します。

＜この項の構成＞

(1)　JavaBeansリソースのサンプルプログラムの概要

(2)　JavaBeansリソースのサンプルプログラムの実行手順

(1)　JavaBeansリソースのサンプルプログラムの概要

JavaBeansリソースのサンプルプログラムの構成を次に示します。

図F-35　JavaBeansリソースのサンプルプログラムの構成

このサンプルプログラムは，JavaBeansリソース属性ファイルのプロパティに指定された各設定情報に基づき，ブラウザにその値を表示します。

実行例を次に示します。

図F-36　JavaBeansリソースのサンプルプログラムの実行例

(2)　JavaBeansリソースのサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　サンプルプログラムのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，サンプルプログラムをコンパイルします。このバッチファイルで，JavaBeansリソース（MyJavaBean.jar）とEARファイル（LookupBean.ear）が作成されます。

(b)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(c)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(d)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(e)　JavaBeansリソースのインポート，開始

サンプルで提供するバッチファイル（deployJb.bat）を使用して，JavaBeansリソースをデプロイします。このバッチファイルでは，JavaBeansリソースのインポート，開始が実行されます。

このバッチファイルで実行される処理の内容を示します。

cjimportjbコマンドが実行され，JavaBeansリソースがJ2EEサーバにインポートされます。使用されるJavaBeansリソース属性ファイルは「jb_resource.xml」です。

cjstartjbコマンドが実行され，JavaBeansリソースが開始されます。使用されるJavaBeansリソース表示名は「JavaBean_resource」です。

cjlistjbコマンドが実行され，J2EEサーバ上のJavaBeansリソースの状態が一覧表示されます。この一覧を確認することで，JavaBeansリソースが稼働状態（running）になっていることを確認できます。

(f)　アプリケーションのデプロイ

「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(g)　アプリケーションの実行

ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>:<ポート番号>/<ContextRoot>/servlet/LookupBeanServlet

インプロセスHTTPサーバが使用できる場合，デフォルトでは，次のURLを指定します。

http://localhost/web_jb/servlet/LookupBeanServlet

(h)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(i)　JavaBeansリソースの停止

cjstopjbコマンドでJavaBeansリソースを停止します。

C:¥>cd Program Files¥Hitachi¥Cosminexus¥CC¥admin¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥admin¥bin>cjstopjb MyServer -resname JavaBean_resource

(j)　J2EEサーバの再起動

cjstopsvコマンドでJ2EEサーバを終了し，cjstartsvコマンドでJ2EEサーバを起動します。J2EEサーバの終了方法については，「付録F.1(7)　J2EEサーバの終了」を参照してください。J2EEサーバの起動方法については，「付録F.1(3)　J2EEサーバの起動」を参照してください。

(k)　JavaBeansリソースの削除

cjdeletejbコマンドでJavaBeansリソースを削除します。

C:¥>cd Program Files¥Hitachi¥Cosminexus¥CC¥admin¥bin
C:¥Program Files¥Hitachi¥Cosminexus¥CC¥admin¥bin>cjdeletejb MyServer -resname JavaBean_resource

(l)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

付録F.7　ユーザログ機能のサンプルプログラム

ユーザログ機能の動作確認用のサンプルプログラムとして，userlogが提供されています。また，このサンプルプログラムを実行するためのソースファイルと定義ファイルのサンプルとして次の表に示すファイルが提供されています。

表F-4　ユーザログ機能の動作確認用のサンプルプログラム

ファイル名 | 用途
UserLogServlet.java | ユーザログのサーブレットプログラムです。
UserLogHome.java | ホームインタフェースです。
UserLog.java | リモートインタフェースです。
AdderEJB.java | 整数の合計を計算するEnterprise Beanの実装クラスです。
sample.properties | プロパティにセットするロガーのサンプルプロパティです。
MyFormatter.java | フォーマッタとして提供される独自クラスです。
MyFilter.java | フィルタとして提供される独自クラスです。

これらのファイルは，次の場所にあります。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥userlog

ユーザログ機能のサンプルプログラムの概要と実行手順を説明します。

＜この項の構成＞

(1)　ユーザログ機能のサンプルプログラムの概要

(2)　ユーザログ機能のサンプルプログラムの実行手順

(1)　ユーザログ機能のサンプルプログラムの概要

このサンプルプログラムでは，三つのタイプのログ出力を実行できます。

タイプ1：Sample for outputting messages from servlet
入力されたメッセージがサーブレット側から出力されます。

タイプ2：Sample for outputting the entered numbers and total value from AdderEJB
入力された整数の合計を計算する「AdderEJB（Enterprise Bean）」から，入力した値とその値を足した合計値がログファイルに出力されます。

タイプ3：Sample for outputting exception logs from the servlet
Exceptionが発生し，その内容がサーブレットからログファイルに出力されます。

サンプルプログラムでは，次の図に示す流れで処理が行われます。

図F-37　ユーザログのサンプルプログラムの構造（サーブレット，Enterprise Bean）

［入力］画面で選択するロガー名およびログレベルによって，出力先のログファイルが異なります。

ロガー名「com.example.userlogger1」を選択した場合は，どのレベルを指定してもlogfileAに出力されます。

ロガー名「com.example.userlogger1」を選択して，ログレベルで「SEVERE」以上を指定した場合は，logfileAとlogfileBに出力されます。

ロガー名「com.example.userlogger2」を選択し，ログレベルで「INFO」以上を指定した場合，かつ「MyFilter」によってフィルタリングされなかった場合に，logfileCに出力されます。出力フォーマッタは「MyFormatter（独自クラス）」が使用されます。

MyFormatterの仕様

次の形式で出力します。

message：<入力されたメッセージ>　　　　LEVEL：<指定されたレベル>

MyFilterの仕様

メッセージの頭に「debug:」が付いているものは，ログに出力しません。

(2)　ユーザログ機能のサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(b)　サンプルファイルのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，ユーザログサンプルをコンパイルします。

コンパイルすると「myloglib.jar」というファイルが作成されます。これを任意のディレクトリに格納し，JARファイルにパスを通します。パスを通す方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「12.7.2　コンテナ拡張ライブラリを利用する方法」を参照してください。

(c)　プロパティ情報の設定

セットアップしたサーバにプロパティ情報を設定します。セットアップしたサーバのusrconf.propertiesの内容の一部を，サンプルで提供する設定ファイル（sample.properties）に書き換えます。Management Serverを利用してシステムを構築している場合は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「12.8　J2EEアプリケーションのユーザログ出力の設定」を参照して設定してください。

セットアップしたサーバを「MyServer」としたときのusrconf.propertiesの格納場所と，usrconf.propertiesファイル内の書き換え位置を次に示します。

ファイルの場所
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥MyServer¥usrconf.properties

ファイルの書き換え位置
次に示す個所を，sample.propertyの内容に書き換えます。

    ：
# user-log handler settings
#ejbserver.application.userlog.CJLogHandler.<Specify handler-name>.path=user_log
#ejbserver.application.userlog.CJLogHandler.<Specify handler-name>.count=2
    ：
# user-log logger settings
#ejbserver.application.userlog.Logger.<Specify logger-name>.handlers=<Specify handler-class>
#ejbserver.application.userlog.Logger.<Specify logger-name>.useParentHandlers=true
    ：

サンプルで提供するsample.propertiesの内容を示します。

# user-log handler settings
#conf1 settings
ejbserver.application.userlog.CJLogHandler.conf1.path=userlog/logFileA
ejbserver.application.userlog.CJLogHandler.conf1.level=ALL
ejbserver.application.userlog.CJLogHandler.conf1.appname=userlog_app
ejbserver.application.userlog.CJLogHandler.conf1.formatter=com.hitachi.software.ejb.application.userlog.CJSimpleFormatter

#conf2 settings
ejbserver.application.userlog.CJLogHandler.conf2.path=userlog/logFileB
ejbserver.application.userlog.CJLogHandler.conf2.level=SEVERE
ejbserver.application.userlog.CJLogHandler.conf2.appname=userlog_app

#conf3 settings
ejbserver.application.userlog.CJLogHandler.conf3.path=userlog/logFileC
ejbserver.application.userlog.CJLogHandler.conf3.level=INFO
ejbserver.application.userlog.CJLogHandler.conf3.appname=userlog_app

# user-log logger settings
#logger1 settings
ejbserver.application.userlog.Logger.com.example.userlogger1.handlers=com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf1,com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf2
ejbserver.application.userlog.Logger.com.example.userlogger1.level=ALL

#logger2 settings
ejbserver.application.userlog.Logger.com.example.userlogger2.handlers=com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf3
ejbserver.application.userlog.Logger.com.example.userlogger2.level=INFO

ejbserver.application.userlog.loggers=com.example.userlogger1, com.example.userlogger2

インプロセスHTTPサーバの設定については，「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(d)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(e)　アプリケーションのデプロイ

「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(f)　アプリケーションの実行

ブラウザを起動し，URLに次の文字列を指定します。

http://<マシン名>：<ポート番号>/<ContextRoot>/userlog.html

インプロセスHTTPサーバが使用できる場合，デフォルトでは次のURLを指定します。

http://localhost/userlog/userlog_war/userlog.html

(g)　userlogの実行例

userlogの実行例を示します。アプリケーションを実行して，URLを指定すると，次に示す［実行サンプルタイプの選択］画面が表示されます。

図F-38　［実行サンプルタイプの選択］画面（ユーザログのサンプルプログラム）

実行するサンプルのタイプを選択し，各データ入力フォームへ移ります。この画面以降の操作とログ出力例については，選択したタイプごとに説明します。

出力結果のログファイルは，セットアップしたサーバ名を「MyServer」とした場合，usrconf.propertiesに設定したファイル名で，次に示すディレクトリに出力されます。

<Cosminexusのインストールディレクトリ>¥CC¥server¥public¥MyServer¥logs¥user¥userlog

タイプ1：outputting messageの実行例
［実行サンプルタイプの選択］画面で「Sample for outputting message from the servlet」タイプを選んだ場合の画面遷移とログファイルの出力例を示します。
タイプ選択後，表示された［入力］画面で次の値を入力します。

ロガー名：com.example.userlogger1

メッセージ：AAA

メッセージレベル：SEVERE（致命的）

次に，タイプ1を選択した場合の［入力］画面を示します。

図F-39　［入力］画面（タイプ1：ユーザログのサンプルプログラム）

入力後，［send］ボタンをクリックすると，［入力結果表示］画面が表示されます。

図F-40　［入力結果表示］画面（タイプ1：ユーザログのサンプルプログラム）

この例では，logfileAとlogfileBに出力されます。
logfileAの出力結果を示します。

0310 2005/01/21 20:37:53.296     userlog_app      00922804 01000BCF Msg_100               2005/01/21 20:37:53|UserLogServlet|doPost|致命的|AAA

logfileBの出力結果を示します。

0888 2005/01/21 19:41:03.609     userlog_app      00922804 009B6220 Msg_100               AAA

タイプ2：outputting the entered numbers and total valueの実行例
［実行サンプルタイプの選択］画面で「Sample for outputting the entered numbers and total value from AdderEJB」タイプを選んだ場合の画面遷移とログファイルの出力例を示します。
タイプ選択後，表示された［入力］画面で次の値を入力します。

ロガー名：com.example.userlogger1

入力数：10

次に，タイプ2を選択した場合の［入力］画面を示します。

図F-41　［入力］画面（タイプ2：ユーザログのサンプルプログラム）

入力後，［send］ボタンをクリックすると，［入力結果表示］画面が表示されます。

図F-42　［入力結果表示］画面（タイプ2：ユーザログのサンプルプログラム）

この例では，logfileAだけに出力されます。
logfileAの出力結果を示します。

0324 2005/01/21 20:38:59.500     userlog_app      00922804 015C998A Adder_200             2005/01/21 20:38:59|AdderEJB|add|情報|inputNumber = 10
0327 2005/01/21 20:38:59.500     userlog_app      00922804 015C998A Adder_201             2005/01/21 20:38:59|AdderEJB|getTotal|情報|total = 10

タイプ3：outputting exception logsの実行例
［実行サンプルタイプの選択］画面で「Sample for outputting exception logs from the servlet」タイプを選んだ場合の画面遷移とログファイルの出力例を示します。
タイプ選択後，表示された［入力］画面で次の値を入力します。

ロガー名：com.example.userlogger2

次に，タイプ3を選択した場合の［入力］画面を示します。

図F-43　［入力］画面（タイプ3：ユーザログのサンプルプログラム）

入力後，［send］ボタンをクリックすると，［入力結果表示］画面が表示されます。

図F-44　［入力結果表示］画面（タイプ3：ユーザログのサンプルプログラム）

この例では，logfileCだけに出力されます。
logfileCの出力結果を示します。

1077 2005/01/21 19:55:19.328     userlog_app      00922804 006458A6 Exp_300               message:Exception     LEVEL:SEVERE

(h)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(i)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

付録F.8　Webアプリケーションのサンプルプログラム

Webアプリケーションのサンプルプログラムは，次のディレクトリに格納されます。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥webapps

サンプルプログラムの概要と実行手順を示します。

＜この項の構成＞

(1)　Webアプリケーションのサンプルプログラムの概要

(2)　Webアプリケーションのサンプルプログラムの実行手順

(1)　Webアプリケーションのサンプルプログラムの概要

Webアプリケーションのサンプルとして，Servlet 2.4仕様に準じたサーブレットおよびJSPのサンプルプログラムを利用できます。ここでは，前提事項，サンプルプログラムの種類，およびサンプルプログラムの構成について説明します。

(a)　前提事項

Webアプリケーションのサンプルプログラムの前提事項を次に示します。

Webアプリケーションのバージョンは，Servlet 2.4であること。

J2EEサーバモードで実行すること。

また，Webアプリケーションのサンプルプログラムでは，JSTL 1.1を使用します。JSTL 1.1はサンプルに含まれないため，別途用意する必要があります。

(b)　サンプルプログラムの種類

提供するサンプルプログラムの種類を次に示します。

サーブレット

「Hello World」の表示

HTTPリクエスト情報の表示

HTTPヘッダの表示

HTTPリクエストのパラメタ表示

Cookie操作

HTTPセッションの操作

JSP

Expression Language※1

シンプルタグハンドラ，JSPフラグメント

タグファイル※1

XMLシンタックスのJSP※1※2

その他JSP2.0仕様の機能

JSP1.2仕様の機能

注※1

JSTLを使用するサンプルプログラムです。JSTLをインストールしていない場合，JSPのコンパイルで失敗し，JSPを実行できません。

注※2

このサンプルでは，実行結果としてSVG形式のデータを返します。SVG形式のデータをブラウザで表示するには，SVGに対応したブラウザが必要です。

(c)　サンプルプログラムの構成

Webアプリケーションのサンプルプログラムは，展開ディレクトリ形式のアプリケーションとしてそのまま使用できます。<Cosminexusのインストールディレクトリ>¥CC¥examples¥webapps以下の構成を次に示します。

図F-45　webappsディレクトリ以下の構成

以降に説明するWebアプリケーションのサンプルプログラムの実行手順では，<Cosminexusのインストールディレクトリ>¥CC¥examplesの下にあるwebappディレクトリを，<webappsディレクトリ>と表記します。

(2)　Webアプリケーションのサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。この手順では，次の機能を使用します。

展開ディレクトリ形式のデプロイ

JSPの事前コンパイル

(a)　JSTL 1.1のインストール

JSTL 1.1で提供されるjstl.jar，standard.jar，およびJSTL 1.1が前提とするライブラリを次のディレクトリ以下に配置します。

<webappsディレクトリ>¥app¥webapp-examples¥WEB-INF¥lib

(b)　サンプルプログラムのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，Webアプリケーションのサーブレット，フィルタ，リスナ，JavaBeansのJavaソースファイル，およびJSPファイルをコンパイルします。

なお，サーブレットやフィルタなどJavaソースファイルはjavacコマンドが使用され，JSPファイルのコンパイルには，cjjspcコマンドが使用されます。

(c)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(d)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(e)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(f)　ユーザ，ロールの登録

サンプルで提供するバッチファイル（setupUsers.bat）を使用して，ユーザおよびロールを登録します。このバッチファイルでは，J2EEサーバ名「MyServer」のJ2EEサーバに対し，ユーザの登録とロールの登録の処理が実行されます。

このバッチファイルで実行される処理の内容を示します。

cjaddsecコマンドが実行され，次のユーザが登録されます。
ユーザ１：ユーザ名「user1」，パスワード「passwd1」
ユーザ２：ユーザ名「user2」，パスワード「passwd2」

cjaddsecコマンドが実行され，ロール「role1」とロール「role2」が登録されます。

cjmapsecコマンドが実行され，次のマッピングが登録されます。
マッピング１：ロール「role1」とユーザ「user1」
マッピング２：ロール「role2」とユーザ「user2」

ここで登録したユーザ名とパスワードは，JSPのサンプルページの「Security」で使用します。

(g)　アプリケーションのデプロイ

「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(h)　アプリケーションの実行

ブラウザを起動し，URLに次の文字列を指定してWebアプリケーションのトップページにアクセスします。

http://<マシン名>/examples

ポート番号をカスタマイズしている場合は，<マシン名>のあとに，「:<ポート番号>」を指定してください。

J2EEサーバを起動したホストからアクセスする場合は，次のように指定します。

http://localhost/examples

アクセスに成功すると，次のようなトップ画面が表示されます。

図F-46　Webアプリケーションのサンプルプログラムの実行例

(i)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(j)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

付録F.9　TP1インバウンド連携機能のサンプルプログラム

TP1インバウンド連携機能を使用するサンプルプログラムは，次のディレクトリに格納されます。

<Cosminexusのインストールディレクトリ>¥CC¥examples¥tp1inbound

サンプルプログラムの概要と実行手順を説明します。

＜この項の構成＞

(1)　TP1インバウンド連携機能のサンプルプログラムの概要

(2)　TP1インバウンド連携機能のサンプルプログラムの実行手順

(3)　サンプルプログラムの注意事項

(1)　TP1インバウンド連携機能のサンプルプログラムの概要

TP1インバウンド連携機能のサンプルプログラムの構成を次に示します。

図F-47　TP1インバウンド連携機能のサンプルプログラムの構成

このサンプルプログラムは，TP1/Server Baseが提供するBaseサンプルのC言語のSUPからRPC要求電文を受け付け，BaseサンプルのC言語のSPPと同等の処理を実行するMessage-driven Beanのプログラムです。BaseサンプルのC言語のSPPと同等の処理とは，RPC要求電文の受け付け時にMessage-driven Beanが実行され，実行結果がRPC応答電文としてC言語のSUPに返される処理を指します。Message-driven Beanの処理は，BaseサンプルのC言語のSPPと同様に顧客情報の取得や更新を実施します。

サンプルプログラムでは，メモリ上のテーブルに顧客情報を格納します。サンプルプログラムで使用するテーブル構成を表F-5に，およびテーブルの内容を表F-6に示します。

表F-5　サンプルプログラムで使用するテーブルの構成

カラム | 説明
name | 名前
sex | 性別
age | 年齢
sale | 販売額

表F-6　サンプルプログラムで使用するテーブルの内容

name | sex | age | sale
Suzuki | M | 30 | 1000000
Okada | F | 23 | 1500000
Yoshida | F | 26 | 800000
Saitoh | M | 24 | 1000000
Itoh | M | 35 | 1800000
Nishikawa | M | 20 | 300000
Katoh | F | 28 | 1000000
Satoh | F | 27 | 2100000
Hasegawa | M | 25 | 600000
Watanabe | M | 31 | 1600000

(2)　TP1インバウンド連携機能のサンプルプログラムの実行手順

サンプルプログラムの実行手順を示します。

(a)　TP1/Server BaseのBaseサンプルの設定

TP1/Server BaseのBaseサンプルに対して，次の設定を実施してください。

●ユーザサービスネットワーク定義によるスケジューラダイレクトの設定

TP1インバウンドアダプタをユーザサービスネットワーク定義によるスケジューラダイレクト機能を使って呼び出すために，OpenTP1のユーザサービス定義，ユーザサービスネットワーク定義の定義を設定します。設定する内容について次に示します。

ユーザサービスネットワーク定義に，TP1インバウンドアダプタのサービスグループ名，ホスト名，およびポート番号を指定します。設定項目について次の表に示します。

表F-7　ユーザサービスネットワーク定義の設定項目

設定項目 | 設定する内容
サービスグループ名 | Baseサンプルで指定しているサービスグループ名「base_svg」を指定します。
ホスト名 | アプリケーションサーバのホスト名を指定します。※
ポート番号 | TP1インバウンドアダプタのConnector属性ファイルのscd_portプロパティで定義したポート番号を指定します。

注※　OpenTP1では，RPCの送信元と送信先のIPアドレスを比較し，同一マシンである場合はUNIXドメイン通信を，異なるマシンである場合はINETドメイン通信をします。TP1インバウンドアダプタでは，INETドメイン通信だけをサポートするため，OpenTP1とTP1インバンドアダプタを同一のマシンで利用する場合は，IP alias機能によって割り振った送信元とは異なるIPアドレスをホスト名に指定する必要があります。

ユーザサービスネットワーク定義の例

dcsvgdef -g base_svg -h ホスト名[:ポート番号]

ユーザサービス定義のrpc_destination_modeにdefinitionを設定します。これによって，dc_rpc_call関数を呼び出す際に，ユーザサービスネットワーク定義の指定値から宛先を検索するようになります。

ユーザサービス定義の例

set rpc_destination_mode = definition

なお，詳細については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

●性能解析トレースの設定

TP1インバウンドアダプタでOpenTP1の性能解析トレースの情報を引き継ぐためには，システム共通定義に性能解析トレースの設定を実施する必要があります。設定内容について次の表に示します。

表F-8　性能解析トレースの設定内容

設定内容 | 設定の目的
set prf_trace=Y | 性能検証用トレース情報を取得するために設定します。
set rpc_prf_trace_level=00010001 | OpenTP1のPRF情報をCosminexusに伝播するために設定します。

システム共通定義については，マニュアル「OpenTP1 システム定義」を参照してください。

(b)　サンプルプログラムのコンパイル

サンプルで提供するバッチファイル（compile.bat）を使用して，サンプルプログラムをコンパイルします。このバッチファイルで，EARファイルが作成されます。

(c)　J2EEサーバのセットアップ

「付録F.1(1)　J2EEサーバのセットアップ」を参照してください。

(d)　J2EEサーバのカスタマイズ

「付録F.1(2)　J2EEサーバのカスタマイズ」を参照してください。

(e)　J2EEサーバの起動

「付録F.1(3)　J2EEサーバの起動」を参照してください。

(f)　TP1インバウンドアダプタのインポート，設定，および開始

TP1インバウンドアダプタのインポートおよび設定方法については，「付録F.1(4)　リソースアダプタの設定」を参照してください。ただし，参照先の記述のうち，cjtestresコマンドを使用したリソースアダプタの接続テストは不要です。接続テストを実施するとメッセージKDJE48606-Eが発生します。TP1インバウンドアダプタの設定では，Connector属性ファイルのservice_groupプロパティにはのBaseサンプルで指定しているサービスグループ名「base_svg」を指定します。

(g)　アプリケーションのデプロイ

「付録F.1(5)　アプリケーションのインポート，設定，および開始」を参照してください。

(h)　SUPの実行

TP1/Server Baseで提供しているBaseサンプルを参照してください。

(i)　アプリケーションのアンデプロイ

「付録F.1(6)　アプリケーションの停止，削除」を参照してください。

(j)　J2EEサーバの終了

「付録F.1(7)　J2EEサーバの終了」を参照してください。

(3)　サンプルプログラムの注意事項

ここでは，サンプルプログラムを使用するときの注意事項について説明します。

●TP1インバウンドアダプタ接続関連の設定について

このサンプルプログラムは，リソースとしてTP1インバウンドアダプタを使用するため，TP1インバウンドアダプタ接続に関する設定を適切に実施してください。

リソースのリンク解決について
TP1インバウンドアダプタのデフォルトの表示名を変更しなければ，リンク解決は不要です。TP1インバウンドアダプタのデフォルトの表示名を変更した場合は，リンク解決が必要になります。リンク解決の方法を次に示します。

サンプルで提供するcosminexus.xmlの<message-ref>にリソースの表示名を設定します。
設定方法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　Cosminexusアプリケーション属性ファイル（cosminexus.xml）」を参照してください。

アプリケーションをデプロイします。

●サンプルプログラムを実行するプラットフォームについて

このサンプルプログラムは，エンディアンを意識したユーザデータの作成，取得は実施しません。このため，エンディアンが同一のプラットフォームでSUPを実行してください。エンディアンが異なるプラットフォームでSUPを実行すると，サンプルプログラムの「販売額」が不正な値となります。

付録G　uCosminexus Operator（実行環境に対するGUI操作環境の構築）

uCosminexus Operatorは，アプリケーションサーバをインストールしたマシンとは別のマシンから，GUI（Eclipseプラグイン）画面を使用して運用操作を実行するための製品です。

アプリケーションサーバをインストールした実行環境がUNIXの場合，Server Plug-inは使用できません。Server Plug-inは，実行環境の運用操作をするための機能を持つEclipseプラグインです。Server Plug-inをUNIXの実行環境で使用したい場合には，実行環境のマシンとは別に，uCosminexus Operatorをインストールしたマシンを用意します。これによって，uCosminexus OperatorをインストールしたマシンのServer Plug-inから，UNIXの実行環境に対して運用操作ができます。Server Plug-inの機能および操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。

なお，uCosminexus Operatorは，次のOS環境のマシンにだけインストールできます。

Windows Server 2003

Windows Server 2003 R2

Windows 7

Windows Vista

Windows XP

ここでは，uCosminexus Operatorに関連する次の項目について説明します。

インストール手順

環境変数の設定

uCosminexus Operatorのディレクトリ構成

＜この節の構成＞

付録G.1　インストール手順（uCosminexus Operator）

付録G.2　環境変数の設定（uCosminexus Operator）

付録G.3　uCosminexus Operatorのディレクトリ構成

付録G.1　インストール手順（uCosminexus Operator）

ここでは，uCosminexus Operatorのインストール手順について説明します。

インストール手順を次に示します。

uCosminexus Operatorをインストールします。
インストールには，日立総合インストーラを使用します。詳細については，リリースノートを参照してください。

環境変数を設定します。
uCosminexus Operatorで設定が必要な環境変数については，「付録G.2　環境変数の設定（uCosminexus Operator）」を参照してください。

リソースおよびメモリ所要量を見積もって設定します。
uCosminexus Operatorをインストールしたマシンで使用するリソースの見積もりと設定をします。

Server Plug-inを設定します。
Server Plug-inを使用するためには，EclipseのインストールやServer Plug-inのEclipseへの組み込みが必要です。Server Plug-inの設定については，「7.8　Server Plug-inの設定」を参照してください。

インストール後のuCosminexus Operatorのディレクトリ構成については，「付録G.3　uCosminexus Operatorのディレクトリ構成」を参照してください。

付録G.2　環境変数の設定（uCosminexus Operator）

ここでは，uCosminexus Operatorを使用する場合に設定する環境変数について説明します。環境変数の詳細については，「7.3.2　環境変数の詳細」を参照してください。

設定が必要な環境変数と設定値を次の表に示します。

表G-1　設定が必要な環境変数と設定値（uCosminexus Operator）

環境変数名 | 設定値
PATH | <Cosminexusのインストールディレクトリ>¥jdk¥bin
TZ | JST-9　など

付録G.3　uCosminexus Operatorのディレクトリ構成

uCosminexus Operatorのディレクトリ構成を次の図に示します。

図G-1　uCosminexus Operatorのディレクトリ構成

付録H　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

＜この節の構成＞

付録H.1　関連マニュアル

付録H.2　マニュアル体系の変更について

付録H.3　このマニュアルでの表記

付録H.4　英略語

付録H.5　KB（キロバイト）などの単位表記について

付録H.1　関連マニュアル

アプリケーションサーバのマニュアルについて次に示します。

Cosminexus アプリケーションサーバ V8 概説（3020-3-U01）
アプリケーションサーバの概要について説明しています。

Cosminexus アプリケーションサーバ V8 ファーストステップガイド（3020-3-U02）
Application ServerまたはDeveloperを使用して，サンプルプログラムを動かすためのシステムを構築する手順について説明しています。

Cosminexus アプリケーションサーバ V8 システム設計ガイド（3020-3-U03）
システム設計時に，システムの目的に応じたシステム構成や運用方法を検討するための指針について説明しています。また，チューニングの方法についても説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(Webコンテナ)（3020-3-U05）
アプリケーションサーバで提供するWebコンテナの機能，およびWebコンテナに関連する機能（Webサーバ，サーブレット／JSPなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ)（3020-3-U06）
アプリケーションサーバで提供するEJBコンテナの機能，およびEJBコンテナに関連する機能（EJB，EJBクライアントなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能)（3020-3-U07）
WebコンテナおよびEJBコンテナで共通して利用する機能について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 拡張編（3020-3-U08）
アプリケーションサーバで提供する拡張機能（セッションフェイルオーバ機能，バッチサーバ，CTMなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編（3020-3-U09）
アプリケーションサーバで提供する運用・監視機能，およびほかのプログラムとの連携について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編（3020-3-U10）
アプリケーションサーバで構築したシステムの保守に関する機能，移行情報，および互換用機能について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド（3020-3-U12）
アプリケーションサーバで動作するアプリケーションの操作方法について説明しています。

Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド（3020-3-U13）
運用管理ポータルの使用方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス コマンド編（3020-3-U14）
アプリケーションサーバを構築・運用するときに使用するコマンドについて説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義)（3020-3-U15）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに，使用するファイルのうち，J2EEサーバやManagement Serverなどのサーバの定義に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義)（3020-3-U16）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに使用するファイルのうち，アプリケーションやリソースの属性設定に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 仮想化システム構築・運用ガイド（3020-3-U18）
アプリケーションサーバを仮想化したサーバ上に構築する場合の設計，構築，運用の手順について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド（3020-3-U25）
アプリケーションサーバで動作させるアプリケーションの開発方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス API編（3020-3-U26）
アプリケーションを開発するときに使用するAPIの形式について説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 1 KDAL-KDCGおよびHitachi Web Server編（3020-3-U41）
アプリケーションサーバで出力されるKDALからKDCGまでのメッセージ，およびHitachi Web Serverのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 2 KDJE-KDJW編（3020-3-U42）
アプリケーションサーバで出力されるKDJEからKDJWまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 3 KECX-KEDT／KEOS02000-29999／KEUC-KFRM編（3020-3-U43）
アプリケーションサーバで出力されるKECXからKEDTまでのメッセージ，KEOS02000からKEOS29999までのメッセージ，およびKEUCからKFRMまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 4 監査ログ編（3020-3-U44）
アプリケーションサーバで出力される監査ログメッセージについて説明しています。

また，このマニュアルと関連するこのほかのマニュアルを次に示します。必要に応じてお読みください。

Hitachi Web Server（3020-3-U17）

VisiBroker Version 5 Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド（3020-3-U28）

Cosminexus アプリケーションサーバ V8 SOAPアプリケーション開発の手引（3020-3-U30）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 プログラム作成の手引（3000-3-D51）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 システム定義（3000-3-D52）

スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（UNIX(R)用）（3000-6-352）

スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（Windows(R)用）（3020-6-352）

スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド（3020-6-356）

スケーラブルデータベースサーバ HiRDB Version 8 XDM/RD E2接続機能（3020-6-365）

HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）（3000-6-452）

HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）（3020-6-452）

HiRDB Version 9 UAP開発ガイド（3020-6-456）

HiRDB Version 9 XDM/RD E2接続機能（3020-6-465）

JP1 Version 8 JP1/ServerConductor/Deployment Manager（3020-3-L53）

VOS3　Database Connection Server（6190-6-648）

なお，このマニュアルでは，次のマニュアルについて，対象OSおよびバージョン番号を省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

正式名称 | このマニュアルでの表記
Cosminexus アプリケーションサーバ V8 概説 | Cosminexus アプリケーションサーバ 概説
Cosminexus アプリケーションサーバ V8 システム設計ガイド | Cosminexus アプリケーションサーバ システム設計ガイド
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(Webコンテナ) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)
Cosminexus アプリケーションサーバ V8 機能解説 拡張編 | Cosminexus アプリケーションサーバ 機能解説 拡張編
Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編 | Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編 | Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編
Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド | Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド
Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド | Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド
Cosminexus アプリケーションサーバ V8 リファレンス コマンド編 | Cosminexus アプリケーションサーバ リファレンス コマンド編
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)
Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド | Cosminexus アプリケーションサーバ アプリケーション開発ガイド
Cosminexus アプリケーションサーバ V8 SOAPアプリケーション開発の手引 | Cosminexus アプリケーションサーバ SOAPアプリケーション開発の手引
JP1 Version 8 JP1/ServerConductor/Deployment Manager | JP1/ServerConductor/Deployment Manager
OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 プログラム作成の手引 | OpenTP1 プログラム作成の手引
OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 システム定義 | OpenTP1 システム定義
VisiBroker Version 5 Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド | Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド
スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（UNIX(R)用） | HiRDB システム導入・設計ガイド
スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（Windows(R)用）
HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）
HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド | HiRDB UAP開発ガイド
HiRDB Version 9 UAP開発ガイド
スケーラブルデータベースサーバ HiRDB Version 8 XDM/RD E2接続機能 | HiRDB XDM/RD E2接続機能
HiRDB Version 9 XDM/RD E2接続機能

付録H.2　マニュアル体系の変更について

このマニュアルは，07-60のマニュアル「Cosminexus　簡易構築・運用ガイド」の内容の一部を移動し，目次の構成を変更したものです。また，08-00では，07-60のマニュアル「Cosminexus　機能解説」，マニュアル「Cosminexus　システム構築ガイド」およびマニュアル「Cosminexus　システム運用ガイド」の内容を分冊して，マニュアル体系を変更しています。

目次の対応は次のようになっています。

07-60のマニュアル「Cosminexus　簡易構築・運用ガイド」 | 08-00のマニュアル
1.　Cosminexusでのシステム構築の概要 | 1.　アプリケーションサーバでのシステム構築の概要
マニュアル「Cosminexus　機能解説」から移動
2.　セットアップウィザードを使用したシステムのセットアップ | 2.　セットアップウィザードを使用したシステムのセットアップ
3.　セットアップウィザードで使用するコマンドとファイル | 3.　セットアップウィザードで使用するコマンドとファイル
4.　J2EEアプリケーションを実行するシステムの構成の検討 | 4.2　J2EEアプリケーションを実行するシステムを構成する要素
4.3　J2EEアプリケーションを実行するシステムで使用するマシンの種類
4.7　JP1/SC/DPMの利用
5.1　使用リソースの見積もり | マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」へ移動
5.2.1　Cosminexusのシステムでできる運用作業 | 9.1.2　アプリケーションサーバで実行できる運用作業
5.2.2　運用設計 | 6.1　J2EEアプリケーションを実行するシステムの運用・障害設計
5.2.3　障害設計
5.3　簡易構築定義ファイルの運用方法 | 8.1.2　システム構築で使用するファイル
マニュアル「Cosminexus　システム構築ガイド」から移動 | 7.　インストールと初期設定
6.　J2EEアプリケーションを実行するシステムの構築 | 8.　J2EEアプリケーションを実行するシステムの構築
7.　J2EEアプリケーションを実行するシステムの運用 | 9.　J2EEアプリケーションを実行するシステムの運用
8.　バッチアプリケーションを実行するシステムの構成の検討 | 4.5　バッチアプリケーションを実行するシステムを構成する要素
4.6　バッチアプリケーションを実行するシステムで使用するマシンの種類
9.1　使用リソースの見積もり | マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」へ移動
9.2.1　Cosminexusのシステムでできる運用作業 | 11.1.2　アプリケーションサーバで実行できる運用作業
9.2.2　運用設計 | 6.2　バッチアプリケーションを実行するシステムの運用・障害設計
9.2.3　障害設計
9.3　簡易構築定義ファイルの運用方法 | 10.1.2　システム構築で使用するファイル
10.　バッチアプリケーションを実行するシステムの構築 | 10.　バッチアプリケーションを実行するシステムの構築
11.　バッチアプリケーションを実行するシステムの運用 | 11.　バッチアプリケーションを実行するシステムの運用
12.　コマンド | マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」へ移動
13.　ファイル | マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」へ移動
14.　簡易構築定義ファイルおよび構成変更定義ファイルに指定できるタグとパラメタ | マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」へ移動
15.　JP1と連携したSmart Composer機能でのシステム構築・運用 | マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」へ移動
付録A　Smart Composer機能が実行する負荷分散機のCLIコマンド | 付録A　Smart Composer機能が実行する負荷分散機のCLIコマンド
付録B　抽象パラメタ | マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」へ移動
付録C　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル | 付録B　JP1/SC/DPMを利用したスケールアウト時に削除するログファイル
付録D　JP1/Cm2/NCとの連携 | 削除
付録E　論理サーバのコンフィグレーションに指定できるパラメタ（互換用） | マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」へ移動
付録F　J2EEサーバのスレッド数とファイルディスクリプタ数の見積もり | マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」へ移動
付録G　バッチサーバのスレッド数とファイルディスクリプタ数の見積もり | マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」へ移動
付録H　Cosminexus DABroker Libraryのメモリ所要量 | マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」へ移動
付録I　Cosminexus DABroker Libraryの設定（Windowsの場合） | マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」へ移動
付録J　Cosminexus DABroker Libraryの設定（UNIXの場合） | マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」へ移動
付録K　データベースの設定 | 付録C　データベース（XDM/RD E2・SQL Server）の設定
付録L　セットアップウィザードで設定されるパラメタ | 付録D　セットアップウィザードで設定されるパラメタ
マニュアル「Cosminexus　システム運用ガイド」から移動 | 付録F　代替手段で実行できる運用作業
マニュアル「Cosminexus　システム構築ガイド」から移動 | 付録G　アプリケーションサーバが提供するサンプルプログラム
マニュアル「Cosminexus　システム構築ガイド」から移動 | 付録H　uCosminexus Operator（実行環境に対するGUI操作環境の構築）
付録M　用語解説 | 付録I　用語解説

付録H.3　このマニュアルでの表記

このマニュアルで使用している表記と，対応する製品名を次に示します。

表記
製品名

ACOS
AX2000
AX2000

AX2500
AX2500

BS320
BS320ロードバランサブレード

Application Server
Application Server Enterprise
uCosminexus Application Server Enterprise

Application Server Standard
uCosminexus Application Server Standard

BIG-IP
BIG-IP v10.1
BIG-IP ソフトウェアバージョン 10.1.0以降

BIG-IP v10.2
BIG-IP ソフトウェアバージョン 10.2.0以降

BIG-IP v9
BIG-IP ソフトウェアバージョン 9.1.0以降

BJEX
Batch Job Execution System - Base

Developer
Developer Professional
uCosminexus Developer Professional

Developer Standard
uCosminexus Developer Standard

Eclipse
Eclipse 3.6.1

HiRDB
HiRDB Server
HiRDB Server Version 9

HiRDB Server with Additional Function
HiRDB Server with Additional Function Version 9

HiRDB/Parallel Server
HiRDB/Parallel Server Version 8

HiRDB/Single Server
HiRDB/Single Server Version 8

HiRDB Run TimeまたはHiRDBクライアント
IPF
HiRDB Developer's Suite Version 9

HiRDB/Developer's Kit Version 8

HiRDB/Developer's Kit Version 9

HiRDB/Run Time Version 8

HiRDB/Run Time Version 9

Itanium(R) Processor Family

JP1/AJS
JP1/AJS - Agent
JP1/Automatic Job Management System 2 - Agent※

JP1/Automatic Job Management System 3 - Agent

JP1/AJS - Manager
JP1/Automatic Job Management System 2 - Manager※

JP1/Automatic Job Management System 3 - View

JP1/AJS - View
JP1/Automatic Job Management System 2 - View※

JP1/Automatic Job Management System 3 - View

JP1/AJS2 - SO
JP1/AJS2 - SO Manager
JP1/Automatic Job Management System 2 - Scenario Operation Manager

JP1/AJS2 - SO View
JP1/Automatic Job Management System 2 - Scenario Operation View

JP1/IM
JP1/IM - CM
JP1/Integrated Management - Central Information Master

JP1/IM - Manager
JP1/Integrated Management - Manager

JP1/IM - View
JP1/Integrated Management - View

JP1/NETM/Audit
JP1/NETM/Audit - Manager

JP1/SC/DPM
JP1/ServerConductor/Deployment Manager Standard Edition

Loadflowbal
HA8000-ie/Loadflowbal

Oracle
Oracle10g
Oracle 10g

Oracle 10g R2

Oracle Database 10g

Oracle11g
Oracle Database 11g

Oracle Database 11g R2

Oracle9i
Oracle9i

Oracle9i R2

TP1/Base
uCosminexus TP1/Server Base

UNIX
AIX
AIX 5L V5.3

AIX V6.1

AIX V7.1

HP-UXまたはHP-UX（IPF）
HP-UX 11i V2（IPF）

HP-UX 11i V3（IPF）

Linux
Linux（IPF）
Red Hat Enterprise Linux(R) AS 4（IPF）

Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）

Red Hat Enterprise Linux(R) 5（Intel Itanium）

Linux（x86/AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) AS 4（x86）

Red Hat Enterprise Linux(R) ES 4（x86）

Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）

Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）

Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）

Red Hat Enterprise Linux(R) 5（x86）

Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）

Red Hat Enterprise Linux(R) 5（AMD/Intel 64）

Red Hat Enterprise Linux(R) Server 6（32-bit x86）

Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）

Solaris
Solaris 10（SPARC）

Solaris 10（x64）

Solaris 9（SPARC）

Web Redirector
uCosminexus Web Redirector

XDM/RD E2
VOS3 XDM/RD E2

注※　総称して，JP1/AJS2と表記することがあります。

なお，Application ServerおよびDeveloperを総称して，アプリケーションサーバと表記します。

また，Linuxに関しては，バージョンごとに次のように表記することがあります。

表記 | OS名
Red Hat Enterprise Linux 4 | Red Hat Enterprise Linux(R) AS 4（IPF）
Red Hat Enterprise Linux(R) AS 4（x86）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5 | Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）
Red Hat Enterprise Linux(R) 5（Intel Itanium）
Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）
Red Hat Enterprise Linux(R) 5（x86）
Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux(R) 5（AMD/Intel 64）
Red Hat Enterprise Linux Server 6 | Red Hat Enterprise Linux(R) Server 6（32-bit x86）
Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）

このマニュアルで使用している表記と，対応するアプリケーションサーバの機能名を次に示します。

表記 | アプリケーションサーバの機能名
Cosminexus Developer's Kit for Java | Cosminexus Developer's Kit for JavaTM
Cosminexus RM | Cosminexus Reliable Messaging
CTM | Cosminexus Component Transaction Monitor
Management Server | Cosminexus Management Server
MyEclipse | MyEclipse for Cosminexus
PRF | Cosminexus Performance Tracer
Server Plug-in | Cosminexus Server Plug-in
Smart Composer | Cosminexus Smart Composer

このマニュアルで使用している表記と，対応するJava関連用語を次に示します。

表記 | Java関連用語
EAR | Enterprise ARchive
EJBまたはEnterprise JavaBeans | Enterprise JavaBeansTM
EJB QL | EJBTM Query Language
J2EEまたはJava 2 Platform, Enterprise Edition | J2EETM
JavaTM 2 Platform, Enterprise Edition
J2SE | JavaTM 2 Platform, Standard Edition
JAAS | JavaTM Authentication and Authorization Service
JAR | JavaTM Archive
Java | JavaTM
JavaBeans | JavaBeansTM
Java EEまたはJava Platform, Enterprise Edition | JavaTM Platform, Enterprise Edition
JavaMail | JavaMailTM
JavaVM | JavaTM Virtual Machine
JCA | J2EETM Connector Architecture
JDBC | JDBCTM
JavaTM Database Connectivity
JDK | JDKTM
JavaTM Development Kit
JMS | JavaTM Message Service
JNDI | Java Naming and Directory InterfaceTM
JSP | JSPTM
JavaServer PagesTM
JSTL | JavaServer PagesTM Standard Tag Library
JTA | JavaTM Transaction API
Servletまたはサーブレット | JavaTM Servlet
WAR | Web ARchive

付録H.4　英略語

このマニュアルで使用している英略語を次に示します。

英略語 | 英字での表記
ACOS | Advanced Core Operating System
API | Application Programming Interface
ASCII | American Standard Code for Information Interchange
BMP | Bean-Managed Persistence
BMT | Bean-Managed Transaction
CMP | Container-Managed Persistence
CMT | Container-Managed Transaction
CORBA | Common Object Request Broker Architecture
CSV | Comma Separated Value
CUI | Character User Interface
DB | Database
DBMS | Database Management System
DD | Deployment Descriptor
DMZ | Demilitarized Zone
DTD | Document Type Definition
EIS | Enterprise Information System
EL | Expression Language
FK | Foreign Key
GUI | Graphical User Interface
HA | High Availability
HTML | Hyper Text Markup Language
HTTP | Hyper Text Transfer Protocol
HTTPS | Hyper Text Transfer Protocol Security
IIOP | Internet Inter-Orb Protocol
MIB | Management Information Base
OS | Operating System
OTM | Object Transaction Monitor
OTS | Object Transaction Service
PK | Primary Key
RAC | Real Application Clusters
RDB | Relational Database
RMI | Remote Method Invocation
SFO | Session Fail Over
SMTP | Simple Mail Transfer Protocol
SNMP | Simple Network Management Protocol
SPP | Service Providing Program
ssh | Secure Shell
SSL | Secure Sockets Layer
SUP | Service Using Program
URL | Uniform Resource Locator
VM | Virtual Machine
XML | Extensible Markup Language

付録H.5　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

付録I　用語解説

アプリケーションサーバで使用する用語について説明します。

（数字）

1.4モード

サーバの動作モードです。J2EE 1.4以降の機能を使用できます。データベースを含む複数のリソースのトランザクション管理ができます。

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

実行系のアプリケーションサーバと待機系のアプリケーションサーバが1:1で対応しているシステムです。実行系のアプリケーションサーバに障害が発生すると，待機系のアプリケーションサーバで処理を引き継ぎます。

（英字）

Application Server

アプリケーションサーバの実行環境を構築する基盤製品です。Application Server Standardと，Application Server Enterpriseの総称です。

BMP（Bean-Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化を管理するモデルです。

BMT（Bean-Managed Transaction）

Enterprise Beanでトランザクションを管理するモデルです。Session BeanおよびMessage-driven Beanが対象になります。Entity Beanは対象外です。

CMP（Container-Managed Persistence）

EJBコンテナがデータの永続化を管理するモデルです。

CMT（Container-Managed Transaction）

EJBコンテナがトランザクションを管理するモデルです。Session Bean，Entity BeanおよびMessage-driven Beanが対象になります。

Component Container管理者

スーパーユーザ以外の，J2EEサーバやバッチサーバのセットアップ，J2EEサーバやバッチサーバの起動・停止などを実施できるユーザを指します。Component Container管理者はUNIXの場合に設定できます。

Cookieスイッチング機能

負荷分散機で提供しているサーバスイッチング機能の一つです。Cookieスイッチング機能を使用すると，クライアントからのリクエストパケット内のCookie情報に基づいて，同じサーバにセッションをリダイレクトします。

CORBAネーミングサービス

CORBAの仕様に準拠した，リモートオブジェクトの格納場所を管理するためのネーミングサービスです。アプリケーションサーバの構成ソフトウェアであるCosminexus TPBrokerによって提供される機能です。

cosminexus.xml

Cosminexus アプリケーションサーバ独自の情報を定義するための属性ファイルです。

Cosminexus Component Container

サーバ・サイドの業務処理プログラム（ビジネスロジック）をコンポーネントとして実行するための構成ソフトウェアです。また，アプリケーションサーバの運用管理をするためのManagement Server，統合ユーザ管理，snapshotログ収集などの機能も提供しています。

Cosminexus Component Transaction Monitor

クライアントからのリクエストのスケジューリングを実現するための構成ソフトウェアです。

Cosminexus Performance Tracer

リクエストが処理されるときに，決められたポイントごとに各機能が出力する性能解析情報をファイルに出力するための構成ソフトウェアです。

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

アプリケーションサーバを中核とした，性能および信頼性の高いアプリケーションを実行および開発するためのシステム構築基盤製品です。

CTM

Cosminexus Component Transaction Monitorのことです。リクエストのスケジューリングをするための構成ソフトウェアです。

CTMデーモン

クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。リクエストのスケジューリングを実現する，スケジューラとして機能します。

Management Serverを利用している場合，CTMデーモンは論理サーバとして扱えます。

CTMドメイン

複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。CTMデーモンはCTMドメイン内で，それぞれに登録された業務処理プログラムの情報やスケジュールキューの負荷情報を交換してリクエストを振り分けます。

CTMドメインマネジャ

CTMドメインを管理するプロセスです。ホスト内のCTMデーモンの情報を，CTMドメイン内のほかのCTMドメインマネジャに配布します。

Management Serverを利用している場合，CTMドメインマネジャは論理サーバとして扱えます。

CTMレギュレータ

EJBクライアントからCTMデーモンに集中するリクエストを，分散集約するためのプロセスです。TPBrokerクライアント（CORBAクライアント）からJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能も提供します。

DB Connector

データベースに接続するためのリソースアダプタです。

DD

アプリケーションを運用環境に配置するときの定義情報を記述したものです。

EARファイル

J2EEアプリケーションを構成する複数のEJB-JARファイル，WARファイル，およびDDをEARファイル形式でパッケージ化したものです。

EIS

データベースやトランザクションサーバなど，企業内に構築されているバックエンドシステムです。

EJB（Enterprise JavaBeans）

業務ロジックをプログラムとして記述したビジネスロジック，および永続的データを格納するオブジェクトであるエンティティをJavaコンポーネント化したものです。

EJBクライアント

J2EEサーバ上で開始されているEnterprise Beanを呼び出すクライアントプログラムです。次の3種類があります。

EJBクライアントアプリケーション

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーション

Enterprise Beanを呼び出すJavaアプリケーションです。

EJBコンテナ

Enterprise Beanを制御する実行環境です。また，通信，トランザクション管理などのシステムレベルのサービスも提供します。Enterprise Beanの実体は，EJBコンテナの中で実行されます。

HAモニタ

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。HAモニタと連携することで，アプリケーションサーバで構築したシステムの信頼性や稼働率を向上できます。AIX，HP-UXまたはLinuxを使用しているときに連携できます。

HAモニタと連携することで，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステム，およびホスト単位管理モデルを対象とした系切り替えシステムが実現できます。

J2EEアプリケーション

JSP，サーブレット，EnterpriseBeanなどで構成されるアプリケーションです。アプリケーションサーバで扱うJ2EEアプリケーションの形式には，EARファイル形式でパッケージ化されたアーカイブ形式のアプリケーションと，アーカイブ化しない展開ディレクトリ形式のアプリケーションがあります。EARファイル形式でパッケージ化されたアプリケーションの場合，複数のEJB-JARファイル，複数のWARファイル，および一つのDDから構成されます。

J2EEアプリケーション実行時間の監視機能

EJBおよびWebアプリケーションのリクエスト実行時間を監視する機能です。実行時間監視中に障害を検知すると，メソッドタイムアウト機能およびメソッドキャンセル機能が動作します。

J2EEサーバ

J2EEコンテナを生成，実行する環境です。

J2EEリソース

サーバから利用できるリソースです。J2EEサーバの場合，データベース，OpenTP1，SMTPサーバなどを利用できます。また，バッチサーバの場合，データベースを利用できます。

J2EEリソースアダプタ

J2EEサーバに共有スタンドアロンモジュールとして配備したリソースアダプタのことです。

JNDI（Java Naming and Directory Interface）

Javaプラットフォーム用の標準拡張機能で，Java テクノロジに対応したアプリケーションに，企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供します。

アプリケーションサーバでは，Cosminexus TPBrokerのCORBAネーミングサービスを利用して，JNDIの機能を実現しています。

JP1

日立の統合システム運用管理ソフトウェアです。

JP1/AJS

日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するめたのプログラム群です。JP1/AJS - Manager，JP1/AJS - Agent，JP1/AJS - Viewの製品で構成されます。

JP1/AJS2 - SO

一つ一つの運用手順を蓄積し，ライブラリとして統合する運用管理の基盤機能を提供するプログラムです。立案したシナリオに合う運用手順をライブラリから選択し，運用環境に合わせてカスタマイズすることで，業務運用の設計を容易に，かつ高品質で実現することができます。

JP1/IM

企業情報システム全体を統合管理する基盤になるプログラム群です。JP1/IM - Manager，JP1/IM - View，およびJP1/IM - CMで構成されます。

JP1/IM - CM

業務システムを構成する各種のリソース（サーバ，ストレージなど）やシステム構成に関する情報を集約して管理するためのプログラムです。管理対象のリソースを任意にグルーピングできるため，システムの監視（性能，障害）や運用（設定配布，構成変更）の際に，グループ単位で管理したり操作したりできます。

JP1/NETM/Audit

システム内の製品が出力した監査ログを自動収集して，一括管理するためのプログラムプロダクトです。JP1/Baseと連携して，Cosminexusのアプリケーションサーバ，運用管理サーバ，連携する日立オープンミドルウェア製品などが出力した監査ログを監査ログ管理サーバで自動収集できます。また，収集した監査ログを，監査ログ管理サーバのデータベースで一元管理できます。

JP1/SC/DPM

デプロイメント操作を実行するためのソフトウェアです。ディスクイメージをバックアップしたり，OSやアプリケーションのインストールを一括して実施したりできます。

JP1イベント

システム内で何らかの事象が発生した際に，その事象に関してJP1/Baseに通知される情報です。

Management Server

運用管理ドメインを構成するサーバプログラムです。運用管理ドメイン単位に一つ配置します。

Management Serverは運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行します。

Managementアクション

Managementイベント発生時に自動的に実行される処理です。Managementアクションとしてどのような処理をするかは，Management Server側であらかじめ定義しておきます。

Managementイベント

Management Serverを利用して運用している場合に，運用管理ドメイン内の論理サーバで発生した事象に応じてManagement Serverで発行するイベントです。論理サーバでメッセージが出力されたタイミングで発行できます。例えば，リソース監視中に設定したしきい値を超えた場合などに発行できます。

Managementイベントに対してManagementアクションを定義しておくと，発生した事象に応じたアクションを自動的に実行できます。

Microsoft Cluster Service

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。Microsoft Cluster Serviceと連携することで，アプリケーションサーバで構築したシステムの信頼性や稼働率を向上できます。Windows Server 2003で使用できます。

Microsoft Cluster Serviceと連携したシステムでは，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステム，およびホスト単位管理モデルを対象とした系切り替えシステムが実現できます。

N:1リカバリシステム

クラスタ構成の実行系のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。リカバリ専用サーバでは，障害が発生した実行系のアプリケーションサーバのトランザクションの決着をします。

ORBゲートウェイ

CORBAクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。CTMレギュレータプロセスによって提供されます。

PRFデーモン

バッファに出力されたPRFトレースをPRFトレースファイルに出力するIOプロセスです。

Management Serverでは，論理サーバとして扱えます。Management Serverで扱う場合は，パフォーマンストレーサといいます。

PRFトレース

リクエストを処理する時にアプリケーションサーバの各機能で出力されたトレース情報です。バッファに出力されて，一定量たまったらPRFトレースファイルに出力されます。

PRFトレース取得レベル

PRFトレースを取得するレベルです。「標準レベル」，「詳細レベル」，「保守レベル」があります。「詳細レベル」または「保守レベル」を指定した場合，「標準レベル」に比べてトレース取得ポイントが多くなります。

PRFトレースファイル

PRFトレースを出力したバイナリ形式のファイルです。性能解析トレースファイル（CSV形式）に変換する基になるファイルです。

SecurityManager

セキュリティポリシーに基づいたWebコンテナの実行時保護をするJ2EEサーバの機能です。

Server Plug-in

Eclipseのプラグインです。Server Plug-inを使用すると次の操作ができます。

リソースアダプタのプロパティを設定したり，設定したリソースアダプタをJ2EEサーバやバッチサーバにデプロイしたりする。

J2EEアプリケーションのプロパティを設定したり，設定したJ2EEアプリケーションをJ2EEサーバにインポートしたりする。

論理サーバを起動・停止する。

SFOサーバ

システム内のJ2EEサーバのJ2EEアプリケーション内で生成されたグローバルセッション情報を管理するJ2EEサーバです。メモリセッションフェイルオーバ機能を使用するときにシステム構成に含めます。

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

SFOサーバ上で稼働するJ2EEアプリケーションを，SFOサーバアプリケーションといいます。SFOサーバアプリケーションはEJBで実装されています。なお，SFOサーバアプリケーションはアプリケーションサーバで提供しています。

Smart Composer機能

一般的な3階層モデルのアプリケーションサーバのシステムを，簡単に構築および運用できるよう支援する機能です。システム全体に対して，システムの設定，およびJ2EEアプリケーションやリソースアダプタのデプロイを一括で実行できるので，簡単，迅速にシステム構築ができます。

構築したシステムを一括で起動したり，一括でシステムの設定を変更したりなど，運用機能についてもサポートしています。

snapshotログ

ある時点でのJ2EEサーバやバッチサーバの状態が出力されたログファイルです。

トラブルシューティングに必要な情報が自動的に出力されます。

Management Serverを利用している場合は，次のタイミングで出力されます。

論理サーバに異常が発生した時

運用管理ポータルまたは運用管理コマンドによってsnapshotログの収集を要求した時

Management Serverを利用していない場合は，コマンド（snapshotlog）を実行した時に出力されます。このコマンドで出力できるのは，そのコマンドを実行したホストの情報だけです。

uCosminexus Client

EJBクライアント環境を構築するための製品です。

uCosminexus Operator

アプリケーションサーバをインストールしたマシンとは別のマシンから，GUI（Eclipseプラグイン）画面を使用して運用操作を実行するための製品です。例えば，実行環境がUNIXの場合に，別のWindowsのマシンでEclipseプラグインのGUIによる運用管理操作を実行したいときに，この製品を使用します。

usrconf.properties（ユーザプロパティファイル）

J2EEサーバ，バッチサーバ，Webコンテナサーバ，またはサーバ管理コマンドで使用するJavaVMのシステムプロパティを定義するファイルです。

Webアプリケーション

Webブラウザを備えたクライアントを対象に作成されたアプリケーションです。具体的には，サーブレットプログラム，JSPファイル，HTML/XMLドキュメントなどの集合体です。

Webコンテナ

Webアプリケーションを制御する実行環境です。また，セキュリティ，トランザクションなどの各種サービスも提供します。Webアプリケーションは，Webコンテナ上で動作します。

Java Servlet2.5仕様，およびJavaServer Pages Specification v2.1仕様に準拠したWebアプリケーションを実行できます。

Webサーバ

Webブラウザからのリクエスト受信およびWebブラウザへのデータ送信に関連する処理を実行するプログラムです。アプリケーションサーバでは，Hitachi Web Server，Microsoft IIS，またはインプロセスHTTPサーバを使用できます。インプロセスHTTPサーバは，J2EEサーバプロセス内で動作するWebサーバです。

なお，Management Serverを利用する場合，Hitachi Web Serverは論理サーバとして扱えます。

Webサーバ連携

アプリケーションサーバで使用するWebサーバとして，Hitachi Web ServerまたはMicrosoft IISを使用する方法です。

Hitachi Web ServerまたはMicrosoft IISにCosminexus Component Containerが提供するリダイレクタモジュールを組み込んで使用します。

Webシステム

1台の負荷分散機（ロードバランサ）と複数のWebサーバおよびアプリケーションサーバで構築されるWebクラスタシステムで，単一の業務サービスを提供します。

Windows Server Failover Cluster

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。Windows Server Failover Clusterと連携することで，アプリケーションサーバで構築したシステムの信頼性や稼働率を向上できます。Windows Server 2008で使用できます。

（ア行）

アーカイブ形式

EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションの形式です。

アプリケーションサーバ

情報システムの中間に位置し，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。

インプロセス

プロセスの起動のしかたです。インプロセスで起動させると，J2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムが実現できます。ネーミングサービス，トランザクションサービスおよびHTTPサーバ機能をインプロセスで起動できます。このとき，CORBAネーミングサービス，インプロセスOTSおよびインプロセスHTTPサーバは，J2EEサーバ起動時に自動で起動されます。

インプロセスHTTPサーバ

J2EEサーバのインプロセスで動作するWebサーバ機能です。Webコンテナの機能の一部として提供されます。

運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェントプログラムです。

運用管理コマンド（mngsvrutil）

Management Serverを操作するためのCUIです。

運用管理サーバ

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverを配置したホストです。運用管理ドメイン内の各ホストに配置されている運用管理エージェントに対して，管理操作を指示します。

運用管理サーバモデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，アプリケーションサーバとは別の運用管理用のホストにManagement Serverを配置するシステム構成モデルです。

運用管理ドメイン

Management Serverが管理する論理サーバの集合です。同じ運用管理ポリシーが適用されます。

運用管理ポータル

Management Serverを操作するためのGUIです。Webブラウザで表示します。

運用管理ポリシー

運用，監視，セキュリティなど，運用管理に関するポリシーです。

（カ行）

仮想サーバ

負荷分散機で複数の実サーバを管理するための仮想的なサーバです。負荷分散機では，クライアントから仮想サーバにアクセスされたトラフィックを，実サーバに自動分配します。

監査証跡

データベースの機能で出力する，データベースに対する操作記録のことです。データベースに対する権限の運用が適切に行われているかどうかをチェックするために使用します。アプリケーションサーバでは，監査証跡にアプリケーションサーバで構築したシステムの情報を出力するためのデータベース監査証跡連携機能を提供しています。

監査ログ

システム構築者やシステム運用者がアプリケーションサーバのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」「だれが」「何をしたか」を知ることができて，システムの運用が法規制，セキュリティ評価基準，または業界ごとの各種の基準に準拠していることを証明できます。

業務処理プログラム

ビジネスロジックを実装したEnterprise Beanのことです。

クラスタ

ある共通の機能を提供するサーバの集合です。

Management Serverでは，J2EEサーバクラスタまたはWebサーバクラスタを論理サーバとして扱えます。

クラスタソフトウェア

システムの信頼性向上，稼働率向上を目的として，システムの切り替えを実現するプログラムです。

実行中のサーバシステムに障害が発生した場合，事前に待機しているサーバシステムに，直ちに自動で切り替えることができます。そのため，オペレータが特に意識することなく，システムの信頼性や稼働率を高められます。

アプリケーションサーバでは，クラスタソフトウェアを使用して，1:1系切り替えシステム，N:1リカバリシステム，相互系切り替えシステム，およびホスト単位管理モデルを対象とした系切り替えシステムを実現できます。

AIX，HP-UXまたはLinuxを使用している場合は，クラスタソフトウェアとしてHAモニタが使用できます。Windowsの場合は，クラスタソフトウェアとしてMicrosoft Cluster ServiceおよびWindows Server Failover Clusterが使用できます。

グローバルCORBAネーミングサービス

CTMによってリクエストをスケジューリングする場合に，CTMドメイン内に含まれる複数のJ2EEサーバに登録されている業務処理プログラム（Stateless Session Bean）の情報を共有管理するネーミングサービスです。

系

系とは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器を含めたシステム全体の総称です。系の種類には，実行系と待機系があります。

系切り替え

システムに障害が発生した場合やシステムの保守のために，システムを切り替えることをいいます。系切り替えが行われると，待機系は業務処理を引き継いで実行系となります。一方，実行系は，さらに障害が発生した場合に備えて待機系となります。以降，系切り替えのたびに，実行と待機を交代して，どちらかの系で常に業務処理を実行するようにします。

コンテナ拡張ライブラリ

ユーザ作成ライブラリのインタフェースおよび機能を，J2EEコンテナ，Webコンテナ，またはバッチサーバから利用できるように拡張したライブラリです。Enterprise Bean，サーブレットおよびJSPから共通して利用できます。

（サ行）

サーバ管理コマンド

サーバで管理しているアプリケーションおよびリソースの設定をするためのコマンド群です。

サービス閉塞

J2EEアプリケーションの運用中に特定の業務処理プログラムを入れ替えたい場合などに，システム全体は稼働させたまま，該当サービスだけを安全に閉塞させる機能です。

サービスユニット

J2EEサーバやWebサーバで構成される業務サービスを提供する閉じた部分系を，サービスユニットといいます。Smart Composer機能では，サービスユニット単位でシステムを構築したり，一括起動や一括停止をしたりできます。

Smart Composer機能を利用してシステムを構築するときの概念です。

実行系

業務処理を実行させる系（実行中のサーバ）を指します。

実パラメタ

アプリケーションサーバの定義ファイルに設定するパラメタです。Smart Composer機能では，抽象パラメタを一つ設定することで，互いに関連のある複数の実パラメタに，一括で値を設定できます。

スケールアウト

システム全体の処理性能を向上させることを目的として，サーバの台数を増やすことをいいます。

スケールイン

システムの規模を縮小する場合などに，サーバの台数を減らすことをいいます。

スマートエージェント

1.4モードでグローバルトランザクションを使用する場合，またはCTMを使用する場合に，動的な分散ディレクトリサービスを提供するプロセスです。

Management Serverを利用する場合，スマートエージェントは論理サーバとして扱えます。CTMはスマートエージェントによって管理されます。

なお，グローバルトランザクションの場合でも，インプロセストランザクションサービスを利用するときは，スマートエージェントは不要です。

性能解析トレース

アプリケーションサーバで構築したシステムの性能を解析するためのトレース情報です。

性能解析トレースファイル

アプリケーションサーバで構築したシステムの性能を解析するためのトレース情報をCSV形式で編集出力したテキストファイルです。

セッションフェイルオーバ機能

J2EEアプリケーション実行中のHttpSessionオブジェクトに登録されたオブジェクトをセッション情報として管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡す機能です。J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

セッションフェイルオーバ機能には，メモリセッションフェイルオーバ機能とデータベースセッションフェイルオーバ機能の2種類があります。メモリセッションフェイルオーバ機能の場合，セッション情報をSFOサーバで管理します。データベースセッションフェイルオーバ機能の場合，セッション情報をデータベースで管理します。

セッションフェイルオーバサーバ

メモリセッションフェイルオーバ機能を使用する場合に，J2EEサーバを配置しないで，SFOサーバを配置して使用するホストです。

セットアップウィザード

対話形式のウィザードプログラムを使用してシステムを構築するための機能です。必要最低限の項目を設定するだけで，J2EEアプリケーションを実行するためのシステムを構築できます。できるだけ少ない手順で実行環境を構築したい場合にお勧めの機能です。ただし，セットアップウィザードで実行できるのは，1台のマシンを対象にしたシステム構築だけです。

相互系切り替えシステム

クラスタソフトウェアを使用して実現できるシステムの一つです。アプリケーションサーバの実行系と待機系を1：1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にするシステムです。

（タ行）

待機系

障害に備えて待機させている系（待機中のサーバ）を指します。

抽象パラメタ

互いに関連のあるパラメタを一つのパラメタとしてまとめたものです。Smart Composer機能で使用します。Smart Composer機能のコマンドを使用してパラメタを展開すると，一度に複数の実パラメタに値が展開されます。

デプロイ

J2EEアプリケーションの場合，J2EEサーバ内にインポートしたJ2EEアプリケーションを，クライアントから実行可能な状態にすることです。

J2EEリソースアダプタの場合，J2EEサーバ内にインポートしたJ2EEリソースアダプタを，そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションから使用可能な状態にすることです。

展開ディレクトリ形式

EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションの形式です。

統合ネーミングスケジューラサーバ

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないで，グローバルCORBAネーミングサービスを配置して使用するホストです。統合ネーミングスケジューラサーバのレプリカを作成することで，可用性を向上できます。なお，統合ネーミングスケジューラサーバにもCTMデーモンは必要です。

統合ネーミングスケジューラサーバモデル

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないでグローバルCORBAネーミングサービスを配置するホストを作成するシステム構成モデルです。

（ナ行）

ネーミングサービス

オブジェクトに名前を付けて格納場所を管理しておくことで，格納先を知らなくても名前からそのオブジェクトを利用できるようにするサービスです。アプリケーションサーバではCORBAネーミングサービスを利用します。

Management Serverでは，ネーミングサービスを論理サーバとして扱えます。

（ハ行）

バッチアプリケーション

バッチ処理を実装したJavaアプリケーションです。バッチ実行コマンドを使用して，バッチサーバ上で実行します。バッチ実行コマンドをJP1/AJS2のジョブとして定義しておくと，JP1/AJS2からバッチアプリケーションを実行できます。

バッチサーバ

バッチアプリケーションを実行するためのサーバです。バッチアプリケーションの実行機能のほかに，バッチアプリケーションからデータベースに接続したり，EJBにアクセスしたりする機能も提供しています。

パフォーマンストレーサ

PRFデーモンのことです。

Management Serverでは，パフォーマンストレーサを論理サーバとして扱えます。

負荷分散機

Webブラウザなどからのリクエストを一元的に受け付けて，同等の機能を持つ複数のサーバに転送して各サーバの負荷を分散させるための装置です。

物理ティア

同一のデプロイメント（プロセスの配置，J2EEアプリケーションやリソースアダプタのデプロイ，定義）を適用するサーバマシンの集合を物理ティアといいます。

Smart Composer機能を利用してシステムを構築するときの概念です。

ホスト単位管理モデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverをアプリケーションサーバと同じホストに配置するシステム構成モデルです。

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

クラスタソフトウェアを使用して実現できるシステムの一つです。複数の実行系アプリケーションサーバと1台の予備系アプリケーションサーバを配置して，それぞれにManagement Serverおよび運用管理エージェントを配置したシステムです。

（マ行）

面数

ログファイルを保持する数です。ログファイルは面数分作成され，循環して使用されます。

（ヤ行）

ユーザプロパティファイル

usrconf.propertiesのことです。J2EEサーバ，Webコンテナサーバまたはサーバ管理コマンドを実行するJavaVMのシステムプロパティを指定します。なお，J2EEサーバ，Webコンテナサーバおよびサーバ管理コマンドで使用するユーザプロパティファイルは，それぞれ格納先および指定できるキーが異なります。

ユーザログ

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションが出力するログのことです。

予備系

最初に待機系として起動する系を予備系といいます。系切り替えによって，待機系が実行系になった場合でも，呼び方は変わりません。

（ラ行）

ライトトランザクション

ローカルトランザクションを最適化した状態で使用できる機能です。

ライブラリJAR

JARファイル形式でパッケージされた，共通ライブラリです。J2EEアプリケーション内のJ2EEコンポーネントから共通に使用できます。

リソースアダプタ

J2EE Connector Architectureによって，J2EEサーバまたはバッチサーバと，EISを接続するための接続機能です。

アプリケーションサーバで構築したシステムでは，データベースに接続するためのリソースアダプタであるDB ConnectorおよびDB Connector for Cosminexus RMを提供しています。また，OpenTP1のSPPと接続するためのリソースアダプタであるuCosminexus TP1 Connector，TP1/Message Queueと接続するためのリソースアダプタであるTP1/Message Queue - Access，データベース上に実現したキューに接続するためのリソースアダプタであるCosminexus RMも使用できます。

リダイレクタ

Webサーバに登録しWebコンテナへの接続を可能にするプラグインコンポーネント（ライブラリ）です。Webサーバに登録したリダイレクタによって，リクエストをURLパターンまたはラウンドロビン方式で複数のWebコンテナに振り分けて処理できます。

リデプロイ機能

J2EEアプリケーションを入れ替えるときに使用する機能です。リデプロイ機能による入れ替えは，J2EEアプリケーションのテスト時などに，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたいときに使用します。

リロード機能

開始状態にあるアプリケーションを停止させないで，アプリケーションを構成するクラスやJSPを，少ない手順で動的に入れ替える機能です。

ロードバランサ

リダイレクタを使用してリクエストを振り分ける場合に使用するワーカ定義のうち，クラスタ構成の場合に使用する特殊なワーカ定義です。振り分け先のWebコンテナのリストが定義されています。リダイレクタでは，この定義を基に，ラウンドロビン方式でリクエストの振り分け処理をします。

論理サーバ

Management Serverの運用管理の対象になる，サーバまたはクラスタです。サーバには，Webサーバ，J2EEサーバなどがあります。クラスタとは，ある共通の機能を提供するサーバの集合です。

論理ネーミングサービス

JNDIがラウンドロビン検索の対象にする複数のCORBAネーミングサービスのことです。

論理ユーザサーバ

任意のサービスやプロセスをManagement Serverの管理対象として定義した論理サーバです。Management Serverで起動・停止したり，ステータス監視したりできるようになります。

索引

[記号]
[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｆ][Ｈ][Ｊ][Ｌ][Ｍ][Ｎ][Ｏ][Ｐ][Ｒ][Ｓ][Ｔ][Ｕ][Ｗ][Ｘ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行][ワ行]

(記号)

.cmxrc

.cmxrc

(数字)

1.4モード

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

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

(英字)

(Ａ)

accountの概要

ACOSのCLIコマンド

adderの概要

adminagent.properties

adminagent.properties

adminagent.xml

adminagent.xml

Application Server

Application Serverのディレクトリ構成

(Ｂ)

bankの概要

BIG-IPでの負荷分散機の設定

BIG-IPのCLIコマンド

BMP

BMT

(Ｃ)

C++ライブラリのバージョン指定

cartの概要

checkerの概要

CLIコマンド

CMP

cmp20productの概要

CMT

cmxclient.properties

cmxclient.properties

cmxdefcombinedmodel.xml

cmxserver.properties

cmxserver.properties

combined-tier

Component Container管理者

Component Container管理者

Component Container管理者

Component Container管理者グループ

Component Container管理者による運用に関する留意事項

Component Container管理者の設定

confirmerの概要

Cookieスイッチング機能

Cookieスイッチング機能

CORBAネーミングサービス

cosminexus.xml

Cosminexus Component Container

Cosminexus Component Containerのディレクトリ構成

Cosminexus Component Transaction Monitor

Cosminexus Performance Tracer

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

CTM

ctm-tier

ctm-tier

CTMデーモン

CTMドメイン

CTMドメインマネジャ

CTMレギュレータ

CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成〔J2EEアプリケーションを実行するシステム〕

CTMを使用するパターン（ctm-tier）の簡易構築定義ファイルの作成〔バッチアプリケーションを実行するシステム〕

CTMを使用するパターン（ctm-tier）のシステムのスケールアウト

(Ｄ)

DB Connector

DB Connector以外のリソースアダプタのインポートと開始

DB ConnectorのConnector属性ファイルの編集〔J2EEアプリケーションを実行するシステム〕

DB ConnectorのConnector属性ファイルの編集〔バッチアプリケーションを実行するシステム〕

DB Connectorのインポートと開始

DD

(Ｅ)

EARファイル

Eclipseでの操作

EIS

EJB

EJBクライアント

EJBクライアントアプリケーション

EJBクライアント環境

EJBコンテナ

enrollerの概要

Enterprise Bean（EJB2.0）のサンプル実行手順

Enterprise Bean（EJB2.0）のサンプルの概要

Enterprise Bean（EJB2.0）のサンプルプログラム

Enterprise Bean（Timer Service）のサンプルプログラム

Enterprise Bean（アノテーション）のサンプルプログラム

Enterprise Bean（アノテーション）のサンプルプログラムの実行手順

(Ｆ)

free-tier

free-tier

(Ｈ)

HAモニタ

HAモニタ

HiRDBの設定（HiRDB Type4 JDBC Driverの場合）

hitachi_web.properties〔J2EEサーバ用〕

Hitachi Web Server定義ファイル

http-tier

httpsd.conf

(Ｊ)

j2ee-tier

j2ee-tier

J2EEアプリケーション

J2EEアプリケーション実行時間の監視機能

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

J2EEアプリケーションのインポートと開始

J2EEアプリケーションのインポートと開始

J2EEアプリケーションのインポートと開始

J2EEアプリケーションの管理で実行できる作業

J2EEアプリケーションの実行時間監視機能

J2EEアプリケーションを実行するシステム

J2EEアプリケーションを実行するシステムで使用するマシンの種類

J2EEアプリケーションを実行するシステムで設定する環境変数

J2EEアプリケーションを実行するシステムでの構成定義パターンの選定

J2EEアプリケーションを実行するシステムの運用・障害設計

J2EEアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応

J2EEアプリケーションを実行するシステムの構築

J2EEアプリケーションを実行するシステムの構築

J2EEアプリケーションを実行するシステムの構築に必要な作業の流れ

J2EEアプリケーションを実行するシステムを構成する要素

J2EEサーバ

J2EEサーバの起動ユーザの設定

［J2EEサーバの起動ユーザの設定］画面

［J2EEサーバの起動ユーザの設定］画面（設定内容変更）

［J2EEサーバの起動ユーザの設定］画面での画面遷移

J2EEサーバの作業ディレクトリ

J2EEサーバの作業ディレクトリの構成

J2EEサーバの自動再起動設定の無効化

J2EEリソース

J2EEリソースアダプタ

JavaBeansリソースのサンプルプログラム

JIS X0213:2004に含まれるUnicodeの補助文字を使用する場合の注意事項

JNDI

JP1

JP1

JP1/AJS

JP1/AJS2 - SO

JP1/AJS2 - SOとの連携（シナリオによるシステムの自動運転）

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

JP1/IM

JP1/IM - CM

JP1/IM - CMとの連携（システムの構成定義および管理）

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

JP1/NETM/Audit

JP1/NETM/Auditとの連携（監査ログの収集と一元管理）

JP1/SC/DPM

JP1/SC/DPM管理サーバマシン

JP1/SC/DPMの利用

JP1/SC/DPMを利用したシステムのスケールアウト〔J2EEアプリケーションを実行するシステム〕

JP1/SC/DPMを利用したシステムのスケールアウトとスケールイン〔バッチアプリケーションを実行するシステム〕

JP1/SC/DPMを利用したスケールアウト時に削除するログファイル

JP1/SC/DPMを利用して構築したシステムのスケールイン

JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成〔J2EEアプリケーションを実行するシステム〕

JP1/SC/DPMを利用する場合の簡易構築定義ファイルの作成〔バッチアプリケーションを実行するシステム〕

JP1/SC/DPMを利用できる構成定義パターン

JP1イベント

JP1との連携

JPAのサンプルプログラム

jsptagの概要

jsptobeanの概要

(Ｌ)

lb.properties

lb.propertiesの格納場所

localadderの概要

(Ｍ)

Management Server

Management ServerがCTMドメインマネジャに自動で設定する内容

Management ServerがCTMに自動で設定する内容

Management ServerがJ2EEサーバに自動で設定する内容

Management ServerがSFOサーバに自動で設定する内容

Management ServerがWebサーバに自動で設定する内容

Management Serverが自動で生成するユーザ定義ファイル

Management Serverが自動で設定する内容

Management Serverが自動で設定する論理サーバの環境変数

Management Serverがバッチサーバに自動で設定する内容

Management Server環境設定ファイル

Management Server環境設定ファイル

Management Serverの環境設定

Management Serverの起動

Management Serverの自動起動の設定

Management Serverの設定

Management Serverのセットアップ

Management Serverのセットアップと環境設定

Management Serverの動作環境の設定

Management Serverのプロパティの設定

Managementアクション

Managementアクション

Managementアクション

Managementアクション実行コマンドの作成

Managementアクション実行用プロパティファイルの設定

Managementイベント

Managementイベント

Managementイベント

Managementイベントの発行の設定

Managementイベント発行用メッセージIDリストファイル

Managementイベント発行用メッセージIDリストファイルの設定

messageの概要

Microsoft Cluster Service

Microsoft Cluster Service

mngsvrutil

mod_jk.conf

mserver.properties

mserver.properties

(Ｎ)

N:1リカバリシステム

N:1リカバリシステム

(Ｏ)

Oracleの設定（Oracle JDBC Thin Driverの場合）

ORBゲートウェイ

orderの概要

(Ｐ)

PRFデーモン

PRFトレース

PRFトレース取得レベル

PRFトレースファイル

productの概要

(Ｒ)

RMIレジストリに関する注意事項

(Ｓ)

salesrepの概要

SecurityManager

server.policy〔J2EEサーバ用〕

server.policy〔バッチサーバ用〕

Server Plug-in

Server Plug-inの組み込み手順

Server Plug-inの設定

Server Plug-inを使用するためのManagement Serverの設定

setup.cfg（セットアップウィザード用設定ファイル）

setupwizardコマンド（システムのセットアップ，アンセットアップと複製）

setupwizardコマンドでできる操作

［setupwizardコマンドの形式の表示］画面

setupwizardコマンドの使用方法の表示

sfo-tier

SFOサーバ

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

SFOサーバを使用するパターン（sfo-tier）の簡易構築定義ファイルの作成

SFOサーバを使用するパターン（sfo-tier）のシステムのスケールアウト

SFOサーバを使用するパターン（sfo-tier）のシステムのスケールイン

shipperの概要

Smart Composer機能

Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先〔J2EEアプリケーションを実行するシステム〕

Smart Composer機能で使用できるアプリケーションサーバの機能の一覧と参照先〔バッチアプリケーションを実行するシステム〕

Smart Composer機能の概要

Smart Composer機能の目的

Smart Composer機能の利点

Smart Composer機能を使用した運用作業〔J2EEアプリケーションを実行するシステム〕

Smart Composer機能を使用した運用作業〔バッチアプリケーションを実行するシステム〕

snapshotログ

SQL Serverの設定

storagebinの概要

(Ｔ)

tellerの概要

TP1インバウンド連携機能のサンプルプログラム

(Ｕ)

uCosminexus Client

uCosminexus Client

uCosminexus Operator

uCosminexus Operator

uCosminexus Operator（実行環境に対するGUI操作環境の構築）

uCosminexus Operatorのディレクトリ構成

usrconf.bat〔サーバ管理コマンド用〕

usrconf.cfg〔J2EEサーバ用〕

usrconf.cfg〔バッチサーバ用〕

usrconf.properties

usrconf.properties〔J2EEサーバ用〕

usrconf.properties〔サーバ管理コマンド用〕

usrconf.properties〔バッチサーバ用〕

usrconf〔サーバ管理コマンド用〕

(Ｗ)

warehouseの概要

Web Redirector

Webアプリケーション

Webアプリケーションのサンプルプログラム

Webアプリケーションプロパティファイル〔J2EEサーバ用〕

Webコンテナ

Webサーバ

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）の簡易構築定義ファイルの作成

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールアウト

WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン（combined-tier）のシステムのスケールイン

WebサーバとJ2EEサーバを別のサーバマシンに配置するパターン（http-tierとj2ee-tierとの組み合わせ）の簡易構築定義ファイルの作成

Webサーバ連携

Webシステム

Webシステム

Webシステム

Webシステム間での負荷分散機の共有

Webリダイレクタ環境

Windows 7〔注意事項〕

Windows Server 2008〔注意事項〕

Windows Server Failover Cluster

Windows Server Failover Cluster

Windows Vista〔注意事項〕

workers.properties

(Ｘ)

XDM/RD E2の設定

(ア行)

(あ)

アーカイブ形式

アプリケーションサーバ

アプリケーションサーバが提供するコマンドの使用

アプリケーションサーバが提供する定義ファイルの更新

アプリケーションサーバから負荷分散機を制御するための設定

アプリケーションサーバで構築するシステムで使用できるオプション製品

アプリケーションサーバでサポートしているシンボリックリンク

アプリケーションサーバで実行できる運用作業〔J2EEアプリケーションを実行するシステム〕

アプリケーションサーバで実行できる運用作業〔バッチアプリケーションを実行するシステム〕

アプリケーションサーバでのシステム構築の概要

アプリケーションサーバの機能を有効にするための設定

アプリケーションサーバマシン〔J2EEアプリケーションを実行するシステム〕

アプリケーションサーバマシン〔バッチアプリケーションを実行するシステム〕

アンインストール方法

［アンセットアップ］画面（アンセットアップの実施決定）

［アンセットアップ完了］画面

［アンセットアップ完了］画面（［一括セットアップ］画面）

［アンセットアップ完了］画面（［ようこそ］画面）

［アンセットアップ失敗］画面（アンセットアップできないシステムの場合）

［アンセットアップ失敗］画面（エラーが発生した場合）

アンセットアップ失敗時の対処

［アンセットアップ要求］画面（アンセットアップの実施確認）

［アンセットアップ要求］画面（［一括セットアップ］画面）

［アンセットアップ要求］画面（［ようこそ］画面）

(い)

一括起動〔サービスユニット単位〕

一括起動〔サービスユニット単位〕

一括起動〔すべてのサービスユニット〕

一括起動〔すべてのサービスユニット〕

［一括セットアップ］画面（システムの複製）

［一括セットアップ］画面（通常開始）

［一括セットアップ完了］画面（強制開始）

［一括セットアップ失敗］画面（強制開始）

一括停止〔サービスユニット単位〕

一括停止〔サービスユニット単位〕

一括停止〔すべてのサービスユニット〕

一括停止〔すべてのサービスユニット〕

インストール

インストール後のディレクトリ構成

インストール手順（uCosminexus Operator）

インストールとアンインストール

インストールと初期設定

インストールと初期設定の概要

インストール方法

インプロセス

インプロセスHTTPサーバ

インプロセスHTTPサーバを使用するパターン（j2ee-tier）の簡易構築定義ファイルの作成

(う)

運用・障害設計

運用管理エージェント

運用管理エージェント設定ファイル

運用管理エージェント設定ファイル

運用管理エージェントによる論理サーバの監視に関する設定

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

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

運用管理エージェントの設定

運用管理エージェントのプロパティの設定

運用管理エージェントプロパティファイル

運用管理エージェントプロパティファイル

運用管理機能の設定

［運用管理機能の設定］画面

［運用管理機能の設定］画面（設定内容変更）

運用管理コマンド

運用管理コマンド（mngsvrutil）を利用する場合の留意事項

運用管理サーバ

運用管理サーバマシン〔J2EEアプリケーションを実行するシステム〕

運用管理サーバモデル

運用管理サーバモデル

運用管理サーバモデルでのシステムのスケールアウト

運用管理サーバモデルでのシステムのスケールイン

運用管理ドメイン

運用管理ドメイン

運用管理ポータル

運用管理ポータルの概要

運用管理ポータルの目的

運用管理ポータルの利点

運用管理ポリシー

運用管理ユーザの設定

［運用管理ユーザの設定］画面

［運用管理ユーザの設定］画面（設定内容変更）

運用設計〔J2EEアプリケーションを実行するシステム〕

運用設計〔バッチアプリケーションを実行するシステム〕

(お)

オプション定義ファイル〔J2EEサーバ用〕

オプション定義ファイル〔バッチサーバ用〕

(カ行)

(か)

各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成〔J2EEアプリケーションを実行するシステム〕

各構成定義パターンで使用できる設定と簡易構築定義ファイルの作成〔バッチアプリケーションを実行するシステム〕

カスタムセットアップ

カスタムセットアップ

仮想サーバ

簡易構築定義ファイル

簡易構築定義ファイル

［簡易構築定義ファイルのエクスポート完了］画面

［簡易構築定義ファイルのエクスポート失敗］画面（Management Serverが起動していない場合）

［簡易構築定義ファイルのエクスポート失敗］画面（エクスポートできない変更をしている場合）

簡易構築定義ファイルの構成

簡易構築定義ファイルの作成〔J2EEアプリケーションを実行するシステム〕

簡易構築定義ファイルの作成〔バッチアプリケーションを実行するシステム〕

簡易構築定義ファイルの作成手順〔J2EEアプリケーションを実行するシステム〕

簡易構築定義ファイルの作成手順〔バッチアプリケーションを実行するシステム〕

簡易構築定義ファイルの設定内容〔J2EEアプリケーションを実行するシステム〕

簡易構築定義ファイルの設定内容〔バッチアプリケーションを実行するシステム〕

簡易構築定義ファイルのパラメタだけを編集する場合のチューニング

環境構築／運用時の注意事項

環境変数の詳細

環境変数の設定

環境変数の設定（uCosminexus Operator）

環境変数の設定の要否

監査証跡

監査ログ

管理者特権で実行する必要がある操作

管理ユーザアカウントを設定しない場合の設定

関連マニュアル

(き)

業務処理プログラム

(く)

クライアント共通設定プロパティファイル

クライアント共通設定プロパティファイル

クライアント設定プロパティファイル

クライアント設定プロパティファイル

クラスタ

クラスタソフトウェア

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

グローバルCORBAネーミングサービス

(け)

系

系切り替え

(こ)

構成定義パターン

構成定義パターン

構成定義パターンごとの簡易構築定義ファイルの作成〔J2EEアプリケーションを実行するシステム〕

構成定義パターンごとの簡易構築定義ファイルの作成〔バッチアプリケーションを実行するシステム〕

構成定義パターン選定の考え方〔J2EEアプリケーションを実行するシステム〕

構成定義パターン選定の考え方〔バッチアプリケーションを実行するシステム〕

構成変更定義ファイル

構成変更定義ファイル

構成変更定義ファイルの作成

構成変更定義ファイルの作成

構成変更定義ファイルの作成

構成変更定義ファイルの作成

構成変更定義ファイルの作成

構築済みのシステムの移行〔J2EEアプリケーションを実行するシステム〕

構築済みのシステムの移行〔バッチアプリケーションを実行するシステム〕

構築済みのシステムの移行時に出力する簡易構築定義ファイルの内容

構築済みのシステムの移行手順

構築済みのシステムを移行するときの注意事項

構築済みのシステムを移行するときの注意事項

異なるWebシステム間で負荷分散機を共有する場合の簡易構築定義ファイルの作成

このマニュアルでの表記

このマニュアルの参考情報

コマンド実行時に指定するWebシステム名，サービスユニット名，およびサーバ名に関する注意事項

コマンドとシステム構築の関係〔J2EEアプリケーションを実行するシステム〕

コマンドとシステム構築の関係〔バッチアプリケーションを実行するシステム〕

コンテナ拡張ライブラリ

(サ行)

(さ)

サーバ管理コマンド

サーバ管理コマンドによるサンプル実行環境の構築，運用手順

サーバ管理コマンドの動作設定のカスタマイズ

サーバ管理コマンドのログ取得の設定

サーバ管理コマンドを利用する場合の留意事項

サーバ設定プロパティファイル

サーバ設定プロパティファイル

サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

サーバマシン内に複数のサービスユニットを配置する場合の簡易構築定義ファイルの作成

サービス閉塞

サービスユニット

サービスユニット

サービスユニット

サービスユニット単位の一括起動と一括停止〔J2EEアプリケーションを実行するシステム〕

サービスユニット単位の一括起動と一括停止〔バッチアプリケーションを実行するシステム〕

サービスユニットとは〔J2EEアプリケーションを実行するシステム〕

サービスユニットとは〔バッチアプリケーションを実行するシステム〕

サービスユニットの追加

サービスユニットの追加

サービスユニットの追加

サービスユニットの追加

サービスユニットの閉塞によるシステムの部分メンテナンス

サービスユニットを自動再起動するための設定〔J2EEアプリケーションを実行するシステム〕

サービスユニットを自動再起動するための設定〔バッチアプリケーションを実行するシステム〕

作業ディレクトリに関する注意事項

作業ディレクトリのパス長の見積もり式〔J2EEサーバ〕

作業ディレクトリのパス長の見積もり式〔バッチサーバ〕

サンプルプログラム一覧（Enterprise Beanの種類と動作内容）

サンプルプログラムで使用するJMSの設定

サンプルプログラムで使用するデータベースの設定

サンプルプログラムで使用するメールの設定

サンプルプログラムのクライアントの種類

サンプルプログラムの使用

(し)

システム環境の移行で実行できる運用作業〔J2EEアプリケーションを実行するシステム〕

システム環境の移行で実行できる運用作業〔バッチアプリケーションを実行するシステム〕

システム環境の設定

［システム環境の設定］画面

［システム環境の設定］画面（設定内容変更）

システム構成ごとに選択できる構成定義パターン〔J2EEアプリケーションを実行するシステム〕

システム構成ごとに選択できる構成定義パターン〔バッチアプリケーションを実行するシステム〕

システム構成とセットアップ方法の決定

システム構成に合わせた構成定義パターンの選定

システム構成の選択

［システム構成の選択］画面

［システム構成の選択］画面（設定内容変更）

システム構築で使用するファイル〔J2EEアプリケーションを実行するシステム〕

システム構築で使用するファイル〔バッチアプリケーションを実行するシステム〕

システム構築の概要〔J2EEアプリケーションを実行するシステム〕

システム構築の概要〔バッチアプリケーションを実行するシステム〕

システム構築の流れ〔J2EEアプリケーションを実行するシステム〕

システム構築の流れ〔バッチアプリケーションを実行するシステム〕

システム提供の障害検知時コマンド

システム提供の障害検知時コマンド

システムのアンセットアップ

システムの一括起動（READY）〔J2EEアプリケーションを実行するシステム〕

システムの一括起動（サービスユニットの開始）〔J2EEアプリケーションを実行するシステム〕

システムの一括起動〔バッチアプリケーションを実行するシステム〕

システムの一括構築〔J2EEアプリケーションを実行するシステム〕

システムの一括構築〔バッチアプリケーションを実行するシステム〕

システムの運用

システムの運用監視で実行できる作業〔J2EEアプリケーションを実行するシステム〕

システムの運用監視で実行できる作業〔バッチアプリケーションを実行するシステム〕

システムの運用で使用する機能〔J2EEアプリケーションを実行するシステム〕

システムの運用で使用する機能〔バッチアプリケーションを実行するシステム〕

システムの運用の概要〔J2EEアプリケーションを実行するシステム〕

システムの運用の概要〔バッチアプリケーションを実行するシステム〕

システムの運用を始める前に

システムの監査で実行できる運用作業〔J2EEアプリケーションを実行するシステム〕

システムの監査で実行できる運用作業〔バッチアプリケーションを実行するシステム〕

システムの起動と停止で実行できる作業〔J2EEアプリケーションを実行するシステム〕

システムの起動と停止で実行できる作業〔バッチアプリケーションを実行するシステム〕

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

システムの構成定義〔J2EEアプリケーションを実行するシステム〕

システムの構成定義〔バッチアプリケーションを実行するシステム〕

システムの構築方法の種類（J2EEアプリケーションを実行するシステム）

システムの構築方法の種類（バッチアプリケーションを実行するシステム）

システムの削除〔J2EEアプリケーションを実行するシステム〕

システムの削除〔バッチアプリケーションを実行するシステム〕

システムの情報モデルの変更

システムの情報モデルの変更

システムの情報モデルの変更

システムの情報モデルの変更

システムの情報モデルの変更（サービスユニットの追加）

システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

システムの情報モデルの変更（複製先アプリケーションサーバのホスト情報変更）

システムの処理性能解析で実行できる作業〔J2EEアプリケーションを実行するシステム〕

システムの処理性能解析で実行できる作業〔バッチアプリケーションを実行するシステム〕

システムのスケールアウト〔J2EEアプリケーションを実行するシステム〕

システムのスケールアウト〔バッチアプリケーションを実行するシステム〕

システムのスケールアウトとスケールイン〔バッチアプリケーションを実行するシステム〕

システムのスケールイン〔J2EEアプリケーションを実行するシステム〕

システムのスケールイン〔バッチアプリケーションを実行するシステム〕

システムの設定の一括変更〔J2EEアプリケーションを実行するシステム〕

システムの設定の一括変更〔バッチアプリケーションを実行するシステム〕

システムの設定変更

システムの設定変更

システムの設定変更

システムの設定変更〔J2EEアプリケーションを実行するシステム〕

システムの設定変更〔バッチアプリケーションを実行するシステム〕

システムの設定変更時の注意事項

システムのセットアップ

システムのセットアップの流れ

システムの複製の流れ

システムの変更で実行できる運用作業

システムの変更で実行できる運用作業

システムのメンテナンス

システムをセットアップする前に

実行環境に対するGUI操作環境

実行系

実パラメタ

［終了確認］画面

障害検知時コマンドの作成

障害設計〔J2EEアプリケーションを実行するシステム〕

障害設計〔バッチアプリケーションを実行するシステム〕

障害に対応したシステムの構築〔J2EEアプリケーションを実行するシステム〕

障害に対応したシステムの構築〔バッチアプリケーションを実行するシステム〕

障害発生時にサービスユニットを自動閉塞するための設定

使用リソースの設定

(す)

スケールアウト

スケールアウト

スケールアウトの準備

スケールアウト用ホスト定義ファイル

スケールアウト用ホスト定義ファイル

スケールアウト用ホスト定義ファイルの作成

スケールアウト用ホスト定義ファイルの作成

スケールイン

すべてのサービスユニットの一括起動と一括停止〔J2EEアプリケーションを実行するシステム〕

すべてのサービスユニットの一括起動と一括停止〔バッチアプリケーションを実行するシステム〕

スマートエージェント

(せ)

性能解析トレース

性能解析トレースファイル

セキュリティポリシーファイル〔J2EEサーバ用〕

セキュリティポリシーファイル〔バッチサーバ用〕

セッションフェイルオーバ機能

セッションフェイルオーバサーバ

セッションフェイルオーバサーバマシン〔J2EEアプリケーションを実行するシステム〕

設定の一括変更

セットアップウィザード

セットアップウィザード

セットアップウィザードで使用するコマンド

セットアップウィザードで使用するコマンドとファイル

セットアップウィザードで使用するファイル

セットアップウィザードで設定されるパラメタ

セットアップウィザードで設定できる項目

セットアップウィザードでセットアップしたシステムの起動と停止

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理J2EEサーバ）

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理Webサーバ）

セットアップウィザードでパラメタの省略値と異なる値が設定されるパラメタ（論理パフォーマンストレーサ）

セットアップウィザードの概要

セットアップウィザードの起動

セットアップウィザードの目的

セットアップウィザードの利点

セットアップウィザードを使用したシステムのセットアップ

セットアップウィザードを使用したシステムのセットアップの流れ

セットアップウィザードを使用するための準備

セットアップウィザードを使用する場合の注意事項

セットアップウィザードを使用する前に

［セットアップ完了］画面

［セットアップ失敗］画面

［セットアップ失敗］画面（障害時のログを採取しない場合）

［セットアップ失敗］画面（障害時のログを採取する場合）

セットアップ失敗時の対処

［セットアップ情報］画面

［セットアップ情報］画面（セットアップ情報の再設定）

［セットアップ情報］画面（セットアップ情報の保存）

［セットアップ情報］画面（セットアップ情報ファイルの上書き）

［セットアップ情報］画面（セットアップ情報ファイルの保存）

［セットアップ情報］画面（ポート番号エラー）

セットアップ情報の確認

セットアップ情報ファイルの内容表示

［セットアップ情報ファイルの内容表示］画面

セットアップ情報ファイルを使用した一括セットアップ

セットアップの開始

セットアップの実行

［セットアップの実行］画面

セットアップ方法の選択

［セットアップ方法の選択］画面

［セットアップ方法の選択］画面（設定値確認）

(そ)

相互系切り替えシステム

(タ行)

(た)

待機系

(ち)

抽象パラメタ

チューニング

チューニング〔J2EEアプリケーションを実行するシステム〕

チューニング〔バッチアプリケーションを実行するシステム〕

(て)

ディスク複製OSインストール機能

データベース（XDM/RD E2・SQL Server）の設定

データベースサーバマシン〔J2EEアプリケーションを実行するシステム〕

データベースサーバマシン〔バッチアプリケーションを実行するシステム〕

データベース接続環境の設定

［データベース接続環境の設定］画面

［データベース接続環境の設定］画面（使用するデータベースの決定）

［データベース接続環境の設定］画面（設定内容確認）

［データベース接続環境の設定］画面（データベースへの接続設定：HiRDB）

［データベース接続環境の設定］画面（データベースへの接続設定：Oracle）

データベースを使用するための設定

デプロイ

展開ディレクトリ形式

テンプレートファイル

(と)

統合ネーミングスケジューラサーバ

統合ネーミングスケジューラサーバマシン〔J2EEアプリケーションを実行するシステム〕

統合ネーミングスケジューラサーバモデル

トラブルシューティングで実行できる作業〔J2EEアプリケーションを実行するシステム〕

トラブルシューティングで実行できる作業〔バッチアプリケーションを実行するシステム〕

トラブルの種別と対処

トラブルへの対処〔J2EEアプリケーションを実行するシステム〕

トラブルへの対処〔バッチアプリケーションを実行するシステム〕

(ナ行)

(ね)

ネーミングサービス

(ハ行)

(は)

バッチアプリケーション

バッチアプリケーションのスケジューリング機能を使用するための設定

バッチアプリケーションを実行するシステム

バッチアプリケーションを実行するシステムで使用するマシンの種類

バッチアプリケーションを実行するシステムで設定する環境変数

バッチアプリケーションを実行するシステムでの構成定義パターンの選定

バッチアプリケーションを実行するシステムの運用

バッチアプリケーションを実行するシステムの運用・障害設計

バッチアプリケーションを実行するシステムの構成情報と簡易構築定義ファイルの定義との対応

バッチアプリケーションを実行するシステムの構築

バッチアプリケーションを実行するシステムの構築

バッチアプリケーションを実行するシステムの構築に必要な作業の流れ

バッチアプリケーションを実行するシステムを構成する要素

バッチサーバ

バッチサーバとして動作するための設定

バッチサーバの作業ディレクトリ

バッチサーバの作業ディレクトリの構成

バッチサーバを配置するパターン（j2ee-tier）の簡易構築定義ファイルの作成

パフォーマンストレーサ

パラメタチューニングしたシステムの複製

(ひ)

標準セットアップ

標準セットアップ

(ふ)

負荷分散機

負荷分散機

負荷分散機定義プロパティファイル

負荷分散機のAPI

負荷分散機の冗長化

負荷分散機の冗長化構成でトラブルが発生した場合の対処

負荷分散機の制御方法

負荷分散機の設定

負荷分散機を冗長化する場合の簡易構築定義ファイルの作成

負荷分散機を冗長化する場合の注意事項

物理ティア

物理ティア

物理ティア

物理ティアとは〔J2EEアプリケーションを実行するシステム〕

物理ティアとは〔バッチアプリケーションを実行するシステム〕

プログラムのインストール

プロセスの種類と論理サーバとの対応〔J2EEアプリケーションを実行するシステム〕

プロセスの種類と論理サーバとの対応〔バッチアプリケーションを実行するシステム〕

(ほ)

ホスト単位管理モデル

ホスト単位管理モデル

ホスト単位管理モデルでのシステムのスケールアウト

ホスト単位管理モデルでのシステムのスケールイン

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

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

(マ行)

(め)

面数

(ヤ行)

(ゆ)

ユーザ作成の障害検知時コマンド

ユーザ作成の障害検知時コマンド

ユーザプロパティファイル

ユーザプロパティファイル〔J2EEサーバ用〕

ユーザプロパティファイル〔バッチサーバ用〕

ユーザログ

ユーザログ機能のサンプルプログラム

(よ)

［ようこそ］画面

予備系

(ラ行)

(ら)

ライトトランザクション

ライブラリJAR

(り)

リクエストで使用する場合の注意事項

リソースアダプタ

リソースアダプタのインポートと開始〔J2EEアプリケーションを実行するシステム〕

リソースアダプタのインポートと開始〔バッチアプリケーションを実行するシステム〕

リソースアダプタまたはJ2EEアプリケーションの設定変更を伴う場合のチューニング

リソースおよびJ2EEアプリケーションの設定で使用できる機能（J2EEアプリケーションを実行するシステム）

リソース枯渇監視機能

リソース枯渇監視機能

リソース枯渇監視機能の設定

リソース枯渇監視機能の設定

リソースとJ2EEアプリケーションの設定〔J2EEアプリケーションを実行するシステム〕

リソースとJ2EEアプリケーションの設定の前に〔J2EEアプリケーションを実行するシステム〕

リソースの管理で実行できる作業〔J2EEアプリケーションを実行するシステム〕

リソースの管理で実行できる作業〔バッチアプリケーションを実行するシステム〕

リソースの設定〔バッチアプリケーションを実行するシステム〕

リソースの設定で使用できる機能（バッチアプリケーションを実行するシステム）

リソースの設定の前に〔バッチアプリケーションを実行するシステム〕

リダイレクタ

リダイレクタ動作定義ファイル

リデプロイ機能

リデプロイによる入れ替え

リロード機能

リロードによる入れ替え

(ろ)

ロードバランサ

論理サーバ

論理サーバ

論理サーバの環境変数

論理サーバのコンフィグレーション定義の適用範囲〔J2EEアプリケーションを実行するシステム〕

論理サーバのコンフィグレーション定義の適用範囲〔バッチアプリケーションを実行するシステム〕

論理ネーミングサービス

論理ユーザサーバ

論理ユーザサーバを配置する場合の簡易構築定義ファイルの作成

(ワ行)

(わ)

ワーカ定義ファイル

■ 商標類

AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
BIG-IP，3-DNS，iControl Services Manager，FirePass　および F5 は F5 Networks Inc の商標，または登録商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Internet Explorerは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSTLは，The Jakarta Projectのタグライブラリ名称です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle9iは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
SQL Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
PuTTYは，Simon Tatham氏が提供するオープンソースソフトウェア(フリーソフトウェア)です。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).