High Availability & Redundancy Models

Every other architecture in this documentation starts from a single-path baseline and then adds resilience. This page is the shared vocabulary: single, redundant (active-active) and clustered (active-standby), and how each maps to the Standard, High and Maximum resiliency tiers.

Why this page exists

The reference architectures deliberately show a simple, single-path baseline first, then state how to make it resilient. That keeps each pattern honest about its failure modes. This page defines the redundancy models they all refer to, so the other pages can point here instead of repeating themselves.

The three models

Single path (baseline). One connection, one edge. It is the clearest way to explain a pattern and is acceptable for non-critical or short-lived workloads, but it has no fault tolerance – any single failure interrupts the service. Every production design should move beyond it.

Redundant, active-active. Two independent connections and edges, each fully addressed, both carrying traffic. There is no shared component to fail. Resilience comes from routing: equal-cost paths spread load, and if one fails, traffic continues on the other. This is the workhorse for production.

Clustered, active-standby. Two edges presented as one logical unit with a shared identity; one is active, one is on standby and takes over automatically on failure. Configuration and state are kept in step so failover is fast and largely invisible to the workload. It suits stateful roles – a firewall or a stateful gateway – where the standby must know what the active was doing.

Model	Failure behaviour	Best for
Single path	Interrupted on any failure	Non-critical, interim, test
Redundant (active-active)	Both live; routing continues on the survivor	Most production connectivity
Clustered (active-standby)	Automatic promotion of standby	Stateful edge functions (firewall, gateway)

How it maps to resiliency tiers

Tata Communications describes connection resilience as Standard, High and Maximum. Standard gives dual diverse paths within a metro – the redundant model, close together. Maximum diverges paths across regions or metros, so a whole-metro failure is survivable – the model behind multi-region and geo-redundant designs. High sits between. Fast failure detection uses BFD (standard 300 ms × 3), and BGP path selection (local preference 400/300/200/100, AS-PATH prepend 4755 2 / 4755 3 / 4755 4) makes failover deterministic.

A cloud will often treat two connections as active/active on its side. Tata Communications still weights them active/backup with BGP so the path choice is predictable and failback is clean – the cloud’s view and the network’s view are reconciled deliberately, not left to chance.

Example

A hospital group runs a clinical records interface between its on-premises systems and a cloud analytics environment. The interface is stateful, so the managed edge is deployed as an active-standby cluster; the connections underneath use the High resiliency tier with diverse paths. A path failure triggers sub-second BFD detection and BGP reconvergence, while the standby edge preserves session state – the interface keeps running through the event.

IZO™+ Multi Cloud Connect components in this architecture

This is the canonical dual build – the reference for how every other pattern becomes resilient:

IZO™+ Multi Cloud Connect Direct (private MPLS underlay):

Fabric Port ×2 and Virtual Cloud Connection ×2 – Primary + Secondary, Active/Active or Active/Passive.

IZO™+ Multi Cloud Connect Flex (internet underlay with an in-path VNF):

Fabric Port ×2, Edge Connect ×2 and VNF ×2 – the redundant or clustered pair.
Device Interconnection – joins the two VNFs (state sync for a cluster, or an HA link).
Virtual Cloud Connection ×2.

From the IZO™+ Multi Cloud Connect side, the dual build uses two Fabric Ports + two Virtual Cloud Connections (plus two VNFs + two Edge Connects + a Device Interconnection on Flex); the Tata Communications-billed parts run to the Virtual Cloud Connections, while each cloud port/attachment and egress sit on your cloud bill.

Considerations

Redundant vs clustered - Redundant (active-active) uses two independent nodes with routing-based resilience (ECMP); clustered (active-standby) presents two nodes as one logical unit with a Device Interconnection carrying state sync – use clustered for stateful functions.
Tier mapping - Standard is in-metro dual; Maximum diverges paths across regions/metros; High sits between.
Detection & steering - BFD (300 ms × 3) plus BGP local preference (400/300/200/100) and AS-PATH prepend (4755 2/3/4) make failover deterministic.
Cloud-side diversity - Some clouds require paired connections for their own resiliency commitments – map that to diverse Virtual Cloud Connections.
Cos - Dual roughly doubles the connectivity components (and, on Flex, the VNFs and Edge Connects), plus one Device Interconnection.

What’s on the cloud side

Redundant connections are matched on the cloud side in the provider’s console – some clouds require paired connections for their own resiliency commitments. This page covers how redundancy is delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.