Category Archives: FortiBalancer

Secure Sockets Layer – FortiBalancer

Leave a reply

Chapter 11 Secure Sockets Layer (SSL)

11.1 Overview

Now that the basic SLB and Caching are setup on the FortiBalancer appliance, we can set up the SSL (Secure Sockets Layer) acceleration functionality to provide secure transactions with your clients. The SSL Accelerator works by decrypting the secure traffic and passing the unencrypted traffic to the original server. In an alternative mode the SSL accelerator can be used to decrypt the secure traffic, apply traffic management (SLB, caching, etc.) processing on decrypted traffic and then encrypt it back before passing it to SSL enabled origin server.

Pages: 1 2 3

HTTP Compression – FortiBalancer

Leave a reply

Chapter 10 HTTP Compression

10.1 Overview

The FortiBalancer appliance supports in-line compression of HTTP objects. By employing this licensed feature, administrators may maximize throughput to the desired site while end-users will experience quicker download speeds. This chapter describes the configuration of HTTP Compression capabilities which are part of the FortiBalancer platform. Configuration of HTTP Compression functionality can be divided into two main parts. The first part is the basic configuration and the second part is dedicated to advanced configuration.

Pages: 1 2 3

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

HTTP Content Rewrite – FortiBalancer

Leave a reply

Chapter 8 HTTP Content Rewrite

8.1 Overview

The HTTP Content Rewrite feature allows end users to visit the HTTP contents on the Web servers behind the FortiBalancer appliance. This feature aims to reduce network latency and improve user experience.

This chapter will cover the theories and configurations of the HTTP Content Rewrite feature.

Pages: 1 2 3

Reverse Proxy Cache – FortiBalancer

Leave a reply

Chapter 7 Reverse Proxy Cache

7.1 Overview

This chapter will cover the concepts and strategies of using the Reverse Proxy Cache to better enhance the overall speed and performance of your Web servers. Using the cache function will improve website performance and throughput, and will also reduce server load by caching heavily requested data in the temporary memory of the FortiBalancer appliance.

7.1 Understanding Reverse Proxy Cache

7.1.1 How Reverse Proxy Cache Works

The Reverse Proxy Cache is located right in front of Web servers. It receives the requests from clients all over the Internet and responds to these requests by working with the Web servers.

 

Figure 7-1 Reverse Proxy Cache Working Mechanism

  1. The client sends a request to the FortiBalancer appliance, requesting for a file on the Web server. The FortiBalancer appliance will forward the request to the cache module for processing.
  2. If the requested content has been cached on the FortiBalancer appliance and the cache does not expire (cache hit), the FortiBalancer appliance will send the file copy to the client directly without forwarding the request to the Web server. If the requested content does not exist in cache (cache miss), the request will be forwarded to the Web server for processing.
  3. The Web server responds to the FortiBalancer appliance with the requested content.
  4. The FortiBalancer appliance responds to the client with the requested content, and caches the content. Future requests for the same content will be responded directly from the FortiBalancer appliance cache module.

The default behavior of the cache is to send the cached object to the client while the cache is being filled with new objects.

The maximum size of the cache objects depends on different system memories of the FortiBalancer appliances. See the table below:

Table 7-1 Max Size of Cache Object

System Memory Max Size of Cache Object
4GB 10240KB (10MB)
8GB 20480KB (20MB)
16GB 40960KB (40MB)

 

7.1.2 Advantages of Reverse Proxy Cache

Compared with traditional cache functions, the Reverse Proxy Cache, without making any compromise on the overall stability and performance, provides a smarter, high-efficient and personalized configuration platform for administrators to more flexibly adjust the FortiBalancer appliances to addressing the demands of different websites. This helps administrators improves the response ability of the websites, reduces the load of Web servers and delivers perfect user experience of visiting the websites.

The Reverse Proxy Cache function is mainly featured with the following advantages: Ø Improved performance

  • The cache function is an independent module in the OS. Turning it off will not impact the functionality of other modules in the system.
  • The cache module strictly controls its memory consumption under 25% of the total system memory.
  • The ability to cache both the compressed and uncompressed contents allows the

FortiBalancer to send compressed contents to appropriate clients without having to involve the compression engine. This greatly enhances compression throughput.

Ø    Outstanding stability

  • If any error occurs to the cache module, administrators can turn off the module immediately, which will not affect the running of other system functions.
  • All cache tuning parameters now use the “cache filter” mechanism, and the global control parameters are reduced. This new approach gives administrators more flexibility and control and minimizes confusion during configuration.

Ø    Intelligent monitoring

Ÿ     The FortiBalancer process monitor also monitors the cache (in addition to the reverse proxy). If it detects any issues (or if the cache process crashes), it will restart the cache after appropriate cleanup.

Ø    Flexible configuration

  • Since the cache is a separate process, it can be updated in place using the “component update” mechanism.
  • The statistics from “show statistics cache” are more detailed and are designed to allow administrators to get data that would help them understand how the FortiBalancer is making caching decisions. This should help the customer tune the FortiBalancer or their website to optimize performance.
  • The “cache filter” mechanism reduces global control parameters, which increases the precision and flexibility of command control by administrators.
  • The cache can now be switched on/off on a per-virtual site basis.

