White Paper

MICROSOFT SHAREPOINT SERVER: BEST

PRACTICES AND DESIGN GUIDELINES FOR
EMC STORAGE
EMC VNX Family, EMC Symmetrix VMAX Systems, and EMC Xtrem
Server Products
 Design and sizing best practices
 SharePoint performance acceleration with flash technologies
 SharePoint farm availability, protection, and recovery
considerations

EMC Solutions

Abstract
This paper identifies best practices and key decision points for planning and
deploying Microsoft SharePoint Server with the EMC® VNX® family, EMC
Symmetrix® VMAX® Systems, EMC XtremTM Server products, EMC VPLEX® , and
EMC RecoverPoint® .

December 2013
 Copyright © 2013 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as of its

publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC Corporation makes no

representations or warranties of any kind with respect to the information in this
publication, and specifically disclaims implied warranties of merchantability or
fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in this

publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation
Trademarks on EMC.com.

All trademarks used herein are the property of their respective owners.

Part Number H12468

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 2
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table of contents
Executive summary............................................................................................................................... 7

Introduction.......................................................................................................................................... 8
Purpose ........................................................................................................................................... 8
Audience ......................................................................................................................................... 8
Scope .............................................................................................................................................. 8
Terminology ..................................................................................................................................... 8

Microsoft SharePoint Server farm architecture ................................................................................... 10

Microsoft products ......................................................................................................................... 10
Microsoft SharePoint Server ...................................................................................................... 10
Microsoft SQL Server ................................................................................................................. 10
Microsoft Windows Server ......................................................................................................... 10
Topology overview ......................................................................................................................... 11
SharePoint logical architecture ...................................................................................................... 11
SharePoint farm ........................................................................................................................ 11
Web application ........................................................................................................................ 11
Content database ...................................................................................................................... 11
Service application .................................................................................................................... 11
Site collection ........................................................................................................................... 11
Site ........................................................................................................................................... 11
Lists and libraries ...................................................................................................................... 12
SharePoint physical architecture .................................................................................................... 13
SharePoint farm topology............................................................................................................... 13
Farm topology with different scale sizes .................................................................................... 13
Farm topology with different search architectures...................................................................... 15
Farm topology with different user profile architectures .............................................................. 18
Other SharePoint related concepts ................................................................................................. 19

SharePoint I/O and capacity characteristics....................................................................................... 20

Content database I/O and capacity characteristics ........................................................................ 20
I/O characteristics and capacity for content database in SharePoint Server 2010 ...................... 20
I/O characteristics and capacity for content database in SharePoint Server 2013 ...................... 22
Summary of I/O characteristics of content database ................................................................. 24
Content database I/O characteristics with RBS .......................................................................... 24
Search and user profile service application I/O and capacity characteristics .................................. 24
Other service application I/O and capacity characteristics ............................................................. 26

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 3
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint Server hypervisor best practices ...................................................................................... 27
Overview ........................................................................................................................................ 27
General virtualization considerations ........................................................................................ 27
Virtualizing farm server roles ..................................................................................................... 27
Server roles distribution ............................................................................................................ 30
VMware vSphere best practices ..................................................................................................... 30
VMware VMFS versus VMware RDM best practices .................................................................... 30
VMware DRS best practices ....................................................................................................... 31
VMware HA best practices ......................................................................................................... 31
VMware vSphere networking best practices............................................................................... 31
EMC VSI best practices .............................................................................................................. 32
Microsoft Windows Server 2012 with Hyper-V best practices ......................................................... 33
General best practices ............................................................................................................... 33
Microsoft Hyper-V storage options best practices ...................................................................... 33
Guest storage best practices ..................................................................................................... 35
High availability best practices .................................................................................................. 36
Failover cluster best practices ................................................................................................... 36
Multipath I/O best practices ...................................................................................................... 36

SharePoint storage sizing and provisioning ....................................................................................... 38

General storage considerations...................................................................................................... 38
Performance versus capacity considerations ............................................................................. 38
Disk types considerations ......................................................................................................... 38
Pools and RAID type considerations .......................................................................................... 39
LUN selection considerations .................................................................................................... 40
Volume types considerations .................................................................................................... 40
NFS and SMB 3.0 considerations ............................................................................................... 41
RBS (file and block) considerations ........................................................................................... 43
Sizing SharePoint components best practices ................................................................................ 45
Sizing content database best practices ..................................................................................... 46
Sizing SharePoint search service best practices ........................................................................ 47
Sizing SharePoint user profile service best practices ................................................................. 49
Sizing other components in SharePoint ..................................................................................... 50
FAST Suite best practices ............................................................................................................... 50
FAST Suite in next-generation VNX best practices ...................................................................... 50
Best practices for FAST VP on Symmetrix VMAX ......................................................................... 52
Server flash considerations ............................................................................................................ 53
XtremSF ..................................................................................................................................... 53
XtremCache ............................................................................................................................... 54
Automation with ESI....................................................................................................................... 56

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 4
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint Server farm protection ..................................................................................................... 58
Backup and Recovery ..................................................................................................................... 58
General considerations for Backup and Recovery in SharePoint ................................................ 58
SharePoint Server 2010 and 2013 VSS for backup replication ................................................... 61
EMC replication technologies .................................................................................................... 61
EMC Replication Management tool ............................................................................................ 64
Multi-site disaster recovery ............................................................................................................ 66
Disaster recovery scenarios introduction ................................................................................... 66
General considerations and best practices in different disaster recovery scenarios ................... 67
Choosing the right SharePoint disaster and recovery option ...................................................... 73
EMC multi-site replication technologies..................................................................................... 73
SQL Server restart automation tools .......................................................................................... 76
Virtualized instances automation tools ..................................................................................... 77

Conclusion ......................................................................................................................................... 79

References.......................................................................................................................................... 80
EMC documentation ....................................................................................................................... 80
VMware documentation ................................................................................................................. 80
Microsoft documentation ............................................................................................................... 81
Product documentation.................................................................................................................. 81
Links .............................................................................................................................................. 81
Microsoft TechNet ..................................................................................................................... 81
MSDN Library ............................................................................................................................ 82

Appendix A: I/O characteristics analysis for SharePoint Server 2010 and 2013 search and user profile
service application ............................................................................................................................. 83
Search service I/O and capacity characteristics ............................................................................. 83
Sizing I/O characteristics and capacity for search in SharePoint Server 2010 ............................ 83
Sizing I/O characteristics and capacity for search in SharePoint Server 2013 ............................ 88
User profile service I/O and capacity characteristics ...................................................................... 92
Sizing I/O characteristics and capacity for a user profile in SharePoint Server 2010 .................. 92
Sizing I/O characteristics and capacity for user profiles in SharePoint Server 2013 ................... 94

Appendix B: Tools for SharePoint Server performance testing, monitoring, tuning, and sizing .......... 97
EMC DBclassify .............................................................................................................................. 99
Developer dashboard..................................................................................................................... 99
ULS .............................................................................................................................................. 100
System Center Management Pack for SharePoint Server 2010 and 2013 ...................................... 100
EMC Workload Performance Assessment Tool .............................................................................. 101
PAL .............................................................................................................................................. 101
VSPEX SharePoint Server sizing tool............................................................................................. 101

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 5
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Sample tool to create large number of random documents .......................................................... 101
Sample tool to load documents into SharePoint........................................................................... 101
Sample code for SharePoint performance testing ......................................................................... 101
Others.......................................................................................................................................... 102

Appendix C: Sample storage designs and reference architectures ................................................... 103

Overview ...................................................................................................................................... 103
High-level steps for SharePoint farm sizing.............................................................................. 103
SharePoint Server 2013 topology and compute resource sizing ................................................... 103
Sizing web servers................................................................................................................... 103
Sizing application servers ....................................................................................................... 105
Sizing database servers .......................................................................................................... 107
Sizing storage layout .................................................................................................................... 107
Sizing content database pool .................................................................................................. 108
Sizing services pool................................................................................................................. 111
Sizing My Site pool .................................................................................................................. 112

Appendix D: Optimized setting in SQL Server for SharePoint ........................................................... 113

Appendix E: Scripts to break down items in the content database.................................................... 114

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 6
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Executive summary
In the planning and design phases of a Microsoft SharePoint Server infrastructure, it
is important to understand how the SharePoint collaboration platform across various
server roles interacts with the storage platform. It is also critical to know which
practices to follow to avoid bottlenecks and achieve best performance while
maintaining availability and protecting the content and configurations of the
SharePoint Server.

From a storage design aspect, SharePoint architecture and usage profile

characteristics may vary widely, depending on a common set of usage patterns,
database configuration, and content types. SharePoint Server 2013 storage
architecture introduces several infrastructure related changes:
 Server side disk input/output (I/O) pressure has been reduced significantly due
to the introduction of several new features, such as shredded storage,
minimum download strategy, and database schema update, which optimizes
multiple list items concurrently.
 SharePoint search service application has been redesigned. Its I/O
characteristics are different from previous search architectures, especially
those with larger write I/Os.
 In previous versions of SharePoint, social database features in a scaled
environment could present an I/O bottleneck. In SharePoint Server 2013, social
data is moved from a social database and now resides in the content database
of personal user sites.

EMC recommends you follow the best practices for SharePoint Server storage design
to take full advantage of the features of SharePoint Server and EMC technologies.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 7
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Introduction
Purpose The purpose of this document is to assist technology professionals and SharePoint
architects in designing the optimal infrastructure for SharePoint Server 2010 and
2013 using EMC® VNX® family storage, EMC Symmetrix® VMAX® series storage, EMC
XtremSF™, or EMC XtremCache™ in both physical and virtual environments.

Audience This white paper is intended for customers, EMC partners, and service personnel who
want to implement an intranet or internet web site environment with Microsoft
SharePoint Server or upgrade an earlier version of SharePoint Server. You should be
familiar with Microsoft SharePoint Server, EMC storage families such as VNX family
and Symmetrix VMAX; XtremSF and XtremCache; and VMware or Microsoft Hyper-V
virtual environments.

Scope Best practices documented in this white paper include sizing guidelines and design
examples based on EMC’s proven approaches. Details and end-to-end
implementation instructions are beyond the scope of this document.

Terminology This white paper includes the terminology listed in Table 1.

Table 1. Terminology

Term Definition
Enterprise multi-level cell Enterprise multi-level cell. Multi-level cells designed for
(eMLC) flash low error rates. A flash memory technology using multiple
levels per cell to allow more bits to be stored using the
same number of transistors.

Multi-level cell (MLC) flash A flash memory technology using multiple levels per cell
to allow more bits to be stored using the same number of
transistors.

Multipath I/O Multiple paths between the CPU in a computer system

and its mass storage devices that achieve fault-tolerance
and enhance performance.

NAS Network-attached storage, a network-based computer

data storage system.

RAID Redundant array of independent disks. A method for

storing information where the data is stored on multiple
disk drives to increase performance and storage capacity
and to provide redundancy and fault tolerance.

SAN Storage area network, an architecture that attaches

computer storage remotely and connects servers with
Fibre Channel (FC).

Single-level cell (SLC) flash A type of solid state storage (SSD) that stores one bit of
information per cell of flash media.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 8
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Term Definition
Storage pool Storage pools are virtual constructs that enable data to
move dynamically across different tiers according to the
data’s business activity. With VNX and VMAX systems,
storage pools are fully automated and self-managing.

SQL Server 2012 AlwaysOn Refers to the comprehensive high availability and disaster
recovery solution for SQL Server 2012. AlwaysOn presents
new and enhanced capabilities for both specific
databases and entire instances, providing flexibility to
support various high availability configurations.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 9
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Microsoft SharePoint Server farm architecture
Microsoft products Microsoft SharePoint Server
Microsoft SharePoint Server provides a business-collaboration web application
platform for enterprise and commercial organizations.

Microsoft SharePoint Server 2013 is a framework for sharing ideas, content, and the
vision of the customer’s company. SharePoint Server 2013 can be scalable enough to
organize and manage all information assets. It is designed to organize and store
documents, which enables personal productivity and keeps teams synchronized and
projects on track. Using SharePoint Server 2013, you can find experts, share
knowledge, connect to people, and find information. For developers, SharePoint
Server 2013 is a hub to build and deploy modern applications. SharePoint Server
2013 is built with the cloud in mind, which enables Information Technology
professionals to manage costs and compliance risks.

Microsoft SharePoint Server 2010 is the previous release of SharePoint Server 2013.
It provides a business-collaboration platform for enterprise and commercial
organizations.

Microsoft SQL Server

SharePoint Server 2010 and 2013 use a Microsoft SQL Server database backend to
store content and SharePoint configurations. For both SharePoint Server 2010 and
2013, 64-bit SQL Server is required.

Microsoft Windows Server

SharePoint Server 2013 is supported on the following:
 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard,
Enterprise, or Data Center
 64-bit edition of Windows Server 2012 Standard or Data Center

Server Core installation of Windows and Web Edition is not supported.

SharePoint Server 2010 is supported on the following:

 64-bit edition of Windows Server 2008 Standard, Enterprise, Data Center, or
Web Server with SP2
 64-bit edition of Windows Server 2008 R2 Standard, Enterprise, Data Center, or
Web Server
 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard,
Enterprise, Data Center, or Web Server

SharePoint Server 2010 with Service Pack 2 offers support for Windows Server 2012.
Refer to the SharePoint 2010 support for Windows Server 2012 portal for more
information.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 10
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Topology overview Designing or implementing a SharePoint farm is similar to designing or implementing
a SharePoint topology. A SharePoint farm is made up of logical and physical
components.

SharePoint logical SharePoint contains the following components which form the logical architecture:
architecture
SharePoint farm
A SharePoint farm is a set of one or more server computers working together to
provide SharePoint foundation functionality to clients.

Web application
At a physical level, a web application is a collection of one or more Microsoft Internet
Information Server (IIS) websites configured to map incoming Hypertext Transfer
Protocol (HTTP) requests to a set of SharePoint sites. SharePoint foundation is built
on top of IIS and relies on IIS websites to handle incoming HTTP requests. An IIS
website provides an entry point into the IIS web server infrastructure. SharePoint
foundation creates an abstraction on top of IIS that is known as a web application.

Content database
The web application maps each SharePoint site to one or more specific content
databases. SharePoint uses content databases to store site content such as list
items, documents, and customization information.

Service application
Service applications provide SharePoint functionality to other web and service
applications in the farm. Service applications facilitate the sharing of resources
across sites running in different web applications and different farms. The service
application architecture enables the scaling of a SharePoint farm by offloading
processing cycles from the front-end web servers to dedicated application servers.

Site collection
A site collection is a container of sites. Each site must be created within a site
collection.

Site
A site is defined as follows:
 An endpoint that is accessible from across a network such as the Internet, an
intranet, or an extranet.
 A storage container that allows users to store and manage content, such as list
items and documents.
 A customizable entity that allows privileged users to add pages, lists, and child
sites.
 A securable entity whose content is accessible to a configurable set of users.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 11
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Lists and libraries
Lists and libraries are stored in SharePoint sites. A list is a collection of pieces of
information. A library is a special list that each item in the list refers to a file.

The SharePoint containment hierarchy is described in Figure 1.

Figure 1. SharePoint containment hierarchy

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 12
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint A SharePoint environment consists of physical components with multiple server
physical roles, which are combined into units called farms. The SharePoint Server 2010 and
architecture 2013 farm includes the following three-tier server roles:
 Web server role—Responsible for the actual SharePoint pages that a user
views. A web server hosts web pages, web services, and the web functionality
that is required to process requests from users. The web server directs these
requests to the application server, which returns the results back to the web
server.
 Application server role—Runs all the SharePoint application services, including
index crawling and search query services. This server also hosts the SharePoint
Central Administration website. You can add application servers to host
services that can be deployed to a single server to be used by all the servers in
a farm. Services with similar usage and performance characteristics can be
logically grouped on a server and, if necessary, hosted on multiple servers if a
scale out is required to respond to performance or capacity requirements.
 Database server role—Runs the SharePoint databases, including the content
databases, configuration database, and search databases.

SharePoint farm The topology for a SharePoint farm can vary widely depending on the following key
topology factors:
 Scale size—Reflects the size of the total content and the active users accessing
the SharePoint web applications from time to time. Refer to Farm topology with
different scale sizes for details.
 Business purpose—Reflects the workloads and the general uses that
differentiate architectures, such as search and user profile architectures. For
example, some customers use the search function in SharePoint to establish a
search portal for business cases, while others only use SharePoint to manage
large numbers of documents. Refer to Farm topology with different search
architectures and Farm topology with different user profile architectures for
details.

Farm topology with different scale sizes

The farm topology can be both physical topology and virtual topology. Virtualized
topologies include both SharePoint components and hypervisors. Virtual topologies
depend on the capacity of physical hosts, the number of hosted virtual machines,
and the underlying virtualization technology.

SharePoint topologies include the service, server role distribution among servers, and
farm scale.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 13
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Table 2 illustrates the general scale of the SharePoint farm topologies.

Note: Size and design of SharePoint farm topology varies according to the business needs of
the customer.

Table 2. SharePoint farm general size scale

Configured
Server
Topology scale user or item General purpose
count
numbers
Limited deployment < 10,000 1~2 Product evaluation, deployment and testing, or
environments that have a limited number of users
and do not require fault-tolerance.

Small farm 10,000– 3~4 Small farm architectures serve a larger number of
20,000 users and scale out based on how heavily
services are used. Not all small farms are fault-
tolerant.

Medium farm > 30,000 or 6+ Medium farm architectures can be multipurpose

content up or optimized for specific purposes. Medium-size
to 40 million farms are fully fault-tolerant.
items Some environments might require more web
servers. Factor 10,000 users per web server as a
starting point.

Large farm > 50, 000 or 10+ Large farm architectures are scaled out to group
content up service applications, services, or databases with
to 100 similar performance characteristics onto
million items dedicated servers and then scale out the servers
as a group.

Note: To calculate the number of items for different types of content databases, use the
scripts in Appendix E: Scripts to break down items in the content database.

“Configured user number” is the total number of users in the SharePoint farm. The
Content database I/O and capacity characteristics section discusses the active user
number. “Active user number” is the average number of concurrent users visiting the
SharePoint farm at any point-in-time. The number of active users can be calculated as
the formula below:

The information in Table 2 applies to both SharePoint Server 2010 and 2013.

To design the distribution of services and server roles, the customer must provide
their requirements, such as number of users, farm capacity, services that will be used,
and how they will use the service. Refer to the topology sizing details for SharePoint
Server 2010 and 2013 in Appendix C: Sample storage designs and reference
architectures.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 14
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Farm topology with different search architectures
Search architecture in SharePoint Server 2010
Search in SharePoint Server 2010 is redesigned from Microsoft Office SharePoint
Server 2007 with new components to create better redundancy and better scalability.

Components in SharePoint Server 2010 can be divided into two categories:

 Query architecture—Includes the following components:
 Index partitions—Logical portion of the entire index. The index is the
aggregation of all index partitions.
 Query components—Components that process search results for their own
portions of the index. A mirror for each query component can be created.
Add a query component mirror to a different server to achieve redundancy
of the query partition.
 Property databases—Storage of the metadata and security descriptors for
the items in the index. They are involved in property based queries and
return standard document attributes for all query results.
 Crawl architecture—Includes the following components:
 Crawl components (crawler)—Searches content based on what is specified
in the crawl databases. Each crawler is associated with one crawl database.
Add crawlers to address capacity requirements and to increase search
performance.
 Crawl databases—Stores the crawl history and manages crawl operations.
Each crawl database can have one or more crawlers associated with it.
 Property databases
 Query server—Server hosting the components of the query architectures.
 Crawl server—Server hosting crawl components.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 15
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 2 shows an example of the typical search architecture with backend storage in
SharePoint Server 2010.

Figure 2. Typical search architecture in SharePoint Server 2010

For more information, refer to Search Technologies for SharePoint 2010 Products
technical diagram.
Search architecture in SharePoint Server 2013
In SharePoint Server 2013, Microsoft has fully integrated its highly scalable FAST
Search product. SharePoint Server 2013 search capabilities include:
 Metadata extraction, visual search, and advanced linguistics
 Content and analytics processors that are added to the logical architecture
 Search-related components managed by a specialized search administrator
 A dedicated analysis engine which performs both search and usage analytics

