1. ドメイン・コンポーネント・ユーザーズ・ガイド
  2. Domainsについて

1 Domainsについて

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

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

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

図1-1 Oracle Tuxedo Domainsコンポーネントを使用したドメイン間通信


Oracle Tuxedo Domainsコンポーネントを使用したドメイン間通信の図

親トピック: Domainsについて

1.1.1 ドメイン間の相互運用性

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

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

親トピック: Oracle TuxedoのDomainsコンポーネントとは

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

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

  • Oracle Tuxedo TDomainゲートウェイ(GWTDOMAINサーバー・プロセスで実装) - ネットワーク・プロトコルTCP/IP上で機能する特別に設計されたTPプロトコルを使用して、複数のOracle Tuxedoドメイン間での相互運用性を実現します。WebLogic Tuxedo Connector (WTC)ゲートウェイ(Oracle WebLogic Serverコンポーネント)と連係することで、Oracle Tuxedo TDomainゲートウェイはTuxedoドメインとWebLogic Serverアプリケーションの間でも相互運用性を実現できます。
  • Oracle TMA TCPゲートウェイ(GWIDOMAINサーバー・プロセスで実装) - ネットワーク・プロトコルTCP/IP経由でOracle Tuxedoドメインと、IBM OS/390顧客情報管理システム(CICS)および情報管理システム(IMS)の下で動作するアプリケーションの間の相互運用性を実現します。ゲートウェイでは非トランザクション型のタスクのみサポートされます。
  • Oracle TMA SNAゲートウェイ(GWSNAXサーバー・プロセスで実装) - システム・ネットワーク体系(SNA)拡張プログラム間通信機能(APPC)または共通プログラミング・インタフェース・コミュニケーション(CPI-C)がサポートされるプラットフォーム(IBM OS/400、OS/390 CICSおよびIMSシステム、およびVSE/CICS)で動作するOracle Tuxedoドメインとアプリケーション間の相互運用性を実現します。ゲートウェイでは複数のSNAネットワークとの通信がサポートされます。

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

Oracle TMAゲートウェイの詳細は、Oracle Tuxedo Mainframe Adapterのドキュメントを参照してください。

親トピック: Oracle TuxedoのDomainsコンポーネントとは

1.2 Domains構成の例

次の図は、4つのドメインがあり、そのうちの3つはOracle TuxedoドメインであるサンプルDomains構成を示しています。

図1-2 銀行業務のDomains構成の例


銀行業務のDomains構成の例の図

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

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

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

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

親トピック: Domainsについて

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

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

  • マルチネットワークのサポート - ゲートウェイは、TCP/IP、IPX/SPX、OSIなど、様々なネットワーク・プロトコルを介して他のドメインと通信できます。ただし、ゲートウェイは、そのリンク先であるネットワーク・ライブラリの機能に制限を受けます。つまり、ゲートウェイは通常、1種類のネットワークをサポートします。たとえば、Oracle Tuxedo TDomainゲートウェイではTCP/IPのみサポートされます。
  • バイパス・ドメイン・モデル — 複数のドメインにまたがるATMIアプリケーションは、GWTDOMAINを使用せずに、RDMAを直接経由して相互に通信できます。

    ノート:

    バイパス・ドメイン・モデルは、Exalogic上のLinuxプラットフォームのみをサポートします。
  • マルチドメイン間の対話 - ゲートウェイは、複数のドメインと通信できます。
  • トランザクション管理 - ゲートウェイにより、ATMIアプリケーションはトランザクション内で他のドメインと相互運用できます。ゲートウェイは、ドメイン間で行われるトランザクションのコミットまたはロールバックを調整します。
  • 複数のメッセージング・モデル - ゲートウェイは、次のATMIメッセージング・モデルをサポートしています。既存のOracle Tuxedoアプリケーションを修正する必要はありません。
    • リクエスト/レスポンス型モデル - Oracle Tuxedoシステムを使用するATMIアプリケーションは、他のドメインで動作するアプリケーションのサービスをリクエストできます。
    • 会話型モデル - ATMIアプリケーションは、他のドメインで動作しているプログラムと会話型の通信を行うことができます。
    • キューの処理モデル - Oracle Tuxedoシステムを使用するATMIアプリケーションは、ほかのドメインのキューにデータを保存できます。
  • 型付きバッファのサポート - ゲートウェイは、Oracle Tuxedo ATMIアプリケーションで定義されるすべてのバッファ型に対して、エンコードまたはデコードの操作を実行できます。

親トピック: Domainsについて

1.3.1 ローカル・ドメインとリモート・ドメイン間でのリクエスト/レスポンス型の通信

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

  • tpinit(3c)/tpterm(3c) - Oracle Tuxedoアプリケーションは、リモート・ドメインの環境にはアタッチされません。リモート・ドメインへのアクセスは、ドメイン・ゲートウェイを使用して行われます。したがって、リモート・アプリケーションにtpinit()/tpterm()シーケンスは必要ありません。
  • tpadvertise(3c)およびtpunadvertise(3c) - Domainsではこれらの関数はサポートされていません。ドメイン・ゲートウェイで、ドメイン間の動的なサービスの通知がサポートされていないからです。
  • tpnotify(3c)およびtpbroadcast(3c) - Domainsでは、これらの関数によって提供される、非請求の通信パラダイムはサポートされません。
  • イベントのポスト(tppost(3c))およびイベントの通知(tpsubscribe(3c)) - ドメイン間では、これらの関数はサポートされません。

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

図1-3 tpforwardを使用してリモート・サービスにリクエストを送信する


tpforwardを使用してリモート・サービスにリクエストを送信する場合の図

Oracle Tuxedoリクエスト/レスポンス型モデルの詳細は、『Oracle Tuxedo ATMIの紹介』のリクエスト/レスポンス型通信に関する項を参照してください。

親トピック: ドメイン・ゲートウェイでサポートされる機能

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

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

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

ノート:

接続指向型のATMI関数では、半二重会話を使用できます。会話サービスではtpforward(3c)を使用できません。

Oracle Tuxedo会話型モデルの詳細は、『Oracle Tuxedo ATMIの紹介』の会話型通信に関する項を参照してください。

親トピック: ドメイン・ゲートウェイでサポートされる機能

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

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

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

Oracle Tuxedoキューの処理モデルの詳細は、『Oracle Tuxedo ATMIの紹介』のメッセージ・キューイング通信に関する項を参照してください。

