Chapter 8 - Creating Clusters and Deploying Applications

This chapter provides information about the preferred approaches to creating single and multi-tier clusters, creating a stager, and using a stager to deploy applications to both the Web and component tiers.

The first goal of this chapter is to set up a cluster and staging environment that's similar to the one illustrated in Figure 8.1. The other goal is to show you how to deploy different types of applications to one or both server tiers by using the staging server (stager).

In the architecture shown in Figure 8.1, we have a front-end Web cluster with three servers that can be accessed by both internal and external Web clients. These clients can access only the Web cluster, but the stager can access both clusters to deploy applications. The back-end cluster consists of two component servers that support Component Load Balancing (CLB) by responding to component requests that are routed from the Web cluster.

Figure 8.1 A two-tier cluster and stager environment 

Table 8.1 describes the configuration of each computer that we used in our test clusters. Their capacity should be taken into account when viewing the load testing results that are provided later in this chapter.

Table 8.1 Computer Configurations Used in the Test Clusters 

Name and role	Cluster type	CPU	Memory	Drive capacity
ACDW516AS, controller	Web	1xP6-550	256	2.9 GB
ACDW802AS, member	Web	1xP6-366	256	2.5 GB
ACDW518AS, member	Web	1xP6-550	256	3.0 GB
ACDW522AS, controller	COM+	1xP6-366	256	2.2 GB
ACDW811AS, member	COM+	1xP6-233	256	4.0 GB
ACDW822AS, stager	Web	1xP6-266	128	2.5 GB

On This Page

Setting Up and Testing a Two-Tier Cluster Environment
Setting Up a Stager
Sample Applications for Staging
Deployment Issues
Using a Stager to Deploy Applications
Deploy a New Application to a Web Cluster
Deploy an Application Update to a Web Cluster
Deploy a New Application with COM+ Components to Two Tiers
Resources

Setting Up and Testing a Two-Tier Cluster Environment

We've assumed that you have installed Microsoft Application Center 2000 (Application Center) on several test computers, and that you are familiar with:

• The Application Center user interface. 

• The Registry Editor. 

• The Internet Information Services 5.0 (IIS) and COM+ user interfaces. 

• The Web Application Stress tool (WAS). 

The approach that we're going to take for building our multi-tier environment is to develop the infrastructure in two phases. In phase one we'll build and test the Web tier; in phase two we'll build and test the COM+ application tier.

We'll start by creating a simple Web cluster and running a cross-section of tests to validate the operational consistency of Application Center in this test environment.

Note This section is based on the Pre-Flight Manual, which was developed by the product test team and is included on the Resource Kit companion CD. In addition to the set-up and testing process, they created the sample pages, components, and executables. They've also provided a document named "AC_PreflightCheck.doc" that provides detailed information about the configurations that the team created and tested in the lab.

Build the Web Tier

First we have to create the Web cluster that serves as the front-end tier for a multi-cluster environment. After we've created and tested the Web cluster, we can move on and set up the COM+ applications, or component server cluster. Although you're not restricted to using Microsoft Windows 2000 Network Load Balancing (NLB), we'll use this load-balancing solution on the test cluster.

Create the Load-Balanced Web Cluster

Before starting the cluster creation process, make sure that the following prerequisites have been met.

Prerequisites

In order to create a cluster that uses NLB for load balancing, each server should be running Windows 2000 Server or Windows 2000 Advanced Server; in either case, Service Pack 1 (SP1) and the additional hot fixes need to be installed. These hot fixes are pre-Windows 2000 SP2 and are required for Application Center to run correctly.

Each server must have two network adapters. (See Chapter 5, "Load Balancing.")

The first, or front-end, adapter handles all the public traffic between the cluster members and either Internet or intranet clients. NLB uses the front-end adapter for balancing client requests across the cluster. Since this is the first member we're configuring and it will be the cluster controller, it should have two static IP addresses bound to the adapter. The first IP address is the dedicated, or management, IP address that enables us to communicate directly with each member without using the back-end adapter. The second IP is the cluster IP address—some times referred to as the virtual IP address—which is mapped to the Web site's URL and is common to all the cluster members. All incoming client requests are directed to the cluster IP address.

The second, or back-end, adapter is used for private traffic and outbound traffic to Web clients. Application Center uses this adapter for intra-cluster communications and for supporting its features (such as cluster synchronization) transmitting Application Center heartbeats, and obtaining performance data. This adapter also carries the traffic to back-end databases and/or component servers. In addition to the Application Center cluster services traffic, a typical cluster will access the following network services via the back-end adapter: the domain controller, DHCP server, DNS server, and the Windows Internet Name Service (WINS) server. You can use either static or DHCP-provided IP addresses on the back-end adapter. In this case, we've used an IP address provided by a DHCP server.

The basic cluster configuration looks like the one shown in Figure 8.2, but without the additional member.

Note The configuration in Figure 8.2 does not show additional elements of the network infrastructure, such as switches, routers, hubs, and firewalls. These elements are omitted for the sake of simplicity. All the IP addresses shown are for the purpose of illustration only.

After you've enabled your adapters and bound the IP addresses to them, you can check the adapter configuration by entering the ipconfig command at the Windows 2000 command prompt, and then pressing ENTER. You should get a display that's similar to the one that follows. Notice that we've labeled the two adapters as the "Back-end" and "Front-end"; this isn't required, but it makes it easier to keep track of adapters and their settings in a multi-adapter configuration.

Figure 8.2 Typical network adapter configuration for load-balanced (NLB) cluster members 

D:\>ipconfig
Windows 2000 IP Configuration
Ethernet adapter Back-end:
Connection-specific DNS Suffix . : 
IP Address. . . . . . . . . . . . : 192.168.100.104
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.28.1
Ethernet adapter Front-end:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.100.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.100.102
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.28.1

Create a Web Cluster

Now that the server's been configured to function as a cluster controller, we can create the cluster.

1. Open the Application Center snap-in: click the Windows 2000 Start button, point to Application Center, point to Programs, and then click Administrative Tools. 

2. In the Application Center snap-in, in the console tree, right-click ApplicationCenter, and then click Connect. 

   The Connect to Server dialog box appears. 

3. In the Server name box, enter localhost as the name of the server to connect to and leave the default connection option as Manage cluster for this server, and then click OK. 

   You can identify the server by providing a valid BIOS name, DNS name, or IP address. 

4. The New Server dialog box appears, which gives you the option of creating a new cluster or joining an existing cluster. 

   Note We logged on to the server with an account that has administrative privileges, so it's not necessary to select the Connect as check box and provide administrative credentials. 

5. Create a new cluster, which is what we want to do, is selected by default in the New Server dialog box. 

6. Click OK to launch the New Cluster Wizard. 

7. Step through the New Cluster Wizard pages and provide the information requested in each page. 

Table 8.2 lists the information we provided when creating and configuring our cluster.

Table 8.2 New Cluster Wizard Configuration Information 

Wizard page	Configuration information, comments
Welcome to the New Cluster Wizard	Click Next
Cluster Name and Description	Cluster name: RKWebCluster
Cluster description: A Web cluster.
Cluster Type	Keep default: General/Web cluster
Load Balancing	Keep default: Network Load Balancing (NLB)
Monitoring Notifications	E-mail address: someone@microsoft.com E-mail server name: smarthost
Completing the New Cluster Wizard	Click Next

At the end of this process, we have a cluster named RKWebCluster, consisting of the cluster controller, ACDW516AS, which was our localhost system. (Figure 8.3 shows the Application Center snap-in after adding additional members.) The next thing we want to do is increase the size of the cluster by adding two members.

Figure 8.3 The RKWebCluster 

Secure your server 

A good time to secure the server is after you've created the initial cluster. At this point you can implement some basic security settings for the operating system and the Web server. For information about site hardening and checklists for securing both Windows 2000 and IIS, see Chapter 12, "Security for Administrators and Developers."

As a test to show how Application Center replicates IIS settings, try the following. Open the Internet Information Services snap-in on the cluster controller (ACDW516AS in our test cluster), and set the following for all the Web sites:

• Connections limited to 1,000 

• Bandwidth throttling enabled 

After you add a cluster member, you can check these settings on the member to see if they've been replicated.

The next step in creating our test environment is scaling out the Web tier by adding cluster members.

Add a Member

Adding another server to a cluster only takes a couple of steps. Use Figure 8.3 as a guide for the following steps.

1. Right-click Members, on the pop-up menu, point to All Tasks, and then click Add Cluster Member. 

   The Add Cluster Member Wizard appears. 

2. On the Welcome to the Add Cluster Member Wizard page, click Next. 

3. The Name and Credentials page provides a dialog box for identifying the server that you want to add to the cluster. 

