|Installation Planning / Hardware Infrastructure|
Understanding the distributed architecture and the known issues help you to work properly in an environment with several connected servers.
Vocera clustering provides a distributed architecture that allows you to locate nodes anywhere on your network, including on different subnets and in different geographic locations. This flexibility is intended in part to provide disaster recovery capabilities from catastrophic events such as an earthquake or a WAN failure.
The flexibility of this distributed cluster architecture requires you to have a stable network environment. In particular, either of the following network problems will cause unwanted cluster behavior:
For Vocera purposes, any network event that blocks all routes between the active node and a standby node is an outage. For example, restarting a switch may cause an outage.
The standby nodes each poll the active node periodically to draw down synchronization transactions. If the active node fails to service a poll from a standby node within 10 seconds, it fails over to one of the standby nodes.
Either of the network problems described above may result in the following cluster behavior:
Multiple nodes become active as independent servers that are isolated from each other (a split brain state).
Some badges may connect to one active server; other badges may connect to another active server.
For more information about how to troubleshoot network problems and Vocera clusters, see the Vocera Administration Guide.