addNode コマンド

addNode コマンドは、アプリケーション・サーバー・インストール・システムをセルに取り込みます。

セルに取り込んでいる新規ノードのサイズと場所によっては、 このコマンドが完了するまでに数分かかることがあります。

[z/OS][AIX Solaris HP-UX Linux Windows] addNode 関数を使用するには、 管理者特権 が必要です。

[IBM i]ユーザー・プロファイルには、*ALLOBJ 権限か、addNode Qshell スクリプトに対する読み取り権限および実行権限が必要です。

ノード・エージェント・サーバーは、 -noagent オプションを指定しない限り、 addNode コマンドの一部として自動的に開始されます。 アプリケーション・サーバー・ノードをホストするシステムをリサイクルする際に、 ノード・エージェントがオペレーティング・システム・デーモンとして機能するように設定しなかった場合は、 すべてのアプリケーション・サーバーを始動する前に、startNode コマンドを実行してノード・エージェントを始動する必要があります。

addNode コマンドを実行すると、コマンドによって、セルに取り込んでいる実行中のアプリケーション・サーバーが停止します。 オプションで、そのアプリケーション・サーバーを addNode コマンドを実行する前に停止しておくことができます。

[Windows]セルにノードを追加する前にサーバーに関連付けられていた既存の Windows サービスは、 addNode コマンドを実行すると削除されます。 そのノードをあとでセルから除去しても、基本サーバーに関連付けられていた Windows サービスは自動では再作成されません。 この製品で Windows サービスを作成するには、 WASService コマンドに関する情報を参照してください。

この製品は、ノードが追加されたときにポートを生成する場合があります。 ポート生成には、 以下の項目が当てはまります。
  • ノード・エージェント用に生成されるポートは、 インストール・システム内のすべてのプロファイルで固有になっています。 開発目的の場合、同一システム上に複数のプロファイルを作成し、 ポートの競合を気にすることなくそれらを 1 つ以上のセルに追加することができます。
  • ノード・エージェントが使用するポートを指定する場合は、ファイル内でポートを指定し、 そのファイルの名前を -portprops オプションで渡してください。 そのファイルのフォーマットは、各行に 1 つの key=value のペアで、その鍵は、serverindex.xml ファイルのポート名と同じです。
  • 多数の順次ポートを使用したい場合、 -startingport オプションを検討してください。 これは、他のプロファイルとのポート競合が 検出されないことを意味します。
ベスト・プラクティス: addNode コマンドに -includeapps オプションを使用して、環境が同じバージョンのアプリケーションで開始されるようにします。 addNode コマンドの実行前にサーバー上に任意のカスタム・ポリシー・セットを作成した場合、そのカスタム・ポリシー・セットは addNode コマンドの実行が完了した際に新規セルにコピーされません。 したがって、-installApps オプションを使用している場合、そのサーバー上のカスタム・ポリシー・セットを使用しているアプリケーションは、addNode コマンドの実行後にポリシー・セットをロードできなくなります。 addNode コマンドの実行前にスタンドアロン・サーバーからカスタム・ポリシー・セットをエクスポートし、addNode コマンドの実行後にそのカスタム・ポリシー・セットを新規セルにインポートすることができます。

プロファイルまたはアプリケーション・サーバー・ルート・ディレクトリーのどちらからこのコマンドを 実行するのかを決定するには、コマンド行ツールの使用に関するトピックを参照してください。

構文

以下のコマンド構文を参照してください。

[z/OS][AIX Solaris HP-UX Linux Windows]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses]
[-startingport portnumber] [-portprops qualified_filename]
[-nodeagentshortname name] [-nodegroupname name] [-registerservice]
[-serviceusername name] [-servicepassword password] [-coregroupname name]
[-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile filename]
[-replacelog] [-trace] [-username uid] [-password pwd]
[-localusername localuid] [-localpassword localpwd] [-profileName profilename]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]
[IBM i]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses name]
[-startingport portnumber] [-portprops qualified_filename] 
[-nodeagentshortname name] [-nodegroupname name] [-registerservice] 
[-serviceusername name] [-servicepassword password] [-coregroupname name] 
[-noagent] [-statusport port] [-quiet] [-nowait] [-logfile filename] 
[-replacelog] [-trace] [-username uid] [-password pwd] 
[-localusername localuid] [-localpassword localpwd] [-profileName profilename]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]

