Category Archives: layer7

Aloha Load-balancer as a reverse proxy

Synopsis

You own small public subnet and want to be able to access multiple web sites or application behind a single public IP address.
Basically, you want to use your Aloha load-balancer as a reverse proxy.

Diagram

The diagram below shows how the reverse proxy works.
In our case, we have 2 domains pointing to the Aloha IP address.
Depending on the domain name, the Aloha will decide which farm it will use.
reverse_proxy

Configuration

On the Aloha, the reverse-proxy configuration is achieved by HAProxy.
HAProxy configuration can be done in the “layer 7” tab of the GUI or through the CLI command “service haproxy edit”.

First, the Frontend definition.
This is where HAProxy will take rooting decision based on layer 7 information.

frontend ft_websites
   mode http
   bind 0.0.0.0:80
   log global
   option httplog
# Capture Host header is important to know whether rules matches or not
   capture request header host len 64
# mysite configuration
   acl site1 hdr_sub(host) site1.com
   acl site1 hdr_sub(host) site1.eu
   use_backend bk_site1 if site1
# yoursite configuration
   acl site2 hdr_sub(host) site2.com
   acl site2 hdr_sub(host) site2.ie
   use_backend bk_site2 if site2
# default configuration
   default_backend bk_default

And now, we can define our backend sections for each website or application:

# First site backend configuration
backend bk_site1
   mode http
   balance roundrobin
   cookie SERVERID insert indirect nocache    # persistence cookie
   option forwardfor # add X-Forwarded-For
   option httpchk HEAD / HTTP/1.0rnHost: www.site1.com
   default-server inter 3s rise 2 fall 3 slowstart 0 # servers default parameters
   server srv1 192.168.10.11:80 cookie s1 weight 10 maxconn 1000 check
   server srv2 192.168.10.12:80 cookie s2 weight 10 maxconn 1000 check

# Second site backend configuration
backend bk_site2
   mode http
   balance roundrobin
   cookie SERVERID insert indirect nocache    # persistence cookie
   option forwardfor # add X-Forwarded-For
   option httpchk HEAD / HTTP/1.0rnHost: www.site2.com
   default-server inter 3s rise 2 fall 3 slowstart 0 # servers default parameters
   server srv1 192.168.10.13:80 cookie s1 weight 10 maxconn 1000 check
   server srv2 192.168.10.14:80 cookie s2 weight 10 maxconn 1000 check

And finally, the “garbage collector”, the default backend which hosts all the traffic that has not match any other rules.
It may be important to watch logs from this backend in order to ensure there is no mis-configuration.

backend bk_default
   mode http
   balance roundrobin
   option forwardfor # add X-Forwarded-For
   option httpchk HEAD /
   default-server inter 3s rise 2 fall 3 slowstart 0 # servers default parameters
   server srv1 192.168.10.8:80 weight 10 maxconn 1000 check
   server srv2 192.168.10.9:80 weight 10 maxconn 1000 check

Links

layer 7 load-balancing proxy mode

This mode is sometimes called reverse-proxy.

The load-balancer is in the middle of all transactions between the user and the server.
It maintains two separated TCP connections:

  • One with the user: the load-balancer acts as a server. It takes requests and forward responses
  • One with the server: the load-balancer acts as a user: it forward requests and get responses

This mode is the less intrusive in an architecture: nothing to change on any server or router.

TCP connection overview

layer7_reverse_proxy_tcp_connection
The diagram shows clearly the two TCP connections maintained by the load-balancer.

Data flow

layer7_reverse_proxy_data_flow
As a consequence of the proxy mode, the server gets a connection from the load-balancer IP address and the server can only get the client IP address at the application level.
IE: HTTP X-Forwarded-For header.

Pros and cons

Pros

  • not intrusive
  • more secure: server aren’t reached directly
  • allows protocol inspection and validation
  • can load-balance services even if both client and server are in the same subnet

Cons

  • backend servers only see one IP address: the one from the LB
  • “slower” than layer 4 load-balancing (we speak about micro-seconds)

When use this mode?

  • when you need application layer intelligence (content switching, etc…)
  • in order to protect an application
  • when the application does not care about the user IP (or can use the X-Forwarded-For header)

Links

layer 7 load-balancing transparent proxy mode

The load-balancer is in the middle of all transactions between the user and the server.
It maintains two separated TCP connections:

  • With the user: the load-balancer acts as a server. It takes requests and forward responses
  • With the server: the load-balancer acts as a user: it forward requests and get responses

It is really close to the proxy mode, but has one main difference: the load-balancer opens the connection to the server using the client IP address as source IP.

Of course, the backend server default gateway must be the load-balancer.

TCP connection overview

layer7_transparent_proxy_tcp_connection
The diagram shows clearly the two TCP connections maintained by the load-balancer.

Data flow

layer7_transparent_proxy_data_flow
Since the load-balancer opens the TCP connection to the server with the user IP address, the server must use the load-balancer as its default gateway.
Otherwise, the server would forward response directly to the client and the client would drop it…

Pros and cons

Pros

  • servers see the client IP address at network layer
  • secure: server aren’t reached directly
  • allows protocol inspection and validation

Cons

  • intrusive: must change the default gateway of the server.
  • “slower” than layer 4 load-balancing (we speak about micro-seconds)
  • clients and servers must be in two different subnets.

