L4 vs L7 Showdown

10. December 2016 2016 0

Author: Atif Siddiqui

Editors: Vinny Carpenter, Brian O’Rourke

Objective

This article will explain the role and types of load balancers before delving into it through the prism of Amazon Web Services (AWS). This post wraps up with a lab exercise on AWS Load Balancer migration.

Introduction

A load balancer is a device that in its simplest form acts as a funnel for traffic before redistributing it. This is achieved by playing the role of reverse proxy server (RPS). While a load balancer can be a hardware device or a software component, this article will focus on a Software Defined Networking (SDN) load balancer.

Load Balancer dictating traffic distribution
Load Balancer dictating traffic distribution

OSI 101

Open System Interconnection (OSI) model is a conceptual illustration of networking. It shows the dependency of each layer serving the one above it. When discussing load balancers, transport and applications layer hold our interest.

Open Systems Interconnection model – high level
Open Systems Interconnection model – high level

There are two types of load balancers.

1. A Layer 4 load balancer works at the networking transport layer. This confines the criteria to IP addresses and ports as only the packet header is being inspected without reviewing its contents.

2.A  Layer 7 load balancer works at the application layer. It has higher intelligence because it can inspect packet contents as it understands protocols such as HTTP, HTTPS, WebSockets. This gives it the ability to perform advanced routing.

Open Systems Interconnection model – close up [1]
Open Systems Interconnection model – close up [1]

AWS Perspective

Elastic Load Balancer (ELB) is one of the cornerstones of designing resilient applications. A walk down memory lane shows that beta release happened back in May 2009. Being a layer 4 (L4) load balancer, with ELB, routing decisions are made without inspecting contents of the packet.

The abstraction and simplicity of use remain as its core strengths: provisioning can be done through one click of a button. On the flip side, one of the features that is conspicuously missing is the support of server name indication (SNI). While wildcard and SAN certificates are supported, hopefully multiple certificates support is around the corner.

As a new offering in this space, AWS recently came out with Layer 7 Load balancer aptly named Application Load Balancer (ALB). This was announced in August this year with availability across all AWS commercial regions. Along with this announcement, the original load balancer was rebranded as Class Load Balancer.

Building blocks of an AWS application load balancer
Building blocks of an AWS application load balancer

AWS has also introduced target group as the new nomenclature. Target group is used to register EC2(s) that is mapped to port number(s). Target group is linked to ALB via Listener which in turn can have rule(s) association.

Register/de-register instance for Target group
Register/de-register instance for Target group

Some other noteworthy aspects about ALB are:

1. ALB supports HTTP and Web Sockets.

3. While AWS cli for Classic Load Balancer is aws elb, for Application Load Balancer it is aws elbv2.

4. ALB allows routing via path matching only with a ceiling of 10 URL based rules.

5. Like Classic, pre-warming for ALB is recommended in preparation for major traffic spike.

6. ALB’s hourly late is 10% lower than ELB.

7. CloudFormation supports ALB though, interestingly, it is referred to as ElasticLoadBalancingV2.

Migration Guide: ELB -> ALB

While ELB cannot be converted to an ALB, migration is supported [2]. AWS recommends python script [3] available in github. The following exercise was done on an Amazon AMI to test such a migration. Each command is preceded with a comment to indicate the purpose. It is assumed that the reader already has the AWS CLI installed, as well as has their credentials set up to be able to manipulate aws objects from the command line.

— grab migration utility [4]

— verify existing ELB name via cli

— Conduct dry run for load balancer migration (specified incorrect region first time around). As python script needs boto3; prerequisite step is to run command via pip install boto3

— create application load balancer

Target group ARNs:

Considerations:

1. If your Classic load balancer is attached to an Auto Scaling group, attach the target groups to the Auto Scaling group.

2. All HTTPS listeners use the predefined security policy.

3. To use Amazon EC2 Container Service (Amazon ECS), register your containers as targets.

On November 22, the product team published [5] a new ALB feature for request tracing. This will provide the ability to trace through individual requests. I can’t wait to play with it.

References

  1. https://mplsnet.files.wordpress.com/2014/06/osi-model.gif
  2. http://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-to-application-load- balancer.html
  3. https://github.com/aws/elastic-load-balancing-tools
  4. https://raw.githubusercontent.com/aws/elastic-load-balancing- tools/master/copy_classic_load_balancer.py
  5. https://aws.amazon.com/blogs/aws/application-performance-percentiles-and-request-tracing-for- aws-application-load-balancer/

 

About the Author:

Atif Siddiqui is a certified AWS Solutions Architect. He works as an Architect at General Electric (GE) in enterprise applications space. His responsibilities encompass critical applications with global footprint where he brings solutions and infrastructure expertise for his customers. He is also an avid blogger on GE’s internal social media.

About the Editors:

Brian O’Rourke is the co-founder of RedisGreen, a highly available and highly instrumented Redis service. He has more than a decade of experience building and scaling systems and happy teams, and has been an active AWS user since S3 was a baby.