構成ファイルについて

このトピックには次の項が含まれます:

•

構成ファイルとは

•

構成ファイルの内容

構成ファイルとは

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

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

構成ファイルには、次の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-1に、構成ファイルの9つのセクションおよび各セクションの目的の説明を示します。

 

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

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

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

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

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

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

•	複数のドメインにまたがるアプリケーション - 複数のアプリケーションが、Oracle Tuxedoの拡張機能であるDomains機能を利用して相互に通信します。この構成に含まれる各アプリケーションをドメインと呼びます。

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

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

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環境の信頼性を向上させる方法について説明します。

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

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

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

複数のNameManagerとFactoryFinderの構成

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

マスターNameManagerの指定

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

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

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

関連項目

•	3-2ページの「?$paratext>?」

•	3-3ページの「?$paratext>?」。

•	『Oracle Tuxedo ATMIの紹介』のOracle Tuxedo Domains (マルチ・ドメイン)サーバーに関する項

•	『Oracle Tuxedoアプリケーション実行時の管理』のTUXCONFIGファイルの作成に関する項

•	分散型のOracle Tuxedo CORBAアプリケーションの詳細は、『CORBAアプリケーションのスケーリング、配布およびチューニング』ガイドを参照してください。