Chapter 14: Application Center Interoperability

This chapter provides information about the products that have been extensively tested in Microsoft® Application Center 2000 (Application Center) cluster environment. A summary of the interoperability testing that was done with each product, as well as setup and configuration guidelines are provided.

Note Our product testing took place up until the time that Application Center was released. Since that time, additional service packs or hot fixes—which may affect interoperability by eliminating the need for work arounds—may have been released for these products. You should check new service packs or hot fixes for all of the products described in this chapter.

The primary goal of the product system testing was to determine the level of interoperability between Application Center and various products, as well as identify any issues related to setup or functionality.

A secondary goal was to go through the normal processes associated with installing and using the products together with each other. Activities and objectives for this goal included:

• Testing different setup scenarios. 

• Implementing and verifying individual product requirements, such as hot fixes and required software. 

• Testing different product upgrade scenarios. 

• Verifying product functionality in a cluster and ease-of-use.

• Identifying product features that could leverage Application Center to achieve usability, maintenance, or performance gains. 

• After establishing system test goals, objectives, and priorities, a general methodology was developed for testing all of the products covered in this chapter. 

Testing Methodology 

The following general approach was taken to testing all the products:

• Establish priorities for the areas to test, the products to test, and levels of testing. 

• Tests would be based on different combinations of configurations and scenarios. 

• Testing would be done by incrementally increasing the complexity of the configurations and scenarios. 

• Testing would be done via the product's user interface. 

  Note Automated testing was also done to observe product behavior under load and to obtain performance data. However, the level of interoperability was not determined by these tests. 

• Testing would focus on the features and operational scenarios that are most likely to be used. 

• Monitoring would be done at all stages of the testing process. 

Assumptions 

The following assumptions are made.

• You have installed Application Center on a server and used the product to create a cluster and are familiar with basic administrative tasks such as adding/removing members, creating an Application Center application, and working with monitoring and eventing. (Refer to chapters 4 through 8).

• If you are interested in learning about a specific product's level of interoperability with Application Center, you possess a working knowledge of that product, for example, Commerce Server 2000.

On This Page

Application Center Test Configuration
BizTalk Server
Commerce Server
Content Deployment Service 3.0
Host Integration Server
Site Server 3.0 and Site Server 3.0, Commerce Edition

Application Center Test Configuration

The basic Application Center configuration is similar to that described in other chapters, and is, for the most part, the same for all the products that were tested. The key issue is one of software installation sequencing; in some cases, Application Center must be installed first to avoid setup errors. The following configuration was used for the Application Center clusters that were used for testing product interoperability:

• Two network adapter cards installed on each cluster member 

• Two static IP addresses bound to the front-end adapter on the cluster controller, one static IP address bound to the front-end adapter for cluster members 

• One static IP address bound to the front-end adapter for servers in the COM+ application cluster

• All members on the same subnet 

• Homogenous file systems, at least to the extent that the Microsoft Windows® directory path and file system type (NTFS, for example) are the same on all members 

• All cluster members must either be in the same domain or the same workgroup 

• Each server must have a minimum of 162 MB of free disk space on the install partition 

  Note Setup will not warn you if there is not enough free space. 

• Microsoft SQL Server™ is not installed on any members. 

Operating System 

The test systems all used Windows 2000 Advanced Server with Service Pack 1 applied.

Note We recommend that you remove your current installation of Inoculan or other virus protection software before installing Service Packs (SPs) and hot fixes. After removing this software, restart the computer before installing the software. After you've finished installing the required software, you can re-install your virus protection software.

Pre-Setup Verification 

We recommend that the cluster members used for test servers have a clean installation of the operating system, and that any preview or beta versions of Application Center are removed before installing Application Center.

Application Center 2000 Cluster Installation 

Refer to Chapters 4, 5, and 8 for detailed information about creating and configuring various types of cluster topologies.

BizTalk Server

In addition to the stated test goals and objectives, the test team was very interested in seeing how the BizTalk Server implementation of clustering—the BizTalk Group—co-existed with the Application Center implementation of clustering.

Test Results and Observations

All the examples described in the BizTalk Server tutorial were used and no problems were discovered after certain setup issues, such as the product installation sequence, were resolved. BizTalk elements, such as the conversion rules repository were identified as resources in an Application Center application, and no additional or special resources were needed in order to successfully scale out BizTalk on a cluster. However, it should be noted that we did not test any stage and deploy scenarios.

BizTalk Server Optimization

The repository that BizTalk Server uses for storing the conversion rules are used for converting XML documents (for example, the rules for converting a Purchase order to an Invoice are stored locally and referenced by a URL that can use the computername, localhost, or the IP address for localhost). In a cluster environment, this means that all the BizTalk servers end up referencing the initial repository, which resides on the cluster controller. If the repository is only installed on the controller, it presents a single point of failure, as well as a potential performance bottleneck. Therefore, we recommend that a copy of the repository be installed on each cluster member.

