SharePoint 2016 Core Infrastructure Design

As with any version of SharePoint there are changes that inherently make its way to the overall logical design of a farm. Previous to SharePoint 2016 we had been given specific guidance based on what was referred to as the “Traditional” model. This was based around the simple 3-tier model of a Web, App and Database Server.

This design worked great and made it very simple for a SharePoint Farm to be built, however it did have limitations of choice for each server. From a Security Perspective it meant that the footprint of each server tended to be much larger than it needed to be. With subsequent releases Microsoft gave us the “Streamlined” approach instead. This design was about increasing the base number of servers, by splitting a role out which was introduced called “Distributed Cache”, then making sure that SharePoint had an internal load balancer to allow traffic to go between all servers as designated if needed. So Service Application traffic could always work, based on it selecting the best node to access it from.

With SharePoint 2016 we now have what is called “MinRole” which even though the design is not called this, has a greater bearing on the number of servers that are needed to make the farm work. A standard SharePoint 2016 environment now needs to use 4 servers in the farm if “MinRole” is being used. This is very similar to the other topology designs that we have been used to with SharePoint 2013. The core difference here is that as I posted in a previous post about “MinRole”, the servers only enable the features and components needed for the specific role.

One of the main things that SharePoint 2016 allows is for each server to be scaled sideways, so a High Availably farm would look like this.

As you can see this increases the number of servers to double that of what we have in a smaller farm but does give you better availability for each component. This logical design allows to mix roles as needed, combining all “MinRole” models together. Now you do not have to follow the “MinRole” approach, you can still choose a custom installation allowing you to follow the older style designs as needed.

If needed you also have the ability to mix “MinRole” defined servers with “Custom” servers to give you the best design possible. Personally I like to stick with the “MinRole” design, as I then know that all my servers only have the roles and services enabled that I specified for them. It also means that using the compliance features I can then see if some enabled or changed something in the environment making the servers go out of compliance.

The main logic behind this type of architecture can be summed up in the following benefits:

All in all, this new design pattern will allow for a better design, easier support and a cleaner overall solution.

To learn more you can see the official Microsoft diagrams for SharePoint 2016 here: https://docs.com/officeitpro/2973/microsoft-sharepoint-architectural-models

To learn more about SharePoint 2016, join me on June 29^th, for three webinars on SharePoint 2016 Infrastructure. You can register here: http://sharepointpromag.com/sharepoint-2016-infrastructure