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 .. 13 14 15 16 17 18 < 19 > 20 21 22 23 24 25 .. 70 >> Next

Network address translation forms the foundation for the load balancer’s processing. There are different types of NAT, such as destination NAT and source NAT, that help in accommodating a variety of network designs with load balancers. Direct Server Return helps in load-balancing applications with complex NAT requirements, by obviating the need for destination NAT.
24
Chapter З: Server load balancing: Advanced Concepts
We covered enough concepts of load balancing for a new user to start using load balancers for basic applications. The moment you want to do anything more than the very basic functions, you will need a bit more advanced technology. In this chapter, we will cover those topics, including session persistence and URL switching, that are necessary to use load balancing with many applications.
Session Persistence
Many popular applications run over TCP, as TCP provides reliable transport and takes care of many of the communication semantics. TCP is a connection-oriented protocol. A client and server establish a TCP connection to exchange data. But as we examined in Chapter 2, Web server applications such as HTTP involve using several TCP connections between a client and server. So if we define the application-level work unit as an application transaction, each transaction uses several TCP connections. The load balancer performs load distribution for each TCP connection, as the load balancer is unaware of the application transaction progressing on top of TCP. In this section, we will discuss how the application transactions behave on top of TCP protocol, and how this will impact the function of the load balancer.
Defining Session Persistence
Let’s first define an application transaction as a high-level task, such as buying a book from Amazon.com.
An application transaction may consist of several exchanges between the client and the server that take place over multiple TCP connections. Let’s consider an example of the shopping-cart application that’s used at e-commerce Web sites where consumers buy some items. Let’s look at the request-and-reply flow between the client browser and the Web server, as shown in Figure 3.1.
Client Server
_______________TCP SYN____________________
__________TCP SYN ACK______________
TCP ACK_
___________HTTP Request___________________
__________HTTP Res|X)iise__________
_______________TCP________________________FIN_____________________
TCP FIN ACK
New TCP connection established HTTP Request
__________HTTP Response__________
TCP connection terminated
25
Chapter 3: Server load balancing: Advanced Concepts
Figure 3.1: Request-and-reply flow for a Web transaction.
First, the browser opens a TCP connection to the Web site, and sends an HTTP GET request. The server replies with all the objects that are part of the Web page. The browser then obtains each object and assembles the page. When the user clicks another link, such as “buy this book” or “search for a book,” the browser opens another TCP connection to send the request. As part of the reply, the browser receives several objects as part of the next page. The browser obtains all the necessary objects and assembles the next page. When the user adds an item to the shopping cart, the server keeps track of the shopping cart for the user. Where there is just one server running the application, all the connections from all users go to the same server.
Let’s now deploy a load balancer to get the desired scalability by distributing load across multiple servers.
The load balancer sends each TCP connection to a server based on the load on each server at the moment the connection request is received, as shown in Figure 3.2. The user may add an item to the shopping cart over a TCP connection that goes to server 1. If the next connection goes to server 2, which does not have the shopping-cart information, the application breaks. To solve this problem, the load balancer must send all the connections from a given user to the same server for the entire duration of the application transaction, as shown in Figure 3.3. This is known as session persistence, as the load balancer persists all the sessions from a given user to the same server. Many people also refer to session persistence as sticky connections because a user must stick to one server for all connections. The question now is, How does the load balancer identify a given user and recognize when an application transaction begins and ends?
® HTTP mfucst/rcNfiuiac to brow» a hook
(2) HTTP rcqucst.Vcspoitsc to add
IxmAI Id ihr carl.
@ HTTP rrqucM.'r^porwr to add boofci to the stopping can.
(ij) Clkk A button to proceed to checkout page.
User expects book I and book'd to be hi tlic si topping can.
®,
©

Load
Balancer rm

© %

Shopping cart is empty
Book I in Hit* shopping cart
Book? in the shopping cart
Shopping cart is empty
Each server ha» a different perspec tive of the shopping carl, because the load balancing sends the user to a different server fui eac h connection
Previous << 1 .. 13 14 15 16 17 18 < 19 > 20 21 22 23 24 25 .. 70 >> Next