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.
Each server in the SharePoint farm has its role to play, and these roles are:
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.
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.
The database servers deal solely with the storage and retrieval of data.
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:
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.
Souce: 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:
There are also two special roles:
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.
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.
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:
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.
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.