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

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

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

WLSSchemaDataSourceの適切なサイズ変更および構成の確認
WLSSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データベースです。WLSSchemaDataSourceを使用して、重要なWLSインフラストラクチャ内の競合を回避したり、デッドロックを防止したりします。
管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次の各項で、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップについて説明します。
動的クラスタ・サーバー・テンプレートのリスニング・アドレスの構成
動的クラスタ内の動的管理対象サーバーのデフォルトの構成では、すべての使用可能なネットワーク・インタフェースをリスニングします。ほとんどの場合、これは望ましくありません。
中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を理解することが重要です。
エンタープライズ・デプロイメントの管理用のロールの構成
1つのエンタープライズ・デプロイメント・ドメイン内で効率的に各製品を管理するためには、特定の管理ロールまたはグループを必要とする製品、およびエンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する方法を理解する必要があります。
エンタープライズ・デプロイメントでのTLOGおよびJMSの永続ストアの使用
永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。
エンタープライズ・デプロイメントのバックアップとリカバリの実行
Oracle WebCenter Contentエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするために、次に記載するガイドラインに従うことをお薦めします。
エンタープライズ・デプロイメントのuploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
動的クラスタ内のサーバーの起動と停止
構成済の静的クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法を使用して、動的クラスタ内のサーバー・インスタンスを起動および停止できます。
動的クラスタの拡張と縮小
動的クラスタを作成すると、指定した数の動的サーバーがWebLogic Serverによって生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。

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

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

WLSSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービス用としてFMWコンポーネントによって使用されるために予約された共通のデータ・ソースです。WLSSchemaDataSourceを使用して、重要なWLSインフラストラクチャ内の競合を回避したり、デッドロックを防止したりします。

WLSSchemaDataSourceの接続使用量を削減するには、JMS JDBCおよびTLOG JDBCストア接続キャッシュ・ポリシーを、各接続キャッシュ・ポリシー設定を使用して「デフォルト」から「最小」に変更します。バックエンド・データベース・システム内の接続数を削減する必要がある場合、キャッシュ・ポリシーを「最小」に設定することをお薦めします。キャッシュ・ポリシー「なし」を使用するとパフォーマンスが低下する可能性があるため、このポリシーは使用しないでください。JDBCストアによって使用される接続に関する詳細なチューニング・アドバイスについては、『Oracle Fusion Middleware 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のコンポーネントが、このガイドの個々の構成の章で示すように、WCCHOST2にインストールされています。

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

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

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

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

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

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

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

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

管理サーバーを停止します。
管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
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:Y
```
  ここでは、X:Yは、ADMINVHNで現在使用されているインタフェースです。
  たとえば:
```
ip addr add 100.200.140.206/24 dev eth0:1
```
  ノート:
  
  使用するネットマスクとインタフェースを表すCIDRは、WCCHOST2で使用可能なネットワーク構成と一致している必要があります。
  
  特に、冗長な結合インタフェースを持つシステムの場合、ネットワーク・インタフェース・デバイスの名前がethXとは別の名前である可能性があります。
arpingを使用してルーティング表を更新します。たとえば:
```
arping -b -A -c 3 -I eth0 100.200.140.206
```
WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
WCCHOST2上で管理サーバーを起動します。
次の方法でWCCHOST2上の管理サーバーにアクセスできることをテストします。
1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
```
http://ADMINVHN:7001/console
```
2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
```
http://ADMINVHN:7001/em
```

親トピック: 管理サーバーの手動フェイルオーバーの検証

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

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

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

http://admin.example.com/console

このURLではWebLogic Server管理コンソールが表示されます。
http://admin.example.com/em

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

親トピック: 管理サーバーの手動フェイルオーバーの検証

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

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

管理サーバーを停止します。
管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
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:Y
```
  ここでは、X:Yは、ADMINVHNで現在使用されているインタフェースです。
  たとえば:
```
ip addr add 100.200.140.206/24 dev eth0:1
```
  ノート:
  
  使用するネットマスクとインタフェースを表すCIDRは、WCCHOST1で使用可能なネットワーク構成と一致している必要があります。