dmgr_host 引数は 必須です。 それ以外の引数はすべてオプションです。 デプロイメント・マネージャーのデフォルト SOAP ポートの ポート番号は、デフォルトでは 8879 です。 SOAP は、コマンドのデフォルトの Java™ Management Extensions (JMX) コネクター・タイプです。 製品が複数インストールされている場合、 あるいは複数のプロファイルがある場合は、SOAP ポートが 8879 以外になることがあります。 現在使用中のポートを確認するには、デプロイメント・マネージャーの SystemOut.log ファイルを調べてください。

注: このトピックでは、1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。 推奨される代替方法として、分散システムおよび IBM® i システムで SystemOut.logSystemErr.logtrace.log、および activity.log ファイルを使用する代わりに、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成することができます。 HPEL は、ネイティブ z/OS® ロギング機能と組み合わせて使用することもできます。 HPEL を使用する場合、すべてのログとトレース情報にアクセスするには、サーバー・プロファイルの bin ディレクトリーから、LogViewer コマンド行ツールを使用します。 HPEL の使用について詳しくは、 HPEL の使用に関する情報 を参照してアプリケーションのトラブルシューティングを行ってください。

パラメーター

addNode コマンドで使用可能なオプションは、以下のとおりです。

-conntype <type>
デプロイメント・マネージャーへの接続に使用する JMX コネクター・タイプを指定します。 SOAP は、コマンドのデフォルトの Java Management Extensions (JMX) コネクター・タイプです。 他の有効なタイプには、JSR160RMI やリモート・メソッド呼び出し (RMI) があります。
-includeapps
デフォルトで、addNode コマンドは、 新規ノード上のスタンドアロン・サーバーのアプリケーションをセルに引き継ぎません。 通常の場合は、アプリケーションはデプロイメント・マネージャーを使用してインストールしてください。 -includeapps は、addNode コマンドのオプションで、ノードからアプリケーションを引き継ぎます。 アプリケーションが既にセルに存在する場合、 警告が印刷され、アプリケーションはそのセルにインストールされません。

アプリケーションは、addNode コマンドを使用して統合したサーバーへマップされます。 addNode コマンド・オペレーションが完了すると、サーバー始動時にアプリケーションはそのサーバー上で稼働します。 これらのアプリケーションは、Network Deployment セルの一部なので、管理コンソールを使用して、セル内の他のサーバーおよびクラスターへマップすることが可能です。 詳しくは、モジュールからサーバーへのマッピングについての項目をお読みください。

統合するノードにサンプルなどの製品提供のアプリケーションが含まれている場合は、-includeapps オプションは使用しないでください。 使用すると、 2 番目に統合されるノードにこれらのアプリケーションが含まれている場合、そのノードは 拒否されます。それらのアプリケーションはセル内に存在し、アプリケーションのマージは サポートされていないためです。

多数のアプリケーションを含むノードで -includeapps オプションを 使用する場合は、addNode オペレーション中に すべてのアプリケーションをデプロイメント・マネージャーに転送し、 リモート側でそれらのアプリケーションをセルにインストールするのに必要な追加時間を確保するために、管理コネクターのタイムアウトを延長する必要があります。 ノード上に固有のアプリケーションが ごくわずかしか存在しない場合を除き、-includeapps オプションを使用する方法は お勧めしません。

[z/OS][AIX Solaris HP-UX Linux Windows]デフォルトでは、アプリケーションのインストール時に、アプリケーション・バイナリーは app_server_root/installedApps/cellName ディレクトリーに解凍されます。 addNode コマンドの実行後、追加したノード上の構成のセル名は、 ベース・セル名からデプロイメント・マネージャー・セル名に 変更されます。 アプリケーション・バイナリー・ファイルは、addNode コマンドの実行前に それがあった場所 (例えば app_server_root/installedApps/old_cellName) にあります。

[IBM i]デフォルトでは、アプリケーションのインストール時に、アプリケーション・バイナリー・ファイルは profile_root/installedApps/cellName ディレクトリーに解凍されます。 addNode コマンドの実行後、追加したノード上の構成のセル名は、 ベース・セル名からデプロイメント・マネージャー・セル名に 変更されます。 アプリケーション・バイナリー・ファイルは、addNode コマンドの実行前の格納場所 (例えば profile_root/installedApps/old_cellName) にあります。

以下の例では、バイナリー・ファイルのロケーションを明示的に指定することによってアプリケーションがインストールされています。
${APP_INSTALL_ROOT}/${CELL}
変数 ${CELL} は、現在のセル名を指定します。 したがって、バイナリー・ファイルは、addNode コマンドが実行される際に、profile_root/installedApps/currentCellName ディレクトリーに移動します。

