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.