in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 70 >> Next

Figure 3.24: How URL switching works.
Separating Static and Dynamic Content
URL switching can also be used to serve a number of Web sites with the same public VIP address. For example, an ISP hosting personal Web sites for individual users cannot possibly afford to use one public VIP for each individual user because the public IP addresses are a scarce resource these days. While the disk space consumed by each user is limited to a few megabytes, the sheer number of users makes the total disk space consumed too large to fit on a single server. The ISP may use just one or more VIPs and yet service all of the users by taking advantage of URL switching.
Figure 3.25 shows a Web site with one VIP serving many individual user Web sites. Since all of the content can’t fit into one server, let’s divide the content into three equal groups: users whose names start from A to G, H to P, and Q to Z. If we place only each part of the content on a single real server, it becomes a reliability and performance bottleneck. We now need to define a VIP on the load balancer and bind the VIP to all the real servers on port 80. We can now define URL rules on the load balancer to direct all traffic for* through* to server group 1 and so on. The load balancer will distribute the requests for a content group among the real servers in that group. If the response time is poor for a content group, either because of an increase in the number of users in that group or if there are too many visitors, we can simply add another server to that group. Using URL switching in this example, we are able to provide a highly scalable, reliable, and cost-effective Web site with just one public IP address.
Figure 3.25: Using URL switching to serve multiple Web sites.
URL switching can also be used to serve many domain names with just one public IP address. For example, we can service and with one VIP by using URL switching. We need to configure the load balancer to match the host name against news, sports, or stocks and direct the request accordingly. Also, if the news content is too large, we can further divide it by specifying yet another URL rule to identify and and direct the request to the right server group. The granularity of URL switching specification thus varies from one load-balancing product to another.
Separating Static and Dynamic Content
Yet another example of URL switching is to separate the static content from dynamic content in the server farm. Static content consists of all the content that does not change often, such as background color, company logo, and static text. Dynamic content changes very often and may even depend on the requesting user. An example of dynamic content is an account statement on a bank’s Web site that is unique to each individual user and may have to be generated at the time of request. Static content is relatively easy to manage because we publish it onto the server only when there is a change. Dynamic content, on the other hand, requires more frequent updates and may even interface with a database server in the back end to generate the data based on the user request. It makes sense to separate the static and dynamic content onto different server groups so that
URL Switching Usage Guidelines
it can be easily managed. Dynamic content often includes Common Gateway Interface (CGI), Active Server Pages (ASP), or Visual Basic or JavaScript that is executed on the server when the user makes a request. For example, when you go to type load balancing in the search field and press Search, you get the results on the next Web page. The URL of the results page is When we press the search button, the browser requests this URL, where q stands for a script or program on Google’s Web server and the data following the 7 is passed on to the program as input. The program q generates the output based on the input and replies with results, which we see on the search results page.
We need to organize the servers into two groups—1 and 2—that serve static and dynamic content respectively. We need to define URL rules on the load balancer to distinguish and direct dynamic content to server group 2. We can do this by defining URL rules that look for a 7, .cgi, or .asp in the URL and direct those requests to group 2.
URL Switching Usage Guidelines
While URL switching provides us a lot of flexibility in organizing and managing content, it can be unnecessarily complex if all the content can easily fit into one server. When using URL switching, we must take care to define URL rules that exactly match how content is divided among servers. Otherwise, users will get “object not found” errors, as the load balancer may send the request to a server that does not have the right content. Also, URL switching does impact the performance of the load balancer because of the time it takes to search through URLs and process all the specified rules. This is in addition to the overhead of delayed binding. Each rule we specify presents a different workload for the load balancer. In general, a rule that matches the end of a URL string to .asp presents relatively less load than a rule that requires the load balancer to look for cgi anywhere in the URL request; although, in reality this does depend on how URL rule processing is implemented in the load-balancing product.
Previous << 1 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 70 >> Next