Time flies when you are having fun. It is hard to believe, but this month marks exactly one year since Commerce Server 2009 became commercially available.

One of the things been long overdue is an in-depth, guided tour of Commerce Server 2009. Especially one that provides some behind-the-scenes insight into the functionality provided – and “why” things were implemented in the way that they are. So, without further adieu – here it is…

As a software product release, Commerce Server 2009 was approached with three principles in mind:

·     Deliver more capabilities to end-users

·   Modernize the technology within Commerce Server

·  Minimize migration pain from Commerce Server 2007

The challenge in that is that these principles – especially the latter two – are somewhat diametrically opposed to one another. Each of these points shall be spoken to over this and the subsequent two postings in this series, the second and third of which shall provide more specific in-depth looks at:

·         SharePoint Commerce Services

·         Multi-Channel Commerce Foundation

For the balance of this post, a quick look at the usually boring component of Setup and Configuration is warranted. Commerce Server upgrades have traditionally been a painful and destructive process. You could never just install it and have things work. With CS2009, we elected to change that – as part of delivering upon the tenet of minimizing migration pain.

Functionality delivered in Commerce Server 2009 is a super-set of Commerce Server 2007. The release was exhaustively backward compatibility tested to ensure that Commerce Server 2007 applications would run without any tweaking or modification – by purpose of very strict design. Hence, CS2007 customers can be assured that their stuff “will just work” without modification. All new capabilities can be leveraged a la carte on top of an existing installation.

A la carte deployments are probably one of the most overlooked virtues of Commerce Server 2009. Imagine having a large investment in CS2007 that is not in a place to be changed – and then leveraging CS2009’s new capabilities to add, say, Mobility or a promotion/event-specific site – all without touching the original site. Imagine the possibilities…

Hence, to deliver as friction-free a setup experience as possible, CS2009 is easily installable over an existing Commerce Server 2007 installation. It can simply configure the latest and greatest bug fixes (including those post-Commerce Server 2007 Service Pack 2) and the new functionality – all without breaking anything in CS2007.

Hopefully this helps provide some context. Next up – a look at SharePoint Commerce Services.

I have now concluded the series of material constituting the Deployment Series of blog posts – and thus my brain-dump of the answers to all of the questions I find myself repeatedly answering. For quick access, please refer to:

• Part 1 – Kick-Off: http://blogs.msdn.com/rdonovan/archive/2010/03/15/commerce-server-2007-2009-deployment-series-part-1-kick-off.aspx
  
• Part 2 – Types of Deployments: http://blogs.msdn.com/rdonovan/archive/2010/03/17/commerce-server-deployment-series-part-2-types-of-deployments.aspx
  
• Part 3 – Choosing the Right Software: http://blogs.msdn.com/rdonovan/archive/2010/03/19/commerce-server-deployment-series-part-3-choosing-the-right-software.aspx
  
• Part 4 – Stand-Alone & Dedicated Servers: http://blogs.msdn.com/rdonovan/archive/2010/03/22/commerce-server-deployment-series-part-4-standalone-and-dedicated-servers.aspx
  
• Part 5 – Single-Environment Web Farm: http://blogs.msdn.com/rdonovan/archive/2010/03/24/commerce-server-deployment-series-part-5-single-environment-web-farm.aspx
  
• Part 6 – Multi-Environment Deployments: http://blogs.msdn.com/rdonovan/archive/2010/03/26/commerce-server-deployment-series-part-6-multi-environment-deployments.aspx
  
• Part 7 – Building and Testing Environments: http://blogs.msdn.com/rdonovan/archive/2010/03/29/commerce-server-deployment-series-part-7-building-and-testing-environments.aspx
  
• Part 8 – Maintaining a Healthy System: http://blogs.msdn.com/rdonovan/archive/2010/03/31/commerce-server-deployment-series-part-8-maintaining-a-healthy-system.aspx

Hope this helps!

Backup and Restore

Having good backups – and tested restore processes – is an important element of any mission-critical systems deployment. Commerce Server and SharePoint, like any other Microsoft server product built under the Common Engineering Criteria specification launched in 2005-2006, has been designed to work with backup and restore solutions that leverage the Volume Shadow Copy Service (VSS Writer – and not to be confused with the old Visual SourceSafe product).

Software solutions, such as Microsoft’s Data Protection Manager – or hardware solutions (such as those offered on high-end storage devices from manufacturers such as EMC) both support VSS. This is the officially supported and most non-intrusive way to backup and restore Commerce Server configurations. In general, hardware solutions will offer superior performance with less degradation during the backup/restore operation than software-based tools.

Geographical Redundancy

For the largest enterprises, it may make sense to have multiple sites. These can be in a strict failover configuration or actually geographically load-balanced.

Geographical Failover Configurations

Consider that much of Web hosting in North America is located in Silicon Valley, as it is the center-point of several large Internet access points such as MAE West or PAX. Given this, it makes perfect sense to host data centers for large production Web sites there. But, what happens if an earthquake takes out Silicon Valley? It has happened before, such as the 1989 Loma Prieta quake with an epicenter in nearby Santa Cruz.

