目次


Maximo シリーズ

Part 10 – クラスター構成

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Maximo シリーズ

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Maximo シリーズ

このシリーズの続きに乞うご期待。

はじめに

TPAE は標準的な Java EE アーキテクチャーにより構成された Web アプリケーションで、WebSphere Application Server (以下 WAS) および Oracle WebLogic Server をサポートしています。このため、TPAE は、大量のユーザー・アクセス、クーロン・タスクによる内部処理、大規模なデータ連携などの高い負荷に対し、アプリケーション・サーバーのクラスター構成によるスケールアウトで、柔軟に対応することができます。本稿は TPAE のクラスター構成について解説します。

クラスターとは

クラスターとは、同じ機能を処理する複数のアプリケーション・サーバーをグループ化したもので、クラスターに属する各アプリケーション・サーバーをメンバーと呼びます。TPAE のアプリケーション・サーバーの場合、4 つの機能 (ユーザー・インターフェース、クーロン・タスク、統合フレームワーク、BIRT レポート) ごとにクラスターを構成することにより、各クラスターを独立して稼動させることができます。TPAE のアプリケーション・サーバーをクラスター化することにより、一般的な Java EE による Web アプリケーションの場合と同様に、以下のような効果が期待できます。

パフォーマンスの改善

Maximo や ICD にアクセスするユーザーがストレスなくアプリケーションを使用できるよう、UI 操作への応答は十分な速さが求められます。TPAE を単一アプリケーション・サーバー構成とすると、ユーザー・アクセス数が増えるのにともない、パフォーマンスが低下することが考えられます。このような場合、ユーザー・インターフェース用のクラスターを構成し、メンバーを増やすことで、より多くのユーザー・アクセスに対し、速い応答を実現することができます。外部システムとのデータ連携処理や TPAE の内部処理についても同様で、処理負荷が増えるのにともない、パフォーマンスが低下することが考えられます。このような場合にも、それぞれの機能ごとにクラスターを構成し、メンバーを増やして並行処理することにより、大量処理への対応を実現することができます。

可用性の向上

機能ごとにクラスターを分けることにより、障害の影響を最小限にすることができます。例えば、クーロン・タスクを実行しているクラスターで障害が発生しても、ユーザー・インターフェースのクラスターには影響がなく、ユーザーはアプリケーションを使用し続けることができます。

各クラスターのメンバーを増やして冗長化することにより、可用性の向上にも効果があります。例えば、ユーザー・インターフェースのクラスターに属している一つのアプリケーション・サーバーに障害が発生したとしても、別のアプリケーション・サーバーにアクセスし直すことで、継続してアプリケーションを使用することができます。

運用の効率化

クラスター構成により、アプリケーション・サーバーごとではなく、クラスター単位で導入や設定などの運用作業を実施することができます。

また、運用環境の変化に応じて、柔軟な性能向上が求められることがあります。このような場合にも、クラスターのメンバーを簡単に増やすことができるため、柔軟に対応することができます。

TPAE システム概要

製品コンポーネント

TPAE をベースとした Maximo および ICD を使用するには、ミドルウェアと呼ばれる複数のソフトウェアを必要とします。これらのミドルウェア・コンポーネントはシステムの規模に応じて単一もしくは複数の物理サーバー上で実行することができます。Maximo もしくは ICD インストール環境で使用されるコンポーネントの構成、各コンポーネントの説明は以下の通りです。

