Exam Prep: SharePoint Workload Optimization

The Exam for SharePoint 2016, is broken down into various categories, in these blog posts we will cover the following:

This post will focus on our second topic of SharePoint Workload Optimization. You will also need to study the following areas:

Some key links outside of the topic for this post can be found below: 

OneDrive for Business in SharePoint Server 2016

My Sites in SharePoint Server 2016

Data loss prevention in SharePoint Server 2016

Once you have designed the SharePoint Infrastructure the next step is to define the services and components in a way that utilize the resources efficiently. For this post, I, will focus on SharePoint High Availability. This is one area that can be complex as it not only covers the services used by SharePoint and their availability but also the end user access and availability to the site.

Firstly, lets understand what we mean by High Availability. We are not talking about Disaster Recovery even though that almost fits into this space. Instead we are talking about making sure that everything works, all the time (well as much of the time as possible) and gives the end user the best performance needed. High availability is generally used to describe the ability of a system to continue operating and provide resources to its users when a failure occurs in one or more of the following categories in a fault domain: hardware, software, or application. The level of availability is expressed as a measure of the percentage of time that a system is continuously operational to support business functions. The required level of availability varies among organizations. Although this requirement may also vary among business units, a service level agreement is for the organization as a whole. From the perspective of users, a SharePoint farm is available when users can access the farm and use the features and services that they must have to do their work.

When designing, and building a Highly Available SharePoint Farm, the goal is to achieve the following:

The availability of SharePoint really comes down initially to the logic design chosen for either the Physical or Virtual machines that will be used. For example, when using a Virtual Environment, High Availability dictates that not all SharePoint VMs are on the same Physical Host.

If using Physical Machines the same would apply, in that each SharePoint Role at least has two servers, as well as SQL server using technology that allows failover to separate nodes as needed.

Each service that resides within the SharePoint Farm also needs to be catered for when looking at High Availability. As an example, Distributed Cache requires special considerations during failover, SharePoint Workflow requires Workflow Manager 1.0 Cumulative Update 3, these need to be considered in the overall design. 

Although service applications can run on multiple computers, which Microsoft recommends, some have unique installation and configuration requirements for high availability. The User Profile application is a well-known example of this. Knowing and understanding this will help you to craft the right high availability solution.

One option that works well and covers all components is the idea of using the Stretched Farm approach for your High Availability. This covers all layers of the design from the database level right through to the end user traffic with load balancing. A stretched farm is about placing servers for the SharePoint, SQL and other Components within different data centers. Now to achieve this your network needs to comply with the following:

Though it does work without meeting this, you will end up with potential errors as well as not having a truly supported environment.

The logical design is actually straightforward, you utilize the standard setup for SharePoint, by using as needed the MinRole roles for the servers, making sure you store the servers across the two data centers instead of all in one. You are not looking at building an old skool failover but more of an environment where traffic could potentially route backwards and forwards between the two sites easily. The following basic image provided by Microsoft (https://i-technet.sec.s-msft.com/dynimg/IC654215.gif) outlines a simple design:

Depending on the number of servers, services and components needed you may have more servers within each data center. Notice that the core piece of this design is not only the SQL Always On / Mirroring but the DNS / Load Balancer that controls the user requests. The advantage of this design is that all content is everywhere, more importantly though is that when something needs to be deployed such as Solution Package (WSP) it is automatically pushed to all servers no matter which data center they reside in.

The Database infrastructure is really the most important element in this design. Building out a solution such as Mirroring, or the better option of Availability Groups is key. 

https://technet.microsoft.com/en-us/library/jj841106(v=office.16).aspx 

To learn more about High Availability and also Disaster Recovery please read the following Microsoft documentation.