An administrative
agent environment consists of an administrative
agent and the stand-alone application servers that it manages. Setting
up an administrative agent environment involves creating an administrative
agent profile and one or more stand-alone application server profiles,
called nodes, on the same computer and then registering
the node profiles with the administrative agent.
Before you begin
Install the WebSphere® Application Server product.
Make sure that the nodes that you want the administrative
agent to manage have the same products as the administrative agent,
and the products are at the same version levels on these nodes and
the administrative agent. This requirement is enforced because the
administrative agent must have a matching environment to handle all
the administrative capabilities of the registered node. A node cannot
register with an administrative agent unless that node has an identical
set of products and versions.
newfeatA DMZ proxy
does not work with the administrative agent when security is enabled.
Keep security enabled and do not use the administrative agent in a
DMZ proxy environment.
newfeat For transitioning users: If you were previously running
on Version 7.0.0.11 or earlier, and have an administrative agent with
a managed node that has mismatched products or versions, when you
migrate to Version 8.0, that administrative agent will not be able
to start the subsystem for any mismatched nodes. You must update these
nodes to have the same products and versions as the administrative
agents, restart the servers on the node and then restart the administrative
agent, before the administrative agent can resume managing these registered
nodes.
trns
About this task
You can use an administrative agent
to manage base (stand-alone)
application servers that are on the same computer.
Administrative
agents and the managed nodes are part of the flexible management environment.
To
add an administrative agent to your environment, create an administrative
agent profile using the manageprofiles command
or the Profile Management Tool. To add a node, create a stand-alone
application server profile and then register the stand-alone application
server with the administrative agent.
The
node must be on the same computer as the administrative agent.
On a Network Deployment product, you also can add
job managers to your flexible management environment. A job manager
is a single management server from which you can remotely manage multiple
administrative agents, deployment managers, and stand-alone application
servers. From an administrative agent, you can register stand-alone
application server nodes with a job manager. Nodes that register with
a job manager maintain their own administrative capabilities. Additionally,
the nodes periodically poll the job managers to determine whether
there are jobs posted there that require action. The advantage to
a job manager configuration is the ability to coordinate management
actions across multiple varied environments.
Ensure that the
profiles in the flexible management environment either all have security
enabled or all have security disabled.
- Determine
the topology for your administrative agent environment.
Determine
which computers, stand-alone application server
nodes, and node resources such as applications that you want to use.
To
manage stand-alone application servers, use an administrative agent
on each computer where the stand-alone application servers reside.
For more information, see Scenarios 5 in the Planning to install WebSphere Application Server topic.
- Determine the security roles needed for your administrative
agent environment.
For an administrative agent environment,
you typically have one administrative agent profile and one or more
stand-alone application server profiles on the same computer. The
stand-alone application server nodes are registered to the administrative
agent. Profiles in the environment must either all have security enabled
or all have security disabled. When you create the profiles, you can
specify security options, user names, and passwords.
You must
have security roles that authorize you to work with an administrative
agent and to manage registered nodes and resources on those nodes.
For more information, see the administrative agent security topic.
- Create a management profile for the administrative
agent.
You can use the Profile Management Tool or the manageprofiles command.
For
example, in the Profile Management Tool, select the Management environment
and click Next, select the Administrative
agent server type, and select options that create the
profile. By default, an administrative agent has its own administrative
console, administrative security is enabled, and the console port
is 9065. To disable administrative security, to specify a security
certificate, or to change the default ports, use the advanced profile
creation option when creating the administrative agent profile.
By
default, the first administrative agent profile in a product installation
is named AdminAgent01 and its server name is adminagent.
For
more information, see the topic on creating management profiles for
administrative agents.
For manageprofiles examples,
see the topic on the manageprofiles command. For -templatePath,
specify the management template. For -serverType,
specify ADMIN_AGENT.
- Create
profiles for the stand-alone application server
nodes that you intend to have in your flexible management environment.
Create profiles for one or more stand-alone application server
nodes that reside on the same computer as the administrative agent
profile. You can use the Profile Management Tool or the manageprofiles command.
For
example, in the Profile Management Tool, select the Application
server environment and click Next,
and then select options that create the profile. By default, an application
server has its own administrative console, administrative security
is enabled, and the console port is 9060. To disable administrative
security, to specify a security certificate, to specify to install
sample application, or to change the default ports, select the advanced
profile creation option when creating the application server profile.
By
default, the first application server profile in a product installation
is named AppSrv01 and its server name is server1.
For
more information, see the topic on creating application server profiles.
For manageprofiles examples,
see the topic on the manageprofiles command. For -templatePath,
specify the default template. Do not specify a -serverType parameter.
- Start the administrative agent server.
If the administrative agent starts successfully, the open
for e-business message displays and is written to the administrative
agent startServer.log file:
Server launched. Waiting for initialization status.
Server adminagent open for e-business; process id is 1932.
For
more information, see the topic on starting and stopping the administrative
agent.
- Register the stand-alone application
server nodes with
the administrative agent.
Run the registerNode command
of the administrative agent.
When you run the registerNode command,
you can optionally specify parameters such as -node to
assign a node name and -port to assign an administrative
agent connector port. If security is enabled for the node that you
are registering and the node user name and node password are different
than those used for the administrative agent, specify values for -nodeusername and -nodepassword.
For more information, see the topic on the registerNode command.
To
register the AppSrv01 profile with the administrative agent, run the
following command from the bin directory of the
administrative agent profile:
registerNode -profilePath user_data_root/profiles/AppSrv01
For more information, see the topic on the registerNode command.
- Verify that the nodes have been registered to the
administrative
agent.
You can use the administrative agent console
or wsadmin scripting commands to see a list of nodes that are registered
with the administrative agent.
- Start
the stand-alone application server nodes.
Run
the startServer command.
startServer server1
If the
server starts successfully, the open for e-business message
displays and is written to the startServer.log file.
For
more information, see topics on the startServer command and on starting
application servers.
What to do next
Use the administrative
agent to monitor and configure
the stand-alone application server nodes.
From
the administrative agent, you can register the stand-alone application
server nodes with a job manager. After the nodes are registered with
a job manager, you can remotely manage the administrative agent and
the stand-alone application servers. The nodes periodically poll the
job manager to determine whether there are jobs posted that pertain
to the nodes.
You can use the administrative
agent console to register a stand-alone application server node with
a job manager:
- Click .
- On
the Configuration tab of the Administrative agent page, click Nodes.
- On the Nodes page, select the node to register with the job manager
and click Register with Job Manager.
- On
the Register with Job Manager page, specify a node name, specify
a job manager administrative console port number, optionally specify
other parameters such as the job manager user name and password, and
click OK.
Avoid trouble: For
Port,
if security is not enabled, specify
9960 for an unsecure
job manager administrative console port. If no port number is specified,
the default secure port number 9943 is used.
gotcha
To unregister a node later, you can use
the same Nodes page, except click Unregister with Job Manager.
Instead of using the administrative agent console
to register and unregister with a job manager, you also can use the
ManagedNodeAgent registerWithJobManager wsadmin
command. To unregister a node, use the ManagedNodeAgent unregisterWithJobManager wsadmin
command.
If you plan to change the system clock, stop all the
application servers, the node agent servers, the deployment manager
server, the administrative agent server, and the job manager server
first. After you stop the servers, change the system clock, and then
restart the servers. If you change the system clock on one system,
you must ensure the clocks on all systems that communicate with each
other and have WebSphere Application Server installed
are synchronized. Otherwise, you might experience errors, such as
security tokens no longer being valid.