To install the repository on all members, as well as ensure that the local copy of the repository is referenced when appropriate, you should identify the repository as an Application Center application resource and specify 127.0.0.1 (rather than the computername or localhost) as the URL for the repository when you install BizTalk Server on the cluster controller. Each time a member is added to the cluster, the repository will be replicated to the new member; whenever the member receives a request, it will reference the local copy of the repository.

Test Environment

The test environment used two load-balanced Web clusters, one for the buyer side and one for the seller side. Each of these clusters used its own back-end SQL server database whose name was specified when BizTalk Server was initially installed on the cluster controller. Figure 14.1 illustrates the cluster topology that was used for running the application tests provided in the BizTalk Server 2000 Tutorial.

 

Figure 14.1 The BizTalk Server test clusters 

Configuration Notes

We set up the test topology using the following software builds installed in the specified sequence (refer to "Installation Sequence," later in this chapter).

Cluster Member Configuration

• BizTalk Server, including hot fixes 

  Note For a detailed description about product installation requirements, see the Microsoft BizTalk Server 2000 Installation Guide. To view this document, in the first screen of the Welcome to the Microsoft BizTalk Server 2000 Setup Wizard, click Installation Guide.

• BizTalk Server 2000 Tutorial components 

• Application Center

  Note During Application Center setup, you can install the required Windows 2000 Service Pack and hot fixes. 

Installation Sequence

Both Application Center and BizTalk Server store information in a database and use Microsoft Data Access Component (MDAC) to access these databases. Application Center uses MSDE as its database manager, which is installed during Application Center setup.

The key issue is MDAC versions. Windows installs MDAC version 2.5; whereas, Application Center uses MDAC version 2.6. The Application Center Setup program updates MDAC to the newer version (2.6). If you install BizTalk Server before Application Center, there will be some processes running that may be using the MDAC components. If this is the case, these files will be locked when Application Center Setup is executed and Setup could fail. Therefore, the recommended installation sequence is:

• Application Center

• BizTalk Server

If you cannot avoid installing Application Center on a system that already has BizTalk Server installed, you can circumvent a potential setup failure by making sure that the MDAC components on the server are updated to version 2.6. If you installed the pre-SP2 hot fixes during Application Center setup, MDAC is updated automatically. However, if the target system already has Windows 2000 SP2 installed, you will have update MDAC manually by executing SQLredis.exe, which is located on the Application Center CD. Make sure that you do this before running Application Center Setup.

BizTalk Server Monitoring

Application Center provides a number of sample monitors that users can use as a starting point towards application monitoring and management. These sample monitors are located in the Samples directory under the directory where Application Center was installed. There is a set of monitors dedicated to watch and manage BizTalk Server services, performance counters, and events.

For additional information about these sample monitors, see Chapter 9, "Working with Monitors and Events."

Testing Scenario

The testing scenario was based on the BizTalk Server 2000 Tutorial. This tutorial implements a business-to-business (B-to-B) automated procurement system between two companies: ProElectron, Inc., which is the buyer organization, and Bits, Bytes, & Chips, Inc., the seller organization. Figure 14.2 illustrates this hypothetical B-to-B procurement system.

 

Figure 14.2 The BizTalk Server B-to-B procurement system 

Testing Summary

We carried out all of the tasks described in the BizTalk Server 2000 Tutorial without encountering any problems.

Note Application Center will not replicate any local MSMQ queues on a cluster member.

Commerce Server

The Commerce Server testing consisted of implementing and working with different Commerce Server elements in a cluster environment. This includes:

• Synchronizing Custom Sites across a cluster 

• Carrying out tasks involving Retail sites, Supplier sites, and the BizDesk 

Custom Site Synchronization

This part of our Commerce Server testing deals with synchronizing Commerce Server Custom Site configuration information to servers as they are added to the cluster. This information is essential for supporting Commerce Server's implementation of its Web farm concept.

Test Results and Observations

Application Center can replicate Commerce Server Custom Sites successfully; however, some minor configuration is required to facilitate replication. This is due to the fact that Application Center does not automatically update the Commerce Server administration database, MSCS_Admin, on the SQL Server backend when you add or remove an Application Center cluster member.

Test Environment

A subset of the test environment described in "Retail and Supplier Sites, BizDesk" test section, later in this chapter, was used for Custom Site synchronization tests. The test bed consisted of a load-balanced Web cluster that was using multi-node configurations.

Configuration Notes

We used the JoinWebFarm() method in the Commerce Server Global.asa file in conjunction with Microsoft Health Monitor 2.1 (Health Monitor) eventing—provided by Application Center—to automatically update MSCS_Admin whenever a new member is added to the test cluster. Application Center and Commerce Server must be installed on the cluster controller and on the cluster member before using the following configuration process.

