addNode -asExistingNode コマンドを使用したノードのリカバリーまたは移動
addNode コマンドの -asExistingNode オプションを使用すると、デプロイメント・マネージャーのノードをリカバリーまたは移動することができます。 -asExistingNode オプションを使用すると、新規カスタム・ノードが既存のノードとしてデプロイメント・マネージャーに統合されます。 統合の際、本製品はデプロイメント・マネージャーのマスター構成の情報を使用して、カスタム・ノードを既存のノードに変換します。
始める前に
このトピックでは、1 つ以上の管理対象ノードを持つデプロイメント・マネージャーが WebSphere® Application Server Network Deployment 製品に含まれていることを前提としています。
このタスクについて
addNode コマンドの -asExistingNode オプションを使用すると、損傷したノードを迅速にリカバリーしたり、別のコンピューター上の同じパスにある製品インストール済み環境にノードを移動したり、異なるオペレーティング・システムまたは異なるパスにある製品インストール済み環境にノードを移動したり、テンプレート・セルからセルを作成したりすることができます。
以下の手順は、-asExistingNode オプションの使い方を説明しています。
- デプロイメント・マネージャーの既存の管理対象ノードをリカバリーします。
- 別のコンピューター上の同じパスにある製品インストール済み環境にノードを移動します。
- 異なるオペレーティング・システムまたは異なるパスにある製品インストール済み環境にノードを移動します。
- テンプレート・セルからセルを作成します。

