コンフィギュレーション・ファイルについて

ここでは、次の内容について説明します。

• コンフィギュレーション・ファイルとは

• コンフィギュレーション・ファイルの内容

 

---

コンフィギュレーション・ファイルとは

BEA Tuxedo の各アプリケーションのコンフィギュレーションは、管理者の主要なタスクです。管理者は、コンフィギュレーション・ファイルにパラメータ値を設定して、アプリケーションを記述します。これらのパラメータ値により、実行可能なアプリケーションが作成されます。コンフィギュレーション・ファイルとは、アプリケーションの起動と実行に必要なすべての情報 (アプリケーションのリソース、マシン・グループ、サーバ、および利用可能なサービスなどの仕様) が格納されたファイルです。

テキスト形式とバイナリ形式のコンフィギュレーション・ファイル

コンフィギュレーション・ファイルには、次の 2 つの形式があります。

• UBBCONFIG ファイルは、テキスト形式のコンフィギュレーション・ファイルであり、任意のエディタで作成したり、編集できます。BEA Tuxedo のサンプル・アプリケーションには、コンフィギュレーション・ファイルのサンプルが用意されていますが、UBBCONFIG そのものは用意されていません。UBBCONFIG ファイルは、アプリケーションごとに作成してください。コンフィギュレーション・ファイルのエントリで使用する構文については、『BEA Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) を参照してください。

  注記 BEA Tuxedo ソフトウェアには、bankapp および simpapp アプリケーションの一部として 3 つの UBBCONFIG ファイルのサンプル (ubbshm、ubbmp、ubbsimple) が用意されています(『サンプルを使用した BEA Tuxedo アプリケーションの開発方法』を参照してください)。

• TUXCONFIG ファイルは、バイナリ形式のコンフィギュレーション・ファイルであり、tmloadcf(1) コマンドにより、テキスト形式のファイルから作成されます。tmloadcf を実行する前に、TUXCONFIG をロードするデバイスまたはシステム・ファイルの絶対パス名に環境変数 TUXCONFIG を設定しておく必要があります。TUXCONFIG のパラメータの多くは、必要に応じて、アプリケーションの実行中に tmconfig、wtmconfig(1)、または MIB を使って変更できます。

 

---

コンフィギュレーション・ファイルの内容

次の表は、コンフィギュレーション・ファイルの 9 つのセクションと、各セクションの目的を説明します。

セクション	必須/オプション	説明
RESOURCES	必須	すべてのシステム・パラメータを定義します。
MACHINES	必須	アプリケーションで使用されるすべてのマシンを指定します。
GROUPS	必須	アプリケーション内のすべてのグループ、グループ名、および グループ ID を定義します。
SERVERS	オプション	システム内で起動するサーバの初期条件を指定します。
SERVICES	オプション	アプリケーションで使用されるサービスに関する情報を提供します。
INTERFACES	オプション	CORBA 環境のアプリケーションで使用されるインターフェイスに対し、アプリケーション全体にわたるデフォルト・パラメータに関する情報を指定します。
NETWORK	オプション	LAN 環境のネットワーク設定を記述します。
NETGROUPS	オプション	LAN 環境で使用可能なネットワーク・グループを記述します。
ROUTING	オプション	FML バッファおよび VIEW を使用するサービス要求のデータ依存型ルーティングに関する情報を提供します。

 

コンフィギュレーション・ファイルには、少なくとも 9 つのパラメータが必要です。パラメータは 80 種類あります。最初のセクション以外のすべてのセクションには、複数のエントリを指定でき、各エントリには、独自のパラメータを指定できます。RESOURCES セクション以外のすべてのセクションでは、デフォルト値を使用して、複数のエントリに含まれるパラメータを指定できます。

コマンド行インターフェイスまたは BEA Tuxedo Administration Console を使用して、バイナリ形式のコンフィギュレーション・ファイル (TUXCONFIG) を作成することができます。まず、そのファイルで定義するコンフィギュレーションの種類を決定します。

• 1 台のマシンで構成するアプリケーション―1 つ以上のローカル・クライアントまたはリモート・クライアントが、同じマシン上にある 1 つ以上のサーバと通信します。

• 複数のマシンで構成 (分散) するアプリケーション―1 つ以上のローカル・クライアントまたはリモート・クライアントが、複数のマシン上に分散する 1 つ以上のサーバと通信します。

• 複数のドメインにまたがるアプリケーション―複数のアプリケーションが、BEA Tuxedo の拡張機能である Domains 機能を利用して相互に通信します。このコンフィギュレーションに含まれる各アプリケーションをドメインと呼びます。

 

---

CORBA 環境の管理上の要件とパフォーマンス

この節では、BEA Tuxedo システムで CORBA 環境を適切に管理する方法について説明します。

NameManager の設定

CORBA 環境を適切に管理するには、以下の要件を満たす必要があります。

• NameManager は、BEA Tuxedo のイベント・ブローカを使用して相互にアクティビティを調整し合い、管理者やオペレータの介入が不要でなければなりません。イベント・ブローカは、サーバが NameManager サービスを提供する前に起動しておく必要があります。アプリケーションでイベント・ブローカが設定されていないため、NameManager サービスの起動時にイベント・ブローカが実行されない場合、NameManager は起動処理をアボートし、ユーザ・ログにエラー・メッセージが記録されます。

