designing and building a large farm for moss 2007 and building a... · designing and building a...

Designing and Building a Large Farm for MOSS 2007

SharePoint Solutions Engineering By Kevin Guinn

Dell Product Group July 2009


Page ii

Executive Summary

Implementing a Microsoft® SharePoint® solution presents many decision points and challenges. This paper

discusses some of those challenges and provides possible solutions. It also proposes reference architectures for

integrating Dell server and storage hardware into a large server farm for Microsoft Office SharePoint Server

(MOSS) 2007. The typical large farm, as documented in this paper, is designed to handle up to 10000 users; such a

farm generally houses and indexes hundreds of gigabytes of mixed content.

Many of the early planning steps and design decisions that define the size and topology of the farm are

instrumental in defining the farm’s information architecture. Determining the topology for a SharePoint solution

that can accommodate up to 10000 users and provide collaboration, search, portal, and document library

functions across departmental boundaries requires planning. The solution should be designed to accommodate

business controls and regulatory requirements, and must also provide room for future flexibility and scalability. To

meet these goals, the information architecture should be carefully planned prior to deploying a large SharePoint

farm.

A large SharePoint farm uses many servers: these fulfill roles in the database tier, the application tier, and the

presentation tier. Choosing the right hardware—such as Dell™ PowerEdge™ servers and Dell EqualLogic™, Dell

PowerVault™, or Dell / EMC storage arrays —provides a solid foundation for the farm and allows scalability to

accommodate future growth. This paper provides planning considerations and recommendations for deploying

servers in each tier of the farm.

At this scale, most SharePoint deployments are considered critical and must be able to meet stringent service level

agreements. In such scenarios, the farm must be designed to provide additional redundancy and availability. For

the database tier, Microsoft Windows Server® Failover Clustering and Microsoft SQL Server® Database Mirroring

offer high levels of protection; however, each solution has its benefits and drawbacks. At the application tier,

distributing the various SharePoint roles across multiple servers provides enhanced availability for the solution.

Finally, at the presentation tier, Network Load Balancing or other similar technologies can be used for the Web

front‐end services.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND

TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF

ANY KIND.

© 2009 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express

written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

Dell, the DELL logo, PowerEdge, PowerVault, and EqualLogic are trademarks of Dell Inc. Microsoft, Windows,

Windows Server, SQL Server, Excel, Word, PowerPoint, Outlook, Active Directory, and SharePoint are registered

trademarks of Microsoft Corporation in the United States and/or other countries. Intel and Xeon are registered

trademarks of Intel Corporation.


Page 1

Table of Contents Introduction ................................................................................................................................................................... 2

Overview of SharePoint Products and Technologies ..................................................................................................... 2

MOSS Containment Hierarchy ................................................................................................................................... 4

MOSS Roles and Services ........................................................................................................................................... 6

Designing and Building a Large Farm for MOSS 2007 .................................................................................................... 7

Information Architecture ........................................................................................................................................... 7

Other Infrastructure Elements .................................................................................................................................. 9

Large Farm Topology ............................................................................................................................................... 10

Considerations for the Database Server .................................................................................................................. 11

Database Server System Architecture ................................................................................................................. 11

Windows Server and SQL Server Editions for the Database Server ..................................................................... 11

Database Storage ................................................................................................................................................. 12

Estimating Storage Capacity .................................................................................................................................... 14

Considerations for the MOSS Application and Web Front‐End Servers .................................................................. 15

Application and Presentation Server System Architecture ................................................................................. 15

Windows Server and Office SharePoint Server Editions for Application and Presentation Servers .................... 16

Index Server Storage ............................................................................................................................................ 16

Query Server Storage ........................................................................................................................................... 17

Providing High Availability and Redundancy for a Large Farm .................................................................................... 18

Providing High Availability for the SharePoint Databases ....................................................................................... 19

SQL Server with Windows Server Failover Clustering .......................................................................................... 19

SQL Server Database Mirroring ........................................................................................................................... 21

Providing High Availability for the Application and Presentation Tiers ................................................................... 22

Shared Service Provider and Index Server ........................................................................................................... 22

Query Server ........................................................................................................................................................ 22

Load Balancing Web Front‐End Servers ............................................................................................................... 23

Conclusions .................................................................................................................................................................. 24

Figures ......................................................................................................................................................................... 24

Tables ........................................................................................................................................................................... 25

References ................................................................................................................................................................... 25

Appendix A: Selecting a Dell Storage Array ................................................................................................................. 26

Appendix B: Selecting PowerEdge Servers and Blade Servers ..................................................................................... 27


Page 2

Introduction SharePoint is widely used to provide collaborative sites, portals, document repositories, and other Web‐based

content. MOSS includes templates for many common use cases, and offers a development platform that allows for

significant customization. This paper provides an overview of SharePoint products, and proposes a recommended

architecture for a large farm.

The basic topology of a large farm consists of one or more back‐end database servers, and multiple servers for the

mid‐tier and front‐end roles. This type of farm is typically designed as a production environment for up to 10,000

users. This paper provides recommendations for designing a large farm using Dell server and storage hardware and

for configuring the services in the farm.

SharePoint solutions of this scale often specify a service level agreement (SLA) that requires redundancy and fault

tolerance. To meet this common need, this paper also discusses techniques that increase the availability of

services hosted by the farm.

Overview of SharePoint Products and Technologies The term SharePoint is broadly used to describe a family of products and technologies that interact with Microsoft

SQL Server® and Internet Information Server (IIS) to provide a Web‐based engine and a platform for deploying a

wide range of business services. The most common solutions deployed using this platform are collaborative sites,

content management systems, and Web portals. SharePoint solutions are usually deployed in a farm environment

that provides scalability by distributing database, application, and presentation roles across a group of servers.

Windows SharePoint Services 3.0 (WSS 3.0) provides the core engine, platform services, and facilities for creating

and using templates. This core functionality is based on the ASP.NET 2.0 framework; it can be enhanced and

extended by deploying MOSS 2007 and by developing custom templates and code. All data that is stored within a

SharePoint infrastructure resides within a SQL Server database.

Figure 1 outlines the key services provided by WSS 3.0 and the key enhancements provided by MOSS 2007. It

illustrates how a SharePoint deployment builds on foundational elements provided by SQL Server and Windows

Server, adds platform infrastructure elements in the form of services provided by WSS 3.0, and enhances the

features and functionality of these elements through additional services provided by MOSS 2007. Improved

indexing and search capabilities, the ability to define audiences and share user profile data throughout the

infrastructure, and extensive reporting and analytic capabilities make a compelling case for selecting MOSS as the

technology on which to build a SharePoint solution.

Some MOSS 2007 services are only available with Enterprise Edition1, including the Business Data Catalog and

other services intended to facilitate creating Business Intelligence systems, such as Microsoft Excel® 2007 Services.

The Business Data Catalog allows SharePoint users to search against and interact with external data sources, such

as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) systems, or Oracle and SQL

Server databases. Excel Services enable a rich interaction with Excel, including a snapshot facility for spreadsheets

and the ability to use Web Services protocols to remotely interact with data stored in an Excel spreadsheet.

Ultimately, the Business Data Catalog and Excel Services allow users to quickly and easily develop Business

1 For a more detailed list, see Which SharePoint technology is right for you? on Microsoft.com


Page 3

Intelligence applications and workflows by simplifying access and enabling SharePoint users to work with data

that must otherwise be imported through manual processes.

Figure 1: SharePoint Services Provided by WSS 3.0 and MOSS 2007