4. You have to provide the name of the computer as well as logon information (User name, Password, and Domain) for an account with administrative privileges on the specified system. (In my test environment, the server I'm adding is ACDW518AS.) When you've finished providing the required information, click Next. 

5. On the Controller Name page, enter the cluster controller name (or localhost), and then click Next. 

   After analyzing the configuration of the target system, the Load Balancing Options page appears. 

6. Accept the page defaults (Set this server to be part of automatic synchronization and Bring the server online after initial synchronization), and then click Next. 

7. On the last page of the Add Cluster Member Wizard, click Finish. 

Application Center replicates all settings to the member, and then the new member adds to the cluster.

At this point we have a two-node Application Center Web server cluster. If you want to add more members, simply repeat the previous procedure.

If you configured the security settings as indicated in the preceding sidebar, you can verify that the controller's settings were replicated to a new member by using the following steps. (Use Figure 8.3 as a guide.)

1. Right-click the IIS node, and then on the pop-up menu, click Connect. 

2. Specify the name of the server to which you want to connect. 

   This action adds the IIS snap-in for the server that you specify. Through the Application Center user interface, you can use the IIS snap-in for every cluster member. 

   Tip You can use this technique to add the Component Services snap-in for each cluster member. On the controller, expand the Component Services node to reveal the Computers folder; right-click, and then when prompted, enter the name of the computer to add. The advantage of adding the snap-ins for cluster members to the controller console tree is that it provides a single interface for managing your cluster. 

3. Open the snap-in for a member, and verify that the settings you established for the cluster controller were replicated when the member was added to the cluster. 

   Figure 8.4, shows the Default Web Site Properties dialog box (Performance tab) for the default Web site on ACDW802AS. Notice that bandwidth throttling, enabled on the controller, was set on the new member. 

   

   Figure 8.4 IIS settings, which are replicated from the controller to a new member 

Validate the Configuration: Visibility

In this validation step, we check to see whether cluster members are visible from within the cluster and from outside the cluster.

Visibility Inside the Cluster

These steps verify server name resolution and connectivity.

From the Controller

1. In Windows 2000, open a command prompt, and then use the ping command to verify the presence of the other cluster members. 

   Each ping should succeed and display results similar to those that follow. 

2. Ping each of the members by using their machine names: 

D:&gt;ping -a acdw802as Pinging ACDW802AS [192.168.100.104] with 32 bytes of data: Reply from 192.168.100.104: bytes=32 time<10ms TTL=128 Reply from 192.168.100.104: bytes=32 time<10ms TTL=128 Reply from 192.168.100.104: bytes=32 time<10ms TTL=128 Reply from 192.168.100.104: bytes=32 time<10ms TTL=128 Ping statistics for 192.168.100.104: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms D:&gt;

The name should resolve to the back-end adapter's (DHCP or static) IP address (boldface in the preceding display). 

3. Ping the controller by using its dedicated IP address. 

4. Ping the virtual IP address. 

From All of the Members

1. On each member, in Windows 2000, open a command prompt, and then use the ping command to verify the presence of each member on the cluster. 

   Each ping should succeed with and display results that are similar to the ones shown in the previous example. 

2. Ping the controller by using its machine name. 

   The name should resolve to the back-end adapter's IP address. 

3. Ping each of the other cluster members by using their computer names. 

   Each name should resolve to the IP address assigned to the corresponding back-end adapter. 

4. Ping the virtual IP address. 

5. Optionally, ping the dedicated IP address on each member's front-end adapter. 

Visibility Outside the Cluster

From an Internal Client

1. On a server outside of the cluster, in Windows 2000, open a command prompt, and then use ping to verify visibility of the cluster members. 

2. Each ping should succeed with the IP address resolution described next. 

3. Ping the cluster controller by using its name. 

4. The name should be resolved to the back-end adapter's IP address. 

5. Ping each member by using its name. 

   Each name should be resolved to the corresponding back-end adapter's IP address. 

From an External Client

1. In Windows 2000, open a command prompt, and then use ping to verify visibility of the cluster members. 

2. Each ping should succeed with the results described next. 

3. Ping the controller by using the dedicated IP address on the front-end adapter. 

4. Ping each member by using the dedicated IP address on the front-end adapter. 

5. Ping the cluster's virtual IP address. 

6. Open Microsoft Internet Explorer, and then make an HTTP request to the cluster controller's dedicated IP address (for example, https://192.168.100.102). 

7. The default Web page for the IIS Default Web Site should be displayed. On a new cluster, such as this one, you should see "This page is under construction". 

8. Update the page several times by pressing F5 to force the client to retrieve the page from the server rather than from the client's local cache. 

9. Repeat the preceding test for each of the cluster members, using their dedicated IP addresses. 

10. As before, the default Web page of the Default Web Site should be displayed with the under construction message. 

11. Update the page several times. 

12. Make an HTTP request to the cluster's virtual IP address, and then do the same by using the cluster's virtual IP. 

13. As before, the default Web page of the Default Web Site should be displayed with the under construction message. 

14. Update the page several times. 

Validate the Configuration: Monitoring

The purpose of this step is to verify that the Application Center monitoring feature works and that the system has access to the logging database via the Microsoft SQL Server Desktop Engine (SQL desktop engine).

Note We've made the assumption that you installed with the monitoring option enabled. If you didn't install this feature, then skip this series of tests and go to "Validate the Configuration: Replication" later in this chapter.

All of the following tests are conducted on the cluster controller by using the Application Center snap-in.

Performance Counters

1. Open the Application Center snap-in; in the console tree, expand the cluster node, and then click on the cluster controller name. 

2. Add three performance counters: Processor Utilization, Web Service GET Requests per second, and ASP Requests per second. 

   The chart generated by these performance counters should be displayed in the details pane for the cluster controller. (See Figure 8.5.) 

   

   Figure 8.5 The RKWebCluster with performance counters added to the cluster controller 

3. Repeat the preceding process for each of your cluster members; add the same counters, and then verify that they are installed. 

4. Finally, click the cluster node (RKWebCluster in our case), and then add the counters. 

   Application Center will take the data from each member and roll it up to plot an average for processor utilization and totals for GET and ASP Requests per second. 

You should get a display similar to the one shown in Figure 8.5 for each of the members.

Events

1. Under the cluster controller name, click Events. 

2. Verify that events from the event log are displayed. 

3. Enter some filters for Product, Type, and Source, as shown in Figure 8.6. 

4. Click Filter to apply these filters. 

5. Verify that the Application Center event system filters the events properly. 

6. Restore the Events view to its initial state. 

7. Click Filter. 

   

   Figure 8.6 Using filters to display ApplicationCenter event information 

8. Repeat the event feature testing on each of the cluster members. 

Monitors

1. Click the cluster controller name, and then click Monitors. 

2. In the Monitors view, click Check Now. 

3. Verify that all the icons for the default monitors are green. 

   Note The default monitors that are installed and enabled by Application Center are:

   • Cluster Service 

   • Health Monitor Action Failure 

   • Memory 

   • Processor 

   • Request Forwarding Failure 

   • Server Offline 

   • Synchronization Session Failure 

   • W3SVC 

4. Repeat this process for each cluster member. 

Validate the Configuration: Replication

In this validation step our goal is to verify that the major replication engines are correctly installed and functioning normally. We will use sample Web pages and COM+ components as part of our testing. First, we have to do some preparation by installing sample files that are located on the Resource Kit CD. If you ran the Resource Kit Setup program, these files are installed in the following default directory:

C:\Program Files\Microsoft Application Center 2000 Resource Kit\Pre-Flight Manual

Preparation

This section describes how to install a simple set of Web pages and COM+ components, how to create a simple virtual Web directory, and how to declare them as Application Center resources. They will be used to perform basic replication tests.

On the Cluster Controller

1. Locate the file named ACPF.EXE in the Pre-Flight Manual folder. This file is a self-extracting ZIP file that contains all the elements for the Pre-Flight application. 

2. Execute ACPF.EXE to the partition where Windows and Application Center are installed. 

   When extracted, ACPF will consist of three folders that contain a collection of Web pages, batch files, configuration files, and executables. You can prepare the cluster controller manually or automate this process by using the batch files that you installed in C:\ACPF directory. (See sidebar.) 

Automated setup 

You can set up the test Web site, COM+ components, and the Application Center application by running the batch files provided on the CD and extracted to C:\ACPF.

1. In Windows 2000, open a command prompt, and then navigate to C:\ACPF. 

2. Create two COM+ applications, and install six components by running: 

C:\ACPF\Files\PFSetupCOM.bat

3. Create a Web virtual directory under the Default Web Site by running: 

C:\ACPF\Files\PFSetupWeb.bat

4. Create the Application Center application (ACPFApp), and then add the COM+ applications, the Web virtual directory, and the application resources by running: 

C:\ACPF\Files\PFSetupAC.bat

Note We recommend the manual approach first to increase your familiarity with the Application Center user interface. Later, you can use the batch files to update configurations on test computers.

Let's step through a manual preparation of the cluster controller. We'll start by creating the two COM+ applications and installing the test components.

In the Application Center snap-in, expand the Component Services node down to, and including, the COM+ Applications folder.

1. Right-click the COM+ Applications folder; on the pop-up menu, point to New, and then click Application. 

2. The COM+ Application Install Wizard appears. 

3. Click Next. 

4. On the Install or Create a New Application page, click Create an Empty Application. 

5. On the Create Empty Application page, for application name, enter AC_PF_VB; for Activation type, use the default setting, Server Application; and then click Next. 

6. On the Set Application Identity page, use the default setting, Interactive user, and then click Next. 

   Warning In a properly secured production environment, you should not use Interactive user but should specify a specific user. For example, Application Center specifies ACL_ servername as the user for its COM+ applications. 

7. On the last wizard page, click Finish to create your new application. 

8. Expand the newly created AC_PF_VB node; right-click the Components folder; and on the pop-up menu, point to New, click Component to launch the COM Component Install Wizard, and then click Next. 

9. On the Import or Install a Component page, click Install new component(s). 

   The wizard opens a file explorer so that you can select the files that you want to install. 

10. Navigate to the C:\ACPF\Components directory, click PFComponent.dll, and then click Open. 

    The files that you selected are displayed in the Install new components page. 

11. Click Next to continue installing the .dll and the PFComp COM+ component. 

12. On the last page of the wizard, click Finish. 

13. Repeat the preceding steps to create a second application named AC_PF_VC, and then install TestCOM.dll in this application. 

Now we'll build the Web application.

1. Expand the IIS node, and then expand the cluster controller node. 

2. Right-click Default Web Site; on the pop-up menu, point to New, and then click Virtual Directory. 

3. On the Virtual Directory Creation Wizard Welcome page, click Next. 

4. On the Virtual Directory Alias page, in the Alias On box, enter ACPFWeb and then click Next. 

5. On the Web Site Content Directory page, click Browse, locate C:\ACPF, identify it as the content directory, and then click Next. 

6. On the Access Permissions page, accept the defaults, select the Write check box, and then click Next. 

7. On the last wizard page, click Finish. 

At this point we have a Web site that contains the pages described in Table 8.3.

Table 8.3 Test Files in the ACPFWeb Site 

File name	Description
PFWelcome.ASP	Creates a simple COM+ component that calls a method to obtain the server name, and then releases the component. It returns and displays a short message containing the name of the server that returned the page.
PFStatic1.HTM through PFStatic5.HTM	This set of static HTML pages is used to display short messages on the screen.
PFDynamic1.ASP through PFDynamic5.ASP	This collection of ASP pages displays a short message as well as the name of the server that returned the page.
PFDynaCOM1.ASP through PFDynaCOM5.ASP	This collection of Active Server Pages (ASP) randomly creates one of five COM+ components, calls a method on the component, and then releases the component. Each page displays a short message and the name of the server that returned the page, as well as the name of the component that was created.

The final step in preparing the controller is to create an Application Center application we can use to identify all of the specific resources that are associated with our test application.

NoteApplication Center applications provide a very useful mechanism for identifying and compartmentalizing application resources for deployment from a stager to multiple cluster tiers.

1. In the console tree, under the cluster node, click Applications, and then in the Applications view, click New. 

2. In the Create a new application dialog box, for the application name, enter ACPFApp, and then click OK. 

3. In the upper part of the Applications view, click ACPF, click the down arrow to the right of Resource Type, click Web Site and Virtual Directories, and then click Add to activate the Add Resource dialog box. 

4. Browse down the Web Sites and Virtual Directories tree until ACPFWeb is displayed, click ACPFWeb, and then click OK to add this resource. 

5. Click the down arrow to the right of Resource Type, click COM+ Applications, and then click Add. 

6. In the Add Resource dialog box, click AC_PF_VB, and then click OK. 

7. Repeat the preceding two steps, and add AC_PF_VC as a COM+ Application resource. 

8. Click the down arrow to the right of Resource Type, click File System Paths, and then click Add. 

9. Use the Add Resource browser to locate the ACPF folder, and then add the ACPF folder to the application resource list. 

Note This resource is not necessary for deploying the Pre-Flight COM+ applications or Web site; however, adding this directory will allow us to test file replication, and there are some scripts in it that will be useful to have on the cluster controller.

When you're finished, your new application and its associated resources will look similar to the one shown in Figure 8.7.

Figure 8.7 The ACPFApp custom application and associated resources 

Note You'll notice that the file system path identified as a resource in Figure 8.7 is pointing to the D drive. This isn't an error or mandatory, it's simply the way the test computers are set up for the cluster RKWebCluster. Although we used different partitions, the drive mappings are homogenous on all our test servers and the drives are NTFS formatted.

Although the controller has been prepared by adding our sample files, we should test our installation before proceeding with testing. We'll use the browser to verify that the site we created is functioning correctly.

On an External Client

1. Open Internet Explorer. 

2. Connect to the controller's Web server by specifying the front-end adapter's dedicated IP address in the following URL: 

   https:// ControllerDedicated IPAddress /ACPFWeb/PFWelcome.asp 

   You should see a screen similar to the one shown in Figure 8.8. 

   

   Figure 8.8 Test page served from the cluster controller 

Now that we know the site's functioning correctly, let's start replication testing with file replication.

File Replication

Manually Synchronize an Application

1. In the console tree, click Applications, and then in the Applications view, click ACPFApp to identify the application. 

2. Click Synchronize, and then when prompted for confirmation to synchronize the application, click OK. 

3. In the console tree, click the RKWebCluster node. 

4. In the details pane, under Synchronization, observe the synchronization icon for ACPFApp. 

   When the synchronization is finished, the animated icon will change to a check mark. 

   Note If you open the Synchronizations node in the console tree you can obtain more detailed status information about the synchronization job. For more information about synchronization monitoring and events, see Chapter 6, "Synchronization and Deployment." 

5. Click the cluster controller name to view CPU utilization (it should increase) in the performance chart and the status of the synchronization. 

6. When the synchronization is finished, verify that the directory and all of its files is replicated on all members. 

Trigger an Automatic Synchronization

1. Copy some test files to the ACPF directory on the controller. 

2. Observe to see that the files are automatically replicated. 

   The Synchronizing icon, under Status for the cluster controller, should change, indicating that an automatic synchronization is taking place. 

3. Check the ACPF directory on each member to verify that your test files were replicated to each member. 

COM+ Replication

Application Center doesn't handle COM+ replication in the same manner as HTML pages or configuration settings. Because the controller doesn't automatically synchronize these components across a cluster, we have to use another approach to getting them on the cluster members.

Note Log on to one of the members, and then open the Application Center snap-in. Expand the Component Services node down to, and including, the COM+ Applications folder. You'll see that the components we registered on the controller are not on the member.

Components can be copied to and registered on cluster members by using the Application Center New Deployment Wizard. The next set of steps is used to deploy the ACPFApp application.

In the Application Center snap-in:

1. In the console tree, right-click the Applications node, and then click Deploy Applications. 

   The New Deployment Wizard appears. 

2. Click Next to proceed. 

   The Deployment Target Options page appears. 

3. By default, the Deployment Target Options page enters the current time and date as the deployment name. 

4. Enter your own deployment name or keep the default. 

   The other default on the Deployment Target Options page is to deploy content inside the current cluster, which is what we're going to do. 

5. Click Next. 

6. On the Deployment Targets Within the Cluster page, which enables us to specify where we want to deploy the application, click to highlight the member names that are listed, and then click Next. 

   Note In RKWebCluster, the member names are ACDW518AS and ACDW802AS, so these were selected. 

   The Deployment Content page, which allows you to deploy the entire server image or a specific application(s), appears. 

7. Because we want to deploy a specific application, leave the default option button selected; in the list of available applications, click ACPFApp; and then click Next. 

8. Because we don't want to use the default selection on the Deployment Options page (folder and file permissions) but we do want to deploy COM+ applications instead, change the selection, and then click Next. 

9. Click Finish to start the deployment. 

You can monitor the deployment process by selecting the cluster controller node in the console tree and watching the counters and status messages that appear in the details pane for the controller. The Synchronizations view provides extensive information about deployments. After the deployment is finished, check the Component Services COM+ Applications folder for each member and verify that the sample components were copied to the members and registered.

Optional Replication Test

1. Remove one or more COM+ components from the AC_PF_VC application or change a component's properties (for example, transaction affinity, synchronization, or object pooling). 

2. Deploy the ACPFApp application again. 

3. After the cluster is synchronized, check the members to see if the changes are implemented on the local copy of the components. 

4. When you're finished testing, restore the original configuration because we need these settings for additional tests. 

Registry Replication

1. On the controller, start the Registry Editor, and then create a new key (for example, HKEY_LOCAL_MACHINE \Software \TestKey). 

2. Add a value (for example, TestValue) of the data type REG_SZ, string. 

3. For the key's value, enter a test string, such as A test key. 

4. In the console tree, click the Applications node, and then in the Applications view, click ACPFApp. 

5. Next, add the test registry key to this application as a resource. In the Resource Type box, click Registry Keys, and then click Add. 

6. Navigate the registry by using the Add Resource dialog box to locate TestKey, and then click OK to add the key to the ACPFApp resource list. 

7. In the upper part of the Applications view, click ACPFApp, and then click Synchronize. 

8. After the application is replicated to the members, check the settings on each member to verify that this synchronization worked. 

9. You can check the individual registry settings on each member as well as the resource list for ACPFApp on each member. 

10. You should repeat this test a couple of times; try adding another test key, deleting a test key, or changing the values of a test key. 

Metabase Replication

We'll test the replication of metabase settings by altering some of the values stored by IIS.

• Click on the Internet Information Services node in the Application Center UI, and expand it down to and including Default Web Site for the cluster controller (ACDW516AS in RKWebCluster). 

• Right-click on ACPFWeb to open the ACPFWeb Properties page. 

• Change a property, such as Execute permissions, and click OK to save the changes. 

• Synchronize the cluster. 

• Check the metabase settings for the ACPFWeb directory on each of the members. 

• Restore the original settings on the cluster controller, and synchronize the cluster again. Verify that the original settings were restored on each member by this synchronization. 

Validate the Configuration: Request Forwarding

This series of tests will verify that request forwarding works, as well as demonstrate this feature.

Preparation

We'll start by verifying that the cluster is accessible via the cluster or virtual IP address that's shared by all the members. Open Internet Explorer on a system outside the cluster, and provide the following URL, using the cluster IP address in the root:

https://<cluster_ IP_address>/ACPFWeb/PFWelcome.asp

After the screen is displayed, refresh it several times to confirm that the cluster is serving this page correctly.

Note Use Ctrl-F5 to refresh pages in the browser. This forces the browser to retrieve the requested page from the server rather than pulling it out of a cache.

We created this cluster using NLB with a client affinity set at Single. For the next set of tests, we need to change this affinity to Custom (None). The reason for doing this is that we need to ensure that no session stickiness, which can trigger the request forwarder, is maintained.

Tip In general you should use an affinity setting of Custom (None) when conducting localized testing of clustered Web servers. This is due to the nature of the algorithms that NLB uses to distribute load using IP address ranges. Typically, clients on the same internal subnet—provided that you're using Class C affinity—will end up getting balanced to the same server in a cluster. And, if you're using Single affinity, internal clients will always have their requests sent to the same Web server and you won't be able to observe request forwarding. Chapter 10, "Working with Performance Counters," covers this subject in more detail.

• Right-click on the cluster name in the Console tree, and select Properties. 

• Change the cluster client affinity by selecting Custom (none) in the Network Loading Balancing options drop-down, and click OK. This change in client affinity, and the load-balancing algorithm, will be replicated to the cluster members. 

Static Content – Not Forwarded

Now we'll test static content that isn't forwarded. Open the Web browser on an external system, and connect to the cluster, using the cluster IP address in the following URL to retrieve "PFStatic1.htm":

https://<cluster_IP_address>/ACPFWeb/PFStatic1.htm

After the screen displays, refresh the screen 10 – 20 times. Open the Web server log file on the controller and the members to verify that this page was opened on different servers. The log files are in the following path: C:\WINNT\system32\LogFiles\W3SVC1.

Dynamic Content – Forwarded by Default

Use the Web browser on the external client to connect to the cluster using the cluster IP address in the following URL to retrieve "PFDynamic1.asp":

https://<cluster_ IP_address>/ACPFWeb/PFDynamic1.asp

Verify that the page is properly displayed. The page returns short text with the server name. Refresh the screen 5 – 10 times. In every instance you should see the same server name displayed. Remember, with request forwarding enabled, subsequent requests from the same client are always returned from the server that initially handled the request.

Dynamic Content – Not Forwarded When Request Forwarding Is Turned Off

Now we'll disable request forwarding. Once again, we're working in the controller user interface. Right-click on the cluster name, and select Properties. When the cluster properties page appears with the General tab displayed, click the Advanced button that's located in the Load balancing options section. This will bring up the Advanced Load Balancing options screen, and you can deselect the Enable request forwarding check box. Click OK to apply the change.

Use the browser on your external client to connect to the cluster, using the cluster IP address in the following URL to retrieve "PFDynamic1.asp":

https://<cluster_ IP_address>/ACPFWeb/PFDynamic1.asp

Verify that the page is properly displayed. The page returns short text with the server name. Refresh the screen 5 – 10 times. Because request forwarding is turned off, you should see different server names displayed.

Note Remember to restore the Single affinity setting and to turn request forwarding back on at the end of your testing.

Validate the Configuration: Put Load on the Cluster

Now that we've verified that all of Application Center's major features are functioning correctly, we'll apply some load to the cluster as a final step in validating the configuration.

Preparation

Before running any tests, we have to do some preparation, starting with an external client.

On an External Client

Since we use the Web Application Stress tool (WAS), you'll have to obtain a copy and install it on the client system that you're going to use for testing. If you don't already have a copy, you can download the latest version from https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

Note The WAS tool is used extensively in Chapter 10, "Resolving Performance and Capacity Issues." Refer to this chapter for more detailed information about configuring and using this tool.

Locate the file named ACPreflight.mdb in the ACPF directory. This file is a Web Application Stress database that contains a script that the test team designed to test the configuration we've created. It loops through calls to the pages described earlier, randomly specifying COM+ components to create.

Start WAS, and open ACPreflight.mdb to load the test script. You'll have to edit this script for your test environment as follows:

• Specify the cluster IP address for the cluster you created. 

• Change the duration of the test from one minute to 15 minutes, the minimum time for counter performance graphs. 

• Since this particular application doesn't use sessions, you can disable the "Use users, passwords, and save cookies" option. This prevents skewing of the results. 

Note Turning off the "users, passwords, and save cookies" feature in WAS is fine for quick and dirty tests; as long as the application does not use cookies (not session cookies), no authentication is required, and the %USERNAME% and %PASSWORD% string replacements are not used in the query string. Additionally, static headers are fine as long as the application does not use dynamic cookies. However, a better approach is to leave these WAS settings enabled, and use the cluster configuration settings contained in the next section, "On the Cluster Controller."

Each of the tests in the script is executed on the cluster using a simulated load, and the results are stored in a report that WAS generates after a test run.

On the Cluster Controller

If you're using internal WAS clients, you should set the client affinity to Custom (None) in order to get better load distribution on the cluster. To do this, right-click on the cluster node, select Properties, and on the General tab, use the drop-down list for the NLB client affinity option to choose Custom (None).

Disable Request Forwarding by right clicking on the cluster node, select Properties, choose the Request Forwarding tab, and uncheck "Enable Web request forwarding". There are two reasons for doing this.

First, unless you're running WAS clients through a proxy server and the application that you're testing requires request forwarding, leaving Request Forwarding enabled serves no purpose.

Second, disabling Request Forwarding is, in most test scenarios, the preferred alternative to turning off the "Use users, passwords, and save cookies" feature in WAS is to disable Request Forwarding. This is preferable since many Web applications do require string replacements in the querystring, do require authentication, and do use cookies. Also, the request header size is a more accurate when monitoring bandwidth (303 bytes instead of 202 or 185).

Basic Tests with Load on Cluster

Before conducting any testing, follow the next set of steps to verify that the ACPreflight script is functioning correctly:

• Start the script. 

• Use the Application Center user interface to observe the performance counters that you set for Processor utilization and GET requests for on each cluster server. The performance graphs for each server should all be within the same range, indicating the requests are being load-balanced across the cluster. 

  Note Processor utilization for the controller will be slightly higher, which is to be expected. 

• Check the cluster performance monitor—notice how the counters for the individual servers are rolled up and averaged, providing a cluster-wide view of performance. 

After the script is finished running, check the WAS report file that was generated. It contains information such as the number of requests, requests per second, socket errors, and error codes.

Some Tests to Try

Run the test script against your cluster, and carry out the following activities. In each case, observe the effect that each activity has on controller, member, and cluster-wide performance.

• Set a member offline from load balancing. Right-click on the member name, and select Set Offline. Since we're running in a test environment, there's no need to drain connections—choose the Take offline now option on the Set Offline screen, and click OK. Processor utilization should increase on the remaining servers. 

• Reverse the preceding process, and bring a server online. Processor utilization should come down for the original two servers. 

• Remove one of the members from the cluster. Right-click on the member name, and click on Remove Cluster Member under All Tasks. Click OK to confirm the removal, and provide the required credentials when prompted. Click OK. After the member is removed, processor utilization should be higher on the remaining servers. 

• Nominate one of the members to be the cluster controller. Right-click on the member name, and select All Tasks, Designate as Controller. Observe the impact that this action has on processor utilization as the Application Center reconfigures the cluster. 

• Repeat the replication and deployment steps that you conducted earlier. 

• Change the cluster's bandwidth, and process throttling settings. 

• Turn request forwarding on and off. 

Scale Out the Web Tier

For a final test of the product's features, try scaling out the Web tier by adding a new system that has Application Center installed but hasn't been used on a cluster. For our test environment, we added one more server (ACDW802AS), so the final Web cluster consists of the following servers in the Figure 8.1 architecture:

• ACDW516AS, cluster controller (WC) 

• ACDW518AS, a cluster member (W1) 

• ACDW802AS, a cluster member (W2) 

Add the new member's snap-ins—that is to say, IIS and Component Services—to the cluster controller's console, and verify that the configuration settings and application installs that you did in the preceding sections were replicated to the new member. Figure 8.9 shows the controller console in the RKWebCluster after all the snap-ins were added.

Figure 8.9 The RKWebCluster controller console tree with member snap-ins added 

The few tests that we've described provide the foundation for verifying that your cluster is functioning correctly, as well as give you a preliminary understanding of cluster performance. Your own situation may require custom testing that reflects the needs of your platform and applications.

Let's move on and build the back-end tier of our environment—the COM+ application cluster for serving out-of-process components to the front-end Web tier.

Build the COM+ Tier

In this step, we'll create a two-member cluster that will be used to serve COM+ components to Web servers on the front tier. After creating the COM+ cluster, we have to configure the Web cluster members so that they will route requests to the component cluster. CLB in fact, is implemented on the Web tier rather than the COM+ tier.

Create the COM+ Cluster

Before starting the cluster creation process, make sure that the following prerequisites have been met.

Prerequisites

The configuration, shown in Figure 8.10 requires the same software as the Web cluster. The notable difference is that because this cluster doesn't use NLB, only one static IP address is required on the front-end adapters. Unlike members in the Web cluster, component servers don't share a cluster/virtual IP and media access control (MAC) address. When a Web server needs to route a request to a component server, it uses the component server's machine name. Once again, the back-end adapters, which are not a requirement, could be used for carry Application Center-specific traffic.

Figure 8.10 Typical network adapter configuration for a COM+ application cluster 

Before opening the Application Center snap-in and creating the cluster, you should use ping to verify the visibility of the computers on the network.

Create a COM+ Application Cluster

Now that the server's been configured to function as a cluster controller, we can create the cluster. Because the steps that you're going to take to create this cluster are identical to those used for creating the Web cluster, we've provided the following summary.

1. On the computer that you want to use as the cluster controller, open the Application Center snap-in. 

2. Connect to the computer as localhost, and then in the New Server dialog box, click New Cluster to launch the New Cluster Wizard. 

3. Step through the screens in the New Cluster Wizard. 

Because we're not implementing NLB on this cluster, refer to Table 8.4 and take note of the slightly different configuration information that we used to build RKCOMCluster, our test component server cluster.

Table 8.4 New Cluster Wizard Configuration Information for the COM+ Application Cluster 

Wizard page	Configuration information, comments
Welcome to the New Cluster Wizard	Click Next
Cluster Name and Description	Cluster name: RKCOMCluster
Cluster description: A COM+ application cluster.
Cluster Type	Click COM+ application cluster
COM+ Application Clients	Kept default: Server applications
Monitoring Notifications	E-mail address: someone@microsoft.com
	E-mail server name: yourmailserver
Completing the New Cluster Wizard	Click Next

At the end of this process we have a cluster named RKCOMCluster, consisting of the cluster controller, ACDW522AS. The next thing we want to do is increase the size of the cluster by adding one member.

Add a Member

Adding another cluster member only takes a couple of steps. Repeat the steps you used to add a member to the Web cluster. (The assumption is that you are doing this while logged on to the cluster controller.) In brief:

1. Right-click the cluster controller node; on the pop-up menu, point to All Tasks, and then click Add Cluster Member to launch the Add Cluster Member Wizard. 

2. Identify the server to add, and provide valid credentials. 

3. Enter the cluster controller name. 

4. Complete the wizard steps. 

At this point we have a two-node Application Center COM+ application cluster. If you want to add more members, simply repeat the previous procedure.

For our test environment, the final cluster consists of the following servers in the Figure 8.1 architecture:

• ACDW522AS, cluster controller (CC) 

• ACDW811AS, a cluster member (C1) 

As a final set up step, we added the IIS and Component Services snap-ins for ACDW811AS to the controller console tree so that we could have a single management console for the cluster, in the same fashion as the Web cluster controller.

Validate the Configuration

You should take the time to test the cluster configuration before installing any applications. You can do this by repeating most of the tests described for testing the Web cluster. The key difference is that HTTP- and NLB-related tests aren't relevant for the COM+ cluster. You don't have to worry about request forwarding, which is an advanced load balancing option, because load balancing isn't enabled for this cluster.

However, you can install performance counters—processor utilization as a minimum—as well as verify that monitoring is working.

Install the Components

Now we have to install the same COM+ applications that went on the Web tier to the component servers. (If you haven't already done so, execute the Pre-Flight Manual's ACPF.EXE to the partition where Application Center is installed.)

1. Navigate to the ACPF\Files directory. 

2. In Windows 2000, open a command prompt, and then type: 

   C:\ACPF\Files\PFSetupCOM.bat 

   Create an application named ACPFApp and add the test COM+ applications as resources for this application. Once again, we'll use a batch file to do this. 

3. In Windows 2000, from the command line, type: 

   C:\ACPF\Files\PFSetupACCom.bat 

4. At this point we have two COM+ applications, and one Application Center application that has both the COM+ applications registered as resources. Now we have to deploy ACPFApp to the cluster member in order to replicate the COM+ applications and install them correctly. In the Application Center snap-in, right-click the cluster name, and then on the pop-up menu, click Deploy Applications to deploy ACPFApp to the member by using the New Deployment Wizard. 

   Note Make sure you specify Deploy COM+ applications on the Deployment Options page. 

5. When the deployment is finished, do a visual check on the member and verify that the COM+ application is installed correctly. 

The final step involves configuring the Web cluster controller so that the test components will be load balanced and their activations will occur on the COM+ servers.

Enable CLB on the Web Cluster

1. Log on to the Web cluster controller, and then open the Application Center snap-in. 

2. Expand the Component Services snap-in for the controller and verify that both the AC_PF_VB and AC_PF_VC applications have their components installed. 

After we enable the components in both applications for load balancing, we'll create the routing list needed to forward component requests to the COM+ cluster members.

Enable CLB

In the console tree, expand the Component Services node down to the component level, and in the AC_PF_VB application, reveal PFComponentPFComp. Figure 8.11 illustrates the fully expanded component snap-in on the RKWebCluster controller.

To enable load balancing:

1. Right-click PFComponentPFComp, and then on the pop-up menu, click Properties to open the object Properties dialog box. 

2. Click the Activation tab. 

3. Select the Component supports dynamic load balancing check box, as illustrated in Figure 8.11, and then click OK to save your changes. 

Next we have to enable load balancing for the components in the other test application.

• Under the AC_PF_VC node, expose the components, and then repeat the preceding steps to enable load balancing for each of the components (TestCOM.TestCOM1 through TestCOM.TestCOM5) in this application. 

  

  Figure 8.11 The dialog box for enabling dynamic load balancing on a COM+ component 

Automated CLB configuration 

You can also mark all the test components for dynamic load balancing by using a batch file provided with the Pre-Flight Check Application. In Windows 2000, open a command prompt, type the following batch file name, C:\ACPF\Files\PFSetupCOMDLB.bat, and then press Enter.

The next step in enabling CLB on our Web cluster is creating a routing list that references the COM+ cluster members.

Create the Routing List

1. Right-click the cluster node (RKWebCluster in our cluster), and then on the pop-up menu, click Properties. 

   The RKWebCluster Properties dialog box appears (Figure 8.12). 

2. Click the Component Services tab. 

3. Add the name of each member in the COM+ cluster, and then click OK to save this configuration. 

   

   Figure 8.12 A routing list identifies component servers that handle component requests 

As you can see in Figure 8.12, we identified both of the RKCOMCluster members as targets for object instantiation requests.

Finally, we have to copy all the configuration information that we just did on the controller to the other Web cluster members. Once again, we use the deployment wizard and cluster synchronization to do this. The wizard copies the components and their new settings to each member, and synchronization copies the cluster routing list information to the members.

Use the following steps:

1. Deploy the ACPFApp application from the controller to the members; remember to specify Deploy COM+ applications on the Deployment Options page. 

2. Perform a visual check, and verify that the newly installed components have dynamic load balancing enabled. 

3. Synchronize the cluster (right-click the controllername, and then on the pop-up menu, click Synchronize) to make sure that each member has the updated routing list. 

At this point CLB is enabled on our two-tier cluster environment and we can proceed with some basic testing.

Validate the Configuration: Load-Balanced Components

You should perform the following tests to verify that component creation is taking place on the COM+ tier, and that these instantiations are being load balanced between the two component servers.

On the External Client

Use the following steps to verify how the configuration works.

1. Open the Web browser, and then use the cluster IP address to connect to the Web cluster. 

2. Use the following URL to open the PFWelcome.asp page: 

   http://WebclusterCluster IPAddress/ACPFWeb/PFWelcome.asp 

   Verify that your test environment correctly serves the Web page, which shows:

   • The name of the Web server that returned the page. 

   • The name of the COM+ component that was instantiated. 

   • The name of the COM+ application cluster member that created the component. 

3. Update the screen several times by pressing CTRL+F5. 

   You should see different Web and COM+ server names as you generate requests. 

Note Your Web cluster should have request-forwarding disabled, and as mentioned earlier, should use an affinity setting of Custom (None).

Validate the Configuration: Put Load on the Clusters

We also want to apply some load to our multi-tier configuration so that we can observe how the servers on both tiers respond. Start WAS, and run the test script that we used earlier. While the stress test is running, you should:

• Observe processor utilization and ASP Requests per second on the Web servers. 

• Check the processor utilization on the members in the component cluster. 

• Open the Component Services snap-in on one of the component members, and verify that both applications are running and all of the COM+ components are created at least once. 

When the script finishes running, examine the report that's generated for the run:

• Check for errors. 

• Check for failed connections. 

Note It may be necessary to apply more load to the clusters. You can install WAS on other clients and add their names to the client list on the system that ran the ACPreflight stress test script. This allows you to manage stress tests from a single console.

Once again, you can conduct more extensive testing by running the WAS script against the clusters and trying different tasks, such as setting members online and offline in the Web tier, or removing members.

The RKWebCluster under load 

In our test environment, the load results (running two WAS clients against the cluster) clearly showed that one of our members, ACDW802AS, could not handle the same load as the other two members. Even the controller, which also had to handle the various Application Center services, showed processor utilization that was at least 10 percent lower than ACDW802AS. In Chapter 10, "Working with Performance Counters," you'll see how these members can be tuned for better performance, as well as how you can re-distribute cluster traffic to compensate for lower capacity members.

Summary

Up to this point we've been working with test clusters that weren't actively serving content to clients. In this situation it didn't really matter if services such as COM+ or IIS got reset because it didn't affect live users. In a production situation, however, you can't do this—a staging and deployment process and platform is essential for installing or refreshing applications on a production cluster. In the following section we'll set up an Application Center stager that we'll use for deploying applications.

Setting Up a Stager

The stager that we're going to set up next consists of a single server running Application Center—it is a cluster of one member, which is all we need to use the New Deployment Wizard and leverage it's capabilities, particularly in the area of component installation. However, there's nothing to prevent you from building a multi-member staging environment if you feel it's required. You may find, for example, that you want to use the staging cluster for final pre-deployment testing, in which case a staging cluster with several members makes sense and is desirable from a failover perspective.

Server Configuration

As was the case with the other servers we configured earlier, the stager is running Windows 2000 Advanced Server with Application Center installed.

Because our stager is going to be used solely for deployments, we did a custom installation of the product and disabled the installation of Application Center Events and Performance Logging—any performance monitoring we need to do can be accomplished easily by using Windows 2000 System Monitor. Also, the stager only has one network adapter with a single dedicated IP address because we aren't going to do any load balancing.

Note Remember to configure your stager with the same directory and file structure that you used on the Web and COM+ clusters.

Create a Staging Cluster

Open the Application Center snap-in, and then launch the New Cluster Wizard in the same way you did when you created the initial clusters. The steps, in brief, are:

1. Connect to the server, and then identify the server by its name or use localhost. 

2. Click Create a new cluster. 

3. Use the information provided in Table 8.5 to create the cluster on the stager. 

Table 8.5 New Cluster Wizard Configuration Information for the Stager 

Wizard page	Configuration information, comments
Welcome to the New Cluster Wizard	Click Next
Cluster Name and Description	Cluster name: RKStager
Cluster description: A staging cluster.
Cluster Type	Keep default: General/Web cluster
Load Balancing	Change to None
Monitoring Notifications	E-mail address: someone@microsoft.com
	E-mail server name: yourmailserver
Completing the New Cluster Wizard	Click Next

At the end of this process, we have a cluster named RKStager that consists of a single member (ACDW822AS in our test configuration).

Before loading any applications on your system, you should disable any automatic services that aren't required for staging operations, such as automatically synchronizing members when content is updated (right-click the cluster name, click Properties, and then in the clustername Properties dialog box, click the General tab).

Note Several services, such as request forwarding, are automatically disabled by Application Center when you create a cluster without load balancing enabled.

Validate the Configuration

You should perform some simple validation tests to verify that the staging cluster is operating correctly. In addition to pinging the network adapter from external clients, you can use Internet Explorer to open the Web-based administration interface by specifying the stager name and port 4242 as the URL (that is, https:// stagername :4242).

Sample Applications for Staging

We installed three sample applications on our stager in order to test different deployment scenarios by using applications of varying complexity, as well as determine what impact staging had on clusters that were actively serving content. The three sample applications are:

• Web Guide—This application comprises a collection of static HTML pages and graphics that we assembled locally. The 90+ files in Web Guide have a combined size of one-half of a megabyte on the drive. You can prepare a similar collection of files if you want to step through the deployment example we've provided. 

• Pre-Flight Check—The Pre-Flight Check, which you already had a chance to install and test, consists of 16 Web pages (HTML and ASP) and 2 COM+ applications that contain a total of 6 components. 

• FMStocks 2000—The revised version of this well-known MSDN (Microsoft Developer Network) sample application is used to instruct developers in using the .NET platform. FMStocks combines Web and ASP technologies with COM+ and database technologies in a fairly typical distributed application. 

Note This application also requires a back-end SQL Server database.

Installing the Applications on the Stager

Use the following steps to install the three sample applications on the staging cluster.

Web Guide

1. On the controller's C drive, create a directory named GUIDE, and then put the collection of HTML pages and graphics in this folder. 

   Note We created a separate subdirectory named Images to hold the graphics. 

   First we'll create the Web application in IIS, and then the Application Center application. 

2. Expand the IIS node, and then expand the cluster controller node. 

3. Right-click Default Web Site, point to New, and then click Virtual Directory. 

4. On the Virtual Directory Creation Wizard Welcome page, click Next. 

5. On the Virtual Directory Alias page, in the Alias box, enter WebGuide and then click Next. 

6. On the Web Site Content Directory page, click Browse, locate the C:\GUIDE directory, identify it as the content directory, and then click Next. 

7. Accept the defaults, and then click Next. 

8. On the last wizard page, click Finish. 

Create an Application Center Application

Finally, we'll create an Application Center application.

1. In the Application Center snap-in, click Applications to display the Applications view. 

2. Click New, and then in the Name box, enter Web Guide as the name of the new application. 

3. Click Web Guide, right-click the arrow to the right of Resource Type, and then click Web Sites and Virtual Directories. 

4. In the Web Sites and Virtual Directories list, click Default Web Site, click Add, and then click Close. 

5. Right-click the arrow to the right of Resource Type; click File System Paths; in the File System Paths list, click C:\GUIDE; click Add; and then click Close. 

You now have the application fully installed on the stager and ready for deployment.

Pre-Flight Check

Repeat the instructions you followed in "Validate the Configuration: Replication" earlier in this chapter to install the PreFlight Check sample application on the stager. The quickest way to do this installation is to run the following batch files in the C:\ACPF\Files directory:

• PFSetupCOM.bat—creates the two COM+ applications (AC_PF_VB and AC_PF_VC) and installs their components. 

• PFSetupWeb.bat—creates a Web virtual directory (ACPFWeb) under the Default Web Site. 

• PFSetupAC.bat—creates an Application Center application (ACPFApp) that contains all of the resources for the Pre-Flight Check application. 

FMStocks 2000

You can find the compressed file containing the FMStocks 2000 application on the CD or you can obtain the latest version from the Microsoft Web site at https://msdn.microsoft.com/library/default.asp.

Copy FMStocks2000.exe to a temporary directory on the stager's drive and run this executable. This setup program will expand the executable and source code files into the \Program Files\FMStocks 2000 directory. This directory will contain the following four subdirectories: Components, Documentation, Database, and Website.

There are four batch files in the FMStocks 2000 root directory (C:\Program Files\FMStocks 2000) that you can use to install the application. These batch files are:

• Setup-web.cmd—creates the FMStocks virtual Web site in IIS. 

• Setup-components.cmd—installs the COM+ components. 

• Setup-db.cmd—installs database objects, such as tables, stored procedures, and initial data. 

To install FMStocks 2000 on the stager, we only ran the Setup-web and Setup-components programs. The application's database was then installed on a separate server outside the cluster environment. We did this by:

• Copying the \Program Files\FMStocks 2000\database directory and the database setup file (Setup-db.cmd) to this server. 

• Running Setup-db on the database server. 

There are three steps required to complete the installation of FMStocks on the stager:

1. Configure a component that identifies the application's data source. 

2. Install an ISAPI filter. 

3. Create an Application Center application that identifies the FMStocks resources. 

Configure the Data Source

You need to configure a component that identifies the database server and database that FMStocks will use in your environment.

1. On the stager, open the Application Center snap-in, and then expand the Component Services node down to and including FMStocks Core. 

2. Open the Components folder, and click FMStocks_DB.DBHelper. 

3. Right-click; on the pop-up menu, click Properties; and then click the Activation tab. 

4. Select the Enable object construction check box, and then in the Constructor string box, define the new data source name, which should correspond to the database server name. (See Figure 8.13.) Click OK to save this configuration. 

   

   Figure 8.13 Enabling the FMStocks data connection 

Install the ISAPI filter

The filter's DLL file, Fms2ksec.dll, is located in the directory \Program Files\FMStocks 2000\Components\ISAPI Filter. This filter has to be added to the properties for Default Web Site.

1. Use the Application Center snap-in to open the Default Web Site Properties dialog box. 

2. Click the ISAPI Filters tab, and then click Add. 

3. Use the Filters Properties browser to name and identify the filter. 

   After you've done this, the Default Web Site Properties dialog box will be similar to the one shown in Figure 8.14. 

   

Figure 8.14 Using the Default Web Site Properties dialog box to add a global ISAPI filter 

Create the Application Center Application

1. In the Application Center snap-in, click Applications to display the Applications view. 

2. Click New, and then in the Name box, enter FMStocks 2000. 

3. With FMStocks 2000 highlighted, use the Resource Type list to add COM+ Components and Web Sites and Virtual Directories as resources for this application. 

   Add the following COM+ applications to FMStocks 2000:

   • FMStocks 2000 Core 

   • FMStocks 2000 Events 

   • FMStocks 2000 Office Extensions 

   • FMStocks 2000 Store Order Processing 

   • FMStocks 2000 Store Shopping Cart 

4. In the Resource Type list, click Web Sites and Virtual Directories, and then add the FMStocks Web site (Web Site/Root) as a resource. 

Test the FMStocks Application

After you've finished installing FMStocks, you should test the application to see if it's installed and configured correctly. You can do a simple application to test database connectivity by running the Test FMStocks installation.vbs script, which is located in the FMStocks 2000 root directory.

You can test the application more extensively by using the Web browser to access the FMStocks home page on the server, log on, and trade stocks.

Note The FMStocks sample application also contains a script that you can load into WAS and run to apply load on a server (FMStocks 2000 Template.mdb).

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 Application to 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 Web Cluster," 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 Application with 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

Using a Stager to Deploy Applications

Even if your Web application contains ISAPI filters or COM+ objects, these application elements don't mandate the need for a stager. You can install them directly on the controller and deploy them to the rest of cluster. The decision to use a stager is driven by the need for release management in all deployment cases.

A stager does enable you to manage the production process better by inserting a layer between your production cluster and your development/test server(s).

For this reason we've included several staging scenarios to illustrate how you can deploy different types of applications to one or two tiers. These scenarios include:

• Deploying a static Web application (Web Guide) containing HTML pages and graphics to a Web cluster. 

• Deploying updated components in the Pre-Flight Check application to a Web cluster. 

• Deploying the FMStocks 2000 application to both the Web and COM+ clusters. 

About the Scenarios

The following deployment scenarios are provided solely for the purpose of illustrating how you can use a stager to deploy new applications as well as application updates to one-tier, two-tier, or three-tier cluster environments. In every case you have to develop a deployment strategy that takes into account your operational requirements as well as address the deployment issues we've highlighted. Once again, the questions to consider:

• Do you have to provide 365-day/24-hour uptime? 

• Do you currently use scheduled downtime for maintenance? 

• Are there periods where a live update will have minimal impact on your users? 

After you establish your operational needs, you can use the scenarios we describe as guides for tailoring custom deployments on your own clusters.

Preparing for the Scenarios

After we finished configuring the two-tier environment earlier in this chapter, we had load-balanced COM+ objects getting created on the cluster in the component server tier (RKCOMCluster). Because these deployments are to a single tier—the RKWebCluster—we have to reconfigure some settings on the servers in the Web tier.

Reconfigure RKWebCluster

What we need to do is unmark the load-balancing option for the Pre-Flight Check components so that they get created and executed on the Web tier. You can do this manually, or create a batch file that does the reverse of PFSetupCOMDLB.bat and its associated INF file, PFCOMSetupDLB.

We logged on to the controller and created two new files (uPFSetupCOMDLB.BAT and uPFCOMSetupDLB.INF), which we saved in C:\ACPF.

The code in uPFSetupCOMDLB.BAT is:

@echo off
regsvr32 /s COMpWrap.dll 
COMTestSetup /inf:uPFCOMSetupDLB.INF

The code in the INF file is:

&ACPF
* Set component properties
SetCompProp AC_PF_VB PFComponent.PFComp LoadBalancingSupported N
SetCompProp AC_PF_VC TestCOM.TestCOM1.1 LoadBalancingSupported N
SetCompProp AC_PF_VC TestCOM.TestCOM2.1 LoadBalancingSupported N
SetCompProp AC_PF_VC TestCOM.TestCOM3.1 LoadBalancingSupported N
SetCompProp AC_PF_VC TestCOM.TestCOM4.1 LoadBalancingSupported N
SetCompProp AC_PF_VC TestCOM.TestCOM5.1 LoadBalancingSupported N

We then ran uPFSetupCOMDLB.bat and unmarked the components for load balancing. After confirming that the changes were implemented correctly on the controller, we deployed ACPFApp to the other cluster members, ACDW518AS and ACDW802AS. As a final test, we used the Web browser to connect the cluster (https:// 192.168.100.102/ACPFWeb/PFWelcome.asp) and verify that the objects were being created on the Web cluster.

Note It's not necessary to delete the component server routing list because it will be used by the FMStocks 2000 application, which also uses CLB.

Prepare the Stager

As a final step in deployment preparations, we implemented the single management console concept on the stager by opening the Application Center snap-in on the stager and adding the RKWebCluster to the console tree. This approach enables you to manage the entire staging process from a single console, as shown in Figure 8.15.

Figure 8.15 Managing a staging cluster and Web cluster from the stager console 

Now that we've prepared our staging environment, we can step through the various staging scenarios, beginning with a deployment of our Web Guide application to the Web cluster, RKWebCluster.

Deploy a New Application to a Web Cluster

We're going to deploy the Web Guide application by using the strategy illustrated in Figure 8.16. Using this figure as a reference, our deployment consists of the following steps:

• Perform a single deployment from the stager (ACDW822AS) to the Web cluster controller (WC - ACDW516AS). 

• Replicate content from the controller to the members (ACDW802AS and ACDW518AS). 

It's important to remember that the strategy shown in Figure 8.16 is based on the cluster set up that we're running here and on the following rationale:

• Because the Web Guide application consists solely of static Web pages and graphics, there is no requirement to reset services, such as IIS. And, because there aren't any ISAPI filters or COM+ components that require Web Service resets or need to be deployed to a member, we can leverage the Application Center synchronization feature to replicate new content to the members. 

• You can use a similar strategy in your own environment—but you should factor in server capacity, cluster load, and operational requirements. 

  

  Figure 8.16 Using a stager to deploy static content to a Web cluster 

Deploy the Web Guide

To ensure that we had a load on the cluster during deployment, we configured WAS to run for 20 minutes and started it against the cluster. Then, we deployed the Web Guide application by using the following steps. (Use Figure 8.16 as a reference for this operation.)

Note We used the Application Center snap-in of the stager for the entire deployment.

1. Activate the console tree for the stager, launch the New Deployment Wizard, right-click ACDW822AS, and then on the pop-up menu, click Deploy Applications. 

   Complete the wizard pages by using our responses as guidelines:

   • Deployment Target Options: Append the default deployment name (date/time stamp) with Web Guide, and then select Deploy content outside the current cluster check box. 

   • Deployment Target Authentication: Provide logon information for an account with administrator privileges on all targets. 

   • Deployment Targets: Add the Web cluster controller name (ACDW516AS). 

   • Deployment Content: Click Web Guide. 

   • Deployment Options: Keep the default, Folder and File permissions, and then click Next to launch the deployment 

2. Activate the Synchronizations view and observe the progress of the deployment as Application Center provides real-time status information. 

   Continue observing the Synchronizations view as the cluster is synchronized. 

   After cluster synchronization is finished, verify that the deployment was successful by:

   • Activating the Applications node on the controller (ACDW516AS). Web Guide should appear in the list of applications. 

   • Open the IIS snap-in for each member, and then open the Default Web Site node. WebGuide should appear in the site list. 

   • Log on to each member and use the folder explorer to verify that the GUIDE directory was copied to each member. 

Note As an option, you can disable automatic synchronization on the target cluster and manually synchronize the new application across the cluster after the deployment finishes. You can do this by displaying the cluster Applications list, highlighting the application, and then clicking Synchronize. When you do this, all the new content that you deployed to the controller is replicated to all the cluster members.

Variations on a Theme

There are two variations on the preceding deployment scenario that may be useful in your own situation.

Staged Cluster Synchronization

We used a staged synchronization to compensate for the lower capacity—relative to the other members—of ACDW802AS. Based on previous WAS runs and load results, we felt that this particular member shouldn't be serving content at the same time that new content was replicated to the system. Before we deployed the Web Guide application to the cluster, we took ACDW802AS out of the load-balancing loop. After deployment and cluster synchronization was finished, we brought the member back online.

Live Testing Prior to Deployment

Another scenario is one in which you might want to test new content with "live" users before making it generally available on the cluster. We tested this case as well, and so can you, by following these steps:

• Identify the test server in the cluster (we used ACDW518AS (W1) in our case) and take it out of the load-balancing loop. 

• Disable synchronization on the member (W1). 

• Deploy the Web Guide application to the W1 server. 

• Bring W1 back online for load balancing. 

At this point, the new content is available to any of the clients that get load balanced to W1, which is approximately one-third of the traffic to RKWebCluster. When you're finished testing, you can follow the steps described in "Web Guide Deployment," earlier in this chapter, to deploy the application to the entire cluster.

Warning Don't forget to re-enable synchronization on W1 before you deploy the application to the cluster. You want to make sure that any application changes made as a result of the live testing get copied to the test server.

Deploy an Application Update to a Web Cluster

Deploying application updates to the Web tier has to be handled differently, depending on whether or not your updates involve COM+ components.

Deploying Applications Without 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.

Deploy the Web Guide Update

Use the following steps to deploy the updated files for the Web Guide application.

1. Take the controller (WC – ACDW516AS) and one member offline (W2 – ACDW802AS), and then disable automatic synchronization on WC. 

2. Deploy the Web Guide application to WC and W2 by using the steps described in "Deploy the Web Guide" earlier in this chapter. 

   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. 

3. Set the remaining member, W1, offline for load balancing. 

   In addition to draining the existing connections, this action ensures that this member does not accept any new requests. 

4. Set the controller and W2 back online immediately after step 3. 

5. Re-enable synchronization on the cluster controller, and then force a synchronization of the cluster. 

6. Set W1 back online. 

Deploying Applications with COM+ Components

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.

Deploy an Update to the ACPFApp Components

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.

• Create a new Application Center application named ACPFCOM. 

• In the Resource Type list, click COM+ Applications, and the add AC_PF_VB and AC_PF_VC as 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.)

Deploy ACPFCOM

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.

1. Starting with the W2 member, take the WC controller and the W2 member out of the load-balancing loop. 

2. Change the draining period from the default (20 minutes) to 5 minutes, and then click OK. 

3. Observe the RKWebCluster status indicators to confirm that WC and W2 are offline for load balancing. 

4. In the console tree, right-click the stager, ACDW822AS, and then on the pop-up menu, click Deploy Applications to open the New Deployment Wizard. 

   Respond to wizard pages by using the following responses as guidelines.

   • Deployment Target Options: Append the default deployment name (date/time stamp) with ACPFCOM, and then select the Deploy content outside the current cluster check box. 

   • Deployment Target Authentication: Provide logon information for an account with administrative privileges on all targets. 

   • Deployment Targets: Add the Web cluster controller and member names (ACDW516AS and ACDW802AS). 

   • Deployment Content: Click ACPFCOM. 

   • Deployment Options: Clear the default, folder, and file permissions, select the Deploy COM+ applications check box, and then click Next to launch the deployment. 

5. Observe the Synchronizations view as it provides real-time status information about the deployment. When the deployment is finished, activate the Applications node for RKWebCluster and verify that ACPFCOM was replicated. You should also verify that the COM+ applications were installed by checking for their presence in the Component Services console tree on the cluster controller. 

   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. 

6. Bring the cluster controller and member (W2) back online for load balancing. 

7. As soon as the controller comes online, set the next deployment target, ACDW518AS (W1) offline with a 5-minute draining period. 

8. Deploy the ACPFCOM application again (steps 3 and 4), this time using ACDW518AS as the deployment target, and verify the success of the deployment as you did in step 5. 

9. Bring the remaining member back online for load balancing. 

10. As a final test of the success of the deployment, open the Web browser, and then on the Web cluster, open PFWelcome.asp to see if the components are created on the Web tier—they should be. 

11. On the cluster controller, in the Applications list, delete ACPFCOM. 

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

Deploy a New Application with COM+ Components to Two Tiers

This scenario illustrates how you can deploy a Web application, FMStocks 2000, to a multi-tier cluster that uses both NLB and CLB. As you know, this particular application uses both ISAPI filters and COM+ components, which means that services are going to be reset on the targets on both tiers. Therefore, we can't deploy to the entire cluster without effecting existing client connections. The strategy, then, is to deploy the application in several phases.

First, we'll deploy the load-balanced component to the COM+ cluster in two phases. Second, we'll deploy the entire application to the Web cluster in two phases to minimize the impact on users.

However, before we can begin deploying content we have to prepare the FMStocks 2000 application on the stager.

Prepare the Application

Because our application consists of HTML pages, ASP pages, ISAPI filters, and load-balanced COM+ components, we're going to determine which elements must be deployed to the COM+ tier. Using the same technique described for the ACPFApp update, we'll create a temporary application on the stager that's a subset of FMStocks 2000. This provides some granularity in our deployment by letting us deploy only the required components to the COM+ tier.

Note For the purposes of this scenario, the only FMStocks component that we're going to load balance is FMStocks_DB.DBHelper. This object is located in the following path in the Application Center snap-in:

/Component Services/Computers/My Computer/COM+ Applications/FMStocks 2000 Core/Components

Working from the stager:

• Create a new application named FMStocksCOM, and then identify FMStocks Core as a COM+ application resource for FMStocksCOM. 

Now we have two Application Center applications that are ready to deploy:

• FMStocks 2000: contains everything in the application and will be deployed to the Web tier (RKWebCluster). 

• FMStocksCOM: contains the load-balanced components and will be deployed to the COM+ tier (RKCOMCluster). 

Let's step through both deployment phases, using our stager and the test clusters that we've created.

Note All the steps in phases one and two are implemented from the stager.

Phase One: Install to the COM+ Application Cluster

Use Figure 8.18 as a guide for this deployment phase. It illustrates how we're going to deploy both Web and COM+ components to the two tiers of our environment. As you can see in this illustration, the actual members that we set up in our test environment are displayed.

Warning This scenario assumes that all object requests to the COM+ tier are routed via the Web cluster. If the COM+ cluster has any requests coming from servers outside the Web cluster or from clients running the Win32 API, the server resets that occur for each of the following deployments could disrupt these connections.

1. Take the COM+ cluster controller (CC – ACDW522AS) out of the routing list on the Web cluster controller (WC - ACDW516AS). 

   At this point any new object requests from RKWebCluster will not be directed to this controller; however, existing objects will continue to respond to method requests until they are released or the drain time in step 2 expires. 

2. Launch the New Deployment Wizard, and then deploy FMStocksCOM to the COM+ controller, CC, by using a drain time that you chose. 

3. Add the COM+ cluster controller (CC – ACDW522AS) back into the CLB routing list on the Web cluster controller (WC - ACDW516AS). 

4. Take the COM+ cluster member (C1 – ACDW811AS) out of the routing list on the Web cluster controller (WC - ACDW516AS). 

5. Launch the New Deployment Wizard again, and then deploy FMStocksCOM to C1. 

6. Add C1 back into the CLB routing list on the Web cluster controller (WC). 

At this point we have the new load-balanced FMStocks component installed and activated on all of the COM+ cluster members. Now we can apply the entire application to the Web tier.

Figure 8.18 Phase 1: Deploy the COM+ resources to the COM+ application cluster in two steps 

Phase Two: Install to the Web Cluster

To finish our deployment, all we have to do is deploy the FMStocks 2000 application to the Web cluster. Use Figure 8.19 as a guide for phase 2 of the deployment.

Figure 8.19 Phase 2: Deploy the Web resources to the Web cluster in two steps 

Use the following steps for phase 2 of the deployment:

1. Enable the FMStocks_DB.DBHelper component for load balancing. 

2. Take the cluster controller (WC – ACDW516AS) and one member (W2 – ACDW802AS) out of the load-balancing loop. 

3. Launch the New Deployment Wizard, and then deploy FMStocks 2000 to both the WC and W2. 

4. After the targets are reset, bring them back online for load balancing. 

5. Set the remaining server, W1, offline for load balancing. 

6. Launch the New Deployment Wizard again, and then deploy FMStocks 2000 to W1. 

7. Set W1 back online for load balancing, and then re-enable synchronization on the members on which you disabled it in step 2. 

Summary

The deployment scenario presented for a distributed application, as well as those scenarios based on a single tier, are not cast in stone. They merely illustrate how we handled application deployment based on the test environment that we set up. However, even though your own situations may differ (which is to say, different applications, different cluster sizes, and different server configurations), you can use the scenarios we've described as a reference for planning and developing deployment processes that are tailored to meet your company's operational requirements.

Resources

The following Web sites provide additional information about Windows 2000 Advanced Server and Application Center 2000.

Web Links

https://www.microsoft.com/com/default.asp 

The Microsoft COM technologies home page.

https://msdn.microsoft.com/library/default.asp 

The COM+ start page in the Platform SDK.