構成ファイルについて

2.1 構成ファイルとは

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

テキスト形式とバイナリ形式の構成ファイル

親トピック: 構成ファイルについて

2.1.1 テキスト形式とバイナリ形式の構成ファイル

構成ファイルには、次の2つの形式があります。

UBBCONFIGファイルは、テキスト形式の構成ファイルであり、任意のエディタで作成したり、編集できます。Oracle Tuxedoのサンプル・アプリケーションには、構成ファイルのサンプルが用意されていますが、UBBCONFIGそのものは用意されていません。UBBCONFIGファイルは、アプリケーションごとに作成してください。ファイルのエントリで使用する構文については、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)に関する項を参照してください。
Oracle Tuxedoソフトウェアには、bankappおよびsimpappアプリケーションの一部として3つのUBBCONFIGファイルのサンプル(ubbshm、ubbmp、ubbsimple)が用意されています。(『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』を参照してください。)
TUXCONFIGファイルは、バイナリ形式の構成ファイルであり、tmloadcf(1)コマンドにより、テキスト形式のファイルから作成されます。tmloadcfを実行する前に、TUXCONFIGをロードするデバイスまたはシステム・ファイルのフルパス名に環境変数TUXCONFIGを設定しておく必要があります。TUXCONFIGのパラメータの多くは、必要に応じて、アプリケーションの実行中にtmconfig、wtmconfig (1)またはMIBを使用して変更できます。

2.2 構成ファイルの内容

次の表では、構成ファイルの9つのセクションと、各セクションの目的を説明します。

表2-1 構成ファイルの内容

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

構成ファイルには、少なくとも9つのパラメータが必要です。パラメータは80種類あります。最初のセクション以外のすべてのセクションには、複数のエントリを指定でき、各エントリではそれぞれ固有のパラメータを選択します。RESOURCESセクション以外のすべてのセクションでは、デフォルト値を使用して、複数のエントリに含まれるパラメータを指定できます。

コマンド行インタフェースを使用して、バイナリ形式の構成ファイル(TUXCONFIG)を作成できます。まず、そのファイルで定義する構成の種類を決定します。

1台のマシンで構成するアプリケーション - 1つ以上のローカル・クライアントまたはリモート・クライアントが、同じマシン上にある1つ以上のサーバーと通信します。
複数のマシンで構成(分散)するアプリケーション - 1つ以上のローカル・クライアントまたはリモート・クライアントが、複数のマシン上に分散する1つ以上のサーバーと通信します。
複数のドメインにまたがるアプリケーション - 複数のアプリケーションが、Oracle Tuxedoの拡張機能であるDomains機能を利用して相互に通信します。この構成に含まれる各アプリケーションをドメインと呼びます。

親トピック: 構成ファイルについて

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

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

親トピック: 構成ファイルについて

2.3.1 NameManagerの構成

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

NameManagerは、Oracle 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は、リモート・ドメインにあるファクトリの検索リクエストを受け取らないかぎり、相互に通信することはありません。
Oracle Tuxedoのイベント・ブローカ、NameManager、およびFactoryFinderサービスは、アプリケーション固有のサーバーを起動する前に起動しておく必要があります。ただし、アプリケーションに複数のイベント・ブローカが構成される場合、すべてのセカンダリ・イベント・ブローカは、アプリケーション・サーバーがすべて起動された後に起動しなければなりません。アプリケーション・サーバーにはこの起動順序を設定するシステム・プロトコルがないので、すべてのセカンダリ・イベント・ブローカをアプリケーション・サーバーの後に配置する必要があります。
アプリケーション・サーバーからファクトリ・オブジェクトへの参照を登録するには、マスターNameManagerを起動し、実行している必要があります。スレーブNameManagerを実行しておくだけでは不十分です。

親トピック: CORBA環境の管理上の要件とパフォーマンス

2.3.2 信頼性に関する要件

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

親トピック: CORBA環境の管理上の要件とパフォーマンス

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

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

通常、アプリケーション・ファクトリはその後すぐに再起動でき、ファクトリを提供します。ただし、ファクトリ・エントリが無制限に保持されないように保証するため、アプリケーションがダウンするとNameManagerに通知されます。この通知を受信すると、NameManagerは現在アクティブなサーバーではサポートされていないファクトリ・エントリを削除することができます。

親トピック: 信頼性に関する要件

2.3.2.2 複数のNameManagerとFactoryFinderの構成

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

親トピック: 信頼性に関する要件

2.3.2.3 マスターNameManagerの指定

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

親トピック: 信頼性に関する要件

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

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