Is a multi-role Sitecore server ok in production?

Question

The architecture guidance from Sitecore suggests that multi-role servers - e.g. combining Content Management / Processing / Reporting - should only be done in development and not in production.

However, I've now seen many installations that are only splitting Content Delivery roles out onto their own servers. Often Processing + Reporting are also running on a single Content Management server.

These sites weren't falling over, but perhaps their traffic was just low enough for it not to be a problem. Does anyone have experience of a definite limit they were able to see, that meant running these multi-role servers was just not viable?

Answer 1

It depends somewhat on the modules you're running (and version of Sitecore) and the traffic of your site.

For instance - there is specific guidance around when a dedicated server is needed for EXM (A dedicated server is recommended at 100k+ emails per week): https://doc.sitecore.net/email_experience_manager/configuring_the_delivery_process/dedicated_email_dispatch_server/dedicated_email_dispatch_servers

For xDB - I couldn't find documentation - but in meetings with Sitecore, they've mentioned that more than 1 million interactions per month requires a dedicated Processing Server.

For scale - one of the first things that ends up being broken out is Content Delivery. Your CM server is typically less utilized and can then take on roles like processing, EXM dispatch, etc.

Sitecore licenses are just too expensive to dedicate a server to every role.

Answer 2

I don't think Sitecore specifically says not to combine any roles. From what I've read, they only highly discourage using a standalone (one-instance) environment in production. Separating some roles (such as CM and CD) is crucial. Keeping some other roles combined may not be such a bad idea.

As a matter of fact, the out-of-the-box server roles Sitecore provides are merely examples. Each role consists of several smaller features/subsystems, most of which can be disabled or moved to another server role—so you can actually invent your own server roles! The structure of Sitecore's configuration files was built with that in mind.

Below I'll give examples for two server roles that are most often candidates for combining with other roles.

Reporting Server

In my experience, you only need a dedicated Reporting Server in two cases:

• Your xDB is hosted in the cloud, or in another similar setup, making the Collection database (MongoDB) and the Reporting database (SQL) unreachable directly. In this case, you'd host the Reporting Server in the same network with these databases, and make the Reporting Server directly available to your CM running reporting applications.
• Generation of reports may sometimes take a lot of CPU and memory, which would also justify using a dedicated Reporting Server.

Outside of these two cases, the CM server should be the one generating reports.

Processing/Aggregation Servers

Depending on the amount of traffic your CD servers get, you may or may not need dedicated Processing Server(s). The crucial thing here is to monitor the CPU and memory consumption on all of your servers.

You can combine the Processing Server role with either:

• The CM role if it's not loaded by heavy content editing/publishing/etc.
• The CD role in case your CD servers are powerful enough (which should be a rare case).

If you monitor you server performance, you'll know when you need to scale out and separate your roles. On smaller sites, combining some server roles is a very reasonable thing to do, and I don't believe it contradicts any official recommendations by Sitecore.