This topic describes the essential behavioral characteristics of
the application rollout algorithm to better explain the operational implications
on your WebSphere Extended Deployment environment. The installation and distribution
of an application edition is separate from its activation.
Two basic patterns exist for interruption-free replacement: group rollout
or atomic rollout. The steps that occur to roll out the new application edition
vary depending on which of these options you choose.
The dynamic clusters are put in manual mode during the rollout. If your
load becomes heavy during the rollout, application placement does not occur.
Plan your rollouts so that you avoid peak periods or heavy loads. When rollout
completes, the dynamic cluster is put back into its original mode.
Group rollout
The following
steps occur for each node hosting an application server that comprises the
application server cluster to which the application is deployed:
- The node is placed in maintenance mode.
- Work to the application on that node is quiesced.
- The application is stopped on that node.
- Server configuration on that node is changed to reflect the replacement
edition is active and the previous edition is inactive.
- The application is restarted on that node.
- The node is returned to normal mode.
Atomic rollout
- Half of the nodes hosting the application servers that comprise the application
server cluster to which the application is deployed are placed into maintenance
mode. No new requests are sent to these application servers. If there is
an odd number of nodes, the number is rounded up, but is at least one less
than the total number of nodes hosting the application server cluster.
- Work to the application on those nodes quiesces.
- The application stops on those nodes.
- Server configuration on those nodes is changes to reflect that the replacement
edition is active and that the previous edition is inactive.
- The application restarts on those nodes.
- The first step is performed on the remaining nodes.
- The second step is performed on the remaining nodes. No application servers
are available to serve requests for either edition of the application. Requests
for this application are queued in the on demand router (ODR) to ensure that
they are not lost.
- The first set of nodes returns to normal mode. New requests for the new
edition can now be processed and any requests queued in the ODR are released.
- The third, fourth, and fifth step are performed on the remaining nodes.
- The remaining nodes are placed into normal mode.
Default rollout settings
The following options are
preset for the rollout actions in the administrative console:
- Group rollout:
- rollout strategy = group, group size = 1
- reset strategy = application
- drainage interval = 30 seconds
- Atomic rollout:
- rollout strategy = atomic
- reset strategy = application
- drainage interval = 30 seconds
Scripting interface rollout options
The group and
atomic rollout options in the administrative console offer a preset selection
of rollout options. Greater flexibility over these options is possible through
the scripting interface. Read about Application edition management administrative
tasks for more information. The scripting options follow:
- Rollout strategy: Specifies the rollout method, either groups of
nodes updated serially or the divide and swap atomic strategy.
- Group: Specifies that the target cluster is divided into groups
for rollout. Group rollout is most effective when your cluster is large. You
can specify the group size with a sub-option. The group size gives the number
of nodes to process at a time. The default is 1.
- Atomic: Specifies that only one edition of the application can
serve requests during the rollout period. This results in half of the application
server cluster being taken offline and updated, and then the other. Application
requests that arrive while both halves of the cluster are offline are queued
by the ODR.
- Reset strategy: Specifies whether to recycle, for example, stop
and restart, the application or the entire application server.
- Application: Activates the new edition in each application server
by recycling the application. The application server remains up.
- Server: Activates the new edition in each application server by
recycling the server itself. This is necessary if you need to refresh connectors,
native libraries, or reset the Java virtual machine.
- Drainage interval: Specifies the amount of time to wait for
processing requests to complete before the application or application server
is stopped. The default is 30 seconds.