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

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

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

Oracle Fusion Middlewareエンタープライズ・デプロイメントに適用されるこれらの共通の構成タスクを完了します。これらのタスクには、デプロイメントのサイジング要件の確認、Webサービス用のJDBC永続ストアの使用、およびデプロイメントのバックアップの取得が含まれます。

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

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

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

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

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

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

前提条件:

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

    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マシン(物理マシンではなく論理マシン)を使用することに注意してください。

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

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

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

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

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

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

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

      ip addr show dev ethX

      たとえば:

      ip addr show dev eth0

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

      ip addr del ADMINVHN/CIDR dev ethX

      たとえば:

      ip addr del 100.200.140.206/24 dev eth0

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

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

      たとえば:

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

      ノート:

      使用するCIDRとインタフェースが、WCCHOST2で使用可能なネットワーク構成と一致することを確認します。

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

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

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

    cd $NM_HOME

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

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

    wccedg_domain=MSERVER_HOME;

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

    cd $NM_HOME

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

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

    wccedg_domain=MSERVER_HOME;ASERVER_HOME

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ノート:

    使用するCIDRとインタフェースが、WCCHOST1で使用可能なネットワーク構成と一致することを確認します。

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

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

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

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

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

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

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

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

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

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

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

      MSERVER_HOME/servers/server_name/stage

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

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

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

      ASERVER_HOME/servers/AdminServer/upload

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

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

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

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

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

      ASERVER_HOME/servers/AdminServer/stage

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

      ASERVER_HOME/servers/AdminServer/upload

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

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

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

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

    ノート:

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

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

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

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

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

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

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

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

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

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

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

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

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

    構文

    
WL_HOME/server/bin/setWLSEnv.sh

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

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

    
WL_HOME/server/bin/setWLSEnv.sh

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

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

    構文

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

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

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

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

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

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

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

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

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

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

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

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

    構文

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

    例

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

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

    構文

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

    例

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

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

    例

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

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

    例

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

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

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

ノート:

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

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

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

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

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

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

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

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

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

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

    たとえば:

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

    ノート:

    WLSサーバー・トラスト・ストアにロード・バランサ証明書を追加する必要があるのは、自己署名証明書の場合のみです。サードパーティの認証局が発行したロード・バランサ証明書の場合は、ルートの公開証明書と中間証明書をトラスト・ストアにインポートする必要があります。
Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加
トラスト・ストアのパスは、ドメインが作成された章でWebLogic起動スクリプトにすでに追加されているため、追加の構成は必要ありません。SSLエンドポイントのCAや証明書が追加された新しいトラスト・ストアで既存のトラスト・ストアを置き換えるようにすれば十分です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Oracle Unified Directoryの場合:

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

    Oracle Internet Directoryの場合:

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

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

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

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

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

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

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

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

ノート:

(構成ウィザードを使用して)このEDGで様々なコンポーネントを設定するために提供されるステップは、JDBC永続ストアですでに構成されていることに注意してください。カスタム永続ストアの場合、またはファイル・ストアからJDBCストアに再構成する場合は、次のステップを使用します(ファイルからJDBCへのメッセージの移行は、このEDGの範囲外です)。
TLOGおよびJMSデータ・ソースの統合に関する推奨事項

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

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

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

  • データ・ソース内の競合が多いときに、JMSメッセージを永続化するためにプール内で使用可能な接続がない場合、永続ストアに障害が発生する可能性があります。

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

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

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

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

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

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

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

ノート:

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

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

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

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

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

  3. JDBC JMSストアの作成

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

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

ノート:

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

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

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

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

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

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

    たとえば:

    SQL> create user TLOGS identified by password;

SQL> grant create table to TLOGS;

SQL> grant create session to TLOGS;

SQL> alter user TLOGS default tablespace tlogs;

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

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

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

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

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

    たとえば:

    SQL> create user JMS identified by password;

SQL> grant create table to JMS;

SQL> grant create session to JMS;

SQL> alter user JMS default tablespace jms;

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

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

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

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

    表18-1 GridLinkデータ・ソースのプロパティ

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

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

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

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

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

    ノート:

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

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

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

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

  1. unresolvable-reference.htmlの情報を確認し、使用している環境に適した表機能を決定します。

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

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

    例:

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

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

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

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

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

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

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

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

  • 接続

  • SecureConversation

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

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

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

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

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

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

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

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

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

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

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

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

  • 予約時に接続をテスト

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

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

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

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

  • テスト頻度

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

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

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

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

jdbc:oracle:thin:@wccedg_alias

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


wccedg_alias =
        (DESCRIPTION=
        (ADDRESS_LIST=
            (LOAD_BALANCE=ON)
            (ADDRESS=(PROTOCOL=TCP)(HOST=wccedgdb-scan)(PORT=1521)))
            (CONNECT_DATA=(SERVICE_NAME=wccedg.example.com))
        )

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

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

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

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

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

    ノート:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ノート:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      jdbc:oracle:thin:@wccedg_alias

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

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

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

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

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

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

該当なし

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

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

タイプ ホスト 層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

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

ホスト当たり

アプリケーション層

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

WCCHOST1 (またはNASファイラ)

アプリケーション層

OHS構成ディレクトリ

WEBHOST1およびWEBHOST2

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

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

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

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

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

    WCCHOST1 (またはNASファイラ)

    アプリケーション層

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

    WCCHOST1 (またはNASファイラ)

    アプリケーション層

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

    WCCHOST1 (またはNASファイラ)

    アプリケーション層

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

    WCCHOST1 (またはNASファイラ)

    アプリケーション層

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

    ホスト当たり

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

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

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

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

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

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

    ノート:

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

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

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

    BAK_TAG

    BEFORE_BPM

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

    BAK_DIR

    /backups

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

    DOMAIN_NAME

    wccedg_domain

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

    ASERVER_HOME

    /u01/oracle/config/domains/wccedg_domain

    DEPLOY_PLAN_HOME

    /u01/oracle/config/dp

    APPLICATION_HOME

    /u01/oracle/config/applications/wccedg_domain

    ORACLE_RUNTIME

    /u01/oracle/runtime

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

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

    ノート:

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

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

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

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

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

    ノート:

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

Example:
NAME                           GUA TIME                              STORAGE_SIZE
------------------------------ --- -------------------------------- -------------
SOAEDG_BEFORE_BPM              YES 12-MAY-17 03.29.28.000000000 AM     8589934592
exit
ドメイン・ランタイム・アーティファクトのリストア
バックアップが作成された時点までドメインをリカバリするには、次のステップに従います:
  1. oracleユーザーを使用してWCCHOST1にログインします。
  2. ドメイン内のすべてのサーバー(AdminServerを含む)を停止します。
  3. 次のドメイン変数にドメインの値が設定されていることを確認します:
    変数 値の例

    ASERVER_HOME

    /u01/oracle/config/domains/wccedg_domain

    DEPLOY_PLAN_HOME

    /u01/oracle/config/dp

    APPLICATION_HOME

    /u01/oracle/config/applications/wccedg_domain

    ORACLE_RUNTIME

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

    BAK_TAG

    BEFORE_BPM

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

    BAK_DIR

    /backups

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

    DOMAIN_NAME

    wccedg_domain

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

    ノート:

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

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