Oracle Tuxedo Domains コンポーネント

Domains について

以下の節では、Oracle Tuxedo Domains コンポーネントの概要を説明します。

Oracle Tuxedo の Domains コンポーネントとは

企業のビジネスが拡大するにつれ、機能、地理、機密度に基づいて分かれている、それぞれが管理上独立したアプリケーションにビジネス情報管理を取り入れる必要が出てきます。それらの独立したビジネス アプリケーションはドメインと呼ばれ、情報を共有する必要があります。Oracle Tuxedo Domains コンポーネントはビジネスのドメイン間で相互運用を実現するインフラストラクチャを提供し、それによって Oracle Tuxedo クライアント/サーバ モデルが複数のトランザクション処理 (TP) ドメインに拡張されます。次の図は、Oracle Tuxedo Domains コンポーネントによって、どのようにして複数のドメインが結び付けられるのかを示しています。

ドメイン間の相互運用性

リモート ドメインのサービスをローカル ドメインのユーザが透過的に利用できるようにしたり、ローカル ドメインのサービスをリモート ドメインのユーザが利用できるようにすることで、Oracle Tuxedo Domains コンポーネントは企業のビジネス アプリケーションの間にある壁を取り払います。また、Domains コンポーネントを利用することで、Oracle Tuxedo アプリケーションを実行する企業は、ほかのトランザクション処理 (TP) システム (Oracle 社の WebLogic Server、IBM/Transarc の Encina、IBM の CICS など) で動作するアプリケーションとの相互運用を実現してビジネスを拡張することができます。

企業ではビジネス アプリケーションの性質をその名前の一部としてよく使用するので、アプリケーションの名前は「課金ドメイン」や「オーダ エントリ ドメイン」のようになります。Oracle Tuxedo ドメインは、UBBCONFIG という 1 つのコンフィグレーション ファイルで制御される単一コンピュータまたは複数コンピュータのネットワークです。Oracle Tuxedo のコンフィグレーション ファイルには、どのような名前でも付けられます。ただし、そのファイルの内容は『Oracle Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) リファレンス ページで指定された形式に準拠している必要があります。Oracle Tuxedo ドメインは、1 つのユニットとして管理されます。

ドメイン ゲートウェイの種類

Oracle Tuxedo Domains コンポーネントは、各種のネットワークおよびドメインと通信するためのさまざまなゲートウェイを提供します。具体的には、Domains コンポーネントでは以下のドメイン ゲートウェイが提供されます。

これ以降は、Oracle TDomain ゲートウェイおよび Oracle Tuxedo ドメイン間の通信を中心に説明します。WTC ゲートウェイについては、次のドキュメントを参照してください。

Oracle TMA ゲートウェイについては、http://download.oracle.com/docs/cd/E13161_01/tuxedo/tux100/interm/mainfrm.html を参照してください。

Domains コンフィグレーションの例

次の図は、ドメインが 4 つのサンプル Domains コンフィグレーションを示しています。そのうちの 3 つは Oracle Tuxedo ドメインです。

図の一番下にある Oracle Tuxedo クレジット カード認可センターには、bankgw1 という TDomain ゲートウェイ グループと bankgw2 という OSI TP ゲートウェイ グループの 2 つのゲートウェイ グループがあります。 bankgw1 は、ネットワーク プロトコル TCP/IP を使用して 2 つのリモート Oracle Tuxedo ドメイン (ABC 銀行と CBA 銀行) へのアクセスを提供します。bankgw2 は、ネットワーク プロトコル OSI TP を使用して 1 つのリモート ドメイン (XYZ 銀行) へのアクセスを提供します。

この例では、別のドメインである ABC 銀行が、クレジット カード認可システムに対するサービス要求を生成しています。その要求は、グループ bankgw1 で動作している GWTDOMAIN というドメイン ゲートウェイ サーバ プロセスによって受信されます。このゲートウェイは、ローカルで動作している別のサーバ プロセスが提供するクレジット カード認可サービスに対し、リモート ドメインの代わりにサービス要求を発行します。このサーバは、要求を処理してから、応答をゲートウェイに送信します。ゲートウェイは、応答を ABC 銀行に転送します。

クレジット カード認可センターからサービス要求を発行することもできます。たとえば認可センターは、GWOSITP というドメイン ゲートウェイ サーバ プロセスを通じて XYZ 銀行に残高照会を要求できます。

Oracle Tuxedo Domains コンポーネントは、リモート サービス (ほかのドメインのサービス) をローカル サービスであるかのように宣言するドメイン ゲートウェイ サーバ プロセスを通じてドメイン間通信を実現します。

ドメイン ゲートウェイでサポートされる機能

ドメイン ゲートウェイでは、次の機能がサポートされています。

ローカル ドメインとリモート ドメイン間での要求/応答型の通信

ドメイン ゲートウェイは、ATMI インタフェースで定義された要求/応答型のモデルをサポートしています。論理的に 1 つのアプリケーション内で使用するよう制限されており、ドメイン間での使用はサポートされていない以下の Oracle Tuxedo ATMI 関数を除いて、Oracle Tuxedo アプリケーションはローカル サービスの場合とまったく同じようにリモート サービスを要求できます。

アプリケーションの移植性を維持するため、tpforward(3c) がサポートされています。転送された要求は、ドメイン ゲートウェイにより、単純なサービス要求として解釈されます。次の図は、このプロセスを示しています。この図では、tpforward を使用して、リモート サービスを要求する簡単な流れを示します。

Oracle Tuxedo 要求/応答型モデルの詳細については、『Oracle Tuxedo システム入門』の「要求/応答型通信」を参照してください。

ローカル ドメインとリモート ドメイン間での会話型通信

ドメイン ゲートウェイは、ATMI インタフェースで定義された会話型のモデルをサポートしています。ATMI は接続指向型のインタフェースです。このインタフェースを使用すると、クライアントは、会話型モデルでプログラミングされたサービスとの会話を確立し、保持することができます。

Oracle Tuxedo アプリケーションは、tpconnect(3c) を使用してリモート サービスとの会話を確立し、tpsend(3c) と tprecv(3c) を使用してこのサービスと通信し、tpdiscon(3c) を使用して会話を終了します。ドメイン ゲートウェイは、リモート サービスとの会話を保持し、Oracle Tuxedo の会話型サービスの定義と同じセマンティクスで戻り値 (TPSUCCESS または TPFAIL を返す tpreturn) を返し、接続を切断します。

Oracle Tuxedo 会話型モデルの詳細については、『Oracle Tuxedo システム入門』の「会話型通信」を参照してください。

リモート ドメインでのメッセージのキュー登録

ドメイン ゲートウェイは、ATMI インタフェースで定義されたキューの処理モデルをサポートしています。クライアントやサーバはどれも、リモート ドメインのキューにメッセージまたはサービス要求を格納できます。格納された要求はすべて、安全性を確保するため、トランザクション プロトコルを使用して送信されます。

Oracle Tuxedo システムでは、メッセージを永続ストレージ (ディスク) や非永続ストレージ (メモリ) に登録して、後で処理や検索を行うことができます。ATMI には、メッセージをキューに追加 (tpenqueue) したり、キューから読み取る (tpdequeue) ためのプリミティブが用意されています。応答メッセージやエラー メッセージをキューに登録しておき、後でクライアントに返すこともできます。キューの作成、一覧表示、および変更を行うための管理コマンド インタプリタ (qmadmin) も用意されています。また、メッセージをキューに登録したり、キューから取り出す要求を受け付けるサーバ (TMQUEUE サーバ)、キューから取り出したメッセージを処理するために転送するサーバ (TMQFORWARD サーバ)、およびキューの処理を伴うトランザクションを管理するサーバ (TMS_QM サーバ) の 3 つのサーバが用意されています。

Oracle Tuxedo キューの処理モデルの詳細については、『Oracle Tuxedo システム入門』の「メッセージ キューイング通信」を参照してください。

Domains のエンコードおよびデコード操作

ドメイン ゲートウェイは、ドメイン ゲートウェイ サーバ プロセスが実行されているリリースの Oracle Tuxedo システム ソフトウェアによってサポートされているすべての定義済み型付きバッファをサポートします。Oracle Tuxedo は、11 種類の定義済みバッファ型をサポートしています。

Oracle Tuxedo リリースでサポートされている各バッファ型には、プログラマの介入なしで初期化、メッセージの送受信、およびデータのエンコード/デコードを行うために自動的に呼び出すことができるそれ独自のルーチン セットがあります。このルーチン セットを型付きバッファ スイッチと呼びます。

