1. Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの共通の構成および管理手順
  3. エンタープライズ・デプロイメントの共通の構成および管理タスク

19 エンタープライズ・デプロイメントの共通の構成および管理タスク

この項では、エンタープライズ・デプロイメント環境で実行する必要がある構成および管理タスクについて説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

すべてのエンタープライズ・デプロイメントの構成および管理タスク

ここに示すのは、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い一般的な構成および管理タスクです。

  • WLSRuntimeSchemaDataSourceの適切なサイズ変更および構成の確認
    Oracle FMW 14.1.2では、WLSRuntimeSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データソースです。WLSRuntimeSchemaDataSourceは、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。
  • 管理サーバーの手動フェイルオーバーの確認
    ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップは、これ以降の項で詳細に説明します。
  • エンタープライズ・デプロイメントのuploadおよびstageディレクトリの絶対パスへの変更
    ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく同じ絶対パスを持つように更新します。そうしないとデプロイメントの問題が発生する可能性があります。
  • WebLogicクラスタのフロントエンド・ホストおよびポートの設定
    Oracle SOA SuiteサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。ただし、Oracle SOA Suiteエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。
  • WebLogic ServerおよびOracle HTTP Serverでのサード・パーティSSL証明書の使用について
    このOracle SOA Suiteエンタープライズ・デプロイメント・トポロジでは、外部クライアントからバックエンドWebLogic ServerまでのすべてでSSLを使用します。このガイドの前の章では、様々なFMWコンポーネントに必要なSSL証明書を生成するためのスクリプト(generate_perdomainCACERTS.shおよびgenerate_perdomainCACERTS-ohs.sh)が提供されています。
  • 中間層とSSLエンドポイント間のSSL通信の有効化
    中間層とフロントエンド・ハードウェア・ロード・バランサ(またはSOA Suite WebLogic Serverによってアクセスする必要があるその他の外部SSLエンドポイント)との間のSSL通信を有効にする方法を理解することが重要です。たとえば、外部Webサービスの呼出しやコールバックなどです。
  • エンタープライズ・デプロイメントの管理用のロールの構成
    1つのエンタープライズ・デプロイメント・ドメインで各製品を効果的に管理するには、どの製品が特定の管理ロールまたはグループを必要とするか、また製品固有の管理ロールをエンタープライズ・デプロイメント管理グループにどのように追加するかを理解する必要があります。
  • エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用
    Oracle WebLogic永続ストア・フレームワークは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。
  • WebサービスのJDBC永続ストアについて
    デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。
  • RACおよびGridlinkデータソースを使用する場合の構成のベスト・プラクティス
    Oracle RACデータベースの使用時は、GridLinkデータ・ソースを使用することをお薦めします。エンタープライズ・デプロイメント・ガイドで説明されているステップに従うと、データソースはGridLinkとして構成されます。
  • 接続文字列でのTNS別名の使用
    データソースのJDBC接続プールで長いデータベース接続文字列を指定するかわりに、別名を作成してURL情報をマップできます。接続文字列情報は、関連する別名とともにtnsnames.oraファイルに格納されます。この別名は、接続プールの接続文字列で使用されます。
  • エンタープライズ・デプロイメントのバックアップとリカバリの実行
    Oracle SOA Suiteエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

WLSRuntimeSchemaDataSourceの適切なサイズ変更および構成の確認

Oracle FMW 14.1.2では、WLSRuntimeSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データソースです。WLSRuntimeSchemaDataSourceは、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。

WLSRuntimeSchemaDataSourceの接続使用量を削減するには、JMS JDBCおよびTLOG JDBCストア接続キャッシュ・ポリシーを、各接続キャッシュ・ポリシー設定を使用して「デフォルト」から「最小」に変更します。バックエンド・データベース・システム内の接続数を削減する必要がある場合、キャッシュ・ポリシーを「最小」に設定することをお薦めします。キャッシュ・ポリシー「なし」を使用するとパフォーマンスが低下する可能性があるため、このポリシーは使用しないでください。JDBCストアで使用される接続についての詳細な推奨事項については、『WebLogic永続ストアの管理』で、JDBCストア接続キャッシュ・ポリシーの構成に関する項を参照してください。

WLSRuntimeSchemaDataSource接続プールのデフォルト・サイズは75です(GridLinkデータ・ソースの場合はサイズが2倍になります)。FMWの各クラスタのサイズと、移行に構成する候補に応じて、このサイズは高い値にチューニングすることができます。たとえば、ストア当たりのワーカー・スレッドがデフォルト値である一般的なSOA EDGデプロイメントを考えてみます。25個を超えるJDBCストアまたはTLOG-in-DBインスタンス(あるいはその両方)が同じWebLogicサーバーにフェイルオーバーでき、「接続キャッシュ・ポリシー」が「デフォルト」から「最小」に変更されていない場合は、接続の競合問題が発生する可能性があります。このような場合は、デフォルトのWLSRuntimeSchemaDataSourceプール・サイズ(最大容量)を増やす必要があります(各JMSストアは、最小で2つの接続を使用し、リースとJTAが追加されてもプールの競合が発生します)。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

管理サーバーの手動フェイルオーバーの検証

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップは、これ以降の項で詳細に説明します。

前提条件:

  • 管理サーバーを、ADMINVHN上またはフローティングIP/VIPにマップされるカスタム仮想ホスト上でリスニングするように構成します。ANY (空白のリスニング・アドレス)、localhost、または単一ノードを一意に識別するホスト名でリスニングすることはできません。

    ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

  • この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。

  • 管理サーバーはSOAHOST1からSOAHOST2アプリケーションにフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

    • SOAHOST1: 100.200.140.165

    • SOAHOST2: 100.200.140.205

    • ADMINVHN : 100.200.140.206これは管理サーバーを実行している場所の仮想IPであり、SOAHOST1またはSOAHOST2で使用可能になるように仮想サブインタフェース(eth0:1など)に割り当てられます。

  • Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、SOAHOST2にインストールされています。

    具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。

次の項では、管理サーバーのフェイルオーバー手順のテストを実行する方法について詳しく説明します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

ホストごとのノード・マネージャを使用している場合の管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

管理サーバーを別のホストにフェイルオーバーするには:

  1. SOAHOST1で管理サーバーを停止します。

  2. SOAHOST1でノード・マネージャを停止します。

    NM_HOMEで作成されたスクリプトstopNodeManager.shを使用できます。

  3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

    1. SOAHOST1上で次のコマンドをroot権限で実行し(XはADMINVHNで現在使用しているインタフェース)、そのCIDRで仮想IPアドレスを確認します。 

      ip addr show dev ethX

      たとえば:

      ip addr show dev eth0

    2. SOAHOST1で次のコマンドをroot権限で実行します(XはADMINVHNで現在使用しているインタフェース)。 

      ip addr del ADMINVHN/CIDR dev ethX

      たとえば:

      ip addr del 100.200.140.206/24 dev eth0

    3. 次のコマンドをSOAHOST2でrootとして実行します。 

      ip addr add ADMINVHN/CIDR dev ethX label ethX:Y

      たとえば:

      ip addr add 100.200.140.206/24 dev eth0 label eth0:1

      ノート:

      使用するCIDRとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります

  4. arpingを使用してルーティング表を更新します。たとえば: 

    arping -b -A -c 3 -I eth0 100.200.140.206

  5. SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。 

    cd $NM_HOME

  6. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を削除します。

    SOAHOST1 nodemanager.domainsファイルで次のようなエントリが生成されます。 

    soaedg_domain=MSERVER_HOME;

  7. SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。 

    cd $NM_HOME

  8. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を追加します。

    SOAHOST2 nodemanager.domainsファイルで次のようなエントリが生成されます。 

    soaedg_domain=MSERVER_HOME;ASERVER_HOME

  9. SOAHOST1でノード・マネージャを起動し、SOAHOST2でノード・マネージャを再起動します。

  10. SOAHOST2で管理サーバーを起動します。

  11. 次のURLを使用して、SOAHOST2上の管理サーバーにアクセスできることを確認し、Fusion Middleware Controlのコンポーネントのステータスを確認します:

    https://ADMINVHN:9002/em
ロード・バランサを介したSOAHOST2上の管理サーバーへのアクセスの検証

AdminServerにアクセスするようにWeb層を構成してある場合、標準の管理URLを使用して、管理サーバーの手動フェイルオーバーを実行した後で管理サーバーにアクセスできるかどうかを確認することが重要です。

ロード・バランサから次のURLにアクセスして、SOAHOST2で稼働中の管理サーバーにアクセスできることを確認します。

  • https://admin.example.com:445/em

    ここで、445は、ロード・バランサでFusion Middleware Controlへのアクセスに使用するポートです。

    このURLはOracle Enterprise Manager Fusion Middleware Controlを表示するはずです。

  • このドメインに対して定義したプロバイダからWebLogicリモート・コンソールにログインできることを確認します。
ホストごとのノード・マネージャを使用する場合の管理サーバーのSOAHOST1へのフェイルバック

管理サーバーの手動フェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを確認したら、管理サーバーを元のホストに戻すことができます。

この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

  1. SOAHOST2で管理サーバーを停止します。
  2. SOAHOST2でノード・マネージャを停止します。
  3. 次のコマンドをSOAHOST2上でrootとして実行します。
    ip addr del ADMINVHN/CIDR dev ethX
    たとえば:
    ip addr del 100.200.140.206/24 dev eth0
  4. 次のコマンドをSOAHOST1上でrootとして実行します。
    ip addr add ADMINVHN/CIDR dev ethX label ethX:Y
    たとえば:
    ip addr add 100.200.140.206/24 dev eth0 label eth0:1

    ノート:

    使用するCIDRとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります

  5. SOAHOST1上でarpingを使用して、ルーティング表を更新します。
    arping -b -A -c 3 -I eth0 100.200.140.206
  6. SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  7. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を削除します。
  8. SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  9. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を追加します。
  10. SOAHOST2でノード・マネージャを起動し、SOAHOST1でノード・マネージャを再起動します。
  11. SOAHOST1で管理サーバーを起動します。
  12. WebLogicリモート・コンソールを使用して、このドメインに対して定義したプロバイダにアクセスできることをテストします。
  13. 次のURLを使用して、Oracle Enterprise Managerにアクセスできることと、そこでのコンポーネントのステータスを確認できることを確認します。
    https://ADMINVHN:9002/em
    https://admin.example.com:445/em

エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく同じ絶対パスを持つように更新します。そうしないとデプロイメントの問題が発生する可能性があります。

このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避と、ステージ・モードが必要なデプロイメントのために必要です。

