This section allows you to manage the clustering service, which ensures high availability for load balancing through two collaborative nodes in active-passive mode.

How does the RELIANOID cluster works #

Overview #

The Stateful Cluster feature in RELIANOID ensures continuous service availability and fault tolerance by combining two nodes that operate together as a single logical unit.

The primary objective of this setup is to prevent service interruptions and maintain seamless connectivity from the client’s perspective, even in the event of a node failure.

A cluster consists of two nodes that work in active-passive mode, where one acts as the master node and the other as the backup node.

• The master node actively manages all client traffic, balancing connections to backend servers and maintaining real-time session information.
• The backup node stays in standby mode, continuously synchronizing its configuration, state, and session data from the master to be ready to take over at any time.

If the master node becomes unresponsive or unreachable, the backup node automatically takes control, ensuring uninterrupted service delivery.

Master and Backup Role Selection #

The determination of which node acts as master and which acts as backup is managed by Keepalived, using VRRP (Virtual Router Redundancy Protocol) and interface tracking mechanisms.

Each cluster node is assigned a priority value, which influences the master election process:

• The node with the highest priority is selected as the master.
• If both nodes have the same priority, the one with the lowest IP address becomes master by default.

Keepalived continuously monitors tracked interfaces (network interfaces configured for failover detection). If one of these tracked interfaces fails or becomes unavailable, the node’s effective priority decreases, allowing the other node to take over as master.

This ensures that traffic is always routed through the most stable and fully operational node.

Stateful Synchronization #

RELIANOID clusters operate in stateful mode, meaning that session data and connection tables are synchronized between the master and backup nodes in real-time.
This synchronization allows active client sessions to persist even after a failover occurs — clients do not experience interruptions or need to reconnect, maintaining a seamless user experience.

Configuration changes, IPDS settings, SSL certificates, and farm states are also replicated automatically, ensuring both nodes remain fully aligned at all times.

Maintenance Behavior #

When performing maintenance operations (such as software updates, configuration changes, or hardware interventions), the cluster can temporarily adjust the master-backup roles:

• If maintenance mode is enabled on the current master, the backup node automatically promotes itself to master, taking over active services.
• When maintenance is complete and the node is re-enabled, it rejoins the cluster as backup unless configured as the preferred master.

This mechanism ensures maintenance activities can be performed without disrupting active client connections or availability.

Preferred Master Node #

Administrators can configure a preferred master node within the cluster.

This setting ensures that, once both nodes are online and stable, the designated preferred node will automatically reclaim the master role, even if the other node temporarily took over during a failover.

Advantages #

• Predictable traffic routing: Consistent master selection simplifies monitoring, logging, and traffic analysis.
• Configuration consistency: Ensures that a known, stable node remains the default control point.

Disadvantages #

• Brief service switchovers: When the preferred node returns and reclaims the master role, a short failover event may occur, potentially resetting some sessions.
• Less flexibility in failover control: In certain cases, the cluster might revert to the preferred master even if both nodes are healthy, which could introduce unnecessary transitions.

For deployments prioritizing maximum uptime and minimal disruption, administrators may choose to disable the preferred master option.

For environments where role consistency and operational predictability are critical, enabling the preferred master node is recommended.

Requirements for Creating a Cluster #

Both nodes must run the same Relianoid version (i.e., same appliance model).
Each node should have a unique hostname.
Both nodes should have identical NIC names (network interfaces).
Configuration changes must be made only on the master node, never on the backup node.
Intermediate switching and routing devices may need configuration to prevent conflicts with cluster switching.
Setting a floating IP is recommended to avoid service downtime during a cluster switch.

When load balancing services switch from one node to another, the backup node manages current connections and service status to prevent client interruptions.

Cluster Service components #

This is the main page for configuring the Cluster. The clustering service includes several components:

Synchronization. Automatically synchronizes configurations from the master to the backup node using inotify and rsync through SSH. Every change applied in the filesystem in the master node that is related to the virtual services or common configuration for the virtual services will be automatically replicated to the backup node.
Heartbeat. Monitors the health of cluster nodes using the VRRP protocol over multicast, facilitated by keepalive.
Connection Tracking. Replicates connection states in real-time to allow seamless failover without disrupting client or backend connections, using the conntrackd service.
Command Replication. Sends and activates configurations from the master to the backup node through zclustermanager via SSH.

