VSP High Availability

For best results when implementing a high-availability solution using multiple instances of VSP, implement a round-robin solution with online-offline status using a load balancer.

• The load should be distributed evenly between available VSP instances.
• The VSP instances should all point to the VMP Server, or to an internal VMP load balancer if VMP has been implemented in a cluster deployment.

If you are implementing the Vocera Smartphone Proxy in a high-availability solution, these tests will be of use to you.

• http://<serverid>/vsptest: This query checks the status of the VSP.
• http://<serverid>/WIC?query=test: This query is terminated on the VMP Server, and tests the status of VMP and the connection between the VSP and the VMP Server.

<serverid> is the VSP IP address or domain name. The interval between tests using http://<serverid>/WIC?query=test should be identical to the timeout interval on the VSP (this is normally 30 seconds).

If two consecutive queries fail on a particular instance of VSP:

• This VSP instance should be considered unavailable.
• The load balancer should route traffic to the other available VSP instances.
• An email notification should be sent to the administrator, along with the results of the http://<serverid>/vsptest query. If this query fails, this VSP service is down and should be considered offline, and the administrator needs to attend to the server (for example, restart the server or start up the virtual machine). If this query passes, it may indicate that either the VMP Server is unavailable or the connection to it is unavailable. In this case, the administrator should look at the VMP Server or the connection between it and the VSP.

http://<serverid>/WIC?query=test queries should continue. If a query passes, this instance of VSP is again functional and can be considered online. The load balancer should redistribute loading to this VSP instance.