At 11:40 on the Friday after Thanksgiving, one of an online retailer's four web servers runs out of memory and stops answering. Customers don't notice. The load balancer's next health check fails, it pulls the server out of rotation, and the other three carry the traffic. Twenty minutes later utility power drops for six seconds, and again nobody notices, because the UPS holds the racks until the line comes back. Failures still happened. They just didn't become outages.
That is the job of redundancy. On the CompTIA Security+ SY0-801 exam it sits under objective 3.4, which expects you to explain why resilience matters in security architecture. This lesson covers high availability and single points of failure, load balancing in active/active and active/passive designs, clustering, autoscaling, multicloud and storage redundancy, and the four power protections the objective names: UPS, redundant power supplies, generators and surge protectors.
High availability starts with removing single points of failure
High availability means designing a system to keep running when individual components fail. It is usually stated as a percentage of uptime, such as 99.99 percent, and those numbers are covered in the recovery metrics lesson. The method behind the number is simple to describe: find every single point of failure, meaning any one component whose loss stops the service, and give it a spare or an alternative path.
The practical way to find them is to trace a request end to end. A customer's order travels over an internet link, through a firewall, a load balancer and a switch, to a web server, which calls a database, which writes to storage. All of that depends on power and cooling. If any link in that chain exists only once, it's a single point of failure, and the availability of the whole service can be no better than that one part.
Two sizing terms come up often. N+1 means running one more unit than the load requires: if three web servers handle peak traffic, you run four. 2N means a complete duplicate of everything, such as two full power paths. More redundancy costs more and adds complexity, so it goes where an outage hurts most.
Load balancers spread requests and route around failed servers
A load balancer sits in front of a pool of servers and hands each incoming connection to one of them. Common scheduling methods are round robin, which takes turns; weighted, which sends more to bigger servers; and least connections, which picks the server with the fewest active sessions. The resilience comes from health checks. The load balancer probes each server on a schedule and stops sending traffic to any that fail.
Here is what that looks like in an HAProxy configuration, with TLS ended at the load balancer and plain HTTP to the servers behind it:
backend web_pool
balance leastconn
option httpchk GET /health
server web1 10.0.1.11:8080 check inter 5s fall 3 rise 2
server web2 10.0.1.12:8080 check inter 5s fall 3 rise 2
server web3 10.0.1.13:8080 check inter 5s fall 3 rise 2 backup
Each server is checked every 5 seconds, marked down after 3 failed checks and returned after 2 good ones. The backup keyword means web3 gets traffic only if web1 and web2 are both down.
Two details trip people up. First, if user sessions live in one server's memory, losing that server logs those users out; storing sessions in a shared cache or database avoids it. Second, a single load balancer is itself a single point of failure, so they are normally deployed in pairs that share a virtual IP address, using a protocol such as VRRP or a vendor equivalent to move the address when one fails.