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.
Before we start, perhaps an Nr.0:
This could prevent future problems. The current approved version can be found here ( as always to be obtained via the Kemp Support )
(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.
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!
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.)
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!
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.
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:
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.
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...
Last but not least a classic: Don’t forget the backup!
A few subtleties you should be aware of:
Amendment: 11. Monitoring your Interface
I just remembered another important subject: The “Use for HA checks” option.