emc solution for virtualized microsoft sql server on emc xtremio

Design Guide

EMC SOLUTION FOR VIRTUALIZED MICROSOFT SQL SERVER ON EMC XTREMIO

EMC Solutions Abstract This Design Guide describes how to design the resources necessary to deploy Microsoft SQL Server on any infrastructure that uses EMC XtremIO™ storage. The guide also illustrates how to size a virtualized system for SQL Server 2012 and SQL Server 2014 and allocate resources following best practices. October 2015

Copyright © 2014 - 2015 EMC Corporation. All rights reserved. Published in the USA. Published October 2015. 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 Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide Part Number H13949.1

2

EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide

Contents

Contents Chapter 1

Introduction

9

Purpose of this guide................................................................................................ 10 Business value ......................................................................................................... 10 Scope ....................................................................................................................... 11 Audience .................................................................................................................. 11 Terminology.............................................................................................................. 12

Chapter 2

Solution Overview

13

Overview .................................................................................................................. 14 Deployment workflow ............................................................................................... 14 Solution architecture ................................................................................................ 14 Key components ....................................................................................................... 15 Introduction ......................................................................................................... 15 Microsoft SQL Server 2014 and SQL Server 2012 ................................................. 15 EMC XtremIO........................................................................................................ 16 Virtualization management .................................................................................. 20 VMware vSphere 6.0 ............................................................................................ 21 EMC PowerPath/VE .............................................................................................. 21

Chapter 3

Solution Infrastructure Design

22

Overview .................................................................................................................. 23 Step 1: Evaluate the customer use case.................................................................... 23 Overview.............................................................................................................. 23 Virtualized SQL Server sizing input ...................................................................... 23 Step 2: Design the application architecture .............................................................. 25 Overview.............................................................................................................. 25 Sizing guide ......................................................................................................... 27 Step 3: Design the solution infrastructure................................................................. 29 Considerations .................................................................................................... 29 Examples ............................................................................................................. 30

Chapter 4

Solution Design Considerations and Best Practices

44

Overview .................................................................................................................. 45 Network design considerations ................................................................................ 45 Overview.............................................................................................................. 45


3

Contents

Network design best practices ............................................................................. 45 Storage layout and design considerations ................................................................ 46 Overview.............................................................................................................. 46 Storage design..................................................................................................... 47 Component design best practices ........................................................................ 48 Building block examples...................................................................................... 48 Virtualization design considerations ........................................................................ 49 Overview.............................................................................................................. 49 Virtualization design best practices ..................................................................... 49 Application design considerations ........................................................................... 51 Overview.............................................................................................................. 51 Application design best practices ........................................................................ 51 SQL Server licensing consideration ...................................................................... 52

Chapter 5

Solution Verification Methodologies

54

Overview .................................................................................................................. 55 Baseline hardware verification methodology ............................................................ 55 Application verification methodology ....................................................................... 55 Understanding key metrics .................................................................................. 56 Running tests, analyzing results, and optimization .............................................. 56

Chapter 6

Reference Documentation

58

EMC documentation ................................................................................................. 59 Other documentation ............................................................................................... 59 Links ........................................................................................................................ 59

Appendix A SQL Server Sizing Input

61

Virtualized Microsoft SQL Server worksheet .............................................................. 62

Appendix B High-level SQL Server Sizing Logic and Methodology

63

Overview .................................................................................................................. 64 Sufficient resources .................................................................................................. 66 Sizing considerations ............................................................................................... 66 Virtual machine recommendation for SQL Server ................................................. 67

Figures

4

Figure 1.

Solution architecture ........................................................................... 15

Figure 2.

XtremIO Virtual Copies......................................................................... 19

Figure 3.

Building block architecture for SQL Server ........................................... 25

Figure 4.

Multiple databases in single SQL Server instance ................................ 26

EMC Solutions for virtualized Microsoft SQL Server on EMC XtremIO Design Guide

Contents

Figure 5.

Storage layout and LUN design for single SQL Server database ........... 31

Figure 6.

Storage layout and LUN design for single SQL Server database with heavy workload ................................................................................... 33

Figure 7.

Storage layout and LUN design for multiple low workload SQL Server databases ........................................................................................... 35

Figure 8.

Storage layout and LUN design for high workload databases with mounted snapshots ............................................................................ 38

Figure 9.

Storage layout and LUN design for SQL Server OLAP database............. 40

Figure 10.

Storage layout and LUN design for Mixed SQL Server OLTP and OLAP databases ........................................................................................... 42

Figure 11.

SQL Server storage elements on VMware vSphere 6.0 platform ........... 47

Figure 12.

Building block example ....................................................................... 49


5

Contents

Tables

6

Table 1.

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

Table 2.

Infrastructure for virtualized SQL Server deployment process .............. 14

Table 3.

Proven Infrastructure selection steps ................................................... 23

Table 4.

Virtualized SQL Server sizing input guidelines ..................................... 23

Table 5.

Sample sizing guide calculation results ............................................... 27

Table 6.

Infrastructure design steps .................................................................. 29

Table 7.

Example sizing input for a low workload SQL Server OLTP instance...... 30

Table 8.

Example of required resources for a low workload SQL Server OLTP instance .............................................................................................. 31

Table 9.

Example sizing input for a high workload SQL Server OLTP instance .... 32

Table 10.

Example of required resources for a high workload SQL Server OLTP instance .............................................................................................. 32

Table 11.

Example sizing input for a low workload SQL Server OLTP instance with multiple user databases ...................................................................... 33

Table 12.

Example of required resources for a low workload SQL Server OLTP instance with multiple user databases ................................................ 34

Table 13.

Example sizing input for a high workload SQL Server with multiple user databases ........................................................................................... 36

Table 14.

Example of required resources for a high workload SQL Server OLTP instance with multiple user databases ................................................ 37

Table 15.

Example of user profiles: User database requirements ........................ 38

Table 16.

Example of sizing input for a SQL Server OLAP instance with a single user database ..................................................................................... 39

Table 17.

Example of required resources for a SQL Server OLAP instance with a single user database ........................................................................... 39

Table 18.

Example of user profiles: User database requirements ........................ 40

Table 19.

Example of sizing input for a SQL Server instances with mixed database workload ............................................................................................. 40

Table 20.

Example of required resources for a SQL Server OLAP instance with a Mixed OLAP and OLTP user database .................................................. 41

Table 21.

Storage layout example on XtremIO ..................................................... 48

Table 22.

Storage configuration example on XtremIO .......................................... 49

Table 23.

Recommended vCPU and memory for SQL Server ................................ 50

Table 24.

High-level steps for application verification ......................................... 55

Table 25.

Key metrics.......................................................................................... 56

Table 26.

Worksheet for a SQL Server user database .......................................... 62

Table 27.

Recommended vCPU and memory for database size ............................ 64

Table 28.

Recommended vCPU and memory for database performance .............. 65

Table 29.

Example of user input for multiple user databases .............................. 67

Table 30.

An example of user input for multiple user databases ......................... 67


Contents

Table 31.

Recommended configuration ............................................................... 69

Table 32.

Sample configuration for SQL Server ................................................... 70

Table 33.

XtremIO Storage for SQL Server ........................................................... 70


7

Contents

8


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


9


Purpose of this guide Optimized for virtualizing business-critical applications, this EMC solution provides partners with the ability to plan and design the assets required to support Microsoft SQL Server in a virtualized environment in the private cloud. The architecture of this solution for virtualized Microsoft SQL Server 2014 and SQL Server 2012 provides a validated system, capable of hosting a virtualized SQL Server solution at a consistent performance level. This solution is designed for a private cloud solution using a VMware vSphere virtualization layer and highly available EMC® XtremIO™ arrays for the storage. The compute and network components, while vendor-definable, are designed 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 the resources necessary to deploy Microsoft SQL Server on any infrastructure that uses XtremIO storage. This guide applies to SQL Server online transaction processing (OLTP) workloads and online analytical processing (OLAP) or data warehousing workloads.