• 少なくとも 2 つのサーバが、アプリケーションの一部として NameManager サービスを実行するように設定されていなければなりません。これにより、常に「名前 - IOR」マッピングのコピーが使用可能になります。複数のマシン上に複数のサーバが存在し、1 台のマシンがクラッシュした場合、そのマシンとアプリケーションを再起動する際に、新しい NameManager がほかの NameManager からマッピングを取得します。アプリケーションが 1 台のマシン上にのみ存在し、そのマシンがクラッシュした場合は、アプリケーションを再起動しなければならないので、アプリケーションの起動処理の一部として NameManager が再起動されます。NameManager サービスの起動時に、アプリケーションに 2 つの NameManager が設定されていない場合、NameManager は起動処理をアボートし、ユーザ・ログにエラー・メッセージが記録されます。

• NameManager はマスタとスレーブのどちらにも指定できますが、デフォルトはスレーブです。アプリケーションでマスタの NameManager サーバが設定されていないため、スレーブ NameManager サーバの起動時にマスタ NameManager サーバが実行されていない場合、スレーブ・サーバの起動時にサーバ自体が終了し、ユーザ・ログにエラー・メッセージが記録されます。

• FactoryFinder サービスの起動時に、アプリケーションで NameManager サービスが設定されていない場合、FactoryFinder は起動処理をアボートし、ユーザ・ログにエラー・メッセージが記録されます。FactoryFinder は、アプリケーションから “find” 要求を受信した場合のみ NameManager と通信するので、FactoryFinder サービスの前に NameManager サービスを起動する必要はありません。これに対し、NameManager は起動時に相互通信を試みます。FactoryFinder は、リモート・ドメインにあるファクトリの検索要求を受け取らない限り、相互に通信することはありません。

• BEA Tuxedo のイベント・ブローカ、NameManager、および FactoryFinder サービスは、アプリケーション固有のサーバを起動する前に起動しておく必要があります。ただし、アプリケーションに複数のイベント・ブローカが設定されている場合、すべてのセカンダリ・イベント・ブローカは、アプリケーション・サーバがすべて起動された後に起動しなければなりません。アプリケーション・サーバにはこの起動順序を設定するシステム・プロトコルがないので、すべてのセカンダリ・イベント・ブローカをアプリケーション・サーバの後に配置する必要があります。

• アプリケーション・サーバからファクトリ・オブジェクトへのオブジェクト・リファレンスを登録するには、マスタ NameManager を起動し、実行しておく必要があります。スレーブ NameManager を実行しておくだけでは不十分です。

信頼性に関する要件

この節では、CORBA 環境の信頼性を向上させる方法について説明します。

ファクトリ・エントリの管理

アプリケーション・サーバがダウンすると、NameManager に登録されたファクトリを削除できなくなります。また、FactoryFinder が、アクティブではなくなったファクトリのオブジェクト・リファレンスを返す場合もあります。これは、非アクティブになったファクトリを含むサーバが使用不能になった、ファクトリを NameManager から登録解除できない、または、ファクトリ用のインターフェイスを提供するサーバがほかに存在しないことが原因で発生します。

通常、直後にアプリケーション・ファクトリを再起動してファクトリを提供できますが、ファクトリ・エントリがいつまでも残ったままにならないように、アプリケーション・サーバがダウンした場合は NameManager に通知されます。この通知を受信すると、NameManager は現在アクティブなサーバではサポートされていないファクトリ・エントリを削除することができます。

複数の NameManager と FactoryFinder の設定

少なくとも、マスタとスレーブの 2 つの NameManager をアプリケーションで (可能であれば異なるマシンに) 設定し、FactoryFinder で照会機能を実行できるようにします。アプリケーションには、複数の FactoryFinder を設定することも可能です。

マスタ NameManager の指定

マスタ NameManager は、UBBCONFIG ファイルで指定する必要があります。マスタ NameManager には、登録に関するあらゆるアクティビティが送信されます。内容が更新されると、マスタ NameManager からスレーブ NameManager に通知されます。マスタ NameManager がダウンすると、マスタが再起動されるまで、ファクトリの登録と削除はできません。

パフォーマンスに関するヒント

FactoryFinder と NameManager を別々のマシン上で実行するより、同じマシン上の別のサーバで実行した方が、パフォーマンスを最適化することができます。これにより、マシン間の通信が不要になるので、より迅速な応答が可能になります。

関連項目

• コンフィギュレーション・ファイルの作成

• 複数のマシンで構成 (分散) するアプリケーション用のコンフィギュレーション・ファイル

• 『BEA Tuxedo システム入門』の「BEA Tuxedo Domains (マルチ・ドメイン) サーバ」

• 『BEA Tuxedo アプリケーション実行時の管理』の1-4 ページの「TUXCONFIG ファイルの作成」

• 分散型の BEA Tuxedo CORBA アプリケーションについては、『BEA Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』を参照してください。