addNode コマンドを使用してノードをセルに統合する場合、 仮想ホスト情報を含むセル・レベルの構成はマージされません。 新規セルの仮想ホストと別名が製品に一致しない場合、 サーバー上で実行されているアプリケーションにはアクセスできません。 デプロイメント・マネージャー上で稼働している管理コンソールを使用して、 すべての仮想ホストとホスト別名を手動で新規セルに追加する必要があります。

[z/OS][AIX Solaris HP-UX Linux Windows]トラブルの回避: -includeapps パラメーターを指定した場合、Java 仮想マシン (JVM) ヒープ・サイズが小さすぎると、 OutOfMemoryError が発生する可能性があります。 このエラーが発生すると、 以下のエラー・メッセージが発行されます。
ADMU0111E: Program exiting with error: java.lang.OutOfMemoryError

大容量アプリケーションが処理された場合や、基本アプリケーション・サーバー内に大量のアプリケーションが存在する場合、このエラーが発生することがあります。

このエラーを復旧し、アプリケーション・サーバーを正常に統合するには、以下のアクションを実行します。

  1. デプロイメント・マネージャー・サーバーで、cleanupNode コマンドを発行します。 このコマンドについて詳しくは、cleanupNode コマンドの説明をお読みください。
  2. addNode スクリプト実行のために、JVM ヒープ・サイズを増やしておきます。 addNode コマンドを発行すると、JVM ヒープ・サイズは、-Xms128m -Xmx512m に設定されます。 これらの値を増やすには、-javaoption パラメーターを使用します。 例えば、以下を指定できます (1 行で記述)。[Windows]
    addNode localhost 8879 -javaoption java_option "-Xmx512m"
    [Linux][AIX]
    addNode.sh localhost 8879 -javaoption java_option "-Xmx512m"
  3. addNode コマンドを再発行します。
-includebuses
セルに統合されるノードからバスをコピーします。 このパラメーターは、 リモート・ノードのサービス統合バス構成をセルにコピーすることも試みます。 リモート・ノードのバスと同じ名前のバスが宛先セルに既に含まれている場合は、ノードの追加は失敗します。 addNode コマンドを使用する前に対処することで、この失敗を回避できます。 宛先セルにあるその名前のバスを削除するか、セルに追加するバスの 名前を変更するか、あるいは既にセル内にあるバスを手動で構成することができます。
-startingport <portNumber>
addNode コマンドの実行時に作成されるすべてのノード・エージェントおよび Java Messaging Service (JMS) サーバー・ポートの基本ポート番号として使用するポート番号の指定をサポートします。 このサポートにより、デフォルトのポート値を使用するのではなく、 上記のサーバーにどのポートを定義するかを制御できるようになります。 開始ポート番号は、addNode コマンドで構成される ノード・エージェント・ポートおよび JMS サーバー・ポートごとにポート番号を計算するために、1 ユニットずつ増分されます。

[AIX Solaris HP-UX Linux Windows]ポートの競合の可能性を回避するために、デフォルトのポート設定について詳しくは、「 ポート番号の設定 」を参照してください。

同じ物理サーバー上に複数のノード・エージェントがある 場合、それぞれに対してベース・ポート番号を定義できます。そうするには、統合前に -startingport パラメーターを 使用するか、または、serverindex.xml ファイル内のノード・エージェント・セクションでポートを変更します。

-portprops <filename>
新規ノード・エージェントで使用する明示的ポートの鍵と値のペアが含まれるファイルの名前を渡します。 例えば、SOAP ポートと RMI ポートをそれぞれ 3000 と 3001 に設定するには、 以下の 2 行を含むファイルを作成し、それをパラメーターとして渡します。
SOAP_CONNECTOR_ADDRESS=3000
BOOTSTRAP_ADDRESS=3001
-nodeagentshortname <name>
新規ノード・エージェントに使用するショート・ネーム。
-nodegroupname <name>
このノードを追加するノード・グループの名前。 これを指定しない場合、 ノードは DefaultNodeGroup に追加されます。
[Windows]-registerservice
ノード・エージェントを Windows サービスとして登録します。

-serviceusername パラメーターおよび -servicepassword パラメーターを使用して、ウィンドウ・サービス用のユーザー名およびパスワードをオプションで定義できます。 ユーザー名を定義する場合、サービスを適切に実行するために、ユーザー名に「サービスとしてログオン」権限を提供する必要があります。

