Top Three KEMP LoadMaster options & things to be aware of when using them

The following is a list of top three KEMP LoadMaster options and things to be aware of when configuring these options on the LoadMaster appliance (virtual or hardware) in a network infrastructure. In particular, the options that will be discussed in detail are: Transparency, High Availability, and Bonding. The goal of this document is to educate an end user with the best approach for when configuring these options as to avoid any possible first time setup/deployment issues with the LoadMaster.

 

  1. Transparency – when configuring a Virtual Service on a KEMP LoadMaster, Transparency is enabled by default so if Transparency is not needed and will not be used then this should be disabled while configuring the VS as this will cause routing issues with traffic headed to the LoadMaster if not configured correctly.

What is Transparency? Transparency as far as Kemp LoadMasters are concerned means that the LoadMaster will pass along the original source IP address of the client.  So when a request comes into a Virtual Service, and to the VIP, the client request will be passed off to the best available server but it will look like its coming from the original source IP of the client, and not from the Load Balancer.

In contrast Non-Transparency means that the LoadMaster will NAT the IP address of the client so that the source IP appears to be coming from the LoadMaster. So when Transparency is disabled then all traffic looks like it is coming from the Load Balancer. NOTE: by default any VS configured for Layer 4 traffic is Transparent and if Non-Transparency is needed or desired then the box that says “Force L7” MUST be enabled. See the screen shot below.


Figure 1 - Force L7 option in a Virtual Service.

 

Routing issues are the #1 problem in LoadMaster setup so when first setting up a LoadMaster and for some reason you’re seeing network resets and time outs, check to see if Transparency is enabled. If it is try to turn Transparency off and if the problem disappears then the configuration with the LoadMaster on your network and/or routing from your servers was either not configured correctly or there is more than likely another routing issue somewhere in your network. See the screen shot below for the Transparency setting in a Virtual Service.


Figure 2 - Transparency option in a Virtual Service.


 

The simple reason or cause of this is that if you have Transparency enabled in a Layer 7 VS or perhaps are using a Layer 4 VS for your traffic, the default gateway for your servers MUST be the Load Balancer interface IP or the shared IP if you have two LoadMasters in HA mode. All the traffic going through the LoadMaster(s) and to your servers has to flow back out through the LoadMaster(s) interface. 

  1. High Availability – when configuring High Availability for two KEMP LoadMasters (hardware or virtual appliances), please note the following important settings and guidelines that are critical to a successful first time setup/deployment of an HA pair:

 

NTP Host. Prior to pairing two LoadMasters, an NTP Host should be set to ensure no time drift occurs between the two appliances in the HA pair. The reason being is that the HeartBeat and CARP packets that flow between the appliances carry a timestamp. For example, if using the default HA timeout setting of 9 seconds and if the time difference or drift between the appliances is more than 9 seconds, the Standby or Hot Standby appliance thinks it missed or didn't receive any HeartBeat/CARP packets (which in actuality it did) and will assume the Active appliance is dead. This is because it is fooled into thinking it didn’t receive any packets thus initiating a failover event to occur.  Examples of NTP Hosts that can be used are time.nist.gov or the IP address of a Domain Controller and can be set by drilling down to System Configuration > System Administration > Date/Time in the LoadMaster Web User Interface (WUI). See the screen shots below.


Figure 3 – Navigating to the Date/Time setting in the LoadMaster WUI.


Figure 4 – Setting an NTP Host.


 

NOTE: Once an NTP Host has been added and is set by clicking on the “Set NTP host” button the following message must follow a few seconds after to ensure the LoadMasters are able to grab the time from the NTP time source. Setting an NTP Host is normally done through the shared management IP address of the HA pair however to avoid a lengthy delay in synchronizing the LoadMaster HA pair to a particular NTP Host, it would be best to set the NTP Host on the Master and Standby appliance individually. Set the NTP Host information on the Master first, wait to see the message below then set the NTP Host on the Standby and make sure the message below is returned. That should successfully complete the NTP Host setup for the HA pair without a delay.


Figure 5 – NTP message received after setting an NTP Host.