As its name implies, MOSS 2007 is considered to be a part of the Microsoft Office family. As such, it offers

integration and ease‐of‐use benefits when used in conjunction with Microsoft Office client applications. For

example, documents stored in a SharePoint library can be directly opened from Microsoft Word®, Microsoft

PowerPoint®, or Excel. Also, from within Microsoft Outlook®, users can subscribe to and display list items from a

SharePoint site or RSS (Really Simple Syndication) feeds provided by a SharePoint‐powered blog. This integration

makes data stored in a SharePoint infrastructure more accessible to end users.


Page 4

MOSS Containment Hierarchy When designing and maintaining a SharePoint solution, it is important to understand the various levels at which

information is organized and contained. The containers within a SharePoint infrastructure are outlined in Table 1.

The most granular individual items are located at the bottom of the table, and the level of aggregation increases as

you progress to the top of the table. These containers provide physical and logical boundaries2 to consider while

designing and deploying a SharePoint infrastructure.

Table 1: MOSS Containment Hierarchy

Container Description

SharePoint Farm A set of servers that collectively provides the databases, applications, and Web services that comprise a SharePoint solution.

SharePoint Servers Individual servers that run the operating system and application software required to perform roles or provide services for the SharePoint farm. Examples include a Web front‐end server, an application server, and a database server.

IIS Application Pool

A container that is configured within Internet Information Server (IIS) to constrain a defined set of content to operate within a defined set of system processes. Application Pools provide logical barriers that protect against the threat of a compromised site being used as a vector to attack other sites hosted on the same Web server.

IIS Web Application

An IIS Web site with a unique domain name that is created and used by SharePoint products. Three Web applications must be configured: Central Administration, Shared Services Provider (SSP), and content. Additional Web applications may be useful for providing content isolation or for establishing distinct management or SLA boundaries within the farm.

SharePoint Database

Individual SQL Server databases that are used to store information about or data from within a SharePoint farm. The core databases used by SharePoint are Configuration, Administration, SSP, Search, and Content. Depending on its architecture and needs, a farm may feature multiple SSP, Search, and Content databases.

Site Collection

A set of sites that feature the same owners and administrative settings (such as content types or quotas). A site collection features a top‐level Web site and may also contain several sub‐sites. Generally, all of the sites within a site collection share a common navigational design. One content database can host multiple site collections, but data from a given site collection must reside in the same content database. Similarly, one or more site collections may be configured within the same Web application.

Site

A set of Web pages stored within a site collection that provide common features or content to users. Sites may be structured, such as a top‐level portal site, or may be ad hoc, such as team sites for collaboration. MOSS provides templates for several types of sites, such as blogs, wikis, team sites, and portals.

List A means of collecting, storing, and organizing data within a site. Some common examples include document collections, calendars, and tasks.

Item An individual data object within a list. Some common examples include document or image files, contacts, and calendar entries.

2 For more information, see Plan for software boundaries (Office SharePoint Server) on Microsoft TechNet.


Page 5

Figure 2 represents the relationship between a site collection and the sites, lists, and items of which it is

comprised. The items are organized into lists, which are – in turn – organized into sites within the site collection.

This site collection is configured within a single Web application, and all of its data and items are stored in a

content database. A large farm can house many separate site collections, and its information architecture plays a

critical role in determining the relationships between the Web applications and other higher‐level entities outlined

in Table 1.

Figure 2: Relationships between Entities within a Site Collection


Page 6

MOSS Roles and Services Within a SharePoint farm, there are many different services that can be hosted on various servers in the farm to

provide specific roles within the solution. The most common roles and services are outlined in Table 2. Due to the

size and complexity of a large farm, these roles will typically be distributed among many servers. The next section

of this paper makes recommendations about how to allocate roles in a large SharePoint farm.

Table 2: MOSS Roles and Services

Role / Service Description

Central Administration Provides the services and interfaces necessary for configuration, provisioning, and management of the farm and the sites that it contains.

Shared Service Provider (SSP)

A set of core services that can be shared across several Web Applications in the farm. These services include user profiles, usage reporting, search, Excel services, and the business data catalog. One Shared Service Provider (SSP) can generally serve the entire farm, but additional SSPs may be desired in circumstances where business requirements dictate a strict level of data isolation that exceeds the capabilities of defining audiences.

WSS Search Provides basic search services for content that is within the farm and provided by SharePoint Services features. The enhanced search functionality of a MOSS farm primarily relies on the SSP Search component.

Index

Responsible for crawling content and building indexes which contain keywords and metadata related to the content. These indexes facilitate searching for people and content. Only one index server can be configured for each SSP, but it is possible for a single index server to be associated with multiple SSPs.

Query Accepts search queries that enable users to locate previously‐indexed content. When this role is configured separately from the index server, a copy of the index is propagated to each query server.

Web Front End (WFE) Acts as the presentation tier, and uses Internet Information Server (IIS) to display the SharePoint sites and their content to end‐users.

Document Conversion Launcher

Provides a means for converting a document from one format to another (e.g., from Microsoft Word to an HTML Web page). This facilitates publishing of content, and is particularly useful when using the Enterprise Content Management (ECM) features of SharePoint.

Document Conversion Load Balancer

Processes document conversion requests and assigns conversion tasks to an available Document Conversion Launcher. If document conversion services are needed, at least one Load Balancer and one or more Launchers must be running in the farm. Both of these services can be hosted on the same server. Because a Load Balancer can select any available Launcher, custom converters must be installed on all servers that host the Launcher service.

Excel Services [Enterprise Edition Only]

Consists of Excel Web Access, Excel Web Services, and Excel Calculation Services. The Web access component runs on a Web front‐end server and provides the facility to render an Excel spreadsheet as an HTML page. The Web services component runs on a Web front‐end server, and enables programmatic access to data stored in a spreadsheet. Finally, the calculation services run on the SSP, and allow loading, calculation, and interaction with a shared spreadsheet.

Business Data Catalog [Enterprise Edition Only]

Provides a means to interact with data sources that are outside of the SharePoint farm. Examples include other SQL Server or Oracle databases, Enterprise Resource Planning (ERP) solutions, and Customer Relationship Management (CRM) applications.


Page 7

Designing and Building a Large Farm for MOSS 2007 A SharePoint server farm is a set of servers which collectively provides the services needed by a SharePoint

deployment. Some of these services, or sets of services, comprise predefined roles and must be configured within

the solution. Other services and roles are optional, but they provide additional features and functionality that are

often desirable. There are some constraints and best practices that help determine which roles should be located

on each server in the farm. Also, by considering how the roles are distributed, the farm can be designed to more

easily accommodate later growth.

Information Architecture A large farm will typically include multiple application pools, content databases, and site collections. The way that

these entities are allocated and arranged helps determine the information architecture for the farm, which should

be developed in conjunction with the farm’s hardware topology. Considerations for developing the information

architecture are based on the intended uses of the farm and on the SLAs that govern these uses, including

performance targets, data isolation, and backup windows. A farm may provide services to intranet, extranet, and

internet environments; it may feature large document repositories, portals, enterprise search, and collaborative

sites. The end‐user experience will depend heavily on how hardware and software resources are used in the farm.

The information architecture for a large SharePoint farm should be designed to allow for flexibility and growth, and

must account for this growth in terms of many overlapping factors. Some of these factors include physical storage,

number of sites and sub‐sites, number of list items, and number of users. The scalability boundary conditions3

listed in Table 3 serve as a starting point for discussing how information will be organized within the MOSS 2007

