The HAS Architecture: A Highly Available and Scalable Cluster Architecture for Web Servers

Transcription

1 The HAS Architecture: A Highly Available and Scalable Cluster Architecture for Web Servers Ibrahim Haddad A Thesis in the Department of Computer Science and Software Engineering Presented in Partial Fulfillment of the Requirements For the Degree of Doctor of Philosophy at Concordia University Montréal, Québec, Canada March 2006 Ibrahim Haddad, 2006

2 This is to certify that the thesis prepared CONCORDIA UNIVERSITY SCHOOL OF GRADUATE STUDIES By: Entitled: and submitted in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY (Computer Science and Software Engineering) complies with the regulations of the University and meets the accepted standards with respect to originality and quality. Signed by the final examining committee: Chair External Examiner External to Program Examiner Examiner Thesis Supervisor Approved by Chair of Department or Graduate Program Director 2006 Dr. Nabil Esmail, Dean Faculty of Engineering and Computer Science ii

3 Abstract The HAS Architecture: A Highly Available and Scalable Cluster Architecture for Web Server Ibrahim Haddad, Ph.D. Concordia University, 2006 This dissertation proposes a novel architecture, called the HAS architecture, for scalable and highly available web server clusters. The prototype of the Highly Available and Scalable Web Server Architecture was validated for scalability and high availability. It provides non-stop service and is able to maintain the base line performance of approximately 1000 requests per second per processor, for up to 16 traffic processors in the cluster, achieving close to linear scalability. The architecture supports dynamic traffic distribution using a lightweight distribution scheme, and supports connection synchronization to ensure that web connections survive software or hardware failures. Furthermore, the architecture supports different redundancy models and high availability capabilities such as Ethernet and NFS redundancy that contribute in increasing the availability of the service, and eliminating single points of failures. This dissertation presents current methods for scaling web servers, discusses their limitations, and investigates how clustering technologies can help overcome some of these challenges and enables the design of scalable web servers based on a cluster of workstations. It examines various ongoing research projects in the academia and the industry that are investigating scalable and highly available architectures for web servers. It discusses their scope, architecture, provides a critical analysis of their work, presents their advantages and drawbacks, and their contributions to this dissertation. The proposed Highly Available and Scalable Web Server Architecture builds on current knowledge, and provides contributions in areas such as scalability, availability, performance, traffic distribution, and cluster representation. iii

4 Acknowledgments The work that has gone into this thesis has been thoroughly enjoyable largely because of the interaction that I have had with my supervisors and colleagues. I would like to express my gratitude to my supervisor Professor Greg Butler, whose expertise, understanding, and patience, added considerably to my graduate experience. I appreciate his vast knowledge and skills in many areas, and his encouragement that provided me with much support, guidance, and constructive criticism. I would like to thank the other members of my committee, Professor J. William Atwood, Dr. Ferhat Khendek, and Professor Thiruvengadam Radhakrishnan for the assistance they provided at all levels of the project. The feedback I received from members of my committee as early as during my doctoral proposal was very important and had influence on the direction of the work. I also would like to acknowledge the support I received from Ericsson Research granting me unlimited access to their remarkable research lab in Montréal, Canada. I would also like to thank and express my gratitude to my wife, parents, brother, and sister for their love, encouragement, and support. Ibrahim Haddad March 2006 iv

5 Table of Contents Abstract...iii Acknowledgments...iv Table of Contents...v List of Figures...viii List of Tables...xi Chapter 1 Introduction and Motivation Internet and Web Servers The Need for Scalability Web Servers Overview Properties of Internet and Web Applications Study Objectives Scope of the Study Thesis Contributions Dissertation Roadmap...14 Chapter 2 Background and Related Work Cluster Computing SMP versus Clusters Cluster Software Components Cluster Hardware Components Benefits of Clustering Technologies The OSI Layer Clustering Techniques Clustering Web Servers Scalability in Internet and Web Servers Overview of Related Work Related Work: In-depth Examination...46 Chapter 3 Preparatory Work Early Work Description of the Prototyped Web Cluster Benchmarking Environment Web Server Performance LVS Traffic Distribution Methods...70 v

