Category list

Resources and Real Servers

The concept of a real server in content switching is very important. While the name might give the impression that the definition must be a traditional server of some flavor, this is not necessarily always the case. In the instances of server load balancing as an application, the real server definitions are typically normal Web or application servers. In the instance of cache redirection, the real servers will be the caches rather than a Web server, and in firewall load balancing the real servers merely represent the path through the firewalled network. From this, it's easy to see that a real server is merely the definition of a resource, typically identified by a unique real server IP address, or RIP.

In server load balancing terms, an RIP is the actual IP address the content switch will use when performing the translation required to send a client request to an object server. In application redirection, the real server enables the content switch to resolve a MAC address that must be used when the translation takes place at Layer 2 only.

Real servers are traditionally associated to a group. This means that load balancing is typically done to a group of real servers rather than an individual server. This allows administrators to bring servers into and out of a group without impacting the application. The more servers in a group, the more the load will be distributed. Load distribution is dependent on load balancing metrics discussed in Chapter 5, Basic Server Load Balancing .

Frames , Packets, and Sessions

Throughout this book, we will talk about frames, packets, and sessions. In a very basic way, a frame is what is used to communicate at Layer 2 and holds the MAC address and protocol type information, among others. Packets are traditionally used for layer 3 communications and have the source and destination IP address within the header. A packet is inserted into a frame for communication across a network. A session is made up of a series of packets transporting user requests to a server. Today, most traffic sent across content switches is HTTP. Each object retrieved for a Web page or similar is seen as a single TCP session. When a user requests a page, some having up to 80 or more objects, a session needs to be set up for each object. All of these sessions are "collated" and referred to as a user session.

Determining switch performance, however, relies on session setup. The quicker we can set up a session and tear it down, the quicker we can complete the user session and ultimately display the content requested . Having a low session setup rate can impact the performance of a network and severely delay user response times. Some content switch manufacturers promote simultaneous session support as the key area in order to mask their inefficiencies in the session setup arena.

Lets look at an example. In Table 4-1, we can see that while content switch manufacturer A only supports 500,000 simultaneous sessions, it can set up and tear down 300,000 per second. Content switch manufacturer B can support 2,000,000 simultaneous sessions, but can only set up 10,000 per second.

Table 4-1. Session Per Second vs. Simultaneous Sessions

	M ANUFACTURER A	M ANUFACTURER B
Maximum simultaneous sessions supported	500,000	2,000,000
Maximum sessions setups per second	300,000	10,000
Time taken to setup 300,000 sessions	1 second	30 seconds