親トピック: ドメイン・ゲートウェイでサポートされる機能

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

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

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

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

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

  • データ依存型ルーティングは、指定した条件に一致するデータ内のフィールドに基づいて実行されます。したがって、ドメイン・ゲートウェイでは、データを適切なリモート・ドメインにルーティングするためにエンコードされたデータをデコードする必要があります。
  • ドメインで実装または使用されるネットワーク・プロトコルに応じて、異なるデータ形式が使用される可能性があります。したがって、ドメイン・ゲートウェイではエンコードされたデータをデコードしてどのデータ形式が使用されているのかを判別する必要があります。

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

型付きバッファおよびエンコード/デコード操作の詳細は、『Oracle Tuxedo ATMIの紹介』の型付きバッファに関する項を参照してください。

親トピック: ドメイン・ゲートウェイでサポートされる機能

1.4 Oracle Tuxedo Domainsのアーキテクチャ

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

親トピック: Domainsについて

1.4.1 Domains構成ファイル

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

テキスト形式のDomains構成ファイルはDMCONFIGファイルと呼ばれますが、任意の名前を付けることもできます(ただし、そのファイルの内容が『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「DMCONFIG(5)」リファレンス・ページで説明されている形式に準拠している場合にかぎります)。バイナリ形式のDomains構成ファイルは、BDMCONFIGと呼ばれます。DMCONFIGファイルの詳細は、「Domains構成ファイルの理解」を参照してください。

親トピック: Oracle Tuxedo Domainsのアーキテクチャ

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

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

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

図1-4 ゲートウェイを介した双方向通信


ゲートウェイを介した双方向通信の図

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

親トピック: Oracle Tuxedo Domainsのアーキテクチャ

1.4.3 Domains管理サーバー

次の図は、Domains構成を管理するために使用されるOracle Tuxedo Domains管理サーバーを示しています。

図1-5 Domains管理サーバー


Domains管理サーバーの図

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

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

親トピック: Oracle Tuxedo Domainsのアーキテクチャ

1.4.3.1 GWADMサーバー

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

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

親トピック: Domains管理サーバー

1.4.3.2 DMADMサーバー

DMADM(5)サーバーは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、GWADMサーバーでサーバー初期化プロシージャの一部としてリクエストされます。登録サービスは、リクエスト側のゲートウェイ・グループで必要な構成情報をダウンロードします。DMADMサーバーは、登録済のゲートウェイ・グループのリストを保守し、ドメイン構成ファイル(BDMCONFIG)が変更されると、変更内容をこれらのゲートウェイ・グループに伝播します。

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

親トピック: Domains管理サーバー

1.4.4 Domains管理ツール

次のDomains管理ツールは、Domains構成の設定と管理のためにOracle Tuxedoシステムによって提供されます。

  • dmloadcf(1) - DMCONFIGファイルを読み取り、構文をチェックし、バイナリ形式のBDMCONFIG構成ファイルをロードします。
  • dmunloadcf(1) - BDMCONFIG構成ファイルをバイナリ形式からテキスト形式に変換します。
  • dmadmin(1) - Oracle Tuxedoの管理者がTuxedoドメインの実行時にBDMCONFIGファイルを更新できるようにします。

次の図は、Domains管理ツールとDomainsのテキスト形式およびバイナリ形式の構成ファイルの関係を示しています。dmadminユーティリティを使用する管理は、DMADMサーバーによって通知されるDMADMINサービスを通じて行います。

図1-6 Domains管理ツールとファイルの関係


Domains管理ツールとファイルの関係の図

親トピック: Oracle Tuxedo Domainsのアーキテクチャ

1.4.4.1 dmloadcfコマンド

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

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

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

dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib

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

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

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

親トピック: Domains管理ツール

1.4.4.2 dmunloadcfコマンド

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

親トピック: Domains管理ツール

1.4.4.3 dmadminコマンド

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

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

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

親トピック: Domains管理ツール

1.5 Domains構成ファイルの理解

Domains構成に関与する各Oracle Tuxedoドメインには、ドメイン間パラメータの定義される構成ファイルがあります。テキスト形式の構成ファイルはDMCONFIGと呼ばれますが、構成ファイルの内容がDMCONFIG(5)のリファレンス・ページで説明する形式に従っているかぎり、任意の名前を付けることができます。典型的な構成ファイル名は、文字列dmで始まり、その後にファイル名dmconfigのconfigのようなニーモニック文字列が続きます。

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

関連項目:

『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG(5)に関する項

親トピック: Domainsについて

1.5.1 DMCONFIGファイルの場所

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

ノート:

Oracle Tuxedoドメインのマスター・マシンにはドメインのUBBCONFIGファイルが含まれ、UBBCONFIGファイルのRESOURCESセクションでマスター・マシンとして指定されます。Tuxedoドメインは、マスター・マシンを使用して起動、停止、および管理します。

親トピック: Domains構成ファイルの理解

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

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

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

親トピック: Domains構成ファイルの理解

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

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

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

  • DM_LOCAL (DM_LOCAL_DOMAINSとも呼ばれる)
  • DM_REMOTE (DM_REMOTE_DOMAINSとも呼ばれる)
  • DM_EXPORT (DM_LOCAL_SERVICESとも呼ばれる)
  • DM_IMPORT (DM_REMOTE_SERVICESとも呼ばれる)
  • DM_RESOURCES
  • DM_ROUTING
  • DM_ACCESS_CONTROL
  • DM_domtype (domtypeは、TDOMAIN、またはSNACRM + SNALINKS + SNASTACKS)
  • DM_LOCALセクションは、DM_REMOTEセクションの前になければなりません。

Domains構成の管理者は、以上のセクションを以下の目的で使用します。

  • リモート・ドメインのアプリケーション・クライアントがローカル・ドメインのサービスにアクセスするためのローカル・ドメイン・アクセス・ポイントを定義します。
  • 各ローカル・ドメイン・アクセス・ポイントを通じて利用可能なローカル・サービスを指定します。
  • ローカル・ドメインのアプリケーション・クライアントがリモート・ドメインのサービスにアクセスするためのリモート・ドメイン・アクセス・ポイントを定義します。
  • 各リモート・ドメイン・アクセス・ポイントを通じて利用可能なリモート・サービスを指定します。
  • ローカル・ドメイン・アクセス・ポイントおよびリモート・ドメイン・アクセス・ポイントを特定のドメイン・ゲートウェイ・グループ(TDOMAINなど)およびネットワーク・アドレスにマップします。

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

図1-7 2つのOracle Tuxedoドメインで共有されるサービスを確定する - 例


2つのOracle Tuxedoドメインで共有されるサービスを確定する - 例の図

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

次の表に、DMCONFIGファイルの各セクションの説明を示します。

表1-1 DMCONFIGファイルのセクション(シート1/4)

