High availability for Application Servers

The Application Server type affects how you achieve high availability for the Application Server.

• Job type — These Application Servers are self-managing regarding high availability. Jobs and work items are assigned to different Application Servers of type Job based on resource availability. If an Application Server of type Job fails, the jobs and work items are routed to other running Application Servers of type Job.
• Configuration and NSH Proxy types — These Application Server types require a network load-balancing technology to provide highly available services. A team of load balancers are tied together to present a virtual IP address (VIP) for high availability. The VIP is used by client applications to connect to the Application Server services. When a client is connected to the VIP, the load balancer directs the incoming client connection to an Application Server for servicing. The client is directed to a specific Application Server based on criteria that depend on the load-balancing solution used, including simple round-robin across available servers, open connection counts, server loads, and so on.
• All type — These Application Servers act as a combination of the other types. To provide high availability, an Application Server of type All must be combined with load balancers for the Configuration and NSH Proxy functions, but the Job functions provide high availability on their own.

The following figure shows the high availability (HA) architecture for Application Servers:

For any load-balancing solution that you implement, persistence of the network connection is a requirement. A client that is connected to a particular Application Server must have any newly opened network connections directed at the same currently connected Application Server. This requirement is necessary because no client connection state-sharing exists between Application Servers. As a result, new connections associated with an existing operation could receive errors if they are opened to a new Application Server.

Also, the idle connection timeout setting on the load balancer is important. If timeout values are set too low, clients such as Configuration Manager observe connection closures and timeouts associated with losing and reopening connections to the Application Server.

The Application Server also uses the database and the file server in the TrueSight Server Automation framework. To have a truly highly available Application Server implementation, you must ensure that all architecture on which the Application Server depends is also highly available. For information, see High availability for database servers and High availability for file servers.

The benefits of a highly available architecture for Application Servers are as follows:

• The Application Server infrastructure becomes highly available.
• Loss of a single Application Server cannot take down the Application Server services as a whole.
• The Application Server services can scale horizontally to meet the growth requirements of the organization.
• Scheduled maintenance can occur on an Application Server node without affecting the availability of the Application Server services. You can simply take one of the nodes out of the load-balancing server pool (possibly by using automatic functionality of the load balancer) and perform the required maintenance.

Implementation

To implement a highly available architecture for Application Servers, you perform the following actions:

1. Install multiple Application Servers.
2. Modify the Application Server configurations to use a JDBC connection string that load-balances database connections across all database server nodes. To configure the JDBC connection string, use the BMC Application Server Administration console (blasadmin) or the TrueSight Server Automation Post-Install Configuration wizard. Construct a JDBC connection string for a highly available database by following the instructions provided by the database vendor.
3. Configure the external load balancer to distribute client connections across multiple Application Servers.
4. On the client-facing side of your load balancer, configure a VIP for handling client connections to the Application Server cluster. Configure the load balancer so that connections associated with the Application Server VIP maintain persistence of the network connection. Persistence ensures that, when a client is connected to a particular Application Server, any new connections are opened on the same Application Server.
5. To avoid client visibility of network connection resets, BMC recommends that you set the idle-connection-related timeouts on the load balancer associated with the Application Server VIP to at least 60 minutes (1 hour).

Partitioned Application Servers architecture

In a configuration with multiple Application Servers, consider partitioning the functionality of the Application Servers between handling incoming client connections and running jobs. Such partitioning minimizes the negative impact of resource-heavy job runs on client interactions with the Application Server.

To partition Application Server functionality, you perform the following actions:

1. Define one or more Application Servers as type Configuration. These Application Servers handle client connections only.
2. Configure the load balancer to direct client connections first to the Application Servers of type Configuration. Only when Application Servers of type Configuration are unavailable should the load balancer direct a client to the Application Servers of type Job.