In this chapter, we will be reviewing physical architectures for SharePoint Server 2016, as well as networking, virtualization, and other farm considerations.
Decisions on architectures are dependent on content size, concurrent user support, overall user count, and of course monetary considerations. While this book will cover a highly available architecture with disaster recovery systems, many architectures remain valid for a variety of use cases and should be designed with your use case and requirements in mind.
SharePoint Server 2016 Farm Architecture
Choosing a farm architecture is a difficult decision, more so when a SharePoint has never been previously deployed to the environment.
Deciding on a farm architecture largely relies on these factors :
Monetary investments available for hardware and software licensing
High Availability and Disaster Recovery Requirements (RTO/RPO)
Anticipated Content Size
Overall User Count
Anticipated Concurrent User Count
Provisioned Services
All of these play a factor in determining hardware and software requirements. For Enterprises implementing a SharePoint farm for the first time, the anticipated content size and concurrent user count may not be easily determined, but there are load generation tools which this chapter will touch on to assist in determining what may be appropriate.
SharePoint Server can represent a significant monetary cost. Hardware requirements are on the upper end of many Document Management Systems. Each SharePoint Server must be licensed, along with each SharePoint User. Another licensing point to consider is SQL Server, and as SharePoint Server 2016 does not support SQL Express, the only option is the licensed editions of SQL Server.
Creating a highly available SharePoint farm will also raise costs not only in initial investment, but also in operational costs. The more servers and services there are to manage, the more expensive the farm becomes over time.
What services are provisioned on the farm will also impact performance. In a farm where you have over 500 million items to crawl, it is necessary to provision a new Search Service Application. If you have additional Search Service Applications, you may also want to provision additional SharePoint Servers to handle that load.
Microsoft introduced the concept of MinRole and Zero Downtime patching . MinRole specifies a specific server runs specific services. MinRole provides the best service placement based on Microsoft’s experience with SharePoint Online. Per Table 2-1, MinRole service placement cannot be changed as it is defined in code. This may be an important consideration if you want to run any custom services within the farm. Zero Downtime patching allows for patching of a SharePoint farm without taking the farm offline, but Zero Downtime patching does not prevent any one particular server in the farm from going offline; for example, a SharePoint patch may require a reboot. This means that for effective high availability, all services within the farm must be allocated to at least two servers.
Table 2-1. MinRole Matrix
Service | Custom | Single Server | Front-end | Distributed Cache | Search | Application |
|---|---|---|---|---|---|---|
Access Services | Y | Y | Y | |||
Access Services 2010 | Y | Y | Y | |||
App Management Service | Y | Y | Y | Y | ||
Application Discovery and Load Balancer Service | Y | Y | ||||
Business Data Connectivity Service | Y | Y | Y | Y | ||
Claims to Windows Token Service | Y | Y | Y | Y | Y | Y |
Distributed Cache | Y | Y | Y | |||
Document Conversions Launcher Service | Y | Y | ||||
Document Conversions Load Balancer Service | Y | Y | ||||
Information Management Policy Configuration Service | Y | Y | Y | |||
Lotus Notes Connector | Y | Y | ||||
Machine Translation Service | Y | Y | Y | Y | ||
Managed Metadata Web Service | Y | Y | Y | Y | ||
Microsoft Project Server Calculation Service | Y | Y | Y | Y | ||
Microsoft Project Server Events Service | Y | Y | Y | |||
Microsoft Project Server Queuing Service | Y | Y | Y | |||
Microsoft SharePoint Foundation Administration | Y | Y | Y | Y | Y | |
Microsoft SharePoint Foundation Database | Y | Y | Y | Y | Y | |
Microsoft SharePoint Foundation Incoming E-Mail | Y | Y | ||||
Microsoft SharePoint Foundation Sandbox Code Service | Y | Y | Y | Y | ||
Microsoft SharePoint Foundation Subscription Settings Service | Y | Y | Y | Y | ||
Microsoft SharePoint Foundation Timer Service | Y | Y | Y | Y | Y | |
Microsoft SharePoint Foundation Tracing Service | Y | Y | Y | Y | Y | |
Microsoft SharePoint Usage Service | Y | Y | Y | Y | Y | |
Microsoft SharePoint Foundation Web Application Service | Y | Y | Y | Y | ||
Microsoft SharePoint Foundation Workflow Timer Service | Y | Y | Y | |||
Microsoft SharePoint Insights | Y | Y | Y | Y | Y | Y |
PerformancePoint Service | Y | Y | Y | |||
Portal Service | Y | Y | Y | Y | ||
PowerPoint Conversion Service | Y | Y | ||||
Project Server Application Service | Y | Y | Y | Y | ||
Request Management | Y | Y | Y | Y | Y | |
Search Administration Web Service | Y | Y | ||||
Search Host Controller Service | Y | Y | ||||
Search Query and Site Settings Service | Y | Y | ||||
Secure Store Service | Y | Y | Y | Y | Y | |
Security Token Service | Y | Y | Y | Y | ||
SharePoint Server Search | Y | Y | Y | |||
SSP Job Control Service | Y | Y | Y | Y | Y | |
User Profile Service | Y | Y | Y | Y | ||
Visio Graphics Service | Y | Y | Y | |||
Word Automation Services | Y | Y | Y |
With this data in hand, a better determination can be made as to what your farm should look like.
When a server is out of compliance with a specific MinRole, it will be notated in Central Administration under Manage Servers in Farm, as shown in Figure 2-1, as well as for the specific service in Manage Services in this Farm.
Figure 2-1. Compliant role information in Central Administration
Dedicated MinRole requires a minimum of eight servers within the SharePoint farm to keep all services highly available, while shared MinRole requires four servers. High Availability will be covered further in Chapter 17.
With the basic concepts of farm architecture, the next step in the architecture process is reviewing the hardware and software requirements for SharePoint Server 2016.
Hardware and Software Requirements
SharePoint Server 2016 hardware requirements remain largely unchanged from SharePoint Server 2013, and any production hardware provisioned for SharePoint Server 2013 can be used with SharePoint Server 2016, as noted in Table 2-2. These are minimum requirements. Production deployments often require significantly higher specifications.
Table 2-2. Hardware Requirements
Server | Processor | Memory | Primary Disk | Secondary Disk |
|---|---|---|---|---|
SharePoint Server | 4 Cores, 64-bit | 12 – 24GB | 80GB | 80GB |
SQL Server | 4 Cores, 64-bit | 12 - 16GB | 80GB | N/A |
SharePoint Single Server Farm | 4 Cores, 64-bit | 12 - 24GB | 80GB | 100GB |
SharePoint Server 2016 can be installed on Windows Server 2012 R2 Standard or Datacenter, as well as Windows Server 2016 Standard or Datacenter.
Each SharePoint Server requires the following prerequisites.
Active Directory Rights Management Services Client 2.1
Cumulative Update 7 for AppFabric 1.1 for Windows Server
Microsoft CCR and DDS Runtime 2008 R3
Microsoft .NET Framework 4.6
Microsoft Identity Extensions
Microsoft Information Protection and Control Client
Microsoft ODBC Driver 11 for SQL Server
Microsoft SQL Server 2005 Analysis Services ADOMD.NET
Microsoft Silverlight 3 (optional)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
SQL Server 2012 Native Client
Visual C++ Runtime Package for Visual Studio 2012
Visual C++ Runtime Package for Visual Studio 2015
WCF Data Services 5.6
Windows Server AppFabric 1.1
Additional software may be required when installing other services on top of SharePoint, such as Microsoft’s Business Intelligence functionality.
Supported versions of SQL Server are SQL Server 2014 Service Pack 1 and SQL Server 2016, Standard and Enterprise editions. SQL Express is no longer supported for a SharePoint Server farm.
When deploying Business Intelligence services, such as SQL Server Reporting Services, PowerPivot, and Power View, SQL Server 2016 is required with SharePoint Server 2016.
The choice for using SQL Server Standard or Enterprise will largely come down to what method of SQL Server High Availability and Business Intelligence services are deployed to and for the farm.
Virtualization plays an important role in today’s data center as well as the cloud; next we will take a look at virtualization options, as well as restrictions with regards to SharePoint Server 2016.
Virtualization
Microsoft fully supports virtualizing SharePoint Server and SQL Server on Hyper-V and other hypervisors, such as VMware ESXi, via the Server Virtualization Validation Program at https://www.windowsservercatalog.com/svvp.aspx. For SharePoint Server, there are restrictions on supported virtualization technologies.
Virtualization is an important technology in today’s world, providing greater density in the enterprise environment. It is important to thoroughly test performance of the underlying host hardware in order to properly plan the layout and configuration of virtual machines. For example, placing SQL Server virtual disks on the same LUN as a SharePoint Server may not be appropriate, or allocating a large number of vCPUs when a SharePoint Server may only require four vCPUs, thereby causing CPU oversubscription and reducing overall performance.
Virtualization Limitations and Restrictions
Dynamic memory techniques, which adjust the amount of virtual RAM allocated based on the load of the virtual machine, such as Hyper-V Dynamic Memory or VMware Memory Ballooning, are not supported by SharePoint Server. The Distributed Cache service and Search Server Service create memory allocations based on the memory available when those respective services start. If memory is removed from the system below the amount of memory allocated when the SharePoint Server has started, these two services would be unaware of that change in allocation and cannot adjust their memory quotas appropriately.
Differencing disks are virtual disks that multiple virtual machines may use as a “base.” For example, a virtual disk with Windows Server 2012 R2 and the appropriate SharePoint Server 2016 prerequisite installed could serve as that base, and each SharePoint Server virtual machine would have its own, separate virtual disk where changes would take place. This can cause performance penalties for SharePoint Server, thus Microsoft does not support them.
“Online” virtual machine backups are backups of an entire virtual machine, including virtual machine configuration as well as any virtual disks. The operating system in the virtual machine, as well as any applications, is unaware of the online backup. Microsoft does not support these operations with SharePoint Server as online backups do not happen at exactly the same time throughout the farm. This could lead to inconsistencies between farm members if the backups were to be restored, including inconsistencies between the SharePoint Servers and SQL Server databases.
Like online virtual machine backups, online checkpoints, also called snapshots, are also not supported by Microsoft for the same reason. Not only do checkpoints present the same issue of farm consistency during a checkpoint rollback, but they may lead to performance issues, as checkpoints generate a new differencing virtual disk for any changes after the checkpoint was taken.
Replication of SharePoint Server virtual machines is not supported. This includes any form of replication, such as Hyper-V Replica, VMware vSphere Replication, or even Storage Area Network (SAN) block level or file level replication.
Time synchronization services at the virtual machine level should be disabled. The Windows virtual machine will then leverage an authoritative time source within the domain, either the Active Directory Domain Controller with the PDC Emulator FSMO role, or another Domain Controller member server. This ensures time is consistent between SharePoint servers within the farm.
Networking plays a very important role with SharePoint, and next we will examine the required ports for SharePoint as well as networking bandwidth and latency limitations.
Network Requirements
Microsoft recommends the use of the Windows Firewall when possible. With this in mind, and with the potential of other firewalls between SharePoint farm members, SQL Servers, and/or Domain Controllers, it is important to make sure the appropriate ports are open for SharePoint to operate properly. SharePoint will automatically create the Windows Firewall rules when SharePoint is installed. Review Table 2-3 for the ports required by SharePoint and related services.
Table 2-3. Ports Required for SharePoint
Service | TCP Port | UDP Port | Protocols |
|---|---|---|---|
Distributed Cache | 22233, 22236 | N/A | ICMP Type 0 (ping) |
People Picker | 53, 88, 135, 137 - 139, 389, 445, 636, 749, 750, 3268, 3269 | 53, 88, 137 - 139, 389, 445, 749 | N/A |
Sandbox Service | 32846 | N/A | N/A |
Search Crawler | Web Application Ports Used (e.g. 80, 443) | N/A | N/A |
Search Index | 16500 - 16519 | N/A | N/A |
Service Applications | 32843, 32844 | N/A | N/A |
SQL Server | 1433 (default) | 1434 (default) | N/A |
WCF Services | 808 | N/A | N/A |
User Profile Service | 53, 88, 389, 5725, 1025 - 5000, 49152 - 65536 | 53, 88, 389, 464 | N/A |
SMTP | 25 (default) | N/A | N/A |
SharePoint Server requires that all servers in the farm are connected with at least 1Gbps network connectivity and 1ms response time over an average of ten minutes. Latency can be measured using any preferred tool, including ping, Psping, Hrping, and others. Microsoft does expect some latency above 1 ms due to various factors, including the use of virtualization or switch fabrics adding latency. The latency limits a SharePoint member server placement to 186 miles (299 km) from each other in a vacuum; however, given that we do not live in a vacuum, the distance may be significantly reduced.
Like SharePoint Servers in the farm, the SQL Servers must also have 1 ms or less latency to each SQL Server running in a synchronous form of replication, as well as the SharePoint servers that the SQL Servers are supporting. This means a SQL Server using AlwaysOn Availability Groups in Synchronous mode will likely need to be within a very short distance of one another.
SharePoint is heavily dependent on a healthy Active Directory forest. Domain Controllers for all domains from which SharePoint users and services reside in should be close to the SharePoint farm, preferably within 1ms RTT and connected with at least 1Gbps connectivity. Each Active Directory Domain should have two or more Domain Controllers for high availability.
Chapter 3 will discuss in further depth how Active Directory is secured for the SharePoint Server 2016 farm.
Note
Psping is a Microsoft Sysinternals Utility available from https://technet.microsoft.com/en-us/sysinternals/jj729731.aspx. Hrping is available from CFOS Software at https://www.cfos.de .
Network Load Balancers
Network Load balancers are key to providing high availability to SharePoint for your end users. While many load balancers offer SSL Offloading, this should be avoided where possible. Using SSL Offloading removes the encryption on the load balancer and sends the resulting request in clear text to the target services, such as SharePoint. SharePoint uses OAuth tokens for a variety of purposes, such as communicating with Office Online Server, Workflow Manager, and SharePoint Add-ins. OAuth tokens are plain text and rely on transport security, such as SSL, in order to remain secure. While SSL Offloading no longer provides a performance advantage in terms of CPU utilization on a server with a modern AMD or Intel processor, it can reduce the impact of the SSL handshake, which can add up to a few hundred milliseconds. Browsers will reuse the HTTP session, which may reduce the likelihood of another SSL handshake from being required. SSL Offloading may also be used for traffic inspection, looking for exploits, data validation, and so on.
In either case, explore using SSL Bridging instead of SSL Offloading. SSL Bridging decrypts the end user’s SSL session at the load balancer, and re-encrypts the SSL session from the load balancer to the SharePoint server. This allows the load balancer to reuse the SSL sessions and reduce the impact of any SSL handshake.
With networking requirements restrictions, and load balancer options covered, we will take a look at the Active Directory service accounts that SharePoint requires.
Service Accounts
Guidance for Service Accounts varies. In this book, we will be taking the minimalist approach, which has proven performance benefits and no known security risks. There are four recommended Managed Accounts for SharePoint; the Farm Account, Service Application, Web Application Pool Account, and Claims to Windows Token Service account. In addition, non-Managed Accounts include a Crawl Account (for Search), User Profile Synchronization (for the AD Import synchronization connection), Portal Super User (for Publishing), and Portal Super Reader (for Publishing). SQL Server should also be run as a Domain User account.
Each account has a specific purpose and supports various services of the SharePoint environment as outlined in Table 2-4.
Table 2-4. Service Account Rights
Service Account | System/Service | Permission/Role | Notes |
|---|---|---|---|
Farm Account | SQL Server | dbcreator securityadmin | Roles are optional but recommended; database creation/security may be managed by DBA |
Farm Account | SharePoint Server | Farm Administrator Shell Administrator WSS_ADMIN_WPG Local Group WSS_RESTRICTED_WPG_V4 Local Group WSS_WPG Local Group | On Farm creation, these permissions are assigned automatically |
SQL Server Account | SQL Server | sysadmin Perform Volume Maintenance Tasks Lock Pages in Memory | Fixed role is added automatically when the SQL Server service is configured to run as the Domain User. Perform Volume Maintenance Tasks and Lock Pages in Memory are Local Security Policy User Rights. These will allow instant initialization of database files and prevent Windows from paging out memory in use by SQL Server, respectively. |
Web Application Pool Account | SharePoint Server | WSS_WPG Local Group | Other permissions may vary |
Service Application Pool Account | SharePoint Server | WSS_WPG Local Group | Other permissions may vary |
Claims to Windows Token Service Account (C2WTS) | SharePoint Server | Local Administrator User Rights Assignment: Act as part of the Operating System Impersonate a client after authentication Log on as a service | These rights must be assigned on any SharePoint Server running the C2WTS service, in addition to configuring Kerberos Constrained Delegation for external services where required |
Search Crawl Account | SharePoint Web Applications | Full Read User Policy | |
User Profile Synchronization Account | Active Directory | Delegated Rights: Replicate Directory Changes Replicate Directory Changes All | Can be configured via Active Directory Users and Computers or ADSI Edit |
Portal Super User Account | SharePoint Web Applications | Full Control User Policy | |
Portal Super Reader Account | SharePoint Web Applications | Full Read User Policy |
It should be noted that the Farm Account account no longer requires Local Administrator rights on any SharePoint server. This is due to the User Profile Synchronization Service (Forefront Identity Manager) no longer being part of the SharePoint Server 2016 product. The Claims to Windows Token Service account is now the only account that continues to require Local Administrator rights, but depending on the features deployed to the farm, does not necessarily need to be provisioned.
With all of the basic requirements for SharePoint Server 2016 covered, let’s take a look at the various topology options available to us.
SharePoint Farm Topology Options
SharePoint topology strategies are numerous. Here we will go over the most common topologies, as well as the minimum required topology for the new “Zero Downtime” patching functionality.
Single Server Farm
A single server farm , as depicted in Figure 2-2, consists of a single SharePoint Server with SQL Server installed on the same server. It is possible that SQL Server may also be running on its own server. This farm architecture has a specific installation role named “Single Server Farm.” With this role, it is not possible to add additional SharePoint Servers to the farm, although it is possible to change the role postinstallation to accommodate a farm expansion.
Figure 2-2. Single Server Farm
Single server farms have the disadvantage of high memory requirements in order to operate effectively, especially when SQL Server is installed on the same server. Careful memory management with SQL Server is key to acceptable performance. Continuously monitoring the SQL Server memory requirements via Performance Counters is required in order to properly set the Maximum Memory value.
Single Server farms are suited to specialized roles, such as the Microsoft Identity Manager Portal, or Team Foundation Server integration, but are otherwise not recommended for production purposes due to potential significant load and lack of high availability.
One advantage of Single Server farms with SQL Server on the SharePoint Server over all other farm types is that these farms may be checkpointed/snapshotted, replicated (via a hypervisor or SAN block or file level replication), and online virtual machine backups may be taken for this farm type.
If a Single Server farm is under consideration, it may be worth looking into leveraging SharePoint Online for the lower cost of ownership.
Three-Tier Farm
The three-tier farm is one of the most common farm types. These farms consist of a single Web Front End, single Application Server, and single SQL Server. Web Front End is simply defined as the SharePoint Server that is handling end-user traffic, while the Application Server is defined as a SharePoint Server that is not handling end-user facing traffic while typically handling most SharePoint services, such as Business Data Connectivity Services, Managed Metadata Service, and so on.
When installing SharePoint Server with the three-tier farm architecture, shown in Figure 2-3, the Custom role option must be selected for each SharePoint Server. This will allow you to set which services run on each server. The Custom option is the same approach to deploying a SharePoint farm as one would have taken with SharePoint Server 2010 and 2013.
Figure 2-3. Three-Tier Farm
For the three-tier farm architecture, it is recommended to run Distributed Cache, Microsoft SharePoint Foundation Web Application, Search Query Processing role, and Search Index Partition role on the Web Front End. This provides the best end-user experience for these services, although you may want to consider running additional services on the Web Front End for improved performance. See the Streamlined Architecture section later in this chapter.
The Web Front End Server is where all other services will run, such as Business Data Connectivity Services, Managed Metadata Service, User Profile Service, and any other service which will not run on the Web Front End but is required within the farm. This may lower the memory requirements for the Application Server compared to the Web Front End.
Traditional Highly Available Farms
Other topologies provide basic high availability, as Figure 2-4 shows. These topologies can suffer the loss of one or more SharePoint Servers and SQL Servers while still serving users.
Figure 2-4. Highly Available Traditional Topology Farm
An example of this would be two Web Front Ends, two Application Servers, and two SQL Servers using a form of high availability, such as SQL Clustering, Database Mirroring, or AlwaysOn Availability Groups with Failover Clustering.
The Web Front Ends would be behind a load balancer, such as an F5 Big-IP or KEMP LoadMaster. The load balancers would detect a server failure and automatically route traffic to the available Web Front End. For Service Applications, SharePoint operates in a round-robin load balancing when two or more SharePoint Servers in the farm are running any one particular Service Instance. For example, if two SharePoint Servers are running the Managed Metadata Service and one SharePoint Server fails, the SharePoint Topology Service will automatically remove the failed SharePoint Server from the round-robin load balancing and the Managed Metadata Service would continue to be available within the farm. More information on the Topology Service and round-robin load balancing can be found later in this chapter.
MinRole Farms
Microsoft introduced the new concept of “MinRole” to SharePoint Server 2016. Dedicated MinRole is a set of SharePoint Server roles that are defined by the services required for that role. Roles are enforced through SharePoint code. For example, if a SharePoint Server is deployed with the “Distributed Cache” MinRole, SharePoint will automatically provision the Distributed Cache service. If other services are started that do not comply with the MinRole selected, such as the Managed Metadata Service, the SharePoint Server with the Distributed Cache MinRole will be considered out of compliance and notated as such in Central Administration.
MinRole consists of the following new installation roles.
Distributed Cache. This role runs Distributed Cache, but does not handle end-user traffic directly.
Front-end. This role not only handles end-user traffic, but runs many services that require low latency for end users, such as the Managed Metadata Service, or User Profile Service.
Application. The Application role runs what are considered non-latency-sensitive services, such as workflow or PowerPoint Conversion Service.
Search. Search runs the specific Search roles such as the Admin or Content Processing roles.
Dedicated MinRole farms can be deployed with a minimum of four SharePoint Servers in the farm, although this provides no high availability for SharePoint. Dedicated MinRole farms comply with the Streamlined Topology, discussed later in this chapter.
Zero Downtime MinRole Farms
Downtime patching requires the SharePoint farm be highly available for all services, as shown in Figure 2-5. This means there must be a minimum of eight SharePoint Servers within the farm when using dedicated MinRole and four servers when using shared MinRole.
Figure 2-5. Highly Available MinRole with Zero Downtime Patching Support
There are two servers deployed with the Distributed Cache MinRole. The next two SharePoint Servers run the Front-end MinRole, and these two SharePoint Servers are behind a load balancer that can detect server failure and route end-user traffic to the available server. Next, there are two Application MinRole servers, and finally, two Search MinRole servers for a highly available Search Service. In this configuration, any one particular role can suffer a single SharePoint Server failure, or multiple server failures across roles. For example, a single Front-end and single Application server can be down at the same time.
A Zero Downtime MinRole farm , of course, would be supported by one or more highly available SQL Server configurations, such as one or more SQL Clusters or AlwaysOn Availability Groups with Failover Clustering.
The November 2016 Public Update brings Feature Pack 1 where Microsoft has introduced the concept of shared MinRoles. These consist of the following new installation roles.
Distributed Cache and Front-end
Application and Search
The enhanced MinRole options allow for smaller farms than the original MinRole options, but the roles are otherwise identical to the dedicated MinRoles described above.
This book will be using dedicated MinRoles, although shared MinRoles are a viable option for the smaller installations where prior to the November 2016 Public Update, the custom MinRole option had to be used.
As with previous MinRoles, it is possible to convert a server from the dedicated to shared MinRoles, or visa versa.
Zero Downtime Traditional Farms
Zero Downtime patching can also be used with more traditional farms, such as a three-tier highly available farm configuration. Each server would use the Custom role with all services remaining highly available within the farm.
Traditional Service Application Topology
The Traditional Topology is a topology that has been used for many years, and is often deployed today with SharePoint Server 2013.
This model follows installation of the Microsoft SharePoint Foundation Web Service on the Web Front End server. The topology may also add Distributed Cache to the Web Front End, as well.
The Application server runs all other services in this topology. This places a higher load on the Application server in comparison to other topologies, while potentially reducing the load of the Web Front End. Increased network traffic may result from this topology due to services communicating from the Application server to the Web Front End; for example, a call to a Managed Metadata field would travel from the Web Front End to the Application server, then back through the Web Front End before reaching the user’s browser.
Streamlined Service Application Topology
The Streamlined Topology was born out of Microsoft’s experience with SharePoint Online and is the preferred topology. This topology was introduced about a year into the SharePoint Server 2013 lifecycle.
Microsoft tiered services in the Streamlined Topology based on latency for end users. Services that required lower latency, that is, faster access for end-user requests, were placed on the Web Front Ends. Services that were not end user interactive, such as the workflow service, were placed on back-end Application servers (also called “batch” servers).
In certain conditions, this farm topology provided better performance and responsiveness for end users over the Traditional farm topology. Farms using MinRole leverage this topology.
Topology Service
The Round Robin Service Load Balancer , the core function of the Topology Service, is responsible for adding and removing available Service Application endpoints, along with endpoint availability.
The Round Robin Service Load Balancer will enumerate all Service Application Proxies in the farm and determine what endpoints are available. Each Service Instance on a SharePoint server is exposed via an endpoint.
In SharePoint Server 2013 with the Streamlined Topology configuration (and in certain scenarios, the Traditional Topology), because the Round Robin Service Load Balancer would add endpoints to the internal round-robin load balancer, it was possible that even if a particular endpoint was available on the SharePoint Server the end user was connected to, their request may be routed to another SharePoint Server in the farm. This is less than ideal, as the idea behind the Streamlined Topology was to keep end-user requests on the local SharePoint Server.
With SharePoint Server 2016, Microsoft introduced the ability for the Round Robin Service Load Balancer to keep the end-user requests on the same server when MinRole is enabled. This provides the best latency and performance for end-user requests and reduces network load between SharePoint farm member servers.
Hybrid Considerations
SharePoint Server 2016 offers Hybrid Search, where the Search Index is unified with a SharePoint Online Tenant Search Index. If Hybrid Search is used, the On-Premises farm does not utilize a local Search Index. This may factor into plans to reduce the number of Search Servers within the farm.
Utilizing OneDrive for Business in hybrid configuration (redirection) can also help reduce the necessary On-Premises hardware required for SharePoint and SQL Server by offloading all MySite-related activity and storage to SharePoint Online. Chapter 14 will go into further detail on Hybrid.
SQL Server architecture is also an important consideration for a performant SharePoint farm. We will take a look how measure performance and a brief look at high availability architecture.
SQL Server Architecture
SQL Server plays a very important role for SharePoint Server 2016 performance, availability, and Disaster Recovery. Performance measurements of SQL Server prior to deployment are crucial in to gauge limitations of the system and determine when a scale up or scale out of SQL Server is required.
Performance
The first step is to measure the potential performance of SQL Server is the disk I/O subsystem. Microsoft has created a tool, Diskspd, to measure disk performance. This tool will provide valuable data in terms of the number of IOPS the disk subsystem is capable of supporting. Note that testing write performance (the DiskSpd -w switch) will cause data loss. Only test write performance on a disk with no data.
Note
Diskspd is available from Microsoft on the TechNet Gallery. https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223
In addition to disk, the amount of memory available to SQL Server plays a critical role in SharePoint Server performance. The more memory is available to SQL Server, the larger datasets the memory can hold and the longer SQL Server can keep those datasets in memory.
Lastly, CPU performance is crucial. Modern physical SQL Servers will typically have two sockets with four or more cores per CPU. However, in a virtual environment, be sure to allocate two or more vCPUs, depending on performance requirements. A single vCPU may lead to very poor performance in all but the very smallest of environments.
Setting an appropriate Maximum Memory value for SQL Server is important to reserve memory for the operating system and any ancillary programs running on the SQL Server. This will help prevent paging of either SQL Server memory or other process memory to disk, which may reduce overall SQL Server performance.
High Availability and Disaster Recovery
SharePoint Server supports SQL Server High Availability including SQL Server Clustering, Database Mirroring, and SQL Server AlwaysOn Availability Groups. As SQL Server Database Mirroring is deprecated, this book will focus on leveraging AlwaysOn with SharePoint Server databases. We will be reviewing AlwaysOn Availability Groups in Synchronous mode with automatic failover for a local site. SQL Server Clustering is also a valid option; however, SQL Server Clustering does not provide high availability for storage. Conversely, AlwaysOn doubles the storage requirements.
As with disk performance testing for SQL Server, we need to perform load testing for SharePoint, covered in the next section.
Load Generation/Load Testing
While having an architecture outlined is important, so is testing it! Microsoft has two primary tools for testing, Visual Studio 2013 Ultimate or Visual Studio 2015 Enterprise, and the SharePoint Load Generation Tool. These Visual Studio editions include recording specific actions taken in a browser, with the ability to run multiple controllers concurrently to test many users accessing a farm at once.
The SharePoint Load Generation Tool is an add-in for Visual Studio 2013 Ultimate and Visual Studio 2015 Enterprise that performs the following tests:
CSOM List Read and Write load test
MySite Read and Write load test
MySiteHost Read and Write load test
The SharePoint Load Generation Tool also has additional options for authentication and number of servers to test, and automatically records pertinent performance counters for review post-test.
Note
`The SharePoint Load Generation Tool is available on the Visual Studio Gallery.
https://visualstudiogallery.msdn.microsoft.com/04d66805-034f-4f6b-9915-403009033263
Now we will examine the SharePoint Server, SQL Server, Workflow Manager, and Office Online Server architecture used in this book. This farm architecture demonstrates the High Availability MinRole architecture.
Architecture in Action
The farm architecture chosen for this book, depicted in Figure 2-6, we will be using the minimum viable farm for a highly available MinRole configuration and “Zero Downtime” patching .
Figure 2-6. Farm Architecture chosen for this book
The SQL Servers will be part of an Availability Group using Failover Clustering to provide an AlwaysOn Availability Group for the SharePoint Server databases. In addition, the Failover Cluster quorum will reside on a file server, LSQUORUM01, in order to provide automatic failover. The SharePoint servers fulfilling the Front-end role will reside behind a load balancer. This load balancer offers detection of failed hosts to provide the highest availability possible to clients. In addition to the SharePoint farm, a Workflow Manager farm will also be provisioned with the following architecture, shown in Figure 2-7.
Figure 2-7. Workflow Manager Farm
Workflow Manager will be covered in further detail in Chapter 10; however, Workflow Manager can be set up with either a single server or three servers. No other valid configuration is available. In addition, Workflow Manager only supports up to SQL Server 2012, hence the addition of two SQL Servers configured with an AlwaysOn Availability Group.
Lastly, the environment shown in Figure 2-8 consists of an Active Directory Rights Management Services server, Exchange Server 2016, Microsoft Identity Manager 2016, and Office Online Server in a three server highly available environment.
Figure 2-8. The Learn-SP2016.com environment
Business Intelligence
SQL Server will continue providing Business Intelligence features for SharePoint Server 2016. Features such as SQL Server Reporting Services, PowerPivot, and Power View will require SQL Server 2016 for Business Intelligence services, although the SQL Server Database Engine may continue to run on SQL Server 2014 with Service Pack 1. Previous versions of SQL Server for Business Intelligence services are not compatible with SharePoint Server 2016. Business Intelligence will be discussed further in Chapter 12.
Next Steps
We covered some of the basic decisions required to determine what farm topology is right for your configuration and touched on a variety of viable farm topologies, along with reviewing the MinRole and Zero Downtime patching features.
In the next chapter, we will go through an end-to-end installation of SQL Server 2014 with Service Pack 1 on Windows Server 2012 R2 with a Core installation, as well as SharePoint Server 2016 in a highly available MinRole farm. The chapter will also cover security fundamentals for Active Directory, SQL Server, and SharePoint Server.