デプロイメント・ステージとアップロード場所のディレクトリ・パスを更新するには、次のステップを実行します。

  1. WebLogicリモート・コンソールにログインして、このドメインのプロバイダにアクセスします。

  2. 「ツリーの編集」を開きます。

  3. 「環境」を開きます。

  4. 「サーバー」を開きます。

  5. 編集する管理対象サーバーの名前をクリックします。管理対象サーバーごとに次のステップを実行します:

    1. 「詳細」タブをクリックします。
    2. 「デプロイメント」タブをクリックします。
    3. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します:

      MSERVER_HOME/servers/server_name/stage

      MSERVER_HOMEを、MSERVER_HOMEディレクトリのフルパスに置き換えます。

      編集する管理対象サーバーの正しい名前を使用して更新します。

    4. 「アップロード・ディレクトリ名」を次の値に更新します:

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEを、ASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

    5. 「保存」をクリックします。
    6. 「サーバーのサマリー」画面に戻ります。

    新しい管理対象サーバーごとに同じステップを繰り返します。

  6. 移動して、AdminServerの「アップロード・ディレクトリ名」の値を更新します:

    1. 「サーバー」に移動して「AdminServer」を選択します。
    2. 「詳細」タブをクリックします。
    3. 「デプロイメント」タブをクリックします
    4. 「ステージング・ディレクトリ名」が次の絶対パスに設定されていることを確認します:

      ASERVER_HOME/servers/AdminServer/stage

    5. 「アップロード・ディレクトリ名」を次の絶対パスに更新します:

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEを、ASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

    6. 「保存」をクリックします。

  7. 該当するすべてのオブジェクトを変更したら、ショッピング・カートの変更をコミットします。

  8. 変更内容を有効にするためにすべてのサーバーを再起動します。EDGのステップを順に実行しており、すぐには何もデプロイしない場合は次の再起動まで待つこともできます。

    ノート:

    次のドメインの構成を直接続行する場合は、ステージおよびアップロード・ディレクトリの変更を有効にするための再起動が、ここで必ず必要なわけではありません。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

WebLogicクラスタのフロントエンド・ホストおよびポートの設定

Oracle SOA SuiteサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。ただし、Oracle SOA Suiteエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。

WebLogicリモート・コンソールからフロントエンド・ホストおよびポートを設定するには:

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」を開きます。
  3. 「環境」を開きます。
  4. 「クラスタ」を開きます。「クラスタ」ページで、変更するクラスタをクリックし、「HTTP」タブを選択します。
  5. 表19-1の情報を使用して、必要なフロントエンド・ホスト名およびポートを各クラスタに追加します。

    表19-1 各クラスタのフロントエンド・ホスト名およびポート

    名前 クラスタ・アドレス フロントエンド・ホスト フロントエンドHTTPポート フロントエンドHTTPSポート

    SOA_Cluster

    空白のままにします

    soa.example.com

    0

    443

    WSM-PM_Cluster

    空白のままにします

    soainternal.example.com

    0

    444

    OSB_Cluster

    空白のままにします

    osb.example.com

    0

    443

    ESS_Cluster

    空白のままにします

    soa.example.com

    0

    443

    BAM_Cluster

    空白のままにします

    soa.example.com

    0

    443

    MFT_Cluster

    空白のままにします

    mft.example.com

    0

    443
  6. 「保存」をクリックします。
  7. ショッピング・カートの変更をコミットします。
  8. クラスタの管理対象サーバーを再起動します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

WebLogic ServerおよびOracle HTTP Serverでのサード・パーティSSL証明書の使用について

このOracle SOA Suiteエンタープライズ・デプロイメント・トポロジでは、外部クライアントからバックエンドWebLogic ServerまでのすべてでSSLを使用します。このガイドの前の章では、様々なFMWコンポーネントに必要なSSL証明書を生成するためのスクリプト(generate_perdomainCACERTS.shおよびgenerate_perdomainCACERTS-ohs.sh)が提供されています。

これらのスクリプトは、WebLogicドメインのドメインごとの認証局を使用して、異なるSSL証明書を生成します。また、これらのスクリプトは、フロントエンドのSSL証明書を信頼キーストアに追加します。ただし、本番環境では、独自の認証局またはサード・パーティの認証局によって発行された独自のSSL証明書を使用できます。この項では、このタイプのSSL証明書を使用してEDGシステムを構成するためのガイドラインについて説明します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

WebLogic Serverでのサード・パーティSSL証明書の使用

次に、WebLogic Serverでのカスタムまたはサード・パーティSSL証明書の使用に関するガイドラインを示します:

  • 各WebLogic Serverで使用されるSSL証明書(アイデンティティ・キー、秘密キー)は、そのサーバーのリスニング・アドレスに発行する必要があります。たとえば、サーバーWLS_PROD1がapphost1.example.comでリスニングしている場合、SSL証明書のCNは、そのホスト名であるか、そのホスト名に対して有効なワイルドカード名である必要があります。

  • Oracleでは、同じドメイン内のすべてのサーバーで共有されるアイデンティティ・キーストアを使用することをお薦めします。この場合、それぞれ異なる別名にマップされた異なるWebLogic Serverで使用されるすべての秘密キーをインポートします。

  • Oracleでは、ドメイン内のすべてのサーバーで共有される信頼キーストアを使用することをお薦めします。認証局の証明書(および必要に応じて中間CAおよびルートCA)をこの信頼キーストアにインポートする必要があります。

  • WebLogicドメインの構成で、各WebLogic Serverのアイデンティティ・キーストア、アイデンティティ・キーの別名、および信頼キーストアを指定する必要があります。WebLogicのリモート・コンソールを使用して、サーバーごとにこれらのSSL設定を構成します。

  • 信頼できるキーストアを指すように適切なJavaオプションを使用してWebLogic Serverを起動し、そのようなトラスト・ストアに含まれる認証局を使用する外部SSLエンドポイントと通信できるようにします。

次のコマンドは、WebLogicでSSL証明書を管理する場合に役立ちます。

  • SSL証明書(秘密キー)をアイデンティティ・キーストアにインポートするコマンド:

    構文

    
WL_HOME/server/bin/setWLSEnv.sh

java utils.ImportPrivateKey
      -certfile cert_file
      -keyfile private_key_file
      [-keyfilepass private_key_password]
      -keystore keystore
      -storepass storepass
      [-storetype storetype]
      -alias alias 
      [-keypass keypass]

    apphost1.example.comに発行された証明書の例

    
WL_HOME/server/bin/setWLSEnv.sh

java utils.ImportPrivateKey \
-certfile apphost1.example.com_cert.der \
-keyfile apphost1.example.com_key.der \
-keyfilepass keypassword \
-storetype pkcs12 \
-keystore CustomIdentityKeystore.pkcs12 \
-storepass keystorepassword \
-alias apphost1.example.com \
-keypass keypassword

  • SSL証明書(信頼できる証明書)を信頼できるキーストアにインポートするコマンド:

    構文

    
keytool -import -v -noprompt -trustcacerts \
-alias <alias_for_trusted_cert> \
-file <certificate>.der \
-storetype <keystoretype> \
-keystore <customTrustKeyStore> \
-storepass <keystorepassword>

    CA証明書のインポートの例

    
keytool -import -v -noprompt -trustcacerts \
-alias example_ca_cert \
-file example_ca_cert.der \
-storetype pkcs12 \
-keystore CustomTrustKeyStore.pkcs12 \
-storepass keystorepassword

    カスタム信頼キーストアをロードするサーバーのJavaオプションの例

    
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
      -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/CustomTrustKeyStore.pkcs12
      -Djavax.net.ssl.trustStorePassword=<keystorepassword>"
export EXTRA_JAVA_PROPERTIES
Oracle HTTP Serverでのサード・パーティSSL証明書の使用

次に、OHSで独自のSSL証明書を使用するためのガイドラインを示します:

  • SSLを使用する各OHS仮想ホストでは、秘密キーが1つのみ含まれるウォレットを使用する必要があります。この秘密キーは、OHSサーバーのSSL証明書として使用されます。これは、仮想ホストがリスニングしているホスト名("VirtualHost"ディレクティブのホスト名の値)に発行する必要があります。秘密キーには、サブジェクト代替名(SAN)などの他のホスト名(たとえば、"ServerName"ディレクティブの値)を含めることもできます。仮想ホストには、このウォレットを指すSSLWalletディレクティブを含める必要があります。

  • 異なるOHS仮想ホストは、VirtualHostディレクティブで同じホスト名を使用しているかぎり、同じSSLWallet (つまり、同じ秘密キー)を使用できます。ポートは異なってもかまいません。

  • OHSは、WebLogic Serverに接続するとクライアントとして機能します。したがって、WebLogicの証明書を発行した認証局を信頼する必要があります。mod_wl_ohs.confファイルのディレクティブWLSSLWalletを使用して、WebLogic証明書のCA証明書を含む適切なウォレットを指し示します。

  • フロントエンド・ロード・バランサは、OHSサーバーに接続するとクライアントとして機能します。OHSで使用される証明書を発行した認証局を信頼する必要があります。ロード・バランサのドキュメントを確認して、OHSのCAを信頼できる認証局としてインポートする必要があります。

次のコマンドは、OHSでキーとウォレットを管理する場合に役立ちます。

  • OHSのウォレットを作成するコマンド(orapki):

    構文

    
$WEB_ORACLE_HOME/bin/orapki wallet create \
-wallet wallet \
-auto_login_only

    例

    
$WEB_ORACLE_HOME/bin/orapki wallet create \
-wallet /u02/oracle/config/keystores/orapki/ \
-auto_login_only

  • アイデンティティ・キーストアからウォレットに秘密キーを追加するコマンド(orapki):

    構文

    
$WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
-wallet wallet \
-pwd pwd \
-keystore keystore \
-jkspwd keystorepassword 
[-aliases [alias:alias..]]

    例

    
$WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
-wallet /u02/oracle/config/keystores/orapki/ \
-keystore /u02/oracle/config/keystores/customIdentityKeyStore.pkcs12 \
-jkspwd keystorepassword \
-aliases ohshost1.example.com

  • 信頼できるキーストアからウォレットにすべての信頼できるキーを追加するコマンド(orapki):

    例

    
$WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
-wallet /u02/oracle/config/keystores/orapki/ \
-keystore /u02/oracle/config/keystores/customTrustKeyStore.pkcs12 \
-jkspwd password

  • ウォレットのすべてのキーをリストするコマンド(orapki):

    例

    
$WEB_ORACLE_HOME/bin/orapki wallet display \
-wallet /u02/oracle/config/keystores/orapki/

中間層とSSLエンドポイント間のSSL通信の有効化

