Having discussed a basic setup in our last part of our “cookbook” series, this time we want to look at some details. We will do this using a checklist with explanations.

The topics:

1. Virtual Service – Installation
2. SNAT
3. Stateful Failover
4. Virtual MAC
5. Positive HA-Recognition
6. LoadMaster as a Router
7. Fast Switchover in case of a server breakdown
8. Drain Stopping
9. Logging using an external Syslog Server
10. Backup
11. [Amendment: Interface Monitoring]

Before we start, perhaps an Nr.0:

0. Make sure the firmware is up-to-date

   This could prevent future problems. The current approved version can be found here ( as always to be obtained via the Kemp Support )
    

1. Virtual Service – Installation
   Lets talk about some details of the Virtual Services – these settings must be carried out for each service individually.

1. Transparency on!
   Whenever possible all services should use active “Transparency”. This has got some mandatory requirements:

• The Default Gateway of the Real Server is the LoadMaster ( more precisely: their shared IP)
• No clients in the same subnet as the Real Server

(Also see the blog article about Transparency) [Link: Link to blog entry: Was bedeutet eigentlich Transparenz. I can’t find this article in your blog. Have attached it to this email again]

Note: L4-Services use Transparency by default. Certain Constellations (SSL Reencryption, Nested Virtual Services) generally prevent Transparency.

2. High quality fault monitoring!

• Select a representative URL (which shouldn’t stress the Server too much)
• In case you use name based virtual hosts on the web server you might need to specify the server name of the server to be monitored. To do so activate “HTTP 1.1”!
   

3. Sensible Persistency Values
    

• Select a generous Persistency Value (“Timeout”)! Ideally it should be equal or larger than the longest session life time of your application. In case the life time is not known or flexible I usually recommend 30 minutes (unless you have hundred thousands of users on your system...).
• In case you are using “Active Cookie”: Pick a name that is not used elsewhere.
• If the persistency rule of your choice allows for “OR Source-IP”, use it. This enables a fallback even though the actual persistency criteria is not available (i.e. no cookie support by the browser)

   

4. Select a sensible distribution method!
   No idea what to choose? “Weighted Least Connections” almost always suits.

2. SNAT

   SNAT doesn’t make sense unless the connected servers need to create their own connections to the internet (i.e. DNS requests or in order to send emails) and thus need to “hide” behind the LoadMaster IP.

   Depending on the routing, in many cases this “hiding” might create undesirable effects.

Thus: Unless you don’t absolutely need it disable this option!

3. Stateful Failover

   Using two LoadMasters in high availability mode (“HA-mode”) the changeover (planned or breakdown) between the LoadMaster should happen without a loss of service. Especially running web services (HTTP/S) it is very important that the session is maintained. To do so activate the “Inter HA L7 Persistency Updates” option. (When using virtual services in L4 mode also activate the L4 option.)
    

4. “Virtual MAC”

To manage the switchover between two LoadMasters fast and smoothly, it is recommended to activate the “Virtual MAC” option. (This option is not available on Virtual LoadMasters, as they don’t always support this functionality.) This makes sure, that in case of a failover, not only the IP addresses but also the Ethernet addresses will be transferred to the second LoadMaster. Thus the surrounding systems don’t need to adapt their ARP-Caches, but can just continue undisturbed.
 

This option can be found within the “HA parameters” on the same screen than “Stateful Failover right at the bottom.

Careful: Not every switch allows for the change of the Ethernet address from one LoadMaster to the other – sometimes the security configurations prevent this. So please check for this and adjust if applicable!

5. Positive HA-Recognition

   Just another HA trifle: By default the cluster-ID is set to “1” – should there be another cluster-system in the same network problems might arise. So take care administrating this... I made a habit out of changing the ID to a non-default value.

6. LoadMaster as a Router

A fact not widely known: Wanting to reach appliances downstream the LoadMaster directly (i.e. via SSH, RDP or the like) nothing needs to be done, because the LoadMaster acts as a router by default.

If that is not desired (i.e. in a DMZ environment), this functionality might be switched off. This is called “packet Filter” and looks like that:

7. Fast switchover on case of a server breakdown

Example Exchange 2010: In some Virtual Services looong timeouts are used to protect the user from annoying warnings. If a “Real Server” would fail in such a case the LoadMaster would wait for the timeout. To avoid this (thus switching over immediately) just tick “Drop Connection on RS failure”!

8.  Drain Stopping

In the meantime we have reached the real “fine-tuning”. What happens if deactivating a Real Server at the LoadMaster- i.e. for maintenance? The Real Server can be deactivated completely or each service individually.

• Open connections stay live
• If persistency is defined, even new connections from the same client will be sent to the same Real Server. This happens over a defined period, the so called “Drain Stop” Timeout

This mode is used to avoid a “hard” drop of the user from the session (I.e. losing his shopping basket or having to log in again). In fact no new clients are accepted, thus over time less and less users will be linked to the Real Server. (The number of active connections can be checked using the statistics)

Depending on the nature of the service it might be sensible to define very long Drain Stop times and to start the deactivating long before the maintenance.

9.  Logging using an external Syslog-Server

Would you like to store LoadMaster messages permanently? Then you should remember that the LoadMaster doesn’t save these messages – at least after the next reboot the logs get cleared. This makes it necessary to set up forwarding the messages to an external Syslog-server.

This can be done at “System Configuration” -> “Logging Options” -> Syslog Options”. Ideally only forward messages with a status of WARN and higher, otherwise this could create quiet a lot of data...

10. Backup

Last but not least a classic: Don’t forget the backup!

A few subtleties you should be aware of:

• A backup of a HA-pair contains the configurations of both systems – no separate backups are necessary
• Passwords are not saved – a rebuild won’t change them. (Want to reset a lost password? Have a look at the manual, keyword “pwreset”...)
• SSL certificates are relevant to security, thus not contained in a standard backup. Instead a separate passphrase secured certificate backup  should be used (“certificates” ->”Backup/Restore Certs.”)!

Amendment: 11. Monitoring your Interface

I just remembered another important subject: The “Use for HA checks” option.