This page documents our "Loading Balancing Web Proxy" for the comp243 final project.
 

• Project description
• System overview
• Novel Problems to solve
• Professor Smith's suggestions
• Appendix A: Other projects and references

Description [top]

 

Our suggested distributed system is a web proxy load balancing server. Retrieving web content from the web is improved by caching web-pages closer to clients. Load balancing the web proxies has the advantage of scaling the system to more users. We do not expect to improve the performance of retrieving web content but hope to explore the distributed system concepts. In addition, we intend our system to work for organizations such as university departments or companies. 

In a more general context load balancing can be applied to managing limited resources such as printers or distributing computational intensive to appropriate workstations. Our choice of load balancing web proxies is to take advantage web software we have already written in comp 243. As a part of the project, we plan to implement a simplistic and alternative DNS mechanism to query and resolve the address of the proxy in a dynamic way. In our implementation, we will have a number of web proxies that cooperate with an alternative DNS server (ADNS server). The ADNS server communicates with the web proxies and knows their current workload. When receiving a DNS query for web proxy, it "directs" the clients to the proxy with the lowest load. In addition, it would be interesting to think of what environments the DNS server (or other Load balance server) would fail.

The following diagram illustrates the system we hope to build. The area shaded in Carolina blue highlights the components provided by us; elements outside we would interface to.
 
 

The alternative DNS is the most central component. The alternative DNS will point the client request to the lowest loaded proxy. The proxy will retrieve the client's request when the client connects to it.
We are interested in making the alternative DNS fault tolerant as well as the web proxy caches. Using our DNS will only work with our web browser that accounts for the alternative DNS server switching IP addresses when it fails. Existing DNS server do not account for this, such as those used by the web proxies. We do not account for those failing. When a client is started, it sends a multicast message to a pre-defined multicast address to look for an ADNS server. The ADNS server will reply to this query and notify the client of its IP address. 

Novel Problems to Solve [top]

Our main interest is to design the protocol for the alternative DNS to communicate between the web browser on one side and the web proxies on the other side. The protocol must share the state of the web proxies so that the DNS server can redirect the web clients based on the load. The backup alternative DNS server should also maintain the state of the proxies.

In the case the alternative DNS server fails, we would want the backup server to take over and start a new back up server. When the web proxies lose the connection with the ADNS server, they will transmit a multicast message to query for the backup ADNS server at a pre-defined multicast address. If the web proxies do not find an ADNS server after a certain time interval. One of them should spawn an alternative DNS server. This is achieved by having the web proxies back off for a random period of time. The web proxy with the shortest backoff time will spawn the ADNS server. In order to avoid potential problems in dealing with multicast routing/forwarding across routers in colab, hosts for clients, web proxies, and ADNS servers should be in one broadcast domain (e.g., one LAN).

We hope to learn about the DNS protocol that we can implement between the client and alternative DNS server. It would be fun if we could get conventional browsers to use our client (unlikely).

If time permits we will implement a Java web-proxy which would allow us to run on different systems. Presently we plan to implement on Solaris, FreeBSD, and 
Linux. 

• To demonstrate the load balancing scheme: try to make SURGE query the ADNS server. By this way, we can emulate several clients. Some useful information for SURGE can be found here. The site for software download is here.

• Set up a demo where the web proxies have some output to demonstrate their current workload (and thus show that our load balancing scheme really works). Set up a demo where the ADNS server is shut down and show that the back up server is started and takes over the primary server's task. 
• If encouter problems with multicast, simply have a list in a config file to specify on which machines the backup ADNS server is to be started. 

The final project documentation needs to include the information given at: http://www.cs.unc.edu/~smithfd/243f00/Info-final.pdf

Here are some notes. Final written project report is due no later than 5:00PM on Monday, December 18, 2000. The following is a minimal list of topics (mini-outline) that you should cover in your report:

• System services provided (what users can expect the system to do).
• System structure (what processes are involved and how they are distributed over various processors). If there are clients and servers, explain how they are organized.
• Availability and fault-tolerance goals for your system. State which failures are dealt with (and which are not). For each failure (including those you do not deal with), state how your system responds.
• System state (both persistent and volatile state). For any parts of the state that is shared or replicated, state your consistency requirements for that state and how you maintain consistency.
• Protocols used.
• Important distributed system problems taken into consideration and decisions about how to deal with those problems.

• Writing concurrent servers. We have two versions single/multiple processes
• Multicasting/ UDP
• DNS protocol
• System call to make new processes

Appendix A: Other projects and references [top]

• Class sugguestions
• CMU security class
• CMU distributed class (big pdf)
• Portolano (UW)
• University study into load balancing using Surge (boston univ)
• SURGE stands for "Scalable URL Reference Generator"