Default language.

Monitoring and managing 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  by using the  API to get their work and to create or change entries. In the , companion services provide services such as the  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 .

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

Companion services do not have to run on the same computer as the . 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 ( instances) access the  group through a load balancer.

Example configuration of a server group with companion services

HighLevelArch.jpg

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  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 ( instances). The service providers' states are stored in a  form, and the server group manages those states.

If the  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 .

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

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:

 

 

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