Tag Archives: fortibalancer

DNS Cache – FortiBalancer

Leave a reply

Chapter 9 DNS Cache

9.1 Overview

The DNS SLB mechanism used by FortiBalancer appliance supports DNS cache feature. Upon receiving any type “A” or “AAAA” DNS responses, which are mapping of host names to IP addresses, FortiBalancer will save them in SLB DNS cache. Then, when the FortiBalancer appliance receives any DNS requests for the cached “A” or “AAAA” records from clients, the appliance will directly send back the “A” or “AAAA” responses to the clients. If there is no records in cache that hit the requests, the FortiBalancer appliance will communicate with the remote DNS server(s) directly, and then save the server responses in cache for responding to the coming requests.

Pages: 1 2

High Availability – FortiBalancer

Leave a reply

Chapter 5 High Availability (HA)

5.1 Overview

As the network applications develop, customers have higher and higher requirements for the reliability of the network and network appliances. During network planning and design, to improve the reliability of the network, some critical network appliances must have redundancy protection mechanisms. The Clustering function mentioned in the “Clustering” chapter uses the VRRP technology to solve the single-point failure. This chapter will introduce the High Availability (HA) function that newly provided by FortiBalancer appliances. The HA function not only solves the single-point failure, but also provides more policies to ensure the network reliability.

The HA function allows two or more FortiBalancer appliances to continuously exchange the running status with each other, and keep their configurations synchronized. When an appliance becomes down, other available appliances will take over the application services on the faulty appliance, which ensures the high availability of application services.

Besides, the HA function provides the Stateful Session Failover (SSF) function. With the SSF function, when a service failover occurs, connections on the service will be switched to the new appliance. This avoids the interruption of connections and therefore improves user experience. The HA function can be deployed flexibly. Besides the Active/Active and Active/Standby deployment scenarios, the HA function can be deployed among multiple appliances to achieve mutual-backup.

Pages: 1 2 3 4 5 6 7 8

Clustering – FortiBalancer

Leave a reply

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

  1. 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.
  2. The device collected the health information of the heartbeat cable. If the heartbeat cable is well connected, it will switch to Backup state.
  3. 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.
  4. If the backup receives a higher priority VRRP packet, it will switch to Discreet Backup state.
  5. In the following events, the discreet backup will switch to Backup state:
  6. 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.).
  7. 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.
  8. In the following events, the backup will switch to Master state:
  9. The backup receives a lower priority VRRP packet (in Preemption mode).
  10. 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.
  11. If the master receives a higher priority VRRP packet, it will switch to Backup state.
  12. 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

Pages: 1 2