Sun Java System Application Server Enterprise Edition 8.2 High Availability Administration Guide

Chapter 8 Configuring Node Agents

This chapter describes the node agents in Application Server. It contains the following sections:

What is a Node Agent?

A node agent is a lightweight process that is required on every machine that hosts server instances, including the machine that hosts the Domain Administration Server (DAS). The node agent:

When you install the Application Server, a node agent is created by default with the host name of the machine. This node agent must be manually started on the local machine before it runs.

You can create and delete server instances even if the node agent is not running. However, the node agent must be running before you use it to start and stop server instances.

A node agent services a single domain. If a machine hosts instances running in multiple domains, it must run multiple node agents.

Deploying Node Agents

You configure and deploy node agents in two ways:

ProcedureTo Deploy Node Agents Online

Use online deployment if you already know the domain topology and have the hardware for your domain.

The following figure summarizes the online deployment of node agents:

Node Agent Online Deployment
Before You Begin

Install and start the Domain Administration Server. Once the Domain Administration Server is up and running, begin either online or offline deployment.

  1. Install a node agent on every machine that will host a server instance.

    Use the installer or the asadmin create-node-agent command . If a machine requires more than one node agent, use the asadmin create-node-agent command to create them.

    See Creating a Node Agent for more information.

  2. Start the node agents using the asadmin start-node-agent command .

    When started, a node agent communicates with the Domain Administration Server (DAS). When it reaches the DAS, a configuration for the node agent is created on the DAS. Once the configuration exists, the node agent is viewable in the Admin Console.

    See Starting a Node Agent for more information.

  3. Configure the domain: create server instances, create clusters, and deploying applications.

ProcedureTo Deploy Node Agents Offline

Use offline deployment to deploy node agents in the domain before configuring the individual local machines.

The following figure summarizes the offline deployment.

Node Agent Offline Deployment
Before You Begin

Install and start the Domain Administration Server. Once the Domain Administration Server is up and running, begin either online or offline deployment.

  1. Create placeholder node agents in the Domain Administration Server.

    See To Create a Node Agent Placeholder for more information.

  2. Create server instances and clusters, and deploy applications.

    When creating a server instance, make sure to assign port numbers that are not already in use. Because the configuration is being done offline, the domain cannot check for port conflicts at creation time.

  3. Install a node agent on every machine that will host a server instance.

    Use the installer or the asadmin create-node-agent command . The node agents must have the same names as the placeholder node agents previously created.

    See Creating a Node Agent for more information.

  4. Start the node agents using the asadmin start-node-agent command .

    When a node agent is started, it binds to the Domain Administration Server and creates any server instances previously associated with the node agent.

    See Starting a Node Agent for more information.

Synchronizing Node Agents and the Domain Administration Server

Because configuration data is stored in the Domain Administration Server’s repository (the central repository) and also cached on the node agent’s local machine, the two must be synchronized. The synchronization of cache is always done on a explicit user action through the administration tools.

This section contains the following topics:

Node Agent Synchronization

When a node agent is started for the first time, it sends a request to the Domain Administration Server (DAS) for the latest information in the central repository. Once it successfully contacts the DAS and gets configuration information, the node agent is bound to that DAS.


Note –

asadmin start-node-agent command will automatically start the remote server instances without synchronizing with DAS. Use the --startinstances=false option followed by the asadmin start-instance command to start a remote server instance that is synchronized with the central repository managed by DAS.


If you created a placeholder node agent on the DAS, when the node agent is started for the first time it gets its configuration from the central repository of the DAS. During its initial start-up, if the node agent is unable to reach the DAS because the DAS is not running, the node agent stops and remains unbound.

If changes are made in the domain to the node agent’s configuration, they are automatically communicated to the node agent on the local machine while the node agent is running. However, if you added a property to the node agent, you must restart the node agent to synchronize it with the updated configuration.

