Check out the new USENIX Web site. next up previous
Next: TCP Connection Handoff Up: Prototype Cluster Design Previous: Prototype Cluster Design

   
Overview


  
Figure 9: TCP connection handoff
\begin{figure}
\centerline{\psfig{figure=fig/hop.eps,width=4.0in}}
\end{figure}

The cluster consists of a front-end node connected to the back-end nodes with a high-speed LAN. HTTP clients are not aware of the existence of the back-end nodes, and the cluster effectively provides the illusion of a single Web server machine to the clients.

Figure 9 shows the user-level processes and protocol stacks at the client, the front-end and the back-ends. The client application (e.g., Web browser) is unchanged and runs on an unmodified standard operating system. The server process at the back-end machines is also unchanged, and can be any off-the-shelf Web server application (e.g., Apache [2], Zeus [31]). The front-end and back-end protocol stacks, however, employ some additional components, which are added via a loadable kernel module.

The front-end and back-end nodes use the TCP single handoff protocol, which runs over the standard TCP/IP to provide a control session between the front-end and the back-end machine. The LARD and extended LARD policies are implemented in a dispatcher module at the front-end. In addition, the front-end also contains a forwarding module, which will be described in Section 7.2. The front-end and back-end nodes also have a user-level startup process (not shown in Figure 9) that is used to initialize the dispatcher and setup the control sessions between the front-end and the back-end handoff protocols. After initializing the cluster, these processes remain kernel resident and provide a process context for the dispatcher and the handoff protocols. Disk queue lengths at the back-end nodes are conveyed to the front-end using the control sessions mentioned above.


next up previous
Next: TCP Connection Handoff Up: Prototype Cluster Design Previous: Prototype Cluster Design
Peter Druschel
1999-04-27