セクション 目的
DM_LOCAL (DM_LOCAL_DOMAINSとも呼ばれる) 1つ以上のローカル・ドメイン・アクセス・ポイント識別子(ローカル・ドメインまたはLDOMとも呼ばれる)を定義します。定義した各ローカル・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ(TDOMAINなど)を指定し、アクセス・ポイントを通じて利用できるローカル・サービスをDM_EXPORTセクションで指定します。ローカル・ドメイン・アクセス・ポイントを通じて利用可能なローカル・サービスは、1つ以上のリモート・ドメインのクライアントから利用できます。このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(TDOMAIN、SNAX)について1つずつ、複数のローカル・ドメイン・アクセス・ポイントを定義できます。

ローカル・ドメイン・アクセス・ポイントは、ゲートウェイ・グループごとに1つのみ定義できます。ドメイン・ゲートウェイ・グループは、GWADMサーバー・プロセスとドメイン・ゲートウェイ・サーバー・プロセス(GWTDOMAIN、TDomainゲートウェイ・サーバーなど)で構成されます。

次に、ローカル・ドメイン・アクセス・ポイントのエントリ例を示します。

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

ノート:

ACCESSPOINTIDパラメータのかわりにDOMAINIDを使用することもできます。
DM_REMOTE (DM_REMOTE_DOMAINSとも呼ばれる) 1つ以上のリモート・ドメイン・アクセス・ポイント識別子(リモート・ドメインまたはRDOMとも呼ばれる)を定義します。定義した各リモート・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ(TDOMAINなど)を指定し、アクセス・ポイントを通じて利用できるリモート・サービスをDM_IMPORTセクションで指定します。リモート・ドメイン・アクセス・ポイントを通じて利用可能なリモート・サービスは、ローカル・ドメインのクライアントから利用できます。このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(TDOMAIN、SNAX)について1つ以上、複数のリモート・ドメイン・アクセス・ポイントを定義できます。次に、リモート・ドメイン・アクセス・ポイントのエントリ例を示します。
*DM_REMOTE
REMOT1  TYPE=TDOMAIN
        ACCESSPOINTID=“BA.BANK01”
REMOT2  TYPE=TDOMAIN
        ACCESSPOINTID=“BA.BANK02”

ノート:

ACCESSPOINTIDパラメータのかわりにDOMAINIDを使用することもできます。
DM_EXPORT (DM_LOCAL_SERVICESとも呼ばれる) DM_LOCALセクションで定義されたローカル・ドメイン・アクセス・ポイントを通じて1つ以上のリモート・ドメインにエクスポートされるローカル・サービスを定義します。ローカル・ドメイン・アクセス・ポイントで指定されたサービスのみ、1つ以上のリモート・ドメインのクライアントから利用できます。つまり、このセクションでサービスを指定すると、ローカル・サービスへのリモート・クライアントのアクセスが制限されます。DM_EXPORTセクションがないか、あっても何も指定されていない場合は、ローカル・ドメインで通知されたすべてのサービスがリモート・ドメインから利用可能になります。リモート・ドメインから利用可能になったローカル・サービスは、ローカルUBBCONFIGファイルのSERVICESセクションからそのプロパティの多くを継承します。継承されるプロパティとして、LOAD、PRIO、AUTOTRAN、ROUTING、BUFTYPE、TRANTIMEがあります。次に、リモート・ドメインから利用可能になったローカル・サービスの例を示します。 
*DM_EXPORT
LTOLOWER  LACCESSPOINT=LOCAL1
          CONV=N
          RNAME=“TOLOWER”
          ACL=branch

ノート:

LACCESSPOINTパラメータのかわりにLDOMを使用することもできます。
DM_IMPORT (DM_REMOTE_SERVICESとも呼ばれる) DM_REMOTEセクションで定義された1つ以上のリモート・ドメイン・アクセス・ポイントを通じてインポートされ、1つ以上のローカル・ドメイン・アクセス・ポイントを通じてローカル・ドメインから利用可能なリモート・サービスを指定します。DM_IMPORTセクションが存在しない場合、または存在しても空の場合、リモート・サービスはローカル・ドメインで使用できません。ローカル・ドメインから利用可能になったリモートOracle Tuxedoサービスは、リモートUBBCONFIGファイルのSERVICESセクションからそのプロパティの多くを継承します。継承されるプロパティとして、LOAD、PRIO、AUTOTRAN、ROUTING、BUFTYPE、TRANTIMEがあります。次に、ローカル・ドメインから利用可能になったリモート・サービスの例を示します。
*DM_IMPORT
RTOUPPER  AUTOTRAN=N
          RACCESSPOINT=REMOT1
          LACCESSPOINT=LOCAL1
          CONV=N
          RNAME=“TOUPPER”

ノート:

RACCESSPOINTパラメータのかわりにRDOM、LACCESSPOINTパラメータのかわりにLDOMを使用することもできます。
DM_RESOURCES グローバルのDomains構成情報、具体的にはユーザー指定の構成バージョン文字列を指定します。このセクションでは、VERSION=stringが唯一のパラメータです。stringは、現在のDMCONFIGファイルのバージョン番号を入力できるフィールドです。このフィールドはソフトウェアによってチェックされません。
DM_ROUTING 同じサービスを提供する複数のリモート・ドメインの1つにローカルのサービス・リクエストをルーティングするためのデータ依存型ルーティング基準を指定します。例については、「Domainsデータ依存型ルーティングの指定」を参照してください。
DM_ACCESS_CONTROL 1つ以上のアクセス制御リスト(ACL)の名前を指定し、1つ以上のリモート・ドメイン・アクセス・ポイントを指定された各ACL名に関連付けます。ACL=ACL_NAMEを設定してDM_EXPORTセクションでACLパラメータを使用すると、特定のローカル・ドメイン・アクセス・ポイントを通じてエクスポートされるローカル・サービスへのアクセスをACL_NAMEと関連付けられたリモート・ドメイン・アクセス・ポイントのみに制限できます。次に、ACLエントリの例を示します。 
*DM_ACCESS_CONTROL
branch ACLIST=REMOT1
DM_domtype 特定のDomains構成に必要なパラメータを定義します。現時点で、domtypeの値としては、TDOMAIN、またはSNACRM + SNALINKS + SNASTACKSを指定できます。各ドメイン・タイプは、別々のセクションで指定する必要があります。DM_TDOMAINセクションでは、ローカルまたはリモート・ドメイン・アクセス・ポイントのTDomain固有のネットワーク構成を定義します。1つ以上のWebLogic Serverアプリケーションと関連付けられた1つ以上のリモート・ドメイン・アクセス・ポイントのネットワーク構成を定義して、アプリケーションでTuxedo ATMIサーバーとWebLogic Server Enterprise JavaBean (EJB)サーバーを結合することもできます。詳細は、『Oracle Tuxedo相互運用性』を参照してください。DM_TDOMAINセクションでは、リモート・ドメインからローカル・サービスへのリクエストがローカル・ドメイン・アクセス・ポイントを通じて受け付けられる場合に、そのローカル・ドメイン・アクセス・ポイントごとにエントリが必要です。このセクションで指定された各ローカル・ドメイン・アクセス・ポイントについて、受信接続のリスニングに使用するネットワーク・アドレスを指定する必要があります。DM_TDOMAINセクションでは、ローカル・ドメインからリモート・サービスへのリクエストがリモート・ドメイン・アクセス・ポイントを通じて受け付けられる場合に、そのリモート・ドメイン・アクセス・ポイントごとにエントリが必要です。このセクションで指定された各リモート・ドメイン・アクセス・ポイントについて、そのリモート・ドメイン・アクセス・ポイントへの接続時に使用する接続先ネットワーク・アドレスを指定する必要があります。Tuxedoのリリース9.0以降では、DM_TDOMAINセクションに、特定のローカル・ドメイン・アクセス・ポイントとリモート・ドメイン・アクセス・ポイント間のTDomainセッションごとにエントリを定義できます。このセクションで指定された各TDomainセッションについて、そのTDomainセッションへの接続時に使用する接続先ネットワーク・アドレスを指定する必要があります。Domainsのリンク・レベルのフェイルオーバーが使用されている場合は、リモート・ドメイン・アクセス・ポイントまたはTDomainセッションの複数の接続先ネットワーク・アドレスを指定してゲートウェイのミラーリングを実装できます。ゲートウェイのミラーリングの例については、「Domainsリンク・レベルのフェイルオーバーの構成」を参照してください。DM_SNACRM、DM_SNALINKSおよびDM_SNASTACKSセクションの詳細は、Oracle Tuxedo Mainframe Adapters 12cリリース2 (12.2.2)を参照してください。

