The algorithm for performing a rollout to a new edition
has operational implications on your 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 perform a rollout
to a new 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 the rollout completes, the dynamic cluster is
put back into its original mode.
Avoid trouble: Do not perform
a rollout during periods of heavy traffic.
gotcha
Group rollout
When
you choose to perform a 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
Before you perform an atomic
rollout, determine the load capability of the target server cluster.
Performing an atomic rollout activates the new edition on half of
the cluster first, and then activates the edition on the remaining
half of the cluster. While the first half of the cluster is taken
offline and updated, application requests are routed to the second
half of the cluster. Verify that half the cluster can handle the entire
load during the rollout period.
When you choose to perform an
atomic rollout, the following steps occur for each server:
- 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
following scripting options exist:
- 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 on demand router (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 continues
to run.
- Server: Activates the new edition in each application
server by recycling the server itself. This option 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.