ヘッダーをスキップ
Oracle® Exalogic Elastic Cloud Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
リリースEL X2-2、X3-2、X4-2およびX5-2
E51447-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

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

この章では、オラクル社のベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法について説明します。

この章は次の項で構成されています:

12.1 ノード・マネージャの概要

ノード・マネージャによって、管理サーバーおよび管理対象サーバーの起動と停止が可能です。

プロセス

この章で説明する手順は、第2.2項「ExalogicにおけるOracle SOAデプロイメント・トポロジの表示」に示すように、Exalogicエンタープライズ・デプロイメント・トポロジの各種コンポーネントに対してSOAHOST1およびSOAHOST2で実行する必要があります。

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

推奨事項

Exalogicエンタープライズ・デプロイメント・トポロジにおけるノード・マネージャ構成について、次の2つの主要な推奨事項があります。

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

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


注意:

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


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

この項では、Exalogicエンタープライズ・デプロイメント用のノード・マネージャの設定方法について説明します。

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

12.2.1 ノード・マネージャ構成ファイルの保存場所の変更

ノード・マネージャの構成ファイルとログ・ファイルの新しいディレクトリをMW_HOMEディレクトリの外部に作成し、ノード・マネージャのすべての構成タスクをこのディレクトリから実行します。

新しいディレクトリを作成する手順は、次のとおりです。

  1. 次のコマンドをSOAHOST1およびSOAHOST2で実行します。

    mkdir -p /u02/private/oracle/config/nodemanager
    
  2. 次のディレクトリ内のnodemanager.propertiesファイルをコピーします。

    /u01/oracle/products/access/wlserver_10.3/common/nodemanager
    

    コピー先は、SOAHOST1およびSOAHOST2上に作成した新しいnodemanagerフォルダです。

  3. 次のディレクトリ内のstartNodeManager.shファイルをコピーします。

    /u01/oracle/products access/wlserver_10.3/server/bin
    

    および次のフォルダ内にあるnodemanager.domainsファイル。

    /u01/oracle/products/access/wlserver_10.3/common/nodemanager
    

    コピー先は、SOAHOST1およびSOAHOST2上に作成した新しいnodemanagerフォルダです。

  4. SOAHOST1およびSOAHOST2のstartNodeManager.sh (SOAHOST1およびSOAHOST2内の新しいnodemanagerフォルダ内にある)を、テキスト・エディタを使用して開き、次の変更を行います。

    SOAHOST1およびSOAHOST2上で次のように実行します。

    NODEMGR_HOME="/u02/private/oracle/config/nodemanager
    

12.2.2 ノード・マネージャのプロパティ・ファイルの編集

SOAHOST1およびSOAHOST2上の次のディレクトリにあるnodemanager.propertiesファイルを更新します。

/u02/private/oracle/config/nodemanager

SOAHOST1上で、ファイルを次のように編集します。

NodeManagerHome: /u02/private/oracle/config/nodemanager
 ListenAddress= 192.168.10.1
 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log
Properties Value
SecureListener Set the value to "false".
StartScriptEnabled Set the value to "true",
StopScriptEnabled Set the value to "true",
StopScriptName Specify a name for the stop script, for example stopWebLogic.sh.
DomainsFile /u02/private/oracle/config/nodemanager/nodemanager.domains

SOAHOST2上:

NodeManagerHome: /u02/private/oracle/config/nodemanager
 ListenAddress= 192.168.10.2
 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log
Properties Value
SecureListener Set the value to "false".
StartScriptEnabled Set the value to "true",
StopScriptEnabled Set the value to "true",
StopScriptName Specify a name for the stop script, for example stopWebLogic.sh.
DomainsFile /u02/private/oracle/config/nodemanager/nodemanager.domains

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

次のディレクトリにあるstartNodeManager.shを使用することで、SOAHOST1およびSOAHOST2でノード・マネージャを起動します。

/u02/private/oracle/config/nodemanager

たとえば、次のコマンドをSOAHOST1およびSOAHOST2で実行します。

./startNodeManager.sh

12.3 ノード・マネージャに対するホスト名検証証明書の有効化

