All Blueworx Voice components critical to call handling can be made redundant to provide high-availability if required.
BVR Redundancy
BVR handles call processing and instances of BVR are designed to be ‘disposable’; BVR is configured on-the-fly for each call and an absolute minimum amount of configuration is stored in the instance itself. In the unlikely event of BVR ceasing to respond for any reason, another instance can take over its role; however in-progress calls are not handed over and may be terminated. This design also enables dynamic capacity scaling in virtual environments; surplus instances of BVR can be quiesced and destroyed during quiet periods if required, reducing call capacity and potentially saving Virtual Machine resources/cost.
BRM Redundancy
BRM provides configuration information and monitoring for BVR instances and as such is a critical component for call handling. To mitigate this, multiple instances of BRM can be used to provide redundancy and high availability. Multiple instances of BRM work as a team and are largely self-managing; there is no need to configure a master/slave. The BRM team use a distributed memory pool to share state so that all instances can perform the same at any point.
An instance of BRM can be replaced with a new BRM instance should it become unavailable. The new instance will communicate with the remaining BRM team to establish the current state of the shared memory pool. A quorum is established from existing instances. The minimum quorum size is two machines, if only a single machine is running in the quorum that machine will NOT function. Therefore it is important to have three or more machines in a quorum. If only two machines are used two points of failure have been created, if one fails the other will also stop working. The optimum number of machines in a quorum is an odd number of 3 or more BRM servers.
BRM uses Apache Zookeeper to maintain the shared memory pool.
BAM Redundancy
BAM provides an API for managing the cluster and handles non time-critical requests. It is not critical for handling calls and as such cannot currently be made redundant for instantaneous failover. However, a failed instance of BAM can be replaced immediately, minimising any admin downtime.