SharePoint 2013 farm planning and sizing
There are plenty of resources out there with the information on how to plan for and deploy the SharePoint 2013 farm but here I wanted to try to simplify some of that guidance and gather the best pieces of information at one place, along with sharing my own years of experience from the field.
It goes without saying that you can’t deploy a solution without documenting it first. When I am creating a design and deployment document, I like to start with the solution summary, followed by the scope, prerequisites, and, and then by providing a quick overview of the step by step process on how I am going to deploy the solution. I would also supplement the overview with a picture; you know they say “picture worth a thousand words”. Here is a quick overview of the step by step planning and deployment process which I will be covering in much more detail later in this article.
Sizing the farm
Start your design by gathering some basic workload characteristics such as total number of users, average daily concurrent users, and total number of requests per day. Also try to estimate the workload distribution across different SharePoint capabilities such as Search crawl, Team site activities, and Office Web Apps. Estimate the database size, number of web apps, site collections, number of lists, libraries, and number of items.
In my experience, there is no magic formula for sizing the farm which will get you the exact number of servers and resources for your farm. It is basically more of an art than a science – it is about coming up with an estimate that you can compare with the reference architecture, deploying it and then testing it to make sure that it meets your performance targets. If for some reason you are unable to estimate your workload characteristics, at least try to estimate the total number of users and storage, and use the guidance and reference architectures provided here to design your startup farm. To learn more click here.
The way I like to size the farm is to start with the recommended number of servers for the estimated workload. For example, for 10,000 users or so, I would start with at least four SharePoint servers, and two SQL Servers. This configuration provides a good, well balanced startup topology consisting of the load balancing and redundancy for front end, batch processing, and application servers. The key steps then are to pilot the farm as the following:
- Populate the storage with a sample dataset
- Stress the system with synthetic load
- Run tests, analyze results, and then optimizing the farm by tuning or adding more servers if performance targets are not met.
Use the guidance provided at this link to learn more about performance testing for SharePoint.
Once you have deployed your SharePoint farm in production, continue analyzing performance against the targeted workload on an on-going bases, and make adjustments to the hardware, settings, and the topology based on those analysis. I would scale out (add more servers), rather than scale up (add CPU, RAM) as that provides better performance.
I would load balance web traffic using the hardware load balancer to ensure even distribution across all the web servers, and an optimal experience for the end users. To provide high availability for SQL server, I would use the AlwaysOn technology which automatically failover databases to the active SQL nodes in case one of the nodes fail. AlwaysOn is also much easier to deploy and maintain and now supports most, if not all, of the SharePoint databases. To learn more about AlwaysOn, click here.
If you are using SAN (storage area network), make sure to estimate the amount of traffic (IOPS) and allocate enough disks to satisfy that traffic. For DAS (Direct Attached Storage) on the other hand, separate out the Data, Logs, and TempDB on separate drives and make sure that each disk is providing the required IOPS. Here is a link to learn more on about how to estimate IOPS.
As a recommended practice, you should maintain two times as much free space as your RAM in your SharePoint servers. It is better to oversize and overinvest in hardware as the cost is almost always far less than the cumulative expenses related to issues caused by under sizing.
You should maintain less than 1 millisecond of network latency and 1 Gbps of bandwidth between the farm servers.
Software and Hardware requirements and boundaries
System requirements are pretty simple to understand but make sure to understand the software boundaries as well. Click on the following links to learn more:
Software Boundaries and SharePoint Limits
Traditional Topologies for SharePoint 2013
Streamlined Topologies for SharePoint 2013
Distributing and running servicesWith SharePoint 2013, Microsoft introduced the new streamlined topology model designed to maximize the system resources. This model include Front-end servers, batch-processing servers, specialized workload servers, and database servers. Front-end servers are good candidate for running services that interact directly with users such as web applications, search query, managed metadata, and user profile. These servers are optimized for fast performance. Batch processing servers are good candidates for running background tasks such as search crawl, user profile synchronization service, and workflow timer service. These servers are optimized for maximum system resources. Database servers are where you host all of your databases. Guidance for deploying database servers is same as the traditional topology. If needed, you can have dedicated servers for specialized workloads such as search crawl, search query, and excel calculation services as these services tend to require more processing power. For complete guidance and list of services that make good candidates for each of the servers. click here. SQL ServerSQL Server requires special attention as that is where all the databases reside, thus it is very IO intensive. Keeping default settings maybe fine in a test environment but in a production environment, tuning up your SQL server will give you more horse power. This requires allocating the required RAM, CPU, and IOPS based on your workload, changing few settings, staying within the supported boundaries, and continuously monitoring to proactively resolve any potential issues. Here are the links to learn more: Storage and SQL Server capacity planning and configuration Best practices for SQL Server in a SharePoint Server farm SharePoint Lifecycle ManagementI recommend a complete SharePoint ALM environment which consist of a separate development, testing/integration, staging, and production farms. Following is brief description of each of the environments: Development: Used for development, integration and customization of web-based solutions. This environment consist of a developer virtual machine installed with SharePoint Designer, Visual Studio Team System, SharePoint, and SQL Server. You can easily reset your virtual machine to previous system snapshots as needed. Test/Integration: Used for testing and quality check purposes. This is where different development and testing teams come together to perform integration testing. Staging: Used for UAT (user acceptance testing) before deploying the solution to the production environment. This should be build same as the production environment as this environment is also used for workload testing purposes which ensures that the production environment is capable of handling additional traffic as more solutions and workload is added to the production environment. Also ensure that this environment is at the same patch level as the production and in sync with the production database which can be accomplished by copying production data regularly. Production: Hosts the end-user facing environment.
To learn more about SharePoint ALM, click here. Service Accounts PlanningAt a minimum, you should plan on having the following service accounts for your farm deployment. depending on your requirements, you can combine some of the services to run under the same service account. Create these account as the domain accounts.
Create the following groups in AD to mange and maintain the farm:
To learn more, click on the following links: Plan for administrative and service accounts Plan site permissions overview Authentication PlanningClassic mode authentication in SharePoint 2013 has been deprecated so by default the web application is created with Claims based authentication. Claims based authentication allows you to connect with your partner, vendors and cloud based computing services more easily and securely and is supported by many third-party authentication providers. Just simply create the Web Application as you normally would. Claims based authentication doesn’t require additional infrastructure setup unless you need to connect with an entity outside of your organization which will then require federation system such as ADFS. NTLM and the Kerberos protocol (excerpt from TechNet) Both NTLM and the Kerberos protocols are Integrated Windows authentication methods, which let users seamlessly authenticate without prompts for credentials. NTLM is the simplest form of Windows authentication to implement and typically requires no additional configuration of authentication infrastructure. Simply select this option when you create or configure the web application. Kerberos provides faster authentication. It is more secure and provides advance encryption. It requires SPNs to be setup in active directory for web applications and delegation for some of the service applications. Click here to learn more about Authentication planning. Site Publishing and DNSFor each of your site URLs, you will need setup a load balancing record with its public IP and map it to its internal IP. Depending on your load balancer, it can also be your web proxy which hides the internal servers from the internet. You will also want to create short URLs for your sites in your DNS such as //teams, and //intranet that users can easily remember to quickly browse to those sites. Firewall, Reverse Proxy, and ExtranetIf you are planning on exposing your content for remote employee access, and collaborating and sharing with partners and vendors, you will need to create your Web Applications using SSL, port 443, that way the traffic from both the external and internal access is encrypted. To provide excess to external users, you will need to terminate traffic at the revers proxy which protects your web servers from direct access. You can either setup the HTTPS to HTTP bridging or HTTPS to HTTPS bridging from your proxy to your web servers. You will need to obtain the SSL certificate from a certificate authority (CA) which you will need to install on your web servers. To learn more, click here. You can securely publish SharePoint through a product such as Forefront UAG which provides the following benefits:
To learn more about publishing and extranet, click here. Here is a link to a design sample. |