6 3.6 Benchmarking Scenarios Apache Performance Test Results Tomcat Performance Test Results Scalability Results Discussion Contributions of the Preparatory Work Chapter 4 The Architecture of the Highly Available and Scalable Web Server Cluster Architectural Requirements Overview of the Challenges The HAS Architecture HAS Architecture Components HAS Architecture Tiers Characteristics of the HAS Cluster Architecture Availability and Single Points of Failures Overview of Redundancy Models HA Tier Redundancy Models SSA Tier Redundancy Models Storage Tier Redundancy Models Redundancy Model Choices The States of a HAS Cluster Node Example Deployment of a HAS Cluster The Physical View of the HAS Architecture The Physical Storage Model of the HAS Architecture Types and Characteristics of the HAS Cluster Nodes Local Network Access Master Nodes Heartbeat Traffic Nodes Heartbeat using the LDirectord Module CVIP: A Cluster Virtual IP Interface for the HAS Architecture Connection Synchronization Traffic Management Access to External Networks and the Internet Ethernet Redundancy vi

7 4.26 Dependencies and Interactions between Software Components Scenario View of the Architecture Network Configuration with IPv Chapter 5 Architecture Validation Introduction Validation of Performance and Scalability The Benchmarked HAS Architecture Configurations Test-0: Experiments with One Standalone Traffic Node Test-1: Experiments with a 4-nodes HAS Cluster Test-2: Experiments with a 6-nodes HAS Cluster Test-3: Experiments with a 10-nodes HAS Cluster Test-4: Experiments with an 18-nodes HAS Cluster Scalability Charts Validation of High Availability HA-OSCAR Architecture: Modeling and Availability Prediction Impact of the HAS Architecture on Open Source HA-OSCAR versus Beowulf Architecture The HA-OSCAR Architecture versus the HAS Architecture HAS Architecture Impact on Industry Chapter 6 Contributions, Future Work, and Conclusion Contributions Future Work Conclusion Bibliography Glossary vii

8 List of Figures Figure 1: Web server components... 4 Figure 2: Request handling inside a web server... 5 Figure 3: Analysis of a web request... 5 Figure 4: The SMP architecture Figure 5: The MPP architecture Figure 6: Generic cluster architecture Figure 7: Cluster architectures with and without shared disks Figure 8: A cluster node stack Figure 9: The L4/2 clustering model Figure 10: Traffic flow in an L4/2 based cluster Figure 11: The L4/3 clustering model Figure 12: The traffic flow in an L4/3 based cluster Figure 13: The process of content-based dispatching L7 clustering model Figure 14: A web server cluster Figure 15: Using a router to hide the web cluster Figure 16: Hierarchical redirection-based web server architecture Figure 17: Redirection mechanism for HTTP requests Figure 18: The web farm architecture with the dispatcher as the central component Figure 19: The SWEB architecture Figure 20: The functional modules of a SWEB scheduler in a single processor Figure 21: The LSMAC implementation Figure 22: The LSNAT implementation Figure 23: The architecture of the IP sprayer Figure 24: The architecture with the HACC smart router Figure 25: The two-tier server architecture Figure 26: The flow of the web server router Figure 27: The architecture of the prototyped web cluster Figure 28: The architecture of the WebBench benchmarking tool Figure 29: The architecture of the LVS NAT method Figure 30: The architecture of the LVS DR method Figure 31: Benchmarking results of NAT versus DR Figure 32: Benchmarking results of the Apache web server running on a single processor Figure 33: Apache reaching a peak of 5,903 KB/s before the Ethernet driver crashes Figure 34: Benchmarking results of Apache on one processor post Ethernet driver update Figure 35: Results of a two-processor cluster (requests per second) Figure 36: Results of a four-processor cluster (requests per second) Figure 37: Results of eight-processor cluster (requests per second) Figure 38: Results of Tomcat running on two processors (requests per second) Figure 39: Results of a four-processor cluster running Tomcat (requests per second) Figure 40: Results of an eight-processor cluster running Tomcat (requests per second) Figure 41: Scalability chart for clusters consisting of up to 12 nodes running Apache Figure 42: Scalability chart for clusters consisting of up to 12 nodes running Tomcat Figure 43: The HAS architecture Figure 44: Built-in redundancy at different layers of the HAS architecture Figure 45: The process of the network adapter swap Figure 47: The 1+1 active/standby redundancy model viii

