Oracle Tuxedo Domains コンポーネント

Domains の管理

以下の節では、Oracle Tuxedo Domains 環境を管理する方法について説明します。

Domains の実行時管理コマンドを使用する

Domains コンポーネントを既存の Oracle Tuxedo アプリケーションと統合するには、ドメイン ゲートウェイ グループとゲートウェイ サーバのエントリを TUXCONFIG ファイルに追加します。実行中の Oracle Tuxedo アプリケーションに Domains コンフィグレーションを追加するには、tmconfig(1) または tmadmin(1) コマンドを使用します。tmadmin を使用すると、ドメイン ゲートウェイ グループや個々のドメイン ゲートウェイの掲示板で使用できる情報をリストすることもできます。

Domains 環境を設定し、統合すると、Domains コンポーネントに用意されている一連の管理ツールを使用して、Domains 環境を動的に管理できます。たとえば、アプリケーションのどこからでもアクセスできるサービスをリスト化したり、そのリストを変更することができます。Domains ソフトウェアには、Oracle Tuxedo のプログラミング インタフェース (ATMI) の機能に加え、拡張された機能が備わっているため、クライアントはドメイン内のあらゆるサービスを呼び出すことができます。この機能により、プログラマは、アプリケーション コードを変更せずに、アプリケーションを拡張したり、分割できます。

次の図は、Domains の管理サブシステムにおける管理コマンドと管理サーバの関係を示します。

Oracle Tuxedo Domains コンポーネントには、次の管理コマンドが用意されています。

管理インタフェース dmadmin(1) を使用する

dmadmin は、DMADM サーバ用の GWADM サーバへの管理インタフェースです。これらの 2 つのサーバ間の通信は、FML の型付きバッファを使用して実行されます。管理者は、dmadmin コマンドを使用して、次の作業を実行できます。

関連項目

Domains 管理サーバ DMADM(5) を使用する

Domains の管理サーバである DMADM(5) は、Oracle Tuxedo に組み込まれているサーバであり、以下の機能を実行します。

DMADM サーバは、次の 2 つのサービスを宣言します。

DMADM サーバは、グループ内で実行しているサーバ (DMADMGRP など) として TUXCONFIG ファイルの SERVERS セクションで定義されている必要があります。このグループには、DMADM サーバのインスタンスが 1 つのみ必要です。

関連項目

ゲートウェイ管理サーバ GWADM(5) を使用する

ゲートウェイ管理サーバ GWADM(5) は、Oracle Tuxedo に組み込まれているサーバであり、ドメイン ゲートウェイ グループ用の管理機能を提供します。GWADM サーバの主な機能は、以下のとおりです。

GWADM サーバは、GWADM サーバが属するドメイン ゲートウェイ グループに関連付けられたローカル ドメイン アクセス ポイントの名前 (BDMCONFIG ファイルの DM_LOCAL セクションで指定) に基づいてサーバ名を宣言します。dmadmin コマンドは、このサービスを使用して、アクティブなすべてのドメイン ゲートウェイ グループまたは特定のドメイン ゲートウェイ グループから、情報を取り出します。

GWADM サーバは、TUXCONFIG ファイルの SERVERS セクションで定義しておく必要があります。グループに関連するゲートウェイが使用する MSSQ の一部として指定することはできません。また、ドメイン ゲートウェイ グループ内で最初に起動されるサーバでなければなりません。つまり、SEQUENCE で番号が指定されているか、またはゲートウェイ サーバより先に定義されていなければなりません。

GWADM サーバには DMADM サーバが必要です。具体的には DMADM サーバを起動してから、GWADM を起動する必要があります。

GWADM サーバは、ドメイン ゲートウェイ グループに必要な共有メモリを作成し、DMADM サーバから受け取る情報をコンフィグレーション テーブル内に設定しなければなりません。GWADM サーバは shmget で IPC_PRIVATE を使用し、掲示板のレジストリ エントリにある shmid フィールドに返された ipckey を格納します。ゲートウェイは、GWADM レジストリ エントリを取得し、shmid フィールドをチェックすることにより、ipckey を取得できます。

