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

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

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

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

WLSSchemaDataSourceの適切なサイジングおよび構成の検証

Oracle FMW 14.1.2では、WLSRuntimeSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データソースです。

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

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

管理サーバーの手動フェイルオーバーの確認

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップについて説明します。

前提条件:

  • 管理サーバーを、localhostまたは他の任意のホストのアドレスではなく、ADMINVHN上でリスニングするように構成します。

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

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

  • 管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

    • WCCHOST1: 100.200.140.165

    • WCCHOST2: 100.200.140.205

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

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

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

ここでは、管理サーバーのフェイルオーバー手順のテストを実行する方法を詳しく説明します。
ホストごとのノード・マネージャを使用している場合の管理サーバーのフェイルオーバー

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

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

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

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

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

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

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

    1. WCCHOST1上で次のコマンドをroot権限で実行し、そのCIDR上の仮想IPアドレスを確認します。 

      ip addr show dev ethX

      ここで、XはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr show dev eth0

    2. WCCHOST1上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。 

      ip addr del ADMINVHN/CIDR dev ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr del 100.200.140.206/24 dev eth0:1

    3. WCCHOST2で次のコマンドをルートとして実行します。 

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

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr add 100.200.140.206/24 dev eth0 label eth0:1

      ノート:

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

      特に冗長結合インタフェースを持つシステムの場合、ネットワーク・インタフェースのデバイス名がX以外のものである場合があります。

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

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

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

    cd $NM_HOME

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

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

    wcpedg_domain=MSERVER_HOME;

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

    cd $NM_HOME

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

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

    wcpedg_domain=MSERVER_HOME;ASERVER_HOME

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

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

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

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

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

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

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

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

    このURLによって、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

    このドメインに対して定義したプロバイダからWebLogicリモート・コンソールにログインできることを確認します。

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

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

    このURLによって、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

ホストごとのノード・マネージャを使用する場合の管理サーバーのWCCHOST1へのフェイルバック

管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

  1. WCCHOST2で管理サーバーを停止します。
  2. WCCHOST2でノード・マネージャを停止します。
  3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

    1. WCCHOST2上で次のコマンドをroot権限で実行し、そのCIDR上の仮想IPアドレスを確認します。 

      ip addr show dev ethX

      ここで、XはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr show dev eth0

    2. WCCHOST2上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースです)。 

      ip addr del ADMINVHN/CIDR dev ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr del 100.200.140.206/24 dev eth0:1

    3. WCCHOST1で次のコマンドをroot権限で実行します。 

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

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      たとえば:
      ip addr add 100.200.140.206/24 dev eth0 label eth0:1

      ノート:

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

  4. arpingを使用してルーティング表を更新します。たとえば:
    arping -b -A -c 3 -I eht0 100.200.140.206
  5. WCCHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  6. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を削除します。
  7. WCCHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  8. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を追加します。
  9. WCCHOST2でノード・マネージャを起動し、WCCHOST1でノード・マネージャを再起動します。
  10. WCCHOST1上で管理サーバーを起動します。
  11. 次の方法でWCCHOST1上の管理サーバーにアクセスできることをテストします。

    1. WebLogicリモート・コンソールを使用して、このドメインに対して定義したプロバイダにアクセスできることをテストします。

    2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

      https://ADMINVHN:9002/em

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

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

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

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

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

  2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

  3. 「ロックして編集」をクリックします。

  4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

    1. 静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。

    2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。

  5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

    1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。 

      MSERVER_HOME/servers/server_or_template_name/stage

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

      静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。

      動的クラスタを使用する場合、テンプレート名はそのままにしておきます。たとえば: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage

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

      ASERVER_HOME/servers/AdminServer/upload

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

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

    5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

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

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

    1. 「サーバー」に移動してAdminServerを選択します。

    2. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    3. 「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。

      ASERVER_HOME/servers/AdminServer/stage

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

      ASERVER_HOME/servers/AdminServer/upload

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

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

  8. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

ノート:

これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。

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

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

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

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」を開きます。
  3. 「環境」を開きます。
  4. 「クラスタ」を開きます。「クラスタ」ページで、変更するクラスタをクリックし、「HTTP」タブを選択します。
  5. 次の値を設定します。

    • フロントエンド・ホスト: wcp.example.com

    • フロントエンドHTTPポート: 0

    • フロントエンドHTTPSポート: 443

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

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

