Anyone who has ever deployed SharePoint 2010 understands that a lot of planning needs to go into the process. Even...
so, unforeseen issues can arise during deployment. More often, such issues do not become apparent until long after the deployment process has been completed and the SharePoint collaboration platform is being used across an enterprise.
These latent concerns, which are annoying at best and can be downright problematic at times, catch many people off guard because using the SharePoint 2010 setup wizard is relatively painless. If you’ve done even a modest amount of planning, you’re unlikely to encounter a deployment issue so severe that it directly impacts the setup process. Instead, most of the issues that people experience are tied to migrations from previous versions of SharePoint or to resource management tasks. This article will focus on how to avoid some of the challenges and pitfalls common to SharePoint 2010 deployments that can affect resource management on an ongoing basis.
When preparing to deploy SharePoint 2010, it is important to consider the hardware on which SharePoint will run. It’s easy to assume that if a server was previously able to run SharePoint 2007, then it must be adequate for running SharePoint 2010. However, SharePoint 2010 is more demanding than SharePoint 2007, requiring more memory and greater processing power. For example, the minimum memory required for a SharePoint 2007 application server was 2 GB, and Microsoft recommended that the server have at least 4 GB. In contrast, the minimum memory for a SharePoint 2010 application server has doubled to 4 GB, with 8 GB recommended.
From a processing standpoint, the minimum requirement for a SharePoint 2007 application or Web server was a 2.5 GHz CPU, with Microsoft recommending a dual-core processor. The minimum clock speed hasn’t changed for SharePoint 2010, but Microsoft now requires a quad-core CPU for both types of servers.
The chart below illustrates how SharePoint’s requirements have changed:
|SharePoint 2007 Web Server||SharePoint 2007 App Server||SharePoint 2010 Web Server||SharePoint 2010 App Server|
|Minimum memory||2 GB||2 GB||4 GB||4 GB|
|Recommended memory||2 GB+||4 GB||8 GB||8 GB|
|Minimum CPU||2.5 GHz CPU||2.5 GHz CPU||Quad-core 2.5 GHz||Quad-core 2.5 GHz|
|Recommended CPU||3.0 GHz dual-core CPU||2.5 GHz+ dual-core CPU||No longer specified||No longer specified|
SharePoint 2010 will run within a virtualized data center, but the hardware requirements remain the same regardless of whether the servers are running on physical or virtual hardware. If SharePoint servers are to be virtualized, avoid using memory over commitment (which allows other VMs to “steal” unused memory) or thin provisioning (which allocates physical disk space to a VM on demand rather than reserving the space specifically for the VM ahead of time) for storage. Both will negatively impact SharePoint performance. Memory over commitment is a virtualization technology that allows at the moment.
The art of server selection
In all but the smallest environments, SharePoint is designed to be deployed as a distributed application that spans multiple servers. Choosing the number of servers required for a successful SharePoint 2010 deployment is something of an art form. It’s necessary to have a sufficient number of SharePoint servers to provide redundancy and load balancing without going overboard. At the same time, it is wise to limit the overall number of SharePoint servers because the bigger the SharePoint farm, the more it costs. Not only do hardware and software licensing costs increase in relation to the number of servers, but so do support costs.
Medium-sized and large SharePoint 2010 deployments should always be constructed as a three-tier topology. The top tier should consist of a minimum of two Web servers (for the sake of redundancy and load balancing). Larger organizations should consider a minimum of four, with two handling inbound Web requests and the other two dedicated to administration and “crawling” or indexing SharePoint data.
The middle tier should consist of the application servers. In medium-sized organizations, two application servers will often be sufficient for handling the workload and providing redundancy. Larger organizations often require several additional application servers. For example, large enterprises usually have a pair of “crawl servers,” a pair of query servers, a group of servers for all of the other SharePoint services (plus the Central Administration site), and possibly some servers for running “sandboxed” code in connection with a new SharePoint 2010 feature that enables end users with the right system privileges to deploy applications on their own.
Finally, the bottom tier should contain a set of clustered SQL Server systems. The best thing an organization can do to make sure its SharePoint deployment runs well is to focus on the performance of SQL Server. In small organizations, a pair of clustered systems running the database may be sufficient. In larger organizations, it is often necessary to create three separate SQL Server clusters. One cluster would be used for the “search” databases that store content-indexing information. Another cluster would be used for content databases, while still another would be used for all other SharePoint databases.
While designing a database topology to meet your organization’s needs is critical, it would also make sense to “pre-grow” the individual databases. Many SharePoint administrators prefer the convenience of using SQL Server’s autogrow feature to automatically increase database file sizes when needed, but that can add processing time to transactions. Assessing your expected file-size requirements and setting limits that can accommodate future growth needs typically yields much better performance.
It also helps to carefully plan your SQL Server storage environment. SharePoint 2010 is very I/O-intensive, so the more I/O operations per second that SQL Server can deliver, the better SharePoint is going to perform. It would be wise to store SharePoint databases on a RAID 10 array: That offers the high performance of a striped set of data and the fault tolerance that comes with mirroring. It’s also worth considering using separate disks (or disk arrays) for each database. SQL Server will perform better if separate storage is used for each workload.
There are numerous things an organization can do to avoid server performance- and failure-related pitfalls as part of SharePoint 2010 deployments. The key during the preparation process is to remember that there is no substitute for thorough architectural planning.
ABOUT THE AUTHOR:
Brien M. Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Posey worked as CIO for a national chain of hospitals and health care facilities and as a network administrator for insurance companies and for the Department of Defense.