Oracle Tuxedo ATMI アプリケーションでは、クライアントとサーバとの間でデータ (サービス要求と応答) を送信するために型付きバッファが使用されます。その名前のとおりそれ自身についての情報 (メタデータ) が含まれている型付きバッファにより、アプリケーション プログラマは、アプリケーションのクライアントサイドおよびサーバサイドで稼動中のマシンのデータ表現スキーマを意識せずにデータを転送することができます。

ドメイン ゲートウェイは、ワークステーション、ローカルの Oracle Tuxedo マシン、およびリモート ドメインから送信されるサービス要求を受信し、処理できます。ドメイン ゲートウェイは、次の理由により、エンコードされている受信したすべてのサービス要求を適切な型付きバッファ スイッチを使用してデコードします。

OSI 用語では、抽象構文 (データの構造) と転送構文 (データ転送に使用する特定のエンコード) を明確に区別します。各型付きバッファでは、特定のデータ構造 (抽象構文) と、そのデータ構造を特定の転送構文 (たとえば XDR) にマップするのに必要なエンコード規則 (型付きバッファの動作) を暗黙的に定義します。エンコード/デコードをサポートする定義済みのバッファ型について、Oracle Tuxedo システムではそれらの型を XDR 転送構文にマップするためのエンコード規則が用意されています。

型付きバッファおよびエンコード/デコード操作の詳細については、『Oracle Tuxedo システム入門』の「型付きバッファ」を参照してください。

Oracle Tuxedo Domains のアーキテクチャ

Oracle Tuxedo Domains のアーキテクチャは、主に次の 4 つの要素で構成されています。

Domains コンフィグレーション ファイル

Domains コンフィグレーションは、Oracle Tuxedo Domains コンポーネントを介して通信したりサービスを共有したりできる複数のドメイン (アプリケーション) の集合です。複数のドメインがどのように接続されるのか、およびどのサービスが互いに利用可能になるのかは、Domains コンフィグレーション ファイルで定義します。Domains コンフィグレーションに関与する各 Oracle Tuxedo ドメインでは、それ専用の Domains コンフィグレーション ファイルが必要です。

テキスト形式の Domains コンフィグレーション ファイルは DMCONFIG ファイルと呼ばれますが、任意の名前を付けることもできます。ただし、そのファイルの内容が『Oracle Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) リファレンス ページで説明されている形式に準拠している場合に限ります。バイナリ形式の Domains コンフィグレーション ファイルは、BDMCONFIG と呼ばれます。DMCONFIG ファイルの詳細については、「Domains コンフィグレーション ファイル」を参照してください。

ドメイン ゲートウェイ サーバ

Oracle Tuxedo Domains コンポーネントは、非同期性の高い、マルチタスク型およびマルチスレッド型のドメイン ゲートウェイ プロセスを使用してマルチ ドメインの相互運用性を実現します。そのドメイン ゲートウェイ プロセスは、アプリケーション プログラマとアプリケーション ユーザが両方とも別のドメインのサービスに透過的にアクセスできるようにする Oracle Tuxedo 提供サーバです。

次の図は、1 つの Oracle Tuxedo ドメインが、ドメイン ゲートウェイを介して別のドメインと通信する方法を示しています。

この図では、ドメイン ゲートウェイがクレジット カードの認可要求を処理し、別のドメインに送信する様子を示しています。このゲートウェイは、認可要求に対する応答も処理します。

Domains 管理サーバ

次の図は、Domains コンフィグレーションを管理するために使用される Oracle Tuxedo Domains 管理サーバを示しています。

ドメイン ゲートウェイ グループは、前の図で示されているように、ゲートウェイ管理サーバ (GWADM)、ドメイン ゲートウェイ サーバ (GWTDOMAIN など)、および (省略可能な) Domains トランザクション ログ (TLOG) で構成されます。GWADM サーバは、ドメイン ゲートウェイの実行時における管理を可能にします。Oracle Tuxedo ドメインは、ドメイン ゲートウェイ グループを通じて 1 つ以上のリモート ドメインと通信できます。

Oracle Tuxedo ドメインで動作するすべてのドメイン ゲートウェイ グループと関連付けられているのは、Domains 管理サーバ (DMADM) です。Domains 管理サーバは、Oracle Tuxedo Domains コンフィグレーション ファイル (BDMCONFIG) の実行時における管理を可能にします。

GWADM サーバ

GWADM(5) サーバは、DMADM サーバに登録して、対応するゲートウェイ グループで使用されるコンフィグレーション情報を取得します。GWADM は、DMADMIN サービスからの要求、つまり、指定したゲートウェイ グループの実行時オプションでの統計情報や変更に対する要求を受け付けます。DMADMIN サービスは、DMADM によって宣言された汎用管理サービスです。GWADM は、定期的に "I-am-alive" メッセージを DMADM サーバに送信します。DMADM から応答がなければ、GWADM は再度登録を行います。このプロセスにより、GWADM サーバは、そのゲートウェイ グループの Domains コンフィグレーションに関する最新の情報を常に保持できます。

GWADM の詳細については、「Domains の管理」を参照してください。

DMADM サーバ

DMADM(5) サーバは、ゲートウェイ グループの登録サービスを提供します。このサービスは、GWADM サーバの初期化プロシージャの一部として GWADM サーバによって要求されます。登録サービスは、要求元のゲートウェイ グループが要求するコンフィグレーション情報をダウンロードします。DMADM サーバは、登録済みのゲートウェイ グループのリストを管理し、Domains コンフィグレーション ファイル (BDMCONFIG) が変更されると、変更内容をリスト内のゲートウェイ グループに伝播します。

DMADM の詳細については、「Domains の管理」を参照してください。

Domains 管理ツール

次の Domains 管理ツールは、Domains コンフィグレーションの設定と管理のために Oracle Tuxedo システムによって提供されます。

次の図は、Domains 管理ツールと Domains のテキスト形式およびバイナリ形式のコンフィグレーション ファイルの関係を示しています。dmadmin ユーティリティを使用する管理は、DMADM サーバで宣言される DMADMIN サービスを通じて行います。

dmloadcf コマンド

dmloadcf(1) コマンドは、DMCONFIG ファイルを解析して、その情報を BDMCONFIG にロードします。このコマンドは、環境変数 BDMCONFIG を使用して、コンフィグレーションが格納されるデバイス ファイルまたはシステム ファイルの名前を示します。

dmloadcf コマンドに -c オプションを指定して実行すると、コンフィグレーションで指定された各ローカル ドメインに必要なプロセス間通信 (IPC) リソースの量を計算できます。

dmloadcf コマンドは、DMTYPE ファイル (Windows の場合は %TUXDIR%\udataobj\DMTYPE、UNIX の場合は $TUXDIR/udataobj/DMTYPE) をチェックして、Domains コンフィグレーション ファイルで指定されたドメイン ゲートウェイ タイプが有効であるかどうかを検証します。各タイプのドメイン ゲートウェイには、DMTYPE ファイルでタグとして使用されるドメイン タイプ指定子 (TDOMAIN、SNAX、OSITP、OSITPX) があります。ファイル内の各行の形式は、次のとおりです。

dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib

このファイルには、次のような TDomain ゲートウェイ用のエントリがあります。

TDOMAIN:-lgwt:-lnwi -lnws -lnwi::

dmloadcf の詳細については、『Tuxedo コマンド リファレンス』の dmloadcf(1) リファレンス ページを参照してください。

dmunloadcf コマンド

dmunloadcf(1) コマンドは、BDMCONFIG コンフィグレーション ファイルをバイナリ形式からテキスト形式に変換して、標準出力に出力します。dmunloadcf の詳細については、『Tuxedo コマンド リファレンス』の dmunloadcf(1) リファレンス ページを参照してください。

dmadmin コマンド

dmadmin(1) コマンドは、Oracle Tuxedo の管理者が Tuxedo の実行中にドメイン ゲートウェイをコンフィグレーション、モニタ、およびチューニングできるようにします。このコマンドは、管理コマンドを変換して要求を DMADMIN サービス (DMADM サーバにより宣言される汎用管理サービス) に送信する管理コマンド インタプリタとしても機能します。この結果、DMADMIN サービスは、BDMCONFIG ファイル内の情報を検証、取得、または更新する関数を呼び出します。

-c オプションを指定して dmadmin を呼び出すと、BDMCONFIG ファイルが動的に更新されます。変更されるコンフィグレーションに応じて、一部の更新はすぐに行われ、ほかの更新はその更新で影響を受けるものが新しく発生したときにのみ行われます。

dmadmin の詳細については、「Domains の管理」を参照してください。

Domains コンフィグレーション ファイル