If you delete a node agent configuration on the DAS, the next time the node agent synchronizes, it stops and marks itself as awaiting deletion. Manually delete it using the local asadmin delete-node-agent command.

Server Instance Synchronization

If you explicitly start a server instance with the Admin Console or asadmin tool, the server instance is synchronized with the central repository. If this synchronization fails, the server instance doesn’t start.

By default a node agent is configured to start its instances automatically. In this situation, the instances are not synchronized when the node agent is restarted. Each server instance runs with the configuration as stored in its cache. You must not add or remove files in a remote server instance's cache.

To synchronize the instances of a node agent that is configured to start its instances automatically, you must stop and restart the instances.

If a node agent is not configured to start its instances automatically, you must start the instances explicitly when the node agent is restarted. In this situation, repository cache for each server instance is synchronized.

The remote server instance's configuration are treated as cache (all files under nodeagents/na1/server1) and owned by Application Server. In extreme cases, if user removes all files of a remote server instance and restarts the node agent, the remote server instance (for example, server1) will be recreated and all necessary files will be synchronized.

The following files and directories are kept synchronized by the Application Server.

Table 8–1 Files and directories synchronized among remote server instances

File or directory 

Description 

applications

All deployed applications. The parts of this directory (and sub directories) synchronized depend on the applications referred to from the server instance. The Node agent does not synchronize any of the applications because it does not reference any application. 

config

Contains configuration files for the entire domain. All the files in this directory are synchronized except runtime temporary files, such as, admch, admsn, secure.seed, . timestamp, and __timer_service_shutdown__.dat.

config/config_name

Directory to store files to be shared by all instances using config named config_name. There will be one such directory for every config defined in domain.xml. All the files in this directory are synchronized to the server instances that are using the config_name.

config/config_name/lib/ext

Folder where Java extension classes (as zip or jar archives) can be dropped. This is used by applications deployed to server instances using config named config_name. These jar files are loaded using Java extension mechanism.

docroot 

The HTTP document root. In out of the box configuration, all server instances in the domain use the same docroot. The docroot property of the virtual server needs to be configured to make the server instances use a different docroot. 

generated 

Generated files for Java EE applications and modules, for example, EJB stubs, compiled JSP classes, and security policy files. This directory is synchronized along with applications directory. Therefore, only the directories corresponding to applications referenced by a server instance are synchronized. 

lib, lib/classes 

Folder where common Java class files or jar and zip archives used by applications deployed to entire domain can be dropped. These classes are loaded using Application Server's class loader. The load order in class loader is: lib/classes, lib/*.jar, lib/*.zip.

lib/ext 

Folder where Java extension classes (as zip or jar archives) used by applications deployed to entire domain can be dropped. These jar files are loaded using Java extension mechanism. 

Synchronizing Library Files

The --libraries deploy time attribute for an application can be used to specify runtime dependencies of an application.

To make a library available to the whole domain, you could place the JAR file in domain-dir/lib or domain-dir/lib/classes. (For more information, see Using the Common Classloader in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide. ) This is usually the case for JDBC drivers and other utility libraries that are shared by all applications in the domain.

For cluster-wide or stand alone server wide use, copy the jars into the domain-dir/domain1/config/xyz-config/lib directory. Next, add the jars in classpath-suffix or classpath-prefix element of xyz-config. This will synchronize the jars for all server instances using xyz-config.

In summary:

Unique Settings and Configuration Management

