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.
As long as the new edition is backward compatible, 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.
Note: Performing a rollout
fails when two user IDs on two administrative consoles attempt to
complete the process in parallel.
Note: 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 the rollout using the wsadmin tool, adjust
the request timeout value by setting the com.ibm.SOAP.requestTimeout
property in the soap.client.props in the deployment
manager profile. The default value is 180 seconds and should be increased
adequately.
- If you are performing the rollout using the administrative console,
adjust the request timeout value by clicking . The default
value is 600 seconds and should be increased adequately.
For more information, see
Java Management Extensions connector properties.
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, see Changing the console session expiration.
Note: If you have multi-cluster routing
policies (MCRP) defined for existing application editions, you must
create and define a new MCRP rule for each new edition before you
can perform a rollout. MCRP rules apply only to specific editions
as opposed to all of the editions for an application. See
Rules for ODR routing policy administrative tasks for more information.
About this task
You can also use the application edition
manager if you are using the Compute Grid component
and want to perform a rollout to Compute Grid applications. These are Java Enterprise Edition 5 (Java EE
5) applications that conform to one of the grid programming models.
Procedure
- Install the new edition. Use the same steps
that are described in Installing an 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, 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.
Note: 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.
- 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® Virtual Enterprise, lengthen the effective
drainage interval because the server does not stop until these units
of work complete. Applications with activities unknown to WebSphere Virtual Enterprise 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.
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.
For
a Compute Grid application,
after the drainage time, the job scheduler will cancel those jobs
(of the rolling out application) which are still running on the quiesced
endpoints.
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.
Attention: Edition validation does
not work properly for applications that are deployed on a dynamic
cluster that is converted from a static cluster.