中間層とフロントエンド・ハードウェア・ロード・バランサ(またはSOA Suite WebLogic Serverによってアクセスする必要があるその他の外部SSLエンドポイント)との間のSSL通信を有効にする方法を理解することが重要です。たとえば、外部Webサービスの呼出しやコールバックなどです。

ノート:

次のステップは、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

中間層とフロントエンド・ロード・バランサ間のSSL通信が必要になるとき

エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。

たとえば、次の例は、Oracle SOA Suiteエンタープライズ・デプロイメントに適用できます:

  • Oracle Business Process ManagementおよびSOA Composerでは、特定のWebインスタンス経由でロール情報やセキュリティ情報を取得しようとするときに、フロントエンド・ロード・バランサのURLにアクセスする必要があります。一部の呼出しについては、LBR証明書をWebLogic Serverのトラスト・ストアに追加する必要があるだけでなく、SOAサーバーのリスニング・アドレス用に適切なアイデンティティ・キー証明書を作成する必要もあります。

  • Oracle Service Busは、ロード・バランサのSSL仮想サーバーで公開されているエンドポイントに対する呼出しを実行する。

  • Oracle SOA Suiteのコンポジット・アプリケーションとサービスは、ロード・バランサで公開されているSSLアドレスを使用して呼出しを実行する必要のあるコールバックを、頻繁に生成する。

  • Oracle SOA Suiteコンポジット・アプリケーションおよびサービスは通常、SSLを使用して外部Webサービスにアクセスします。

  • Oracle Enterprise Manager Fusion Middleware ControlでSOA Webサービスのエンドポイントをテストするとき、管理サーバーで実行されているFusion Middleware Controlソフトウェアは、ロード・バランサのフロントエンドにアクセスして、エンドポイントを検証する必要があります。

証明書、アイデンティティ・ストアおよびトラスト・ストアの生成

このエンタープライズ・デプロイメント・ガイドではエンドツーエンドSSL (データベースへのアクセスを除く)が使用されるため、証明書はドメインごとのCAを使用して別の章ですでに生成されています。これらは関連するアイデンティティ・ストアにすでに追加されており、トラスト・ストアもドメインごとのCAを含めるように構成されています。提供されている様々なgenerateCertsスクリプトを使用することで、ドメイン内のWebLogic Serverで使用される様々なリスニング・アドレスの適切な証明書がこれらのストアにすでに存在することが想定されます。さらに、スクリプトgenerate_perdomainCACERTS-ohs.shが実行されると、ドメインのconfig.xml内のすべてのフロントエンド・アドレスがトラバースされ、その関連する証明書がドメインで使用されるトラスト・ストアに追加されます。これらのトラスト・ストアをドメイン内のWebLogic Serverで使用されるJavaプロパティ(-Djavax.net.ssl.trustStoreおよび-Djavax.net.ssl.trustStorePassword)に追加することで、これらのWebLogic ServerがSSL呼出しでクライアントとして機能する場合に、適切なSSLハンドシェイクが保証されます。

トラストストアへの他の外部証明書のインポート
次のステップを実行して、他のSSLエンドポイントの証明書をドメインのトラストストアに追加します。これらは、SOA EDGのアプリケーションで使用される他のWLSドメインの外部アドレスまたはフロントエンドです:
  1. ブラウザでSSLのエンドポイント・サイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。
  2. サイトから証明書を取得します。たとえば、Firefoxなどのブラウザを使用してWebサービス・サイトの証明書を取得できます。ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システム上のファイル(ファイル名site.webservice.com.crtなど)にエクスポートします。または、opensslコマンドを使用して、証明書を取得することもできます。コマンドの構文は、次のとおりです。
    
openssl s_client -connect site.webservice.com -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > $KEYSTORE_HOME/ site.webservice.com.crt
  3. keytoolを使用して、サイトの証明書をトラストストアにインポートします:

    たとえば:

    
keytool -import -file /oracle/certificates/site.webservice.com.crt -v -keystore appTrustKeyStore.pkcs12 -alias siteWS -storepass password
  4. WebLogic ServerによってアクセスされるSSLエンドポイントごとに、この手順を繰り返します。

    ノート:

    WLSサーバー・トラスト・ストアにロード・バランサ証明書を追加する必要があるのは、自己署名証明書の場合のみです。サードパーティの認証局が発行したロード・バランサ証明書の場合は、ルートの公開証明書と中間証明書をトラスト・ストアにインポートする必要があります。
Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

トラスト・ストアのパスは、ドメインが作成された章でWebLogic起動スクリプトにすでに追加されているため、追加の構成は必要ありません。SSLエンドポイントのCAや証明書が追加された新しいトラスト・ストアで既存のトラスト・ストアを置き換えるようにすれば十分です。

エンタープライズ・デプロイメントの管理用のロールの構成

1つのエンタープライズ・デプロイメント・ドメインで各製品を効果的に管理するには、どの製品が特定の管理ロールまたはグループを必要とするか、また製品固有の管理ロールをエンタープライズ・デプロイメント管理グループにどのように追加するかを理解する必要があります。

各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。

ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよび管理者グループのプロビジョニング」を参照してください。

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。

詳細な情報は、次のトピックを参照してください

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

特定の管理ロールを持つ製品のサマリー

次の表に、エンタープライズ・デプロイメント用にLDAP認可プロバイダで定義した、エンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します。

次の表の情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

製品 アプリケーション・ストライプ 割り当てられる管理ロール

Oracle Web Services Manager

wsm-pm

policy.updater

SOAインフラストラクチャ

soa-infra

SOAAdmin

Oracle Service Bus

Service_Bus_Console

MiddlewareAdministrator

エンタープライズ・スケジューラ・サービス

ESSAPP

ESSAdmin

Oracle B2B

b2bui

B2BAdmin

Oracle MFT

mftapp

MFTAdmin

Oracle MFT

mftes

MFTESAdmin
特定の管理グループを持つOracle SOA Suite製品のサマリー

表19-2には、特定の管理グループを使用する必要のあるOracle SOA Suite製品のリストを示します。

これらのコンポーネントごとに、共通エンタープライズ・デプロイメントの管理ユーザーを製品固有の管理グループに追加する必要があります。追加しなければ、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したEnterprise Manager管理ユーザーを使用して製品リソースを管理できません。

表19-2の情報と「製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

表19-2 製品固有の管理グループを持つOracle SOA Suite製品

製品 製品固有の管理グループ

Oracle Business Activity Monitoring

BAMAdministrator

Oracle Business Process Management

Administrators

Oracle Service Bus統合

IntegrationAdministrators

MFT

OracleSystemGroup

ノート:

MFTでは、集中LDAPに特定のユーザー(OracleSystemUser)を追加する必要があります。このユーザーは、OracleSystemGroupグループに属している必要があります。MFTジョブの作成および削除が適切に動作するように、ユーザー名とユーザー・グループの両方を集中LDAPに追加する必要があります。
エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

  1. 管理者のアカウント(たとえば: weblogic_soa)を使用してFusion Middleware Controlにサインインして、アプリケーションのホーム・ページに移動します。

    これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_soa)とパスワードを作成したときに作成した資格証明です。

  2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
  3. 製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。
  4. 「アプリケーション・ロールの検索」アイコン検索アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。
  5. エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。
  6. 「編集」アイコンアプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
  7. 「アプリケーション・ロールの編集」ページの「追加」アイコンアプリケーション・ロールの「追加」アイコンをクリックします。
  8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
  9. 「プリンシパル名」の「次で始まる」フィールドにグループ名(SOA Administratorsなど)を入力し、右矢印をクリックして検索を開始して、エンタープライズ・デプロイメントの管理者グループを検索します。
  10. 検索結果で管理者グループを選択し、「OK」をクリックします。
  11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。
製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザー(weblogic_soa)をグループに追加します。これにより、Enterprise Managerの管理者ユーザーを使用して製品を管理できるようになります。

  1. 以下に示すような、product_admin_group.ldifというldifファイルを作成します。
    dn: cn=product-specific_group_name, cn=groups, dc=us, dc=oracle, dc=com
displayname: product-specific_group_display_name
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=oracle,dc=com
cn: product-specific_group_name
description: Administrators Group for the Domain

    この例では、product-specific_group_nameを、表19-2で示す製品管理者グループの実際の名前と置き換えます。

    product-specific_group_display_nameを、LDAPサーバーの管理コンソールとOracle WebLogicリモート・コンソールに表示されるグループの表示名と置き換えます。

  2. ldifファイルを使用して、エンタープライズ・デプロイメントの管理者ユーザーを製品固有の管理グループに追加します。

    Oracle Unified Directoryの場合:

    OUD_INSTANCE_HOME/bin/ldapmodify -a 
                                 -D "cn=Administrator" 
                                 -X 
                                 -p 1389 
                                 -f product_admin_group.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oid.example.com 
                            -p 389 
                            -D cn="orcladmin" 
                            -w <password> 
                            -c 
                            -v 
                            -f product_admin_group.ldif

エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用

Oracle WebLogic永続ストア・フレームワークは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

たとえば、JMSサブシステムは、永続JMSメッセージおよび永続サブスクライバを格納し、JTAトランザクション・ログ(TLOG)は、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納します。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。永続ストアの高可用性は、サーバーまたはサービスの移行により提供されます。サーバーまたはサービスの移行には、WebLogicクラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

エンタープライズ・デプロイメントの場合、トランザクション・ログ(TLOG)とJMSにはJDBC永続ストアを使用することをお薦めします。

この項では、JDBCとファイル永続ストアを比較して利点を分析し、サポートされるデータベースで永続ストアを構成する手順を説明します。このガイドの様々な章に含まれる構成ウィザードのステップでは、使用するコンポーネントのJDBC永続ストアがすでに作成されていることに注意してください。カスタム・ストアの場合、またはファイル・ストアからJDBCストアに移行する場合は、次の手動ステップを使用します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

JMS永続ストアとTLOGを使用する製品およびコンポーネント

どのインストール済製品およびコンポーネントが永続ストアを利用しているかは、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションのドメイン名→「サービス」→「永続ストア」で判別できます。このリストは、ストアの名前、ストアのタイプ(FileStore/JDBC)、およびストアのターゲットを示します。リストされたMDS関連のストアは、この章の範囲外であり、ここでは検討しません。

これらのコンポーネントは、デフォルトでストアを使用します(該当する場合)。
コンポーネント/製品 JMSストア TLOGストア

B2B

はい

はい

BAM

はい

はい

BPM

はい

はい

ESS

いいえ

いいえ

MFT

はい

はい

OSB

はい

はい

SOA

はい

はい

WSM

いいえ

いいえ
JDBC永続ストアとファイル永続ストアの比較

Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。環境の永続ストア戦略を決定する前に、各アプローチのメリットとデメリットを検討してください。

