For manual application rollout, workload routing is controlled
by stopping the application server on which the cluster member being
updated resides. This results in a quiesce of that server. All existing
requests already in the server are allowed to complete, but no new
requests are accepted. Both the sysplex distributor and the WebSphere® Application Server Web server
plug-in routes work away from the quiescing server. After all work
has completed, you start the application update process on this server.
Before you begin
Determine which application servers are hosting the cluster
members that need updating.
About this task
If you have a high availability application whose updates
you want to manually control you can use this process or you can use
the MVS™ Modify command to pause the listeners for
the affected application servers. See the information about pausing
an application server to manually update a high availability application.
To manually control application rollout and workload routing
in a high availability environment:
Procedure
- Disable all forms of automatic synchronization, across
all nodes in the cell and save the changes. Perform one
of the following processes to complete this step:
- In the administrative console:
- Click node_agent_name >
File Synchronization Service.
- Unselect the Automatic Synchronization and Startup Synchronization options.
- Select the Synchronize changes with nodes option.
- Click Save.
- Use wsadmin scripting to specify the following commands and then
restart all affected node agents:
set node NODE
set na_id [$AdminConfig getid /Node:$node/Server:nodeagent/]
set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]
$AdminConfig modify $syncServ {{autoSynchEnabled false}}
$AdminConfig modify $syncServ {{synchOnServerStartup false}}
$AdminConfig save
set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*]
$AdminControl invoke $nodeSync sync
Avoid trouble: For a production environment, it is reasonable to always
run the node agent with automatic synchronization disabled. However,
it is advisable for startup synchronization to be enabled for the
node agent so that it can acquire configuration updates that occur
when the node agent is down. Startup Synchronization can be left enabled
provided you can ensure that you will not restart the node agent manually,
through automation, or through automatic restart manager during the
application update process.
gotcha
- Update the application in the master configuration repository
on the deployment manager server. Perform one of the following
processes to complete this step:
- In the administrative console:
- Click Applications > Enterprise Applications.
- Select the application you want to update.
- Complete the application update process.
- Save your changes to the master configuration. DO NOT select
the Synchronize changes with nodes option .
- Use wsadmin scripting to issue the following command:
set app_loc /path/to/app
set app_options {application options ie: -appname app}
set options [list -update] lappend options $app_options
$AdminApp install $app_loc $options
$AdminConfig save
At this point, you have the updated the
version of your application (App v2 in the following figure) in your
Master Configuration. However, the original version of your application
(App v1 in the following figure) is still running in the cluster that
has Cluster members on LPAR1 and LPAR2.
Figure 1. Install application update.
This
figure illustrates the first stage of an application update in a high
availability environment.
- Stop the Application Server on LPAR1 and manually synchronize
the node to the updated version of the application. This
step may take time to complete because the server must wait for all
currently assigned work items to complete before shutting down.
Perform
one of the following processes to complete this step:
- Synchronize the node. Perform one of the following
processes to complete this step:
As illustrated in the following figure, the updated version
of the application (App v2) now resides in the node on LPAR1.
Figure 2. Update the node on LPAR1.
This figure illustrates the first stage of an application update
in a high availability environment with two LPARs.
- Restart the server on LPAR1. Perform one of
the following processes to complete this step:
- In the administrative console:
- Click .
- Select the server you want to start, and then click START.
- Use wsadmin scripting to issue the following commands:
set node NODE
set server SERVER
$AdminControl startServer $server $node
- Issue the following command from the MVS Console:
START procname,JOBNAME=server_short_name.ENV=cell_short_name.node_short_name.server_short_name
For
example:START BBO6ACR,JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001
When this server comes back up, it will be running the new version
of the application (App v2), Figure 3. Restart
the server on LPAR1.
This figure illustrates the completion
of the first stage of an application update in a high availability
environment.
- With the new version of the application running on LPAR1,
repeat the preceding three steps on the other LPARs in the cluster
to update them with the new version of the application. The
following figure illustrates what your configuration will look like
in a two LPAR cluster.
Figure 4. Update
the node on LPAR2.
This figure illustrates the second
stage of an application update in a high availability environment.

Results
The application update process is complete when the new
version of the application is running on all of the cluster members
in the cluster. The following figure illustrates what a two LPAR cluster
will look like after you restart the server on LPAR2.
Figure 5. Restart server on LPAR2.
This
figure illustrates what a two LPAR cluster will look like after you
restart the server on LPAR2.