プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
12c (12.2.1.1)
E77231-01
目次へ移動
目次
前
前 		次
次

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

次の各項では、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。
親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

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

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

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

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

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

    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であり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。

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

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

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

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

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

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

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

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

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

    このガイドの前半で示した手順を使用してホストごとのノード・マネージャを起動した場合、ノード・マネージャを起動したターミナル・ウィンドウに戻り、[Ctrl]キーを押しながら[C]キーを押してプロセスを停止します。

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

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

      /sbin/ifconfig ethX:Y down

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

      /sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>

      例:

      /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

      注意:

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

  4. 次の例のように、arpingを使用してルーティング表を更新します。

    /sbin/arping -q -U -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ファイルを編集し、MSERVER_HOMEへの参照を追加します。

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

    soaedg_domain=MSERVER_HOME;ASERVER_HOME

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

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

  11. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

    1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

      http://ADMINVHN:7001/console

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

      http://ADMINVHN:7001/em

21.1.1.2 Oracle HTTP Serverを介したSOAHOST2上の管理サーバーへのアクセスの検証

管理サーバーの手動フェイルオーバーを実行したら、標準の管理URLを使用して管理サーバーにアクセスできるかを確認することが重要です。

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

  • http://admin.example.com/console

    このURLはWebLogic Server管理コンソールを表示するはずです。

  • http://admin.example.com/em

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

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

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

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

  1. SOAHOST2で管理サーバーを停止します。
  2. SOAHOST2でノード・マネージャを停止します。
  3. 次のコマンドをSOAHOST2上でrootとして実行します。
    /sbin/ifconfig ethZ:N down
  4. 次のコマンドをSOAHOST1上でrootとして実行します。
    /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

    注意:

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

  5. SOAHOST1上でarpingを使用して、ルーティング表を更新します。
    /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
  6. SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  7. nodemanager.domainsファイルを編集し、MSERVER_HOMEへの参照を削除します。
  8. SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  9. nodemanager.domainsファイルを編集し、MSERVER_HOMEへの参照を追加します。
  10. SOAHOST2でノード・マネージャを起動し、SOAHOST1でノード・マネージャを再起動します。
  11. SOAHOST1で管理サーバーを起動します。
  12. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。
    http://ADMINVHN:7001/console
  13. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
    http://ADMINVHN:7001/em

21.1.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

この項では、中間層とハードウェア・ロード・バランサとの間のSSL通信を有効にする方法を説明します。

注意:

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

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

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

たとえば、Oracle SOA Suiteエンタープライズ・デプロイメントでは、次のような例が該当します。

  • Oracle Business Process Managementは、特定のWebサービス経由でロール情報を取得しようとするときに、フロントエンド・ロード・バランサのURLにアクセスする必要がある。

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

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

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

21.1.2.2 utils.CertGenユーティリティを使用した自己署名証明書の作成

この項では、SOAHOST1に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」に記載されているKEYSTORE_HOMEの場所に対するファイル・システムの指定に関する情報を参照してください。

かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

  1. 一時的に環境を設定するためにWL_HOME/server/bin/setWLSEnv.shスクリプト・コマンドを実行します。
    . WL_HOME/server/bin/setWLSEnv.sh

    現在のシェルでシェル・スクリプトを参照するために、スクリプト名の前にドット(.)と空白( )があることに注意してください。

  2. CLASSPATH環境変数が設定されていることを確認します。
    echo $CLASSPATH
  3. 共有構成ディレクトリ・フォルダが作成され、「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように共有記憶域に正しくマウントされていることを確認します。

    たとえば、次のコマンドを使用して、各ホストで共有構成ディレクトリが使用できることを確認します。

    df -h | grep -B1 SHARED_CONFIG_DIR

    SHARED_CONFIG_DIRを、共有構成ディレクトリへの実際のパスに置き換えます。

    ディレクトリを表示して、ホストで使用できることを確認することもできます。

    ls -al SHARED_CONFIG_DIR
  4. キーストア・ホーム・フォルダ構造が存在しない場合は、作成します。

    例:

    cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores
export KEYSTORE_HOME=$SHARED_CONFIG_DIR/keystores
  5. ディレクトリを、キーストア・ホームに変更します。
    cd KEYSTORE_HOME
  6. utils.CertGenツールを実行し、ノード内のサーバーで使用される物理ホスト名と仮想ホスト名の両方の証明書を作成します。

    構文:

    java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

    例:

    java utils.CertGen password ADMINVHN.example.com_cert \
      ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password SOAHOST1.example.com_cert \
      SOAHOST1.example.com_key domestic SOAHOST1.example.com

