Microsoft SharePoint Server

The Planning and Design Series Approach

This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies.

Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics:

  • Defining the technical decision flow (flow chart) through the planning process.
  • Describing the decisions to be made and the commonly available options to consider in making the decisions.
  • Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
  • Framing the decision in terms of additional questions to the business to ensure a comprehensive understanding of the appropriate business landscape.

The guides in this series are intended to complement and augment the product documentation. It is assumed that the reader has a basic understanding of the technologies discussed in these guides. It is the intent of these guides to define business requirements, then align those business requirements to product capabilities, and design the appropriate infrastructure.

Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective Microsoft SharePoint® Server 2010 implementation.

Benefits for Business Stakeholders/Decision-makers:

  • Most cost-effective design solution for an implementation. Infrastructure Planning and Design (IPD) eliminates over-architecting and overspending by precisely matching the technology solution to the business needs.
  • Alignment between the business and IT from the beginning of the design process to the end.

Benefits for Infrastructure Stakeholders/Decision-makers:

  • Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
  • Business validation questions to ensure the solution meets the requirements of both business and infrastructure stakeholders.
  • High integrity design criteria that includes product limitations.
  • Fault-tolerant infrastructure, where necessary.
  • Proportionate system and network availability to meet business requirements.
  • Infrastructure that is sized appropriately to meet business requirements.

Benefits for Consultants or Partners:

  • Rapid readiness for consulting engagements.
  • Planning and design template to standardize design and peer reviews.
  • A "leave-behind" for pre- and post-sales visits to customer sites.
  • General classroom instruction/preparation.

Benefits for the Entire Organization:

Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.

Introduction to the Microsoft SharePoint Server 2010 Guide

SharePoint Server 2010 is an integrated platform that allows users to share information effectively. It facilitates collaboration, provides content management, and can assist the organization in implementing business processes.

This guide leads the reader through the design process to create a SharePoint Server 2010 infrastructure design that is appropriately placed, sized, and designed to deliver the stated business benefits while also considering the performance, capacity, and fault tolerance of the system. It addresses the scenarios most likely to be encountered by someone designing a SharePoint Server 2010 infrastructure. Customers with specific questions should consider having their architecture reviewed by Microsoft Customer Service and Support prior to implementation to ensure the supportability of a particular design.

When used in conjunction with product documentation, this guide helps organizations confidently plan a SharePoint Server 2010 implementation. Appendix A: "Job Aids" includes sample job aids for recording the decisions made during the design process.

Assumptions

To limit the scope of material in this guide, the following assumptions have been made:

  • The decision to implement SharePoint Server 2010 has already been made.
  • The reader is familiar with the SharePoint Server 2010 product technologies. This guide does not attempt to educate the reader about the features and capabilities of SharePoint Server 2010, because the product documentation covers that information.
  • Microsoft Forefront® Unified Access Gateway (Forefront UAG) provides secure Web publishing of applications, using SSL. Forefront UAG provides access to internal resources for remote employees and partners. The design of remote access is outside the scope of this guide. See the Infrastructure Planning and Design Guide for Microsoft Forefront Unified Access Gateway at http://go.microsoft.com/fwlink/?LinkId=169356.
  • A functional Active Directory® Domain Services (AD DS) infrastructure that meets the requirements of SharePoint Server 2010 is either in place or planning for it has been completed. The design of AD DS is covered in the Infrastructure Planning and Design Guide for Active Directory Domain Services at http://go.microsoft.com/fwlink/?LinkId=157704.

SharePoint Server 2010 Design Process

The goal of this guide is to assist the reader through the process of planning a SharePoint Server 2010 infrastructure by addressing the following:

  • Step 1: Identify the Requirements
  • Step 2: Apply the IT Policies
  • Step 3: Define the High-Level Architecture
  • Step 4: Design the Web Server Infrastructure
  • Step 5: Design the Application Server Infrastructure
  • Step 6: Design the SQL Server® Infrastructure
  • Step 7: Identify the Optimization Opportunities

Figure 1 provides a graphical overview of these steps.

Figure 1. The SharePoint Server 2010 infrastructure decision flow

Figure 2 is a graphical representation of one SharePoint Server 2010 implementation. Note that the figure does not provide a comprehensive view of all possible options; rather, it is a single representation that shows the architectural items that must be considered for each SharePoint Server 2010 design.

Figure 2. Example SharePoint Server 2010 architecture

Step 1: Identify the Requirements

A well-designed SharePoint Server 2010 implementation starts with defining the business requirements and then applying all appropriate IT policies to those business requirements to create the overall system requirements. This list of requirements is then used in subsequent steps to guide the design of components and/or functions, their placement, capacity planning, performance needs, and fault tolerance. This step identifies and collects the business requirements for each website in scope.

Task 1: Determine the Business Requirements

The business requirements in this guide are determined by identifying the SharePoint Server 2010 websites that will be created, where geographically and by whom they will be accessed, and other characteristics about the functionality the business needs the websites to be capable of providing.

For every website that the organization will host in this SharePoint Server 2010 project, ask the business representative the following questions and record the answers in Table A-1 in Appendix A.

  • What is the name of the website? Identify the SharePoint Server 2010 website name. This information is used to uniquely identify one website from another during the design process.
  • Which physical locations have users who will require access to the website? This information will inform the placement of SharePoint Server 2010 servers in Step 3.
  • Does the website require operational autonomy in any of the locations in which it will be used? Must the website be accessed independently of the availability of the wide area network (WAN)? For example, if a website hosts a manufacturing process at a factory that is critical to factory production, this website must be available at the factory even if the WAN is not available; otherwise, production will be halted.
  • How many users will access the website from each physical location mentioned previously? This information will inform the placement of SharePoint Server 2010 servers in Step 3.
  • Will the website require high availability? Are unplanned service outages acceptable, or does the business require the website to be continuously available? High availability adds cost and complexity to the design.
  • Will the website require isolation? Is there a requirement that mandates the website be hidden from the general population or that prevents the website from sharing its data or business logic with other SharePoint Server 2010 websites in the organization, such as sensitive data collected during corporate merger or acquisition planning? Do governance policies require that all data on the website be kept separate from other websites? If either of these is true, then record a "yes" in Table A-1 in Appendix A.

Repeat this task for every website being designed.

Task 2: Determine the Functionality Requirements

Now that all of the websites were defined in Task 1, the next task is to identify what types of functionality each website requires. For each website identified in Task 1, determine the specific SharePoint Server 2010 functionality required by interviewing the business representative and recording the answers in Table A-2 in Appendix A. Ask the questions found in the next three sections.

User Functionality

The following questions are about the functionality exposed directly to users.

Does the website need to:

  • Centrally manage Microsoft InfoPath® forms that will be available for editing online in a web browser?
  • Provide web-based project scheduling functionality?
  • Interact with Microsoft Access® 2010 databases in a web browser?
  • Allow users to edit worksheets without having Microsoft Office installed on each client computer?
  • Allow users to edit presentations without having Microsoft Office installed on each client computer?
  • Allow users to edit documents without having Microsoft Office installed on each client computer?
  • Allow users to edit diagrams without having Microsoft Visio® installed on each client computer?
  • Allow users to edit Microsoft OneNote® notebooks without having Microsoft Office installed on each client computer?
  • Allow users to access shared Microsoft PowerPivot for Excel® 2010 workbooks that are stored in SharePoint Server 2010?
  • Provide a "My Sites" social networking platform for users to share personal information?

