Now that SharePoint 2016 IT Preview is available to play with and test, the first thing you need to understand before you even think about installing is what the MinRole is. In a nutshell, MinRole allows you to define the purpose of the SharePoint server. By selecting a specific role, SharePoint automatically configures the services it needs and optimizes performance of the farm based on that topology. The following table outlines each role that is available:
| Server role | Description | ||
|---|---|---|---|
|
Front end |
Service applications, services, and components that serve user requests belong on front-end web servers. These servers are optimized for fast performance. |
||
|
Application |
Service applications, services, and components that serve back-end requests, such as background jobs or search crawl requests, belong on Application servers. These servers are optimized for high throughput. |
||
|
Distributed Cache |
Service applications, services, and components that are required for a distributed cache belong on Distributed Cache servers. Optionally, you can configure these servers to also load balance farm traffic using the SharePoint Request Manager. |
||
|
Search |
Service applications, services, and components that are required for search belong on Search servers. |
||
|
Custom |
Custom service applications, services, and components that do not integrate with MinRole belong on Custom servers. The farm administrator has full control over which service instances can run on servers assigned to the Custom role. MinRole will not control which service instances are provisioned on this role. |
||
|
Single-Server Farm |
Service applications, services, and components required for a single-machine farm belong on a Single-Server Farm. A Single-Server Farm is meant for development, testing, and very limited production use. A SharePoint farm with the Single-Server Farm role cannot have more than one SharePoint server in the farm.
|
Table originally posted https://msdn.microsoft.com/en-us/library/mt346121(v=office.16).aspx
How does this work, you ask?
SharePoint is built and run by using a core set of base services and instances of those services that are required by the specific role of that server. In the past, you would need to define what roles and services were enabled on which. In some cases, the process caused confusion--and often issues--when completed incorrectly.
The MinRole option allows users--right at the start of setup, whether for a new farm or the addition of a new server to an existing farm--to define its role and have SharePoint automatically enable or disable services. It also lets us provision services and optimize for that specific role. This means that we now have the ability to demote and promote server roles, and not have to worry about what services should be disabled or enabled, or provisioned or un-provisioned--it's all done automatically.
What are the real, tangible benefits to the use of MinRole?
I am a great advocate of template-type deployment of SharePoint Servers. We have the ability using PowerShell or other tools to ensure that when we deploy an environment, the process is completed in a way that is repeatable, without odd little things being left out. Too often issues with SharePoint environments are caused by slight misconfigurations, because the process being used is not repeatable or even scripted.
The benefits of using the MinRole approach are not only that it can be scripted to make it an even better template approach, but that deployment is now simplified. By deploying the servers using the Microsoft-recommended MinRole topology, we can now focus on what actually needs to be enabled in the feature stack.
The MinRole model also brings with it better performance tweaks than we could probably have figured out ourselves due to Microsoft running it in the cloud. As you know, the model has always been "cloud first." As such, we in the On-Premises world get those benefits in SharePoint 2016. As the deployed services are optimized as part of the MinRole approach, we should get better reliability and network latency.
The final benefit is really around capacity planning. As I mentioned before, I am an advocate of deploying environments using the "template" approach, whether scripted or not. The new role approach allows for predictable and prescriptive capacity planning guidance, and for topologies to be designed and delivered. Adding servers to scale is now even easier due to the automated process used for provisioning of services specifically for the designated roles.
What topologies are recommended when using the MinRole?
Microsoft currently recommends the following server topologies:
These topologies will allow for better server farms; however, if we look at what the minimum should be, we are now moving into using more servers than before.
Microsoft has stated the minimum 100% supported environment using MinRole is a four-server farm. The farm would not offer any resiliency or recovery as such, so larger farms will be needed. The example used by Microsoft is moving the standard four-server farm to be a fully resilient topology, which would mean the minimum would now be nine servers.
- 3 x Distributed Cache Servers
- 2 x Front-end Web Servers
- 2 x Application Servers
- 2 x Search Servers
We would also need to add SQL to this, and you would probably be using Always On Availability Groups--using multiple servers that could then scale to a minimum of two servers or more, which would take our total to about 11 servers!!
This does not mean that you have to have something this large. You still have the ability to build out servers as needed, starting with a two-server farm. Of course, my recommendation would be to build out a much larger, more resilient environment. Now, remember, you can opt out of the MinRole setup process, as SharePoint 2016 Preview supports the backward-compatible approach using the Custom role. You can setup your SharePoint 2016 farm in this manner, and then choose to modify later by using the standard role change options that are now available within Central Administration. To change a server role simply modify its role.
- Access the Central Administration website
- Click System Settings section.
- Click Convert server role in this farm.
- Click the drop-down box to select the appropriate new role.
- Click Apply.
So no more worries about manually changing the services and roles if you are using the MinRole process. And, as an advocate for making our SharePoint environments more secure, i encourage you to consider that the MinRole model--though not a security function--goes a long way toward reducing the footprint and surface area of attack on these servers, which can only help us in the long term.
