1.はじめに

本書はWebOTX実行環境を運用するための運用操作法について概要や具体的な設定項目や設定方法について記載しています。

対象読者

このマニュアルはWebOTX Application Server Web Edition、Standard-J Edition、Standard Edition、Enterprise Editionを使って運用環境を構築するシステムエンジニア、日々の運用を行うオペレータを対象としています。

 

表記について

パス名表記

本書ではパス名の表記については特にOSを限定しない限りセパレータはスラッシュ’/’で統一しています。Windows環境においては’\’に置き換えてください。

環境変数表記

インストールディレクトリやドメインルートディレクトリなど環境によって値の異なるものについては環境変数を用いて表します。

${env} または　$(env)で表しています。

例)
${AS_INSTALL} : インストールディレクトリ
${INSTANCE_ROOT}: ドメインルートディレクトリ

 

コマンド操作について

本書中では運用操作に用いるコマンドの詳細についての説明は省略しています。

コマンドの詳細は「運用管理コマンド」、「運用管理コマンドリファレンス」を参照してください。

 

2.運用管理の概要

WebOTXの、運用管理の概要について説明します。

 

2.1.ドメイン

WebOTXではシステムをドメインという構成単位で管理を行います。ドメインについて説明します。

2.1.1.ドメインとは

WebOTXの基本的な構成単位をドメインと呼びます。このドメインはJMX仕様で定義されているドメインに対応します。ドメインはWebOTXで管理するリソースやサービス群を論理的にグルーピングしています。ドメインは独立して運用され、コンフィグレーション情報など構成情報はドメイン単位で独立したディレクトリに管理されます。それぞれの業務システムの要件にあわせてドメインを構成することができます。例えば1つのホストで商用環境と評価環境を構築したい場合、そのホスト上に商用のドメインと評価用のドメインを構成させることができます。また稼動、待機構成のクラスタ構成を行いたい場合は、複数のホストで1つのドメインを定義できます。

2.1.2.ドメインの構成要素

ドメインを構成するモジュール群について説明します。ドメインは大きくドメイン情報を管理する運用管理エージェントとアプリケーションサーバとしての機能を提供するサービス群(以下の表で示します)で構成されます。

運用管理エージェントはそのドメイン内で動作するサービスやコンフィグレーションを管理します。またリモートから運用操作が行えるためのインタフェースを外部に提供します。

サービスには次のものを提供しており、そのドメインで必要なサービスをドメイン作成時に指定します。

WebOTXが提供するサービス群

サービス名称 Web Edition Standard-J Edition Standard Edition Enterprise Edition

HTTPサーバ

○

○

○

○

Webコンテナ

○

○

○(注1)

○(注1)

EJBコンテナ

×

○

○(注2)

○(注2)

JNDIサービス

○

○

○

○

JMSサービス

×

○

○

○

Object Brokerサービス

○

○

○

○

Transactionサービス

○

○

○

○

TPモニタ

×

×

○

○

WatchServer

×

×

×(注3)

○

キャッシュ名前サーバ

×

×

×(注3)

○

(注1) Web Editionおよび Standard-J EditionのWebコンテナはWebOTXエージェントのJava VM内で動作します。 Standard Editionおよび Enterprise Editionの Webコンテは WebOTXエージェントとは独立したJava VM上で動作します。ただし従来どおり WebOTXエージェントのJava VM内で動作させることも可能です。

(注2) Standard-J EditionのEJBコンテナはWebOTXエージェントのJava VM内で動作します。Standard Editionおよび Enterprise EditionのEJBコンテは WebOTXエージェントとは独立したJava VM上で動作します。

(注3) Standard EditionはWebOTXクラスタ環境と組み合わせることにより、WatchServerやキャッシュ名前サーバを利用することが出来ます。

2.1.3.ドメインのタイプ

WebOTXでは大きく2つのドメインにタイプ分けしています。

 

2.1.4.シングルドメインモードとマルチドメインモード

ドメイン構成としてV6.4からシングルドメインモードとマルチドメインモードをインストール時に選択することが可能になりました。ドメインを１つしか利用しないケースでは管理ドメインを起動せずに済むためマシンリソースを節約することができます。

ドメインモードの選択

 

ドメインモードの切り替え

 