Note You can use PUP to perform the installation of your Custom Site on a new cluster member, provided that you follow the steps described in the following section.

Enabling Custom Site Synchronization

The first step is to copy the CSACIntegrationInterface.mof and GoOline.vbs files to the C:\ partition (or the partition where the operating system is installed) on the server that will be added to the cluster. This must be done before the new member is added to the cluster.

CSACIntegrationInterface.mof 

This file will create a new Windows Management Instrumentation (WMI) class called CSACIntegrationInterface in the Application Center namespace on the new cluster member.

This .mof file contains the following instructions:

#pragma Namespace("\\root\\MicrosoftApplicationCenter")
[singleton: DisableOverride ToInstance ToSubClass]
class CSACIntegrationInterface
{
boolean State = FALSE;
};
instance of CSACIntegrationInterface
{
State = FALSE;
};

GoOnline.vbs 

This file updates the time stamp of the Global.asa file, an action which is necessary in order to properly execute the JoinWebFarm() method.

This Microsoft Visual Basic® Scripting Edition (VBScript) file contains the following code:

Dim ServicesObj
Dim Instance
Dim Shell
Set ServicesObj = GetObject("WinMgmts:{impersonationLevel=impersonate}!/root/MicrosoftApplicationCenter")
Set Instance = ServicesObj.Get("CSACIntegrationInterface=@")
if Instance.State = false then
' touch the global.asa
set Shell = WScript.CreateObject("WScript.SHell")
call Shell.Run("D:\WINNT\idw\touch.exe D:\Inetpub\wwwroot\myretail\global.asa", 0, true)
set instance = nothing
set Instance = ServicesObj.Get("CSACIntegrationInterface=@")
Instance.State = true
Instance.Put_
set instance= nothing
end if
call WScript.Quit

Note The path statement in the "call Shell.Run…" line in the preceding code sample should reflect your installation of Windows 2000. In addition, you should use the name of the retail site that you created instead of "Myretail" under D:\Inetpub\WWWroot\.

After these two files are copied to the new member, you have to compile the CSACIntegrationInterface.mof file in order to create the CSACIntegrationInterface class in WMI.

The next step is to set up the two data collectors—with associated thresholds and actions—that are needed. We used two types of data collectors:

• A WMI instance collector named Binding Complete 

• A WMI Event Query collector named Synchronization Complete 

See also: Chapter 9, "Working with Monitors and Events" 

Binding Complete 

The purpose of the WMI instance collector, Binding Complete, is to expose the interface to online and offline actions that are triggered when the collector's threshold changes, which is to say, to Normal or to Critical.

We used the configuration information provided in Table 14.1 to configure this data collector.

Table 14.1 Binding Complete Configuration 

General tab	Details tab	Actions
Name: Binding Complete	Namespace: ROOT\MicrosoftApplicationCenter Class: CSACIntegrationInterface Instance: CSACIntegrationInterface=@ Properties: State = checked	If the data collector's condition evaluates to Normal, execute the Bring Server Online action. If the condition evaluates to Critical, execute the Take Server Offline action

After Binding Complete is set up, it's necessary to create and configure a threshold for the data collector. Using the Expression tab in the Threshold Properties dialog box for Binding Complete we added the following expression: "If the current value for state is not equal to True, the status changes to Critical." This ensures that member synchronization is only executed once.

The final step in setting up our data collector is associating an action that will be fired when the threshold is crossed. We used the Health Monitor Actions menu and selected New/Command Line Action to open the Command Line Action Properties dialog box shown in Figure 14.3.

 

Figure 14.3 Command Line Action Properties dialog box 

The following configuration information was added on the Details tab:

File name: C:\WINNT\System32\CScript.exe 

Working directory: C:\ 

Command line: C:\WINNT\System32\CScript.exe GoOnline.vbs 

Note Make sure that the preceding configuration information points to the partition where Microsoft Windows NT® is installed on the system that you are configuring.

To finish configuring this new action, we named the action Cscript GoOnline.

Synchronization Complete 

The purpose of this data collector is to monitor an Application Center replication session event to determine if the session succeeded or failed.

This time we created a WMI Event Query data collector and configured it as described in Table 14.2.

Table 14.2 Synchronization Complete Configuration 

General tab	Details tab	Actions
Name: Synchronization Complete	Namespace: ROOT\MicrosoftApplicationCenter Class: MicrosoftAC_Replication_Session _General_Success_Event Properties: EventID	If the data collector's condition evaluates to Critical, use Cscript.exe to execute GoOnline.vbs

The threshold for Synchronization Complete, shown in Figure 14.4, uses the number of instances collected for the EventID.

 

