was V8.5 application versioning, dynamic clustering, health management, and intelligent routing

Intelligent management includes application versioning, dynamic clustering, health management, and intelligent routing. This article mainly introduces you to application version management.

IBM released the WebSphere creator Server (WAS) V8.5 on June 15, 2012. A significant change in was V8.5 is that the functionality of the previously independent product WebSphere Virtual Enterprise (hereinafter referred to as WVE) was fully incorporated into was. The related functionality previously provided by WVE, in was V8.5, is called intelligent management. Intelligent management includes application versioning, dynamic clustering, health management, and intelligent routing. This article mainly introduces you to the Application version management feature.

The goal of application versioning is to deploy and manage application versions with uninterrupted external service.

Application Versioning Manager

Uninterrupted production application deployment is controlled by the application version manager, which is the core component of application versioning. When you install application updates in such environments, you enable applications to provide uninterrupted service to the outside world.

The Application version Manager provides an application versioning model that supports multiple applications of the same application in an intelligent snap-in. A unique version name is used for each deployment. The application version Manager allows you to select the version you want to activate on the smart management cluster, so that you can perform an outbound application update or revert to a previous level.

The application versioning Manager is fully integrated with intelligent management to interact with the On Demand router (ODR), dynamic workload balancing, and application placement manager. This integration ensures that application behavior can be predicted when updates are made to the application and that the system continues to manage application performance goals while ensuring smooth transfer from one application version to another. You can use the administrative console to access the application update process, which includes version activation operations between application servers. Scripting application programming interfaces enables versioning to integrate with automated application deployments.

The Java EE application supports the application version, including the EAR file and batch applications that conform to the batch programming model.

Was itself provides a management function called a spin out update. The move out update provides a basic application upgrade, but it is intermittent. The application version Manager is the preferred way to upgrade your application. The application version Manager supports the entire lifecycle of the application and supports updates to applications running in a production environment and seamless, uninterrupted application deployment.

Operating Environment

The environment in which the application version Manager runs is an intelligent snap-in. As the following illustration shows, application version Manager manages applications deployed to dynamic clusters that accept work requests through the On Demand router (ODR).

Figure 1. Application version Manager diagram with ODR and dynamic clustering

Intelligent Management also supports SIP protocols

The application version Manager provides uninterrupted application updates, but is limited to accessing applications via the ODR through HTTP and HTTPS. During an application upgrade, if you do not use HTTP and HTTPS and use another ODR layer to achieve access between applications, you cannot ensure continuity of the services that are accessed, for example, the service continuity of a Java EE application's invocation of another application.

Version compatibility

Only version-compatible application upgrades are supported for this application version manager, which means that non-disruptive upgrades are only available for versions that are compatible with previous versions. When you deploy a version that contains incompatible changes, you may need to take a parallel activation mode and use routing rules to isolate the request traffic between the previous version of the user and the current version of the user. With parallel activation, you can charge multiple versions of the same application at the same time, and each version supports a user set that is different and does not intersect. However, concurrent activation may not provide an uninterrupted upgrade.

When deploying an application version, consider the following compatibility issues:

Application interface or semantics: When you try a version switch, if the interface between the application versions or the semantics changes, the active user who is using the application is affected. Examples of changes include changes to existing interfaces, including modifying or removing existing interfaces. In addition, the changes in the behavior of the docking of colloquial meaning will also affect the existing activities. For example, if an interface originally allowed a parameter to be null and then modified to require that the same parameter not be null. Changes that affect the user today are considered not backward compatible or as part of a continuous update. If the impact on existing users is not a problem, then you can consider using was's to move out of the update. HTTP session state: If the HTTP session state is either persistent or replicable, adding or altering the type of data stored in the session is also considered incompatible. The current version may not be able to use session state information created by previous versions. Web Content Caching: If the new version of the application contains caching for static WEB content, and you are using the ODR to cache content, you may need to manually clear the cache when the version is turned out.

Version and Edition

Terminology Version and Edition are distinguished from the build environment to the deployment and operating environment. Version is a collection of successive generations of interfaces, functions, implementations, or entire applications. Version is a development and build concept. Edition is a continuous deployment of generations, for example, for a set of version-controlled specific artifacts. Edition is a concept of deployment and operation.

The application version refers to the unique deployment of a specific application. In the was management environment, application versions are uniquely identified by the combination of application name and version name. Although multiple versions of the same application have the same application name, they have different version names. The version name can be a number, such as 1.0 or 2.0, and the name is descriptive, such as the edition or Blue Edition.

Version Transfer algorithm

Many business applications require stable availability. The standard for application availability advocates deploying applications on the application server cluster. Cluster redundancy is critical to providing continuous availability. Continuous application update refers to the ability to update while maintaining application availability. In other words, users of the application will not experience service outages during application updates.

When a release is performed on a version, the active version is replaced with the new version. To provide non-disruptive application updates, the perform a spin out operation on a version contains the following items:

prevents the server from receiving new requests. A request to stop an application on a specific server. Stops the currently active version. Start a new version. Restores the request stream to the new version of the application.

There are two basic modes of continuous updating: Group transfer or Atom transfer. The steps that are taken when you turn out a new version vary according to the selection.

Note: The mode of the dynamic cluster is placed manually during the transfer. If the load becomes heavier during the transition, then intelligent management does not perform load balancing operations, so avoid running out at the peak of the business. When the switch is over, the dynamic cluster returns to its original mode.

Group out

Grouping out is to divide the servers in a cluster into groups and define the size of the group, which is the number of nodes to be processed at once. Performing a spin out on a group allows the servers in that group to be updated to the new version at the same time. In the admin console, you can perform a spin out operation only on one group at a time. When any member in the new version becomes available, all requests are routed to the new version.

