2.3. Create and manage nodes in a WebSphere topology (e.g., flexible management, network deployment cell).

2.3. Create and manage nodes in a WebSphere topology (e.g., flexible management, network deployment cell).
Prev	Chapter 2. Installation, Configuration and Maintenance	Next


	[WAS_8.0_INFOCENTER] Setting up the administrative agent environment [WAS_8.0_ADMIN_GUIDE] Configuration and application data repository

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

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.
  1. Start the administrative agent console at the URL: http://test317.java.boot.by:9062/ibm/console
  2. 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.
    
    Figure 2.3.
  3. Log in to the administrative agent console.
    
    Figure 2.4.
  4. Examine the Nodes page.
    Click System administration > Administrative agent.
    
    Figure 2.5.
    
    On the Configuration tab of the Administrative agent page, click Nodes.
    
    Figure 2.6.
  5. 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.

Figure 2.7. Repository directory structure

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.

Prev	Up	Next
2.2. Illustrate the silent installation process for WebSphere Application Server software and Fix pack installations.	Home	2.4. Manipulate profiles using the Profile Management Tool and `manageprofiles` command.