HA for AWS

 

1Introduction

The KEMP LoadMaster system can be deployed as a single unit or in an active/standby dual-unit configuration (HA). HA allows two physical or virtual machines to become one logical device. Only one of these units is active and handling traffic at any one time. One unit is active and the other is a hot standby (passive). This provides redundancy and resiliency, meaning if one LoadMaster goes down for any reason, the hot standby can become active, therefore avoiding any downtime.

AWS Elastic Load Balancing is used to achieve HA in AWS when using KEMP LoadMasters.

Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances in the cloud. Elastic Load Balancing ensures that only healthy Amazon EC2 instances receive traffic by detecting unhealthy instances and re-routing traffic across the remaining healthy instances.

1.1Document Purpose

The purpose of this document is to provide information and step-by-step instructions on how to configure HA when using the KEMP LoadMaster in AWS.

1.2Intended Audience

This document is intended to be read by anyone who is interested in finding out how to configure HA when using the KEMP LoadMaster in an AWS environment.

1.3Prerequisites

This document assumes that you already have two LoadMaster HA instances which are configured and accessible using the User Interface (UI). One should be designated as a master and the other as a slave.

For step-by-step instructions on how to deploy a LoadMaster in AWS, please refer to the LoadMaster for AWS, Feature Description document.

2AWS Elastic Load Balancing Service Architecture

Figure 2‑1: AWS Elastic Load Balancing Service Architecture

There are two logical components in the Elastic Load Balancing service architecture:

  • Load balancers
  • A controller service

The load balancers are resources that monitor traffic and handle requests that come in through the Internet, that is, the KEMP LoadMaster.

The controller service monitors the load balancers and verifies that load balancers are behaving properly.

Once you create an elastic load balancer, you must configure it to accept incoming traffic and route requests to your EC2 instances. These configuration parameters are stored by the controller, and the controller ensures that all of the load balancers are operating with the correct configuration.

Elastic Load Balancing will perform health checks on back-end instances, using the configuration that you supply.

To discover the availability of your EC2 instances, the load balancer periodically sends pings, attempts connections, or sends requests to test the EC2 instances. These tests are called health checks. Instances that are healthy at the time of the health check are marked as InService and the instances that are unhealthy at the time of the health check are marked as OutOfService. The load balancer performs health checks on all registered instances, whether the instance is in a healthy state or an unhealthy state. When using AWS VLMs in HA mode – one unit is active and in service, the other is stand-by and out-of-service.

Figure 2‑2: HA failover

The load balancer routes traffic only to the healthy instances. When the load balancer determines that an instance is unhealthy, it stops routing traffic to that instance. The load balancer resumes routing traffic to the instance when it has been restored to a healthy state.

The load balancer checks the health of the registered instances using either the default health check configuration provided by Elastic Load Balancing or a health check configuration that you configure.

The health checks must reach the defined target set in the Elastic Load Balancing configuration for the number of successful checks before the instance is considered to be “in service” and healthy. For example, for any instance registered with Elastic Load Balancing - if you set the interval for health checks to 20 seconds, and you set the number of successful health checks to 10, then it will take at least 200 seconds before Elastic Load Balancing will route traffic to the instance.

The health check also defines a failure threshold. For example, if you set the interval to 20 seconds and you set the failure threshold at 4, then when an instance no longer responds to requests - at least 80 seconds will elapse before it is taken out of service. However, if an instance is terminated, traffic will no longer be sent to the terminated instance, but there can be a delay before the load balancer is aware that the instance was terminated. For this reason, it is important to de-register your instances before terminating them; instances are removed from service in a much shorter amount of time if they are de-registered.

3Using LoadMaster HA for AWS

When using LoadMaster in High Availability on AWS, HA operates in much the same way as it does on non-cloud platforms, but with some key differences due to how HA interacts with the AWS Elastic IP feature:

  • LoadMaster HA for AWS involves two LoadMasters that synchronize settings bi-directionally. Changes made to the master are replicated to the slave and changes made to the slave are replicated to the master.
  • When synchronizing the GEO settings from master to slave, any Fully Qualified Domain Name (FQDN) or cluster IP addresses that match the master’s IP address are replaced with the slave’s IP address. Likewise, when synchronizing from slave to master, the slave’s IP address is replaced with the master’s IP address.
  • All user-defined settings are synchronized, with the exception of the following:

Default gateway (both IPv4 and IPv6)

IP addresses and netmasks

Hostname

Name server

Domain

Admin default gateway

Administrative certificate settings

Network interface settings: Link Status (Speed and Duplex), MTU and additional addresses

Virtual LAN (VLAN) configuration

Virtual Extensible LAN (VXLAN) configuration

Interface bonding

Additional routes

  • The cloud HA LoadMaster does not have a “force update” option.
  • Both devices are capable of responding to Elastic Load Balancer health check requests.

The LoadMaster that is currently handling client traffic will respond with the status code 200 OK to the AWS health check - meaning that it is healthy. Meanwhile, the standby LoadMaster will respond with the status code 503 -- meaning that it is unhealthy. In this way, all client requests are redirected by the Elastic Load Balancer to the healthy LoadMaster.

The “slave” LoadMaster (the LoadMaster which is not handling traffic) will probe the “master” LoadMaster to check the availability of the service. If the probe is successful, it will remain in “slave” mode, otherwise it will take over as the “master” - answering 200 OK to the AWS health check becoming capable to handle traffic.

