Unofficial Sitecore Planning Checklist

Thursday, March 02, 2017

Unofficial Sitecore Planning Checklist

By: Scott Gillis, Lead Consultant – 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, but sadly it seems we continue to be in a slow shift to easily discoverable and consumable documentation. It reminds me of the early days of my SharePoint work, where the community documented better than 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.

Some Basics

Beginning with Sitecore Experience Platform 8.0, the ability to scale both horizontally and vertically was introduced and provides the flexibility to place different Sitecore components on individual or combined servers.

The key components to be accounted for during server architecture are:

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 house your content

Session state server

This is the method you choose to track contacts while they actively visit the site.

Listed as an actual server, this can take the form of a server, SQL database, MongoDB collection, or just run 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 to be properly licensed by Sitecore for an additional server install. Each one requires 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, it 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 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.