Recently I had the opportunity to sit through a series of management courses. One of the main focuses was how to provide an environment to help motivate your team members and increase performance. In parallel to these courses I was working with a client to define the steps required to properly secure and architect a scalable Sitecore installation. After some extensive research and reading, followed by re-reading I’ve tried to compile the ‘Unofficial Sitecore Planning Checklist’.
As Sitecore has matured as a product so has the method of documenting the product, sadly it seems we continue to be in a slow shift to easily consumable and discoverable documentation, it reminds me of the early days of my SharePoint work, where the community documented better the product team. Because of this positive growing pain, you may end up on really old blog posts as well as some ‘ancient’ PDF documentation, which is still plenty applicable. Finally, this checklist is a starting point as documentation and feature sets continue to change and growth with the product always check for the latest before finalizing your organizations plans.
Begin with Sitecore Experience Platform 8.0 the ability to scale both horizontally and vertically was introduced through flexibility to place different Sitecore components on individual or combined servers.
The key components to be accounted for during server architecture is
- Content delivery (CD) server (including personalization)
- the touch point to the visitors, HTML, personalization, etc..flow from here
- Content management (CM) server
- Central nerve to the entire site, authoring and reporting occur here
- Content databases (SQL)
- SQL databases that houses your content
- Session state server
- This is the method you choose to track contacts while the actively visit the site.
- Listed as an actual server this can take the form of a server, SQL database, MongoDB collection, or just ran in memory.
- Collection database (MongoDB)
- Storehouse for xAnalytics as data is collected
- Processing server
- Performs the heavy lifting job number crunching
- Reporting database (SQL)
- Just a database that all the pretty tables and charts come from
- Reporting service
- Service that moves data from SQL to those pretty tables and charts
- Email Experience Manager Dispatch database (SQL)
- Finally a clearly named item (database used to manage the queueing and sending of emails)
- Email Experience Manager Dispatch service
- Another straight named item (API that the servers use to perform the actual sending, dispatching, of emails)
You’ll notice there are a number of SQL databases that are required to support the system. These can all run on the same SQL instance or cluster without issue.
If you plan to place any of the service components on individual servers, you will need be properly licensed by Sitecore for an additional server install as they all require an installation of Sitecore just like a content delivery or management server.
Checkpoint 1: CM and CD Setup
- CD Server
- Bare minimum requirements: 16GB RAM, 4 cores resulting in 8 threads
- Things to watch out for
- Site must process heavy business or search logic making it computationally heavy CPU increase may be needed
- Caching strategy may require additional RAM to support better cache retrieval of HTML and images
- In-Proc Session State will be store to RAM, in which case a high traffic site is going to need more RAM
- CM Server
- Bare minimum: 16GB RAM, 4 cores resulting in 8 threads
- Things to watch out for
- As increase of con-current authors editing increases additional RAM becomes required to provide the better experience (this number may be around 10 to 15)
- In a standard installation the CM server performs the additional duties of processing server, reporting service, and EXM Dispatch manager
- All these will impact the performance of the CM requiring both additional CPU (helps with processing) to additional RAM (helpful for large EXM dispatches as each email is built in memory before being sent.)
Checkpoint 2: Experience Database (xDB)
The Experience Database commonly referred to as the ‘xDB’, is based on the NoSQL solution MongoDB. The xDB is the primary storage for all analytics information and the registry of contacts and engagement automation states. Both Content Delivery and Content Management servers talk to the xDB performing read and write actions against it.
Because data is written and read at high rates from the xDB as visitor’s sessions start and end requires a proper amount of RAM and high speed disk, such as SSD, to maximize performance.
Using MongoDB as your collection database, you should install plenty of RAM and use SSD drives. Sharding can also improve performance significantly. Read the documentation on the MongoDB website to learn about the MongoDB architecture, replication, sharding, and configuration options. (taken from xDB Hardware Guidelines)
Depending on the version of Sitecore running there are official supported MongoDB versions. This does not mean a newer/older version will not work with your version of Sitecore, but Paragon nor Sitecore can guarantee the behavior.
|—||Sitecore XP 7.5 series||Sitecore XP 8.0 Initial Release to Update 4||Sitecore XP 8.0 Update 5 and later||Sitecore XP 8.1 and later||Sitecore XP 8.2 and later|
|Mongo 2.6 mmapv1||Yes||Yes||Yes||Yes||Yes|
|Mongo 3.0 mmapv1||No||No||Yes||Yes||Yes|
|Mongo 3.0 Wired Tiger||No||No||Yes||Yes||Yes|
|Mongo 3.2.1 mmapv1||No||No||No||No||Yes|
|Mongo 3.2.1 Wired Tiger||No||No||No||No||Yes|
|Mongo 3.2.1 Enterprise with data-at-rest encryption (Wired Tiger only)||No||No||No||No||Yes|
Sitecore recommends that MongoDB is setup in a replication architecture with sharding enabled. The minimum configuration is to run two full capacity MongoDB servers for data and a third lower capacity server to act as the arbiter. This third server would not need to handle any data in the basic configuration.
MongoDB can run on either Windows or Linux/Unix servers, as long as the proper version of MongoDB is used the Sitecore application does not care.
Additional Helpful references
- Estimate Memory and Storage Requirements for Session State
- Session State Configuration Scenarios
- MongoDB Considerations
- MongoDB Example Architecture
- MongoDB Session Database Performance Considerations
- MongoDB Performance Considerations 2.4 PDF