A third-party application delivery controller (ADC) is used to manage the virtual IP (VIP) independently of the Vocera Engage cluster.
An application delivery controller (ADC) is a networking appliance used to improve the security and resiliency of applications delivered over the web. As companies move from hardware toward cloud services, the load balancing functionality initially associated with ADCs has been enhanced to integrate applications with the networks and protocols that are needed now. Implementing an ADC helps customers reduce security risk, and increase performance and availability of applications. Vocera customers may implement an ADC to control how data moves, enable a reverse proxy, and provide intrusion detection.
Application delivery controllers (ADC) are also known as “load balancers”, as they direct connections to the active node of a cluster. However, the active-standby scheme employed by Vocera Engage requires the entire workload be directed to the active node, so there is no actual “load sharing” between the nodes in the cluster in the Layer 3 ADC Deployment Model in Vocera Engage.
In this model, the use of an ADC is a critical element in the operation of the Vocera cluster, so the ADC servers must be deployed in a cluster configuration of their own, independent of the Vocera Engage cluster. The ADC cluster itself will then require a common subnet across the datacenters in order to transfer the "floating IP" from one ADC node to the other.
As shown in this diagram, the Vocera Engage cluster shares a layer 3 subnet with the ADC cluster, while the distributed datacenters share a layer 2 adjacent subnet.
There are network elements which will connect to the ADC instead of directly connecting with Vocera Engage. For example, external systems such as ResponderSync, TAP, and HL7 will all need to communicate with Vocera Engage, but they will connect directly to the ADC. From a network perspective, when the Vocera Engage connects to the external system (such as Rauland ResponderSync), the system sees the IP address of the ADC, not the IP address of the external system (Rauland).
In most cases, the external system communication is relayed through the ADC, where the ADC controls the IP address, without any problems. For some systems, however, the external system's IP address is required for Vocera Engage functionality. With both CUCM and SpectraLink XML external systems, for example, the Vocera Engage needs the external IP address to correlate the registration status of a device with the external system. Normally, the Vocera Engage cannot access the external IP address, as the ADC address is proxied instead. In these cases, there is a special requirement that the Vocera Engage will need knowledge of the remote IP address for those devices that the Vocera Engage connects to.
The requirement is to configure the ADC to carry in its data payload the information for the remote address for the device. This configuration means that even though the direct connection is with the ADC and not the device, inside the data payload, encoded in the data, is the remote address (ADDR) of the device. The Vocera Engage finds the IP address, extract it, and link it to the CUCM exchange. Using this design, when the system needs to communicate with the device directly, in order to change the registration status or send something to the device, then by using the exact IP address that was encoded in the data payload, the correct device is accessed.
Deployment guidance information is provided in ADC Guidance in your Deployment in Vocera Engage. This information is generic and universal to the Vocera Engage product, and is provided as an example only. Contact Vocera Support Services for assistance if needed.
