Virtual Server via NAT
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 limited. The load balancer may be a bottleneck of the whole system when the number of server nodes (general PC servers) increase to around 20 or more, because both the request packets and response 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 throughput of the load balancer is 8.93 MBytes/s. Assuming the average throughput 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 or virtual server via direct routing. In the DNS hybrid approach, there are many load balancers who all have their own server clusters, and the load balancers are grouped at a single domain name by Round-Round DNS. You can try to use VS-Tunneling or VS-DRouting for good scalability, you can also try the nested VS load balancers approach, the first front-end is the VS-Tunneling or VS-DRouting load balancer, the second layer is many VS-NAT load balancers, which all have their own clusters.
Virtual Server via IP Tunneling
In the virtual server via NAT, request and response packets all need to pass through the load balancer, the load balancer may be a new bottleneck when the number of server nodes increase to 20 or more, because the throughput of the network interface is limited eventually. We can see from many Internet services (such as web service) that the request packets are often short and response packets usually 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 throughput 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. It is 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.
Virtual Server via Direct Routing
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 response 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 the same physical segment.
The following subsections will explain their advantages and disadvantages. The comparison of VS/NAT, VS/TUN and VS/DR is summarized in the following table.
|server number||low (10~20)||high||high|
|server gateway||load balancer||own router||own router|