Changes

Jump to: navigation, search

Load balancing

6,025 bytes added, 17:16, 10 February 2018
no edit summary
The load balancer can dynamically redirect and route traffic. 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 ==
* Internet failover
It's most commonly used to forward traffic to multiple servers with load distribution and health checking. This functionality can, with some generalization, be divided into layer 3 (called redirects) and layer 4+ (called relays). They are configured in much the same way, but have some striking technical differences. Both the redirects and relays are sometimes referred to as "virtual servers" in other products.
 
=== Check and distribution methods ===
The following methods can be used to check the health of a host.
{| class="wikitable"
! Syntax !! Comment
|-
| <tt>http ... code</tt> || HTTP(S) response code
|-
| <tt>http ... digest</tt> || HTTP(S) response content digest
|-
| <tt>send</tt> || Raw data response to configurable request (possibly using SSL)
|-
| <tt>script</tt> || Shell or Perl script [[Root_access|placed]] in the <tt>/cfg/relayd/</tt> folder
|-
| <tt>ssl</tt> || Complete SSL handshake on the forwarded port
|-
| <tt>tcp</tt>|| Complete TCP handshake on the forwarded port
|-
| <tt>icmp</tt> || Ping the host
|}
 
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 ====
Some protocols need <tt>sticky-session address</tt> in order to load-balance properly, like FTP where the control- (21) and data-connection must end up on the same backend server, or web-sessions which doesn't have a shared session store. The load-balancer uses the firewalls source tracking cache to keep track of previous redirects from a particular source address (IP). This cache has two parameters, one of which you may need to change primarily for web applications.
In the configuration editor, you may set these values in the <tt>firewall {</tt> section.
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 server. 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 ==
The preferred way of creating notifications is using SNMP traps; notifying all trap receivers about hostUp and hostDown event. Configure a trap receiver on the System > SNMP page, and then enable SNMP traps on the Network > Load balancer page. In raw configuration, this equals to
load-balanacer {
send traps
...
}
system {
snmp-server {
trap receiver X.X.X.X
}
...
}
...
 
The <tt>relayd</tt> daemon sends a <tt>enterprise.30155.3.1</tt> (relaydStateChange), with descriptive object values. Please note that this MIB file's layout is not final and may be revised in the future. The MIB file is available from the Network > Load balancer page.
 
+--openBSD(30155)
|
+--relaydMIBObjects(3)
|
+--relaydStateChange(1)
+-- -R-- String hostName(1)
+-- -R-- EnumVal hostStatus(2)
| Values: hostDown(-1), hostUnknown(0), hostUp(1)
+-- -R-- EnumVal hostLastStatus(3)
| Values: hostDown(-1), hostUnknown(0), hostUp(1)
+-- -R-- INTEGER checksSuccessful(4)
+-- -R-- INTEGER checks(5)
+-- -R-- String tableName(6)
+-- -R-- INTEGER tableHosts(7)
+-- -R-- INTEGER hostRetriesLeft(8)
+-- -R-- INTEGER hostRetries(9)
 
=== Net-SNMP guide ===
This short guide describes how to set up a trap receiver with Net-SNMP[http://www.net-snmp.org] and run a custom script when a load balancer host is up/down. Net-SNMP works on many platforms including Win32, OSX and Linux. SNMP authentication and security is out of scope for this guide.
 
# Install the HALON-RELAYD-TRAP-MIB.txt file to your mibs/ folder.
# Create a configuration file for <tt>snmptrapd</tt> (snmptrapd.conf). Run whatever script/interpreter you prefer (eg. PHP). <pre>authCommunity log,execute,net public&#10;traphandle HALON-RELAYD-TRAP-MIB::relaydStateChange /path/to/php /path/trap.php</pre>
# Start <tt>snmptrapd</tt>.
 
Below is an example <tt>trap.php</tt> script file.
 
<?php
$result = array();
$result['host'] = trim(fgets(STDIN));
$result['ip'] = trim(fgets(STDIN));
while(!feof(STDIN)) {
list($type, $value) = explode(' ', trim(fgets(STDIN)), 2);
if ($type == "") break;
$result[$type] = $value;
}
mail("[email protected]", "SNMP trap", var_export($result, true));
?>

Navigation menu