DMCONFIGファイルの詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG(5)およびDM_MIB(5)のリファレンス・ページを参照してください。

親トピック: Domains構成ファイルの理解

1.5.4 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ファイルの旧用語と新用語の対応を示します。

表1-2 DMCONFIGファイルの旧用語と新用語の対応

旧用語 新用語
セクション名 パラメータ名 セクション名 パラメータ名
DM_LOCAL_DOMAINS   DM_LOCAL  
DM_REMOTE_DOMAINS   DM_REMOTE  
  DOMAINID   ACCESSPOINTID
  MAXRDOM   MAXACCESSPOINT
  MAXRDTRAN   MAXRAPTRAN
DM_LOCAL_SERVICES   DM_EXPORT  
DM_REMOTE_SERVICES   DM_IMPORT  
  LDOM   LACCESSPOINT
  RDOM   RACCESSPOINT

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

prompt> dmunloadcf -c > dmconfig_prev

親トピック: Domains構成ファイルの理解

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

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

  • FML
  • FML32
  • VIEW
  • VIEW32
  • X_C_TYPE
  • X_COMMON
  • XML

次の例では、リモート・サービスの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フィールドの有効な値は次のとおりです。

  • REMOT1アクセス・ポイントの場合、有効な値の範囲はREMOT1と関連付けられたマシンで許可される最小値から1000までです。
  • REMOT2アクセス・ポイントの場合、有効な値の範囲は1001から3000までです。

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

親トピック: Domainsについて

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

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

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

親トピック: Domainsについて

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

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

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

  • AUTOTRAN - AUTOTRANがサービスに対して有効になっている状態で、まだトランザクションにないサービスに対するサービス・リクエストが受信されると、ローカルのOracle Tuxedoシステムによって自動的にそのサービスのトランザクションが開始されます。
  • TRANTIME - サービスに対して自動的に開始されたトランザクションのトランザクション・タイムアウト値(秒単位)。トランザクションでこのタイムアウト値を過ぎると、そのトランザクションの影響を受けるOracle Tuxedoノード(マシン)によってTMSタイムアウト・メッセージが生成されます。

同様に、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パラメータを認識しないノードが影響を受ける場合、またはMAXTRANTIMEパラメータを認識するがパラメータが設定されていない場合、トランザクションのタイムアウト値はTRANTIME、またはトランザクションを開始したtpbegin()呼出しで渡されたタイムアウト値によって決まります。TRANTIMEまたはtpbegin()のタイムアウト値を超えると、トランザクションの影響を受けるすべてのOracle Tuxedoノード(トランザクションを開始したノードも含む)はTMSタイムアウト・メッセージを生成します。
  • ドメイン間トランザクションがMAXTRANTIMEパラメータを認識するノードに影響を及ぼし、そのノードに対してパラメータが設定されている場合、トランザクションのタイムアウト値はそのノードのMAXTRANTIME値を超えない値にまで削減されます。

    TRANTIMEまたはtpbegin()タイムアウト値がMAXTRANTIME以下である場合、トランザクション処理は前に説明したシナリオになります。

    TRANTIMEまたはtpbegin()タイムアウト値がMAXTRANTIMEより大きい場合、トランザクションのタイムアウト値は影響を受けるノードによってMAXTRANTIMEに削減されます。MAXTRANTIMEタイムアウト値を超えると、影響を受けるノードはTMSタイムアウト・メッセージを生成します。

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

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

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

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

1.8 Domainsの接続ポリシーの指定

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

  • ON_DEMAND (デフォルト) - リモート・サービスへのクライアント・リクエストまたは管理接続コマンドのいずれかによってリクエストされたときに接続します。この接続ポリシーにおける接続の確立方法は次のとおりです。
    • クライアント・リクエスト
    • 手動によるdmadmin(1) connectコマンドの実行
    • 受信接続
  • ON_STARTUP - ゲートウェイ・サーバーの初期化(起動)時に接続します。この接続ポリシーにおける接続の確立方法は次のとおりです。
    • Oracle Tuxedoアプリケーション起動時の自動接続
    • 手動によるdmadmin(1) connectコマンドの実行
    • 受信接続
  • INCOMING_ONLY - 受信接続を受け入れますが、接続を自動的に開始しません。この接続ポリシーにおける接続の確立方法は次のとおりです。
    • 手動によるdmadmin(1) connectコマンドの実行
    • 受信接続

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

親トピック: Domainsについて

1.8.1 接続ポリシーの構成方法

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

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

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

親トピック: Domainsの接続ポリシーの指定

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

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セクションでローカル・ドメイン・アクセス・ポイントに次のいずれかの接続ポリシー値を指定できます。

  • ON_DEMAND
  • ON_STARTUP
  • INCOMING_ONLY

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