21.1.2.3 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

この項では、SOAHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、SOAHOST1とADMINVHN両方の証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

  1. ADMINVHNおよびSOAHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

    構文:

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

    注意:

    デフォルトのkeystore_typeはjksです。

    例:

    java utils.ImportPrivateKey 
     -certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem
     -keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem
     -keyfilepass password
     -keystore appIdentityKeyStore.jks 
     -storepass password
     -alias ADMINVHN
     -keypass password

java utils.ImportPrivateKey 
     -certfile KEYSTORE_HOME/SOAHOST1.example.com_cert.pem
     -keyfile KEYSTORE_HOME/SOAHOST1.example.com_key.pem
     -keyfilepass password
     -keystore appIdentityKeyStore.jks
     -storepass password 
     -alias SOAHOST1
     -keypass password
  2. システムで使用される残りのすべてのホスト(SOAHOST2など)について、上述の手順を繰り返します。

21.1.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.example.comに信頼キーストアを作成するには:

  1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。

    標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。例:

    cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks
  2. キーツール・ユーティリティを使用してデフォルト・パスワードを変更します。

    標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。

    keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

    例:

    keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
  3. キーツール・ユーティリティを使用してCA証明書をappTrustKeyStoreにインポートします。

    CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。

    次の構文を使用して、証明書をインポートします。

    keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

    例:

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

21.1.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。

  1. ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。
  2. ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システムにある(soa.example.comのようなファイル名を持つ)ファイルにエクスポートします。
  3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。
    keytool -import -file soa.example.com -v -keystore appTrustKeyStore.jks

21.1.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリにsetUserOverrides.shスクリプトを作成して編集します。
  1. SOAHOST1にログインして、テキスト・エディタで次のファイルを開きます。
    ASERVER_HOME/bin/setUserOverrides.sh
  2. 2行を追加してEXTRA_JAVA_PROPERTIES環境変数を設定およびエクスポートし、カスタマイズされたSSLトラスト・ストア・パラメータを挿入します。

    EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。例:

    EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks"
export EXTRA_JAVA_PROPERTIES
  3. setUserOverrides.shをASERVER_HOME/binディレクトリから、このドメインで使用されるすべてのホスト上のMSERVER_HOME/binディレクトリにコピーします。

    注意:

    これにはWEBHOSTnホストは含まれません。

setUserOrverrides.shの使用は、従来setDomainEnv.shを編集して実装されてきたドメイン・レベルでの変更を構成するために推奨されるベスト・プラクティスです。setDomainEnv.shを編集することは、ドメインのスクリプトが構成ウィザードで拡張されたり解凍操作で更新されたりすると、そのファイルに対する手動変更が上書きされるため、推奨されません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

21.1.2.7 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、次の手順を実行します。

IDキーストアおよび信頼キーストアを構成するには:

  1. 管理コンソールにログインして「ロックして編集」をクリックします。
  2. 左ペインで「環境」を開き、「サーバー」を選択します。
  3. IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。
  4. 「構成」を選択して、「キーストア」を選択します。
  5. 「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。
  6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

    • カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

      KEYSTORE_HOME/appIdentityKeyStore.jks

    • カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    • カスタムIDキーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します

      この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  7. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

    • カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

      KEYSTORE_HOME/appTrustKeyStore.jks

    • カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    • カスタム信頼キーストアのパスフレーズ: 「keytoolユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。

      前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

  8. 「保存」をクリックします。
  9. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  10. 「ロックして編集」をクリックします。
  11. 「構成」をクリックし、「SSL」をクリックします。
  12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

    「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します

  13. 「保存」をクリックします。
  14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
  15. 管理サーバーを再起動します。
  16. キーストアが更新された管理対象サーバーを再起動します。

    注意:

    管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正常であるということです。

21.1.2.8 SSLエンドポイントを使用したコンポジットのテスト