図 1. コンポーネントの構成
表 1. 各コンポーネントの説明
コンポーネント説明
データベース・サーバー資産やロケーション、作業指示書などの業務データだけでなく、Web ブラウザー上から行ったコンフィグレーションやテーラリングの内容がすべて保管されています。
アプリケーション・サーバーMBO (Maximo Business Object)、プレゼンテーション XML、Bean クラスの処理が実行されます。詳細については、Maximo シリーズ: Part 2 - Maximo フレームワーク概説を参照してください。
HTTP サーバー一般的な Web アプリケーションの構成と同様に、HTTP サーバーをアプリケーション・サーバーと連携して使用することができます。
Web ブラウザーMaximo および ICD のすべてのアプリケーションは Web ブラウザーから使用します。
管理ワークステーションMaximo もしくは ICD のインストールに使用され、指定したインストール・フォルダー内にデプロイメントに必要となるファイル (すべてのクラス・ファイル、EAR ファイル、プロパティー・ファイル、インストール・ツールなど) が格納されます。インストール後は、管理ワークステーションを使用して構成の更新もしくは変更を行います。
ディレクトリー・サーバーIBM Tivoli Directory Server (TDS)、Lightweight Directory Access Protocol (LDAP) などのディレクトリー・サーバーを構成して、アプリケーション・サーバーのユーザー管理や認証に使用することができます。

アプリケーション・モデル

TPAE は、一般的な Java EE の Web アプリケーションと同様に、クライアント層、Web 層、ビジネス層、EIS (Enterprise Information System) 層から構成されています。このうち、Web 層とビジネス層では TPAE のアプリケーション・サーバーが稼動し、EIS 層にある TPAE データベースにデータが格納されます。

図 2. アプリケーション・モデル

このような分散多階層アプリケーション・モデルを採用し、各階層の相互依存を抑えることで、変更容易性や拡張性を高めています。大規模な TPAE のシステム構成を設計する際、各層ごとに検討することができるようになっています。表 2 に各層ごとの検討内容をまとめています。

表 2. 各層ごとの検討内容
検討内容
EIS 層DB2、Oracle Database、SQL Server をサポートしています。TPAE のデータベースは、管理対象データの容量および処理量、冗長構成の必要性に応じて構成します。システム構成の設計については、一般的なデータベースの設計と変わりません。
アプリケーション・サーバー
(Web 層+ビジネス層)
WebSphere Application Server、Oracle WebLogic Server をサポートしています。TPAE のアプリケーション・サーバーは、Java 仮想マシン (JVM) 上で動作するため、サーバーの物理的な台数やリソースを増やし、稼動する JVM 数を増やすことで、負荷分散することができます。また、TPAE は複数の機能に分けることができ、機能ごとに JVM を稼動することができるため、機能ごとにクラスターを分けて構成することができます。
クライアント層Firefox および Internet Explorer をサポートしています。TPAE 7.6 以降は、Chrome および Safari もサポートされています。アプリケーション・サーバーのシステム構成を設計する際、同時にアクセスするブラウザー数を同時セッション数として見積もる必要があります。

TPAE の機能

TPAE の機能分類は、Maximo シリーズ: Part 1 - Maximo Basic で紹介していますが、ここでは、アプリケーション・サーバーのクラスター構成を考えるため、TPAE をシステム視点で見ます。そうすると、TPAE は MBO (Maximo Business Object) をベースとして、4 つの機能 (ユーザー・インターフェース、統合フレームワーク、クーロン・タスク、BIRT レポート) に分けて考えることができます。

図 3. TPAE の機能

各機能の詳細は以下の通りです。

ユーザー・インターフェース機能

Web ブラウザーからアクセスし、Maximo のアプリケーションを使用するための機能です。アーキテクチャーについての詳しい説明は、Maximo シリーズ: Part 2 - Maximo フレームワーク概説を参照してください。

統合フレームワーク機能

TPAE と外部システム間でリアルタイムもしくはバッチでのデータ同期および統合を行うためのシステム連携機能です。統合フレームワーク機能には、システム連携のデータ構造定義を行うオブジェクト構造、データ受信を行うサービス、データ送信を行うチャネルが含まれています。

クーロン・タスク機能

TPAE 内でスケジュールされたジョブを処理する機能です。統合フレームワークやレポートに関係したタスク、各アプリケーション特有のタスク、エスカレーションを実行するタスクがあります。