ユーザー名とパスワードを指定しない場合、サービスはローカル・システム・アカウント下で実行します。

[Windows]-serviceusername <user>
[Windows]指定したユーザー名を Windows サービスのユーザーとして使用します。
[Windows]-servicepassword <password>
[Windows]指定された Windows パスワードを Windows サービス・パスワードとして使用します。
-coregroupname <name>
このノードを追加するコア・グループの名前。 このオプション が指定されていない場合、ノードは DefaultCoreGroup に追加されます。
-noagent
addNode コマンドに、 新規ノードのノード・エージェント・プロセスを立ち上げないよう指示します。
-statusport
管理者がノード・エージェント状況のコールバック用のポート番号を設定できるようにするオプション・パラメーター。 ツールは、このポートを開いて、開始を示すノード・エージェントからの状況の コールバックを待機します。 このパラメーターが設定されていない場合、未使用のポートが自動的に割り振られます。
-quiet
addNode コマンドにより通常モードで印刷される進行情報を抑止します。
-nowait
addNode コマンドに、 立ち上げられたノード・エージェント・プロセスが正常に初期化されるまで待たないように指示します。
-logfile <filename>
トレース情報を書き込むログ・ファイルのロケーションを指定します。 デフォルトでは、 ログ・ファイルは addNode.log で、追加されるノードのプロファイルの logs ディレクトリーに作成されます。
-replacelog
現行ログ・ファイルに追加する代わりに、ログ・ファイルを置き換えます。 デフォルトで、addNode コマンドは、既存のトレース・ファイルへ追加されます。 このオプションにより、 addNode コマンドがトレース・ファイルを上書きします。
-trace
デバッグのために、ログ・ファイルに追加のトレース情報を生成します。
-user <name> or -username <name>
セキュリティーが使用可能な場合、 認証のためのユーザー名を指定します。 -user オプションと同様の働きをします。 選択するユーザー名は、既存のユーザー名である必要があります。
-password <password>
セキュリティーが使用可能な場合、 認証のためのパスワードを指定します。 選択するパスワードは、既存のユーザー名に関連したものである必要があります。
-localusername <name>
統合するノード上の既存のアプリケーション・サーバーに、 認証用のユーザー名を指定します。 このパラメーターは、 アプリケーション・サーバーのセキュリティーが有効になっている場合にのみ適用できます。
-localpassword <password>
統合するノード上の既存のアプリケーション・サーバーに、 認証用のパスワードを指定します。 選択するパスワードは、既存のユーザー名に関連したものである必要があります。 このパラメーターは、 アプリケーション・サーバーのセキュリティーが有効になっている場合にのみ適用できます。
-profileName
マルチプロファイル・システムで、アプリケーション・サーバー・プロセスのプロファイルを定義します。 -profileName オプションは、単一プロファイル環境で実行する場合は必要ありません。 このオプションのデフォルトは、 デフォルト・プロファイルです。 デフォルト以外の プロファイルをデプロイメント・マネージャー・セルに追加する場合は、 このパラメーターが必要です。
-excludesecuritydomains true | false
セキュリティー・ドメインを、セルに統合されたアプリケーション・サーバー・ノードで構成されないようにするには、-excludesecuritydomains パラメーターを true に設定します。 このパラメーターを true に設定すると、セルのセキュリティー構成が使用されます。 このパラメーターは、セキュリティー・ドメインを、統合されていないアプリケーション・サーバーで構成した場合にのみ適用されます。 デフォルトでは、アプリケーション・サーバーに関連付けられているセキュリティー・ドメインがある場合、そのセキュリティー・ドメインはセルに統合され、 統合後はそのサーバーは同じセキュリティー・ドメイン情報を使用します。
-asExistingNode
デプロイメント・マネージャー・セルの既存の管理対象ノードをリカバリー するように指定します。
addNode コマンド の -asExistingNode パラメーターを使用すると、損害を受けたノードが直ちに リカバリーされます。 例えば、マシン障害によってノードは 使用できなくなったが、ノード情報がデプロイメント・マネージャーに残っている場合は、 以下のステップを実行すれば、addNode -asExistingNode オプションを使用して、使用不可に なったノードを再作成できます。
  1. 使用不可になったノードと同じノードおよびプロファイル名で、新しいプロファイルを作成します。 このプロファイルは、元のノードと異なるマシン上に 作成できます。
  2. この新しいプロファイルに対して、-asExistingNode オプションを 指定して addNode コマンドを実行します。