補足：マルチドメインモードはすべてのWebOTX Editionでサポートされています。

2.1.5.ドメインの構成

業務システムのユーザドメインの構成について説明します。ドメイン構成は大きく次の6つのグループに分割することができます(DBサーバについては省略します)。これらについてそれぞれ独立したドメインに割り当てることも、同一のドメインに割り当てることも可能ですが、基本的な構成について次に説明します。

 

Web Editionドメイン

Web Editionで動作するサービスを1つのドメインで動作させます。Webアプリケーションシステムを構築する上でもっともシンプルなドメイン構成です。1台のマシンで全て動作させる場合は通常この構成となり以下のサービスが動作します。

マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置(Load Balancer)により分散を行います。

 

Standard-JEditionドメイン

Standard-J Editionで動作するサービスを1つのドメインで動作させます。J2EEアプリケーションシステムを構築する上でもっともシンプルなドメイン構成です。1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は通常この構成となり以下のサービスが起動します。

マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。

 

Standard/EnterpriseEditionドメイン

Standard/Enterprise Editionで動作するサービスを1つのドメインで動作させます。システムを構築する上でもっともシンプルなドメイン構成です。1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は通常この構成となり以下のサービスが起動します。

マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。

 

Webサーバドメイン

Webサーバ層を構成するドメインでは次のサービスが動作します。

Webサーバはクラスタ化する場合、基本的にはマルチサーバ負荷分散構成となります。さらに1つのマシンでは1つのWebサーバ、Webコンテナを動作させる構成が基本です。

また、パターンによっては1マシン内でWebサーバとWebコンテナが1対nになるような構成も可能です。この場合はそれぞれ(Webサーバ、Webコンテナ)が独立したドメイン構成となります。

 

APサーバドメイン

APサーバ層を構成するドメインでは次のサービスが動作します。

APサーバ層のクラスタとしては負荷分散がメインですが稼動待機構成(シングルスタンバイ、相互スタンバイ)も用いられ、また業務の特性に応じてマルチシステム構成となるため、柔軟な構成が望まれています。

負荷分散構成：

シングルスタンバイ構成：

相互スタンバイ構成：

マルチシステム構成：

 

名前サーバドメイン

名前サーバ層を構成するドメインでは次のサービスが動作します。

名前サーバ自身は、負荷分散クラスタなどの負荷を分散する構成にする必要はありませんが、基本的にはシステムで1つの存在であるので、SPOF(Single Point of Failure)とならないための対策が必要となります。また名前サーバ専用にマシンを割り当てる構成は、コスト的に敬遠されるためさまざまな箇所に配置されることが想定されます。

Webサーバ上に配置する場合は、Webサーバと1対1で配置します。各名前サーバには全てのAPサーバの名前情報が格納されるように設定します。Webサーバ上の名前サーバは、APサーバ負荷分散実装するために、全てのAPサーバ上の情報を持ち、どのWebサーバ上の名前サーバも同一の情報を保持しています。

APサーバ上に配置する場合は、APサーバのクラスタ構成によって構成が変わります。

 

負荷分散構成：
負荷分散構成の場合、1マシンに1名前サーバを配置します。APサーバ負荷分散実装するために、名前サーバ間でレプリケーションを行い、全てのAPサーバ上の情報を格納します。名前サーバは全て同一の情報を保持しています。

 

シングルスタンバイ構成：
シングルスタンバイ構成の場合、稼動系マシンに1名前サーバとなります。異常時にはAPサーバと同様、名前サーバもフェイルオーバします。この場合、フェイルオーバしても登録情報を引き継げるようにする必要があるため、情報を永続化します。

 

相互スタンバイ構成：
相互スタンバイ構成の場合、APサーバドメイン1つにつき1名前サーバとなります。この場合、縮退時には1マシン上に複数の名前サーバが稼動します。

 

マルチシステム構成：
マルチシステム構成の場合、システムごとに名前サーバを配置するか、1つにするかは要件に依存します。通常は1つで問題はありませんが、本番、テスト系のような構成の場合、名前サーバも本番、テスト系で別運用となるため独立に運用できることが必要です。


補足:WebEditionにおいてAPサーバドメインを作成することはできません。

 

2.2.実装している仕様について