Domains コンフィグレーションに関与する各 Oracle Tuxedo ドメインには、ドメイン間パラメータの定義されるコンフィグレーション ファイルがあります。テキスト形式のコンフィグレーション ファイルは DMCONFIG と呼ばれますが、コンフィグレーション ファイルには任意の名前を付けることができます。ただし、そのファイルの内容が『Oracle Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) リファレンス ページで説明されている形式に準拠している場合に限ります。典型的なコンフィグレーション ファイル名は、文字列 dm で始まり、その後にファイル名 dmconfig の config のようなニーモニック文字列が続きます。

Domains コンフィグレーションの管理者は、コンフィグレーションに参加する Oracle Tuxedo ドメインごとに別個の DMCONFIG ファイルを作成する必要があります。DMCONFIG ファイルは、任意のテキスト エディタで作成および編集できます。

DMCONFIG ファイルの場所

Domains コンフィグレーションに関与する Oracle Tuxedo ドメインの DMCONFIG ファイルは、Tuxedo ドメインの UBBCONFIG ファイルで指定されているとおりに、Domains 管理サーバ DMADM が実行されるマシン上に配置されます。DMADM サーバは、Tuxedo ドメインのどのマシン (マスタ マシン、非マスタ マシン) でも実行できます。

バイナリ形式の DMCONFIG ファイル

BDMCONFIG ファイルは、DMCONFIG ファイルのバイナリ形式です。dmloadcf コマンドを実行することで作成されます。このコマンドは、DMCONFIG を解析して、バイナリ形式の BDMCONFIG ファイルを BDMCONFIG 環境変数で示された位置にロードします。DMCONFIG ファイルと同様、BDMCONFIG ファイルがどのような名前であっても、実際の名前は BDMCONFIG 環境変数で指定されたデバイス ファイル名またはシステム ファイル名になります。BDMCONFIG 環境変数は、BDMCONFIG がロードされるデバイス ファイル名またはシステム ファイル名で終わる絶対パス名に設定する必要があります。

UBBCONFIG のバイナリ形式である TUXCONFIG ファイルと違って、BDMCONFIG ファイルは Tuxedo アプリケーションの起動時に Tuxedo ドメインのほかのどのマシンにも伝播されません。BDMCONFIG ファイルを Tuxedo ドメインのほかのマシンにも配置するためには、そのドメインの管理者が手作業で配置する必要があります。

DMCONFIG ファイルのセクションの記述

DMCONFIG ファイルは、複数の指定セクションで構成されます。セクションは、アスタリスク (*) が先頭に付いた行から始まります。アスタリスク (*) の直後にはセクション名が表示されます。アスタリスクは、セクション名を指定するときに必要です。

使用可能なセクション名は次のとおりです。

Domains コンフィグレーションの管理者は、以上のセクションを以下の目的で使用します。

次の図は、いまここで説明している作業の単純な例です。

この例では、ドメイン X に作成された DMCONFIG ファイルを補うドメイン Y の DMCONFIG ファイルも作成する必要があります。つまり、ドメイン X の DMCONFIG ファイルのローカル ドメイン アクセス ポイントがドメイン Y の DMCONFIG ファイルでリモート ドメイン アクセス ポイントになり、ドメイン X の DMCONFIG ファイルのリモート ドメイン アクセス ポイントがドメイン Y の DMCONFIG ファイルでローカル ドメイン アクセス ポイントになります。例では、TDomain ゲートウェイ サーバの使い方が例示されています。

次の表では、DMCONFIG ファイルの各セクションについて説明します。

DMCONFIG ファイルの詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) および DM_MIB(5) のリファレンス ページを参照してください。

DMCONFIG ファイル関連の新しい用語

Oracle Tuxedo のリリース 7.1 以降では、Domains 用の MIB で、ローカル ドメインとリモート ドメインとの相互作用を記述するため、クラスと属性の用語が改善されています。新しい用語は、DMCONFIG(5) リファレンス ページ、セクション名、パラメータ名、エラー メッセージ、および DM_MIB(5) リファレンス ページ、クラス、エラー メッセージに適用されます。

下位互換性のため、Oracle Tuxedo 7.1 より前に使用されていた DMCONFIG 用語と Domains 用の MIB の新しい用語との間でエリアスが提供されています。Oracle Tuxedo リリース 7.1 以降の DMCONFIG では、両方のバージョンの用語を使用できます。次の表に、DMCONFIG ファイルの旧用語と新用語の対応を示します。

Oracle Tuxedo のリリース 7.1 以降の dmunloadcf コマンドでは、デフォルトで新しいドメイン関連の用語を使用する DMCONFIG ファイルが生成されます。以前のドメイン関連の用語を使用する DMCONFIG ファイルを出力するには、-c オプションを使用します。次に例を示します。

プロンプト > dmunloadcf -c > dmconfig_prev

Domains データ依存型ルーティングの指定

次のどのバッファ タイプでも、DMCONFIG ファイルの DM_ROUTING セクションで、ローカルのサービス要求をリモート ドメインにルーティングするためのデータ依存型ルーティング基準を指定できます。

次の例では、リモート サービスの TOUPPER は REMOT1 および REMOT2 という 2 つのリモート ドメイン アクセス ポイントを通じて利用でき、TOUPPER のデータ依存型ルーティング基準は ACCOUNT というルーティング基準テーブルで定義されています。例の RTOUPPER1 と RTOUPPER2 は、リモート ドメインで予期される実際のサービス名 TOUPPER のエリアスです。

*DM_IMPORT
RTOUPPER1  AUTOTRAN=N
           RACCESSPOINT=REMOT1
           LACCESSPOINT=LOCAL1
           CONV=N
           RNAME=“TOUPPER”
           ROUTING=ACCOUNT
RTOUPPER2  AUTOTRAN=N
           RACCESSPOINT=REMOT2
           LACCESSPOINT=LOCAL1
           CONV=N
           RNAME=“TOUPPER”
           ROUTING=ACCOUNT

*DM_ROUTING
ACCOUNT    FIELD=branchid
           BUFTYPE=“VIEW:account”
           RANGES=“MIN-1000:REMOT1,1001-3000:REMOT2”

ACCOUNT ルーティング テーブルに関して、VIEW と account はこのルーティング テーブルが有効であるデータ バッファのタイプとサブタイプで、branchid はルーティングが適用される VIEW データ バッファのフィールドの名前です。branchid フィールドの有効な値は次のとおりです。

TOUPPER サービス要求の branchid フィールドの値が MIN-1000 の範囲にある場合、サービス要求は REMOT1 アクセス ポイントを通じてルーティングされます。TOUPPER サービス要求の branchid フィールドの値が 1001-3000 の範囲にある場合、サービス要求は REMOT2 アクセス ポイントを通じてルーティングされます。

Domains のトランザクション タイムアウトとブロッキング タイムアウトの指定

Oracle Tuxedo システムには、トランザクション タイムアウト メカニズムとブロッキング タイムアウト メカニズムの 2 つのタイムアウト メカニズムがあります。トランザクション タイムアウトは、サービス要求を処理する ATMI トランザクションの期間を定義するために使用します。このタイムアウト値は、トランザクションを開始するときに定義されます。一方、ブロッキング タイムアウトは、個々のサービス要求の期間、つまり、サービス要求に対する応答を ATMI アプリケーションが待つ時間を定義するために使用します。

プロセスがトランザクション モードではない場合、Oracle Tuxedo システムによってブロッキング タイムアウトが実行されます。プロセスがトランザクション モードである場合は、Oracle Tuxedo システムによってトランザクション タイムアウトが実行されますが、ブロッキング タイムアウトは実行されません。後者の説明はドメイン内トランザクション (1 つの Oracle Tuxedo ドメイン内で処理されるトランザクション) では当てはまりますが、ドメイン間トランザクションでは当てはまりません。ドメイン間トランザクションでは、プロセスがトランザクション モードである場合、Domains ソフトウェアによってトランザクション タイムアウトとブロッキング タイムアウトの両方が実行されます。

Domains コンポーネントによるトランザクション タイムアウトの処理

Oracle Tuxedo のトランザクション タイムアウト メカニズムは、Domains コンポーネントにもそのまま適用されます。ドメイン ゲートウェイはトランザクション マネージャ サーバ (TMS) 機能を実装しているため、Oracle Tuxedo BBL 管理プロセスで生成される TMS タイムアウト メッセージの処理を要求されます。したがって、Oracle Tuxedo と Domains で使用されるトランザクション タイムアウトのメカニズムが同じであることが必要となります。

DMCONFIG ファイルの DM_EXPORT セクションでリモート ドメインから利用できるようにされたローカル サービスは、ローカル UBBCONFIG ファイルの SERVICES セクションから次のトランザクション関連プロパティを継承します。