関連項目

ドメイン ゲートウェイ サーバを使用する

ドメイン ゲートウェイ サーバは、リモート ドメイン ゲートウェイ サーバへの接続を実現し、1 つ以上のリモート ゲートウェイと同時に通信することができます。ゲートウェイは、Oracle Tuxedo アプリケーションにインポートされたサービスを宣言し、アプリケーションによってエクスポートされたローカル サービスへのアクセスを制御します。アプリケーションのエクスポートされたサービスとインポートされたサービスは、Domains コンフィグレーション ファイル (DMCONFIG) で定義します。ドメイン ゲートウェイ グループを動的にコンフィグレーション、モニタ、および調整するには、dmadmin を使用します。

関連項目

ドメイン ゲートウェイのパフォーマンスをチューニングする

Oracle Tuxedo 9.x では、GWTDOMAIN ゲートウェイのパフォーマンスの向上を実現しつつ、ほかのタイプのドメイン ゲートウェイとの互換性を保持しています。このため、パフォーマンスの大部分はスレッド対応プラットフォームに制限されます。また、プログラムを一部変更するだけで、ほかのタイプのドメイン ゲートウェイも、拡張された共通ゲートウェイ アーキテクチャでこの機能を利用できます。

複数のドメインにわたるアプリケーションのパフォーマンスは、さまざまな要因の影響を受けます。たとえば、以下のような要因です。

このため、ドメイン ゲートウェイのパフォーマンスの向上を実感するには、アプリケーションで上記の要因を最小限に抑える必要があります。そのようにしない場合、ゲートウェイのパフォーマンスはさほど向上しない場合があります。

次に、パフォーマンスに関する推奨事項を示します。

Domains 環境でのトランザクションの管理

アプリケーション プログラマは、トランザクションでリモート サービスの実行を要求することができます。また、リモート ドメインのユーザが、トランザクションでローカル サービスの実行を要求することもできます。Domains は、リモート トランザクションをローカル トランザクションにマッピングしたり、これらのトランザクションが正しく終了 (コミットまたはロールバック) されるように調整する役割を果たします。

Oracle Tuxedo のシステム アーキテクチャでは、トランザクション マネージャ サーバ (TMS: Transaction Manager Server) という別個のプロセスにより、特定のグループにアクセスするトランザクション ブランチのコミットや回復が調整されます。ただし、Domains 環境で、受信したトランザクションのコミット操作を処理するには、ゲートウェイから TMS サーバに別途メッセージを送信しなければなりません。Domains のアーキテクチャを単純化し、送信メッセージの数を抑えるため、TMS コードは、ゲートウェイ コードと統合されています。これで、ドメイン ゲートウェイは、Oracle Tuxedo システムで使用されるトランザクション プロトコルを処理できます。Oracle Tuxedo のトランザクション プロトコルを使用するには、ドメイン ゲートウェイ グループで TMS サービスが宣言されていなければなりません。この宣言は、最初のゲートウェイの起動時に実行されます。いったん TMS サービスが宣言されると、ドメイン ゲートウェイ グループ宛てのトランザクション コントロール メッセージは、すべてゲートウェイのキューに登録されます。

ドメイン ゲートウェイ グループは、TUXCONFIG ファイルで定義されており、TMSNAME、TMSCOUNT、OPENINFO、CLOSEINFO の 4 つのパラメータは指定されません。これらのパラメータは、XA 対応のリソース マネージャを使用するゲートウェイ グループにのみ適用されるためです。ドメイン ゲートウェイは、このリソース マネージャを使用しません。

ドメインのコミット プロトコルは厳密な階層構造になっています。トランザクション ツリーを水平に構成することはできません。上位ドメインが認識するのは、すぐ下の下位ドメインだけであり、各ドメインがトランザクション ツリー全体を把握しているわけではないためです。ツリーを水平に構成すると、トランザクションに参加しているすべてのドメインにルート ドメインを完全に接続することも必要になります。

ドメイン ゲートウェイには、トランザクションを管理するための 4 つの機能が用意されています。これらの機能については、以下の節を参照してください。