WebOTX の運用管理基盤で、Javaで標準仕様とされている以下の仕様に対応しています。WebOTXが提供するシステム管理ツールを利用してシステムを運用管理行う上ではこの仕様をほとんど意識する必要はありませんが、システム構成を検討したり、システム構築したり、運用管理APIを使って独自の運用管理アプリケーションを作成する 上で参考になります。それぞれの仕様の詳細についてはそれぞれのJSRより公開されている仕様を参照してください。

2.2.1.JMX

WebOTXにおけるJMXの実装について説明します。

JMX仕様はJava言語によるネットワークマネージメントアーキテクチャで、マルチサーバで構成されたシステムをリモートの運用管理アプリケーションから一元的に運用管理するためのAPIやサービスを提供します。WebOTXではJMXで規定された運用管理基盤を提供しています。

JMXのアーキテクチャ

JMXで規定されているアーキテクチャについて説明します。

JMXアーキテクチャの構成

JMXアーキテクチャは次の3レベルで構成されており、エージェントを通して運用管理クライアントから管理リソースを制御する仕組みとなっています。

 

Instrumentation level

Agent level

 

Distributed Service level

補足：ObjectNameのフォーマットについてはJ2EE Management仕様でさらに詳細に規定されています。WebOTXのMBeanのObjectNameについてはJ2EE ManagementのObjectNameフォーマットに準拠しています。詳細は「2.2.3J2EE Management」を参照ください。

2.2.2.JMX Remote

WebOTXにおけるJMX Remote APIの実装について説明します。

JMX仕様ではリモートの運用管理クライアントからどのようにエージェントにアクセスするのかはアダプタ・コネクタを用いてアクセスするというガイドラインは示していましたが、詳細な仕様を規定していません。JMX Remote APIではJMX準拠の運用管理クライアントが利用するコネクタの仕様について規定しています。WebOTXではJMX Remote APIで規定されたコネクタとそのコネクタを利用したJMX準拠の運用管理クライアントを提供しています。

 

コネクタ

リモートの運用管理クライアントからMBeanServerにアクセスするためにJMX Remote APIではいくつかのプロトコルを利用したコネクタインタフェース(MBeanServerConnectionインタフェース)について規定しています。コネクタインタフェースについてはプロトコルに依存せず、MBeanServerのインタフェースと同様なものを提供しています。

 

コネクタの種類

JMX Remote APIとしては、クライアント、サーバ間の通信プロトコルにより、標準で次の2つのコネクタについて規定しています。

WebOTXでは以下のコネクタを提供しています。

エージェントへの接続

コネクタを利用してエージェントに接続する方式について説明します。JMX Remote APIでは次の方式について規定しています。

Notification

JMX Remote APIではリモートの運用管理クライアントに対してエージェントで発生したイベントを通知する機能(Notification)について規定しています。JMX Remote APIのNotificationは非同期で実装されており、バッファ上にイベントが存在する限り、そのイベントを受け取ることができます。WebOTXでもこれに基づいたリモートへのNotificationを提供します。

コネクタは全てのMBeanで発生するNotificationイベントをハンドルして運用管理クライアントに通知する機能を実装しています。そのためにコネクタはMBeanの作成、削除イベントを監視し、MBeanが作成されると、リスナーのプロキシ(下図のL’)をMBeanServerに登録します。こうして、コネクタは運用管理クライアントの接続の有無にかかわらず、エージェントで発生する全てのイベントをハンドルします。非同期通知を実装するため、コネクタはハンドルしている全てのNotificationイベントを格納するNotificationBufferを保持しています。NotificationBufferはシーケンス番号を元にイベントを管理しており、新しいイベントは前回のシーケンス番号をインクリメントして割り振られます。また、バッファのサイズは有限であり、もしバッファがいっぱいになった場合は、最も古いイベントが削除されます。

クライアント側でaddNotificationListenerメソッドによりエージェントに対してリスナーの登録を行うと、クライアントコネクションは次に検索するシーケンス番号を保持します。コネクタ側で、クライアントが持つシーケンス番号からイベントを検索しフィルタ条件に一致するイベントがあれば、そのイベントを運用管理クライアントに通知します。

2.2.3.J2EE Management

WebOTXにおけるJ2EEManagementの実装について説明します。