この項では、ノード・マネージャと管理サーバーとの間の通信用のホスト名検証証明書を設定する方法を説明します。これは、次の手順で構成されています。

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

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

  1. 必要なホスト名を証明書ストアに追加します(それらがHOST.mycompany.comおよびVIP.mycompany.comとは異なる場合)。

  2. ノード・マネージャ(ノード・マネージャによって追加のホスト名が使用される場合)またはサーバー(管理対象サーバーによって追加のホスト名が使用される場合)のアイデンティティおよび信頼ストアの場所情報を変更します。

次の手順に従って、HOST上に自己署名証明書を作成します。これらの証明書は、ネットワーク名または別名を使用して作成する必要があります。信頼できるCA証明書を使用する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverの保護のアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comおよびVIP.mycompany.com用の証明書を構成します。つまり、物理ホスト名(HOST)と仮想ホスト名(VIP)の両方がHOSTで使用されていると想定しています。また、HOST.mycompany.comがノード・マネージャによって使用されるアドレスであり、VIP.mycompany.comが管理対象サーバーまたは管理サーバーによって使用されるアドレスであると想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノード、または2つの管理対象サーバーが共存してそのうちの1つのサーバーが物理ホスト名でリスニングして1つのサーバーが仮想ホスト名を使用する(これは移行サーバーを使用するサーバーの場合)ノードによくある状況です。

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

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

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

    echo $CLASSPATH
    
  2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリの下のcertsという名前のディレクトリを作成します。証明書は、複数のWebLogicドメインで共有できることに注意してください。

    cd ASERVER_HOME
    mkdir certs
    

    注意:

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


  3. ディレクトリを、先ほど作成したディレクトリに変更します。

    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]

    例:

    java utils.CertGen Key_Passphrase SOAHOST1.mycompany.com_cert SOAHOST1.mycompany.com_key domestic SOAHOST1.mycompany.com
    
    java utils.CertGen Key_Passphrase SOAHOST2.mycompany.com_cert SOAHOST2.mycompany.com_key domestic SOAHOST2.mycompany.com
    
    java utils.CertGen Key_Passphrase ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com
    
    java utils.CertGen Key_Passphrase OUDADMINVHN.mycompany.com_cert OUDADMINVHN.mycompany.com_key domestic OUDADMINVHN.mycompany.com
    

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

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

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


    注意:

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


  2. SOAHOST1.mycompany.comSOAHOST2.mycompany.comおよびADMINVNH.mycompany.comの証明書および秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートされた証明書と鍵のペアごとに異なる別名を使用するようにしてください。

    構文(すべてを1行で指定します):

    java utils.ImportPrivateKey Keystore_File Keystore_Password 
    Certificate_Alias_to_Use Private_Key_Passphrase
    Certificate_File
    Private_Key_File

    [Keystore_Type]

    例:

    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentitySOAHOST1 Key_Passphrase ASERVER_HOME/certs/SOAHOST1.mycompany.com_cert.pem ASERVER_HOME/certs/SOAHOST1.mycompany.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentitySOAHOST2 Key_Passphrase ASERVER_HOME/certs/SOAHOST2.mycompany.com_cert.pem ASERVER_HOME/certs/SOAHOST2.mycompany.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityADMVHN Key_Passphrase ASERVER_HOME/certs/ADMINVNH.mycompany.com_cert.pem ASERVER_HOME/certs/ADMINVNH.mycompany.com_key.pem
    

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

次の手順に従って、各ホスト、SOAHOST1およびSOAHOST2に信頼キーストアを作成します。

  1. 標準Javaキーストアには、必要なルートCA証明書の大部分がすでに含まれているため、それをコピーして新しい信頼キーストアを作成します。標準Java信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリの下に配置されている標準JavaキーストアCA証明書を、その証明書と同じディレクトリにコピーします。次に例を示します。

    cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStoreSOAHOST1.jks
    
  2. 標準Javaキーストアのデフォルト・パスワードはchangeitです。デフォルト・パスワードは常に変更することをお薦めします。これを行うには、keytoolユーティリティを使用します。構文は次のとおりです。

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

    次に例を示します。

    keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreSOAHOST1.jks -storepass changeit
    
  3. CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書に署名するために使用します。これは、WL_HOME/server/libディレクトリに配置されています。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

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

    次に例を示します。

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreSOAHOST1.jks -storepass Key_Passphrase
    

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

