Dell Large Share Point Farm

Designing and Building a

Large Farm for MOSS 2007

SharePoint Solutions
Engineering
By Kevin Guinn

Dell Product Group
July 2009
Designing and Building a Large Farm for MOSS 2007

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 ii

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 1


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 2


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 3


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
A set of servers that collectively provides the databases, applications, and Web services that
SharePoint Farm
comprise a SharePoint solution.
Individual servers that run the operating system and application software required to
SharePoint Servers perform roles or provide services for the SharePoint farm. Examples include a Web front‐end
server, an application server, and a database server.
A container that is configured within Internet Information Server (IIS) to constrain a defined
IIS Application set of content to operate within a defined set of system processes. Application Pools provide
Pool 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.
An IIS Web site with a unique domain name that is created and used by SharePoint products.
IIS Web Three Web applications must be configured: Central Administration, Shared Services
Application 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.
Individual SQL Server databases that are used to store information about or data from within
SharePoint a SharePoint farm. The core databases used by SharePoint are Configuration, Administration,
Database SSP, Search, and Content. Depending on its architecture and needs, a farm may feature
multiple SSP, Search, and Content databases.
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
Site Collection
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.
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
Site
team sites for collaboration. MOSS provides templates for several types of sites, such as
blogs, wikis, team sites, and portals.
A means of collecting, storing, and organizing data within a site. Some common examples
List
include document collections, calendars, and tasks.
An individual data object within a list. Some common examples include document or image
Item
files, contacts, and calendar entries.

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


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 5


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
Provides the services and interfaces necessary for configuration, provisioning, and
Central Administration
management of the farm and the sites that it contains.
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,
Shared Service Provider and the business data catalog. One Shared Service Provider (SSP) can generally serve
(SSP) 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.
Provides basic search services for content that is within the farm and provided by
WSS Search SharePoint Services features. The enhanced search functionality of a MOSS farm
primarily relies on the SSP Search component.
Responsible for crawling content and building indexes which contain keywords and
metadata related to the content. These indexes facilitate searching for people and
Index
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.
Accepts search queries that enable users to locate previously‐indexed content.
Query When this role is configured separately from the index server, a copy of the index is
propagated to each query server.
Acts as the presentation tier, and uses Internet Information Server (IIS) to display the
Web Front End (WFE)
SharePoint sites and their content to end‐users.
Provides a means for converting a document from one format to another (e.g., from
Document Conversion Microsoft Word to an HTML Web page). This facilitates publishing of content, and is
Launcher particularly useful when using the Enterprise Content Management (ECM) features
of SharePoint.
Processes document conversion requests and assigns conversion tasks to an
available Document Conversion Launcher. If document conversion services are
Document Conversion needed, at least one Load Balancer and one or more Launchers must be running in
Load Balancer 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.
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
Excel Services render an Excel spreadsheet as an HTML page. The Web services component runs on
[Enterprise Edition Only] 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.
Provides a means to interact with data sources that are outside of the SharePoint
Business Data Catalog farm. Examples include other SQL Server or Oracle databases, Enterprise Resource
[Enterprise Edition Only] Planning (ERP) solutions, and Customer Relationship Management (CRM)
applications.
Page 6


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 3 per farm The absolute limit is 20 SSPs per farm, but no more than
(SSP) 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 Overall farm throughput has been seen to decrease as
database the number of site collections increases.
Sites 125 (top‐level) sites per If nested in this manner, a total of 250,000 total sites
site collection can be provisioned. Exceeding these boundaries can
Sub‐sites 2,000 sub‐sites per top‐ impact the performance of the entire site collection.
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
Items 2,000 per view experience when rendering list views. Some larger lists
may be acceptable if filtered views are used.
Web Parts 50 (basic) Web Parts per As Web Part complexity increases, the number of Web
page Parts per page should be reduced.

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


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 8


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 9


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 10


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 Windows Server 2008 x64
Edition 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 11


Table 5: Key Factors for Selecting a SQL Server Edition
SQL Server 2008 x64 Standard SQL Server 2008 x64 Enterprise
Edition 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 12


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
Performance Preferred RAID
Function Notes
Priority Level
TempDB Data and 1 RAID 1/0 TempDB is used fairly heavily in a SharePoint
Transaction Logs environment. Always allocate dedicated spindles,
and preferably provision one (equal‐sized)
TempDB data file per processor core.
Transaction Logs for all 2 RAID 1/0 Transaction logs are accessed often and are
Other Databases write‐intensive. Always allocate dedicated
spindles, and preferably provision one log file per
processor core.
SSP Search Database 3 RAID 1/0 When possible, allocate dedicated spindles for
Data 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 Consider separate content databases for site
collaborative sites collections that are particularly active or for site
or when there will collections with access patterns that differ
be significant write greatly. Consider provisioning one data file per
activity processor core for the content databases.