9 Figure 48: Illustration of the failure of the active node Figure 49: The 1+1 active/active redundancy model Figure 50: The N+M and N-way redundancy models Figure 51: The N+M redundancy model with support for state replication Figure 52: The N+M redundancy model, after the failure of an active node Figure 53: the redundancy models at the physical level of the HAS architecture Figure 54: The state diagram of the state of a HAS cluster node Figure 55: The state diagram including the standy state Figure 56: A HAS cluster using the HA NFS implementation Figure 57: The HA-OSCAR prototype with dual active/standby head nodes Figure 58: The physical view of the HAS architecture Figure 59: The no-shared storage model Figure 60: The HAS storage model using a distributed file system Figure 61: The NFS server redundancy mechanism Figure 62: DRDB disk replication for two nodes in the 1+1 active/standby redundancy model Figure 63: A HAS cluster with two specialized storage nodes Figure 64: The master node stack Figure 65: The traffic node stack Figure 66: The redundant LAN connections within the HAS architecture Figure 67: The topology of the heartbeat Ethernet broadcast Figure 68: The CVIP generic configuration Figure 69: Level of distribution Figure 70: Network termination concept Figure 71: The CVIP framework Figure 72: Step 1 - Connection Synchronization Figure 73: Step 2 - Connection Synchronization Figure 74: Step 3 - Connection Synchronization Figure 75: Step 4 - Connection Synchronization Figure 76: Peer-to-peer approach Figure 77: The CPU information available in /proc/cpuinfo Figure 78: The memory information available in /proc/meminfo Figure 79: Example list of traffic nodes and their load index Figure 80: Illustration of the interaction between the traffic client and the traffic manager Figure 81: The direct routing approach traffic nodes reply directly to web clients Figure 82: The restricted access approach traffic nodes reply to master nodes, who in turn reply to the web clients Figure 83: The dependencies and interconnections of the HAS architecture system software Figure 84: The sequence diagram of a successful request with one active master node Figure 85: The sequence diagram of a successful request with two active master nodes Figure 86: A traffic node reporting its load index to the traffic manager Figure 87: A traffic node joining the HAS cluster Figure 88: The boot process of a diskless node Figure 89: The boot process of a traffic node with disk no software upgrades are performed Figure 90: The process of rebuilding a node with disk Figure 91: The process of upgrading the kernel and application server on a traffic node Figure 92: The sequence diagram of upgrading the hardware on a master node Figure 93: The sequence diagram of a master node becoming unavailable Figure 94: The NFS synchronization occurs when a master node becomes unavailable ix