J2EE Management仕様はJ2EEにおいて、Javaエンタープライズ・マネージメントやモニタリング・サービスを実現する共通フレームワークとして、JMXを基盤機能として規定されています。J2EE Management仕様の目的は、J2EEが提供する情報にアクセスするため、より良い定義モデルを供給するJ2EEアーキテクチャの、基本的な管理可能の概観を抽象化することにあります。加えてこの仕様では、プラットフォームリソースのモニタリングやコントロールに参加するJ2EEコンポーネントに操作が共通の標準APIを定義しています。J2EE Management仕様で規定している基本機能は次のとおりです。

 

 

なおJ2EE Management仕様は上記以外に既存マネージメントプロトコル(SNMP/CIM)とのマッピングについても規定していますが、これについてはWebOTX では未サポートであるため説明は省略します。

 

管理オブジェクト

J2EE Management仕様では、管理リソース単位で管理オブジェクト(Managed Object以下MOと略します)を定義しています。管理オブジェクトはリソースのコンフィグレーションの取得や設定、状態管理、パフォーマンス情報の取得をするためのメソッドを提供します。管理オブジェクトはJMX仕様で規定されているMBeanで実装されています。J2EE Management仕様ではJ2EEアプリケーションサーバを構成する全ての管理リソースについて具体的に管理オブジェクトのインタフェースを規定しています。これに従いWebOTXも全ての管理リソースを管理オブジェクトとしてJMXのmodel MBeanの形式で提供しています。

またJ2EE Management仕様では、次に示す管理オブジェクトとしての振る舞いを規定しています。MOはMBeanであるので属性、オペレーション、コンストラクタ、notificationをインタフェースとして提供します。

WebOTXでは基本的にはJ2EE Management仕様に準拠したMOとして実装していますが、J2EE RIなど流用元で提供されている一部MBean（統計情報を管理するStatsHolderMBeanなど）については以下に示すObjectNameフォーマットに従っていないものもあります。

ObjectName

JMX仕様で個々のMBeanを識別するための情報としてObjectNameが用いられていますが、J2EE ManagementでもMOの識別にはObjectNameを使用しています。J2EEのObjectNameはJMXフォーマットで定められた形式であるがいくつか必須のプロパティを規定しています。

[フォーマット]

[domainName]:J2EEType=j2eeType,name=name, <parent-j2eeType>=<parent ManagedObject name> [,property=value,…]

[説明]

domainName JMX仕様 大文字・小文字を区別する文字列で、MBeanの名前空間を指定します。MBeanServer自身のDomainNameはデフォルトドメイン名として扱われ、省略することができます。省略した場合はMBeanServerにより自身のDomainNameを補完してMBeanの検索を行います。これにより運用管理クライアントはドメイン名を知らなくても省略してプロパティ値のみでMBeanの指定を行うことができます。DomainNameは’.’セパレートされたネットワークドメイン名とは逆の記述で表現します。 例) jp.co.nec.mydomain
J2EEType=j2eeType J2EE仕様 MOの種別を表す。J2EEにおいていくつかのJ2EETypeが規定されています。WebOTX独自のJ2EETypeもいくつか規定しており、WebOTXのプレフィックスをつけています。必須プロパティです。
name=name J2EE仕様 個々のMOにつけられたオブジェクト名称。必須プロパティです。
<parent-j2eeType>=
<parentManagedObject name>		 J2EE仕様 MO間の親子関係を識別するため、子のMOについては親のJ2EETypeとそのnameプロパティの値を指定します。子のMOについては必須プロパティです。
property=value JMX仕様 上記のプロパティ以外で、個々のMOを一意に決定するためのプロパティとその値を示す文字列です。

[例]

 

必須属性

MOとして必ず持たなければならない属性がJ2EE Management仕様により規定されています。MOがどのような特性をもつのかを表します。これらの属性はJ2EEManagedObjectインタフェースで規定されており、MOは必ずこのインタフェースを実装しなければなりません。

 

状態管理

J2EEMangementでは状態のあるリソースのMOには状態管理を行い、運用管理クライアントに対してその状態を取得できるインタフェースを提供するように規定されています。さらに状態に変更があった場合、その変更をイベントとして通知することも規定されています。状態管理を行うためのインタフェースとしてStateManageableインタフェースが用意されており、MOはそのインタフェースを実装するようになっています。WebOTXで提供するMBeanも状態管理を提供するものは全てこのインタフェースを実装しています。