BIRT レポート機能

BIRT レポートを出力する機能です。TPAE には BIRT エンジンが組み込まれており、レポート処理に使用されています。BIRT レポート機能は業務データを読み込んでレポートを出力するだけなので、業務データを更新することはありません。BIRT レポートの詳しい説明は、Maximo シリーズ: Part 5 - Maximo BIRT Reporting を参照してください。

TPAE 7.5 以降、Cognos BI によるレポート機能もサポートしています。また、Maximo 7.6 では Cognos BI がバンドルされています。システムとしては TPAE に含まれず、Cognos BI 専用のサーバーを構築する必要があります。

システム構成

TPAE のシステム構成は、一般的な Java EE ベースの Web アプリケーションと同じように、階層ごとに分けて検討することができます。アプリケーション・サーバーについては、一般的なクラスター構成を検討するのに加え、JVM 単位で有効な機能を設定できるため、機能の異なる複数クラスター構成、JVM 単位の機能分担も検討する必要があります。

TPAE のアプリケーション・サーバーはすべての機能を持っており、設定により JVM ごとにアクティブな機能を切り替えることができます。TPAE のアプリケーション・サーバーをいくつの JVM で構成するかに関わらず、全体として 4 つの機能をカバーし、お互いに干渉しないように構成する必要があります。

以下、TPAE のアプリケーション・サーバーを中心に、基本構成およびクラスター構成の概要について説明します。

基本構成

基本構成は、TPAE のアプリケーション・サーバーを 1 つの JVM で構成します。統合フレームワークでキューを使った非同期のシステム連携を行う場合、JMS キューを構成する必要があります。

図 4. TPAE の基本構成

基本構成は、教育、開発や保守といった用途、ユーザー負荷の少ない本番環境に使用します。基本構成に適した負荷の目安は、Maximo Asset Management V7.6 マニュアルサイトの基本システム構成に、ユーザー負荷で同時 50 セッションと記載されています。

この目安を超えるユーザー負荷に対しては、セッション数に応じて稼動 JVM 数を増やすというスケールアウトで対応することができます。システム連携、クーロン・タスクやレポートの負荷は実装に依存する割合が高い上、インフラ全般の影響を受ける可能性があることからMaximo Asset Management V7.6 マニュアルサイトに明確な目安は記載されていません。システム連携、クーロン・タスクやレポートに関する基本構成に適した負荷の目安は、本番と似た物理環境を使用して実測して決定ことをお勧めします。また、この目安を超える負荷に対しては、ユーザー負荷の場合と同様に、スケールアウトで対応することができます。

クラスター構成

前述したように、処理負荷が高い TPAE の大規模システムでは、稼動 JVM 数を増やすというスケールアウトで対応することができます。4 つの機能 (ユーザー・インターフェース、統合フレームワーク、クーロン・タスク、BIRT レポート) ごとに処理負荷を見積もり、アプリケーション・サーバーの JVM 数を検討します。すべての機能の処理負荷が高い場合、ユーザー・インターフェース (UI)、統合フレームワーク (MIF)、クーロン・タスク (CRON) および BIRT レポート専用 (BROS) の 4 クラスターに分け、それぞれ複数の JVM によって構成することができます。

図 5. TPAE のクラスター構成

各クラスターの詳細は以下の通りです。

ユーザー・インターフェース・クラスター (UI クラスター)

ユーザー・インターフェース機能を持ったクラスターです。直接もしくは HTTP サーバーや負荷分散装置 (ロードバランサー) を経由してエンド・ユーザーにアプリケーションを提供します。

統合フレームワーク・クラスター (MIF クラスター)

統合フレームワーク機能を持ったクラスターです。Web サービス (SOAP) や REST API、ファイル、データベースのテーブル、JMS キューなどシステム連携インターフェースを持っています。非同期処理にも対応しており、必要に応じてキューを構成する必要があります。

クーロン・タスク・クラスター (CRON クラスター)

