标签：#vrrp

You built the system the way everyone tells you to. Three API servers instead of one, so a crash doesn't take you down. A load balancer in front of them spreading traffic around. Your domain points at the load balancer, the load balancer health-checks the backends, and when one server dies the other two pick up the slack. Textbook. Then at 2 AM the load balancer itself dies. Not a backend. The balancer. Maybe the box lost power, maybe the kernel panicked, maybe HAProxy hit an out-of-memory kill. It doesn't matter which. Your three API servers are sitting there completely healthy, idle, ready to serve, and every single request is timing out. Because nothing can reach them anymore. You removed the single point of failure from your application tier and quietly moved it to the thing in front. Adding a second load balancer doesn't fix it The instinct is right: run two. The problem is what clients are actually dialling. Your DNS points api.example.com at 203.0.113.10 , and that address belongs to load balancer 1. Load balancer 2 sits there with 203.0.113.11 , perfectly healthy, and no traffic at all. Nobody is asking for it. So you update DNS to point at the second one. Now you wait. TTLs are cached by resolvers, by operating systems, by browsers, and some of them ignore your TTL entirely. You're looking at minutes of downtime at best, and a long tail of clients still hammering the dead address. That's not failover, that's a slow-motion recovery. What you actually need is for the address to move. Clients keep dialling 203.0.113.10 , and a different machine starts answering for it. No DNS change, nothing to wait for. That's what a virtual IP is, and VRRP is how two machines agree on who's currently answering. What is a virtual IP address? A virtual IP (VIP) is an address that no machine owns permanently. Clients connect to it, DNS points at it, firewall rules reference it. But it can move from one server to another without anything on the client side changing. The address