arpingを使用してルーティング表を更新します。たとえば:
```
arping -b -A -c 3 -I eht0 100.200.140.206
```
WCCHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
WCCHOST1上で管理サーバーを起動します。
次の方法でWCCHOST1上の管理サーバーにアクセスできることをテストします。
1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
```
http://ADMINVHN:7001/console
```
2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
```
http://ADMINVHN:7001/em
```

親トピック: 管理サーバーの手動フェイルオーバーの検証

動的クラスタ・サーバー・テンプレートのリスニング・アドレスの構成

動的クラスタ内の動的管理対象サーバーのデフォルトの構成では、すべての使用可能なネットワーク・インタフェースをリスニングします。ほとんどの場合、これは望ましくありません。

障害時リカバリに備えて、別のデータ・センターの別のIPにマップできるホスト名の別名(たとえば、WCCHOST1、WCCHOST2)を使用して、それぞれのサーバーのリスニング・アドレスを特定のネットワーク・インタフェースに設定することをお薦めします。動的クラスタでは、それぞれのサーバーを限定的に構成することはできません。リスニング・アドレス構成は、クラスタのserver-templateに1つのみ存在します。クラスタ内の各動的サーバーのlisten-addressプロパティを効率的に設定するために、計算されるマクロを使用する必要があります。

WebLogic Serverには、クラスタ内の動的サーバーの索引番号に対応する"${id}"マクロがあります。この索引は、数字の"1"から始まり、現在のクラスタの管理対象サーバー数だけ増加されます。この連続採番されるサーバーIDマクロは、動的サーバーごとに特定のネットワーク・インタフェースでリスニングするようにリスニング・アドレスが計算される、推奨のホストのネーミング・パターンに使用できます。

このアプローチは、クラスタ当たりのホストごとに管理対象サーバーが1つのみ存在し、クラスタのスケールアウトが水平方向に限定されると見込まれるエンタープライズ・デプロイメント環境にお薦めします。

${id}マクロを使用してserver-templateのリスニング・アドレスを構成するには:

必要なWCCHOSTn、WEBHOSTn、/etc/hosts内のエントリが目的のマシンの適切なIPアドレスに構成されていることを確認します。
たとえば:
```
10.229.188.205 host1.example.com host1 WCCHOST1 
10.229.188.206 host2.example.com host2 WCCHOST2 
10.229.188.207 host3.example.com host5 WEBHOST1 
10.229.188.208 host4.example.com host6 WEBHOST2
```
名前解決の要件の詳細は、「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」を参照してください。
Oracle WebLogic Server管理コンソールに移動し、管理資格証明を使用してサインインします。
```
http://adminvhn:7001/console
```
ドメインに対して「ロックして編集」を選択します。
「クラスタ」→「サーバー・テンプレート」に移動し、変更するサーバー・テンプレートを選択します。

リスニング・アドレス値を、変数割当てが書き込まれた状態で、適切な抽象リスナー・ホスト名に設定します。

たとえば:

wsmpm-server-template  : Listen Address = WCCHOST${id}
UCM-server-template    : Listen Address = WCCHOST${id}
soa-server-template    : Listen Address = WCCHOST${id}
CPT-server-template    : Listen Address = WCCHOST${id}
IPM-server-template    : Listen Address = WCCHOST${id}

「保存」をクリックします。
別のサーバー・テンプレートを変更する必要がある場合は、ステップ4から繰り返します。
「変更のアクティブ化」をクリックします。
テンプレートを使用するサーバーを再起動して、変更内容を有効にします。

マシン名を使用したサーバー・テンプレートのリスニング・アドレスの構成

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

マシン名を使用したサーバー・テンプレートのリスニング・アドレスの構成

ホストのネーミングまたは別名指定の規則が各動的サーバーの内部ID番号と相関する1から始まる連続採番パターンに従っていない場合、またはクラスタ当たりのホストごとに複数の管理対象サーバーでクラスタをスケールアップしようとしている場合は、別の構成が必要になります。この場合、ホスト名の接頭辞とサーバーIDのマクロ・パターンを使用するかわりに、${machineName}マクロの値を使用して特定のリスニング・アドレスを指定できます。${machineName}マクロは、サーバーに動的に割り当てられるマシンの表示名を使用します。そのマシン名は、IPアドレスに解決される必要があります。