The node where the Cluster is configured becomes the master node. Warning: Any previous configuration on the backup node will be erased, resulting in the loss of any Farms (including certificates), Virtual Interfaces, IPDS rules, etc.

Data Replicated in a Cluster #

In a clustering environment, data replication ensures that the configuration and state of the services are consistent between the master and backup nodes. Below are the specific elements that are replicated across the nodes:

• LSLB (Local Server Load Balancer), GSLB (Global Server Load Balancer), DSLB (Data Server Load Balancer) Services. These services are critical for load balancing and are replicated to ensure that failover does not disrupt traffic distribution, including configuration, sessions and traffic states.
• Static Routing. Routes defined statically are replicated to maintain consistent network paths.
• RBAC (Role-Based Access Control) Settings. User roles, permissions, and related settings are replicated to ensure security policies are consistent across nodes.
• Users, Groups, and Permissions. User accounts, group memberships, and associated permissions are synchronized.
• SSL Certificates and Let’s Encrypt Configuration. SSL certificates, including those managed by Let’s Encrypt, are replicated to secure communications and services.
• Virtual, VLANs, Bonding, and Floating Interfaces. Network interfaces configurations such as virtual interfaces, VLANs, bonded interfaces, and floating IPs are replicated.
• VPN Services. VPN configurations and states are synchronized to maintain secure connections.
• IPDS (Intrusion Prevention and Detection System) Rules and Files. IPDS rules and associated files are replicated for consistent security monitoring.
• Farmguardians Configuration. Monitoring and health check configurations for farms (groups of servers) are replicated.
• Notification Settings. Settings for system notifications are synchronized to ensure alerts are consistent.

Non-Replicated Data in a Cluster #

• Physical NIC Interfaces. Physical network interface cards (NICs) configurations are not replicated because they are hardware-specific.
• Default Gateways. Default gateway settings are local to each node and are not replicated.
• Local and Remote Services Configuration. Services such as DNS, NTP (Network Time Protocol), SNMP (Simple Network Management Protocol) are configured locally and not replicated.
• API Keys. API keys used for accessing services are not replicated for security reasons.
• Activation Certificates. Activation certificates for software licensing are not replicated.
• Installed Packages. Software packages installed on the nodes are not synchronized, as they can vary between nodes.
• Backups. Generated backups are specific to each node and, therefore, are not replicated across nodes.

Configure Cluster Service #

Local IP. Select from available network interfaces for cluster management (no virtual interfaces allowed).
Remote IP. IP address of the future backup node.
Remote node Password. Root password for the remote (future backup) node.
Confirm remote node Password. Root password for the remote (future backup) node.

After entering the necessary parameters, click the Apply button.

Show Cluster Service #

If the cluster service is configured and active, it displays the following information about services, backends, and actions:

Interface. Network interface where cluster services are configured.
Failback. Option to return load balancing services to the master when it becomes available again.
Check Interval. Time interval for heartbeat checks between nodes.
Tracked interfaces. Active network interfaces being monitored in real-time.

Cluster Actions #

Show Nodes. Displays the status of nodes.
Edit. Modify configuration settings.
Destroy. Remove configuration settings and a node.

The Show Nodes action displays a table with:

Node. Indicates if the node is local or remote according to the node where you’ve been connected to the web GUI. Local will be the node that you’re currently connected and remote is the remote node.
Role. Shows if the node is master (currently serving load balancing services), backup, or maintenance if it is a temporarily disabled node.
IP. IP address of each node.
Hostname. Hostname of each node.
Status. Node status, indicated by:

• Red. Failure.
• Grey. Unreachable.
• Orange. Maintenance mode.
• Green. Operational.

Message. Debug messages from each node.
Actions. Options for each node include.

• Enable Maintenance. Temporarily disables a node for maintenance to avoid failover.
• Disable Maintenance. Enables the node again.

Cluster Settings #

Global setting options available:

Failback. Select which load balancer is preferred as the master.
Track Interfaces to monitor. Monitor specific interfaces (e.g., LAN or VLAN).
Check Interval. Time between health checks from the backup node to the master.

Click the Apply button to save the changes.

Cluster maintenance and updates #

To perform maintenance or update a Relianoid cluster with minimal downtime, please refer to the detailed guide Update RELIANOID Cluster with minimum downtime.