High Availability and Load Balancing

High Availability and Load Balancing

This document explains how to deploy Radiator Server with high availability (HA) and load balancing.

To create high availability and load balancing, run multiple Radiator instances.

1. Incoming Requests

• AAA client capabilities usually limit LB and HA options. Clients often use IP or DNS lists of Radiator servers. Some protocols, such as RadSec and EAP, keep long-lived connections for encryption.

2. Radiator instances

• Authentication deployments are usually active-active, with all instances serving traffic. See Radiator Sizing for performance information.

3. Backends

• Radiator backends can use discovery, retries, load balancing, and failover. These options are covered in Backend Load Balancing.
• Radiator also supports Local Backends for simplified deployments.
• Backend speed is often the limiting factor.

4. Other common requirements

• Geographical redundancy
• Standalone operations
• Encryption and data security

Overview

Design HA and LB together. Start from the peak throughput that the whole system must handle.

1. Maximum TPS needed.

• Base this value on the number of users and how quickly they must authenticate after a full system restart.
• Convert the restart target into requests per second. For example, divide the number of users by the allowed authentication window in seconds.
• Account for expensive operations, such as password hashing and TLS handshakes, when sizing CPU capacity.
• Use current benchmarks from your target hardware and configuration before choosing the number of Radiator instances.

2. Backend capabilities

• Deployments usually request information from external systems. These systems are network-connected and have their own latency.
• Use multiple backends when you need backend load balancing.
• Understand the total TPS capacity of your backends. You may need to throttle incoming requests in Radiator to keep backends stable.

This document uses the Radiator cluster and instance naming convention. HA Identifiers explains cluster IDs such as C01 and instance IDs such as R01.

Architecture Patterns

This section describes how HA and LB setups can handle incoming requests. Client capabilities often limit the available options. Some clients do not support round-robin configuration for multiple Radiator servers. Others do not support DNS service lookups.

Multiple Radiator instances

The most common setup runs multiple Radiator instances. This is an active-active setup, where all instances serve traffic. Active-passive is usually more relevant for databases that must maintain a single state.

Each client can connect to any of the Radiator instances. The dotted lines indicate that clients typically have all servers configured and will fail over between them if one becomes unavailable. This could be done on DNS level, but usually it is best to configure the clients to just round robin Radiator servers.

For load balancing just two nodes adds limited value as in the case of one node going down the other one needs to handle all traffic.

By adding more nodes we start seeing benefits of load balancing.

Not all clients support many Radiator servers. This can make configuration harder because each client may need a different server list.

DNS Round-Robin

Using DNS round-robin selection for Radiator services is an efficient way to balance load and provide high availability. This requires reliable DNS. DNS is usually built with redundancy.

If one Radiator instance fails, 2 of 3 instances remain available. Clients retry the next IP address after a failure.

Load Balancers

Instead of DNS load balancing, you can use a hardware or software load balancer. Radiator itself is powerful, so a load balancer is often unnecessary for performance alone. Load balancers usually solve these problems:

• Cloud providers load balancers for incoming traffic
• Hardware load balancers for security requirements
• Proxying of requests to simplify client configurations
• Transmission encryption handling

This solution lets you distribute CPU-intensive encryption work based on performance and protocol needs.

Radiator itself can act as an IP access list, load balancer, proxy, and rate limiter. Some authentication protocols require client sessions. In those cases, using one or two middle Radiator instances can be the right solution.

Session State Management

Some AAA protocols require session state to be kept over multiple requests. Examples of these are TACACS+ and EAP-TLS multi round requests-response groups. In these cases a load balancer in front of the actual Radiators is needed.

Some cases will require external databases for keeping session states. This is needed for change of authority (CoA) requests to be possible from external systems. Like a client needing a different profile for speed.

See Backends for more information how to configure them.

Monitoring Integration

Radiator provides comprehensive monitoring capabilities through Prometheus metrics and the Management API. These enable centralized logging aggregation and alerting on node failures across your HA deployment.

Backend Failover

Radiator automatically detects and fails over from unhealthy backend servers using two complementary mechanisms:

• Unreachable-server detection — when a backend server has connections { min ...; } greater than zero, Radiator skips it immediately if its pool has no established connections, avoiding a full connect timeout on the first request after a failure.
• Service Level Objective circuit breaking — each server supports a service-level-objective block that marks the server degraded when its failure rate exceeds the configured threshold and re-routes traffic with exponential backoff.

See Backend Load Balancing for details.

PROXY Protocol Integration

Using PROXY protocol to preserve client IPs through load balancers - see PROXY Protocol Support for detailed configuration.