クーロン・タスク機能を持ったクラスターです。通常、統合フレームワーク機能に関連したクーロン・タスクを除き、すべてのクーロン・タスクを実行するよう設定します。

BIRT レポート専用クラスター (BROS クラスター)

BIRT レポート機能を持ったクラスターです。BIRT レポートのみを実行するよう設定します。BIRT レポート処理のみ実行するサーバーが BIRT Report Only Server (BROS) と呼ばれることから、BIRT レポート専用クラスターは BROS クラスターとも呼ばれます。レポート処理によるデータベースへの負荷が大きい場合、TPAE のデータベースを定期的に複製し、レポート専用データベースを構成します。

機能分離

4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成のデプロイ方法は、Maximo Asset Management V7.6 マニュアルサイトのクラスター・システムの構成に詳細な手順が記載されています。また、Maximo 7.6 ではインストーラーおよび構成ツールを使うことで、簡単にクラスター構成がデプロイできるようになっています。ここでは、この手順により、どのように機能分離されているのかを説明します。

TPAE の機能は、クラスターもしくは JVM ごとに分離することができます。TPAE の機能分離に関連する設定は、システム・プロパティーおよび Web モジュールの構成情報があります。システム・プロパティーは、TAPE の EAR ファイルに含まれる maximo.propeties ファイルや「システムのプロパティー」アプリケーションから設定することができます。また、JVM ごとにアプリケーション名を付与する場合、JVM の起動オプションからシステム・プロパティーを設定することもできます。Web モジュールの構成情報は、TAPE の EAR ファイルに含まれる web.xml、ejb-jar.xml などで設定できます。

プロパティー値の分離

システム・プロパティーは、maximo.propeties ファイルや「システムのプロパティー」アプリケーションから設定することができます。

maximo.properties による設定では、TAPE の EAR ファイルに含まれる maximo.propeties ファイル内でプロパティー値を設定するので、EAR ファイル単位でのプロパティー値を分離することができます。通常、クラスターごとに EAR ファイルを作成するので、EAR ファイルのビルド前に、maximo.properties ファイル内でプロパティー値を設定することにより、クラスター単位で機能分離することができます。

「システムのプロパティー」アプリケーションによる設定では、「インスタンス・プロパティー」テーブルでサーバー名ごとにプロパティー値を設定することができます。

図 6. インスタンス・プロパティー

「インスタンス・プロパティー」テーブルでクラスターもしくは JVM ごとにプロパティー値を設定するためには、予めサーバー名を付与しておく必要があります。クラスターもしくは JVM ごとにサーバー名を付与するには、mxe.name というプロパティーを設定します。以下、クラスターもしくは JVM 単位でのサーバー名の付け方を示します。

  • クラスター単位

クラスターごとにサーバー名を分離する場合、デプロイする EAR ファイルに含まれる maximo.properties ファイル内でサーバー名を設定します。下記の maximo.properties の設定例のように、”mxe.name=<サーバー名>” とすることでサーバー名 *2 を設定することができます。

図 7. サーバー名の設定 (maximo.properties)

Maximo 7.6 ではインストーラーおよび構成ツールが新しくなり、Tivoli Process Automation Suite 構成ツールからクラスター構成のデプロイを行うと、クラスター単位でサーバー名が設定されてデプロイされます。サーバー名は各クラスターのアプリケーション名が設定されます。

図 8. アプリケーション・サーバーの構成
  • JVM 単位

JVM ごとにサーバー名を分離する場合、JVM の起動オプションでサーバー名を設定します。下記の起動オプションの設定例のように、”-Dmxe.name=<サーバー名>” により設定することができます。

図 9. 起動オプションの設定例

クーロン・タスクの分離

各クラスターの機能に応じて、クラスターもしくは JVM ごとに稼動するクーロン・タスクを分離する必要があります。稼動するクーロン・タスクは、システム・プロパティーで設定することができます。クーロン・タスクの設定を行うプロパティーは、以下の通りです。