Domains で TMS 機能を使用する

Oracle Tuxedo システムの TMS は、X/Open XA 準拠のリソース マネージャを使用するサーバ グループと暗黙的に関連付けられた特別なサーバです。TMS サーバは、分散型の 2 フェーズ コミット プロトコルに伴うアプリケーション サーバでの遅延を解消します。つまり、TMS サーバは、TMS サービスに対して特殊なサービス要求を発行することにより、トランザクションのコミットを調整します。このサービスは、すべての TMS サーバで提供されます。

一方、Domains 環境では、GWTDOMAIN ゲートウェイは XA 準拠のリソース マネージャと関連付けられていません。X/Open のトランザクション処理委員会 (TPWG: Transaction Processing Working Group) は、高度な XA インタフェースを提案しましたが、このインタフェースは、非同期性が高く、非ブロッキング モデル型のゲートウェイには不適切なため、Oracle Tuxedo システムでは使用されていません。ドメイン ゲートウェイは、専用の TMS サーバは使用しませんが、トランザクション マネージャ サーバと同等の機能、つまり、ドメイン間で実行されるトランザクションの 2 フェーズ コミットを調整します。

ドメイン ゲートウェイは、次のようにしてドメインをまたがるトランザクションを調整します。

トランザクションで GTRID マッピングを使用する

Oracle Tuxedo システムのトランザクション ツリーは、2 レベルで構成されています。ルートには、グローバル トランザクションを調整するドメイン ゲートウェイ グループがあり、トランザクションはブランチに含まれます。各ゲートウェイ グループは、ほかのグループからは独立して、グローバル トランザクションの一部を実行します。したがって、各グループは、暗黙的にトランザクション ブランチを定義します。Oracle Tuxedo システムは、TMS サーバを使用して、各ブランチの完了を確認しながら、グローバル トランザクションの完了を調整します。

GTRID は、グローバル トランザクションの識別子です。GTRID マッピングでは、ドメインの境界をまたぐトランザクション ツリーの構築方法を定義します。GTRID を指定するには、Oracle Tuxedo コンフィグレーション ファイルの RESOURCES セクションの MAXGTT パラメータを使用します。

密結合関係と疎結合関係の定義

X/Open DTP モデルのトランザクション マネージャ サーバ (TMS) は、リソース マネージャ (RM) との関係を表すトランザクション ツリーを構築できます。関係は「密結合」または「疎結合」で定義し、XA インタフェースで使用されるトランザクション識別子 (XID) が使用されます。

「密結合関係」では、1 つのグローバル トランザクションに参加するすべてのプロセスで同じトランザクション識別子 (XID) が使用され、同じ RM へのアクセスが行われます。この関係が確立されていると、プロセス間のデータ共有性を最大化できます。つまり、XA 準拠の RM では、同じ XID のプロセスによって使用されるリソースがロックを共有すると見なされます。Oracle Tuxedo システムでは、「グループ」の概念に基づいて密結合関係を実現します。つまり、指定されたグローバル トランザクションの代わりに、グループがすべての作業を行い、それらの作業は同じトランザクション ブランチに設定されます。グループが行ったすべてのプロセスには、同じ XID が指定されます。

「疎結合関係」の TMS は、グローバル トランザクションに参加する各作業に対して、トランザクション ブランチを生成します。RM は、各トランザクション ブランチを別々に処理します。トランザクション ブランチ間では、データやロックは共有されません。トランザクション ブランチ間でデッドロックが発生すると、グローバル トランザクションがロールバックされます。Oracle Tuxedo アプリケーションでは、1 つのグローバル トランザクションにさまざまなグループが参加している場合、グループごとに別のトランザクション ブランチが定義され、疎結合関係が確立されます。

Domains をまたがるグローバル トランザクション

単独の Oracle Tuxedo アプリケーション内のグローバル トランザクションと、ドメインをまたがるグローバル トランザクションとでは、いくつかの違いがあります。最大の相違点は、Domains のフレームワークでは、トランザクション ツリーの構成を 2 レベルに下げることができないことです。これには、次の 2 つの理由があります。

