In this interview I answered the question: “How would you work with a client to figure out an environment that best suits their needs?”
While informative, this interview only scratches the surface of all the options presented to them when trying to determine the ideal environment so let's go into more detail.
The Most Basic Sitecore Environment (minimum recommended)
The simplest environment that meets Sitecore recommendations has a web server and a separate SQL server.
The web server handles both content authoring and content delivery. The SQL server includes three Sitecore databases: Master, Web and Core. Content is managed in the Master database and published to the Web database. The Core database provides settings and security information.
This environment is acceptable for some sites, however next we will explain ways to improve and expand the environment.
Separating Authoring from Delivery (beginning to scale the environment)
This is the first step to having a more substantial architecture. It has two web servers. One server handles all authoring. The other exclusively delivers content.
Why do this?
- Security advantage: Even without a firewall, the authoring server will be more obfuscated because it is at a different URL.
- Increased load ability: This environment provides a dedicated delivery server, which should handle load better than a server that also includes authoring.
- Redundancy: If either server fails, the other might still be standing. Also, authoring can act as a test ground for new content and code.
- Beginning to scale: This is the first step to a scaled environment.
The SQL server continues to have the three Sitecore databases. Authoring accesses the Master and the Core databases. Delivery only accesses Web and Core.
Considerations for a multi-web server environment:
- Delivery should not include authoring: The delivery server should be configured to not allow access to the authoring admin tools.
- Delivery database access: The delivery server should be configured to not have access to the Master database.
- Sitecore cache management: In a single server environment, the Sitecore caches are automatically cleared with a Sitecore publish. With more servers, something needs to trigger that process. Prior to Sitecore v6.3, the Staging Module served this purpose. With Sitecore v6.3 and above, Sitecore Scaling should be enabled.
- Sitecore managed media in the file system: Large media (mostly videos) should not be stored in the database. Sitecore offers the option to store these in the file system. But, when there is more than one server, the files need to be synced. The easiest way to solve this is to restrict the use of file system media. But, if you need to use file system media…Prior to Sitecore v6.3, the Staging Module could be configured to sync these files using SOAP or FTP. For Sitecore 6.3 and beyond, it is recommended to configure MS Web Deployment to move the media files from the author environment to the delivery environment, and then to use DFS to sync the files between servers within the delivery environment.
- Machine keys: If the web site uses encryption a consistent machine key must be configured for the servers.
- Delivery optimizations: As an option, you may want to streamline the delivery server’s configuration to remove less needed steps like gathering Sitecore measurements and by lowering the logging level.
Planning for Load (keeping up with your traffic)
As you get more traffic, you’ll need more web servers to keep up with it. A single web server can only process so many requests. If too many requests come in, the response time will slow dramatically as resources are maximized. Eventually, the site will be un-usable, and users will go elsewhere.
Prior to site launch, the amount of traffic and the complexity of the application should be reviewed to determine how many web servers are needed to deliver the site with confidence. How to analyze load needs will be part of a future post.
After your review, you should have an idea of how many web servers will be needed to meet the expected traffic of the site. More traffic will require additional delivery web servers.
Why do this?
If there are not enough server resources, the site will fail to deliver content, and users will leave the site.
At a basic level, scaling for load starts with separating authoring from delivery (see above). Then, you simply add more delivery servers to meet the expected load.
Beyond this, you’ll need a load balancer to route traffic to the web servers. The load balancer algorithm is not super important, as long as traffic gets routed reasonably well.
Considerations for load balancing:
- Session management: Sticky sessions with the load balancer will help with this. A load balanced Authoring environment requires sticky sessions. For delivery, there are options at the application level.
- SSL: Load balancers are often used as the SSL end point. This may affect how the web application understands SSL.
- Server access: For testing purposes, it is useful to configure a way to access each web server specifically.
- Server testing: Many load balancers use tests that ping the web servers to ensure they are alive and working. This may need to be added to the web application.
- Staged deployments: With load balanced web servers, it would be ideal to deploy updates to the environment in stages. Each stage would update a different group of servers, removing them from the load balancer while they are updated. This will allow the application to remain live during the update, provided the remaining servers are sufficient the handle the load. Also, when configuring this with more than two stages, keep in mind that some servers in the live environment will be updated while others are still pending. Without sticky sessions, this can create errors.
In addition to adding delivery web servers, you may want to consider scaling for load on the database and on the authoring server.
- SQL scaling: Consult with a SQL DBA on how best to analyze and scale for the database load. A clustered SQL environment might be one solution.
- Authoring scaling: Starting in Sitecore v6.3, authoring servers can be load balanced. This would not be required for most sites. But, for sites with many active authors, this should be considered. Note: scaling for authoring requires sticky sessions and a publishing instance must be configured.
Planning for Isolation (providing security)
You’ll want to protect (isolate) your admin tools and data as much as you can. The need for security may also be greater if your authoring environment is integrated with internal resources, for example AD integration for authoring authentication.
The simplest model for isolation will have separated authoring and delivery web servers (see above). To improve this, you would also protect your authoring environment with a firewall. Additionally, you can isolate the authoring data from the delivery data.
Why do this?
- To protect your content: Isolating the authoring admin will make the CMS more secure. The same is true for isolating the authoring databases.
- To protect integrated resources: Not all environments will have this need.
- Corporate requirements: Your organization may require this to fulfill security standards.
The delivery environment SQL server only needs a Core and a Web database. Authoring requires the Master and Core databases, and access to the Delivery Web database.
Considerations for an isolated environment:
- Delivery Web database: The Delivery environment should always have a local Web database for optimal performance.
- Authoring access to Delivery data: The authoring web server needs to be able to publish content to the Delivery Web database.
- Authoring with Sitecore managed media in the file system: If large media is managed in the file system, the authoring environment needs to be able to deploy that media to the Delivery environment.
- Core database security data: If the web site uses extranet security that is managed in the Authoring environment, the Core database in the Authoring environment needs to be synced with the Core database in the Delivery environment. Typically, this is done through SQL replication. Security caches may also need to be synchronized.
- Sitecore indexing: If the web site uses the Sitecore Links data or Lucene indexes, some configuration steps may be required to make those available to both Authoring and Delivery.
- Authoring Web database: As an option, it may be desired to have a local copy of the Web database for the Authoring environment. This will perform faster than the external Web database. Also, it could be used to test content during authoring prior to publishing it to the Delivery Web database.
Servers fail. The common way to guard against that is to have backup servers. These could be cold failovers with a plan to quickly bring them to life, if needed. Or, these could be live, load balanced servers that provide real-time redundancy.
Redundancy creates a window of time to fix problems before the world sees them. The more redundant the environment, the larger that window is.
Planning for Redundancy (maximize up-time)
It is important to consider load when planning redundancy. If five web servers are required to meet the site load, more than five would be required to support redundancy. Also, as the number of servers grows, the probability of server failure grows proportionally.
Why do this?
Without redundancy, when servers fail, your site fails.
There are no extra details for redundancy. It’s all about having more than enough.
In addition to adding delivery web servers, you should also consider redundancy for the database and the authoring server.
- SQL redundancy: Consult with your SQL DBA on how best to make SQL redundant. This may be a clustered SQL environment, or a Mirrored failover.
- Authoring redundancy: If it is business critical to keep the authoring environment alive, you will want to have plans for how to restore authoring if it fails. In Sitecore v6.3 and beyond, authoring can be load balanced for redundancy. Apart from this, a cold failover server may be a good option.
Testing considerations (avoiding surprises)
All site updates should be tested. Simple content updates should be reviewed prior to and after publishing. Larger content updates and code releases should be tested and reviewed as much as possible. More testing provides greater confidence that the site will work.
Considerations for testing in a scaled environment:
- Test environments: Every site should have a test environment that mirrors the production environment as closely as possible, including authoring, delivery and load balancing. However, the test environment does not need to scale for load, beyond what is required for testing the scaling. Also, it typically does not need to be redundant, beyond what is required for testing redundancy.
- Larger content releases: A test environment is a good place to create larger content updates. These may, or may not, involve code level changes. But, developing them in a test environment provides extra assurance that they will not be released early, or cause conflict with more immediate updates.
- Testing code releases: A test environment provides the ability to test code deployments in an environment other than production. This assumes that code releases can be pushed from a development environment to the test environment.
- Automated testing: Ideally, automated testing tools should be utilized to ensure that updates do not break functionality. In addition to unit and regression tests, UI tests can be created to ensure that deployments are successful.
- Using Authoring as a test environment: The separated Authoring environment may also be used as a testing location for releases. Whether this is a viable option depends on how business critical it is to keep Authoring live. But, typically, Authoring is less critical than Delivery.
- Load testing: Load testing is the best way to validate assumptions about the site’s ability to handle traffic. Ideally, load testing will occur early enough to allow for adjustments in the hosted environment and the application.
The Ultimate Environment
The ideal Sitecore environment will:
- Handle the expected maximum load within desired response thresholds
- Isolate Authoring for security (CMS admin, non-published content, and integrated resources)
- Include redundant resources to handle server failures
That said, the ideal environment is expensive. So, choose what elements are required for your needs, and consider the rest as nice to haves if budget permits.
Sitecore provides some excellent resources to assist with environment planning and configuration.
Sitecore v6.3 and above:
- Introduction to Sitecore 6.3: This document describes how Sitecore’s methodology for handling scaled environments has changed with version 6.3 and beyond. It defines key terms and is a good foundation for understanding Sitecore scaling.
- Scaling Guide: This document describes many environment scenarios and provides details instructions for how to configure scaled environments. It is an excellent document and it covers many of the concepts of this blog post. If using Sitecore 6.3 and beyond, this document is a must read when planning and configuring your hosting architecture.
Sitecore v6.2 and below:
- Staging Module: These pages include all references for the Staging Module, Sitecore supporting scaling technique prior to version 6.3.
- Stager Shared Source Module: This link is to the SVN download for the Stager Module, a competitor to the Staging Module.
- Configuring Production Environments: These pages discuss environment configuration options and provide resources for handling security to optimizing the delivery environment.