Best practices for operational excellence (SharePoint Server 2010) Published: May 12, 2011 Microsoft SharePoint Server 2010 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To achieve this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing, and patching. This article is one of a series of best practices articles for SharePoint Server 2010. 1. Use lots of memory, and fast network adapters To get the performance you want from an environment, make sure that you use lots of memory on the Web and application servers. Network speed is also important for performance of the environment. Take the following actions to make network traffic move quickly: Use gigabit network adapters for all server roles. For front-end Web servers and application servers, use dual network adapters in production environments. Use one network adapter for users and one for Microsoft SQL Servercommunication. Use private network adapters for inter-server communications for tasks such as management and backups so that this traffic does not affect the overall farm performance. Under heavy load, consider using virtual local area networks (VLANs) to reduce network traffic. For more information, see Hardware and software requirements (SharePoint Server 2010) and Performance and capacity management (SharePoint Server 2010). 2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers No front-end Web server or application server should have more than one millisecond (ms) of latency between it and the database server. In practice, this generally means that you should keep all the servers in a farm in the same data center. All servers in a farm must be in the same time zone. For more information, see Global solutions for SharePoint 2010 Products (model). 3. Consider performance and availability when you configure Web servers and application servers The way that you configure Web servers and application servers can have a big effect on throughput and availability. Follow the following recommendations for best results: Separate system components into logical drives and use RAID for redundancy. Components on drive Recommended RAID level
Windows and program files drive RAID 1 Operating system swap drive and temp directory RAID 1 Log files RAID 1 Boot disk for imaging and Windows Desktop Search (optional) RAID 1 Use at least four physical disks and use separate disks to keep the log files and swap drive separate from the Windows and program files drive. In most production environments, we recommend that you allocate at least 200 GB of disk space for the operating system and temporary files and 150 GB of disk space for logs. Be sure to test the Web server capacity and provide sufficient servers for the number of users and requests that are in the farm. For high availability, make sure that you allocate an additional server so that you can pull one server out of a network load-balancing server farm and recycle it without affecting service availability. For more information, see the following resources: Planning for server farms (SharePoint Server 2010) Plan for availability (SharePoint Server 2010) Capacity management and sizing overview for SharePoint Server 2010 Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) Enterprise intranet publishing environment technical case study (SharePoint Server 2010) 4. Consider performance and availability when you configure database servers As is also the case with Web servers and application servers, the configuration for database servers affects how well SharePoint Server 2010 performs. Certain databases require specific co-location with or separation from other databases. For more information, see Data scale in the Capacity management and sizing overview for SharePoint Server 2010 article and Storage and SQL Server capacity planning and configuration (SharePoint Server 2010). The databases listed in the following table should be kept separate from other databases. Database name Size Read/write optimization Co-location TempDB Medium Must be on a separate spindle from all other databases. Secure Store Small Host on a separate database instance. Limit access to one administrator. Search Crawl Extra large Optimize for read This is a large-scale database. Host on a separate server from the Search Property database.
Search Property Large to extra large Optimize for write This is a large-scale database. Host on its own server. Usage Extra large Optimize for write Must be on a separate spindle. Note: The usage database can be on a separate server, and does not need performance to be as high as other databases. The speed of the usage database does not affect the performance of the site. The databases in the following table must be stored in the same location as other databases. Database name Size Co-location Configuration Central Admin content SQL Server ReportServer ReportServerTempDB Small Small Varies Must be located together Must be on the same database server More information about database sizing and read/write mix for specific databases is available in the Databases That Support SharePoint 2010 Products model(http://go.microsoft.com/fwlink/?linkid=187970). 5. Keep it clean: Maintain databases in a healthy state A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests. Use the recommendations in the following list to keep database servers performing optimally. Pre-grow all databases and logs if you can. Be sure to monitor the sizes so that you do not run out of disk space. Do not overload database servers by using too many databases or data. Use the following guidelines: When you use SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server. Limit content databases to 200 GB. Defragment and rebuild indices daily, if you can absorb the downtime required to rebuild. Monitor the database server to make sure that it is responding correctly and is not overloaded. Key performance counters to monitor include the following: Network Wait Queue: at 0 or 1 for good performance Average Disk Queue Length (latency): less than 5 ms Memory used: less than 70 percent Free disk space: more than 25 percent Buffer cache hit ratio: 90 percent or better
For more information, see the following resources: SharePoint Diagnostic Studio 2010 (SPDiag 3.0) (SharePoint Server 2010) Good List of Performance Counters (http://go.microsoft.com/fwlink/?linkid=123925) (Although this link points to content for Microsoft Office SharePoint Server 2007, the guidance it contains is still valid for SharePoint Server 2010.) 6. Keep servers current by using the latest updates It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, make sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure to deploy the updates, including the following: Turn on Windows Update to download updates automatically, but not install automatically. Schedule time to install updates at off-peak hours. For high availability, rotate servers out of service one at a time during the update process. Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Microsoft SharePoint Foundation 2010 and SharePoint Server 2010, and SQL Server. For more information, see the Updates for SharePoint 2010 Products Resource Center. 7. Use different accounts for different actions Use appropriate accounts for the Web applications and services. All accounts should be domain accounts. (Reminder: Do not use Network Service.) For best results, use separate accounts for the following: Web applications: Use different accounts based on your security requirements. Search account: Use one account for the farm. Excel Services account: Use one account for external connections. For more information, see Account permissions and security settings (SharePoint Server 2010). There are many more accounts that are used by SharePoint Server 2010, such as SQL Server services accounts, the Central Administration application pool identity, the SharePoint Foundation Timer service account, the default content access account, the single sign-on account, and the profile import account. Be sure to follow recommended procedures to keep their passwords current and ensure that the services keep working. For more information, see Change passwords used for administration accounts (SharePoint Server 2010). 8. Follow recommendations for backing up and restoring data In general, it is best to use a local disk, not a network drive, for backups, and then copy the data later. Use compression when you can, but when you use compression with backups, be mindful not to overwhelm SQL Server. For example, SQL LightSpeed compresses during backup, which can disrupt SQL Server performance. For large databases, rely on incremental backups such as those available with System Center Data Protection Manager (DPM) 2010. Do not rely on full backups as your primary mechanism. They are too large to restore quickly.
For more information, see Backup and recovery best practices (SharePoint Server 2010). 9. Be sure that you back up and truncate the log files Do not only back up the data. Back up the log files, too. The usage logs, IIS logs, transaction logs, and SMTP e- mail logs all must be backed up if you want to be able to fully recover your environment. For transaction logs, you should back up and truncate the log file every five minutes. However, never shrink the transaction log because you may experience performance issues while the log re-grows. For more information, see Back up or archive logs (SharePoint Server 2010) and How to stop the transaction log of a SQL Server database from growing unexpectedly (http://go.microsoft.com/fwlink/?linkid=111458). 10. Restore data: Test backups and have a standby environment available for service continuity Routinely test backups and validate their consistency. Do not assume that the backup will work when you want it to. Make sure that it will. Practice recovery to learn what else you must do to bring back the whole environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. Keep databases small to speed recovery. For more information, see Procedural best practices. If you are using DPM 2010 for backup and recovery, make sure that you plan for backup and recovery of service applications separately. DPM 2010 does not back up Search or other service applications.