Figure 14.4 The threshold for Synchronization Complete 

As shown in Figure 14.4, the expression for the threshold is: "If the current value for # of instances collected is greater than 0, any time this occurs, the status changes to Critical."

Now that our data collectors are fully configured, we can add a new member to the cluster by using the Application Center snap-in. There are two ways to confirm the success of this operation:

• Use the Commerce Server snap-in. 

• Use the Commerce Server administration database, MSCS_Admin. Open the Resource table and find the site ID. In ResourceProps, check s_WebServerMachine and s_WebServerName. The new cluster member should be listed here. 

  Note This technique is not recommended for anyone who is not familiar with the structure of the Commerce Server administration database. 

Retail and Supplier Sites, BizDesk

This series of tests was designed to verify that all the features associated with the BizDesk, the Retail site, and the Supplier site functioned as expected in an Application Center cluster.

Test Results and Observations

Several manual tests were conducted by using the Commerce Server user interface. All of the following tests passed without any problems:

• Initial synchronization succeeds when a member is added to the cluster. 

• Cluster members stay in synchronization while the controller is pushing changes to the members. 

• The .ini files for all the sites are successfully synchronized across the cluster. 

• The Microsoft Internet Information Services 5.0 (IIS) metabase settings are replicated correctly. 

• All site content files and file types are replicated correctly. 

In addition to these user interface tests, we tested the Application Center Synchronization service to evaluate how it handled Commerce Server site configuration and content replication across a cluster.

Test Environment

The cluster topologies that we used in our testing are illustrated in Figures 14.5 and 14.6.

Figure 14.5 illustrates a scaled-out test bench with eight clients, four Web servers, and one back-end SQL Server database.

 

Figure 14.5 Commerce Server and the BizDesk hosted on a single Web cluster 

Figure 14.6 shows a test bench that uses two clusters, one for hosting Commerce Server, and the other for hosting the BizDesk.

 

Figure 14.6 Topology with Commerce Server and BizDesk hosted on separate load-balanced Web clusters. 

Configuration Notes

The following product installation notes should be followed to ensure that you have a clean and fully functional server configuration. The same operating system and Application Center installations described in earlier tests were used for this particular test bed.

SQL Server 2000

For our tests we used SQL Server 2000. The following installation notes describe the installation sequence, service packs, hot fixes, and add-ons that we used.

• When you install SQL Server you must install full-text search support. During Setup, use the Custom installation option, and then select full-text search support. If you have already installed SQL Server, reinstall the product by using the Custom option. In the Select Components dialog box click Full-Text Search.

• If you want to use the Commerce Server PUP utility or the Data Warehouse feature, SQL Server must be configured as case-sensitive. 

  If you're running SQL Server 7.0, you will need to install the following:

  • SQL Server Service Pack 2 

  • SQL Server 7.0 OLAP Services 

  • SQL Server OLAP Services Service Pack 2 

  • OLAP Manager Add-in 

  • COM+ Hot Fixes 

  Tip Follow the Commerce Server installation procedure and recommendations to ensure that you configure the SQL database correctly. 

Commerce Server 2000

This section describes how we installed and configured Commerce Server 2000 on each of our test systems.

Note If you installed a pre-release version of Commerce Server, you must uninstall this version before installing the released version of Commerce Server.

Installing Commerce Server 

When you run Commerce Server Setup, make sure that you select the Complete option so that all the product components are installed. Table 14.3 lists the configuration options and settings that we used when we ran Commerce Server Setup.

Table 14.3 Commerce Server Setup Options and Configuration 

Step	Configuration
Administration Configuration Database	SQL Server computer: localhost User name: sa Password:
Direct Mail Database Configuration	User name: sa Password: Windows 2000 user account: Password:

After Commerce Server Setup finishes, a folder containing the available PUP packages is displayed. We ran the Retail.pup package to install the Retail site on our system. The next table (Table 14.4) describes the options that we chose and configured when we used the PUP utility to unpackage the Retail.pup package.

Table 14.4 Retail Site PUP Options and Configuration 

Option	Configuration
Commerce Server Unpackager	SQL Server computer: localhost User name: sa Password: Default Web Site: IIS Web Site
Datawarehouse Properties	User ID: SA Password: Database: servername for localhost
Authentication Service Settings	Enable Commerce Authentication: checked
Connection Information for BizData Store	User ID: SA Password: Server name: localhost
Information for OLEDB Datasource	BizData Store: checked

After you've run Setup, you'll see the Unpacking is Complete dialog box, which lists the SQL databases and IIS applications that were created. For our setup, the Retail and RETAILBizDesk applications were created on the Default Web Site. To verify that the Retail install was successful, open https://localhost/Retail/default.asp in Internet Explorer.