ノート:

DM_TDOMAINセクションでグローバル接続ポリシーを指定する場合は、DM_LOCALセクションでグローバル接続ポリシーを指定しないでください。

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

  • LOCAL(デフォルト)
  • ON_DEMAND
  • ON_STARTUP
  • INCOMING_ONLY

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

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

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

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

TDomainセッション単位の接続ポリシーを開始するには、次を実行する必要があります:

  • 特定のローカル・ドメイン・アクセス・ポイントとリモート・ドメイン・アクセス・ポイント間でTDomainセッションを確立します。これにより、セッション接続アクセスを、1つ以上のローカルおよびリモート・ドメイン・ゲートウェイに制限できるようになります。

    TDomainセッションごとに使用するパラメータと属性を定義するために、1つまたは複数のレコード・エントリを作成できます。

  • 使用するconnection_policyパラメータ属性を指定します。TDomainセッションの接続ポリシーを指定しない場合、そのセッションの接続ポリシー属性はデフォルトでLOCALになります。
1.8.1.2.1 TDomainセッションの作成

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

  • FAILOVERSEQ: TDomainセッション・フェイルオーバー・シーケンスとプライマリ・レコードを指定します。
  • LACCESSPOINT (LDOM): DM_LOCALセクションで指定されたローカル・ドメイン・アクセス・ポイントの名前を指定します。

他のTDomainセッション・パラメータおよび属性(SECURITY、DMKEEPALIVE)も指定できます。FAILOVERSEQ、LACCESSPOINTおよびその他のTDomainパラメータおよび属性の詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDM_TDOMAINセクションのオプション・パラメータに関する項を参照してください。

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

次のリストに、TDomainセッション単位の接続ポリシーを作成するために使用するFAILOVERSEQ、LACCESSPOINTおよびCONNECTION_POLICYパラメータを示します:

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

*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つのレコードから構成されています。

表1-3 TDomainセッション

レコード ドメイン・セッション 接続ポリシー 接続/フェイルオーバー・シーケンス セッション階層
4 [LOCAL,REMOT1] ON_STARTUP 1番目 プライマリ
7 [LOCAL,REMOT1] Ignored 2番目 セカンダリ
5 [LOCAL2,REMOT1] INCOMING_ONLY 1番目 プライマリ
6 [LOCAL2,REMOT2] ON_DEMAND 1番目 プライマリ
  • レコード4は、FAILOVERSEQがレコード7より小さいので、TDomainセッションLOCAL1,REMOT1のプライマリ・レコードです。このTDomainセッションの接続ポリシーはON_STARTUPで、128ビットのリンク・レベル暗号化セキュリティ・ポリシーを必要とします。このレコードへの接続が失敗した場合、そのセカンダリ/バックアップ・レコードであるレコード7への接続が試行されます。
  • レコード7は、FAILOVERSEQがレコード4より大きいので、TDomainセッションLOCAL1,REMOT1のセカンダリ/バックアップ・レコードです。

    このセッションのプライマリ・レコードはレコード4なので、レコード7の接続およびセキュリティ・ポリシーは無視されます。レコード7には、セカンダリ/バックアップ・フェイルオーバー・レコードがありません。レコード7への接続が失敗した場合、RETRY_INTERVALに従ってMAXRETRYに達するまでレコード4への接続が試行されます。RETRY_INTERVALの詳細は、「接続再試行プロセスの使用方法」を参照してください。

  • レコード5は、TDomainセッションLOCAL2,REMOT1のプライマリ・レコードです。このTDomainセッションの接続ポリシーはINCOMING_ONLYです。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。
  • レコード6は、TDomainセッションLOCAL2,REMOT2のプライマリ・レコードです。このセッションの接続ポリシーはON_DEMANDです。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。ローカル・アクセス・ポイントLOCAL2は、2つのTDomainセッション(レコード5のREMOT1とREMOT2)に接続します。

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

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

  • dmloadcf -yを使用して、DMCONFIGファイルをコンパイルしてBDMCONFIGファイルに変換します。
  • tmboot -yを使用してサーバーを起動します。
1.8.1.2.3 TDomainセッションでの正規表現の使い方

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

ノート:

DM_TDOMAINは、DMCONFIGファイルの中でLACCESSPOINTに正規表現を指定できる唯一のセクションです。

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

DMCONFIGファイルと正規表現のリスト 

*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ファイルの出力は次のリストのようになります。

リスト1-3 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
1.8.1.2.4 DM_MIBを使用したTDomainセッション情報の指定とリクエスト

DM_MIBを使用してTDomainセッション情報を指定およびリクエストすると、BDMCONFIGファイルが直接修正されます。元のDMCONFIGファイルは修正されません。DM_MIBの詳細。

ノート:

dmunloadcf >DMCONFIGを使用すると、BDMCONFIGファイルを解析してDMCONFIGファイルの情報を更新できます。dmunloadcfの詳細は、「Domains管理ツール」を参照してください。

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

  • TA_DMFAILOVERSEQ: TDomainセッション・レコードのセッション接続フェイルオーバー・シーケンスとプライマリ・レコードをBDMCONFIGファイルに指定し、それらをリクエストします。
  • TA_DMLACCESSPOINT: TDomainセッション・レコードのDM_LOCALセクションで見つかったローカル・ドメイン・アクセス・ポイントをBDMCONFIGファイルに指定し、それらをリクエストします。
  • TA_DMCONNECTION_POLICY: TDomain接続ポリシーを指定します

また、他の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
1.8.1.2.5 DMADMINを使用したTDomainセッション情報の指定とリクエスト

Tuxedoのコマンドライン・インタフェース、DMADMINを使用すると、TDomainセッション情報を指定およびリクエストできます。DMADMINの一般的な説明は、「Domains管理ツール」を参照してください。

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

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

  • TA_DMFAILOVERSEQ: TDomainセッション・レコードのセッション接続フェイルオーバー・シーケンスとプライマリ・レコードをBDMCONFIGファイルに指定し、それらをリクエストします。
  • TA_LDOM: TDomainセッション・レコードのDM_LOCALセクションで見つかったローカル・ドメイン・アクセス・ポイントをBDMCONFIGファイルに指定し、それらをリクエストします。
  • TA_CONNECTION_POLICY: TDomain接続ポリシーを指定します

