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

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

• 管理サーバーの手動フェイルオーバーの確認
  ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
• 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
  この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を説明します。
• エンタープライズ・デプロイメントの管理用のロールの構成
  この項では、特定の管理ロールを持つ製品の概要を提供して、エンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する手順を説明します。
• エンタープライズ・デプロイメントでのTLOGおよびJMSのためのJDBC永続ストアの使用
  次のトピックは、どのようなときにトランザクション・ログ(TLOGs)およびJMSにJDBC永続ストアを使用するかのガイドラインを提供します。サポートされるデータベースに永続ストアを構成するために使用できる手順も説明します。
• エンタープライズ・デプロイメントのバックアップとリカバリの実行
  この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。
• uploadおよびstageディレクトリの絶対パスへの変更
  ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、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であり、ethX:Yに割り当てられており、WCCHOST1およびWCCHOST2からアクセスできます。

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

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

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

• 別のホストへの管理サーバーのフェイルオーバー
  次の手順は、管理サーバーを異なるノード(WCCHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。
• Oracle HTTP Serverを介したWCCHOST2上の管理サーバーへのアクセスの検証
  管理サーバーの手動フェイルオーバーを実行したら、標準管理URLを使用して管理サーバーにアクセスできることを確認することが重要です。
• WCCHOST1への管理サーバーのフェイルバック
  手動管理サーバーフェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを検証したら、管理サーバーを元のホストに移行して戻すことができます。

17.1.1 別のホストへの管理サーバーのフェイルオーバー

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

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

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

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

2. 管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。

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

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

      /sbin/ifconfig ethX:Y down
      

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

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

      注意:

      索引は、BIHOST2上のBIサーバー2の索引と異なるものにする必要があります。

      次に例を示します。

      /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

      注意:

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

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

   /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
   

5. WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

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

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

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

      http://ADMINVHN:7001/console
      

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

      http://ADMINVHN:7001/em

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

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

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

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

  このURLではWebLogic Server管理コンソールが表示されます。

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

  このURLでは、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

17.1.3 WCCHOST1への管理サーバーのフェイルバック

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

1. 管理サーバーを停止します。
2. WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを停止します。
3. WCCHOST2で次のコマンドをルートとして実行します。

   /sbin/ifconfig ethZ:N down
   

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

   /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

   注意:

   使用するネットマスクおよびインタフェースがWCCHOST1の使用可能なネットワーク構成と一致することを確認します

5. WCCHOST1上でarpingを使用して、ルーティング表を更新します。

   /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
   

6. WCCHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
7. WCCHOST1上で管理サーバーを起動します。
8. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

   http://ADMINVHN:7001/console
   

9. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

   http://ADMINVHN:7001/em

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

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

注意:

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

• 中間層とロード・バランサ間のSSL通信が必要になるとき
  
• utils.CertGenユーティリティを使用した自己署名証明書の作成
  
• utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成
  
• Keytoolユーティリティを使用した信頼キーストアの作成
  
• トラスト・ストアへのロード・バランサ証明書のインポート
  
• Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加
  
• カスタム・キーストアを使用するためのノード・マネージャの構成
  
• カスタム・キーストアを使用するためのWebLogic Serverの構成
  
• SSLエンドポイントを使用したコンポジットのテスト
  

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

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

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

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

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。異なる目的(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 WCCHOST1.example.com_cert \
         WCCHOST1.example.com_key domestic WCCHOST1.example.com
   

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

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

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

注意:

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

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

   構文:

   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/WCCHOST1.example.com_cert.pem
        -keyfile KEYSTORE_HOME/WCCHOST1.example.com_key.pem
        -keyfilepass password
        -keystore appIdentityKeyStore.jks
        -storepass password 
        -alias WCCHOST1
        -keypass password
   

2. システムで使用される残りのすべてのホスト(たとえばWCCHOST2)で前述の手順を繰り返します。

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

WCCHOST1.example.comに信頼キーストアを作成する手順は次のとおりです。

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

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

   cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks
   

2. keytoolユーティリティを使用してデフォルト・パスワードを変更します。

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

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

   次に例を示します。

   keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
   

3. keytoolユーティリティを使用して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
   

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

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

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

   keytool -import -file wcc.example.com -v -keystore appTrustKeyStore.jks

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

各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetUserOverrides.shスクリプトを次のように作成および編集します。

1. WCCHOST1にログインして、テキスト・エディタで次のファイルを開きます。

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

17.2.7 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/nodemanagerディレクトリの両方にあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成の手順に従って、WCCHOST1 MSERVER_HOMEでは別名WCCHOST1を使用し、WCCHOST1上のASERVER_HOMEでは別名ADMINVHNを使用します。

(appIdentity2 mapped to the WCCHOST1 listen address).
Example for Node 1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

「WCCHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを再起動し、エントリを暗号化します。

注意:

この構成の実行後にドメインが拡張されるたびにCustomIdentityAlias値を修正する必要があります。解凍操作によって、ドメイン構成が書き込まれるときにCustomIdentityAliasが管理サーバーの値に置き換えられます。

17.2.8 カスタム・キーストアを使用するための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になります)。

   • カスタム・アイデンティティ・キーストアのパスフレーズ: 「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. キーストアが更新された管理対象サーバーを再起動します。

    注意:

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

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

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

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

   http://ADMINVHN:7001/em
   

   この例では、次のとおりです。

   • ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

   • ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

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

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

この項では、特定の管理ロールを持つ製品の概要を提供して、エンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する手順を説明します。

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

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

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

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

• 特定の管理ロールを持つ製品のサマリー
  
• エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加
  

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

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

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

製品	アプリケーション・ストライプ	割り当てる管理ロール
Oracle Web Services Manager。	wsm-pm	policy.updater
SOAインフラストラクチャ	soa-infra	SOAAdmin

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

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

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

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

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

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

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

• JMSおよびTLOGのためのJDBC永続ストアについて
  Oracle Fusion Middlewareは、Oracle WebLogic Serverトランザクション・ログ(TLOG)およびJMSのために、データベースベースとファイルベース両方の永続ストアをサポートします。環境の永続ストア戦略を決定する前に、各アプローチのメリットとデメリットを検討してください。
• JMS永続ストアとTLOGを使用する製品およびコンポーネント
  
• TLOGおよびJMS永続ストアのパフォーマンスへの影響
  トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。ここでは、TLOGおよびJMSのJDBC永続ストアの使用によるパフォーマンスの影響を判別するために役立つガイドラインと詳細情報を説明します。
• TLOG用のJDBC永続ストア構成のロードマップ
  次のトピックでは、トランザクション・ログのためにデータベースベースの永続ストアを構成する方法を説明します。
• JMS用のJDBC永続ストア構成のロードマップ
  次のトピックでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。
• TLOGのユーザーと表領域の作成
  トランザクション・ログのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。
• JMSのユーザーと表領域の作成
  JMSのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。
• TLOGおよびJMSストアのGridLinkデータ・ソースの作成
  JMSおよびTLOGにデータベースベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
• 管理対象サーバーへのTLOG JDBCストアの割当て
  データベースで表領域とユーザーを作成して、データ・ソースを作成した後で、TLOG永続ストアを必須の管理対象サーバーそれぞれに割り当てることができます。
• JDBC JMSストアの作成
  JMS永続ストアのユーザーと表領域をデータベースに作成し、JMS永続ストアのデータ・ソースを作成した後で、管理コンソールを使用してストアを作成できます。
• JMSサーバーへのJMS JDBCストアの割当て
  データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。
• JMS JDBCストアに必要な表の作成
  JMSにJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表を作成することです。このタスクを実行してから、ドメインの管理対象サーバーを再起動します。

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

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

注意:

選択する記憶域のタイプにかかわらず、トランザクションの整合性と一貫性を保つためにJMSとTLOGで同じタイプのストアを使用することをお薦めします。

OracleデータベースでTLOGおよびJMSデータを格納すると、データベースのレプリケーションや高可用性の機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡略化できます。これは、障害時リカバリ構成にOracle Fusion Middlewareをデプロイしている場合に特に重要です。

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

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

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

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

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

移行可能なターゲットを含む永続ストアは、JDBC永続ストア使用の検討対象として適しています。MDSに関連するリストされたストアについてはこの章では扱わず、検討対象にはなりません。

17.4.3 TLOGおよびJMS永続ストアのパフォーマンスへの影響

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

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

トランザクション・ログの場合、ログの性質から非常に一過性が高いため、JDBCストア使用の影響は相対的にわずかです。一般的に、システムの他のデータベース操作と比べると影響は最小です。

一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。

パフォーマンスに影響する要因

JMS DBストアをカスタム宛先で使用するとき、システムのパフォーマンスに影響する要因は複数あります。主なものを次に示します。

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

• 永続化するペイロード

• SOAシステムでの同時実行性(宛先のコンシューマに対するプロデューサ)

前述のそれぞれの影響の程度に応じて、パフォーマンスを改善するために次に関して様々な設定を構成できます。

• JMS表で使用されるデータ型(RAWまたはLOBの使用)

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

JMSトピックの影響

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

データ型とペイロード・サイズの影響

ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズが100バイトから20KBまでの場合、SecureFiles LOBで必要なデータベース時間はRAWデータ型の場合よりも少し長くなります。

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

SecureFilesのもう1つの利点は、ペイロードが500KB以上に増加すると、発生するデータベース時間が安定することです。つまり、その時点で、データによって格納されるペイロードが500KB、1MBまたは2MBであるかは(SecureFilesにとって)関係ありません。書込みは非同期で行われ、競合はすべてのケースで同一であるためです。

キューのスループットに対する同時実行性(プロデューサとコンシューマ)の影響は、ペイロード・サイズが50KBになるまではRAWとSecureFilesで似ています。ペイロードが小さい場合は、同時実行性を変更しても影響は実質的に同じです(RAWのスケーラビリティが少し上回ります)。ペイロードが50KBを超えると、SecureFilesのスケーラビリティが高くなります。

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

永続ストアに定義された同時実行性とワーカー・スレッドによって、RACデータベースの索引およびグローバル・キャッシュ・レベルで競合が発生することがあります。1つのサーバーで複数のワーカー・スレッドを有効にするときに逆索引を使用する、または複数のOracle WebLogic Serverクラスタを使用すると、逆索引を使用すると状況が改善する可能性があります。ただし、Oracle Databaseのパーティション化オプションが使用可能な場合は、索引のグローバル・ハッシュ・パーティションをかわりに使用してください。こうすると、索引の競合とグローバル・キャッシュ・バッファの待機が減少し、それによってアプリケーションのレスポンス時間が短縮されます。パーティション化はどのケースでも効果がありますが、逆索引を使用しても大きく改善されないことがあります。

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

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

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

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

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

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

ここでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

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

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

3. JDBC JMSストアの作成

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

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

17.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;

17.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;
   

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

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

エンタープライズ・デプロイメントでは、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のサービス名を入力します。次に例を示します。

     wccedg.example.com

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

     db-scan.example.com:1521
     

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

     
     図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=wccedg.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データ・ソースを作成します。

17.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. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.10 JDBC JMSストアの作成

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

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

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

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

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

17.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/
   

   注意:

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

   注意:

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

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

   このリリースで提供され、前の手順のレビュー用に抽出された3つのOracle DB定義があります。基本定義には、索引用のパーティションを使用しない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);

   この例をJMSストアのデフォルト・スキーマ定義と比較してください。デフォルトのスキーマ定義では、RAWデータ型が使用され、索引のパーティションはありません。

   パーティション数は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. 管理対象サーバーを再起動します。

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

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