ノート:

選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。

TLOGおよびJMSのJDBC永続ストアについて

TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、Oracle Data Guardを使用するとサイト間の同期が簡単になります。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。

また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の局面では、共有記憶域は依然として必要です。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポート)、デプロイメント・プラン、およびアダプタ・アーティファクト(ファイル/FTPアダプタの制御ファイルおよび処理済ファイル)でも必要です。

TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システムの保護機能はOracle Databaseによって提供される保護機能ほど優れていません。

データベース・ベースのTLOGおよびJMSストアを使用する場合のパフォーマンスへの影響の詳細は、「TLOGおよびJMS永続ストアに関するパフォーマンス上の考慮事項」を参照してください。

TLOGおよびJMS永続ストアに関するパフォーマンス上の考慮事項

トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。

トランザクション・ログとJMSストアのパフォーマンスへの影響

トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。

他方、アプリケーションがJMS集約型である場合、JMSデータベース・ストアはパフォーマンスに大きな影響を及ぼす可能性があります。たとえば、SOA Fusion Order Demo (Oracle SOA Suite環境をテストするために使用されるサンプル・アプリケーション)を使用している場合、JMSデータベース操作はより重い他の多くのSOAデータベース起動によってマスクされるため、ファイル・ベースからデータベース・ベースの永続ストアへの切替えの影響は非常に小さくなります。

パフォーマンスに影響を与える要素

カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。

  • 関与するカスタム宛先とそのタイプ

  • 永続化されるペイロード

  • SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)

上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。

  • JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)

  • JMS表のセグメント定義(索引および表レベルでのパーティション)

JMSトピックの影響

システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。OracleがJMSに対して実施したテストでは、様々なペイロード・サイズおよび様々な同時実行性での平均パフォーマンス低下率は、キューの場合は30%未満でした。トピックの場合、影響は40%を超えていました。データベース・ストアを使用するかどうかを決定する際、リカバリの観点からこれらの宛先の重要性を検討してください。

データ型およびペイロード・サイズの影響

ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。

具体的に言うと、ペイロード・サイズが約4kに達すると、SecureFilesはより多くのデータベース時間を必要とするようになります。これは、4kでは書込みが行外になるためです。約20kのペイロード・サイズで、SecureFilesデータはより効率的になり始めます。ペイロード・サイズが20kを超えると、RAWデータ型に設定されたペイロードのデータベース時間は悪化します。

SecureFilesのもう1つの利点は、500kを超えた時点からペイロードが増加してもデータベース時間が安定化し始める点です。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みは非同期で、すべてのケースで競合が同じになるためです。

ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。

同時実行性、ワーカー・スレッド、データベースのパーティション化の影響

永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。

エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用

この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用するためのガイドラインを説明します。サポートされているデータベースで永続ストアを構成するための手順も説明します。

ノート:

(構成ウィザードを使用して)このEDGで様々なコンポーネントを設定するために提供されるステップは、JDBC永続ストアですでに構成されていることに注意してください。カスタム永続ストアの場合、またはファイル・ストアからJDBCストアに再構成する場合は、次のステップを使用します(ファイルからJDBCへのメッセージの移行は、このEDGの範囲外です)。
  • TLOGおよびJMSデータ・ソースの集計に関する推奨事項
    データ・ソースの集計と接続使用状況の緩和を達成するために、JMS永続ストアとTLOG永続ストアの両方に1つの接続プールを使用します。
  • TLOGに対するJDBC永続ストアの構成のロードマップ
    次の項では、トランザクション・ログにデータベース・ベースの永続ストアを構成する方法について説明します。
  • JMSに対するJDBC永続ストアの構成のロードマップ
    次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。
  • TLOG用のユーザーおよび表領域の作成
    トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。
  • JMS用のユーザーおよび表領域の作成
    JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。
  • TLOGおよびJMSストアのGridLinkデータ・ソースの作成
    JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
  • 管理対象サーバーへのTLOG JDBCストアの割当て
    データ・ソース集計を達成しようとしている場合は、TLOG永続ストアのために<PREFIX>_WLS表領域とWLSRuntimeSchemaDataSourceを再使用します。別の方法では、データベースでその表領域とユーザーを必ず作成し、必要な各管理対象サーバーにTLOGストアを割り当てる前にデータ・ソースを作成してあることを確認します。
  • JDBC JMSストアの作成
    データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、WebLogicリモート・コンソールを使用してストアを作成できます。
  • JMSサーバーへのJMS JDBCストアの割当て
    データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。
  • JMS JDBCストアに必要な表の作成
    JMSにJDBC永続ストアを使用する最後のステップは、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

親トピック: エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用

TLOGおよびJMSデータ・ソースの集計に関する推奨事項

データ・ソースの集計と接続使用状況の削減を達成するために、JMS永続ストアとTLOG永続ストアの両方に1つの接続プールを使用します。

ワークロードが高くないTLOGおよびJMS永続ストアの場合のようにWLSRuntimeSchemaDataSourceを再利用することをお薦めします。また、WLSRuntimeSchemaDataSourceプール・サイズを増やすことも検討してください。データ・ソースを再利用すると、強制的に同じスキーマと表領域が使用されるため、PREFIX_WLS表領域のPREFIX_WLS_RUNTIMEスキーマが、TLOGメッセージとJMSメッセージのどちらにも使用されます。

データ・ソースでストレス(たとえば、JMSアクティビティ量が大きい)と競合が大きいと、安定性とパフォーマンスの点で問題が発生する場合があります。たとえば:

  • データ・ソースで競合が大きいと、プールで接続が利用できずJMSメッセージを永続させられない場合に、連続ストアでエラーが発生することがあります。

  • データ・ソースで競合が大きいと、プールで接続が利用できずトランザクション・ログを更新できない場合に、トランザクションで問題が発生することがあります。

そのような場合は、各TLOGおよびストアに別々のデータ・ソース、各種のストアに別々のデータ・ソースを使用してください。PREFIX_WLS_RUNTIMEスキーマは引き続き使用できますが、競合の問題を避けるために、同じスキーマに別々のカスタム・データ・ソースを構成してください。

TLOGに対するJDBC永続ストアの構成のロードマップ

ここでは、トランザクション・ログ用にデータベースベースの永続ストアを構成する方法を説明します。

  1. TLOG用のユーザーおよび表領域の作成

  2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

  3. 管理対象サーバーへのTLOG JDBCストアの割当て

ノート:

ステップ1と2はオプションです。データ・ソースの集計と接続使用状況の緩和を達成するために、「TLOGおよびJMSデータ・ソースの集計に関する推奨事項」での説明に従って、PREFIX_WLS表領域とWLSRuntimeSchemaDataSourceを再利用します。

JMSに対するJDBC永続ストアの構成のロードマップ

次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。

  1. JMS用のユーザーおよび表領域の作成

  2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

  3. JDBC JMSストアの作成

  4. JMSサーバーへのJMS JDBCストアの割当て

  5. JMS JDBCストアに必要な表の作成

ノート:

ステップ1と2はオプションです。データ・ソースの集計と接続使用状況の緩和を達成するために、「TLOGおよびJMSデータ・ソースの集計に関する推奨事項」での説明に従って、PREFIX_WLS表領域とWLSRuntimeSchemaDataSourceを再利用します。

TLOG用のユーザーおよび表領域の作成

トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

  1. tlogsという表領域を作成します。

    たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。 

    SQL> create tablespace tlogs
        logging datafile 'path-to-data-file-or-+asmvolume'
        size 32m autoextend on next 32m maxsize 2048m extent management local;
  2. TLOGSという名前のユーザーを作成し、そのユーザーにtlogs表領域を割り当てます。

    たとえば:

    SQL> create user TLOGS identified by password;

SQL> grant create table to TLOGS;

SQL> grant create session to TLOGS;

SQL> alter user TLOGS default tablespace tlogs;

SQL> alter user TLOGS quota unlimited on tlogs;
JMS用のユーザーおよび表領域の作成

JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

  1. jmsという表領域を作成します。

    たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。 

    SQL> create tablespace jms
        logging datafile 'path-to-data-file-or-+asmvolume'
        size 32m autoextend on next 32m maxsize 2048m extent management local;
  2. JMSという名前のユーザーを作成し、そのユーザーにjms表領域を割り当てます。

    たとえば:

    SQL> create user JMS identified by password;

SQL> grant create table to JMS;

SQL> grant create session to JMS;

SQL> alter user JMS default tablespace jms;

SQL> alter user JMS quota unlimited on jms;
TLOGおよびJMSストアのGridLinkデータ・ソースの作成

JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

エンタープライズ・デプロイメントでは、TLOGおよびJMSストアにGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成するには:

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「サービス」を開き、「データ・ソース」を選択します。
  4. 「データ・ソースのサマリー」ページで、「新規」をクリックし、「GridLinkデータ・ソース」を選択します。次を入力します:

    表19-3 GridLinkデータ・ソースのプロパティ

    プロパティ 説明
    名前 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingです。
    JNDI名 JNDIの名前を入力します。たとえば、TLOGストアの場合、jdbc/tlogsと入力します。JMSストアの場合、jdbc/jmsと入力します。
    ターゲット 永続ストアを使用しているクラスタを選択し、「選択済」に移動します。
    データ・ソース・タイプ 「GridLinkデータ・ソース」を選択します。
    データベース・ドライバ 「Oracle's Driver (Thin) for GridLink Connections Versions: Any」を選択します。
    グローバル・トランザクション・プロトコル 「なし」を選択します。
    リスナー RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。たとえば、db-scan.example.com:1521です。
    サービス名 データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、soaedg.example.comです。
    データベース・ユーザー名 ユーザー名を入力します。たとえば、TLOGストアの場合、TLOGSと入力します。JMS永続ストアの場合、JMSと入力します。
    パスワード データベースでユーザーを作成した際に使用したパスワードを入力します。
    プロトコル デフォルト値(TCP)のままにします。
    FANの有効化 このプロパティは選択する必要があります。
    ONSノード このフィールドは空のままにできます。ONSノード・リストは、データベースが12.2以上のバージョンであれば自動的に取得されます。
    ONSウォレットとパスワード このフィールドは空のままにできます。
    構成のテスト このオプションは有効にする必要があります。
  5. 「作成」をクリックします。
  6. ショッピング・カートの変更をコミットします。
  7. ステップ4からステップ6を繰り返し、JMSファイル・ストアのGridLinkデータ・ソースを作成します。
管理対象サーバーへのTLOG JDBCストアの割当て

