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

A cluster is formed by 2 nodes working together to maintain backends services always available and avoiding any downtime of the services from a client point of view. Usually, there is master and backup roles in an active-passive mode: the master is the node that is currently managing the services traffic to the backends and accepting the connections from the clients, the backup node knows all the configuration in real time in order to be ready to launch the services if they detect that the master node is not responding properly.

Some requirements to take into account when creating a cluster:

• Both nodes should be running the same Zevenet version (ie. same appliance model)
• Both nodes should have different hostnames
• Both nodes should have the same NICs names (Network interfaces)
• Master node must be the only node where to configure services, never should it be done in the backup node
• There may be the need to configure intermediate switching and routing devices in order to avoid any kind of conflict with the cluster switching
• To define floating IP is always a good practice when the cluster service is running in order to avoid the service to experience any downtime due to a cluster switch.

When the load balancing services switch from one node to another, the backup node will take care of all the current connections and services status by itself in order to avoid the client from suffering any interruption in the service.

Configure Cluster Service

This is the main page where to configure the Cluster. The clustering is composed of several services including:

Synchronization. This service synchronizes the configuration made in the master node to the backup node automatically, so every change made in the configuration is replicated to the backup node and letting him take control whenever it is required. This service uses inotify and rsync daemons through SSH in order to synchronize configuration files in real-time.
Heartbeat. This service permits to check the cluster nodes health status among all of them in order to detect quickly when a node is not correctly working. This service relies on the VRRP protocol over multicast designed to be lightweight and real-time communication. Zevenet 6 uses keepalive in order to provide this service.
Connection Tracking. This service permits to real-time replicate connections and their state in order to allow the backup node to resume all the connections during a failover so the clients and backends connections won’t detect any connection disruption, thanks to the conntrack service.
Command Replication. This service permits to send and activate the configuration applied in the master node to the backup, but in a passive way so that during a failover task the backup will take the control and will launch all the networking, farms and resume the connections as soon as possible. This service is managed by zclustermanager through SSH.

The node where the Cluster is configured becomes the master node.
Warning: Any previous configuration in the backup node will be erased. It means you will lose any Farms (including their certificates), Virtual Interfaces, IPDS rules, etc.

New cluster configuration requires the following parameters in order to be created:

Local IP. Drop down with all the available network interfaces to be selected as the cluster management interface, no virtual interfaces are allowed.
Remote IP. Remote IP address of the node that will behave as the future backup node.
Remote Root Password. Password of the root user of the remote (future backup) node.
Confirm Password. Ensure that it’s the correct password by repeating the password.

After setting all the needed parameters, click on the CREATE button and a confirmation that the cluster services are setup properly if there is communication between the nodes and no issues has been produced.

Show Cluster Service

If the cluster service is already configured and active, the cluster shows the following information about the services, backends and actions.

Interface. Network interface from where the cluster services have been configured.
Failback. Set if during a failover the load balancing services should be returned to the master when it’s available again or maintain the current node as the new master. This option is useful when the backup node has less resources allocated than the master and the last should be the preferred master for the services.
Check Interval. Time checks that the heartbeat service will use to check the status between the nodes.
Actions. Available actions to apply.

• Configure. Change some available cluster settings.
• Unset. Disable the cluster between the given nodes.
• Show Nodes. Show the table nodes and their status.
• Reload. Refresh the nodes table and their status.

The Show Nodes action shows a table with:

Node. For every node of the cluster show if it’s local or remote. It depends to which node you’ve connected through the web GUI, local will be the node that you’re currently connected and remote is the other node.
Role. For every node of the cluster show if it’s master, backup (also known as slave) or maintenance if it’s temporary disabled the node. It’ll depend on the role that the node has in the cluster.
IP. IP address of every node that compounds the cluster.
Hostname. Hostname of every node that compounds the cluster.
Status. The nodes status could be Red if there is any failure, Grey if the node is unreachable or not responding, Orange if it’s in maintenance mode or Green if it’s everything right.
Message. The message from the remote node, it’s a debug message of every node in the cluster.
Actions. The actions available for every node are the following.

• Maintenance. Put in maintenance mode, it disables temporary a cluster node in order to perform maintenance tasks and avoid a failover.
• Start. Put the cluster node back on the cluster after maintenance tasks.

In the top of the web panel it’s shown a summarized status of the cluster local node. For example, status green and role master:

Another example, a cluster node put in maintenance state:

Cluster configuration

The global setting options available are described below.

Failback. Select which of the load balancers is preferred as the master.
Check Interval. Time between each health check from the backend node, in order to check the master’s health.

Click on the SAVE button in order to apply the changes.

Check out our video about stateful cluster failover with Zevenet.