The search architecture is divided into the following components:

 Crawl component—Collects crawled properties and metadata from crawled
items and sends this information to the content processing component.
 Content processing component—Transforms the crawled items and sends them
to the index component. This component also maps crawled properties to
managed properties and interacts with the analytics processing component.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 16
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  Analytics processing component—Analyzes the crawled items and the methods
that users use to interact with the search results. The analyses are used to
improve the search relevance and to create search reports as well as
recommendations.
 Index component—Receives the processed items from the content processing
component and writes the items to the search index. This component also
handles incoming queries, retrieves information from the search index, and
sends back the result set to the query processing component.
 Query processing component—Analyzes incoming queries, which helps to
optimize precision, recall, and relevance. The queries are sent to the index
component, which returns a set of search results.
 Search administration component—Runs the system processes for search and
also adds and initializes new instances of search components.

The following databases are created to support these search components:

 Crawl database—Stores tracking information and details about crawled items
such as documents and uniform resource locators (URLs). Also stores
information such as the last crawl time, the last crawl ID, and the type of update
(add, update, delete) during the last crawl.
 Link database—Stores unprocessed information that is extracted by the
content processing component and information about search clicks. The
analytics processing component analyzes this information.
 Analytics reporting database—Stores the results of usage analysis, such as the
times an item has been viewed. It also stores statistics from different analysis.
These statistics are used to create the usage reports.
 Search administration database—Stores the settings for the search service
application, such as the crawl rules, topology, query rules, and the mapping
between crawled and managed properties.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 17
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 3 shows an example of the SharePoint Server 2013 typical search topology.

Figure 3. Typical search architecture in SharePoint Server 2013

For more information, refer to SharePoint Server 2013 Search technical diagram.

Farm topology with different user profile architectures

A user profile is a collection of properties that describes a single user and the policies
and other settings associated with each property. The set of user profiles for a
SharePoint Server 2010 and 2013 farm is stored in the profiles database associated
with the user profile service application.

When you create a user profile service application, SharePoint Server creates three
types of databases for storing user profile information and associated data:
 Profile database—Stores user profile information.
 Synchronization database—Stores configuration and staging information for
synchronizing profile data from external sources such as the Active Directory
Domain Services.
 Social tagging database—Stores social tags and notes created by users. Each
social tag and note is associated with a profile ID.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 18
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Other SharePoint Table 3 shows two typical SharePoint use profiles that describe how the SharePoint
related concepts workload includes various user activities.
Table 3. Use profiles

Use profile Description

Publishing Portal A starter site hierarchy that can be used for an
Internet site or a large intranet portal. The site
includes a home page, a sample press releases
site, a search center, and a log-in page. Typically,
this site has many more readers than
contributors, and it uses approval workflows to
publish the web pages.

Document Management Portal A site on which you can centrally manage and
collaborate on documents in your enterprise.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 19
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint I/O and capacity characteristics
Understanding the characteristics of I/O in SharePoint is useful in determining
deployment requirements for any given workload and designing and sizing a
SharePoint farm. A well-performing I/O subsystem is a critical component in any
SharePoint farm.

This section focuses on SharePoint I/O and capacity characteristics.

Content database Content database I/O and capacity characteristics vary among different workload
I/O and capacity types. The following sections focus on two workload types:
characteristics  Publishing Portal—The most common workload type, used mostly for browsing
operations mixed with slight document operations and searches.
 Document Management Portal—Another common workload type, used for
document operations.

I/O characteristics and capacity for content database in SharePoint Server 2010
Publishing Portal I/O characteristics
In this workload, the content database host input/output operations per second
(IOPS) is determined by several factors—most importantly, the active user number.

The correlation between the content database host IOPS and the number of active
users is shown in Figure 4.

Figure 4. Correlation between content database IOPS and active user number for the
Publishing Portal in SharePoint Server 2010

Note: The correlation in Figure 4 is observed when the SQL server memory is 64 GB with
incremental crawl running every half hour.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 20
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
For example, if 5,600 active users access the Publishing Portal in SharePoint 2010,
the host IOPS for the content database is calculated as follows:

Table 4 shows the I/O characteristics for the content database.

Table 4. I/O characteristics for content database

Database name Read size (KB) Write size (KB) Read/write ratio
Content database 24 32 3:1

Document Management Portal I/O characteristics

Compared with the Publishing Portal, this workload generates more IOPS over the
content databases. The correlation between the content database host IOPS and the
number of active users is shown in Figure 5.

Figure 5. Correlation between content database IOPS and active user number for
Document Management Portal in SharePoint Server 2010

Note: The correlation in Figure 5 is observed when the SQL Server memory is 64 GB with
incremental crawl running every half hour.

For example, if 3,600 active users access the Document Management Portal in
SharePoint 2010, the host IOPS for the content database is calculated as follows:

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 21
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 5 shows the content database characteristics for the Document Management
Portal.
Table 5. Content database characteristics for Document Management Portal

Database name Read size (KB) Write size (KB) Read/write ratio
Content database 24 32 2:1

To calculate host IOPS for the content database, refer to the examples in Formula to
size content database.

Capacity characteristics of SharePoint Server 2010 content database

For more information about the capacity of content database, refer to Storage and
SQL Server capacity planning and configuration.

I/O characteristics and capacity for content database in SharePoint Server 2013
Publishing Portal I/O characteristics
The correlation between the content database host IOPS and the number of active
users is shown in Figure 6.

Figure 6. Correlation between content database IOPS and active user number for
Publishing Portal in SharePoint Server 2013

Note: The correlation in Figure 6 is observed when the SQL server memory is 32 GB with
incremental crawl running every half hour.

For example, if 8,000 active users access the Publishing Portal in SharePoint 2013,
the host IOPS for the content database is calculated as follows:

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 22
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The I/O characteristics for the content database are shown in Table 6.
Table 6. Content database I/O characteristics for Publishing Portal

Database name Read size (KB) Write size (KB) Read/write ratio
Content database 24 32 3:1

Document Management Portal I/O characteristics

The correlation between the content database host IOPS and the number of active
users is shown in Figure 7.

Figure 7. Correlation between content database IOPS and active user number for
Document Management Portal in SharePoint Server 2013

Note: The correlation in Figure 7 is observed when the SQL server memory is 32 GB with
incremental crawl running every half hour.

For example, if 4,000 active users access the Document Management Portal in
SharePoint 2013, the host IOPS for the content database is calculated as follows:

Table 7 shows the I/O characteristics for the content database.

Table 7. Content database I/O characteristics for Document Management Portal

Database name Read size (KB) Write size (KB) Read/write ratio
Content database 24 32 2:1

To calculate host IOPS for the content database, refer to the examples in Formula to
size content database.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 23
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Summary of I/O characteristics of content database
Table 8 summarizes the I/O characteristics of the content database in two versions of
SharePoint with different use cases.

Table 8. Summary of I/O characteristics of content database

Read size Write size Read/write

Product Use case Host IOPS
(KB) (KB) ratio
SharePoint Publishing Portal 24 32 3:1
Server
2010 Document 24 32 2:1
Management Portal

SharePoint Publishing Portal 24 32 3:1

Server
2013 Document 24 32 2:1
Management Portal

Note: In Table 8, y represents the host IOPS while x represents the active user number.

Capacity characteristics of SharePoint Server 2013 content database

For more information about the capacity of content database, refer to Storage and
SQL Server capacity planning and configuration.

Content database I/O characteristics with RBS

The Remote BLOB Storage (RBS) feature enables SharePoint Server 2010 or 2013 to
store binary large objects (BLOBs) in a location outside the content databases.
Storing the BLOBs externally can reduce the required SQL Server database storage
space. The metadata for each BLOB is stored in the SQL Server database and the
BLOB is stored in the RBS store.

Because content databases store only the metadata of the BLOBs, the majority of the
I/O happens in the BLOBs store, not in the content database.

Table 9 shows the I/O characteristics when RBS is enabled.

Table 9. I/O characteristics for RBS

Name Read size (KB) Write size (KB) Read/write ratio

Content database 8 8 Read dominant
with RBS enabled

BLOB store 40 8 Read dominant

Search and user Search service and user profile service are commonly used service applications in
profile service SharePoint. Table 10 and Table 11 list the details of the I/O characteristics of these
application I/O two application services in SharePoint Server 2010 and 2013 when running crawl and
and capacity user profile synchronization.
characteristics

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 24
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Table 10. Search and user profile service application I/O and capacity characteristics in
SharePoint Server 2010

Service Read Write

Database or Read/write
application IOPS size size Capacity
component name ratio
name (KB) (KB)
Content database Read: High 8 N/A All read N/A
Write: Zero

Crawl database Read: High 8 96 6:1 0.046 data set

Write: Low size

Property database Read: 0 8 From N/A 0.15 data set

Write: High 16 to size
Search service 96
application Search Read: 0 32 8 N/A 10 GB
administration Write: 0
database

Crawl component Read: 0 32 64 Write 1 GB for 100 GB

Write: Low dominant data set

Query component Read: Low 32 128 Write 2 GB for 100 GB

Write: Low dominant data set

Synchronization Read: 0 64 32 Write 630 KB per user

database Write: Low dominant profile

User profile Profile database Read: 0 64 16 Write 1 MB per user

service Write: High dominant profile
application
Social database Read: 0 N/A N/A N/A 0.009 MB per tag,
Write: 0 comment or
rating

Table 11. Search and user profile service application I/O and capacity characteristics in
SharePoint Server 2013

Service Database or Read Write

Read/write
application component IOPS size size Capacity
ratio
name name (KB) (KB)
Content Read: High 8 N/A All read N/A
database Write: Zero

Search Crawl database Read: Medium 8 32 3:1 10 million items: 15

service Write: Medium GB for data, 2 GB for
application log
100 million items:
110 GB for data, 2 GB
for log

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 25
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Service Database or Read Write
Read/write
application component IOPS size size Capacity
ratio
name name (KB) (KB)
Link database Read: 0 8 64 N/A 10 million items: 10
Write: 0 GB for data, 0.1 GB for
log
100 million items: 80
GB for data, 5 GB for
log

Search Read: 0 64 8 N/A 10 million items: 0.4

administration Write: 0 GB for data, 0.1 GB for
database log
100 million items: 1
GB for data, 2 GB for
log

Analytics Read: 0 8 N/A N/A Usage dependent

reporting Write: 0

Crawler Read: 0 4 128 Write 1 GB for 100 GB data

Write: 115 dominant set

Index partition Read: Medium 2048 1024 3:2 2 GB for 100 GB data
Write: Low set

Synchronization Read: 0 64 32 Write 2.5 MB per user

database Write: Low dominant profile

User profile Profile database Read: 0 64 32 Write 1 MB per user profile

service dominant
application Write: Low

Social database Read: 0 N/A N/A N/A 0.018 MB per tag,

Write: 0 comment or rating

For analysis details, refer to Appendix A: I/O characteristics analysis for SharePoint
Server 2010 and 2013 search and user profile service application.

Other service The storage and IOPS for all of the service applications in SharePoint Server 2013
application I/O remain the same as in SharePoint Server 2010 except for the search service
and capacity application and the user profile service application, which are the most common
characteristics service applications. For more information, refer to Storage and SQL Server capacity
planning and configuration.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 26
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint Server hypervisor best practices
Overview General virtualization considerations
SharePoint Server 2010 and 2013 are fully supported in a virtual environment that is
supported by Microsoft Hyper-V technology or VMware vSphere ESXi technology. This
section discusses the best practices and design guidelines for SharePoint Server
2010 and 2013 virtualization consideration and the compute resource for each role.

Organizations increasingly want to virtualize their modern multi-tiered application—

SharePoint. The latest release, SharePoint 2013, has been redesigned to better suit
virtualization requirements.

The main merits of virtualizing SharePoint farm servers include:

 Easily scalable topology—Business needs and use of a SharePoint farm evolves
with time. Virtualized SharePoint farm allows you to easily add or remove
specific server roles from the farm to accommodate the changes.
 Flexible resource allocation—Easily and quickly adjusts the CPU and memory to
address the spikes in the usage of a specific virtualized SharePoint server. The
spikes can be predicted.
 Easy to maintain—Most companies have multiple SharePoint environments,
such as test, development, and training, to make sure the development and
setting changes to the production environment are safe. As configuration drift
happens frequently, over time, these systems often fall out of synchronization
with production systems, resulting in inaccurate testing and quality assurance
(QA) cycles, or even worse, down time. With hypervisors, you can create
snapshots or clones of a virtualized SharePoint environment to achieve high
efficiency and safe maintenance.
 Cost savings—Virtualization makes the best use of server hardware
investments by consolidating workloads as separate virtual machines.

Virtualizing farm server roles

This section discusses the compute resource allocation of the SharePoint server roles:
 Web servers
 Application servers
 SQL servers

The web server and application server roles are usually the first choices for
virtualization.

Virtual machines for web server roles can be configured to use fewer processors, less
memory and fewer (and smaller) hard disks. The web server role also enables you to
adjust the compute resources to meet burst performance requirements and is easier
to plan for virtualization than other roles. It has the lowest virtualization host
requirements and the lowest risk in a production environment.

Application servers are also initial candidates for virtualization. Depending on the
degree of specialization, which is reflected by services they provide, application

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 27
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
servers do not always have low resource requirements. A good example is an
application server that hosts the search crawl component.

Conventional wisdom dictates that SQL Server instances not be virtualized. Using
Microsoft Hyper-V and VMware vSphere 5.0 with increased scalability and
performance capabilities, customers can now virtualize tier 1, mission-critical SQL
Server workloads. EMC has proved that virtualized SQL Server can meet critical
business performance and security needs.

Note: The business requirements of SharePoint farms can vary, leading to different compute
resource allocations for the farm virtual machines.

Virtualizing web servers

In performance testing, we1 found that the CPU is typically the first bottleneck for a
web server because of the nature of the work carried out by the web server.

Table 12 and Table 13 include the recommended compute resources for virtualized
web servers.

Table 12. Resource recommendation for web server in SharePoint Server 2010

Compute resource for web server Resource recommendation

vCPU 4 cores

Memory 4 GB

Table 13. Resource recommendation for web server in SharePoint Server 2013

Compute resource for web server Resource recommendation

vCPU 4 cores

Memory 12 GB

Virtualizing application servers

Virtualized application servers usually have low resource requirements. However, at
times their resource requirements may increase. A good example is an application
server that hosts the search crawl component.

Table 14 and Table 15 include the recommended number of vCPUs and memory for
virtualized application servers.

Table 14. Resource recommendation for application server in SharePoint Server 2010

Purpose of the application server Resource recommendation

Application server vCPU 4 cores

Memory 4 GB

1
In this white paper, "we" and “our” refers to the EMC Solutions engineering team that
validated the solution

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 28
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 15. Resource recommendation for application server in SharePoint Server 2013

Purpose of the application server Resource recommendation

Application server with search crawler vCPU 12 cores

Memory 12 GB

Application server with other service vCPU 4 cores

applications
Memory 12 GB

Virtualizing SQL servers

The role of the SQL Server instance is storing, maintaining, and returning data to the
other roles in the farm. This role has the highest amount of disk I/O activity and often
has high memory and processor requirements. The SQL Server can migrate to a
higher-powered server or provide greater resourcing through virtualization.

With virtualized SQL Server, it is easy to scale SQL Server roles vertically or
horizontally in any SharePoint farm as required.

Table 16 and Table 17 include the recommended number of vCPUs and memory for
different ranges of total users of virtualized SQL Server.

Table 16. Resource recommendation for SQL Server in SharePoint Server 2010

Combined size of content databases Recommended number of vCPUs for SQL Server
Up to 1 TB vCPU 4 cores

Memory 8 GB

1 TB to 5 TB vCPU 8 cores

Memory 32 GB

Table 17. Resource recommendation for SQL Server in SharePoint Server 2013

Total number of users Recommended number of vCPUs for SQL Server

Less than 1,000 users vCPU 4 cores

Memory 8 GB

Between 1,000 and 10,000 users vCPU 8 cores or 16 cores

Memory 16 GB

EMC recommends that you place only one SQL Server virtual machine per physical
hypervisor server to avoid the whole farm becoming inoperable in the event of host
failure. Server roles distribution provides details on distributing SharePoint server
roles among hypervisors.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 29
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Server roles distribution
EMC recommends the distribution of server roles as follows:
 Each hypervisor host should contain different farm server roles if possible—
Mixing SharePoint server roles that share the same hypervisor host maximize
the overall throughput. For example, mixing of web servers and application
servers reduces disk contention, because they usually do not write to disk at
the same time.
 Each kind of server role should be spread across different hypervisor hosts if
possible—For redundancy considerations, spread web servers, application
servers, and database servers across different hosts, if possible. To achieve
this you can implement Anti-Affinity rules in both Microsoft Hyper-V and
VMware vSphere to keep related SharePoint virtual machines separate on hosts
within a cluster. For details refer to Best Practices for Virtualizing & Managing
SharePoint 2013 and VMware vSphere 5.1 Documentation Center.
Hypervisor virtual networking
Each hypervisor host should have multiple connections to the user and storage
Ethernet networks to guard against link failures. The connections should be
separated across multiple Ethernet switches to guard against component failure in
the network.

Regarding the details of networking design, refer to:

 VMware Network Virtualization Design Guide when using VMware vSphere.
 Configuring Virtual Networks when using Microsoft Hyper-V.

VMware vSphere VMware vSphere is the leading virtualization hypervisor used across thousands of IT
best practices environments around the world. Virtualizing SharePoint Server on VMware vSphere is
commonly used in enterprises. This section introduces best practices of virtualizing
SharePoint Server 2010 and 2013 on VMware vSphere.

VMware VMFS versus VMware RDM best practices

VMware Virtual Machine File System (VMFS) is a high-performance cluster file system
that provides storage virtualization optimized for virtual machines. VMware raw
device mapping (RDM) allows a special file in a VMFS volume to act as a proxy for a
raw device.
VMFS is suitable in most cases, while RDM is the only option for the following three
scenarios:
 Migrating an existing application from a physical environment to a virtual
environment
 Using Microsoft Windows Server Failover Clustering (WSFC) for clustering in a
virtual environment
 Using storage area network (SAN) management tasks for specific needs such as
snapshots

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 30
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
VMFS and RDM provide similar performance. For SharePoint, EMC recommends you
use VMFS for performance and management considerations and to provision multiple
virtual disks with similar I/O characteristics in the same VMFS datastore.
EMC recommends considering the following scenarios to use RDM for SharePoint:
 Create a virtual disk over 2 TB to host a SharePoint content database. For
VMware vSphere 5.0 and 5.1, 2 TB is the size limit for a single VMware virtual
machine disk (VMDK) file.
 Use EMC Replication Manager for SharePoint protection and recovery.

VMware DRS best practices

VMware Distributed Resource Scheduler (DRS) dynamically balances computing
capacity across a collection of hardware resources aggregated into logical resource
pools. VMware DRS also continuously monitors utilization across resource pools and
intelligently allocates available resources among the virtual machines based on pre-
defined rules that reflect business needs and changing priorities.

VMware has published the DRS Performance and Best Practices white paper. The best
practices introduced in this paper apply to SharePoint Server 2010 and 2013
virtualized environment.
When using VMware DRS, monitor the VMware DRS status regularly, and adjust virtual
machine deployment among hosts according to business needs.
VMware HA best practices
VMware High Availability (HA) provides easy-to-use, cost-effective high availability for
all applications running on virtual machines. In the event of server failure, affected
virtual machines are automatically restarted in the cluster on other host machines
that have spare capacity. VMware HA minimizes downtime and IT service disruption
while eliminating the need for dedicated standby hardware and installation of
additional software. VMware HA provides high availability across the entire
virtualized IT environment without the cost and complexity of failover solutions tied to
either OSs or specific applications.

All general VMware HA best practices apply to the SharePoint environment. Refer to
the following VMware papers for more information about the VMware HA best
practices:
 VMware vSphere High Availability 5.0 Deployment Best Practices
 Automating High Availability (HA) Services with VMware HA

VMware vSphere networking best practices

