Large Site Configuration

The simplest way for Commerce Server sites to increase capacity is to add Web servers and distribute the Commerce Server components onto separate database servers. You should base your availability decisions on the expected usage of each database. To increase availability and hide site complexities from customers, you can place a single-IP solution in front of the Web services. You can use a combination of SQL Server clustering or SQL Server replication to increase the availability of the database tier. In a large Web cluster, all business logic can run on the stateless Web servers. However, in some environments, you might want to isolate some functions from the site shopping functions. For example, you might prefer to run pipeline components on a separate Web cluster, if the components are particularly CPU-intensive (such as encryption of large files) or if they require access to secure data (such as computing insurance rates while processing social security number, credit history, or medical reports). An example of a CPU-intensive function that you might want to run on a separate server is the generation of analysis models.

The following figure shows an example of a large site production environment of 10 to 100 servers.

Important

Commerce Server 2002 Data Warehouse does not support OLAP clustering.

This configuration separates each of the component databases onto its own Microsoft SQL Server cluster. In addition, the Catalogs database is installed over multiple load-balanced clusters. Additional Web servers are added to spread out the load on Commerce Server services and applications.

If your database tiers require more capacity than the four-node limitation in Windows Clustering, you should consider the following strategies for the database tier:

• OLAP servers. Add servers to a single-IP solution. Synchronize data by using archive/restore. Windows Clustering for OLAP is not supported.
• Catalog. Add servers to a single-IP solution. Synchronize data by using SQL Server replication.
• Order Form. Create multiple data partitions and distribute transactions across the partitions. For example, you can implement distributed SQL Server databases (federated views). For more information, see "Designing Federated Database Servers" in SQL Server 2000 Help.
• Profiles resource. Create multiple data partitions and distribute user data across the partitions. Data source partitions use profile properties designated as hashing keys to keep data together. Note that with this architecture, you should create partitions when you set up the site. If you add partitions to a site with existing user profiles, you have to reload user data. Partitioning is useful for both SQL Server and Active Directory profile stores. Scaling for Active Directory requires multi-forest design with trusts established from the domains in the user forests to the domain in the resource forest.

For more information about planning and deploying a large site configuration, see the Commerce Server 2000 Resource Kit.

Copyright © 2005 Microsoft Corporation.
All rights reserved.