表 3. クーロン・タスクの実行許可に関するプロパティー
プロパティー説明
mxe.crontask.donotrun実行しないクーロン・タスクを指定するために使用します。特定のクーロン・タスクを実行させない場合、クーロン・タスクやクーロン・タスクのインスタンス (<クーロン・タスク名>.<インスタンス名>のような形式) を設定します。すべてのクーロン・タスクを実行しない場合、”ALL” を設定します。
mxe.crontask.dorun
(Maximo 7.6 新機能)
Maximo 7.6 で追加されたプロパティーです。実行するクーロン・タスクを指定するために使用します。”mxe.crontask.donotrun” の設定と論理矛盾が発生しないようにするため、”mxe.crontask.donotrun=ALL” を設定した上で、クーロン・タスクやクーロン・タスクのインスタンスを設定して使用します。

複数の JVM に対して、同一のクーロン・タスクやクーロン・タスクのインスタンスの実行が許可されている場合、許可された JVM の中から実行する JVM が自動で選択されます。TPAE 7.5 以前、最初に選択された JVM による実行が優先されていました。このため、適切に負荷分散されないケースが考えられ、JVM 単位で明示的に実行許可の設定を行うことがありました。TPAE 7.6 以降、実行許可された JVM 間でクーロン・タスクの負荷分散が行われるようになり、負荷分散を目的とした JVM 単位での実行許可の設定は必要なくなりました。

4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成の場合、UI クラスターで JMS 連続キュー・コンシューマーを実行し、それ以外のクーロン・タスクを CRON クラスターで実行させる設定が一般的です。

メッセージ駆動型 Bean (MDB) の有効化

継続中のキューは、メッセージ取り込み処理を並行化し、パフォーマンスを向上させるために使用される JMS キューです。メッセージ駆動型 Bean (MDB) は継続中のキューのコンシューマーとして動作し、メッセージの取り込み処理を行います。このため、継続中のキューのコンシューマーは MDB が構成されている JVM でのみ動作します。

MDB の構成は、TAPE の EAR ファイルに含まれる EJB の設定情報ファイルにより設定します。EJB の設定情報ファイルは EAR ファイルに含まれるため、クラスターごとに設定を変えることができます。クラスターで継続中のキューのコンシューマーを動作させる場合、ejb-jar.xml 内で必要となる 4 つの MDB (MessageDriven_JMSContQueueProcessor_1、MessageDriven_JMSContQueueProcessor_2、JMSContQueueProcessor-1、JMSContQueueProcessor-2) に関連設定をアンコメントして有効化します。また、ibm-ejb-jar-bnd.xmi (WebSphare Application Server の場合) もしくは weblogic-ejb-jar.xml (WebLogic Server の場合) でアプリケーション・サーバーに使用する製品固有の設定が必要となります。以下、MDB を有効化した設定の例です。以下、MDB を有効化した設定の例です。

  • MDB 有効化設定 (ejb-jar.xml)

MDB を有効化する場合、4 つの MDB (MessageDriven_JMSContQueueProcessor_1、MessageDriven_JMSContQueueProcessor_2、JMSContQueueProcessor-1、JMSContQueueProcessor-2) を設定します。

MDB 有効化した ejb-jar.xml の例
<!-- MEA MDB -->

    <message-driven id="MessageDriven_JMSContQueueProcessor_1">
      <ejb-name>JMSContQueueProcessor-1</ejb-name>
      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>
      <transaction-type>Container</transaction-type>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <env-entry>
        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>
	<env-entry-type>java.lang.String </env-entry-type>
	<env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>
      </env-entry> 
    </message-driven>