Configuration files (under domains/domain1/config are synchronized across the domain. If you want to customize a server.policy file for a server1-config used by a stand alone server instance (server1), place the modified server.policy file under domains/domain1/config/server1-config directory.

This modified server.policy file will only be synchronized for the stand alone server instance, server1. You should remember to update the jvm-option. For example: <java-config> ...<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server1-config/server.policy</jvm-options></java-config>

Synchronizing Large Applications

When your environment contains large applications to synchronize or available memory is constrained, you can adjust the JVM options to limit memory usage. This adjustment reduces the possibility of receiving out of memory errors. The instance synchronization JVM uses default settings, but you can configure JVM options to change them.

Set the JVM options using the INSTANCE-SYNC-JVM-OPTIONS property. The command to set the property is:

asadmin set 
domain.node-agent.node_agent_name.property.INSTANCE-SYNC-JVM-OPTIONS="JVM_options"

For example:

asadmin set 
domain.node-agent.node0.property.INSTANCE-SYNC-JVM-OPTIONS="-Xmx32m -Xss2m"

In this example, the node agent is node0 and the JVM options are -Xmx32m -Xss2m.

For more information, see http://java.sun.com/docs/hotspot/VMOptions.html.


Note –

Restart the node agent after changing the INSTANCE-SYNC-JVM-OPTIONS property, because the node agent is not automatically synchronized when a property is added or changed in its configuration.


Using the doNotRemoveList Flag

If your application requires to store and read files in the directories (applications, generated, docroot, config, lib) that are synchronized by the Application Server, use the doNotRemoveList flag. This attribute takes a coma-separated list of files or directories. Your application dependent files are not removed during server startup, even if they do not exist in the central repository managed by DAS. If the same file exists in the central repository, they will be over written during synchronization.

Use the INSTANCE-SYNC-JVM-OPTIONS property to pass in the doNotRemoveList attribute.

For example:

<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>

Viewing Node Agent Logs

Each node agent has its own log file. If you experience problems with a node agent, see the log file at:

node_agent_dir /node_agent_name/agent/logs/server.log .

Sometimes the node agent log instructs you to look at a server’s log to get a detailed message about a problem.

The server logs are located at:

node_agent_dir/node_agent_name/ server_name/logs/server.log

The default location for node_agent_dir is install_dir/nodeagents.

Working with Node Agents

How to Perform Node Agent Tasks

Some node agent tasks require you to use the asadmintool locally on the system where the node agent runs. Other tasks you can perform remotely using either the Admin Console or asadmin.

The following table summarizes the tasks and where to run them:

Table 8–2 How To Perform Node Agent Tasks

Task 

Admin Console 

asadmin Command 

Create node agent placeholder on Domain Administration Server 

Create Node Agent placeholder page 

create-node-agent-config 

Create node agent 

Not available 

create-node-agent 

Start node agent 

Not available 

start-node-agent 

Stop node agent 

Not available 

stop-node agent 

Delete node agent configuration from Domain Administration Server 

Node Agents page 

delete-node-agent-config 

Delete node agent from local machine 

Not available 

delete-node-agent 

Edit node agent configuration 

Node Agents pages 

set 

List node agents 

Node Agents page 

list-node-agents 

Node Agent Placeholders

You can create and delete server instances without an existing node agent using a node agent placeholder. The node agent placeholder is created on the Domain Administration Server (DAS) before the node agent itself is created on the node agent’s local system.

For information on creating a node agent placeholder, see To Create a Node Agent Placeholder


Note –

Once you’ve created a placeholder node agent, use it to create instances in the domain. However, before starting the instances you must create and start the actual node agent locally on the machine where the instances will reside using the asadmin command. See Creating a Node Agent and Starting a Node Agent


ProcedureTo Create a Node Agent Placeholder

Because the node agent must be created locally on the machine hosting the node agent, through the Admin Console you can only create a placeholder for a node agent. This placeholder is a node agent configuration for which a node agent does not yet exist.

After creating a placeholder, use the asadmin command create-node-agent on the machine hosting the node agent to complete the creation. For more information, see Creating a Node Agent.

For a list of the steps involved in creating and using node agents, see Deploying Node Agents

  1. In the tree component, select the Node Agents node.

  2. On the Node Agents page, click New.

  3. On the Current Node Agent Placeholder page, enter a name for the new node agent.

    The name must be unique across all node agent names, server instance names, cluster names, and configuration names in the domain.

  4. Click OK.

    The placeholder for your new node agent is listed on the Node Agents page.

Equivalent asadmin command

create-node-agent-config

Creating a Node Agent

To create a node agent, run the asadmin command create-node-agent locally on the machine on which the node agent runs.

The default name for a node agent is the host name on which the node agent is created.

If you’ve already created a node agent placeholder, use the same name as the node agent placeholder to create the associated node agent. If you have not created a node agent placeholder, and the DAS is up and reachable, the create-node-agent command also creates a node agent configuration (placeholder) on the DAS.

For a complete description of the command syntax, see the online help for the command.


Example 8–1 Example of Creating a Node Agent

The following command creates a node agent:


asadmin create-node-agent --host myhost --port 4849 ---user admin nodeagent1

where myhost is the Domain Administration Server (DAS) hostname, 4849 is the DAS port number, admin is your DAS user, and nodeagent1 is the name of the node agent being created.



Note –

In the following situations, you must specify a DNS-reachable hostname:

Specify a DNS-reachable hostname by explicitly specifying the host name for the domain and the node agent when you create them:


create-domain --domainproperties domain.hostName=DAS-host-name
create-node-agent --hostDAS-host-name
--agentproperties remoteclientaddress=node-agent-host-name

Another solution is to update the hosts hostname/IP resolution file specific to the platform so the hostname resolves to the correct IP address. However, when reconnecting using DHCP you might get assigned a different IP address. In that case, you must update the host resolution files on each server.


Starting a Node Agent

Before a node agent can manage server instances, it must be running. Start a node agent by running the asadmin command start-node-agent locally on the system where the node agent resides.

For a complete description of the command syntax, see the online help for the command.

For example:

asadmin start-node-agent --user admin --startinstances=false nodeagent1

where admin is your administration user, and nodeagent1 is the node agent being started. Next, use asadmin start-instance command to start the server instance.

Stopping a Node Agent

Run the asadmin command stop-node-agent on the system where the node agent resides to stop a running node agent. The stop-node-agent command stops all server instances that the node agent manages.

For a complete description of the command syntax, see the online help for the command.

For example:

asadmin stop-node-agent nodeagent1

where nodeagent1 is the name of the node agent.

Deleting a Node Agent

Before deleting a node agent, the node agent must be stopped. You can also delete a node agent if it has never been started, or never successfully able to contact the Domain Administration Server (that is, if it is still unbound).

Run the asadmin command delete-node-agent on the system where the node agent resides to delete the node agent files.

For a complete description of the command syntax, see the online help for the command.

For example:

asadmin delete-node-agent nodeagent1

where nodeagent1 is your node agent.

When deleting a node agent, you must also delete its configuration from the Domain Administration Server using either the Admin Console or the asadmin delete-node-agent-config command.

ProcedureTo View General Node Agent Information

  1. In the tree component, select the Node Agents node.

  2. Click the name of a node agent.

    If a node agent already exists but does not appear here, start the node agent on the node agent’s host machine using asadmin start-node-agent. See Starting a Node Agent

  3. Check the node agent’s host name.

    If the host name is Unknown Host, then the node agent has not made initial contact with the Domain Administration Server (DAS).

  4. Check the node agent status.

    The status can be:

    • Running: The node agent has been properly created and is currently running.

    • Not Running: Either the node agent has been created on the local machine, but never started or the node agent was started but has been stopped.

    • Waiting for Rendezvous: The node agent is a placeholder that has never been created on the local machine.

    See Creating a Node Agent and Starting a Node Agent.

  5. Choose whether to start instances on start up.

    Select Yes to start server instances associated with the node agent automatically when the node agent is started. Select No to start the instances manually.

  6. Determine whether the node agent has made contact with the Domain Administration Server.

    If the node agent has never made contact with the Domain Administration Server, it has never been successfully started.

  7. Manage server instances associated with the node agent.

    If the node agent is running, start or stop an instance by clicking the checkbox next to the instance name and clicking Start or Stop.

ProcedureTo Delete a Node Agent Configuration

Through the Admin Console you can only delete the node agent configuration from the domain. You cannot delete the actual node agent. To delete the node agent itself, run the asadmin command delete-node-agent on the node agent’s local machine. For more information, see Deleting a Node Agent.

Before deleting the node agent configuration, the node agent must be stopped and it must not have any associated instances. To stop a node agent, use the asadmin command stop-node-agent. See Stopping a Node Agent for more information.

  1. In the tree component, select the Node Agents node.

  2. On the Node Agents page, select the checkbox next to the node agent to be deleted.

  3. Click delete.

Equivalent asadmin command

delete-node-agent-config

ProcedureTo Edit a Node Agent Configuration

  1. In the tree component, expand the Node Agents node.

  2. Select the node agent configuration to edit.

  3. Check Start Instances on Startup to start the agent’s server instances when the agent is started.

    You can also manually start and stop instances from this page.

    If this configuration is for a placeholder node agent, when you create the actual node agent using asadmin create-node-agent , it picks up this configuration. For information on creating a node agent, see Creating a Node Agent.

    If this configuration is for an existing node agent, the node agent configuration information is synchronized automatically.

ProcedureTo Edit a Node Agent Realm

You must set an authentication realm for users connecting to the node agent. Only administration users should have access to the node agent.

  1. In the tree component, expand the Node Agents node.

  2. Select the node agent configuration to edit.

  3. Click the Auth Realm tab.

  4. On the Node Agents Edit Realm page, enter a realm.

    The default is admin-realm, created when you create the node agent. To use a different realm, replace the realms in all the components controlled by the domain or the components won’t communicate properly.

  5. In the Class Name field, specify the Java class that implements the realm.

  6. Add any required properties.

    Authentication realms require provider-specific properties, which vary depending on what a particular implementation needs.

ProcedureTo Edit the Node Agent’s Listener for JMX

The node agent uses JMX to communicate with the Domain Administration Server. Therefore it must have a port to listen on for JMX requests, and other listener information.

  1. In the tree component, expand the Node Agents node.

  2. Select the node agent configuration to edit.

  3. Click the JMX tab.

  4. In the Address field, enter an IP address or host name.

    Enter 0.0.0.0 if the listener listens on all IP addresses for the server using a unique port value. Otherwise, enter a valid IP address for the server.

  5. In the Port field, type the port on which the node agent’s JMX connector will listen.

    If the IP address is 0.0.0.0, the port number must be unique.

  6. In the JMX Protocol field, type the protocol that the JMX connector supports.

    The default is rmi_jrmp.

  7. Click the checkbox next to Accept All Addresses to allow a connection to all IP addresses.

    The node agent listens on a specific IP address associated to a network card or listens on all IP addresses. Accepting all addresses puts the value 0.0.0.0 in the “listening host address” property.

  8. In the Realm Name field, type the name of the realm that handles authentication for the listener.

    In the Security section of this page, configure the listener to use SSL, TLS, or both SSL and TLS security.

    To set up a secure listener, do the following:

  9. Check the Enabled box in the Security field.

    Security is enabled by default.

  10. Set client authentication.

    To require clients to authenticate themselves to the server when using this listener, check the Enabled box in the Client Authentication field.

  11. Enter a certificate nickname.

    Enter the name of an existing server key pair and certificate in the Certificate NickName field. For more information, see Working with Certificates and SSL in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

  12. In the SSL3/TLS section:

    1. Check the security protocol(s) to enable on the listener.

      You must check either SSL3 or TLS, or both protocols.

    2. Check the cipher suite used by the protocol(s).

      To enable all cipher suites, check All Supported Cipher Suites.

  13. Click Save.