Client-side Load Balancer using Cloud

ABSTRACT: 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 largescale 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:

chine. which still presents a single point of failure and scalability bottleneck. Propose client-side load balancing architecture: Differing from previous proposals on client-side load balancing. a Java Applet is an application. This is especially true in the mobile environment. so users cannot view applets by default. Last. which is not available by default on most browsers.Existing System: The concept of client side load balancing is not new. leaving open big security vulnerability. First.tails behind the scene. requires modification to the browser. More specifically. if the user accidentally agrees. Second. Java Applets require the Java Virtual Machine. but also overcomes the limitations posed above. a Java Applet could have full access to the client ma. From a user's perspective. Smart Client still relies on a central server to download the Java Applet and the server list. In the rest of the paper. Fourth. Our evaluation shows that our proposed architecture can indeed scale linearly as demand increases. 3. We use JavaScript technology to handle all load-balancing de. developed as part of the WebOS project requires Java Applets to perform load balancing at the client. it is difficult to make sure that the visitors to a web site have the required modification. One existing approach. many organizations only allow administrators to install software. 2. Realistic evaluation: We evaluate the proposed architecture using a realistic benchmark suite. A practical implementation: Previous implementations are not transparent to end users. we show the limitations of cloud to host a web . Given the diversity of web browsers available today. our proposal is built on insights gained from our performance studies of cloud components. Proposed System: we propose a client-side load balancing architecture that not only leverages the strength of existing cloud components. Third. Smart Client. We leverage the strength of a cloud component (S3's scalability) to avoid any single point of scalability bottleneck. We use JavaScript to get around current browsers' cross-domain security limitations. we present the following contributions. Unfortunately. it has several drawbacks. the earlier version of Netscape. 1. the HTML page navigation structure is lost if navigating within the applet. he is not able to distinguish a web site using client-side load balancing from a normal web site.

we present the evaluation results.level of load. DNS Load Balancing: Another well established technique is DNS aliasing.. all browsers contacting the same DNS server would get the same IP address. Second. When a user browses to a domain (e.presence using the standard techniques. it does a poor job in balancing the load. a local DNS server caches the IP address information. However. which will eventually be the original DNS server that the web server farm directly manages.com). the local DNS server guides requests from browsers to the same web server. 1. it seriously affects the scalability of a cloud-based web server farm. e. the browser contacts the IP address. so all communication with the web application hits the load balancer first.8. Thus. then. tweaking DNS server settings has little effect. DNS load balancing has its drawbacks {load balancing granularity and addictiveness {that are not specific to the cloud. The hardware-based load balancer is designed to handle high. the browser first asks its local DNS server for the IP address (e. When traffic fluctuates at a time scale much smaller than days.website. the local DNS server caches IP address for a set period of time. Traditionally. the load balancer forwards packets to different web servers for processing. We then describe our client-side load balancing architecture and implementation.11).g. Since the DNS server could be responsible for a large number of hosts. First. the load could not be effectively smoothed out.g. 209. A cloud-based web server . In case the local DNS server does not have the IP address information for the asked domain. so it can easily scale. The load balancer assumes the IP address of the web application. it contacts other DNS servers that have the information. for days. For performance reasons. Depending on the user Session and the load on each web server. Until the cache expires. The load balancer is connected to one or more identical web servers in the back-end.g. this drawback has not been as pronounced because the number of back-end web servers and their IP addresses are static anyway.231. www. 2.. 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. Load Balancer: A standard way to scale web applications is by using a hardware-based load balancer. Last..

but different layer 2 addresses (MAC address). A browser first establishes a TCP connection with a front-end dispatcher. leaving open big security vulnerability. Last. Days of DNS caching dramatically reduces this elasticity. if the user accidentally agrees. the HTML page navigation structure is lost if navigating within the applet. One way. a Java Applet is an application. 3. Before any data transfer occurs. In addition. all have the same IP address. when a web server fails. Another variation. it has several drawbacks. so users cannot view applets by default. . This is especially true in the mobile environment. Smart Client still relies on a central server to download the Java Applet and the server list. the earlier version of Netscape. Third. One existing approach. the DNS entry could not be immediately up. 4. Smart Client. This technique again requires the ability for the back. a Java Applet could have full access to the client ma. developed as part of the WebOS project requires Java Applets to perform load balancing at the client. First.end servers to masquerade the dispatcher's IP address.end servers. Second. Layer 2 Optimization: There are several variations of layer 2 optimization. referred to as direct web server return. More specifically. works in a slightly different way. which is not available by default on most browsers. which takes over the communication with the client. the dispatcher transfers the TCP state to one of the back.dated. it is difficult to make sure that the visitors to a web site have the required modification. While the DNS changes propagate. Client Load Balancing: The concept of client side load balancing is not new. Fourth. users are not able to access the service even though there are other live web servers. Given the diversity of web browsers available today. Java Applets require the Java Virtual Machine. is to have a set of web servers.chine. TCP handoff. requires modification to the browser. IP addresses for new web servers will not be propagated to DNS servers that already have a cached IP address. many organizations only allow administrators to install software.farm elastically changes the number of web servers tracking the volume of traffic in minute’s granularity. Unfortunately. even though the web server farm increases the number of web servers to serve the peak load. which still presents a single point of failure and scalability bottleneck.

0/6.44 MB Standard Windows Keyboard Two or Three Button Mouse SVGA S/W System Configuration:  Operating System Application Server Front End Scripts Server side Script Database Database Connectivity :Windows95/98/2000/XP : Tomcat5. Jsp : JavaScript. Java. : MyAccess : JDBC.1 Ghz 256 MB(min) 20 GB 1.X : HTML. : Java Server Pages.System Configuration:H/W System Configuration:Processor Speed RAM Hard Disk Floppy Drive Key Board Mouse Monitor - - Pentium –III 1.      .

Sign up to vote on this title
UsefulNot useful