General networking best practices for VMware VSphere also apply to a SharePoint
virtual environment. For details refer to Best Practices for Virtual Networking.
EMC recommends ensuring no more than 1 ms of latency between web servers,
application servers, and SQL Server instances to achieve robust performance of the
whole SharePoint farm.
If you are using network-attached storage (NAS) for RBS, make sure the connection to
the EMC storage responds to a ping within 1 ms and returns the first byte of data
within 20 ms.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 31
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
EMC VSI best practices
EMC Virtual Storage Integrator (VSI) for VMware vSphere is a plug-in to VMware
vCenter that provides a single interface for managing EMC storage within the vSphere
environment. EMC VSI for VMware vSphere can provision network file system (NFS)
datastores on NAS and VMFS datastores, and provision RDM volumes on block
storage. It can also perform array-based compression and array-based cloning of
virtual machines in NFS datastores and array-based compression in VMFS datastores
and RDM volumes. The cloning functions include full clones (copies), fast clones
(snaps), and native clones of VMDK files. VMware administrators can also use it to
manage NAS and block storage in VMware environments that use the existing
vSphere Client user interface. Figure 8 shows the VSI in the vSphere Client interface.

Figure 8. VSI in VMware vSphere client

Refer to the following two documents for detailed information:

 EMC VSI for VMware vSphere Unified Storage Management Product Guide
 EMC VSI for VMware vSphere Web Client Product Guide

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 32
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Microsoft Windows Microsoft Windows Server 2012 with Hyper-V (Microsoft Hyper-V for short) is a good
Server 2012 with virtualization platform that can be used for deploying demanding and multi-tiered
Hyper-V best production applications, such as SharePoint. This section discusses the best
practices practices for virtualizing SharePoint on Microsoft Hyper-V.

General best practices

EMC recommends the following general best practices for Microsoft Hyper-V:
 Use the 1:1 recommended ratio of virtual processor to logical processor for any
virtual machine in a SharePoint farm. Oversubscribing the CPU on the
virtualization host can decrease performance, depending on how much the CPU
is oversubscribed.
 Do not use Dynamic Memory on any SharePoint Server 2013 virtual machines
because certain features of SharePoint can suffer from performance
degradation when Dynamic Memory is enabled. For example, the cache size for
the search and distributed cache features is not resized when the memory
allocated to the virtual machine is dynamically adjusted.
 Install the latest virtual machine integration services in each supported guest
virtual machine. Virtual machine integration services help improve I/O
throughput and decrease the overall CPU usage of guests because they include
drivers for Microsoft Hyper-V-specific I/O devices that reduce CPU overhead for
I/O.
 Disable the Microsoft Hyper-V Time Synchronization service on each SharePoint
virtual machine. SharePoint Server 2013 uses timer jobs frequently and the
latency during time synchronization causes unpredictable results in the
SharePoint environment. Instead, ensure that your guest virtual machine’s OS
retrieves its time from an authoritative time source, such as a domain controller.
 Do not configure a SharePoint virtual machine to save its state when shutting
down. Virtual machines that start from a saved state are out of synchronization
with the other servers in the farm. We recommend that you configure the virtual
machine to use a shutdown as its automatic stop behavior. This minimizes the
chances of the virtual machines being corrupted. When a physical host
shutdown happens, all running timer jobs finish and no synchronization issues
occur when the virtual machine restarts.

Microsoft Hyper-V storage options best practices

VHD and VHDX
The Microsoft virtual hard disk (VHD) format is a common virtualization file format. It
provides a uniform product support system, as well as more seamless manageability,
security, reliability and cost-efficiency for customers.
VHDX file format is a new version of VHD introduced with Windows Server 2012.

Best practices for VHD and VHDX are as follows:

 When using Windows Server 2012, we recommend converting all VHD files to
VHDX format. The only exception is when a virtual machine might be moved to a
previous release of the Windows Server OS that supports Microsoft Hyper-V. In
that case, it makes sense to keep the files in VHD format.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 33
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  For SharePoint Server 2010 and 2013, use VHDX (on Windows Server 2012) or
VHD (on Windows Server 2008 R2). The capacity advantage better aligns with
stronger protection against corruption, making it an ideal choice for key and
mission-critical workloads.
 Avoid differentiating disks and dynamically expanding disks in a virtualized
SharePoint environment.

CSV
Failover clustering provides an extra level of resiliency for SharePoint when compared
with a physical implementation.

Cluster Shared Volume (CSV), a feature available with WSFC and Microsoft Hyper-V
2012 and later, simplifies the configuration and management of clustered virtual
machines. With CSV, multiple clustered virtual machines can use the same LUN (disk)
while maintaining the ability to fail over (or move from node to node) independently.

All nodes of a failover cluster can access volumes that are configured as CSVs. Each
node can open and manage files on the volumes. Therefore, different nodes hosting
different virtual machines can have files on the same volume.

On a failover cluster that uses CSV, Microsoft Hyper-V stores and accesses the files
used for clustered virtual machines by using the \ClusterStorage path on the system
drive. For example, on a node that runs the OS from the C drive, the path is
C:\ClusterStorage\.

Best practices for CSV are as follows:

 Store only the files that are created for the Microsoft Hyper-V role (such as VHD)
on CSV. The creation, reproduction, and storage of files on CSV that were not
created for the Microsoft Hyper-V role, including any user or application data
stored under the ClusterStorage folder of the system drive on each node, are
not supported and might result in unpredictable behavior, including data
corruption or data loss on these shared volumes.
 For easier management, rename the volume folder name. However, you cannot
rename the ClusterStorage folder.

Pass-through disks
Pass-through disks were a popular option prior to the release of Windows Server
2012. The VHD format used by Microsoft Hyper-V was limited to 2 TB, which was
inadequate for some virtual machines. Pass-through disks were used as a way to
break the 2 TB capacity limit. In Windows Server 2012, Microsoft introduced the VHDX
format, which supports up to 64 TB of capacity.

Best practices for pass-through disks are as follows:

 Pass-through disks provide a slight performance improvement over virtual hard
drives only when massive amounts of I/O are required and limits of the
physical environment must be pushed.
 Do not use Storage Live Migrations in Microsoft Hyper-V with pass-through
disks.
 When using pass-through disks, EMC Replication Manager works.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 34
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Guest storage best practices
In addition to presenting VHD or VHDX files to the respective SharePoint virtual
machines, the administrator can choose to connect the guest OS of the SharePoint
virtual machines directly to existing storage. Two methods provided in Microsoft
Hyper-V allow you to use In-Guest Internet small computer system interface (iSCSI) or
virtual Fibre Channel (FC) to connect to the storage elements.

In-Guest iSCSI best practices

Instead of using virtual disks, such as the VHD or VHDX files discussed earlier, and
placing them on the iSCSI LUNs presented to the host, the administrator can choose
to bypass the host and connect the virtual machines directly to the iSCSI array itself.
The iSCSI target, part of the storage array itself, provides storage to the SharePoint
virtual machine directly over the virtual machine’s network adaptors. The SharePoint
virtual machine uses the in-box iSCSI initiator inside the Windows Server Guest OS to
connect to the storage over a virtual network interface card (vNIC) that has
connectivity on the iSCSI storage network. The respective SharePoint servers can
store their information, logs, and other critical data directly on iSCSI disk volumes.

Best practices for In-Guest iSCSI are listed as follows:

 If running the virtual machine with In-Guest iSCSI on top of a Microsoft Hyper-V
cluster, all cluster nodes must have the same iSCSI virtual switches created on
the hosts. This helps to ensure that when the virtual machines are migrating
around the cluster, connectivity to the underlying storage is not lost.
 For resiliency, the administrator can use multiple vNICs to connect the virtual
machine to the iSCSI SAN. In that case, it is important to enable and configure
Multipath I/O to ensure optimal performance and resiliency.
 In-Guest iSCSI can also be used to create guest failover clusters. In a
SharePoint environment, guest failover clusters could create a SQL Server 2012
AlwaysOn Availability Group, as a resilient backend for the SharePoint
databases.

Virtual FC best practices

Virtual FC for Microsoft Hyper-V helps to connect to FC storage from within a virtual
machine, bypassing the host OS. It provides the guest OS with unmediated access to
a SAN by using a standard World Wide Name associated with a virtual machine.
Microsoft Hyper-V users can now use FC SANs to virtualize workloads that require
direct access to SAN LUNs. FC SANs also allow you to operate in new scenarios, such
as running the Failover Clustering feature inside the guest OS of a virtual machine
connected to the shared FC storage.

As for In-Guest iSCSI, SQL Server 2012 AlwaysOn Availability Groups of failover
cluster instances can be created as a resilient backend for SharePoint Server 2013
databases.

For virtualizing SharePoint Server 2010 and 2013, virtual FC for Microsoft Hyper-V
allows you to use existing FC investments to drive the highest levels of storage
performance access, while also retaining support for virtual machine live migration
and Multipath I/O.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 35
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
High availability best practices
Keeping mission-critical data continuously available has become a requirement over
a wide range of customer segments from small business to datacenter environments.
Enterprise environments that use Windows Server require zero downtime for key
workloads, including file server, database, messaging, and other lines of business
applications. This level of availability can be difficult and costly to achieve, and it
requires that redundancy be built-in at multiple levels:
 Storage redundancy
 Backup to separate recovery servers
 Server clustering
 Redundancy of the physical path components between server and storage

Failover cluster best practices

A failover cluster is a group of independent computers that work together to increase
the availability and scalability of clustered roles (formerly called clustered
applications and services). The clustered servers (called nodes) are connected by
physical cables and by software. If one or more of the cluster nodes fail, other nodes
begin to provide service (a process known as failover). In addition, the clustered roles
are proactively monitored to verify that they are working properly. If they are not
working, they are restarted or moved to another node.

Failover clusters also provide CSV functionality that provides a consistent, distributed
namespace that clustered roles can use to access shared storage from all nodes.
With the WSFC feature, users experience minimal disruptions in service.

The aim of WSFC is to provide a resilient solution for SharePoint workloads that are
running on top of the cluster. For virtualized SharePoint, the clustered role is virtual
machines. For virtual machines running on top of a Hyper-V cluster, the virtual
machines experience downtime if a Hyper-V cluster node fails. However, the
remaining cluster nodes immediately start to work to bring the virtual machines up
again on an alternative node within the cluster. This ensures minimal downtime and
administrator intervention is not required. This supplies the SharePoint workload an
extra level of resiliency when compared with a physical implementation, in which the
administrator can only rely on application-level resiliency.

For more information about failover cluster, refer to Understanding Requirements for
Failover Clusters.

Multipath I/O best practices

In SharePoint Server 2010 and 2013, EMC recommends that you use:
 Multipath I/O (MPIO) software for the highest level of redundancy and
availability when connecting hosts to iSCSI or FC storage because Windows
Server 2008 R2 has native MPIO capabilities.
 PowerPath or PowerPath/VE for automated data path management, failover and
recovery, and optimized load balancing. Compared to Windows native MPIO,
PowerPath ensures best performance, selects the right optimized data path
algorithm automatically for data center environment, and does not have some
limitations that native MPIO has.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 36
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
For details of the comparison between PowerPath and Windows native MPIO, refer to
EMC PowerPath vs. Windows Native MPIO.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 37
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint storage sizing and provisioning
Storage design is one of the most important elements of a successful Microsoft
SharePoint deployment. This section discusses the guidelines for successful storage
design featuring optimal reliability, performance, cost, and ease of use.

General storage Performance versus capacity considerations

considerations When designing storage for SharePoint, separately calculate the number of disks
required to satisfy performance requirements and capacity requirements, and then
choose the larger number.

Note: You can use the VSPEX sizing tool to automatically complete the sizing calculation.
This tool implements the sizing logic in this section. It is easy to use and it saves time and
energy for the sizing calculations.

Disk types considerations

Flash disk, Serial Attached SCSI (SAS) disk, and Near-Line Serial Attached SCSI (NL-
SAS) disk are the three major types of hard disks used in storage arrays. Table 18
describes the three disk types.

Table 18. Drive type and match workloads

Drive type Characteristics Workload examples

Flash Flash drives have the highest I/O FASTTM Cache, Extreme Performance Fully
speed with low power Automated Storage Tiering for Virtual
consumption. Pools (FAST VP) Tier, best performance
for transactional random workloads

SAS An improvement over traditional General performance tier

small computer system interface
(SCSI) drives. SAS disks provide
high capacity with moderate I/O
speed.

NL-SAS As with Serial Advanced Well-behaved streaming, aging data and

Technology Attachment (SATA) archive purposes, and backups.
disks, NL-SAS disks are a good fit NL-SAS is used in capacity cost-effective
for the less demanding I/O implementations. It provides limited
requirements with large capacity. performance and has higher failure rate
than the other two types of disks. RAID 6
is recommended to guard against disk
failure.

For SharePoint specifically, we recommend the following best practices:

 Use flash disk in FAST VP first to ensure SharePoint benefits from the flash disk
investment.
 Use SAS disk for content and other databases and for data used in service
applications.
 Use NL-SAS for low-access content, such as My Site content.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 38
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Note: Social media content such as tagging, comments, and likes, are stored in a social
media database, so that feature performance is not affected.

Pools and RAID type considerations

EMC recommends using storage pools for virtualized SharePoint for the following
reasons:
 Storage pools support more number of disks than traditional RAID groups and
can:
 House heterogonous disk types; for example, flash, SAS, NL-SAS.
 House different RAID types; for example, RAID 10, RAID 5, and RAID 6.
 Use FAST Suite to improve performance or reduce cost.
 Use both thick and thin LUN types.
 Storage pools are extendable.

Table 19 compares RAID types for various disk types.

Table 19. RAID level performance characteristics

RAID
Random Random Sequential Sequential write Capacity
RAID level
read write read write overhead utilization
value
RAID 10 Excellent Excellent Excellent Excellent 2 Low

RAID 5 Excellent Moderate Good Moderate 4 High

RAID 6 Good Poor Good Moderate 6 Medium

The RAID level characteristics also apply to storage pools, because storage pools
internally are composed of one or more private RAID groups of disks.
SharePoint has three types of data with different I/O characteristics:
 Content databases—Medium IOPS requirement. However, when workload
becomes heavier, I/O requirements expand linearly with end user requests.
Disk read operations require more IOPS than write operations for content
databases. Refer to Content database I/O and capacity characteristics for
details.
 Service application databases and Index files for search—Increased IOPS
requirement when certain service applications run, such as crawling and
generating index files. For more information on I/O characteristics for search,
refer to Appendix A: I/O characteristics analysis for SharePoint Server 2010 and
2013 search and user profile service application.
 My Site databases—Low IOPS requirement. Capacity is the main concern. NL-
SAS with RAID 6 configuration can service these databases.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 39
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Choose the RAID type for each type of SharePoint data, as shown in Table 20.
Table 20. RAID types for SharePoint data

SharePoint data RAID type

Content databases data files RAID 5

Service application database, content database log files, RAID 10

and search index files

My Site databases RAID 6

LUN selection considerations

Pool LUNs are created within pools. A pool LUN can be either thick or thin. You can
determine whether to choose thick LUNs or thin LUNs for the SharePoint databases
and service application files using the criteria listed in Table 21.
Table 21. LUN selection criteria

Pool-based thin LUN Pool-based thick LUN

 Applications with moderate performance requirements  Applications that
 Advanced data services, such as FAST VP, VNX Snapshots, require good
compression, and deduplication performance

 Ease of setup and management  Ease of setup and

management
 Best storage efficiency
 Storage assigned to
 Energy and capital savings VNX for file
 Applications where space consumption is difficult to forecast

Using thin LUNs provides significant storage savings when deploying a large-content
SharePoint environment because you can create LUNs with the required user capacity
using less physical capacity in the storage array.

When creating pool LUNs for file, EMC recommends using thick LUNs. Refer to EMC
VNX Unified Best Practices for Performance White Paper.

Volume types considerations

Master boot record (MBR) disks use the standard Basic Input Output System partition
table. The partition table is only saved at the beginning of the disk.

Globally unique identifier partition table (GPT) disks use a unified extensible firmware
interface. Its partition table is saved in multiple locations. It can be easily recovered if
any partition is corrupted.

GPT disks have the following advantages:

 More than four partitions per disk.
 Suitable for disks larger than 2 TB.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 40
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Two types of disk modes are supported:
 Basic—Contains primary partitions and optional extended partitions.
 Dynamic—A native host-based logical volume manager, responsible for
aggregating disks into logical volumes with multiple options.

Table 22 describes the best practice for typical volumes created on EMC storage in a
SharePoint Server 2010 or 2013 environment.

Table 22. Typical SharePoint deployment for EMC storage

Volume partition Disk Volume Allocation size Formatting options

MBR Basic NTFS 64 KB Quick format

GPT (for larger Basic NTFS 64 KB Quick format

than 2 TB disks)

Note: Because the EMC array provides storage RAID protection, dynamic disks should be
avoided if possible because they complicate the management of storage and local and
remote disaster recovery. Quick format options are required for thin LUNs.

SharePoint Server 2010 requires Windows Server 2008 or later and SharePoint Server
2013 requires Windows Server 2008 R2 or later. On these versions of Windows,
partition alignment is usually performed by default. Partitions created on versions of
Windows earlier than Windows Server 2008 maintain the properties under which they
were created. That is, if partition alignment is not performed, these partitions are not
aligned. This could affect SQL Server performance, and therefore, SharePoint
performance. Refer to Disk Partition Alignment Best Practices for SQL Server for more
information.

NFS and SMB 3.0 considerations

Network file system (NFS) and Server Message Block (SMB) 3.0 are both network file
sharing protocols for NAS. Below are the file storage best practices for NFS and SMB
3.0.

File storage best practices

The recommended file system layout implements the following best practices:
 When the number of disks is set, the number of storage pools does not affect
file system performance.
 In order to spread I/O across all the disks in a storage pool, divide the number
of disks in the pool by four and round up to the nearest ten. The result is the
number of LUNs to create in the pool.
 Use Automatic Volume Management to create the file system to achieve
balance between performance and capacity.
 For versions of VNX OE for File earlier than 8.x, select Direct Writes Enabled so
that asynchronous writes can be written directly to the back end for better
performance.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 41
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  For versions of VNX OE for File 8.x or later, clear Direct Writes Enabled, because
the VNX OE for File cached I/O path has been enhanced to support parallel
writes.
 Set the parameter asyncUncachedOpt to 1 (true) on the Data Mover. If set to 1,
asynchronous writes to a file system mounted with the uncached option will be
written out without being buffered in cache. If set to 0, writes to a file system
mounted with the uncached option will be written out via the buffer cache. The
setting has no impact on file systems mounted without the uncached option.
Execute the following command to set the parameter:
server_param server_2 -facility file -modify asyncUncachedOpt
-value 1

NFS
NFS is a distributed file system protocol allowing a user on a client computer to
access files over a network the way local storage is accessed.

Best practices for NFS:

 VMDKs created on NFS datastores are in thin provisioned format by default.
 Isolate storage traffic from other networking traffic.
 Select No for network interface card (NIC) teaming failback option.

For more information, refer to the Best Practices for running VMware vSphere on
Network Attached Storage white paper.
SMB 3.0
SMB is based on the Common Internet File System protocol that the Microsoft
Windows OS uses for distributing file sharing, printing, and communication services
from a server over a network. SMB 3.0 protocol support is available with Windows
Server 2012. For detailed configuration of SharePoint over SMB 3.0, refer to EMC
Integration for Microsoft Private Cloud Using EMC VNX Unified Storage White Paper.
Best practices for SMB 3.0:
 Do not use a computer running Microsoft Hyper-V as the file server for virtual
machine storage. This forms a so-called “loopback” configuration which is not
supported by Microsoft Hyper-V.
 Use multiple network adapters to take advantage of SMB multichannel when
using SMB storage with Microsoft Hyper-V, as this provides increased
performance and resiliency.
 Make sure the continuous availability (CA) feature is enabled on both the
Windows server and the Data Mover.
For details on how to use the CA feature with VNX, refer to the EMC VNX Series:
Introduction to SMB 3.0 Support White Paper.
 Use a dedicated network between the SMB 3.0 server and the Data Mover.
 Test the CA and multichannel features during the deployment steps.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 42
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
RBS (file and block) considerations
One significant challenge all SharePoint users face is the requirement to store BLOBs
on the most expensive tier of storage (block) when alternative, less-expensive tiers of
storage (file) could be used. For example, file-based content such as PDFs, Microsoft
Office documents, and engineering drawings, are stored in SQL Server databases.
However, BLOBs can reside on a lower-cost tier of storage and still meet SLAs.