When use this mode?

  • when the load-balanced service needs client IP at network layer (IE: anti-spam services)
  • when you need application layer intelligence (content switching, etc…)
  • in order to protect an application

Links

Smart content switching for news website

Purpose

Build a scalable architecture for news website using below components:

  • load balancer with content switching capability
  • cache server
  • application server

Definition

  • Content switching: the ability to route traffic based on the content of the HTTP request: URI, parameters, headers, etc…
    HAproxy is a good example of OpenSource reverse proxy load-balancer with content switching capability.
  • cache server: a server able to quickly deliver static content.
    Squid, Varnish and Apache Traffic Server are OpenSource cache reverse proxy.
  • application server: the server which build the pages for your news website.
    This can be either Apache+PHP, Tomcat+Java, IIS+asp .net, etc…

Target Network Diagram

Architecture

Context

All the traffic pass through the Aloha load-balancer.
HAproxy, the layer 7 load-balancer included in Aloha, will do the content switching to route request either to cache servers or to application servers.
If cache server misses an object, it will get it from the application servers.

Haproxy configuration

Service configuration:

frontend public
	bind :80
	acl DYN path_beg /user
	acl DYN path_beg /profile
	acl DYN method POST
	use_backend APPLICATION if DYN
	default_backend CACHE

The content switching is achieved by the few lines beginning with the keyword acl.
If a URI starts with /user or /profile or if the method is a POSTthen, the traffic will be redirected to the APPLICATION server pool, otherwise the CACHE pool will be used.

Application pool configuration:

backend APPLICATION
	balance roundrobin
	cookie PHPSESSID prefix
	option httpchk /health
	http-check expect string GOOD
	server APP1 1.1.1.1:80 cookie app1 check
	server APP2 1.1.1.2:80 cookie app2 check

We maintain backend server persistence using the cookie sent by the application server, named PHPSESSID in this example. You can change this cookie name to the cookie provided by your application, like JSESSIONIDASP.NET_SessionId or anything else.
Note the health check URL: /health. The script executed on the backend will check server health (database availability, CPU usage, memory usage, etc…) and will return a GOOD if everything looks fine and a WRONG if not. With this, HAproxy will consider the server as ready only if the server returns a GOOD.

Cache pool configuration

backend CACHE
	balance url
	hash-type consistent
	option httpchk /
	http-check expect KEYWORD
	reqidel ^Accept-Encoding unless { hdr_sub(Accept-Encoding) gzip }
	reqirep ^Accept-Encoding: .*gzip.* Accept-Encoding: gzip
	server CACHE1 1.1.1.3:80 check
	server CACHE2 1.1.1.4:80 check

Here, we balance requests according to the URL. The purpose of this metric is to “force” a single URL to always be retrieved from the same server.
Main benefits are :

  1. less objects in caches memory
  2. less requests to the application server for static and pseudo-static content

In order to lower the impact of the Vary: header on Content Encoding, we added the two lines reqidel / reqirep to normalize a bit the Accept-Encoding header.

Links

Layer7 IPv6 configuration

Purpose

Use the Aloha as an IPv6 to IPv4 gateway without modifying anything on your current platform.

Target Network Diagram

Context

The website is available through IPv4 on  the service IP  192.168.1.254. The IPv4 router does NAT IPv4 public address to this service IP.
About IPv6, the website hostname resolves directly on the IP 2001::2254, which is the  IPv6 service IP hosting the service. The router just routes traffic to the Aloha.
All IPv6 traffic will be automatically translated to IPv4 by the Aloha: nothing to change on your servers and your servers don’t even need to be IPv6 compliant.

Configuration

Aloha 1 network configuration

On the GUI, click on Services > network > eth0  setup icon  , then  update  the configuration as below:

service network eth0
    vrrp id 254
    vrrp garp 30
    vrrp prio 100
    vrrp no-address
    vrrp address 2001::2254
    vrrp address 192.168.1.254
    vrrp address 2001::2254
    ip6  address 2001::2201/96
    ip address 192.168.1.201/24
    mtu 1500

Click on [OK], then [Close].

Once the configuration has been updated, you need to reload the services:

  • Network: Click on Services > eth0 reload icon
  • VRRP: Click on Services > vrrp reload icon

Aloha 2 network configuration

On the GUI, click on Services > network > eth0  setup icon  , then  update  the configuration as below:

service network eth0
    vrrp id 254
    vrrp garp 30
    vrrp prio 99
    vrrp no-address
    vrrp address 2001::2254
    vrrp address 192.168.1.254
    vrrp address 2001::2254
    ip6  address 2001::2202/96
    ip address 192.168.1.202/24
    mtu 1500

Click on [OK], then [Close].

Once the configuration has been updated, you need to reload the services:

  • Network: Click on Services > eth0 reload icon
  • VRRP: Click on Services > vrrp reload icon

Layer 7 (HAproxy) configuration

This configuration is common to both Aloha load balancer.
Add the bind on the IPv6 service address in the corresponding frontend section:

frontend ft_myappli
    bind  192.168.1.254:80
    bind 2001::2254:80
    mode http
    log global
    option httplog
    maxconn 1000
    timeout client 25s
    default_backend bk_myappli

Click on [OK], then [Apply].

Links