farm.

Table 3: Upper Bounds for Various Farm Objects

Object Advised Upper Bound Discussion

Shared Services Provider (SSP)

3 per farm The absolute limit is 20 SSPs per farm, but no more than three are advised to maintain optimal performance.

Web Applications 99 per SSP Child farms that use the same SSP are included in this maximum.

Content Databases 100 per Web application A given query server can also support up to 100 content databases.

Site Collections 50,000 per content database

Overall farm throughput has been seen to decrease as the number of site collections increases.

Sites 125 (top‐level) sites per site collection

If nested in this manner, a total of 250,000 total sites can be provisioned. Exceeding these boundaries can impact the performance of the entire site collection. Sub‐sites 2,000 sub‐sites per top‐

level site

Documents 5 million per library The type and size of documents that are stored will impact this limit. Nested folders, views, and other organization techniques enable larger libraries.

Lists 2,000 per site (or sub‐site) These guidelines are intended to maintain a good user experience when rendering list views. Some larger lists may be acceptable if filtered views are used.

Items 2,000 per view

Web Parts 50 (basic) Web Parts per page

As Web Part complexity increases, the number of Web Parts per page should be reduced.

3 For more details, see Plan for software boundaries (Office SharePoint Server) on Microsoft Technet


Page 8

Object Advised Upper Bound Discussion

Managed Paths 20 per Web application More than 20 may be allocated, but each managed path can consume memory and processor resources on Web front‐end servers.

Users in security groups 2 million per Web site When there is a large user population, use Windows security groups instead of managing security on an individual user basis.

User profiles 5 million per farm This is the maximum number of user profiles that can be imported from Microsoft Active Directory® into the SharePoint farm’s profile store.

The factors in Table 3 influence the scalability and performance considerations of the information architecture. For

an optimal end‐user experience, all basic farm navigation operations and page loads should be able to complete

with sub‐second response times. This is not always practical, but response times that exceed three seconds for

high‐frequency operations – such as loading a portal home page or a document library – are likely to generate user

complaints. Predictions and modeling are an important part of the information architecture. However, when a

farm is released to production, its use will evolve over time. In addition to planning for growth, administrators

should monitor response times, indexing times, and other criteria as the farm is used. Based on the actual

observations, assumptions may change and it may prove useful to reallocate roles among the servers in the farm.

Business and regulatory controls may also require various levels of data isolation. Strict data isolation

requirements may not only necessitate additional content databases, web applications, and site collections, but

may also stipulate that separate SSPs or database servers be provisioned within a farm. If the farm needs to meet

these types of requirements, then the information architecture and physical hardware topology may both be

impacted.

Similarly, planning the information architecture can help improve search performance in the farm. A few factors

that will influence the capabilities of the search infrastructure include the number of (internal and external)

content sources that are indexed, how “Best Bets” and synonyms are assigned to keywords, and which properties

and metadata are discovered during a crawl operation. Additionally, how crawl rules are defined, and if results

removal is required for various audiences will influence the time required to complete an indexing operation. That

time directly impacts the “freshness” of the index and, therefore, how rapidly new content can be found by end‐

users.

Complete books can be written about many of the areas for which planning the information architecture of the

farm is important, and an in‐depth examination of these topics is beyond the scope of this paper. However, Dell

Pro‐Consult services have detailed assessment, design, and implementation offerings that bring our experts on site

to assist you with your specific SharePoint requirements and needs.


Page 9

Other Infrastructure Elements Installing a server farm for MOSS 2007 requires the inclusion of certain infrastructure and services to fully exploit

SharePoint features and functionality. For example, Active Directory (AD) is a pre‐requisite, because it provides

authentication and authorization among the servers in a MOSS 2007 farm and can be used to import user profile

information from AD into SharePoint. If your farm is heavily used, adding additional directory servers may be

necessary to handle the authentication traffic.

Figure 3: Integrating SharePoint into an Enterprise Infrastructure

Exchange Server 2007 can be used for the mail‐out and mail‐in connections for SharePoint. These connections

enable features such as e‐mail notification of changes to a SharePoint collaboration site and the ability to create

blog entries by sending an e‐mail. In addition, if Outlook Web Access (OWA) is configured in the Exchange

environment, then data stored in Exchange – such as a user or group calendar, task list, or e‐mail items – can be

directly displayed within a page on a SharePoint site.

Similarly, Office Communications Server (OCS) 2007 enables user presence information to be displayed on

SharePoint pages. For example, the familiar “gumball” from Office Communicator is displayed next to user names

on the SharePoint page, providing the ability to view free/busy data, initiate instant messaging conversations, send

e‐mail, or even initiate a call with another user. Depending on the configuration of Exchange and OCS and on the

log‐in state of other users, some of these functions may not be available. To fully exploit functionality, a SharePoint

end‐user must be logged in to both Office Communicator 2007 and Outlook 2007.


Page 10

Large Farm Topology The setup utility for MOSS 2007 offers either a Basic Installation or an Advanced Installation. Basic Installation is

intended only for single‐server deployments. Therefore, the Advanced Installation option will be required for all

application servers and web front‐end servers in a large SharePoint farm. A typical large farm uses a three‐tier

architecture: featuring database, application, and presentation tiers. SQL Server is hosted by one server (or a

failover cluster) to form the database tier, systems hosting the MOSS application server roles form the middle tier,

and the Web front‐end server role is distributed across several servers to form the presentation tier. An example

of this architecture is illustrated in Figure 4.

Figure 4: Typical Large Farm for MOSS 2007

In general, this type of large farm is expected to host hundreds of gigabytes (or possibly even terabytes) of content

and to provide services for up to 10,000 users. However, the way a SharePoint deployment is used can vary widely.

The number and type of user requests ultimately determines whether a particular topology is suitable for the

intended use of a SharePoint farm. For example, if much of the content is static or archival, then the data capacity

of the farm can grow considerably without placing additional stress on the web servers. However, the additional

content will cause a full search indexing operation to take longer to complete. Similarly, if enterprise search

represents a significant proportion of the user activities, it can be beneficial to separate the query server role to

dedicated servers. Because there are many such factors at play within a farm of this scale, it is extremely important

to consider the information architecture as well as the hardware topology when determining the farm topology.


Page 11

Considerations for the Database Server The first step toward deploying a SharePoint farm is to prepare the database server. All of the information that is

made available from SharePoint sites is stored in SQL Server databases. SQL Server 2008 has been supported as

the database for SharePoint farms since the release of Service Pack 1 (SP1)4 for MOSS 2007. Several features of

SQL Server 2008 can be used to enhance the functionality or performance of a MOSS farm5. For example, database

backup compression can reduce both the size of backup sets and the time required to complete a backup

operation. Similarly, Transparent Data Encryption can play a role in providing additional security for data stored

within a SharePoint farm.

Database Server System Architecture

The 64‐bit extended (x64) system architecture enables direct addressing of memory beyond the 4 GB ceiling

imposed by 32‐bit systems. Utilizing this capability to increase the number of connections and transactions that

the database server can handle requires x64 server hardware, an x64 operating system, and an x64 version of the

database software. A Dell PowerEdge dual‐socket server running x64 editions of Windows Server 2008 and SQL

Server 2008 provides a strong foundation for a MOSS farm’s database server. For a typical large MOSS farm, eight

processing cores and 16 GB of memory are recommended for the database server. To meet the storage needs for

the database, an external storage array is recommended. The Database Storage section of this paper provides

more information about the storage capacity and I/O requirements.