SOAHOST1およびSOAHOST2上の次のディレクトリに配置されているnodemanager.propertiesファイルを編集することで、カスタム・キーストアを使用するようにノード・マネージャを構成します。

/u02/private/oracle/config/nodemanager_directory

次の行をnodemanager.propertiesファイルに追加します。

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

次に例を示します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ASERVER_HOME/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=Key_Passphrase
CustomIdentityAlias=appIdentitySOAHOST1
CustomIdentityPrivateKeyPassPhrase=Key_Passphrase

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

12.3.5 共通または共有記憶域インストールの使用方法

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

各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2

注意:

必ず、たとえば、...HOST1にappIdentity1、...HOST2にappIdentity2のように、各ホストそれぞれに割り当てられたカスタム・アイデンティティ別名を指定してください。


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

次の手順に従って、WLS_SERVERのアイデンティティおよび信頼キーストアを構成します。

  1. 第8.18.2項「Oracle Traffic Directorを介したアクセスの検証」に示すURLにあるOracle WebLogic Server管理コンソールにログインします。

  2. 「ロックして編集」をクリックします。

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

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

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

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

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

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

    • カスタムIDキーストア: 次のようなアイデンティティ・キーストアの完全修飾パス。

      ASERVER_HOME/certs/appIdentityKeyStore.jks
      
    • カスタムIDキーストアのタイプ: 空白のままにします。デフォルトのJKSになります。

    • カスタムIDキーストアのパスフレーズ: 第12.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じてオプションの場合も必須の場合もあります。すべてのキーストアで、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

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

    • カスタム信頼キーストア: 次のような信頼キーストアの完全修飾パス。

      ASERVER_HOME/certs/appTrustKeyStoreSOAHOST1.jks
      
    • カスタム信頼キーストアのタイプ: 空白のままにします。デフォルトのJKSになります。

    • カスタム信頼キーストアのパスフレーズ: 第12.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」New_Passwordとして指定したパスワード。この属性は、キーストアのタイプに応じてオプションの場合も必須の場合もあります。すべてのキーストアで、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

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

  11. 管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックし、変更を有効化します。

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

  13. 「ロックして編集」をクリックします。

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

    • wls_oam1の場合、appIdentitySOAHOST1を使用します。

    • wls_oam2の場合、appIdentitySOAHOST2を使用します。

    • ADMINSERVERの場合、ユーザーappIdentityADMVHN

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

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

  16. 管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックし、変更を有効化します。

  17. 第8.5.3項「SOAHOST1での管理サーバーの起動」の説明に従って、変更を適用したサーバーを再起動します。

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

前述の手順を実行したら、影響を受ける管理対象サーバーのホスト名検証をBea Hostname Verifierに設定します。これを行うには、次の手順を実行します。

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

  2. チェンジ・センターから「ロックして編集」を選択します。

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

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

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

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

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

  8. ホスト名検証をBea Hostname Verifierに設定します。

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

  10. 「変更のアクティブ化」をクリックします。

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

次のディレクトリにあるstartNodeManager.shを実行することで、SOAHOST1およびSOAHOST2でノード・マネージャを起動します。

/u02/private/oracle/config/nodemanager

ノード・マネージャを起動するには、次のコマンドをSOAHOST1およびSOAHOST2で実行します。

./startNodeManager.sh

注意:

まだ、ノード・マネージャの構成も起動もしていない場合は、setNMProps.shを実行します。これによって、Fusion Middleware SOAコンポーネントに必要な起動スクリプトの使用が可能になります。



注意:

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

<Loading identity key store:
  FileName=ASERVER_HOME/certs/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>

サーバーにテスト構成変更を適用し、ノード・マネージャによってSSLエラーが報告されることなくそれが続行される場合、ホスト名検証は機能しています。