Efficient support for content‐aware request distribution and persistent connection in Web clusters

Abstract

To support Web clusters with efficient dispatching mechanisms and policies, we propose a light-weight TCP connection transfer mechanism, TCP Rebuilding, and use it to develop a content-aware request dispatching platform, LVS-CAD, in which the request dispatcher can extract and analyze the content in requests and then dispatch each request by its content or type of service requested. To efficiently support HTTP/1.1 persistent connection in Web clusters, request scheduling should be performed per request rather than per connection. Consequently, multiple TCP Rebuilding, as an extension to normal TCP Rebuilding, is proposed and implemented. On this platform, we also devise fast TCP module handshaking to process the handshaking between clients and the request dispatcher in the IP layer instead of in the TCP layer for faster response times. Furthermore, we also propose content-aware request distribution policies that consider cache locality and various types of costs for dispatching requests in this platform, which makes the resource utilization of Web servers more effective. Experimental results of a practical implementation on Linux show that the proposed system, mechanisms, and policies can effectively improve the performance of Web clusters.

An up-to-date survey in web load balancing

“…The third and last two-way mechanism, Redirect Flows developed by Colby et al [27], is very similar to the TCP Splicing approach but based on the NAT architecture [19,51]. It was a proprietary mechanism of Arrowpoint Communications Inc., a company that was acquired by Cisco Systems Inc. [24] in the year 2000.…”

“…The seventh and last mechanism is TCP Rebuilding which was proposed by Liu et al in [50,51] to be implemented in a LVS with Content-Aware Dispatching (LVS-CAD) platform (that is described in Section 6). Figure 6b details its procedure: when the connection between the client and the load balancer is established and the HTTP request has arrived to the load balancer, it is sent to the selected Web server which starts rebuilding the TCP connection without the need of interchanging any more packets.…”

“…We have divided the content-aware architecture solutions in seven main groups based on the original mechanisms proposed to route the requests from a target Web server to clients in one-way architecture. : TCP Hand-off [38], One-packet TCP State Migration to Packet Filter [49], TCP Connection Hop [65], Socket Cloning [73], One-way TCP Splicing [55], One-way Connection Binding [53] and TCP Rebuilding [51]. Variations of these original proposals are also considered in each classification group.…”

“…Table 2 summarises the solutions covered in this section, indicating if they include request granularity when using the HTTP/1.1 protocol. We have marked in bold the -One-packet TCP state migration to packet filter [49] -Socket cloning [73] -Multiple-cloning [73] -One-way TCP Splicing [55] -One-way connection binding [53] -TCP rebuilding [50] -Multiple TCP rebuilding [51] options that implement content-aware distribution based on a layer-4 front-end. The variations of these proposals have been omitted in the table.…”

“…The Linux software framework, LVS [70], also can be configured to support NAT and IPTun, but the most efficient mechanism is DR [19,51]. Microsoft also implements a layer-3 forwarding mechanism named Network Load Balancing (NLB) that is included in the Windows Server 2003 Family [15].…”