Another reason to select x64 architecture is that Microsoft has announced that Microsoft SharePoint Server 2010

will only be offered for 64‐bit environments6. Planning for and implementing a 64‐bit architecture for a MOSS 2007

farm helps ensure that the infrastructure will be able to accommodate future SharePoint upgrades.

Windows Server and SQL Server Editions for the Database Server

Choosing among the various editions of Windows Server 2008 and SQL Server 2008 is primarily a function of which

system specifications and software features are important in the intended environment. The most important

considerations for the operating system7 are listed in Table 4, and those for the database software8 are listed in

Table 5. The high‐availability features listed in these tables, such as failover clustering and database mirroring, are

examined later in this paper.

Table 4: Critical Factors for Selecting an Operating System Edition

Windows Server 2008 x64 Standard Edition

Windows Server 2008 x64 Enterprise Edition

Support for Failover Clustering No Yes, up to 16 nodes

Maximum x64 Server RAM 32 GB 2 TB

4 At the time this paper was written, MOSS 2007 SP2 and an additional cumulative update package had been released. Additionally, SQL Server 2008 SP1 had also been released and could be used with SharePoint farms. 5 For more information about using SQL Server 2008 features with MOSS 2007, refer to Integration of SQL Server 2008 and Office SharePoint Server 2007 on Microsoft Technet 6 For more information, see Announcing SharePoint Server 2010 Preliminary System Requirements on the Microsoft SharePoint Team Blog. 7 For a more detailed comparison, see Windows Server 2008: Compare Technical Features and Specifications on Microsoft.com 8 For a more detailed comparison, see SQL Server 2008: Compare Edition Features on Microsoft.com


Page 12

Table 5: Key Factors for Selecting a SQL Server Edition

SQL Server 2008 x64 Standard Edition

SQL Server 2008 x64 Enterprise Edition

Support for Failover Clustering 2 nodes Maximum number of nodes supported by the OS

Database Mirroring High‐safety mode only All High‐performance and High‐safety modes

Database Backup Compression No Yes

Transparent Data Encryption No Yes

Resource Governor No Yes

The combination of these factors will influence which editions of the OS and database are required for a given

farm. Consider the following example: mirrored database servers with 16 GB of RAM are sufficient to meet the

availability and scalability goals for a company’s SharePoint farm, and high‐safety (synchronous) mirroring is

desired. There is also a business need to deploy transparent data encryption to enhance data security in the

SharePoint content databases that are associated with some site collections that the farm will provide. If no other

decision points are involved, the mirrored database servers for this example farm could employ Windows Server

2008 x64 Standard Edition and SQL Server 2008 x64 Enterprise Edition.

Database Storage

The overall performance of a database server is often constrained by its disk I/O subsystem. EqualLogic,

PowerVault, and Dell / EMC storage arrays all provide a storage subsystem that offers battery‐backed cache,

redundant array power supplies, multiple RAID levels, and other core availability features that are commonly

requested in service level agreements for a MOSS farm. For more information about these arrays, see Appendix A.

For best performance, it is recommended to segregate Data, Log, and TempDB files for a SharePoint farm onto

separate sets of spindles in accordance with SQL Server best practices. For a large MOSS farm, separate, dedicated

spindles should also be used for the SSP search database; it is particularly beneficial to create a dedicated file

group for the tables that are heavily involved in crawl operations9. Like the SSP search database, the content

databases can benefit from using more than one file group. However, the native SharePoint backup utilities cannot

be used in conjunction with multiple file groups—in such cases, other SQL Server backup strategies must be used.

These include the database backup facilities provided by SQL Server 2008, or other applications such as Microsoft

Data Protection Manager.

Disk I/O latency and disk queue length are critical factors to monitor as a solution is deployed and adopted. If

requests take longer than 20 milliseconds to complete, the end‐user experience will decline. Additional disks or

arrays can be added if the demands of a farm are placing too much stress on the database storage subsystem. The

expansion capability of EqualLogic, PowerVault, and Dell / EMC storage arrays also provides a path that can be

used to accommodate growth or increased use of the SharePoint farm.

Optimizing I/O for SharePoint Databases The overall performance of a SharePoint solution can be limited by an I/O bottleneck within the database. As a

result, it is important to consider how the solution will be used when determining RAID levels and designing the

9 For a list of these tables and more information about planning storage for a MOSS 2007 deployment, see Physical storage recommendations (Office SharePoint Server) on Microsoft Technet.


Page 13

layout of logical disks for the SharePoint databases. The information architecture for the farm will help determine

the number and size of content databases that are required, and what the I/O priorities are for each database. For

site collections that feature many collaboration sites, there will be many write operations to the database. In

contrast, portals and document libraries tend to favor reads. Table 6 outlines some of the functions that should

have dedicated spindles, identifies a performance priority, and recommends optimal RAID and file configurations.

The performance priority offers guidance for determining the order in which I/O optimizations – such as faster

disks, optimal RAID levels, and multiple SQL Server data or log files – should be applied.

Additionally, there are some optimizations that can be applied when volumes are created within the operating

system. Windows Server 2008 uses a 1024 KB NTFS volume offset that eliminates the need to provide manual

partition alignment using diskpart.exe. NTFS volumes used for SQL Server data, logs, and TempDB should be

configured with a 64 KB allocation unit size.

Table 6: I/O Considerations for SharePoint Database Components

Function Performance

Priority Preferred RAID

Level Notes

TempDB Data and Transaction Logs

1 RAID 1/0 TempDB is used fairly heavily in a SharePoint environment. Always allocate dedicated spindles, and preferably provision one (equal‐sized) TempDB data file per processor core.

Transaction Logs for all Other Databases

2 RAID 1/0 Transaction logs are accessed often and are write‐intensive. Always allocate dedicated spindles, and preferably provision one log file per processor core.

SSP Search Database Data

3 RAID 1/0 When possible, allocate dedicated spindles for the search database and consider provisioning one data file per processor core. To improve indexing performance, consider separate file groups for the tables that are heavily accessed during indexing.

Content Database Data 4 RAID 1/0 for collaborative sites or when there will be significant write activity RAID 5 is appropriate for read‐intensive content repositories or portals

Consider separate content databases for site collections that are particularly active or for site collections with access patterns that differ greatly. Consider provisioning one data file per processor core for the content databases.

Configuration Database Data

5 RAID 5 or RAID 1/0 The configuration database is changed and written to less frequently than the other SharePoint databases; it is generally the best candidate RAID sets with fewer or slower disks.


Page 14

Estimating Storage Capacity Estimating the total data storage space required for a MOSS farm can be challenging, and is highly dependent on

how MOSS will be used within the organization. A departmental or company‐wide portal may demand significantly

more storage be allocated versus a team site or an individual MySite; however, there are likely to be many more of

these smaller sites hosted within the farm. In addition, document libraries will generally require more storage than

site features such as blogs, wikis, and other types of lists. If the versioning and recycle bin features of SharePoint

are to be used, then additional space must also be allocated for this data.

The general recommendation is that each content database should be limited to storing 100 GB of content.

However, experiments at Dell and elsewhere10 indicate that that this limit may be able to be increased to as high

as 300 GB. Even with this relaxed constraint, a large farm is likely to require more than one content database. The

allocation of containers (e.g., application pools and site collections) that a well‐planned information architecture

prescribes will also influence how many separate content databases are required. Each content database is

associated with a Web application, which may encompass one or more site collections.

Table 7 outlines a rule of thumb and provides some examples for estimating the required amount of storage for a