Business value Never before has access to mission-critical data been more important to businesses competing in a rapidly changing global economy. Today, IT departments are challenged with an explosion of corporate data along with stagnant or shrinking budgets. As the foundation of the cloud-ready information platform, SQL Server provides high availability, reliable data storage, data-driven business intelligence, and a productive development experience to customers. It can be used to quickly build solutions and extend data across on-premises storage and public clouds, while providing users with mission-critical reliability. EMC offers customers even greater performance and choice with the inclusion of XtremIO storage into the system architecture. The XtremIO array is designed to offer an all-flash high-performance storage system for EMC customers who need to simplify and upgrade their storage system. The XtremIO array's architecture distributes all data services across all the system cores. Customers who want to virtualize Microsoft SQL Server on a private cloud will immediately see the benefits. XtremIO’s distributed data services allow cache management and back-end RAID management processes to scale linearly, and to greatly benefit from the latest Intel multicore CPUs. The XtremIO storage system accelerates I/O operations so that they can run faster and more efficiently than ever before. EMC solutions enable customers to accelerate their IT transformation with faster deployments, and simplified storage provisioning and management. Customers can achieve greater storage efficiency even with increased storage use. This openframework solution provides customers with several options when selecting a hypervisor, server, and network to build their SQL Server environments.

10



Scope This Design Guide describes how to design an infrastructure for virtualized Microsoft SQL Server 2014 and SQL Server 2012 environments running on a VMware vSphere platform. The guide provides examples of deployments on an XtremIO storage array. It also illustrates how to size SQL Server 2014 and SQL Server 2012 on the infrastructure using a provided sizing method, and how to allocate resources following best practices. The examples used in this guide describe a deployment on an XtremIO 20 TB dual XBrick cluster. The same principles and guidelines apply to any XtremIO arrays.

Audience This guide is intended for internal EMC personnel and qualified EMC Partners who intend to deploy this EMC solution for virtualized SQL Server. The guide assumes you are: 

Qualified by Microsoft to sell and implement SQL Server solutions



Certified in SQL Server, ideally with one or all of the following Microsoft certifications: 

Microsoft Certified Solutions Associate (MCSA)



Microsoft Certified Solutions Expert (MCSE)



Microsoft Certified Solutions Master (MCSM)



Qualified by EMC to sell, install, and configure the XtremIO storage systems



Qualified to sell, install, and configure the network and server products required for EMC solutions

The team which implement this solution need to have the necessary technical training and background to install and configure: 

EMC XtremIO



VMware vSphere virtualization platforms



Microsoft Windows Server 2012 R2



Microsoft SQL Server 2014 or Microsoft SQL Server 2012

This guide provides external references where applicable. EMC recommends that partners implementing this solution are familiar with these documents. Chapter 6: Reference Documentation for details.


11


Terminology Table 1 includes the terminology used in this guide. Table 1.

12

Terminology

Term

Definition

File group

SQL Server database objects and file groups

OLTP

Online transaction processing, typical applications of which include data entry and retrieval transaction processing

OLAP

Online analytical processing, typical applications of which include business reporting, business process management and data mining.

tempdb

A system database used by Microsoft SQL Server as a temporary working area during processing


Chapter 2: Solution Overview

Chapter 2

Solution Overview

This chapter presents the following topics: Overview ..................................................................................................................14 Deployment workflow .............................................................................................. 14 Solution architecture ............................................................................................... 14 Key components ......................................................................................................15


13


Overview This chapter provides an overview of the key technologies used in this EMC solution for virtualized Microsoft SQL Server. This solution has been designed and validated by EMC to provide the server, storage, and network resources for hardware consolidation of Microsoft SQL Server deployments using VMware virtualization technologies and EMC XtremIO all flash arrays. This solution was validated using Fibre Channel (FC) for XtremIO storage arrays. This solution requires the presence of Active Directory and DNS. The implementation of these services is beyond the scope of this guide, but the services are prerequisites for a successful deployment.

Deployment workflow EMC recommends that you refer to the process flow in Table 2 to design and implement your infrastructure for virtualized SQL Server. Table 2.

Infrastructure for virtualized SQL Server deployment process

Step

Action

1

Use the Virtualized SQL Server worksheet to collect user requirements in Appendix B of this Design Guide.

2

Use the sizing guidelines in Appendix B to determine the recommended components of the infrastructure for virtualized SQL Server based on the user requirements collected in step 1.

3

Use this Design Guide to determine your final design for the infrastructure to support virtualized SQL Server. Note: Ensure that you consider all application requirements, and not just this particular application.

4

Refer to the EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide to deploy and test your infrastructure for virtualized SQL Server.

Solution architecture Figure 1 shows the architecture that characterizes the validated infrastructure for SQL Server. SQL Servers are deployed as virtual machines on VMware vSphere 6.0. We1 used the sizing methodology in Appendix B for each SQL Server instance to determine the number of SQL Server virtual machines, the compute resources, and the recommended storage layout. The storage layout is in addition to the private cloud storage in the XtremIO.

1

14

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



Figure 1.

Solution architecture

Key components Introduction

Microsoft SQL Server 2014 and SQL Server 2012

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

Microsoft SQL Server 2014 and SQL Server 20122



EMC XtremIO



Virtualization management



VMware vSphere 6.0



EMC PowerPath/VE

SQL Server 2014 and SQL Server 2012 are Microsoft’s database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions. SQL Server is 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, etc., you should fully understand these factors and plan accordingly when deploying SQL Server. 2

In this guide, the design and implementation applies to both SQL Server 2014 and SQL Server 2012, unless specified otherwise.


15


The I/O pattern for SQL Server depends upon the user application that accesses the databases. The most common types of database workloads are discussed in this guide, including:

EMC XtremIO



On-line Transaction Processing (OLTP) – a transactional database consisting of more frequent and smaller I/O operations with random read/write access to data files



On-line Analytical Processing (OLAP) –a data-analytical type of workload consisting mostly of read-only, larger-sized I/O operations with more sequential disk access

The EMC XtremIO All-Flash Array is deployed in one of the two specialized configurations—Starter X-Brick or X-Brick—and is designed to maximize the use of flash storage media. Key attributes of the XtremIO platform are: 

Very high levels of I/O performance, particularly for random I/O workloads that are typical in virtualized environments



Consistently low (sub-millisecond) latency



True inline data reduction—the ability to remove redundant information in the data path and write only unique data on the storage array, thus lowering the amount of capacity required



A full suite of enterprise array capabilities, such as integration with VMware through vStorage APIs for Array Integration (VAAI), N-way active controllers (allows multiple active assignments), high availability, strong data protection, and thin provisioning

Furthermore, the XtremIO array is a scale-out design, in which additional performance and capacity are added in a building block approach, with all building blocks forming a single clustered system. XtremIO storage includes the following components: 

Host adapter ports—Provide host connectivity through fabric into the array.



Storage controllers (SCs)—The compute component of the storage array. SCs handle all aspects of data moving into, out of, and between arrays.



Disk drives—Solid state drives (SSDs) that contain the host/application data and their enclosures.



InfiniBand switches—A computer network communications link used in multi-XBrick configurations that is switched, high throughput, low latency, scalable, and quality-of-service and failover-capable.

Standards-based enterprise storage system The XtremIO system interfaces with vSphere hosts using standard FC and iSCSI block interfaces. The system supports complete high-availability features, including support for native VMware multipath I/O, protection against failed SSDs, nondisruptive software and firmware upgrades, no single point of failure (SPOF), and hotswappable components.

16



Real-time, inline data reduction The XtremIO storage system deduplicates desktop images in real time, allowing a massive number of virtual machines to reside in a smaller amount of flash capacity. Furthermore, data reduction on the XtremIO array enhances performance. XtremIO's unique inline data reduction is achieved by using inline data deduplication and inline data compression.

Inline data deduplication Inline data deduplication reduces redundancy before data is written to the flash media. XtremIO's inline data deduplication and its intelligent data storage process ensure: 

Balanced system resource usage and maximized system performance



Minimum amount of flash operations and maximized flash longevity



Equal data distribution and evenly balanced flash usage across the system



No system-level garbage collection and no post-processing data reduction



Efficient SSD capacity usage and minimized storage costs

Inline data compression Inline data compression compresses the deduplicated data before it is written to the flash media. XtremIO inline data compression provides the following benefits: 

Data is only written once inline and is never written as a post-processing activity.



A variety of data sets can be compressed (for example, database data, VDI, VSI environments, and so on).



Complements data deduplication. For example, in a SQL Server environment, deduplication reduces the physical storage capacity needed for database files wherever possible. Compression further reduces the specific user data. As a result, an increased amount of data can be managed by a single X-Brick.