${machineName}マクロでserver-templateのリスニング・アドレスを構成するには:

Oracle WebLogic Server管理コンソールに移動し、管理者の資格証明を使用してサインインします。
```
http://adminvhn:7001/console
```
「マシン」に移動して、マシン名のリストを確認します。
それらの名前がネットワーク・アドレスとして解決されることを確認するために、OSのコマンド(pingなど)を使用します。
ドメインに対して「ロックして編集」を選択します。
「クラスタ」→「サーバー・テンプレート」の順に移動して、変更するserver-templateを選択します。
「リスニング・アドレス」の値を${machineName}に設定します。ここに示したとおりに設定します。その他の値を代用しないでください。
「保存」をクリックします。
別のserver-templateも変更する場合は、ステップ5を繰り返します。
「変更のアクティブ化」をクリックします。
変更したserver-templateを使用するサーバーを再起動して、変更内容を有効にします。

親トピック: 動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成

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

中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を理解することが重要です。

ノート:

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

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

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

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

この項では、WCCHOST1に自己署名証明書を作成する手順を説明します。各ホストのネットワーク名または別名を使用してすべてのアプリケーション層ホストの証明書を作成します。

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

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

パスワードについて

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

自己署名証明書を作成するには:

一時的に、次のスクリプトを実行して環境を設定します。
```
. WL_HOME/server/bin/setWLSEnv.sh
```
現在のシェルのシェル・スクリプトをソースとすることを示すためにスクリプト名の前にドット(.)とスペース( )があります。
CLASSPATH環境変数が設定されていることを確認します。
```
echo $CLASSPATH
```
「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明どおりに、正しく共有構成ディレクトリ・フォルダが作成され、共有記憶域にマウントされていることを確認します。
たとえば、次のコマンドを使用して、共有構成ディレクトリが各ホストで使用可能になっていることを確認します。
```
df -h | grep -B1 SHARED_CONFIG_DIR
```
共有構成ディレクトリの実際のパスでSHARED_CONFIG_DIRを置き換えます。

また、ディレクトリのリスト表示を実行して、ホストでディレクトリが使用可能であると確認することもできます。
```
ls -al SHARED_CONFIG_DIR
```

キーストア・ホーム・フォルダ構造が存在していない場合は作成します。

たとえば:

cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores
export KEYSTORE_HOME=SHARED_CONFIG_DIR/keystores

キーストア・ホームにディレクトリを変更します。
```
cd KEYSTORE_HOME
```
utils.CertGenツールを実行し、ホスト当たり1つずつ、管理対象およびノード・マネージャによって使用されるホスト名または別名の証明書を作成します。

ノート:

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
```
システムで使用される残りのすべてのホスト(たとえば、WCCHOST2、WCCHOST1およびWCCHOST2)で前述のステップを繰り返します。
動的クラスタの場合、ADMINVHNおよびホスト当たり1つの証明書以外にも、ワイルドカードURLと一致する証明書も生成する必要があります。
たとえば:
```
java utils.CertGen password WILDCARD.example.com_cert \ 
WILDCARD.example.com_key domestic \*.example.com 
```

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

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

ノート:

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

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

残りのホスト固有の証明書とキーの組合せそれぞれに、java importPrivateKeyコマンドを実行します(たとえば、WCCHOST1、WCCHOST2に対して実行します)。

ノート:

インポートする証明書とキーの各組合せに対して一意の別名を使用してください。

動的クラスタの場合、WILDCARDのカスタムID別名を使用してワイルドカードの証明書と秘密キーの組合せをインポートします。

例:

${JAVA_HOME}/bin/java utils.ImportPrivateKey \ 
-certfile ${KEYSTORE_HOME}/WILDCARD.example.com_cert.pem \ 
-keyfile ${KEYSTORE_HOME}/WILDCARD.example.com_key.pem \ 
-keyfilepass password \ 
-keystore ${KEYSTORE_HOME}/appIdentityKeyStore.jks \ 
-storepass password \
-alias WILDCARD \ 
-keypass password

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。
標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。たとえば:
```
cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks
```
keytoolユーティリティを使用してデフォルト・パスワードを変更します。
標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。
```
keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password
```
たとえば:
```
keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
```
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
```

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