TA_DMFAILOVERSEQ、TA_LDOM、TA_CONNECTION_POLICYおよびその他のフィールド識別子の詳細。

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
1.8.1.2.6 旧バージョンのTuxedoとのTDomainセッションの相互運用性

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

  • TDomainセッションを作成する場合は、Tuxedo 9.x DMADMサーバーとdmloadcfを使用する必要があります。
  • Tuxedo 8.1ローカル・ドメイン・ゲートウェイ・アクセスをリモート・ドメインに制限することはできません。制限した場合、ルーティング失敗のエラーが発生する場合があります。Tuxedo 8.1のメッセージ・ルーティングは、ローカル・ドメイン・ゲートウェイがすべてのリモート・ドメインに接続できることを前提としています。

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

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

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ゲートウェイで使用される自動接続再試行の基準になります。

親トピック: Domainsの接続ポリシーの指定

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

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

  • ON_DEMANDの場合、ローカル・ドメイン・ゲートウェイはリモート・ドメインからインポートされたサービスを継続的に通知します。
  • ON_STARTUPの場合、ローカル・ドメイン・ゲートウェイはリモート・ドメインからインポートされたサービスを、そのリモート・ドメインとの接続が存在するかぎり通知します。
  • INCOMING_ONLYの場合、ローカル・ドメイン・ゲートウェイは受信接続で、またはdmadmin connectコマンドの発行時にリモート・ドメインからインポートされたサービスを通知します。

接続ポリシーが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に送信します。接続が両方とも不可能になると、ゲートウェイは、掲示板のRSVCを中断します。RSVCに対する以降のリクエストは、ローカル・サービスにルーティングされるか、または失敗してTPENOENTが返されます。

関連項目:

親トピック: Domainsの接続ポリシーの指定

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

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

親トピック: Domainsについて

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

  • 自動接続再試行(ON_STARTUPのみ)
  • 受信接続
  • 手動によるdmadmin connectコマンドの実行

親トピック: Domainsのフェイルオーバーとフェイルバックの指定

1.9.2 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セクションで同じ値でなければなりません。この仕組みはミラー・ゲートウェイと呼ばれます。この機能は、トランザクションや会話の際に使用しないようにしてください。また、一次リモート・ゲートウェイが使用できるときには、ミラー・ゲートウェイの使用はお薦めできません。

親トピック: Domainsのフェイルオーバーとフェイルバックの指定

1.9.2.1 TDomainセッションのリンク・レベルのフェイルオーバーの構成

TDomainセッションのリンク・レベルのフェイルオーバーを構成するには、DMCONFIGファイルのDM_TDOMAINセクションのFAILOVERSEQパラメータを使用します。TDomainセッションでのFAILOVERSEQの指定の詳細は、1‑29ページの「TDomainセッション単位の接続ポリシー」を参照してください。

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

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

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

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

表1-4 Domainsのキープ・アライブについて

レベル 旧リリースのTuxedoとの相互運用性があるか 個別のタイマーか 接続の失敗を迅速に検出できるか ファイアウォールをまたいだキープ・アライブが可能か
TCPレベルのキープ・アライブ はい いいえ はい* はい
アプリケーション・レベルのキープ・アライブ いいえ はい はい はい
* TCPレベルのキープ・アライブでTDomainゲートウェイ接続の失敗を迅速に検出するには、このキープ・アライブの時間間隔を短く設定する必要があります。このように設定すると、TCPパケットでネットワークがいっぱいになる可能性があります。

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

親トピック: Domainsについて

1.10.1 TCPレベルのキープ・アライブとは

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

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

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

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

親トピック: Domainsのキープ・アライブの指定

1.10.2 DomainsのTCPレベルのキープ・アライブの構成

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

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

  • LOCAL (リモート・ドメイン・アクセス・ポイントでのみ有効)
  • NO (キープ・アライブ無効)
  • YES (キープ・アライブ有効)

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パラメータに次のいずれかの値を指定できます。

  • NO (デフォルト)
  • YES

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

  • LOCAL (デフォルト)
  • NO
  • YES

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

ノート:

相互作用する2つのOracle TuxedoドメインのそれぞれでTCPレベルのキープ・アライブを有効にできます。ただし、両方のドメインでOracle Tuxedo 8.1以降が動作している必要があります。

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

親トピック: Domainsのキープ・アライブの指定

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

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

  • アプリケーションがメッセージの受信をかなり長い時間待っているかどうか
  • TCP接続がまだオープンであるか、および接続の反対側のマシンとアプリケーションがまだ機能しているかを判断するためにどのアクションを行うのか

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

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

親トピック: Domainsのキープ・アライブの指定

1.10.4 Domainsのアプリケーション・レベルのキープ・アライブの構成

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

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

  • -1 (リモート・ドメイン・アクセス・ポイントでのみ有効)。
  • 0 (キープ・アライブ無効)
  • 1 <= value <= 2147483647 (キープ・アライブ有効)。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます

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

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

  • DMKEEPALIVEが0 (キープ・アライブ無効)の場合は、DMKEEPALIVEWAITを設定しても効果はありません。
  • DMKEEPALIVEが有効で、DMKEEPALIVEWAITがDMKEEPALIVEより大きい値に設定されている場合、ローカルTDomainゲートウェイはDMKEEPALIVEWAITタイマーが切れるまでに複数のアプリケーション・レベル・キープ・アライブ・メッセージを送信します。この組合せの設定は可能です。
  • DMKEEPALIVEが有効で、DMKEEPALIVEWAITが0に設定されている場合、送信したキープ・アライブ・メッセージに対する肯定応答を受信することは重要ではありません。そのような肯定応答はすべて、ローカルTDomainゲートウェイで無視されます。ローカルTDomainゲートウェイは、DMKEEPALIVEタイマーがタイムアウトになるたびにキープ・アライブ・メッセージを送信し続けます。この設定の組み合わせは、ファイアウォールを介したアイドル接続を保持するために使用します。

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パラメータに次のいずれかの値を指定できます。

  • 0 (デフォルト)
  • 1 <= value <= 2147483647。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます

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

  • -1 (デフォルト)
  • 0
  • 1 <= value <= 2147483647。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます

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

ノート:

相互運用される2つのOracle Tuxedoドメインのそれぞれで、アプリケーション・レベルのキープ・アライブを構成できます。待機間隔は同じでも別々でもかまいません。ただし、両方のドメインでOracle Tuxedo 8.1以降が動作している必要があります。

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

親トピック: Domainsのキープ・アライブの指定

1.10.5 旧リリースの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のキープ・アライブの指定

1.11 Domains環境の構成

次のリストは、TDomainゲートウェイ・タイプ用にDomains環境を構成するためのタスクをまとめたものです。

  1. テキスト・エディタでUBBCONFIGファイルを編集し、Domains管理サーバーとTDomainゲートウェイ・サーバーを構成します。例:
    *GROUPS