StateManageableインタフェースで規定されているインタフェースの概要を以下に示します。

パフォーマンスモニタリング

J2EE Managementでは管理リソースのパフォーマンス情報を提供するため、リソース毎に提供すべきパフォーマンス情報について規定しています。それぞれのMOに対して提供すべきパフォーマンス情報を定義するインタフェースを規定しています。例えばEJBのMOについてはEJBStatsというインタフェースを規定し、そのインタフェースを実装したMOを提供しています。パフォーマンス情報を提供するために以下のインタフェースを規定しています。なおパフォーマンスモニタリングの詳細については「運用編(モニタリング)」を参照してください。

 

Statisticインタフェース

Statisticインタフェースおよびそのサブインタフェースは、パフォーマンスデータを供給するのに必要なアクセサを規定します。以下のインタフェースが規定されています。

属性名 概要
name パフォーマンスデータの名称
unit パフォーマンスデータの単位
description パフォーマンスデータの概要
startTime パフォーマンスデータを採取し始めた時間
lastUpdateTime パフォーマンスデータを最後に取得した時間
属性名 概要
count パフォーマンスデータの値(回数)
属性名 概要
count パフォーマンスデータを採取した回数。
maxTime 採取した中での最大値。
minTime 採取した中での最小値。
totalTime 採取したパフォーマンスデータの合計値。countで割ると平均値となる。
属性名 概要
highWaterMark 採取した中での最大値。
lowWaterMark 採取した中での最小値。
current カレント値
属性名 概要
upperBound 上限値
lowerBound 下限値
属性名 概要
highWaterMark 採取した中での最大値。
lowWaterMark

採取した中での最小値。
current カレント値
upperBound 上限値
lowerBound 下限値

 

Statsインタフェース

Statsインタフェースおよびそのサブインタフェースは、おのおの指定されたMOのためのパフォーマンスデータのアクセサを規定します。各Statsインタフェースは提供するパフォーマンスデータを適切なStatisticインタフェースとして提供します。J2EE Managementとして以下のインタフェースが規定されています。なおWebOTXでは以下に加え独自の統計情報を取得するためのStasインタフェースを拡張しています。拡張したインタフェースについては「運用編（モニタリング）」を参照してください。

 

イベント

J2EEMangementではイベント通知の実装についてはJMXのNotificationモデルで実装することを規定しています。WebOTXでもJMXおよびJMX Remote APIのNotificationモデルをサポートします。以下にWebOTXが標準的に提供するイベントの概要について示します。

補足:J2EE仕様ではMOの種別を表すプロパティとしてj2eeTypeを用いますが、WebOTXの提供する一部はtpyeプロパティを用いています。

 

2.3.システム管理ツール

WebOTXではアプリケーション実行環境を運用操作するための次のツールを提供しています。これらのツール群を利用することでリモートの運用コンソールより複数の実行環境(Webサーバ,APサーバ)の統合的な運用ができます。

システム管理ツールの詳細については「運用編(統合運用管理ツール)」を参照してください。

 

2.3.1.統合運用管理ツール

GUIにより複数のサーバに分散した運用操作が行えます。

 

2.3.2.Web版統合運用管理コンソール

Flash を利用したブラウザベースの GUI により、分散した複数のサーバの運用操作が一箇所で行なえます。

（セキュリティ上の配慮から、統合運用管理ツールに比べていくつか機能の制限があります）

 

2.3.3.運用管理コマンド

コマンドベースでコマンドライン上から運用操作が行えます。運用管理コマンドでは全ての運用操作を行うことができます。

 

2.3.4.運用管理API

プログラミングにより、独自の統合運用管理ツールを作成することができます。標準のJMXおよびJMX Remote APIを利用してプログラミングすることが可能です。

 

2.4.WebOTX Model MBean

model MBeanはJMX仕様で規定されているMBeanであり、WebOTXではこのModelMBeanを独自に機能強化しています。WebOTX Model MBeanの機能と特長について説明します。

 

2.4.1.ポリシー

model MBeanはリソース管理を容易に行えるようにするためさまざまなポリシーが規定されています。以下にmodel MBeanで規定されているポリシーについて説明します。