XtremIO Compression reduces the physical storage footprint by storing data blocks in the most efficient manner.



Works seamlessly with SQL Server native compression.

Total data reduction XtremIO data deduplication and data compression complement each other. Data deduplication reduces physical data by eliminating redundant data blocks. Data compression further reduces the data footprint, by eliminating data redundancy within the binary level of each data block. XtremIO can support petabytes of functional application data in some environments. Scale-out design The X-Brick is the fundamental building block of a scaled out XtremIO clustered system. Using a Starter X-Brick, SQL Server deployments can start small and grow to nearly any scale required by upgrading the Starter X-Brick to an X-Brick, and then EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide

17


configuring a larger XtremIO cluster if required. The system expands capacity and performance linearly as building blocks are added, making non-disruptive online expansion of future growth extremely simple. Extended flash lifetime XtremIO data reduction extends the life of the flash memory. Writes are avoided by reducing data in flight, and extending flash endurance by leaving flash write cycles available for unique data. Extreme performance The XtremIO array is designed to handle very high and sustained levels of random, and mixed read and write I/O with consistently low latency. It is also capable of handling large block with high throughput. The active/active storage processors increase performance, resiliency, and efficiency. Ease of use The XtremIO storage system requires only a few basic setup steps that can be completed in minutes with no tuning or ongoing administration to achieve and maintain high performance levels. The XtremIO system can be deployment ready in less than an hour after delivery. Data center economics Up to 256 snapshots of each production LUNs are supported on XtremIO, resulting in a reduced storage footprint for production data for QA, data analysis, and development. Writeable Virtual Copies XtremIO elevates writeable Virtual copies as the key enabler of huge productivity gains by: 

Creating many writeable copies of production volumes with a small storage footprint



Consolidating test/dev, data warehousing, business intelligence copies, and application workloads



Managing the agile database lifecycle

XtremIO Virtual Copies are equivalent to production volumes in terms of performance and functions. These Virtual Copies are created with read/write access. Figure 2 shows how XtremIO writeable Virtual Copy works in an environment with a demand for large numbers of testing, development, and quality assurance (QA) copy.

18



Figure 2.

XtremIO Virtual Copies

XtremIO Virtual Copy technology provides users with an image that can be used as a test bed, and lowers the cost of creating and keeping a large number of copies. XtremIO Virtual Copies benefits include: 

Storage space and metadata usage efficiency



XtremIO Virtual Copies do not need the full metadata structure







Common metadata is shared between production and Virtual Copy instances



Storage space is only used for new unique data blocks and associated metadata



Deduplication and thin provisioning are always in use

Maximum performance, scalability, and economy 

Instant creation of a complete Virtual Copy



No impact on system performance



No overhead from “brute-force” copies



No metadata bloat



Minimal deletion penalty for data and metadata

Flexibility 

Take and keep large amount of Virtual Copies



Take Virtual Copies of Virtual Copies at any level



Create any Virtual Copy tree topology as needed



Remove Virtual Copies or their parent volume without affecting the other copies


19


XtremIO Operating System The XtremIO storage cluster is managed by the XtremIO Operating System (XIOS). XIOS ensures that the system remains balanced and always delivers the highest levels of performance without any administrator intervention by doing the following:

Virtualization management



Evenly loading all SSDs in the system and providing both the highest possible performance and endurance to support demanding workloads for the life of the array.



Eliminates the need to perform the complex configuration steps found on traditional arrays. There is no need to set RAID levels, determine drive group sizes, set stripe widths, set caching policies, build aggregates, or do any other such configuration.

Automatically and optimally configures every volume at all times. I/O performance on existing volumes and data sets automatically increases with large cluster sizes. Every volume is capable of receiving the full performance potential of the entire XtremIO system. EMC Virtual Storage Integrator EMC Virtual Storage Integrator (VSI) is a free plug-in for VMware vCenter that is available to all VMware users with EMC storage. Customers can use VSI to simplify management of virtualized storage. VMware administrators can view their XtremIO storage using the same familiar vCenter interface to which they are accustomed. With VSI, IT administrators can do more work in less time. VSI offers unmatched access control that enables you to efficiently manage and delegate storage tasks with confidence. With VSI, you can perform daily management tasks with up to 90 percent fewer clicks and up to 10 times higher productivity. VMware vSphere Storage API for Array Integration VMware vSphere Storage API for Array Integration (VAAI) offloads VMware storagerelated functions from the server to the storage system, enabling more efficient use of server and network resources for increased performance and consolidation. The XtremIO array is fully integrated with VAAI. All API commands are supported, including ATS, Clone Blocks/Full Copy/XCOPY, Zero Blocks/Write Same, Thin Provisioning, and Block Delete. This, in combination with the array’s inline data reduction and in-memory metadata management, enables nearly instantaneous virtual machine provisioning and cloning and makes it possible to use large volume sizes for management simplicity. VMware vSphere API for Storage Awareness VMware vSphere API for Storage Awareness (VASA) is a VMware-defined API that displays storage information through vCenter. Integration between VASA technology and XtremIO makes storage management in a virtualized environment a seamless experience.

20



EMC Storage Integrator EMC Storage Integrator (ESI) is targeted towards the Windows and application administrator. ESI is easy to use, delivers end-to end monitoring, and is hypervisor agnostic. Administrators can provision in both virtual and physical environments for a Windows platform, and troubleshoot by viewing the topology of an application from the underlying hypervisor to the storage. VMware vSphere 6.0

VMware vSphere 6.0 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 6.0 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 can access the appropriate resources at any point in time through load balancing of compute and storage resources. VMware Native Multipathing Plug-In (NMP) is the default module in vSphere used for multipathing. It provides a default path selection algorithm based on the array type. NMP associates a set of physical paths with a specific storage device or logical unit number (LUN). The specific details for handling path failover for a given storage array are delegated to a Storage Array Type Plug-In (SATP). The specific details for determining which physical path is used to issue an I/O request to a storage device are handled by a Path Selection Plug-In (PSP). SATPs and PSPs are sub plug-ins within the NMP module.

EMC PowerPath/VE 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 into 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.


21

Chapter 3: Solution Infrastructure Design

Chapter 3

Solution Infrastructure Design

This chapter presents the following topics: Overview ..................................................................................................................23 Step 1: Evaluate the customer use case ...................................................................23 Step 2: Design the application architecture .............................................................25 Step 3: Design the solution infrastructure ............................................................... 29

22



Overview This chapter describes how to design the infrastructure for virtualized SQL Server and how to choose the right solution to meet your requirements. Table 3 outlines the main steps you need to complete when designing an infrastructure. Table 3.

Proven Infrastructure selection steps

Step

Action

1

Evaluate the customer SQL Server workload by using the virtualized SQL Server sizing input, based on the business requirement. See Step 1: Evaluate the customer use case.

2

Determine the required infrastructure, SQL Server resources, and architecture using the sizing guidelines in Appendix B.

3

Design the solution infrastructure, based on examples that showcase proper XtremIO SQL Server database layout.

Step 1: Evaluate the customer use case Overview

Before deploying virtualized Microsoft SQL Server, gather and understand the infrastructure requirements, limitations, and estimated workload to design the SQL Server environment properly. To better understand the customer’s business requirements for the infrastructure design, EMC strongly recommends that you use the virtualized SQL Server sizing input to evaluate the workload requirements for the solution.

The virtualized SQL Server sizing input in Table 4 presents a list of simple questions Virtualized SQL Server sizing input to help identify customer requirements, usage characteristics, and dataset sizes. Table 4 provides a detailed explanation of the questionnaire and general guidance on how to determine the input values. Table 4.

Virtualized SQL Server sizing input guidelines

Question

Description

Do you have an existing SQL Server database that you would like to size for the environment?

 Choose Yes if the customer already has a SQL Server database and understands the characteristics that are going to migrate to a private cloud  Otherwise, choose No.

How many databases do you want to deploy?

Enter the number of databases that the customer expects to deploy.

The following questions are asked for each database What is the size of the user database (GB)?

The customer’s expected database size.


23

Chapter 3: Solution Infrastructure Design Question

Description

What is the size of user log file (GB) (optional)?

The customer’s expected database log size.

What is the annual growth rate (percent)?

Future growth is a key characteristic of the solution. This value is the expected annual growth rate of the user database. Enter a number that is appropriate for customer’s environment.

