To use the application edition manager to rollout Compute Grid
applications, you must own the WebSphere Extended Deployment Operations Optimization
component. Compute Grid applications are Java 2 Platform Enterprise Edition
(J2EE) applications that conform to one of the grid programming models. By
rolling out an edition, you replace an active edition with a new edition.
Before you begin
You must have an application edition that is installed and started,
and have
configurator or
administrator administrative privileges
to perform this task.
Note: Application edition rollout fails when two user
ID's on two administrative consoles attempt a parallel application edition
rollout.
About this task
The new edition might be a simple modification to the application,
such as a bug fix, or a more substantial change. As long as the new edition
is backward compatible, it can be rolled out to replace the active edition
without impacting existing clients. To roll out a new edition, you must first
install the application edition with the new edition information.
Procedure
- Install the new edition. 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
the Applications > Edition control center > application_name.
Select your new edition, for example, 2.0, and click Rollout.
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
is large. 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 is very large, consider
dividing up your rollout into smaller groups by using group rollout. Atomic
mode can also be 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.
- 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 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 best performing application reset, because it
loads 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 are rolling out an application 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 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 is unnecessary for persistent sessions, for example, those
backed in database or replicated through DRS, but is important for transient
(in memory) sessions. 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.
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.
- Launch the rollout. Click OK. This action launches
an interruption-free replacement of the older 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. 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
Applications > Edition Control
Center > application_name. Your new edition should be the active
edition on deployment target. The new edition automatically starts, because
it replaces a running edition.
When an application edition in validation
mode is rolled out, the binding names must be changed back to the original
values. For example: /clusters/cluster1-validation/jdbc/CustomerData must
be changed back to /clusters/cluster1/jdbc/CustomerData.