7.1.3 Cacheability of Contents

The HTTP traffic falls into two categories: cacheable contents and non-cacheable contents. The cacheability of contents depends on the information within the HTTP headers. The reverse-proxy cache will check the request and response HTTP headers to make cache decisions. If the response for a request is cached, the subsequent request for the same object will be served from the cache instead of from a backend server.

By default, if there are no HTTP headers that restrict caching for an object, the reverse-proxy cache will cache the content. The following are the more popular cache-control headers that will control if the content will be cached and if so, for how long.

Cache-Control: public

The public keyword indicates that any available and configured cache may store the content. Cache-Control: private

This directive is intended for a single user and will not be cached by the reverse-proxy cache.

Cache-Control: no-cache

This directive lets the reverse-proxy cache know that it can cache the content and can only use the cached content if the appliance first re-validates the content with the origin server.

Expires: Tue, 30 Oct 2010 14:00:00 GMT

This header tells the cache when the content will expire and when to re-fetch it from an origin server when the request for that object is made. In this example it tells the cache to make the content expire on Tuesday, 30 Oct 2010 14:00:00 GMT.

7.1.3.1 Cacheable Contents

Any content with Cache-Control directives which allow caching of the content will always be cached. If the content does not contain a Cache-Control directive, then it will always be cached and will not be re-validated until it is manually flushed from the cache. If the content does not contain an “Expires” header, after it expires, the FortiBalancer appliance will re-validate the content with the origin server and update the content when it is requested next time.

7.1.3.2 Non-Cacheable Contents

Content that has Cache-Control headers which restrict caching of the content will not be cached. Responses to requests with cookies are not served from cache, unless configured by the user to do so.

7.1.4 Cache Filter

The Cache Filter mechanism helps administrators realize more precise control over the cache module with simple cache configurations, such as whether to cache the contents requested by a specific host or not and how long the cached content will live. The priority of the control parameters in cache filter is higher than the peer parameters defined in the Cache-Control header.

The following gives several application examples of cache filter. For detailed configuration examples, refer to the section Reverse Proxy Cache Configuration and the FortiBalancer CLI Reference.

  • Cache all “*.jpg” files from the host “www.xyz.com”, and the TTL of cache contents is 200,000 seconds.
  • Only cache the image files in common formats, such as JPG, GIF or BMP.
  • For the cache objects from the same host, some can be cached by following the cache filter rules, and others can be cached by following the definitions in the cache control header, such as the TTL of the cache.
  • Ignore the specific type of query strings in the request URL when looking up for an object in cache.

7.1.5 Cache Expiration Time

Three types of cache expiration time are involved during the cache process:

  • The expiration time defined by the “Expires” field in the HTTP header;
  • The global cache expiration time configured via the command “cache settings expire {hh:mm:ss|seconds}”;
  • The TTL time specified by the “ttl” parameter in the command “cache filter rule <host_name> <url> {cache|urlquery|ttl}”.

The priorities of the three expiration times are as follows:

  1. The expiration time configured in “cache filter rule” will be used first.
  2. If the “ttl” parameter is not specified, the global expiration time specified by “cache settings expire” command will apply.
  3. For the cache content that does not match any cache filter rule, the expiration time defined in the HTTP header will be applied.
  4. If no “Expires” field is available in the HTTP header to define the expiration time, just follow the configuration of “cache settings expire”.
Pages: 1 2

Server Load Balancing – FortiBalancer

Leave a reply

Chapter 6 Server Load Balancing (SLB)

6.1 Overview

SLB (Server Load Balancing) allows you to distribute load and traffic to specific groups of servers or to a specific server. The FortiBalancer appliance supports server load balancing in Layers 2-7 of the OSI network model. Layer 2 SLB is based on network interfaces. Layer 3 SLB works on IP addresses. Layer 4 SLB is mostly concerned with port based load balancing. Layer 7 is used when you want to perform load balancing based on URLs, HTTP headers or Cookies. The basic steps for setting up SLB are:

  1. Define the real servers.
  2. Define a group load balancing method.
  3. Add real servers to the group.
  4. Define a Virtual IP to listen for requests.
  5. Bind the group balancing method to the Virtual IP.

The real server, the VIP and the virtual service are the fundamental components of SLB deployment.

  • The real server is an application server hosting varied applications or services. It processes the requests from the client side.
  • The VIP in general is a public IP address that can be accessed from the external clients. As an entrance, it receives and forwards external requests, and sends the processed results from the real servers back to the client side.
  • For the Layer 4 and Layer 7 SLB, the virtual service is commonly represented with a VIP/port pair and can be accessed by the external clients to get their target network resources. For example, if a client wants to access some Web resources by a predefined VIP or a Web site name (with DNS), all the requests from this client will go through the VIP and be sent out to different real servers by the FortiBalancer appliance hosting the VIP and real servers. With the virtual service, the internal network architecture and backend real servers are hidden from the external clients by only exposing the VIP address.

The remainder of this chapter will cover these steps and cover some examples of Layer 2, Layer 3, Layer 4 and Layer 7 load balancing strategies.

This following figure is a logical overview of load balancing using the FortiBalancer appliance.

 

Figure 6-1 SLB Architecture

Pages: 1 2 3 4 5 6 7 8

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