What are the IOPS (OLTP workload), or bandwidth (MB/s) (OLAP workloads)?

 The number of IOPS or bandwidth for SQL databases to prevent potential storage performance issues.  Enter an estimate for the IOPS at peak loads in the environment.

What is the required tempdb size (optional)?

Skip this question if the customer cannot estimate the space requirement or there is no significant activities anticipated with tempdb, this can be skipped. Tempdb size is important for the OLAP database.

Data reduction ratio

This includes deduplication and the compression ratio for the SQL Server production database. Use a ratio between 1.4:1 and 2:1. The default value is 1.5:1 for SQL Server databases.

The following questions are optional and related to snapshots.

24

How many virtual copies of the database exist?

Includes virtual copies on the same array as the production database.

What are the IOPS (OLTP workload) or bandwidth (MB/s) (OLAP workloads) needed for each snapshot (optional)?

The XtremIO data copies for SQL Server database can be treated as equivalent to the production database when the workload is considered.



Step 2: Design the application architecture Overview

In SQL Server XtremIO implementation, we suggest using a building block approach, based on the general solution architecture, as described in Figure 3:

Figure 3.

Building block architecture for SQL Server

Each SQL Server virtual machine can be built from two different kinds of building blocks: 1.

OS/ SQL server base building block (on the private cloud infrastructure): Each virtual machine with one SQL Server instance needs one base building block. The base block provides the foundation for the OS and the database’s computational and storage needs. By default, start build SQL server with the OS/Server block:

2.



CPU: 2 vCPU



Memory: 4 GB RAM



Storage: 100 GB virtual disk storage in the OS storage datastore

User database building block: The user database building block has CPU, memory, and storage capable of supporting the user database's data file and log file. These can be determined with the sizing guide if you do not know the specific needs. Tempdb needs can be determined in a per-database level or instance level, EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide

25


depending on how much information the user already has for the workload on each database. Each virtual machine can have one base block and one database block. Figure 3 shows a virtual machine with one small user database block and a typical OS/SQL Server base block from the infrastructure cloud. Figure 4 shows that multiple user databases can be put into one SQL Server instance. You can put multiple user databases on a single SQL Server instance virtual machine. Calculate the computational needs for the vCPU and memory based on the total database size and workload. Use IOPS for OLTP and use bandwidth (MB/s) for the OLAP workload. The tempdb needs can be aggregated if each database has its unique requirements, or the needs can be estimated at an instance level. Each SQL Server instance has only one tempdb, and the tempdb needs to have sufficient space, I/O and CPU resources to accommodate needs for all the databases in that instance. Note: The tempdb usually is not very big and not heavily used for the OLTP workload. The tempdb size and workload is significant for the OLAP workload and needs to be taken into consideration when designing the overall environment.

Figure 4.

Multiple databases in single SQL Server instance

It is simple to configure XtremIO storage to create suitably sized LUNs for the SQL Server database and server capacity needs.

26



XtremIO Virtual Copies require minimum storage footprint, and can be accessed in the same way as the production databases. The same building block approach can be used to build the instance for mounted XtremIO Virtual Copies with workloads. Database design principles and guidelines

Sizing guide

1.

Use the sizing guidelines in Appendix B for basic sizing.

2.

Use 20 TB XtremIO X-Bricks for the SQL Server database infrastructure. Other X-Brick sizes are available using the sizing guidelines in Appendix B.

3.

Create LUNs with future growth space in mind and not just the current size. XtremIO LUNs are thin-provisioned; larger LUNs only use the physical space for the actual data.

4.

With XtremIO built-in inline data reduction (deduplication and compression), the physical storage needs on XtremIO for the production SQL Server database is typically 50-70percent of the physical data (with a compression ratio of 1.4:1 to 2:1).

5.

Create up to 256 virtual copies of each LUN with a minimum storage footprint to enable database repurposing for analysis, development, QA, and so on.

6.

Consider the OS, tempdb, and user database needs for storage and server resources.

In this solution we defined a representative customer reference workload to be sized. The sizing guidelines in Appendix B give configuration recommendations after you collect the customer’s answers as sizing input. For more information, refer to the sizing guidelines in Appendix B After you complete the inputs to the sizing guide, the tool generates a series of recommendations, as listed in Table 5. Table 5.

Sample sizing guide calculation results

Type

Description

Reference

vCPU

Number of vCPUs to configure for each SQL Server virtual machine

NA

Memory

Amount of memory recommended for each SQL Server virtual machine

NA

Storage needs for SQL Server databases

Suggested XtremIO X-Brick size and numbers of X-Bricks

Storage layout and design considerations

Virtual machine best practices for SQL Server The sizing guidelines in Appendix B provide detailed best practice recommendations for sizing the virtual machine based on the following basic resource types for each SQL Server machine: 

vCPU resources



Memory resources


27


This section describes the resource types, how they are used in the sizing guide, and key considerations and best practices for a customer environment. 

vCPU resources best practices The sizing guide calculates the number of vCPUs for the virtual machines running SQL Server instances in the virtual infrastructure. The CPU type must meet or exceed the defined CPU or processor models. We validated this virtualized SQL Server solution with a statically assigned processor and no virtual-to-physical CPU oversubscription. EMC recommends the following in SQL Server deployments: 

Enable hardware-assisted virtualization for CPU and hardware-assisted virtualization for Memory Management Unit (MMU) at the BIOS level if the processors support those functions.



Maintain a 1:1 ratio of physical cores to vCPUs for business-critical or tier-1 workloads. Extend the Non-Uniform Memory Access (NUMA) architecture to the guest OS while keeping the NUMA node size in mind when sizing virtual machines, because the SQL Server automatically detects NUMA architecture.

The number of vCPUs allocated to the SQL Server virtual machines should not be larger than the number of physical NUMA node, so that all memory access will be local to that NUMA node. This provides the lowest memory access latencies. 

Memory resources best practices The sizing guidelines in Appendix B calculate the recommended amount of memory for each of the virtual machines running SQL Server instances. We validated this virtualized SQL Server 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 value that was tested in the solution. For most production SQL Server deployments, EMC recommends that you allocate at least 8 GB of memory to the SQL Server virtual machine and reserve at least 2 GB for the OS. To avoid accessing remote memory in a NUMA-aware environment, EMC recommends that you size a SQL Server virtual machine's memory with less than the amount available per NUMA node. For information about the SQL Server memory recommendations in this infrastructure, refer to Virtualization design considerations.



OS capacity resources best practices The sizing guidelines in Appendix B show the recommended storage capacity for the virtual machines running SQL Server instances. This is separate from the storage capacity required for the database data and log files. EMC recommends that you put the OS volume into the private cloud datastore.

28



For small- and medium-sized SQL Server deployments, EMC recommends that you allocate 100 GB of disk space for the OS. Larger sized SQL Server can allocate more as needed. 

OS IOPS best practices The sizing guidelines in Appendix B will also give the recommended number of IOPS for the virtual machines running SQL Server instances. We assume that the read/write ratio is approximately 90:10 in the examples of this guide for a typical OLTP load, and 100 percent reads for typical OLAP workloads. For more information, see the examples under Step 3: Design the solution infrastructure.

Additional considerations The sizing guidelines in Appendix B also allow you to consider the future data growth for up to seven years, which should be planned for so that the environment can continue to deliver an effective business solution to maintain performance targets and accommodate growth. XtremIO is very flexible so that it can add more storage into the environment without interruption as needs grows. The need to plan for longterm data requirements is less strict in this platform.

Step 3: Design the solution infrastructure Considerations

This solution is designed to simplify the deployment of a consolidated virtual infrastructure using vSphere, XtremIO, and EMC data protection. After confirming the application architecture using the sizing guidelines in Appendix B, you can design a solution infrastructure based on the calculated results. Note: While this Design Guide is intended for SQL Server requirements, SQL Server may not be the only application deployed on the Infrastructure. You must carefully consider the requirements for each application that you plan to deploy. If you are uncertain about the best infrastructure to deploy, consult EMC before making the decision.

Follow the steps shown in Table 6 when designing a solution infrastructure. Table 6.

Infrastructure design steps

Step

Action

1

Use the Sizing guide to calculate the resource requirements, including CPU, memory, and storage for virtual machines and for the SQL Server user database needs.

2

Use the Sizing guide to design the resource requirements for additional applications, based on business needs. Calculates the total number of required resources, including CPU, memory, and storage for virtual machines and both SQL Server and other applications.