同様に、DMCONFIG ファイルの DM_IMPORT セクションでローカル ドメインから利用できるようにされたリモート Oracle Tuxedo サービスは、リモートの UBBCONFIG ファイルの SERVICES セクションから AUTOTRAN プロパティと TRANTIME プロパティを継承します。トランザクションで TRANTIME タイムアウト値を過ぎると、そのトランザクションの影響を受ける Oracle Tuxedo ノードによって TMS タイムアウト メッセージが生成されます。

Oracle Tuxedo のリリース 8.1 以降が動作するマシンで宣言されたサービスは、UBBCONFIG ファイルの RESOURCES セクションから MAXTRANTIME という追加的なトランザクション タイムアウト プロパティを継承します。MAXTRANTIME タイムアウト値が TRANTIME タイムアウト値またはトランザクションを開始する tpbegin(3c) の呼び出しで渡されたタイムアウト値より小さい場合、トランザクションのタイムアウトは MAXTRANTIME の値に削減されます。MAXTRANTIME は Oracle Tuxedo 8.0 以前を実行するマシン上で開始されるトランザクションには影響を与えません。ただし、Oracle Tuxedo 8.1 以降を実行するマシンがトランザクションの影響を受ける場合は、そのノードに対してコンフィグレーションされている MAXTRANTIME 値までトランザクション タイムアウト値が制限 (必要に応じて減少) されます。

Domains コンフィグレーションの場合は、以下のようなトランザクション処理のシナリオが考えられます。

MAXTRANTIME の詳細については、UBBCONFIG(5) の RESOURCES セクションにある MAXTRANTIME、または TM_MIB(5) の T_DOMAIN クラスにある TA_MAXTRANTIME を参照してください。

Domains コンポーネントによるブロッキング タイムアウトの処理

Oracle Tuxedo のブロッキング タイムアウト メカニズムでは、ローカル マシンで動作する各 Oracle Tuxedo クライアント プロセスまたはサーバ プロセスに割り当てられたレジストリ スロット内の情報を使用します。レジストリ スロットは、各プロセスに 1 つです。レジストリ スロット内の情報は、BLOCKTIME で指定された期間を過ぎてもブロックされたままの要求元を検出するためにローカルの BBL で使用されます。ドメイン ゲートウェイ プロセスは一度に複数のサービス要求を処理できるマルチタスク型サーバなので (複数のレジストリ スロットが必要)、ドメイン ゲートウェイではレジストリ スロット メカニズムを使用できません。Domains 環境でブロッキング タイムアウトが発生すると、エラーまたは障害を通知する応答メッセージがドメイン ゲートウェイから要求元に送信され、サービス要求に関連するあらゆるコンテキストがクリーンアップされます。

DMCONFIG ファイルの DM_LOCAL セクションでは、BLOCKTIME パラメータを使用してローカル ドメイン アクセス ポイントのブロッキング タイムアウトを設定できます。次に例を示します。

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30

BLOCKTIME パラメータでは、ATMI ブロッキング呼び出しがブロックされる最大待ち時間を指定します。この時間を過ぎると、タイムアウトになります。ブロッキング タイムアウト状態は、関連する要求が失敗したことを示します。

ブロッキング タイムアウト値は、UBBCONFIG ファイルの RESOURCES セクションで指定された SCANUNIT パラメータの乗数です。値 SCANUNIT * BLOCKTIME は、SCANUNIT 以上、32,767 秒以下である必要があります。

BLOCKTIME が DMCONFIG ファイルで指定されていない場合、デフォルトは UBBCONFIG ファイルの RESOURCES セクションで指定された BLOCKTIME パラメータの値に設定されます。BLOCKTIME パラメータが UBBCONFIG ファイルで指定されていない場合、デフォルトは SCANUNIT * BLOCKTIME が約 60 秒になるように設定されます。

トランザクションの期間が BLOCKTIME を過ぎると、ドメイン間トランザクションでブロッキング タイムアウト状態が生じます。つまり、ドメイン間トランザクションについては、BLOCKTIME 値が UBBCONFIG ファイルの SERVICES セクションで指定された TRANTIME タイムアウト値、またはトランザクションを開始する tpbegin() の呼び出しで渡されたタイムアウト値より小さい場合、トランザクションのタイムアウトは BLOCKTIME の値に削減されます。その一方で、1 つの Oracle Tuxedo ドメイン内で処理されるドメイン内トランザクションの場合、TUXCONFIG ファイルの RESOURCES セクションで指定された BLOCKTIME 値はドメイン内トランザクションのタイムアウトに影響しません。

Domains の接続ポリシーの指定

ユーザは、以下のいずれかの接続ポリシーを選択して、ローカル ドメイン ゲートウェイから 1 つ以上のリモート ドメインへの接続条件を指定できます。

接続ポリシーは、TDomain ゲートウェイにのみ適用されます。

接続ポリシーのコンフィグレーション方法

DMCONFIG ファイルの DM_LOCAL セクションでは、CONNECTION_POLICY パラメータを使用してローカル ドメイン アクセス ポイントの接続ポリシーを設定します。次に例を示します。

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30
        CONNECTION_POLICY=ON_STARTUP

ローカル ドメイン アクセス ポイントの接続ポリシーを指定しない場合、そのアクセス ポイントの接続ポリシーはデフォルトで ON_DEMAND になります。

ローカル/リモート ドメイン単位の接続ポリシー

Oracle Tuxedo リリース 8.1 以降が動作している TDomain ゲートウェイについては、DMCONFIG ファイルの DM_TDOMAIN セクションでローカルまたはリモート ドメイン単位で接続ポリシーを設定できます。次に例を示します。

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30

*DM_REMOTE
REMOT1  TYPE=TDOMAIN
        DOMAINID=”REMOT1”

REMOT2  TYPE=TDOMAIN
        DOMAINID=”REMOT2”

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
        CONNECTION_POLICY=ON_STARTUP
REMOT1  NWADDR=“//newyork.acme.com:65431”
        CONNECTION_POLICY=ON_DEMAND
REMOT2  NWADDR=“//philly.acme.com:65431”

リモート ドメイン アクセス ポイントに指定された接続ポリシーは、ローカル ドメイン アクセス ポイントに指定された接続ポリシーに優先します。このため、前の例の接続ポリシー コンフィグレーションは次のようになります。

LOCAL1 to REMOT1 — ON_DEMAND
LOCAL1 to REMOT2 — ON_STARTUP

Oracle Tuxedo 8.1 以降では、DMCONFIG ファイルの DM_TDOMAIN セクションでローカル ドメイン アクセス ポイントに次のいずれかの接続ポリシー値を指定できます。

ローカル ドメイン アクセス ポイントの接続ポリシーを指定しない場合は、DMCONFIG ファイルの DM_LOCAL セクションで指定されたグローバル接続ポリシーがデフォルトで使用されます。DM_TDOMAIN セクションで指定されたグローバル接続ポリシーは、DM_LOCAL セクションで指定されたグローバル接続ポリシーに優先します。

Oracle Tuxedo 8.1 以降では、リモート ドメイン アクセス ポイントの接続ポリシー値も、DMCONFIG ファイルの DM_TDOMAIN セクションで次のいずれかから指定できます。

リモート ドメイン アクセス ポイントに LOCAL を指定するか、接続ポリシーを指定しないと、デフォルトでグローバル接続ポリシーが使用されます。

リモート ドメインの接続ポリシー機能がないと、グローバル接続ポリシーが ON_STARTUP の場合に、ローカル TDomain ゲートウェイはたとえ一部のリモート ドメインが最初は使用されない場合でも起動時にすべてのリモート ドメインに接続しようとします。このため、リモート ドメインの数が多い場合は起動にかなりの時間がかかります。リモート ドメインの接続ポリシー機能を使用する場合は、グローバル接続ポリシーの ON_STARTUP で、起動時に自動的には確立されないリモート ドメインの接続を選択できます。

TDomain セッション単位の接続ポリシー

Oracle Tuxedo リリース 9.0 では、DMCONFIG ファイルの DM_TDOMAIN セクションで TDomain ゲートウェイまたは TDomain セッション単位で接続ポリシーを定義できます。

TDomain セッション単位の接続ポリシーを定義するには、次のことを行う必要があります。

TDomain セッションの作成

TDomain セッションの作成には、DMCONFIG ファイルの DM_TDOMAIN セクションで 2 つのパラメータを使用します。

他の TDomain セッション パラメータおよび属性 (SECURITY、DMKEEPALIVE) も指定できます。FAILOVERSEQ、LACCESSPOINT、およびその他の TDomain パラメータおよび属性については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「DM_TDOMAIN セクションの省略可能パラメータ」を参照してください。

