Changes

Jump to: navigation, search

Load balancing

1,777 bytes added, 17:16, 10 February 2018
no edit summary
The load balancer can dynamically redirect and route traffic. Halon Security's implementation is based on, and slightly extends, We use OpenBSD's relayd which makes relayd.conf's manual page[http://www.openbsd.org/cgi-bin/man.cgi?query=relayd.conf] a great source of information.
== Introduction ==
| <tt>send</tt> || Raw data response to configurable request (possibly using SSL)
|-
| <tt>script</tt> || Shell or Perl script [[Skeleton filesRoot_access|Installedplaced]] shell or Perl scriptin the <tt>/cfg/relayd/</tt> folder
|-
| <tt>ssl</tt> || Complete SSL handshake on the forwarded port
Traffic is distributed over the active hosts using one of the following methods. Persistence is sometimes provided by the distribution method, and otherwise (in case of for example least states) by the source tracking mechanism (if [[#Redirect sticky address|sticky address]] is enabled).
{| class="wikitable"
! Syntax !! Supported by !! Comment
|-
| <tt>loadbalance</tt>|| Relays || Source IP address of the client, and the IP address and port of the relay
|-
| <tt>source-hash</tt> || Relays || Source IP address of the client
|-
| <tt>hash</tt> || Relays || Input fed from the protocol specification, for example HTTP headers and GET variables
|-
| <tt>least-states</tt> || Redirects || The host with the fewest active connections (firewall states)
|-
| <tt>roundrobin</tt> ||Relays, Redirects || Distributes connections using round robin to all active hosts
|-
| <tt>random</tt> ||Relays || Distributes connections randomly to all active hosts
|}
 
=== Layer 3 (redirects) ===
Layer 3 load balancing is implemented as a firewall port forward, which is very efficient, and therefore gives layer 3 load balancing a performance advantage over layer 4+. Because of its implementation, it '''requires the firewall to be started''' (simply check if there are any firewall rules in the configuration). Also because if this, it's normally not necessary to add any additional firewall rules. Further, it's necessary that the load balancer is the default route (gateway) of the servers being load balanced, since the source packets of the incoming traffic is maintained. In order words, the topology would look something like:
Internet -> Halon SR -> Switch -> Server1
-> Server2
-> Server3
# Check that the firewall is enabled by looking for a <tt>firewall</tt> statement in the configuration, or rules on the Network > Firewall page (if not, add a rule)
# Go to the Network > Load balancer page, click the "Pools (tables)" button and then click "Add pool"
# Just give it Give the pool a name, type an IP address in the table's node column (add Add multiple hosts by pressing the + icon to the right in the table header) and finally click "ApplySave"# If you likewant, you can click the "Node (hosts)" button and give names to the IP addresses namesyou just added and then click "Save"
# Click the "Relays (servers)" button, click "Add..." and select "Redirect (layer 3)"
# Just give it Give the redirect a name, and add one or more listen address addresses (the external virtual IP), and listen port, forward pool ports (By pressing the + icon to the right in the table header)# Add the forward pool you created in step 3. It's possible to specifiy more than one forward pool (by adding an additional row) . The second row's nodes will be used as backup if all nodes in the main forward's pool are down.# When you're done, apply the changes by clicking "Save" and then click "ApplyDeploy working copy".# Click ==== Filtering traffic ==== If you want to create your own firewall rules for a particular redirect (for example, if you wish to block a certain IP from accessing the redirect) you'll need to enter a "Redirect firewall tag" and enable the "CancelRedirect match-only" button, then click checkbox in the settings for the newly added redirect . Please keep in mind that if you enable this setting you most likely have to add rules on your own allowing traffic to the table, and watch the health check statusredirect.
==== Redirect sticky address ====
Unlike redirects, relays doesn't require the firewall to be enabled, nor that the load balancer is the servers' default route (gateway). In fact, the most common scenario is to perform layer 4 load balancing with the firewall disabled (removing the <tt>firewall</tt> configuration) and to not use the load balancer as a router. Please keep in mind that if the firewall is enabled (simply check if there are any firewall rules in the configuration), you most likely have to add rules on your own allowing traffic to the relay. The topology would look something like:
Internet -> Router -> Switch <-> HalonSR
-> Server1
-> Server2  Note that unlike redirects, you can only specify '''one''' listen port for each relay you create.
To add a layer 4+ load balancer, follow these steps
# Check if the firewall is enabled by looking for a <tt>firewall</tt> statement in the configuration, or rules on the Network > Firewall page (if it is, you might have to add rulesfor the relay)
# Go to the Network > Load balancer page, click the "Pools (tables)" button and then click "Add pool"
# Just give it Give the pool a name, type an IP address in the table's node column (add Add multiple hosts by pressing the + icon to the right in the table header) and finally click "ApplySave"# If you likewant, you can click the "Node (hosts)" button and give names to the IP addresses namesyou just added and then click "Save"
# Click the "Relays (servers)" button, click "Add..." and select "Relay (layer 4+)"
# Just give it Give the relay a name, and add '''one''' listen address (the external virtual IP) and set '''one''' listen port, # Add the forward pool (the pool you created in step 3. It's possible to specifiy more than one forward pool (by adding an additional row) and then click "Apply". The second row's nodes will be used as backup if all nodes in the main forward's pool are down.# Click When you're done, apply the changes by clicking "CancelSave" button, and then click the newly added relay in the table, and watch the health check status"Deploy working copy".
== Configuration examples ==
table <servers> { 192.168.0.101 192.168.0.102 }
relay "webservers" {
listen on 192.168.0.100 port 443 ssltls
forward to <servers> port 80 check tcp
}
}
Then, upload the certificate and private key. Currently, these are not in the configuration file. Instead, enable [[root access]] (already enabled by the above example) and upload the file using for example <tt>sepscp</tt> according to the [[skeleton files]] guidelines. You can also try out the load balancer by using the web administration's self-signed certificate, by issuing the following commands when logged in as root:
# cp /etc/ssl/server.crt /etccfg/skel/ssl/192.168.0.100.crt # cp /etc/ssl/private/server.key /etccfg/skel/ssl/private/192.168.0.100.key
=== Internet failover ===
The load balancer can be used to select one of several default routers (gateways) which is useful for outbound internet failover when more sophisticated protocols such as BGP is unavailable. Below is an incomplete example of such a a configurationusing one main gateway and one fallback gateway. Note the different priorities used for the gateways in this example as these are the lowest and highest priorities that you can assign to individual hosts (gateways in this case) in the load balancer.
load-balancer {
gw1 main_gateway = 212.37.18.193 gw2 fallback_gateway = 213.12.48.1 table <gateways> { $gw1 main_gateway retry 2 ip ttl 1, priority 8 $gw2 fallback_gateway ip ttl 1 priority 52 }
router "internetfailover" {
forward to <gateways> check icmp
route 0.0.0.0/0
forward to <gateways> check icmp
}
}
 
Note that this function does '''not''' require a load-balancer license.
=== SSL stripping ===
If you would like to strip the SSL from a service that is only available over SSL (eg. the web administration, even thou though it's not recommended nor good practice), this example shows how to make the web administration available for unsecure HTTP connections.
load-balancer {
relay "webui" {
listen on 0.0.0.0 port 80
forward with ssl tls to 127.0.0.1 port 443
}
}
Be aware that some web services send "secure" cookies (Set-Cookie), that needs to be disabled on the backend web server. This is also true for our built-in web uiserver. Add this to your [[skeleton files]] <tt>rc.local</tt>for the example above to work.
#!/bin/sh
perl -pi -e 's/session.cookie_secure=True/session.cookie_secure=False/g' /etc/php-5.3.ini
pkill -9 httpd
 
=== Microsoft Exchange ===
 
We have a separate article on [[Load balancing Microsoft Exchange]].
== SNMP traps ==

Navigation menu