Now virtual server is implemented in three ways. There are three request dispatching techniques existing together in the LinuxDirector. They are the virtual server via NAT, the virtual server via IP tunneling and the virtual server via direct routing. Please see the three separate sections for their working principles.
How to build the kernels and how to use them are also explained there in details. The following subsections will explain their advantages and disadvantages.
The advantage of the virtual server via NAT is that real servers can run any operating system that supports TCP/IP protocol, real servers can use private Internet addresses, and only an IP address is needed for the load balancer.
The disadvantage is that the scalability of the virtual server via NAT is not very good, the load balancer may be a bottleneck of the whole system when the number of server nodes increase to around 25 or more, because both the request packets and the reply packets are need to be rewritten by the load balancer. Supposing the average length of TCP packets is 536 Bytes, the average delay of rewriting a packet is around 60us (on Pentium processor, this can be reduced a little by using of higher processor), the maximum throughout of the load balancer is 8.93 MBytes/s. Assuming the average throughout of real servers is 400Kbytes/s, the load balancer can schedule 22 real servers.
Virtual server via NAT can meet the performance request of many servers. Even when the load balancer is becoming a bottleneck of the whole system, there are two methods to solve it, one is the hybrid approach, and the other is the virtual server via IP tunneling. In the hybrid approach, there are many load balancers who all have their own server clusters, and many load balancers are grouped at a single domain name by Round-Round DNS. The virtual server via IP tunneling is explained above.
In the virtual server via NAT, incoming packets and replies all need to pass through the load balancer, the load balancer may be a new bottleneck when the number of server nodes increase to 25 or more, because the data throughout may reach the max data through of the network interface. We can see from many Internet services (such as web service) that the incoming packets are always short and reply packets always have large amount of data.
In the virtual server via IP tunneling, the load balancer just schedules requests to the different real servers, and the real servers return replies directly to the users. So, the load balancer can handle huge amount of requests, it may schedule over 100 real servers, and it won't be the bottleneck of the system. :-) Thus using IP tunneling will greatly increase the maximum number of server nodes for a load balancer. The maximum throughout of the virtual server can reach over 1Gbps, even if the load balancer just has 100Mbps full-duplex network adapter.
The IP tunneling feature can be used to build a very high-performance virtual server, extremely good to build a virtual proxy server, because when the proxy servers get request, it can access the Internet directly to fetch objects and return them directly to the users.
However, all servers must have "IP Tunneling"(IP Encapsulation) protocol enabled, I just tested it on Linux IP tunneling. If you make virtual server work on servers running other operating systems with IP tunneling, please let me know, I will be glad to hear that.
Like in the virtual server via tunneling approach, LinuxDirector processes only the client-to-server half of a connection in the virtual server via direct routing, and the reply packets can follow separate network routes to the clients. This can greatly increase the scalability of virtual server.
Compared to the virtual server via IP tunneling approach, this approach doesn't have tunneling overhead(In fact, this overhead is minimal in most situations), but requires that one of the load balancer's interfaces and the real servers' interfaces must be in physical segment.
Last updated: 1999/5/1
Created on: 1998/12/5