TDomain セッション単位の接続ポリシーの作成

次の例では、TDomain セッション単位の接続ポリシーを作成するために使用する FAILOVERSEQ、LACCESSPOINT、および CONNECTION_POLICY パラメータを指定しています。

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30

LOCAL2  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL02”
        BLOCKTIME=30

*DM_REMOTE
REMOT1  TYPE=TDOMAIN
        DOMAINID=”REMOT1”

REMOT2  TYPE=TDOMAIN
        DOMAINID=”REMOT2”

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
LOCAL2  NWADDR=“//chicago.acme.com:4032”
LOCAL1  NWADDR=“//albany.acme.com:4052”
REMOT1  NWADDR=“//newyork.acme.com:65431” LACCESSPOINT=LOCAL1
        CONNECTION_POLICY=ON_STARTUP
        MINENCRYPTBITS=128 MAXENCRYPTBITS=128
        FAILOVERSEQ=100
REMOT1  NWADDR=“//newyork.acme.com:65432” LACCESSPOINT=LOCAL2
        CONNECTION_POLICY=INCOMING_ONLY
        FAILOVERSEQ=110
REMOT2  NWADDR=“//philly.acme.com:65431” LACCESSPOINT=LOCAL2
        CONNECTION_POLICY=ON_DEMAND
        FAILOVERSEQ=120
REMOT1  NWADDR=“//detroit.acme.com:65431” LACCESSPOINT=LOCAL1
        CONNECTION_POLICY=INCOMING_ONLY
        MINENCRYPTBITS=40 MAXENCRYPTBITS=40
        FAILOVERSEQ=130

DM_TDOMAIN セクションは、3 つの TDomain セッションを含む 7 つのレコードから構成されています。

同じ TDomain セッションで 2 つ以上のレコードの FAILOVERSEQ 値が同じである場合、最初に入力されたレコードがプライマリ レコードになります。残りのレコードのフェイルオーバ シーケンスは、レコード エントリ順序に基づいて決定されます。

TDomain セッション単位の接続ポリシーを作成するには、次の手順を行います。

TDomain セッションでの正規表現の使い方

DMCONFIG ファイルを小さくし、処理しやすくするために、LACCESSPOINT で正規表現を使用して複数のローカル ドメイン アクセス ポイントを定義できます。

DMCONFIG ファイルがコンパイルされると、出力バイナリ BDMCONFIG ファイルで正規表現がローカル ドメイン名に展開されます。この結果、次の例のように、BDMCONFIG ファイルのサイズが増加します。

*DM_LOCAL
ALPHA1   .. .
ALPHA2   .. .
ALPHA3   .. .
ALPHA10   .. .
ALPHA11   .. .
ALPHA24   .. .
ALPHA36   .. .
BETA2   .. .
BETA3   .. .
BETA15   .. .
BETA20   .. .
*DM_REMOTE
REMOT1   .. .
REMOT2   .. .
REMOT3   .. .
*DM_TDOMAIN
REMOT1  NWADDR=“//philly.acme.com:65431” LACCESSPOINT=ALPHA1
        CONNECTION_POLICY=INCOMING_ONLY
        FAILOVERSEQ=100
REMOT1  NWADDR=“//philly.acme.com:65432” LACCESSPOINT=BETA2
        CONNECTION_POLICY=ON_DEMAND
        FAILOVERSEQ=110
REMOT1  NWADDR=“//philly.acme.com:65433” LACCESSPOINT=”ALPHA[1-2][0-9]”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=120
REMOT1  NWADDR=“//philly.acme.com:65434” LACCESSPOINT=”BETA[1-2][0-9]*”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=130

TDomain セッション レコード 3 および 4 では、正規表現によってローカル アクセス ポイントが定義されます。dmloadcf でこの DMCONFIG ファイルが解析された場合、BDMCONFIG ファイルの出力は次のとおりです。

REMOT1  NWADDR=“//philly.acme.com:65431” LACCESSPOINT=ALPHA1
        CONNECTION_POLICY=INCOMING_ONLY
        FAILOVERSEQ=100
REMOT1  NWADDR=“//philly.acme.com:65432” LACCESSPOINT=BETA2
        CONNECTION_POLICY=ON_DEMAND
        FAILOVERSEQ=110
REMOT1  NWADDR=“//philly.acme.com:65433” LACCESSPOINT=”ALPHA10”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=120
REMOT1  NWADDR=“//philly.acme.com:65433” LACCESSPOINT=”ALPHA11”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=120
REMOT1  NWADDR=“//philly.acme.com:65433” LACCESSPOINT=”ALPHA24”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=120
REMOT1  NWADDR=“//philly.acme.com:65434” LACCESSPOINT=”BETA2”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=130
REMOT1  NWADDR=“//philly.acme.com:65434” LACCESSPOINT=”BETA15”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=130
REMOT1  NWADDR=“//philly.acme.com:65434” LACCESSPOINT=”BETA20”
        CONNECTION_POLICY=ON_STARTUP
        FAILOVERSEQ=130

DM_MIB を使用した TDomain セッション情報の指定と要求

DM_MIB を使用して TDomain セッション情報を指定および要求すると、BDMCONFIG ファイルが直接修正されます。元の DMCONFIG ファイルは修正されません。DM_MIB の詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「DM_MIB(5)」を参照してください。

DM_MIB は、3 つの T_DM_TDOMAIN クラス定義属性を使用して、TDomain セッション単位の接続ポリシーを BDMCONFIG ファイルに作成します。

また、他の T_DM_TDOMAIN クラス定義属性 (セキュリティやキープアライブなど) を指定および要求できます。T_DM_TDOMAIN クラス定義属性情報については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「T_DM_TDOMAIN クラス定義」を参照してください。

DM_MIB を使用して、BDMCONFIG ファイルの TDomain セッション レコードを追加、削除、または検索できます。TDomain セッション レコード情報を追加、削除、または検索するには、該当するすべての T_DM_TDOMAIN クラス定義キー フィールドを使用する必要があります。

次に例を示します。

例 1: 新しい TDomain セッションおよび接続ポリシー レコードを追加するための DM_MIB 要求

TA_OPERATION                SET
TA_CLASS                    T_DM_TDOMAIN
TA_DMACCESSPOINT            RDOM1
TA_DMNWADDR                 //philly.acme.com:65431
TA_STATE                    NEW
TA_DMLACCESSPOINT           LDOM3
TA_DMFAILOVERSEQ            50
TA_DMCONNECTION_POLICY      ON_STARTUP

これにより、次の TDomain セッション レコードが BDMCONFIG ファイルに追加されます。

RDOM1  NWADDR=“//philly.acme.com:65431” LACCESSPOINT=LDOM3
       FAILOVERSEQ=50
       CONNECTION_POLICY=ON_STARTUP

例 2: 既存の TDomain セッション接続ポリシー レコードを削除するための DM_MIB 要求

要求されたレコードは BDMCONFIG ファイルで「無効」と識別されているので、TDomain セッションには含まれていません。

TA_OPERATION                SET
TA_CLASS                    T_DM_TDOMAIN
TA_DMACCESSPOINT            RDOM1
TA_DMNWADDR                 //philly.acme.com:65431
TA_STATE                    INV
TA_DMLACCESSPOINT           LDOM3
TA_DMFAILOVERSEQ            50
TA_DMCONNECTION_POLICY      ON_STARTUP

例 3: 既存の TDomain セッション接続ポリシー レコードを検索するための DM_MIB 要求

TA_OPERATION                GET
TA_CLASS                    T_DM_TDOMAIN
TA_DMACCESSPOINT            RDOM1
TA_DMNWADDR                 //philly.acme.com:65431
TA_STATE                    INV
TA_DMLACCESSPOINT           LDOM3
TA_DMFAILOVERSEQ            50
TA_DMCONNECTION_POLICY      ON_STARTUP

DMADMIN を使用した TDomain セッション情報の指定と要求

Tuxedo のコマンドライン インタフェース、DMADMIN を使用すると、TDomain セッション情報を指定および要求できます。DMADMIN の詳細については、「Domains 管理ツール」を参照してください。

DMADMIN で TDomain セッション情報を指定および要求する場合の効果は、DM_MIB を使用する場合とほぼ同じです。つまり、DMADMIN を使用すると、BDMCONFIG ファイルが修正されますが、元の DMCONFIG ファイルは修正されません。

DMADMIN は、3 つのフィールド識別子を使用して、TDomain セッション単位の接続ポリシー レコードを BDMCONFIG ファイルに追加します。