つまり、ドメインをまたがるコミット プロトコルは、階層型でなければなりません。ループバックされたサービス要求も、トランザクション ツリーでは新しいブランチとして定義されます。

ドメインをまたがるグローバル トランザクションのトランザクション ツリー構造は、対応するドメイン ゲートウェイのインスタンスが使用する分散トランザクション処理プロトコルにも依存します。たとえば、OSI TP プロトコルのダイアログ (OSI TP でのサービス要求) は、それぞれ別のトランザクション ブランチに関連付けられています。Oracle Tuxedo システムでは、OSI TP インスタンスがサービス要求でダイアログを使用するため、各サービス要求は別のトランザクション ブランチにマッピングされます。XAP-TP インタフェースは、このマッピングを隠し、ユーザ定義の識別子を使用して OSI TP サブツリー全体を参照するようなメカニズムを提供します (Oracle Tuxedo の実装では、この識別子は GTRID になります)。GTRID は、トランザクション ツリーの構築方法を XAP-TP に指示します。つまり、指定された OSI TP トランザクションに含めるダイアログを指定します。したがって、Oracle Tuxedo からは、OSI TP サブツリー全体が 1 つのトランザクション ブランチとして管理されているように見えます。

しかし、この特徴は、ルート ドメインから下位ドメインに送信されるサービス要求にのみ適用されます。逆方向で送信されるサービス要求には適用されません。OSI TP のインスタンスは、続いて疎結合関係をインプリメントします。受信したサービス要求は、新しい Oracle Tuxedo グローバル トランザクションにマッピングされます。

TDomain のインスタンスは、密結合関係を実現することにより、GTRID のマッピングを最適化しようとします。TDomain では、同じグローバル トランザクションから発行された複数のサービス要求は、同じネットワーク トランザクション ブランチにマッピングされます。したがって、受信したサービス要求は、1 つの Oracle Tuxedo トランザクションにマッピングされます。ただし、ドメイン間通信の階層構造とドメイン間の関係を示すトランザクション ツリーは保持される必要があります。

TDomain による最適化処理は、単一のドメインに対してのみ適用されます。トランザクションに複数のドメインが関係する場合、ネットワーク トランザクション ツリーには、ドメイン間の通信ごとに少なくとも 1 つのブランチが必要です。したがって、ドメインにまたがるネットワーク トランザクション ツリーは、疎結合のままになります。トランザクション ブランチの数は、トランザクション内のドメイン数になります。これは、すべてのブランチが同じリソース マネージャのインスタンスにアクセスしている場合も同じです。

ドメイン ゲートウェイ グループは、ドメイン間のトランザクションに対して異なるトランザクション ブランチを生成するため、疎結合関係をインプリメントします。

ローカル要求とリモート要求を生成するサービス要求グラフの例

次の図に、3 つのサービス要求 (1 つのローカル要求 (r0) と 2 つのリモート要求 (r2 および r3)) を生成するクライアントのサービス要求のグラフを示します。r0 は、ローカル サービス (Svc0) に送信され、別のリモート サービス要求 (r1) を生成します。r1 はリモート サービス Rsvc1 に送信され、Rsvc1 は、ループバック サービス要求 r4 をローカル サービス Svc4 に送信します。Svc0 と Svc4 は、別々のグループ (G0 と G4) で実行されます。ドメイン ゲートウェイは、ほかのグループ (GW) 内で実行され、リモート サービス Rsvc1、Rsvc2、および Rsvc3 は別のドメイン (ドメイン B) で実行されます。

Oracle eLink OSI TP と Oracle Tuxedo Domains のトランザクション ツリー

次の 2 つの図は、Oracle eLink OSI TP のトランザクション ツリーと、Oracle Tuxedo ドメインのトランザクション ツリーを示します。これらの図では、ドメイン A とドメイン B が Oracle Tuxedo システムのアプリケーションであることを想定しています。

