Cloud Computing 11 min read

How UCloud Achieves Second‑Level Failover with Internal VIP High‑Availability Service

This article explains how UCloud's internal‑VIP based high‑availability solution provides second‑level failover for cloud and physical hosts, detailing the evolution from simulated broadcast to a GARP‑sniffing broadcast cluster and showcasing real‑world e‑commerce and database use cases.

UCloud Tech
UCloud Tech
UCloud Tech
How UCloud Achieves Second‑Level Failover with Internal VIP High‑Availability Service

High‑Availability Service Based on Internal VIP

In fast‑paced environments, any service interruption is intolerable. UCloud offers an internal‑VIP based HA service that provides second‑level failover, suitable for e‑commerce spikes like Double‑11.

1. HA Concept and Key Points

From a business perspective, eliminating all failures is impossible; the goal is to ensure automatic failover to backup nodes without user impact. The two essential elements are backup nodes and automatic fault‑transfer.

2. Traditional Network HA Solutions

In conventional networks, Keepalived + virtual IP (VRRP) is a classic HA solution. A master node shares a virtual IP with backup nodes; when the master fails, VRRP negotiates a new master and the virtual IP migrates automatically.

3. HA in Cloud Overlay Networks

Cloud environments use overlay networks, making traditional broadcast mechanisms inadequate. UCloud’s controller (based on the open‑source Ryu framework) programs OVS bridges to manage ACLs, VPC connectivity, and flow rules, while GRE encapsulation preserves transparency for upper‑layer traffic.

UCloud Internal‑VIP Service

The internal‑VIP product provides a drift‑able entry point for cloud and physical hosts. Fault detection triggers automatic VIP migration within seconds, without extra API calls or host configuration.

Broadcast Mechanism Evolution

Failover time depends on master election and broadcasting the new VIP location. UCloud evolved three broadcast solutions:

First Generation – Simulated Broadcast

Replicates a broadcast packet N times to each node via OVS flow outputs. This approach suffers from flow‑update overhead, flow‑length limits, and incompatibility with heterogeneous networks.

Second Generation – Broadcast Cluster

A DPDK‑based broadcast cluster pulls broadcast information from a database, replicates packets, and forwards them, eliminating the need to update every node and removing size constraints.

Third Generation – Broadcast Cluster + GARP Sniffing

Integrates GARP sniffing to notify the entire network of VIP migration, allowing three‑layer access to remain functional across public and private clouds.

Application Cases

1. E‑commerce Payment System HA

UCloud deployed Keepalived + internal‑VIP for an online payment service, enabling automatic VIP drift and ensuring seamless two‑ and three‑layer connectivity within seconds.

2. UDB Database HA

The UDB product uses a dual‑master architecture with semi‑synchronous replication. When the master DB fails, the internal‑VIP instantly shifts to the standby, providing transparent failover without user intervention.

Conclusion

High availability requires not only internal‑VIP to avoid single points of failure but also rigorous service segmentation and monitoring. Continuous optimization based on Murphy’s law helps operations engineers maintain stable systems.

internal VIPUCloudbroadcast cluster
UCloud Tech
Written by

UCloud Tech

UCloud is a leading neutral cloud provider in China, developing its own IaaS, PaaS, AI service platform, and big data exchange platform, and delivering comprehensive industry solutions for public, private, hybrid, and dedicated clouds.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.