addNode コマンドの -asExistingNode オプションを使用して、同じパスの別のコンピューター上の製品インストール済み環境へのノードの移動、異なるパスの別のオペレーティング・システム上の製品インストール済み環境へのノードの移動、またはテンプレート・セルからのセルの作成が行えます。 addNode -asExistingNode コマンドを使用するノードのリカバリーまたは移動に関するトピックを参照してください。

問題の回避: ノード構成の他の addNode オプションは、この-asExistingノード・オプションと互換性がありません。 非互換オプションである -includeapps、-includebuses、-startingport、-portprops、-nodeagentshortname、 -nodegroupname、-registerservice、-serviceusername、-servicepassword、 -coregroupname、-excludesecuritydomains オプションを -asExistingNode と一緒に使用しないでください。
-help
使用ステートメントを出力します。
-?
使用ステートメントを出力します。

使用のシナリオ

以下は、正しい構文の例です。
addNode testhost 8879 (adds an application server to the deployment manager)

addNode deploymgr 8879 -trace (produces the addNode.log file)

addNode host25 8879 -nowait (does not wait for a node agent process)
8879 はデフォルトのポートです。
[IBM i]
addNode mydmgr 11383 -profileName mynode (adds profile, mynode, to the cell managed by profile mydmgr, which listens on SOAP port 11383)

アプリケーション・サーバー・ノードを WebSphere Application Server Network Deployment セルに追加する際のセキュリティーに関する考慮事項

[AIX Solaris HP-UX Linux Windows][IBM i]セルにノードを追加すると、セルのユーザー・レジストリーと認証メカニズムの両方が自動的に継承されます。

[z/OS]セルにノードを追加すると、新規統合ノードは、既存の WebSphere Application Server Network Deployment セルのユーザー・レジストリー (ローカル OS、Lightweight Directory Access Protocol (LDAP)、またはカスタム)、認証メカニズム (LTPA)、および許可設定 (WebSphere® バインディングまたは System Authorization Facility (SAF) EJBROLE プロファイル) を自動的に継承します。

分散セキュリティーでは、セル内のすべてのサーバーが同じユーザー・レジストリーと認証メカニズムを使用しなければなりません。 ユーザー・レジストリーの変更からリカバリーするには、アプリケーションを変更して、ユーザーおよびグループのロールへのマッピングが新しいユーザー・レジストリーに関して正しくなるようにする必要があります。 ロールへのユーザーおよびグループの割り当てに関する項を参照してください。

もう 1 つの重要な考慮事項は、Secure Sockets Layer (SSL) 公開鍵インフラストラクチャーです。 デプロイメント・マネージャーを使用して addNode を実行する前に、 addNode コマンドが SSL クライアントとしてデプロイメント・マネージャーと通信できることを確認してください。 この通信のためには、sas.client.props ファイルで構成される addNode トラストストアに、鍵ストアに入っていて、 管理コンソールで指定されるデプロイメント・マネージャー個人証明書の署名者証明書が含まれている必要があります。

