Deployment Issues

Updating applications that don't use global ISAPI filters or COM+ components is not problematic in most cases. The primary operational decision that you'll face is whether to continue serving stale content for a brief period or cause a temporary lapse in server availability. This case is noted in two of the deployment scenarios that we've provided. (See "Deploy a New Applicationto a Web Cluster" in this chapter.)

Deploying Global ISAPI Filters

The .dll files for ISAPI filters are replicated by automatic or manual synchronization, so it's not absolutely necessary to deploy them to each cluster member as in the case of COM+ applications. However, if you choose not to use the deployment wizard for ISAPI filters, you may need to restart the Web Service on each cluster member after the filter is installed.

As a general practice, the steps you need to take in deploying global ISAPI filters are:

• On the controller, disable automatic synchronization.
• Deploy the application to the controller.
• Set the cluster members offline for load balancing.
• Synchronize the cluster.

If you use the New Deployment Wizard to deploy the Default Web Site and select the check box for deploying global ISAPI filters, Application Center replication automatically drains, sets offline, restarts IIS on, and then sets online each target.

Deploying COM+ Applications

The deciding factor in determining how to deploy a COM+ application in either a single or a multi-tier situations is whether or not the COM+ application is new or an update to an existing application on the cluster(s). In the case of the former, the FMStocks 2000 deployment scenario described in "Deploy a New Application to a WebCluster," later in this chapter, provides a guideline for deploying this type of application.

Updating an application that contains COM+ components is more complex, particularly when CLB is used and some of the components are hosted on a COM+ cluster. You have to develop a deployment strategy that considers the following questions:

• Does the update include changes to both the ASP pages and components or only the components?
• Can the new version and the old version of the application operate side by side without conflicts?
• Are the new component interfaces backwards compatible, which is to say, can the existing pages call both sets of components?
• Is it necessary to manipulate the Web server routing list so that new calls are not made to old components?
• Are all the component calls coming from the Web cluster or are there also calls being made by other servers and/or clients running the Microsoft Win32 API?

You have three options for installing COM+ application updates. You will have to determine which is appropriate for your organization's operational requirements. The advantages and disadvantages of these options are summarized in Table 8.6.

Scheduled Maintenance

If you are already using scheduled maintenance with brief down times, this is the simplest approach. Take your clusters down, apply the updates, and then bring your clusters back online.

Cluster Mirroring

If 7-day/24-hour is an operational requirement, cluster mirroring is a viable alternative. In this case you would create a mirror of your production cluster. You would install and test all the updates on the mirrored cluster, and then, when the applications are ready to go live, switch your traffic over from the production cluster to the mirror.

Phased Deployment

A phased deployment, similar to our "Deploy a New Applicationwith COM+ Components to Two Tiers" scenario later in this chapter, is only feasible if the updates are such that you are, in effect, deploying a new application. In other words, you have changes across the application that include ASP pages and COM+ applications. The COM+ applications are either fully backward compatible or have been renamed and will not be called by the existing application. Of the three deployment options, this is the most difficult and vulnerable.

Table 8.6 Comparison of COM+ Application Deployment Options

Option	Advantage	Disadvantage
Scheduled maintenance	Simple	Downtime
Cluster mirroring	Provides maximum redundancy	Under-utilized server resource
Phased deployment	Least amount of downtime	Complex process to implement