10 Figure 95: The sequence diagram of a traffic node becoming unavailable Figure 96: The scenario assumes that node C has lost network connectivity Figure 97: The scenario of an Ethernet port becoming unavailable Figure 98: The sequence diagram of a traffic node leaving the HAS cluster Figure 99: The LDirectord restarting an application process Figure 100: The network becomes unavailable Figure 101: The sequence diagram of the IPv6 autoconfiguration process Figure 102: A functional HAS cluster supporting IPv4 and IPv Figure 103: A screen capture of the WebBench software showing 379 connected clients Figure 104: The network setup inside the benchmarking lab Figure 105: The benchmarked HAS cluster configurations showing Test-[1..4] Figure 106: The results of benchmarking a standalone processor -- transactions per second Figure 107: The throughput benchmarking results of a standalone processor Figure 108: The number of failed requests per second on a standalone processor Figure 109: The number of successful requests per second on a HAS cluster with four nodes Figure 110: The throughput results (KB/s) on a HAS cluster with four nodes Figure 111: The number of failed requests per second on a HAS cluster with four nodes Figure 112: The number of successful requests per second on a HAS cluster with six nodes Figure 113: The throughput results (KB/s) on a HAS cluster with six four nodes Figure 114: The number of failed requests per second on a HAS cluster with six nodes Figure 115: The number of successful requests per second on a HAS cluster with 10 nodes Figure 116: The throughput results (KB/s) on a HAS cluster with 10 nodes Figure 117: The number of successful requests per second on a HAS cluster with 18 nodes Figure 118: The throughput results (KB/s) on a HAS cluster with 18 nodes Figure 119: The results of benchmarking the HAS architecture prototype Figure 120: The scalability chart of the HAS architecture prototype Figure 121: The possible connectivity failure points Figure 122: The tested setup for data redundancy Figure 123: The modeled HA-OSCAR architecture, showing the three sub-models Figure 124: A screen shot of the SPNP modeling tool Figure 125: System instantaneous availabilities Figure 126: Availability improvement analysis of HA-OSCAR versus the Beowulf architecture Figure 127: The architecture of a Beowulf cluster Figure 128: The architecture of HA-OSCAR Figure 129: The CGL cluster architecture based on the HAS architecture Figure 130: The contributions of the HAS architecture Figure 131: The untested configurations of the HAS architecture Figure 133: The architecture logical view with specialized nodes x

11 List of Tables Table 1: Classification of clusters by usage and functionality...21 Table 2: Characteristics of SMP and cluster systems...22 Table 3: Expected service availability per industry type...24 Table 4: Advantages and drawbacks of clustering techniques operating at the OSI layer...31 Table 5: Web performance metrics...69 Table 6: The results of benchmarking with Apache...78 Table 7: The results of benchmarking with Tomcat...81 Table 8: The possible redundancy models per each tier of the HAS architecture Table 9: The supported redundancy models per each tier in the HAS architecture prototype Table 10: The performance results of one standalone processor running the Apache web server Table 11: The results of benchmarking a four-nodes HAS cluster Table 12: The results of benchmarking a HAS cluster with six nodes Table 13: The results of benchmarking a HAS cluster with 10 nodes Table 14: The summary of the benchmarking results of the HAS architecture prototype Table 15: Input parameters for the HA-OSCAR model Table 16: System availability for different configurations Table 17: The changes made to the Linux kernel to support NFS redundancy xi

12

13 Chapter 1 Introduction and Motivation 1.1 Internet and Web Servers An Internet server is a server that provides services to users over the Internet using the client/server model. We differentiate between the various flavors of Internet servers by the type of services they offer, the characteristics of their workload, degree of high availability, security levels, performance, throughput, and response times. A web server is one specialization of Internet servers. A web server is a client/server program that uses the Hypertext Transfer Protocol (HTTP) to serve static and dynamic contents to web users. We use web servers as a case study throughout this dissertation. In recent years, the interest in and the deployment of scalable and highly available Internet servers has increased rapidly for the wide potential such systems offer. The progress of Internet servers has been feasible, driven by advances in network, software, and computer technologies. However, there are still many challenges to resolve. Scalability is one of the biggest challenges facing Internet servers providing interactive services for a large user base, and it presents itself as a crucial factor for the success or failure of an online service. The scalability of an Internet server refers to its ability to retain performance levels when adding additional resources without requiring architectural changes or technology changes, and without imposing additional overhead. For instance, a web server scales linearly if it continues to be available and functional at consistent speeds as the number of users and requests continues to grow to high numbers. As long as the web server continues to provide consistent performance in the face of rising demand, then it is scalable. For instance, a web server is able to serve up to 1,000 requests per second with a single processor (Section 3.7). If we double the number of processors, then each processor in the cluster should theoretically be able to maintain a 1,000 request per second per processor, and the cluster serving 2,000 requests per second, achieving linear scalability. The common strategy in measuring server scalability is to measure throughput as the number of users or traffic increases and identify important trends. For instance, we measure the throughput of the server with 100 concurrent transactions, then with 1,000, and then with 10,000 transactions. We then examine how throughput changes and observe how it compares with linear scalability. This comparison gives us a measure of the scalability of the architecture. 1