なお以下に説明するポリシーのフィールドについてはWebOTX側で適切な値を設定しています。利用者がその値を変更することはできません。

Notificationポリシー

model MBeanは提供する属性に対して更新 (SetAttribute/SetAttributesメソッドが実行された) があった場合、属性変更通知 (jmx.attribute.change) を通知する実装がなされています。

 

Notificationロギングポリシー

MBeanで発生した全てのNotification通知をログファイルに記録する仕組みを実装しています。ログ採取の有無やログファイル名を設定します。

なおWebOTXで提供するMBeanについてはNotificationロギングポリシーフィールドを設定しません。

フィールド名 型 概要

Log

boolean

ロギングを行うかどうか

logFile

String

ログファイル名

 

Persistenceポリシー

MBeanのコンフィグレーション情報などを永続的に扱うために、model MBeanではファイルなど外部リソースに属性の値を格納するインタフェースをサポートしています。永続化をサポートしない場合、MBeanの属性値は一時的なものになり、システムの再起動などを行った場合、設定された値はリセットされます。WebOTXでは永続化が必要なものについてはMBean毎にxmlファイルとして永続化する実装を行っています。

また、永続化するタイミングについて以下に示すポリシーをPersistPolicyフィールドに設定します。これらはMBeanの属性の特性に応じて設定します。

フィールド名 型 概要

persistPorlicy

String

PersistPolicyの値以下うちいずれか

Never,OnTimer,OnUpdate,NoMoreOftenThan

persistLocation

String

永続情報を格納するディレクトリ名

persistName

String

永続情報を格納するファイル名

persistPeriod

int

persistPolicyフィールドの値がOnTimerまたはNoMoreOftenThanである場合のみ、有効です。OnTimerについては、その属性はその値が最初に設定する時に始まる各persistPeriodの最初の部分で格納されます。NoMoreOftenThanについては、前回の格納以来persistPeriodが経過していない場合を除いては、それが更新されるごとに、属性は格納されます。

 

Cacheポリシー

MBeanでは属性もしくはオペレーションの戻り値に対して、キャッシュポリシーとともにデータのキャッシュ値および既定値を保持しています。運用管理クライアントから、属性値の取得要求があった場合、キャッシュポリシーに従い保持しているキャッシュ値が有効であると判断した場合、リソースに対してデータ取得要求を行わず、キャッシュ値を返却する仕組みを実装しています。リソースとの直接のやりとりが行われないため、実行時のアプリケーションリソースと性能の管理活動のインパクトを最小限にすることができます。

MBeanの属性単位で、秒単位で表現されるcurrencyTimeLimitフィールド(キャッシュ値の有効期限)とlastUpdatedTimeStampフィールド (前回更新時刻) が設定でき、運用管理クライアントから属性取得要求があった時刻がlastUpdateTimeStamp+currencyTimeLimitを過ぎている場合、属性値は無効と判断され、過ぎていない場合有効と判断されます。有効と判断された場合は即座にキャッシュ値を返却し、無効と判断された場合はgetMethodフィールドで設定されたgetterメソッドを呼び出してリソースに対して属性値取得要求を行います。getMethodフィールドでgetterメソッドが定義されていない場合、常にdefaultフィールドで設定された既定値が返されます。

フィールド名 型 概要

currencyTimeLimit

int

valueがセットされるときから最新であり古くない秒単位の期間。valueがcurrentの場合、保存された値は返され、getMethod(もし定義されれば)は起動されません。currencyTimeLimitが0である場合、値はすべてのリクエストのために検索されなければなりません。currencyTimeLimitが-1である場合、値は古くなりません。

default

String

valueがセットされず、getMethodが定義されない場合、返されることになっている値です。

getMethod

String

属性の値を検索するために使用されるオペレーション・ディスクリプタからのオペレーション名。返されたオブジェクトは、valueフィールドで保存されます。

lastUpdatedTimeStamp

int

valueフィールドが最後に更新された時のタイムスタンプ。

setMethod

String

管理されたリソースの中で属性の値をセットするために使用されるオペレーション・ディスクリプタからのオペレーション名。新しい値もvalueフィールドで保存されます。

value

String