3

Discuss with your customers the maximum workload on Infrastructure that meets their business requirements—this is the maximum workload on both SQL Server and other applications. Use that workload demand as input into the Sizing guide. The tool provides a recommendation for the Infrastructure.


29


Examples

Step

Action

4

Select your hardware and software vendor for the recommended Proven Infrastructure offering.

This section describes five scenarios and how to size the infrastructure for each one with the XtremIO 20 TB X-Bricks: 

A low workload SQL Server OLTP instance with a single user database



A high workload SQL Server OLTP instance with a single user database



A low workload medium-sized SQL Server OLTP instance with multiple databases



Two high workload SQL Server OLTP instances with multiple user databases which have snapshots mounted on separate SQL instances



A medium-sized SQL Server OLAP instance



A medium workload SQL Server OLTP instance with single user database with another SQL Server OLAP instance with single user database

Example 1: Low workload SQL Server OLTP instance with a single user database In this scenario, a customer would like to create a small-sized SQL Server OLTP instance on the infrastructure. The customer has a 250 GB user database, and 1,000 IOPS are expected. The completed sizing input for this production SQL Server database is shown in Table 7. Table 7.

Example sizing input for a low workload SQL Server OLTP instance

Question

Answer


Yes


1

What is the size of user database (GB)?

250

What is the size of user log file (GB)? (optional)

100


30

What is the maximum number of IOPS?

1,000

What is the required tempdb size (GB) (optional question)?

150


1.5:1

Use the answers from the sizing input in Appendix A as input to the sizing guide. The recommendations for the required resources are shown in Table 8. You can always allocate more than the minimum recommended resources for the environment.

30


Chapter 3: Solution Infrastructure Design Table 8.

Example of required resources for a low workload SQL Server OLTP instance

SQL Server

vCPUs

Memory

Minimum XtremIO X-Bricks

Database resource requirement

4

12 GB

1

OS resource requirement

2

4 GB

Total

6

16 GB

In this example, with very a low workload, all database files can be stored on the same datastore. It is possible to put a log file in the same LUN as a database file. Performance will be similar regardless of the placement of log files. The log file is placed in a separate LUN in this example to accommodate replication and backup/restoration needs. You should create a datastore that is larger than the physical need for all components to accommodate future data growth. XtremIO uses thin provisioning to ensure efficient storage usage. All the additional space that is not currently used is not allocated any physical storage, so there is no wasted space even if we created LUNs and data files much larger than actually needed.

Figure 5.

Storage layout and LUN design for single SQL Server database

With the compression ratio expected to be 1.5:1, the actual physical storage used for database data files is about 167 GB for the 250 GB database, as shown in Figure 5. The virtual machine’s OS and SQL Server installation files and system databases are all on the datastore for the private cloud. The Tempdb database file and its log files are on the same LUN. EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide

31


Example 2: High workload SQL Server OLTP instance with a single user database In this scenario, a customer would like to create a high workload SQL Server OLTP instance on an infrastructure. The customer has a 1 TB user database, and 50,000 IOPS are expected. Complete the sizing input for the production SQL Server database, as shown in Table 9. Table 9.

Example sizing input for a high workload SQL Server OLTP instance

Question

Answer


Yes


1


1 TB

What is the size of user log file (GB)? (optional)

250


30


50,000

What is the required tempdb size (optional question)?

300


1.5:1

The recommendation for the resources from the private cloud storage is shown in Table 10. Table 10.

Example of required resources for a high workload SQL Server OLTP instance

SQL Server

vCPUs

Memory


Database resource requirement

26

400 GB

1


2

4 GB

Total

28

404 GB

In this example, with a very high workload, files for the database are placed on the four different LUNs to ensure the maximum IOPS can be achieved. As a general best practice, create four LUNs on XtremIO for the same database. That is sufficient to support a database with more than 160,000 IOPS in an OLTP environment. Each database LUN and log LUN in this design is created as separate 1 TB LUN, they can all be created as a group in XtremIO and configured in the same way. At an expected 1.5:1 compression ratio, the actual physical storage used for the database datafile is less than 700 GB for the 1 TB database, as shown in Figure 6. The virtual machine’s OS and SQL Server installation files and system databases are all on the datastore for the private cloud. Tempdb and its log files are on the same LUN.

32



Figure 6.

Storage layout and LUN design for single SQL Server database with heavy workload

Example 3: Low workload SQL Server OLTP instance with multiple user databases In this scenario, a customer would like to create a small-sized SQL Server OLTP instance on an infrastructure. The customer has one 50 GB, one 100 GB, and one 250 GB database. A total of 2,800 IOPS are expected. The customer also plans to back up and restore these databases together and use VMDK for the virtual disks. Complete the sizing input for the production SQL Server database, as shown in Table 11. Table 11.

Example sizing input for a low workload SQL Server OLTP instance with multiple user databases

Question

Answer


Yes


1


50, 100, 250 GB


50


10


500, 300, 2,000


33

Chapter 3: Solution Infrastructure Design Question

Answer


N/A


1.5:1

Table 12 shows the system resources required to support this environment: Table 12.

Example of required resources for a low workload SQL Server OLTP instance with multiple user databases

SQL Server

vCPUs

Memory


Resource requirement

4

12 GB

1

OS Resource requirement

2

4 GB

Total

6

16 GB

In this example of a very low user workload, all three user databases need to be backed up and restored together. The database data LUNs for the different databases are put on the same datastore that was created as single LUN in XtremIO. All database log LUNs are put on the same datastore that was created as a single LUN in XtremIO as well. Each database LUN and log LUN in this design is created as a 1 TB LUN, so they can all be created as a group in XtremIO and configured in the same way. With a compression ratio expected to be 1.5:1, the actual physical storage used for the database datafile and log files vary, as shown in Figure 7. The three databases' tempdb needs are satisfied by a single tempdb because the three user databases share the same tempdb in the same SQL Server instance. The virtual machine’s OS and SQL Server installation files and system databases are all on the private cloud datastore.

34



Figure 7.

Storage layout and LUN design for multiple low workload SQL Server databases

Example 4: High workload SQL Server OLTP instance with multiple user databases and snapshots mounted on separate SQL Server instances In this scenario, a customer would like to create two medium-sized SQL Server OLTP instances on an infrastructure. The customer has a 500 GB and 750 GB database on one instance, and a 250 GB and a 1 TB database on the second instance. The snapshots of the 500 GB database and 1 TB database are mounted on a separate mount host for data analysis and a QA workload. The expected IOPS measurement is detailed in Table 13. After talking to the customer, complete the sizing input for the production SQL Server database, as shown in Table 13.


35


Example sizing input for a high workload SQL Server with multiple user databases

Question

Answer


Yes

Instance1

Instance2


2

2


500 GB (DB1)

250 GB (DB2)

750 GB (DB3)

1 TB (DB4)


10

10

10

10


1.5:1

1.5:1

1.5:1

1.5:1


35,000

25,000

50,000

75,000


NA

Snapshot needed?

Y

NA N

N

Y

Number of Snapshot

10

10

Total Max IOPS for snapshots?

20,000

84,000

Putting the answers from the sizing input into the sizing guide generates a series of recommendations for the resources needed from the private cloud pool. The recommendations for the XtremIO storage are shown in Table 14.

36



Example of required resources for a high workload SQL Server OLTP instance with multiple user databases

SQL Server Resource requirement

vCPUs

Memory

Instance 1

Database

30

480 GB

OS

2

4 GB

Total

32

484 GB

Database

63

1,000 GB

OS

2

4 GB

Total

65

1,004 GB

Instance 3

Database

52

832 GB

Mount host of snapshot for databases 1 and 4

OS

2

4 GB

Total

54

836 GB

151

2,324 GB

Instance 2

Total

Minimum XtremIO XBricks

2

In this example, with very high workload, database files for the database are placed on the four different LUNs to ensure the maximum IOPS can be achieved. As a general best practice, create four LUNs on XtremIO for any database with more than 16,000 IOPS with an OLTP workload. Most storage and LUN configuration should follow the principles of a single instance configuration as a building block. If multiple databases need to be on the same instance, the additional user database building blocks can be easily fit into the same virtual machine by adding them to the base building block as shown in Figure 6. Additional databases on the same instance and different instances have a similar layout. This example also has multiple snapshots for some of the databases. Some of the databases are mounted on the mount host to support various workloads. In general, XtremIO Virtual Copies will take minimal physical storage to create (about 1 percent in this example). You can create up to 63 snapshots per LUN for XtremIO database LUNs as shown in Figure 7. The workload (either read/write) on the snapshot is treated the same as any other workload and contributes to the total system workload on XtremIO. The mounthost OS is on a separate XtremIO Private Cloud pool datastore. The tempdb and logs for the mount SQL Server instance is also on a separate LUN.


