Data partitioning in a Web server environment is similar to building a partitioned file system. The primary difference is that you use IIS's Virtual Directories feature instead of Dfs to provide the unified namespace. For example, suppose you have multiple file servers (i.e., FileServer1 FileServer2, and so on), one of which will be the Web server (i.e., FileServer1). You configure the file servers just as you would in a file-server environment, then configure FileServer1 to be your Web server. Next, you use the Internet Services Manager (ISM) tool to publish a series of virtual directories off the root of the Web server. To do so, in ISM, right-click the root of the Web site on \fileserver1 and select New, Virtual Directory. Name the directory (e.g., \products), and identify the directory path for that data as \fileserver2\products. When users access your Web site's root, they can access the Products page as if it were on the root Web server—but the data actually resides on the small back-end FileServer2. The back-end server is small enough for you to restore in less than the allotted time, but the farm appears as one Web site to users.
In the case of a simple file server, you can use server redundancy (which the cluster example in Figure 4 shows) to reduce the frequency of perceived outages. In the case of a Web server, you have an additional option that's roughly equivalent to using Dfs replicas for a fault-tolerant file server. Because you're primarily reading individual document pages in a stateless action, whether subsequent reads take place from one server or another server is irrelevant. Therefore, you can provide a reasonably seamless user experience while you swap servers indiscriminately in the background. You can use Win2K AS's NLB to manage those transitions.
Figure 5 shows a sample Web server farm that contains four identical servers. In this scenario, the best strategy is to simply build redundant servers, all of which contain the entire 200GB of data. To ensure that the data is identical on each server, you might use a service such as Dfs and the Win2K File Replication Service (FRS) to duplicate the information across the servers or use a third-party product to perform this type of replication. In a pure Microsoft environment, you might use the Site Server 3.0 Content Deployment Service or the Application Center 2000 Synchronization Service. Then, you install and configure the NLB service on all the servers so that they share one virtual IP (VIP) address.
When a user connects to the Web server cluster, the NLB service determines which server responds to the user. This determination depends on the NLB configuration. For example, in the case of the http://www.usi.net URL in Figure 5, the /www1.usi.net server might respond. If one of the servers fails, the NLB service simply fills the next user request from one of the remaining servers. The more servers you create, the less likely one server failure will affect your SLA. If you have two servers that handle 50 percent of the user traffic, one server's failure increases the other server's load by 100 percent. If you have five servers, one server's failure increases the load on the other four servers from 20 to 25 percent. As long as you have sufficient redundancy to maintain acceptable user performance while the failed server is offline, you'll meet your SLA by reducing or eliminating the number of outages that the user perceives.
Comparing the cost of using redundancy to enable a high-availability Web server with the cost of data partitioning a file server is interesting. In the scenario in Figure 1, the file servers collectively hold 200GB of available disk space for user data, whereas the scenario in Figure 5 requires that each Web server contain the full 200GB of disk space. Furthermore, in Figure 1, the file servers can be fairly small, regardless of whether you use one or five servers. A Web server, however, is more taxing on CPU capacity and memory; if you have only one Web server, you need a much more powerful machine, such as a ProLiant DL580 with four processors and 2GB of RAM. If you have multiple Web servers, you might be able to get away with the ProLiant DL380 in the example that Figure 1 shows.
Table 4 shows the relative costs. The price of a large server is greater than the price of multiple small servers. One reason for the higher cost is that the ProLiant DL580 needs an external drive chassis. Multiple load-balanced and redundant servers, with a theoretical SLA of 100 percent, are sometimes cheaper than one server that provides no redundancy.
Large public Web sites typically use a combination of technologies to achieve high availability. Figure 6, page 30, shows one method of combining strategies into an environment that boasts numerous high-availability components. The scenario uses redundant load-balanced front-end Web servers, so the user will always be able to connect to the site. Server clustering ensures that a server is always available to handle file-system requests. Finally, to guarantee the availability of data, the system uses a redundant fibre channel fabric for access to an enterprise SAN. Only the number of servers in the front-end and back-end clusters—and any communications components between the client and servers—limit this architecture's availability. For more information about this kind of complex architecture, see the Microsoft article "Web Server Load Balancing and Redundancy" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/ecommerce/deploy/rollout/duwwsr.asp).
Prev. page
1
2
3
[4]
5
next page 