SSLが有効になると、Oracle Enterprise Manager FMW Controlから、SSL上のコンポジット・エンドポイントを検証できます。SSLエンドポイントをテストするには、次の手順に従います。

  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    http://ADMINVHN:7001/em

    この例では、次のようになります。

  2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  3. 左側のツリーから、SOAを開きます。「soa-infra」(WLS_SOAn)をクリックして、コンポジットがデプロイされたパーティションを選択します。
  4. コンポジットを選択します。
  5. 右側のペインで、「テスト」タブをクリックします。
  6. WSDLまたはWADLアドレスで、http://soa.example.com:80をsoa.example.comに置き換えます。
  7. 「WSDLまたはWADLの解析」をクリックします。
  8. 表示されるエンドポイントURLがSSLであることを確認します。
  9. コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。

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

この項では、固有の管理ロールを使用する製品のサマリーを示し、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する手順を示します。

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

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

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

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

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

次の表に、エンタープライズ・デプロイメント用に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

Oracle MFT

mftess

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

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

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

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

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

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

Oracle Business Activity Monitoring

BAMAdministrators

Oracle Business Process Management

Administrators

Oracle Service Bus統合

IntegrationAdministrators

MFT

OracleSystemGroup

注意:

MFTでは、集中LDAPに特定のユーザー(OracleSystemUser)を追加する必要があります。このユーザーは、OracleSystemGroupグループに属している必要があります。MFTジョブの作成および削除が適切に動作するように、ユーザー名とユーザー・グループの両方を集中LDAPに追加する必要があります。

21.1.3.3 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

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

  1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

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

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

21.1.3.4 製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザー(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を、表21-1で示す製品管理者グループの実際の名前と置き換えます。

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

  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

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

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

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

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

注意:

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

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

また、TLOGおよびJMSデータをデータベースに格納するということは、このデータ専用の共有記憶域の場所を識別する必要がないことを意味します。ただし、エンタープライズ・デプロイメントの他の局面では、共有記憶域は依然として必要です。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポートするため)、デプロイメント・プラン、ファイル/FTPアダプタ制御や処理ファイルなどのアダプタ・アーティファクトには必要です。

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

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

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

どのインストール済製品およびコンポーネントが永続ストアを利用しているかは、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションのドメイン名→「サービス」→「永続ストア」で判別できます。このリストには、ストア名、ストア・タイプ(通常はFileStore)、ターゲットの管理対象サーバー、およびターゲットを移行できるかどうかが示されます。

移行可能なターゲットを持つ永続ストアは、JDBC永続ストアの使用を考慮するうえで適切な候補となります。リストされたMDS関連のストアは、この章の範囲外であり、ここでは検討しません。

21.1.4.3 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のパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。

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

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

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

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

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

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

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

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

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

  3. JDBC JMSストアの作成

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

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

21.1.4.6 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;

21.1.4.7 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;

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

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

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

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
  3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
  4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

    • 「名前」フィールドに、データ・ソースの論理名を入力します。

      TLOGストアの場合はTLOGを入力し、JMSストアの場合はJMSを入力します。

    • JNDIの名前を入力します。

      TLOGストアの場合はjdbc/tlogsを入力し、JMSストアの場合はjdbc/jmsを入力します。

    • 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

    • 「次へ」をクリックします。

  5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。
    「グローバル・トランザクションのサポート」チェック・ボックス
  6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
  7. 次の接続プロパティを入力します。

    • サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:

      soaedg.example.com

    • ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例:

      db-scan.example.com:1521

      「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

      GUID-4EE8C869-7B58-4D2E-8525-8AFB9F9A3879-default.jpgの説明が続きます
      GUID-4EE8C869-7B58-4D2E-8525-8AFB9F9A3879-default.jpgの説明

      SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

      SQL>show parameter remote_listener;

NAME                 TYPE        VALUE
 
--------------------------------------------------
 
remote_listener     string      db-scan.example.com

      注意:

      Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

      dbhost1-vip.mycompany.com (port 1521)

      および

      dbhost2-vip.mycompany.com (1521)

    • データベース・ユーザー名: 次を入力します。

      TLOGストアの場合はTLOGSを入力し、JMS永続ストアの場合はJMSを入力します。

    • パスワード: データベースでユーザーを作成した際に使用したパスワードを入力します。

    • パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

  8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

    「次へ」をクリックします。

  9. 「ONSクライアント構成」ページで、次の手順を実行します。

    • 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

    • ここにも、次のように、SCANアドレス: RACデータベースのONSリモート・ポート、データベースから報告されたONSリモート・ポートを入力し、「追加」をクリックします。

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
 