SSLハンドシェイクが適切に動作するには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。ロード・バランサの証明書を追加するには:

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

keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

たとえば:

keytool -import -file /oracle/certificates/soa1.cz.example.com -v -keystore appTrustKeyStore.jks -alias aliasSOA -storepass password
keytool -import -file /oracle/certificates/soa1-osb.cz.example.com.crt -v -keystore appTrustKeyStore.jks -alias aliasOSB -storepass password

ノート:

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

setDomainEnv.shスクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用されます。各サーバーが更新済のトラスト・ストアにアクセスできるように、エンタープライズ・デプロイメントの各ドメイン・ホーム・ディレクトリ内のsetDomainEnv.shスクリプトを編集します。

WCCHOST1にログインして、テキスト・エディタで次のファイルを開きます。
```
ASERVER_HOME/bin/setDomainEnv.sh
```
既存のDemoTrust.jksエントリへの参照を次のエントリに置き換えます。

ノート:

EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。
```
EXTRA_JAVA_PROPERTIES="-Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.jks ${EXTRA_JAVA_PROPERTIES} ......." 
export EXTRA_JAVA_PROPERTIES
```
MSERVER_HOME/binディレクトリ WCCHOST1、WCCHOST2にあるsetDomainEnv.shファイルに対して同じ変更を行います。

ノート:

ASERVER_HOME/binとMSERVER_HOME/binのファイルには違いがあるため、この2つのドメイン・ホームの場所の間でsetDomainEnv.shファイルをコピーすることはできません。MSERVER_HOME/bin/setDomainEnv.shファイルは、ホスト間でコピーできます。

ドメイン拡張のたびに、WebLogic Serverは自動的にsetDomainEnv.shファイルを上書きします。一部のパッチは、このファイルを置き換えることもあります。このタイプの保守操作の後は必ず、setDomainEnv.shに対するカスタマイズ内容を検証してください。

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内の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を使用します。

Example for WCCHOST1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=WCCHOST1
CustomIdentityPrivateKeyPassPhrase=password

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

ノート:

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

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

管理コンソールにログインして「ロックして編集」をクリックします。
左ペインで「環境」を開き、「サーバー」を選択します。
IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。
「構成」を選択して、「キーストア」を選択します。
「キーストア」フィールドで、「変更」をクリックし、秘密キー/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
- カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。
```
KEYSTORE_HOME/appIdentityKeyStore.jks 
```
- カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
- カスタム・アイデンティティ・キーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します
  
  この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。
- カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。
```
KEYSTORE_HOME/appTrustKeyStore.jks 
```
- カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
- カスタム信頼キーストアのパスフレーズを確認: Keytoolユーティリティを使用した信頼キーストアの作成でNew_Passwordの値として指定したパスワード。
  
  前のステップで説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。
「保存」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
「ロックして編集」をクリックします。
「構成」をクリックし、「SSL」をクリックします。
「秘密キーの別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

「秘密キーのパスフレーズ」フィールドと「秘密キーのパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
管理サーバーを再起動します。
キーストアが更新された管理対象サーバーを再起動します。