RBS is designed to move the storage of BLOBs from database servers to commodity
storage solutions. If the content databases in Microsoft SharePoint Server 2010 or
SharePoint Server 2013 are 4 TB or larger, and the contents are read intensive,
consider using RBS as part of your data storage solution.

RBS is composed of the following components:

 RBS client library
 RBS provider
 Local RBS provider—Stores BLOBs on the same server, for example SQL
FILESTREAM provider.
 Remote RBS provider—Stores BLOBs on a separate server.
 BLOB store

Metalogix StoragePoint is an example of a third-party solution that is a good choice

for both local and remote RBS providers. It is an easy-to-install RBS and archive
solution that allows you to consolidate and optimize SharePoint storage.
StoragePoint improves performance, scalability, and compliance requirements while
decreasing overall storage and administrative costs of the growing SharePoint
environment.

EMC recommends that you use well-established content management and content
externalization vendors to host your StoragePoint solution and ensure that you have
the flexibility to store unstructured SharePoint content on any tier of the storage
device, including SAN, NAS, and cloud storage platforms.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 43
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 9 shows an example of the reference architecture of using Metalogix
StoragePoint with SharePoint.

Figure 9. Sample reference architecture for Metalogix StoragePoint

In this architecture, SharePoint BLOB is externalized by the RBS provider to external

storage such as Isilon. Meanwhile the metadata is still stored in the content
databases.
Best practices for RBS are as follows:
 Install an RBS provider on each server where SharePoint Server 2013 is
installed and on each database server in the topology. The provider includes a
set of DLLs that implement methods for the RBS application programming
interfaces (APIs) and perform the actual operation of externalizing the BLOBs.
 Determine the limitations of each RBS provider. For limitations of a Microsoft
FILESTREAM provider, refer to Limitations of RBS.
 Use RBS to optimize the following environments:
 Environments that store fewer large BLOBs (256 KB or larger) for read-
intensive or read-only access.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 44
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  Environments where the resources on the computer that is running SQL
Server could become a performance bottleneck.
 Environments where the expense of high-cost drive space is greater than
the expense of increased complex IT operations that might be introduced
by using RBS.
 When SharePoint Server 2013 is configured to use RBS, and the BLOBs reside
on NAS storage, ensure that no more than 20 milliseconds elapses from the
time that SharePoint Server 2013 requests a BLOB to the time it receives the
first byte from the NAS.
 Plan for more time to upgrade an RBS-enabled SharePoint. Under some
circumstances, an upgrade or software updates can enumerate and iterate
through each object to include BLOB data regardless of where that data is
stored. Therefore, upgrade operations are similar in duration whether inline or
remote BLOBs are used.
 When using Metalogix StoragePoint, consider the following best practices:
 Either arrange downtime or run externalization on servers that do not affect
farm performance, for example the application server. Running
externalization on all servers in the farm consumes resources. For details,
refer to EMC Efficient BLOB Storage Management for Microsoft SharePoint
White Paper.
 The StoragePoint database is created on installation, and it can reside on
any SQL Server to which a SharePoint farm server connects. Use the
StoragePoint in the SQL Server that SharePoint farm uses.
 Capacity is based on the size of the tasks that are being run. 4 TB content
database externalizations make the StoragePoint database grow to
approximately 100 GB. The growth is caused by the worker tasks that are
added in batches. The completed batches are also recorded until the task is
done.
 After the externalization task is completed, the completed batches are
removed from the StoragePoint database. You must manually shrink the
database.

Sizing SharePoint Table 23 lists the guidelines for sizing SharePoint components.
components best
practices Table 23. General guidelines for sizing SharePoint components

SharePoint components Guideline

Configuration and administration  Storage and SQL Server capacity planning
database and configuration (SharePoint Server 2010)
 Storage and SQL Server capacity planning
and configuration (SharePoint Server 2013)
Content database Sizing content database best practices

Search service related database and Sizing SharePoint search service best practices
components

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 45
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 SharePoint components Guideline
User profile service related database Sizing SharePoint user profile service best
practices

Other service application related  Storage and SQL Server capacity planning
databases and configuration (SharePoint Server 2010)
 Storage and SQL Server capacity planning
and configuration (SharePoint Server 2013)
tempDB Sizing tempDB best practices

Sizing content database best practices

The best practices for content databases are as follows:
 Content database data files and log files should reside on different LUNs.
 Two kinds of disks can be used for storing content database:
 SAS—for consistent performance
 NL-SAS flash (FAST VP SSD)—for cost saving considerations
 Put content database data files on RAID 5 LUNs.
 Put content database log files on RAID 10 LUNs.
 Each content database must contain less than 60 million items, including
documents and list items. For details on how to calculate the item count in an
existing content database, refer to Appendix E: Scripts to break down items in
the content database.

Formula to size content database

In the section Content database I/O and capacity characteristics, we introduced the
relationship between content database IOPS and concurrent user numbers with a few
formulas. These are powerful tools for sizing the content database from a
performance perspective.

The formulas were developed from a test environment featuring the following
important conditions:
 64 GB of memory was allocated for SQL Server.
In SharePoint Server 2010, for up to 4 TB content databases, Microsoft
recommends allocating 64 GB memory for SQL Server, while in SharePoint
Server 2013 Microsoft recommends allocating 32 GB for memory. If SQL Server
does not have enough memory, the disk I/O increases greatly due to memory
swap.

 Incremental crawl was running as a background job every half hour.

This simulated the workload I/O of a production environment in which search
crawl and content processing run at regular intervals.
 Web server CPU usages were all under 70 percent.

When using these formulas, consider above three conditions to get the expected
performance estimations.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 46
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 24 and Table 25 show formulas in two workload profiles.
Table 24. SharePoint Server 2010 formulas

Workload profile Formula More

Publishing Portal y is the host IOPS

Document Management Portal x is the number of

concurrent users

For example, in SharePoint Server 2010 Publishing Portal with 20,000 users and a
concurrency rate of 25 percent, the host IOPS for content databases is calculated as
follows:
( )

Table 25. SharePoint Server 2013 formulas

Workload profile Formula More

Publishing Portal y is the host IOPS

Document Management Portal x is the number of

concurrent users

For example, in SharePoint Server 2013 Document Management Portal with 20,000
users and a concurrency rate of 20 percent, the host IOPS for content databases is
calculated as follows:

To continue sizing the content database, we need the backend IOPS. The read/write
ratio is needed to calculate backend IOPS. Refer to Content database I/O and
capacity characteristics for details of the read/write ratios of different SharePoint use
cases.

Using the storage RAID type combined with the read/write ratio, you can calculate the
backend IOPS. EMC VNX Unified Best Practices for Performance provides methods of
calculating the backend IOPS.

Sizing SharePoint search service best practices

The search service application is a very important part of the SharePoint farm. It
contains many components that work together and can scaled according to the size
of the farm.

Since SharePoint contains multiple components to support the search function, EMC
recommends that you use the following sequence to size the SharePoint search
service:
 Size search components based on business needs—Determine the scalability
of the search topology to meet the business requirements. For example, the
number of index partitions and crawlers.
 Size storage for each search component—Size storage for each search
component based on its I/O characteristics.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 47
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The next two sections discuss the best practices for sizing search components for
both SharePoint Server 2010 and 2013.

Note: You can use the VSPEX sizing tool to automatically complete the sizing calculation.
This tool implements the sizing logic in this section. It is easy to use and it saves time and
energy for the sizing calculations.

Storage best practices for sizing SharePoint Server 2010 and 2013 are as follows:
 Put search service application-related contents (databases, index files) on RAID
10 SAS disks. Refer to Appendix A: I/O characteristics analysis for SharePoint
Server 2010 and 2013 search and user profile service application for search
related I/O characteristics.

 For detailed storage sizing for each component for search service, refer to
Search and user profile service application I/O and capacity characteristics.
Sizing SharePoint Server 2010 best practices
A best practice for search components sizing in SharePoint Server 2010 is to scale
topology according to the number of items. Table 26 shows different topology best
practices for different numbers of items.

Table 26. Topologies for different numbers of items

Number of
Topology best practice
items
0-1 million All components could coexist on one or two servers.

1-10 million One dedicated application server running crawl components.

10-20 million Two dedicated servers running crawl component.

Two index partitions.
Two query components. Each query components should have a mirror.
Application running index partitions also hosting query components.

20-40 million Three index partitions with distributed query components.

Two crawl databases.
Each crawl server has two crawler components running on it.

40-100 million Isolate each topology layer into server groups in which each role is
deployed to its own servers.
Scale server group to meet specific requirements for the components in
that role.
Add more crawl and query database for redundancy.

 Add crawl servers, crawlers, and crawl databases to improve full crawl time and
refresh time.
 Add query servers and index partitions to improve high load query latency.
 Deploy redundant query components for the same index partition on different
servers for redundancy.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 48
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  Use clustered or mirrored database servers to host crawl and property
databases.
 Use multiple crawl components on redundant crawl servers and add crawl
databases for high availability.
 For each search application in SharePoint Server 2010, there is only one search
admin component. Putting this component on a dedicated server is a best
practice, which means this server does not function as web front end, query
server, or crawl server.

For details on sizing principles, refer to the Scale-out decision points section of the
article Search Architectures for Microsoft SharePoint Server 2010.

For details of each component of SharePoint Server 2010, refer to Search

Architectures for Microsoft SharePoint Server 2010.
Sizing SharePoint Server 2013 best practices
Search component sizing best practices are as follows:
 Add one index partition per 10 million items.
 Use two query processing components for redundancy. Above 80 million items,
increase to 4.
 Add one crawl database per 20 million items.
 Add one link database per 60 million items.
 Add one analytics reporting database for each 500K unique items viewed each
day or every 10-20 million total items.
 Use two search administration components for redundancy.

For details regarding each component of the search function in SharePoint Server
2013, refer to Overview of search in SharePoint Server 2013.

For information on how to scale search for performance and availability, refer to the
documents below:
 Scale search for performance and availability in SharePoint Server 2013
 Enterprise Search Architectures for SharePoint Server 2013

Sizing SharePoint user profile service best practices

SharePoint user profile service sizing follows the same sequence of SharePoint
search service sizing.

Refer to Best practices for people and profiles (SharePoint Server 2010) for details.
The content applies for both SharePoint Server 2010 and SharePoint Server 2013.

For detailed storage sizing for each component for user profile service, refer to Search
and user profile service application I/O and capacity characteristics.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 49
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Sizing other components in SharePoint
For other components in SharePoint, such as service application databases, EMC
recommends storing the content on SAS RAID 10 disks to satisfy the random I/O
requirements.

In some cases, such as browsing a long list with thousands of files, SharePoint
generates many IOPS for SQL tempDB. The following section introduces some best
practices for tempDB in a SharePoint environment.

Sizing tempDB best practices

TempDB is a temporary database that contains all temporary user objects such as
global or local temporary tables, table variables, and cursors. It also includes internal
objects created by the SQL Server Database Engine, such as work tables to store
intermediate results for spools or sorting. TempDB handles and manages row
versions. In SharePoint, almost every action and request generates work in the
tempDB.
EMC suggests the following best practices for tempDB:
 Put tempDB on SAS RAID 10 disk LUNs because tempDB is write-intensive.
 Use a minimum of two tempDB data files for a small SharePoint farm, and a
minimum of four tempDB data files for a medium SharePoint farm.
 Set the database autogrowth value as percentage instead of a fixed number of
megabytes.

For compute resource sizing of SQL Server, refer to Virtualizing SQL servers.

For best practices in configuring SQL Server for SharePoint Server 2010 and 2013
farm, refer to Best practices for SQL Server 2008 in a SharePoint Server 2010 farm.
The article is also applicable for SharePoint Server 2013 users.

Refer to the Storage layout sizing for SharePoint 2013 section in Appendix D of EMC
VSPEX for Virtualized Microsoft SharePoint 2013 Design Guide for more information
about the tool’s sizing logic. The sizing logic is also applicable for SharePoint Server
2010 users.

FAST Suite best The EMC FAST Suite (FAST VP and FAST Cache) provides two key technologies that
practices enable automated high performance, as needed.

Enabling FAST Cache or FAST VP is a transparent operation to SharePoint and no

reconfiguration or downtime is necessary. To make the best use of either of the FAST
technologies, enable FAST VP on the SharePoint services storage pool first.

Note: Only FAST VP applies to Symmetrix VMAX, while both FAST Cache and FAST VP apply to
VNX.

FAST Suite in next-generation VNX best practices

Overview
EMC next-generation VNX is a flash-optimized hybrid array that provides automated
tiering to deliver the best performance for your critical data, while intelligently moving
less frequently-accessed data to lower-cost disks.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 50
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
In this hybrid approach, a small percentage of flash drives in the overall system can
provide a high percentage of the overall IOPS. The flash-optimized VNX takes full
advantage of the low latency of flash to deliver cost-saving optimization and high
performance scalability. The EMC FAST suite (FAST Cache and FAST VP) tiers both
block and file data across heterogeneous drives and boosts the most active data to
cache, ensuring that customers never have to make concessions for cost or
performance.

FAST Cache dynamically absorbs unpredicted spikes in system workloads. As data

ages and becomes less active over time, FAST VP tiers the data from high
performance to high-capacity drives automatically, based on customer-defined
policies. This functionality has been enhanced with four times better granularity and
with new FAST VP SSDs based on eMLC technology to lower the cost per gigabyte.

FAST Cache best practices

FAST Cache allows you to use the lower response time and better IOPS of flash drives
without dedicating flash drives to specific applications. A single FAST Cache instance
per storage system serves as a system-wide resource.

If a particular chunk of data is accessed frequently by the user application, that

chunk is automatically promoted into the FAST Cache by copying from hard disk
drives to the flash drives. Subsequent access to the same chunk is serviced at flash
drive response times, thus boosting the performance of the storage system.

Applications that access a small area of storage with high frequency benefit the most
from using FAST Cache. For example, in SharePoint, FAST Cache provides fast access
to the crawl database and index files to accelerate the crawl rate.

General best practices for FAST Cache apply to SharePoint Server 2010 and 2013. For
general best practices for using FAST Cache, refer to EMC FAST Cache—A Detailed
Review White Paper and EMC VNX Unified Best Practices for Performance—Applied
Best Practices Guide.
For SharePoint specifically, consider the following:
 Content database access and service application database access benefit from
FAST Cache, because a considerable portion of the access to these types of
data comes from small-block random I/O.
 The search index may not benefit from FAST Cache when being generated,
because of the large I/O. But when being queried, it benefits from FAST Cache
due to the small random read on index partition. Refer to Search service I/O
and capacity characteristics section for more details.
 When dealing with customized development in SharePoint, be careful when the
storage related workload is small block sequential. This kind of data should be
avoided when using FAST Cache. FAST Cache must be disabled at the pool
level, so it is best to separate pools of LUNs storing this data.

FAST VP best practices

FAST VP can lower the total cost of ownership (TCO) and increase performance by
intelligently managing data placement at a sub-LUN level. FAST VP automatically
moves more active chunks (data that is more frequently accessed) to the best
performing storage tier, and it moves less active chunks to a lower performing tier.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 51
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
EMC recommends that you enable FAST VP on the VNX and add additional flash disks
as a high performance tier into the SharePoint content database pool. For best use of
the flash tier, set all LUNs to Start High, then Auto-Tier.

General best practices for FAST VP apply to SharePoint Server 2010 and 2013. For
details, refer to EMC FAST VP for Unified Storage Systems—A Detailed Review and
FAST VP design best practices section of EMC VSPEX for Virtualized Microsoft
SharePoint 2013 Design Guide.
For SharePoint specifically, consider the following best practices:
 Plan for the growth of SharePoint content and maintain some unallocated
capacity within the pool to help with relocation schedules when using FAST VP.
 Schedule relocations for off-peak hours so the primary workload does not
contend with the relocation activity.
 During peak hours, EMC recommends you set the Data Relocation Rate to
Medium to move the hot data to the highest performance tier as soon as
possible without affecting the SharePoint performance. At non-peak hours,
EMC recommends you set the Data Relocation Rate to High.
 For a medium to large SharePoint farm, EMC suggests you enable FAST VP on
the SharePoint content database pool to aggressively reduce TCO. The
percentage of the reduced TCO can vary widely, depending on the size of the
SharePoint farm and the workload in this farm. The SharePoint workload can be
serviced with a mix of tiers and a much lower drive count. Table 27
demonstrates details of this mixed pool after FAST VP is enabled.

Table 27. Disk type and RAID type for storage pool after FAST VP is enabled

Storage pool name RAID type Disk type

Content database pool RAID 6 NL-SAS

RAID 10 FAST VP SSD

Best practices for FAST VP on Symmetrix VMAX

FAST VP monitors the performance of a LUN at fine granularity and moves only a small
number of Symmetrix tracks between storage tiers. FAST VP proactively monitors
workloads at a sub-LUN level in order to identify active areas that would benefit from
being moved to higher-performing drives. FAST VP also identifies less active sub-LUN
areas that could be moved to higher capacity drives, without affecting existing
performance.

FAST VP best practices

For general best practices of FAST VP on VMAX, refer to FAST VP for EMC Symmetrix
VMAX Theory and Best Practices for Planning and Performance Technical Notes.
For SharePoint specifically, consider the following best practices:
 FAST policies control tier capacities used by storage groups. When configuring
policies for a typical SharePoint workload, EMC recommends setting a high
performance tier at less than 100 percent of capacity, a performance tier
equal to 100 percent of capacity, and a capacity tier equal to 100 percent of

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 52
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 capacity for a self-adjusting black box. Use different values as dictated by
chargeback or other operational reasons.
 FAST VP has the following time windows:
 Performance time window—Time window that the SharePoint is serving the
user.
 For most SharePoint applications where users generate the most data
during the weekdays, simply setting the collection policy to be active
only during the daytime from 7 AM to 7 PM, Monday to Friday helps to
address the normal performance requirement.
 For users in a globally distributed SharePoint farm, collecting statistics
24x7 would be a simple and comprehensive approach.
 Each environment must make the decision based on their particular
requirements and SLAs. No performance time window is applicable to
all customer environments.
 Workload analysis period—Affects decay rates and time to respond to
changes. EMC recommends that you set this value to seven days (168
hours) a week.
 Data movement time window—Defines when FAST VP is allowed to move
data. EMC recommends an initial data movement time window of 24x7 for
SharePoint.
 For a typical SharePoint deployment, EMC recommends keeping the default
FAST VP Relocation Rate value at five.
 Use the PIN feature to override FAST VP. If, for example, the LUNs containing
tempDB and log files do not need to be moved between the tiers, you can use
the PIN feature.

Server flash XtremSF

considerations EMC XtremSF is a server-based peripheral component internet express (PCIe) flash
hardware that reduces latency and increases throughput to dramatically increase
application performance. XtremSF can be used as a direct-attached storage (DAS)
device or as a caching device in conjunction with EMC XtremCache server flash
caching software.

When XtremSF is used as DAS, data sets are stored locally for accelerated reads and
writes.

When XtremSF is used with XtremCache, the intelligent caching algorithm accelerates
reads, while all writes persist to the networked storage for HA, integrity and disaster
recovery.

The following two sections focus on DAS use cases of XtremSF and XtremCache.

XtremSF benefits
Applications with performance requirements (with or without protection
requirements) that are read and write heavy can be a good fit for XtremSF DAS.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 53
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The large capacities offered in the XtremSF portfolio allow users to store large
SharePoint content databases on a single PCIe flash device to improve both read and
write performance.

XtremSF Best practices

The best practices for XtremSF as DAS are listed as follows:
 The eMLC flash-based PCIe cards are adequate for performance and endurance
requirements for SharePoint Server 2010 and 2013 environments.
 You should know the SharePoint data set size with predictable future growth
relative to the XtremSF card capacity. The entire data set can be placed on the
XtremSF card for maximum performance benefit.
 Business-critical data in the SharePoint environment must be protected. This is
because as DAS, XtremSF does not provide the data protection benefits
inherently found on the backend storage arrays. Best practice is to use data
protection features at the OS or SharePoint level. For the SharePoint out-of-box
protection feature refer to General considerations for Backup and Recovery in
SharePoint.

XtremCache
EMC XtremCache is a server flash-caching software that reduces latency and
accelerates throughput to dramatically improve application performance, and is most
effective when coupled with EMC XtremSF—EMC PCIe flash technology.

