|Status / Voice Cluster|
When a failover occurs, a new node becomes active and takes control of the cluster almost immediately.
The telephony server connects to the new active node several seconds later and then becomes available for calls. Badges try to find each server in their cluster list until they locate the new active node and connect to it. The entire system—voice service, telephony server, and badges—becomes available a few seconds after a failover occurs.
Following is the sequence of events that occur during a failover:
The voice service on the active node fails, resulting in the following events:
The voice service control panel on this failing node closes and the command window displays the message Restarting All Processes.
If the badge is in a call with another badge, both badges drop the call within 30 seconds. Badge-to-badge calls often persist for a short while after the active node fails because the server is not directly involved in the call after the initial set up.
If the badge is in a call with a phone, the badge drops the call immediately, and the phone drops the call after the telephony server connects to the new active server (within about 30 seconds).
Standby nodes continue to look for the most recently active node at 3-second intervals and find out that it is not responding.
When the active node does not respond, standby nodes go into discovery mode to determine the status of the other cluster nodes.
The first node to enter discovery mode becomes active and takes control of the cluster.
If multiple nodes are in discovery mode at the same time, the node at the top of the list becomes active and takes control of the cluster.
Badges and the telephony server look for the servers in their cluster list until they find the new active node and then connect to it.
When you first configure the Vocera SIP Telephony Gateway, specify the current active cluster node or the list of cluster members. Since the telephony server stays in contact with the cluster, it dynamically maintains the cluster list when nodes are added and removed.
When you first configure the badges, you specify the current active node or the list of cluster members. You must then maintain this cluster list in badge.properties when cluster nodes are added and removed.
Because badges are mobile, they can be off-network when the cluster membership changes. However, as long as a badge can locate any current cluster node—even if it is not the active node—it can still connect to the active node and download the current cluster list in badge.properties.
The voice service node that failed restarts, goes through the discovery process, and comes online as a standby node.