High Availability – Ensuring Reliability of Virtual SBCs in the Cloud

In my continuing series about the key attributes required for successful deployment of virtual, cloud-based SBCs, I want to spend some time talking about high availability and the importance of ensuring reliability in a virtual, cloud deployment.

Real-time applications have a set of high availability requirements for service, subscriber, and call / session resiliency. The one that most often is highlighted is for real-time media, where interruptions of anything much greater than 500ms are perceived as glitches. To address this requirement, Sonus’ traditional, hardware-based SBCs were paired 1-1, with a redundancy framework on both the active and standby systems continuously monitor the active for any possible fault conditions, such as process crashes, link failure, OS crash, hardware or power faults, and alive but unresponsive elements.

Discovery of one of these fault conditions would trigger a switchover to the standby system. Upon switchover, the “newly-activated” standby recovers the service, the registrations and the stable calls. The media path for all active sessions is reconstructed, and the signaling path is restored. This would be transparent to all peers and no action would be required to achieve this seamless transition.

Now move those real-time applications into a virtual, cloud-based environment. They still have the same high availability requirements for service, subscriber, and call / session resiliency as they do in traditional, hardware-based network environments. So what is the best way to replicate the level of fault tolerance available in hardware?

We can start by looking at IP address solution that is most commonly used for high availability with web-based applications, called “Floating IP Address”.

A floating IP address is a normal IP address assigned to a virtual server, but used to support failover scenarios. The active member of two or more virtual servers "owns", or responds, to that IP address at any given time. Should the active member fail, then "ownership" of the floating IP address would be transferred to a standby member in order to promote it as the new active member. With the use of a gratuitous ARP, the new MAC address–to–IP address association is announced.

The scenario above, using floating IP, could take many seconds to fully effect the changeover. While this may be reasonable and acceptable for most web-based applications, it is not acceptable for an SBC switchover. When dealing with real-time communications this method violates the 500ms limit on switchover needed to ensure uninterrupted media.

Instead, in a virtual, cloud-based environment, Sonus will use the “Allowed Address Pair” method to replicate the very effective techniques used in the hardware-based SBC for active to standby switchover to ensure high availability for real-time applications in the cloud environment.

Allowed Address Pairs is an OpenStack-defined capability, beginning with the Havana release, whereby, one virtual server is active and is the only one that will respond on that given address. All other associated virtual servers are assigned the same IP address, but are standby and just monitor the active one periodically to ensure that it’s still running. If the active server goes down, an associated standby server takes over and starts replying on the specified IP address.  The advantage of this solution is it enables fast data plane failover and meets the 500ms requirement for uninterrupted media.

There is one more important aspect of ensuring reliability in a virtual, cloud deployment that I want to discuss - automated orchestration. As described in the example above, in the event of a failure of the active server, a standby server takes over processing. But to get back to “full” reliability, we want to restore the failed virtual server as soon as possible. Upon recover, the previously active server now gets configured as the standby server and full reliability is in place.

However, if restoration is not viable, then a new virtual server needs to be instantiated to replace the failed one. While this can be done manually following an alert of the failure and switchover, it would be much more efficient if this was automated. As part of the Sonus solution, we have integrated automated monitoring with our VNF Manager to automatically instantiate another virtual server to take the place of the failed one and to apply the right configuration to the new virtual server including its assignment as a standby virtual server in the Allowed Address Pair.

For Sonus, it continues to be our priority to ensure our virtual, cloud-based SBC delivers the same level of reliability and resiliency that our service provider customers have come to expect from their more traditional hardware-based solutions. With that goal in mind, we believe the innovations discussed above are key aspects for our customer’s success in deploying virtual, cloud-based SBCs.