addNode コマンドをセキュリティーを介して実行する際に考慮する必要がある問題を以下に示します。
  • addNode コマンドなどのシステム管理コマンドを実行する場合は、 その操作を実行するための管理クレデンシャルを指定します。 addNode コマンドは、ユーザー ID とパスワードを指定するのに、-username パラメーターと -password パラメーターを受け入れます。 指定するユーザー ID およびパスワードは、管理ユーザーのものである必要があります。 例えば、管理者の特権を持っているか、 ユーザー・レジストリーで構成されている管理ユーザー ID を持っているコンソール・ユーザーのメンバーを指定します。 以下の addNode コマンドの例を参照してください。
    addNode CELL_HOST 8879 -includeapps -username user -password pass

    -includeapps パラメーターはオプションです。 このオプションはサーバー・アプリケーションをデプロイメント・マネージャーに組み込もうとします。 アプリケーション・サーバーが使用するユーザー・レジストリーと、 デプロイメント・マネージャーが使用するユーザー・レジストリーが同一でなければ、 addNode コマンドは失敗します。 この障害を解決するには、ユーザー・レジストリーを同一にするか、セキュリティーをオフにします。 ユーザー・レジストリーを変更する場合は、 ユーザーのロールへのマッピングとグループのロールへのマッピングが正しいことを必ず確認してください。 addNode 構文について詳しくは、addNode コマンドに関する項をお読みください。

    [z/OS]セキュリティーを有効にして addNode コマンドを発行する場合は、権限を持つユーザー ID を使用し、-user および-password オプションを指定する必要があります。

  • 管理コンソールを使用したセキュア・リモート・ノードの追加は、サポートされていません。 リモート・ノード上のセキュリティーを使用不可にしてからこの操作を実行するか、 あるいは addNode スクリプトを使用してコマンド・プロンプトから操作を実行してください。
  • [z/OS] addNode コマンドを実行する前に、ノード上のトラストストア・ファイルが、デプロイメント・マネージャーが所有する鍵ストア・ファイルおよび System Authorization Facility (SAF) 鍵リングと通信していること、およびその逆であることを確認する必要があります。 ノード・エージェント・プロセスで使用したものと同じ認証局を使用して デプロイメント・マネージャーの証明書を生成した場合、問題は発生しません。 以下の SSL 構成には、 相互運用可能な鍵ストアおよびトラストストアが含まれる必要があります。
    • 管理コンソールで指定された、システム SSL レパートリー。 「システム管理」 > 「デプロイメント・マネージャー」 > 「HTTP トランスポート」 > sslportno > 「SSL」をクリックします。
    • 適切な JMX コネクターの SSL レパートリー (SOAP が指定されている場合)。 「システム管理」 > 「デプロイメント・マネージャー」 > 「管理サービス」 > 「JMX コネクター」 > 「SOAPConnector」 > カスタム・プロパティー > sslConfigをクリックします。
    • NodeAgent で指定された SSL レパートリー。 「システム管理」 > 「ノード・エージェント」 > NodeAgent Server > 「管理サービス」 > JMX コネクター > SOAPConnector > カスタム・プロパティー > sslConfigをクリックします。

    [z/OS]異なるセキュリティー・ドメインを定義するデプロイメント・マネージャー構成にノードを追加する場合、注意が必要です。

  • [AIX Solaris HP-UX Linux Windows][IBM i] addNode コマンドを実行する前に、ノード上のトラストストア・ファイルがデプロイメント・マネージャーからの鍵ストア・ファイルと通信できること、およびその逆を確認する必要があります。 デフォルトの DummyServerKeyFile および DummyServerTrustFile を使用する場合は、既に通信可能になっているため、通信エラーは発生しません。 ただし、これらのダミー・ファイルは、実稼働環境や機密データを送信する場合には決して使用しないでください。
  • セキュリティーがバージョン 7 または 8 のデプロイメント・マネージャーで使用可能な場合、バージョン 6.x ノードをフェデレートするために、デプロイメント・マネージャーは自動生成された内部サーバー ID を使用できません。 自動生成された内部サーバー ID は、セキュリティーを使用可能にするときにデフォルトで使用されます。
  • 以前のリリースのクライアントから addNode コマンドを使用してバージョン 7 または 8 のデプロイメント・マネージャーを統合する場合は、 ハンドシェークを正常に行うために、 まずクライアントが署名者を取得する必要があります。 このシナリオで addNode コマンドを実行する前の必要な変更について詳しくは、 クライアント取得のための安全なインストールに関するトピックに含まれている、前のリリースからの署名者の取得についての説明をお読みください。 特に、前のリリースからのクライアントおよびサーバーの署名者の取得に 関するセクションを参照してください。 ユーザー・レジストリーは、以下のアクションのいずれか 1 つを実行して変更することができます。
    • 管理コンソールで、「グローバル・セキュリティー」をクリックします。 「使用可能なレルム定義 (Available realm definitions)」の下で、 構成 > リポジトリーに保管されているサーバー IDをクリックします。 ユーザー名とパスワードを入力し、「適用」をクリックします。
    • wsadmin コマンドを実行します。
      AdminTask.configureAdminWIMUserRegistry('[-autoGenerateServerId false -serverId testuser
       -serverIdPassword testuserpwd -primaryAdminId testuser -ignoreCase true ]')
    これらの変更を有効にするためには、サーバーを再始動する必要があります。
  • addNode コマンドを実行すると、アプリケーション・サーバーは新しい SSL ドメインに入ります。 そこには、鍵ストア・ファイルおよびトラストストア・ファイルを指す SSL 構成が含まれている場合がありますが、これらのファイルは、同一ドメイン内の別のサーバーとの相互運用には対応していません。 サーバーの相互通信関係を考慮し、それらのサーバーがトラストストア・ファイル内で信頼されていることを確認してください。