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

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

管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、BIHOST1およびBIHOST2から管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法について説明します。
エンタープライズ・デプロイメントのバックアップとリカバリの実行
この項では、Oracle Business Intelligenceエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

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

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

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

前提条件:

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

ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。
管理サーバーはBIHOST1からBIHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
- BIHOST1: 100.200.140.165
- BIHOST2: 100.200.140.205
- ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、BIHOST1とBIHOST2からアクセスできます。
Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、BIHOST2にインストールされています。

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

次のトピックでは、管理フェイルオーバー・プロシージャのテストを実行する詳細な方法について説明します。

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

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

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

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

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

管理サーバーを停止します。
管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
ADMINVHN仮想IPアドレスを第2ホストに移行します。
1. BIHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
```
/sbin/ifconfig ethX:Y down
```
2. BIHOST2で次のコマンドをルートとして実行します。
```
/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>
```
  次に例を示します。
```
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
```
  注意:
  使用するネットマスクとインタフェースは、BIHOST2で使用可能なネットワーク構成と一致している必要があります。
次の例のように、arpingを使用してルーティング表を更新します。
```
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
```
BIHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
BIHOST2で管理サーバーを起動します。
次の方法でBIHOST2上の管理サーバーにアクセスできることをテストします。
1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
```
http://ADMINVHN:7001/console
```
2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
```
http://ADMINVHN:7001/em
```

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

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

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

http://admin.example.com/console

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

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

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

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

管理サーバーを停止します。
BIHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを停止します。
BIHOST2で次のコマンドをルートとして実行します。
```
/sbin/ifconfig ethZ:N down
```
BIHOST1で次のコマンドをルートとして実行します。
```
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
```
注意:
使用するネットマスクおよびインタフェースがBIHOST1の使用可能なネットワーク構成と一致することを確認します
BIHOST1上でarpingを使用して、ルーティング表を更新します。
```
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
```
BIHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
BIHOST1上で管理サーバーを起動します。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。
```
http://ADMINVHN:7001/console
```
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
```
http://ADMINVHN:7001/em
```

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

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

注意:

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

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

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

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

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

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、BIHOST2では、BIHOST1の証明書用に作成されたcertディレクトリを使用します。

かわりに信頼できる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 
```
ディレクトリをキーストア・ホームに変更します。
```
cd KEYSTORE_HOME
```

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 BIHOST1.example.com_cert \
      BIHOST1.example.com_key domestic BIHOST1.example.com

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

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

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

注意:

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

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

構文:

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

システムで使用されている残りのすべてのホスト(BIHOST2など)に対して前述の手順を繰り返します。

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

BIHOST1.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
```

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

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

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

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

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

BIHOST1にログインして、テキスト・エディタで次のファイルを開きます。
```
ASERVER_HOME/bin/setDomainEnv.sh
```
既存のDemoTrustStoreエントリへの参照を、appTrustKeyStore.jksファイルの場所で置き換えます。
EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。次に例を示します。
```
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
         -Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks..."
export EXTRA_JAVA_PROPERTIES
```
BIHOST1およびBIHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。

あるいは、setUserOverrides.shファイルを使用して、これらのオプションを配置できます。この方法では、ドメインのスクリプトが構成ウィザードによって拡張されたり、解凍操作によって更新されたりする場合にも、これらのオプションは上書きされません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

13.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には必ず正しい値を使用してください。たとえば、BIHOST1では、「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従って、appIdentity2を使用します

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

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

13.2.8 カスタム・キーストアを使用するための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ユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。
  
  前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。
「保存」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
「ロックして編集」をクリックします。
「構成」をクリックし、「SSL」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
変更を適用したサーバーを再起動します。管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。

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

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

注意:

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

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

「環境のバックアップ」
「環境のリカバリ」

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

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

タイプ	ホスト	層
データベースOracleホーム	DBHOST1およびDBHOST2	データ層
Oracle Fusion Middleware Oracleホーム	WEBHOST1およびWEBHOST2	Web層
Oracle Fusion Middleware Oracleホーム	BIHOST1およびBIHOST2	アプリケーション層
インストール関連ファイル	WEBHOST1、WEHOST2および共有記憶域	N/A

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

表13-2 Oracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ	ホスト	層
管理サーバーのドメイン・ホーム(ASERVER_HOME)	BIHOST1およびBIHOST2	アプリケーション層
アプリケーション・ホーム(APPLICATION_HOME)	BIHOST1およびBIHOST2	アプリケーション層
Oracle RACデータベース	DBHOST1およびDBHOST2	データ層
スクリプトとカスタマイズ	BIHOST1およびBIHOST2	アプリケーション層
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)	BIHOST1およびBIHOST2	アプリケーション層
シングルトン・データ・ディレクトリ(SDD)	BIHOST1およびBIHOST2	アプリケーション層