Use IBM pureapplication System to achieve high availability across multiple sites

Brief introduction

Pureapplication System provides a flexible platform to run the various application workloads in the cloud infrastructure. This design is designed to enable applications running on the rack to achieve high levels of availability to help eliminate single points of failure.

Enterprises that pursue the highest level of flexibility must consider how to run their workloads across multiple systems and geographically dispersed data centers, leaving no hardware, local network, or power supply problems with long service outages.

This article describes a design for a multi-site environment that uses pureapplication System and describes how application workloads deployed across these two sites continue to provide high availability through a series of possible failure scenarios. In writing this article, the author takes into account the interests of the infrastructure and application architects to help them understand how to use the Pureapplication System to meet the more demanding non-functional requirements.

Article Pureapplication System's high-availability topology describes some of the high-availability topologies that are used to implement applications and multiple rack settings running on the pureapplication system rack, and we recommend that you read the following article first, Then continue reading this article.

Building High Availability Web applications

A real high-availability solution needs to span multiple geographically dispersed data centers. In this article, we will discuss a design that assumes that we have the pureapplication System rack running on the same application in two different data centers, and that there is a wide area network between them. The network infrastructure includes load Balancing to distribute the application's user requests evenly across two sites.

Before we discuss our design further, we need to select an application type to focus on. The application infrastructure is a key consideration when designing a topology that supports high availability. Questions such as where the topology data is stored in the application and what methods are used to handle continuous user requests in the application will affect how the choice of high availability services is implemented. For example, if the user's shopping cart state is stored in memory between successive user requests, the High-availability infrastructure must consider the behavior that needs to be performed if the component is affected by a run outage. By choosing a simple, commonly used sample application infrastructure and making some assumptions about it, we can provide a brief introduction to the topic.

We focus on a typical three-tier Web application infrastructure consisting of application servers that have been configured with a Web server and supported by the database. To further simplify the discussion, we assume that all application data is stored in the database and that no data is stored in the application tier. In this way, we will focus on how to implement the high availability of applications running on Pureapplication System without making the discussions around data replication and parallelism more complicated. These important topics will be discussed further in subsequent articles.

We also assume that the database components of an application are managed on a separate infrastructure of the WEB application, which is the practice of most user environments. Of course, databases should also be highly available, so applications running on Pureapplication System will connect remotely from each data center to a highly available database infrastructure. Finally, we assume that the client has redundant load balancing, and that as part of the core network functionality, requests can be distributed across remote data centers.

Figure 1 shows an overview of the sample settings, which contains the features we described.

Figure 1. Overview of a sample multisite setting

This infrastructure allows the racks to be located in geographically dispersed data centers, and these racks operate in "active-active" mode. This means that two of racks can handle the real-time generation requirements of the user in a normal operating environment. If a rack or data center fails, the user request is routed to the operating rack and continues to receive service. After the problem is resolved, the load will be processed by both racks.

Applications deployed across two systems

Let's take a detailed description of the pureapplication System in this setting. Because we focus on the Web application, we need a Web server, an application server, and the application itself, which are arranged in a topology that supports high availability. This is useful for discussing practical applications, so let's take tradelite as an example.

Sample WEB Application and database

Tradelite is an IBM WebSphere Application Server End-to-end benchmark program and performance sample application. The benchmarking program is designed and developed to understand the broad programming model of WebSphere. This provides an actual workload that facilitates the WebSphere implementation of the Java Platform Enterprise Edition 1.4 and WEB services, including key WebSphere performance components and features.

Tradelite does not rely on any state that needs to be maintained on the application server layer, and its associated databases run on remote database servers that fully match the design of the sample settings.

To achieve high availability service levels, applications need to run on clustered application servers, so application requests can be serviced across multiple nodes on each rack. To implement this on the Pureapplication System, you can select a WebSphere pattern as the standard –websphere cluster model that provides this cluster functionality.

WebSphere cluster mode

The WebSphere cluster pattern is a virtual system pattern.

Figure 2 shows the custom WebSphere cluster pattern in the Pureapplication System mode editor.

Figure 2. Custom WebSphere cluster Virtual system mode