What is HA 2.0
Edge HA 2.0 is the new high-availability architecture for the Celona Edge, generally available in release 2026.1. It replaces the Kubernetes-quorum-based HA 1.0 model with an N-way active-active design: every Access Point registers with every Edge node in the cluster, and device (UE) sessions are load-balanced across all of them. No node is a standby or a spare.
The headline changes for anyone designing or supporting a site:
Two nodes minimum: two Edge nodes are enough for full high availability — the three-node minimum is gone.
No quorum: any node count works, odd or even, with no quorum or tie-breaker node — a cluster keeps serving devices down to a single surviving node.
Scale out by adding nodes: adding an Edge node adds capacity and another layer of redundancy without redesigning the topology.
Fast failover: UE traffic recovers in under 15 seconds after an Edge node failure.
Hitless upgrades: the same drain-and-move mechanism enables rolling software upgrades with no maintenance window on multi-node clusters.
Background: from HA 1.0 to HA 2.0
HA 1.0 (since 2019) implemented high availability inside Kubernetes. Celona's all-master design made every node both a Kubernetes leader and a worker serving user traffic, avoiding the dedicated leader nodes a standard Kubernetes HA deployment requires. Even so, the Kubernetes control plane needs a quorum of 2 of 3 nodes, which imposed a hard three-node minimum cluster size — a floor that does not fit many established enterprise network designs.
HA 2.0 lifts high availability out of Kubernetes entirely. Kubernetes remains what it was adopted for — containerized service delivery, independent service lifecycles, and operational manageability — but service availability no longer depends on a Kubernetes quorum. Two Edges are enough, odd or even counts are fine, and the topology fits standard enterprise network designs.
Figure 1 — HA 1.0 (Kubernetes quorum, 3-node minimum) vs. HA 2.0 (N-way active-active, 2-node minimum).
| HA 1.0 (2019 – 2411) | HA 2.0 (2026.1) |
HA mechanism | Kubernetes cluster quorum | Application-level, outside Kubernetes |
Minimum nodes for HA | 3 | 2 |
Node count | Fixed at 3 | Any count, odd or even (N-way) |
Quorum required | Yes (2 of 3) | No — serves down to 1 surviving node |
Traffic model | All nodes serve traffic | Active-active; UEs load-balanced across all nodes |
Scale out | Not supported | Add nodes for capacity + redundancy |
Architecture: N-way active-active
Every Access Point holds a live connection to every Edge node in the cluster, and UE sessions are spread across all nodes. With 2 Edges and 2 APs there are 4 active AP↔Edge links; with 3 Edges, 6; with 5 Edges, 10. When a new node is added, every AP establishes a connection to the new node in the cluster automatically.
Figure 2 — N-way active-active: every AP holds a live link to every Edge; node count is even or odd with no penalty.
Both/all nodes carry live traffic from day one — no node sits idle as a designated spare.
An odd node count carries no penalty; no tie-breaker node is ever required.
Adding a node never requires redesigning the site topology and has no impact on the existing APs and devices.
Supported scale
Capacity follows an N+1 model: a 2-node cluster provides the same capacity as a single node — the second node buys availability, not scale. Each node beyond the second adds one node's worth of capacity, on the assumption the cluster tolerates a single node failure.
UE capacity is derived from AP count × 128 UEs per AP at 100% utilization; the 60% figure is the recommended planning number.
Edge Express
Cluster size | APs | UEs @ 100% AP util. | UEs @ 60% AP util. |
Single node | 40 | 5,120 | 3,072 |
2-node (HA) | 40 | 5,120 | 3,072 |
3-node | 80 | 10,240 | 6,144 |
Edge Enterprise v2
Cluster size | APs | UEs @ 100% AP util. | UEs @ 60% AP util. |
Single node | 100 | 12,800 | 7,680 |
2-node (HA) | 100 | 12,800 | 7,680 |
3-node | 200 | 25,600 | 15,360 |
4-node | 300 | 38,400 | 23,040 |
Note: Mixing Edge Express and Edge Enterprise hardware in one cluster is not supported.
Failover behavior
Failover is driven by the Access Points: when an Edge node becomes unreachable, the APs release the UE sessions that were terminating on it, and those UEs immediately reattach through the same APs to a surviving Edge. When the node returns, its AP links come back up and it resumes serving newly connecting devices.
Scenario 1 — Edge node down
A node goes down entirely: power cycle, reboot, hardware fault, or crash — the cause does not matter. All AP links to that node fail at once; affected UEs are released and reconnect to the surviving Edge(s), which then carry the full site load.
Figure 3 — Edge node down: APs release affected UEs, which reattach to a surviving Edge.
Scenario 2 — Edge up but isolated from the APs
The node itself is healthy, but a network partition has cut the path between the APs and that Edge. An unreachable Edge is handled exactly like a dead one: affected UEs are released and reattach to the reachable Edge, while the isolated node stays up but serves nothing. Once the partition clears, its AP links return and it resumes serving new connections — with no action on the Edge node itself. Failover behavior and recovery are the same as for an Edge node failure.
Figure 4 — Edge isolated from the APs: an unreachable node is handled like a dead one.
Failover time
In both scenarios the failover target is the same: UE traffic resumes on a surviving Edge node in less than 15 seconds, measured from the failure to the device passing traffic again.
Hitless rolling upgrades
HA 2.0's failover mechanics double as the upgrade mechanism: an upgrade is the same drain-and-move, run on purpose. Nothing is upgraded while it still holds sessions, so devices and APs stay in service and no maintenance window is required on a multi-node cluster.
Figure 5 — Rolling upgrade sequences: drain first, upgrade empty, repeat — for APs and Edge nodes.
Access Points — one at a time: one AP is selected, its UEs are drained onto neighbouring APs, the empty AP is upgraded, and the cycle repeats AP by AP while every other AP keeps serving the site.
Edge nodes — drain first, then upgrade: the node stops admitting new UE sessions, a cooling-off period lets active UEs drain off naturally, the control plane releases any that remain, and only then — once the node is empty and all UEs have landed on the other Edge(s) — is the upgrade initiated. The cycle repeats node by node.
Note: Single-node sites still take a service outage during upgrade — there is no second node to drain onto.
Requirements and restrictions
Software version: HA 2.0 requires release 2026.1 or later on all Edge nodes in the cluster.
5G only (Phase 1): 2026.1 Phase 1 supports 5G networks only. Sites with 4G networks (AP11/AP12, or AP20 operating in 4G mode) cannot migrate to HA 2.0 and remain on single-node or 3-node HA 1.0. This includes Neutral Host and private 4G deployments. The restriction is enforced in the Orchestrator.
Supported Access Points: HA 2.0 is supported with the AP2x series of access points.
Network design: all Edge nodes in a cluster must sit in the same Layer-2 domain. Edge-to-AP connectivity over a WAN (remote branch ↔ datacenter) is supported with up to 250 ms latency.
Firewall: spectrum services (SAS) moved to the Celona cloud in 2026.1, so the Edge no longer needs direct SAS connectivity.
IP planning: static/internal IP pools must be sized for the active-active allocation model — undersized pools block migration or fail device-profile mapping afterwards. See Edge IP address requirements — 2026.1 and the attached planning sheet for per-topology requirements.
HA 1.0 deprecation and transition paths
3-node HA 1.0 is deprecated in 2026.1. Existing 3-node HA 1.0 clusters can continue running on release 2411 during the transition. Supported transition paths, none of which introduce new firewall or customer network requirements:
Figure 6 — Supported transition paths from 2411 to HA 2.0 on 2026.1 — diagram needed
From | To | How |
Single-node (2411) | Single-node (2026.1) | Upgrade without restrictions once 2026.1 is GA |
Single-node (2026.1) | 2-node HA 2.0 | Add a second node; cluster forms and state syncs with configuration preserved |
3-node HA 1.0 (2411) | 3-node HA 2.0 (recommended) | Migrate 2411 → 2026.1 in a maintenance window; no node removal needed |
3-node HA 1.0 (2411) | 2-node HA 2.0 + cold spare | Same migration as above, then remove the 3rd node and retain it as a spare |
The 2411 → 2026.1 crossing itself is performed with the one-click MIGRATE TO V2 action on the Edge Cluster page — it is never offered from the Software Upgrade page. Preconditions, phases, monitoring, and troubleshooting are covered in Existing 2411 Customer: Software Upgrade / Migration to 2026.1.