<!-- MEA MDB for error queue -->

    <message-driven id="MessageDriven_JMSContQueueProcessor_2">
      <ejb-name>JMSContQueueProcessor-2</ejb-name>
      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>
      <transaction-type>Container</transaction-type>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <env-entry>
        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>
	<env-entry-type>java.lang.String </env-entry-type>
	<env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>
      </env-entry> 
      <env-entry>
        <env-entry-name>MDBDELAY</env-entry-name>
	<env-entry-type>java.lang.Long </env-entry-type>
	<env-entry-value>30000</env-entry-value>
      </env-entry>      
      <env-entry>
        <env-entry-name>ERRORQUEUE</env-entry-name>
	<env-entry-type>java.lang.String </env-entry-type>
	<env-entry-value>1</env-entry-value>
      </env-entry>      
      
    </message-driven>


<!-- MEA MDB -->

    <container-transaction>
    	<method>
    	   <ejb-name>JMSContQueueProcessor-1</ejb-name>
    	   <method-name>*</method-name>
    	</method>
    
    	<trans-attribute>Required</trans-attribute>
    
    </container-transaction>

<!-- MEA MDB for error queue -->

    <container-transaction>
    	<method>
    	   <ejb-name>JMSContQueueProcessor-2</ejb-name>
    	   <method-name>*</method-name>
    	</method>
    
    	<trans-attribute>Required</trans-attribute>
    
    </container-transaction>
  • (WebSphere Application Server の場合) MDB 有効化設定 (ibm-ejb-jar-bnd.xmi)

WAS で MDB を有効化する場合、2 つの MDB バインディング (ejbbnd:MessageDrivenBeanBinding、ejbbnd:MessageDrivenBeanBinding) を設定します。

MDB 有効化した ibm-ejb-jar-bnd.xmi の例
<!-- MEA MDB -->
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsact">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_1"/>
  </ejbBindings>

<!-- MEA MDB for error queue -->
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsacterr">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_2"/>
  </ejbBindings>

4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成の場合、MIF クラスターで実行させる設定が一般的です。

  • (Oracle WebLogic Server の場合) MDB 有効化設定 (weblogic-ejb-jar.xml)

WebLogic で MDB を有効化する場合、MDB の構成設定を設定します。

MDB 構成設定した weblogic-ejb-jar.xml の例
<!-- MEA MDB -->

  <weblogic-enterprise-bean>
    <ejb-name>JMSContQueueProcessor-1</ejb-name>
    <message-driven-descriptor>
      <pool>		
          <max-beans-in-free-pool>3</max-beans-in-free-pool>	
      </pool>      
      <destination-jndi-name>jms/maximo/int/queues/cqin</destination-jndi-name>
      <connection-factory-jndi-name>jms/maximo/int/cf/intcf</connection-factory-jndi-name>
    </message-driven-descriptor>
    
    <transaction-descriptor>
    
          <trans-timeout-seconds>600</trans-timeout-seconds>
    
    </transaction-descriptor>
    

    <jndi-name>JMSContQueueProcessor-1</jndi-name>
  </weblogic-enterprise-bean>

<!-- MEA MDB for error queue -->

  <weblogic-enterprise-bean>
    <ejb-name>JMSContQueueProcessor-2</ejb-name>
    <message-driven-descriptor>
      <pool>		
          <max-beans-in-free-pool>3</max-beans-in-free-pool>	
      </pool>      
      <destination-jndi-name>jms/maximo/int/queues/cqinerr</destination-jndi-name>
      <connection-factory-jndi-name>jms/maximo/int/cf/intcf</connection-factory-jndi-name>
    </message-driven-descriptor>
    
    <transaction-descriptor>
    
          <trans-timeout-seconds>600</trans-timeout-seconds>
    
    </transaction-descriptor>
    

    <jndi-name>JMSContQueueProcessor-2</jndi-name>
  </weblogic-enterprise-bean>

4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成の場合、MIF クラスターで実行させる設定が一般的です。

BIRT レポート

BIRT レポートにはスケジュール実行と即時実行のレポートがあります。BIRT レポートの実行サーバーを設定するプロパティーは、以下の通りです。