TA_DMFAILOVERSEQ、TA_LDOM、TA_CONNECTION_POLICY、およびその他のフィールド識別子の詳細については、『Tuxedo コマンド リファレンス』の dmadmin(1) を参照してください。

DMADMIN を使用して、TDomain セッション レコードを追加、削除、または検索できます。次に、DMADMIN を使用して TDomain セッション接続ポリシー レコードを BDMCONFIG ファイルに追加する例を示します。

TA_CMPLIMIT                   2147483647
TA_MINENCRYPTBITS             0
TA_MAXENCRYPTBITS             128
TA_DMNWADDR                   //philly.acme.com:65431
TA_LDOM                       LDOM3
TA_DMFAILOVERSEQ              50
TA_RDOM                       RDOM1
TA_CONNECTION_POLICY          ON_STARTUP

旧バージョンの Tuxedo との TDomain セッションの相互運用性

Tuxedo 9.x TDomain ゲートウェイは、旧リリースの Tuxedo の TDomain ゲートウェイと通信できます。しかし、Tuxedo 9.x と 8.1 が動作する混在アプリケーション環境で TDomain セッション機能を使用する場合、以下の制限に留意してください。

混在アプリケーション環境では、TDomain セッション機能は 8.1 より前のリリースの Tuxedo では使用できません。

接続再試行プロセスの使用方法

CONNECTION_POLICY が ON_STARTUP に設定されている場合は、ほかの 2 つのパラメータをコンフィグレーションして、ローカル ドメイン ゲートウェイがリモート ドメインへの接続を試行する回数を指定できます。デフォルトでは、ローカル ドメイン ゲートウェイは 60 秒おきに失敗した接続を再試行しますが、パラメータ MAXRETRY および RETRY_INTERVAL を使用してこの間隔に別の値を指定することもできます。

MAXRETRY パラメータでは、ドメイン ゲートウェイがリモート ドメインへの接続を試行する回数を指定します。最小値は 0、最大値は 2147483647 で、デフォルト設定は 2147483647 です。このパラメータを 0 に設定すると、接続再試行プロセスが無効になります。

RETRY_INTERVAL パラメータでは、リモート ドメインへの接続を確立する自動的な試みの秒間隔を指定します。最小値は 0、最大値は 2147483647 で、デフォルト設定は 60 です。MAXRETRY パラメータを 0 に設定した場合は、RETRY_INTERVAL は設定できません。

例 1

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30
        CONNECTION_POLICY=ON_STARTUP
        MAXRETRY=5
        RETRY_INTERVAL=100

例 2 (Oracle Tuxedo リリース 8.1 以降が動作する TDomain ゲートウェイでのみ可能)

*DM_LOCAL
LOCAL1  GWGRP=GWTGROUP
        TYPE=TDOMAIN
        ACCESSPOINTID=“BA.CENTRAL01”
        BLOCKTIME=30

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
        CONNECTION_POLICY=ON_STARTUP
        MAXRETRY=5
        RETRY_INTERVAL=100
REMOT1  NWADDR=“//newyork.acme.com:65431”
        CONNECTION_POLICY=ON_STARTUP
        MAXRETRY=10
        RETRY_INTERVAL=40

2 番目の例で、MAXRETRY および RETRY_INTERVAL の値 10 と 40 は、REMOT1 というリモート ドメイン アクセス ポイントへの接続を確立するためにローカル TDomain ゲートウェイで使用される自動接続再試行の基準になります。

接続ポリシーによるリモート サービスの可用性の判断

接続ポリシーを指定すると、それによって、リモート ドメインからインポートされたサービスがドメイン ゲートウェイによって Oracle Tuxedo 掲示板でどのように宣言されるかが決まります。

接続ポリシーが ON_STARTUP または INCOMING_ONLY の場合 (ON_DEMAND は除く)、TDomain ゲートウェイの機能である Dynamic Status はリモート サービスの状態を調べます。リモート サービスの状態は、ローカル ドメイン ゲートウェイとリモート ドメイン ゲートウェイのネットワーク接続の状態によって決まります。リモート サービスは、そのサービスのあるドメインへの接続が正常に確立されるたびにローカル ドメインで宣言されて利用可能になります。リモート サービスは、そのサービスのあるドメインとの接続が切れるたびに中断されて利用不能になります。

ドメイン ゲートウェイは、各サービスに対して、サービスのインポート元であるリモート ドメインを監視するほか、どのリモート ドメインがアクセス可能であるかも監視します。この方法により、ゲートウェイは、リモート ドメインに対する要求のロード バランシングを実行します。サービスのインポート元であるすべてのリモート ドメインがアクセス不可能になると、そのサービスはドメイン ゲートウェイによって Oracle Tuxedo 掲示板で中断されます。

たとえば、DMCONFIG ファイルの DM_IMPORT セクションを以下のように指定することにより、RSVC というサービスを 2 つのリモート ドメインからインポートするとします。

*DM_IMPORT
RSVC  AUTOTRAN=N
      RACCESSPOINT=REMOT1
      LACCESSPOINT=LOCAL1
RSVC  AUTOTRAN=N
      RACCESSPOINT=REMOT2
      LACCESSPOINT=LOCAL1

REMOT1 および REMOT2 への接続が可能な場合、ドメイン ゲートウェイは、RSVC サービスに対する要求のロード バランシングを実行します。REMOT1 への接続が不可能になると、ゲートウェイは、RSVC サービスへのすべての要求を REMOT2 に送信します。REMOT1 および REMOT2 への接続が両方とも不可能になると、ゲートウェイは、掲示板の RSVC を中断します。RSVC に対する以降の要求は、ローカル サービスにルーティングされるか、または失敗して TPENOENT が返されます。

関連項目

Domains のフェイルオーバとフェイルバックの指定

DMCONFIG ファイルの DM_IMPORT セクションでは、Domains コンフィグレーションの Domains レベルのフェイルオーバおよびフェイルバック機能を設定できます。DMCONFIG ファイルの DM_TDOMAIN セクションでは、Domains コンフィグレーションの Domains リンク レベルのフェイルオーバ機能を設定できます。

Domains レベルのフェイルオーバとフェイルバックのコンフィグレーション

Domains レベルのフェイルオーバは、一次リモート ドメインで障害が検出されたときに要求を代替リモート ドメインに転送するメカニズムです。一次リモート ドメインが回復したときには、そのドメインへのフェイルバックも行われます。

Domains レベルのフェイルオーバとフェイルバックをサポートするには、特定のサービスを実行できるリモート ドメイン アクセス ポイントのリストを指定します。次に例を示します。

*DM_IMPORT
TOUPPER RACCESSPOINT=“REMOT1,REMOT2,REMOT3”

この例で、TOUPPER サービスは REMOT1 (一次)、REMOT2、および REMOT3 の 3 つのリモート ドメイン アクセス ポイントのいずれかで実行できます。REMOT1 が利用できなくなると、REMOT2 がフェイルオーバに使用されます。REMOT1 と REMOT2 が両方とも使用できない場合は、REMOT3 がフェイルオーバに使用されます。

サービスの代替リモート ドメインをコンフィグレーションする必要がある場合は、ON_STARTUP または INCOMING_ONLY を CONNECTION_POLICY パラメータの値として指定します。接続ポリシーとして ON_DEMAND を指定すると、RACCESSPOINT パラメータで指定された代替リモート ドメインに「フェイルオーバ」できません。

Domains レベルのフェイルバックは、一次リモート ドメインへのネットワーク接続が次のいずれかの理由で再確立されたときに行われます。

Domains リンク レベルのフェイルオーバのコンフィグレーション

Domains のリンク レベルのフェイルオーバは、一次ネットワーク リンクが失敗したときに二次ネットワーク リンクが有効になるようにするメカニズムです。ただし、一次リンクが回復してもそのリンクへのフェイルバックは行われません。つまり、一次リンクが回復したときには、二次リンクを手動で無効にしてトラフィックを強制的に一次リンクに戻す必要があります。

Domains のリンク レベルのフェイルオーバをコンフィグレーションするには、DMCONFIG ファイルの DM_TDOMAIN セクションでリモート ドメイン アクセス ポイントの複数のエントリを指定します。次に例を示します。

*DM_TDOMAIN
REMOT1  NWADDR=“//newyork.acme.com:65431”
REMOT1  NWADDR=“//trenton.acme.com:65431”

最初のエントリは一次アドレスと見なされます。つまり、その NWADDR はリモート ドメイン アクセス ポイントへの接続が試行されるときに試される最初のネットワーク アドレスです。2 番目のエントリは二次アドレスと見なされます。つまり、その NWADDR は一次アドレスを使用して接続を確立できないときに試される 2 番目のネットワーク アドレスです。

