Planning Redundancy and Scaling the SharePoint Environment
- Understanding Scalability for SharePoint
- Scaling Logical SharePoint Components
- Utilizing and Understanding Clustering for SharePoint
- Choosing the Right Clustering Technology for SharePoint
- Scaling SQL Server with High Availability Alternatives
- Choosing the Appropriate SQL Server High Availability Alternative
- Scaling Across a SharePoint Farm
- Justifying and Deploying Business Portals
- Addressing Common Business Issues with SharePoint Features
- Deploying a Team Collaboration Solution with SharePoint
- Deploying a Corporate Intranet Solution with SharePoint
- Deploying a Customer Extranet Solution with SharePoint
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
- Understanding Scalability for SharePoint
- Scaling Logical SharePoint Components
- Utilizing and Understanding Clustering for SharePoint
- Choosing the Right Clustering Technology for SharePoint
- Understanding Microsoft Cluster Service Clustering for SharePoint's SQL Database
- Scaling SQL Server with High Availability Alternatives
- Choosing the Appropriate SQL Server High Availability Alternative
- Scaling Across a SharePoint Farm
- Justifying and Deploying Business Portals
- Addressing Common Business Issues with SharePoint Features
- Deploying a Team Collaboration Solution with SharePoint
- Deploying a Corporate Intranet Solution with SharePoint
- Deploying a Customer Extranet Solution with SharePoint
- Best Practices
Any enterprise platform needs to be able to adjust, grow, and scale out to fit the needs of a changing organization. SharePoint is no exception to this rule, and the creators focused on the ability to scale certain components within SharePoint to be able to adjust to the unique conditions that exist in various environments. For small organizations in need of simply document management and team sharing, Windows SharePoint Services (WSS) offers a rich set of easily deployed capabilities. For larger or growing organizations, the full Microsoft Office SharePoint Server product allows for the centralization of information and the distribution of knowledge.
This chapter focuses on techniques and information necessary to scale a SharePoint implementation to organizations of varying sizes. Specific components that can be scaled are described and contrasted. High-redundancy options such as clustering and Network Load Balancing for SharePoint and SharePoint's SQL Databases are outlined. In addition, examples of scalability in organizations of different sizes are presented.
Understanding Scalability for SharePoint
The first step in scaling a SharePoint environment is to understand the level of usage it will receive, both presently and in the future. After the level of usage is determined, understanding which specific components can be extended is vital to structuring the system to match the desired user load. The key is to match SharePoint functionality to the specific identified need.
Mapping SharePoint Functionality to Business Needs
When deploying SharePoint, the primary concern in regards to scalability is how many users will utilize the system. For departmental collaboration, the numbers may be small. For large, publicly accessible portals, on the other hand, the numbers could scale up quickly. Scaling a SharePoint implementation based on the number of users is simplistic but can be used as a starting point. In addition to total number of users, the following factors should be identified to more fully understand the load placed on a SharePoint server:
- Number of users
- Pages per user per work day
- Length of work day (hours)
- Type of work performed and level of Office integration
- Size of document repositories
Collecting this information and understanding who will be accessing a SharePoint environment is the first step toward properly scaling the environment.
Planning for Capacity with SharePoint
When designing a SharePoint environment, it is always best to start the design simply and then expand on that design as needs arise. With SharePoint, this means that a single server should be planned and other servers added as new constraints are identified. A single server should not exceed several general limits in SharePoint, and those limits should be understood. These limits are as follows:
- Number of SharePoint users fewer than 2,000—The number of specifically defined users in a SharePoint site should not exceed 2,000, or the risk of performance degradation arises. If more users are needed, Active Directory group membership can be used to scale the number of users to the tens of thousands.
- Site collections of fewer than 50,000—Each site collection should hold no more than 50,000 users for optimal performance.
- Subsites to a website fewer than 2,000—More than 2,000 subsites of any one site slows server performance.
- Documents in a single folder of a document library fewer than 10,000—Performance degrades if more than 10,000 documents are stored in a single folder. Using multiple folders, however, increases this limit to almost two million documents.
- Items in a view fewer than 2,000—Any more than this slows access.
- Fewer than 100 web parts per page—Loading more than 100 web parts slows down the users' ability to view a page.
- Individual document size less than 50MB—The bigger a document grows, the greater strain that document has on an environment. The default "hard limit" in SharePoint is 50MB; any larger documents would seriously slow down the server. The maximum document size is 2GB.
Understanding these limits is an important part of scaling the environment. If, after designing and implementing a SharePoint environment, any of these limits is reached, SharePoint should be scaled to match.
Gauging Content Growth
In addition to the amount of data that initially is loaded into SharePoint, an understanding of how fast that content will grow is critical in properly scaling an environment. Running out of storage space a year into a SharePoint deployment is not an ideal situation. It is important to understand how quickly content can grow and how to control this inevitable growth.
Proper use of site quotas in SharePoint is an effective way to maintain control over the size that a SharePoint database can grow to. Implementing site quotas as they are created is a recommended best-practice approach and should be considered in most situations. It is easy to bloat SharePoint with unnecessary data, and site quotas help local site administrators to make judicious use of their available space.
SharePoint's SQL database can grow in size dramatically, depending on how heavily it is used and what type of content is included in it. Table 3.1 illustrates the effect that various data sources can have on a SQL database. Of particular note is the search and indexed content, which can grow large in tandem with the existing content.
Table 3.1. Effect of Various Components on SQL Server
|
Storage Type |
Size |
|
Database overhead |
12MB |
|
WSS site overhead |
4MB |
|
Document metadata (10 properties) |
12KB |
|
Search content |
Up to 25% of content size |
|
Indexed content |
Up to 50% of content size |
|
Transaction log |
2–4% of content size on average after initial content upload |
After SharePoint is implemented, it is important to monitor the system to ensure that it is not growing too fast for its own good. In addition to some of the default alerts and tools, a Management Pack for Microsoft Operations Manager (MOM) has been specifically designed to collect information about SharePoint, including the ability to monitor growth of specific components.