Books
in black and white
Main menu
Home About us Share a book
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 70 >> Next

Clients
a En
□ Qi
a St
Internal network for an itiirriwKr or ISP with a
proxy server serving thousands of users
Proxy Servers ® From proxy Is IP
ad © From proxy I's IP
s © From proxy I s IP
CD©®'
load
Balancer
Load balancer sends all connections to the same server tn assure session persistence because all users through proxy server have |iroxy s IP address as the source IP.
1 his causes uneven load balancing.
31
Delayed Binding
Figure 3.9: Load-balancing problem with megaproxy.
When dealing with the megaproxy session-persistence problem where a user may come through different proxy servers for each connection, we can use virtual source, another type of session-persistence method, to maintain the session persistence. If the megaproxy involves four proxy servers, we can identify the IP address of each proxy server, and group them together to be treated as one virtual source. The load balancer considers connections from these four IP addresses as if they are from one virtual source IP address. With this approach, the load balancer can still maintain the session persistence by sending all the users coming through these four proxy servers to the same application server. While this solves the session-persistence problem, it can violate the load balancing in a big way, depending on what percentage of total traffic for this site comes from this set of megaproxy servers.
Delayed Binding
So far, we have looked at load-balancing and session-persistence methods, where the load balancer assigns a server at the moment it receives a TCP SYN packet. Once the connection is assigned to a server, all subsequent packets are forwarded to the same server. However, there is a lot of good application information in the packets received after the TCP connection is established. If the load balancer can look at the application request, it can make more intelligent decisions. In the case of Web applications, the HTTP requests contain URLs and cookies that the load balancer can use to select an appropriate server. In order to examine the application packets, the load balancer must postpone the binding of a TCP connection to a server until after the application request is received. Delayed binding is this process of delaying the binding of a TCP connection to a server until after the application request is received.
In order to understand how delayed binding actually works, we need to discuss a few more details about TCP protocol semantics, especially focusing on TCP sequence numbers.
First, the client sends its initial sequence number of 100 in the SYN packet, as shown in Figure 3.10. The server notes the client’s sequence number and replies with its own starting sequence number to the client as part of the SYN ACK. The SYN ACK conveys two things to the client. First, the server’s starting sequence number is 500. Second, the server got the client’s SYN packet with a sequence number of 100. The client and server increment sequence numbers for each packet sent. The sequence numbers help the client and server ensure reliable data delivery of each packet. As part of each packet, the client also sends acknowledgment for all the packets received from the server so far. The initial starting sequence number picked by the client or server depends on the TCP implementation. RFC 793 contains more details about choosing starting sequence numbers.
Request Data (sequence 102. ACK sequence 501)
Request Data (sequence 103, ACK sequence 502) _
Figure 3.10: Understanding TCP sequence numbers.
32
Delayed Binding
Since a TCP connection must first be in place in order to receive the application request, the load balancer completes the TCP connection setup with the client on behalf of the server. The load balancer must respond to the client’s SYN packet with a SYN ACK by itself, as shown in Figure 3.11. In this process, the load balancer has to make up its own sequence number without knowing what the server may use. Once the HTTP request is received, the load balancer selects the server, establishes a connection with the server, and forwards the HTTP request to the server. The initial sequence number chosen by the server can be different from the initial sequence number chosen by the load balancer in the client-side connection. Therefore, the load balancer must translate the sequence number for all reply packets from the server to match what the load balancer used on the client-side connection. Further, since the client includes an acknowledgment for the server-side sequence number in each packet it sends to the server, the load balancer must also change the ACK sequence numbers for packets from client to the server.
Figure 3.11: Delayed binding.
Because the load balancer must perform an additional sequence-number translation process for client requests as well as server replies, delayed binding can impact the performance of the load balancer. Obviously, the amount of performance impact varies from one load-balancing product to another. But delayed binding represents a significant advancement in the information the load balancer can use to select servers. The load balancer does not have to rely on the limited information in the TCP SYN packet alone. It can now look at the application-request packets and significantly extend the capabilities of a load balancer.
Previous << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 70 >> Next