データ・ソース集計を達成しようとしている場合は、TLOG永続ストアのために<PREFIX>_WLS表領域とWLSRuntimeSchemaDataSourceを再使用します。別の方法では、データベースでその表領域とユーザーを必ず作成し、必要な各管理対象サーバーにTLOGストアを割り当てる前にデータ・ソースを作成してあることを確認します。

  1. Oracle WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」で、「環境」→「サーバー」に移動します。
  3. 管理対象サーバーの名前をクリックします。
  4. 「サービス」→「JTA」タブを選択します。
  5. 「JDBCのトランザクション・ログ・ストア」を有効にします。
  6. 「データ・ソース」メニューで、WLSSchemaRuntimeDatasourceを選択し、データ・ソースの集計を実行します。TLOGには、<PREFIX>_WLS表領域が使用されます。
  7. 「トランザクション・ログ接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。
  8. 「保存」をクリックします。
  9. 追加の管理対象サーバーごとにステップ2からステップ7を繰り返します。
  10. これらの変更をアクティブ化するには、ショッピング・カートの変更をコミットします。
JDBC JMSストアの作成

データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、WebLogicリモート・コンソールを使用してストアを作成できます。

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「サービス」を開き、「JDBCストア」を選択します。
  4. 「新規」をクリックします。
  5. 永続ストアを使用している、永続化するJMSサーバーに容易に結び付けられる永続ストア名を入力します。

    ノート:

    データ・ソース集計を完了するには、WLSRuntimeSchemaDataSourceを選択します。JMS永続ストアには、<PREFIX>_WLS表領域が使用されます。
  6. JMSサーバーが属する移行可能ターゲットにストアをターゲット指定します。
  7. クラスタ内の追加のJMSサーバーごとにステップ3からステップ7を繰り返します。
  8. ショッピング・カートの変更をコミットします。
JMSサーバーへのJMS JDBCストアの割当て

データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。

JMS永続ストアをJMSサーバーに割り当てるには:
  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「サービス」→「メッセージング」→「JMSサーバー」を開きます。
  4. 永続ストアを使用するJMSサーバーの名前をクリックします。
  5. 「永続ストア」プロパティで、作成したJMS永続ストアを選択します。
  6. 「保存」をクリックします。
  7. クラスタ内の追加のJMSサーバーごとにステップ3からステップ6を繰り返します。
  8. これらの変更をアクティブ化するには、ショッピング・カートの変更をコミットします。
JMS JDBCストアに必要な表の作成

JMSにJDBC永続ストアを使用する最後のステップは、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

  1. 「TLOGおよびJMS永続ストアに関するパフォーマンス上の考慮事項」の情報を確認し、現在の環境に適切な表機能を決定します。

    このリリースで提供されるOracle DBスキーマ定義は3つあり、前のステップで確認用に抽出されています。基本定義には、索引のためのパーティションのないRAWデータ型が含まれます。2番目のものはBLOBデータ型を使用し、3番目のものはBLOBデータ型とセキュア・ファイルを使用します。

  2. 共有記憶域上にカスタムDDLファイル用として、ドメイン固有の適切に名前付けされたフォルダ構造を作成します。すべてのサーバーで使用できるように、ORACLE_RUNTIME共有ボリュームをお薦めします。

    例:

    mkdir -p ORACLE_RUNTIME/domain_name/ddl
  3. 要件分析に基づいて新しい共有ddlフォルダにjms_custom.ddlファイルを作成します。
    たとえば、セキュア・ファイルとハッシュ・パーティション化の両方を使用する最適化されたスキーマ定義を実装するには、次の内容を含むjms_custom.ddlファイルを作成します。 
    CREATE TABLE $TABLE (
  id     int  not null,
  type   int  not null,
  handle int  not null,
  record blob not null,
PRIMARY KEY (ID) USING INDEX GLOBAL PARTITION BY HASH (ID) PARTITIONS 8)
LOB (RECORD) STORE AS SECUREFILE (ENABLE STORAGE IN ROW);

    この例を、索引パーティションなしでRAWデータ型が使用される、JMSストアのデフォルトのスキーマ定義と比較することができます。

    パーティションの数は2の累乗にする必要があります。これにより、各パーティションがほぼ同じサイズになります。推奨するパーティション数は、表または索引サイズの増大をどのように予期するかによって変わります。データベース管理者(DBA)に一定期間における表の増加率を分析させて、それに応じて表を調整する必要があります。Oracle Database VLDBおよびパーティショニング・ガイドのパーティション化の概念に関する項を参照してください。

  4. リモート・コンソールを使用して、前に作成した既存のJDBCストアを編集します。JMSデータのために使用される表を作成します:
    1. WebLogicリモート・コンソールにログインします。
    2. 「ツリーの編集」に移動します。
    3. 構造ツリーで、「サービス」を開き、「JDBCストア」を選択します。
    4. 前に作成した永続ストアをクリックします。
    5. 「拡張フィールドの表示」をクリックします。
    6. 「詳細」オプションの下で、「DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlと入力します。
    7. 「保存」をクリックします。
    8. これらの変更をアクティブ化するには、ショッピング・カートの変更をコミットします。
  5. 管理対象サーバーを再起動します。

WebサービスのJDBC永続ストアについて

デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。

デフォルトWebサービス永続ストアは、次の拡張機能で使用されます。

  • 信頼性のあるメッセージング

  • 接続

  • セキュア通信

  • メッセージ・バッファリング

デフォルト・ストアではなく、JDBC永続ストアをWebLogic ServerのWebサービスで使用することもできます。Webサービスの永続性の詳細は、Webサービスの永続性の管理を参照してください。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

RACおよびGridlinkデータソースを使用する場合の構成のベスト・プラクティス

Oracle RACデータベースの使用時は、GridLinkデータ・ソースを使用することをお薦めします。エンタープライズ・デプロイメント・ガイドで説明されているステップに従うと、データソースはGridLinkとして構成されます。

GridLinkデータソースは、Oracle Databaseクラスタ内のノード間で動的ロード・バランシングおよびフェイルオーバーを提供し、ノードが追加または削除されたときにRACクラスタから通知を受信します。GridLinkデータソースの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のActive GridLinkデータ・ソースの使用に関する項を参照してください。

GridLinkを使用してRACデータベースに接続する場合のベスト・プラクティスのサマリーを次に示します:

  • デフォルトのデータベース・サービスとは別のデータベース・サービス(srvctlで定義)の使用

    RACデータベースから通知を受信して処理するには、GridLinkがデフォルトのデータベース・サービスではなく、(srvctlで定義された)データベース・サービスに接続する必要があります。これらのサービスは、データベース・クラスタ内のリソースのステータスを監視し、ステータスが変更されたときに通知を生成します。データベース・サービスはエンタープライズ・デプロイメント・ガイドで使用され、「データベース・サービスの作成」の説明に従って作成および構成されます。

  • データソースでの長い形式のデータベース接続文字列の使用

    Gridlinkデータソースを使用する場合は、長い形式のデータベース接続文字列を使用する必要があります。構成ウィザードでは長い形式の文字列は設定されず、かわりに短い形式が設定されます。後で手動で変更して長い形式を設定できます。データソースを更新するには:

    1. WebLogic Serverコンソールに接続し、「ドメイン構造」→「サービス」→「データソース」に移動します。
    2. データソースを選択し、「構成」タブ、「接続プール」タブの順にクリックします。
    3. JDBC URL内で、URLを jdbc:oracle:thin:[SCAN_VIP]:[SCAN_PORT]/[SERVICE_NAME]からjdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=[SCAN_VIP])(PORT=[SCAN_PORT])))(CONNECT_DATA=(SERVICE_NAME=[SERVICE_NAME])))に変更します
      たとえば:
      jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan-address)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)))
  • 自動ONSの使用

    ONS接続リストは、データベースからドライバに自動的に提供されます。データソース構成では、「ONSノード」リストを空のままにできます。

  • 予約時に接続をテスト

    データソースで「予約時に接続をテスト」が選択されていることを確認します。

    RACインスタンスが使用できなくなったときにGridLinkデータソースがFANイベントを受信しますが、ベスト・プラクティスは、データソースで「予約時に接続をテスト」を有効にし、アプリケーションに返される接続が正常であることを確認することです。

  • アイドル・プール接続を信頼する秒数

    テストを最大限に効率化するために、「アイドル・プール接続を信頼する秒数」を0に設定して、接続が常に検証されるようにすることもできます。この値をゼロに設定すると、アプリケーションに返されるすべての接続がテストされます。このパラメータが10に設定されている場合、前のテストの結果は10秒間有効になり、10秒経過する前に接続が再利用された場合、結果は引き続き有効になります。

  • テスト頻度

    データソースの「テスト頻度」パラメータ値が0でないことを確認します。未使用の接続をテストするときに、次のテストが試行されるまでWebLogic Serverインスタンスが待機する秒数です。通常、デフォルト値の120で十分です。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

接続文字列でのTNS別名の使用

データソースのJDBC接続プールで長いデータベース接続文字列を指定するかわりに、別名を作成してURL情報をマップできます。接続文字列情報は、関連する別名とともにtnsnames.oraファイルに格納されます。この別名は、接続プールの接続文字列で使用されます。

次に、TNS別名を使用した接続文字列の例を示します。

jdbc:oracle:thin:@soaedg_alias

tnsnames.oraファイルには、次の詳細が含まれます。 