Oracle eLink OSI TP は、OSI TP プロトコルを使用しているため、疎結合です。このインスタンスのトランザクション ツリーでは、ドメイン A (クライアントが開始したグローバル トランザクションを調整) 内にグループ G0 が示されています。グループ G0 は、グループ GW を調整します。r1、r2、および r3 の 3 つの要求は、それぞれ別の OSI TP ダイアログにマッピングされ、次に 1 つの OSI TP のトランザクション ブランチにマッピングされます。ただし、OSI TP は、XAP-TP の機能を使用して、ユニークな識別子 (T1) で OSI TP トランザクション全体を参照し、r1、r2、および r3 の 3 つの要求にも使用します。OSI TP トランザクション識別子を作成し、対応する OSI TP トランザクション ツリーを構築するかどうかは、XAP-TP に依存します。一般的な Domains ソフトウェアでは、r1、r2、および r3 の 3 つの要求の T1 識別子へのマッピングが、必ず実行される唯一の処理です。

Domain B では、新しい Oracle Tuxedo トランザクションには新しいトランザクション ブランチをマッピングする、という OSI TP の規則が使用されます。したがって、OSI TP トランザクション ブランチである r1、r2、および r3 は、3 つの異なる Oracle Tuxedo トランザクション (T2、T3、および T4) にマッピングされます。グラフでは、Domain B のドメイン ゲートウェイ グループ GW が、グループ G1 での 3 つの Oracle Tuxedo トランザクションを調整します。

ループバックのサービス要求 r4 は、トランザクション ツリーに別のブランチを生成します。OSI TP は、この要求を識別子 T2 にマッピングしますが、XAP-TP は、トランザクション ツリーに新しいブランチを生成します。r4 の場合は、B から A' のブランチです。生成されたブランチは、ドメイン A の新しいトランザクション ブランチであるため、ゲートウェイは新しい Oracle Tuxedo トランザクションに対する新しいマッピング T5 を生成します。トランザクション グラフでは、ドメイン A のドメイン ゲートウェイ グループ GW が、グループ G4 を調整する様子を示します。

これらのマッピング関係により、OSI TP プロトコルの階層構造は強化されます。ただし、これらのマッピング関係は疎結合であるため、トランザクション内でデッドロックが発生する可能性が高まります。たとえば、グループ G1 が示す RM には、3 つの Oracle Tuxedo トランザクションがアクセスします。

TDomain のインスタンスは、密結合関係を使用してドメインを統合する、つまり、2 つのドメイン間の処理で必要なトランザクション ブランチの数を減らすことにより、このデッドロックを解決します。次の図は、この関係を表すトランザクション ツリーを示しています。

ここでも、ゲートウェイでは、Oracle Tuxedo システムのトランザクションとネットワーク トランザクションのマッピングを行わなければなりません。また、ドメイン間の階層構造も維持されていなければなりません。この図では、r1、r2、および r3 の 3 つの要求が、1 つの TDomain トランザクション ブランチにマッピングされています。したがって、ドメイン B で生成される必要があるのは、1 つの Oracle Tuxedo システムのトランザクションだけです。T2 は、このマッピングを表します。グラフでは、ドメイン B のドメイン ゲートウェイ グループ GW が、グループ G1 を調整する様子を示します。要求 r4 は、Domain B の識別子 T2 にマッピングされますが、TDOMAIN はトランザクション ツリーに新しいブランチを生成します。r4 の場合は、B から A' のブランチです。生成されたブランチは、ドメイン A の新しいトランザクション ブランチであるため、ゲートウェイは新しい Oracle Tuxedo トランザクションに対する新しいマッピング T3 を生成します。グラフでは、ドメイン A のドメイン ゲートウェイ グループ GW が、グループ G4 も調整する様子を示します。このマッピング関係により、ドメイン間通信の階層構造は強化されます。グループ G4 は、グループ G1 より先にコミットすることはできません。

Domains でのトランザクション管理のまとめ

Domains でのトランザクション管理は、次のようにまとめることができます。

ログ機能によるトランザクションの追跡