Warning If you unpack more than one site, make sure that each BizDesk has a unique name. If you don't, the most recent installation will overwrite an existing BizDesk.

Business Desk Client Setup 

We launched the Business Desk Client Setup by opening https://localhost/Retailbizdesk/ in Microsoft Internet Explorer. In the Browse for Folder dialog box, we located and accepted the Commerce Server 2000 folder as the default, and then closed the browser.

Note If the Microsoft ActiveX® controls won't download and display in your browser, follow the steps in the Business Desk Client Setup dialog box to enable all entries under ActiveX controls and plug-ins. This process creates a Retail Business Desk shortcut in the Startup menu and on the local desktop.

After you finish installing Commerce Server, you should create an Application Center application that identifies all of the Commerce Server Web sites, files, and components as application resources. This will ensure that this content is synchronized across the cluster.

Test Scenarios

We conducted both manual and automated tests during our evaluation of Commerce Server.

Manual Tests

We used the tutorial and sample sites provided with Commerce Server to conduct our manual tests. These test were done on a stand-alone Commerce Server system, as well as on a two-node, load-balanced Web cluster. In both cases, no problems were encountered during the testing.

Automated Tests

We ran a selection of script-based automated tests to simulate customer activities at a Commerce Server site. The scripts used the following pages and tasks to simulate users visiting the site:

• Default Page—an Active Server Page (ASP) page with graphics that serves as the home page. 

• Category Browsing Page—a page where users browse for categories and items. 

• Item Detail Page—a page that provides a detailed description of an item. 

• Keyword Search—used to simulate a keyword(s) catalog search. 

• Shopping—this includes User Login, Add and Edit Cart content, and Payment activities. 

An activity mix, based on marketing assumptions derived from historical visitor behavior at the Microsoft Web site, was applied to the automated tests.

Content Deployment Service 3.0

The Content Deployment Service (CDS)—previously named the Content Replication Service—is part of the Site Server 3.0 product and is also included with Application Center 2000. The CDS program is in the Content Deployment Service directory on the Application Center CD.

Note Some of the Site Server features used CDS to deploy content from one computer to another. For example, the Site Server search engine creates a catalog on one server, and then deploys the new catalog to other servers that are generating search requests.

Because there are design similarities between the Application Center replication engine and CDS, these products were tested to determine if there were any compatibility issues when both products are installed and used on the same system.

Test Results and Observations

The testing that was conducted with several different projects did not indicate any co-existence problems between CDS and Application Center installations on the same server. However, since the two deployment systems function slightly differently, there is one thing that you should be aware of—the possibility of overwriting existing directories or virtual directories on an Application Center cluster controller.

Protecting Target Directories

When you deploy a project from a CDS source to a target, you can specify the deployment source simply by referencing the ROOT\ for the directories and files that you want to deploy. One of the settings for a CDS project is Preserve content on destination when deleting from source. When this switch is set, existing content on the target will be protected. Figure 14.7 illustrates how this works.

 

Figure 14.7 CDS and Application Center deployment 

Before deploying the CDS Project ("Deploy1" in Figure 14.7) from the CDS server (A) to the Application Center Staging Cluster (B), you can specify that selected content on this destination, the App2, App3, and App4 directories in our example, should be preserved. This will allow you to specify ROOT\ as a resource on the project and these directories will not be overwritten when CDS copies the files contained in the Deploy1 project to the target.

Unlike CDS, Application Center does not support content preservation for directories with identical names. For example, if you create an Application Center application on the Staging Cluster (B) and specify ROOT\ as a resource, all the directories under ROOT\ will be deployed to the target in the Application Center Web Cluster (C) and like named directories will be overwritten. When you add directories as resources to an application on a staging cluster, you must explicitly identify each directory. For example, ROOT\App1 and ROOT\App5. This will ensure that the other directories (App2, App3, and App4) are preserved on the target.

Test Environment

Figure 14.8 illustrates the test environment that we used. This topology was used to deploy content from a CDS server to a single-node Application Center staging cluster. The new content on the staging cluster was then deployed to a load-balanced Application Center Web cluster.

 

Figure 14.8 CDS to stager to cluster 

Configuration Notes

We set up the test topology using the following software builds installed in the indicated sequence.

CDS Server Configuration

• Windows 2000 Advanced Server with SP1 applied 

• Content Deployment Service 3.0 

CDS Target/Staging Cluster Configuration

• Windows 2000 Advanced Server with SP1 applied 

• Content Deployment Service 3.0 

• Application Center

Web Cluster Member Configuration

• Windows 2000 Advanced Server with SP1 applied 

• Application Center

Test Scenario

We tested the following scenario using the topology described in Figure 14.8.

You can follow these steps to duplicate these tests.

1. Create a directory with sample content on the CDS server. 