37


Figure 8.

Storage layout and LUN design for high workload databases with mounted snapshots

Example 5: Medium-sized SQL Server OLAP instance with single database In this scenario, a customer would like to create a user database on a SQL Server OLAP instance. Table 15 lists the database size and expected bandwidth. Table 15.

Example of user profiles: User database requirements

Database profile OLAP

DB size (TB) 1

bandwidth(MB/s) 1,024

Complete the sizing input for each production SQL Server database, as shown in Table 16.

38



Example of sizing input for a SQL Server OLAP instance with a single user database

Question

Answer


Yes


1


1,024


250


30

What is the maximum bandwidth (MB/s)?

1,024

What is the required tempdb size (GB) (optional)?

500


1.5:1

Use the answers from the sizing input to calculate a series of recommendations for the resources needed from the resource pool including the XtremIO storage. The recommendations are shown in Table 17. Table 17.

Example of required resources for a SQL Server OLAP instance with a single user database

SQL Server

vCPUs

Memory


Resource requirement

18

128 GB

1


2

4 GB

Total

20

132

In this example, with very high workload, database files for the database are placed on the eight different LUNs to ensure the maximum IOPS can be achieved. As a general best practice, it is also recommended to create eight LUNs on XtremIO for the same database to support maximum bandwidth on an OLAP environment. An OLAP workload places a very high demand on tempdb. To support complex and long-running aggregated queries in this example, tempdb uses eight LUNs to ensure it does not become a bottleneck. The tempdb log file is also placed on a separate LUN in this use case. Because tempdb size can vary depending on the environment, we can use XtremIO’s thin provisioning feature to allocate larger sizes for tempdb. With the compression ratio as expected at 1.5:1, the actual physical storage for the database datafile is about 683 GB for the 1 TB database, as shown in Figure 9.


39


Figure 9.

Storage layout and LUN design for SQL Server OLAP database

Example 6: A medium workload SQL Server OLTP instance with single user database and another SQL Server OLAP instance with single user database In this scenario, a customer would like to have a mixed OLTP and OLAP environment: one user database with OLTP instance, and another user database with a SQL Server OLAP instance. Table 18 lists the database size and expected bandwidth. Table 18.

Example of user profiles: User database requirements

Database profile

DB size (TB)

OLTP

1

OLAP

1

IOPS

bandwidth(MB/s)

10,000 1,024

Complete the sizing input for each production SQL Server database, as shown in Table 19. Table 19.

40

Example of sizing input for a SQL Server instances with mixed database workload Question

Answer


Yes



OLTP data base

OLAP data base

Question

Answer


1


1,024


250


30

What is the maximum IOPS?

10,000


500


1.5:1


Yes


1


1,024


250


30

What is the maximum bandwidth (MB/s)?

1,024


500


1.5:1

Use the answers from the sizing input and the sizing guidelines in Appendix B to calculate a series of recommendations for the resources needed from the resource pool including the XtremIO storage. The recommendations are shown in Table 20. Table 20.

Example of required resources for a SQL Server OLAP instance with a Mixed OLAP and OLTP user database

SQL Server

vCPUs

Memory


Resource requirement for OLTP database instance

8

80 GB

1

OS resource requirement for OLTP database

2

4 GB

Resource requirement for OLAP database instance

16

128 GB

OS resource requirement for OLAP database

2

4 GB

Total

28

216 GB

In this example, with a mixed workload, the OLTP database follows the OLTP database design principles, and the OLAP database follows the design principles of EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Design Guide

41


OLAP, to ensure that the maximum IOPS can be achieved. As a general best practice, create eight LUNs on XtremIO for the same database to support a database with more than 1 GB/s for an OLAP environment. For easy configuration, the OLTP database with about 10,000 IOPS requirement has its four database LUNs created on one XtremIO LUN and mounted as a single datastore. An OLAP workload places a very high demand on tempdb. To support complex and long running aggregated queries in this example, tempdb uses eight LUNs to ensure it does not become a bottleneck. The tempdb log file is also placed on a separate LUN in this use case. Eight tempdb database LUNs are sufficient for a typical heavy workload. For more demanding workloads, more LUNs can be used for tempdb. Because tempdb size can vary depending on the environment, we can use XtremIO’s thin provisioning feature to allocate larger sizes for tempdb. With the compression ratio as expected at 1.5:1, the actual physical storage used for the database datafile is about 683 GB for the 1 TB database, as shown in Figure 10.

Figure 10. Storage layout and LUN design for Mixed SQL Server OLTP and OLAP databases

42




43

Chapter 4: Solution Design Considerations and Best Practices

Chapter 4

Solution Design Considerations and Best Practices

This chapter presents the following topics: Overview ..................................................................................................................45 Network design considerations ................................................................................45 Storage layout and design considerations ............................................................... 46 Virtualization design considerations........................................................................49 Application design considerations ...........................................................................51

44



Overview This chapter provides best practices and considerations of the infrastructure for the virtualized SQL Server solution. We considered the following aspects during the solution design: 

Network design



Storage layout design



Virtualization design



Application design

For information on design considerations and best practices for EMC data protection solutions for your SQL Server environment, refer to EMC Backup and Recovery

Options for VSPEX for Virtualized Microsoft SQL Server 2014 Design and Implementation Guide.

Network design considerations Overview

Virtual networking follows the same concepts as physical networking, but some of these concepts are applied in the software instead of through physical cables and switches. Although many best practices that apply to physical networking apply to virtual networking, additional considerations apply for traffic segmentation, availability, and throughput. The advanced networking features of XtremIO provide protection against network connection failures at the array. Meanwhile, each hypervisor host has multiple connections to user and storage Ethernet networks to guard against link failures. These connections should be spread across multiple Ethernet switches to guard against component failure in the network. The network connection for the boot volume of the virtualized SQL Server is FC on XtremIO. For more information, refer to the documents listed in Chapter 6.

Network design best practices

EMC recommends that you consider the following aspects for network design: 

Separate different network traffic Separate the virtual machine, storage, management, vSphere vMotion network traffic, and heartbeat using VLAN segmentation.


45




Set up network redundancy Redundant topologies can 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. Design networks to recover rapidly and bypass the fault. In this solution, we have two network switches, and all three networks have their own redundant links.



Use NIC teaming Aggregate multiple parallel network connections to increase the 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. For the NIC teaming settings, as a best practice, select No for the NIC teaming failback option. This setting prevents NIC card flip-flopping in case of some intermittent network behavior. When setting up VMware high availability (VMware HA), set the following ESX Server timeouts and settings under the ESX Server Advanced Settings tab: 

NFS.HeartbeatFrequency = 12



NFS.HeartbeatTimeout = 5



NFS.HeartbeatMaxFailures = 10

For more NIC teaming best practices for VMware vSphere, refer to Best Practices for running VMware vSphere on Network Attached Storage.

Storage layout and design considerations Overview

The best practices and design considerations in this section provide guidelines for effectively planning storage for various business requirements in SQL Server environments. Figure 11 shows the high-level architecture of the SQL Server components and storage elements validated in the infrastructure for virtualized SQL Server on a vSphere virtualization platform. All the SQL Server volumes are stored in Virtual Machine Disk (VMDK) or Raw Device Map (RDM) format in a VMware virtualized environment. Note: RDM is required format for SQL Server Failover Cluster Instances (FCI) configuration. Standalone SQL Server can use either RDM or VMDK format. Performance is very similar for RDM and VMDK on XtremIO storage.

46



Figure 11. SQL Server storage elements on VMware vSphere 6.0 platform

Storage design

EMC recommends implementing the following storage design best practices. Application storage design Consider the following best practices for application storage layout and design. 





SQL Server user database data LUNs: 

Use separate LUNs for restoring granularity if needed.



Use four data LUNs to support heavy workloads( greater than 20,000 IOPS).

SQL Server log 

Use separate LUN for restoring granularity if needed.



