設定データは、ドメイン管理サーバーのリポジトリ (中央リポジトリ) に格納されると同時に、ノードエージェントのローカルマシンにもキャッシュされるため、これらの 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 によって同期が保たれます。
表 4–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 GlassFish Communications Server 1.5 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>