Category Archives: architecture

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

Layer 4 load balancing tunnel mode

The tunnel mode looks like the Direct Server Return mode, except that traffic between the load-balancer and the server can be routed.

The load-balancer encapsulates the request in an IP tunnel to the server.
The server recover the client request from the loadbalancer, process it and forward the response directly to the client.

TCP connection overview

layer4_tunnel_tcp_connection
The loadbalancer takes client requests then encapsulate them into an IP tunnel to forward them to the server.

Data flow

layer4_tunnel_data_flow
The client traffic between the server and the load-balancer is tunneled and can be routed between both of them.
The server will answer directly to the client.

Pros and cons

Pros

  • backends from multiple datacenters can be used
  • load-balancer network bandwith is not a bottleneck anymore
  • total output bandwith is the sum of each backend bandwith

Cons

  • requires patched backend to be able to tunnel IP traffic
  • no layer 7 advanced features are available

When use this architecture?

  • when the only way to reach backends is routing.
  • where no intelligence is required
  • when output capacity of the load-balancer could be the bottleneck

Links

layer 4 load balancing Direct Server Return mode

Direct server return is usually shortened to DSR.

In DSR mode, the load-balancer routes packets to the backends without changing anything in it but the destination MAC address.
The backends process the requests and answer directly to the clients, without passing through the load-balancer.

The backends must have the service IP configured on a loopback to be able to accept the requests.

TCP connection overview

layer4_dsr_tcp_connection
As usual when performing layer 4 load-balancing, the TCP connection is established directly between the client and the backend.
Note that the the requests pass through the load-balancer while the responses not.

Data flow

layer4_dsr_data_flow
As explained above, the load-balancer sees only the requests and just change the destination MAC address of the packets.
The backends answers directly to the client using the service IP configured on a loopback interface.

Pros and cons

Pros

  • very fast load-balancing mode
  • load-balancer network bandwith is not a bottleneck anymore
  • total output bandwith is the sum of each backend bandwith
  • less intrusive than the layer 4 load-balancing NAT mode

Cons

  • the service VIP must be configured on a loopback interface on each backend and must not answer to ARP requests
  • no layer 7 advanced features are available

When use this architecture?

  • where response time matters
  • where no intelligence is required
  • when output capacity of the load-balancer could be the bottleneck

Links

Layer 4 load balancing NAT mode

NAT stands for Network Address Translation.

In the NAT mode, the load-balancer will route traffic between user and server by changing destination IP address of the packets.

TCP connection overview

TCP connection is established between the client and the server.
The loadbalancer just ensures a client is always forwarded to the same server.
layer4_nat_tcp_connection

Data flow

As shown below, the clients get connected to the service VIP.
The load balancer chooses a server in the pool then forwards packets to it by changing destination IP address.
layer4_nat_data_flow

Pros and cons

Pros

  • fast load balancing
  • easy to deploy

Cons

  • infrastructure intrusive: need to change the default gateway of the servers
  • The server default gateway must use the load balancer, in order to do reverse NAT operation.
  • output bandwith is limitated by loadbalancer output capacity

When use this architecture?

  • where response time matters
  • where no intelligence is required
  • when output capacity of the load-balancer won’t be a bottleneck in a near future
  • when nothing but the default gateway of the servers can be changed

Links