2. Use the CDS command-line tool or the MMC to create a CDS project on the CDS.

   This project identifies the directory created in the previous step as the source for content deployment. 

3. On the target server, use the CDS command-line tool to create a CDS project that can be referenced to receive content. 

4. Deploy the CDS project to the target. 

5. Create an Application Center Web cluster on the CDS target. This system can now serve as a staging cluster, in addition to functioning as a CDS deployment target. 

6. On the staging cluster, create a new Application Center application and identify one resource, the directory that is specified in the CDS project. 

7. Create a three-node Application Center cluster with network load balancing (NLB) enabled.

   This cluster is the final deployment destination.

8. Deploy the Application Center application created in step 5 from the staging cluster to the Web cluster controller.

   After the controller receives the new application, the new content is synchronized to the cluster members. 

The preceding steps were repeated by using different content mixes and projects of varying sizes to determine if these factors would have an impact on interoperability. They did not.

Host Integration Server

After the functional tests were run, extensive performance testing was also conducted. This performance testing focused on determining the potential performance gains that Host Integration Server (HIS) could realize by leveraging Application Center Component Load Balancing (CLB), especially for long lasting—heavy weight—transactions.

Test Results and Observations

Testing did not reveal any interoperability issues between HIS and Application Center, and the performance tests indicated that appreciable performance gains could be attained by using CLB for COMTI components.

In our simulated load tests (using up to 1000 clients) the difference in transactions per second between a single HIS server and a two tier (2 node NLB Web cluster and 2 node CLB COM+ application cluster) was nearly 2:1. The performance indicators that we used for our measurements are summarized in Table 14.5.

Test Environment

We developed the final two-tier topology, illustrated in Figure 14.9, in several phases.

During the first phase, we set up a one-node cluster that used HIS to access data on a simulated mainframe-based database. The general setup sequence was as follows:

• Install Application Center and create a cluster. 

• Install HIS and register the COMTI components as resources in an Application Center application. 

After the environment was fully configured, we used ASP pages to instantiate a COMTI component that performed credit and debit transactions on the database backend.

Next, we scaled out the cluster and used NLB to load-balance the incoming client requests. The COMPTI component was instantiated locally by whichever Web server handled a given incoming request.

The final phase involved creating a COM+ application cluster that could be used as a second tier for implementing CLB. (For information about implementing CLB by using two clusters, see Chapter 5, "Load Balancing.")

 

Figure 14.9 Scaled out, two-tier HIS test environment 

Testing Scenario

Custom in-house applications were used for running our tests. These applications work in conjunction with each other and enable client-host transaction simulation by using variable data types. Various performance counters were also used to collect performance data for the different tests.

Variable Data Types

In addition to running the tests with a variable number of hosts and client objects, different data characteristics were used. These data variations were used to determine the impact of different data types on performance.

Performance Counters

The test performance counters described in Table 14.5 were used to measure transaction activities and provide performance data.

Table 14.5 Test Settings and Counters 

Setting	Description
Calls started	The total number of method calls that have been started across all client objects.
Calls completed	The total number of method calls that completed successfully across all client objects.
Calls failed	The total number of method calls that failed across all client objects.
Calls per second	The effective (combined) throughput rate, expressed in calls per second, for all the client objects.
CPU% utilization	The percentage of CPU utilization that is occurring during the execution of a test case. This measure is the same as the one provided by the Task Manager; however, because it is derived with the Performance Data Helper, the overhead associated with the Task Manger is eliminated.
Average call time	The average method invocation time (including the 2PC time for transactions) that is achieved across all client objects.
Fastest call	The fastest method invocation time achieved by a single client object during the test.
Slowest call	The slowest method invocation time achieved by a single client object during the test.
Average commit time	The average two phase commit time that is achieved across all client objects that are using transactional semantics.
Fastest commit time	The fastest two-phase commit time for an object that is using transactional semantics.
Slowest commit time	The slowest two-phase commit time for an object that is using transactional semantics.

Site Server 3.0 and Site Server 3.0, Commerce Edition

The Site Server 3.0 testing consisted of two parts:

• Site Server 3.0 

• Site Server 3.0, Commerce Edition 

Site Server 3.0

In addition to testing to determine if there are interoperability problems, we also wanted to identify which features could be used in a cluster environment by implementing minor topology or configuration changes. Although performance testing was not carried out, we looked for areas where Site Server could leverage Application Center to improve usability and site management.

Test Results and Observations

All the product features functioned as expected after the test environment was properly configured.

Test Environment

We used a two-node Application Center Web cluster with a back-end SQL Server database for our test bed. Figure 14.10 illustrates this topology.

 

Figure 14.10 Base topology for testing Site Server 

Configuration Notes

We set up the test topology using the following software builds installed in the indicated sequence.

• Site Server 3.0 