soaedg_alias =
        (DESCRIPTION=
        (ADDRESS_LIST=
            (LOAD_BALANCE=ON)
            (ADDRESS=(PROTOCOL=TCP)(HOST=soaedgdb-scan)(PORT=1521)))
            (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
        )

特定のtnsnames.oraファイルを指すように、データソース構成でoracle.net.tns_adminプロパティを指定する必要があります。たとえば、<property><name>oracle.net.tns_admin</name><value>/u01/oracle/config/domains/fmw1412edg/config/tnsadmin</value></property></properties>です

これは、JDBC URLの最大可用性およびエンタープライズ・デプロイメントの推奨アプローチです。これにより、JDBC構成を簡素化し、障害保護シナリオでのDB構成のエイリアス化を容易にして、データベース接続の変更をより動的にします。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のDB接続文字列のかわりにTNS別名を使用する方法に関する項を参照してください。

Oracle Fusion Middleware 14.1.2では、新しいタイプのデプロイメント・モジュールを使用して、データベース接続に関連付けられたtnsnames.oraファイル、ウォレット・ファイル、キーストア・ファイルおよびトラストストア・ファイルを管理できます。これらはDBClientDataモジュールと呼ばれます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のDBClientDataモジュールの内容に関する項を参照してください。このEDGでは、DBClientDataタイプのモジュールを使用して、データベース・クライアント情報を管理します。ただし、ウォレットおよびSSL構成はデータベースへのアクセスには使用されないため、DBClientDataモジュールには適切なtnsnames.oraのみが含まれます。

FMWおよびWLSスキーマで使用される様々なデータソースでTNS別名を使用するには、次のステップが必要です:

  1. 接続プールで使用される関連する別名およびマッピングURLを含むtnsnames.oraを作成します。既存のデータソース構成ファイルの1つから接続文字列をコピーします。たとえば、

    ノート:

    これは、短いJDBC URLを使用する例です。 
    
[oracle@soahost1~]$  grep url  /u01/oracle/config/domains/soaedgdomain/config/jdbc/opss-datasource-jdbc.xml
    <url>jdbc:oracle:thin:@drdbrac12a-scan.dbsubnet.vcnlon80.oraclevcn.com:1521/soaedg.example.com</url>
[oracle@soahost1~]$

    接続文字列の情報を使用して、長いURLエントリをtnsnames.oraファイルに追加します。接続を識別する別名を使用します。tsnnames.oraをDBCLientモジュールとしてデプロイするには、デプロイメント・モジュールの場所がドメイン構成ディレクトリの2レベル下にある必要があります(それがWLS管理サーバー・ノードに存在する場合)。このファイルは、WebLogicリモート・コンソールを実行するノードに作成することや、アプリケーションのearまたはwarファイルとしてアップロードすることもできます。 

    
[oracle@soahost1~]$  cat /u01/oracle/config/tnsadmin/tnsnames.ora

soaedg_alias =
        (DESCRIPTION=
        (ADDRESS_LIST=
            (LOAD_BALANCE=ON)
            (ADDRESS=(PROTOCOL=TCP)(HOST= drdbrac12a-scan.dbsubnet.vcnlon80.oraclevcn.com)(PORT=1521)))
            (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
        )

  2. tnsnames.oraを含むディレクトリをDBClientDataモジュールとしてデプロイします。

    1. WebLogicリモート・コンソールでドメイン・プロバイダにアクセスします。

    2. 「ツリーの編集」をクリックします。

    3. 「環境」→「デプロイメント」→「データベース・クライアント・データ・ディレクトリ」をクリックします。

    4. 「新規」をクリックします。

    5. dbclientディレクトリ・デプロイメントの名前を入力します。たとえば、dbclientdata_modulenameです。

      tnsnames.oraファイルを含むディレクトリがローカル・コンピュータに存在する場合は、「アップロード」チェック・ボックスの選択を解除します。

    6. 「作成」をクリックします。

    7. 「保存」をクリックします。

      画面の右上にあるカートが、内部に黄色いバッグが入った状態で表示されます。

    8. 「カート」アイコンをクリックし、「変更のコミット」を選択します。

      これにより、ドメイン・ディレクトリ/u01/oracle/config/domains/soaedgdomain/config/ dbclientdata/dbclientdata_modulenameの下にtnsnames/dbclientモジュールが作成されます。

      WLSTのdeployコマンドを使用して、データベース・クライアント・モジュールのデプロイメントを実行することもできます。

  3. 明示的なURLのかわりに別名を使用するように、異なるデータソースおよびfmwconfigファイルを更新します。

    ノート:

    TNS別名を使用するようにデータソースを更新するには、データソース構成で、JDBC URLにtsnames.oraファイルへのポインタと別名自体の両方を含める必要があります。

    次のステップを実行して、tnsnames.oraファイルへのポインタを含め、データソース・プロパティにoracle.net.tns_adminプロパティを含める必要があります。

    1. WebLogicリモート・コンソールでドメイン・プロバイダにアクセスします。

    2. 「ツリーの編集」をクリックします。

    3. 「サービス」→「データソース」→「Datasource_name」をクリックします。

    4. 左側のナビゲーション・ツリーで、正確なデータソースとして「プロパティ」を選択します。

    5. 「新規」をクリックします。

    6. プロパティ名としてoracle.net.tns_adminと入力します。

    7. 「作成」をクリックします。

    8. プロパティの詳細が表示された次の画面で、値としてdbclientdata_modulename (前述の例では/u01/oracle/config/domains/soaedgdomain/config/ dbclientdata/dbclientdata_modulename)のディレクトリを入力します。

    9. 「保存」をクリックします。

      画面の右上にあるカートが、内部に黄色いバッグが入った状態で表示されます。

    10. 左側のナビゲーション・ツリーで、データソース名をクリックします。

    11. 「接続プール」タブを選択します。

    12. 「URL」で、次に示すようにURLを別名構文に置き換えます:

      jdbc:oracle:thin:@soaedg_alias

    13. 「保存」をクリックします。

    14. 「カート」アイコンをクリックし、「変更のコミット」を選択します。

      データソース構成ファイルを確認すると、<jdbc-driver-params> <properties>エントリの下に次の内容が反映されています: 

      
<property>
<name>oracle.net.tns_admin</name>
<value>/u01/oracle/config/domains/soaedgdomain/config/dbclientdata/dbclientdata_modulename</value>
</property>

      データソース構成ファイルには、次に示すようにJDBC URLが<jdbc-driver-params>の下に反映されます:

      <url>jdbc:oracle:thin:@soaedg_alias</url>

  4. TNS別名を使用するようにFMW JPS構成を更新するには、domain_path/config/fmwconfig/jps-config.xmlおよびdomain_path/config/fmwconfig/jps-config-jse.xmlファイルを更新し、tsnames.oraファイルへのポインタと別名自体の両方をJDBC URLに含める必要があります。これにより、DBのpropertySet内の情報が、更新されたURLおよびtnsadminポインタに置き換えられます。 

    
<property name="oracle.net.tns_admin" value="/u01/oracle/config/domains/soaedgdomain/config/dbclientdata/dbclientdata_modulename "/>
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg_alias "/>

すべての変更が適用されるように管理サーバーを再起動します。

または、ステップ1、2、3、4のかわりにhttps://github.com/oracle-samples/maa/tree/main/1412EDG/fmw1412_change_to_tns_alias.shスクリプトを使用して、対応するDBClientDataモジュールをデプロイし、JDBCおよびJPS構成内のすべてのURLを関連する別名に置き換えることができます。

ただし、スクリプトの使用は、すべてのドメイン拡張が完了し、必要なすべてのデータソースがドメイン構成に存在する場合にのみ推奨されます。これは、既存のtnsadminが構成ファイルにすでに存在する場合に終了するようにスクリプトが構成されているためです。この動作は、ドメイン内の他のDBClientモジュールとの競合を回避するために意図的に行われます。

推奨されるアプローチは、機能的なニーズを満たすようにドメインを構成することです(SOA、OSB、SOA+OSB、SOA+BPMNなど。「Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて」の章の「プライマリOracle SOA Suiteエンタープライズ・トポロジの実装のフロー・チャートとロードマップ」を参照してください)。ドメインが完了して機能するようになったら、スクリプトを使用してTNS別名を変更します。正しい実行のために、スクリプトのヘッダーにある手順を確認してください。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

エンタープライズ・デプロイメントのバックアップとリカバリの実行

Oracle SOA Suiteエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

ノート:

この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームはアプリケーション・サーバーからでなく、NASファイラから直接バックアップおよびリカバリしてください。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

表19-4は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表19-4 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

SOAHOST1およびSOAHOST2 (またはNASファイラ)

アプリケーション層

インストール関連ファイル

WEBHOST1、WEHOST2および共有記憶域

なし

表19-5は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表19-5 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ ホスト 層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

SOAHOST1 (またはNASファイラ)

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

SOAHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

ホスト当たり

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

SOAHOST1 (またはNASファイラ)

アプリケーション層

OHS/OTD構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

オンライン・ドメインのランタイム・アーティファクトのバックアップ/リカバリの例

この項では、WebLogicドメイン・アーティファクトのバックアップを実装する手順の例を説明します。この方法は、ドメインを拡張して新しいコンポーネントを追加する前など、EDG構成プロセス中に使用できます。

この例には、次の機能があります:

  • この例では、アプリケーション層ランタイム・アーティファクトがバックアップ/リカバリされます:
    アーティファクト ホスト 層

    管理サーバーのドメイン・ホーム(ASERVER_HOME)

    SOAHOST1 (またはNASファイラ)

    アプリケーション層

    アプリケーション・ホーム(APPLICATION_HOME)

    SOAHOST1 (またはNASファイラ)

    アプリケーション層

    デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

    SOAHOST1 (またはNASファイラ)

    アプリケーション層

    ランタイム・アーティファクト(アダプタ制御ファイル) (ORACLE_RUNTIME)

    SOAHOST1 (またはNASファイラ)

    アプリケーション層

    スクリプトとカスタマイズ

    ホスト当たり

    アプリケーション層
  • このバックアップ手順は、ドメインに対して大規模な構成変更(ドメイン拡張)が行われる場合に適しています。何か問題が発生した場合、または間違った選択を行った場合は、ドメイン構成を以前の状態にリストアできます。

    このサンプル・プロシージャではデータベースのバックアップ/リストアは必須ではありませんが、データベースをバックアップ/リストアするステップはオプションとして含まれています。

    アーティファクト ホスト 層

    Oracle RACデータベース(オプション)

    Oracle RACデータベース(オプション)

    データ層
  • この例では、オペレーティング・システム・ツールを使用します。この項で示すランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームのバックアップおよびリカバリは、アプリケーション・サーバーからではなくNASファイラから直接実行します。
  • 管理対象サーバーはバックアップ中に稼働しています。MSERVER_HOMEはバックアップされず、後でpack/unpackプロシージャを使用してMSERVER_HOMEをリカバリします。したがって、管理対象サーバーのロック・ファイルはバックアップに含まれません。
  • .lokファイルがバックアップから除外されている場合は、バックアップ中にAdminServerを実行できます。バックアップの矛盾を防ぐために、バックアップが完了するまで構成を変更しないでください。WebLogic Serverドメインが変更されないようにするには、WebLogic Server構成をロックします。

    ノート:

    次を除く:
    • AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok
    • AdminServer/tmp/AdminServer.lok
ドメイン・ランタイム・アーティファクトのバックアップ

ドメイン・ランタイム・アーティファクトをバックアップするには、次のステップを実行します:

  1. ユーザーoracleでSOAHOST1にログインし、次の変数を定義してエクスポートします:
    変数 値の例 説明

    BAK_TAG

    BEFORE_BPM

    バックアップ・ファイルおよびデータベース・リストア・ポイントの名前で使用される説明タグ。

    BAK_DIR

    /backups

    		 バックアップ・ファイルが格納されるホスト・フォルダ。

    DOMAIN_NAME

    soaedg_domain

    ドメイン名
    たとえば:
    export BAK_TAG=BEFORE_BPM
export DOMAIN_NAME=soaedg_domain
export BAK_DIR=/backups
  2. 次のドメイン変数にドメインの値が設定されていることを確認します:
    変数 値の例

    ASERVER_HOME

    /u01/oracle/config/domains/soaedg_domain

    DEPLOY_PLAN_HOME

    /u01/oracle/config/dp

    APPLICATION_HOME

    /u01/oracle/config/applications/soaedg_domain

    ORACLE_RUNTIME

    /u01/oracle/runtime

    表7-2を参照してください。

  3. バックアップを作成する前に、ドメイン構成をロックして、編集セッション中に他のアカウントが変更を行わないようにします。Fusion Middleware Controlからドメイン構成をロックするには:
    1. https://admin.example.com:445/emにログインします。
    2. Fusion Middleware Controlの上部にあるチェンジ・センターを探します。
    3. 「変更」メニューから、「ロックして編集」を選択してドメインの構成編集をロックします。

    ノート:

    バックアップの矛盾を防ぐために、バックアップが完了するまで構成を変更しないでください。
  4. SOAHOST1にログインし、バックアップの前にログおよびバックアップ・アプリケーションをクリーンします。
    find ${ASERVER_HOME}/servers/AdminServer/logs -type f -name "*.out0*" ! -size 0c -print -exec rm -f {} \+
find ${ASERVER_HOME}/servers/AdminServer/logs -type f -name "*.log0*" ! -size 0c -print -exec rm -f {} \+
find ${APPLICATION_HOME} -type f -name "*.bak*" -print -exec rm -f {} \;
  5. tarを使用して、各アーティファクトのバックアップを実行します:
    tar -cvzf  ${BAK_DIR}/backup_aserver_home_${DOMAIN_NAME}_${BAK_TAG}.tgz   ${ASERVER_HOME} --exclude ".lok" 

tar -cvzf ${BAK_DIR}/backup_dp_home_${DOMAIN_NAME}_${BAK_TAG}.tgz    ${DEPLOY_PLAN_HOME}/${DOMAIN_NAME} 

tar -cvzf ${BAK_DIR}/backup_app_home_${DOMAIN_NAME}_${BAK_TAG}.tgz   ${APPLICATION_HOME}  

tar -cvzf ${BAK_DIR}/backup_runtime_${DOMAIN_NAME}_${BAK_TAG}.tgz         ${ORACLE_RUNTIME}/${DOMAIN_NAME} 

ls --format=single-column ${BAK_DIR}/backup_aserver_*.tgz
ls --format=single-column ${BAK_DIR}/backup_dp_*.tgz
ls --format=single-column ${BAK_DIR}/backup_app_*.tgz
ls --format=single-column ${BAK_DIR}/backup_runtime_*.tgz
  6. ドメイン・ロックを解除します。
    1. https://admin.example.com:445/emにログインします。
    2. Fusion Middleware Controlの上部にあるチェンジ・センターを探します。
    3. 「変更」メニューから、「構成の解放」を選択してドメインの構成編集を解放します。
  7. 必要に応じて、スクリプトおよびカスタマイズをバックアップします。
  8. (オプション)データベースにログインし、フラッシュバック・データベースのリストア・ポイントを作成します:

    ノート:

    この例では、データベース・リカバリにフラッシュ・データベース・テクノロジを使用します。フラッシュバックの詳細は、データベースのバージョンのドキュメントを確認してください。
    1. フラッシュバック保証付きチェックポイントを作成します。
      sqlplus / as sysdba
SQL> create restore point BEFORE_BPM guarantee flashback database;
SQL> alter system switch logfile;
    2. 確認します。
      SQL> set linesize 300
SQL> column name format a30
SQL> column time format a32
SQL> column storage_size format 999999999999
SQL> SELECT name, guarantee_flashback_database, time, storage_size FROM v$restore_point ORDER BY time;

Example:
NAME                           GUA TIME                              STORAGE_SIZE
------------------------------ --- -------------------------------- -------------
SOAEDG_BEFORE_BPM              YES 12-MAY-17 03.29.28.000000000 AM     8589934592
exit
ドメイン・ランタイム・アーティファクトのリストア
バックアップが作成された時点までドメインをリカバリするには、次のステップに従います:
  1. oracleユーザーを使用してSOAHOST1にログインします。
  2. ドメイン内のすべてのサーバー(AdminServerを含む)を停止します。
    ${ORACLE_COMMON_HOME}/common/bin/wlst.sh
connect('<weblogic_admin_username>','<password>','t3://adminvhn:7001'))

shutdown('OSB_Cluster', 'Cluster', force='true')
shutdown('ESS_Cluster', 'Cluster', force='true')
shutdown('BAM_Cluster','Cluster', force='true')
shutdown('MFT_Cluster','Cluster', force='true')
shutdown('SOA_Cluster','Cluster', force='true')
shutdown('WSM-PM_Cluster','Cluster', force='true')

state('SOA_Cluster', 'Cluster')
state('OSB_Cluster', 'Cluster')
state('ESS_Cluster', 'Cluster')
state('BAM_Cluster', 'Cluster')
state('MFT_Cluster', 'Cluster')
state('WSM-PM_Cluster' , 'Cluster')

shutdown('AdminServer', force='true', block='true')
  3. 次のドメイン変数にドメインの値が設定されていることを確認します:
    変数 値の例

    ASERVER_HOME

    /u01/oracle/config/domains/soaedg_domain

    DEPLOY_PLAN_HOME

    /u01/oracle/config/dp

    APPLICATION_HOME

    /u01/oracle/config/applications/soaedg_domain

    ORACLE_RUNTIME

    /u01/oracle/runtime
  4. 名前を変更して現在のフォルダを削除します。これらのフォルダは、リカバリしたドメインを検証した後、プロセスの最後に完全に削除できます。
    1. SOAHOST1で:
      mv  ${ASERVER_HOME}  ${ASERVER_HOME}_DELETE
mv  ${DEPLOY_PLAN_HOME}/${DOMAIN_NAME}  ${DEPLOY_PLAN_HOME}/${DOMAIN_NAME}_DELETE
mv  ${APPLICATION_HOME}   ${APPLICATION_HOME}_DELETE
mv  ${ORACLE_RUNTIME}/${DOMAIN_NAME} ${ORACLE_RUNTIME}/${DOMAIN_NAME}_DELETE
    2. 各SOAHOSTNで:
      mv   ${MSERVER_HOME}  ${MSERVER_HOME}_DELETE
  5. バックアップ・フォルダでバックアップを検索して特定します。リカバリするバックアップの正しい値を使用して、次の変数を定義およびエクスポートします:
    変数 値の例 説明

    BAK_TAG

    BEFORE_BPM

    バックアップ・ファイルおよびデータベース・リストア・ポイントの名前で使用される説明タグ。

    BAK_DIR

    /backups

    		 バックアップ・ファイルが格納されるホスト・フォルダ。

    DOMAIN_NAME

    soaedg_domain

    ドメイン名
    たとえば:
    export BAK_TAG=BEFORE_BPM
export DOMAIN_NAME=soaedg_domain
export BAK_DIR=/backups
  6. ファイルを抽出して、ファイルのリカバリを実行します。

    ノート:

    TARファイルは/で始まる構造を再作成するため、/フォルダに移動する必要があります。 
    cd  /
tar -xzvf ${BAK_DIR}/backup_aserver_home_${DOMAIN_NAME}_${BAK_TAG}.tgz   
tar -xzvf ${BAK_DIR}/backup_dp_home_${DOMAIN_NAME}_${BAK_TAG}.tgz    
tar -xzvf ${BAK_DIR}/backup_app_home_${DOMAIN_NAME}_${BAK_TAG}.tgz   
tar -xzvf ${BAK_DIR}/backup_runtime_${DOMAIN_NAME}_${BAK_TAG}.tgz
  7. (オプション)データベースをフラッシュバック・リカバリ・ポイントにリカバリする必要がある場合は、次のステップを実行します:
    1. oracleユーザーでDBHOSTにログインし、データベースを停止します:
      srvctl stop database -database soaedgdb
    2. データベースにログインし、リストア・ポイントにデータベースをフラッシュバックします:
      sqlplus / as sysdbaSQL>
          startup mountSQL>
          FLASHBACK DATABASE TO RESTORE POINT BEFORE_BPM;
    Flashback complete.
    3. 次のコマンドでデータベースを起動します:
      SQL> ALTER DATABASE OPEN RESETLOGS;
  8. AdminServerを起動します:
    ${ORACLE_COMMON_HOME}/common/bin/wlst.sh
wls:/offline> nmConnect('nodemanager','password','ADMINVHN','5556', 'domain_name','ASERVER_HOME','PLAIN')
Connecting to Node Manager ...
Successfully Connected to Node Manager.
wls:/nm/domain_name > nmStart('AdminServer')
  9. 管理対象サーバーにドメインを伝播します。
    1. SOAHOST1にサインインし、次のようにpackコマンドを実行してテンプレートを作成します:
      cd ${ORACLE_COMMON_HOME}/common/bin
./pack.sh -managed=true 
          -domain=ASERVER_HOME \ 
          -template=/full_path/recover_domain.jar \ 
          -template_name=recover_domain_template \
          -log_priority=DEBUG \ 
          -log=/tmp/pack.log
      • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。
      • /full_path/を、ドメイン・テンプレートJARファイルを作成する完全なパスで置き換えます。
      • recover_domain.jarは、作成するJARファイルの名前の例です。
      • recover_domain_templateは、作成するJARファイルの名前の例です。
    2. 次のように、すべてのSOAHOSTでunpackコマンドを実行します:
      cd $ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/recover_domain.jar
            -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME \
      • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。
      • /full_path/ recover_domain.jarを、packコマンドを実行して共有ストレージ・デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。
  10. 必要に応じて、カスタマイズをリカバリ/実行します。
  11. サーバーを起動し、ドメインを確認します。
  12. すべて正しいことを確認した後、以前に名前を変更したフォルダを削除できます:
    1. SHOAHOST1で:
      rm –rf   ${ASERVER_HOME}_DELETE
rm –rf   ${KEYSTORE_HOME}_DELETE
rm –rf   ${DEPLOY_PLAN_HOME}/${DOMAIN_NAME}_DELETE
rm –rf   ${APPLICATION_HOME}_DELETE
rm –rf   ${ORACLE_RUNTIME}/${DOMAIN_NAME}_DELETE
    2. 各SOAHOSTNで:
      rm –rf   ${MSERVER_HOME}_DELETE

Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

Oracle SOA Suiteエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

エンタープライズ・デプロイメントへのOracle SOA Suiteコンポジット・アプリケーションのデプロイ

Oracle SOA Suiteアプリケーションは、様々な種類のOracle SOA Suiteコンポーネントから構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次が含まれます。

  • サービス・コンポーネント。ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、オーケストレーションのためのBAMプロセス(Oracle BAM Suiteがインストールされている場合)、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどがあります。

  • 外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)

これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。

Oracle SOA Suiteコンポジット・アプリケーションをOracle SOA Suiteエンタープライズ・デプロイメントにデプロイするときは、必ず各コンポジットを、ロード・バランサ・アドレス(soa.example.com)ではなく、特定のサーバーまたはクラスタ・アドレスにデプロイしてください。

ロード・バランサ・アドレスにコンポジットをデプロイするには、多くの場合、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になります。そのため、ファイアウォールに追加のポートを開く必要があります。

Oracle SOA Suiteコンポジット・アプリケーションの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の項を参照してください。

親トピック: Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用

SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。

SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。

デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。

親トピック: Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

Oracle SOA Suiteエンタープライズ・デプロイメントでのデータベース増分の管理

Oracle SOA Suiteデータベースのデータ量が非常に多くなると、特に、多くのコンポジット・アプリケーションがデプロイされている可能性のあるOracle SOA Suiteエンタープライズ・デプロイメントでは、データベースの保守が難しくなることがあります。

『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の項を参照してください。

親トピック: Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

SOAサーバーでのJMSメッセージの管理

SOAサーバーでJMSメッセージを管理する手順は、いくつかあります。スケール・イン操作の間にメッセージを保持する場合など、一部シナリオでは、これらの手順に従う必要があることがあります。

