Number of servers in a standard Sitecore 9.0.1 XP1 Installation

Question

Currently, in our local environment, we are using Sitecore 9.0.1 XP0 topology but now when we will move to uat or production environments, we will need scaled environments. I need to know that how many servers are mandatory for Sitecore 9.0.1 XP1 basic installation.

FYI: we are planning to have two web servers for load balancing.

Answer 1

With XP1 and two web servers for load balancing, you'll need the following:

On Prem XP1 Configurations

A Standard Sitecore XP1 Environment

• 2 Servers for Content Delivery
• 1 Server for Content Management
• 1 Server for Processing
• 1 Server for Reporting
• 1 Server for xConnect Roles
• 2+ Servers for SQL Server
• 2+ Servers for SOLR / SOLR Cloud

For full detail on topologies, you can visit: https://doc.sitecore.net/developers/scaling-guide/scaling-scenarios/scale-vertically/built-in-topologies.html

On Prem - Absolute Minimum (Not Recommended)

• 2 Servers Content Delivery
• 1 Server - For Everything Sitecore
• 1 SQL Server
• 1 SOLR Server

In this configuratuon, all of the Sitecore roles and xConnect are installed on a single server using different IIS sites. No redundancy, no scaling. Because 9 different server roles are running independently, but at the same time, performance will most likely be an issue.

On Prem Separate but Condensed

• 2 Servers Content Delivery
• 1 Server Content Management
• 1 Server xDB (Containing Reporting and Processing as different IIS Sites, plus xConnect XP0)
• 1 SQL Server
• 1 SOLR Server

This gives you some separation, however processing of interactions may be slowed down significantly if you have a busy site.

Summary

At the end of the day, these are all separated IIS sites, you can combine them anyway you like. But if you're looking for Best Practice, the "Standard" is the way to go.

Answer 2

Dylan Young pointed out that this is likely an opinion-based answer, and I agree. It will completely depend on your solution and how you plan on using the different roles.

Which features you use and how much you use them will dictate your production setup.

Basic recommendations

1. In production XP1 you cannot use Lucene, so that means you need a server running Solr. You could technically run Solr on the same server with other shared services, but you will most likely want this to be isolated in most scenarios.
2. You should likely make sure xDB Collection shards are on dedicated resources and not sharing with other dbs.
3. In most cases, the analytics/reporting databases (i.e. processing tasks/pools/reporting) should also be isolated to make sure processing tasks don't consume the IO needed for content databases
4. Content Delivery should be isolated from Content Management, so there's two servers minimum there when you scale out, even if you run Processing/Reporting alongside CM. You likely have at least one more Content Delivery for High Availability.

What do you need?

1. What kind of traffic levels do you need to meet?
2. Are you going to be running Sitecore Connect or Data Exchange Framework regularly?
3. Do you have additional integrations to xConnect, like in-store applications?
4. Are you triggering a lot of live events from the CD?
5. Do you have surge traffic patterns throughout the year?
6. What is your implementation code going to be doing?
7. Are you running transactional revenue through your site?
8. What kind of performance numbers do you need?
9. What are your requirements for High Availability?
10. Do you have Disaster Recovery requirements? If so, what do you require in your DR scenario?
11. How often do you publish, and how much do you publish?
12. Where are your visitors? Do you have a global delivery need?

All of these, and other factors, dictate what infrastructure you need.

Be ready to change

In the end, my recommendation is to deploy in such a way that you can be flexible and react. If you try to overprovision up front you will inevitably have it wrong and need to change, so make sure that you have put out an infrastructure model where you can easily scale where you find bottlenecks and are not stuck and scrambling to respond to a change in infrastructure requirements.

Separating out the roles will allow you to distribute across servers and scale horizontally more easily. They don't necessarily need their own server to start, but if you scale out fully and share some resources initially it will be easier to spread out.

Takeaways

1. "It depends". Number of servers will be dictated by scenario.
2. Know your Scenario. You need to think through what you are going to do to plan.
3. Be flexible. Separate roles, be ready for change.