Select Atomic or Grouped rollout type.
Use group rollout to replace editions on members of
the target cluster in a group of one. Group rollout is the most typical
choice, and is useful when the cluster contains four or more members.
Alternatively, you can perform group rollout with a specified group
size through scripting. For more information, read about Application edition management administrative tasks
. When
the new edition becomes available during group rollout, all requests
are directed to the new edition.
Use atomic rollout to
replace one edition with another on half of the cluster at a time.
This rollout type serves all user requests with a consistent edition
of the application. Because all user requests are served a consistent
edition, your cluster runs at half capacity. If your cluster has four
or more members, consider dividing up the cluster into smaller groups
by performing a group rollout. Atomic mode is also used with a single
server deployment target. In a single server deployment target, the
actions that are carried out against the second half of the cluster
are omitted. If you stop your deployment targets before you start
atomic rollout, the deployment targets are started when the new edition
replaces the active edition regardless of the reset strategy you choose.
This procedure provides better availability to the requests that are
serviced during the rollout period.
Avoid trouble: 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.
gotcha
Select the reset strategy. The reset strategy
instructs the application edition manager how each deployment target
loads the new edition into the server runtime. Use a Soft reset
strategy to reset the application by stopping or restarting the application
in each server of the cluster as the next edition replaces the old
edition in that server. Soft reset is the most typical choice and
the most optimal performing application reset because it results in
loading the new edition by recycling the application in the running
application server. The server stays up during this process. With
soft reset, native libraries are not unloaded from memory. Soft reset
is generally safe for applications that use no native libraries. When
soft reset is used in a production environment, monitor the application
server process to ensure that sufficient virtual memory exits.
A Hard reset
strategy recycles the each entire application server of the cluster
as the next edition replaces the former edition in the server, refreshing
both process memory and any native libraries used by the application.
This strategy prevents virtual storage exhaustion and allows new versions
of native libraries to be loaded. Select hard reset as your reset
strategy when you perform a rollout on an edition that depends on
new versions of native libraries or other dependencies that are refreshed
only by recycling the entire application server, or if you have large
applications that consume a lot of memory for just-in-time compilation
(JIT).
Set the drainage interval in seconds. The
drainage interval gives the HTTP sessions time to complete before
the application or server is reset. The drainage interval specifies
the amount of time that the application edition manager waits before
the reset strategy starts. Affinities, such as transaction, activity,
and compensation-scope, and activities unknown to WebSphere® Extended Deployment, lengthen the effective
drainage interval because the server does not stop until these units
of work complete. Applications with activities unknown to WebSphere Extended Deployment can use the AppEditionManager
MBean quiesce initiated notification as a trigger to begin shutdown
processing and exploit the drainage interval as a time period during
which to complete the shutdown. This process is unnecessary for persistent
sessions, for example, those backed in database or replicated through
VMware Distributed Resource Scheduler (DRS), but is important for
transient (in memory) sessions.
The goal of the drainage interval
is to allow requests with affinities and inflight requests to complete.
To prevent the loss of transient sessions, set the drainage interval
to exceed the application session timeout interval. After the rollout
starts, as each server updates, the server is marked as ineligible
to begin any new sessions. Set this value to 0 to
not wait for sessions to complete.
For a soft reset, the application
edition quiesce manager waits the full length of the drainage interval
to ensure that any existing sessions can complete. The application
edition quiesce manager waits whether any pending sessions exist or
if the sessions complete before the defined drainage interval time.
For the hard reset, the application edition quiesce manager might
not wait the full length of the drainage interval. Performance Monitoring
Infrastructure (PMI) statistics are available to the quiesce manager
to determine if all active requests on a sever have been quiesced.
If all the requests are quiesced before the drainage interval, the
application edition quiesce manager does not need to wait for the
full drainage interval.
The drainage interval allows existing
sessions to complete. However, at the end of the drainage interval,
a period of time exists during which inflight requests can still arrive.
In such cases, the on demand router (ODR) provides a timeout value
of 60 seconds within which to complete the quiesce operation. If the
requests end within 60 seconds or the 60 seconds expire, the application,
or the server in the case of a hard reset strategy, is stopped. Next,
if inflight requests have still not ended, WebSphere Application Server Network Deployment provides a quiesce time
of 60 seconds before stopping the application or the server instance.
For hard reset strategies, WebSphere Application Server Network Deployment provides
a quiesce time of 180 seconds before stopping the server instance.
You can use the com.ibm.ws.webcontainer.ServletDestroyWaitTime custom
property to define the amount of time that the Web container waits
for the requests to complete. For more information, see Web container custom properties.
You
can use the com.ibm.ejs.sm.server.quiesceTimeout custom property to
define the amount of the time that the server instance waits for the
requests to complete before initiating shutdown. For more information,
see Java virtual machine custom properties. You
must set both the com.ibm.ws.webcontainer.ServletDestroyWaitTime custom
property and the com.ibm.ejs.sm.server.quiesceTimeout custom property
on each of the server instances on which the application editions
are deployed.