注意:

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

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

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

• 環境のリカバリに関する項

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

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

タイプ	ホスト	層
データベースOracleホーム	DBHOST1およびDBHOST2	データ層
Oracle Fusion Middleware Oracleホーム	WEBHOST1およびWEBHOST2	Web層
Oracle Fusion Middleware Oracleホーム	WCCHOST1およびWCCHOST2	アプリケーション層
インストール関連ファイル	WEBHOST1、WEHOST2および共有記憶域	該当なし

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

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

タイプ	ホスト	層
管理サーバーのドメイン・ホーム(ASERVER_HOME)	WCCHOST1およびWCCHOST2	アプリケーション層
アプリケーション・ホーム(APPLICATION_HOME)	WCCHOST1およびWCCHOST2	アプリケーション層
Oracle RACデータベース	DBHOST1およびDBHOST2	データ層
スクリプトとカスタマイズ	WCCHOST1およびWCCHOST2	アプリケーション層
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)	WCCHOST1およびWCCHOST2	アプリケーション層
OHS構成ディレクトリ	WEBHOST1およびWEBHOST2	Web層

17.6 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを作成し、すべてのホストの管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

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

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

4. 「サーバー」をクリックします。

5. 管理対象サーバー・ドメイン・ホーム・ディレクトリ内の新しい各管理対象サーバーについて次の操作を実行します。

   1. 管理対象サーバーの名前をクリックします。

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

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

      MSERVER_HOME/servers/server_name/stage
      

      MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。

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

      ASERVER_HOME/servers/AdminServer/upload
      

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

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

   6. 「サーバーのサマリー」画面に戻ります。

6. 各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。