When you perform a rollout on an edition, you replace an
active edition with a new edition. The new edition might be a simple
modification to the application, or contain a more substantial change.
If the new edition is compatible with earlier versions, then you can
perform a rollout to replace the active edition without impacting
existing clients. To perform a rollout on a new edition, you must
first install the application edition with the new edition information.
Before you begin
You must have an application edition that is installed and started, and have
configurator or
administrator privileges to perform a rollout.
- Performing a rollout fails when two user IDs on two administrative consoles attempt to complete
the process in parallel.
- Tune the SOAP connector properties to set the request timeout value for the deployment manager
to be greater than the total time required to perform a rollout on your system, and restart the
deployment manager. Not setting the property can cause the rollout process to fail when the
requestTimeout value expires. The formula to estimate the value to set is
number-of-groups-to-rollout * (drainage-interval +
internal-quiesce-timeouts-approximately-5minutes +
application-or-server-restart-times-approximately-10minutes). Alternatively, you can set
the value to zero to disable the timeout.
- If you are performing a rollout within the administrative console, set the session expiration
for the administrative console to a value greater than the amount of time required for the entire
rollout process to end. Multiply the request timeout value by the number of groups processed during
the rollout. For more information about session expiration for the administrative console, read
about changing the console session expiration.
- You must define a multi-cluster routing policy for each new edition you install before you can
perform a rollout. Use the administrative tasks to add multi-cluster routing policies for your new
editions. For more information about multi-cluster routing policies, read about rules for ODR
routing policy administrative tasks.
About this task
You can also use the application edition manager if you
want to perform a rollout to batch applications. These are Java Enterprise Edition 5 (Java EE 5) applications that conform
to one of the batch programming
models.
Procedure
- Install the new edition. Use the same steps
that are described in installing an application edition, but specify
your new edition information. For example, type 2.0 in
the Application edition field and Second
edition in the Application description field.
Select the same deployment targets that are used for the current edition.
- Save and synchronize your nodes.
- Specify the rollout settings. Click . Select your new edition, for example, 2.0,
and click Roll out.
Specify the following
settings for enterprise or other middleware applications:
- 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
about group rollout, 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 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 Intelligent Management,
lengthen the effective drainage interval because the server does not stop until these units of work
complete. Applications with activities unknown to Intelligent Management can
use the AppEditionManager MBean quiesce initiated notification as a trigger to
begin shutdown processing and use 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 wait for sessions to complete for all inflight
requests. To wait until the drainage interval or sessions complete for all inflight requests, set
the drainage interval to a value greater than 0.
The application edition
quiesce manager might not wait the full length of the drainage interval. Performance Monitoring
Infrastructure (PMI) statistics are available for the quiesce manager to determine if all active
requests on a server have been quiesced. If all requests are quiesced before the drainage interval,
the application edition quiesce manager does not need to wait for the full drainage interval. To
force a soft reset to wait the entire drainage interval, you can set the
appedition.rollout.softreset.fulldrainageinterval system property to true on the
deployment manager.
The drainage interval allows existing sessions to complete. However, at
the end of the drainage interval, a period 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, read about
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 about the timeout property, read about 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.
Specify the following settings for Session Initiation Protocol
(SIP) applications:- Choose a quiesce strategy. The quiesce strategy
specifies how old servers or cluster members that host the current
edition are removed. This setting does not affect the new edition
that is being rolled out.
- Quiesce server or cluster members after all active sessions or
dialogs are completed:
- Removes the server or cluster member when all of the active sessions
and dialogs for the server or cluster member complete.
- Quiesce servers or cluster member after the specified interval:
- Removes the server or cluster member after a specified time period.
Specify an amount of time, in seconds, minutes, or hours.
Attention: Performing
a rollout is not supported for SIP applications that are deployed
on a dynamic cluster that has been converted from a static cluster.
- Start the rollout. Click OK.
This action launches an interruption-free replacement of the previous
edition with your new edition.
Results
For an edition that is not in validation mode, the new
edition replaces the current edition after the rollout completes.
An edition that is in validation rolls out on the original deployment
target and the cloned environment is deleted. The routing rules are
updated to begin routing to your new edition.
During the application
rollout process, errors that occur in the first group of targets are
handled differently than errors that occur in later groups. In atomic
rollouts, the first group is the first half of the targets where the
new edition is activated. In group rollouts, the first group refers
to the first group of targets where the new edition is activated.
If an error occurs during the rollout on the first group of targets
(for example an application or a server fails to start), the rollout
process fails. The current application edition remains in active state.
If an error occurs after the rollout on the first group of targets,
the rollout process completes successfully. The new application edition
is now in active state. The old application edition moves into inactive
state.
What to do next
To validate the results, click . Your new edition is the active edition on the deployment
target. The new edition automatically starts, because it replaces
a running edition.
When you perform a rollout on an edition
in validation mode, the binding names are changed back to the original
values. For example, /clusters/cluster1-validation/jdbc/CustomerData is
changed back to /clusters/cluster1/jdbc/CustomerData.