• Site Server hot fix for Windows 2000 

• Site Server 3.0, Commerce Edition 

• Site Server 3.0, Service Pack 3 

• Application Center 2000 

Following setup and initial testing, we discovered that a hot fix and some configuration adjustments were required for the following:

• The Membership Services dynamic-link library (DLL) 

• The Lightweight Directory Access Protocol (LDAP) used by Site Server 

• Web Site Custom Errors 

• The Membership Mapping settings 

Membership Services Hot Fix

We identified a problem involving the membership services DLL, mss_log.dll. This library is an ISAPI filter that is loaded into the Inetinfo.exe process. Sometimes it fails to load by causing a failure when a user tries log on to a Web site—this process uses membership services. The Site Server team delivered a hot fix that resolves this issue and the fix is available from Microsoft Product Support Services (PSS).

LDAP services

The Site Server Personalization and Membership features are based on the LDAP service. There are two possible configurations for the LDAP service root database; it can either be configured to access a local .mdb file or a SQL Server database.

The LDAP root database stores attributes and properties for many objects, such as users, applications, and distribution lists (DLs). This database is updated during user interaction with any Web application that uses the Personalization and Membership features. In a single server environment, using a local .mdb file does not cause problems; however, in a cluster environment, maintaining .mdb integrity is problematic whenever the cluster is synchronized.

We recommend using a centralized back-end SQL Server database as the LDAP root database to ensure data integrity and consistency among cluster members. Figure 14.11 illustrates this configuration.

 

Figure 14.11 Application Center cluster with back-end SQL Server/LDAP database 

It's necessary to configure the LDAP service to access a centralized SQL Server. This involves creating and configuring the database. The steps in this process are summarized in the following section.

Creating a SQL Server LDAP Root Database 

• In Site Server Service Administration, open the New Membership Server Wizard. 

• Create a new Membership Directory.

• After specifying Authentication Mode, Name of the Membership Directory, and Account, you will be prompted to select the database type. Select the Microsoft SQL Database option. 

• After selecting the database type, provide the required connection information: server name, database name, user name, and password.

The specified database name should be a valid database name on the specified server.

Once complete, the New Membership Server Wizard will create all database objects such as tables and stored procedures, and then populate them with initial data.

Web Site Custom Errors

New entries are added to the Custom Error property of a Site Server Web site each time the membership mapping setting changes to reflect changes in a Membership server instance. Site Server adds these entries directly to the metabase. However, some of these entries are incorrect and point to file name paths that are not valid. This prevents Application Center from synchronizing the affected Web site(s) across the cluster. Figure 14.12 provides an example of these file name paths that are not valid.

 

Figure 14.12 Entries on the Custom Errors tab that are not valid 

The workaround for this is as follows:

1. Open the Site Server Commerce web site Properties dialog box, and then click the Custom Errors tab. 

2. Locate any entries that have a single space before the complete file name path. 

3. Double-click one of these entries to open the Edit dialog box, and then click OK. 

The IIS web site Properties dialog box will correct the entry automatically by removing the space before the complete file name path for the custom error. Figure 14.13 shows the invalid entries after they have been corrected.

 

Figure 14.13 Custom errors after correcting entries that are not valid 

Membership Mapping Settings

The membership mapping setting is not replicated by Application Center Synchronization services because it is not stored in the /LM/W3Svc/ path that Application Center uses.

The workaround for this involves manually adding a metabase entry so Application Center will pick it up for synchronization.

For example, suppose you have a Site Server Web site named Site Server Commerce Membership Samples Web site with the following metabase entries:

Web site: /LM/W3SVC/5

Membership mapping: /LM/MEMBERSHIP/MAPPINGS/W3SVC/5

If you had an Application Center application named Site Server Commerce Membership Samples Site you could add this information as application resources by using the Application Center command-line tool as follows:

D:\>ac application /addresource /name:"Site Server Commerce Membership Samples Web Site" 
/resourcetype:iis /resourcepath:/lm/membership/mappings/w3svc/1

Figure 14.14 shows the results of this action in the resource list for the "Site Server Commerce Membership Samples Web Site" application.

Figure 14.14 The Applications view showing the "Site Server Commerce Membership Samples Web Site" and its resources 

Testing Scenario

Table 14.6 summarizes the Site Server feature set that we tested by using the product user interface.

Table 14.6 Site Server Feature Set 

Feature	Implemented by	Description
Information publishing	Content Management	Multiple content that authors can submit, tag, and edit content with a drag-and-drop Web interface. Site editors can then approve, edit, and enforce uniform guidelines for content.
	Content deployment	Collect content for review on a staging server, and then deploy it to destination Web servers. Deploy content across a single server or to multiple servers, as well as to UNIX-based servers.