ログ機能は、2 フェーズ コミット プロトコルの進行をトラッキングするために使用します。ログの情報から、ネットワーク障害やマシンのクラッシュが発生したときに、トランザクションが完了したかどうかを確認できます。

ドメインをまたがるトランザクションが確実に処理されるようにするため、ドメイン ゲートウェイでは、ローカル識別子とリモート識別子のマッピングが記録されます。このマッピング情報に加え、Domains のトランザクション管理機能により、異なるコミット プロトコル フェーズで決定された処理と、トランザクションに関連するリモート ドメインの情報が記録されます。OSI TP の場合、XAP-TP インタフェースにより、OSI TP プロトコル マシンの回復に必要な情報が記録されます。blob (バイナリ ラージ オブジェクト) と呼ばれるこの情報は、コミット情報と同じログ レコードに記録され、回復を行うときに使用されます。

Domains のログ レコードの構造は、Oracle Tuxedo システムの TLOG の構造とは異なります。TLOG レコードのサイズは決まっており、単一のページに格納されています。一方、Domains のログ レコードのサイズは可変であり、レコードの大きさによっては、複数のページが必要な場合もあります。Domains のログ メカニズムである DMTLOG では、さまざまなサイズのログ レコードを格納できます。

TMS がドメイン ゲートウェイ グループより上位の場合は、コミットの調整のために Oracle Tuxedo の TLOG が必要です。

ログは、GWADM 管理サーバによって記録されます。ログへの書き込みは、GWTDOMAIN プロセスによって要求されますが、実際の書き込みは、GWADM プロセスによって実行されます。

各ドメイン ゲートウェイ グループには、DMTLOG というログ ファイルを作成する必要があります。DMTLOG ファイルは、DMCONFIG ファイルの DM_LOCAL セクションで定義されます。DMTLOG ファイルを作成するには、DMTLOGDEV パラメータにエントリを追加します。

DMTLOGDEV=string

string はログ ファイルの名前です。さらに、次の 2 つのオプション パラメータのどちらか、または両方を設定できます。

詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) を参照してください。

管理者は、実行時管理ユーティリティ (dmadmin) を使用して DMTLOG を作成することもできます。詳細については、『Tuxedo コマンド リファレンス』の dmadmin(1) を参照してください。

ドメイン ゲートウェイ グループの起動時に、DMTLOG が作成されていないと、ゲートウェイ サーバは、BDMCONFIG ファイルの情報に基づき、ログを自動的に作成します。

BDMCONFIG ファイルでログ デバイスが指定されない限り、ドメイン ゲートウェイ グループは、要求をトランザクション モードで実行できず、ドメイン ゲートウェイ グループは TMS サービスを提供できません。

コミット プロトコルを調整するため、ドメイン ゲートウェイでは、次の 2 つのログ レコードが必要です。

トランザクションがすべてのマシンでコミットされると、そのトランザクションのログは削除されます。

OSI TP プロトコルを使用する場合は、次の 2 つのヒューリスティックなレコードが記録されます。

ヒューリスティックなログ レコードは、管理者によって明示的に削除されない限り、削除されません。この特性は、クラッシュ時の回復処理で正しい情報を取得し、管理者に対して診断情報を提供するために必要です。

管理者は、forgettran コマンド (tmadmin(1) で実行) を使用して、不要になったヒューリスティック レコードを削除することができます。

失敗したトランザクションの回復

ドメイン ゲートウェイ グループが起動すると、ゲートウェイ サーバは、DMTLOG を自動的にウォームスタートします。ウォームスタートでは、ログがスキャンされ、未完了のトランザクションがあるかどうかがチェックされます。未完了のトランザクションが見つかると、そのトランザクションを処理するアクションが実行されます。

OSI TP では、DMTLOG 内の blob にあるトランザクション レコードが、ネットワーク アクセス モジュールに渡されます。渡された blob は、内部状態を再構築し、失敗した接続を回復するために使用されます。

ドメイン ゲートウェイ グループがローカル TMS の下位であり、ヒューリスティックな決定が行われた場合、TMS は、最終的に決定された処理を示す TMS_STATUS メッセージを生成します。