RAID 5 is
appropriate for
read‐intensive
content
repositories or
portals
Configuration Database 5 RAID 5 or RAID 1/0 The configuration database is changed and
Data written to less frequently than the other
SharePoint databases; it is generally the best
candidate RAID sets with fewer or slower disks.

Page 13


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 Database Fill factor (for growth Minimum disk space

to be stored overhead and versioning) to allocate
Rule of Thumb X 20% 50 – 70% recommended ~1.7 * X (70% fill factor)
(0.2 * X) ~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 14


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 15


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 Approximate Minimum disk space to allocate

(based on content source) index size (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 16


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 17

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
Any scheduled full or incremental crawls will not take place.
New content can be added, but will not be indexed.
Index Server
Users can still search against the “stale” version of the index stored on the
Query servers.
Users cannot perform searches.
All content remains available, and new content can be added.
Query Server 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.
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
Web Front‐End Server Dedicated Query servers.
to Crawling Operations 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.
All crawling and indexing operations are disabled.
SSP Search Database Content remains accessible, and site browsing is possible.
No query responses (search results) can be generated.
Any content within web applications and site collections associated with a
Content Database
content database that is down are completely inaccessible.

Page 18


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 Both the primary SQL Server and its
array and employs RAID, hardware mirroring partner have their own copy of
redundancy, and multipath I/O for the data, and each node’s storage
protection. The clustered SQL Server subsystem features RAID and hardware
instance can run on any node in the redundancy. Although manual recovery is
cluster, providing tolerance for a wide necessary, the fact that there are
range of hardware or software faults on independent database servers provides
the host servers. The design goal for a protection against faults that may
failover cluster is to militate against a adversely impact one of the database host
single point of failure causing the servers.
database to remain offline.
Recovery Method When there is a failover event, there will Although it is possible to use a witness
be some downtime as SQL Server system and provide automated failover of
services are started on the alternate the database to the mirroring partner, the
cluster node and the database steps SharePoint application server will still have
through the redo logs to ensure to be updated to connect to the alternate
consistency. Once this is complete, database server. Using SQL Server
services will resume without connection aliases can help reduce the
intervention. time required to perform the manual (or
scripted) recovery steps.
Performance Impact The overhead associated with running a Logs are compressed and transmitted to
clustered instance versus a standalone the database mirroring partner. This will
instance of SQL Server is generally add some additional CPU, network, and
considered to be negligible. I/O load to the primary SQL Server system.
OS and SQL Server Operating System: Enterprise Edition is Operating System: Standard Edition is
Editions required for Failover Clusters. generally sufficient.

SQL Server: Standard Edition supports SQL Server: Standard Edition provides
exactly two cluster nodes. Enterprise high‐safety (synchronous) mirroring.
Edition supports as many nodes as the Enterprise Edition adds support for high‐
operating system. 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 19


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 20


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 21


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 22


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 23


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 24


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 25

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 Storage Capacity

Other Notes
Array Technology (# of Disks)
EqualLogic iSCSI Sixteen 3.5” disks per array. Supports thin provisioning that can be
PS Series Up to 12 arrays per group. used to enable future growth.
One server can access volumes from Arrays can be added non‐disruptively.
multiple groups. Volumes are designated based on
capacity; administrators do not need to
consider spindle count.
Dell / EMC Fibre Channel Fifteen 3.5” disks per array or Supports thin provisioning that can be
CX4 Series or iSCSI expansion enclosure. used to enable future growth.
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.
PowerVault SAS Twenty‐four 2.5” disks per array. Host‐based RAID (PERC 6/E), so cannot
MD1120 Up to three arrays (72 disks) can be be used with failover clusters.
daisy‐chained and connected to a
single x4 SAS bus. SAS, so cannot be attached to modular
For optimal performance, limit daisy‐ (blade) servers.
chaining and consider adding
additional PERC 6/E controllers.

Page 26

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

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.
channels.
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).
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).
Database Server 18 total DIMM slots (9 per socket): for best memory bandwidth, populate all three
channels.
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.
channels.
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.
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.
Seven PCIe expansion slots (e.g., for storage HBAs or additional network ports).

Page 27


Farm Role Server Notes
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.
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.
Index Server 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 R710 If the server will be hosting a query role, the same storage considerations in the
and/or Query M610 “Index Server” section above will apply.
Server M710 If the server will host the WFE role but not the query role, then the storage
T710 considerations are mostly irrelevant.

Page 28

Dell Large Share Point Farm

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Dell Large Share Point Farm

Diunggah oleh

Hak Cipta:

Format Tersedia

Designing and Building a

Object Advised Upper Bound Discussion

Size of content Database Fill factor (for growth Minimum disk space

Size of data crawled Approximate Minimum disk space to allocate

SQL Server on a Failover Cluster SQL Server Database Mirroring

Storage Storage Capacity

Farm Role Server Notes

Anda mungkin juga menyukai