XtremCache accelerates reads and protects data by using a write-through cache to

the networked storage to deliver persistent high availability, integrity, and disaster
recovery.

XtremCache benefits
XtremCache can benefit SharePoint components with read-heavy high performance
and protection requirements, such as content or crawl database data LUNs.

XtremCache accelerates block I/O reads that require the highest IOPS and/or lowest
response times, when a LUN housing a SharePoint database is configured as the
source device for XtremCache. At the same time, it can also offload the I/O
processing from the storage array.

Our validation testing of XtremCache with SharePoint Server 2010 shows a significant
reduction in both crawl duration, which is decreased by 20 percent, and content
database latency, which is decreased by 80 percent, during the full crawl. In daily
user workloads, XtremCache can also provide benefits based on the characteristics of
the workloads.

Note: Performance gain and reduction in response times can vary based on each customer’s
SharePoint usage profile. We recommend that you use a pilot phase test in your
environment to determine the exact benefits of this technology. However, all testing within
EMC showed improvements in performance.

For detailed test results and configuration, refer to EMC VSPEX with EMC XtremSF and
EMC XtremCache Design Guide.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 54
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
XtremCache best practices
Here are the best practices for both SharePoint Server 2010 and 2013 in virtual or
physical environments:
 Use XtremCache Performance Predictor in the SharePoint Server 2010 and
2013 farm to view predicted performance in LUN granularity and choose the
best LUNs to accelerate. For details on where to download this tool, refer to
Appendix B: Tools for SharePoint Server performance testing, monitoring,
tuning, and sizing.
 Exclude log LUNs and tempDB LUNs in the SharePoint Server 2010 and 2013
farm from the acceleration of XtremCache.
 There is no hard limit on the maximum number of server volumes on which
XtremCache can be enabled. However, if you enable it on a large number of
volumes or LUNs, resource starvation could result for those volumes that could
benefit from XtremCache. EMC recommends that XtremCache not be enabled
for those volumes or LUNs that are least likely to gain any performance benefit
from XtremCache. This allows other volumes or LUNs that are a good fit for
XtremCache to get the maximum processing and cache capacity resources.
 Manually stop and restart the XtremCache software driver for the source device
if any operations modify the SharePoint data without the knowledge of the
server that results in stale data in the XtremCache. For example, if a SharePoint
LUN snapshot were taken on the array and later used to roll back changes on
the source device, the SharePoint server would have no knowledge of any
changes that had been done on the array.

Note: As a generic best practice, EMC recommends you unmount the SharePoint LUNs
when there are any changes which only apply to storage without the knowledge of the
server.

 Set the page size to 64 KB (the default is 8 KB) and the maximum I/O size to
128 KB (the default is 64 KB) in XtremCache to accommodate the large I/O size
of the content and crawl databases.
 Use the VSI plug-in for VMware vSphere vCenter to easily manage and monitor
XtremCache in a virtualized environment.

Best practices for SharePoint Server 2010:

 Include content database data LUNs and crawl database data LUNs as the
XtremCache source devices, since they are both read intensive when doing
crawl.
 In SharePoint Server 2010, for each 1 TB of the content database, an
XtremCache of 250 GB or more and for each 100 GB of the crawl database, an
XtremCache of 40 GB or more can significantly improve the crawl performance.

Best practices for SharePoint Server 2013:

 The crawl mechanism is redesigned in SharePoint Server 2013. The crawl
database does not experience heavy workloads during crawl as in SharePoint
Server 2010. So it is not necessary to include the crawl database as the
XtremCache source device.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 55
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  In SharePoint Server 2013, for each 1 TB of the content database, an
XtremCache of 250 GB or more can significantly improve the crawl performance.

Best practices for SharePoint Server 2010 and 2013 in a virtualized environment:
 Clear the XtremCache before the virtual machine “suspend” and “remove”
operations if the SharePoint farm is hosted in VMware environment. This is
handled using scripts that are automatically installed when the XtremCache
Agent is installed in the SharePoint virtual machine.
 Stop the source device volume where you want to take a snapshot in VMware.
XtremCache metadata is kept in the virtual machine memory; therefore it is a
part of the snapshot image when a virtual machine snapshot is taken. This
means that when this snapshot image is used to roll back the virtual machine,
the old metadata is restored and potentially causes data corruption.

For other best practices under virtualized environments, refer to Microsoft SQL Server
Best Practices and Design Guidelines for EMC Storage White Paper.

Automation with EMC Storage Integrator (ESI) for Windows Suite is a set of tools for Microsoft Windows
ESI and Microsoft applications administrators. The suite includes ESI for Windows, ESI
PowerShell Toolkit, ESI Service, ESI Management Packs for System Center Operations
Manager, and ESI Service PowerShell Toolkit.
ESI for Windows Suite contains a component named ESI Microsoft SharePoint
Adapter. It can help SharePoint administrators easily complete storage related tasks.
SharePoint adapter in ESI currently supports only SharePoint Server 2010.
Figure 10 shows the site collections and content databases information in the ESI
interface.

Figure 10. View site collections and content databases in ESI

SharePoint adapter in ESI can help perform the following functions with SharePoint
farms:
 View SharePoint storage, farms, sites, and content databases.
 Connect to existing SharePoint farms and enumerate farm information,
including servers, web applications, site collections, and content databases.
 Provision storage on the SharePoint server by partitioning, formatting, and
assigning it a drive letter, and provisioning the storage to the SharePoint site.
 Support File Stream Remote BLOB Store.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 56
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  Create a web application and map it to the newly created content database.

For detailed steps of how to perform these tasks, refer to the Chapter 7 ESI Microsoft
SharePoint Adapter in EMC Storage Integrator for Windows Suite Technical Notes.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 57
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
SharePoint Server farm protection
Backup and General considerations for Backup and Recovery in SharePoint
Recovery This section discusses the best practices for designing the high availability
infrastructure.

By default, Microsoft SharePoint Server provides the ability for different levels of
backup and recovery as listed in Table 28. EMC has a number of data protection
products and options that can further protect your SharePoint environment from the
loss of databases, servers, or entire sites.

EMC storage systems offer a wide range of features for SharePoint protection and
high availability. EMC replication technologies such as EMC TimeFinder® , EMC
Symmetrix Remote Data Facility (SRDF® ), and VNX snaps and clones provide the best
data protection in the industry. EMC RecoverPoint® with continuous protection and
replication management tools such as Replication Manager, provide protection for
the SharePoint server at the application level. Some third-party tools, such as
Metalogix StoragePoint and Kroll Ontrack PowerControls, provide some advanced
backup and recovery features that are not part of the standard SharePoint protection
options.

Table 28. SharePoint backup and recovery in general

Maximum backup size Supported backup

Tool Type of restorable objects
supported type
SharePoint Farm  Farm <200 GB  Full
Backup and Restore
 Service application  Incremental
 Web application
 Content database
 Site collection
 Site
 List item/document
 Configurations
 Customizations (if packaged
as user solutions)

SQL Server  Content database Content databases >  Full

200 GB may require
 Site  Differential
additional management
 List item/document

Windows PowerShell Site collection (not recommend 100 GB  Full

Site Collection Backup for site collections larger than
 Differential
and Restore 100 GB)

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 58
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Maximum backup size Supported backup
Tool Type of restorable objects
supported type
Windows PowerShell  Site 100 GB Full
Import and Export
 List/Document Library
 List items
 Customizations (if packaged
as user solution)

For details of general best practices for SharePoint Server 2010, refer to Backup and
recovery best practices (SharePoint Server 2010).
For details of general best practices for SharePoint Server 2013, refer to Backup and
restore best practices in SharePoint 2013.
Content recovery with Kroll Ontrack PowerControls
EMC is part of a technology partnership with Kroll Ontrack that provides granular,
item-level recovery of SharePoint data for both NetWorker and EMC Avamar® . With
Kroll Ontrack PowerControls, EMC can provide an appropriate solution to meet
customer recovery performance requirements.

Kroll Ontrack PowerControl can:

 Restore data from content database backups
 Quickly and easily find, recover and restore SharePoint content, such as
documents, lists, libraries and folders, or entire SharePoint sites
 Maintain data integrity during a SharePoint granular recovery

For best practices using Kroll Ontrack PowerControl with SharePoint, refer to EMC
Replication Manager and Kroll Ontrack PowerControls for Granular Recovery of
SharePoint Items White Paper.
Backup and recovery SharePoint content with RBS
RBS is a SQL Server library API which enables applications, such as SharePoint Server
2013, to store BLOBs in a location outside the content databases. Storing the BLOBs
externally can reduce requirements for SQL Server database storage space. The
metadata for each BLOB is stored in the SQL Server database and the BLOB is stored
in the RBS store.

These example scenarios benefit from RBS:

 The need to store fewer large BLOBs (256 KB or larger) for read-intensive or
read-only access
 Huge content databases for archiving in order to reduce storage costs
 A great number of large unstructured data files, such as media files

Note: Although RBS supports the large file size, a single document still has the limitation of
2 GB.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 59
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
RBS uses a provider to connect to any dedicated BLOB store that uses the RBS APIs.
SharePoint Server 2013 supports a BLOB storage implementation that accesses BLOB
data by using the RBS APIs through such a provider. RBS has two kinds of providers,
local and remote.

The RBS FILESTREAM provider is a typical local RBS provider which uses the SQL
Server FILESTREAM feature to store BLOBs in an additional resource. This provider
supports only a local hard disk or an attached iSCSI device.

If you want to make BLOB stores in NAS or remote sites, you can use a third-party
remote RBS provider such as Metalogix StoragePoint.

The combination of VNX snapshot technology, EMC Replication Manager, and

Metalogix Selective Restore Manager offers unique advantages over many of the
available technologies:
 Reduced backup and recovery times
 Complete and synchronized backup and recovery process
 Reduced management overhead through automated creation of point-in-time
copies and intuitive recovery workflows
EMC recommends that you follow these best practices for backup and recovery in
SharePoint with RBS:
 When protecting a SharePoint farm with remote BLOB stores with Replication
Manager, inconsistencies might exist between the BLOB stores and the RBS
databases. BLOBs can be present in the BLOB store replica while absent from
the RBS database replica. We recommend that you run RBS database and BLOB
store consistency checks and clean up orphaned BLOBs using RBS Maintainer
after database restoration. For details about RBS maintainer, refer to Running
RBS maintainer.
 If you are using Metalogix StoragePoint as the RBS provider, protect SharePoint
farms in the following order so that the StoragePoint database is as close to
being in sync with the SharePoint farm databases as possible. This ensures
that StoragePoint’s orphan control can identify and clean up any orphaned
documents.
 SharePoint farm
 StoragePoint database
 BLOB stores

 If you are using Metalogix StoragePoint as the RBS provider, use the following
order to restore a single content database
 BLOB store
 StoragePoint database
 Content database

Note: System Center 2012 Data Protection Manager cannot use the RBS FILESTREAM
provider to back up or restore RBS. Meanwhile SQL backup can take care of FILESTREAM
BLOB objects.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 60
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 For details refer to EMC Efficient BLOB Storage Management for Microsoft SharePoint
White Paper.

SharePoint Server 2010 and 2013 VSS for backup replication

Microsoft SharePoint foundation includes a referential volume shadow copy service
(VSS) Writer (SPF-VSS Writer) that integrates with the Windows VSS backup
framework, enabling backup applications to back up and restore SharePoint data. It
supports a catastrophic overwrite scenario for the entire farm (search index included).

EMC Replication Manager, Networker Module for Microsoft Applications, and Avamar
VSS plug-in are built on top of these technologies to provide data protection that
suits different environments.

One general best practice for any solution which uses SPF-VSS Writer is that the
number of LUNs mounted to a mount host should not exceed 32.

For details about SharePoint foundation and the VSS, refer to:
 SharePoint Foundation and the Volume Shadow Copy Service
 Overview of SharePoint 2013 and the Volume Shadow Copy Service

EMC replication technologies

EMC offers a wide range of options to provide replication technologies with
SharePoint farm protection. Table 29 lists the options for EMC replication
technologies.

Table 29. EMC replication technologies offering

Category Tool/System Features Description

RecoverPoint Continuous data  Synchronous
protection (CDP)
 Local recovery protection

Continuous  Asynchronous
remote
 Continuous remote replication
replication (CRR)

Continuous Concurrent local  Concurrent local and remote data

availability and remote data
 Combines CDP and CRR
protection (CLR)

VMAX/VNX CDP/CRR/CLR Both VMAX and VNX arrays have options

with a built-in with a built-in RecoverPoint splitter that
RecoverPoint functions as native continuous availability
splitter

VMAX SRDF Continuous replication

Replication Snapshot/Clone,  A comprehensive data protection

Point-in-time Manager SAN copy for software
rapid VMAX and VNX
 Must install agent on SharePoint Server
replication
recovery VMAX Mirror General monitor and control operations for
TimeFinder business continuance volumes (BCV)

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 61
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Category Tool/System Features Description
CG Consistency groups

Clone Clone sessions generally consume the

same size of production LUNs, but have no
impact once created.

Snap Snapshots consume less space than

clones, but have more impact on production
LUNs if the data changes frequently on the
LUNs.

VNX Clone Clone sessions generally consume the

same size of production LUNs, but have no
impact once created.

Snap Snapshots offer an alternative to clones in

that they require less space, but because
they are pointer-based they may cause
spindle contention, in which case users
may opt for the performance benefit
provided by clones.

Avamar Complete Variable-length deduplication significantly

software and reduces the backup time by only storing
hardware unique daily changes while maintaining full
Point-in-time solution daily backups for immediate, single-step
efficient restore.
backup and
restore EMC Traditional Centralizes, automates, and accelerates
Networker backup and data backup and recovery with a wide range
restore software of data protection options.
solution

Each product has its own benefits and considerations. The decision depends on the
service-level requirements of each use case.

EMC hardware-based snap and clone products have been integrated with Microsoft
Virtual Device Interface (VDI) and VSS technology for many years. Symmetrix
TimeFinder and VNX Snapshots (or advanced snap in the later version) enable local
point-in-time snapshots and data clones for backup and recovery operations. These
products enable simple, non-destructive backup operations with space-saving
snapshots or full block-for-block clone copies of your SharePoint farm. With these
products, backups and restores can occur in seconds.

EMC TimeFinder
TimeFinder software works by creating multiple, independently addressable BCVs for
independent storage. The BCV is a Symmetrix device with special attributes created
when the Symmetrix is configured. It can function either as an additional mirror to a
Symmetrix logical volume or as an independent, host-addressable volume.
Establishing BCV devices as mirror images of active production volumes allows you to
run multiple simultaneous business continuance tasks in parallel.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 62
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
EMC suggest you follow the best practices below when you use TimeFinder:
 Issue TimeFinder commands from a management host but not the SQL server
for SharePoint. The reason is that in rare cases when consistent split is used,
under heavy write activity Symmetrix management commands may be queued
behind database writes, interfering with completing the replication. In such
cases, the replica is deemed invalid.
 If TimeFinder spans Symmetrix array, use a composite group instead of device
group.
 Remote TimeFinder replica creation from an SRDF/A target should always use
the –consistent flag to coordinate SRDF/A cycle switching with the TimeFinder
operation in order to guarantee that the replica is consistent.
VNX Snapshots
VNX Snapshots is a VNX software feature introduced in the EMC VNX operating
environment for VNX OE 5.32. This feature creates point-in-time data copies that
customers can use for data backups, software development and testing, repurposing,
data validation, and local rapid restores.

EMC suggests you follow these best practices when you use VNX Snapshots in
conjunction with SharePoint:
 Start with thin LUNs to implement VNX Snapshots for SharePoint LUNs. This is
because traditional or thick LUNs are converted to thin LUNs once a VNX
snapshot is created on them.
 Put all SharePoint components into a consistency group in order to snap them
concurrently.
 Do not perform excessive deletion of snapshots during SharePoint busy I/O
operations.
 Enable FAST Cache on the storage pools for SharePoint where you take
snapshots to eliminate overhead. A very small amount of FAST Cache absorbs
all the metadata.

SnapView clones
SnapView clones are fully populated point-in-time copies of LUNs that allow
incremental synchronization between the source and destination LUNs.

General best practices for SnapView clones apply to SharePoint environment.

Following are some key best practices to follow. For details refer to EMC CLARiiON
SnapView Clones:
 Ensure that clones reside on different drives from the source LUN. In case the
source LUN is not available due to some disk level hardware failure, the clone
could still remain accessible.
 Place clones on the same type of drives as source LUNs to ensure optimal
performance of source LUNs when working with clones.
 Proactively verify the state of the data in the replicas as soon as they are
created. This ensures that the replica used for restoring the source LUN has the
required data.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 63
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
EMC RecoverPoint bookmarks
A bookmark is a named RecoverPoint snapshot. The book mark uniquely identifies an
image.

EMC suggests you follow these best practices when using bookmarks in
RecoverPoint:
 Avoid creating too many shared bookmarks if you are using group sets to
distribute the load between several RecoverPoint Appliances to protect your
SharePoint environment. When creating a bookmark between the groups all the
groups are quiescent. During this period writes are temporarily delayed to the
host, and the bookmark is created. The amount of delay is not significant if few
shared bookmarks are created.

 Modify the VMware vCenter Site Recovery Manager (SRM) timeout value if you
want to restore from an older SharePoint farm bookmark. The older the
bookmark, the longer it takes RecoverPoint to enable image access and
consequently complete the failover. VMware SRM 5.x enforces a timeout of 300
seconds for all RecoverPoint storage replication adapter (SRA) operations. If
SRA does not complete an operation within this time limit, the VMware SRM
terminates the operation, possibly causing the environment to be in an
undesired state. This timeout is more likely to be breached, the older the
RecoverPoint point-in-time being used. Refer to VMware SRM document for
details.

EMC Replication Management tool

The replication process can be simplified and centrally managed by tools and scripts.
The following sections introduce some common tools for replication management
and their best practices.

EMC Replication Manager

EMC Replication Manager enables the management of EMC point-in-time replication
technologies for SharePoint protection through a centralized management console.
Replication Manager coordinates the entire data replication process—from discovery
and configuration to the management of multiple, application-consistent, disk-based
replicas.

EMC strongly recommends a robust method that enables rapid SharePoint farm
backup and restore. EMC Replication Manager, EMC Avamar, and EMC Networker offer
features for log truncation and the mounting of databases to alternative hosts. EMC
Replication Manager helps you safeguard SharePoint using EMC point-in-time
replicas to off-load production for business repurposing actives, such as backup,
development, and quality assurance. Some key benefits include:
 Using Replication Manager’s easy-to-use interface, you can automate
management of EMC replication technologies for backup acceleration and
operational recovery of SharePoint content databases in minutes, versus hours
or days by using Microsoft VDI.
 Built-in application intelligence ensures the underlying Microsoft SQL server
database backup is consistent.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 64
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  Enables you to set up replication jobs for backup acceleration on a scheduled
basis or create a replica ad-hoc.
 Enables you to restore a replica of SharePoint content databases or perform a
surgical repair to your production environment.
 Using Ontrack PowerControls for SharePoint software (available through EMC
Select) enables SharePoint administrators to restore items, such as documents,
lists, libraries, folders, tasks, calendar items, and attachments, from a previous
full back up or replica of the content database.
 Replication Manager provides an easy-to-use graphical user interface (GUI) to
manage, schedule, and monitor replication jobs. It is also flexible to script by
using command line interface.
 Replication Manager Console is a portable Java application that lets you control
Replication Manager from a Windows system that has a TCP/IP connection to
the Replication Manager Server. A command line interface is also provided. It
can be run interactively or in batch mode.
 Replication Manager can protect the whole SharePoint farm including remote
BLOB stores within a virtualized SharePoint environment. For details, refer to
EMC Efficient BLOB Storage Management for Microsoft SharePoint—EMC VNX,
EMC Replication Manager, Microsoft SharePoint 2010, VMware vSphere,
Metalogix StoragePoint.
Below are some best practices for protecting a SharePoint farm with EMC Replication
Manager:
 Configure separate LUNs for SharePoint configuration databases, search
databases, search indexes and content databases. This is necessary as certain
databases and indexes are restored at specific points during the restore
procedure.
 Put SharePoint search indexes on a dedicated LUN for protection instead of
local drives.
 Replication Manager and SharePoint require permissions and rights to
