Before configuring your clustered IIS resource, decide whether you want to keep any related data local to each server or whether you will put the data on the shared disk. Both are valid options, and the choice depends on whether you need to maintain dynamic data and how often it changes. For example, a read-only Web site or an FTP site that offered a stable list of files to download would qualify for a local configuration of the data (copied to both servers). If the data changed infrequently, you would need to manually update the other server. However, if the content changed frequently, it would be better to put the data on the shared storage. If you decide to put the data on the shared storage, remember to include the Physical Disk resource in the IIS group and make it a dependency of the IIS Server Instance resource. If you decide to keep the data local to each server (exactly the same location on each) you do not need to include the Physical Disk resource, but you must remember to manage data replication between the two servers. Figure A shows the configuration options available when creating an IIS Server Instance resource. In this example we're clustering a Web site, and the IIS Server drop-down list will display all the configured sites on the server. If you want to cluster a specific site rather than a virtual directory off the Default Web Site, make sure that you configure this in the IIS MMC in advance.
| Figure A |
![]() |
| Configuring a clustered WWW Site |
Using the Cluster Service, you can cluster a couple of IIS Web servers at the application level instead of using NLB to cluster large numbers of servers at the network level. This can be especially useful for a departmental intranet server that is crucial for business productivity but that does not get a ton of traffic.
Tech Update forum. Find out what's where in the new Tech Update with our
Guided Tour. Let the editors know what you think in the
Mailroom.