ONS exists: Local port 6100, remote port 6200, EM port 2016

    • 「次へ」をクリックします。

    注意:

    Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

    custdbhost1.example.com (port 6200)

    および

    custdbhost2.example.com (6200)
  10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for db-scan.example.com:6200 succeeded.

    「次へ」をクリックします。

  11. 「ターゲットの選択」ページで、永続ストアを使用するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。
  12. 「終了」をクリックします。
  13. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  14. 手順4から手順13を繰り返し、JMSファイル・ストアのGridLinkデータ・ソースを作成します。

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

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

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
  3. 「ドメイン構造」ツリーで「環境」を展開し、「サーバー」を展開します。
  4. TLOGストアを使用する管理対象サーバーの名前をクリックします。
  5. 「構成」>「サービス」 タブを選択します。
  6. 「トランザクション・ログ・ストア」で、「タイプ」メニューから「JDBC」を選択します。
  7. 「データ・ソース」メニューで、TLOG永続ストアに作成したデータ・ソースを選択します。
  8. 「接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。
  9. 「保存」をクリックします。
  10. クラスタ内の追加の管理対象サーバーごとに、手順3から7を繰り返します。
  11. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

21.1.4.10 JDBC JMSストアの作成

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

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
  3. 「ドメイン構造」ツリーで「サービス」を開き、「永続ストア」を選択します。
  4. 「新規」をクリックしてから「JDBCストア」をクリックします。
  5. 使用している永続化するJMSサーバーに容易に結び付けられる永続ストア名を入力します。
  6. インストールとクラスタを修飾する一意の接頭辞を指定し、JMS永続ストアに作成したデータ・ソースに関連付けます。
  7. ストアをJTAサービスをホストするエンティティにターゲット指定します。
    サービス移行を使用するサーバーの場合、これはJMSサーバーが属する移行可能なターゲットになります。
  8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

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

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

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
  3. 「ドメイン構造」ツリーで、「サービス」、「メッセージング」、「JMSサーバー」の順に開きます。
  4. 永続ストアを使用するJMSサーバーの名前をクリックします。
  5. 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。
  6. 「保存」をクリックします。
  7. クラスタ内の追加のJMSサーバーごとに、手順3から6を繰り返します。
  8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

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

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

  1. findコマンドを使用してWLSコアJDBCストア・ライブラリの場所を特定し、JDKに付属するjarユーティリティを使用してDDLファイルを一時ディレクトリに抽出します。
    mkdir /tmp/edgddl
cd /tmp/edgddl
JAVA_HOME/bin/jar xvf WL_HOME/modules/com.bea.core.store.jdbc.jar weblogic/store/io/jdbc/ddl/

    注意:

    これにより、サポートされる様々なデータベース・プラットフォーム用およびOracle DB用の複数のDDLファイルが抽出され、必要な機能に基づいて選択できます。

    注意:

    weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。

  2. 「TLOGおよびJMS永続ストアのパフォーマンスへの影響」の情報を確認し、現在の環境に適切な表の機能を決定します。

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

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

    例:

    mkdir -p ORACLE_RUNTIME/domain_name/ddl
  4. 要件分析に基づいて新しい共有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およびパーティショニング・ガイド』を参照してください。

  5. 前の手順1でtmpディレクトリに抽出したカスタム・ディレクトリおよびファイルをクリーンアップします。
  6. 管理コンソールを使用して、前に作成した既存のJDBCストアを編集し、JMSデータに使用する表を作成します。
    1. Oracle WebLogic Server管理コンソールにログインします。
    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
    3. 「ドメイン構造」ツリーで「サービス」、「永続ストア」の順に開きます。
    4. 前に作成した永続ストアをクリックします。
    5. 「詳細」オプションの下で、「DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlと入力します。
    6. 「保存」をクリックします。
    7. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  7. 管理対象サーバーを再起動します。

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

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

注意:

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

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

  • 「環境のバックアップ」

  • 「環境のリカバリ」

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

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

タイプ ホスト 層

データベースのOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

SOAHOST1およびSOAHOST2

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

なし

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

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

タイプ ホスト 層

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

SOAHOST1およびSOAHOST2

アプリケーション層

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

SOAHOST1およびSOAHOST2

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

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

SOAHOST1およびSOAHOST2

アプリケーション層

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

SOAHOST1およびSOAHOST2

アプリケーション層

OHS構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

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

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

21.2.1 エンタープライズ・デプロイメントへの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コンポジット・アプリケーションの管理

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

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

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

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

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

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

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

  • データベース増分管理戦略の策定に関する項

  • データベース増分の管理に関する項

前
前 		次
次
目次へ移動
目次