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.
newfeatMake 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 node
and the administrative agent. Starting with Version 7.0.0.13, this requirement is enforced
because the administrative agent must have a matching environment
in order to handle all of the administrative capabilities of the registered
node. A node is not allowed to register with an administrative agent
unless that node has an identical set of products and versions.
newfeatIf 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 apply Version
7.0.0.13 or later to the administrative agent, 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
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 nodes must be on the same computer as the administrative
agent.
On a WebSphere Application Server, 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 machines, 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.
Attention: If the administrative agent resides on a DMZ image,
do not change the bootstrap port. Even though the administrative agent
does not open the bootstrap port, the control region needs the bootstrap
port definition to communicate with the servant region of the administrative
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.
- Run the startServer command.
For example,
suppose the AdminAgent01 profile has the server name adminagent.
Run the following command from the bin directory
of the AdminAgent01 profile:
startServer adminagent
Use the Windows® operating
system Taskbar. Click .
Use the START command to start the administrative
agent.START administrative_agent_proc_name,JOBNAME=server_short_name,
ENV=cell_short_name.node_short_name.server_short_name
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
registerNode.sh -profilePath app_server_root/profiles/default
registerNode.sh -profilePath app_server_root/profiles/AppSrv01
registerNode -profilePath app_server_root\profiles\AppSrv01
![[Windows]](../../windows.gif)
For example, to register the AppSrv01
profile with the administrative agent and specify other values, such
as
8877 for the administrative agent port and
nodeA for
the AppSrv01 node name, run the following command from the
bin directory
of the administrative agent profile:
registerNode -profilePath C:\v70_WAS\IBM\WebSphere\AppServer\profiles\AppSrv01 -host localhost -conntype SOAP -port 8877 -name nodeA
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.
For example, suppose the
AppSrv01 stand-alone application server profile has the server name server1.
From the bin directory of the AppSrv01 profile,
run the following command:
startServer server1
You can also use the Windows operating system Taskbar.
Click .
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.
Avoid trouble: Even though the administrative agent
console navigation implies that you can specify SIP application router
settings for the administrative agent, if you have the Feature Pack
for Communications Enabled Applications (CEA) Version 1.0.0.7 or higher
installed on your system, you must use either the administrative console
or wsadmin commands for the managed server to specify SIP application
router settings.
gotcha
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
from a 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.
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, the job manager server, and the location service daemon
first. After you stop the servers and location service daemon, change
the system clock, and then restart the servers and location service
daemon. 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.