If business continuity is a high priority, a second site in another location such as the Washington DC/Virginia area (located near MAE East, the center-point of Internet traffic for the Eastern United States) may make perfect sense. Failover can occur at the DNS level, which is straightforward enough to configure.

The challenge becomes getting a mirror of data in Virginia from the master in Silicon Valley. From a Commerce Sever perspective, one must look at data origins and what actually needs to be replicated:

· Catalog & Marketing data is read-only, with the master living in the business environment at corporate headquarters

· Orders and Profiles contain actual customer data, with the master living in the live site’s data center

· Inventory data is typically living at corporate headquarters in the order/warehouse management system

Given this, the following fail-over strategy probably makes best sense:

· Push Catalog and Marketing data from corporate headquarters to the backup site at the same time as it is pushed to the live site, utilizing Commerce Server Staging

· For Inventory:

o Push it to the backup site from corporate headquarters using the BizTalk adapters (assuming an up-to-date master at headquarters)

o Update simultaneously at corporate headquarters and at the backup site from the live site – also utilizing the BizTalk adapters

· Replicate Order and Profile data from the live site to the backup site utilizing:

o BizTalk Adapters

o VSS Writer with scheduled backup/restore in near real-time – possibly even implementable in hardware utilizing long-distance fiber-optic links between SAN devices

Geographical Load Balancing Configurations

It may be desirable to take the geographical failover configuration one step further and go to a multi-master approach with multiple sites active in different geographies and processing different sets of customers.

Practically speaking, this configuration can be made to work as follows:

· Catalog and Marketing data is pushed from corporate headquarters to all geographical environments – most likely utilizing Commerce Server Staging

· Inventory data is updated at time of order, and synchronized with a corporate master – most likely via BizTalk

· Orders and Profiles are synchronized amongst environments utilizing either:

o BizTalk Adapters

o SQL Server Transactional Replication (with multi-master replication configured)

o Note: Both of these methods require that Orders and Profiles be globally unique (such as by utilizing a Microsoft Globally Unique Identifier (GUID) data type) so no database key conflicts can ever exist

In the end state, geographical load balancing devices would segregate traffic amongst regional data centers. If a regional data center were to fail, traffic could be rebalanced amongst other regional data centers with ongoing business continuity.

Health Monitoring

It is imperative that all key Event Log messages and Performance Monitor counters be continuously monitored to ensure quality of service. The Operations Manager management pack that ships with Commerce Server provides an established means of doing this. If a non-Microsoft systems management tool is to be utilized, such as Hewlett-Packard’s OpenView, the management pack provided with Commerce Server can be used as a baseline to configure similar monitoring rules.