DMADMGRP  LMID=SITE1 GRPNO=1
GWTGROUP  LMID=SITE2 GRPNO=2
*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

    ノート:

    この例では、DMADM、GWADM、およびGWTDOMAINの各サーバーでREPLYQ=Nが指定されています。この設定は必須ではありません。必要に応じてREPLYQ=Yを指定して、それらのどのサーバーにでも応答キューを指定できます。ただし、REPLYQがNに設定されている場合は、パフォーマンスが向上することがあります。

    TDomainゲートウェイ・サーバーとその関連するGWADMサーバーは、Oracle Tuxedoドメインの同じマシンで実行する必要があります。DMADMサーバーは、Oracle Tuxedoドメインのどのマシン(マスター・マシン、非マスター・マシン)でも実行できます。

  2. tmloadcf(1)を実行してOracle Tuxedo構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。
  3. テキスト・エディタでDMCONFIGファイルを編集し、TDomainゲートウェイ・サーバー用にDomains環境を構成します。例:
    *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”
REMOT1  NWADDR=“//newyork.acme.com:65431”
REMOT2  NWADDR=“//philly.acme.com:65431”
    DMCONFIGファイルは、DMADMサーバーと同じマシン上に配置する必要があります。
  4. dmloadcf(1)を実行してDomains構成をロードします。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。
  5. tmboot(1)を実行してOracle Tuxedoアプリケーション・サーバーを起動します。tmbootコマンドは、すべての管理プロセスと環境変数TUXCONFIGとTUXOFFSETに指定されているTUXCONFIGファイルのSERVERSセクションにリストされているすべてのサーバーを実行します。サーバーは、SERVERSセクションにリストされている順序で起動します(DMADM、GWADM、そしてGWTDOMAINの順)。Domainsサーバーは、この順序で起動する必要があります。また、Domainsサーバーはアプリケーション・サーバーの前に起動する必要があります。

Domains ATMI環境を構成する詳しい例については、「ATMI Domainsの計画と構成」を参照してください。Domains CORBA環境を構成する詳しい例については、「CORBA Domainsの計画と構成」を参照してください。

親トピック: Domainsについて

1.12 移行を考慮したDomains環境の構成

次のリストに、Domainsの移行用にOracle Tuxedoアプリケーションを構成する方法を示します。Domainsの移行に特に重要なエントリは太字で示されています。

Domainsの移行を考えて構成されたサンプルUBBCONFIGファイルのリスト 

*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
.
.
.

ノート:

この例では、DMADM、GWADM、およびGWTDOMAINの各サーバーでREPLYQ=Nが指定されています。この設定は必須ではありません。必要に応じてREPLYQ=Yを指定して、それらのどのサーバーにでも応答キューを指定できます。ただし、REPLYQがNに設定されている場合は、パフォーマンスが向上することがあります。

Domainsの移行を考えて構成されたサンプルDMCONFIGファイルのリスト 

*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サーバー・プロセスをアクティブにします。

  • SITE3マシンでBDMCONFIG環境変数を設定します。
  • dmloadcf(1)コマンドを実行して、BDMCONFIGファイルをSITE3マシンにロードします。

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

ノート:

DMADMとドメイン・ゲートウェイ・グループは、同じマシンに移行する必要はありません。

親トピック: Domainsについて

1.12.1 DMADMサーバーの移行

DMADMを新しいマシンに移行するには、次のステップに従います。

  1. DMCONFIGを新しいマシンにコピーし、dmloadcfを実行します。
  2. 新しいマシンでDMADMサーバー・プロセスをアクティブにします。詳細は、「個々のサーバー・プロセスをアクティブにする手段」を参照してください。
  3. 必要に応じて、Oracle Tuxedoアプリケーションのすべてのドメイン・ゲートウェイ・グループを再起動します。

    ドメイン・ゲートウェイ・グループを再起動しない場合、それらは動作を続けますが、DMADMが移行された後はドメイン・ゲートウェイ・グループに対するすべてのMIBリクエストが失敗します。

親トピック: 移行を考慮したDomains環境の構成

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

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

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

  1. DMCONFIGファイルのDM_TDOMAINセクションに、次の形式で複数のリスニング・アドレスを追加します。 
    *DM_TDOMAIN
LOCAL1 NWADDR=“//primary:port”
LOCAL1 NWADDR=“//backup:port”
  2. トランザクションを使用している場合は、Domainsのトランザクション・ログを手動でバックアップ・マシンにコピーする必要があります。
  3. ステップ1で指定した2つのネットワーク・アドレスが、リモート・ドメインのDMCONFIGファイルに含まれていることを確認します。
  4. 新しいマシンでGWADMおよびGWTDOMAINサーバー・プロセスをアクティブにします。詳細は、次のセクションを参照してください。

親トピック: 移行を考慮したDomains環境の構成

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

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

  • コマンドtmboot(1) (-sコマンドライン・オプションを指定)
  • MIB (TM_MIB(5)) API

アプリケーションの移行タスクの詳細は、『Oracle Tuxedoアプリケーション実行時の管理』のアプリケーションの移行に関する項を参照してください。

親トピック: 移行を考慮したDomains環境の構成

1.13 ExalogicのRDMAを利用するクロスドメイン直接通信

この項で説明する内容は次のとおりです。

親トピック: Domainsについて

1.13.1 RDMAを利用するクロスドメイン直接通信の概要

このリリースでは、ドメイン間の関係を記述する、バイパス・ドメイン・モデルという新しいモデルが導入されています。直接または間接的に相互に接続され、バイパス・ドメイン・モデルで実行される一連のドメインで、バイパス・ドメイン・グループが構成されます。同じバイパス・ドメイン・グループ内のドメインでは、機能は次のように動作します。