2 番目のエントリは、一次リモート ゲートウェイのある Oracle Tuxedo ドメインとは別の Oracle Tuxedo ドメインにある二次リモート ゲートウェイを指します。二次および一次リモート ゲートウェイの ACCESSPOINTID は、それぞれに対応する DMCONFIG ファイルの DM_LOCAL セクションで同じ値でなければなりません。この仕組みはミラー ゲートウェイと呼ばれます。この機能は、トランザクションや会話の際に使用しないようにしてください。また、一次リモート ゲートウェイが使用できるときには、ミラー ゲートウェイの使用はお勧めできません。

TDomain セッションのリンク レベルのフェイルオーバのコンフィグレーション

TDomain セッションのリンク レベルのフェイルオーバをコンフィグレーションするには、DMCONFIG ファイルの DM_TDOMAIN セクションの FAILOVERSEQ パラメータを使用します。TDomain セッションでの FAILOVERSEQ の指定については、「TDomain セッション単位の接続ポリシー」を参照してください。

また、DM_MIB の TA_DMFAILOVERSEQ 属性を使用して TDomain セッションのリンク レベルのフェイルオーバをコンフィグレーションすることもできます。詳細については、「DM_MIB を使用した TDomain セッション情報の指定と要求」を参照してください。

Domains のキープアライブの指定

Domains のキープアライブ (Oracle Tuxedo リリース 8.1 以降が動作する TDomain ゲートウェイで利用可能) を利用すると、TDomain ゲートウェイの接続ごとに TCP レベルおよびアプリケーション レベルでキープアライブ プロトコルを有効化およびコンフィグレーションできます。TCP レベルのキープアライブとアプリケーション レベルのキープアライブは相互に排他的ではないので、両方のオプションを使用して Domains 接続をコンフィグレーションできます。

次の表は、Domains のキープアライブに関する主要な情報を提供します。

ほとんどの Oracle Tuxedo Domains コンフィグレーションはファイアウォールをまたがっており、ファイアウォールはアイドル接続がタイムアウトになる原因となります。Domains キープアライブは活動のない期間に Oracle Tuxedo のドメイン間接続をオープンに維持するだけでなく、TDomain ゲートウェイで Domains 接続の失敗を迅速に検出できるようにします。現在、TDomain ゲートウェイは基底の TCP スタックを通じて Domains 接続の失敗を検出しています。TCP スタックは、失敗の発生後 15 分以上経ってからその失敗を報告します。実際に何分かかるかは、ローカルのオペレーティング システムのコンフィグレーションによって異なります。

TCP レベルのキープアライブ

キープアライブ機能は TCP の仕様に含まれていませんが、ほとんどのオペレーティング システムでは TCP キープアライブ タイマーが提供されます。TCP キープアライブ タイマーを使用すると、TCP 接続の片側のサーバ マシンでその接続のもう片側のクライアント マシンがアクセス可能かどうかを検出できます。

TCP 接続を経由してサーバ マシンに届くメッセージはすべて、TCP キープアライブ タイマーをリセットします。キープアライブ タイマーで事前定義済みの期間 (通常は 2 時間) TCP 接続で活動がないと検出されると、タイマーが切れて、サーバ マシンからセグメント検査パケットがクライアント マシンに送信されます。接続がまだオープンであり、クライアント マシンがまだ機能している場合は、クライアント マシンから肯定応答がサーバ マシンに送信されます。セグメント検査パケットを送信してから一定の期間肯定応答が届かない場合、サーバ マシンは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。

接続がオープンでクライアント マシンが機能しているかどうかを判断するだけでなく、TCP レベルのキープアライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がない状態が定義済みの期間続いた後にセグメント検査パケットを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。

オペレーティング システムの TCP キープアライブ タイマーの間隔は、通常は 2 時間に設定されます。この間隔は変更できますが、その変更によってマシンのすべての TCP 接続が影響を受けます。オペレーティング システムの TCP キープアライブ間隔は、システム全体にかかわる値です。

Domains の TCP レベルのキープアライブのコンフィグレーション

Domains の Oracle Tuxedo TCP レベル キープアライブ オプションは TCPKEEPALIVE という名前で、DMCONFIG ファイルの DM_TDOMAIN セクションにオプション パラメータとして追加されています。このパラメータを使用すると、Domains の TCP レベルのキープアライブ オプションをローカル ドメインまたはリモート ドメイン単位で有効にできます。

TCPKEEPALIVE の有効な値は次のとおりです。

Domains の TCP レベルのキープアライブ オプションは、デフォルトでは無効です。Domains 接続で TCP レベルのキープアライブを有効にした場合、オペレーティング システムの TCP キープアライブ タイマーにコンフィグレーションされたシステム全体にかかわる値が、その接続のキープアライブ間隔として使用されます。

TCPKEEPALIVE の使い方を明確にするために、次の Domains TCP レベル キープアライブ コンフィグレーションを考えてください。

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
        TCPKEEPALIVE=Y
REMOT1  NWADDR=“//newyork.acme.com:65431”
REMOT2  NWADDR=“//philly.acme.com:65431”
        TCPKEEPALIVE=NO

リモート ドメイン アクセス ポイントに指定された TCP レベルのキープアライブ コンフィグレーションは、ローカル ドメイン アクセス ポイントに指定された TCP レベルのキープアライブ コンフィグレーションに優先します。このため、前の例の TCP レベルのキープアライブ コンフィグレーションは次のようになります。

LOCAL1 から REMOT1 - TCP レベルのキープアライブ有効
LOCAL1 から REMOT2 - TCP レベルのキープアライブ無効

ローカル ドメイン アクセス ポイントの場合、TCPKEEPALIVE パラメータに次のいずれかの値を指定できます。

リモート ドメイン アクセス ポイントの場合、TCPKEEPALIVE パラメータに次のいずれかの値を指定できます。

リモート ドメイン アクセス ポイントで LOCAL を指定するか、コンフィグレーションを指定しないと、デフォルトでローカルの TCP レベルのキープアライブ コンフィグレーションが使用されます。

Domains 接続の接続ポリシーが ON_STARTUP で、TCP 接続が TCP レベルのキープアライブの障害によりクローズしている場合は、自動接続再試行が行われます。接続の再試行が成功しない場合は、dmadmin connect コマンドを使用して接続を再確立する必要があります。dmadmin connect コマンドについては、「ドメイン間の接続の確立」を参照してください。

アプリケーション レベルのキープアライブ

オペレーティング システムの TCP キープアライブについては、セグメント検査パケットが不必要に帯域幅を消費し、インターネット接続でユーザがパケット単位で支払うお金を浪費するということで、一部の人たちは使用することに異を唱えています。また、アプリケーション層では次のことを判断すべきなので、キープアライブはトランスポート (TCP) 層ではなくアプリケーション層またはリンク層が適していると信じている人たちもいます。

誰がどのような意見を持っているかに関係なく、アプリケーション レベルのキープアライブはキープアライブ タイマーの間隔を接続ごとに設定できるという点では TCP レベルのキープアライブよりも優れています。TCP レベルのキープアライブの場合、タイマーの間隔はマシン単位で設定します。

アプリケーション レベルのキープアライブを使用した場合、サーバ アプリケーションはアプリケーション キープアライブ タイマーがタイムアウトになるたびにアプリケーション固有のキープアライブ メッセージを送信します。キープアライブ メッセージは通常はヘッダ情報のみで構成され、データは関連付けられていません。クライアント アプリケーションは、肯定応答を送信してサーバ アプリケーションに応答します。キープアライブ メッセージを送信してから事前定義済みの期間肯定応答が届かない場合、サーバ アプリケーションは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。

接続がオープンでクライアント アプリケーションが機能しているかどうかを判断するだけでなく、アプリケーション レベルのキープアライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がないことが定義済みの期間続いた後にキープアライブ メッセージを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。

Domains のアプリケーション レベルのキープアライブのコンフィグレーション

Domains の Oracle Tuxedo アプリケーション レベル キープアライブ オプションは KEEPALIVE 名前です。このパラメータとそれに伴う KEEPALIVEWAIT というパラメータが、DMCONFIG ファイルの DM_TDOMAIN セクションのオプション パラメータとして追加されています。これらのパラメータを使用すると、Domains のアプリケーション レベルのキープアライブ オプションをローカル ドメインまたはリモート ドメイン単位でコンフィグレーションできます。

DMKEEPALIVE パラメータでは、Domains 接続でトラフィックを受信することなくローカル TDomain ゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイからアプリケーション レベル キープアライブ要求メッセージが送信されます。DMKEEPALIVE の有効な値は次のとおりです。