中間層とフロントエンド・ハードウェア・ロード・バランサ(またはWebCenter Content 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や証明書が追加された新しいトラスト・ストアで既存のトラスト・ストアを置き換えるようにすれば十分です。

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

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。

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

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

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

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

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

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

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

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

Oracle Web Services Manager

wsm-pm

policy.updater

WebCenter Portal

webcenter

s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator

SOAインフラストラクチャ

soa-infra

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

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

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

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

表17-1 製品固有の管理グループを持つ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_wcp)を使用してFusion Middleware Controlにサインインして、アプリケーションのホーム・ページに移動します。

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

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

製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザー(weblogic_wcp)をグループに追加します。これにより、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_wcp,cn=users,dc=us,dc=oracle,dc=com
cn: product-specific_group_name
description: Administrators Group for the Domain

    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に対する永続ストアの使用

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

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

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

この項では、JDBCとファイル永続ストアを比較して利点を分析し、サポートされるデータベースで永続ストアを構成する手順を説明します。JDBCストアではなくファイル永続ストアを使用する場合に、これを構成する手順も、この項で説明します。

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

永続ストアを利用するFMW製品およびコンポーネントを決定するには、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションで、ドメイン名 > 「サービス」 > 「永続ストアを使用します。リストには、ストア、ストア・タイプ(FileStoreおよびJDBC)、およびストアのターゲットが示されます。リストされている中でMDSに関連するストアについてはこの章では扱わず、考慮されません。

これらのコンポーネントは(必要に応じて)ストアをデフォルトで使用します。
コンポーネント/製品 JMSストア TLOGストア

SOA

あり

あり

WCC

あり

あり

WCP

なし

なし

WSM

なし

なし
コンポーネント/製品 JMSストア TLOGストア

OAM

なし

なし

OIM

あり

あり

通常、Oracle WebCenter ContentおよびOracle SOAが含まれるOracle WebCenter Portal環境の場合、各クラスタ内の管理対象サーバーがJMSおよびTLOGSのデータ・ソースと新しいJDBC永続ストアのターゲットとなります。

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

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

ノート:

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

JMSおよびTLOGのための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使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。

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

カスタム宛先に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永続ストアを使用するためのガイドラインを説明します。サポートされているデータベースで永続ストアを構成するための手順も説明します。

TLOGとJMSデータ・ソース結合の推奨事項

データ・ソースの結合および接続の使用を減らすには、JMSおよびTLOG永続ストアの両方に単独接続プールを使用します。

作業負荷が高くない場合、およびWLSSchemaDatasourceプール・サイズの増加を考慮する場合は、TLOGおよびJMS永続ストアに対してWLSSchemaDatasourceをそのまま再利用することをお薦めします。データ・ソースを再利用すると、同じスキーマと表領域が必然的に使用され、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はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS表領域およびWLSSchemaDatasourceを、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。

JMS用のJDBC永続ストア構成のロードマップ

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

  1. JMSのユーザーと表領域の作成

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

  3. JDBC JMSストアの作成

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

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

ノート:

ステップ1と2はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS表領域およびWLSSchemaDatasourceを、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。

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データ・ソース」を選択し、次の内容を入力します。

    表17-2 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表領域およびWLSSchemaDatasourceを再利用します。あるいは、データベースでユーザーと表領域を作成し、データ・ソースが作成済であることを必要な各管理対象サーバーに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サーバーとすぐに関連付けることができる永続ストア名を入力します。

    ノート:

    DBがリリース12.2.x.x.x以下の場合は、接頭辞名が30文字を超えないようにしてください。

    ノート:

    データ・ソース集計を完了するには、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)に一定期間における表の増加率を分析させて、それに応じて表を調整する必要があります。『Database VLDBおよびパーティショニング・ガイド』のパーティション化の概念に関する項を参照してください。

  4. WebLogicリモート・コンソールを使用して、前に作成した既存の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サービスの永続性の管理を参照してください。

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

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

ノート:

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

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

表17-3に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示します。

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

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

WCCHOST1およびWCCHOST2 (またはNASファイラ)

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

N/A

表17-4に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクトを示します。

表17-4 Oracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクト

タイプ ホスト 層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

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

ホスト当たり

アプリケーション層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

OHS/OTD構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

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

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

エンタープライズ・デプロイメントへの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の管理』の次の項を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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