Shared Database Across Multiple Clusters
Blueworx Voice Response 7.18 enables a single database to be shared with multiple clusters even when each cluster has their own Zookeeper Shared Memory quorum. This has significant benefits in situations where multiple clusters are required, such as for geographic redundancy, but a single configuration database is preferred to ensure the multiple clusters function as a single system. Previously, either a separate database for each cluster or a shared Zookeeper quorum across sites was required.
BVR for Linux uses Zookeeper technology to provide resilient Shared Memory across a cluster of BVR components, enabling redundancy, scaling and reliability. It is also used for signalling between components. However running Zookeeper across geographies can introduce challenges.
Previously, when Blueworx Admin Manager (BAM) modified the database, it notified any BRMs in the cluster via Shared Memory to refresh their cache of the database (Diagram 1). 7.18 now uses the database itself to trigger a notification to any BRMs that they need to refresh their cache. As a result, any modifications made by BAM on Cluster A is propagated to Cluster B even though they are not in the same Shared Memory quorum (Diagram 2).