Developer Functionality

The following questions are about functionality that the software developers require to produce the desired website.

Does the website need to:

  • Access line-of-business (LOB) system data?
  • Use managed taxonomy hierarchies, keywords, and a social tagging infrastructure?
  • Use custom dashboards, scorecards, key performance indicators (KPIs), or reports?
  • Collect, report, and analyze the use and effectiveness of the SharePoint Server 2010 deployment?
  • Automatically convert documents between formats that Microsoft Word recognizes—for example, saving a Word document as a PDF?

Administrative Functionality

This last set of questions focuses on functionality that the administrative staff who will manage the SharePoint Server 2010 environment need.

Does the website need to:

  • Allow users to search documents stored in SharePoint Server 2010?
  • Provide enhanced search services such as contextual or linguistic search?
  • Allow users to use data from external sources without having to log on to those external sources?
  • Allow the temporary storage of user data (session state)?
  • Provide system health reports, web analysis reports, or administrative reports?
  • Have an end-to-end secure/encrypted environment?

Step Summary

In this step, the SharePoint Server 2010 business requirements were identified. The information gathered in this step will be used in Step 3 to define the high-level architecture for SharePoint Server 2010 and to design the individual server roles in Steps 4-6.

Step 2: Apply the IT Policies

In this step, the IT policies applicable to the SharePoint Server 2010 websites identified in Step 1 are collected. This policy information, together with the business requirements previously collected, should be applied to form the overall system requirements.

Task 1: Determine the IT Policy Requirements

In Step 1, the business representative was interviewed for the organization's business requirements. In this task, the IT policy representative, such as a systems architect, should be interviewed or written policies reviewed to ensure that the SharePoint Server 2010 design is aligned and compliant with current policy.

For each website identified in Step 1, answer the following questions about system implementation information and record the answers to the following questions inTable A-3 in Appendix A.

For this website, are there any IT policies that:

  • Specify where servers must be located? This answer will affect the server placement decisions in Step 3. If the answer is yes, make a note of how this policy affects this website.
  • Affect where data can be stored? For example, data may be required to stay within the organization's country, facility, or other boundaries. If the answer is yes, make a note of how this policy affects this website.
  • Require the use of an existing enterprise database or web server infrastructure? This answer will affect the SharePoint Server 2010 application placement decisions in Step 3. If the answer is yes, make a note of how this policy affects this website.
  • Add to the availability requirements identified in Step 1? If the answer is yes, then for each website that will require additional availability requirements, update the availability item in Table A-1 in Appendix A.

Step Summary

The business requirements and technical policies have now been collected. When combined, these two information collections represent the overall system requirements.

Step 3: Define the High-Level Architecture

The SharePoint Server 2010 system requirements were collected in Steps 1 and 2. In this step, the requirements will be combined with SharePoint Server 2010 product design information to create a logical system design that describes the high-level architecture. Steps 4-6 will complete the process by applying the logical design to specific physical systems.

SharePoint Server 2010 is a client server application where client computers access information and services on SharePoint Server 2010 by HTTP—or optionally HTTP over Secure Sockets Layer (HTTPS)—connections made across the network. The clients and server can be anywhere on the network provided there is sufficient bandwidth, acceptably low network latency, and no routing or security obstacles to prevent the connection between client and server.

The SharePoint Server 2010 servers responsible for hosting a particular website are grouped into a collection called a farm. A farm contains all of the SharePoint Server 2010 web servers, SharePoint Server 2010 application servers, and SQL Server instances needed to host a particular collection of websites. It is a product requirement that all servers in a farm be able to communicate with less than 1 millisecond (ms) of network latency. Effectively, this means that the servers must all be in the same physical location. SharePoint Server 2010 does not use farm names, but names are used in this guide to differentiate one farm from another.

SharePoint Server 2010 farms can be specifically designed to support different workload scenarios (such as portals or Search). Each scenario has its own capacity and performance requirements; see "Design server farms and topologies (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/cc263157.aspx for help in understanding implications of different farm topologies and scenarios.

Task 1: Design the SharePoint Server 2010 Farms

This task designs the total number of farms needed to match the system requirements previously defined. Start with one farm and identify geographically where it will be placed—a location nearest the majority of the users in the scope of the project. This information will be used during the network review of connections from each location to this first farm location. Record this location in Table A-4 in Appendix A as well as a name for this farm.

Apply Network Constraints

For each physical user location identified in Step 1, review the network connection from that user location to the first farm location and answer the following questions:

  • Does this connection have sufficient bandwidth to service all of the user connections?
  • Does this connection have sufficient speed (low latency) to service all of the user connections?
  • Does this connection have sufficient reliability?

If the answer to any of these questions is no, then either the network must be upgraded or an additional farm needs to be placed at the user side of this connection. If the decision is made to add another farm, then record the user location in Table A-4 as well as a name for this new farm.

  • Does the user location require site autonomy? In the event of a WAN failure, must this location's SharePoint Server 2010 users still be able to access their websites?

If the answer is yes, place an additional farm at the user side of this connection. Record the user location in Table A-4 as well as a name for this new farm.

Note   Microsoft Forefront UAG provides secure web publishing of applications, using Secure Sockets Layer (SSL). Forefront UAG provides access to internal resources for remote employees and partners. The design of remote access is outside the scope of this guide.

Apply Isolation Requirements

For every SharePoint Server 2010 website identified in Step 1, review the website requirements and, if physical isolation was defined as a requirement in Step 1, either add a new isolated farm at the first farm location and associate only this website with the new farm or add new farms as appropriate based on the network constraints in each location where the websites' users exist. Record the new farm names and website mappings in Tables A-1 and A-4.

Map Website User Locations to Farms

Now that all of the initial SharePoint Server 2010 farms have been identified, individual websites not already connected with a farm (by isolation requirements) will be associated with each farm to start to give it context.

For every SharePoint Server 2010 website identified in Step 1, compare that site's user locations and map each website with one of the farm names previously defined so that every user population for the website is associated with a single farm name. Record the website-to-farm name mapping in Table A-1.

Repeat this process until every website and every user location for every website are associated with at least one SharePoint Server 2010 farm name while recording the answers in Table A-1.

Additional Considerations

All of the websites in the project have been distributed to farms across the environment. Below is a list of items that may need to be addressed based on other organizational requirements. Such work is outside of the scope of this guide.

  • Domain name uniqueness. At this point, it is possible that any given website could be logically associated with more than one SharePoint Server 2010 farm. If this is the case, then a unique website fully qualified domain name will be needed for each website so that each site has a globally unambiguous name in the organization's Domain Name System (DNS). This is necessary to ensure that users can connect to the proper website for their location.
  • Data consistency among farms. SharePoint Server 2010 does not replicate the data or configuration information from a given website in one farm to its corresponding website in other farms. A separate process is needed to accomplish this replication, if desired.
  • Encrypted client-to-server communications. Any website that requires an end-to-end secure/encrypted environment must have additional architectural components designed—for example, certificate servers that support HTTPS.
  • Active Directory Domain Services (AD DS). SharePoint Server 2010 requires AD DS for authenticating users and services in a farm. Ensure that both the SharePoint Server 2010 website and users who consume its resources are able to authenticate with the organization's AD DS infrastructure.
  • Extranet access. Making SharePoint websites available outside of the corporate network is outside the scope of this guide. See "Extranet topologies for SharePoint 2010 Products: Model" at http://technet.microsoft.com/en-us/library/cc263513.aspx for more information.