ノート:

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
```
http://ADMINVHN:7001/em
```
この例では、次のとおりです。
- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。
- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。
管理ユーザー資格証明を使用してFusion Middleware Controlにログインします。
左側のツリーから、SOAを展開し、「soa-infra」 (WLS_SOA1)をクリックします。
「デプロイ済コンポジット」ナビゲーション・タブ・リンクをクリックします。
「コンポジット」をクリックして、コンポジットのダッシュボード・ビューを開きます。
「テスト」ボタンをクリックし、ドロップダウンからサービスの1つを選択します。
WSDLまたはWADLのアドレスで、ベースURL (http://WCCHOST1:8001)をフロントエンド・ロードバランサのベースURL (https://wcc.example.com:443)で置き換え、URIリソース・パスと問合せ文字列は変更しないでおきます。
「WSDLまたはWADLの解析」をクリックします。
表示されるエンドポイントURLがSSLであり、エラーが返されないことを確認します。
コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

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

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

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

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

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

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

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

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

製品	アプリケーション・ストライプ	割り当てる管理ロール
SOAインフラストラクチャ	soa-infra	SOAAdmin

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

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

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

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

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_wcc)とパスワードを作成したときに作成した資格証明です。
「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。
「アプリケーション・ロールの検索」アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。
エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。
「編集」アイコンをクリックして、ロールを編集します。
「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。
「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
エンタープライズ・デプロイメント管理者グループを検索します。グループ名(WCCAdministratorsなど)を「プリンシパル名が次で始まる」フィールドに入力し、右矢印をクリックして検索を開始します。
検索結果で管理者グループを選択し、「OK」をクリックします。
「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

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

エンタープライズ・デプロイメントでの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ストア
B2B	はい	はい
BAM	はい	はい
BPM	はい	はい
ESS	いいえ	いいえ
HC	はい	はい
Insight	はい	はい
MFT	はい	はい
OSB	はい	はい
SOA	はい	はい
WSM	いいえ	いいえ

コンポーネント/製品	JMSストア	TLOGストア
OAM	いいえ	いいえ
OIM	はい	はい

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

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

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

ノート:

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

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

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

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

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

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

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

親トピック: JDBC永続ストアとファイル永続ストアの比較

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にとって)関係ありません。書込みは非同期で行われ、競合はすべてのケースで同一であるためです。

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

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

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

親トピック: JDBC永続ストアとファイル永続ストアの比較

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

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

TLOGおよびJMSデータ・ソースの統合に関する推奨事項
データ・ソースの統合および接続使用量の削減を実現するには、JMSおよびTLOG永続ストアの両方に対して単一の接続プールを使用します。
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データ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。
JMS JDBCストアに必要な表の作成
JMSにJDBC永続ストアを使用する最後のステップは、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

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

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

データ・ソースの統合および接続使用量の削減を実現するには、JMSおよびTLOG永続ストアの両方に対して単一の接続プールを使用します。

ワークロードが大きくない状況下ではTLOGおよびJMS永続ストアに対してWLSSchemaDatasourceをそのまま再使用し、WLSSchemaDatasourceプール・サイズの増大を検討することをお薦めします。データ・ソースを再使用すると、実行スキーマと表領域の使用が強制されるため、PREFIX_WLS表領域内のPREFIX_WLS_RUNTIMEスキーマがTLOGメッセージとJMSメッセージの両方に使用されます。

(たとえば、JMSアクティビティの多さに関連して)ストレスが大きく、データ・ソース内の競合が多い場合、安定性とパフォーマンスの問題が発生する可能性があります。たとえば:

データ・ソース内の競合が多いときに、JMSメッセージを永続化するためにプール内で使用可能な接続がない場合、永続ストアに障害が発生する可能性があります。
データ・ソース内の競合が多いときに、トランザクション・ログを更新するためにプール内で使用可能な接続がない場合、トランザクションで問題が発生する可能性があります。

このような場合は、TLOGとストアに対して個別のデータ・ソースを使用し、異なるストアに対して個別のデータ・ソースを使用します。依然としてPREFIX_WLS_RUNTIMEスキーマを使用できますが、競合の問題を解決するために同じスキーマに対して個別のカスタム・データ・ソースを構成してください。

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

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

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

ノート:

ステップ1と2はオプションです。データ・ソースの統合および接続使用量の削減を実現するには、「TLOGおよびJMSデータ・ソースの統合に関する推奨事項」で説明されているように、PREFIX_WLS表領域およびWLSSchemaDatasourceを再使用できます。

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

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

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

ノート:

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

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

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

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;

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;

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

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

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

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;

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でのJDBC永続ストアの使用

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

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

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

