SharePoint Min Roles

Why the SharePoint 2016 MinRoles make Max Sense

Microsoft introduced the MinRole concept to the SharePoint 2016 farm setup:

You had the choice of adding a server of type “FrontEnd”,”Distributed Cache”,”Search”, or “Application”

So if you wanted to build a farm using Min Roles and ensure all components were available you needed a minimum of 4 Servers. So MS gave us a 5th option: “custom” which effectively bypasses the MinRole concept and allows you to provision anything you want on that server.

That has lead to many farms consisting of two servers, a FrontEnd and a custom which hosts the rest. This tended to overload the custom server a bit and was less than optimal. but adding any new services to the front end would make it non-compliant!

in November last year MS introduced Feature Pack 1 for SharePoint (just a prettier name than Service Pack) that not only fixed a whole range of cumulative bugs but also introduced new features, such as two new roles:

FrontEnd+Cache and Search+App.

Yay! so now we can build small 2 server farms using the MinRole approach and balance the load better across the two servers. plus having the cache as close as possible to the user-endpoint makes a lot of performance sense.


Why MinRoles?

Out of years of troubleshooting SharePoint farm stability issues I can add my 2c worth:

The distributed cache does not like anyone stealing its RAM. this service, while crucial for operating a stable farm is one of the most fickle and instable components I have come across from MS. if you try co-locating it on a search server you’ll have endless grief as both will be competing for the same precious RAM. forget about Dynamic Memory allocation. I mean it. Forget it even exists. If you want more than one server in your distributed cache, then make sure both have the same spec. any change in how memory is made available to either machine can bring down the cache.

Verdict: if you can, host the distributed cache on its own server(s) (goes for 2013 farms too!). never on the search server, and if co-locating it, then only on the front end server using the new MinRole option.

Search will eat up all resources you can throw at it. RAM, CPU & Disk. It’s the hungriest beast in the whole farm and will bring to a grinding halt any other services you try to co-locate on the server. The crawler will chew through CPU cycles and RAM when performing its crawl cycle, which on continuous crawl is about ALL THE TIME. IO on the Disks will be hammered with the creation and compilation of the search index and your drives will be filling up nicely based on how many TB of content your search server is indexing.

Verdict: always host the search crawl, admin, content processing and analytics components on a separate server to the rest of the farm. you can co-locate those search topology components if your load and patterns allow for it, or break them out onto separate servers. plan your disk space wisely for the server(s) hosting the index component and feel free to co-locate the query component on the front end servers

That leaves us with the IIS Web App components (Front End) and the remaining service applications. in SharePoint 2016 the Application Role and the Front End Role are very similar, the both host most of the required components to serve content to the users. The main difference is that the front end servers have been optimised for low latency and the application server for high throughput.

low latency means that the front end servers will benefit from hosting the service applications locally instead of being forced to connect to service apps on another machine.

With this configuration you do wonder why you should need the app role at all? all it does is host the application discovery and load balancing components and a small hand full of extra services.

Verdict: With the new App+Search role you can now easily co-host the app role on the search server for small farms, eliminating a whole server for the paltry few services that the app role runs.

Leave a Reply

Your email address will not be published. Required fields are marked *