content database. The database overhead in this calculation also provides for metadata storage. Specifying a lower

fill factor provides additional space in the database that can be used to store document version and site recycle

bins. This “unused space” also serves as a buffer that can accommodate growth of the content stored in the farm.

Table 7: Estimating Content Database Size Requirements

Size of content to be stored

Database overhead

Fill factor (for growth and versioning)

Minimum disk space to allocate

Rule of Thumb X 20% (0.2 * X)

50 – 70% recommended ~1.7 * X (70% fill factor)~2.4 * X (50% fill factor)

100 GB of content 100 GB 20 GB 50% 240 GB

175 GB of content 175 GB 35GB 70% 300 GB

In addition to the content databases, the SQL Server host will also require space for housing the configuration and

search databases. The minimum disk space to allocate for the search database should be roughly four times as

large as the approximate index size that is calculated using the formula in Table 8. As discussed in that section, the

size of the index can vary based on the type of content that is stored and indexed by the farm. The search database

is larger than its corresponding index because the search system stores additional metadata that is not part of the

index.

Employing quotas to limit the size of individual sites and establishing governance policies to manage the content

and control the number of sites in the farm can help control the total space required by a given farm. These factors

also play a role in determining the information architecture for the farm. Regardless, it is important to plan for

capacity to increase over time, and to build a flexible and scalable infrastructure that will enable the farm to grow.

10 For example, see the presentation regarding Considerations for Large‐Scale SharePoint Deployments on Microsoft SQL Server on Joel Oleson’s Blog at sharepointjoel.com.


Page 15

Considerations for the MOSS Application and Web Front‐End Servers In a large farm topology, the database server is typically hosted on one server (or a set of clustered or mirrored

servers) and the remaining application server and Web front‐end roles are distributed across several other servers.

This topology enables additional servers to be added and roles to be reallocated as the farm grows to meet the

changing needs of the business. To configure the SharePoint farm, complete the following high‐level steps:

1. Deploy the database server first.

2. Install the MOSS 2007 software and any relevant updates on all application and Web front‐end servers.

NOTE: During the MOSS installation, select the Advanced option (to avoid provisioning a single‐server

solution), and then select the Complete option, even for systems that will initially serve as Web front‐end

servers. This option allows a server to host different roles as the farm changes over time.

3. Configure hardware or software load balancing for the Web front‐end servers.

4. Start to configure the farm by running the SharePoint Products and Technologies Configuration Wizard

on one of the servers that will host the Central Administration role.

5. Run the SharePoint Products and Technologies Configuration Wizard to add additional servers to the

farm.

6. Use the Central Administration interface (or the stsadm command) to configure the roles for each server

in the farm.

At the time this paper was written, SP2 and an additional (April 2009) Cumulative Update were available for WSS

3.0 and MOSS 2007. All servers in the farm must run the same code levels. To facilitate the process of keeping code

levels synchronized, and to reduce the time required to manually apply multiple updates, creating a slipstreamed

installation source is strongly recommended. For more information about available updates, the preferred

installation sequence, and the steps required to create a slipstreamed installation source, see Deploy software

updates for Office SharePoint Server 2007 on Microsoft Technet.

Application and Presentation Server System Architecture

As with SQL Server, the various services that constitute the application and presentation tiers of the MOSS 2007

farm are available for both 32‐bit (x86) and 64‐bit extended (x64) architectures. Some custom code and third‐party

packaged functions have been developed using 32‐bit native code; if these elements are needed in your

environment, then you may choose to host the 32‐bit MOSS and IIS components on an x86 version of the

operating system. If you are primarily using out‐of‐the box functionality, or plan to develop custom functions and

Web parts built with the .NET framework, deploy the x64 versions of the operating system and MOSS 2007. In fact,

Microsoft has already announced that “Windows SharePoint Services 3.0 and Office SharePoint Server 2007 are

the last SharePoint Products and Technologies versions able to run on 32‐bit hardware and operating systems. Do

take this into account in current and future hardware decisions: Buying 64‐bit hardware today helps ensure that

your environment can accommodate future requirements and helps you to take advantage of the performance

and scale of 64‐bit technologies.”11

PowerEdge servers with x64 versions of Windows Server 2008 provide a solid foundation for such an environment.

In this large farm architecture, each server that hosts the Web front‐end role should be configured with at least

four processing cores and at least 6 GB of RAM. When combining the query and Web front‐end roles, increase the

amount of RAM to at least 8 GB. To take advantage of all three memory channels on Nehalem‐based servers,

11 Service Pack 1 for Windows SharePoint Services 3.0 and Office SharePoint Server 2007, p3.


Page 16

consider deploying 12 GB on servers that host both roles. If searches are expected to constitute more than 20% of

user activity, consider increasing the RAM further.

Windows Server and Office SharePoint Server Editions for Application and Presentation Servers

It is uncommon for a SharePoint application server or Web front‐end server to be able to benefit from the

enhancements in Windows Server 2008 Enterprise Edition that are not available in Standard Edition. At the

application tier and presentation tier, failover clustering is not employed for availability; instead, roles within the

farm are configured to run on multiple servers. This means that, in most cases, Windows Server 2008 Standard

Edition will be sufficient for the application and Web front‐end servers.

For MOSS 2007, the biggest differentiator between Standard Edition and Enterprise Edition is related to the

features and services used to develop solutions for Business Intelligence and Business Analytics. These features are

enabled by the Business Data Catalog and Excel Services12 that were outlined in Table 2. If these features are (or

will be) needed in the farm, then select MOSS 2007 Enterprise Edition; otherwise, Standard Edition is likely to be

sufficient.

Index Server Storage

The large farm illustrated in Figure 4 features an index server that crawls sites and makes it possible to search the

content stored within the farm. A content source specifies the locations, depth, and type of content that will be

crawled. Table 8 outlines a rule of thumb and provides some examples for estimating the required amount of

storage for the search index. Exactly one index server is associated with a shared service provider, and can handle

content from several different content databases.

Table 8: Estimating Index Size Requirements

Size of data crawled (based on content source)

Approximate index size

Minimum disk space to allocate (not including future growth)

Rule of Thumb X ~12% * X 2.85 * (Index Size) = ~34% * X

200 GB of data 200 GB 24 GB 68.4 GB

750 GB of data 750 GB 90 GB 256.5 GB

While this rule of thumb is useful, the index size will vary based on the definitions provided by the content source.

If a file share or large content repository contains a significant amount of the indexed content, the index will

generally contain more metadata. In such a scenario, the index size could be closer to 30% of the base content size,

resulting in a recommended allocation that is only 15% smaller than the actual content. If, however, there are no

document libraries and no external content is indexed, then the index size could be as low as 1% to 5% of the base

content size. These factors should be considered when planning the farm’s information architecture.

For best performance, the index should be located on a dedicated RAID 1/0 volume. An index volume with good

write performance can reduce the time required to complete a crawl operation. RAID 1/0 provides write

performance that is well suited for this purpose. The internal disks in many PowerEdge servers can be used to

provide a high‐performance index volume. If there are insufficient internal disks for this purpose, then a volume

from an external storage array can be provisioned for this purpose.

12 See Unsupported Features in Excel Services on the Microsoft Office Developer Center to determine whether Excel Services are desirable in your environment.


Page 17

Query Server Storage

The index data is also propagated to each query server. The query servers use their local copy of the index to

provide responses when an end‐user searches for content. A file share is created on each query server to enable

the index data to propagate properly.