DMKEEPALIVE のデフォルト設定は 0 です。

DMKEEPALIVEWAIT パラメータでは、送信したキープアライブ メッセージに対する肯定応答を受信することなくローカル TDomain ゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイはリモート TDomain ゲートウェイとの接続が切れているものと判断し、その接続に関連付けられたすべてのリソースを解放します。DMKEEPALIVEWAIT の最小値は 0、最大値は 2147483647 ミリ秒で、現在は Domains ソフトウェアによって最近の秒に丸められます。DMKEEPALIVEWAIT のデフォルト設定は 0 です。

DMKEEPALIVE と DMKEEPALIVEWAIT の使い方を明確にするために、次の Domains アプリケーション レベル キープアライブ コンフィグレーションを考えてください。

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
        DMKEEPALIVE=1010
        DMKEEPALIVEWAIT=20
REMOT1  NWADDR=“//newyork.acme.com:65431”
        DMKEEPALIVE=4000
        DMKEEPALIVEWAIT=3000
REMOT2  NWADDR=“//philly.acme.com:65431”
        DMKEEPALIVE=-1

リモート ドメイン アクセス ポイントに指定されたキープアライブ コンフィグレーションは、ローカル ドメイン アクセス ポイントに指定されたキープアライブ コンフィグレーションに優先します。このため、前の例のアプリケーション レベルのキープアライブ コンフィグレーションは次のようになります。

LOCAL1 から REMOT1 - キープアライブ タイマー = 4 秒、待機タイマー = 3 秒
LOCAL1 から REMOT2 - キープアライブ タイマー = 2 秒、待機タイマー = 1 秒

ローカル ドメイン アクセス ポイントの場合、DMKEEPALIVE パラメータに次のいずれかの値を指定できます。

リモート ドメイン アクセス ポイントの場合、DMKEEPALIVE パラメータに次のいずれかの値を指定できます。

リモート ドメイン アクセス ポイントで -1 を指定するか、キープアライブ コンフィグレーションを指定しないと、デフォルトでローカルのアプリケーション レベルのキープアライブ コンフィグレーションが使用されます。

Domains 接続の接続ポリシーが ON_STARTUP であり、その接続でアプリケーション レベルのキープアライブの障害が発生した場合は、自動的な接続再試行プロセスによって接続の再確立が行われます。接続再試行プロセスの詳細については、「接続再試行プロセスの使用方法」を参照してください。

旧リリースの Oracle Tuxedo とのキープアライブの互換性

ドメインの TCP レベルのキープアライブは、Oracle Tuxedo 8.0 以前のリリースと互換性があります。Domains の TCP レベルのキープアライブはネットワーク トランスポート (TCP) 層で実行されるので、TCP 接続の反対側の Oracle Tuxedo ソフトウェアはどのリリースの Oracle Tuxedo でもかまいません。

ドメインのアプリケーション レベルのキープアライブは、Oracle Tuxedo 8.0 以前のリリースと互換性がありません。TCP 接続の反対側の Oracle Tuxedo ソフトウェアは、Oracle Tuxedo 8.1 以降でないとアプリケーション レベル キープアライブ メッセージを理解できません。旧リリースの Oracle Tuxedo ソフトウェアが動作している TDomain ゲートウェイに接続した場合、TDomain ゲートウェイはアプリケーション レベルのキープアライブ メッセージを送信しません。代わりに、リモート ドメインで旧リリースの Oracle Tuxedo ソフトウェアが動作しており、Domains のアプリケーション レベルのキープアライブがサポートされていないことを示す警告メッセージがローカルのユーザ ログ (ULOG) に記録されます。

Domains 環境のコンフィグレーション

次のリストは、TDomain ゲートウェイ タイプ用に Domains 環境をコンフィグレーションするためのタスクをまとめたものです。

Domains ATMI 環境をコンフィグレーションする詳しい例については、「ATMI Domains の計画とコンフィグレーション」を参照してください。Domains CORBA 環境をコンフィグレーションする詳しい例については、「CORBA Domains の計画とコンフィグレーション」を参照してください。

移行を考慮した Domains 環境のコンフィグレーション

次に示すサンプルの UBBCONFIG ファイルと DMCONFIG ファイルを参照すると、Domains の移行を考慮して Oracle Tuxedo アプリケーションをコンフィグレーションする方法がわかります。Domains の移行に特に重要なエントリは太字で示されています。

*RESOURCES
IPCKEY    76666
MASTER    SITE1,SITE2
OPTIONS   LAN,MIGRATE
MODEL     MP
#
*MACHINES
mach1     LMID=SITE1
          TUXDIR=“/home/rsmith/tuxroot”
          APPDIR=“/home/rsmith/bankapp”
          TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach2     LMID=SITE2
          TUXDIR=“/home/rsmith/tuxroot”
          APPDIR=“/home/rsmith/bankapp”
          TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach3     LMID=SITE3
          TUXDIR=“/home/rsmith/tuxroot”
          APPDIR=“/home/rsmith/bankapp”
          TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
#
*GROUPS
DMADMGRP  LMID=“SITE1,SITE3” GRPNO=1
GWTGROUP  LMID=“SITE2,SITE3” GRPNO=2
.
.
.
*NETWORK
SITE1     NADDR=“//albany.acme.com:4065”
          NLSADDR=“//albany.acme.com:4068”
SITE2     NADDR=“//auburn.acme.com:4065”
          NLSADDR=“//auburn.acme.com:4068”
SITE3     NADDR=“//boston.acme.com:4065”
          NLSADDR=“//boston.acme.com:4068”

#
*SERVERS
DMADM     SRVGRP=DMADMGRP
          SRVID=1001
          REPLYQ=N
          RESTART=Y
          GRACE=0
GWADM     SRVGRP=GWTGROUP
          SRVID=1002
          REPLYQ=N
          RESTART=Y
          GRACE=0
GWTDOMAIN SRVGRP=GWTGROUP
          SRVID=1003
          RQADDR=“GWTGROUP”
          REPLYQ=N
          RESTART=Y
          GRACE=0
.
.
.

*DM_LOCAL
LOCAL1    GWGRP=GWTGROUP
          TYPE=TDOMAIN
          ACCESSPOINTID=“BA.CENTRAL01”
          BLOCKTIME=30
          CONNECTION_POLICY=ON_STARTUP
          MAXRETRY=5
          RETRY_INTERVAL=100

*DM_REMOTE
REMOT1    TYPE=TDOMAIN
          ACCESSPOINTID=“BA.BANK01”
REMOT2    TYPE=TDOMAIN
          ACCESSPOINTID=“BA.BANK02”

*DM_EXPORT
LTOLOWER  LACCESSPOINT=LOCAL1
          CONV=N
          RNAME=“TOLOWER”

*DM_IMPORT
RTOUPPER  AUTOTRAN=N
          RACCESSPOINT=REMOT1
          LACCESSPOINT=LOCAL1
          CONV=N
          RNAME=”TOUPPER”

*DM_TDOMAIN
LOCAL1  NWADDR=“//albany.acme.com:4051”
LOCAL1  NWADDR=“//boston.acme.com:4051”
REMOT1  NWADDR=“//newyork.acme.com:65431”
REMOT2  NWADDR=“//philly.acme.com:65431”

サンプルのコンフィグレーション ファイルで、DMADM サーバと TDomain ゲートウェイ グループ サーバは SITE3 マシンに移行するように設定されています。DMADM の移行については、次のタスクを終えた後に管理者が SITE3 マシンで DMADM サーバ プロセスをアクティブにします。

TDomain ゲートウェイ グループの移行については、管理者が SITE3 マシンで GWADM サーバ プロセスと GWTDOMAIN サーバ プロセスをアクティブにします。その時点で、LOCAL1 アクセス ポイントと関連付けられたコンフィグレーションと責任は、ネットワーク アドレス boston.acme.com:4051 で接続要求をリスンする新しい GWTDOMAIN サーバ プロセスによって処理されます。

DMADM サーバの移行

DMADM を新しいマシンに移行するには、次の手順に従います。

TDomain ゲートウェイ グループの移行

トランザクションが Domains コンフィグレーションで使用されている場合、TDomain ゲートウェイ グループは同じ種類のマシン間でのみ移行できます。

TDomain ゲートウェイ グループを移行するには、次の手順に従います。

個々のサーバ プロセスをアクティブにする手段

個々の Oracle Tuxedo サーバ プロセスは、次のいずれかの手段でアクティブにできます。

アプリケーションの移行タスクについては、『Oracle Tuxedo アプリケーション実行時の管理』の「アプリケーションの移行」を参照してください。