Remedy high availability deployment

High availability (HA) refers to the ability of a system to remain available at all times. The goal of HA is to ensure that a service remains available always, even in case of failure. For example, when a server providing a service fails, another server continues the processing and takes the workload of the failed server. By doing this failover, you can ensure uninterrupted service to the user. Most of the Remedy products support seamless failover, where you do not have to log in again if the currently connected server becomes unavailable and the services fail over to a secondary server. However, you might have to log in again in certain scenarios in case of a failover. 

Achieving high availability in Remedy

You can achieve HA by standard horizontal scaling to remove single point of failure. To build a highly available system, each tier in Remedy-web tier, server tier, and data tier-must to be built with redundancy. For example, for a basic deployment of the Remedy web tier, you can have one server where you can deploy all the web tier components. However, if you want to implement HA for the same web tier, you must add at least one more server so that if the primary server becomes unavailable for any reason, the redundant server can take the load, thereby eliminating or minimizing the downtime. You can use a virtualized environment for the HA deployment; duplicate the entire deployment model and allocate enough resources to the virtual machines.

You must also add load balancers so that any one server does not become overloaded. Other devices such as load balancers and firewalls should also be considered for redundancy, as a failure at any of these levels can cause the service to become unavailable.

High availability deployment of the server tier

The Remedy AR System server provides a built-in mechanism called server groups that allows multiple Remedy AR System servers to share responsibilities among themselves. With such a setup, the load is distributed by the load balancer, and the servers collaborate to manage the execution of batch operations and administrator responsibilities. 

A server group typically consists of multiple AR System servers that run in a cluster. You can distribute the load between them by using a third-party load balancer. All of these instances work on the same database, so they are always in sync. This is a typical server group configuration. This clustered environment creates a highly scalable and highly available Remedy AR System installation. You can also assign rankings to servers in the server group for specific Remedy AR System operations. If any one server becomes unavailable in a server group, the workload of that server can be taken up by other servers in the group based on the rankings, thereby providing high availability. 

The following example uses a load balancer to direct traffic to a server group of three Remedy AR System servers. In the following figure, one of the Remedy AR System servers has the primary ranking for the Administration and Escalation operations. The other two AR System servers can be used to back up these operations, when the primary server is not running.

HA-1.png

BMC CMDB and Remedy ITSM applications run as hosted applications inside the Remedy AR System server. They inherit the same level of HA with which the Remedy AR System server has been configured.

High availability deployment of the web tier

Each web tier component is hosted in a separate Apache Tomcat web container. Depending on your requirement, you can install all the web tier components on one server where each component runs on different Tomcat instances, on multiple servers where each component is installed on a separate server, or in combination of the two. To achieve HA in this tier, you can run multiple web tier servers simultaneously, with a load balancer distributing the load among the different instances. If one of the web tier server fails, the load balancer detects the failure and directs traffic to the available servers.

The following diagram shows a redundant deployment of the web tier components. In this deployment model, each web tier component is installed on a separate server. For HA, an additional server is included for each component.

HA-2.png

High availability deployment of the data tier

For a highly available deployment, ensure that the database is redundant. The redundancy at this tier is based on the options provided by the database vendor. Typically this is done with grid or clustering technologies, or replication. For database HA, we recommend that you use the vendor's technology or a third-party solution (for example, Oracle Real Application Clustering, Microsoft Always On, or Microsoft Peer to Peer Replication).

Related topics


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*