表 4. BIRT レポートの実行許可に関するプロパティー
プロパティー説明
mxe.report.birt.disablequeuemanagerBIRT レポートをスケジュール実行するサーバーを指定することができます。スケジュール実行レポートのキュー・マネージャーを無効にする (値を 1 に設定する) と、スケジュール実行レポートは処理されません。
mxe.report.birt.reportserverBIRT レポートを即時実行するサーバーを指定することができます。BIRT Viewer を実行するサーバーの URL を設定すると、即時実行レポートが指定されたサーバーで実行されます。

4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成の場合、BROS クラスターで BIRT レポートを実行させる設定が一般的です。

機能分離のまとめ

複数の機能に分けてクラスターを構成する場合、検討が必要となる設定項目をまとめると以下の通りとなります。

表 5. クラスター構成に関する設定項目一覧
項目設定箇所
サーバー名mxe.name プロパティー
実行クーロンmxe.crontask.donotrun プロパティー
TPAE 7.6 以降、mxe.crontask.donrun プロパティー
スケジュール実行レポートmxe.report.birt.disablequeuemanager プロパティー
BIRT Viewer URLmxe.report.birt.reportserver プロパティー
継続中のキュー用 MDBejb-jar.xml の MDB 関連セクション
製品別 MDB 設定(WebSphere Application Server の場合) ibm-ejb-jar-bnd.xmi の MDB 関連セクション
(WebLogic Server の場合) weblogic-ejb-jar.xml の MDB 関連セクション

Maximo Asset Management V7.6 マニュアルサイトのクラスター・システムの構成には、4 つのクラスター (UI、MIF、CRON、BROS) を持った TPAE の標準的なクラスター構成をデプロイする方法が記載されており、設定をまとめると以下のようになります。

表 6. 「クラスター・システムの構成」で使用されている設定一覧
設定UIMIFCRONBROS
mxe.crontask.donotrunALLJMSQSEQCONSUMER 以外すべてJMSQSEQCONSUMERALL
mxe.report.birt.disablequeuemanager1110
mxe.report.birt.reportserverBROS の URL不要不要不要
ejb-jar.xml の MDB 関連セクションコメントアウトアンコメントコメントアウトコメントアウト
ibm-ejb-jar-bnd.xmi / weblogic-ejb-jar.xml の MDB 関連セクションコメントアウトアンコメントコメントアウトコメントアウト

考慮点

共有ディレクトリー

TPAE の大規模なクラスター構成では、複数の物理サーバー上で JVM を稼動させることが多いと考えられます。このとき、いくつかの設定に関連し、共有ディレクトリーについて検討する必要があります。

図 10. 共有ディスクを含む物理構成の概要
  • 統合グローバル・ディレクトリー

TPAE 7.5 以前の環境では、統合グローバル・ディレクトリーは、メッセージ再処理のエラーXML メッセージ、XML スキーマ、Web サービス用の WSDL ファイルなど統合フレームワークに関連したファイルの出力、読み取りに使用されていました。統合グローバル・ディレクトリーで管理されるファイルは、TPAE のアプリケーション・サーバー全体で同一である必要があります。このため、複数の物理サーバー上で TPAE の JVM を稼動する場合、すべての JVM から統合グローバル・ディレクトリーにアクセスできるように共有ディスク上に配置し、同一パスでアクセスできるように構成する必要があります。

TPAE 7.6 以降、TPAE 7.5 以前の環境で統合グローバル・ディレクトリーにファイル形式で保管されていたデータが、データベースに保管できるようになりました。このため、統合フレームワークに関連したファイルを保管するために統合グローバル・ディレクトリーを使用する必要がなくなりました。

  • インポート/エクスポート用ディレクトリー

