注意: | この項では、OTMQがOracle Tuxedoとどのように連携して機能するかについての高水準な概要を説明します。すでにこれらの製品相互の連携について理解している方は、この項はスキップしてもかまいません。 |
OTMQは、Oracle Tuxedoアーキテクチャに基づいて実装されており、標準的なクライアント/サーバー方式です。基本的なキューイング機能は、中心となるOTMQサーバーTuxMsgQ(5)
によって提供されます。詳細は、『Oracle Tuxedo Message Queueリファレンス・ガイド』を参照してください。
QSpaceは、OTMQの基礎となる物理ストレージであり、その中にメッセージが存在する実際の物理デバイスです。QSpaceには1つ以上のメッセージ・キューが含まれます。メッセージは、メッセージ・キューに格納されます。
クライアントがメッセージ・キューへエンキューまたはメッセージ・キューからデキューするためにキュー・サービスを呼び出すと、そのリクエストはTuxMsgQサーバーで処理されます。このサーバーは、クライアントのリクエストとして、特定のQSpaceに定義されているキューに対してメッセージを書き込み、または取得します。
ユーザーのプロセスは、直接QSpaceにアクセスできません。QSpaceを操作するすべてのリクエストは、OTMQサーバーを経由します。図1に、OTMQおよびTuxedoのアーキテクチャを示します。
さらに、ネーミング・サーバーのTMQ_NAなど、OTMQのキューイング機能を強化するいくつかのコンポーネントがあります。これらのコンポーネントの詳細は、OTMQのe-docsマニュアルの「OTMQシステム・コンポーネント」を参照してください。
OTMQの基盤となるOracle Tuxedoによって、異機種構成、分散環境でのスケーラブルな複数階層のクライアント/サーバー・アプリケーション構築のフレームワークが提供されます。
Oracle Tuxedoドメイン(Oracle Tuxedoアプリケーションともいう)は、1つのTuxedo構成ファイルによって1つの単位として管理される、Tuxedoシステム、クライアントおよびサーバー・プロセスの集まりです。Oracle Tuxedoドメインは、多数のシステム・プロセス、1つ以上のアプリケーション・クライアント・プロセス、1つ以上のアプリケーション・サーバー・プロセス、およびネットワークで接続された1つ以上のコンピュータ・マシンで構成されます。
1つのOracle Tuxedoドメインは、単一マシン(SHM)またはネットワークで結合された複数マシン(MP)のアーキテクチャが可能です。
SHMドメインは、そのすべてのOracle Tuxedoプロセスが同一の共有メモリーにアクセスする単一ノードのOracle Tuxedoドメインです。
MPドメインは、アプリケーションを複数のマシン/ノードに配置できるクラスタ環境で、クラスタのすべてのノードは単一のエンティティとして管理されます。
Oracle Tuxedoアプリケーションは、複数ドメインで構成できます。各ドメインは、それぞれ独立した管理対象の単位です。Oracle Tuxedoでは、アプリケーションを複数のドメインに分けながら、1つのドメインにあるアプリケーションのように他のドメインのサービスにアクセスできます。
企業のビジネスが拡大するにつれ、アプリケーションの設計者は、ビジネス情報の管理を、機能、所在地または機密性に基づき、管理上の自律性を備えたそれぞれ個別のアプリケーションに編成する必要に迫られます。それらの独立したビジネス・アプリケーションは、いくつかのドメインとして構成できます。Oracle Tuxedo Domainsコンポーネントにより、ビジネスのドメイン間の相互運用を実現するインフラストラクチャが提供され、それによってOracle Tuxedoのクライアント/サーバー・モデルが複数ドメインに拡張されます。
Oracle Tuxedoドメインのドメイン間通信には、ドメイン・ゲートウェイが使用されています。ドメイン・ゲートウェイは、非同期性の高いマルチタスク型のサーバー・プロセスであり、リモート・ドメインとの間で送受信されるサービス・リクエストを処理します。これらにより、ドメイン間でのサービスへのアクセスがアプリケーション・プログラマとアプリケーション・ユーザーのどちらにも透過的になります。
詳細は、『Oracle Tuxedo Domainsコンポーネントの使用』を参照してください。
Oracle Tuxedoの構成ファイルは、Oracle Tuxedoアプリケーションの記述に使用されます。構成ファイルとは、アプリケーションの起動と実行に必要なすべての情報(アプリケーションのリソース、マシン・グループ、サーバー、および利用可能なサービス、インタフェースなどの仕様)が格納されたリポジトリです。
SHM/MPドメインの構成ファイルはUBBCONFIGです。これは構成ファイルのテキスト版で、任意のテキスト・エディタで作成および編集できます。構成ファイルを使用してアプリケーションを起動する前に、tmloadcf(1)コマンドにより、テキスト版からバイナリ版の構成ファイルTUXCONFIGを作成する必要があります。
複数ドメインで構成されるアプリケーションの場合は、ドメイン接続のための追加の構成ファイルがあります。UBBCONFIGと同様に、DMCONFIGはテキスト版の構成ファイルで、複数のドメインの接続方法および相互にアクセス可能とするサービスを記述します。ドメインの構成ファイルのバイナリ版BDMCONFIGは、dmloadcf(1)ユーティリティを使用して作成します。
詳細は、「構成ファイルについて」および「構成ファイルの作成」を参照してください。
UBBCONFIGファイルは、次の9つのセクションで構成されます。
*RESOURCES
、*MACHINES
、*GROUPS
、*SERVERS
、 *SERVICES
、*INTERFACES
、*NETWORK
、*NETGROUPS
、*ROUTING
。
*RESOURCES
セクションでは、システムのデフォルトとして、アプリケーション全体とサーバーを制御するパラメータを定義します。
*MACHINES
セクションでは、アプリケーション内の各マシンに対するパラメータを定義します。
*GROUPS
セクションでは、論理的にグループ化されるサーバーのセットを指定します。少なくとも、1つのマシンに1つのサーバー・グループを定義する必要があります。
*SERVERS
セクションには、サーバー・プロセスに固有の情報が含まれています。このセクションの各エントリは、アプリケーションで起動されるサーバー・プロセスを表します。
*SERVICES
セクションには、サーバー・プロセスによって通知されるサービスについての情報が含まれています。
詳細は、『Oracle Tuxedoリファレンス・ガイド』の第5章「ファイル形式、データ記述、MIBおよびシステム・プロセスのリファレンス」のUBBCONFIG(5)に関する項を参照してください。
ドメイン構成ファイルDMCONFIGは、ローカル/リモート・ドメインのアクセス・ポイント、および各アクセス・ポイント経由で使用可能なローカル/リモートのサービスを定義します。アプリケーションのクライアントは、これらのアクセス・ポイント経由でサービスにアクセスできます。またそれは、ローカル・アクセス・ポイントおよびリモート・アクセス・ポイントを、特定のドメイン・ゲートウェイのグループおよびUBBCONFIGに定義されるネットワーク・アドレスにマッピングします。
DMCONFIGファイルは、次の詳細セクションから構成されます: *DM_LOCAL
、*DM_REMOTE
、*DM_EXPORT
、*DM_IMPORT
、*DM_RESOURCES
、*DM_ROUTING
、*DM_ACCESS_CONTROL
、*DM_TDOMAIN
。
*DM_LOCAL
セクションでは、1つまたは複数のローカル・ドメイン・アクセス・ポイント識別子と、それらに関連付けるゲートウェイ・グループを定義します。それと関連して、*DM_REMOTE
セクションでは、1つまたは複数のリモート・ドメイン・アクセス・ポイント識別子とそれらの特性を定義します。
*DM_EXPORT
セクションでは、各ローカル・ドメイン・アクセス・ポイントによってエクスポートされるサービスについての情報を指定します。そして、*DM_IMPORT
セクションでは、*DM_REMOTE
セクションで定義されているリモート・ドメイン・アクセス・ポイントを介してローカル・ドメインにインポートおよび提供されるサービスに関する情報を指定します。
詳細は、『Oracle Tuxedoリファレンス・ガイド』の第5章「ファイル形式、データ記述、MIBおよびシステム・プロセスのリファレンス」のDMCONFIG(5)に関する項を参照してください。
Oracle Tuxedoシステムのワークステーション・コンポーネントを使用すると、サーバー側の機能がフル・インストールされていないマシン、つまり管理サーバーもアプリケーション・サーバーもサポートしないマシンに、アプリケーション・クライアントを収容できます。ワークステーション・クライアント(ワークステーション・コンポーネント上で動作するアプリケーション・クライアント)とサーバー・アプリケーションの間の通信は、すべてネットワーク経由で行われます。詳細は、『Oracle Tuxedo ATMIワークステーション・コンポーネントの使用』を参照してください。
クライアント/サーバー・アプリケーションのための基本的なフレームワークであるばかりでなく、Oracle Tuxedoでは、次のような一連の先進的な機能が提供されます。
Oracle Tuxedoをベースにビルドされたアプリケーションでは、単一のサーバーに存在する単一のクライアントでも、または数千のクライアントとサーバーでも、アプリケーションのコードを変更することなくサポートできます。Oracle Tuxedoシステムは、アプリケーションの拡張に応じてエンドユーザーに高いパフォーマンスと応答性を提供し続けます。
数千個もの独立したプロセッサとプロセスが存在する分散クライアント/サーバー環境において、Oracle Tuxedoでは、レプリケートされたサーバー・グループの提供により、シングル・ポイント障害が存在しないことを保証し、障害発生後には、実行中のアプリケーションを良好な状態にリストアします。
Oracle Tuxedoのセキュリティには、認証、認可、およびOracle Tuxedoアプリケーションをネットワークにデプロイするときのデータのプライバシを保証するための暗号化が含まれています。ネットワーク・レベルおよびアプリケーション・レベルの暗号化がサポートされます。
OTMQでは、アプリケーションの要件に応じてQSpaceおよびキューをデプロイし、フレキシブルでスケーラブルなOracle Tuxedoのドメイン構成を使用できます。
基本的なOTMQアプリケーションをデプロイおよび実行するには、次の手順を実行します。
Oracle Tuxedo SHMドメイン上のOTMQアプリケーションでは、1つまたは複数のQSpaceを作成できます。各QSpaceは、OTMQサーバーTuxMsgQによって提供されるサービスにマッピングします。アプリケーションのクライアントは、まずOTMQ APIのtpqattach()
を呼び出して特定のQSpaceを利用するためキューにアタッチし、それからtpenqplus()
を呼び出してメッセージをエンキューしたり、アタッチしたキューからメッセージをデキューします。
また、図2に示すように、クライアントは、アタッチされていない別のQSpaceに属するキューにメッセージをエンキューすることもできます。
Oracle Tuxedo MPドメイン上OTMQアプリケーションでは、そのマスターおよびスレーブ・ノードごとに、1つまたは複数のQSpaceを作成できます。各QSpaceは、OTMQサーバーTuxMsgQによって提供されるサービスにマッピングします。マスターまたはスレーブ・ノードのアプリケーション・クライアントは、まずOTMQ APIのtpqattach()
を呼び出して、自身のノード上の特定のQSpaceを利用するためキューにアタッチし、それからtpenqplus()
を呼び出してメッセージをエンキューしたり、アタッチしたキューからメッセージをデキューします。
また、図3に示すように、ノードB上のクライアントは、ノードA上のアタッチされていない別のQSpaceに属するキューにメッセージをエンキューすることもできます。
OTMQアプリケーションは、複数のOracle Tuxedoドメインに渡ってデプロイできます。各ドメインは、1つまたは複数のQSpaceを持つことができます。各QSpaceは、OTMQサーバーTuxMsgQによって提供されるサービスにマッピングします。ドメインAのアプリケーションのクライアントは、まずOTMQ APIのtpqattach(3c)を呼び出し、利用する特定のQSpaceのキューにアタッチし、それからtpenqplus(3c)を呼び出してアタッチしたQSpaceに属するキューにメッセージをエンキューしたり、アタッチしたキューからメッセージをデキューします。
また、図4に示すように、ドメインB上のクライアントは、ドメインAがそのQSpaceのサービスをエクスポートしていれば、ドメインA上の別のQSpaceに属するキューにメッセージをエンキューすることもできます。
図5に示すように、OTMQアプリケーションでは、Oracle Tuxedoワークステーション・コンポーネントを使用することで、ワークステーション・クライアントを持つこともできます。
Oracle Tuxedoの管理者は、サーバーを定義し、Oracle Tuxedo Message Queue (OTMQ)コンポーネントのためのキュー・スペースおよびキューを作成します。
管理者は、TMS_TMQMをグループのトランザクション・マネージャ・サーバーとして、最低1つのキュー・サーバー・グループを定義する必要があります。
また、管理者は、キュー管理プログラムのtmqadmin(1)またはOTMQの拡張クラスを含むOTMQ_MIB()
管理情報ベース(MIB)を使用して、キュー・スペースを作成する必要があります。各キュー・スペースはリソース・マネージャ・インスタンスであり、1つのグループに単一のリソース・マネージャ(RM)だけが存在できるため、キュー・スペースとキュー・サーバー・グループは1対1のマッピングです。
管理者は、キュー・スペースに対して、アプリケーション構成内に単一のサーバー・グループを定義でき、その場合は、UBBCONFIGにグループを指定するか、またはtmconfig
を使用してグループを動的に追加します。
キューを定義する作業の1つに、キューのメッセージの順序を指定することがあります。キューの順序は、メッセージの可用性時間、有効期限、優先度、FIFOおよびLIFOによって決定されます。詳細は、tmqadmin(1)
のサブコマンドqcreate
に関する項を参照してください。
注意: | OTMQサーバーは、OTMQ形式のQSPACEでのみ起動でき、/Q形式のQSAPCEでは起動できません。 |
従来のOracle Tuxedo /Qクライアントは、図6に示すように、構成の変更のみでOTMQと通信できます。
もちろん、OTMQで導入された新機能を活用するには、アプリケーション・コードを変更する必要があります。従来のTuxedo /Q tpenqueue(3c)
/tpdequeue(3c)
関数は、それに対応するOTMQのtpenqplus(3c)
/tpdeqplus(3c)
に置き換える必要があります。APPQ_MIB
(T_APPQ、T_APPQMSG、T_APPQSPACE
およびT_APPQTRANS
)クラスを含む従来のTuxedo /Qクライアントは、それに対応するOTMQ_MIB(5)
(T_OTMQ、T_OTMQMSG、T_OTMQSPACEおよびT_OTMQTRANS
)クラスに置き換える必要があります。
Tuxedo /Qサーバーは、新規のOTMQ QSpaceでは起動できず、新規のOTMQクライアントからのキューイング・リクエストは処理できません。
OMQとのグループ間通信をサポートするため、図7に示すように、OTMQではリンク・ドライバ・サーバーとしてTuxMsgQLD(5)
が提供されます。このサーバーのデプロイにより、OTMQおよびOMQは、次のような制限付きでメッセージ・レベルでの互換性を持ちます。
MEM、DEQおよびACK DIPのみがサポートされ、OTMQを介してOMQからOMQへ、またはOMQを介してOTMQからOTMQへメッセージを送信するような場合には、複数回のプロトコル変換が行われます。
OTMQでは、Qspaceおよびキュー名は文字列です。OMQでは、それに対応するグループおよびキューの番号は整数値です。そのため、OMQと通信するには、OTMQで数値型のQspaceおよびキュー名が必要です。
OTMQでは、メッセージ・ベース・サービス(MBS)はサポートされません。
OMQでは、CARRAYおよびFML32のバッファ・タイプのみがサポートされます。
OMQクライアント・アプリケーションとOTMQの相互運用性をサポートするため、OTMQでは、クライアント・ライブラリ・サーバーとしてTuxCls(5)
が提供されます。このサーバーのデプロイにより、OTMQおよびOMQのクライアントは、メッセージ・レベルでの互換性を持ちます。従来のOMQクライアントは、コードの変更、コンパイルやリンク、構成の変更をしなくても、次の制限を除いて、OTMQサーバーで動作します。
OTMQのグローバル・ネーミング・サービスとOMQのネーミングを統合するには、環境変数DMQNS_DEFAULTPATHおよびDMQNS_DEVICEで指定されるグローバル・ネーミング・ファイルに、OTMQおよびOMQのネーミング・サービスによる読取り/書込みの権限が必要です。
MQSeriesと統合するには、次の作業を行う必要があります。
構成およびキューの属性は、アプリケーションの要件を反映している必要があります。
OTMQにより、コア・サーバーとしてTMS_TMQM(5)
、TuxMsgQ(5)
、TuxMQFWD(5)
およびTMQEVT(5)
が提供されます。TMS_TMQM(5)
は、メッセージのキュー機構のためのグローバル・トランザクションを管理します。それは構成ファイルの*GROUPS
セクションに定義され、TuxMsgQ(5)
およびTuxMQFWD(5)
によってメッセージ・キュー・サービスがユーザーに提供されます。この2つのサーバーは、構成ファイルの*SERVERS
セクションで定義されている必要があります。TMQEVT(5)
により、パブリッシュ/サブスクライブ・サービスがユーザーに提供されます。それは、構成ファイルの*SERVERS
セクションで定義されている必要があります。
1つ以上のOTMQキュー・スペースのため、追加のサーバーTMQ_NA(5)
、TuxMsgQLD(5)
およびTuxCls(5)
がマシン・レベルで構成できます。
標準の要件であるグループ名のタグおよびGRPNO
の値の他に、アプリケーションが使用する各OTMQキュー・スペースごとに1つのサーバー・グループを定義する必要があります。TMSNAME
およびOPENINFO
パラメータを設定します。次に例を示します。
OPENINFO=" TUXEDO/TMQM:<device_name>:<queue_space_name>"
TMS_TMQMは、OTMQのトランザクション・マネージャ・サーバーの名前です。OPENINFOパラメータのTUXEDO/TMQMは、$TUXDIR/udataobj/RM
にあるリソース・マネージャのリテラル名です。<device_name
>および<queue_space_name
>の値は、状況に応じて決定され、汎用デバイス・リストのパス名、およびキュー・スペースに関連付けられた名前をそれぞれ設定する必要があります。これらの値は、tmqadmin(1)
を使用して管理者が指定します。
注意: | これらの値は、時系列順に指定されている必要はありません。構成ファイルは、キュー・スペースを定義する前でも定義した後でも作成できます。構成が定義され、以前に作成されたキュー・スペースとキューが使用できることが重要です。 |
*GROUPS
セクションのエントリごとに、キュー・スペースを1つのみ使用できます。CLOSEINFO
パラメータは使用されません。
次の例は、OTMQのサーバー・グループの構成を示しています。
*GROUPS
QGRP1 GRPNO=1 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device1: queuespace1"
QGRP2 GRPNO=2 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device2: queuespace2"
TuxMsgQ(5)
は、Oracle Tuxedo /QのTMQUEUEサーバーと同じCLOPTを受け取ります。TuxMsgQ(5)
のリファレンス・ページに、構成ファイルのSERVERSセクションの詳細な説明があります。また、TuxMsgQ(5)
では、次のように、いくつかの独特なプロパティも指定できます。
アタッチは、OTMQキュー・スペースにアクセスするOTMQアプリケーションの必須の操作です。このアタッチ操作は、キュー・スペースごとにデフォルトのタイムアウト値を持って構成されます。キュー・スペースのデフォルトのアタッチ・タイムアウトを構成するには、SERVICESセクションに、TuxMQATH<qspace_name>
という名前のサービスを追加し、このサービスのBLOCKTIMEプロパティをデフォルトのアタッチ・タイムアウト値として設定します。
TuxMsgQ(5)
により、無効なキューの所有者を削除するための正常性チェック機能が提供されます。TuxMsgQ(5)
サーバーの正常性チェック間隔を構成するには、CLOPT
に-i <interval>
を設定します。<interval>
の値は、この数のメッセージを受信するたびにTuxMsgQ(5)
サーバーが正常性チェックを実行する数を意味します。
OTMQのオフライン・トレード・ドライバ・サーバーTuxMQFWD(5)
は、OTMQの信頼性の高いメッセージ配信機能の一部です。それは、OTMQのメッセージ・キュー・マネージャ・サーバーTuxMsgQ(5)
がメッセージのターゲットへの配信に失敗した後に、そのリカバリ可能なメッセージのターゲットへの再送信を担当します。
このサーバーの構成ファイルの*SERVERS
セクションの詳細は、TuxMQFWD(5)
のリファレンス・ページを参照してください。
TuxMQFWD(5)
サーバーによるメッセージのデキューや転送を妨げるような誤った構成は、サーバーの起動失敗の原因となります。強調すべき重要な項目のいくつかを次に示します。
OTMQイベント・ブローカTMQEVT(5)
は、パブリッシュ/サブスクライブ機能ために必要です。これは、トピックがパブリッシュされたときにサブスクライブの通知を行います。TuxMsgQ(5)
およびTuxMQFWD(5)
とは別のサーバー・グループとして構成する必要があります。
このサーバーの構成ファイルの*SERVERS
セクションの詳細は、TMQEVT(5)
のリファレンス・ページを参照してください。
OTMQネーミング・サーバーTMQ_NA(5)
は、ネーミング機能を提供するために構成できます。これにより、アプリケーションでは、キューのエイリアスを実際のキュー名にバインドすることができ、与えられたキューのエイリアスからの実際のキュー名のルックアップが可能となります。
このサーバーの構成ファイルの*SERVERS
セクションの詳細は、TMQ_NA(5)
のリファレンス・ページを参照してください。
ネーミング・サーバーの1つの制限は、1つのOTMQキュー・スペースに対して、1つのTMQ_NA(5)
サーバー・プロセスのみが構成できることです。
TMQ_NA(5)
は、キュー・スペースの作成または更新時に指定される事前定義済のネームスペース・ファイルで起動できます。次の例は静的なネームスペース・ファイルの内容で、ユーザー定義のキューのエイリアスと実際のキュー名の関連付けが定義されています。
静的なネームスペース・ファイルの指定方法は、tmqadmin(1)
のqspacecreate
またはqspacechange
コマンドに関する項を参照してください。
OTMQコマンドのtmqadmin(1)
は、OTMQのリソースの設定に使用されます。また、OTMQ_MIB管理情報ベース(MIB)によっても、OTMQをプログラムで管理するための別の方法が提供されます。MIB操作の詳細は、「MIBの使用」を参照してください。
tmqadmin
の主なコマンドのほとんどに位置パラメータがあります。コマンドの実行時に、コマンドラインに位置パラメータ(オプションの前にダッシュ(-)が付かないパラメータ)が指定されていない場合は、tmqadmin
から、必要な情報を入力するように要求されます。
汎用デバイス・リスト(UDL)は、Oracle Tuxedoで制御されるVTOCファイルです。このファイルは、Oracle Tuxedoを実行するマシンに物理的な記憶空間をマッピングします。UDLのエントリは、キューとキュー・スペースのメッセージが格納されるディスク領域を指定します。Oracle Tuxedoはその領域への入出力を管理します。Oracle Tuxedoの新規インストールの一部としてキュー機能がインストールされる場合、構成ファイルの初回のロード時に、tmloadcf(1)によってUDLが生成されます。
キュー・スペースを作成する前に、UDLにそのキュー・スペースのエントリを作成する必要があります。次は、コマンドの例です。
#最初に、OTMQの管理インタフェースであるtmqadmin
を起動します
# QMCONFIG変数は、UDLが置かれる、または置かれる予定の
# 上のコマンドは、ブロック番号0から始まる5000物理ページを確保します
既存のOracle Tuxedo UDLにエントリを追加する場合は、QMCONFIG変数の値にはTUXCONFIGで指定されたパス名と同じ値を指定する必要があります。tmqadmin(1)
を一度呼び出したら、新しいエントリを作成する前に、lidl
コマンドを実行してどの領域を使用できるのかを確認します。
キュー・スペースでは、IPCリソースが使用されます。そのため、キュー・スペースを定義する場合は、共用メモリー・セグメントとセマフォを割り当てることになります。前述のように、このコマンドを使用する簡単な方法はプロンプトを表示することです。(また、OTMQ_MIBのT_OTMQSPACEクラスを使用して、キュー・スペースを作成することもできます。)プロンプトは次の順で表示されます。
> qspacecreate
Queue space name: 1
IPC Key for queue space: 123567
Size of queue space in disk pages: 2048
Number of queues in queue space: 15
Number of concurrent transactions in queue space: 100
Number of concurrent processes in queue space: 100
Number of messages in queue space: 100
Error queue name: errque
Initialize extents (y, n [default=n]): y
Blocking factor [default=16]:
Create SAF and DQF queue by default: (y, n [default=y]):
Enables PCJ journaling by default: (y, n [default=n]): y
Enable Dead Letter Journal by default: (y, n [default=y]): y
共用メモリーの予約領域は、キュー・スペース内のすべてのキューの永続的ではないメッセージを格納するために使用されます。プログラムでは、この予約領域のサイズを指定するように要求されません。永続的ではない(メモリー・ベースの)メッセージが必要な場合は、qspacecreate
のコマンドラインに-nオプションでメモリー領域のサイズを指定する必要があります。
IPCキーには、他のIPCリソースの要件と競合しない値を指定します。この値は32,768より大きく262,143未満にします。
キュー・スペースのサイズ、キューの数、および一度に登録できるメッセージの数は、アプリケーションのニーズによって決定されます。UDLエントリで指定されたページ数より大きいサイズを指定することはできません。また、これらのパラメータに関連して、キュー・スペース内の個々のqueue capacityパラメータを検討する必要があります。これらのパラメータを使用すると、(a)キューに登録できるメッセージの上限値を設定し、(b)キューに登録されたメッセージの数がしきい値に達したときに実行するコマンドの名前を指定できます。キュー・スペースに同時に登録できるメッセージの数を小さくすると、キューのしきい値に達しなくなります。
並列トランザクションの数を計算するには、次の各項目を1つのトランザクションとしてカウントします。
OTMQキュー・スペースに接続する前にクライアント・プログラムがトランザクションを開始する場合は、そのキュー・スペースに同時にアクセスするクライアントの数だけカウント数を増やします。最悪のケースは、すべてのクライアントがキュー・スペースに同時にアクセスすることです。
同時に発生するプロセスの数は、このキュー・スペースを使用するグループのTMS_TMQM
サーバー、TuxMsgQ
サーバー、またはTuxMQFWD
サーバーごとに1、余裕として1をカウントします。
プロンプトのほとんどは、Oracle Tuxedo /Qコンポーネントのqmadmin
のqspacecreate
コマンドと同じです。最後の3つのプロンプトはOTMQ固有のものです。
デフォルトでSAFおよびDQFキューが作成されている場合、SAFおよびDQFを使用した配信失敗のリカバリ機能が有効になっています。そうでない場合は、ユーザーがqcreate
コマンドでこれら2つのキューを手動で作成してOTMQ_MIB
で有効にするまでリカバリ機能は使用できません。
PCJおよびDLJは、デフォルトで永続アクティブ・キューとして作成されます。デフォルトで有効になっていない場合は、ユーザーがOTMQ_MIB
で有効にするまでは使用できません。
qspacecreate
コマンドの使用時に、キュー・スペースを初期化するように設定できます。また、キュー・スペースを初めて開くときに、qopen
コマンドで初期化するように設定することもできます。
QSpaceの高可用性は、Oracle Tuxedo Automatic Failover機能によってサポートされています。このソリューションは、サーバー・グループの移行を可能とし、OTMQサーバー・グループのマスターおよびバックアップ・マシンを構成するものです。マスター・マシンが停止すると、OTMQサーバー・グループは自動的にバックアップ・マシンに移行します。QSpaceは、マスターおよびバックアップ・マシンの両方からアクセス可能なNFSに置く必要があります。リスト3は、UBBconfig
ファイルの例を示しています。
QSpaceは、最初にオープンされるときに共有メモリーにロードされます。移行中、QSpaceがすでに共有メモリーにある場合は、リロードはされず、新規のメッセージは失われます。バックアップ・マシンでは、QSpaceのオープンにtmqadmin qopen
コマンドを実行することは推奨されません。必要なら、QSpaceをクローズした後で、ipcrm
を使用して共有メモリーから削除します。
サーバー・グループ移行の有効化に加え、重要な構成は、UBBconfig
ファイルの*RESOURCES
セクションでのDBBLFAILOVER
およびSGRPFAILOVER
の設定、および*SERVERS
セクションでの移行グループ内の各サーバーのRESTART=Y
およびMAXGEN
を0より大きく設定することです。
*RESOURCES
MODEL MP
OPTIONS LAN,MIGRATE
DBBLFAILOVER 1
SGRPFAILOVER 1
*MACHINES
"machine1 "LMID=L1
"machine2 "LMID=L2
*GROUPS
QGRP1
LMID=L1,L2 GRPNO=1 TMSNAME=TMS_TMQM TMSCOUNT=2
OPENINFO="TUXEDO/TMQM:/dev/device1:queuespace1"
*SERVERS
TuxMsgQ
SRVGRP=QGRP1 SRVID=11 RESTART=Y CONV=N MAXGEN=10
CLOPT = "-s queuespace1:TuxMsgQ -- "
TuxMQFWD
SRVGRP=QGRP1 SRVID=12 RESTART=Y CONV=N MAXGEN=10
使用するキューは、tmqadmin(1)のqcreate
コマンドで作成する必要があります。まず、qopen
コマンドでキュー・スペースをオープンします。キュー・スペース名を指定していない場合は、qopen
で名前を入力するように求められます。(また、OTMQ_MIBのT_OTMQクラスを使用して、キューを作成することもできます。)
> qcreate -t PQ -a Y
Queue name: my_que
Queue order (priority, time, expiration, fifo, lifo): fifo
Out-of-ordering enqueuing (top, msgid, [default=none]):
Retries [default=0]: 0
Retry delay in seconds [default=0]: 30
High limit for queue capacity warning (b for bytes used, B for blocks used,
% for percent used, m for messages [default=100%]):
Default high threshold: 100%
Reset (low) limit for queue capacity warning [default=0%]:
Default low threshold: 0%
Queue capacity command:
No default queue capacity command
Queue 'my_que' created
デフォルトの配信オプションやメモリーのしきい値のオプションを入力するようには求められません。デフォルトの配信オプションを使用すると、配信モードが指定されていないメッセージを永続(ディスク・ベースの)ストレージに配信するか、または非永続(メモリー・ベースの)ストレージに配信するかを指定できます。メモリーのしきい値オプションでは、非永続メモリーのしきい値に達したときに、コマンドを実行するための値を指定できます。これらのオプションを使用するには、qcreate
のコマンドラインで、-dおよび-nのそれぞれを指定する必要があります。配信ポリシーが永続に指定されている場合は、-qオプションを使用して記憶域のしきい値を指定できます。
これらのプロンプトおよびオプションのほとんどは、Oracle Tuxedo /Qコンポーネントのqmadmin
のqcreate
コマンドと同じです。さらに、次のようなOTMQ固有のオプションがあります。
OTMQキューは次のようなタイプを持ちます: PQ(プライマリ・キュー)、SQ(セカンダリ・キュー)、MRQ(マルチリソース・キュー)およびUNLIMITQ(無制限キュー)。指定されない場合は、デフォルトのタイプはUNLIMITQです。
キュー・タイプに「SQ」を指定する場合は、「-o」オプションを使用してこの「SQ」を制御するキューを定義できます。SQの所有者として定義できるのはPQのみです。指定されない場合は、デフォルトで所有者なしになります。
キューには、永続アクティブまたは一時アクティブを指定できます。永続アクティブ・キューは、それにアタッチしているアプリケーションがなくても、常にメッセージを受信して格納でき、一時アクティブ・キューは、それにアタッチしているアプリケーションがある場合にのみ、メッセージを受信して格納できます。「-a」オプションの値を「Y」または「N」に設定することで、アクティブ・プロパティを指定します。指定されない場合は、デフォルトのプロパティは一時アクティブです。
キューの確認スタイルは、そのキューにアタッチしている受信側アプリケーションが、リカバリ可能なメッセージを確認するための動作を決定します。その指定には「-c」オプションを使用します。このオプションに指定できるのは、EO(明示的、順不同確認)とII(暗黙的、順序確認)です。指定されない場合は、デフォルトの確認スタイルはEOです。
異なるOTMQキュー・スペースに属するアプリケーションでは、相互に通信が可能で、これはキュー・スペース間相互通信と呼ばれます。最も一般的な使用例は、OTMQキュー・スペースのAにアタッチしている送信側アプリケーションが、別のOTMQキュー・スペースのBにアタッチしているリモートの受信側アプリケーションに向けてメッセージをエンキューできるというものです。
これらのOTMQキュー・スペースは、同じOracle Tuxedoドメインに置くことも、異なるOracle Tuxedoドメインに置くこともできます。
1つのOracle Tuxedoドメイン内に複数のOTMQキュー・スペースを構成できます。異なるOTMQキュー・スペースは、UBBCONFIG内の異なるサーバー・グループに属する必要があります。このため、TMSおよびOPENINFOは、各OTMQキュー・スペースごとに定義します。
次の例は、同じOracle Tuxedoドメインに置かれた2つのOTMQキュー・スペースの構成を示しています。
*GROUPS
QGRP1 GRPNO=1 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device1: queuespace1"
QGRP2 GRPNO=2 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device2: queuespace2"
*SERVERS
TuxMsgQ
SRVGRP=QGRP1 SRVID=11 RESTART=Y CONV=N MAXGEN=10
CLOPT = "-s queuespace1:TuxMsgQ -- -i 60 "
TuxMsgQ
SRVGRP=QGRP2 SRVID=12 RESTART=Y CONV=N MAXGEN=10
CLOPT = "-s queuespace2:TuxMsgQ -- -i 30 "
異なるOracle TuxedoドメインにOTMQキュー・スペースを構成できます。これらのキュー・スペースに属するアプリケーションでは、DMCONFIGが適切に構成されていれば、相互に通信が可能です。
Oracle Tuxedoクロス・ドメインのサービス呼出しのための通常のDMCONFIG構成と同様に、アプリケーションでリモート・ドメインにあるOTMQキュー・スペースにアクセスできるようにし、OTMQキュー・スペースは、ピアに対して自身をサービスとしてエクスポートする必要があります。これに対応して、ローカル・ドメインは、ローカルのOTMQアプリケーションのためにこのサービスをインポートします。
次の例は、異なるOracle Tuxedoドメインに置かれた2つのOTMQキュー・スペースの構成を示しています。
*GROUPS
QGRP1 GRPNO=1 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device1: QS1"
*SERVERS
TuxMsgQ
SRVGRP=QGRP1 SRVID=11 RESTART=Y CONV=N MAXGEN=10
CLOPT = "-s QS1:TuxMsgQ -- -i 60 "
*GROUPS
QGRP1 GRPNO=1 TMSNAME=TMS_TMQM
OPENINFO="TUXEDO/TMQM:/dev/device2: QS2"
*SERVERS
TuxMsgQ
SRVGRP=QGRP1 SRVID=11 RESTART=Y CONV=N MAXGEN=10
CLOPT = "-s QS2:TuxMsgQ -- -i 30 "
*DM_EXPORT
QS2 LDOM=DomB RDOM=DomA
適切な構成が済むと、キュー・スペースQS1にアタッチしたアプリケーションでは、リモート・ドメインにあるキュー・スペースQS2のリモート・キューに、標準のエンキューAPIを介して直接メッセージをエンキューできます。
この項では、OTMQのWSクライアントの構成方法を説明します。OTMQのWSクライアントは、WS SAF機能を活用するために、いくつか環境を設定する必要があります。次に示す構成オプションは、スクリプト、WSENVFILEまたはデフォルトの値を使用して設定できます。WSENVFILEは、クライアントの環境で使用される環境変数が定義されるファイルの名前です。その書式についての説明は、TUXEDOのe-docsマニュアルを参照してください。
WSC_JOURNAL_ENABLE
: 1に設定すると、WS SAFが有効です。0に設定すると、WS SAFが無効です。デフォルト値は0です。
WSC_JOURNAL_PATH
: ジャーナル・ファイルのパスを指定します。デフォルトの値は、UNIXでは「./」、Windowsでは「.\\」です。
WSC_JOURNAL_SIZE
: ジャーナル・ファイルの初期サイズです。デフォルト値は49150です。
WSC_JOURNAL_CYCLE_BLOCKS
: 一杯になり、前のメッセージを上書きする際のジャーナル・サイクル(再利用)のディスク・ブロックです。デフォルト値は0です。
WSC_JOURNAL_FIXED_SIZE
: ジャーナル・サイズを固定とするか、拡大を許可するかを決定します。デフォルト値は0です。
WSC_JOURNAL_PREALLOC
: 最初にジャーナルをオープンしたときにジャーナル・ファイルのディスク・ブロックを事前に割り当てます。デフォルト値は1です。
WSC_JOURNAL_MSG_BLOCK_SIZE
: ファイルI/Oのブロック・サイズをバイト単位で定義します。デフォルト値は0です。
OTMQでは、Oracle Tuxedo /QのQspaceをOTMQのQspaceにアップグレードするためのConvertQSPACE()
ユーティリティが提供されており、すでにOracle Tuxedo /Qアプリケーションをデプロイしている場合でも、データを失うことなくOTMQの新機能を利用できます。
使用法の詳細は、ConvertQSPACE(1)
のリファレンス・ページを参照してください。
QMCONFIG
環境変数が、/Qデバイスとして構成されていることを確認します。ConvertQSPACE -d [Q++ デバイス名] -s [Qspace名] -i [Q++ ipckey]
QMCONFIG
環境変数が、OTMQデバイスとして構成されていることを確認します。Oracle Tuxedo UBBconfig
ファイルで、OTMQデバイスおよびQspace名に従ってOTMQサーバーを構成します。 Tuxedo /QのQspaceからOTMQのQspaceへのアップグレードが完了し、OTMQサーバーを起動すると、Tuxedo /Qクライアントは、何も変更しなくてもOTMQと通信できます。また別の方法として、Tuxedo /Qクライアントは、OTMQによって提供される/Q互換のAPIであるtpenqueue(3c)およびtpdequeue(3c)を使用し、再コンパイルしてOTMQのライブラリと再リンクすることもできます。OTMQの新機能を活用するには、OTMQのAPIを使用するようにアプリケーションのコードを変更する必要があります。1つのアプリケーションまたは相互に通信する複数のアプリケーション内で、/Q互換のAPIであるtpenqueue()
/tpdequeue()
と、tpenqplus()
/ tpdeqplus()
/ tpqconfirmmsg()
などのOTMQのAPIを混在させることはできず、混在させた場合、その結果は不定となります。
OTMQでは、OMQのリンク・ドライバに相当するものとして、リンク・ドライバ・サーバーTuxMsgQLD(5)
が提供されており、OTMQおよびOMQアプリケーション間でのグループ間通信のためのメッセージ・レベルの互換性を実現します。
また、TuxMsgQLD(5)
により、従来のOMQリンク・ドライバと同様のルーティング機能が提供されますが、いくつかの制限があります。詳細は、「相互運用性」を参照してください。
TuxMsgQLD(5)
は、OTMQ Qspaceに対応する事前作成済のリンク表およびルーティング表を必要とします。リンク表は、それぞれが1つのリモートOMQグループを表す複数のエントリで構成されます。ルーティング表は、それぞれがターゲット・グループとグループを経由するルーティングの1つの組合せを表すエントリで構成されます。リンク表およびルーティング表は、tmqadmin(1)
のqspacecreateコマンドで作成されます。リンク表のデフォルトのサイズは200で、-Lオプションで別のサイズを指定できます。ルーティング表のデフォルトのサイズは200で、-Rオプションで別のサイズを指定できます。
リンク表およびルーティング表のサイズの指定方法は、tmqadmin(1)
のqspacecreateコマンドに関する項を参照してください。
リモートOMQに対して同じバスにあることを通知するには、TuxMsgQLD(5)
の起動に先立って、環境変数DMQ_BUS_IDを定義する必要があります。
TuxMsgQLD(5)
は、APPDIRに置かれた構成ファイルを必要とします。この構成ファイルの名前は、CLOPTの-fパラメータで指定します。このサーバーの構成ファイルのSERVERSセクションの詳細は、TuxMsgQLD(5)
のリファレンス・ページを参照してください。
次に、リンク・ドライバ・サーバーの構成ファイルの例を示します。
#ここには、リモートのOMQグループの情報のみをリストします
#Group Group Node/ Init- Thresh Buffer Recon- Window Trans- End-
#Name Number Host iate old Pool nect Delay Size(Kb) port point
GRP_11 11 host1.abc.com Y - - 30 10 250 TCPIP 10001
GRP_12 12 host2.abc.com Y - - 30 10 250 TCPIP 10002
#----------------------------------
#----------------------------------
OTMQでリモートOMQグループとのXGROUP接続を設定するために必須の属性を次に示します。
次に示す属性はオプションです。設定されない場合は、デフォルトの値が使用されます。
次に示す属性は、従来のOMQのXGROUP設定に合せるために存在するのみで、OTMQのリンク・ドライバ・サーバーではサポートされません。
OTMQで、直接接続できないリモートOMQ/OTMQグループのためのROUTE情報の設定に必須の属性を次に示します。
注意: |
OTMQでは、OMQのクライアント・ライブラリ・サーバーに相当するものとして、クライアント・ライブラリ・サーバーTuxCls(5)
が提供されており、OMQワークステーション・クライアントとのメッセージ・レベルの互換性を実現します。TuxCls(5)
のデプロイにより、OMQワークステーション・クライアントは、何も変更しなくてもOTMQサーバーとともに動作します。
TuxCls(5)
はOTMQクライアントのプロキシとして機能し、サポートされるOMQクライアントの最大数は、UBBCONFIG内の*SERVERS
セクションにあるTuxCls(5)
のMIN
およびMAX
パラメータによって構成されます。
Windowsでは、MINは1に設定するか未設定のままにしておく必要があり、MAXは2-512の範囲で設定します。OTMQに接続されるOMQクライアントの最大数は511に制限されています。
UNIXでは、MINは1に設定するか未設定のままにしておく必要があり、MAXの制限はありません。OTMQに接続されるOMQクライアントの最大数は、オペレーティング・システムおよびOracle Tuxedoの制限によります。