ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B63036-03
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

10 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。


重要:

セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。

この章には次のトピックが含まれます:

10.1 ノード・マネージャの設定について

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

エンタープライズ・デプロイメント・トポロジのノード・マネージャの構成に関して、次の2つの推奨事項があります。

  1. ノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するミドルウェア・ホーム内)以外の場所に置くことをお薦めします。詳細は、第10.2項「ノード・マネージャのログの場所の変更」を参照してください。

  2. また、ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。それには、ドメイン内で使用される複数のアドレスの証明書を使用する必要があります。この章では、ホスト名検証のために各ホストで証明書を構成する手順について説明します。詳細は、第10.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。


注意:

このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムな順序で並べたパスワードを使用します。

10.2 ノード・マネージャのログの場所の変更

ノード・マネージャのログの場所を変更するには、MW_HOME/wlserver_10.3/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルを編集します。ログ・ファイルの新しい場所を指定する次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

この場所には、MW_HOMEディレクトリの外部にあり、EDGのadminディレクトリの内部にある場所を使用することをお薦めします。

ノード・マネージャを再起動して、変更を有効にします。

10.3 ノード・マネージャのホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間の通信にホスト名検証証明書を設定する手順は次のとおりです。

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

ノード・マネージャが物理ホスト名(APPHOSTn.mycompany.com)をリスニングし管理対象サーバーが仮想ホスト名(APPHOSTnVHN1.mycompany.com)をリスニングする構成に、この章で(例として)追加された証明書は対応します。管理対象サーバーが仮想ホスト名を使用しているときはいつでも、管理対象サーバーがあるノードから別のノードに移行する可能性があることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順は次のように拡張されます。

  • 必要なホスト名(APPHOSTn.mycompany.comおよびAPPHOSTnVHN1.mycompany.com以外のホスト名の場合)を証明書ストアに追加します。

  • アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、APPHOSTnに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