If the master unit fails, connections are directed to the slave unit. The master unit never assumes the slave role. When the master unit becomes available again after a failure, connections are automatically directed to the master unit again.

In order for HA to work, the two LoadMasters must have different values set for the AWS HA Mode.

A complete description of non-cloud LoadMaster HA can be found in the High Availability (HA), Feature Description document.

4Creating AWS HA Pairs

This document assumes that you already have two LoadMaster HA instances which are configured and accessible using the User Interface (UI). One should be designated as a master and the other as a slave.

For further information and steps on how to deploy an individual LoadMaster instance, refer to the LoadMaster for AWS, Feature Description document.

4.1Create the Elastic Load Balancer in AWS

To create AWS HA pairs, carry out the following steps:

  1. Open the Amazon EC2 console.
  2. Navigate to Load Balancing > Load Balancers.

Figure 4‑1: Create Load Balancer

  1. Click Create Load Balancer.

Figure 4‑2: Configure the Load Balancer

  1. Set the name and Virtual Private Cloud (VPC).
  2. Add listeners as necessary. Typically HTTP and HTTPS are used.

Other listeners can be added as required.

  1. Add selected subnets, as needed.

Figure 4‑3: Assign a Security Group

  1. Assign a security group which allows load-balanced traffic.

Figure 4‑4: Configure Security Settings

  1. Select an SSL certificate, if needed.
  2. Select the desired ciphers and protocols.

Figure 4‑5: Configure Health Check

  1. Select HTTP as the Ping Protocol for the health check.
  2. Set the Ping Port to 8444.

The port can be changed as needed.

KEMP Technologies strongly recommend not lowering the timeout and interval values. If the settings are lower, it may cause false health check failures.

Figure 4‑6: Select the LoadMaster instances

  1. Select the LoadMaster instances.

Figure 4‑7: Add Tags

  1. Specify any tags, as desired.

Figure 4‑8: Review

  1. Review the settings and click Create to create the Elastic Load Balancer (ELB).

4.2Configure the LoadMaster

Complete the following steps to configure the LoadMaster settings:

  1. Log in to the UI of the master LoadMaster.
  2. In the main menu, go to System Configuration > HA and Clustering.

Figure 4‑9: HA Mode or Clustering

  1. If you have a clustering license, a screen will appear asking if you want to set up HA Mode or Clustering. To set up HA, select HA Mode and click Confirm.

Figure 4‑10: AWS HA Parameters (master)

  1. Select Master HA Mode from the AWS HA Mode drop-down list.
  2. Enter the IP address of the slave LoadMaster in the Partner Name/IP text box and click Set Partner Name/IP.
  3. Enter the health check port selected earlierin the Health Check Port text box and click Set Health Check Port.
  4. Log in to the UI of the slave LoadMaster.
  5. In the main menu, go to System Configuration HA and Clustering.

Figure 4‑11: HA Mode or Clustering

  1. If you have a clustering license, a screen will appear asking if you want to set up HA Mode or Clustering. To set up HA, select HA Mode and click Confirm.

Figure 4‑12: AWS HA Parameters (slave)

  1. Select Slave HA Mode from the AWS HA Mode drop-down list.
  2. Enter the IP address of the master LoadMaster in the Partner Name/IP text box and click Set Partner Name/IP.
  3. Enter the health check port selected earlierin the Health Check Port text box and click Set Health Check Port.

The Health Check Port must be the same on both the master and slave units in order for HA to function correctly.

In the Amazon EC2 console, go to the ELB and select the Instances tab. The master instance should be marked as InService. The slave instance should be marked as OutOfService.

In the LoadMaster, set up a HTTP and HTTPS Virtual Service with Real Servers. These should then be available using the ELB domain and they should properly fail over.

4.2.1Virtual Service Restrictions

There are some situations where Virtual Service settings may prevent HA from functioning correctly. Please follow the guidelines below to avoid any issues:

  • Do not set up a Virtual Service on the same port as the health check port
  • Do not set up a TCP Virtual Service on port 6973 on the interface where HA sync is configured
  • Do not set up a Virtual Service on either of the individual HA addresses
  • Do not set up a TCP Virtual Service on port 22 on a LoadMaster interface port

5LoadMaster Firmware Downgrades

Do not downgrade from firmware version 7.2.36 or higher to a version below 7.2.36. If you do this, the LoadMaster becomes inaccessible and you cannot recover it.

6Other Notes

If a LoadMaster instance is manually stopped and then started again, the instance must be removed and re-added to the Elastic Load Balancer after it is started. This is a limitation of AWS as documented in the AWS ELB documentation: https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-deregisterregister-instances.html.

Failure to do this will result in a HA pair where neither unit takes over the Active role. This is because the LoadMaster HA mechanism operates separately from the ELB mechanism. The Master is considered to be the active unit - but the ELB is ignoring the instance.

References

Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

LoadMaster for AWS, Feature Description High Availability (HA), Feature Description

Document History

Date

Change

Reason for Change

Version

Resp.

Dec 2015

Initial draft

First draft of document

1.0

LB

Jan 2016

Minor update

Updated

2.0

LB

July 2016

Minor updates

Enhancements made

3.0

LB

Oct 2016

Release updates

Updates for 7.2.36

4.0

LB

Was this article helpful?

0 out of 0 found this helpful

Comments