以下の項では、Oracle Tuxedo Domainsコンポーネントの概要を説明します。
企業のビジネスが拡大するにつれ、機能、地理、機密度に基づいて分かれている、それぞれが管理上独立したアプリケーションにビジネス情報管理を取り入れる必要が出てきます。それらの独立したビジネス・アプリケーションはドメインと呼ばれ、情報を共有する必要があります。Oracle Tuxedo Domainsコンポーネントはビジネスのドメイン間で相互運用を実現するインフラストラクチャを提供し、それによってOracle Tuxedoクライアント/サーバー・モデルが複数のトランザクション処理(TP)ドメインに拡張されます。図1-1は、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ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「UBBCONFIG(5)」
リファレンス・ページで指定された形式に準拠している必要があります。)Oracle Tuxedoドメインは、1つのユニットとして管理されます。
Oracle Tuxedo Domainsコンポーネントは、各種のネットワークおよびドメインと通信するための様々なゲートウェイを提供します。具体的には、Domainsコンポーネントでは以下のドメイン・ゲートウェイが提供されます。
GWTDOMAIN
サービス・プロセスで実装) - ネットワーク・プロトコルTCP/IP上で機能する特別に設計されたTPプロトコルを使用して、複数のOracle Tuxedoドメイン間での相互運用性を実現します。WebLogic Tuxedo Connector (WTC)ゲートウェイ(Oracle WebLogic Serverコンポーネント)と連係することで、Oracle Tuxedo TDomainゲートウェイはTuxedoドメインとWebLogic Serverアプリケーションの間でも相互運用性を実現できます。GWIDOMAIN
サーバー・プロセスで実装) - ネットワーク・プロトコルTCP/IP経由でOracle Tuxedoドメインと、IBM OS/390顧客情報管理システム(CICS)および情報管理システム(IMS)の下で動作するアプリケーションの間の相互運用性を実現します。ゲートウェイでは非トランザクション型のタスクのみサポートされます。GWSNAX
サーバー・プロセスで実装) - システム・ネットワーク体系(SNA)拡張プログラム間通信機能(APPC)または共通プログラミング・インタフェース・コミュニケーション(CPI-C)がサポートされるプラットフォーム(IBM OS/400、OS/390 CICSおよびIMSシステム、およびVSE/CICS)で動作するOracle Tuxedoドメインとアプリケーション間の相互運用性を実現します。ゲートウェイでは複数のSNAネットワークとの通信がサポートされます。GWOSITP
サーバー・プロセスで実装) - Oracle Tuxedoドメインと、開放型システム間相互接続(OSI)トランザクション処理(TP)規格を使用するほかのトランザクション処理アプリケーションの間の相互運用性を実現します。OSI TPは、国際標準化機構(ISO)によって定義された分散トランザクション処理のためのプロトコルです。ゲートウェイでは、グローバル・トランザクションと様々な非トランザクション型タスクがサポートされます。これ以降は、Oracle TDomainゲートウェイおよびOracle Tuxedoドメイン間の通信を中心に説明します。WTCゲートウェイについては、次のドキュメントを参照してください。
Oracle TMAゲートウェイの詳細は、Oracle Tuxedo Mainframe Adapterのドキュメントを参照してください。
図1-2は、ドメインが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コンポーネントは、リモート・サービス(ほかのドメインのサービス)をローカル・サービスであるかのように通知するドメイン・ゲートウェイ・サーバー・プロセスを通じてドメイン間通信を実現します。
ドメイン・ゲートウェイでは、次の機能がサポートされています。
GWTDOMAIN
を使用せずに、RDMAを直接経由して相互に通信できます。注: | バイパス・ドメイン・モデルは、Exalogic上のLinuxプラットフォームのみをサポートします。 |
ドメイン・ゲートウェイは、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)
がサポートされています。転送されたリクエストは、ドメイン・ゲートウェイにより、単純なサービス・リクエストとして解釈されます。図1-3はこのプロセスを示しており、この図では、tpforward
を使用して、リモート・サービスをリクエストする簡単な流れを示します。
Oracle Tuxedoリクエスト/レスポンス型モデルの詳細は、『Oracle Tuxedo ATMIの紹介』のリクエスト/レスポンス型通信に関する項を参照してください。
ドメイン・ゲートウェイは、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の紹介』の会話型通信に関する項を参照してください。
ドメイン・ゲートウェイは、ATMIインタフェースで定義されたキューの処理モデルをサポートしています。クライアントやサーバーはどれも、リモート・ドメインのキューにメッセージまたはサービス・リクエストを格納できます。格納されたリクエストはすべて、安全性を確保するため、トランザクション・プロトコルを使用して送信されます。
Oracle Tuxedoシステムでは、メッセージを永続ストレージ(ディスク)や非永続ストレージ(メモリー)に登録して、後で処理や検索を行うことができます。ATMIには、メッセージをキューに追加(tpenqueue
)したり、キューから読み取る(tpdequeue
)ためのプリミティブが用意されています。応答メッセージやエラー・メッセージをキューに登録しておき、後でクライアントに返すこともできます。キューの作成、一覧表示、および変更を行うための管理コマンド・インタプリタ(qmadmin
)も用意されています。また、メッセージをキューに登録したり、キューから取り出すリクエストを受け付けるサーバー(TMQUEUE
サーバー)、キューから取り出したメッセージを処理するために転送するサーバー(TMQFORWARD
サーバー)、およびキューの処理を伴うトランザクションを管理するサーバー(TMS_QM
サーバー)の3つのサーバーが用意されています。
Oracle Tuxedoキューの処理モデルの詳細は、『Oracle Tuxedo ATMIの紹介』のメッセージ・キューイング通信に関する項を参照してください。
ドメイン・ゲートウェイは、ドメイン・ゲートウェイ・サーバー・プロセスが実行されているリリースのOracle Tuxedoシステム・ソフトウェアによってサポートされているすべての定義済型付きバッファをサポートします。Oracle Tuxedoは、11種類の定義済バッファ型をサポートしています。
Oracle Tuxedoリリースでサポートされている各バッファ型には、プログラマの介入なしで初期化、メッセージの送受信、およびデータのエンコード/デコードを行うために自動的に呼び出すことができるそれ独自のルーチン・セットがあります。このルーチン・セットを型付きバッファ・スイッチと呼びます。
Oracle Tuxedo ATMIアプリケーションでは、クライアントとサーバーとの間でデータ(サービス・リクエストと応答)を送信するために型付きバッファが使用されます。その名前のとおりそれ自身についての情報(メタデータ)が含まれている型付きバッファにより、アプリケーション・プログラマは、アプリケーションのクライアント側およびサーバー側で稼働中のマシンのデータ表現スキームを意識せずにデータを転送することができます。
ドメイン・ゲートウェイは、ワークステーション、ローカルのOracle Tuxedoマシン、およびリモート・ドメインから送信されるサービス・リクエストを受信し、処理できます。ドメイン・ゲートウェイは、次の理由により、エンコードされている受信したすべてのサービス・リクエストを適切な型付きバッファ・スイッチを使用してデコードします。
OSI用語では、抽象構文(データの構造)と転送構文(データ転送に使用する特定のエンコード)を明確に区別します。各型付きバッファでは、特定のデータ構造(抽象構文)と、そのデータ構造を特定の転送構文(たとえばXDR
)にマップするのに必要なエンコード規則(型付きバッファの動作)を暗黙的に定義します。エンコード/デコードをサポートする定義済のバッファ型について、Oracle Tuxedoシステムではそれらの型をXDR
転送構文にマップするためのエンコード規則が用意されています。
型付きバッファおよびエンコード/デコード操作の詳細は、『Oracle Tuxedo ATMIの紹介』の型付きバッファに関する項を参照してください。
Oracle Tuxedo Domainsのアーキテクチャは、主に次の4つの要素で構成されています。
Domains構成は、Oracle Tuxedo Domainsコンポーネントを介して通信したりサービスを共有したりできる複数のドメイン(アプリケーション)の集合です。複数のドメインがどのように接続されるのか、およびどのサービスが互いに利用可能になるのかは、Domains構成ファイルで定義します。Domains構成に関与する各Oracle Tuxedoドメインでは、それ専用のDomains構成ファイルが必要です。
テキスト形式のDomains構成ファイルはDMCONFIG
ファイルと呼ばれますが、任意の名前を付けることもできます(ただし、そのファイルの内容が『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「DMCONFIG(5)」
リファレンス・ページで説明されている形式に準拠している場合にかぎります)。バイナリ形式のDomains構成ファイルは、BDMCONFIG
と呼ばれます。DMCONFIG
ファイルの詳細は、「Domains構成ファイルの理解」を参照してください。
Oracle Tuxedo Domainsコンポーネントは、非同期性の高い、マルチタスク型およびマルチスレッド型のドメイン・ゲートウェイ・プロセスを使用してマルチ・ドメインの相互運用性を実現します。そのドメイン・ゲートウェイ・プロセスは、アプリケーション・プログラマとアプリケーション・ユーザーが両方とも別のドメインのサービスに透過的にアクセスできるようにするOracle Tuxedo提供サーバーです。
図1-4は、1つのOracle Tuxedoドメインが、ドメイン・ゲートウェイを介して別のドメインと通信する方法を示しています。
この図では、ドメイン・ゲートウェイがクレジット・カードの認可リクエストを処理し、別のドメインに送信する様子を示しています。このゲートウェイは、認可リクエストに対するレスポンスも処理します。
図1-5は、Domains構成を管理するために使用されるOracle Tuxedo Domains管理サーバーを示しています。
前述の図で示されるように、ドメイン・ゲートウェイ・グループは、ゲートウェイ管理サーバー(GWADM
)、ドメイン・ゲートウェイ・サーバー(GWTDOMAIN
など)、および(オプション)Domainsトランザクション・ログ(TLOG
)から構成されます。GWADM
サーバーは、ドメイン・ゲートウェイの実行時における管理を可能にします。Oracle Tuxedoドメインは、ドメイン・ゲートウェイ・グループを通じて1つ以上のリモート・ドメインと通信できます。
Oracle Tuxedoドメインで動作するすべてのドメイン・ゲートウェイ・グループと関連付けられているのは、Domains管理サーバー(DMADM
)です。Domains管理サーバーは、Oracle Tuxedo Domains構成ファイル(BDMCONFIG
)の実行時における管理を可能にします。
GWADM(5)
サーバーは、DMADM
サーバーに登録して、対応するゲートウェイ・グループで使用される構成情報を取得します。GWADM
は、DMADMIN
サービスからのリクエスト、つまり、指定したゲートウェイ・グループの実行時オプションでの統計情報や変更に対するリクエストを受け付けます。DMADMINサービスは、DMADM
によって通知された汎用管理サービスです。GWADM
は、定期的に"I-am-alive"メッセージをDMADM
サーバーに送信します。DMADM
から応答がなければ、GWADM
は再度登録を行います。このプロセスにより、GWADM
サーバーは、そのゲートウェイ・グループのDomains構成に関する最新の情報を常に保持できます。
GWADM
の詳細は、「Domainsの管理」を参照してください。
DMADM(5)
サーバーは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、GWADMサーバーの初期化プロシージャの一部としてGWADM
サーバーによってリクエストされます。登録サービスは、リクエスト元のゲートウェイ・グループが要求する構成情報をダウンロードします。DMADM
サーバーは、登録済のゲートウェイ・グループのリストを管理し、Domains構成ファイル(BDMCONFIG
)が変更されると、変更内容をリスト内のゲートウェイ・グループに伝播します。
DMADM
の詳細は、「Domainsの管理」を参照してください。
次のDomains管理ツールは、Domains構成の設定と管理のためにOracle Tuxedoシステムによって提供されます。
図1-6は、Domains管理ツールとDomainsのテキスト形式およびバイナリ形式の構成ファイルの関係を示しています。dmadmin
ユーティリティを使用する管理は、DMADM
サーバーによって通知されるDMADMIN
サービスを通じて行います。
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
の詳細は、『Oracle Tuxedoコマンド・リファレンス』のdmloadcf (1)リファレンス・ページを参照してください。
dmunloadcf(1)
コマンドは、BDMCONFIG
構成ファイルをバイナリ形式からテキスト形式に変換して、標準出力に出力します。dmunloadcf
の詳細は、『Oracle Tuxedoコマンド・リファレンス』のdmunloadcf (1)リファレンス・ページを参照してください。
dmadmin(1)
コマンドは、Oracle Tuxedoの管理者がTuxedoの実行中にドメイン・ゲートウェイを構成、モニター、およびチューニングできるようにします。このコマンドは、管理コマンドを変換してリクエストをDMADMIN
サービス(DMADM
サーバーにより通知される汎用管理サービス)に送信する管理コマンド・インタプリタとしても機能します。この結果、DMADMIN
サービスは、BDMCONFIG
ファイル内の情報を検証、取得、または更新する関数を呼び出します。
-c
オプションを指定してdmadmin
を呼び出すと、BDMCONFIG
ファイルが動的に更新されます。変更される構成に応じて、一部の更新はすぐに行われ、ほかの更新はその更新で影響を受けるものが新しく発生したときにのみ行われます。
dmadmin
の詳細は、「Domainsの管理」を参照してください。
Domains構成に関与する各Oracle Tuxedoドメインには、ドメイン間パラメータの定義される構成ファイルがあります。テキスト形式の構成ファイルはDMCONFIG
と呼ばれますが、構成ファイルには任意の名前を付けることができます。ただし、そのファイルの内容が『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG(5)リファレンス・ページで説明されている形式に準拠している場合に限ります。典型的な構成ファイル名は、文字列dm
で始まり、その後にファイル名dmconfig
のconfig
のようなニーモニック文字列が続きます。
Domains構成の管理者は、構成に参加するOracle Tuxedoドメインごとに別個のDMCONFIG
ファイルを作成する必要があります。DMCONFIG
ファイルは、任意のテキスト・エディタで作成および編集できます。
Domains構成に関与するOracle TuxedoドメインのDMCONFIG
ファイルは、TuxedoドメインのUBBCONFIG
ファイルで指定されているとおりに、Domains管理サーバーDMADM
が実行されるマシン上に配置されます。DMADM
サーバーは、Tuxedoドメインのどのマシン(マスター・マシン、非マスター・マシン)でも実行できます。
注: | Oracle Tuxedoドメインのマスター・マシンにはドメインのUBBCONFIG ファイルが含まれ、UBBCONFIG ファイルのRESOURCES セクションでマスター・マシンとして指定されます。Tuxedoドメインは、マスター・マシンを使用して起動、停止、および管理します。 |
BDMCONFIG
ファイルは、DMCONFIG
ファイルのバイナリ形式です。dmloadcf
コマンドを実行することで作成されます。このコマンドは、DMCONFIG
を解析して、バイナリ形式のBDMCONFIG
ファイルをBDMCONFIG
環境変数で示された位置にロードします。DMCONFIG
ファイルと同様、BDMCONFIG
ファイルがどのような名前であっても、実際の名前はBDMCONFIG
環境変数で指定されたデバイス・ファイル名またはシステム・ファイル名になります。BDMCONFIG
環境変数は、BDMCONFIG
がロードされるデバイス・ファイル名またはシステム・ファイル名で終わる絶対パス名に設定する必要があります。
UBBCONFIG
のバイナリ形式であるTUXCONFIG
ファイルと違って、BDMCONFIG
ファイルはTuxedoアプリケーションの起動時にTuxedoドメインのほかのどのマシンにも伝播されません。BDMCONFIG
ファイルをTuxedoドメインのほかのマシンにも配置するためには、そのドメインの管理者が手作業で配置する必要があります。
DMCONFIG
ファイルは、複数の指定セクションで構成されます。セクションは、アスタリスク(*)が先頭に付いた行から始まります。アスタリスク(*)の直後にはセクション名が表示されます。アスタリスクは、セクション名を指定するときに必要です。
注: | DM_LOCAL セクションは、DM_REMOTE セクションの前になければなりません。 |
Domains構成の管理者は、以上のセクションを以下の目的で使用します。
TDOMAIN
など)およびネットワーク・アドレスにマップします。図1-7は、ここで説明している作業の単純な例です。
この例では、ドメインXに作成されたDMCONFIG
ファイルを補うドメインYのDMCONFIG
ファイルも作成する必要があります。つまり、ドメインXのDMCONFIG
ファイルのローカル・ドメイン・アクセス・ポイントがドメインYのDMCONFIG
ファイルでリモート・ドメイン・アクセス・ポイントになり、ドメインXのDMCONFIG
ファイルのリモート・ドメイン・アクセス・ポイントがドメインYのDMCONFIG
ファイルでローカル・ドメイン・アクセス・ポイントになります。例では、TDomainゲートウェイ・サーバーの使い方が例示されています。
表1-1では、DMCONFIG
ファイルの各セクションについて説明します。
1つ以上のローカル・ドメイン・アクセス・ポイント識別子(ローカル・ドメインまたは
LDOM とも呼ばれる)を定義します。定義した各ローカル・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ(TDOMAIN など)を指定し、アクセス・ポイントを通じて利用できるローカル・サービスをDM_EXPORT セクションで指定します。ローカル・ドメイン・アクセス・ポイントを通じて利用可能なローカル・サービスは、1つ以上のリモート・ドメインのクライアントから利用できます。
このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(
TDOMAIN 、SNAX 、OSITP 、OSITPX )について1つずつ、複数のローカル・ドメイン・アクセス・ポイントを定義できます。
ローカル・ドメイン・アクセス・ポイントは、ゲートウェイ・グループごとに1つのみ定義できます。ドメイン・ゲートウェイ・グループは、
GWADM サーバー・プロセスとドメイン・ゲートウェイ・サーバー・プロセス(GWTDOMAIN 、TDomainゲートウェイ・サーバーなど)で構成されます。
|
|||
1つ以上のリモート・ドメイン・アクセス・ポイント識別子(リモート・ドメインまたは
RDOM とも呼ばれる)を定義します。定義した各リモート・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ(TDOMAIN など)を指定し、アクセス・ポイントを通じて利用できるリモート・サービスをDM_IMPORT セクションで指定します。リモート・ドメイン・アクセス・ポイントを通じて利用可能なリモート・サービスは、ローカル・ドメインのクライアントから利用できます。
このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(
TDOMAIN 、SNAX 、OSITP 、OSITPX )について1つ以上、複数のリモート・ドメイン・アクセス・ポイントを定義できます。
*DM_REMOTE “BA.BANK01” “BA.BANK02”
|
|||
DM_LOCAL セクションで定義されたローカル・ドメイン・アクセス・ポイントを通じて1つ以上のリモート・ドメインにエクスポートされるローカル・サービスを定義します。ローカル・ドメイン・アクセス・ポイントで指定されたサービスのみ、1つ以上のリモート・ドメインのクライアントから利用できます。つまり、このセクションでサービスを指定すると、ローカル・サービスへのリモート・クライアントのアクセスが制限されます。DM_EXPORT セクションがないか、あっても何も指定されていない場合は、ローカル・ドメインで通知されたすべてのサービスがリモート・ドメインから利用可能になります。
リモート・ドメインから利用可能になったローカル・サービスは、ローカル
UBBCONFIG ファイルのSERVICES セクションからそのプロパティの多くを継承します。継承されるプロパティとして、LOAD 、PRIO 、AUTOTRAN 、ROUTING 、BUFTYPE 、TRANTIME があります。
|
|||
DM_REMOTE セクションで定義された1つ以上のリモート・ドメイン・アクセス・ポイントを通じてインポートされ、1つ以上のローカル・ドメイン・アクセス・ポイントを通じてローカル・ドメインから利用可能なリモート・サービスを指定します。DM_IMPORT セクションが存在しない場合、または存在しても空の場合、リモート・サービスはローカル・ドメインで使用できません。
ローカル・ドメインから利用可能になったリモートOracle Tuxedoサービスは、リモート
UBBCONFIG ファイルのSERVICES セクションからそのプロパティの多くを継承します。継承されるプロパティとして、LOAD 、PRIO 、AUTOTRAN 、ROUTING 、BUFTYPE 、TRANTIME があります。
|
|||
同じサービスを提供する複数のリモート・ドメインの1つにローカルのサービス・リクエストをルーティングするためのデータ依存型ルーティング基準を指定します。例については、「Domainsデータ依存型ルーティングの指定」を参照してください。
|
|||
特定のDomains構成に必要なパラメータを定義します。現時点で、
domtype の値としては、TDOMAIN 、OSITP 、OSITPX 、またはSNACRM + SNALINKS + SNASTACKS を指定できます。各ドメイン・タイプは、別々のセクションで指定する必要があります。
DM_TDOMAIN セクションでは、ローカルまたはリモート・ドメイン・アクセス・ポイントのTDomain固有のネットワーク構成を定義します。1つ以上のWebLogic Serverアプリケーションと関連付けられた1つ以上のリモート・ドメイン・アクセス・ポイントのネットワーク構成を定義して、アプリケーションでTuxedo ATMIサーバーとWebLogic Server Enterprise JavaBean (EJB)サーバーを結合することもできます。詳細については、『Tuxedoの相互運用性』を参照してください。
DM_TDOMAIN セクションでは、リモート・ドメインからローカル・サービスへのリクエストがローカル・ドメイン・アクセス・ポイントを通じて受け付けられる場合に、そのローカル・ドメイン・アクセス・ポイントごとにエントリが必要です。このセクションで指定された各ローカル・ドメイン・アクセス・ポイントについて、受信接続のリスニングに使用するネットワーク・アドレスを指定する必要があります。
DM_TDOMAIN セクションでは、ローカル・ドメインからリモート・サービスへのリクエストがリモート・ドメイン・アクセス・ポイントを通じて受け付けられる場合に、そのリモート・ドメイン・アクセス・ポイントごとにエントリが必要です。このセクションで指定された各リモート・ドメイン・アクセス・ポイントについて、そのリモート・ドメイン・アクセス・ポイントへの接続時に使用する接続先ネットワーク・アドレスを指定する必要があります。
Tuxedo release 9.0では、
DM_TDOMAIN セクションに、特定のローカル・ドメイン・アクセス・ポイントとリモート・ドメイン・アクセス・ポイント間のTDomainセッションごとにエントリを定義できます。このセクションで指定した各TDomainセッションについて、そのTDomainセッションへの接続時に使用する接続先ネットワーク・アドレスを指定する必要があります。
Domainsのリンク・レベルのフェイルオーバーが使用されている場合は、リモート・ドメイン・アクセス・ポイントまたはTDomainセッションの複数の接続先ネットワーク・アドレスを指定してゲートウェイのミラーリングを実装できます。ゲートウェイのミラーリングの例については、「Domainsリンク・レベルのフェイルオーバーの構成」を参照してください。
DM_OSITP 、DM_OSITPX 、DM_SNACRM 、DM_SNALINKS 、およびDM_SNASTACKS の各セクションについては、http://download.oracle.com/docs/cd/E13161_01/tuxedo/tux100/interm/mainfrm.htmlを参照してください。
|
DMCONFIG
ファイルの詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG (5)およびDM_MIB (5)のリファレンス・ページを参照してください。
Oracle Tuxedoのリリース7.1以降では、Domains用のMIBで、ローカル・ドメインとリモート・ドメインとの相互作用を記述するため、クラスと属性の用語が改善されています。新しい用語は、「DMCONFIG(5)」
リファレンス・ページ、セクション名、パラメータ名、エラー・メッセージ、および「DM_MIB(5)」
リファレンス・ページ、クラス、エラー・メッセージに適用されます。
後方互換性のため、Oracle Tuxedo 7.1より前に使用されていたDMCONFIG
用語とDomains用のMIBの新しい用語との間で別名が提供されています。Oracle Tuxedoリリース7.1以降のDMCONFIG
では、両方のバージョンの用語を使用できます。表1-2に、DMCONFIG
ファイルの旧用語と新用語の対応を示します。
Oracle Tuxedoのリリース7.1以降のdmunloadcf
コマンドでは、デフォルトで新しいドメイン関連の用語を使用するDMCONFIG
ファイルが生成されます。以前のドメイン関連の用語を使用するDMCONFIG
ファイルを出力するには、-c
オプションを使用します。例:
プロンプト> dmunloadcf -c > dmconfig_prev
次のどのバッファ・タイプでも、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
アクセス・ポイントを通じてルーティングされます。
Oracle Tuxedoシステムには、トランザクション・タイムアウト・メカニズムとブロッキング・タイムアウト・メカニズムの2つのタイムアウト・メカニズムがあります。トランザクション・タイムアウトは、サービス・リクエストを処理するATMIトランザクションの期間を定義するために使用します。このタイムアウト値は、トランザクションを開始するときに定義されます。一方、ブロッキング・タイムアウトは、個々のサービス・リクエストの期間、つまり、サービス・リクエストに対する応答をATMIアプリケーションが待つ時間を定義するために使用します。
プロセスがトランザクション・モードではない場合、Oracle Tuxedoシステムによってブロッキング・タイムアウトが実行されます。プロセスがトランザクション・モードである場合は、Oracle Tuxedoシステムによってトランザクション・タイムアウトが実行されますが、ブロッキング・タイムアウトは実行されません。後者の説明はドメイン内トランザクション(1つのOracle Tuxedoドメイン内で処理されるトランザクション)では当てはまりますが、ドメイン間トランザクションでは当てはまりません。ドメイン間トランザクションでは、プロセスがトランザクション・モードである場合、Domainsソフトウェアによってトランザクション・タイムアウトとブロッキング・タイムアウトの両方が実行されます。
Oracle Tuxedoのトランザクション・タイムアウト・メカニズムは、Domainsコンポーネントにもそのまま適用されます。ドメイン・ゲートウェイはトランザクション・マネージャ・サーバー(TMS)機能を実装しているため、Oracle Tuxedo Bulletin Board Liaison (BBL)管理プロセスによって生成されるTMSタイムアウト・メッセージの処理を要求されるので、同じトランザクション・タイムアウト・メカニズムの使用が必要になります。
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
パラメータを認識しないノードが影響を受ける場合、または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
を参照してください。
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
値はドメイン内トランザクションのタイムアウトに影響しません。
ユーザーは、以下のいずれかの接続ポリシーを選択して、ローカル・ドメイン・ゲートウェイから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
to
LOCAL1REMOT2
- ON_STARTUP
Oracle Tuxedo 8.1以降では、DMCONFIG
ファイルのDM_TDOMAIN
セクションでローカル・ドメイン・アクセス・ポイントに次のいずれかの接続ポリシー値を指定できます。
ローカル・ドメイン・アクセス・ポイントの接続ポリシーを指定しない場合は、DMCONFIG
ファイルのDM_LOCAL
セクションで指定されたグローバル接続ポリシーがデフォルトで使用されます。DM_TDOMAIN
セクションで指定されたグローバル接続ポリシーは、DM_LOCAL
セクションで指定されたグローバル接続ポリシーに優先します。
注: | DM_TDOMAIN セクションでグローバル接続ポリシーを指定する場合は、DM_LOCAL セクションでグローバル接続ポリシーを指定しないでください。 |
Oracle Tuxedo 8.1以降では、リモート・ドメイン・アクセス・ポイントの接続ポリシー値も、DMCONFIG
ファイルのDM_TDOMAIN
セクションで次のいずれかから指定できます。
リモート・ドメイン・アクセス・ポイントにLOCAL
を指定するか、接続ポリシーを指定しないと、デフォルトでグローバル接続ポリシーが使用されます。
リモート・ドメインの接続ポリシー機能がないと、グローバル接続ポリシーがON_STARTUP
の場合に、ローカルTDomainゲートウェイはたとえ一部のリモート・ドメインが最初は使用されない場合でも起動時にすべてのリモート・ドメインに接続しようとします。このため、リモート・ドメインの数が多い場合は起動にかなりの時間がかかります。リモート・ドメインの接続ポリシー機能を使用する場合は、グローバル接続ポリシーのON_STARTUP
で、起動時に自動的には確立されないリモート・ドメインの接続を選択できます。
Oracle Tuxedoリリース9.0では、DMCONFIG
ファイルのDM_TDOMAIN
セクションでTDomainゲートウェイまたはTDomainセッション単位で接続ポリシーを定義できます。
TDomainセッション単位の接続ポリシーを定義するには、次のことを行う必要があります。
TDomainセッションの作成には、DMCONFIG
ファイルのDM_TDOMAIN
セクションで2つのパラメータを使用します。
他のTDomainセッション・パラメータおよび属性(SECURITY
、DMKEEPALIVE
)も指定できます。FAILOVERSEQ
、LACCESSPOINT
、およびその他のTDomainパラメータおよび属性については、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDM_TDOMAINセクションの省略可能パラメータに関する項を参照してください。
リスト1-1では、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つのレコードから構成されています。
FAILOVERSEQ
がレコード7より小さいので、TDomainセッションLOCAL1,REMOT1
のプライマリ・レコードです。このTDomainセッションの接続ポリシーはON_STARTUP
で、128ビットのリンク・レベル暗号化セキュリティ・ポリシーを必要とします。このレコードへの接続が失敗した場合、そのセカンダリ/バックアップ・レコードであるレコード7への接続が試行されます。FAILOVERSEQ
がレコード4より大きいので、TDomainセッションLOCAL1,REMOT1
のセカンダリ/バックアップ・レコードです。 このセッションのプライマリ・レコードはレコード4なので、レコード7の接続およびセキュリティ・ポリシーは無視されます。レコード7には、セカンダリ/バックアップ・フェイルオーバー・レコードがありません。レコード7への接続が失敗した場合、RETRY_INTERVAL
に従ってMAXRETRY
に達するまでレコード4への接続が試行されます。RETRY_INTERVAL
の詳細は、「接続再試行プロセスの使用方法」を参照してください。
LOCAL2,REMOT1
のプライマリ・レコードです。このTDomainセッションの接続ポリシーはINCOMING_ONLY
です。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。LOCAL2,REMOT2
のプライマリ・レコードです。このセッションの接続ポリシーはON_DEMAND
です。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。ローカル・アクセス・ポイントLOCAL2
は、2つのTDomainセッション(レコード5のREMOT1
とREMOT2
)に接続します。 同じTDomainセッションで2つ以上のレコードのFAILOVERSEQ
値が同じである場合、最初に入力されたレコードがプライマリ・レコードになります。残りのレコードのフェイルオーバー・シーケンスは、レコード・エントリ順序に基づいて決定されます。
TDomainセッション単位の接続ポリシーを作成するには、次の手順を行います。
DMCONFIG
ファイルを小さくし、処理しやすくするために、LACCESSPOINT
で正規表現を使用して複数のローカル・ドメイン・アクセス・ポイントを定義できます。
注: | DM_TDOMAIN は、DMCONFIG ファイルの中でLACCESSPOINT に正規表現を指定できる唯一のセクションです。 |
DMCONFIG
ファイルがコンパイルされると、出力バイナリBDMCONFIG
ファイルで正規表現がローカル・ドメイン名に展開されます。この結果、リスト1-2のように、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
ファイルの出力はリスト1-3のようになります。
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セッション情報を指定およびリクエストすると、BDMCONFIG
ファイルが直接修正されます。元のDMCONFIG
ファイルは修正されません。DM_MIB
の詳細は、セクション5の『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「DM_MIB(5)」を参照してください。
注: | dmunloadcf >DMCONFIG を使用すると、BDMCONFIG ファイルを解析してDMCONFIG ファイルの情報を更新できます。dmunloadcf の詳細は、「Domains管理ツール」を参照してください。 |
DM_MIB
は、3つのT_DM_TDOMAINクラス定義属性を使用して、TDomainセッション単位の接続ポリシーをBDMCONFIG
ファイルに作成します。
また、他のT_DM_TDOMAINクラス定義属性(セキュリティやキープ・アライブなど)を指定およびリクエストできます。T_DM_TDOMAINクラス定義属性情報については、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の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
Tuxedoのコマンドライン・インタフェース、DMADMIN
を使用すると、TDomainセッション情報を指定およびリクエストできます。DMADMIN
の詳細は、「Domains管理ツール」を参照してください。
DMADMIN
でTDomainセッション情報を指定およびリクエストする場合の効果は、DM_MIB
を使用する場合とほぼ同じです。つまり、DMADMIN
を使用すると、BDMCONFIG
ファイルが修正されますが、元のDMCONFIG
ファイルは修正されません。
DMADMIN
は、3つのフィールド識別子を使用して、TDomainセッション単位の接続ポリシー・レコードをBDMCONFIG
ファイルに追加します。
TA_DMFAILOVERSEQ
、TA_LDOM
、TA_CONNECTION_POLICY
、およびその他のフィールド識別子の詳細は、『Oracle Tuxedoコマンド・リファレンス』のdmadmin(1)を参照してください。
DMADMIN
を使用して、TDomainセッション・レコードを追加、削除、または検索できます。次に、DMADMIN
を使用してTDomainセッション接続ポリシー・レコードをBDMCONFIG
ファイルに追加する例を示します。
TA_CMPLIMIT 2147483647
TA_CONNECTION_POLICY
TA_MINENCRYPTBITS 0
TA_MAXENCRYPTBITS 128
TA_DMNWADDR //philly.acme.com:65431
TA_LDOM LDOM3
TA_DMFAILOVERSEQ 50
TA_RDOM RDOM1 ON_STARTUP
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
は設定できません。
*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
に送信します。接続が両方とも不可能になると、ゲートウェイは、掲示板のRSVC
を中断します。RSVC
に対する以降のリクエストは、ローカル・サービスにルーティングされるか、または失敗してTPENOENT
が返されます。
DMCONFIG
ファイルのDM_IMPORT
セクションでは、Domains構成のDomainsレベルのフェイルオーバーおよびフェイルバック機能を設定できます。DMCONFIG
ファイルのDM_TDOMAIN
セクションでは、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のリンク・レベルのフェイルオーバーを構成するには、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セッションのリンク・レベルのフェイルオーバーを構成するには、DMCONFIG
ファイルのDM_TDOMAIN
セクションのFAILOVERSEQ
パラメータを使用します。TDomainセッションでのFAILOVERSEQ
の指定については、「TDomainセッション単位の接続ポリシー」を参照してください。
また、DM_MIB
のTA_DMFAILOVERSEQ
属性を使用してTDomainセッションのリンク・レベルのフェイルオーバーを構成することもできます。詳細は、「DM_MIBを使用したTDomainセッション情報の指定とリクエスト」を参照してください。
Domainsのキープ・アライブ(Oracle Tuxedoリリース8.1以降が動作するTDomainゲートウェイで利用可能)を利用すると、TDomainゲートウェイの接続ごとにTCPレベルおよびアプリケーション・レベルでキープ・アライブ・プロトコルを有効化および構成できます。TCPレベルのキープ・アライブとアプリケーション・レベルのキープ・アライブは相互に排他的ではないので、両方のオプションを使用してDomains接続を構成できます。
表1-4は、Domainsのキープ・アライブに関する主要な情報を提供します。
ほとんどのOracle Tuxedo Domains構成はファイアウォールをまたがっており、ファイアウォールはアイドル接続がタイムアウトになる原因となります。Domainsキープ・アライブは活動のない期間にOracle Tuxedoのドメイン間接続をオープンに維持するだけでなく、TDomainゲートウェイでDomains接続の失敗を迅速に検出できるようにします。現在、TDomainゲートウェイは基底のTCPスタックを通じてDomains接続の失敗を検出しています。TCPスタックは、失敗の発生後15分以上経ってからその失敗を報告します。実際に何分かかるかは、ローカルのオペレーティング・システムの構成によって異なります。
キープ・アライブ機能はTCPの仕様に含まれていませんが、ほとんどのオペレーティング・システムではTCPキープ・アライブ・タイマーが提供されます。TCPキープ・アライブ・タイマーを使用すると、TCP接続の片側のサーバー・マシンでその接続のもう片側のクライアント・マシンがアクセス可能かどうかを検出できます。
TCP接続を経由してサーバー・マシンに届くメッセージはすべて、TCPキープ・アライブ・タイマーをリセットします。キープアライブ・タイマーによって事前定義済の期間(通常は2時間)にTCP接続で活動がないことが検出されると、タイマーが時間切れになり、サーバー・マシンはセグメント検査パケットをクライアント・マシンに送信します。接続がまだオープンであり、クライアント・マシンがまだ機能している場合は、クライアント・マシンから肯定応答がサーバー・マシンに送信されます。セグメント検査パケットを送信してから一定の期間肯定応答が届かない場合、サーバー・マシンは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。
接続がオープンでクライアント・マシンが機能しているかどうかを判断するだけでなく、TCPレベルのキープ・アライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がない状態が定義済の期間続いた後にセグメント検査パケットを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。
オペレーティング・システムのTCPキープ・アライブ・タイマーの間隔は、通常は2時間に設定されます。この間隔は変更できますが、その変更によってマシンのすべてのTCP接続が影響を受けます。オペレーティング・システムのTCPキープ・アライブ間隔は、システム全体にかかわる値です。
DomainsのOracle Tuxedo TCPレベル・キープ・アライブ・オプションはTCPKEEPALIVE
という名前で、DMCONFIG
ファイルのDM_TDOMAIN
セクションにオプション・パラメータとして追加されています。このパラメータを使用すると、DomainsのTCPレベルのキープ・アライブ・オプションをローカル・ドメインまたはリモート・ドメイン単位で有効にできます。
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レベルのキープ・アライブ構成が使用されます。
注: | 相互作用する2つのOracle TuxedoドメインのそれぞれでTCPレベルのキープ・アライブを有効にできます。ただし、両方のドメインでOracle Tuxedo 8.1以降が動作している必要があります。 |
Domains接続の接続ポリシーがON_STARTUP
で、TCP接続がTCPレベルのキープ・アライブの障害によりクローズしている場合は、自動接続再試行が行われます。接続の再試行が成功しない場合は、dmadmin
connect
コマンドを使用して接続を再確立する必要があります。dmadmin
connect
コマンドについては、「ドメイン間の接続の確立」を参照してください。
オペレーティング・システムのTCPキープ・アライブについては、セグメント検査パケットが不必要に帯域幅を消費し、インターネット接続でユーザーがパケット単位で支払うお金を浪費するということで、一部の人たちは使用することに異を唱えています。また、アプリケーション層では次のことを判断すべきなので、キープ・アライブはトランスポート(TCP)層ではなくアプリケーション層またはリンク層が適していると信じている人たちもいます。
誰がどのような意見を持っているかに関係なく、アプリケーション・レベルのキープ・アライブはキープ・アライブ・タイマーの間隔を接続ごとに設定できるという点ではTCPレベルのキープ・アライブよりも優れています。TCPレベルのキープ・アライブの場合、タイマーの間隔はマシン単位で設定します。
アプリケーション・レベルのキープ・アライブを使用した場合、サーバー・アプリケーションはアプリケーション・キープ・アライブ・タイマーがタイムアウトになるたびにアプリケーション固有のキープ・アライブ・メッセージを送信します。(キープ・アライブ・メッセージは通常はヘッダー情報のみで構成され、データは関連付けられていません。)クライアント・アプリケーションは、肯定応答を送信してサーバー・アプリケーションに応答します。キープ・アライブ・メッセージを送信してから事前定義済の期間肯定応答が届かない場合、サーバー・アプリケーションは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。
接続がオープンでクライアント・アプリケーションが機能しているかどうかを判断するだけでなく、アプリケーション・レベルのキープ・アライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がないことが定義済の期間続いた後にキープ・アライブ・メッセージを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。
DomainsのOracle Tuxedoアプリケーション・レベル・キープ・アライブ・オプションはKEEPALIVE
名前です。このパラメータとそれに伴うKEEPALIVEWAIT
というパラメータが、DMCONFIG
ファイルのDM_TDOMAIN
セクションのオプション・パラメータとして追加されています。これらのパラメータを使用すると、Domainsのアプリケーション・レベルのキープ・アライブ・オプションをローカル・ドメインまたはリモート・ドメイン単位で構成できます。
DMKEEPALIVE
パラメータでは、Domains接続でトラフィックを受信することなくローカルTDomainゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイからアプリケーション・レベル・キープ・アライブ・リクエスト・メッセージが送信されます。DMKEEPALIVE
の有効な値は次のとおりです。
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
パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントの場合、DMKEEPALIVE
パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントで -1を指定するか、キープ・アライブ構成を指定しないと、デフォルトでローカルのアプリケーション・レベルのキープ・アライブ構成が使用されます。
注: | 相互運用される2つのOracle Tuxedoドメインのそれぞれで、アプリケーション・レベルのキープ・アライブを構成できます。待機間隔は同じでも別々でもかまいません。ただし、両方のドメインでOracle Tuxedo 8.1以降が動作している必要があります。 |
Domains接続の接続ポリシーがON_STARTUP
であり、その接続でアプリケーション・レベルのキープ・アライブの障害が発生した場合は、自動的な接続再試行プロセスによって接続の再確立が行われます。接続再試行プロセスの詳細は、「接続再試行プロセスの使用方法」を参照してください。
ドメインの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)に記録されます。
次のリストは、TDomainゲートウェイ・タイプ用にDomains環境を構成するためのタスクをまとめたものです。
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ドメインのどのマシン(マスター・マシン、非マスター・マシン)でも実行できます。
tmloadcf(1)
を実行してOracle Tuxedo構成をロードします。tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。DMCONFIG
ファイルを編集し、TDomainゲートウェイ・サーバー用にDomains環境を構成します。例:*DM_LOCALLOCAL1 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
サーバーと同じマシン上に配置する必要があります。
dmloadcf(1)
を実行してDomains構成をロードします。dmloadcf
コマンドを実行すると、DMCONFIG
が解析され、BDMCONFIG
変数が指す場所にバイナリ形式のBDMCONFIG
ファイルがロードされます。tmboot(1)
を実行してOracle Tuxedoアプリケーション・サーバーを起動します。tmboot
コマンドは、すべての管理プロセスと環境変数TUXCONFIG
とTUXOFFSET
に指定されているTUXCONFIG
ファイルのSERVERS
セクションにリストされているすべてのサーバーを実行します。サーバーは、SERVERS
セクションにリストされている順序で起動します(DMADM
、GWADM
、そしてGWTDOMAIN
の順)。Domainsサーバーは、この順序で起動する必要があります。また、Domainsサーバーはアプリケーション・サーバーの前に起動する必要があります。Domains ATMI環境を構成する詳しい例については、「ATMI Domainsの計画と構成」を参照してください。Domains CORBA環境を構成する詳しい例については、「CORBA Domainsの計画と構成」を参照してください。
リスト1-4とリスト1-5を参照すると、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
.
.
.
注: | この例では、DMADM 、GWADM 、およびGWTDOMAIN の各サーバーでREPLYQ=N が指定されています。この設定は必須ではありません。必要に応じてREPLYQ=Y を指定して、それらのどのサーバーにでも応答キューを指定できます。ただし、REPLYQ がN に設定されている場合は、パフォーマンスが向上することがあります。 |
*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
を新しいマシンに移行するには、次の手順に従います。
DMCONFIG
を新しいマシンにコピーし、dmloadcf
を実行します。DMADM
サーバー・プロセスをアクティブにします。詳細は、「個々のサーバー・プロセスをアクティブにする手段」を参照してください。 ドメイン・ゲートウェイ・グループを再起動しない場合、それらは動作を続けますが、DMADM
が移行された後はドメイン・ゲートウェイ・グループに対するすべてのMIBリクエストが失敗します。
トランザクションがDomains構成で使用されている場合、TDomainゲートウェイ・グループは同じ種類のマシン間でのみ移行できます。
TDomainゲートウェイ・グループを移行するには、次の手順に従います。
DMCONFIG
ファイルのDM_TDOMAIN
セクションに、次の形式で複数のリスニング・アドレスを追加します。*DM_TDOMAIN
LOCAL1 NWADDR=“//primary
:port
”
LOCAL1 NWADDR=“//backup
:port
”
DMCONFIG
ファイルに含まれていることを確認します。GWADM
およびGWTDOMAIN
サーバー・プロセスをアクティブにします。詳細は、次のセクションを参照してください。個々のOracle Tuxedoサーバー・プロセスは、次のいずれかの手段でアクティブにできます。
アプリケーションの移行タスクについては、『Oracle Tuxedoアプリケーション実行時の管理』の「アプリケーションの移行」を参照してください。
このリリースでは、ドメイン間の関係を記述する、バイパス・ドメイン・モデルという新しいモデルが導入されています。直接または間接的に相互に接続され、バイパス・ドメイン・モデルで実行される一連のドメインで、バイパス・ドメイン・グループが構成されます。同じバイパス・ドメイン・グループ内のドメインでは、機能は次のように動作します。
バイパス・ドメイン・モデルで実行している場合、他のドメインからインポートされたサービスとして構成されるサービスは、ローカルの掲示板に登録されます。クライアントは、ローカルの掲示板でターゲット・サービスのプロバイダを検索し、リモート・サーバーに直接メッセージを送信します。これを促進するために、必要なすべての情報(グローバル・リソース)はバイパス・ドメイン・グループ内のノード間で共有され、このバイパス・ドメイン・グループ内のすべてのドメインがアクセスできる必要があります。
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
は、反対側のドメインの設定に応じて、バイパス・ドメイン・モデルおよび非バイパス・ドメイン・モデルの両方で機能することがあります。ただし、同じ接続の場合、つまり特定のリモート・ドメイン・ゲートウェイの場合は、バイパス・ドメインまたは従来のドメインのいずれかになります。GWTDOMAIN
で実装されるロード・バランスのアルゴリズムは機能しなくなります。ACL
またはMANDATORY_ACL
をサポートしていません。UBBCONFIG
にACL
またはMANDATORY_ACL
が指定され、DMCONFIG
内のACL_POLICY
がLOCAL
に設定されている場合、ACL_POLICY
が指定されている2つのドメインは、そのバイパス・ドメイン機能が自動的にオフになります。GWTDOMAIN
がバイパス・モデルとして指定されている場合であっても、非バイパス・ゲートウェイとしてのみ提供されます。GWTDOMAIN
によってエクスポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。 GWTDOMAIN
によってインポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。UBBCONFIG
でGWWS
を構成できません。それ以外の場合は、tmloadcf
でエラーが報告されます。Exalogic上のLinuxプラットフォームのみをサポートします。
次の表は、RDMAを利用するクロスドメイン直接通信における動作の変更を示しています。