Chapter 4 Clustering
4.1 Overview
The clustering function allows you to maintain high availability within a local site. With other options you can also distribute load across multiple boxes within a cluster.
4.2 Understanding Clustering
The Clustering function allows two or more FortiBalancer appliances to be grouped together to form a logical device, which provides scalability and high availability within a local site. Please refer to the following figure.
Figure 4-1 FortiBalancer Clustering
Clustering can be configured in Active-Standby (A/S) or Active-Active (A/A) mode:
Active-Standby mode – In Active-Standby mode, all VIPs on one FortiBalancer appliance in the cluster will be the master, and all VIPs on the other FortiBalancer appliances in the cluster are standby. In this mode, clustering supports fast failover.
Active-Active mode – In Active-Active mode, each FortiBalancer appliance in the cluster has a different master VIP or cluster ID.
4.2.1 Fast Failover
The Fast Failover (FFO) mechanism uses a new additional serial port (fast failover port on the FortiBalancer appliance mother board) to detect each other’s status transparently in a cluster (refer to the following figure). When one system powers off, panics, reboots or its interface losses carrier (link disconnection), all the traffic will be immediately switched to the other. The Clustering function with fast failover mechanism provides higher availability and much faster response time than the typical Clustering.
Figure 4-2 Clustering FFO Mode
4.2.2 Discreet Backup Mode
For traditional clustering, a backup and a master communicate each other’s state information through the network. If the backup does not receive the VRRP (Virtual Router Redundancy Protocol) multicast packets from the master within a specified time, it will mandatorily preempt the master. However, because of the network complexity, when something totally unexpected happens, this way may lead to a double-master state.
Discreet Backup mode is designed to prevent a double-master state. In this mode, the system determines whether a state transition is needed for the devices based on their state information detected by a heartbeat cable. This mode makes the state transition more reliable, and any VRRP packet loss will not result in double-master state.
The following shows how the Discreet Backup mode works.
Figure 4-3 Discreet Backup Mode Working Mechanism
- After turning on clustering, the device enters into Init state. Then, in order to check the health of the heartbeat cable, the Init device switches to FFO state.
- The device collected the health information of the heartbeat cable. If the heartbeat cable is well connected, it will switch to Backup state.
- Note: Even though the heartbeat cable is disconnected, the device will still switch to Backup state, and clustering will work well. However, the discreet mode is invalid.
- If the backup receives a higher priority VRRP packet, it will switch to Discreet Backup state.
- In the following events, the discreet backup will switch to Backup state:
- The device in Discreet Backup state receives a lower priority VRRP packet (after the successful state transition, the backup will go on to switch to Master state.).
- The device in Discreet Backup state will check the heartbeat cable health. If the heartbeat cable is disconnected, it will log out to Backup state.
- In the following events, the backup will switch to Master state:
- The backup receives a lower priority VRRP packet (in Preemption mode).
- In three continuous broadcast intervals (the default interval is 5 seconds, three intervals are 15 seconds), the backup does not receive the VRRP packet from the master.
- If the master receives a higher priority VRRP packet, it will switch to Backup state.
- If the heartbeat cable detected the master’s NIC is down, the discreet backup will switch to Master state directly.
Note: All cluster state transitions can be traced by the command “show cluster virtual transition”.
By default, discreet backup mode is turned off.
To configure the discreet backup mode, the following two commands MUST be configured first to turn on the discreet backup mode.
FortiBalancer(config)#cluster virtual ffo on
FortiBalancer(config)#cluster virtual discreet on
4.2.3 IPv6 Support for Clustering
The FortiBalancer Clustering function now supports IPv6 VIPs switchover. Both IPv4 and IPv6-based VRRP packets can be processed by the FortiBalancer appliance.
If the interface for Clustering is configured with both the IPv4 and IPv6 addresses or with only the
IPv4 address, then the IPv4-based VRRP packets will be used for communication between the FortiBalancer appliances. If only the IPv6 address is configured on the interface for Clustering, then the IPv6-based VRRP packets will be used.
Note: The VRRP packets are incompatible with each other among different OS versions. So please use the same OS version for the FortiBalancer appliances in a cluster.
4.3 Clustering Configuration
4.3.1 Clustering SLB VIPs
When using the clustering capabilities of the FortiBalancer appliance, we will first define our SLB virtual IPs that we want to use in the cluster. Each of the following sections will define the virtual IPs that we will use.
For information about SLB, please refer to the chapter Server Load Balancing (SLB).
4.3.1.1 Active-Standby: Two Nodes
Configuration Guidelines
In Active-Standby mode, one node in the cluster will be the master of the VIP, and thus active. The other node in the cluster will be in standby mode. Upon failure of the active node, the standby node will take over the VIP and become master. If preemption has been enabled on the initial master node, it will reassume mastership when it returns to a working state. Otherwise, the VIP will stay with the new master node until the node fails.
Refer to the following figure for the typical layout of Active-Standby architecture, in which:
- FortiBalancer1 is the current master, and handles SLB traffic for VIP.
- FortiBalancer2 is the backup, and listens for advertisements from the master. It will resume master status if FortiBalancer1 stops sending advertisements (i.e. FortiBalancer1 fails).
Figure 4-4 Active-Standby Two-Node Architecture
Table 4-1 General Settings of Active-Standby Two-Node Clustering
| Operation | Command |
| Configure SLB | Refer to the SLB Configuration section. |
| Configure a virtual interface | cluster virtual ifname <interface_name> <cluster_id> |
| Configure virtual cluster authentication | cluster virtual auth <interface_name> <cluster_id> {0|1} [password] |
| Configure preemption | cluster virtual preempt <interface_name> <cluster_id> <mode> |
| Configure virtual IP | cluster virtual vip <interface_name> <cluster_id> <vip> |
| Configure priority | cluster virtual priority <interface_name> <cluster_id> <priority> [synconfig_peer_name] |
| Enable the virtual cluster | cluster virtual {on|off} [cluster_id|0] [interface_name] |
| Enable fast failover feature | cluster virtual ffo {on|off} cluster virtual ffo interface carrier loss timeout <interface_timeout> |
Configuration Example for Active-Standby SLB Clustering via CLI Now let’s start to configure FortiBalancer1 and FortiBalancer2:
Ø Step 1 Configure SLB for both FortiBalancer1 and FortiBalancer2
FortiBalancer1(config)#slb real http “server1” 192.168.1.50 80 1000 tcp 1 1
FortiBalancer1(config)#slb real http “server2” 192.168.1.51 80 1000 tcp 1 1
FortiBalancer1(config)#slb group method “group1” rr
FortiBalancer1(config)#slb group member “group1” “server1” 1
FortiBalancer1(config)#slb group member “group1” “server2” 1
FortiBalancer1(config)#slb virtual http “vip1” 192.168.2.100 80
FortiBalancer1(config)#slb policy default “vip1” “group1”
FortiBalancer2(config)#slb real http “server1” 192.168.1.50 80 1000 tcp 1 1 FortiBalancer2(config)#slb real http “server2” 192.168.1.51 80 1000 tcp 1 1
FortiBalancer2(config)#slb group method “group1” rr
FortiBalancer2(config)#slb group member “group1” “server1” 1
FortiBalancer2(config)#slb group member “group1” “server2” 1
FortiBalancer2(config)#slb virtual http “vip1” 192.168.2.100 80
FortiBalancer2(config)#slb policy default “vip1” “group1”
- Step 2 Configure a virtual interface name
FortiBalancer1(config)#cluster virtual ifname “port1” 100
FortiBalancer2(config)#cluster virtual ifname “port1” 100
- Step 3 Configure virtual cluster authentication
It is recommended that you run clustering with an authentication string to avoid unauthorized participation in your cluster.
FortiBalancer1(config)#cluster virtual auth port1 100 0
FortiBalancer2(config)#cluster virtual auth port1 100 0
- Step 4 Configure virtual cluster preemption
Now we configure FortiBalancer1 to preempt the VIP when the initial master returns online. For FortiBalancer2, it will not preempt the VIP from the master node, but will take over if the master ceases operations.
FortiBalancer1(config)#cluster virtual preempt port1 100 1
FortiBalancer2(config)#cluster virtual preempt port1 100 0
- Step 5 Define the VIP by the “cluster virtual vip” command
FortiBalancer1(config)#cluster virtual vip “port1” 100 192.168.2.100 FortiBalancer2(config)#cluster virtual vip “port1” 100 192.168.2.100
- Step 6 Define the priority
Cluster priority determines which node becomes the master. The node with highest priority becomes the master. Since we want FortiBalancer1 to always be master of the VIP, we will set its priority to 255. For FortiBalancer2, we will leave its priority at 100. In a two-node cluster, this is permissible. Though, when you include more nodes in your cluster, you will need to set a unique priority for each VIP to properly communicate and fail-over. To do this, use the following command:
FortiBalancer1(config)#cluster virtual priority port1 100 255 FortiBalancer2(config)#cluster virtual priority port1 100 100
Note: The state is the backup on FortiBalancer2. This is expected since it is of lower priority than the master.
- Step 7 Turn on the clustering
FortiBalancer1(config)#cluster virtual on
FortiBalancer2(config)#cluster virtual on
- Step 8 Turn on fast failover
FortiBalancer1(config)#cluster virtual ffo on
FortiBalancer1(config)#cluster virtual ffo interface carrier loss timeout 1000
FortiBalancer2(config)#cluster virtual ffo on
FortiBalancer2(config)#cluster virtual ffo interface carrier loss timeout 1000