EMC VSPEX for Virtualized Microsoft SharePoint 2013€¦ · Contents EMC VSPEX for Virtualized...

DESIGN GUIDE

EMC VSPEX FOR VIRTUALIZED MICROSOFT SHAREPOINT 2013

EMC VSPEX

Abstract

This Design Guide describes how to design virtualized SharePoint resources on the appropriate EMC® VSPEX™ Private Cloud solutions for Microsoft Hyper-V or VMware vSphere. This Design Guide also illustrates how to use the available VSPEX Sizing Tool, allocate resources following best practices, and leverage all the benefits that VSPEX offers.

June 2013

2 EMC VSPEX for Virtualized Microsoft SharePoint 2013 Design Guide

Copyright © 2013 EMC Corporation. All rights reserved. Published in the USA.

Published June 2013.

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.

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

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

EMC VSPEX for Virtualized Microsoft SharePoint 2013 Design Guide

Part Number H11769

http://www.emc.com/legal/emc-corporation-trademarks.htm

http://www.emc.com/legal/emc-corporation-trademarks.htm

Contents


Contents

Chapter 1 Introduction 9

Purpose of this guide ................................................................................................ 10

Business value ......................................................................................................... 10

Scope ....................................................................................................................... 11

Audience .................................................................................................................. 11

Terminology .............................................................................................................. 12

Chapter 2 Before You Start 13

Deployment workflow ............................................................................................... 14

Essential reading ...................................................................................................... 14

VSPEX Solution Overviews ................................................................................... 14

VSPEX Implementation Guides............................................................................. 14

VSPEX Proven Infrastructures ............................................................................... 15

Best Practices guides ........................................................................................... 15

Chapter 3 Solution Overview 17

Overview .................................................................................................................. 18

Solution architecture ................................................................................................ 18

Key components ....................................................................................................... 19

Introduction ......................................................................................................... 19

Microsoft SharePoint Server 2013........................................................................ 20

Microsoft SQL Server 2012 .................................................................................. 21

EMC VSPEX Proven Infrastructures ....................................................................... 22

VMware vSphere 5.1 ............................................................................................ 24

Microsoft Windows Server 2012 with Hyper-V ...................................................... 24

EMC VNX family ................................................................................................... 24

EMC Unisphere .................................................................................................... 27

EMC Virtual Storage Integrator for VMware vSphere ............................................. 27

VMware vStorage APIs for Array Integration .......................................................... 27

EMC Storage Integrator ........................................................................................ 28

EMC Avamar ........................................................................................................ 28

EMC Data Domain ................................................................................................ 29

EMC PowerPath/VE .............................................................................................. 29

Contents


Chapter 4 Choosing a VSPEX Proven Infrastructure 31

Overview .................................................................................................................. 32

Step 1: Evaluate the customer use case .................................................................... 32

Overview .............................................................................................................. 32

VSPEX for virtualized SharePoint 2013 qualification worksheet ........................... 32

Step 2: Design the application architecture .............................................................. 35

Overview .............................................................................................................. 35

VSPEX Sizing Tool ................................................................................................ 35

Step 3: Choose the right VSPEX Proven Infrastructure ............................................... 39

Overview .............................................................................................................. 39

Considerations .................................................................................................... 39

Examples ............................................................................................................. 40

Chapter 5 Solution Design Considerations and Best Practices 47

Overview .................................................................................................................. 48

Network design considerations ................................................................................ 48

Overview .............................................................................................................. 48

Network design best practices ............................................................................. 48

Storage layout and design considerations ................................................................ 50

Overview .............................................................................................................. 50

Storage design best practices .............................................................................. 52

Storage layout examples...................................................................................... 57

Virtualization design considerations ........................................................................ 61

Overview .............................................................................................................. 61

Virtualization design best practices ..................................................................... 61

Application design considerations ........................................................................... 63

Overview .............................................................................................................. 63

Application design best practices ........................................................................ 63

Backup and recovery design considerations ............................................................. 67

Overview .............................................................................................................. 67

Considerations .................................................................................................... 67

Minimum backup software and hardware requirements ....................................... 68

Chapter 6 Solution Verification Methodologies 73

Overview .................................................................................................................. 74

Baseline hardware verification methodology ............................................................ 74

Application verification methodology ....................................................................... 74

Defining the test scenarios .................................................................................. 75

Understanding key metrics .................................................................................. 76

Creating the test environment .............................................................................. 77

Contents


Populating the database ...................................................................................... 77

Running tests, analyzing results, and optimization .............................................. 78

Backup and recovery verification methodology ......................................................... 79

Validating the backup and recovery plan ............................................................. 79

Test tools.................................................................................................................. 80

Sample tool to create large number of random documents .................................. 80

Sample tool to load documents into SharePoint .................................................. 80

Sample code for SharePoint performance testing................................................. 80

Chapter 7 Reference Documentation 81

EMC documentation ................................................................................................. 82

Other documentation ............................................................................................... 82

Links ........................................................................................................................ 83

Appendix A Qualification Worksheet 85

VSPEX for virtualized SharePoint 2013 qualification worksheet ................................ 86

Printing the qualification worksheet .................................................................... 87

Appendix B SharePoint Server 2013 Concepts 89

SharePoint Server 2013 concepts ............................................................................. 90

SharePoint Server 2013 fundamentals ................................................................. 90

SharePoint Server 2013 Search Service ............................................................... 91

Appendix C VSPEX Sizing Tool for Virtualized SharePoint 93

VSPEX sizing concepts for virtualized SharePoint ..................................................... 94

RPS calculation methodology .............................................................................. 94

Estimate content database size ........................................................................... 94

Appendix D High-level SharePoint Server 2013 Sizing Logic and Methodology 97

High-level SharePoint Server 2013 sizing logic and methodology ............................. 98

Overview .............................................................................................................. 98

SharePoint topology and compute resource sizing ............................................... 99

Storage layout sizing for SharePoint Server 2013 ............................................... 104

Select the right VSPEX Proven Infrastructure ...................................................... 110

Contents


Figures Figure 1. Architecture of the validated infrastructure .......................................... 19

Figure 2. SharePoint Server 2013 topology ........................................................ 22

Figure 3. VSPEX Proven Infrastructure ................................................................ 23

Figure 4. Required resources example: VSPEX Proven Infrastructure for small SharePoint 2013 farm ......................................................................... 42

Figure 5. Required resources example: VSPEX Proven Infrastructure for medium SharePoint farm ................................................................................... 46

Figure 6. SharePoint 2013 storage elements on VMware vSphere 5.1 platform .. 50

Figure 7. SharePoint 2013 storage elements on Hyper-V platform ...................... 51

Figure 8. Storage layout example: SharePoint farm for the VNXe series .............. 58

Figure 9. Storage layout example: SharePoint farm for VNX series without FAST VP ............................................................................................... 59

Figure 10. Storage layout example: SharePoint farm for VNX series with FAST VP ............................................................................................... 60

Figure 11. Installation map .................................................................................. 68

Figure 12. Printable qualification worksheet ........................................................ 87

Figure 13. SharePoint Server 2013 content structure ........................................... 91

Figure 14. Test result of relationship of active user number and host IOPS for search intensive publishing portal ..................................................... 105

Figure 15. Test result of relationship of active user number and host IOPS for search intensive document management portal ................................ 105

Tables Table 1. Terminology ......................................................................................... 12

Table 2. VSPEX for virtualized SharePoint Server 2013: Deployment workflow .. 14

Table 3. Reference virtual machine: Characteristics .......................................... 24

Table 4. VNX software suites ............................................................................. 26

Table 5. VNXe software suites ........................................................................... 26

Table 6. VNX software packs ............................................................................. 26

Table 7. VNXe software packs ........................................................................... 27

Table 8. VSPEX for virtualized SharePoint 2013: Design process ....................... 32

Table 9. VSPEX for virtualized SharePoint 2013 qualification worksheet guidelines ........................................................................................... 33

Table 10. VSPEX Sizing Tool output ..................................................................... 35

Table 11. VSPEX Proven Infrastructure: Selection steps ...................................... 39

Table 12. Example qualification worksheet: Small SharePoint farm .................... 40

Table 13. Example of required resources: Small SharePoint farm ........................ 41

Table 14. Example of SharePoint farm details in VSPEX Sizing Tool ..................... 41

Table 15. Example of performance key metrics: Small SharePoint farm ............... 42

Contents


Table 16. Example VSPEX qualification worksheet: Medium SharePoint farm ...... 43

Table 17. Example of required resources: Medium SharePoint farm .................... 44

Table 18. Example summary : Medium SharePoint farm in VSPEX Sizing Tool ..... 44

Table 19. Example performance key metrics: Medium SharePoint farm ............... 45

Table 20. SharePoint related storage pools name and the purpose ..................... 51

Table 21. Example I/O pattern of the index temporary location in SharePoint Server 2013 ......................................................................................... 52

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

Table 23. Recommended number of vCPUs for the application server ................. 61

Table 24. Recommended number of vCPUs for SQL Server .................................. 62

Table 25. Recommended RAM for SQL Server ...................................................... 62

Table 26. Example I/O pattern of the index temporary location in SharePoint Server 2013 ......................................................................................... 65

Table 27. Hardware requirements for backup ...................................................... 68

Table 28. Services and writers used by Avamar plug-in for SharePoint VSS ......... 71

Table 29. High-level steps for application validation ........................................... 74

Table 30. General operations .............................................................................. 75

Table 31. Mixed workloads ................................................................................. 76

Table 32. VSPEX for virtualized SharePoint 2013 qualification worksheet ........... 86

Table 33. SharePoint Server 2013 fundamental concepts ................................... 90

Table 34. SharePoint search service concepts .................................................... 91

Table 35. Formula to estimate content database size .......................................... 95

Table 36. High-level steps for SharePoint farm Sizing ......................................... 98

Table 37. Sizing the web server by active user number ..................................... 100

Table 38. Web server compute resource assignment ......................................... 101

Table 39. Sizing application servers for a normal farm ...................................... 102

Table 40. Sizing application servers to search a heavily used farm ................... 102

Table 41. Application server compute resource assignment .............................. 103

Table 42. SQL Server vCPU resource sizing for SharePoint Server 2013 ............. 103

Table 43. SQL Server memory resource sizing for SharePoint Server 2013 ........ 103

Table 44. Example user input for sizing the content database pool ................... 106

Table 45. Size the application server for non-intensive search farm .................. 108

Table 46. Size the application server for intensive search farm ......................... 108

Table 47. RAID configuration for the MySite pool............................................... 109

Table 48. VSPEX storage model support matrix ................................................. 111

Table 49. Storage system support matrix .......................................................... 112

Contents


Chapter 1: Introduction


Chapter 1 Introduction

This chapter presents the following topics:

Purpose of this guide ............................................................................................. 10

Business value ...................................................................................................... 10

Scope .................................................................................................................... 11

Audience ............................................................................................................... 11

Terminology .......................................................................................................... 12



Purpose of this guide

EMC® VSPEX™ Proven Infrastructures are optimized for virtualizing critical business applications. VSPEX gives customers the ability to plan and design the virtual assets required to support Microsoft SharePoint Server 2013 in a virtualized environment on a VSPEX Private Cloud infrastructure.

The VSPEX for virtualized SharePoint 2013 architecture provides customers with a modern system, capable of hosting a virtualized SharePoint solution at a consistent performance level. This solution runs on VMware vSphere or Microsoft’s Hyper-V virtualization layer, backed by the highly available EMC VNX® family, which provides the storage. The compute and network components, while vendor-definable, are laid out to be redundant and are sufficiently powerful to handle the processing and data needs of the virtual machine environment.

This Design Guide describes how to design a VSPEX Proven Infrastructure for virtualized SharePoint 2013 with best practices and how to select the right VSPEX Proven Infrastructure with the EMC VSPEX Sizing Tool for sizing guidance.

Business value

The volume and diversity of content and the size of user data continues to grow year over year. Data is exploding, with a 50 times growth rate forecasted over the next 10 years. To realize the value in all of this data, businesses are turning to content management applications to promote collaboration and information sharing. For over ten years, SharePoint has been helping customers to develop portals for collaboration, to manage documents and records, search and share documents, and develop business process automation around their most valuable asset—their information.

As SharePoint has developed and continued to add new functionality and features, the challenges that businesses face in managing their data have also grown. Administering, auditing, protecting, managing, and delivering an optimal SharePoint infrastructure for a geographically distributed work force is a major challenge for most IT departments. Virtualization of physical servers and storage assets with VSPEX enables IT departments to be more dynamic, and agile, and to keep pace with ever-changing demands on the business.

VSPEX enables customers to accelerate their IT transformation with faster deployments, simplified management, backup, and storage provisioning. Customers can realize greater efficiency with higher application availability, increased storage utilization, and faster and leaner backups. In addition, VSPEX provides customers with choices when selecting a hypervisor, servers, and networks to address the requirements of their unique SharePoint environments.



Scope

This Design Guide describes how to design a VSPEX Proven Infrastructure for virtualized SharePoint Server 2013 for Microsoft Hyper-V or VMware vSphere. The guide assumes that a VSPEX Private Cloud already exists in the customer’s environment.

The guide provides examples of deployments on both a VNX and an EMC VNXe® storage array. Furthermore, it illustrates how to size SharePoint Server 2013 on the VSPEX infrastructures, allocate resources following best practices, and use all the benefits that VSPEX offers.

Audience

This guide is intended for internal EMC personnel and qualified EMC VSPEX partners. The guide assumes that VSPEX partners who intend to deploy this VSPEX for virtualized SharePoint 2013 solution are:

Qualified by Microsoft to sell and implement SharePoint solutions

Certified in SharePoint Server 2013 with one or both of the following Microsoft certifications:

Core Solutions of Microsoft SharePoint Server 2013 (Exam: 331)

Advanced Solutions of Microsoft SharePoint Server 2013 (Exam: 332)

Qualified by EMC to sell, install, and configure the EMC VNX family of storage systems

Certified for selling VSPEX Proven Infrastructures

Qualified to sell, install, and configure the network and server products required for VSPEX Proven Infrastructures

Partners who plan to deploy the solution must also have the necessary technical training and background to install and configure:

VMware vSphere or Windows Server 2012 with Hyper-V as virtualization platforms

Microsoft Windows Server 2012 operating systems (OS)

Microsoft SharePoint Server 2013

EMC next-generation backup, which includes EMC Avamar® and EMC Data Domain®

This guide provides external references where applicable. EMC recommends that partners implementing this solution are familiar with these documents. For details, see Essential reading and Chapter 7: Reference Documentation.



Terminology

Table 1 lists the terminology used in this guide.

Table 1. Terminology

Term Definition

ACL Access control list

BLOB Binary large object

CSV Cluster-shared volume

DRS Distributed Resource Scheduler

GLR Granular-level recovery

IIS Internet Information Services

IOPS Input/output operations per second

LUN Logical unit number

NIC Network interface card

NFS Network file system

NLB Microsoft Network Load Balancing

NL-SAS Near-line serial-attached SCSI

Overlay A VSPEX technology solution that adds optional functionality to a VSPEX Proven Infrastructure

RDM Raw device mapping

RPS Requests per second

tempdb Tempdb refers to a system database used by Microsoft SQL Server as a temporary working area during processing.

TCO Total cost of ownership

VAAI VMware vStorage APIs for Array Integration

VHDX Hyper-V virtual hard disk format

VMDK VMware virtual machine disk

VMFS VMware Virtual Machine File System

VSS Volume Shadow Copy Service

VSTS Microsoft Visual Studio Team System

Chapter 2: Before You Start


Chapter 2 Before You Start


Deployment workflow ............................................................................................ 14

Essential reading ................................................................................................... 14



Deployment workflow

To design and implement your VSPEX for virtualized SharePoint 2013 solution, refer to the process flow in Table 2.

Table 2. VSPEX for virtualized SharePoint Server 2013: Deployment workflow

Step Action

1 Use the VSPEX for virtualized SharePoint 2013 qualification worksheet to collect user requirements. The one-page qualification worksheet is in Appendix A of this Design Guide.

2 Use the EMC VSPEX Sizing Tool to determine the recommended VSPEX Proven Infrastructure for your virtualized SharePoint solution, based on the user requirements collected in Step 1.

For more information about the Sizing Tool, refer to the VSPEX Sizing Tool on the EMC VSPEX Sizing Tool Portal.

Note: If the Sizing Tool is not available, you can manually size the application using the guidelines in Appendix D: High-level SharePoint Server 2013 sizing logic and methodology.

3 Use this Design Guide to determine the final design for your VSPEX solution.

Note: Ensure that all application requirements are considered, not just the requirements for virtualized SharePoint.

4 Select and order the right VSPEX Proven Infrastructure. Refer to the appropriate VSPEX Proven Infrastructure document in Essential reading for guidance.

5 Deploy and test your VSPEX solution. Refer to the appropriate VSPEX Implementation Guide in Essential reading for guidance.

Essential reading

EMC recommends that you read the following documents, available from the VSPEX space in the EMC Community Network or from EMC.com or the VSPEX Proven Infrastructure partner portal.

Refer to the following VSPEX Solution Overview documents:

EMC VSPEX Server Virtualization for Midmarket Businesses

EMC VSPEX Server Virtualization for Small and Medium Businesses

Refer to the following VSPEX Implementation Guides:

EMC VSPEX for Virtualized Microsoft SharePoint 2013 with Microsoft Hyper-V

EMC VSPEX for Virtualized Microsoft SharePoint 2013 with VMware vSphere