As with the index server, it is preferred to allocate a dedicated volume for the propagated index on each query

server. For these volumes, good read performance is necessary to improve the time required to return search

results. Write performance is generally less critical than network characteristics in determining the time required

for the index to propagate from the index server to the query servers. Either RAID 5 or RAID 1/0 can be used for

the propagated index volume on each query server. This index volume can reside on either internal or external

storage, depending on which servers are chosen for the query server role.


Page 18

Providing High Availability and Redundancy for a Large Farm A SharePoint solution may provide functionality that is deemed to be of high importance for the business. In such

cases, it is important to design the farm in a manner that enhances that availability of the solution.

The server and storage components used throughout this paper offer redundant hardware components, including

power supplies and RAID volumes. Unfortunately, hardware redundancy is often insufficient to meet the service

level agreement (SLA) demanded of important business infrastructure components. To overcome these limitations,

additional hardware can be deployed to protect the solution against a greater range of potential failure scenarios,

and to ensure that most operations can continue in the event that a single server is completely offline.

This section discusses techniques for increasing the availability of a large SharePoint farm and explains the benefits

and limitations of the highly‐available farm architecture. Specific recommendations for backup and recovery,

business continuity, and disaster recovery are outside the scope of this paper.

Table 9 provides an overview of the impact of having various farm roles unavailable for a period of time. This data

is helpful when making decisions about the information architecture for the farm.

Table 9: Impact of Downtime for Farm Roles

Role that Suffers Downtime Impact to the farm and its users

Index Server

Any scheduled full or incremental crawls will not take place.

New content can be added, but will not be indexed.

Users can still search against the “stale” version of the index stored on the Query servers.

Query Server

Users cannot perform searches.

All content remains available, and new content can be added.

Scheduled crawls continue, but updated index is not usable to execute searches until after the query server has been restored and the index has been propagated.

Web Front‐End Server Dedicated to Crawling Operations

Content within the SharePoint farm will not be crawled. Indexes associated with the affected SSP may become outdated.

Users can still search against the “stale” version of the index stored on the Query servers.

External content sources will still be crawled by the indexer.

All content remains available.

New content can be added, but will not be indexed until the role is restored or the indexer is redirected to use alternate Web front‐end servers.

Database Server The impact depends on which databases are unavailable:

Configuration Database The entire farm and all of its content is completely inaccessible.

SSP Search Database

All crawling and indexing operations are disabled.

Content remains accessible, and site browsing is possible.

No query responses (search results) can be generated.

Content Database Any content within web applications and site collections associated with a content database that is down are completely inaccessible.


Page 19

Providing High Availability for the SharePoint Databases Table 9 revealed that database downtime can be extremely disruptive to the farm. Therefore, limiting the potential

for database downtime should be considered a high priority. The two most common ways to enhance the

availability of the database tier are to deploy a failover cluster that runs a SQL Server instance or to employ SQL

Server database mirroring. When used within a SharePoint farm, each of these methods has its own advantages

and disadvantages. These are summarized in Table 10, and discussed in the following sub‐sections.

Table 10: Comparison of Availability Techniques for SQL Server

SQL Server on a Failover Cluster SQL Server Database Mirroring

Protection Provided Data is stored on a single, shared storage array and employs RAID, hardware redundancy, and multipath I/O for protection. The clustered SQL Server instance can run on any node in the cluster, providing tolerance for a wide range of hardware or software faults on the host servers. The design goal for a failover cluster is to militate against a single point of failure causing the database to remain offline.

Both the primary SQL Server and its mirroring partner have their own copy of the data, and each node’s storage subsystem features RAID and hardware redundancy. Although manual recovery is necessary, the fact that there are independent database servers provides protection against faults that may adversely impact one of the database host servers.

Recovery Method When there is a failover event, there will be some downtime as SQL Server services are started on the alternate cluster node and the database steps through the redo logs to ensure consistency. Once this is complete, services will resume without intervention.

Although it is possible to use a witness system and provide automated failover of the database to the mirroring partner, the SharePoint application server will still have to be updated to connect to the alternate database server. Using SQL Server connection aliases can help reduce the time required to perform the manual (or scripted) recovery steps.

Performance Impact The overhead associated with running a clustered instance versus a standalone instance of SQL Server is generally considered to be negligible.

Logs are compressed and transmitted to the database mirroring partner. This will add some additional CPU, network, and I/O load to the primary SQL Server system.

OS and SQL Server Editions

Operating System: Enterprise Edition is required for Failover Clusters. SQL Server: Standard Edition supports exactly two cluster nodes. Enterprise Edition supports as many nodes as the operating system.

Operating System: Standard Edition is generally sufficient. SQL Server: Standard Edition provides high‐safety (synchronous) mirroring. Enterprise Edition adds support for high‐performance (asynchronous) mirrors.

SQL Server with Windows Server Failover Clustering

A failover cluster allows a SQL Server instance to run on any one node that is a cluster member. If the hosting node

fails, the instance will be relocated and start to run on an alternate node; this process is known as failover. During

the installation of SQL Server 2008, options are provided for configuring a clustered instance and for adding an

additional node to a clustered instance13. The clustered instance is configured within a dedicated cluster resource

group that includes the necessary SQL Server services, a common network name and IP address for the instance,

13 For more information, see Getting Started with SQL Server 2008 Failover Clustering on MSDN


Page 20

and the shared NTFS volumes that will be used for data, transaction log, and TempDB storage. This resource group,

and the SQL instance that it contains, will run on one physical node at any given point in time. A failover cluster

hosting the SQL Server database for a large farm is illustrated in Figure 5.

NOTE: Instead of consolidating the roles, the farm in Figure 5 also features separate Web front‐end and query

servers. Such a configuration would be preferred if a significant percentage of the farm’s activities involved search

functionality. The M710 was selected for index and query servers because it offers greater storage capacity than

the M610. If this capacity is insufficient, then M610 servers could be used in conjunction with volumes configured

on an external storage array.

Figure 5: SQL Server Failover Cluster Hosting a Large SharePoint Farm

The failover cluster employs a shared data storage array with integrated RAID controllers, such as the EqualLogic

arrays in Figure 5. The integrated RAID controllers in EqualLogic, PowerVault14, and Dell / EMC arrays help ensure

that uncommitted writes – which reside in cache memory – are preserved in the event that a cluster node fails.

These storage arrays also provide multipath I/O, which protects the clustered SQL Server instance from failures

related to the data paths between the host nodes and the storage array. In addition, expansion arrays can be

connected to expand the capacity of these storage systems. Detailed installation and configuration details for

14 The PowerVault MD3000 and MD3000i feature integrated RAID controllers, and can therefore be used to build SQL Server failover clusters. The PowerVault MD1120 and MD1000 require host‐based RAID controllers, but can be used with SQL Server Database Mirroring.


Page 21

failover clusters with Dell PowerEdge servers and the EqualLogic, PowerVault, and Dell / EMC arrays are available

at www.dell.com/ha and support.dell.com.

SQL Server Database Mirroring

Database mirroring provides a means to keep two copies of a database on separate instances of SQL Server. In

order to provide better data protection, the principal instance and mirror instance should be configured on distinct

servers, and should store data on separate storage devices. This configuration is illustrated in Figure 6. The mirror

relationship is established on a per‐database basis; therefore, mirroring a content database does not automatically

cause configuration or search databases to be mirrored.

The mirror operates by sending sets of transaction log records from the principal server to the mirror server, which

then applies these log records to its copy of the database.15 So, a database that is mirrored must use the full

