All rights reserved. Use of this product and this manual is subject to license. Information in this document is subject to change without notice.
Trademarks
Barracuda Load Balancer is a trademark of Barracuda Networks. All other brand and product names mentioned in this document are registered
trademarks or trademarks of their respective holders.
This chapter provides an overview of the Barracuda Load Balancer and includes the following topics:
• Overview on page 8
• Features of the Barracuda Load Balancer on page 9
Introduction 7
Overview
Note
The Barracuda Load Balancer is not designed for link balancing that distributes traffic across
multiple Internet connections.
Organizations use load balancers to distribute traffic across a set of servers in their network. In the
event a server goes down, the load balancer automat ically detects this failure an d beg in s forwarding
traffic to the remaining functioning servers, main taining high avail ability of the services pro vided by
the servers. The Barracuda Load Balancer is designed to help organizations achieve their high
availability objectives by providing:
•Comprehensive failover capabilities in case of server failure
•Distribution of traffic across multiple servers
•Integrated protection from network intrusions
The Barracuda Load Balancer enables you to set conditions that dictate how traffic should be
distributed to your Real Servers. For example, you can specify that a new connection should be
processed by the Real Server with the lowest CPU load.
The Barracuda Load Balancer also makes it easy to scale your network to handle increased traffic
because you can simply add a Real Server at any time, and the Barracuda system will automatically
detect the new server and add it to the load-balanced farm of servers.
Powerful Enterprise-Class Solution
The Barracuda Load Balancer uses a variety of factors to make load-balancing decisions. It is
designed to provide comprehensive IP load-balancing capabilities to any IP-based application,
including:
•Internet sites with high traffic requirements, including Web, FTP, media streaming, and content
delivery networks
•Hosted applications using thin-client architectures, such as Windows® Terminal Services
•Other IP services requiring optimal performance, including SMTP, DNS, RADIUS, and TFTP
The Barracuda Load Balancer's integrated Service Monitor ensures that servers and their associated
applications are operational. In the event of server or application failure, t he Barracuda Load Balancer
facilitates automatic failover among servers to ensure continuous availability. The Barracuda Load
Balancer also assists in orchestrating scheduled maintenance windows on specific servers while
maintaining application availability through other servers in the server farm.
To minimize the risk associated with failures of the load balancers themselves, two Barrac uda Loa d
Balancers can be deployed in an active/passive configuration. In the event a primary active Barracuda
Load Balancer fails, a backup Barracuda Load Balancer can quickly assume the identity of the
primary Barracuda Load Balancer. The switchover happens automatically to maintain application
availability.
8 Barracuda Load Balancer Administrator’s Guide
Features of the Barracuda Load Balancer
The Barracuda Load Balancer is designed with the following fea tures:
Load balancing for all IP-based applicat ions .. ...................... .............9
Easy Setup and Maintenance ...............................................................9
Intrusion Prevention System ..............................................................10
High Availability ............ ..................... ...................... .................... .....13
Web Administrative Interface............................................................. 13
Load balancing for all IP-based applications
The Barracuda Load Balancer is designed to provide fast and comprehensive IP load-balancing
capabilities to any IP-based application, including:
•HTTP
•HTTPS (SSL)
•SSH
•SMTP
•IMAP
•RDP (Terminal Services)
•POP3
•NTP
•ASP
•Streaming Media
•DNS
•LDAP
•RADIUS
•TFTP
•Other TCP/UDP-based services
Easy Setup and Maintenance
The Barracuda Load Balancer is extremely easy to deploy, fe aturing auto matic discov ery of systems
in the server farm and easy-to-use configuration tools through an intuitive Web interface. To
minimize ongoing administration associated with security, the Barracuda Load Balancer can
automatically receive current intrusion prevention and security updates from Barracuda Central, an
advanced technology operations center.
Introduction 9
Intrusion Prevention System
Many security technologies are integrated into the Ba rracuda Load Balancer. The set-and-forget
Intrusion Prevention System (IPS) helps secure your network, even if you may have missed a patch
or if an exploit manages to get past your existing security. The Barracuda Load Balancer will
automatically block any exploits that are detected across any protocol; no configuration is required.
The built-in IPS also provides Denial of Service (DoS) protection for all load-balanced servers.
There are important differences between an Intrusion Detection System (IDS) and an IPS. An IDS
and an IPS are similar conceptually; however, an IDS merely alerts and can become a significant
source of incoming messages during an attack. An IPS, on the other hand, is capable of rejecting a
connection before damage is done. This makes it much less noisy in that it does not alert on every
attempt, and instead will simply block any malicious activity.
As with any security feature, IPS is designed to complement any existing security measures, not
replace them. The role of the Intrusion Prevention System is to eliminate any damage from an attack
that manages to penetrate the existing security architecture.
The Intrusion Prevention System protects all your load-balanced services from the following common
threats:
•Virus propagation
•Buffer overflows
•Protocol-specific attacks. The Barracuda Load Balancer contains protocol-specific guards that
protect your Real Servers from attacks targeting the SMTP, DNS, and LDAP protocols.
•Application-specific attacks. The Barracuda Load Balancer protects common applications that
are particularly vulnerable to external attacks. These applications include IIS, Websphere, Cold
Fusion, Exchange, and many more.
•Operating system-specific attacks. The Barracuda Load Balanc er contains Microsoft and UNIXspecific detection capabilities that identify malicious activity against these operating systems.
The Intrusion Prevention System is updated with the latest threats every hour by Energize Updates.
The following figure shows how Barracuda Central provides the latest rules and definitions through
the Energize Update feature.
10 Barracuda Load Balancer Administrator’s Guide
Figure 1.1: Barracuda Energize Updates
Auto-Discover
All models of the Barracuda Load Balancer support Auto-Discovery of Real Servers and Services, to
ensure quick and easy deployment of new servers. For common services, there's no need to manually
configure each port. The Barracuda Load Balancer can automatically detect which services are
running on a specified server and save deployment and configuration time.
Layer 4 IP Persistence
The Barracuda Load Balancer supports technology that directs clients back to the same server. In
environments where session persistence is required, Layer 4 IP persistence provides a fast and reliable
solution for most configurations including encrypted e-commerce traffic and database applications.
The length of time that session persistence is maintained during a time of inactivity can be enabled on
a Service level.
Layer 7 Cookie Persistence
Session persistence for many HTTP-based applications can also be tracked by using cookies. The
Barracuda Load Balancer supports all cookies that are gene rated or used by any application, as well
as cookie insertion for times when applications do no t have or use their own cooki es. Persistenc e in
all cases will last for as long as the cookie does unless a period of inactivity exceeds the configured
timeout value.
Introduction 11
Cookie persistence is not available if using the Direct Server Return (DSR) mode of deployment
unless the application manages the co okies. This is because the cookie is inse rted into the data stream
by the Barracuda Load Balancer when the traffic is ou tbound. In DSR t he traffic goes di rectly to the
client, bypassing the Barracuda Load Balancer, so there is no opportunity to insert a cookie.
Session Directory Integration
Session persistence may also be maintained by queryi ng Windows Server 20 03 Session Dire ctory or
Windows Server 2008 Terminal Services Session Broker. The Barracuda Load Balancer notes the
open sessions on each Terminal Server and checks if each connecting client already has a session open
on a particular Terminal Server. If the client has an open session, the Barracuda Load Balancer
forwards that user to the appropriate Terminal Server.
SSL Offloading / Acceleration
The Barracuda Load Balancer has the ability to handle SSL encryption and decryption locally , to help
ease the burden on backend Real Servers. Hardware SSL Acceleration is available on selected
models.
SSL offloading is not available if using the Direct Server Return mode of deployment.
Scheduling Policy
The Barracuda Load Balancer supports multiple scheduling technologies that support server
weighting including Weighted Least Connection (WLC) and Weighted Round Robin (WRR). The
Barracuda Load Balancer also supports adaptive scheduling, a resource based algorithm that can
take into account factors like CPU load or a customer modifiable load URL option. You can also
specify that certain servers handle more traffic than others.
Automated Service Monitor
Barracuda Load Balancer features a fully integrated Service Monitor which can be configured to reroute traffic based on automated tests of servers being clust ered or their upstream and downstream
dependent infrastructure components. Downed servers are automatically removed from the farm
within seconds of server failure.
Multiple Deployment Modes
The Barracuda Load Balancers support Route-Path, Bridge-Path, and Direct Server Return modes, for
the most flexibility of any load balancer on the market. Ro ute-Path offers increased flex ibility, while
Bridge-Path allows deployment without changes to existing IP infrastructure. Direct Server Return
allows for maximum throughput, ideal for content delivery net works.
12 Barracuda Load Balancer Administrator’s Guide
High Availability
With simple setup through the Web administrative interface, the Barracuda Load Balancer supports
High Availability configurations. Just point the backup Barracuda Load Balancer to the primary
Barracuda Load Balancer's management IP address to synchronize configurations and establish a
highly available network that brings your server farm to enterprise grade availability.
Web Administrative Interface
The Barracuda Load Balancer configuration is administered through an SSL-sec ured Web interface.
With features such as quick server and service adding, health monitoring, and Auto-Discover, the
Barracuda Load Balancer is easy to use. A typical configuration can be performed in less than ten
minutes.
Last Resort Server
The Barracuda Load Balancer allows you to specify a Last Resort Serv er, which is the server to which
all traffic for a particular Service is routed in the event that all Real Servers associated with that
Service are not available. This Last Resort Server can be located on a different net work, or even across
the Internet, so long as the WAN port of the Barracuda Load Balancer has a route to that server. If all
Real Servers for a particular Service are unavailable, the Barracuda Load Balancer will route all
traffic bound for that Service to the Last Resort Server. The Last Resort Server does not need to be
configured as a Real Server for the Service, and the Barracuda Load Balancer will not perform any
health checks on the Last Resort Server.
Introduction 13
14 Barracuda Load Balancer Administrator’s Guide
Chapter 2
Load Balancing Concept s
This chapter provides an overview of the Barracuda Load Balancer and includes the following topics:
• Barracuda Load Balancer Terminology on page 16
• Load Balancer Deployment Options on page 19
Load Balancing Concepts 15
Barracuda Load Balancer Terminology
The following is a list of some of the terms used by the Barracuda Load Balancer.
Table 2.1: Barracuda Load Balancer terminology
TermDescription
ServiceA combination of a Virtual IP (VIP) and one or more TCP/UDP ports that the
Service is to listen on. Traffic arriving over the designated port(s) to the
specified Virtual IP is directed to one of the Real Servers that are associated
with a particular Service.
Service MonitorThe Service Monitor monitors the availability of the Real Servers. It can be
configured either on a per-Service or per-Real Server basis to use one of
several different methods to establish the availability of a Real Server. If the
Service Monitor finds that no Real Servers are available, you can specify an IP
address to which all traffic for the Service will be routed.
Virtual IP (VIP)The IP address assigned to a specific Service. A client uses the Virtual IP
address to connect to the load-balanced Service. The Virtual IP address must
be different than the WAN or management IP address, and it must be on the
subnet as the WAN IP address.
Real ServerOne of the systems that perform the actual work of the load-balanced Service.
The Barracuda Load Balancer assigns new connections to it as determined by
the scheduling policy in effect for the Service.
Server FarmA collection of Real Servers.
ClientThe entity requesting connection to a load-balanced Service. It can be an
external Web browser accessing your load-balanced Web site, or an internal
user connecting to a load-balanced mail server.
PersistenceA returning connection is routed to the same Real Server that handled a
previous request from the same client within a specified time. Examples of
Servces that may need persistence settings are Web sites that have shopping
carts or require some sort of login. See Enabling Persistence on page 46 for
more information.
Scheduling policySpecifies how the Barracuda Load Balancer determines which Real Server is
to receive the next connection request. Each Service can be configured with a
different policy.
More information can be found in Selecting a Scheduling Policy on page 47.
Route-Path
Bridge-Path
Direct Server Return
Deployment modes for the Barracuda Load Balancer. They differ in how the
Real Servers are connected. Details and benefits of each mode can be found
in the sections Route-Path (Recommended) on page 19 and Bridge-Path on
page 21.
Option that is enabled on individual Real Servers. However, because it can
affect how a deployment is designed, it is often treated as a mode of its own.
More details on this can be found in the section on
Direct Server Return on
page 22.
Logical NetworkA collection of systems on an isolatable subnet. In Route-Path mode, for
example, all systems associated with the LAN interface would be in one (or
more) logical network(s) 10.1.1.x, and all systems connected to the WAN
interface would be in another logical network of 192.168.1.x. See Figure 2.1: A logical network layout using Route-Path on page 17 for an example.
16 Barracuda Load Balancer Administrator’s Guide
TermDescription
Physical NetworkA group of systems that are physically connected to each other, usually
over a switch or VLAN.
Route-Path on page 18 for an example.
See Figure 2.2: A physical network layout using
WAN IP Address or
Management IP
Address
High AvailabilityA pair of Barracuda Load Balancers, one of which performs the load-balancing
The IP address assigned to the Barracuda Load Balancer, which is also the IP
address used to access the Web interface.
This address must be different than the Virtual IP addresses assigned to the
Services.
while the other monitors it, ready to take over operations if the first one fails.
For more information, see Creating a High Availability Environment on page
49.
Figure 2.1: A logical network layout using Route-Path
Load Balancing Concepts 17
Figure 2.2: A physical network layout using Route-Path
18 Barracuda Load Balancer Administrator’s Guide
Load Balancer Deployment Options
Services on the Barracuda Load Balancer can be deployed in the following three modes:
Direct Server Return ................. ........................ ........................ .........22
Choose the deployment mode for the Barracuda Load Balancer based on the type of network
configuration that currently exists at your site as well as on the types of Services you wish to load
balance. The recommended mode is Route-Path because it requires the least amount of invasive
changes to your existing network configuration. For Services that have high outbound traffic,
enabling the Direct Server Return option is recommended for the Real Servers that are producing that
traffic.
All of these deployment modes require specific network configurations. However, the Barracuda
Load Balancer must be in either Route-Path or Bridge-Path mode . Direct Server Return is an op tion
that you may choose for each Real Server.
Table 2.2 shows the number of logical and physical networks required by each deployment method.
Route-Path deployment is the most frequently used deployment method, providing the most
flexibility by allowing load-balancing of any server in a downstream route. With Route-Path, the
WAN and LAN interface of the Barracuda Load Balancer must be on se parate logic al networks. The
load-balanced servers are moved to a new private network and the Barracuda Load Balancer takes
control of the publicly-accessible IP addresses (VIPs) used to reach the Services.
The following table describes the advantages and disadvantages of deploying your Barracuda Load
Balancer in Route-Path mode.
AdvantagesDisadvantages
Minimal network re-designing; works with
existing physical configurations
Fast High Availability failoverReal servers must be on a logically separate network
The Barracuda Load Balancer must be the default
gateway for all downstream Real Servers
from the Virtual IP addresses.
Can load-balance any downstream serverAll return traffic must be directed through the Barracuda
Load Balancer
No changes to Real Server setups other than
changing their IP addresses
Load Balancing Concepts 19
Figure 2.3: Sample Route-Path network layout
Deploying Route-Path
In the Route-Path method of deployment, the Virtual IP addresses must be on the same subnet as the
Barracuda Load Balancer. The Real Servers must be on a subnet separate from the VIPs and the
Barracuda Load Balancer. This may require changing the IP addresses of your Real Servers.
Normally the Real Servers are on an isolated IP network behind the Barracuda Load Balancer. If IP
address changes are not possible, or if there i s no way to make Route-Path deployment work, the n ext
choice for deployment method is Direct Server Return. See Direct Server Return on page 22 for
details.
Real Servers that are on multiple networks simultan eously may break th e route path. If Real Servers
have more than one network adapter enabled, and traffic has a route around the Barracuda Load
Balancer, the deployment will not work p roperly even th ough it may appear to work i nitially . There
are two exceptions where Real Servers may have multiple network adapters:
•The other networks that the Real Servers are on are also isolated and cannot access the WAN
network without going through the Barracuda Load Balancer
•Static routes for incoming and outgoing traffic for each IP address of each Real Server have
been defined.
Each Real Server must be one hop away from the LAN port on the Barracuda Load Balancer. This
means their switch must be directly connected into the LAN port of the Barracuda Load Balancer, or
connected to a series of switches that eventually reach the LAN port of the Barracuda Load Balancer
without going through any other m achines.
20 Barracuda Load Balancer Administrator’s Guide
If you need to remotely administer your Real Servers individually then you should create new
Services, each of which only load balances a single Real Server. Each Real Server must list the LAN
IP address of the Barracuda Load Balancer as its gateway IP address.
Note that Real Servers in the Route-Path deployment cannot access their own VIPs, or any other VIPs
on their own Barracuda Load Balancer.
If you choose this mode of deployment, make sure that the Operating Mode of the Barracuda Load
Balancer is set to Route-Path on the
Bridge-Path
Bridge-Path provides an easy configuration scenario. Place the Barracuda Load Balancer inline wit h
your existing IP infrastructure and it can load-balance servers without changing IP addresses. With
Bridge-Path deployment, the WAN and LAN interfaces must be on physically separate networks. The
LAN interface must be on the same logical switch as the servers being load-balanced.
Despite its simple configuration, Bridge-Path deploy ment is not recommended for most situations.
The following table describes the advantages and disadvantages of deploying your Barracuda Load
Balancer in Bridge-Path mode.
AdvantagesDisadvantages
Basic>IP Configuration page.
Minimal network changes since the existing IP
infrastructure is reused
Real Servers keep their existing IP addresses Separate physical networks required for downstream
Slow High Availability failover - longer than 30 seconds.
Real Servers
Less resilient to network misconfigurations
Sensitive to broadcast storms and other errors related to
loops in a Spanning Tree protocol
Improper configuration of a Bridge-Path network may
result in a broadcast storm, resulting in network outages
Session Directory Integration is not available in BridgePath mode
Load Balancing Concepts 21
Figure 2.4: Sample Bridge-Path network layout
Deploying Bridge-Path
In Bridge-Path mode, the Real Servers must be physically isolated behind the Barracuda Load
Balancer. This means that each Real Server is no longer visible on the net work if the Barracuda Load
Balancer becomes unavailable (a separate switch is absolutely required for models 440 and below).
Each Real Server must be one hop away from the LAN port on the Barracuda Load Balancer. This
means their switch must be directly connected into the LAN port of the Barracuda Load Balancer, or
connected to a series of switches that eventually reach the LAN port of the Barracuda Load Balancer
without going through any other machines. The Real Servers must be on the same subnet and logical
network as the Barracuda Load Balancer, the VIPs, and the rest of the WAN, and they must specify
the same gateway as the Barracuda Load Balancer.
Finally, make sure that the Operating Mode of the Barracuda Loa d Balancer is se t to Bridge-Path on
Basic>IP Configuration page. The LAN IP Address on the same page should be empty.
the
Direct Server Return
Direct Server Return (DSR) is an option associated with a Real Server which allows for increased
outbound traffic throughput. In DSR, connection requests and incoming traffic still go from the
Barracuda Load Balancer to the Real Server, but all outgoing traffic goes directly from the Real
Server to the client. Because the Barracuda Load B alancer does not process the outbou nd traf fic, the
throughput is increased.
Because the Barracuda Load Balancer does not process the outgoing traffic, Direct Server Return
does not support SSL offloading or cookie persistence.
With DSR, requests come through the WAN interface of the Barracuda Load Balancer and are handed
off to the Real Servers via the WAN port. The Real Servers then respond directly to the request
22 Barracuda Load Balancer Administrator’s Guide
through their own interfaces. This implementation requires enabli ng a non-ARPing loopback adapter,
a feature that can be found on most server operating systems. Your applications may need to be
explicitly bound to the loopback adapter.
The Barracuda Load Balancer does not alter packets when it delivers them to the Real Servers.
Instead, only the destination MAC address is changed to match the Real Server that is to handle the
request, as shown in Figure 2.5.
Figure 2.5: Direct Server Return Packet Handling
DSR configuration can be more complex than the other methods of deployment. Because of this, it
is recommended that it be used only when there is a specific need. Situations where DSR is
recommended include streaming media, Real Servers not on an isolated subnet, and Windows servers.
• If the outbound traffic is far greater than the inbound traffic, for example, if the Real
Servers are providing streamed audio or visual media, throughput will be increased by
using DSR.
• If the Real Servers cannot be placed on a separate and isolated subnet from the Barracuda
Load Balancer, it may be better to use DSR than Route-Path. If the Real Servers are in a
Load Balancing Concepts 23
Loading...
+ 53 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.