14 To measure scalability, we need to benchmark and measure the performance of the web server. Benchmarks operate on a real system or a working prototype. A benchmark is a publicly defined procedure, designed to evaluate the performance of a web server system using a well-defined and standardized workload model. The web server benchmark is a mechanism that generates a controlled stream of web requests with standard metrics and aims at reproducing as accurately as possible the characteristics of real traffic patterns, and reports the results. The main goals of benchmarking are: to measure the performance and scalability of request dispatching algorithms and request routing mechanisms, to assess the impact of changes in the information system such as the system architecture and the distribution of content and services, and to help tune the system configuration. Furthermore, benchmarking helps evaluate the system capacity and response time with respect to an existing, expected, or standardized workload. The common metrics for web server performance include throughput, connection rate, request rate, reply rate, error rate, connect time, latency time, and transfer time. Section 3.4 discusses the metrics for web server performance. 1.2 The Need for Scalability The explosive growth of the Internet in the last few years has given rise to a vast range of new online services. Current Internet services span a diverse range of categories that require significant computational and I/O resources to process each request. Furthermore, exponential growth of the Internet population is placing unprecedented demands upon the scalability and robustness of these services [1][2]. Yahoo!, for instance, receives over 1.2 billion page views a day [3], while AOL s web caches service over 10 billion hits daily [4]. Internet services have become critical both for driving large businesses as well as for personal productivity. Global enterprises are increasingly dependent upon Internet-based applications for e- commerce, supply chain management, human resources, and financial accounting, while many individuals consider and web access to be indispensable. This growing dependence upon Internet services underscores the importance of their availability, scalability, and ability to handle large loads. Popular web sites such as ebay [5], Excite [6], and E*Trade [7] have, at times, experiences costly and high profile outages during periods of high load. As more people rely upon the Internet for managing financial accounts, paying bills, and potentially even voting in elections, it is increasingly important that these services are available at all times, perform well under high demand, 2

15 and are robust to accommodate to rapid changes in load. Furthermore, the variations of load experienced by web servers intensify the challenges of building scalable and highly available web servers. It is not uncommon to experience more than 100-fold increases in demand when a web site becomes popular [8]. When the terrorist attacks on New York City and Washington DC occurred on September 11, 2001, Internet news services reached unprecedented levels of demands. CNN.com, for instance, experienced a two-and-a-half hour outage with load exceeding 20 times the expected peak [8]. Although the site team managed to grow the server farm by a factor of five by borrowing machines from other sites, this arrangement was not sufficient to deliver adequate service during the load spike. CNN.com came back online only after replacing the front page with a text-only summary in order to reduce the load [9]. Web sites are also subject to sophisticated denial-of-service attacks, often launched simultaneously from thousands of servers, which can knock a service out of commission. Denial-ofservice attacks have had a major impact on the performance of sites such as Yahoo! and whitehouse.gov [10]. The number of concurrent sessions and hits per day to Internet sites translates into a large number of I/O and network requests, placing enormous demands on underlying resources. 1.3 Web Servers Overview Web servers are a specialization of a server providing services over the Internet. The following subsections describe the functions of a web server, present on the HTTP [11] request and reply cycle, and discuss the protocol performance issues Web Server Definition A web server, sometimes called HTTP server, is a program that responds to an incoming TCP connection, and provides a service to the requester. Its primary purpose is to provide data using the HTTP [11]. There are many variants of web servers for different operating system platforms. Figure 1 illustrates the three core components of a web server: the web server software, a computer system with a connection to the Internet, and the information or documents that are available for serving. In this dissertation, the term web server refers to the whole entity, computer platform, server software, and the documents. 3

