この章では、Application Server のノードエージェントについて説明します。次の節で構成されています。
ノードエージェントは、ドメイン管理サーバー (DAS) をホストするマシンを含む、サーバーインスタンスをホストするすべてのマシンに必要な軽量プロセスです。ノードエージェントは次の機能を実行します。
ドメイン管理サーバーの指示により、サーバーインスタンスの起動、停止、作成、または削除を行います。
障害の発生したサーバーインスタンスを再起動します。
障害の発生したサーバーのログファイルを表示します。
各サーバーインスタンスのローカル設定リポジトリとドメイン管理サーバーの中央リポジトリを同期化します。各ローカルリポジトリには、そのサーバーインスタンスまたはノードエージェントに関する情報のみが含まれます。
次の図は、ノードエージェントの全体的なアーキテクチャーを示しています。
Application Server をインストールすると、マシンのホスト名を持つノードエージェントがデフォルトで作成されます。このノードエージェントは、実行する前に、ローカルマシン上で手動で起動する必要があります。
ノードエージェントを実行していない場合でも、サーバーインスタンスを作成および管理できます。ただし、ノードエージェントを使用してサーバーインスタンスを起動および停止するには、ノードエージェントが実行中である必要があります。
ノードエージェントは 1 つのドメインを処理します。マシンが複数のドメインで実行されるインスタンスをホストする場合は、複数のノードエージェントを実行する必要があります。
ソフトウェアの障害またはその他のエラーによって、ノードエージェントが予期せず停止する場合があります。この状況では、ノードエージェントが管理していたすべてのサーバーインスタンスは管理されなくなります。ただし、そのようなサーバーインスタンスは稼動を続けており、DAS からもアクセス可能なままです。それらのサーバーインスタンスについての情報はまだ Application Server の管理インタフェースから入手可能であり、それらのサーバーインスタンスに配備されたアプリケーションへのアクセスもまだ可能です。
ノードエージェントを再起動しても、管理対象外となったサーバーインスタンスは管理されていない状態のままです。ノードエージェントはこれらのサーバーインスタンスの管理を再開しません。ソフトウェアの障害やその他のエラーによって、管理対象外のサーバーインスタンスが予期せず停止した場合、ノードエージェントはそのサーバーインスタンスを再起動できません。
管理対象外のサーバーインスタンスが稼働を続ける必要がある場合、ノードエージェントによるそのサーバーインスタンスの管理を再開することはできません。管理対象外となったサーバーインスタンスの管理を再開するただ 1 つの方法は、ノードエージェントを再起動したあとでサーバーインスタンスを停止し、再起動することです。
次の 2 とおりの方法で、ノードエージェントの設定および配備ができます。
オンライン配備: 用いるトポロジがわかっていて、すでにドメイン用のハードウェアが設置されている場合。
オフライン配備: 完全な環境を設定する前に、ドメインとサーバーインスタンスを設定する場合。
すでにドメインのトポロジがわかっていて、ドメイン用のハードウェアが設置されている場合は、オンライン配備を使用します。
次の図は、ノードエージェントのオンライン配備の概要を示しています。
ドメイン管理サーバーをインストールして起動します。ドメイン管理サーバーが起動し、実行中になったら、オンラインまたはオフライン配備を開始します。
サーバーインスタンスをホストするすべてのマシンにノードエージェントをインストールします。
インストーラまたは asadmin create-node-agent コマンドを使用します。マシンに複数のエージェントが必要な場合は、asadmin create-node-agent を使用してエージェントを作成します。
詳細については、「ノードエージェントの作成」を参照してください。
asadmin start-node-agent コマンドを使用して、ノードエージェントを起動します。
起動すると、ノードエージェントはドメイン管理サーバー (DAS) と通信します。それが DAS に到達すると、DAS にノードエージェントに対する設定が作成されます。設定が作成されると、管理コンソールでノードエージェントを表示できます。
詳細については、「ノードエージェントの起動」を参照してください。
ドメインを設定します。サーバーインスタンスを作成し、クラスタを作成して、アプリケーションを配備します。
個々のローカルマシンを設定する前に、オフライン配備を使用してドメイン内にノードエージェントを配備します。
次の図は、オフライン配備の概要を示しています。
ドメイン管理サーバーをインストールして起動します。ドメイン管理サーバーが起動し、実行中になったら、オンラインまたはオフライン配備を開始します。
ドメイン管理サーバーにプレースホルダノードエージェントを作成します。
詳細については、「ノードエージェントのプレースホルダを作成する」を参照してください。
サーバーインスタンスとクラスタを作成して、アプリケーションを配備します。
サーバーインスタンスを作成するときは、まだ使用されていないポート番号を割り当てるようにしてください。設定がオフラインで実行されるため、作成時にはドメインでポートの競合をチェックすることができません。
サーバーインスタンスをホストするすべてのマシンにノードエージェントをインストールします。
インストーラまたは asadmin create-node-agent コマンドを使用します。ノードエージェントには、以前に作成したプレースホルダノードエージェントと同じ名前を付ける必要があります。
詳細については、「ノードエージェントの作成」を参照してください。
asadmin start-node-agent コマンドを使用して、ノードエージェントを起動します。
ノードエージェントが起動すると、ドメイン管理サーバーにバインドされ、以前にノードエージェントに関連付けられたサーバーインスタンスを作成します。
詳細については、「ノードエージェントの起動」を参照してください。
設定データは、ドメイン管理サーバーのリポジトリ (中央リポジトリ) に格納されると同時に、ノードエージェントのローカルマシンにもキャッシュされるため、これらの 2 つは同期化する必要があります。キャッシュの同期化は、常に管理ツールでの明示的なユーザーのアクションによって実行されます。
この節には、次のトピックが含まれます。
はじめてノードエージェントが起動すると、中央リポジトリの最新情報の要求をドメイン管理サーバー (DAS) に送信します。ノードエージェントが DAS に正常に接続され、設定情報を取得すると、ノードエージェントは DAS にバインドされます。
デフォルトでは、asadmin start-node-agent コマンドを使用すると、DAS と同期化せずに、リモートサーバーインスタンスが自動的に起動します。DAS によって管理されている中央リポジトリと同期化しているリモートサーバーインスタンスを起動する場合は、asadmin start-node-agent コマンドの --startinstances=false オプションを指定します。次に、asadmin start-instance コマンドを使用してリモートサーバーインスタンスを起動します。
DAS にプレースホルダノードエージェントを作成した場合、ノードエージェントがはじめて起動するときに、ノードエージェントは DAS の中央リポジトリから設定を取得します。最初の起動時に、DAS が実行されていないため、ノードエージェントが DAS に到達できない場合、ノードエージェントは停止し、バインドされないままの状態になります。
ドメインのノードエージェントの設定が変更された場合、ノードエージェントを実行するローカルマシンのノードエージェントと自動的に通信します。
DAS のノードエージェント設定を削除すると、次に同期するときにノードエージェント自体が停止し、削除待ちとしてマーク付けされます。ローカルの asadmin delete-node-agent コマンドを使用して、ノードエージェントを手動で削除します。
管理コンソールまたは asadmin ツールを使用してサーバーインスタンスを明示的に起動する場合、サーバーインスタンスは中央リポジトリと同期化されます。この同期が失敗すると、サーバーインスタンスは起動しません。
ノードエージェントが、管理コンソールまたは asadmin ツールによる明示的な要求なしにサーバーインスタンスを起動する場合、サーバーインスタンスのリポジトリキャッシュは同期しません。サーバーインスタンスは、キャッシュに格納された設定によって実行されます。リモートサーバーインスタンスのキャッシュ内にファイルを追加または削除してはいけません。
リモートサーバーインスタンスの設定は、キャッシュとして扱われ (nodeagents/na1/server1 の下にあるすべてのファイル)、Application Server によって所有されます。極端な例を挙げれば、ユーザーがリモートサーバーインスタンスのすべてのファイルを削除し、ノードエージェントを再起動すると、リモートサーバーインスタンス (server1 など) は再作成され、すべての必要なファイルは同期化されます。
次のファイルおよびディレクトリは Application Server によって同期が保たれます。
表 8–1 リモートサーバーインスタンス間で同期化されるファイルとディレクトリ
ファイルまたはディレクトリ |
説明 |
---|---|
applications |
配備されているすべてのアプリケーション。このディレクトリ (およびサブディレクトリ) は、サーバーインスタンスから参照されるアプリケーションに基づいて同期化されます。ノードエージェントはどのアプリケーションも参照しないので、アプリケーションを同期化しません。 |
config |
ドメイン全体に対する設定ファイルを格納します。実行時の一時ファイル (admch、admsn、secure.seed、. timestamp、__timer_service_shutdown__.dat など) を除いたこのディレクトリ内のすべてのファイルは、同期化されます。 |
config/config_name |
config_name という名前の設定を使用してすべてのインスタンスによって共有されるファイルを格納するためのディレクトリ。domain.xml で定義されるすべての設定に対して、このようなディレクトリが 1 つずつ存在することになります。このディレクトリ内のすべてのファイルが、config_name を使用しているサーバーインスタンスと同期化されます。 |
config/config_name/lib/ext |
Java 拡張クラスを (zip または jar アーカイブとして) 置くことができるフォルダ。これは、config_name という名前の設定を使用してサーバーインスタンスに配備されたアプリケーションによって使用されます。これらの jar ファイルは、Java 拡張メカニズムを使用してロードされます。 |
docroot |
HTTP ドキュメントルート。既定の設定では、ドメイン内のすべてのサーバーインスタンスが同じ docroot を使用します。それらのサーバーインスタンスに異なる docroot を使用させるためには、仮想サーバーの docroot プロパティーを設定する必要があります。 |
generated |
Java EE アプリケーションやモジュール用に生成されたファイル。たとえば、EJB スタブ、コンパイル済みの JSP クラス、セキュリティーポリシーファイル。このディレクトリは、applications ディレクトリと同様に同期化されます。したがって、サーバーインスタンスによって参照されるアプリケーションに対応するディレクトリのみが同期化されます。 |
lib、lib/classes |
ドメイン全体に配備されたアプリケーションに使用される共通の Java クラスファイルまたは jar および zip アーカイブを置くことができるフォルダ。これらのクラスは、Application Server のクラスローダーを使用してロードされます。クラスローダーでのロード順序は次のとおりです。lib/classes、lib/*.jar、 lib/*.zip |
lib/ext |
ドメイン全体に配備されたアプリケーションによって使用される Java 拡張クラスを (jar または zip アーカイブとして) 置くことができるフォルダ。これらの jar ファイルは、Java 拡張メカニズムを使用してロードされます。 |
lib/applibs |
依存する jar ファイルを domains/<domain_name>lib/applibs の下に配置し、libraries オプションを使用して jar ファイルへの相対パスを指定します。 たとえば、asadmin deploy --libraries commons-coll.jar,X1.jar foo.ear のようにします。 |
java-web-start |
このディレクトリ (およびサブディレクトリ) の各部分が、サーバーインスタンスから参照されるアプリケーションに基づいて同期化されます。 |
アプリケーションの --libraries 配備時属性を使用して、アプリケーションの実行時の依存関係を指定することができます。相対パス (jar の名前のみ) を指定すると、Application Server は指定したライブラリを domain-dir /lib/applibs 内で見つけようとします。
ライブラリをドメイン全体で使用できるようにするには、JAR ファイルを domain-dir/lib または domain-dir/lib/classes に配置することができます。(詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の「Using the Common Class Loader」を参照してください。) 通常この方法は、JDBC ドライバや、ドメイン内のすべてのアプリケーションによって共有されているその他のユーティリティーライブラリに対してあてはまります。
クラスタ全体またはスタンドアロンのサーバー全体で使用する場合は、jar ファイルを domain-dir/domain1/config/xyz-config/lib ディレクトリにコピーします。次に、それらの jar ファイルを、xyz-config の classpath-suffix または classpath-prefix 要素に追加します。これによって、xyz-config を使用するすべてのサーバーインスタンスの jar ファイルが同期化されます。
要約すると、次のようになります。
domains/domain1/lib - ドメイン全体スコープ、共通のクラスローダー、jar ファイルを自動的に追加。
domains/domain1/config/cluster1, config/lib - 設定全体、classpath-prefix または classpath-suffix を更新。
domains/domain1/lib/applibs - アプリケーションスコープ、アプリケーションのクラスローダーに自動的に追加。
domains/domain1/config/cluster1, config/lib/ext - http://java.sun.com/j2se/1.5.0/docs/guide/extensions/extensions.html に自動的に追加。
設定ファイル (domains/domain1/config の下) は、ドメイン全体にわたって同期化されます。スタンドアロンのサーバーインスタンス (server1) によって使用される server1-config 用に server.policy をカスタマイズする場合は、変更後の server.policy ファイルを domains/domain1/config/server1-config ディレクトリの下に配置します。
変更済みの server.policy ファイルは、スタンドアロンのサーバーインスタンス server1 とのみ同期化されます。 jvm-option を更新することも忘れないでください。次に例を示します。<java-config> ...<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server1-config/server.policy</jvm-options></java-config>
同期化の必要な大きなアプリケーションが使用環境に含まれる場合、または使用できるメモリーが制限されている場合は、JVM オプションを調整してメモリーの使用を制限できます。この調整によって、メモリー不足によるエラーを受信する可能性は低くなります。インスタンス同期化 JVM ではデフォルトの設定が使用されますが、JVM オプションを設定してそれらを変更することもできます。
INSTANCE-SYNC-JVM-OPTIONS プロパティーを使用して、JVM オプションを設定します。このプロパティーを設定するコマンドは次のとおりです。
asadmin set domain.node-agent.node_agent_name.property.INSTANCE-SYNC-JVM-OPTIONS="JVM_options"
次に例を示します。
asadmin set domain.node-agent.node0.property.INSTANCE-SYNC-JVM-OPTIONS="-Xmx32m -Xss2m"
この例では、ノードエージェントは node0、JVM オプションは -Xmx32m -Xss2m です。
詳細については、http://java.sun.com/docs/hotspot/VMOptions.htmlを参照してください。
ノードエージェントの設定にプロパティーが追加されたり変更されてもノードエージェントは自動的に同期化されないため、INSTANCE-SYNC-JVM-OPTIONS プロパティーの変更後、ノードエージェントを再起動してください。
Application Server によって同期化されたディレクトリ (applications、generated、docroot、config、lib、java-web-start) 内のファイルを、アプリケーションによって保存して読み取る必要のある場合は、doNotRemoveList フラグを使用します。この属性は、ファイルまたはディレクトリのコンマ区切りのリストをとります。アプリケーション依存ファイルは、DAS によって管理される中央リポジトリに存在していない場合でも、サーバーの起動時には削除されません。中央リポジトリに同じファイルが存在する場合は、同期化中に上書きされます。
INSTANCE-SYNC-JVM-OPTIONS プロパティーを使用して、doNotRemoveList 属性に渡します。
次に例を示します。
<node-agent name="na1" ...>
...
<property name="INSTANCE-SYNC-JVM-OPTIONS" value="-Dcom.sun.appserv.doNotRemoveList=applications/j2ee-modules/<webapp_context>/logs,generated/mylogdir"/>
</node–agent>
各ノードエージェントには、固有のログファイルがあります。ノードエージェント関連の問題がある場合、次の場所にあるログファイルを参照します。
node_agent_dir /node_agent_name/agent/logs/server.log です。
ノードエージェントログにより、サーバーのログを参照して問題に関する詳細なメッセージを調べるように指示される場合もあります。
サーバーログの場所は以下のとおりです。
node_agent_dir/node_agent_name/ server_name/logs/server.log
node_agent_dir のデフォルトの位置は install_dir/nodeagents です。
一部のノードエージェントタスクについては、ノードエージェントを実行するシステムでローカルに asadmin ツールを使用する必要があります。その他のタスクは、管理コンソールまたは asadmin を使用してリモートで実行できます。
次の表は、タスクとそれを実行する場所の概要です。
表 8–2 ノードエージェントタスクの実行方法
作業 |
管理コンソール |
asadmi コマンド |
---|---|---|
ノードエージェントのプレースホルダをドメイン管理サーバーに作成します。 |
「新しいノードエージェントのプレイスホルダ」ページ。 |
create-node-agent-config |
ノードエージェントを作成します。 |
使用不可 |
create-node-agent |
ノードエージェントを起動します。 |
使用不可 |
start-node-agent |
ノードエージェントを停止します。 |
使用不可 |
stop-node-agent |
ドメイン管理サーバーからノードエージェント設定を削除します。 |
「ノードエージェント」ページ。 |
delete-node-agent-config |
ローカルマシンからノードエージェントを削除します。 |
使用不可 |
delete-node-agent |
ノードエージェント設定を編集します。 |
「ノードエージェント」ページ。 |
set |
ノードエージェントを一覧表示します。 |
「ノードエージェント」ページ。 |
list-node-agents |
既存のノードエージェントが存在しなくても、ノードエージェントのプレースホルダを使用して、サーバーインスタンスを作成および削除することができます。ノードエージェントのプレースホルダは、ノードエージェント自体がノードエージェントのローカルシステムに作成される前に、ドメイン管理サーバー (DAS) 上に作成されます。
ノードエージェントのプレースホルダの作成については、「ノードエージェントのプレースホルダを作成する」を参照してください。
プレースホルダノードエージェントを作成すると、それを使用してドメインにインスタンスを作成できます。ただし、インスタンスを起動する前に、asadmin コマンドを使用して、インスタンスが配置されるマシン上に実際のノードエージェントをローカルに作成し、起動する必要があります。詳細については、「ノードエージェントの作成」および 「ノードエージェントの起動」を参照してください。
ノードエージェントは、リモートマシンで実行されているサーバーインスタンスのローカルウォッチドッグです。このため、ノードエージェントはサーバーインスタンスをホストしているマシン上に作成する必要があります。この要件の結果として、管理コンソールを使用して作成できるのはノードエージェントのプレースホルダに限られます。, このプレースホルダは、ノードエージェントが存在しない場合のノードエージェントの設定です。
プレースホルダを作成したら、ノードエージェントをホスティングするマシン上で、asadmin コマンドの create-node-agent を使用して作成を完了します。詳細については、「ノードエージェントの作成」を参照してください。
ノードエージェントを作成および使用するために必要な手順のリストについては、「ノードエージェントの配備」を参照してください。
ツリーコンポーネントで、「ノードエージェント」ノードを選択します。
「ノードエージェント」ページで、「新規」をクリックします。
「新しいノードエージェントのプレイスホルダ」ページで、新規ノードエージェントの名前を入力します。
名前は、ドメインのすべてのノードエージェント名、サーバーインスタンス名、クラスタ名、および設定名の間で一意である必要があります。
「了解」をクリックします。
新規ノードエージェントのプレースホルダが「ノードエージェント」ページにリスト表示されます。
create-node-agent-config
ノードエージェントを作成するには、ノードエージェントを実行するマシンで、asadmin コマンドの create-node-agent をローカルに実行します。
ノードエージェントのデフォルト名は、ノードエージェントを作成するホストの名前です。
ノードエージェントのプレースホルダをすでに作成している場合は、ノードエージェントプレースホルダと同じ名前を使用して、関連したノードエージェントを作成します。ノードエージェントのプレースホルダをまだ作成しておらず、DAS が起動していて到達可能である場合、create-node-agent コマンドは DAS 上にノードエージェント設定 (プレースホルダ) も作成します。
コマンド構文の詳しい説明については、コマンドに関するオンラインヘルプを参照してください。
セキュリティー保護された通信を行うように、DAS およびノードエージェントが設定される場合があります。この状況では、ノードエージェントが起動されるとき、DAS がノードエージェントに送信する証明書をノードエージェントの側で検証する必要があります。証明書を検証するために、ノードエージェントはそのローカルトラストストアから証明書を検索します。このトラストストアはマスターパスワードによって保護されています。ユーザーにパスワードの入力を求めることなくノードエージェントを起動できるようにするには、ノードエージェントの作成時に、ノードエージェントのマスターパスワードをファイルに保存します。ノードエージェントのマスターパスワードをファイルに保存しない場合、ユーザーはノードエージェントを起動するたびにマスターパスワードの入力を求められます。
状況によっては、DNS 経由で到達可能なホストの名前を指定する必要があります。詳細については、「DNS に到達可能なホストに対してノードエージェントを作成する」を参照してください。
次のコマンドを入力します。
asadmin create-node-agent --host das-host --port port-no --user das-user [--savemasterpassword=true] nodeagent |
ユーザーにパスワードの入力を求めることなくノードエージェントを起動できるようにするには、ノードエージェントのマスターパスワードをファイルに保存します。ノードエージェントのマスターパスワードをファイルに保存するには、ノードエージェントを作成するためのコマンドで、--savemasterpassword オプションを true に設定します。
--savemasterpassword を true に設定すると、マスターパスワードの入力を求められます。それ以外の場合、パスワードの入力を求められることはありません。
ドメイン管理サーバー (DAS) が稼働しているホストの名前を指定します。
ドメインを管理するための HTTP または HTTPS ポート番号を指定します。
DAS ユーザーを指定します。
作成するノードエージェントの名前を指定します。この名前はドメイン内で一意である必要があります。
asadmin create-node-agent --host myhost --port 4848 --user admin nodeagent1 |
このコマンドは、nodeagent1 という名前のノードエージェントを作成します。ノードエージェントが通信する DAS は、マシン myhost 上で稼働しています。エージェントのドメインを管理するための HTTP ポートは 4848 です。DAS ユーザーの名前は admin です。
次の状況では、DAS が稼働しているホストが DNS 経由で到達可能である必要があります。
ドメインがサブネット境界にまたがっている。すなわち、ノードエージェント と DAS が異なるドメイン (例: sun.com と java.com) 内にある。
ホスト名が DNS に登録されていないDHCP マシンが使用されている。
ドメインを作成するための create-domain コマンドで、--domainproperties domain.hostName=das-host-name オプションを指定します。
das-host-name は、DAS が稼働しているマシンの名前です。
ノードエージェントを作成するための create-node-agent コマンドで、次のオプションを指定します。
--host das-host-name。das-host-name は、手順 1 で指定した DAS ホスト名です。このオプションは、ファイル as-install/nodeagents/nodeagentname/agent/config/das.properties 内の agent.das.host プロパティーに対応します。
--agentproperties remoteclientaddress=node-agent-host-name。node-agent-host-name は、DAS がノードエージェントへの接続に使用するホスト名です。このオプションは、ファイル as-install/nodeagents/nodeagentname/agent/config/nodeagent.properties 内の agent.client.host プロパティーに対応します。
別の解決法は、プラットフォームに特定のホスト名およびアドレス解決を定義する、hosts ファイルを更新し、ホスト名を正しい IP アドレスに解決することです。ただし、DHCP 使用して再接続する時に、異なる IP アドレスを割り当てられる可能性があります。その場合、各サーバーでホスト解決ファイルを更新する必要があります。
ノードエージェントがサーバーインスタンスを管理できるようにするには、ノードエージェントを実行している必要があります。ノードエージェントを起動するには、ノードエージェントが存在するシステムで asadmin コマンドの start-node-agent をローカルに実行します。
コマンド構文の詳しい説明については、コマンドに関するオンラインヘルプを参照してください。
次に例を示します。
asadmin start-node-agent --user admin --startinstances=false nodeagent1
ここで、admin は管理ユーザーであり、nodeagent1 は起動しているノードエージェントです。
デフォルトでは、ノードエージェントインスタンスのキャッシュリポジトリは、ノードエージェントの再起動時に中央リポジトリから同期されません。インスタンスのキャッシュリポジトリを中央リポジトリと強制的に同期するには、asadmin start-node-agent コマンドで --syncinstances オプションを true に設定します。
--syncinstances オプションを true に設定すると、すべてのインスタンスのリポジトリがノードエージェントの再起動時に同期されます。
ノードエージェントを再起動したあとで、asadmin start-instance コマンドを使用してサーバーインスタンスを起動します。
実行中のノードエージェントを停止するには、ノードエージェントが存在するシステムで、asadmin コマンドの stop-node-agent を実行します。stop-node-agent は、ノードエージェントが管理するすべてのサーバーインスタンスを停止します。
コマンド構文の詳しい説明については、コマンドに関するオンラインヘルプを参照してください。
次に例を示します。
asadmin stop-node-agent nodeagent1
ここで、nodeagent1 はノードエージェントの名前です。
ノードエージェントを削除する前に、ノードエージェントを停止する必要があります。ノードエージェントが起動しない場合、またはドメイン管理サーバーに正常に接続できない (バインドされない) 場合も、ノードエージェントを削除できます。
ノードエージェントのファイルを削除するには、ノードエージェントが存在するシステムで、asadmin コマンドの delete-node-agent を実行します。
コマンド構文の詳しい説明については、コマンドに関するオンラインヘルプを参照してください。
次に例を示します。
asadmin delete-node-agent nodeagent1
ここで、nodeagent1 はノードエージェントです。
ノードエージェントを削除する場合は、管理コンソールまたは asadmin delete-node-agent-config コマンドのいずれかを使用して、ドメイン管理サーバーからノードエージェントの設定も削除する必要があります。
ツリーコンポーネントで、「ノードエージェント」ノードを選択します。
ノードエージェントの名前をクリックします。
ノードエージェントがすでに存在するのに、ここに表示されない場合は、ノードエージェントのホストマシンで、asadmin start-node-agent を使用して、ノードエージェントを起動します。「ノードエージェントの起動」を参照してください。
ノードエージェントのホスト名をチェックします。
ホスト名が「不明なホスト」の場合、ノードエージェントはドメイン管理サーバー (DAS) と初期接続をしていません。
ノードエージェントの状態をチェックします。
この状態は次のいずれかです
稼働中: ノードエージェントが正常に作成され、現在実行中です。
停止中: 「ノードエージェントはローカルマシンで作成されているが、起動していない」、または「ノードエージェントは起動したが、その後停止した」のどちらかです。
ランデブーを待機しています: ノードエージェントは、ローカルマシンで作成されていないプレースホルダです。
詳細については、「ノードエージェントの作成」および 「ノードエージェントの起動」を参照してください。
起動時にインスタンスを起動するかどうかを選択します。
ノードエージェントが起動するときに、ノードエージェントに関連するサーバーインスタンスが自動的に起動するようにするには「Yes」を選択します。インスタンスを手動で起動するには、「No」を選択します。
ノードエージェントがドメイン管理サーバーと接続したかどうかを確認します。
ノードエージェントがドメイン管理サーバーと接続していない場合、正常に起動していません。
ノードエージェントに関連するサーバーインスタンスを管理します。
ノードエージェントが実行中の場合、インスタンス名の横にあるチェックボックスをクリックし、「起動」または「停止」をクリックしてインスタンスを起動または停止します。
管理コンソールを使用すると、ドメインからノードエージェントの設定を削除することができます。設定は削除できますが、実際のノードエージェントは削除できません。ノードエージェント自体を削除するには、ノードエージェントのローカルマシンで asadmin コマンドの delete-node-agent を実行します。詳細については、「ノードエージェントの削除」を参照してください。
ノードエージェントの設定を削除する前に、ノードエージェントの実行を停止し、関連するインスタンスを削除する必要があります。ノードエージェントを停止するには、asadmin コマンドの stop-node-agent を使用します。詳細については、「ノードエージェントの停止」を参照してください。
delete-node-agent-config
ツリーコンポーネントで、「ノードエージェント」ノードを開きます。
編集するノードエージェントの設定を選択します。
「起動時にインスタンスを起動」を「Yes」に設定し、エージェントの起動時にエージェントのサーバーインスタンスが起動されるようにします。
このページから、手動でのインスタンスの起動または停止もできます。
この設定がプレースホルダノードエージェント用である場合は、asadmin create-node-agent を使用して実際のノードエージェントを作成するときに、この設定が引き継がれます。ノードエージェントの作成については、「ノードエージェントの作成」を参照してください。
この設定が既存のノードエージェント用である場合、ノードエージェントの設定情報が自動的に同期されます。
ノードエージェントに接続しているユーザーの認証レルムを設定する必要があります。管理ユーザーだけがノードエージェントにアクセスできます。
ツリーコンポーネントで、「ノードエージェント」ノードを開きます。
編集するノードエージェントの設定を選択します。
「認証レルム」タブをクリックします。
「レルムの編集」ページで、レルムを入力します。
デフォルトは、ノードエージェントの作成時に作成された admin-realm です。別のレルムを使用するには、ドメインによって制御されるすべてのコンポーネントまたは正常に通信しないコンポーネントのレルムを置き換えます。
「クラス名」フィールドで、レルムを実装する Java クラスを指定します。
必要なプロパティーを追加します。
認証レルムは、特定の実装によって必要とするものが異なるプロバイダ固有のプロパティーが必要です。
ノードエージェントは、JMX を使用してドメイン管理サーバーと通信します。このため、JMX 要求を待機するポートとその他のリスナー情報が必要です。
ツリーコンポーネントで、「ノードエージェント」ノードを開きます。
編集するノードエージェントの設定を選択します。
「JMX」タブをクリックします。
「アドレス」フィールドに、IP アドレスまたはホスト名を入力します。
リスナーが一意のポート値を使用してサーバーのすべての IP アドレスを待機する場合は、「0.0.0.0」を入力します。それ以外の場合は、サーバーの有効な IP アドレスを入力します。
「ポート」フィールドに、ノードエージェントの JMX コネクタが待機するポート番号を入力します。
IP アドレスが「0.0.0.0」の場合、ポート番号は一意のものである必要があります。
「JMX プロトコル」フィールドで、JMX コネクタがサポートするプロトコルを入力します。
デフォルトは rmi_jrmp です。
「すべてのアドレスを受け付ける」の横にあるチェックボックスをクリックして、すべての IP アドレスに接続できるようにします。
ノードエージェントは、ネットワークカードに関連付けられた特定の IP アドレスを待機するか、またはすべての IP アドレスを待機します。すべてのアドレスを許可すると、「待機するホストアドレス」プロパティーに値「0.0.0.0」が設定されます。
「レルム名」フィールドで、リスナーの認証を処理するレルムの名前を入力します。
このページの「セキュリティ」セクションで、リスナーが SSL、TLS、あるいはこの両方のセキュリティーを使用するように設定します。
安全なリスナーを設定するには、次の手順を実行します。
「セキュリティー」フィールドの「有効」ボックスにチェックマークを付けます。
デフォルトで、セキュリティーが有効になります。
クライアント認証を設定します。
このリスナーを使っている個々のクライアントにサーバーへの認証を要求する場合は、「クライアント認証」フィールドの「有効」ボックスにチェックマークを付けます。
証明書のニックネームを入力します。
「証明書のニックネーム」フィールドに、既存サーバーの鍵ペアと証明書の名前を入力します。
証明書および SSL の操作の詳細については、管理コンソールのオンラインヘルプを参照してください。
SSL3/TLS セクションでは次の手順を実行します。
「保存」をクリックします。