SharePoint farm architecture explained

Sooner or later, when reading about SharePoint, you will undoubtedly come across the term SharePoint farm architecture. In a broader sense in IT, the term farm is used for servers. A server farm is just a collection of servers working together to serve a common purpose, or in this case, a web page. Of course, getting a bunch of servers working together is no small feat, just like with people, issues are bound to happen.

Luckily, SharePoint has been around for a while now, and they seem to have hammered down the architecture. It is scalable from a single machine for development purposes up to hundreds of machines. A testament to this fact is SharePoint Online, which is used by thousands of businesses.

Naturally, SharePoint Online is not a single farm, but the performance and scalability improvements that Microsoft achieved with SharePoint Online have trickled down to SharePoint 2016 and later versions.  Learn more about SharePoint architecture best practices in the webinar recording with Michael Noel, one of the best-selling SharePoint authors.

SharePoint server roles

Each server in the SharePoint farm has its role to play, and these roles are:

• Web Front End (WFE) Servers
• Application Servers
• Database Servers

Web front end servers

The end-user interacts with SharePoint by accessing the frontend servers through an internet browser. The WFE server handles user requests for each site, document, or list. The WFE server will most surely need to communicate with other types of servers, but ultimately it is responsible for responding to the user’s request.

Application servers

These servers are typically more resource-demanding and optimized for high throughput. Applications servers run service applications and services that serve backend requests—i.e., scheduled jobs or content crawling. The most notable service application is the search service. Since search plays a huge role in the SharePoint experience, it is not uncommon to dedicate a separate pool of servers just for the search service.

Database servers

The database servers deal solely with the storage and retrieval of data.

SharePoint Server architecture with MinRoles

Before SharePoint 2016, the server roles inside a SharePoint farm were not clear-cut, and you needed to put more care into the initial installation and configuration of SharePoint. With SharePoint 2016 came a new farm architecture design called MinRole.

During the configuration, SharePoint will automatically assign a predefined role to a server and ensure that the server is compliant with the role definition. This definition specifies which services are running. If a service that does not belong to a role attempts to start, SharePoint will automatically stop it. Vice versa, if a service that belongs to a role is about to stop, it will automatically restart.

The server roles that can be assigned are:

• Application
• Distributed Cache
• Frontend
• Search

In other words, to deploy a SharePoint farm, you would need a minimum of four servers. Those, however, do not include the SQL server(s) or any additional servers required to achieve high availability and fault tolerance. So, the number of servers required for high-capacity SharePoint farms can go even higher.

Original image can be found: http://www.sharepointboard.de/sharepoint-2016-2019-medium-and-large-minrole-farm-architectures/

However, the default number of servers needed for a full SharePoint deployment was not justifiable for smaller organizations. After a while, Microsoft realized this and provided two additional roles to minimize the number of servers needed to deploy a more modest farm:

• Frontend with Distributed Cache
• Application with Search

There are also two special roles:

• Single-Server Farm
• Custom

A Single -Server Farm is designed for the purposes of development, testing, and minimal production use. As the name implies, you cannot have additional servers in this farm. In the Custom role, the service applications and services on the servers are under full control of a SharePoint farm administrator. You can find more information about a MinRole server deployment here.

Zero-downtime patching

Sooner or later, the time comes when you want newer features or fix security issues on your SharePoint farm. Software patches are a crucial part of keeping your servers up-to-date and safe from potential cyber-attacks. Patching servers can cause prolonged downtime of your servers, which is no fun at all for users that depend on a functioning system.

Zero-downtime patching allows the users to keep on working while a patch is applied to a server in the SharePoint farm. Zero-downtime patching was not always possible with SharePoint on-prem. The process, along with MinRoles, originated in SharePoint Online, where having downtime was not an option. Microsoft recognized the need for this in on-prem environments, and eventually, it has made its way down to SharePoint On-Premises.

We are mentioning zero-downtime patching because the SharePoint farm architecture must be highly available to achieve it. This means that each role in the Server farm must have at minimum two servers so that one can continue to provide services to the SharePoint Farm while the other one is being patched. Although there is more to the zero-downtime patching than just having a highly available SharePoint farm, this is necessary for the process to work.

Multi-farm SharePoint farm architecture

SharePoint deployment can involve multiple farms. You can configure a SharePoint farm to serve as a host for services that are to be consumed by other farms. This would then be a services farm. The actual types of farms can be:

• Content Farms – host the sites and service applications, but can also consume services from other farms.
• Services Farms – provide services for other farms.
• Search Farms – hosts only the Search service application, consumed by other farms.
• My Site farm – it can exist if there are multiple content farms.

Why multiple farms? One reason might be scaling and capacity requirements. Another reason might be regulatory, keeping the data inside a political boundary will require multiple content farms for a global company.

Original image can be found: https://docs.microsoft.com/en-us/sharepoint/administration/global-architectures#design-a-central-site-with-multiple-farms

What does SharePoint farm architecture have to do with cows?

As we mentioned in the first paragraph, the term farm is used for a number of servers working together to serve a common purpose. But we, at Syskit, came from different backgrounds, and some people were not familiar with this IT term. So, as a not so inside joke, we put cow icons inside of our SharePoint On-Premises administration tool, SPDockit to indicate a SharePoint farm.

SPDockit does a complete scan of your environment and generates a detailed report of your SharePoint farm configuration settings. Check out how SPDockit can help you document your SharePoint server configuration in a blog from Todd Klindt.