もしセットされていれば、このフィールドの値は属性の現在値を表わすオブジェクトです。これはcurrencyTimeLimitが古くなっていない場合、返される属性のキャッシュされた値です。

 

Protocol Mapポリシー

MBeanのデフォルト動作とAPIはほとんどのアプリケーションの管理ニーズを満たすことになっています。しかしながらmodel MBeanは複雑なりソース管理のシナリオも提供します。model MBean APIはアプリケーションのMBeanの属性とMIBやCIMオブジェクトのような既存マネージメントデータモデルとのマッピングをProtocolMapフィールドの定義に従って行うことができます。

例えばMIB generatorはJMXエージェントと相互に作用し、SNMP管理システムによってロードされたMIBファイルを作成します。作成したMIBファイルはJMXエージェントによって知られているresource情報を表現します。

なおWebOTXで提供するMBeanについてはProtocolMapフィールドを設定しません。

フィールド名 型 概要

protocolMap

String

このフィールドの値はディスクリプタ・オブジェクトでなければなりません。プロトコル名とマップされたプロトコル値のペアのセットを含んでいます。これは、特別のプロトコル用に属性が特別の識別子(CIMスキーマ、SNMP MIB Oidなど)に関係していることを可能にします。このディスクリプタは管理されたリソースによってセットされ、管理アプリケーションにこの属性を表わすためにヒントとしてアダプタによって使用されるべきです。

 

Export ポリシー

JMXエージェントがマルチ環境で動作する場合、各JMX エージェントは適切なディレクトリかルックアップサービスで存在および有効性を公示することが運用管理を容易にする。JMXでは MBeanが現在どのJMX エージェントに登録されているかを、他のJMXエージェントからも位置を確定できるようするしくみを提供している。このようにディレクトリおよびルックアップサービスによりMBeanの位置を公示する場合は、Exportフィールドを定義するようになっています。

なおWebOTXで提供するMBeanについてはExportフィールドを設定ません。

フィールド名 型 概要

export

String

その値はシリアライズ可能でMBeanの位置を確定できるようにするのに必要な情報を含んでいるすべてのオブジェクトでありえます。nullは、MBeanが他のJMX agentに公開されてはならないことを示します。定義された値は、MBeanが他のJMX agentに公開されるべきでありさらに、JMX agentアドレスが未知の場合、検出可能であるべきであることを示します。MBeansとMBeanサーバのexportがサポートされない場合、このフィールドが無視されます。

 

Visibility ポリシー

運用管理を行うにあたって、運用管理クライアントをGUIで提供することは必要であるが、多種多様なMBeanの属性やオペレーションをどのように見せるかについてポリシーを規定しています。

例えば、エンタープライズマネージャは全ての情報を見て、より高いレベルの管理オブジェクトと対話したいと思うかもしれません。ドメインマネージャは、一般にアプリケーションの内容だけを見たいと思うでしょう。JMXではこのようにユーザの関心度に対応したクライアントビューを見せる仕組みを提供しています。

VisibilityフィールドはMBean、属性あるいはオペレーション単位に1～4の整数で設定します。最大は1で、ユーザの関心度が最も高いことを示しています。最小は4であまり重要性のない、特別の場合だけ必要な情報であることを意味しています。なおJMX仕様はこれら1-4のレベルを厳密に定義していません。MBean作成者に定義を委ねています。WebOTXの統合運用管理ツールでは通常ユーザではVisibilityが1のものしか表示しません。

フィールド名 型 概要

visibility

int
(1-4)

MBeanのために細分性のレベルを示す1～4の整数です。1は、大きく分け、最もしばしば見られるMBeansのためにあります。4は最も小さく、恐らく見られる度合いが最も少ないMBeansです。この値はアダプタあるいは管理アプリケーションによって使用されます。

 

Presentation ポリシー

PresentationStringフィールドは任意のディスクリプタに定義することができる文字列です。この文字列はコンソールに関するヒントを提供するための、XMLにフォーマットされた文字列であると規定されています。しかしながJMX 1.2ではプレゼンテーションフィールドの標準のセットはまだ定義されておらず、WebOTXでもPresentationStringについては何も設定しません。

フィールド名 型 概要

presentationString

String

どのように属性を示さなければならないか説明するXMLにコード化された文字列です。

2.4.2.MBeanのタイプ