When you turn on version execution, some servers in the cluster have switched from the old version to the new version, some are switching, and the other servers have not started switching. If an application on any server is the latest version and its instance is active and running, all application requests are sent to that server. For example, when you perform version 1.0 through 2.0 transfer operations, once version 2.0 becomes available on a server, all application requests are processed by version 2.0. Any server that is still running version 1.0 will not process the request until the server is updated to version 2.0. The following is a group spin out diagram:

Figure 2. Example of group turn production

When the execution group is turned out, it is transferred across the cluster in the server group. Each server performs the following steps:

pauses to send a request to the server. Stop the application or stop the server. Update server configuration. Restart the application or server. The server is ready to use the new version of the application.

Atoms turn out

Performing an atom out of a version is to replace the version on half of the cluster at a time to process all user requests using a consistent version of the application. All user requests are processed by an older version or a new version, not by two versions at the same time.

The atom turns out to ensure that all application requests are processed by a consistent version, for example, by version 1.0 or 2.0, rather than both. The available versions of the current version are offline from the server that makes up half of the cluster. Although the new version is activated and started on those servers, those servers remain offline until the next step is complete. The next step is to make the currently active version of the server on the remaining half of the cluster offline. No old version or new version of an instance can be used to process application requests at this time. The ODR will temporarily queue any requests that arrive at the application. After the application on the latter half of the cluster is offline, the first half of the cluster is returned to the online state. The second half of the cluster switches from the previous version to the new version and returns to the online status. The following example is an atomic spin out diagram:

Figure 3. Atom spin out schematic diagram

Before you perform an atom transfer, you need to determine the load capacity of the target server cluster. In fact, only half of the clusters have service requests when the atom is executed. So when choosing an atom to go out, it's best to verify in advance whether half of the cluster can handle the entire load during the transfer.

When you choose to perform an atomic spin out, the following steps are performed:

The

pauses to send a request to half the server. Stop the application or server in the first half of the server. Update the configuration to activate the new version of the application. Start the application or server in the first half of the application server. Pause backward half the server sends the request. Starts routing the request to a new version of the first half of the server shipment. On the second half of the server, stop the application or server, update the configuration, and then start the application or server. Turn out to finish.

Two typical usage scenarios

Next, I'll give you an example of two typical scenarios for application versioning: Parallel activation and version validation

Parallel activation

Parallel activation is the simultaneous activation and enabling of multiple versions of the same application. A version that is active in parallel can provide a group of users with access to one version and another to other users. When using parallel activation, you must establish a routing policy to differentiate users who have access to a version. The routing policy is part of the application configuration metadata. In addition, the routing strategy prevents ambiguity and determines which version acquires control.

Use Scenario Example: a telecom operator

User requirements: Due to geographical differences, tariff standards, package content, promotional activities are also different, so need the same application in different versions of the local version, and require that these versions run at the same time, according to user login IP to the user request routing to the corresponding version of the application up.

Figure 4. Parallel activation scene diagram

Operation Process:

You must first install at least a different version of this application to a different target cluster. For example, My_application Application 1.0 is installed on the dynamic_cluster_1 dynamic cluster, and application version 2.0 is installed on the dynamic_cluster_2 dynamic cluster, and so on, and so on how to install the application see Reference resources.

activates the application version. Click Application > Version Control center > application_name. Select the inactive version and click Activate. In order to be able to route requests from different IP to different versions of the application, we need to set the routing strategy in advance, and see the reference resources to verify that the ODR is working correctly. Click the server > On Demand router. To route a request, the state must be started.

This completes the parallel activation, and the ODR routes the request to a different

Verify version

Verify that a version is a process that determines whether the new version is available and is ready to move to the production environment and replace the current version. It clones a production environment that is identical to the production environment for new versions of the test. In this way, your production application can continue to maintain requests while installing and validating new versions under real production conditions.

Use Scenarios for example: a global shopping site

User needs: Shopping site competition is fierce, according to market conditions, at any time to launch and update promotional activities, to request a new version of the online before, can be in the same environment with the production environment for testing, and requirements in the application of the update, uninterrupted service to the outside.

Figure 5. Verifying version Scenario diagram

Operation Steps:

First, make sure that the application is in the same dynamic cluster. Version 1.0 is active and runs on a dynamic cluster. Version 2.0 is a candidate-verified version, and the same dynamic cluster is installed and inactive.

Click Application > Version Control Center to verify that the two versions of the application are installed, and that only one of the versions processes the active state. In version control center, select version 2.0 and click Verify. The Validation status page shows you how to verify the new version on the dynamic cluster dynamic_cluster and the first step on the release 2 to the clone cluster. The application and Order version control center shows that one version is in the authentication mode, and the Manage Versions page shows that version 2.0 is deployed on the dynamic_cluster-validation dynamic cluster. The Dynamic clustering page shows a dynamic cluster of clones such as Dynamic_cluster-validation, and the server page shows the cloned server.

Tip: The clone dynamic cluster that is used for validation is deleted after the transfer is performed or when the validation is canceled. If you want to keep the cluster, you can preserve the validation cluster by setting Saveclonedcluster custom properties on the validation cluster.

verifies that validation is performed correctly. Click Application > Enterprise applications or Applications > All applications, select version 2.0 applications, and in the management module, verify that version 2.0 is mapped to a validation cluster. Test the new version. Start the validation cluster and set the routing rules.

Now you can test the new version of the application in a real production environment, and after the test is done, you can go out and switch to the new version.

Summary

This article introduces you to the application versioning features in intelligent management in the was V8.5. It enables you to deploy and update the application version with uninterrupted external service, and introduces two different versions of the release mode, and two typical scenarios that are used by the application version management. Hopefully this article will help you understand the Intelligent management feature in was.