- -includeapps
- -includebuses
- -startingport
- -portprops
- -nodeagentshortname
- -nodegroupname
- -registerservice
- -serviceusername
- -servicepassword
- -coregroupname
- -excludesecuritydomains
addNode コマンドに -asExistingNode オプションを指定して実行すると、本製品はポート間の競合の検査やその解決を行いません。 ノードと関連付けられているポートが、ターゲット・ホストで既に使用されているポートと競合しないことを確認する必要があります。
手順
- デプロイメント・マネージャーの既存の管理対象ノードをリカバリーします。
addNode コマンドの -asExistingNode オプションを使用すると、損傷した既存のノードをリカバリーできます。 例えば、コンピューター障害によってノードが使用不可になっても、ノード情報がデプロイメント・マネージャーに残っている場合は、使用不可になったノードを -asExistingNode オプションを使用して再作成できます。
- 既存の損傷したノードが実行中ではないことを確認します。 ノード・エージェントを停止します。ノード上にアプリケーション・サーバーが存在する場合はそれもすべて停止します。
- 元のプロファイルを削除し、損傷したノードを置き換えるためにプロファイルを作成し、そこで使用不可ノードと同じプロファイル・パス、プロファイル名、およびノード名を指定します。
あるいは、元のコンピューターが使用不可であり、同じホスト名で新規コンピューターを構成した場合は、元のノードと異なるコンピューターにプロファイルを作成することもできます。
例えば、AppSrv01 というプロファイル名を持つ myNode01 ノードが機能を停止したとします。 このノードを新しいノードで置き換えるには、 ノード myNode01 用に AppSrv01 という名前のアプリケーション・サーバー・プロファイルを作成します。
- 損傷したアプリケーション・サーバー・プロファイルの bin ディレクトリーで、コマンド行から -asExistingNode オプションを指定した addNode コマンドを実行します。
新しいノードの名前は、 -asExistingNode オプションを指定して addNode を実行するノードの名前と一致していなければなりません。
- コマンド・プロンプトを開き、アプリケーション・サーバー・プロファイルの bin ディレクトリーに移動します。 例えば、アプリケーション・サーバー・プロファイル AppSrv01 の場合、profile_root/AppSrv01/bin ディレクトリーに移動します。
- addNode コマンドに -asExistingNode オプションを指定して実行し、アプリケーション・サーバー・ノードを新規ノードに置き換えます。
以下のコマンド例では、セキュリティーが使用可能になっていて、本製品によってユーザー名とパスワードの入力を求められることを想定しています。
dmgr_host および dmgr_port に対して、デプロイメント・マネージャーのホスト名およびポート番号を指定します。
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
制約事項: 以前にインストールされた JCA アダプターは、WebSphere 構成の一部として保管されません。ノードを置き換えた後、JCA アダプターを再インストールして、新しい環境で作動するようにしてください。 - セル内の他のすべてのアクティブ・ノードを同期化します。
- アクティブ・ノードを同期化する最も簡単かつ効率的な方法は、自動同期を実行可能にすることです。 デフォルトでは、自動同期が使用可能になっていて、ノードは構成された間隔で自動同期を実行します。
- 自動同期が使用可能でない場合は、ノードを明示的に同期化できます。
- 「システム管理」 > 「ノード」とクリックします。
- 「ノード (Nodes)」ページで同期化されないノードを選択し、「同期化 (Synchronize)」をクリックします。
同期化されないノードが 5 つを超える場合、一度に 5 つのノードだけを同期化します。
デプロイメント・マネージャー管理コンソールを使って管理対象ノードをリカバリーする方法については、ノードの追加、管理、および除去に関するトピックを参照してください。
- 別のコンピューター上の同じパスにある製品インストール済み環境にノードを移動します。
以下の設定が別のコンピューターでも同じ場合、-asExistingNode オプションを使用してノードを別のコンピューターに移動できます。
- WebSphere Application Server インストール・ディレクトリー
- プロファイル名
- プロファイル・ディレクトリー
- ノード名
この手順には、3 つの異なるプロファイルが関係します。
- deployment manager profile。これは、デプロイメント・マネージャーのプロファイルです。 changeHostName コマンドをデプロイメント・マネージャーのプロファイルから実行します。
- source profile。これは、移動元にある元のプロファイルです。
- destination profile。これは、別のコンピューターに移動するプロファイルです。
- 移動するノード (ソース・プロファイル) が稼働していないことを確認します。 ノード・エージェントを停止します。ノード上にアプリケーション・サーバーが存在する場合はそれもすべて停止します。
- デプロイメント・マネージャーに存在するマスター構成内のノードのホスト名を変更します。
以下のステップを実行します。このステップには、デプロイメント・マネージャー・プロファイルが関係します。
- コマンド・プロンプトを開き、デプロイメント・マネージャー・プロファイルの bin ディレクトリーに移動します。 例えば、デプロイメント・マネージャー・プロファイルに Dmgr01 という名前が付いている場合、 profile_root/Dmgr01/bin ディレクトリーに移動します。
- ノードのホスト名を変更する wsadmin Jython コマンドを実行します。
以下のコマンド例では、セキュリティーが使用可能になっていて、本製品によってユーザー名とパスワードの入力を求められることを想定しています。
new_host_name に、ターゲット・コンピューターのホスト名を指定します。
wsadmin -lang jython -userName user_name -password password AdminTask.changeHostName('[-hostName new_host_name -nodeName node_name]') AdminConfig.save() quit
- ノードをソース・コンピューター上の製品インストール済み環境からターゲット・コンピューター上の製品インストール済み環境に移動します。
ターゲット・コンピューターで以下のステップを実行します。このステップには、宛先プロファイルが関係します。
- ソース・コンピューター上の製品インストール・ディレクトリーと同じ名前を持つディレクトリーに WebSphere Application Server をインストールします。
- 移動するノードのプロファイルと同じプロファイル名、プロファイル・ディレクトリー、およびノード名を持つカスタム・プロファイルを作成します。 カスタム・プロファイルを作成する際、ノードを後で統合することを選択します。 プロファイルの作成中にノードを統合するという選択は行わないでください。
- コマンド・プロンプトを開き、アプリケーション・サーバー・プロファイルの bin ディレクトリーに移動します。 例えば、アプリケーション・サーバー・プロファイルに AppSrv01 という名前が付いている場合、profile_root/AppSrv01/bin ディレクトリーに移動します。
- addNode コマンドに -asExistingNode オプションを指定して実行し、アプリケーション・サーバー・ノードを、移動するノードに置き換えます。
以下のコマンド例では、セキュリティーが使用可能になっていて、本製品によってユーザー名とパスワードの入力を求められることを想定しています。
dmgr_host および dmgr_port に対して、ターゲット・デプロイメント・マネージャーのホスト名およびポート番号を指定します。
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
制約事項: 以前にインストールされた JCA アダプターは、WebSphere 構成の一部として保管されません。ノードを移動した後、JCA アダプターを再インストールして、新しい環境で作動するようにしてください。 - ターゲット・デプロイメント・マネージャーの管理コンソールまたは wsadmin を使用して、ノード上のサーバーが適切に稼働するようにします。
- ノードを始動します。 このステップには、宛先プロファイルが関係します。
- アプリケーション・サーバー・ノードのターゲット・ホスト名が組み込まれるように仮想ホスト (ホスト別名) を更新します。
- ノードのアプリケーション・サーバーを始動します。
- ノードで Secure Sockets Layer (SSL) 証明書を使用する場合は、デフォルトの証明書を変更し、ノードのホスト名を組み込みます。
SSL 証明書を作成してノードの既存の証明書を置き換える方法に関するトピックを参照してください。
- セル内の他のすべてのアクティブ・ノードを同期化します。
特定のホストに存在するアプリケーション・サーバーを使用するよう静的に構成されている他のインフラストラクチャー・コンポーネント (Web サーバーなど) の構成を更新する必要が生じることがあります。
- 異なるオペレーティング・システムまたは異なるパスにある製品インストール済み環境にノードを移動します。
-asExistingNode オプションを使用して、オペレーティング・システムが同じでホスト名とパスは異なる別のコンピューター上の製品インストール済み環境にノードを移動することができます。 また、このオプションを使用して、オペレーティング・システムは異なっていても互換性のある構成ファイルを持つ別のコンピューター上の製品インストール済み環境にノードを移動することもできます (例えば、AIX オペレーティング・システムから Windows オペレーティング・システム)。
制約事項:- スケジューラーを使用するアプリケーションは、同じホスト名でのみ作動します。 スケジュール済みのタスクにはそれぞれホスト名が組み込まれているため、ノードを移動する前に存在しているタスクは適切に機能しませんが、移動した後に作成するタスクは適切に機能します。 ノードを移動した後、ノードの移動時に存在していたスケジュール済みタスクのスケジュールをすべて変更します。
- z/OS オペレーティング・システムと非 z/OS オペレーティング・システム上の製品インストール済み環境間では、ノードは移動できません。
- 以前にインストールされた JCA アダプターは、WebSphere 構成の一部として保管されません。ノードを移動した後、JCA アダプターを再インストールして、新しい環境で作動するようにしてください。
このタスクでは、移動するノード (ソース・コンピューター) があるコンピューター上の WebSphere Application Server インストール・ディレクトリーおよびプロファイル・ディレクトリーがターゲット・コンピューター上のディレクトリーと異なることを想定しています。 ただし、ノードのプロファイル名とノード名は、ソース・コンピューターとターゲット・コンピューターの両方で同じでなければなりません。
このタスクを完了するには、別のコンピューター上の同じパスにある製品インストール済み環境にノードを移動するタスクのステップを実行します。ただし、ターゲット・コンピューターにノードを移動する前に、デプロイメント・マネージャー構成の変数マップにある各ノードの製品インストール・パスとプロファイル・パスを変更する作業は行いません。 以下に例を示します。
- デプロイメント・マネージャーの管理コンソールで、「環境 (Environment)」 > 「WebSphere 変数 (WebSphere Variables)」とクリックします。
- 「WebSphere 変数 (WebSphere Variables)」ページでノードの有効範囲を選択した後、WAS_INSTALL_ROOT 変数をクリックします。
- WAS_INSTALL_ROOT 変数の設定ページで、「値 (Value)」の設定を変更し、新しい製品インストール・パスを指定して、変更を保存します。
- 「WebSphere 変数 (WebSphere Variables)」ページで、ノードの有効範囲を選択した状態で USER_INSTALL_ROOT 変数をクリックします。
- USER_INSTALL_ROOT 変数の設定ページで、「値 (Value)」の設定を変更し、新しいプロファイル・インストール・パスを指定して、変更を保存します。
- 必要に応じてこれらのステップを繰り返して各ノードの製品インストール・パスとプロファイル・パスを変更し、ターゲット・コンピューターのパスが正しくなるようにします。
このタスクでは、製品インストール・ディレクトリーとプロファイルのディレクトリーがソース・コンピューターとターゲット・コンピューターで同じである必要はありません。
- テンプレート・セルからセルを作成します。
addNode コマンドの -asExistingNode オプションを使用すると、既存のセルからセルをより短時間で作成することができます。 新しいセルの名前は、テンプレート・セルのものと同じである必要があります。
制約事項:- スケジューラー・アプリケーションは複数の環境には対応しません。 スケジュール済みのタスクにはそれぞれホスト名が組み込まれているため、ノードを移動する前に存在しているタスクは適切に機能しませんが、移動した後に作成するタスクは適切に機能します。 ノードを移動した後、ノードの移動時に存在していたスケジュール済みタスクのスケジュールをすべて変更します。
- 環境ごとに異なるリソース (データ・ソースなど) が必要かどうかを評価する必要があります。
- 以前にインストールされた JCA アダプターは、WebSphere 構成の一部として保管されません。ノードを移動した後、JCA アダプターを再インストールして、新しい環境で作動するようにしてください。
セキュリティーが有効である場合は、新しいセル用の新しいキーとトークンの再生成が必要になる可能性があります。
- セルを作成し、それが新しい製品インストール済み環境で使用するためのテンプレート・セルになるように構成します。
- backupConfig コマンドを使ってデプロイメント・マネージャー・プロファイル構成のコピーを作成します。 この構成のコピーは、新しいインストール済み環境でデプロイメント・マネージャー構成をリストアするために使用します。
- テンプレート・セルを新しい製品インストール済み環境にコピーします。
プロビジョンされる新しい環境ごとに、以下のステップを実行します。
- WebSphere Application Server をインストールします。
- デプロイメント・マネージャーおよびアプリケーション・サーバー・ノードのプロファイルを作成します。 アプリケーション・サーバー・プロファイルは、テンプレート・セルと同じノード名でなければなりません。
- restoreConfig コマンドを使用して、デプロイメント・マネージャー・プロファイル構成をリストアします。 ローカル・モードで wsadmin を使用してデプロイメント・マネージャーのホスト名を更新します。 プロファイル・パスまたは製品インストール・パスが変更された場合、新しいパスを反映するようにデプロイメント・マネージャー・ノードの variables.xml ファイルを変更します。 必要に応じて追加のプロパティー・ファイルを更新します。 更新する必要のあるプロパティー・ファイルとして、例えば wsadmin.properties や soap.client.props があります。
- デプロイメント・マネージャー・プロファイルの各ノード構成をカスタマイズします。
例えば、以下の設定を変更します。
- ホスト名
- ポート
- 製品インストール・ディレクトリー
- プロファイル・ディレクトリー
- セキュリティー構成
- 各ノードで addNode –asExistingNode を実行します。
コマンドは各ノードから同時に実行することができます。
- コマンド・プロンプトを開き、アプリケーション・サーバー・プロファイルの bin ディレクトリーに移動します。 例えば、アプリケーション・サーバー・プロファイルに AppSrv01 という名前が付いている場合、profile_root/AppSrv01/bin ディレクトリーに移動します。
- addNode コマンドに -asExistingNode オプションを指定して実行し、アプリケーション・サーバー・ノードをターゲット・セルのノードに置き換えます。
以下のコマンド例では、セキュリティーが使用可能になっていて、本製品によってユーザー名とパスワードの入力を求められることを想定しています。
dmgr_host および dmgr_port に対して、ターゲット・デプロイメント・マネージャーのホスト名およびポート番号を指定します。
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
- 新規デプロイメント・マネージャーの管理コンソールまたは wsadmin を使用して、各ノードのサーバーが適切に稼働するようにします。
- ノードを始動します。 ノード・プロファイルから startNode コマンドを実行します。
- アプリケーション・サーバー・ノードのホスト名が組み込まれるように仮想ホスト (ホスト別名) を更新します。
- ノードのアプリケーション・サーバーを始動します。
- セルで Secure Sockets Layer (SSL) 証明書を使用する場合は、ルート鍵ストア DmgrDefaultRootStore にある自己署名ルート証明書を置き換えます。
SSL 証明書を作成してセルの既存の証明書を置き換える方法に関するトピックを参照してください。
- セル内の他のすべてのアクティブ・ノードを同期化します。
次のタスク
ターゲット・インストール済み環境にあるノードを調べ、ノード構成が正しく作動することを確認します。 必要に応じて、ソース・インストール済み環境のプロファイルを削除します。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tagt_addNode_asExistingNode
ファイル名:tagt_addNode_asExistingNode.html