configure application sets, run jobs, and perform restores. Establish a common
set of credentials for all SQL Server instances used by the SharePoint servers.
The SharePoint farm account must have local administrative rights on the
SharePoint VSS Writer host.

Table 30 shows the supported storage connectivity options for Replication Manager.

Table 30. Supported storage connectivity options for Replication Manager

Options Hyper-V VMware

iSCSI to guest Yes Yes

RDM N/A Yes

VHD/VHDX No N/A

VMDK N/A No

Pass-through Yes N/A

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 65
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 For details, refer to EMC Replication Manager and Microsoft SharePoint—A Detailed
Review.
EMC RecoverPoint kutils utility
RecoverPoint provides a kutils utility that can be used for creating consistent
Microsoft SQL server database replicas used for backup and recovery. The kutils
sqlsnap command sets SQL Server into a quiescent mode with the aid of SQL Server
VDI mode while taking the snapshot. The VDI-enabled snapshot is then bookmarked
by kutils and it can be restored using the kutil sqlRestore command.

By leveraging EMC RecoverPoint kutils in conjunction with Windows PowerShell, it is

easy to automate a management job for RecoverPoint.

For details, refer to EMC RecoverPoint Replicating Microsoft SQL Server Technical
Notes.

Multi-site disaster Disaster recovery scenarios introduction

recovery Considering the various business requirements for disaster recovery in a SharePoint
farm, there are several possible options for configuring a disaster recovery
environment with storage or SAN based replication technology. Table 31 lists three
specific scenarios: Failover farm, full farm replication, and stretched farm.

Table 31. Three disaster recovery scenarios

Disaster recovery
Description
scenario
Failover farm Provides for two independent farms where only contents are
scenario replicated between the sites. Server roles are maintained separately
between the farms.

Full farm replication All data and server roles are replicated to a passive site for the
scenario purpose of disaster recovery.

Stretched farm Provides a farm to stretch, otherwise has active server roles enabled
scenario between multiple data centers connected by high-bandwidth fiber
optic links.

According to Microsoft, stretched farm in SharePoint Server 2013 is not supported,

unless the following two prerequisites are met:
 There is a highly consistent intra-farm latency of <1ms (one way), 99.9 percent
of the time over a period of ten minutes. Intra-farm latency is commonly defined
as the latency between the front-end web servers and the database servers.
 The bandwidth speed is at least 1 gigabit per second.

For details, refer to Create a high availability architecture and strategy for SharePoint
2013.
All three disaster recovery scenarios support synchronous or asynchronous
replication technologies. EMC recommends you carefully choose the mode based on
your business requirements. Table 32 lists the advantages and disadvantages of
each mode.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 66
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 32. Synchronous replication mode vs. asynchronous replication mode

Replication
Advantages Disadvantages
mode
Synchronous No data loss of committed  Requires high bandwidth and low
replication transactions (RPO=0) network latency.
mode
 Distance between two sites may
not exceed 200 km.

Asynchronous No limitation for replication Consistent point-in-time image on the

replication distance target devices that is only slightly
mode behind the source devices

General considerations and best practices in different disaster recovery scenarios

Regardless of the specific disaster recovery technology you use, EMC recommends
you follow some general best practices after the disaster recovery scenario is
selected.
Failover farm scenario
The failover farm scenario, also referred to as a mirror farm within some Microsoft
documentation, involves a source SharePoint farm contained in a production site and
a target SharePoint farm contained in a remote or disaster recovery site. With
independent farms implemented in both sites, the web, query, service application,
database, and index servers are maintained separately in each of the farms. While it
is possible to replicate several types of SharePoint databases, only the content
databases and specific service application databases will be replicated. Any
customizations to web servers or indexed data need to be configured and maintained
separately in each farm. Users can be redirected between the farms as required using
Domain Name System (DNS) updates or network load balancers.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 67
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 11 demonstrates the reference architecture of a failover farm scenario.

Figure 11. Failover farm

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 68
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
General best practices for a failover farm scenario:
 Ensure the virtual SharePoint server name and URL of the web application at
the disaster recovery site match the production site. This is because, for client
redirection, DNS can be modified to reference the web servers that host the
appropriate URL in the failover farm.
 Use relative paths to link items within site, when creating and editing pages at
the production site. In the event that the content database is used at the
failover farm under a different web application name, relative paths ensure that
links and images continue to work.
 Detach and re-attach the content database or refresh the configuration
database using .RefreshSitesInConfigurationDatabase() method periodically in
the disaster recovery site. This is because each time a new site collection is
created to a given content database, information about that site collection is
also added to the configuration database. As failover farm only replicates
content databases, the configuration database is not automatically updated
with the information of the new site collection.
 Duplicate the following items at the target site:
 Windows OS, including installed service packs and hotfixes.
 SharePoint program installation, including installed service packs and
hotfixes.
 Active Directory replication.
 IIS settings for the web front end servers, including any customization.

Full farm replication scenario

Under the full farm replication scenario, the disaster recovery site is intended
to host the whole production farm. This requires that the disaster recovery
site must be designed to exactly replicate the production site. The full farm
replication allows index information to be replicated; however, OS
information must also be replicated.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 69
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 12 shows a typical architecture of a full farm replication scenario.

Figure 12. Full farm replication

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 70
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
General best practices for a full farm replication include:
 Place all content databases, application server related databases,
configuration databases, and indexed data into a consistency group to ensure
they are replicated to the same dependent write point-in-time.

 Use virtualization technology to avoid the physical hardware restriction

between the primary and disaster recovery site if you configure boot from SAN.
By booting servers from SAN, it is possible to replicate the entire OS using SAN
or storage based replication technologies. This allows any changes made to the
source site to be automatically replicated to the disaster recovery site. Booting
from the SAN has specific requirements, including the need from the server
hardware at the remote site to exactly match the server hardware from the
production site. By using virtualization technology, the OS has the same virtual
hardware configured for both the source and disaster recovery site, even
though the physical hardware may differ.

 Ensure the SQL instance name at the disaster recovery site matches the
instance name from the production site, if the SQL instance is not booted from
the SAN or otherwise virtualized.

Stretched farm scenario

In the stretched farm scenario, the disaster recovery site is intended to support the
production site with separate servers that exist within the same farm. With this
configuration, the hosts from the disaster recovery site are within the same farm as
the servers of the production site, operating with redundant roles. All SQL Server
databases are replicated, which also allows the possibility to replicate all farm
databases including the configuration, content, and those supporting service
applications. Web, query, crawl, and application servers are maintained
independently, but within the same SharePoint farm.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 71
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 13 demonstrates the reference architecture of a stretched farm scenario.

Figure 13. Stretched farm

General best practices for a stretched farm scenario include:

 Replicate the configuration database consistently with all content databases.
 Provision a redundancy central administration web site on a server at the
disaster recovery site.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 72
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Choosing the right SharePoint disaster and recovery option
Three disaster and recovery scenarios provide different levels of protection. Table 33
lists the advantages and disadvantages for each scenario.

Table 33. Advantages and disadvantages for disaster and recovery scenario

SharePoint
DR Synchronous/ Additional
components Customization Crawl Network
scenario Asynchronous consideration
to replicate
Failover  Content Both Need to rebuild Need to N/A N/A
farm database customization run
increment
 BLOB
al crawl to
store
refresh
data

Full farm Everything Both No need to rebuild No need to If the If SAN boot is
replication including in customization run crawl, network used to replicate
OS all index is subnet in operation system
up to date the disaster volume, make
recovery sure the hardware
site differs in the remote site
from that in exactly matches
production the one in source
site, need
to refresh IP
in DNS

Stretched SQL server Both Depends (if No need to N/A  Create a high
farm customization is run crawl, availability
deployed at both all indexes architecture
site, no need to are up to and strategy
rebuild date for SharePoint
customization) 2013
 Plan for
availability
(SharePoint
Server 2010)

EMC recommends you consider the generic advantages and disadvantages for each
scenario in Table 33 to decide which option to apply. For details, refer to Remote
Disaster Recovery Concepts for Microsoft SharePoint Server 2010 with storage Based
Replication White Paper.

EMC multi-site replication technologies

You can select multiple EMC multi-site replication technologies to implement the
disaster recovery scenario you have chosen. The following sections introduce each
technology and its associated best practices.

SRDF
SRDF is a Symmetrix-based business continuance and disaster restart solution. In
simplest terms, the purpose of SRDF is to maintain real-time copies of host devices in
more than one physical Symmetrix.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 73
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The local SRDF device, known as the source (R1) device, is configured in a pairing
relationship with a remote target (R2) device, forming an SRDF pair. When the R2
devices are mirrored with R1 devices, the R2 devices are write-disabled to the remote
host. After the R2 devices are synchronized with their R1 devices, they can be split at
any time, making the R2 devices fully accessible to their hosts.

There are three basic operation modes for SRDF, SRDF/Synchronous (SRDF/S),
SRDF/Asynchronous (SRDF/A), and SRDF Adaptive Copy. The following discussion
only focuses on SRDF/S and SRDF/A.

SRDF best practices for SharePoint include:

 Always use a composite group with consistency enabled (also called a
consistency group) for SharePoint content databases, configuration databases,
service application databases and index partition. There is a common
misconception that you must enable consistency, which is only required for
SRDF/A. SRDF/S does not benefit from it.
 Have a clone copy (TimeFinder/Clone as an example) available at the SRDF
target as a gold copy protection in order to avoid the rolling disasters of
SharePoint farm.
 Use a TimeFinder copy created from the R2 devices to retain the disaster
recovery SharePoint site online between refresh cycles while maintaining
remote replication. Also, in order to refresh the data within the failover farm,
the TimeFinder copy can be incrementally updated from the R2 devices.
 Maintain a third copy of the content databases to implement the TimeFinder
scenario with SRDF. Using TimeFinder/Snap can alleviate the space concerns of
a third copy; however, using snaps against an R2 device should be done
carefully with performance implications in mind.

EMC RecoverPoint
EMC RecoverPoint provides synchronous and asynchronous continuous remote
replication and data protection across heterogeneous storage arrays and SAN.

General best practices for EMC RecoverPoint inlcude:

 Configure the whole SharePoint farm as a single consistency group in
RecoverPoint.
 Configure the RecoverPoint repository and journal LUNs on RAID 10 to ensure
the best performance for RecoverPoint.
 As a general rule, if changed data statistics for your SharePoint environment are
not available, the journal size can accommodate 20 percent capacity of the
data being replicated.
 Refer to the following validated results for change rate if your SharePoint usage
profile is similar to that shown. After you have the change rate in your
environment, use the following formula to estimate the journal size:

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 74
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 34 shows the change rates for SharePoint servers.
Table 34. Validated change rate

Change rate for Publishing Change rate for Document

SharePoint Server version
Portal Management Portal
SharePoint Server 2010 1 MB/s 7 MB/s

SharePoint Server 2013 0.8 MB/s 5 MB/s

 If VMware SRM is built on top of this solution and orchestrating recovery from
the production site to the disaster recovery site, the control of the RecoverPoint
consistency groups must be passed over to the VMware SRM by selecting Use
VMware Site Recovery Manager (SRM) with Group is managed by SRM,
RecoverPoint can only monitor, as shown in Figure 14.

Figure 14. VMware SRM configuration with RecoverPoint

If you plan to use VMAX splitter, EMC recommends you follow the best practices
below:
 Present protected LUNs on the same front end adapters (FAs) as the host
splitting occurs at the FA level using Open Replicator for Symmetrix.
 Plan LUNs with no more than 32 FAs.
 Plan your VMAX port groups ahead of time because changes are not allowed for
a RecoverPoint protected host.
 Plan your utilization of FAs ahead of time because with RecoverPoint, 100
percent additional writes apply to FA. For example, if you are using an FA that is
currently 60 percent utilized with 3:1 Read Write ratio, RP drives utilization to
75 percent.

EMC VPLEX
The EMC Virtualization and Private Cloud (VPLEX) provides access to a single copy of
data at different geographical locations concurrently, enabling a transparent
migration of running virtual machines between data centers. It allows SharePoint data
to be moved, accessed, and mirrored transparently between data centers, effectively

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 75
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
allowing storage and applications to work between data centers as though those
physical boundaries were not there.

The EMC VPLEX family consists of three viable configurations and offerings:
 VPLEX Local—For managing data mobility and access within the data center
using a single VPLEX cluster.

 VPLEX Metro—For mobility across two sites separated by an inter-site latency

of up to 5 ms round-trip time.

 VPLEX Geo—For access between two sites over extended asynchronous

distances with the latency of up to 50 ms round-trip time.

Integrating with server virtualization technology, including VMware Storage VMotion

and Microsoft Hyper-V Live Migration technology and the VPLEX family, allows the
user to move SharePoint farms between different data centers without interrupting
operations on the farm. It reduces the storage maintenance costs rather than building
a mirror SharePoint farm.

While running the VMotion or Live Migration technology between sites, SharePoint
web servers, index and SQL servers are migrated from Site A to Site B. During the
migration, the response times are slightly impacted. However, it does not interrupt
the running application and provides the data center with the capability to manually
reallocate the resource across sites. To summarize, it provides a virtual infrastructure
stretched across two sites with zero downtime for migration operation and very low
downtime for a disaster scenario.

Storage best practices that apply to directly-accessed storage volumes apply to

VPLEX virtual volumes as well. One important best practice to follow is partition
alignment for x86-based OS platforms. Misaligned partitions can consume resources
or cause additional work in a storage array, leading to performance loss.

For more details, refer to the following two white papers:

 VMotion Over Distance for Microsoft, Oracle, and SAP—Enabled by VCE Vblock
1, EMC Symmetrix VMAX, EMC CLARiiON, and EMC VPLEX Metro—An
Architectural Overview
 Long distance application mobility—Enabled by VPLEX Geo

SQL Server restart automation tools

SharePoint can use SQL Server restart automation tools to achieve disaster recovery
such as:
 Database mirroring
 AlwaysOn Availability Group

Although database mirroring is supported in both SharePoint Server 2010 and 2013,
EMC does not recommend this technology to protect your SharePoint environment
because this feature will be removed in a future version of Microsoft SQL Server. For
details, refer to Database Mirroring (SQL Server).

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 76
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
To use AlwaysOn for SharePoint protection, EMC recommends you follow these best
practices:
 If the connection between SharePoint AlwaysOn Availability Groups is across
multi-subnet, configure specifyMultiSubnetFailover=True. This avoids issues
caused by high network latency. For details, refer to Availability Group
Listeners, Client Connectivity, and Application Failover (SQL Server).
 The asynchronous-commit mode for SQL Server AlwaysOn Availability Group is
not supported for every SharePoint database. For a complete list of supported
modes, refer to Supported high availability and disaster recovery options for
SharePoint databases (SharePoint 2013).
For other details of SQL Server restart automation tool, refer to Microsoft SQL Server
Best Practices and Design Guidelines for EMC Storage White Paper.

Virtualized instances automation tools

EMC Cluster Enabler and VMware SRM use EMC disaster recovery solutions such as
SRDF, RecoverPoint, and MirrorView in a virtualized environment.

EMC Cluster Enabler in a virtualized environment

EMC Cluster Enabler software enables geographically distributed Microsoft failover
clusters to replicate their data using MirrorView, RecoverPoint, and SRDF.

For general best practices for EMC Cluster Enabler, refer to Remote Disaster Recovery
Concepts for Microsoft SharePoint Server 2010 with Storage Based Replication White
Paper.
For general best practices for RecoverPoint/Cluster Enabler, refer to EMC
RecoverPoint/Cluster Enabler White Paper.
VMware SRM
VMware SRM enables you to build, manage, and execute reliable disaster recovery
plans for the virtual environment.

VMware SRM best practices include:

 Group SharePoint virtual machines in fewer protection groups to enable faster
recoveries, provided that those virtual machines have no constraints
preventing them from being grouped under similar protection groups.
 In a recovery plan, the virtual machines being recovered can be assigned with
high, normal, or low priority. The dependencies between virtual machines to be
recovered should be clear so that only a certain number of required virtual
machines can be assigned as high priority for performance. The recovery time
increases as the number of virtual machines with high priority increases,
because the operations of recovering high-priority virtual machines are
executed sequentially. Based on this, EMC recommends you set all virtual
machines to Normal priority if you are concerned about recovery time objective
(RTO) of your SharePoint farm. Otherwise, you can set High priority to SQL
server, and leave other virtual machines set to Normal priority.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 77
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Install the Site Recovery Manager database as close as possible to the Site
Recovery Manager server because the round trip from the VMware SRM
database to the VMware SRM server may greatly impact the recovery time.
 Enable VMware DRS on the recovery cluster. By doing so, VMware SRM can
utilize VMware DRS for load balancing the recovered virtual machines across
the hosts for performance and RTO perspective.
 Install VMware Tools in all protected SharePoint virtual machines to accurately
acquire their heartbeats and network change notification.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 78
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Conclusion
This document highlights the key decision points in planning a Microsoft SharePoint
Server 2010 or 2013 deployment with EMC storage systems. Multiple configuration
options are available to suit most requirements for any customer. EMC storage and
data management software products are designed to provide customers the flexibility
to manage their SharePoint environments in a manner that best meets their business
needs.

Best practices for designing Microsoft SharePoint Server storage are constantly
evolving. With storage technologies rapidly improving, traditional best practices may
not apply to all configurations. This document presents a snapshot of the current best
practices recommended by EMC for deploying Microsoft SharePoint Server with the
EMC VNX family of unified storage or EMC Symmetrix VMAX series storage. Following
these guidelines can greatly assist you in achieving an efficient, high-performance,
and highly available Microsoft SharePoint Server environment that meets your
requirements.

This paper presents concepts, principles, and formulas to help you:

 Understand the I/O characteristics of Microsoft SharePoint Server 2010 and
2013.
 Understand best practices for Microsoft SharePoint Server over VNX family or
VMAX series storage.
 Use Microsoft SharePoint Server storage building block.
 Understand best practices for hypervisor which hosts the SharePoint
environment.
 Become familiar with various data protection options for SharePoint Server.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 79
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
References
EMC For additional information regarding to EMC solutions, see the documents listed
documentation below:
 Storage Pool Management Feature in EMC Virtual Storage Integrator
 EMC FAST Cache A Detailed Review
 EMC FAST VP for Unified Storage Systems A Detailed Review
 EMC VNX Virtual Provisioning Applied Technology
 EMC Efficient Blob Storage Management for Microsoft SharePoint
 EMC VNX Unified Best Practices for Performance
 EMC VNXe Series: Introduction to SMB 3.0 Support
 Implementing Full Automated Storage Tiering (FAST) for EMC Symmetrix V-Max
Series Arrays Technical Note
 EMC VNX Series Configuring NFS on VNX
 EMC CLARiiON SnapView Clones
 EMC Backup and Recovery for Microsoft Exchange and SharePoint 2010
 EMC PowerPath vs. Windows Native MPIO
 EMC VNX Series: Introduction to SMB 3.0 Support
 EMC RecoverPoint Replicating Microsoft SQL Server Technical Notes
 Microsoft SQL Server Storage Best Practices and Design Guidelines for EMC
Storage
 Remote Disaster Recovery Concepts for Microsoft SharePoint Server 2010 with
storage Based Replication White Paper

VMware For additional information regarding to VMware, see the documents listed below:
documentation
 VMware Fault Tolerance Recommendations and Considerations on VMware
vSphere 4
 Protecting Mission-Critical Workloads with VMware Fault Tolerance
 Best Practices for running VMware vSphere on Network Attached Storage
 Virtualizing Business-Critical Applications on vSphere
 VMware vSphere High Availability 5.0 Deployment Best Practices
 Best Practices for Virtual Networking
 VMware Network Virtualization Design Guide
 VMware vSphere 5.1 Documentation Center

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 80
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Microsoft For additional information regarding to Microsoft SharePoint, see the documents
documentation listed below:
 Microsoft SharePoint 2010 on VMWare Best Practices Guide
 Microsoft SQL Server 2008 R2 Remote Blob Storage
 Best Practices for Virtualizing & Managing SharePoint 2013
 SharePoint Server 2013 Search technical diagram

Product For additional information, see the product documents listed below:
documentation
 Introduction to EMC XtremSF
 Introduction to EMC XtremCache
 EMC VNX Family
 EMC VNX Series Specifications
 EMC Symmetrix VMAX Family
 EMC Replication Manager
 EMC Storage Integrator (ESI) for Windows Suit

