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

Figure 3.2: Web transaction flow with load balancer involved.
Because lire load balancer all sessions from the same user to the same server, the server has an accurate context of tlic stopping cart.
Figure 3.3: Web transaction flow with session persistence on the load balancer.
26
Types of Session Persistence
Session persistence is generally not an issue if we are dealing with a read-only environment where the same content is served regardless of the user. For example, if someone is browsing Yahoo’s home page, it does not really matter how the connections are distributed. If someone registers at Yahoo and creates a customized Web page, then the server must know the user identification in order to serve the right content. In this case, session persistence can be an issue.
Types of Session Persistence
Let’s just quickly recap the definition of session persistence. Session persistence is the ability to persist all the sessions for a given user to the same server for the duration of an application transaction. In order to perform session persistence, the load balancer must know two things: how to identify a user, and how to recognize when an application transaction begins or ends.
When the load balancer receives a new connection, it can either load-balance it or perform session persistence. In other words, the load balancer assigns the connection to a server based on server health and load conditions, or selects a server based on the information in the TCP SYN packet, and determines if this user has already been to a server before. load balancing involves server selection based on server conditions, and session persistence involves server selection based on information in the TCP SYN packet.
To perform session persistence, what relevant information is available for the load balancer in the TCP SYN packet? We can get the source IP address, source port, destination IP address, and destination port. To start with, the load balancer can identify a user based on the source IP address in the packet. But what if the load balancer could look into the request data to determine the server selection? We probably could get a lot more interesting application information by looking into the request packets. Based on this, session persistence can broadly be categorized into two types: session persistence based on information in the TCP SYN packet, and session persistence based on information in the application request. Since, session persistence based on information in the TCP SYN packets revolves around the source IP, as that’s the key to identify each user, we refer to this method as a source IP based persistence.
Source IP-Based Persistence Methods
When a TCP SYN packet is received, the load balancer looks for the source IP address in its session table. If an entry is not found, it treats the user as new and selects a server based on the load-distribution algorithm and forwards the TCP SYN packet. The load balancer also makes an entry in the session table for this session. If an entry for this source IP address is found in the session table, the load balancer forwards the TCP SYN packet to the same server that received the previous connection for this source IP address, regardless of the load-distribution algorithm. When a TCP FIN or RESET is received, the load balancer terminates the session, but leaves an entry in the session table to remember that a connection from this source IP address has been assigned to a particular server.
Since the load balancer does not understand the application protocol, it cannot recognize when an application transaction begins or ends in order to continue or end the session-persistence process. Therefore, when configured to perform session persistence, the load balancer simply starts a configurable timer against the session-table entry that records the association of a user’s sessions to a particular server. This timer starts when the last active connection from the user terminates. This timer is known as the session-persistence timer, and it works as an idle timer. If there are no new connections from a user for the duration of session-persistence timer, the load balancer removes the user’s association with a server from its session table. If a new connection from the same user is received before the timer expires, the load balancer resets the timer, and starts it again when the last active session from that user terminates.
27
Source IP-Based Persistence Methods
There are many different variations in providing source IP based session persistence. It’s important to understand the need for these different variations. When performing session persistence, the load balancer sends subsequent connections to the same server regardless of the load on that server. If that server is very busy, the user may get slow response, although there are other servers running the same application that may provide much better response time. Session persistence violates load balancing. load balancing involves sending the request to the server with least load, whereas session persistence involves sending the request to the same server as before, regardless of the load. In order to get the best scalability and response time, we need to use the minimum level of session persistence that fulfills the application requirements, so we can get more load balancing.
Previous << 1 .. 14 15 16 17 18 19 < 20 > 21 22 23 24 25 26 .. 70 >> Next