Administering an ISP Installation
Administering an ISP Installation |
|
With two new Web servers added to your installation, you now have to balance the load of requests among three servers by running Network Load Balancing. The three servers will now appear as one to the client. Because you assign only one IP address to the servers grouped into a cluster, managing the cluster is very easy. To configure a DNS server, you would set up reskit1.microsoft.com with the IP address 172.16.1.10. That IP address represents all of the hosts in the cluster (three servers at this point). To learn how to assign an IP address, see the “Configure TCP/IP Settings” topic in the Windows 2000 online product documentation.
With this configuration, you have changed the topology of the site from one Web server to three. Now you can use the Web Application Stress Tool again to test the application. You should see an immediate improvement in performance. Next, stress the cluster again, but this time with thousands of simulated users, making sure that the site consumes far fewer resources than the single computer running IIS 5.0. If the application demands higher availability, you can add more hosts, up to a total of 32.
In addition to building a cluster, another way to improve reliability is to bar customers from writing to the production Web servers (also called end-point servers). Set up a staging server (domain.com, for example), where customers can publish content and test their applications. You can then relegate all authoring and development to the staging server.
If you install FrontPage Server Extensions on the staging server (domain.com), customers can then connect with FrontPage to the staging server, write content, and create applications without bringing an application down on the production Web servers.
Once the data is ready for production, use the Content Deployment feature of Site Server 3.0 to replicate the data from the staging server to the production Web servers. The only element of replication that must be the same across the three Web servers is the Web content. When you need to replicate data, Content Deployment, which is very easy to implement, will save you a lot of time.
As your site grows, you might need a separate log file for each server. If you have three servers in a Web cluster, therefore, you would have to analyze three individual log files, presumably by importing all of them into one source to help simplify the task. The Site Server Usage Analyst offers you an easy way to import these files into a source. You can then generate custom reports representing all the traffic on a Web site.
For even more reliability and availability, you can add another cluster and restrict it to business clients only. In the figure at Creating a Three-Tier Web Cluster, this cluster was called reskit.premium.com. The strategy here is to divert mission-critical business requests to reskit.premium.com, while leaving reskit.microsoft.com for the general public.
Once you have added servers, created a staging server, and simplified logging, you will notice that the site has become quite complex. To handle the increasing complexity and increased number of applications, you will probably need to build a second tier, in order to maintain the availability and performance of the Web site.