TPAE の MIF によるファイル連携において、使用するディレクトリーは TPAE 全体で共通となります。インポート用ファイルが置かれるディレクトリー用ファイルが置かれるディレクトリーは、「クーロン・タスクのセットアップ」の「クーロン・タスクのパラメーター」テーブルで設定できます。エクスポート用ファイルが置かれるディレクトリーは「エンドポイント」の「エンドポイントのプロパティー」テーブルで設定できます。

このため、設定されたインポート/エクスポート用ディレクトリーは、ファイルのインポートもしくはエクスポートが実行される可能性があるすべての JVM から同一パスである必要があります。このため、一般的に、複数の物理サーバー上でこれら処理が実行される場合、すべての JVM からソース・ディレクトリーにアクセスできるように共有ディスク上に配置し、同一パスでアクセスできるように共有ディレクトリーを構成します。

UI セッション

TPAE のセッションには、以下の通り、サーバー・セッションと UI セッションという二つの考え方があります。

図 11. サーバー・セッションと UI セッションの概要
表 7. セッションの説明
セッション説明
サーバー・セッションユーザーが TPAE にログインすると、サーバー側には Web ブラウザーとサーバーの間で固有のサーバー・セッションが生成され、クライアント側へセッション・クッキーを渡されます。一つのクライアントから TPAE にアクセスすると、同一のサーバー・セッションが共有されます。
UI セッションWeb ブラウザーの複数ウィンドウもしくはタブで TPAE にアクセスする場合、同一のサーバー・セッションが共有されます。このため、ウィンドウもしくはタブごとに UI セッションを割り当て、個別にステータス管理できるようになっています。

TPAE のクラスター環境において、UI クラスターへのアクセスに分散装置を使用する際、注意が必要となります。あるクライアントから TPAE にログインし、サーバー・セッションが生成されます。その後、異なる JVM にアクセスすると、新たなサーバー・セッションが生成され、クライアントのセッション・クッキーも更新されます。その結果、古いセッション・クッキーが使用できなくなり、古いサーバー・セッションに紐付いた Web ブラウザーのウィンドウもしくはタブからのアクセスはエラーとなってしまいます。

このため、TPAE のクラスター環境において、UI クラスターへのアクセスに分散装置を利用する場合、同一クライアントからのアクセスは、同一 JVM になるよう構成する必要があります。

JMS キュー

TPAE のクラスター構成における JMS キュー構成の考え方は、Maximo Asset Management V7.5.0.5 マニュアルサイトのサーバー・クラスターの JMS キュー*2 にアプリケーション・サーバー製品別に記載されています。マニュアルには、WAS によるクラスター環境において、サービス統合バス (SIBus) の構成について注意点が記載されています。アプリケーション・サーバーとして WAS を使用する場合、SIBus の持つメッセージ・エンジンを並行処理する機能によって、高可用性や高いパフォーマンスを実現できます。しかし、連続キューの場合はキューが処理される順序性を確保するため、SIBus 内にメッセージ・ストアが一つになるよう構成する必要があります。それぞれのキュー用に構成した SIBus の例を以下に示します。

図 12. 継続中のキュー用 SIBus
図 13. 連続キュー用 SIBus

おわりに

本稿では TPAE のクラスター構成の考え方について解説しました。Maximo Asset Management V7.6 マニュアルサイトのクラスター・システムの構成で紹介されている 4 つのクラスター (UI、MIF、CRON、BROS) 構成以外にも、様々なクラスター構成が取れることを理解いただき、TPAE のインフラ設計に生かしてください。

注釈

*1 Take Control of JVM Names for Instance, Cron and Log Names Using -Dmxe.name に記載されている通り、それぞれのサーバーには連番が付けられます。

*2 Maximo Asset Management V7.6 マニュアルサイトのサーバー・クラスターの JMS キューでも説明されていますが、より詳しく記載されている Maximo Asset Management V7.5.0.5 マニュアルサイトのリンクとしています。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1007817
ArticleTitle=Maximo シリーズ: Part 10 – クラスター構成
publish-date=06112015