With low workloads and HA/DR, backup and restore operations do not require the logs to be on a separate datastore. Logs can be put on the same datastore as the data file LUNs.

Tempdb LUNs: 

Use separate LUNs other than those used for the production database for restoring granularity.



For higher workloads use four to eight tempdb LUNs.

For more information about best practices for the tempdb database, see Application design considerations and Application design best practices.


47


LUN format unit The NTFS allocation unit size is determined when the partition is formatted by the OS or user. For the best performance, use 64 KB of the file allocation unit size (cluster size) for the SQL Server volumes. Component design Usage patterns and workloads on SQL Server can vary. In general, the XtremIO storage platform supports most highly demanding workloads and will meet or exceed best practices customer-driven response-time SLAs and continue to provide the best user experience. Building block examples

This section provides an example of the building block construction in the infrastructure for virtualized SQL Server—one for a high workload and one for a light workload on a private cloud. Both of these examples follow the best practices and design considerations previously discussed. Table 21 shows an example of a storage layout dedicated for SQL Server database with very high workload. The configuration can support hosts running OLTP workloads with up to 10,000 IOPS. Note: This is only an example for both the infrastructure and the SQL Server database storage usage. The actual storage capacity and throughput used in the example for the virtual infrastructure can be variable. Table 21.

Storage layout example on XtremIO

Building block for low demanding workload

Number of LUNs

Size of LUN

Datafile size

SQL Server user database data LUNs

1

1 TB

Less than 1 TB

SQL Server database log LUN

1

1 TB

Less than 1 TB

SQL Server Tempdb LUN

1

1 TB

Less than 1 TB

Figure 12 shows an example of building block construction for a SQL Server instance with small database with low workload on XtremIO:

48



The base building block consists of the OS with 100 GB LUN on the 2 TB private cloud datastore LUN with 2 vCPUs and 4 GB of RAM.



The database building block consists of one database LUN, one log LUN, and one combined tempdb/log LUN. According to the sizing calculation, for a small database use 2 vCPUs and 4 GB of RAM in addition to the resources required by the base configuration.



Figure 12.

Building block example

Table 22 shows an example of storage configuration for SQL Server on XtremIO in addition to the private cloud pool. Table 22.

Storage configuration example on XtremIO

Storage pool name

number of LUN

Size of the LUN

Physical capacity used (each LUN)

SQL user database data LUNs

1

1 TB

67 GB

SQL user database log LUN

1

1 TB

15 GB

SQL Server tempdb/log LUN

1

1 TB

100 GB

Virtualization design considerations Overview

SQL Server 2012 and SQL Server 2014 are supported when deployed in a virtual environment that is supported by VMware vSphere. The following sections describe the best practices and design considerations for SQL Server virtualization.

Virtualization design best practices

Table 23 lists the recommended RAM for computers running SQL Server, based on the combined size of SQL Server user databases.


49

Chapter 4: Solution Design Considerations and Best Practices Table 23.

Recommended vCPU and memory for SQL Server

Combined size of SQL Server user databases

Recommended vCPU in addition to base configuration of 2 vCPUs

Recommended memory (GB) in addition to base configuration of 4 GB

Up to 100 GB (including 100 GB)

2

4 GB

100 GB to 250 GB (including 250 GB)

4

12 GB

250 GB to 500 GB (including 500 GB)

6

28 GB

500 GB to 1 TB (including 1 TB)

8

60 GB

Greater than 1 TB

Contact EMC for validation

Each SQL Server has its own datastores and virtual disks for its operating system. In VMware virtualized environments, the SQL Server OS/boot LUNs use a VMDK on their own datastore. All database LUNs use VMDK or RDM in VMware. Because SQL Server 2012 and SQL Server 2014 can automatically detect NUMA, and the SQL Server processor and memory allocation can be optimized for NUMA, this solution implemented the following best design practices: 

Keep the number of physical cores and vCPUs in a 1:1 ratio. Ensure that there are no overcommitted CPUs for running business-critical SQL Server instances.



Consider the NUMA node size when sizing virtual machines. To avoid accessing remote memory in a NUMA-aware environment, size a SQL virtual machine's memory so that it is less than the amount available per NUMA node.



Fully reserve the RAM for the SQL Server virtual machines.



In VMware, enable the VMware HA, DRS, and vMotion functions. The VMware DRS function can automatically balance the workload between the hosts by using the vMotion function. When SQL Server workloads increase, DRS automatically moves a bottlenecked virtual machine to another host with more available resources, without causing any 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 vMotion. 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 details, refer to the documents listed in the EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide. Monitor the performance of the entire infrastructure regularly. Monitoring performance not only happens at the virtual machine level, but also at the hypervisor level. For example, you can use performance monitoring inside the

50



SQL Server virtual machine to ensure that the virtual machine or SQL Server are performing well. Meanwhile, at the ESXi level, you can use the esxtop command to monitor host performance. For detailed information on the performance monitoring tool, refer to the documents listed in the EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide.

Application design considerations Overview

Design considerations for SQL Server 2012 and SQL Server 2014 involve many aspects. The best practices and design considerations in this section provide guidelines for the most common and important ones.

Application design EMC recommends that you consider the following best practices for the SQL Server 2012 and SQL Server 2014 design. best practices SQL Server instance settings 

The Lock Pages in Memory privilege is granted to the SQL Server startup account. This privilege is designed to prevent the process working set (committed memory) from being paged out or trimmed by the operating system. For more information, refer to the Microsoft Support article How to enable the "locked pages" feature in SQL Server 2014. Note: After enabling the Lock Pages in Memory privilege, set the maximum server memory of the SQL Server instance to prevent the instance from reserving all memory from OS.

 

Add E to the startup options. This privilege increases the number of contiguous extents in each file that are allocated to a database table as it grows, and improves sequential disk access. Add T1117 to the start-up options. This trace flag ensures even growth of all files in a file group when auto-grow is enabled.

SQL Server database settings Consider the following best practices for user database settings: 

Use multiple datafiles for large databases.



Use the full recovery model to enable administrators to back up the transaction logs incrementally after full backup. This model enables recovery of the SQL Server database to a specific point in time from the log backup, even if the datafiles of the content databases are corrupt. EMC recommends that you create log backups regularly for the full recovery model.



Allocate enough RAM to SQL Server and OS.

EMC recommends that you use the following settings for tempdb: 

Pre-allocate data file and LUN space, because with thin provisioning and compression and deduplication, XtremIO storage usage is very efficient.


51


Storage will only be consumed when actually needed. Allocating larger space for a LUN will not result in any wasted space. EMC recommends that you use the following configuration for the transaction logs: 

Create a single transaction log file per database on one of the LUNs assigned to the transaction log space. Spread log files for different databases across available LUNs for log growth as required.



Enable the autogrow option for log files. The autogrow increment must be large enough to avoid the performance implications.

For detailed configuration steps, refer to the documents listed in EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide. SQL Server licensing consideration

With SQL Server 2012 and 2014, customers have various licensing options, including the Server+Client Access License (CAL) licensing model, which provides low-cost access to incremental SQL Server deployments, and core-based licensing, a computing power-based license model based on compute cores. The licensing options vary depending on the SQL Server version you are using. Refer to Microsoft SQL Server 2012 Licensing Guide and Microsoft SQL Server 2014 Licensing Guide on the Microsoft website. Under the core-based licensing model, customers count the total number of physical cores for each processor in the server and multiply the number of cores by an appropriate core factor to determine the number of licenses required for each processor. The core-based licensing model is appropriate when one or more of the following circumstances apply: 

Deploying SQL Server 2012 Enterprise Edition



Implementing centralized deployments that span a large number of users or devices, whether direct or indirect



Anticipating total licensing costs lower than that of using the Server+CAL licensing model

Under the Server+CAL licensing model, customers purchase a server license for each server and a CAL for each device and/or user who will access SQL Server. The Server+CAL licensing model is appropriate when one or more of the following circumstances apply: 

Deploying SQL Server 2012 Business Intelligence Edition



Deploying SQL Server Standard Edition in scenarios where you can easily count users or devices and the total licensing costs are lower than that of using the core-based licensing model



Planning to scale out use of SQL Server by adding new servers over time

To license virtualized SQL Server, customers can choose either to license individual virtual machines or, for maximum virtualization in a highly virtualized private cloud, to license the entire physical server with Enterprise Edition core licenses.

52