VSPEX Solution Overviews

VSPEX Implementation Guides

https://express.salire.com/signin.aspx?t=emc&atid=224a9bcc-caa3-48f4-8ff8-33051513c410

https://community.emc.com/community/partner/vspex?view=overview

http://www.emc.com/resource-library/resource-library.htm

http://www.emc.com/platform/virtualizing-information-infrastructure/vspex.htm




Refer to the following VSPEX Proven Infrastructure documents:

EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 100 Virtual Machines


EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 100 Virtual Machines


Refer to the following Best Practices guides:

EMC VNX Unified Best Practices for Performance

EMC FAST VP for Unified Storage Systems

VSPEX Proven Infrastructures

Best Practices guides

Chapter 3: Solution Overview


Chapter 3 Solution Overview


Overview ............................................................................................................... 18

Solution architecture ............................................................................................. 18

Key components .................................................................................................... 19



Overview

This chapter provides an overview of the VSPEX Proven Infrastructure for Microsoft SharePoint Server 2013 and the key technologies used in this solution. The solution described in this Design Guide includes the servers, storage, network components, and SharePoint components that focus on small and medium business private cloud environments.

The solution enables customers to quickly and consistently deploy a virtualized SharePoint farm in the VSPEX Proven Infrastructure. The reference architecture will support the reference virtual machine resources, based on the sizing guidance in the VSPEX Proven Infrastructure, and combine with additional storage for the SharePoint application data.

The VNX and VNXe family storage arrays are multiprotocol platforms that can support the iSCSI, network file system (NFS), Common Internet File System (CIFS), Fibre Channel (FC), and Fibre Channel over Ethernet (FCoE) protocols depending on a customer’s specific needs. This solution was validated using NFS and iSCSI for data storage.

This Design Guide can help customers to deploy a simple, effective, and flexible SharePoint solution on a VSPEX Proven Infrastructure. The guidance applies to all VSPEX Proven Infrastructures, including both VMware vSphere and Microsoft Hyper-V.

Solution architecture

Figure 1 shows the architecture that characterizes the validated infrastructure for the support of a SharePoint 2013 overlay on a VSPEX Proven Infrastructure.

All SharePoint servers—web server, application server, and SQL Server—are deployed as virtual machines on VMware vSphere 5.1 or Microsoft Windows Server 2012 with Hyper-V. We1 used the VSPEX Sizing Tool for SharePoint to determine the number of SharePoint server roles and the detailed compute resources for each role. We also used it to determine the recommended storage layout for SharePoint Server 2013, in addition to the VSPEX private cloud pool in the EMC VNX or EMC VNXe series.

The backup and recovery components of the solution provide SharePoint data protection, ranging from the entire SharePoint farm to various object levels.

1 In this guide, "we" refers to the EMC Solutions engineering team that validated the solution.



Figure 1. Architecture of the validated infrastructure

Key components

This section provides an overview of the key technologies used in this solution:


Microsoft SQL Server 2012

EMC VSPEX Proven Infrastructures:

VSPEX Proven Infrastructure

Reference virtual machines

VMware vSphere 5.1

Microsoft Windows Server 2012 with Hyper-V

EMC VNX family

EMC Unisphere®

EMC Virtual Storage Integrator for VMware vSphere

Introduction



VMware vStorage APIs for Array Integration (VAAI) for EMC VNX

EMC Storage Integrator (ESI)

EMC Avamar

EMC Data Domain

EMC PowerPath®/VE

Microsoft SharePoint Server 2013 provides a business-collaboration platform for enterprise and commercial organizations. SharePoint enables organizations to share content and information through websites, blogs, wikis, and document libraries—some of the many features of a SharePoint environment. Content within these features can be managed collectively from start to finish.

The SharePoint Server 2013 platform comprises a rich set of integrated capabilities that can be used either out of the box or customized to address specific business needs and integrated with other products and solutions. The platform can be deployed both within the organization (through intranets) and outside of the firewall (through extranets and the Internet) to enable interaction with employees, customers, and business partners. Thoughts and ideas can be easily exchanged and discussed using the same set of capabilities and tools.

A SharePoint environment consists of multiple server roles combined into units called farms. The SharePoint Server 2013 farm in this solution includes the following server roles:

Web server role: This server is responsible for the actual SharePoint pages that a user views. The role of the web server is to host web pages, web services, and the web parts that are required to process requests from users. The web server directs these requests to the application server, which returns the results to the web server.

Application server role: This server runs all the SharePoint application services, including index crawling and search query services. It also hosts the SharePoint Central Administration website. You can add application servers to host services that can be deployed to a single server and 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.

EMC recommends that you use three types of search application roles as distributed across the application servers:

All-in-one—The server contains all of the search application roles:

Query processing

Index partition

Crawler

Content processing

Analytics processing




Administration

Crawler-type—The server has four roles:

Crawler

Content processing

Analytics

Administration

Query-type—The machine has two roles:

Query processing

Index partitioning

Database server role: These are servers that run the SharePoint databases, including the content databases, configuration database, search databases, and so on. For this solution, we installed SQL Server 2012 with a back-end database role for SharePoint Server 2013.

SQL Server 2012 is Microsoft’s database management and analysis system for e-commerce, line-of-business, and data warehousing solutions. SQL Server is widely used to store, retrieve, and manage application data. Because it is used with a range of applications, and each application has different requirements for performance, sizing, availability, recoverability, manageability, and so on, it is important to fully understand these factors and plan accordingly when deploying SQL Server.

SharePoint Server 2013 is built on the SQL Server database engine and most of the content and SharePoint configurations are stored in the SQL Server databases. In this VSPEX Proven Infrastructure for virtualized SharePoint, we used SQL Server 2012 as the back-end database application. SharePoint Server 2013 uses the following types of SQL Server databases:

Configuration databases: The configuration database and Central Administration content database are called configuration databases. They contain data about farm settings such as the databases used, Internet Information Services (IIS) websites or web applications, solutions, web part packages, site templates, default quota, and blocked file types. A SharePoint farm can have only one set of configuration databases.

Content databases: Content databases store all site content: site documents, such as files in document libraries, list data, web part properties, and user names and rights. All the data for a specific site resides in one content database. Each web application can contain many content databases. Each site collection can be associated with only one content database, although a content database can be associated with many site collections.

Service application related databases: Service application databases store data for use by a service application. The databases for service applications vary significantly in how they are used.

Microsoft SQL Server 2012



Figure 2 shows the server roles in the SharePoint farm and the related service components that we validated in this VSPEX Proven Infrastructure for SharePoint. For detailed information about basic SharePoint Server 2013 concepts, refer to the Appendix B: SharePoint Server 2013 concepts.

Figure 2. SharePoint Server 2013 topology

SharePoint Server 2013 also supports other service components. If you plan to design additional services for SharePoint Server 2013, refer to the Microsoft TechNet website for information about the performance of these features, capacity test results, and recommendations.

EMC has joined forces with the industry’s leading providers of IT infrastructure to create a complete virtualization solution that accelerates deployment of private cloud. VSPEX enables faster deployment, greater simplicity and choice, higher efficiency, and lower risk. Validation by EMC ensures predictable performance and enables customers to select technology that uses their existing IT infrastructure while eliminating planning, sizing, and configuration burdens. VSPEX provides a virtual infrastructure for customers looking to gain the simplicity that is characteristic of truly converged infrastructures, while at the same time gaining more choice in individual stack components.

VSPEX solutions are proven by EMC and packaged and sold exclusively by EMC channel partners. VSPEX provides channel partners with more opportunity, a faster sales cycle, and end-to-end enablement. By working more closely together, EMC and

EMC VSPEX Proven Infrastructures



its channel partners can now deliver infrastructure that accelerates the journey to the cloud for even more customers.

VSPEX Proven Infrastructures

VSPEX Proven Infrastructures, as shown in Figure 3, are modular, virtualized infrastructures validated by EMC and delivered by EMC partners. VSPEX includes a virtualization layer, servers, networks, and storage, designed by EMC to deliver reliable and predictable performance.

Figure 3. VSPEX Proven Infrastructure

VSPEX provides the flexibility to choose best-of-breed network, server, and virtualization technologies that fit a customer’s environment to create a complete virtualization solution. VSPEX delivers faster deployment for EMC partner customers, with greater simplicity and efficiency, more choice, and lower risk to a customer’s business.

Reference virtual machine

To simplify the virtual infrastructure discussion, VSPEX defines a reference virtual machine to represent a unit of measure for quantifying the compute resources in the VSPEX virtual infrastructure. By comparing your actual customer usage to this reference workload, you can extrapolate which reference architecture to choose.

The reference virtual machine is defined as a single virtual machine with the characteristics shown in Table 3. For more information about a reference virtual machine and its characteristics, refer to the VSPEX Proven Infrastructures.



Table 3. Reference virtual machine: Characteristics

Characteristic Value

Virtual processors per virtual machine 1

RAM per virtual machine 2 GB

Available storage capacity per virtual machine 100 GB

Input/output operations per second (IOPS) per virtual machine 25

I/O pattern Random

I/O read:write ratio 2:1

VMware vSphere 5.1 transforms a computer’s physical resources by virtualizing the CPU, RAM, hard disk, and network controller. This transformation creates fully functional virtual machines that run isolated and encapsulated operating systems and applications just like physical computers.

VMware High Availability (HA) provides easy to use, cost-effective high availability for applications running in virtual machines. The VMware vSphere vMotion and VMware vSphere Storage vMotion features of vSphere 5.1 enable the seamless migration of virtual machines and stored files from one vSphere server to another, with minimal or no performance impact. Coupled with VMware vSphere Distributed Resource Scheduler (DRS) and VMware vSphere Storage DRS, virtual machines have access to the appropriate resources at any point in time through load balancing of compute and storage resources.

Microsoft Windows Server 2012 with Hyper-V provides a complete virtualization platform, which offers increased scalability and performance with a flexible solution from the data center to the cloud. It makes it easier for organizations to realize the cost savings from virtualization and to optimize server hardware investments.

Windows Server 2012 Hyper-V high-availability options include incremental backup support, enhancements in clustered environments to support virtual adapters within the virtual machine, and inbox network interface card (NIC )teaming. In Hyper-V, “shared nothing” live migration enables the migration of a virtual machine from a server running Hyper-V to another one without the need for both of them to be in the same cluster or to share storage.

The EMC VNX family of storage arrays is optimized for virtual applications delivering industry-leading innovation and enterprise capabilities for file, block, and object storage in a scalable, easy-to-use solution. This next-generation storage platform combines powerful and flexible hardware with advanced efficiency, management, and protection software to meet the demanding needs of today’s enterprises.

The VNX family is powered by Intel Xeon processors, for intelligent storage that automatically and efficiently scales in performance, while ensuring data integrity and security.

VMware vSphere 5.1

Microsoft Windows Server 2012 with Hyper-V

EMC VNX family



The VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large enterprises. The VNXe series is purpose-built for the IT manager in smaller environments.

VNX features

VNX supports the following features:

Next-generation unified storage, optimized for virtualized applications

Capacity optimization features including compression, deduplication, thin provisioning, and application-centric copies

High availability, designed to deliver five 9s (99.999 percent) availability

Automated tiering with FAST VP™ (Fully Automated Storage Tiering for Virtual Pools) for the VSPEX private cloud pools and FAST™ Cache that can be optimized for the highest system performance and lowest storage cost simultaneously

Simplified management with EMC Unisphere for a single management interface for all network-attached storage (NAS), storage area network (SAN), and replication needs

Up to three times improvement in performance with the latest Intel Xeon multicore processor technology, optimized for Flash