Step Summary

In this step, the SharePoint Server 2010 high-level architecture was defined based on the business requirements and IT policies identified in Steps 1 and 2. The number and location of SharePoint Server 2010 farms were determined, and the websites were placed within farms.

Additional Reading

  • Plan for availability (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc748824.aspx
  • Logical architectural components (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc263121.aspx
  • Global deployment of multiple farms (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/gg441257.aspx
  • Design server farms and topologies (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc263157.aspx

Step 4: Design the Web Server Infrastructure

This step and the steps that follow provide information about designing the server roles and servers needed in each farm defined in Step 3. This step specifically focuses on defining the web servers for each farm.

In SharePoint Server 2010, the web server role uses the functionality built into Internet Information Services (IIS) 7.5 or 7.0. For information about planning a complete IIS architecture, see the Infrastructure Planning and Design Guide for Internet Information Services 7.5 and 7.0 at http://go.microsoft.com/fwlink/?LinkId=157703.

Each SharePoint Server 2010 farm must contain at least one SharePoint Server 2010 web server and one SQL Server instance. Optionally, the farm may also contain SharePoint Server 2010 application services. These roles can be located on a single server or separated across many servers. SharePoint Server 2010 can be deployed in any of the following models:

  • 3 tier. Separate web server, application server, and SQL Server tiers of physical or virtual servers.
  • 2 tier. Web server and application server tiers are combined, and SQL Server is on a separate physical tier of servers.
  • 1 tier. Web server, application server, and SQL Server are all installed on the same servers.

Choosing which model to use is architecturally driven largely by capacity and performance needs. SQL Server uses a different fault-tolerance method than does the web server and application server, so a single-tier approach may not be appropriate if fault tolerance is required.

The tasks in this step need to be performed for each SharePoint Server 2010 farm identified in Step 3.

Task 1: Design the Web Servers

The initial base number of SharePoint Server 2010 web servers required for each farm is established by combining the total website capacity information for the farm, the total website performance requirements for the farm, and the fault-tolerance requirements for the farm.

Start with a single web server for the farm, and add servers based on the impacts of the following information. It may be necessary to repeat this process more than once to achieve the right balance of capacity and performance for a given hardware and/or virtual platform.

Determine Server Capacity Requirements

Capacity is defined in this guide as the amount of storage needed to hold all data that the server generates. SharePoint Server 2010 itself stores all of the content information in SQL Server. It is possible, however, that some custom applications running on SharePoint Server 2010 could choose to store data on the web server. Calculate the total amount of storage required for all web servers in the farm, and record the information in Table A-5. If this total local capacity amount exceeds the amount of storage of the web server footprint, add servers until the capacity limits of each server are within tolerance levels.

Determine Server Performance Requirements

System performance is defined as the amount of physical resources needed to meet business requirements (processor, memory, disk, and network) per server based on estimated peak user loads. The SharePoint Server 2010 product group has no specific guidance on individual website performance metrics; however, the group has identified processes on web servers that can be particularly hardware-intensive. These processes are listed in Table 1.

Table 1. Hardware-Intensive Service Applications for Web Servers

Hardware item

Hardware-intensive service applications

Processor (64-bit required)

  • Microsoft SharePoint Foundation 2010, when a large number of users will access the server
  • Workflow services
  • Search service

Memory

  • SharePoint Foundation 2010, when a large number of users will access the server
  • Workflow services
  • PerformancePoint Services in Microsoft SharePoint Server 2010
  • Search service

Disk subsystem

  • Search Index Query
  • User activity logging
  • Binary large object caching

Network subsystem

  • Large file transfers
  • Content indexing with the crawler feature

Table 2 lists the product group's recommended minimum hardware for small and large deployments. Even though small and large deployments are not defined, the product group does give a relative bracket or range for consideration.

Table 2. Minimum Hardware Recommendations

Hardware item

Minimum recommendation for small deployments

Minimum recommendation for large deployments

Processor (64-bit required)

4 cores

8 cores

Memory

8 gigabytes (GB)

16 GB

Disk subsystem (input/output per second [IOPS])

Not applicable

Not applicable

Network subsystem

1 gigabyte per second (GBps)

<1 ms latency

1 GBps

<1 ms latency

For more information about how to estimate SharePoint Server 2010 capacity and performance requirements, see "Performance and capacity test results and recommendations (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/ff608068.aspx.

Record the server hardware configuration in Table A-5 in Appendix A. Add SharePoint Server 2010 web servers to the farm design until the total performance and capacity requirements for all websites are accommodated.

As SharePoint Server 2010 web servers are added to the farm, it will be necessary to distribute SharePoint Server 2010 websites logically across the web servers. Each time a website is moved from one server to another, its capacity and performance information will move with it. Record in Table A-6 a name for each SharePoint Server 2010 web server (to distinguish one web server from another) and the name of every website it will contain.

Task 2: Apply the Fault-Tolerance Requirements

Fault tolerance through load balancing is the mechanism by which SharePoint Server 2010 web servers achieve high availability. For each web server identified in Task 1, review the list of websites on the server. If any of the websites on the server required high availability as identified in Step 1, add at least one more web server to the farm. This additional server will need to contain duplicate configurations (mirror image) of the first web server.

It is possible to optimize the number of fault-tolerant servers through additional manipulation of which websites are placed on the fault-tolerant servers rather than making an entire mirror image of the first server. However, the details of this work is beyond the scope of this guide.

If any fault-tolerant servers are added to the farm, either a hardware or software load balancer will need to be added to the environment to automatically redirect network traffic to the fault-tolerant (backup) server in the event of a failure on the primary web server. Record the fault-tolerance requirements in Table A-5 in Appendix A.

Step Summary

This step focused on the design of the SharePoint Server 2010 web server infrastructure. The design of web server instances, system capacity and performance, number of web servers required in each farm, fault-tolerance requirements, and virtualization were discussed.

Additional Reading

  • Infrastructure Planning and Design Guide for Internet Information Services 7.5 and 7.0: http://go.microsoft.com/fwlink/?LinkId=157703
  • SharePoint Server 2010 capacity management: Software boundaries and limits: http://technet.microsoft.com/en-us/library/cc262787.aspx
  • Capacity management and sizing overview for SharePoint Server 2010: http://technet.microsoft.com/en-us/library/ff758647.aspx
  • Performance and capacity technical case studies (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc261716.aspx
  • Capacity planning for SharePoint Server 2010: http://technet.microsoft.com/en-us/library/ff758645.aspx
  • Performance testing for SharePoint Server 2010: http://technet.microsoft.com/en-us/library/ff758659.aspx
  • Analyzing Microsoft SharePoint Products and Technologies Usage: http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm
  • Plan for caching and performance (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee424404.aspx

Step 5: Design the Application Server Infrastructure

This step specifically focuses on designing the application servers for each farm. The only difference between SharePoint Server 2010 web servers and SharePoint Server 2010 application servers is the information they are serving. In fact, SharePoint Server 2010 web servers can host SharePoint Server 2010 service applications, and SharePoint Server 2010 application servers can host SharePoint Server 2010 websites. The only distinction between the two roles is a logical one.

The application server tier is optional. Review each SharePoint Server 2010 farm identified in Step 3, and look at the requirements that were identified in Step 1, Task 2 of each website associated with the farm. If no service application requirements were identified for any farm, skip this step and proceed to Step 6.

Proceed through the following tasks for each farm that has one or more service application requirement.

Task 1: Design the Application Servers

Similar to a SharePoint Server 2010 web server, the base number of SharePoint Server 2010 application servers required for each farm is established by combining the total application server capacity information for the farm, the total application server performance requirements for the farm, and the fault-tolerance requirements for the farm.

Start with a single application server for the farm and add servers based on the impacts of the following information. One server can host as many service applications as the platform allows. It may be necessary to repeat this process more than once to achieve the right balance of capacity and performance for a given hardware or virtual platform.

Using the information collected from Step 1, Task 2 that was recorded in Table A-2, create a list of the unique service applications required in the farm. These are the service applications that must be accounted for in the design.

Determine Server Capacity Requirements

Capacity is defined as the amount of storage needed to hold all data the server generates. Service applications typically store a limited amount of data that is used during the processing of information stored in SharePoint Server 2010 databases for rendering to user clients (application state and session information).

The SharePoint Server 2010 product group has established the capacity recommendations shown in Table 3. Start with these recommendations, and monitor the server to determine when additional disk space will be needed.

Table 3. Application Server Capacity Recommendations

Item

Description

Recommendation

System partition

Operating system, program files, and temporary storage

Minimum of 80 GB; 200 GB recommended based on real-world tested scenarios

SharePoint Server 2010 log files

Unified Logging System logs and IIS logs

Minimum of 150 GB

For more information on SharePoint Server 2010 capacity planning, see "Capacity planning for SharePoint Server 2010" at http://technet.microsoft.com/en-us/library/ff758645.aspx and "Performance and capacity technical case studies (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/cc261716.aspx.

Calculate the total amount of storage required for all application servers in the farm using the list created at the beginning of this task. If this total local capacity amount exceeds the amount of storage of the application server, add servers until the capacity limits of each server are within tolerance levels. Record the server and capacity counts in Table A-7 in Appendix A.

Determine Server Performance Requirements

System performance is defined as the amount of physical resources needed to meet business requirements (processor, memory, disk, and network) per server based on estimated peak user loads. The SharePoint Server 2010 product group has no specific guidance on performance metrics; however, they have identified processes on application servers that can be particularly hardware-intensive. These processes are listed in Table 4.

Table 4. Hardware-Intensive Service Applications

Hardware item

Hardware-intensive service applications

Processor (64-bit required)

  • Microsoft Office web applications
  • SharePoint Search service
  • Access service
  • Visio services
  • PowerPivot Service
  • Business Connection Service

Memory

  • Excel Calculation services
  • SharePoint Search service
  • FAST Search service enabled

Disk subsystem

  • Search Index creation
  • User activity logging

Network subsystem

  • Large file transfers
  • Content indexing with the crawler feature

Table 5 lists the product group's recommended minimum hardware for small and large deployments. Even though small and large deployments are not defined, the product group does give a relative bracket or range for consideration.

Table 5. Minimum Hardware Requirements for Small and Large Deployments

Hardware item

Small deployment minimum recommendation

Large deployment minimum recommendation

Processor (64-bit required)

4 cores

8 cores

Memory

8 GB

16 GB

Disk subsystem (IOPS)

Not applicable

Not applicable

Network subsystem

1 GBps

<1 ms latency

1 GBps

<1 ms latency

As application servers are added to the farm, it will be necessary to distribute SharePoint Server 2010 service applications logically across application servers. Each time a service application is moved from one server to another, its capacity and performance information will move with it. Record the server hardware configuration in Table A-7 in Appendix A.

Add application servers to the farm design until the total performance and capacity requirements for all service applications from the list created at the beginning of this task are accommodated. Record in Table A-7 a name for each SharePoint Server 2010 application server (to distinguish one web server from another) and the name of every service application it will contain.

Task 2: Apply the Fault-Tolerance Requirements

Fault tolerance through the implementation of multiple servers is the mechanism by which SharePoint Server 2010 application servers achieve high availability. Review the list of websites on the farm. If a website requires high availability, so do all service applications the website uses to provide continuous operation. If any of the websites in the farm require high availability and a service application (identified in Step 1), add at least one more application server to the farm. This additional server will need to contain duplicate configurations (mirror image) of each service application that requires high availability. Record the fault-tolerance requirements in Table A-7 in Appendix A.

It is possible to optimize the number of fault-tolerance servers through additional manipulation of the service applications placed on the fault-tolerant servers rather than making an entire mirror image of the first server. However, the details of this work are beyond the scope of this guide.

Additional Considerations

Application servers and service applications have additional flexibility whose design is outside of the scope of this guide:

  • Isolation of service applications. It is possible to segregate service applications so that, for example, one instance of a Microsoft Excel service application is used by some websites and another instance of the Excel service application is used by others to isolate these functions for security or administrative purposes.
  • Cross-farm sharing of service applications. It is also possible for service applications in one farm to be used by websites in a different farm, assuming that they are within the 1-ms range that the product requires.
  • Server consolidation. After reviewing the capacity and performance information of the service applications for each farm, it may be possible to collapse the application server tier into the SharePoint Server 2010 web server tier if there is sufficient capacity, performance, and fault tolerance on the web servers to host the service applications, as well.

Step Summary

This step focused on the design of the SharePoint Server 2010 application server infrastructure.

Additional Reading

  • Plan for availability (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc748824.aspx
  • Services architecture planning (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc560988.aspx
  • Performance and capacity technical case studies (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc261716.aspx
  • Share service applications across farms (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ff621100.aspx
  • Plan for PerformancePoint Services (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee681486.aspx
  • Enterprise search planning (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc263400.aspx
  • Plan the Secure Store Service (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee806889.aspx
  • Manage the State Service (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee704548.aspx
  • Visio Services overview (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee663485.aspx
  • Microsoft Forefront Protection 2010 for SharePoint: http://technet.microsoft.com/en-us/library/cc482990.aspx
  • Monitoring overview (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee748636.aspx
  • Reporting and usage analysis overview (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/gg266383.aspx

Step 6: Design the SQL Server Infrastructure

This step focuses on the design of the SharePoint Server 2010 SQL Server infrastructure. In SharePoint Server 2010, databases are used to store all SharePoint Server 2010 configuration and administration data, user data, crawl state and histories, metadata, user profiles, and usage data (indices are stores on the file system). Microsoft SQL Server 2008 or SQL Server 2008 R2 is required for hosting the databases.

The Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=160982 may assist in the design of the SQL Server instances.

At a minimum, each SharePoint Server 2010 farm must have one SQL Server instance that can host all of the databases required in the farm. A single SQL Server installation can host multiple SQL Server instances if needed. More instances and servers can be added for isolation, performance, and scalability, and individual databases can be implemented on multiple servers to provide fault tolerance.

The number of databases required for each farm depends on the amount of user content to be stored as well as which service applications are used. In addition, SharePoint Server 2010 uses several databases that are required to manage the administration and configuration of the farm. This step must be performed at least once per farm.

For each farm, start with a single SQL Server instance located on a computer running SQL Server within the same location as the SharePoint Server 2010 farm to ensure the 1-ms response requirement. Use the information in the following sections to help define the size of the instance and whether additional SQL Server instances will be needed.

Task 1: Determine SQL Server Capacity and Performance Requirements

Determining the capacity and performance requirements for SQL Server for the farm is the focus of this task. SharePoint Server 2010 stores the majority of its data within SQL Server databases. This means that proper capacity and performance planning is critical to the long-term health of the SharePoint Server 2010 environment. Capacity is defined as the total amount of disk space required by the SQL Server instance. Performance is defined as the amount of throughput (expressed in IOPS) needed to meet business requirements at peak user load as well as the memory, processing, and network needed.

To determine how many servers are needed in each farm, the requirements for all of the databases in the farm must first be identified. SharePoint Server 2010 uses SQL Server databases at three different levels within a farm:

  • Farm-level databases. Used to hold the farm configuration information as well as administration and other functions. These databases exist once for the entire farm.
  • Content-level databases. Used to hold the user content of all the websites. These databases exist once for every farm and may optionally be split into multiple databases by deploying multiple site collections. Site collection design is outside of the scope of this guide.
  • Service application-level databases. Used to hold the information for individual SharePoint Server 2010 service applications. These databases differ based on the need for each service application being used in the farm. They exist once for each instance of a service application in the farm.

There is no prescriptive guidance from the product group on capacity and performance planning for the SQL Server instance design for a farm. There is, however, a limited amount of planning information available, which can be found in Appendix C, "SQL Server Database Information," along with a complete listing of all known SharePoint Server 2010 databases. Use this information as a reference when designing the SQL Server infrastructure.

Create a SQL Server instance design that supports the capacity and performance requirements for the farm by iterating through the farm, user content, and application service–level database requirements and summing the total amount of capacity and performance capabilities needed. If necessary, SQL Server databases required at the three different levels previously described can be distributed over several SQL Server instances to accommodate capacity and performance abilities of the hardware being considered. Record the database instance requirements in Table A-9 in Appendix A.

Task 2: Apply the Fault-Tolerance Requirements

SharePoint Server 2010 relies on SQL Server's fault-tolerance mechanisms to provide high availability for SharePoint Server 2010 databases. Review each SQL Server instance defined in the preceding task. If any SharePoint Server 2010 website associated with the SQL Server instance (because of its user content database or service application dependencies) requires high availability (identified and recorded in Step 1), this SQL Server instance and the SQL Server instance containing the farm-level databases must be configured to be fault tolerant to allow the website to meet its requirement for continuous availability.

SharePoint Server 2010 only supports two SQL Server database fault-tolerance mechanisms: SQL Server Failover Clustering and high-availability database mirroring. See Step 3, Task 4 of the Infrastructure Planning and Design Guide for SQL Server 2008 and SQL Server 2008 R2 for help with determining the right fault-tolerance mechanism. If SQL Server Failover Clustering is used to provide fault tolerance, a SQL Server cluster instance is required for each SQL Server instance containing databases that require fault tolerance. If SQL Server high-availability database mirroring is used to provide fault tolerance, a mirror is required for each individual SQL Server database that requires fault tolerance.

Record the fault-tolerance requirements in Table A-9 in Appendix A. Repeat this step for every farm.

Step Summary

This step focused on the design of the SharePoint Server 2010 SQL Server infrastructure.

Additional Reading

  • Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2: http://go.microsoft.com/fwlink/?LinkId=163302
  • Performance and capacity test results and recommendations (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ff608068.aspx
  • SharePoint Server 2010 capacity management: Software boundaries and limits: http://technet.microsoft.com/en-us/library/cc262787.aspx
  • Running SQL Server 2008 in a Hyper-V Environment—Best Practices and Performance Recommendations: http://go.microsoft.com/fwlink/?LinkID=134106

Step 7: Identify the Optimization Opportunities

This step focuses on the server optimization opportunities of the SharePoint Server 2010 infrastructure. The potential for consolidation of individual SharePoint Server 2010 server roles will be discussed, with considerations given to isolation, capacity, performance, and fault tolerance.

Steps 4-6 were used to design each of the different infrastructure parts of a SharePoint Server 2010 farm: the web servers, application servers, and SQL Server instances independent of one another. The final step in the design process is to review all three of these designs collectively to see whether the design within each farm can be optimized.

Figure 3 is a graphical representation of SharePoint Server 2010 server consolidation options.

Figure 3. Example SharePoint Server 2010 server consolidation options

Review each tier of applications, overlaying one over the next to determine whether some capabilities can be combined. For example, in a design with just a few websites, it may be feasible to combine the SharePoint Server 2010 web servers and application servers on a single set of servers, reducing the amount of hardware needed. The same could be true for a review of the application server and the SQL Server instances.

In this review, it is important to ensure that IT policies, system capacity, system performance, and system fault tolerance are all aligned before consolidating any platforms. Record any changes in the design in Table A-10 in Appendix A.

Step Summary

This step focused on the potential server optimization opportunities for SharePoint Server 2010 servers.

Conclusion

This guide focused on the critical design decisions, activities, and tasks required to enable a successful design of SharePoint Server 2010. It addressed the business requirements, IT policies, and service characteristics for completing a comprehensive review of the decision-making process. When used in conjunction with product documentation, this guide can help organizations confidently plan a SharePoint Server 2010 implementation.

Appendix A: Job Aids

This section provides job aid examples for recording data while planning the SharePoint Server 2010 infrastructure. For Steps 1 and 3, use Table A-1 to record the answers asked of the business to determine the SharePoint Server 2010 business requirements.

Table A-1. Business Requirements

Step and task

Requirement

Result

Step 1, Task 1

What is the name of the website?

 

Step 1, Task 1

Which physical locations have users who will require access to the website?

 

Step 1, Task 1

Does the website require operational autonomy in any of the locations in which it will be used?

 

Step 1, Task 1

How many users will access the website from each physical location?

 

Step 1, Task 1

Will the website require high availability?

 

Step 1, Task 1

Will the website require isolation for any of the following reasons?

  • Website visibility to the general population
  • Governance requirements
  • Operational autonomy
 

Step 3, Task 1

Within which farms must the website be deployed?

 

For Step 1, use Table A-2 to record the answers for mapping the service applications. Use this table once per website.

Table A-2. SharePoint Server 2010 Functionality to Service Application Mapping

Service applications for the website

Step and task

Requirement: Does the website need to

Result

Maps to

Step 1, Task 2

Centrally manage InfoPath forms that will be available for editing online in a web browser?

 

InfoPath Forms service

Step 1, Task 2

Provide web-based project scheduling functionality?

 

Microsoft Project Server 2010

Step 1, Task 2

Interact with Access 2010 databases in a web browser?

 

Access services

Step 1, Task 2

Allow users to edit worksheets without having Microsoft Office installed on each client computer?

 

Office Web Apps: Excel Calculation Services

Step 1, Task 2

Allow users to edit presentations without having Microsoft Office installed on each client computer?

 

Office Web Apps: PowerPoint® Service

Step 1, Task 2

Allow users to edit documents without having Microsoft Office installed on each client computer?

 

Office Web Apps:

Word Viewing Service

Step 1, Task 2

Allow users to edit diagrams without having Visio installed on each client computer?

 

Visio Services

Step 1, Task 2

Allow users to edit OneNote notebooks without having Microsoft Office installed on each client computer?

 

Office Web Apps: OneNote Web App

Step 1, Task 2

Allow users to access shared PowerPivot for Excel 2010 workbooks that are stored in SharePoint Server 2010?

 

PowerPivot System Service

Step 1, Task 2

Provide a "My Sites" social networking platform for users to share personal information?

 

User Profile Service

Step 1, Task 2

Access LOB system data?

 

Business Data Connectivity Service

Step 1, Task 2

Use managed taxonomy hierarchies, keywords, and a social tagging infrastructure?

 

Managed Metadata Service

Step 1, Task 2

Use custom dashboards, scorecards, KPIs, or reports?

 

PerformancePoint Services

Step 1, Task 2

Collect, report, and analyze the usage and effectiveness of the SharePoint Server 2010 deployment?

 

Usage and Health Data Collection Service

Step 1, Task 2

Automatically convert documents between formats that Word recognizes—for example, saving a Word document as a PDF?

 

Word Automation Services

Step 1, Task 2

Allow users to search documents stored in SharePoint Server 2010?

 

Search Service

Step 1, Task 2

Provide enhanced search services such as contextual or linguistic search?

 

FAST Search Service

Step 1, Task 2

Allow users to use data from external sources without having to log on to those external sources?

 

Secure Store Service

Step 1, Task 2

Allow the temporary storage of user data (session state)?

 

State Service

Step 1, Task 2

Provide system health reports, web analysis reports, or administrative reports?

 

Web Analytics

Step 1, Task 2

Have an end-to-end secure/encrypted environment?

 

No service application; requires a certificate infrastructure for HTTPS

For Step 2, use Table A-3 to record the answers asked of the technical decision-makers to determine the SharePoint Server 2010 IT policy requirements.

Table A-3. IT Policy Requirements

Step and task

Requirement

Result

Step 2, Task 1

Do any IT policies specify where servers can be located?

 

Step 2, Task 1

Do any IT policies affect where data can be stored?

 

Step 2, Task 1

Is the use of an existing enterprise database or web server infrastructure required?

 

Step 2, Task 1

Do any IT policies add to the availability requirements identified in Step 1?

 

For Step 3, use Table A-4 once per user location to record the answers asked of the technical decision-makers to determine the SharePoint Server 2010 high-level architectural requirements.

Table A-4. High-Level Architectural Requirements

User location

Step and task

Requirement

Result

Step 3, Task 1

SharePoint Server 2010 farm name

 

Step 3, Task 1

Websites deployed in the farm

 

For Step 4, use Table A-5 once per farm to record the web server infrastructure requirements.

Table A-5. Web Server Infrastructure Requirements

SharePoint Server 2010 farm

Step and task

Requirement

Result

Step 4, Task 1

Total amount of storage capacity required for all web servers in the farm

 

Step 4, Task 1

Processor

 

Step 4, Task 1

Memory

 

Step 4, Task 1

Disk IOPS

 

Step 4, Task 1

Network

 

Step 4, Task 1

Total number of web servers

 

Step 4, Task 2

Fault tolerance

 

For Step 4, use Table A-6 once per farm to record the web servers and websites.

Table A-6. Web Servers and Websites

SharePoint Server 2010 farm

Step and task

Web server name

Websites hosted

Step 4, Task 1

   
     
     
     
     

For Step 5, use Table A-7 to record the application server infrastructure requirements.

Table A-7. Application Server Infrastructure Requirements

SharePoint Server 2010 farm

Step and task

Requirement

Result

Step 5, Task 1

Total amount of storage capacity required for all application servers in the farm

 

Step 5, Task 1

Processor

 

Step 5, Task 1

Memory

 

Step 5, Task 1

Disk IOPS

 

Step 5, Task 1

Network

 

Step 5, Task 1

Total number of web servers

 

Step 5, Task 2

Fault tolerance

 

For Step 5, use Table A-8 once per farm to record the application servers and service applications.

Table A-8. Application Servers and Service Applications

SharePoint Server 2010 farm

Step and task

Application server name

Service applications hosted

Step 5, Task 1

   
     
     
     
     

For Step 6, use Table A-9 to record the database fault-tolerance requirements.

Table A-9. Database Server Requirements

Step and task

Database name

Fault-tolerance requirement

Step 6, Task 1 and 2

   

For Step 7, use Table A-10 to record the server consolidation options.

Table A-10. Server Consolidation Options

Design changes based on consolidation

 
 
 

Appendix B: List of Service Applications

Use Table B-1 as a guide for the service applications needed for the websites in the organization, along with their dependent databases, if required.

Table B-1. SharePoint Server 2010 Website and Database Mapping

Service application

Service application description

Databases

Default database name prefix

InfoPath Forms Services

Allows the deployment of organizational forms that enable users to interact with the forms in a web browser to standardize, customize, and validate data collection.

Uses State Service database (below)

Uses State Service database (below)

Project Server 2010

Hosts one or more Project Web Access instances; exposes scheduling functionality and other middle-tier calculations on Project data and exposes web services for interacting with Project 2010 data.

  • Draft
  • Published
  • Archive
  • Reporting

ProjectServer_Draft*

ProjectServer_Published*

ProjectServer_Archive_*

ProjectServer_Reporting

*Must be together in the same database instance

Access Services

Allows users to view, edit, and interact with Access 2010 databases in a web browser.

None

None

Office Web Apps: Excel Calculation Services

Allows users to view and interact with Excel files in a web browser.

None

None

Office Web Apps: PowerPoint Service

Allows users to view and interact with PowerPoint files in a web browser.

None

None

Office Web Apps: Word Viewing Service

Allows users to view and interact with Word documents in a web browser. (Documents created by using Office Web Apps are no different than documents created by using the corresponding desktop applications.)

None

None

Visio Services

Allows users to view and refresh published Visio 2010 drawings in a web browser.

None

None

Office Web Apps: OneNote Web App

Allows users to view and interact with OneNote documents in a web browser.

None

None

PowerPivot System Service

Integrates with Excel and SharePoint Server 2010 to provide an end-to-end solution for creating and sharing business intelligence via PowerPivot for Excel 2010 data stored in Excel workbooks.

Application

DefaultPowerPivotServiceApplicationDB

User Profile Service

Adds support for My Sites, profile pages, social tagging, and other social computing features.

  • Profile
  • Synchroni-zation
  • Social Tagging

User Profile Service Application_ProfileDB_

User Profile Service Application_SyncDB_

User Profile Service Application_SocialDB_

Business Data Connectivity Service

Gives access to LOB data systems.

Business Data Connectivity

Bdc_Service_DB_

Managed Metadata Service

Manages taxonomy hierarchies, keywords, and social tagging infrastructure and publishes content types across site collections.

Managed Metadata

Managed Metadata Service_

PerformancePoint Services

Provides flexible, easy-to-use tools for building dashboards, scorecards, reports, and KPIs that can be used to monitor and analyze business data.

Performance-Point

PerformancePoint Service Application_

Usage and Health Data Collection Service

Collects farm-wide usage and health data and provides the ability to view various usage and health reports.

Usage and Health Data Collection

WSS_UsageApplication

Word Automation Services

Performs automated bulk document conversions.

Word Automation Services

WordAutomationServices_

Search Service

Crawls content, produces index partitions, and serves search queries.

  • Search Administra-tion
  • Search Crawl
  • Search Property

Search_Service_Application_DB_

Search_Service_Application_CrawlStoreDB_

Search_Service_Application_PropertyStoreDB_

FAST Search Service

Provides enhanced enterprise search services, such as contextual search, thumbnail previews, advanced linguistics, and sub-second query response times through the FAST engine.

Administration

FASTSearchAdminDatabase

Secure Store Service

Provides single sign-on authentication to access multiple applications or services.

Secure Store

Secure_Store_Service_DB_

State Service

Provides temporary storage of user session data for SharePoint Server 2010 components; InfoPath Forms Services and Visio Services require the State Service.

State

StateService

Web Analytics

Provides the ability to collect, report, and analyze the use and effectiveness of SharePoint Server 2010 sites.

  • Web Analytics Staging
  • Web Analytics Reporting

WebAnalyticsServiceApplication_StagingDB_

WebAnalyticsServiceApplication_ReportingDB_

SharePoint Foundation 2010

The services that make up SharePoint Server 2010; these services provide the overall configuration, administration, and website environment to users and services in a SharePoint Server 2010 implementation and are installed with all versions of Microsoft SharePoint.

  • Configuration
  • Central Administra-tion
  • Content

SharePoint_Config

Central_AdministrationContent

WSS_Content

Microsoft SharePoint Foundation Subscription Settings Service

Provides multi-tenant functionality for service applications; tracks subscription IDs and settings for services that are deployed in partitioned mode.

Subscription Settings

SubscriptionSettings_

Appendix C: SQL Server Database Information

Calculations and product group guidance are given in this appendix where possible and are noted where none is available. Estimating the storage and IOPS required for individual databases will not provide precise results, because the results depend on predicting how much information users will store, modify, and delete over time. See "Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/cc298801.aspx for detailed information.

The product group has identified broad size ranges for databases that are used. The size ranges are broken down as follows:

  • Small (less than 1 GB)
  • Medium (less than 100 GB)
  • Large (less than 1 terabyte)
  • Extra-large (larger than 1 terabyte)

See "Database types and descriptions (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/cc678868.aspx for detailed information.

Farm-Level Databases

Calculate the capacity and performance requirements for the databases that exist to serve an entire farm, and record this information in Table A-6 in Appendix A.

  • SharePoint Foundation 2010 databases. SharePoint Server 2010 stores all of its operation data in two databases: Configuration and Central Administration.
    • Configuration database. Contains data about SharePoint Server 2010 databases, websites, site templates, service applications, and farm settings.
      • Capacity requirements. Small size; the recommended minimum size is 2 GB. Database size may increase with time, growing by approximately 40 MB for each 50,000 site collections. Transaction logs for the configuration database can grow large if many items are created between transaction log checkpoints.
      • Performance requirements. No guidance.
    • Central Administration database. Stores all site content, including site documents or files in document libraries, list data, and user names and rights.
      • Capacity requirements. Small size; the recommended minimum size is 1 GB.
      • Performance requirements. No guidance.
  • Business Data Connectivity database. Stores external content types and related objects.
    • Capacity requirements. Small size; significant growth is unlikely.
    • Performance requirements. No guidance.
  • Usage and Health Data Collection database. Stores health monitoring and usage data temporarily and can be used for reporting and diagnostics.
    • Capacity requirements. Extra-large size, depending on retention factors, items monitored, number of websites, and number of users. Note that this database can grow quickly. For example, in collaborative environments that use out-of-the-box settings, 1 million HTTP requests require 2 GB of storage.
    • Performance requirements. Use the larger of two calculations based on page hits or HTTP requests on the website accessing the database.
    • IOPS page hits = Estimated page hits per second x 115
    • IOPS requests = Number of HTTP requests per second x 5

Content-Level Databases

Calculate the capacity and performance requirements for the Content database, understanding that the calculation includes data from all websites in each site collection, and record this information in Table A-6 in Appendix A. Because all websites in a site collection share a single Content database, this must be performed for each site collection defined in the farm.

  • Content database. Stores all content for a site collection, including site documents or files in document libraries, list data, Web Part properties, audit logs, and sandboxed solutions in addition to user names and rights.
    • Capacity requirements. Size varies; the maximum supported size is 200 GB or 2,000 site collections. If the amount of space required exceeds these amounts, additional content databases must be implemented that distribute the data.

Note   Content databases up to 1 terabyte are supported only for large, single-site repositories and archives with non-collaborative I/O and usage patterns, such as Records Centers. See "SharePoint Server 2010 capacity management: Software boundaries and limits" at http://technet.microsoft.com/en-us/library/cc262787.aspx#ContentDB for more details.

For each content database, perform the following:

Database size = ((D × V) × S) + (10 KB × (L + (V × D)))

where:

D = Expected total number of documents that will be stored

V = Expected number of versions of individual documents; must be >0

10 KB = Metadata overhead constant

The value of 10 KB in the formula is a constant that roughly estimates the amount of metadata that SharePoint Server 2010 requires. If the system requires significant use of metadata, consider increasing this value.

S = Average size of the individual documents to be stored

Note that the average file size for My Site websites, media repositories, and different department portals can vary significantly.

L = Expected number of lists in the website

Consider using an estimate of three times the number of documents (L = 3 × D); this value may vary depending on how the organization expects to use its sites.

For example, assume that:

D = 200,000 documents (10,000 users with 20 documents per user)

V = 4 versions of each document

S = 250 KB per document

L = 600,000 lists

Therefore:

Database size = ((D × V) × S) + (10 KB × (L + (V × D)))

Database size = ((200,000 × 4) × 250 KB) + (10 KB × (600,000 + (4 × 200,000)))

Database size = 204 GB

  • Performance requirements. Vary significantly depending on usage. For examples by the product group, see "Performance and capacity test results and recommendations (SharePoint Server 2010)" at http://technet.microsoft.com/en-us/library/ff608068.aspx.

Service Application-Level Databases

Calculate the capacity and performance requirements for the databases that will be implemented on a per-website basis, and record this information in Table A-6 in Appendix A.

  • FAST Search Administration database. Stores search setting groups, keywords, synonyms, document and site promotions and demotions, term entity extractor inclusions and exclusions, spelling checker exclusions, best bets, visual best bets, and search schema metadata.
    • Capacity requirements. Small size; no guidance; depends on the number of keywords, synonyms, document promotions and demotions, site promotions and demotions, term entity extractor inclusions, term entity extractor exclusions, spelling checker exclusions, best bets, and visual best bets.
    • Performance requirements. No guidance.
  • Managed Metadata database. Stores managed metadata and syndicated content types.
    • Capacity requirements. Medium size; no guidance; depends on the number of content types and keywords used in the farm.
    • Performance requirements. No guidance.
  • PerformancePoint database. Stores temporary objects, persisted filter values, and user comments.
    • Capacity requirements. Small size; no guidance; however, plan for a minimum size of 1 GB.
    • Performance requirements. No guidance; however, minimal IOPS is to be expected.
  • PowerPivot Application database. Stores the location of cached or loaded PowerPivot for Excel 2010 data files, data refresh schedules, and PowerPivot for Excel 2010 usage data that is copied from the central usage data collection database.
    • Capacity requirements. Small size; no guidance.
    • Performance requirements. No guidance.
  • Office Project Server 2010 database. Stores data in four separate databases: Drift, Published, Archive, and Reporting.
    • Draft database. Contains data for editing projects and hosts the tables that the Project Queue uses.
      • Capacity requirements. Medium size; must be located in the same database instance as the Published and Archive databases.
      • Performance requirements. No guidance.
    • Published database. Contains a copy of all of the projects that have been published, tables that are specific to Project Server 2010 (timesheets, resources, custom fields, security definitions, and other metadata) and tables that the Timesheet Queue uses.
      • Capacity requirements. Medium size; must be located in the same database instance as the Draft and Archive databases.
      • Performance requirements. No guidance.
    • Archive database. Stores project backups, resources, calendars, enterprise custom fields, the enterprise global Project Web Access view definitions, Project Web Access system settings, and category and group security settings as set up by the Project Web Access administrator.
      • Capacity requirements. Small to extra-large size. If archiving is used, this database will be at least as large as the Draft database but is likely to be much larger. Size can be limited to a set multiplier of the Draft database.
      • Performance requirements. No guidance.
    • Reporting database. Contains all projects in Project Server 2010 as snapshots of each project plan based on the last time a project was published to Project Server 2010.
      • Capacity requirements. Large size; no guidance.
      • Performance requirements. No guidance.
  • Search databases. Enterprise search stores data in three separate databases: Administration, Property, and Crawl.
    • Administration database. Hosts the Search Service application configuration and access control list as well as best bets for the crawl feature. This database is accessed for every user and administrative action.
      • Capacity requirements. Small to medium size; the recommendation is to allocate 10 GB of space.
      • Performance requirements. No guidance.
    • Property database. Stores information associated with the crawled data, including properties, history, and crawl queues.
      • Capacity requirements. Large to extra-large size; estimate the size using the following calculation:

        Database size = sum of all content databases in the farm × 0.015

      • Performance requirements. Index creation of items is extremely IOPS heavy. Though the product group has no detailed guidance, plan for a minimum of 2,000 IOPS. At least one-third of this database should fit into RAM on the server.
    • Crawl database. Stores the state of the crawled data and the crawl history.
      • Capacity requirements. Medium to large size; estimate the size using the following calculation:

        Database size = sum of all content databases in the farm × 0.046

      • Performance requirements. Index creation of items in this database is extremely IOPS heavy. Though the product has no detailed guidance, plan for a minimum of 3,500 IOPS. IOPS can reach 7,000 during indexing.
  • Secure Store database. Stores and maps credentials, such as account names and passwords.
    • Capacity requirements. Medium size; the size of this database is influenced by both the number of credentials stored and the number of entries in the audit table. Estimate the size using the following calculation:

      Database size = (Number of credentials in store / 1,000) × 5 MB

    • Performance requirements. No guidance; however, minimal IOPS is to be expected.
  • State database. Stores temporary state information for the InfoPath Forms Services, the chart Web Part, and Visio Services.
    • Capacity requirements. Medium to large size; no guidance, but plan for a minimum size of 1 GB.
    • Performance requirements. No guidance; however, minimal IOPS is to be expected.
  • Subscription Settings database. Stores features and settings for hosted customers.
    • Capacity requirements. Small size; no guidance, but plan for a minimum size of 1 GB.
    • Performance requirements. No guidance; however, minimal IOPS is to be expected.
  • User profile databases. Stores data in three separate databases: Profile, Synchronization, and Social Tagging.
    • Profile database. Stores and manages users and associated information. It also stores information about a user's social network in addition to memberships in distribution lists and sites.
      • Capacity requirements. Medium to large size; estimate the size using the following calculation:

        Database size = Number of users × 1 MB

        This calculation is based on a deployment of SharePoint Server 2010 using default settings and can change based on how much detail is being gathered from AD DS.

      • Performance requirements. No guidance.
    • Synchronization database. Stores configuration and staging data for use when profile data is being synchronized with directory services such as AD DS.
      • Capacity requirements. Medium to large size; estimate the size using the following calculation:

        Database size = Number of users × 630 KB

        This calculation is based on a deployment of SharePoint Server 2010 using default settings and can change based on the number of groups to which each user belongs.

      • Performance requirements. No guidance.
    • Social Tagging database. Stores social tags and notes created by users, along with their respective URLs.
      • Capacity requirements. Small to extra-large size; estimate the size using the following calculation:

        Database size = Number of user artifacts (tags, comments, or ratings) × 0.009 MB

        This calculation is based on a deployment of SharePoint Server 2010 using default settings and can change based on the number of artifacts users create over time. The product group has studied real-world data and trending from the popular website del.icio.us and has determined that approximately 10 percent of all users should be considered active, creating approximately 6.3 artifacts (4.5 tags and 1.8 comments) per user per month, while 90 percent of users should be considered average, creating approximately one artifact per user per month.

        Thus, a more refined estimation can be used if users will be leveraging artifacts:

        Database size = (((number of users × 0.9) x 1) + ((number of users × 0.1) × 6.3)) × 0.009 MB

      • Performance requirements. No guidance.
  • Web Analytics databases. Stores data for the Web Analytics service application in two databases: Staging and Reporting.
    • Web Analytics Staging database. Stores unaggregated fact data, asset metadata, and queued batch data.
      • Capacity requirements. Large size; no guidance; the size of these databases varies depending on the retention period; the overall daily volume of data being tracked; and the number of site collections, sites, and subsites in the particular website being analyzed.
      • Performance requirements. No guidance for IOPS requirements for the Web Analytics databases. For information on estimating the performance for these databases, see "Capacity requirements for the Web Analytics Shared Service in SharePoint Server 2010" at http://technet.microsoft.com/en-us/library/gg440601.aspx.
    • Web Analytics Reporting database. Stores aggregated standard report tables, fact data aggregated by groups of sites, date and asset metadata, and diagnostics information.
      • Capacity requirements. Extra-large size; no guidance; depends on the website's retention policy.
      • Performance requirements. No guidance.
  • Word Automation Services database. Stores information about pending and completed document conversions.
    • Capacity requirements. Small size; no guidance.
    • Performance requirements. No guidance; however, this database is read-heavy.

For more information, see "Storage and SQL Server capacity planning and configuration" at http://technet.microsoft.com/en-us/library/cc298801.aspx.