Microsoft released SharePoint 2016 with much marketing on two new server end features:
- MinRole
- Zero downtime patching
The focus of this blog post will be solely limited to MinRole farms and explaining why it is so important and the improvements it brings.
As you are aware, SharePoint 2013 and 2010 were role agnostic farms. What this really meant is that you were able to run any service on any server in the farm. This was great for flexibility and scale-out options. You could choose to run same service on multiple servers for the sake of load distribution and choose lightweight services to run on front-end/application servers. This was also good for whiteboard presentation and sketch drawing in the meeting rooms. You could also be able to easily add a new server to the farm and then move your service over there without much issues.
However, at some point one would ask and this was perhaps the most common question, “That’s great but how do you choose where to run what and how many servers do you need?”. Microsoft did come out with few service topology architectures most popular being streamlined topology but it did not helped much. The real answer was always, “It depends. Start with basic, observe the performance and then adjust/scale-out.”
Welcome to 2016. Microsoft did get some of the taste of its architecture flexibility by running SharePoint online farms for office 365. So learning from past, the concept of MinRole is introduced. “MinRole” is exactly what it sounds like. A server in a SharePoint farm now runs an explicit set of services based on its role, and no other services are turned on. By selecting a specific role, SharePoint automatically configures the services it needs and optimizes performance of the farm based on that topology. No more running around creating service applications, then running around to start that service on different servers in the farm as per the requirement.
Why this is great? Few reasons that I can think of:
- Automation
- Compliance
- Performance
- Planning
Automation:
Since the role of each server in the farm is exactly defined, you can quickly write scripts to stand up a SharePoint server. When you are joining a server to the farm(or creating a SharePoint farm), you need to define what this server is going to do. It’s also made removal of servers from farms and adding new servers easy. This also forms the core of zero downtime patching where you can quickly add say a front end server in the farm and then remove existing one.
Compliance:
Since role of each server is defined already, you can run a quick compliance check and then brought servers in compliance:
Performance:
It brings improved performance. For this, let’s try to understand how SharePoint 2013 and 2010 handled the incoming traffic. On each server in the SharePoint farm, there was one service known as ‘Application Discovery and Load Balancing Service’ or the ‘topology service’. This service was mainly responsible for maintaining the list of addresses of the service application endpoints. So the communication was like:
IIS Web Application Topology service application and service application endpoint Service Application.
In the previous versions, it would be extremely likely to go to another machine even if the requested service was running locally. It was a basic round robin style approach.
In SharePoint 2016 this has been changed to always “prefer local”. In other words if the requested service is running locally, go there instead of hoping over to another machine. If that isn’t possible then it will go to a remote server. This prefer local model is used within both farms leveraging MinRole Server Roles, and farms where every machine is of role Custom (aka Opting out of MinRole, or a 2013 style topology). So this brings a lot of performance improvement for large farms.
In addition to the prefer local model, the Topology service in SharePoint 2016 is no longer deployed on every server in the farm. It is only deployed to the Application, Search and Custom roles. Also to be worth noted that service application endpoints are only deployed on the roles that are hosting the service instances. For example, if you are running a Distributed Cache minrole server, it does not need any endpoints. There is no need as it always has to check locally for cache.
Planning:
Last but not least, the new role approach allows for predictable and prescriptive capacity planning guidance, and for topologies to be designed and delivered. As mentioned previously, adding/removing servers to the farm is also made easy and can be done on-demand.
Below table summarizes the various MinRoles available in SharePoint 2016 (adapted from MSDN article):
| 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 low latency. | ||
| 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. | ||
| 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 does 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.
|
Important:If you are reading this carefully, you should be noticing that for a fully compliant MinRole farm, you need to have at least 4 servers (each server running one of the MinRoles). for the famous zero-downtime patching marketing, your farm needs to be fault tolerant. So you would need at least 8 servers in the farm. More details can be found in this TechNet article.
You can also go for the custom roles and choose what to run where(in 2013 and 2010 style) but then you would lose all of the above benefits associated with MinRole topology.
Its been sometime since SharePoint 2016 release and Microsoft has realized that forcing users to run these many servers is not doing any good. In SharePoint Server 2016 feature pack 1 released on 1 Nov, they have increased the MinRoles options. Two additional server roles are available: “Front-end with Distributed Cache” and “Application with Search.” The Front-end with Distributed Cache role combines the Front-end and Distributed Cache roles together, while the Application with Search role combines the Application and Search roles together. These new roles let you host a multi-server MinRole farm with just two servers or four servers with HA:
There are some other improvements made in feature pack 1. You can check the link associated for more details.
Don’t panic if you don’t know where to start. You can always start with custom role and then later switch the server role. To change a server role, follow these basic steps:
- 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.
Not only this, in the lifetime of a MinRole server, you can switch from any to any.
mohitgoyal.co 