Table of Contents
Understanding High Availability
High availability in network design is about keeping services reachable even when parts of the system fail. The focus is not to prevent every failure, which is impossible, but to design the network so that failures have minimal impact on users. In this chapter the attention stays on what high availability means, what design patterns are used for it, and how it affects decisions at network level, without repeating generic redundancy topics from the parent chapter.
High availability is usually described using a percentage. For example, “five nines” means 99.999% availability in a given period, often a year. This translates to only a few minutes of downtime per year. Designing for high availability means understanding what level of uptime is realistic and necessary, and then building a network that can meet it.
High availability is about service continuity despite failures, not about eliminating all failures.
Availability and Downtime
Availability expresses how often a service is up and reachable. It is commonly written as a percentage, and it can be converted into allowed downtime over a period, usually a year. The basic relationship between availability and downtime is simple but important for design decisions such as how much redundancy to add and how much complexity is acceptable.
The key idea is that higher availability percentages allow less downtime. The useful formula relates availability to downtime:
Availability formula:
If $A$ is availability as a fraction (for example $0.999$), then
$$\text{Unavailability} = 1 - A$$
Over a period $T$ (for example, one year in minutes), the allowed downtime $D$ is
$$D = T \times (1 - A)$$
For practical design work you usually think in yearly terms. One year has $365 \times 24 \times 60 = 525{,}600$ minutes. If you want 99.9% availability, the unavailability is $1 - 0.999 = 0.001$, so you can calculate the maximum downtime:
$$D_{\text{year}} = 525{,}600 \times 0.001 = 525.6 \text{ minutes}$$
This is about 8.76 hours of downtime per year. A similar calculation can be done for other availability targets.
A useful table of typical availability targets and their allowed yearly downtime looks like this:
| Availability | Allowed downtime per year (approx) |
|---|---|
| 99% | 3.65 days |
| 99.5% | 1.83 days |
| 99.9% | 8 hours 46 minutes |
| 99.99% | 52 minutes 34 seconds |
| 99.999% | 5 minutes 15 seconds |
These numbers matter when deciding if a certain design is “good enough.” For a small office, a few hours of downtime per year might be acceptable. For an online banking service, even a few minutes might be too much. High availability network design always starts with an agreed target like this, because it guides how much cost and complexity are justified.
Designing Out Single Points of Failure
A single point of failure is any component where a single fault can break the whole service. High availability designs focus on finding and removing, or at least minimizing, single points of failure. This mindset applies to every layer of the network, including devices, links, power, and even external providers.
To identify a single point of failure, imagine that one element is removed or fails. If users lose access, that element is critical. For example, if a branch office has just one router that connects it to the internet, and that router fails, the entire site goes offline. That router is a clear single point of failure.
You can think of three basic strategies to handle single points of failure in network design. The first is to add another component of the same type and connect it so that either can carry the traffic. The second is to add an alternative path that can be used if the primary path fails. The third is to design the system so that even if a component fails, it is easy and fast to repair or replace, reducing downtime.
The goal is not to remove every single point of failure, because that can be too expensive or complex. The goal is to remove or mitigate the ones that would cause unacceptable disruption given the availability target. For example, you might decide that redundant data center core switches are necessary, but redundant printers are not.
High availability design often uses visual diagrams that highlight where all user traffic passes. Any chokepoint in such a diagram is a candidate for improvement. This practice is more than a drawing exercise: it directly informs which components must be duplicated or protected.
Active/Active and Active/Standby Designs
High availability networks use specific patterns for how multiple devices share the load and take over during failures. Two of the most common patterns are active/active and active/standby. These patterns appear in different layers and technologies, but the core concepts stay the same.
In an active/active design, two or more devices are all working at the same time. Traffic is distributed among them in normal conditions. If one device fails, the remaining devices take over its share. This approach can provide both high availability and higher performance, because all devices contribute capacity during normal operation.
In an active/standby design, one device processes traffic and the other device stays ready but mostly idle. The standby device monitors the active one using some health signals. If the active device fails or becomes unreachable, the standby device takes over the traffic. Once the active device is restored, it may either become active again or remain secondary, depending on how the system is configured.
A simple comparison of these two models in terms of behavior looks like this:
| Aspect | Active/Active | Active/Standby |
|---|---|---|
| Normal use | All devices carry traffic | Only one device carries traffic |
| Capacity | Combined capacity of all active devices | Limited to capacity of single active device |
| Failover effect | Loss of capacity but service continues | Switchover from active to standby |
| Complexity | Often more complex to balance and monitor | Usually simpler but can waste resources |
For example, two core switches operating together and sharing VLANs and routing are often active/active. Two internet edge firewalls where only one forwards actual traffic and the other waits for a failover event are often active/standby.
From a high availability perspective, active/active can offer better resource usage and faster failure handling, but it requires careful design to avoid inconsistent states or loops. Active/standby is easier to reason about because only one device is making decisions at a time, but it does not use all available hardware capacity in normal operation.
Redundant Network Paths and Links
High availability is not only about redundant devices, it is also about redundant paths. A path is a sequence of links and devices that traffic follows between two endpoints. If there is only one path, any failure along that path can cut the connection. If there are multiple paths, routing or switching mechanisms can often redirect traffic when a failure happens.
A simple example is a distribution switch connected to each core switch using separate links. Under normal conditions, traffic may use both links. If one core or link fails, the switch still has a path through the other core. The whole idea is that there is always at least one working path between important network segments.
In enterprise and data center networks this often leads to multi tier architectures where each tier has multiple uplinks to the next tier. High availability design ensures that a single failure at any one tier does not isolate a part of the network. This can involve multiple physical links between the same pair of devices, multiple devices providing the same role, or both.
One important detail for high availability is the convergence time when a path fails. Convergence is the time it takes for the network to notice a failure and choose a new path. Even if redundant paths exist, slow convergence can cause noticeable outages. While the technical mechanisms that control convergence belong to routing and switching topics, from a design perspective you must recognize that both the existence of alternative paths and the speed of switching to them matter for real availability.
In high availability design, links should as far as practical avoid sharing the same physical route or infrastructure outside the devices themselves. Two “separate” fiber links that run through the same small conduit in a building, or two circuits from the same provider that share an upstream section, can fail together during a physical cut or provider problem. High availability networks consider not only logical redundancy, but also physical separation whenever it is feasible.
Geographic Redundancy and Site Level HA
High availability for large organizations often extends beyond a single building or campus. Geographic redundancy means placing critical services in multiple locations, often called sites or data centers, so that a failure at one location does not stop the service globally.
At the network level this can involve multiple data centers that both provide access to the same application, with traffic entering through more than one internet connection and more than one physical place. A regional failure, such as a power outage, natural disaster, or connectivity problem affecting one city, then does not disable the service entirely.
Networks that use geographic redundancy typically use some way to steer users toward one site or another, and to move traffic away from a failed site. The specific mechanisms are part of routing, load balancing, and name resolution topics, so they are not deeply covered here. The design principle is that no single site should be so critical that its loss breaks the entire system, except for services that are explicitly declared as non critical.
Geographic redundancy introduces new challenges. Data and configuration must be consistent across sites. Latency between sites can be higher, which affects internal protocols and replication. The cost is greater because several locations must be built and maintained. High availability designs weigh these trade offs and usually reserve full geographic redundancy for the most critical services.
A common compromise is to use one main site and one smaller, secondary site that can host a reduced but functional version of important services during disasters. High availability in this context means that core functions work from either site, even if capacity or performance is lower when only the backup site is active.
Measuring and Planning for High Availability
High availability is not just about having multiple devices and links, it is about quantifying risk and planning around real world failure behavior. Two helpful concepts in planning are mean time between failures and mean time to repair, usually shortened to MTBF and MTTR.
MTBF describes how long a component is expected to work on average before it fails. MTTR describes how long it usually takes to restore it to working order once it has failed. Even without exact numbers, the relationship between these quantities and availability can be expressed.
For a single component, the probability that it is working at any given moment can be approximated with:
Approximate availability from MTBF and MTTR:
$$A \approx \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$
If a device has an MTBF of 100,000 hours and an MTTR of 4 hours, then:
$$A \approx \frac{100{,}000}{100{,}000 + 4} \approx 0.99996$$
which is about 99.996% availability.
High availability design uses this kind of reasoning to decide where redundancy will have the greatest impact. Reducing MTTR, for example by having spare devices on site and clear procedures, can significantly improve availability even without changing the architecture.
Planning also involves understanding maintenance windows. Some downtime is planned for upgrades or replacements. To maintain a high availability target, the network must be designed so that as much maintenance as possible can be performed without interrupting service. This often drives decisions such as dual power supplies, modular chassis designs, and hitless upgrades, where one member of a pair is upgraded at a time while traffic stays on the other.
Finally, high availability planning always includes realistic assumptions about human factors. Misconfigurations and procedural mistakes are frequent causes of outages. A complex design that is hard to understand and maintain may actually reduce availability in practice, even if the architecture looks highly redundant on paper. Therefore, there is a constant trade off between extra redundancy and added complexity. True high availability design aims not just for technical redundancy, but also for operational simplicity and clarity.
Testing and Validating High Availability
A high availability design exists only as a plan until it is verified in real conditions. Validation is an essential part of ensuring that the network behaves as expected during failures. It is not enough to assume that if there are two devices or two links, the network is resilient. The actual behavior during faults must be tested.
This usually involves planned failover exercises. For example, an engineer might intentionally shut down a core switch link and observe how quickly traffic reroutes, and whether all critical services remain reachable. Similar tests can be done for power supply failures, device reloads, or loss of an external circuit. Testing reveals misconfigurations or hidden single points of failure before they cause real outages.
The outcome of good testing is not just pass or fail. It should also produce metrics about how long failover takes and how many users experienced disruption. If congestion happens during failover because backup links are smaller, or if certain applications time out during convergence, those observations feed back into the design.
High availability validation is not a one time activity. As the network evolves, new components and paths are added, and old ones are removed. Each significant change can affect the overall behavior in ways that are not obvious. Including failover testing as part of regular change management is a key part of maintaining the availability level that the design promises.
High availability is therefore not only an architecture topic but also a discipline. It combines careful design, deliberate redundancy, quantified targets, and continuous validation to create networks where failures are expected and handled gracefully instead of causing surprise and major downtime.