16 Web Server Machine Disk Storage Web Clients Apache Web Server Software Network Figure 1: Web server components Functions of a Web Server The primary function of a web server is to service requests made over the HTTP. The web server receives a request asking for a specific resource, a document for instance, and then it returns the resource as a response to the web client. A web server consists of several internal components. Each component is responsible for imparting certain functionality to the whole system. These components work in tandem, as well as with other external components. The web server software is composed of a stream manager, a HTTP server, and a path resolver. These internal components to the web server software interact with external components, such as the common gateway interface (CGI) [12] and the file system. The file system is the main source of information of a web server where data resides. The CGI provides an interface where the use of scripts empowers the server to compute request specific information; it allows the web clients to view documents created at run time. The data flow in the server from the time a request enters the server until the server sends the output back to the client follows a cycle called the data flow cycle. Figure 2 illustrates how a web server handles an incoming web client request. The stream manager is the first contact point for a web client with the web server. When a client sends a request to a server (1), it docks on to the stream manager. A client might reference a file in its request, and as a result, the web server returns that file to the client. A client can also request a program, a CGI script for instance, and the web server launches that program and returns the resulting output to the client. The stream manager decodes the request (2) and pushes the request to the HTTP server module. The HTTP server is the layer between the server and the underlying operating system. It provides the necessary functionality to gain access to the file system, either by connecting directly by making system calls to it or through the CGI. The HTTP 4

17 server decodes the path of the request from the uniform resource locator (URL) of the request (3) using the path resolver. Next, the HTTP server authenticates the user using the access list, which stores all the authorized users. On a successful authentication (4), the HTTP server accesses the file system (5). Depending on the request type, the web server either retrieves a resource from the file system, or executes a new program in a separate process. In both cases, the result of the above operation is written on an output stream and passed on to the client via a stream manager (6). Native File System CGI 5 3 Web Client 1 6 Stream Manager 2 HTTP Server Path Resolver Access List 4 Figure 2: Request handling inside a web server Web Server hosting Web Object 5 Users Users 4 HTTP Request Local DNS Server Authoritative DNS Server for Figure 3: Analysis of a web request Figure 3 illustrates the two main phases that a web request goes through from outside the web server: the lookup phase includes steps (1), (2), and (3), and the request phase includes steps (4) and (5). 5

18 When the user requests a web site from the browser in the form of a URL, the request arrives (1) to the local DNS server who consults (2) the authoritative DNS server responsible for the requested web site. The local domain name system (DNS) server then sends back (3) the IP address location of the web server hosting the requested web site to the client. The client requests (4) the document from the web server using the web server s IP address and the web server responds (5) to the client with the requested web document. Web servers should cope with the numerous incoming requests using minimum system resources. They have to be multitasking to deal with more than one request at a time. They provide mechanisms to control access authorization and ensure that the incoming requests are not a threat for the host system, where the web server software runs. In addition, web servers respond to error messages they receive, negotiate a style and a language of response with the client, and in some cases run as a proxy server. Web servers generate logs of all connections for statistics and security reasons The HTTP Request and Reply Cycle Web servers follow the client/server model, where a client sends a request to the server and the server replies to the client. This cycle is called the HTTP request and reply cycle. This section illustrates the steps that take place in a HTTP request and response cycle. The web server, running as a background process, listens on a specific port for requests addressed to it; the default port where web servers listen to incoming connections is port 80. A HTTP request arrives from a client to the web server. The request includes the information needed by the web server to decide what to do with the request. The web server reads the request and parses it to determine how to handle it. The web server tries to fulfill the request. If the client is requesting a document, the web server locates the document on the disk. Each web server has a repository of data that each request accesses. If there is only one copy of the data, then all concurrently processed requests funnel through the one database of documents. The web server sends a response to the client, which is in this case the requested document. Finally, the web server cleans up by closing open files and terminates the network connection. This cycle illustrates how a web server handles one request per connection. With the newer version of the HTTP, HTTP version 1.1, the protocol sets up a persistent connection between the web client and the web server, which stays open and allows the web client to send multiple requests. The operating system completes several parts of the HTTP request and reply cycle such as creating a new process to 6