MBeanは以下に示すタイプで分類され、そのMBeanの持つObjectNameのcategoryプロパティでその識別を行います。以下にWebOTXで提供するMBeanのタイプについて説明します。

コンフィグMBean(category=config)

ドメインに関する構成情報を格納します。設定値は全てドメイン構成情報ファイル(domain.xml)に格納されます。

ランタイムMBean(category=runtime)

各サービスやリソースに対応したMBeanで、J2EE Management仕様で規定されたMOとして実装しています。サービスやリソースに対する設定やオペレーションが行えます。

「2.6管理対象リソース・サービス」に記述しているMBeanが該当します。

モニターMBean(category=monitor)

パフォーマンス情報を管理するStatsHolderMBeanやモニタリングを行なうMonitorMBeanが該当します。管理対象リソースのパフォーマンス情報を取得するgetterメソッドおよび子モニターMBeanの一覧を取得するオペレーションを提供します。「運用編（モニタリング）」に記述しているMBeanが該当します。

 

2.4.3.dottedname(CLIName)

ObjectNameはMOを一意に識別するための識別子として用いますが、MO間の親子関係を簡潔に示すためにCLINameという識別子も定義されています。ObjectNameとCLINameは1対1でマッピングされているます。WebOTXではこのCLINameを統合運用管理ツールのツリー表示や運用管理コマンドでMOを指定する識別名として利用しています。

[フォーマット]

CLINameはルートから区切り文字’.’で親MOのNameプロパティの値で連結したものです。例えば上記れいにもあるObjectName “domain1:j2eeType=J2EEApplication,name=AccountsController,J2EEServer=server”のCLINameは

“server.applications.j2ee-application.AccountsController”

と表されます。

なお先頭に現れるルート識別子について以下に説明します。

domain ドメインのMOが該当します。

server名

(通常”server”となっている)

J2EEサーバで管理しているコンフィグMBeanを示しています。配備されたアプリケーション、登録されているリソース、動作するサービスなどのMOが該当します。

tpsystem

アプリケーショングループやプロセスグループなどStandard/Enterprise　EditionにおけるTPモニタ関連のMOが該当します。

applications

Standard/Enterprise　Editionでプロセスグループに配備したアプリケーションおよび共有コンポーネントのMOが該当します。

なおdottednameについては運用管理コマンド(otxadmin)のlistコマンドで一覧を確認でき、getコマンドやsetコマンドで属性値の取得/変更が可能です。なお具体的な運用管理コマンドについての説明は「運用編(統合運用管理ツール)」を参照してください。

 

 

2.5.管理対象リソース・サービス

WebOTXでは全てのリソースやサービスをJ2EE Managemantで規定されるManaged Object(JMX仕様ではMBean)として提供しています。これにより、運用管理操作は全てJMXインタフェースで行なうことが出来ます。なお提供するMBeanについては「運用編　MO定義リファレンス」を参照ください。

 

 

2.6.JMX Remoteプロトコルについて

WebOTXでは、JMX Remote APIの通信プロトコルとしてJMXMP (JMX Messaging Protocol)、JRMP(Java Remote Method Protocol)をサポートしています。以下にJMXMPプロトコルについて説明します。なおJMX Remote APIを利用する場合には、プロファイル情報をサーバ／クライアントで一致させる必要があります。

 

2.6.1.使用するプロファイル情報

WebOTXで利用しているJMX Remote APIのプロファイル情報は以下の通りです。

プロパティ 説明

jmx.remote.profiles

"TLS SASL/PLAIN"

jmx.remote.tls.socket.factory

(証明書の情報から作成したSSLScocketFactoryオブジェクト)

jmx.remote.tls.enabled.protocols

"TLSv1"

jmx.remote.tls.enabled.cipher.suites

"SSL_RSA_WITH_NULL_MD5"

jmx.remote.sasl.callback.handler

(クライアント)

new com.nec.webotx.enterprise.admin.jmx.remote.

client.UserPasswordCallbackHandler(user, password))

(サーバ)

new com.nec.webotx.enterprise.admin.jmx.remote.

    server.PropertiesFileCallbackHandler

(“${INSTANCE_ROOT}/config/keyfile”)

Callback関数は、wosv-rt.jarで提供されています。