Links Microsoft TechNet

Refer to the following topics on the Microsoft TechNet website:
 Storage and SQL Server capacity planning and configuration
 Limitations of RBS
 Disk Partition Alignment Best Practices for SQL Server
 Overview of search in SharePoint Server 2013
 Scale search for performance and availability in SharePoint Server 2013
 Enterprise Search Architectures for SharePoint Server 2013
 Best practices for people and profiles (SharePoint Server 2010)
 Best practices for SQL Server 2008 in a SharePoint Server 2010 farm
 Backup and restore best practices in SharePoint 2013
 Backup and recovery best practices (SharePoint Server 2010)
 Create a high availability architecture and strategy for SharePoint 2013
 Database Mirroring (SQL Server)
 Supported high availability and disaster recovery options for SharePoint
databases (SharePoint 2013)
 Plan for availability (SharePoint Server 2010)
 Understanding Requirements for Failover Clusters

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 81
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
MSDN Library
Refer to the following topics in the MSDN Library:
 Running RBS maintainer
 SharePoint Foundation and the Volume Shadow Copy Service
 Overview of SharePoint 2013 and the Volume Shadow Copy Service
 Availability Group Listeners, Client Connectivity, and Application Failover (SQL
Server)
 Bulk Loader—Create Unique Documents based on Wikipedia Dump File
 Load Bulk Content to SharePoint 2010
 SharePoint Performance Testing

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 82
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Appendix A: I/O characteristics analysis for SharePoint Server 2010 and
2013 search and user profile service application
Search service I/O Sizing I/O characteristics and capacity for search in SharePoint Server 2010
and capacity During the full or incremental crawl, host I/O shows the following characteristics.
characteristics
Note: The IOPS for SharePoint search related components, such as content database and
crawl database, are positively correlated with the crawl rate, which can vary widely. The
results below are from our validated test in a lab environment with the out-of-box crawl
settings. The crawl rate is an average of 70 items per second with a 200 GB data set.

Content database
Table 35 lists the I/O characteristics of the content database when running crawl.

Table 35. Content database I/O characteristics

Read I/O size Write I/O size Read/write

Avg. read IOPS Avg. write IOPS
(KB) (KB) ratio
3091 All read 8 N/A All read

The content database shows a steady read I/O rate when running the crawl, as shown
in Figure 15.

Figure 15. Content database read IOPS distribution pattern

Crawl database
Table 36 lists the I/O characteristics of the crawl database when running crawl.

Table 36. Crawl database I/O characteristics in SharePoint Server 2010

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
305 40 8 96 6:1

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 83
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 16 shows a steady pulse wave pattern for the crawl database read IOPS.

Figure 16. Crawl database read I/O pattern in SharePoint Server 2010

Figure 17 shows high write IOPS over the crawl database in the first few minutes after
starting the crawl, then it maintains very low write IOPS.

Figure 17. Crawl database write I/O pattern in SharePoint Server 2010

In our validated environment, the capacity of the crawl database is positively

correlated with the total number of crawlable items and crawl times. Microsoft
recommends using the following formula to calculate the capacity of the crawl
database:

For details, refer to the Storage and SQL Server capacity planning and configuration.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 84
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Property database
Table 37 lists the I/O characteristics of the property database when running crawl.

Table 37. Property database I/O characteristics in SharePoint Server 2010

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
Near zero Change with 8 From 16 to 96 N/A
write I/O size

On average, although average read IOPS is almost zero, there are some spikes spread
over the crawl process. Figure 18 shows the read IOPS spikes in SharePoint Server
2010.

Figure 18. Property store database read I/O pattern in SharePoint Server 2010

Property store database write size changes with time, reducing in size from 96 KB to
16 KB; as a result, the write IOPS size increases from 10 to 330, as shown in Figure
19 and Figure 20.

Figure 19. Property store database write I/O size pattern in SharePoint Server 2010

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 85
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 20. Property store database write I/O pattern in SharePoint Server 2010

The size of the property store database is positively correlated with the number and
size of metadata for each crawlable item. Microsoft recommends that you to use the
following formula to calculate the capacity of Property database.

For details, refer to Storage and SQL Server capacity planning and configuration.

Search administration database

The search administration database shows almost no IOPS during crawl. Table 38
shows the I/O characteristics.

Table 38. Search administration database I/O characteristics in SharePoint Server 2010

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
Near zero Near zero 32 8 N/A

The search administration database is typically small, with 10 GB allocated.

Crawl component
Table 39 shows the crawl component I/O characteristics.

Table 39. Crawl component I/O characteristics in SharePoint Server 2010

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
Near zero 32 64 64 Write dominant

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 86
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 21 shows that the pulse wave pattern of the crawl component write I/O with
average peak IOPS around 32.

Figure 21. Crawl component I/O read pattern in SharePoint Server 2010

The crawl component only stores a temporary index file, so it is sufficient to allocate a
small capacity to the crawl component. For 100 GB of content data, allocate 1 GB of
capacity for the crawl component.

Query component
Table 40 shows the query component I/O characteristics.

Table 40. Query component I/O characteristics

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
19 43 32 128 Write dominant

Read IOPS shows a clear pulse wave pattern with 19 IOPS as peak, and the same
applies to write IOPS, whose peak is around 43, as shown in Figure 22 and Figure 23.

Figure 22. Query component read I/O pattern in SharePoint Server 2010

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 87
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 23. Query component write I/O pattern in SharePoint Server 2010

The query component stores index files. EMC recommends allocating 2 GB for a 100
GB data set.

Sizing I/O characteristics and capacity for search in SharePoint Server 2013
FAST search technology was first introduced in SharePoint Server 2013 as the out-of-
box server search technology. Therefore, the I/O characteristics are very different
from what it was in SharePoint Server 2010.

Note: The IOPS for SharePoint search-related components, such as the content database
and the crawl database, are positively correlated with the crawl rate, which can vary widely.
The following results are from our validated test in a lab environment with out-of-box crawl
settings. The crawl rate is an average of 76 items per second with a 200 GB data set.

Content database
Table 41 lists the I/O characteristics of the content database when running crawl.

Table 41. Content database I/O characteristics when running crawl in SharePoint Server
2013

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
3445 All read 8 N/A All read

The content database shows a steady read I/O rate when running the crawl, as shown
in Figure 24.

Figure 24. Content database read IOPS distribution pattern in SharePoint Server 2013

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 88
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Crawl database
Table 42 lists the I/O characteristics of the crawl database when running crawl.

Table 42. Crawl database I/O characteristics in SharePoint Server 2013

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
260 200/40 8 32 29:11

Read I/O for the crawl database shows a pulse wave pattern in the second half of the
crawl process, where the majority of the read I/O happens, as shown in Figure 25.

Figure 25. Crawl database read IOPS pattern in SharePoint Server 2013

Write I/O shows a clear pulse wave pattern, as shown in Figure 26. The first half of the
crawl generates more write IOPS than the second half.

Figure 26. Crawl database write IOPS pattern in SharePoint Server 2013

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 89
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The Microsoft recommendation for crawl database capacity sizing in SharePoint
Server 2013 is shown in Table 43.
Table 43. Crawl database capacity planning

Database 10 M items 100 M items

Crawl 15 GB for data, 2 GB for log 110 GB for data, 2 GB for log

For details, refer to Storage and SQL Server capacity planning and configuration.

Link, analytics reporting, and search administration databases

The link database, analytics reporting database, and search administration database
show almost no IOPS during crawl. Table 44 lists the I/O characteristics of each
database.

Table 44. I/O characteristics of link, search administration and analytics reporting
database

Database Avg. read Avg. write Read I/O Write I/O Read/write
name IOPS IOPS size (KB) size (KB) ratio
Link database Near zero Near zero 8 64 N/A

Search Near zero Near zero 64 8 N/A

administration
database

Analytics Near zero zero 8 N/A N/A

reporting
database

Microsoft recommends the crawl database capacity sizing for SharePoint Server 2013
shown in Table 45.

Table 45. Capacity planning of link, search administration and analytics reporting database

Database 10 M items 100 M items

Link 10 GB for data, 0.1 GB for 80 GB for data, 5 GB for log
log

Analytics Reporting Usage dependent Usage dependent

Search Administration 0.4 GB data, 1 GB log 1 GB data, 2 GB log

For details, refer to Storage and SQL Server capacity planning and configuration.

Crawler
Table 46 shows the I/O characteristics when running crawl.

Table 46. Crawler I/O characteristics in SharePoint Server 2013

Avg. peak read Read I/O size Write I/O size Read/write
Avg. write IOPS
IOPS (KB) (KB) ratio
Near zero 115 4 128 Write dominant

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 90
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
The crawler write IOPS rate produces a flat pattern, as shown in Figure 27.

Figure 27. Crawler write I/O pattern in SharePoint Server 2013

Crawler capacity requirements are small because only temporary data is stored when
running the crawl. Our validated tests in the EMC lab indicate that you should allocate
1 GB for each 100 GB data set.

Index partition
Table 47 shows the index partition I/O characteristics when running crawl.

Table 47. Index partition I/O characteristics in SharePoint Server 2013

Avg. peak read Avg. peak write Read I/O size Write I/O size Read/write
IOPS IOPS (KB) (KB) ratio
150 35 2048 1024 3:2

Read IOPS for the index partition shows an increasing pulse wave pattern, as shown
in Figure 28.

Figure 28. Index partition read IOPS pattern in SharePoint Server 2013

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 91
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 The write IOPS for the index partition produces a much steadier pattern, as shown in
Figure 29.

Figure 29. Index partition write IOPS pattern in SharePoint Server 2013

The size of the index partition can vary depending on several factors, including file
type and file size. In our validated lab environment, the majority of the file types are
DOCX, XLSX, PPTX, and HTML; the average file size is 250 KB. In this scenario, a 100
GB data set requires a 5 GB index partition allocation.

User profile Sizing I/O characteristics and capacity for a user profile in SharePoint Server 2010
service I/O and During full or incremental profile synchronization, host I/O shows the following
capacity characteristics:
characteristics
Synchronization database
Table 48 lists the I/O characteristics of the synchronization database when running
profile synchronization.

Table 48. Synchronization database I/O characteristics in SharePoint Server 2010

Avg. peak write Read I/O size Write I/O size Read/write
Avg. Read IOPS
IOPS (KB) (KB) ratio
Almost zero 26 64 32 Write dominant

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 92
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 30 shows the characteristics of write IOPS against a synchronization database
as a pulsed wave pattern. The average peak IOPS is around 26, as shown in Table 48.

Figure 30. Pulsed wave pattern for synchronization database write IOPS in SharePoint
Server 2010

Microsoft recommends that with default settings in an environment that has few
groups per user, the synchronizing database requires approximately 630 KB per user
profile. 90 percent of the space is used by the data file.

For details, refer to Storage and SQL Server capacity planning and configuration.

Profile database
Table 49 lists the I/O characteristics for a profile database when running profile
synchronization.

Table 49. Profile database I/O characteristics in SharePoint Server 2010

Avg. Write Read I/O size Write I/O size Read/write

Avg. Read IOPS
IOPS (KB) (KB) ratio
Almost zero 300 64 16 Write dominant

Figure 31 shows the distribution pattern of write IOPS. Profile database write IOPS
start in the second half of the profile synchronization cycle. The 300 average write
IOPS in Table 49 are calculated only when the writes take place.

Figure 31. Distribution pattern of profile database write I/O in SharePoint Server 2010

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 93
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 32 shows the combination of the synchronization write IOPS chart and the
profile database write IOPS chart. It shows that write IOPS for synchronization and the
profile database happens in sequence.

Figure 32. Write IOPS for both profile synchronization database and synchronization
database in SharePoint Server 2010

Microsoft suggests that with default settings and in an environment configured to use
Active Directory, the profile database requires approximately 1 MB per user profile.

For details, refer to Storage and SQL Server capacity planning and configuration.

Social database
During profile synchronization, the social database is almost under no I/O pressure.

Microsoft recommends that, with default settings, the social database requires
approximately 0.009 MB per tag, comment, or rating.

For details, refer to Storage and SQL Server capacity planning and configuration.

Sizing I/O characteristics and capacity for user profiles in SharePoint Server 2013
Profile synchronization in SharePoint Server 2013 shares the same technology with
SharePoint Server 2010. The I/O pattern during full or incremental crawl is similar
between the two versions.

Synchronization database
Table 50 lists the I/O characteristics of the synchronization database when running
profile synchronization.

Table 50. Synchronization database I/O characteristics in SharePoint Server 2013

Avg. Peak write Read I/O size Write I/O size Read/write
Avg. Read IOPS
IOPS (KB) (KB) ratio
Almost zero 27 64 32 Write dominant

Figure 33 shows the characteristics of write IOPS against the synchronization

database as a pulsed wave pattern. The average peak IOPS is around 27, as shown in
Table 50. The write IOPS are distributed in the first half of the profile synchronization
cycle.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 94
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 33. Pulsed wave pattern for synchronization database write IOPS in SharePoint
Server 2013

In our validated lab environment for the same Active Directory, the size of the
synchronization database is four times larger than in SharePoint Server 2010. Based
on this, EMC recommends allocating 2.5 MB of capacity for each user profile with
default settings.

Profile database
Table 51 lists the I/O characteristics for a profile database when running profile
synchronization. The write IOPS are much fewer than in SharePoint Server 2010 when
running profile synchronization.

Table 51. Profile database I/O characteristics in SharePoint Server 2013

Avg. peak write Read I/O size Write I/O size Read/write
Avg. Read IOPS
IOPS (KB) (KB) ratio
Almost zero 31 64 32 Write dominant

Figure 34 shows the pulsed wave pattern of write IOPS over the profile database. The
profile database write IOPS start at the second half of the profile synchronization
cycle and the average peak write IOPS is around 31, as shown in Table 51.

Figure 34. Pulsed wave pattern of profile database write I/O in SharePoint Server 2013

Figure 35 shows the combination of the synchronization write IOPS chart and the
profile database write IOPS chart. It shows that write IOPS for synchronization and the
profile database happen in sequence.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 95
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 35. Write IOPS for both profile synchronization database and synchronization
database in SharePoint Server 2013

In our validated lab environment, the profile database size in SharePoint Server 2013
is almost the same as in SharePoint Server 2010. Based on this, EMC recommends
using 1 MB per user profile with default settings.

Social database
During profile synchronization, the social database is almost under no I/O pressure.

In our validated lab environment, the social database size in SharePoint Server 2013
is almost twice the size of the one in SharePoint Server 2010. It is recommended that
with default settings, the social database requires approximately 0.009 MB per tag,
comment, or rating.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 96
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Appendix B: Tools for SharePoint Server performance testing,
monitoring, tuning, and sizing
The primary goal of monitoring is to ensure a healthy SharePoint Server 2010 or 2013
environment so that you can achieve service performance objectives, such as short
response times. You can use the monitoring features from the SharePoint Central
Administration website, System Center Management Pack for SharePoint Server 2010
and 2013, and Windows PowerShell scripts to monitor the SharePoint Server 2010
and 2013 environment and services.

Logs and reports track SharePoint Server 2013 environment and service status. You
can read the logs from the logging database. The advantage of using the logging
database is that you can configure your view and export the logs to Excel. The logs
and reports from Central Administration help you to understand how the SharePoint
Server 2010 or 2013 system is running, analyze and repair problems, and view
metrics for the sites. In addition, System Center Management Pack for SharePoint
Server 2010 and 2013 provides an end-to-end monitoring and reporting system that
you can use to monitor SharePoint Server 2010 and 2013. Table 52 lists the tools for
each level of use.

Table 52. Tools used for SharePoint Server performance monitoring, tuning and sizing

Tool Source/Links Description Level

EMC DBclassify EMC Database Performance Constantly monitors data, Application
Tiering Solutions learns its patterns and past
behavior, and then classifies
and moves it according to
business priorities.

Developer Microsoft (SharePoint Server Provides diagnostic Application

dashboard 2010/2013 built-in feature) information that can help a
developer or system
administrator to troubleshoot
problems with page
components that would
otherwise be very difficult to
isolate.

Unified Logging Microsoft (SharePoint Server A unified logging system to Application

System (ULS) 2010/2013 built-in feature) help administer all aspects of
the entire SharePoint
environment.

System Center Microsoft system Center Enables operators and Application

Management Management Pack for administrators to manage
Pack for SharePoint Server 2013 Microsoft SharePoint Server
SharePoint 2013 products, including
Server 2013 SharePoint Server, project
server, and search server.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 97
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Microsoft Microsoft SharePoint 2010 Enables operators and Application
SharePoint Products Management pack administrators to manage
Server 2010 for System Center Microsoft SharePoint Server
Products Operations Manager 2007 2010 products
Management
Pack for System
Center
Operations
Manager 2007

EMC workload EMC mitrend Also known as Mitrend. Hypervisor, storage,

performance Automated online workload OS and server cache
assessment performance assessment tool,
which correlates and displays
key performance information
related to sizing.

PAL Performance Analysis of Useful for troubleshooting OS and storage

Logs (PAL) Tool performance issues.

VSPEX EMC Business Value Can be used to determine the Application, OS and
SharePoint recommended VSPEX Proven storage
sizing tool Infrastructure for virtualized
SharePoint Server based on
the user requirements.

T-SQL Microsoft (comes with SQL Provides Transact-SQL system Application

server installation) stored procedures to create
traces on an instance of the
SQL Server Database Engine.

SQL Server Microsoft Provides SQL Trace capture Application

profiler and replay in a graphic user
interface.

Perfmon Windows performance Tracks the performance Application, OS and

monitor ( comes with characteristics of SharePoint storage
windows server installation) farm workloads.

vSphere Client vSphere client GUI Primary tool to track Hypervisor

GUI interface performance and configure
data for one or more ESX/ESXi
hosts.

Resxtop/Esxtop ESX/ESXi Provides a performance Hypervisor

matrix, but requires root
access.

Unisphere Included with EMC storage Provides performance Storage

Analyzer systems monitoring for EMC storage
systems.

XtremCache Search EMC support Provides a performance Server cache

performance predictor tool for EMC
predictor tool XtremCache to assess and
evaluate the SharePoint
environment for the
XtremCache.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 98
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 EMC Storage Available through EMC pre- Assists in defining tiering Storage
Configuration sales and post-sales policies for an existing
Advisor environment; Tier Advisor
monitors I/O and recommends
tiering policy settings.

Bulk Loader Bulk Loader-Create Unique Tool to create raw data to Application testing
Documents based on upload to SharePoint.
Wikipedia Dump File

LoadBulk2SP Load Bulk Content to Tool to load documents into

SharePoint 2010 SharePoint.

Sample script for SharePoint Performance Sample script in Visual Studio

SharePoint Testing to provide load and stress
performance tests for SharePoint functions.
testing

EMC DBclassify EMC DBclassify™ is a database optimization solution that reduces the TCO of
database storage, while enhancing the performance of business applications.

For detailed best practices, refer to Microsoft SQL Server Storage Best Practices and
Design Guidelines for EMC Storage White Paper.

Developer The developer dashboard is introduced in SharePoint Server 2010 and enhanced in
dashboard SharePoint Server 2013, which is designed to provide additional performance and
tracing information that can be used to debug and troubleshoot issues. The
dashboard is turned off by default, but can be enabled via the object model, stsadm
and PowerShell.

Use the following Windows PowerShell cmdlets to enable the developer dashboard:
(Get-SPFarm).PerformanceMonitor.DeveloperDashboardLevel = ”On”

When the dashboard is turned on you can find information about SQL query, service
call, ULS, and execution times that occur as part of the page rendering process.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 99
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Figure 36 shows a typical screen of the developer dashboard in SharePoint Server
2013.

Figure 36. Developer dashboard in SharePoint Server 2013

EMC recommends using the developer dashboard for troubleshooting page-level

performance issues.

ULS Unified Logging System (ULS) can track problems with SharePoint components,
provide quantifiable statistics for SharePoint, help troubleshoot issues, and monitor
overall health.

EMC recommends the following best practices to use SharePoint ULS logging:
 Avoid keeping the log files on the same drive where SharePoint is installed. Use
the following PowerShell cmdlet to change the default location for ULS log:
Set-SPDiagnosticConfig -LogLocation <PathToNewLocation>

 Restrict ULS log size. Use the following PowerShell cmdlet to configure disk
