|
|
この章では、Enterprise Manager for Oracle Tuxedo (EM)を使用してTuxedoターゲットをモニターし、EMの機能を統合し、リソース・ブローカによりTuxedoアプリケーションを別のリモート・マシンに自動的にデプロイする方法について説明します。
ログインすると、Enterprise Manager Cloud Controlのホーム・ページが表示されます。ホーム・ページの各要素の詳細は、ページ右上にある「ヘルプ」をクリックしてください。
「Tuxedoサマリー」ページでは、多数のEnterprise Managerの監視ターゲットからTuxedoドメイン・ターゲットがすべてフィルタされるため、このページを使用すると、Tuxedoターゲットを一元的に管理し、各ターゲット・ホーム・ページに簡単に移動できます。
「Tuxedoサマリー」ページを開く手順は、次のとおりです。
図1に示すように、「Tuxedoサマリー」ページが表示されます。
表1に、アクション・バー機能を示します。
Tuxedoドメインを監視ターゲットに追加します。リソース・ブローカのドメインUBBCONFIGエディタで、既存のドメインを検出するのか、新しいTuxedoドメインを作成するのかを選択できます。
|
|
このボタンは、リソース・ブローカ・ドメイン・エディタによって作成されたTuxedoドメインが強調表示されている場合にのみ使用できます。このボタンをクリックすると、選択したドメインがドメインUBBCONFIGエディタにロードされます。
|
|
「検索」パネルを使用すると、特定のフィールドを使用してターゲットをすばやく検索できます。
ドロップダウン・リストから検索するフィールドを選択し、テキスト・ボックスに適切な検索文字列を入力して標準検索を実行します。拡張検索を使用して、さらに詳細なフィルタ処理を行う検索を実行することもできます。
表2に、各サマリー列フィールドに関する説明を示します。
TuxedoターゲットをEnterprise Manager Cloud Controlホーム・ページまたは「Tuxedoサマリー」ページから選択すると、そのターゲットのホーム・ページが表示されます。たとえば、Tuxedoドメイン・ターゲットをクリックすると、図2に示す画面が表示されます。
図2では、左側にターゲット・ナビゲーション・ペインを、右側にコンテンツ・ページを示しています。ターゲット・ナビゲーション・ペインでは、ツリーを開いたり閉じたりできます。ターゲットを選択すると、コンテンツ・ペインにそのターゲットのホーム・ページが表示され、ページの上部にターゲットのメニューが表示されます。ナビゲーション・ペインでターゲットを右クリックしても、ターゲットのメニューを表示できます。
一般的なターゲット・ホーム・ページには、次の項目が含まれます。
ナビゲーション・ツリーには、OMSインスタンスでモニターされているTuxedoターゲットがすべて表示されます。Tuxedoドメインに属するすべてのTuxedoターゲットは、リスト1に示すようなツリー階層で表示されます。
ツリーには、カテゴリ・ノードとターゲット・ノードという2種類のノードがあります。
カテゴリ・ノードはTuxedoターゲットに対応していません。上位レベルのターゲットの下に同じタイプのすべてのターゲットをグループ化するために使用されます。カテゴリ・ノードをクリックすると、その下にあるすべての子ノードを開いたり閉じたりできます。ツリーでターゲット・ノードをクリックすると、コンテンツ・ペインにそのターゲット・ホーム・ページが表示されます。
選択されているターゲットに対して実行可能な操作のリストを示します。表示されるメニューは、選択したターゲットに応じて異なります。個々のターゲットのメニューには、右クリック・ターゲット・メニューと同じ操作が含まれています。
現在選択されているターゲットに対して実行可能な操作のリストを示します。このメニューは、ターゲット・ナビゲーション・ペインで、ターゲット名を右クリックすると表示されます。
Enterprise Manager for Oracle Tuxedoは、いくつかのターゲットに特別なUBBページを提供し、Enterprise Manager Cloud ControlコンソールからUBB構成を変更できるようになります。「UBBの変更」ページに移動するには、ターゲットのトップ・メニューから「コントロール」→「UBBの変更」をクリックします。
詳細は、Oracle Tuxedoのドキュメントを参照してください。
| 注意: | UBBの変更機能を正しく機能させるには、UBBCONFIG *RESOURCESセクションでDOMAINIDを構成する必要があります。 |
UBBCONFIGファイルのSECURITYパラメータがNONEではないセキュリティ・ドメインの場合、ターゲット・ページや基礎となるターゲットのページでドメインの閉鎖/停止、ログ・メッセージの表示、UBBの変更などのセキュリティ・レベルが高い操作を初めて実行すると、図3に示すように「資格証明」ページが表示されます。
図3の資格証明を構成する手順は、次のとおりです。
| 注意: |
APP_PWの場合、TuxedoがTuxedoユーザー名フィールドおよびTuxedoパスワード・フィールドの値を使用して認証または認可をしなくても、これら2つのフィールドをプレースホルダとして入力する必要があります。Enterprise Manager Cloud ControlからTuxedoターゲットをモニタリングする前に、次の点に注意してください。
SQL> select dbtimezone from dual;
SQL> select sessiontimezone from dual;
SQL> alter database set time_zone='<new time zone>';
SQL> alter session set time_zone='<new time zone>';
表3では、Enterprise Manager Cloud Controlからモニター可能なTuxedoターゲット、各ターゲットでサポートされているメトリックに関する参照先、および各ターゲット・ホーム・ページで実行可能な管理操作の概要を説明しています。
| 注意: |
JMXエージェントのターゲットでは、Tuxedo Domainコンテキスト・メニューから「メンバー」→「トポロジ」をクリックして、構成トポロジを表示できます。図4に示すように、「表示」ドロップダウンから「使用」を選択します。
Enterprise Manager for Oracle Tuxedoを使用すると、Tuxedo Job Enqueueing Service (TuxJES)をEnterprise Manager Cloud Controlからモニターできます。
JESターゲット・インスタンスがジョブ統計を受信する前に、次の手順を実行します。
JESMONITOR=yesを設定します。UBBCONFIGファイルのTMSYSEVTパラメータおよびTMUSREVTパラメータを構成します。TMAGENTパラメータトラップ・ホストはEnterprise Managerエージェント・ホストであり、ポートはEnterprise Managerエージェントのリスニング・ポートです。これは、バッチ・システム・ターゲットのモニタリング・プロパティとして構成されます。
TRAP_HOST 10.182.54.215 1061 public
SNMP_ENABLE_AUTH_TRAP 1
TMAGENT tuxedo_agent_1 /home/tge/tuxedo12.1.1.0 /home/tge/test/jmx/fakemp/master/tuxconfig
BEA_SM_SNMP_MIBFILE環境変数およびBEA_SM_BEAMGR_CONF環境変数を設定します。 tux_snmpdを起動します。詳細は、「Oracle SNMPエージェントの紹介」を参照してください。
Tuxedoドメインの検出プロセス中にTuxJESモニタリングの検出は実行されます。Tuxedoドメイン検出が実行されると、JESターゲット・インスタンスが作成されます。
TuxJES監視ホームページにログインするには、次の手順を実行します。
NONE (PRIVILEGE MODEを参照)ではないTuxedoドメインにある場合、資格証明を使用してログインすることを要求されます。「ログイン」をクリックします。| 注意: | Enterprise Managerユーザーは、一度ログインすると資格証明の有効期限が切れるかまたはEnterprise Managerコンソールからログアウトするまでバッチ・システムの資格証明を変更できません。 |
バッチ・システム・ターゲットのホーム・ページにログインした後で、Tuxedoドメインの「権限モード」パラメータがNONE (「PRIVILEGE MODE」を参照)になっている場合は、ページで初めて「発行」をクリックすると、接続文字列の入力を求めるダイアログ・ボックスが表示されます。入力すると、接続文字列は、現在のセッションが期限切れになるまでこのセッションに保存されます。
Tuxedoバッチ・システムは、JESジョブにより生成されたメトリックのモニターに使用されるシステム・ターゲット・タイプです。詳細は、「ARTバッチ・ターゲット」を参照してください。
Tuxedoバッチ・システムでJESジョブ統計を受信する前に、SNMPポートを構成する必要があります。次の手順を実行します。
Tuxedo JES Adminターゲット・ホームページから「JESジョブ」タグをクリックすることにより、使用可能なすべてのジョブを表示し、一連のジョブ操作を実行できます。詳細は、「JESジョブの操作」を参照してください。
Enterprise Manager for Oracle Tuxedoを使用すると、Enterprise Manager Cloud ControlからGeneration Data Group (GDG)ファイルを管理できます。
GDGがデータを受信できるようになる前に、次の手順を実行します。
$ART_HOME /Batch_RT/sample/simpjobファイルを使用)。環境変数JESMONITOR=yesを設定します。$ART_HOME/Batch_RT/ejr/CONF/BatchRT.confでDBベースとして設定します。BatchRT.confで設定が必要な値は、次のとおりです。$JESDIR/ejr_mf_ora/pp/macro/template/GDG_PREDEFINED_JOBを、TuxJESがあるディレクトリにコピーします。JOBREPOSITORYがjesconfigファイルに設定されている場合は、これをJOBREPOSITORYの下に置きます。または、APPDIRの下に置きます。Tuxedo JES Adminターゲット・ホームページからGDGタグをクリックすると、GDGファイルを管理できます。詳細は、「GDG管理」を参照してください。
ドメイン・ターゲットのすべてのTuxedoイベント・トラップは、Enterprise Manager for Oracle TuxedoのSNMP Receivletによって受信されます。Enterprise Manager for Oracle Tuxedoから、受信したTuxedoイベント・トラップに対して、重大度がクリティカルまたは警告のEnterprise Managerメトリック・アラートが生成されます。クリティカルはTuxedoイベント・トラップの重大度がエラー(1)であり、警告はTuxedoイベント・トラップの重大度が警告(2)であることを意味します。重大度(3)である情報はサポートされていません。SNMPリスニング・ポートが正しく構成されている場合は、Tuxedoイベント・トラップにより生成されたすべてのアラートから、EMのインシデントが自動的に作成されます。
"EventName: <tuxEventsName>. Tuxedo Event LMID: <tuxEventsLmid>. Tuxedo Event Detection Time: <tuxEventsTime>. Tuxedo Event Class: <tuxEventsClass>. Tuxedo Agent Name:<beaLogicalAgentName>. Description: <tuxEventsDescription>"
詳細は、イベント・トラップに関するOracle Tuxedoのドキュメントを参照してください。
| 注意: | Tuxedo 11gリリース(11.1.1.3.0)およびリリース(11.1.1.2.0)でユーザー・イベント機能を使用するには、tux_snmpdを起動する前に、環境(SNMP_USER_EVENT=y)を設定しておく必要があります。 |
EMでTuxedoイベント収集を有効化するには、次の手順を実行します。
UBBCONFIG(5)ファイルでTMSYSEVTを構成します。beamgr.confで、TRAP_HOSTおよびTMAGENTを構成します。 トラップ・ホストがEMエージェント・ホスト、ポートがEMエージェント・リスニング・ポートになります。
TRAP_HOST 10.182.54.215 1061 public
SNMP_ENABLE_AUTH_TRAP 1
TMAGENT tuxedo_agent_1 /home/tge/tuxedo12.1.1.0 /home/tge/test/jmx/fakemp/master/tuxconfig
BEA_SM_SNMP_MIBFILEおよびBEA_SM_BEAMGR_CONFを設定します。| 注意: | 1つのEMエージェントで複数のTuxedoドメインをモニターする場合は、各Tuxedoドメイン・ターゲットのSNMPリスニング・ポートは1つのEMエージェント内で一意である必要があります。 |
図6に、EMにより作成され、Tuxedoイベント・トラップにより引き起こされるインシデントを示します。
| 注意: | ポスト・データが表1に示すフィールドを含む32ビットのフィールド化バッファである場合に、Tuxedoイベント監視でユーザー・イベントをモニターできます。TSAM Plusアラート定義によって生成されたTuxedoユーザー・イベントは、Tuxedo SNMPエージェントでトラップでき、その後Enterprise Manager for Oracle Tuxedoでモニターできます。また、TMUSREVTおよびTMSYSEVTを、ユーザー・イベント・コレクションに対して構成する必要があります。 |
リスト1に、Enterprise Manager for Oracle Tuxedoによってトラップされたユーザー・イベントの例を示します。
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <time.h>
#ifdef WIN32
#include <sys/types.h>
#endif
#include "atmi.h"
#include "userlog.h"
#include "Uunix.h"
#include <evt_mib.h>
#define NFLOATS 50 /* Number of string fields */
#define LEN (NFLOATS*sizeof(float))
static long long_v;
#define LFADDR(x) ( long_v=(x), (char*)&long_v )
int
main(int argc, char *argv[])
{long len;
int error;
time_t currtime;
FBFR32 * buf;
char decTime[14];
if (tpinit((TPINIT *)NULL) == -1) {(void)fprintf(stderr, "Failed to join application -- %s\n",
tpstrerror(tperrno));
(void)userlog("Clientpost failed to join application -- %s\n",tpstrerror(tperrno));
(void)exit(1);
}
if ((buf = (FBFR32 *)tpalloc("FML32", NULL, Fneeded32(NFLOATS, LEN))) == NULL) {(void)fprintf(stderr, "Failure to allocate FML32 buffer -- %s\n",
tpstrerror(tperrno));
(void)userlog("Clientpost failure to allocate FML32 buffer -- %s\n",tpstrerror(tperrno));
(void)tpterm();
(void)exit(1);
}
if(Fadd32(buf, TA_EVENT_NAME, "Test Event", 0) == -1){ (void)fprintf(stderr, "Failed to add TA_EVENT_NAME field -- %s\n", Fstrerror32(Ferror32));
(void)tpfree((char *)buf);
(void)tpterm();
(void)exit(1);
}
if(Fadd32(buf, TA_EVENT_SEVERITY, "ERROR", 0) == -1){(void)fprintf(stderr, "Failed to add TA_EVENT_SEVERITY field -- %s\n", Fstrerror32(Ferror32));
(void)tpfree((char *)buf);
(void)tpterm();
(void)exit(1);
}
currtime = time(NULL);
if(Fadd32(buf, TA_EVENT_TIME, LFADDR(currtime), 0) == -1){(void)fprintf(stderr, "Failed to add TA_EVENT_TIME field -- %s\n", Fstrerror32(Ferror32));
(void)tpfree((char *)buf);
(void)tpterm();
(void)exit(1);
}
if(tppost("Test Event", (char *)buf, 0, TPSIGRSTRT) == -1) {(void)fprintf(stderr, "Failure to post request -- %s\n",
tpstrerror(tperrno));
(void)userlog("Clientpost failed to post request -- %s\n",tpstrerror(tperrno));
/* Free any allocated buffers, leave the application, and exit */
(void)tpfree((char *)buf);
(void)tpterm();
(void)exit(1);
}
(void)tpfree((char *)buf);
(void)tpterm();
exit(0);
}
Tuxedo監視ターゲットのレポートには、Enterprise Manager GCソリューションが採用されています。BI Publisherは高度なカスタマイズが可能な製品であり、Enterprise Manager GCの推奨レポート・ソリューションの1つです。
BI Publisherインストレーション・ガイドに従って、既存のEnterprise ManagerにBIをインストールします。BIをインストールしたら、Enterprise Managerのホーム・ページで「エンタープライズ」→「レポート」→「BI Publisher Enterpriseレポート」をクリックすると、「BI Publisher Enterpriseレポート」ページに移動できます。
新しいWebappが開きます。新しいWebappへのログインには、Enterprise Manager管理者ユーザーであるsysmanのみ使用できます。
詳細は、Oracle Enterprise Manager 12c: BI Publisherのレポート処理を参照してください。
Enterprise Manager Service Level Agreement (SLA)機能をEnterprise Manager for Oracle Tuxedoで使用するためには、まず、汎用サービス・ターゲットを定義する必要があります。Enterprise Manager for Oracle Tuxedoでは、汎用サービス・ターゲットは、次のEnterprise Manager Systemターゲット上でのみ定義できます。
Enterprise Managerのホームページの上部のアクション・バーで、「ターゲット」→「サービス」をクリックし、「サービス」ダッシュボードを開きます。「サービス」ページの右上隅にある「ヘルプ」をクリックし、詳細を表示します。
Tuxedo SLAは、Enterprise Manager Services SLAによって管理されます。Enterprise Managerサービスを作成するには、次の手順を実行します。
詳細は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。
リソース・ブローカは、主要なOracle Tuxedoプラグイン機能で、事前定義されたOracle Tuxedoアプリケーション・ポリシーに基づいて、リソースの弾性的な調整や割当てを行います。リソース・ブローカには、次の主要な機能が含まれます。
TUXCONFIG (UBBCONFIG)構成ファイルで定義されているように、Tuxedoアプリケーション(ドメイン)は、マシン、サーバーおよびその他のリソースのセットです。1つのマシンにも、複数のクロス・ネットワーク接続マシンにも実装できます。Tuxedoアプリケーションを自動的にデプロイするには、まず、Enterprise Manager Consoleからアプリケーション・パッケージをアップロードする必要があります。アプリケーションの基本単位であるアプリケーション・パッケージには、複数のTuxedoアプリケーション・サーバーとTuxedoグループのその他のリソースが含まれます。Tuxedoアプリケーションは1つ以上のアプリケーション・パッケージで構成されます。
1つのアプリケーション・パッケージは、複数の異なるドメイン、複数の異なるマシンの1つのドメインまたは同一のマシンの1つのドメインに繰り返し適用できます。
アプリケーション・パッケージはzipファイルで、Tuxedoシステムで必要なTuxedoグループ構成ファイルがすべて含まれています(アプリケーション・サーバー、TMSサーバー、ENVFILE、アプリケーション・レベルの構成ファイルなど)。アプリケーション・パッケージの構造を図10に示します。
最初のディレクトリの下にサブディレクトリを作成し、アプリケーションを編成することもできます。上図に示すように、サブディレクトリ・サーバーには、Server1とServer2という2つのアプリケーション・サーバーがあります。
図11に、パッケージのマシンへのデプロイ後の、マシンのアプリケーション構造を示します。DOM1下のアプリケーション構造は、元のアプリケーション・パッケージの構造と変わりません。
Properties.xmlファイルは、グループ・レベルのUBBCONFIGファイルです。このファイルには、パッケージのグループ内のすべてのサーバーの関係およびパラメータが記述されています。これには完全なUBBCONFIGファイルの*GROUPS、*RMS、*SERVERSおよび*SERVICESの各セクションにあるプロパティが含まれ、複数のグループも組み込むことができます。
パッケージをマシンにデプロイする際に、Properties.xmlファイルが使用されて最終的なUBBCONFIGファイルが生成されるため、その時点でそのコンテンツを変更できるようになります。
単純なProperties.xmlファイルをリスト2に示します。
<ApplicationProperties>
<PackageName>APP1.zip</PackageName>
<TuxedoVersion>12.1.1.0 </TuxedoVersion>
<SupportedOS>Linux</SupportedOS>
<TuxedoWordSize>64<TuxedoWordSize>
<MachineArch>x86_64</MachineArch>
<LibPath> libs</LibPath>
<Groups>
<GroupSection GROUPNAME="G1" GRPNO="29999">
<ServerSections>
<ServerSection AOUT="servers/simpserv1" SRVID="20">
</ServerSection>
</ServerSections>
</GroupSection>
</Groups>
</ApplicationProperties>
Groups要素内のTuxedoグループの関連情報に加え、表2に示すように、Properties.xmlファイルの先頭には、パッケージ・グローバル属性がいくつか定義されています。
UBBCONFIGファイルの*GROUPS、*RMS、*SERVERSおよび*SERVICESの各セクションのすべてのパラメータは、3つのカテゴリに分けられます。これにより、Propertise.xmlでの定義方法が決まります。
表3に、*GROUPS、*RMS、*SERVERSおよび*SERVICESセクションの各パラメータのカテゴリを示します。
詳細は、Enterprise Manager for Oracle Tuxedoリファレンス・ガイドのProperties.xmlスキーマに関する項を参照してください。
コマンドbuildtmsによって生成されるTMS実行可能ファイルを、tmbootを実行中にTuxedo Application Runtimeでアクセスできるようにするには、TMS実行可能ファイルをアプリケーション・パッケージのサブディレクトリbinに置く必要があります。<package_name>/binフォルダは、生成されるsetenvファイルの環境変数PATHに付加されます。setenvファイルは、Tuxedoアプリケーションを起動する前にソーシングされます。
前述のENVFILE、RCMD、およびTMSYSEVT -fによって指定されたcontrol_fileの場合、この機能では、APPDIR以外のディレクトリへのデプロイをサポートしていません。たとえば、APPDIRが/nfs/lcfilerc/vol1/APPDIRの場合、ENVFILEが/nfs/lcfilerc/vol1/APPDIR/APP1/…の下にあるため、UBBCONFIGでENVFILE=/nfs/lcfilerc/vol2/envfileを指定できません。
| 注意: | Databaseクライアント・ライブラリなど、Tuxedoサーバーに依存するサード・パーティ製のライブラリはすべて、この機能のデプロイメント範囲には含まれません。 |
アプリケーション・パッケージを準備したら、Enterprise Managerコンソールを使用してパッケージをアップロードする必要があります。これは、「Tuxedoサマリー」ページで実行できます。詳細は、「Tuxedoサマリーの表示」を参照してください。
| 注意: | パッケージ名はアップロードされたすべてのパッケージで一意である必要があります。一意でない場合は、アップロード・ページでエラーが報告されます。 |
既存のアプリケーション・パッケージを削除するには、次の手順を実行します。
ドメインUBBCONFIGエディタは、Oracle Tuxedoドメインの作成に使用されます。ドメイン・エディタ・ページを開くには、「Tuxedoサマリー」ページで、「追加」→「Tuxedoドメインの作成」をクリックします。「OK」をクリックします。ドメイン・エディタの最初のページが表示されます。
| 注意: | ドメイン名は、現在のEM内でグローバルに一意であり、0から256文字である必要があります。 |
ドメイン・エディタの上部にあるエディタのヘッダーには、次の情報が表示されます。
ページの右上隅にリフレッシュ・ボタンが表示されます。ボタンをクリックすると、ドメインのステータスとともに「マシン」/「パッケージ」リストも更新されます。
表4に、コントロール・パネルのコントロール・ボタンを示します。
|
詳細は、「ポリシー管理」を参照するか、またはページの右上の「ヘルプ」をクリックしてください。
|
|
「セキュリティ管理」を開きます。Tuxedoアプリケーションをアセンブルする際にTuxedo
SECURITYを有効化する場合は、「セキュリティ管理」ページで、特定の認証および認可に関連した情報を構成する必要があります。詳細は、「セキュリティ管理」を参照するか、またはページの右上の「ヘルプ」をクリックしてください。
|
|
TuxedoドメインのARTバッチに固有のTuxedoシステム・サーバーを構成できます。詳細は、「JES構成」を参照するか、またはページの右上の「ヘルプ」をクリックしてください。
|
|
TuxedoドメインのART CICSに固有のTuxedoシステム・サーバーを構成できます。詳細は、「ART CICS用リソース・ブローカの使用」を参照してください。
|
|
「マシン・リスト」パネルには、Tuxedoドメインのデプロイに使用可能な、EMによって管理されるマシンがすべて表示されます。Tuxedoドメインのデプロイメントに使用するマシンは、次の2つの前提条件を満たしている必要があります。
| 注意: |
マシン・エントリの+ボタンをクリックすることによってマシンが現在のドメインに追加されると、マウス・カーソルをそのマシン・エントリの上に置くと、マシン情報がツールチップとして表示されます。
「パッケージ・リスト」パネル(右下)には、アップロードされたパッケージがすべて表示されます。また、パッケージ名の上にマウス・カーソルを置くと、パッケージの詳細な情報が表示されます。
左側がUBBセクションのパネルです。UBBCONFIGファイルの各セクションは、パネル・ボックスに対応しています。この領域では各セクションの有効なパラメータのみが編集可能です(つまり、マスター・マシンのバージョンに属するパラメータのみが定義できます)。
Oracle Tuxedoドメイン作成の初期段階では、ドメインUBBCONFIGエディタの*RESOURCESセクションで、限定されたパラメータ・セットが提供されます。これは、Tuxedoのバージョン間で異なることはありません。
*RESOURCESセクションの「詳細」…および他のセクションの「追加」…は無効です。これらのパラメータは、マスター・マシンがドメインに追加されるまで表示されます。マスター・マシンがドメインに追加されると、マスター・マシンのTuxedoバージョンに従って、各セクションのすべての無効なパラメータが選別され、非表示になります。
ドメイン・エディタに初めてアクセスしたときには、メトリックを収集する目的で、OPTIONSパラメータのインジケータEXT_MONがデフォルトで設定されています。
このパネルには、ドメインを作成するときに、UBBCONFIGファイルの*RESOURCESセクションの生成用に選択可能なUBB_Resourceテンプレートが用意されています。このテンプレートのアイテムを表5に示します。
MASTERを除いてすべての項目を変更できます。MASTERの項目は、マスター・マシンおよびバックアップ・マシンを指定する際にロックされた変数として生成されます。これらのパラメータに加えて、他のパラメータも追加できます。
固有のUBB_Resourceテンプレートを作成し、これらをソフトウェア・ライブラリに保存することも可能です。すべてのテンプレートで、MASTERは前述のルールに従って自動的に入力されます。
このパネルには、ドメインを作成してマシンを指定するときに、UBBCONFIGファイルのMACHINESセクションの生成用に選択できるUBB_Machineテンプレートが用意されています。このテンプレートのアイテムを表6に示します。
UBBCONFIGファイルの*MACHINESセクションのその他のパラメータを追加することも可能です。TLOGをロー・ディスクに指定することもできます。このドメインをアンデプロイするとき、システムで削除されます。
固有のUBB_Machineテンプレートを作成し、これらをソフトウェア・ライブラリに保存できます。パラメータの置換は、表6に記載のルールに従います。
アプリケーション・パッケージをドメインに追加すると、表7に示すように、Properties.xmlの*GROUPSセクションのパラメータが一部置き換えられます。
詳細は、表3を参照してください。他のパラメータをUBBCONFIGファイルに追加することも可能です。
アプリケーション・パッケージをドメインに追加すると、表8に示すように、Properties.xmlの*RMSセクションのパラメータが一部置き換えられます。
詳細は、表3を参照してください。他のパラメータをUBBCONFIGファイルに追加することも可能です。
このセクションのすべてのパラメータは、必要に応じてユーザーが手動で入力する必要があります。
このセクションはUBB_Machineテンプレートにも含まれています。ドメインがMPモードである場合は、このセクションは表9に示すように、UBBCONFIGファイルに自動的に追加されます。
他のパラメータをUBBCONFIGファイルに追加することも可能です。
アプリケーション・パッケージをドメインに追加すると、表10に示すように、Properties.xmlの*SERVERSセクションのパラメータが一部置き換えられます。
詳細は、表3を参照してください。他のパラメータをUBBCONFIGファイルに追加することも可能です。
アプリケーション・パッケージをドメインに追加すると、表11に示すように、Properties.xmlの*SERVICESセクションのパラメータが一部置き換えられます。
詳細は、表3を参照してください。他のパラメータをUBBCONFIGファイルに追加することも可能です。
アプリケーション・パッケージをドメインに追加すると、Properties.xmlの*ROUTINGセクションのパラメータが一部置き換えられます。
Properties.xmlファイルの*ROUTINGセクションの他のパラメータの場合、これらの値は保持され、手動で変更できます。他のパラメータをUBBCONFIGファイルに追加することも可能です。
通常、アプリケーション・パッケージをTuxedoドメインにデプロイするためには、次の手順を実行する必要があります。
各マシンに1つのアプリケーション・パッケージが必要です。「アプリケーション・パッケージの構成とコンテンツ」の説明を参照し、2つのアプリケーション・パッケージAPP1.zipおよびAPP2.zipを準備します。
APP1.zipのコンテンツ構造を図12に示します。
APP1.zip Properties.xmlをリスト3に示します。
<?xml version="1.0" encoding="ISO-8859-1" ?>
<ApplicationProperties>
<PackageName>APP1.zip</PackageName>
<TuxedoVersion>12.1.1.0</TuxedoVersion>
<SupportedOS>Linux</SupportedOS>
<TuxedoWordSize>64</TuxedoWordSize>
<MachineArch>x86_64</MachineArch>
<GroupSection GROUPNAME="GROUP1" GRPNO="29999">
<MRM>N</MRM>
<ServerSections>
<ServerSection AOUT="servers/simpserv1" SRVID="30000">
<CONV>N</CONV>
</ServerSection>
</ServerSections>
</GroupSection>
</ApplicationProperties>
APP2.zipのコンテンツ構造を図13に示します。
APP2.zip Properties.xmlをリスト4に示します。
<?xml version="1.0" encoding="ISO-8859-1" ?>
<ApplicationProperties>
<PackageName>APP2.zip</PackageName>
<TuxedoVersion>12.1.1.0</TuxedoVersion>
<SupportedOS>Linux</SupportedOS>
<TuxedoWordSize>64</TuxedoWordSize>
<MachineArch>x86_64</MachineArch>
<GroupSection GROUPNAME="GROUP1" GRPNO="29999">
<ServerSections>
<ServerSection AOUT="servers/simpserv2" SRVID="20000" />
<ServerSection AOUT="servers/simpserv3" SRVID="20010" />
</ServerSections>
</GroupSection>
</ApplicationProperties>
アプリケーション・パッケージを準備したら、「パッケージのアップロード」を参照し、「Tuxedoサマリー」ページで「アプリケーション・パッケージの管理」を選択してパッケージをEMにアップロードします。
Tuxedoドメインのデプロイにホストを使用できるようにするには、ホストのEMエージェントによってTuxedo tlistenとTuxedoホーム・ターゲットを検出しておく必要があります。
Tuxedo tlistenターゲットとTuxedoホーム・ターゲットを検出するには、次の手順を実行します。
| 注意: | 前述の検出プロセスによって、2つのターゲットを検出する必要があります。2つのターゲットをスタンドアロン・ターゲットとして別々に追加しても、リソース・ブローカでは機能しません。 |
2つのタイプのTuxedoドメイン、SHMドメインとMPドメインを作成できます。
*RESOURCESセクションに入力します。次の点に注意してください。マシン関連情報を収集するためのポップアップ・ダイアログが表示されます。
初めてマシンを追加する場合は、「アプリケーション・ホーム」オプションを指定する必要があります。アプリケーション・ホームは、すべてのドメインのデプロイ先のルート・ディレクトリです。
マシンを追加する場合は、「環境パス変数」も指定できます。コロン(UNIX/Linux)またはセミコロン(Windows)区切りの文字列で、環境固有のコマンドの検索先のパスを含みます。たとえば、ユーザー・プログラムで使用されるコンパイラやOracle DBクライアントです。
UBBCONFIGファイルの*MACHINESセクションのすべてのパラメータを含む、別のポップアップ・ダイアログが表示されます。
MPドメインの作成手順は、SHMドメインの作成手順と似ています。追加のタスク(デプロイに使用可能な別のマシンの追加)が必要です。
EMエージェントを新しいホストにデプロイする手順は、次のとおりです。
Tuxedoドメインのデプロイに新たに追加したマシンを使用できるようにするには、EMエージェントによってtlistenプロセスが開始され、「Tuxedoドメイン検出」ページで検出される必要があります。手順説明は、「Tuxedo tlistenおよびTuxedoホームの検出」を参照してください。tlistenターゲットおよびTuxedoホーム・ターゲットが検出されたら、ドメインUBBCONFIGエディタ・ページでステータスを確認します。マシン・リストには、新たに追加されたマシンが表示されています。
アプリケーション・パッケージをドメインに追加するには、次の手順を実行します。
| 注意: | パッケージがマシンに適していない場合は、+ボタンは無効になります。 |
パッケージのProperties.xmlに記述されているすべてのエントリが、図14に示すように、対応するUBBCONFIGファイルのセクションに追加されます。
GROUPSエントリおよびSERVERSエントリの前の(*)記号は、デプロイされていない、このドメインに新たに追加されたアイテムを示しています。
GROUPNAMEパラメータおよびGRPNOパラメータは、パッケージの追加時に自動的に生成されます。Properties.xmlで定義されたすべてのグループおよびそのアセットがドメインに追加されます。マシン・エントリとは異なり、1つのアプリケーション・パッケージを複数回追加できます。
これで、新しいTuxedoドメインのデプロイとモニターの準備が整いました。
新たに作成したTuxedoドメインに必要なすべての構成が完了したら、次の手順を実行して新しいドメインをリモート・マシンにデプロイします。
| 注意: | すべてのデプロイ・プロセスで、このドメインに含まれるすべてのマシンのユーザー資格証明が必要です。ユーザー資格証明を入力しておくと、記憶済のものが表示されます。ターゲット・マシンに対して有効なOSのユーザーであり、アプリケーション・ホーム・ディレクトリに対する書込み権限がある必要があります。ユーザーは、管理エージェントをインストールしたユーザー・グループと同じグループに属している必要があります。 |
図15に、ドメイン・デプロイメント・オプション画面を示します。
すべての手順に成功すると、ドメインがターゲット・マシンのアプリケーション・ホームにデプロイされ、起動されます。デプロイメントの最後のステップはCheckDeployStatusです。ここでは、デプロイメント・ステータスが確認され、ドメイン・エディタの対応するエントリのステータスがそれに応じて変更されます。デプロイメントに成功すると、ドメインの自動検出が実行されます。ドメインに属する、新たに検出されたターゲットは、「Tuxedoサマリー」ページの「すべてのターゲット」に表示されます。
アプリケーション・パッケージを動的にデプロイするには、次の手順を実行します。
ドメインのコンテンツが ドメインUBBCONFIGエディタ・ページにリロードされます。
APP2.zipのProperties.xmlに記述されているグループの2つのサーバーsimpserv2とsimpser3が、*SERVERSセクションに追加されます。
| 注意: |
デプロイメントが完了すると、新しいディレクトリAPP2がドメインAPPDIRに存在し、GROUP2およびsimpserv2/simpserv3が作成された状態になります。
場合によっては、アップロードしたアプリケーション・パッケージの更新が必要なことがあります。現時点では、次の手順に従って手動で更新できます。
パッケージに関連付けられたグループがマシンに追加されると、パッケージ名の横にあるXボタンが使用可能になり、パッケージをマシンから削除できるようになります。
パッケージに関連付けられたグループを削除するには、次の手順を実行します。
動的リソース・ブローカを使用すると、特定のEnterprise Managerターゲットの柔軟なリソース割当てを実現するために、実行中のOracle Tuxedoドメインに、Tuxedoサーバー、グループおよびマシンを手動およびポリシー主導でデプロイできます。
Tuxedoアプリケーション・パッケージおよびTuxedoマシンは両方とも、アクティブ・ドメインに手動で追加できます。
ドメインに新たに追加されたパッケージ(アスタリスクで(*)で表示)がある場合に、パッケージを手動でデプロイするには、「コントロール」パネルで「保存してデプロイ」をクリックします。
「保存してデプロイ」ボタンをクリックすると、現在のドメイン編集ステータスが保存され、ドメインUBBCONFIGで完全検証が開始されます。検証に失敗すると、デプロイメント・プロセスが停止し、エラー・メッセージが表示されます。
| 注意: | 「追加…」リンクをクリックして手動で追加されたUBBCONFIGエントリは、動的にデプロイおよびアクティブ化できません。 |
| 注意: | 動的デプロイメントは、アプリケーション・パッケージからインポートされたUBBCONFIGエントリでのみ機能します。手動で追加したUBBCONFIGエントリを有効にするには、ドメインの完全なデプロイを実行する必要があります。 |
収集済のマシンの資格証明を使用してデプロイメントがただちに実行され、新しいマシンがスレーブ・マシンとしてドメインに追加されます。
| 注意: | マシン・レベルの動的デプロイメントでは、MPモードのドメインのみをサポートしています。 |
次の3つのレベルの動的デプロイメントは、ユーザー定義のポリシーにより実行されます。
アクティブなTuxedoマシン上での1つ以上のアプリケーション・パッケージの動的なデプロイまたはアンデプロイは、一定の条件(CPU負荷が低く、60%を超えないなど)の下でトリガーされます。パッケージをデプロイするマシンは、事前定義されたフィルタリング・ポリシーに従って候補マシンの中から最終的に選択されます。
パッケージ・レベルのポリシーを作成する前に、候補としてパッケージ・リストからパッケージを追加(「候補として」チェック・ボックスを選択)しておく必要があります。インポートされた各UBBCONFIGエントリで「編集」をクリックしてそのエントリの詳細構成を変更し、ポリシー管理コンソールで候補パッケージに対してデプロイメント・ポリシーを作成できます。
| 注意: | パッケージの動的なデプロイの前に、新たに導入されたTMSサーバーを、Tuxedoの起動時にPATH環境変数で参照されるディレクトリの下に置く必要があります。そうしないと、TMSサーバーがパッケージのbinサブディレクトリにある場合でも、Tuxedo Application Runtimeで検出できません。 |
マシンの動的なデプロイとアンデプロイは、ポリシーで定義されている条件(インシデント・ルール)に一致した場合にトリガーされます。
新たに追加されたマシン・エントリにポリシーを定義し、これらを候補マシンに変換できます。デプロイされるマシンは、事前定義されたフィルタリング・ポリシーに従って候補マシンの中から最終的に選択されます。
動的なマシン・レベル・デプロイメントは、パッケージ・レベル・デプロイメントと併用されることがよくあります。マシンを動的にデプロイすると、マシンに追加されたパッケージが同時にデプロイされます。
実行中のデプロイされたTuxedoサーバーの数は、ポリシーで定義されている条件(インシデント・ルール)に一致すると、自動的に増減します。サーバーの最小数および最大数は、UBBCONFIGに設定されているMINおよびMAXパラメータに応じて異なります。
詳細については、「ポリシー」を参照してください。
リソース・ブローカのデプロイメント・ポリシー(Enterprise Managerのインシデント・ルールに連動)は、リソース・ブローカのデプロイメント・ポリシー評価がトリガーされる条件を定義します。
インシデント・ルールでは、リソース・ブローカ・ポリシーをトリガーする条件を詳細に指定します。条件は複雑で、イベントの特性(イベントの種類、重大度、カテゴリなど)を表す条件の組合せから構成されている可能性があります。インシデント・ルールを定義することによって、次の条件のいずれかが満たされたときにデプロイメント・ポリシーを評価することを指定できます。
インシデント・ルールにはあらゆるモニター対象のターゲットから提供されるメトリックを含めることができます。特定のターゲットについてインシデント・ルールを評価するには、ターゲットにEnterprise Managerグループを作成し、このグループをルール・セットで参照します。
CPUメトリック・イベントのタイプを定義する方法を説明する例として、次の手順を示します。ポリシーを作成する前に、インシデント・ルールを作成する必要があります。
| 注意: | このステップでは個々のグループの選択が重要です。正しく選択しないと、ターゲットにある同じタイプのすべてのイベントでインシデント・ルールが実装されます。 |
新たに作成されたイベントが「メトリック・アラート」パネルに表示されます。
これはつまり、インシデントが発生した場合、Tuxedoイベント接続が通知されることを意味します。
「すべてのエンタープライズ・ルール」ページでは、インシデント・ルールがアクティブ・ステータスでTuxedoインシデント・ルール・ルール・セットの下に追加されます。
ポリシーは、ポリシー管理コンソールで一元的に定義および管理されます。ポリシー管理コンソールを開くには、ドメイン・エディタの「コントロール」パネルで「ポリシー」をクリックします。
インシデント・ルールを定義したら、ポリシー管理コンソールで「追加」をクリックし、「ポリシー・プロパティ」ページでオプションを指定すると、ポリシーを作成できます。詳細は、「ポリシー管理」を参照するか、またはページの右上の「ヘルプ」をクリックしてください。
「Tuxedoサマリー」ページには、ドメイン・エディタで作成されたTuxedoドメイン・ターゲットのコントロール・セットが組み込まれています。ドメイン・ターゲットを右クリックすると、リソース・ブローカに固有のアクションが「コントロール」メニュー・アイテムに表示されます。
このアクションは、ドメイン・エディタ・ページのものとまったく同じです。ドメインが停止中またはターゲット・マシンにデプロイされていない場合は、完全なデプロイが実行されます。ドメインがアクティブ・ステータスである場合、新たに追加されたパッケージが動的にデプロイされてアクティブ化されます。
ドメインは、デプロイ後に起動できるように構成する必要があります。このアクションは、アクティブ・ステータスでないドメインにのみ適用できます。
デフォルトの構成アクションは、マスター・マシンでUBBCONFIGのtmloadcf を実行することです。ドメインの起動前に実行しておく必要がある特定の構成(TLOGデバイスやQUEUEスペースの作成など)がある場合は、スクリプトをカスタマイズできます。
このアクションは、アクティブ・ステータスでないドメインに適用できます。「起動」のデフォルトのアクションは、マスター・マシンでtmboot -yを実行することです。ブート・スクリプトをカスタマイズすることもできます。
このアクションは、アクティブ・ステータスのドメインにのみ適用できます。「停止」のデフォルトのアクションは、マスター・マシンでtmshutdown -yを実行することです。停止スクリプトをカスタマイズすることもできます。
このアクションは、アクティブ・ステータスでないドメインにのみ適用できます。「アンデプロイ」のデフォルトのアクションは、ターゲット・マシンでAPPDIR全体を削除することです。APPDIRを削除する前に、構成解除スクリプトをカスタマイズしてクリーンアップを実行できます。
TuxedoドメインでARTバッチ用リソース・ブローカを使用するには、サーバー・パラメータとJESパラメータの両方を構成する必要があります。
ARTバッチを正常に機能させるためには、ARTバッチ固有のいくつかのTuxedoシステム・サーバーをTuxedoドメインで構成する必要があります。たとえば、サーバーARTJESADM、ARTJESCONV、ARTJESINITIATORおよびARTJESPURGEは、動作中のART JESシステムに必要です。
ARTバッチはOracle Tuxedo Eventコンポーネントを使用するため、Oracle Tuxedoユーザー・イベント・サーバーTMUSREVTがUBBCONFIGファイルに必要です。さらに、JESジョブ情報を格納するために、TMQUEUEサーバーも必須です。
これらのTuxedoシステム・サーバーを追加するには、次の3つの方法があります。
ドメインUBBCONFIGエディタの「サーバー」セクションで「追加」をクリックすると、サーバーを手動で追加できます。正しいパラメータ(CLOPT)をサーバーに指定したことを確認します。ドメインに構成を保存すると、ドメイン・エディタにより、システム・サーバーに対してCLOPT検証が実行されます。
システム・サーバーの関連情報は、Properties.xmlに記述して、アプリケーション・パッケージにまとめることができます。アプリケーション・パッケージをTuxedoドメインに追加することにより、それに応じて、対応するサーバーが追加されます。
これが、ポリシー主導の動的リソース・ブローカの機能を使用する唯一の方法です。
アプリケーション・パッケージにまとめられた前述のサーバーには、対応するバイナリはありません。これらのシステム・サーバー・バイナリは、ARTバッチ・インストール・ディレクトリに含まれています。
システム・サーバーは、1つのサーバー名を使用してProperties.xml内で参照されます。
サーバー・テンプレートを使用してARTバッチ関連サーバーを追加できます。次の手順を実行します。
サーバーTMQUEUEに使用されるTMS_QMにはTLOGデバイスが必要であるため、サーバー・テンプレートの適用後にパスが指定されていない場合は、対応するマシンのTLOGDEVICEおよびTLOGSIZEパラメータが$APPDIR/TLOGに対して構成されます。
JES構成ファイルは、TuxJES管理サーバーであるARTJESADMによって使用されます。JES構成ファイルの次のパラメータを構成できます。
JESROOTベース・ディレクトリ。これが設定されていない場合は、ベース・ディレクトリは$APPDIRになります。
JESROOT ジョブ情報を格納するルート・リポジトリ。このディレクトリは、JES Base Directoryで設定されたパスの下に作成されます。たとえば、JESROOTがjesrootに設定されており、JESベース・ディレクトリが$APPDIRに設定されている場合、JESROOTディレクトリのフルパスは{$APPDIR}/jesrootです。
| 注意: | ARTバッチに関連するサーバーが2つのTuxedoマシン上で構成される場合は、同一のJESROOTリポジトリを共有する必要があります。つまり、JESROOTの絶対パスのみが許容されるため、このディレクトリはネットワーク・ファイル・システムに存在する必要があります。 |
DEFAULTJOBCLASSオプション。JCLでジョブ・クラスが設定されていない場合のデフォルト・ジョブ・クラス。このオプションが設定されていない場合のデフォルト・ジョブ・クラスは、Aです。
DEFAULTJOBPRIORITYオプション。JCLでジョブ優先度が設定されていない場合のデフォルトのジョブ優先度。このオプションが設定されていない場合のデフォルトのジョブ優先度は、0です。
DUPL_JOB NODELAYが選択されていない場合、ジョブ名ごとに1つのジョブのみが実行ステータスであることができます。選択されている場合は、NODELAYは、依存性チェックを削除します。
EVENTPOST個別のステージで、ジョブに対してポストされるイベントを指定します。
JOBREPOSITORY 格納されたジョブ・リポジトリのパス。設定された場合、ジョブ送信スクリプト・ファイル・パスに、JOBREPOSITORY内の相対パスを使用できます。
PRIVILEGE MODEユーザー代入を有効化するかどうか、およびその方法を指定します(TuxJESユーザー代入に関する項を参照してください)。
NONE: デフォルト値。ジョブが、JESシステムを起動するOSユーザーによって実行されることを示します。これは、これまでのJESシステムの実装すべてと互換性があります。 USER_IDENTICAL: ジョブが、JESシステムに参加するJESクライアントを使用してOracle Tuxedoユーザーによって実行されることを示します。このオプションを選択する前に、Oracle Tuxedoの各ユーザーが既存のOSユーザーに対応することを確認します。 USER_MAPPING: JESシステムはTuxJESユーザー・マッピング・ファイルを参照し、JESシステムに参加するJESクライアントのOracle Tuxedoユーザーに対応するOSユーザーを検出して、このOSユーザーをジョブの実行者として指名します。 USER MAPPING FILE USER_MAPPINGを権限モードとして選択した場合に、このオプションは有効になります。ユーザー・マッピング・ファイルの名前を指定します。ユーザー・マッピング・ファイルは、デフォルトで$APPDIRディレクトリの下にあります。
リソース・ブローカによって作成されたユーザー・マッピング・ファイルの所有者はrootで、そのファイル権限は-rw-------です。
| 注意: | ユーザー・マッピング・ファイルに次の名前は指定できません。 |
USER MAPPING表 ユーザー・マッピング表には、Oracle TuxedoユーザーとOSユーザーの間のマッピング関係が表示されます。権限モードがUSER_MAPPINGに設定されている場合、ユーザー・マッピング表が有効なため、ユーザー・マッピング・エントリの追加、編集または削除が可能です。マッピング表の各行は次の形式です。
tuxedousername OSusername
| 注意: |
権限モードをUSER_IDENTICALまたはUSER_MAPPINGのいずれかに設定した場合、リソース・ブローカにより、次の権限設定が自動的に実行されます。
リスト5は、UBBCONFIGファイルの例を示しています。
*RESOURCES
IPCKEY <IPCKEY> # for example 132770
DOMAINID jessample
MASTER SITE1
MODEL SHM
MAXACCESSERS 200
MAXSERVERS 50
NOTIFY SIGNAL
PERM 0666 #Adding "PERM=0666" in RESOURCES section
SECURITY USER_AUTH
AUTHSVC "AUTHSVC"
*MACHINES
#
<uname -n>
LMID = SITE1
TUXDIR ="<full path of TUXEDO software>"
TUXCONFIG = "<full path of APPDIR>/tuxconfig"
TLOGDEVICE ="<full path of APPDIR>/TLOG"
TLOGSIZE=10
APPDIR = "<full path of APPDIR>"
ULOGPFX = "<full path of APPDIR>/ULOG"
*GROUPS
ARTGRP
LMID = SITE1 GRPNO = 1
QUEGRP
LMID = SITE1 GRPNO = 2
TMSNAME = TMS_QM TMSCOUNT = 2
OPENINFO = "TUXEDO/QM:<full path of APPDIR>/QUE:JES2QSPACE"
EVTGRP
LMID= SITE1 GRPNO=3
#
*SERVERS
# Adding RQPERM=0666 RPPERM=0666 in all JES servers entry in SERVERS section
DEFAULT: CLOPT="-A"
TMUSREVT SRVGRP=EVTGRP SRVID=1 CLOPT="-A"
RQPERM=0666 RPPERM=0666
TMQUEUE
SRVGRP = QUEGRP SRVID = 1
GRACE = 0 RESTART = Y CONV = N MAXGEN=10
CLOPT = "-s JES2QSPACE:TMQUEUE -- -t 5 "
RQPERM=0666 RPPERM=0666
ARTJESADM SRVGRP =ARTGRP SRVID = 1 MIN=1 MAX=1
CLOPT = "-A -- -i jesconfig"
RQPERM=0666 RPPERM=0666
ARTJESCONV SRVGRP =ARTGRP SRVID = 20 MIN=1 MAX=1
CLOPT = "-A --"
RQPERM=0666 RPPERM=0666
ARTJESINITIATOR SRVGRP =ARTGRP SRVID =30
CLOPT = "-A -- -n 20 -d"
RQPERM=0666 RPPERM=0666
ARTJESPURGE SRVGRP =ARTGRP SRVID = 100
CLOPT = "-A --"
AUTHSVR SRVGRP=ARTGRP SRVID=104 CLOPT="-A"
RQPERM=0666 RPPERM=0666
*SERVICES
権限モードをUSER_IDENTICALまたはUSER_MAPPINGのいずれかに設定する場合は、次の権限の要件を満たす必要があります。
UBBCONFIGの権限要件Oracle Enterprise Manager Cloud Controlで、「設定」→「セキュリティ」→「権限委任」をクリックします。詳細は、Oracle Enterprise Managerライフサイクル管理者ガイドの権限委任設定の構成に関する項を参照してください。
「その他の構成」フィールドの次のオプションを構成し、ARTバッチ関連情報を指定できます。
JESキュー初期化スクリプト。JESのsimpjobという例で提供されているテンプレートが、デフォルトとして使用されます。テキスト・フィールドをカスタマイズできます。その場合、キュー・ファイル名はQUEにする必要があります。
必須。ページでARTバッチ・インストール・ディレクトリを指定する必要があります。
| 注意: | MPドメインを構成する場合は、すべてのマシンのARTバッチ・インストール・ディレクトリのパスが同じである必要があります。 |
PDKSH オプション。ARTバッチの実行に使用される、PDKSHの実行可能ファイルです。指定されていない場合、実行時にシステムのデフォルトのkshコマンドが使用されます。
静的デプロイメントを使用する場合、すべてのARTバッチ関連のシステム・サーバーが、その他のサーバーとしてUBBCONFIGファイルにアセンブルされます。保存済のJES構成ファイルは、デプロイメントのために配布パッケージに組み込まれます。デプロイされたJES構成ファイルの名前は、ARTJESADM CLOPTの-iオプションで指定されます。JESROOTディレクトリは、この段階では作成されません。これは、実行時にARTバッチによって自動的に作成されます。
JESが構成される場合は、次の環境変数設定がsetenv.shファイルに追加されます。
JESDIR=<full path of ART JES software>
MT_KSH=<full path of pdksh>
MT_ROOT=$JESDIR/ejr
PATH=$JESDIR/bin:$PATH
QMCONFIG=$APPDIR/QUE
DATA_SOURCE=$APPDIR/data_source
DATA=$APPDIR/data
TMP=$APPDIR/tmp
MT_TMP=$APPDIR/tmp
MT_ACC_FILEPATH=$APPDIR/acc
MT_LOG=$APPDIR/Logs/log
SPOOL=$APPDIR/Logs/sysout
構成中、デフォルトのjesqinitスクリプトまたはユーザー定義スクリプトによって、JES QUEUEシステムが初期化されます。
パッケージ・レベルの動的デプロイメントは、既存のリソース・ブローカ・フレームワークによって処理されます。
JES関連Tuxedoシステム・サーバーは、様々なアプリケーション・パッケージに組み込まれるProperties.xmlに記述されます。これらのパッケージを候補として既存のドメインに追加し、そのポリシーを定義できます。ポリシーが実行する必要があると評価された場合は、パッケージがデプロイされ、そこに記述されているサーバーがアクティブ化されます。
| 注意: | 動的デプロイメントは、パッケージ(サーバー)レベルでのみ使用できます。JESCONFIGでは、動的デプロイメント(たとえば、ARTバッチが構成されていないTuxedoドメインの実行)をサポートしません。JESCONFIGは動的に実行できません。 |
ARTバッチ用リソース・ブローカを使用する場合、Tuxedo提供の複数のシステム・サーバーをUBBCONFIGファイルで構成し、ART CICSランタイムのリソース・ブローカを有効にする必要があります。
これらのTuxedoシステム・サーバーを追加するには、次の3つの方法があります。
詳細は、「Tuxedoシステム・サーバーの手動追加」を参照してください。
ART CICS固有のシステム・サーバーは次の2つのカテゴリに分類できます。
ART CICS提供のシステム・サーバーの場合は、Properties.xmlでサーバー名のみが参照されます。
ユーザーが構築可能なシステム・サーバーの場合は、Properties.xmlで定義したサーバー名を、表示されたサーバー名の先頭に付ける必要があります。
サーバー・テンプレートを使用してART CICS関連サーバーを追加できます。次の手順を実行します。
CICSアプリケーション・パッケージは、様々なCICSリソースの処理のために特に導入されました。
Tuxedoアプリケーション・パッケージと同様に、CICSアプリケーション・パッケージは、CICSランタイム実行用のアセットを含む.zipファイルです。これには、次に記述されるコンポーネントが含まれています。
(zipファイルのrootにある) Properties.xmlは、パッケージ全体の一般プロパティの記述に使用されます。Tuxedoアプリケーション・パッケージの次の一般パラメータは、CICSパッケージにも適用できます。
すべての要素は、SupportedOSを除き、Tuxedoアプリケーション・パッケージの要素と同じ意味を持ちます。Windowsプラットフォーム用のART CICSはありません。Linux、SunOSおよびAIXのみがサポートされます。
新しい要素CICSVersionがProperties.xmlに追加されます。これは、このパッケージが構築されたART CICSのバージョンを示しています。このフィールドは、今後の拡張に使用されます。これは、正規表現ルール1[1-9](\.[0-9]){3,4}に一致する任意の値に構成できます。12cR1リリースでは、推奨値は12.1.1.0になります。
Tuxedoアプリケーション・パッケージから区別するために、タイプ属性がApplicationPropertiesルート要素に導入されます。パッケージをCICSアプリケーション・パッケージとマークするには、タイプ属性をCICSに設定します。タイプが設定されていないかTUXに設定されている場合は、パッケージはTuxedoアプリケーション・パッケージと見なされます。
次のCICSリソース構成ファイルがCICSランタイムでサポートされています。
list_of_groups.desc)transclasses.descファイル)transactions.descファイル)同一のtransactionsは、異なるCICSグループに含まれる場合でも、2つ定義できません。
programs.descファイル)同一の2つのプログラムを1つのCICSグループに定義できません。異なるグループに同一の2つのプログラムを定義することは可能です。
tsqmodel.descファイル)同一のTSQモデルは、異なるCICSグループに含まれる場合でも、2つ定義できません。
mapsets.descファイル)同一のmapsets2つをファイルに定義できますが、最初に定義したもののみが使用されます。
typeterms.descファイル)同一のtypeterms2つをファイルに定義できますが、最初に定義したもののみが使用されます。
enqmodel.desc) 同一のenqmodelは、異なるCICSグループに含まれる場合でも、ファイルに2つ定義できません。
tdqextra.desc) 同一のtdqueueは、異なるCICSグループに含まれる場合でも、2つ定義できません。
tdqintra.desc) 同一のtdqueueは、異なるCICSグループに含まれる場合でも、2つ定義できません。
各CICSアプリケーション・パッケージには、前述の.descファイルのセットを組み込めます。各.descは1つのパッケージに1つしか存在しません。すべての.descファイルをパッケージのDESCサブディレクトリに置く必要があります。
すべてのCOBOL .gntファイルは、パッケージのCOBLIBサブディレクトリにあります。COBOLプログラムは、実行時にprograms.descファイルによって参照されます。
すべての.mpdefファイルは、パッケージのMAPサブディレクトリにあります。これらは、mapsets.descファイルで使用されます。
ARTTDQの/QおよびTSQ DBの作成に使用されるスクリプトは、パッケージに組み込まれる可能性もあります。これらはSCRIPTサブディレクトリにあり、パッケージがデプロイされると呼び出されます。すべてのシェル・スクリプトは互いに独立しているため、呼出しシーケンスがスクリプトの実行結果に影響を与えません。
CICSアプリケーション・パッケージは、「Tuxedoサマリー」ページで管理されます(Tuxedoアプリケーション・パッケージと同様)。詳細は、「アプリケーション・パッケージの管理」を参照してください。
アップロード中に、各パッケージのProperties .xmlファイルと.descリソース構成ファイルに対して検証が行われます。Properties.xmlファイルは.xsd XMLスキーマに対して検証され、一方、リソース構成ファイルは、ファイル形式やコンテンツが適切かどうか(たとえば一意のキー・フィールド制約、列番号および必須列など)について検証されます。
検証に失敗すると、アップロードが失敗してエラー・メッセージが表示されます。パッケージのエラーはすべてポップアップ・ダイアログで報告されます。
「CICS構成」ページにアクセスする手順は、次のとおりです。
詳細は、「CICS構成の構成」を参照するか、または右上の「ヘルプ」をクリックしてください。
デプロイ中、保存済のCICSリソース・ファイルと追加済のCICSアプリケーション・パッケージすべてがソフトウェア・ライブラリから取得され、他のTuxedoドメイン・アセットと一緒に配布パッケージにまとめられます。
デプロイ済のAPPDIRでは、各CICSアプリケーション・パッケージは、パッケージ名に応じて名付けられたサブディレクトリに対応します。マージされたすべての.descリソース・ファイルは、APPDIR/resourcesディレクトリにあり、KIXCONFIG環境変数で参照されます。
次の環境変数設定がsetenv.shファイルに追加されます。
KIXDIR=<full path of ART CICS software>
KIXCONFIG=<full path of ART CICS resources configuration files, fixed as $APPDIR/resources>
PATH=$KIXDIR/bin:$PATH
COBPATH=APP1/COBLIB:APP2/COBLIB:APP3/COBLIB: ... :$COBPATH
COB_LIBRARY_PATH=$COBPATH:$COB_LIBRARY_PATH
KIX_MAP_PATH=APP1/MAP:APP2/MAP:APP3/MAP: ... :$KIX_MAP_PATH
| 注意: | 上に記載されていない環境変数が使用されている場合は、その変数をconfideスクリプトまたはbootスクリプトに手動で指定する必要があります。 |
動的リクエスト・ブローカは、Tuxedoロード・バランシング機能の拡張で、リクエスト・コールに対する応答時間を最短にし、(特にマルチプロセッサ(MP)ドメインで)複数のサーバー間により適切なワークロード分散を実現します。具体的には、動的リクエスト・ブローカは、新しいリクエスト・ルーティング・メトリック(サービス実行時間、ネットワーク時間など)を、UBBCONFIGファイルに設定されている静的ロード値の代替として導入するメカニズムです。したがって、サービスとネットワークのロード・レベルが動的に反映されます。さらに、MPドメインのすべての分散マシン間でメトリックを同期し、最適なリソース使用率を実現します。
server2は、異なるマシン上にあるclient1とclient2の両方に対応します。
UBBCONFIGファイルに指定されているロード値は静的なので、状況が変わるとサービスに適用できなくなる可能性があります。UBBCONFIGファイルに指定されているロード値は静的なので、状況が変わるとサービスに適用できなくなる可能性があります。| 注意: | 動的リクエスト・ブローカは、Oracle Tuxedo 12c以降のリリースのみをサポートします。 |
Enterprise Manager ConsoleのTuxedoドメイン・メニューから「制御」→「Request Brokerの有効化/無効化」をクリックして、動的リクエスト・ブローカ機能を有効または無効にできます。
動的リクエスト・ブローカ機能を有効にすると、次のコマンドを使用して動的ロード情報を表示できます。
$ tmadmin
> psc -m all -v
Oracle Virtual Assembly Builder (OVAB)を使用すると、管理者はOracle Tuxedoアプリケーションをすばやく構成してクラウド環境にプロビジョニングできます。Enterprise Manager for Oracle Tuxedoを使用すると、特定の条件下でEnterprise Managerポリシー・メカニズムを利用してOVABスクリプトを実行し、Tuxedoアプリケーションをデプロイできます。
次に、統合例を示します。この例では、Enterprise Managerを起動してOVABスクリプトを呼び出し、Oracle Tuxedoスレーブ・マシンの台数を増減します。
3つのMPマシン(マスター、バックアップおよびスレーブ)で構成されるゴールデン・システムがあるとします。ここで、スレーブ・マシンの台数を1から10の間で増減するデプロイ・プランを作成する場合は、Tuxedoアプリケーションをデプロイするための次の手順を実行します。
./abctl createDeployerConnection -name WLSADMIN -url http://10.182.73.21:7001 -username ovabAdmin
./abctl createTarget -name myTarget -type ovm -connectionName WLSADMIN -properties ovm.user=admin ovm.pwd=Tuxqa123 ovm.url=http://10.182.73.11:7001 ovm.vmOperationTimeout=3600 ovm.vmmversion=3.0 ovm.poolName=MyServerPool -default
次のコマンドを使用して、接続とターゲットの可用性を確認できます。
./abctl describeDeployerConnections
./abctl describeTargets -connectionName WLSADMIN
./abctl introspectTuxedo -TUXDIR /testarea/tuxreg/tuxedo/tuxedo12.1.1.0 -TUXCONFIG /testarea/tuxreg/workspace/OVAB/tux/work/domain/tuxconfig -environmentScript /testarea/tuxreg/workspace/OVAB/tux/work/domain/setenv_ovab.sh -remoteHost bej301175.cn.oracle.com -remoteUser tuxreg -name master -force
./abctl introspectTuxedo -TUXDIR /testarea/tuxreg/tuxedo/tuxedo12.1.1.0 -TUXCONFIG /testarea/tuxreg/workspace/OVAB/tux/work/domain/tuxconfig -remoteHost bej301165.cn.oracle.com -remoteUser tuxreg -name slave -force
./abctl introspectTuxedo -TUXDIR /testarea/tuxreg/tuxedo/tuxedo12.1.1.0 -TUXCONFIG /testarea/tuxreg/workspace/OVAB/tux/work/domain/tuxconfig -remoteHost bej301168.cn.oracle.com -remoteUser tuxreg -name backup -force
./abctl createAssembly -name testdomain
./abctl addToAssembly -name master -into testdomain
./abctl addToAssembly -name slave -into testdomain
./abctl addToAssembly -name backup -into testdomain
| 注意: |
./abctl createAssemblyArchive -name testdomain -platform OVM -force
./abctl uploadAssemblyArchive -fileName /u01/slce04cn06/general/testarea/tuxreg/OVABR2/oracle.ovab/ab_instance/archives/testdomain.ova -name testdomain -connectionName WLSADMIN
./abctl downloadAssemblyMetadata -connectionName WLSADMIN -name testdomain -generateplan -version 1
./abctl registerAssemblyArchive -name testdomain -connectionName WLSADMIN -waitforComplete -pollTime 300 -version 1 -target myTarget
./abctl createAssemblyInstance -deploymentPlan /u01/slce04cn06/general/testarea/tuxreg/OVABR2/oracle.ovab/ab_instance/catalog/metadata/testdomain/deploymentPlans/myPlan/deploymentPlan.xml -name testdomain -version 1 -target myTarget -connectionName WLSADMIN
./abctl deployAssemblyInstance -assemblyInstanceId 0V0G_5Yn8_testdomain8_1 -connectionName WLSADMIN -waitForComplete -pollTime 3600
次のように、OVABスクリプトdeploy_ovab.shを作成します。
./abctl ./scale -scalingGroupId MpNZ-qhmZ_testdomain_1:testdomain/slave -target 2 -connectionName WLSADMIN
次のコマンドを使用して、scalinggroupIDを検索できます。
./abctl describeScalingGroups -connectionName MasterDeployer
前の手順で作成したOVABスクリプトに関連付けられたEnterprise Manager通知メソッドを作成するには、次の手順を実行します。
上で定義した通知メソッドをトリガーするインシデント・ルールを作成するには、次の手順を実行します。
  
|
