|
•
|
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 TMA OSI TPゲートウェイ( GWOSITPサーバー・プロセスで実装) - Oracle Tuxedoドメインと、開放型システム間相互接続(OSI)トランザクション処理(TP)規格を使用する他のトランザクション処理アプリケーションの間の相互運用性を実現します。OSI TPは、国際標準化機構(ISO)によって定義された分散トランザクション処理のためのプロトコルです。ゲートウェイでは、グローバル・トランザクションと様々な非トランザクション型タスクがサポートされます。
|
図1-2に、4つのドメインがあり、そのうちの3つはOracle TuxedoドメインであるサンプルDomains構成を示します。
図の一番下にあるOracle Tuxedoクレジット・カード認可センターには、bankgw1というTDomainゲートウェイ・グループと
bankgw2というOSI TPゲートウェイ・グループの2つのゲートウェイ・グループがあります。
bankgw1は、ネットワーク・プロトコルTCP/IPを使用して2つのリモートOracle Tuxedoドメイン(ABC銀行とCBA銀行)へのアクセスを提供します。
bankgw2は、ネットワーク・プロトコルOSI TPを使用して1つのリモート・ドメイン(XYZ銀行)へのアクセスを提供します。
|
•
|
マルチネットワークのサポート - ゲートウェイは、TCP/IP、IPX/SPX、OSIなど、様々なネットワーク・プロトコルを介して他のドメインと通信できます。ただし、ゲートウェイは、そのリンク先であるネットワーク・ライブラリの機能に制限を受けます。つまり、ゲートウェイは通常、1種類のネットワークをサポートします。たとえば、Oracle Tuxedo TDomainゲートウェイではTCP/IPのみサポートされます。
|
|
•
|
バイパス・ドメイン・モデル - 複数のドメインにまたがるATMIアプリケーションは、 GWTDOMAINを使用せずに、RDMAを直接経由して相互に通信できます。
|
|
•
|
トランザクション管理 - ゲートウェイにより、ATMIアプリケーションはトランザクション内で他のドメインと相互運用できます。ゲートウェイは、ドメイン間で行われるトランザクションのコミットまたはロールバックを調整します。
|
|
•
|
複数のメッセージング・モデル - ゲートウェイは、次のATMIメッセージング・モデルをサポートしています。既存のOracle Tuxedoアプリケーションを修正する必要はありません。
|
|
•
|
リクエスト/レスポンス型モデル - Oracle Tuxedoシステムを使用するATMIアプリケーションは、他のドメインで動作するアプリケーションのサービスをリクエストできます。
|
|
•
|
会話型モデル - ATMIアプリケーションは、他のドメインで動作しているプログラムと会話型の通信を行うことができます。
|
|
•
|
キューの処理モデル - Oracle Tuxedoシステムを使用するATMIアプリケーションは、ほかのドメインのキューにデータを保存できます。
|
|
•
|
型付きバッファのサポート - ゲートウェイは、Oracle Tuxedo ATMIアプリケーションで定義されるすべてのバッファ型に対して、エンコードまたはデコードの操作を実行できます。
|
|
•
|
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アプリケーションは、tpconnect(3c)を使用してリモート・サービスとの会話を確立し、
tpsend(3c)と
tprecv(3c)を使用してこのサービスと通信し、
tpdiscon(3c)を使用して会話を終了します。ドメイン・ゲートウェイは、リモート・サービスとの会話を保持し、Oracle Tuxedoの会話型サービスの定義と同じセマンティクスで戻り値(
TPSUCCESSまたは
TPFAILを返す
tpreturn)を返し、接続を切断します。
テキスト形式のDomains構成ファイルはDMCONFIGファイルと呼ばれますが、任意の名前を付けることもできます(ただし、そのファイルの内容が
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
「DMCONFIG(5)」リファレンス・ページで説明されている形式に準拠している場合にかぎります)。バイナリ形式のDomains構成ファイルは、
BDMCONFIGと呼ばれます。
DMCONFIGファイルの詳細は、
1-15ページの「Domains構成ファイルの理解」を参照してください。
図1-4に、1つのOracle Tuxedoドメインが、ドメイン・ゲートウェイを介して別のドメインと通信する方法を示します。
図1-5に、Domains構成を管理するために使用されるOracle Tuxedo Domains管理サーバーを示します。
前述の図で示されるように、ドメイン・ゲートウェイ・グループは、
ゲートウェイ管理サーバー(
GWADM)、ドメイン・ゲートウェイ・サーバー(
GWTDOMAINなど)および(オプション) Domainsトランザクション・ログ(
TLOG)から構成されます。
GWADMサーバーは、ドメイン・ゲートウェイの実行時における管理を可能にします。Oracle Tuxedoドメインは、ドメイン・ゲートウェイ・グループを通じて1つ以上のリモート・ドメインと通信できます。
GWADM(5)サーバーは、
DMADMサーバーに登録して、対応するゲートウェイ・グループで使用される構成情報を取得します。
GWADMは、
DMADMINサービスからのリクエスト、つまり、指定したゲートウェイ・グループの実行時オプションでの統計情報や変更に対するリクエストを受け付けます。DMADMINサービスは、
DMADMによって通知された汎用管理サービスです。
GWADMは、定期的に"I-am-alive"メッセージを
DMADMサーバーに送信します。
DMADMから応答がなければ、
GWADMは再度登録を行います。このプロセスにより、
GWADMサーバーは、そのゲートウェイ・グループのDomains構成に関する最新の情報を常に保持できます。
DMADM(5)サーバーは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、GWADMサーバーの初期化プロシージャの一部として
GWADMサーバーによってリクエストされます。登録サービスは、リクエスト元のゲートウェイ・グループが要求する構成情報をダウンロードします。
DMADMサーバーは、登録済のゲートウェイ・グループのリストを管理し、Domains構成ファイル(
BDMCONFIG)が変更されると、変更内容をリスト内のゲートウェイ・グループに伝播します。
|
•
|
dmloadcf(1) - DMCONFIGファイルを読み取り、構文をチェックし、バイナリ形式の BDMCONFIG構成ファイルをロードします。
|
|
•
|
dmadmin(1) - Oracle Tuxedoの管理者がTuxedoドメインの実行時に BDMCONFIGファイルを更新できるようにします。
|
図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)があります。ファイル内の各行の形式は、次のとおりです。
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ファイルが動的に更新されます。変更される構成に応じて、一部の更新はすぐに行われ、ほかの更新はその更新で影響を受けるものが新しく発生したときにのみ行われます。
Domains構成に関与するOracle TuxedoドメインのDMCONFIGファイルは、Tuxedoドメインの
UBBCONFIGファイルで指定されているとおりに、Domains管理サーバー
DMADMが実行されるマシン上に配置されます。
DMADMサーバーは、Tuxedoドメインのどのマシン(マスター・マシン、非マスター・マシン)でも実行できます。
BDMCONFIGファイルは、
DMCONFIGファイルのバイナリ形式です。
dmloadcfコマンドを実行することで作成されます。このコマンドは、
DMCONFIGを解析して、バイナリ形式の
BDMCONFIGファイルを
BDMCONFIG環境変数で示された位置にロードします。
DMCONFIGファイルと同様、
BDMCONFIGファイルがどのような名前であっても、実際の名前は
BDMCONFIG環境変数で指定されたデバイス・ファイル名またはシステム・ファイル名になります。
BDMCONFIG環境変数は、
BDMCONFIGがロードされるデバイス・ファイル名またはシステム・ファイル名で終わる絶対パス名に設定する必要があります。
UBBCONFIGのバイナリ形式である
TUXCONFIGファイルと違って、
BDMCONFIGファイルはTuxedoアプリケーションの起動時にTuxedoドメインの他のどのマシンにも伝播
されません。
BDMCONFIGファイルをTuxedoドメインのほかのマシンにも配置するためには、そのドメインの管理者が手作業で配置する必要があります。
DMCONFIGファイルは、複数の指定セクションで構成されます。セクションは、アスタリスク(*)が先頭に付いた行から始まります。アスタリスク(*)の直後にはセクション名が表示されます。アスタリスクは、セクション名を指定するときに必要です。
|
•
|
DM_domtype ( domtypeは、 TDOMAIN、 OSITP、 OSITPXまたは SNACRM + SNALINKS + SNASTACKS)
|
|
注意:
|
DM_LOCALセクションは DM_REMOTEセクションの前にある必要があります。
|
図1-7は、ここで説明している作業の単純な例です。
この例では、ドメインXに作成されたDMCONFIGファイルを補うドメインYの
DMCONFIGファイルも作成する必要があります。つまり、ドメインXの
DMCONFIGファイルのローカル・ドメイン・アクセス・ポイントがドメインYの
DMCONFIGファイルでリモート・ドメイン・アクセス・ポイントになり、ドメインXの
DMCONFIGファイルのリモート・ドメイン・アクセス・ポイントがドメインYの
DMCONFIGファイルでローカル・ドメイン・アクセス・ポイントになります。例では、TDomainゲートウェイ・サーバーの使い方が例示されています。
表1-1に、
DMCONFIGファイルの各セクションの説明を示します。
|
|
|
DM_LOCAL ( DM_LOCAL_DOMAINSとも呼ばれる)
|
1つ以上のローカル・ドメイン・アクセス・ポイント識別子(ローカル・ドメインまたはLDOMとも呼ばれる)を定義します。定義した各ローカル・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ( TDOMAINなど)を指定し、アクセス・ポイントを通じて利用できるローカル・サービスを DM_EXPORTセクションで指定します。ローカル・ドメイン・アクセス・ポイントを通じて利用可能なローカル・サービスは、1つ以上のリモート・ドメインのクライアントから利用できます。
このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(TDOMAIN、 SNAX、 OSITP、 OSITPX)について1つずつ、複数のローカル・ドメイン・アクセス・ポイントを定義できます。
ローカル・ドメイン・アクセス・ポイントは、ゲートウェイ・グループごとに1つのみ定義できます。ドメイン・ゲートウェイ・グループは、 GWADMサーバー・プロセスとドメイン・ゲートウェイ・サーバー・プロセス( GWTDOMAIN、TDomainゲートウェイ・サーバーなど)で構成されます。
|
注意:
|
ACCESSPOINTIDパラメータのかわりに DOMAINIDを使用することもできます。
|
|
DM_REMOTE ( DM_REMOTE_DOMAINSとも呼ばれる)
|
1つ以上のリモート・ドメイン・アクセス・ポイント識別子(リモート・ドメインまたはRDOMとも呼ばれる)を定義します。定義した各リモート・ドメイン・アクセス・ポイント(論理名)について、このセクションでアクセス・ポイントのドメイン・ゲートウェイ・グループ( TDOMAINなど)を指定し、アクセス・ポイントを通じて利用できるリモート・サービスを DM_IMPORTセクションで指定します。リモート・ドメイン・アクセス・ポイントを通じて利用可能なリモート・サービスは、ローカル・ドメインのクライアントから利用できます。
このセクションでは、このOracle Tuxedoドメインがリモート・ドメインと通信するために使用する各ゲートウェイ・グループ(TDOMAIN、 SNAX、 OSITP、 OSITPX)について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があります。
|
注意:
|
LACCESSPOINTパラメータのかわりに LDOMを使用することもできます。
|
|
DM_IMPORT ( DM_REMOTE_SERVICESとも呼ばれる)
|
DM_REMOTEセクションで定義された1つ以上のリモート・ドメイン・アクセス・ポイントを通じてインポートされ、1つ以上のローカル・ドメイン・アクセス・ポイントを通じてローカル・ドメインから使用可能なリモート・サービスを指定します。 DM_IMPORTセクションが存在しない場合、または存在しても空の場合、リモート・サービスはローカル・ドメインで使用できません。
ローカル・ドメインから使用可能になったリモートOracle Tuxedoサービスは、リモートUBBCONFIGファイルの SERVICESセクションからそのプロパティの多くを継承します。継承されるプロパティとして、 LOAD、 PRIO、 AUTOTRAN、 ROUTING、 BUFTYPE、 TRANTIMEがあります。
|
注意:
|
RACCESSPOINTパラメータのかわりに RDOM、 LACCESSPOINTパラメータのかわりに LDOMを使用することもできます。
|
|
|
|
グローバルのDomains構成情報、具体的にはユーザー指定の構成バージョン文字列を指定します。このセクションでは、VERSION=stringが唯一のパラメータです。 stringは、現在の DMCONFIGファイルのバージョン番号を入力できるフィールドです。このフィールドはソフトウェアによってチェックされません。
|
|
|
|
|
|
1つ以上のアクセス制御リスト(ACL)の名前を指定し、1つ以上のリモート・ドメイン・アクセス・ポイントを指定された各ACL名に関連付けます。ACL=ACL_NAMEを設定して DM_EXPORTセクションで ACLパラメータを使用すると、特定のローカル・ドメイン・アクセス・ポイントを通じてエクスポートされるローカル・サービスへのアクセスを ACL_NAMEと関連付けられたリモート・ドメイン・アクセス・ポイントのみに制限できます。
|
|
|
|
|
|
特定のDomains構成に必要なパラメータを定義します。現時点で、domtypeの値には、 TDOMAIN、 OSITP、 OSITPXまたは 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セッションへの接続時に使用する接続先ネットワーク・アドレスを指定する必要があります。
|
DMCONFIGファイルの詳細は、
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
DMCONFIG(5)および
DM_MIB(5)のリファレンス・ページを参照してください。
Oracle Tuxedoのリリース7.1以降のdmunloadcfコマンドでは、デフォルトで新しいドメイン関連の用語を使用する
DMCONFIGファイルが生成されます。以前のドメイン関連の用語を使用する
DMCONFIGファイルを出力するには、
-cオプションを使用します。例:
プロンプト> dmunloadcf -c > dmconfig_prev
次のどのバッファ・タイプでも、DMCONFIGファイルの
DM_ROUTINGセクションで、ローカルのサービス・リクエストをリモート・ドメインにルーティングするためのデータ依存型ルーティング基準を指定できます。
次の例では、リモート・サービスのTOUPPERは
REMOT1および
REMOT2という2つのリモート・ドメイン・アクセス・ポイントを通じて使用でき、
TOUPPERのデータ依存型ルーティング基準は
ACCOUNTというルーティング基準表で定義されています。例の
RTOUPPER1と
RTOUPPER2は、リモート・ドメインで予期される実際のサービス名
TOUPPERの別名です。
ACCOUNTルーティング表に関して、
VIEWと
accountはこのルーティング表が有効であるデータ・バッファのタイプとサブタイプで、
branchidはルーティングが適用されるVIEWデータ・バッファのフィールドの名前です。
branchidフィールドの有効な値は次のとおりです。
|
•
|
REMOT1アクセス・ポイントの場合、有効な値の範囲は REMOT1と関連付けられたマシンで許可される最小値から1000までです。
|
|
•
|
REMOT2アクセス・ポイントの場合、有効な値の範囲は1001から3000までです。
|
TOUPPERサービス・リクエストの
branchidフィールドの値が
MIN-1000の範囲にある場合、サービス・リクエストは
REMOT1アクセス・ポイントを通じてルーティングされます。
TOUPPERサービス・リクエストの
branchidフィールドの値が
1001-3000の範囲にある場合、サービス・リクエストは
REMOT2アクセス・ポイントを通じてルーティングされます。
Oracle Tuxedoシステムには、トランザクション・タイムアウト・メカニズムと
ブロッキング・タイムアウト・メカニズムの2つのタイムアウト・メカニズムがあります。トランザクション・タイムアウトは、サービス・リクエストを処理するATMIトランザクションの期間を定義するために使用します。このタイムアウト値は、トランザクションを開始するときに定義されます。一方、ブロッキング・タイムアウトは、個々のサービス・リクエストの期間、つまり、サービス・リクエストに対する応答をATMIアプリケーションが待つ時間を定義するために使用します。
プロセスがトランザクション・モードではない場合、Oracle Tuxedoシステムによってブロッキング・タイムアウトが実行されます。プロセスがトランザクション・モードである場合は、Oracle Tuxedoシステムによってトランザクション・タイムアウトが実行されますが、ブロッキング・タイムアウトは実行されません。後者の説明は
ドメイン内トランザクション(1つのOracle Tuxedoドメイン内で処理されるトランザクション)では当てはまりますが、
ドメイン間トランザクションでは当てはまりません。
ドメイン間トランザクションでは、プロセスがトランザクション・モードである場合、Domainsソフトウェアによってトランザクション・タイムアウトとブロッキング・タイムアウトの両方が実行されます。
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値までトランザクション・タイムアウト値が制限(必要に応じて減少)されます。
|
•
|
ドメイン間トランザクションで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を参照してください。
DMCONFIGファイルの
DM_LOCALセクションでは、
BLOCKTIMEパラメータを使用してローカル・ドメイン・アクセス・ポイントのブロッキング・タイムアウトを設定できます。例:
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値はドメイン内トランザクションのタイムアウトに影響しません。
|
•
|
ON_DEMAND (デフォルト) - リモート・サービスへのクライアント・リクエストまたは管理接続コマンドのいずれかによってリクエストされたときに接続します。この接続ポリシーにおける接続の確立方法は次のとおりです。
|
|
•
|
手動によるdmadmin(1) connectコマンドの実行
|
|
•
|
ON_STARTUP - ゲートウェイ・サーバーの初期化(起動)時に接続します。この接続ポリシーにおける接続の確立方法は次のとおりです。
|
|
•
|
手動によるdmadmin(1) connectコマンドの実行
|
|
•
|
INCOMING_ONLY - 受信時に接続しますが、自動的には行いません。この接続ポリシーにおける接続の確立方法は次のとおりです。
|
|
•
|
手動によるdmadmin(1) connectコマンドの実行
|
DMCONFIGファイルの
DM_LOCALセクションでは、
CONNECTION_POLICYパラメータを使用してローカル・ドメイン・アクセス・ポイントの接続ポリシーを設定します。例:
LOCAL1 to
REMOT1 —
ON_DEMAND
LOCAL1 to
REMOT2 —
ON_STARTUP
|
注意:
|
DM_TDOMAINセクションでグローバル接続ポリシーを指定する場合は、 DM_LOCALセクションでグローバル接続ポリシーを指定しないでください。
|
リモート・ドメインの接続ポリシー機能がないと、グローバル接続ポリシーがON_STARTUPの場合に、ローカルTDomainゲートウェイはたとえ一部のリモート・ドメインが最初は使用されない場合でも起動時に
すべてのリモート・ドメインに接続しようとします。このため、リモート・ドメインの数が多い場合は起動にかなりの時間がかかります。リモート・ドメインの接続ポリシー機能を使用する場合は、グローバル接続ポリシーの
ON_STARTUPで、起動時に自動的には確立されないリモート・ドメインの接続を選択できます。
|
•
|
使用するconnection_policyパラメータ属性を指定します。TDomainセッションの接続ポリシーを指定しない場合、そのセッションの接続ポリシー属性はデフォルトで LOCALになります。
|
|
•
|
FAILOVERSEQ: TDomainセッション・フェイルオーバー・シーケンスとプライマリ・レコードを指定します。
|
|
•
|
LACCESSPOINT (LDOM): DM_LOCALセクションで指定されたローカル・ドメイン・アクセス・ポイントの名前を指定します。
|
他のTDomainセッション・パラメータおよび属性(SECURITY、
DMKEEPALIVE)も指定できます。
FAILOVERSEQ、
LACCESSPOINTおよびその他のTDomainパラメータおよび属性の詳細は、
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
DM_TDOMAINセクションの省略可能パラメータに関する項を参照してください。
リスト1-1に、TDomainセッション単位の接続ポリシーを作成するために使用する
FAILOVERSEQ、
LACCESSPOINTおよび
CONNECTION_POLICYパラメータを示します。
DM_TDOMAINセクションは、3つのTDomainセッションを含む7つのレコードから構成されています。
|
•
|
レコード4は、FAILOVERSEQがレコード7より小さいので、TDomainセッション LOCAL1,REMOT1のプライマリ・レコードです。このTDomainセッションの接続ポリシーは ON_STARTUPで、128ビットのリンク・レベル暗号化セキュリティ・ポリシーを必要とします。このレコードへの接続が失敗した場合、そのセカンダリ/バックアップ・レコードであるレコード7への接続が試行されます。
|
|
•
|
レコード7は、FAILOVERSEQがレコード4より大きいので、TDomainセッション LOCAL1,REMOT1のセカンダリ/バックアップ・レコードです。
|
|
•
|
レコード5は、TDomainセッションLOCAL2,REMOT1のプライマリ・レコードです。このTDomainセッションの接続ポリシーは INCOMING_ONLYです。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。
|
|
•
|
レコード6は、TDomainセッションLOCAL2,REMOT2のプライマリ・レコードです。このセッションの接続ポリシーは ON_DEMANDです。このセッションのセカンダリ/バックアップ・フェイルオーバー・レコードはありません。ローカル・アクセス・ポイント LOCAL2は、2つのTDomainセッション(レコード5の REMOT1と REMOT2)に接続します。
|
|
•
|
dmloadcf -yを使用して、 DMCONFIGファイルをコンパイルして BDMCONFIGファイルに変換します。
|
DMCONFIGファイルを小さくし、処理しやすくするために、
LACCESSPOINTで正規表現を使用して複数のローカル・ドメイン・アクセス・ポイントを定義できます。
|
注意:
|
DM_TDOMAINは、 DMCONFIGファイルの中で LACCESSPOINTに正規表現を指定できる唯一のセクションです。
|
DMCONFIGファイルがコンパイルされると、出力バイナリ
BDMCONFIGファイルで正規表現が完全なローカル・ドメイン名に展開されます。この結果、
リスト1-2のように、
BDMCONFIGファイルのサイズが増加します。
DM_MIBを使用してTDomainセッション情報を指定およびリクエストすると、
BDMCONFIGファイルが直接修正されます。元の
DMCONFIGファイルは修正されません。
DM_MIBの詳細は、
セクション5 - 『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
DM_MIB(5)に関する項を参照してください。
|
注意:
|
dmunloadcf >DMCONFIGを使用すると、 BDMCONFIGファイルを解析して DMCONFIGファイルの情報を更新できます。 dmunloadcfの詳細は、 1-13ページの「Domains管理ツール」を参照してください。
|
DM_MIBは、3つのT_DM_TDOMAINクラス定義属性を使用して、TDomainセッション単位の接続ポリシーを
BDMCONFIGファイルに作成します。
|
•
|
TA_DMFAILOVERSEQ: TDomainセッション・レコードのセッション接続フェイルオーバー・シーケンスとプライマリ・レコードを BDMCONFIGファイルに指定し、それらをリクエストします。
|
|
•
|
TA_DMLACCESSPOINT: TDomainセッション・レコードの DM_LOCALセクションで見つかったローカル・ドメイン・アクセス・ポイントを BDMCONFIGファイルに指定し、それらをリクエストします。
|
DM_MIBを使用して、
BDMCONFIGファイルのTDomainセッション・レコードを追加、削除または検索できます。TDomainセッション・レコード情報を追加、削除、または検索するには、該当するすべてのT_DM_TDOMAINクラス定義キー・フィールドを使用する必要があります。
リクエストされたレコードはBDMCONFIGファイルで無効としてマークされているので、TDomainセッションには含まれていません。
DMADMINでTDomainセッション情報を指定およびリクエストする場合の効果は、
DM_MIBを使用する場合とほぼ同じです。つまり、
DMADMINを使用すると、
BDMCONFIGファイルが修正されますが、元の
DMCONFIGファイルは修正されません。
DMADMINは、3つのフィールド識別子を使用して、TDomainセッション単位の接続ポリシー・レコードを
BDMCONFIGファイルに追加します。
|
•
|
TA_DMFAILOVERSEQ: TDomainセッション・レコードのセッション接続フェイルオーバー・シーケンスとプライマリ・レコードを BDMCONFIGファイルに指定し、それらをリクエストします。
|
|
•
|
TA_LDOM: TDomainセッション・レコードのDM_LOCALセクションで見つかったローカル・ドメイン・アクセス・ポイントをBDMCONFIGファイルに指定し、それらをリクエストします。
|
TA_DMFAILOVERSEQ、
TA_LDOM、
TA_CONNECTION_POLICYおよびその他のフィールド識別子の詳細は、
『Oracle Tuxedoコマンド・リファレンス』の
dmadmin(1)に関する項を参照してください。
DMADMINを使用して、TDomainセッション・レコードを追加、削除または検索できます。次に、
DMADMINを使用してTDomainセッション接続ポリシー・レコードを
BDMCONFIGファイルに追加する例を示します。
混在アプリケーション環境では、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_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ゲートウェイで使用される自動接続再試行の基準になります。
|
•
|
ON_DEMANDの場合、ローカル・ドメイン・ゲートウェイはリモート・ドメインからインポートされたサービスを継続的に通知します。
|
|
•
|
ON_STARTUPの場合、ローカル・ドメイン・ゲートウェイはリモート・ドメインからインポートされたサービスを、そのリモート・ドメインとの接続が存在するかぎり通知します。
|
|
•
|
INCOMING_ONLYの場合、ローカル・ドメイン・ゲートウェイは受信接続で、または dmadmin connectコマンドの発行時にリモート・ドメインからインポートされたサービスを通知します。
|
接続ポリシーがON_STARTUPまたは
INCOMING_ONLYの場合(
ON_DEMANDは除く)、TDomainゲートウェイの機能である
動的ステータスはリモート・サービスのステータスを調べます。リモート・サービスのステータスは、ローカル・ドメイン・ゲートウェイとリモート・ドメイン・ゲートウェイのネットワーク接続のステータスによって決まります。リモート・サービスは、そのサービスのあるドメインへの接続が正常に確立されるたびにローカル・ドメインで通知されて利用可能になります。リモート・サービスは、そのサービスのあるドメインとの接続が切れるたびに中断されて利用不能になります。
たとえば、DMCONFIGファイルの
DM_IMPORTセクションで次のようなエントリを指定することで、RSVCというサービスを2つのリモート・ドメインからインポートするとします。
REMOT1および
REMOT2両方への接続が可能な場合、ドメイン・ゲートウェイは、
RSVCサービスに対するリクエストのロード・バランシングを実行します。
REMOT1への接続が不可能になると、ゲートウェイは、
RSVCサービスへのすべてのリクエストを
REMOT2に送信します。接続が両方とも不可能になると、ゲートウェイは、掲示板の
RSVCを中断します。
RSVCに対する以降のリクエストは、ローカル・サービスにルーティングされるか、または失敗して
TPENOENTが返されます。
|
•
|
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の T_DM_TDOMAINクラスの定義に関する項
|
DMCONFIGファイルの
DM_IMPORTセクションでは、Domains構成のDomainsレベルのフェイルオーバーおよびフェイルバック機能を設定できます。
DMCONFIGファイルの
DM_TDOMAINセクションでは、Domains構成のDomainsリンク・レベルのフェイルオーバー機能を設定できます。
この例で、TOUPPERサービスは
REMOT1 (プライマリ)、
REMOT2および
REMOT3の3つのリモート・ドメイン・アクセス・ポイントのいずれかで実行できます。
REMOT1が利用できなくなると、
REMOT2がフェイルオーバーに使用されます。
REMOT1と
REMOT2が両方とも使用できない場合は、
REMOT3がフェイルオーバーに使用されます。
サービスの代替リモート・ドメインを構成する必要がある場合は、ON_STARTUPまたは
INCOMING_ONLYを
CONNECTION_POLICYパラメータの値として指定します。接続ポリシーとして
ON_DEMANDを指定すると、
RACCESSPOINTパラメータで指定された代替リモート・ドメインに「フェイルオーバー」できません。
|
•
|
手動によるdmadmin connectコマンドの実行
|
最初のエントリはプライマリ・アドレスとみなされます。つまり、そのNWADDRはリモート・ドメイン・アクセス・ポイントへの接続が試行されるときに試される最初のネットワーク・アドレスです。2番目のエントリは二次アドレスと見なされます。つまり、その
NWADDRは一次アドレスを使用して接続を確立できないときに試される2番目のネットワーク・アドレスです。
表1-4に、Domainsのキープ・アライブに関する主要な情報を示します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* TCPレベルのキープ・アライブでTDomainゲートウェイ接続の失敗を迅速に検出するには、このキープ・アライブの時間間隔を短く設定する必要があります。このように設定すると、TCPパケットでネットワークがいっぱいになる可能性があります。
|
TCPKEEPALIVEの有効な値は次のとおりです。
|
•
|
LOCAL (リモート・ドメイン・アクセス・ポイントでのみ有効)
|
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
LOCAL1から
REMOT1 - TCPレベルのキープ・アライブ有効
LOCAL1から
REMOT2 - TCPレベルのキープ・アライブ無効
Domains接続の接続ポリシーがON_STARTUPで、TCP接続がTCPレベルのキープ・アライブの障害によりクローズしている場合は、自動接続再試行が行われます。接続の再試行が成功しない場合は、
dmadmin connectコマンドを使用して接続を再確立する必要があります。
dmadmin connectコマンドの詳細は、
2-65ページの「ドメイン間の接続の確立」を参照してください。
DMKEEPALIVEパラメータでは、Domains接続でトラフィックを受信することなくローカルTDomainゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイからアプリケーション・レベル・キープ・アライブ・リクエスト・メッセージが送信されます。
DMKEEPALIVEの有効な値は次のとおりです。
|
•
|
1 <= value <= 2147483647 (キープ・アライブ有効)。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます
|
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秒
|
•
|
1 <= value <= 2147483647。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます
|
|
•
|
1 <= value <= 2147483647。値はミリ秒単位ですが、現在はDomainsソフトウェアによって最近の秒に丸められます
|
|
1.
|
テキスト・エディタでUBBCONFIGファイルを編集し、Domains管理サーバーとTDomainゲートウェイ・サーバーを構成します。例:
|
|
注意:
|
この例では、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_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サーバーはアプリケーション・サーバーの前に起動する必要があります。
|
リスト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_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とドメイン・ゲートウェイ・グループは、同じマシンに移行する必要はありません。
|
DMADMを新しいマシンに移行するには、次の手順に従います。
|
1.
|
DMCONFIGを新しいマシンにコピーし、 dmloadcfを実行します。
|
|
1.
|
DMCONFIGファイルの DM_TDOMAINセクションに、次の形式で複数のリスニング・アドレスを追加します。
|
|
4.
|
新しいマシンでGWADMおよび GWTDOMAINサーバー・プロセスをアクティブにします。詳細は、次のセクションを参照してください。
|
|
•
|
コマンドtmboot(1) ( -sコマンド行オプションを指定)
|
|
•
|
GWTDOMAINによって実行される通知/通知取消しのメカニズムとは異なり、リモート・ドメインによってエクスポートされたインポート・サービスはBBに直接追加され、RDMAキュー・アドレスを介して起動されます。
|
|
•
|
BYPASSDOM_SHARED_DIRで指定されるディレクトリに、「 .」+「 DOMGLOBAL」+「 _」+「 BYPASSDOM_ID」+「 _」+「 BYPASSDOM_SEQ_NUM」という修正ファイル名のOracle Tuxedoファイル・システムが自動的に作成されます。これは、複数のドメイン間で情報を交換する際のメディアです。
|
|
•
|
GWTDOMAINがTMSとしてトランザクションに参加することはありません。ただし、必要なTMSサービスのBBへのインポートは、ローカル・ドメインが行います。これによって、トランザクションを実行でき、2つのドメイン間で必要な情報が交換されます。
|
|
•
|
GWTDOMAINは、デフォルトではバイパス・ドメイン・モデルで機能します。または、 DMCONFIGに THROUGHGATEWAY=Yを指定することで、非バイパス・ドメイン・モデルでも機能できます。
|
|
•
|
GWTDOMAINは、リモート・ドメインの機能を検索し、この機能を利用できるかどうかを判断します。 GWTDOMAINは、反対側のドメインの設定に応じて、バイパス・ドメイン・モデルおよび非バイパス・ドメイン・モデルの両方で機能することがあります。ただし、同じ接続の場合、つまり特定のリモート・ドメイン・ゲートウェイの場合は、バイパス・ドメインまたは従来のドメインのいずれかになります。
|
|
•
|
イベント・ブローカは、GWTDOMAINがバイパス・モデルとして指定されている場合であっても、非バイパス・ゲートウェイとしてのみ提供されます。
|
|
•
|
1つのドメインで複数のGWTDOMAINによってエクスポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。
|
|
•
|
複数のGWTDOMAINによってインポートされた場合でも、リモート・サービスはローカル・ドメイン内で1つのサービスとしてインポートされます。
|
|
|
|
|
|
|
GWTDOMAINがバイパス・ドメイン・モデルで実行されている場合、 ON_DEMANDを指定しないでください。それ以外の場合、 ON_DEMANDは自動的に ON_STARTUPとして扱われ、 GWTDOMAINは LIBGWT_CAT XXXX、バイパス・ドメイン・モードでON_DEMANDのかわりにON_STARTUPが適用されましたというメッセージを出力します。
|
|
|
|
各リモート・ドメインには、一意のBYPASSDOM_SEQ_NUMを付ける必要があります。接続しているドメイン上のサービスのみがインポートされます。
|
|
|
|
|
|
|
メッセージングまたはGWTDOMAINのプロトコルによってトリガーされる、 GWTDOMAIN間でのデータ送信で機能します。ただし、ATMIコールのメッセージングでは、指定の暗号化方法は使用されなくなりました。
|
|
|
|
|
|
|
|
|
|
|
|
メッセージングまたはGWTDOMAINのプロトコルによってトリガーされる、 GWTDOMAIN間でのデータ送信で機能します。ただし、ATMIコールのメッセージングでは、指定の暗号化方法は使用されなくなりました。
|
|
|
|
|
|
|
|
DM_REMOTEセクション内のACLが LOCALとして構成されている場合は、非バイパス・ドメイン・モデルでのみ機能します。
|
|
|
|
|
|
|
|
