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

前
 
次
 

7 ノード・マネージャの設定

この章では、EDGの推奨事項に従ってノード・マネージャを構成する方法を説明します。


重要:

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

この章の内容は次のとおりです。

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

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

プロセス

この章に記載されている手順は、第1.5項「エンタープライズ・デプロイメントの参照用トポロジ」で説明しているエンタープライズ・デプロイメント・トポロジの様々なコンポーネントで実行する必要があります。この章では、次の変数を使用して、コンポーネント固有の項目を区別します。

これらの変数に使用する値は、このEDGのコンポーネント固有の章に記載されています。この章に記載されている手順は、コンポーネント固有の章に記載されている情報を使用して、VIPとIPのペアごとに複数回実行する必要があります。

推奨事項:

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

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

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


注意:

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

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

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

LogFile=ORACLE_BASE/admin/nodemanager.log

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    注意:

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

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

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

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

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

    例:

    HOST> java utils.CertGen welcome1 HOST.mycompany.com_cert 
    HOST.mycompany.com_key domestic HOST.mycompany.com
    
    HOST> java utils.CertGen welcome1 VIP.mycompany.com_cert 
    VIP.mycompany.com_key domestic VIP.mycompany.com
    

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

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

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

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

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


    注意:

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

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

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

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

    例:

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

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

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

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

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

    HOST> 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
    

    例:

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

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

    例:

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

7.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の正しい値を使用してください。たとえば、HOST2ではappIdentity2を使用します。

例:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    3. カスタムIDキーストアのパスフレーズ: 第7.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. カスタム信頼キーストアのパスフレーズ: 第7.3.3項「keytoolユーティリティを使用したトラスト・キーストアの作成」New_Passwordに指定したパスワードを入力します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HOST> cd WL_HOME/server/bin
HOST> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

注意:

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

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

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

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

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

    注意:

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