19 handle an incoming request, reading from the network, looking up the requested document, reading the document from disk, and writing the document onto the network Web Servers Requirements This section discusses the requirements of a highly available and scalable web server related to this dissertation such as minimal response time, fast processing of requests, high availability, and reliability. - Minimal response time: A crucial factor in the success of a web service is the response time experienced by the web user. The server has to minimize response times to meet the expectations of the users. Research on a wide variety of web systems has demonstrated that users require response times of less than one second when moving from one page to another when browsing the web [13]. Traditional human factors research into response times confirmed the need for response time faster than one second. The general guidelines regarding response times has been about the same for almost thirty years [14][15]: > 0.1 second is the approximate limit for having the user feel that the system is reacting instantaneously, meaning no special feedback is necessary to display the result. > 1.0 second is the approximate limit for users flow of thought to remain un-interrupted, even if the user notices the delay. Normally, no special feedback is necessary during delays of more than 0.1 second and less than 1.0 second, but the user does lose the feeling of operating directly with the data. > 10 seconds is the approximate limit for keeping the attention of the user focused on the dialogue. For longer delays, users want to perform other tasks while waiting for the computer to finish, so they expect some feedback indicating when the computer expects to finish. Feedback during the delay is especially important if the response time is likely to be highly variable, since users do not know what to expect. - Fast processing capability: In a distributed environment, several factors introduce delays that lessen the speed of processing of a web request, and the speed in which the traffic is distributed among the servers within the web cluster. Therefore, a fast and lightweight traffic distribution mechanism can help speed up processing time of web requests. - Reliability and availability: Web servers need to be reliable and highly available. As the number of users and the volume of data handled increases, it becomes difficult to guarantee web server 7

20 reliability and availability. Therefore, web servers should deploy hardware and software faulttolerance and redundancy mechanisms to ensure reliability, to prevent single points of failure, and to maintain availability in case of a hardware or software failure. - Ability to sustain a guaranteed number of connections: This requirement entails the web server to maintain a minimum number of connections per second and to process these connections simultaneously. The ability to sustain a guaranteed number of connections, also described as maintaining the base performance, has a direct effect on the total number of requests the web server can process at any point in time. - High storage capacity: Web servers provide I/O storage capacity to store data and a variety of information it is hosting. In addition, with the increased demand on multimedia data, requiring fast data retrieval is an essential requirement. - Cost effectiveness: An important requirement governing the future of web servers is their cost effectiveness. Otherwise, the cost per transaction increases as the number of transactions increase, and as a result, the cost becomes an important factor governing which server architecture and software to use in any given deployment case. Designing a high performance and scalable web and Internet server is a challenging task. This dissertation aims to understand what causes scalability problems in the web server cluster and explores how we can scale a web server cluster. The dissertation focuses on the design of next generation cluster architecture to meet the requirements discussed above. The architecture need to be able to scale linearly for up to 16 processors, support service availability, and reliability. The architecture will inherently meet other requirements such as better cluster resource utilization and the ability to handle different types of traffic. 1.4 Properties of Internet and Web Applications To scale the performance of a distributed web server, system designers need to understand its structure and purpose, as well as the characteristics of the provided services and data, for these all affect the architecture and the scaling methods. The three fundamental properties of web applications, also applicable to web servers, are massive concurrency demands, an increasing trend towards complex content, and a need to be extremely robust to load. The following subsections discuss each of these properties. 8