space usage for ULS:
Set-SPDiagnosticConfig -LogMaxDiskSpaceUsageEnabled
Set-SPDiagnosticConfig -LogDiskSpaceUsageGB <UsageInGB>

 Use verbose only when necessary, and then revert back. Use the following
PowerShell cmdlet to set the verbose logging level:
Set-SPLogLevel -TraceSeverity Verbose

System Center The Microsoft SharePoint Server 2010 and 2013 Management Pack is designed for:
Management Pack
 Health monitoring of SharePoint Server 2010 and 2013 product events
for SharePoint
Server 2010 and  Collecting SharePoint component-specific performance counters in one central
2013 location
 Raising alerts for operator intervention as necessary
 Indicating, correcting, and preventing possible service outages or configuration
problems by detecting, sending alerts, and automatically correlating critical

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 100
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 events, allowing you to proactively manage SharePoint servers and identify
issues before they become critical.

EMC Workload The EMC Workload Performance Assessment tool is available to EMC partners. This
Performance automated online tool correlates and displays key performance information related to
Assessment Tool sizing. This tool is available from your reseller or EMC presales systems engineer.

PAL You can use the open source Performance Analyzer of Logs (PAL) tool to troubleshoot
performance issues (as opposed to sizing for migrations). You can use performance
monitor with the PAL tool, which can be downloaded from the CodePlex website.

VSPEX SharePoint The VSPEX SharePoint Server sizing tool is available to size VSPEX Proven
Server sizing tool Infrastructure for virtualized SharePoint Server based on user requirements. You can
also use the sizing estimate for other virtualized environments on EMC VNX storage.
For details, refer to EMC VSPEX for Virtualized Microsoft SharePoint 2013 Design
Guide.

Sample tool to In this validated testing environment, we used the Bulk Loader tool to create unique
create large documents. This command-line tool, written using the Microsoft .NET 4.0 Framework,
number of random can create unique documents based on a Wikipedia dump file. The utility enables you
documents to create up to 10 million unique Word, Excel, PowerPoint, and HTML files of various
sizes so you can load different content types directly into the SharePoint Server 2013
Document Libraries.

For more information on the bulk loader tool, refer to Bulk Loader—Create Unique
Documents based on Wikipedia Dump File.

Sample tool to In this validated testing environment, we used the LoadBulk2SP tool to load
load documents documents into the SharePoint Server. The tool was written using C# and the
into SharePoint Microsoft .NET 3.5 Framework to be compatible with SharePoint Server. This tool
takes the Bulk Loader tool disk output files as input for loading directly into the
SharePoint Server, mimicking the same folder and file structure, and using the
targeted web applications and document libraries specified in the application
configuration.

For more information on the LoadBulk2SP tool, refer to Load Bulk Content to
SharePoint 2010.

Sample code for In this validated testing environment, we used sample project in Visual Studio 2010
SharePoint to provide load and stress testing for search, document download, and view pages
performance scenarios. Refer to the sample project in SharePoint Performance Testing and
testing customize in your own environment to validate the SharePoint Server 2013
performance.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 101
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Others Other tools listed in Table 52 also help to monitor and tune all aspects of SharePoint
server performance. For details, refer to Microsoft SQL Server Storage Best Practices
and Design Guidelines for EMC Storage White Paper.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 102
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Appendix C: Sample storage designs and reference architectures
Overview This section introduces an example of how to size a SharePoint Server 2013 farm.

The methodology also applies to SharePoint Server 2010. Refer to I/O characteristics
and capacity for content database in SharePoint Server 2010 to change the formula
to size the content databases.

Note: You can use the VSPEX sizing tool to automatically complete the sizing calculation.
This tool implemented the sizing logic in this section. It is easy to use and it saves time and
energy for the sizing calculations.

High-level steps for SharePoint farm sizing

1. SharePoint topology and compute resource sizing—Determine the
SharePoint topology based on customer requirements, including:
 Number of web server roles and required compute resources
 Number of application server roles and required compute resources
 Database server compute resource sizing
2. Storage layout sizing—Determine the storage requirement for a SharePoint
farm based on the customer requirements, including:
 Content database pool storage layout
 Services pool storage layout
 My Site pool storage layout

Note: If the customer has more than one SharePoint farm, repeat Step 1 and Step 2 to
size all the SharePoint farms.

SharePoint Server The SharePoint farm is made up of SharePoint servers with different roles. Topology
2013 topology and sizing and design determines how to distribute the roles on a certain number of
compute resource servers. With a good topology design, compute resources are appropriately
sizing distributed and customer requirements for the SharePoint application are satisfied.
This section introduces a high-level view of sizing the SharePoint farm topology and
compute resources.

Servers in the SharePoint farm have three roles: web server, application server, and
database server. EMC recommends that you to size the web servers first, use the
result to size the application servers, and then size the database servers.

Sizing web servers

The web server directly manages user requests, handling the basic process and
rendering the information required by the user. When necessary, it passes requests to
the back-end application servers for further processing. The web server role helps you
to size the farm.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 103
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 The qualification sheet contains the information needed to size the farm. To size the
web server for the SharePoint farm, you need the following information:
 The number of users
 The percentage of user concurrency at peak
 Whether or not the farm is accessed globally
 The main purpose of the web application (publishing or document
management)

The answers to these questions help you to figure out the maximum number of active
users. The formula for calculating the number of active users is as follows:
( )

Web applications with different purposes have different access characteristics, which
can result in different web server resource consumptions. For example, we used the
numbers in Table 53 to define the relationship between the number of active users
and the number of web servers.

Table 53. Sizing the number of web servers by the number of active users

Main purpose of Number of active users Number of web servers

web application
Publishing Portal Less than 120 1 (web server with application server on one
machine)

From 120 to 750 1

From 751 to 1,506 2

From 1,507 to 2,948 3

From 2,949 to 3,785 4

From 3,786 to 4,528 5

Document Less than 120 1 (web server with application server on one
Management Portal machine)

From 120 to 582 1

From 583 to 1,152 2

From 1,153 to 2,094 3

From 2,095 to 2,652 4

From 2,653 to 3,144 5

Note: The number of active users can be transferred to request per second (RPS) under a
specific kind of user load. For example, for a heavy user load where one user generates 60
requests per hour and with 600 active users, the calculation would be:
⁄ ⁄
RPS is a key metric to collect when validating the SharePoint solution.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 104
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Sizing compute resource for web servers
After finalizing the number of web servers, we used the following best practices to
calculate the compute resource (vCPU and memory) of the web servers:
 Each web server should have four cores for vCPU and 12 GB of memory.
 If the web server also includes the crawler role of the search application (all-in-
one topology), the best practice is to assign this server 12 cores for vCPU and
12 GB of memory.

Table 54 lists the detailed information we used to calculate the web server compute
resources.

Table 54. Web server compute resource assignment

Server type vCPU Memory

Web server 4 12 GB

Web server (including application server role) 12 12 GB

After sizing the web servers, size the application servers.

Sizing application servers

The application server hosts most of the load from the service applications. Using the
appropriate number of application servers ensures that the service application
functions as expected.

Farm administrators can provision service applications and assign specific

application servers to run them. We mainly focus on the application servers that host
the search application.

The application server for the search service has six roles. General guidelines for
scaling the application servers to satisfy common search usage are provided in Table
55 and Table 56.

We used the numbers from the web server sizing to establish a benchmark for the
user load. A certain percentage of the requests generated by end users are search
requests. There is a relationship between the number of active users and the search
request load, as shown in Table 55 and Table 56.

Use Table 55 and Table 56 to confirm the number of application servers and their
roles. If the customer has a large amount of content to be searched with a high
expectation of search content freshness, refer to Table 55 to size the application
servers. If not, refer to Table 56 to size the application servers.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 105
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Table 55. Sizing application servers for a normal farm

Number of Number of Description

web servers application
servers
1 Web server and application role server co-exist in one box

2 1 All-in-one

3 2 One server is crawler-type

The other is query-type

4 2 One is crawler-type
The other one is query-type

Table 56. Sizing application servers to search a heavily used farm

Number of Number of Description

web servers application
servers
1 Web server and application server role co-exist in one box

2 2 One server is crawler-type

The other one is query-type application server

3 4 Two crawler-type
Two query-type

4 4 Two crawler-type
Two query-type

5 4 Two crawler-type
Two query-type

Sizing compute resource for application servers

We used the following best practices to size the compute resources for the
application servers:
 Application servers should have four cores for vCPU and 12 GB of memory.
 Any server running the crawler role of the search service application should
have 12 cores of vCPU and 12 GB of memory.
Table 57 shows the compute resource details for each type of application server.

Table 57. Application server compute resource assignment

Server type vCPU Memory

Application (query-type) 4 12 GB

Application (crawler-type) 12 12 GB

Application (all-in-one) 12 12 GB

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 106
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Sizing database servers
SharePoint Server 2013 uses SQL server as its database engine to store the content
databases and the databases of the service applications. Assigning the proper
compute resources to the database engine is important for a well-functioning
SharePoint farm.

A SharePoint farm can contain more than one SQL Server instance. Customers can
choose multiple SQL Server instances to serve the SharePoint farm. In this document,
we used only one SQL Server instance. We sized the compute resources for this SQL
Server as follows:

Sizing computing resource for database servers

The sizing process for the SQL Server for SharePoint Server 2013 can be divided into
two parts: CPU and memory.

Table 58 and Table 59 show the detailed information of the vCPU and memory
resources for SQL Server.

Table 58. Sizing SQL Server vCPU resource for SharePoint Server 2013

Number of active users Number of web servers vCPU resource

Less than 1,000 1 or 2 4 cores

Equal or more than 1,000 Less than 5 8 cores

5 16 cores

Table 59. Sizing SQL Server memory resource for SharePoint Server 2013

Number of active users Memory resource

Less than 1,000 8 GB

Equal or more than 1,000 16 GB

After the sizing of the SharePoint virtual machines and the SQL Server virtual
machines is completed, size the storage backend next.

Sizing storage SharePoint contents that need to be stored can be classified by their uses:
layout
 Content databases—Site content and site settings, for example, site pages,
documents, metadata, and permission settings.
 Service application databases and files—Data and settings of specific service
applications.
 Content database hosting My Sites—User’s My Site content.
 Server’s OS volumes

These four kinds of content have different performance characteristics. According to

their storage access characteristics, we divide the storage into four pools:
 Content database pool (RAID 5)
 SharePoint services pool (RAID 10)

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 107
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
  My Sites pool (RAID 6)
 Virtual machine OS pool that stores the OS volumes of the SharePoint servers
(RAID 5)

When sizing storage pools, we should compare the results of both performance-
based and capacity-based calculations. Choose the larger number. This ensures both
requirements are satisfied.

Sizing content database pool

This section describes how to size the content database pool. EMC recommends
calculating for performance first, and then for capacity.

Sizing content database pool from performance perspective

Figure 37 and Figure 38 show the test results of the relationship between the
numbers of active users and host IOPS for the content database.

Figure 37. Test result of active user number and host IOPS relationship for search intensive
Publishing Portal

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 108
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Figure 38. Test result of active user number and host IOPS relationship for search intensive
Document Management Portal

As the number of active users grows, the host IOPS on content databases grow in a
linear way. According to the linear relationship, we were able to calculate the host
IOPS for any given number of active users. We used the host IOPS to size the content
database storage pool.

Use the following formula to calculate the host IOPS:

 For the search intensive Publishing Portal:

 For the search intensive Document Management Portal:

Use the following formula to calculate the backend IOPS from the host IOPS:
 For the Publishing Portal, the read/write ratio is 3:1 with RAID 5.

 For Document Management Portal, the read/write ratio is 2:1 with RAID 5.

Use the following formula to calculate the number of disks:

⁄

The IOPS per disk can vary for different types of disk.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 109
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Finally, we used RAID 5 (4+1). The final number of disks should be rounded up to five.
An example of sizing content database pool provides an example of a detailed sizing
calculation.

Sizing content database pool from capacity perspective

Use the following formula to calculate the content database LUN size. We reserved 30
percent of storage space as a buffer:
( )

Use the following formula to get the number of disks:

⁄

When calculating the number of disks, we used the disk’s usable capacity. This value
can vary for different raw capacity disks.

An example of sizing content database pool

A customer has the requirements for his SharePoint Server 2013 farm, as shown in
Table 60.
Table 60. Example items for sizing SharePoint Server 2013 farm

Items Value

Content size annual growth rate 20 percent

Web application globally access No

Initial farm size 4 TB

Number of users 10,000

User concurrency at peak 50 percent

Main purpose of web application Publishing Portal

My Site function No

SharePoint search function Heavily relied on

Enable FAST VP on storage No

Performance perspective
For this example, you can calculate the content database pool from performance
perspective as follows:

( ) ( )

⁄ ⁄

Finally, round up the number of disks by five for RAID 5. In this example, 15 disks are
needed from the IOPS perspective.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 110
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Capacity perspective
For this example, the initial farm content size is 4,000 GB. The growth rate is 20
percent and the number of years for growth is two.

The usable capacity available per 600 GB 15k SAS drive is 537 GB.
⁄

When rounded up by five for RAID 5, the capacity requirement is 15 disks.

Performance versus capacity

This example requires 15 disks from an IOPS perspective and 15 disks from a
capacity perspective. If they are not equal, choose the larger one.

If the selected farm is not search intensive, subtract 15 percent of the host I/O from
the previous calculation result to support the impact caused by frequent incremental
crawls on the content databases.

To enable FAST VP, EMC recommends you use RAID 10 (1+1) flash disk and RAID 6
(6+2) NL-SAS for the content database storage pool.

Sizing services pool

This section describes how to size the service pool. As in sizing the content database
pool, we calculated from both the performance perspective and the capacity
perspective.

Sizing services pool from performance perspective

Table 61 and Table 62 detail the service pool sizing from a performance perspective.
The search-intensive SharePoint farm generates sequential IOPS for the service pool.
Refer to Table 61 and Table 62 to find the appropriate number of disks based on the
customer’s business requirements.

Table 61. Sizing the application server for non-intensive search farm

No. of web No. of Description VNXe (SAS 15K) VNX (SAS 15K)
servers application
servers
1 1 Web server and RAID 10 (3+3) RAID 10 (1+1)
application in one 6 disks 2 disks
box

2 1 All-in-one RAID 10 (3+3) RAID 10 (2+2)

6 disks 4 disks

3 2 One query-type RAID 10 (3+3) RAID 10 (4+4)

One crawler-type 6 disks 8 disks

4 2 One query-type RAID 10 (3+3) RAID 10 (4+4)

One crawler-type 6 disks 8 disks

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 111
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 No. of web No. of Description VNXe (SAS 15K) VNX (SAS 15K)
servers application
servers
5 2 One query-type RAID 10 (3+3) RAID 10 (4+4)
One crawler-type 6 disks 8 disks

Table 62. Sizing the application server for intensive search farm

No. of No. of Description VNXe (SAS 15K) VNX (SAS 15K)

web application
servers server
1 1 All Service Roles in one RAID 10 (3+3) RAID 10 (3+3)
box 6 disks 6 disks

2 2 One query-type RAID 10 (3+3) RAID 10 (4+4)

One crawler-type 6 disks 8 disks

3 4 Two query-type RAID 10 (3+3) RAID 10 (4+4)

Two crawler-type 12 disks 16 disks

4 4 Two query-type RAID 10 (3+3) RAID 10 (4+4)

Two crawler-type 12 disks 16 disks

5 4 Two query-type RAID 10 (3+3) RAID 10 (4+4)

Two crawler-type 12 disks 16 disks

Sizing services pool from capacity perspective

EMC recommends that the services pool capacity requirement is 30 percent of the
content capacity.

For example, if the farm content capacity requirement is 12 TB:

⁄

For the RAID 10 (3+3) service pool, we round up the number of disks to six. For RAID
10 (4+4) services pool, we need to round up the number of disks to eight. In this
example, if the RAID 10 is (3+3), the capacity requirement should be 12 disks for the
services pool.

Sizing My Site pool

For the My Site pool, we used RAID 6 with the NL-SAS disk type. Since My Site is used
by fewer people, when sizing a My Site pool, we only consider the capacity.

The formula for calculating the number of disks for the My Site pool is:

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 112
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Appendix D: Optimized setting in SQL Server for SharePoint
The Optimized settings for SQL Server are listed as follows:
 Do not enable AUTO_CREATE_STATISTICS on a server that hosts SQL Server and
SharePoint Server. Enabling AUTO_CREATE_STATISTICS is not supported for
SharePoint Server. SharePoint Server configures the required settings during
provisioning and upgrade. Manually enabling AUTO_CREATE_STATISTICS on a
SharePoint database can significantly change the execution plan of a query.
The SharePoint databases either use a stored procedure that maintains the
statistics (proc_UpdateStatistics) or rely on SQL Server to do this.
 Set the maximum degree of parallelism option to 1 for SQL Server instances
hosting SharePoint Server 2010 and SharePoint Server 2013 databases to
ensure that each request is served by a single SQL Server process.
 Set the database autogrowth values as a percentage instead of a fixed number
of megabytes. The larger the database, the larger the growth increment should
be. Consider, for example, that we used 10 percent autogrowth for the
SharePoint databases.
 EMC recommends that you continuously monitor SQL Server storage and
performance to ensure that each production database server is adequately
handling its load.
 Use the full recovery model for the SharePoint content database and the simple
recovery model for the SharePoint services database:
 The full recovery model enables administrators to back up the transaction
logs incrementally. It enables recovery of the SharePoint content database
from a specific point-in-time from log backup, even if the data files of the
content databases are corrupt. EMC recommends that you monitor the
growth of the log file and take log backups regularly for the full recovery
model.
 The simple recovery model automatically reclaims log space to keep the
space requirement small, essentially eliminating the need to manage the
transaction log space. However, simple recovery cannot support log
backups.

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 113
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
Appendix E: Scripts to break down items in the content database
Understanding the detailed information of items in a SharePoint farm is very
important for sizing and designing. The information includes: Item number, item type,
average size, and the maximum item size.

In order to get the information, use the scripts in Figure 39 to generate a report for
content database. Replace the content database name in the script with the actual
name in your environment to prepare this script.
use master
go

if object_id('sumcontentsize') is not null drop table

sumcontentsize
create table sumcontentsize(extension varchar(100), summation
DECIMAL (20,5),countnum DECIMAL (20,5),maxsize DECIMAL(20,5))
go
sp_MSforeachdb 'use [?] if ''?'' like ''content database name''
begin
--need to change the content database name
insert into master.dbo.sumcontentsize
select extension, SUM (CAST ([size]/1000.00000 AS DECIMAL
(20,5)))as [Size Summuation of Doc Type (kb)],
count(extension) as [Count], MAX (CAST ([size]/1000.00000 AS
DECIMAL (20,5)))
from [?].dbo.alldocs
where extension like ''doc'' or extension like ''docx'' or
extension like ''xlsx'' or extension like ''pptx'' or extension
like ''mpp'' or extension like ''jpg'' or extension like ''gif''
or extension like ''vsd''
group by extension
end'
--need to change the file type above

select extension,
sum(convert(DECIMAL(20,5),summation)) AS [Total Summation],
sum(convert(DECIMAL(20,0),countnum)) AS [Total Count],
sum(convert(DECIMAL(20,5),summation))/sum(convert(DECIMAL(20,5),co
untnum)) AS [Avg doc size],
AVG(convert(DECIMAL(20,5),maxsize)) AS [MAX SIZE]
from sumcontentsize group by extension

Figure 39. Scripts to generate the report for a content database

Table 63 shows a sample output to break down items in a content database.

Table 63. Sample output to break down items in a content database

Maximum
Extension Total summation (KB) Total count Average doc size (KB)
size (KB)
doc 1,182.72 55 21.504 21.504

docx 326,896,188.8 970,351 336.884476 49,137.197

gif 191.165 28 6.827321 24.363

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 114
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products
 Maximum
Extension Total summation (KB) Total count Average doc size (KB)
size (KB)
jpg 73.84 7 10.548571 28.113

pptx 343,079,641.1 985,550 348.109828 742.837

xlsx 300,081,942.2 979,624 306.323591 2,813.764

Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage 115
EMC VNX family, EMC Symmetrix VMAX systems, EMC Xtrem Server products