Kemp leads the industry in driving the price/performance value proposition for application delivery and load balancing to levels that our customers can afford. Our productsâ versatile and powerful architecture provide the highest value, while enabling our customers to optimize their businesses that rely on Internet-based infrastructure to conduct business with their customers, employees and partners.
Kemp LoadMaster family of feature-rich application delivery controllers and server load balancer appliances automatically and intelligently manage user traffic and applications, to deliver website integrity for all sizes of businesses and managed service providers.
Kemp products optimize web infrastructure as defined by high-availability, high-performance, flexible scalability, ease of management and secure operations - while streamlining IT costs. LoadMaster simplifies the management of networked resources, and optimizes and accelerates user access to diverse servers, content and transaction-based systems.
For a lot of organisations, having the company website or intranet accessible, secure and continuously operating is critical. With a powerful Application Delivery Controller (ADC) or load balancer from Kemp, you will be providing your business with a high-value, reliable infrastructure appliance that will significantly improve your web server performance, reduce costs and increase your customerâs web experience.
The LoadMaster Application Delivery Controller (ADC) provides the following features with the LoadMaster Operating Software and the Web User Interface (WUI):
Application Front End
Rule Based Content Switching
Bonding and VLAN
FIPS 140-2 Level 2 compliance
An example of a two-armed LoadMaster site may look as follows.
The system has been configured as follows:
A Virtual Service has been created on the LoadMaster with an IP address of 220.127.116.11 for an HTTP service.
The Virtual Service has been configured to balance the incoming traffic across the Real Servers (server 1, 2 and 3).
A user requests the URL http://www.kemptechnologies.com.
The URL will be resolved by the DNS into IP address 18.104.22.168.
The request will be routed to the LoadMaster, which offers this IP address as an IP-alias of its network interface eth0.
The LoadMaster is connected to the server farm subnet 10.0.0.0 using its network interface eth1.
The LoadMaster knows that there are three Real Servers in this subnet that are assigned to the requested address 22.214.171.124 and are able to deliver the required content.
The LoadMaster uses the load balancing method configured, for example weighted round robin, to send the request on to one of the three Real Servers.
Other items to note regarding the two-armed configuration are:
- Both eth0 (net side) and eth1 (farm side) interfaces are used. Additional ports go to the farm side for multi-armed configurations
- The server farm(s) may make use of non-routable (RFC1918) IP addresses
Leveraging one port and configuring the âAdditional Subnetâ feature qualifies as two-armed.
The High Availability feature of the LoadMaster guarantees the availability of your server farm. HA is achieved by a hot-standby, failover mechanism. Two identical LoadMaster units are integrated into the network as a cluster. One machine serves as the active LoadMaster and the second one remains in a standby, idle state, always prepared to take over the activities from the active server. This cluster appears as a single logical unit to the Internet side and to the server farm side connections.
With an HA cluster, each network interface has an individual IP address and one shared IP address which is shared with the partner unit. The shared IP address is identical for both LoadMaster appliances, though it is associated with only the active LoadMaster at any given time.
If the LoadMaster is set as the default gateway of the servers, remember to use the shared address of the HA pair since this address will always be available.
During normal operation each node periodically sends health check messages over the eth0 and eth1 connections to verify the availability of the peer appliance. Health checks are enabled unless they have been explicitly disabled. In the event that the active LoadMaster should fail, the standby appliance will become active and take over the task of balancing.
The topology for HA dual arm looks like this:
Both HA1 and HA2 use eth0 to connect to the network (firewall) and eth2 for connection to the servers. The two eth0 ports have one shared IP address and the two eth2 ports have a different shared IP address. Health checking between the two LoadMasters occurs between both eth ports. Optionally, eth1 on each unit may be directly connected using a patch cable for added HA health checking though it is quite unnecessary since there is already 2 health check routes between the HA pair.
HA1 and HA2 must be on the same subnet with the same default gateway and be located within the same physical site. They must not be separated by an intra-site link and must use the same gateway to return traffic.
Running HA spanned across multiple subnets will not provide hardware redundancy in the event of a failure of the link between them. If traffic balancing between multiple sites is required, the GEO LoadMaster is the correct solution. This Kemp's DNS-based appliance that employs health checking to avoid site outages.
Clustering involves deployment of multiple LoadMaster instances (nodes) as a single management and control domain where each node is actively passing traffic. If any of these nodes fail - the remaining nodes continue to provide service to the remote client, providing resilience.
Clustering supports scaling - LoadMaster nodes can be added to or removed from a cluster so that capacity can be dynamically adjusted to match business requirements. Each additional LoadMaster node which is added to the cluster can provide a linear increase in throughput and performance. The maximum number of nodes that can be added to a cluster is defined by your license agreement.
An example use case is - if a website experiences higher than usual traffic during a holiday period and the amount of traffic cannot be predicted in advance - often the capacity is over-provisioned to handle these requests that come in spikes. One of the simplest solutions is to deploy LoadMasters in a cluster and then add new nodes as the capacity requirements (concurrent connections and performance requirements) increase.
With LoadMaster clustering, the load-balancing capability can be extended as needed by adding additional LoadMasters for the same Virtual Service. Traffic which is intended for a failed node is either passed on to an existing node or load-balanced across the remaining nodes.
The LoadMasters all work in parallel. If a LoadMaster node fails, traffic is redistributed amongst the remaining nodes. Health checking is performed on each of the LoadMasters.
Most administrative changes should be made on the shared IP address interface. These changes are then propagated to the LoadMasters in less than a second. Local administration of the individual LoadMasters can also be performed by accessing the WUI of the units directly. The WUI of the local LoadMasters contains limited configuration options.
For further information on clustering, refer to the LoadMaster Clustering, Feature Description.
1. Incoming request intercepted by LoadMaster
2. Routed to Server 1
3. Response from Server 1
4. Response goes directly to Client without LoadMaster
This feature should be implemented only if the Real Servers need to respond to the clients directly, without going through the LoadMaster. In this configuration the Real Servers must have a path to the clients without going through the LoadMaster, for example an additional router in parallel with the LoadMaster.
The only persistence option supported in a DSR configuration is Source IP. No Layer 7/Application features can be used with DSR. Also, DSR may be used only in a 1-arm configuration due to routing issues caused on the Real Server with the loopback interface in a 2-arm solution.
DSR uses a combination of MAT (MAC Address Translation) and a modified Real Server configuration. The RS is configured with an IP address as normal but it is also given the IP address of the VIP. Normally you cannot have two machines on a network with the same IP address. To get around this, the VIP address on a Real Servers must be configured so that the server does not respond to ARP requests on the VIP address.
For further information on how to configure Real Servers (both Linux and Windows) please refer to the Configuring Real Servers for DSR, Technical Note document.
There are several load balancing methods provided by the LoadMaster, which are known as "Scheduling Methods" or âalgorithmsâ. These are described in the sections below.
With this method, incoming requests are distributed sequentially across the server farm (cluster), that is, the available servers.
If this method is selected, all the servers assigned to a Virtual Service should have the similar resource capacity and host identical applications. Choose round robin if all servers have the same or similar performance and are running the same load. Subject to this precondition, the round robin system is a simple and effective method of distribution.
However, if the servers have different capacities, the use of the round robin system can mean that a less powerful server receives the next inquiry even though it has not yet been able to process the current one. This could cause a weaker server to become overloaded.
This method balances out the weakness of the simple round robin: incoming requests are distributed across the cluster in a sequential manner, while taking account of a static âweightingâ that can be pre-assigned per server.
The administrator simply defines the capacities of the servers available by weighting the servers. The most efficient server, A for example, is given the weighting 100, whilst a much less powerful server (B) is weighted at 50. This means that Server A would always receive two consecutive requests before Server B receives its first one, and so on.
Both round robin methods do not take into account that the system does not recognize how many connections are maintained over a given time. It could therefore happen that Server B is overloaded, although it receives fewer connections than Server A, because the users of this server maintain their connections longer. This means that the connections, and thus the load for the server, accumulate.
This potential problem can be avoided with the "least connections" method: requests are distributed on the basis of the connections that every server is currently maintaining. The server in the cluster with the least number of active connections automatically receives the next request. Basically, the same principle applies here as for the simple round robin: the servers related to a Virtual Service should ideally have the similar resource capacities.
Please note that in configurations with low traffic rates, the traffic will not balance out and the first server will be preferred. This is because if all the servers are equal, then the first server is preferred. Until the traffic reaches a level where the first server continually has active traffic, the first server will always be selected.
For both the Least Connection and the Weighted Least Connection scheduling methods, when a Real Server is initially brought online, a period of time can be configured where the number of connections is initially restricted and gradually increased. This provides a âramp-up timeâ for a Real Server to ensure that it is not overloaded by a flood of connections upon startup.
This value is configured in the L7 configuration screen.
If the servers have different resource capacities the âweighted least connectionâ method is more applicable: The number of active connections combined with the various weights defined by the administrator generally provides a very balanced utilization of the servers, as it employs the advantages of both worlds.
This is, in general, a very fair distribution method, as it uses the ratio of the number of connections and the weight of a server. The server in the cluster with the lowest ratio automatically receives the next request.
Please note that the caveat for Least Connections regarding low traffic rates applies here as well.
In addition to the methods above the LoadMaster contains an adaptive logic, which checks the state of the servers at regular intervals and independently of the configured weighting.
For the extremely powerful âagent based adaptive balancingâ method, the LoadMaster periodically checks the system load on all the servers in the farm. Each server machine should provide a file that contains a numeric value in the range between 0 and 99 representing the actual load on this server (0 = idle, 99 = overload, 101 = failed, 102 = administratively disabled). The LoadMaster retrieves this file by an HTTP GET operation. It is the serverâs job to provide the actual load in the ASCII file. There are no prerequisites, though, to how the servers evaluate this information.
Two different strategies are applied, depending on the overall load of the server farm:
During normal operation the scheduling algorithm calculates a weighting ratio out of the collected load values and distributes the connections according to it. So if excessive overloading of a server occurs, the weighting is readjusted transparently by the system. As with the weighted round robin, incorrect distribution can then be countered by assigning different weights to the servers available.
During a period of very low traffic, however, the load values as reported by the servers will not build a representative sample. A load distribution based on these values would result in uncontrolled, oscillating directives. Therefore, in such a situation it is more reasonable, to calculate the load distribution based on the static weight ratio. The LoadMaster switches to the weighted round robin method automatically when the load on all servers falls below a limit defined by the administrator. If the load rises above the limit the LoadMaster switches back to the adaptive method.
For further information regarding Adaptive Balancing, please refer to the API for Agent Based Adaptive Balancing, Technical Note document.
The highest weight Real Server is only used when other Real Server(s) are given lower weight values. However, if the highest weighted server fails, the Real Server with the next highest priority number will be available to serve clients. The weight for each Real Server should be assigned based on the priority among the Real Server(s).
The traffic is scheduled using the weighted round robin method. The weights used by the weighted round robin method are calculated using the response times from health check requests.
Each health check request is timed to see how long it takes to respond. Please note that is assumed that the speed of the health check depends on how slow the machine is which may not always be the case.
The total response times of all the real servers on the Virtual Service are added together, from which the weight of the individual Real Server is calculated.
The weights are recalculated approximately every fifteen seconds.
A hash of the source IP is generated and used to find the correct real server. This means that the Real Server is always the same from the same host.
With this scheduling method, you do not need any source IP persistence.
This may cause real server imbalance.
Persistence â which can also be referred to as âaffinityâ, âserver affinityâ, or âserver stickyâ -- is the property that enables all requests from an individual client to be sent to the same server in a server farm. Persistence is not turned on by default, but it is an option configurable for each Virtual Service.
Without persistence, the LoadMaster will direct traffic according to the load balancing algorithm, such as round-robin, weighted round-robin, etc. (diagram below).
With persistence, the LoadMaster will direct new connections according to the load balancing algorithm, but returning connections will go to the same server (diagram below).
If the site you have is an interactive site, then you will probably need persistence. This is especially true for sites that require some type of login. If the site you are running is static, serving only static text and images, then you may not need persistence. In most cases, persistence cannot hurt even if you do not need it.
The session handling mechanism for many website programming languages (ASP, PHP, and so on) are known as âstatefulâ. There is a unique session established for the user, and that âstateâ is kept on the same server. This stateful information, which can include everything from login credentials to the content of a shopping cart, is typically not shared among servers. So, when using multiple servers it is important to keep an individual user tied to a specific web server for the duration of the interaction, and that is where persistence comes in.
For each persistence method, there is a configurable timeout value that determines how long the persistence for each user is honored, selectable from one minute to seven days.
This timeout clock is started when the initial connection is established. The persistence timeout value is updated if the client reconnects within the timeout period. For example, if the persistence timeout is set to 1 hour and the client starts a connection at 2pm, if the client disconnects and then reconnects before 3pm they will still persist to the same Real Server. Also, the persistence record is updated to reflect this and the persistence countdown timer is reset back to 1 hour for this client.
If a client made connections to the Virtual Service repeatedly within the timeout period, the persistence would be honored indefinitely. For instance, given the following scenario:
Persistence Timeout is set to 10 minutes
A user makes several requests in the course of 20 minutes, but the time between connections is always less than 1 minute
The request should be sent to the correct Real Server, as long as it is available (that is, passing health checks).
If the user goes idle for 20 minutes, then the next connection will be counted as a new session, and may be sent to a different server, depending on scheduling. If the connection is opened for more than 10 minutes and the client disconnects and reconnects, the persistence record would have expired, the LoadMaster will create a new persistence entry for that client and possibly send the client to a new Real Server. This is due to the fact that the persistence countdown starts once a connection is established, not at the closing of the connection.
If you are experiencing persistence issues, this may be due to the fact that the persistence timeout is not long enough. If this is not long enough, then the timeout value should be set for a higher amount. In general, matching this value to your server timeout value is recommended.
These are methods that look beyond the IP address and port and provide a range of options to achieve layer 7 persistence.
The Server Cookie option is a Layer 7 feature that uses existing cookies generated from the server to determine which server to send users to. This method is sometimes referred to as âpassive cookieâ, as the LoadMaster does not generate or manage the cookie, it only observes the cookie in the HTTP stream.
With Server Cookie persistence, you will need to configure the Cookie Name option so the LoadMaster knows which cookie to refer to. For Server Cookie persistence to work best, the cookie generated by the server should have a unique value for each individual user.
When a connection comes into a LoadMaster Virtual Service configured with Active Cookie, the LoadMaster looks for a specific cookie. If that cookie is not there, the LoadMaster inserts it into the HTTP stream with a Set-Cookie directive. Existing cookies are not affected.
A benefit of this method is that no cookies need to be managed or generated by the servers, relieving the burden of server configuration. To gain better dispersion per client connection you can enable the âAdd Port to Active Cookieâ feature in the L7 configuration.
With Active Cookie persistence, the cookie is valid for the session or until the persistence time expires. For example, if using Active Cookie persistence with the persistence timeout set to 10 minutes and the client connects at 2pm, then disconnects and reconnects at 2.05pm â this would reset the persistence timeout value. If the client tries to connect to a Virtual Service after the persistence timeout has expired, they would present the old cookie. The LoadMaster will check its persistence table and see that it does not have a valid entry. The LoadMaster would then generate a new cookie for the client and would update its persistence table.
The Active Cookie or Source IP setting is identical to the Active Cookie Persistence. If, for any reason, the expected cookies are not present, then the source IP address will be used to determine persistence.
All things being equal, if you are going to use Layer 7 persistence, this is the recommended method. It requires no configuration on the servers, the LoadMaster manages all persistence-related cookies, and it falls back onto source IP address in cases where cookies are rejected by the client.
The Hash All Cookies method creates a hash of the values of all cookies in the HTTP stream. Cookies with the same value will be sent to the same server for each request. If the values change, the connection will be treated as a new connection. The client will then be allocated to a server according to the load balancing algorithm.
Hash All Cookies or Source IP is identical to Hash All Cookies, with the additional feature that it will fall back to Source IP persistence in the event that no cookies are in the HTTP string.
Source IP Address persistence uses the source IP address of the incoming request to differentiate between users. This is the simplest method of persistence, and works for all TCP protocols, including those that are not HTTP related.
There are situations where Source IP persistence may be undesirable or even ineffective in properly keeping persistence. These situations include:
When many (or all) users appear to come from a single IP address
When a user switches IP addresses
The first case is often encountered when a significant number of user requests traverse a single proxy, and thus appear to come from a single IP. With Source IP persistence, this would mean that all of those users would appear as a single user.
Another way this might occur is when all of the client requests come over the Internet from a single office. Office routers typically NAT all office systems to one IP address, so again, all users and all requests would appear to be a single user. This can result in uneven load balancing, since new user sessions arriving would all be directed to the same Real Server, without being balanced.
The second case is a largely historical concern, having to do with proxy servers at some of the mega-Internet Service Providers (ISPs), for example AOL and Earthlink. In some cases, proxy configuration or any number of networking issues, might switch IP addresses from time to time. When the IP address changes, the user appears as a different user to SRC persistence.
In each of these cases, Layer 7 persistence would solve the issue, regardless of what IP they came from. However, this only works for the HTTP protocol (and HTTPS/SSL when the session is terminated at the LoadMaster).
Super HTTP persistence functions by creating a unique fingerprint of the client browser and uses that fingerprint to preserve connectivity to the correct Real Server. The fingerprint is based on the combined values of the User-Agent field and, if present, the Authorization header. Connections with the same header combination will be sent back to the same Real Server.
With URL Hash persistence, the LoadMaster will send requests with the same URL to the same server.
With HTTP Host Header persistence, the LoadMaster will send all requests that contain the same value in the HTTP Host: header to the same server.
This method operates that the named item being inspected is a Query Item in the Query String of the URL. All queries with the same Query Item value will be sent to the same server.
With Selected Header persistence, the LoadMaster will send all requests that contain the same value in the specified header to the same server
SSL Session ID is a persistence method that may be used with SSL services even if they are not offloaded. This relies on the client maintaining the same SSL Session ID for a complete user session.
Browser support of this is spotty. As a result, this is not recommended for use with HTTPS services. In order to utilize this persistence method, the Service Type must be set to Generic.
SSL Session ID will only be available as a persistence mode if the Virtual Service has a Service Type of Generic and SSL Acceleration is disabled.
This persistence mode is only available in a UDP Virtual Service when Force L4 is disabled. SIP uses request and response transactions, similar to HTTP. An initial INVITE request is sent, which contains a number of header fields. These header fields can be used for persistence. When this mode is selected in the LoadMaster, a text box called Header field name will appear. The header field that is to be used as the basis for the persistence information should be entered here.
With HTTPS/SSL, there are a few things to consider. If you are not terminating the SSL session at the LoadMaster, then your only options are Source IP Address persistence or SSL Session ID Persistence. Since the stream is encrypted in a non-terminated session, the LoadMaster cannot look at the HTTP headers or other Layer 7 information.
If you are terminating the HTTPS/SSL session at the LoadMaster, then any of the LoadMaster persistence options can be used. Since the HTTPS/SSL session is terminated, the LoadMaster sees all of the unencrypted traffic, and is able to look at the HTTP stream. This is true even when you are terminating the HTTPS/SSL session at the LoadMaster and then re-establishing an SSL session with the Real Servers.
When using âshopping cartâ-like services where a user selects items and adds them to a list, any of the previous types of persistency can be used. When the user then decides to pay for the items, this is normally performed using a secure SSL (https) service. When port following is turned on, the Real Server where the âshopping cartâ connection is active will be selected for the SSL session. This selection will only occur when a connection is still open from the same client (as determined by the source IP address), and if the SSL service has the same IP address as the âshopping cartâ service.
For example, if a connection is made to the HTTP service of www.somewebsite.com, and then a new SSL connection is made to the same address, then the SSL session will be directed to the same Real Server as the original HTTP service.
Port following can be done between UDP and TCP connections if desired.
Application Front End is a group of features that revolve around web application delivery and network optimization. The introduction of the LoadMaster Application Front-End Services (AFE) solves very core requirements by providing better bandwidth and server utilization while allowing LoadMaster to remain a transparent load-balancing appliance that is easy to deploy and manage. LoadMaster AFE Services include:
Each feature can be deployed per web Virtual Service.
The LoadMaster is an established, hardened Internet appliance with HTTP intrusion prevention. In addition to Secure Socket Layer (SSL), Denial of Service support offered by the LoadMaster, the Intrusion Prevention System (IPS) service will provide in-line protection of Real Server(s) by providing real-time mitigation of attacks and isolation of Real Server(s). Intrusion prevention is based on the industry-standard SNORT database and provides real-time intrusion alerting.
The LoadMaster supports SNORT rules version 2.9 and below.
There are two options for handling of requests that match a SNORT rule: Drop Connection or Send Reject. Both options prevent the request from reaching the Real Server(s); this option configures the response returned to the client sending the malicious request.
A rule match will generate no HTTP response. The TCP connection will terminate - no HTML content will be delivered to the client.
Once a rule is matched the response to the client will be set to HTTP 400 âInvalid Requestâ and the corresponding exploit note will be delivered to the client in a HTML document.
Sample Request: http://<VIP>/modules/articles/index.php?cat_id=SQL
Sample Response: <html><head><title>400 Invalid Request</title></head><body>Invalid Request: COMMUNITY WEB-PHP Xoops module Articles SQL Injection Exploit</body>
Low = Only logging with no rejection
Default = Priority 1 (high) rules are block all else is logged
High = Priority 1 (high) and 2 (medium) rules are block all else is logged
Paranoid = All priority levels are blocked and logged
The IPS system will throw out any malicious connections, but there are some requests that are not exactly dangerous, but an indication that something may be wrong. These are not blocked and by default, these are not logged, turning on the WARNING option will allow the logging of these requests.
Examples for non-dangerous operations are requests that are specified as misc-activity in the snort rule file:
which is described as "WEB-MISC HP OpenView Manager DOS" and is only suspicious.
All intrusion alerts are recorded in the system and warning logs. Alert notification can also be obtained by syslog facility, the minimum level is Notice Host, and email alert facility, the minimum level is Notice Recipient. It is recommended that critical system messages like intrusion alerts be recorded by a syslog facility for records retention.
Rules can be downloaded from . Once a new rule set has been obtained or created you can load the rule set by using the WUI and navigating to System Configuration > Miscellaneous Options > AFE Configuration. Using the Choose File button, select the downloaded community-rules file and click Install new Rules. The community-rules files should be encoded in a Tar and Gzip file end with the tar.gz extension and containing a directory named âcommunity-rulesâ, LoadMaster will un-compress this file and reload the new rule files (tar.gz is the standard format for rules download from ). Installing a new rules file will replace the current rules. LoadMaster ships with the Community Rules under General Public License (GPL) by default.
The LoadMaster advanced caching engine saves valuable Real Server processing power and bandwidth, which can be dedicated to performing critical core business application logic. Significant server performance gains can be achieved when implementing caching. Chatty protocols, such as HTTP, require frequent creating and closing of connections for fetching of static resources, creating unnecessary resource utilization on Real Server(s) and the network.
By enabling LoadMaster caching you can re-purpose connection-related resources for more relevant business logic. By deploying LoadMaster caching, your organization can also greatly reduce web traffic to the Real Server(s), saving on bandwidth in-front of your Real Server(s).
HTTP/HTTPS requests with no-cache headers will bypass the cache, following RFC 2616. Cache is filled in a delayed manner - please allow a few seconds for static content to be cached.
In accordance with RFC 2616, URLs which contain query strings (those containing a question mark symbol (?) in the rel_path part) will not be cached.
LoadMaster will not monitor file changes on the Real Server and auto-reload the cache maintained within the Virtual Service. You can force reload the cache by deselecting and selecting the Enable Caching checkbox. You can also reload a cached object, sending a non-cache request. Most browsers support this by holding the left Shift key and clicking reload (or pressing F5).
The amount of global memory available for caching can be configured; values have a linear relation to actual memory. To configure this, navigate to Virtual Services > View/Modify Services > Modify > Advanced Properties in the LoadMaster WUI.
Data compression allows the LoadMaster to compress the application payload per request, reducing network bandwidth consumption without degrading content quality and response time resulting in an improvement for the end-users' overall experience. Data compression is supported on all files. Compression ratios vary by file type.
Compression is not recommended for files 100Mb or greater in size.
The compression feature should be deployed simultaneously with the caching feature to reduce the real-time inline compression requirements. Using only compression can potentially bottleneck the Virtual Service throughput depending on the hardware platform.
Compression depends on clients having gzip support. You can verify that a compressed connection to the Virtual Service exists by tracing the client HTTP traffic. If you can locate the Content-encoding:gzip header from the LoadMaster your client communication to the LoadMaster is compressed.
The LoadMaster Supports SSL 3.0, TLS 1.0 and TLS 1.2.
- The LoadMaster offloads the SSL workload off the Real Servers
- The LoadMaster performs Layer 7 processing: persistence or content switching
Without terminating the SSL session at the LoadMaster, the headers and content cannot be read so persistence cannot be done. The only consistently reliable persistence method available when the SSL session is not terminated at the LoadMaster, is Source IP.
With SSL acceleration, the LoadMaster uses a specialized processor to perform the SSL functions. With this SSL acceleration hardware, the LoadMaster handles SSL connections as easily as it handles non-SSL connections.
LoadMaster-FIPS supports hardware-based SSL acceleration and offloading. With hardware SSL, the LoadMaster has a separate specialized processor which handles all SSL functions. No matter what level of SSL connections, the LoadMaster's general processor is not burdened. This specialized hardware is purpose-built for SSL, and can handle extremely high connection rates (TPS) of SSL traffic.
For more information on SSL, refer to the SSL Accelerated Services, Feature Description.
The Kemp Edge Security Pack (ESP) pack delivers a solution using the Kemp LoadMaster line of load balancers to customers who would have previously deployed Microsoftâs Threat Management Gateway (TMG) to publish their Microsoft applications.
The Kemp ESP offers the following key features:
End point authentication for pre-auth
Persistent logging and reporting for user logging
Single Sign On (SSO) across Virtual Services
LDAP authentication from the LoadMaster to the Active Directory
Basic and form-based authentication communication from a client to the LoadMaster
RSA SecurID two-factor authentication
Kerberos Constrained Delegation (KCD) authentication
Client certificate authentication
Clients who are trying to access Virtual Services on the LoadMaster will have to provide authentication information which will be used by the ESP to validate the clientsâ right to access the service. In the event of success, the client is enabled to access the service. In the event of failure, the client will be blocked until valid credentials are provided.
When clients try to access a service this will be logged on the LoadMaster as part of the ESP. This allows monitoring by the administrator.
The LoadMaster is designed to handle multiple virtual services supporting unique workloads. These Virtual Services can be joined together by associating them with the same Single Sign-On (SSO) Domain.
The Virtual Services need to be on the same domain for this to work, for example ecp.example.com and www.example.com.
SSO in ESP will enable clients to only enter the authentication information when accessing the first Virtual Service and then this same information will be used to access other services associated with the Single Sign-On Domain. Therefore, a client accessing Exchange will also be able to access SharePoint and other workloads if they are associated with the same Single Sign-On Domain.
Active Directory is the standard Authentication Provider for Microsoft workloads. LoadMaster supports the key connection types between the LoadMaster and Active Directory.
LoadMaster with ESP currently supports basic and form-based authentication between the client and the LoadMaster, providing clients with an optimum authentication experience. In future releases, there are plans to also support NTLM.
Large and small businesses are deploying large numbers of internet-facing applications to support ever expanding business requirements. This rapidly growing number of servers needs to be scalable and highly reliable. Above all, the access to these servers and services needs to be secure. With the addition of the ESP, the LoadMaster will continue to deliver on customer security requirements for internet-facing applications in a world without TMG, while continuing to address requirements for feature-rich and cost-effective scalability and high reliability.
As part of the Kemp Edge Security Pack (ESP), the LoadMaster supports the RSA SecurID authentication scheme. This scheme authenticates the user on an RSA SecurID Server. When RSA is enabled as the authentication method, during the login process the user is prompted to enter a password that is a combination of two numbers â a Personal Identification Number (PIN) and a token code which is the number displayed on the RSA SecurID authenticator (dongle).
There are two additional challenge-response modes: next token and new PIN.
For more information, refer to the RSA Two Factor Authentication, Feature Description.
When using KCD as the authentication protocol, the LoadMaster provides seamless access to protected resources in a Kerberos realm even when credentials provided are not directly valid for such an environment.
The KCD authentication protocol is used to confirm the identity of the users that are attempting to access resources on a network. KCD authentication uses tickets that are encrypted and decrypted by secret keys and do not contain user passwords. These tickets are requested and delivered in Kerberos messages. When the userâs password is not provided, a trusted administrator user account is used to get tickets on behalf of services and users.
For more information refer to the Kerberos Constrained Delegation (KCD), Feature Description.
Using certificates for authentication can be considered more secure because a user cannot gain access to something simply by knowing the username and password. Using certificates prevents key loggers or other malware on a client machine from capturing keystrokes to identify user accounts and passwords.
The LoadMaster supports the use of certificates with KCD authentication. For more information refer to the Kerberos Constrained Delegation (KCD), Feature Description.
Some authentication mechanisms assume a dual-factor approach where both the Active Directory and a secondary mechanism are used in sequence. For these, the form includes the username, password and also a passcode which is checked after the username and password.
Web Application Firewall (WAF) services are natively integrated in the Kemp LoadMaster. This enables secure deployment of web applications, preventing Layer 7 attacks while maintaining core load balancing services which ensures superior application delivery performance, high availability and scalability. The WAF directly augments the LoadMasterâs existing security features to create a layered defence for web apps, and therefore enables a safe, compliant and productive use of web application resources.
Some of the challenges faced when using a traditional firewall are listed in the section below. Some of the benefits of Kemp WAF are listed in the Challenges with Traditional Firewalls section.
There are many limitations of traditional firewalls, such as the fact that they:
Typically operate below Layer 4
Have limited support for protocol inspection (that is, packet filtering)
Are only aware of âports and socketsâ
Modern-day hacker attacks present many security challenges due to the fact that they are:
Becoming increasingly complex
Frequently changing their attack vectors
Focusing on application vulnerabilities
Harder to detect and block on a firewall
As depicted in the diagram above, Kemp WAF offers many benefits, such as the fact that it:
Processes web-based traffic, that is, HTTP/HTTPS
Is able to detect modern application attack vectors
Is deployed between perimeter defences and the application servers
Works in conjunction with existing security technologies to provide complete application attack prevention
Kempâs integrated L7 WAF platform is based on an industry-leading rules engine that provides real-time coverage for all published application threats, including the Open Web Application Security Project (OWASP) Top Ten, as well as critical baseline protections. It also allows you to use your existing rules in a centralized Kemp Application Delivery Controller (ADC) appliance.
With the WAF-ADC integration, Kemp enhances its existing security features available on LoadMaster platforms, which currently feature edge security gateway functionality to protect published workloads including reverse proxy, Single Sign On (SSO), pre-authentication and SMTP domain filtering, dual-factor authentication, Intrusion Prevention System (IPS) and SSL bridging for secured traffic flows. Kempâs commercial rules also includes attack categories such as IP reputation, botnet attack detection, web-based malware detection, webshell/backdoor detection, HTTP Denial of Service (DoS) attack detection and anti-virus scanning of file attachments.
The LoadMaster includes WAF features and security services. This gives network administrators the ability to:
Secure applications with minimum network impact and maximum protection
Simplify infrastructure with this integrated solution
Centralize required Application Delivery Controller (ADC) and WAF SSL overlay services into one product
As depicted in the diagram above, the Kemp WAF provides a number of useful features such as:
Fully-featured load balancing and content switching
Intrusion Prevention System (IPS) and content filtering
Protection against the Open Web Application Security Projectâs (OWASP) top ten vulnerabilities
Support for standard and custom applications
Active (block and log) mode operation support
Passive (log only) mode operation support
SQL injection protection
Cross-site scripting mitigation
Cross-Site Request Forgery (CSRF) prevention
Cookie or form tampering prevention
Distributed Denial of Service (DDOS) mitigation
IP reputation checking
Daily rules updates
Data leakage protection
Built in reporting
Built in logging including log field masking (that is, credit card numbers)
For further information, including steps on how to configure WAF, refer to the Web Application Firewall (WAF), Feature Description.
GEO assures seamless failover and failback to the best performing and geographically closest datacenter for optimal use of web-based applications, including Microsoft Exchange. In the event of a service disruption, traffic is automatically controlled based on a set policy in order to minimize impact and the need for manual intervention.
The GEO product is available in two forms:
A standalone GEO product
A Global Sever Load Balancing (GSLB) Feature Pack that is part of the Kemp LoadMaster product
GEO offers many load balancing algorithms including round robin, weighted round robin, fixed weighting, real server load, location based and proximity. âRound Robinâ load balancing can be used for all active data centers, which includes support for weights and a chained failover option for disaster recovery. Location Based load balancing allows GEO to direct a client to a data center based on the client's country or continent, as defined by the created policies. Proximity takes Location Based one step further and allows for longitude and latitude granularity for definition of proximity. GEO securely and seamlessly integrates with LoadMaster to offer âReal Server Loadâ load balancing, in which GEO uses local data center metrics provided by LoadMaster, allowing clients to connect to the least busy data center.
GEO can be deployed in a distributed (Active/Active) high availability configuration, with multiple appliances securely synchronizing information. Introducing GEO in your existing Authoritative Domain Name Services (DNS) requires minimal integration work and risk, allowing you to fully leverage your existing DNS investment.
For further information on GEO, please refer to the GEO, Feature Description on the Kemp Documentation Page.
The National Institute of Standards and Technology (NIST) issued the Federal Information Processing Standard (FIPS) Publication 140-2 to coordinate the requirements and standards for cryptography modules that include both hardware and software components. Federal agencies and departments can validate that the module in use is covered by an existing FIPS 140-2 certificate that specifies the exact module name, hardware, software, firmware, and/or applet version numbers. The cryptographic modules are produced by the private sector or open source communities for use by the U.S. government and other regulated industries (such as financial and health-care institutions) that collect, store, transfer, share and disseminate sensitive but unclassified (SBU) information. A commercial cryptographic module is also commonly referred to as a Hardware Security Module (HSM).
FIPS 140-2 defines four levels of security, âLevel 1â to âLevel 4â. This document describes the compliance of the Kemp LoadMaster products with Level 1 and Level 2 of the FIPS 140-2 standard.
The FIPS LoadMaster is compliant with FIPS 140-2 Level 2.
Security Level 2 improves upon the levels of security provided for in Level 1. The cryptographic module must protect against unauthorized physical access and include the use of tamper-evident coatings or seals which must be broken to attain physical access to the module. Role-based authentication is also required.
The cryptographic module, or Hardware Security Module (HSM), included in the FIPS products are as follows:
1x Cavium CN1620-NFBE3-3.0-FW2.2-G (LM-8020-FIPS product)
1x Cavium FIPS CN1610-NFBE1-3.0-FW2.1-G (LM-5305-FIPS product)
These are produced by Cavium Networks. These HSMs are fully compliant with FIPS 140-2 Level 2 requirements as certified by the National Institute of Standards and Technology (NIST), certificate number 1369. The HSM has a secure, tamper-proof barrier and all critical security parameters (CSPs), for example certificate keys, are encompassed within the cryptographic boundary. All keys are cleared if the module is breached.
The FIPS processor can be damaged if it is allowed to overheat. To prevent this, the temperature of the card is monitored and the following remedial action is taken if the temperature rises too high.
If the temperature is above or equal to 60C, but below 70C, a warning is sent to the syslog.
If the temperature is above or equal to 70C in two consecutive checks, a critical error is sent to the syslog and then the LoadMaster shuts down.
If the temperature is above 70C but the next check is below 70C, a warning is sent to the syslog but the LoadMaster is not shut down.
When the temperature goes below 60C, the syslog warning messages cease.
From within a Virtual Service you can create one or more âSub-Virtual Servicesâ (SubVSs). A SubVS is linked to, and uses the IP address of, the âparentâ Virtual Service. The SubVSs may have different settings (such as health check methods, content rules etc.) to the parent Virtual Service and to each other. This allows the grouping of related Virtual Services, all using the same IP address. This could be useful when there are complex configurations such as Exchange or Lync which typically are comprised of a number of Virtual Services.
There are many advantages to using SubVSs, such as:
SubVSs are linked to, and use the IP address of, the âparentâ Virtual Service
Using SubVSs reduces the number of IP addresses required by applications such as Lync or Exchange
SubVSs do not require non-transparency
SubVSs may have different settings (such as content rules) to the parent Virtual Service and to each other
Using a SubVS provides the ability to have content switching and persistency on the same Virtual Service
Using a SubVS gives the ability to perform multiple health checks on the same Virtual Service
SubVSs work well with ESP, but ESP is not required
Self-signed certificates generated by the LoadMaster itself
Generally, self-signed certificates should not be used for public-facing production websites.
They may be acceptable for use in some other scenarios, such as:
QA sites, where web sites are tested but not presented to the general public
Both self-signed and CA signed certificates provide encryption for data in motion. A CA-signed certificate also provides authentication - a level of assurance that the site is what it reports to be, and not an impostor website.
The primary operational difference between a self-signed certificate and a CA certificate is that with self-signed, a browser will generally give some type of error, warning that the certificate is not issued by a CA. An example of the self-signed certificate error is shown in Figure 1.
This is the same warning message you receive when connecting to the LoadMaster WUI, as the WUI uses a self-signed certificate. Generally, this warning should occur only once per browsing session.
The LoadMaster series of load balancers support content switching, which is sometimes referred to a URL switching. This allows the LoadMaster to direct specific requests to specific Real Servers based on the contents of the requested URL.
For example, if you have two groups of servers; one group to serve images and the other to serve all other content - you can create content rules to separate these two classes of request (Fig. 1).
Any URL that includes /images in it, such as âhttp://url.com/images/party.jpgâ or âhttp://url.com/images/dogs.jpgâ would be directed to server 3 and 4, while anything else would be directed to server 1 and 2.
This can be very useful if you have servers that perform different functions (application servers, static content servers, mapping servers, specialized content generation servers, etc.) that must all be served from the same general hostname (for example, www.websitename.com).
The term content switching does not refer to the process involved with Layer 2 switching. Instead, content switching refers to switching traffic between different servers, depending upon the content requested.
There are two parts to configuring content switching: the content rules, and the Virtual Service configuration. The content rules are configured globally on the LoadMaster and various rules are applied to specific Real Servers operating under a Virtual Service.
The LoadMaster utilizes health checks to monitor the availability of the Real Servers and the Virtual Services. If one of the servers does not respond to a health check within a defined time interval for a defined number of times, the weighting of this server will be reduced to zero. This zero weighting has the effect of removing the Real Server from the Virtual Service configuration until it can be determined that this Real Server is back online. The LoadMaster uses health checks that can be specified in the WUI. By default, the highest possible health check is associated with a Virtual Service. The LoadMaster performs Layer 7 health checks for the following ports:
When creating a Virtual Service and using a service type other than Generic, additional health checking protocols are available. For example, the service type Remote Terminal will permit checking with Remote Terminal Protocol.
The Remote Terminal Protocol supports Network Level Authentication.
For other ports the LoadMaster uses Layer 4 health checks for TCP services and Layer 3 health checks for UDP services. The settings for the health checks can be changed from the default settings using the Virtual Service wizard to accommodate non-standard settings. For example, one could run an http service on port 8080 instead of 80, and change the health check to HTTP instead of the default Layer 4 check.
These global settings hold for all servers in the farm, that is, you cannot assign different timeouts for different servers.
It is mandatory that one of the service checking options be used when defining a Virtual Service on the LoadMaster.
Layer 3 health checks utilize ICMP based echo requests (pings) to test whether a Real Server can be reached over the network. A Layer 3 check is not Virtual Service specific, for example, when it fails, the corresponding Real Server will be removed from all Virtual Services that use it.
In contrast to the Layer 3 health checks, service based health checking for both the Layer 4 and Layer 7 health checks are Virtual Service based. When a Real Server fails such a check, it will be removed only from the corresponding Virtual Service â all other Virtual Services that use this Real Server are unaffected.
The current version is SNMPv3. The two previous revisions in use are SNMPv1 and SNMPv2c (community-based SNMPv2).
The SNMP support of the LoadMaster is based on SNMPv3, and is backwards-compatible such that all three of the above versions can be used. However, since SNMPv1 does not support 64bit-values (as used in the LoadMaster Management Information Base (MIB)), it is recommended to use SNMPv2c or SNMPv3. MsgSecurity is supported only with SNMP v1 and v2c.
The information regarding all LoadMaster-specific data objects is stored in the enterprise-specific MIBs listed below.
Virtual Server stats
LoadMaster configuration data
|CERTS-MIB.txt||SSL certificate information|
SNMP is supported on both IPv4 and IPv6 Virtual Services at both Layer 4 and Layer 7.
The SNMP support is disabled by default.
You can retrieve SSL certificate information including the file name, certificate Subject Name, certificate serial number, certificate start date, certificate end date, and certificate issuer information using SNMP. SNMP can display this information for up to 256 SSL certificates.
You can also retrieve disk space usage details using SNMP. The /var/log and /var/log/userlog partition information is available.
The LoadMaster provides the ability to perform online software updates and upgrades. Patches will be made available by Kemp. These patches should be installed on a machine which supports an FTP, HTTP or SSH daemon.
Patches are checksummed (with MD5) and encrypted to protect against data corruption or tampering.
Patches can be installed using one of two methods:
Using the Console Line Interface (CLI)
Using the WUI
Using the CLI
Using the Configuration menu, select the Utilities > Software Upgrade menu option.
When the patch has been downloaded, the patch will be unpacked and checked.
If the patch is valid, the patch version will be displayed and the user will be asked if the patch should be installed.
Upon the successful installation of the patch, the LoadMaster should be rebooted to activate the new version.
Using the WUI
To upgrade the software using the WUI, follow the steps below:
1. In the main menu of the LoadMaster WUI, select System Configuration > System Administration > Update Software.
2. Click the Browseâ¦ button and browse to and select the the patch.
3. Click the Update Machine button.
Upon successful installation of the patch, the LoadMaster should be rebooted to activate the new version.
If the patch does not install correctly, the previous version of the software may be reactivated using the configuration menu or WUI.
License information can be entered in the WUI as described in the Licensing, Feature Description document.
After updating a license key, a reboot should be performed to enable the new functionality.
Patch support can expire; if this happens you will be notified during the upgrade procedure.
If you receive the message âUpdate not permittedâ please contact Kemp for re-licensing.
The LoadMaster supports multiple user logins with varying levels of access that can be managed by navigating to System Configuration > System Administration > User Management. Each username must be a minimum of three characters and a maximum of fourteen. Passwords must be a minimum of six characters long. Users created here can only access the WUI, remote access using SSH is not supported.
The LoadMaster can be configured to utilize client certificates in the authentication process.
For further information on User Management in general, and client certificate WUI authentication, refer to the User Management, Feature Description.
The factory default username is bal and the default password is 1fourall. The factory default user retains the highest level of access. All users created have a subset of the access permitted by the default account. Changing roles for users takes effect in real-time. Roles can be combined and are mutually exclusive.
This role permits enabling and disabling Real Servers.
Users with the Real Servers permission cannot add SubVSs.
This role permits managing Rules. Rule modifications permitted include add, delete and modify.
This role permits performing system backups.
This role permits the ability to export and import certificates.
This role is allowed access to all functionality within the System Configuration > System Administration > User Management screen.
This role gives users all permissions except the permission to change the bal password and the permission to create or delete other users.
This role is used only with the LoadMaster GEO product. For more information on GEO and the Global Server Load Balancing (GSLB) Feature Pack, refer to the GEO, Feature Description on the Kemp Documentation Page.
The WUI Authentication and Authorization screen enables the administration of the available authentication (login) and authorization (allowed permissions) options.
Users must be authenticated before logging on to the LoadMaster. The LoadMaster allows authentication of users to be performed using the LDAP authentication method as well as Local User authentication.
When all authentication methods are selected, the LoadMaster attempts to authenticate users using the authentication methods in the following order:
2. Local Users
If the LDAP server is also not available, then Local User authentication methods are used.
If the LDAP authentication method is not selected, then the Local User authentication method is selected by default.
LoadMaster allows the users to be authorized using Local User authorization. The userâs authorization decides what level of permissions the user has and what functions on the LoadMaster they are allowed to perform.
Authorization using LDAP is not supported.
LoadMaster bonding/VLAN tagging can be easily set up and configured using the WUI. Successful deployment requires that the pre-requisites have been satisfied. This guide is designed to introduce interface bonding and VLAN configuration on the LoadMaster. Bonding support is available with all network modules.
A list of prerequisites are below:
IEEE 802.1AX/IEEE 802.3ad/LACP
Enabling the Active-Backup mode generally does not require switch intervention and can be configured directly on the LoadMaster. Using the 802.3ad bonding mode will require configuring a link aggregation group on the switch in conjunction with the LoadMaster. Please read the switch documentation to establish the corresponding team/bond, common terms for link aggregation, which include; "Ethernet trunk", "NIC teaming", "port channel", "port teaming", "port trunking", "link bundling", "EtherChannel", "Multi-Link Trunking (MLT)", "NIC bonding", "Network Fault Tolerance (NFT)" and âLAGâ.
When enabling VLAN trunking on the switch port make sure to configure the port to support the appropriate mode; General, Access, or Trunking. General descriptions are as follows (check the switch documentation for specifics):
General: the port belongs to VLANs, and each VLAN is user-defined as tagged or untagged (full 802.1Q mode)
Access: the port belongs to a single untagged VLAN
Trunk: the port belongs to VLANs in which all ports are tagged
There are a few key things to keep in mind when creating bonds/teams:
You can only bond interfaces higher than the parent, so if you choose to start with port 10 then you can only add ports 11 and greater
In order to add a link to a bonded interface, any IP addressing must first be removed from the link to be added
Bonding eth0 with eth1 can lead to serious issues and is not allowed to occur
Ensure that all bonded interfaces are configured for the same link speed, both on the switch and LoadMaster.
If bonding port 0, Kemp recommends you move the web administrative interface and/or the remote SSH access to a different port temporarily until the bonding has been completely configured and is working.
Things to keep in mind:
VLANs can be added to physical interfaces or bonded interfaces
Internet Protocol Security (IPsec) is designed and used to provide secure connections between nodes and networks throughout the internet. IPsec has become the standard for most of the IP Virtual Private Network (VPN) technology.
IPsec can operate in a point-to-point (aka host-to-host) configuration or in a site-to-site (aka network-to-network) configuration. An IPsec implementation operates in a host, as a Security Gateway (SG), or as an independent device, affording protection to IP traffic for both IPv4 and IPv6. (A security gateway is an intermediate system implementing IPsec, for example a firewall, router or gateway which has been IPsec-enabled.)
There are many benefits of using IPsec. These include, but are not limited to:
Secure connectivity provided across distributed enterprises
Bandwidth benefits over traditionally expensive Wide Area Network (WAN) infrastructure
Cost benefits over traditionally expensive WAN infrastructure
Security - IPsec VPNs inherently provide a high degree of data security
Flexibility - IPsec VPNs can be established and be available using the internet
Resilience and High Availability (HA) for critical and sensitive applications available over the internet
For further information, including step-by-step instructions on how to configure the LoadMaster to work with IPsec tunneling, refer to the IPsec Tunneling, Feature Description.
This version of LoadMaster software includes IPv6 support at both Layer 4 and Layer 7. Before you lay out your network addresses, consider which will remain as IPv4 and which will convert to IPv6. The LoadMaster is capable of supporting, and is able to translate between IPv4 and IPv6, unlike networks. Therefore, you may have an internal network that is IPv6, and interconnect to an external IPv4 network.
FTP for IPv6 at Layer 4 is not supported.
The LoadMaster can produce various warning and error messages using the syslog protocol. These messages are normally stored locally.
It is also possible to configure the LoadMaster to transmit these error messages to a remote syslog server by entering the relevant IP address in the Syslog host text box, selecting the severity and clicking Add Syslog Host. Six different error message levels are defined. Each level of message may be sent to a different host server.
Notice messages are sent for information only. Emergency messages normally require immediate user action.
To enable a syslog process on a remote Linux server to receive syslog messages from the LoadMaster, the syslog must be started with the â-râ flag.
To unlock the LoadMaster software, you need a license. The license will be generated individually for each LoadMaster instance in conjunction with an Access Code.
There are three different licenses that you can get for a LoadMaster:
A trial license - this is a fully functional license which is valid for up to 30 days
A full, non-time-limited LoadMaster license
License information can be updated in the Web User Interface at System Configuration > System Administration > Update License. Repeat the process for a second LoadMaster if using HA systems. Kemp recommends rebooting after updating the license.
You need a Kemp ID to license a Virtual LoadMaster for the first time. If you do not have a Kemp ID, refer to the Licensing, Feature Description, for instructions on how to set one up. When you have a Kemp ID, you can license the Virtual LoadMaster using the WUI options provided.
If you need to upgrade a license, contact Kemp.
You can backup and restore the LoadMaster configuration settings as needed. You can take manual backups, but you can also save backups to a remote server. The complete configuration (the Virtual Service, GEO, ESP and base configuration) of the LoadMaster is saved to a single file on the server along with statistical data.
No SSL certificate information is contained within a backup.
The server must be running an FTP daemon or an SSH daemon. By default the remote protocol is FTP but that can be changed to SCP.
When restoring a configuration, you specify what parts of the configuration should be restored:
The Virtual Service configuration only
The LoadMaster base configuration only
The GEO configuration only
The ESP SSO configuration only
A combination of the Virtual Service, GEO, ESP and/or LoadMaster base configuration
The base configuration contains the information about the basic configuration of the LoadMaster, that is, the IP addresses of the various interfaces and the keyboard and time zone settings.
The Virtual Service configuration contains only the settings relating to the Virtual Services and the Real Servers.
The GEO configuration contains only the settings relating to the GEO configuration.
The ESP SSO configuration stores the SSO domains, LDAP endpoints and SSO custom image sets. This does not restore the Virtual Service settings - use the VS Configuration option to restore those.
When performing a restore on the standby machine of a High Availability (HA) cluster only the base configuration can be restored. The Virtual Service configuration is taken from the active machine.
You can configure automated backups on a daily or weekly basis.
In certain circumstances users may wish to disable access to the LoadMaster WUI. This can be done by going to Certificates & Security > Remote Access in the LoadMaster WUI and deselecting the Allow Web Administrative Access check box.
If the access is disabled, no users will be able to use the LoadMaster WUI. This may be required in certain circumstances for security or other reasons.
When a service is switched from one persistency method to another, the absolute values of all Virtual Service and Real Server counters will be reset to zero.
This may cause peaks in the service graphs when displaying relative values (bytes per second, etc.) when, for example, the bytes counter jumps from terabyte values to zero.
Log files are viewable in the WUI at System Configuration > Logging Options > System Log Files:
Boot.msg File contains Linux standard boot information
Warning Message File contains a list of events generated by the core load-balancing engine
System Message File contains a list of events generated by the core load balancing and the underling Linux operation system
Log files are volatile. To ensure that critical log information is available in the event of a recycle on the LoadMaster, please use the syslog facility.
Debugging utilities can be executed in the WUI at System Configuration > Logging Options > System Log Files > Debug Options. These are best utilized when working with the Kemp Support Team.
Enable additional debugging information that is captured in the System Messages log.
Reports the Process Status (PS).
LoadMaster provides an interface designed to allow remote applications access in a simple and consistent manner. The interface is a REST-like interface. REST (REpresentational State Transfer) is a style of software architecture for distributed systems and is one of the predominant web service design models.
The LoadMaster RESTful API works by allowing a user or application to pass HTTP requests to the LoadMaster. The LoadMaster answers the request with an XML-formatted response.
The interface is disabled by default. For more information on enabling the interface, please refer to Web User Interface (WUI), Configuration Guide.
For further details on the RESTful API, please refer to the RESTful API, Interface Description document which can be found on the Kemp documentation page.
Oracle Virtual Box, Installation Guide
VMWare Workstation and Player, Installation Guide
XEN (Para Virtualized), Installation Guide
Cisco UCS B-Series Blade Server, Installation Guide
KVM (Para-Virtualized), Installation Guide
Hyper-V, Installation Guide
VMWare ESX, ESXi and vSphere, Installation Guide
RADIUS Authentication and Authorization, Technical Note
SDN Adaptive Load Balancing, Feature Description
This document was last updated on 30 January 2019.