recovery model. This recovery model is the default for SharePoint content and configuration databases, but search

databases default to using quick recovery. Changing the recovery mode of the search databases may require

allocating additional space for their transaction logs. The cost of this disk space can be weighed against the time

that would be required to perform a full crawl and regenerate search data in the event that the mirror was not

available. Also, it is a good practice to dedicate a network connection to allow the log data to be copied between

the two servers.

Figure 6: Mirrored SQL Servers Hosting a Large SharePoint Farm

15 For more information, see Database Mirroring Overview in SQL Server 2008 Books Online


Page 22

NOTE: Two possible index storage strategies are illustrated in Figure 6. For the propagated indexes on the query

servers, virtual disks on the MD1120 have been used. In this example, the MD1120 would be configured in split‐

bus mode, offering 12 disks to each R610 server that hosts the Web front‐end and query roles. In contrast, a T710

server was selected for the index server. This server features up to 16 internal disks, which can be used to hold the

index volume. Either of these index storage strategies could be easily applied in either the application or the

presentation tier.

SharePoint is not natively aware of database mirroring. Therefore, if the principal SQL Server host fails, the other

servers in the farm will lose their connection to the database. This is true even for cases where the mirror

relationship includes a witness and is configured for automatic failover. To simplify restoring the operations of a

SharePoint farm, using SQL Server connection aliases on the Web front‐end and application servers is

recommended. In the event that the principal SQL Server fails, the alias can be edited to refer to the mirror server.

After this is completed, the affected databases need to be removed and re‐added from Central Administration or

via the stsadm command16.

Providing High Availability for the Application and Presentation Tiers One of the more complicated decisions to make when providing availability17 to a SharePoint farm is related to

distributing the application‐tier and presentation‐tier roles. Many MOSS roles can inherently be run on, and

distributed across, multiple servers in the farm; these include Central Administration, Query, Document

Conversion Launcher, Excel Services, and the Business Data Catalog. These services can simply be configured on

more than one host in the farm. The SSP and Index roles are exceptions to this rule. If two SSPs are configured,

they will operate independently. Further, each SSP can have only one Index server assigned. It is possible,

however, to configure an index server to operate with more than one SSP. To reduce the end‐user impact of

indexing operations, an index server may also host a Web front‐end that is dedicated for crawling content.

Shared Service Provider and Index Server

While many large farms can be served by a single SSP, provisioning additional SSPs may be necessary in order to

provide strict data isolation or to enforce separation between search domains. Although a single index server can

serve many SSPs, many of the business or regulatory controls that would require a farm with multiple SSPs will also

require separate index servers.

It is also possible to configure dual, independent shared service providers for the same set of content. Similarly,

each SSP in this configuration could have a dedicated index server. Because the query servers are associated with a

single index server, manual intervention would be required to re‐configure the query servers and enable this type

of configuration to provide increased availability for the SSP server.

Query Server

When a single host runs both the index and query services, the index server will not propagate the index data to

other query servers18. Additional query servers can share the load and increase the ability of the farm to respond

to concurrent search requests. As a result, the query server role in a large farm is often co‐located on the hosts

that provide the Web front‐end role. For farms where search is heavily used, or if query response latencies are

16 For a full description of the configuration and recovery processes for Database Mirroring, see Using SQL Server Database Mirroring with Office SharePoint® Server and Windows® SharePoint Services on Microsoft.com. 17 For more information about MOSS availability, see Plan for availability (Office SharePoint Server) on Microsoft Technet 18 For more information about search services availability, see Plan for Redundancy on Microsoft Technet


Page 23

high, then separating the query server role onto dedicated servers may prove beneficial. This type of farm is

illustrated in Figure 5.

Load Balancing Web Front‐End Servers

For the Web front‐end server role, a load balancing solution can provide both performance and availability for the

farm’s services. Performance is derived from the fact that user requests to the SharePoint web sites are distributed

among a pool of several servers that host the Web front‐end role. Availability is derived by provisioning an

additional server or servers to provide more capacity than is required to handle the volume of user requests to the

Web sites.

Several load‐balancing solutions are suitable for use with a SharePoint farm, including both hardware‐ and

software‐based options. Many of these solutions, such as Microsoft Internet Security and Acceleration (ISA) Server

or hardware load balancers, can often provide better monitoring and more granular fault detection than is possible

with the Microsoft Network Load Balancing (NLB) service. However, NLB is provided as a component of Windows

Server 2008 and therefore offers a low‐cost option for increasing the overall availability of a SharePoint farm.

When a load‐balancing solution such as NLB is configured, a single network name and IP address is used to

represent the pool of load‐balanced servers. In addition to distributing the load among several nodes, NLB can

detect a failed host and reroute the traffic to provide increased availability. However, NLB does not have the

intelligence to detect many “soft faults,” such as the IIS service not running on a node. Other solutions are able to

overcome this limitation, but were not tested during the development of this paper.

When creating SharePoint Web applications, there is an option to specify a load‐balanced URL, which should be set

to use the logical network name that is provided by NLB (or another load balancing solution). This load‐balanced

URL is specified when a Web application is created from the farm’s Central Administration site, as seen in Figure 7.

If maintaining the state of a session is important, NLB Affinity can cause a session to persist on the same node. This

persistence can also prove helpful for troubleshooting connectivity problems. Similar persistence features are

available with most load balancing solutions.

Figure 7: Specifying a Load‐balanced URL for a Web Application


Page 24

When using NLB (or another load‐balancing solution), the IIS Application Pools and Web Applications are assigned

to the shared, load‐balanced, logical network name. As a result, it is preferable to deploy and verify that the NLB

cluster (or other load‐balancing solution) is operational before configuring the MOSS components.

The NLB service supports both unicast and multicast modes. To allow it to operate in unicast mode, each Web

front‐end host should have more than one available network interface. The shared network name and address will

be configured on the interface that serves end‐user Web requests, and node‐to‐node communication will employ

the other network. This second network can also be used for communication with the SQL Server and other servers

in the farm.

Conclusions Because it is likely to host many different Web applications, site collections, and provide services broadly across

the business, careful planning is required before deploying a large SharePoint farm. Determining the information

architecture for the farm, and understanding important physical and logical boundaries within the system helps

determine the farm’s topology. Dell PowerEdge servers, and EqualLogic, PowerVault, or Dell / EMC storage arrays

are good building blocks for each role in the farm. In addition, Dell has the expertise and offers services to help

determine the information architecture and to design, deploy, and customize the farm.

High availability is often essential for large farms, because they tend to host critical data or services. When a single

role is not available in the farm, the effects range from end‐user inconvenience through complete unavailability of

the farm and its services. Protecting the SharePoint databases is the most critical, and can be accomplished with

either a Windows Server failover cluster or SQL Server Database Mirroring. Techniques are also readily available to

protect the roles at the application and presentation tiers.

Figures Figure 1: SharePoint Services Provided by WSS 3.0 and MOSS 2007 ........................................................... 3

Figure 2: Relationships between Entities within a Site Collection ................................................................ 5

Figure 3: Integrating SharePoint into an Enterprise Infrastructure .............................................................. 9

Figure 4: Typical Large Farm for MOSS 2007 .............................................................................................. 10

Figure 5: SQL Server Failover Cluster Hosting a Large SharePoint Farm .................................................... 20

Figure 6: Mirrored SQL Servers Hosting a Large SharePoint Farm ............................................................. 21

Figure 7: Specifying a Load‐balanced URL for a Web Application .............................................................. 23


