Algorithm for performing a rollout

The algorithm for performing a rollout to a new edition has operational implications on the 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 we choose.

The dynamic clusters are put in manual mode during the rollout. If our load becomes heavy during the rollout, application placement does not occur. Plan the rollouts so that you avoid peak periods or heavy loads. When the rollout completes, the dynamic cluster is put back into its original mode.

Do not perform a rollout during periods of heavy traffic.

Group rollout

When we choose to perform a group rollout, the rollout occurs across the clusters in groups of servers. The following steps occur for each server:

1. Quiesce work to the server.
2. Stop the application or stop the server.
3. Update the server configuration.
4. Restart the application or the server.
5. The server is ready with the new edition.

Atomic rollout

Before performing 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 we choose to perform an atomic rollout, the following steps occur:

1. Quiesce work to half of the servers.
2. Stop the applications or servers in the first half of the servers.
3. Update the configurations.

4. Start the applications or servers in the first half of the servers.
5. Quiesce work to the second half of the servers.

6. Start routing requests to the new edition, which is running on the first half of servers.
7. On the second half of the servers, stop the applications or servers, update the configurations, and start the applications or servers.
8. Rollout is complete.

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: Rollout method, either groups of nodes updated serially or the divide-and-swap atomic strategy.

  Group	The target cluster is divided into groups for rollout. Group rollout is most effective when your cluster is large. We 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	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.

• Reset strategy: Recycle, for example, stop and restart, the application or the entire application server.

  Application	Activate the new edition in each application server by recycling the application. The application server continues to run.
  Server	Activate the new edition in each application server by recycling the server itself. This option is necessary if we need to refresh connectors, native libraries, or reset the Java virtual machine.

• Drainage interval: Amount of time to wait for processing requests to complete before the application or application server is stopped. The default is 30 seconds.

Related:

Application edition manager

Intelligent Management: application edition management administrative tasks