Perform a rollout on an edition

When we perform a rollout on an edition, we 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 we can perform a rollout to replace the active edition without impacting existing clients. To perform a rollout on a new edition, first install the application edition with the new edition information.

We must have an application edition installed and started, and have configurator or administrator privileges to perform a rollout.

• Perform 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 the 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, we can set the value to zero to disable the timeout.

  • If we are performing the rollout using the wsadmin tool, adjust the request timeout value by setting...
    com.ibm.SOAP.requestTimeout

    ...in the soap.client.props in the deployment manager profile. The default is 180 seconds and should be increased adequately.

  • If we are performing the rollout using the administrative console, adjust the request timeout value by clicking...
    System administration > Deployment manager > Administration services > JMX connectors > SOAPConnector > Custom properties > requestTimeout

    The default is 600 seconds and should be increased adequately.

• If we 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.

We can also use the application edition manager 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.

Perform a rollout on an edition

1. Install the new edition.

   Use the same steps described in installing an application edition, but specify the 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 used for the current edition.

2. Save and synchronize the nodes.

3. Specify the rollout settings.
   Applications > Edition control center > application_name

4. Select the new edition, for example, 2.0, and click Roll out.

   Specify the following settings for enterprise or other middleware applications:

   1. 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, we can perform group rollout with a specified group size through scripting. 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 our 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 we stop the deployment targets before starting atomic rollout, the deployment targets are started when the new edition replaces the active edition regardless of the reset strategy we choose. This procedure provides better availability to the requests serviced during the rollout period.

      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.

   2. 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 the reset strategy when we 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 we have large applications that consume a lot of memory for just-in-time compilation (JIT).

   3. 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, we 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, WAS Network Deployment provides a quiesce time of 180 seconds before stopping the server instance. 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.

      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. We 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 SIP applications:

   1. 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 being used 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.

      Perform a rollout is not supported for SIP applications deployed on a dynamic cluster that has been converted from a static cluster.

5. Start the rollout.

   Click OK. This action launches an interruption-free replacement of the previous edition with the new edition.

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 the 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...

Applications > Edition control center > application_name

Your new edition is the active edition on the deployment target. The new edition automatically starts, because it replaces a running edition.

When we 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

Subtopics

• Algorithm for performing a rollout
  

Related:

Application edition manager concepts

Changing the console session expiration

Install an application edition

Perform a rollback on an edition

Activate concurrent application editions

Validate an edition

Intelligent Management: routing and service policies

Intelligent Management: administrative roles and privileges

Intelligent Management: application edition management administrative tasks

Intelligent Management: application edition manager custom properties

Java Management Extensions connector properties

Intelligent Management: rules for ODR routing policy administrative tasks

Web container custom properties

Java virtual machine custom properties