Multiprotocol support for file, block, and object with object access through EMC Atmos® Virtual Edition (Atmos VE）

VNXe features

VNXe supports the following features:

Next-generation unified storage, optimized for virtualized applications

Capacity optimization features including compression, deduplication, thin provisioning, and application-centric copies

High availability, designed to deliver five 9s availability

Multiprotocol support for file and block

Simplified management with Unisphere for a single management interface for all NAS, SAN, and replication needs



VNX software suites

Table 4 lists the software suites that are available with VNX.

Table 4. VNX software suites

Component Features

FAST Suite Automatically optimizes for the highest system performance and the lowest storage cost simultaneously

Local Protection Suite Practices safe data protection and repurposing

Remote Protection Suite Protects data against localized failures, outages, and disasters

Application Protection Suite Automates application copies and proves compliance

Security and Compliance Suite

Keeps data safe from changes, deletions, and malicious activity

VNXe software suites

Table 5 lists the software suites that are available with VNXe.

Table 5. VNXe software suites

Component Features

Local Protection Suite Increases productivity with snapshots of production data

Remote Protection Suite Protects data against localized failures, outages, and disasters

Application Protection Suite Automates application copies and proves compliance

Security and Compliance Suite

Keeps data safe from changes, deletions, and malicious activity

VNX software packs

Table 6 lists the software packs that are available with VNX.

Table 6. VNX software packs

Component Features

Total Efficiency Pack Includes all five software suites

Total Protection Pack Includes the Local, Remote, and Application Protection Suites



VNXe software packs

Table 7 lists the software packs that are available with VNXe.

Table 7. VNXe software packs

Component Features

VNXe3300 Total Protection Pack Includes the Local, Remote, and Application Protection Suites

VNXe3150 Total Value Pack Includes the Remote and Application Protection Suites, and the Security and Compliance Suite

EMC Unisphere is the next-generation unified storage management platform that provides intuitive user interfaces for the newest range of unified platforms including the VNX and VNXe series. Unisphere’s approach to storage management fosters simplicity, flexibility, self-help, and automation—all key requirements for the journey to the cloud. Unisphere can be customized to the needs of a midsize company, a department within large enterprises, or a smaller remote office/branch office type environment. With pluggable architecture, Unisphere is easily extensible and continues its seamless support for additional EMC offerings, including integration with data protection and security.

EMC Virtual Storage Integrator (VSI) for VMware vSphere is a plug-in for the vSphere client that provides a single management interface, which is used for managing EMC storage within the vSphere environment. Features can be added and removed from VSI independently, which provides flexibility for customizing VSI user environments. Features are managed by using the VSI Feature Manager. VSI provides a unified user experience, which enables new features to be introduced rapidly in response to changing customer requirements.

We used the following features during validation testing:

Storage Viewer (SV): Extends the vSphere client to facilitate the discovery and identification of the VNX storage devices that are allocated to vSphere hosts and virtual machines. SV presents the underlying storage details to the virtual datacenter administrator, merging the data of several different storage mapping tools into a few seamless vSphere client views.

Unified Storage Management: Simplifies storage administration of the VNX unified storage platform. It enables VMware administrators to provision new NFS and virtual machine file system (VMFS) datastores, and raw device mapping (RDM) volumes seamlessly within vSphere client.

For more information, refer to the EMC VSI for VMware vSphere product guides on EMC Online Support.

Hardware acceleration with VMware VAAI is a storage enhancement in vSphere 5.1 that enables vSphere to offload specific storage operations to compatible storage hardware such as the VNX family platforms. With storage hardware assistance, vSphere performs these operations faster and consumes less CPU, memory, and storage fabric bandwidth.

EMC Unisphere

EMC Virtual Storage Integrator for VMware vSphere

VMware vStorage APIs for Array Integration

https://support.emc.com/



EMC Storage Integrator (ESI) is an agent-less, no-charge plug-in that enables application-aware storage provisioning for Microsoft Windows server applications, Hyper-V, VMware, and Xen Server environments. It provides the ability for administrators to easily provision block and file storage for Windows or for SharePoint sites using wizards. ESI supports the following capabilities:

Provisioning, formatting, and presenting drives to Windows servers

Provisioning new cluster disks and adding them to the cluster automatically

Provisioning shared CIFS storage and mounting it to Windows servers

Provisioning SharePoint storage, sites, and databases in a single wizard

EMC Avamar solves the challenges associated with traditional backup, enabling fast, reliable backup and recovery for remote offices, data center local area networks (LANs), and VMware environments. Avamar is backup and recovery software that uses patented global data deduplication technology to identify redundant sub-file data segments at the source, reducing daily backup data up to 500 times before it is transferred across the network and stored to disk. This enables companies to perform daily full backups even across congested networks and limited wide area network (WAN) links.

Key Avamar differentiators are:

Deduplication of backup data at the source—before transfer across the network

Enabling of fast, daily full backups across existing networks and infrastructure

Up to 500 times reduction of required daily network bandwidth

Up to 10 times faster backups

Encryption of data in flight and at rest

Patented redundant array of independent nodes (RAIN) technology that provides fault tolerance across nodes and eliminates single points of failure

Scalable grid architecture

Up to 50 times reduction of total backup storage due to global data deduplication

Daily verification of recoverability

Centralized web-based management

Simple one-step recovery

Flexible deployment options, including the Avamar Data Store package

For more information, see the Avamar documents referenced in the EMC documentation section.

EMC Storage Integrator

EMC Avamar



If you use Avamar to implement a backup and recovery solution, you can choose to direct backups to an EMC Data Domain system instead of to the Avamar server.

EMC Data Domain deduplication storage systems deduplicate data inline so that the data lands on disk already deduplicated, which requires less disk space than the original dataset. With Data Domain, you can retain backup and archive data on site longer to quickly and reliably restore data from disk.

The Data Domain software suite includes the following options:

EMC Data Domain Replication

Virtual Tape Library (VTL)

Data Domain Boost

Retention Lock

Encryption

Extended Retention

EMC recommends that you install EMC PowerPath for advanced multipathing functionality such as intelligent path testing and performance optimization.

EMC PowerPath/VE provides intelligent, high-performance path management with path failover and load balancing optimized for EMC and selected third-party storage systems. PowerPath/VE supports multiple paths between a vSphere host and an external storage device. Having multiple paths enables the vSphere host to access a storage device, even if a specific path is unavailable. Multiple paths can also share the I/O traffic to a storage device. PowerPath/VE is particularly beneficial in highly available environments because it can prevent operational interruptions and downtime. The PowerPath/VE path failover capability avoids host failure by maintaining uninterrupted application support on the host in the event of a path failure (if another path is available).

PowerPath/VE works with VMware ESXi as a Multipath Plug-in (MPP) that provides path management to hosts. It is installed as a kernel module on the vSphere host. It plugs in to the vSphere I/O stack framework to bring the advanced multipathing capabilities of PowerPath/VE, including dynamic load balancing and automatic failover, to the vSphere hosts.

EMC Data Domain

EMC PowerPath/VE

Chapter 4: Choosing a VSPEX Proven Infrastructure


Chapter 4 Choosing a VSPEX Proven Infrastructure


Overview ............................................................................................................... 32

Step 1: Evaluate the customer use case ................................................................. 32

Step 2: Design the application architecture ............................................................ 35

Step 3: Choose the right VSPEX Proven Infrastructure ............................................ 39



Overview

This chapter describes how to design the VSPEX for virtualized SharePoint solution and how to choose the right VSPEX Proven Infrastructure on which to layer SharePoint. Table 8 outlines the main steps you need to complete when selecting a VSPEX Proven Infrastructure.

Table 8. VSPEX for virtualized SharePoint 2013: Design process

Step Action

1 Evaluate the customer’s SharePoint workload by using the VSPEX for virtualized SharePoint 2013 qualification worksheet. See Step 1: Evaluate the customer use case.

2 Determine the required infrastructure, SharePoint resources, and architecture using the VSPEX Sizing Tool. See Step 2: Design the application architecture.

Note: If the Sizing Tool is not available, you can manually size the application using the guidelines in Appendix D: High-level SharePoint Server 2013 sizing logic and methodology.

3 Choose the right VSPEX Proven Infrastructure, based on the recommendations from Step 2. See Step 3: Choose the right VSPEX Proven Infrastructure.

Step 1: Evaluate the customer use case

Before you choose any VSPEX solution, it is important to gather and understand the infrastructure requirements, limitations, and the estimated workload in order to design the SharePoint environment properly. To help you to better understand the customer’s business requirements for the VSPEX infrastructure design, EMC strongly recommends that you use the VSPEX for virtualized SharePoint 2013 qualification worksheet when evaluating the workload requirements for the VSPEX solution.

The VSPEX for virtualized SharePoint 2013 qualification worksheet presents a list of simple questions to help identify customer requirements, usage characteristics, and dataset. For a one-page EMC qualification worksheet for the VSPEX Proven Infrastructure for virtualized SharePoint, see Appendix A: VSPEX for virtualized SharePoint 2013 qualification worksheet.

Before you start, it is important that you understand the key concepts of SharePoint Server 2013. For more information, see Appendix B: SharePoint Server 2013 concepts.

Overview

VSPEX for virtualized SharePoint 2013 qualification worksheet



Table 9 provides a detailed explanation of the qualification worksheet and general guidance on how to determine input values.

Table 9. VSPEX for virtualized SharePoint 2013 qualification worksheet guidelines

Question Description

How many SharePoint 2013 farms do you plan to host in your VSPEX Proven Infrastructure?

To identify the number of SharePoint 2013 farms to plan for in your VSPEX Proven infrastructure. SharePoint 2013 enables you to independently create multiple farms for your organization. The VSPEX Proven Infrastructure is designed for up to three SharePoint 2013 farms.

Note: If a customer plans to have more than one farm in the VSPEX Proven Infrastructure, repeat all of the following questions in this worksheet for each SharePoint 2013 farm.

Included number of years’ growth?

To define the number of years’ growth that will be calculated in the VSPEX Sizing Tool. Future growth is a key characteristic of the VSPEX solution. This answer helps you to understand the customer’s plan for future growth. EMC suggests planning for at least one year’s growth when using the VSPEX Sizing Tool.

Annual growth rate (%)? To define the expected annual growth for the amount of data in your SharePoint environment. Future growth is a key characteristic of the VSPEX solution. Enter a number that is appropriate for your environment.

Is the SharePoint Web application going to be accessed globally?

To define the user base of a SharePoint 2013, you need to combine the total number of users and how they are geographically distributed. The answer helps you to understand the peak user base for the VSPEX for virtualized SharePoint 2013 solution.

Initial farm size (GB)? To define the volume of the content database that is stored in the SharePoint system. The volume of content is an important element for sizing disk capacity because it can influence the performance of other features, and can also potentially affect network latency and available bandwidth.

If it is your first time to estimate your content database size, refer to the Estimate content database size section.

Number of users? To define the total number of unique users that will access the SharePoint environment. This element is important for defining the resources required in the VSPEX for virtualized SharePoint 2013 solution.

User concurrency at peak (%)? Concurrency of users is defined as the total percentage of users actively using the system at peak time. The combination of the number of users and user concurrency defines the user connections to SharePoint at peak time.




What is the main purpose of the SharePoint Web application?

A farm's performance can be affected not only by the number of users interacting with the system, but also by their usage characteristics. The VSPEX Sizing Tool defines the two operations in general use:

Publishing Portal: The website used for social sites and collaboration in the organization.

Document Management Portal: The website used to control the life cycle of documents in the organization.

Select either Publishing Portal or Document Management Portal for your customer’s environment. If your customers are planning to apply SharePoint for other usage characteristics, contact EMC through your Partner Development Manager for information on SharePoint sizing.

Do you use or intend to use the My Sites function?

Because My Site users can edit their profiles, generate activities, upload and download documents, and so on, additional planning of the storage and capacity needs of the VSPEX for virtualized SharePoint 2013 solution is required. Enter Yes or No for the customer’s environment.

What is the percentage of the total users who will create My Sites?

Use the answer to this question to estimate the additional storage for the VSPEX for virtualized SharePoint 2013 solution.

What is the quota for a single My Site (MB)?

SharePoint Server includes a default Personal Site quota template, which has a storage limit of 100 MB and no user limit. This quota template is used for each user's individual site collection in their My Site. If the default settings for this template do not meet your needs, you can edit it. This factor is important for defining additional storage planning for the VSPEX for virtualized SharePoint 2013 solution.

Do you intend to enable FAST VP? FAST VP automatically optimizes performance in a tiered environment reducing costs, footprint, and management effort.

FAST VP maximizes the utilization of the Flash drive capacity for high IOPS workloads and maximizes the utilization of near-line SAS (NL-SAS) drives for capacity-intensive applications.

FAST VP can lower total cost of ownership (TCO) and increase performance by intelligently managing data placement at a sub-LUN level. When FAST VP is implemented, the storage system measures, analyzes, and implements a dynamic storage-tiering policy much faster and more efficiently than a human analyst could ever achieve.

Enter Yes or No for the customer’s business requirements.




Do you heavily rely on SharePoint search functionality?

A SharePoint farm where users rely heavily on search functionality drives the following requirements of the system:

Updated search indexes, which means most recently added content can be quickly found in search result

High volume of items to be searched

Such requirements need more back-end I/O to support.

Enter Yes or No for the customer’s environment.

Step 2: Design the application architecture

After you evaluate your customer’s SharePoint real workload and requirements, use the VSPEX Sizing Tool for virtualized SharePoint to design your VSPEX for virtualized SharePoint 2013 solution.

Principles and guidelines

In this VSPEX Proven Infrastructure solution, we defined a representative customer reference workload to be sized. The VSPEX Proven Infrastructure reference architectures create a pool of resources that are sufficient to host a target number of reference virtual machines with characteristics, as shown in Table 3. For more information about a reference virtual machine and its characteristics, refer to the relevant documents in the VSPEX Proven Infrastructures section.

VSPEX Sizing Tool output: Requirements and recommendations

The VSPEX Sizing Tool enables you to input up to three farm configurations from the customer’s answers in the qualification worksheets. After you complete the inputs to the VSPEX Sizing Tool, the tool generates a series of recommendations, as listed in Table 10.

Table 10. VSPEX Sizing Tool output

Type VSPEX Sizing Tool recommendation

Description Reference

Individual farm SharePoint farm configuration

Provides suggestions about farm topology.

For example, medium or small farm.

SharePoint Server 2013 fundamentals

Individual farm VSPEX configuration suggestion

Sums up the reference virtual machines consumed in this farm.

VSPEX sizing concepts for virtualized SharePoint

Overview

VSPEX Sizing Tool



Type VSPEX Sizing Tool recommendation

Description Reference

Individual farm Reference virtual machine suggestions for each SharePoint role

Provides detailed information including the number of virtual machines, vCPU, memory, IOPS, and the capacity of the operation system volume in each farm.

Reference virtual machine best practices for SharePoint roles

Individual farm Key metrics and thresholds

Provides key performance metrics that you may need to meet in the validation tests for each farm.

Understanding key metrics

Individual farm Additional storage pool suggestions

Additional storage pools recommendation for SharePoint data including content database, search components, and so on in each farm.

In this VSPEX for virtualized SharePoint solution, customers may need to add more disks and storage pools to the infrastructure layer to meet different business requirements from performance and capacity considerations for the SharePoint farm.

Storage layout and design considerations

Total Total reference virtual machine

Sums up the reference virtual machines required in the virtual infrastructure for all the SharePoint farms.

This helps you to design and select the right VSPEX solution in the design phase, and combine it with other applications.


Total Additional disks information summary

Summary of the additional disks required for SharePoint data, including the content databases, Services databases, and My Sites content databases of all SharePoint farms.


For more information, see the examples in Step 3: Choose the right VSPEX Proven Infrastructure.

Reference virtual machine best practices for SharePoint roles

The VSPEX Sizing Tool provides detailed recommendations for sizing the reference virtual machine from the following basic resource types for each SharePoint role:

vCPU resources best practices

Memory resources best practices

OS capacity resources best practices

OS IOPS best practices



This section describes the resource types, how they are used in the VSPEX Sizing Tool, and key considerations and best practices for a customer environment.

vCPU resources best practices

The VSPEX Sizing Tool provides the vCPU of the reference virtual machine measurement unit consumed for each SharePoint role from the virtual infrastructure. The CPU type must meet or exceed the defined CPU or processor models as defined in the VSPEX Proven Infrastructures. We validated this VSPEX for virtualized SharePoint 2013 solution with a statically assigned processor, and no virtual-to-physical CPU oversubscription.

In SharePoint Server deployments, EMC recommends that you allocate multiple quad-core web servers that can be easily virtualized and scaled out. The application servers' processor capacity requirements differ, depending on the role of the server and the services it is running. In this solution, we used multiple quad-core application servers, mainly for search consideration on the medium SharePoint farm, which proved best during testing. If you are planning additional services on the SharePoint application server, consider reserving more processor resources.

As the crawler server role of the SharePoint 2013 Search service application requires a lot of CPU resources, EMC recommends you assign it 12 cores.

The processor capacity requirements for SQL Server also depend on the service databases that a SQL Server-based computer is hosting. In the small farm, we used a quad-core virtualized SQL Server, which was found to be acceptable. In the medium farm, we used an eight-core virtualized SQL Server that yielded good results during testing. If the farm is even bigger, for example if there are five web servers, SQL Server will require 16 cores to stay in the Green Zone. For SQL Server, the Green Zone means that CPU utilization is kept at less than 50 percent. For detailed design best practices for vCPU, refer to the Virtualization design considerations section.

Memory resources best practices

The VSPEX Sizing Tool shows the recommended memory and the equivalent reference virtual machines for each SharePoint role. We validated this VSPEX for virtualized SharePoint 2013 solution with statically assigned memory, no over-commitment of memory resources, and no memory swapping or ballooning. The memory values provided in the tool are not hard limits but represent the values that were tested in the VSPEX solution.

In general, web server memory requirements are highly dependent on the number of application pools enabled in the farm and the number of concurrent requests being served. In most production SharePoint Server deployments, EMC recommends that you allocate at least 12 GB of RAM on each web server and application server. For information about the SQL memory recommendations in this VSPEX Proven Infrastructure, refer to the VSPEX Proven Infrastructures section.

OS capacity resource sizing best practices

The VSPEX Sizing Tool shows the recommended capacity of the reference virtual machine measurement unit suggested for the operating system for each SharePoint role. EMC recommends that you put the OS volume into the VSPEX



private cloud pool in the VSPEX Proven Infrastructure solution. For more information about the VSPEX private cloud pool, see the VSPEX Proven Infrastructures section.

In the medium and small SharePoint farms, EMC recommends that the web servers and application servers allocate at least 100 GB of disk space for the OS and log files.

OS IOPS sizing best practices

The VSPEX Sizing Tool shows the estimated IOPS of the reference virtual machine measurement unit suggested for each SharePoint role in the OS. EMC recommends that you put the OS volume into the VSPEX private cloud pool. In this scenario, we considered performance characteristics from the application perspective more than from the capacity perspective.

The VSPEX Sizing Tool shows suggestions for the number of virtual machines for each SharePoint role. These numbers are calculated, based on the answers in the qualification worksheet, which identify the business requirements.

For more information, see the examples in the section Step 3: Choose the right VSPEX Proven Infrastructure.

Additional considerations and best practices

After you obtain a recommended sizing guide from the VSPEX Sizing Tool, you may need to consider some additional key areas:

Search external data in SharePoint 2013

SharePoint 2013 provides support for searching external content, such as public websites, file shares, Exchange public folders, and so on. If customers want to crawl and search through external data, you need to define the additional capacity demand and factor this into the storage layout design.

Customization

Adding custom code to frequently used pages in the SharePoint environment is a common cause of performance issues. Adding custom code can generate additional round trips to the database servers or web services to service data requests. Customization of infrequently used pages might not significantly impact the throughput, but even well-optimized code can decrease the farm throughput if it is requested thousands of times a day.

If you have custom code in the SharePoint environment, EMC strongly recommends that you contact the vendor to do the capacity design for the VSPEX for virtualized SharePoint 2013 solution for any additional reference virtual machines required by custom code.

Future growth

It is important to plan for growth so that the environment can continue to deliver an effective business solution. To maintain performance targets and accommodate growth, the VSPEX Sizing Tool enables customers to select from one to three years growth. The cost of over-investment in hardware is usually far less than the cumulative expense of troubleshooting problems caused by undersizing.



Additional services feature for SharePoint 2013

SharePoint 2013 provides many additional features—for example, Access Services, Business Connectivity Services, and Excel Services. This VSPEX solution focuses on SharePoint core features like Search Services, User Profile Services, and the My Sites function. If you plan to design additional services for SharePoint 2013, EMC strongly recommends that you refer to the article Performance and capacity test results and recommendations (SharePoint Server 2013) on the Microsoft TechNet website for performance and capacity test results and recommendations for different features.

Step 3: Choose the right VSPEX Proven Infrastructure

This section describes two examples of SharePoint 2013 farms—one small, one medium—and demonstrates how you would select the VSPEX Proven Infrastructure for each one. For more information about selecting a VSPEX Proven Infrastructure, see Appendix A: VSPEX for virtualized SharePoint 2013 qualification worksheet.

The VSPEX program has produced numerous solutions designed to simplify the deployment of a consolidated virtual infrastructure using vSphere, Hyper-V, the VNX and VNXe family of products, and EMC Next-Generation Backup. Once the application architecture has been confirmed using the VSPEX Sizing Tool, you can choose the right VSPEX Proven Infrastructure based on the calculated results.

Note: While this Design Guide is intended for SharePoint Server farm requirements, this may not be the only application intended for deployment on the VSPEX Proven Infrastructure. You must carefully take into account the requirements for each application you plan to deploy.

Follow the steps in Table 11 when choosing a VSPEX Proven Infrastructure.

Table 11. VSPEX Proven Infrastructure: Selection steps

Step Action

1 Use the VSPEX Sizing Tool to get the total number of reference virtual machines and additional suggested storage layout.

2 Use the VSPEX Sizing Tool to design the other applications’ resource requirements, based on business needs. The VSPEX Sizing Tool calculates the total number of required reference virtual machines and additional recommended storage layouts for both SharePoint and other applications.

3 Discuss with your customers the maximum utilization of the VSPEX Proven Infrastructure for combined applications to meet their business requirements. Input the maximum utilization percentage of the VSPEX Proven Infrastructure in the VSPEX Sizing Tool. The tool provides a recommendation for the VSPEX Proven Infrastructure offering.

4 Select your network vendor and hypervisor software vendor for the recommended VSPEX Proven Infrastructure offering. For more information, visit the VSPEX Proven Infrastructure partner portal.

Overview

Considerations

http://technet.microsoft.com/en-us/library/ff608068.aspx





For more information about the required reference virtual machines, refer to the relevant sizing section in VSPEX Proven Infrastructures.

Example 1: SharePoint small farm

In this scenario, a customer would like to create a small SharePoint 2013 farm for an intranet-publishing portal on a VSPEX Proven Infrastructure. The customer has a locally accessed farm, with about 800 GB of content data spread across three content databases of varying sizes. The expected user count of the farm is 1,000 users, of which 10 percent will be accessing the farm at any peak time. The customer would like to use at most 75 percent of the VSPEX Proven Infrastructure utilization for applications.

After talking to the customer, complete the qualification worksheet for the production SharePoint Server 2013 farm, as shown in Table 12.

Table 12. Example qualification worksheet: Small SharePoint farm

Question Example answer

How many SharePoint farms do you plan to host in your VSPEX Proven Infrastructure?

1

Included number of years’ growth? 1

SharePoint Farm 1

Annual growth rate (%)? 10

Is the SharePoint Web application going to be accessed globally? No

Initial farm size (GB)? 800

Number of users? 1,000

User concurrency at peak (%)? 20

What is the main purpose of the SharePoint Web application? Publishing Portal

Do you use or intend to use the My Sites function? No

What is the percentage of total users who will create My Sites? N/A

What is the quota for a single My Sites (MB)? N/A

Do you heavily rely on SharePoint Search function? Yes

Do you intend to enable FAST VP? No

After inputting the answers from the qualification worksheet into the VSPEX Sizing Tool, the tool generates recommendations for the resources required from the resource pool, as shown in the example in Table 13. For detailed steps on using the VSPEX Sizing Tool, see Appendix D: High-level SharePoint Server 2013 sizing logic and methodology.

Examples



Table 13. Example of required resources: Small SharePoint farm

SharePoint server role vCPU Memory OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Web server Resource requirements

4 12 GB 100 GB Less than 25

1 6 Equivalent reference virtual machines

4 6 1 1

SQL Server Resource requirements



4 4 1 1

Application server

(All-in-one)

Resource requirements



12 6 1 1

Total equivalent reference virtual machines 22

For example, each web server requires four vCPUs, 12 GB of memory, 100 GB of storage, and 25 IOPS. This translates to:

Four reference virtual machines for the CPU requirement

Six reference virtual machines for the memory requirement

One reference virtual machine for the capacity requirement

One reference virtual machine for the IOPS requirement

The VSPEX Sizing Tool also lists recommendations for the storage layout as shown in Table 14. In this case, therefore, implementing this small SharePoint farm on an infrastructure pool would consume the resources of 22 reference virtual machines.

The suggested storage layout for the SharePoint data is in addition to the VSPEX Proven Infrastructure VNXe pool. For more information, see Principles and guidelines.

Table 14. Example of SharePoint farm details in VSPEX Sizing Tool

VSPEX configuration suggestions (total reference virtual machines)

22

Recommended additional storage layout

Pool name RAID type Disk type Disk capacity Disk no.

SharePoint content database pool 4+1 RAID 5 SAS disks rpm 15,000 600 GB 5

SharePoint services pool 3+3 RAID 1/0 SAS disks rpm 15,000 600 GB 6



The VSPEX Sizing Tool lists the key metrics for performance validation, as shown in Table 15. For a detailed explanation of these key metrics, refer to the Understanding key metrics section.

Table 15. Example of performance key metrics: Small SharePoint farm

Key metrics Thresholds User profile usage

Passed tests per second More than 4

Browse operation Less than 3 seconds 80%

Search operation Less than 3 seconds 10%

Modify operation Less than 3 seconds 10%

Operation states

SQL Server CPU usage less than 50%

Web server CPU usage less than 70%

Failure rate less than 0.01%

SharePoint is the only application planned for deployment on this VSPEX Proven Infrastructure. To implement this small SharePoint 2013 farm on a pool for 50 reference virtual machines, EMC recommends that customers consider the following two VSPEX infrastructures for the best fit with their requirements:

EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 100 virtual machines

EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 100 virtual machines

In this example, the small SharePoint 2013 farm consumes the resources of 22 reference virtual machines and leaves resources for 28 reference virtual machines in the 50 reference virtual machine VSPEX Proven Infrastructure, as shown in Figure 4.

Figure 4. Required resources example: VSPEX Proven Infrastructure for small SharePoint 2013 farm

Note: This is not a hard limit; you can select larger VSPEX Proven Infrastructures if requirements from multiple applications make it necessary. In the Implementation Guide, we used Microsoft Hyper-V for 50 virtual machines as a VSPEX solution example. For more information, refer to the VSPEX Proven Infrastructures.



Example 2: SharePoint medium farm

In this scenario, a customer would like to create a medium SharePoint 2013 farm for the company’s intranet Document Management Portal on a VSPEX Proven Infrastructure. The customer has a locally accessed farm, with about 4 TB of content data spread across four content databases of varying sizes. The expected user count of the farm is 5,000 users. During the business day, 85 percent of users will log onto the portal as the intranet homepage in the morning, which is a peak time. You must define the primary purpose of the SharePoint farm because this is relevant for subsequent CPU and storage resource recommendations. The customer also plans for other applications in the VSPEX Proven Infrastructure, such as Microsoft Exchange and SQL Server, which are outside the scope of this Design Guide, with a total of 180 reference virtual machines required. In addition, the customer would like to use at most 75 percent utilization of the VSPEX Proven Infrastructure for combined applications.

After talking to the customer, complete the VSPEX qualification worksheet for the production SharePoint 2013 farm, as in the example shown in Table 16.

Table 16. Example VSPEX qualification worksheet: Medium SharePoint farm



1


SharePoint Farm 1



Initial farm size (GB)? 4,000



What is the main purpose of the SharePoint Web application? Document Management Portal



What is the quota for a single My Site (MB)? N/A

Do you heavily rely on SharePoint Search function? Yes


After inputting the answers into the VSPEX Sizing Tool, the following resources are needed from the resource pool, as shown in the example in Table 17.



Table 17. Example of required resources: Medium SharePoint farm

SharePoint server role vCPU Memory OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Web server Resource requirements

4

12 GB

100 GB

Less than 25


4 6 1 1

SQL Server Resource requirements



16 8 1 1

Application server

(Query-type)




4 6 1 1

Application server

(Crawler-type)




12 6 1 1

Total equivalent reference virtual machines 82

The VSPEX Sizing Tool also lists recommendations for the storage layout, as shown in Table 18. In this case, therefore, implementing this medium SharePoint farm on a virtual infrastructure pool would consume the resources of 82 reference virtual machines.

The suggested storage layout to store SharePoint data is in addition to the VSPEX Proven Infrastructure VNX pool. For more information, see the VSPEX sizing concepts for virtualized SharePoint section.

Table 18. Example summary : Medium SharePoint farm in VSPEX Sizing Tool

VSPEX configuration recommendations (total reference virtual machines)

82

Recommended additional storage layout

Pool name RAID type Disk type Disk capacity Disk no.

SharePoint content database pool

4+1 RAID 5 SAS disks rpm 15,000 300 GB 30

SharePoint services pool 4+4 RAID 1/0 SAS disks rpm 15,000 600 GB 16



The VSPEX Sizing Tool lists the key metrics for performance validation, as shown in Table 19. For a detailed explanation of these key metrics, refer to the Understanding key metrics section in Chapter 6.

Table 19. Example performance key metrics: Medium SharePoint farm

Key metrics Thresholds User profile usage

Passed tests per second More than 50

Browse operation Less than 3 seconds 50%

Search operation Less than 3 seconds 20%

Modify operation Less than 3 seconds 20%

Upload operation Less than 3 seconds 10%

Operation states SQL Server CPU usage less than 50%

Web server CPU usage less than 70%

Failure rate less than 0.01%

SharePoint is not the only application that the customer needs to design in the VSPEX Proven Infrastructure. To implement this medium SharePoint farm on a pool for 250 reference virtual machines, EMC recommends using the VSPEX Sizing Tool to design the combined applications workload that has the best fit with the VSPEX Proven Infrastructure offering.

Because the total combined applications required 180 reference virtual machines and 75 percent utilization of the VSPEX Proven Infrastructure, EMC recommends that customers consider the following two VSPEX infrastructures for the best fit with their requirements:

EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 500 virtual machines

EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 500 virtual machines

In this example, the medium SharePoint 2013 farm consumes the resources of 82 reference virtual machines and leaves resources for 210 reference virtual machines for other applications. Figure 5 shows the required resources for a SharePoint medium farm and 168 reference virtual machines, available in the 250 reference virtual machine VSPEX Proven Infrastructure.



Figure 5. Required resources example: VSPEX Proven Infrastructure for medium SharePoint farm

In the Implementation Guide, we used VMware vSphere 250 virtual machines as a VSPEX solution example. For more information, refer to the VSPEX Implementation Guides.

Chapter 5: Solution Design Considerations and Best Practices


Chapter 5 Solution Design Considerations and Best Practices


Overview ............................................................................................................... 48

Network design considerations .............................................................................. 48

Storage layout and design considerations ............................................................. 50

Virtualization design considerations ...................................................................... 61

Application design considerations ......................................................................... 63

Backup and recovery design considerations ........................................................... 67



Overview

This chapter describes best practices and considerations for designing the VSPEX for virtualized SharePoint 2013 solution. It covers the following VSPEX infrastructure layers and components:

Network design

Storage layout design

Virtualization design

Application design

Backup and recovery design

Network design considerations

Networking in the virtual world follows the same concepts as in the physical world, but some of these concepts are applied in the software instead of using physical cables and switches. Although many of the best practices that apply in the physical world continue to apply in the virtual world, there are additional considerations for traffic segmentation, availability, and throughput.

The advanced networking features of the VNXe and VNX series provide protection against network connection failures at the array. Meanwhile, each hypervisor host has multiple connections to the user and storage Ethernet networks to guard against link failures. You should spread these across multiple Ethernet switches to guard against component failure in the network.

The network connection for the boot volume of VSPEX for virtualized SharePoint 2013 can be FC, FCoE, or iSCSI for NFS and CIFS on VNX, and iSCSI for CIFS and NFS on VNXe.

To bring SharePoint into your VSPEX infrastructure on VNX or VNXe, you can use the existing network infrastructure or set up additional iSCSI, FC, FCoE, CIFS, or NFS connections for SharePoint databases and other components.

For more information, refer to the VSPEX Proven Infrastructures section.

In this VSPEX Proven Infrastructure for virtualized SharePoint, EMC recommends that you consider the following aspects for network design:

Separate different network traffic

Keep the virtual machine, storage, and vSphere vMotion or Microsoft Windows Hyper-V Live Migration network traffic separate using VLAN segmentation.

Network redundancy

A goal of redundant topologies is to eliminate network downtime caused by a single point of failure. All networks need redundancy for enhanced reliability. Network reliability is achieved through reliable equipment and network designs that are tolerant to failures and faults. Networks should be designed to

Overview

Network design best practices



reconverge rapidly so that the fault is bypassed. In this solution, we have two network switches and all three networks have their own redundant link.

Use NIC teaming

Aggregate multiple network connections in parallel to increase throughput beyond what a single connection can sustain, and to provide redundancy in case one of the links fails. For example, in the VMware virtualization environment, use two physical NICs per vSwitch and uplink the physical NICs to separate physical switches.

When specifying the NIC teaming settings, it is best practice to select “no” for the NIC teaming failback option. If there is some intermittent behavior in the network, this will prevent flip-flopping of the NIC cards being used.

When setting up VMware high availability (VMware HA), it is a good starting point to also set the following ESX Server timeouts and settings under the ESX Server advanced setting tab:

NFS.HeartbeatFrequency = 12

NFS.HeartbeatTimeout = 5

NFS.HeartbeatMaxFailures = 10

Use hardware load balancing or Windows Network Load Balancing (NLB)

NLB is particularly useful for ensuring that stateless applications, such as a web server running IIS, are scalable by adding additional servers as the load increases. Load-balancing servers (also called hosts) in a cluster communicate among themselves to provide key benefits, including:

Scalability: NLB scales the performance of a server-based program, such as a web server, by distributing its client requests across multiple servers within the cluster. As traffic increases, additional servers can be added to the cluster, with up to 32 servers possible in any one cluster.

High availability: NLB provides high availability by automatically detecting the failure of a server and repartitioning client traffic among the remaining servers within ten seconds, while providing users with continuous service.

SharePoint supports hardware load balancing that provides various layers of security filtering, caching, compression, and other advanced features that Windows NLB does not have.

For more information on creating a Windows NLB cluster, refer to the VSPEX Implementation Guides. For other best practices in network design for the VSPEX Proven Infrastructure, refer to the VSPEX Proven Infrastructures guides.



Storage layout and design considerations

The best practice and design considerations in this section provide guidelines for effectively planning storage for various business requirements in SharePoint Server 2013 environments.

Figure 6 shows the high-level architecture of the SharePoint components and storage elements validated in the VSPEX Proven Infrastructure for virtualized SharePoint on a vSphere virtualization platform. All the SharePoint volumes are stored in virtual machine disk (VMDK) format on iSCSI datastores.

Figure 6. SharePoint 2013 storage elements on VMware vSphere 5.1 platform

In addition to the VSPEX private cloud pool for virtual machines, EMC recommends that you use three additional storage pools to store SharePoint data for different purposes. For more information, see Table 20.

Overview



Table 20. SharePoint related storage pools name and the purpose

Pool name Purpose RAID recommendation

VSPEX private cloud pool

The pool where all the virtual machines reside. For details, refer to the appropriate VSPEX Proven Infrastructures.

Refer to the appropriate VSPEX Proven Infrastructures

SharePoint content databases pool

The pool where all content database data and their logs reside.

RAID 5 with SAS disks

SharePoint Services pool

The pool for SharePoint query and crawl components and all the service databases.

RAID 1/0 with SAS disks

SharePoint My Sites content databases pool

The pool for SharePoint My Sites content database data and log files.

RAID 6 with NL-SAS disks

Figure 7 shows the high-level architecture of the SharePoint components and storage elements validated in the VSPEX Proven Infrastructure for SharePoint on a Microsoft Window Server 2012 Hyper-V virtualization platform.

Figure 7. SharePoint 2013 storage elements on Hyper-V platform



All the SharePoint volumes are stored in the new Hyper-V virtual hard disk format (VHDX) on the cluster-shared volume (CSV). For more information on additional storage pools to store SharePoint data, see Table 20.

In this VSPEX Proven Infrastructure for virtualized SharePoint, consider the following best practices for storage layout and design:

SharePoint content databases pool:

Use RAID 5 for the SharePoint content database storage pool where the SharePoint content databases reside. This is because RAID 5 provides high capacity utilization, along with good I/O performance, at a low cost. This applies to both the VNXe and VNX series.

Use SAS disks for both performance and capacity considerations. In the VSPEX Sizing Tool, the disk number of each pool is calculated to meet both capacity and IOPS requirements.

Reserve a buffer for the content database capacity volume. All SharePoint content resides in the content database, which means it can grow at a certain rate. Consider this factor when planning the capacity for your content databases. In this VSPEX Proven Infrastructure, we reserved an additional 30 percent buffer for the content database capacity volumes.

SharePoint services pool:

Use RAID 1/0 for the SharePoint services storage pool. This pool consists of all the SharePoint services components, configuration databases, and tempdb, except the content database. The composition of this pool depends on which features or services you want to enable in SharePoint, according to your business requirements.

One of the most demanding components is the SharePoint Server Search function, which has a very important role in this pool. When the SharePoint Server Search function is started and the corresponding Search Service Application has been created, four search databases are generated. For more information about the basic concepts of search components, refer to Appendix B: SharePoint Server 2013 concepts.

During the crawl, all the crawled items will be temporarily downloaded and stored in the index temporary location.

The index temporary location resides in the SharePoint application servers that host the crawler component. All crawl items are temporarily downloaded to this location and stored during the crawl.

Table 21 details an example of the I/O pattern of this component, showing that the IOPS is high and the read:write size is large. In this situation, EMC recommends that you change its default location (C:\Program Files\Microsoft Office Servers\15.0\Data\) to the SharePoint services pool, which is RAID 1/0.

Table 21. Example I/O pattern of the index temporary location in SharePoint Server 2013

IOPS Read:Write Read size (KB) Write size (KB)

410 2:3 129 90

Storage design best practices



For more information about how to change this location, refer to the VSPEX Implementation Guides.

Use SAS disks for both performance and capacity considerations. In our VSPEX Sizing Tool, the disk number of each pool is calculated to meet both capacity and IOPS requirements.

Put the SQL Server tempdb database on a RAID 1/0 array for the best performance because tempdb is write-intensive into the SharePoint services pool. For more information about best practices for the tempdb database, see the Application design best practices for SQL Server 2012 for SharePoint Server .

SharePoint My Site content database pool (if applicable):

Use RAID 6 with NL-SAS for the SharePoint My Site pool. The SharePoint My Site pool, which is not illustrated in the storage layout diagram, consists of a content database, which is only used for My Site.

Considering that My Site has relatively low client access and the main design factor is the capacity, EMC recommends that you set this pool to RAID 6 with NL-SAS for high capacity considerations.

Estimate the SharePoint search volume capacity:

The VSPEX Sizing Tool calculates the recommended disk requirements for the VSPEX for virtualized SharePoint 2013 solution. You may also need to calculate the total capacity of the volume for the SharePoint search components. Some guidelines for volume capacity planning are as follows:

a. Understand your customer’s estimate of the total content database size with yearly growth for crawl needs. You can easily get this number from the qualification worksheet. The value is referred to as ContentDBSize in the formula.

TotalIndexSize= ContentDBSize * 0.04

b. Determine the number of index partitions you will have, based on your scenario. Divide the TotalIndexSize by the number of index partitions.

c. Multiply each query component by 2 to calculate the disk volume capacity for a single query component to allow room for index merging.

For example, in the medium SharePoint farm, you will have four index partitions. Use the following formula to calculate each query component’s size: QueryComponentIndexSize = TotalIndexSize / 4 * 2

d. Calculate the size of the search-related databases. Use the following formula to estimate the total volume capacity of all four search-related databases:

SearchDBs = ContentDBSize * 0.01

e. Multiply the size of all four search-related databases by 2 to calculate the disk volume capacity for these databases.

For example, in the medium SharePoint farm, you have 4 TB content databases. In this case, you would calculate the volume size to host the

a. Calculate the total index



analytics reporting database, the crawl store database, the search administration database, and the link store database as follows:

SearchDBs = 4 TB * 0.01 * 2 = 80 GB

For detailed steps on how to scale out search components, refer to the VSPEX Implementation Guides.

Use 64 KB of the file allocation unit size (cluster size) for the SharePoint volumes:

Cluster size is determined when the partition is formatted by the OS or user. For the best performance, EMC recommends using 64 KB for SQL databases. For more information, refer to the topic Disk Partition Alignment Best Practices for SQL Server in the MSDN Library.

Customization consideration:

If customers have custom code for the SharePoint farm, EMC recommends that customers work together with vendors to estimate the additional capacity and IOPS requirement for the storage layout.

VNX for file design best practices:

When creating LUNs for VNX for file, consider the following best practices:

a. Create approximately one LUN for every four drivers in the storage pool.

b. Create the LUNs in even multiples of 10.

c. Numbers of LUNs = (number of drivers in pool divided by 4), rounded up to the nearest multiple of 10.

d. Make all the LUNs the same size.

e. Balance LUN ownership across SPA and SPB.

For more information, refer to EMC VNX Unified Best Practices for Performance.

FAST Suite design best practices:

As an extensible and customizable collaboration platform, usage patterns and workloads on SharePoint Server 2013 can vary greatly. While this guide caters and designs for typical deployments, as described by Microsoft and experienced by EMC, additional storage performance requirements may be demanded by certain highly active SharePoint environments.

The EMC FAST Suite— FAST VP and FAST Cache—provides two key technologies, available on the VNX series, that enable extreme performance in an automated fashion, when and where needed. FAST technology is an available option in VSPEX Proven Infrastructures. For more information on FAST Suite for VSPEX Proven Infrastructures, see the VSPEX Proven Infrastructures section.

As SharePoint has a significant number of active storage elements (such as databases, search indexes, and so on), it can be difficult to manually analyze and provision storage designs, and to continue to meet those ever-changing requirements. In such SharePoint environments, extreme performance demands are put on the storage to meet or exceed customer-driven response time service-level agreements (SLAs) and to continue to provide the best user experience.

http://msdn.microsoft.com/en-us/library/dd758814(SQL.100).aspx




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, first enable FAST Cache on the SharePoint Services storage pool.

FAST VP design best practices:

EMC recommends that you enable FAST VP on the VNX system and add additional Flash disks as an extreme performance tier into the SharePoint content database pool. For best use of the Flash tier, set all LUNs to auto-tier. You can verify this in the Advanced Data Services section for the storage pool properties in Unisphere.

Pool capacity utilization and configuration best practices:

Maintain some unallocated capacity within the pool to help with relocation schedules when using FAST VP.

Relocation will reclaim 10 percent free capacity per tier. This space is used to optimize relocation operations but also helps when new LUNs are created that want to use the higher tiers.

Avoid using enclosure 0_0.

Relocation best practices:

Schedule relocations for off-peak hours so the primary workload does not contend with the relocation activity.

Enable FAST VP on a pool, even if the pool has only one tier, to provide ongoing load balancing of the LUNs across the available drives.

Set the FAST policy for the participating pool LUNs to Start High then Auto-Tier (Recommended).

VNX for file considerations and best practices:

By default, a VNX for file system-defined storage pool is created for every VNX for block storage pool that contains LUNs available to file. (This is a mapped storage pool.)

All LUNs in a given file storage pool should have the same FAST VP tiering policy.

SharePoint specified FAST VP configuration:

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 22 demonstrates details of this mixed pool after FAST VP is enabled. For detailed configuration and reduced TCO information, refer to the VSPEX sizing concepts for virtualized SharePoint.

Put the database log file for the content databases in the RAID 1/0 SharePoint services pool.



Table 22. 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 1/0 Flash drive

For more information, refer to the best practices in the white paper EMC FAST VP for Unified Storage Systems.

FAST Cache design best practices:

You can use FAST VP in combination with other performance optimization software, such as FAST Cache. A common strategy is to use FAST VP to gain TCO benefits while using FAST Cache to boost overall system performance. EMC recommends that you use the available Flash drives first for FAST Cache, which can globally benefit all LUNs in the storage system, and then supplement performance as needed with additional Flash drives in the storage pool tiers.

When using Flash drives as FAST Cache, consider the following best practices:

Place all Flash drives (up to eight drives) in enclosure 0_0. If you have more than eight drives, consider the following:

Spread Flash drives across all available buses.

Mirror drives within one enclosure, to avoid mirroring across enclosure 0_0.

Preferred application workloads for FAST Cache are as follows:

Small-block random I/O applications with high locality

High frequency of access to the same data

Systems where current performance is limited by HDD capability, not Storage Processor (SP) capability

Avoid enabling FAST Cache for LUNs that are not expected to benefit, such as when:

The primary workload is sequential

The primary workload is large-block I/O

Avoid enabling FAST Cache for LUNs where the workload is small-block sequential, including database logs.

FAST Cache can improve overall system performance if the current bottleneck is drive-related. However, boosting the IOPS will result in an increase in CPU utilization on the VNX SPs. Systems should be sized so that the maximum sustained utilization is 70 percent.

Use Unisphere to check the SP CPU utilization and then proceed as follows:

SP CPU utilization less than 60 percent: Enable groups of LUNs or one pool at a time until they are equalized in the cache. Ensure that the SP CPU utilization is still acceptable before turning on FAST Cache for more LUNs/pools.

http://www.emc.com/collateral/software/white-papers/h8058-fast-vp-unified-storage-wp.pdf

http://www.emc.com/collateral/software/white-papers/h8058-fast-vp-unified-storage-wp.pdf



SP CPU utilization of 60 to 80 percent: Scale in carefully. Enable FAST Cache on one or two LUNs at a time, and verify that the SP CPU utilization does not go above 80 percent.

SP CPU utilization greater than 80 percent: Do not activate FAST Cache.

Avoid enabling FAST Cache for a group of LUNs where the aggregate LUN capacity exceeds 20 times the total FAST Cache capacity.

Enable FAST Cache on a subset of the LUNs first, and allow the LUNs to be equalized before adding the other LUNs.

Note: For storage pools, FAST Cache is a pool-wide feature so you have to enable or disable at the pool level for all LUNs in the pool.

This section describes three example storage layouts in this VSPEX Proven Infrastructure for virtualized SharePoint—one of a farm for VNXe, layered on a VSPEX Proven Infrastructure, and the other two for VNX, layered on a VSPEX Proven Infrastructure with and without FAST VP for the SharePoint content database pool. All of these examples follow the best practices and design considerations previously discussed.

Storage layout examples



Figure 8 shows an example of the storage layout in the SharePoint farm for the VNXe series.

Figure 8. Storage layout example: SharePoint 2013 small farm for the VNXe series



Figure 9 shows an example of the storage layout in the SharePoint farm for the VNX series without FAST VP enabled.

Figure 9. Storage layout example: SharePoint 2013 medium farm for VNX series without FAST VP



Figure 10 shows an example of the storage layout in the SharePoint medium farm for the VNX series with FAST VP enabled.

Figure 10. Storage layout example: SharePoint 2013 medium farm for VNX with FAST VP

Note: These are examples of a storage layout. To plan and design your own storage layouts for SharePoint over a VSPEX Proven Infrastructure, follow the guidance in the VSPEX Sizing Tool and the best practices in Storage layout and design considerations.



Virtualization design considerations

SharePoint Server 2013 is fully supported when you deploy it in a virtual environment that is supported by Hyper-V technology or VMware vSphere ESXi technology. The following sections describe the best practices and design considerations for SharePoint Server 2013 virtualization.

In this VSPEX Proven Infrastructure for virtualized SharePoint, EMC recommends that you consider the following best practices for virtualization design.

Virtualize the web servers and application servers. Operating in a virtual environment gives you the flexibility to reallocate resources across virtual machines as necessary to tune performance. You can also add and remove virtual servers more easily to address spikes in the usage of specific services that occur at predictable times throughout the year.

Application servers are good candidates for virtualization. Depending on the degree of specialization, which is reflected by the services they provide, they do not always have low resource requirements. A good example is a SharePoint application server that hosts the search crawl component. In this solution, EMC recommends that application servers that host search crawl components should have 12 cores, while application servers that host other service applications should have four cores. Table 23 demonstrates the recommended number of vCPUs for the application server, based on the purpose of the application server.

Table 23. Recommended number of vCPUs for the application server

Purpose of the application server Recommended number of vCPUs

Application server with search crawler 12 cores

Application server with other service applications

4 cores

Virtualize SQL Server. The database role is responsible for storing, maintaining, and returning data to the other roles in the farm. This role has the highest amount of disk I/O activity and can often have very high memory and processor requirements. There is high value in being able to simply migrate the SQL Server application to higher-powered servers or provide greater resourcing through virtualization.

Set the proper number of vCPU cores for the SQL Server virtual machine. The number of vCPU cores for SQL Server is related to the total number of users in the SharePoint farm. Table 24 demonstrates the recommended number of vCPUs for different ranges of total users.

Overview

Virtualization design best practices



Table 24. Recommended number of vCPUs for SQL Server

Total number of users Recommended vCPU number for SQL Server

Fewer than 1,000 users 4 cores

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

Note: In a large SharePoint farm with five web servers, EMC recommends you have 16 cores for virtualized SQL Server to keep the CPU utilization of SQL Server in the Green Zone.

Set the proper amount of memory for the SQL Server virtual machine. The memory required for SharePoint Server 2013 is directly related to the size of the content databases that you are hosting on the server that is running SQL Server. Table 25 demonstrates the RAM recommended for computers running SQL Server, based on the combined size of the content databases.

Table 25. Recommended RAM for SQL Server

Total number of users RAM recommended for computers running SQL Server

Fewer than 1,000 users 8 GB

Between 1,000 and 10,000 users 16 GB

Maximize the overall throughput by mixing the farm server roles on each host. For example, you can reduce disk contention by mixing web servers with application servers because they usually do not write to disk at the same time.

Spread the same SharePoint server role across different hosts. For example, you may have several web servers in a medium SharePoint farm. In this scenario, for redundancy considerations, EMC recommends that you spread these web servers across different hosts.

In VMware vSphere, enable the VMware HA, DRS, and vMotion functions. If you select vSphere as your hypervisor, enable the VMware HA, DRS, and vMotion functions on the ESXi servers to provide basic availability and scalability. As before, EMC recommends that you spread the SharePoint roles across different ESXi hosts.

The VMware DRS function can automatically balance the workload between the hosts by using the vMotion function. When SharePoint workloads increase, DRS automatically moves a bottlenecked virtual machine to another host with more available resources, without downtime.

After you enable the DRS function, consider using DRS affinity and anti-affinity rules. EMC recommends that you use DRS affinity and anti-affinity rules for specific groups of virtual machines (for example, a group of web servers) that should never reside on the same host. DRS also enables the grouping of virtual machines by a common name and restricting their execution to a specific subset of hosts. For detailed steps on how to configure DRS, refer to the VSPEX Implementation Guides.



In Hyper-V, enable the Hyper-V high availability and Live Migration functions. Enabling Hyper-V with System Center and integrating with System Center Operations Manager enables you to monitor the resource utilization of the Hyper-V hosts and virtual machines and can automatically balance resource utilization by using Live Migration to move virtual machines with no downtime.

When you want to enable the DRS function, ensure that the automatic rebalancing is not too aggressive as this can cause performance issues with constant Live Migration.

Monitor the performance of your whole VSPEX Proven infrastructure regularly. Monitoring performance not only happens at the virtual machine level, but also at the hypervisor level. For example, when the hypervisor is ESXi, you can use performance monitoring inside the SharePoint virtual machine to ensure virtual machine or SharePoint performance. Meanwhile, at the hypervisor level, you can use esxtop to monitor host performance. For detailed information on the performance monitoring tools, refer to the VSPEX Implementation Guides.

Application design considerations

Design considerations for SharePoint Server 2013 involve many aspects. The best practice and design considerations in this section provide guidelines for the most common and important ones.

SQL Server 2012 for SharePoint Server 2013

In this VSPEX Proven Infrastructure for virtualized SharePoint, EMC recommends that you consider the following best practices for the SharePoint 2013 farm design:

To ensure optimal performance for farm operations, EMC recommends that you install SQL Server 2012 on a dedicated server that does not run other farm roles and does not host databases for other applications.

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 (MAXDOP) option to 1 for SQL Server instances hosting SharePoint Server 2013 databases, to ensure that each request is served by a single SQL Server process. For detailed steps, refer to the VSPEX Implementation Guides.

For best performance, place the tempdb system database on a RAID 1/0-capable array. In this solution, EMC suggests using a minimum of two tempdb datafiles for the small SharePoint farm and a minimum of four datafiles for the medium SharePoint farm.

Set the database autogrowth values as a percentage instead of a fixed number of megabytes. The bigger the database, the bigger the growth increment should

Overview

Application design best practices



be. Consider, for example, that we used 10 percent autogrowth for the SharePoint databases. For detailed steps, refer to the VSPEX Implementation Guides.

EMC recommends that you continuously monitor SQL Server storage and performance to make sure that each production database server is adequately handling its load. For more information, refer to the MSDN Library topic Monitoring SQL Server Performance.

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.

For detailed configuration steps, refer to the VSPEX Implementation Guides.

SharePoint Server 2013 Publishing Portal

In this VSPEX Proven Infrastructure, EMC suggests that you use caching to the Publishing Portal for better performance in the SharePoint farm. Caching can provide big benefits in a publishing site. Be sure to use the appropriate caching type. When used correctly, caching can significantly improve the throughput and user response time. You can configure the following cache types:

Output cache: Stores the rendered output of a page. It also stores different versions of the cached page, based on the permissions of the users who are requesting the page.

Object cache: Reduces the traffic between the web server and the SQL database by storing objects such as lists and libraries, site settings, and page layouts in memory on the front-end web server. As a result, the pages that require these items can be rendered quickly, increasing the speed with which pages are delivered to the client browser.

Binary large object (BLOB) cache: Disk-based cache that controls the caching for BLOBs, such as frequently used image, audio, and video files, and other files that are used to display web pages, such as CSS and JS files. The BLOB cache is enabled on a front-end web server and improves performance by retrieving BLOB files from the database and storing them in a directory on the front-end web end server where they are served to users. This reduces the network traffic to and the load on the database server.

Anonymous search results cache: Used primarily by publishing sites that allow access to anonymous users. The anonymous search results cache saves search results from anonymous users and reuses them for later queries that are the same as the original query.

http://msdn.microsoft.com/en-us/library/ee377023(v=bts.10).aspx



For more information, refer to the article Plan for caching and performance in SharePoint Server 2013 on the Microsoft TechNet website. For detailed steps on creating a SharePoint 2013 Publishing Portal, refer to the VSPEX Implementation Guides.

SharePoint Server 2013 Document Management Portal

If you have a huge number of items such as Word documents, Excel spreadsheets, or PowerPoint presentations stored in the SharePoint Document Library, EMC recommends that you create very large document libraries by either nesting folders or using standard views and site hierarchy.

SharePoint Server 2013 supports high-capacity document storage. A document library can contain millions of documents. However, depending on how the content is used, the performance of sites that contain many documents can decrease. If you are planning a large-scale content management solution, refer to the article Plan document management in SharePoint 2013 on the Microsoft TechNet website.

For detailed steps on creating a SharePoint 2013 Document Management Portal, refer to the VSPEX Implementation Guides.

SharePoint Server 2013 Search Service

Before you design your SharePoint search topology in a farm, it is important for you to understand the search concepts described in Appendix B: SharePoint Server 2013 concepts.

The SharePoint Server 2013 Search Service contains a richer set of features and a more flexible topology model than earlier versions. Consider the following best practices before you implement your search topology:

The index temporary location resides in the SharePoint application servers that host the crawler component. All crawl items are temporarily downloaded to this location and stored during the crawl.

Table 26 details an example of the I/O pattern of this component, showing that the IOPS is high and read and write size is large. In this situation, EMC recommends that you change its default location (C:\Program Files\Microsoft Office Servers\15.0\Data\) to the SharePoint services pool, which is RAID 1/0. For details on how to change this location, refer to the VSPEX Implementation Guides.

Table 26. Example I/O pattern of the index temporary location in SharePoint Server 2013

IOPS Read:Write Read size (KB) Write size (KB)

410 2:3 129 90

Scale out the query and crawl components to multiple partitions for load balancing. EMC recommends placing the query components load on different servers to distribute the load.

If the number of items to crawl is up to 10 million items, all search roles can co-exist on one nonredundant server or on two servers.

http://technet.microsoft.com/en-us/library/ee424404.aspx

http://technet.microsoft.com/en-us/library/ee424404.aspx

http://technet.microsoft.com/en-us/library/cc263266.aspx




If the number of items to crawl is from 40 million items, add:

One crawl database per 20 million items

One index partition per 10 million items

Up to two query processing components

To optimize your crawl performance, consider creating more crawl components or adding more application servers for crawl.

Redirect all crawl traffic to the application server in the SharePoint farm. This prevents the crawler from using the same resources that are being used to render and serve web pages and content to active users.

By default, the SharePoint Server 2013 crawler crawls all available web servers in a SharePoint farm through the network load balancer in that farm. Therefore, when a crawl is occurring, the crawler can cause increased network traffic, increased usage of the storage and processor resources on the web servers, and increased usage of the resources on the database servers. Putting this additional load on all web servers at the same time can decrease performance across the SharePoint farm.

For detailed steps on search topology configuration, refer to the VSPEX Implementation Guides.



Backup and recovery design considerations

This section introduces the backup and recovery design considerations for the solution.

The EMC Avamar plug-in supports the backup and recovery of SharePoint, ranging from the entire SharePoint farm to various object levels, such as content databases or items. Additional flexibility includes the ability to change the installation type from the web server to the back-end and conversely. You should back up the other components in the SharePoint environment with the Avamar Client for Windows. This enables recovery not only for the web servers and content databases, but also for the related SharePoint servers.

If vSphere is protected by Avamar virtual machine image protection, users can restore the virtual machines without needing an Avamar Client installed on the hosts. Those hosts need to be restored from federated SharePoint backups if they are web servers or content databases.

The Avamar plug-in for SharePoint Volume Shadow (Copy) Service (VSS) relies on the base Avamar Client for Windows and enables the web servers and content databases to realize federated backups. For disaster-level recovery, virtual machine image recovery enables OS-level recovery. SharePoint-level recovery is applied after those resources are restored. The implementation of vSphere image-level protection is beyond the scope of this guide but is a viable option for restoring base operating systems.

Only the Avamar SharePoint VSS or Microsoft Office SharePoint Sever (MOSS) plug-in can enable federation between the web servers and content database servers. It is critical that those components are federated as they rely on data to be consistent with each other. A single web server has the Avamar SharePoint VSS plug-in installed and set to “front-end installation”. This manages the federated backup task. Even if other web servers exist, only one of them is set to the front-end installation type. Figure 11 shows a visual representation of an installation map.

Note: Using Data Domain as the backup target for Avamar is also an option. The Avamar Client and plug-ins are installed in the same way as when using Avamar as the backup target. If you use Data Domain, the only difference between methods is a checkbox in the dataset definition. This is called out in context within these implementation steps.

Overview

Considerations



Figure 11. Installation map

Table 27 lists the minimum hardware requirements.

Table 27. Hardware requirements for backup

Requirement Minimum

Memory (RAM) 2 GB

File system NTFS

Note: You must convert FAT 16 and 32 systems to NTFS.

Network 10BASE-T at a minimum; 100BASE-T or higher is recommended, configured with the latest drivers for the platform.

Minimum backup software and hardware requirements



Avamar plug-in for SharePoint granular-level recovery: Hardware and software requirements

The Avamar plug-in for SharePoint granular-level recovery (GLR) places additional demands on computer hardware and software resources, beyond the base requirements for the Avamar plug-in for SharePoint VSS. The following topics describe the various requirements for the Avamar plug-in for SharePoint GLR.

Memory The Avamar plug-in for SharePoint GLR may require additional memory (RAM). The amount of additional or total memory required depends on the current system performance with the existing memory:

If resources are already strained and performance is slow with regular operations of the Avamar plug-in for SharePoint VSS, then add significantly more memory to support SharePoint GLR operations.

If performance is currently adequate with regular operations of the Avamar plug-in for SharePoint VSS, then additional memory may not be required to support SharePoint GLR operations.

Third-party recovery tools may require additional memory. Consult the vendor documentation for the tool for specific memory requirements.

The minimum hardware requirements in Table 27 are for reference, as a minimum for the plug-in to operate. In the context of this guide, the environment will surpass these requirements.

Database size SharePoint Server 2013 Service Pack 1 (SP1) supports content databases up to 4 TB in size, and the Avamar software supports databases up to the maximums allowed by SharePoint. However, the maximum database size recommended by Microsoft for rapid backup and recovery is 200 GB for SharePoint Server 2013, as specified on the Microsoft TechNet website.

Third-party recovery tool A third-party recovery tool, such as Kroll Ontrack, is required to browse and restore individual items from the data restored to the Administrator Console with the Avamar plug-in for SharePoint VSS.

The Kroll Ontrack package is not included in the Avamar plug-in for SharePoint VSS installation and must be purchased separately.

Kroll Ontrack PowerControls is available for resale through the EMC Select program. You can order it within the EMC ordering system. The Avamar ordering flow on Direct Express and Channel Express provides the option of selecting PowerControls. For details on the software, go to the EMC Online Support website and select Home > Products > EMC Select > Kroll Ontrack to view the Kroll Ontrack landing page.

The EMC Avamar Compatibility and Interoperability Matrix, also available on the EMC Online Support website, provides the most up-to-date and accurate listing of supported third-party recovery tools.






Mapped network drive

For SharePoint GLR you need to create an Avamar virtual drive, which appears as a local drive in folder windows such as Windows Explorer. If another user or user session has mapped a network drive within a user session on a client machine, the Avamar software cannot detect those drive mappings when assigning a drive letter for the Avamar virtual drive. If you select a drive letter that is already mapped during SharePoint GLR, then the folder view of the drives shows the mapped network drive. The drive letter assignment for the Avamar virtual drive is not visible.

To prevent this from occurring, use a drive letter that you know is not in use when you specify the drive letter for the Avamar virtual drive during the recovery. If the “Z” drive is already mapped to a network drive, do not use the default value of slash (/) because that causes the Avamar virtual drive to map to the Z:\ drive.

If you notice drive-mapping issues after you create the Avamar virtual drive, then disconnect the conflicting network mapping in GLR sessions where it does not appear. The Avamar virtual drive then appears.

Multistreaming Avamar configuration requirements

When you specify multistreaming options for a backup, specify a maximum of one backup stream for each disk in the backup set. For example:

If you back up two databases with each database on its own disk, you can specify a maximum of two streams.

If you back up two databases with each database and its logs on two disks (for a total of four disks), you can specify a maximum of four streams.

Database requirements

SharePoint documentation provides a list of SQL Server versions that SharePoint supports. The Avamar plug-in for SharePoint VSS supports all SQL Server versions that SharePoint supports.

Notes

Full farm recovery and disaster recovery requires a full backup provided by the Avamar plug-in for SharePoint VSS. You cannot use a backup from the Avamar plug-in for SQL Server. See the section “Avamar plug-in for SQL Server” in the EMC Avamar 6.1 for SharePoint VSS User Guide for more information about the advantages and disadvantages of using the Avamar plug-in for SQL Server for SharePoint database backups.

If you plan to use the Avamar plug-in for SQL Server to back up SharePoint databases, then review the EMC Avamar Compatibility and Interoperability Matrix, available on the EMC Online Support website, for a list of SQL Server versions that the SQL Server plug-in supports. It is important to understand that using the Avamar plug-in for SQL Server does not protect the SharePoint instance at a farm level.

You can use the Avamar plug-in for SQL Server to back up all databases in the environment except for the search database. The Avamar plug-in for SQL Server backup does not include the search index file, which must be synchronized with the search database backup so that they can both be restored together.




In addition, the Avamar plug-in for SharePoint VSS only performs full backups of SharePoint SQL content databases.

A full backup does not manage SQL Server log file truncation. To work around this limitation, set the SQL Server databases to Simple Recovery Model so that log truncation is not necessary.

Required account privileges

You must run the Avamar plug-in for SharePoint VSS agent service and the SharePoint administrator with the same domain account.

In addition, to perform a federated farm restore, which is a full farm restore of a distributed farm, you must have domain-level administrator access. Typically, the administrator account you used when installing and configuring the SharePoint farm is a member of the Administrators group on each server, and can be used as a valid account for the federated restore. If you use a different administrator account, other than the one you used to install SharePoint, you must do both of the following:

1. Add the SharePoint Administrator account to the Domain Administrators group.

2. Assign the Log on as a service right to the SharePoint Administrator account on each server that runs any of the SharePoint services. This setting is specified in Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service.

Avamar Backup Agent service runs as LocalSystem

The Avamar Backup Agent service must be running as LocalSystem on all machines.

Services and writers

Table 28 lists the services and writers required for Avamar SharePoint VSS plug-in operations. If in a federated environment, each of these may be on a different machine. This list may be useful for troubleshooting backup or recovery failures.

Table 28. Services and writers used by Avamar plug-in for SharePoint VSS

Microsoft application Service or writer name

SharePoint Server 2013 SharePoint2013Administration(SPAdminV4)

SharePoint2013Timer(SPTimerV4)

SharePointFoundationSearchV4(SPSearch4)

SharePointServerSearch14(OSearch14)

SharePoint2013VSSWriter(SPWriterV4)

SQL Server SQLServer(MSSQLSERVER)

SQLServerVSSWriter(SQLWriter)

Chapter 6: Solution Verification Methodologies


Chapter 6 Solution Verification Methodologies


Overview ............................................................................................................... 74

Baseline hardware verification methodology .......................................................... 74

Application verification methodology ..................................................................... 74

Backup and recovery verification methodology ...................................................... 79

Test tools .............................................................................................................. 80



Overview

This chapter describes the methodologies used to verify the VSPEX for virtualized SharePoint 2013 solution:

Baseline hardware verification methodology

Application verification methodology

Backup and recovery verification methodology

Baseline hardware verification methodology

Hardware consists of the computer's physical resources such as processors, memory, and storage. Hardware also includes physical network components such as NICs, cables, switches, routers, and hardware load balancers. You can avoid many performance and capacity issues by using the correct hardware for the VSPEX for virtualized SharePoint 2013 solution. Conversely, a single misapplication of a hardware resource, such as insufficient memory on a server, can affect performance across the entire farm.

For detailed steps on verifying the redundancy of the solution components, refer to the VSPEX Implementation Guides.

Application verification methodology

After you verify the hardware and redundancy of the solution components, the next stage is SharePoint application testing and optimization, which is also a critical step of the VSPEX for virtualized SharePoint 2013 solution. Test the new VSPEX Proven Infrastructure before deploying it to production to ensure the architectures you designed achieve the required performance and capacity targets. This enables you to identify and optimize potential bottlenecks before they negatively impact users in a live deployment.

Before you start validating your SharePoint performance on the VSPEX Proven Infrastructure, make sure you have deployed SharePoint 2013 in your VSPEX Proven Infrastructure, based on the VSPEX Implementation Guides. You can test and validate SharePoint only after it has been implemented.

Table 29 describes the high-level steps to complete before you put the SharePoint environment into production.

Table 29. High-level steps for application validation

Step Description Reference

1 Define the test scenario (as noted in the VSPEX Sizing Tool) to demonstrate your realworld business workload.

Defining the test scenarios

2 Understand the key metrics for your SharePoint environment to achieve performance and capacity that meet your business requirements.





3 Use the VSPEX Sizing Tool for SharePoint to determine the architecture and resources of your VSPEX Proven Infrastructure.

VSPEX Proven Infrastructure partner portal

4 Design and build the SharePoint solution on the VSPEX Proven Infrastructure.

VSPEX Implementation Guides

5 Create the test environment using Microsoft Visual Studio Team System (VSTS).

Application Lifecycle Management with Visual Studio and Team Foundation Server

6 Populate or copy data from an old production environment to demonstrate a realworld environment.

Test tools for database population

7 Run the tests, analyze the results, and optimize your VSPEX architecture.

Test tools for database population

Before running a SharePoint test, it is important that you define the test scenarios according to the business requirements. You can easily work out your own test scenarios and test plans in the VSPEX Sizing Tool.

The key factors we considered in the VSPEX for virtualized SharePoint 2013 test scenario are:

Operations: Define the different operations that end users perform in the SharePoint website. Understanding these key operations helps you to demonstrate a real environment test. Table 30 lists some of the general operations we considered in the VSPEX for virtualized SharePoint 2013 solution.

Table 30. General operations

Operation Description

Browse Browse the SharePoint page, including the home page.

Access a document library list view page.

Modify Download a random document in SharePoint (for example, DOC, DOCX, PPT, or XLS).

Edit and update the properties of the document.

Search Search for keywords in the SharePoint search portal.

Document upload Upload a document to SharePoint.

Workload: Define the key operational characteristics of the farm, including the user base, concurrency, the features being used, and the user agents or client applications that are used to connect with the farm. Understanding your expected demand and usage characteristics enables you to validate your environment more accurately, and reduces the risk when constantly running the

Defining the test scenarios

http://www.emc.com/platform/vspex-proven-infrastructure/index.htm



http://msdn.microsoft.com/en-us/library/fda2bad5.aspx







system in the production environment. Table 31 lists some of mixed workloads considered in the VSPEX for virtualized SharePoint 2013 solution.

Table 31. Mixed workloads

Mixed workload Scenario % in the mix

Publishing Portal:

The operation mainly focuses on page browse.

Browse 80

Modify 10

Search 10

Document Management Portal:

Document activities are typically 30%.

Browse 50

Modify 20

Search 20

Document upload 10

Operational states: The load of a production system has two major operational states—the Green Zone state, in which the system is operating under the normal, expected load range, and the Red Zone state, in which the farm experiences very high, transient resource demand that can only be sustained for limited periods. In the VSPEX for virtualized SharePoint 2013 solution, we specified the Green Zone and Red Zone with the following criteria:

Green Zone:

All the operations were completed in less than 3 seconds.

All SharePoint servers have a CPU utilization of less than 70 percent; all the SQL servers have a CPU utilization of less than 50 percent.

Failure rate is less than 0.01 percent.

Red Zone:

All the operations were completed in less than 3 seconds.

All SharePoint servers have a CPU utilization of less than 90 percent; all the SQL Server instances have a CPU utilization of less than 70 percent.

Failure rate is less than 0.1 percent.

Note: During a search crawl, it is acceptable for the CPU utilization and disk response time to exceed the stated SLAs for a temporary period of time.

In addition to the test scenario, it is important to know the goal of the SharePoint testing to make it easier to decide which metrics to capture and what thresholds must be met for each metric when running the SharePoint tests. To verify the VSPEX for virtualized SharePoint 2013 solution, we considered the following key metrics:

Requests per second (RPS): This is also known as Passed Tests per Second in the VSTS test. RPS is the number of operations received by a farm or server in one second. Most tests are based on RPS, which can tell you how many requests the SharePoint farm can service in a given period of time. RPS can be




used for measuring how many pages or documents are delivered, uploaded, or modified, as well as how many queries are executed.

This is a common measurement of the server and farm load. For more information about how RPS is calculated, refer to Appendix C: RPS calculation methodology.

Operation duration: The length of time it takes to complete a user request (SharePoint operation). Different organizations define different goals, based on their business requirements and user expectations. Some organizations can afford a latency of several seconds, whereas other organizations require very fast transactions. In the VSPEX for virtualized SharePoint 2013 solution, the default response time for each common SharePoint user operation is to be completed within 3 seconds or less.

Note: Microsoft publishes SLA response times for each SharePoint user operation. Common operations (such as browse and search) should be completed within 3 seconds or less, and uncommon operations (such as modify) should be completed within 5 seconds or less. These response-time SLAs were comfortably met or exceeded.

The VSPEX Sizing Tool helps you to understand your basic metrics and thresholds to meet your customer’s business requirement.

When you have decided the test objectives, defined the measurements, and determined what the capacity requirements are for your farm, the next objective is to design and create the test environment for the VSPEX for virtualized SharePoint solution. The test farm should duplicate the production environment as closely as possible. You should consider, all the features previously described, for example: storage layout, network load balance, networking, and so on.

In the VSPEX for virtualized SharePoint 2013 solution, we used VSTS in conjunction with code to simulate realworld SharePoint user activity. For more information about the sample performance test code, refer to the Sample code for SharePoint performance testing section. When you set up your test environment, you need to create a test plan for the servers in the SharePoint Server 2013 farm, and also for the machines needed to execute the tests. Generally, more of the machines are used as load test agents. The agents are the machines that take instructions from the test controller about what to test, and issue requests to the SharePoint Server 2013 farm. The test results themselves are stored on a SQL Server-based computer. For more information about VSTS, see the Application Lifecycle Management with Visual Studio and Team Foundation Server topic at the MSDN Library.

As well as the test environment and test tool, you may also need to use some other tools to prepare the whole test environment for SharePoint. For more information on tools, see the Backup and recovery verification methodology section. Also, refer to the Microsoft TechNet website for more information about building the test environment for the SharePoint environment.

After the test environment is created, you need to decide what type of data you are going to run. If you do not have any production environment data, refer to the Backup and recovery verification methodology section for the general data population tool to

Creating the test environment

Populating the database



http://technet.microsoft.com/en-us/sharepoint/fp123618



demonstrate a customer environment. EMC recommends that you use data from an existing production farm and restore it to the VSPEX SharePoint environment. If you run tests against made-up or sample data that is different from your real content, you run the risk of skewed test results.

After the database is populated and the test environment is created, run the tests based on the designed test scenario using VSTS. With Visual Studio Team Test Load Agent, you can configure the browser mix, network mix, load patterns, and run settings for different workloads in the web tests.

We followed these general best practices in the VSPEX for virtualized SharePoint 2013 solution:

Do not use the think time feature. Think time is a VSTS feature that enables you to simulate the time that users pause between clicks on a page. For example, a typical user might load a page, spend three minutes reading it, and then click a link on the page to visit another site. Trying to model this in a test environment is nearly impossible to do correctly, so it does not add value to the test results. Modeling is difficult because most organizations do not have the ability to monitor different users and the time they spend between clicks on different types of SharePoint sites (such as publishing or search or collaboration). Furthermore, using the think time does not add value because even though users may pause between page requests, the SharePoint Server 2013-based servers do not.

Use a goal-based load pattern in the VSTS test for the Green Zone test. A goal-based usage test is when you establish a threshold for a certain diagnostic counter, like CPU utilization, and test attempts to drive the load to keep that counter between the minimum and maximum threshold that you defined. If you want to understand your general throughput for the VSPEX SharePoint environment in a normal situation, use goal-based load pattern tests to establish a threshold for the CPU utilization of the SharePoint Server. For more information about different patterns, see the Running Load and Web Performance Tests topic at the MSDN Library.

Once the test is complete, you can use the Visual Studio Analyzer to check the results and verify that you have achieved the key metrics in your test environment. If the test results are not ideal, it is easy to identify the bottleneck using different tools. For detailed information about tools, refer to the corresponding guide in the VSPEX Implementation Guides section.

After identifying potential bottlenecks, refer to the VSPEX Proven Infrastructure documentation to make sure that you have the correct configuration of VNXe/VNX, switches, hypervisor, or load balancer for the VSPEX for virtualized SharePoint 2013 solution. System bottlenecks represent a point of contention where there are insufficient resources to service user transaction requests. Consider adding more resources into the solution to meet the requirement. Often, the reason for the bottleneck will be inefficient custom code or third-party solutions due to customization.

For detailed configuration information, refer to the VSPEX Implementation Guides section.

Running tests, analyzing results, and optimization

http://msdn.microsoft.com/en-us/library/ee923688.aspx




Backup and recovery verification methodology

The topology of SharePoint can vary depending on the specific requirements of the implementation. For a summary review of data protection, initial implementation points, and recovery options, refer to this list:

Install the Avamar Client for Windows on all SharePoint hosts, including those that are not web servers or content servers. This provides restore abilities for all farm servers in the event that other components need to be restored. Use of Avamar VMware vSphere image protection is also a consideration in the protection and recovery plans for base OS/virtual machine recovery.

Install the Avamar SharePoint VSS plug-in with one front-end configuration installation and the rest as the back end, even if there are multiple web servers. The front-end Avamar SharePoint VSS plug-in acts as the master to ensure the federated VSS snapshot take place throughout the farm in relation to web and content servers.

The first SharePoint VSS backup should not use multiple streams. The base Level 0 backups are very I/O intense. Single stream use alleviates resource utilization. This only applies to the very first back up. To use a single stream for the first backup, edit the existing SharePoint dataset you have created and set streams to 1.

The granular recovery feature is possible with the Kroll Ontrack PowerControls software. Avamar’s restore tasks enable the GLR option that mounts the virtual device for Kroll to use for granular recovery needs. This alleviates the need to restore the entire database in order to recover a subset of content.

When you install Avamar SQL Server plug-ins on the back-end servers, this enables you to recover other databases into the farm. It also enables a SharePoint Administrator to add new content to the farm. The SQL Server plug-in is not intended to be used for the existing farm content, because the plug-in needs to be federated with the indexes in the farm. The SharePoint VSS plug-in enables that requirement. However, a SQL Server backup of the content databases does enable that content to be restored out of place, or into another SQL Server instance, for migration purposes. Those tasks are then finished by a SharePoint Administrator and are added to the new SharePoint farm.

The Avamar plug-in for SharePoint VSS performs only full backups of the SharePoint SQL content databases. A full backup does not manage SQLServer log file truncation. To work around this limitation, set the SQL Server databases to Simple Recovery Model so that log truncation is not necessary.

For specific expectations about performance or deduplication results, EMC offers a Backup Recovery Systems (BRS) assessment to analyze content based on actual data. Because the Avamar and Data Domain implementation and sizing is a global task, which includes many backup requirements, it is outside the scope of this document. The BRS assessment activity, whether onsite with installed tools or with provided information from a site, is from where the design specifications are driven.

Validating the backup and recovery plan



Test tools

In this VSPEX for virtualized SharePoint 2013 solution, we used the Bulk Loader tool to create unique documents. This command-line tool, written using the Microsoft .NET 4.0 Framework, can create unique documents based on a Wikipedia dump file. The utility enables you to create up to 10 million unique Word, Excel, PowerPoint, and HTML files of various sizes so you can load different content types of different sizes directly into the SharePoint 2013 Document Libraries. This tool uses a dump file of Wikipedia content as input to allow the creation of up to 10 million unique documents to a disk location.

For more information on the bulk loader tool, see the Bulk Loader - Create Unique Documents based on Wikipedia Dump File topic at the MSDN Library.

In this VSPEX for virtualized SharePoint 2013 solution, we used the LoadBulk2SP tool to load documents into the SharePoint Server. The tool was written using C# and the 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 targeted web applications and document libraries specified in the application configuration.

For more information on the LoadBulk2SP tool, see the Load Bulk Content to SharePoint 2010 topic at the MSDN Library.

In this VSPEX for virtualized SharePoint 2013 solution, we used sample Visual Studio 2010 to provide load and stress testing for search, document download, and view pages scenarios. Refer to the sample code and customize in your own VSPEX solution to validate the SharePoint 2013 performance.

For more information, see the SharePoint Performance Testing topic at the MSDN library.

Sample tool to create large number of random documents

Sample tool to load documents into SharePoint

Sample code for SharePoint performance testing

http://code.msdn.microsoft.com/Bulk-Loader-Create-Unique-eeb2d084


http://code.msdn.microsoft.com/Load-Bulk-Content-to-3f379974


http://code.msdn.microsoft.com/SharePoint-Testing-c621ae38

Chapter 7: Reference Documentation


Chapter 7 Reference Documentation


EMC documentation ............................................................................................... 82

Other documentation ............................................................................................. 82

Links ..................................................................................................................... 83



EMC documentation

The following documents, available from the EMC Online Support or EMC.com websites, provide additional and relevant information. If you do not have access to a document, contact your EMC representative.

EMC Unisphere Remote: Next-Generation Storage Monitoring - A Detailed Review

EMC FAST VP for Unified Storage Systems

EMC VNXe Series Using a VNXe System with Microsoft Windows Hyper-V

EMC VNXe Series Using a VNXe System with NFS Shared Folders

EMC VNX Unified Best Practices for Performance - Applied Best Practices Guide

EMC VNXe Series Configuration Worksheet

EMC VNX Series Configuration Worksheet

EMC VSI for VMware vSphere: Storage Viewer - Product Guide

EMC VSI for VMware vSphere: Unified Storage Management - Product Guide

EMC VNX Host Connectivity Guide for VMware ESX Server

VNX Operating Environment for File Release Notes Version

EMC Avamar 6.1 for SharePoint VSS User Guide

EMC Avamar 6.1 Administration Guide.pdf

EMC Avamar 6.1 for Hyper-V User Guide.pdf

EMC Avamar 6.1 for VMware User Guide.pdf

EMC Avamar Compatibility and Interoperability Matrix

Other documentation

For documentation on Microsoft Hyper-V and Microsoft SharePoint, refer to the Microsoft website at http://www.microsoft.com. For documentation on VMware vSphere, refer to the VMware website.


http://www.emc.com/resource-library/resource-library.htm

http://www.microsoft.com/

http://www.vmware.com/



Links

Microsoft TechNet

Refer to the following articles on the Microsoft TechNet website:

Performance and capacity test results and recommendations (SharePoint Server 2013)

Configure cache settings for a web application in SharePoint Server 2013

MSDN Library

Refer to the following topics in the MSDN Library:

Application Lifecycle Management with Visual Studio and Team Foundation Server

Disk Partition Alignment Best Practices for SQL Server

Bulk Loader - Create Unique Documents based on Wikipedia Dump File

Load Bulk Content to SharePoint 2010

SharePoint Performance Testing

Running Load and Web Performance Tests

Note: The links provided were working correctly at the time of publication.









http://code.msdn.microsoft.com/SharePoint-Testing-c621ae38


Appendix A: Qualification Worksheet


Appendix A Qualification Worksheet

This appendix presents the following topic:

VSPEX for virtualized SharePoint 2013 qualification worksheet ............................. 86



VSPEX for virtualized SharePoint 2013 qualification worksheet

Before sizing the VSPEX solution, use the qualification worksheet to gather information about the customer’s business requirements. Table 32 shows the qualification worksheet for virtualized SharePoint 2013.

Table 32. VSPEX for virtualized SharePoint 2013 qualification worksheet

Question Answer



SharePoint 2013 Farm 1

Annual growth rate (%)?

Is the SharePoint Web application going to be accessed globally? Yes or No

Initial farm size (GB)?

Number of users?

User concurrency at peak (%)?

What is the main purpose of the SharePoint Web application? Publishing Portal or Document Management Portal

Do you use or intend to use the My Sites function? Yes or No

What is the percentage of total users who will create My Sites?


Do you intend to enable FAST VP? Yes or No

Do you heavily rely on the RELY ON THE SHAREPOINT SharePoint search function? Yes or No





Number of users?









Question Answer

Do you heavily rely on the SharePoint search function? Yes or No





Number of users?







Do you heavily rely on SharePoint search function? Yes or No

A standalone copy of the qualification worksheet is attached to this document in PDF format. To view and print the worksheet:

1. In Adobe Reader, open the Attachments panel as follows:

Select View > Show/Hide > Navigation Panes > Attachments.

or

Click the Attachments icon as shown in Figure 12.

Figure 12. Printable qualification worksheet

2. In the Attachments panel, double-click the attached file to open and print the qualification worksheet.

Printing the qualification worksheet

Appendix B: SharePoint Server 2013 Concepts


Appendix B SharePoint Server 2013 Concepts


SharePoint Server 2013 concepts .......................................................................... 90



SharePoint Server 2013 concepts

Review the key SharePoint Server 2013 concepts listed in Table 33. It is important that you fully understand these key concepts.

Table 33. SharePoint Server 2013 fundamental concepts

Concept Description

Server farm The top-level element of a logical architecture design for SharePoint Server.

Web application An IIS website that is created and used by SharePoint Server 2013.

Web application is an integration of SharePoint and ASP.NET which makes sure SharePoint takes control over every request that reaches IIS.

Content database Provides web application content storage. You can also have multiple content databases in a web application.

Read and write characteristics depend on the user profile: the Publishing Portal is read-intensive; the Document Management Portal could be write-intensive.

Site collection A set of websites that have the same owner and share administration settings.

Site One or more related web pages and other items (such as lists, libraries, and documents) that are hosted inside a site collection.

Service applications A service application provides a resource that can be shared across sites within a farm or, in some cases, across multiple farms.

My Sites My Sites are special SharePoint site collections that contain profile information about a user, links to content created by a user and stored in SharePoint databases, and information about the people, interests, and activities a user is tracking.

Publishing Portal A starter site collection that can be used for an Internet site or a large intranet portal. The site includes a home page, sample press releases site, search center, and 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 collection in which you can centrally manage and collaborate on documents in your organization.

Figure 13 shows the basic content structure in a SharePoint Server 2013 farm. In the SharePoint farm, you can create multiple web applications to host IIS websites with different URLs. For each web application, you can have multiple content databases. You can create different site collections in one content database, including the Publishing Portal or Document Management Portal. Each site collection can have multiple sites with different lists and document libraries to store list items and different types of documents.

SharePoint Server 2013 fundamentals



Figure 13. SharePoint Server 2013 content structure

Table 34 lists the key concepts of the SharePoint search service. It is important to understand these concepts before designing the SharePoint search function.

Table 34. SharePoint search service concepts

Concept Description

Search service application

A search service application provides the search function to end users to search across the sites in the farm, or even across multiple farms.

Crawling Collects content to be processed.

Indexing Organizes the processed content into a structured or searchable index.

SharePoint Server 2013 Search Service



Concept Description

Query processing Retrieves a relevant result set relative to a given user query.

Crawl component Crawls the content sources to collect crawled properties and metadata from the 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.

Analytics processing component

Analyzes the crawled items and how users interact with the search results. The analyses are used to improve the search relevance and to create search reports and recommendations.

Index component Receives the processed items from the content processing component and writes them 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. This helps to optimize precision, recall, and relevance. The queries are sent to the index component, which returns a set of search results for the query.

Search administration component

Runs the system processes for search, and adds and initializes new instances of search components.

Search administration database

The search administration database stores search configuration data and the access control list (ACL) for the crawl component. There can be only one search administration database per search service application.

Analytics reporting database

Stores the results of usage analysis, such as the number of times an item has been viewed. It also stores statistics from the different analyses. These statistics are used to create usage reports.

Crawl database The crawl database stores tracking information and details about crawled items. For example, it stores information about the last crawl time, the last crawl ID, and the type of update during the last crawl.

Link database The link database stores information extracted by the content processing component. It also stores information about the number of times people have clicked on a search result. The information is stored unprocessed; the analytics processing component performs the analysis.

Appendix C: VSPEX Sizing Tool for Virtualized SharePoint


Appendix C VSPEX Sizing Tool for Virtualized SharePoint


VSPEX sizing concepts for virtualized SharePoint................................................... 94




In the VSPEX Sizing Tool, one of the key metrics is requests per second (RPS). Most tests are based on RPS, which can tell you how many requests the SharePoint farm can service in a given period of time. RPS can be used for measuring how many pages or documents are delivered, uploaded, or modified, as well as how many queries are executed.

RPS is calculated automatically after customers complete the qualification worksheet in the VSPEX Sizing Tool. The formula is:

Total RPS = Active User * Heavy User Load

“Active User” means the average number of active users at any point in time. In cases where the distribution of the users is worldwide, we assume that only half of the total number of users is active due to the time-zone gap.

SharePoint site users can be classified into four groups:

Light users generate 20 requests per hour or 2 user operations per hour (user ops/hour)

Typical users generate 36 requests per hour or 3.6 user ops/hour

Heavy users generate 60 requests per hour or 6 user ops/hour

Extreme users generate 120 requests per hour or 12 user ops/hour

In this VSPEX Sizing Tool, we used a heavy users profile as an assumption, which is suitable for most user scenarios.

For example, if you get the following answers from a customer:

Question Answer

Is the SharePoint Web application going to be accessed globally? Yes


User concurrency at peak (%)? 20%

Then, the total RPS is:

Total RPS = 10,000 * 0.5 * 20% * 60/3600 = 17

If it is your first time using a SharePoint farm, you might need to estimate your content database storage size. The questionnaire in Table 35 describes how to estimate the content database size.

RPS calculation methodology

Estimate content database size



Table 35. Formula to estimate content database size

Question Answer

Number of documents?

Refer to D in the formula.

For the Document Management Portal and Publishing Portal, you can calculate the number of documents that are managed and generated by a process.

If you are migrating from a current system, it may be easier to extrapolate your current growth rate and usage. If you are creating a new system, review your existing file shares or other repositories and estimate based on that usage rate.

Average size of documents?

Refer to S in the formula.

It may be worthwhile to estimate averages for different types or groups of sites. The average file size for document management or publishing portals can vary significantly.

List Items?

Refer to L in the formula.

List items are more difficult to estimate than documents. We generally use an estimate of three times the number of documents (D), but this will vary based on how you expect to use your sites.

Number of noncurrent versions?

Refer to V in the formula.

Estimate the average number of versions any document in a library will have (this value will usually be much lower than the maximum allowed number of versions).

After you complete the questionnaire, use the following formula to estimate the size of your content databases:

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

For example, if you get the following answers from a customer:

Question Answer

Number of documents (D) 200,000

Average size of documents (S) 500 KB

List Items (L) 50,000

Number of non-current versions (V) 2

Then, the database size is:

Database size = (((200,000 x 2)) × 500) + ((10 KB × (50,000 +

(200,000 x 2))) = 204,500,000 KB or 195 GB

Appendix D: High-level SharePoint Server 2013 Sizing Logic and Methodology


Appendix D High-level SharePoint Server 2013 Sizing Logic and Methodology


High-level SharePoint Server 2013 sizing logic and methodology .......................... 98



High-level SharePoint Server 2013 sizing logic and methodology

This section describes how to size the SharePoint Server 2013 farm environment on an EMC VSPEX Proven Infrastructure. Sizing SharePoint Server 2013 depends on multiple factors, such as farm purpose, user access load, service application load, and capacity. These factors can affect the farm topology and storage layer design.

Table 36 details the steps to follow to size SharePoint Server 2013 for the VSPEX Proven Infrastructure.

Table 36. High-level steps for SharePoint farm Sizing


1 Determine the SharePoint topology based on the customer’s requirement, including the:

Number of web server roles and required compute resources

Number of application server roles and required compute resources

Database server compute resource sizing

SharePoint topology and compute resource sizing

2 Determine the storage requirement for a SharePoint farm based on the customer’s need, including:

VSPEX private cloud pool

Content database pool storage layout

Services pool storage layout

MySite pool storage layout

Storage layout sizing for SharePoint Server 2013

3 If the customer has more than one SharePoint farm on the VSPEX Proven Infrastructure, repeat Step 1 and Step 2 to size all the SharePoint farms. In this VSPEX Proven Infrastructure, we supported a maximum of three SharePoint farms on the VSPEX Proven Infrastructure.

4 If customer has other applications to be deployed on the VSPEX Proven Infrastructure, refer to the appropriate Design Guide to size the other applications.

VSPEX Proven Infrastructure partner portal

5 Aggregate all the required resources and select the right VSPEX Proven Infrastructure.

Select the right VSPEX Proven Infrastructure

Note: If the VSPEX Sizing Tool is not available, these manual sizing instructions can be used to provide an approximate single application sizing. The VSPEX Sizing Tool, with its multi-application, multi-instance capability is recommended as the preferred sizing approach.

Overview






The SharePoint farm comprises SharePoint servers with different roles. Topology sizing and design considers how to distribute the roles on a certain number of servers. With a good topology design, compute resources are appropriately distributed and the customer’s requirement for the SharePoint application is better satisfied. This section introduces a high-level view of sizing the SharePoint farm topology and compute resource.

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

SharePoint Server 2013 web server sizing

The web server directly manages users’ 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 role that the web server plays helps you to start sizing of the farm.

The qualification sheet contains the information needed to size the farm. To size the web server numbers of the SharePoint farm, you need to know:

The number of users

The percentage of user concurrency at peak

If 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 active user number. The formula for calculating the active user number is:

Active user number = Number of users * User concurrency (need to

/2 if it is global)

Web applications with different purposes have different access characteristics, which can result in varying web server resource consumption. For example, in our VSPEX Proven Infrastructure, we used the numbers in Table 37 to define the relationship between the active user number and web server (WFE) number.

SharePoint topology and compute resource sizing



Table 37. Sizing the web server by active user number

Main purpose of web application

Active user number WFE server number

Publishing portal Less than 120 1 (web server with application server in one box)

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 management portal

Less than 120 1 (web server with application server in one box)

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 active user number can be transferred to RPS under a specific kind of user load. For example, for a heavy user load where one user generates 60 requests per hour and we have 600 active users, the calculation would be:

RPS = 600 active users * 60 request / 3600 second = 10

request/second RPS is the key metric to collect when validating the SharePoint solution.

Compute resource for web server role 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:

Every 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 38 lists the detailed information we used to calculate the web server compute resource in the VSPEX Proven Infrastructure.



Table 38. Web server compute resource assignment

Server type vCPU Memory Reference virtual machines of compute resources

Web server 4

(4 reference virtual machines)

12 GB


6

Web server (including application server role)

12


12 GB


12

After completing the web server sizing, the next step is to size the application servers.

Application server sizing

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 at will. In the VSPEX Proven Infrastructure, we mainly focused on the application servers hosting the search application.

For search service applications, the application server can have six roles. General guidelines on scaling the application servers to satisfy common search usage are provided.

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

Use Table 39 and Table 40 to confirm the application server number and its roles.

The VSPEX qualification sheet for SharePoint Server 2013 has a question “Do you heavily rely on the SharePoint search function?” If the customer has a large amount of content to be searched with a high expectation of search content freshness, the answer would be “yes”. If the customer answers “no”, refer to Table 39 to size the application servers. If the customer answers “yes”, refer to Table 40 to size the application servers.



Table 39. Sizing application servers for a normal farm

Web server number

Application server number

Description

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 40. Sizing application servers to search a heavily used farm

WFE number Application server number

Description

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


Two query-type


Two query-type

Compute resource sizing for application servers In this VSPEX Proven Infrastructure, we used the following best practices to size the compute resource for the application servers.

Application severs 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 41 shows compute resource detail of each type of application server.



Table 41. Application server compute resource assignment

Server type vCPU Memory Reference virtual machines of compute resources

Application

(query-type)

4


12 GB


6

Application

(crawler-type)

12


12 GB


12

Application

(all-in-one)

12


12 GB


12

Database server sizing

SharePoint 2013 uses SQL server as its database engine to store the content database and the databases of the service applications. Assigning the proper compute resource to the database engine is important for a well-functioning SharePoint farm.

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

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

Refer to Table 42 and Table 43 to find detailed information for the vCPU and memory resources for SQL Server on the VSPEX Proven Infrastructure.

Table 42. SQL Server vCPU resource sizing for SharePoint Server 2013

Active user number Web server number 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 43. SQL Server memory resource sizing for SharePoint Server 2013

Active user number Memory resource

Less than 1000 8 GB

Equal or more than 1,000 16 GB

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



SharePoint contents that need to be stored can be classified by their usage:

Content databases: Stores site content and site settings, for example, site pages, documents, metadata, permission settings, etc.?

Service application databases and files: Stores data and settings of specific service applications.

Content database hosting My Sites: Stores the content of the user’s MySite.

Server’s OS volumes

These four kinds of content have different performance characteristics. According to their storage access characteristics, we divide the storage into 4 pools:

Content database pool (RAID 5)

SharePoint services pool (RAID 1/0)

MySites pool (RAID 6)

VSPEX private cloud pool that stores the OS volumes of the SharePoint servers

When sizing storage pools, take care of both performance-based and capacity-based calculations on the disk layout. Compare both results and choose the larger number of the two. This ensures both requirements are satisfied.

SharePoint Server 2013 content database pool sizing

This section describes how to size the content database pool. EMC recommends that you first calculate from the performance perspective, and then from the capacity perspective.

Performance perspective sizing for content database pool Figure 14 and Figure 15 show the results of EMC tests of the relationship between the active user number and host IOPS for the content database.

Storage layout sizing for SharePoint Server 2013



Figure 14. Test result of relationship of active user number and host IOPS for search intensive publishing portal

Figure 15. Test result of relationship of active user number and host IOPS for search intensive document management portal

As the active user number grows, the host IOPS on content databases grows in a linear way. Using the result here, we were able to calculate the host IOPS for any given number of active users, which we used to size the content database storage pool.



Use the following formula to calculate the host IOPS.

For the search intensive publishing portal:

Host IOPS = 0.2397 * Active user number

For the search intensive document management portal:

Host IOPS = 0.4173 * Active user number

Use the following formula to calculate the back-end IOPS from the host IOPS.

For the publishing portal, the read:write ratio is 3:1 with RAID 5.

Backend IOPS = Host IOPS * (3/4) + Host IOPS * (1/4) * 4 =

Host IOPS * (7 / 4)

For document management portal, the read:write ratio is 2:1 with RAID 5.

Backend IOPS = Host IOPS * (2/3) + Host IOPS * (1/3) * 4 =

Host IOPS * 2

Use the following formula to calculate the disk number:

Disk number = required backend IOPS / IOPS per disk

The IOPS per disk can vary for different types of disk. Refer to the EMC recommended IOPS for different types of disk.

Finally, we used RAID 5 (4+1). The final disk number should be rounded up by 5. Table 44 shows an example of the user input for sizing the content database pool.

Table 44. Example user input for sizing the content database pool



1


Farm 1



Initial farm size (GB)? 4,000



What is the main purpose of the SharePoint Web application? Publishing Portal



What is the quota for a single My Site (MB)? N/A

Do you heavily rely on the SharePoint search function? Yes




From this example, you can calculate as follows:

Active user number = 10000 * 50% = 5000

Host IOPS = 5000 * 0.2397 = 1198.5

Total I/O backend for RAID 5 = (1198*(3/4)) + 4* (1198*(1/4))

= 2097

Disk number = required backend IOPS / IOPS per disk

= 2096.5 / 180 = 11.65

Finally, round up the disk number by 5 for RAID 5. In here, 15 disks are needed from the IOPS perspective.

Capacity perspective sizing for content database pool The next step in sizing the content database pool is to consider the capacity.

Use the following formula to calculate the content database LUN size. Note we have given 30 percent of space as a buffer:

ContentDatabase LUN size = <Content Database size> * (1 + Annual

growth rate) ^ years * 1.3

Use the following formula to get the disk number:

Spindle requirement = <Total capacity> / <Usable capacity>

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

In the example shown in Table 44, the initial farm content size is 4,000 GB. The growth rate is 20 percent and the number of years for growth is 2.

Farm capacity = 4,000 * 1.2^2 * 1.3 = 7488 GB

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

SAS 600 GB requirement = 7488 / 536.81 = 13.9

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

This example requires 15 disks from an IOPS perspective and 15 disks from a capacity perspective. If either one is bigger than the other, choose the bigger 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 that you use RAID 1/0 (1+1) Flash disk and RAID 6 (6+2) NL-SAS for the content database storage pool.

In our validated VSPEX Proven Infrastructure for virtualized SharePoint 2013 solution, FAST VP saved 44 percent TCO.

SharePoint 2013 services pool sizing

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



Performance perspective sizing for services pool Table 45 and Table 46 detail the services pool sizing from a performance perspective in this VSPEX Proven Infrastructure. The search intensive SharePoint farm generates sequential IOPS for the services pool. Refer to Table 45 and Table 46 to find the appropriate disk numbers, based on your customer’s business requirements.

Table 45. Size the application server for non-intensive search farm

No. of web servers

No. of application servers

Description VNXe (SAS 15K) VNX (SAS 15K)

1 1 WFE and application in one box

RAID 1/0 (3+3)

6 disks

RAID 1/0 (1+1)

2 disks

2 1 All-in-one RAID 1/0 (3+3)

6 disks

RAID 1/0 (2+2)

4 disks

3 2 One query-type

One crawler-type

RAID 1/0 (3+3)

6 disks

RAID 1/0 (4+4)

8 disks

4 2 One query-type

One crawler-type

RAID 1/0 (3+3)

6 disks

RAID 1/0 (4+4)

8 disks

5 2 One query-type

One crawler-type

RAID 1/0 (3+3)

6 disks

RAID 1/0 (4+4)

8 disks

Table 46. Size the application server for intensive search farm

No. of WFEs No. of application server

Description VNXe (SAS 15K) VNX (SAS 15K)

1 1 All Service Roles in one box

RAID 1/0 (3+3)

6 disks

RAID 1/0 (3+3)

6 disks

2 2 One query-type

One crawler-type

RAID 1/0 (3+3)

6 disks

RAID 1/0 (4+4)

8 disks

3 4 Two query-type

Two crawler-type

RAID 1/0 (3+3)

12 disks

RAID 1/0 (4+4)

16 disks

4 4 Two query-type

Two crawler-type

RAID 1/0 (3+3)

12 disks

RAID 1/0 (4+4)

16 disks

5 4 Two query-type

Two crawler-type

RAID 1/0 (3+3)

12 disks

RAID 1/0 (4+4)

16 disks

Capacity perspective sizing for services pool 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:

SAS 600 GB requirement = 12,000 * 30% / 537 = 6.7

For the VNXe array, the services pool should be RAID 1/0 (3+3). We need to round up the number by 6. For the VNX array, the services pool should be RAID 1/0 (4+4). We



need to round up the number by 8. In this example, the array is VNXe, so the capacity requirement is 12 disks for the services pool.

If the table shows the services pool should have six disks from an IOPS perspective, choose the bigger number between the IOPS disk number and the capacity disk number. In this example, the result for the services pool is 12 disks.

MySite pool sizing

For the MySite pool, we used RAID 6 with the NL-SAS disk type. Since MySite is most used by less number of people, when sizing MySite pool, we only consider the capacity. Refer to Table 47 for the detailed RAID configuration of the MySite pool.

Table 47. RAID configuration for the MySite pool

VNXe VNX

RAID 6 (4+2) RAID 6 (6+2)

The formula for calculating the disk number for the MySite pool is:

Disk number = Number of users * Percentage of MySite usage *

Single User quota / <Disk usable capacity>

VSPEX private cloud pool sizing

The SharePoint Server 2013 farm is composed of different servers running Windows Server OS. When you have finished the sizing of server numbers, you can then size the pool storing the OS.

The following section describes how to size the VSPEX private cloud pool for storing these OSs.

One SharePoint Server 2013 server instance has one OS volume. The average single OS volume is 25 IOPS and the capacity is 100 GB.

Use the following formula to calculate the OS IOPS and capacity:

Total OS IOPS = Server number * 25

Total capacity for OS = Server number * 100

For more information, refer to the following virtualization infrastructure documents.







After you have completed the application sizing and obtained the numbers of reference virtual machines and suggested disk storage layouts, use the following steps to choose the right VSPEX Proven Infrastructure, based on the calculated results.

1. Use the manual sizing logic and methodology to get the total number of reference virtual machines and any additional suggested storage layouts for application.

For example, for a SharePoint Server 2013 farm containing one WFE, one application server, and one SQL server:

[SharePoint Server 2013 reference virtual machine] = Total

reference virtual machines required for SharePoint Server

2013 = 6 + 4 + 12 = 22 reference virtual machines

[Disks for SharePoint Server 2013 storage] = Total disk

numbers suggested for SharePoint Server 2013 = 5 + 6 = 11

disks

2. If customers want to deploy the other applications in the same VSPEX Proven Infrastructure, refer to the appropriate VSPEX design guide for applications and size the total number of reference virtual machines and storage layouts with the combined workload.

For example, customers would also like to deploy Exchange 2010 and Oracle 11g in the same VSPEX Proven Infrastructure. Based on the discussion with customers, refer to EMC VSPEX for virtualized Microsoft Exchange 2010–Design Guide to size Exchange 2010 manually and EMC VSPEX for virtualized Oracle 11g–Design Guide to size Oracle 11g in the VSPEX Proven Infrastructure. You get the following results:

[Exchange reference virtual machines] = Total reference

virtual machines required for Exchange 2010 = 12 reference

virtual machines

[Exchange disks]= Total disk numbers suggested for Exchange

2010 = 18 disks

[Oracle reference virtual machines] = Total reference

virtual machine required for [Oracle 11g]= 16 reference

virtual machines

[Oracle disks] = Total disk numbers suggested for Oracle

11g= 55 disks

3. Aggregate the total number of reference virtual machines and total disk numbers for all applications. For example:

Total reference virtual machines for applications =

SharePoint reference virtual machines + Exchange reference

virtual machines + Oracle reference virtual machines = 22

reference virtual machines + 12 reference virtual machines +

16 reference virtual machines = 50 reference virtual

machines

Total disks for applications = SharePoint disks + Exchange

disks + Oracle disks = 11 disks + 18 disks + 55 disks = 84

disks

4. Discuss with your customers the maximum utilization of the VSPEX Proven Infrastructure for application and virtualization solution they want to use to

Select the right VSPEX Proven Infrastructure



meet their business requirements. Calculate the total disks for the reference virtual machines suggested for the combined applications.

For example, since Oracle will be also deployed in the VSPEX Proven Infrastructure, EMC recommends that customers use VMware as the virtualization solution, enabled by VNX. If customers want a maximum 75 percent utilization for all the combined applications, the calculation would be:

Total reference virtual machines needed for applications =

Total reference virtual machines for applications / Maximum

utilization = 50 reference virtual machines / 75% = 67

reference virtual machines

Total disks needed for applications= Total disks for

applications / Maximum utilization = 84 disks/ 75% = 112

disks

5. Use Table 48 and the total number of reference virtual machines to select the minimum recommended VSPEX Proven Infrastructure.

In this example, because Oracle is also deployed in the same VSPEX Proven Infrastructure, EMC recommends that customers use VMware as the virtualization solution, enabled by VNX. In this example, EMC recommends that you select the VSPEX VMware private cloud solution for up to 125 reference virtual machines as the minimum VSPEX Proven Infrastructure for the combined workload.

Table 48. VSPEX storage model support matrix

VSPEX Proven Infrastructure models*

Maximum supported reference virtual machine

Supported storage array

Up to 50 virtual machines 50 VNXe3150

Up to 100 virtual machines 100 VNXe3300

Up to 125 virtual machines 125 VNX5300



*Includes the following VSPEX models:

VSPEX Private Cloud for Microsoft

VSPEX Private Cloud for VMware

6. Refer to the appropriate EMC VSPEX Proven Infrastructure and calculate the disk number required for the VSPEX private cloud pool by using the virtual infrastructure building block methodology.

In this example, EMC suggests you select a VSPEX VMware private cloud solution for up to 125 reference virtual machines as the minimum VSPEX Proven Infrastructure. After referring to the building block of VSPEX private cloud pool, you will get the total disk number required:

Total disks for private cloud = 5 SAS disks + 2 SSD disks =

7 disks



7. Aggregate the total disk number required including the disk number of combined applications, VSPEX private cloud pool, and the hot spare.

Total disks = Total disks needed for applications + Total

disks for private cloud + Hot Spare = 112 disks + 7 disks +

4 disks = 123 disks

8. Compare the values in Table 49 with Table 48 to make sure the VSPEX Proven Infrastructure supported array can support the total disk numbers that are required for the combined applications and private cloud. If not, you may need to upgrade to the next model of the VSPEX Proven Infrastructure.

In this example, EMC recommends the VSPEX VMware private cloud solution for up to 125 reference virtual machine as the VSPEX Proven Infrastructure, and VNX5300 as the storage array. VNX5300 can support a maximum of 125 disks in total, which can fit the requirement of 118 disks that you may need for the combined workload. As a result, EMC recommends that you consider the VSPEX VMware private cloud solution for up to 125 reference virtual machines for customers to deploy the proven infrastructure.

Table 49. Storage system support matrix

Storage system Maximum number of drives storage system

VNXe3150 100

VNXe3300 150

VNX5300 125

VNX5500 250

VNX5700 500

EMC VSPEX for virtualized SharePoint 2013 qualification worksheet

Question Answer







Number of users?












Number of users?






Question Answer







Number of users?








EMC VSPEX for Virtualized Microsoft SharePoint 2013€¦ · Contents EMC VSPEX for Virtualized...

Documents

Transcript of EMC VSPEX for Virtualized Microsoft SharePoint 2013€¦ · Contents EMC VSPEX for Virtualized...