Definitive Guide to Sitecore Infrastructure and Licensing – Part 2: Sitecore Roles and Horizontal Scaling

See Part 1: Sitecore Solution Components

Sitecore Roles

Once installed, the Sitecore software can be configured as part of a multiple instance solution to perform a specific role or set of functions.

• Content management, such as authoring and editing.
• Content delivery, serves HTTP/HTTPS requests for the visitors to the website(s).
• Processing and aggregation, extracts raw information (generally from the Mongo collections) and makes it suitable for reporting (loaded in the relational reporting database).
• Reporting service, fetches data from various sources used in reports.
• Publishing service, takes responsibility for publishing content; when scaled out from content management this is a new distinct service (different software) written in .NET core.

When Sitecore is initially installed, configuration of the software is such that all of the above roles and features are installed in the single instance of the software.

Simple Scaled Sitecore Solution

The decision to separate the various Sitecore roles is largely driven by performance and security isolation concerns.

The most common production deployment we see is constituted of three instances of Sitecore. Two content delivery instances sit behind a load balancer and the third performs all of the management, processing, aggregation, reporting and publishing.  Now if we map the roles to actual virtual machines (or physical servers), the model would be as follows.

With two servers acting in the content delivery role, this configuration provides some measure of high availability on the published site and obviously increased capacity while keeping both complexity and licensing costs contained.

Choosing to scale out other roles will depend on the specifics of your solution. Here are some considerations:

• For organizations that have a low tolerance for an outage in a content management (CM) capabilities, the CM function can also be load balanced.
  • Note: While some business will require a guarantee to be able to update the site, it has been our experience that this type of content or data is automatically fed via integration points. Hence, an outage on the content management instance would not impact this ability to manage critical data.
• If there is a high traffic, the market team may value dedicated processing and aggregation servers to handle the load and ensure analytics are processed in a timely manner.
• Related to the previous, heavy use of the reporting interfaces may also warrant dedicated reporting service instances.
• High volumes of content publication or a large number of concurrent authors may warrant offloading publication to dedicated instances.

In the following diagram this scaled scenario has been depicted. An overly simplified view of the database and indexing tiers has been used to highlight the Sitecore interactions. Note that now that reporting is no longer on the same server as content management, a communication path between content management and these services is required. Communication from Content Management to Reporting is over HTTP.

Network Topology and Impact on Database and Indexing Tier

In the last example the database tier was simplified, but the reality of a scaled Sitecore installation and the need for the various roles (possibly distinct virtual machines) to access different databases and services such as Solr will have a meaningful impact on the configuration.

Let’s consider the simple example of the core database. Every Sitecore instance in the environment needs access to either the same instance of the core database or access to near real time replicas of the core database. In Sitecore solutions with geographic distribution – most commonly the content delivery function – latency will become a driving concern.