Client Side Load Balance Using Cloud

To get this project's source code, synopsis, video, documentation and ppt,

Mail Us at:
info@ocularsystems.in

or

Visit Us:
http://blog.ocularsystems.in/blog

Web applications’ traffic demand fluctuates widely and unpredictably. The common practice of provisioning a fixed capacity would either result in unsatisfied customers (under provision) or waste valuable capital investment (overprovision). By leveraging an infrastructure cloud’s on-demand, pay-per-use capabilities, we finally can match the capacity with the demand in real time. This paper investigates how we can build a large-scale web server farm in the cloud. Our performance study shows that using existing cloud components and optimization techniques, we cannot achieve high scalability. Instead, we propose a client-side load balancing architecture, which can scale and handle failure on a milli-second time scale. We experimentally show that our architecture achieves high throughput in a cloud environment while meeting QoS requirements.

Algorithm / Technique used:

     Load Balancing Algorithm

System Architecture:

Existing System:

The concept of client side load balancing is not new. One existing approach, the earlier version of Netscape, requires modification to the browser. Given the diversity of web browsers available today, it is difficult to make sure that the visitors to a web site have the required modification. Smart Client, developed as part of the WebOS project requires Java Applets to perform load balancing at the client. Unfortunately, it has several drawbacks. First, Java Applets require the Java Virtual Machine, which is not available by default on most browsers. This is especially true in the mobile environment. Second, if the user accidentally agrees, a Java Applet could have full access to the client ma- chine, leaving open big security vulnerability. Third, many organizations only allow administrators to install software, so users cannot view applets by default. Fourth, a Java Applet is an application; the HTML page navigation structure is lost if navigating within the applet. Last, Smart Client still relies on a central server to download the Java Applet and the server list, which still presents a single point of failure and scalability bottleneck.

Proposed System:

we propose a client-side load balancing architecture that not only leverages the strength of existing cloud components, but also overcomes the limitations posed above. More specifically, we present the following contributions.

1. Propose client-side load balancing architecture: Differing from previous proposals on client-side loadbalancing, our proposal is built on insights gained from our performance studies of cloud components. Weleverage the strength of a cloud component (S3′s scalability) to avoid any single point of scalability bottleneck.

2. A practical implementation: Previous implementations are not transparent to end users. We use JavaScript technology to handle all load-balancing de- tails behind the scene. From a user’s perspective, he is not able to distinguish a web site using client-side load balancing from a normal web site. We use JavaScript to get around current browsers’ cross-domain security limitations.

3. Realistic evaluation: We evaluate the proposed architecture using a realistic benchmark suite. Our evaluation shows that our proposed architecture can indeed scale linearly as demand increases. In the rest of the paper, we show the limitations of cloud to host a web presence using the standard techniques. We then describe our client-side load balancing architecture and implementation. Last, we present the evaluation results.

1. Load Balancer:

A standard way to scale web applications is by using a hardware-based load balancer. The load balancer assumes the IP address of the web application, so all communication with the web application hits the load balancer first. The load balancer is connected to one or more identical web servers in the back-end. Depending on the user Session and the load on each web server, the load balancer forwards packets to different web servers for processing. The hardware-based load balancer is designed to handle high- level of load, so it can easily scale.

2. DNS Load Balancing:

Another well established technique is DNS aliasing. When a user browses to a domain

(e.g., www.website.com), the browser first asks its local DNS server for the IP address (e.g., 209.8.231.11), then, the browser contacts the IP address. In case the local DNS server does not have the IP address information for the asked domain, it contacts other DNS servers that have the information, which will eventually be the original DNS server that the web server farm directly manages. The original DNS server can hand out different IP addresses to different requesting DNS servers so that the load could be distributed out among the servers sitting at each IP address.

DNS load balancing has its drawbacks {load balancing granularity and addictiveness {that are not specific to the cloud. First, it does a poor job in balancing the load. For performance reasons, a local DNS server caches the IP address information. Thus, all browsers contacting the same DNS server would get the same IP address. Since the DNS server could be responsible for a large number of hosts, the load could not be effectively smoothed out.

Second, the local DNS server caches IP address for a set period of time, e.g., for days. Until the cache expires, the local DNS server guides requests from browsers to the same web server. When traffic fluctuates at a time scale much smaller than days, tweaking DNS server settings has little effect. Traditionally, this drawback has not been as pronounced because the number of back-end web servers and their IP addresses are static anyway. However, it seriously affects the scalability of a cloud-based web server farm. A cloud-based web server farm elastically changes the number of web servers tracking the volume of traffic in minute’s granularity. Days of DNS caching dramatically reduces this elasticity. More specifically, even though the web server farm increases the number of web servers to serve the peak load, IP addresses for new web servers will not be propagated to DNS servers that already have a cached IP address. In addition, when a web server fails, the DNS entry could not be immediately up- dated. While the DNS changes propagate, users are not able to access the service even though there are other live web servers.

3. Layer 2 Optimization:

There are several variations of layer 2 optimization. One way, referred to as direct web server return, is to have a set of web servers, all have the same IP address, but different layer 2 addresses (MAC address).

Another variation, TCP handoff, works in a slightly different way. A browser first establishes a TCP connection with a front-end dispatcher. Before any data transfer occurs, the dispatcher transfers the TCP state to one of the back- end servers, which takes over the communication with the client. This technique again requires the ability for the back- end servers to masquerade the dispatcher’s IP address.

4. Client Load Balancing:

The concept of client side load balancing is not new. One existing approach, the earlier version of Netscape, requires modification to the browser. Given the diversity of web browsers available today, it is difficult to make sure that the visitors to a web site have the required modification. Smart Client, developed as part of the WebOS project requires Java Applets to perform load balancing at the client. Unfortunately, it has several drawbacks. First, Java Applets require the Java Virtual Machine, which is not available by default on most browsers. This is especially true in the mobile environment. Second, if the user accidentally agrees, a Java Applet could have full access to the client ma- chine, leaving open big security vulnerability. Third, many organizations only allow administrators to install software, so users cannot view applets by default. Fourth, a Java Applet is an application; the HTML page navigation structure is lost if navigating within the applet. Last, Smart Client still relies on a central server to download the Java Applet and the server list, which still presents a single point of failure and scalability bottleneck.

System Configuration:-

H/W System Configuration:-

• Processor                      -     Pentium III
• Speed                                -    1.1 Ghz
• RAM                                 -    256  MB(min)
• Hard Disk                          -   20 GB
• Floppy Drive                     -    1.44 MB
• Key Board                         -    Standard Windows Keyboard
• Mouse                                -    Two or Three Button Mouse
• Monitor                              -    SVGA

 S/W System Configuration:-

§  Operating System            :Windows95/98/2000/XP

§  Application  Server          :   Tomcat5.0/6.X                                               

§  Front End                          :   HTML, Java, Jsp

§   Scripts                                :   JavaScript.

§  Server side Script             :   Java Server Pages.

§  Database                            :   MyAccess

§  Database Connectivity      :   JDBC.