Error: Invalid spaceKey on retrieving a related space config.

Service failover

A companion service is a process that the operating system starts (typically, when the system starts up) or that armonitor starts. These processes communicate with the AR System server by using the BMC Remedy AR System API to get their work and to create or change entries. In the BMC Remedy AR System environment, companion services provide services such as the Email Engine sending outgoing emails and handling incoming emails. You can deploy these services in a server group, which provides resiliency if something fails. The servers in the group cooperate to manage service failover. The server group manages when the companion services become active to perform tasks and when they are suspended. Also, the companion services are tracked and can fail over independently of any AR System server.

In this topic:

Companion services periodically assert their current state in the form of a heartbeat. This heartbeat informs the AR System server of the companion service's state. When the AR System server does not detect a companion service's heartbeat, it instructs another companion service to take over.

Note

Companion services do not have to run on the same computer as the AR System server. Furthermore, multiple companion services can run on the same computer.

The following figure shows an example of a server group with companion services. Two companion services (Email Engine instances) access the AR System server group through a load balancer.

Example configuration of a server group with companion services


The load balancer provides a single connection point, attempts to direct the load across all nodes in the server group, and routes clients to active nodes in the server group when a node is inactive due to a failure. Clients access the server group through the load balancer.

One companion service can perform multiple services. In this example, one Email Engine instance can provide a service for sending outgoing emails and another service for handling incoming emails. In such a configuration, each companion service can own, or have exclusive rights to perform work on, any number of services. This configuration enables both companion services to process work. (However, only one companion service can own a given service at a time.)

The companion service, in this case, would house two service providers (Email Engine instances). The service providers' states are stored in a AR System form, and the server group manages those states.

If the AR System detects that a companion service's heartbeat has stopped, it can instruct another companion service to take over. Each service provider can fail over independently of the other servers and independently of a given AR System server.

To ensure high availability in a server group environment, the email engine must point to the load balancer or the AR server name.

Monitor service failover

The following forms enable you to monitor or manage failover:

  • AR System Service Failover Ranking — The form that you use to manage the ranking of each service provider. You can view and change entries in this form. To change the ranking of a service provider, see Changing the ranking of a service provider.
  • AR System Service Failover Whiteboard— A form that stores the current status of all service providers. You can use this form’s entries to see which clients are:
    • Providing a service
    • Waiting to provide a service
    • Unavailable

Warning

Do not modify the existing workflows on these forms.

 The following topics provide information about service failover:  

Was this page helpful? Yes No Submitting... Thank you

Comments

  1. Seth Mcculloch

    How is this concept different from Server Group ranking?  Email in particular seems to exist in both places.

    Feb 06, 2017 03:30