To choose an appropriate licensing model for SQL Server 2012 and SQL Server 2014 in various environments, refer to SQL Server 2012 Licensing Quick Reference Guide and SQL Server 2014 Licensing Quick Reference Guide on the Microsoft website.


53

Chapter 5: Solution Verification Methodologies

Chapter 5

Solution Verification Methodologies

This chapter presents the following topics: Overview ..................................................................................................................55 Baseline hardware verification methodology ...........................................................55 Application verification methodology ......................................................................55

54



Overview This chapter provides a list of items that you should review after configuring the solution. Use the information in this chapter to verify the functionality and performance of the solution and its components and to ensure that the configuration supports core availability and performance requirements.

Baseline hardware verification methodology The purpose of this chapter is to provide the verification methodologies for the hardware, application, and data protection aspects of the solution. 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 virtualized SQL Server solution. Conversely, a single misapplication of a hardware resource, such as insufficient memory on a server, can affect performance of the SQL Server. For detailed steps on verifying the redundancy of the solution components, refer to the resources listed in the EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide.

Application verification methodology After you verify the hardware and redundancy of the solution components, perform SQL Server application testing and optimization, which is a critical step of the solution. Test the new infrastructure before deploying it to production to ensure that the architectures you designed achieve the required performance and capacity targets. This testing enables you to identify and optimize potential bottlenecks before they impact users in a live deployment. Before you start verifying your SQL Server performance on the infrastructure, ensure that you have deployed SQL Server in your infrastructure based on EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide. Table 24 describes the high-level steps to be completed before you put the SQL Server environment into production. Table 24.

High-level steps for application verification

Step

Description

Reference

1

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

Understanding key metrics

2

Use the Sizing guide for SQL Server to determine the architecture and resources of infrastructure.

Appendix B


55

Chapter 5: Solution Verification Methodologies Step

Description

Reference

3

Design and build the SQL Server solution on Proven Infrastructure.

EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide

4

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

Running tests, analyzing results, and optimization

Understanding key We considered the key metrics shown in Table 25 to validate the virtualized SQL Server solution. metrics Table 25.

Key metrics

Metric

Threshold

Average CPU utilization (percent)

Less than 85 percent

Average datafile disk latency

Less than 20 milliseconds3

Average log file disk latency

Less than 5 milliseconds

The Sizing calculation helps you to understand the basic metrics and thresholds to meet your customer’s business requirements. Running tests, analyzing results, and optimization

After creating the database environment, run test applications to verify the performance of SQL Server. In this solution, we ran the tests using a simulated workload to validate the SQL Server OLTP workload performance and the SQL Server OLAP workload performance. The OLTP emulates the brokerage market transactions between market, customer, and broker. The OLAP application is an ad-hoc decision support system which consists of a suite of business ad-hoc queries and concurrent data modification to examine large volumes of data, execute queries with high degree of complexity, and provide answers to critical business questions. In the real customer environment, we highly recommend that customers do the following: 

Evaluate the OLTP and OLAP workload and I/O pattern. If it is acceptable and the real workload is similar, you can use the test results as a reference. However, customers need to consider the potential risks.



Build a test environment first, and then copy and restore the production database. This will test the real workload and verify the SQL Server performance, since the real application workload types will be different from what we validated in our test environment.

3

This is a Microsoft SQL Server best practice. XtremIO is a high performance array and can deliver sub-millisecond performance for database processing. For high workloads, it will still provide 1-5 ms performance for OLTP. For OLAP, the focus is on the bandwidth, and the disk latency can be higher, but still well below 20 ms.

56



For detailed configuration information, refer to the documents listed in the EMC

Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide.


57

Chapter 6: Reference Documentation

Chapter 6

Reference Documentation

This chapter presents the following topics: EMC documentation .................................................................................................59 Other documentation ............................................................................................... 59 Links ........................................................................................................................59

58


Chapter 6: Reference Documentation

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

EMC Solutions for Virtualized Microsoft SQL Server on EMC XtremIO Implementation Guide



EMC XtremIO Installation Guide



EMC PowerPath and PowerPath/VE for Windows Installation and Administration Guide



EMC XtremIO Series Configuration Worksheet



Using EMC XtremIO Storage with VMware vSphere TechBook



EMC VSI for VMware vSphere: Storage Viewer Product Guide



EMC Host Connectivity Guide for VMware ESX Server



EMC Host Connectivity Guide for Windows

Other documentation For information on Microsoft SQL Server, see the following documents: 

Microsoft SQL Server 2014 on VMware Best Practices Guide



Microsoft SQL Server 2014 on VMware Frequently Asked Questions (FAQ)



Microsoft SQL Server 2014 on VMware Availability and Recovery Options



Best Practices for Running VMware vSphere on Network Attached Storage



SQL Server 2012 Licensing Quick Reference Guide

For documentation on Microsoft SQL Server, refer to the Microsoft website at http://www.microsoft.com. For documentation on SQL Server 2014 on VMware, refer to the VMware website at http://www.vmware.com.

Links MSDN Library Refer to the following topics in the MSDN Library: 

Books Online for SQL Server 2014



Optimizing tempdb Performance

TechNet Library 

NIC Teaming Overview


59

Chapter 6: Reference Documentation Note: The links provided were working correctly at the time of publication.

60


SQL Server Sizing Input

Appendix A


This appendix presents the following topic: Virtualized Microsoft SQL Server worksheet ............................................................62


61


Virtualized Microsoft SQL Server worksheet Before you start sizing the virtualized SQL Server solution, gather information about the customer’s business requirements by using the worksheet. Table 26 provides a worksheet for an SQL Server user database. Table 26.

Worksheet for a SQL Server user database

Question Do you have an existing SQL Server database that you would like to size for the environment? How many databases do you want to deploy? What is the size of user database (GB)? What is the size of user database log (GB) (optional) What is the annual growth rate (percent)? What is the maximum number of IOPS? What is the required tempdb size? (optional) What is the compression ratio? (default 1.5:1) How many snapshots of the database? (optional) What is the IOPS for OLTP workloads, or bandwidth (MB/s) for OLAP workloads for each snapshot? (optional)

62


Answer

Appendix B: High-level SQL Server Sizing Logic and Methodology

Appendix B

High-level SQL Server Sizing Logic and Methodology

This appendix presents the following topics: Overview ..................................................................................................................64 Sufficient resources .................................................................................................66 Sizing considerations .............................................................................................. 66


63

Appendix B: High-level SQL Server Sizing Logic and Methodology

Overview The infrastructure supporting OLTP and OLAP—vCPUs, memory, and storage layout for SQL Server databases—must provide a robust, powerful, and flexible solution. Sizing SQL Server depends on multiple factors, such as disk type, protection type, and cache. The sufficient resources should be part of the SQL Server sizing method. 1.

We recommend 20 TB X-Bricks for SQL Server database needs. For smaller environments that do not have much future capacity growth, 5 TB or 10 TB can be used. Refer to the sizing guide for other size XtremIO X-Bricks.

2.

Expect a majority of production OLTP databases to be capacity-bound; that is, the sizing for X-Bricks mostly depends on the database size for production databases: a.

SQL Server instance VM OS and SQL Server binary storage defaults to 100 GB and performs about 25 IOPS per instance. In this manual sizing guide, we will add this to the total for easy calculation. For more accurate calculation, refer to the Sizing guide.

b.

Calculate the SQL Server database capacity using a 1.4 to 2:1 compression ratio and a 1:1 deduplication ratio.

c.

Minimal capacity requirements for snapshot copies:

b.

3.

For each snapshot, add about 1 percent of the production storage for initial sizing.

ii.

XtremIO Virtual Copy capacity can vary if they are kept for a long time, or if there are a large number of database snapshots with frequent data changes or growth. Refer to the sizing guide for a detailed calculation.

Additional capacity may be needed based on the annual growth. For example, an extra 10 percent physical capacity might be needed for future growth.

If the performance requirement is unknown, or light (less than 5,000 IOPS for OLTP or less than 100 MB/s for OLAP), refer to Table 27 for vCPU and memory requirement for the virtual machines running SQL Server instances for databases with specific sizes. For more demanding workloads, refer to Table 28.

Table 27.

64

i.

Recommended vCPU and memory for database size

DB size

Recommended CPU in addition to base configuration of 2 vCPU

Recommended memory (GB) in addition to base configuration of 4 GB