![]() | |
|
Setting up the administrative agent environment
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.
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.
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 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.
Create a management profile for the administrative agent.
You can use the Profile Management Tool or the manageprofiles.sh
command.
By default, the first administrative agent profile in a product installation is named AdminAgent01
and its server name is adminagent
.
For -templatePath
, specify the management
template. For -serverType
, specify ADMIN_AGENT
.
test317:~ # /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh -create -profileName AdminAgent01 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/management/ -serverType ADMIN_AGENT INSTCONFSUCCESS: Success: Profile AdminAgent01 now exists. Please consult /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/logs/AboutThisProfile.txt for more information about this profile.
test317:~ # tail /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/logs/AboutThisProfile.txt Make this profile the default: False Node name: test317AANode01 Cell name: test317AACell01 Host name: test317.java.boot.by Enable administrative security (recommended): False Administrative console port: 9062 Administrative console secure port: 9045 Management bootstrap port: 9807 Management SOAP connector port: 8877 Run Management as a service: False
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.sh
command.
By default, the first application server profile in a product installation is named AppSrv01
and its server name is server1
.
For -templatePath
, specify the default
template.
Start the administrative agent server: run the startServer.sh
command.
For example, suppose the AdminAgent01
profile has the server name adminagent
. Run the following command from the bin
directory
of the AdminAgent01
profile:
test317:~ # cd /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/bin/ test317:/opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/bin # ./startServer.sh adminagent ADMU0116I: Tool information is being logged in file /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/logs/adminagent/startServer.log ADMU0128I: Starting tool with the AdminAgent01 profile ADMU3100I: Reading configuration for server: adminagent ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server adminagent open for e-business; process id is 50732
Register the stand-alone application server nodes with the administrative agent.
Run the registerNode.sh
command of the administrative agent.
When you run the registerNode.sh
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
.
To register the AppSrv01
profile with the administrative agent, run the following command from the bin
directory of the
administrative agent profile:
test317:/opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/bin # ./registerNode.sh -profilePath /opt/IBM/WebSphere/AppServer/profiles/AppSrv01 ADMU0116I: Tool information is being logged in file /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/logs/registerNode.log ADMU0128I: Starting tool with the AdminAgent01 profile ADMU8053I: Successfully connected to AdminAgent Server: localhost:8877 ADMU8002I: Exchanging signers between adminagent and node with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv01. ADMU8007I: Exchanged signers successfully. ADMU0505I: Servers found in configuration: ADMU0506I: Server name: server1 ADMU2010I: Stopping all server processes for node exampleNode01 ADMU0510I: Server server1 is now STOPPED ADMU8010I: Begin registration of Application Server with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv01 ADMU0024I: Deleting the old backup directory. ADMU8004I: Backing up the original config directory of the node to be registered. ADMU8037I: Backing up the original wsadmin.properties file of the node to be registered. ADMU8036I: Registering the node with an AdminAgent. ADMU8042I: Node has been successfully registered. ADMU8040I: The administrative agent is initializing the administrative subsystem for the registered node. ADMU8014I: The administrative subsystem for the registered node has been successfully initialized. ADMU8041I: The administrative agent is starting the administrative subsystem for the registered node. ADMU8015I: The administrative subsystem for the registered node has been successfully started. ADMU8012I: Application Server with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv01 has been successfully registered.
repeat the command for other profile(s)
test317:/opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/bin # ./registerNode.sh -profilePath /opt/IBM/WebSphere/AppServer/profiles/AppSrv02 ADMU0116I: Tool information is being logged in file /opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/logs/registerNode.log ADMU0128I: Starting tool with the AdminAgent01 profile ADMU8053I: Successfully connected to AdminAgent Server: localhost:8877 ADMU8002I: Exchanging signers between adminagent and node with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv02. ADMU8007I: Exchanged signers successfully. ADMU0505I: Servers found in configuration: ADMU0506I: Server name: server1 ADMU2010I: Stopping all server processes for node test317Node01 ADMU0512I: Server server1 cannot be reached. It appears to be stopped. ADMU8010I: Begin registration of Application Server with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv02 ADMU0024I: Deleting the old backup directory. ADMU8004I: Backing up the original config directory of the node to be registered. ADMU8037I: Backing up the original wsadmin.properties file of the node to be registered. ADMU8036I: Registering the node with an AdminAgent. ADMU8042I: Node has been successfully registered. ADMU8040I: The administrative agent is initializing the administrative subsystem for the registered node. ADMU8014I: The administrative subsystem for the registered node has been successfully initialized. ADMU8041I: The administrative agent is starting the administrative subsystem for the registered node. ADMU8015I: The administrative subsystem for the registered node has been successfully started. ADMU8012I: Application Server with path /opt/IBM/WebSphere/AppServer/profiles/AppSrv02 has been successfully registered.
Verify that the nodes have been registered to the administrative agent.
You can use the administrative agent console or wsadmin.sh
scripting commands to see a list of nodes that
are registered with the administrative agent.
Use the administrative agent console to see a list of managed nodes.
Start the administrative agent console at the URL: http://test317.java.boot.by:9062/ibm/console
On the opening page of the administrative agent console, select to administer the administrative agent. The administrative
agent has a name such as host_nameAANode01
.
Log in to the administrative agent console.
Examine the Nodes page.
Click System administration > Administrative agent.
On the Configuration tab of the Administrative agent page, click Nodes.
Ensure that the Nodes page lists nodes that have been registered with the administrative agent.
Use the AdminConfig
list
command to see a list of managed nodes. Run the following wsadmin.sh
scripting
commands from the administrative agent bin
directory.
To use the Jython scripting language, enter the following two commands in succession:
test317:/opt/IBM/WebSphere/AppServer/profiles/AdminAgent01/bin # ./wsadmin.sh -lang jython WASX7209I: Connected to process "adminagent" on node test317AANode01 using SOAP connector; The type of process is: AdminAgent WASX7031I: For help, enter: "print Help.help()" wsadmin>print AdminConfig.list('ManagedNode') exampleNode01(cells/test317AACell01/managednodes/exampleNode01|managednode.xml#ManagedNode_1369735365227) test317Node01(cells/test317AACell01/managednodes/test317Node01|managednode.xml#ManagedNode_1369735970916) wsadmin>
After you verify that the stand-alone application server nodes are registered with the administrative agent, enter quit
to exit the
wsadmin.sh
scripting tool.
Start the stand-alone application server nodes.
Run the startServer.sh
command:
test317:~ # /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh server1 ADMU0116I: Tool information is being logged in file /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/startServer.log ADMU0128I: Starting tool with the AppSrv01 profile ADMU3100I: Reading configuration for server: server1 ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server server1 open for e-business; process id is 56528 test317:~ # /opt/IBM/WebSphere/AppServer/profiles/AppSrv02/bin/startServer.sh server1 ADMU0116I: Tool information is being logged in file /opt/IBM/WebSphere/AppServer/profiles/AppSrv02/logs/server1/startServer.log ADMU0128I: Starting tool with the AppSrv02 profile ADMU3100I: Reading configuration for server: server1 ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server server1 open for e-business; process id is 56944
The administrative agent environment is set up and the nodes are running.
Configuration and application data repository
The configuration and application data repository is a collection of files containing all the information necessary to configure and execute servers and their applications. Configuration files are stored in XML format, while application data is stored as Enterprise ARchive (EAR) files and deployment descriptors.
Repository directory structure
It is important to know that configuration files defining a runtime environment are stored in
profile directories. Each node containing a deployment manager, application server,
administrative agent, or job manager has its own profile directory under the
install_root/profiles
directory.
The repository files are arranged in a set of cascading directories under each profile directory structure, with each directory containing a number of files relating to different components of the cell, as shown in figure below. The repository structure follows the same format, regardless of whether you have a stand-alone server environment or distributed server environment.
The profile_root/config
directory is the root of the repository for each profile.
test317:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config # ls -l total 32 drwxr-xr-x 2 root root 4096 Sep 19 2012 .repository drwxr-xr-x 2 root root 4096 May 21 08:46 backup drwxr-xr-x 2 root root 4096 May 21 09:28 bundlecache drwxr-xr-x 3 root root 4096 May 21 08:37 cells drwxr-xr-x 3 root root 4096 May 21 08:42 temp drwxr-xr-x 8 root root 4096 Sep 19 2012 templates drwxr-xr-x 3 root root 4096 Sep 19 2012 waspolicies drwxr-xr-x 9 root root 4096 Sep 19 2012 xforms
test317:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config # ls -l cells/ total 4 drwxr-xr-x 13 root root 4096 May 21 08:45 test317Cell01
test317:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config # ls -l cells/test317Cell01/ total 552 drwxr-xr-x 14 root root 4096 May 21 08:42 PolicySets drwxr-xr-x 10 root root 4096 May 21 08:42 PolicyTypes -rwxr-xr-x 1 root root 428 May 21 08:42 WSSCCache.xml -rwxr-xr-x 1 root root 599 May 21 08:42 WSSDistributedCache.xml -rwxr-xr-x 1 root root 1928 May 21 08:42 admin-authz.xml -rwxr-xr-x 1 root root 2163 May 21 08:42 amwas.amjacc.template.properties -rwxr-xr-x 1 root root 10352 May 21 08:42 amwas.pdjlog.template.properties drwxr-xr-x 5 root root 4096 May 21 08:42 applications -rwxr-xr-x 1 root root 765 May 21 08:42 audit-authz.xml -rwxr-xr-x 1 root root 2039 May 21 08:42 audit.xml drwxr-xr-x 10 root root 4096 May 21 08:42 bindings drwxr-xr-x 5 root root 4096 May 21 08:42 blas -rwxr-xr-x 1 root root 888 May 21 08:42 cell.xml -rwxr-xr-x 1 root root 353 May 21 08:42 centralizedinstall.xml -rwxr-xr-x 1 root root 795 May 21 08:42 coregroupbridge.xml drwxr-xr-x 3 root root 4096 May 21 08:42 coregroups drwxr-xr-x 5 root root 4096 May 21 08:42 cus -rwxr-xr-x 1 root root 1854 May 21 08:42 filter.policy -rwxr-xr-x 1 root root 251 May 21 08:42 gridscheduler.xml -rwxr-xr-x 1 root root 270 May 21 08:42 jvms.xml -rwxr-xr-x 1 root root 3762 May 21 08:44 key.p12 -rwxr-xr-x 1 root root 1613 May 21 08:44 ltpa.jceks -rwxr-xr-x 1 root root 414 May 21 08:42 multibroker.xml -rwxr-xr-x 1 root root 344 May 21 08:42 namestore.xml -rwxr-xr-x 1 root root 1496 May 21 08:42 naming-authz.xml drwxr-xr-x 3 root root 4096 Sep 19 2012 nodegroups drwxr-xr-x 3 root root 4096 May 21 08:37 nodes -rwxr-xr-x 1 root root 2426 May 21 08:42 pmirm.xml -rwxr-xr-x 1 root root 1750 May 21 08:42 product-info.xml -rwxr-xr-x 1 root root 2033 May 21 08:42 ras.rawtracelist.properties -rwxr-xr-x 1 root root 343 May 21 08:42 resources-cei.xml -rwxr-xr-x 1 root root 2117 May 21 08:42 resources-pme.xml -rwxr-xr-x 1 root root 323 May 21 08:42 resources-pme502.xml -rwxr-xr-x 1 root root 51161 May 21 08:45 resources.xml -rwxr-xr-x 1 root root 3762 May 21 08:44 rsatoken-key.p12 -rwxr-xr-x 1 root root 1338 May 21 08:44 rsatoken-trust.p12 -rwxr-xr-x 1 root root 41957 May 21 08:44 security.xml drwxr-xr-x 3 root root 4096 May 21 08:42 sts -rwxr-xr-x 1 root root 1338 May 21 08:44 trust.p12 -rwxr-xr-x 1 root root 851 May 21 08:42 variables.xml -rwxr-xr-x 1 root root 270939 May 21 08:46 virtualhosts.xml drwxr-xr-x 4 root root 4096 May 21 08:42 wim -rwxr-xr-x 1 root root 16106 May 21 08:42 ws-security.xml
In a distributed server environment, the structure has the following characteristics:
The master repository is held on the node containing the deployment manager. It contains the master copies of the configuration and application data files for all nodes and servers in the cell.
Each node also has a local copy of the configuration and application data files from the master repository that are relevant to the node.
When changes are made to the configuration in the master repository, those changes need to be synchronized to the configuration files on the nodes.
Changes can be made to the configuration files on a node, but the changes are temporary and are overwritten by the next file synchronization from the deployment manager. Permanent changes to the configuration require changes to the file or files in the master repository. Configuration changes made to node repositories are not propagated up to the cell.
The applications directory of the master repository contains the application data (binaries and deployment descriptors) for all applications deployed in the cell. The local copy of the applications directory on each node only contains the directories and files for the applications deployed on application servers within that node.
File synchronization in distributed server environments
The file synchronization service is the administrative service responsible for keeping the configuration and application data files that are distributed across the cell up to date. The service runs in the deployment manager and node agents, and ensures that changes made to the master repository are propagated out to the nodes, as necessary. The file transfer system application is used for the synchronization process. File synchronization can be forced from an administration client, or can be scheduled to happen automatically.
During the synchronization operation, the node agent checks with the deployment manager to see if any files that apply to the node have been updated in the master repository. New or updated files are sent to the node, while any deleted files are also deleted from the node.
Synchronization is one-way. The changes are sent from the deployment manager to the node agent. No changes are sent from the node agent back to the deployment manager.
![]() ![]() ![]() |