Separately, it is a best practice to configure real-world transactions simulating users browsing a site and checking out – and programming these into the health monitoring tool. This way if the actual user experience starts to degrade, it can be caught in real-time and corrected. Keynote Systems (http://www.keynote.com/) (and several others) also offers a global user experience monitoring service that can measure performance from various points around the Internet; if absolute quality of user experience matters – a service such as this is a must as there is no other way to tell what an end-user is actually seeing. For example, it is not uncommon to see great results on a local Operations Manager or OpenView deployment – but see terrible results across the country from a user’s desktop due to a telecommunications bottleneck.

Data Archiving

Commerce Server generates quite a bit of data. Performance can degrade over time if this data is not periodically archived and/or purged. Some things that should be periodically examined include:

· Anonymous User Profiles – delete any that have not been used in a reasonable amount of time (such as 4-12 months)

· Anonymous Baskets – delete any that have not been used in a reasonable amount of time (such as 4-12 months)

· Order History – delete anything that is more than 1-2 years old if appropriate

Building Boxes

Configuring Commerce Server securely requires one to be an expert in the entire Microsoft technology stack that supports the underlying product, such as Windows Server, SharePoint, SQL Server, BizTalk Server, etc. Further complicating matters, each version of the technology utilized typically has considerably different steps required to successfully configure a box. And the technology matrix itself is changing on a very rapid basis – with major refreshes at least once per 12-18 month time period.

So, what is one to do? The first thing is to invest in an automated imaging solution to automate the process of provisioning boxes. There are simply too many complex steps that if left to human touch can result in undesirable errors. From Microsoft, the combination of Remote Installation Services and Windows Deployment Services coupled with products such as System Center provide a robust toolset that can be leveraged. Third party solutions such as Altiris can also be utilized.

The second critical element is to have the right information on how to actually configure the stack. Microsoft maintains up-to-date documentation on how to configure Commerce Server step-by-step based on the underlying supported platforms. This is based on the core deployments documented for the base product:

· Single Sever Deployment: http://msdn.microsoft.com/en-us/library/dd452321.aspx

· Base Deployment: http://msdn.microsoft.com/en-us/library/dd452382.aspx

· Enterprise Deployment: http://msdn.microsoft.com/en-us/library/dd451606.aspx

· Development Environment: http://msdn.microsoft.com/en-us/library/dd328262.aspx

Based upon the guidance provided earlier in the chapter, these can be mapped as follows:

Deployment	Deployment Subset	Relevant Microsoft Guidance
Standalone Server	N/A	Single Server Deployment
Dedicated Server	N/A	Single Server Deployment
Single Environment Web Farm	N/A	Base Deployment
Multi-Environment Deployment	Web Tier	Enterprise Deployment
Data Tier	Enterprise Deployment
Corporate Tier	Single Server Deployment Enterprise Deployment Development Environment

Testing

The key to a successful deployment is testing – especially from a performance, scale, and stress perspective. From a testing perspective, the following goals must be met to assure system stability:

· Ability to run at the peak load / worst case scenario the site is apt to experience in the real world from a traffic/transactional volume perspective – with all background processes running

· Ability to run at peak load for a continuous time period without affecting availability (e.g. – need for server reboots due to running out of memory); this time period should be defined by the maintenance window utilized for the site – which is typically nightly reboots to once weekly reboots

Conducting this type of testing effectively is potentially an extremely complex and expensive process. What is needed includes:

1. A testing methodology that allows one to extrapolate a full production environment’s volume – without requiring an exact (and very costly) mirror of the production environment. The best methodology for achieving this is the Transactional Cost Analysis (TCA) methodology invented by Microsoft in the Site Server days. For information that is kept up-to-date continuously:

a. TCA Article: http://technet.microsoft.com/en-us/commerceserver/bb608757.aspx

b. Commerce Server 2009 Performance Whitepaper: http://www.microsoft.com/downloads/details.aspx?FamilyID=61fac357-9df5-4324-b17d-bc6af9d980a4&displaylang=en

2. A reasonable mirrored subset of the hardware to be utilized in production. Key elements to ensure that configurations match include:

a. Web Servers (2-8) with identical hardware configuration to production

b. Similar network hardware (firewalls, load balancers, switches, etc.), though redundant configurations do not need to be utilized

c. SQL Server hardware with identical configuration to production (as these configurations are fixed, the test bed should mirror production)

d. BizTalk hardware with identical configuration to production (as these configurations are fixed, the test bed should mirror production)

e. Operations Manager hardware (can be non-redundant)

f. Staging server hardware (can be non-redundant)

g. SAN storage with similar IOPS rating to production (although smaller units can be leveraged)

3. A load testing tool and enough testing hardware to simulate a subset of the expected load utilizing TCA methodology. Several possible tools include Microsoft’s Visual Studio Team System, Borland’s SilkPerformer, or Hewlett-Packard’s Load Runner.

4. Enough generated or actual data to simulate real-world data volumes across all Commerce Server databases.

5. Ensuring that background processes are running during performance tests – such as staging, BizTalk data pushes and pulls, and so forth.

Most performance tests fail due to:

· Inability to mirror hardware configurations – for example one large retail site that passed its internal testing flawlessly failed in production due to different network interface cards, switches, and load balancers being utilized – and the wrong configuration settings being set on the production hardware

· Insufficient data volumes – another large retail site failed within the first 10 minutes after launch, because the performance tests utilized less than 10K profile records whereas the actual live site had 4-5 million and it turned out another SQL index was desperately needed

· Not conducting performance testing with background processes running – a third large retail site failed due to the fact that its order pull operation to send completed orders to the warehouse management system imposed such a significant performance overhead that it brought the site down under peak loads.

Following the guidelines suggested herein will generally ensure the most accurate real-world performance possible while minimizing the testing expenditure.

There are many potential flavors and permutations of configuring Commerce Server to run in multiple environments. For the purposes of this discussion, it is assumed that the following actual environments will be utilized for the sake of bounding the problem:

1. Live Web Site – This is where customers access the site to purchase merchandize over the Internet.

2. Staging Site – This is where the next version of content for the live site is kept and validated for quality purposes.

3. Content Production – This is where business users make changes and preview them. There may be multiple versions of this environment based upon brands, seasonal merchandizing policies, etc. Creative look-and-feel changes will typically occur here.

4. Code Development – This is where developers make functional changes to the Commerce Server application.

5. Code Testing – This is where testers validate functional changes made by developers.

In terms of aligning to prescribed product deployment topologies:

· The Live and Staging and Content Production sites correspond to the prescribed Enterprise Deployment in the core product documentation

· The Code Development and Testing sites correspond to the Development Environment deployment in the core product documentation

From a physical deployment perspective, this can be enumerated as:

· Web Tier – machines that are directly connected to the Internet (via a firewall)

· Data Tier – machines one layer removed from the Internet that provide data processing capabilities

· Corporate Tier – Machines residing at corporate headquarters for internal business management functions.

Each of these shall now be examined in requisite detail.

The Web Tier

Overview

The Web Tier handles front-end user experience and transaction processing. It is scaled horizontally based on transaction volume. Depending upon the number of transactions, this tier can get extremely large – spanning potentially into dozens of servers or more. Depending upon whether or not a content delivery network such as Akamai is utilized, this may be scaled out accordingly beyond the bounds of a single data center. This environment represents the Internet-facing portion of the Live Site.

Virtualization Considerations

Given the rigorous performance and scale requirements, it does not typically make sense to consider virtualization for the Web Tier.

Software Considerations

The following software considerations should be taken into account:

· Operating Systems – The Web servers can leverage the base editions of Windows Server, such as Standard Edition or Web Edition. Domain controllers must utilize at least Standard Edition.

· Commerce Server – Enterprise Edition must be utilized.

· SharePoint – MOSS should be utilized given Web farm support. 

· Operations Manager – Any version supported by the base platforms can be chosen.

Directory Configuration

It is assumed that Active Directory will be utilized, with a trust relationship to the Data Tier.

Server Configurations

This environment will leverage the following servers:

· 2 Active Directory Domain Controllers

· 2 or more Web Servers based upon transaction volume

· 1-2 Operations Manager servers (depending upon the level of redundancy desired)

Hardware Considerations

In this configuration, there are quite a few hardware considerations that one must examine:

· Firewall

o A firewall should be installed between the front-end Web servers and the Internet.

o A second firewall should be installed between the Web Tier and the Data Tier.

o Firewalls should be redundant to prevent single points of failure.

· Load Balancer

o Redundant hardware load balancers should be utilized. The scale of this type of environment precludes Windows Server’s Network Load Balancing feature from being a practical solution.

· Network

o For the Web Servers, it makes the most sense to have these be dual-homed, with one NIC pointing to the Internet and the other pointing to the Data Tier.

o Care must be taken to ensure that sufficient bandwidth exists between the Web servers and the Data Tier.

· Server Hardware

o Dual socket Web servers typically provide the best mix of price versus performance given the overall linear scalability of Microsoft’s Web platform. (For example, four dual socket Web servers will perform better than a single eight socket Web server in almost all instances.)

Database Considerations

As there are no SQL Servers in the Web tier, there are no data-specific considerations.

The Data Tier

Overview

The Data Tier provides several functions in the overall deployment and serves as the central nervous system of the entire e-commerce ecosystem within the organization. Some of its purposes include:

· Providing data storage for the Web Tier

· Providing a staging environment for data transfer from the Corporate Tier and previewing it before putting it into production

· Data interchange with line-of-business systems

· Web analytics

It corresponds to the non-Internet-facing portion of the Live Site plus the Staging Site.

Virtualization Considerations

Given the rigorous performance and scale requirements, it does not make sense to consider virtualization for the Data Tier.

Software Considerations

The following software considerations should be taken into account:

· Operating Systems – Active Directory domain controllers will need to utilize at least Standard Edition of Windows Server. Commerce Server Web servers can use either the Standard or Web Editions of Windows Server. Database and BizTalk Servers will need to leverage clustering-enabled versions of Windows Server, such as Enterprise or Data Center Edition.

· Commerce Server – Enterprise Edition must be utilized.

· SharePoint – MOSS must be utilized.

· Operations Manager – Any version supported by the base platforms can be chosen.

· SQL Server – Clustering-enabled versions of SQL Server must be utilized.

· BizTalk Server – Clustering-enabled versions of SQL Server must be utilized.

Directory Configuration

It is assumed that Active Directory will be utilized, with multiple trust relationships:

· Trust with the Web Tier

· Trust with the Corporate Tier

These should be one way trusts for maximum security.

Server Configurations

This environment will leverage the following servers:

· 2 Active Directory Domain Controllers

· 1-2 Operations Manager servers (depending upon the level of redundancy desired)

· Two 2-node clusters running SQL Server for the live site’s databases

· At least 2 Web servers for running the Web Services (for emergency data changes on the live site itself and to support the BizTalk adapters in Commerce Server 2007)

· At least 2 Web servers for staging and running the Web Services (for data changes inside of the staging environment)

· A 2-node cluster running SQL Server for the staging site’s databases

· A 2-node SQL cluster and 2-node BizTalk cluster for data interchange with the live site. This may need to be scaled further based upon data volumes being processed through BizTalk.

· An environment for running the Commerce Server Data Warehouse (if desired), which would entail:

o 1 server for log collection and importation

o 1 server for SQL Analysis Services

o 1 server for SQL Reporting Services

Hardware Considerations

In this configuration, there are quite a few hardware considerations that one must examine:

· Firewall

o A firewall should be installed between the Web Tier and the Data Tier

o A second firewall should be installed between the Data Tier and the Corporate Tier

o Firewalls should be made redundant to eliminate single points of failure

· Load Balancers

o In this environment, hardware load balancers for the Web Servers are not strictly necessary and the Network Load Balancing feature of Windows Server could suffice. However, redundant hardware load balancers will always provide better and more reliable performance.

· Network

o Care must be taken to ensure that sufficient bandwidth exists between the Web Tier and the database servers. Likewise, other infrastructure servers speaking to the database server must also have sufficient bandwidth. This may require multi-homing and network segmentation.

· Clustering-aware Hardware

o Both the SQL Server and BizTalk Server configurations must support Windows Server’s clustering capabilities.

· Server Hardware

o Dual socket Web servers typically provide the best mix of price versus performance given the overall linear scalability of Microsoft’s Web platform. (For example, four dual socket Web servers will perform better than a single eight socket Web server in almost all instances.)

o Database and BizTalk servers should be based upon projected performance/scale – in some cases this may need to be sized to be very large scale (e.g. – 8-64+ socket servers).

o Storage Area Networks (SANs) will provide the best performance for the SQL database servers

Database Considerations

To provide maximal performance, two Active/Active clusters should be utilized for the database servers supporting the main site:

Cluster Node	Cluster 1	Cluster 2
Node 1	· MSCS_Admin · Profiles	· Catalog (with Inventory included)
Node 2	· Transactions and TransactionConfig	· Marketing

This configuration will provide the best use of hardware and logical superstation of data storage based upon query behavior and joins.

For the staging environment’s 2-node SQL cluster, the following configuration will provide the best performance:

Server 1	Server 2
· MSCS_Admin · Profiles · Transactions and TransactionConfig	· Catalog (with Inventory included) · Marketing

Given that this is a controlled, dedicated environment, it is assumed that Active Directory and Windows Authentication for SQL Server are in use.

The Corporate Tier

Overview

The Corporate Tier is where all business functions occur, including:

· Code Development

· Code Testing

· Content Production , involving creative changes (look-and-feel, page styles, etc.) as well as business data changes (prices, promotions, etc.).

Tying back to the prescribed Commerce Server deployment topologies, it mixes part of the Enterprise Deployment with the Development Environments as specified in the Commerce Server product documentation.

Virtualization Considerations

Given that the corporate tier represents internal business functions that are not subject to the rigors of performance and scale of a live site – unless an extremely large number of business users are involved – it may make sense to selectively run parts of the Corporate Tier under virtual servers. It is assumed, however, that the minimum break-out of servers described herein is still maintained – regardless of whether they are implemented on physical or virtual hardware.

Software Considerations

The following software considerations should be taken into account:

· Operating Systems – Active Directory domain controllers will need to utilize at least Standard Edition of Windows Server. Commerce Server Web servers can use either the Standard or Web Editions of Windows Server. Database and BizTalk Servers will need to leverage clustering-enabled versions of Windows Server, such as Enterprise or Data Center Edition – where appropriate.

· Commerce Server – Enterprise Edition must be utilized for all aspects of content management and integration testing.

· SharePoint – MOSS must be utilized such that Content Deployment can be used for moving content to production. 

· Operations Manager – Any version supported by the base platforms can be chosen.

· SQL Server – Clustering-enabled versions of SQL Server should be utilized.

· BizTalk – Enterprise Edition, to support clustering.

MSDN licenses should be considered for Code Development and Testing to save on software license costs. However, anything that is utilized for ANYTHING other than code development or testing (such as content management, business data editing, look-and-feel changes, etc.) need full commercial licenses to be legal.

Directory Configuration

It is assumed that Active Directory will be utilized, with a trust relationship to the Data Tier.

Server Configurations

This environment will leverage the following servers:

· At least 2 Active Directory domain controllers, though this function is usually accounted for by the internal corporate Active Directory structure

· For the Content Development environment:

o At least 2 Web Servers, running both the site and the Web Services for supporting the business user management tools – this will need to be scaled based upon the number of

o At least a 2-node SQL cluster should be utilized to provide redundancy

· For the Code Development environment:

o At least 1 Web Server and SQL Server that can support integrating the results of the internal development team together into a single environment

o Single-box deployment configurations for developer desktops

o Other hardware as appropriate to support the development environment tools being utilized, such as Microsoft Visual Studio Team System (VSTS)

· For the Code Testing environment:

o A subset of the Web and Data Tier environments that can reasonably approximate the performance characteristics (in an extrapolated manner when utilizing a methodology for Web performance testing such as Transactional Cost Analysis) of the actual environment

o At minimum this would probably include:

§ 2-4++ Web Servers to simulate the live site

§ At least 2 Web servers to simulate the Web services and staging

§ 2 SQL clusters

§ A BizTalk cluster

§ A load testing tool and enough supporting hardware to simulate real-world performance scenarios

Hardware Considerations

For the Corporate Tier, the following hardware considerations should be made:

· Firewall

o A firewall should be installed between the Data Tier and the Corporate Tier

o Firewalls should be made redundant to eliminate single points of failure

o Code testing environments may want to utilize firewalls for testing purposes to ensure that there are no performance bottlenecks caused by the firewall hardware

· Load Balancers

o In this environment, hardware load balancers for the Web Servers are not strictly necessary and the Network Load Balancing feature of Windows Server could suffice. However, redundant hardware load balancers will always provide better and more reliable performance.

o Code testing environments should utilize similar hardware load balancers as the production environment to provide like-for-like performance results

· Network

o The code testing environment should probably be segregated into its own network, as performance testing is extremely bandwidth-intensive and could cause severe disruption on a network shared with other users

· Clustering-aware Hardware

o The Content Development environment should utilize clustering-aware hardware for redundancy’s sake, to prevent downtime to business users

o The Code Testing environment should approximate the live Web Tier and Data Tier configurations to provide for comparable results when testing

· Server Hardware

o Dual socket servers should suffice for Content Development and Code Development environments

o The Code Testing environment should approximate the actual live production environment

Database Considerations

For the Content Development environment, as a 2-node SQL cluster is recommended the standard configuration should be utilized:

Server 1	Server 2
· MSCS_Admin · Profiles · Transactions and TransactionConfig	· Catalog (with Inventory included) · Marketing

For the Code Development environment, as single servers could be utilized, the only guiding principle should be to separate Commerce Server resources into their own databases.

For the Code Testing environment, it should mirror production to provide accurate performance analysis results.

Overview

Typical of small to medium businesses with their own dedicated e-commerce presence, the Single Environment Web Farm provides a separation of functions for performance and redundancy’s sake to the maximum extent possible within a single physical environment. For most small to medium businesses with a few hundred to a few thousand orders per day, such a deployment makes perfect sense and provides a good tradeoff of cost vs. benefit (from performance, redundancy, etc. perspective). For discussion purposes, the assumption will be that the Standard Edition of Commerce Server 2009 will be utilized.

This scenario corresponds well to the Base Deployment of Commerce Server as identified in the product documentation. There are exceptions, however, based upon limitations of the Standard Edition of Commerce Server, specifically:

· There is no Data Warehouse, as that feature is not present in the Standard Edition of Commerce Server

· Web Services for hosting the business management tools will reside on the actual production Web services in the Web tier, given that no more than 2 Web servers can be in a Web farm for Commerce Server Standard Edition

Virtualization Considerations

As the point of this environment is to separate functions based upon performance and redundancy, it largely does not make sense to consider virtualization.

Software Considerations

The following software considerations should be taken into account:

· Operating Systems – The Web servers can leverage the base editions of Windows Server, such as Standard Edition or Web Edition. The Database Servers must use Enterprise Edition or another version that supports clustering in order to achieve redundancy. Domain Controllers must leverage at least Standard Edition.

· Commerce Server – Everything identified here can be deployed on the Standard Edition of Commerce Server. The only reasons that Enterprise Edition would need to be contemplated include:

o Need for beyond two processor sockets

o Need for greater than 10 sites or 1 application per Commerce Server instance

o The number of Web servers in the farm needs to scale beyond two

· SQL Server – Any version of SQL Server can be utilized that supports clustering.

· BizTalk – As clustering has been utilized, the Enterprise Edition of BizTalk must be utilized.

· Operations Manager – Any version supported by the base platforms can be chosen.

Hardware Considerations

In this configuration, there are quite a few hardware considerations that one must examine:

· Firewall

o A firewall should be utilized to separate the Web tier from the Internet, to prevent denial of service attacks.

o A second firewall should be utilized to provide redundancy

o It may make sense to have a firewall or VPN to corporate headquarters depending upon the actual geographical proximity of the servers.

o Firewalls should potentially be redundant to eliminate single points of failure.

· Load Balancer

o A hardware load balancer should be utilized, though it is possible to utilize the Windows Server Network Load Balancing feature for such a small environment.

o If a hardware load balancer is utilized, it should potentially be made redundant to eliminate a single point of failure.

· Network

o For the Web Servers, it makes the most sense to have these be dual-homed, with one NIC pointing to the Internet and the other pointing to the back-end.

o To minimize round trips, it makes the most sense to have the back-end of the Web servers, the SQL servers, and the BizTalk servers all running on the same network.

· Clustering-aware Hardware

o Both the SQL Server and BizTalk Server configurations must support Windows Server’s clustering capabilities.

· Server Hardware

o Moderate low-end to mid-range servers can be utilized across-the-board because the limits of transactions that can be supported by Standard Edition (typically 10K per day/less) do not warrant any specific server or other hardware considerations.

o The hardware required for this configuration is relatively fixed given the constraints of the Standard Edition of Commerce Server 2007, specifically:

§ Web Tier

· 2 Active Directory Domain Controllers

· 2 Web Servers (running both the site and Web Services for business management)

· 1-2 Operations Manager servers (depending upon the level of redundancy desired)

§ Data Tier

· 2 Clustered SQL Servers

· 2 Active Directory Domain Controllers

· 1-2 Operations Manager servers (depending upon the level of redundancy desired)

Directory Configuration

It is assumed that Active Directory with two trusted domains will be leveraged (one for the Web tier and one for the Data tier), with a set of common service accounts utilized across the Web and Data tier environments respectively. Depending on how things are connected to a back-office, this may be trusted with the corporate environment. It would not be advisable to leverage the same domain as the corporate environment, however.

Server Configurations

The hardware required for this configuration is relatively fixed given the constraints of the Standard Edition of Commerce Server 2007, specifically:

· Web Tier

o 2 Active Directory Domain Controllers

o 2 Web Servers (running both the site and Web Services for business management)

o 1-2 Operations Manager servers (depending upon the level of redundancy desired)

· Data Tier

o 2 Clustered SQL Servers

o 2 Active Directory Domain Controllers

o 1-2 Operations Manager servers (depending upon the level of redundancy desired)

Database Configurations

With two database servers in a cluster being utilized, an Active/Active cluster can be utilized to maximize hardware. Given this, it makes the most sense to have separate databases per Commerce Server resources. Given a mix of two servers, the most logical separation would be:

Server 1	Server 2
· MSCS_Admin · Profiles · Transactions and TransactionConfig	· Catalog (with Inventory included) · Marketing

Given that this is a controlled, dedicated environment, it is assumed that Active Directory and Windows Authentication for SQL Server are in use.

The Standalone Server

The Standalone Server has a very simple topology – that of a single box. It is intended that all software be installed on this box. Typically secure configuration is a non-concern in this type of scenario, as it is typically intended for some sort of demonstration or development (as opposed to production task).

Some resultant considerations with respect to software include:

· Windows Server must be utilized, as both Commerce Server and SharePoint have dependencies that preclude them from being run on Windows client operating systems.

· In a standalone configuration, the cheapest editions of Windows, SQL, and BizTalk + the free WSS probably make the most sense, as the additional capabilities of higher end editions will not be effectively leveraged in a single server deployment scenario.

From a performance perspective, this solution should really only be utilized for development, evaluation, and demonstration purposes.

This corresponds well to the Single Server deployment of Commerce Server as described in the product’s documentation.

The Dedicated Server

Overview

This scenario represents the true operational baseline for deploying Commerce Server 2007 – and would represent something typical of what would be experienced when leasing inexpensive dedicated servers for a small/medium business’s hosted Commerce Server site.

The main difference between this and the Standalone Server configuration is that SQL Server is optionally partitioned out onto a separate box, typical of the shared SQL Server environments in use within many Internet hosting providers.

This corresponds well to the Single Server deployment of Commerce Server as described in the product’s documentation.

Virtualization Considerations

Additionally, virtualization has the potential to make a significant impact on this configuration as hardware could potentially be best utilized to have many separate virtual dedicated servers running Commerce Server running on the same physical piece of hardware.

Database Deployment Configurations

If SQL Server is configured on the same box as Commerce Server, either SQL Authentication or Windows Authentication can be leveraged. Windows Authentication is the preferred and default mode. If SQL Server is run on a separate box, it probably makes the most sense to use SQL Authentication as many hosting environments do not utilize Active Directory, which would preclude the use of Windows Authentication. SQL Authentication is also considerably easier to configure and support in an environment where multiple sites are being stored on the same SQL Server.

From a software deployment perspective, it probably makes the most sense to leave all Commerce Server resources in the same database – as there are no inherent performance or logical separation advantages required to have separate databases per resource – and indeed the support cost of such for an Internet hosting provider might be somewhat prohibitive for both the end customer and hosting provider.

Hardware Considerations

The following should be contemplated from a hardware perspective:

· Network – Network is a potentially bigger bottleneck than one might think in this scenario. If there are multiple single servers pointing to a single SQL Server, sufficient bandwidth must exist between the Web Servers and SQL to prevent saturation. Likewise, if multiple servers are virtualized on the same piece of hardware, network bandwidth must be sufficient to handle the traffic of all servers in aggregate – potentially requiring more network interface cards to be installed. Separately, from a security perspective it might make sense to dual home servers if a separate SQL back-end is utilized to provide for maximum security.

· Firewall – It is recommended that a hardware firewall be put between the Commerce Server system and the Internet. It is also recommended that another hardware firewall be put between Commerce Server and SQL Server – if appropriate.

There are currently two versions of Microsoft Commerce Server available – Standard Edition and Enterprise Edition. Some of the key differences between the two can be summarized as follows:

Function	Standard Edition	Enterprise Edition	Notes
Processor Sockets	Up to 2	Unlimited	Standard Edition cannot be installed – and will not function on machines with more than 2 processor sockets visible and usable to Windows.
Web Farm Size	Up to 2 Web Servers	Unlimited	A Commerce Server site in Standard Edition cannot span more than 2 Web servers. Although technically bits can be used and code replicated on more machines, many management/administrative functions will not behave properly if this limitation is circumvented.
Sites	Up to 10	Unlimited	Standard Edition will not allow more than 10 Sites (in Commerce Server definitions – see last chapter for more information) to be provisioned.
Applications	Up to 5	Unlimited	Standard Edition can practically only support an individual Web site, the Orders Web Service, Catalog Web Service, Profile Web Service, and Marketing Web Service configured within a Commerce Server site given the restrictions on Commerce Server Applications being provisioned is restricted to 5 (see last chapter for more information).
Data Warehouse	Not Included	Included	Standard Edition does not support the Data Warehouse. That being said, it can be installed on a separate instance of Enterprise Edition and data collected and analyzed from a system running Standard Edition.
Staging	Not Included	Included	Standard Edition is effectively restricted to being deployed in a single environment – as data cannot be replicated from one environment to another.

Given these differences, it is important to pick the right version of Commerce Server for the task at hand. The principal considerations of using Standard Edition can be summarized as follows (with the invalidation of any assumption requiring an upgrade to Enterprise Edition):

· The use of a single Web farm deployment is not a problem – and the potentially negative performance and business impact of making changes to a live production site is a non-issue.

· The traffic volume will not exceed the capacity of 2 Web servers with 2 processor sockets each.

· Data Warehouse capabilities will not be needed.

· There will not be more than 1-10 sites deployed on the same physical hardware, depending on how Commerce Server is configured (please refer to the last chapter for in-depth description of the tradeoffs here from an application architecture perspective).

Mapping Scenarios to Commerce Server Editions

Going back to the aforementioned list, the fits of the various usage scenarios outlined can be summarized as follows (with the assumption that the previous list of caveats has also been evaluated):

Scenario	Standard Edition Fit	Enterprise Edition Fit
Standalone User	Yes	Yes – but it may be overkill from a cost perspective unless an extremely high number of sites/application or processor sockets is required.
Dedicated Server	Yes	Yes – but it may be overkill from a cost perspective unless an extremely high number of sites/application or processor sockets is required.
Single Environment Web Farm	Yes – though the farm cannot scale beyond 2 servers.	Yes – if more than 2 servers is needed.
Multi-Environment Web Farm	No – this is not possible given software limitations.	Yes
Shared Hosting of Commerce Server	N/A	N/A

Impact of Virtualization

Virtualization can play a role now in virtually any Commerce Server deployment scenario. It is fully supported by the product – on either Microsoft Virtual Server or Windows Server 2008 Hyper-V. The only consideration is that often times a virtual server will not perform as well as a real physical server – so long as this impact is inconsequential, virtualize away!

Base Platform

The following summarizes the best platform upon which to run Commerce Server:

· Base Operating System – Windows Server 2008 x64 will provide the most forward mobility for upgrades beyond Commerce Server 2007 or Commerce Server 2009. x86/32-bit support is being dropped beyond CS2009, as previously blogged.

· WSS versus MOSS – The main reasons to use MOSS would be enhanced Web Farm, Search, content management (approvals, workflow), and Site Variations (useful for implementing globalized sites)

· SQL Server – SQL Server 2008 x64 should be utilized, as previous versions will not be supported beyond Commerce Server 2009 as previously blogged.

· BizTalk Server – 2009 should be utilized.

· Visual Studio – VS2008 should be utilized, as VS2005 support will be dropped beyond CS2009, as previously blogged.

In the Commerce Server product documentation, several baseline deployment configurations are covered in extreme detail. In practicality, this is only of partial use – as these configurations are extremely generic and do not map back to particular real world problems and scenarios. Looking at Commerce Server at a high-level – several real-world deployment scenarios immediately come to mind – in order of least complex to most complex…

The Standalone User

For various reasons, people may want to run Commerce Server entirely standalone. This would typically be for development or demonstration purposes and typically leverage a single piece of hardware. Often times, this type of environment must co-exist with other desktop applications – as it is indeed often running on a desktop.

The Dedicated Server

Within the space of Internet hosting, it is often times very economical to lease a dedicated server – sometimes for as little as under $50 per month. This can represent a valid and often overlooked utilization of Commerce Server and allow the technology to be leveraged economically for small-scale e-commerce operations.

The Single Environment Web Farm

Medium sized organizations often times deploy Commerce Server in a single Web farm with some distribution of function – for both performance and redundancy purposes. (Yet the entire deployment can still run on a small enough number of machines as to match up with fingers on a hand.)

The Multi-Environment Web Farm

Larger organizations often times deploy Commerce Server across multiple Web farms, each one serving a different purpose with only one actually processing transactions from live customers. The other Web farms are often utilized for the purposes of dedicating hardware to other functions such as code development, code testing, data entry of business data, and validation of business data.

Shared Hosting of Commerce Server

Although it is desired, this is not a practical configuration. For shared hosting to be effective, customers cannot impact each other from a software perspective even if they are utilizing the same hardware. From a .NET application perspective, this requires that Medium/Partial Trust be utilized. Given the amount of unmanaged code in Commerce Server and the fact that Web service calls may need to be made for payment processing – Medium/Partial trust cannot be utilized.

For hosting providers looking to offer Commerce Server hosting, it would be better to offer low-end hardware in a dedicated capacity or to provide virtual environments leveraging Virtual Server, Windows Server 2008 Hyper-V, or a 3^rd party operating system virtualization solution such as VMWare. Commerce Server has not been tested with application-level virtualization solutions such as SWSoft’s Virtuozzo. Though it may in fact work, utilizing something like Virtuozzo may lead to unpredictable results and lack of support from Microsoft.

Deploying any mission critical system is an extremely non-trivial task. Dollars and cents are at stake. Almost any deployment of Microsoft Commerce Server 2007 or 2009 (hereafter CS2009) can fit this bill. Inherently, e-commerce is about collecting money. If a system is not available, money cannot be collected. That is the direct cost of downtime. Indeed, during peak holiday shopping season hundreds of thousands, if not millions, of dollars can be lost for every hour of partial or complete downtime during the middle of peak shopping hours. Then, there is the indirect cost – that of professional reputation. If someone has a bad or unavailable experience with an e-commerce site – business is lost to the competition. Sometimes it is a permanent loss. This loss can spread like wildfire – amongst friends and colleagues, online communities, and even into the public media. During the United States Thanksgiving holidays of 2005 and 2006 – Black Friday resulted in several key e-commerce sites suffering outages that resulted in top headlines in national media. The reputation cost is difficult to directly quantify – but it is often times far greater than the direct cost of downtime itself. Hence, downtime or poor performance of any kind is something best avoided.

This series of blog posts shall attempt to outline the thoughts and considerations that must go into deploying CS2009 – such that downtime is avoided and system performance is always within acceptable levels. Topics covered include selecting the right version of Commerce Server and other underlying Microsoft technologies, the configuration of deployment environments for a variety of common scenarios, Commerce Server-specific tradeoffs and consequences, advanced tips and tricks, and impacts upon operational processes from looking at deployments from an end-to-end perspective. What is not covered is the actual step-by-step building out of individual hardware software configurations – as the potential permutations are many and the documentation of individual products themselves are likely a more appropriate source of reference.

Hope this helps – and that you enjoy reading them as they come…