Information searching	Search	Use Search Server to find information in a range of sources—intranet and Internet Web sites, files, ODBC databases, and Microsoft Exchange Server folders.
Information delivery	Personalization	Deliver personalized content on Web sites. Administrators can author personalized pages with the new Rule Builder tools. Use the Direct Mailer tool to build targeted mailings. All user information is stored in a LDAP directory based on SQL Server.
	Knowledge Manager	Users can browse, search, share, and subscribe to relevant information with a centralized Web-based application that integrates the Site Server knowledge management features.
	Push	Microsoft Active Channel Server builds, manages, and schedules the delivery of organized information by using multicast technology to deliver channels.
Analyzing site usage	Analysis	Generate site usage reports and classify site usage data (integrated other information) to develop profiles of site visitors and their behavior. Enterprise management capabilities provide the ability to centrally administer multi-homed or distributed server environments.

Site Server Catalog Building and Searching

The Site Server Search feature was of particular interest for seeing how the product behaved in a cluster environment. This feature was tested extensively to see if it was possible for a Web user to make a query to a cluster, receive the first query results page from one member, and then retrieve the second query results page from a different member.

To set up this test case we created a catalog by using one of the cluster members. During the build process, we used the Site Server propagation feature, which allows you to specify servers that received updated catalogs and to identify the second cluster member as a target for receiving the updated catalog when the new catalog was built.

As shown in Figure 14.15, ACSINTSRV04AS built five catalogs that were then propagated to ACSINTSRV03AS.

Figure 14.15 The Site Server Search snap-in showing the Catalog Build and targets 

Optimizing the Catalog Build and Propagation Process 

The cluster topology suggested in Figure 14.16 leverages the Application Center Synchronization and Deployment feature to optimize the process for building and propagating new catalogs to cluster members. This topology includes an Application Center stager with Site Server installed, which enabled it to be used as a Catalog Build Server.

 

Figure 14.16 Topology for building and propagating new Site Server catalogs 

Referring to Figure 14.16, the steps in the catalog build process are as follows:

1. The stager/build server gathers information from Web servers (Internet and intranet) and creates a catalog.

   After the build is finished, Site Server doesn't have to propagate the new catalog. 

2. The Catalog is registered as a file resource in an Application Center application. 

3. The new catalog is deployed to the Web cluster controller, by using either the Application Center deployment wizard or the Application Center command-line tool. 

4. The cluster controller synchronizes the new catalog across the cluster. 

Clients can conduct searches against the cluster and results are returned from any cluster member, which is transparent to the user.

Site Server 3.0, Commerce Edition

Interoperability testing for Site Server 3.0, Commerce Edition focused on the features that extended the base Site Server feature set. As in the case of Site Server 3.0, no performance testing was conducted.

Test Results and Observations

All of the functional tests conducted against the Site Server, Commerce Edition feature set passed without any problems.

Test Environment

The test environment used a Web cluster with two nodes and a back-end SQL Server database, as illustrated in Figure 14.10.

Configuration Notes

The following configuration settings were applied in order to facilitate Site Server, Commerce Edition testing.

Load Balancing Configuration

The Web cluster was configured to load balance all requests equally between the two members by setting the client affinity to None and by disabling the request-forwarding feature.

Note The Site Server 3.0, Commerce Edition infrastructure doesn't store any session state information on the server that processed the last request; request forwarding is not required. Client session information, such as a shopping cart addition or checkout request, is stored in the back-end database.

URL Redirects

Site Server, Commerce Edition stores the host name and redirected closed page explicitly in the back-end database. These setting are configured in the Commerce web site Properties dialog box for the site that we created by using the Site Server, which is shown in Figure 14.17.

 

Figure 14.17 The Commerce web site Properties dialog box 

Referring to Figure 14.17, note that the settings for the redirect URL, Secure host name and Nonsecure host name are specified by using the cluster's virtual IP address.

Typically, links in a Web page point to other pages hosted on the same server. However, when a link points to a page on a Site Server, Commerce Web server, the links contained in the response will point to the host specified in Nonsecure host name, in which case, the page is not secured.

These settings are stored in the Site.csc file. You should change this configuration on the cluster controller, and then synchronize the cluster to ensure that all the members have this updated configuration information.

Note This process should also be following when closing a Site Server, Commerce Edition store. When you close a store, this status information is updated in the Site.csc file on the server that processed the request to close the store. At this point, that server will stop processing store requests. By closing the store on the controller, and then synchronizing the cluster, you will ensure that all members stop processing requests for the store that is closed.

Testing Scenario

We tested the Site Server, Commerce Edition feature set by using the following scenarios:

• The Volcano Coffee sample application 

• A new Commerce Web site that was created with the Site Server wizard 

Testing Summary

We carried out a variety of tests by using the preceding scenarios and did not encounter any problems.