次の例では、APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの証明書を構成します。つまり、APPHOSTnで、物理ホスト名(APPHOSTn)と仮想ホスト名(APPHOSTnVHN1)の両方を使用することを前提としています。また、APPHOSTn.mycompany.comはノード・マネージャが使用するアドレスであり、APPHOSTnVHN1.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも前提としています。これは、管理サーバーとOracle Fusion Middlewareコンポーネントをホストするノードや、1つのサーバーに共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングしてもう一方が仮想ホスト名をリスニング(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

  1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境設定を行います。Bourneシェルの場合、次のコマンドを実行します。

    APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> ../setWLSEnv.sh

    CLASSPATH環境変数が設定されていることを確認します。

    APPHOSTn> echo $CLASSPATH

  2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ORACLE_BASE/admin/domain_name/cluster_nameディレクトリの下にcertsというディレクトリを作成します。証明書はWLSドメイン間で共有できることに注意してください。

    APPHOSTn> cd ORACLE_BASE/admin/domain_name/cluster_name
APPHOSTn> mkdir certs

    注意:

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

  3. 前の手順で作成したディレクトリに移動します。

    APPHOSTn> cd certs

  4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの両方の証明書を作成します。

    構文(すべてを1行で入力します):

    java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name 
[export | domestic] [Host_Name]

    例:

    APPHOSTn> java utils.CertGen welcome1 APPHOSTn.mycompany.com_cert 
APPHOSTn.mycompany.com_key domestic APPHOSTn.mycompany.com

APPHOSTn> java utils.CertGen welcome1 APPHOSTnVHN1.mycompany.com_cert 
APPHOSTnVHN1.mycompany.com_key domestic APPHOSTnVHN1.mycompany.com

    最初のコマンドの出力例を次に示します。

    ...... Will generate certificate signed by CA from CertGenCA.der file
...... With Domestic Key Strength
...... Common Name will have Hostname APPHOSTn.mycompany.com
...... Issuer CA name is CN=CertGenCAB,OU=FOR TESTING ONLY,O=MyOrganization,
L=MyTown,ST=MyState,C=US

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

次の手順に従って、APPHOSTnにアイデンティティ・キーストアを作成します。

  1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前で新しいアイデンティティ・キーストアを作成します。このキーストアは、証明書と同じディレクトリ(つまり、ORACLE_BASE/admin/domain_name/aserver/domain_name/certs)に作成します。


    注意:

    utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

  2. APPHOSTn.mycompany.comとAPPHOSTnVHN1.mycompany.comの両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。

    構文(すべてを1行で入力します):

    java utils.ImportPrivateKey Keystore_File Keystore_Password 
Certificate_Alias_to_Use Private_Key_Passphrase 
Certificate_File Private_Key_File [Keystore_Type]

    例:

    APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 
appIdentity1 welcome1 ORACLE_BASE/admin/domain_name/aserver/domain_name/
certs/APPHOSTn.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/
aserver/domain_name/certs/APPHOSTn.mycompany.com_key.pem

APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 
appIdentity2 welcome1 ORACLE_BASE/admin/domain_name/aserver/
domain_name/certs/APPHOSTnVHN1.mycompany.com_cert.pem ORACLE_BASE/admin/
domain_name/aserver/domain_name/certs/APPHOSTnVHN1.mycompany.com_key.pem

10.3.3 Keytoolユーティリティを使用したトラスト・キーストアの作成

この項の手順は、最初の管理対象サーバーでのみ実行する必要があります。

次の手順に従って、APPHOST1にトラスト・キーストアを作成します。

  1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書をその証明書と同じディレクトリにコピーします。例:

    APPHOST1> cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks

  2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。パスワードを変更するにはkeytoolユーティリティを使用します。構文は、次のとおりです(すべてを1行で入力します)。

    APPHOST1> keytool -storepasswd -new New_Password -keystore Trust_Keystore 
-storepass Original_Password

    例:

    APPHOST1> keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks 
-storepass changeit

  3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。また、このCA証明書は、keytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は、次のとおりです(すべてを1行で入力します)。

    APPHOST1> keytool -import -v -noprompt -trustcacerts -alias Alias_Name 
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

    例:

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

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

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

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

各ノードでCustomIdentityAliasの正しい値を使用してください。たとえば、APPHOST2ではappIdentity2を使用します。

例:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/
certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity2
CustomIdentityPrivateKeyPassPhrase=welcome1

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

10.3.5 カスタム・キーストアを使用するための管理対象サーバーの構成

この項の手順は、管理サーバーとすべての管理対象サーバーで実行する必要があります。

アイデンティティ・キーストアおよびトラスト・キーストアを構成する手順は次のとおりです。

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

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. アイデンティティ・キーストアとトラスト・キーストアを構成するサーバーの名前(bi_servern)をクリックします。選択したサーバーの設定ページが表示されます。

  6. 「構成」を選択して、「キーストア」を選択します。

  7. 「キーストア」フィールドを、秘密鍵/デジタル証明書の組合せおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法に変更します。

  8. 「ID」セクションで、アイデンティティ・キーストアの属性を次のように定義します。

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

      ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/
appIdentityKeyStore.jks

    2. カスタムIDキーストアのタイプ: このフィールドは必ず空白にします。デフォルト値のJKSは使用しないでください。

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

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

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

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

      ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/
appTrustKeyStore.jks

    2. カスタム信頼キーストアのタイプ: このフィールドはデフォルトでJKSになっています。このデフォルト値を明示的に削除して、フィールドを空白にする必要があります。

    3. カスタム信頼キーストアのパスフレーズ: 第10.3.3項「keytoolユーティリティを使用したトラスト・キーストアの作成」でNew_Passwordに指定したパスワードを入力します。

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

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

  11. チェンジ・センターで、変更のアクティブ化をクリックします。

  12. 「構成」を選択して、「SSL」を選択します。

  13. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  14. 「秘密鍵の別名」フィールドに、管理対象サーバーがリスニングするホスト名として使用した別名を入力します。

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

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

  16. チェンジ・センターで、変更のアクティブ化をクリックします。

10.3.6 管理対象サーバーのホスト名検証設定の変更

前項までの手順を実行した後、影響を受ける管理対象サーバーのホスト名検証を「BEAホスト名の検証」に設定する必要があります。そのためには、すべての管理対象サーバーで次の手順を実行します。

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

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で管理対象サーバーを選択します。そのサーバーの設定ページが表示されます。

  6. 「SSL」タブを開きます。

  7. 表示されたページの「詳細」セクションを開きます。

  8. 「ホスト名の検証」を「BEAホスト名の検証」に設定します。

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

  10. チェンジ・センターで、変更のアクティブ化をクリックします。

  11. 変更を適用した管理対象サーバーを再起動します。

10.4 ノード・マネージャの起動

MW_HOMEに共通記憶域または共有記憶域のインストールを使用している場合は、同じ基本構成(nodemanager.properties)を使用する別のノードからノード・マネージャを起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第10.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」に従って、appIdentityKeyStore.jksにインポートします。ストア内で証明書が利用可能になった場合、各ノードマネージャでは別のアイデンティティの別名が指定され、正しい証明書が管理サーバーに送信される必要があります。そのためには、各ノードで、ノード・マネージャを起動する前に次のように適切な環境変数を設定します。

APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityn

各ホストに明確に割り当てられているカスタムID別名を指定してください。たとえば、APPHOST1の場合はappIdentity1、APPHOST2の場合はappIdentity2を指定します。


注意:

ノード・マネージャの出力から、ノード・マネージャが適切なストアおよび別名を使用していることを確認します。ノード・マネージャの出力は、次のように表示されます。

CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityn

ここでnは1、2、...です。

共通記憶域または共有記憶域のインストールをMW_HOMEで使用していない場合、次のコマンドを実行して、APPHOSTnでノード・マネージャを再起動します。

  1. ノード・マネージャのプロセスを停止します。そのためには、そのプロセスが起動されたシェルでCTRL-Cを使用するか、またはオペレーティング・システムでプロセスを確認して強制終了します。

  2. ノード・マネージャを次のように起動します。

    APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> ./startNodeManager.sh

    注意:

    ノード・マネージャが未構成で、1回も起動していない場合は、ORACLE_COMMON_HOME/common/bin/setNMProps.shスクリプトを実行します。これにより、Oracle Business Intelligenceに必要な起動スクリプトを使用できるようになります。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引