HA Virtual ID. The HA Virtual ID field under the HA Parameters should be changed to a number other than "1" if there are any other network appliances functioning as virtual clusters in the network infrastructure. This is because a Virtual ID of “1” is commonly used by vendors such as Cisco, and etc when it comes to clustering networking devices such as switches, routers, firewalls, etc. The HA Parameters can be located by drilling down to System Configuration > Miscellaneous Options > HA Parameters in the LoadMaster WUI. See the screen shots below.

Figure 6 – Navigating to the HA Parameters in the LoadMaster WUI.

Figure 7 – Setting the HA Virtual ID in the HA Parameters.

 

Use for HA checks. On a network interface, the "Use for HA checks" box MUST be selected on any interface that will be used for sending HeartBeats to the Partner LoadMaster. This applies regardless if the interface has an IP address assigned and connected to a switch or if there is a direct cable connect on the "eth1" interfaces of both LoadMasters. NOTE: if a direct cable connect is implemented, assigning an IP address on the “eth1” interface is not necessary and should not be added unless it will also be used as an HA Update or Multicast interface. See the screen shot below.


Figure 8 – Setting an interface for HA checks.


 

L4/L7 Updates. Ensure "Inter HA L4 TCP Connection Updates" and/or "Inter HA L7 Persistency Updates" are selected depending on what Layers the Virtual Services have been configured on. If both Layer 4 and Layer 7 Virtual Services are configured then both of these options should be selected to ensure consistent connection/persistence updates are synchronized between LoadMaster partners for the Virtual Services that are configured. These settings ensure that client session and connection state remains intact during an HA failover scenario. See the screen shot below.


Figure 9 – Setting Inter HA Updates in the HA Parameters.

 

HA Multicast Interface. Once the Inter HA option(s) have been selected, ensure the correct "HA Multicast Interface" is selected in the HA parameters.  This is the interface that’s used for syncing connection/persistence updates (as mentioned above). So, for example if there is a direct cable connect between the two LoadMasters, “out of band” Multicast updates or syncs can be done. As an example, you can specify the second interface on the LoadMasters (eth1) to be your sync port and it will pass the Multicast information “out of band” on that port only thus keeping it out of, or separate from your network. That said it is without a doubt a great idea to have at least two connections on your LoadMaster HA pair. NOTE: The HA Multicast Interface is not to be confused with the HA Update Interface as the Update Interface is used to synchronize configuration updates from the Active to the Partner LoadMaster.  See the screen shot below.


Figure 10 – Setting an interface for HA Multicast Updates in the HA Parameters.

 

  1. Bonding/VLAN’s – one of the main reasons why Bonding is configured is because various kinds of application traffic will need to be routed through different VLAN’s on one interface and bonding allows this traffic to pass through a group or team of interfaces at the same time instead of just one allowing for more bandwidth for the VLAN traffic. If this is the case the rule is simple, bond the interfaces first then add the VLAN’s after. This is simply because from a logical standpoint the bonded interface is seen as one interface and the VLAN’s get configured “on top of” or get affiliated with the interface name such as “bnd0” for example rather than eth0 or eth1 which are single interfaces. NOTE: If the eth0 interface will need to be included as one of the bonded interfaces, in order to maintain remote management access to the LoadMaster WUI, access needs to be temporarily switched to another interface that will not be part of the bond before configuring the bonded interface. This is because by default, the management interface on the LoadMaster is set to eth0. Once the bond has been set up, remote management can be switched back to the bonded interface if desired but if not then it can be left alone. Remote management access using another interface can be set through the Remote Access configuration settings. The Remote Access settings can be located by drilling down to System Configuration > Miscellaneous Options > Remote Access in the LoadMaster WUI.  See the screen shots below.

Figure 11 – Navigating to the Remote Access settings in the LoadMaster WUI.Figure 12 – Setting an alternate Management Interface through the Remote Access settings.


Figure 13 – Location of Bonding and VLAN Configuration settings on a Network Interface in the LoadMaster WUI.

In conclusion, Transparency, High Availability, and Bonding are the top three KEMP LoadMaster options that usually dictate or determine whether a first time LoadMaster (virtual or hardware) deployment is successful or not. Adhering to the recommendations and guidelines mentioned in this document can aid in preventing common first time setup issues and pitfalls. For more detailed information on LoadMaster setup and on the complete feature set, please visit this link: http://www.kemptechnologies.com/loadmaster-documentation