CDN: Load Balancer + Multiple Origins

The scenario

The User (10.0.0.10) connects to Edge-LB's virtual IP, 10.0.0.1, on TCP port 80. Behind it, Origin-1 (10.0.1.10), Origin-2 (10.0.1.11) and Origin-3 (10.0.1.12) serve the same site on port 80. For each new connection Edge-LB rewrites the destination to one origin and the source to its own origin-side address, 10.0.1.1, and translates the reply back. In a live lab each new connection goes to the next origin in turn (round-robin); the simulator always shows Origin-1. Edge-LB does not check whether an origin is working. It forwards to the address it was given, whether or not anything answers there.

What you will work out

Learn how an edge load balancer spreads connections across origin servers, what it does and does not know about them, and why production balancers need health checks.

Why this matters

'Some requests fail and some work' is the signature of a balancer sending traffic to a broken backend, and it is much harder to spot than a total outage. Health checks are what turn several servers into real redundancy: without them, one failed origin means a share of users get errors. When you configure a load balancer in any cloud, the health check path, interval and thresholds matter as much as the list of backends.

Running it

CDN: Load Balancer + Multiple Origins opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.