| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
前 |
次 |
この章では、Business Transaction Managementについて説明します。内容は次のとおりです。
Business Transaction Managementのアーキテクチャの概要
以前のバージョンからアップグレードする場合は、1.4項「機能アップグレードの問題」を参照してください。
Oracle ManagementパックのコンポーネントであるBusiness Transaction Managementを使用すると、次のことを実行できます。
アプリケーション環境にデプロイされたサービスを検出し、どのように機能するかを把握します。
Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。
トランザクションを定義および追跡し、トランザクションのコンシューマやビジネス・ペイロードなど、各トランザクションのビジネス・コンテキストを把握します。
リアルタイムでサービスおよびトランザクションのパフォーマンスを監視します。
サービス・レベル合意を定義し、ビジネス基準に基づいてパフォーマンス・ターゲットを設定し、これらのターゲットを基準としてパフォーマンスを監視します。
異常な状態を警告するアラートを生成します。
障害を監視し、根本原因の分析を実行して、ボトルネック、エラーおよび不完全なトランザクションを見つけます。
Business Transaction Managementの使用に関するワークフローの詳細は、第2章「Business Transaction Managementの開始」を参照してください。
管理コンソールを使用して、Business Transaction Management機能セットにアクセスします。コンソールの使用の詳細は、第3章「管理コンソールの使用方法」を参照してください。
コマンドライン・インタフェース(CLI)を使用してスクリプトや個別のコマンドを実行することもできます。CLIの使用の詳細は、第10章「コマンドおよびスクリプト」を参照してください。
Enterprise Managerコンソールから一部のBusiness Transaction Management機能にアクセスすることもできます。詳細は、「新機能および変更点」を参照してください。
この項では、追加された新機能および最終リリースからの変更点について説明します。
SOA_B2Bプローブ – SOAアプリケーションのSOA B2B (企業間)アダプタを監視します。
アウト・オブ・バンド検出 - オブザーバが新規コンポーネントの検出を試みる際の動的検出期間を有効化します。オブザーバの詳細設定で有効化されるこの機能の詳細は、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。
SOA 12.1.3 - Business Transaction Managementは、Oracle SOA Suiteリリース12.1.3と互換性があります。
SOA_RESTアダプタ - SOAアプリケーション(SOAリリース12.1.3のみ)のSOA RESTアダプタを監視します。
OSB 12c - Business Transaction Managementは、Oracle Service Busリリース12cと互換性があります。この機能を使用するには、WebLogic 12オブザーバをインストールします。
Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。
Business Transaction Managementは、最高レベルで次の3つのタイプのコンポーネントで構成されています。
セントラル・サーバー: セントラル・サーバーは、アプリケーション・サーバーにデプロイするアプリケーションEARファイルです。3つのセントラル・サーバーがあります。これらのサーバーについて、それぞれ1つのインスタンスのみをデプロイします。パフォーマンス上の理由から、各サーバーを個別のアプリケーション・サーバーにデプロイする必要があります。監視対象のサービスまたはコンポーネントをホストするアプリケーション・サーバーには、いずれのセントラル・サーバーもデプロイしないでください。次のセントラル・サーバーがあります。
メイン・サーバー(btmMain.ear): Business Transaction Managementのすべてのセントラル・システム・サービスおよびユーザー・インタフェース・アプリケーション(スフィアを含む)が含まれています。スフィアは、Business Transaction Management環境を管理するBusiness Transaction Managementのコンポーネントです。また、btmMain.earにはF5仲介のサブデプロイメントが含まれています。
パフォーマンス・サーバー(btmPerformanceServer.ear): サービス・レベルの管理コンポーネントが含まれています。btmMain.earまたはbtmTransactionServer.earがデプロイされているアプリケーション・サーバー以外のアプリケーション・サーバーにbtmPerformanceServer.earをデプロイします。
トランザクション・サーバー(btmTransactionServer.ear): トランザクション管理コンポーネントが含まれています。btmMain.earまたはbtmPerformanceServer.earがデプロイされているアプリケーション・サーバー以外のアプリケーション・サーバーにbtmTransactionServer.earをデプロイします。
オブザーバ: オブザーバは、監視対象のビジネス・アプリケーションをホストするアプリケーション・サーバーにインストールする一覧のライブラリです。オブザーバは、アプリケーションのコンポーネント間のメッセージおよびコールを監視します。オブザーバは、多くのタイプのコンポーネントを監視でき、JavaEE、OSB、WCFなど、オブザーバが監視するタイプに基づいて分類されます。
モニター(btmMonitor.ear): モニターは、アプリケーションのパフォーマンスおよび使用状況の測定をオブザーバから収集します。モニターは、アプリケーション・サーバーにデプロイするアプリケーションEARファイルです。大規模システムでは、シングルトンまたはレプリケートとして複数のモニターをデプロイできます。パフォーマンス上の理由から、セントラル・サーバーがデプロイされているアプリケーション・サーバーにはモニターをデプロイしないでください。
また、Business Transaction Managementは、パフォーマンス測定の格納、メッセージのログ記録、環境モデルとBusiness Transaction Management構成の維持のために、Oracle RDBMSにアクセスする必要もあります。
次の図に、一般的な分散アプリケーション環境、およびBusiness Transaction Managementコンポーネントとその環境との関係を示します。
図1-1 一般的なアプリケーション環境でのBusiness Transaction Managementコンポーネントのデプロイメント
Business Transaction Managementは、様々なBusiness Transaction Managementコンポーネントが複数のマシンおよびアプリケーション・サーバーにデプロイされている分散アプリケーション環境で使用するように設計されています。
技術的に、すべてのセントラル・サーバーを単一のアプリケーション・サーバーにインストールできますが、そのようなデプロイメント・シナリオは本番環境ではお薦めしません。単一のアプリケーション・サーバーへのインストールは、デモンストレーションや製品の使用方法を学習する場合には有用ですが、このシナリオは、たとえば数多くのビジネス・サービスや大量のメッセージ・トラフィックに対しては正常に対応できない可能性があります。
各セントラル・サーバーを個別のアプリケーション・サーバーにデプロイすることをお薦めします。特にパフォーマンス・コンポーネントとトランザクション・コンポーネントは、通常、パフォーマンス分析に関する大量の計算を実行します。アプリケーション・サーバー間でプロセスを分割することにより、メモリーとプロセッサのリソースを制御できます。
また、セントラル・サーバーとは別のアプリケーション・サーバーにモニターをデプロイする必要があります。監視の要件に応じて、複数のモニターをデプロイする必要がある場合があります。モニターは、シングルトンまたはレプリケートとしてロード・バランサの背後にデプロイできます。モニターのレプリケートの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。
オブザーバは常に、セントラル・サーバーまたはモニターをホストしているアプリケーション・サーバーの外部にインストールする必要があります。
Business Transaction Managementでは、リリース12.1.0.2、12.1.0.3、12.1.0.4または12.1.0.5からアップグレードするための簡単なプロセスが提供されています。
アップグレード・プロセスで、管理構成、オブジェクト定義および既存の操作データを保持しつつ、停止時間が最小化されます。
システムのバックアップおよびアップグレードに使用されるプロセスの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。
この項では、Business Transaction Managementによるトランザクションの監視や通信の保護機能に影響を与える可能性がある、このアップグレードで導入された変更点について説明します。ここに含まれる項を読み、製品の変更点がトランザクション定義およびトランザクションを監視するBusiness Transaction Managementの機能にどう影響するかを理解する必要があります。アップグレード後、いくつかのトラフィックを実行してトランザクション・インスタンスを監査し、システムで期待どおりにトランザクションが監視されていることを確認することをお薦めします。そのようでない場合は、状況に応じて、オブザーバ通信ポリシーの調整、トランザクション定義の更新またはノード間への手動キーイングの追加が必要となる場合があります。
次の各項を読んだ後も12.1.0.5リリースへのアップグレードについて不明な点がある場合は、Oracleテクニカル・サポートでサービス・リクエストをオープンしてください。
12.1.0.3より前のリリースでは、WebLogic 10.3サーバーにインストールするための様々なオブザーバが提供されていました。各タイプのオブザーバには、特定のコンポーネント・タイプを監視する機能を提供する一連のプローブが含まれていました。たとえば、JavaEEオブザーバにはJavaEEコンポーネントを監視するプローブが、SOAオブザーバにはSOAコンポーネントを監視するプローブが含まれていました。12.1.0.3以降のリリースでは、WebLogic 10.3サーバーにインストールするための単一の汎用オブザーバが提供されています。この汎用オブザーバには以前のオブザーバに含まれていたすべてのプローブのスーパーセットが含まれているため、以前に監視可能であったコンポーネント・タイプのスーパーセットの監視が可能となります。
汎用オブザーバにアップグレードすると、システムで新しいタイプのコンポーネントを検出および監視できるようになります。この拡張機能により新規オブジェクトが検出され、次に説明するようにトランザクションの表示および監視機能に影響を及ぼす可能性があります。
A→B→Cというトランザクションがあり、新たにB1という操作が監視されると(コール・チェーンはA→B→B1→Cになります)、使用される相関方法に応じて次の2つの結果が考えられます。
自動相関: 操作Cはグレーで表示されます。BからCに欠落メッセージ条件が定義されている場合は、アラートを受信します。トランザクションを再定義してCを表示可能にし、トランザクションを監視対象にする必要があります。AからB、Cへのメッセージが変化しないというまれな状況では、システムでCが引き続き監視されます。
手動相関: 操作Cが表示可能になり、Bと相関します。新しく監視された操作B1は、依存関係グラフで表示可能になりますが、トランザクション定義では表示可能になりません。トランザクションを再定義してB1を表示可能にする必要があります。この場合、トランザクションは監視されますが、B1はその中に含まれません。
アップグレード・プロセスでは、既存のオブザーバ通信ポリシーの値が継承されます。つまり、既存のポリシーでほとんどのプローブ・フィールドがアクティブ化されており、WebLogic汎用オブザーバへのアップグレードを行い、以前は検出されなかったが現在はアクティブ化されたプローブがあるコンポーネント・タイプがアプリケーション・サーバーでホストされる場合、これらは検出および監視されます。
検出および監視するコンポーネントの数を関心のあるものだけに制限する場合は、アップグレードの前に、オブザーバ通信ポリシーでアクティブ・プローブを確認および調整できます。作業内容を確認し、汎用オブザーバの使用により発生する変更内容を判断するには、WebLogic 10.3コンテナで実行される操作に含まれるすべてのトランザクションを監査する必要があります。
オブザーバの詳細は、12.1.1項「オブザーバについて」を参照してください。オブザーバのアップグレードの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。
基礎となるテクノロジによっては、クライアントから直接サービス・エンドポイントに流れるメッセージもありますが、その他のメッセージは実際の宛先に到達する前に中間エンドポイントのホストを通過します。このような中間エンドポイントは、メッセージ・システム、ジョブ・スケジュール・システム、分散システムなどの実装で構成されている場合があります。
中間エンドポイントを使用するテクノロジのプローブをインストールしている場合、Business Transaction Managementを使用すると、このようなシステムのすべてのエンドポイントを監視するか、またはエッジにあるエンドポイントのみを監視するかを指定できます。多くの場合、これらは目的のビジネス・サービスを直接示すエンドポイントです。現在のリリースでは、デフォルトで中間エンドポイントの監視はオフになっています。これによって、監視のパフォーマンスが向上し、分散アプリケーションの監視に不要なデータが排除されます。
中間エンドポイントの監視がオンになっているシステムからアップグレードする場合、Business Transaction Managementでは、新規のデフォルト設定にアップグレードした後、これらのエンドポイントの設定が保持されます。これらのエンドポイントは依存関係グラフで確認できます。これらはトランザクション・グラフではグレー表示されます。トランザクション定義を編集してこれらのエンドポイントを削除できます。
デフォルト設定が示すように、中間エンドポイントの監視をオフにすることをお薦めします。
検出の制限の詳細は、4.1.3項「検出の制限」を参照してください。
現在のリリースのBusiness Transaction Managementでは、オブザーバ認証が導入されており、オブザーバとモニター間の通信でSSLがデフォルトでオンに設定されています。これらの機能の詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。現在のリリースでは、新しいオブザーバ通信ポリシーを作成すると、クライアント認証およびSSLがデフォルトでオンになります。
ほとんどの場合、システムをアップグレードしても予想される動作に影響はありません。次に説明するように、オブザーバとモニター間の通信に影響を及ぼす例として、旧オブザーバと新規通信ポリシーを組み合せる場合があります。
既存のオブザーバが、SSLを使用しないモニターと通信を行っています。アップグレードを行っても、何も変わりません。新規オブザーバは旧オブザーバと同じように動作します。動作を変更するには、オブザーバ通信ポリシーを編集してSSLまたはオブザーバ認証を追加します。
既存のオブザーバがSSLを介してモニターと通信を行っています。アップグレードを行っても、引き続き同じように動作します。クライアント認証を追加する場合は、オブザーバ通信ポリシーをそのように編集する必要があります。
フィールドに旧オブザーバが存在しており、セントラル・サーバーとモニターをアップグレードします。旧オブザーバに適用する新規オブザーバ通信ポリシーを作成すると、旧オブザーバはモニターに対して認証できず、モニターは旧オブザーバがそのモニターに送信するデータを認識できないため、旧オブザーバは失敗します。新規オブザーバが使用可能で、クライアント認証を使用する場合は、新規オブザーバをインストールしてください。新規オブザーバを使用できない場合は、オブザーバ通信ポリシーで認証をオフにしてください。
リリース12.1.0.6のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。
SOA_B2B – SOAアプリケーションのSOA B2B (企業間)アダプタを監視します。
リリース12.1.0.5のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。
SOA_JCA: SOA JCAアダプタを監視します(AQ、データベース、ファイル、FTP、JMS、MQシリーズ、ソケット、Oracle Applicationsなど)。
リリース12.1.0.4のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。
SOA_WORKFLOW: Oracle SOAヒューマン・ワークフローのコンポーネントおよび通知を監視します。
SOA_DIRECT: SOAコンポジット間およびSOAとOracle Service Bus間の直接バインディング・コールを監視します。
新規プローブを含むオブザーバにアップグレードすると、そのプローブは、作成するすべての新規オブザーバ通信ポリシーですぐに使用可能になります。ただし、プローブは既存のポリシーに自動的には追加されません。既存のポリシーで新規プローブのいずれかを使用する場合は、手動でポリシーに追加する必要があります。プローブをポリシーに追加する方法の詳細は、12.1.2.3項「プローブの追加」を参照してください。
アクティブ化後、新規プローブのタイプによって新規タイプのコンポーネントが検出されます。定義したトランザクションのフロー内でこれらの新しく検出されたコンポーネントのいずれかがコールされる場合は、トランザクションを完全に監視することができなくなります。トランザクションの監視は、新しく検出されたコンポーネントの部分で終了します。
トランザクションを完全に監視するには、次のいずれかの方法でトランザクションを編集する必要があります。
非結合ノードのキーイングを手動で行うことにより、トランザクションを元の状態に戻します。
新しく検出されたコンポーネントを新規ノードとしてトランザクションに追加し、それを非結合ノードに接続することにより、トランザクションを拡大します。
セントラル・サーバーとモニターをアップグレードすると、作成するすべての新規オブザーバ通信ポリシー用に(既存のポリシーは影響を受けません)、新規JMSオプションが「詳細設定」の「モデル構成」セクションに追加されます。デフォルトで、この新規JMSオプションは「フローのエッジのモデル化」に設定されます。この設定では、JMSトピック・メッセージ・リスナーのみがモデル化されます。すべてのJMSトピック、JMSキューおよび関連メッセージ・リスナーをモデル化する場合は、JMSオプションを編集して「すべてモデル化」に設定する必要があります。
詳細は、「モデル構成」のエントリを参照してください。
リリース12.1.0.4では、以前のリリースに含まれるJMSプローブに置き換わる、大幅に改善されたWebLogic用のJMSプローブが新たに提供されています。新規JMSプローブは次のオブザーバに含まれています。
WebLogic 10.3用の汎用オブザーバ
WebLogic 12.1用のJavaEEオブザーバ
セントラル・サーバーとモニターをアップグレードした後、これらは新旧両方のJMSプローブで互換性が維持されます。オブザーバをアップグレードする必要はなく、アップグレードしない場合は、引き続き以前と同様に動作します。アップグレードされたオブザーバとアップグレードされていないオブザーバが混在するシステムを実行することもできます。ただし、すべてのオブザーバをアップグレードすることをお薦めします。
アップグレード後、オブザーバによってシステムのJMSコンポーネントが再検出され、新規タイプのJMSサービスとしてモデル化されます。キューおよびトピックはタイプ「JMSリソース」のサービスとしてモデル化され、メッセージ・リスナーはタイプ「メッセージ・リスナー」のサービスとしてモデル化されます。(旧JMSプローブによって検出される)旧JMSサービスは引き続き表示されますが、システム内を流れるビジネス・トラフィックを登録しません。旧サービスのタイプは「JMSメッセージ・コンシューマ」です。これらの旧JMSサービスの登録を解除する必要があります。
旧JMSサービスを含むトランザクションは正しく機能しなくなります。旧トランザクションを削除し、新しく検出されたJMSサービスを使用して再定義する必要があります。
