Deploying application updates to the Web tier has to be handled differently, depending on whether or not your updates involve COM+ components.
To deploy updated HTML-based and ASP-based applications, you should use a phased-deployment strategy. This involves deploying the modified application to part of the cluster first, and then deploying it a second time to members that weren't updated in the first pass.
NOTE
Staged deployment for application updates in this case make sense only if:
- The Web site is very large and only small portions of the site require updating.
- Page version control and consistency are major considerations.
Let's use the Web Guide application as an example, with the cluster illustrated in Figure 8.16 as our target cluster. (For testing purposes we made some changes to some of the HTML pages.)
NOTE
Because none of the graphics in the Web Guide application were altered, this update scenario provided an opportunity to test the exclusions aspect of synchronization. We opened the Synchronizations Properties dialog box, and then under GUIDE, added the Images directory to the exclusion list.
Use the following steps to deploy the updated files for the Web Guide application.
This completes the first phase of the deployment.
NOTE
You have two choices at this point in the deployment:
- If you want to ensure that stale content isn't served to your clients, you should execute the next two steps in their sequence (step 3, step 4). However, there will be several seconds when the site may not be available to service client requests. For high traffic sites, notify users that site maintenance is in process and that they might experience a disruption of service.
- If uninterrupted service is your operational priority, you should bring online the members with the refreshed content before setting the remaining member(s) offline. In this case, execute step 4 before step 3.
In addition to draining the existing connections, this action ensures that this member does not accept any new requests.
Because this deployment scenario is for an application that contains COM+ components, you must restart the target(s). Therefore, you'll have to handle this case slightly differently. Let's use the Pre-Flight Check application as an example.
NOTE
The assumption made for this scenario is that the component interfaces are backwards compatible with the old components and the existing ASP pages can call either set of components without errors.
The process for deploying ACPFApp Update is similar to the one we've described for the Web Guide; however, there is one notable difference that affects our deployment strategy. Because ACPFApp contains COM+ components that have to be installed and registered on the targets, we can't use controller synchronization to update the application for the remaining part of the cluster after we've done the initial deployment.
Instead, we have to deploy the application to each member, as well as the controller. Figure 8.17 illustrates how we deployed ACPFApp to the Web cluster. As you will note, we used two deployments from the stager to install the application on all the targets. The first deployment was to the controller and the member ACDW802AS, and the second was to the remaining member, ACDW518AS.
Figure 8.17 Deploy dynamic content and components to the Web tier
We'll step through this deployment in detail shortly. But first, let's create a subset to illustrate how you can stage and deploy parts of an application rather than replicating unnecessary files across the network.
Create the ACPFApp Update Application
The first thing we have to do is mark the components for load balancing by running the PFSetupCOMDLB.bat batch file (in the ACPF directory). Next, create a new application that identifies the COM+ applications (AC_PF_VB and AC_PF_VC) as its resources.
Now that the application update is ready, we can deploy it to the members on the target cluster. (Once again, we activated the PreFlight Check script in WAS and ran it against the Web cluster to simulate a load while deploying the application.)
We deployed the ACPFCOM application by using the following steps. (Use Figure 8.17 as a reference for this operation.)
CAUTION
If you previously installed the Pre-Flight application's COM+ applications on the target by using the batch files that are provided, make sure that you remove these applications before proceeding with deployment. The reason for this is that the components on the target and stager will have different program identifiers but the same name.
NOTE
Once again, you have to decide which is a priority, serving stale content or briefly interrupting service. This will determine the ordering for the next two steps.
You can use the preceding technique for larger clusters—the basic approach is the same, take approximately one-half of the members out of the load-balancing loop, and then deploy the application to them. Bring the members back online, and then deploy to the remaining members (after you set them offline for load balancing).