バイパス・ドメイン・モデルで実行している場合、他のドメインからインポートされたサービスとして構成されるサービスは、ローカルの掲示板に登録されます。クライアントは、ローカルの掲示板でターゲット・サービスのプロバイダを検索し、リモート・サーバーに直接メッセージを送信します。これを促進するために、必要なすべての情報(グローバル・リソース)はバイパス・ドメイン・グループ内のノード間で共有され、このバイパス・ドメイン・グループ内のすべてのドメインがアクセスできる必要があります。

  • ドメイン間のTuxedo tpcallが、各ドメイン内のGWTDOMAINプロセスを介して実行されることはありません。
  • GWTDOMAINによって実行される通知/通知取消しのメカニズムとは異なり、リモート・ドメインによってエクスポートされたインポート・サービスはBBに直接追加され、RDMAキュー・アドレスを介して起動されます。
  • BYPASSDOM_SHARED_DIRで指定されるディレクトリに、「.」+「DOMGLOBAL」+「_」+「BYPASSDOM_ID」+「_」+「BYPASSDOM_SEQ_NUM」という修正ファイル名のOracle Tuxedoファイル・システムが自動的に作成されます。これは、複数のドメイン間で情報を交換する際のメディアです。

    ノート:

    バイパス・ドメインIDは、バイパス・ドメイン・グループの論理名です。バイパス・ドメイン・シーケンス番号は、ドメイン・グループ内のドメインを識別する番号です。1つのグループ内で一意の番号である必要があります。
  • GWTDOMAINがTMSとしてトランザクションに参加することはありません。ただし、必要なTMSサービスのBBへのインポートは、ローカル・ドメインが行います。これによって、トランザクションを実行でき、2つのドメイン間で必要な情報が交換されます。
  • GWTDOMAINは、デフォルトではバイパス・ドメイン・モデルで機能します。または、DMCONFIGにTHROUGHGATEWAY=Yを指定することで、非バイパス・ドメイン・モデルでも機能できます。
  • GWTDOMAINは、リモート・ドメインの機能を検索し、この機能を利用できるかどうかを判断します。GWTDOMAINは、反対側のドメインの設定に応じて、バイパス・ドメイン・モデルおよび非バイパス・ドメイン・モデルの両方で機能することがあります。ただし、同じ接続の場合、つまり特定のリモート・ドメイン・ゲートウェイの場合は、バイパス・ドメインまたは従来のドメインのいずれかになります。
  • リモート・サービス・ルーティングの規則は、非バイパス・ドメイン・モデルとは多少異なります。基本的に、インポート・サービスはBBに登録されるため、インポート・サービスの選択はローカル・サービスと同じです。つまり、GWTDOMAINで実装されるロード・バランスのアルゴリズムは機能しなくなります。
  • バイパス・ドメイン・モデルは、ドメイン間で異なるセキュリティ・トークンを使用する、セキュリティ・レベルACLまたはMANDATORY_ACLをサポートしていません。UBBCONFIGにACLまたはMANDATORY_ACLが指定され、DMCONFIG内のACL_POLICYがLOCALに設定されている場合、ACL_POLICYが指定されている2つのドメインは、そのバイパス・ドメイン機能が自動的にオフになります。
  • イベント・ブローカは、GWTDOMAINがバイパス・モデルとして指定されている場合であっても、非バイパス・ゲートウェイとしてのみ提供されます。
  • 1つのドメインで複数のGWTDOMAINによってエクスポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。
  • 複数のGWTDOMAINによってインポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。
  • WTCへの相互接続が可能なのは、非バイパス・ドメインの場合のみです。
  • バイパス・ドメインを指定した場合は、UBBCONFIGでGWWSを構成できません。それ以外の場合は、tmloadcfでエラーが報告されます。

親トピック: ExalogicのRDMAを利用するクロスドメイン直接通信

1.13.2 相互運用性または互換性の要件

  • この機能がオンの場合、ドメイン内のすべてのマシンは、ExalogicでTuxedo 12cリリース2 (12.1.3)にアップグレードする必要があります。
  • この機能がオンで、トランザクションがアプリケーションに関連する場合、トランザクション・ログ(TLOGまたはDMTLOG)を再生成する必要があります。

親トピック: ExalogicのRDMAを利用するクロスドメイン直接通信

1.13.3 サポート対象のプラットフォーム

Exalogic上のLinuxプラットフォームのみをサポートします。

親トピック: ExalogicのRDMAを利用するクロスドメイン直接通信

1.13.4 RDMAを利用するクロスドメイン直接通信における動作の変更

次の表に、RDMAを利用するクロスドメイン直接通信における動作の変更を示します。

表1-5 RDMAを利用するクロスドメイン直接通信における動作の変更

カテゴリ 説明
接続ポリシー ON_DEMAND GWTDOMAINがバイパス・ドメイン・モデルで実行されている場合、ON_DEMANDを指定しないでください。それ以外の場合、ON_DEMANDは自動的にON_STARTUPとして扱われ、GWTDOMAINは「LIBGWT_CAT XXXX、ON_DEMANDのかわりにON_STARTUPがバイパス・ドメイン・モデルで適用されます」というメッセージを出力します。
フェイルオーバー リンク・レベルのフェイルオーバー(リモート・ドメイン・アクセス・ポイントの複数のエントリ)およびセッション・リンク・レベルのフェイルオーバー(FAILOVERSEQ) 接続の動作は同じです。

ノート:

各リモート・ドメインには、一意のBYPASSDOM_SEQ_NUMを付ける必要があります。接続しているドメイン上のサービスのみがインポートされます。
Domainsレベルのフェイルオーバー サービスは、接続しているすべてのリモート・ドメインからインポートされますが、サービス・リストの先頭にあるサービス(たとえば、フェイルオーバー番号が最小のサービス)がアクティブ化されます。Domainsレベルのフェイルオーバーは、動作が非バイパス・モデルと完全には同じでないため(ロード・バランスなど)、部分的にサポートされます。バイパス・ドメイン・モードのフェイルオーバーの場合、リモート候補のゲートウェイを別のドメインにデプロイする必要があります。そうしないと、最初のゲートウェイ・サービスのみがインポートされます。
Domainsリンク・レベルの暗号化 LLE / SSL / SSL_ONE_WAY メッセージングまたはGWTDOMAINのプロトコルによってトリガーされる、GWTDOMAIN間でのデータ送信で機能します。ただし、ATMIコールのメッセージングでは、指定の暗号化方法は使用されなくなりました。
トランザクション トランザクション・タイムアウト インポートされたサービスは、タイムアウト設定に変換されます。
ブロッキング・タイムアウト - DMCONFIGの構成は、ローカルBBでサービス・タイムアウトとして変換されます。
セキュリティ NONE | APP_PW | DM_PW メッセージングまたはGWTDOMAINのプロトコルによってトリガーされる、GWTDOMAIN間でのデータ送信で機能します。ただし、ATMIコールのメッセージングでは、指定の暗号化方法は使用されなくなりました。
イベント・ブローカ - イベント・ブローカの動作は変更されていません。ただし、非バイパス・ドメイン・モデルとして機能します。
ACL Tuxedo ACL DM_REMOTEセクション内のACLがLOCALとして構成されている場合は、非バイパス・ドメイン・モデルでのみ機能します
Domainsアクセス制御(ACL) ACLリストに含まれないリモート・ドメインにサービスをエクスポートしないことによって、完全にサポートされます
ロード・バランス - ロード・バランス・アルゴリズムは、通常のローカル/MP ATMIコールのアルゴリズムに従います。

親トピック: ExalogicのRDMAを利用するクロスドメイン直接通信