A major U.S. telecommunication service provider needed to offer the HPE OpenCall INS cell phone application with considerable customizations to its customers. One of its customers had nine total nodes in its architecture; and the system had to survive the loss of one or more of these nodes. The customer’s nodes also needed to be geographically distributed to provide regional disaster tolerance.
HPE Shadowbase Solution: Homogeneous Active/Active Systems
In Figure 1, nine HPE NonStop servers are shown, eight are subordinate nodes, which are connected to the master node in an active/active configuration via Shadowbase bi-directional replication. Please note that in this architecture, data collisions can and do occur.
Figure 1 — Shadowbase for Scalable Homogeneous Active/Active Systems
- This application is configured as a multinode, bi-directional, active/active system, which the company calls the “N+1 Geographic Redundancy Option.” It allows the entire clustered solution to survive the loss of one or more nodes, depending upon the total number of nodes in the system.
- Each node uses a NonStop server that actively runs the application and processes any request, and are load-balanced (routed) to the least busy node.
- The databases of the various nodes are kept synchronized via asynchronous data replication.
- One node is selected as the “master” node and the other nodes are “subordinate” nodes. If there is a data collision, the database update algorithm is “first to update the master wins.”
- Changes to the master node database are always directly replicated and applied to each of the child node databases (the master always wins).
- Changes to a subordinate node’s database are directly replicated to the master node, and if no data collision occurs, they are replicated back to all subordinate nodes and applied. If a data collision has occurred at the master (because two or more subordinate nodes updated the same data item at the same time), only the first subordinate change is accepted; the other subordinate changes are logged and then discarded at the master as they were not the first to update the master’s database.
- Hence, collisions are always resolved by the master node, which is the final adjudicator. The databases of all subordinate nodes may diverge, but will then converge to the contents of the master database.
- There are as many subordinate nodes as are needed for the anticipated transaction volume. Additional subordinate nodes are provided to maintain full capacity in case of one or more node failures. If the master node fails, one of the subordinate nodes is promoted to be the new master.