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.)
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:
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.
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:
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 |