Page 25

Tables Table 1: MOSS Containment Hierarchy ........................................................................................................ 4

Table 2: MOSS Roles and Services ................................................................................................................ 6

Table 3: Upper Bounds for Various Farm Objects ........................................................................................ 7

Table 4: Critical Factors for Selecting an Operating System Edition ........................................................... 11

Table 5: Key Factors for Selecting a SQL Server Edition.............................................................................. 12

Table 6: I/O Considerations for SharePoint Database Components ........................................................... 13

Table 7: Estimating Content Database Size Requirements ......................................................................... 14

Table 8: Estimating Index Size Requirements ............................................................................................. 16

Table 9: Impact of Downtime for Farm Roles ............................................................................................. 18

Table 10: Comparison of Availability Techniques for SQL Server ............................................................... 19

Table 11: Dell Storage Arrays for Database or Index/Query Volumes ....................................................... 26

Table 12: PowerEdge Servers for Various Farm Roles ................................................................................ 27

References Dell Resources

SharePoint Solutions: www.dell.com/sharepoint

SQL Server 2008 Solutions: www.dell.com/sql2008

Windows Server 2008: www.dell.com/microsoft

High‐Availability Solutions: www.dell.com/ha

Exchange Server Solutions: www.dell.com/exchange

Unified Communications Solutions (with OCS): www.dell.com/unified

Microsoft Resources

Administrator’s Guide of Topics to Consider before Deployment:

http://go.microsoft.com/fwlink/?LinkId=139163&clcid=0x409

Which SharePoint Technology is Right for You:

http://office.microsoft.com/en‐us/sharepointtechnology/FX101758691033.aspx?ofcresset=1

Service Pack 1 for Windows SharePoint Services 3.0 and Office SharePoint Server 2007:

http://technet.microsoft.com/en‐us/library/cc262529.aspx

Plan for Software Boundaries: http://technet.microsoft.com/en‐us/library/cc262787.aspx

Physical Storage Recommendations: http://technet.microsoft.com/en‐us/library/cc298801.aspx

Integration of SQL Server 2008 and Office SharePoint Server 2007:


Using SQL Server Database Mirroring with Office SharePoint® Server and Windows® SharePoint Services:

http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409

Plan for Availability (Office SharePoint Server):



Page 26

Appendix A: Selecting a Dell Storage Array Dell offers several storage arrays that can be used to fulfill the capacity and performance need for the SQL Server

databases and Index/Query Server volumes in a large SharePoint farm. The following table outlines some of the

key considerations that impact the selection among the most popular of these arrays. Additional information

about deploying these arrays with SQL Server is available at www.dell.com/sql.

Table 11: Dell Storage Arrays for Database or Index/Query Volumes

Storage Array

Storage Technology

Capacity (# of Disks)

Other Notes

EqualLogic PS Series

iSCSI Sixteen 3.5” disks per array.Up to 12 arrays per group. One server can access volumes from multiple groups.

Supports thin provisioning that can be used to enable future growth. Arrays can be added non‐disruptively. Volumes are designated based on capacity; administrators do not need to consider spindle count.

Dell / EMC CX4 Series

Fibre Channel or iSCSI

Fifteen 3.5” disks per array or expansion enclosure. Total number of disks varies based on the array model. CX4‐120, CX4‐240, CX4‐480, and CX4‐960 all offer up to the number of disks designated by the array’s model number.

Supports thin provisioning that can be used to enable future growth.

PowerVault MD1120

SAS Twenty‐four 2.5” disks per array.Up to three arrays (72 disks) can be daisy‐chained and connected to a single x4 SAS bus. For optimal performance, limit daisy‐chaining and consider adding additional PERC 6/E controllers.

Host‐based RAID (PERC 6/E), so cannot be used with failover clusters. SAS, so cannot be attached to modular (blade) servers.


Page 27

Appendix B: Selecting PowerEdge Servers and Blade Servers The table below introduces Dell PowerEdge servers that are well‐suited for deploying large SharePoint farms, such

as those illustrated in Figure 4, Figure 5, and Figure 6. The basic specifications that are most important for the SQL

Server are listed first, followed by internal storage considerations that are important if the server will be used to

host the Index Server or Query Server roles. The figures in this document showed a few representative samples of

farms that can be built using different models of stand‐alone and modular (blade) servers. It is reasonable to

assume that systems with similar specifications can be readily substituted; regardless of their form‐factor, these

systems serve as strong building blocks for a large SharePoint farm.

Table 12: PowerEdge Servers for Various Farm Roles

Farm Role Server Notes

Database Server

R610 1U Rack form‐factor dual‐socket server. 12 total DIMM slots (6 per socket): for best memory bandwidth, populate all three channels. Four integrated GbE network ports. Two PCIe x8 expansion slots (e.g., for storage HBAs).

R710 2U Rack form‐factor dual‐socket server.18 total DIMM slots (9 per socket): for best memory bandwidth, populate all three channels. Four integrated GbE network ports. Up to four PCIe expansion slots (e.g., for storage HBAs or additional network ports).

M610 Half‐height modular form‐factor dual‐socket server (16 per M1000e chassis).12 total DIMM slots (6 per socket): for best memory bandwidth, populate all three channels. Two integrated GbE network ports. Two dual‐port expansion cards (e.g., for storage HBAs or additional network ports).

M710 Full‐height modular form‐factor dual‐socket server (8 per M1000e chassis).18 total DIMM slots (9 per socket): for best memory bandwidth, populate all three channels. Four integrated GbE network ports. Four dual‐port expansion cards (e.g., for storage HBAs or additional network ports).

T710 Tower or 5U Rack‐mountable form‐factor dual‐socket server. 18 total DIMM slots (9 per socket): for best memory bandwidth, populate all three channels. Four integrated GbE network ports. Six PCIe expansion slots (e.g., for storage HBAs or additional network ports).

R900 4U Rack form‐factor four‐socket server. (Intel® Xeon®)32 DIMM slots. Four integrated GbE network ports. Seven PCIe expansion slots (e.g., for storage HBAs or additional network ports).

R905 4U Rack form‐factor four‐socket server. (AMD Opteron™)32 DIMM slots. Four integrated GbE network ports. Seven PCIe expansion slots (e.g., for storage HBAs or additional network ports).


Page 28

Farm Role Server Notes

Index Server

R610 See basic specs in the “Database Server” section above.Six total 2.5” HDDs. External storage may be necessary to increase the capacity or performance of the index volume.

R710 See basic specs in the “Database Server” section above.Six total 3.5” or eight total 2.5” HDDs. Four 450 GB 3.5” 15k rpm SAS drives in a RAID 1/0 configuration provides sufficient capacity for most index volumes.

M610 See basic specs in “Database Server” section above.Two total 2.5” HDDs. External storage (Fibre Channel or iSCSI) should be used for the index volume.

M710 See basic specs in the “Database Server” section above.Four total 2.5” HDDs. For farms with minimal search needs, it may be possible to house the index internally. However, external storage (Fibre Channel or iSCSI) is still recommended.

T710 See basic specs in the “Database Server” section above.Sixteen total 2.5” HDDs. Internal disks offer adequate performance and capacity for the index volume for almost any farm.

Web Front‐End and/or Query

Server

R610 See basic specs in the “Database Server” section above. If the server will be hosting a query role, the same storage considerations in the “Index Server” section above will apply. If the server will host the WFE role but not the query role, then the storage considerations are mostly irrelevant.

R710

M610

M710

T710