この項では、これらの手順のいくつかを詳しく説明します。

親トピック: Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

SOAサーバーからのJMSメッセージの排出

JMSメッセージの排出のプロセスは、特定のWebLogicサーバーからメッセージをクリアするために役立ちます。ストアを排出するための基本的な手法は、適切なJMSサーバーでのメッセージ生成の停止、およびアプリケーションへのメッセージ使用の許可で構成されています。

ただし、この手順は、アプリケーションによって異なり、かかる時間を予測できない可能性があります。別の方法として、ここでは、現在のJMS宛先からの現在のメッセージを保存して、必要な場合にそれらを別のサーバーにインポートするための、一般的な手順を示します。

排出手順は、1つ以上のサーバーを削除することでクラスタのサイズが縮小されるため、スケール・インやスケール・ダウンのシナリオで役立ちます。削除するサーバーからメッセージを排出し、それらをクラスタ内の別のサーバーにインポートすることで、メッセージが失われないようにすることができます。

一部の障害回復保守シナリオで、スナップショット・スタンバイ・データベースを使用することでセカンダリの場所でサーバーを起動するときに、この手順を使用することもできます。この場合は、ドメインの起動時にスタンバイ・ドメインで使用されないようにするために、セカンダリの場所でドメインを起動する前に、ドメインからメッセージを排出する必要があることがあります(そうしないと、実行が重複する可能性があります)。このシナリオでは、メッセージをインポートできません。

サーバーからJMSメッセージを排出するには、次のステップを実行します。
  1. JMSサーバーに対して生成を一時停止することで、新しいワークロードを停止します。操作の影響を受けるサーバーのJMSサーバーごとに、このアクティビティを実行する必要があります。
    1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。
    2. 「環境」→「サーバー」に移動します。
    3. 削除するサーバーで、「サービス」→「メッセージング」→「JMSランタイム」→「JMSサーバー」に移動します。
    4. 「JMSサーバー」を選択します。
    5. 「休止」→「生成」をクリックします。
  2. 宛先からメッセージを排出します。JMSメッセージを排出するには、アプリケーションで保留中メッセージを使用します。ただし、このタスクは、アプリケーションによって異なり、時間がかかる可能性があります。そのため、各宛先のメッセージをエクスポートすることをお薦めします。どの宛先にメッセージがあるかの確認:
    1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。
    2. 「環境」→「サーバー」に移動します。
    3. 削除するサーバーで、「サービス」→「メッセージング」→「JMSランタイム」→「JMSサーバー」に移動します。
    4. 各JMSサーバーで、宛先メンバーに現在のメッセージがあるかどうかを確認します。宛先名、そのJMSモジュールおよびJMSサーバーを識別します。
    5. 削除するサーバーで実行されているJMSサーバーごとに、このアクティビティを繰り返します。
    • キューからのメッセージの排出: 現在のメッセージがあるキュー宛先の場合:

      1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。

      2. 「ダッシュボード」に移動し、「JMS宛先」ダッシュボードをクリックします。

      3. メッセージをエクスポートするキューを選択します。

      4. 「メッセージ」タブで、「エクスポート」→「すべてエクスポート」を選択し、メッセージをファイルにエクスポートします。後で使用するために、ファイル名をノートにとります。

      5. 「すべて削除」オプションを使用して、エクスポートしたメッセージを削除します。このステップは、メッセージの重複を避けるために重要となります。

    • トピックからのメッセージの排出

      重大なビジネス・インパクトがある場合のみ、トピックからメッセージを排出およびインポートするようにすることをお薦めします。各トピックの用途およびビジネス・インパクトの詳細は、表19-6を参照してください。EDNによって使用される、トピックdist_EDNTopic_auto内のメッセージの損失のみ、ビジネス・インパクトがあります。

      表19-6 コンポーネントの各トピックの用途とビジネス・インパクトの詳細

      コンポーネント JMSモジュール JMSトピック名 用途 メッセージ損失のビジネス・インパクト

      BPM

      BPMJMSModule

      dist_MeasurementTopic_auto

      内部プロセスのスター・スキーマにプロセス・メトリックのメッセージを公開するために使用されます。

      影響は少ない。

      プロセスのスター・スキーマ・データ・オブジェクトに基づいてPCSワークスペース・ダッシュボードおよびBAMダッシュボードに表示される、一部のダッシュボード数に影響します。

      BPM

      BPMJMSModule

      dist_PeopleQueryTopic_auto

      論理グループ・メンバーシップを更新するために使用されます。

      影響は少ない。

      グループ・メンバーシップは、スケジューラに基づいて再計算されます。

      SOA

      SOAJMSModule

      dist_B2BBroadcastTopic_auto

      B2Bによって使用されます。メッセージは、すぐに使用するためのものです。

      影響なし。

      SOA

      SOAJMSModule

      dist_EDNTopic_auto

      EDN用に使用されます。アプリケーションのイベント・メッセージが含まれています。

      ビジネス・インパクト。

      これらのEDNイベント・メッセージを使用するアプリケーションは、それらを失うことになります。

      SOA

      SOAJMSModule

      dist_TenantTopic_auto

      使用されなくなりました。

      影響なし。

      SOA

      SOAJMSModule

      dist_XmlSchemaChangeNotificationTopic_auto

      使用されなくなりました。

      影響なし。

      Insight

      ProcMonJMSModule

      dist_ProcMonActivationTopic_auto

      ライフサイクル操作(クラスタの様々なノード間でのInsightモデルのアクティブ化)のために、Insightによって使用されます。

      影響なし。

      BAM

      BAMJMSSystemResource

      dist_oracle.beam.cqs.activedata_auto

      本番環境では使用されません。

      影響なし。

      BAM

      BAMJMSSystemResource

      dist_oracle.beam.persistence.activedata_auto

      アクティブ・データ問合せを支援して永続から連続問合せプロセッサに送信されるデータ変更通知です。

      影響は少ない。

      メッセージ損失によって起こる可能性があるのは、アクティブ・データ・ダッシュボードでの誤ったデータ表示のみです。ダッシュボードのリフレッシュまたはアクティブ問合せの再実行によって、正しいデータが復元されます。

      BAM

      BAMJMSSystemResource

      dist_oracle.beam.server.event.reportcache.changelist_auto

      レポート・キャッシュからアクティブ・データ・ダッシュボードに送信されるデータ変更です。

      BAM

      BAMJMSSystemResource

      dist_oracle.beam.server.metadatachange_auto

      アーティファクト(問合せ、ビュー、ダッシュボード)が変更された場合に、下流のリスナーに送信されるメタデータ変更です。

      MFT

      MFTJMSModule

      dist_MFTSystemEventTopic_auto

      リスニング・ソースのアクティブ化、PGPキーの追加、Mbeanプロパティの変更など、すべてのノードでの同期が必要なイベントを公開するために使用されます。

      影響は少ない。

      これらのメッセージは、存続期間が非常に短く、少ない頻度となります。メッセージ損失があった場合は、再起動により、すべてのノードが同期されます。
      トピックからメッセージを排出するには、次のステップに従います。

      1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。

      2. 「ダッシュボード」に移動し、「JMS宛先」ダッシュボードをクリックします。

      3. 削除するトピックを選択し、そのサブスクライバに移動します。

      4. 現在のメッセージがある恒久サブスクライバを選択し、「メッセージの表示」をクリックします。

      5. 「エクスポート」→「すべてエクスポート」をクリックし、メッセージをファイルにエクスポートします。後で使用するために、ファイル名をノートにとります。

      6. 「削除」→「すべて削除」をクリックして、サブスクライバからエクスポートしたメッセージを削除します。このステップは、メッセージの重複を避けるために重要となります。

      7. 現在のメッセージがあるトピック内の任意のサブスクライバに対してエクスポート・プロセスを繰り返します。

SOAサーバーへのJMSメッセージのインポート

前にエクスポートしたメッセージを、JMS宛先の別のメンバーまたは同じメンバーにインポートできます。この手順は、スケール・インやスケール・ダウンのシナリオで、削除するサーバーからクラスタ内の別のメンバーにメッセージをインポートするために使用されます。

JMSメッセージをインポートするには、次のステップを実行します。

  • キュー内のメッセージのインポート:

    1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。

    2. 「ダッシュボード」に移動し、「JMS宛先」ダッシュボードをクリックします。

    3. メッセージをインポートするキューを選択します。

    4. 「メッセージ」タブで、「インポート」を選択してこの宛先のメッセージをインポートします。

    5. キュー宛先ごとにステップを繰り返します。

  • トピック内のメッセージのインポート:

    1. WebLogicリモート・コンソールで、「モニタリング・ツリー」を開きます。

    2. 「ダッシュボード」に移動し、「JMS宛先」ダッシュボードをクリックします。

    3. メッセージをインポートするトピック・メンバーを選択します。

    4. トピックで、恒久サブスクライバを開き、メッセージをインポートするサブスクライバを選択します。

    5. 「メッセージの表示」および「インポート」をクリックします。このサブスクライバのメッセージを含むファイルを選択します。

    6. メッセージをインポートする必要があるトピック内のサブスクライバごとに、ステップを繰り返します。