next up previous contents
Next: Load balancing extra features Up: Future enhancements to ProtoWrap Previous: Signal handling   Contents


Load balancing

Another possibility that opens up when designing a program like ProtoWrap is to implement in it a load balancer. Load balancing is a technique very often used in heavy-traffic sites, allowing many computers to answer at the requests directed at a single IP address/port pair. There are many ways to achieve this:

Round-robin DNS
The DNS server is configured to relate more than one IP address to each hostname, as in the following case:
[user@host user]$ nslookup www.microsoft.com
Server:  dns1.unam.mx
Address:  132.248.204.1

Non-authoritative answer:
Name:    www.microsoft.akadns.net
Addresses:  207.46.230.229, 207.46.230.219, 207.46.131.199
          207.46.230.218, 207.46.130.45
Aliases:  www.microsoft.com
Clustered server
There are many ways to build a cluster[*], suited for different purposes. Among the most often heard is Beowulf, a project started at NASA which implements Parallel Virtual Machines. However, clustering servers do not require (in fact, would hardly be benefited from) a programming technique as hard to master and code; a fork-and-forget clustering system such as Mosix[*] is much more adequate -- In such a system, a master server appears to be the only one running, but when a connection is recieved, the server process is forked to a different computer, according to the systems' current load. This may be the most scalable solution, and it provides the closest answer to high-availability requirements.
Dispatching server
This will be the proposed solution for extending ProtoWrap: A single server is registered, and no special software is running in each server. A separate machine appears to be serving all the pages, but what it does essentialy is to wrap the connections and forward them to another server.
ProtoWrap can easily be expanded to become a load balancing dispatching server -- most of what is needed is already done. Of course, as a great benefit, it would be also a traffic validator, ProtoWrap's main function, protecting all the real servers.

How would this implementation look like? ProtoWrap's code could be easily modified to discern whether the value contained in the destAddr attribute is a scalar value (as it usually is) or a reference to an array of values. When creating the wrapper, instead of

destAddr => '192.168.0.1'

we would have

destAddr => ['192.168.0.1', '192.168.0.2', '192.168.0.3']



Subsections
next up previous contents
Next: Load balancing extra features Up: Future enhancements to ProtoWrap Previous: Signal handling   Contents
Gunnar Wolf
2001-03-12