Oracle WebLogic Server管理コンソールにサインインします。
「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。
- 「名前」フィールドに、データ・ソースの論理名を入力します。
  
  TLOGストアの場合はTLOG、JMSストアの場合はJMSと入力します。
- JNDIの名前を入力します。
  
  TLOGストアの場合はjdbc/tlogs、JMSストアの場合はjdbc/jmsと入力します。
- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。
- 「次」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスをクリアして「次へ」をクリックします。
「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
次の接続プロパティを入力します。
- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば:
  
  wccedg.example.com
- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。たとえば:
```
db-scan.example.com:1521
```
  「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。
  
  図18-1 RACデータベースのホスト名とポートの詳細の追加
  
  「図18-1 RACデータベースのホスト名とポートの詳細の追加」の説明
  
  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.example.com (port 1521) 
```
  および
```
dbhost2-vip.example.com (1521)
```
- データベース・ユーザー名: 次のように入力します。
  
  TLOGストアの場合はTLOGSを入力し、JMS永続ストアの場合はJMSを入力します。
- パスワード: データベースでユーザーを作成した際に使用したパスワードを入力します。
- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。
「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.
```
「次」をクリックします。
「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)
```
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。
```
Connection test for db-scan.example.com:6200 succeeded.
```
「次」をクリックします。
「ターゲットの選択」ページで、永続ストアを使用するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
ステップ4～13を繰り返してJMSファイル・ストア用のGridLinkデータ・ソースを作成します。

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

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

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

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

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

JDBC JMSストアの作成

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

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

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

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

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

JMSサーバーに対してJMS永続ストアを割り当てるには:

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

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

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

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

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

このリリースで提供されるOracle DBスキーマ定義は3つあり、前のステップで確認用に抽出されています。基本定義には、索引用のパーティションを使用しないRAWデータ型が含まれます。2番目ではBlobデータ型を使用し、3番目ではBlobデータ型とセキュア・ファイルを使用します。
共有記憶域でカスタムDDLファイルにドメイン固有の名前の付いたフォルダ構造を作成します。すべてのサーバーで使用できるように、ORACLE_RUNTIME共有ボリュームをお薦めします。
例:
```
mkdir -p ORACLE_RUNTIME/domain_name/ddl
```
要件分析に基づいて新しい共有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およびパーティショニング・ガイド』のパーティション化の概念に関する項を参照してください。
管理コンソールを使用して、前に作成した既存のJDBCストアを編集します。JMSデータのために使用される表を作成します。
1. Oracle WebLogic Server管理コンソールにログインします。
2. 「チェンジ・センター」で「ロックして編集」をクリックします。
3. 「ドメイン構造」ツリーで、「サービス」、「永続ストア」を順に展開します。
4. 前に作成した永続ストアをクリックします。
5. 「詳細」オプションで、「DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlを入力します。
6. 「保存」をクリックします。
7. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
管理対象サーバーを再起動します。

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

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

この項では、共有フォルダでTLOGおよびJMSファイル永続ストアを構成するための手順を説明します。

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

共有フォルダでのTLOGファイル永続ストアの構成

Oracle WebLogic Serverでは、トランザクション・ログを使用してシステムのクラッシュやネットワーク障害からリカバリします。

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

静的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成

静的クラスタ内の各管理対象サーバーにデフォルト永続ストアの場所を設定するには、次のステップを実行します。

Oracle WebLogic Server管理コンソールにログインします。
```
ADMINVHN:7001/console
```
ノート:

Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
クラスタ内の管理対象サーバーごとに、次を実行します。
1. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
  
  「サーバーのサマリー」ページが表示されます。
2. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
  
  選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
3. 「構成」タブで、「サービス」タブをクリックします。
4. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
  
  エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
  
  たとえば:
```
ORACLE_RUNTIME/domain_name/cluster_name/tlogs
```
  この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。
5. 「保存」をクリックします。
SOA_Cluster内のすべてのサーバーについて、ステップ3を実行します。
「変更のアクティブ化」をクリックします。

ノート:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

親トピック: 共有フォルダでのTLOGファイル永続ストアの構成

動的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成

動的クラスタのデフォルト永続ストアの場所を設定するには、サーバー・テンプレートを更新します。

Oracle WebLogic Server管理コンソールにログインします。
```
ADMINVHN:7001/console
```
ノート:

Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
クラスタのサーバー・テンプレートにナビゲートします。
1. 「ドメイン構造」ウィンドウで、環境およびクラスタ・ノードを開いて「サーバー・テンプレート」ノードをクリックします。
  
  「サーバー・テンプレートのサマリー」ページが表示されます。
2. 表の「名前」列で、サーバー・テンプレートの名前(ハイパーリンクとして表示)をクリックします。
  
  選択したサーバー・テンプレートの設定ページが開き、「構成」タブがデフォルトで表示されます。
3. 「構成」タブで、「サービス」タブをクリックします。
4. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
  
  エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
  
  たとえば:
```
ORACLE_RUNTIME/domain_name/cluster_name/tlogs
```
  この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。
5. 「保存」をクリックします。
「変更のアクティブ化」をクリックします。

ノート:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

親トピック: 共有フォルダでのTLOGファイル永続ストアの構成

トランザクション・ログの場所と作成の検証

WLS_SERVER_TYPE1およびWLS_SERVER_TYPE2管理対象が起動して稼働した後、「静的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成」および「動的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成」で実行したステップに基づいて、トランザクション・ログ・ディレクトリおよびトランザクション・ログが想定どおりに作成されていることを確認します。

ORACLE_RUNTIME/domain_name/OSB_Cluster/tlogs

_WLS_WLS_SERVER_TYPE1000000.DAT
_WLS_WLS_SERVER_TYPE2000000.DAT

親トピック: 共有フォルダでのTLOGファイル永続ストアの構成

共有フォルダでのJMSファイル永続ストアの構成

ドメインをすでに構成および拡張している場合、JMS永続ファイルは共有の場所にすでに構成されています。他の永続ストア・ファイルを共有フォルダに変更する場合は、次のステップを実行します。

Oracle WebLogic Server管理コンソールにログインします。
「ドメイン」→「サービス」→「永続ストア」にナビゲートし、共有フォルダに移動する永続ストアの名前をクリックします。
「構成: 一般」タブが表示されます
ディレクトリをORACLE_RUNTIME/domain_name/soa_cluster/jmsに変更します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。

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

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

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

ノート:

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

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

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

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

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

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

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

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

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

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

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

ノート:

このオプションは、静的クラスタにのみ適用可能です。

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

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

Oracle WebLogic Server管理コンソールにログインします。
左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。
「ロックして編集」をクリックします。
使用するクラスタ・タイプに適したオブジェクトに移動して編集します。
1. 静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。
2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。
編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。
1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。
2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。
```
MSERVER_HOME/servers/server_or_template_name/stage
```
  MSERVER_HOMEを MSERVER_HOMEディレクトリのフルパスに置き換えます。
  
  静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。
  
  動的クラスタを使用する場合、テンプレート名はそのままにしておきます。たとえば: /u02/oracle/config/domains/wccedg_domain/servers/XYZ-server-template/stage
3. 「アップロード・ディレクトリ名」を次の値に更新します。
```
ASERVER_HOME/servers/AdminServer/upload
```
  ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。
4. 「保存」をクリックします。
5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。
新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。
AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。
1. 「サーバー」に移動してAdminServerを選択します。
2. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。
3. 「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。
  
  ASERVER_HOME/servers/AdminServer/stage
4. 「アップロード・ディレクトリ名」を次の絶対パスに更新します。
  
  ASERVER_HOME/servers/AdminServer/upload
  
  ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。
5. 「保存」をクリックします。
該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。
変更内容を有効にするためにすべての管理対象サーバーを再起動します。

ノート:

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

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

動的クラスタ内のサーバーの起動と停止

構成済の静的クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法を使用して、動的クラスタ内のサーバー・インスタンスを起動および停止できます。

構成済クラスタ内のサーバー・インスタンスを起動および停止する方法は次のとおりです。

WebLogic Server管理コンソール
Fusion Middleware Control
WLSTのstartコマンドとshutdownコマンド
ノード・マネージャ
起動スクリプト

選択する起動方法や実行済のタスクに応じて、サーバー・インスタンスを起動する前に他の手順の実行が必要になる場合があります。『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動および停止に関する項を参照してください。

ノート:

始める前に、WebLogic Serverが、サーバー・インスタンスを実行するすべてのホストにインストールされていることを確認します。ノード・マネージャを使用してサーバー・インスタンスを起動および停止する場合は、それらのホスト上でノード・マネージャも実行する必要があります。

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

動的クラスタの拡張と縮小

動的クラスタを作成すると、WebLogic Serverでは指定した数の動的サーバーが生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。

使用可能な動的サーバー・インスタンスの数は、特定の動的クラスタのサーバー・テンプレートで指定されている構成済の最大値に基づいています。容量要件の一時的な変更は、クラスタ内の使用可能な管理対象サーバーの一部を起動または停止することにより簡単に実現できます。高可用性を維持するためには、少なくとも2台か3台必要であることに注意してください。

最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成で動的サーバーの最大数を増やすことができます。動的クラスタ内のサーバー・インスタンスの数を減らすには、動的サーバーの属性の最大数の値を減らします。この値を小さくする前に、削除する予定のサーバー・インスタンスを停止します。

WLSTのscaleUpコマンドとscaleDownコマンドを使用して、動的クラスタを管理することもできます。動的クラスタ内の動的サーバーの数を増やすには、scaleUpコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数のサーバーの分だけクラスタの最大サイズを増やし、サーバー・インスタンスを起動します。

scaleUpコマンドにより、指定した動的クラスタの実行サーバーの数が増加します。サーバーIDが最も小さい非実行サーバー・インスタンスが最初に起動し、指定した数のサーバー・インスタンスが起動するまで、次に大きなIDの非実行サーバー・インスタンスの起動が続きます。

動的クラスタ内で1つ、すべて、または任意の数のサーバー・インスタンスを起動するには、scaleUpコマンドでnumServers引数を使用して目的の数を指定します。利用可能なすべてのサーバー・インスタンスがすでに実行している場合、指定した数のサーバーを起動する前に、scaleUpコマンドにより、リクエストしたサーバー・インスタンスの最小数までクラスタのサイズを増やします。

動的クラスタの最大サイズを減らすには、scaleDownコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数の実行サーバー・インスタンスを適切に停止して、それらを動的クラスタから削除します。『Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンス』のscaleUpおよびscaleDownに関する項を参照してください。scaleDownコマンドでは、指定した数の実行サーバーを適切に停止します。サーバーIDが最も大きいサーバー・インスタンスが最初に停止し、指定した数のサーバー・インスタンスが停止するまで、次に大きなIDのサーバー・インスタンスの停止が続きます。

ノート:

動的サーバー・インスタンスでは、WLSTのscaleUpコマンドとscaleDownコマンドのみ使用できます。手動で構成したサーバー・インスタンスと動的サーバー・インスタンスの両方が含まれる混在クラスタの場合、scaleUpコマンドとscaleDownコマンドでは、構成済サーバーが無視されます。混在クラスタ内の構成済サーバー・インスタンスを手動で起動して停止する必要があります。

たとえば、クラスタ内に、実行中の動的サーバー2台と実行していない構成済サーバー2台があるとします。scaleUpコマンドを使用する場合、WLSTでは、クラスタに動的サーバー・インスタンスを1つ追加して、動的サーバーを起動します。

WLSTのscaleUpコマンドとscaleDownコマンドには、動的クラスタを手動でスケーリングする方法が用意されています。自動スケーリングの場合、動的クラスタの拡張度を構成できます。拡張度を使用する場合、動的クラスタでは、要求に反応して、あるいはカレンダ・ベースのスケジュールのとおりにスケーリング操作や再プロビジョニング操作を自動で実行できます。WebLogic Serverでは、WebLogic診断フレームワーク(WLDF)のポリシーおよびアクション・システムによって動的クラスタに拡張度が提供されます。「Oracle WebLogic Server動的クラスタの拡張度の構成」を参照してください。

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